Экономический эффект от LLM-ассистента: как посчитать

Что именно считаем и зачем

Экономический эффект от LLM-ассистента считают не ради красивой цифры. Расчет нужен, чтобы принять практичное решение: запускать ли пилот, какой бюджет закладывать и какие KPI реально улучшатся - и в какие сроки.

Руководству обычно важны простые ответы:

• Когда окупится внедрение (и какой горизонт смотреть: 3, 6, 12 месяцев).
• Во сколько обойдется эксплуатация, а не только запуск.
• Какие показатели улучшатся: скорость, качество, нагрузка на команду, число ошибок.
• Что будет считаться успехом пилота, а что - поводом остановиться.

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

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

• Время: сколько часов экономится у сотрудников.
• Качество: насколько ответы и результаты стали точнее и полезнее.
• Обращения: сколько запросов уходит в самообслуживание и не попадает к людям.
• Ошибки: как меняется частота промахов, переделок, инцидентов и связанных затрат.

Когда эти метрики переведены в деньги и сопоставлены с затратами (инфраструктура, поддержка, обновления), появляется честный ROI, а не ощущение «стало лучше».

С чего начать: выбрать процесс и собрать базовые данные

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

Выберите процесс и сузьте его до конкретного потока работ. Например: внутренняя IT-поддержка (сброс пароля, доступы, типовые ошибки ПО), HR (справки, отпуска, адаптация), бухгалтерия (платежные вопросы), закупки (статусы заявок), поддержка клиентов.

В компании-производителе и системном интеграторе вроде GSE.kz часто хорошо стартует IT-служба или внутренние заявки по оборудованию: вопросы повторяются, а стоимость простоя понятна.

Дальше опишите «как сейчас» в цифрах. Важно не только количество кейсов, но и кто участвует (линия 1, линия 2, менеджер), сколько времени уходит на обработку и чем заканчивается обращение (решено, эскалация, повторный вопрос).

Перед пилотом зафиксируйте базовую линию: возьмите один и тот же период (например, последние 4-8 недель), определите источники данных и назначьте владельца метрики, который подтвердит цифры. Без этого любой ROI будет выглядеть как оценка «на глаз».

Минимальный набор данных на старте:

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

Если данных мало, начните с ручного учета на небольшой выборке (100-200 кейсов). Это быстрее, чем спорить о точности, и уже дает основу для расчета и сравнения «до/после».

Метрики времени: как посчитать экономию часов

Время - самая понятная метрика, но именно ее чаще всего завышают. Учитывайте только подтвержденное сокращение, а не ощущение «стало быстрее». Лучше всего работают замеры до и после на одинаковых задачах.

Начните с простой единицы: «минуты на задачу». Например, оператор внутренней поддержки тратит 12 минут на типовой ответ, с ассистентом - 8 минут. Экономия - 4 минуты. Дальше переводите это в «минуты на сотрудника в месяц», умножая на реальное число таких задач.

Как замерять, чтобы цифры были честными

Сделайте короткий цикл измерений:

• Выберите 2-3 типовые задачи (поиск инструкции, подготовка письма, оформление заявки).
• Замерьте 20-30 выполнений «как сейчас» (таймер, логи, контрольные выборки).
• Замерьте столько же «с ассистентом» при тех же условиях.
• Отдельно вычтите время на проверку ответа ассистента.
• Зафиксируйте диапазон, а не одну цифру (например, 3-5 минут).

Перевод времени в деньги

Денежная оценка = (экономия часов) x (стоимость часа) x (доля реально высвобожденного времени).

Стоимость часа берите не только по окладу, но и с налогами и накладными расходами. А доля высвобожденного времени почти никогда не равна 100%: если сотрудник экономит 10 часов в месяц, в деньги может превратиться, например, только 30-60%. Остальное уйдет на другие задачи без прямой экономии бюджета.

Отдельно имеет смысл оценить ускорение обучения новых сотрудников и поиск информации. В сервисной команде у системного интегратора новичок раньше искал нужную инструкцию 20 минут, а с ассистентом - 5. Такие «малые» куски времени дают заметный эффект, если повторяются каждый день и у многих людей.

Метрики качества: как измерять и переводить в деньги

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

Для старта достаточно двух показателей, которые легко объяснить руководству:

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

Как измерять качество без сложной аналитики

