Лабораторная работа №3: создаем процессного ассистента. А где здесь LLM?

Последние пару лет вокруг нас появляется огромное количество историй о том, что LLM вот-вот станут полноценными сотрудниками компаний.

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

Мы решили не спорить с этой идеей, а провести очередной эксперимент в нашей небольшой лаборатории. На этот раз задача звучала просто: создать процессного ассистента, который бы последовательно выполнил 2 действия –

• Создал контрагента в 1С.ДО

• Создал проект в Redmine

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

В ходе эксперимента мы обнаружили вещь, которая немного противоречит сегодняшнему представлению об AI-агентах: Для значительной части работы LLM вообще не понадобилась.

Разумеется LLM быстро собирает программы, которые нам помогли, но остается вне процесса. Конечно, до эры LLM – никто бы такой стенд собираться не стал – слишком дорого, слишком долго и непонятно зачем.

Что мы автоматизируем

Возьмем вполне практический сценарий в любом IT интеграторе. Компания победила в тендере на внедрение 1С системы и нужно создавать записи о новом проекте и контрагенте в текущем информационном ландшафте.

Традиционный подход заключается в следующем

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

• Далее звонок/письмо в бухгалтерию с темой «новый проект». В ответ – «пришлите название контрагента».

• Название, ИНН отправлено в бухгалтерию – завтра уже можно звонить и уточнять

• Уже через 3 дня новый контрагент создан в 1С Документообороте и на вопрос «что дальше» - бухгалтер пожимает плечами – про Redmine она не знает ничего.

• Через главного системного администратора узнаем, что новый проект должен появиться в базе Redmine – и к этому проекту можно создавать задачи

• Чертыхаясь, Руководитель проекта раздает поручения и просьбы и выступает очень дорогим передаточным звеном -«благо сейчас начну проект и этот ужас закончится»

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

Даже в самом сложном случае – подготовка к старту проекта занимает в среднем 2 недели активностей, без которых кажется нельзя обойтись.

Такое «дано» для текущей лабораторной работы

«Ожидаемый результат»

• Пользователь пишет в Telegram: «Начинаем новый проект».

• Все как-то делается само собой, нужные данные Бот просит у пользователя, во всех нужных системах создаются новые элементы.

«Решение»

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

В системе управления разработкой создается заявка. Заявка состоит из шагов Каждая шаг имеет название и исполнителя.

Один шаг выполняется в 1С ДО. Другой — через браузер, так как Redmine именно там и работает.

То есть в конечном счете одна фраза пользователя превращается в цепочку вполне конкретных действий. В реализованном кейсе создание контрагента в 1С и проекта в Redmine уложилось в 1 минуту и не отвлекло никого в компании, сожжено 0 «священных» токенов.

Как и сказано выше LLM не задействован, а используется алгоритм и сценарии работы пользователей.

Где живет процесс

Ключевым элементом эксперимента стала система, в которой мы храним описание бизнес-процессов - ERP-tools. Но нам оказалось недостаточно просто хранить BPMN-схему или последовательность шагов.

Нам нужно было описывать сценарии функции — конкретные действия, которые умеют выполнять наши живые исполнители.

И опять нам попалась «функция» - однократное действие пользователя. Это максимально полезный артефакт.

Например:

• Создать проект в 1С;

• Создать проект в Redmine;

• Назначить руководителя проекта;

• Создать заявку на комплектование команды и т.д.

Практически все наши рабочие «человеческие действия» - это и есть «функции». И пока остальные интеграторы старательно описывают функции в WORD документах – мы их фиксируем как ключевой артефакт в ERP-tools и фактически используем как базу знаний.

Процесс в таком случае становится не абстрактной картинкой, а последовательностью функций. Процесс отвечает на вопрос «что и в каком порядке делаем?». Функция отвечает на вопрос «что делаем», а сценарий -«как делаем».

Заявка становится экземпляром процесса

В обычной системе управления разработкой заявка чаще всего означает просьбу: кому-то нужно что-то сделать. В нашем эксперименте смысл несколько другой. Заявка — это экземпляр бизнес-процесса «Создание нового проекта»

У каждой функции есть входные данные (переменные), исполнитель, постановщик, сценарий и ожидаемый результат.

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

А заявка становится механизмом запуска и контроля этой последовательности.

Telegram: разговор с человеком

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

Он просто говорит:

«Начинаем новый проект».

Ассистент может задавать вопросы:

• «Для какого клиента?»

• «Как называется проект?»

• «Кто руководитель проекта?»

Ответы превращаются в переменные процесса.

И здесь действительно может пригодиться LLM. Она хорошо подходит для работы с естественным языком: понять намерение пользователя, извлечь значения из свободного текста, переспросить, если данных не хватает. На этом этапе мы общаемся через выбор нужного проекта и операции, но подключить голосовое распознавание и поиск внутри ERP-tools, чтобы на просьбу голосом

«ё, нужно новый проектик замутить!»

уже настоящий ИИ-агент найдет что ответить

Что должно быть на стороне ERP-tools

Упростим пример до 2 шагов для старта нового проекта

1. Создание контрагента в 1С ДО

2. Создание нового проекта в Redmine.

Принципиальна тут работа не только с 1С, но и веб-приложением.

Сложная услуга

