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