Начинать BPMN-схему удобно с одного процесса и понятного результата. Возьмём учебное согласование заявки: сотрудник отправляет заявку, руководитель принимает решение, а при нехватке данных возвращает её на доработку. В конце заявка либо согласована, либо отклонена.
Ниже нет универсального регламента компании. Это специально заданные правила упражнения, по которым можно проверить модель. На Mentoring.digital можно найти наставника, чтобы затем разобрать реальный процесс и не переносить учебные допущения в работу без проверки.
Сначала задаём границы процесса
Начальное событие: появилась потребность отправить заявку. Конечные результаты: «Заявка согласована» или «Заявка отклонена». Доработка не считается завершением: после исправления заявку снова рассматривают.
В упражнении участвуют две роли внутри одной организации: сотрудник и руководитель. Оплата, закупка, бухгалтерия и выдача оборудования находятся за пределами схемы. Такое ограничение позволяет обсудить именно согласование, а не пытаться вместить весь жизненный цикл в один рисунок.
- Сотрудник указывает цель, описание и необходимые исходные данные.
- Руководитель выбирает один исход: согласовать, отклонить или вернуть на доработку.
- При возврате сотрудник меняет заявку и отправляет её повторно.
- В этой версии не моделируются отпуск согласующего, срок ожидания и отзыв заявки. Их нужно обсудить отдельно перед применением схемы в организации.
Один пул и две дорожки
Создайте пул «Согласование заявки» и две дорожки: «Сотрудник» и «Руководитель». Пул задаёт участника процесса, дорожки помогают распределить ответственность внутри него. Обычный поток последовательности может переходить между дорожками одного пула.
Не проводите поток последовательности между разными пулами. Для взаимодействия самостоятельных участников используют поток сообщений. В данном упражнении отдельный внешний участник отсутствует, поэтому поток сообщений не нужен.
Название задачи должно обозначать действие: «Заполнить заявку», «Рассмотреть заявку», «Доработать заявку». Формулировки «Сотрудник» и «Согласование» сами по себе не объясняют, что происходит на шаге.
Собираем основной маршрут
Разместите обычное начальное событие, затем задачу сотрудника «Заполнить и отправить заявку», затем задачу руководителя «Рассмотреть заявку». После рассмотрения поставьте исключающий шлюз с вопросом «Какое решение принято?».
Шлюз не должен сам изображать работу руководителя. Работа находится в задаче перед ним, а шлюз направляет поток по уже полученному результату.
| Откуда | Условие или действие | Куда |
|---|---|---|
| Начальное событие | Возникла потребность | Заполнить и отправить заявку |
| Заполнить и отправить заявку | Заявка отправлена | Рассмотреть заявку |
| Рассмотреть заявку | Решение записано | Какое решение принято? |
| Шлюз | Согласована | Конечное событие «Заявка согласована» |
| Шлюз | Отклонена | Конечное событие «Заявка отклонена» |
| Шлюз | Нужна доработка | Доработать и повторно отправить заявку |
| Доработать и повторно отправить заявку | Исправления отправлены | Рассмотреть заявку |
Этот список переходов можно использовать как проверяемую основу рисунка в BPMN-редакторе. Возвратная стрелка ведёт к повторному рассмотрению, а не к конечному событию и не к самому началу с созданием новой заявки.
Почему здесь исключающий шлюз
По условиям упражнения решение одно. Поэтому нужен исключающий шлюз, часто обозначаемый ромбом с X: он выбирает один исходящий маршрут. Параллельный шлюз с плюсом запустил бы несколько ветвей и изменил смысл процесса.
Подпишите исходящие потоки условиями. Условия должны быть взаимно исключающими и покрывать допустимые решения. Для исполняемой модели нужно дополнительно определить, где хранится результат и как выражаются условия в выбранном движке. Человеческая подпись «Согласована» ещё не является исполняемым выражением.
В BPMN можно задать поток по умолчанию, если ни одно условие не выполнено. Он не должен незаметно превращать неизвестный результат в согласование. Сначала договоритесь, что делать с отсутствующим или некорректным решением, затем отразите это в модели и реализации.
Проверяем схему на конкретных сценариях
| Сценарий | Ожидаемый путь | Что проверить |
|---|---|---|
| Согласование с первого раза | Отправка → рассмотрение → согласовано | Не активируются ветки отказа и доработки |
| Отказ с первого раза | Отправка → рассмотрение → отклонено | Процесс действительно заканчивается |
| Один возврат, затем согласование | Отправка → рассмотрение → доработка → рассмотрение → согласовано | Заявка повторно попадает к руководителю |
| Два возврата, затем отказ | Два прохода цикла, затем отклонено | Цикл не создаёт параллельные копии рассмотрения |
| Решение не записано | Отдельно определяемое поведение | Нет молчаливого перехода к согласованию |
Пройдите каждый сценарий пальцем по стрелкам или в симуляторе выбранного редактора. Таблица проверяет логику маршрута; она не доказывает, что конкретный BPMN XML развёрнут и выполняется в движке. Для этой статьи исполняемый процесс не разворачивался.
Частые ошибки в первом варианте
- Решение руководителя заменено одним ромбом без предшествующей задачи.
- Все стрелки подписаны «Да» и «Нет», хотя вопрос у шлюза не сформулирован.
- После возврата заявка заканчивается, хотя автор должен продолжить работу.
- Для ролей одной организации созданы независимые пулы, а между ними проведены потоки последовательности.
- Параллельный шлюз используется вместо выбора одного решения.
- На рисунке есть таймер или сообщение, но в правилах процесса не описано соответствующее событие.
Проверка синтаксиса редактором полезна, но не заменяет проверку смысла. Формально допустимая схема может согласовывать заявку без нужной проверки или оставлять её в бесконечном ожидании.
Что уточнить перед переносом в рабочий процесс
Кто может быть согласующим? Может ли автор отозвать заявку? Есть ли замещение и сроки? Нужно ли хранить причину отказа? Можно ли менять уже согласованные данные? Как фиксируется новая версия при возврате? Ответы изменят модель и требования к системе.
Не добавляйте все события заранее ради сложного рисунка. Для каждого нового элемента должно быть правило и сценарий проверки. Храните вместе схему, словарь решений и примеры прохождения процесса.
На курсе системного анализа можно связать BPMN с требованиями, ролями и данными. Наставник по системному анализу поможет проверить конкретную модель: где смешаны ответственность и действия, какие исключения пропущены и как подтвердить корректность процесса.
