Оценка эффективности внедрения ИИ: затраты и результат пилота по данным

Пилот запущен, бот отвечает, сотрудники показывают удачные диалоги — но руководитель всё ещё не знает, стал ли процесс выгоднее. Для ответа нужно сравнить пилот с тем, что происходило бы без ИИ, проверить качество и учесть все дополнительные расходы автоматизации.

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

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

Как сформулировать проверяемую цель пилота

Цель описывает изменение рабочего процесса и деловой результат. Формулировка «бот отвечает клиентам» сообщает только о наличии функции. Она не показывает, верны ли ответы, сколько работы осталось человеку и изменились ли расходы.

Рабочая цель может звучать так: «На сопоставимых обращениях сократить трудозатраты на подготовку результата, сохранить долю задач без критической ошибки не ниже согласованного порога и определить экономический результат после дополнительных расходов пилота».

До запуска заполните карточку:

Для фиксированного маршрута может хватить обычной интеграции. Бот даёт пользователю диалоговый вход. ИИ-агент выбирает следующий шаг и разрешённый инструмент в заданных границах. Эти форматы создают разные расходы и требуют разных проверок.

Какие показатели собирать

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

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

Для каждой метрики запишите формулу, единицу, знаменатель, источник, периодичность и владельца. Для экономической строки укажите статус: денежный расход, высвобождённое время, потенциальная выручка или потенциальная маржинальная прибыль. Это не взаимозаменяемые результаты.

Как измерить исходный уровень и сравнение

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

Сопоставимые периоды и выборки

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

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

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

Что менялось кроме автоматизации

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

Для числового сравнения подходит поправка: эффект пилота = изменение в пилотной группе − изменение в контрольной группе. Она не устраняет все различия, но отделяет часть результата, которая могла возникнуть без автоматизации.

Как посчитать затраты и экономический результат

Сначала выберите одну базу сравнения и не меняйте её внутри расчёта. В приростном подходе базой служит процесс без ИИ. В затраты пилота входят только расходы, которые появились или выросли из-за автоматизации.

Разработка, эксплуатация и ручная проверка

Формула за период:

дополнительные расходы пилота = разработка за период + API и инфраструктура + дополнительная поддержка + дополнительное обучение + дополнительные простои + стоимость неуспешных попыток и исправлений, ещё не учтённых в трудозатратах нового процесса.

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

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

Высвобождённое время и денежная экономия

Разделите результаты.

Высвобождённая мощность:

высвобождённая мощность, часы = трудозатраты базового процесса − трудозатраты процесса с ИИ.

При необходимости её можно оценить в деньгах:

оценочная стоимость мощности = высвобождённые часы × полная стоимость часа × коэффициент полезного использования.

Это управленческая оценка, а не подтверждённая экономия. Зарплата сохраняемых сотрудников не становится денежной экономией только потому, что освободилось время.

Денежная экономия:

денежная экономия = фактически устранённые денежные расходы базового процесса.

Кассовый результат:

кассовый результат = фактически устранённые денежные расходы базового процесса − дополнительные денежные расходы пилота.

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

Потенциальную выручку рассчитывают как ожидаемое число дополнительных продаж × средний чек. Потенциальную маржинальную прибыль рассчитывают отдельно: потенциальная выручка × маржинальность. Состоявшиеся продажи позволяют оценивать фактическую дополнительную выручку, если обоснована её связь с пилотом. Ни один из этих показателей не следует включать в денежную экономию.

Как учитывать скрытые потери

В журнал нужно включить не только счёт за модель:

• повторные попытки после сбоя;
• недостоверные ответы;
• ручную эскалацию и ожидание ответственного;
• исправление записей в CRM, таблице или документе;
• простой и возврат к ручной работе;
• обучение пользователей и обновление инструкций;
• время сотрудника, который поддерживает решение;
• зависимость от единственного человека, понимающего настройки.

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

Учебный расчёт и чувствительность результата

Все числа и результаты ниже — синтетический учебный пример. Это не файл, клиентский кейс, тариф, проведённый тест, ROI или результат Switch On AI. Значения нужны только для демонстрации формул.

Формула с открытыми допущениями

Генеральная совокупность пилота — 1 000 входящих задач месяца. У них три взаимоисключающих маршрута:

1. 700 задач завершены ИИ и проверены человеком.
2. 200 задач сразу переданы на ручную обработку.
3. Для 100 задач попытка ИИ не удалась, после чего их обработал человек.

До пилота ручная обработка занимала 10 минут на задачу: 1 000 × 10 / 60 = 166,7 часа.

Трудозатраты процесса с ИИ:

• проверка 700 результатов: 700 × 3 / 60 = 35 часов;
• ручная обработка 300 задач: 300 × 10 / 60 = 50 часов;
• разбор 100 неуспешных попыток: 100 × 8 / 60 = 13,3 часа;
• внутренняя поддержка: 12 часов.

Итого новый процесс потребовал 110,3 часа. Предварительно высвобождено 166,7 − 110,3 = 56,4 часа.

Контрольная группа без ИИ ускорилась с 10 до 9,5 минуты на задачу после обновления инструкции. При пересчёте на 1 000 задач это изменение составляет 8,3 часа. Скорректированное высвобождение без промежуточного округления — 48 часов.

