Внешняя система передаёт заявку, после чего начинается обработка. Что на BPMN-модели должно обозначать сам факт поступления заявки?
Сам факт поступления заявки следует обозначить событием начала, инициированным сообщением — Message Start Event. Оно показывает, что процесс запускается внешним сообщением, а не действием, выполняемым внутри процесса.
В нотациях моделирования процессов события отделяют факты, которые происходят, от действий, которые выполняют участники. Такое разделение появилось из практической необходимости однозначно показывать причины запуска, ожидание внешних сигналов, завершение и исключения.
В BPMN это различие особенно важно: модель описывает не только последовательность работ, но и поведение процесса во времени. Поэтому получение сообщения, выполнение задачи и отправка сообщения представлены разными типами элементов.
Если показать поступление заявки задачей, например «Получить заявку», модель смешает внешний факт и внутреннюю работу. Неясно, кто выполняет эту задачу, когда она считается завершённой и является ли получение заявки причиной старта процесса или частью уже идущего процесса.
Такая ошибка влияет на анализ ожиданий, времени цикла и ответственности. Кроме того, при автоматизации может возникнуть неверное понимание: система должна ждать сообщение, регулярно проверять источник или запускать обработку по другому условию.
Message Start Event означает: процесс ещё не выполняется, а его экземпляр создаётся после получения определённого сообщения. В модели нужно явно указать, какое сообщение запускает процесс, например «Заявка на обслуживание».
Задача начинается уже после события. Она описывает работу процесса — например, «Проверить комплектность заявки». Событие не следует трактовать как действие сотрудника или системы: это факт, который инициирует или изменяет состояние процесса.
Важно отличать похожие случаи:
Если одно входящее сообщение может относиться к уже существующему процессу, нужно определить правило корреляции: например, по идентификатору заявки. Иначе система может ошибочно создать новый экземпляр вместо продолжения существующего.
Сервис получает обращение от внешнего портала. Аналитик рассмотрел три варианта: показать получение заявки задачей, использовать обычное событие начала или использовать событие начала сообщения.
Задача была отвергнута, потому что она не показывает внешний триггер и исполнителя. Обычное событие начала упрощает схему, но скрывает контракт между порталом и сервисом. Выбрано событие начала сообщения: оно явно фиксирует источник запуска и позволяет отдельно анализировать случаи, когда сообщение не пришло или содержит некорректные данные.
После этого команда смогла разделить задержку доставки сообщения и время обработки заявки, а также определить правило, по которому повторное сообщение связывается с существующим обращением.
1. Всегда ли входящее сообщение должно запускать новый экземпляр процесса?
Нет. Если процесс уже начат и ожидает дополнительную информацию, сообщение моделируется как промежуточное событие получения сообщения. Решение зависит от жизненного цикла процесса: создаёт ли сообщение новый экземпляр или продолжает существующий.
2. Чем событие отличается от задачи с точки зрения измерения процесса?
Задача имеет исполнителя, длительность и обычно потребляет ресурсы. Событие фиксирует факт или изменение состояния и само по себе не описывает работу. Если смешать их, можно неверно рассчитать трудозатраты и время ожидания.
3. Что произойдёт, если не определить корреляцию сообщений?
Система не сможет надёжно понять, к какому экземпляру процесса относится сообщение. Возможны создание дубликатов, потеря продолжения процесса или обработка данных не той заявки. Поэтому для сообщений, поступающих в уже запущенные процессы, нужно явно определить идентификатор или другое правило сопоставления.