Фёдор литовко
Один пример и три нотации: сравниваем
BPMN, EPC и DMN
Введение
Для бизнес-аналитика очень важно уметь моделировать бизнес-процессы (БП) и знать нужные для этого нотации. Наиболее распространенные нотации моделирования БП — BPMN и EPC. Существует большое статей и других материалов, посвященных нотациям и особенностям их использования. С теоретической точки зрения в этой статье не будет ничего нового. Основная цель  — показать, как можно решить одни и те же задачи с помощью нотаций BPMN и EPC и в чем особенность DMN.

В этой статье мы:

  • Расскажем о ценности внедрения методологии моделирования
  • На примерах покажем, для каких задач больше подходит BPMN, а для каких — EPC
  • Напомним про нотацию DMN, которая создана для описания моделей принятия решений
Статья будет полезна начинающим аналитикам процессов, техническим писателям, а также руководителям, переходящим от интуитивного описания процессов к их регламентации и формализации.
Время на чтение статьи: 15 минут
Не любите читать? Посмотрите видео.
Зачем нужна методология моделирования
Методология моделирования представляет собой внутренний стандарт описания БП. В такую методологию можно включить:

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

Методология моделирования особенно полезна, если в вашей компании все описывают бизнес-процессы по-разному. Это может приводить к недопониманию как внутри команд, так и между командами.
Наличие общего стандарта по описанию БП:

  • Позволит унифицировать процессы команды проекта или компании
  • Поможет начать внедрять процессный подход в проекте или компании
  • Сократит время обучения нотации для незнакомых с процессным подходом сотрудников

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

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

Ниже показан пример заполнения некоторых разделов методологии моделирования.

1. Общее описание
2. Описание процессов оперативного уровня
3. Пример описанного процесса

Приводится пример процесса оперативного уровня, смоделированного в соответствии с методологией (скриншот или ссылка).
Нотации EPC и BPMN
EPC
EPC — Event-driven Process Chain, Событийная цепочка процессов. EPC предназначена для описания порядка выполнения БП в виде последовательности действий, управляемых событиями и выполняемых исполнителями. Нотация разработана в 1990-х годах как часть методологии управления процессами и программного продукта ARIS.

Основные особенности

  1. Нотация создавалась как нотация для работы с системой SAP R/3
  2. Нотация ориентирована на описание высокоуровневых БП
  3. Главное преимущество нотации в том, что в ней мало элементов. Человек, не знакомый с нотацией, легко может понять EPC-диаграмму.
BPMN
BPMN — Business Process Model and Notation, Нотация Моделирования Бизнес-процессов. Первая версия нотации разработана в 2009 году, в 2011 году была выпущена её новая версия — BPMN 2.0.

Основные особенности

  1. Нотация разрабатывалась для применения совместно с BPMS-системами. В такой системе можно смоделировать БП и запустить его на исполнение.
  2. Нотация имеет большое количество элементов, связанных с автоматизацией процессов (триггеры, сообщения, потоки данных и так далее).
Пример
Исходные данные

Предположим, что мы участвуем в проекте внедрения информационной системы (ИС). Считаем, что:

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

Заказчик ставит перед нами следующие задачи:
  1. Реализовать в ИС процесс выбора поставщика.
  2. Описать процесс выбора поставщика в виде инструкций для пользователей.

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

Задачу реализации процесса в ИС при этом можно декомпозировать на две:

  1. Описать процесс в общем виде
  2. Поставить задачу по реализации процесса команде разработки

В реальных проектах бывает два кейса:
  1. Автоматизация в ИС существующих в компании процессов
  2. Оптимизация текущих процессов или создание новых процессов, сопутствующих реализации ИС
Процесс выбора поставщика

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

  1. Закупщик формирует требования к закупаемому оборудованию
  2. Закупщик организует и проводит тендер
  3. Закупщик выбирает лучшее предложение, представленное на тендере
  4. Закупщик заключает договор с выбранным поставщиком

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

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

Схема процесса выбора поставщика (BPMN)
Схемы в нотации BPMN ориентированы слева направо. Любая схема должна содержать начальное и конечное события.

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

