Ситуация

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

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

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

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

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

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

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

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

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

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

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

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

Решение

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

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

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

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

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

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

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

• Инструменты быстрой разработки. Унификация архитектуры, модели данных, паттернов реализации бизнес-логики и 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:

• Исправление всех публичных уязвимостей.

• Совместимость с российскими ОС RedOS, AltLinux, AstraLinux.

• Разделение 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 и Камунда.рф сами движки закрытые, но благодаря открытому стандарту в основе бизнес-логику при желании можно перенести на другую платформу. В случае с остальными продуктами провести миграцию уже будет невозможно, придется переписывать проект. 

Результаты и бизнес-выгоды

Проект решил три задачи одновременно: гарантировал выполнение требований законодательства по импортозамещению без потери функциональности, сохранил независимость от конкретного вендора и обеспечил официальную поддержку с SLA. Работа с Хоулмонт позволила реализовать все это и не останавливать развитие проекта даже тогда, когда Camunda сменила бизнес-модель.

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

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

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