Процессы: чего до сих пор не хватало обычным BPM (Часть 2) / Хабр

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

Откуда в организациях процессы

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

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

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

Они могут быть зашиты в ERP/CRM и другие корпоративные системы.
Вместе с лоукод-платформой, где они являются неотъемлемой частью функциональности.
Через BPM-движки, которые интегрируется в различные приложения или выступают внешним оркестратором.

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

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

BPMN-модель деплоится в BPM-движок
Происходит запуск экземпляров процессов (вручную или автоматически)
Выполняются сервисные и пользовательские задачи
По окончании — запись в историю

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

Процесс как сущность

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

Иначе говоря, бизнесу нужен репозиторий процессов — это централизованное хранилище, где живут не только схемы BPMN, но и все, что нужно, чтобы процесс был управляемым: версии моделей, регламенты, роли, метрики, связи с ИТ-системами и история изменений. Его главная задача — сделать процессы единым источником истины, чтобы бизнес, аналитики, разработчики и владельцы процессов работали с одной актуальной картиной. Например, в качестве такого репозитория может выступать Stornbpmn или Business Studio.

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

С этой целью был реализован объект Business Process, который несет дополнительные атрибуты, позволяющие организовать удобную навигацию по множеству процессов и задать бизнес-контекст — область действия (scope), какой организации процесс принадлежит, к какой категории относится. Если потребуется, можно добавить более детальную бизнес-классификацию, но на первом этапе и этого достаточно.

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

Таким образом, мы получаем не только process management, но в перспективе и process governance, чтобы поддержать регламент работы с процессами и их жизненный цикл.

Модели процесса

А что насчет собственно BPMN-модели? И как быть с их версионностью? — Вопрос не простой.

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

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

По-любому получается, что к объекту Business Process может относится множество версий BPMN-моделей. Но какую из них считать актуальной?

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

Процессные роли

Процессные роли обычно трактуются сугубо утилитарно — какие задачи та или иная роль исполняет (что часто моделируется дорожками).

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

Однако, мы ведь вышли за рамки этого ограничения, да? — Теперь у нас есть объект Business Process, и, соответственно, процессные роли привязываются к нему.

Также, стоит вспомнить, что в фундаменте у нас лежит оргмодель — значит, мы можем назначать сотрудников на процессные роли через организационный контекст.

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

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

Механизм назначений

Что делать, когда подходящих кандидатов много, а исполнитель нужен только один?

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

BPM-движки предлагают простое решение — давайте кинем задачу на всех кандидатов и пусть кто-то ее заберет.

При таком подходе возможны две конфликтные ситуации:

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

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

Работает это так:

Через оргконтекст система резолвит потенциальных исполнителей
Дополнительно подключается один из методов, который уже определяет кто именно будет назначен на задачу
На выходе мы получаем username, который и нужен BPM-движку для корректной работы

Небольшое пояснение по методам:

Все — когда нам все-таки нужна групповая задача или мульти-инстанс
Руководитель — это понятно, руководитель подразделения
Единственный — когда по смыслу должности на нее может быть только одно действующее назначение, например, генеральный директор; добавлено для дополнительного контроля
Случайный — тоже понятно
Round robin — назначение по кругу; но это не так просто, как кажется, логику надо тщательно прорабатывать
Наименее загруженный — в первом приближении тот, у кого меньше активных задач; но тоже можно усовершенствовать, например, учитывать суммарную длительность задач

Помните DSL-правила из первой части? Для процессов добавляется еще метод назначения, а в остальном все так же.

Например, рандомный инженер со знанием Java:

select:
  organization: ACME
  position: JAVA_DEV
  skills:
    - JAVA
assign: RANDOM
sourceSystem: LOCAL

Пусть неявное станет явным: контракт процесса

Что говорит нам теория? — В стандарте ISO 9001 процесс прямо определяется как совокупность взаимосвязанных действий, преобразующих входы в выходы, это базовый принцип всего процессного управления.

Но как из BPMN-модели понять, что процесс получает на вход и что отдает на выходе? — Никак. Модель начинается со стартового события и заканчивается конечным событием, насчет данных или состояний объектов ничего не говорится, это надо выяснять отдельно.

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

В классических движках Camunda и Flowable этого нет от слова совсем, можно только неявно определить через стартовые формы для входных данных, а выходные пытаться понять по конечным событиям, коих может быть множество.

Чуть ближе к этому Appian, где можно зайти в процесс и увидеть его data model, иногда даже интерфейс (SAIL), где видны входные параметры и Pega Platform — там есть структура кейса и данные, которые можно воспринимать как вход/выход. Но и там это не оформлено как явный контракт процесса.

В BPM-мире вход/выход процесса почти везде существуют неявно, через переменные и формы; явное, визуально выделенное представление “это вход, это выход” — это отсутствующая концепция, никак не стандартная фича.

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

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

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

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

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

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

И наконец, это бьёт по управляемости: невозможно нормально измерять, тестировать и обсуждать процесс на уровне бизнеса, потому что вместо понятной трансформации “было → стало” у нас есть просто некие исторические данные, которые еще надо как-то интепретировать.

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

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

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

Входные и выходные схемы

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

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

Входные и выходные JSON-схемы могут генериться полуавтоматически:

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

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

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

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

Его выходные и выходные схемы будут выглядеть так:

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

Результат процесса

"Что остается от сказки потом, после того, как ее рассказали?" — так же и от процесса, только воспоминание, что он был. Да россыпь значений переменных в истории, которые еще надо собрать.

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

Кроме того, для каждого экземпляра процесса создается отдельный объект Process Result — в него записываются реальные входные и выходные данные согласно JSON-схемам. Теперь вам не надо копаться в сырых логах BPM-движка, чтобы узнать, что получил на вход и отдал на выходе каждый запущенный процесс.

Например вот так:

А если какие-то результаты процесса нельзя просто взять и положить в переменную, то можно сохранить их в файл и прикрепить к результирующему объекту.

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

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

Собираем все вместе

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

Каждый экземпляр процесса получает входные данные согласно своей input-схеме, а по его окончании на основании output-схемы создается объект Process Result с реальными данными.

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

Ничто нам не мешает сохранять их сразу в Process Result — как JSON-поля или в виде attachment'ов. При этом и контекст не страдает, и история не растет.