Jak działa RPA w praktyce? Przykłady procesów automatyzowanych w firmach

RPA to skrót od Robotic Process Automation, czyli robotyzacji procesów. Brzmi poważnie, ale w praktyce chodzi o coś bardzo prostego: program komputerowy, który uczy się sekwencji kliknięć i wpisywanych danych, a potem powtarza ją samodzielnie. Można sobie wyobrazić, że nagrywamy makro w Excelu – tylko że to makro potrafi obsłużyć dowolny system, nie tylko arkusz.

Robot RPA loguje się do aplikacji, otwiera załączniki w mailach, kopiuje dane z portalu do systemu księgowego, pobiera raport z jednego narzędzia i wkleja do drugiego. Działa na pulpicie tak samo, jak działałby człowiek – tylko szybciej i bez zmęczenia. Z punktu widzenia systemów, które obsługuje, wygląda jak normalny użytkownik.

To bardzo ważna cecha: RPA nie wymaga, żeby systemy w firmie były nowoczesne. Robot pracuje tak, jak pracuje człowiek – przez interfejs użytkownika. Dlatego potrafi obsłużyć system księgowy z 2003 roku, portal urzędowy bez integracji i nową aplikację SaaS w tym samym przepływie. To jest największa siła tej technologii.

Warto od razu wyjaśnić, czego RPA nie robi. Robot nie myśli, nie ocenia, nie wyciąga wniosków. Jeśli proces wymaga decyzji typu czy ta faktura jest poprawna merytorycznie, to nie jest robota dla RPA – to robota dla człowieka albo dla połączenia robota z AI. RPA wykonuje to, co da się zapisać jako jasny scenariusz: zrób A, potem B, jeśli warunek spełniony – C, jeśli nie – wyślij maila.

Najlepiej pokazać to na konkretnym przykładzie. Wyobraźmy sobie firmę, która codziennie dostaje 80 faktur od dostawców mailem. Klasycznie księgowa otwiera każdą fakturę, sprawdza numer, kwotę, NIP, pobiera załącznik PDF, wprowadza dane do systemu księgowego, dopina załącznik, zapisuje. Jedna faktura to 3–4 minuty, 80 faktur to cały dzień jednej osoby.

Po wdrożeniu robota wygląda to inaczej. O godzinie 22:00 robot startuje sam. Loguje się do skrzynki mailowej, filtruje wiadomości z załącznikami fakturowymi, pobiera każdy PDF do osobnego folderu. Następnie otwiera narzędzie OCR, które wyciąga z PDF-a dane: numer faktury, datę, kwotę, NIP dostawcy. Robot porównuje te dane z bazą dostawców w systemie księgowym – jeśli dostawca istnieje, robot otwiera moduł rejestracji faktur i wpisuje dane jeden po drugim. Dopina załącznik. Zapisuje. Przechodzi do kolejnej faktury.

Jeśli robot trafi na coś, czego nie potrafi obsłużyć – na przykład nowy dostawca, którego nie ma w bazie, albo faktura w nietypowym formacie – nie zatrzymuje całego procesu. Odkłada tę fakturę do folderu wymaga decyzji człowieka, zapisuje powód, dlaczego nie dał rady, i przechodzi do kolejnej. Rano księgowa otwiera komputer i widzi raport: 73 faktury obsłużone automatycznie, 7 wymaga decyzji. Decyzje zajmują 20 minut zamiast całego dnia.

To jest praktyczny rytm pracy robota w typowej firmie. Działa wtedy, kiedy ludzie nie pracują – nocą, w weekendy, w święta. Albo działa równolegle z zespołem – obsługując prostsze przypadki, podczas gdy ludzie zajmują się tymi, które wymagają rozmowy, decyzji, wyjaśnienia.

Po wielu wdrożeniach widać wyraźnie, że pewne kategorie procesów wręcz proszą się o robota. Każda z nich ma swoje sygnały – jeśli rozpoznajemy je w swojej firmie, to bardzo dobry kandydat na pierwszy projekt RPA.

Pierwsza kategoria: przepisywanie danych między systemami. Klasyk – ktoś codziennie eksportuje plik z jednego narzędzia, otwiera drugie i wprowadza dane wiersz po wierszu. Sprzedaż do księgowości, CRM do ERP, sklep internetowy do magazynu. Wszędzie, gdzie nie ma integracji, robot ją zastępuje.

