Процессы как код

Безлюдный бизнес-движок — это прежде всего движок процессов. Учёт, данные и агенты, о которых шла речь в предыдущих главах, остаются мёртвым капиталом, пока нет слоя, который превращает намерение («принять клиента на обслуживание», «закрыть месяц», «выставить счёт по всем юрлицам») в последовательность машинно-исполняемых шагов с гарантией доведения до конца. Эта глава — о том, как за пятьдесят лет индустрия научилась описывать бизнес-процессы формально и исполнять их программно: от реинжиниринга Хаммера и сетей Петри через BPMN-движки (Camunda, Flowable) к durable execution (Temporal.io), process mining (Celonis) и RPA-роботам, которые сегодня перерождаются в агентные платформы. Для проектировщика безлюдного движка это не история технологий, а меню архитектурных решений: какие процессы описывать диаграммами, какие — кодом, где встраивать человека, как измерять «безлюдность» через straight-through processing и как положить LLM-агентов на процессные рельсы так, чтобы они не разнесли бэк-офис. К концу главы вы должны уметь осознанно выбирать между BPMN-движком, durable-execution-платформой и оркестрацией агентов — и понимать, почему это на самом деле один и тот же вопрос, заданный трижды.

• 1962Сети Петри.

  Диссертация Карла Адама Петри — формальный фундамент: токены, переходы, машинно проверяемая корректность.

• 1990Реинжиниринг Хаммера.

  «Don't Automate, Obliterate» в HBR: устранять шаги, а не ускорять их. Кейс Ford: −75% численности.

• 2011BPMN 2.0 + Process Mining Manifesto.

  Диаграмма становится программой; ван дер Аалст формализует «рентген» процессов по журналам событий.

• 2011Celonis.

  Три студента из Мюнхена индустриализуют process mining; к 2022 — оценка $13 млрд.

• 2017RPA-бум.

  UiPath, Blue Prism, Automation Anywhere: «руки на клавиатуре» как обход отсутствия API. IPO UiPath 2021 — ~$35 млрд.

• 2019Temporal.io.

  Фатеев и Аббас (Cadence, Uber) выносят durable execution в отдельную платформу: процесс — это код + event history.

• 2024–26Agentic-конвергенция.

  BPM-, RPA- и durable-платформы сходятся к одной архитектуре: оркестратор + агенты + человек по исключению. Temporal — $5 млрд.

7.1. BPM как дисциплина: жизненный цикл и уроки реинжиниринга

Управление бизнес-процессами (Business Process Management, BPM) как дисциплина строится вокруг простого, но дисциплинирующего цикла: моделирование → исполнение → мониторинг → улучшение. Сначала процесс описывается явно — кто, что, в каком порядке и при каких условиях делает. Затем модель не кладётся в шкаф, а загружается в исполняющую систему, которая ведёт каждый экземпляр процесса (заявку, счёт, заказ) по описанному маршруту. Работающая система порождает журналы событий, по которым видно, где процесс буксует. Наконец, модель корректируется — и цикл повторяется. Ключевая идея BPM в том, что эти четыре фазы замкнуты в петлю обратной связи: модель — не документация, а управляющий артефакт, а данные исполнения — не отчётность, а сырьё для следующей итерации проектирования.

Интеллектуальная предыстория BPM — реинжиниринг бизнес-процессов (Business Process Reengineering, BPR). В июле 1990 года Майкл Хаммер опубликовал в Harvard Business Review статью «Reengineering Work: Don't Automate, Obliterate» (hbr.org), тезис которой стал классикой: компании десятилетиями использовали ИТ, чтобы ускорять существующие процессы, «мостить коровьи тропы» (paving the cowpaths), — вместо того чтобы воспользоваться технологией как поводом уничтожить устаревший процесс и спроектировать его заново. Канонический пример Хаммера — Ford: в отделе кредиторской задолженности работало около 500 человек, сверявших заказы, накладные и счета; изучив Mazda, где аналогичную функцию выполняли 5 человек, Ford перепроектировал процесс — оплата стала запускаться автоматически при приёмке товара, сверенного с заказом в общей базе, и счёт-фактура как документ вообще исчез из процесса. Численность сократилась примерно на 75%. Обратите внимание на механизм: не «робот быстрее вводит счета», а «шаг ввода счетов перестал существовать». Это различие — автоматизация шага против устранения шага — будет главным критерием качества решений на протяжении всей главы.

Реинжиниринг 1990-х, однако, закончился болезненно. Сами Хаммер и Чампи признавали, что порядка 50–70% инициатив BPR не достигали заявленных результатов; движение выродилось в прикрытие для массовых сокращений, проекты «большого взрыва» ломались о сопротивление людей и о то, что радикально перепроектированный процесс негде было исполнять — ERP-системы того времени зашивали процесс в код намертво. Уроки, которые индустрия вынесла и на которых вырос BPM 2000-х: во-первых, радикализм «с чистого листа» проигрывает итеративной петле улучшений; во-вторых, процесс, существующий только на слайдах, не управляем — нужна среда исполнения, где модель и реальность совпадают по построению; в-третьих, перепроектирование без данных о фактическом поведении процесса — гадание (ответом на это через 20 лет станет process mining). BPM в современном смысле — это BPR, лишённый мессианства и снабжённый исполняемыми моделями и телеметрией.

