Моделирование бизнес-процессов (стр. 24 )

А.3.2.4. Описание реализации

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

Объектно-ориентированные языки программирования (C++, Smalltalk, Java и т. д.) позволяют реализовать методы и диаграммы спецификации проекта в программном коде (см. рис. 128, где описание класса «окружность», приведенное на рис. 125, реализовано на языке C++).

class cirle

{

int radius; point position;

public:

void radius (int newradius); void position (point newpoint); void display (); void hide ();

};

void cirle::radius (int newradius)

{

if (newradius > 0)// evaluation

{

};" };

Конкретная реализация одиночных операций здесь опущена.

Рис. 128. Реализация объектного класса, приведенного на рис. 125 (Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 37)

А.3.3. Отношения между функциями и выходом

Понятие «выход» охватывает материальный выход и услуги, в том числе информационные.

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

На рис. 129 показаны отношения между функциями и выходом в здании ARIS.

Рис. 129. Отношения между функциями и выходом

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

На рис. 130 показана детальная модель выходов, включая количественные взаимосвязи функции, а на рис. 131 — соответствующая метамодель. Для упрощения результаты в метамодели опущены. На этом рисунке мы исходим из предположения, что после выполнения каждой функции создается выход, имеющий свое собственное обозначение.

Рис.130. Поток выходов функции

Рис. 131. Метамодель изменения типов выходов после выполнения функций

На рис. 132 и 133 представлена ситуация, когда выход после обработки приобретает другое состояние, но не новое обозначение. Поэтому завершенный функциональный этап можно использовать для идентификации начального состояния для следующего процесса. Эта процедура применяется также для составления графиков операций в промышленном производстве.

Рис. 132. Поток выходов после выполнения функций без изменения обозначения выхода

Рис. 133. Метамодель обновления состояния после выполнения функции

Каждый результат бизнес-процесса моделируется путем привязки выходов к функциям. Выход последней функции бизнес-процесса является конечным выходом данного бизнес-процесса.

Привязка типов стоимости к выходу, как было показано при отдельном описании модели выходов, позволяет включить в модель и поток затрат в рамках процесса.

Поток выходов в рамках функционального процесса включает также структуру выхода, т. е. прейскурант материалов.

При описании потока управления жесткое разделение описания структур продуктов и процессов после создания продуктов приводит к отношениям подстановки (см. рис. 134). Связывание выходов с процессами позволяет описать процесс создания выхода из входа в той же мере, в какой выход моделируется в рамках структуры выхода.

На рис. 134а структура выхода характеризуется двумя промежуточными продуктами. Для создания выхода необходима одна функция на каждый продукт. В результате мы получаем четыре диаграммы ЕРС, каждая из которых описывает одну функцию, относящуюся к изготовлению соответствующего продукта.

Рис. 134а. Структура процесса и структура выхода с промежуточными продуктами

На рис. 134б та же структура выхода представлена в виде двух выходов, т. е. без описания промежуточных продуктов. Здесь соответствующий бизнес-процесс для создания конечного выхода более сложный; параллельная обработка вводится теперь не в прейскурант материалов, а в процесс.

Рис. 1346. Структура процесса и структура выхода без промежуточных продуктов

Отсюда понятно, почему графики работ в промышленном производстве, как први-ло включают лишь несколько (7-10) операций (функций). Это обусловлено тем, что наибольшая часть структуры процесса вводится в прейскурант материалов.

Однако в общем моделировании бизнес-процессов мы обычно имеем дело со всей структурой процесса. Лишь косвенно затрагивая промежуточные продукты, она включает также ряд функций и параллельных структур. Чем более обособлено администрирование выходов, процессов и соответствующих отношений, тем чаще возникают идентичные возможности. Это достигается тем, что структуры выходов моделируют структуру ключевых процессов, а процессы моделируют только непосредственные процессы входа/выхода для каждого выхода.

Метод UML описывает поток объектов, обрабатываемых функциями, посредством диаграмм операций или действий (см. рис. 135). Изменения состояний, вызванные функциями, можно интерпретировать как результаты, т. е. как информационные выходы. Метамодель (см. рис. 133) уже отражает этот поток объектов. В дополнение к этому, к операционным диаграммам привязаны организационные единицы.

Рис. 135. Поток действий и объектов (UML Notation Guide. 1997, рис.56)

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

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

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

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

А.3.4. Отношения между организационной структурой и данными

На рис. 136 показано, как соотносятся организационная структура и данные в «здании» ARIS.

Рис. 136. Отношения между организацией и данными

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

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

Рис. 137. Модель на уровне данных

Рис. 138. Метамодель, связывающая организацию и данные

При более пристальном рассмотрении полномочия пользователей на уровне атрибутов описываются такими операциями, как «создать», «удалить», «обновить» или «читать». Эти полномочия можно представить в виде таблиц. Соответствующая метамодель приведена на рис. 139. Пользователи, связываемые с определенной организационной единицей, описываются через должности.

Рис. 139. Метамодель присвоения полномочий

Мы должны определить, какие атрибуты разрешено обрабатывать каждому типу операции и каждому пользователю. Можно также задать дополнительные пределы для экземпляра значений атрибута. Например, если пользователю отдела управления персоналом разрешается читать сведения о заработной плате только ниже определенной суммы, это необходимо уточнить с помощью значений атрибутов ассоциации ПОЛНОМОЧИЯ. При привязке должностей можно также задать различные полномочия для нескольких типов операций. Например, сотрудник отдела управления персоналом может обновлять данные о заработной плате до определенной суммы, а читать их - до некоторой другой суммы.

Как и управляющие функции, организационные единицы могут активизироваться событиями. Эта процедура называется «управлением процессами, ориентированными на действия (операции)». По аналогии с триггерами функций передача элементов данных в виде побуждающих сообщений инициирует выполнение действий организационными единицами, как показано на рис. 140. Это особенно важно в управлении потоками работ, где побуждающие сообщения рассылаются в виде электронных папа и представляются при помощи диаграмм ЕРС в соответствии с организационным распределением функций. В упрощенном виде обмен сообщениями между организационными единицами описывается диаграммами взаимодействий (см. рис. 114).

Рис. 140. Управление организационными единицами посредством событий