Отчёт MIT Project NANDA 2025 года «The GenAI Divide: State of AI in Business» обнаружил, что около 95% корпоративных пилотов с генеративным ИИ не дали измеримого эффекта на P&L. Цифру цитируют как доказательство, что технология не работает. Измеряет она не это.
Она измеряет провал доставки. Пилоты в основном делали то, для чего были построены; построены они были показать возможность, а не изменить процесс, а возможность в P&L не появляется. Те 5%, что эффект дали, — это в подавляющем большинстве проекты, вшитые в реальный рабочий процесс и с числом, привязанным к ним с самого начала.
Если метрику выбирают после того, как пилот отработал, пилот не может провалиться — а значит, и не может удаться. Все объявляют частичную победу, проект тихо заканчивается, и ничего не разворачивается.
Лечение скучное и действенное: назовите одно число, измерьте его до старта и заранее договоритесь, какое значение считается успехом. «Среднее время обработки по этой категории тикетов, сейчас 11 минут, цель — меньше 7» — это метрика. «Улучшить клиентский опыт» — это способ метрики избежать.
Мы согласуем метрику успеха на аудите, до того как будет спроектирован пилот. Если не удаётся найти число, которое примут обе стороны, это само по себе вывод — и обычно означает, что процесс не подходит на роль первого.
Пилоты демонстрируют на чистых 80%. Продакшен — это в основном остальные 20%: искажённый ввод, поставщика нет в справочнике, клиент, который одновременно партнёр, случай, которого правила не предусмотрели.
Пилот без пути исключений выглядит впечатляюще и не может быть развёрнут, потому что первый же день в продакшене выдаёт случай, который он молча обработает неправильно. Проектирование путей отказа — повтор, передача человеку, остановка потока — это не лоск, добавляемый в конце. Это разница между демо и системой.
Автоматизация — не результат, который остаётся готовым. Поставщики меняют форматы, система выпускает новую версию, объёмы сдвигаются, меняется политика. Без named-владельца и дашборда, который показывает дрейф, поток тихо деградирует, и кто-нибудь в итоге его выключает.
Для этого не нужна команда. Нужен один человек, у которого это в должностных обязанностях, и вид мониторинга, делающий деградацию видимой раньше, чем её найдёт клиент.
Самая дорогая ошибка в последовательности — сначала доказать модель, а системы подключать потом. Риск для сроков живёт именно в интеграции: доступы, песочницы, лимиты запросов, система без API, вендор, который отвечает три недели.
В обратном порядке — сначала убедиться, что данные могут двигаться, потом доказать модель на реальных данных на месте — это не стоит ничего дополнительно и убирает режим отказа, при котором удачный пилот нельзя развернуть по причинам, обнаруженным на третий месяц.
Пилот, который работает на выгруженных таблицах, не проверен против того, что вероятнее всего его и убьёт.
Один процесс, целиком, на реальных данных, в реальных системах, с названной метрикой, измеренной до и после, с путём исключений на каждом шаге и с владельцем с первого дня. Уже обычного пилота по амбиции и намного шире по тому, что доказывает.
В этом весь аргумент за узкий объём: узкая вещь в продакшене лучше широкой в презентации, и это к тому же единственная версия, которая даёт доказательства, нужные для финансирования следующей.
Аудит, пилот с метриками, согласованными заранее, затем поэтапная раскатка.
Как выбрать число, по которому будут судить пилот.
Большинство провалов пилотов — провалы выбора, сделанного до внедрения.
Мы используем cookie только для аналитики — чтобы видеть, с каких страниц приходят заявки. Ничего больше и ничего до вашего согласия. Политика cookie