Roboty RPA - jak automatyzują pracę na komputerze?

Otwiera wiadomość e-mail, pobiera załącznik, odczytuje numer faktury, przepisuje dane do programu księgowego i zapisuje dokument w odpowiednim katalogu. Po kilku sekundach przechodzi do następnej wiadomości. Nie jest pracownikiem siedzącym przed monitorem, ale programem, który wykonuje wcześniej przygotowaną sekwencję czynności. Tak działają roboty programowe RPA, coraz częściej wykorzystywane do automatyzowania powtarzalnej pracy na komputerze. Choć nazwa może kojarzyć się z mechanicznymi maszynami, taki robot nie ma ramion, silników ani czujników ruchu. Jego środowiskiem pracy są aplikacje, dokumenty i systemy informatyczne. Jak właściwie działa i dlaczego czasami lepiej zastosować zwykły skrypt niż rozbudowanego bota?

Robot, którego nie widać - czym jest RPA?

Słowo "robot" przywodzi na myśl mechaniczną konstrukcję wykonującą zadania w fabryce, magazynie albo laboratorium. Tymczasem w informatyce robotem nazywa się również oprogramowanie, które potrafi samodzielnie wykonywać określone operacje w systemach komputerowych. RPA, czyli Robotic Process Automation, jest właśnie technologią pozwalającą automatyzować czynności realizowane dotychczas przez użytkownika przy pomocy myszy, klawiatury i interfejsu aplikacji.

Robot programowy może uruchomić przeglądarkę, zalogować się do systemu, wyszukać dokument, skopiować informacje i umieścić je w innej aplikacji. W zależności od zastosowanego narzędzia wykorzystuje identyfikatory elementów interfejsu, mechanizmy automatyzacji aplikacji, a czasem rozpoznawanie obrazu i tekstu. Nie musi rozumieć wykonywanej pracy tak, jak rozumie ją człowiek. W klasycznym RPA działa przede wszystkim na podstawie reguł, warunków i kolejności operacji przygotowanych podczas konfiguracji.

Warto odróżnić robotyzację programową od robotyzacji przemysłowej. W pierwszym przypadku automatyzujemy działania w świecie cyfrowym, a w drugim wykorzystujemy urządzenia fizyczne do wykonywania konkretnych operacji. Oba rozwiązania mieszczą się w szerszym pojęciu robotyzacji i jej zastosowań, ale różnią się wymaganym sprzętem, sposobem sterowania i rodzajem realizowanych zadań. Bot obsługujący faktury nie potrzebuje manipulatora, a robot spawalniczy nie musi korzystać z formularza internetowego.

Nie oznacza to również, że każdy program automatyzujący czynności jest rozwiązaniem RPA. Zwykły skrypt PowerShell, zadanie harmonogramu systemowego albo proces synchronizacji danych przez API mogą realizować podobny cel, lecz inną metodą. Charakterystyczną cechą wielu wdrożeń RPA jest automatyzowanie czynności na poziomie aplikacji, z których wcześniej korzystał człowiek, bez konieczności całkowitej przebudowy tych systemów.

Jedna faktura, osiem czynności - jak pracuje człowiek, a jak bot?

Najłatwiej zrozumieć działanie robota programowego na przykładzie. Wyobraźmy sobie firmę, która każdego miesiąca otrzymuje kilkaset faktur w wiadomościach e-mail. Dokumenty trafiają do wspólnej skrzynki, a pracownik pobiera załączniki, sprawdza dostawców i ręcznie wprowadza informacje do programu księgowego. Pojedyncza faktura nie wymaga wiele pracy, ale obsługa całego zbioru potrafi zajmować wiele godzin.

Proces można rozłożyć na osiem podstawowych czynności: odebranie wiadomości, pobranie dokumentu, odczytanie danych, sprawdzenie dostawcy, zweryfikowanie numeru faktury, wprowadzenie danych do systemu, zapisanie załącznika i oznaczenie wiadomości jako obsłużonej. Jeżeli dokumenty mają podobną strukturę, a reguły postępowania są jednoznaczne, część tych operacji można przekazać robotowi.

Załóżmy, że ręczne wykonanie całej sekwencji zajmuje przeciętnie 3 minuty. Przy 400 fakturach otrzymujemy 1200 minut, czyli 20 godzin pracy. Jeżeli automatyzacja skróci przeciętny czas bezpośredniej obsługi pojedynczego dokumentu przez człowieka do 30 sekund, daje to około 3 godzin i 20 minut. Różnica wynosi 16 godzin i 40 minut miesięcznie. Jest to jedynie model obliczeniowy - rzeczywisty wynik zależy od jakości dokumentów, liczby wyjątków i konieczności weryfikowania danych.

Automatyczne rozpoznanie kwoty z faktury nie oznacza bowiem, że dokument jest poprawny. Robot może odczytać wartość, ale niekoniecznie potwierdzi zasadność kosztu, zgodność z zamówieniem czy prawidłową kwalifikację księgową. Takie decyzje wymagają osobnych reguł biznesowych, danych z innych systemów lub udziału uprawnionego pracownika.

Dobrze zaprojektowany proces nie polega więc na bezwarunkowym przepisywaniu wszystkiego. Dokument spełniający ustalone warunki może przejść dalej automatycznie, natomiast faktura o nieznanym numerze kontrahenta, nieczytelnej dacie lub nietypowej kwocie powinna trafić do weryfikacji. W wielu firmach właśnie takie połączenie automatyzacji i kontroli człowieka daje najbardziej przewidywalne rezultaty.

Jak robot rozpoznaje przyciski, pola i dane w aplikacjach?

Człowiek obsługujący program księgowy rozpoznaje przycisk "Dodaj dokument", ponieważ widzi jego położenie i rozumie opis. Robot musi otrzymać informację, jak zidentyfikować właściwy element. W aplikacji internetowej może to być atrybut HTML, identyfikator pola formularza albo inna cecha elementu dostępna przez mechanizmy automatyzacji przeglądarki. W programach desktopowych wykorzystuje się często interfejsy dostępności i automatyzacji systemu operacyjnego.

Najprostsza automatyzacja mogłaby polegać na przesunięciu kursora do określonych współrzędnych i wykonaniu kliknięcia. Jest to jednak rozwiązanie podatne na błędy. Wystarczy zmienić rozdzielczość ekranu, powiększenie interfejsu albo położenie okna, żeby robot kliknął w niewłaściwym miejscu. Z tego powodu bardziej niezawodne narzędzia starają się rozpoznawać konkretne komponenty, zamiast polegać wyłącznie na ich pozycji.

Trudniej wygląda obsługa danych zawartych w dokumentach. Faktura zapisana jako PDF może zawierać warstwę tekstową, którą stosunkowo łatwo odczytać programowo. Skan papierowego dokumentu wymaga natomiast zastosowania OCR, czyli optycznego rozpoznawania znaków. Wynik zależy między innymi od jakości obrazu, układu dokumentu, czcionki i obecności tabel.

Rozpoznany tekst trzeba następnie odpowiednio zinterpretować. W dokumencie mogą znajdować się różne daty: wystawienia, sprzedaży i terminu płatności. Podobnie mogą występować kwoty netto, brutto i podatek VAT. Samo znalezienie ciągu cyfr nie wystarczy do prawidłowego wypełnienia formularza. Konieczne jest przypisanie wartości do odpowiednich pól i sprawdzenie ich logicznej zgodności.

Coraz częściej w automatyzacji dokumentów wykorzystuje się również modele uczenia maszynowego, które pomagają rozpoznawać pola w mniej uporządkowanych plikach. Nie zmienia to jednak podstawowej zasady: system powinien posiadać procedurę obsługi sytuacji, w której odczytane dane są niepewne albo niezgodne z oczekiwanym formatem.

RPA, skrypt czy API - trzy sposoby wykonania tego samego zadania

Wyobraźmy sobie konieczność codziennego pobierania zamówień ze sklepu internetowego i przenoszenia ich do programu magazynowego. Można przygotować robota, który zaloguje się do panelu sklepu, otworzy listę zamówień i ręcznie, choć automatycznie, przeniesie potrzebne dane. Można również napisać skrypt przetwarzający plik CSV. Trzecia możliwość to bezpośrednie połączenie obu systemów za pomocą interfejsów API.

Wszystkie metody mogą prowadzić do podobnego rezultatu, ale różnią się odpornością na zmiany, możliwościami kontroli i kosztami utrzymania. Jeśli oba programy oferują dobrze udokumentowane API, bezpośrednia integracja często okazuje się trwalsza niż automatyczne klikanie w ich interfejsach. RPA bywa jednak przydatne wtedy, gdy starsza aplikacja nie udostępnia odpowiednich mechanizmów wymiany danych.

Nie ma sensu stosować RPA do każdej operacji, którą można wykonać automatycznie. Jeżeli zadanie polega na zmianie nazw kilkuset plików, prosty skrypt będzie zwykle wystarczający. Jeśli natomiast pracownik codziennie wykonuje te same operacje w trzech odrębnych aplikacjach, z których jedna nie pozwala eksportować danych, robot programowy może okazać się praktycznym rozwiązaniem.

Co się dzieje, gdy robot trafi na nieprzewidzianą sytuację?

Jednym z największych problemów automatyzacji jest przekonanie, że proces działający poprawnie podczas testu będzie działał identycznie przez kolejne miesiące. Tymczasem aplikacje są aktualizowane, zmieniają się układy formularzy, pojawiają się dodatkowe komunikaty, a niektóre operacje trwają dłużej z powodu obciążenia serwera.

Załóżmy, że robot ma po zalogowaniu kliknąć w przycisk "Nowa faktura". Po aktualizacji programu przycisk zostaje przeniesiony do rozwijanego menu. Jeżeli automatyzacja opierała się na współrzędnych ekranu, prawdopodobnie przestanie działać. Jeśli korzystała ze stabilnych identyfikatorów elementów, może znieść zmianę ich położenia, ale niekoniecznie zmianę całej struktury interfejsu.

Dlatego poprawny projekt RPA powinien przewidywać sytuacje wyjątkowe. Robot musi wiedzieć, jak długo czekać na odpowiedź aplikacji, kiedy powtórzyć operację i w którym momencie zakończyć pracę z błędem. Ważne są również dzienniki zdarzeń, dzięki którym administrator potrafi ustalić, na jakim etapie wystąpił problem.

Szczególnego znaczenia nabiera zapobieganie duplikowaniu operacji. Jeżeli robot zapisze dokument, ale nie otrzyma potwierdzenia z systemu, ponowne uruchomienie całej procedury może doprowadzić do dodania tej samej faktury drugi raz. Zamiast bezwarunkowo powtarzać ostatni krok, trzeba sprawdzić, czy dokument już istnieje. Pomagają w tym unikalne identyfikatory, kontrola stanu transakcji i odpowiednie mechanizmy obsługi błędów.

Osobnym zagadnieniem jest bezpieczeństwo. Robot może potrzebować dostępu do poczty, programu księgowego lub bazy kontrahentów. Nie powinien jednak otrzymywać nieograniczonych uprawnień tylko dlatego, że nie jest człowiekiem. Dane uwierzytelniające należy przechowywać w bezpieczny sposób, a działania automatyzacji rejestrować tak, aby można było odtworzyć historię wykonanych operacji.

Gdzie roboty programowe rzeczywiście oszczędzają czas?

Najlepiej automatyzują się czynności powtarzalne, oparte na jasno określonych regułach i wykorzystujące dane o przewidywalnej strukturze. Przykładem może być codzienne pobieranie raportów z kilku aplikacji, porównywanie zestawień, aktualizowanie statusów zamówień albo przygotowywanie dokumentów na podstawie informacji z formularzy.

W administracji firmowej robot może przenosić dane pomiędzy starszymi systemami, które nie zostały ze sobą zintegrowane. W obsłudze sprzedaży może sprawdzać statusy dostaw i przygotowywać zestawienia dla pracowników. W księgowości pomaga w pobieraniu dokumentów i kontroli kompletności danych, a w dziale IT może obsługiwać wybrane czynności związane z zarządzaniem kontami użytkowników.

Automatyzacja programowa różni się pod tym względem od rozwiązań stosowanych na halach produkcyjnych. W zakładzie robot może wykonywać powtarzalne operacje mechaniczne, podczas gdy bot w systemie komputerowym przetwarza informacje. Oba podejścia mają jednak podobne cele organizacyjne: ograniczenie ręcznej pracy, poprawę powtarzalności i skrócenie czasu realizacji zadań. Więcej przykładów fizycznej automatyzacji przedstawia artykuł o wpływie automatyzacji i robotyzacji na wydajność produkcji. Porównanie obu środowisk pokazuje, dlaczego przed wyborem technologii trzeba dobrze rozpoznać sam proces.

Nie każda oszczędność polega przy tym na zastąpieniu czasu pracy człowieka. Robot może wykonywać zadania poza godzinami pracy firmy, przygotowywać raporty przed rozpoczęciem dnia albo wykrywać brakujące dokumenty. Pracownik otrzymuje wówczas gotowe zestawienie zamiast rozpoczynać pracę od ręcznego zbierania informacji.

Kiedy automatyzowanie pracy na komputerze nie ma sensu?

Wyobraźmy sobie czynność zajmującą 10 minut tygodniowo. Nawet jeśli robot skróci ją do kilku sekund, koszt przygotowania, wdrożenia i późniejszego utrzymywania automatyzacji może przewyższyć uzyskane korzyści. Podobna sytuacja występuje wtedy, gdy procedura często się zmienia albo każda sprawa wymaga indywidualnej oceny.

Przed rozpoczęciem projektu można wykonać prosty rachunek. Jeśli dana czynność zajmuje 5 minut i jest realizowana 600 razy w miesiącu, daje to 3000 minut, czyli 50 godzin. Zakładając, że po automatyzacji 80% przypadków zostanie obsłużonych bez udziału pracownika, potencjalna oszczędność czasu przy tych przypadkach wyniesie około 40 godzin miesięcznie. Od tej wartości należy jednak odjąć czas poświęcany na obsługę wyjątków, kontrolę wyników i utrzymywanie robota.

Prawidłowa kalkulacja obejmuje także licencje, infrastrukturę, koszty wdrożenia i ryzyko przerw w działaniu. Istotna jest też częstotliwość zmian w obsługiwanych aplikacjach. Bot oparty na interfejsie starego programu, aktualizowanego raz na kilka lat, może działać względnie stabilnie. Automatyzacja witryny internetowej, której struktura zmienia się co kilka tygodni, będzie wymagała częstszych poprawek.

Najbardziej problematyczne bywają projekty rozpoczynane od wyboru narzędzia, zamiast od uporządkowania sposobu wykonywania pracy. Jeżeli pracownicy stosują różne zasady nazywania dokumentów, wprowadzają dane w przypadkowych polach lub omijają ustalone procedury, robot może tylko przyspieszyć powstawanie podobnych nieprawidłowości. Automatyzowanie chaotycznego procesu nie czyni go automatycznie dobrze zorganizowanym.

Robot programowy może być bardzo użytecznym narzędziem, ale jego największą zaletą nie jest samo naśladowanie ruchów użytkownika. Dobrze przygotowany bot wykonuje powtarzalne czynności w przewidywalny sposób, pozwala kontrolować rezultaty i przekazuje człowiekowi przypadki, których nie potrafi poprawnie obsłużyć. Czasami wystarczy do tego kilka reguł i prosty skrypt. W innych sytuacjach potrzebna będzie rozbudowana platforma RPA. Decyzję najlepiej podjąć dopiero wtedy, gdy wiadomo, co dokładnie ma zostać zautomatyzowane i jak sprawdzimy, czy cały proces rzeczywiście działa lepiej.