пр_ИС_Тем14
.pdfпроектирования пользовательского интерфейса и отчетов (VIP, FCOM, ARD, GalaGraf, «Бизнес-текст»).
Ксредствам администратора базы данных относятся следующие утилиты:
•• утилита разграничения прав доступа Protect, которая предназначена для регистрации пользователей комплекса «Галактика». Утилита позволяет установить права пользователей или групп пользователей на чтение, добавление, модификацию и удаление записей базы данных, а также ограничить доступ к элементам меню прикладной программы;
•• утилита ведения журнальных файлов и персонификации действий оператора
Journal, которая предназначена для контроля действий пользователя по модификации базы данных. Утилита осуществляет ведение системного журнала по всей БД либо по выбранному перечню таблиц и позволяет администратору системы отследить дату и время последней модификации или удаления записей БД, а также оператора, выполнившего эти действия;
•• утилита корпоративного меж-офисного обмена данными Corpo,
предназначенная для организации меж-офисного обмена данными в территориально удаленных локальных вычислительных сетях;
•• утилита пошагового воспроизведения операций с данными Repair,
позволяющая восстановить базу данных, утерянную или ошибочно модифицированную вследствие некорректных действий операторов.
Средства пользователя-программиста включают следующие инструменты.
Процессор пользовательского интерфейса Vip, предназначен для создания многооконного пользовательского интерфейса, обеспечивающего корректный и эффективный ввод данных.
Средства Vip позволяют:
•задать логическую таблицу;
•описать анкетные и табличные редакторы с указанием корневой таблицы, переключаемые форматы, дополнительные окна (диалоговые окна, режимы перехода и выбора);
•запрограммировать обработчики событий для видимых элементов экрана, используя функции управления логическими таблицами и видимыми элементами, операторы
SQL, циклы, условные операторы, запуск другого меню, интерфейса или диалогового окна с передачей параметров.
Компилятор выходных форм Fcom, необходим для автоматического формирования отчетных документов по заданному шаблону. FCom может быть использован для создания выходных текстовых документов на основе информации из прикладных программ или баз данных. Возможности по модификации существующих в «Галактике» форм базируются на механизме формы-прототипа и присоединенной формы.
Многофункциональный текстовый процессор БИЗНЕСТЕКСТ предназначен для просмотра и редактирования текстов и ориентирован на обработку больших массивов данных.
Пакет деловой графики GalaGraf, необходим для создания графических отчетов по данным, извлекаемым из таблиц БД или подготовленным любым другим образом.
Пакет деловой графики GALAGRAF обеспечивает следующие возможности:
1)создание семи типов диаграмм с эффектом трехмерности;
2)нескольких графиков на одной странице (экране) с размещением в координатах виртуального экрана;
3)многостраничные отчеты, вывод легенды;
4)сортировку данных перед построением;
5)вывод на график линий минимума, максимума и среднего значения;
6)использование шрифтов разных стилей, цветов и размеров;
7)печать графических отчетов на принтере, вывод графических отчетов в файл формата PCX
ит.д.
11
Интерактивный генератор отчетов ARD, предназначен для интерактивного формирования сложных отчетов по любым данным, извлекаемым из БД.
Перечисленные инструменты ППП «Галактика» позволяют выполнять
•доработку модулей стандартной конфигурации,
•добавлять новые формы отчетов, документов, экранные формы ввода данных, новые модули обработки информации баз данных.
Таким образом, параметрически-ориентированное проектирование ИС на основе использования ППП по сравнению с оригинальным проектированием дает возможность более быстрого и гибкого внедрения информационной системы.
Однако существует ряд проблем, сдерживающих распространение данной технологии. К ним можно отнести следующее:
•психологические и организационные трудности внедрения ППП;
•достаточно высокую стоимость приобретения ППП и обучения персонала;
•отсутствие глобальной модели объекта управления, что ведет к затратам по увязке различных ППП в рамках корпоративной ИС.
14.3Модельно-ориентированное проектирование ИС
Сущность модельно-ориентированного проектирования ИС сводится к адаптации компонентов типовой ИС в соответствии с моделью предметной области конкретной организационно-экономической системы. Для этого технология проектирования должна поддерживать как модель типовой ИС, так и модель конкретного предприятия, а также средства поддержания соответствия между ними.
Ядром типовой ИС является постоянно развиваемая модель предметной области (предприятия), поддерживаемая в специальной базе метаинформации - репозитории, на основе которого осуществляется конфигурация программного обеспечения. Таким образом, проектирование и адаптация ИС сводятся прежде всего к построению модели предметной области и ее периодической корректировке.
Для моделирования предметной области и последующих конфигураций информационной системы из отдельных компонентов (программных модулей) используется специальный программный инструментарий, например SAP Business Engineering Workbench (BEW) и BAAN Enterprise Modeler. Несомненным достоинством применения модельно-ориентированных компонентных систем, таких, как R/3 или BAAN IV, перед CASE-технологиями является накапливание опыта проектирования информационных систем для различных отраслей и типов производства в виде типовых моделей, которые поставляются вместе с программным продуктом в форме наполненного репозитория. Таким образом, вместе с программным продуктом пользователи приобретают базу знаний «know-how» об эффективных методах организации и управления бизнес-процессами, которые можно адаптировать в соответствии со спецификой конкретного экономического объекта.
Репозитории корпоративной ЭИС, использующей модельно-ориентированную технологию проектирования, в общем случае содержит метаинформацию базовой модели функциональности типовой системы (ссылочной модели в терминологии R/3), типовых моделей определенных классов ИС (референтных моделей в терминологии BAAN) и модели предприятий, получаемой на основе базовой или типовых моделей.
Базовая модель репозитория содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, организационной структуры, которые используются в программных модулях типовой ЭИС. При этом большое значение в базовой модели имеет задание бизнес-правил поддержания целостности информационной системы, определяющих условия проверки корректности совместного применения различных компонентов ЭИС. Таким образом, многообразие и гибкость определения бизнес-процессов и соответствующих конфигураций информационной системы задаются с помощью набора бизнес-правил.
12
Типовые (референтные) модели описывают конфигурации информационной системы для определенных отраслей (автомобильной, электронной, нефтегазовой и др.) или типов производства (единичного, серийного, массового, непрерывного и др.).
Модель предприятия (предметной области) строится либо путем привязки фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия, например как в инструментальном средстве BAAN Enterprise Modeler, либо в результате просмотра этих моделей и экспертного опроса, как в инструментальном средстве SAP Business Engineering Workbench. Причем в последнем случае пользователю предлагается определить значения не всех параметров, а только тех, которые связаны между собой в контексте диалога и описаны бизнес-правилами.
Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. Далее по модели предприятия автоматически осуществляется конфигурация информационной системы, в ходе которой выполняется семантический контроль по бизнес-правилам.
В обобщенном виде конфигурация корпоративных информационных систем на основе модельно-ориентированной технологии представлена на рис. 14.5.
Рис. 14.5. Конфигурация ИС на основе модельно-ориентированной технологии
Рассмотрим компоненты модели предприятия более детально.
Функциональная модель (модель функций)
Модель функций представляет собой иерархическую декомпозицию функциональной деятельности предприятия. На первом уровне иерархии обычно указываются основные виды функциональных подсистем: сбыт, производство, логистика, сервис, финансы, персонал и т.д. На следующем уровне иерархии для каждой функциональной подсистемы показываются функциональные модули, например, подсистема «Логистика» включает в себя функциональные
13
модули: планирование потребности в материалах, закупки, управление запасами, управление складами, проверка платежей и т.д. Для функциональных модулей задаются наборы бизнесфункций, для каждой из которых в дальнейшем определяются бизнес-процессы. Например, для функционального модуля «закупки» определяются бизнес-функции: оформление договоров, оформление заказов, выписка счетов и т.д.
В системе R/3 просмотр функциональности типовой ИС осуществляется с помощью программы-навигатора репозитория. Пример навигации на фрагменте модели функций показан на рис. 14.6. В процессе навигации по дереву можно перейти к документации, описывающей соответствующую функцию, и определению подфункций. Для функций последнего уровня по желанию специалиста-конфигуратора открывается просмотр схемы бизнес-процесса с используемыми входными - выходными данными и участвующими организационными единицами или схемы бизнес-объектов в виде ER-модели.
Рис.14.6. Фрагмент модели функций в системе R/3
В системе BAAN IV с помощью инструмента Enterprise Modeler можно построить четырехуровневое дерево декомпозиции функций (рис. 14.11). В отличие от R/3 бизнес-функции могут называться именами, характерными для конкретного предприятия. Кроме того, для функций могут быть заданы показатели оценки эффективности их выполнения, произвольное текстовое описание (например, инструкции для выполнения), а для функций последнего уровня указываются варианты реализации (оптимизации) по мере внедрения ИС (например, функция с интерактивным и автоматическим выполнением).
Модель бизнес-процессов
Модель бизнес-процесса отражает последовательность выполнения работ (операций) для функций самого нижнего уровня модели бизнес-функций, которая позволяет провести конфигурацию программных модулей информационной системы в соответствии с характерными особенностями конкретной предметной области.
Как в системе R/3, так и в системе BAAN IV для представления бизнес-процессов используется аппарат сетей Петри, позволяющий отображать управление процессами в зависимости от событий: работа выполняется в том случае, если на входе известно состояние системы.
14
В системе R/3 для отображения процессов используется модель управления событиями (ЕРС - event-driven process chain), реализованная в ARIS Toolset (рис. 14.12). В соответствии с этим методом переходы между операциями осуществляются в зависимости от событий, которые могут связываться логическими связками AND, OR, XOR. Кроме того, по требованию пользователей в модели процесса могут быть показаны входные-выходные данные, участвующие организационные единицы, указывается тип обработки (интерактивный, пакетный). Операции бизнес-процесса, как и процесс в целом, документируются.
Модель бизнес-процесса, построенная с помощью BAAN Enterprise Modeler (рис. 14.13), позволяет в качестве операций использовать не только программные модули BAAN IV, но и ручные процедуры, приложения, разработанные в другой программной среде. Конкретные операции могут иметь вложенные наборы операций, т.е. представляться в виде подпроцессов.
Рис. 14.11. Модель функций системы BAAN IV
15
Рис. 14.12 Модель управления событиями бизнес-процесса в системе R/3
Рис.14.13. Модель бизнес-процессов в среде ВААN Enterprise Modeler
Некоторые части бизнес-процесса могут не выполняться в зависимости от конкретных условий, связанных с состояниями (событиями) процесса, и затеняются на графическом
16
изображении процесса. С работами могут быть соотнесены должностные инструкции, документы и коды общих вспомогательных программ (утилит).
Модели объектов (данных)
Вмодельно-ориентированной технологии проектирования ИС интегрирование различных бизнес-процессов (приложений) осуществляется на основе бизнес-объектов. Согласно определению комитета Business Object Task Force OMG бизнес-объекты - компоненты уровня предметной области, которые используются в различных приложениях в произвольных комбинациях и не зависят от них. При этом «приложение обеспечивает среду для функционирования бизнес-объектов». OMG разрабатывает спецификации программных оболочек, которые предоставляют готовые объекты для следующих приложений: производства, электронной коммерции, транспортировки, телекоммуникаций, здравоохранения, финансов и др.
С одной стороны, бизнес-объекты - это объекты-сущности в нотации UML, например заказы, счета, материалы, поставщики и т.д. С другой стороны, в отличие от обычных объектовсущностей бизнес-объекты являются самодостаточными, т. е. имеют стандартный интерфейс, написанный на языке описания интерфейсов IDL (Interface Definition Language), с помощью которого бизнес-объекты могут взаимодействовать друг с другом через объектную шину - брокер объектных запросов (Object Request Broker). Таким образом, бизнес-объекты обладают более сложной внутренней структурой по сравнению с простыми объектами. Например, структура бизнес-объектов R/3 включает ограничения целостности в виде допустимых типов связей с другими объектами и бизнес-правила по связям с внешней средой, интерфейсы в виде входныхвыходных событий и спецификации доступа к объектам.
Всистеме R/3 разработано более 100 стандартных интерфейсов бизнес-объектов, называемых ВАРI (Business Application Programming Interface), которые позволяют осуществлять непосредственную связь между приложениями разных предприятий в среде ИНТЕРНЕТ. Например, при оформлении заказа от клиента поставщику могут использоваться следующие стандартные методы бизнес-объектов:
•ProductGroup.Select - выбор группы изделий в каталоге;
•ProductDescription - просмотр описания изделия, Product.Select - выбор изделия из группы;
•Order Create - создание заказа и т.д.
Всистеме R/3 модель бизнес-объектов описывается как статическая ЕR модель, в которой каждая сущность может рассматриваться как типичный объект данных, который используется на или выходе операций, так и как бизнес-объект с присоединенными методами.
Винструменте BAAN Enterprise Modeler мoдeль бизнec-oбъектов не отражается вследствие использования стандартной структуры базы данных, которую можно настраивать на особенности конкретного предприятия.
Модель организационной структуры
Модель организационной структуры предприятия представляет собой традиционную иерархическую структуру подчинения подразделений и персонала (организационных единиц). Назначение моделирования организационной структуры применительно к информационной системе заключается в распределении автоматизируемых функций по работникам подразделений
иопределении полномочий доступа к информационной системе.
Спомощью инструмента BEW в модели бизнес-процесса явно указывается закрепление автоматизированных функций по подразделениям (см. рис. 14.12).
Спомощью инструмента Enterprise Modeler связь модели бизнес-процесса и модели организационной структуры задается через указатели роли, которые могут выполняться различными организационными единицами (рис. 14.14). Через указатели роли сотрудников устанавливается связь организационной структуры с бизнес-процессами. Указатель роли определяет тип работника, который может выполнять ту или иную работу (экономист, бухгалтер, менеджер и т.д.). Для каждой роли определяются полномочия в выполнении функций, права
17
доступа к информации, должностные инструкции. При назначении работы конкретному работнику всегда осуществляется проверка роли, которую он может выполнять. Если при этом тип конкретного работника не соответствует роли, то последний не получает доступа к выполнению работы.
Рис. 14.14. Установление связи модели организационной структуры и модели бизнес-процесса
Модели бизнес-правил
Бизнес-правила - это специальные сведения в области типовой ЭИС, которые хранятся в репозитории и используются для контроля корректности построенной модели предприятия и процессов конфигурации и эксплуатации ЭИС. В системе R/3 бизнес-правила встроены в бизнесобъекты, в системе BAAN бизнес-правила выделены в самостоятельные компоненты. Рассмотрим применение бизнес-правил на примере системы BAAN.
Правила целостности модели предприятия
Правила целостности используются для проверки согласованности модели предприятия с точки зрения полноты и непротиворечивости бизнес-функций, например:
Если присутствует вариант бизнес-функции «Прямая поставка», тогда бизнес-функции «Обработка заказа на приобретение» и «Обработка заказа на сбыт» должны быть представлены в модели.
Правила преобразования моделей бизнес-функций в модели бизнес-процессов
Модель бизнес-функции может быть автоматически преобразована в модель бизнес-процесса посредством правил преобразования, которые задают соответствие бизнес-функции и бизнеспроцесса, например:
Если был определен вариант бизнес-функции «Обработка заказа на приобретение с контрактами», необходимо выбрать бизнес-процесс «Обработка контрактов».
Правила конфигурации (установки параметров)
Правила конфигурации используются для присвоения значения параметру BAAN в зависимости от его наличия в бизнес-функциях, бизнес-процессах или их комбинациях. Например:
Если был определен вариант бизнес-функции «Обработка заказа на покупку в режиме ЭОД (электронный обмен данными)», значение параметра «электронный обмен данными» настраивается на «да».
18
Правила установки статических условий
Правила установки статических условий осуществляют выбор варианта бизнес-процесса в зависимости от выполнения условия. Если значение условия правила ложно, то данный вари ант в процессе эксплуатации не выполняется и на диаграмме процесса соответствующая неактивная ветвь дерева изображается в затемненном виде, например: Если бизнес-функция «Оформление аккредитива» не используется в фазе внедрения, то запретить процесс оформления аккредитива.
14.4. Технология модельно-ориентированного проектирования ИС
Всилу сложности комплексной типовой информационной системы для модельноориентированного проектирования характерны следующие особенности.
Привязка типовой информационной системы к условиям конкретного экономического объекта осуществляется в результате совместных усилий фирмы-производителя программного продукта и проектной группы предприятия.
Консультанты со стороны фирмы-производителя программного продукта принимают участие на всех этапах внедрения системы и особенно на этапе анализа требований.
Возрастает роль руководства предприятия в организации и контроле за созданием информационной системы.
Визвестных методологиях модельно-ориентированного проектирования ИС Accelerated SAP и BAAN Orgware большое внимание уделяется регламентации последовательности операций на основе применения программных средств планирования, позволяющих ускорить процесс внедрения типовой ЭИС.
Технология модельно-ориентированного проектирования ИС включает четыре основные стадии: выбор типового проекта, разработку проектной модели предприятия, реализацию проекта, ввод в эксплуатацию и поддержку функционирования.
На всех стадиях используется инструментарий моделирования предприятия, применение которого рассматривается в функциональной модели проектирования ИС (рис. 14.15).
Операция 1 «Выбор типовой ИС - анализ требований»
Внедрение типовой информационной системы начинается с анализа требований конкретной организационно-экономической системы предприятия к ИС (см. рис. 14.15).
Рис. 14.15. Функциональная модель модельно-ориентированного проектирования ИС:
19
В частности, на основе результатов предпроектного обследования формируется предварительная модель предприятия, которая аккумулирует требования к функциональности информационной системы (множеству автоматизируемых функций) и на основе которой осуществляется выбор наиболее адекватного программного комплекса. Данная работа может быть выполнена в рамках проведения предварительного реинжиниринга бизнес-процессов. Возможен и другой вариант анализа требований, которые определяются существующей организацией бизнеспроцессов. Во втором случае реально существующая модель предприятия будет адаптироваться (эволюционировать) на этапе эксплуатации информационной системы с целью оптимизации функционирования организационно-экономической системы. По мнению специалистов, такой эволюционный инжиниринг обеспечивает более быстрое внедрение корпоративной ИС, сокращение капитальных затрат и повышение эффективности эксплуатации ИС.
Предприятие, внедряющее типовую информационную систему, стремится выбрать наилучший программный продукт, соответствующий конкретным условиям. Поэтому на этапе выбора типового проекта в конкурсе может участвовать несколько конкурирующих фирм, программные продукты которых (универсум типовых ИС) не только оцениваются по методике, изложенной в п. 14.2, но и с позиции реализации предлагаемой модели предприятия. В результате анализа требований выбирается конкретная типовая ЭИС, универсум компонентов которой используется на последующих стадиях внедрения проекта.
Рассмотрим выполнение стадии «Выбор типовой ИС» более детально. На рис. 14.16 представлена функциональная схема построения предварительной модели предприятия.
Сущность операций «Построение модели бизнес-функций» сводится к определению набора бизнес-функций, которые должны быть автоматизированы с позиции наибольшего влияния на достижение основных бизнес-целей (критериев эффективности функционирования предприятия) при условии соблюдения ресурсных ограничений. Данная операция выполняется на уровне руководителей предприятия при непосредственном участии консультантов фирм-производителей типовых информационных систем, которые демонстрируют руководству референтные модели из универсума. На выходе операции формируется список выбранных бизнес-функций, представленных в графической модели.
Рис. 14.16. Выбор типовой ИС
Далее к построению предварительной модели предприятия подключаются ключевые пользователи предприятия - руководители линейных и функциональных подразделений. Консультанты, интервьюируя ключевых пользователей, на основе сформированных бизнес-
20