Действие Вызов

Действие «Вызов» в BPMN

Автор: Олег Борознов, 04.03.2018

Действие «Вызов» BPMN – это задача, которая вызывает глобальный процесс BPMN или глобальную задачу. Глобальный процесс или глобальная задача – это такой процесс или задача, которые вызываются из различных других процессов. В некоторых источниках можно встретить название «универсальный процесс» или «универсальная задача».

Например, глобальный процесс «Вход в систему» может использоваться в разных процессах, причем, вместо дублирования данный процесс моделируется один раз и затем вызывается там, где это необходимо. Глобальными задачами в BPMN 2.0 могут быть: пользовательская задача, ручная операция, задача-сценарий и выполнение бизнес-правила.

Чтобы отличать повторно используемый подпроцесс от встроенного, в BPMN 1.2 ему назначался специальный атрибут. В BPMN 2.0 повторно используемый подпроцесс теперь реализуется действием «Вызов», а любой подпроцесс является встроенным. При этом любой встроенный подпроцесс может быть определен как глобальный и вызван действием «Вызов» в любом другом процессе.

Действие «Вызов» BPMN изображается на диаграмме в виде прямоугольника с закругленными углами, но с границами выполненными жирной линией:

• Если целью действия «Вызов» является обычный подпроцесс, то оно изображается на диаграмме, с маркером подпроцесса (знаком «+»):
  
• Если целью действия «Вызов» является циклический подпроцесс, то оно содержит маркер соответствующего цикла. Например, вызов параллельного циклического подпроцесса выглядит так:
  

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

• Упрощения диаграммы процесса путем скрытия определенной последовательности действий на диаграмме.
• Объединения частей родительского процесса с добавлением определенных событий и маркеров.

Глобальные подпроцессы BPMN могут использоваться в различных процессах многократно. На диаграмме ниже приведен пример подпроцесса «Закупка товара», который вызывается в процессах «Обработка заказа» и «Управление закупками». В первом случае, если клиент купил товар и его нет в наличии. Во втором - если достигнут минимальный уровень запаса товара. Другой пример на этом же рисунке – подпроцесс «Оплата заказа», который вызывается в процессах «Обработка заказа» и «Ремонт».

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

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

Так, например, когда Ваша бухгалтерия хочет выставить счет-фактуру на ремонт, ей всегда необходимы следующие данные:

• Адрес
• Дата поставки
• Описание товаров или услуг
• Сумма счета-фактуры
• Ожидаемая дата оплаты

Владельцы всех процессов, в которых предусмотрено выставление счета-фактуры (процесс обработки заказов, процесс ремонта и т.д.), должны предоставить эти данные. Учет будет нуждаться в данных в стандартном формате.

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