BPMN
BPMN (Business Process Model and Notation) — стандарт визуального описания бизнес-процессов. Основные элементы: события (кружки), действия (прямоугольники), шлюзы (ромбы: XOR, AND, OR), потоки (стрелки), пулы и дорожки (разграничение участников и ролей). Пример, типичные ошибки, инструменты и ценность BPMN для системного аналитика.
Для корректного понимания диаграмм бизнес-процессов сначала рассмотрим, что такое бизнес-процесс.
Бизнес-процессы
Бизнес-процесс – это понятная и повторяемая цепочка шагов, которая выполняется внутри компании, чтобы получить конкретный результат, полезный для бизнеса.
Проще говоря: это “как у нас принято делать дело от начала до конца”, чтобы цель была достигнута стабильно и предсказуемо.
Бизнес-процесс всегда отвечает на три вопроса:
Зачем это делаем (цель/результат).
Кто участвует (роли и ответственные).
Как именно происходит работа (шаги, правила, входы/выходы).
Обычно в бизнес-процессе есть:
старт (что запускает процесс: заявка, событие, задача)
последовательность действий (что делаем и в каком порядке)
участники (клиент, менеджер, бухгалтерия, склад, система)
данные и документы (что используем и что создаем по ходу)
правила и ограничения (например: сроки, лимиты, обязательные проверки)
финиш (что считается завершением и какой результат получен)
Бизнес-процессы бывают простые (несколько шагов, одна команда) и сквозные (затрагивают несколько отделов и систем). Чем процесс сложнее, тем важнее его моделировать, чтобы не терять детали и не допускать разночтений.
Примеры бизнес-процессов:
Клиент оставляет заявку на сайте → менеджер уточняет детали → формируется коммерческое предложение → клиент подтверждает → выставляется счет.
Магазин получает поставку → кладовщик принимает товар → товар оприходуется в системе → появляется на витрине → становится доступен для продажи.
Сотрудник готовит договор → юрист проверяет формулировки → руководитель утверждает → договор отправляется клиенту → подписанный экземпляр сохраняется в архив.
Зачем рисовать процессы
Представьте, что вам нужно объяснить иностранцу, как сварить пельмени. Можно рассказать словами: “Возьми кастрюлю, налей воду, поставь на огонь, когда закипит, брось пельмени, вари 7 минут…” Это длинно и запутанно.
А можно нарисовать схему: прямоугольник “Взять кастрюлю”, стрелка к следующему прямоугольнику “Набрать воду”, ромб “Вода закипела?” и так далее. Схема нагляднее, в ней сразу видно логику и варианты развития событий.
В бизнесе и IT то же самое. Текстом можно описать любой процесс, но когда доходит до сложных логик, множества участников и исключений – текст становится нечитаемым. Тут на помощь приходит моделирование.
BPMN (Business Process Model and Notation) – это международный стандарт для описания бизнес-процессов. Это язык, на котором можно рисовать схемы, понятные и бизнесу, и разработчикам.
Что такое BPMN
BPMN – это язык, у которого есть строгие правила. Вы не можете просто рисовать квадратики и стрелочки как попало. У каждого элемента есть свое значение.
Зачем это нужно:
- Чтобы все понимали схему одинаково (и бизнес-аналитик, и программист, и заказчик).
- Чтобы можно было передать схему в разработку, и программист точно понял логику.
- Чтобы потом можно было автоматизировать процесс.
BPMN придумали, чтобы устранить разрыв между тем, как бизнес видит свою работу, и тем, как это реализовано в IT-системах.
Основные элементы BPMN
Для начала хватит 5-6 элементов. Всё остальное – надстройки.
События (Events)
Событие – это то, что происходит в процессе. Событиями отмечают старт, финиш или важные точки внутри процесса (“Начало по таймеру”, “Получен отказ”, “Успешное завершение”). Обозначаются кружочками.
Событие представляет собой нечто, происходящее в ходе бизнес-процесса и влияющее на его течение. Так, указание типа триггера (условия или ограничения) на событие устанавливает определенные ограничения на процесс потока. Также события могут приводить бизнес-процесс к некоторому результату.

Начальное и конечное события представляют собой точки начала и окончания процесса и должны обязательно присутствовать на диаграмме. Промежуточное событие представляет собой результат выполнения одного или нескольких действий процесса, но не может являться началом или завершением процесса.
| Название | Что означает |
|---|---|
| Начальное (стартовое) событие | Начало процесса. Тонкая окружность. |
| Промежуточное событие | Что-то происходит в процессе (например, пришло уведомление). Двойная окружность. |
| Конечное событие | Завершение процесса. Жирная окружность. |
Примеры: “Поступил заказ” (начальное), “Получена оплата” (промежуточное), “Заказ доставлен” (конечное).
2.2. Действия (Activities)
Действие – это работа, которую кто-то выполняет. Прямоугольники со скругленными углами.

| Название | Что означает |
|---|---|
| Задача (Task) | Одно атомарное действие. Задача без определенного типа называется абстрактной. Абстрактные задачи используют, когда тип задачи очевиден из контекста и его можно не указывать. “Проверить наличие товара”, “Отправить письмо”. |
| Подпроцесс (Sub-process) | Целый процесс внутри процесса. Можно раскрыть и увидеть детали. Диаграмма не отображает детали подпроцесса. Знак “плюс” находится в центре нижней части фигуры, символизирующей подпроцесс, и указывает на то, что данное действие является подпроцессом. В данном случае детали процесса находятся на нижнем уровне. |
2.3. Шлюзы (Gateways)
Шлюзы – это развилки, где процесс разделяется или соединяется. Ромбы.
Эксклюзивный шлюз:

