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

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

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

Бизнес-процессы иногда называют «генетическим кодом организации».

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

В рамках этой аналогии BPM – это генная инженерия:

• мы расшифровываем геном организации (анализ и моделирование бизнес-процессов)
• мы идентифицируем отдельные хорошие и плохие гены (процессные паттерны и антипаттерны)
• мы удаляем плохие гены, заимствуем хорошие у одних живых организмов и прививаем их другим

Разница в том, что мы воздействуем на образ жизни и эффективность  в конкурентной борьбе его самого, а не его будущих потомков.

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

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

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

Я часто использую аналогию между системами управления базами данных (DBMS) и бизнес-процессами (BPMS):

1. Когда-то давным-давно компьютерные программы состояли из одних алгоритмов.
2. Потом в какой-то момент выяснилось, что алгоритмы и данные - это разные сущности. Профессор Вирт написал свою знаменитую книгу “Алгоритмы и структуры данных”, и появилось понимание, что для работы с данными нужен специальный инструментарий. Возник новый класс программного обеспечения под названием DBMS.
3. Аналогичным образом, в какой-то момент появилось понимание того, что процесс лучше не сводить к алгоритмам или данным, а рассматривать как самостоятельную сущность, требующую специального инструментария. Так появились BPMS.

Теперь вспомним, как прогрессировали пользовательские интерфейсы к базам данных:

1. Вначале каждая DBMS поставлялась со своим собственным инструментарием. Например, Informix 4GL для СУБД Informix или Oracle Forms для СУБД Oracle.
2. Затем стали появляться универсальные инструменты, позволяющие работать с различными СУБД. Например, в 80-е Unify создал Accell 4GL, функционально очень близкий с Informix 4GL и Oracle Forms, но отличавшийся от них тем, что мог работать и с собственной СУБД Unify, и со всеми ведущими на тот момент СУБД: Informix, Oracle, Sybase. На этом этапе универсальность достигалась просто: поставщик встраивал в свой продукт поддержку той или иной СУБД. Преимущество, которое получал клиент: с таким инструментарием он мог безболезненно сменить СУБД. И это не абстракция: так, Сбербанк в свое время смог сменить СУБД Unify на Oracle, безболезненно перенеся миллионы строк кодов, написанных на Accell. Причем если бы даже Сбербанк сразу сделал ставку на Oracle, то и в этом случае у него были бы сейчас серьезные проблемы, так как, в отличие от Unify, который продолжает исправно выпускать для Accell новые версии, Oracle прикрыл Forms. (Повторяю, речь идет о прикладной системе масштабом многих миллионов строк исходного кода.)
3. В конце концов появился поставщик инструментария настолько мощный, что он сумел заставить поставщиков СУБД стандартизировать программные интерфейсы: Microsoft предложил ODBC. Потом JDBC пошел уже по накатанной дорожке. Поставщикам СУБД пришлось на это пойти, чтобы не оказаться на обочине, но они делают все, чтобы их собственные проприетарные интерфейсы оставались более быстрыми или предоставляли доступ к нестандартным расширениям данной конкретной СУБД. Поэтому не является чем-то необычным инструментарий, который поддерживает, скажем, Oracle и MS-SQL по их собственным протоколам, а всех остальных - по ODBC.

Хотя Microsoft Studio и Oracle JDeveloper достаточно популярны, множество приложений для СУБД от Microsoft и Oracle разрабатывается не на них, а на Delphi, PHP и бог знает чем еще. Так что большинство прикладных разработчиков предпочитает вариант 3.

Как же обстоит дело с интерфейсами к BPMS? Очевидно, они сейчас находятся на шаге 1, и это печально.

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

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

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

По функциональности такой продукт должен поддерживать:

• Интроспекцию, т.е. предлагать, например, список атрибутов процесса, для которого разрабатывается данная форма.
• Два режима: быстрого прототипирования и создания продуктивной системы. Первый предназначен для бизнес-аналитика, в нем достаточно задать перечень атрибутов и указать для них признак только для чтения / редактируемый / обязательный для ввода, а форма создается автоматически. Во втором визуальные компоненты размещаются на холсте вручную программистом и есть возможность писать код для валидации ввода, фоновых обращений к движку и т.д.
• Те же два режима для портала. На этапе прототипирования - стандартный портал “из коробки”, для продуктивной системы - портал, собранный программистом из высокоуровневых компонент (см. “Демо- и промышленная система на основе BPM“).
• Два типа клиентов: браузер и смартфон. Очень хочется иметь среду разработки форм, которые будут исполняться и на компьютере, и, скажем, на iPhone. В идеале хотелось бы, чтобы это была одна и та же форма. Как минимум, пусть формы будут разные, но со схожим дизайном и разрабатываемые в одной среде.
• Ну и само собой, стандартную работу с базами данных и вебсервисами.

А вы воспользовались бы таким инструментом? Или он уже есть, а я просто отстал от жизни? Или вы собираетесь, или уже разрабатываете что-то подобное?