BPMN для системного аналитика: моделирование бизнес-процессов

Когда бизнес говорит «у нас сложный процесс согласования», а аналитик кивает и пишет портянку текста на три страницы — никто это читать не будет. Разработчик откроет, увидит стену из абзацев, закроет и пойдёт уточнять устно. Я видел такое десятки раз.

BPMN решает эту проблему одной схемой. Одна диаграмма заменяет три страницы текста, снимает вопросы «а кто после кого» и «а что если отказ» и становится тем документом, который реально открывают перед разработкой. Не потому что красиво. Потому что понятно за 30 секунд.

Что такое BPMN и почему это не «просто квадратики со стрелочками»

BPMN (Business Process Model and Notation) — стандарт для описания бизнес-процессов в виде диаграмм. Его разработала Object Management Group (те же, кто UML), и в отличие от UML-диаграмм, которые чаще читают разработчики, BPMN рассчитан на всех участников: бизнес, аналитиков, архитекторов, инженеров.

Главное преимущество — однозначность. Ромб с крестиком внутри означает шлюз «исключающее ИЛИ» в любой BPMN-диаграмме, где бы вы её ни открыли. Нет ситуации «я думал это просто ромбик для красоты». Это инженерная нотация, а не художественная.

Аналитику BPMN нужен в первую очередь для трёх сценариев:

• Документирование текущего процесса (as-is) — когда надо понять, как всё работает сейчас и где узкие места.
• Проектирование целевого процесса (to-be) — когда внедряете новую систему и надо договориться, как будет.
• Автоматизация — некоторые BPMN-движки умеют исполнять модель напрямую (Camunda, Flowable). Но это уже тема для архитектора.

Ядро BPMN: пулы, дорожки и исполнители

Если вы запомните три вещи про BPMN, запомните вот это:

Пул (Pool) — это граница процесса. Обычно одна организация или одна система. Взаимодействие между пулами — только через сообщения (пунктирная стрелка с конвертом), никогда через поток управления. Два пула на диаграмме — это уже взаимодействие B2B или интеграция систем.

Дорожка (Lane) — исполнитель внутри пула. Отдел, роль, конкретный сотрудник. Дорожки горизонтальные — читаются легче, особенно когда много участников.

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

Вот типичный пример распределения. Процесс «Оформление заказа»:

• Пул: «Интернет-магазин». Внутри — дорожки «Клиент», «Система», «Склад», «Бухгалтерия».
• Отдельный пул: «Платёжный шлюз» — внешняя система, с которой магазин обменивается сообщениями.

Начинающие часто лепят всё в один пул без дорожек. На диаграмме из 30 элементов это превращается в кашу: непонятно, кто делает каждое действие. Дорожки — это первое, что превращает кашу в читаемый процесс.

Обратная крайность — дробить на дорожки каждую роль. Если у вас Иван Петрович и Марья Ивановна делают одно и то же — это одна дорожка «Сотрудник», а не две персональные. BPMN моделирует роли, не личности.

Шлюзы: где процесс ветвится

Шлюз (Gateway) — это ромб. Точка, где поток управления разделяется или сливается. Четыре типа, которые реально нужны:

Эксклюзивный шлюз — самый частый. Параллельный — на втором месте. Вы используете именно их в 80% случаев.

Распространённый косяк: ставить шлюз там, где достаточно простого действия с двумя выходящими условными стрелками. Но без шлюза непонятно, это ветвление или параллельный запуск. Правило простое: раздвоение потока управления — всегда через шлюз.

Ещё один косяк: забывать про шлюз слияния. Если вы развели потоки эксклюзивным шлюзом, сведите их обратно таким же. Иначе диаграмма становится невалидной для исполнения в движках.

События: старт, финиш и всё, что между ними

События в BPMN — это круги. Три типа:

• Стартовое (тонкая линия) — с чего процесс начинается. Пришла заявка, клиент нажал кнопку, сработал таймер. Стартовое событие всегда одно на процесс (в рамках одного пула — да, в разных пулах могут быть свои старты).
• Промежуточное (двойная линия) — то, что происходит в середине. Отправка уведомления, ожидание ответа, ошибка. Может быть и кидающим (throw), и ловящим (catch).
• Конечное (жирная линия) — процесс завершён. Может быть несколько: успешное завершение, отказ, отмена.

