RPA — це програма, яка керує іншими програмами через їхній інтерфейс. Відкриває портал, логіниться, знаходить поле, вводить значення, натискає «зберегти». Швидко, без утоми і — головне — працює з системою, у якої немає ні API, ні вивантаження. Заради цього RPA й існує.
Мовна модель робить зовсім інше: перетворює неструктурований вхід на структуру. З листа, скана накладної чи розшифровки дзвінка вона дістає поля, з якими можна працювати далі. Вона нічого не клікає і не переносить дані між системами. Це дві взаємодоповнювальні здатності, а не альтернативи, — тому питання у звичному формулюванні відповіді не має.
Майже завжди процес приходить до нас із готовим припущенням: хтось вирішив, що це задача для RPA чи для AI, ще до того, як подивилися, що взагалі вміють системи. Дешевше йти трьома варіантами по черзі.
API або база. Якщо він є в обох систем — це і є відповідь. Швидше, дешевше в експлуатації, переживає редизайн інтерфейсу і падає гучно, а не тихо. Перевіряти треба насамперед, зокрема у вендорів, які про API не писали.
Файл, який система й так робить. Нічне вивантаження, звіт, CSV, який хтось завантажує руками. Некрасиво і абсолютно надійно — і знімає більшість приводів водити мишкою по екрану.
І лише потім робот. Автоматизація на рівні екрана — це те, що лишається, коли до системи справді не дотягнутися інакше. Це нормальний варіант, просто третій, а не перший.
Модель може стояти всередині будь-якого з трьох варіантів і зазвичай там і стоїть: читає те, що прийшло текстом, і віддає структуровані поля кроку, який переносить дані.
Є робота, яку більше нічим не зробити. Легасі-системи з термінальним інтерфейсом, у яких уже немає в кого спитати. Державні та банківські портали без API — і без планів його зробити. Десктопні застосунки, ліцензія яких забороняє лізти в базу напряму. У таких випадках робот на екрані — не компроміс, а єдиний шлях, і шлях цілком робочий.
Ламається все на масштабі задачі. Бот, який заходить в один портал, завантажує виписку і кладе її в теку, проживе роки. Бот, який проклікує чотирнадцять екранів у чотирьох системах, кожну з яких хтось переробляє без попередження, перетворюється на обслуговування, що тихо коштує дорожче за роботу, яку він замінив.
RPA ламається об верстку. Кнопка, що переїхала, нове вікно згоди, повільне завантаження, зайвий крок підтвердження — робот не розуміє екран, він іде за координатами й селекторами. Оновлення вендора — його природний ворог.
Модель ламається об упевненість. Вона не зупиняється, коли не впевнена, а видає гладку правдоподібну неправильну відповідь. Лікується порогами, посиланнями на джерело і маршрутом до людини, а не надією.
RPA падає помітно, модель — тихо. Зупинений бот — це алерт. Неправильно прочитане поле йде в облік і знаходиться на закритті місяця. Другий сценарій вимагає обережнішої конструкції.
Обидва ламаються об невирішену політику. Якщо ніхто не записав, що робити з винятком, жодна з технологій відповіді не вигадає. Це управлінське рішення в технічному костюмі.
Випишіть кроки одного процесу і позначте в кожного, що йому потрібно: перенести дані чи щось інтерпретувати. Далі по кожному кроку «перенести» спитайте, чи є вже API або вивантаження, — питайте у вендора напряму, бо в документації цього часто немає. Те, що лишиться після цих питань, і є чесна площа для RPA, і вона зазвичай помітно менша, ніж здавалося.
За нашим досвідом відповідь найчастіше така: невелика інтеграція плюс модель на одному-двох кроках, де читається мова, і жодного робота взагалі. Якщо робот усе ж потрібен, ми тримаємо його в найвужчих межах — одна система, один шлях по екранах, — щоб редизайн коштував вечора, а не переробки.
Ми робимо цю розмітку безкоштовно на міні-аудиті: кроки, що потрібно кожному, у яких систем є API, про який ви не знали, і що потрібно, щоб обійтися без екранного робота.
Ми використовуємо cookie лише для аналітики — щоб бачити, з яких сторінок приходять заявки. Нічого більше й нічого до вашої згоди. Політика cookie