Как Сатья Наделла объясняет разрыв между пилотами Microsoft Copilot и реальным продакшеном и что это значит для внедрения ИИ в процессы.

Профиль человека: путь, решения и уроки для бизнеса.

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

Связанные услуги: каталог, AI Boost Team, стать клиентом.

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

Вопрос, на который ниже есть ответ: что конкретно ломается между пилотом на 5–30 сотрудников и продакшеном на всю компанию, и в каком порядке это чинить, если у вас 20–300 человек в штате и один ИТ-специалист на всё про всё.

Кто такой Наделла и почему его формулировки читают операционщики, а не только айтишники

Уроженец Хайдарабада, инженерное образование в Индии, магистратура по computer science в Висконсине, MBA в Чикаго. До Microsoft успел поработать в Sun Microsystems. В Microsoft пришёл инженером и прошёл через Windows, Office, поиск и облако, а позже возглавил направление Azure. Третий CEO в истории компании после Билла Гейтса и Стива Балмера.

Смена модели, которую он провёл, интересна не масштабом, а типом решения. Компания, десятилетиями продававшая лицензии в коробке, перестроилась вокруг подписок и облачных мощностей. И это была не смена витрины. Это была смена того, как считается выручка, как устроена ответственность внутри продуктовых команд и что вообще считается готовым продуктом. Именно поэтому его объяснение провалов ИИ-пилотов звучит убедительно для тех, кто отвечает за операционный контур, а не за демо для совета директоров.

Второй его публичный тезис, который стоит держать в голове: культура обучения. Звучит как коуч-бот, но в переводе на операционный язык это означает, что команда имеет право показать отрицательный результат замера и не быть за это наказанной. Без этого вы не получите ни одной честной метрики после пилота. Получите отчёт, нарисованный под ожидания руководителя.

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

Что Наделла называет разрывом между пилотом и продакшеном

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

Три вещи, которые в демо не видны вообще.

• Ответственность за ошибку. Пока непонятно, кто отвечает за неверный ответ ассистента клиенту, никто не понесёт этот ответ в реальный канал. Люди саботируют не технологию, а неопределённую ответственность.
• Права доступа и контуры данных. Ассистент, которому дали читать всё «чтобы работало», на первом же разборе инцидентов превращается в проблему безопасника. Ассистент, которому дали читать слишком мало, отвечает мусором и теряет доверие за неделю.
• Стыковка с регламентом. Если в инструкции написано «менеджер проверяет заявку по чек-листу из 12 пунктов», ассистент либо встраивается в эти 12 пунктов, либо инструкцию надо переписывать. Третьего не дано.

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

Почему малая группа искажает результат

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

Дальше начинается арифметика узкого места. Ассистент экономит 20% времени на шаге, но шаг согласования с смежным отделом занимает 2–4 недели ожидания. Ваша экономия растворяется в очереди, и в отчёте по процессу остаётся ноль. Это не провал модели. Это провал выбора процесса для пилота.

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

Три условия перехода от пилота к процессу

Условий ровно три, и все три проверяются до старта, а не после. Если хотя бы одно не выполнено, расширение превратится в тиражирование ошибки на весь штат.

Черновик регламента пишется до пилота, финальная версия после. Это единственная последовательность, при которой вы сравниваете не «было/стало», а «план/факт по одному и тому же процессу». Подробнее про то, как такой контур собирается на стороне продукта, есть в разборе ИИ-ассистента для операционных процессов.

Данные и доступы: где чаще всего ломается

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

Права доступа это часть процесса, а не настройка в админке. Решение о том, что ассистент видит, а