Druga kategoria: ekstrakcja danych z dokumentów. Faktury, zamówienia, formularze, potwierdzenia przelewów, listy przewozowe. Robot w połączeniu z OCR potrafi wyciągać dane z setek dokumentów dziennie i ładować je do właściwego systemu, podczas gdy ludzie zajmują się trudniejszymi przypadkami.

Trzecia kategoria: cykliczne raporty i zestawienia. Pobierz dane z trzech systemów, połącz w Excelu, sformatuj, wyślij do pięciu odbiorców, codziennie o 8:00. To zadanie wymaga 60–90 minut dziennie. Robot wykonuje je w 5 minut, każdego dnia, bez wyjątku.

Czwarta kategoria: sprawdzanie statusów i monitorowanie. Robot codziennie loguje się do portalu urzędowego, pobiera status sprawy, aktualizuje go w wewnętrznym systemie i powiadamia opiekuna sprawy, jeśli pojawiła się zmiana. Działa to dla portali dostawców, systemów spedycyjnych, baz urzędowych – wszędzie, gdzie ktoś codziennie klika po to samo, żeby sprawdzić, czy coś się zmieniło.

Piąta kategoria: czynności pomocnicze w obsłudze klienta. Klient zgłasza reklamację – robot tworzy ticket w trzech systemach, dopina dokumenty, generuje numer sprawy, wysyła maila potwierdzającego. Człowiek dostaje już otwartą i opisaną sprawę gotową do realnej pracy, czyli rozmowy z klientem.

Pierwszy przykład – firma produkcyjna, 200 osób. Codziennie wpływa 120 faktur od dostawców mailem. Trzy osoby w księgowości spędzały na ich wprowadzaniu po 4 godziny dziennie. Po wdrożeniu robota z OCR: 95 procent faktur jest obsługiwane automatycznie. Czas pracy księgowych przesunięty na analizę kosztów i kontrolę wydatków, czyli na to, do czego są naprawdę potrzebne.

Drugi przykład – firma logistyczna. Każdego ranka spedytor sprawdzał status 60 przesyłek na trzech różnych portalach przewoźników. Klikał, kopiował numer listu, wklejał do wewnętrznego systemu i aktualizował status. Każdego dnia 90 minut tylko na sprawdzanie. Robot przejął tę pracę: o 6:00 rano wszystkie 60 przesyłek ma aktualny status w systemie, spedytor dostaje powiadomienie tylko o tych, gdzie coś poszło nie tak.

Trzeci przykład – sklep internetowy. Klient zwraca produkt, otwiera reklamację przez formularz. Klasycznie: ktoś z obsługi otwierał ją w trzech systemach (CRM, magazyn, księgowość), kopiował dane między nimi, generował numer sprawy, wysyłał maila do klienta. 8 minut na jedną reklamację, 40 reklamacji dziennie, czyli ponad 5 godzin tylko na otwieranie spraw. Robot tworzy reklamację we wszystkich trzech systemach w 30 sekund. Człowiek dostaje już opisaną sprawę i zajmuje się tym, co naprawdę wymaga uwagi: kontaktem z klientem i decyzją o zwrocie.

We wszystkich trzech przypadkach wspólny mianownik jest taki sam: robot nie zastąpił nikogo. Zabrał tę część dnia, która była najbardziej rutynowa i najmniej rozwijająca, i przekazał ludziom więcej czasu na pracę, którą tylko oni są w stanie wykonać.

Łatwo wpaść w pułapkę myślenia, że robot załatwi wszystko. Nie załatwi. Jeśli proces wymaga oceny merytorycznej – czy ta faktura jest poprawna, czy ten klient zasługuje na wyjątek, czy ten dokument można podpisać – to nie jest robota dla RPA. Robot wykona dokładnie to, co mu powiemy: jeśli kwota poniżej 5000 zł, zaakceptuj. Jeśli powyżej, przekaż do kierownika. Reguła musi być jasna.

Druga rzecz: robot nie radzi sobie z chaosem. Jeśli proces zmienia się co tydzień, jeśli każdy dostawca przysyła fakturę w innym formacie, jeśli system co chwilę zmienia interfejs – robot będzie się ciągle psuł. RPA dobrze działa tam, gdzie proces jest powtarzalny i stabilny. Jeśli sam proces jest pomyłką, to robotyzacja nie pomoże, tylko go zabetonuje.