Для проектировщика безлюдного движка BPR даёт правильный порядок вопросов. Прежде чем автоматизировать процесс, спросите: должен ли он вообще существовать? Из процесса согласования счёта на пять подписей нельзя сделать хороший автоматический процесс — можно сделать быстрый плохой. Сначала obliterate (устранить шаги, существующие из-за недоверия, отсутствия общих данных или исторической случайности), потом automate то, что осталось.

7.2. Формальные основы: сети Петри и workflow patterns

Чтобы модель процесса можно было исполнять машиной и проверять на корректность, нужна формальная семантика. Исторический фундамент здесь — сети Петри (Petri nets), предложенные Карлом Адамом Петри в диссертации 1962 года. Сеть Петри — это двудольный ориентированный граф из позиций (places, рисуются кружками) и переходов (transitions, прямоугольники), соединённых дугами. Состояние системы задаётся разметкой (marking) — распределением токенов (фишек) по позициям. Переход может «сработать» (fire), когда во всех его входных позициях есть токены; срабатывание забирает по токену из входных позиций и кладёт по токену в выходные. Этот примитивный механизм выразителен ровно настолько, насколько нужно процессам: последовательность, ветвление по условию, параллелизм (переход с двумя выходными позициями порождает два токена — две параллельные ветки) и синхронизация (переход с двумя входными позициями ждёт оба токена) моделируются естественно, а главное — формально анализируемы.

Вил ван дер Аалст (Wil van der Aalst, Эйндховенский технический университет) в работе «The Application of Petri Nets to Workflow Management» (1998, полный текст) ввёл специальный класс — workflow-сети (WF-nets): сеть с единственной входной позицией i, единственной выходной o, где каждый узел лежит на пути от i к o. Экземпляр процесса — это токен, проходящий от i к o. Для WF-сетей определено ключевое свойство корректности — обоснованность (soundness): (1) из любого достижимого состояния можно дойти до завершения; (2) при завершении в сети не остаётся «забытых» токенов; (3) нет мёртвых переходов, которые не могут сработать никогда. Практический смысл: soundness — это машинно проверяемая гарантия отсутствия зависаний (deadlock) и «утечек работы» (activity, которая запустилась и повисла навсегда). Для больших классов сетей проверка выполняется автоматически (см. обзор «Soundness of workflow nets: classification, decidability, and analysis», van der Aalst и др., Formal Aspects of Computing, 2011). Здесь и лежит ответ на возражение «формальные модели — это бюрократия»: диаграмма в PowerPoint — бюрократия, потому что её никто не исполняет и нельзя верифицировать; формальная модель — инженерный артефакт, который компилируется в исполнение и статически проверяется, как проверяется типами программа.

Вторая опора — workflow patterns, каталог, который ван дер Аалст, тер Хофстеде, Кепушевски и Баррос начали публиковать с 2000 года (итоговая статья «Workflow Patterns» в Distributed and Parallel Databases, 2003; сайт workflowpatterns.com). Исходные 20 паттернов управления потоком (control-flow patterns), позднее расширенные до 40+, — это систематизация всего, что встречается в реальных процессах: от тривиальных Sequence, Parallel Split, Synchronization, Exclusive Choice до коварных. Например, Discriminator (из N параллельных веток продолжаем после первой завершившейся, остальные игнорируем), Milestone (активность разрешена, только пока процесс находится в определённом состоянии), Deferred Choice (выбор ветки делает не движок по данным, а внешняя среда — какое событие придёт первым), Multiple Instances (породить заранее неизвестное число копий подпроцесса — по строке на каждую позицию счёта). Практическая ценность каталога двоякая. Во-первых, это тест выразительности: авторы прогнали через паттерны полтора десятка коммерческих workflow-систем и показали, что большинство поддерживает лишь малую часть, — и этот бенчмарк заставил вендоров подтянуться (BPMN 2.0 проектировался с оглядкой на паттерны). Во-вторых, это словарь проектировщика: увидев в требовании «платим по первому из двух подтверждений» паттерн Discriminator, вы знаете и как его моделировать, и какие ловушки (что делать со второй веткой? отменять? дать дозавершиться?) он несёт.

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

7.3. BPMN 2.0, DMN и CMMN: три языка исполняемой работы

Стандарт BPMN 2.0 (Business Process Model and Notation, спецификация OMG, финализирована в 2011 году) решил проблему, убившую первое поколение BPM-систем: разрыв между картинкой аналитика и исполняемым кодом. До BPMN 2.0 аналитик рисовал диаграмму (часто в BPMN 1.x, который был только нотацией), а разработчик вручную переводил её в исполняемый язык (BPEL — XML-язык оркестрации веб-сервисов, безнадёжно неудобный для людей). Любое изменение проходило двойной перевод и накапливало расхождения. BPMN 2.0 совместил в одном стандарте нотацию, формальную метамодель и семантику исполнения: XML-файл диаграммы — это одновременно и картинка, и программа, которую движок исполняет напрямую. Семантика исполнения BPMN явно описана в терминах токенов — прямое наследие сетей Петри: токен рождается в стартовом событии, размножается на параллельном шлюзе, поглощается на завершающем событии.

