Если вам интересны мои мысли по поводу BPM/N/S, подпишитесь на новости.

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

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

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

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

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

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

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

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

Мы начнем сценарии моделирования процессов для целей автоматизации, а затем рассмотрим моделирование для целей регламентации.

Брюс аргументирует свою позицию следующим образом:

1. Промежуточно событие-условие, базирующееся на данных процесса, в большинстве случаев избыточно, т.к. его можно заменить развилкой, что является более интуитивно-понятным и потому предпочтительным решением.
2. Чтобы от события-условия была какая-то реальная польза, оно должно базироваться на данных вне контекста процесса. Однако спецификация BPMN оставляет вопрос о механизме обращения к таким данным за рамками. Брюс интерпретирует “оставить за рамками” как некую магию, а магии в солидной методологии конечно же нет места.
3. Срабатывание события-условия можно было бы привязать к хранилищу данных потоком данных, но такую связь можно устанавливать только внутри процесса, по крайней мере в моделере Trisotech. (Брюс в течение нескольких лет продуктивно сотрудничает с этой компанией.)

Я полностью согласен с первым аргументом, но довод относительно магии мне представляется сомнительным. Я считаю, что одним из базовых допущений BPMN является то, что 1) существует некоторая информационная среда помимо собственных (транзакционных) данных процесса, 2) процессные данные каким-то образом связаны с сущностями в этой среде (например, внешними ключами БД, глобальными идентификаторами, бизнес-идентификаторами и т.п.) и 3) существует некоторый механизм доступа к этим данным (например, SQL select или вызов сервиса oData). Было бы странным разъяснять это в каждом разделе стандарта, поэтому я предпочитаю трактовать фразу в стандарте “the specification of mechanisms is out of scope of the standard” как “используйте подходящий механизм”.

Третий аргумент относится скорее не к логике моделирования, а к конкретному программу обеспечению. Действительно, существующие средства моделирования BPMN не очень хорошо умеют обращаться с событиями-условиями. Я бы хотел, чтобы вендоры позволили изображать потоки данных от хранилища данных к событию так, как показано на этом фрагменте, сделанном в Visio:

Рис. 3. Событие-условие, срабатывающее по изменению данных в хранилище.

К сожалению, пока этого нет. Весьма популярный Bizagi Modeler в принципе не позволяет соединять поток данных с событием-условием. Другой популярный инструмент bpmn.io изображает поток данных в обратном направлении:

Рис. 4. Изображение события-условия в bpmn.io (ошибочное).

К слову, моделеры BPMN к сожалению не позволяют также прикреплять потоки данных к пулам-”черным ящикам”, как на рис. 11 ниже.

Чем же может быть полезно промежуточное событие-условие? Рассмотрим бизнес-сценарий, схожий с тем, который использовал Брюс:

1. Клиент присылает запрос на обслуживание.
2. Менеджер рассматривает запрос, и если он его одобряет, то создается счет, который отправляется клиенту.
3. Если в течении срока действия счета проходит платеж, процесс переходит к оказанию услуги, в противном случае завершается.
4. Теперь самое интересное: предполагается, что клиент оплачивает счет банковским переводом. Наш финансовый отдел регулярно (например, дважды в день) запускает программное обеспечение клиент-банк и получает выписку исходящих и входящих платежей - таким способом наша компаний узнает, что клиент оплатил счет.

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

Взаимодействие через событие-сообщение

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

Рис. 5. Взаимодействие через событие-сообщение.

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

Такой алгоритм не очень надежен, поскольку клиент мог не указать номер счета в платежном поручении, что в реальной жизни случается достаточно часто. Обычно в такой ситуации платеж можно идентифицировать по названию/ИНН плательщика и сумме платежа. Чтобы реализовать такую более продвинутую бизнес-логику, процесс обработки выписки банка должен иметь доступ к счетам, что означает межпроцессное взаимодействие через общие данные:

Рис. 6. Взаимодействие через события-сообщения и общие данные.

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

Взаимодействие через событие-сигнал

Рис. 7. Взаимодействие через событие-сигнал (ошибочное).

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

Взаимодействие через событие-условие

Рис. 8. Взаимодействие через событие-условие.

Центральную роль здесь играет хранилище данных “Выставленные счета”, которое может быть реализовано, например, одноименной таблицей БД.

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

Процесс обработки выписки банка использует эту таблицу чтобы идентифицировать платеж и, в случае успеха, чтобы присвоить атрибуту статус значение “оплачено”, что вызовет срабатывание триггера во клиентском процессе.

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

