Как посчитать эффект от AI-автоматизации до запуска

Эффект от AI-автоматизации до запуска считают не через обещанный процент экономии, а через сравнение двух моделей одного процесса: достоверного baseline «как сейчас» и сценария «как будет» с полной стоимостью решения, остаточным ручным трудом, рисками и диапазоном неопределённости. Итогом должен быть не один красивый ROI, а три сценария — консервативный, базовый и оптимистичный — плюс метрики пилота, которые подтвердят или опровергнут исходные допущения.

Короткий ответ: как посчитать ROI AI-автоматизации

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

Базовая формула для горизонта оценки:

ROI = (измеримый эффект − полная стоимость проекта) / полная стоимость проекта × 100%.

Для управленческого решения одной формулы мало. Нужно отдельно показать срок окупаемости, стоимость одного успешного результата, влияние на пропускную способность и чувствительность расчёта к главным допущениям. Microsoft рекомендует фиксировать телеметрический baseline до запуска, а NIST — сравнивать ожидаемые выгоды и затраты с подходящими benchmarks и учитывать стоимость ошибок. Это защищает business case от подмены реального результата количеством вызовов модели.

Как устроен расчёт: от события процесса к бизнес-результату

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

Для каждого кейса полезно собрать цепочку: входящий объём → фактические действия → ручные передачи → ожидание → решение → исправления → завершённый outcome. Данные берут из CRM, helpdesk, ERP, журналов workflow, телефонии или process mining. Опрос сотрудников дополняет картину, но не заменяет события: люди обычно хорошо помнят сложные случаи и хуже оценивают частоту типовых операций.

Microsoft в рекомендациях по baseline предлагает сохранять как минимум объём по категориям, распределение cycle time, типы ошибок, fully loaded cost на транзакцию и клиентский сигнал. Для времени важны не только средние значения: медиана показывает типичный случай, а P90 и P99 — длинный хвост, который часто создаёт очереди и нарушает SLA.

Каким должен быть baseline до запуска

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

Минимальный набор baseline-метрик:

• объём: количество входов и завершённых кейсов по типам;
• touch time: активное время сотрудников на один кейс;
• cycle time: полное время от входа до результата, включая ожидание;
• качество: доля ошибок, возвратов и повторной обработки по причинам;
• конверсия или resolution: доля кейсов, достигших целевого исхода;
• стоимость: fully loaded labor, лицензии и инфраструктура текущего процесса;
• риск: частота и тяжесть инцидентов, даже если они редки.

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

Стоимость ручного процесса: что включить

Прямой труд считают через фактический touch time, объём и полную часовую стоимость роли. Полная стоимость включает не только оклад, но и связанные расходы, принятые в финансовой модели компании. Если в процессе участвуют оператор, руководитель смены и контролёр качества, их время учитывается отдельно.

Прямой труд за период = Σ(объём сегмента × минуты работы роли / 60 × полная стоимость часа роли).

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

Экономия времени также не всегда равна экономии денег. Освободившиеся часы становятся денежным эффектом, когда компания действительно сокращает внешние расходы, избегает найма, перераспределяет людей на измеримую работу или увеличивает пропускную способность без роста штата. Если сотрудники просто получают свободное время, это полезный capacity effect, но не немедленный cash saving.

Время сотрудников: отделяйте touch time от cycle time

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

Touch time отвечает на вопрос, сколько оплачиваемой работы требуется для одного результата. Cycle time показывает, как быстро бизнес получает результат. Для клиентских процессов дополнительно отслеживают first response time; для производства контента — time to publish; для документов — время до утверждения. Оценивать только среднее опасно: улучшение медианы может сопровождаться ростом P90 из-за сложных исключений, которые система чаще передаёт людям.

Количество ошибок: учитывайте тяжесть, а не только частоту

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

AI способен сократить одни ошибки и создать другие. Например, структурированная валидация уменьшает пропуски обязательных полей, но генеративный компонент может уверенно сформировать неверный факт. Поэтому в будущем процессе нужно учитывать стоимость evaluation, выборочного контроля, human approval и расследования инцидентов. NIST прямо рекомендует измерять ожидаемые и реализованные затраты, связанные с ошибками и доверием к системе, в контексте риск-толерантности организации.

