BPMN 2.0: от нотации к исполняемым процессам

Business Process Model and Notation в версии 2.0 — это не просто очередная нотация в длинном ряду методологий описания бизнес-процессов. Это попытка создать универсальный язык, на котором могли бы разговаривать друг с другом бизнес-аналитики, методологи, разработчики и менеджеры — и при этом этот язык должен быть напрямую исполняем компьютером.

Удалось ли это? И да, и нет. В этой статье мы разберём, что именно представляет собой BPMN 2.0, как его правильно использовать, и какие ошибки чаще всего совершают команды при его внедрении.

Краткая история

BPMN 1.0 был опубликован в 2004 году Business Process Management Initiative (BPMI) — отраслевым консорциумом, в который входили крупнейшие игроки рынка BPM-инструментов. В 2005 году BPMI слилась с Object Management Group, и дальнейшая разработка стандарта пошла под её эгидой.

BPMN 2.0, опубликованный в январе 2011 года, стал водоразделом. Если BPMN 1.x был преимущественно графической нотацией с туманными правилами интерпретации, то BPMN 2.0 ввёл строгую исполняемую семантику, формальный метамодель и XML-сериализацию. В том же году BPMN 2.0 получил статус международного стандарта ISO/IEC 19510.

Три уровня BPMN

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

Дескриптивный уровень

На этом уровне используется минимальный набор элементов: задачи, шлюзы XOR и AND, события начала и конца, последовательные потоки. Модель воспринимается как «продвинутая блок-схема» — она наглядна и понятна без подготовки. Дескриптивный BPMN — это инструмент для коммуникации с бизнесом, для документирования процесса в общих чертах.

Аналитический уровень

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

Исполняемый уровень

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

Главная ошибка — смешение уровней

Самая распространённая ошибка при внедрении BPMN — попытка использовать одну и ту же модель на разных уровнях. Бизнес-аналитик рисует «красивую» дескриптивную модель и передаёт её разработчику с фразой «теперь автоматизируй». Разработчик добавляет необходимые технические детали — и в результате модель перестаёт быть понятной бизнесу.

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

Семантика токенов

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

Процесс завершается, когда все токены достигают конечных событий или поглощаются. Если хотя бы один токен «застрял» — процесс висит в состоянии незавершённого исполнения. Это типичная проблема плохо спроектированных моделей с параллельными ветками, которые не сходятся корректно.

Что выбрать вместо или вместе

BPMN — мощный, но не универсальный инструмент. Для адаптивных слабоструктурированных процессов лучше подходит CMMN, для бизнес-правил — DMN, для верхнего уровня процессной архитектуры — VAC или VAD. Для производственных потоков с акцентом на потери — VSM.

Современная практика — использовать комбинацию стандартов. OMG специально разрабатывала «триаду» BPMN + CMMN + DMN как единую экосистему. BPMN-процесс может вызывать CMMN-кейсы и опираться на DMN-решения, и всё это исполнимо в современных движках типа Camunda 8.

Заключение

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

Главное при освоении BPMN — помнить, что нотация не существует ради себя. Хорошая BPMN-модель — это не та, в которой использованы все возможные элементы, а та, которая решает поставленную задачу с минимальной сложностью.