Задача: автоматизировать процесс, который сейчас идёт через переписку, таблицы и напоминания на словах. Вы открываете рынок решений, а там предлагают и BPM, и Low-code, и какие-то ESM-платформы. Каждое определение звучит так, будто именно оно решает именно вашу задачу.

Low-code, BPM и ESM-платформы — взаимозаменяемы или нет? Решают ли они одну задачу? Как формировать стратегию автоматизации, если отличия не понятны? Если запутаться в терминах, есть риск выбрать не то, что нужно для вашей задачи. Разберёмся, что может каждое из трёх решений.

Почему понятия путают

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

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

И еще надо обратить внимание, кто принимает решение о покупке. Раньше выбором инструмента для автоматизации занимался ИТ-отдел, и терминология внутри команды была более-менее согласована. Сейчас решение часто принимает HR-директор, финансовый контролёр или руководитель административного блока — человек, для которого BPM, Low-code и ESM звучат как синонимы, потому что все три обещают избавить от рутины. Разницу можно почувствовать месяцев через шесть использования, когда выясняется, что купленный инструмент не умеет того, что должен был уметь по замыслу задачи.

Разберёмся с определениями

Термины BPM, Low-code и ESM обозначают разные вещи, но в разговоре о них редко фиксируют, что именно сравнивается: методология, класс софта или организационный подход. Спорить «что лучше» бесполезно, люди на самом деле обсуждают разные уровни задачи, просто называют их одним словом. Дальше — определение каждого подхода по отдельности, без сравнения между собой.

BPM/BPA

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

Где используют:

• Процессы с чёткими правилами и предсказуемой последовательностью шагов — банковские операции, госуслуги, комплаенс.

• Контроль KPI/SLA в реальном времени с автоматическими алертами при отклонениях.

Где ограничение:

• Не предназначен для создания полноценных пользовательских интерфейсов и клиентских приложений — только для оркестрации шагов процесса.

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

• Нет единой среды для смешивания No-code/Low-code/Pro-code — либо настройка через интерфейс, либо отдельный скрипт, без плавного перехода между ними.

Low-code

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

Где используют:

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

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

Где ограничение:

• Гибкость визуального конструктора не бесконечна — сложные интеграции и нетривиальная бизнес-логика всё равно требуют pro-code части.

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

ESM

— подход, переносящий сервисные принципы ITSM (каталог услуг, SLA, единая точка входа, роли и маршрутизация) с ИТ на остальные подразделения — HR, АХО, финансы, юрдепартамент.

Где используют:

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

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

Где ограничение:

• Требует организационной зрелости: без готовности подразделений формализовать свои процессы через каталог услуг эффект не достигается — это не разовая установка софта, а изменение способа работы.

• Основная выгода реализуется не сразу, а по мере расширения охвата на новые подразделения.

Как обстоят дела в индустрии автоматизации

Долгое время BPM существовал как отдельная категория софта со своим рейтингом: аналитики Gartner ежегодно сравнивали вендоров внутри Magic Quadrant for iBPMS, оценивая, кто сильнее в оркестрации сложных процессов. В 2021 году Gartner закрыл этот рейтинг и заменил его на Market Guide for Business Process Automation — формат, который просто описывает рынок и его направления, без ранжирования лидеров и претендентов. Причина в том, что BPM перестал существовать как самостоятельный продукт: сегодня Gartner описывает BPA как одну из нескольких технологий внутри общей Low-code линейки, рядом с RPA и интеграционными платформами, и вендоры комбинируют эти технологии внутри одной системы, а не продают их по отдельности. Покупателю нет смысла искать отдельную BPM-платформу в чистом виде, рынок уже устроен по-другому.

Low-code прошёл похожую трансформацию, но по другой оси — сменился не статус категории, а её аудитория. По данным Gartner, доля пользователей Low-code вне ИТ-отдела выросла с 60% в 2021 году до прогнозируемых 80% к 2026 году. Инструмент, который создавался для разработчиков, теперь настраивают HR-специалисты, бухгалтеры и административные команды, и это меняет требования к самой платформе. Интерфейс и логика работы должны быть понятны человеку без технического образования, а не только программисту.

В свою очередь ESM-системы не конкурируют с BPM или Low-code за одну и ту же задачу — технически они строятся на Low-code фундаменте (движок разработки, конструкторы форм и workflow), а логику согласований, маршрутизации и эскалаций реализуют как встроенную функцию сервисных инструментов, а не как отдельный модуль, который нужно покупать и подключать сбоку. Поэтому расширение ESM на новое подразделение не требует покупки BPM-системы или Low-code платформы — используется тот же слой платформы, просто с новым каталогом услуг и правилами для конкретного отдела. В отчёте Gartner «How to Build a Successful Enterprise Service Management Program» 45% руководителей называют главной ценностью ESM не покупку нового софта, а максимизацию отдачи от уже сделанных инвестиций в ITSM, то есть перенос уже работающей модели на новые подразделения (при этом не навязывать правила ИТ и ITSM другим отделам, а предоставить им те же инструменты, такие как контроль SLA, каталог услуг).

Как ESM, BPM и Low-code работают вместе

BPM-логика отвечает за формализованные сквозные процессы, где заранее известны шаги, роли и сроки — согласование договора, обработка обращения от клиента, выдача доступа новому сотруднику. Эта логика реализована внутри ESM-платформы как встроенный механизм маршрутизации и эскалаций.

При этом строгая BPMN-нотация — не единственный способ формализовать процесс. Внутри Low-code платформ (и в Low-code инструментах самих ESM-решений) чаще всего есть свой визуальный конструктор рабочих процессов: он не требует моделирования по стандарту BPMN и разработки со стороны программистов, а значит бизнес-аналитик или администратор процесса может собрать маршрут согласования сам, перетаскивая шаги в визуальном редакторе.

Low-code берёт на себя ту часть задачи, где готового шаблона процесса нет — нужно быстро собрать форму заявки, кастомное приложение под задачу конкретного отдела или адаптировать существующий процесс под изменившиеся правила. Если ESM-платформа построена на Low-code фундаменте, эта настройка происходит средствами самой платформы: специалист отдела собирает форму или меняет маршрут через визуальный конструктор, без обращения к команде разработки.

ESM в этой связке задаёт масштаб и единые правила игры для всей компании: каталог услуг, к которому обращается сотрудник любого отдела, единую точку входа и общую логику SLA. Когда компания расширяет автоматизацию, например, с запросов в ИТ на HR или АХО, она не создаёт для нового отдела отдельную инфраструктуру — использует те же слои платформы, куда уже встроены BPM-логика и Low-code инструменты, просто наполняя их новым каталогом и правилами конкретного подразделения.

Пример

Мы уже рассказывали о возможностях No/Low/Pro-code разработки на SimpleOne: в каталоге на 1500 услуг нельзя вручную прописать правило маршрутизации для каждой — это BPM-задача (кто обрабатывает заявку), но типовыми средствами она не решается. Решением стал один Low-code скрипт, который сам достаёт исполнителя из справочника услуг. Логика маршрутизации осталась той же, Low-code просто снял ограничение «одна услуга = одно жёстко прописанное правило».

Резюме

Так есть ли разница? Да, но не в в смысле что лучше, а в том смысле, что все три решения — это три разных слоя одной задачи автоматизации. BPM/BPA — это логика жёстко формализованного процесса (кто, в каком порядке, с каким сроком). Low-code — инструмент, чтобы быстро собрать под эту логику форму, приложение или нестандартный маршрут без разработчика. ESM — рамка, которая масштабирует и то, и другое на всю компанию через единый каталог услуг и правила SLA. 

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