От Camunda до российского BPM-движка: опыт автоматизации процессов в страховой компании

Ситуация

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

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

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

1. Разветвленные внутренние регламенты компании

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

2. Законодательные требования по импортозамещению

Информационная система заказчика относится к критической информационной инфраструктуре (КИИ), поэтому ее требовалось реализовать на базе технологий, внесенных в реестр российского ПО. В дополнение к этому были важны наличие лицензии ФСТЭК у исполнителя и совместимость с российским ПО, в частности, СУБД и ОС.

3. Контроль на стороне ИТ-команды заказчика в сочетании с вендорской поддержкой

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

Исполнитель проекта

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

Разработка пилота заняла 1 месяц. В оценке демо со стороны заказчика принимали участие представители бизнеса, ИТ и ИБ. По итогам компания Хоулмонт была признана победителем. Дополнительным аргументом в ее пользу стал опыт работы с open source BPM-технологиями — как на клиентских проектах, так и в собственных инструментах разработки.

Решение

BPM и платформенный подход

Верхнеуровнево с архитектурной точки зрения проект представляет собой комбинацию BPM-движка Camunda и витрины задач — модулей на базе Java-платформы Jmix.

BPM-движки сегодня присутствуют «под капотом» практически у всех современных ERP, CRM, СЭД, АБС и уникальных систем автоматизации. Этот подход применяется как для координации пользователей, так и для оркестрации микросервисов и ИИ-агентов.

Сильные стороны BPM-движков — высокая скорость разработки и прозрачность. Бизнес быстро получает результат, ИТ-команда концентрируется на логике и интеграциях, а не на повторяющихся блоках типового кода. При этом аналитики, разработчики и администраторы системы могут наблюдать как общую картину по всем процессам, так и отдельные инстансы, в том числе в режиме реального времени. Фактически, отраслевым стандартом долгое время был open source движок Camunda — именно его выбрали для реализации проекта.

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

Фуллстек-разработка

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

Java-стек технологий

Знакомый многим специалистам программирования обеспечивает легкий вход для команды, в отличие от скриптовых языков, которые лежат в основе многих low-code-платформ.

Инструменты быстрой разработки

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

Экосистема для работы с ИИ

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

Архитектура и технологии

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

Функциональные модули системы:

• Урегулирование убытков
• Работа с договорами
• Работа со счетами (бордеро и премии-убытки)
• Обработка входящих сообщений
• Рабочее место операциониста
• Рабочее место андеррайтера
• Работа с дебиторской задолженностью
• Управление ретроцессией

В числе сервисных модулей системы:

• BPM — ключевой среди сервисных модулей, который выступает в качестве ядра внутри обертки с прикладной бизнес-логикой
• Управление задачами
• Модуль управления учетными данными
• Модуль НСИ
• Модуль мониторинга и сообщений
• Модуль для полнотекстового поиска Elasticsearch

Взаимодействие с внешними системами происходит через интеграционную шину на базе Arenadata Streaming Platform — российской платформы для управления Kafka-коннекторами.

Интеграции:

• Почтовый сервер VK WorkMail
• Система ЮЗЭДО Контур.Диадок
• Финансовая система Diasoft
• Хранилище учетных записей LDAP
• Хранилище файлов S3

В компании провели импортозамещение не только системы автоматизации процессов страхования, но и всего ИТ-ландшафта.

В проекте используются:

• Серверная ОС Astra Linux
• СУБД Tantor
• Платформа контейнеризации Docker
• Российская JDK от Axiom

Процессная автоматизация

BPM-движок управляет процессами в рамках каждого функционального модуля. Например, в процессе урегулирования убытков:

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

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

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

Смена курса Camunda и замена BPM-движка

Планы по развитию модуля BPM пришлось скорректировать из-за смены бизнес-модели Camunda. Версия Camunda 7, выпущенная в октябре 2025 года, стала последним open source релизом. Патчи к ней можно получить уже только по подписке, мажорные версии также проприетарные. Поскольку оплатить подписку в РФ невозможно из-за санкций, для многих проектов на Camunda это означает, что они остались без вендорской поддержки, обновлений и исправления уязвимостей, а также без понятного пути дальнейшего развития или миграции.

