На рынке BPM никогда не было хайпа — концепция сформировалась в начале 2000-х, поступательно развиваясь, показывая ежегодный рост рынка соответствующих решений около 10%. За точку отсчета можно взять появление первого магического квадранта Gartner, посвященного BPMS, хотя первые дискуссии вокруг концепции начались раньше [1, 2]. Объем рынка тогда оценивался примерно в 1,7–1,8 млрд долл. или менее 1% от всего рынка корпоративного ПО, превышавшего 200 млрд.

Легко строить прогнозы, когда рынок спокойно растет линейно — завтра будет примерно то же, что и вчера, но чуть больше и лучше. Ошибиться сложно — достаточно взять старую презентацию, стряхнуть с нее пыль, добавить модных терминов, и готов актуальный доклад. Чтобы шагать в ногу со временем, в 2012 году аналитики Gartner к BPM добавили названию 'i', как это тогда было модно после выхода «айфона», и появился iBPMS — «умный BPMS», хотя реально ничего не поменялось (см. Рисунок). На волне увлечения «цифрой» аналитики из Forrester попробовали переименовать на новый манер и автоматизацию процессов — Digital Process Automation (DPA), но сообщество идею не оценило.

BPM в точке бифуркации: утраченная идентичность
Хронология наименования рынка управления бизнес-процессами.
Источник — канал BPM Developers https://t.me/bpm_developers

Конечно, и в этом в стакане воды периодически случались бури. Например, когда семь лет назад поднялся ажиотаж вокруг RPA — это стало вызовом для BPM. Появились утверждения, что роботизация бизнес-процессов «заменит миллионы рабочих мест» и мир на пороге «следующей революция автоматизации», а аналитики из Forrester и Gartner называли рынок RPA «самым быстрорастущим сегментом корпоративного ПО», предрекая ему ежегодный рост более 60%. Однако этот пузырь быстро сдулся и скоро стало ясно, что RPA — это, по сути, экранные скрипты — хрупкие к любым изменениям интерфейса, слабопригодные для сквозных процессов и дорогие в сопровождении. Они неплохо решали частные задачи «малой автоматизации», но не годились для интеграции и оркестрации корпоративного уровня. Поставщики BPM с облегчением выдохнули.

Потом все резко метнулись в сторону Low-code — в 2020 году аналитики Gartner выпустили Magic Quadrant for LCAP (Low Code Application Platform), куда переехали и некоторые бывшие BPM-вендоры (Appian, Pega и др.). Однако в этом была какая-то надуманность, ибо Low-code — это про быстрое создание простых приложений, тогда как в корпоративных системах основная нагрузка приходится не на рисование «формочек», а на архитектуру, интеграцию, надежность, устойчивость к высоким нагрузкам и пр., что гражданским разработчикам обеспечить явно не под силу.

Затем аналитики предложили еще одно словечко – Hyperautomation, которым попытались накрыть и BPM, и молодой, но уже потрепанный RPA, постоянно обещающий чудеса Process Mining, но... завтра, и Low-сode, который одновременно и рядом, и внутри BPM. В итоге получилось слишком тяжеловесно и расплывчато для употребления.

В конце концов, попытались вбросить новый термин — BOAT (Business Orchestration and Automation Technologies), но в эту «лодку» уже никто не захотел садиться, термин звучал уж совсем вымучено.

А что сейчас? Разброд и шатание. Продолжать говорить про старый BPM — отдает нафталином, хотя задачи никуда не делись и автоматизировать процессы надо. Гуру аналитики уже ничего внятного не говорят, хотя маркетологи не унимаются: Process Automation, Intelligent Automation и т. д. Все вроде бы верно, но ни один из этих ярлыков не стал общепринятым. В итоге сейчас это рынок без названия — нечто про автоматизацию процессов в широком смысле.

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

BPM снова на распутье

Итак, у рынка BPM кризис самоидентификации — нет ясного и общепринятого названия, а значит, нет и четкого позиционирования. Иными словами, вендоры не могут внятно объяснить, чем они занимаются и чем отличаются, а заказчики не понимают, что именно покупают, и это мешает им двигаться дальше.

