BPMN 2.0: как нарисовать бизнес-процесс по нотации
BPMN — нотация моделирования бизнес-процессов: набор условных обозначений и правил, с помощью которых описывают действия, события и движение работы между участниками. Схема BPMN помогает согласовать, кто выполняет шаг, когда выбирается другой маршрут и чем заканчивается процесс.
Для первого обсуждения достаточно небольшого набора элементов. Не нужно размещать все символы стандарта на одной диаграмме: важнее, чтобы участники одинаково понимали маршрут работы. Ниже разберём нотацию BPMN 2.0 на учебном примере согласования договора, включая возвраты и повторную проверку.
Что такое BPMN 2.0 и чем она отличается от 1.x
Расшифровка BPMN — Business Process Model and Notation. В версии 2.0 стандарт охватывает не только графические обозначения, но и модель данных, формат обмена и семантику исполнения процессов. Поэтому BPMN-диаграмма может быть частью подготовки автоматизации, хотя нарисованная картинка сама по себе исполняемой моделью не становится. Нормативный источник — спецификация OMG BPMN 2.0.2.
Практический вопрос перед началом: вы хотите договориться о работе или настроить её выполнение в системе? Для разговора с командой нужна понятная схема и перечень нерешённых вопросов. Для автоматизации понадобятся технические настройки, поддерживаемые целевым движком элементы и проверка модели. Не смешивайте эти результаты в одном обещании.
Базовые элементы BPMN
| Элемент | Как выглядит | Что обозначает |
|---|---|---|
| Начальное событие | Круг с тонкой границей | Запуск процесса |
| Промежуточное событие | Круг с двойной границей | Событие в ходе процесса |
| Конечное событие | Круг с толстой границей | Завершение пути |
| Задача | Прямоугольник со скруглёнными углами | Действие |
| Шлюз | Ромб с маркером | Разветвление или объединение потоков |
| Поток управления | Сплошная линия с закрашенной стрелкой | Последовательность внутри процесса |
| Поток сообщений | Пунктир, кружок в начале, открытая стрелка в конце | Обмен между участниками в разных пулах |
| Пул | Контейнер участника | Граница участника взаимодействия |
| Дорожка | Раздел внутри пула | Группировка действий, например по ролям |
Поток управления может пересекать границы дорожек одного пула, но не границу пула. Поток сообщений не используют для передачи работы между дорожками внутри одного пула. Эти правила позволяют отличить внутреннюю последовательность действий от взаимодействия самостоятельных участников.
Для читаемости называйте задачу глаголом и объектом: «Проверить договор». Название роли «Юрист» лучше оставить дорожке. У события указывайте понятное состояние или повод, например «Нужен договор». Цвет может помогать ориентироваться, но не должен заменять форму, маркер и подпись. Такие приёмы рассматриваются и в рекомендациях Camunda по читаемости моделей.
Шлюзы BPMN: XOR, AND и OR
XOR: выбрать один путь
Исключающий шлюз обычно показывают ромбом с X. При разветвлении он выбирает один исходящий поток. В примере договора вопрос «Условия согласованы?» имеет два взаимоисключающих ответа: «Да» и «Нет». Если условия не приняты, документ возвращается на доработку, а юридическая проверка не начинается.
Условия относятся к исходящим потокам. Для понятной модели формулируйте их так, чтобы читатель мог однозначно выбрать путь. Поток по умолчанию предназначен для случая, когда другие условия не сработали; его нужно обозначать явно. При объединении XOR пропускает поступивший поток дальше и не синхронизирует параллельные ветви. Подробнее — документация по XOR.
AND: выполнить все ветви
Параллельный шлюз обозначают ромбом с плюсом. При разделении он активирует все исходящие ветви. Например, если регламент требует независимых проверок безопасности и финансов, обе проверки должны состояться. Условия выбора одной из них здесь не нужны: смысл AND именно в выполнении всех путей.
При объединении AND ждёт поступления потока по каждому входу. Поэтому нельзя бездумно поставить его после альтернативных маршрутов XOR: невыбранная ветвь не принесёт ожидаемый поток. Проверяйте не только развилку, но и точку встречи путей. Подробности — описание параллельного шлюза.
OR: выполнить подходящие ветви
Включающий шлюз обозначают ромбом с кружком. При разделении он выбирает все пути, чьи условия выполнены: один или несколько. Например, договор может требовать проверки персональных данных, валютных условий или обеих проверок. Это другая логика, чем «ровно одна» у XOR и «все без выбора» у AND.
В простом структурированном блоке объединяющий OR ждёт выбранные активные ветви, а не все нарисованные альтернативы. В сложных схемах с циклами семантика объединения требует особенно внимательной проверки. Для первой модели лучше обойтись понятными блоками и отдельно описать исключения. См. документацию по OR.
Как нарисовать BPMN-схему за шесть шагов
- Задайте границы. Запишите повод начала и результат. Не включайте соседний процесс только потому, что он идёт следующим.
- Назовите участников. Определите, какие роли работают внутри одного процесса и с какими внешними участниками происходит обмен.
- Соберите действия. Попросите исполнителей описать реальный случай. Пока не тратьте время на выравнивание фигур.
- Добавьте решения. Уточните условия переходов, возвраты и точки, где необходимо дождаться нескольких результатов.
- Пройдите исключения. Проверьте отказ, неполные данные, повторную проверку и ожидание ответа.
- Согласуйте версию. Зафиксируйте открытые вопросы, владельца процесса и дату следующего пересмотра.
На каждом шаге отделяйте текущее состояние от предлагаемого. Фраза «юрист должен отвечать за день» может быть пожеланием руководителя, а не действующим правилом. Если смешать факты и планы, участники подтвердят разные версии процесса. Разместите рядом две схемы или явно подпишите, какую именно модель обсуждаете.
Не пытайтесь сразу показать десятки исключений. Начните с основного маршрута и двух наиболее частых возвратов, а детали раскройте на следующем уровне. При этом не объявляйте упрощённую модель полной: рядом перечислите сценарии, которые пока остаются за её границами.
Пример BPMN: согласование договора
Возьмём процесс из статьи «Схема бизнес-процесса» и выразим его средствами BPMN. Границы те же: от потребности подготовить договор до согласованной версии, готовой к подписи. Само подписание, обмен с контрагентом и хранение документа здесь не моделируются.
В одном внутреннем процессе три роли: инициатор, руководитель и юрист. Инициатор готовит проект. Руководитель согласует условия. Если условия не подходят, инициатор дорабатывает документ и отправляет обновлённую версию на повторное согласование. Если подходят — начинается проверка формулировок юристом.
После юридической проверки второй XOR отвечает на вопрос «Есть замечания?». Ответ «Да» возвращает договор на доработку, ответ «Нет» ведёт к конечному событию «Готов к подписи». В этом учебном процессе после любой доработки снова проверяются и условия, и формулировки. Если ваш регламент другой, измените маршрут явно.
Рассмотреть фигуры и связи можно на доске с учебными примерами. Здесь нет параллельного запуска руководителя и юриста: такая замена была бы изменением процесса, а не косметическим выбором другого шлюза.
Пройдите три сценария. В первом замечаний нет: подготовка, согласование, проверка, готовность к подписи. Во втором руководитель возвращает условия: доработка, повторное согласование, затем юрист. В третьем замечания находит юрист: инициатор меняет версию, после чего договор снова проходит руководителя. На каждом шаге должно быть понятно, у кого находится работа.
Отдельно спросите команду, что происходит при окончательном отказе и кто следит за сроком ожидания. Эти сценарии пока не включены в учебную схему. Для вашего регламента их нельзя молча считать возвратом или успешным завершением: договоритесь о результате и добавьте соответствующий маршрут.
BPMN, блок-схема, UML, EPC и IDEF0: что выбрать
| Подход | Когда рассмотреть |
|---|---|
| Простая блок-схема | Нужно быстро объяснить последовательность действий небольшой команде |
| BPMN | Важны события, участники, условия маршрутов и синхронизация |
| UML | Нужно описывать программную систему; конкретная диаграмма зависит от вопроса |
| EPC | Компания уже использует событийные цепочки в своей архитектуре процессов |
| IDEF0 | Нужно рассмотреть функции через входы, выходы, управление и механизмы |
Это ориентир для обсуждения, а не рейтинг нотаций. Если команда уверенно работает с простыми диаграммами для бизнеса, переход к BPMN должен решать конкретную проблему: например, неоднозначность возвратов или ожидания нескольких проверок. Больше символов не означает лучшее описание.
Для взаимодействия программных компонентов полезно отдельно рассмотреть UML онлайн. Не пытайтесь одновременно показать на одной процессной диаграмме обязанности отдела, структуру классов и все сетевые запросы. Такие вопросы требуют разных уровней детализации и разных собеседников.
BPMN онлайн: доска или система исполнения
На онлайн-доске удобно собрать обсуждаемую модель, разместить рядом пояснения и пройти сценарии с участниками. В Эсборд можно открыть шаблон BPMN 2.0 и использовать фигуры и связи для совместной работы. Проверку правил нотации и корректности маршрутов нужно провести отдельно.
Если задача — автоматически назначать работу, обрабатывать события и отслеживать выполнение экземпляров процесса, нужен инструмент исполнения, например подходящая BPM-система. Совместимость модели и состав поддерживаемых элементов проверяют по документации выбранной платформы. Рисование на доске не обещает экспорт исполняемого BPMN XML или запуск процесса в Camunda либо ELMA.
После согласования схемы переходите к оптимизации бизнес-процессов: выбирайте изменение, назначайте владельца и измеряйте результат. Сохраните исходную модель. Иначе через месяц будет сложно отличить эффект нового правила от изменения нагрузки или состава команды.
Частые ошибки при построении BPMN
- Неясные начало и результат. Для учебной модели показывайте их явно. Отсутствие стартового или конечного события не во всех случаях является нарушением стандарта, но часто затрудняет чтение.
- Развилка без понятного правила. У читателя должна быть возможность выбрать маршрут по данным конкретного случая.
- Все роли смешаны. Одна дорожка сама по себе допустима; проблема возникает, когда скрывается нужная для обсуждения ответственность.
- Поток управления между пулами. Не путайте последовательность одного процесса с обменом сообщениями между участниками.
- AND после альтернативных ветвей. Проверьте, действительно ли все ожидаемые входы могут получить поток.
- Схема только успешного случая. Пройдите хотя бы один возврат и один отказ, иначе важные правила останутся устными.
Перед завершением встречи дайте схему человеку, который не участвовал в рисовании. Предложите ему провести договор с замечаниями до результата и объяснить каждый переход. Отмечайте места, где потребовалась устная подсказка: это кандидаты на уточнение подписи, условия или границы модели.
Вопросы и ответы
Что означает BPMN простыми словами?
Это общий язык схем бизнес-процессов: условные обозначения и правила, которые помогают показать действия, события, участников и маршруты работы.
Чем XOR отличается от AND и OR?
XOR выбирает один путь, AND запускает все ветви, OR выбирает одну или несколько по условиям. При объединении их поведение тоже различается.
Можно ли нарисовать BPMN на онлайн-доске?
Да, для обсуждения процесса можно использовать фигуры, связи и шаблон. Соответствие нотации нужно проверить отдельно; такая схема не равнозначна исполняемому BPMN XML.
Нужно ли начинать с полного стандарта?
Для первого обсуждения достаточно базовых элементов и ясного сценария. Перед автоматизацией изучите требования выбранного движка и проверьте модель.
