Стартовое событие BPMN

Стартовое событие BPMN — это элемент нотации BPMN (Business Process Model and Notation, рус. «Нотация моделирования бизнес-процессов»), обозначающий начало потока работ (процесса) или подпроцесса. В диаграммах BPMN стартовое событие изображается в виде окружности с тонкой одинарной линией и всегда является точкой входа, инициирующей выполнение последовательности действий. Оно может быть как явным (например, получение сообщения), так и неявным (например, наступление определённого времени). Стартовое событие — обязательный элемент для любого процесса, за исключением некоторых типов подпроцессов.

Классификация и виды

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

Пустое стартовое событие (None Start Event)

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

Стартовое событие по сообщению (Message Start Event)

Инициируется получением сообщения от другого участника (роли, системы или внешнего процесса). Внутри окружности изображается конверт. Сообщение может быть как синхронным (например, вызов API), так и асинхронным (например, электронное письмо). Этот тип часто используется для моделирования взаимодействия между процессами разных организаций или систем.

Стартовое событие по таймеру (Timer Start Event)

Запускает процесс в определённый момент времени или по расписанию. Маркер — часы. Может быть задан:

• конкретная дата и время (например, «2024-01-01T00:00:00»);
• циклическое расписание (например, «каждый первый понедельник месяца»);
• период (например, «через 2 часа после завершения предыдущего процесса»).

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

Стартовое событие по условию (Conditional Start Event)

Запускается, когда выполняется определённое логическое условие. Маркер — лист бумаги с загнутым углом. Условие может быть связано с изменением состояния данных (например, «когда остаток товара на складе становится меньше 10 единиц») или с наступлением бизнес-события (например, «когда заявка поступает в систему»). В отличие от таймера, условие не привязано ко времени, а только к факту выполнения.

Стартовое событие по сигналу (Signal Start Event)

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

Стартовое событие по ошибке (Error Start Event)

Используется в контексте подпроцессов-обработчиков ошибок (Error Boundary Event). Запускает подпроцесс, когда в основном процессе возникает ошибка определённого типа. Маркер — молния. Этот тип событий применяется для моделирования исключительных ситуаций, например, обработки сбоя в работе системы или отказа оборудования.

Стартовое событие по эскалации (Escalation Start Event)

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

Стартовое событие по компенсации (Compensation Start Event)

Запускает подпроцесс компенсации, который отменяет или корректирует действия, выполненные в основном процессе. Маркер — стрелка, закрученная в спираль. Используется в сложных бизнес-процессах, где требуется откат транзакций (например, при отмене заказа).

Стартовое событие по нескольким условиям (Multiple Start Event)

Обозначает, что процесс может быть инициирован любым из нескольких триггеров (например, по сообщению или по таймеру). Маркер — пятиугольник. Внутри может быть указано, какой именно триггер сработал первым. Этот тип событий редко используется на практике из-за сложности реализации.

Стартовое событие по параллельным условиям (Parallel Multiple Start Event)

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

Графическое представление

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

Применение в моделировании

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

• Внешними — инициируются извне (сообщения, сигналы, таймеры).
• Внутренними — запускаются вручную или по условию внутри организации.

На практике наиболее часто используются пустое, таймерное и стартовое событие по сообщению. Остальные типы применяются в специфических сценариях, таких как обработка ошибок или компенсация.

Примеры использования

1. Обработка заказа: пустое стартовое событие — сотрудник вручную начинает процесс при поступлении заявки.
2. Ежемесячная отчётность: стартовое событие по таймеру — процесс запускается первого числа каждого месяца.
3. Интеграция с CRM: стартовое событие по сообщению — процесс начинается при получении данных о новом клиенте из внешней системы.
4. Аварийное оповещение: стартовое событие по сигналу — процесс запускается при срабатывании датчика пожарной сигнализации.

Ограничения и особенности

• В одном процессе может быть только одно стартовое событие, если процесс не является подпроцессом. Для подпроцессов допускается несколько стартовых событий, но это редкость.
• Стартовое событие не может иметь входящих потоков (sequence flows) — только исходящие.
• В некоторых реализациях BPMN (например, в Camunda или Activiti) поддерживаются не все типы стартовых событий. Например, событие по компенсации часто отсутствует.
• При моделировании процессов с несколькими стартовыми событиями (множественное или параллельное) необходимо учитывать, что они могут привести к неоднозначности в потоке управления, если не заданы чёткие правила приоритета.

Источники

• Object Management Group (OMG). «Business Process Model and Notation (BPMN), Version 2.0.2». — 2014.
• Freund, J., Rücker, B. «Real-Life BPMN: Using BPMN 2.0 to Analyze, Model, and Improve Business Processes». — 2019.
• Silver, B. «BPMN Method and Style: A Levels-based Methodology for BPMN Process Modeling». — 2011.
• Документация Camunda Platform 7. «BPMN 2.0 Event Types». — 2023.