RPA - co to jest i czym różni się od automatyzacji
RPA automatyzuje pracę w interfejsie aplikacji, zwykła automatyzacja wymienia dane wprost między systemami. Kiedy pierwsze rozwiązanie ma sens, a kiedy jest kosztowną protezą.
Autor: Paweł Cybulko, ekspert SEO i entuzjasta rozwiązań AI
RPA (Robotic Process Automation) to automatyzacja polegająca na tym, że program naśladuje pracę człowieka w interfejsie: klika, przepisuje, przechodzi między oknami. Nazwa jest myląca - żadnego robota tu nie ma, jest skrypt obsługujący aplikację tak, jak robiłby to pracownik.
Kluczowa różnica wobec zwykłej automatyzacji: przepływ danych łączy systemy bezpośrednio, przez ich interfejsy programistyczne. RPA obchodzi ten brak, udając użytkownika.
Porównanie
| Zwykła automatyzacja | RPA | |
|---|---|---|
| Jak działa | Systemy wymieniają dane bezpośrednio | Program klika w interfejsie za człowieka |
| Warunek | System musi dawać sposób wymiany danych: API, webhooki, bazę albo pliki | Wystarczy, że da się w nim klikać |
| Odporność | Wysoka, interfejsy zmieniają się rzadko | Niska, psuje się przy zmianie układu ekranu |
| Szybkość | Natychmiastowa | Ograniczona tempem interfejsu |
| Koszt utrzymania | Niski | Wysoki, wymaga ciągłych poprawek |
| Kiedy stosować | Zawsze, gdy to możliwe | Gdy nie ma innej drogi |
Kiedy RPA ma sens
Są sytuacje, w których to jedyne wyjście:
- Stary program działający wyłącznie lokalnie, bez żadnej możliwości połączenia z zewnątrz - a wymiana go kosztowałaby wielokrotnie więcej.
- System dostawcy albo urzędu, do którego nie masz dostępu na poziomie interfejsu programistycznego i nie możesz tego zmienić.
- Rozwiązanie tymczasowe na kilka miesięcy, do czasu wdrożenia właściwej integracji.
We wszystkich trzech przypadkach warto traktować RPA jako protezę, a nie docelowe rozwiązanie - i policzyć koszt jej utrzymania, zanim się je wybierze.
Dlaczego to bywa kosztowne
Problem jest jeden i wraca zawsze: RPA opiera się na wyglądzie interfejsu. Wystarczy, że dostawca przesunie przycisk, doda pole albo zmieni układ ekranu i skrypt przestaje działać. Czasem zatrzymuje się z błędem, co jest scenariuszem lepszym. Czasem wpisuje dane w niewłaściwe pole i nikt tego nie zauważa przez tydzień.
Do tego dochodzi kwestia dostępów: RPA loguje się do systemu jako użytkownik, więc gdzieś muszą być przechowywane jego dane logowania. Przy bezpośrednim połączeniu też trzeba pilnować kluczy API, tokenów i kont technicznych, ale ich uprawnienia da się zawęzić do jednej operacji - konta użytkownika nie.
Dlatego zasada, którą stosujemy, brzmi: sprawdź najpierw, czy system ma interfejs programistyczny. Większość popularnych narzędzi - systemy sprzedażowe, sklepy, programy do fakturowania, skrzynki pocztowe, arkusze - ma go od lat. RPA zostaje wtedy tam, gdzie naprawdę nie ma innej drogi.
A gdzie w tym wszystkim AI
Trzy pojęcia mieszają się w rozmowach, więc warto je rozdzielić:
- Automatyzacja przenosi dane według reguł. Przewidywalna i tania w utrzymaniu, ale wymaga pilnowania wyjątków i okresowych poprawek.
- RPA robi to samo, ale przez interfejs - gdy nie ma innego sposobu. Zawodna, wymaga opieki.
- AI wchodzi tam, gdzie reguły nie da się zapisać, bo trzeba zrozumieć tekst.
Bywa, że są łączone: scenariusz pobiera dokument, model odczytuje z niego dane, a automatyzacja zapisuje je w systemie. Sensowna kolejność wyboru jest jednak zawsze ta sama - najpierw sprawdź, czy wystarczy bezpośrednie połączenie systemów, bo to najtańsze i najtrwalsze rozwiązanie.
Jak zacząć
Zanim zaczniesz rozważać RPA, odpowiedz na dwa pytania. Po pierwsze: ile godzin miesięcznie zajmuje ta czynność - przy kilku godzinach warto najpierw zestawić koszt wdrożenia z oszczędnością czasu, kosztem pomyłek i ryzykiem w procesie. Po drugie: czy systemy, które chcesz połączyć, mają interfejsy programistyczne - bo jeśli tak, RPA jest niepotrzebne.
Jak podchodzimy do tego rachunku i w jakiej kolejności dobieramy rozwiązania, opisujemy przy automatyzacji procesów. Porównanie samych narzędzi znajdziesz we wpisie o n8n, Make i Zapierze.