Как моделировать бизнес-процессы

В ходе своей работы и преподавания я сталкиваюсь с описанием бизнес-процессов организации в нотации eEPC (Extended event driven process chain), которая принята стандартом де-факто для описания процедур и регламентов после обследования деятельности организации. К сожалению, используя эту нотацию очень просто допустить ошибки моделирования, не зная правил, по которым она составляется. Эти ошибки приводят в последующем к несоответствию логики процесса, и как следствие – непониманию реальной ситуации в организации. Эта статья является некоторым обобщением моего опыта моделирования бизнес-процессов, и надеюсь, послужит некоторым читателям полезным руководством.

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

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

Меня часто спрашивают, как называть события и функции при моделировании. Для того чтобы ответить на этот вопрос, необходимо понимать, что такое событие. Событие – это некоторое состояние, которое является необходимым условием для начала и окончания выполнения функции. Основное правило моделирования — любой процесс должен начинаться и заканчиваться событием или интерфейсом в другой процесс, а любая функция – событием или логическим оператором. При определении событий важно помнить, что событие мгновенно во времени, то есть не может быть события типа «Ожидание согласования договора», его следует заменить двумя событиями «Договор согласован» и «Договор не согласован». Примеры наиболее типичных событий:

• наступление плановой даты, времени, например, «принято решение о начале проекта»
• получение или отправка сотрудником заявки, распоряжения, формы, информации, например «поступила заявка от клиента»

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

Большинство ошибок в модели делается из-за неправильного использования логических операторов и их сочетаний. Их всего три: и, или, исключающее или. Я приведу несколько примеров их использования на примере простых моделей.

Самыми распространенными ошибками являются использование оператора «ИЛИ» и «исключающего ИЛИ» после события, например:



Обе эти ситуации запрещены, так как событие не может принимать решения. В данном случае единственными вариантом является использование оператора «И»:



либо добавление двух дополнительных состояний:



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

Самой распространенной ошибкой является неправильное использование обратной связи, например, как тут:



В данном случае пропущен логический оператор, то есть нарушено правило о том, что функция может иметь только одну входящую связь. Также ошибкой будет, если в качестве логического оператора будет использован оператор «И». Единственно правильным решением в данном случае является использование логического оператора «исключающее ИЛИ»:



В заключении хочу отметить, что для успешного полного описания бизнес-процесса необходимо знать не только правила моделирования, но перед началом описания необходимо узнать:

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

Источник: здесь