Как моделировать процесс в BPMN 2.0 для согласования требований с бизнесом и разработкой

BPMN 2.0 полезен системному аналитику не потому, что позволяет нарисовать «красивую схему», а потому, что делает требования наблюдаемыми. Хорошая диаграмма показывает, где начинается процесс, кто за что отвечает, какие шаги выполняются человеком, какие — в системе, где процесс ветвится, что может идти параллельно и какими исходами всё заканчивается. Для согласования с бизнесом и разработкой этого обычно достаточно.

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

BPMN как общий язык требований

В контексте согласования требований BPMN отвечает на несколько базовых вопросов:

• Что запускает процесс и что считается его завершением.
• Какие действия происходят по пути и в какой последовательности.
• Кто выполняет шаг: бизнес-роль, пользователь в системе, автоматизированный компонент.
• Где принимается решение и по каким исходам расходятся ветки.
• Что можно делать параллельно, а что требует синхронизации.

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

Минимальный каркас: что брать в первую схему

Для большинства учебных и рабочих задач на этапе согласования хватает такого набора: pool, при необходимости lane, start event, end event, task, sequence flow, XOR gateway и AND gateway.

Pool задаёт границу процесса. Для первой версии схемы удобно держать один pool на один процесс: например, «Согласование изменения требования». Это помогает не расползаться в смежные процессы.

Lane нужен, когда важно показать ответственность внутри процесса. Это может быть роль, отдел или система: «Бизнес-заказчик», «Системный аналитик», «Разработчик», «CRM». Не делайте lanes автоматически для всех участников встречи: добавляйте их только там, где распределение ответственности помогает чтению.

Start event и end event проясняют рамку обсуждения. Без них схема часто превращается в бесконечный фрагмент «что-то где-то происходит».

XOR gateway используйте для взаимоисключающих вариантов, когда после проверки или решения возможен только один путь. AND gateway — когда нужно распараллелить шаги или затем дождаться завершения нескольких веток. Для начинающего аналитика этого почти всегда достаточно; более сложные конструкции имеет смысл подключать только при реальной необходимости.

Если предмет обсуждения — взаимодействие независимых участников как отдельных процессов, тогда уместны разные pools и message flow. Но для согласования продуктовых требований это часто избыточно. Сначала соберите понятную схему в одном pool, а отдельные pools вводите только тогда, когда именно межпроцессное взаимодействие является источником вопросов.

Как различать ручные, пользовательские и автоматизированные шаги

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

Manual Task полезен, когда в процессе есть офлайн-действие: например, менеджер созванивается с заказчиком или согласует спорный момент на встрече. Для описательной схемы важнее всего сам смысл: команда видит, что это не клик в системе и не автоматизация, а отдельная человеческая работа.

User Task нужен там, где есть конкретное пользовательское действие в системе: «Подтвердить приоритет требования», «Заполнить поля согласования», «Выбрать вариант реализации». В исполнимых BPM-платформах такой тип обычно означает создание задачи для пользователя или группы. Но на этапе согласования требований его главная ценность проще: он явно отделяет работу в интерфейсе от свободной ручной активности.

Service Task показывает автоматическую работу: «Проверить дубликаты требований», «Создать задачу в трекере», «Отправить уведомление». Для бизнеса это снимает ожидание, что шаг кто-то делает вручную, а для разработки — помогает увидеть границу автоматизации.

Здесь важно развести два уровня разговора. BPMN-тип элемента — это язык модели. Поведение во время исполнения зависит от конкретной платформы. Например, в материалах Camunda User Task создаёт пользовательскую задачу, а Service Task может выполняться встроенным кодом или через внешний обработчик. Поэтому в статье о согласовании требований лучше сначала фиксировать смысл шага для участников, а технические нюансы исполнения выносить в комментарии к модели.

Отдельно стоит сказать про внешний вызов автоматизированного шага. В материалах Camunda это описано как способ исполнения Service Task, при котором движок публикует единицу работы, а внешний worker забирает и завершает её. Для разговора с бизнесом такой механизм обычно не рисуют целиком. На диаграмме чаще достаточно показать Service Task, а в текстовых требованиях указать, что шаг реализуется внешним worker по topic или через другой механизм получения работ.

Декомпозиция без перегрузки

Если один шаг на верхнем уровне начинает распухать до отдельного сценария, его стоит свернуть в sub-process. Это помогает сохранить обзорность родительской схемы и при этом не потерять детали.

Embedded sub-process — встроенный подпроцесс внутри родительского процесса. Он нужен для иерархического описания: на верхнем уровне вы видите один укрупнённый шаг, а на дочернем — его внутреннюю последовательность. Встроенный подпроцесс живёт внутри родительской модели, а его потоки не должны пересекать границу подпроцесса.

