RPA w firmach bez API – jak automatyzować stare systemy i portale webowe

W każdej dyskusji o cyfrowej transformacji pojawia się sugestia – wymieńcie stare systemy. W praktyce to znacznie trudniejsze, niż się wydaje. Wymiana centralnego systemu ERP w firmie 200-osobowej to zwykle projekt na 2–3 lata i budżet rzędu kilku milionów złotych. Wymiana modułu księgowego – kilkanaście miesięcy. Wymiana własnej aplikacji firmowej – jeszcze dłużej, bo nie ma standardowego zamiennika.

Powody, dla których stare systemy zostają: koszt wymiany jest często wyższy niż wartość, którą wymiana przyniesie. Dane historyczne są zbyt skomplikowane do migracji. Zespół zna stary system i nie chce zmiany. Producent nowego nie daje gwarancji, że jego rozwiązanie obsłuży nasze specyfiki. Wszystkie te powody są realne.

Dlatego w typowej firmie z 15-letnią historią obok nowoczesnych narzędzi (M365, monday.com, CRM SaaS) działa kilka starych systemów: główny ERP, system magazynowy, system kadrowy, własna aplikacja produkcyjna. Każdy z nich obsługuje kawałek procesu, a między nimi przelewa się dane ręcznie.

I właśnie tu RPA pokazuje swoją prawdziwą wartość. Robot nie pyta producenta starego systemu o API. Nie czeka na aktualizację. Nie wymaga zmiany w żaden sposób. Po prostu loguje się jak człowiek, klika to, co klika człowiek, wpisuje to, co wpisuje człowiek. Działa.

Scenariusz pierwszy: stary moduł księgowy. Klasyk w polskich firmach – Symfonia, Comarch w starszych wersjach, Insert, czasem rozwiązania producentów, którzy zniknęli. Codzienne wprowadzanie faktur, generowanie zestawień, eksport danych do banku. Robot loguje się rano, otwiera moduł rejestracji faktur, wprowadza dane jeden po drugim. Działa bez zmian latami.

Scenariusz drugi: portal urzędowy. Sprawdzanie statusów wniosków, pobieranie zaświadczeń, składanie dokumentów. Portale ZUS, US, KRS, ePUAP, portale samorządowe – wszystkie one mają tę samą cechę: są zaprojektowane dla człowieka klikającego, nie dla systemu wymieniającego dane. RPA tu działa idealnie – loguje się, klika, pobiera, zapisuje.

Scenariusz trzeci: własna aplikacja firmowa. W każdej firmie produkcyjnej i handlowej istnieje program napisany przez kogoś, kto już dawno odszedł. Obsługuje produkcję, magazyn, specyficzne procesy branżowe. Dokumentacji nie ma, kod jest niedostępny, producent zniknął. Tu RPA bywa jedyną metodą integracji takiej aplikacji z resztą firmy.

We wszystkich trzech scenariuszach klasyczne narzędzia integracyjne (Power Automate Cloud, n8n) są bezsilne. Nie mają konektorów do tych systemów, bo te systemy nie udostępniają niczego do podłączenia. RPA jest narzędziem stworzonym właśnie do takich sytuacji.

Paradoksalna obserwacja, której nie spodziewa się większość firm: roboty pracujące na starych systemach są stabilniejsze niż roboty pracujące na nowoczesnych aplikacjach. Powód jest prosty: stare systemy się nie zmieniają.

Klasyczny ERP zainstalowany w 2010 roku wygląda dokładnie tak samo jak w 2010 roku. Pola w tym samym miejscu, przyciski tej samej barwy, układ ekranu identyczny. Robot raz nauczony tego systemu – działa bez ingerencji przez lata. Producent nie wypuszcza aktualizacji, bo system jest na ostatnich nogach, ale właśnie to jest dla robota dobrą wiadomością.

Z drugiej strony nowoczesne aplikacje SaaS aktualizują interfejs co kilka tygodni. Nowy projekt graficzny, nowa lokalizacja przycisków, nowa kolejność pól. Każda taka zmiana to wywrócenie robota i konieczność jego poprawienia. W skali roku robot pracujący na SaaS może wymagać 5–10 napraw, podczas gdy robot na starym ERP – żadnej.

Druga zaleta: stare systemy są często prostsze. Mają jedno okno, kilka pól, jeden przycisk. Robot uczy się ich w godziny. Nowoczesne SaaS są bardziej rozbudowane – ścieżki użytkownika, modale, animacje, lazy loading. Robot pracujący na takim systemie wymaga znacznie więcej pracy programistycznej.

Wniosek praktyczny: jeśli firma waha się, czy wdrażać RPA do starego ERP, czy do nowoczesnego SaaS – stary ERP jest często lepszym wyborem. Mniej pracy, więcej stabilności, dłuższa wartość z wdrożenia.

Firma produkcyjna, 150 osób. Centralny ERP zainstalowany w 2009 roku. Producent dawno przestał go rozwijać, ale firma trzyma się go, bo migracja do nowego to projekt na 18 miesięcy i 2 miliony złotych. Tymczasem proces wprowadzania faktur zajmuje dwóm księgowym po 3 godziny dziennie.

Rozwiązanie: robot RPA. Workflow w Power Automate Cloud odbiera faktury z firmowej skrzynki mailowej. OCR (Microsoft Document Intelligence) wyciąga z PDF-ów numery, daty, kwoty, NIP-y. Power Automate przekazuje dane do robota Power Automate Desktop. Robot loguje się do starego ERP-a, otwiera moduł rejestracji faktur, wpisuje pola jeden po drugim, dopina załącznik, zapisuje. Cały proces dla jednej faktury – 45 sekund.