Самая частая ошибка новичков — забывать конечные события на альтернативных ветках. Если у эксклюзивного шлюза есть ветка «Отказ», она должна заканчиваться конечным событием «Заявка отклонена». Иначе процесс висит в воздухе.

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

Пример: процесс согласования командировки

Ниже — реальный процесс согласования заявки на командировку с участием сотрудника, руководителя и бухгалтерии:

graph TD
  Start(["Старт: заявка на командировку"]) --> Fill["Сотрудник: заполнить заявку"]
  Fill --> Check{"Сумма > 50 000 ₽?"}
  Check -->|"Нет"| AutoApprove["Автосогласование"]
  Check -->|"Да"| ManagerReview["Руководитель: проверить обоснование"]
  ManagerReview --> MgrDecision{"Одобрено?"}
  MgrDecision -->|"Нет"| Reject["Отклонено: вернуть на доработку"]
  Reject --> Fill
  MgrDecision -->|"Да"| Budget["Бухгалтерия: проверить бюджет"]
  AutoApprove --> Budget
  Budget --> BudgetOk{"Бюджет доступен?"}
  BudgetOk -->|"Нет"| Escalate["Эскалация на финансового директора"]
  Escalate --> FinalDecision{"Финансовый директор"}
  FinalDecision -->|"Отказ"| Archived["Архивировано: отказано"]
  FinalDecision -->|"Одобрено"| Book["Бухгалтерия: заказать билеты и гостиницу"]
  BudgetOk -->|"Да"| Book
  Book --> Done(["Завершено: командировка оформлена"])

  style Start fill:#50c878,stroke:#3a9a5c,color:#fff
  style Done fill:#50c878,stroke:#3a9a5c,color:#fff
  style Reject fill:#f0a500,stroke:#c88400,color:#fff
  style Archived fill:#e0e0e0,stroke:#999,color:#333
  style Fill fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style AutoApprove fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style ManagerReview fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Budget fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Book fill:#4a90d9,stroke:#2c5f8a,color:#fff
  style Escalate fill:#7b68ee,stroke:#5a4db2,color:#fff
  style Check fill:#f0a500,stroke:#c88400,color:#fff
  style MgrDecision fill:#f0a500,stroke:#c88400,color:#fff
  style BudgetOk fill:#f0a500,stroke:#c88400,color:#fff
  style FinalDecision fill:#f0a500,stroke:#c88400,color:#fff

Синие элементы — действия исполнителей. Жёлтые ромбы — шлюзы, точки ветвления. Зелёные скруглённые блоки — старт и финиш процесса. Серый — тупиковая ветка «архивировано». Фиолетовый — этап эскалации на уровень выше.

Здесь три дорожки: сотрудник (заполнение), руководитель (проверка обоснования), бухгалтерия (бюджет и заказ). Обратите внимание: если руководитель отклоняет, процесс возвращается на доработку сотруднику — цикл, а не линейка. Такие петли — норма для реальных процессов, и BPMN их отлично показывает.

Уровни детализации: от наброска до исполняемой модели

BPMN различает три уровня проработки. Не нужно сразу лезть в третий — это как учиться водить на Ferrari.

Описательный (Descriptive) — набросок процесса для обсуждения с бизнесом. Минимум элементов: пулы, дорожки, задачи, базовые шлюзы. Понятно бухгалтеру и гендиру. Делается за час-два.

Аналитический (Analytical) — детальная схема для ТЗ и разработки. Добавляются типы задач (ручная, сервисная, скриптовая), события, потоки сообщений. Это уже документ для тех, кто будет реализовывать. Уровень аналитика.

Исполняемый (Executable) — модель, из которой BPMN-движок генерирует работающий процесс. Требует точных атрибутов, условий на шлюзах, привязки к API. Это уже зона архитектора, но аналитик должен понимать, что его схема может дойти до этого уровня — и не закладывать в неё неформализуемой логики.

