Пример BPMN: роли, развилки и исключения на заявке

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

Ниже — не аудит реальной компании и не отчёт о внедрении. Это руководство и синтетический BPMN-пример на условной заявке на закупку. Его можно перенести на свой процесс, заменив учебные роли, суммы, сроки и правила фактическими данными.

Какую задачу решает этот процесс

Представим рабочую ситуацию. Владелец процесса хочет убедиться, что заявка не потеряется между подразделениями. Бизнес-аналитик должен превратить устные объяснения участников в схему, которую все прочитают одинаково.

Им нужно ответить на четыре вопроса:

1. Кто подаёт, проверяет, согласует, исполняет и подтверждает заявку.
2. При каких условиях заявка движется дальше, возвращается или завершается отказом.
3. Что происходит, если не хватает документа или согласующий не отвечает.
4. Какой результат считается завершением каждой ветви.

Результат работы — читаемая BPMN-модель одной заявки с ролями, развилками и исключениями. Она помогает обсудить процесс до разработки автоматизации, но не заменяет аудит фактического процесса. Схема сама по себе не подтверждает, что сотрудники действительно работают именно так, данные доступны, а системы поддерживают нужные операции.

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

Какие данные и правила подготовить

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

Удобно разделить сведения на три группы:

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

Заполненный синтетический образец

Все имена, суммы, сроки и обозначения ниже условны. Это не данные клиента и не результат проекта Switch On AI.

Сумма учебной заявки вычисляется одинаково во всех ветвях: 3 × 40 000 ₽ = 120 000 ₽. Поскольку условные 120 000 ₽ больше условного порога 100 000 ₽, после проверки полноты заявка должна перейти к Борису на согласование.

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

Какие элементы BPMN нужны для первого процесса

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

• Событие — наступивший факт. Начальное событие запускает процесс, промежуточное показывает ожидание или полученное сообщение, конечное фиксирует результат ветви.
• Задача — работа участника или системы: подать заявку, проверить документ, согласовать закупку.
• Exclusive gateway — развилка, после которой токен идёт по одной подходящей ветви. У каждой исходящей ветви должно быть проверяемое условие.
• Parallel gateway — параллельный запуск всех предусмотренных ветвей. Один входящий токен создаёт два токена для двух ветвей; объединяющий parallel gateway ждёт оба и выпускает один токен дальше.
• Pool — отдельный участник взаимодействия или граница управляемого процесса.
• Lane — роль или зона ответственности внутри pool. В учебном процессе один pool организации содержит lanes «Заявитель», «Согласующий» и «Исполнитель».
• Sequence flow — порядок действий внутри одного процесса. Он соединяет задачи, события и gateway внутри pool, в том числе между его lanes.
• Message flow — обмен сообщениями между разными участниками, представленными отдельными pools. Между lanes одного pool его не используют.

Такое различие pool, lane, sequence flow и message flow соответствует справочнику символов BPMN 2.0. Справочник также описывает онлайн- и настольный modeler, но эта статья не заявляет личный запуск программы и не оценивает её совместимость с системами читателя.

Токен и две разновидности развилок

Токен — удобная мысленная метка текущего положения экземпляра процесса. После exclusive gateway токен выбирает одну ветвь: например, «документ приложен» или «документ отсутствует». После parallel gateway появляются токены на всех параллельных ветвях: например, одновременно отправить уведомление и подготовить внутреннюю задачу. Если ветви затем объединяются, gateway ждёт завершения обеих.

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

Участники, сообщения, таймеры и подпроцессы

Внутренние роли удобно показать lanes одного pool. Если в модель добавляется внешний поставщик, его можно представить отдельным pool. Тогда запрос коммерческого предложения и ответ поставщика соединяются message flow, а внутренние действия организации — sequence flow.

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

Таймер обозначает ожидание определённого момента или интервала. Он не означает автоматического одобрения. Сообщение показывает отправку или получение информации, а не просто переход к следующему внутреннему шагу.

Краткий справочник событий

