ТОП-10 ошибок в BPMN-диаграммах

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

Анна Вичугова, babok-school.ru

Пример процесса и перечень ошибок в BPMN-диаграммах

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

• Проверить наличие товаров во вновь пришедшем заказе;
• Если все товары в наличии, надо присвоить заказу статус «Ждет оплату», иначе – предложить покупателю неполную сборку заказа;
• Сформировать счет на оплату при наличии товаров или при согласии покупателя на неполную сборку заказа;
• Если счет оплачен, отправить заказ на сборку, а потом присвоить заказу статус «В сборке»;
• Если счет не оплачен в течении 7 дней после выставления, присвоить заказу статус «Отменен магазином»;
• При отказе от неполной сборки заказа присвоить заказу статус «Отменен покупателем».

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

Для рассмотренного бизнес-процесса у меня получилась следующая диаграмма.

Пример корректной BPMN-диаграммы

На этом примере рассмотрим популярные ошибки начинающих аналитиков, которые часто встречаются в BPMN-диаграммах:

• отсутствие стартового и/или финишного событий;
• не задано название пула для рассматриваемого бизнес-процесса;
• нарушены границы бизнес-процесса;
• название финишного события не коррелирует с названием бизнес-процесса;
• висячие вершины;
• некорректно названы события и задачи;
• нарушены правила использования триггеров в событиях;
• использованы неправильные шлюзы для логического соединения или разделения потоков управления;
• в одну задачу входит несколько стрелок потока управления без использования шлюза;
• есть открытые развернутые пулы, на которых нет ни одного события и действия;
• вместо использования маркеров задачи, например, Service Task, для системных действий используется дорожка Система.

Далее подробно разберем примеры каждой ошибки.

Отсутствие стартового и/или финишного событий

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

На практике это означает, что бизнес-процесс всегда запускается каким-либо триггером, например, пришла заявка от клиента, наступил 3-ий вторник второго квартала и т.д. Финишное событие означает факт фиксации результатов выполнения действий в бизнес-процессе. Количество стартовых и финишных событий в BPMN-диаграмме не ограничено, однако если их получилось слишком много, это может быть сигналом к пересмотру архитектуры процессов и/или способу их отображения.

Пример BPMN-диаграммы с отсутствующими стартовыми и финишными событиями

Отсутствует или не назван пул для рассматриваемого бизнес-процесса

Специализированные BPMN-редакторы, такие как Camunda и веб-движки (demo.bpmn.io, stormbpmn.com и пр.) предохраняют от этой ошибки, позволяя располагать события, задачи и шлюзы только в развернутом пуле. Однако, они не требуют от автора диаграммы обязательного именования каждого пула. А простые «рисовалки» типа Visio, Miro и пр. вообще не имеют даже элементарных правил проверки синтаксиса нотации. Поэтому я вообще не рекомендую ими пользоваться.

Пример BPMN-диаграммы с отсутствующим названием пула

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

Нарушение границ бизнес-процесса

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

Пример BPMN-диаграммы с нарушением границ процесса

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

Название финишного события не коррелирует с названием бизнес-процесса

Хотя эта ошибка фактически не нарушает правил использования элементов нотации BPMN, она затрудняет понимание представленной диаграммы. Логично, чтобы название финишного события, по крайней мере в «счастливом пути» (happy path), который приводит к нужному результату, было семантически связано с названием пула. Например, при рассмотрении бизнес-процесса обработки новой заявки на финише ожидается то, что заявка обработана, а не то, что склад проинформирован или запущена сборка заказа.

Пример BPMN-диаграммы с неверным именованием финишного процесса

Висячие вершины

Как уже было отмечено выше, BPMN-диаграмма – это направленный граф от стартового до финишного события. Она начинается стартовым событием и заканчивается финишным. Поэтому если после задачи поток управления не перешел на другую задачу, шлюз или финишное событие, возникает так называемая висячая вершина, на которой завис токен, чего быть никак не должно.

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

Пример BPMN-диаграммы с висячими вершинами

Некорректно названы события и задачи

Событие – это свершившийся факт, который уже случился, например, клиент позвонил, договор подписан, ТЗ согласовано, пришла весна, наступили выходные и т.д. Оно должно называться как глагол в прошедшем времени + семантическое дополнение. Также на BPMN-диаграмме не должны присутствовать неименованные события. Поскольку именно событие меняет ход процесса, надо точно знать, что же оно означает. А поскольку событие уже случилось, присоединять к нему входящие или выходящие объекты нельзя, в отличие от задач.

Задачи на BPMN-диаграмме означают действия, работу, которую кто-то или что-то должен выполнить. Поэтому задачи рекомендуется называть как глагол в инфинитиве + семантическое дополнение, например, разработать ТЗ, изменить статус заявки, отправить запрос и т.д.

Пример BPMN-диаграммы с некорректно названными задачами и событиями

Нарушены правила использования триггеров в событиях

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

Пример BPMN-диаграммы с некорректным использованием триггеров в событиях

Логические операторы (шлюзы или развилки в терминологии BPMN) нужны для отображения бизнес-логики выполнения процесса: условного деления в зависимости от результатов или произошедших событий, соединения и распараллеливания потоков управления. Неисключающее ИЛИ (OR), распараллеливание (AND) и исключающее ИЛИ по данным (XOR) могут как разделять, так и соединять потоки управления. Основным правилом работы с ними является рекомендация использовать тот же шлюз для соединения потоков, которым эти потоки были разделены. Например, если потоки были разделены XOR, это означает, что один результат исключает другие. Поэтому попытка соединения этих потоков шлюзом AND не даст ничего, поскольку он ожидает всех входящих потоков, чего быть не может. Исключающее ИЛИ (XOR) и неисключающее ИЛИ (OR), которые разветвляют потоки, предполагают результаты обработки данных, поэтому перед ними и после них должны идти задачи. А вот исключающее ИЛИ по событиям (XOR) означает движение потока по той ветке, событие на которой случится первым. Оно не работает как соединяющий шлюз, т.е. в него не может заходить несколько стрелок, а выходить одна.

Пример BPMN-диаграммы с некорректным использованием шлюзов

В одну задачу входит несколько стрелок потока управления

Поскольку стрелка потока управления показывает перемещение токена по задачам и событиям, количество стрелок, входящих в задачу, означает потенциальное количество ее запусков. Хотя это особенно важно для исполняемого моделирования BPMN-диаграмм, на описательном и аналитическом уровнях не стоит пренебрегать правилом, что в одну вершину графа должна все-таки приходить только одна стрелка потока управления и выходить тоже только одна. Для разветвления и слияния потоков следует использовать шлюзы, которые точно будут показывать логику исполнения процесса. Например, что задача «Присвоить заказу статус Ждет оплаты» исполняется 1 раз после события, фиксирующего факт согласия покупателя, а не ожидает обоих потоков, ранее разветвленных шлюзом XOR.

Пример диаграммы с отсутствием соединяющих шлюзов

Пустые развернутые пулы

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

Пример BPMN-диаграммы с пустыми развернутыми пулами

Дорожка Система

BPMN позволяет задать маркеры для задач, чтобы показать детали их выполнения. Например, пользовательская задача (User Task), выполняемая автоматизировано, т.е. с участием человека, или сервисная задача (Service Task), выполняемая автоматически, т.е. каким-либо сервисом. Поэтому не рекомендуется выделять дорожку Система и располагать на ней программные действия.

Пример BPMN-диаграммы с дорожкой Система

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

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