Провалившийся пилот теряет деньги не в тот момент, когда не дал результата, а в тот, когда его закрывают без разбора. Сценарий знакомый: пилот провалился, цифры не сошлись, руководство спрашивает, куда ушли деньги, и проект тихо хоронят с выводом «AI у нас не работает». Но за эти недели компания уже заплатила за информацию, которую иначе добывала бы год, — и вопрос только в том, заберёт она её или выбросит вместе с проектом.
«Не получилось» — это три разных провала
Пилот AI — это ограниченная по сроку и объёму проверка гипотезы на данных компании, у которой до старта названы метрика и условие остановки. Из этого определения следует неприятная вещь: если метрику и условие не называли, то провалиться пилот не мог — он просто закончился, и спорить о его итогах можно бесконечно.
Если же рамка была, то «не получилось» распадается на три разных исхода, и лечатся они противоположным образом. Пока вы их не различили, любое решение принимается наугад.
Провалилась гипотеза. Технически всё работало, но эффекта нет: агент отвечал корректно, а конверсия не изменилась. Звучит как поражение, а на деле это ценнейший результат — вы за две недели узнали то, на что иначе потратили бы год.
Провалило исполнение. Гипотеза верная, но реализация не дотянула: модель ошибалась на типовых случаях, интеграция отваливалась, ответы приходили с задержкой. Здесь вопрос уже не «нужно ли это», а «кто и как это делает».
Провалилось внедрение в работу. Система работала, выводы были верные, но ими никто не пользовался. Самый частый и самый неприятный вариант, потому что чинить придётся не софт, а привычки и ответственность людей.
Один день на разбор: система, люди, метрика
Разбор не требует комиссии и месяца совещаний. Он занимает день и строится на трёх вопросах к данным пилота, причём задавать их стоит именно в этом порядке: каждый следующий имеет смысл, только если на предыдущий ответ «да».
Правильно ли работала система? Возьмите выборку в 50–100 случаев и разметьте вручную: сколько раз система отработала верно. Если доля верных ответов высокая — исполнение в порядке, ищите причину дальше. Если низкая — дальше можно не идти: метрика и не должна была сдвинуться.
Пользовались ли ею люди? Смотрите не на отчёты и не на слова, а на следы: открывали ли задачи, созданные системой, менялось ли поведение менеджеров, кто и как часто заходил в интерфейс. Работающая система, которой не пользуются, — провал внедрения, и никакая доработка модели его не исправит.
Сдвинулась ли целевая метрика? Если система работала, ею пользовались, а конверсия стоит на месте — вы получили честный ответ по гипотезе. Узкое место было не там, где его искали.
Заметьте, чего в этом списке нет: мнения команды о том, «понравилось ли». Ощущения участников пилота — плохой прибор. Уставшая команда оценит живой проект как мёртвый, а увлечённая — наоборот.
Возражение: зачем разбирать проект, который уже закрыт
У этой позиции есть серьёзные сторонники, и их аргумент стоит выслушать. Проект закончился, деньги потрачены, команда хочет забыть и заняться текущей работой. День на разбор — это ещё один день, вложенный в то, что уже не принесёт выручки. Экономисты называют такое ловушкой невозвратных затрат: не стоит добавлять ресурсы к проигранной ставке.
Аргумент верен ровно наполовину. Ловушка невозвратных затрат — это когда вы продолжаете проект, чтобы оправдать вложенное. Разбор — обратное действие: он нужен, чтобы перестать вкладывать, но перестать осознанно. Без него компания не знает, что именно закрыла — неверную идею, плохую реализацию или хороший инструмент, которым никто не пользовался.
А эти три случая ведут к противоположным решениям на следующий год. Неверную идею не стоит пробовать снова. Плохую реализацию стоит повторить с другими исполнителями. Неиспользуемый инструмент бесполезно покупать заново, пока не поменялся процесс. Закрыть проект, не узнав, какой из трёх случаев ваш, — всё равно что выписать пациента, не поставив диагноз: симптомов сейчас нет, но через полгода он вернётся с тем же.
Что остаётся на руках, даже если проект закрыт
Даже полностью закрытый проект оставляет активы, которые обидно потерять, — и которые пригодятся при любом следующем подходе.
- Размеченные данные. Сотня-другая случаев с эталонными ответами — это то, чего у вас не было и что пригодится в любом следующем подходе, хоть с другим подрядчиком.
- Базовая линия метрик. Теперь вы знаете, какая конверсия и какие сроки были до. Раньше это были ощущения.
- Карта процесса. Пилот всегда вскрывает, как работа устроена на самом деле, а не по регламенту.
- Понимание, где болит по-настоящему. Часто пилот показывает, что проблема была этажом выше — и это самая дорогая находка.
Пилот провалился: доработать, переставить или закрыть
После разбора вариантов остаётся три, и у каждого есть узкое условие, при котором он правильный.
Дорабатывать имеет смысл, когда провалило исполнение, а гипотеза подтверждается: люди пользовались, эффект нащупывался, мешало качество. Условие одно — понятно, что конкретно чинить, и это можно проверить за две-три недели. «Давайте ещё немного подкрутим» без названного дефекта — не доработка, а продление агонии.
Переставить на другой процесс — когда гипотеза не подтвердилась, но пилот показал, где настоящее узкое место. Условный пример: проект по контролю качества звонков заканчивается выводом, что менеджеры говорят нормально, а сделки теряются раньше — заявка ждёт первого ответа полдня. Инструмент был не тот, но деньги на пилот потрачены не зря: теперь известно, куда смотреть.
Закрыть — когда система работала, ею пользовались, метрика не изменилась и никакой альтернативной гипотезы нет. Это нормальный исход, и он дешевле, чем тянуть проект ради того, чтобы никому не пришлось признавать ошибку.
Какой вариант выбирают чаще, чем следовало бы? По-моему, доработку. Она психологически удобна: никто не проиграл, проект жив, бюджет продлевается малыми порциями. Именно поэтому к ней стоит относиться строже всего и требовать названный дефект и срок проверки.
Когда второй заход вообще не нужен
Агентству, которое зарабатывает на внедрениях, выгодно советовать попробовать ещё раз. Поэтому скажу прямо, в каких случаях второй пилот не нужен ни с нами, ни с кем-то другим.
Объём не окупит даже удачный результат. Если после честного расчёта выясняется, что при идеальной работе системы экономия меньше стоимости её поддержки, повторять нечего. Пилот уже ответил на главный вопрос, просто не тот, который задавали.
Проблема решается без ИИ. Нередко разбор показывает, что узкое место — в регламенте, мотивации или распределении заявок, и его закрывает приказ руководителя, а не модель. Какие задачи дешевле решить иначе, разобрано в статье о том, когда AI не нужен.
С вашей стороны некому вести изменения. Если провалилось внедрение, потому что у процесса не было владельца, и владельца по-прежнему нет, второй пилот закончится так же. Это одна из причин, по которым 404ai не берётся за проект: без человека, который принимает решения по процессу, результат не наступает, как бы хорошо ни работала система (так записано в нашем подходе).
Пилот провалился или просто идёт медленно
Разница существенная, а на глаз неразличимая: и в том и в другом случае к сроку нет результата, команда устала, а руководство спрашивает. Отличает их только то, что было названо до старта.
Если срок и критерий были заданы, ответ формальный: срок вышел, критерий не достигнут — пилот закончен, дальше разбор. Если их не было, вопрос не имеет ответа, и обсуждение превращается в спор об ощущениях, где выигрывает тот, кто настойчивее.
Признак медленного, но живого пилота: метрика движется в нужную сторону, просто медленнее ожидаемого, и понятно, что именно её тормозит. Признак провалившегося: метрика не движется, а объяснения меняются от встречи к встрече. Второе обычно означает, что причину не нашли и ищут не там.
Три ошибки в разборе провала
Первая и самая разрушительная — искать виноватого. Как только разбор превращается в поиск ответственного за неудачу, участники начинают защищаться, а не объяснять, и вся информация, ради которой затевался разбор, теряется. Следующий пилот в такой компании никто не вызовется вести.
Вторая — переписать цель под полученный результат. «Мы и не рассчитывали на рост конверсии, зато у нас теперь есть расшифровки всех звонков» — формулировка, которая спасает лицо и убивает возможность научиться. Цель фиксировалась до старта именно для того, чтобы её нельзя было подвинуть после.
Третья — немедленно запустить вторую попытку с другим подрядчиком. Если причина провала не установлена, вторая попытка воспроизведёт её в точности, только дороже. Разбор занимает день, вторая попытка — квартал; экономить стоит на второй.
Тот же подрядчик или другой
Вопрос решается по одному признаку: как подрядчик вёл себя, когда стало ясно, что не получается. Признаки хорошего поведения — сам сообщил о проблеме раньше, чем её заметили вы; предложил конкретные варианты; честно назвал, чего его решение не умеет.
Признаки, после которых менять стоит: проблема выяснилась от вас, а не от него; объяснения менялись; на прямой вопрос о возможностях системы отвечал уклончиво. Это не про качество технологии — это про то, как пройдёт следующий проект, когда снова что-то пойдёт не так, а идти не так будет обязательно.
Отдельный случай — когда провалилось внедрение, а не решение: люди не пользовались, процесс не поменяли, ответственного не назначили. Здесь смена подрядчика не изменит ничего, потому что причина на вашей стороне, и честнее признать это до подписания второго договора.
Как оформить выводы, чтобы через год их нашли
Знание, полученное в неудачном пилоте, живёт в головах трёх человек и исчезает вместе с ними. Через полтора года компания запускает похожий проект, потому что никто не помнит, что он уже был.
Документ нужен короткий, на страницу, и структура у него фиксированная: что проверяли и какой гипотезой, что было измерено до и после, что пошло не так и на каком шаге, что оставили себе, при каких условиях к этому стоит вернуться. Последний пункт важнее остальных: он превращает провал в отложенное решение, а не в закрытую тему.
Храниться он должен там, где его найдут — рядом с описанием процесса, которого касался, а не в почте участников. И упоминаться при следующем похожем предложении: пятнадцать минут на чтение прошлого разбора экономят квартал.
Что сказать команде и руководству
Формулировка «эксперимент не подтвердил гипотезу» звучит академично, но она честнее, чем «не получилось». Разница принципиальная: в первом случае компания научилась, во втором — потеряла.
Практически стоит зафиксировать письменно три вещи: что проверяли, что выяснили, что решили. Через полгода, когда вернётся вопрос «а почему мы это не делаем», такой документ сэкономит месяц обсуждений — и не даст повторить тот же заход второй раз.
Про самые частые причины, по которым пилоты не доходят до результата, мы писали отдельно в статье про ошибки внедрения AI в продажах.
Моя позиция: провал пилота закладывается до старта
Если свести всё сказанное к одной мысли, она будет такой: большинство пилотов проваливаются не в конце, а в первый день, когда никто не записал, что будет считаться успехом и когда остановиться. Всё остальное — последствия. Без метрики нельзя отличить провал от медленного прогресса, без условия остановки нельзя закрыть проект без обид, без базовой линии нельзя даже сказать, был ли эффект.
Поэтому моя ставка простая. Компании, которые научатся спокойно закрывать пилоты по заранее названному условию, будут внедрять ИИ быстрее тех, у кого каждый пилот обязан закончиться успехом. Первые за год успевают проверить несколько гипотез и оставить рабочие. Вторые годами тянут одну, потому что закрыть её — значит признать чью-то ошибку.
Так мы и строим работу в 404ai: цель и метрика согласуются до пилота, пилот идёт на данных клиента, и на каждом шаге у клиента есть право остановиться. Это не страховка от провалов — провалы бывают у всех. Это способ сделать так, чтобы провал стоил недели, а не года.
Что проверить у себя, если пилот уже закрыт
Главное следствие для читателя: закрытый пилот ещё можно превратить из потери в информацию, если сделать это в ближайшие недели, пока живы данные и люди помнят детали.
Проверка укладывается в три действия. Поднимите выгрузку пилота и разметьте выборку вручную — так вы узнаете, работала ли система. Посмотрите журнал действий пользователей — так вы узнаете, пользовались ли ею. Сравните целевую метрику с периодом до старта — так вы узнаете, была ли верна гипотеза. Первый ответ «нет» в этой цепочке и есть причина провала.
Если ответы сложились, запишите их на одну страницу и решите по ней, дорабатывать, переставлять или закрывать. Если выгрузки нет, журнала нет и метрику до старта никто не мерил — это тоже ответ, и довольно точный: следующий пилот нужно начинать не с выбора подрядчика, а с метрики и условия остановки.
