Если вы взялись за достаточно сложный бизнес-процесс, то скорее рано, чем поздно вы столкнетесь с тем, что схема процесса разрослась и стала нечитаемой. Это значит, что пришла пора выполнить иерархическую декомпозицию - проще говоря, разбить процесс на подпроцессы. На BPMN распространяется старое правило: на одном уровне декомпозиции желательно иметь от 5 до 9 активностей.

Рассмотрим в качестве примера процесс заключения договора, состоящий из трех фаз:

1. согласование содержательных условий договора
2. согласование текста договора
3. подписание договора

Зачастую приходится встречать наивные процессные диаграммы типа следующей:

» читать дальше

Определение 1: оркестровка (orchestration) - это диаграмма, показывающая последовательность выполнения активностей, координируемых из одного центра.

Примечания:

• Синонимами оркестровки являются поток работ (workflow) и, собственно, процесс.
• В BPMN оркестровка моделируется развернутым пулом (white-box pool), при этом на диаграмме могут опционально присутствовать внешние сущности, моделируемые свернутыми пулами (black-box pool).
• Формулировка “координируемых из одного центра” означает, что, даже если процесс на каком-то шаге распараллеливается, исполнение разных ветвей процесса остается координированным: они могут в дальнейшем синхронизироваться в сходящейся развилке, а процесс в целом завершится тогда, когда завершатся все ветви.

Определение 2: межпроцессное взаимодействие (collaboration) - это диаграмма, показывающая взаимодействие между потоками работ.

Примечания:

• В BPMN 1.x межпроцессное взаимодействие называлось хореографией (choreography). В BPMN 2.0 хореографией стал называться новый, отдельный вид диаграммы, а то, что раньше называлось choreography, теперь называется collaboration. Такие дела.
• На диаграмме межпроцессного взаимодействия отображается больше одного развернутого пула (white-box pool).
• Межпроцессное сообщение иногда сводят к обмену сообщениями (message), но в общем случае процессы могут взаимодействовать при помощи сообщений (message), сигналов (signal) и/или данных (data store, conditional event).
• Отдельные процессы на диаграмме межпроцессного взаимодействия исполняются в целом независимо, за исключением явно обозначенных точек синхронизации - отправки и получения сообщения/сигнала, записи/чтения данных.

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

Тут встречаются две крайности:

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

Рис.1 Антипаттерн “Сообщения вместо подпроцесса”

Обычные аргументы в пользу такой схемы:

• “Вызываемый процесс выполняется другим подразделением.” - Чтобы показать исполнителя, пользуйтесь дорожками (swimlane), а не пулами.
• “Вызываемый процесс можно использовать где-нибудь еще.” - Как и повторно-используемые (reusable) подпроцессы.
• “Явно видна связь между вызывающим и вызываемым процессом.” - Во-первых, развернутый подпроцесс не менее нагляден:

Рис.2 Развернутый подпроцесс

• А во-вторых, диаграмма с грамотно выделенными уровнями абстракции вполне обходится свернутыми подпроцессами: когда мы смотрим на процесс верхнего уровня, мы должны понимать его логику без знания деталей подпроцессов. Содержимое подпроцесса будет изображено на отдельной странице, и это правильно:

Рис.3 Свернутый подпроцесс

Конечно это вопрос не корректности, а стиля - диаграмма на рис.1 формально корректна. Но я считаю, что это антипаттерн и изобретение велосипеда, потому что сообщениями тут смоделировано то же поведение, которое встроено в вызов подпроцесса:

• когда поток управления доходит до подпроцесса, появляется токен в подпроцессе, а вызывающий процесс переходит в состояние ожидания
• когда подпроцесс завершается, вызывающий процесс продолжает работу

Резюмируя, вот мои правила для оптимального баланса между оркестровкой и межпроцессным взаимодействием:

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

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

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

Иво Величков заставил меня обратить внимание на разницу между BPMN 1.x и BPMN 2.0 в части моделирования обмена данных.

Обмен данными в BPMN 1.x моделируется при помощи объектов данных (Data Objects):

Рис. 1 Объекты данных в BPMN 1.x

Объект данных в рамках BPMN 1.x  - это артефакт, помогающий описывать процессы. При помощи ассоциации (association) его можно связать с задачей (task), потоком управления (control flow) или сообщением (message flow), при этом никакого воздействия на них он оказывать не будет.

Объектом данных можно изображать самые разнообразные объекты, физические или электронные. Например, мы имеем право изобразить объект данных вне пула и назвать его “база данных заказов”, чтобы смоделировать таким способом межпроцессное взаимодействие через данные.

Однако, как справедливо указал Иво, в рамках BPMN 2.0 приведенная выше диаграмма становится некорректной!

