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

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

Рассмотрим процесс выдачи банковской карты клиенту:

Рис. 1. Выдача банковской карты с «пассивной» задачей «Выдать карту».

Обратим внимание на задачу «Выдать карту». Бизнес-сценарий: после того как карта изготовлена, клиент в течение 45 дней должен прийти в отделение банка и получить ее. Если считать, что в среднем клиент приходит за картой через 10 дней, и что отделение выдает по 100 карт в день, то у банковского клерка скопится очередь из 1000 задач. » читать дальше

Напомню, что дорожки (lane в BPMN 2.0, swimlane в BPMN 1.x) изображают исполнителей процесса.

Правила для дорожек:

1. Дорожки опциональны – диаграмма может обходиться без них.
2. Дорожки могут быть вложенными (иерархическими).
3. Семантика дорожек может быть любой, на усмотрение автора диаграммы – подразделение, роль, должность…
4. Встроенные подпроцессы (embedded subprocesses) не имеют пулов и, следовательно, не могут иметь дорожек.
5. Дорожки имеют отношение только к задачам, исполняемым людьми (user task) – автоматическим задачам (service task, script task), подпроцессам, развилкам, событиям все равно на какую дорожку вы их поместили.
6. Даже для задач, назначаемых людям, дорожки по сути является комментариями – реальный исполнитель задается в атрибутах модели для данной задачи.

Начинающие пользователи BPMN любят дорожки и с энтузиазмом рисуют их в своих первых  диаграммах:

Рис.1. BPMN-диаграмма с дорожками.

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

Рис.2. BPMN-диаграмма, на которой показан магистральный путь процесса.

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

Дело в том, что существует универсальное правило, применимое к любой нотации, не только BPMN: число активностей на одном уровне диаграммы не должно превосходить 7-9. Иначе схему становится сложно воспринимать:

Рис.3. “Плоская” диаграмма с большим числом активностей сложна для понимания.

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

Рис.4. С помощью подпроцессов сложный процесс можно изобразить в виде простой диаграммы.

Однако в этом стиле моделирования для дорожек не остается места:

• На верхнем уровне остаются только подпроцессы, а дорожки относятся только к задачам, исполняемым людьми (правило 5).
• На схеме подпроцесса нет ни пула, ни дорожек (правило 4).

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

Если вам так уж необходимо показать исполнителей на схеме встроенного подпроцесса, используйте BPMN-артефакт «группа»:

Рис.5. Исполнители во встроенном подпроцессе изображены группами.

Если вы взялись за достаточно сложный бизнес-процесс, то скорее рано, чем поздно вы столкнетесь с тем, что схема процесса разрослась и стала нечитаемой. Это значит, что пришла пора выполнить иерархическую декомпозицию - проще говоря, разбить процесс на подпроцессы. На 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 является корректной.

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

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

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

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

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

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

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

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

Мой приятель занимается процессами в телекоме. Там есть своя специфика, о которой я уже писал раньше: много координации между системами и относительно небольшое участие человека.

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

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

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

b) Появление на радаре обьекта пришельца регистрируется и реплицируется в систему слежения напарника - на основании этого каждая цель получает свой индивидуальный id. Потерянная обоими цель получает статус потеряна - средств идентификации старая потерянная или новая нет.

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

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

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

Считается, что весь процесс постоянный и непрерывный.

Не совсем обычное применение для BPMN, не правда ли? В связи с этим вопросы залу:

• можно ли решить эту задачу средствами BPMN?
• стоит ли?
• ну и само решение, если есть.

По-моему, задача достаточно интересная; во всяком случае, меня самого она заинтриговала.

Мой вариант BPMN-диаграммы (кликните, чтобы открыть в отдельном окне):

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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