У неудачного AI-проекта редко бывает драматичный финал. Обычно всё выглядит благополучно: решение сдано, демонстрация прошла, команда поблагодарила. Потом наступает обычная рабочая неделя, и оказывается, что старый способ быстрее — не объективно, а для конкретного человека в конкретный вторник. Через месяц решением пользуются двое, через три — никто.
1. У процесса нет владельца
Самая частая и самая недооценённая причина. Владелец — это не спонсор проекта и не тот, кто подписал бюджет. Это человек, который отвечает за результат процесса и имеет право менять то, как люди в нём работают.
Без такого человека внедрение упирается в согласования на каждом шаге. Решение технически готово, но чтобы им пользовались, нужно изменить регламент, а менять его некому. Проект зависает в состоянии «работает, но не используется» — самом дорогом из возможных, потому что деньги потрачены, а эффекта нет.
Проверка до старта: попросите назвать человека, который через полгода будет отвечать на вопрос «почему метрика такая». Если названы двое или ответ звучит как название отдела, владельца нет.
2. Не с чем сравнивать
Пилот без зафиксированного исходного состояния не может ни подтвердиться, ни опровергнуться. Разговор о его судьбе превращается в обмен впечатлениями, а в таком разговоре выигрывает не тот, кто прав, а тот, кто увереннее.
Отдельная ловушка — менять определение метрики по ходу. Если в начале считали «долю разобранных звонков», а к финалу считаете «долю звонков, по которым система что-то выдала», это уже другая величина, и сравнение бессмысленно.
3. Не определён критерий остановки
Пилот без критерия остановки не заканчивается — он продлевается. Каждое продление выглядит разумным: ещё две недели, ещё один набор данных, ещё одна итерация промпта. Проблема в том, что решение о продолжении принимается тем же человеком, который в него уже вложился, и на каждом шаге отказаться дороже, чем на предыдущем.
Критерий остановки должен быть числом и датой, записанными до начала. Не «если не получится» — а «если к такому-то числу величина не достигла такого-то значения на таком-то объёме, работу прекращаем».
Остановленная вовремя слабая инициатива — это сэкономленный бюджет следующей. Растянутая — это две неудачи вместо одной.
4. Adoption считали делом второго порядка
Инструмент, который контролирует человека, но ничего ему не даёт, не приживается. Это не вопрос мотивации и не решается обучением: сотрудник рационально выбирает способ работы, при котором его результат выше, а риск ниже.
У решения должна быть польза для того, кто им пользуется, а не только для того, кто на него смотрит
Индивидуальные оценки на старте лучше не показывать: пока критерии не откалиброваны, они вызывают сопротивление и обесценивают систему
Первые недели разбирать спорные случаи вместе с людьми, а не присылать им результат
Метрика adoption должна быть в проекте с самого начала — иначе о ней вспоминают, когда исправлять поздно
5. «Готово» означало не то
Если готовность определяется как «код работает», проект закончится ровно там. Рабочее определение другое, и его стоит согласовать до начала — тогда никто не удивится объёму работ на последнем этапе.
| «Готово» в проекте | «Готово» в процессе |
|---|---|
| Решение работает на тестовых данных | Решение встроено в ежедневный маршрут работы |
| Прошла демонстрация | Люди пользуются без напоминаний |
| Код передан | Определён владелец на стороне клиента |
| Есть документация | Есть мониторинг качества и стоимости |
| Задача закрыта | Эффект измерен на сопоставимом периоде |
Что проверить до старта
- 1
Кто владелец процесса и может ли он менять регламент
- 2
Какие величины зафиксированы как baseline и из какого источника
- 3
Какое значение и к какой дате считается подтверждением гипотезы
- 4
При каком значении работа прекращается
- 5
Что получает от решения человек, который будет им пользоваться
- 6
Кто разбирает исключения и сколько времени это займёт в неделю
Ни один из этих вопросов не про технологию, и все шесть решаются до того, как начата разработка. Это и есть та часть работы, которую проще всего пропустить и дороже всего пропускать.
Aplora Sales
Превращает звонки, CRM и вашу методологию продаж в систему управленческих действий.Подробнее о решенииСвязанный кейсРазбор консультационных звонков в приёмной кампании: как мы проверили систему на себе
Разобрать кейсРазборы методологии — на почту
Присылаем то же, что публикуем здесь: как считать экономику инициативы, где ломаются внедрения и что проверять до начала работ. Не чаще раза в месяц, без новостей рынка и без продающих писем.
