5 automatyzacji, które się nie udały — i dlaczego (porady antywzorce) 

Większość wdrożeń automatyzacji, które się nie udały, nie wyglądała jak katastrofa. Wyglądała jak projekt, który ciągnie się miesiącami, kosztuje więcej, niż zakładano, i kończy się bez wdrożenia. Poniżej pięć takich przypadków opisanych w publikowanych analizach, każdy z liczbami, przyczyną i konkretną naprawą. Wspólny mianownik jest prosty: w każdym z nich najpierw podjęto decyzję o narzędziu, a dopiero potem o procesie, który miał się zmienić. Albo nie było osoby odpowiedzialnej za wynik.

Skala problemu w liczbach

O niepowodzeniach mówi się dużo, ale liczby z różnych badań dotyczą różnych rzeczy. Jedno badanie S&P Global obejmujące ponad tysiąc liderów IT i biznesu w Europie i Ameryce Północnej podaje, że 42% firm porzuciło większość swoich inicjatyw AI jeszcze przed produkcją, wobec 17% rok wcześniej. To wzrost ponad dwukrotny w ciągu roku.

Inny zestaw danych, przywołany w analizie wdrożeń enterprise, mówi o 5% własnych narzędzi AI, które docierają do produkcji, i o 87% pilotaży oraz proof-of-concept, które do niej nie trafiają. Z raportów branżowych z 2024 roku wynika z kolei, że tylko 26% inicjatyw AI wychodzi poza fazę pilota. Do tego Ernst & Young podaje, że od 30% do 50% projektów robotycznej automatyzacji nie powodzi się globalnie.

Jeżeli dodać do tego badanie BCG obejmujące ponad tysiąc przedsiębiorstw, wychodzi najważniejsza liczba tego artykułu: około 70% problemów przy skalowaniu AI to kwestie ludzi i procesu, około 20% to technologia i dane, a tylko 10% to sam model. Innymi słowy: lepszy model rzadko jest tym, co ratuje projekt, bo rzadko jest problemem.

Ta proporcja przesuwa całą rozmowę. Nie pytasz, jaki model kupić, tylko który proces jest zepsuty, kto za niego odpowiada i po czym poznać, że jest lepiej.

Automatyzacja pierwsza: zamiana działającego procesu na nowsze narzędzie

Zacznijmy od przypadku, w którym wszystko było zrobione dobrze poza jednym punktem. Firma logistyczna miała proces rutowania przesyłek: 200 tysięcy transakcji dziennie, jasne reguły, gotowy bot RPA działający z dokładnością 99,2%. Zamiast szukać w nim dalszego punktu wzrostu, firma postawiła na agenta AI.

Po sześciu miesiącach i 400 tysiącach dolarach agent działał na poziomie 94% dokładności. Projekt wstrzymano. Po dwunastu miesiącach migracji na podejście agentowe okazało się, że 60% zautomatyzowanych procesów działa wolniej, kosztuje więcej i jest mniej odporne na błędy niż zastąpione przez nie boty RPA. Pozostałe 40% faktycznie się poprawiło.

Wniosek nie brzmi „nie używajcie agentów”, tylko: tam, gdzie proces jest duży, deterministyczny, opiera się na uporządkowanych danych i ma już dokładność powyżej 95%, zostaje RPA. Zmiana paradygmy musi mieć powód wykraczający poza modę. Warto przy tym rozróżnić różnicę między zwykłą automatyzacją a AI, bo to dwie różne klasy kosztu i ryzyka.

Co bym sprawdził przed taką decyzją: czy nowy wariant rozwiązuje konkretny ból, którego nie da się zamknąć prostą regułą. Jeśli da, nie ruszaj.

Automatyzacja druga: decyzja bez ustalonego limitu

Ubezpieczyciel postawił agenta do oceny roszczeń. Agent zatwierdził roszczenie na 180 tysięcy dolarów, czyli trzykrotność limitu polisy. Powód był przewidywalny: opis szkody był szczegółowy i emocjonalnie przekonujący, a model uznał go za wiarygodny. Reguła „kwota roszczenia nie może przekroczyć limitu polisy” nigdzie nie stała. Jej dodanie zajęłoby 20 minut pracy.

Ten sam mechanizm w dziale rozliczeń wywołał 2,3 mln dolarów ekspozycji: agent zatwierdził 47 faktur z numerami zamówień niezgodnymi z dokumentacją. Opanowanie skutków trwało sześć miesięcy.

Ten sam raport opisuje osobny przypadek: dwa agenty pracujące równolegle nad tym samym stanem uszkodziły 300 zapisów w dwa dni, zanim ktokolwiek to zauważył. Nie było nikogo, kto odpowiadał za stan tych danych.

Lekarstwo jest nieintuicyjne, bo brzmi jak formalność, a działa jak hamulec. Granice uprawnień ustala się przed pisaniem promptu, a egzekwuje się w trzech miejscach, nie w jednym: w prompcie, w definicji narzędzia i w orkiestracji. Jedno z tych trzech miejsc zawsze zawiedzie. Przy decyzjach, które mają koszt pieniężny, człowiek w pętli nie jest opcją.

