А. З. Моделирование отношений между разными типами представлений (модель управления) 88

Вид материалаДокументы
А.3.7. Объединение всех представлений ARIS в полную модель
А.3.7.1. Моделирование определения требований
А.3.7.1.1. Модели процессов
А.3.7.1.2. Бизнес-объекты
А.3.7.2. Конфигурирование
А.3.7.2.2. Конфигурирование бизнес-объектов
А.3.7.3. Спецификация проекта
Подобный материал:
1   ...   8   9   10   11   12   13   14   15   16

А.3.7. Объединение всех представлений ARIS в полную модель


В ходе систематизированного описания двусторонних отношений в рамках концепции ARIS мы обсудили все ключевые вопросы моделирования, конфигурирования и реализации бизнес-процессов. В заключение мы объединим все представления ARIS в полную модель. Поскольку здесь хотелось бы заострить внимание на принципах объединения, мы не станем подробно вдаваться в вопросы реализации.

А.3.7.1. Моделирование определения требований


В качестве отправной точки для рассмотрения полных моделей может выступать, по сути, любое представление ARIS (на уровне функций, организации, данных, выхода или управления), вокруг которого группируются элементы других представлений. Здесь мы взяли за фокусные точки представление, ориентированное на процессы, и представление, ориентированное на объекты. Оба типа представления мы подробно рассмотрели выше.

А.3.7.1.1. Модели процессов


Диаграмма процесса (ДП) для стратегического планирования, приведенная на рис. 12а и 126, отображает бизнес-процессы в виде таблицы. Каждая строка диаграммы показывает, каким образом данная функция в рамках процесса активизируется событием, какие объекты данных какими атрибутами обрабатываются, какое организационное подразделение в этом участвует и какой выход, соответственно, реализуется или создается. Кроме того, можно указать, какое бизнес-приложение используется для поддержки функций.

На рис. 156 показана предварительная метамодель этого контекста с функцией в качестве отправной точки.



Рис. 156. Метамодель диаграммы цепочки процессов


Для описания интегрированных бизнес-процессов можно вместо таблиц использовать свободное моделирование, включив в каждое представление ARIS диаграмму СДП (событийная диаграмма процесса). Это соответствует общему описанию модели бизнес-процессов на базе ARIS (Scheer. ARIS — Business Process Frameworks. 1998, с. 31; русское издание с. 24), при этом метаструктура же соответствует диаграмме цепочки процессов (поскольку ситуация та же, за исключением способа ее представления). Поэтому одно описание можно вывести из другого.

А.3.7.1.2. Бизнес-объекты


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

Таким образом, бизнес-объекты описываются путем привязывания этих элементов (см. рис. 157). В соответствующий набор методов и функций входят методы, инициируемые извне посредством сообщений. В приложении SAP R/3 эти методы известны как BAPI (интерфейсы программирования бизнес-приложений). На рис. 158 изображена метамодель для бизнес-объектов.



Рис. 157. Модель бизнес-объекта




Рис. 158. Метамодель бизнес-объекта


Для того чтобы охватить внутреннее управление процессами, присвоенные бизнес-объекту данные, методы и экраны связываются с моделью процесса. Выход, требующийся или создаваемый для бизнес-объектов, представлен в модели выхода.

Приложения состоят из множества бизнес-объектов, управляемых бизнес-процессом, описанным специально для данного приложения (см. рис. 159).



Рис. 159. Бизнес-объекты, встроенные в приложение


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

А.3.7.2. Конфигурирование


Включив все представления ARIS, можно скомпилировать сконфигурированные приложения и уже скомпонованные модульные приложения.

А.3.7.2.1. Конфигурирование на базе моделей бизнес-процессов


На рис. 160 показаны конфигурации, возможные в рамках модели бизнес-процессов на базе ARIS. Инфраструктура ARTS Framework поддерживает возможности конфигурирования в реальных приложениях (IDS. ARIS-Framework. 1997).



Рис. 160. Конфигурирование бизнес-процессов


Часть (а) представляет фрагмент существующей цепочки процессов для приложения, связанного с закупками. При активизации определенным событием возможна реализация обоих вариантов выполнения функции «обновить данные о закупках/продажах». ARIS Framework внедряет эту модель процесса в прототип действующей системы.

Часть (б) показывает, как пользователи могут манипулировать системой, изменяя ее конфигурацию путем обновления модели. При добавлении функции «проверить стоимость товара», которая выбирается из дерева функций, эта функция дополняется соответствующими функциональными модулями системы.

Используя атрибут «стоимость товара», организационное подразделение по приемке товара проверяет эти данные, после чего полученная информация интерпретируется системой workflow.

Если стоимость товара превышает заданный критерий, функция «обновить данные о закупках/продажах» выполняется руководителем подразделения.

Эта функция объединяет в себе две другие функции: «обновление данных о закупках» и «обновление данных о продажах». Эта новая ветвь включается в модель и интерпретируется системой workflow и инфраструктурой ARIS Framework. К функции «обновить данные о закупках/продажах» привязывается новый модуль от дерева модулей.

Компиляция функций обусловливает и выделение нового экрана. ARIS Framework и система workflow ARIS реализуют эти обновления модели в прототипах действующих систем.

Приведенный пример иллюстрирует такие возможности конфигурирования, как:

• модификация процессов,

• добавление функций,

• интеграция функций,

• обновление структуры организационной отчетности,

• обновление экранов.

В нем наглядно представлены также функциональные возможности для адаптации систем, открывающие широкие перспективы для непрерывного совершенствования процессов.

А.3.7.2.2. Конфигурирование бизнес-объектов


Если в качестве отправной точки конфигурирования выбраны бизнес-объекты, мы можем обратиться непосредственно к рис. 157.

На рис. 161 показано, как изменять элементы бизнес-объекта для настройки стандартного бизнес-объекта в соответствии с требованиями конкретного пользователя.




Рис. 161. Возможности индивидуальной настройки бизнес-объекта

А.3.7.3. Спецификация проекта


Если в описании на уровне определения требований модель процессов и модель объектов были «на равных» (модели процессов даже отдавалось предпочтение), то в последующих описаниях будут доминировать представления объектов. Это облегчает такие задачи реализации, как многократная применимость программ и повышение сопровождаемости системы.

Для настройки системы в соответствии со спецификацией проекта бизнес-элементы (функции, организационные единицы, объекты данных, выходы и т.д.) переносятся на уровень элементного модуля, узла, отношения и выходного объекта.

Кроме того, к бизнес-объекту привязываются межплатформные интерфейсы, являющиеся «посредниками» между прикладными программами и аппаратными средствами.

Особенно важны коммуникационные интерфейсы, предоставляемые определенными бизнес-объектами для доступа к другим бизнес-объектам, например, CORBA (общая архитектура брокера запросов к объектам), COM/DCOM (компонентная объектная модель/распределенная компонентная объектная модель) и вызов удаленных методов (RMI) для Java (см. рис. 162).



Рис. 162. Интерфейсы для бизнес-объектов


Затем различные элементы можно скомпоновать в бизнес-объект в соответствии со спецификацией проекта.