Описание основных элементов BPMN 2.0

Событие в BPMN 2.0 – это элемент диаграммы процесса, который показывают, что в определенный момент что-то произошло (или может произойти), и процесс должен на это отреагировать.

По своему положению в процессе события могут быть стартовыми, промежуточными или завершающими.

По поведению в процессе события могут быть перехватывающими или инициирующими.

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

Инициирующие события (Throwing events) имеют активную природу и создают определенное действие (например, отправку сообщения клиенту). Не блокируют выполнение процесса – оно продолжается без задержек. Инициирующими могут быть промежуточные или завершающие события.

Триггер – причина возникновения события и результат, который инициирует событие. Тип триггера (событие, таймер, условие, сигнал) указывается внутри значка события. Событие может быть абстрактным – без триггера (None).

События в BPMN 2.0 не являются обязательными. Однако рекомендуется указывать на диаграммах стартовые и завершающие события, а промежуточные события использовать при необходимости.

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

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

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

Действие в BPMN 2.0 – это элемент диаграммы процесса, который обозначает единицу работы, выполняемой в процессе. Это единственный элемент BPMN, у которого есть исполнитель. Процесс задает последовательность выполнения действий (workflow). Действия бывают двух типов: задачи (Tasks) и подпроцессы (Sub-Processes).

Задача в BPMN 2.0 – это простое действие (атомарная операция), которое не имеет дальнейшей декомпозиции в рамках рассматриваемого процесса. Поэтому описание задачи на диаграмме должно полностью передавать ее содержание. Специализированные типы задач по исполнителям и способам выполнения:

В дополнение к приведенным выше специализированным типам задач их можно маркировать как циклы, множественные экземпляры и компенсации.

Подпроцесс в BPMN 2.0 – это действие в рамках основного процесса, которое имеет декомпозицию и описывается более подробно на отдельной диаграмме. Подпроцессы позволяют разбивать большой и сложный процесс на логически связанные части, а также скрывать детали их внутреннего устройства от основного процесса. Использование подпроцессов упрощает диаграммы, облегчает понимание и сопровождение процессов.

Классификация подпроцессов

1. Встроенный подпроцесс (Embedded Sub-Process).
2. Независимый подпроцесс (Reusable Sub-Process | Call Activity).
3. Спонтанный подпроцесс (Ad-Hoc Sub-Process).
4. Событийный подпроцесс (Event Sub-Process).
5. Транзакционный подпроцесс (Transaction Sub-Process).

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

Ниже приведен упрощенный пример процесса обработки заявки клиента управляющей компании в сфере ЖКХ.

Приведенная диаграмма процесса обработки заявки клиента сделана в iDTU Studio на нашем сайте. Редактор позволяет разворачивать и сворачивать подпроцесс непосредственного на диаграмме родительского процесса.

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

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

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

Например, процесс обработки заявки клиента управляющей компании в сфере ЖКХ может отличаться для разных типов заявок – аварийных, платных, текущих (без оплаты). Это может потребовать разработки трех разных диаграмм. При этом закрытие заявки будет одинаковым для всех типов заявок и его целесообразно сделать независимым подпроцессом.

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

Например, процесс "Подготовка презентации для клиента" может включать ad-hoc подпроцесс "Создание контента", где дизайнер свободно выбирает последовательность действий по подготовке текстовых блоков, подбору картинок, разработке инфографики в зависимости от специфики проекта и собственного творческого подхода.

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

Поддерживает события: сообщение, таймер, ошибка, эскалация, компенсация, условие, сигнал. Прерывающие подпроцессы дополнительно поддерживают события отмены (в контексте транзакций) и завершения.

Например, в процессе обработки заказа в интернет-магазине может быть непрерывающий событийный подпроцесс "Уведомление клиента о статусе заказа", который запускается по таймеру каждые 3 часа для отправки клиенту e-mail о ходе выполнения заказа, а также прерывающий подпроцесс "Отработка отмены заказа", который запускается при получении сообщения от клиента об отмене заказа. Прерывающий подпроцесс полностью прекращает обработку заказа, меняет статус заказа в ИТ-системе интернет-магазина и инициирует событие, запускающее компенсационные задачи: снятие резерва товара, возврат денег клиенту, расформирование заказа и возврат товара на склад, отмену заявки на доставку товара клиенту. В такой модели отмена может произойти на любом этапе обработки заказа.