Последний Magic Quadrant по iBPMS вышел в 2019 году и был закрыт — специалисты Gartner переключились на LCAP и гиперавтоматизацию. Аналитики Forrester пишут, что истинные вендоры BPM/DPA «испытывают давление» от Low-code и RPA, хотя пытаются их включать в один рынок. Компания Camunda публично отказалась от участия в магических квадрантах по iBPMS, заявив, что эта категория ПО не соответствует их стратегии 'developer-friendly', и придумала себе собственную нишу Process Orchestration, что лишний раз свидетельствует — прежняя категория BPM размылась и уже не имеет четких границ.

Как же так получилось? Корпорации нормально сидели, пилили процессы, и вот опять — каждые несколько лет BPM приходится переизобретать себя заново, чтобы вписаться в новый бизнес-контекст. Другим технологиям, как, например, СУБД или виртуализации, будучи однажды взятыми на борт корпоративного корабля, вновь и вновь доказывать свою ценность не приходится. Они могут колебаться в глазах руководства или вовсе растаять, но содержательно не меняются [3]. С BPM ситуация иная — это, по сути, метатехнология — одновременно управленческая методология и технологическая платформа. Такой методико-технологический дуализм мешает четко определить, в чем ценность концепции. Примерно, как обычному человеку трудно понять, что частица это одновременно и волна — это можно выучить, но сложно представить.

Заигрывание с Low-сode — это уклон в сторону большей понятности, но примитивности. Зато польза более наглядна — быстро набросал формочки, и готово! А разговоры про оркестрацию — это поворот в сторону архитектуры, это концептуально, но менее понятно для топ-менеджеров. Теоретически можно скомбинировать эти качества в одном продукте, но соблюсти чистое позиционирование не получается. Такой продукт вынужден выступать в нескольких категориях, однако в разных номинациях сложнее попасть в число лидеров. Поэтому аналитики и пытаются придумать некую объединяющую категорию, но пока не очень успешно.

Великая тайная мечта BPM

А почему вообще так много внимания этому небольшому рынку? Ведь на общем фоне ИТ-бюджетов BPM практически не виден. Дело в том, что когда-то у BPM была тайная мечта — занять место ERP на корпоративном Олимпе, ведь ERP — это всего лишь некий планировщик ресурсов, управляющий склада и бухгалтер, а главный менеджер-то — это BPM, что и в названии звучит. Идея была в том, что процессы охватят все бизнес-функции — продажи, снабжение, производство, HR и пр., став единым контуром управления предприятием. Потому что все остальное просто ПО, а за BPM стоит методология процессного управления, это разговор на языке бизнеса.

Однако так не случилось. Ключевые вендоры ERP — SAP и Oracle быстро почуяли угрозу и встроили процессные функции в свои продукты, заперев клиентов внутри своих проприетарных экосистем. Кроме того, идея управления всем бизнесом из одной точки оказалась утопией — слишком разные горизонты у разных корпоративных систем, частоты изменений данных, глубина автоматизации процессов и т. п. Модель сквозного процесса хорошо смотрится за спинкой кресла CEO, но с трудом воплощается в виде автоматизированной системы.

В результате встать во главе у BPM не вышло. Но ореол заявки на величие остался до сих пор подогревая интерес к теме.

Конец гомеостаза

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

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

Основные факторы, которые сегодня давят на BPM:

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

Унесенные ИИ

Искусственный интеллект спутал все карты мира процессов. Теперь любой прогноз развития бизнеса надо строить с учетом ИИ.

Вчерашний лидер зрительских симпатий — Low-сode — под натиском ИИ внезапно оказался слабым звеном. Обнуляется сама идея иметь какие-то визуальные конструкторы, где бизнес-менеджер из-за боязни перед кодированием мышкой «накликивает» нужные ему приложения — ИИ-ассистент, если его правильно попросить, генерирует нужный код. Разумеется, это не значит, что все LCAP-вендоры в одночасье разорятся и уйдут с рынка. Но риски для них повысились, правда, большинство накопило «жирок», что позволит в очередной раз «переобуться на лету» — готовьтесь встречать VCAP (Vibe Coding Application Platform).

