Вопрос пользователя: У нас есть процесс в 1С ERP. Как понять заранее, нужен ли в нем LLM-агент, или достаточно классического RPA без лишней сложности?
Суть проблемы
Самая дорогая ошибка в автоматизации — не техническая, а архитектурная. Команда может выбрать слишком слабый контур и оставить обычный RPA там, где поток входных данных уже давно стал смысловым и неструктурированным. А может выбрать слишком сложный контур и затянуть LLM туда, где процесс и так идеально автоматизируется правилами, циклами и UI-привязками.
Обе ошибки стоят денег. В первом случае проект тонет в исключениях, ручных доработках и неустойчивых сценариях. Во втором — становится слишком дорогим в поддержке, тестировании и сопровождении, хотя исходную задачу можно было решить обычным роботом.
Главный принцип выбора
Нужно перестать задавать вопрос «нужен ли нам ИИ». Это слишком общий и бесполезный вопрос. Вместо него нужно задавать другой: в каком именно месте процесса возникает смысловая неопределенность, которую нельзя надежно прошить обычными правилами.
Если такой неопределенности нет, LLM не нужен. Если она есть, но не влияет на ход процесса, LLM можно не включать в контур исполнения, а использовать только как аналитическую подсказку. Если же именно эта неопределенность и является главным узким местом процесса, тогда без LLM-слоя архитектура будет слабой.
Матрица выбора для 1С ERP
Чтобы не принимать решение интуитивно, удобно использовать матрицу из шести осей.
Ось 1. Повторяемость сценария. Если 80–90% кейсов проходят одинаково, это сильный аргумент в пользу обычного RPA. Если каждый второй кейс идет по другой ветке, вероятно, уже нужен смысловой слой.
Ось 2. Степень структурированности входа. Excel со стабильными колонками — это один класс задач. Письма поставщиков, PDF, комментарии менеджеров, сканы и вложения — совсем другой.
Ось 3. Количество исключений. Если исключения редки и легко перечисляются, их можно формализовать. Если список исключений постоянно растет и живет «в голове у эксперта», это явный сигнал в пользу LLM.
Ось 4. Цена ошибки. Чем выше цена ошибки, тем осторожнее нужно включать агент в контур принятия решения. Высокая цена ошибки не запрещает LLM, но требует обязательной валидации и нередко — ручного утверждения.
Ось 5. Наличие человеческого суждения. Если специалист каждый раз оценивает смысл, контекст, похожесть, правдоподобие, корректность формулировки, без LLM или без перепроектирования процесса не обойтись.
Ось 6. Возможность выразить логику в правилах. Если правила можно описать в виде конечного дерева условий и оно остается устойчивым, обычный RPA вполне справится. Если же правила становятся громоздкими, нестабильными и дорогими в сопровождении, смысловой слой становится оправданным.
Четыре зоны автоматизации
Из этих осей получается практичная матрица выбора.
Зона A: чистый RPA. Сценарий стабилен, вход структурирован, исключений мало, цена ошибки понятна, правила описываются формально. Примеры: массовое создание документов по Excel, проведение стандартных действий по расписанию, ночные сверки, перенос данных между системами, выгрузки и загрузки с четко заданной структурой.
Зона B: гибрид RPA + LLM. Основной ход процесса стабилен, но входной поток неструктурирован или содержит смысловые развилки. Примеры: письма поставщиков, сопоставление номенклатуры, регистрация обращений, разбор приложений, извлечение данных из прайсов и PDF.
Зона C: LLM + человек + RPA. Повторяемость низкая, исключений много, цена ошибки ощутимая, а специалист фактически принимает решение на основе контекста. Здесь агент можно использовать для подготовки решения и предварительного маршрута, но не для окончательного автономного выполнения.
Зона D: сначала стабилизация процесса, потом автоматизация. Если сам процесс не определен, нет нормального владельца, правила противоречивы, а сотрудники делают одно и то же по-разному, никакой LLM проблему не решит. Сначала нужен организационный порядок.
Как встроить это в вашу диагностику
У вас уже есть сильная рамка быстрой оценки RPA-эффекта: потери документов, регуляторные риски, повторяемость сценария, объем операций, необходимость вертикальной прошивки. Для гибридной автоматизации эту рамку нужно расширить дополнительным смысловым слоем.
При диагностике процесса теперь нужно задавать еще и такие вопросы:
- какая доля входа приходит в виде свободного текста, писем, PDF, сканов или комментариев;
- сколько случаев в месяц требуют ручного выбора между несколькими ветками;
- какие правила реально существуют только в голове эксперта;
- сколько времени уходит не на действия в системе, а на «понять, что хотел инициатор»;
- какие признаки дубля, конфликта или неполноты сегодня определяются вручную;
- в каких точках процесса сотрудник принимает решение «по смыслу», а не по чек-листу.
Вот именно здесь и определяется потребность в агентном слое.
Где LLM точно не нужен
Есть соблазн вписать LLM почти в любой процесс, потому что тогда проект выглядит современнее. Но в ряде случаев это просто лишняя сложность.
LLM не нужен, если:
- данные уже поступают в строгом шаблоне;
- набор правил стабилен и редко меняется;
- основная трудоемкость процесса находится в рутинном UI-прохождении;
- исключения редки и хорошо описаны;
- цена ошибки высока, а смысла в свободной интерпретации нет;
- проблема процесса — не в понимании данных, а в отсутствии дисциплины исполнения.
Например, если у вас есть типовой Excel-файл для массового заведения позиций, где структура уже согласована, обязательные колонки определены, а дальше нужна просто последовательная регистрация в 1С ERP с логами и архивом, здесь LLM только утяжелит контур.
Где LLM действительно полезен
LLM оправдан тогда, когда именно на этапе понимания входа умирает основная производительность процесса.
Типичные сигналы:
- письма приходят в свободной форме;
- одни и те же товары описываются по-разному;
- единицы измерения, упаковки, артикулы и названия плавают;
- специалисты тратят время на сравнение похожих позиций;
- часто нужно принять решение: создавать новую карточку или нет;
- сотрудники каждый раз «примерно понимают», что делать, но не могут это строго формализовать;
- доля ручного разбора выше, чем доля ручного ввода.
Тогда LLM не заменяет робота, а забирает на себя именно то, что раньше делал человек как интерпретатор.
Практическая матрица для проектного решения
Хорошее проектное правило звучит так.
Если процесс состоит в основном из кликов, ожиданий, переносов, архивирования, проверок и типовых условий — делаем обычный RPA.
Если процесс состоит в основном из разбора текста, приложений, неформальных описаний, сопоставления, оценки похожести и выбора ветки — добавляем LLM.
Если процесс одновременно и смысловой, и регламентный — строим гибрид.
Если процесс хаотичен организационно — сначала стабилизируем его, а потом автоматизируем.
Решение и рекомендации
Первое. Не начинайте выбор инструмента с технологий. Начинайте с диагностики природы неопределенности в процессе.
Второе. Отделите действия от интерпретации. Часто оказывается, что процесс несложен в исполнении, но тяжел в интерпретации входа. Тогда нужен именно гибрид.
Третье. Если есть сомнение, сначала проектируйте минимально достаточный контур. Лишний LLM в стабильном процессе хуже, чем его отсутствие.
Четвертое. Высокая цена ошибки означает не отказ от LLM, а изменение его роли: он становится помощником по подготовке решения, а не автономным исполнителем.
Пятое. Всегда учитывайте стоимость сопровождения. Чем больше в процессе чистой логики правил, тем выгоднее она живет в RPA. Чем больше там смыслового хаоса, тем больше пользы от агентного слоя.
Итог простыми словами
Нужен не «ИИ вообще», а правильный ответ на вопрос: где в процессе заканчиваются правила и начинается смысл. Всё, что до этой границы, спокойно отдавайте RPA. Всё, что после нее, проектируйте как агентный слой. А если процесс проходит через обе зоны, стройте гибридную архитектуру.
Типичный сценарий правильного использования
Массовое создание стандартных заказов по согласованному Excel — чистый RPA. Но если перед этим Excel формируется из разнородных писем и прайсов поставщиков, где каждую строку еще надо понять и нормализовать, тогда на вход добавляется LLM-агент, а сам процесс создания документов остается за роботом.
Типичный сценарий опасного использования
Команда решает, что LLM теперь «умеет всё», и добавляет его в процесс ночной регламентной обработки, где вся логика уже давно стабилизирована. В результате растет стоимость, усложняется тестирование, появляется новый класс ошибок, а пользы почти нет. То есть проект становится современнее на словах, но слабее на практике.