Рис. 2. Структура книги, отражающая
концепцию ARIS
Таким образом, программное обеспечение на
уровнях II-IV можно охарактеризовать как оболочку. Для связи с конкретными
приложениями эту оболочку следует наполнить содержанием, представленным в
моделях бизнес-процессов на уровне I.
Например, информационную систему планирования
мощностей на уровне II, прежде чем ее можно будет использовать в качестве системы
управления для больничной операционной, необходимо сначала привязать к модели
процессов, выполняемых в больнице. Точно так же, прежде чем информационную
систему планирования мощностей можно будет применить к управлению логистикой,
ее необходимо привязать к модели процессов, связанных с парком грузовых
автомобилей. Таким образом, обобщенное понятие «ресурс», фигурирующее в системе
планирования мощностей, на уровне I модели бизнес-процессов наполняется
конкретным содержанием, в данном случае «хирург, прибор для искусственного
дыхания и койка» или «экспедитор, грузовик и склад».
Аналогично структуры процессов используются
для конфигурирования систем workflow на уровне III и прикладных систем на
уровне IV. Отсюда с очевидностью вытекает необходимость в соответствующих
интерфейсах для этих систем. Современные стандартные приложения типа SAP R/3
или BAAN IV имеют собственные инструменты конфигурирования и настройки, а
системы workflow — собственные языки конфигурирования, например FDL (язык
описания потоков) в системе IBM FlowMark.
Поскольку конфигурирование осуществляется на
уровне модели бизнеса, мы рассматриваем его как расширенный вариант описания на
уровне определения требований. О конфигурациях мы поговорим после того, как
рассмотрим определение требований.
Затем мы коснемся отображения моделей бизнеса
в объекты на уровнях спецификации проекта и описания реализации.
При реализации информационных систем на всех
четырех уровнях АБИ ARIS переход от определения требований к описанию
реализации обычно связан с
