Рынок стал требовательнее к платформам

Системы управления бизнес-процессами (BPM, Business Process Management) долгое время помогали наводить порядок в маршрутах, согласованиях и ручных операциях. Сегодня крупным заказчикам важна не просто автоматизация отдельных процессов, а способность платформы объединять данные, пользователей, документы, внешние системы и аналитические инструменты.

Конкурентная борьба смещается в сторону платформенных возможностей: архитектуры, интеграций, безопасности, инструментов быстрой разработки без глубокого программирования и готовности к внедрению искусственного интеллекта. Рынок при этом сохраняет динамику: по оценке BPMSoft, за последние два года выручка российских разработчиков BPM-систем росла в среднем на 13–15% ежегодно, около 60% крупных компаний назвали уход иностранных вендоров главным драйвером цифровизации, а сегмент лицензий в ближайшие два года может остаться на уровне ₽11 млрд.

Вот переписанный HTML-контент с сохранением всех тегов и смысла, но с изменёнными формулировками и структурой предложений:

С точки зрения продуктовой стратегии, это подразумевает переход от разрозненных функций к единой платформенной архитектуре. Генеральный директор Elma Наталия Долженкова подчёркивает, что low-code стал общепринятым стандартом в отрасли и больше не является конкурентным преимуществом: клиенты отдают предпочтение платформам, способным охватывать несколько контуров без потери контроля.

Дополнительное давление на разработчиков оказывает искусственный интеллект. Ведущий аналитик Comindware Игорь Простоквашин характеризует текущий этап как «гонку догоняющих»: вендоры стремятся определить границы применения ИИ в системах управления бизнес-процессами (BPMS) и выбирают между традиционным развитием продукта и его адаптацией к новой технологической парадигме.

Практическим следствием этих изменений становится расширение круга пользователей BPM-систем. По словам руководителя направления «Автоматизация бизнес-процессов» компании «Диасофт» Никиты Маркелова, BPMS больше не воспринимаются просто как инструмент для проектирования и выполнения процессов. Современная система должна служить рабочим инструментом для всей команды, включая бизнес-пользователей без технического образования.

Базовая функциональность стала шире

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

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

Аналогичный набор требований называет генеральный директор BPMSoft (ИТ-холдинг Lansoft) Юрий Востриков: управление бизнес-правилами, кейс-менеджмент, развитые интеграционные механизмы и полноценный low-code-контур. Поэтому открытый программный интерфейс, готовые коннекторы и понятная интеграционная архитектура становятся обязательными условиями для промышленного внедрения.

Разработка смещается ближе к бизнесу

Инструменты быстрой разработки без глубокого программирования (low-code и no-code) изменили роль BPM-систем. Раньше настройка процесса почти всегда зависела от ИТ-команды или внешнего интегратора. Теперь часть изменений может выполнять бизнес-аналитик: собрать форму, изменить маршрут, настроить справочник, добавить простой прикладной сценарий.

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

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

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

Искусственный интеллект становится частью процесса

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

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

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

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

В условиях промышленной эксплуатации на первый план выходят права доступа, логи, аудит, работа с корпоративными знаниями и размещение языковых моделей в инфраструктуре заказчика. Эти требования к применению ИИ в процессах выделяет Наталия Долженкова.

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

Процесс необходимо измерять после запуска

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

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

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

Собственная система редко становится заменой BPMS

Средства быстрой разработки без глубокого программирования, такие как low-code, no-code и искусственный интеллект, снизили планку создания прикладных решений. Компания способна быстрее собрать внутренний сервис, форму заявки, простой портал или сценарий согласования. Однако собственная BPM-платформа представляет собой задачу совершенно иного масштаба.

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

Разработка платформы собственными силами требует значительных ресурсов. Наталия Долженкова подчеркивает, что создание с нуля процессного движка, моделлера, механизмов прав, аудита, отказоустойчивости и ИИ-слоя редко дает бизнесу конкурентное преимущество. Гораздо разумнее собирать прикладные решения на базе зрелой платформы.

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

Внедрение стартует с выбора процесса

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

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

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

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

После запуска начинается развитие

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

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

Игорь Простоквашин подчеркивает: BPMS не следует рассматривать как проект с фиксированной датой завершения — это операционная деятельность. Если после внедрения отложить платформу в сторону, она перестанет соответствовать потребностям бизнеса и начнет создавать препятствия в работе.

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