Ищем сценарии, где ИИ может нам помочь
Последние пару лет вокруг нас появляется огромное количество историй о том, что 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С ДО
Создание нового проекта в 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 - запись сценария работы пользователя и имитация работы пользователей в браузере
Если интересно воспользоваться результатами исследований - свяжитесь в нами