Что же до моделирования процессов посредством ИИ, то на этом поприще прорывов пока не наблюдается. Скорее всего, в ближайшем будущем ничего и не случится, потому что написать такой промпт, чтобы ИИ сгенерировал адекватную модель реального корпоративного процесса, будет сложнее и дольше, чем вручную построить BPMN. Наивно полагать, что можно по регламентам и должностным инструкциям автоматически создавать модели. Люди не работают по строго прописанным правилам и обычно находят возможности их обойти, иначе все процессы давно бы остановились — писаные правила не учитывают всех исключительных ситуаций. Однако, несомненно, появятся процессные генеративные помощники на основе ИИ (copilot), которые будут подсказывать, как сделать лучше, на лету валидировать модель и т. д. То есть бизнес-аналитики все равно будут нужны, но и инструменты у них станут «умнее».

Еще теплится надежда, что благодаря ИИ наконец-то выстрелит Process Mining и действительно станет возможным из цифровых следов в разных системах получать хотя бы черновик процесса. В связке с Task Mining это позволит увидеть реальную картину «как есть» и сравнить ее с моделью, а также находить узкие места и получать подсказки по возможным улучшениям.

А вот ИИ-агенты вряд ли несут какие-то риски для индустрии BPM. С точки зрения процесса агент, каким бы «умным» он ни был — всего лишь исполнитель. Процессу не важно, кто решает задачу — человек, микросервис, программный робот или искусственная нейронная сеть. Процессный движок только оркестрирует всех этих исполнителей ради общей цели. Скорее наоборот, когда люди наиграются с кубиками визуальных платформ рабочих процессов (n8n и др.) и сделают небольшое интеллектуальное усилие для освоения нотации BPMN, управлять агентами им станет проще. Так что ажиотаж вокруг агентского ИИ пошел вендорам BPM только на руку.

Облака «съедают» процессы

Интеграционные платформы — iPaaS (Integration Platform as a Service), вроде MuleSoft, Boomi, Informatica Cloud, Jitterbit и пр. сегодня захватывают территории процессного мира. Пока BPM-инженеры спорят о нотациях и моделях, iPaaS-вендоры тихо перестраиваются в универсальный слой оркестрации, где можно буквально в несколько кликов «протянуть поток» между CRM, ERP и SaaS.

Коммодитизация облаков сделала оркестрацию частью инфраструктуры. Теперь процессы не строят — они возникают в виде побочного продукта интеграций. И чем глубже интеграция, тем крепче зависимость. Оркестрация в облаке означает не просто автоматизацию, а новый уровень «vendor lock-in»: логика бизнес-операций становится неотделимой от платформы, а миграция — почти невозможной.

Для BPM давление облаков не столько технологическое, сколько онтологическое —само понятие «процесс» растворяется в инфраструктуре, iPaaS продает интеграцию как процесс — и рынок в это верит. Чтобы выжить, BPM следует не конкурировать с облачными шинами, а встраиваться поверх них, быть тем, кто видит весь поток и управляет им, а не просто проталкивает данные от одного API к другому. Однако убедить в этом бизнес сегодня не просто.

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

В эпицентре событийного шторма

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

Но, как и в природе, массовое разнообразие породило новый хаос — тысячи автономных сервисов начали обмениваться сообщениями, каждый на своем языке и в своем ритме. Мир приложений ожил, но его пульс превратился в гул — бесконечный поток событий, который уже никто не в состоянии охватить полностью. Так решение одной проблемы породило другую — вместо неповоротливых монолитов получился событийный шторм, в котором стало трудно различить, где начало, где конец и кто вообще задает порядок, стала нормой EDA (Event-Driven Architecture).

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

