Представьте совещание по цифровой трансформации. На экране — ассистент, который за секунды отвечает клиенту, собирает отчёт и находит нужный договор. Команда показывает количество пользователей и запросов. Выглядит убедительно.
Потом собственник задаёт вопрос: «А что изменилось в экономике компании?» Сколько дополнительных заявок обработали? Какие расходы исчезли? Стал ли клиент быстрее получать результат? И здесь разговор часто приходится начинать заново: эти показатели до запуска никто не зафиксировал.
Технически проект состоялся. Управленчески — пока нет.
Меня в этой истории интересует именно второй уровень. Я сам строю AI-продукты и работаю с компаниями, поэтому не разделяю восторг от любого работающего прототипа. Убедительное демо показывает возможности технологии. Чтобы получить результат в бизнесе, нужно ещё выбрать правильную задачу, изменить процесс и договориться об ответственности.
Из опыта цифровой трансформации я вынес простую вещь: инструмент внедряется в уже существующую систему интересов, договорённостей и привычек. Если коммерческий директор, ИТ и операционный блок по-разному понимают цель, новая модель этот конфликт за них не разрешит. Зато очень быстро сделает его заметным.
Разрыв начинается между удобством сотрудника и результатом компании
Сотруднику стало проще писать письма. Аналитик быстрее собирает первый вариант отчёта. Руководитель может задать вопрос документам вместо ручного поиска. Всё это полезно. Но ни одно из этих улучшений ещё не объясняет, что получила компания.
Этот разрыв виден и в исследовании McKinsey за 2026 год: 80% респондентов говорят о росте личной продуктивности, а 37% — хотя бы о некотором вкладе ИИ в прибыль до процентов и налогов, EBIT. Это ответы участников опроса, а не финансовый аудит, но различие уровней здесь показательно.
Я бы разделял четыре результата: доступ к инструменту, ускорение отдельной задачи, изменение рабочего процесса и финансовый эффект. Между ними каждый раз требуется управленческое решение. Логин не меняет порядок согласований. Быстрый черновик не отменяет проверку. Освободившийся час сам по себе не создаёт дополнительный заказ.
Поэтому мне не нравится вопрос «сколько сотрудников уже пользуется ИИ?» в качестве главного показателя программы. Мне важнее другое: какая работа теперь проходит через компанию быстрее, дешевле или качественнее и за счёт чего это произошло.
Начните с места, где бизнес теряет деньги
«Нам нужен корпоративный чат-бот» — ещё не постановка задачи. «У конкурента есть агент» — тоже. В обоих случаях компания уже выбрала форму решения, хотя с проблемой пока не разобралась.
Допустим, коммерческое предложение готовится три дня. ИИ может написать его текст за десять минут. Но если два с половиной дня менеджер ждёт расчёта себестоимости, остатков и согласования скидки, клиент почти не заметит разницы. Вы ускорили удобный для автоматизации фрагмент, а ограничение осталось на прежнем месте.
Я бы сначала прошёл путь заявки целиком: от обращения до результата. Где она ждёт? Где данные переписывают руками? Какое согласование действительно защищает бизнес, а какое существует по привычке? На каком участке теряются заказ, маржа или доверие клиента?
Ошибка в понимании самой задачи — одна из основных причин неудач, которые разбирает RAND в исследовании AI-проектов. Для меня практический вывод простой: прежде чем обсуждать модель, команда должна суметь объяснить, какой показатель она меняет и почему выбранное действие на него повлияет.
Хорошая гипотеза может звучать так: «Сократить время от входящей заявки до принятого решения, сохранив качество и долю повторных обращений». После этого уже можно искать решение. Иногда им окажется ИИ. Иногда — интеграция двух систем или отмена лишнего согласования. Убирать такие варианты из обсуждения я бы не стал.
Сэкономленное время ещё нужно превратить в деньги
Предположим, менеджер действительно стал тратить на операцию на четыре минуты меньше. Это хороший промежуточный результат. Дальше я задам вопрос: что компания сделала с этим ресурсом?
Обработала больше заявок тем же составом? Уменьшила сверхурочные? Отказалась от части внешней работы? Смогла выдержать рост нагрузки без дополнительного найма? Если ничего из этого не произошло, мы получили запас мощности. Он может быть полезен, но записывать его целиком в экономию расходов рано.
Удобная ошибка — умножить минуты на зарплату и показать годовой эффект. При этом фонд оплаты труда остаётся прежним, заказов больше не становится, а компания начинает платить за сервис, поддержку и проверку ответов.
Сначала нужно понять, куда пойдёт высвободившийся ресурс. И только после этого считать финансовый эффект.
Для отдельного сценария я бы раскладывал расчёт на три части: дополнительную маржинальную прибыль, подтверждённое сокращение расходов и полную стоимость решения. Предотвращённые потери и рост доступной мощности показывал бы отдельно, с понятными допущениями. Одно и то же высвободившееся время нельзя одновременно посчитать как сокращение затрат и как ресурс для дополнительных продаж.
В расходы входят не только лицензии или вызовы модели. Есть подготовка данных, интеграции, время внутренних специалистов, обучение, проверка результата, исправление ошибок и сопровождение после запуска. Если собственная разработка кажется почти бесплатной, полезно сразу назначить человека, который будет отвечать за неё через год. Его работа тоже имеет стоимость.
Такой расчёт обычно скромнее цифры из презентации поставщика. Зато по нему можно решить, стоит ли вкладывать следующие деньги.
За результат должен отвечать человек, который может менять процесс
ИТ может обеспечить архитектуру, доступность и безопасность. Подрядчик — выполнить согласованный объём работ. HR — организовать обучение. Но кто из них вправе отменить этап продажи, изменить правила согласования скидки или договориться о новой работе коммерческого блока?
Если ответ — «никто», экономический эффект оказывается общей надеждой без конкретного владельца. Каждый участник выполнил свою часть, а компания продолжает работать как раньше.
У инициативы нужен бизнес-владелец: человек, у которого есть метрика результата и полномочия менять работу. А если процесс проходит через несколько подразделений, нужен управленческий спонсор, способный разрешать конфликты между ними.
Для средней и крупной компании это особенно важно. Заявка может последовательно проходить через маркетинг, продажи, юристов, финансы и операционный блок. Улучшить один участок проще, чем договориться о результате всей цепочки. Поэтому я бы не начинал с создания «AI-отдела», пока не понятно, кто будет принимать решения на этих стыках.
Название должности здесь вторично. Руководитель внедрения может называться CDO, директором по трансформации или руководителем AI-направления. Существенно то, какие решения он вправе принимать и кто поддержит их исполнение.
Проверяйте полный цикл работы, включая доработки
Самая быстрая часть процесса теперь часто выглядит впечатляюще. Текст появился за минуту. Код написан. Отчёт собран. А потом начинается работа, которую на демонстрации почти не видно: проверить источники, исправить расчёт, встроить результат в систему и согласовать с тем, кто будет им пользоваться.
Если сотрудник сгенерировал презентацию за пять минут, а руководитель два часа разбирался, откуда взялись цифры, время не обязательно сэкономлено. Часть работы просто перешла к другому человеку.
Мне нравится неудобный пример из эксперимента METR с опытными разработчиками: инструменты начала 2025 года увеличили время выполнения задач в среднем на 19%, хотя участникам казалось, что они работают быстрее. Эксперимент был узким, а в последующем обновлении авторы отмечали вероятное улучшение новых инструментов и сложности надёжного измерения. Делать из старого результата вывод о любых современных AI-инструментах было бы неверно.
Для руководителя здесь ценен сам вопрос: мы измеряем ощущение скорости или принятую работу? Я бы считал время от начала задачи до результата, которым действительно можно пользоваться. Вместе с проверкой, переделками, согласованиями и последствиями ошибок.
И смотрел бы на разные типы задач отдельно. Средний показатель может скрыть, что на типовых обращениях решение помогает, а на сложных создаёт дополнительную очередь. Именно эта очередь иногда и определяет впечатление клиента от компании.
В поддержке клиенту нужен решённый вопрос
В феврале 2024 года Klarna в своём сообщении о первом месяце работы AI-ассистента оценивала его нагрузку как эквивалент работы 700 сотрудников: 2,3 млн разговоров и две трети чатов поддержки. Это заявление компании об объёме работы. Оно само по себе не доказывает ни увольнение именно 700 человек, ни такой же эффект в другом бизнесе.
Когда я читаю подобный кейс, мне хочется узнать, что считалось завершённым обращением. Клиент получил правильное решение? Ему пришлось написать ещё раз? Система вовремя передала сложный случай человеку? Снижение стоимости контакта мало помогает, если для решения одного вопроса клиенту теперь нужны три контакта.
Есть и другая сторона. В деле Moffatt v. Air Canada трибунал Британской Колумбии признал ответственность авиакомпании за неверную информацию её чат-бота об условиях тарифа. Это конкретное решение в конкретной юрисдикции, но управленческий урок понятен: клиент получает ответ от вашего бренда.
Поэтому для клиентского сервиса я бы одновременно проверял стоимость решённого обращения, повторные контакты, жалобы и корректность передачи человеку. Ускорение первого ответа — только часть этой картины. И менять штат на основании красивого процента автоматизации до такой проверки я бы не стал.
Новый инструмент должен изменить ежедневную работу
После курса по нейросетям сотрудник возвращается к прежнему руководителю, прежним KPI и обязательным действиям. Если к старой работе просто добавили новую систему, у него стало на один инструмент больше.
Представьте аналитика: ИИ подготовил черновик отчёта, но затем нужно вручную перепроверить все цифры, перенести таблицы в прежний шаблон и пройти те же согласования. Польза возможна, однако искать её нужно во всём процессе, а не в скорости появления черновика.
Мне кажется неправильным в такой ситуации сразу обвинять людей в сопротивлении. Сотрудник может вполне рационально избегать нового маршрута: в системе нет актуальных данных, за ошибку отвечает он, руководитель требует старый формат, а времени на освоение никто не выделил.
До запуска стоит договориться, какие действия исчезают, что остаётся на проверку человеку, как оценивается качество и на что пойдёт освободившееся время. А обучение проводить на реальных задачах команды, с разбором удачных и неудачных случаев.
Хороший признак внедрения — когда новый маршрут становится обычным способом выполнить работу. Если человек отчитывается об использовании ассистента, а результат всё равно собирает ночью в старом Excel, я бы разбирался в устройстве процесса.
Демо должно выдержать ваши данные и ваши исключения
В CRM может быть один статус клиента, в учётной системе — другой, а важная договорённость вообще хранится в переписке менеджера. Модель, подключённая к этим источникам, не получит автоматически понимание, чему верить.
Человек часто умеет обходить такой беспорядок: знает, кому позвонить и какой файл считать действующим. Для системы эти правила нужно определить. Кто обновляет данные? Какая версия документа актуальна? Что делать при расхождении? Кто имеет право видеть этот ответ?
При этом предложение сначала навести идеальный порядок во всех данных компании способно остановить работу на годы. Я бы выбрал ограниченный процесс и подготовил именно тот участок, который для него нужен. Тогда станет понятно, какие следующие вложения оправданы.
То же относится к испытаниям. В пилот должны попасть неполные заявки, устаревшие документы, нестандартные условия и высокая нагрузка. Иначе компания проверит способность модели пройти демонстрацию, а реальную работу начнёт изучать уже после масштабирования.
Правила продолжения нужно определить до запуска. Какое изменение метрики достаточно? Какое качество обязательно? Какие ошибки неприемлемы? Когда дорабатываем, а когда останавливаем? Без этих условий пилот легко становится бессрочным: команда занята, бюджет расходуется, но момента принятия решения не наступает.
Полномочия агента нужно выдавать вместе с контролем
Ассистент, который готовит письмо, и агент, который сам отправляет его клиенту, создают разные последствия. То же касается скидки, изменения реквизитов или удаления документа. Поэтому уровень автономности нельзя выбирать только по тому, насколько эффектно это выглядит.
Я бы начал с простых вопросов: какие данные система видит, что может сделать без человека, где ограничена по сумме и количеству операций, кто заметит ошибку и как восстановит процесс.
Там, где действие дорого обходится или трудно отменяется, нужен дополнительный контроль. Часто разумный первый шаг — дать ИИ собрать контекст и подготовить решение, а право исполнения расширять после проверки надёжности.
В бюджет придётся включить журнал действий, тесты, мониторинг, поддержку и возможность отключения. Компания платит за способность пользоваться системой в реальной работе и разбирать её ошибки. Возможность быстро собрать агента не отменяет этой части проекта.
Что я бы сделал в первые 90 дней
Я не считаю 90 дней обещанием завершить AI-трансформацию. Это удобный срок, чтобы проверить несколько важных предположений и получить основания для следующего решения.
Первый месяц: выбрать задачу и зафиксировать исходное состояние
Я бы собрал собственника или управленческого спонсора, владельцев процессов, ИТ и финансы. Выбрал несколько повторяющихся задач с заметной стоимостью, очередью или потерей выручки. По каждой нужно понять объём работы, ограничения, качество данных и способ измерить результат.
Затем оставил бы один-два сценария для проверки. У каждого — конкретный владелец и исходные показатели: время полного цикла, ошибки, повторные обращения, затраты. Если измерения пока нет, первым результатом станет его организация.
Второй месяц: проверить решение на ограниченном потоке
Пилот запускается на реальных задачах и ограниченной группе. По возможности — с контрольной группой. Сотрудники участвуют в настройке нового порядка работы, а команда учитывает фактические расходы, время проверки и переделки.
Здесь особенно важно не менять определение успеха по ходу проекта. Если обещали уменьшить срок обработки заявки, количество сгенерированных ответов не заменяет эту метрику.
Третий месяц: принять решение
Подтверждённый эффект даёт основание планировать следующий объём, обучение и поддержку. Смешанный результат — сузить сценарий или изменить процесс. Отрицательная экономика — остановить инициативу и зафиксировать выводы.
Остановка неудачной гипотезы после ограниченной проверки может быть хорошим результатом работы. Гораздо дороже годами поддерживать программу, которую неудобно закрыть из-за уже потраченных денег.
К концу этого этапа собственник должен понимать, что изменилось, сколько это стоит и кто будет отвечать за решение дальше. Если вместо ответа есть только список запущенных инструментов, я бы не спешил расширять бюджет.
Где я могу быть полезен компании
Самая сложная часть такой работы часто находится между подразделениями. У ИТ своя ответственность, у бизнеса свои показатели, у подрядчика свой объём работ. Каждая из этих позиций может быть разумной, но кто-то должен собрать их в последовательность решений.
Мне эта задача близка: в X-Fit и World Class я работал в роли CDO/CPO, а сейчас также развиваю собственные AI-продукты — JobSignal, DataDoctor и VengoFlow. Этот опыт помогает связывать обсуждение инструментов с процессом, экономикой и возможностями команды.
В работе с компаниями у меня есть три формата в зависимости от глубины задачи:
- AI-стратсессия — договориться с управленческой командой о приоритетах и плане первых проверок.
- AI-аудит и дорожная карта — разобрать процессы и данные, оценить сценарии в деньгах и определить порядок внедрения.
- Внешний AI-директор — вести инициативы вместе с вашей командой: от постановки метрик и пилотов до контроля подрядчиков и развития внутренней компетенции.
Во всех трёх случаях мне важно, чтобы компания понимала логику решений и могла дальше работать с ними самостоятельно. Где-то достаточно одной сессии. Где-то потребуется длительное сопровождение. Иногда полезнее сначала исправить процесс и вернуться к ИИ позже.
Какой вопрос я бы задал на следующем совещании
Собственнику не обязательно разбираться во всех моделях и архитектурах. Достаточно спросить: какой результат для клиента или компании теперь получается быстрее, дешевле или надёжнее — и чем это подтверждено?
Хороший ответ будет включать исходную метрику, изменение процесса, фактические затраты и владельца результата. По нему понятно, что делать дальше. Ради такого ответа я и вижу смысл внедрять ИИ.
Возможности технологии уже достаточно велики, чтобы быть полезными. Теперь компаниям нужно научиться выбирать задачи, менять работу и спокойно принимать решения по результатам проверки. Красивое демо может стать началом этой работы. До денег её всё равно придётся довести.
Если у вас уже есть пилоты и много активности вокруг ИИ, но общая картина эффекта не складывается, можно начать с разбора одного процесса. Обсудим вашу задачу и определим, какой следующий шаг имеет смысл для вашей компании.