Fig. 9. Multiple messages.

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

Это фундаментальная проблема сообщений в BPMN: они приводят к тесно связанным диаграммам. Вы не можете просто отправить сообщение - вы должны показать в какой процесс и в какой элемента процесса оно должно попасть.

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

Рис. 10. Сторона-инициатор взаимодействия.

Рис. 11. Сторона-обработчик.

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

Неисполняемые модели

До сих пор мы говорили об исполняемых моделях, т.е. обрабатываемых процессным движком.

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

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

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

Рис. 12. Неисполняемая модель: событие-условие заменено задачей, развилкой и таймером.

Хранилище данных “счета выставленные” можно реализовать множеством способов, начиная с SAP и заканчивая сетевым Excel и канбан-доской.

Рис. 13. Пример канбан-доски.

Выводы

1. Моделировать межпроцессное взаимодействие предпочтительно через событие-условие, а не сообщения, поскольку это приводит к слабосвязную архитектуру.
2. Производителям программного обеспечения BPMN надо разрешить соединять потоками данных хранилища данных (и объекты данных) с событиями-условиям, чтобы показать какие данные вызывают срабатывание события.

]]> https://mainthing.ru/ru/item/900/feed/ https://mainthing.ru/ru/item/898/ https://mainthing.ru/ru/item/898/#comments Tue, 06 Sep 2022 14:08:25 +0000 Anatoly Belychook https://mainthing.ru/?p=898 Этот контент доступен на языках: English.

В результате сформировался класс программного обеспечения BPMS — эта аббревиатура изначально расшифровывалась как Business Process Management System, затем, с легкой руки Gartner, System превратилась в Suite. На рынке BPMS представлены как «гранды» (IBM, Oracle, SAP, Software AG), так и десятки компаний ‒ узких специалистов (pure-play vendors). Появление программных продуктов Open Source стало свидетельством зрелости рынка.

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

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

Может быть, ошибочной была сама концепция BPM? Для сравнения: за 10 лет увлечения реинжинирингом было накоплено достаточно опыта применения, чтобы выявить и сильные, и слабые его стороны. BPM же практикуется уже почти 15 лет, но каких-то существенных изъянов в нем не обнаружилось и новой процессной парадигмы за это время не предложено.

Если только не считать таковой концепцию кейс-менеджмента (ACM, Adaptive Case Management).

Процессы для клерков и для креативных сотрудников: ACM

Приверженцы этой концепции заявили, что на смену клеркам, выполняющим механическую работу по утвержденным регламентам, в современном мире пришли креативные работники умственного труда (knowledge workers), которым нужны не традиционные жестко определенные процессы, а более гибкие и динамичные формы работы — кейсы.

Ничего особенно нового в кейсах нет: когда в организацию приходит письмо и начальник «расписывает» его замам, а те, в свою очередь, ставят задачи подчиненным — это и есть кейс, т. е. просто «дело» на русском канцелярском. Или когда пользователь пишет заявку в техподдержку вида «не печатается отчет» — это ведь может означать что угодно, от закончившегося картриджа в принтере до планового обновления SAP. На верхнем уровне можно представить работу над заявкой в виде процесса — ввести первую и вторую линию техподдержки, определить нормативные сроки и SLA — но сами действия по устранению проблемы будут планироваться на ходу. Про кейс говорят, что он «развертывается во времени» — вы не можете заранее определить все, с чем столкнетесь, поэтому планируете только первый шаг, а по его результатам смотрите, что делать дальше.

В чем-то сторонники ACM были правы: на тот момент все больше производств и стандартных услуг выводилось на аутсорсинг в страны с дешевой рабочей силой, а в Штатах оставались управление, разработка, маркетинг и продвижение, т. е. в основном творческая работа. Поэтому при взгляде из США могло сложиться впечатление, что традиционные процессы уже неактуальны. Но если взглянуть шире, становится понятно, что рутинная работа переместилась географически, но не исчезла.

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

В условиях, когда между традиционными потоками работ и кейсами нет непроницаемого барьера, отдельные средства для управления только кейсами оказались невостребованными. В итоге производители BPMS включили поддержку кейсов в свои продукты, и бизнес-процесс стал трактоваться расширительно — это и работа, выполняемая по шаблону, и планируемая «на лету». Отдельная ниша для систем ACM не сложилась.

В поисках правильного лейбла: iBPMS & Low-code