Automatyzacja trzecia: wdrożenie, o którym nikt nie wie, że przestało działać

To najcichszy rodzaj porażki, bo dashboard wygląda dobrze. Zespół wdrożył agenta, zestaw testowy pokazywał 91% dokładności. Sześć tygodni później dostawca modelu wypuścił cichą aktualizację - ta sama nazwa wersji, inne zachowanie. Dokładność spadła do 78%. Zespół nie wiedział o tym przez trzy tygodnie, nie dlatego, że nikt nie patrzył, tylko dlatego, że monitoring mierzył wolumen i szybkość, a nie jakość.

W innym wdrożeniu kwartalny audyt wykazał, że dla 22% spraw agent podawał klientom błędną informację o zasadach zwrotów. Konsekwentnie, pewnie i przez sześć tygodni. Tego nie dało się zauważyć w statystykach wolumenu, bo wolumen był idealny.

Różnica między wdrożeniem dobrym a takim, które cicho umiera, mieści się w jednym artefakcie: zestawie 50 do 100 realnych przypadków z poprawnym wynikiem, przygotowanym przed produkcją. Jeżeli nikt w projekcie nie potrafi takiego zestawu wskazać, jakość systemu jest kwestią opinii, a opinie się rozjeżdżają. Do tego jeden alarm: gdy wynik spada o więcej niż 5 punktów poniżej wartości wyjściowej, system się zatrzymuje i ktoś się temu przygląda.

Praktyczne pytanie przed wdrożeniem brzmi: gdyby to przestało działać jutro po cichu, ile czasu zajęłoby zauważenie? Jeśli odpowiedź brzmi „tygodnie”, monitoring budujemy przed systemem, nie po nim.

Automatyzacja czwarta: pilot, który nigdy nie trafił na produkcję

Najczęstszy scenariusz w firmach nie wygląda jak porażka, tylko jak wieczny status „w przygotowaniu”. Dziewięć miesięcy po starcie pilot się kończy i nic nie zostaje wdrożone. W analizie enterprise opisano to dosłownie: dziewięć miesięcy później pilot się kończy, nic nie wchodzi na produkcję.

W studium szpitala pierwszy pilot zbudowany od zera trwał dziewięć miesięcy i się nie udał. Druga próba, na platformie, doszła do produkcji w cztery miesiące i zadziałała. W tym samym materiale każda kolejna integracja pochłaniała od dwóch do trzech miesięcy, więc przy czterech integracjach sam ten etap zjadał od ośmiu do dwunastu miesięcy.

Równolegle pada pytanie, które rzadko ktoś zadaje na starcie: czy budżet obejmuje utrzymanie, monitoring, przeliczenia, ewaluacje i zgodność z regulacjami przez co najmniej 24 miesiące po uruchomieniu. Jeśli budżet kończy się w dniu startu, kończy się wraz z nim program.

Co działa, to rollout rozłożony na cztery miesiące, a nie cztery tygodnie. Tydzień 1-4: system działa obok człowieka i musi zgadzać się z jego decyzjami w co najmniej 95% na reprezentatywnych przypadkach. Tydzień 5-8: wskaźnik nadpisań przez człowieka spada poniżej 5%. Tydzień 9-16: system obsługuje 80% przypadków samodzielnie, a 20% złożonych lub niepewnych przekazuje dalej. Do tego gotowość wycofania w godzinę, nie w tydzień. W studium szpitala faza obok człowieka wykryła 23 przypadki brzegowe, których pilotaż nie zauważył, a wskaźnik nadpisań spadł z 18% do 3%.

Do tego jedna decyzja organizacyjna: właściciel procesu musi być jedną osobą z imienia i nazwiska. Opis projektu, w którym decyzję zatwierdza pięć osób z trzech działów, mówi o sześciu tygodniach oczekiwania na zgodę, po których zatwierdza się dokładnie ten pomysł, który zespół przedstawił pierwszego dnia.

Automatyzacja piąta: liczba, która wygląda dobrze i ukrywa najgorszy kawałek

Tu nie ma awarii. Jest raport, który wygląda jak sukces. System obsługi klienta rozwiązuje automatycznie 80% zgłoszeń. Liczba jest prawdziwa i nikt jej nie podważa, bo nikt nie zadaje pytania, której 20% to były: spory rozliczeniowe, reklamacje i skargi.

Ten sam mechanizm zobaczył Klarna. W lutym 2024 firma ogłosiła, że jej asystent AI obsługuje około dwóch trzecich czatów w obsłudze klienta, robiąc robotę odpowiadającą około 700 agentom, a czas rozwiązania spadł z około 11 minut do poniżej dwóch. W maju 2025 prezes przyznał, że firma nadmiernie postawiła na koszt kosztem jakości i wróci do inwestowania w wsparcie ludzkie.

Dokładność 95% nie wystarczy, jeśli użytkownik nie odczuwa poprawy. W studium wdrożenia pada zdanie, że dokładność wynosi 95%, a projekt zabija percepcja.