Остаточные 110,3 часа уже включают ручную проверку, обработку после сбоев и внутреннюю поддержку. Их стоимость не вычитается повторно из оценки высвобождённой мощности.

Качество процесса проверили на синтетической выборке из 200 исходных задач каждой группы. В пилоте приемлемый итог получили 188 задач: 188 / 200 = 94%. В контроле — 190 задач: 190 / 200 = 95%. До запуска условно установили порог не ниже 93% и отставание от контроля не более двух процентных пунктов. Порог вымышлен и не подходит для реального процесса без отдельного утверждения.

Дополнительные денежные расходы пилота:

• доля разработки за период — 30 000 ₽;
• API — 12 000 ₽;
• инфраструктура — 8 000 ₽;
• внешняя поддержка — 20 000 ₽.

Всего: 30 000 + 12 000 + 8 000 + 20 000 = 70 000 ₽. Внутренние 12 часов поддержки уже входят в трудозатраты нового процесса. Дополнительной оплаты за них в примере нет, поэтому в 70 000 ₽ они не добавляются.

Высвобождённая мощность. Условная полная стоимость часа — 800 ₽, коэффициент полезного использования — 0,75. Оценочная стоимость мощности: 48 × 800 × 0,75 = 28 800 ₽. Сравнительный результат мощности после дополнительных расходов пилота: 28 800 − 70 000 = −41 200 ₽. Это управленческая оценка, а не денежная экономия.

Кассовый результат. В примере не сократились оплачиваемые часы, штат, сверхурочные или платежи подрядчикам базового процесса. Фактически устранённые расходы равны 0 ₽. Кассовый результат: 0 − 70 000 = −70 000 ₽.

Потенциальная выручка. В примере не заданы ни ожидаемое число дополнительных продаж, ни средний чек. Поэтому формула численно не применяется, результат — «не рассчитано». Потенциальная маржинальная прибыль также не рассчитана. Эти показатели не входят в оценочную стоимость мощности или кассовый результат.

Журнал допущений:

Перед утверждением расчёта ответьте на четыре вопроса: какие часы высвободились; какие расходы действительно исчезли; какие новые платежи вызвал пилот; не учтены ли одни и те же часы одновременно как остаточный труд, расход и эффект.

Чувствительность к ошибкам и нагрузке

В учебной модели скорректированное высвобождение равно 60 × N / 1 000 − 12 часов, где N — число задач. Дополнительные расходы пилота равны 58 000 + 12 × N. Коэффициент использования мощности остаётся 75%, а фактически устранённые расходы — 0 ₽.

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

Как организовать сбор метрик в рабочем процессе

Назначьте идентификатор каждой исходной задаче и записывайте события: поступление, попытку обработки, результат ИИ, ручную проверку, исправление, эскалацию и завершение. Повторные попытки должны относиться к исходной задаче и содержать причину неуспеха.

Учебная последовательность сбора выглядит так:

1. Рабочая система создаёт событие с идентификатором задачи.
2. Интеграция или программный бот добавляет статусы попыток и передачи человеку.
3. Журнал связывает события с одной исходной задачей.
4. Выгрузка сопоставляет результат, трудозатраты и расходы.

В проекте на n8n согласованный сценарий может передавать события между системами и записывать статусы. Программный бот может фиксировать сообщения, результат операции и передачу человеку. Конкретный состав событий, доступные подключения и способ хранения нужно проверять для выбранной версии и среды. Это пример проектирования, а не описание личного запуска или реализации конкурента.

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

Полнота журнала — самостоятельный критерий: задачи с полным набором обязательных событий / все исходные задачи. Если журнал неполон, расчёт качества, времени и затрат нельзя считать надёжным. Владелец процесса отвечает за смысл данных, технический владелец — за доставку событий, владелец бюджета — за расходы.

Для настройки измеримого процесса можно сравнить направления Switch On AI. Состав решения зависит от операции: иногда нужен ИИ-агент, иногда бот, а иногда достаточно фиксированной интеграции.

Ошибки оценки и решение по пилоту

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

Правило решения утверждают до запуска:

• Продолжить — качество процесса проходит порог, журнал полон, скрытые потери учтены, а выбранный показатель — кассовый результат или стоимость высвобождённой мощности — соответствует заранее принятому правилу.
• Доработать — причина отклонения локализована, изменение можно проверить на новой сопоставимой выборке, а ожидаемое снижение приростных расходов или ручного труда записано как допущение.
• Остановить — качество неприемлемо, журнал не позволяет восстановить результат либо кассовый результат отрицателен и высвобождённая мощность не оправдывает дополнительные расходы пилота по заранее принятому правилу.

В синтетическом примере качество проходит условный порог, но оценка мощности и кассовый результат отрицательны. По заданному правилу текущую конфигурацию следует остановить. Перед новой попыткой можно изменить границы задачи, дополнительные расходы эксплуатации или объём ручной проверки, а затем повторить сравнение.

Switch On AI может помочь описать процесс, выбрать между ИИ-агентом, ботом и обычной интеграцией, определить метрики и подготовить состав пилота. Чтобы обсудить аналогичную карточку измерения для своей операции, отправьте через контакты обезличенный пример задачи, текущий порядок работы и желаемый результат. Пароли, ключи и персональные данные для первого разговора не нужны.