Если товар под старым лейблом продается плохо, а нового нет — надо обновить лейбл. В начале 2010-х Джим Сайнур из Gartner предложил новую аббревиатуру: Intelligent BPMS. По сути, речь шла о том, что современные BPMS обязаны были соответствовать общим ИТ-трендам, наметившимся к этому моменту: SMAC — Social, Mobile, Analytics, Cloud, т. е. поддержка социального взаимодействия, доступ с мобильного устройства, «облака», «продвинутая аналитика» (с последней ясности было меньше).

Вендоры, бывшие в числе «любимчиков» Gartner, с энтузиазмом поддержали это движение (кто сказал «сговор»?!), но надо признать, что такого единодушного признания, как исходная концепция BPMS, новинка не получила, и рейтинги iBPMS выпускает только Gartner. Хотя по факту все те BPM-вендоры, которые продолжали активно развивать свои продукты, добавили в них и мобильность, и «облака», и поддержку социального взаимодействия, и функциональность кейс-менеджмента.

Через несколько лет компания Forrester, вечный конкурент Gartner, предложила новый лейбл: Low-code, или системы с минимальным кодированием.

Ключевых идей в этой концепции можно выделить две: во-первых, центр тяжести усилий по разработке процессных бизнес-приложений переносится с программистов на аналитиков. Действительно, BPMS-системы, ориентированные на программистов, плохо соответствуют методологии BPM и из-за этого демонстрируют ограниченный успех. С точки зрения бизнеса это выглядит как всего лишь еще одна ИТ-система: раньше процессы кодировали в АБС или ERP, теперь в BPMS — что изменилось-то? (Тем более что АБС и ERP никуда не делись.) Чтобы BPM дал эффект, должен измениться стиль взаимодействия между бизнесом и ИТ, старая модель «бизнес пишет ТЗ и перебрасывает его через стену в ИТ-отдел» должна смениться аджайлом с его быстрыми итерациями и тесной вовлеченностью бизнеса в проектирование бизнес-процессов.

Чтобы этого добиться, нужно минимизировать объем кодирования, максимально использовав программирование от графических моделей и сделав среду разработки максимально дружественной по отношению к «гражданским» разработчикам. Другими словами, это должен быть не Eclipse, java и XML, а разработка от диаграммы BPMN, простой и удобный редактор форм, и желательно, чтобы все это было реализовано в браузере.

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

При этом использование реляционных баз данных здесь нецелесообразно, ведь скорость внесения изменений — не самая их сильная сторона. Например, в графовой базе добавить атрибут можно мгновенно, без реконфигурирования. Также графовая база умеет отвечать на запросы вида «покажи все процессы и задачи, связанные с данным бизнес-объектом — машиной, клиентом, товаром…».

Еще одна особенность систем Low-code, отличающая их и от традиционных корпоративных систем, и от BPMS: в качестве пользователя здесь рассматриваются не только внутренние (сотрудники компании), но и внешние (клиенты, поставщики, партнеры). Это радикально меняет требования к визуальной привлекательности и эргономике пользовательского интерфейса.

Идея минимального кодирования не нова — SQL в свое время создавался под этим же флагом: иметь возможность обращаться к БД без программирования, на языке, максимально близком к естественному человеческому. Также можно вспомнить аббревиатуру RAD — Rapid Application Development. Так что системы Low-code продолжают давнюю традицию.

Идея Low-code оказалась удачной — ее хорошо восприняли и заказчики, и вендоры. Кое-кто пошел дальше, заявив о Zero-code или No-code, но это больше похоже на маркетинговый шум, чем на работающую технологию.

BPM и цифровая трансформация

Концепция BPM- и BPM-систем, предложенная без малого 15 лет назад, выдержала проверку временем. Но проблема тех, кто ее предложил и развивал тогда, в том, что они «бежали впереди паровоза» — пусть концепция у вас правильная, но большого спроса на нее не будет, пока есть более простые способы повышения эффективности бизнеса, начиная с банального сокращения персонала и наведения порядка в управленческом учете.

Только в последние два года ситуация для энтузиастов BPM стала меняться в лучшую сторону. Связано это с повсеместным острым интересом бизнеса к цифровой трансформации. Происходит что-то невообразимое: мы привыкли к тому, что ИТ-отрасль предлагает бизнесу свои игрушки, а он от них большей частью отмахивается, а сейчас требования бизнеса к ИТ зачастую опережают предложение.

