Внедрение ИИ: как преодолеть скрытое сопротивление команд и перестроить бизнес-процессы

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

Партнёр практики «Операционная эффективность» Strategy Partners Денис Тверской проанализировал ключевые проблемы российских компаний при внедрении технологий. Опыт показывает, что большинство ИИ-инициатив спотыкаются не о технические барьеры, а о человеческий фактор и устаревшие управленческие привычки.

Содержание:

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

Почему ИИ-проекты не дают ожидаемого эффекта

Статистика отражает двойственную картину. Технологии искусственного интеллекта активно осваиваются: по данным Strategy Partners, 95% крупных компаний из сферы промышленности и электронной коммерции вовлечены во внедрение генеративного ИИ. При этом всего 10–15% достигли промышленной эксплуатации.

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

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

В своей практике я регулярно наблюдаю, как скрытый человеческий фактор разрушает ИИ-проекты изнутри.

Данные в системе есть, но работать с ними нельзя

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

Ключевые показатели эффективности (KPI) противоречат внедрению технологии

Похожая картина возникает, когда бизнес пытается внедрить автоматический контроль качества. По регламенту при подозрении на дефект оператор обязан остановить линию, зафиксировать отклонение и дождаться решения технолога. Однако KPI (от англ. key performance indicator — «ключевые показатели эффективности») начальника смены и премия самих операторов по-прежнему зависят от объёма выпуска. Возникает конфликт: управленческое решение требует остановить производство, а система мотивации вознаграждает непрерывную работу. В итоге дефекты оформляются постфактум или переводятся в менее критичные категории, а через пару месяцев руководство объявляет ИИ-систему неэффективной.

Сотрудники формально принимают систему, но саботируют процесс

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

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

От пилота к рабочему процессу: что нужно перестроить

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

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

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

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

Почему успешные пилоты не масштабируются: два кейса из практики

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

Агропромышленный комплекс

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

• рекомендации ИИ не внесли в график технического обслуживания и ремонта (ТОиР);
• порядок формирования заявок оставили старым;
• систему не связали с KPI ремонтной службы;
• мастеров не обучили интерпретировать предупреждения;
• ответственность за реакцию на сигналы ни за кем не закрепили.

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

Финансовый сектор

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

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

Кто определяет результат внедрения

Чтобы ИИ стал частью ежедневной работы, недостаточно решить задачу на уровне ИТ-департамента. В процессе изменении всегда задействованы три уровня организации.

1. Топ-менеджмент принимает стратегическое решение и определяет ожидаемый бизнес-эффект.
2. Средний менеджмент выступает проводником изменений: переводит стратегию в конкретные регламенты и перестраивает работу команд.
3. Линейные сотрудники непосредственно применяют инструмент в своей повседневной практике.

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

Если не учитывать этот разрыв в восприятии, проект неизбежно столкнётся со скрытым сопротивлением.

Три уровня принятия изменений

Согласно классической модели управления изменениями Курта Левина, процесс трансформации состоит из трёх этапов: подготовки к изменениям («разморозки»), реализации («движения») и закрепления нового состояния («заморозки»).

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

Какая аргументация нужна каждому уровню?

Топ-менеджмент: экономика и управляемость

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

Язык аргументации: финансово-экономические модели, расчёт ROI (от англ. return on investment — «возврат инвестиций»), отраслевые бенчмарки, системы управления рисками и бизнес-кейсы.

Средний менеджмент: реализуемость и ответственность

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

Язык аргументации. Руководителю бизнес-функции нужно показать:

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

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

Линейные сотрудники: роль и безопасность

Для линейного персонала ИИ выглядит ещё конкретнее: это новая программа, необходимость переучиваться и менять привычный порядок действий параллельно с основной работой.

Язык аргументации. Важно ответить сотруднику на вопрос, что изменится лично для него. Нужно заранее объяснить:

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

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

Средний менеджмент — связующее звено между стратегией и практикой

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

Кейс из практики: внедрение ИИ в клиентском сервисе

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

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

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

Что изменило ситуацию? Проект перезапустили, проведя адресную «разморозку» для каждого уровня:

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

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

Пять шагов, которые помогают преодолеть сопротивление

Как перевести эти принципы в практическую плоскость? Рассмотрим пошаговый управленческий алгоритм на примере страховой компании, которая внедряет ИИ для первичной оценки страховых случаев.

1. Объяснить цели и границы изменений. На каждом уровне нужно чётко обозначить цель проекта и определить, какие процессы останутся неизменными.
   
   Пример. Сотрудникам отдела автострахования честно показывают проблему: большие затраты времени на ручную проверку документов создают очередь. ИИ будет выполнять первичную сверку бумаг, но итоговое решение о выплате останется строго за экспертом.
2. Выявить участников и точки скрытого саботажа. Важно заранее определить неформальных лидеров, сторонников проекта и тех, кто может тормозить внедрение.
   
   Пример. Специалисты по урегулированию убытков опасаются сокращений и завышения норм. Руководство фиксирует цель проекта — снять рутину, а не сократить штат; сохраняет KPI на переходный период и привлекает опытных сотрудников к настройке системы.
3. Обучить сотрудников новым ролям на конкретных рабочих сценариях. Обучающая программа должна быть привязана не к возможностям технологии вообще, а к ежедневным действиям сотрудников.
   
   Пример. Вместо абстрактной лекции про ИИ специалисты отрабатывают понятный алгоритм: загрузить заявление и фото, затем проверить найденные несоответствия, после принять или отклонить рекомендацию ИИ и наконец передать сложный кейс эксперту.
4. Показать «быстрые победы». Первые позитивные результаты помогают снизить скепсис и показать практическую пользу нового инструмента.
   
   Пример. Первые две недели специалисты по урегулированию убытков работают в паре с наставниками: вместе разбирают дела, проверяют рекомендации ИИ, исправляют ошибки системы. Это помогает понять возможности и ограничения алгоритмов и быстро сформировать устойчивый навык.
5. Закрепить новый порядок работы. После пилота изменения нужно официально интегрировать в регламенты, стандарты и KPI.
   
   Пример. В регламент страховой компании вносят правило: все стандартные заявления обязаны проходить первичный анализ ИИ, а руководитель еженедельно отслеживает сроки и долю возвратов на ручную проверку. Параллельный старый процесс постепенно закрывается.

Вместо заключения: системная работа с изменениями

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

Управление изменениями стоит выстраивать в три непрерывных этапа:

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

Тогда технологии начнут приносить реальный бизнес-эффект, а не просто пополнят список купленных софтверных лицензий.

• Чтобы быть в курсе важных трендов и мнений ведущих экспертов, следите за нами в канале в Max. О развитии навыков управления, личностном росте пишем в «Дзене». Про технологии и развитие в IT — в блоге на VC.