Три уровня модели процесса

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

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

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

Процитированное выше – правда, но не вся. На самом деле уровней три:

1. архитектура процесса
2. схема процесса
3. рабочие инструкции процесса

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

Пример: закупка сырья

Рассмотрим в качестве примера процесс закупки основного сырья промышленным предприятием. Эксперт предметной области (например, руководитель отдела закупок) может изложить высокоуровневый взгляд на процесс так:

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

Неопытный аналитик воспримет этот рассказ за чистую монету и изобразит процесс так, как услышал:

Рис. 1. Наивное представление процесса закупки сырья

Отношения множественности

У более искушенного процессного специалиста возникнет ряд вопросов:

• Судя по схеме на рис. 1, для каждой закупки выбирается поставщик и с ним заключается договор. Но смысл рамочного договора в том, что он заключается на длительный срок (измеряемый месяцами или даже годами), после чего по нему периодически размещаются заказы. То есть связь между договором и заказом не один-к-одному (один договор – один заказ), а один-ко-многим (один договор – ноль, один или много заказов).
• Аналогичным образом, по одному заказу осуществляется несколько поставок.
• Оплата тоже осуществляется не по схеме»одна поставка – один платеж», а в соответствии с платежным календарем предприятия. Может проводиться как несколько платежей по одному заказу (аванс и оплата), так и наоборот – один платеж по нескольким заказам. То есть связь между поставкой и оплатой имеет вид многие-ко-многим.

Для наглядности покажем отношения множественности на схеме:

Рис. 2. Отношения множественности в закупке

Здесь 1:М – соотношение один-ко-многим, М:М – многие-ко-многим.

Чтобы показать, что в ходе процесса по одной и той же процедуре обрабатывается несколько объектов, в нотации BPMN есть специальный модификатор – цикл по объектам (multi-instance). Выглядит он так:

Рис. 3. Процесс закупки с циклами по объектам

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

Но к сожалению в данном случае цикл по объектам применить не удастся. Его можно использовать только если число объектов известно заранее, до начала цикла. В данном же процессе число заказов сырья в момент заключения договора неизвестно – заказывать будем по мере необходимости. Число поставок по одному заказу более предсказуемо, но тоже не на 100%: доставку осуществляет поставщик, и график доставки может корректироваться.

Стартовые события

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

В случае подпроцесса (как на диаграммах выше) стартовое событие – «отмашка» от процесса/подпроцесса уровнем выше: завершили один подпроцесс, переходим к другому.

Но в данном случае это не так – инициатором является внешнее событие:

• заказ сырья инициируется фактом снижения запасов ниже нормативного минимума
• прием инициируется фактом прихода груза от поставщика
• оплата инициируется платежным календарем (например, еженедельно)

Событие произошло – отрабатываем его; событие не произошло – ничего не делаем. Этот сценарий в BPMN соответствует запуску процесса, а не подпроцесса.

От одного процесса к нескольким

Вывод: закупка – не один, а несколько процессов BPMN:

Рис. 4. Закупка в виде нескольких процессов

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

Недостаток схемы на рис. 4 – на ней не показаны связи между процессами. Это можно исправить:

Рис. 5. Межпроцессное взаимодействие через данные

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

Более существенная проблема – чрезмерная сложность диаграммы на рис. 5. Представьте, что вместо прямоугольника с многоточием мы честно покажем действия, составляющие каждый процесс. Даже если мы покажем только верхний уровень (т.е. ограничимся подпроцессами), диаграмма получится необозримой. В мире BPMN хорошим стилем считаются диаграммы, помещающиеся на одном экране монитора или на одном листе формата А4.

В BPMN процессы можно изображать в виде «черных ящиков», т.е. без содержимого:

Рис. 6. Белые, но на самом деле черные ящики

Гибридная диаграмма DFD-BPMN

Диаграмма на рис. 6 корректна, компактна, но малоинформативна – к сожалению, BPMN не позволяет соединять пулы с потоками данных, поэтому мы не можем показать связь между процессами, как мы это сделали на рис. 5.

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

Диаграмма потоков данных (DFD – data flow diagram) выглядит так:

Рис. 7. Архитектура процесса закупки сырья в нотации DFD

А вот как выглядит та же диаграмма, но построенная с помощью значков BPMN:

Рис. 8. Уровень 1: архитектура процесса закупки в нотации DFD-BPMN

Детализируя ее на уровень ниже, получаем уже честный BPMN. Например, процесс «Заказ сырья»:

Рис. 9. Уровень 2: схема процесса «Заказ сырья»

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

Третий уровень – рабочие инструкции. Например, инструкции исполнителю задачи «Подготовить заказ поставщику» могут выглядеть так:

Рис. 10. Уровень 3: рабочие инструкции задачи «Подготовить заказ поставщику»

Нестандартно, зато дешево, надежно и практично

Ситуация, когда то, что бизнес рассматривает как один бизнес-процесс (в данном случае – процесс закупки сырья), при моделировании в BPMN распадается на несколько процессов, является достаточно частой.

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

Существует несколько нотаций, подходящих для моделирования процессной архитектуры: IDEF0, VAD, DFD. Не вдаваясь в подробности, мне больше нравится последний.

Но две нотации – это или два разных инструмента для моделирования или, как минимум, проблемы интеграции. Чтобы упростить себе жизнь, я моделирую процессную архитектуру в моделере BPMN, но в семантике нотации DFD.

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

Рис. 11. Карта процессов верхнего уровня (DFD-BPMN)

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

Когда нужна архитектура процесса

Всегда ли нужен уровень архитектуры процесса? Нет, не всегда.

В простых случаях процесс в понимании бизнеса – это один процесс BPMN. Примеры:

• увольнение сотрудника
• очередной отпуск
• от командировочного предписания до отчета

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

Большой размер также не является основанием разбивать процесс на несколько. Разбейте его на подпроцессы; если подпроцессы тоже слишком велики, чтобы их охватить взглядом – сделайте подпроцессы второго уровня. Число уровней подпроцессов в BPMN не ограничено.

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

Если модель не складывается, остановитесь и задайте себе вопрос: сколько здесь в действительности процессов BPMN? Пока нет правильного ответа на этот вопрос, к схеме процесса будет возникать много вопросов.

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

• У процесса есть внешние участники – например, поставщик в случае закупки сырья. Он порождает события (в нашем примере закупки сырья это поступление товара), которые порождают процесс. В процессах увольнения, отпуска, командировки все участники процесса внутренние, поэтому их можно смоделировать одним процессом BPMN.
• В процесс вовлечены подразделения с собственным ритмом. Например, в нашем примере это финансисты, которые планируют оплату всей совокупности полученных счетов, чтобы избежать кассовых разрывов и оптимизировать использование финансовых ресурсов.
• У процесса несколько «входных точек». В нашем примере это выбор поставщика и заказ сырья. Вначале, вероятно, они отрабатывают один за другим (мы выбираем поставщика, чтобы заказать у него сырье), но в дальнейшем мы многократно заказываем сырье у уже имеющегося поставщика.

Эти техники мы осваиваем в теории на тренингах BPMN052 или BPMN101, а на практике BPMN102 приходит полное понимание.

Хотите научиться? Бронируйте место на очередном тренинге.