Метрики, которые важны руководителю

ИИ легко создает ощущение прогресса. Сотрудники начинают активнее пользоваться ассистентами. В чатах появляются красивые ответы. Кто-то показывает впечатляющую презентацию,

кто-то за десять минут пишет текст, который раньше готовил час, кто-то просит модель объяснить сложный документ.

На уровне впечатления кажется: “все заработало”. Но руководителю этого мало.

Ему нужно понять:

изменилась ли работа компании;

стало ли быстрее;

стало ли качественнее;

снизились ли потери;

выросла ли прозрачность;

появился ли денежный эффект;

можно ли масштабировать подход;

не выросли ли риски.

Если метрик нет, AI-Native внедрение превращается в спор ощущений. Одни говорят: “ИИ очень помогает”. Другие говорят: “ничего не изменилось”. Третьи говорят: “стало даже хуже, потому что теперь нужно проверять тексты ассистента”.

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

Использование не равно эффект

Первая ловушка — мерить только использование.

Например:

сколько сотрудников вошло в ассистента;

сколько запросов отправлено;

сколько документов сгенерировано;

сколько skills установлено;

сколько агентов запущено.

Эти показатели полезны, но они не доказывают бизнес-эффект. Можно иметь тысячи запросов к модели и нулевое изменение процесса. Можно иметь высокий adoption и низкое качество. Можно активно генерировать документы, которые потом долго исправляются.

Можно поставить ассистента всем сотрудникам, но не изменить ни одну роль. Поэтому использование — это только первый слой.

Оно отвечает на вопрос:

Люди вообще начали работать с новым способом?

Но руководителя должен интересовать следующий вопрос:

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

Пять групп метрик

Для AI-Native контура удобно смотреть пять групп метрик:

Принятие командой.
Скорость процесса.
Качество результата.
Снижение потерь.
Бизнес-эффект и управляемость.

Их не нужно считать сразу по всей компании. Сначала — по одному контуру. Например: подготовка коммерческого предложения, проверка договора, проектный статус, обработка входящей заявки, разработка функции, поддержка клиента. Метрика без контура почти бесполезна.

Фраза “мы стали использовать ИИ на 40% больше” звучит бодро, но мало что говорит руководителю. Фраза “в контуре подготовки КП среднее время снизилось с 4 часов до 1 часа 40 минут, возвраты на доработку упали с 60% до 25%, а менеджеры стали использовать

единый quality review” — уже управленческий факт.

Принятие командой

Принятие — это не просто число логинов. Настоящее принятие видно по тому, что люди начинают включать ассистента в свою обычную работу, а не только показывать его на демо.

Что можно измерять:

доля пользователей пилотной группы, которые используют ассистента каждую неделю;

количество реальных рабочих задач, выполненных с ассистентом;

доля задач, где использовался утвержденный skill;

повторное использование skills;

количество улучшений skills, предложенных сотрудниками;

доля пользователей, которые готовы продолжать после пилота;

число случаев, когда ассистент стал частью стандартного процесса.

Важно различать любопытство и принятие.

Любопытство выглядит так:

Сотрудник один раз попробовал, получил интересный

ответ и больше не вернулся.

Принятие выглядит так:

Сотрудник каждую неделю использует ассистента в

конкретной задаче и уже чувствует, что без него работа стала бы медленнее.

Отдельно стоит смотреть на “сдвиг мышления”.

Он не всегда измеряется числом, но его можно заметить по поведению:

человек начинает приносить ассистенту более качественный контекст;

просит не просто “напиши”, а “проверь”, “сравни”, “найди риск”;

предлагает улучшения skill;

сам спрашивает, где source of truth;

начинает думать задачами для ассистента;

перестает воспринимать ИИ как игрушку.

Для руководителя это важный сигнал: новый способ работы начал закрепляться.

Скорость процесса

Скорость — самая понятная метрика. Но и здесь есть нюанс. Нужно мерить не только “сколько времени занял один текст”, а весь процесс. Например, если ассистент написал черновик КП за 10 минут, но потом менеджер и руководитель три часа исправляли

ошибки, эффект сомнительный.

Лучше смотреть:

cycle time — время от начала задачи до готового результата;

touch time — активное время человека;

время ожидания данных;

время на поиск информации;

время на согласование;

количество возвратов;

долю задач, выполненных в срок.

Для разных контуров скорость выглядит по-разному.

В продажах:

время от входящего запроса до первого качественного ответа;

время подготовки КП;

время подготовки к встрече;

время передачи сделки в производство.

В проектах:

время подготовки статуса;

время обнаружения блокера;

время от появления проблемы до эскалации;

время входа нового участника в контекст.

В разработке:

время от задачи до первого плана;

время подготовки MR;

время ревью;

количество возвратов после ревью;

время на поиск связанного контекста.

В документообороте:

время проверки договора;

время подготовки акта или счета;

время поиска правильного шаблона;

время согласования.

Главное — мерить скорость всей работы, а не скорость генерации текста.

Качество результата

AI-Native внедрение не должно ускорять мусор. Если компания стала быстрее выпускать плохие документы, нет повода радоваться.

