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

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

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

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

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

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

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

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

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

Словарь опубликован и ждет вашей критики, дополнений и предложений.

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

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

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

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

Уместен вопрос: зачем нужен “живой” тренинг, если в интернете есть масса материалов? - Это так, но интернет не научит вас, как применять BPMN к задачам, встречающимся в реальной жизни. Я занимаюсь этим последние пять лет - вы можете либо потратить примерно столько же, либо за 3 дня на тренинге получить необходимые знания и закрепить их в рабочих навыках.

Четвертое по счету подобное мероприятие CNews на этот раз проходит под заголовком “BPM в России: мода или потребность”.

Нам удалось привлечь к нему в качестве спонсора BizAgi. И не просто привлечь, а убедить приехать в Россию первое лицо компании (CEO) Густаво Игнасио Гомеса. Планируется, что мы с ним сделаем совместный доклад.

Компания BizAgi и ее продукт BizAgi BPM Suite очень интересные; на мой взгляд, недооцененные. Судите сами:

1. Самая полная реализация BPMN в исполнительном движке. В частности, реализованы сообщения (message flow), циклы по объектам (multi-instance), сигналы, транзакции и компенсации. На фоне множества вендоров, которые декларируют BPMN, а на деле реализуют только самые базовые конструкции, это впечатляет.
2. Очень лояльная по отношению к клиенту ценовая политика. Ценового барьера как такового нет: младшая конфигурация стоит $100 за пользователя. Приятный контраст по сравнению с BPM-системами, для которых за “входной билет” просят сто-двести-триста тысяч долларов. Есть бесплатная пробная версия, не ограниченная ни по функциональности, ни по срокам.
3. Поддержка одновременно и .NET, и J2EE. Опять-таки, другого такого вендора я не знаю.

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

Резюмируя, я считаю, это тот продукт и тот вендор, которых не хватало российскому рынку.

Так что приходите - для представителей компаний-заказчиков мероприятие бесплатное. Регистрация >>

Небольшое дополнение к предыдущей заметке “Применение для сигнала BPMN“.

Отмеченная в ней специфика события типа “сигнал” - получение сигнала всеми экземплярами процесса-получателя, находящимися на шаге ожидания данного сигнала - относится к промежуточным событиях (intermediate event).

В случае стартового события (start event) все более спокойно: в одном процессе инициировали сигнал, в результате какой-то другой процесс стартовал. Правда, возникает вопрос: зачем тут использовать сигнал, когда то же самое можно сделать сообщением?

Во-первых, сигнал позволяет инициировать не один, а несколько процессов.

Во-вторых, у схемы с сигналом есть концептуальное преимущество:

• Пусть определенный сигнал, инициированный процессом А, вызывает старт процесса Б.
• Теперь вспомним, что BPM - это не просто управление бизнес-процессами, а управление процессами, меняющимися во времени, и предположим, что мы решили назначить обработчиком сигнала процесс В вместо процесса Б.
• В схеме с сообщением получатель указан в процессе А, т.е. чтобы заменить обработчик, нам придется изменить схему А. При этом возникнет проблема: что делать с уже запущенными экземплярами А?
• В схеме с сигналами мы просто инсталлируем процесс В и деинсталлируем Б. Менять схему А не требуется, проблем с запущенными экземплярами А не возникает.

Таким образом, сигнал позволяет реализовать позднее связывание: обработчик можно назначать и переназначать не на этапе разработки, а на этапе исполнения.

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

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

В этой заметке я остановлюсь на событии типа “сигнал”.

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

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

• Инструментарий Enterprise Architecture (EA) предназначен для моделирования следующих аспектов корпоративной архитектуры:
  1. бизнес-архитектура - бизнес-цели, организационная структура, функции, процессы, роли и т.д.
  2. архитектура приложений - корпоративные системы и их интерфейсы
  3. архитектура данных - логическая и физическая
  4. технологическая инфраструктура - программно-аппаратное обеспечение и сети
• Инструментарий Business Process Analysis (BPA) в части моделирования является подмножеством EA, покрывая полностью или частично бизнес-архитектуру. Но, помимо моделирования, может содержать специализированные средства, например, имитационное моделирование бизнес-процессов или статистический анализ результатов исполнения.
• Business Process Management Suite (BPMS) в обязательном порядке включает моделирование бизнес-процессов, их исполнение (process engine, процессный “движок”) и мониторинг/анализ. Опционально может включать имитационное моделирование, движок бизнес-правил и многое другое.
• Некоторые вендоры используют для своих продуктов определение “BPM Software”. Обычно это означает, что система не дотягивает до BPMS - например, в ней нет исполняемого движка - но маркетинг хочет видеть в названии BPM.

Апологеты BPMS (я в том числе) верят в силу исполняемых бизнес-процессов, в принцип “what you model is what you run”. Соответственно, наличие процессного движка для них - необходимость, и EA инструментарием они обойтись не могут.

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

Как быть? Может это временные трудности, и через некоторое время либо BPMS дорастут до EA, либо EA включат функциональность BPMS?

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

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