• Start event: известен факт, запускающий экземпляр процесса.
• End event: ветвь получила определённый итог — исполнена, отклонена или закрыта без исполнения.
• Message event: продолжение зависит от отправки или получения сообщения.
• Timer event: процесс ждёт срока или реагирует на его наступление.
• Conditional event: продолжение зависит от изменения проверяемого условия.
• Error event: подпроцесс или операция завершились определённой ошибкой, для которой предусмотрена обработка.
• Escalation event: ситуацию нужно передать на другой уровень, не подменяя этим бизнес-решение.
• Signal event: одно опубликованное событие предназначено для нескольких потенциальных получателей; применять его стоит только при действительно широковещательном взаимодействии.

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

Как нарисовать нормальный путь заявки

Сначала нарисуйте путь без ошибок. Используйте один pool организации и три lanes по ролям, а не по состояниям карточки:

• «Заявитель» — подаёт заявку и исправляет неполные данные;
• «Согласующий» — проверяет полноту и принимает решение по заявке;
• «Исполнитель» — выполняет одобренную заявку и подтверждает результат.

Названия «Новая», «На согласовании» и «Исполнена» описывают состояния заявки, поэтому для lanes они не подходят.

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

1. Start event «Возникла потребность».
2. Заявитель выполняет задачу «Подать заявку».
3. Согласующий выполняет задачу «Проверить полноту».
4. Exclusive gateway проверяет условие «Коммерческое предложение приложено?».
5. При ответе «Да» выполняется задача «Рассчитать сумму».
6. Exclusive gateway проверяет условие «Сумма выше 100 000 ₽?».
7. Для учебных 120 000 ₽ токен идёт по ветви «Да — требуется согласование».
8. Согласующий выполняет задачу «Принять решение».
9. Exclusive gateway направляет токен по условию «Одобрено» или «Отклонено».
10. При условии «Одобрено» исполнитель выполняет заявку.
11. Исполнитель подтверждает результат.
12. Процесс заканчивается событием «Исполнена и подтверждена».

Учебный регламент может разрешать переход к исполнению без отдельного согласования, если сумма не выше условных 100 000 ₽. Это именно условное правило примера, а не универсальная практика. В реальном процессе его утверждает владелец процесса, а бухгалтерские, юридические и отраслевые требования проверяет профильный специалист заказчика.

Каждая исходящая ветвь gateway получает условие. Подписи «к Борису» и «к Вере» недостаточны: они называют адресата, но не объясняют, почему токен выбрал этот путь.

Как показать отказ, таймер и возврат

Исключение нужно довести до результата так же тщательно, как нормальный путь. Иначе схема выглядит законченной, но не отвечает на вопрос сотрудника: «Что делать сейчас?»

Возврат из-за недостающего документа

После проверки полноты поставьте exclusive gateway «Коммерческое предложение приложено?»:

• Да: рассчитать сумму и продолжить маршрут.
• Нет, возвратов меньше двух: вернуть заявку заявителю и увеличить счётчик возвратов.
• Нет после второго возврата: завершить экземпляр событием «Закрыта без исполнения».

Изменение счётчика задаётся формулой r_new = r_old + 1. В учебном прогоне r_old = 0, поэтому после первого возврата r_new = 1. Анна добавляет коммерческое предложение, повторная проверка даёт ответ «Да», и процесс продолжается. Сумма остаётся равной условным 120 000 ₽.

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

Отклонение

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

Таймер отсутствия ответа

Для учебного примера контрольная точка определяется так: deadline = время передачи на согласование + 2 условных рабочих дня.

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

• отправить напоминание согласующему и продолжить ожидание;
• прекратить ожидание ответа и создать задачу владельцу процесса для ручного решения;
• зафиксировать просрочку и продолжить ожидание по утверждённому правилу.

Таймер не меняет решение на «Одобрено» и не отправляет заявку к исполнителю автоматически. Отсутствие ответа и одобрение — разные факты.

Учебный пример: путь от входных данных до результата