В примере мы видим два пула:

  1. Закупщик — исполнитель процесса. В зоне ответственности Закупщика находятся в данном случае все события процесса. Если в процессе несколько исполнителей, каждый из них будет выражен отдельной дорожкой или пулом.
  2. Поставщик. Поставщик является внешним по отношению к процессу элементом, поэтому выражен в виде свернутого пула. Для нас поставщик — чёрный ящик: мы не знаем, какие процессы происходят у поставщика (на самом деле, нам и не нужно знать о них).
EPC
В нотации EPC схема процесса выбора поставщика может выглядеть так.

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

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

В EPC большое внимание уделяется различным видам документации, поэтому, если в вашем процессе важное место занимает документация, используются нормативно-правовые акты, нотация EPC может быть значительнее удобнее. При этом нотация требует, чтобы после любого действия следовало событие. Это увеличивает количество элементов схемы и делает её более громоздкой по сравнению с BPMN.
Постановка задачи на разработку

После того как процесс в общем виде описан, необходимо поставить задачи команде разработки для реализации процесса в ИС.

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

  1. Окончание тендера по таймеру (например, если тендер не проведён, то через 10 рабочих дней он завершается)
  2. Завершить процесс выбора поставщика, если при определении требований к оборудованию получено от руководителя получено уведомление об отмене поиска поставщика.
BPMN
Окончание тендера по таймеру

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

Окончание тендера по таймеру (BPMN)
Завершение процесса при получении уведомления
Другой удобный элемент в нотации BPMN — граничные события. Такие события прикрепляются к границе действия. Граничные события могут быть прерывающими и непрерывающими. Непрерывающие события запускают дополнительные ветки действий, а прерывающие завершают текущую ветку.

Так как нашим требованием является завершить процесс поиска поставщика при получении уведомления от руководителя, используем граничащее прерывающее событие типа «Сообщение». На схеме это будет выглядеть так:

Завершение процесса при получении уведомления (BPMN)
EPC
Окончание тендера по таймеру

В EPC события не классифицируются так, как в BPMN. Все события отображаются через один элемент нотации. Поэтому событие окончания тендера по таймеру может выглядеть в EPC так:

Окончание тендера по таймеру (EPC)
На схеме мы показываем, что от действия проведения тендера к действию выбора лучшего предложения можно перейти при наступлении одного из двух событий (обратите внимание, что на схеме используется логический оператор XOR — исключающее ИЛИ, то есть может произойти либо одного событие, либо другое, но не оба):

  1. Тендер проведен
  2. Прошло 10 рабочих дней с начала тендера

Завершение процесса при получении уведомления

Отобразить подобное событие в нотации EPC можно например так:

Завершение процесса при получении уведомления (EPC)
В BPMN мы мы использовали для моделирования такого процесса элемент типа «граничное событие», аналога которому в нотации EPC нет.
Вывод
BPMN содержит множество элементов для отображения триггеров процесса: таймеры, сообщения, различные виды событий, прерывающих или разветвляющих процесс. Разнообразие элементов позволяет более точно, чем в EPC, описывать алгоритмические действия, которые необходимо реализовать в ИС.
Написание инструкций

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

  1. Проведение повторного тендера с согласованием руководителя закупщика.
  2. Последовательное согласование договора перед оформлением с руководителем, владельцем бюджета и правовым управлением.
BPMN
Повторный тендер

Инструкция по проведению повторного тендера в нотации BPMN может быть изображена так:

Инструкция по проведению повторного тендера (BPMN)
Обратите внимание, что на этой схеме появляется вторая дорожка — Руководитель. Это позволяет наглядно показать распределение ответственности между участниками процесса.

Согласование договора

Инструкция по согласованию договора в нотации BPMN может выглядеть так:

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

В нотации EPC инструкцию по проведению повторного тендера можно показать так:

Инструкция по проведению повторного тендера (EPC)
Визуально такая схема получается больше, чем схема аналогичного процесса в нотации BPMN. Но нужно помнить, что перед нами стоит задача составить инструкцию. Скорее всего потребитель схемы-инструкции детально не знаком с особенностями нотаций и значениями многочисленных элементов BPMN. Поэтому инструкция в нотации EPC будет понятнее.

Согласование договора

Инструкцию по согласованию договора можно представить графически в нотации EPC следующим образом:

