Автоматизация с помощью ИИ: как выбрать первый процесс и измерить результат

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

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

Хороший кандидат имеет пять признаков:

· повторяется достаточно часто;

· начинается с наблюдаемого события;

· заканчивается проверяемым результатом;

· использует доступные данные;

· ошибка обнаруживается до серьезного последствия.

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

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

До добавления ИИ пройдите процесс вместе с исполнителем. Запишите:

1. что запускает работу;

2. откуда берутся данные;

3. какие решения принимает человек;

4. какие системы меняются;

5. где возникают ожидания и возвраты;

6. что считается завершением;

7. какие ошибки уже происходят.

Измерьте исходную линию хотя бы на 20–30 реальных случаях. Для каждого случая отметьте время работы, время ожидания, число исправлений и итоговый статус. Не просите сотрудника назвать «среднее на глаз»: сложные случаи обычно запоминаются лучше обычных.

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

У автоматизации есть уровни автономности:

1. ИИ предлагает результат, человек выполняет действие.

2. ИИ готовит черновик в системе, человек подтверждает.

3. ИИ выполняет обратимое действие и сообщает человеку.

4. ИИ самостоятельно выполняет действие с внешними последствиями.

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

Для каждого действия задайте три вопроса:

· можно ли его отменить;

· как быстро обнаружится ошибка;

· кто несет последствия.

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

Рабочая гипотеза содержит процесс, изменение и метрику:

Если модель будет классифицировать входящие обращения и готовить черновик по базе знаний, то медианное активное время оператора на один принятый ответ снизится с исходного значения минимум на 25%, при этом доля существенных исправлений не превысит согласованный порог.

Числа в примере не являются универсальной нормой. Команда задает их после измерения текущего процесса и оценки риска.

Заранее определите срок и объем эксперимента: например, две недели или 200 обращений. Зафиксируйте условие остановки: раскрытие данных, повторное внешнее действие, превышение бюджета или рост критичных ошибок.

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

Используйте четыре группы.

· доля случаев, завершенных правильно;

· время от входа до принятого результата;

· доля обращений, вернувшихся на доработку;

· влияние на целевое действие клиента.

· существенные фактические ошибки;

· нарушения правил или тона;

· пропущенные обязательные поля;

· ложные уверенные ответы.

· активное время сотрудника;

· стоимость модели и интеграций;

· стоимость ручной проверки;

· стоимость одного принятого результата;

· время поддержки самой автоматизации.

· технические сбои;

· дубли действий;

· передачи человеку;

· инциденты с данными;

· время восстановления.

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

Возьмите реальные случаи и удалите лишние персональные данные. Включите:

· обычные запросы;

· редкие, но важные случаи;

· неоднозначные формулировки;

· ошибки во входных данных;

· попытки обойти инструкцию;

· случаи, которые обязательно передаются человеку.

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

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

Первая версия может состоять из пяти шагов:

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

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

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

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

Теневой режим показывает:

· какие данные реально отсутствуют;

· где инструкция неоднозначна;

· сколько случаев модель передает человеку;

· сколько времени занимает проверка;

· какие ошибки не покрыты тестовым набором.

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

У процесса должно быть не менее трех ролей, даже если их выполняют два человека:

· владелец процесса определяет правильный результат;

· технический владелец поддерживает интеграцию;

· проверяющий принимает спорные и рискованные случаи.

Также нужен владелец базы знаний. Устаревший источник будет стабильно давать устаревшие ответы, даже если модель и код работают без ошибок.

Запишите, кто имеет право менять инструкцию, модель и пороги. Изменение промпта в production является изменением системы и должно проходить проверку.

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

· медиану и разброс времени;

· долю принятых без изменения черновиков;

· существенные исправления;

· стоимость всего маршрута;

· технические сбои;

· новые риски и ручные операции.

Не объединяйте обычные и редкие критичные случаи в одно среднее. Автоматизация может хорошо работать на 90% потока и быть неприемлемой из-за оставшихся 10%.

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

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

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

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

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

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

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

Даже если агент правильно передает 20% случаев, оператор должен успевать их обработать. Посчитайте пиковую очередь, рабочее время и срок ответа. Автоматизация, которая круглосуточно создает задачи для команды с графиком 5/2, может ухудшить клиентский опыт.

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

Храните версию промпта, модели, инструментов и базы знаний. Каждое изменение проходит эталонный набор, теневой прогон и ограниченное включение. Запишите дату, автора и причину.

Не редактируйте production-инструкцию прямо во время спора с одним ответом. Сначала добавьте случай в тесты и определите ожидаемое поведение. Иначе локальное исправление может сломать более частый маршрут.

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

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

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

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

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

Спроектировать такой тест и собрать минимальный контур можно на курсе "Вайбкодинг на максималках"«Вайб-кодинг: быстрый старт». Основной результат при этом не сам агент, а измеряемое изменение процесса.

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