Собирайте данные короткими циклами и на небольшой выборке, но регулярно. На практике работают такие методы: выборочная проверка 50-100 диалогов в неделю ответственным сотрудником, двойная разметка (два проверяющих оценивают независимо и сверяют расхождения), контрольные вопросы с эталоном для регламентов и безопасности.

Добавьте простую оценку пользователем: CSAT или один вопрос после ответа («полезно / не полезно»), а также NPS по итогам месяца - если он уже используется в компании.

Как перевести качество в деньги

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

(число задач с доработками) x (среднее время на доработку) x (стоимость часа сотрудника).

Если из 1 000 обращений 300 требуют переделки по 6 минут, это 30 часов потерь в месяц.

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

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

Число обращений: эффект на нагрузку и самообслуживание

После появления LLM-ассистента важно не только «быстрее отвечаем», но и «сколько обращений вообще осталось у людей». Это напрямую влияет на ФОТ, SLA и очередь ожидания.

Сначала выберите одинаковые темы «до» и «после» (пароли, доступы, типовые заявки, справочные вопросы). Затем сравните поток обращений по этим темам: тикеты, звонки, письма, чаты. Если каналов несколько, сведите их в одну таблицу, иначе часть нагрузки просто «переедет» в другой канал, и эффект будет выглядеть искаженно.

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

• Обращения по темам (штук в неделю или месяц).
• Доля самообслуживания: сколько вопросов ассистент закрыл без участия сотрудника.
• Доля эскалаций: сколько диалогов ассистент передал человеку.
• Повторные обращения: тот же пользователь по той же теме в течение, например, 7 дней.
• Среднее время до первого ответа человека (если эскалация нужна).

Самообслуживание считайте строго. «Закрыто без человека» - только если не было ручного ответа и пользователь не открыл повторный тикет по той же теме. Иначе вы завысите пользу.

Отдельно смотрите перераспределение нагрузки. Часто падают простые вопросы, но растут сложные: люди перестают откладывать проблемы и чаще доходят до экспертной поддержки. Это нормально, просто учитывайте, какие очереди разгружаются (1 линия), а какие могут вырасти (2-3 линия).

Чтобы сравнение было честным, внесите поправки на контекст: сезонность (отпуска, отчетные периоды), изменения продукта или регламентов, крупные релизы и инциденты, рост штата или клиентской базы.

Пример: в IT-службе компании вроде GSE.kz ассистент может закрывать типовые вопросы по доступам и рабочим станциям, снижая поток на 1 линию. При этом доля «правильных» эскалаций в инфраструктурную команду иногда растет, потому что пользователи точнее формулируют проблему.

Снижение ошибок: как посчитать экономию и риски

Если ассистент влияет на качество ответов и документов, экономия часто прячется не во времени, а в ошибках, которые перестали случаться. Считать стоит не абстрактное «стало лучше», а конкретные типы промахов и их цену.

Сначала договоритесь, какие ошибки учитываете. Обычно это то, что потом приходится исправлять руками или что приводит к возвратам и претензиям: неверные реквизиты и данные в заявках, счетах, договорах; пропуски обязательных полей и вложений; неправильные маршруты согласования или статусы; ошибки при переносе данных в учетные системы (CRM/ERP/Service Desk); неверные инструкции, из-за которых задачу делают не так с первого раза.

Дальше нужны два числа: насколько упала частота ошибок и сколько стоит одна ошибка. Частоту берите из реальных источников: инциденты в Service Desk, возвраты на доработку, рекламации, аудиторские замечания, история исправлений в системах. Стоимость ошибки считайте как сумму понятных компонентов: время сотрудников на разбор и исправление, время повторных согласований, простой, штрафы или потери от срыва сроков.

Базовая формула:

Экономия = (частота ошибок до - частота после) x количество операций x стоимость одной ошибки.

Пример: в IT-службе системного интегратора готовят заявки на закупку и выдачу оборудования. Если ассистент уменьшил долю заявок с неверными данными с 6% до 3% при 2 000 заявок в месяц, а средняя цена исправления 8 000 тенге (время, перепроверки, повторные согласования), экономия составит:

(0,06 - 0,03) x 2 000 x 8 000 = 480 000 тенге в месяц.