Trzecia: robot nie ulepszy złego procesu. Jeśli dzisiaj ktoś przepisuje dane z systemu A do systemu B, robot to przyspieszy. Ale prawdziwe pytanie powinno brzmieć: dlaczego w ogóle przepisujemy te dane? Czasem najlepszą odpowiedzią na ręczne przeklejanie jest nie zatrudnij robota, tylko zintegruj systemy raz, porządnie. Robotyzacja ma sens, gdy integracja nie wchodzi w grę – bo system jest stary, bo dostawca nie udostępnia API, bo to tylko proces przejściowy.

Czwarta: robot wymaga opieki. To nie jest produkt, który się raz uruchamia i działa wiecznie. Co kilka miesięcy zmienia się interfejs jakiegoś systemu, robot przestaje działać, ktoś musi go poprawić. Dlatego warto od początku zdecydować, kto w firmie się tym zajmuje i kto monitoruje, że roboty pracują tak, jak powinny.

Najlepszy pierwszy projekt RPA to taki, który spełnia kilka warunków na raz. Po pierwsze – jest dobrze zdefiniowany. Wiemy dokładnie, co się dzieje krok po kroku, i jesteśmy w stanie opisać to na kartce A4. Po drugie – jest powtarzalny. Wykonywany codziennie lub kilka razy w tygodniu, nie raz na pół roku. Po trzecie – zajmuje sensowną ilość czasu. Pół godziny dziennie razy 250 dni roboczych to już 125 godzin w skali roku. Po czwarte – nie wymaga oceny merytorycznej, tylko wykonywania reguł.

Kiedy mamy kandydata, najlepiej zrobić mały pilot. Jeden proces, mała skala, krótki czas wdrożenia. Cel pilota nie jest taki, żeby zaoszczędzić od razu setki godzin – cel jest taki, żeby zespół zobaczył, jak robot działa w naszej firmie, jak się nim opiekować, jak monitorować, jak reagować, gdy coś przestanie działać. Po takim pilocie kolejne wdrożenia idą wielokrotnie szybciej.

Warto też od początku zaplanować, kto jest właścicielem robota. Nie chodzi o stanowisko z nazwą RPA Champion – chodzi o jasną odpowiedź na pytanie: jeśli robot przestanie działać w środę o 23:00, kto się tym zajmie w czwartek rano. Bez tej osoby robotyzacja w firmie zwykle wygasa po roku, kiedy roboty się psują, a nikt nie czuje się za nie odpowiedzialny.

I ostatnia rzecz: nie traktować robota jako celu samego w sobie. Robot to narzędzie do oddania zespołowi czasu na lepszą pracę. Jeśli po wdrożeniu robota ten oddany czas idzie na nowe sensowne zadania – mamy sukces. Jeśli idzie na to, żeby zwolnić ludzi, którzy znali firmę – mamy często więcej szkody niż pożytku. Ten wybór jest po stronie firmy, nie technologii.

RPA w praktyce wygląda bardzo zwyczajnie. To nie cyfrowa rewolucja ani futurystyczna sztuczna inteligencja – to program, który wykonuje za człowieka rzeczy, które od lat wykonuje człowiek, choć nie powinien. Faktury, dane z portali, raporty, statusy, transfery między systemami.

Robot działa wtedy, kiedy proces jest powtarzalny, oparty na regułach i wykonywany w wielu systemach naraz. Wszędzie tam jest szansa odzyskać setki godzin pracy rocznie i przesunąć ludzi na zadania, które wymagają myślenia, rozmowy i decyzji.

Najczęstszy błąd to traktowanie RPA jako magii, która rozwiąże wszystko. Robot nie naprawi złego procesu i nie zastąpi ludzkiej oceny. Ale w miejscach, w których ktoś od trzech lat klika tę samą sekwencję między trzema systemami – RPA jest jedną z najszybciej zwracających się inwestycji, jaką można zrobić.

Jeśli rozpoznajesz w swojej firmie procesy, w których ktoś codziennie przepisuje dane lub klika to samo w portalu – to jest dobry moment, żeby przyjrzeć się RPA z bliska. Praktyczne podejście do tematu znajdziesz w artykułach RPA w firmie – jakie procesy warto automatyzować i RPA vs integracja API.