«У нас старая учётная система, к ней нет API, автоматизация нам не светит». Эту фразу мы слышим почти на каждом втором разборе. Система работает пятнадцать лет, в ней вся история компании, разработчик давно недоступен, а документацию не видел никто из живых сотрудников. Менять её – год работы и риск парализовать учёт.
Хорошая новость: менять не нужно. Если в систему может войти сотрудник, в неё может войти и агент. Он видит тот же экран, читает те же поля и нажимает те же кнопки – просто не устаёт, не отвлекается и не ошибается в цифрах после обеда.
Как агент «видит» экран
UI-агент работает с интерфейсом на двух уровнях. Первый – структура: элементы окна, поля, таблицы, кнопки, их подписи и состояния. Второй – визуальный: агент смотрит на экран так же, как человек, и понимает, что перед ним форма накладной, что поле «Контрагент» ещё пустое, а система показала модальное окно с предупреждением.
Принципиальное отличие от классической роботизации в том, что агент понимает смысл, а не координаты. Старые скрипты запоминали «кликнуть в точку 640:480» – и ломались от любого сдвига макета. Агент ищет не точку, а «кнопку „Провести" в форме документа». Переехала кнопка, сменилась цветовая тема, добавилась колонка в таблице – агент продолжает работать, потому что ориентируется по смыслу элементов, как ориентировался бы человек.
| Способ | Что нужно от системы | Скорость | Где уместен |
|---|---|---|---|
| Интеграция по API | Документированный API | Максимальная | Современные CRM, банки, госсервисы |
| Работа с базой данных | Доступ к БД, знание схемы | Высокая | Чтение и отчётность, редко запись |
| UI-агент | Только учётная запись | Как у сотрудника и быстрее | Системы без API, устаревшие приложения |
На платформе эти способы комбинируются: где есть API – работаем через интеграции, где нет – через интерфейс. Для процесса разницы не видно: агент получает задачу «провести накладную» и сам выбирает путь до результата.
Сценарий: перенос заказов, который занимал два часа в день
Типичный случай с разборов. Оптовая компания: заказы приходят в CRM, а склад и учёт живут в системе 2009 года без API. Оператор дважды в день переносит заказы руками: открыл заказ в CRM, переключился в учётную систему, создал документ, выбрал контрагента из справочника, перебил 15–40 позиций, проверил цены, провёл. Два часа в день, порядка 44 часов в месяц, и стабильно 2–3% документов с опечатками – не потому, что оператор плохой, а потому что переносить цифры между окнами восемь лет подряд без ошибок не может никто.
Агент делает тот же маршрут: читает заказ из CRM, открывает учётную систему, находит контрагента (а если написание различается – сопоставляет по БИН), заполняет позиции, сверяет итоговую сумму с заказом и только при совпадении проводит документ. Не совпало – документ остаётся в черновике, а человек получает уведомление с указанием конкретной строки расхождения. Перенос, занимавший два часа, идёт фоном в течение дня по мере поступления заказов.
Журнал шагов: агент работает под запись
Главное возражение против «робота с мышкой» – неконтролируемость. Обоснованное: доверять учёт процессу, который нельзя проверить, никто в здравом уме не станет. Поэтому каждый шаг UI-агента журналируется: какое окно открыл, какое значение в какое поле ввёл, какую кнопку нажал, что система ответила. К критическим шагам – проведению, удалению, изменению сумм – прикладывается снимок экрана до и после.
Правило платформы: у каждого действия агента есть ответ на три вопроса – что сделано, на каком основании и как это отменить. Если хотя бы на один вопрос ответа нет, действие требует подтверждения человека.
На практике это даёт неожиданный эффект: работа агента прозрачнее работы сотрудника. Когда оператор ошибается в накладной, восстановить, как это произошло, почти невозможно. Когда с документом работал агент – есть полная трасса с экранами. Аудиторы и служба безопасности обычно оценивают это быстрее всех.
Что происходит, когда интерфейс меняется
Системы обновляются: вышел патч, переехала кнопка, форма получила новое обязательное поле. Для старой роботизации это означало «всё сломалось в пятницу вечером, чиним неделю». Поведение агента другое, и его стоит описать честно, по уровням.
Косметические изменения – сдвиги, переименования, новые темы оформления – агент проходит сам, потому что ищет элементы по смыслу. Изменения посерьёзнее, например новое обязательное поле, агент распознаёт как незнакомую ситуацию: он видит, что система не принимает документ, и не начинает жать кнопки наугад. Документ откладывается, человеку уходит уведомление с описанием того, что изменилось. После короткой донастройки – обычно это часы, а не недели – агент продолжает с отложенных документов. Ни один документ не проводится «вслепую» в изменившемся интерфейсе: это жёсткое правило платформы.
Ограничения, о которых мы говорим сразу
UI-агент – не волшебная палочка. Он медленнее прямого API: секунды на документ вместо миллисекунд. Для потока в сотни документов в день это неважно, для десятков тысяч транзакций в час – важно, и тогда нужен другой путь. Ему нужна стабильная среда: отдельная учётная запись с правами не шире, чем у сотрудника на этой операции, и рабочее место в контуре компании, где систему не будут дёргать параллельно. И он не исправляет хаос в процессе: если операторы заполняли справочник контрагентов как попало, агент этот беспорядок покажет, но разгребать дубли – отдельная задача, которую, впрочем, он тоже умеет.
Проверить всё это на своей системе можно без обязательств: прототип на вашем реальном сценарии мы настраиваем примерно за неделю, бесплатно – вы увидите, как агент проводит ваши документы в вашей системе. До продуктива – от 8 недель, платформа работает по подписке от 12 млн тенге в год. Чаще всего первым UI-сценарием становится именно первичка в бухгалтерии; записаться на разбор можно на странице контактов.
Частые вопросы
Чем UI-агент отличается от RPA-робота?
RPA исполняет жёсткий сценарий по координатам и селекторам: шаг влево – ошибка. Агент понимает смысл экрана и цель операции, поэтому переживает косметические изменения интерфейса и умеет останавливаться в незнакомой ситуации вместо того, чтобы ломать данные. Подробное сравнение – в статье про агентов, чат-ботов и RPA.
Под какой учётной записью работает агент и что с правами?
Под отдельной, выделенной именно ему. Права – минимально необходимые для операции: агент, который проводит накладные, не имеет доступа к зарплатной ведомости. Все действия записи видны в журнале системы и в журнале платформы, так что вопрос «кто это сделал» решается за минуту.
Система очень медленная и иногда зависает. Это проблема?
Нет, это обычная среда для UI-агента. Он ждёт отклика интерфейса, распознаёт зависание, умеет закрыть сессию и повторить операцию с контрольной точки – не создавая дубль документа. Именно на «капризных» системах выигрыш заметнее всего: агент терпеливее человека.