McKinsey State of AI 2025: разрыв между внедрением и ценностью и при чем тут PMO

McKinsey State of AI 2025: разрыв между внедрением и ценностью и при чем тут PMO

Опубликовано 12 июля 2026 7 мин чтения

88% против 39%: цифры, которые меняют вопрос

Восемьдесят восемь процентов организаций используют AI в работе. Эта цифра из отчёта McKinsey State of AI 2025 звучит как победная реляция: внедрение состоялось, технология перешла из категории экспериментов в категорию нормы. Можно переключаться на следующую тему.

Но рядом стоит другая цифра: 39% фиксируют измеримый эффект на чистую прибыль. То есть из тех, кто внедрил, меньше половины видит ценность в финансовых результатах. А шесть процентов компаний получают непропорционально большую долю этой отдачи — это high performers, которые играют по другим правилам.

Разрыв между 88% и 39% - вот где начинается настоящий разговор.

Прежде чем идти дальше, нужно оговориться: цифра 88% широкая, в неё почти наверняка входит использование ChatGPT для разовых задач, встроенные AI-функции в офисных пакетах, рекомендательные системы, существующие годами. Это не одно и то же, что институциональное внедрение AI в бизнес-процессы. Цифра в 39% компаний с влиянием AI на прибыль - это самооценка из опроса: компании могут приписывать результаты AI-инициативам постфактум, завышая реальный вклад.

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

McKinsey его даёт в своем отчете.

Почему разрыв не технологический

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

McKinsey предлагает другую логику. Три структурные причины, которые они выделяют, не имеют отношения к качеству моделей.

Первая: AI встраивают в старые процессы вместо того, чтобы перепроектировать процессы под новую логику. Автоматизация существующего шага не меняет результата, если сам шаг создан под другую реальность. Модель, встроенная в неэффективный процесс, делает этот процесс быстрее, но не лучше.

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

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

Три независимых управленческих барьера между внедрением AI и реальной отдачей: (1) AI встраивают в старые процессы без…

Здесь стоит остановиться и проговорить неудобный аргумент. Разрыв между обещанием технологии и реальной отдачей — не новость. Можно вспомнить:

  • RPA (robotic process automation, роботизация) обещала освободить людей от рутины: процессы автоматизировали, но бот ломался каждый раз, когда менялся интерфейс.
  • Большие данные обещали инсайты: аналитика множилась, решения принимались по-прежнему интуитивно.
  • Облака обещали гибкость: миграция затянулась, а экономия оказалась меньше прогнозов.

Аргумент «на этот раз иначе» нужно произносить вслух, а не замалчивать и явно пояснять, что за этим стоит. Почему сейчас “иначе”: генеративный AI встраивается в когнитивные задачи - туда, где раньше автоматизация была практически невозможна. Это не ускорение транзакций, а изменение природы работы с информацией. И именно поэтому управленческая инфраструктура (то, как организация решает, что внедрять, как верифицировать и как тиражировать) становится переменной, которая раньше не имела значения, а теперь имеет.

Данные как узкое горлышко при переходе от пилота к масштабу

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

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

Лидеры по отдаче от AI, по наблюдению McKinsey, приоритизируют data readiness: соединение структурированных и неструктурированных данных в единую управляемую, переиспользуемую основу. Не как разовый проект, а как инфраструктуру. Поток от управляемого пилотного датасета (вручную собранные источники, очищенные форматы) через узкое горлышко…

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

Для работы проектного офиса с AI это переводится в конкретный вопрос: какие данные о проектах, процессах и результатах сейчас разрознены настолько, что AI-инструмент, встроенный в PMO-процессы, через месяц упрётся в невозможность получить нужное? Ответ на этот вопрос до начала внедрения экономит больше, чем любая последующая интеграция.

Что делать PMO с этим знанием

Здесь разговор переходит от диагноза к операционному минимуму.

Первое — каталог процессов с AI. Не стратегическая карта, не дорожная карта на три года. Просто реестр: где в организации AI уже используется, в каком процессе, с каким измеримым или наблюдаемым результатом, что технически готово к тиражированию. PMO по природе своей - это структура, которая умеет делать такие реестры. Разница в том, что объектом учёта становятся не проекты, а AI-применения внутри процессов.

Зачем это нужно? Потому что без каталога организация будет заново изобретать одно и то же в разных подразделениях, тратить ресурсы на пилоты, которые уже проведены по соседству, и не иметь возможности сравнить, где AI работает, а где нет. Каталог — это не бюрократия. Это условие масштабирования.

Второе — чек-листы валидации AI-результатов. McKinsey называет слабый контроль качества на выходе модели одной из трёх причин разрыва. Решение не требует ни архитектурных изменений, ни больших бюджетов. Оно требует договорённости: кто проверяет конкретный тип AI-вывода, по каким критериям, что делает при расхождении.

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

Каталог и чек-листы — это не всё, что нужно сделать. Но это то, что можно сделать на следующей неделе. И именно в этом их ценность: они переводят стратегический разрыв между 88% и 39% в конкретное действие с конкретным исполнителем.

Два конкретных инструмента PMO как операционный минимум: слева — реестр AI-применений по процессам (что, где, с каким…

Риск для PMO остаться наблюдателем

PMO создан для управления изменениями. Это его определение, его причина существования. Governance, методология, стандарты, портфельное мышление — всё это инструменты перехода от одного состояния к другому.

Однако в AI-волне PMO рискует остаться наблюдателем. Не злонамеренно, а просто потому что AI-инициативы запускаются как ИТ-проекты или продуктовые эксперименты, управление этими инициативами выстраивается через CDO или отдельными подразделениями в “вертикали инноваций”, а PMO получает и будет получать отчёт о статусе постфактум. Структура, которая по определению должна быть агентом перехода, оказывается в роли получателя информации.

Шесть процентных пунктов между теми, кто получает отдачу от AI, и всеми остальными — это не технологическое преимущество, high performers не используют принципиально другие модели. Они по-другому управляют: принимают решения о том, где применять AI, создают инфраструктуру для валидации и тиражирования, встраивают новую логику в процессы, а не встраивают AI в старую логику.

Вопрос не в том, меняет ли AI управление проектами. Он уже меняет. Вопрос в том, кто управляет этим изменением внутри организации. McKinsey даёт цифровое обоснование того, почему ответ «само разберётся» стоит дорого. А структура, у которой есть инструменты, мандат и привычка работать с переходами, имеет основание не ждать, пока её позовут.

Дочитали — заходите в Telegram

Короткие заметки и эксперименты между лонгридами.

Подписаться на @ai_pmo