Мой самый популярный пост на bpmntraining.ru: Информационные системы в BPMN: взгляд снаружи и изнутри. » читать дальше

В своей недавней заметке Брюс Силвер поделился соображениями относительно условного события в BPMMN.

Для тех, кто недостаточно погружен в BPMN 2.0, условное событие ставит процесс на паузу до того момента, как заданное логическое условие становится истинным (точнее, меняет свое значение с “ложь” на “истина”). Сейчас на дворе октябрь, так что вот вам подходящий пример стартового события-условия:

Рис. 1. Пример стартового события-условия.

Процесс стартует, когда указанное логическое условие становится истинным, т.е. когда зима вступает в свои права. (К слову, это реальное правило, действующее в Москве.)

Типичный пример промежуточного события-условия::

Рис. 2. Пример промежуточного события-условия.

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

Брюс пишет, что он предпочитает не пользоваться событием-условием и исключил его из “Method and Style” - сборника лучших практик моделирования, который он создал, поддерживает и рекламирует своей знаменитой книгой (лучше книгой по BPMN, на мой взгляд).

При всем моем уважении к Брюсу, которого я считаю своим учителем в BPMN, у меня другое мнение на этот счет: я считаю, что для определенных достаточно распространенных сценариев межпроцессного взаимодействия это лучшее решение. (Точнее, речь пойдет о промежуточном событии-условии; стартовое событие не представляет большой ценности и далее не будет рассматриваться.) » читать дальше

Этот контент доступен на языках: English.

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

Схема рабочая, но у нее есть недостаток: сервер здесь должен знать клиента, что называется, “в лицо” - в схему процесса-сервера зашивается отправка сообщения в процесс-клиент. Если сервер обслуживает всего одного клиента, то это нормально, но если это не так?

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

В прошлой заметке мы выяснили, что при всем многообразии развилок в BPMN, строго необходимыми являются две из пяти: “или/или” и “и”.

Перейдем к событиям. События в BPMN классифицируются по типу (13 вариантов) и по месту (8 вариантов). Рассмотрим классификацию по типам:

1. Простое событие

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

Как это не парадоксально, но термин “процесс” остается самым неоднозначным в BPM - недавняя дискуссия на форуме BPM.com это наглядно демонстрирует.

• Когда мы разрабатывали профстандарт, одно из рабочих вариантов названия было “Специалист по управлению процессами”. И на одном из обсуждений мы получили замечание: “Уточните, о каких процессах идет речь - процессами пищеварения вы собираетесь управлять?” В самом деле, на бытовом уровне мы процессами называем все что угодно, от пищеварения до образования галактик.
• Среди консультантов по управлению распространен взгляд на процессы как на любую упорядоченную деятельность, нацеленную на получение определенного результата. В таком определении есть смысл - если в фокусе нашего внимания находится эффективность бизнеса, то для нас нет большой разницы между деятельностью в рамках функциональных подразделений, кросс-функциональных процессов или проектов. Но если погружаться в конкретику, то такое определение процесса становится непродуктивным: конечно, мы можем принять, что проект - это тоже процесс, просто нацеленный на однократный результат, но методы управления проектами и процессами ведь существенно разные, как ни крути. К слову, в последнее время для обозначения широкого спектра деятельности вместо термина “процесс” стали употреблять “бизнес-способность”. Мне этот термин нравится, поскольку позволяет объединить процессы и проекты, не сливая их в одно.
• В контексте BPMN определение процесса сужается еще больше. Во-первых, в BPMN есть четкая разница между процессом и подпроцессом: первый инициируется внешним событием (сообщением, таймером или просто волевым решением), второй вызывается. Во-вторых, BPMN в упор не видит уровни выше отдельного процесса - такие сущности, как, например, “цепочка создания ценности”, “вспомогательные бизнес-процессы” или “продвижение продукции”. В BPMN нет средств для моделирования групп процессов.

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

См.также

• Что является процессом в BPMN (и что не является)

Полная палитра BPMN включает сотни элементов (если считать все возможные комбинации). И хотя профессионал знать их должен все, не надо стремиться все их использовать.

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

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

Попробуем ответить на эти вопросы и показать, какие элементы абсолютно необходимы, а без каких можно обойтись, заменив их другими.

Начнем с развилок.

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

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

Опасно! Не пытайтесь повторить.

Я заметил, что те, кто обходятся задачами, развилкам и потоками управления, рисуют схемы более понятные и прямолинейные, чем те, кто в курсе существования сообщений. События-сообщения и задачи-сообщения похожи на автоматические задачи: они предназначены для процессных движков, а не для того, чтобы их обрабатывали люди.

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

Неправильно: email через сообщение	Правильно: email через пользовательскую задачу (ручной процесс)	Правильно: email через задачу-сценарий (процесс, реализованный в BPMS)

Если вам надо показать, что какая-то задача взаимодействует с внешним миром (например, с заказчиком или поставщиком), то можно использовать пул - черный ящик и сообщения, прикрепленные непосредственно к задаче:

Но лучше не засорять диаграмму потоками сообщений и черными ящиками. Ведь если задача называется “Get customer’s commitment”, то и так понятно, что она взаимодействует с клиентом:

Использование черных ящиков и сообщений имеет смысл только в одном случае: если вам надо отобразить ВСЕ сообщения, входящие в / исходящие от внешнего контрагента, чтобы специфицировать “коммуникационный контракт” с ним.

И завершая эту заметку,- о различиях между событиями-сообщениями и задачами-сообщениями: их основные функции тождественны; небольшое различие проистекает из общего различия между событиями и задачами. К последним можно прикреплять обработчики событий (например, таймер) и модификаторы (например, цикл по объектам), что иногда бывает удобно:

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

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

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

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

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

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

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

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

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

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

Некая организация живет по плану: на регулярной основе планы составляются, затем пункты плана выполняются.

1. Антипаттерн: планирование и исполнение в одном процессе

Проблема этой диаграммы в том, что планирование длится, пока не будут выполнены все пункты плана. » читать дальше