Почему внедрение ИИ не оправдывает ожиданий: пять управленческих ошибок

В разговорах с руководителями я часто слышу одну и ту же жалобу, только в разных формулировках. Мол, компания внедряет ИИ-решения, а производительность не растет. Ручной работы меньше не становится. Согласования, подготовка документов, обработка запросов занимают столько же времени, сколько и до внедрения. Ощущение, что усилий и затрат много, а реальная польза скромнее обещаний.

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

Почему недостаточно – просто внедрить технологию

Публичных разборов реальных проектов по теме внедрения ИИ со стороны российского бизнеса пока немного – заметно больше подробной зарубежной аналитики. Я бы смотрел на это как на полезную фору. На рынках, где искусственный интеллект начали внедрять раньше, довольно ясно видна закономерность: узкие места находятся не в самой технологии, а в управлении, ролях, процессах и организационной дисциплине. Для российских компаний это возможность не повторять чужие дорогие ошибки, а учесть их заранее. Здесь ставки высоки, потому что ожидания сразу привязаны к производительности труда, снижению ручной нагрузки, ускорению цикла и качеству решений.

Главный разрыв возникает не в технологии, а между техническим запуском и реальным использованием в работе. Похожие сценарии уже случались. Компании покупали CRM, ERP, BI с понятной деловой логикой: навести порядок, ускорить процессы, снизить зависимость от ручного управления. Технически проекты часто делались добросовестно. Но способ работы людей не менялся, и система жила отдельно от реальной работы.

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

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

Внедрение новой технологии и управление изменениями – где связь?

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

Корень проблемы в том, что внедрение понимается как запуск новой технологии, а не как изменение способа работы. Есть понимание «что мы внедряем», но нет ответа на вопрос: «как после этого должна измениться реальная работа людей?».

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

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

Как управленцы проваливают проекты внедрения ИИ

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

1. AI встраивается в существующий процесс без его изменения

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

2. Руководители не делают нормой новый способ работы

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

3. Нет ясной бизнес-цели и критерия результата

«Мы внедряем AI для эффективности» – такая фраза никому в компании не объясняет, что и как конкретно должно измениться:

  • Время подготовки документа?
  • Скорость ответа клиенту?
  • Количество операций на одного сотрудника?
  • Качество планирования?
  • Точность прогноза?
  • Нагрузка на конкретную функцию?

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

4. Проблему сводят к обучению, но не меняют роли и правила

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

5. Считают, что после технического запуска «все произойдет само»

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

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

Что надо продумать до внедрения ИИ-проектов

Самая дорогая ошибка – начинать процесс, не договорившись о том, ради чего это запускается и как должна измениться работа компании. Эти вопросы полезно задать себе до того, как подписан договор с подрядчиком, и продолжать задавать после запуска.

1. С какой целью внедряем ИИ в бизнес?

Не чтобы «не отстать от рынка», а конкретный ожидаемый эффект:

  • Сократить время подготовки коммерческого предложения с трех дней до одного.
  • Снизить количество ручных операций при обработке заявок.
  • Ускорить ответ клиенту с 48 часов до 4.
  • Уменьшить время на формирование управленческой отчетности.
  • Сократить цикл согласования договора.

Чем конкретнее сформулирована цель, тем проще потом понять, сработало внедрение или нет.

2. Какой критерий результата?

Договориться не только о сроках и бюджете, но и о том, какой показатель должен измениться через три, шесть, 12 месяцев. Например:

  • Время обработки запроса сократилось на 40%.
  • Количество ручных операций в процессе уменьшилось вдвое.
  • Один сотрудник обрабатывает на 30% больше заявок без потери качества.
  • Точность прогноза продаж выросла с 60% до 85%.

Без таких критериев получается, что технически все работает, но непонятно, что конкретно изменилось.

3. Кто владелец бизнес-результата?

Не формальный руководитель IT-проекта, который координирует сроки и встречи с подрядчиком, а управленец, который отвечает за то, чтобы решение дало эффект в работе.

