Как измерить пользу пилота ИИ, если нет готовой аналитики
Журнал задач и формула полной стоимости принятого результата: как сравнить работу до и с ИИ, учесть проверку, ошибки и решить судьбу пилота.
Если в компании нет отчёта по процессу, начните с простого журнала. Возьмите одинаковый тип задач, запишите полное время работы человека до пилота и с ИИ, а затем сравните стоимость одного результата, который ответственный сотрудник действительно принял. Добавьте время проверки, исправлений, передачи сложного случая человеку и расходы на сервис. Скорость первого ответа модели сама по себе не показывает пользу бизнесу.
Этот способ подходит владельцу небольшой команды, который проверяет конкретную операцию: подготовку ответа на заявку, разбор входящего письма или черновик документа. Для финансового решения рядом с временем нужно видеть качество и цену ошибки. Никакая таблица не заменяет ответственного за приёмку.
Сначала определите единицу результата
Не сравнивайте «сколько текстов написал ИИ» с «сколько писем обработал сотрудник». Выберите одну единицу, например ответ на обращение, проверенный и пригодный к отправке. Запишите критерии приёмки: верные факты, нужные поля, корректный тон, отсутствие неразрешённых обещаний, понятная передача человеку в исключениях. Сотрудник отмечает «принято», «исправлено» или «отклонено»; спорные случаи решает владелец процесса.
Зафиксируйте границы теста: один канал, один тип обращений, одинаковые часы работы и схожая сложность. Если в одной группе только простые вопросы, а в другой возвраты и претензии, разница во времени мало что скажет об ИИ. NIST рекомендует оценивать систему в условиях, похожих на её применение, и документировать выбранные метрики; это методический ориентир, а не обязательная для бизнеса схема.
Соберите базовую линию вручную
Возьмите небольшой набор последовательных задач до пилота. Для старта можно записать 10–20 случаев, но это не статистическая гарантия: при большом разбросе или редких дорогих ошибках потребуется больше наблюдений и отдельная проверка. Не отбирайте только удобные примеры. Для каждой задачи фиксируйте время от начала работы до принятого результата, включая поиск информации, согласования и исправления.
Сохраните тот же журнал для пилота. Важно разделить время ИИ и время людей: подготовка задания, проверка фактов, правка, перенос в CRM и эскалация тоже стоят денег. Отмечайте дату, тип задачи и причину отклонения. Работайте на разрешённых или обезличенных данных, пока условия обработки и доступы не проверены.
Для честного сравнения не меняйте одновременно всё: если вместе с ИИ появилась новая база знаний, другой сотрудник и новые правила распределения заявок, результат нельзя приписать только помощнику. Укажите эти изменения рядом с журналом. Если поток зависит от дня недели, сравните похожие дни или запишите это ограничение в выводе. Базовая линия нужна как ориентир для решения, а не как лабораторное доказательство причинности.
| Поле журнала | До пилота | С ИИ | Как заполнять |
|---|---|---|---|
| ID и тип задачи | Без персональных данных в общей таблице | ||
| Сложность: обычная / исключение | По одному правилу в обеих группах | ||
| Работа сотрудника, мин | Подготовка, поиск, ответ | ||
| Проверка и исправления, мин | Включая повторный запуск и согласование | ||
| Передача человеку, мин | Время передачи и доработки | ||
| Результат принят? | Да / нет и причина | ||
| Ошибка с расходом | Только фактический расход, без придуманной оценки |
Таблицу можно скопировать в электронную таблицу или вести на бумаге. Храните первоначальные записи: без них сложно объяснить, почему расчёт изменился после исправлений.
Считайте стоимость принятого результата
Для каждого периода сложите всё время людей по выбранным задачам. Разделите его на число принятых результатов. Затем добавьте прямые расходы на ИИ за тот же период: подписку или расход по API, настройку и интеграцию в доле, относящейся к пилоту. Не складывайте минуты и рубли без перевода; если нужен денежный итог, умножьте часы людей на внутреннюю стоимость часа, заранее согласованную с бухгалтерией или владельцем.
Формула: (часы людей × стоимость часа + прямые расходы на пилот + фактические расходы от ошибок) / число принятых результатов.
Отдельно покажите долю принятых результатов, число отклонений и эскалаций. Дешёвый результат не является успехом, если качество снизилось ниже допустимого уровня. Метод NIST также предлагает подбирать метрики под существенные риски и сравнивать состояние до и после внедрения.
Если прямые расходы оплачены сразу за месяц, а тест длится неделю, запишите правило распределения заранее: например, фактически использованную долю или весь платёж, если подписка куплена только ради пилота. Для единовременной настройки покажите оба взгляда — стоимость только текущего теста и стоимость при ожидаемом объёме за несколько месяцев. Не маскируйте разовый расход делением на гипотетические тысячи задач.
Учебный расчёт, не клиентский кейс и не прогноз. Допустим, до пилота 12 принятых ответов заняли 6 часов человека при внутренней оценке 800 ₽/час: 4800 ₽, или 400 ₽ на результат. Во время пилота 12 принятых ответов потребовали 3 часа подготовки, проверки и исправлений; сервис стоил 1200 ₽ за учитываемый период, других расходов не было. Получается (3 × 800 + 1200) / 12 = 300 ₽ на принятый ответ. Разница — 100 ₽ в этом наборе, но она не доказывает экономию на будущем потоке. Если настройка заняла ещё 4 часа, а её не учли, вывод поменяется. Если один ответ оказался ошибочным и потребовал компенсации, её фактическую стоимость тоже надо добавить.
Заранее запишите решение по итогам
До теста владелец процесса фиксирует пороги: минимально допустимое качество, максимальную долю передач человеку, предельную стоимость результата и ошибки, при которых пилот останавливается немедленно. Например, неверное обещание клиенту не следует «усреднять» с десятью быстрыми ответами. Значения порогов зависят от процесса; универсального безопасного процента нет.
После пилота возможны три решения:
- Продолжить: качество прошло пороги, стоимость принятого результата ниже или появилась другая измеримая польза, а выборка покрывает обычные и сложные случаи.
- Изменить сценарий и повторить тест: ошибка сосредоточена в определённом типе задач, базу знаний можно исправить, а права и объём работы остаются контролируемыми.
- Остановить: цена ошибки неприемлема, проверка съедает эффект, данные нельзя безопасно передать или контроль отсутствует. В этом случае возможны обычные CRM-правила, шаблон или изменение процесса без ИИ.
Даже удачный пилот не гарантирует прежних результатов на большем потоке. Запланируйте периодический контроль качества и возможность вернуть задачу человеку: NIST отдельно описывает мониторинг и действия при новых рисках. Чтобы проверять поведение помощника последовательно, подготовьте набор из десяти реальных сценариев с эталоном и условиями остановки.