Здесь и далее Камунда 7.x и подобные ей системы будут называться легкими процессуальными движками.

Зачем нужны процессуальные движки?

Зачем легкий процессуальный движок собственнику

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

Представитель одной страховой компании утверждал, что удовлетворенность клиентов падала в течении ряда лет, несмотря на то, что скорость обслуживания постоянно повышалась. То есть, запросы клиентов выполняются все быстрее, а они все равно недовольны. Как такое может быть?

В той страховке это объяснили эффектом Амазона. Люди привыкли, что заказанный сегодня днем товар будет у них завтра утром. От других компаний, в т. ч. страховых они ожидают такой же скорости. А если компании реагируют медленнее Амазона, то клиенты недовольны.

Пример ускорения компании

Для примера я возьму бизнес Гаса Фринга из популярного телесериала про тяготы и лишения инновационного предпринимателя, пытающегося прокормить семью.

Предупреждение о спойлере

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

Шаг 1: Выбираем процесс

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

Шаг 2: Создаем модель процесса

В первом приближении модель процесса перевозок может выглядеть так:

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

Шаг 3: Внедряем легкий процессуальный движок в связке с таск-трекером

Имея модель процесса, мы можем преобразовать все активности в ручные задачи. Вот так:

Одновременно с этим нужно добавить в Камунду интеграцию с таск-трекером (Джирой или аналогом), которая будет работать так:

1. Когда выполнение доходит до той или иной ручной задачи, процессуальный движок создает задачу в таск-трекере и назначает ее исполнителю.

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

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

Шаг 4: Анализируем данные

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

Зачем процессуальный движок бизнес-аналитику

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

Зачем процессуальный движок разработчику

Визуализация

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

Если

1. в том или ином процессе очень много активностей и/или

2. есть много вложенных процессов (процесс 1 вызывает подпроцесс 2, который вызывает подпроцесс 3 и так далее),

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

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

Повторное выполнение при ошибках

Разработчика грамотное использование процессуального движка также освобождает от необходимости самому реализовывать стандартный функционал. Например, Камунда 7.x поддерживает механизм повторных попыток – если в первый раз та или иная активность не сработала, процессуальный движок сам повторит попытку указанное количество раз в указанном интервале.

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

Зачем процессуальный движок админу

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

На этот случай есть вызов REST API, который позволяет это сделать для тысяч экземпляров процессов с помощью одного вызова.

Есть и другие, полезные в исключительных случаях функциональности:

• Передвижение токена: Можно сделать так, что выполнение тех или иных экземпляров процессов начнется с другого места.

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

Зачем процессуальный движок архитектору

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

• внешние служебные задачи и

• кластерный режим.

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

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

1. BPM-системы (Business Process Management Systems) подобны автомобилю, у которого, кроме всего прочего, есть мотор. Купив автомобиль вы, теоретически, можете сразу поехать в сторону ускорения вашей компании.

2. Легкие процессуальные движки подобны мотору. Чтобы куда-то поехать вам надо собрать вокруг этого мотора автомобиль.

3. Решения для автоматизации по принципу "если-то" подобны метро. С одной стороны вам не надо ни уметь водить (настраивать BPMS), ни тем более собирать автомобиль (строить систему на базе Камунды). С другой стороны ездить вы можете только туда, куда проложены рельсы.

Рассмотрим каждый из этих видов систем по отдельности.

BPM-системы

Кроме самого процессуального движка эти системы включают пользовательский интерфейс и ряд других инструментов.

В эту категорию попадают устаревшие системы, в т. ч. Oracle Workflow Builder и TIBCO iProcess.

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

Легкие процессуальные движки

К легким процессуальным движкам относятся

• jBPM,

• Activiti (часть системы документооборота Alfresco),

• Камунда 7.х и

• Flowable.

Насколько мне известно

• Activiti является форком jBPM, а

• Камунда 7.x и Flowable – форками Activiti.

В приватной беседе представитель Flowable утверждал, что их продукт сделан разработчиками Activiti. Процессуальный движок при этом полностью переписан (в отличии от Камунды 7.х).

Он также утверждал, что из-за особенностей Flowable в этой системе хорошо работается с CMMN (схема процессов, в которой последовательность выполнения активностей задается пользователем) и ряд заказчиков пользуется этой функциональностью. Производитель Камунды 7.х разочаровался в CMMN и не планирует развивать эту часть движка.

Решения для автоматизации по принципу "если-то"

Такие решения позволяют делать автоматизацию по правилам если произошло такое-то событие, то сделай то-то, например:

1. Если пришло письмо с такой-то темой на такой-то ящик, то создай в Джире задачу по такому-то шаблону.

2. Если от сервиса рассылок пришло письмо о том, что пользователь такой-то подписался на рассылку, то занеси его данные в CRM.

3. Если пользователь положил документа в такую-то папку на Яндекс.Диске, то отправь электронное письмо по такому-то адресу.

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