4. Какие процессы и роли затронет технология, как на них повлияет?

  • Какие шаги в процессе исчезнут, какие упростятся, где изменится логика принятия решений.
  • Кто будет делать меньше вручную, а где человеку придется не выполнять действие, а проверять и интерпретировать.
  • Какие новые ожидания появятся у руководителей.

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

5. Агенты изменений – кто они?

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

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

6. Как новую модель работы сделать устойчивой практикой?

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

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

Как сократить разрыв между внедрением технологии и результатом

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

Из этого следуют выводы:

  • Для руководителей. Покупать нужно не «AI как таковой», а увеличение производительности, снижение ручной нагрузки, ускорение процессов, более эффективное использование ресурсов. А значит, оценивать проект стоит не только по тому, состоялся ли технический запуск, но и по тому, изменился ли подход к работе.
  • Для интеграторов. Даже технически безупречный проект не создает ценности для клиента, если после запуска решением мало пользуются. Репутация, последующие продажи, долгосрочное партнерство – все это зависит не только от качества технологии, но и от того, получил ли клиент ощутимый результат.

Поэтому стоит разводить роли. Интегратор отвечает за технологическую часть: архитектуру, настройку, интеграцию, запуск. Компания отвечает за готовность менять собственный способ работы. Но между этими двумя зонами есть третья задача – провести внедрение как управляемое организационное изменение: определить бизнес-цель, владельца результата, затронутые процессы, роль руководителей, план реального использования и закрепления новой практики. Эта часть работы чаще всего выпадает, когда проект ведут только как IT-инициативу.

Также читайте:

Расскажите коллегам:
Комментарии
Николай Сибирев пишет:

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

Более того, важно посмотреть или проанализировать все не успешные проекты для внедрения IT решения, то это будет повторятся. 

Последнее время в нашей практике большинство проектов приходит, когда уже все сроки сгорели и надо делать уже вчера. Это конечно не очень нравиться нам, но сейчас такое время

Николай Сибирев пишет:

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

Более того, важно посмотреть или проанализировать все не успешные проекты для внедрения IT решения, то это будет повторятся. 

Последнее время в нашей практике большинство проектов приходит, когда уже все сроки сгорели и надо делать уже вчера. Это конечно не очень нравиться нам, но сейчас такое время

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

К сожалению, этот проект внедрения закончен только для поставщика технологии. А для компании потребителя он должен был только начаться - проект изменений, вызванных внедрением новой технологии.

Как правило, такие проекты успешны только при условии полного погружения в него совбственников и ТОПов компании, а это, к сожалению, большая редкость.

Как пример, компания, в одном из процессов, заменила старое универсальное оборудование на новое, более производительное оборудование с ПУ, но, в целом, производительность процесса не увеличилась, а эффективность даже снизилась.

Здравствуйте. Зацепилась за

"Разбирая такие ситуации, проблема обычно оказывается..."

То есть, получается, что проблема сама должна разобрать ситуации и где-то там оказаться?

Мне кажется (даже уверена), именно поэтому ИИ не оправдывает ожиданий.

Чтобы люди захотели меняться, они должны понять, что с ИИ им лучше, чем без него.

Вопрос в том, что дальше?

Вы отдаёте себе отчёт в том, что именно будет с людьми, как конкретными, так и в мировом масштабе, если они ПРИВЫКНУТ полагаться только на ИИ?

С уважением, Г. В. Кузнецова 

Будьте здоровы.