Транзакционный подпроцесс выполняет группу активностей как единую атомарную операцию по принципу "все или ничего". Гарантирует, что все содержащиеся в подпроцессе активности будут выполнены успешно либо все изменения будут отменены. Обозначается двойной рамкой. Может быть завершен тремя способами:

1. Успешное завершение (все операции подтверждены).
2. Отмена транзакции (возврат в исходное состоянию).
3. Опасность (hazard) (частичное выполнение без гарантий целостности).

Поддерживает специальные граничные события: отмена (сancel), ошибка (error) и компенсация (compensation). Cancel event принудительно завершает транзакцию с полным откатом изменений. Error event обрабатывает ошибки и может инициировать компенсацию. Compensation event определяет логику отмены уже выполненных операций.

Шлюз в BPMN 2.0 – это элемент диаграммы процесса, который управляет маршрутизацией потоков в процессе (workflow). С помощью шлюзов моделируют точки принятия решений, в которых происходит ветвление (split) и слияние (join) потоков. Шлюз сам не выполняет действий – он лишь контролирует поток, поэтому все данные, на основе которых происходит маршрутизация, должны быть определены до достижения шлюза.

Классификация шлюзов

1. Шлюз XOR (Exclusive Gateway).
2. Шлюз AND (Parallel Gateway).
3. Шлюз OR (Inclusive Gateway).
4. Событийный шлюз (Event-based Gateway).
5. Комплексный шлюз (Complex Gateway).

Шлюз XOR используется, когда из нескольких возможных направлений нужно выбрать только один путь. При ветвлении (XOR-split) выполняется проверка условий на исходящих потоках. Сработает первый поток, для которого условие истинно. На случай, когда не выполнено ни одно из условий, может быть задан путь по умолчанию (default). Если путь по умолчанию не указан и ни одно из условий не выполнено, возникает исключение времени исполнения. При слиянии (XOR-join) ожидается поступление потока по одному из входящих маршрутов. Шлюз XOR используется для моделирования ситуаций выбора ("если … то … иначе …").

Представленный фрагмент диаграммы процесса со шлюзами XOR-split и XOR-join может быть выполнен 3 различными путями: <ABE>, <ACE>, <ADE>.

Шлюз AND используется, когда нужно организовать параллельное выполнение задач. При ветвлении (AND-split) запускаются все исходящие потоки одновременно, без условий. При слиянии (AND-join) ожидается поступление потоков со всех входящих маршрутов и только после этого процесс может быть продолжен. Порядок выполнения задач между AND-split и AND-join может быть любым, но они должны быть выполнены все.

Представленный фрагмент диаграммы процесса со шлюзами AND-split и AND-join может быть выполнен 3! = 6 различными путями: <ABCDE>, <ABDCE>, <ACBDE>, <ACDBE>, <ADBCE>, <ADCBE>.

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

Представленный фрагмент диаграммы процесса со шлюзами OR-split и OR-join может быть выполнен 5 различными путями: <ABE>, <ACE>, <ADE>, <ABCE>, <ACBE>.

Событийный шлюз используется, когда выбор направления зависит не от условий, а от того, какое событие произошло. После достижения такого шлюза процесс «ждет» одного из возможных событий (сообщения, таймера и т.п.). Как только первое событие случается, соответствующий поток активируется, а остальные становятся недоступны. Событийный шлюз работает на ветвление (split). Поскольку сработать может только одно направление, то для слияния используется XOR-join.

Комплексный шлюз используется для сложных правил маршрутизации, которые не удается описать с помощью шлюзов XOR, AND или OR. При ветвлении (split) может содержать сложные условия и выражения, которые определяют, какие исходящие пути будут активированы. При слиянии (join) шлюз работает как "умный синхронизатор". В отличие от AND-join (который ждет все входящие потоки) и OR-join (который ждет только активированные), комплексный шлюз позволяет задать собственные правила синхронизации. Используется редко – в сложных процессах, где недостаточно стандартных шлюзов.