В отличии от систем первых двух видов, у решений автоматизации по принципу "если-то" нет поддержки схем процессов. Все делается на цепочках правил.

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

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

Использование легких процессуальных движков требует минимум миниморум одного разработчика-джависта (а лучше трех – один болеет, второй в отпуске, третий работает). У всех известных мне эксплуатантов Камунды 7.x есть свой ИТ-отдел. Стоимость владения BPMS, как правило, еще выше из-за более дорогих лицензий.

Недостатки этих решений суть продолжение преимуществ:

• Нет кода: В них вы не пишете код в православно-кошерном Емаксе или Виме, а вводите данные в формочки. Это усложняет версионирование и рецензирование кода.

• Ограничения доступа: Если все правила редактирует один человек (например, админ), то есть потерять доступ к системе, если он обидится или начнется весеннее обострение активной гражданской позиции. Камунда 7.x поддерживает аутентификацию через LDAP и все, что поддерживает KeyCloak (в т. ч. гугловую аутентификацию).

• Тестирование и развертывание: Для всех легковесных процессуальных движков есть устоявшийся инструментарий для автоматического тестирования (Maven/Gradle, JUnit и т. п.). Облачные системы этого тестировать можно, на первый взгляд, только в продакшене.

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

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

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

В-третьих, автоматизация "если-то" может подойти для стартапов без технических сооснователей. Например, на TypeForm создается форма опроса. Когда пользователь ввел данные, TypeForm отправляет электронное письмо. Когда электронное письмо приходит, в такой-то таблице в Google Docs создается новая строка. А дальше сотрудник что-то делает с этими данными.

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

Камунда против Пеги -- за и против

Стоимость

Главный козырь легковесных процессуальных движков в сравнении с TIBCO iProcess и Пегой – стоимость эксплуатации.

Один европейский производитель аппаратуры для связи использует Пегу и Камунду одновременно. В приватной беседе его представитель утверждал, что стоимость эксплуатации Камунды 7.х (включая деньги за лицензию и оплату программистов) составляет около 10% от стоимости эксплуатации Пеги.

Одна из причин заключается в том, что все форки jBPM написаны на Джаве и процессуальные приложения можно писать на Джаве. А у Пеги – свой язык и свои инструменты. На рынке больше джавистов, чем тех, кто владеет Пегой. Поэтому в среднем разработчики на Джаве стоят дешевле разработчиков на Пеге.

Поддержка инструментов для разработки пользовательской оболочки

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

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

Открытый код

Код движка Камунды 7.x – открытый. Закрытым является лишь код платной версии веб-приложений (а пока есть Экскамад, платная версия веб-приложений нужна чуть чаще, чем никогда). Сам движок в платной и бесплатной версии одинаковый.

Несмотря на качественную документацию время от времени возникают вопросы, ответ на которые можно найти только в коде. Классический случай: Есть некий запрос в REST API. Как я могу использовать эту функциональность в Джаве, без REST API?

Ответ на такие вопросы очень легко найти в коде Камунды 7.

Поддержка производителя

2-го марта 2022 Camunda Services GmbH в лице Якоба Фройнда прекратила (резервная копия) обслуживать заказчиков из России, в том числе тех кто платил от 50.000 евро за enterprise edition Камунды 7.x.

Насколько мне известно, ни Пега, ни Mimacom (производитель Flowable) пока не достигли таких зияющих высот заботы о клиенте.

Противопоказания

Есть ряд случаев, для которых процессуальные движки не подходят:

1. Документооборот

2. Процессы, окончания которых ждет пользователь

3. Процессы, которые никогда не меняются

4. Процессы, которые взаимодействуют только с одной системой

Документооборот

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

Процессы, окончания которых ждет пользователь

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

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

Напрашивается следующая схема процесса:

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

Контрпример

Давным-давно, когда лицензии выдавались на ядра процессора, пенсионный фонд одной европейской страны купил лицензию Камунды 7.x на два ядра. В этой стране около 9 миллионов человек и для взрослой части населения каждый месяц надо обновлять данные относительно пенсии. Те, кто работает, платит в пенсионный фонд. Те, кто на пенсии получает из него деньги.

Интегратор, продавший эту лицензию потирал руки – мол, сейчас этот пенсионный фонд распробует Камунду 7.x и закупит еще лицензий. Не может же Камунда 7.x каждый месяц обсчитывать до 9 миллионов человек на всего лишь двух ядрах!

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

Так вот, в отличии от примера с авиабилетами в случае с пенсионным фондом пользователь не ждет завершения процесса. Не так важно, будет ли обсчитан тот или иной человек прямо сейчас, через 30 секунд или через несколько часов. Камунда 7.х рассчитана именно на это.

Процессы, которые никогда не меняются

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

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

Процессы, взаимодействующие только с одной системой

Камунда 7.х хорошо подходит для случаев, когда надо спросить одну систему, потом другую, а после этого на основе их ответов что-то сделать.

