RPA-боты с компьютерным зрением: где ломается обычная автоматизация
Часть систем в контуре заказчика не отдаёт данные программно: API нет, интеграционный шлюз не предусмотрен, а сам клиент — окно терминала или тонкий веб-фронт с закрытой авторизацией. Именно здесь автоматизация упирается в узкое место: данные между учётной системой, почтой и таблицами переносит человек руками, потому что другого доступа к интерфейсу не существует.
Цена этого узкого места растёт незаметно. Оператор держит в голове порядок окон, копирует реквизиты, сверяет статусы — и как только поток заявок увеличивается, он становится ограничителем всего процесса: очередь копится, ошибки переноса всплывают на следующих этапах, а отпуск или больничный останавливает обмен данными.
Классический бот ломается здесь предсказуемо. Он привязан к разметке страницы или к координатам кнопок, поэтому сбои на обновлении формы — штатный сценарий: сдвинулся блок, поменялся порядок полей, добавился шаг подтверждения — и робот либо падает, либо записывает данные не в то поле. Переписывать сценарий под каждое изменение интерфейса дороже, чем оставить ручной перенос.
RPA-боты с компьютерным зрением снимают это ограничение: робот распознаёт поля, кнопки и таблицы по изображению экрана и работает с ними так же, как человек, не требуя ни API, ни доступа к внутренней разметке. Разбираем, как это закрывается на практике.
Эффект от внедрения: скорость, устойчивость, разгрузка людей
Скорость обработки одной операции перестаёт зависеть от темпа человека. Робот проходит сценарий целиком — находит окно, распознаёт поля, заполняет, подтверждает — и тратит на это секунды вместо минут у оператора. Важнее другое: на тысячной итерации он работает так же, как на первой, без усталостной ямы к концу смены.
Доля операций без участия человека обычно держится на уровне 70–85%: всё, что укладывается в правило — типовые счета, заявки, сверки — идёт полностью автоматически. Остаток попадает в очередь исключений, где оператор разбирает только нетиповые случаи, а не весь поток целиком. Загрузка сотрудников на рутине падает: люди переходят на спорные операции и работу с клиентом.
Заодно уходит целый класс отказов — ошибки ввода. Перепутанный столбец, опечатка в реквизите, значение не в том поле: зрение читает данные так же, как их видит человек, а проверка по правилам и справочнику отсекает некорректное до записи в систему. То, что раньше ловилось только на сверке, просто не возникает.
Восстановление после сбоя — больное место ботов на жёстких скриптах: сместилась кнопка, обновился интерфейс, отвалилась сессия. Сценарии строим с точками сохранения состояния: после падения робот повторяет шаг с последней подтверждённой операции, а не начинает цикл заново, и оставляет снимок экрана для разбора. Время восстановления измеряем минутами вместо часов ручной досборки — простой считается временем, а не переработками команды. Тот же принцип устойчивости заложен в зрелых платформах вроде UiPath.
Режимы работы робота: от снимков экрана до гибридных схем
Режим работы робота выбирается не по вкусу, а по тому, сколько доступа даёт целевая система. Если у неё есть открытый программный интерфейс — идём через него: это самый быстрый и предсказуемый путь. Если система закрыта и живёт только как окно приложения, остаётся распознавание экранных форм и эмуляция действий пользователя.
Ключевой критерий выбора — устойчивость к смене вёрстки. Привязка к координатам рассыпается от любого обновления, привязка к именам элементов — от переименования, а распознавание по визуальным признакам переживает переезд кнопки. Поэтому в реальных контурах почти всегда выигрывает гибридный сценарий автоматизации: часть шагов идёт по данным, часть — по картинке.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Программный интерфейс | У системы открыты точки обмена данными | Часть операций всё равно проходит только через окно |
| Работа по элементам окна | Вёрстка стабильна и меняется редко | Ломается при обновлении разметки или смене версии клиента |
| Распознавание по снимкам экрана | Система полностью закрыта, внутренних данных нет | Нужны эталонные профили экрана и стабильный масштаб |
| Гибридный сценарий | Часть шагов открыта, часть — только визуально | Сложнее в поддержке: требуются и правила распознавания, и логика обмена |
Отдельно закрываем обработку нестандартных окон — модальные диалоги, предупреждения, окна выбора файла. Под них пишутся свои правила распознавания и время ожидания, иначе робот встанет на первом же всплывающем окне, которого не было в записи сценария.
Как мы внедряем робота: этапы инженерной работы
Робот ломается не на сложной логике, а на редкой ветке процесса, которую не увидели на старте. Поэтому работа идёт от реальных действий сотрудника к сценарию: сначала фиксируем, что происходит в интерфейсе, затем пишем автоматизацию и выводим её в эксплуатацию.
- Обследование процесса. Разбираем шаги сотрудника по порядку: откуда приходят данные, в каких системах работаем, какие операции повторяются, а какие требуют решения человека. На выходе — перечень шагов с частотой и оценкой, что автоматизируем полностью, а что оставляем на согласование.
- Карта экранов и переходов. Фиксируем каждый элемент, который робот должен найти, состояния загрузки, всплывающие окна и порядок переходов между формами. По карте сразу видно, где сценарий упрётся в изменение интерфейса.
- Настройка сценария робота. Собираем логику на поиске элементов по визуальным признакам, а не по координатам на экране: при смещении блоков робот продолжает работу, а не кликает в пустоту.
- Проверка на исключениях. Прогоняем сценарий на нештатных ситуациях — пустая выборка, долгий ответ системы, изменившаяся форма, истёкшая сессия. На каждый случай своя ветка и запись в журнал, чтобы разбор занимал минуты.
- Тестовый прогон. Сверяем результат робота с работой сотрудника на накопленных данных и смотрим расхождения: они показывают, каких проверок не хватает.
- Передача в эксплуатацию. Отдаём документацию и регламент запуска и разбора сбоев, обучаем тех, кто будет управлять сценариями и менять их без нас.
Комплект передачи: схемы, регламенты, инструкции оператора
После сдачи у заказчика остаётся не только работающий робот, но и комплект, по которому его команда сама разворачивает сценарии, меняет доступы и разбирает сбои без нашего участия.
- Схема сценария робота — шаги обработки операции с точками ветвления, условиями остановки и местами обращения к учётной системе. По ней видно, какой сбой останавливает процесс, а какой уводит робота в повтор.
- Рабочая конфигурация сценариев — параметры распознавания, шаблоны экранных форм и пороги уверенности, вынесенные наружу. Порог правится без изменения кода.
- Регламент запуска и перезапуска — порядок старта, действия при зависшем окне и правила продолжения с прерванной операции, чтобы не появилось дублей.
- Правила доступа к учётным записям — какие права нужны роботу, как заводится отдельная сервисная учётная запись и как отзывается доступ при смене пароля или уходе сотрудника.
- Инструкция оператора — расшифровка статусов, действия при типовой ошибке распознавания и момент, когда нужно звать поддержку. Рассчитана на сотрудника без опыта разработки.
- Журнал обработки операций — по каждой операции время, результат и снимок спорного шага. Это и доказательство для аудита, и материал для настройки порогов.
- Карта зависимостей — какие экранные формы и интерфейсы учётных систем затрагивает робот и что ломается при их обновлении.
Комплект собран так, что типовые задачи — смена пароля, перезапуск после сбоя, разбор зависшей операции — команда заказчика закрывает сама. Поддержка остаётся, но не как единственная точка входа для любого изменения.
Кейс: обработка заявок в системе без программного доступа
Дистрибьютор стройматериалов принимал заявки почтой и через форму на сайте, а операторы вручную переносили их в учётную систему 1С без опубликованного программного интерфейса. Одна заявка — 12-14 полей: контрагент, номенклатура, объём, адрес доставки, сверка остатка и цены.
К открытию смены в очереди оставалось 400-600 необработанных заявок: письма, пришедшие ночью, ждали оператора, а время реакции на обращение доходило до 6 часов. Три оператора были заняты однотипным вводом, а после акций график ломался: часть заявок уезжала на следующий день.
Обработку заявок RPA-ботом с компьютерным зрением построили так: агент работает в том же окне программы, что и человек, распознаёт форму, поля и строки табличной части по изображению, подставляет данные из письма и подтверждает операцию. При несовпадении — новый контрагент, незнакомая номенклатура, расхождение цены — заявка помечается и уходит оператору.
Очередь заявок до и после несопоставима: к началу смены остаётся 40-50 позиций, время реакции на обращение сократилось до 10-15 минут. Робот закрывает около 900 заявок в сутки, доля исключений, которые требуют человека, — 6-8%. Двое операторов перешли на сверку расхождений и работу с новыми контрагентами.
Метрики до и после держатся не на скорости набора: по каждой операции пишется журнал — что распознано, что записано, на каком шаге агент остановился. Тот же контур потом переносят на подтверждение отгрузок, акты и возвраты.
Что делать, если целевая система обновила интерфейс?
Сценарий цепляется не за координаты кнопки, а за устойчивые признаки элемента: текст подписи, роль в дереве доступности, иконку, соседние метки, относительное положение в блоке. Обновление интерфейса целевой системы — перенос кнопки в другой угол, смена цвета, перестановка полей — такие признаки сохраняет, и сценарий продолжает работать без вмешательства.
Когда переработка глубже: изменили формулировку подписи, добавили шаг подтверждения, разбили форму на два экрана — бот ищет элемент по совокупности признаков и, если уверенность распознавания просела, не жмёт наугад, а фиксирует расхождение в журнале. Правка сценария после обновления сводится к нескольким действиям: обновить эталон области, добавить новый признак в описание шага, дописать ветку для появившегося окна.
Контроль работоспособности сценариев держим регулярным прогоном на тестовом контуре: бот проходит маршрут, результат сверяется с ожидаемым, при отклонении приходит уведомление снимком проблемного экрана. Так обновление в целевой системе видно до того, как оно задело боевой процесс, и правка занимает часы, а не недели простоя.
Резервный маршрут обработки закрывает случай, когда интерфейс поменяли принципиально: если уверенность распознавания ниже заданного порога, задача уходит через программный обмен, файловый канал или на оператора — данные не теряются и не дублируются. Сравнение областей и поиск шаблонов строим на открытой библиотеке машинного зрения OpenCV, поэтому пороги чувствительности настраиваются под конкретный экран, а не берутся наугад.
Практический итог: вёрстка живёт своей жизнью, а сценарий остаётся работоспособным, потому что опирается на смысл элемента, а не на его координаты.
Частые сомнения: устойчивость, доступы, сопровождение
Сомнения у инженеров и руководителей обычно одни и те же, и они справедливы: робот работает поверх интерфейса, значит зависит от вёрстки, доступов и поведения людей. Показываем, как каждый риск закрывается на уровне сценария и регламента, а не обещаний.
Как отсекаются ложные срабатывания распознавания?
Элемент ищется по совокупности признаков — место в форме, подпись рядом, состояние поля, — а не по одному фрагменту картинки. При низкой уверенности робот пробует альтернативный эталон и делает контрольный снимок; если совпадения нет, шаг останавливается и уходит оператору, а не выполняется наугад. Спорные кадры копятся в журнале и уходят в обновление эталонов.
Какие права доступа получает робот?
Отдельная учётная запись с минимально нужным набором прав: только те разделы и операции, что описаны в сценарии. Это же снимает риск двойного ввода данных — повторный запуск не создаёт вторую заявку, а сверяется с уже сделанным. Каждое действие пишется в журнал с привязкой к шагу сценария.
Как разбираются инциденты и что с сопровождением после передачи?
На каждый сбой сохраняется снимок экрана, лог шагов и версия сценария — по ним за минуты видно, что изменилось: элемент интерфейса, права или ответ смежной системы. Передаём регламент сопровождения: мониторинг прогонов, реакция на остановки, обновление эталонов после изменений в обслуживаемой системе.
Обсудим задачу: вернёмся с оценкой и планом внедрения
Точная оценка сроков внедрения получается не из фразы «хотим, чтобы бот повторял действия оператора», а из данных о процессе и среде, где ему предстоит работать. Ниже — минимальный комплект, который позволяет вернуться с планом работ по автоматизации, а не с вилкой «от и до»: чем конкретнее исходные, тем меньше допущений в смете и тем выше шанс, что бот выйдет в продуктив без переделок распознавания.
- Перечень целевых систем — где именно работает процесс: десктоп-клиент, терминал, устаревшее окно без API, веб-формы, сканы и вложения из почты. По этому списку мы определяем, что закрывается компьютерным зрением, а что — штатным программным интерфейсом.
- Доступы для обследования — тестовый стенд или песочница с учётной записью нужных ролей, копия справочников, обезличенная выборка записей. Без этого обследование превращается в опрос, а не в замер.
- Описание процесса — шаги оператора по порядку, точки принятия решений, где он сверяет данные вручную и по какому правилу выбирает вариант.
- Образцы входных данных — реальные экраны, сканы, фотографии и письма, включая неаккуратные: засвеченные, повёрнутые, с рукописными пометками.
- Объём и частота — сколько операций в смену, как распределена нагрузка в течение дня и в какое окно бот обязан укладываться.
- Нештатные ситуации — что сейчас делает человек, когда данные не сходятся, а также кто в компании отвечает за изменения в интерфейсах целевых систем.
- Критерии приёмки — как договоримся считать результат: доля операций, закрытых без ручного вмешательства, и класс ошибок, который для вас недопустим.
Если часть данных закрыта — присылайте то, что есть: пробелы закрываем на обследовании и выносим отдельными этапами плана. Опишите задачу в свободной форме и укажите, к какому сроку нужен результат, — вернёмся с оценкой и планом внедрения.
