RPA w firmie – które procesy warto automatyzować robotami jako pierwsze

Zanim wskażemy konkretny proces, warto przejść przez cztery pytania. Te same pytania zadaje sobie każdy doświadczony zespół robotyzacji, choć rzadko się je formułuje wprost.

Pytanie pierwsze: czy proces da się opisać krok po kroku, tak żeby ktoś nowy mógł go wykonać czytając instrukcję. Jeśli nie – to nie jest kandydat dla RPA, bo robot nie radzi sobie z to zależy. Jeśli tak – idziemy dalej.

Pytanie drugie: jak często ten proces się wykonuje. Codziennie, kilka razy w tygodniu, raz w tygodniu, raz w miesiącu. Im częściej – tym lepiej, bo czas się szybciej kumuluje. Procesy wykonywane raz w miesiącu na 30 minut to słaby kandydat, choćby były bardzo irytujące.

Pytanie trzecie: ile osób w firmie wykonuje ten sam proces albo bardzo podobny. Jeśli pięć osób w dziale codziennie robi to samo – wartość rośnie pięciokrotnie. Procesy wykonywane przez wiele osób z tym samym scenariuszem są najszybciej zwracającymi się projektami.

Pytanie czwarte: ile w tym procesie jest decyzji merytorycznych. Jeśli zero albo bardzo niewiele – idealne. Jeśli proces co krok zatrzymuje się na zastanawiam się – robot nie pomoże. Tam, gdzie człowiek musi ocenić, decydować, oceniać – proces nie nadaje się dla RPA w czystej postaci.

Z doświadczenia wdrożeń RPA w polskich firmach układa się powtarzalna lista procesów, które są dobrym pierwszym wyborem. Nie są to spektakularne projekty, ale dają mierzalne efekty w kilka tygodni.

Wprowadzanie faktur od dostawców. Codziennie wpływa od kilkudziesięciu do kilkuset faktur, ktoś je wprowadza ręcznie do systemu księgowego. To klasyczny pierwszy projekt, bo proces jest powtarzalny, reguły są jasne (numer, data, NIP, kwota), a wartość jest mierzalna w godzinach dziennie.

Codzienne raporty. Ktoś codziennie rano pobiera dane z trzech systemów, łączy w Excelu, sformatuje i rozsyła. 60–90 minut dziennie, każdy dzień. Robot wykona to w 5 minut, codziennie, bez wyjątku. Wartość – kilka godzin pracy tygodniowo.

Sprawdzanie statusów w portalach. Spedycja, logistyka, sprawy urzędowe – wszędzie tam ktoś codziennie klika po to samo, żeby sprawdzić, czy coś się zmieniło. Robot loguje się, pobiera, aktualizuje i powiadamia tylko o zmianach.

Onboarding ticketów i spraw. Klient zgłasza problem przez formularz, ktoś otwiera go w trzech systemach, dopina dokumenty, generuje numer, odpisuje. Robot tworzy sprawę w 30 sekund, człowiek skupia się na rozwiązaniu, nie na otwieraniu sprawy.

Transfer danych między systemami. Eksport z CRM-a, import do ERP. Eksport ze sklepu, import do magazynu. Eksport z monday.com, import do księgowości. Wszędzie tam, gdzie nie ma integracji, robot ją zastępuje.

Niektóre procesy wyglądają jak idealni kandydaci, dopóki nie wejdziemy w nie głębiej. Warto je rozpoznać wcześnie, bo zaoszczędzą firmie miesięcy frustracji.

Procesy oparte na mailach pisanych przez ludzi. Wygląda atrakcyjnie – maile przychodzą codziennie, ktoś je obsługuje, dlaczego nie wziąć robota. Problem w tym, że ludzie piszą maile na 50 sposobów. Robot nie zrozumie treści maila. To zadanie wymaga AI + RPA, nie sama RPA.

Procesy z dokumentami w wielu formatach. Faktury w czterech wzorcach to RPA, faktury w 30 wzorcach to już AI + OCR + RPA. Ten sam rodzaj problemu, dwie zupełnie różne skale wdrożenia.

Procesy, w których trzeba podjąć decyzję merytoryczną. Zaakceptować wniosek urlopowy zależnie od sytuacji w zespole. Odpowiedzieć na pytanie klienta zależnie od historii relacji. Sklasyfikować dokument na podstawie kontekstu. Wszędzie tam czysty RPA się wywróci, bo każda decyzja oznacza, że robot się zatrzymuje.

Procesy, które miałyby zniknąć po reorganizacji. Czasem proces istnieje tylko dlatego, że ktoś nie miał czasu go uprościć. Jeśli za sześć miesięcy systemy zostaną zintegrowane i sam proces zniknie – nie ma sensu wdrażać robota tylko na ten okres. Lepiej cierpieć ręcznie sześć miesięcy.

Najprostszy rachunek: ile czasu zajmuje proces w skali roku, jaka jest stawka osoby go wykonującej, jaki będzie koszt robota.

Przykład pierwszy. Proces: 60 minut dziennie, jedna osoba, 250 dni roboczych. Łącznie 250 godzin w skali roku. Koszt godziny zewnętrznej (z narzutami) około 80 zł. Wartość czasu odzyskanego: 20 tys. zł rocznie. Koszt wdrożenia robota dla takiego procesu: 15–25 tys. zł jednorazowo plus kilka tys. zł rocznie utrzymania. Zwrot: 12–14 miesięcy. Zaczyna mieć sens, ale niespecjalnie ekscytujący.

Przykład drugi. Proces: 120 minut dziennie, trzy osoby, 250 dni roboczych. Łącznie 1500 godzin w skali roku. Wartość czasu: 120 tys. zł. Koszt wdrożenia: 25–40 tys. zł. Zwrot: 3–4 miesiące. Tu już jest realna wartość.

Przykład trzeci. Proces: 30 minut dziennie, jedna osoba, 250 dni. Łącznie 125 godzin rocznie. Wartość: 10 tys. zł. Koszt wdrożenia: 12–18 tys. zł. Zwrot: 14–18 miesięcy. To na granicy opłacalności, raczej nie pierwszy projekt.

Zasada praktyczna: pierwszy projekt powinien zwracać się w 4–8 miesięcy. Krótsze okresy są mało prawdopodobne dla pierwszego wdrożenia, dłuższe oznaczają, że proces nie nadaje się jako pilot. Po pierwszym sukcesie kolejne projekty mogą mieć dłuższy okres zwrotu, bo zespół już wie, co robi.

Pomijane przy doborze procesów, ale często decydujące: na ilu i jakich systemach pracuje robot. Im więcej systemów – tym większa szansa, że któryś z nich będzie się aktualizował, zmieniał interfejs, restartował.

Procesy na systemach Microsoft 365 są w praktyce najstabilniejsze. Outlook, SharePoint, Teams, Excel zmieniają się powoli i przewidywalnie. Robot na takim stack-u może działać latami bez zmian.

Procesy na nowoczesnych aplikacjach SaaS bywają trudniejsze. Dostawcy SaaS aktualizują interfejs co kilka tygodni, czasem bez ostrzeżenia. Robot się wywraca, bo przycisk Zapisz nagle nie ma już takiej samej etykiety. Lepiej tu szukać API i robić integrację, a RPA zostawić na resztę.

Procesy na starych systemach Windowsowych są często paradoksalnie najstabilniejsze. Stary ERP wygląda dokładnie tak samo od 10 lat. Robot raz nauczony – działa bez zmian. To dlatego RPA tak dobrze sprawdza się tam, gdzie systemy są stare i nie ma planu ich wymiany. Więcej w artykule RPA w firmach bez API – jak automatyzować stare systemy.

Wniosek praktyczny: dla pierwszego projektu wybieramy proces na stabilnych systemach. Najlepiej takich, które nie zmieniły interfejsu od miesięcy. Po pierwszym sukcesie i nauce można brać się za trudniejsze, mniej stabilne procesy.

Pułapka pierwsza: wybór najbardziej irytującego procesu. Zarząd ma swój ulubiony proces, który chciałby zlikwidować. Często to dobry kandydat psychologicznie, ale słaby technicznie. Najczęściej są to procesy zbyt rzadkie, zbyt zmienne albo wymagające decyzji.

Pułapka druga: wybór najbardziej spektakularnego procesu. Chcemy robota, który zrobi coś, czego nigdy nie udało się zrobić. Tymczasem pilot powinien być nudny, mały, mierzalny – nie spektakularny. Spektakularne projekty zostawiamy na drugi i trzeci raz.

Pułapka trzecia: wybór procesu w jednej osobie. Ktoś jeden zna ten proces od lat, robi go w pamięci. Robotyzacja takiego procesu wymaga najpierw spisania go z głowy tej osoby, a to bywa trudniejsze niż samo wdrożenie robota.

Pułapka czwarta: wybór procesu zaplanowanego do zmiany. Mamy proces, robi go ktoś codziennie, ale za rok wymieniamy ERP i proces zniknie. Pilot pójdzie zgodnie z planem, robot będzie działał, a potem firmę spotka tego konsekwencja – wdrożenie do wyrzucenia.

Pułapka piąta: brak właściciela. Zespół wdraża robota, ale nikt w firmie nie czuje się odpowiedzialny za jego utrzymanie. Po kilku miesiącach robot się zatrzymuje, nikt nie wie dlaczego, nikt nie ma czasu. Bez właściciela RPA się nie kończy – po prostu wygasa.

Wybór pierwszego procesu RPA decyduje o tym, czy w firmie przyjmie się robotyzacja na dłużej. Dobry pilot to nudny pilot – powtarzalny, mierzalny, na stabilnych systemach, bez decyzji merytorycznych.

Cztery pytania pomagają wybrać: czy proces da się opisać, jak często się wykonuje, ile osób go robi, ile decyzji wymaga. Jeśli odpowiedzi są dobre, kolejny krok to prosty rachunek wartości czasu odzyskanego.

Idealny pierwszy projekt zwraca się w 4–8 miesięcy. Procesy najlepsze na pierwszy raz to wprowadzanie faktur, codzienne raporty, sprawdzanie statusów, otwieranie spraw, transfer danych między systemami bez integracji.

Wystrzegamy się procesów wymagających rozumienia maili, dokumentów w wielu formatach i decyzji merytorycznych – to obszar dla RPA + AI razem, nie samego RPA. Więcej w artykule Czym różni się RPA od AI.