Najlepsza rekomendacja, jaką jeden z naszych klientów usłyszał w zeszłym roku na warsztacie, brzmiała: “tego nie automatyzujcie”. Nie “da się”, nie “policzymy wam licencje”, nie “zrobimy to w sześć tygodni”. Po prostu: nie warto, jeszcze nie teraz.
To brzmi jak strzał we własne kolano. Firma konsultingowa, która żyje z automatyzacji, mówi klientowi, żeby nie automatyzował. A jednak to właśnie ta rozmowa zbudowała więcej zaufania niż dziesięć slajdów o oszczędnościach. Bo klient usłyszał coś, czego rynek mu nie mówi.
Rynek mówi jedno: automatyzujcie wszystko. Teraz doszła do tego druga warstwa - wpuśćcie agentów AI, niech robią za was. Presja jest realna, a pokusa jeszcze większa, bo narzędzia są coraz lepsze i coraz łatwiejsze w użyciu. Problem w tym, że łatwość uruchomienia automatyzacji nie ma nic wspólnego z tym, czy dany proces w ogóle powinien zostać zautomatyzowany.
W tym Technologicznym Czwartku idziemy pod prąd. Zamiast kolejnej listy procesów, które warto zrobotyzować, pokazujemy cztery sygnały, że proces zabije wam projekt - i dajemy prosty test, który wychwyci to, zanim wydacie pierwszą złotówkę.
Automatyzacja to nie zawsze oszczędność. Bywa przyspieszonym wydatkiem
Zacznijmy od liczby, która powinna dać do myślenia każdemu, kto planuje program automatyzacji. Z obserwacji EY, opisanych w raporcie “Get ready for robots”, wynika, że nawet od 30 do 50 procent początkowych projektów RPA kończy się niepowodzeniem (dane z okolic 2016 roku - traktujcie je jako precedens sprzed lat, nie jako dzisiejszy stan rynku; mechanizm porażki jest jednak wciąż aktualny). To nie jest margines błędu. To rzut monetą.
Druga liczba jest jeszcze bardziej wymowna. Deloitte w globalnym badaniu RPA ustalił, że wówczas tylko 3 procent organizacji zdołało przeskalować cyfrową siłę roboczą do pięćdziesięciu lub więcej robotów (badanie z 2017 roku, opublikowane w 2018 - od tego czasu rynek dojrzał, ale luka między pilotażem a skalą została ta sama). Reszta utknęła na pilotażach i pojedynczych botach. Pilotaż działa, prezentacja robi wrażenie, a potem projekt cichnie - bo okazuje się, że utrzymanie tego, co zbudowano, kosztuje więcej, niż ktokolwiek zakładał.
Dlaczego tak się dzieje? Nie dlatego, że technologia jest zła. UiPath, na którym pracujemy jako partner Platinum, to dojrzała, potężna platforma. Problem prawie nigdy nie leży w narzędziu. Leży w doborze procesu. Automatyzacja jest jak dźwignia - wzmacnia to, co jej podłożycie. Podłożycie dobry, stabilny proces, a dostaniecie realne oszczędności. Podłożycie proces chaotyczny, zmienny i pełen wyjątków, a dostaniecie ten sam chaos, tylko szybszy i droższy w utrzymaniu.
Te cztery sygnały to filtr, który stosujemy w SNOK, zanim powiemy klientowi “tak”. Warto, żebyście stosowali go i Wy.
Sygnał 1 - Proces zmienia się szybciej, niż zdążycie go zautomatyzować
Robot programowy naśladuje człowieka klikającego w aplikacje. Widzi pola, przyciski, tabele - i odtwarza tę samą sekwencję setki razy. Dopóki ekran wygląda tak samo, bot działa bez zarzutu. Kłopot zaczyna się w momencie, gdy ekran się zmienia.
A ekran zmienia się częściej, niż myślicie. Dostawca aktualizuje interfejs aplikacji. Dział finansowy dokłada nowe pole do formularza. Wchodzi zmiana prawna i trzeba przebudować część procesu. Każda taka zmiana potrafi złamać bota, który dzień wcześniej działał idealnie. To zjawisko ma nawet swoją nazwę w branży - kruche selektory. Bot trzyma się konkretnego miejsca na ekranie albo konkretnej struktury pola, a gdy ta się przesuwa, automatyzacja przestaje rozumieć, co widzi.
Jeśli proces, który chcecie zautomatyzować, przechodzi istotną zmianę częściej niż raz na kwartał - a to próg, który z naszego doświadczenia sprawdza się jako granica ostrożności - budujecie coś, na czym spędzicie więcej czasu na naprawianiu niż na korzystaniu. Automatyzacja stabilizuje to, co stabilne. Nie goni ruchomego celu. Zanim zaczniecie, zadajcie sobie uczciwe pytanie: czy ten proces będzie wyglądał tak samo za rok? Jeśli nie potraficie odpowiedzieć “tak” z ręką na sercu, macie pierwszy sygnał ostrzegawczy.
To nie znaczy, że proces jest stracony na zawsze. Znaczy tylko, że dopóki się nie ustabilizuje, automatyzacja będzie beczką bez dna.
Sygnał 2 - Wejście nie jest ustandaryzowane ani cyfrowe
Automatyzacja karmi się przewidywalnością. Bot najlepiej radzi sobie z wejściem, które za każdym razem wygląda tak samo: ustrukturyzowany plik, formularz z tymi samymi polami, dane z systemu w stałym formacie. Wtedy potrafi przetworzyć tysiąc rekordów bez jednego błędu.
Rzeczywistość w wielu firmach wygląda inaczej. Dane przychodzą z pięciu źródeł, w pięciu formatach. Część w mailu, część w skanie, część w arkuszu, który każdy dział wypełnia po swojemu. Do tego swobodny tekst, literówki, brakujące pola i “przecież wiadomo, o co chodzi”. Dla człowieka to codzienność, z którą radzi sobie intuicyjnie. Dla bota to pole minowe.
Kiedy nakarmicie automatyzację takim wejściem, dostaniecie jeden z dwóch efektów. Albo bot będzie się wywracał na każdej nietypowej sprawie i zasypie was zgłoszeniami o błędach, albo, co gorsza, przetworzy błędne dane bez mrugnięcia i rozniesie pomyłkę po całym systemie z prędkością maszyny. Bo automatyzacja nie naprawia jakości danych. Ona ją powiela.
Dlatego zanim zautomatyzujecie proces, sprawdźcie, czy wejście jest cyfrowe i ustandaryzowane. Jeśli nie - to właśnie tam leży prawdziwa robota do zrobienia. Uporządkowanie danych źródłowych zwykle daje większy zwrot niż sama automatyzacja i jest warunkiem, żeby ta w ogóle miała sens. Automatyzacja bałaganu to wciąż bałagan.
Sygnał 3 - Wolumen jest za niski, żeby zwróciła się inwestycja
To najprostszy matematycznie sygnał, a mimo to najczęściej pomijany - bo automatyzacja bywa modna i chce się ją mieć niezależnie od rachunku.
Każda automatyzacja ma dwa koszty: budowę i utrzymanie. Budowa to jednorazowy wysiłek analizy, projektu i wdrożenia. Utrzymanie to koszt, który wraca co miesiąc, dopóki bot żyje - bo, jak pisaliśmy przy pierwszym sygnale, systemy się zmieniają i automatyzację trzeba dostrajać. Po drugiej stronie równania stoi oszczędność, czyli czas ludzi, których praca zostaje zdjęta.
Jeśli proces uruchamiacie kilka razy w miesiącu i za każdym razem zajmuje człowiekowi kwadrans, oszczędność jest symboliczna. Break-even, czyli moment, w którym automatyzacja zaczyna zarabiać, nie nastąpi nigdy - albo nastąpi za tak długo, że wcześniej proces i tak się zmieni. Automatyzacja ma sens tam, gdzie powtarzalność i wolumen tworzą realną dźwignię: proces uruchamiany dziesiątki albo setki razy dziennie, pochłaniający godziny pracy zespołu.
Zanim zaczniecie budować, policzcie. Ile razy w miesiącu ten proces się wykonuje? Ile czasu zajmuje ręcznie? Ile realnie kosztuje jego zbudowanie i roczne utrzymanie? Jeśli te liczby nie składają się w sensowny zwrot w rozsądnym horyzoncie, automatyzacja jest sztuką dla sztuki. Lepiej te same pieniądze i uwagę skierować na proces, który naprawdę udźwignie dźwignię.
Sygnał 4 - Wyjątki przewyższają regułę
Wyobraźcie sobie proces, w którym happy path - czyli standardowy przebieg bez komplikacji - pokrywa dwadzieścia procent przypadków. Pozostałe osiemdziesiąt to sytuacje nietypowe: “ten klient ma inną umowę”, “tu trzeba dopytać dział prawny”, “to zależy od tego, co powie kierownik”. Każdy z tych przypadków wymaga osądu, decyzji, kontekstu.
Taki proces da się zautomatyzować - technicznie prawie wszystko da się zautomatyzować. Ale każdy wyjątek to osobna gałąź logiki, którą trzeba zaprojektować, zbudować, przetestować i potem utrzymywać. Kiedy wyjątków jest więcej niż reguł, automatyzujecie głównie wyjątki. A to najdroższy i najbardziej kruchy rodzaj automatyzacji, jaki istnieje - drzewo decyzyjne, które puchnie z każdym kwartałem i którego nikt po roku nie rozumie w całości.
Sygnał czwarty to często sygnał, że proces jest po prostu zbyt skomplikowany - nie dla bota, lecz w ogóle. Zanim go zrobotyzujecie, warto zadać pytanie, czy nie da się go najpierw uprościć. Ograniczyć liczbę wyjątków, ujednolicić zasady, odciąć przypadki brzegowe, które wynikają z przyzwyczajenia, a nie z realnej potrzeby. Uproszczony proces często okazuje się świetnym kandydatem do automatyzacji. Ten sam proces w pierwotnej, rozgałęzionej formie - koszmarem utrzymaniowym.
Prosty test go/no-go, zanim wydacie pierwszą złotówkę
Cztery sygnały łatwo sprowadzić do pięciu pytań, które możecie zadać na dowolnym procesie jeszcze przed rozmową z dostawcą. To nasz test go/no-go:
- Stabilność. Czy proces będzie w tej samej formie za dwanaście miesięcy?
- Dane. Czy wejście jest cyfrowe i ustrukturyzowane?
- Zwrot. Czy wolumen daje realny zwrot w rozsądnym horyzoncie?
- Wyjątki. Czy standardowy przebieg pokrywa większość przypadków?
- Jakość procesu. Czy sam proces jest sensowny, czy tylko utrwalamy zły nawyk?
Reguła jest prosta. Jeśli na trzy lub więcej pytań odpowiadacie “nie”, to nie jest kandydat do automatyzacji. Przynajmniej jeszcze nie. Najpierw uporządkujcie proces, a dopiero potem do niego wróćcie. Wstrzymanie na tym etapie nie jest porażką. To zaoszczędzone pieniądze i nerwy.
Ten test celowo jest prosty. Nie zastąpi rzetelnej analizy wykonalności, którą i tak warto przeprowadzić przy poważniejszej inwestycji. Ale wychwyci najczęstsze pomyłki na etapie, na którym korekta kosztuje rozmowę, a nie spalony budżet.
Jak te sygnały wyglądają w praktyce
Teoria brzmi czysto, ale najlepiej widać ją na wzorcach, które powtarzają się u klientów niezależnie od branży. Poniżej cztery typowe sytuacje - celowo bez nazw i konkretnych liczb, bo chodzi o mechanizm, nie o pojedynczy przypadek.
Pierwszy sygnał najczęściej widać przy procesach opartych na aplikacji webowej zewnętrznego dostawcy, który regularnie zmienia interfejs. Bot działa świetnie przez kilka tygodni, aż przychodzi aktualizacja portalu i sekwencja przestaje się zgadzać. Zespół spędza więcej czasu na łataniu automatyzacji po kolejnych wdrożeniach dostawcy niż zaoszczędził na samym procesie. Rozwiązaniem bywa nie lepszy bot, lecz integracja przez API zamiast klikania po ekranie - o ile dostawca ją udostępnia.
Drugi sygnał klasycznie ujawnia się przy obsłudze dokumentów przychodzących od wielu podmiotów - faktur, zamówień, formularzy - w kilkunastu różnych układach, często jako skany o różnej jakości. Pokusa, żeby “wpuścić na to bota z OCR”, jest duża. Ale dopóki wejście nie zostanie choć częściowo ujednolicone albo uzupełnione o warstwę rozpoznawania dokumentów z walidacją, automatyzacja generuje więcej wyjątków do ręcznej obsługi niż spraw załatwionych samodzielnie.
Trzeci sygnał to procesy uruchamiane rzadko - na przykład raz w miesiącu przy zamknięciu okresu - które przy pierwszym oglądzie wyglądają na idealnych kandydatów, bo są uciążliwe. Dopiero rachunek pokazuje, że przy tej częstotliwości koszt budowy i utrzymania zwróciłby się po latach, a proces prawdopodobnie zmieni się wcześniej. Uczciwa kalkulacja bywa tu ważniejsza niż entuzjazm zespołu, który ma dość klikania.
Czwarty sygnał widać wszędzie tam, gdzie każda sprawa jest “trochę inna” - obsługa reklamacji, nietypowe przypadki kadrowe, negocjowane indywidualnie warunki. Drzewo wyjątków rośnie szybciej niż oszczędności, a po roku nikt w zespole nie potrafi już powiedzieć, co dokładnie robi automatyzacja w każdej gałęzi. To moment, w którym warto cofnąć się o krok i zapytać, czy proces nie wymaga najpierw uproszczenia po stronie organizacyjnej.
Wspólny mianownik tych czterech wzorców jest jeden: problem nigdy nie leżał w narzędziu. Leżał w tym, że proces nie był gotowy.
Automatyzacja zepsutego procesu to zepsuty proces, tylko szybszy
Jest pod tym wszystkim jedna zasada, którą warto zapamiętać ponad konkretnymi sygnałami. Automatyzacja niczego nie naprawia. Ona utrwala i przyspiesza to, co już jest.
Michael Hammer napisał o tym w “Harvard Business Review” jeszcze w 1990 roku, w słynnym artykule “Reengineering Work: Don’t Automate, Obliterate”. Jego zdanie przeszło do klasyki: czas przestać asfaltować krowie ścieżki. Zamiast zaklinać przestarzałe procesy w oprogramowaniu, trzeba je najpierw przemyśleć od nowa. Trzydzieści sześć lat później zdanie jest boleśnie aktualne, bo pokusa jest ta sama - łatwiej zautomatyzować to, co jest, niż zapytać, czy to w ogóle powinno tak wyglądać.
Kolejność ma znaczenie. Najpierw uprość i ustabilizuj proces, potem go zautomatyzuj. Odwrotna kolejność - najpierw robot, a porządkowanie kiedyś potem - to jeden z najczęstszych powodów, dla których projekty RPA nie dowożą obiecanego zwrotu. Bo automatyzujecie wtedy nie proces, tylko jego chaos.
Agentic AI nie znosi tych pytań. Podnosi stawkę
W tym miejscu pojawia się kontrargument, który słyszymy coraz częściej: przecież agenty AI zmieniają reguły gry. Agent lepiej radzi sobie ze zmiennością niż sztywny bot regułowy, potrafi zinterpretować niestrukturalne wejście, poradzi sobie z wyjątkiem, którego nie przewidziano. Czy to nie znosi czterech sygnałów?
Częściowo tak. Agent oparty na modelu językowym rzeczywiście znosi wariancję lepiej niż selektor przyklejony do konkretnego pola. To realny postęp i sami budujemy takie rozwiązania w ramach inteligentnej automatyzacji na ścieżce Agentic Automation UiPath. Ale byłoby błędem uznać, że agent znosi problem. On go przenosi na wyższy poziom - i podnosi stawkę.
Agent na niestabilnym, chaotycznym procesie to jednocześnie źródło niedeterministycznych błędów (bo model nie zawsze odpowie tak samo) i nowa powierzchnia ryzyka. Uprawnienia, którymi dysponuje agent, prompt injection, brak czytelnego audytu decyzji, koszty, które rosną z każdym wywołaniem modelu - to wszystko sprawia, że zły proces obsługiwany przez agenta jest nie tańszym, lecz droższym i trudniejszym do skontrolowania problemem. Pisaliśmy o tej nowej powierzchni ataku osobno, bo to temat na cały artykuł.
Rynek już to weryfikuje. Gartner prognozuje, że ponad 40 procent projektów agentic AI zostanie anulowanych do końca 2027 roku - z powodu rosnących kosztów, niejasnej wartości biznesowej i niewystarczających mechanizmów kontroli ryzyka (komunikat Gartnera z czerwca 2025). To dokładnie te same przyczyny, które kładły projekty RPA dekadę wcześniej. Technologia się zmieniła, pytania zostały te same.
Nasza pozycja: mówienie “nie” to część roboty
W SNOK traktujemy dobór procesu jako pierwszy i najważniejszy etap każdego projektu automatyzacyjnego. Zanim zaproponujemy architekturę, licencje czy harmonogram, przechodzimy przez ten filtr razem z klientem. Czasem kończy się to rekomendacją, żeby wstrzymać się z automatyzacją i najpierw uporządkować proces. Wiemy, że to nie jest to, co dostawca “powinien” mówić. Ale to jest to, co uczciwy doradca mówić musi.
Jak ujmuje to Michał Korzeń, CTO SNOK:
“Najdroższy bot to nie ten, którego nie zbudowaliśmy. To ten, który działa, ale trzeba go naprawiać po każdej aktualizacji systemu. Dlatego zanim cokolwiek zautomatyzujemy, pytamy klienta nie o to, czy się da, tylko czy proces jest gotowy. Zwykle najpierw trzeba go uporządkować.”
To nie jest ostrożność dla ostrożności. To rachunek. Projekt, który startuje na dobrze dobranym procesie, dowozi zwrot i rośnie. Projekt, który startuje na złym procesie, pochłania budżet, frustruje zespół i kończy się w statystyce tych 30-50 procent, które nie dowiozły.
Trzy ruchy, zanim wrócicie do automatyzacji
Proces, który nie przeszedł testu, nie trafia do kosza. Trafia do kolejki - z konkretną listą rzeczy do zrobienia, które zwykle i tak przynoszą wartość niezależnie od tego, czy na końcu pojawi się bot.
Pierwszy ruch to uproszczenie. Jeśli proces poległ na czwartym sygnale, przyjrzyjcie się wyjątkom. Ile z nich wynika z realnej potrzeby, a ile z przyzwyczajenia, historycznej decyzji albo tego, że “zawsze tak robiliśmy”? Odcięcie choćby połowy przypadków brzegowych potrafi zamienić proces nieautomatyzowalny w oczywistego kandydata. To praca organizacyjna, nie techniczna, i często najtrudniejsza - bo wymaga decyzji, a nie kodu.
Drugi ruch to ustabilizowanie wejścia. Jeśli proces poległ na drugim sygnale, zapytajcie, gdzie powstają dane i czy da się je uporządkować u źródła. Jeden ustandaryzowany formularz zamiast pięciu wariantów, integracja zamiast ręcznego przepisywania, walidacja na wejściu zamiast poprawek na końcu. To inwestycja, która zwraca się nawet bez automatyzacji, a dopiero robi z niej realną opcję.
Trzeci ruch to zmierzenie. Jeśli proces poległ na trzecim sygnale, zbierzcie twarde dane, zanim podejmiecie decyzję: rzeczywistą częstotliwość, czas wykonania, liczbę osób zaangażowanych. Bardzo często okazuje się, że proces, który “wydawał się” uciążliwy, w liczbach nie uzasadnia inwestycji - albo że prawdziwy koszt leży zupełnie gdzie indziej niż tam, gdzie zamierzaliście postawić bota.
Dopiero po tych ruchach warto wrócić do testu go/no-go. Zwykle proces, który wcześniej zbierał trzy odpowiedzi “nie”, po uporządkowaniu przechodzi bez trudu - i wtedy automatyzacja robi dokładnie to, co obiecuje.
Co z tym zrobić w praktyce
Jeśli planujecie automatyzację - RPA, agenty AI, cokolwiek pośrodku - zacznijcie od zmiany pytania. Nie pytajcie “czy da się to zautomatyzować”, bo odpowiedź prawie zawsze brzmi “tak”. Pytajcie “czy powinniśmy to teraz automatyzować”, a potem przepuśćcie proces przez pięć pytań testu go/no-go.
Trzy odpowiedzi “nie” to nie wyrok. To informacja, że najpierw jest inna robota do zrobienia - i że warto ją zrobić, zanim wpuścicie na proces bota albo agenta. Automatyzacja dobrego procesu to dźwignia. Automatyzacja złego to przyspieszony wydatek.
Jeśli chcecie przepuścić swój proces przez ten filtr z kimś, kto powie wam “nie”, gdy trzeba - porozmawiajmy. Czasem najlepszą rekomendacją, jaką od nas usłyszycie, będzie “tego jeszcze nie automatyzujcie”. I to też jest wartość.
Technologiczny Czwartek ze SNOK - cotygodniowa dawka praktycznej wiedzy o automatyzacji, SAP i cyberbezpieczeństwie. Więcej o naszym podejściu do automatyzacji przeczytacie w tekstach Od pomysłu do agenta na produkcji, Agent AI po obu stronach ataku oraz Automatyzacja SAP - klucz do efektywności działów IT.
Źródła
- EY, “Get ready for robots: Why planning makes the difference between success and disappointment” (ok. 2016) - nawet 30-50% początkowych projektów RPA nie osiąga celów. https://eyfs.ie/wp-content/uploads/2016/11/ey-get-ready-for-robots.pdf
- Deloitte, “The robots are ready. Are you? Global RPA Survey” (badanie 2017, publikacja 2018) - tylko 3% organizacji przeskalowało do 50+ robotów. https://www2.deloitte.com/be/en/pages/strategy-operations/core-business-operations/articles/therobotsarereadyareyou.html
- Gartner, komunikat prasowy z 25.06.2025 - ponad 40% projektów agentic AI zostanie anulowanych do końca 2027. https://www.gartner.com/en/newsroom/press-releases/2025-06-25-gartner-predicts-over-40-percent-of-agentic-ai-projects-will-be-canceled-by-end-of-2027
- Michael Hammer, “Reengineering Work: Don’t Automate, Obliterate”, Harvard Business Review, lipiec-sierpień 1990.