Введение. Декомпозиция как необходимый метод построения архитектуры бизнес-процессов организации
По ходу моделирования бизнес-процессов в нотации BPMN в Business Studio схемы часто становятся слишком сложными, что снижает их визуальную наглядность, повышает трудоемкость анализа и принятия решений, затрудняет регламентацию. На громоздкой, запутанной схеме сложно выявить и устранить логические ошибки. Часто бывает так, что схема включает действия, которые являются фрагментами других процессов. Возможные причины — недостаточно продуманная архитектура бизнес-процессов организации, отсутствие навыка определения границ процессов, использования декомпозиции, применения типовых (повторно выполняемых) процессов.
Для того, чтобы сделать модель достаточно простой и наглядной можно:
- создать несколько подпроцессов;
- исключить со схемы действия, которые выполняются в рамках других процессов, и смоделировать взаимодействие с этими процессами (межпроцессное взаимодействие);
- использовать типовые (повторно выполняемые) процессы.
В любом случае, возникает практическая необходимость грамотно использовать методы декомпозиции и межпроцессного взаимодействия. Давайте их рассмотрим.
Создание подпроцессов
На рис. 1 показана схема процесса, включающая несколько задач (действий, операций). Документооборот и подписи шлюзов не показаны для упрощения восприятия схемы. Модель может рассматриваться в качестве учебного примера.
На рис. 1 выделены оранжевым цветом и обведены красными овалами группы задач, которые усложняют схему. По размеру они сделаны специально меньше (на практике я не рекомендую изменять размеры значков).
Рис. 1. Исходная схема бизнес-процесса
Начнем с группы задач, выполняемых Исполнителем Б. Они обведены красным овалом № 1. Вместо этой группы задач оставим одну — «Выполнить расчет и подготовить презентацию».
Далее декомпозируем эту задачу на нижний уровень, используя так же нотацию BPMN.
На рис. 2 видно, что у этой задачи появился маркер «+» внутри квадрата, а схема в целом стала выглядеть значительно проще.
Рис. 2. Создание подпроцесса
Что означает «Подпроцесс» в нотации BPMN? В отличие от полноценного процесса, для которого определяется так называемая «Процессная сущность» (уникальная структура данных) и могут запускаться отдельные экземпляры, подпроцесс в BPMN не имеет своей процессной сущности и является обособленной частью процесса в целом. Это удобно для моделирования (упрощения схемы процесса) и автоматизации.
Однако такой подпроцесс, поскольку он не имеет процессной сущности, невозможно «запустить» на исполнение другим процессом или использовать как типовой при проектировании других процессов в архитектуре.
В BPMN используется два понятия: Collapsed Sub Process («Свернутый») и Extended Sub Process («Раскрытый»). Первый показывается в виде задачи с маркером «+» внутри квадрата, второй — в виде схемы процесса. На рис. 3 показан пример: схема без Sub Process (вверху), Collapsed Sub Process (в середине) и Extended Sub Process (внизу).
В Business Studio в силу архитектуры этой системы невозможно показать на схеме процесса Extended Sub Process, только Collapsed Sub Process.
Рис. 3. Collapsed Sub Process и Extended Sub Process
При моделировании процессов в нотации BPMN в Business Studio довольно часто возникает ситуация, когда на схеме процесса указан один исполнитель, а на схеме подпроцесса возникает несколько дорожек с разными исполнителями.
Если на уровне процесса исполнитель — подразделение, а на уровне подпроцесса — сотрудники, то с этим еще можно мириться, принимая во внимание насущные задачи регламентации процесса. Но если подпроцесс на верхнем уровне выполняет конкретный исполнитель, а на нижем — куча других исполнителей, то это методическая ошибка.
Дело в том, что в Business Studio дорожки используются для назначения исполнителей задач. Это означает, что если мы помещаем какую-то задачу на дорожку исполнителя, то для этой задачи автоматически назначается этот же исполнитель с типом связи «Выполняет». Поэтому очень странно выглядит ситуация, когда на одном уровне задачу «выполняет» конкретный сотрудник, а ниже уровнем задачи «выполняют» уже совершенно другие сотрудники.
С точки зрения регламентации процессов и формирования должностных инструкций такое решение, на мой взгляд, недопустимо. Если бы мы использовали на верхнем уровне тип связи «Является владельцем» или «Отвечает» (такого типа связи по умолчанию нет в Business Studio, но его можно создать), а на нижнем «Выполняет», то такое решение можно было бы считать рациональным.
Обратите внимание, что в нотации BPMN (в отличие от решения, реализованного в Business Studio) дорожки вообще носят вспомогательный (иллюстративный) характер. Назначение исполнителей осуществляется для каждой задачи. Даже если мы назовем как-то дорожку, мы можем в BPMN назначить любых исполнителей.
На рис. 4 показана схема подпроцесса «Выполнить расчет и подготовить презентацию». В данном случае исполнитель тот же самый, что и на верхнем уровне, так что все корректно (с точки зрения регламентации в Business Studio).
Обратите внимание, что подпроцесс начинается с неопределенного события. Как правильно его называть в Business Studio? Часто я просто указываю «Нужно сделать что-то...» и т. п. в зависимости от сути выполняемых действий. Завершающее событие так же именовано по смыслу.
Рис. 4. Схема подпроцесса «Выполнить расчет и подготовить презентацию»
Рассмотрим далее группу задач 2 (см. рис. 1) и обсудим, как можно поступить в этом случае.
Запуск других процессов путем отправки сообщений
Обратите внимание на группу задач на рис. 1, обведенных овалом под номером 2. Его выполняют «Другие исполнители». Можно было бы создать несколько дорожек, но я специально не стал усложнять схему.
Создадим отдельный процесс под названием «Подготовить данные». Теперь этот процесс можно запустить на исполнение из Процесса А, организовав межпроцессное взаимодействие.
Измененная модель показана на рис. 5. Исполнитель А выполняет задачу «Запросить данные». После нее показано промежуточное событие «Запрос на предоставление данных», которое инициирует на выполнение процесс «Подготовить данные». Он показан в виде свернутого пула над схемой. От события к нему проведена стрелка типа Message Flow.
После отправки сообщения поток процесса идет далее и останавливается на событии ожидания сообщения «Предоставлены данные». Когда оно приходит из процесса «Подготовить данные», Процесс А продолжается. Выполняется проверка данных. Если данные некорректные, то происходит возврат и повторный запуск процесса «Подготовить данные». Видно, что схема процесса (рис. 5) стала значительно проще.
Рис. 5. Межпроцессное взаимодействие
Схема процесса «Подготовить данные» показана на рис. 6. Обратите внимание, что процесс запускается путем получения сообщения из Процесса А и завершается отправкой сообщения в Процесс А.
Рис. 6. Схема процесса сбора данных
На рис. 7 показаны возможные варианты моделирования межпроцессного взаимодействия путем отправки и получения сообщений. Поскольку в Business Studio такие примеры технически сделать нельзя, я использовал моделер Camunda.
Пример 1. Первый процесс запускается событием неопределенного типа, например человеком. После выполнения первой задачи отправляется сообщение, которое инициирует выполнение второго процесса. Стартовое событие второго процесса — сообщение. После выполнения двух задач второй процесс отправляет в первый ответное сообщение. Первый процесс, в свою очередь, находится в режиме ожидания получения сообщения после выполнения третьей задачи.
Пример 2. Первый процесс отправляет во второй сообщение. Но проблема в том, что сообщение нельзя отправить в процесс, который еще не стартовал. Поэтому межпроцессное взаимодействие в Примере 2 возможно только в том случае, если второй процесс стартует раньше, чем первый отправит в него соответствующее сообщение. Эту особенность нужно учитывать, используя метод организации межпроцессного взаимодействия при моделировании в нотации BPMN.
Рис. 7. Возможные варианты межпроцессного взаимодействия путем отправки и получения сообщений
Представим себе ситуацию когда необходим сбор массива данных по одному и тому же алгоритму, но одновременно в разных подразделениях и разными исполнителями. В предыдущем примере мы запускали на исполнение только один экземпляр процесса «Подготовить данные». Как быть, если нужно запустить сразу несколько экземпляров этого процесса, получить и проверить данные? На рис. 8 показано, как это можно сделать.
Создан подпроцесс «Получить данные». Для него показан маркер параллельного многоэкземплярного цикла. Это означает, что этот подпроцесс будет запушен столько раз, сколько необходимо для сбора всех данных.
Рис. 8. Подпроцесс, созданный для отправки/получения сообщений
Схема подпроцесса «Получить данные» показана на рис. 9. Она достаточно проста и не требует комментариев.
Рис. 9. Схема процесса «Получить данные»
Использование типовых процессов
Еще одним достаточно интересным архитектурным решением является использование так называемых типовых или, другими словами, повторно выполняемых процессов. В нотации BPMN это называется Call Activity — вызов другого процесса в рамках уже выполняемого.
Обратите внимание на красный овал № 3 на рис. 1. На нем показаны задачи по согласованию документа. В данном, учебном примере использован параллельный метод согласования. Если у кого-то из согласующих лиц есть замечания, то после выполнения всех задач согласования, необходимо получить и проверить результаты (задача «Получить результаты согласования») и, при наличии замечаний, повторно выполнить подготовку документа. Возможны другие модели цикла согласования.
На практике часто бывает так, что процесс согласования является стандартным — определена последовательность задач и список участвующих в процессе руководителей. В этом случае совершенно нецелесообразно описывать такой цикл в каждом конкретном процессе, где необходимо что-то согласовать. Гораздо проще и практичнее описать цикл согласования как отдельный типовой процесс, а потом использовать его в виде готового решения в моделях других процессов.
В Business Studio создадим новую модель процесса в нотации BPNM под названием «Согласовать документ». Она показана на рис. 10.
Рис. 10. Процесс «Согласовать документ». Упрощенный учебный пример
На схеме Процесса А удалим группу задач согласования (овал № 3) и соответствующие дорожки, закроем схему, скопируем в навигаторе процесс «Согласовать документ» и вставим его как задачу в Процесс А, обязательно используя опцию «Вставить как ссылку», откроем схему Процесса А на редактирование и внесем необходимые изменения. На рис. 11 показана готовая схема Процесса А.
Задача «Согласовать документ» на дорожке Руководителя — это типовой (повторно выполняемый) процесс. В терминах Business Studio — это процесс-ссылка.
Содержательно, представленная конструкция означает следующее. После выполнения операции «Проверить документ» запускается типовой процесс «Согласовать документ» с параметрами (данными), определенными при выполнении Процесса А. При запуске создается отдельный экземпляр процесса «Согласовать документ». После его завершения продолжается Процесс А, в который передаются соответствующие данные по результатам согласования.
Кстати, если нам нужно запустить несколько экземпляров типового процесса, то можно использовать маркер многоэкземплярного параллельного (или последовательного — в зависимости от потребности) цикла. В данном примере для процесса согласования договора это лишено физического смысла, но в других ситуациях может понадобиться.
Рис. 11. Использование типового процесса
Как вы видите на рис. 11, схема процесса стала существенно проще и понятнее.
Кейс. Взаимодействие с типовым процессом путем отправки-получения сообщений
В одном из проектов при использовании типовых процессов возникла интересная практическая задача. Нужно было в рамках выполнения некоторого процесса:
- запустить на выполнение типовой процесс;
- продолжить выполнение процесса и:
- дождаться, когда внутри типового процесса будет выполнена определенная задача (сам типовой процесс еще не закончен), получить сообщение из типового процесса, обработать его и продолжить выполнение.
На рис. 12 показан фрагмент модели, которая решает поставленные задачи. После выполнения шага «Задача N» одновременно запускается типовой процесс и еще два потока работ.
Внизу схемы показано, что типовой процесс выполняется и затем данный поток работ завершается.
Средний поток («Задача N+1» и далее) продолжается своим чередом.
Верхний поток работ сразу останавливается и ждет получения сообщения из процесса «Подготовить данные» (свернутый пул).
Как работает такая модель? По ходу выполнения запущенный из нашего процесса экземпляр типового процесса отправляет сообщение, которое обрабатывается. Это кажется немного странным (и для многих спорным), но может использоваться.
Рис. 12. Фрагмент типового процесса
На рис. 13 показан фрагмент типового процесса, который отправляет нужное сообщение в рассматриваемый нами процесс.
Рис. 13. Фрагмент типового процесса
Сравнение трех методов «декомпозиции» процессов
Сравнение трех рассмотренных нами методов представлено в таблице 1.
| № | Наименование метода | Особенности |
|---|---|---|
| 1 | Использование подпроцесса |
|
| 2 | Взаимодействие с другим (в т.ч. типовым) процессом путем отправки/получения сообщения |
|
| 3 | Использование типового процесса (процесса-ссылки) |
|
Итак, мы рассмотрели три метода, позволяющие сделать модель процесса проще и визуально нагляднее за счет декомпозиции и применения архитектурных решений.
Вы можете осознанно применять представленные методы при моделировании бизнес-процессов вашей организации с использованием Business Studio. Не стоит чрезмерно увлекаться каким-то одним методом. Нужно умело их комбинировать и использовать там, где это практически целесообразно.
Февраль 2022 г.
Поделиться: