В статье «Почему Visio не годится для BPMN» я писал, что грамотная модель бизнес-процесса в нотации BPMN должна быть двухуровневой:
… на уровне графической диаграммы сконцентрироваться на том, что и в какой последовательности надо сделать, чтобы добиться требуемого результата – то есть на «квадратиках», «стрелочках» и «ромбиках». Документы и данные изображать не все и не тотально, а только те и там, где эта информация действительно важна для понимания логики процесса.
Все остальное – состав исполнителей, инструкции исполнителю, состав реквизитов, нормативные сроки, стоимости и другие атрибуты – тоже важны и в конечном счете должны быть определены, но не надо пытаться изобразить все это на диаграмме. Помните, что у значков на диаграмме есть свойства. Например, инструкцию исполнителю можно и нужно подробно расписать в описании задачи. Не надо рисовать несколько квадратиков в ряд, расписывая последовательность действий одного исполнителя, замените их одним квадратиком и инструкцией исполнителю в виде текста.
Процитированное выше – правда, но не вся. На самом деле уровней три:
- архитектура процесса
- схема процесса
- рабочие инструкции процесса
Выше речь шла об уровнях 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 приходит полное понимание.
Хотите научиться? Бронируйте место на очередном тренинге.
