Часть вторая. Выигрыш для всех
Большинство разработчиков финансовых программ движутся в общем направлении, но каждый сам прокладывает дорогу, дублируя усилия других. При этом в самом большом проигрыше оказываются пользователи. Даже предприятия, схожие по роду деятельности, имеют различные программы, в которых одни и те же задачи формализуются разными способами. Одинаковые для всех формы бухгалтерской отчетности каждый квартал приходится переписывать на языке своей системы.
Для конечного пользователя, который выбирает тот или иной “склад” или “бухгалтерию” в какой-то мере случайно, идеальным было бы существование единого макроЯзыка высокоуровневого Описания информационных объектов учета, Бухгалтерских Расчетов и форм выходной информации (ЯОБР), поддерживаемого несколькими программными системами.
Это позволило бы применять стандартные, не зависящие от конкретного продукта библиотеки описаний расчетов, правил формирования типовых операций и выходных форм, создаваемые независимыми консультационными фирмами, в том числе аудиторскими.
ОТКРЫТЫЙ ИНТЕРФЕЙС СИСТЕМ АВТОМАТИЗАЦИИ УЧЕТА
Один из вариантов поддержки единого языка - встраивание его интерпретатора в каждую систему автоматизации учета, что эффективно для небольших систем. А при использовании в прикладной системе механизмов межпрограммной связи открылись бы качественно иные перспективы. Тогда стало бы возможным автоматизировать оперативный и бухгалтерский учет на основе архитектуры, включающей следующие компоненты: систему ведения первичных данных (СВПД), основанную на собственной модели логической организации учетных данных, поддерживающей расчет базисного набора показателей и построение форм выходной информации, устойчивых относительно изменений законодательства; единый язык высокоуровневого описания информационных объектов учета, бухгалтерских расчетов и форм выходной информации (ЯОБР) и исполнительную систему макропрограмм (ИСМ), написанных на нем, оформленную как отдельный модуль, поддерживающий механизм межпрограммного взаимодействия; комплекс макропрограмм на ЯОБР, описывающих нестандартные, характерные именно для данного предприятия или отрасли особенности обработки данных, которые нецелесообразно включать в типовую систему СВПД.
Проще говоря, в качестве основы проекта автоматизации разумно использовать не один, как сейчас, замкнутый в себе продукт, который и вводит данные, и выполняет их обработку, а два во многом независимых, созданных разными разработчиками.
Один из них - СВПД - вводит и хранит данные, а другой - ИСМ - вычисляет, выполняет алгоритмы расчета тех или иных показателей, получая данные от внешней системы - СВПД.
ДОПОЛНИТЕЛЬНАЯ СТЕПЕНЬ СВОБОДЫ
Если СУБД обеспечивают независимость программ от логической и физической структуры используемых ими данных, а механизм ODBC позволяет прикладному ПО быть относительно независимым от самих СУБД, то в рассматриваемом случае появляется некое ядро прикладной системы, полностью независимое от способов ввода, накопления, организации документооборота, первичной обработки и организации доступа к оперативным учетным данным.
СУБД дают только формальную независимость от данных, а пара {ЯОБР, ИСМ} - содержательную, стандартизируя способы описания нестандартных расчетов в конкретной предметной области и не связывая алгоритмы с частностями ее информационных моделей в системах конкретных разработчиков.
ВОЗМОЖНО ЛИ ЭТО?
В изложенном выше контексте СВПД - это та же “бухгалтерия”, “склад” или “зарплата”, выполняющая функции ввода, хранения и базовой обработки данных. Под базовой обработкой понимается совокупность алгоритмов и выходных форм, относительно устойчивых к изменению нормативных актов. ЯОБР - язык описания информационных объектов данной предметной области и манипуляций над ними. ИСМ - некий новый продукт, интерпретирующий макропрограммы на ЯОБР.
Схема функционирования конечного проекта системы автоматизации бухгалтерского учета на основе принципа открытой архитектуры
Реализация ИСМ как интерпретатора формального языка - каноническая задача программирования. Организовать межпрограммные связи тоже не Бог весть как сложно: любая “бухгалтерия” под Windows поддерживает DDE. Таким образом, технически реализовать предложенное не составляет больших проблем.
Несколько сложнее придумать содержательно полный ЯОБР. Однако и этот вопрос решается: для того чтобы придумать что-то типа Account Basic, достаточно очертить примерный круг задач по обработке учетных данных. Значительно сложнее сделать так, чтобы Account Basic стал промышленным стандартом в своей области. Кто же по собственной воле откажется от идеи, что его программа самая великая и могучая и способна решать все задачи учета?
ПОСЛЕДСТВИЯ ДЛЯ РЫНКА
Посмотрим на рынок. Оказывается, тихо и незаметно определенные стандарты в области автоматизации бухгалтерии уже установились. Так, не менее десяти “складов” независимых разработчиков умеют передавать информацию в “1С:Бухгалтерию”. Немало “складов” и “зарплат” умеют взаимодействовать с “Турбо-Бухгалтером” и “Инфо-Бухгалтером”. А если кто-то предложит удачный продукт типа Account Basic, построенный на изложенных выше принципах, то почему бы и здесь не возникнуть стандарту де-факто?
Следом появится возможность использовать массовые, независимые от СВПД библиотеки приложений, применяемые конкретными организациями. Это могут быть, например, настройки, имеющие отраслевую специфику. Универсальность языка их описания стала бы для консультационных фирм стимулом к разработке таких библиотек. Конкуренция может частично переместиться из сферы тиражного прикладного ПО на уровень конечных решений. При этом разработчики СВПД смогут сосредоточиться на совершенствовании систем для информационной платформы бухгалтерского и оперативного учета, не заботясь о функциональной полноте процедур обработки данных.
Двухуровневое построение систем автоматизации управления дает существенные козыри и при системной интеграции. Не надо будет проводить анализ того, являются ли те или иные пакеты программ функционально полными и совместимы ли они друг с другом на уровне данных. Достаточно ответить только на один вопрос - обеспечивает ли СВПД ведение базы данных, включающей необходимую информацию. А это значительно проще, чем задача анализа функциональной полноты, который не всегда тривиален в случае ПО для решения учетных задач.
К Евгению Шуремову, доценту Финансовой академии, эксперту Центра исследований экономических систем “Бизнес-Программы-Сервис”, можно обратиться по телефону: (095) 281-2443 или по адресу:
E-mail: root@arep.msk.su.
Евгений Шуремов
