Эффект от внедрения ИИ измеряется сравнением показателя «до» и «после» на одном и том же процессе, и решающее условие здесь — зафиксировать показатель «до» до начала проекта. Задним числом эффект не доказывается: без исходной точки любые цифры выглядят подгонкой, и чаще всего ею и являются. Второе условие — считать экономию честно: высвобожденные часы становятся деньгами только тогда, когда превращаются либо в сокращение затрат, либо в дополнительный объём работы.
Почему замер «до» решает всё
Это самая дешёвая и самая часто пропускаемая операция во всём проекте. Занимает она немного, а её отсутствие обесценивает результат целиком.
Механика проста. После запуска решения возникает вопрос: стало лучше? Отвечать на него приходится по памяти — «кажется, раньше уходило часа два». Память в этой ситуации системно искажена: тот, кто продвигал проект, помнит, что было тяжело; тот, кто был против, помнит, что справлялись. Спор становится неразрешимым, потому что сравнивать не с чем.
Практический вывод: показатель «до» фиксируется на этапе выбора процесса, ещё до discovery. Это часть критериев отбора кандидата — процесс, для которого нельзя зафиксировать исходное значение, плохо подходит для первого проекта именно потому, что успех потом нечем будет доказать. Подробнее о критериях — в статье «Как выбрать процесс для первого ИИ-проекта».
Замерять нужно не идеальную неделю и не аврал, а обычный период достаточной длины, чтобы усреднить колебания.
Какие показатели действительно измеримы
Работают метрики, которые можно снять объективно, без опроса участников.
- Время на одну операцию. Сколько занимает обработка одного обращения, документа, заявки от поступления до готового результата.
- Доля результатов, принятых без правок. Ключевая метрика для решений, готовящих черновики: показывает, насколько система реально экономит, а не создаёт работу по исправлению.
- Доля обращений, закрытых без человека. Для систем ответов на типовые вопросы.
- Срок реакции. Время от поступления до первого ответа — часто важнее общей трудоёмкости.
- Объём, обработанный за период. Если целью был не отказ от людей, а увеличение пропускной способности.
- Доля ошибок. Обязательно вместе с остальными: рост скорости при росте ошибок — не эффект, а перенос проблемы дальше по процессу.
Общее у всех — их можно посчитать из системы или по журналу, а не выяснить у сотрудников.
Что мерить бесполезно
Абстрактную «эффективность» и «производительность» без определения, из чего они складываются. Такой показатель всегда растёт, потому что каждый считает его по-своему.
Удовлетворённость без методики. Опрос «стало ли удобнее», проведённый инициатором проекта вскоре после запуска, даёт предсказуемо положительный результат и не значит ничего.
Количество обращений к системе. Показывает активность, а не пользу. Сотрудник может обращаться к решению часто и всё равно переделывать результат вручную.
Технические метрики модели в отрыве от процесса. Точность на тестовой выборке — рабочий инструмент разработки, но не доказательство бизнес-эффекта: система может отвечать правильно и при этом не экономить ничего, если проверка ответа занимает столько же, сколько ручная работа.
Как считать экономию честно
Здесь находится главная ловушка обоснований, и о ней стоит сказать прямо, потому что именно на ней рушится доверие к проекту при разговоре с финансистом.
Расчёт обычно делается так: операция занимала 20 минут, стала занимать 5, в месяц таких операций 400 — сэкономлено 100 часов, умножаем на стоимость часа, получаем сумму. Проблема в том, что эти 100 часов физически не превратились в деньги. Зарплатный фонд не изменился, люди на месте, расходы прежние.
Высвобожденное время становится экономическим эффектом только в одном из двух случаев:
- Затраты сократились. Отказались от найма, который планировался; не продлили подряд; перераспределили людей на другой участок, закрыв потребность без расширения штата.
- Объём вырос без роста затрат. Тот же коллектив обрабатывает больше заявок, компания берёт больше заказов, отдел успевает то, до чего раньше не доходили руки.
Если ни того ни другого не произошло, эффект существует как удобство, но не как деньги. Это нормально для первого проекта — его цель в получении опыта, — но выдавать удобство за экономию не стоит: финансовый директор заметит расхождение, и пострадает доверие ко всем последующим расчётам.
Из экономии обязательно вычитаются расходы на эксплуатацию, и считать их нужно было ещё до разработки — методика в статье «Сколько стоит эксплуатация ИИ-решения». Чистый эффект — это разница, а не валовая экономия времени.
Неденежные эффекты: как их предъявлять
Часть результатов реальна, но плохо сводится к рублям: сокращение срока ответа клиенту, единообразие ответов, снижение зависимости от конкретного сотрудника, обработка того, до чего раньше просто не доходили руки, снятие рутинной нагрузки.
Такие эффекты стоит фиксировать и предъявлять — но отдельной строкой и без попытки перевести в деньги через сомнительные коэффициенты. Честная формулировка «срок ответа сократился с двух дней до двух часов, в деньгах не оцениваем» вызывает больше доверия, чем натянутая монетизация. Полагаться только на неденежные эффекты при обосновании продолжения рискованно: см. «Как обосновать внедрение ИИ перед руководством».
Метрика под тип процесса
| Тип процесса | Основная метрика | Контрольная метрика |
|---|---|---|
| Ответы на типовые вопросы | Доля закрытых без оператора | Доля ошибочных ответов |
| Обработка документов | Время на документ, доля без правок | Доля пропущенных ошибок |
| Классификация и маршрутизация | Доля верных направлений | Доля переназначений вручную |
| Подготовка черновиков | Доля принятых без правок | Время на редактирование |
| Поиск по внутренним знаниям | Время до нахождения ответа | Доля обращений к эксперту |
Контрольная метрика обязательна: без неё легко улучшить основную за счёт качества и не заметить этого.
Когда проводить замер
Не сразу после запуска. В первые недели показатели искажены в обе стороны: сотрудники осторожничают и перепроверяют всё подряд, а система работает на потоке, к которому ещё не адаптирована. Разумно дать процессу выйти на устойчивый режим и только потом снимать значение «после» за период, сопоставимый по длине с периодом замера «до».
Дальше замер становится регулярным. Это уже не доказательство эффекта, а контроль деградации: качество ИИ-решения снижается постепенно и незаметно, по мере расхождения базы знаний с реальностью — см. «Сопровождение ИИ-решений».
Частые вопросы
Что делать, если показатель «до» не зафиксирован, а проект уже запущен?
Оценить его ретроспективно по объективным следам, а не по памяти: журналы систем, даты в документах, выгрузки обращений часто позволяют восстановить исходное значение. Если следов нет, честнее признать, что точное сравнение невозможно, и измерять эффект от текущей точки вперёд. Попытка подставить правдоподобное число задним числом обычно распознаётся и подрывает доверие ко всему расчёту.
Высвобожденное время сотрудников — это экономия?
Только если оно превратилось в сокращение затрат или в дополнительный объём работы. Сами по себе освободившиеся часы не меняют расходов: зарплата выплачивается та же. Корректная формулировка звучит так: высвобождено столько-то часов, из них столько-то направлено на такую-то задачу, за счёт чего не потребовался найм. Без второй части это не экономия, а удобство.
Через какое время после запуска можно оценивать эффект?
После выхода процесса на устойчивый режим — первые недели показывают искажённую картину, потому что сотрудники перепроверяют результаты чаще обычного, а решение ещё настраивается под реальный поток. Период замера «после» должен быть сопоставим по длине с периодом замера «до», иначе сравниваются несопоставимые величины.
Какая метрика самая универсальная?
Универсальной нет, но ближе всего к ней доля результатов, принятых без доработки. Она одновременно отражает и качество, и реальную экономию: результат, который приходится переделывать, не экономит ничего, даже если получен мгновенно. Использовать её нужно в паре с метрикой ошибок, иначе можно улучшить показатель за счёт снижения требований.
Нужно ли считать ROI ИИ-проекта?
Считать полезно, но с осторожностью в первом проекте: его цель — не максимальная отдача, а получение организацией опыта, и ROI на нём обычно скромный. Разумнее считать не доходность как таковую, а срок окупаемости с учётом расходов на эксплуатацию, и отдельно фиксировать неденежные эффекты. Требовать от первого проекта впечатляющего ROI — верный способ выбрать слишком амбициозную задачу и провалить её.
Что дальше
Метрика задаётся ещё на этапе выбора процесса — «Как выбрать процесс для первого ИИ-проекта», а вычитать из эффекта нужно расходы на эксплуатацию — «Сколько стоит эксплуатация ИИ-решения». Как превратить замеры в аргументы для руководства — «Как обосновать внедрение ИИ перед руководством». Полная картина — в опорной статье «Внедрение ИИ в бизнес».
Постановка метрик и фиксация исходных значений — часть аудита процессов перед разработкой и внедрением ИИ.