Параллельный шлюз:

Неэксклюзивный шлюз:

| Название | Что означает |
|---|---|
| Эксклюзивный шлюз (XOR. “ИЛИ/ИЛИ”) | Выбирается только ОДИН путь из нескольких. Условия проверяются, и выполняется тот, где условие истинно. Используется для ветвления потока управления на несколько альтернативных маршрутов, из которых может быть выбран только один. Таким образом, часть действий в процессе может быть выполнена только при определенном условии. Шлюз позволяет задать это условие. |
| Параллельный шлюз (AND. “И”) | Разделяет поток на несколько ветвей, которые выполняются одновременно. При слиянии ждет завершения ВСЕХ ветвей. Используется для создания параллельных путей без оценки какого бы то ни было условия или для сходящихся потоков и синхронизации параллельных веток выполнения процесса. |
| Неэксклюзивный шлюз (OR. “И/ИЛИ”) | Может активировать ОДНУ ИЛИ НЕСКОЛЬКО ветвей одновременно. Все ветви, чьи условия истинны, будут выполнены. Применяется для разделения потока управления на один или несколько альтернативных маршрутов, либо для объединения их в один маршрут. |
2.4. Потоки (Flows)
Стрелки, которые соединяют элементы.
Поток управления:

Поток сообщений:

| Название | Что означает |
|---|---|
| Поток управления | Последовательность действий. Стрелка от одного элемента к другому. Используется для передачи работы между элементами процесса. Потоки управления можно использовать только внутри пула или дорожки – они не могут пересекать границы пула. |
| Поток сообщений | Обмен информацией между разными процессами или участниками. Пунктирная стрелка. Используется для соединения сообщений и\или пулов, отображает отправку сообщений. Поток сообщений не может начинаться и заканчиваться внутри одного и того же пула. |
2.5. Дорожки и пулы (Pools и Lanes)
Это способ показать, кто за что отвечает.
Пул:

Свернутый пул:

Дорожка:

| Название | Что означает |
|---|---|
| Пул/Бассейн (Pool) | Один участник процесса. Например, “Интернет-магазин” или “Клиент”. Есть 2 вида пулов на диаграмме: 1. Раскрытый пул используется для показа бизнес-процесса и обозначения его границ. 2. Свернутый пул используется для клиентов, систем и других участников взаимодействия, чье поведение мы не знаем. |
| Дорожка (Lane) | Роль внутри участника. Например, внутри магазина: “Менеджер”, “Кладовщик”, “Курьер”. Используется для отображения участника процесса. Как правило дорожки располагаются внутри пула и используются для распределения операций процесса между его участниками. |
Пример процесса в BPMN

Зачем BPMN системному аналитику
Чтобы понимать бизнес
Прежде чем автоматизировать процесс, нужно понять, как он работает сейчас. BPMN дает четкую картину “как есть” (as-is).
Чтобы предлагать улучшения
Посмотрев на текущий процесс, вы можете увидеть узкие места, лишние шаги, задержки. Можно предложить “как будет” (to-be).
Чтобы передать разработчикам
Разработчикам не нужно читать 10 страниц текста. Им достаточно посмотреть на BPMN-схему, чтобы понять логику.
Чтобы согласовать с заказчиком
Бизнес-люди тоже понимают схемы (если они не перегружены). BPMN достаточно наглядный, чтобы показать заказчику и спросить: “Так?”.
Типичные ошибки при проектировании BPMN
Рисовать “как в голову придет”
Использовать произвольные фигуры, не соблюдать нотацию. Тогда схема теряет смысл – ее нельзя прочитать по правилам.
Перегружать схему
Пытаться втиснуть в одну схему все на свете. Если процесс сложный – разбейте на подпроцессы или несколько уровней.
Забывать про начало и конец
У каждого процесса должно быть стартовое событие и конечное. Иначе непонятно, где вход и где выход.
Неправильно использовать шлюзы
Путать XOR и AND. Или ставить шлюз там, где достаточно простого ветвления.
Рисовать без дорожек
Когда на одной схеме смешаны действия разных участников без разделения, быстро становится непонятно, кто за что отвечает.
Инструменты для BPMN
| Инструмент | Описание |
|---|---|
| Draw.io | Бесплатный, простой, есть все базовые элементы BPMN. |
| BPMN.io | Онлайн-редактор, заточенный именно под BPMN. Легкий и удобный. |
| Camunda Modeler | Профессиональный инструмент для BPMN. Поддерживает все уровни, можно экспортировать в исполняемый формат. |
| Stormbpmn | Российский инструмент, удобный для командной работы. |
| Visio | Классика, но дорого и не всегда удобно для совместной работы. |
Резюме для системного аналитика
BPMN – это язык описания процессов. Как и любой язык, его нужно учить и соблюдать правила.
Главное – наглядность и однозначность. Схему должны одинаково понимать и бизнес, и IT.
Начинайте с малого. Не пытайтесь использовать все элементы сразу. Освойте базу: события, действия, шлюзы, дорожки.
Всегда указывайте начало и конец. Процесс без конца – это бесконечный процесс.
Используйте дорожки. Они сразу показывают, кто за что отвечает и где возможны проблемы на стыках.
Рисуйте итеративно. Сначала крупные блоки, потом детали, потом исключения. Не пытайтесь нарисовать идеальную схему с первого раза.