Мой совет: начинайте всегда с описательного уровня. Если на нём процесс уже выглядит запутанным и бизнес не может объяснить логику — глубже лезть бессмысленно. Там не техдолг, там проблема в самом процессе.

Инструменты для рисования BPMN

Подходов два: универсальные рисовалки и специализированные BPMN-редакторы.

Для старта хватит draw.io (бесплатно, веб, есть набор BPMN-фигур). Кривая обучения — полчаса. Miro тоже ок для коллаборации, но BPMN-фигуры там примитивные.

Для серьёзной работы — Camunda Modeler (бесплатен, на десктоп, нативный BPMN 2.0 XML). Если проект дойдёт до автоматизации через Camunda, модель уже будет в правильном формате. Bizagi Modeler — тоже бесплатный, чуть тяжелее, зато с симуляцией процессов.

Для enterprise — ARIS, Sparx EA, Visual Paradigm. Тяжёлые, дорогие, избыточные для рядового аналитика. Если в компании уже есть лицензия — используйте. Если нет — не просите, вам хватит Camunda Modeler.

Главное правило: рисуйте в том инструменте, который удобен команде. BPMN-схема, нарисованная в draw.io и открытая всеми участниками, в сто раз полезнее идеальной модели в ARIS, которую никто не откроет.

Типичные ошибки, которые я вижу у начинающих

1. Поток управления пересекает границу пула. Между пулами — только поток сообщений (пунктир, конверт). Сплошная стрелка через пул — синтаксическая ошибка.

2. Стартовых событий больше одного в пуле. В одном пуле стартовое событие одно. Если кажется, что нужно несколько — вы либо смешали несколько процессов в один, либо нужно использовать события-обработчики на границе.

3. Нет конечных событий на альтернативных ветках. Отрицательный сценарий должен заканчиваться конечным событием, иначе процесс выглядит незавершённым.

4. Перегруженная диаграмма. Если на схеме больше 30 элементов — дробите на подпроцессы (свёрнутый прямоугольник со знаком «+»). Одна диаграмма — один уровень абстракции.

5. Смешение уровней детализации. На одной диаграмме — и «проверить бюджет» (аналитический уровень), и «открыть Excel, ячейка B3, сравнить с лимитом» (исполняемый). Не надо так. Свёрнутый подпроцесс раскрывается на отдельной диаграмме.

6. Шлюз без подписи. Ромб с выходящими стрелками без текста — загадка для читателя. Подписывайте условия на исходящих стрелках: «Сумма > 50 000», «Товар в наличии». Без этого диаграмма бесполезна.

7. Рисование «ради рисования». BPMN-диаграмма без цели — просто красивая картинка. Каждая схема должна отвечать на вопрос: что мы с ней будем делать? Согласовывать? Отдавать в разработку? Автоматизировать? От ответа зависит уровень детализации и выбор элементов.

BPMN и другие нотации: когда что брать

BPMN не универсален. Там, где нужна диаграмма взаимодействия компонентов — берите UML Sequence. Где структура базы — ERD. Где алгоритм внутри одного сервиса — блок-схему или UML Activity. Где состояние заказа — UML State.

BPMN — про сквозной процесс с участием нескольких ролей или систем. Если в процессе три участника, два шлюза и обратная связь — это BPMN. Если один компонент вызывает другой — Sequence.

Что делать дальше

Начните с одного процесса из вашего текущего проекта. Не берите самый сложный. Возьмите «оформление заказа» или «согласование заявки» — тот, где вы уже знаете логику. Откройте draw.io, выберите BPMN-шаблон, нарисуйте описательный уровень с пулами и дорожками. Покажите коллеге, который не в контексте. Если он понял за минуту — схема работает. Если начал задавать вопросы про стрелки и ромбы — правьте.

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

Если вы пишете ТЗ для разработчика, BPMN-диаграмма процесса в разделе «Описание бизнес-процесса» снимает половину вопросов ещё до первого созвона. А в связке с User Story даёт полную картину: процесс показывает поток в целом, а истории — конкретные сценарии внутри каждого шага.