Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

BPMN с ручным приводом

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

В качестве примера, исполнитель A должен передать эстафетную палочку либо B, либо C в зависимости от результатов выполнения назначенной ему задачи Task 1:

Исполнитель A должен отдавать себе отчет, что он отвечает за исполнение не только задачи, но и следующей за ней развилкой “или-или”. Он должен знать и понимать что означает следующий элемент и как его обрабатывать. В примере выше это достаточно очевидно - догадаться, что это развилка, способен каждый - но другие элементы BPMN не столь очевидны.

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

Задачи на вызов сервиса, задачи на выполнение сценария? Забудьте, они вам не понадобятся; автоматическая процедура, запускаемая пользователем - это пользовательская задача, а не сценарий или сервис.

Элементы BPMN, которые можно рекомендовать для использования в процессах, которые будут исполняться без движка:

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

Дополнено: задачи-сообщения и события сообщения лучше оставить за рамками сокращенной палитры. Подробнее о сообщениях в BPMN >>

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

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

10.01.17 | Статьи |    

Комментарии (9)

  1. Владимир 11.01.17 16:10

    Действительно, в последнее время 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. В событиях отсутствует сигнал, который применяется для всякого рода широковещательных уведомлений (например, пожарная тревога или рассылка по открытому списку). Зачем исключать событие-сигнал?

    Спасибо за статью!

  2. Anatoly Belychook 11.01.17 16:39

    Владимир

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

  3. Юлия 13.01.17 14:29

    Отличная заметка! Давно хотелось как-то однозначно объяснить, чего не хватает в рисованных процессах. И вот мысль оформилась)
    По элементам нотации я бы оставила самый минимум, чтобы не было разночтений.
    Дело в том, что в BPMS движок один. И он всегда трактует одинаковые элементы однозначно. А в “ручных” процессах движков столько, сколько сотрудников. Это как автомобиль с двигателем 100 л.с. или с сотней двигателей по 1 л.с. Но будут ли это 100 двигателей работать абсолютно одинаково? Особенно если они разных марок. А сотрудники точно разных “марок”)))
    Короче, прямо много мыслей сразу родилось по этому поводу. Очень понравилась сама идея!

  4. Anatoly Belychook 13.01.17 14:43

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

  5. Илья 16.01.17 11:27

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

  6. Владимир 16.01.17 15:47

    Анатолий

    в спецификации 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) как это лицо должно заданное поведение выполнить. А будет ли это прямая интерпретация (исполнитель выполняет всё, что на его дорожке) или относительная интерпретация (исполнитель выполняет своё действие и все элементы, которые есть в потоке управления до следующего действия) - это уже второй вопрос.

  7. Anatoly Belychook 16.01.17 16:06

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

    У задачи атрибут “исполнитель” имеется, а есть ли он у события или развилки? Проверять лень, но думаю - нет, такого атрибута там нет. Вот и делайте вывод.

    И это не мое открытие - сие знание я почерпнул у Брюса Силвера, который принимал непосредственное участие в разработке спецификации.

  8. Владимир 16.01.17 17:15

    Анатолий,

    при дальнейшем обсуждении было бы хорошо определиться, о чём мы говорим. Насколько я понял, речь идёт о BPMN-диаграммах “на бумаге”, а не об XML-файлах *.bpmn, которые выполняет BMPS-движок. Если речь идёт о первом случае, то у исполнителей есть бумажки с BPMN-диаграммами, где на дорожках указаны роли. Никаких атрибутов и сюрпризов. Попробуйте объяснить людям, у которых на руках BPMN-схемы процессов, что “дорожка не определяет исполнителя - ее значимость на уровне комментария”. Народ просто зависнет!

    У меня нет сомнений, что машина корректно исполнит BPMN-диаграмму, невзирая на дорожки. Но, насколько я понял Вашу статью, Вы говорите о ситуации, когда исполнителями (интерпретаторами диаграммы) являются люди. Как раз наш случай – два человека (Вы и я) одну и ту же диаграмму в статье воспринимаем по-разному, причём эти различия в весьма важной области: кто именно делает то, что предписано. Вот это и есть проблема, поскольку разделение ответственности – извечный предмет производственных споров. И swimlanes-концепция успешно помогает их решить: получив мяч, делай то, что на твоей дорожке, и перебрасывай мяч дальше.

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

  9. Anatoly Belychook 16.01.17 17:29

    Между BPMN-диаграммами “на бумаге” и BPMN-диаграммами в движке есть еще вариант BPMN-диаграмм в моделере, причем он как бы самый распространенный.

    Так вот, при работе в моделере аналитик не только рисует картинку, но и задает атрибуты, в частности - исполнителей задач. На картинке их не видно, но любой приличный моделер умеет экспортировать в word, pdf или гипертекст, и там наряду со схемой будет описание, в котором и отобразятся исполнители, а равно и другие атрибуты - например, нормативная продолжительность задачи.

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

    Причем это правильно! Я видел продукты, которые отступили от этого правила и задавали исполнителя через дорожку. Получилось плохо: диаграмма вырождалась в то, что на каждой дорожке располагалось по одной задаче. Дело в том, что задачи, у которых в первом приближении исполнитель один (рисуем дорожку: бухгалтерия), при ближайшем рассмотрении они оказываются разными (в атрибутах задачи указываем: рядовой бухгалтер, старший бухгалтер или “тот же бухгалтер, который рассматривал документ в первый раз”).

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

Комментирование закрыто

Copyright © 2008-2017 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии