Предыдущие главы описывали целевую архитектуру безлюдного бизнес-движка — слои данных, процессов, агентов и контроля. Эта глава отвечает на вопрос, который встаёт сразу после того, как целевая картинка нарисована: как перейти из сегодняшнего состояния (компания на 180 человек, 255 процессов в реестре, живой бэк-офис с людьми на каждом узле) в состояние, где несколько юрлиц обслуживаются движком с минимумом людей — и при этом не сломать работающий бизнес по дороге. Методология перехода — это не «план внедрения RPA», а дисциплина из четырёх связанных практик: инвентаризация (что вообще за работа делается и сколько она стоит), оценка автоматизируемости (что из этого машина может делать уже сегодня и что — с оговорками), измерение (какими метриками фиксировать прогресс безлюдности и как построить приборную панель перехода) и последовательность (в каком порядке действовать, чтобы не автоматизировать хаос и не застрять в чистилище пилотов). Глава опирается на сорокалетний опыт shared services и BPM-движения, на количественные модели McKinsey Global Institute и APQC, на бенчмарки Hackett Group — и на свежие разборы того, почему трансформации 2024–2026 годов проваливаются чаще, чем признаются. Для проектировщика безлюдного движка это глава-«штурманская рубка»: здесь собраны приборы, карты и правила навигации.
11.1 Инвентаризация работы: сначала увидеть всю работу целиком
Переход к безлюдным операциям начинается не с выбора технологий, а с ответа на обманчиво простой вопрос: какая именно работа делается в компании и сколько она стоит? Большинство организаций не могут ответить на него честно. Оргструктура показывает, кто кому подчиняется, но не что люди делают; должностные инструкции описывают намерения, а не факт; а бюджеты фиксируют затраты по подразделениям, а не по единицам работы. Поэтому первый инструмент методологии перехода — процессная таксономия: единый, иерархический, полный каталог всей работы предприятия.
Таксономия APQC PCF: общий язык для описания работы
Эталонная таксономия — Process Classification Framework (PCF, «классификатор процессов») от APQC (American Productivity & Quality Center), развиваемая с 1992 года; актуальная кросс-индустриальная версия — 7.x (номер и дату последнего релиза сверяйте на apqc.org). PCF делит всю деятельность любой компании на 13 категорий: пять «операционных» (разработка видения и стратегии; разработка продуктов и услуг; маркетинг и продажи; поставка физических продуктов; поставка услуг; управление клиентским сервисом — в v7.x операционный блок расширен до шести) и семь «обеспечивающих» (управление персоналом, ИТ, финансами, активами, рисками и комплаенсом, внешними связями, развитием бизнес-способностей). Ключевой механизм PCF — не сам список, а пять уровней декомпозиции: категория (1.0) → группа процессов (1.1) → процесс (1.1.1) → активность (1.1.1.1) → задача. Каждый элемент имеет уникальный числовой идентификатор, который не меняется между версиями, — именно это превращает PCF из «красивой схемы» в рабочий инструмент: к стабильным идентификаторам можно привязывать трудозатраты, стоимость, системы, метрики и — что важно для нашей задачи — оценки автоматизируемости.
Для проектировщика безлюдного движка PCF решает три задачи. Во-первых, это проверка полноты: реестр из 255 процессов, собранный «снизу», почти наверняка имеет слепые зоны (обычно это категории 1.0 «стратегия», 12.0 «внешние связи» и 13.0 «бизнес-способности» — работа, которую никто не называет процессом, но на которую уходит время руководителей). Прогон собственного реестра через 13 категорий PCF за один день показывает, где дыры. Во-вторых, это общий язык между юрлицами холдинга: если каждый актив описывает свой бэк-офис в терминах PCF, процессы «обработать счёт поставщика» (9.6.x в терминах категории «финансы») становятся сопоставимыми и консолидируемыми — а консолидация, как мы увидим в разделе 11.5, исторически первый шаг к автоматизации. В-третьих, PCF — это ключ к бенчмаркам APQC: база Open Standards Benchmarking содержит нормативы стоимости и производительности, привязанные к тем же идентификаторам (раздел 11.4).
Работа = задачи: урок O*NET
Вторая опора инвентаризации — принцип декомпозиции работы на задачи (task decomposition), канонически реализованный в американской базе O*NET (Occupational Information Network, преемница Dictionary of Occupational Titles). O*NET описывает около тысячи профессий не как «роли», а как наборы конкретных задач: профессия бухгалтера — это не «ведение учёта», а 20–30 отдельных задач вида «сверить банковские выписки с записями в главной книге», каждая со своей частотой и важностью. Именно эта модель — работа состоит из задач, а не из людей — легла в основу всех современных оценок автоматизируемости: и знаменитой работы Фрея и Осборна (2013), и моделей MGI, и свежих оценок эпохи GenAI (включая индексы вроде Anthropic Economic Index, который измеряет использование ИИ именно по задачам O*NET). Практический вывод для инвентаризации: единица анализа — не должность и не отдел, а задача внутри процесса. Автоматизация почти никогда не «съедает профессию целиком»; она съедает 30–70% задач внутри профессии, и увидеть это можно только на уровне задач.
Time studies и activity-value analysis: сколько стоит каждая задача
Третий слой — привязка времени и денег. Классические хронометражные исследования (time studies) восходят к Тейлору и Гилбретам, но в бэк-офисе XXI века используются три более дешёвых метода. Самодекларация (activity survey): сотрудники раз в квартал распределяют свои 100% времени по процессам реестра; метод грубый (ошибки 20–30%, систематическое завышение «важной» работы), но достаточный для первой карты. Выборочные наблюдения (work sampling): вместо непрерывного хронометража — случайные срезы «что вы делаете прямо сейчас», статистически сходящиеся к реальному распределению. Цифровая телеметрия: task mining (запись действий на рабочем столе) и process mining по логам систем (раздел 11.8) — единственный метод, который измеряет факт, а не воспоминания о факте.
Полученную карту «процесс × часы × стоимость часа» пропускают через анализ ценности активностей (activity-value analysis, AVA — методика, популяризированная ещё McKinsey в 1980-х для сокращения накладных расходов): каждая активность классифицируется как создающая ценность для клиента (value-adding), необходимая для бизнеса, но не создающая ценность (business-value-adding: комплаенс, учёт), и не создающая ценности вовсе (non-value-adding: переделки, согласования ради согласований, ручной перенос данных между системами). Типичный результат для бэк-офиса — 15–25% времени в первой категории, и это главный аргумент главы: прежде чем автоматизировать, значительную часть работы надо просто перестать делать (раздел 11.6).
Итоговый артефакт инвентаризации — то, что мы дальше будем называть реестром работы: таблица уровня «активность», где по каждой строке известны привязка к таксономии, годовые часы, полная стоимость (зарплата + начисления + накладные), классификация по ценности, используемые системы и владелец. Реестр из 255 процессов с трудозатратами по отделам — это уже 80% такого артефакта; недостающие 20% — декомпозиция крупных процессов до задач и классификация по ценности.
Не начинать с технологий — начать с реестра работы. Прогнать имеющиеся 255 процессов через 13 категорий APQC PCF (проверка полноты и общий язык для всех юрлиц холдинга), декомпозировать каждый процесс до задач по модели O*NET, привязать часы и рубли, разметить value / business-value / non-value. Этот реестр — основной датасет всей программы перехода: на него лягут оценки автоматизируемости (11.2), метрики (11.3) и приоритизация (11.10). Стоимость упражнения — 2–4 недели одного аналитика с LLM-ассистентом; LLM хорошо декомпозирует процессы на задачи по описанию.
11.2 Оценка автоматизируемости: от MGI-2017 к эпохе генеративных моделей
Когда реестр работы собран, следующий шаг — оценить по каждой задаче: может ли её выполнять машина, и если да, то какой ценой. Здесь полезно понимать эволюцию количественных моделей.
Модель MGI: активность, а не профессия
Доклад McKinsey Global Institute «A future that works» (январь 2017) стал методологическим стандартом. MGI декомпозировал ~800 профессий на ~2000 активностей и оценил каждую по 18 требуемым способностям (восприятие, моторика, когнитивные способности, язык, социальный интеллект). Вывод: около 50% всех оплачиваемых активностей в мировой экономике технически автоматизируемы адаптацией уже продемонстрированных (на 2017 год) технологий; при этом менее 5% профессий автоматизируемы полностью, но в ~60% профессий автоматизируемо не менее 30% активностей. Разница между «50% активностей» и «5% профессий» — центральный урок: автоматизация перекраивает состав работы внутри ролей, а не выключает роли одну за другой.
Второй вклад MGI — разделение технического потенциала и темпа внедрения. Между «технически можно» и «реально внедрено» лежат пять факторов: техническая осуществимость, стоимость разработки и внедрения, динамика рынка труда (дорог ли заменяемый труд), экономические выгоды сверх экономии на зарплате (качество, скорость), регуляторное и социальное принятие. По оценке MGI-2017, точка, где будет фактически автоматизирована половина сегодняшних активностей, наступала в базовом сценарии около 2055 года (в диапазоне ±20 лет).
Эпоха генеративных моделей сместила обе оценки. Доклад MGI «The economic potential of generative AI» (июнь 2023) поднял оценку технического потенциала: текущие технологии, включая генеративный ИИ, способны автоматизировать 60–70% рабочего времени сотрудников (против ~50% в модели 2017 года), а середина сценария фактического внедрения сдвинулась примерно на десятилетие раньше — с ~2053 (ориентир модели 2017 года; в базовом сценарии MGI называла ~2055) на ~2045 год. Экономический потенциал GenAI оценён в $2,6–4,4 трлн в год по 63 корпоративным сценариям использования, причём ~75% этой ценности концентрируется в четырёх функциях: клиентские операции, маркетинг и продажи, разработка ПО, R&D. Принципиально новое: GenAI впервые сделал автоматизируемой работу с естественным языком и знаниями, то есть ударил по высокооплачиваемым «белым воротничкам» — ровно по тем ролям, из которых состоит бэк-офис сервисной IT-компании. Стоит помнить, что это оценки консультантов, заинтересованных в теме; независимые исследования (например, работы Дарона Аджемоглу, оценивающего макроэффект GenAI в скромные ~0,5–1% роста TFP за десятилетие) дают куда более консервативные цифры внедрения — но для одной компании, целенаправленно строящей безлюдный движок, релевантен именно технический потолок, а не средний темп экономики.
Пять критериев автоматизируемости задачи
Для практической разметки реестра работы достаточно пяти критериев, каждый по шкале 1–5:
- Правилосообразность (rule-based vs judgment-based): можно ли описать задачу детерминированными правилами или хотя бы устойчивой политикой принятия решений? С приходом LLM граница сместилась: теперь автоматизируемы и задачи с «мягкими» правилами (классификация обращений, извлечение данных из неструктурированных документов), но задачи, требующие подлинной ответственности и переговорной позиции, остаются людскими.
- Оцифрованность входов и выходов: приходят ли данные в структурированном цифровом виде и уходит ли результат в систему? Задача с бумажным входом или «выходом в разговор» требует сначала оцифровки интерфейсов.
- Частота и объём: автоматизация — это инвестиция с постоянными затратами на разработку и поддержку; задача, выполняемая 10 раз в год, редко окупает её (исключение — эпоха LLM-агентов, снизившая стоимость автоматизации «длинного хвоста» на порядок, см. ниже).
- Вариативность: сколько существенно различных сценариев исполнения? Классическое правило RPA-эпохи — автоматизировать только «счастливый путь» стабильного процесса; LLM-агенты терпимее к вариативности, но каждая ветка — это тест-кейс и источник ошибок.
- Цена ошибки и обратимость: что случится при неверном исполнении и можно ли его откатить? Дешёвые обратимые ошибки → полная автоматизация; дорогие необратимые → автоматизация с человеком-контролёром (human-in-the-loop) на выходе.
Механика скоринга проста: интегральная оценка автоматизируемости (взвешенная сумма критериев 1–4, с ценой ошибки как модификатором режима, а не блокером) откладывается против эффекта (годовая стоимость задачи из реестра × достижимая доля автоматизации) на матрице «усилие × эффект». Получаются четыре квадранта: быстрые победы (высокий эффект, низкое усилие) — стартовый портфель; стратегические ставки (высокий эффект, высокое усилие) — планируются как проекты; фоновые задачи (низкий эффект, низкое усилие) — отдаются «гражданской автоматизации» и универсальным агентам; ловушки (низкий эффект, высокое усилие) — явно и письменно откладываются, потому что именно они порождают RPA-долг (раздел 11.12).
Важная поправка 2024–2026 годов: LLM изменили экономику квадрантов. В RPA-эпоху автоматизация одной задачи стоила десятки тысяч долларов разработки, поэтому «длинный хвост» редких задач был экономически недосягаем. Универсальный агент с доступом к системам и инструкцией на естественном языке снижает предельную стоимость автоматизации очередной задачи почти до стоимости написания регламента — и это стратегически меняет ответ на вопрос «что автоматизировать»: не отдельные задачи по одной, а платформу, на которой автоматизация очередной задачи тривиальна. Именно поэтому безлюдный движок проектируется как движок, а не как портфель роботов.
Разметить все 255 процессов (на уровне задач) пятью критериями — правилосообразность, оцифрованность, частота, вариативность, цена ошибки — силами LLM с выборочной ручной проверкой; это дни, а не месяцы. Держать в голове двухслойность оценки MGI: «технически можно» ≠ «внедрится само»; для собственного холдинга ограничитель — не технология, а оцифрованность входов и готовность перестроить процесс. И считать не «сколько процессов автоматизировано», а какой процент часов из реестра переведён на машину — это честная единица прогресса.
11.3 Метрики безлюдности: приборная панель перехода
Программа перехода без собственной системы измерений вырождается в набор демо. Ниже — семь метрик, из которых собирается приборная панель безлюдности; важно понимать механику каждой, потому что все они умеют врать.
Touchless rate / STP-rate (доля сквозной обработки, straight-through processing) — главная метрика безлюдности: доля транзакций процесса, прошедших от входа до результата без единого касания человеком. Термин пришёл из расчётов по ценным бумагам 1990-х, где STP означал проведение сделки без ручного ввода. Механика измерения: в каждом процессе определяется «касание» (любое действие человека, включая одобрение в один клик), и система процесса логирует их; touchless rate = транзакции с нулём касаний / все транзакции. Ловушка: метрику легко надуть, выведя сложные случаи «за периметр» (они уходят в почту и перестают учитываться). Поэтому touchless rate всегда считается от всего входящего потока, включая исключения. Хорошие ориентиры: в обработке счетов поставщиков лидеры достигают 70–90% touchless, медиана рынка — заметно ниже 30% (непроверено в точной цифре — публикуемые оценки Ardent Partners и SSON расходятся).
First-time-right (FTR, «правильно с первого раза») — доля транзакций, не потребовавших переделки, исправления или возврата. Это метрика качества автоматизации: touchless без FTR означает, что машина быстро производит брак. Пара «touchless × FTR» — честный показатель: их произведение — доля потока, обработанного машиной правильно и без людей.
Cost per transaction (стоимость транзакции) — полная стоимость процесса (люди + лицензии + инфраструктура + доля накладных) / число транзакций. Ключ к бенчмаркингу (раздел 11.4) и единственная метрика, которая ловит RPA-долг: если после автоматизации стоимость транзакции не упала, значит, сэкономленные часы никуда не делись или расходы на поддержку роботов съели эффект.
Cycle time (время цикла) — календарное время от входа до результата. Показательно распределение, а не среднее: у автоматизированного процесса типична бимодальность — 90% транзакций за минуты (машина), 10% за недели (исключения у людей). Хвост распределения — карта следующей волны автоматизации.
Выручка на сотрудника (revenue per FTE) — интегральная метрика уровня компании. Для сервисной IT-компании в 1,4 млрд ₽ на 180 человек это ~7,8 млн ₽/чел — типичный для рынка уровень; безлюдная модель целится в кратный рост. Метрика хороша именно нечувствительностью к локальным манипуляциям: её нельзя улучшить, перекинув работу из отдела в отдел, — только реально убрав труд из системы. Её аналог для бэк-офиса холдинга — число обслуживаемых юрлиц (или транзакций группы) на одного сотрудника УК.
Span of automation (охват автоматизации) — доля часов из реестра работы (раздел 11.1), переведённых на машину. В отличие от лукавого «числа автоматизированных процессов» (можно автоматизировать 100 мелких процессов и не тронуть 80% трудозатрат), эта метрика взвешена по стоимости и напрямую связывает программу с реестром.
Exception rate и ручной остаток — сколько часов человеческой работы осталось в процессе и почему: классификация причин касаний (недостающие данные, нестандартный контрагент, требование регулятора, недоверие к машине) — это управленческий backlog программы.
Приборная панель перехода строится в три слоя. Верхний — 3–4 метрики уровня компании (выручка/FTE, полная стоимость бэк-офиса как % выручки, span of automation, headcount бэк-офиса). Средний — по каждому крупному процессу: touchless, FTR, cost per transaction, cycle time p50/p95. Нижний — операционный лог исключений и причин касаний. Критично: базовую линию (baseline) надо замерить до старта программы, на данных инвентаризации, — иначе через год нечего будет сравнивать, а эффект программы станет предметом веры, а не расчёта.
Сделать touchless rate × FTR парной метрикой каждого процесса движка с первого дня — закладывать логирование «касаний» в архитектуру, а не прикручивать потом. Верхнеуровневая целевая метрика холдинга — «юрлиц на сотрудника УК» и «стоимость бэк-офиса как % консолидированной выручки»: они не поддаются манипуляции и понятны совету директоров. Baseline снять сейчас, по текущей компании, до всякой автоматизации.
11.4 Бенчмаркинг: сколько стоит бэк-офис в норме и у лучших
Бенчмаркинг отвечает на вопрос «а сколько это должно стоить?» — и тем самым задаёт амбицию программы. Два главных источника нормативов — The Hackett Group и APQC.
Hackett Group с 1990-х ведёт крупнейшую базу бенчмарков административных функций (finance, HR, IT, procurement) и ввёл в оборот понятие «world-class» — верхний квартиль по совокупности эффективности и результативности. Классический, десятилетиями устойчивый ориентир: функция финансов у world-class-компаний стоит около 0,6% выручки против ~1,0% у медианных (peer group) — то есть лучшие тратят на финансы почти вдвое меньше при более высоком качестве. В 2020-х Hackett перешёл к категории «Digital World Class»: по данным на июнь 2025 года такие финансовые команды работают на 45% дешевле как процент выручки, держат до 42% меньше FTE, автоматизируют 80% workflow в кредиторской задолженности и 99% журнальных проводок (против 85% у остальных), закрывают период на 35–57% быстрее. В 2025 году Hackett объявил и следующую категорию — «AI World Class», с оценкой, что агентные технологии позволяют снизить стоимость финансовой функции ещё на 52–59% от сегодняшнего уровня (непроверено — цифра из пресс-релиза, полная методология не опубликована). Направление тренда важнее точных цифр: планка «нормального» бэк-офиса сдвигается так быстро, что проектировать надо не от сегодняшней медианы, а от завтрашнего лидера.
APQC Open Standards Benchmarking даёт нормативы на уровне отдельных процессов, привязанные к идентификаторам PCF. Канонический пример — обработка счёта поставщика (accounts payable): у нижнего квартиля полная стоимость обработки одного счёта ~$11+, у верхнего — менее $3 (по данным APQC, разница почти в 4 раза); верхний квартиль обходится 3–4 FTE на $1 млрд выручки в AP против 14+ у нижнего, а цикл обработки — до 3 дней против недели и более. Механизм пользы таких цифр: умножив собственный объём транзакций на дельту «мы минус верхний квартиль», получаем денежную оценку потенциала по каждому процессу — это и есть числитель для матрицы приоритизации из раздела 11.2.
Три правила гигиены бенчмаркинга. Первое: сравнивать полную стоимость (fully loaded cost), включая аллоцированные накладные и стоимость систем, — иначе аутсорсинг и автоматизация будут выглядеть выгоднее, чем есть. Второе: помнить о нелинейности масштаба — бенчмарки Hackett сняты с компаний в миллиарды долларов выручки; у компании в $15–20 млн бэк-офис как % выручки закономерно дороже, поэтому сравниваться надо с квартилями своего размерного класса (APQC это позволяет). Третье: бенчмарк — это диагностический инструмент, а не целевой показатель для премирования; как только квартиль становится KPI менеджера, начинается перекладывание затрат между строками, а не устранение работы (частный случай закона Гудхарта).
Отдельная строка — бенчмарк безлюдности как таковой. Публичные примеры компаний с экстремальной выручкой на сотрудника (WhatsApp: ~55 сотрудников на 450 млн пользователей к моменту продажи за $19 млрд; Telegram: десятки инженеров на сотни миллионов пользователей; современные AI-стартапы, проходящие $100 млн ARR с командами в несколько десятков человек) показывают, что потолок «выручка/FTE» в цифровом бизнесе измеряется десятками миллионов долларов на человека. Это не бенчмарки бэк-офиса в строгом смысле — но они калибруют амбицию: бэк-офис холдинга из нескольких юрлиц технически может обслуживаться единицами людей, если спроектирован как продукт.
Взять 5–7 самых дорогих процессов из реестра и найти для них APQC-нормативы верхнего квартиля — это даст денежную оценку потенциала по каждому и словарь для разговора с партнёрами. Целевую стоимость бэк-офиса УК задать в двух величинах: % от консолидированной выручки холдинга (амбициознее hackett-овского Digital World Class, потому что движок строится с нуля, без наследия) и абсолютный headcount УК. И не премировать никого за достижение бенчмарка — только за устранение работы.
11.5 История shared services и GBS: консолидация → стандартизация → автоматизация
Идея «обслуживать много бизнес-единиц одним бэк-офисом» не нова — ей четыре десятилетия, и её история — это готовая методология для холдинга, который строит Алексей.
- 1980-еGE изобретает shared services.
General Electric консолидирует финансовые операции нескольких бизнесов в единый центр; параллельно похожие шаги делают Ford и клиенты A.T. Kearney. Рождается канон: консолидация → стандартизация → автоматизация.
- 1999P&G собирает GBS.
Бэк-офисные службы ~70 стран сведены в Global Business Services с тремя хабами — Коста-Рика, Манила, Ньюкасл. Каталог услуг, SLA, сквозные владельцы процессов end-to-end.
- 2003Ход Пассерини: «умный заказчик + рынок исполнителей».
Вместо продажи всего GBS одному аутсорсеру P&G делит портфель: ИТ-инфраструктура — HP, здания — JLL, часть HR — IBM; архитектура процессов и ядро — внутри. Экономия — сотни миллионов долларов в год на ~140 стран.
- 2000-еРасцвет BPO — арбитраж стоимости труда.
Работа переносится к подрядчикам с дешёвым трудом (Индия, Филиппины): она остаётся ручной, просто дешевеет. BPO выигрывает у автоматизации по скорости эффекта.
- 2016+RPA-волна и центры компетенций.
Роботы кликают по экранам вместо людей; CoE-модели буксуют (Deloitte-2018: лишь 3–4% организаций домасштабировались до 50+ роботов), рождается RPA-долг.
- 2025Агентное сжатие: «Unbundling the BPO».
a16z: рынок BPO $300+ млрд — главная мишень services-as-software; ценообразование смещается с «время + материалы» на оплату за результат, работа возвращается от дешёвых людей к агентам.
Первый акт: shared services (общие центры обслуживания). В середине 1980-х General Electric консолидировала финансовые операции нескольких бизнесов в единый центр (часто именно GE называют изобретателем модели общего центра обслуживания; параллельно похожие шаги делали Ford и A.T. Kearney-клиенты). Логика была тройной: консолидация (собрать одинаковую работу из разных подразделений в одно место — экономия масштаба и прозрачность), затем стандартизация (один способ делать процесс вместо пяти локальных вариантов — предпосылка для любых дальнейших улучшений), затем автоматизация/оптимизация (только когда процесс один и стандартный, инвестиция в его автоматизацию окупается на всём объёме). Эта последовательность — консолидация → стандартизация → автоматизация — стала канонической, и её порядок неслучаен: попытка автоматизировать пять локальных вариантов процесса означает пять внедрений и пятикратную поддержку.
Второй акт: GBS (Global Business Services). К 2000-м лидеры пошли дальше центров по функциям — к интегрированной сервисной организации, обслуживающей все функции и все регионы с единым управлением, каталогом услуг и сквозной ответственностью за процессы end-to-end. Хрестоматийный пример — Procter & Gamble: в 1999 году компания собрала бэк-офисные службы ~70 стран в подразделение Global Business Services (три хаба — Коста-Рика, Манила, Ньюкасл), а в 2003-м под руководством Филиппо Пассерини совершила нетривиальный ход — вместо продажи всего GBS одному аутсорсеру (сделка с EDS обсуждалась всерьёз) разделила портфель: ИТ-инфраструктуру отдали HP, управление зданиями — Jones Lang LaSalle, часть HR — IBM, а управление, архитектуру процессов и всё, что близко к конкурентному преимуществу, оставили внутри. P&G GBS стал эталоном модели «умный заказчик + рынок исполнителей» и, по опубликованным оценкам, экономил компании сотни миллионов долларов в год, обслуживая ~140 стран (кейс подробно разобран в Harvard Business School case «Procter & Gamble: Global Business Services»). Уроки GBS напрямую переносимы на управляющую компанию холдинга: каталог услуг с ценами (внутренний прайс УК для юрлиц), соглашения об уровне сервиса, сквозные владельцы процессов «от заказа до денег» и «от найма до увольнения» — всё это словарь, изобретённый GBS-движением.
Третий акт: аутсорсинг против автоматизации. Параллельно рос BPO (business process outsourcing) — перенос той же работы не в свой центр, а к подрядчику с дешёвым трудом (Индия, Филиппины). BPO — это арбитраж стоимости труда: работа остаётся ручной, просто дешевеет. Автоматизация — устранение труда. Сорок лет эти стратегии конкурировали, и BPO чаще выигрывал по скорости эффекта. Эпоха агентного ИИ переворачивает доску: рынок BPO объёмом $300+ млрд (оценка a16z, 2025; прогнозы до $525 млрд к 2030-му строились до GenAI-сдвига) оказался главной мишенью «сервисов-как-софта» (services-as-software). Аргумент венчурного разбора a16z «Unbundling the BPO» (Кимберли Тан, февраль 2025): фундаментальные модели уже справляются с извлечением данных и рассуждением, голосовые агенты достигли продакшн-зрелости, ценообразование смещается с «время + материалы + 20–30% маржи» на оплату за результат — и работа, которую 20 лет выгодно было выносить к дешёвым людям, теперь выгоднее возвращать внутрь, к агентам. Индийские IT/BPO-гиганты публично перестраивают модели с headcount-based на outcome-based; для сервисной IT-компании это одновременно угроза (её собственная выручка построена на продаже часов) и подсказка: та же логика, что убивает BPO, делает возможным безлюдный внутренний бэк-офис.
Важно удержать историческую последовательность как чек-лист, а не как обязательную хронологию. Классический путь занимал десятилетия: 5–7 лет консолидации, 5 лет стандартизации, потом волны автоматизации. Компания, строящая движок с нуля для нескольких юрлиц, проходит консолидацию и стандартизацию «на бумаге» — в момент проектирования: один процесс на холдинг, один каталог услуг, одна модель данных — и сразу закладывает автоматизированное исполнение. Но пропустить этапы нельзя — их можно только совместить: если у двух юрлиц окажутся два разных процесса закупок, движок унаследует ровно ту фрагментацию, с которой GE боролась консолидацией.
Проектировать УК как GBS-организацию с первого дня: каталог услуг с внутренними ценами, SLA перед юрлицами, сквозные владельцы end-to-end процессов. Железное правило — «один процесс на холдинг»: любое новое юрлицо получает стандартный процесс движка, а не приносит свой. И переиспользовать урок Пассерини: ядро (архитектура процессов, данные, управление агентами) — только внутри; коммодити-исполнение — рынку, пока агент не станет дешевле подрядчика.
11.6 ESSA: сначала устрани и упрости, потом автоматизируй
Самое дорогое заблуждение программ автоматизации — считать автоматизацию первым шагом. Вся инженерная традиция XX века настаивает: автоматизация — последний шаг четырёхтактной последовательности, известной как ESSA — Eliminate → Simplify → Standardize → Automate («устрани → упрости → стандартизируй → автоматизируй»), или в терминах классической промышленной инженерии ECRS (Eliminate, Combine, Rearrange, Simplify — методика анализа операций, восходящая к work study 1930–50-х).
Механика каждого такта. Eliminate: по каждой активности из реестра задаётся вопрос «что случится, если это перестать делать?» — и значительная часть работы (отчёты, которые никто не читает; согласования, которые никогда ничего не отклоняют; сверки данных, которые не должны были расходиться) устраняется бесплатно. Это прямое продолжение activity-value analysis из раздела 11.1: категория non-value-adding — кандидаты на устранение, а не на автоматизацию. Simplify: у оставшейся работы сокращаются варианты, исключения, ветвления и точки передачи между людьми; каждая устранённая ветка — минус тест-кейс, минус источник ошибок будущего агента. Standardize: один способ исполнения, зафиксированный как регламент (а в безлюдном движке — как машиночитаемая спецификация процесса). Automate: и только теперь — машина, потому что теперь автоматизируется простой, стандартный, очищенный процесс, а не музей исторических компромиссов.
Почему порядок критичен, объясняет афоризм, широко приписываемый Биллу Гейтсу: «Первое правило любой технологии: автоматизация, применённая к эффективной операции, умножит эффективность. Второе: автоматизация, применённая к неэффективной операции, умножит неэффективность» (точный первоисточник цитаты документально не установлен — она кочует по деловой литературе с 1990-х, — но именно в этой формулировке стала каноном). Автоматизация — это усилитель: она масштабирует то, что есть. Автоматизированный хаос — это хаос, исполняемый быстро, дёшево и без человека, который мог бы заметить бессмыслицу.
Радикальную версию Eliminate сформулировал Майкл Хаммер в статье «Reengineering Work: Don't Automate, Obliterate» (Harvard Business Review, июль–август 1990) — манифесте реинжиниринга бизнес-процессов. Знаменитый кейс: в кредиторской задолженности Ford работало ~500 человек, занятых сверкой заказов, накладных и счетов; менеджмент планировал автоматизацией сократить численность на 20%, пока не увидел, что у Mazda ту же функцию выполняют 5 человек. Ford не стал автоматизировать сверку счетов — он упразднил счёт как документ: оплата стала триггериться фактом приёмки товара, сверяемым с заказом в общей базе (invoiceless processing), и функция сжалась на ~75%. Урок Хаммера для проектировщика движка: перед автоматизацией каждого процесса спросить «а нужен ли этот процесс вообще, или он существует потому, что раньше не было общей базы данных?». В холдинге, где все юрлица живут на одной платформе данных, целые классы работы (внутригрупповые сверки, взаимные счета, консолидационные корректировки) устраняются архитектурно.
Наконец, у последовательности есть и «производственное» обоснование — принцип дзидока (jidoka, «автономизация», один из двух столпов производственной системы Toyota): автоматизировать можно только стабильный процесс, а машина обязана останавливаться при отклонении, а не производить брак. Прежде чем передавать процесс агенту, процесс должен демонстрировать стабильность на людях: понятные входы, предсказуемые исключения, измеренный FTR. И сам агент проектируется по-тойотовски: обнаружил аномалию — остановись и позови человека (это архитектурный паттерн «андон» для агентов, о котором шла речь в главах о контурах контроля).
Оговорка эпохи LLM: соблазнительно думать, что раз агенты терпимы к вариативности, то Simplify и Standardize можно пропустить — агент «разберётся». Это возрождение старой ошибки на новом витке: агент, которому скормили хаотичный процесс, будет воспроизводить хаос с уверенным видом, и стоимость его проверки съест экономию. ESSA в эпоху агентов не отменяется — сжимается по времени: устранение и упрощение можно делать одновременно с проектированием автоматизации, но не после неё.
Прогнать реестр 255 процессов через ESSA-фильтр до любых внедрений: сначала вычеркнуть (ожидаемо 10–20% часов умрёт без последствий), потом упростить и свести варианты юрлиц к одному стандарту, и только остаток — в бэклог автоматизации. Заложить jidoka в архитектуру агентов: право и обязанность остановиться при аномалии. И повесить вопрос Хаммера на стену: «какая работа исчезнет сама, если у холдинга одна база данных?»
11.7 Zero-based design: проектирование от чистого листа
Всё сказанное выше — инвентаризация, ESSA, бенчмарки — работает «от текущего состояния»: берём то, что есть, и улучшаем. Но у этого подхода есть потолок: улучшая существующее, вы наследуете его предпосылки. Zero-based design (проектирование с нуля), он же clean-sheet redesign («чистый лист»), инвертирует направление: сначала проектируется целевое состояние без оглядки на текущее — «если бы мы строили эту функцию сегодня, с нынешними технологиями, без наследия, как бы она выглядела?» — и только потом строится мост от нынешнего состояния к целевому. Идеология та же, что у zero-based budgeting (бюджетирование с нулевой базой, где каждая статья ежегодно обосновывается заново, а не индексируется от прошлого года): нулевая точка отсчёта ломает якорение на статус-кво.
Механика clean-sheet-упражнения: (1) зафиксировать исходы, которые функция обязана производить (закрытая отчётность к N-му дню, оплаченные поставщики, нанятые люди), — не процессы, а исходы; (2) спроектировать минимальную систему «данные + агенты + люди-контролёры», производящую эти исходы, исходя из сегодняшних технологий; (3) посчитать её стоимость и штат — это целевой бенчмарк, обычно в разы агрессивнее квартильных бенчмарков из раздела 11.4, потому что квартили усредняют компании с наследием; (4) сравнить с текущим состоянием и решить по каждому блоку: мигрировать или строить заново рядом.
Для стратегии Алексея «новое рядом, а не чинить старое» zero-based design — не один из вариантов, а естественная методология: новые чистые юрлица холдинга с первого дня живут на движке, спроектированном с чистого листа, а старая компания не «трансформируется» — она постепенно переводит объёмы на движок процесс за процессом, как банки переводят клиентов на новое ядро. Это же снимает главный риск классических трансформаций — необходимость перестраивать самолёт в полёте: старый бэк-офис продолжает работать без изменений, пока движок не докажет метриками (touchless, FTR, cost per transaction) превосходство на реальном потоке. Плата за подход — период двойных затрат (две системы живут параллельно) и дисциплина рубежей: без жёстких дат перевода объёмов старая система не умирает никогда.
Не проектировать движок как «автоматизацию 255 процессов» — спроектировать clean-sheet целевую модель бэк-офиса холдинга (исходы → минимальная система → целевой штат УК), а реестр 255 процессов использовать как карту миграции и проверку полноты, а не как техзадание. Правило: старые процессы переезжают на движок только в стандартизованном виде — движок не принимает наследие «как есть».
11.8 Цифровой двойник организации и process mining: докажи цифрами
Две технологии дают методологии перехода измерительную и испытательную базу — «сначала докажи цифрами, потом перестраивай».
Process mining (майнинг процессов) — дисциплина, созданная Вилом ван дер Аалстом (Wil van der Aalst, Эйндховен/Ахен, «крёстный отец process mining») в начале 2000-х и превращённая в индустрию компанией Celonis (Мюнхен, основана в 2011-м, крупнейший вендор рынка). Механика: любая информационная система оставляет журнал событий (event log) — минимум «идентификатор кейса + активность + отметка времени». Алгоритмы discovery восстанавливают из журнала фактическую модель процесса — не ту, что нарисована в регламенте, а ту, что реально исполняется, со всеми обходными путями, петлями переделок и «теневыми» маршрутами. Conformance checking сравнивает факт с нормативной моделью и считает отклонения; performance mining раскладывает время цикла по шагам и очередям. Классический результат первого прогона: процесс, у которого в регламенте 8 шагов, в реальности имеет десятки и сотни вариантов маршрута, и 60–80% времени цикла — это ожидание между шагами, а не работа. Для программы перехода process mining выполняет три роли: честная инвентаризация (дополняет и проверяет самодекларации из раздела 11.1 — люди не помнят, машина логирует), приоритизация (где на самом деле теряются часы и деньги), контроль эффекта (те же метрики до и после — доказательство, что touchless вырос не на бумаге). Дополнение — task mining: запись действий на рабочем столе (клики, приложения, копипаст между окнами) там, где системных логов нет; именно task mining ловит главный резерв бэк-офиса — ручной перенос данных между несвязанными системами.
Цифровой двойник организации (digital twin of an organization, DTO) — термин Gartner (~2018): динамическая программная модель организации, опирающаяся на операционные данные, — по сути, следующая ступень process mining: не только видеть фактический процесс, но и симулировать его изменения. Механика: восстановленная из логов модель процесса дополняется параметрами (частоты вариантов, распределения длительностей, ресурсы, правила маршрутизации) и превращается в имитационную модель (discrete-event simulation), на которой прогоняются сценарии: «что будет с циклом и штатом, если 70% транзакций уйдут в touchless, а люди останутся только на исключениях?», «где возникнет новое узкое место?». Это дешёвый способ ошибаться: эксперимент над моделью стоит часы, эксперимент над живым бэк-офисом — месяцы и деньги. Честная оговорка: полноценный DTO «всей организации» на практике редок и в значительной степени остаётся маркетинговой рамкой (Gartner сам числил DTO среди «переоценённых» концепций хайп-цикла); работающая же практика — симуляция отдельных ключевых процессов перед их перестройкой, и именно в этом объёме её стоит применять.
Практическое замечание по масштабу: компании в 180 человек не обязателен Celonis (лицензии от сотен тысяч долларов); открытый инструментарий (PM4Py — питоновская библиотека ван-дер-аалстовской школы) и выгрузки из трекеров, ERP и сервис-десков покрывают потребности первой инвентаризации силами одного data-инженера. Более того, для нового движка process mining — не внешний инструмент, а архитектурное требование: событийный журнал каждого процесса проектируется сразу, и двойник движка существует по построению, а не восстанавливается археологией по логам.
До перестройки — один прогон process mining по 3–5 самым дорогим процессам текущей компании (PM4Py + выгрузки из ERP/трекеров): он заменит месяцы интервью и покажет фактические маршруты и потери. В сам движок заложить event log как первичный артефакт каждого процесса (case id, activity, timestamp, actor: человек/агент) — тогда метрики раздела 11.3 и симуляция «что если» становятся запросом к данным, а не проектом.
11.9 Модели зрелости: самодиагностика и её ловушки
Модели зрелости (maturity models) — семейство диагностических рамок, выросшее из CMM/CMMI (Capability Maturity Model, Университет Карнеги — Меллона, конец 1980-х, изначально для оценки подрядчиков Минобороны США по разработке ПО). Общая конструкция: пять уровней от «начального/хаотического» (уровень 1: результат зависит от героизма отдельных людей) через «повторяемый», «определённый» (процессы документированы и стандартны), «управляемый количественно» (процессы измеряются) до «оптимизирующегося» (процессы непрерывно улучшаются на основе данных). По этому шаблону построены BPM maturity (зрелость процессного управления — например, модель Хаммера PEMM с её двумя осями «зрелость процесса» и «зрелость предприятия»), модели автоматизационной зрелости вендоров RPA, модели зрелости данных (DAMA, DCAM) и аналитики (Gartner: descriptive → diagnostic → predictive → prescriptive).
Польза моделей зрелости — в двух вещах. Первая: словарь для честного разговора — «наш процесс закрытия месяца на уровне 2: работает, пока Мария Ивановна не в отпуске» — это точный диагноз, понятный всем. Вторая: правило последовательности — нельзя перепрыгнуть с уровня 1 на уровень 4; в терминах этой главы: нельзя навесить агентов (уровень «оптимизирующийся») на процессы, которые не стандартизованы (уровень 3) и не измеряются (уровень 4), — это формальное обоснование ESSA-порядка из раздела 11.6 и jidoka-требования стабильности.
Критика, которую нужно знать до применения. Первое — карго-культ уровней: организация начинает работать «на аттестацию» (документы, комитеты, артефакты, изображающие зрелость) вместо работы на результат; история CMMI-сертификации аутсорсинговых компаний — хрестоматийный пример того, как уровень 5 на бумаге сочетается с провальными проектами в реальности. Второе — модели зрелости консервативны по построению: они описывают путь «как у лучших вчера» и потому систематически недооценивают скачки технологий; компания, строящая движок с нуля, может «родиться» сразу на уровне 4–5 по измеримости (event log по построению, раздел 11.8), не проходя ритуалы уровней 2–3. Третье — уровни агрегируют слишком грубо: реальная организация всегда «пятнистая» (закупки — уровень 4, найм — уровень 1), и управленческое значение имеет карта пятен, а не средняя температура. Вывод: использовать модели зрелости как чек-лист самодиагностики по процессам (полчаса на процесс, шкала 1–5 по осям «стандартизован / измеряется / автоматизирован / улучшается»), но никогда — как дорожную карту («год на уровень 3, потом год на уровень 4») и никогда как KPI.
11.10 Последовательность внедрения: пилот → продуктизация → масштабирование
Когда приоритеты расставлены, встаёт вопрос организации самой работы. Проверенная временем последовательность состоит из трёх фаз с разными целями и критериями успеха.
Пилот отвечает на один вопрос: «работает ли это на нашем реальном потоке?» — и потому должен идти на живых транзакциях (не на синтетике), на полном потоке процесса (включая исключения) и с заранее, до старта, зафиксированными критериями успеха/провала (целевой touchless, FTR, стоимость). Типичная ошибка — пилот как демонстрация: удобный участок, отобранные кейсы, критерий «понравилось руководству». Такой пилот всегда «успешен» и ничего не доказывает — это прямая дорога в чистилище пилотов (pilot purgatory — термин, введённый McKinsey для описания IoT-внедрений, застрявших в вечных пилотах; в 2024–2026 годах он массово применяется к GenAI: по данным доклада MIT Media Lab / проекта NANDA «The GenAI Divide: State of AI in Business 2025», ~95% корпоративных GenAI-пилотов не дают измеримого эффекта на P&L — не потому, что модели плохи, а из-за «разрыва обучения»: инструменты не встраиваются в рабочие процессы и не учатся на обратной связи; примечательно, что закупленные специализированные решения доходили до продуктива примерно вдвое чаще, чем внутренние поделки).
Продуктизация — фаза, которую чаще всего пропускают, и именно её пропуск порождает RPA-долг. Пилот, каким бы успешным ни был, — это прототип. Продуктизация превращает его в промышленный компонент: обработка всех веток исключений, мониторинг и алёрты, журналирование (event log), тесты, документация, владелец, процедура изменения, план отката. Правило: автоматизация — это продукт с жизненным циклом, а не проект с датой окончания; у неё есть роадмап, поддержка и деградация без ухода.
Масштабирование — тираж продуктизированного компонента на новые объёмы, юрлица и смежные процессы. Здесь решается организационный вопрос: кто это делает? RPA-эпоха дала два ответа: центр компетенций (Center of Excellence, CoE — центральная команда, которая одна строит все автоматизации) и федеративная модель (центр задаёт платформу и стандарты, а строят распределённые команды в функциях). Опыт 2016–2022 годов однозначен: чистые CoE-модели буксовали. Деминговская арифметика простая: центральная команда становится бутылочным горлышком (очередь заявок на месяцы), не знает предметной области процессов, которые автоматизирует, а бизнес не чувствует владения результатом. Статистика RPA-эпохи это фиксирует: по глобальному опросу Deloitte (2018), лишь 3–4% организаций, внедрявших RPA, смогли масштабироваться до 50+ роботов, а оценки доли неудачных стартовых RPA-проектов в 30–50% (широко цитируемые данные EY) стали общим местом отрасли (обе цифры — из консалтинговых опросов, методология не публиковалась полностью). Работающий ответ — федерация: центральная платформа (инфраструктура, стандарты безопасности, каталог компонентов, обучение) плюс автоматизаторы внутри функций, знающие процесс изнутри. В эпоху LLM-агентов федеративная модель радикализуется: «строителем» автоматизации всё чаще выступает сам владелец процесса, описывающий регламент на естественном языке, а платформенная команда отвечает за среду исполнения, контуры контроля и качество данных.
Каждый процесс проходит три статуса — «пилот на живом потоке с заранее записанными критериями» → «продуктизирован (исключения, мониторинг, владелец, откат)» → «тиражирован на все юрлица», и статус фиксируется в том же реестре работы. Оргмодель — федеративная с самого начала: платформенная команда движка (2–4 человека) владеет средой исполнения агентов и стандартами, владельцы процессов в юрлицах «пишут» автоматизации регламентами. Урок MIT-2025: покупать зрелые специализированные решения там, где они есть, и строить самим только ядро — оркестрацию, данные, контроль.
11.11 Управление изменением при сокращении ролей
Безлюдный движок — это по определению программа, в конце которой части ролей не будет. Делать вид, что «никто не пострадает», — худшая из стратегий: люди не глупы, недосказанность читается мгновенно, и программа получает тихий саботаж — а инвентаризация и стандартизация (разделы 11.1, 11.6) невозможны без людей, которые единственные знают, как процессы устроены на самом деле.
Из классических моделей управления изменениями достаточно двух, без воды. Коттер (John Kotter, «Leading Change», 1996; 8 шагов) даёт три практических императива: изменение начинается с ощущения необходимости (sense of urgency) — в нашем случае это честный рассказ, что происходит с рынком заказной разработки и BPO (раздел 11.5), а не «оптимизация ради оптимизации»; нужна коалиция — программа перехода, которую двигает один CEO против молчаливого среднего менеджмента, обречена; и нужны короткие победы — первые процессы на движке должны освобождать людей от ненавидимой работы (ручные сверки, перенос данных), а не от любимой. ADKAR (Prosci; Awareness — Desire — Knowledge — Ability — Reinforcement) полезен как диагностика по каждому человеку: сопротивление всегда локализуется на одной из пяти ступеней (не знает, зачем / не хочет / не умеет / не может на практике / откатывается), и лечится ступень, а не «сопротивление вообще».
Практика при сокращении ролей сводится к четырём правилам. Правда о судьбе ролей, рано: объявить принцип («движок заберёт транзакционную работу; ролей X к году Y не будет; вот варианты для каждого») до старта, а не после пилотов, — неопределённость демотивирует сильнее плохих новостей. Переофферы и redeployment прежде увольнений: у оператора процесса есть три естественные траектории — владелец/тренер агентов своего процесса (кто лучше знает исключения?), контролёр исключений (та самая работа «хвоста распределения» из раздела 11.3), переход в растущие бизнес-активы холдинга; честная оценка — покроют не всех, но обязаны быть предложены каждому. Не платить людям за самоуничтожение без контракта: сотрудник, обучающий агента своей работе, должен заранее знать свою следующую роль или условия выхода (retention-бонус до даты, расширенное выходное пособие) — иначе рациональная стратегия каждого — тихо тормозить программу. Этика как экономика репутации: холдинг, публично строящий «безлюдные» активы, будет нанимать редких и дорогих людей в УК и продукты; рынок труда в IT узок, и то, как компания расстаётся с людьми в 2026-м, определяет, кого она сможет нанять в 2028-м.
11.12 Анти-паттерны перехода: каталог граблей
Закончим главу каталогом типовых способов провалить переход — все они многократно задокументированы в разборах 2016–2026 годов.
Автоматизация ради KPI автоматизации. Как только целью становится «N процессов автоматизировано» или «M агентов внедрено», программа начинает производить именно это — счётчик, а не эффект: автоматизируются лёгкие и бесполезные процессы, работа людей никуда не девается. Противоядие — метрики, взвешенные по деньгам и часам (span of automation, cost per transaction, раздел 11.3), и запрет на отчётность «в штуках». Это тот же закон Гудхарта, что и с бенчмарками.
RPA-долг. Роботы RPA-эпохи автоматизировали интерфейсы (клики по экранам), а не процессы; каждый апдейт исходной системы ломал роботов, парк из сотен ботов требовал команду поддержки, сопоставимую с сэкономленными людьми, и «автоматизация» превращалась в новый класс наследия (legacy). Общий механизм — автоматизация поверх беспорядка фиксирует беспорядок: робот, повторяющий действия человека в старом интерфейсе, цементирует и интерфейс, и процесс. Агентные системы наследуют риск в новой форме (промпты и обвязка, намертво привязанные к конкретным экранам и форматам); противоядие то же — автоматизировать через API и данные, а не через имитацию человека за монитором, и проходить продуктизацию (раздел 11.10).
Лоскутные интеграции. Каждая автоматизация тянет свою пару «точка-точка» интеграций; через два года карта интеграций — спагетти, изменение одной системы ломает восемь автоматизаций. Противоядие архитектурное и описано в предыдущих главах: единый слой данных и событийная шина как фундамент движка, автоматизации подключаются к платформе, а не друг к другу.
Локальная оптимизация против потока. Урок теории ограничений (TOC, Голдратт, «Цель»): улучшение участка, не являющегося ограничением системы, не даёт системного эффекта — час, сэкономленный не на бутылочном горлышке, это мираж. Бэк-офисная версия: идеально автоматизированное выставление счетов ничего не меняет, если деньги застревают на согласовании у двух топ-менеджеров; touchless одного шага при недельной очереди на следующем — косметика. Противоядие — оптимизировать по карте потока из process mining (где на самом деле очередь), а эффект мерить только end-to-end метриками процесса (cycle time от входа до денег), не пошаговыми.
Pilot purgatory / витринная трансформация. Организация коллекционирует пилоты и демо, отчитывается инновациями, но ни один пилот не проходит продуктизацию; через два года — музей прототипов и усталость от слова «AI». Свежие данные приводились выше (MIT NANDA 2025: ~95% GenAI-пилотов без P&L-эффекта); туда же — многолетняя оценка, что ~70% программ трансформаций не достигают целей (McKinsey/Kotter-традиция; цифра методологически спорна, но направление подтверждается каждым новым опросом: BCG в 2024–2025 годах оценивал долю AI-программ, достигших целевой ценности, примерно в четверть). Общий механизм провала не технический: пилоты живут вне рабочих потоков, без владельцев, без критериев и без обязательства «прошёл критерии — обязан ехать в прод». Противоядие — правило «пилотируем только то, что заранее обязались масштабировать при достижении записанных критериев», и бюджет, в котором продуктизация стоит в 3–5 раз дороже пилота (если в бюджете этого нет — программа спроектирована как театр).
Повесить над программой четыре запрета: не отчитываться «числом автоматизаций» (только часы и рубли из реестра), не автоматизировать через имитацию человека в интерфейсах (только API и данные), не подключать автоматизации друг к другу (только к платформе), не запускать пилот без записанных критериев и обязательства масштабирования. И помнить арифметику 2025 года: 95% пилотов умирают не от слабых моделей, а от отсутствия встройки в поток и владельца — преимущество Алексея в том, что у движка, строящегося с нуля, «встройка в поток» — это сам движок.
Источники и куда копать глубже
Библия реинжиниринга; читать вместе с первоисточником-статьёй «Don't Automate, Obliterate» ради кейса Ford AP.
Теория ограничений в форме романа; прививка от локальной оптимизации.
Фундаментальный учебник по process mining от создателя дисциплины.
Восемь шагов изменений; главы про urgency и короткие победы — самые практичные.
Компактная история сорока лет консолидации бэк-офиса (материалы под ред. Deborah Kops).
Методология оценки автоматизируемости по активностям; ~50% активностей, <5% профессий.
Обновление оценок: 60–70% рабочего времени, $2,6–4,4 трлн/год, сдвиг сроков на десятилетие.
«95% пилотов без P&L-эффекта» и механизм learning gap; см. разбор Fortune.
Почему $300-миллиардный BPO — главная мишень агентов; тезис services-as-software.
Свежие цифры: −45% стоимости, −42% FTE, 99% автоматизации проводок.
Пример процессного бенчмарка: верхний/нижний квартиль стоимости обработки счёта.
Механика event log → discovery → conformance из первых уст.
Практические кейсы process mining и «цифрового двойника» у корпораций; кейноуты ван дер Аалста и аналитиков Gartner.
Связка process mining → цифровой двойник в изложении вендора (читать критично).
Главное профсообщество shared services/GBS: отчёты, метрики touchless/STP, кейсы.