Kiedy RPA nie ma sensu? Najczęstsze błędy przy robotyzacji procesów

Najczęstszy błąd jest zarazem najprostszy: bierzemy proces, który nie powinien istnieć w obecnej formie, i robotyzujemy go. Robot wykonuje go szybciej, ale problem polega na tym, że ten proces w ogóle nie powinien się odbywać.

Klasyczny przykład. Codziennie ktoś z księgowości eksportuje listę faktur z systemu A, otwiera Excel, modyfikuje ją ręcznie, zapisuje, importuje do systemu B. Wygląda jak idealny kandydat dla RPA – powtarzalny, regularny, mierzalny. Po analizie okazuje się, że system A i system B obsługują dokładnie te same faktury, tylko w innej kolejności. Nikt nie pamięta, dlaczego to się dzieje, ale tak robimy od pięciu lat. Lepszą odpowiedzią niż robot jest tu pytanie czy ten transfer w ogóle jest potrzebny.

Drugi przykład. Codziennie 30 minut komuś zajmuje przygotowanie raportu dla zarządu. Otwiera trzy systemy, łączy w Excelu, formatuje. Po wdrożeniu robota raport jest gotowy w 5 minut. Świetnie. Po pół roku nikt go już nie czyta – zarząd przeszedł na inny dashboard. Ale robot dalej generuje raport, robi to codziennie, bo nikt go nie wyłączył. Klasyk: zautomatyzowaliśmy proces, który dawno wyszedł z użycia.

Lekcja: zanim wdrożymy robota, warto zadać pytanie czy ten proces w ogóle musi się odbywać. Czasem najlepszą odpowiedzią na ręczny proces jest wyrzucić go, a nie zautomatyzować.

Proces stabilny zmienia się raz na rok. Proces niestabilny zmienia się co kilka tygodni. Robotyzacja takiego procesu to zaproszenie do ciągłego utrzymania.

Klasyczny przykład. Firma wdraża robota do obsługi faktur. Wszystko działa pięknie przez dwa miesiące. Potem główny dostawca zmienia format faktury. Robot się wywraca. Ktoś musi go poprawić – kilka godzin pracy. Po kolejnych dwóch miesiącach inny dostawca zmienia format. Znowu robot się wywraca. Po pół roku zespół IT spędza więcej czasu na łataniu robota, niż wcześniej spędzał na ręcznym wprowadzaniu faktur.

Drugi przykład – dotyczy procesów oczekujących na zmianę. Firma planuje migrację z starego ERP-a na nowy w ciągu 12 miesięcy. Tymczasem zaczyna wdrażać robota do procesu, który po migracji zniknie. 80 procent pracy idzie do kosza wraz z migracją.

Trzeci przykład – aplikacje SaaS z częstymi aktualizacjami interfejsu. Robot napisany pod konkretną wersję ekranu przestaje działać po każdej większej aktualizacji. To nie jest wina robota – to wybór niewłaściwego procesu.

Lekcja: jeśli proces zmienia się często, sam systemy zmieniają interfejsy, albo planowana jest migracja – RPA nie jest dobrym pomysłem. Lepiej poczekać, aż wszystko się ustabilizuje, albo wybrać inną technologię.

RPA jest świetne, gdy proces da się opisać jako jasna sekwencja. Im więcej w procesie miejsc, w których trzeba podjąć decyzję merytoryczną – tym mniej RPA się sprawdza.

Konkretny przykład. Firma chce zrobotyzować obsługę wniosków urlopowych. Pierwszy rzut oka: idealny kandydat – formularz, lista zatwierdzeń, kalendarz. Ale przy szczegółach okazuje się, że każdy wniosek wymaga oceny: czy w tym tygodniu w zespole są inne urlopy, czy klient ma akurat ważny termin, czy wnioskodawca już brał dużo wolnego w tym kwartale. To nie są reguły – to oceny sytuacyjne. Robot tu się wywróci.

Lepsze rozwiązanie: workflow (Power Automate, monday.com, Jira) prowadzi wniosek przez kolejnych zatwierdzających, ale decyzję podejmuje człowiek. Robot może obsłużyć część rutynową – sprawdzenie limitu, przygotowanie listy konfliktów z kalendarza, wysłanie maila do następnego zatwierdzającego. Ale samej decyzji o akceptacji nie podejmie.

Drugi przykład. Klasyfikacja reklamacji. Klient pisze: produkt do mnie nie dotarł, proszę o zwrot pieniędzy. Brzmi prosto. Aż się okazuje, że klient już 5 razy pisał takie zgłoszenia, a dwa razy jednak produkt dotarł, tylko był schowany. RPA nie ma jak tego ocenić. Tu jest miejsce dla AI – do oceny treści maila i historii relacji – plus RPA do wykonania decyzji.

Lekcja: jeśli proces ma w sobie więcej niż dwie decyzje wymagające oceny ludzkiej – sama RPA nie wystarczy. Tu wchodzi temat AI + RPA, opisany w artykule Czym różni się RPA od AI.

Bez wyznaczonej osoby odpowiedzialnej za roboty robotyzacja w firmie wygasa po roku. To zdecydowanie najczęstszy powód, dla którego projekty RPA przestają działać.

Scenariusz wygląda tak. Firma wdraża pierwsze trzy roboty. Wszystko działa świetnie. Konsultant zewnętrzny kończy projekt, dziękujemy, wystawiamy fakturę, do widzenia. W firmie nie ma jednej osoby, która czuje się odpowiedzialna za działanie tych robotów. Wszyscy mają inne obowiązki, robot to dodatek.