Человек, однажды воспользовавшийся услугами Яндекс-такси или сервисом Google docs, уже не будет прежним. И когда он приходит к себе на работу, у него возникают вопросы: «Какого черта?! Почему в туалете почти неделю течет кран, а моя бумажная заявка ходит неизвестно где? Почему я не могу сфотографировать на смартфон, отправить заявку одной кнопкой так же, как я одной кнопкой вызываю такси, и на смартфон же получить отчет о том, что кран починен или заменен?» (Кстати, это реальный кейс.)

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

Цифровые клиенты, цифровые услуги — все начинают думать, а многие — уже и действовать в этом направлении. А вторым шагом приходит понимание, что необходимое условие — цифровые бизнес-процессы: пусть вы построили цифровой «фасад» вашего бизнеса, но если в итоге все попадает в бэк-офис, где люди работают по старинке в соответствии с письменными регламентами, то ничего не будет. И естественным образом возникает интерес к цифровым бизнес-процессам, т. е. ко всем тем наработкам, которые BPM предложил еще 15 лет назад и с тех пор последовательно развивал.

Таким образом, сегодня можно говорить о «втором пришествии» BPM — второй волне интереса к процессной методологии и информационным технологиям, поддерживаемым стремлением современного бизнеса к цифровизации своих операций.

Для специалистов по BPM это означает две новости. Первая— хорошая: много новых процессов! Новые исполнители — софтверные боты, роботы-ассистенты, роботизированная техника… Новые модели предоставления услуг, с максимальным переносом в онлайн.

Вторая новость — очень хорошая: это надолго! Речь ведь не идет о том, чтобы заменить старые «аналоговые» бизнес-процессы на новые «цифровые» и на этом успокоиться — прогресс в области цифровизации ускоряется! Вчера это были приложения на смартфонах и «облака», сегодня — элементы искусственного интеллекта, чат-боты, интернет вещей, завтра — беспилотный транспорт и самые разнообразные роботы. Все это потребует массовой и быстрой перестройки бизнес-процессов, а значит, спрос на компетенции и информационные технологии BPM будет продолжать расти.

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

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

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

Решение: вместо сообщения воспользоваться условным событием -

1. Процесс-клиент (Продажа) записывает задачу в базу данных и переходит к ожиданию изменения статуса задачи (статус счета = оплачено).
2. Процесс-сервер (Входящие платежи) меняет статус оплаты.
3. Процесс-клиент просыпается и идет дальше.

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

Отдельный вопрос - поддерживает ли событие-условие ваша конкретная BPMS?

Хорошая новость для пользователей Bizagi: в палитре Bizagi BPM Suite событие-условие появилось и схема типа приведенной выше работает - проверено.

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

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

Строго говоря, начальные и конечные события необходимыми не являются – так, приведенная ниже диаграмма формально корректна: здесь Task 1 – неявное начало (т.к. нет ни одной входящей стрелки), Task 2 – неявный конец процесса (нет ни одной исходящей).

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

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

2. Событие-ссылка

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

3. Событие-таймер

Полезен, интуитивно понятен, часто используется на практике.

4. Событие-условие

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

Вторая проблема условия – большинство движков это событие не поддерживает. (Я пока не видел ни одного движка, умеющего работать с событием-условием.)

Но все не так плохо: событие-условие можно заменить комбинацией таймера и развилки или/или –

	=
	=

Потенциальные недостатки такой замены – лишняя нагрузка на движок и замусоривание журнала беготней по кругу.

5. Событие-сообщение

Основной, наряду с обменом данными, механизм межпроцессного взаимодействия. Берем.

6. Событие-сигнал

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

=

Во-вторых, сообщение – это сильное связывание, сигнал – слабое. Например, если вы хотите из процесса A запустить процесс B через отправку сообщения, то вы не можете это сделать, ограничив поле зрения только процессом A – у вас должна быть схема процесса B:

С сигналом проще – вы можете разрабатывать схемы процессов A и B независимо – все, что им надо знать друг о друге – это имя сигнала и, опционально, формат данных («полезной нагрузки»):

Если вы имеете дело со сложной системой процессов, то это свойство сигнала становится очень ценным – вам наверняка захочется работать над схемой одного процесса, не оглядываясь на то, готов ли уже другой. Впрочем и в этом случае можно обойтись без сигналов:

Здесь процесс A выставляет флаг в хранилище данных, а процесс B периодически его проверяет. Если флаг не выставлен, B заканчивается, в противном случае он сбрасывает флаг и переходит к основной своей работе.