Инструкция по согласованию договора (EPC)
Такая инструкция получается более лаконичной, чем в нотации BPMN. Всех исполнителей можно связать с одним действием согласования договора.
Вывод
Для человека, не знакомого с нотациями моделирования, инструкция в нотации EPC выглядит более лаконичной и понятной, чем в нотации BPMN. EPC изначально создавалась для высокоуровневого описания БП, а BPMN — для описания автоматизируемых БП. Поэтому EPC содержит меньше элементов; их значение интуитивно понятно. BPMN содержит большее количество элементов, особенности применения которых нужно знать.
Нотация DMN
Нотация DMN (Decision Model and Notation, Нотация модели принятия решений) менее известна, чем BPMN или EPC. DMN предназначена для описания моделей принятия решений и используется, когда нужно описать обширные бизнес-правила, используемые в том или ином процессе.

DMN является частью нотации BPMN (разработана той же компанией, что разработала BPMN), расширяет и дополняет BPMN-диаграммы. Действие BPMN-диаграммы, в рамках которого принимается какое-либо бизнес-решение, можно заменить DMN-моделью.

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

DMN-модель, учитывающую все критерии выбора поставщика, можно представить в виде DRD-диаграммы так.

DRD-диаграмма бизнес-правил выбора поставщика
Элемент в виде прямоугольника называется Решение (Decision). Внутри каждого такого элемента заложены правила в виде таблицы принятия решений. Например, для решения «Оценка надёжности поставщика» правила могут быть такими.

Таблица принятия решений («Оценка надёжности поставщика»)
Подробнее о нотации DMN можно прочитать в этой статье.
Резюме
1. При выборе нотации моделирования нужно обращать внимание на специфику задачи и на то, как особенности нотации повлияют на её решение: будет ли модель полной и понятной. Хорошее решение — внедрить в компании или проекте единую методологию моделирования. Это позволит закрепить выбор нотаций для решения разного рода задач, способ хранения моделей и список инструментов моделирования.

2. В силу того, что нотация BPMN содержит больше элементов, она позволяет точно описывать автоматизируемые БП. Например, с помощью нотации можно легко показать:
  • События процесса, вызываемые по таймеру или с приходом сообщения — для этого в нотации есть специальные элементы.
  • Разделение ответственности между участниками процесса за счёт отображения участников в виде отдельных дорожек — это удобно при большом количестве участников с разными зонами ответственности.
3. EPC лучше подходит для описания верхнеуровневых БП и написания пользовательских инструкций, потому что содержит меньше элементов, значения которых нужно знать. Также с помощью EPC удобно:
  • Описывать процессы, в которых используется большое количество документации: в нотации принято для каждого действия указывать входящие и исходящие документы (в BPMN это используется меньше).
  • Описывать процессы, в которых большое количество участников выполняют одно и тоже действие — особенности нотации позволяют отобразить такой процесс лаконично.

4. Если в вашем процессе используются сложные бизнес-правила, их можно формализовать в виде модели принятия решения с помощью нотации DMN. Эта нотация может использоваться совместно с BPMN-диаграммами, расширяя и дополняя их.

воркшоп Анны Вичуговой


«BPMN для людей: основы самой популярной

нотации для описания бизнес-процессов»

13 апреля, суббота, 4 часа

Воркшоп для ИТ-специалистов, которые хотят научиться описывать логику выполнения бизнес-процессов с помощью формальной нотации — BPMN. Читателями таких диаграмм будут люди, а не сервисы.
Ваш промокод BPMN50 даст скидку 50%

Что будет:
  1. Виды BPMN-диаграмм и их практическое использование
  2. Алфавит нотации BPMN
  3. Выделяем границы процесса
  4. Определяем основные задачи процесса
  5. Добавляем роли, участвующие в процессе
  6. Определяем альтернативные варианты выполнения процесса
  7. Разбираем и добавляем дополнительные элементы нотации
  8. Разбираем сложные случаи
Автор
Фёдор Литовко
Ведущий бизнес-аналитик и проектный менеджер в проектах разработки и внедрения информационных систем
  • В бизнес-анализе с 2014 года
  • Преподаватель Школы Systems.Education
  • Нефтепереработка (логистика, закупки, инвестиции, бухгалтерский и налоговый учёт), образование, добывающая промышленность.