Collapsed sub-process — это не отдельный вид логики, а свёрнутое представление того же подпроцесса. Для согласования требований это часто лучший формат: на верхнем уровне остаётся читаемый путь процесса, а детали открываются только тем участникам, которым они действительно нужны.

Практическое правило: выносите шаг в подпроцесс, когда внутри него уже есть несколько содержательных действий, собственные развилки, отдельные участники или исключения, из-за которых верхний уровень перестаёт читаться.

Чтобы декомпозиция не ломала понимание процесса, соблюдайте несколько правил:

• Название дочерней диаграммы должно совпадать с названием подпроцесса.
• Родительский уровень показывает только значимые вход и выход подпроцесса.
• Исходы на дочернем уровне должны объяснять, почему из подпроцесса процесс выходит именно по тем веткам, которые есть у родителя.
• Внутренняя логика живёт внутри подпроцесса; sequence flow не пересекает его границу.

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

Отдельно полезно не путать подпроцесс с Call Activity. Call Activity используют, когда вызывают отдельно определённый, переиспользуемый процесс. Для начального согласования требований это не всегда нужно, но различие важно: встроенный подпроцесс помогает скрыть сложность внутри текущей схемы, а Call Activity обозначает обращение к отдельному процессу, у которого свои границы и своя ответственность.

Правила подписи: как сделать схему однозначной

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

Задачи

• Называйте задачи глаголом и объектом: «Проверить полноту требований», «Создать задачу разработки», «Подтвердить оценку».
• Избегайте абстракций вроде «Обработка», «Работа с заявкой», «Действие 1».
• На одном уровне схемы не давайте разным задачам одинаковые имена, если это не действительно один и тот же шаг.

Конечные состояния

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

XOR-ветвления

Шлюз не принимает решение сам по себе. Сначала должен быть шаг, который создаёт основание для выбора: проверка, анализ, валидация, согласование. После этого ставится XOR gateway, а каждая исходящая ветка подписывается взаимоисключающим исходом: «Полно», «Неполно»; «Одобрено», «Отклонено».

Если вариантов два, допустим формат с вопросом у шлюза и ветками «Да» и «Нет», но только когда вопрос действительно очевиден. Иначе лучше подписывать сами исходы, а не общие «Да/Нет» без контекста.

AND-ветвления

AND не проверяет условия. Он означает: запускаем все исходящие пути параллельно или ждём все входящие пути на объединении. Поэтому подписи на ветвях AND обычно не нужны. Важно не забывать обратный AND-join там, где после параллельных шагов процесс должен продолжиться один раз.

Что фиксировать текстом рядом с BPMN

Даже хорошая диаграмма не заменяет текстовые требования. Рядом с BPMN полезно держать компактное описание, которое снимает скрытую неоднозначность.

Минимальный набор обычно такой:

• Условия ветвления: по каким правилам путь уходит в «Одобрено» или «На доработку».
• Бизнес-правила: что считается полным требованием, кто имеет право отклонить, когда нужна повторная оценка.
• Данные и поля: какие поля обязательны на User Task, откуда они берутся, кто их меняет, какие значения критичны для следующих шагов.
• Интеграционные допущения: вызов синхронный или асинхронный, что считается технической ошибкой, как система узнаёт об успешном результате.
• Альтернативные исходы: какие исключения показаны на диаграмме, а какие пока остаются вне рамки текущего согласования.

Это особенно важно для описательных моделей, потому что часть данных в них остаётся скрытой. Диаграмма показывает, что после проверки возможны две ветки, но не обязана показывать все переменные, которыми эта проверка определяется. Поэтому текст рядом со схемой должен раскрывать именно те данные и правила, без которых участники по-разному поймут один и тот же путь.

Учебный пример. Верхний уровень процесса может выглядеть так:

Старт: Получен запрос на изменение требования
→ Проверить полноту запроса (User Task)
→ XOR: Полно / Неполно
  → Неполно → Запросить уточнение (User Task)
             → Конец: Требования возвращены на доработку
  → Полно → Согласовать решение с командами (Collapsed Sub-Process)
→ Создать задачу разработки (Service Task)
→ Параллельно:
   1) Уведомить бизнес (Service Task)
   2) Обновить реестр требований (User Task)
→ Конец: Требования согласованы

А рядом текстом стоит зафиксировать: какие поля обязательны для «полноты», кто входит в «команды», что именно создаётся в трекере, и как трактуется сбой на автоматизированном шаге. Если команда использует платформу с внешними workers, это тоже можно указать в тексте как способ реализации Service Task, не перегружая саму диаграмму техническим устройством исполнения.

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