Ядро языка компактно. Задачи (tasks) — атомарные шаги: service task (вызов кода/API), user task (работа человека, см. 7.6), script task, business rule task (вызов DMN). Шлюзы (gateways): эксклюзивный (XOR, выбор одной ветки по условию), параллельный (AND, все ветки), инклюзивный (OR, подмножество веток), событийный (deferred choice — ветку выбирает первое наступившее событие). События (events) — самая мощная часть BPMN: таймеры, сообщения, ошибки, эскалации; они бывают граничными (boundary events) — «прилипают» к задаче или подпроцессу и прерывают его: таймер на границе задачи «согласовать договор» реализует SLA («если за 48 часов не согласовано — эскалация») одной фигурой. Компенсационные события дают декларативную сагу: для каждого шага описывается компенсирующее действие («отменить бронь», «вернуть платёж»), и при сбое движок сам раскручивает выполненные шаги назад. Именно события и компенсации отличают промышленный процесс от «блок-схемы со стрелочками»: 80% сложности реального бэк-офиса — это не happy path, а таймауты, отмены и частичные сбои.

DMN (Decision Model and Notation, OMG, 2015) выносит из процесса то, чему в графе потока не место, — бизнес-правила. Ядро DMN — таблица решений (decision table): строки-правила, колонки-входы и выходы, выражения на дружелюбном языке FEEL (Friendly Enough Expression Language). Например, решение «нужна ли ручная проверка счёта» задаётся таблицей от суммы, контрагента и категории затрат. Критично свойство hit policy — политика срабатывания (Unique — правила не должны пересекаться, и движок это проверяет; First — приоритет по порядку; Collect — собрать все сработавшие), превращающая таблицу из документации в верифицируемую спецификацию: полноту и непротиворечивость таблицы можно проверить статически. Архитектурный смысл разделения BPMN/DMN: маршрут процесса меняется редко и дорого, пороги и правила — часто и дёшево; вынеся правила в DMN, вы меняете лимит «счета до 50 000 ₽ проходят без согласования» правкой одной ячейки, не трогая процесс и не передеплоивая его.

CMMN (Case Management Model and Notation, OMG, 2014) — третий язык триады, для работы, у которой нет заранее известного маршрута: разбор претензии, сложное расследование, онбординг нестандартного клиента. Вместо потока — кейс как контейнер: набор возможных задач и стадий, у каждой — условия активации (sentries: «если поступил документ X и стадия Y завершена — задача Z становится доступной»), обязательность и правила ручного запуска (discretionary items). Модель описывает не «что за чем», а «что возможно и что обязательно», порядок выбирает работник кейса. Честная оценка индустрии: CMMN не взлетел как отдельный стандарт — Camunda объявила о прекращении развития его поддержки ещё в 2019–2020 годах, и на практике кейс-менеджмент собирают из BPMN (событийные подпроцессы, ad-hoc-подпроцессы) плюс прикладной код. Но идеи CMMN важны: они точно очерчивают границу, за которой процессное моделирование потоком перестаёт работать, — и, забегая вперёд, именно эту нишу «неструктурированной работы со строгими инвариантами» в 2024–2026 занимают LLM-агенты (раздел 7.10).

7.4. Движки исполнения: Camunda, Flowable и место Airflow

Движок исполнения (workflow engine) — это интерпретатор процессных моделей, отвечающий за три вещи: хранить состояние каждого экземпляра, продвигать токены по модели и гарантировать, что ни один экземпляр не потеряется при сбоях. Различия движков — это различия в том, как решены эти три задачи.

Camunda 7 (форк Activiti 2013 года; Activiti, в свою очередь, вырос из jBPM-линии Тома Байенса) — эталон «встраиваемого» поколения: Java-библиотека, которая живёт внутри вашего приложения и хранит состояние процессов в реляционной БД. Продвижение токена — транзакция в базе: движок читает состояние, исполняет синхронно всё до следующей точки ожидания (wait state — user task, таймер, асинхронное продолжение), пишет новое состояние. Модель прозрачна и удобна (состояние процессов можно смотреть SQL-запросом), но масштабируется ровно до тех пор, пока масштабируется одна реляционная БД: все узлы кластера конкурируют за одни и те же таблицы, и на десятках тысяч экземпляров в секунду база становится бутылочным горлышком. Camunda 7 переведена в режим сопровождения: официальная поддержка community-версии завершилась в октябре 2025, расширенная поддержка enterprise-клиентов — заявлена до ~2030 года (непроверено) (см. разбор Pretius и обзор Altkom Software).

