Внедрение ИИ в бизнес: как выбрать первый процесс и проверить пилот

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

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

Какая задача подходит для первой проверки

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

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

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

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

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

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

Соберите набор примеров и правильных результатов, утверждённых сотрудником процесса. Включите обычные обращения и разные сложные случаи: неполные данные, неоднозначное название, изменение количества, отсутствие нужного товара в исходном перечне. Красиво оформленные примеры, на которых заранее всё известно, не покажут реальную работу.

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

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

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

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

Как описать пилот

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

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

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

До настройки договоритесь, что проверяется и по каким признакам принимается решение.

Первую проверку можно организовать без прямой записи в рабочие системы. Это позволяет отдельно оценить качество черновика. Затем, если подход полезен, проверить интеграцию и действия в ограниченном процессе. Доступ к модели — один компонент; внедрение включает ещё данные, проверку, участников и связь с реальной работой.

Как сравнить качество и стоимость

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

Например, в условном замере ручная подготовка занимает десять минут, а с ИИ — минуту ожидания, четыре минуты проверки и три минуты исправлений. Это арифметический пример, не результат клиента и не прогноз для вашего бизнеса. Он показывает, почему «ответ готов за минуту» не равен минуте работы сотрудника. Ожидание модели при этом стоит учитывать отдельно от активного времени человека.

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

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

Считайте время получения проверенного результата, включая работу человека после ответа ИИ.

Когда продолжать, менять подход или останавливаться

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

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

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

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

В Goncharoff.PRO можно обсудить автоматизацию рабочего процесса, включая ограниченный сценарий с ИИ. Начните с одного примера входных данных и того, что сотрудник должен получить на выходе. Этого достаточно для предметного первого разговора; обещать замену людей или окупаемость до проверки я бы не стал.