Сущность модельно-ориентированного проектирования ЭИС сводится к адаптации компонентов типовой ЭИС в соответствии с моделью проблемной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ЭИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними.
Ядром типовой ЭИС является постоянно развиваемая модель проблемной области (предприятия), поддерживаемая в специальной базе метаинформации - репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ЭИС сводятся прежде всего к построению модели проблемной области и ее периодической корректировке.
Для моделирования проблемной области и последующих конфигураций информационной системы из отдельных компонентов (программных модулей) используется специальный программный инструментарий, например SAP Business Engineering Workbench (BEW) [52] и BAAN Enterprise Modeler [70]. Несомненным достоинством применения модельно-ориентированных компонентных систем, таких, как R/3 или BAAN IV, перед CASE -технологиями является накапливание опыта проектирования информационных систем для различных отраслей и типов производства в виде типовых моделей, которые поставляются вместе с программным продуктом в форме наполненного репозитория. Таким образом, вместе с программным продуктом пользователи приобретают базу знаний «know-how» об эффективных методах организации и управления бизнес-процессами, которые можно адаптировать в соответствии со спецификой конкретного экономического объекта.
Репозитории корпоративной ЭИС, использующей модельно-ориентированную технологию проектирования, в общем случае содержит метаинформацию базовой модели функциональности типовой системы (ссылочной модели в терминологии R/3), типовых моделей определенных классов ЭИС (референтных моделей в терминологии BAAN) и модели предприятий, получаемой на основе базовой или типовых моделей.
Базовая модель репозитория содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, организационной структуры, которые используются в программных модулях типовой ЭИС. При этом большое значение в базовой модели имеет задание бизнес-правил поддержания целостности информационной системы, определяющих условия проверки корректности совместного применения различных компонентов ЭИС. Таким образом, многообразие и гибкость определения бизнес-процессов и соответствующих конфигураций информационной системы задаются с помощью набора бизнес-правил.
Типовые модели описывают конфигурации информационной системы для определенных отраслей (автомобильной, электронной, нефтегазовой и др.) или типов производства (единичного, серийного, массового, непрерывного и др.).
Модель предприятия (проблемной области) строится либо путем привязки фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия, например как в инструментальном средстве BAAN Enterprise Modeler, либо в результате просмотра этих моделей и экспертного опроса, как в инструментальном средстве SAP Business Engineering Workbench. Причем в последнем случае пользователю предлагается определить значения не всех параметров, а только тех, которые связаны между собой в контексте диалога и описаны бизнес-правилами.
Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. Далее по модели предприятия автоматически осуществляется конфигурация информационной системы, в ходе которой выполняется семантический контроль по бизнес-правилам.
В обобщенном виде конфигурация корпоративных информационных систем на основе модельно-ориентированной технологии [83] представлена на рис. 14.9.
Рис. 14.9. Конфигурация ЭИС на основе модельно-ориентированной технологии
Рассмотрим компоненты модели предприятия более детально.
Модель функций
Модель функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия. На первом уровне иерархии обычно указываются основные виды функциональных подсистем: сбыт, производство, логистика, сервис, финансы, персонал и т.д. На следующем уровне иерархии для каждой функциональной подсистемы показываются функциональные модули, например, подсистема «Логистика» включает в себя функциональные модули: планирование потребности в материалах, закупки, управление запасами, управление складами, проверка платежей и т.д. Для функциональных модулей задаются наборы бизнес-функций, для каждой из которых в дальнейшем определяются бизнес-процессы. Например, для функционального модуля «закупки» определяются бизнес-функции: оформление договоров, оформление заказов, выписка счетов и т.д.
В системе R/3 просмотр функциональности типовой ЭИС осуществляется с помощью программы-навигатора репозитория. Пример навигации на фрагменте модели функций показан на рис. 14.10.
Рис. 14.10. Фрагмент модели функций в системе R/3
В процессе навигации по дереву можно перейти к документации, описывающей соответствующую функцию, и определению подфункций. Для функций последнего уровня по желанию специалиста-конфигуратора открывается просмотр схемы бизнес-процесса с используемыми входными-выходными данными и участвующими организационными единицами или схемы бизнес-объектов в виде ER-модели.
В системе BAAN IV с помощью инструмента Enterprise Modeler можно построить четырехуровневое дерево декомпозиции функций (рис. 14.11).
Рис. 14.11. Модель функций системы BAAN IV
В отличие от R/3 бизнес-функции могут называться именами, характерными для конкретного предприятия. Кроме того, для функций могут быть заданы показатели оценки эффективности их выполнения, произвольное текстовое описание (например, инструкции для выполнения), а для функций последнего уровня указываются варианты реализации (оптимизации) по мере внедрения ЭИС (например, функция с интерактивным и автоматическим выполнением).
Модель процессов
Модель бизнес-процесса отражает последовательность выполнения работ (операций) для функций самого нижнего уровня модели бизнес-функций, которая позволяет провести конфигурацию программных модулей информационной системы в соответствии с характерными особенностями конкретной проблемной области.
Как в системе R/3, так и в системе BAAN IV для представления бизнес-процессов используется аппарат сетей Петри, позволяющий отображать управление процессами в зависимости от событий: работа выполняется в том случае, если на входе известно состояние системы.
В системе R/3 для отображения процессов используется модель управления событиями (ЕРС - event-driven process chain), реализованная в ARIS Toolset (рис. 14.12).
Рис. 14.12. Модель управления событиями бизнес-процесса в системе R/3
В соответствии с этим методом переходы между операциями осуществляются в зависимости от событий, которые могут связываться логическими связками AND, OR, XOR. Кроме того, по требованию пользователей в модели процесса могут быть показаны входные-выходные данные, участвующие организационные единицы, указывается тип обработки (интерактивный, пакетный). Операции бизнес-процесса, как и процесс в целом, документируются.
Модель бизнес-процесса, построенная с помощью BAAN Enterprise Modeler (рис. 14.13), позволяет в качестве операций использовать не только программные модули BAAN IV, но и ручные процедуры, приложения, разработанные в другой программной среде.
Конкретные операции могут иметь вложенные наборы операций, т.е. представляться в виде подпроцессов. Некоторые части бизнес-процесса могут не выполняться в зависимости от конкретных условий, связанных с состояниями (событиями) процесса, и затеняются на графическом изображении процесса. С работами могут быть соотнесены должностные инструкции, документы и коды общих вспомогательных программ (утилит).
Рис. 14.13. Модель бизнес-процесса в среде BAAN Enterprise Modeler
Модели объектов (данных)
В модельно-ориентированной технологии проектирования ЭИС интегрирование различных бизнес-процессов (приложений) осуществляется на основе бизнес-объектов. Согласно определению комитета Business Object Task Force OMG [72] бизнес-объекты - компоненты уровня проблемной области, которые используются в различных приложениях в произвольных комбинациях и не зависят от них. При этом «приложение обеспечивает среду для функционирования бизнес-объектов». OMG разрабатывает спецификации программных оболочек, которые предоставляют готовые объекты для следующих приложений: производства, электронной коммерции, транспортировки, телекоммуникаций, здравоохранения, финансов и др.
С одной стороны, бизнес-объекты - это объекты-сущности в нотации UML (см. п. 13.3), например заказы, счета, материалы, поставщики и т.д. С другой стороны, в отличие от обычных объектов-сущностей бизнес-объекты являются самодостаточными, т. е. имеют стандартный интерфейс, написанный на языке описания интерфейсов IDL (Interface Definition Language), с помощью которого бизнес-объекты могут взаимодействовать друг с другом через объектную шину - брокер объектных запросов (Object Request Broker). Таким образом, бизнес-объекты обладают более сложной внутренней структурой по сравнению с простыми объектами. Например, структура бизнес-объектов R/3 включает ограничения целостности в виде допустимых типов связей с другими объектами и бизнес-правила по связям с внешней средой, интерфейсы в виде входных-выходных событий и спецификации доступа к объектам.
В системе R/3 разработано более 100 стандартных интерфейсов бизнес-объектов, называемых BAPI (Business Application Programming Interface), которые позволяют осуществлять непосредственную связь между приложениями разных предприятий в среде ИНТЕРНЕТ. Например, при оформлении заказа от клиента поставщику могут использоваться следующие стандартные методы бизнес-объектов:
ProductGroup.Select - выбор группы изделий в каталоге;
ProductDescription - просмотр описания изделия;
Product.Select - выбор изделия из группы;
Order.Create - создание заказа и т.д.
В системе R/3 модель бизнес-объектов описывается как статическая ER -модель, в которой каждая сущность может рассматриваться как обычный объект данных, который используется на входе или выходе операций, так и как бизнес-объект с присоединенными методами
В инструменте BAAN Enterprise Modeler модель бизнес-объектов не отражается вследствие использования стандартной структуры базы данных, которую можно настраивать на особенности конкретного предприятия.
