В завершение 2025 года хотелось бы взглянуть на проект российского BPM-движка “с высоты птичьего полета” и оценить, насколько нам удалось продвинуться по глобальной функциональной карте. Особенно в свете недавно вышедшего обзора ТБанк, где коллеги пришли к выводам о необходимости создания собственного форка и поставили много вопросов о том, что Camunda-ориентированная разработка архитектурно хороша, но не отвечает многим современным требованиям безопасности.  

UPD: прямая ссылка на исходный программный код, лицензия Apache 2.0

В качестве введения

Технологический стек BPM систем достаточно мощный, но сложный, и его бывает трудно “продать бизнесу”. Частый паттерн: технически всё возможно, но организационно получается тяжело собирать и надежно согласовывать процессные требования, ощущается острая нехватка инструментов для быстрого прототипирования и промежуточных демо. Кроме того, корпоративные пользователи боятся vendor-lock и сложной экосистемы, которую потом будет дорого развивать и поддерживать.  

Администраторам и командам разработки BPM систем на сегодняшний день не хватает (а это объективные данные на начало 2026 года, полученные на основе наших встреч с участниками рынка, а также анализа огромного числа выгрузок с профильных инженерных чатов, форумов и блогов):

• Наблюдаемости и контроля процессов в проде;

• Безопасного и управляемого изменения процессов;

• Удобной работы с задачами на операторов;

• Полноценного BPM-DevOps, а не набора разрозненных API;

• Стандартной работы с данными и интеграциями;

• Предсказуемого масштабирования;

• Фокуса на бизнес-ценностях, а не на BPM-терминах.

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

• Облегчении понимания;

• Полноте контроля;

• Уверенности и прогнозируемости;

• Гибкости и удобстве.

Вот примерно в таком ключе и посмотрим на состояние проекта OpenBPM.

Для наших новых читателей напомню, что российский продукт OpenBPM, вошедший в Репозиторий ИТ-решений для финансовой отрасли ассоциации ФИНТЕХ (реестровая запись АФТ1213), представляет собой доработанную локализацию иностранного промышленного BPM решения Camunda 7, в котором:  

• Проведено исправление всех публичных уязвимостей (Обзорная статья, Вебинар с подробным разбором);

• Проведен рефакторинг по очистке программного кода BPM-движка от устаревших технологий, повышена стабильность работы, упрощено тестирование;

• Поддержана совместимость со всеми популярными дизайнерами BPMN-схем, в том числе предложена своя независимая реализация дизайнера;

• Проведено разделение BPM-движка и инструментов, с использованием российского фреймворка Jmix и открытой среды разработки OpenIDE:

  • Единый центр мониторинга и управления средой исполнения; 

  • Рабочее место разработчика;

  • Шаблонное приложение для построения витрины задач;

  • Инструменты для быстрой миграции проектов;

• Проведено перекрытие собственными компонентами Enterprise функционала Camunda 7;

• Обеспечена совместимость с российскими ОС RedOS, AltLinux, AstraLinux;

• Обеспечено ускорение и удешевление проектов автоматизации.

Информацию по требованиям отразим в виде набора таблиц, типичных для тендерной документации. 

Архитектура

Потребности команд разработки и сопровождения

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

Производительность

Безопасность

Если с производительностью все более-менее понятно, то почему столько внимания  уделяется теме с авторизациями и уязвимостями, если обычно ядро Camunda  функционирует в закрытом и защищенном сетевом контуре? Формально да, контур изолированный, но аргументацию для ИБ служб, почему мы не исправляем уязвимости, получается подбирать все сложнее, так как у процессов регулярные изменения, а значит регулярные деплои, а значит постоянное внимание со стороны ИБ и риск непредвиденных задержек при выкатке обновлений. 

Еще это связано с предстоящими изменениями законодательства: 

Федеральный закон от 31.07.2025 № 325-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации"  предполагал, в т.ч., дальнейшую систематизацию работы с реестром российского ПО,  на основе подзаконных актов, разработанных со стороны Минцифры. В настоящее время завершен этап публичного обсуждения Проекта Постановления  Правительства Российской Федерации «Об утверждении Правил формирования  и ведения перечня  российских программ для электронных вычислительных машин  и баз данных, разработанных и используемых для собственных нужд российскими  юридическими лицами» (https://regulation.gov.ru/projects/160484/ ). 

Вступление в силу этого Постановления планируется с 1 марта 2026 года. 

До 1 марта 2026 Правительство должно будет утвердить порядки ведения 3-х новых  специализированных реестров, назначить нового единого оператора реестров, а также сформировать состав комиссий для проработки подзаконных актов и  дальнейшего мониторинга исполнения. Новые реестры: 

• Перечень значимых разработчиков (решения которых допускаются в  государственные и критически важные проекты);

• Перечень доверенного ПО (соответствие требованиям ФСБ и ФСТЭК);

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

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

В качестве резюме

Компания Хоулмонт вложила более 20 чел./лет в развитие Flowable/Activity и Camunda  проектов, чтобы в России появился инженерный опыт разработки, поддержки и развития промышленных BPM движков. И сейчас вы можете воспользоваться нашими наработками совершенно бесплатно без регистраций, без запросов ТКП - просто прийти и скачать Community версию на GitFlic. 

Если вопросы КИИ и ЗОКИИ для вас не пустой звук - пожалуйста подключайтесь в наши TG каналы, для вас у нас есть решение. По свежим исследованиям CNews доля российских BPM-решений составляет порядка 85–90% новых внедрений. И этот процесс перехода уже не остановить. 

Подписывайтесь на канал BPM Developers — про бизнес-процессы: новости, гайды, полезная информация и юмор.