Как внедрить ИИ в бизнес: от выбора задачи до запуска

Что на самом деле означает внедрение ИИ в бизнес

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

При внедрении система становится частью регулярной работы.

Например, компания получает заявки через сайт. Менеджер читает каждое обращение, определяет его тип, переносит данные в CRM и назначает ответственного.

После внедрения процесс может выглядеть иначе:

заявка → определение типа → извлечение данных → проверка → создание карточки CRM → маршрутизация

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

Именно изменение процесса, а не наличие нейросети, имеет смысл считать внедрением ИИ.

Сначала разберите бизнес-процесс

Начинать проект с формулировки «нам нужен AI-агент» рано. Агент — уже вариант реализации.

Сначала стоит описать существующую работу: входные данные → действия сотрудника → решение → результат → исключения

Возьмём обработку заявок.

Клиент отправляет форму. Менеджер читает обращение, определяет услугу, проверяет данные, создаёт карточку в CRM и назначает ответственного.

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

Полезно отдельно отметить шаги, на которых сотрудник:

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

Это основные кандидаты на автоматизацию.

Но есть важное ограничение: если сам процесс не определён, ИИ его не исправит.

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

Как выбрать первую задачу для внедрения ИИ

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

Хорошая первая задача обычно отвечает нескольким условиям:

• возникает регулярно;
• занимает заметное время сотрудников;
• имеет доступные входные данные;
• результат можно проверить;
• цена ошибки ограничена;
• эффект можно измерить.

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

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

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

Если системе не хватает данных, сильнее модель её не спасёт. Задача «определить точную категорию товара» плохо решается, если на входе есть только название из двух слов.

Какие данные нужны для внедрения ИИ

Разным задачам нужны разные данные.

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

До разработки полезно составить простую карту: какие данные нужны → где они находятся → кто имеет к ним доступ → насколько они актуальны

Возьмём наш пример с заявками.

Текст обращения приходит с сайта. История клиента находится в CRM. Информация об услугах — во внутренней системе. Правила обработки обращений — в регламентах.

ИИ-система может использовать несколько источников одновременно.

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

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

Нужен ли здесь вообще ИИ

До выбора модели стоит проверить, нельзя ли решить задачу проще.

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

Правило «если сумма заявки больше 100 000 рублей — отправить её руководителю» не требует большой языковой модели. Обычное условие работает дешевле и предсказуемее.

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

Как понять, какое решение подходит

В примере с заявками определить тему обращения может одна AI-функция. Создать карточку CRM способна обычная автоматизация. Агент нужен только тогда, когда система действительно должна сама выбирать дальнейшее действие.

Не каждой задаче нужен агент. Иногда одного API-запроса вполне достаточно.

Как провести пилот и проверить, что решение работает

Первый пилот не должен автоматизировать весь отдел.

Его задача — проверить одну конкретную гипотезу на ограниченном участке процесса.

Например:

может ли система правильно классифицировать большинство входящих заявок и передавать спорные обращения менеджеру

У пилота должны быть понятны границы:

• какой процесс проверяем;
• какие данные используем;
• кто работает с системой;
• что делает ИИ;
• что остаётся человеку;
• по каким критериям принимаем результат.

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

Зафиксируйте исходные показатели

До запуска нужно измерить состояние процесса:

• время обработки;
• количество ручных действий;
• объём операций;
• долю ошибок;
• стоимость обработки, если её можно определить.

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

После пилота сравниваются те же показатели.

Иначе результат сведётся к фразе «вроде стало быстрее».

Проверяйте реальные сценарии

Для тестирования нужна выборка реальных задач: обычные ситуации, сложные случаи и исключения.

Стоит считать:

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

Сам по себе показатель «точность 95%» мало что говорит.

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

Поэтому качество всегда оценивается вместе с последствиями ошибки.

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

Как встроить ИИ в рабочие системы компании

На раннем пилоте сотрудник может вручную копировать информацию в AI-чат и переносить ответ обратно.

Для постоянной работы такой процесс неудобен:

система → сотрудник копирует данные → AI-чат → сотрудник копирует результат → система

Автоматизации здесь немного. Зато у Ctrl+C и Ctrl+V появляется новая должность.

При интеграции схема меняется:

бизнес-система → данные → ИИ → проверка → действие → бизнес-система

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

Для заявок схема может выглядеть так:

форма сайта → AI-классификация → CRM → выбор маршрута → менеджер

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

ИИ можно интегрировать с CRM, 1С, ERP, сайтом, базами данных и внутренними сервисами через API и другие механизмы обмена.

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

Где оставить контроль человеку

Полная автономность нужна далеко не каждому процессу.

Условно можно выделить три режима.

1. ИИ советует. Система анализирует данные и предлагает решение. Последнее слово остаётся за сотрудником.
2. ИИ готовит действие. Например, формирует ответ или заполняет карточку, а человек подтверждает операцию.
3. ИИ действует автоматически. Система сама выполняет разрешённые действия, а сотрудник подключается к исключениям.

Главный принцип простой:

чем выше последствия ошибки, тем ближе человек должен быть к точке принятия решения.

В нашем примере стандартные заявки можно маршрутизировать автоматически. Неоднозначные обращения система отправляет менеджеру.

Такой подход обычно полезнее попытки сначала добиться мифических 100% точности, а только потом запускать проект.

Как измерить результат и решить, стоит ли масштабировать

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

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

Необязательно сводить всё к одной метрике. Но результат должен быть измеримым.

Полный расчёт TCO, срока окупаемости и ROI лучше проводить отдельно — это уже самостоятельная задача.

Масштабировать решение стоит после того, как пилот работает стабильно, ограничения понятны, а эффект подтверждён цифрами.

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

Так масштабируется уже проверенный сценарий, а не надежда, что «ИИ где-нибудь точно пригодится».

Что нужно контролировать после запуска

После релиза работа с системой не заканчивается.

Могут измениться документы, ассортимент, внутренние правила, API, используемые модели и сам бизнес-процесс.

Поэтому нужно следить за:

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

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

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

Отдельно определяются ответственные за данные, качество и техническую эксплуатацию.

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