Kategoria: Automatyzacja i autonomia
„Czym różni się n8n od klasycznego RPA?” Nie tym, że jedno jest nowszą wersją drugiego. To dwa różne miejsca podłączenia do tego samego systemu, a wszystko inne wynika z tej jednej różnicy.
Wszystkie liczby po stronie n8n odczytałem z bazy jednej instancji uruchomionej na moim serwerze domowym: workflow i bloki 29 i 30 października 2026, dziennik przebiegów 30 października, z oknem od 16 do 30 października. Po stronie klasycznego RPA nie podaję w tym tekście ani jednej liczby, ponieważ żadnej nie zmierzyłem. Opisuję wyłącznie to, jak działa samo podejście. Tekst nie jest więc testem wydajności i nie rozstrzyga, które rozwiązanie jest szybsze ani które tańsze. Nie wymieniam też żadnego produktu: RPA występuje tu jako kategoria narzędzi, nie jako nazwa.
Jedno podejście czyta ekran, drugie wywołuje interfejs
Gdzie dokładnie przebiega granica
Klasyczne RPA automatyzuje tę samą warstwę, z której korzysta człowiek. Robot otwiera okno aplikacji, odnajduje pole, wpisuje wartość, klika przycisk i odczytuje wynik z kontrolki na ekranie. Dla automatyzowanego systemu wygląda to jak praca szybkiego i bardzo cierpliwego użytkownika.
Przepływ zbudowany w n8n podłącza się o warstwę niżej. Nie widzi okna, ponieważ wcale go nie otwiera: wywołuje adres, odczytuje wiersz w bazie, czeka na wiadomość przychodzącą. Tak wygląda mój własny układ. n8n stoi u mnie w kontenerze i rozmawia z bazą przez pulę połączeń, a nie z żadnym ekranem.
Różnica da się streścić w jednym zdaniu: jedno podejście opiera się na kontrakcie, drugie na obrazie. Kontrakt jest opisany i ma wydania. Obraz nie ma ani jednego, ani drugiego.
Na co jedno i drugie czeka
Wyzwalacz jest pierwszą różnicą, nie ostatnią
W moich 223 workflow odnalazłem 334 bloki wyzwalaczy: 63 czeka na zegar, 40 na wiadomość przychodzącą z zewnątrz, 54 na moją wiadomość (34 w oknie czatu i 20 w Telegramie), a 79, czyli najwięcej ze wszystkich, na wywołanie przez inny przepływ. Rozkład tych ośmiu rodzajów rozbiłem wcześniej, opisując co właściwie uruchamia moje automatyzacje, a pochodzenie samej liczby 223 wyjaśnia osobny tekst: co znaczy ponad 150 workflow w n8n.
Najciekawszy jest w tym zestawieniu wiersz z wiadomością przychodzącą. To drzwi, które istnieją tylko dlatego, że druga strona potrafi je otworzyć i zawołać mnie w ułamku sekundy. Robot pracujący na ekranie takich drzwi nie ma, bo okno aplikacji samo nikogo nie zawoła. Zostaje więc zegar, kolejka zadań zapełniana w innym miejscu albo człowiek, który uruchamia robota u siebie na stanowisku.
Co się psuje po każdej ze stron
Kontrakt psuje się na wydaniu, obraz przy każdym przemeblowaniu
Przez czternaście dni moja instancja wykonała 5 245 przebiegów, z czego 1 044 zakończyły się błędem, co daje 19,9 % i rozkłada się na 31 różnych workflow. Żaden z tych nieudanych przebiegów nie został powtórzony automatycznie, ponieważ nigdzie nie włączyłem ponowień. Cały ten odczyt, razem z zastrzeżeniami, opisałem przy okazji tego, jak czytam dziennik przebiegów. Przyczyny są zawsze po drugiej stronie kontraktu: wygasło uprawnienie, usługa odpowiedziała błędem, w arkuszu nie było spodziewanego wiersza.
Robot pracujący na ekranie psuje się na czymś innym. Element przesunął się na ekranie, pole zmieniło nazwę, okno wczytywało się dłużej niż krok przewidywał, układ wygląda po aktualizacji inaczej. Przemeblowanie ekranu rzadko bywa ogłaszane jako zmiana łamiąca zgodność, bo dla człowieka siedzącego przed tym ekranem nie jest ono żadną zmianą. Widzi po prostu, że przycisk jest teraz niżej.
| Oś porównania | Przepływ wywołujący interfejs | Robot pracujący na ekranie |
|---|---|---|
| Miejsce podłączenia | adres usługi, baza, wiadomość przychodząca | okno aplikacji, pola i przyciski |
| Co go uruchamia | zegar, wiadomość z zewnątrz, inny przepływ, moja wiadomość | zegar, kolejka zadań, start przez człowieka |
| Co go psuje | zmiana kontraktu, wygasłe uprawnienie, brak danych | przesunięty element, zmieniony układ, wolniejsze wczytanie |
| Warunek wstępny | system ma interfejs, który da się wywołać | system ma ekran, i to wystarcza |
Tabela porównuje sposób działania, nie wyniki. Żaden jej wiersz nie zawiera liczby po stronie RPA, bo takiej liczby nie mam.
Ile kosztuje zmiana
Jedno miejsce na jedną zmianę
Policzyłem bloki w każdym ze swoich 223 workflow: łącznie 3 449, mediana 12, a 78 % zbioru mieści się w dwudziestu blokach lub mniej. Zmiana oznacza więc u mnie otwarcie jednego rysunku, który widzę w całości na ekranie, i poprawienie w nim jednego bloku. Granice tej zasady są jednak policzone razem z nią: piętnaście workflow ma po czterdzieści bloków lub więcej i mieści prawie jedną czwartą wszystkiego, co zbudowałem. Dlaczego i tak dzielę przepływy na małe części, opisałem osobno.
Po stronie ekranu rachunek ma jeszcze jeden składnik. Zmiana bywa równie drobna, bo dotyczy jednego kroku i jednego pola, ale poprawność opisu ekranu zależy od aplikacji, której wydania planuje ktoś inny. Część kosztu utrzymania nie pochodzi więc ani od robota, ani od osoby, która go zbudowała, i nie da się jej usunąć lepszym projektem. Można ją tylko przewidzieć.
Kiedy wyboru nie ma
Brak interfejsu rozstrzyga za Ciebie
Wynika z tego jedna rzecz praktyczna. Jeżeli system nie udostępnia niczego do wywołania, a takich systemów jest w firmach dużo i nie znikną w tym roku, to ekran jest jedynymi drzwiami, jakie zostały, a robot pracujący na ekranie jedynym narzędziem, które przez nie wejdzie. To jest powód, dla którego ta kategoria powstała i nie zniknie.
Jeżeli natomiast interfejs istnieje, to wchodzenie przez ekran oznacza płacenie opisanego wyżej kosztu utrzymania za nic. Kolejność pytań jest więc odwrotna do tej, od której zwykle zaczyna się rozmowa. Nie „które narzędzie jest lepsze”, lecz „czy ten system ma interfejs, który da się wywołać”. Dopiero drugie pytanie brzmi: „a jeżeli ma, to co właściwie ma go wywołać i kiedy”.
Liczba automatyzacji nie jest miarą autonomii
Ani jedno, ani drugie podejście nie przesuwa systemu o stopień wyżej na skali, którą opisałem w tekście o pięciu poziomach od automatyzacji do autonomii. Sto rozwiązań, z których każde czeka na kliknięcie, pozostaje na poziomie pierwszym, niezależnie od tego, czy klika za mnie robot, czy wywołuje adres przepływ.
Nie zmienia się też druga rzecz, i to jest zastrzeżenie dotyczące całego porównania: nie dysponuję wartością opisującą zaoszczędzony czas po żadnej ze stron. Opisałem cztery próby zmierzenia tego u siebie i żadna się nie udała. Nie mam więc podstaw, żeby rozstrzygać „n8n czy RPA” na podstawie zwrotu z inwestycji, i nie zamierzam udawać inaczej.
Ograniczenia tego porównania
Ograniczenia zbieram w jednym miejscu, żeby nie trzeba było ich wyszukiwać w akapitach:
- Nie ma tu żadnej liczby po stronie RPA. Nie zmierzyłem tego podejścia, więc opisuję wyłącznie jego sposób działania. Każde zdanie o ekranie jest opisem mechanizmu, nie wynikiem pomiaru.
- Nie wymieniam produktów. RPA jest tu kategorią, a narzędzia RPA różnią się między sobą na tyle, że cechę pojedynczego z nich łatwo wziąć za cechę całej grupy.
- Nie mówi, które jest tańsze. Nie mam dla żadnej ze stron źródła z datą, które podawałoby warunki licencyjne, a czytelnik mógłby je sprawdzić.
- Udział błędów jest przedziałem. Od 19,9 % do 20,7 %, ponieważ dwa odczyty tej samej tabeli różnią się o 54 wiersze, których nie wyjaśniłem.
- Liczby n8n opisują jedną instancję i trzy dni odczytu. 29 i 30 października 2026 dla workflow i bloków, 30 października dla dziennika, który obejmuje czternaście dni i jest regularnie czyszczony.
- Nie jest to instrukcja wdrożenia. Opisuję różnicę w miejscu podłączenia, a nie kolejność kroków po żadnej ze stron.