Участники в BPMN 2.0 – это элементы диаграммы процесса, которые обозначают субъектов, взаимодействующих в рамках рассматриваемого процесса. Каждый участник выполняет свои действия, обменивается сообщениями и может быть изображен в виде пула (pool) или дорожки (lane). Эти элементы позволяют четко разграничивать зоны ответственности в процессах.

Пул в BPMN 2.0 – это контейнер, который описывает границы процесса одного высокоуровневого участника. Обычно пул используется для представления процессов на уровне организации или крупного подразделения. На диаграмме пул может быть развернутым (expanded pool / white box pool) либо свернутым (collapsed pool / black box pool).

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

Свернутый пул отображается как простой прямоугольник с названием участника (например, "Клиент" или "Поставщик") без каких-либо внутренних элементов процесса. Он показывает только факт участия в процессе без деталей.

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

На диаграмме показан развернутый пул процесса обработки текущей заявки клиента управляющей компании в сфере ЖКХ (это может быть ремонт шлагбаума или замена лампы в холле – такие заявки не требуют оплаты и по ним не нужно согласовывать с клиентом время работы), свернутый пул клиента и информационный обмен между ними.

Дорожки в BPMN 2.0 используются внутри пула для визуализации более детального распределения обязанностей по исполнителям или структурирования процесса по иным категориям, например, чтобы отделить действия, создающие ценность, от действий, которые этого не делают. Дорожки могут быть вложенными (nested lanes) для создания иерархической структуры ответственности. Каждая дорожка должна иметь понятное название.

В отличие от пулов, дорожки не ограничивают поток управления – workflow может свободно проходить между ними.

На диаграмме в развернутом пуле процесса обработки текущей заявки клиента управляющей компании в сфере ЖКХ выделены две дорожки с исполнителями задач в рамках процесса – "Диспетчер" и "Профильный специалист".

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

Объектами данных в BPMN 2.0 являются объекты, сопровождающие выполнение процесса. Объекты данных подаются на вход и получаются на выходе задач и подпроцессов. Они могут находиться в разных состояниях (например, "черновик", "согласован", "утвержден"). Объекты данных связываются с действиями ассоциативными связями.

По своей сути объект данных является программной конструкцией и работает как локальная переменная на уровне процесса (временные данные, которые хранятся внутри экземпляра процесса во время его выполнения). Значение объекта данных видно другим элементам процесса – его можно передать на вход задачи или подпроцесса, проверить шлюзом, но оно невидимо в других процессах того же или более высокого уровня. Когда процесс заканчивается, объект данных исчезает.

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

Хранилища данных в BPMN 2.0 – это постоянные данные, такие как информация в базе данных или бизнес-системе. Такие данные могут запрашиваться или обновляться как в моделируемом процессе, так и вне его. Они не исчезают, когда моделируемый процесс завершается. Чаще всего хранилище, это то, что обычно подразумевается под "данными".

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

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

Задача 1 – получает данные о профиле клиента из учетной системы и создает в памяти процесса временный профиль.
Задача 2 – получает временный профиль, рассчитывает на основе данных временного профиля условия обслуживания на следующий месяц, обновляет временный профиль условиями на следующий месяц.
Задача 3 – получает обновленный временный профиль и обновляет профиль клиента в учетной системе.

Обновленный профиль в учетной системе сохраняется и становится доступным в других процессах. Созданный в процессе временный профиль исчезает после завершения процесса.

Для связи элементов BPMN 2.0 используются потоки управления, потоки сообщений, ассоциативные связи.

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

Потоки сообщений показывают обмен сообщениями между разными пулами. Изображаются пунктирной линией со стрелкой. Не используются внутри одного пула.

Ассоциативные связи в виде пунктирной линии со стрелкой используются для соединения объектов и хранилищ данных с другими элементами диаграмм. Пунктирная линия без стрелки используется при добавлении к элементам диаграммы пояснительных текстовых аннотаций.

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

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

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