Camunda 8 построена вокруг нового движка Zeebe, спроектированного по лекалам распределённых логов, а не реляционных СУБД (архитектура в документации). Три ключевых решения. Первое — event sourcing: состояние экземпляра не перезаписывается в таблице, а восстанавливается из журнала команд и событий (append-only log); снимки состояния (RocksDB) — лишь ускоряющий кэш. Второе — партиционирование: пространство экземпляров делится на партиции (как в Kafka), каждый экземпляр живёт в одной партиции, партиции независимы — пропускная способность растёт добавлением партиций и брокеров (docs). Третье — репликация каждой партиции по протоколу консенсуса Raft (лидер + фолловеры), что даёт отказоустойчивость без общей БД. Клиенты не дергают движок синхронно: воркеры подписываются на типы задач (job workers) и забирают работу по gRPC-стримингу. Плата за масштаб — потеря SQL-доступа к состоянию (данные для поиска экспортируются в Elasticsearch) и эксплуатационная сложность кластера.

Flowable — второй форк Activiti (2016), сохранивший верность встраиваемой модели Camunda-7-типа и триаде BPMN+CMMN+DMN (в отличие от Camunda, Flowable до сих пор всерьёз поддерживает CMMN). Ниша — Java-организации, которым нужен зрелый встраиваемый движок с кейс-менеджментом, без распределённой машинерии.

Отдельно стоит Apache Airflow — и о нём важно сказать именно потому, что его регулярно путают с BPM. Airflow — оркестратор данных: DAG-и (направленные ациклические графы) задач, запускаемые по расписанию, где единица работы — батч («перелить таблицу, обучить модель»). Отличия фундаментальны: у Airflow нет понятия долгоживущего бизнес-экземпляра («заявка №4711 ждёт подписи 12 дней»), нет human tasks, событийная реакция вторична, циклы запрещены самой моделью DAG. BPM-движок ведёт миллионы маленьких долгих state machines, привязанных к бизнес-сущностям; Airflow прогоняет по расписанию большие короткие вычисления над данными. В безлюдном движке нужны оба слоя, и смешивать их — типовая архитектурная ошибка: биллинговый процесс в Airflow превращается в клубок сенсоров и костылей, ETL в BPMN — в бессмысленную визуальную обёртку над кодом.

7.5. Temporal.io и durable execution: код как процесс

Пока BPM-мир совершенствовал диаграммы, инженерная культура пошла другим путём и пришла к той же цели с противоположной стороны. Durable execution («надёжное/долговечное исполнение») — это идея, что процесс описывается не диаграммой, а обычным кодом на обычном языке, но исполнение этого кода переживает любые сбои: падение сервера, деплой новой версии, недоступность внешнего API, ожидание длиной в месяцы. Флагман подхода — Temporal.io, основанный в 2019 году Максимом Фатеевым и Самаром Аббасом, авторами движка Cadence в Uber (а до того — участниками разработки AWS Simple Workflow Service; Cadence, в свою очередь, до сих пор развивается как отдельный open-source-проект).

Механизм стоит понять точно, потому что он неочевиден и красив. Workflow в Temporal — функция на Go/Java/TypeScript/Python. Всё взаимодействие с внешним миром (HTTP-вызовы, запись в БД, отправка писем) вынесено в activities — отдельные функции с политиками повторов (retry policies: интервалы, backoff, максимум попыток). Сервер Temporal ведёт для каждого экземпляра event history — журнал событий: «workflow запущен с такими-то аргументами», «activity X запланирована», «activity X вернула такой-то результат», «таймер на 30 дней взведён», «сигнал получен». Сам код workflow исполняется воркером, и вот ключевой трюк: если воркер умер, любой другой воркер поднимает экземпляр репреем (replay) — заново прогоняет код workflow с начала, но вместо реального выполнения activities подставляет их записанные результаты из истории. Код детерминированно доходит ровно до того места, где остановился, и продолжает вперёд (walkthrough в документации). Цена трюка — требование детерминизма: внутри workflow-кода запрещены источники недетерминизма (текущее время, random, прямые сетевые вызовы, итерация по map в Go) — для всего этого есть API-обёртки; SDK ловит нарушения на репрее. По сути Temporal делает с кодом то, что Zeebe делает с BPMN: event sourcing состояния процесса, только «моделью» служит сама программа.

Что это даёт по сравнению с самописной оркестрацией через очереди и cron? Исчезает целый класс инфраструктурного кода: персистентность состояния «на каком шаге мы находимся», идемпотентность повторов, таймеры на недели (в Temporal sleep(30 days) — одна строка, не жрущая ресурсов), сага-компенсации, сигналы в живой процесс (signal — «клиент прислал документ»), запросы состояния (query). Инженеры полюбили это ровно за то, за что не полюбили BPMN: не надо учить нотацию и жить в чужом визуальном редакторе — процесс версионируется в git, тестируется юнит-тестами, рефакторится IDE. Обратная сторона симметрична: процесс на Go не прочитает операционный директор, и слой «модель как общий язык бизнеса и разработки» исчезает — его приходится восстанавливать документацией или надстройками.

