Вопрос пользователя: Можно ли показать гибридную автоматизацию не в теории, а на конкретном сценарии: вход идет из Excel, писем и вложений, агент разбирает данные, а робот создает карточки в 1С ERP?
Суть проблемы
Без конкретного кейса тема гибридной автоматизации быстро уходит в абстракцию. Кажется, что всё понятно: агент разбирает, робот исполняет, человек проверяет сложное. Но пока это не разложено на артефакты, секции процесса, контрольные точки, state-файлы, batch/results/log и шаги в 1С ERP, польза для проекта остается ограниченной.
Сценарий регистрации новой номенклатуры удобен тем, что в нем одновременно присутствуют и смысловые, и исполнительные операции. Это значит, что на нем хорошо видно, зачем нужен каждый слой архитектуры.
Базовый сценарий процесса
У бизнеса есть задача массово или регулярно регистрировать новые позиции номенклатуры в 1С ERP. Вход может приходить из трех источников:
- строгий Excel от внутреннего сотрудника;
- письмо поставщика с приложением;
- прайс-лист или PDF, где данные частично структурированы.
Наивная автоматизация попытается всё свести к экранным действиям. Но это даст эффект только на первом типе входа. Как только появляются письма, плавающие названия, неполные реквизиты и риск дублей, без смыслового слоя процесс начнет тонуть в ручной работе.
Как выглядит правильная гибридная архитектура
Этап 1. Прием входа
Робот или отдельный входной процесс получает файл или письмо, сохраняет его в стандартизированную структуру каталогов и фиксирует запуск. Здесь важна инженерная дисциплина: все пути строятся через resource, а не через абсолютные пути. Сразу создаются или проверяются папки input, data, state, results, reports, archive, Profiles.
Если входом является Excel, он кладется в input. Если входом является письмо, его текст, вложения и метаданные также нормализуются и сохраняются как артефакты запуска. На этом же шаге присваивается технический идентификатор запуска, который дальше будет проходить через весь процесс.
Этап 2. Первичная структурная валидация
До вызова LLM-агента полезно проверить, что вход вообще существует и минимально пригоден для обработки. Например:
- файл найден;
- вложение не пустое;
- таблица читается;
- есть хотя бы одна строка данных;
- присутствуют минимальные поля для дальнейшего разбора.
Если этого не сделать, агент начнет «думать» там, где проблема вообще не в смысле, а в отсутствии входа.
Этап 3. Агентный разбор
Здесь начинается работа LLM-слоя. Он получает не весь мир, а конкретный набор входных артефактов и правил.
На каждую строку или на логическую партию данных агент должен извлечь:
- исходное наименование;
- нормализованное наименование;
- артикул;
- единицу измерения;
- группу или категорию;
- производителя или бренд, если он значим;
- признаки новой позиции;
- признаки возможного дубля;
- недостающие поля;
- уровень уверенности;
- рекомендуемую ветку: создать / проверить вручную / отклонить / запросить уточнение.
Очень важно, чтобы на этом шаге агент работал не только как извлекатель, но и как детектор неопределенности. Его польза не в том, чтобы безошибочно «угадать всё», а в том, чтобы отделить хорошие кейсы от сомнительных.
Этап 4. Валидация ответа агента
Полученный ответ не должен немедленно идти в 1С ERP. Сначала его надо проверить.
Проверяются:
- корректность JSON-структуры;
- наличие обязательных полей;
- допустимость значений по справочникам;
- отсутствие запрещенных комбинаций;
- признаки дублей;
- порог уверенности.
Если ответ не проходит валидацию, строка не должна молча исчезать. Она должна попадать в results с понятным статусом и пояснением, а затем либо эскалироваться, либо уходить в отдельный контур ручной обработки.
Этап 5. Формирование batch-файла
После успешной валидации строки собираются в batch JSON. Это и есть точка передачи от смыслового слоя к исполнительному. Batch должен быть не просто временным файлом, а воспроизводимым артефактом запуска. По нему потом можно восстановить, что именно робот собирался создавать в 1С ERP.
Этап 6. Архивирование входа
Исходный Excel или иные входные файлы архивируются с меткой времени. Это важно и для контроля, и для расследования инцидентов, и для повторного запуска.
Этап 7. Открытие 1С ERP и подготовка сессии
Дальше начинает работать RPA-робот. Он открывает браузер с нужным профилем, переходит на страницу логина, дожидается формы входа, вводит логин и пароль, проверяет успешный вход и пишет state-файл готовности сессии.
Это типовая зона UI-автоматизации. Здесь важны корректные XPath/XPASS, тайм-ауты ожидания элементов и возможность проверить, что интерфейс действительно находится в нужном состоянии.
Этап 8. Открытие справочника номенклатуры
Робот переходит в справочник «Номенклатура» и дожидается готовности таблицы. После этого можно начинать цикл по batch-строкам.
Этап 9. Цикл по строкам партии
На каждую строку робот проходит один и тот же контур:
- читает строку из batch;
- еще раз проверяет обязательные поля;
- ищет совпадения в существующей номенклатуре;
- если совпадение уже существует и это подтверждено правилами — пишет соответствующий статус в results;
- если нужно создавать новую карточку — открывает форму создания;
- заполняет поля;
- сохраняет карточку;
- фиксирует результат;
- при ошибке пишет подробный статус и идет дальше.
Вот здесь и видно, почему агент не должен напрямую создавать карточки. Потому что поиск, ветка «уже существует», ветка «создать», запись результатов и контроль прохождения интерфейса — это задача исполнительного контура.
Этап 10. Завершение и отчетность
После обработки всех строк робот записывает итоговый results-файл, журнал log, итоговые state-маркеры, сохраняет отчеты и завершает процесс. Если часть кейсов эскалирована, формируется удобный список для оператора: что именно не было обработано автоматически и почему.
Где здесь находится человек
Человек в этом сценарии не должен заниматься рутинным набором карточек. Его роль — принимать решения по спорным кейсам. Например:
- найдено несколько возможных дублей;
- не хватает ключевых реквизитов;
- единица измерения не совпадает со справочником;
- есть риск завести неверную карточку;
- агент дал низкую уверенность.
В идеале человек получает уже подготовленный кейс: входные данные, кандидаты, пояснение агента, причину эскалации и удобную форму решения. Тогда ручной труд превращается не в механический ввод, а в точечное ответственное подтверждение.
Как это выглядит в логике процесса
Если записать архитектуру коротко, получится такая цепочка:
входной артефакт → нормализация → агентный разбор → валидация → batch JSON → вход в 1С ERP → поиск/создание карточки → results/log/state → архив/отчет → эскалация спорных кейсов.
Это уже не абстрактная «связка ИИ и робота», а конкретная производственная технология.
Какие ошибки здесь делают чаще всего
Ошибка первая: пытаться вести все типы входа через один и тот же примитивный шаблон. В результате письмо, PDF и Excel начинают обрабатываться одинаково, хотя у них разная природа.
Ошибка вторая: не делать явной валидации ответа агента. Тогда в 1С ERP начинают попадать тихие ошибки нормализации.
Ошибка третья: не разделять results и log. В одном месте тогда смешиваются бизнес-результаты по строкам и технический журнал процесса.
Ошибка четвертая: не фиксировать state-файлы между крупными секциями. Это резко усложняет отладку.
Ошибка пятая: позволять агенту принимать решения о создании карточки там, где есть риск дубля и высокая цена ошибки.
Решение и рекомендации
Первое. Для сценария регистрации номенклатуры почти всегда лучше строить гибрид, а не чистый RPA и не чистого агента.
Второе. Смысловой слой должен заканчиваться batch JSON, а не кликом по интерфейсу.
Третье. Валидация между агентом и 1С ERP обязательна.
Четвертое. Обязательно разделяйте входные артефакты, промежуточные batch-файлы, results, log, archive и state.
Пятое. Сомнительные кейсы не маскируйте под успех. Их надо честно собирать в контур ручной проверки.
Итог простыми словами
В регистрации новой номенклатуры LLM-агент нужен для того, чтобы понять и подготовить данные. RPA-робот нужен для того, чтобы надежно провести эти данные через 1С ERP. А человек нужен для того, чтобы взять на себя ответственность там, где автоматике уже нельзя принимать решение самостоятельно. Именно такая комбинация и дает зрелую гибридную автоматизацию.
Типичный сценарий правильного использования
Поставщик прислал прайс с новыми позициями. Агент извлек и нормализовал строки, выделил возможные дубли и подготовил batch. Робот вошел в 1С ERP, создал карточки для однозначных позиций, а спорные строки пометил для оператора. В результате ручная работа сократилась не за счет опасной автономии, а за счет правильного разделения ролей.
Типичный сценарий опасного использования
Команда заставляет одного и того же агента и читать прайс, и решать судьбу спорных строк, и создавать карточки, и считать процесс завершенным. Пока входы простые, это выглядит эффектно. Как только появляются неоднозначные названия и похожие карточки, автоматизация начинает плодить скрытые ошибки, которые обнаруживаются уже после того, как бизнес начал использовать некорректную номенклатуру.