Маховик не запустился через 3 месяца

Определение. Маховик не запустился (stalled flywheel) — состояние, при котором архитектура AI-процесса собрана: база знаний есть, лог решений пишется, агент работает. Но через 3 месяца Доля вмешательств не падает ниже 60%. Петля обратной связи разомкнута: данные накапливаются, в качество не превращаются.

TL;DR. Маховик данных это архитектура из пяти элементов, которая должна замыкать петлю обучения. Через 3 месяца после запуска один из элементов выпал, цикл не замкнулся, AI не учится. Главная развилка: маховик не закрутился или маховик правильно не запускался. По канону методики Oper8 маховик нужен 15–20% процессов компании — тем, где идёт обучение на каждом контакте. Если ваш процесс из остальных 80%, отсутствие маховика это норма, и самая дорогая ошибка — лечить правильное отсутствие как поломку, бросая ресурсы в цикл, который и не должен крутиться. Поэтому чек-лист «нужен ли маховик» делается до диагностики механизмов остановки.

Как распознать

• Доля вмешательств держится 80–100% второй месяц подряд, никогда не падала ниже 60%.
• Поле результата в логе решений пустое у 40%+ записей. Решение принимается, что было дальше, никто не записывает.
• Третий слой базы знаний (примеры с обоснованием) насчитывает меньше 50 записей через 3 месяца. Лог растёт, в обучающий материал не конвертируется.
• Eval dataset не растёт. Версия от запуска остаётся той же через 3 месяца.
• Демо для топ-уровня проходят, реальные клиентские контакты результата не дают.

Это маховик не нужен или поломка?

Перед диагностикой механизмов остановки проверьте, должен ли маховик вообще крутиться. Четыре вопроса; 3+ «да» означают «маховик нужен».

1. Процесс влияет прямо на клиентский опыт, выручку или удержание? Бэкофис и отчётность обычно нет.
2. Каждый контакт учится на предыдущем? Если решения изолированы (новый случай не зависит от истории), нет.
3. Больше 100 значимых контактов в день? Если меньше, внешний цикл физически не разгонится.
4. Стоимость ошибки высокая? Если ошибку легко переделать вручную, маховик избыточен.

Если 3+ «нет», диагноз другой: процесс из 80%-категории получил инструмент 20%-категории. Лечение: упрощение до автоматизации без маховика, не починка. Перед бордом это звучит не «ждём, когда заработает», а «убрали маховик, оставили простую автоматизацию, вернёмся через год».

Пять механизмов остановки

Каждый механизм — отказ одного из элементов архитектуры маховика. Механизмы 1–4 — из канона методики; механизм 5 — наблюдение из наших проектов.

1. Петля результата разомкнута. Лог решений пишется, агент действует, но поле «результат через N дней» не заполняется. Источник правды (CRM, бэкофис, клиент) не возвращает сигнал автоматически, ручная разметка не назначена. Без поля результата лог превращается в архив отправок. Это самый частый и самый дешёвый в починке механизм. «Дешёвый» относительно: автоматический возврат сигнала из 1С или legacy-CRM без webhook'ов — обычно 2–6 недель работы инженера через периодический опрос таблиц, а не пол-дня.

2. Лог не конвертируется в примеры. Лог растёт, но третий слой базы знаний (примеры с обоснованием) пустой. Никто не выполняет ежедневный ритуал «5–10 решений из лога → 1–2 примера в базе». Лог как учебник для людей; учебник не пишется сам и требует ритма владельца процесса 10–20 мин в день.

3. Eval dataset статичен. Проверки настроены, но dataset из тех же 100 примеров, что собрали при запуске. Новые паттерны не добавляются, регрессии новых сегментов проскакивают. Команда видит «всё хорошо» на тестах, в продакшене метрики не растут. Лечится ежемесячным обзором: 20–30 новых примеров из логов, тестирование на текущей версии.

4. ODD не определена. ODD (operational design domain, операционная область применения) задаёт пространство задач, где автономия допустима. Если ODD не зафиксирована или агент регулярно вызывается за её пределами, он пытается решать задачи, которых нет в базе знаний. Доля вмешательств не падает по объективной причине: AI действительно не справляется с тем, что ему дают. Симптом: «он всё время ошибается на странных запросах». По наблюдениям на 3 наших проектах после отсечения сегментов вне ODD на маршрутизаторе Доля вмешательств за месяц падает с 90% до 40–50%.