Рынок подтвердил, что подход попал в нерв времени, и главный драйвер последних двух лет — агенты. В марте 2025 Temporal привлёк $146 млн Series C при оценке $1,72 млрд, прямо заявив ставку на agentic AI (TechCrunch); в феврале 2026 — уже $300 млн Series D при оценке $5 млрд от a16z, с выручкой, выросшей на 380% за год, и OpenAI среди клиентов (GeekWire). Формула CEO Самара Аббаса из этого анонса стоит того, чтобы её запомнить: «Agentic AI ломается не потому, что модели недостаточно хороши, а потому, что системы вокруг них не выдерживают реального исполнения». Агентный цикл — это длинный, падающий, ожидающий человека и внешних API процесс, то есть ровно то, для чего durable execution создавался; отсюда и волна: конкурирующие рантаймы (Restate, DBOS, Azure Durable Functions — старейший в жанре, Cloudflare Workflows, Inngest, Hatchet) плюс встраивание durable-семантики прямо в агентные фреймворки (LangGraph с чекпоинтами состояния — та же идея event history в миниатюре).

7.6. Human tasks: человек внутри исполняемого процесса

Парадоксально, но лучшая школа проектирования human-in-the-loop для AI-систем — это двадцатилетняя практика human tasks в BPM, отточенная задолго до всякого машинного обучения. Безлюдный движок — это не движок без людей, а движок, где человек появляется в процессе только явно, в спроектированных местах, и его участие обвязано теми же гарантиями, что и вызов API.

Механика человеческой задачи в исполняемом процессе устроена так. Когда токен доходит до user task, движок не «отправляет письмо человеку» — он создаёт запись задачи в очереди задач (task list) и приостанавливает эту ветку экземпляра. Задача имеет жизненный цикл: created → (assigned/claimed) → completed, с важным различием кандидатов (candidate groups — «любой из группы бухгалтеров может взять») и исполнителя (assignee — тот, кто взял, claim). Паттерн claim-based распределения решает классическую проблему: назначение на конкретного человека создаёт зависимость от его отпуска, назначение «всем» — безответственность; очередь с claim даёт и пул, и персональную ответственность после взятия. Поверх жизненного цикла навешиваются механизмы гарантий: SLA-таймеры — граничные события на задаче («не взята за 4 часа — уведомить тимлида; не завершена за 24 — переназначить»), эскалации — отдельный тип события BPMN, поднимающий проблему на уровень выше без отмены работы, делегирование и resolve (передал вопрос эксперту — задача вернулась к тебе). В стандартах это оформлено давно: спецификации WS-HumanTask и BPEL4People (2007) описали формальную модель ещё для SOA-эпохи; современные движки реализуют то же в BPMN.

Второй пласт — контроли, пришедшие из комплаенса. Four-eyes principle («принцип четырёх глаз», разделение обязанностей, segregation of duties): критичная операция требует двух разных людей — и в исполняемом процессе это не регламент на бумаге, а машинное ограничение: движок не позволит пользователю, создавшему платёж, стать исполнителем задачи его подтверждения (в Camunda это буквально выражение на задаче: исполнитель второй задачи ≠ исполнитель первой). Аналогично кодируются лимитные схемы («до 100 тыс. — одна подпись, выше — две, выше 1 млн — плюс CFO» — это DMN-таблица, выдающая список требуемых ролей) и запреты самоодобрения. Смысл для аудита колоссален: контроль, зашитый в модель процесса, доказуем — из журнала движка видно, что ни один платёж не прошёл мимо схемы, тогда как контроль в регламенте доказуем только выборочной проверкой.

Третий пласт — инбокс как продукт. В компаниях, живущих на движке, у сотрудника нет «работы в почте» — есть единая очередь задач со сроками, контекстом (форма задачи подтягивает данные экземпляра) и кнопками решений. Это радикально меняет управляемость: WIP (объём незавершённой работы), время реакции и пропускная способность каждой роли становятся измеримыми из коробки — метрики берутся из тех же журналов движка.

Важно увидеть в этом прообраз AI-эпохи: human task — это «вызов человека как сервиса» с таймаутом, ретраем (переназначением) и эскалацией. Когда в 2024–2026 агентные фреймворки заново изобретают human-in-the-loop (approval-шаги в LangGraph, «ждать подтверждения» в OpenAI/Anthropic-паттернах), они воспроизводят ровно эту модель — и команды, знакомые с BPM-опытом, просто меняют направление вызова: раньше процесс-автомат звал человека на решение, теперь процесс зовёт человека проверить решение агента. Формально это одна и та же фигура на диаграмме.

7.7. Process mining: рентген реальных процессов

Фаза «мониторинг → улучшение» жизненного цикла BPM десятилетиями держалась на интервью и воркшопах: аналитики спрашивали людей, как устроен процесс, и рисовали то, что им рассказали. Process mining заменил опросы рентгеном: реальный процесс восстанавливается из следов, которые он и так оставляет в информационных системах. Отцом дисциплины общепризнанно является всё тот же Вил ван дер Аалст: его группа в Эйндховене с конца 1990-х разработала теорию и инструментарий (открытый фреймворк ProM), в 2004 году вышла основополагающая статья об альфа-алгоритме («Workflow Mining: Discovering Process Models from Event Logs», IEEE TKDE), доказавшая, что для определённого класса процессов сеть Петри восстанавливается из журнала событий точно; в 2011 году международная рабочая группа IEEE под его началом выпустила Process Mining Manifesto, а его учебник «Process Mining: Data Science in Action» (Springer, 2-е изд. 2016) остаётся каноном.