Во-первых, как оркестратор BPM летает слишком высоко — он оперирует бизнес-контекстом, а не API и событиями. Микросервисная архитектура живет ниже — оркестрация здесь идет через очереди, брокеры и вызовы функций. Получился разрыв слоев: BPM говорит на языке активностей и задач, микросервисы — на языке JSON и Kafka, а между ними нет естественного моста.

Во-вторых, исторически BPM-движки — это движки с сохраненным состоянием (stateful): запоминают контекст, токены и историю, что обеспечивает надежность, но снижает производительность. Микросервисы своего состояния не помнят (stateless) и масштабируются горизонтально. Когда BPM оказывается в их контуре, он становится узким местом — каждый переход фиксируется в базе, а каждая транзакция требует сохранения. Отсюда возникает ощущение, что BPM «тормозит».

В-третьих, налицо культурный конфликт — порядок против скорости. DevOps и микросервисная культура родились из идеи 'move fast and fix later' («быстро двигаемся, а ошибки исправим позже»). BPM, наоборот, символизирует управление, контроль и следование регламентам. Для архитекторов, выросших на CI/CD, BPM кажется слишком бюрократизированным — им не нужен централизованный дирижер, но они хотят «хореографию», где каждый сервис сам решает, когда выступить.

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

Highload как новая угроза

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

Сегодня все иначе. Скорость бизнеса выросла на порядки, а вместе с ней и плотность событий, которые нужно мгновенно обработать и связать воедино. Процессы перестали быть долгоживущими историями. Классическая архитектура BPM-движков этого не выдерживает. Чтобы запрыгнуть в этот экспресс, например, компания Camunda полностью переписала свой движок, научила его жить без реляционной СУБД и дала ему новое имя Zeebe. Однако этому примеру последовали не все, например, компания Flowable продолжает развиваться эволюционно, наращивая производительность в рамках прежней архитектуры, и способна вытянуть сотни тысяч экземпляров процессов в час, что пока еще подходит для большинства корпоративных задач.

По-видимому, многие игроки этого рынка предпочитают остаться в привычной зоне комфорта, где процессы — это про SLA, комплаенс, неспешные пользовательские задачи, а не миллионы событий в минуту. Неудивительно, что архитекторы, выбирая подходящий инструмент для оркестрации высоконагруженных событийных процессов, посматривают в сторону Temporal и аналогичных решений durable execution frameworks, в которых «оркестрация как код» выполняется распределенно, но надежно и с минимальной зависимостью от внешних баз данных.

Однако именно BPM остается единственным инструментом, который способен сделать сложные цепочки управляемыми и видимыми. Но в мире, где скорость становится новой валютой, прозрачность перестает быть главным аргументом. Побеждает тот, кто умеет исполнять процессы не только правильно, но и мгновенно. И именно здесь решается судьба классического BPM — сумеет ли он остаться дирижером, когда оркестр уже играет в темпе highload?

BPMN 3.0, которого не будет

Появились сомнения во всемогуществе нотации BPMN 2.0, которая отвечала эпохе неторопливых линейных и предсказуемых процессов, отлично описывая мир, где каждое действие имело начало, конец и согласованное место в диаграмме. Но сегодня бизнес живет не в координатах последовательностей задач, а в потоках событий. Реальность асинхронна, распределена и вероятностна. И там, где BPMN ждет четкого маршрута, события происходят одновременно — и без дирижера, и без репетиций.

Была попытка решить это противоречие с помощью кейс-менеджмента, но соответствующая нотация CMMN (Case Management Modeling Notation) получилась такой громоздкой и непонятной, что эту попытку можно и не засчитывать. Единственная компания, которая смогла в ней разобраться, — это Flowable.

Однако недостаток выразительных средств для новых сценариев, ориентированных на многопоточность, событийность и участие ИИ-агентов, ощущается очень остро. Та же Camunda для оркестрации агентов использует ad hoc-подпроцесс — всеми забытый и невостребованный в моделях элемент BPMN.

