Меня часто спрашивают: — «Мы описали процесс в виде блок-схемы. Это же BPMN?» — «Workflow и BPMN — это одно и то же?» — «Могу я нарисовать workflow и отдать разработчикам?»

Короткий ответ: нет, это не одно и то же. Давайте разбираться.

🧩 Workflow — «что делаем» Workflow (поток работ) — это логика последовательности задач. Кто за кем, что за чем, где решение. Он отвечает на вопрос: «В каком порядке выполняются действия?».

Характеристики workflow: - Может быть нарисован в любой нотации (блок-схема, список шагов, даже текст) - Не требует строгих правил моделирования - Понятен почти любому сотруднику

Пример: «Сначала менеджер заполняет заявку, потом проверяет руководитель, потом отправляем клиенту». Workflow — это содержание. Схема или текст — это форма.

🎯 BPMN — это язык, на котором рисуют workflow (и не только) BPMN (Business Process Model and Notation) — это строгий стандарт моделирования. Он умеет то, что не умеет простая блок-схема: - События (получено письмо, наступил понедельник, пришёл ответ из API) - Шлюзы (ветвления: «если да — то одно, если нет — другое») - Пулы и дорожки (разные организации и роли внутри одной) - Связь с данными и системами

Характеристики BPMN: - Требует обучения (даже опытные аналитики путают типы событий) -Строго формализован (есть спецификация 2.0, по которой разработчики могут реализовать процесс в BPMS) - Не всегда понятен бизнес-пользователю без подготовки.

BPMN — это язык, на котором workflow можно описать так, чтобы его поняла и машина, и человек.

👀 Сравнение на живом примере Процесс: Согласование заявки на отпуск Вариант 1. Workflow (блок-схема, понятно всем) 1. Сотрудник заполняет заявку 2. Руководитель проверяет 3. Если согласовано - Уведомить сотрудника - Сотрудник направляет заявку в кадры 4. Если не согласовано - Уведомить об отказе

✅ Понятно. ✅ Быстро. ❌ Нельзя загрузить в BPMS и запустить автоматически.

Вариант 2. BPMN (строго, исполняемо) Стартовое событие: «Сотрудник инициировал заявку» User Task: «Заполнить заявку на отпуск» User Task: «Проверить заявку» (роль — Руководитель) Exclusive Gateway: «Согласовано?» Если Да → Service Task: «Записать в кадровую систему» Если Нет → User Task: «Указать причину отказа» End Event: «Процесс завершён» (два варианта)

✅ Строго. ✅ Исполнимо. ❌ Дольше рисовать. ❌ Требует знаний BPMN.

🎯 Что использовать и когда Согласовать логику с заказчиком за 15 минут → Workflow. Быстро, понятно, не нужно объяснять нотацию. Обучить нового сотрудника → Workflow + текст. Сотрудник должен въехать с первого раза. Передать процесс разработчикам на автоматизацию → BPMN. Разработчики поймут однозначно, нет двусмысленности. Интегрировать с BPMS (Camunda, ELMA, STORM) → BPMN (строгая 2.0). Система исполнит процесс без доработок. Описать процесс с таймерами (ожидание 3 дня) и событиями (пришло письмо) → BPMN. В блок-схеме это придётся «костылить». Написать регламент для внутреннего использования → Workflow + инструкция. BPMN будет избыточна и сложна для чтения.

💡 Мой подход На старте — workflow в Miro или на бумаге. Договариваюсь о логике с заказчиком. Если процесс идёт в автоматизацию — перевожу workflow в BPMN (в STORM или Camunda Modeler). Добавляю события, типы задач, данные. Если процесс остаётся «ручным» — оставляю workflow, добавляю роли и текстовое описание. BPMN не нужна. Главное правило: не рисуйте BPMN там, где достаточно блок-схемы. И не пытайтесь передать workflow в разработку как «почти BPMN» — программисты не угадают ваши намерения.

А Вы используете workflow и BPMN как взаимозаменяемые вещи или чётко разделяете? Бывало, что вы нарисовали сложную BPMN, а заказчик попросил «попроще, чтобы я понял»?