Всем привет. В этом материале я хочу разобрать, с чем сталкиваются средние и крупные компании при внедрении ИИ, почему одни и те же инструменты дают совершенно разные результаты и какие управленческие ошибки обходятся бизнесу дороже самой технологии.
Представьте ситуацию: компания купила корпоративные подписки, провела обучение, запустила несколько пилотов. Маркетинг быстрее пишет тексты, сотрудники собирают презентации, IT показывает работающего ассистента. На очередной встрече собственник задаёт вполне логичный вопрос: что изменилось в выручке, расходах, скорости обслуживания клиентов? И выясняется, что ответить на него намного сложнее, чем показать очередное демо.
Это условный пример. Между личной продуктивностью сотрудника и финансовым результатом компании есть несколько этапов, которые нельзя пропустить. Нужно выбрать правильную задачу, обеспечить доступ к данным, перестроить рабочий процесс и договориться, кто отвечает за результат.
Опыт работы CDO научил меня смотреть прежде всего на принципы принятия решений, интересы руководителей и способность команды доводить планы до исполнения. С ИИ эти вопросы стали ещё острее: теперь красивый прототип можно получить очень быстро, а организационные ограничения компании остаются прежними.
Что на самом деле происходит на рынке
Я бы разделил происходящее на три уровня. На первом сотрудник пробует ИИ в отдельных задачах: пишет письмо, собирает информацию, готовит черновик презентации. На втором инструмент становится частью регулярного процесса, которым пользуется команда. На третьем компания получает измеримое изменение в экономике: растёт маржа, снижаются расходы, появляется возможность обслуживать больший объём клиентов.
Главная ошибка — считать эти уровни одним и тем же внедрением. Сотрудники могут активно пользоваться ИИ, а компания при этом продолжает работать по прежним правилам. Менеджер быстрее готовит предложение, но клиент всё так же ждёт согласования. Аналитик быстрее собирает отчёт, но руководители принимают решения с прежней скоростью. Локальные улучшения есть, а ограничение бизнеса остаётся на месте.
Отсюда и разочарование. Собственник рассчитывает на рост эффективности всей компании, а получает набор отдельных удобств. Подрядчик показывает работающую технологию, но не отвечает за то, как она встроится в ежедневную работу. Команда довольна инструментом, но никто заранее не договорился, в каком показателе должен проявиться результат.
При этом возможности ИИ вполне реальные — дальше я разберу российские примеры, где эффект связан с основными процессами бизнеса. Вопрос в том, как пройти путь от полезного инструмента до устойчивого результата. Для этого придётся управлять приоритетами, ресурсами и изменениями внутри компании. Именно здесь заканчивается простота красивого демо.
Ошибка №1. Начинать с инструмента, когда проблема бизнеса ещё не определена
«Нам нужен корпоративный чат-бот». «Давайте сделаем AI-агента». «У конкурента уже есть, а мы отстаём». Формально это запросы на внедрение. Но в них пока нет самого главного: какое ограничение компании мы собираемся снять и почему выбранный инструмент способен это сделать.
Допустим, коммерческие предложения готовятся три дня. Можно поручить ИИ писать их текст за десять минут. А потом выяснить, что два с половиной дня менеджер ждёт расчёт себестоимости, остатки на складе и согласование индивидуальной скидки. Письмо теперь пишется быстрее, но клиент получает ответ почти в тот же срок. Это условный пример того, как легко улучшить отдельную операцию, не повлияв на весь процесс.
Я бы начинал с разбора пути от запроса клиента до результата. Где возникают ожидания? Где сотрудники повторно вводят данные? Какие ошибки приходится исправлять? Где компания теряет заказ, маржу или рабочее время? Иногда ответом окажется ИИ, иногда — обычная интеграция систем, изменение регламента или отказ от лишнего согласования.
Разница между технологиями тоже имеет значение. Прогноз спроса, распознавание дефектов, поиск по документам и подготовка текста требуют разных решений. Большая языковая модель не должна становиться обязательным ответом на любую задачу только потому, что именно о ней сейчас чаще говорят.
Для каждой инициативы я рекомендую сначала сформулировать короткую гипотезу: какой показатель меняем, с какого значения, за счёт какого изменения и кто будет пользоваться результатом. После этого уже можно обсуждать архитектуру и поставщиков. Если гипотезу невозможно объяснить без названия конкретной модели, задачу стоит разобрать ещё раз.
Ошибка №2. Поручить внедрение IT и ждать, что бизнес изменится сам
Техническая команда может настроить интеграцию, обеспечить доступность сервиса и безопасность данных. Но она не может самостоятельно решить, какие этапы продажи теперь отменяются, кому разрешено согласовывать исключения и как меняется мотивация коммерческого директора.
Здесь возникает размывание ответственности. IT отвечает за то, чтобы система работала. Подрядчик — за выполнение технического задания. HR — за количество обученных сотрудников. Руководитель функции продолжает работать по старым KPI. А экономический результат от внедрения как будто должен возникнуть между всеми этими зонами.
Поэтому у инициативы должен быть владелец со стороны бизнеса, у которого есть и нужная метрика, и полномочия менять процесс. У программы в целом — руководитель, который связывает приоритеты подразделений, бюджет, данные и требования к качеству. И обязательно нужен спонсор на уровне CEO или собственника, способный разрешать конфликты интересов.
Название должности здесь вторично. В одной компании это CDO, в другой — руководитель AI-направления, в третьей — директор по трансформации. Но если человек может только предлагать идеи, а ресурсы и приоритеты каждый раз согласовывает заново, управлять внедрением ему будет очень сложно.
При этом участие собственника не означает, что ему нужно лично выбирать модели и обсуждать каждый промпт. Его задача — задать цель, поддержать необходимые изменения и регулярно проверять результат. Иначе ИИ рискует остаться инициативой нескольких энтузиастов, которую остальные подразделения воспринимают как дополнительную нагрузку.
Ошибка №3. Считать, что компания уже готова к ИИ, потому что у неё много данных
Данных может быть много, а пригодного для работы контекста — мало. В CRM один статус клиента, в учётной системе другой, в договоре третье условие. Утверждённый регламент лежит рядом с устаревшей версией. Часть важных правил сотрудники вообще передают устно.
Обычный сотрудник часто умеет обходить эту неопределённость: знает, кому позвонить, какой файл считать актуальным и когда лучше перепроверить цифру. Системе эти правила нужно задать. Если просто подключить модель ко всему корпоративному архиву, противоречия никуда не исчезнут.
Даже поиск с опорой на внутреннюю базу знаний не даёт автоматической гарантии достоверности. Нужно определить, какие источники считаются действующими, кто их обновляет, какие права доступа действуют и как проверяется ответ. Для разных задач критерии тоже будут разными: найти пункт договора и корректно рассчитать сумму к оплате — далеко не одно и то же.
Я бы проверял готовность данных на конкретном процессе. Можно ли собрать информацию для реального рабочего решения? Есть ли ответственный за её качество? Увидит ли менеджер только документы, к которым ему положен доступ? Что произойдёт, если в источниках есть расхождение?
При этом ожидание «сначала полностью наведём порядок во всех данных компании» тоже способно остановить работу на годы. Практичнее выбрать ограниченный сценарий, привести в порядок нужный для него участок и проверить пользу. Так становится понятно, какие вложения в данные оправданы следующим этапом.
Ошибка №4. Приравнять сэкономленное время к деньгам в P&L
Это, на мой взгляд, одна из самых дорогих ошибок. Сотрудник говорит, что теперь тратит на задачу на час меньше. Час умножают на стоимость его рабочего времени, затем на количество сотрудников и рабочих дней. Получается впечатляющая годовая «экономия». Но фонд оплаты труда остался прежним, дополнительных заказов компания не получила, расходы на подрядчиков не сократились.
Высвобождение времени может быть очень полезным результатом. Компания получает возможность обслужить больше клиентов, уменьшить очередь, быстрее запустить продукт или обойтись без дополнительного найма при росте нагрузки. Однако для каждого из этих вариантов нужен отдельный механизм превращения производительности в экономический эффект.
Условный расчёт: почему хороший пилот может не окупиться
Предположим, в компании 100 специалистов. Измерение показало, что каждый высвобождает 30 минут в день. При 20 рабочих днях это 1 000 часов в месяц. Внутреннюю стоимость часа для расчёта примем равной 1 000 рублей. Потенциал высвобождённой мощности — 1 млн рублей в месяц. Пока это оценка ресурса, а не снижение расходов.
Дальше проверяем, какая часть ресурса действительно превращается в финансовый результат. Допустим, подтверждённое сокращение расходов на внешних исполнителей и сверхурочную работу составляет 400 тыс. рублей в месяц. Работа сервиса, сопровождение и контроль качества стоят 250 тыс. рублей в месяц. Разовые вложения в запуск — 2 млн рублей.
При таких допущениях чистый ежемесячный эффект составит 150 тыс. рублей. Простой срок окупаемости разовых вложений после выхода на этот режим — около 13,3 месяца. Если устойчивый режим будет достигнут позднее, календарный срок от старта окажется больше. В расчёте пока нет дисконтирования и налоговых различий: это иллюстрация логики, а не финансовый прогноз.
Теперь меняем одно предположение. Если удаётся подтвердить только 200 тыс. рублей сокращения расходов при тех же 250 тыс. рублей затрат, решение даёт минус 50 тыс. рублей в месяц. Те же сотрудники, та же модель, те же красивые отзывы о скорости — и совершенно другая экономика.
Поэтому эффект полезно раскладывать отдельно: реально сокращённые расходы; дополнительная маржинальная прибыль; высвобождённая мощность; качество и снижение риска. Предотвращённый будущий найм тоже требует подтверждённого плана нагрузки. А время, уже учтённое в сокращении расходов, нельзя второй раз включать в расчёт как дополнительную выгоду.
В полную стоимость решения входят подготовка данных, интеграции, лицензии или вычисления, работа внутренних специалистов, проверка результатов, исправление ошибок и поддержка после запуска. Чем больше объём использования, тем важнее считать стоимость одной завершённой задачи. Дешёвый доступ к модели ещё ничего не говорит о стоимости рабочего процесса целиком.
Почему одинаковый ИИ по-разному помогает разным сотрудникам
Разберём условный пример. Новому менеджеру ассистент может помочь быстрее разобраться в продукте, найти нужный регламент и подготовить ответ клиенту. Опытный специалист уже знает всё это и, возможно, потратит больше времени на проверку предложенного текста, чем на собственный ответ. Инструмент один, но задачи и ценность помощи у этих людей разные.
То же касается характера работы. Подготовить первый черновик, разобраться в незнакомой теме и принять решение в сложной ситуации — разные задачи. В одной достаточно проверить структуру и поправить формулировки. В другой ошибка обнаружится только после внимательного разбора документов. Поэтому я бы не закладывал одинаковое ускорение для всех сотрудников и процессов.
Впечатления сотрудников, количество сгенерированного текста или скорость написания первого варианта могут расходиться с итоговым результатом. Нужно измерять весь цикл: подготовку, проверку, исправления, согласование и передачу следующему участнику процесса. И смотреть результаты отдельно по типам задач и уровню опыта людей.
Ошибка №5. Обучить людей и оставить им прежний порядок работы
Обучение нужно. Но сотрудник после курса возвращается в систему, где у него прежняя загрузка, прежний руководитель и прежний способ оценки результата. Если новый инструмент добавляет ещё один этап, а старые действия обязательны, человек получает две параллельные работы.
Поэтому я разделяю обучение инструменту и изменение порядка работы. На обучении человек осваивает новые возможности. В процессе внедрения компания определяет, как именно ими пользоваться: что теперь делает система, что проверяет сотрудник и какие прежние действия больше не нужны. Без второго этапа обучение легко превращается в ещё один пройденный курс.
Представим аналитика, которому ИИ помогает собрать черновик отчёта. Если теперь он должен проверить все утверждения, заново собрать таблицы, вручную перенести их в шаблон и пройти прежние согласования, ускорение генерации легко потеряется на следующих этапах. Нужно договориться, как выглядит новый процесс целиком: какие действия исчезают, какие остаются и где требуется профессиональное решение.
Отдельный вопрос — мотивация. Если внедрение сопровождается только разговорами о сокращениях, сотруднику может быть невыгодно показывать, сколько времени он действительно сэкономил. Если за ошибку отвечает человек, а правила использования ИИ расплывчаты, он будет перепроверять всё вручную или избегать инструмента. Это рациональная реакция на устройство системы.
Поэтому руководителям нужно заранее объяснить, что меняется в ролях, как будет использоваться высвободившееся время и по каким критериям оценивается качество. Людям нужны время на освоение, помощь на реальных задачах и возможность сообщать об ошибках. Один общий вебинар этого не заменяет.
Для пилота я бы выбирал ограниченную команду и повторяемый процесс, собирал удачные и неудачные примеры и обсуждал их с руководителем функции. По мере подтверждения результата можно обновлять регламенты, обучение и систему контроля. Так появляется внутренняя компетенция, которую компания сможет применять и после ухода внешнего специалиста.
Клиентский сервис: скорость ответа ещё не означает решение проблемы
Один из показательных зарубежных примеров — Klarna. В 2024 году её ассистент уже за первый месяц обрабатывал две трети чатов поддержки. Это хороший пример масштаба, которого можно достичь в повторяемой задаче. Но сама доля автоматизированных разговоров ещё не отвечает на вопрос, насколько хорошо решены проблемы клиентов.
Для меня здесь главное — правильно определить результат. Клиенту важно вернуть деньги, разобраться с платежом или получить нужную информацию. Быстрый ответ будет полезен, если приблизит его к решению. Если после разговора с ботом приходится заново объяснять всё оператору, часть эффективности существует только в отчётности.
Клиент общается с представителем бренда и рассчитывает на достоверный ответ. Условия возврата, тарифы и обязательства должны соответствовать действующим правилам компании. Там, где система не может надёжно ответить или решить вопрос, нужен понятный переход к человеку. Ответственность за устройство этого процесса остаётся у бизнеса.
Поэтому для поддержки я бы смотрел одновременно на стоимость решённого обращения, повторные контакты, жалобы, качество и долю корректных передач человеку. Снижение средней длительности разговора при росте повторных обращений может оказаться ухудшением сервиса. Метрика должна отражать задачу клиента целиком.
Ошибка №6. Показать удачный пилот и недооценить промышленную эксплуатацию
В пилоте обычно ограничены пользователи, документы, нагрузка и число исключений. Иногда рядом находится разработчик, который незаметно для заказчика помогает системе пройти сложный участок. После запуска появляются реальные объёмы, новые версии источников, разные права доступа и вопросы, которых не было в демонстрационном наборе.
Я считаю прекращение пилота нормальным управленческим решением, если гипотеза не подтвердилась. Намного хуже масштабировать проект только потому, что он уже получил публичную поддержку или на него потратили много денег. У команды должна быть возможность признать ограничение и скорректировать решение.
До начала эксперимента стоит определить условия продолжения: на каком объёме проверяем решение, какой уровень качества нужен, сколько может стоить обработка одного случая и какие ошибки неприемлемы. Нужны также ответственный за поддержку, способ отключить проблемный сценарий и рабочий резервный процесс. Только после этого можно предметно обсуждать масштабирование.
С AI-агентами появляется ещё один уровень ответственности
Ассистент, который готовит черновик письма, и агент, который сам отправляет его клиенту, создают разный уровень последствий. То же касается изменения карточки контрагента, предоставления скидки или удаления документа. Поэтому расширение автономности должно сопровождаться изменением контроля.
Когда система получает право действовать, её ошибка может выйти за пределы неудачного ответа в чате. Поэтому я бы заранее определил, какие операции она выполняет самостоятельно, где требуется подтверждение сотрудника и как ограничивается возможный ущерб. Особенно это касается платежей, изменения важных данных и действий от имени компании.
Практически это означает, что агенту для чтения заявок не нужен доступ ко всем финансовым документам, а для подготовки ответа не обязательно сразу давать право его отправлять. Нужны журнал действий, ограничения операций и понятный порядок разбора ошибок. Данные из письма или файла также нельзя автоматически считать управляющей командой системе.
Здесь особенно заметна стоимость перехода от эффектного демо к рабочему решению. Компания оплачивает ещё и управляемость: возможность понять, что произошло, остановить ошибку и восстановить процесс. Эти расходы нужно учитывать до расчёта окупаемости.
Российские кейсы: результат появляется в основных процессах бизнеса
X5: прогнозирование, ассортимент и проверка эффекта
X5 оценивает результат применения ИИ за 2025 год примерно в 5 млрд рублей дополнительной операционной прибыли. Основной вклад связан с прогнозированием спроса и пополнением, ценообразованием, управлением ассортиментом и рекомендациями. Эффект проверяется через финансовые модели, A/B-тесты и совместную оценку с бизнес-командами.
Для меня в этом кейсе важен выбор задач. Они напрямую связаны с тем, сколько товара окажется на полке, по какой цене он будет продан и какие потери понесёт сеть. Здесь используются разные классы ИИ, включая машинное обучение. Когда мы обсуждаем возможности генеративных моделей, полезно помнить, что бизнес-эффект может возникать и в менее заметных для широкой аудитории решениях.
«ЕвроХим»: небольшие изменения на большом производственном объёме
У «ЕвроХима» оценка экономического эффекта цифровых продуктов за три года превысила 4 млрд рублей. Большинство этих решений основано на ИИ. В частности, рекомендательные системы на российских производствах аммиака помогли повысить производительность агрегатов в среднем на 2% и снизить удельный расход природного газа на 1%.
Два процента могут выглядеть скромно на фоне обещаний кратного роста эффективности. Но на большом производственном объёме даже такое изменение влияет на экономику. При этом 4 млрд рублей — эффект всего портфеля цифровых продуктов за несколько лет. Я бы смотрел на этот кейс как на пример последовательной работы с конкретными производственными показателями.
Для среднего бизнеса полезно заимствовать способ выбора задач и проверки результата. Размер бюджета и инфраструктуру большой группы копировать целиком не требуется. Инициатива должна соответствовать вашему объёму операций, доступным данным и возможности поддерживать решение.
Средняя и крупная компания сталкиваются с разными ограничениями
У крупного бизнеса больше ресурсов, но обычно сложнее устройство процессов: несколько юридических лиц, разные системы, длительные закупки, требования безопасности и конкуренция подразделений за бюджет. Решение, которое работает в одном отделе, может потребовать серьёзной адаптации в другом.
Здесь полезны общие правила доступа, оценки качества и учёта затрат. При этом у каждой инициативы должен сохраняться конкретный бизнес-владелец. Иначе центральная команда начинает строить универсальную платформу, а подразделения параллельно покупают собственные инструменты, потому что не получают нужного результата вовремя.
Средней компании часто легче договориться об изменении процесса, но у неё меньше свободных специалистов. Один человек совмещает аналитику, автоматизацию и поддержку текущих систем. Для такой организации даже недорогой пилот может оказаться дорогим по времени ключевых людей.
Поэтому я бы начинал с небольшого числа сценариев, где понятны объём задачи, стоимость ошибки и способ измерения. Готовое решение может быть разумнее собственной разработки. Но его всё равно нужно проверить на ваших документах, реальных задачах и условиях эксплуатации. Возможность быстро собрать прототип ещё не означает, что компания сможет годами его сопровождать.
Для российского бизнеса отдельно нужно оценить доступность сервиса, договорные условия, оплату, размещение данных и возможность сменить поставщика. Требования к персональным данным и отраслевые ограничения следует разбирать вместе с юристами и информационной безопасностью применительно к конкретному сценарию. Эти вопросы влияют на архитектуру и бюджет уже на старте.
Что я рекомендую сделать в первые 90 дней
Девяносто дней — удобный горизонт для диагностики и первых проверок. Он не означает, что за это время можно завершить трансформацию всей компании. Задача первого этапа — получить основания для следующих решений.
Первые 30 дней: договориться о задаче и исходных цифрах
Сначала нужно выбрать управленческого спонсора и руководителя программы. Затем провести интервью с владельцами ключевых процессов, посмотреть реальные документы и пройти путь пользователя. На выходе должна появиться карта инициатив: бизнес-задача, ожидаемый эффект, данные, ограничения, владелец, стоимость проверки.
Для одного-двух приоритетных сценариев фиксируется исходное состояние. Например, время от обращения до решения, стоимость обработки, повторные контакты, ошибки, объём операций. Финансовая функция помогает определить, какая часть улучшения может отразиться в экономике. Если надёжной базы пока нет, сначала придётся организовать измерение.
Дни 31–60: проверить гипотезу на реальной работе
Пилот запускается на ограниченной группе и реальных задачах. Там, где возможно, полезно сравнение с контрольной группой; если используется сравнение «до и после», нужно учитывать сезонность, изменение нагрузки и другие факторы. Оценивать следует итоговый результат вместе с проверками и доработками.
Параллельно собираются фактические расходы: использование сервиса, часы команды, поддержка, исправление ошибок. Сотрудники участвуют в настройке нового процесса и сообщают о случаях, где инструмент мешает. Критерии остановки и продолжения должны быть известны заранее.
Дни 61–90: принять решение и закрепить рабочий порядок
Если эффект подтверждён, можно планировать следующий объём, обучение, поддержку и бюджет. Если результат смешанный — сузить задачу или изменить процесс. Если экономика не сходится — остановить проект и зафиксировать выводы. Сам факт завершённого пилота ещё не повод покупать решение на всю компанию.
Результатом этих 90 дней должны стать проверенные гипотезы, понятные ограничения и команда, которая умеет работать с выбранным сценарием. Годовой план после такого этапа будет опираться на опыт вашей компании, а не только на презентацию поставщика.
Когда компании полезен внешний участник
Во всей этой работе есть сложность: человеку внутри компании трудно одновременно разбираться в новых инструментах, спорить с привычным устройством процессов и оставаться независимым от интересов подразделений. А у собственника и CEO редко есть возможность лично вести каждую инициативу.
На этом участке я и работаю с компаниями. Для меня старт — разговор с собственником и управленческой командой о целях, ограничениях и деньгах. Дальше можно понять, где достаточно AI-стратсессии, где нужен аудит процессов и данных с дорожной картой, а где потребуется сопровождение внедрения в роли внешнего AI-директора.
Опыт цифровой трансформации помогает мне связывать обсуждение технологии с устройством бизнеса: кто принимает решения, у кого нужные данные, как проверить гипотезу и какие изменения команда действительно сможет реализовать. Работа идёт вместе с сотрудниками компании и, при необходимости, подрядчиками. Техническое исполнение, бюджет и ответственность за отдельные участки нужно определить заранее.
При этом для меня важно, чтобы внутри оставались люди, которые понимают логику решений, умеют проверять качество и могут дальше развивать этот подход самостоятельно. Внешний участник полезен, когда помогает выстроить такую работу и довести её до измеримого результата. Подход и возможные форматы я подробнее описал на странице работы с компаниями.
С какого вопроса стоит начать
Я бы предложил собственнику или CEO начать следующий разговор об ИИ с конкретного процесса: какой результат для клиента или компании сейчас получается слишком медленно, дорого или нестабильно? Потом — разобраться в причинах и определить, какое изменение можно проверить.
У ИИ уже достаточно возможностей, чтобы быть полезным в большом количестве рабочих задач. Реальные кейсы это подтверждают. Но они также показывают цену ошибок в постановке задачи, измерении результата и организации исполнения.
Компаниям придётся научиться выбирать инициативы, проверять их экономику, менять роли и останавливать то, что не даёт нужного результата. Именно эта управленческая работа определит, насколько ожидания от ИИ совпадут с реальностью вашего бизнеса.
