Агент не наводит порядок в хаосе. Он ускоряет то, что уже описано. Разбираемся, как это выглядит на практике и с чего начать, если вы руководитель, а не программист.
«Купим ИИ-агента, и он всё разгребёт». Эту фразу сегодня произносят на планёрках всё чаще. Звучит заманчиво: нанимать никого не нужно, спать можно спокойнее. Но на деле агент, брошенный в неописанный процесс, быстро становится ещё одним участником хаоса, только очень быстрым.
Правильный вопрос звучит иначе: какой шаг в моей работе тормозит всё остальное? Ответ на него лежит не в магазине приложений, а на листе бумаги. Там и начинается разговор про BPMN.
Знакомая картина
Возьмём обычную ситуацию. Клиент присылает письмо с просьбой вернуть товар. Сотрудник читает его, пытается понять, чего именно хочет человек, ищет заказ в системе, сверяет условия возврата, пишет ответ и отправляет на согласование, если сумма крупная.
Если посмотреть, на что уходит время, окажется, что сама проверка условий занимает минуту. Остальное съедает чтение, поиск и переписка. Письма пишут живые люди: кто-то в трёх предложениях, кто-то на странице с эмоциями. Обычный скрипт с такой почтой не справится. Человек справляется, но тратит на это бо́льшую часть рабочего дня.
Это и есть классическое место для ИИ-агента: хаотичный вход, который нужно понять. Но есть нюанс, о котором мало говорят в рекламе.
Что такое BPMN, без терминов
BPMN — это стандартный способ нарисовать бизнес-процесс. Блоки обозначают шаги, стрелки показывают порядок, ромбы показывают развилки: «если сумма больше такой-то, отправить руководителю». Схемы такого рода существуют не одно десятилетие, и по ним умеют не только рисовать, но и запускать процессы в специальных программах.
Главное свойство схемы простое: она видна. Можно показать пальцем, где заявка застряла, кто её согласовывал и сколько это заняло. Для руководителя это уже половина решения. Нельзя ускорить то, что невозможно увидеть.
Как агент попадает в схему
Одна из платформ, Camunda, описывает подход так. В схеме появляется особый блок. Внутри него шаги идут не строго по порядку: агент сам выбирает, какое действие сделать следующим, повторить его или пропустить. Он смотрит на задачу, берёт инструмент, например «найти заказ» или «запросить документ», получает результат и решает, что делать дальше, пока задача не решена.
Важно, что всё это происходит внутри блока. Снаружи остаётся обычная схема с жёсткими правилами. Получается разделение ролей:
- Схема отвечает за порядок, сроки, повторы при сбоях и журнал действий.
- Агент отвечает за понимание и выбор там, где правила заранее не напишешь.
- Человек подтверждает то, что нельзя доверять машине.
Оговорка для честности: это описание самого вендора, взятое из его документации. Оно показывает замысел продукта, а не независимую оценку его работы. Впрочем, похожую логику разделения ролей обсуждают и в научных работах об управлении процессами с участием агентов.
Как это выглядит на примере
Представим интернет-магазин, который обрабатывает заявки на возврат. Это иллюстрация, а не реальный кейс, и цифры в ней условные.
Было. Менеджер читает письмо, сверяет заказ, проверяет условия, пишет ответ. На одну заявку уходит четверть часа, а то и больше. К концу дня глаз уже замылен, и ошибки в датах не редкость.
Стало. Схема принимает заявку и запускает агента. Агент читает письмо, находит заказ, сверяет условия и готовит черновик решения. Дальше вступают правила схемы: небольшой возврат уходит клиенту автоматически, крупный попадает к менеджеру на подтверждение. Каждый шаг записывается в журнал.
Менеджер не исчез. Он перестал быть читателем писем и стал человеком, который принимает сложные решения. Для большинства сотрудников это, пожалуй, главное изменение к лучшему.
Что говорят цифры
В отрасли часто называют такие результаты: сокращение времени процесса на 20–60% и снижение стоимости на 15–25%. Стоит помнить, откуда они берутся. Эти диапазоны приводят вендоры и консалтинговые компании, а они, как правило, описывают удачные проекты. Как ориентир они годятся, как прогноз для вашей компании нет.
Более скромный и проверяемый пример даёт научная работа 2025 года. Исследователи построили многоагентную систему для поиска узких мест в процессе и проверили её на 8 469 реальных заявках службы поддержки. Результат: время обработки обращения сократилось на 23,7%, использование ресурсов выросло на 18,4%, оценка снижения стоимости составила 15,9%. Узкие места система находила в 92,3% случаев.
Это результат одного исследования на одном наборе данных, а не гарантия для любого бизнеса. Зато он показывает реалистичный порядок величин: десятки процентов, а не «в десять раз». Кто обещает в десять раз, скорее всего, что-то продаёт.
Как найти то самое место
Чтобы понять, какой шаг отдать агенту, нужно знать, где процесс на самом деле тормозит. Не где «кажется», а где есть очередь. Для этого используют анализ журналов систем, его называют process mining. Программа берёт записи о том, как заявки проходили через ваши системы, и показывает настоящий путь: где повторы, где ожидание, где заявки возвращаются на доработку.
Обзоры кейсов показывают, что такой анализ часто вскрывает узкие места, о которых руководители не подозревали. В упомянутой научной работе агенты использовали такие данные, чтобы предлагать изменения в процессе.
Для небольшой компании всё проще. Достаточно выписать шаги, проставить время и спросить сотрудников, на что они тратят силы. Ответы часто удивляют.
Где агент не нужен
Теперь вторая сторона вопроса. У подхода есть критики и ограничения, и многие из них признают сами вендоры.
Схема не умеет описывать неопределённость. BPMN создавался для чётких процессов. Научные работы отмечают, что в нём нет встроенных способов указать, насколько агент уверен в ответе. Поведение приходится описывать словами, а слова бывают двусмысленными.
Агент ошибается вероятностно. Camunda в своих рекомендациях предупреждает: не стоит запускать агентов «сами по себе». Их нужно держать внутри процесса с ограничениями, эскалацией к человеку и запасными вариантами. Финальные расчёты и решения по чётким правилам лучше оставлять обычным системам.
Агент усложняет систему. Там же советуют не ставить агента «просто потому что можно», а начинать с проблемы и проверять, нужен ли он вообще.
Из этих рекомендаций следует простое правило выбора:
- Задача понятная, повторяющаяся, регулируемая — подойдёт обычная автоматизация по правилам.
- Входные данные хаотичные, например письма, документы, разговоры, и нужно понять смысл — подойдёт агент.
- Результат важен или необратим — агент готовит, человек подтверждает.
Что сделать в ближайший месяц
Это следствие описанных подходов, а не персональная рекомендация. Но порядок действий выглядит разумно:
- Выберите один процесс. Лучше тот, который повторяется часто и раздражает сотрудников: заявки, счета, обращения, согласования.
- Нарисуйте его как есть. Хватит листа бумаги: шаги, исполнители, время на каждый.
- Найдите один шаг. Тот, где человек читает, интерпретирует или ищет информацию. Это кандидат для агента.
- Определите границы. Что агент делает сам, что только предлагает, в каких случаях зовёт человека.
- Измерьте до и после. Время на заявку, число ошибок, число повторных обращений. Без замеров вы не узнаете, помог ли агент или только создал ощущение движения.
Итог
ИИ-агент не заменяет процесс, он встраивается в него. Выигрывают те, кто сначала разобрался, как устроена работа, и только потом добавил агента на одно трудное место. При удачном выборе задачи эффект измеряется десятками процентов. При неудачном может оказаться нулевым.
Схема даёт порядок и прозрачность. Агент даёт гибкость. Человек оставляет за собой ответственность. Если эти три роли распределены, у проекта есть шанс. Если нет, никакая модель не поможет.
Редакция: в материале использованы документация Camunda, обзоры кейсов по анализу процессов и научная работа 2025 года о многоагентной оптимизации процессов. Описания продуктов вендоров отражают их собственную позицию.
