Автоматизация бизнес-процессов с ИИ: с чего начать и что проверять
Практический маршрут для команды: выбрать узкий процесс, описать вход и выход, встроить модель, проверить ошибки и назначить владельца. С учебным примером и критериями пилота.
Автоматизировать «работу отдела» невозможно: это слишком широкая цель. Зато можно взять одну повторяющуюся операцию, у которой известны вход, ожидаемый выход и человек, принимающий результат. ИИ добавляют туда, где правилам трудно разобрать свободный текст или подготовить черновик. Всё остальное лучше оставить явными шагами процесса.
Выберите операцию, а не лозунг
Хороший кандидат для первого пилота часто выглядит скучно: входящие сообщения надо распределить по темам, из длинной заявки собрать краткую карточку, из заметок подготовить черновик отчёта. Повторяемость важнее эффектности. Команда должна иметь несколько типичных и несколько неудобных примеров, чтобы проверить результат. Если вход каждый раз уникален и правила оценки не согласованы, сначала договоритесь о самих правилах.
Не начинайте с действия, которое сразу списывает деньги или отправляет ответ клиенту. Учебный пилот может заканчивать работу черновиком для сотрудника. Это даст время понять, какие ошибки допустимы, а какие требуют остановки. Позднее можно добавить запись или отправку с отдельной проверкой адресата, прав и последствий повторного запуска.
- Событие начала: что именно запускает обработку.
- Обязательные поля и источник каждого поля.
- Допустимый результат и признаки ошибки.
- Человек, который принимает спорные случаи.
Нарисуйте путь одного события
Запишите процесс как цепочку: получить событие, проверить полноту, подготовить текст для модели, проверить ответ, передать результат. Для каждого перехода укажите формат данных. Модель может вернуть убедительную фразу, но это не означает, что она вернула нужный ID, правильную категорию или обязательное поле. Структурированный ответ полезен, если следующий шаг рассчитывает на точные ключи; его всё равно следует валидировать.
Отдельно пометьте шаги с побочным эффектом. Чтение карточки и создание второй карточки при повторе имеют разную цену ошибки. Если сервис принял запись, а сценарий потерял ответ, статус может остаться неизвестным. Не запускайте операцию повторно, пока не проверили её результат на стороне получателя. В документации Flow для таких случаев выделены диагностика истории и безопасные повторы.
| Шаг | Что подтверждать |
|---|---|
| Вход | Событие получено один раз или распознано как повтор |
| Модель | Ответ относится к задаче и проходит проверку формата |
| Запись | Известен результат во внешнем сервисе |
| Ошибка | Есть ответственный и исходные данные для разбора |
Учебный пример: разбор обращения
Представим вымышленный сервисный отдел. На вход приходит обезличенное сообщение «Не могу найти счёт за заказ». Цель сценария: определить тему и составить для сотрудника короткое резюме с вопросами, которых не хватает для ответа. Модель не придумывает номер заказа, не меняет статус платежа и ничего не пишет клиенту. Проверка опирается на исходный текст и заранее утверждённые категории.
Для теста добавьте более трудные входы: сообщение без текста, несколько вопросов в одном обращении, фразу на другом языке, повтор того же идентификатора. Ожидание для пустого входа: остановка с причиной; для смешанного: пометка «нужна ручная проверка». Такой набор показывает границы модели лучше, чем один удачный скриншот. Все данные в примере учебные, никакой статистики внедрения здесь нет.
- Вход: текст и тестовый ID обращения.
- Выход: категория, краткое содержание, признак сомнения.
- Остановка: пустой текст или непроверенный внешний эффект.
Как собрать пробную цепочку
В Kvantora Flow документация предлагает начать с триггера и текстового действия, выбрать публичный ID модели и посмотреть ответ в истории. После этого можно передать конкретное поле ответа следующему шагу. Если нужен внешний сервис, проверьте конкретный коннектор и действие в /integrations. Не предполагайте доступность CRM или мессенджера по одному названию категории.
Ограничьте доступные модели и бюджет подключения, задайте максимальную стоимость шага и проверьте текущую цену в /pricing. У модели из /models должна быть нужная операция, а у команды понимание, что пробный запуск тоже может расходовать средства. Сначала работайте на синтетических входах без персональных данных. Затем сравните ответы на подготовленных контрольных примерах.
- Пример сценария и история: документация Flow.
- Каталог операций: /models.
- Каталог интеграций: /integrations.
Приёмка пилота без выдуманных процентов
Не обещайте, что ИИ сократит трудозатраты вдвое. У команды пока нет таких данных. Вместо этого зафиксируйте простые наблюдаемые критерии: сколько контрольных входов прошло без потери обязательных полей, какие случаи попали человеку, видна ли причина остановки и можно ли восстановить исходное событие. Временные затраты можно измерить позже на реальной выборке с понятным способом подсчёта.
Проверку проводите с будущим пользователем сценария. Пусть сотрудник найдёт один неудачный запуск в истории и объяснит, что делать дальше. Если для этого нужен инженер и чтение логов нескольких систем, сценарий ещё не готов к широкому включению. Приёмка должна отражать обычную работу, включая скучные ошибки ввода.
Отдельно оцените цену ошибки. Неверная тема у внутреннего черновика обычно исправляется сотрудником; неверный адресат письма уже меняет последствия. Запишите, какие ошибки допускают ручную поправку, а какие должны остановить цепочку до внешнего действия. Эта классификация помогает расставить проверки. Она также удерживает команду от желания автоматизировать всё, когда пилот прошёл обычные входы, но ещё не встретил редкие опасные случаи.
- Ожидаемый результат для каждого тестового входа записан заранее.
- Причина остановки видна исполнителю.
- Бюджет и ответственный за расходы известны.
Типичные ошибки при расширении
Первая ошибка: сразу добавлять новый шаг на каждый частный случай, пока цепочку перестаёт понимать даже её автор. Сначала пересмотрите входной контракт и категории. Вторая: доверить модели окончательное решение там, где нужен проверяемый факт из системы. Модель может сформулировать ответ, но статус заказа берите из источника данных, а не из её догадки.
Третья ошибка: считать публикацию сценария концом проекта. Назначьте владельца изменений, храните контрольные входы, проверяйте новый вариант до включения и следите за остановившимися запусками. Если внешнее действие имеет неизвестный исход, оставьте его на разбор, даже когда очень хочется нажать «повторить». Автоматизация хороша тогда, когда сотрудник понимает её пределы.
- Разделяйте черновик и внешнее действие.
- Проверяйте новые входы после изменения источника данных.
- Возвращайтесь к критериям пилота при каждой крупной правке.