14.3. Модельно-ориентированное проектирование эис
Сущность модельно-ориентированного проектирования ЭИС сводится к адаптации компонентов типовой ЭИС в соответствии с моделью проблемной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ЭИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними.
Ядром типовой ЭИС является постоянно развиваемая модель проблемной области (предприятия), поддерживаемая в специальной базе метаинформации - репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ЭИС сводятся прежде всего к построению модели проблемной области и ее периодической корректировке.
Для моделирования проблемной области и последующих конфигураций информационной системы из отдельных компонентов (программных модулей) используется специальный программный инструментарий, например 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 модель бизнес-объектов не отражается вследствие использования стандартной структуры базы данных, которую можно настраивать на особенности конкретного предприятия.
Модель организационной структуры
Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала (организационных единиц). Назначение моделирования организационной структуры применительно к информационной системе заключается в распределении автоматизируемых функций по работникам подразделений и определении полномочий доступа к информационной системе.
С помощью инструмента BEW в модели бизнес-процесса явно указывается закрепление автоматизированных функций по подразделениям (см. рис. 14.12).
С помощью инструмента Enterprise Modeler связь модели бизнес-процесса и модели организационной структуры задается через указатели роли, которые могут выполняться различными организационными единицами (рис. 14.14).
Рис. 14.14. Установление связи модели организационной структуры и модели бизнес-процесса
Через указатели роли сотрудников устанавливается связь организационной структуры с бизнес-процессами. Указатель роли определяет тип работника, который может выполнять ту или иную работу (экономист, бухгалтер, менеджер и т.д.). Для каждой роли определяются полномочия в выполнении функций, права доступа к информации, должностные инструкции. При назначении работы конкретному работнику всегда осуществляется проверка роли, которую он может выполнять. Если при этом тип конкретного работника не соответствует роли, то последний не получает доступа к выполнению работы.
Модели бизнес-правил
Бизнес-правила - это специальные сведения в области типовой ЭИС, которые хранятся в репозитории и используются для контроля корректности построенной модели предприятия и процессов конфигурации и эксплуатации ЭИС. В системе R/3 бизнес-правила встроены в бизнес-объекты, в системе BAAN бизнес-правила выделены в самостоятельные компоненты. Рассмотрим применение бизнес-правил на примере системы ВAAN.
Правила целостности модели предприятия
Правила целостности используются для проверки согласованности модели предприятия с точки зрения полноты и непротиворечивости бизнес-функций, например:
Если присутствует вариант бизнес-функции «Прямая поставка», тогда бизнес-функции «Обработка заказа на приобретение» и «Обработка заказа на сбыт» должны быть представлены в модели.
Правила преобразования моделей бизнес-функций в модели бизнес-процессов
Модель бизнес-функции может быть автоматически преобразована в модель бизнес-процесса посредством правил преобразования, которые задают соответствие бизнес-функции и бизнес-процесса, например:
Если был определен вариант бизнес-функции «Обработка заказа на приобретение с контрактами», необходимо выбрать бизнес-процесс «Обработка контрактов».
Правила конфигурации (установки параметров)
Правила конфигурации используются для присвоения значения параметру BAAN в зависимости от его наличия в бизнес-функциях, бизнес-процессах или их комбинациях. Например:
Если был определен вариант бизнес-функции «Обработка заказа на покупку в режиме ЭОД (электронный обмен данными)», значение параметра «электронный обмен данными» настраивается на «да».
Правила установки статических условий
Правила установки статических условий осуществляют выбор варианта бизнес-процесса в зависимости от выполнения условия. Если значение условия правила ложно, то данный вариант в процессе эксплуатации не выполняется и на диаграмме процесса соответствующая неактивная ветвь дерева изображается в затемненном виде, например:
Если бизнес-функция «Оформление аккредитива» не используется в фазе внедрения, то запретить процесс оформления аккредитива.
Технологическая сеть модельно-ориентированного проектирования ЭИС
В силу сложности комплексной типовой информационной системы для модельно-ориентированного проектирования характерны следующие особенности.
Привязка типовой информационной системы к условиям конкретного экономического объекта осуществляется в результате совместных усилий фирмы-производителя программного продукта и проектной группы предприятия.
Консультанты со стороны фирмы-производителя программного продукта принимают участие на всех этапах внедрения системы и особенно на этапе анализа требований.
Возрастает роль руководства предприятия в организации и контроле за созданием информационной системы.
В известных методологиях модельно-ориентированного проектирования ЭИС Accelerated SAP и BAAN Orgware большое внимание уделяется регламентации последовательности операций на основе применения программных средств планирования, позволяющих ускорить процесс внедрения типовой ЭИС. Технология модельно-ориентированного проектирования ЭИС включает четыре основные стадии: выбор типового проекта, разработку проектной модели предприятия, реализацию проекта, ввод в эксплуатацию и поддержку функционирования.
На всех стадиях используется инструментарий моделирования предприятия, применение которого рассматривается в технологической сети проектирования ЭИС (рис. 14.15).
Преобразователь П1 «Выбор типовой ЭИС-анализ требований»
Внедрение типовой информационной системы начинается с анализа требований конкретной организационно-экономической системы предприятия к ЭИС (см. рис. 14.15). В частности, на основе результатов предпроектного обследования (D1) формируется предварительная модель предприятия (D2), которая аккумулирует требования к функциональности информационной системы (множеству автоматизируемых функций) и на основе которой осуществляется выбор наиболее адекватного программного комплекса. Данная работа может быть выполнена в рамках проведения предварительного реинжиниринга бизнес-процессов. Возможен и другой вариант анализа требований, которые определяются существующей организацией бизнес-процессов.
Рис. 14.15. Технологическая сеть модельно-ориентированного проектирования ЭИС: D1 - результаты предпроектного обследования; D2 - предварительная модель предприятия; D3 - проектная модель предприятия; D4 - документация по использованию ЭИС; U1 - универсум типовых ЭИС; U2 – универсум компонентов базовой модели типовой ЭИС (референтная модель), U3 - универсум бизнес-правил; U4 - универсум языковых средств четвертого поколения; G1 - сконфигурированные и доработанные вручную программные модули ЭИС, G2 - интерфейсы; G3 - структура базы данных (бизнес-объектов), G5 - программно-техническая среда эксплуатации ЭИС, G6 - наполненная база данных.
Во втором случае реально существующая модель предприятия будет адаптироваться (эволюционировать) на этапе эксплуатации информационной системы с целью оптимизации функционирования организационно-экономической системы. По мнению специалистов [46], такой эволюционный инжиниринг обеспечивает более быстрое внедрение корпоративной ЭИС, сокращение капитальных затрат и повышение эффективности эксплуатации ЭИС.
Предприятие, внедряющее типовую информационную систему, стремится выбрать наилучший программный продукт, соответствующий конкретным условиям. Поэтому на этапе выбора типового проекта в конкурсе может участвовать несколько конкурирующих фирм, программные продукты которых (U1 - универсум типовых ЭИС) не только оцениваются по методике, изложенной в п. 14.2, но и с позиции реализации предлагаемой модели предприятия. В результате анализа требований выбирается конкретная типовая ЭИС, универсум компонентов которой U2 используется на последующих стадиях внедрения проекта.
Рассмотрим выполнение стадии «Выбор типовой ЭИС» более детально. На рис. 14.16 представлена технологическая сеть построения предварительной модели предприятия.
Рис. 14.16. Технологическая сеть построения предварительной модели предприятия: D11 - бизнес-цели; D12 - модель бизнес-функций; D13 – существующая организационная структура; D14 - модель бизнес-объектов, D15 - модель бизнес-процессов; D16 - модель организационной структуры; Ш - компоненты референтной модели
Сущность операций «Построение модели бизнес-функций» (преобразователь П11) сводится к определению набора бизнес-функций, которые должны быть автоматизированы с позиции наибольшего влияния на достижение основных бизнес-целей D11 (критериев эффективности функционирования предприятия) при условии соблюдения ресурсных ограничений. Данная операция выполняется на уровне руководителей предприятия при непосредственном участии консультантов фирм-производителей типовых информационных систем, которые демонстрируют руководству референтные модели из универсума U2. На выходе операции формируется список выбранных бизнес-функций D12, представленных в графической модели.
Далее к построению предварительной модели предприятия подключаются ключевые пользователи предприятия - руководители линейных и функциональных подразделений. Консультанты, интервьюируя ключевых пользователей, на основе сформированных бизнес-функций D12, используя референтные модели U2, строят модели бизнес-объектов D14 (преобразователь П12), бизнес-процессов D15 (преобразователь П13) и организационной структуры D16 (преобразователь П14). Причем модель организационной структуры строится с учетом построенных моделей бизнес-процессов и бизнес-объектов, а также существующей организационной структуры D13. Заметим, что в предварительной модели предприятия ее элементы могут быть представлены достаточно в обобщенном виде, детализация модели предприятия произойдет после выбора типовой ЭИС.
После завершения этапа построения предварительной модели предприятия руководство предприятия принимает решение о выборе типовой информационной системы, модель предприятия которой в наибольшей степени соответствует целям автоматизации, а также набору других критериев (см. п. 14.2).
Далее на основе принятого решения о закупке программного обеспечения осуществляются оформление соглашения с фирмой-производителем типовой информационной системы о продаже и проведении работ по внедрению программного обеспечения, собственно закупка, формирование проектной группы внедрения, выделение всех необходимых ресурсов и формирование календарного плана-графика работ. В результате формируются технико-экономическое обоснование и техническое задание на внедрение типовой ЭИС.
Преобразователь П2 «Разработка проектной модели предприятия»
Для модельно-ориентированной технологии проектирования ЭИС характерна привязка модели предприятия к функциональности типовой ЭИС (см. рис. 14.15), на основе которой в последующем автоматически выполняется конфигурация информационной системы. Поэтому на входе преобразователя П2 задаются предварительная модель предприятия (D2), референтная модель функциональности типовой ЭИС (U2) и универсум бизнес-правил отображения модели (U3), а на выходе формируется проектная модель предприятия (D3), в которой определяются компоненты типовой ЭИС, компоненты других программных продуктов и компоненты, которые должны быть специально разработаны с помощью инструментальных средств четвертого поколения, например АВАР/4 (SAP) или набора инструментов Tools (BAAN).
На этапе разработки проектной модели предприятия выполняются следующие работы:
инсталляция программного продукта, реализующего типовую ЭИС;
проведение обучения проектной команды;
привязка модели предприятия к компонентам типовой информационной системы;
определение требований к доработке программного обеспечения;
проектирование внешних интерфейсов системы.
Рассмотрим технологическую сеть привязки модели предприятия к компонентам типовой информационной системы более детально (рис. 14.17).
Рис. 14.17. Технологическая сеть привязки модели предприятия к компонентам типовой информационной системы: D12 - модель бизнес-функций; D14 - модель бизнес-объектов; D15 - модель бизнес-процессов; 016 - модель организационной структуры; D21 - проектная модель бизнес-функций; D22 - привязка программных модулей типовой ЭИС к функциональным блокам бизнес-процессов; D23 - спецификации на разработку программных модулей; D24 – структура используемых бизнес-объектов; D25 - роли исполнителей; D26 - спецификации интерфейса пользователя; U2 – компоненты референтной модели; U3 - бизнес-правила
В начале разработки проектной модели консультанты по типовой информационной системе совместно с проектной группой на основе предварительно построенной модели бизнес-функций D12 и референтной модели U2 уточняют модель бизнес-функций D21 (преобразователь П21). Правильность выбора бизнес-функций контролируется на основе использования бизнес-правил U3.
Далее осуществляется привязка программных модулей типовой ЭИС к функциональным блокам бизнес-процессов D22 (преобразователь П22). Для этого компоненты референтной модели U2, описывающие программные модули типовой ЭИС, приписываются к функциональным блокам модели бизнес-процесса D15, связанным с моделью бизнес-функций D21. Для оригинальных компонентов в модели бизнес-процессов задаются спецификации на разработку программных модулей D23. Корректность выбора бизнес-процессов для бизнес-функций и условий привязки и выполнения программных модулей проверяется по бизнес-правилам U3.
В операции «Привязка бизнес-объектов к программным модулям» (преобразователь П23) характер программных модулей D22, D23 уточняется составом используемых бизнес-объектов D14. В результате формируется структура используемых бизнес-объектов D24. В объектно-ориентированном представлении данная операция выполняется путем задания имен методов в определениях классов объектов, в функционально-ориентированном представлении для соответствующих процедур задается список входных и выходных объектов. Корректность привязки контролируется с помощью бизнес-правил U3.
В заключение осуществляется привязка исполнителей процесса D16 (единиц модели организационной структуры) к используемым программным модулям D22 и D23 и бизнес-объектам D24 (преобразователь П24). При этом устанавливаются роли исполнителей D25 для выполнения той или иной работы и создаются спецификации интерфейса пользователя D26. Корректность операции проверяется также с использованием бизнес-правил U3.
Преобразователь ПЗ «Реализация типового проекта ЭИС»
Реализация типового проекта ЭИС сводится к конфигурации ЭИС и генерации интерфейсов пользователей (см. рис. 14.15), то есть получении готовых для эксплуатации программ функций обработки данных G1 и интерфейсов G2, а также определении структуры базы данных (бизнес-объектов) G3. Настройка программного комплекса типовой ЭИС и генерация интерфейса пользователей осуществляются автоматически на основе бизнес-правил U3 и проектной модели предприятия (D3). В исключительных случаях требуется доработка или создание новых программных модулей, которые производятся с помощью инструментальных средств программного комплекса U4.
Реализация типового проекта предполагает установку следующих параметров:
глобальных параметров;
структуры компании;
структуры основных данных;
функций и процессов;
интерфейсов;
системы отчетов;
системы архивирования;
системы авторизации доступа.
Рассмотрим технологическую сеть конфигурации и кастомизации ЭИС более подробно (рис. 14.18).
Рис. 14.18. Технологическая сеть конфигурации ЭИС: D22 - привязка программных модулей типовой ЭИС к функциональным блокам бизнес-процессов; D23 - спецификации на разработку программных модулей, D24 - структура используемых бизнес-объектов, D2S- модель взаимодействия исполнителей и бизнес-процессов (роли исполнителей), D26 – спецификации интерфейса пользователя, G11 - сконфигурированные программные модули; G12 - доработанные (новые) программные модули; G21 – сгенерированные интерфейсы, G22 - запрограммированные интерфейсы; Ш - бизнес-правила, U4 - языковые средства и инструментальные средства 4GL.
Конфигурация программных модулей G11 (преобразователь П31) осуществляется путем установки параметров по модели бизнес-процессов D22 , которая осуществляется либо автоматически с помощью бизнес-правил U3, либо вручную аналогично параметрической настройке отдельных ППП (см. п. 14.2).
Настройка таблиц объектов базы данных G3 (преобразователь П32) осуществляется по определению бизнес-объектов D24 либо автоматически на основе использования бизнес-правил U3, либо вручную путем определения подмножества необходимых атрибутов.
Генерация пользовательских рабочих мест (интерфейсов) G21 (преобразователь П33) выполняется автоматически по модели взаимодействия исполнителей и программных модулей D25 (описанию ролей пользователей).
Доработка программных модулей или разработка новых программных модулей функций G12 и интерфейсов G22 осуществляется на основе определенных ранее спецификаций на доработку программных модулей D23 и интерфейсов D26 и с учетом сконфигурированных других программных модулей G11, структур баз данных или бизнес-объектов G3, интерфейсов G21 с использованием языковых средств 4GL и других программных инструментов U4.
В завершении стадии реализации осуществляется комплексное тестирование всех компонентов корпоративной ЭИС.
Преобразователь П4 «Ввод в эксплуатацию»
Ввод в эксплуатацию типового проекта осуществляется поэтапно в соответствии с определенным планом. Перед началом эксплуатации должны быть выполнены следующие работы (см. рис. 14.15):
создание документации конечных пользователей (D4) и их обучение;
установка программно-технической среды эксплуатации ЭИС (G5);
наполнение информацией новых баз данных или подключение и конвертация существующих баз данных (G6).
В процессе эксплуатации ЭИС осуществляется системная поддержка для устранения возникающих замечаний. Особое внимание на стадии эксплуатации придается развитию проекта ЭИС. Для этого система должна накапливать статистику о характере функционирования информационной системы, на основе которой происходит технологическая отладка эффективности эксплуатации ЭИС. Важно также осуществлять анализ эффективности организации с помощью информационной системы бизнес-процессов на основе контроллинга экономических показателей, который приводит к непрерывному совершенствованию проектной модели предприятия D3 (на рис. 14.15 обратная связь от преобразователя П4 к П3), а следовательно, к адаптации ЭИС к необходимым изменениям.