Wdrożenie: 6 tygodni pracy zewnętrznego konsultanta, koszt około 35 tys. zł. Robot przerabia 90 faktur dziennie, działa przez noc. Rano księgowe widzą raport z listą wyjątków – ok. 8–10 faktur dziennie wymaga decyzji człowieka.

Efekt po 12 miesiącach. Czas pracy księgowych przesunięty z wprowadzania faktur na kontrolę kosztów, audyt podejrzanych transakcji, rozmowy z dostawcami o korektach. ROI w 6 miesięcy. Stary ERP może spokojnie żyć kolejne 5 lat, firma ma czas na świadomy wybór nowoczesnego systemu.

To nie jest opowieść hipotetyczna – to typowy scenariusz dla setek polskich firm produkcyjnych. RPA na starym ERP to często najtańsza droga do wartości z automatyzacji.

Portale urzędowe są w Polsce osobną kategorią. Często nie mają API. Często wymagają logowania kartą lub profilem zaufanym. Często mają captchas i mechanizmy zabezpieczeń przed botami. To wszystko sprawia, że automatyzacja na nich jest trudniejsza niż na zwykłych aplikacjach.

Ale jest możliwa – i często niezbędna. Sprawdzanie statusu sprawy w urzędzie. Pobieranie zaświadczeń. Składanie dokumentów. Codzienne weryfikacje NIP-ów u dostawców. Wszystko to da się zrobić robotem, choć wymaga to staranniejszego projektowania.

Kluczowe zasady. Po pierwsze, robot zawsze loguje się jako konkretny pracownik (z jego zgodą), nie jako anonimowy bot. Po drugie, robot respektuje ograniczenia portalu – nie spamuje, nie próbuje obchodzić captcha, działa w godzinach pracy. Po trzecie, robot zapisuje pełne logi swoich działań, żeby w razie audytu była pełna ścieżka.

Praktyczne przykłady. Robot codziennie weryfikuje status czynnego/zawieszonego dostawców w bazie VAT. Robot codziennie pobiera nowe zaświadczenia o niezaleganiu, których wymaga umowa z klientami. Robot codziennie sprawdza status spraw w portalu sądowym dla działu prawnego. Każdy z tych procesów oszczędza kilka godzin tygodniowo i robi to lepiej niż człowiek.

Ważne: regulamin portalu trzeba zawsze przeczytać. Część portali oficjalnie zakazuje zautomatyzowanego dostępu. W takich przypadkach lepiej szukać innej drogi (np. API, jeśli istnieje w wersji enterprise) albo zrezygnować z automatyzacji.

Własne aplikacje firmowe, napisane lata temu przez kogoś, kto już dawno nie pracuje w firmie, to często najtrudniejsze przypadki RPA. Ale jednocześnie najbardziej wartościowe – bo poza RPA nie ma żadnej innej drogi.

Typowy przykład. Firma produkcyjna ma aplikację desktopową napisaną w Delphi 7 w 2002 roku. Obsługuje całe planowanie produkcji – zlecenia, terminy, surowce. Producent zniknął, kod jest, ale nikt nie umie go zmienić. Wszystko, co firma chce zrobić nowego z tymi danymi, musi przejść przez ręczne kopiowanie z tej aplikacji.

Rozwiązanie: robot RPA na tej aplikacji. Robot uczy się klikania w jej oknach. Pobiera dane zleceń, eksportuje do Excela. Inne workflow firmy odczytują ten Excel i przekazują dane dalej. To nie jest eleganckie, ale działa, i to często wystarczy.

Specyfika takich wdrożeń: czas. Robot na własnej aplikacji wymaga zwykle więcej pracy konfiguracyjnej niż robot na popularnym systemie. Trzeba dokładnie zmapować ścieżki, przewidzieć wyjątki, ustalić, co się dzieje, gdy aplikacja się zawiesi. Wdrożenie trwa dłużej, ale potem działa bezawaryjnie przez lata.

Często takie wdrożenie pozwala firmie odłożyć decyzję o wymianie własnej aplikacji o kilka lat. Robot wypełnia braki, eksportuje dane, integruje aplikację z resztą firmy. Firma w tym czasie spokojnie planuje wymianę – bez paniki i bez pośpiechu.

RPA pokazuje swoją prawdziwą wartość tam, gdzie klasyczne integracje są bezsilne – na starych systemach, portalach urzędowych i własnych aplikacjach firmowych bez wsparcia. To środowiska, w których robotyzacja nie konkuruje z API, bo API tam nie ma.

Paradoksalnie roboty pracujące na takich systemach są często stabilniejsze niż roboty pracujące na nowoczesnych SaaS. Stare systemy się nie zmieniają, więc robot raz nauczony – działa latami bez ingerencji. To czyni RPA na legacy systemach jedną z najlepiej zwracających się inwestycji.

Typowe scenariusze: stary moduł księgowy, portale urzędowe (ZUS, US, KRS, sąd, ePUAP), własna aplikacja firmowa bez wsparcia producenta. W każdym z nich RPA potrafi przejąć codzienne, powtarzalne operacje i uwolnić zespół do bardziej wartościowej pracy.

Dodatkowa zaleta: RPA na starych systemach kupuje firmie czas. Zamiast podejmować pośpieszne decyzje o wymianie systemów, można zautomatyzować to, co najbardziej boli, a strategiczną wymianę zaplanować spokojnie. Patrz też RPA vs integracja API i Dlaczego firmy nadal kopiują dane między systemami ręcznie, mimo dostępności RPA.