Руководитель видит десятки примеров применения ИИ. Один сервис пишет письма, другой разбирает документы, третий отвечает клиентам. Возникает логичный вопрос: с чего начать в своей компании?
Плохой ответ звучит так: "Давайте купим доступ к модели и посмотрим, что получится". Через месяц у команды есть эффектная демонстрация, но нет понятной пользы, владельца процесса и решения о следующем шаге.
Хороший пилот начинается с конкретной работы, которая уже отнимает время или создаёт ошибки. ИИ здесь является способом проверить улучшение, а не целью проекта.
Ищите неудобную работу, а не модную технологию
Поговорите с сотрудниками, которые каждый день выполняют однотипные операции. Обычно они быстро называют задачи, где приходится переносить данные между системами, разбирать похожие обращения, искать сведения в документах или заново составлять стандартные ответы.
Сначала опишите проблему обычными словами. Например: "Менеджер тратит два часа в день на сортировку входящих заявок". Формулировка "Нам нужен ИИ для отдела продаж" слишком широкая. По ней нельзя понять, что именно должно измениться.
Британское руководство по внедрению ИИ советует выбирать сценарии от потребностей пользователей, проблем и потерь в процессе, а не от возможностей технологии. Там же рекомендуется заранее сравнить ожидаемый эффект с затратами и проверить, есть ли у команды нужные данные и навыки.
Пять признаков подходящего первого процесса
Для первого пилота лучше взять задачу, у которой есть несколько свойств.
- Она повторяется достаточно часто. Редкий процесс даст мало примеров и не покажет устойчивый результат.
- Входные данные уже существуют в цифровом виде. Письма, заявки и документы проще использовать, чем сведения, которые сотрудники помнят, но нигде не записывают.
- Результат можно проверить. Человек способен понять, верно ли определена тема обращения, извлечена сумма или найден нужный пункт инструкции.
- Ошибку можно исправить до того, как она навредит клиенту или компании.
- У процесса есть владелец. Конкретный руководитель отвечает за правила, данные и решение по итогам пилота.
Хорошим первым сценарием может быть подготовка черновика ответа клиенту. Сотрудник по-прежнему читает и отправляет письмо, но тратит меньше времени на набор текста. Другой вариант: первичная сортировка входящих документов с обязательной проверкой человеком. Подробнее о такой работе мы писали в статье про автоматизацию документов.
Не начинайте с самого важного решения
Первым кандидатом часто становится процесс с самой заметной ценой ошибки. Например, одобрение кредита, найм сотрудника, постановка медицинского диагноза или автоматическая оплата крупного счёта. Кажется, что там и экономия будет больше. На практике такой пилот сразу требует сложных правил, серьёзной проверки и участия юристов.
Ещё один плохой кандидат: процесс, который постоянно меняется и нигде не описан. ИИ не исправит противоречивые инструкции. Сначала руководитель и сотрудники должны договориться, как выглядит правильный результат.
NIST напоминает, что ИИ может оказаться неподходящим решением для конкретной задачи. Организации стоит формально сравнивать пользу и риски до решения о запуске.
Составьте карточку процесса на одной странице
До встречи с подрядчиком или внутренней командой заполните короткую карточку:
- кто владеет процессом;
- кто выполняет работу сейчас;
- какие данные поступают на вход;
- что сотрудник делает с ними;
- какой результат считается правильным;
- как часто возникает задача;
- сколько времени она занимает;
- какую ошибку нельзя допустить;
- где человек проверит результат ИИ.
Если на половину вопросов нет ответа, процесс ещё не готов к пилоту. Это полезный вывод. Компания обнаружила пробел в управлении до того, как потратила деньги на внедрение.
NIST AI Risk Management Framework предлагает сначала зафиксировать цель, деловую ценность, область применения и допустимый риск. Отдельно нужно определить роли людей, которые контролируют работу системы.
Запишите исходные показатели
Пилот нельзя оценить словами "стало удобнее". До запуска измерьте текущий процесс. Достаточно нескольких понятных показателей:
- число операций за неделю или месяц;
- среднее время на одну операцию;
- доля возвратов и ручных исправлений;
- время ожидания для клиента;
- стоимость используемых сервисов и работы сотрудников.
После пилота измерьте то же самое. Если обработка ускорилась, но сотрудники стали чаще исправлять ошибки, экономия может исчезнуть. Если качество выросло, но один запрос стоит дороже ручной работы, масштабирование тоже требует пересчёта.
В простом расчёте ожидаемая экономия равна сбережённому времени сотрудников минус стоимость сервиса, проверки и интеграции. Не включайте в неё будущие проекты и расплывчатые обещания роста.
Ограничьте пилот
Первый тест не должен охватывать весь отдел. Возьмите одну команду, один тип входных данных и один проверяемый результат. Например, ИИ готовит черновики ответов только по вопросам доставки, а сотрудники подтверждают каждый ответ перед отправкой.
Такой формат помогает увидеть реальные ошибки без потери контроля. Команда собирает примеры, уточняет правила и понимает, сколько времени занимает проверка. Для более самостоятельных ИИ-агентов границы доступа особенно важны.
До старта договоритесь о сроке пилота и критериях остановки. Тест нужно остановить, если система раскрывает закрытые данные, создаёт опасные рекомендации или требует больше ручной работы, чем исходный процесс.
Решите заранее, что будет после теста
У пилота есть три нормальных исхода.
- Масштабировать. Польза подтверждена, качество приемлемо, риски контролируются.
- Доработать. Сценарий полезен, но нужно улучшить данные, правила или обучение сотрудников.
- Остановить. Экономии нет, качество не устраивает или риск слишком велик.
Третий исход не означает провал. Небольшой пилот как раз нужен, чтобы дёшево отказаться от плохой идеи.
Перед масштабированием добавьте регулярную проверку качества. Возьмите реальные примеры работы и повторяйте их после изменения модели, инструкций или данных. Как устроить такую проверку, разобрано в статье про evals для бизнеса.
Вопросы перед запуском
Руководителю не обязательно разбираться в моделях и программном коде. Но он должен получить ясные ответы на вопросы:
- какую проблему решает пилот;
- какой показатель должен измениться;
- кто отвечает за результат;
- какие данные получит система;
- кто увидит и проверит её ответ;
- что произойдёт при ошибке;
- сколько стоит пилот вместе с проверкой и интеграцией;
- по каким условиям компания продолжит или остановит проект.
Если команда отвечает на эти вопросы без названий моделей и модных терминов, процесс выбран неплохо. Технологию можно подобрать позже. Сначала должна быть понятна работа, которую компания хочет улучшить.
