Эффективность внедрения ИИ: почему работа не ускоряется

Почему эффективность внедрения ИИ не видна по сэкономленным минутам?

8 июля 2026 года McKinsey опубликовала исследование о разрыве, из-за которого эффективность внедрения ИИ трудно увидеть в результатах компании. В глобальном опросе участвовали 750 англоязычных сотрудников и руководителей, уже использующих ИИ в работе; ответы собирали с февраля по апрель. Люди были готовы пользоваться инструментами раньше, чем организации – менять работу. Авторы отдельно оговорили границы выводов: ответы участников не представляют организации целиком, а об организационной готовности и ценности отвечали только руководители. Опрос показал связь, но не доказал, что одно стало причиной другого. Источник: McKinsey.

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

Представим условную цепочку подготовки предложения: запрос клиента, уточнение состава работ, расчёт, проверка, отправка. ИИ ускорил черновик. А что изменилось для клиента? Если расчёт всё ещё ждёт ответственного, а проверяющему не хватает вводных, срок может остаться прежним. Это пример того, как устроен процесс, не кейс CRT.

Я предлагаю считать отдельно:

• Трудозатраты – сколько времени люди активно работали, включая проверку и исправления.
• Длительность полного цикла – сколько прошло от получения запроса до принятия результата.
• Объём результата – сколько обращений завершили с согласованным качеством за сопоставимый период.

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

Где искать причину: в инструменте, проверке или передаче работы?

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

Для первого разбора мне хватило бы такой таблицы.

С замерами зашла в тупик и METR. В обновлении от 24 февраля 2026 года исследователи объяснили, почему пересматривают эксперимент по производительности разработчиков. Задачи случайно распределяли между условиями с разрешённым и запрещённым ИИ. Но часть разработчиков не хотела участвовать без ИИ, а участники могли не подавать задачи, для которых ожидали особенно большой пользы от инструмента. Получалось, что отбор начинался ещё до случайного распределения.

Подвёл и учёт времени: пока агент работал, разработчик мог заниматься другим делом. Исследователи признали, что новые данные ненадёжно отражают текущий эффект, и начали менять дизайн исследования. Вывода «ускорения нет» они не делали. Они объяснили, почему полученные замеры не позволяют уверенно назвать его величину. Источник: METR.

Вот что я взял бы из этого для корпоративного пилота: проверяйте, что осталось за пределами отчёта. Если команда показывает удачные обращения, а сложные молча обрабатывает по старому маршруту, результат относится лишь к отобранной части работы. Ощущение ускорения – полезный повод начать проверку. Подменять им замер я бы не стал.

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

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

Я бы проверил кандидата по этому списку:

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

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

А нужен ли здесь вообще ИИ? Если документ ждёт подтверждения от человека, который ничего в нём не проверяет и не принимает решений, я сначала предложил бы пересмотреть это согласование. Ускорять подготовку документа перед ненужной очередью бессмысленно. Другое дело, если согласование защищает от существенной ошибки. Убирать его ради скорости нельзя: нужно выяснить, каких сведений не хватает для более раннего решения.

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

Кто отвечает за результат между отделами?

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

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

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

Похожее разделение предлагает ELMA: среди причин неудач названы отсутствие бизнес-владельца и запуск ИИ как отдельного эксперимента ИТ-отдела. Источник: ELMA.

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

Как измерить эффективность внедрения ИИ до и после?

Предлагаю руководителю заполнить короткий паспорт пилота (это заготовка для обсуждения, а не описание внутренней методики CRT).

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

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

Зависшие обращения тоже должны остаться в отчёте. Быстро закрытые задачи могут улучшить среднее время, пока сложная работа копится в очереди. Покажите отдельно завершённые результаты, незавершённые обращения и причины остановок. Очередь же никуда не делась оттого, что её не посчитали.

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

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