Как измерить эффект от внедрения ИИ

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

Самая частая ошибка выглядит так: «модель пишет черновик за минуту вместо получаса, экономим 29 минут на письмо, умножаем на количество писем». Это не эффект, это оценка — и она почти всегда завышена.

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

Три причины, и все три проверяются на месте.

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

Появился новый шаг — проверка. Черновик надо прочитать и принять. На типовых текстах это быстро, на сложных — сопоставимо с написанием. Из «29 минут экономии» надо вычесть проверку, и остаток бывает отрицательным.

Освободившееся время не собирается. Полчаса, распределённые по десяти задачам за неделю, не превращаются ни в какой видимый ресурс.

Что снимать до запуска

Четыре числа, полдня работы. Без них измерения потом не будет — только ощущения.

Срок прохождения. От появления задачи до готового результата. Медиана и худшие десять процентов; среднее скрывает как раз то, что болит.

Доля возвратов. Сколько результатов отправляют на переделку. Это то число, которое чаще всего портится при внедрении, — и его единственный шанс быть замеченным в том, что оно снято заранее.

Объём. Сколько таких задач в неделю. Определяет, окупится ли вообще.

Кто принимает. Не метрика, но без ответа остальные числа не с кем сверять.

Три числа в работе

Срок прохождения — та же метрика, что снимали до. Единственная, которая отвечает на вопрос «стало ли лучше».

Доля возвратов. Если срок упал, а возвраты выросли, вы переложили работу дальше по цепочке, а не убрали её.

Полная стоимость. Токены, ретраи, время проверяющего, поддержка при смене модели у провайдера. Считать надо не тариф, а стоимость задачи целиком.

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

Чего мерить не стоит

Число обращений к модели. Растёт от чего угодно, не значит ничего.

Удовлетворённость сотрудников на старте. В первый месяц она высокая у всех — это реакция на новизну, а не на пользу.

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

Экономию, посчитанную умножением. «Полчаса × 200 писем» — это не измерение, это гипотеза, которую и надо проверять сроком прохождения.

Условие несогласия

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

Измерение окупается примерно там же, где окупается внедрение: когда задача повторяется достаточно часто, чтобы разница накапливалась.

Чего я делать не стал бы

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

Не стал бы считать эффектом высвобожденное время, пока не названо, чем оно занято. Иначе экономия существует в презентации и не существует в отчётности.

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

Открытый вопрос

Самое ценное почти не поддаётся измерению. Когда исполнитель перестаёт откладывать неприятную задачу, потому что начать теперь легко, — это меняет срок сильнее любой экономии минут. Но проявляется как «стало меньше просрочек», и отделить этот эффект от сезонности или смены руководителя нечем.

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