Дело в том, что в BPMN 2.0 объект данных привязан к контексту процесса: он изображается внутри процесса или подпроцесса и существует только в интервале времени от момента запуска экземпляра процесса  (подпроцесса) до его завершения. Соответственно, доступ к ним из другого внешнего процесса невозможен.

Для изображения персистентных данных, не привязанных к жизненному циклу процесса, в BPMN 2.0 служит хранилище данных (Data Store). Его и надо использовать для моделирования межпроцессного взаимодействия через данные в BPMN 2.0:

Рис. 2. Объекты и хранилища данных в BPMN 2.0

BPMN 2.0 различает единичные объекты данных и коллекции (collection) - последние помечаются специальным маркером. В нем также введены специальные обозначения для данных-входов и данных-выходов (Data Input, Data Output) и новые элементы - наборы входных и выходных данных (Input Sets, Output Sets).

BPMN 2.0 также определяет ассоциацию по данным (Data Association) в добавок к обычной ассоциации (Association), унаследованной из 1.x. Если обычная ассоциация, как и в BPMN 1.x, служит чисто для целей документирования, то ассоциация по данным является “исполняемой”: вы можете определить для нее на уровне атрибутов модели процесса входные и выходные данные и, опционально, трансформацию. Таким образом можно на уровне диаграммы описать манипуляции с данным при старте и завершении активности, отправке или получении сообщения. Изображаются на диаграмме ассоциации по данным так же, как и обычные - точечным пунктиром с V-образной стрелкой.

В спецификации BPMN 2.0 есть небольшое противоречие, относящееся к ассоциации по данным:

• На странице 221 говорится, что ассоциация по данным используется с объектами данных, причем хранилища данных при этом не упоминаются. Учитывая, что объекты данных обязаны принадлежать процессу, из этого можно сделать вывод, что ассоциация по данным не может пересекать за границы пула. Такое правило сделало бы вторую диаграмму некорректной - см. комментарий Иво Величкова.
• Но на стр. 208 спецификации совершенно определенно говорится, что хранилище данных может служить входом или выходом для ассоциаций по данным.

Так что я все же полагаю, что схема на рис.2 является корректной.

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

Это третья и завершающая часть исследования на тему управления кросс-функциональными процессами. Предыдущие части:

1. Вульгарное представление о кросс-функциональных бизнес-процессах
2. Кросс-функциональные паттерны

Во второй части мы рассмотрели два основных способа организации работы смежных участков в рамках кросс-функционального бизнес-процесса:

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

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

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

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

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

Как же примирить эти точки зрения? Попробуем дать рекомендации по выбору оптимальной схемы работы,

» читать дальше

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

Напомню: в первой части речь шла о том, что кросс-функциональные процессы, как правило, невозможно реализовать, пользуясь только оркестровкой (иными словами, оставаясь в пределах одного пула BPMN). Границы между подразделениями существуют объективно, отражая различия в порядке и ритме работы, характерные для разных видов деятельности. Эти различия приводят к тому, что фрагменты процесса, выполняемые каждым подразделением, технически реализуются отдельными пулами, а кросс-функциональный процесс целиком - совокупностью пулов, взаимодействующих через сообщения или данные.

В данной статье мы рассмотрим паттерны, характерные для кросс-функциональных процессов.

Воспользуемся следующим примером:

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

В простейшем виде процессная диаграмма может выглядеть так:

» читать дальше

К сожалению, вопрос “как в BPMN моделировать решения, принимаемые людьми” не относится к числу часто задаваемых.

“К сожалению” потому, что ответ, который новичку кажется очевидным, на самом деле неправилен. Это вот не развилка, это распараллеливание процесса:

На выходе из задачи “Рассмотреть заявку” процесс продолжится параллельно по исходящим ветвям вне зависимости от того, что на них написано.

Правильная BPMN-диаграмма выглядит так:

При этом подразумевается, что у процесса есть атрибут “Одобрено” типа boolean. Пользователь на шаге “Рассмотреть заявку” задает значение этого атрибута, а в развилке оно проверяется, и процесс продолжается по одной из ветвей.

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

Пользовательский интерфейс для шага, на котором принимается решение, выглядит примерно так:

По кнопке “Выполнено” форма закрывается, и задача считается выполненной.

Я согласен с мнением Кейта Свенсона, что отказ от явной поддержки в BPMN решений, принимаемых человеком, был неудачным ходом.

Во-первых, глядя на BPMN-диаграмму, мы не можем сходу определить где в процессе автоматическая развилка, а где - решение человека. А это достаточно важный аспект процесса.

Будь моя воля, я бы ввел в BPMN явную поддержку решений, принимаемых людьми. Так как первая диаграмма вверху на самом деле интуитивно больше походит на принятие решения, чем правильная BPMN-диаграмма, я бы оттолкнулся от нее:

