Пилот провалился. Что делать дальше
Статистика говорит, что это самый вероятный исход: до продакшена доходит около одного пилота из девяти. Разбираем, как извлечь из неудачи пользу вместо вывода «ИИ не работает».
Сначала отделить одно от другого
«Не сработало» означает три разные вещи, и дальнейшие действия у них противоположные:
| Тип | Признак | Что делать |
|---|---|---|
| Провал исполнения | Задача была верная, сделали плохо | Повторить с другим подходом |
| Провал гипотезы | Процесс в принципе не годился | ✓ Не повторять, взять другой |
| Провал замера | Эффект был, доказать нечем | Повторить с нормальной метрикой |
Третий случай встречается чаще, чем кажется. Если значение «до» никто не зафиксировал, проект считается неудачным независимо от того, что происходило на самом деле.
Пять вопросов к прошлому проекту
- Была ли метрика, записанная числом, и знали ли вы её значение до старта?
- Был ли у процесса владелец внутри компании, который тратил на пилот время?
- Смотрел ли кто-нибудь на реальные данные, а не на схему?
- Пилот покрывал один процесс или пытался охватить всё сразу?
- Было ли заранее решено, при каком результате проект закрывается?
Если «нет» хотя бы на три из пяти — это был провал исполнения, и технология тут ни при чём. Развёрнутый разбор причин — в отдельной статье.
Что забрать из неудачного проекта
Неудачный пилот — дорогой, но настоящий источник знаний о вашей компании:
- Теперь вы знаете фактическое состояние своих данных, а не предполагаемое
- Выяснилось, какие правила нигде не записаны — их выявили в процессе
- Понятно, сколько времени у вас занимают согласования и выдача доступов
- Видно, кто внутри готов участвовать, а кто только числится
Второй заход с этими знаниями проходит заметно быстрее и дешевле первого — при условии, что их зафиксировали, а не забыли вместе с проектом.
Менять ли подрядчика
Вопрос не в подрядчике, а в том, изменились ли условия. Если метрики по-прежнему нет и владельца процесса нет, результат повторится с любым исполнителем — просто за ваш счёт ещё раз.
Менять имеет смысл, если выяснилось, что подрядчик не задавал вопросов про данные, обещал сроки, которые не выдержал, или не мог внятно объяснить, что именно пошло не так. Критерии выбора — в разборе из девяти вопросов.
Когда правильный ответ — не повторять
Если при разборе выясняется, что объём операций небольшой, процесс меняется каждый квартал, а данных в системе нет — второй заход закончится так же. Честный вывод здесь: не автоматизировать, а заняться процессом.
Это не поражение. Это экономия следующего бюджета.
Частые вопросы
Значит ли неудача, что ИИ нам не подходит?
Чаще значит, что не подошёл конкретный процесс или подход. Исследования называют главными причинами отсутствие метрики, неготовые данные и отсутствие владельца — всё это исправимо.
Сколько ждать перед вторым заходом?
Столько, сколько нужно, чтобы закрыть выявленные пробелы. Если дело было в данных — пока не наведён порядок. Календарных правил тут нет.
Можно ли использовать наработки прошлого проекта?
Если у вас остались техзадание, описанные правила и доступы — да, и это заметно сокращает второй заход. Поэтому права на результат стоит фиксировать в договоре заранее.
Вы беретесь за повторные проекты?
Да, и они часто идут лучше первых: заказчик уже знает свои слабые места и не питает иллюзий. На аудите разбираем, что именно не сработало.
Разберём, что пошло не так
На аудите смотрим прошлый проект, данные и метрику. Если второй заход повторит первый — скажем об этом сразу.
Оставить заявку