Исходный материал — журнал событий (event log) с минимальной триадой: case id (идентификатор экземпляра — номер заказа, счёта, тикета), activity (что произошло) и timestamp (когда). Опциональны ресурс (кто), атрибуты (суммы, каналы). Стандарт обмена — XES (IEEE 1849-2016). Из такого журнала решаются три задачи. Discovery (обнаружение): построить модель процесса как он есть — со всеми 240 реальными вариантами маршрута там, где регламент рисует пять. Алгоритмическая эволюция показательна: альфа-алгоритм элегантен, но ломается на шуме и неполноте реальных логов; практика ушла к эвристическим и индуктивным майнерам (Inductive Miner гарантирует sound-модели — снова связь с 7.2). Conformance checking (проверка соответствия): наложить журнал на нормативную модель и посчитать отклонения — где платежи прошли без согласования, где шаги идут в обход. Механика — «проигрывание» лога по модели (token replay и alignment-методы) с метрикой fitness. Enhancement (обогащение): раскрасить модель временем и деньгами — где очереди, какие варианты маршрута дороже, и предсказывать исход открытых кейсов.

Индустриализовала дисциплину компания Celonis, основанная в 2011 году в Мюнхене тремя студентами Технического университета Мюнхена — Александром Ринке, Бастианом Номинахером и Мартином Кленком (история — Contrary Research, Wikipedia). Стартовав с проектов анализа логов SAP, Celonis довела process mining до продукта: коннекторы к ERP/CRM, витрины «process intelligence», и к 2022 году — оценка $13 млрд, крупнейший софтверный «единорог» Германии. Что Celonis реально даёт зрелой компании: объективную картину вариативности (типичный шок первого проекта — закупочный процесс, у которого в регламенте 7 шагов, а в реальности 900+ вариантов), локализацию денег (где ручные исправления, возвраты, просроченные скидки за раннюю оплату) и таргетирование автоматизации — какие маршруты достаточно частотны, чтобы их автоматизация окупилась. Чего не даёт: сам по себе рентген ничего не лечит — классическая ловушка «красивые дашборды без изменения процесса», и позиционирование Celonis 2023–2026 (переход от «показать» к «исполнять» — orchestration engine, агентные надстройки) — прямое признание этого предела.

Младший брат — task mining: если process mining читает журналы систем, task mining записывает действия пользователя на уровне интерфейса (клики, окна, копипасты) и восстанавливает рутины, не оставляющие следов в логах, — тот самый «теневой Excel-слой» между системами. Это одновременно и сила (видно невидимое), и этическая мина: запись экранов сотрудников требует прозрачных правил.

Для нового бизнеса, строящегося с нуля, у process mining есть неожиданный разворот. Классический сценарий — «раскопать бардак legacy-процессов» — вам не нужен: бардака ещё нет. Зато нужен сценарий conformance-by-design: если все процессы исполняются движком (BPMN или Temporal), event log идеальной чистоты возникает автоматически, и mining превращается из археологии в постоянный контур контроля — где агенты и люди отклоняются от модели, где деградируют SLA, какие ветки процессов мертвы и подлежат удалению.

7.8. RPA: взлёт, потолок и перерождение в agentic-платформы

RPA (Robotic Process Automation, роботизированная автоматизация процессов) — самая поучительная глава новейшей истории автоматизации: технология, которая взлетела на честном обходе фундаментальной проблемы, упёрлась в потолок, порождённый этим же обходом, и сейчас перерождается. Термин ввёл около 2012 года Пэт Гири из Blue Prism (компания основана в 2001-м, Великобритания); Automation Anywhere стартовала в 2003-м в Калифорнии; UiPath Даниэля Дайнса выросла из бухарестской аутсорсинговой DeskOver (2005) и совершила пивот в RPA-платформу в середине 2010-х, став самой быстрорастущей из троицы — IPO в апреле 2021 года при оценке около $35 млрд.

Почему взлетело. Главная боль корпоративной автоматизации нулевых — отсутствие API: у мейнфреймовых АБС, толстых клиентов SAP GUI, ведомственных порталов и Citrix-окон интеграционных интерфейсов не было, а их создание стоило годы. RPA предложила обход: робот работает через тот же интерфейс, что человек, — «руки на клавиатуре», только программные. Механика: селекторы — адреса элементов интерфейса (для веба — DOM-пути, для десктопа — деревья UI Automation, в худшем случае — распознавание по картинке и координатам), сценарий из шагов «найти поле по селектору → вписать → нажать», и оркестратор (UiPath Orchestrator, Blue Prism Control Room) — серверный центр управления парком роботов: расписания, очереди транзакций, креды, журналы, переигровка упавших. Различают unattended-роботов (работают на виртуалках сами) и attended (помощник на машине сотрудника). Экономика была неотразимой: робот, переносящий данные из почты в АБС, окупался за месяцы, не требовал трогать legacy-систему и продавался бизнесу мимо ИТ-департамента — отсюда взрывной рост 2016–2021.

