Как автоматизировать бизнес-процессы с помощью ИИ: пошаговый план

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

Как автоматизировать бизнес-процессы с помощью ИИ: общая схема

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

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

Весь путь укладывается в восемь шагов:

Шаги 1–2. Выберите процесс и замерьте его

Шаг 1. Выбор процесса

Начинать стоит с одного процесса, а не с «внедрения ИИ во всю компанию». Хороший кандидат отвечает большинству условий:

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

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

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

Шаг 2. Замер процесса как есть

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

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

Точность до минуты не нужна. Достаточно, чтобы два-три сотрудника неделю отмечали время на задачу, а объёмы выгрузили из CRM или почты. Заодно соберите 50–100 реальных примеров входных данных — настоящих писем, документов, записей, включая сложные и нестандартные. На них потом будут проверять прототип.

Условный пример: 600 заявок в месяц × 7 минут на ручной разбор = 70 часов работы менеджеров. Если после автоматизации на заявку уходит минута проверки, высвобождается около 60 часов в месяц. Это расчёт на условных данных, ваши цифры покажет замер.

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

Шаги 3–4. Разложите процесс и подготовьте данные

Шаг 3. Для каждой операции: правило, интеграция, модель или человек

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

Пример для сервисной компании, которая принимает заявки на ремонт из почты, мессенджера и формы на сайте:

1. Заявка поступает в любой канал — интеграция собирает всё в одну очередь.
2. Модель определяет тип обращения, адрес, оборудование и срочность.
3. Код проверяет, есть ли клиент в базе и действует ли договор обслуживания.
4. Правило назначает инженера по району и типу оборудования.
5. Если модель не уверена в типе или срочности, заявка уходит диспетчеру.
6. Клиент получает подтверждение с номером заявки.

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

Шаг 4. Данные, доступы и выбор модели

На этом шаге выясняется, к каким системам нужно подключиться и как. У CRM обычно есть REST API и вебхуки, у 1С — HTTP-сервисы или OData, у почты — стандартные протоколы. Нужны учётные записи с минимально достаточными правами и, по возможности, тестовая копия базы, чтобы прототип не писал в рабочие данные.

Отдельное решение — где будет работать модель. Варианты: зарубежные облачные модели через API, российские (YandexGPT, GigaChat) или open-source модели на ваших серверах. Выбирают по качеству на ваших примерах, цене при вашем объёме и по тому, какие данные будут уходить в модель. Если в процессе есть персональные данные клиентов или сотрудников, требования 152-ФЗ учитывают до разработки, а не после: от этого зависит архитектура. Детали сверяйте с актуальной редакцией закона и с юристом.

Здесь же выбирают платформу: визуальный конструктор вроде n8n или Make либо собственный код. Плюсы и минусы каждого варианта — в статье n8n, Make или разработка.

Шаги 5–6. Прототип и контроль человека

Шаг 5. Прототип на реальных данных

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

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

Прототип почти всегда находит то, чего не было видно на бумаге: документы в неожиданных форматах, заявки без ключевых данных, внутренние договорённости, которые нигде не записаны. Это нормально — ради этого его и делают.

Шаг 6. Контроль, исключения и журнал

Языковая модель иногда ошибается, и система должна быть к этому готова. Базовые механизмы:

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

Шаги 7–8. Запуск и замер результата

Шаг 7. Поэтапный запуск

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

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

Шаг 8. Замер и решение о масштабировании

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

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

Когда автоматизация с ИИ не подходит

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

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

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

С чего начать

1. Выпишите три-пять процессов, где сотрудники больше всего времени тратят на чтение, сортировку и перепечатывание.
2. Для каждого прикиньте объём в месяц и время на единицу.
3. Выберите один процесс по критериям из шага 1 и соберите по нему реальные примеры.
4. Проверьте, к каким системам нужен доступ и есть ли в данных персональные данные.
5. Назначьте человека со стороны бизнеса, который отвечает за результат.

С этим набором можно идти к подрядчику или собирать прототип своими силами. На бесплатном 30-минутном аудите мы разбираем ваш процесс, оцениваем прогнозную окупаемость и честно скажем, если проект не окупится. Проекты по автоматизации бизнес-процессов с помощью ИИ стоят от 50 000 ₽: прототип — за одну-две недели, полноценное решение — за один-три месяца.