Здесь к существующим типам потока управления Control Flow, Conditional Flow и Uncontrolled Flow добавлен еще один: Human Controlled Flow, помеченный двойной поперечной черточкой.

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

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

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

Впрочем, такой подход можно ведь практиковать и для стандартных BPMN-диаграмм:

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

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

Группа на последнем моем BPMN-тренинге хорошо поработала и довела до логического конца два бизнес-процесса: «Внедрение обновления учетной системы» и «Доработка учетной системы». Смотреть тут.

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

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

Во втором процессе группа эффективно использовала один из двух, пожалуй, самых полезных процессных паттернов - пакетную обработку. Обратите на него внимание: он показан к применению везде, где вы сталкиваетесь с ситуацией выполнения множества заказов/работ одним ресурсом.

Внимание, тест!

Вопрос: какие элементы BPMN позволяют моделировать межпроцессное взаимодействие (отметьте все правильные варианты ответа) -

1. поток управления (sequence flow)
2. сообщение (message flow)
3. сигнал (signal event)
4. триггер по данным (conditional event)
5. ассоциация (association)

Ответ: кликните, чтобы увидеть правильные варианты ответа

Комментарии к ответам:

» читать дальше

Рассмотрим процессную диаграмму, позаимствованную мною (с некоторыми упрощениями) из книги Stephen White, Derek Miers, “BPMN Modeling And Reference Guide” (стр. 113):

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

Сложность тут в том, что мы не можем реализовать эту логику при помощи потока управления (sequence flow), так как он не может пересекать границы подпроцессов. (Оставим в стороне вопрос зачем нам тут понадобились подпроцессы; будем считать, что зачем-то они нужны.) Сообщения (message) использовать тоже нельзя, так как мы находимся в пределах одного пула.

Стандартная рекомендация - использовать в подобной ситуации механизм сигналов BPMN (signal event):

• когда концепция готова, первый подпроцесс шлет соответствующий сигнал
• второй процесс до этого момента находится в ожидании сигнала; получив его, он переходит к задаче “Разработать дизайн обложки”

Это так называемый процессный паттерн “этап” (milestone). Аналогичный пример использования сигнала BPMN приведен в книге Bruce Silver, “BPMN Method and Style” (стр. 98).

В чем тут подвох?

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

Для того, чтобы приведенная диаграмма сработала, нам необходимо как-то ограничить распространение сигнала. Как это можно было бы сделать?

1. Первое, что приходит в голову - предусмотреть атрибут сигнала, который будет ограничивать его распространение границами данного экземпляра процесса. Но к сожалению, такого атрибута стандарт не предусматривает. Причем если в рамках BPMN 1.x еще можно сказать, что это вопрос реализации, то в BPMN 2.0 метамодель процесса специфицирована полностью. Смотрим страницу 281 документа OMG, датированного июнем 2010 г.: у сигнала есть единственный атрибут - имя. Значит, сигнал всегда будет распространятся по всем экземплярам процесса.
2. Что ж, раз у сигнала есть только имя, то будем использовать то что есть. Рассматриваемая схема сработает, если мы сможем динамически, т.е. в процессе исполнения процесса, задать его имя. Если имя сигнала будет не “Концепция готова”, а “Процесс 9999 Концепция готова”, то все будет в порядке. Но это, конечно, приемчик так себе, и рассчитывать на него сложно. Движки BPMS позволяют что-то менять в процессе исполнения (например, задавать время срабатывания таймера), но название - вряд ли.

Почему это важно.

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

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

Выводы:

1. В стандарте BPMN не хватает атрибута, ограничивающего распространение сигнала.
2. В отсутствии стандартного способа ограничить распространение сигнала для реализации процессного паттерна “этап” следует использовать сообщения.

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

Я рекомендую чуть более изощренную схему:

При этом содержание заданий “Сделать” и “Переделать” может не отличаться, т.е. разница только в названиях. В чем смысл:

• В первом случае сотрудник видит у себя в списке задач, условно говоря, “Сделать дело”. Делает его, жмет на кнопку и… через 15 минут снова видит у себя эту же задачу, относящуюся к этому же экземпляру процесса. Это сбивает с толку, особенно если за эти 15 (или 30, или 130) минут он успел позаниматься какими-то другими делами.
• Еще вторая схема лучше с точки зрения мониторинга: в ней легко посчитать число переделок и потраченное на них время и бороться за то, чтобы свести их к нулю. Положим, число переделок можно подсчитать и в первой схеме - просто вычесть из числа исполнений задачи число экземпляров процессов. Но суммарное потраченное время (т.е. неоправданные затраты) в первой схеме подсчитать будет затруднительно.

Вот такой получился паттерн: почти тривиальный, но зато (или как раз поэтому?) потенциально широко применимый.