Открытая модель деятельности

Как правило, бизнес-процессы описываются сначала в диаграммах и схемах, а затем - прямым кодированием в приложении. Так, в "горизонтальных" приложениях есть модули "склад", "банк", "касса", а для "вертикальных" приложений созданы программные пакеты "анализ устойчивости коммерческого банка", "анализ инвестиционного портфеля" и "анализ финансового состояния".

Модульные приложения и пакеты программ создаются задолго до их применения. Они развиваются по циклу "проектирование - кодирование - тестирование модуля - тестирование пакета - обучение - сопровождение". Это сложный, долгий и дорогой процесс с большой задержкой реакции на изменения условий бизнеса.

Анализ себестоимости проектов, выполненных нашей компанией до 1994 года, показал, что рентабельность проектов может снизиться до нуля при увеличении числа клиентов, если компания и дальше будет принимать обязательства по адаптации созданных систем к меняющимся условиям. Клиенты не согласились отказаться от дальнейшего развития созданных для них систем (и это правильно).

Весной 1995 года были приняты два решения:

• начать исследования и разработки для создания в течение года новой платформы с целью радикального снижения себестоимости производства и последующей адаптации информационных систем поддержки деятельности и развития предприятий;
• рекратить прием заказов на системы, основанные на платформе "SCO Unix & Informix/4GL", начиная с весны 1996 года.

Принципы новой платформы:

• платформа должна позволять создавать и развивать модель бизнеса посредством ввода новой информации в терминах деятельности без изменения кода платформы;
• платформа должна позволять создавать любое число моделей бизнеса с любым числом предприятий для сценарного исследования будущего и управления текущей деятельностью предприятий;
• платформа должна развиваться, пополняясь новыми компонентами, без переделок ранее созданных моделей бизнеса, автономно от развития серверов и СУБД, на которые она устанавливается.

Мы не стали делить деятельность предприятия по функциям подразделений или процессам, а детально проанализировали доступные нашему наблюдению примеры финансово-хозяйственной деятельности (далее - ФХД) наших клиентов. В итоге были найдены три компонента модели ФХД, инвариантные к виду деятельности (производство, торговля, сервис) и к отрасли предприятия:

• "ресурсы";
• "операции с ресурсами";
• "правила активизации операций с ресурсами".

Эти компоненты состоят из разделов и подразделов, пополняя которые можно по необходимости расширять и изменять модель. Так компонент "ресурсы", как правило, имеет разделы: "финансовые", "материальные", "трудовые", "энергетические", "информационные". Раздел "материальные" делится на подразделы: "товары", "оборудование", "здания" и "коммуникации". Аналогично - для "операций с ресурсами".

Мы установили, что все компоненты модели ФХД можно представить в виде открытой к пополнению сети. Каждый узел сети имеет ссылку на термин, смысл которого описан как стандарт. Термины находятся в диапазоне от уровня СУБД до терминов реальной ФХД предприятия. Мы предположили, что основой новой платформы может стать единый для всех компонентов модели механизм описания и расширения сети терминов и такой механизм можно описать простыми правилами:

ЕСЛИ { "условие" } ТО { "действие" }.

Аргумент "условие" и оператор "действие" могут содержать аналогичные правила. Чтобы платформа с множеством таких простых механизмов работала, должна быть создана программа, способная в реальном времени подбирать нужные в данный момент правила, выводить общее правило и выполнять именно те действия, которые следуют из этого общего правила. Та же программа должна объединять простые понятия в более сложные. Позже мы назвали ее "интерпретатор".

Мы применили интерпретатор для сложения и вычитания сетей терминов и (так как понятия "структура", "список" и "таблица" являются частным случаем понятия "сеть") смогли создать "алгебру документов". Мы нашли правила исчисления вершин и связей для новой сети и создали инструменты исчисления спецификаций, прилагаемых к документам.

Программирование платформы для обработки документов стало делом несложным. Например, написав формулу:

{ "спецификация недопоставленного по контракту [Х]" } = { "спецификация недопоставленного по контракту [Х]" } - { "спецификация к акту оприходования ТМЦ на склад по контракту [X]" },

можно сразу же после приема на складе ТМЦ узнать список недопоставленного по контракту. Аналогично можно автоматически составить реестр по браку или иным претензиям и написать в платформе правило, чтобы она в дальнейшем направляла такие документы, например, юристу.

Конечно, чтобы правила применялись платформой, надо также определить смысл новых понятий "ТМЦ", "контракт" в соответствии с уже определёнными в платформе понятиями.