Скорость обработки: где возникает финансовый эффект

Ускорение создаёт деньги не само по себе, а через конкретный механизм. Это может быть больший throughput без найма, снижение штрафов за SLA, уменьшение незавершённой работы, более ранняя передача заявки менеджеру или сокращение времени вывода карточки на витрину. В business case нужно назвать этот механизм и источник данных.

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

Конверсия: считайте только дополнительный результат

Для заявок, поддержки и контента AI может влиять на конверсию через скорость реакции, полноту данных, персонализацию или качество следующего действия. Но сравнивать нужно сопоставимые группы. Если после запуска изменились рекламные каналы, цены, сезон или команда продаж, прирост нельзя полностью приписывать автоматизации.

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

Полная стоимость AI-решения

Стоимость будущего процесса шире цены модели. В неё входят discovery и проектирование, подготовка данных, интеграции, интерфейс, модели и API, хранение контекста, инфраструктура, наблюдаемость, evaluation, безопасность, поддержка, обновления и остаточный ручной труд. Если решение выполняет действия, добавляются журналы, approvals, восстановление после сбоя и контроль прав.

Разделите затраты на первоначальные и операционные. Первоначальные нужны для срока окупаемости; операционные — для unit economics. Часть расходов меняется с объёмом: model calls, проверки или очереди исключений. Часть остаётся условно постоянной: мониторинг, поддержка, регулярное тестирование. Google Cloud и FinOps Foundation рекомендуют связывать технические расходы с бизнес-единицей — транзакцией, обработанным кейсом или другим outcome, а не останавливаться на стоимости токена.

Расчётный пример с явными допущениями

Ниже — не обещание результата и не кейс клиента, а демонстрация структуры расчёта. Допустим, процесс обрабатывает 4000 однотипных кейсов в месяц. Активная ручная обработка занимает 9 минут, полная стоимость часа роли — 1200 ₽. Ошибки возникают в 3% кейсов, исправление занимает 20 минут.

• основной ручной труд: 4000 × 9 / 60 × 1200 = 720 000 ₽ в месяц;
• исправления: 4000 × 3% × 20 / 60 × 1200 = 48 000 ₽;
• измеримый baseline: 768 000 ₽ в месяц, без спорной оценки упущенной выручки.

Базовая гипотеза будущего процесса: 60% кейсов проходят без ручного touch, оставшиеся 40% требуют в среднем 5 минут; 10% всех кейсов дополнительно проходят трёхминутную проверку. Модель, инфраструктура, мониторинг и поддержка оценены в 170 000 ₽ в месяц. Тогда остаточный ручной труд составляет 160 000 ₽, проверки — 24 000 ₽, а будущая операционная стоимость — 354 000 ₽ в месяц.

Расчётный месячный эффект равен 414 000 ₽. При первоначальной стоимости внедрения 1,8 млн ₽ простой срок окупаемости составляет около 4,35 месяца. За 12 месяцев стоимость текущего процесса равна 9,216 млн ₽, а стоимость проекта — 1,8 млн ₽ внедрения плюс 4,248 млн ₽ эксплуатации. Расчётный ROI за год: (9,216 − 6,048) / 6,048 × 100% ≈ 52%. Этот результат полностью зависит от допущений об автономной доле, времени исключений и стоимости сопровождения, поэтому его нельзя использовать без sensitivity analysis.

Три сценария вместо одного ROI

Консервативный сценарий должен учитывать меньшую долю автоматизации, больше ручных проверок и более дорогую эксплуатацию. Базовый отражает наиболее вероятные значения, подтверждённые тестами. Оптимистичный показывает потенциал, но не должен становиться единственным основанием бюджета. GAO относит анализ чувствительности, рисков и документирование допущений к признакам надёжной оценки затрат; OECD также рекомендует пересчитывать cost-benefit модель при разных значениях неопределённых параметров.

Проверьте, какие переменные сильнее всего меняют результат. Обычно это объём, фактическая доля straight-through processing, время исключения, стоимость human review, частота критических ошибок и переменная стоимость AI. Именно эти параметры должны стать метриками пилота и порогами остановки.

Что чаще всего завышает ожидаемый эффект

