KPI для ИИ-проекта держатся на одном вопросе: что у отдела стало лучше после внедрения. Вопрос звучит так: сколько времени сэкономил сотрудник и насколько быстрее закрывается задача — вместо подсчёта обработанных моделью запросов. Метрики ставят до старта, чтобы было с чем сравнивать. Сам ИИ под капотом — обычная языковая модель, встроенная в процесс отдела.
Главный принцип
KPI для ИИ-проекта мерят пользу для отдела вместо активности модели. Базовые метрики: сэкономленное время сотрудника, скорость закрытия задачи, доля задач без участия человека и качество результата. Цифры снимают до внедрения и сравнивают через месяц. Опасная ловушка — гнаться за объёмом обработанных запросов вместо реальной отдачи.
Руководители часто ставят ИИ-проекту красивые, но пустые метрики: «модель обработала 10 000 запросов». Это число молчит о пользе. Можно обработать десять тысяч запросов плохо и потратить на исправления больше времени, чем сэкономили. Правильный KPI отвечает на вопрос владельца: стало ли отделу легче работать и где это видно в деньгах или во времени.
Я всегда начинаю с замера «до». Прежде чем внедрять модель в отдел, мы фиксируем текущие цифры: сколько времени уходит на типовую задачу, сколько задач сотрудник закрывает за день, сколько обращений висит в очереди. Без этого замера любая метрика после внедрения повисает в воздухе без точки отсчёта для сравнения. Половина проваленных проектов проваливается именно здесь: внедрили, а доказать пользу нечем.
Хороший KPI привязан к процессу вместо технологии. Отделу безразлично, какая модель внутри и сколько токенов она тратит. Отделу важно, что заявка теперь обрабатывается за пять минут вместо тридцати, а сотрудник успевает заняться сложными случаями. Метрику формулируют на языке отдела, чтобы её понимал и руководитель, и сам сотрудник.
- Сэкономленное время: сколько часов в неделю освободилось у сотрудника
- Скорость задачи: за сколько закрывается типовое обращение или документ
- Доля автономной работы: какой процент задач закрывается без человека
- Качество: доля результатов, которые ушли без правок и без жалоб
Метрики по отделам
Каждый отдел измеряют своими цифрами, потому что результат у всех разный. Поддержке важна скорость и доля закрытых обращений, продажам — конверсия и скорость ответа лиду, кадрам — время на обработку откликов, финансам — точность разбора документов. Универсального KPI нет, но логика общая: берём ключевую боль отдела и меряем, насколько модель её сняла.
| Отдел | Что мерить | Как считать |
|---|---|---|
| Поддержка клиентов | Скорость ответа и доля закрытых без человека | Среднее время до ответа и процент обращений, закрытых моделью |
| Отдел продаж | Скорость реакции на лид и конверсия | Минуты до первого ответа и доля лидов, дошедших до сделки |
| Кадры | Время на обработку отклика | Часы на разбор воронки откликов до и после внедрения |
| Финансы и бухгалтерия | Точность разбора документов | Доля счетов и актов, распознанных без ручной правки |
Важно мерить и обратную сторону — качество, помимо одной скорости. Поддержка может отвечать мгновенно, но при четверти неверных ответов такой KPI вреден. Поэтому к каждой метрике скорости добавляют метрику качества: доля ответов без жалоб, доля документов без правок, доля результатов, которые сотрудник принял без переделки. Скорость без качества создаёт иллюзию прогресса при росте скрытых проблем.
Российские отделы упираются в простую вещь: данные для замера часто отсутствуют как класс. Время, которое кадровик тратит на отклик, обычно остаётся неизмеренным. Поэтому первый шаг внедрения — наладить хотя бы грубый учёт текущих цифр. Достаточно недели наблюдений, чтобы получить точку отсчёта, от которой считают отдачу проекта.
Как ставить метрики
Метрики ставят до запуска, причём заранее. Сначала фиксируете текущее состояние отдела, потом внедряете модель на узкий процесс, через месяц сравниваете. Так вы получаете честную картину отдачи вместо ощущений. Ниже порядок, по которому я обычно выстраиваю KPI для отдела перед стартом проекта.
- Выберите один процесс отдела, который сильнее всего грузит сотрудников
- Зафиксируйте текущие цифры до внедрения: время на задачу, объём, доля ошибок
- Сформулируйте 2-3 метрики на языке отдела: скорость, объём, качество
- Поставьте реалистичную цель на месяц, опираясь на замер «до» вместо фантазий
- Запустите модель на узкий процесс и собирайте те же цифры еженедельно
- Через месяц сравните и решите: расширять процесс, дорабатывать или останавливать
Двух-трёх метрик на отдел достаточно: одна про скорость, одна про объём, одна про качество. Десять метрик размывают фокус, и команда перестаёт понимать, за что она отвечает. Лучше мерить три цифры честно, чем десять для галочки.
Опасные ловушки
Главная ловушка — гнаться за метриками активности модели вместо отдачи отдела. «Модель обработала столько-то запросов», «сгенерировала столько-то текстов» — эти цифры тешат самолюбие, но о пользе молчат. Руководителю важно одно: сколько времени и денег это сэкономило и стало ли качество хуже. Активность модели описывает затраты, тогда как KPI описывает результат.
Скорость без качества опаснее медленной работы. Если поддержка отвечает мгновенно, но треть ответов модель выдумала, вы получаете рост жалоб и падение доверия при красивом KPI по скорости. Каждую метрику скорости держите в паре с метрикой качества. Это свойство языковых моделей — отвечать уверенно даже на пустом месте.
Вторая ловушка — ставить цели из воздуха. «Сократим время обработки в десять раз» звучит красиво на презентации и убивает проект на старте, когда реальность даёт сокращение в два раза. Цель опирается на замер «до» и на здравый смысл, вместо желания впечатлить руководство. Лучше поставить достижимую планку и перевыполнить, чем красивую и провалить.
- Активность модели вместо отдачи: число запросов молчит о пользе
- Скорость без качества: быстрые, но неверные ответы хуже медленных верных
- Цели из воздуха: планку ставят от замера «до» вместо фантазий
- Метрики без владельца: за каждую цифру отвечает конкретный человек
Отдельно держите в голове, что часть пользы плохо ложится в цифры. Сотрудник перестал выгорать от рутины, новичок адаптируется быстрее, эксперт освободился для сложных задач — это реальная отдача, которую трудно выразить одним числом. Учитывайте её, даже если её сложно посчитать. Цифры дают каркас оценки, а полную картину видит руководитель, который смотрит на отдел целиком.
Куда двигаться
Когда метрики на первом отделе выстроены и проект показал отдачу, ту же схему переносят на соседние участки. Замер «до», узкий процесс, две-три честные метрики, сравнение через месяц. Так компания получает понятную систему оценки вместо разрозненных внедрений: видно, какой отдел дал отдачу, а где модель пока буксует и нужна доработка.
Со временем у руководителя складывается общая картина: сколько суммарно времени освободил ИИ по всем отделам и где это превратилось в деньги. Этот навык измерять отдачу остаётся с компанией и помогает решать, куда вкладывать дальше. Без него внедрение ИИ превращается в трату ради моды, с ним — в управляемые инвестиции с понятной отдачей.
Сложность здесь в том, чтобы выбрать честные метрики и удержаться от красивых пустых цифр. Самый частый провал — отдел рапортует о тысячах обработанных запросов, а руководитель так и остаётся в неведении, стало ли лучше. На разборе процессов мы вместе смотрим на ваши отделы и подбираем по две-три метрики, которые честно покажут отдачу от ИИ.