Качество можно измерять через:

долю результатов, принятых с первого раза;

количество возвратов на доработку;

число найденных ошибок;

полноту обязательных полей;

соответствие чек-листу;

долю результатов, прошедших quality review;

количество постфактум исправлений;

количество замечаний клиента;

количество дефектов после выпуска.

Для коммерческих предложений качество может означать:

есть ли связь с запросом клиента;

указаны ли ограничения;

учтены ли похожие кейсы;

нет ли необоснованных обещаний;

соблюден ли формат;

приложены ли нужные материалы.

Для договора:

проверены ли реквизиты;

суммы;

сроки;

штрафы;

персональные данные;

нестандартные условия;

актуальность шаблона;

обязательные согласования.

Для инженерной задачи:

понятны ли acceptance criteria;

есть ли тесты;

не нарушена ли архитектура;

нет ли секретов в коде;

оформлен ли MR;

понятен ли риск изменения.

Качество особенно важно потому, что ИИ может создавать убедительные ошибки. Раньше плохой черновик выглядел плохо. Теперь плохой черновик может выглядеть гладко. Поэтому у каждого важного skill должны быть правила качества.

Иначе компания будет мерить скорость красивых ошибок.

Снижение потерь

Часть эффекта от AI-Native внедрения находится не в прямой экономии времени, а в снижении потерь.

Потери часто выглядят так:

забыли следующий шаг по клиенту;

поздно увидели риск проекта;

сделали документ по старому шаблону;

не нашли актуальное решение;

новый сотрудник долго входил в контекст;

задача вернулась из-за плохой постановки;

договор ушел без важной проверки;

команда повторила ошибку прошлого проекта;

руководитель узнал о проблеме слишком поздно.

Ассистент с доступом к source of truth, памятью и skills может снижать такие потери.

Метрики:

количество просроченных задач без комментария;

количество сделок без следующего шага;

доля задач без владельца;

число блокеров старше N дней;

количество документов по устаревшему шаблону;

число повторяющихся ошибок;

время обнаружения риска;

доля задач, прошедших проверку полноты;

количество решений, записанных в журнал.

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

Если проектный ассистент подсвечивает блокер на второй день, а не на второй неделе, он экономит не часы, а весь срок проекта.

Денежный эффект

Руководителю в итоге нужен денежный язык. Но денежный эффект не всегда появляется напрямую в первый месяц. Его можно считать через несколько мостиков.

Экономия времени

Если процесс занимал 4 часа, а стал занимать 2 часа, это можно перевести в часы команды. Но важно не обманывать себя. Сэкономленные часы не всегда превращаются в деньги автоматически.

Они превращаются в деньги, если:

команда делает больше работы тем же составом;

сокращается потребность в найме;

быстрее закрываются сделки;

быстрее выходит продукт;

меньше ошибок и переделок;

руководители тратят меньше времени на ручной контроль.

Ускорение выручки

В продажах и клиентских процессах эффект может быть связан не с экономией, а со скоростью реакции.

Например:

быстрее обработали входящий запрос;

быстрее подготовили предложение;

лучше квалифицировали лид;

не потеряли следующий шаг;

подготовили более точный ответ;

увеличили конверсию из встречи в КП.

Здесь важно смотреть не только на время, но и на движение сделки.

Снижение стоимости ошибки

Ошибка в договоре, просроченный блокер, дефект в коде, потерянная заявка, неверный счет, забытое согласование — все это имеет стоимость. Иногда ее трудно посчитать точно.

Но ее можно оценить через:

количество предотвращенных ошибок;

среднюю стоимость исправления;

время руководителя на разбор;

влияние на срок;

риск штрафа;

влияние на клиента.

Рост пропускной способности

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

Управляемость и прозрачность

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

Ассистенты и агенты, если они правильно встроены, оставляют след работы:

какие задачи выполнялись;

какие источники использовались;

какие решения были приняты;

где возникли блокеры;

какие skills применялись;

какие ошибки повторялись;

какие данные отсутствовали;

где человек подтвердил результат;

где агент остановился.

Это дает новую управленческую видимость. Руководитель видит не только итог, но и качество процесса.

Например:

какие КП постоянно требуют ручной переработки;

в каких проектах нет source of truth;

какие команды чаще всего работают без актуальных задач;

какие skills дают много ошибок;

какие процессы держатся на одном человеке;

где ИБ-блокеры появляются слишком поздно.

Такая прозрачность может быть неприятной. Она показывает не

только успехи, но и слабые места. Но именно это делает AI-Native контур управленческим инструментом, а не просто помощником для текста.

Метрики для разных ролей

CEO смотрит на:

влияние на скорость бизнеса;

пропускную способность;

качество клиентского результата;

снижение потерь;

принятие новой модели;

готовность масштабировать;

риски и безопасность;

денежный эффект.

CTO смотрит на:

архитектуру;

надежность MCP-шлюза;

права;

аудит;

качество интеграций;

стоимость моделей;

latency;

ошибки инструментов;

покрытие проверками;

возможность закрытого контура.

Владелец процесса смотрит на:

скорость конкретной работы;

качество результата;

удобство для команды;

возвраты и ошибки;

изменения в роли;

качество skills;

готовность процесса к масштабированию.

Сотрудник смотрит на:

стало ли ему проще;

убралась ли рутина;

понятны ли границы ответственности;

помогает ли ассистент делать работу лучше;

не превратился ли ИИ в дополнительную отчетность.

Если метрики видит только руководство, команда может

воспринимать их как контроль. Если метрики видит и команда, они становятся способом улучшать работу.

Базовый набор для первого пилота

Для первого 30-дневного пилота не нужен большой дашборд. Достаточно 8-12 показателей.

Например:

Контур: подготовка коммерческих предложений

Adoption:

активных пользователей в неделю - задач с использованием skill

Speed:

среднее время подготовки КП - время до первого черновика

Quality: - возвраты на доработку

прохождение quality review

Loss reduction: - КП без обязательных блоков

случаи использования устаревшего шаблона

Business: - количество КП на менеджера

конверсия в следующий шаг

Governance:

доля КП со ссылками на source of truth - ошибки ассистента, требующие изменения skill

Для проектного статуса:

Adoption:

PM, использующие status-summary skill - количество подготовленных статусов

Speed:

время подготовки статуса - время обнаружения блокера

Quality:

полнота статуса по чек-листу - количество уточнений после статуса

Loss reduction: - блокеры старше 3 дней

задачи без владельца

Governance: - решения, записанные в журнал

расхождения между памятью и source of truth

Для логистического контура:

Speed: - время от входящей заявки до первого ответа

время сбора недостающих данных

Quality: - доля заявок с полным набором полей

количество ошибок в маршруте, сроках или условиях

Loss reduction: - заявки без следующего шага

обращения, зависшие дольше SLA

Business:

конверсия заявки в заказ - количество обработанных заявок на оператора

Для нефтетрейдинга или инвестиционного анализа:

Speed:

время подготовки аналитической сводки - время проверки источников

Quality:

доля сводок со ссылками на source of truth - количество непроверенных предположений

Risk:

число выявленных ограничений до решения - число случаев, где ассистент остановился из-за недостатка данных

Business: - скорость принятия решения

доля решений, где есть сохраненный rationale

Главное — не пытаться измерить все. Нужно измерить то, ради чего запускался контур.

Как не испортить метрики

Метрики легко испортить. Первая опасность — превратить их в

отчетность ради отчетности. Если сотрудник тратит больше времени на фиксацию AI-метрик, чем экономит от ассистента, что- то пошло не так. Вторая опасность — начать мерить людей вместо процесса.

Цель первого этапа — понять, как улучшить контур, а не наказать тех, кто медленнее адаптируется. Третья опасность — выбрать метрики, на которые легко повлиять формально. Например, если премировать за количество запросов к ассистенту, люди начнут делать больше запросов. Но это не означает эффекта.

Четвертая опасность — смотреть только на экономию времени. Иногда главный эффект в качестве, снижении риска или управляемости. Пятая опасность — не учитывать стоимость внедрения.

Модели, интеграции, обучение, поддержка skills, безопасность, инфраструктура — все это имеет цену. Ее нужно видеть.

Еженедельный обзор

Метрики должны обсуждаться в коротком ритме. Для пилота достаточно одного еженедельного обзора на 30-45 минут.

Повестка:

Что было выполнено с ассистентом?
Где получилось быстрее?
Где качество выросло?
Где ассистент ошибся?
Какие данные были недоступны?
Какие skills нужно обновить?
Какие риски появились?
Что меняем на следующей неделе?

Такой обзор превращает внедрение в цикл обучения. Без него пилот распадается на отдельные впечатления.

Что сделать руководителю

Для выбранного AI-Native контура сформируйте одну страницу метрик. Не презентацию на 40 слайдов. Одну страницу.

На ней должны быть:

название контура;

владелец;

цель;

исходный замер;

3-4 метрики скорости;

3-4 метрики качества;

2-3 метрики принятия;

2-3 метрики потерь;

ожидаемый бизнес-эффект;

риски;

дата следующего обзора.

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

контур, skills, source of truth или подход к внедрению.

Вопросы для руководителя

Вы измеряете использование ИИ или изменение работы?

Есть ли исходный замер до пилота?

Какие метрики показывают скорость?

Какие метрики показывают качество?

Какие потери вы хотите снизить?

Какой денежный эффект может появиться?

Какие метрики видит команда?

Не превращаются ли метрики в лишнюю отчетность?

Есть ли еженедельный разбор ошибок ассистента?

Какие метрики помогут принять решение о масштабировании?

Главная мысль главы

AI-Native внедрение нельзя оценивать только по количеству пользователей, запросов или установленных инструментов.

Руководителю нужны метрики работы: скорость, качество, снижение потерь, бизнес-эффект, принятие командой и управляемость.

Сначала измеряйте один контур. Делайте исходный замер.

Смотрите не на активность, а на изменение процесса. Обсуждайте

метрики каждую неделю и улучшайте skills, source of truth и правила качества.

Тогда ИИ перестает быть красивым экспериментом и становится управляемым способом повышать способность компании действовать.