Команда моделирует один сценарий согласования, который должен вызываться из нескольких процессов. Какой элемент BPMN выбрать для такого сценария?
Используйте Call Activity — вызываемую активность. Она ссылается на отдельно определённый переиспользуемый процесс, поэтому один сценарий согласования можно вызывать из нескольких процессов.
Процессные модели часто содержат одинаковые фрагменты: согласование, проверку документов, расчёт лимита. Для таких повторяющихся фрагментов нужен механизм повторного использования, чтобы не копировать одну и ту же логику в разные диаграммы.
Call Activity решает эту задачу через отделение вызывающего процесса от вызываемого процесса. Это снижает дублирование и помогает поддерживать единое описание общего сценария.
Если скопировать сценарий согласования в каждый процесс, изменения придётся вносить во все копии. Со временем диаграммы начнут расходиться: в одном процессе появится дополнительная проверка, а в другом останется устаревшая логика.
Если вместо вызываемой активности использовать обычный Sub-Process, модель может создать ложное впечатление, что сценарий определён только внутри текущего процесса. Это ухудшит повторное использование и затруднит анализ влияния изменений.
Call Activity обозначает вызов глобально определённого процесса. Вызывающий процесс передаёт управление этому сценарию, а после его завершения продолжает выполнение с последующего элемента.
От обычного Sub-Process он отличается областью определения. Встроенный подпроцесс является частью конкретного родительского процесса, тогда как вызываемая активность предназначена для обращения к отдельному переиспользуемому процессу.
Переиспользование не означает автоматического отсутствия различий в данных. Нужно явно определить входные и выходные данные, условия успешного завершения, возможные ошибки и правила возврата управления.
У такого решения есть компромисс: диаграмма вызывающего процесса становится компактнее, но для полного понимания поведения нужно открыть отдельную модель вызываемого процесса. Поэтому полезно согласовать соглашения об именовании, интерфейсах данных и обработке исключений.
В компании согласование договора используется в процессах закупки, продажи и продления обслуживания. Сначала аналитики копировали последовательность задач в каждую диаграмму, из-за чего изменение матрицы согласующих требовало правок в трёх местах.
Рассматривались два варианта. Встроенные подпроцессы сохраняли весь контекст на одной диаграмме, но приводили к дублированию. Отдельные вызываемые процессы требовали перехода между моделями, зато обеспечивали единую реализацию сценария.
Выбрали Call Activity с явно описанными входными данными договора и выходным результатом согласования. После изменения правил согласования обновлялась одна модель, а вызывающие процессы сохраняли единый способ обращения к ней.
Повторное рисование создаёт независимые копии элементов. Между ними нет гарантии синхронности: изменение одной копии не меняет остальные.
Call Activity задаёт ссылку на один общий вызываемый процесс. Поэтому модель выражает не только визуальное сходство, но и намерение повторно использовать один процессный фрагмент.
Нет. Это элемент выполнения процесса, а не только навигационная ссылка в документации. Он обозначает передачу управления вызываемому процессу, его завершение и возврат результата или состояния в вызывающий процесс.
Конкретное поведение при ошибках, отмене и возврате данных должно быть определено моделью и правилами процесса. Одной ссылки на диаграмму недостаточно для полного описания контракта вызова.
Встроенный подпроцесс уместен, когда фрагмент является локальной частью одного процесса и не имеет самостоятельного смысла за его пределами. Он также удобен для структурирования большой диаграммы без создания отдельной переиспользуемой модели.
Call Activity предпочтительнее, когда один и тот же сценарий имеет самостоятельную семантику, используется несколькими процессами или должен изменяться централизованно. Выбор определяется не размером фрагмента, а его границами и намерением повторного использования.