Отдельно оцените риски комплаенса и утечек. Здесь лучше быть консервативным: считайте ожидаемый ущерб как вероятность инцидента x размер ущерба и закладывайте только то, что можно обосновать фактами (история инцидентов, требования аудита, юридические расходы). Если данных мало, фиксируйте риск как неэкономическую метрику и добавляйте стоимость защитных мер (фильтры, контроль доступа, проверки) в раздел затрат.

Затраты: GPU, поддержка, обновления и эксплуатация

Чтобы честно посчитать эффект, разложите затраты на разовые (внедрение) и регулярные (операционные). Так видно, где «съедается» выгода: на старте или в ежемесячной эксплуатации.

Разовые затраты возникают один раз, но их важно амортизировать на срок жизни решения (например, 12-24 месяца), иначе ROI будет выглядеть хуже, чем есть.

К разовым чаще всего относятся интеграции (чат, сервис-деск, CRM/ERP), настройка ролей и доступов; подготовка базы знаний (сбор, чистка, разметка), первые промпты и сценарии; пилотирование и тесты качества (включая безопасность); обучение сотрудников и правила использования.

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

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

Проверьте, что в оценку попали:

• Поддержка и операционка: дежурства, инциденты, метрики, отчеты.
• Обновления: смена версии модели, актуализация документов.
• Безопасность и соответствие: журналирование, тесты, контроль утечек.
• Управление доступом: роли, SSO, аудит действий.

Если ассистент работает для госорганизации или банка, требования к логированию и доступам часто добавляют заметные часы работы ИБ и администраторов. В таких случаях эффект стоит считать только вместе с этими обязательными затратами, а не «в вакууме».

Пошаговый расчет ROI: простая схема

Чтобы посчитать ROI LLM-ассистента, начните с понятного набора сценариев: где именно он помогает и что должно измениться. Один сценарий - один измеримый результат. Тогда расчет не превращается в спор «верю / не верю».

5 шагов, которых обычно достаточно

1. Опишите 3-5 сценариев использования и ожидаемые изменения по метрикам: время, качество, обращения, ошибки. Например: ответы первой линии поддержки, поиск по внутренним регламентам, подсказки оператору.

2. Зафиксируйте базу и запустите пилот: либо контрольная группа (часть команды без ассистента), либо сравнение до/после на одинаковых типах задач. Заранее договоритесь о периоде измерения (например, 2-4 недели) и источниках данных.

3. Посчитайте эффект по метрикам и уберите двойной счет. Если число обращений снизилось, часть экономии времени уже «сидит» в этом снижении. Удобная логика такая: сначала оценить изменения в объеме работы (обращения), затем - время на оставшиеся обращения.

4. Учтите все затраты и посчитайте ROI, срок окупаемости и три сценария (пессимистичный, базовый, оптимистичный).

• ROI = (Выгоды - Затраты) / Затраты
• Срок окупаемости = Затраты / Ежемесячные выгоды

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

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

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

Чтобы цифры не «расползались», заранее зафиксируйте, какие метрики станут регулярными: 1-2 ключевые для бизнеса и 1-2 операционные (например, доля ответов, принятых без правок, и уровень эскалаций).

Частые ошибки и ловушки в расчетах

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

Вторая ловушка - приписывать ассистенту все улучшения подряд. На метрики влияют сезонность, смена регламентов, новые продукты, реорганизация поддержки и обновление базы знаний. Без базовой линии «до» и контрольного периода легко получить красивый, но неверный ROI.

Еще часто забывают, что качество тоже стоит денег. Ассистент может ускорять ответы, но требует проверки, модерации, актуализации знаний, тестов после обновлений и контроля рисков. Эти часы и инструменты должны попадать в расчет так же честно, как и стоимость GPU.

Отдельный эффект, который многих удивляет, - рост обращений. Когда вход становится проще (чат всегда под рукой), люди начинают спрашивать чаще и по более мелким поводам. В итоге «стоимость на обращение» падает, а общая нагрузка остается прежней или даже растет. Это не провал, но трактовка результата меняется.

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

Короткая проверка перед тем, как закрепить цифры:

• Подтверждено ли, что время действительно высвободилось (а не «растворилось»)?
• Есть ли сравнение с периодом без ассистента или с контрольной группой?
• Учтены ли затраты на проверку ответов, модерацию и обновление знаний?
• Проверили ли вы, не выросло ли число обращений из-за удобства?
• Совпадают ли локальные метрики (команда) с итоговым эффектом для компании?