Риски продолжения эксплуатации Camunda:

• Критичные для операционной деятельности сбои из-за несовместимости прикладного ПО с BPM-движком и обновлений инфраструктуры.
• Сбои из-за проработки вариантов обновления неподдерживаемого движка своими силами.
• Рост косвенных затрат на проработку проектов миграции, лицензирование новых систем и переобучение ИТ-команды.
• Штрафы со стороны регулятора из-за нарушения указаний по линии информационной безопасности.
• Замедление развития процессов из-за нехватки специалистов и конфликтов между ИТ и ИБ по поводу затрат на устранение уязвимостей и сбоев.
• Ослабление HR-бренда, трудности в найме в случае использования технологий без активного сообщества.

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

Команда Хоулмонт предложила альтернативу — OpenBPM, форк Camunda 7. Это не статичная копия, а современный развивающийся продукт со своей концепцией.

Какие улучшения отличают OpenBPM от Camunda 7:

• Исправление всех публичных уязвимостей.
• Совместимость с российскими ОС РЕД ОС, ALT Linux, Astra Linux.
• Разделение BPM-движка и инструментов (центр мониторинга и управления средой исполнения, рабочее место разработчика, шаблон витрины задач, инструменты для быстрой миграции проектов), чтобы их можно было при необходимости использовать независимо друг от друга.
• Совместимость со всеми популярными дизайнерами BPMN-схем, а также собственная реализация дизайнера бизнес-процессов с элементами AI.
• Очистка кода движка от устаревших технологий, повышение стабильности работы, оптимизация тестирования.
• Собственные компоненты для перекрытия enterprise-функциональности Camunda 7.
• Возможность сборки процессных приложений на Spring Boot 4 и JDK 25+.

Использование OpenBPM позволяет сохранить кодовую базу и интеграции: новый движок автоматически подхватывает прошлые BPMN- и DMN-модели, все API-методы остаются знакомыми и предсказуемыми. OpenBPM запускается поверх существующей базы данных Camunda, что обеспечивает сохранение истории процессов и данных при миграции. Модификации БД не требуется, так как движки полностью совместимы. Бизнес-логика также остается без изменений.

Сохраняется и методология работы, на которой построено взаимодействие между разработчиками и аналитиками внутри команды. Совместимость с инфраструктурой заказчика минимизирует вероятность ошибок в продакшене. Затраты на внедрение OpenBPM составляют 5–10% от возможных потерь из-за перечисленных выше рисков.

В рассматриваемом проекте движок OpenBPM Engine развертывается в режиме embedded внутри Jmix-приложения, выступающего в качестве модуля-обертки. Обертка выполняет следующие функции:

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

На отдельном сервере было развернуто специализированное прикладное Jmix-приложение, выполняющее функцию «витрины задач», с которой работают пользователи.

Еще одно приложение OpenBPM Control обеспечивает мониторинг и управление процессами.

Все компоненты взаимодействуют между собой по REST API.

Альтернативы Camunda

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

Российские платформы на базе Camunda-технологий:

• Digital.Q BPM от Диасофт
• Камунда.рф от Farzoom, дочернего предприятия «Ростелекома»
• BPM.Платформа от БФТ

BPM-платформы на базе собственных технологий российских вендоров:

• BPMSoft от Ланит
• ELMA365 от ELMA
• Platform V Flow от Сбера

Эти продукты используют не связанные с Camunda собственные разработки, хотя и на похожих принципах. Для команд, которые работают с Camunda, это означает не только перестройку архитектуры, но и новые требования к компетенциям специалистов. Для ELMA365 и BPMSoft разрыв более существенный, для Platform V Flow — менее.

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

Еще один важный вопрос — возможность развития самого движка и реализованных на нем процессов независимо от вендора. OpenBPM дает максимальную свободу. У Digital.Q и Камунда.рф сами движки закрытые, но благодаря открытому стандарту в основе бизнес-логику при желании можно перенести на другую платформу. В случае с остальными продуктами провести миграцию уже будет невозможно, придется переписывать проект.