Формула «часы × ставка» создана для RPA и занижает ценность AI-агентов. Что измерять вместо неё и как заложить расходы в бизнес-кейс.
AWS опубликовал фреймворк для AI-центров компетенций: как строить бизнес-кейс агентной автоматизации.
Авторы исходят из того, что стандартная формула «сэкономленные часы × стоимость труда - стоимость разработки»
Я согласен с диагнозом и иду дальше: агентный проект оценивают по изменению бизнес-метрики, а часы остаются побочным показателем.
RPA-робот повторяет клики человека по фиксированному сценарию.
Заменённый клик легко посчитать: сколько операций в месяц, сколько минут на каждую, какая ставка у сотрудника.
Результат процесса остаётся прежним, стоимость его выполнения падает. Для RPA такая формула работала. Агент устроен иначе.
Он рассуждает над задачей, выбирает инструменты, обрабатывает исключения, которые сценарий не предусматривал.
Он берёт на себя куски работы, которые раньше не автоматизировали вообще: разбор нестандартного письма, сверку договора с регламентом, подготовку ответа клиенту по трём источникам. Часов, потраченных на такую работу раньше, нет: её либо не делали, либо делали выборочно.
Формула считает здесь ноль и занижает проект.
Авторы AWS указывают на ценность, которую агенты создают помимо экономии времени. Я группирую её в четыре статьи, и у каждой есть своя метрика. Скорость цикла. Заявка, которая раньше два дня ждала в очереди между отделами, обрабатывается за минуты.
Здесь работают метрики времени до результата: срок согласования, срок выхода продукта, срок ответа клиенту.
Для нас это TTU, time to use: ценность инструмента измеряется скоростью, с которой он даёт результат.
Впечатляющая архитектура в эту оценку не входит. Качество и ошибки.
Агент проверяет каждую позицию, а человек при нагрузке проверяет выборку.
Стоимость пропущенной ошибки в договоре, в карточке товара или в отчётности может превышать годовую зарплату операциониста.
Её считают через долю брака и цену инцидента. Охват. Задачи, до которых не доходили руки, начинают выполняться.
Это новая выручка или снятый риск, и в калькуляторе часов для них нет строки. Масштаб без найма.
Рост объёма в два раза не требует удвоения штата.
Измеряется это стоимостью обработки единицы работы при растущем потоке.
В RPA-кейсе расходы заканчивались разработкой робота и его поддержкой. У агента добавляются статьи, которые легко пропустить: стоимость токенов и вызовов модели, оценка качества ответов, контроль доступа, наблюдаемость, человек в контуре для спорных случаев. Если в бизнес-кейс заложена только разработка, через полгода проект выглядит убыточным, хотя его неправильно посчитали.
Чтобы ценность поддавалась измерению, агент должен оставлять следы.
1. Базовая линия до запуска. Срок, долю ошибок и стоимость единицы работы фиксируют за месяц-два до внедрения.
Без этого сравнивать не с чем. 2. Единый слой интеграции.
В AI-native integration такой слой строится на MCP-серверах и очередях вроде Apache Kafka, и каждое действие агента попадает в журнал. 3. Шлюз к моделям.
Через LLM & Security Gateway проходят все запросы: там считаются токены и деньги по каждому процессу, вырезаются персональные данные, применяются политики доступа.
Из этих данных складывается статья расходов в кейсе. 4. Заземление ответов. Агент отвечает со ссылкой на
. Qlik Answers на Amazon Bedrock строится вокруг этого требования: сотруднику нужен ответ, который можно проверить, и в регулируемой среде ответ без источника обычно не пускают в работу.
Мы закрываем это через RAG, где каждый вывод агента привязан к документу.
Оркестрацию простых процессов мы нередко собираем на n8n, а сложные интеграции строим на Python и корпоративных шинах.
Выбор зависит от числа систем в процессе и от требований к аудиту.
Как проверять кейс до выделения бюджета: - выбрать одну метрику, которую видит финансовый директор: срок, брак или стоимость единицы работы; - зафиксировать её текущее значение; - договориться, какое значение через квартал считается успехом; - заложить в расходы модели, оценку качества и контроль доступа; - решить заранее, при каком результате проект закрывается. Последний пункт самый неудобный. Без порога закрытия команда годами показывает пилот на конференциях, а метрика остаётся прежней.
Часы сэкономленного труда подходили роботам, которые повторяли клики.
Агенты меняют сам процесс, и оценивать их нужно по результату этого процесса.
Заказчик платит за результат, а AI-проект без сдвига метрики превращается в театр, за который в итоге спрашивают с тех, кто его запустил.
Простой интерфейс, в котором сотрудник задаёт вопрос и получает проверяемый ответ, держится на сложной инженерии: интеграциях, шлюзе, журнале действий.
Эта инженерия и делает результат измеримым.
AWS Machine Learning Blog, «Beyond hours saved: Building the business case for agentic automation»: https://aws.amazon.com/blogs/machine-learning/beyond-hours-saved-building-the-business-case-for-agentic-automation/. Дополнительно: «How Qlik built grounded, enterprise-scale AI with Amazon Bedrock» на том же блоге.