Po trzech miesiącach pierwszy robot się zatrzymuje. Powód: główny dostawca zmienił układ swojego portalu. Nikt tego nie zauważa od razu – robot pracował w nocy, raport poszedł rano, dane są prawdopodobnie aktualne. Po tygodniu ktoś z działu zauważa, że dane są stare. Próbują znaleźć osobę, która opiekuje się robotami. Nie ma takiej osoby. Konsultant zewnętrzny wraca, naprawia za 1500 zł. Sześć tygodni później sytuacja się powtarza.

Po roku trzy roboty są zatrzymane, firma płaci licencje, nikt z tego nie korzysta. Wszyscy są zniechęceni do RPA: próbowaliśmy, nie działa. Tymczasem to nie RPA nie zadziałało – nie zadziałało nasze podejście do utrzymania.

Lekcja: właściciel robotów jest tak samo ważny jak sam robot. Nie musi to być osobne stanowisko – może to być rola w istniejącym zespole. Ale musi być nazwana, znana wszystkim i mająca priorytet w sytuacji, gdy coś się zepsuje.

RPA powstało dla świata, w którym systemy nie mają normalnego sposobu komunikowania się ze sobą. Tam, gdzie systemy mają API – bardziej naturalna jest integracja, nie robot klikający w przeglądarce.

Najczęstszy przypadek. Firma chce, żeby dane sprzedażowe z Salesforce pojawiały się automatycznie w monday.com. Zatrudniony konsultant proponuje robota RPA, który będzie codziennie logował się do obu systemów, pobierał dane z jednego i wpisywał do drugiego. To rozwiązanie zadziała. Ale: Salesforce ma w pełni dojrzałe API, monday.com też. Integracja przez API w Power Automate Cloud zajmie 1–2 dni i będzie działała latami bez modyfikacji. Robot będzie wymagał regularnego utrzymania, bo oba systemy aktualizują interfejsy co kilka miesięcy.

Inny przypadek. Firma chce, żeby maile potwierdzające zamówienia trafiały automatycznie do CRM-a. Konsultant proponuje RPA. Tymczasem zarówno CRM, jak i system mailowy mają konektory w Power Automate Cloud. Konektory załatwiają to w 2 godziny.

Lekcja: zawsze najpierw sprawdzamy, czy systemy mają API. Jeśli tak – pierwsza opcja to integracja, RPA jest opcją zapasową. RPA jest świetne dla systemów bez API: stary ERP, portal urzędowy bez integracji, aplikacja, której producent dawno przestał rozwijać. Tym tematem zajmuje się RPA w firmach bez API – jak automatyzować stare systemy.

Wielu menedżerów na pierwszym wdrożeniu chce zrobotyzować od razu duży, skomplikowany proces. Wynika to z presji wynikowej: skoro płacimy za projekt, niech od razu daje duży efekt. Niestety, tak nie działa to z RPA.

Klasyczny scenariusz porażki. Firma decyduje się na pierwsze wdrożenie, ale celuje od razu w obsługę zwrotów klientów – proces, który dotyka pięciu systemów, ma 30 wariantów wykonania, wymaga integracji z księgowością i magazynem. Konsultant wycenia 12 miesięcy wdrożenia. Po 8 miesiącach robot jeszcze nie działa, budżet się rozszedł, zespół zniechęcony, zarząd zmienia priorytety. Projekt porzucony.

Lepsze podejście: pierwszy projekt – mały, nudny, mierzalny. Trzy miesiące wdrożenia, jeden prosty proces. Robot działa, zespół widzi efekt, uczy się obsługi. Po pierwszym sukcesie kolejne projekty idą wielokrotnie szybciej – bo zespół już wie, jak żyć z robotami.

Drugie podejście do tego błędu: porywanie się na proces, którego nikt w firmie do końca nie rozumie. Konsultant nie poznał szczegółów, klient sam dokładnie ich nie zna. Wdrożenie kończy się serią zaskoczeń, a każde z nich kosztuje dodatkowe tygodnie pracy. Lekcja: jeśli sami nie umiemy opisać procesu na kartce A4, to nie jest moment na RPA.

Lekcja: pierwszy projekt to nauka. Liczy się prostota, mierzalność i sukces w sensownym terminie, a nie spektakularny efekt.

RPA nie ma sensu tam, gdzie procesy są złe, niestabilne, rzadkie, wymagające decyzji albo gdzie systemy mają normalne API. Nie ma też sensu tam, gdzie nikt w firmie nie chce się czuć odpowiedzialny za działanie robotów po wdrożeniu.

Sześć najczęstszych błędów: robotyzacja złego procesu, robotyzacja niestabilnego procesu, robotyzacja procesu z decyzjami merytorycznymi, wdrożenie bez właściciela, RPA tam, gdzie pasuje API, oraz za duże ambicje na start.

Te błędy są przewidywalne i da się ich uniknąć. Wystarczy zadać sobie zerowe pytanie: czy proces, który chcemy zrobotyzować, w ogóle ma istnieć. Jeśli tak – sprawdzamy stabilność, decyzyjność, dostępność API. Jeśli wszystkie warunki spełnione i mamy właściciela robotów na pokładzie – możemy ruszać.

Jeśli pierwsze pytania zwracają wątpliwości – lepiej poczekać, niż zacząć i się sparzyć. Praktyczne podejście do wyboru pierwszych procesów opisuje RPA w firmie – jakie procesy automatyzować.