Как распознать
- AI обрабатывает задачу за 2 минуты, но она всё равно ждёт в очереди 3 дня. Узкое место не на этом шаге.
- Метрики проверок растут, бизнес-метрики стоят или падают. Самый частый и самый игнорируемый признак. Eval-точность 94%, время цикла прежнее, стоимость на сделку выросла.
- Эффективность потока ниже 20%. Lean-метрика, в Process Mining называется process flow efficiency (PFE) — доля полезного времени в общем времени цикла. Считается по самому медленному звену: время от создания записи в 1С до перехода на следующий шаг, делённое на полное время цикла. Норма 30–50%, хорошо 50–70%. Меньше 20% — большинство времени уходит на ожидание, переработки, исправление ошибок.
- Появились ошибки нового типа. Раньше люди обходили их молча, теперь AI следует правилу буквально и ошибки видны. Рост числа эскалаций после внедрения AI больше +20% — это сигнал: AI выявил кривизну, которую процесс маскировал.
- AI внедрена без предварительного аудита потока. Картирования процесса нет, команда исходит из «как должно быть по документации», а не «как есть в реальности».
Почему случается
Кажется, что AI быстрее, чем перепроектирование. На совещании звучит: «Перепроектирование займёт год, AI запустим за 3 месяца». Через 8 месяцев AI работает, бизнес-метрики не сдвинулись, и теперь нужно и перепроектировать, и переучивать модель. Суммарно проигрыш 1.5–2× по времени и 2–3× по бюджету относительно правильного порядка.
AI хорошо работает на одном шаге. Узкое место чаще на стыках процесса (передачи, ожидания, согласования), а AI ставят на сильный шаг, где её эффект виден. Поэтому первый отчёт через 4–6 недель красивый: «время шага сократилось с 3 дней до 2 часов». На сквозную скорость это не влияет, но политически выигрывает: проект продолжается, перепроектирование откладывается.
Грязные данные команда не считает дефектом процесса. «В поле "регион" пишут то "Москва", то "Москва, Россия", то "Moscow", но люди же справляются». AI не справляется, ошибки накапливаются. Команда называет это «проблемой обучающей выборки» и тратит 2–3 месяца на чистку данных, вместо того чтобы починить место их ввода.
Замёрзший средний уровень блокирует перепроектирование. Перепроектирование означает явные правила, описанные роли, лог решений, и всё это уничтожает информационную монополию менеджера. AI на старом процессе монополию не трогает: автоматизируется исполнение, а правила и решения остаются у людей. Поэтому средний слой тихо предпочитает «AI на текущем», а не «процесс заново».
К чему приводит
Бюджет растёт быстрее экономии. Стоимость поддержки AI на сломанном процессе включает: чистку данных каждый квартал, обработку новых типов ошибок, ручную работу со сложными кейсами, которые раньше игнорировались. Через 12–18 месяцев сумма этих расходов часто превышает экономию от ускорения шага.
Появляется ложный сигнал успеха. Eval-метрики хорошие, отчёты зелёные, команда отчитывается наверх: «AI работает». Но операционка не выиграла: тот же lead time, та же стоимость на сделку, иногда и хуже. Когда финансовая служба считает фактический ROI через год, обнаруживается, что AI-инициатива в минусе. Доверие к AI проседает, следующий пилот защищать дороже.
Через 18–24 месяца появляется каскад. Закрытие первой AI-инициативы как «не оправдавшей ROI» замораживает следующие два-три предложения от других подразделений: «уже пробовали, не работает». Команда перепроектирования формируется через год после того, как должна была. Альтернативная стоимость задержки выше прямого перерасхода и редко попадает в отчёт о провале.
Как выходить
1. Диагностика — это автоматизация хаоса или нет. Возьмите три проверки.
- Замерьте эффективность потока процесса. Меньше 20% даёт автоматизацию хаоса с вероятностью около 80%.
- Сопоставьте eval-метрики и бизнес-метрики за последние 8–12 недель. Если eval растут на 10%+, а бизнес стоит или упал — это автоматизация хаоса с вероятностью около 90%. Разрыв указывает, в какой шаг смотреть: узкое место находится на стыках процесса или на шаге, где AI ещё не работает, не там, где работает.
- Спросите владельца процесса: «где мы теряем больше всего времени». Если ответ «везде по немногу», это сигнал фундаментального хаоса.
2. Перепроектирование перед расширением AI. Если диагностика подтвердила паттерн, расширять AI бесполезно. Правильный порядок: ручной аудит потока или process mining (1–2 недели в SMB, 3–4 недели в Mid-market, 6–8 недель в Enterprise) → диагностика узких мест → перепроектирование (6–12 недель в Mid-market с владельцем процесса и аналитиком, в SMB 2–4 недели с собственником) → возврат AI на чистый процесс. Перестановка любых двух шагов даёт перерасход бюджета в 2–3 раза по наблюдениям в проектах Oper8 за 2025 год.
3. Гейт готовности перед следующим AI-кандидатом. На фазе выбора (SELECT методики Oper8) добавьте проверку эффективности потока в обязательный гейт. Норма для запуска AI — 20% и выше; ниже сначала перепроектирование, AI потом. Это снимает паттерн на входе, а не лечит постфактум.
Пример из практики
Страховая компания, обработка заявок 2023 года. Процесс: заявка поступает (1 день) → проверка документов (1 день) → анализ на мошенничество (3 дня) → одобрение (2 дня) → выплата (5 дней). Внедрили AI на шаг «анализ», точность выросла с 85% до 94%, время шага сократилось с 3 дней до 2 часов. Сквозное время цикла осталось 11 дней.
Узкие места были не на анализе. Документы загружали через сканер в общую папку, и сотрудник ОЦО переносил их вручную в 1С — этот шаг занимал полдня и не считался узким местом, потому что «так всегда было». Одобрение упиралось в офицера комплаенса, который проводил 80% времени на совещаниях. AI отлично работал на сильном шаге, узкие места никто не трогал. Через год проект закрыли как «не оправдавший ROI», хотя сам AI работал по плану.
Что путают
Не путать с осторожной выкладкой. Осторожная выкладка двойного прогона — AI обрабатывает 5–10% трафика, потом масштабируется по подписанному плану. У осторожной выкладки есть численные пороги перехода и дата следующей фазы. У AI поверх сломанного процесса нет порогов и нет масштабирования: eval хорошие, бизнес-метрики не сдвинулись, обсуждают «как ещё повысить точность».
Не путать с пилотом без выхода. Пилот без выхода — AI работает на 5–10% трафика три года, процесс под ним нормальный. AI поверх сломанного процесса — AI работает на 100% трафика, процесс под ним кривой. Симптомы похожи (нет роста бизнес-метрик), причины разные, лечатся разными инструментами.
Не путать с проблемой обучающей выборки. Когда AI ошибается из-за грязных данных, команда называет это «нужно больше данных» или «нужно перетренировать». Диагностический тест: если поле в 30%+ записей содержит вариативность («Москва» / «Moscow» / «77»), это дефект ввода в процессе, лечится на месте ввода. Если поле заполнено единообразно, но AI делает ошибки, это дефект модели. Перетренировка на тех же грязных данных даёт временный плюс 2–3% точности и возврат к исходному уровню через 2–3 месяца.
