RPA czy integracja przez API – kiedy robot, a kiedy bezpośrednie połączenie systemów

API to oficjalne łącze, przez które jeden program przekazuje dane drugiemu bez udziału człowieka i bez otwierania okien. Działa jak okienko podawcze między dwiema kuchniami: zamówienie wchodzi z jednej strony, danie wychodzi z drugiej. Wymiana trwa ułamki sekundy i nie zależy od tego, jak wygląda ekran aplikacji.

Robot RPA (od ang. robotic process automation) działa zupełnie inaczej. Loguje się do aplikacji jak pracownik, otwiera okna, klika przyciski i wpisuje dane. Nie potrzebuje API, wystarczy mu to, co widzi człowiek.

Z tej różnicy wynika wszystko inne. API jest szybkie i odporne na zmiany wyglądu programu, ale musi istnieć i być dostępne. Robot poradzi sobie z każdą aplikacją, ale zatrzyma się, gdy zmieni się ekran, na którym pracuje.

Pytanie „co szybciej: API czy robot?” nie ma jednej odpowiedzi, bo integracja przez API to w praktyce dwie różne sytuacje. Pierwsza to gotowy konektor, czyli złącze do konkretnej aplikacji dostępne od ręki w narzędziu do automatyzacji. Druga to API, do którego trzeba napisać połączenie samodzielnie. Poniżej orientacyjne czasy dla jednego prostego procesu, z testami – w Twojej firmie mogą być inne.

Z poniższego zestawienia wynika, że integracja przez gotowy konektor jest zwykle szybsza od robota. Robot wygrywa czasem z integracją budowaną od zera, ale w zamian wymaga stałej opieki. Licz nie tylko czas uruchomienia, ale też koszt utrzymania przez kilka lat.

Wybór robota w poniższych sytuacjach zwykle oznacza wyższy koszt utrzymania bez żadnej korzyści. Jeśli Twój proces pasuje do któregoś punktu, zacznij od API.

Przykład: sklep internetowy i system magazynowy mają API. Klient klika „Zamów”, a w tej samej sekundzie magazyn rezerwuje towar i odsyła potwierdzenie. Robot nie byłby w stanie tego zrobić w takim tempie.

Robot jest właściwym wyborem tam, gdzie integracja jest niemożliwa, niedostępna albo nieopłacalna. Takich sytuacji jest więcej, niż zakładają zespoły IT przyzwyczajone do API.

Szczegóły pracy robota na systemach bez API opisujemy w osobnym poradniku o automatyzacji starych systemów.

Te pytania warto zadać osobno dla każdego połączenia między systemami. Odpowiedzi zapisz – przydadzą się, gdy za kilka lat ktoś zapyta, dlaczego wybrano robota albo integrację.

Jeśli odpowiedź brzmi „robot”, zapisz też warunek powrotu do tematu, np. „sprawdzić API po aktualizacji ERP”. Robot wybrany jako rozwiązanie przejściowe często zostaje na stałe tylko dlatego, że nikt o nim nie pamiętał.

Najlepsze efekty daje dobór sposobu do każdego odcinka procesu osobno. Automatyczny przepływ, np. w Power Automate, pobiera dane przez API tam, gdzie się da, i przekazuje je robotowi tam, gdzie API nie ma.

W takich procesach najważniejsze jest miejsce styku. Ustal, co się dzieje, gdy robot nie zdoła wprowadzić danych: kto dostaje powiadomienie i skąd wie, które rekordy trzeba poprawić. Poniżej trzy hipotetyczne przykłady.

Najczęstszy błąd to jedna technologia dla całej firmy. Zasada „zawsze API” sprawia, że stare systemy latami nie są połączone z niczym. Zasada „zawsze robot” prowadzi do robotów tam, gdzie wystarczyłby konektor.

Drugi błąd to liczenie tylko kosztu uruchomienia. Robot bywa szybszy na starcie, ale wymaga opieki po każdej zmianie w aplikacji. Integracja bywa droższa na starcie, ale potem rzadziej wymaga poprawek.

Trzeci błąd to pominięcie licencji. Konektory premium w Power Automate wymagają licencji Premium, a robot pracujący w nocy – licencji Process. Sprawdź to przed porównaniem ofert, bo ta pozycja łatwo umyka.