BPMN и описание бизнес-процессов

BPMN — рабочий инструмент аналитика в корпоративных проектах, и на собеседовании его почти всегда просят отличить от блок-схемы.

BPMN (Business Process Model and Notation) — нотация описания бизнес-процессов, где явно видно, кто исполнитель каждого шага, какие события влияют на ход процесса и как обрабатываются исключения.

Вопрос 1. Чем BPMN отличается от обычной блок-схемы?

Что проверяют. Понимаете ли вы, что BPMN — это про межролевое взаимодействие и события, а не просто про красивые ромбики.

Три принципиальных отличия:

Исполнители явные. Пул (pool) — организация или система, дорожка (lane) — роль внутри неё. Каждая задача лежит на конкретной дорожке, поэтому сразу видно зоны ответственности и передачи между отделами. В блок-схеме исполнителя нет вообще.
События первого класса. Процесс может стартовать по сообщению, по таймеру, по условию; на задачу можно повесить граничное событие «прошло 3 дня» или «пришёл отказ». Блок-схема этого не выражает.
Стандартизованная семантика. BPMN исполним: описанную схему может выполнять движок процессов (Camunda и подобные). Блок-схема — просто картинка.

Базовые элементы, которые обязан назвать аналитик

Элемент	Значение
Задача (task)	единица работы: пользовательская, сервисная, отправка/получение сообщения
Событие (event)	стартовое, промежуточное, конечное; по сообщению, таймеру, ошибке
Эксклюзивный шлюз (XOR)	ровно одна ветка из нескольких — «или/или»
Параллельный шлюз (AND)	все ветки одновременно, дальше ждём все
Событийный шлюз	дальше пойдём по той ветке, чьё событие наступит первым
Пул / дорожка	участник процесса / роль внутри участника
Поток сообщений	пунктирная стрелка между пулами (между организациями)

Важная деталь, которую спрашивают: сплошная стрелка (sequence flow) не может пересекать границу пула. Между пулами — только пунктирный поток сообщений. Это отражает реальность: вы не управляете порядком работ внутри чужой организации, вы только обмениваетесь с ней сообщениями.

Вопрос 2. Опишите процесс согласования заявки в BPMN

Что проверяют. Разберёте ли вы исключения: отказ, доработку, истечение срока. Кандидат, рисующий только «согласовал → исполнил», выдаёт отсутствие практики.

ПУЛ: Компания
┌──────────────────────────────────────────────────────────────┐
│ Дорожка: Сотрудник                                            │
│  (○ старт) → [Создать заявку] ───────────────┐                │
│                     ▲                        │                │
│              [Доработать заявку]             │                │
│                     ▲                        ▼                │
├─────────────────────┼────────────────────────────────────────-┤
│ Дорожка: Руководитель                        │                │
│                     │                 [Рассмотреть заявку]    │
│                     │                        │                │
│                     │                    <XOR решение>        │
│                     │        отклонить ─────┼──── на доработку│
│                     └───────────────────────┘                 │
│                              согласовать                       │
│                                   │                            │
├───────────────────────────────────┼───────────────────────────-┤
│ Дорожка: Бухгалтерия              ▼                            │
│                          [Провести оплату] → (● конец)         │
└──────────────────────────────────────────────────────────────┘

Граничное событие-таймер на «Рассмотреть заявку»:
если 3 рабочих дня нет решения → эскалация вышестоящему
руководителю (отдельная ветка, не показана в схеме).

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

Вопрос 3. Зачем описывать «как есть», если всё равно всё переделываем?

Что проверяют. Понимание ценности моделей AS-IS и TO-BE.

Модель AS-IS нужна по трём причинам. Первая: чтобы измерить эффект. Без цифр текущего процесса (сколько шагов, сколько времени, сколько ручной работы, где ждут дольше всего) вы не докажете пользу нового решения. Вторая: чтобы не потерять исключения. В работающем процессе годами накоплены обходные пути под реальные ситуации, и их выбрасывание — источник провальных внедрений. Третья: чтобы найти настоящее узкое место — часто оказывается, что автоматизировать нужно вовсе не тот шаг, о котором просил заказчик.

При этом AS-IS не нужно рисовать во всех подробностях. Достаточно уровня, на котором видны передачи ответственности между ролями и точки ожидания — там и живут потери.

Типичные ошибки кандидатов

Ведут сплошную стрелку между пулами вместо потока сообщений.
Рисуют один пул на всех и теряют главное преимущество нотации — видимость передач между ролями.
Показывают только счастливый путь: без отказа, доработки и просрочки.
Путают эксклюзивный и параллельный шлюзы: ставят AND там, где ветки взаимоисключающие, и процесс формально никогда не завершается.
Забывают закрывать открытые шлюзы: разветвили параллельно, а слияние не нарисовали.
Уходят в детали интерфейса: «выбрать в выпадающем списке» — это не задача процесса.

Как ответить кратко

BPMN отличается от блок-схемы тем, что показывает исполнителей через пулы и дорожки, поддерживает события — таймеры, сообщения, ошибки — и имеет строгую исполнимую семантику. Между пулами допустим только пунктирный поток сообщений, сплошные последовательные потоки внутри пула. Обязательно моделирую исключения: отказ, возврат на доработку и граничный таймер на просрочку — без них схема бесполезна. AS-IS рисую до TO-BE, чтобы измерить эффект в цифрах, не потерять накопленные исключения и найти реальное узкое место, а не то, на которое указали.