Нотация описания бизнес-процессов ARIS eEPC. Распространенные ошибки моделирования

При изучении бизнес-процессов предприятия как правило требуется зафиксировать в документальном виде описание бизнес-процесса. Как это сделать?

Описание процессов (иначе говоря, в узком смысле на проекте автоматизации  – сценариев работы пользователей) должно быть наглядным, при этом позволяя и увидеть процесс “в целом”, и в необходимых деталях, выявить причинно-следственные связи, действия пользователей, данные, которые передаются по бизнес-процессу.
Обычно бизнес-процессы имеют в документации текстовое описание. Например,

«При подвозе товара кладовщик должен сделать то-то, заполнить такие-то документы, потом их передать, оприходовать товар, позвонить в отдел снабжения и в цех, передать какую-то информацию, получить сведения для идентификации товара и тому подобное»

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

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

• eEPC: extended Event Driven Process Chain – расширенная нотация описания цепочки процесса, управляемого событиями.
• ARIS: Architecture of Integrated Information Systems.

Нотация ARIS разработана специалистами компании IDS Scheer AG (Германия), в частности профессором Августом-Вильгельмом Шеером.

Первоисточник – фундаментальный труд:  Шеер. “Бизнес-процессы. Основные понятия. Теории. Методы”.

Элементарным кирпичиком нотации ARIS является функция бизнес-процесса и все сопряженные с ней элементы:

В этой статье рассмотрим “урезанное” подмножество eEPC ARIS, которое наиболее часто применяется для документирования бизнес-процессов (потоков работ work flow) на проектах автоматизации.

В основе описания eEPC процесса – описание последовательности функций (действий), которые выполняют пользователи в системе. Каждой функции предшествует событие. Часто событие интерпретируют как некое “происшествие”, например, звонок клиента, получение письма и так далее. Но более точное определение – это состояние процесса, при котором должно выполниться действие. Событие – это необходимое и достаточное условие выполнения некоторого действия:

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

Например, “от начала выполнения техоперации прошло 10 мин” – это тоже событие.

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

Таким образом, базовая цепь описания процесса выглядит следующим образом:

Далее, у каждой функции надо указать исполнителя:

Получаем последовательность состояний системы (результатов) и соответствующих действий пользователей. Но для описания процесса этого недостаточно.

Нужно добавить данные, которые перемещаются между функциями:

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

В вышеприведенной схеме исходящими данными из функции “Действие 1” является “Заказ клиента”, а результатом выполнения функции (завершающим событием) может быть “Заказ обработан отделом продаж”…

Очень важно, что потоки документов (на схеме пунктирные синие стрелки) прописываются в схеме явно, и они отделены от причинно-следственных связей (потоков работ) “событие->функция->события->функция”. Именно этот подход позволяет целостно описать в одной схеме как причинно-следственные связи, так и документооборот.

Некоторые нотации (например, нотация, принятая в 1С СППР) рассматривают только потоки работ, а на связях указываются наименования документов и результатов. Такая упрощенная модель с использованием элементов ARIS выглядела бы так:

Заметим, что всей полноты картины такая модель не дает.

Одно из существенных ограничений схем eEPC ARIS – невозможность указать длительность процесса. Эта модель позволяет отобразить только логическую последовательность действий. Поэтому, по диаграмме eEPC  не получится выявить, что сотрудник должен одновременно выполнять несколько работ, либо не может выполнить весь предписанный ему объем работ за заданный интервал времени, например, за один рабочий день. Если необходимо указать длительность процесса, то как вариант можно использовать диаграмму Гантта.

Далее, использование логических операторов “И”, “ИЛИ”, “ИСКЛЮЧАЮЩЕ ИЛИ” позволяет указать ветвление потоков работ.

Оператор “И”

“И” – позволяет указать что после события запускаются сразу несколько функций:

либо указать, что событие (состояние) возникает только если выполнено несколько функций:

либо указать что только несколько событий (состояний) разрешают выполнение функции:

также, “И” позволяет указать что выполнение функции приводит одновременно к нескольким состоянием (событиям):

Оператор “ИЛИ”

“ИЛИ” – позволяет указать что возникновение одного из нескольких событий (состояний) – достаточно чтобы начать выполнение функции:

либо указать что любая из функций приводит к некоторому состоянию:

Оператор “Исключающее ИЛИ”

И наконец, “Исключающее или” отличается от просто “ИЛИ” тем, что возможен только один из альтернативных вариантов – либо Событие 1 либо Событие 2, но не оба одновременно. Это взаимоисключающие альтернативы: два взаимоисключающих события приводят к выполнению одной функции

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

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

Типичные ошибки

Казалось бы, все достаточно просто, из таких “кирпичиков” можно составить схему любого сложного процесса из десятков и сотен функций. Однако, на практике легко допустить ошибки, если не разобраться в правилах использования модели eEPC ARIS.

Перечислим наиболее распространенные ошибки моделирования в нотации eEPC ARIS.

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

• Два (или больше) входа в одну функцию. Например, при кольцевом выполнении функций:

Правильно: