Model, który klika, to wciąż bot ekranowy

Większość wdrożeń RPA przechodzi tę samą drogę. Boty powstają szybko, żeby połączyć systemy bez integracji, w pierwszym roku oszczędzają prawdziwy czas, a potem koszt utrzymania rośnie z każdą zmianą ekranu, każdym nowym szablonem dostawcy i każdym okienkiem, które pojawiło się po aktualizacji. W końcu zespół od botów więcej naprawia, niż buduje.

Obecna propozycja brzmi: zastąpmy boty agentami AI, które patrzą na ekran jak człowiek i dostosowują się, gdy coś się zmieni. To propozycja w połowie trafna, a chybiona połowa jest tą droższą.

Trzy różne rodzaje kruchości

O botach mówi się, że są kruche w ogóle. Są kruche na trzy konkretne sposoby i ma znaczenie, który z nich akurat boli.

Przywiązanie do ekranu. Bot znajduje pole po położeniu albo identyfikatorze elementu. Wystarczy przesunąć pole, zmienić mu nazwę albo dodać okno potwierdzenia, a bot staje.

Przywiązanie do szablonu. Bot czyta wejście sztywnymi regułami: numer faktury jest w tym polu na układzie tego dostawcy. Nowy układ daje pustkę albo, gorzej, złą wartość z dobrego miejsca.

Przywiązanie do szczęśliwej ścieżki. Bota nagrano, gdy robił to, co człowiek robi w zwykły dzień. Wyjątki obsługiwała osoba siedząca obok i nikt nie zapisał, jak.

Co model naprawia, a czego nie

Drugi rodzaj model naprawia dobrze. Przeczytanie dokumentu, którego nigdy nie widział, i zwrócenie ustrukturyzowanych pól to dokładnie to, w czym jest dobry — i znika utrzymanie szablonów, które każdy zespół od botów zna aż za dobrze.

Pierwszego rodzaju nie naprawia, tylko zmienia sposób, w jaki się psuje. Bot z zepsutym selektorem staje z błędem — głośno, irytująco i bezpiecznie. Model sterujący ekranem, który się zmienił, może znaleźć pole wyglądające na właściwe, wpisać w nie wartość i pracować dalej. Głośna awaria zamienia się w cichą, przy wyższym koszcie transakcji i z przebiegami trudniejszymi do odtworzenia, bo dwa przebiegi po tym samym ekranie nie muszą pójść tą samą drogą.

Trzeciego rodzaju nie naprawi żadna technologia. Wyjątki wymagają projektu, niezależnie od tego, co klika.

Zejdźcie poniżej ekranu

Dla każdego bota użyteczne pytanie nie brzmi „co go zastąpi”, tylko „skąd jeszcze mogą przyjść albo dokąd trafić te dane”. Mniej więcej w tej kolejności: API systemu, jego zdarzenia albo kolejki komunikatów, wymiana plików, którą już obsługuje, a dopiero na końcu ekran.

Infografika

Gdzie podłączyć automatyzację

API systemuZdarzenia i kolejkiWymiana plikówAutomatyzacja ekranu

StabilneKruche

Wiele systemów, których dotykają boty, oferuje którąś z pierwszych trzech dróg. Nie użyto ich, bo bot powstawał szybciej niż zgłoszenie integracyjne — i ta wymiana wyglądała dobrze, dopóki nie przyszło utrzymanie. Stare systemy bez żadnego interfejsu istnieją. Dla nich bot na stabilnym ekranie jest rozsądną odpowiedzią: zostawcie go, monitorujcie i przestańcie oczekiwać, że obsłuży wyjątki.

Model ma swoje miejsce na wejściu, tam, gdzie dane istnieją tylko jako dokument albo wolny tekst — faktura dostawcy, mail od klienta, zeskanowany formularz. Zamienia dokument w ustrukturyzowaną propozycję, którą zwykły kod sprawdza, zanim cokolwiek zostanie gdziekolwiek zapisane.

Posortujcie boty, zamiast je migrować

Program przerabiający boty na agentów jeden do jednego dziedziczy każdą decyzję procesową, którą boty zamroziły. Zamiast tego posortujcie je.

Wyłączyć. Proces się zmienił albo dane są już dostępne inną drogą. Warto to sprawdzić najpierw, bo jest tańsze od każdej przebudowy.

Przebudować poniżej ekranu. Integracja przez API, zdarzenia albo plik, z modelem tylko tam, gdzie trzeba przeczytać dokument.

Zostawić. Stabilny ekran, rzadkie zmiany i brak innego interfejsu. Nie ruszajcie go i przeznaczcie wysiłek na coś innego.

Rejestr zgłoszeń utrzymaniowych jest gotowym uzasadnieniem biznesowym. Boty generujące najwięcej zgłoszeń są miejscem startu, a same zgłoszenia mówią, na który rodzaj kruchości każdy z nich cierpi.

Co boty naprawdę robiły

Przy bliższym spojrzeniu większość parku RPA przenosi dane między systemami, które nie miały innego sposobu, żeby się porozumieć, i czyta dokumenty, których nikt porządnie nie sparsował. Jedno i drugie to problemy z danymi, z doklejonym na wierzchu interfejsem użytkownika.

Dobra wymiana botów to więc w większości inżynieria danych dla AI: pobieranie przyrostowe i obserwowane z niewygodnych źródeł, po których boty dotąd klikały, dokumenty parsowane i sprawdzane, zanim ktokolwiek im zaufa, oraz awarie, które są głośne — jedyna cecha starych botów warta zachowania.