Naprawa jest tania i działa, bo jest darmowa: spisz kryteria sukcesu przed startem, z liczbami, nie z deklaracjami. Na przykład skrócić czas obsługi z 15 do poniżej 5 minut dla co najmniej 70% przypadków, przy błędzie poniżej 3%. Taką definicję ocenia się potem przez jeden do trzech miesięcy równoległej pracy na realnym wolumenie. Liczby pisane po fakcie zawsze dopasowują się do wyniku, czasem w obie strony.

Te statystyki nie zgadzają się między sobą

Zanim ktoś użyje którejkolwiek z tych liczb w prezentacji dla zarządu, warto zobaczyć, że nie dotyczą tego samego. Najgłośniejszy jest wskaźnik 95% organizacji bez mierzalnego zwrotu z inwestycji w generatywną AI, przypisywany badaniu MIT Project NANDA z lipca 2025. Opis tego samego raportu różni się jednak między źródłami: jeden opis mówi o 52 wywiadach z kadrą i 153 ankietach, inny o około 150 wywiadach i kilkuset ankietach, i dodaje, że raport był wstępny i nie przeszedł recenzji. Wartości 95%, 87%, 80% i 30-50% opisują cztery różne mierniki: zwrot z inwestycji, wejście do produkcji, sukces projektu i powodzenie wdrożenia RPA.

Ten sam problem dotyczy datowania jednego wskaźnika: raport S&P Global z wartością 42% jest w jednym źródle przypisany edycji 2025, w innym pomiarowi z 2024 roku. Prognoza Gartnera, że ponad 40% projektów agentowych zostanie anulowanych do końca 2027 roku, dotyczy z kolei przyszłości, a nie przeszłości.

Najuczciwsza wersja tego, co naprawdę pokazują te badania, brzmi tak: kierunek dowodów jest spójny, wielkość efektu nie. Czy liczba to 40%, 60%, czy 95%, zależy od tego, co liczymy jako projekt, co jako porażkę i jak długo czekamy na pomiar. A jednak z całego zestawu liczb najmniej uciekająca jest ta z badania BCG: problemem w większości wypadków nie jest model. Jeśli przyczyny leżą w zakresie, danych, pomiarach i odpowiedzialności, to leżą w zasięgu rąk firmy, a nie dostawcy.

Co sprawdzić przed pierwszym wdrożeniem

Poniższa lista wynika wprost z powyższych przypadków. Większość z punktów kosztuje godzinę spotkania, a oszczędza kwartał pracy.

• Właściciel procesu: jedna osoba z imienia i nazwiska, nie komitet. Zapis decyzji, kto o czym decyduje.
• Baseline przed startem: ile godzin realnie zjada ten proces dziś. Wzór jest prosty - osoby × minuty dziennie × dni robocze ÷ 60, potem godziny × koszt godziny. Bez liczby wyjściowej nie policzysz efektu; opisałem to szerzej przy rachunku ROI automatyzacji.
• Wybór zadania: czy proces jest powtarzalny, mierzalny w godzinach i ma jedno jasne wejście oraz wyjście. Takie zadania warto automatyzować w pierwszej kolejności, a mapa procesów porządkuje to w jeden wieczór.
• Zestaw testowy: 50 do 100 realnych przypadków z poprawnym wynikiem, zrobionych przed produkcją, nie po niej.
• Kryteria sukcesu z liczbami, spisane przed startem, mierzone przez jeden do trzech miesięcy równoległej pracy.
• Monitoring jakości, nie wolumenu, oraz alarm reagujący na spadek wyniku o kilka punktów.
• Budżet obejmujący co najmniej 24 miesiące utrzymania po uruchomieniu, nie tylko wdrożenie.
• Granice uprawnień zapisane w prompcie, w narzędziu i w orkiestracji, plus punkt kontrolny człowieka tam, gdzie decyzja kosztuje pieniądze.
• Gotowość wycofania w godzinę, nie w tydzień.

Jeżeli w firmie jest kilka procesów do rozważenia, użyj macierzy 20 procesów z czasem i ryzykiem, żeby wybrać jeden, a nie pięć naraz. Same wdrożenia na prowadzącym n8n zaczynają się od jednego przepływu, który działa i który da się zmierzyć.

Ostatnie pytanie przed budżetem

Nie ma znaczenia, jakiej technologii użyjecie. Ma znaczenie jedno pytanie: gdyby to wdrożenie przestało działać jutro po cichu, ile czasu zajęłoby zauważenie? Jeśli odpowiedź brzmi tygodnie, zacznijcie od monitoringu, a nie od systemu. Jeśli zespół potrafi wskazać 50 przypadków, na które patrzy i które potrafi porównać z poprawnym wynikiem, to projekt ma szansę. W przeciwnym razie kupujecie liczbę na slajdzie.

Jeśli chcecie przejść tę listę na własnych procesach, napiszcie do mnie albo umówmy bezpłatną rozmowę. Odpowiadam zwykle tego samego dnia.