Вашу диаграмму BPMN исполняет либо движок BPMS, либо исполнители-люди: каждый исполнитель должен не только выполнить назначенную ему задачу, но и маршрутизировать процесс к следующей задаче и следующему исполнителю.
В качестве примера, исполнитель A должен передать эстафетную палочку либо B, либо C в зависимости от результатов выполнения назначенной ему задачи Task 1:
Исполнитель A должен отдавать себе отчет, что он отвечает за исполнение не только задачи, но и следующей за ней развилкой “или-или”. Он должен знать и понимать что означает следующий элемент и как его обрабатывать. В примере выше это достаточно очевидно - догадаться, что это развилка, способен каждый - но другие элементы BPMN не столь очевидны.
Например, я не возьмусь учить сотрудников как исполнить, например, непрерывающий обработчик эскалации, впрочем как и большинство других событий. Помните, что если вы используете в своей диаграмме какой-либо элемент BPMN, вам придется обучить каждого сотрудника как с ним обращаться. Вы также должны быть готовым к тому, что они будут ошибаться. Это толкает к тому, чтобы минимизировать количество используемых элементов.
Задачи на вызов сервиса, задачи на выполнение сценария? Забудьте, они вам не понадобятся; автоматическая процедура, запускаемая пользователем - это пользовательская задача, а не сценарий или сервис.
Элементы BPMN, которые можно рекомендовать для использования в процессах, которые будут исполняться без движка:
- пулы и дорожки
- объекты данных, хранилища данных, потоки данных
- аннотации и ассоциации
- потоки управления и потоки сообщений
- задачи: пользовательские и ручные; никаких сценариев, сервисов, бизнес-правил, отправки и получения сообщений
- цикл по объектам необходим; стандартный цикл избыточен и поэтому не рекомендуется
- подпроцессы: встроенные и повторно-используемые, только свернутые (развернутые не рекомендуются), “по требованию”; подпроцессы-обработчики избыточны, сложны и поэтому не рекомендуются
- развилки: “или-или”, “и”; никаких комплексных и по событиям; развилки “и/или” избыточны и нетривиальны и поэтому не рекомедованы
- события: простое, таймер, сообщение (включая прикрепленные прерывающие и непрерывающие), останов, ошибка
- полностью за рамками: транзакция, компенсация, отмена
Дополнено: задачи-сообщения и события сообщения лучше оставить за рамками сокращенной палитры. Подробнее о сообщениях в BPMN >>
Как видим, лишь небольшое число элементов BPMN пригодны для использования в схемах процессов, которые будут исполняться вручную.
С другой стороны, поразительно как много можно смоделировать даже со столь ограниченной палитрой. Чем более профессиональны вы в BPMN, тем меньше элементов вы используете на постоянной основе.
Действительно, в последнее время 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 или гипертекст, и там наряду со схемой будет описание, в котором и отобразятся исполнители, а равно и другие атрибуты - например, нормативная продолжительность задачи.
Нравится вам это или нет, но стандарт четко говорит, что “настоящий исполнитель” задается на уровне задачи, а не дорожкой.
Причем это правильно! Я видел продукты, которые отступили от этого правила и задавали исполнителя через дорожку. Получилось плохо: диаграмма вырождалась в то, что на каждой дорожке располагалось по одной задаче. Дело в том, что задачи, у которых в первом приближении исполнитель один (рисуем дорожку: бухгалтерия), при ближайшем рассмотрении они оказываются разными (в атрибутах задачи указываем: рядовой бухгалтер, старший бухгалтер или “тот же бухгалтер, который рассматривал документ в первый раз”).
Еще один очень важный атрибут задачи, про который начинающие аналитики зачастую не знают - ее описание, в которое следует поместить детальную инструкцию для исполнителя. Без этого модель процесса нельзя считать полной, а работу аналитика - выполненной.