A. ARIS - моделирование бизнес-процессов

В Архитектуре интегрированных информационных систем (ARIS) можно выделить четыре аспекта:

• концепцию ARIS («здание» ARIS), представляющую собой архитектуру для описания бизнес-процессов;

• концепцию ARIS, предлагающую методы моделирования, метаструктуры которых представлены в информационных моделях;

• концепцию ARIS как фундамент прикладной системы ARIS Toolset, разработанной фирмой IDS Scheer AG Для поддержки процесса моделирования;

• ARIS — «архитектуру» бизнес-инжиниринга (АБИ), представляющую концепцию комплексного автоматизированного управления бизнес-процессами,

Рис. 1а. Здание ARIS (Scheer. ARIS — Business Process Frameworks. 1998, рис. 17)

Концепция ARIS рассматривалась ранее в нашей книге ARIS - Business Process Frameworks[1], где мы показали, как можно упростить описание бизнес-процессов, введя различные уровни представления и фазы модели жизненного цикла. Эта концепция, известная как здание ARIS, проиллюстрирована на рис 1а.

Методы моделирования классифицируются с помощью различных моделей и уровней здания ARIS, которые являются главной темой этой книги. Их метаструктуры подробно описываются в рамках информационной модели ARIS.

В 1992 г. фирма IDS Prof. Scheer GmbH (Саарбрюккен, Германия) разработала на базе концепции ARIS пакет ARIS Toolset, предназначенный для создания и сопровождения моделей программного обеспечения. (На рис. 16 показан пользовательский интерфейс ARIS-Easy Design) Методология ARIS облегчает разработку, последовательно направляя действия пользователя.

Рис. 1б. Пользовательский интерфейс ARIS Easy Design

Пакет ARIS Toolset, завоевавший огромную популярность у широкого круга экспертов занимающихся сопоставлением различных методов моделирования является мировым лидером в области программных средств моделирования и анализа бизнес-процессов. Как это ни странно, но иногда упускают из виду два первых аспекта, упомянутые в начале данной книги (архитектура и информационная модель), a ARIS зачастую приравнивают к понятию «инструмент». Между тем мы всецело поддерживаем точку зрения Баха, Брехта и других специалистов (Bach,Brecht- Hess, Osterle. Enabling Systemaict Business Change. 1996, с. 28), которые, обсуждая последовательность этапов проектов, связанных с моделированием, утверждают, что выбору инструментов всегда должен предшествовать выбор методов («Прежде — методы!»). Собственно говоря, мы готовы пойти еще дальше и взять на себя смелость утверждать, что при оценке пригодности и полноты методов необходимо сначала рассмотреть архитектуру и лишь потом выбрать методы. Таким образом, тезис «Прежде — методы!» следовало бы уточнить и дополнить: «Прежде всего — архитектура!».

Концепция ARIS АБИ (см. рис. 1в) отражает систему обратных связей: от создания бизнес-процессов, через стадию планирования и управления, - к реализации с помощью систем автоматизации потоков работ (workflow) и функциональных компонентов. В частности, связывание уровней I и II позволяет проводить непрерывное совершенствование процессов. Более подробно концепция АБИ наряду с другими вопросами рассматривается в работе: Scheer. ARIS — Business Process Frameworks. 1998.

В первых разделах этой книги обсуждаются методы моделирования стратегических бизнес-процессов. Далее рассматриваются различные модели (типы представлений) ARIS. Описание каждой модели построено в соответствии с последовательными фазами жизненного цикла ARIS — от определения требований до описания реализации. Сначала мы подробно изложим методы моделирования на уровне описания требований, а затем покажем, как концепция НОВЕ используется на уровнях II-IV, выведенных при конфигурации системы, базирующейся на моделях, которые построены на уровне определения требований. Это показано стрелками на рис. 2.

Рис. 2. Структура книги, отражающая концепцию ARIS

Таким образом, программное обеспечение на уровнях II-IV можно охарактеризовать как оболочку. Для связи с конкретными приложениями эту оболочку следует наполнить содержанием, представленным в моделях бизнес-процессов на уровне I.

Например, информационную систему планирования мощностей на уровне II, прежде чем ее можно будет использовать в качестве системы управления для больничной операционной, необходимо сначала привязать к модели процессов, выполняемых в больнице. Точно так же, прежде чем информационную систему планирования мощностей можно будет применить к управлению логистикой, ее необходимо привязать к модели процессов, связанных с парком грузовых автомобилей. Таким образом, обобщенное понятие «ресурс», фигурирующее в системе планирования мощностей, на уровне I модели бизнес-процессов наполняется конкретным содержанием, в данном случае «хирург, прибор для искусственного дыхания и койка» или «экспедитор, грузовик и склад».

Аналогично структуры процессов используются для конфигурирования систем workflow на уровне III и прикладных систем на уровне IV. Отсюда с очевидностью вытекает необходимость в соответствующих интерфейсах для этих систем. Современные стандартные приложения типа SAP R/3 или BAAN IV имеют собственные инструменты конфигурирования и настройки, а системы workflow — собственные языки конфигурирования, например FDL (язык описания потоков) в системе IBM FlowMark.

Поскольку конфигурирование осуществляется на уровне модели бизнеса, мы рассматриваем его как расширенный вариант описания на уровне определения требований. О конфигурациях мы поговорим после того, как рассмотрим определение требований.

Затем мы коснемся отображения моделей бизнеса в объекты на уровнях спецификации проекта и описания реализации.

При реализации информационных систем на всех четырех уровнях АБИ ARIS переход от определения требований к описанию реализации обычно связан с программным обеспечением на каждом уровне. Эта процедура не зависит от типа реализуемых систем. На рис. 2 показан процесс реализации на уровне IV, представленный в виде следующих одна за другой фаз (определение требований, спецификация проекта и описание реализации). То же самое относится к программному обеспечению на других уровнях. Мы лишь кратко обсудим вопросы реализации в соответствии с нашим пониманием бизнес-информатики.

Для описания каждой метамодели используются диаграммы классов с обозначениями, принятыми в унифицированном языке моделирования (UML, см. UML Notation Guide, 1997). Этот тип представления аналогичен модели Чена сущность-отношение (ERM, см. Chen. Entity Relationship Model 1976), которая рассматривалась в предыдущих изданиях этой книги.

На рис. 3 объекты моделирования на языке UML, приведенные в настоящем издании, сравниваются с объектами ERM. Обозначения UML представлены в разделе А.3.2.1.1.1.

Рис. 3. Сравнение диаграмм ERM с диаграммами классов UML

Дата добавления: 2015-08-03