Как описать бизнес-процесс as-is и to-be в BPMN 2.0
Схема «как должно быть» не объясняет, почему заявки сегодня застревают у руководителя. А схема текущей работы без целевого решения лишь фиксирует неудобство. Пара as-is и to-be полезна, когда нужно сравнить наблюдаемый процесс с предложенным изменением, не смешивая факты и намерения.
Разберём авторский учебный процесс согласования клиентской заявки. Нотацию сверяем с руководствами Camunda по BPMN; порядок интервью, сравнения и согласования изменений предложен для упражнения. Это функциональная модель для обсуждения с людьми, не готовый к запуску исполняемый процесс.
Одинаковые границы для двух моделей
Выберем начало — компания получила заявку, конец — отправила подтверждение либо мотивированный отказ. Подготовка рекламы и выполнение уже подтверждённого заказа остаются за рамками. Если в to-be внезапно начать считать процесс только после предварительной проверки, сравнение длительности с as-is станет некорректным: часть работы просто исчезнет из границ.
Один экземпляр процесса — одна заявка. Участники внутри компании: менеджер и руководитель. Клиент взаимодействует с компанией сообщениями, но его внутренний порядок работы нам неизвестен. На модели можно показать отдельный закрытый пул клиента и пул компании с дорожками менеджера и руководителя.
Pool представляет участника взаимодействия, lane распределяет ответственность внутри выбранного процесса. Не превращайте каждый отдел в отдельный независимый пул автоматически: сначала решите, моделируете ли вы единый процесс компании или взаимодействие самостоятельных участников.
Минимум элементов, который нужен в этом случае
| Элемент | Для чего в упражнении | Пример названия |
|---|---|---|
| Start event | Обозначить запуск экземпляра | Получена заявка |
| Task | Показать действие с понятным результатом | Проверить данные заявки |
| Exclusive gateway | Выбрать один из альтернативных путей | Данные полные? |
| Receive task или подходящее catching event | Показать ожидание сообщения | Получить уточнение |
| End event | Обозначить завершение пути | Подтверждение отправлено |
Sequence flow показывает порядок выполнения внутри процесса; message flow — обмен между участниками. Не соединяйте один сквозной sequence flow через границы пула компании и клиента. Переход между дорожками компании допустим в рамках её процесса: это передача работы, а не новый внешний участник.
Исключающий шлюз выбирает один выход. Подпишите условия, например «да» и «нет», чтобы читатель понимал ветвление. Параллельный шлюз имеет другой смысл: запускает все выходящие ветви, а при соответствующем объединении ждёт входящие пути. Его нельзя ставить вместо «одобрить или отказать», если обе ветви не должны выполняться.
As-is: записать действительную работу
Для учебного интервью менеджер рассказал: каждую заявку сначала вручную регистрируют, затем проверяют. Если сведений не хватает, запрашивают уточнение и ждут клиента. Любую полную заявку передают руководителю; после решения менеджер отправляет подтверждение либо отказ. Пока это рассказ одного участника, его нужно сверить с руководителем и примерами заявок.
Соберите в моделере следующую логику. Таблица ниже — инструкция построения, а не замена условным обозначениям BPMN:
| Шаг | Ответственный | Продолжение |
|---|---|---|
| Получена заявка | Процесс компании | Зарегистрировать заявку |
| Зарегистрировать заявку | Менеджер | Проверить данные |
| Проверить данные → Данные полные? | Менеджер | Нет — запросить уточнение; да — согласовать условия |
| Запросить уточнение | Менеджер | Получить уточнение от клиента |
| Получить уточнение | Менеджер | Вернуться к проверке данных |
| Согласовать условия → Одобрено? | Руководитель | Да — отправить подтверждение; нет — отправить отказ |
| Отправить подтверждение или отказ | Менеджер | Соответствующее завершение |
Клиентский пул связан message flows с получением первоначальной заявки, запросом уточнения, получением ответа и итоговым сообщением. Ожидание уточнения не изображайте как мгновенную проверку условия «ответил?»: процесс должен иметь место, где ждёт внешнего сообщения.
Не исправляйте as-is по ходу рисования. Если регистрация действительно дублируется в двух системах, покажите это или зафиксируйте детализацию отдельно. Если участники расходятся в описании, отметьте вопрос и источник сведений; не выбирайте удобную версию без проверки.
Найти узкое место, не угадывая по длине стрелки
В нашей модели две возможные зоны ожидания: ответ клиента и очередь руководителя. На рисунке обе могут занимать мало места. Чтобы сравнить их, нужны события и время: получение заявки, завершение проверки, передача на согласование, решение и отправка результата.
Отдельно посмотрите возвраты: сколько заявок запрашивают уточнение и какие данные чаще отсутствуют? Где запись вводят вручную повторно? Эти вопросы возникают из модели, но сама схема не доказывает длительность или частоту. Пометка «узкое место» без наблюдений остаётся гипотезой.
Уровень детализации выбирают под задачу. Если обсуждается очередь согласования, не обязательно показывать каждый клик интерфейса. Если причина ошибки в переносе реквизитов, соответствующий подпроцесс придётся раскрыть. Руководство Camunda прямо оставляет выбор гранулярности задачи моделировщику; количество прямоугольников не является мерой качества анализа.
To-be: назвать изменение и условия его применимости
Предложим два условных изменения: автоматическую проверку обязательных полей после получения заявки и передачу руководителю только нестандартных условий. Это авторский проект решения. Он требует согласования правил, полномочий и технической реализуемости; нотация BPMN сама по себе ничего не разрешает и не автоматизирует.
Начало и конечные результаты сохраняем. После регистрации идёт предложенная проверка полей. Неполная заявка по-прежнему уходит на уточнение и возвращается к проверке. Для полной заявки добавляем XOR «Условия стандартные?»:
- Да — менеджер готовит и отправляет подтверждение по согласованному правилу.
- Нет — руководитель принимает решение, затем менеджер отправляет подтверждение либо отказ.
Критерий стандартности нельзя оставить как красивое слово. В приложении к модели перечислите, какие параметры проверяются и кто утверждает правила. Если компания не делегировала такое решение менеджеру, ветку нельзя объявить действующим целевым порядком. Сначала требуется управленческое согласование, затем внедрение.
Не убирайте редкие отказы и возвраты только ради более короткой схемы. Отдельно решите, что делать при отзыве заявки, отсутствии ответа клиента и технической ошибке проверки. Если правила ещё неизвестны, перечислите открытые вопросы вместо выдуманного тайм-аута «по стандарту».
Проверить читаемость и пройти сценарии
Названия задач формулируйте через действие и объект: «Проверить заявку», а не «Проверка» или «CRM». Разместите основной ход последовательно и уменьшите пересечения. Каждое ветвление должно отвечать на понятный вопрос, а разные финалы — отличаться результатом.
На согласовании проведите три авторских прохода: полная стандартная заявка; неполная с последующим уточнением; полная нестандартная с отказом руководителя. Для каждого участник должен показать, что получает, что делает и что передаёт дальше. Если путь нельзя пройти без устного «тут и так понятно», уточните модель или сопровождающее правило.
Для исполняемой Camunda-модели дополнительно понадобятся точные выражения условий, обработчики, корреляция сообщений и другие настройки платформы. Не путайте функциональную надпись «данные полные» с уже настроенным conditionExpression. В частности, пустое условие выходящей ветви само по себе не делает её default flow в Camunda.
Передать в работу вместе с правилами измерения
К двум схемам приложите границы, версии, владельца процесса, список согласованных изменений и открытых вопросов. Для учебного сравнения выберем время от получения заявки до отправки результата, ожидание решения и долю возвратов за уточнением. Определите источники временных отметок и состав заявок; это наши выбранные метрики, а не обязательный перечень BPMN.
Улучшение нужно проверить после внедрения на сопоставимых данных. Если целевая схема выглядит короче, это ещё не означает сокращения срока: новая проверка может породить другую очередь. Полезный итог моделирования — объяснимый переход от наблюдаемого порядка к согласованному изменению, за которое есть ответственный и способ проверить результат.