Почему упёрлось. Во-первых, хрупкость: селектор — это контракт с интерфейсом, которого никто не обещал; обновление веб-страницы, смена разрешения экрана, новое поле в форме — и робот ломается, причём молча и в проде. Парк из сотен роботов превращается в фабрику по их починке — это и есть RPA-долг: каждая новая автоматизация увеличивает поверхность хрупкости, и в зрелых программах расходы на сопровождение съедали значительную долю эффекта (по отраслевым обследованиям 2019–2022 годов, от 30 до 50% первых RPA-проектов не достигали целей, а Deloitte фиксировала массовые срывы сроков масштабирования; точные цифры разнятся по методикам — непроверено в деталях, но консенсус о «стене масштабирования» единодушен). Во-вторых, RPA — идеальное «мощение коровьих троп»: робот навсегда цементирует существующий процесс со всеми его абсурдами, потому что копирует человека, а не переосмысляет поток; это анти-Хаммер в чистом виде — automate вместо obliterate. В-третьих, потолок когнитивности: классический робот не понимает содержания — неструктурированное письмо, нестандартный счёт, любое «а тут по ситуации» требует человека. Рынок оценил потолок жёстко: капитализация UiPath упала с пиковых ~$35 млрд почти на порядок к 2022–2024, Blue Prism была поглощена SS&C в 2022-м примерно за $1,6 млрд.

Перерождение 2024–2026 — agentic-платформы. Логика вендоров: у нас есть то, чего нет у чистых LLM-стартапов, — оркестраторы с очередями, кредами, аудитом и тысячи корпоративных внедрений; добавим к рукам (роботы) мозг (LLM). UiPath перезапустилась как «agentic automation company»: Agent Builder (создание LLM-агентов), Autopilot, и ключевое — Maestro (2025) — оркестратор длинных процессов, в котором агенты, роботы и люди — равноправные исполнители шагов, а процесс описывается BPMN-подобной моделью (разбор Reworked, анализ HFS Research «Is the afterlife of RPA agentic?»). Automation Anywhere развивает Process Reasoning Engine, Microsoft вливает агентов в Power Automate. Заметьте иронию архитектурной спирали: агентная волна вернула в моду ровно ту связку, с которой начиналась глава, — формальный оркестратор наверху, исполнители внизу; изменился только тип исполнителя. А само «управление чужим интерфейсом» переизобретено на новом уровне — computer use агентов (Anthropic, OpenAI Operator) — это RPA без селекторов, где элемент находит модель зрения; хрупкость сместилась из селекторов в стохастичность модели, но не исчезла.

7.9. Straight-through processing и low-code платформы

Straight-through processing: главная метрика безлюдности

У «безлюдности» есть точная, давно устоявшаяся метрика — straight-through processing (STP, сквозная обработка): доля кейсов, прошедших процесс от старта до завершения без единого касания человека. Термин родился в финансовой индустрии 1990-х (расчёты по ценным бумагам, SWIFT-платежи), где переход от T+5 к T+1 был физически невозможен, пока в цепочке оставались ручные шаги, и где STP rate по межбанковским платежам довели до 95–99%+. Страхование дало второй эталон: у «цифровых» страховщиков заметная доля простых убытков урегулируется полностью автоматически (хрестоматийный пример — Lemonade с урегулированием простейших claims за секунды), тогда как у классических игроков STP по убыткам исторически близок к нулю.

Почему именно STP, а не «процент автоматизированных шагов»? Потому что STP меряет систему, а не компоненты. Процесс, где автоматизированы 9 шагов из 10, но десятый — ручная проверка каждого кейса, имеет автоматизацию 90% и STP 0%: экономика упирается в человека-в-цикле точно так же, как если бы не было автоматизировано ничего, — очередь, отпуска, ошибки, лимит пропускной способности. STP заставляет проектировать исключения, а не happy path: целевой дизайн — «автоматически по умолчанию, человек по исключению» (management by exception), где DMN-правила сортируют кейсы на «зелёный коридор» (STP) и «серую зону» (human task), а граница коридора — управляемый параметр риска. Практика измерения: STP считается по журналам движка (кейсы без единого user task и без ручных инцидентов), декомпозируется по типам кейсов и юрлицам, и растится итеративно — каждый месяц разбирается топ причин выпадения из коридора (главные подозреваемые всегда одни и те же: грязные мастер-данные, нераспознанные документы, отсутствие правила для редкого случая).

Low-code/no-code платформы: место в архитектуре

Ниже промышленных движков живёт слой low-code/no-code автоматизации: конструкторы «триггер → действия» (Zapier, Make, n8n — open-source-вариант, поднявший в октябре 2025 года $180 млн при оценке $2,5 млрд на волне AI-оркестрации, блог n8n, PitchBook), конструкторы внутренних приложений (Retool — быстрые админки и формы поверх ваших БД и API), базы-таблицы с автоматизациями (Airtable, Notion) и корпоративный вариант жанра — Microsoft Power Automate, который идёт «в комплекте» с подпиской Microsoft 365 и потому размножается в организациях быстрее всех, обычно вообще без ведома ИТ. Их честная ниша определяется тремя свойствами: скорость (автоматизация за час силами оператора, а не разработчика), связность (сотни готовых коннекторов к SaaS) и — оборотная сторона — слабые гарантии: нет durable-семантики (упавший в середине сценарий Zapier не «доедет» сам), нет версионирования и тестов в инженерном смысле, нет консолидированного event log, а при разрастании возникает «shadow BPM» — сотни никем не инвентаризованных зэпов, на которых внезапно держится выручка. Это тот же паттерн, что RPA-долг и excel-хаос: инструмент гражданской автоматизации, масштабированный до системообразующего, становится риском.

