BPMN-модель как основа для реализации процессов в СИЭР. Часть 2

#Уголок_профессора

Часть 2. Ракурсы моделирования и специфика событийной модели

BPMN (Business Process Model and Notation) для большинства знакомых с ней — инструмент иллюстрации и описания бизнес-процессов, регламентации, анализа и оптимизации действий пользователей, включая их взаимодействия со средствами автоматизации. Использование же BPMN2.0 с целью непосредственной реализации процесса переводит схему на другой уровень, где аналитику приходится думать и о технологических моментах.

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

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

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

На рисунке 1 представлена схема, которую легко поймёт заказчик, и по которой он провалидирует наше понимание автоматизируемого бизнес-процесса.

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

Структура нотации BPMN

Как известно, нотация BPMN включает следующие основные группы элементов:

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

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

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

• Согласовательный (описательный)
• Аналитический
• Исполняемый

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

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

Также различные ракурсы моделирования обусловливают условное разделение на стили процессного моделирования:

• Классический, или сценарный, процедурный — когда в процессе широко используются действия (таски), в т.ч. пользовательские действия (в таком стиле выполнена описательная модель с рисунка 1);
• Событийный — когда процесс это реакции на события (сообщения/таймеры/сигналы), в процессе много ожиданий и событийных шлюзов (в таком стиле выполнена исполняемая модель с рисунка 2);
• Статусный — когда процесс является набором состояний (статусов) (“Ожидание исправления”, “На подписании”, “В процессе отмены”) и переходов между ними;
• Статусно-событийный — когда значения для переходов к новым статусам и (или) событиям имеют комбинации текущих статусов и фиксируемых событий;
• Исключение-ориентированный — когда основной фокус на отработке исключений, которые выносятся с помощью граничных событий, компенсаций и эскалаций;
• Решение-ориентированный — когда процессы основаны на бизнес-правилах и принимаемых решениях (использование в связке с BPMN нотации DMN).