Мы инженерная компания, которая занимается производством инструментов и платформ для корпоративной разработки. Недавно перевыпущенный для Jmix BPM-плагин активно набирает популярность в России и в мире. Мы получаем обратную связь от разработчиков и руководителей проектов. Многие сетуют на ограниченность BPMS. Он мёртв, окончательно и бесповоротно.

Ну просто потому, что для сколь-либо понятных и устоявшихся на рынке деловых или отраслевых процессов уже представлены специализированные платформы, а настроить что-то прорывное и кастомное на единой унифицированной BPMS платформе всё равно невозможно. Вендоры в погоне за расширением рынка превратили свои платформы в неповоротливых монстров по мере перетаскивания в коробки удачных фичей с клиентских проектов. Особенно веселят модули процессной аналитики, которые почти никто не использует. Нет области применения для этого класса систем, она сузилась до того предела, за которым содержать отдельную большую платформу в контуре предприятия становится экономически нецелесообразно. На смену идет процессная разработка на open-source стеке и с более высокой инженерной культурой внутри организации, необходимой для скорейшего восприятия и адаптации под нужды предприятия новых технологических возможностей (облака, роботы, ИИ и т. п.).

Цифровая и бизнес трансформация

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

У российского бизнеса уже сформировалось понимание того, что цифровая трансформация — это не только “маркетинг”, это реальный способ вписаться в новый мир, где существенно сокращаются операционные издержки, сокращается по абсолютной величине time-to-market, появляются инструменты и практики для пилотирования и рыночных экспериментов. Кроме того, становится очевидным, что импортозамещение – наиболее экономически эффективный путь адаптации к санкциям. Поэтому в долгосрочной перспективе российский ИТ-рынок, и в том числе сегмент процессного управления, будет расти.

Однако, расти он будет неравномерно. Давайте посмотрим, чем отличаются от BPMS классы других корпоративных систем, имеющих “под капотом” условно те же процессные движки, но при этом вполне уверенно чувствующих себя на рынке.

Платформы, которые “выжили”

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

• ECMS — обеспечивают жизненный цикл контента, как внутреннего, так и внешнего по отношению к предприятию.

• CRM (как операционный, так и аналитический) — помогают сформировать и поддерживать воронку продаж, как правило, включают в себя хранилище данных и мощный аналитический инструментарий, предназначенный для расчета потребительских профилей/корзин и параметров Next Best Action/Product/Offer.

• DMS (СЭД/СУД) — опираются на очень узкую сущностную модель, но при этом достаточно сильно регламентированную со стороны деловой практики или требований законодательства, закрывают огромное число операционных поддерживающих процессов.

• ITSM — помогают организовать ИТ-обслуживание “внутреннего клиента”, развивая в компании сервис-ориентированный подход в оказании взаимных услуг между подразделениями.

Почему они выжили? Потому что это по сути специализированные прикладные конфигурации, построенные поверх BPMS и способные самостоятельно развиваться. При этом “чистая” BPMS оказалась нежизнеспособной.

Плюсы и минусы BPMS

Попробуем подробнее разобраться почему, выделим её сильные и слабые стороны.

Сильные стороны BPMS:

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

• Комплексность, задачи решаются единым набором инструментов и исполняются потом в едином контуре.

• Понятное, достаточно простое лицензирование.

• Обучение, заказная разработка, внедрение и поддержка от вендоров.

Слабые стороны BPMS:

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

• В силу унификации платформы операторам часто приходится заполнять много “лишних” полей, не имеющих непосредственного отношения к решаемой задаче, а аналитикам из-за программных ограничений приходится использовать “весьма развесистые” схемы процессов, чтобы учесть всю вариативность путей согласования или способов исполнения задач (отсутствие или весьма ограниченная поддержка DMN и механизма компенсаций приводит к “адской лапше” в реальных процессных диаграммах).

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

• Сложность поддержки “кастомных” процессов, критичных к компонентам платформы.

• Невозможно или сильно ограничено расширение контекста и создание новых пользовательских сущностей, для которых в системе не было заранее предусмотрено “базовых классов” (простейший пример с согласованием отпусков — руководитель или тимлид не может просто так “жмакнуть кнопку”, ему необходимо посмотреть текущую загрузку команды, дедлайны, пересечения, понять заявлялся ли этот срок отпуска изначально или уже несколько раз переносится, то есть ему необходим контекст, который реализуется доступом во внешние базы данных и/или поднятием каких-то дополнительных экранов прикладных сущностей).

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