Зрелое решение — не запрет, а зонирование: low-code разрешён для периферийных, некритичных, обратимых автоматизаций (уведомления, синки маркетинговых списков, черновые эксперименты — «песочница», где бизнес сам проверяет гипотезы автоматизации), с обязательной инвентаризацией; всё, что касается денег, обязательств и данных клиентов, живёт на движке с гарантиями. Полезна и «лестница зрелости»: автоматизация рождается в n8n за день → доказывает ценность → переписывается на Temporal/BPMN как продукт. Low-code здесь играет роль прототипной глины, а не несущей конструкции.

7.10. Agentic process automation: процесс как рельсы для агента

Финальный синтез главы — вопрос, как встроить LLM в исполняемый процесс, не потеряв ни гибкости модели, ни гарантий движка. Термин agentic process automation (APA) ввела статья Йе и соавторов «ProAgent: From Robotic Process Automation to Agentic Process Automation» (Tsinghua/OpenBMB, ноябрь 2023, arXiv:2311.10751): LLM-агент сам конструирует workflow из описания задачи и сам исполняет шаги, требующие понимания, — авторы прямо противопоставили это RPA, где и конструирование, и исполнение жёстко ручные. Последующие работы 2024–2026 (сравнительные исследования вроде «Are LLM Agents the New RPA?», поток статей BPM-сообщества об «agentic BPM», работы группы ван дер Аалста о встрече process science и AI-агентов) очертили трезвую картину: чистая агентная автономия на корпоративных процессах пока проигрывает по надёжности, а выигрывает гибрид — процесс как рельсы, агент как исполнитель отдельных шагов.

Разложим гибрид по уровням «дозирования LLM», от консервативного к радикальному. Уровень 1 — LLM как activity: детерминированный процесс, внутри которого отдельные шаги — вызовы модели: извлечение полей из первичных документов (счёт, договор, акт — любого формата, что убивает главный когнитивный потолок RPA), классификация обращений, генерация писем. Ключевые механизмы обвязки: структурированный выход (JSON-схема), порог уверенности, при недоборе — автоматический сброс в human task (сортировку делает обычный XOR-шлюз); с точки зрения движка LLM — просто ненадёжный сервис с ретраями, вся теория глав выше применима без изменений. Уровень 2 — LLM как маршрутизатор: модель принимает решения о маршруте («это претензия, жалоба или запрос документов?», «какой сценарий взыскания выбрать?») — но выбирает только из веток, существующих в модели процесса; DMN-таблица с жёсткими правилами уступает место классификатору там, где правила невыразимы, при сохранении конечного множества исходов. Уровень 3 — агент внутри ограждения: неструктурированный шаг («разберись с этим нестандартным запросом клиента») отдаётся агентному циклу с инструментами, но сам цикл живёт внутри шага durable-процесса, который задаёт бюджет (число итераций, деньги, время), таймаут, набор разрешённых инструментов и обязательную точку выхода — результат либо валидируется правилами и идёт дальше, либо падает человеку. Это ровно ниша, которую в 7.3 не смог занять CMMN: неструктурированная работа со строгими инвариантами. Уровень 4 — агент конструирует процесс (по ProAgent): пока экспериментальный; здравая промежуточная форма — агент генерирует черновик BPMN/DMN/кода воркфлоу, человек ревьюит, движок исполняет: генерация артефактов вместо генерации действий.

Почему рельсы обязательны, объясняет статистика самой агентной индустрии: LLM недетерминированы, а бизнес-процесс обязан быть воспроизводимым и аудируемым. Оркестрация даёт три вещи, которых нет у «голого» агента: долговечность (агентный цикл на неделю с ожиданием документов от контрагента невозможен без durable-состояния — отсюда взрывной рост Temporal на AI-нагрузках, см. 7.5), наблюдаемость (каждый шаг агента — событие в общем event log, к траекториям применим conformance checking из 7.7: «агент вышел за эталонный коридор» — алерт) и границы полномочий (агент не может перевести деньги, потому что перевод — отдельный шаг процесса с four-eyes из 7.6, а не инструмент в его распоряжении). Индустрия 2025–2026 сошлась на этой картине с обеих сторон: BPM-вендоры добавляют агентов как исполнителей (agentic orchestration Camunda — программный доклад Бернда Рюкера на CamundaCon NYC 2025, видео), RPA-вендоры строят оркестраторы агентов (UiPath Maestro), durable-execution-платформы объявляют агентов главным сценарием, а агентные фреймворки (LangGraph) отращивают чекпоинты, human-approval и графы состояний — то есть становятся workflow-движками. Конвергенция полная: спор «диаграммы vs код vs агенты» закончился архитектурой «журнал событий + детерминированный оркестратор + недетерминированные исполнители + человек по исключению».

Источники и куда копать глубже