5. Внешний цикл слишком медленный (пограничный случай). В отличие от механизмов 1–4, это не поломка архитектуры, а несовпадение масштаба: формально маховик собран правильно, но физически не получает достаточно сигналов. SMB с 5 контактами в день и циклом обратной связи в 2 недели даёт ~50 сигналов в месяц вместо нужных 500–1000 (наша оценка, малая выборка, не индустриальная константа). Решение то же, что в чек-листе выше: признать процесс из 80%-категории, упростить до автоматизации без маховика, вернуться к маховику когда трафик вырастет.

Как выходить

Шаг 1 (неделя 1). Чек-лист «нужен ли маховик» плюс пять диагностических вопросов по механизмам. Часто 3 из 5 механизмов работают одновременно. Иногда оказывается, что процесс не из 20%-категории, это самый дешёвый итог: меньше вреда, чем продолжение починки.

Шаг 2 (недели 2–6). Закрытие самого дешёвого механизма, обычно петли результата. Автоматический возврат сигнала из источника правды занимает 2–6 недель работы инженера при занятости 60–80% (в часах — 60–200). Эффект виден через 2–4 недели после запуска по росту заполнения поля результата.

Шаг 3 (недели 4–8, параллельно). Ритуал владельца процесса 10–20 мин в день на конвертацию лога в примеры базы знаний. Если у владельца этого времени физически нет (топ-менеджер уровня COO или директора продаж), вариант — выделенная координирующая роль. В Москве и Питере 200–250 тыс ₽/мес ФОТ; в регионах часто проще переквалифицировать L2-аналитика изнутри, около 3 месяцев адаптации.

Шаг 4 (по результатам месяца 2 после интервенции). Решение «продолжаем или сворачиваем». Доля вмешательств снизилась на 15+ процентных пунктов И бизнес-метрика (выручка, удержание, CSAT) не деградировала: продолжаем. Снижение 5–14 пп: маховик частично работает, доделать следующий механизм, ещё месяц. Снижение менее 5 пп или Доля упала, а бизнес-метрика тоже: пересмотр архитектуры или переход на упрощённую автоматизацию. Только Доля без бизнес-метрики — фантом, метрический театр.

Пример из практики

Mid-market B2B-дистрибьютор электроинструмента в Москве, 180 человек. AI-процесс по подбору предложений для клиентов на основе истории заказов и сезонности. Архитектура собрана за 6 недель: база знаний из CRM (3 слоя, 200 правил), лог решений в системе, eval dataset 80 примеров, A2 автономия с одобрением каждого решения.

Через 3 месяца Доля вмешательств 87%, лог 2 800 записей, поле результата заполнено в ~30%. Третий слой базы знаний насчитывал менее 20 примеров (план был 50–100). Владелец — руководитель отдела продаж — смотрит метрики на еженедельной сводке. Никто не делает ежедневной работы с логом.

Диагностика: механизмы 1 и 2. Решение: координатор-аналитик на 60% ставки (220 тыс ₽/мес ФОТ). Задачи координатора: автоматизация обратного сигнала из CRM плюс 1 час в день на конвертацию решений в примеры. Автоматизация заняла 4 недели вместо плановых 1–2: у CRM не было webhook'ов, делали через периодический опрос силами одного 1С-программиста с навыком Python. Через 2 месяца после интервенции поле результата заполнено в ~75%, база знаний выросла до ~90 примеров. Доля вмешательств снизилась с 87% до ~65%, не до плановых 51%. Вылез механизм 3: eval dataset не обновлялся с запуска, на новых сегментах товаров регрессии проскакивали мимо. Требует ещё месяца работы.

Альтернативный сценарий, который не выбрали: руководитель отдела продаж пытался делать ритуал лично, через 3 недели бросил — операционка съедала окно. Урок: если у владельца физически нет 1.5 ч/день, нужна выделенная роль, иначе процесс правильнее перевести в 80%-категорию.

Что путают

Не путать с пилотом без выхода. У пилота без выхода маховик работает, но AI годами обрабатывает 5–10% трафика. У маховика, который не запустился, AI обрабатывает 100% потока, метрики не сдвинулись с первого дня. Симптомы внешне похожи (нет роста бизнес-метрик), лечатся разными инструментами.

Не путать с AI поверх сломанного процесса. У сломанного процесса маховик крутится, но автоматизирует кривой процесс: eval-метрики растут, бизнес-метрики стоят. У маховика, который не запустился, eval-метрики тоже не растут — новые паттерны в dataset не попадают.

Внешний взгляд: команда отчитывается как stalled-flywheel, реально процесс из 80%-категории. На чек-листе «нужен ли маховик» процесс получает 3+ «нет», но команда продолжает лечить петлю результата, нанимать координатора, обновлять eval. Со стороны выглядит как активное лечение, на деле — починка симптома, которого не было. Раскрывает диагноз только разговор спонсора с владельцем процесса один на один: «расскажи, как клиенты используют твой процесс».