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

BPMN-модель готова, процессный движок запускает экземпляры процессов, распределяет задачи между пользователями и сервисами и управляет последовательностью действий. На этапе Proof of Concept этого часто достаточно, чтобы показать: процесс работает.

Но при переходе от PoC к реальной эксплуатации появляются совсем другие вопросы. Где сотрудник создаёт заявку? Где хранятся документы? Как руководитель видит процессы своего подразделения? Кто имеет доступ к данным? Где найти заявку после завершения процесса?

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

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

Что находится вокруг BPM-движка

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

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

Процесс отвечает на вопрос «Что произойдёт дальше?», а бизнес-объект — «С чем мы работаем, что мы об этом знаем и кто имеет к этому доступ?» 

На архитектурном уровне платформа разделена на три основных компонента: бизнес-приложение, процессный движок и среду выполнения интеграций. Отдельно работают frontend, Keycloak, Kafka и хранилища PostgreSQL. При этом бизнес-данные отделены от данных процесса. 

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

Пользователь работает не с диаграммой

Для разработчика процесс — это экземпляры, переменные, события и задачи. Для сотрудника всё гораздо проще: например, «согласовать закупку до пятницы». Поэтому пользовательский слой должен давать человеку привычные инструменты: карточку заявки, задачи, формы, документы и доступные действия.

В UniBPM центральным бизнес-объектом выступает заявка (Ticket). Несмотря на название, это не обязательно обращение: заявкой может быть договор, запрос на закупку, потребность в сотруднике или другой объект конкретной предметной области.

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

Интеграции — отдельная часть архитектуры

Практически любой корпоративный процесс взаимодействует с другими системами: ERP, 1С, внутренними сервисами, внешними API.

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

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

А что с AI?

AI в этой архитектуре рассматривается не как самостоятельный «владелец» процесса, а как ещё один его участник с определённой задачей.

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

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

Не разрабатывать один и тот же фундамент заново

В этом и заключается основная идея платформенного подхода.

Цель не в том, чтобы быстрее рисовать BPMN. И не в том, чтобы убрать из проекта разработку, анализ или архитектуру.

Задача в другом: не создавать заново прикладную инфраструктуру для каждого следующего процесса.

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

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

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

Подробный технический разбор архитектуры UniBPM, работы с данными, интеграциями, AI и моделью доступа — в оригинальной статье команды разработки UniBPM.