Ошибки внедрения ИИ в бизнесе: почему проект не доходит до результата

Ошибка 1. Начали с витрины вместо узкого места

Самый частый сценарий: компания выбирает для первого ИИ-проекта то, что красиво выглядит и хорошо звучит на совещании. Чат-бот на сайте, генератор постов, «умный» виджет. Всё это работает — и почти ничего не меняет в деньгах, потому что узкое место компании находилось в другом месте.

Признаки того, что вы выбираете витрину, а не узкое место:

• задачу сформулировали через инструмент («нужен бот»), а не через проблему («заявки лежат по два часа»);
• инициатива пришла из маркетинга «чтобы было современно», а не от того, кто страдает от процесса;
• на вопрос «сколько это стоит нам сейчас в часах и деньгах» никто не может ответить;
• процесс, который автоматизируем, происходит редко.

Проверка простая: выпишите три процесса, которые съедают больше всего человеко-часов в неделю, и три, где чаще всего теряются деньги. Если ваш будущий проект не попал ни в один список — вы делаете витрину. Метод отбора подробно разобран в статье как внедрить ИИ в бизнес без хаоса.

Ошибка 2. Нет владельца процесса

Вторая по частоте и первая по разрушительности. У проекта есть заказчик (собственник), есть исполнитель (подрядчик) — и нет человека внутри компании, который отвечает за то, чтобы решением пользовались.

Что происходит без владельца:

• некому собрать материалы и ответить на вопросы аналитика — сроки растут;
• некому проверить работу на реальных кейсах — приёмка формальная;
• некому объяснить команде, зачем это и как пользоваться — люди возвращаются к старому способу;
• никто не читает реальные диалоги и не правит сценарии — качество тихо деградирует;
• через три месяца никто не может сказать, работает решение или нет.

Владелец — не технический специалист. Это человек, который знает процесс, имеет полномочия менять регламент и заинтересован в результате. У него должно быть выделенное время: несколько часов в неделю на старте, меньше — потом. Если такого времени нет ни у кого, проект лучше отложить, чем запускать.

Ошибка 3. Нет метрики «до»

Проект запустили, всем нравится, «стало удобнее». Через полгода собственник спрашивает: на сколько? И выясняется, что цифры «до» никто не зафиксировал — а по памяти каждый помнит по-своему.

Метрика «до» снимается за один-два дня и должна включать минимум:

Без этой таблицы разговор об окупаемости невозможен — вы не сможете ни доказать успех, ни честно признать неудачу. И то и другое одинаково вредно: непризнанная неудача продолжает тратить бюджет на поддержку.

Ошибка 4. ИИ поверх сломанного процесса

Автоматизация не чинит процесс — она его ускоряет. Если в компании нет правил обработки заявок, ИИ-агент будет быстрее доставлять заявки туда, где их и раньше теряли. Если данные в CRM неполные, скоринг на них будет уверенно выдавать бессмысленные приоритеты.

Признаки, что процесс не готов к автоматизации:

• на вопрос «как это происходит сейчас» два сотрудника отвечают по-разному;
• нет письменного регламента или он не совпадает с реальностью;
• ключевые данные живут в головах, а не в системе;
• результат процесса зависит от того, кто конкретно его делает;
• исключения из правил встречаются чаще, чем сами правила.

Хорошая новость: описание процесса на этапе аналитики часто само по себе даёт эффект — компания впервые видит, как её работа устроена на самом деле. Плохая: этот этап нельзя пропустить, а пытаются пропустить его почти всегда.

Ошибка 5. Ожидание автономности

«Внедрили и забыли» — самое дорогое заблуждение. Решения на языковых моделях не статичны: меняется прайс, появляются новые типы обращений, клиенты начинают спрашивать иначе, обновляются регламенты. Без регулярного пересмотра решение медленно расходится с реальностью — и, что коварно, продолжает при этом уверенно работать.

Что должно происходить регулярно:

• выборочный просмотр реальных диалогов и результатов — еженедельно на старте;
• обновление базы знаний при любом изменении в прайсе, услугах, регламентах;
• проверка отсева: не режет ли система нормальные обращения;
• сверка метрик с зафиксированным «до»;
• сбор новых сценариев, которых не было в исходном ТЗ.

Отдельная форма этой же ошибки — ожидание, что ИИ будет принимать решения. Он готовит, сортирует, черновит и подсказывает. Решение и ответственность остаются на человеке, и это не временное ограничение технологии, а осознанная граница проектирования. Подробнее о том, где эта граница проходит в продажах — в разборе что из ИИ реально работает в отделе продаж.

Чек-лист перед стартом проекта

Пройдите по пунктам честно. Каждое «нет» — это отложенный риск, а не мелочь.

1. Процесс выбран по объёму потерь, а не по эффектности. Да / нет
2. Назван конкретный владелец процесса с выделенным временем. Да / нет
3. Метрика «до» зафиксирована письменно. Да / нет
4. Процесс описан, и описание совпадает у разных сотрудников. Да / нет
5. Заранее определено, что считаем провалом и когда останавливаемся. Да / нет
6. В бюджет заложены ежемесячные расходы, а не только разработка. Да / нет
7. Понятно, кто и как часто будет читать реальные диалоги. Да / нет
8. Команде объяснили, зачем это и что меняется в их работе. Да / нет

Проекты по ИИ проваливаются не там, где не хватило технологии, а там, где не нашлось человека, которому это нужно. — команда Aivonix

Если чек-лист пройден — переходите к оценке бюджета: из чего складывается смета внедрения. Если хочется сначала увидеть последовательность шагов целиком, она разобрана в материале пошаговый план внедрения ИИ.

Частые вопросы

Почему большинство ИИ-проектов не доходит до результата?

Причины почти всегда управленческие, а не технические: выбрали эффектную задачу вместо узкого места, не назначили владельца процесса, не зафиксировали метрику «до», автоматизировали неописанный процесс или ждали, что решение будет работать само.

Кто такой владелец процесса и обязателен ли он?

Это сотрудник компании, который знает процесс, имеет полномочия менять регламент и заинтересован в результате. Он собирает материалы, проверяет работу на реальных кейсах и регулярно читает диалоги. Без такого человека проект формально сдаётся и перестаёт использоваться.

Что такое метрика «до» и как её снять?

Это зафиксированные до старта цифры: время цикла процесса, человеко-часы в неделю, объём операций в месяц, доля ошибок и потери на выходе. Снимается за один-два дня по выборке из 20–30 реальных случаев.

Можно ли автоматизировать процесс, который не описан?

Технически можно, но результат будет непредсказуемым. Автоматизация не чинит процесс, а ускоряет его — включая ошибки. Проверка готовности: попросите двух сотрудников независимо описать процесс; расхождение означает, что сначала нужен порядок.

Нужно ли поддерживать решение после запуска?

Да. Меняются прайс, услуги, формулировки клиентов и регламенты — без регулярного пересмотра решение расходится с реальностью, продолжая при этом уверенно работать. Просмотр реальных диалогов и обновление базы знаний обязательны.