• Невозможно или технически трудно/затратно организовать омниканальное взаимодействие пользователей с исполняемым экземпляром процесса, так как вендорские API не в полной мере могут поддержать специфические ограничения, накладываемые со стороны служб информационной безопасности, и не везде поддерживается  паттерн External task (он подразумевает создание задачи, которая может быть выполнена внешним обработчиком, реализованным на любом языке программирования с помощью любых инструментов, которые могут выполнять HTTP-запросы).

• Невозможно или крайне затруднительно перенести из одной BPMS в другую описания процессов так, чтобы они потом заработали (проще переписать все в новой BPMS “по мотивам”), получается, что с исторически выбранной BPMS потом невозможно будет “соскочить”.

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

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

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

BPM как технология

Однако, рынок хорошо воспринимает BPM как технологию, и с этой точки зрения рынок активно растёт. Большинство компаний-заказчиков достигли «цифровой зрелости» и стали формировать повестку автоматизации и внедрения процессных систем более осознанно, с ориентацией на потребности своего бизнеса и высокой детализацией запросов/ТЗ. Отмечается увеличение объемов и сложности проектов. Если раньше BPMS использовались в основном для небольших проектов и отдельных классов систем, то сейчас всё больше запросов связано с автоматизацией сложных нестандартных процессов. Усиливается значимость гибкости и адаптивности процессных систем: бизнес-среда достаточно быстро меняется, требуется постоянно корректировать процессы, вводить новые сущности, расширять контекст исполнения. Поэтому с каждым годом усиливается тренд на возможность адаптировать единую процессную систему под самые сложные кейсы или научиться разбивать ее на модули, максимально эффективно реализующие прикладную задачу, но при этом работающие по единым принципам.

И получается, что рынку уже не нужны новые всеобъемлющие BPMS, выполненные в виде замкнутых программных контуров. Этот путь тупиковый.

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

Платформы процессной разработки

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

Сильные стороны платформ процессной разработки:

• Полная и безоговорочная поддержка промышленного стандарта BPMN 2.0.

• Модульность и расширяемость, фокусировка на оптимальном решении задач для команд разработки, исполнения, саппорта и управления, при этом каждая из команд может выбрать и использовать только те инструменты, которые реально востребованы в их проекте или в их типе деятельности.

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

• Interoperability в смысле способности к взаимодействию или функциональной совместимости, когда команды разработки могут продолжать использовать привычные им инструменты, такие как StormBPMN или Camunda Modeler, различные IDE оболочки и плагины для них в сочетании с инструментами от новой процессной платформы.

• Возможность низкоуровневого дизайна и программирования прикладных сущностей и интеграций в сочетании с развитыми IDE-инструментами (инженерный low-code).

• Возможность использования любых фронтовых решений для организации исполнения пользовательских задач, либо полный отказ от "формочек” с переходом на парадигму Event-Driven BPMP.

• Поддержка подходов Cloud Ready, заключающихся в возможности использовать дешевые и легко масштабируемые сервисы типа Cloud Functions и Serverless Containers, а также органичное сочетание высокой степень защиты коммерческих данных с возможностями передать на обработку минимально достаточный ограниченный контекст.

• Простота подключения AI агентов, как ныне существующих, так и потенциальных.

• Построение кластерных конфигураций для исполнения процессов на open-source движках, таких как Activiti, Flowable или Camunda, возможность подключения перспективных API-совместимых движков, находящихся в стадии разработки.

Слабые стороны этих новых систем:

• Слабая функциональность модулей, пока ещё слабая.

• Слабая документация и наработка по лучшим практикам применения, пока нет единого репозитория с шаблонами отраслевых бизнес-процессов и метрик по оценке эффективности, все в стадии становления.

• Недостаточная формально-правовая обвязка под требования российского законодательства.

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

“Похоливарить” об актуальных требованиях к инструментам разработки процессных приложений приглашаем в комментарии и на наш запуск проекта OpenBPM 5 февраля. Мы представим свое видение на разработку BPM решений, результатом которого стала новая open source платформа.

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