• идеальный baseline: берётся нормативное время вместо реального процесса с ожиданием и исключениями;
• вся экономия времени объявляется деньгами: без плана высвобождения или использования capacity;
• игнорируется ручной хвост: сложные кейсы после AI требуют больше квалификации и времени;
• не учитывается контроль: evaluation, approvals, разбор ошибок и аудит исключены из TCO;
• выручка приписывается целиком: нет контрольной группы и окна атрибуции;
• одинаковая цена ошибки: критические инциденты растворяются в среднем error rate;
• нет резерва: интеграции, данные и сопровождение оцениваются по лучшему сценарию.

Если положительный ROI сохраняется только в оптимистичном сценарии, проекту нужен не более убедительный слайд, а более узкий scope. Иногда правильным решением становится AI-ассистент с подтверждением, а не автономный агент. Разницу между этими архитектурами подробно разбирает статья «AI-агент или обычная автоматизация».

Какие метрики подтверждают эффект на пилоте

Пилот должен проверять допущения financial model на одинаковой единице результата. Нельзя признать успехом красивый ответ модели, если не измерена доля завершённых кейсов, ручной touch и стоимость исключений. AWS рекомендует связывать технические метрики с business outcomes и отслеживать ROI как динамический показатель, поскольку расходы и ценность меняются вместе с объёмом, поведением пользователей и качеством модели.

Основной набор:

• straight-through processing — доля кейсов без ручного вмешательства;
• touch time и cycle time: медиана, P90 и P99;
• доля исключений, retries и tool failures;
• ошибки по тяжести и стоимость исправления;
• acceptance rate рекомендаций и override rate;
• стоимость модели, инфраструктуры и проверки на успешный outcome;
• изменение бизнес-KPI: resolution, конверсия, SLA или throughput;
• фактическое использование высвобождённой capacity.

Пошаговый план расчёта до старта

1. Зафиксировать outcome и границы. Владелец процесса описывает начало, конец, сегменты и исключённые участки.
2. Собрать исходные события. Аналитик выгружает объём, время, ошибки, handoff и результаты за репрезентативный период.
3. Посчитать unit cost baseline. Финансы подтверждают стоимость ролей, систем, исправлений и правила монетизации.
4. Спроектировать будущий процесс. Архитектор разделяет автоматические шаги, AI-решения, проверки и fallback.
5. Оценить полный TCO. Включаются внедрение, данные, интеграции, AI, инфраструктура, контроль и сопровождение.
6. Собрать три сценария. Для ключевых допущений задаются консервативные, базовые и оптимистичные значения.
7. Определить метрики пилота. Каждое важное допущение получает источник данных и порог приемки.
8. Утвердить правила решения. Заранее фиксируются условия масштабирования, доработки или остановки.

Перед расчётом полезно проверить, действительно ли выбран правильный процесс: для этого используйте материалы «Какие процессы автоматизировать первыми» и «Как найти узкие места». Архитектуру лучше строить по process-first подходу, а риски пилота сверить с разбором ошибок внедрения ИИ. Контроль расходов уже работающей production-системы — отдельная задача и не подменяет расчёт business case до запуска.

Частые вопросы

Можно ли посчитать ROI, если ещё нет точной цены модели?

Да. Используйте диапазон переменной стоимости и пересчитайте консервативный, базовый и оптимистичный сценарии. Если решение перестаёт быть выгодным при небольшом росте цены, business case слишком чувствителен.

Какой период брать для baseline?

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

Считать ли высвобождённые часы экономией?

Только если есть понятный способ превратить их в снижение расходов, предотвращённый найм, дополнительный throughput или другую измеримую ценность. Иначе это capacity effect, а не cash saving.

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

Через дополнительную маржу сопоставимых групп и заранее определённое окно атрибуции. Нельзя приписывать автоматизации всю выручку процесса.

Что важнее: ROI или срок окупаемости?

Показатели отвечают на разные вопросы. ROI сравнивает эффект с затратами на горизонте, а payback показывает, когда накопленный эффект покроет первоначальное вложение.

Нужно ли включать стоимость ошибок?

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

Когда расчёта недостаточно и нужен пилот?

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

Когда проект лучше не запускать?

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