Ну, не знаю, дамы и господа, пока не знаю. Мне кажется, что повсеместное внедрение этого "дива дивного" носит явно преждевременный характер. Не скажу, что мой опыт взаимодействия с ИИ-системами так уж обширен, но вместо ожидаемого соприкосновения с каким-то всеобъемлющим неземным разумом, у меня неизменно получается общение с индивидом с легкой (а иногда не очень) степенью умственной отсталости. Из недавнего: при наборе некоторых номеров из контактов моего мобильного оператора неприятный женский голос начал отвечать мне, что я неправильно набрал номер.Но это был проверенный годами контакт со стандартным набором цифр, номер был набран абсолютно правильно, и я решил разобраться в ситуации с оператором. Естественно, первое, с чем я столкнулся на этом пути - это был чат с ИИ. Усомнившись, что он поймет ситуацию правильно, я сразу предложил пригласить живого оператора. Но ИИ самонадеянно отказался. Дальнейшие полчаса прошли в весьма эмоциональном общении с этим представителем неземного разума, который упорно не соглашался приглашать своего живого собрата, мне же неизменно отвечал, что не понял моей просьбы и просил повторить ее снова. Наконец-то, когда я использовал весь запас нецензурного русского, мне удалось (о,чудо!) прорваться к оператору. И первое, о чём я ему сообщил - это о невыносимости общения с его искусственным собратом и о том, что получить от него визу на общение с живым сотрудником было более чем проблематично. "А вы в следующий раз скажите, что потеряли сим-карту" - посоветовал земной разум. "Что? Но я не терял никакую сим - карту!" - я был несколько удивлен неординарностью этого совета. "А вы скажите, что потеряли. И тогда он сразу соединит вас со мной"  Дальнейшее общение с уже живым собратом искуссвенного разумом описывать не буду, оно не столь существенно. Что же касается особенностей внедрения систем ИИ в рабочую повседневность крупных (и не очень) компаний, то пример, как по мне, достаточно красноречив. Мне, во всяком случае, многое стало понятно...))

В статье хорошо описаны проблемы, и выводы сделаны правильно. Только это 1 % проблем внедрения ИИ в бизнес‑процессы. И тут нужна не одна статья, а серия статей.

Мы разрабатываем решения на базе ИИ для бизнеса и каждый день на практике, как сейчас модно говорить, «на земле», сталкиваемся с полным непониманием: что такое ИИ, как он работает, что он может и как его внедрить эффективно?

Самый простой пример: возьмём любую отрасль, к примеру медицину. Так вот, только здесь можно применить ИИ более чем в 10 направлениях. Тут, может быть, и BI‑аналитика, и автоматизация записи на приём, и постановка диагноза, и ведение документации, и закупка расходных материалов… И эту работу выполняет не одна модель, а разные модели, использующие разные технологии с разными настройками.

А посмотрите на банковский сектор, логистику, торговлю - везде своя специфика, свои цели, и везде работают разные модели. Но если даже взять одну из бизнес‑функций: финансы, маркетинг, HR - мы увидим, что там огромный разброс по моделям и алгоритмам.

И тут встаёт вопрос: кто из собственников или ТОРов может сделать грамотное ТЗ?

В итоге, прежде чем править работающие бизнес‑процессы под ИИ, необходимо:

  • провести глубокий анализ своего бизнеса (понять, где и что можно оптимизировать с помощью ИИ);
  • найти грамотных интеграторов (имеющих большую насмотренность, понимающих бизнес‑процессы и работающих с разными моделями);
  • создать для них грамотное ТЗ;
  • протестировать прототип на тест‑группе;
  • внести изменения.

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

Владимир Мухин пишет:
И тут встаёт вопрос: кто из собственников или ТОРов может сделать грамотное ТЗ?

А зачем собственникам делать грамотное ТЗ по автоматизации? Им достаточно понимать, что входит в периметр решаемых задач, а также каким должен быть целевой результат.

ТЗ на автоматизацию - результат этапа организационной диагностики и инжиниринга процессов (to-be), и копаться в деталях протоколов ни один собственник может не захотеть. Достаточно просто это отдается на аутсорс.

Николай Сибирев пишет:
Продолжение вашей мысли, можно составить чек-лист для контроля или оценки перспективности автоматизация, просто этим никто не заморачиваться. 

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

 

 

Николай Сычев пишет:
Конечно нужно, но вот только часто ли такое заказывают?

Реже, чем стоило бы. Чаще хотят сразу переходить к выбору решения и запуску, а не тратить время на орг.диагностику

Дмитрий Нор пишет:
Последнее время в нашей практике большинство проектов приходит, когда уже все сроки сгорели и надо делать уже вчера. Это конечно не очень нравиться нам, но сейчас такое время

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

Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии