Automatyzacja miała zdjąć robotę z głowy. W poniedziałek rano sprawdzasz, czy nocny scenariusz przeszedł, i okazuje się, że nie przeszedł. Dostawca zmienił coś w API i integracja stanęła o 3:12. Piszesz do człowieka, który to stawiał. Okazuje się, że zmienił pracę w marcu.
To jest moment, w którym automatyzacja przestaje być oszczędnością i zaczyna być zobowiązaniem. Nie dlatego, że narzędzie zawiodło — narzędzie zrobiło dokładnie to, co mu kazano. Zmieniło się coś obok, a system nie miał jak tego zauważyć.
Brzmi znajomo? To nie jest awaria, tylko normalny koszt posiadania automatyzacji, o którym nikt nie mówi przy zakupie. Bo automatyzacja nie usuwa pracy — zamienia pracę wykonywaną na pracę utrzymywaną. Cała gra polega na tym, czy ta zamiana ci się opłaca.
Co znajdziesz w artykule?
- Dlaczego automatyzacja nie usuwa pracy, tylko zamienia wykonywaną na utrzymywaną — i przy jakim procesie ta zamiana wychodzi na minus
- Co się dzieje, gdy zautomatyzujesz proces, którego nikt nie umie wytłumaczyć, i kto pełnił rolę kontroli jakości, zanim wszedł bot
- Skąd wzięła się liczba „siedemdziesiąt procent wdrożeń zmian kończy się porażką", dlaczego trzeba ją odwołać i co pokazują badania w jej miejsce
- Cztery warstwy wdrożenia w kolejności, której nie da się przeskoczyć, oraz pięć pytań do zadania przed wydaniem pierwszej złotówki
- Jak zaplanować wyłączenie automatyzacji — zanim ją zbudujesz, a nie w dniu, w którym przestanie się opłacać
Automatyzacja nie usuwa pracy, tylko zamienia ją na inną
Większość firm liczy, ile godzin automatyzacja oszczędza. Prawie nikt nie liczy, ile godzin będzie kosztować jej utrzymanie przez najbliższe trzy lata.
Zanim policzysz oszczędność, policz drugą stronę tego równania, bo obie strony istnieją niezależnie od tego, czy ktoś je zapisał. Ręczny proces kosztuje cię godziny, ale jest elastyczny. Kiedy coś się zmienia, człowiek to zauważa i sam się dostosowuje, zwykle nie mówiąc o tym nikomu. Zautomatyzowany proces kosztuje mniej godzin, ale jest sztywny: sam z siebie nie zauważa niczego i o każdej zmianie trzeba mu powiedzieć.
Ta zamiana bywa świetna i wtedy nie ma o czym dyskutować. Jeśli proces jest stabilny, powtarzalny i dobrze opisany, oddajesz nudną robotę i płacisz za utrzymanie ułamek tego, co oszczędzasz. Jeśli proces zmienia się co kwartał, oddajesz nudną robotę i dostajesz w zamian dyżur pod telefonem.
| Proces ręczny | Proces zautomatyzowany | |
|---|---|---|
| Koszt | Zmienny — tyle godzin, ile wykonań | Stały — utrzymanie płacisz nawet w miesiącu bez wykonań |
| Reakcja na zmianę | Człowiek zauważa sam i się dostosowuje, zwykle nikomu o tym nie mówiąc | Nie zauważa niczego. O każdej zmianie trzeba mu powiedzieć |
| Kontrola jakości | Wbudowana mimochodem: widać, że liczba jest dziwna, a plik przyszedł pusty | Żadna, dopóki jej nie dopiszesz. Bot nie wie, czego się spodziewać |
| Zmiana zasad | W środę na spotkaniu | Przebudowa, testy, wdrożenie |
| Kiedy wygrywa | Proces zmienia się co kwartał | Proces stabilny, powtarzalny i opisany |
Pułapka nie polega więc na tym, że „automatyzacja nie działa". Polega na tym, że zamiana kosztu zmiennego na stały jest jednokierunkowa. Ręczny proces możesz zmienić w środę na spotkaniu, a zautomatyzowany trzeba przebudować, przetestować i wdrożyć. Im więcej w niego włożyłeś, tym trudniej będzie ci go wyłączyć.
📖 Ze słownika Noraline Dług operacyjny — nakładające się warstwy prowizorycznych rozwiązań, obejść i ręcznych procesów, które firma akumuluje latami. Jak dług techniczny w kodzie, ale dotyczy całej organizacji. Każda nowa automatyzacja zbudowana na długu operacyjnym dziedziczy jego problemy. Z tą różnicą, że dług jest teraz zapisany w konfiguracji, a nie w czyjejś głowie.
Utrwalasz proces, którego nikt nie umie wytłumaczyć
Jest piątek. Szef mówi: „zautomatyzujmy ten raport, bo Kasia siedzi nad nim pół dnia w tygodniu". Świetnie. Tylko że nikt nie wie, dlaczego raport wygląda tak, a nie inaczej.
Kasia dodała trzy kolumny, bo kiedyś ktoś poprosił, a dwóch z nich nikt nie czyta od dwóch lat. Dane źródłowe są ręcznie kopiowane z maila, bo tak było, kiedy przychodziła do firmy. Automatyzujesz to i masz bota, który co tydzień generuje bezużyteczny raport z błędnymi danymi. Tylko szybciej i bez świadka, który mógłby zauważyć, że coś tu nie gra.
Kasia była przy tym świadkiem, choć nikt jej tej roli nigdy nie przypisał. Człowiek wykonujący proces ręcznie mimochodem robi kontrolę jakości: widzi, że liczba jest dziwna, że plik przyszedł pusty, że w tym miesiącu czegoś brakuje. Bot tego nie robi, bo nie ma pojęcia, czego się spodziewać.
To dlatego twardym warunkiem jest zmapowanie procesu przed dotknięciem jakiegokolwiek narzędzia. Dosłownie: kartka, flamaster, każdy krok osobno. Kto robi co, skąd bierze dane, komu przekazuje wynik, co robi, gdy dane nie przyjdą. Prawie zawsze znajdziesz przy tym dwa kroki, które nie powinny istnieć. To najtańsza optymalizacja, jaką da się zrobić, bo nie wymaga żadnej licencji.
Że nie jest to problem marginalny, widać w danych zebranych na dużej próbie. Deloitte w badaniu na 479 kadrze zarządzającej z 35 krajów wskazuje rozdrobnienie procesów jako główną barierę w skalowaniu automatyzacji. Przed brakiem gotowości IT i przed oporem ludzi. W tym samym badaniu 41% organizacji przyznaje, że nie ma strategii automatyzacji na poziomie firmy, a 22% nie ma jasnej wizji, po co to robi.
To nie jest lista problemów technicznych, tylko lista problemów z porządkiem.
Koszt utrzymania, którego nie ma w ofercie
Robotic Process Automation obiecywało, że bot zrobi wszystko za ciebie, klikając w te same przyciski co człowiek. Mechanizm jest właśnie dlatego kruchy: bot nie rozumie aplikacji, tylko zapamiętuje, gdzie leżą przyciski. Zmienia się układ ekranu i workflow pada, choć merytorycznie nic się nie stało.
Skalę tego widać w globalnym badaniu Deloitte poświęconym RPA. Ponad połowa firm zaczęła wdrażać roboty, ale tylko 3% doszło do skali powyżej pięćdziesięciu botów — rok później było to 4%. Warto powiedzieć wprost, co ta liczba znaczy, a czego nie. To nie jest wskaźnik porażek, tylko miara tego, jak niewiele firm dociąga automatyzację dalej niż do kilku procesów. Reszta zatrzymuje się nie dlatego, że boty nie działają, tylko dlatego, że koszt pilnowania kolejnych rośnie szybciej niż oszczędność.
Nie chodzi o to, żeby nie używać RPA ani żadnego innego narzędzia. Chodzi o to, żeby przy każdym wdrożeniu zapytać o rzecz, której nie ma w ofercie. Kto to naprawi we wtorek o siódmej rano i ile to będzie kosztowało rocznie. Bot nie naprawi procesu — powieli to, czego go nauczysz, razem z błędami.
Ten sam mechanizm opisywałem przy okazji tego, jak technologia przejmuje żmudne i powtarzalne czynności. Automatyzacja nie jest jednorazowym wdrożeniem, tylko ciągłą opieką, którą ktoś musi mieć wpisaną w zakres obowiązków.
Ta sama pułapka na poziomie portfela narzędzi
Pojedyncza automatyzacja to jedna rzecz do utrzymania. Portfel narzędzi to ta sama arytmetyka, tylko pomnożona — i dlatego rozrost SaaS-ów jest wersją tej samej pułapki, a nie osobnym tematem.
Według raportu BetterCloud State of SaaS przeciętna organizacja korzysta ze 106 aplikacji SaaS. Liczba brzmi absurdalnie, dopóki nie sprawdzi się, co obejmuje: nie narzędzia, których używa jedna osoba, tylko cały stos firmy razem z subskrypcjami wykupionymi przez pojedyncze zespoły poza działem IT. Nikt tego nie widzi w całości i to jest właśnie sedno. Każda z tych pozycji ma własny login, własne uprawnienia i własne miejsce, w którym coś siedzi. Każda ma też własny moment, w którym dostawca zmieni cennik albo wyłączy funkcję, na której opierasz proces.
Koszt nie jest tylko finansowy. Badanie Lokalise na tysiącu osób pracujących przy komputerze pokazuje, że przeciętna osoba przełącza się między narzędziami 33 razy dziennie i traci na tym średnio 51 minut tygodniowo. Średnia wygląda znośnie, ale ogon rozkładu już nie. W tym samym badaniu 22% osób traci na przełączaniu ponad dwie godziny w tygodniu, czyli ponad sto godzin rocznie.
Zadaj więc pytanie w drugą stronę, niż zwykle się je zadaje. Nie „jakiego narzędzia mi brakuje", tylko „które z tych, które mam, faktycznie zamyka proces od początku do końca". Odpowiedź bywa niewygodna, bo zwykle oznacza, że problemem nie jest brak funkcji, tylko brak decyzji, gdzie dana rzecz ma mieszkać.
Dlaczego ludzie nie chcą kolejnego systemu
„Siedemdziesiąt procent wdrożeń zmian kończy się porażką przez opór pracowników". Sam to powtarzałem. Ta liczba nie pochodzi z żadnego badania — i to jest dobra wiadomość.
W tym miejscu zwykle pada liczba, którą sam wcześniej powtarzałem: opór pracowników ma odpowiadać za 70% nieudanych wdrożeń zmian. Sprawdziłem ją i trzeba ją odwołać, bo nie pochodzi z żadnego badania.
Trop prowadzi do książek z lat dziewięćdziesiątych i dwutysięcznych, gdzie pada jako szacunek autorów, bez próby, metody i danych. Przegląd pięciu niezależnych publikacji powtarzających ten wskaźnik, opublikowany w Journal of Change Management, nie znalazł pod żadną z nich empirycznego pokrycia. Firmie McKinsey, której tę siedemdziesiątkę najczęściej się przypisuje, wychodzi w cyklicznych badaniach transformacji coś innego: pełnym sukcesem kończy się od 20% do 26% z nich, zależnie od rocznika badania.
Te dwie liczby mówią jednak o czymś innym i warto to rozdzielić. „Niepełny sukces" nie znaczy „porażka", a żadne z tych badań nie przypisuje przyczyny oporowi pracowników. Dostajesz więc odsetek bez przyczyny i przyczynę bez odsetka, sklejone w jedną liczbę, którą potem cytuje się na spotkaniach.
To jest dobra wiadomość i warto ją wyciągnąć na wierzch, bo straszenie siedemdziesiątką prowadzi do fatalistycznego wniosku, że i tak się nie uda. Nie o to chodzi. Chodzi o to, że opór ludzi jest realny, ale ma konkretne, nazywalne przyczyny — i żadna z nich nie brzmi „ludzie nie lubią zmian".
Pamiętasz Martę z księgowości, która dalej wysyła Excele mailem? Nie jest oporna na zmiany, tylko zmęczona. Marta nauczyła się trzech systemów w dwa lata, każdy miał być tym ostatnim, a teraz słyszy o czwartym i zakłada, że za rok będzie piąty. Statystycznie ma rację, a jej opór jest racjonalną reakcją na koszt, który już poniosła.
Wniosek jest niewygodny dla harmonogramu. Jeśli automatyzacja ma przetrwać, ktoś musi Marcie powiedzieć nie tylko, co ma klikać, ale też co przestaje robić. Zmiana, która tylko dokłada, zawsze przegra z nawykiem, który już działa.
Warto przy tym rozpoznać, z czym dokładnie masz do czynienia, bo zmęczenie i zdystansowanie wymagają różnych reakcji. Pierwsze mija po odciążeniu, drugie już nie — a wygląda niemal tak samo z zewnątrz. Test wypalenia zawodowego mierzy oba wymiary osobno: wyczerpanie i utratę zaangażowania. Jeśli u kogoś w zespole wysoko wychodzi ten drugi, kolejne wdrożenie nie ma prawa się przyjąć, niezależnie od tego, jak dobre jest narzędzie.
Cztery warstwy, których nie da się przeskoczyć
20 procesów w firmie, które możesz oddać automatyzacji
Zanim wybierzesz, co automatyzować, zobacz konkretną listę 20 procesów, które inne firmy już bezpiecznie oddały automatyzacji.
Pobierz za darmo →Firmy, które wpadają w tę pułapkę, prawie zawsze zaczynają od góry: kupują narzędzie, a potem szukają, do czego by je przyłożyć. Kolejność, która nie generuje długu, jest dokładnie odwrotna.
Warstwa 1: proces. Zmapuj go, uprość i usuń kroki, których nikt nie umie uzasadnić. Proces zepsuty ręcznie będzie zepsuty automatycznie, tylko szybciej i bez świadka.
Warstwa 2: ludzie. Kto z tego korzysta, kto to utrzyma i kto reaguje, gdy się zepsuje. Trzy pytania, trzy imiona — jeśli któreś zostaje bez odpowiedzi, właśnie znalazłeś przyszłą awarię.
Warstwa 3: narzędzie. Dopiero teraz i dopasowane do skali problemu, a nie do skali ambicji. Jak trafnie zauważa Implemo: „Kiedy właściciel pięcioosobowej firmy kupuje system zaprojektowany dla korporacji, kończy się to tym, że nikt z niego nie korzysta".
Warstwa 4: automatyzacja. Jeden proces, testowany, z feedbackiem, rozbudowywany dopiero po tym, jak przeżyje miesiąc bez interwencji.
Pięć pytań, zanim wydasz złotówkę
Pięć pytań, które rozstrzygają, czy zamieniasz pracę wykonywaną na tańszą utrzymywaną — czy właśnie kupujesz sobie dyżur. Wszystkie pięć rozpisuję niżej — ta zapowiedź obejmuje całą tę sekcję, nie pojedynczy akapit.
Każde z tych pytań sprawdza jedną rzecz: czy ta zamiana ci się opłaci. Odpowiadaj szczerze, bo jedynym odbiorcą jest tu twój przyszły wtorek.
Czy umiem opisać ten proces w trzech zdaniach? Jeśli nie, jest za skomplikowany na automatyzację i najpierw wymaga uproszczenia. Automatyzacja niczego nie uprości za ciebie — utrwali stan, w jakim go zastanie.
Co się stanie, gdy to padnie? Bo padnie, i to zwykle w tygodniu, w którym masz najmniej czasu. Musisz wiedzieć, kto zauważy, po czym pozna i jak wróci do trybu ręcznego, zanim narobi się szkód.
Kto jest właścicielem? Nie „zespół" i nie „wszyscy", tylko jedna osoba z imieniem i nazwiskiem. Musi rozumieć i proces, i automatyzację. A jeśli odejdzie, jej następca dostaje to w zakresie obowiązków, a nie w spadku po fakcie.
Czy ten proces jest stabilny? Proces, który zmienia się co kwartał, będzie kosztował w utrzymaniu więcej, niż oszczędza. To jest dokładnie ten moment, w którym zamiana kosztu zmiennego na stały wychodzi na minus.
Czy zmierzyłem stan „przed"? Samo „zaoszczędzimy czas" nie jest metryką. Ile godzin, czyich, ile błędów, jak często — bez tej bazy nie odróżnisz potem poprawy od wrażenia poprawy.
Wycofanie się jest częścią planu, nie porażką
Z tej całej listy najtrudniejszy jest ostatni krok, o którym prawie nikt nie mówi na etapie wdrożenia. Automatyzację trzeba umieć wyłączyć, i to zaplanować wcześniej niż w dniu, w którym przestaje się opłacać.
Po miesiącu porównaj dane ze stanem „przed" i policz obie strony równania: ile godzin zeszło z procesu i ile godzin poszło na jego pilnowanie. Jeśli bilans nie wychodzi, wycofaj się bez dyskusji. Nie rozbudowuj, nie dokładaj kolejnego scenariusza, który miałby załatać poprzedni — po prostu wróć do trybu ręcznego i zapisz, czego się dowiedziałeś.
Ten ruch jest trudny nie z powodów technicznych, tylko psychologicznych, bo trzeba przyznać, że włożona praca poszła w koszty. To jest błąd utopionych kosztów w czystej postaci: utrzymujesz automatyzację, bo ją zbudowałeś, a nie dlatego, że coś ci daje. Tak samo działa tu syndrom Zosi Samosi. Jeśli jedyną osobą, która umie odpalić ten scenariusz ręcznie, jesteś ty, to nie zbudowałeś systemu, tylko kolejne wąskie gardło z własnym nazwiskiem.
Automatyzacja dobrego procesu jest dźwignią. Automatyzacja procesu, którego nikt nie rozumie, to ta sama praca przeniesiona z kalendarza do konfiguracji. Tam łatwiej ją przeoczyć i trudniej naprawić.
Więc zanim odpalisz kolejny scenariusz, odpowiedz sobie na jedno pytanie: czy wiesz, ile godzin miesięcznie kosztuje cię utrzymanie tych, które już masz? Jeśli nie wiesz — masz odpowiedź, od czego zacząć.
Sprawdźmy, co da się zdjąć z Twojej głowy
Czujesz, że Twoje automatyzacje generują więcej problemów niż rozwiązują? Przejdziemy przez Twoje procesy i znajdziemy te, które naprawdę warto zautomatyzować.
Napisz do mnie →Najczęściej zadawane pytania
Wtedy, gdy zamiana pracy wykonywanej na pracę utrzymywaną wychodzi na minus. Ręczny proces kosztuje godziny, ale jest elastyczny — człowiek sam zauważa zmianę i się dostosowuje. Zautomatyzowany kosztuje mniej godzin, ale niczego nie zauważa i trzeba mu każdą zmianę wprowadzić ręcznie. Przy procesie stabilnym i powtarzalnym ta zamiana się opłaca. Przy procesie zmieniającym się co kwartał kupujesz sobie stały dyżur zamiast oszczędności.
Najczęściej nie z powodu technologii. W badaniu Deloitte na 479 osobach z kadry zarządzającej z 35 krajów główną barierą w skalowaniu automatyzacji jest rozdrobnienie procesów — przed brakiem gotowości IT i oporem ludzi. W tym samym badaniu 41% organizacji nie ma strategii automatyzacji na poziomie firmy, a 22% nie ma jasnej wizji, po co ją wdraża. To są problemy z porządkiem, nie z narzędziami.
Nie. Ta liczba krąży od lat, ale nie pochodzi z żadnego badania — jej ślad prowadzi do książek z lat dziewięćdziesiątych i dwutysięcznych, gdzie pada jako szacunek autorów, bez próby i metody. Przegląd pięciu niezależnych publikacji powtarzających ten wskaźnik, opublikowany w Journal of Change Management, nie znalazł pod żadną z nich empirycznego pokrycia. Firmie McKinsey, której tę liczbę najczęściej się przypisuje, w cyklicznych badaniach transformacji wychodzi co innego: pełnym sukcesem kończy się od 20% do 26% z nich, zależnie od rocznika badania. To zresztą mówi o czymś innym — „niepełny sukces" nie znaczy „porażka", a żadne z tych badań nie przypisuje przyczyny oporowi pracowników.
Od zmapowania jednego procesu na kartce: kto robi co, skąd bierze dane, komu przekazuje wynik i co robi, gdy dane nie przyjdą. Prawie zawsze znajdziesz przy tym dwa kroki, których nikt nie umie uzasadnić — ich usunięcie nie wymaga żadnej licencji. Dopiero potem: kto z tego korzysta i kto to utrzyma, potem wybór narzędzia dopasowanego do skali problemu, a na końcu sama automatyzacja jednego procesu.
To nakładające się warstwy prowizorycznych rozwiązań, obejść i ręcznych procesów, które firma akumuluje latami. Działa jak dług techniczny w kodzie, tylko dotyczy całej organizacji. Każda automatyzacja zbudowana na długu operacyjnym dziedziczy jego problemy, z tą różnicą, że po wdrożeniu dług jest zapisany w konfiguracji, a nie w czyjejś głowie — czyli trudniej go zauważyć i trudniej zmienić.
Liczby krążące po raportach branżowych mówią o dziesiątkach aplikacji SaaS na organizację, i warto od razu powiedzieć, co one liczą, bo brzmią absurdalnie: nie narzędzia używane przez jedną osobę, tylko cały stos firmy razem z subskrypcjami wykupionymi przez pojedyncze zespoły poza działem IT. Problemem nie jest sama liczba, tylko to, że każde narzędzie jest osobną rzeczą do utrzymania. Badanie Lokalise na tysiącu osób pracujących przy komputerze pokazuje 33 przełączenia między narzędziami dziennie i średnio 51 minut tygodniowo straconych na samą nawigację, a 22% badanych traci ponad dwie godziny. Właściwe pytanie brzmi nie „czego mi brakuje", tylko „które z tych narzędzi zamyka proces od początku do końca".
Gdy nie potrafisz opisać go w trzech zdaniach, bo jest zbyt zagmatwany i najpierw wymaga uproszczenia. Gdy zmienia się częściej niż co kwartał, bo koszt utrzymania przewyższy oszczędność. Gdy nikt nie jest jego właścicielem z imienia i nazwiska, bo nikt nie zauważy awarii. Gdy nie masz zmierzonego stanu „przed", bo nie odróżnisz potem poprawy od wrażenia poprawy. I gdy nie umiesz opisać, jak wrócić do trybu ręcznego.
Wyłączyć ją. Po miesiącu porównaj dane ze stanem „przed" i policz obie strony: ile godzin zeszło z procesu i ile poszło na jego pilnowanie. Jeśli bilans nie wychodzi, wróć do trybu ręcznego zamiast dokładać kolejny scenariusz łatający poprzedni. Najczęstszy powód utrzymywania nieopłacalnej automatyzacji to błąd utopionych kosztów — trzymasz ją, bo ją zbudowałeś, a nie dlatego, że coś ci daje.
Szymon Mojsak
Ekspert automatyzacji procesów biznesowych i współwłaściciel RCPonline — systemu rejestracji czasu pracy.
Teoria zastosowana w praktyce — treści opieram na własnych doświadczeniach zdobytych przy wdrożeniach i w relacjach międzyludzkich.
Poszerzam horyzonty — nieustannie rozwijam wiedzę z zakresu marketingu, psychologii i IT.
Zamieniam twórczy chaos w kierunek — najpierw pytanie „po co”, dopiero potem „jak”. Pomagam zrozumieć procesy, by je usprawnić.
Ten materiał powstał z udziałem AI
Narzędzia AI — wspierały research, redakcję tekstu i przygotowanie ilustracji.
Autor — wybiera temat, pisze pierwszą wersję i redaguje całość przed publikacją. Doświadczenia, oceny i punkt widzenia w tekście są jego własne.
Ładowanie komentarzy...