Четыре шага к построению модели сквозного процесса

Тезаурус

Перед тем как перейти к описанию алгоритма, нужно разобраться в двух понятиях: «процесс» и «экземпляр процесса».

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

А теперь предлагаю перейти к пошаговому алгоритму описания сквозного процесса.

Шаг 1. Определение границ процесса

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

• С какого события начинается процесс? Начинается ли он  по запросу клиента  или процесс инициирует сотрудник компании? Либо процесс является регулярным и запускается по определенному расписанию?

• Что определяет момент завершения процесса? Тут важно понимать, что после  завершения экземпляра процесса  никакие дополнительные действия с ним уже невозможны. А это значит, что если ваш процесс завершается на шаге «Подготовить и отправить счет клиенту», то вся дальнейшая работа с этим счетом, по получению денежных средств, например, должна проводиться в рамках отдельного процесса. Либо необходимо включить эти шаги в основной и пересмотреть его границы.

• Есть ли альтернативные сценарии завершения процесса? Например, отказ в сделке со стороны клиента или отказ в согласовании договора и т.д.

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

Очень часто, чтобы доказать «невозможность» описания того или иного процесса, мне во время разговора начинали сыпать фразами: «а вот еще так бывает», «а вот еще так». Вы должны понимать, что мы не создаем полную копию реального процесса, мы создаем его модель. А для создания рабочей модели редко нужно покрывать все возможные сценарии развития событий, достаточно сосредоточиться на основных, например, применив  правило Парето  – описать 80% самых вероятных исходов в процессе. При таком подходе можно описать любой процесс и решить поставленную при этом задачу.

Шаг 2. Выделение основных этапов процесса

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

Каждый из шагов – это повторяемый во времени  набор действий со своими границами . 

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

Пример коллизии

Рассмотрим пример процесса по подбору кадров. На первых этапах процесса задачи направлены на обработку заявки на подбор, а далее по схеме задачи ориентированы уже на работу с конкретным кандидатом. Переход от заявки к кандидатам на схеме упущен. Если читать модель «в лоб», то получается, что в рамках одной заявки на подбор может быть только один кандидат, что является ошибкой.

Для разрешения коллизии необходимо выделить все задачи, относящиеся к работе с конкретным кандидатом, в отдельный  подпроцесс  и в явном виде показать связь с основной заявкой «один ко многим».

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

Шаг 3. Создание диаграммы процесса верхнего уровня 

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

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

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

Это касается и завершающих событий. Поставить завершающее событие при отказе клиента в подпроцессе недостаточно, нужно обработать отказ и на родительском уровне, добавив развилку и повторив завершающее событие со статусом «Отказ со стороны клиента».

Пример ошибки

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

Для исправления этой ошибки необходимо добавить обработку альтернативных сценариев на родительской схеме процесса – добавить соответствующую развилку.

Если выделенные ранее этапы допускают параллельную обработку, то перед ними ставим развилку «И», далее распределяем подпроцессы по  параллельным веткам .

Шаг 4. Детализация подпроцессов

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

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

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

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

Рекомендация

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

• ваши диаграммы должны быть простыми и понятными на каждом уровне вложенности;

• не ленитесь и проводите рефакторинг ваших моделей, как это делают разработчики с кодом.