Ситуация
Заказчик — страховая компания, которая имеет ключевое значение для устойчивости российской экономики. Среди ее клиентов финансовые организации, промышленные предприятия, транспортные компании, а также исполнители крупных инфраструктурных проектов.
Ключевую информационную систему заказчика, через которую проходят все заявки на урегулирование убытков и другие процессы, требовалось перевести на российское ПО.
При выборе пути реализации проекта учитывалась специфика работы компании и связанные с ней ограничения:
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-систем.