Пример: поддержка сократила среднее время ответа на 20%, но после запуска чата входящих стало на 30% больше. Если это не учесть, «экономия» в часах будет выглядеть завышенной, хотя реальная польза может быть в другом - в росте удовлетворенности и меньшем числе повторных обращений.

Чеклист перед тем, как нести расчет руководству

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

Что стоит проверить:

• База сравнения готова: зафиксирован период (например, 4-8 недель), выбран источник данных (тикеты, телефония, CRM, табели), и понятно, кто владелец этих цифр.
• Определены 3-5 ключевых сценариев (например, ответы поддержки, поиск по базе знаний, подготовка писем, оформление заявок), и по каждому есть целевые метрики: время, качество, доля самообслуживания, число эскалаций.
• Затраты посчитаны целиком: разовые (внедрение, настройка, обучение, интеграции) и регулярные (GPU/облако или серверы, лицензии, поддержка, обновления, контроль качества, безопасность).
• Есть правила контроля качества: кто проверяет ответы, как часто, какой порог ошибок допустим, что делать при инцидентах. Плюс простая отчетность: 1-2 показателя в неделю и один владелец отчета.
• Подготовлены три сценария эффекта и окупаемости: пессимистичный, базовый, оптимистичный. Для каждого понятны драйверы (экономия минут, снижение повторных обращений, уменьшение ошибок) и срок окупаемости.

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

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

Реалистичный пример: ассистент для внутренней поддержки

Представим внутреннюю IT-поддержку в крупной организации: сотрудники пишут про сброс пароля, доступ к корпоративным системам, настройку почты, типовые вопросы по VPN и принтерам. Цель ассистента - закрывать простые запросы сразу и помогать инженерам быстрее разбираться со сложными.

База (до пилота): 1 200 тикетов в месяц, среднее время работы инженера на тикет 12 минут, 18% повторных обращений (сотрудник уточняет детали или получает неполный ответ). Ошибки в инструкциях или действиях встречаются примерно в 2% случаев и иногда приводят к откату настроек и повторной работе.

На пилот ассистенту отдают только то, что можно безопасно стандартизировать:

• Ответы по базе знаний и пошаговые инструкции для сотрудников.
• Сбор недостающих данных (ОС, версия клиента, скриншот, код ошибки).
• Создание черновика ответа для инженера в сложных случаях.
• Подсказки по типовым решениям без прав на изменения.

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

Через 4 недели получилось: 25% тикетов закрываются самообслуживанием, в остальных ассистент экономит в среднем 3 минуты на тикет за счет сбора данных и черновиков. Повторные обращения падают с 18% до 12%, а ошибки с переделкой - с 2% до 1,2%.

Переводим в деньги.

Экономия времени там, где остался человек: 900 тикетов x 3 минуты = 2 700 минут (45 часов) в месяц.

Самообслуживание: 300 тикетов x 12 минут = 3 600 минут (60 часов).

Итого 105 часов. Если полный час инженера стоит 7 000 тенге, это 735 000 тенге в месяц. Отдельно можно добавить эффект от снижения повторов и ошибок (это тоже часы), но важно не посчитать одно и то же дважды.

Дальше вычитаем затраты: аренда или амортизация GPU/серверов (или облачные запросы), поддержка промптов и базы знаний, обновления, контроль качества, безопасность. Так получается реалистичный расчет, а не только фраза «сэкономили время».

Следующие шаги: как перейти от расчета к пилоту

После расчета важно быстро перейти к проверке на реальных задачах. Цель пилота - подтвердить цифры в живой работе и понять, что мешает масштабированию.

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

Зафиксируйте правила пилота на 4-8 недель: какие метрики собираете, кто их подтверждает и как часто делаете отчет. Часто хватает еженедельного формата: сэкономленные минуты на обращение, доля решений с первого ответа, доля самообслуживания, уровень эскалаций и список типовых ошибок ассистента.

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

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

Ориентир простой: если за первые 2 недели видны стабильное сокращение времени и приемлемое качество на выбранных кейсах, пилот можно расширять. Если нет, лучше остановиться и вернуться к данным. Чаще всего проблема в качестве источников, правилах доступа или слишком широком наборе задач.