Ниже приведена собственная учебная последовательность, а не снимок интерфейса, клиентский файл или результат внедрения. Все имена, числа и сроки синтетические.

Исходные данные: заявка Z-001; заявитель Анна; 3 условных монитора по условной цене 40 000 ₽; коммерческое предложение сначала отсутствует; порог согласования — условные 100 000 ₽; согласующий Борис; исполнитель Вера; срок ответа — 2 условных рабочих дня; разрешено не более 2 возвратов.

Проход по схеме:

1. Анна подаёт Z-001.
2. Проверка обнаруживает отсутствие коммерческого предложения.
3. Заявка возвращается Анне; счётчик меняется с 0 на 1.
4. Анна прикладывает документ и повторно подаёт заявку.
5. Проверка полноты даёт результат «Да».
6. Система или сотрудник по принятому правилу рассчитывает сумму: 3 × 40 000 ₽ = 120 000 ₽.
7. Exclusive gateway сравнивает 120 000 ₽ с условным порогом 100 000 ₽. Условие «сумма выше порога» выполняется.
8. Борис получает заявку на согласование. Если ответа нет 2 условных рабочих дня, непрерывающий таймер создаёт напоминание Борису, а процесс продолжает ждать явного решения. Таймер не одобряет заявку.
9. В основном учебном прогоне Борис принимает решение «Одобрено».
10. Вера исполняет заявку и подтверждает результат.
11. Процесс завершается событием «Исполнена и подтверждена».

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

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

Как проверить результат перед запуском

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

Проведите настольную проверку токена по нескольким заранее описанным ситуациям:

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

• у каждого exclusive gateway подписаны взаимоисключающие условия;
• parallel gateway применён только там, где нужны все параллельные ветви;
• sequence flow не соединяет разные pools;
• message flow не используется между lanes одного pool;
• роли названы ролями, а не статусами карточки;
• у каждой ветви есть конечный результат либо понятное возвращение к конкретной проверке;
• учебные числа не выданы за регламент компании;
• схема не представлена как доказательство фактической работы процесса.

Такой прогон проверяет внутреннюю согласованность модели, но не заменяет наблюдение за реальной работой, проверку данных и техническую приёмку автоматизации. Process Mining в это предложение и очередь работ не входит.

Что согласовать для внедрения

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

Собственная интеграция нужна, если маршрут должен работать с формой, ботом, внутренним сервисом или другой системой: получать данные, создавать задачу, ждать решение, отправлять уведомление и сохранять подтверждение. До разработки следует проверить фактические данные, доступные API, тариф, права пользователя, ограничения и способ обработки сбоев. Упоминание инструмента моделирования не доказывает совместимость, партнёрство или опыт его внедрения.

Switch On AI может помочь превратить задачу «читаемая схема заявки с ролями, развилками и исключениями» в ограниченный сценарий будущего решения. В зависимости от операции это может быть ИИ-помощник, чат-бот или обычная интеграция. Форматы не взаимозаменяемы: бот даёт диалоговый вход, интеграция передаёт данные и запускает согласованные действия, а ИИ-помощник уместен только там, где требуется работа с неструктурированными запросами или материалами.

Работа начинается не с обещания полной автоматизации, а с одной операции. Нужно согласовать:

• фактический старт и результаты процесса;
• обязательные и условные поля;
• владельцев правил и справочников;
• роли, права и замещение сотрудников;
• условия всех ветвей;
• сроки ожидания и ручные действия при просрочке;
• лимиты повторов и конечные события;
• доступность API и допустимые операции;
• примеры для проверки нормального пути и исключений;
• границы прототипа, разработки, передачи и сопровождения.

Switch On AI разрабатывает ИИ-помощника, бота или интеграцию для согласованной операции после проверки данных и API. Прототип показывает ограниченный ключевой сценарий и не равен полноценному внедрению. Состав работ, оценка, права и условия передачи определяются отдельно. Подробнее о доступных форматах можно прочитать на странице услуг.

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