Зачем компании внедрять ИИ, если 90% проектов проваливаются в первый год

Откуда взялась страшная цифра в 90%

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

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

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

Иллюзия «умной магии»: когда ИИ внедряют ради ИИ

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

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

Самое неприятное последствие такого подхода — «усталость от ИИ» внутри организации. Команда, которая потратила полгода на красивый, но бесполезный проект, разочаровывается. Сотрудники, которых никто не спросил об их реальных проблемах, начинают относиться к новым инициативам со скепсисом. А бюджет, который можно было вложить в простую автоматизацию или обучение персонала, оказывается съеден демо-версиями, которые работают только на совещаниях.

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

Данные — это не техническая, а управленческая проблема

Когда ИИ-система начинает выдавать ерунду, первая реакция — «плохой алгоритм». Но опытный инженер первым делом идёт смотреть не модель, а данные. Потому что модель — это зеркало того, чему её учили. Если в данных хаос, модель будет хаотично предсказывать. А качество данных — это вопрос не столько к программистам, сколько к тому, как компания вообще живёт и работает.

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

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

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

Сотрудники, которых не спросили: почему люди саботируют систему

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

Самый частый страх, который коллектив не озвучивает вслух, — это страх оказаться ненужным. Когда в компании появляется ИИ, многие сотрудники сразу читают это как объявление: «Вас скоро заменят». Причём неважно, что говорит руководство на презентациях и какими словами прикрывается проект. Люди видят, что часть их рабочих задач передаётся машине, и делают простой вывод. Этот вывод может быть неверным, но он эмоциональный, а эмоции всегда сильнее любых разъяснений. Дальше сотрудник начинает вести себя так, как будто угроза уже реальна: перестаёт делиться знаниями с системой, избегает новых процессов, находит способы обойти инструмент. И делает он это не из вредности, а из самосохранения.

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

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

Руководство на дистанции: как топ-менеджмент хоронит проект за полгода

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

Этот паттерн настолько распространён, что аналитики называют его «пропастью разочарования» — стадией цикла хайпа, где раздутые ожидания сталкиваются с реальностью. Ошибка не в том, что руководство одобрило проект, а в том, что само одобрение было воспринято как главная работа. На деле ИИ-инициатива требует устойчивого внимания на уровне первых лиц компании на протяжении полутора-двух лет: перестроенных процессов, переобученных команд, изменённых метрик успеха. Когда генеральный директор уделяет теме пять минут в квартал и подписывает всё, что докладывает ИТ-директор, у проекта формально нет спонсора — есть только строчка в презентации для совета директоров.

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

Что делают иначе те 10% проектов, которые приживаются

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

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

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

Вопросы и ответы

Автор · Собственник

Владислав Острожинский

Хороший руководитель отвечает за результат, а не оправдывается процессом.

Профиль эксперта на ExpertRank →