Вот если бы OMG (Object Management Group) озаботилась раньше и выпустила бы BPMN 3.0, чтобы отреагировать на все новые вызовы, но этого уже не будет. Брюс Сильвер, один из главных евангелистов BPMN, поднимал эту тему еще в 2016 году, высказываясь с изрядным скептицизмом. С тех пор подвижек не было.

Сейчас рынок уже далеко ушел от стандарта BPMN 2.0. Вендоры изобретают свои расширения и дополнения BPMN (Camunda, Flowable и др.), формально оставаясь в рамках нотации или вовсю моделируя процессы другими средствами — Workflow as Code (компании Temporal, Argo). Интересно произошло с движком Zeebe, который на вход принимает BPMN, но не интерпретирует XML, как делают традиционные движки, а компилирует модель во внутреннюю state-machine, которая хранит состояние в event log (наподобие Kafka или RocksDB) и исполняет задачи распределенно. То есть Zeebe — это архитектура Workflow-as-Code с лицом BPMN. На поверхности — те же квадратики и ромбики, а внутри — highload-runtime, родственный решениям от Temporal и Argo.

Как сказал бы Сирил Норткот Паркинсон, автор законов своего имени, комитеты не умирают, а просто продолжают заседать — и BPMN 3.0 застрял где-то между повесткой и протоколом. Нового стандарта не будет, а бюрократия в очередной раз победила здравый смысл. И это еще одна мина под нынешний рынок BPM.

Что год 2030 нам готовит

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

Вот несколько прогнозов на ближайшие годы.

  • BPM перестанет быть рынком. Это уже произошло — продукты стали настолько разными, что не получается объединять их в одну корзину. Отсюда и метания аналитиков с навешиванием ярлыков. То есть надо перестать мыслить в терминах «рынок BPM», рейтингов, лидеров и т. д., признав, что наличие графического редактора процессов еще не является определяющим фактором для формирования рыночной категории.
  • BPM сохранит значимость как управленческая дисциплина. В бизнесе по-прежнему будет спрос на анализ и моделирование процессов, потому что это нужно для понимания, как работает предприятие и как можно оптимизировать его деятельность. «На земле» это будет означать, что продукты для описания и для автоматизации процессов разойдутся еще дальше — BPM будет управленческий и инженерный.
  • Low-code уйдет под зонтик 'AI AppGen'. Миссия Low-code была в ускорении создания приложений с помощью конструкторов-конфигураторов без привлечения профессиональных разработчиков, а сейчас реализуется с помощью LLM — меняется метод, но не цель. Основные LCAP-вендоры: Appian, Pega, IBM BAW, ServiceNow, Microsoft Power Platform найдут свою новую идентичность на этой поляне, которую сейчас формируют новички Replit, Lovable и др.
  • Оркестрация процессов станет отдельным направлением. Назвать это рынком — мелко, но типовым элементом архитектуры — вполне. Причем использование BPMN не будет обязательным, приветствуются также другие подходы, поэтому в одной группе окажутся и Flowable, и Camunda, и Temporal.
  • Process Mining выйдет из тени. До сих пор аналитика процессов была скорее экзотикой, чем общепринятой практикой, а теперь, благодаря ИИ, возможно, это направление расцветет.

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

***

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

Литература

1. Леонид Черняк. SOA — шаг за горизонт // Открытые системы.СУБД. — 2003. — № 9. — С. 35–4URL: https://www.osp.ru/os/2003/09/183385 (дата обращения: 21.10.2025).

2. Станислав Макаров. ECM: информация и процессы // Открытые системы.СУБД. — 2004. — № 8. — С.18–21. URL: https://www.osp.ru/os/2004/08/185073 (дата обращения: 21.11.2025).

3. Дмитрий Волков. СУБД: вчера, сегодня и завтра // Открытые системы.СУБД. — 2024. — № 3. — С. 12–19. URL: https://www.osp.ru/os/2024/03/13058759 (дата обращения: 21.11.2025).

Станислав Макаров (s.makarov@haulmont.com) — продуктовый аналитик Jmix BPM, компания «Холмонт», редактор канала BPM Developers (@bpm_developers), (Самара).