В ERP-tools мы должны создать сложную услугу - «Создание нового проекта» с 2 последовательными шагами. В нашем случае для создания контрагента нужно название контрагента, ИНН и КПП, а для создания проекта в Redmine – название проекта, при этом у каждого шага могут быть самостоятельная пара Постановщик задачи – выполняющий.

Например, можно сделать шаг «согласование создания нового контрагента финансовым директором» - и тогда ФД будет участвовать в процессе и без его резолюции ничего сделано не будет. Но в нашем случае, исполнителем шага будет являться специальный пользователь «ИИ-агент», который ассоциируется с телеграм-ботом

Функция с сценарием работы робота

Эти шаги услуги имеют прямую связь с «функцией», где хранятся файлы сценариев, подготовленные в особых программах, о которых ниже.

Информационный пакет процесса

Содержит названия переменных, необходимых для всего процесса

Работа Телеграм бота

Получив согласие бот посредством MCP интерфейса к ERP-tools создает заявку, которая стартует по первому шагу – «Создать контрагента в ДО»

Создав заявку бот тут-же понимает необходимость сбора данных о переменных, необходимых роботу, о чем просит пользователя

Получив нужный ответ бот вызывает нужный сервис внутри ERP-tools, который формирует пакет данных из файла сценария и файла переменных и выгружает его в особую папку в сети

Дальше работают обычные роботы

После создания заявки процесс начинает выполнять свои функции. Если функция относится к 1С, ее выполняет специализированный 1С Тестировщик. Если нужно работать с системой, работающей в браузере, используется WebRobot (это наша разработка). Он открывает браузер, находит нужные элементы интерфейса, вводит данные и выполняет необходимые действия.

1С Тестировщик

Простой интерфейс, который позволяет записать любое действие пользователя

Робот как будто выполняет задачу от имени человека. Открыл нужную форму, нажимает нужные кнопки

Webrobot

Аналогичная задача – сначала записи действий пользователя в сценарий

Потом выполнение нужного сценария с нужными переменными

Получается своеобразная эстафета:

Telegram → SD → функция → исполнитель → результат → следующая функция.

При этом исполнителям совершенно не обязательно понимать весь бизнес-процесс.

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

И тут мы задали неприятный вопрос: а где здесь LLM?

В какой-то момент мы посмотрели на работающий сценарий и задали себе простой вопрос:

А где здесь искусственный интеллект? Вся эта цепочка может работать без LLM.

Причем именно это оказалось одновременно самым приятным и самым немного грустным открытием эксперимента.

LLM помог нам собрать WebRobot, который умеет записывать макрос из действий пользователя в браузере и потом имитировать работу пользователя в этом же браузере, но уже с другими переменными.

LLM также помогла собрать программу управления Ботом.

Почему это здорово

С точки зрения автоматизации результат впечатляет. Человек не открывает несколько информационных систем, не ищет нужные формы, не копирует данные из одной системы в другую, не объясняет каждому исполнителю, что произошло на предыдущем шаге. Он сообщает намерение, отвечает на вопросы и получает результат.

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

LLM не знает вашу компанию

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

• Какие процессы существуют?

• Какие информационные системы используются?

• Какие функции в них доступны?

• Какие поля обязательны?

• Какие роли имеют право запускать процесс?

• Какие роботы умеют выполнять конкретные действия?

• Что делать при ошибке?

• Как выглядит успешное завершение операции?

Этого знания нет в универсальной LLM и более того LLM может ошибаться.

Базу знаний сначала необходимо каким-то образом получить, структурировать и поддерживать в актуальном состоянии. И именно здесь, похоже, находится одна из самых больших практических задач создания корпоративных AI-агентов.

Наш эксперимент, конечно, не показывает, что LLM не нужны. Скорее наоборот. Он показывает, что у LLM и детерминированной автоматизации разные зоны ответственности.

LLM хорошо подходит там, где присутствует неопределенность:

• понять намерение человека;

• обработать естественный язык;

• извлечь данные из свободного текста;

• сопоставить запрос с возможным процессом;

• объяснить пользователю результат;

• обработать нестандартную ситуацию;

• помочь выбрать следующий шаг.

Если функция формализована и надежно автоматизирована, ее гораздо разумнее выполнить именно как функцию.

Цифровая модель компании

И здесь эксперимент приводит нас к несколько другой картине будущего. В центре оказывается не сама LLM, а цифровая модель компании «цифровой двойник» или База Знаний. В ней описаны процессы, функции, информационные системы, роли, объекты и связи между ними. LLM становится интерфейсом и интеллектуальным слоем над этой моделью.

Человек говорит, чего хочет, LLM помогает понять запрос. Цифровая модель определяет, какие процессы и функции соответствуют этому запросу, а исполнители делают конкретную работу.

И мне кажется, что это гораздо более реалистичная архитектура корпоративного AI-агента, чем идея одной универсальной нейросети, которая просто «умеет работать в компании».

В работе использовалось следующее ПО

• ERP-tools. ФМ - хранение информации о бизнес-процессах компании

• ERP-tools. SD – таск трекер для сложных услуг

• Telegram-бот – общение с пользователями, сбор данных

• 1С-тестировщик – запись сценария работы пользователя и имитация работы пользователей в 1С

• Python по управлению Telegram-ботом

• WebRobot - запись сценария работы пользователя и имитация работы пользователей в браузере

Если интересно воспользоваться результатами исследований - свяжитесь в нами