7. Событие-останов

8. Событие-ошибка

9. Событие-эскалация

Эти три события более-менее взаимозаменяемы:

	=
	=

Ценная особенность эскалации – при помощи промежуточного события-инициатора и непрерывающего обработчика можно породить новый токен и запустить асинхронный поток управления в процессе/подпроцессе верхнего уровня:

10. Множественное событие

Без этого события можно обойтись достаточно легко.

Обработчик:

=

Инициатор:

=

=

11. Параллельное множественное событие

Если событий два, то заменить параллельное множественное событие достаточно легко:

=

Если событий много, то получаем комбинаторный взрыв, и заменить параллельное множественное событие такой техникой становится проблематично. Но мне и два события ни разу не понадобились на практике, а уж больше… А если бы понадобилось, использовал бы CEP (Complex Event Processing), а не BPMN.

12. Событие-отмена

13. Событие-компенсация

События отмены, компенсации, транзакционные подпроцессы и задачи-компенсации крайне полезны в сценарии «все или ничего». Пример: я отправляюсь в командировку, и в порядке подготовки мне надо 1) получить согласие от организаторов выступить с докладом, 2) забронировать авиабилеты, 3) забронировать гостиницу, 4) получить согласие компании оплатить расходы. Все эти действия целесообразно выполнять в параллель – иначе можно не успеть. При этом каждое действие может закончиться неудачей, и в этом случае возникает нетривиальная задача выполнения компенсирующих действий – если организаторы не приняли доклад, а билеты забронированы, то надо сделать возврат билетов и т.п.

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

Резюме

Из 13 типов событий -

• необходимых 4: простое, таймер, сообщение, останов
• полезных 2: сигнал, ошибка
• для специальных случаев 4: условие, эскалация, отмена, компенсация
• практически бесполезных 3: ссылка, множественное, параллельное множественное

Теперь рассмотрим классификацию событий по месту. На примере сообщения:

1. Начальное событие

2. Конечное событие

3. Промежуточное событие-инициатор

4. Промежуточное событие-обработчик

Эта четверка безусловно необходима.

5. Прикрепленное событие прерывающее

Полезно, интуитивно понятно, часто используется на практике.

6. Прикрепленное событие непрерывающее

Интуитивно не понятен. Более-менее можно обойтись:

=

7. Подпроцесс-обработчик прерывающий

8. Подпроцесс-обработчик непрерывающий

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

Выводы

Итого из восьми вариантов классификации событий по месту необходимых и полезных - пять: начало, конец, промежуточный инициатор, промежуточный обработчик, прикрепленный обработчик непрерывающий (подмножество BPMN 1.x).

Если ограничиться событиями только необходимыми и полезными по типу (всего 6) и по месту (всего 5), то получим 30 потенциально возможных комбинаций, из которых реализуются 19:

Для справки, полное число комбинаций событий в BPMN 2.0 равняется 63.

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

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

См.также

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

]]> https://mainthing.ru/ru/item/847/feed/ https://mainthing.ru/ru/item/813/ https://mainthing.ru/ru/item/813/#comments Sat, 28 Jan 2017 12:58:10 +0000 Anatoly Belychook http://mainthing.ru/?p=813 Полная палитра BPMN включает сотни элементов (если считать все возможные комбинации). И хотя профессионал знать их должен все, не надо стремиться все их использовать.

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

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

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

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

1. Развилка “или/или”

Пытаться заменить эту развилку мы не будем.

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

2. Развилка “и” (параллельная)

Тоже вещь незаменимая.

3. Развилка “и/или”

Заменяется комбинацией развилок “или/или” и параллельной:

=

Развилка “и/или” полезна, так как моделирует вполне определенный и достаточно распространенный сценарий “набор независимых опций”; альтернативная реализация получается более громоздкой. Минус тот, что бизнес-пользователи схему справа поймут без дополнительных объяснений, а схему слева - вряд ли.

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

4. Комплексная развилка

Комплексная развилка управляет токенами на схождении нескольких потоков управления. Заменяется парой развилок или/или:

=

5. Развилка по событиям

Заменяется с помощью подпроцесса:

=

Это универсальная техника, позаимствованая у Брюса Силвера, пригодная для любых комбинаций событий.

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

6. Стартовая развилка по событиям

=

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

7. Параллельная стартовая развилка по событиям

=

Представляет в основном лишь академический интерес.

Выводы

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

О взаимозаменяемости событий и других элементах - в следующих статьях.