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

Предлагаемое решение позволяет придать каждой общей функции специальные свойства в контексте конкретного процесса. С другой стороны, если функции описаны настолько четко, что ими можно оперировать в контексте любого приложения, и к тому же состоят из одинаковых подфункций, то их можно описать как общие конструктивные блоки. На рис. 226 такими функциональными объектами могут быть «проверка готовности» и «создание резервов», поэтому они заключены в рамку вместе со своими подфункциями. Применительно к диаграмме классов на рис. 21 это означает, что ассоциативный класс СТРУКТУРА ОБЩЕЙ ФУНКЦИИ представляет собой описание в виде конструктивных блоков, а мощность отношения между ОБЩЕЙ ФУНКЦИЕЙ и БИЗНЕС-ПРОЦЕССОМ равна (1..*):(0..*). Это позволяет привязывать к процессам не каждую общую функцию, а только главные конструктивные блоки, одновременно являющиеся функциональными объектами.

В метаструктурах понятие ФУНКЦИОНАЛЬНЫЙ ОБЪЕКТ представляют в виде конкретной версии класса ОБЩАЯ ФУНКЦИЯ (см. рис. 24). Затем из функциональных объектов можно компоновать сложные функциональные структуры. Позже мы раздвинем рамки этого сценария, связав функции с другими моделями ARIS для формирования бизнес-объектов.

Рис. 23. Присвоение ролевых имен

Рис. 24. Функциональный объект метамодели

Помимо классификаций, ориентированных на операции, ассоциативный класс СТРУКТУРА ОБЩЕЙ ФУНКЦИИ позволяет также моделировать классификации, ориентированные на процессы или объекты.

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

Эти операции выполняются в контексте поставленной задачи. Они не классифицируют функцию, а являются ее составляющими. Соответствующая документация представляет собой своего рода перечень этапов, необходимых для выполнения функции. Его можно моделировать в виде текста, структурограмм или таблиц решений (Nuttgens. Koordiniert-dezentrales Informationsmanagement. 1995, с. 95).

В метаклассах СПИСКИ ОПЕРАЦИЙ представляются как отдельный класс, связанный с общей функцией.

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

А.2.1.1.2. Последовательности процедур

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

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

На рис. 25 часть древовидного индекса, приведенного на рис. 19а, представлена в виде процедуры. Это подтверждает, что изначально описать контекст процедуры на основании древовидного индекса нельзя. После соответствующих расчетов, для которых необходимо знать «приближенные показатели» (например, ставки заработной платы) и стоимость заказываемого оборудования, описывается узел решений с тремя альтернативными исходящими ветвями: составление нового технического предложения, если вычисленная цена нереальна; отказ от выполнения, если есть основания полагать, что предложение не будет принято; выполнение заказа, поскольку клиент принял предложение. Вероятность каждой альтернативы можно привязать в качестве атрибута. Поскольку эти альтернативы взаимоисключающие, их максимальная мощность должна равняться 1.

Рис. 25. Процедурная последовательность функций

Эта концепция из GERT (графический метод оценки и анализа; см. Elmaghraby. Activity Networks. 1977; Scheer. Projektsteuerung. 1978).

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

Упорядоченные отношения образуют в рамках класса ФУНКЦИЯ новую ассоциацию - ПОЗИЦИОНИРОВАНИЕ. Каждое ^ношение позиционирования можно идентифицировать по предыдущему и последующему этапу функции. Добавление на рис. 26 ассоциативного класса ПОЗИЦИОНИРОВАНИЕ позволяет присваивать в качестве атрибутов метрики расстояния для наложений, задержки или коэффициенты (их значения помещаются на соответствующие ветви).

Рис. 26. Учет позиционных отношений

Логические зависимости между ребрами соответствующего графа присваивают-я отношениям позиционирования в качестве атрибутов.

Для функций, преобразующих материалы, процедурные последовательности

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

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

График работ для изделий из листового металла
Номер операции	Название операции	Продолжительность (средняя)	Группа производственных ресурсов
1	Сверление	1	ГПР 1
2	Фрезерование	2	ГПР5
3	Снятие заусенцев	3	ГПР 4
4	Промывка	4	ГПР 7

Рис. 27а. График работ на уровне типов деталей

Операции соответствуют техническим процедурам. Технические процедуры можно описывать независимо от контекста графика работ, а затем уточнять их в контексте этого графика или процесса на более позднем этапе. Диаграммы классов соответствуют рис. 276. С технической точки зрения, эта диаграмма идентична метаструктуре функции, показанной на рис. 21 (БИЗНЕС-ПРОЦЕСС, ОБЩАЯ ФУНКЦИЯ, ФУНКЦИЯ). Таким образом, последовательности технических функций можно рассматривать так же, как последовательности административных функций.

Документирование графиков работ – одна из классических задач планирования и управления производством в информационных системах. Графики работ анализируются на уровне деталей с привлечением экземпляров классов деталей и заполнением соответствующих баз данных.

Рис. 27б. Диаграмма классов для графиков работ

Диаграмма классов для администрирования графиков работ, относящихся к изготовлению деталей, представлена на рис. 27б (Scheer. Business Process Engineering. 1994, с. 216). Контекст процесса становится ясен из описания отношения между деталями, которое теперь становится подэкземпляром.

Обычно в моделировании бизнес-процессов не принято использовать функции, связанные с деталями. Если это и делается, то лишь применительно к особо важным конечным продуктам.

Графики работ на уровне типов и экземпляров, которые мы рассматривали до сих пор, аналогичны эталонным данным; том смысле, что они не зависят от контекста заказов, привязанных к фактору времени, хотя экземпляры, управляемые системами workflow, привязаны к заказам. Здесь эталонные графики работ, оперирующие типами и экземплярами, являются своего рода шаблонами. В системах ПиУП эталонные графики работ, соответственно оперирующие данными и заказами, также рассматриваются параллельно.

А.2.1.1.3. Типы обработки

Для того чтобы описать способ реализации функции (средствами ИТ или вручную), при спецификации понятия ФУНКЦИЯ можно разграничить СИСТЕМНУЮ ФУНКЦИЮ и РУЧНУЮ ФУНКЦИЮ (см. рис. 28).

Рис. 28. Спецификация понятия «функция»

Системные функции порождают заказы клиентов, сопровождают данные о клиентах, ведут статистику и т. п. при помощи информационных систем. Если ПРИКЛАДНАЯ СИСТЕМА уже известна, то эта информация также приобщается к системной функции. Однако такие сведения должны носить лишь общий характер (например, имя бизнес-приложения), чтобы заранее не предопределять описание на уровне спецификации проекта.