Either your BPMN diagram is executed by BPMS engine or it must be executed by human performers: each performer shall not only execute the assigned task but also route the process to next task and next performer.
As an example, performer A should pass the case either to B or C depending on the result of Task 1 assigned to him:
Performer A should be aware that it’s his/her responsibility not only to perform the task but also to execute the following XOR gateway. He/she should know what the following BPMN element means and how to process it. It’s clear enough in the example above - everyone would guess it’s a gateway - but other BPMN elements are not that obvious.
I would not even try to instruct an employee how to execute e.g. a non-interrupting boundary escalation as well as most other events. Please keep in mind that if you leverage some BPMN element in a diagram that will be human-powered then you’ll have to train every employee how to handle it. You should also be prepared to mistakes mistakes they will inevitably make. This pressures to keep the active BPMN palette as low as possible.
Service & script tasks? You won’t need them - an automatic procedure launched by a user is a user task, not script neither service.
The BPMN elements worth to be recommended for human-powered processes:
- Pool & Lane
- Data Object, Data Store & Data Flow
- Annotation & Association
- Control & Message Flow
- Tasks: User & Manual; no Script, Service, Business Rule, Send & Receive
- Cycles: Multi-Instance is essential; Loop is excessive hence not recommended
- Subprocesses: Embedded & Reusable, Collapsed only (Expanded is not recommended), Ad-Hoc; Event Subprocess is excessive and complicated hence not recommended
- Gateways: Exclusive & Parallel; no Complex, no Event-Based; Inclusive is excessive and non-trivial hence better to be avoided
- Events: None, Timer, Message (including attached interrupting and non-interrupting), Terminate, Error
- our of scope altogether: Transactions, Compensations & Cancellations
Update: consider leaving send & receive message tasks and message events out of the human-powered BPMN palette. Read more about BPMN messages >>
As we can see, only a handful of BPMN elements are suitable for human-powered processes.
On the other hand, it’s surprising how much can be modelled even with that limited palette. In fact, the better you are in BPMN, the less elements you are using on day-to-day basis.
Действительно, в последнее время BPMN начинают использовать для моделирования бизнес-процессов (неудивительно!), но не до конца отдают себе отчёт в том, что данная нотация является весьма строгой. Другими словами, BPMN определяет семантику своих элементов глубже и точнее, чем многие другие нотации (включая UML). Незнание семантики BPMN-элементов приведёт к разночтениям и конфликтам.
Тема, которую поднял Анатолий, связана с вопросом: “а кто является оркестратором (оркестровщиком)?”. Ответ на этот вопрос читателю BPMN-диаграммы должен быть понятен из содержания самой диаграммы. По сути, есть два вида исполнителя в бизнес-процессе: человек и машина. Когда мы проектируем бизнес-процесс (требуемое поведение), нужно точно определить, кто будет исполнителем того или иного BPMN-элемента, и показать это на диаграмме.
Также важно понимать, что в поток управления, пересекающий границы дорожки, вкладывается смысл взаимодействия двух исполнителей, то есть момент в процессе, когда один исполнитель передаёт ответственность за дальнейший ход процесса, а другой её принимает. Это места потенциального “провала” процесса, где процесс может “застрять” в “щели” между исполнителями. Для таких мест следует убедиться в том, что протокол приёма-передачи обеспечивает устойчивость процесса.
Я не до конца понимаю, согласованы ли в статье диаграмма и текст. Я бы прочитал диаграмму так:
1. Performer A выполняет действие Task 1 и передаёт результаты Performer B.
2. Performer B получает “эстафетную палочку” от Performer A и, если OK, то выполняет действие Task 2, а если не OK, то передаёт результаты Performer C.
3. Performer C получает “эстафетную палочку” от Performer B и выполняет действие Task 3.
То есть маршрутизацию осуществляет именно Performer B, а не Performer A, как это указано в статье.
По составу элементов, рекомендуемых для использования в “процессах, которые будут исполняться без движка”.
1. Предложен поток сообщений, но почему-то исключена задача приёма сообщения. Как показывать обработку таймаута ожидания сообщения? Почему исключена Recieve Task?
2. Насчет “и/или”-шлюза. Чем большее количество исходящих потоков управления предполагается после “и/или”-шлюза, тем более сложной комбинацией “и”- и “или/или”-шлюзов нужно, чтобы отразить нужное ветвление. А ещё слияние… Не думаю, что “или/или” семантика настолько сложна, чтобы её исключать.
3. В событиях отсутствует сигнал, который применяется для всякого рода широковещательных уведомлений (например, пожарная тревога или рассылка по открытому списку). Зачем исключать событие-сигнал?
Спасибо за статью!
Владимир
Согласно стандарту, “Lanes are used to organize and categorize Activities within a Pool” (v.2.0.2, p.305). Т.е. дорожки имеют отношение только к задачам и подпроцессам; на какой дорожке расположены развилки и события - роли не играет, они просто нарисованы на дорожке, но фактически не связаны с ней.
По элементам:
1. Send/Receive Task мало чем отличается от Message Event. Элемент дублирования, но можно включить, согласен.
2. Схема получится чуть сложнее, зато никому ничего не придется объяснять.
3. Я плохо себе представляю как человек будет отрабатывать событие-сигнал. Ему для этого надо знать обо всех запущенных экземплярах процессов, ожидающих данный сигнал, притом вообще говоря относящихся к разным шаблонам. Как исполнителя такому инструктировать? Разве что включить пожарную сирену - это понятно и соответствует семантике сигнала. Но это экзотика.
Отличная заметка! Давно хотелось как-то однозначно объяснить, чего не хватает в рисованных процессах. И вот мысль оформилась)
По элементам нотации я бы оставила самый минимум, чтобы не было разночтений.
Дело в том, что в BPMS движок один. И он всегда трактует одинаковые элементы однозначно. А в “ручных” процессах движков столько, сколько сотрудников. Это как автомобиль с двигателем 100 л.с. или с сотней двигателей по 1 л.с. Но будут ли это 100 двигателей работать абсолютно одинаково? Особенно если они разных марок. А сотрудники точно разных “марок”)))
Короче, прямо много мыслей сразу родилось по этому поводу. Очень понравилась сама идея!
Спасибо. В следующей заметке хочу рассказать какие элементы являются строго необходимыми, а какие можно заменить другими. Например, прикрепленные обработчики (как прерывающие, так и непрерывающие) являются избыточными, как и развилка по событиям.
Анатолий, спасибо за статью. На схемах рисовал условия как раз на дорожках, не относящиеся к дорожке на которой они нарисованы - видимо интуитивно применил правила, которые вы напомнили. Очень жду следующую заметку с набором строго необходимых элементов.
Заранее спасибо.
Анатолий
в спецификации BPMN поведение процесса определяется (v.2.0, стр.27) с использованием 3-х BPMN-элементов: события (Evernts), действия (Activities) и шлюзы (Gateways). При этом:
1) BPMN-событие показывает поведение, в соответствии с которым либо ожидаются определённые условия (обрабатывающее событие), либо уведомляется, что определённые условия сложились (инициирующее событие);
2) BPMN-шлюз показывает поведение, когда осуществляется разветвление или слияние потоков управления, и это поведение может быть довольно сложным (см. complex gateway);
3) BPMN-действие показывает выполнение работы в процессе.
Из всего этого следует, что поведение процесса - это не только действия, но и также события и шлюзы.
Пока исполнителем (оркестратором) BPMN-схемы является BPMS – не имеет значения, на какой дорожке (Lanes) какой BPMN-элемент размещён. Именно потому, что исполняет эти элементы сама BPMS. Но если мы говорим о “ручном” исполнении BPMN-схемы, то здесь подразумевается столько исполнителей, сколько определено дорожек в пуле. И каждый исполнитель должен вести себя так, как предписывают ему элементы его дорожки. Переход потока управления от элемента одной дорожки к элементу другой дорожки обретает дополнительный смысл: он показывает передачу достигнутых результатов и дальнейшей ответственности за ход процесса между исполнителями. И становится весьма важно то, как именно мы распределяем nonActivity-элементы (т.е. события и шлюзы) по дорожкам.
Например, в приведённой в статье BPMN-схеме, с моей точки зрения, отражено следующее поведение (я показывал это в предыдущем комментарии):
1. Performer A выполняет действие Task 1 и передаёт результаты Performer B.
2. Performer B получает “эстафетную палочку” от Performer A и, если OK, то выполняет действие Task 2, а если не OK, то передаёт результаты Performer C.
3. Performer C получает “эстафетную палочку” от Performer B и выполняет действие Task 3.
То есть маршрутизацию осуществляет именно Performer B, а не Performer A, как это указано в статье (”Исполнитель A должен отдавать себе отчет, что он отвечает за исполнение не только задачи, но и следующей за ней развилкой “или-или”).
Неопределённость выбора исполнителя для выполнения предписанного диаграммой поведения становится более очевидной, когда используются такие BPMN-элементы как события. Попробуйте разместить временное событие (таймер) или отправку/ожидание сообщения, игнорируя дорожки (Lanes). Не получится, потому что вы должны точно указать, кто именно должен выполнять данное поведение (ждать/отправлять).
Таким образом, для ситуаций, когда BPMN-диаграмма определяет работу исполнителей, которую координируют они сами (т.е. без BPMS), нужны дополнительные ограничения. Например, такие:
1) дорожка (Lane) является контейнером BPMN-элементов, определяющий поведение процесса: не только действия (Activity), но события (Events) и шлюзы (Gateways);
2) переход потока управления между дорожками означает передачу необходимых результатов и ответственности за дальнейший ход процесса от одного исполнителя к другому.
На самом деле, BPMN-спецификация (v.2.0) указывает, что при использовании дорожек, элементы поведения размещаются именно на дорожках:
1. Стр.338, рис.10.126 и последующее описание. Если используются дорожки, то для BPMN-диаграммы показывается размещение BPMN-элементов (FlowNode) именно на дорожке (Lane), а не просто в процессе (Pool), для чего используются ссылки (flowNodeRefs) на эти элементы.
2. Как на схеме (стр.338, рис.10.126), так и в примерах (стр.170, таб.10.19) видно, что к дорожке (Lane) относятся не только действия (Activities), но и все остальные включаемые в поток управления (FlowNode) BPMN-элементы: события (Events) и шлюзы (Gateways).
Поэтому фраза (стр. 306) “Lanes are used to organize and categorize Activities within a Pool” скорее похожа на словесное обобщение (”дорожки - для группировки поведения”), чем на точную спецификацию того, что размещается на дорожке (Lane).
В любом случае, наше обсуждение в комментариях показывает, что в соглашении о моделировании весьма важно установить (и убедиться, что исполнители это поняли!): 1) как определяется лицо, ответственное за выполнение поведения, определённого BPMN-элементом (в т.ч. события и шлюза), и 2) как это лицо должно заданное поведение выполнить. А будет ли это прямая интерпретация (исполнитель выполняет всё, что на его дорожке) или относительная интерпретация (исполнитель выполняет своё действие и все элементы, которые есть в потоке управления до следующего действия) - это уже второй вопрос.
Начнем с того, что дорожка не определяет исполнителя - ее значимость на уровне комментария. По-настоящему исполнитель задается в атрибутах задачи. Сюрприз?
У задачи атрибут “исполнитель” имеется, а есть ли он у события или развилки? Проверять лень, но думаю - нет, такого атрибута там нет. Вот и делайте вывод.
И это не мое открытие - сие знание я почерпнул у Брюса Силвера, который принимал непосредственное участие в разработке спецификации.
Анатолий,
при дальнейшем обсуждении было бы хорошо определиться, о чём мы говорим. Насколько я понял, речь идёт о BPMN-диаграммах “на бумаге”, а не об XML-файлах *.bpmn, которые выполняет BMPS-движок. Если речь идёт о первом случае, то у исполнителей есть бумажки с BPMN-диаграммами, где на дорожках указаны роли. Никаких атрибутов и сюрпризов. Попробуйте объяснить людям, у которых на руках BPMN-схемы процессов, что “дорожка не определяет исполнителя - ее значимость на уровне комментария”. Народ просто зависнет!
У меня нет сомнений, что машина корректно исполнит BPMN-диаграмму, невзирая на дорожки. Но, насколько я понял Вашу статью, Вы говорите о ситуации, когда исполнителями (интерпретаторами диаграммы) являются люди. Как раз наш случай – два человека (Вы и я) одну и ту же диаграмму в статье воспринимаем по-разному, причём эти различия в весьма важной области: кто именно делает то, что предписано. Вот это и есть проблема, поскольку разделение ответственности – извечный предмет производственных споров. И swimlanes-концепция успешно помогает их решить: получив мяч, делай то, что на твоей дорожке, и перебрасывай мяч дальше.
Согласен, что набор элементов важен для моделирования. Но единство понимания людей при определении ответственности за работу, показанную на BPMN-диаграмме, ничуть не менее важно. На мой взгляд.
Между BPMN-диаграммами “на бумаге” и BPMN-диаграммами в движке есть еще вариант BPMN-диаграмм в моделере, причем он как бы самый распространенный.
Так вот, при работе в моделере аналитик не только рисует картинку, но и задает атрибуты, в частности - исполнителей задач. На картинке их не видно, но любой приличный моделер умеет экспортировать в word, pdf или гипертекст, и там наряду со схемой будет описание, в котором и отобразятся исполнители, а равно и другие атрибуты - например, нормативная продолжительность задачи.
Нравится вам это или нет, но стандарт четко говорит, что “настоящий исполнитель” задается на уровне задачи, а не дорожкой.
Причем это правильно! Я видел продукты, которые отступили от этого правила и задавали исполнителя через дорожку. Получилось плохо: диаграмма вырождалась в то, что на каждой дорожке располагалось по одной задаче. Дело в том, что задачи, у которых в первом приближении исполнитель один (рисуем дорожку: бухгалтерия), при ближайшем рассмотрении они оказываются разными (в атрибутах задачи указываем: рядовой бухгалтер, старший бухгалтер или “тот же бухгалтер, который рассматривал документ в первый раз”).
Еще один очень важный атрибут задачи, про который начинающие аналитики зачастую не знают - ее описание, в которое следует поместить детальную инструкцию для исполнителя. Без этого модель процесса нельзя считать полной, а работу аналитика - выполненной.