Если ваш процесс взаимодействует только с одной системой, то, возможно, Камунда 7.х вам не нужна.

Как освоить Камунду

Все сказанное выше – общие рекомендации. Чтобы понять по гамбургскому счету, нужна ли Вам Камунда 7.х, надо иметь представление, как она работает.

Рассмотрим варианты его получить.

Отечественные курсы

Одним из лучших ресурсов на тему процессуальных движков является bpmn2.ru. Его автор, Денис Котов,

• разработал Экскамад (бесплатная пользовательская оболочка для Камунды 7.х с рядом функций, которые есть только в enterprise edition) и

• StormBPMN (онлайн-редактор процессуальных схем, аналог Cawemo) и

• является чемпионом по Камунде (см. здесь в разделе Get to know our Champions).

Учиться у него Камунде – все равно, что учиться варить синий мет химии у Гейзенберга.

Главная проблема курсов

Но с курсами, даже самыми крутыми, проблема одна – жаба. Тысячу-другую евро на курсы жалко.

Один немецкий банк в начале 2020-го года решил начать переход с TIBCO iProcess на Камунду 7.x. Пилотный проект поручили орлам из придворной компании-интегратора. Эффективные менеджеры решили, что тратиться на обучение – слишком дорого, особенно учитывая, что у них сеньор на сеньоре сидит и сеньором погоняет.

Но что-то пошло не так.

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

Написанный сеньорами код приготовил нам много открытий чудных.

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

То, что в некоторых делегатах были конструкции switch-case с 40 ветками (и при этом ни единого автоматического теста) можно было объяснить особенностями менталитета – возможно, что в этой придворной компании сеньоры такие же, как в Camunda Services GmbH специалисты по отношениям с клиентами.

Это все, в принципе, понятно.

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

На мой вопрос "Чтобы что?" внятного ответа не было.

Убрав визуализацию из процессуального приложения, они немотивированно лишили себя одного из ключевых преимуществ Камунды 7.х. Работать с Камундой 7.x без визуализации – все равно что нести (а не катить) бочку метиламина.

Уолтеру и Джессе это простительно – все-таки они под стрессом, режимный объект и все такое. А сеньорам непростительно – им деньги платят и держат в хороших офисах, чтобы спокойно работали головой и все делали правильно, а не через Альпы.

Если бы они прошли бы базовое обучение у любого, даже самого тупого, инструктора по Камунде, то им бы там вправили мозги – объяснили, что веб-приложения выпиливать точно не надо, а диаграммы – cюрприз, сюрприз – надо рисовать так, чтобы другие люди могли их читать.

Хороший инструктор это знает не потому, что умнее вас, а потому, что уже сделал ошибки новичков и на них научился.

А так, сэкономив на обучении, этот банк потратил впустую год работы целой команды. Допустим, там было 5 сеньоров и каждый в год стоил компании 70.000 евро. Итого 350.000,– евро "освоенных" денег. Код, который эти сеньоры написали было решено спустить в унитаз переписать с нуля.

Народный самоучитель

Для тех, кого предыдущий параграф не убедил, я написал народный самоучитель по Камунде 7.x.

Несколько отзывов:

Пока лучшее что я видел по руководствам Камунды.

Источник

за ваше здоровье сегодня подниму бокал

Источник

Вот темы, которые освещаются в самоучителе на практических примерах:

1. Минимальное приложение

2. Развертываем диаграмму процесса через Камунда Моделер

3. Помещаем диаграмму процесса в код приложения

4. Подключаем Экскамад

5. Вызываем код на Джаве внутри одной JVM (внутренняя служебная задача)

6. Вызываем код на Джаве вне JVM Камунды (внешняя служебная задача)

7. Простейший шлюз

8. Вызываем подпроцесс и передаем некоторые процессуальные переменны в и из него

9. Знакомимся с DMN

10. Автоматически проверяем таблицу принятия решений

11. Чуть более сложная модель DMN

12. Корреляция сообщений

13. Автоматическое тестирование схем BPMN

14. Обрабатываем бизнесовые ошибки

15. Минимум, что вам нужно знать про async-before

16. Кластерный (deployment-aware) режим

Скачать народный самоучитель можно по следующим ссылкам:

1. EPUB

2. DOCX

3. PDF

Когда-то Камунда 7.х устареет, либо ее заменит другой, более совершенный продукт. Тогда устареет и самоучитель. Для того, чтобы его можно было обновлять, его исходники (как примеры кода, так и сам текст) доступны для форканья на GitFlic.

Заключение

Если у вас возникли вопросы по Камунде, задавайте их в комментариях или российском BPM-сообществе.

П. С.: Осенью 2022-го года я планирую релоцироваться в Москву. Если вашей компании может пригодится старший разработчик на Джаве с 3-летним опытом работы на Камунде (резюме, материалы по Камунде 7.x), предлагаю пообщаться по почте dp@dpisarenko.com.