С чего начать внедрение ИИ в бизнесе

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

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

• Это повторяющаяся задача, занимающая хотя бы несколько часов в неделю
• У решения есть чёткие правила, или каждый раз всё зависит от контекста
• Если ошибка критична (например, проверка счёта), всё ещё нужно подтверждение человека
• Достаточно ли у Вас накопленных данных по этой задаче
• Во сколько обойдётся ошибка, если что-то пойдёт не так

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

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

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

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

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

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

Вместо того чтобы менять весь процесс сразу, протестируйте одну задачу, в одной команде, в течение ограниченного срока. Обычно достаточно четырёх-шести недель; за это время видно, действительно ли решение сэкономило время и как изменилась доля ошибок.

Не принимайте решение «внедряем на всю компанию», пока пилот не завершён. Проблема, незаметная в малом масштабе, при масштабировании растёт лавинообразно, и откат обходится дороже.

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

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

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

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

Самая частая ошибка — запустить пилот и ни разу не измерить результат. Через три месяца, когда спрашивают «работает ли это», никто не может дать чёткий ответ; поэтому в начале пилота определите, на какой показатель смотреть, и проверяйте его регулярно.

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