1. изобразили BPMN-диаграмму средствами EA
2. дальше возможны два варианта:
   • если BPMS непосредственно исполняет BPMN, выполнили экспорт-импорт через XPDL
   • если BPMS поддерживает BPEL, выполнили трансляцию BPMN->BPEL

Например, нарисовали в ARIS - экспортировали в WebMethods. Или нарисовали в Casewise - транслировали в Oracle BPEL.

Схема простая, логичная, но… плохо работающая. Точнее, оба варианта работают только пока мы рассматриваем один проход: нарисовали - передали - исполнили. Но вспомним, что BPM - это ведь не однократная автоматизация процесса, а управление изменчивыми бизнес-процессами.

Что это означает на практике? После того, как схему процесса загрузили в BPMS, разработчик должен внести в нее правки и уточнения, необходимые для исполнения процесса движком. Но исходная схема процесса в EA тоже не остается неизменной - аналитик продолжает ее совершенствовать, ведь за это, собственно, мы и боролись! (Подробно эта проблематика рассмотрена в серии заметок на блоге Keith Swenson, начинающейся с “Model Strategy: Preserving vs. Transforming“. Русский перевод на bpms.ru.)

Таким образом, надо либо уметь передавать подробности физической реализации процесса в BPMS назад в EA и находить для них место в репозитарии (т.н. проблема “round-trip”), либо уметь объединять изменения, выполняемые в одной и в другой схемах (по образцу branch merging в системах контроля версий). Теоретически задача может быть и разрешима, но по факту за много лет решить ее не удалось. Будем ждать?

Предлагаю принять за аксиому, что:

1. водораздел между EA и BPMS есть и останется в обозримом будущем
2. удовлетворительной автоматической передачи артефактов между ними нет и в обозримом будущем не будет

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

Предложение: проводить его на уровне процесса -

• цепочка создания ценностей (value chain) и межпроцессное взаимодействие через события и/или данные моделируются средствами EA
• внутренняя логика процесса моделируется средствами BPMS

Тогда передавать из EA в BPMS придется только номенклатуру и интерфейсы процессов, а для этого автоматический экспорт-импорт не нужен, можно обойтись экспортом-импортом “через принтер”.

Бизнес-аналитик должен провести для себя красную черту: не использовать EA для моделирования бизнес-процесса при наличии BPMS.

Впрочем, для средств моделирования BPMN в EA тоже есть применение. Современные BPMS нацелены на моделирование внутренней логики процессов (оркестровка) и плохо подходят для моделирования межпроцессного взаимодействия (процессная хореография). Но одной оркестровкой можно решать только задачи уровня “автоматизации канцелярии”; как только вы поднимаетесь на уровень сквозных бизнес-процессов - т.е. процессов, за которыми стоят реальные деньги - вам не обойтись без хореографии. (См. на эту тему анти-паттерн “Оркестровка сквозного процесса”.)

Моделировать межпроцессное взаимодействие предлагается средствами EA, используя для этого т.н. “black box BPMN diagram” - технику моделирования, в которой каждый процесс отображается как пустой BPMN pool. Взаимодействие через сообщения моделируется при помощи message flow, взаимодействие через данные - при помощи association.

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

Для каждого процесса на диаграмме вверху средствами BPMS создается BPMN-диаграмма, раскрывающая внутреннюю логику процесса:

Пример:

Бумага конечно все стерпит, но как только мы попробуем превратить эту схему в исполняемый процесс, так сразу выясним, что в реальном мире платеж может прийти, а может и нет. Как и в антипаттерне “шаг с односторонним движением”, мы взаимодействуем с независимым субъектом (покупателем), обладающим свободой воли, и мы не можем полагаться на то, что он будет действовать предписанным нами образом.

В рассматриваемом примере мы как минимум должны предусмотреть три варианта:

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

В BPMN специально для такой ситуации предусмотрена конструкция под названием “исключающая развилка, управляемая событиями” (exclusive event gateway):

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

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

Боюсь, это ошибка с их стороны - ведь задача обработки альтернативных сообщений никуда не денется! В отсутствие event gatway единственный путь - использовать параллельную развилку (parallel gateway). Но тут возникает проблема “гашения” остальных путей при приходе одного из сообщений, которую приходится решать при помощи искусственных конструкций в диаграмме и/или написания программного кода. Конечно, ни о визуальной наглядности процесса, ни о следовании стандарту речь при этом уже не идет.

Таким образом, рассматриваемый антипаттерн необычен тем, что источник его - не процессный аналитик, а разработчик BPMS. С другой стороны, в силах поставщиков BPMS сделать так, чтобы этот антипаттерн исчез - для этого им достаточно изменить свое отношение к поддержке event gateway.

Пока конкретная BPMS не поддерживает event gateway, нормально работать с сообщениями (message flow) в ней невозможно. Оркестровка в ней поддерживается, хореография - нет. На мой взгляд, такая система - это старый добрый workflow вне зависимости от наличия на нем лэйбла BPMN.