Jeśli jesteś CTO, CIO albo Head of IT, prędzej czy później dostajesz to zadanie: „zautomatyzujmy to”, z budżetem, terminem i założeniem, że pierwszy projekt RPA po prostu zadziała.
Tymczasem wiele ważnych decyzji zapada dużo wcześniej niż zaczyna się właściwe wdrożenie. I to one, a nie sama technologia, najczęściej przesądzają o wyniku.
Który proces wybrać? Czy automatyzować go w obecnej formie? Kto zna jego rzeczywisty przebieg? Co zrobić z wyjątkami? I wreszcie: po czym poznamy, że projekt rzeczywiście coś zmienił?
To właśnie na tym etapie można zwiększyć szanse powodzenia projektu albo nieświadomie zbudować automatyzację wokół problemu, który należało najpierw rozwiązać.
Dlatego zanim ruszysz z pierwszym wdrożeniem, warto poznać pięć paradoksów, które najczęściej decydują o tym, po której stronie tej statystyki się znajdziesz.
I uprzedzamy: „Ten proces mamy od dawna poukładany” zwykle jest początkiem bardzo ciekawej rozmowy.
Paradoks 1. Im szybciej chcesz automatyzować, tym bardziej trzeba zwolnić
Coraz więcej ręcznego przepisywania danych, Excela, maili i wyjątków kusi, żeby jak najszybciej wdrożyć rozwiązanie, które zdejmie tę pracę z ludzi.
Paradoks polega na tym, że właśnie w tym momencie wiele projektów zaczyna zmierzać w niewłaściwym kierunku.
Automatyzacja nie porządkuje procesu. Jeżeli opiera się on na nieformalnych obejściach, ręcznych kontrolach i wiedzy kilku osób, technologia jedynie przeniesie tę złożoność do nowego rozwiązania. Tylko szybciej i w większej skali.
Dlaczego niektóre projekty RPA kończą się niepowodzeniem?
Raport EY i Microsoft „Digital Directions: A Perspective on the Impact of Digital Technologies” (2020) potwierdza to twardą liczbą: do 40% projektów RPA kończy się niepowodzeniem.
Wśród najczęstszych przyczyn autorzy wymieniają m.in.:
- prowadzenie projektu przez IT zamiast przez biznes;
- kierowanie automatyzacji na niewłaściwe procesy;
- oraz traktowanie robotyzacji jako serii pojedynczych automatyzacji, a nie elementu szerszego programu zmiany.
Przykład z projektu PIRXON: robot, który miał uruchamiać się częściej
W jednym z projektów robot obsługujący zamówienia uruchamiał się dwa razy dziennie – rano i po południu – i za każdym razem przetwarzał zamówienia, które napłynęły od poprzedniego uruchomienia. Klient chciał pójść o krok dalej: zamiast dwóch uruchomień dziennie, robot miał pracować przez całą dobę, sprawdzając i przetwarzając zamówienia dużo częściej. Sama logika procesu się nie zmieniła – zmienił się harmonogram, według którego uruchamiał się robot.
Po zwiększeniu częstotliwości okazało się, że systemy, z którymi łączył się robot, nie są przystosowane do tak częstej pracy. W części okien czasowych trwały prace serwisowe, w innych serwer był obciążony innymi procesami. Założenie, że harmonogram sprawdzony przy dwóch uruchomieniach dziennie automatycznie wytrzyma kilkadziesiąt uruchomień w ciągu doby, nie zostało wcześniej zweryfikowane. Dopiero analiza tych ograniczeń pozwoliła dobrać harmonogram realnie dopasowany do wydajności systemów klienta.
Ten przypadek dobrze pokazuje, na czym polega paradoks szybkości: chęć szybkiego zwiększenia skali automatyzacji może ujawnić ograniczenia, których nikt wcześniej nie testował. To właśnie ich sprawdzenie, a nie tempo wdrożenia, decyduje o tym, czy rozwiązanie faktycznie zadziała.
Paradoks 2. Najbardziej uciążliwy proces rzadko jest najlepszym kandydatem do automatyzacji
Spora część organizacji rozpoczyna od procesu, który najbardziej boli.
Pracownicy poświęcają na niego najwięcej czasu. Generuje najwięcej wyjątków, ręcznych poprawek i frustracji. Najczęściej wraca jako problem podczas spotkań operacyjnych. Wydaje się więc oczywiste, że właśnie tam należy rozpocząć projekt automatyzacji.
Paradoks polega na tym, że najbardziej uciążliwy proces jest często również najbardziej skomplikowany.
Przez lata taki proces obrósł wyjątkami, dodatkowymi kontrolami, własnymi arkuszami Excel i nieformalnymi zasadami. Każda kolejna zmiana, która miała rozwiązać pojedynczy problem, w rezultacie skomplikowała go. Proces staje się coraz bardziej złożony, a przez to trudniejszy do zrozumienia i optymalizacji.
Automatyzacja takiego procesu rzadko wyeliminuje chaos. Najczęściej przeniesie go do nowego rozwiązania.
Co rekomenduje EY
Raport EY i Microsoft „Get Ready for Robots” (2016) wskazuje to wprost: procesy najbardziej uciążliwe dla pracowników są często wybierane właśnie dlatego, że są najbardziej bolesne, a nie dlatego, że dają największy zwrot z inwestycji. Autorzy rekomendują, by pierwsze projekty obejmowały procesy o niskiej lub średniej złożoności: powtarzalne i pozwalające szybko pokazać wymierny efekt.
Przykład z projektu PIRXON: planowanie produkcji
W jednym z projektów jako pierwszy do robotyzacji klient wskazał najbardziej uciążliwy dla niego proces planowania produkcji. Na etapie analizy reguły wydawały się stosunkowo proste: określony towar oznaczał konkretną ilość, sposób pakowania i czas potrzebny na przezbrojenie. Dopiero podczas testów zaczęły pojawiać się kolejne wyjątki. Dla jednego indeksu obowiązywała niestandardowa liczba sztuk na palecie, zamówienia konkretnego klienta miały pierwszeństwo przed standardowymi regułami planowania, a przy innym produkcie niestandardowy uchwyt wydłużał czas przezbrojenia.
Proces, który w oczach klienta wyglądał na dobrego kandydata do automatyzacji, wraz z kolejnymi wyjątkami okazywał się znacznie bardziej złożony niż zakładano na starcie. Wspólnie z klientem podjęliśmy decyzję, by wstrzymać robotyzację w dotychczasowym kształcie, dopóki proces nie zostanie uproszczony i ujednolicony. To właśnie dlatego uciążliwość procesu nie powinna być jedynym kryterium jego wyboru do wdrożenia.
Przed rozpoczęciem projektu warto zadać sobie nie tylko pytanie: „Który proces najbardziej nas boli?”, ale również: „Który proces przyniesie największą wartość biznesową przy rozsądnym poziomie złożoności?”.
Pierwszy projekt automatyzacji rzadko jest najważniejszy dlatego, że jest pierwszy. Jest ważny, ponieważ staje się fundamentem kolejnych wdrożeń lub przykładem inwestycji, która nie spełniła oczekiwań.
Paradoks 3. Proces, który wszyscy znają, często nie istnieje
W wielu firmach panuje przekonanie, że proces jest dobrze opisany.
Dopiero obserwacja codziennej pracy pokazuje, że w rzeczywistości wygląda on zgoła inaczej. Diagram nie pokazuje dodatkowego Excela, w którym pracownik sprawdza poprawność danych. Nie pokazuje wiadomości na Teamsie z pytaniem, jak obsłużyć nietypowy przypadek. Nie pokazuje wykonanego telefonu do kolegi z innego działu ani listy wyjątków zapisanej w prywatnym notatniku.
To właśnie dzięki takim obserwacjom podczas Odkrywania Procesów możemy zobaczyć różnicę między tym, co opisane w dokumentacji, a tym, jak proces faktycznie wygląda.
Podobny wniosek płynie z materiałów EY dotyczących process miningu: zanim organizacja zdecyduje, co automatyzować, co standaryzować, a co jedynie uprościć, powinna najpierw zobaczyć, jak proces faktycznie przebiega – nie tylko jak jest opisany na papierze.
Przykład z projektu PIRXON: Excel, którego nikt już nie rozumiał
W jednej z firm istotnym elementem procesu był dashboard w Excelu przygotowany przez pracownika, który z czasem odszedł z organizacji. Dopiero wtedy okazało się, jak duża część wiedzy o działaniu rozwiązania była związana właśnie z tą osobą. Pracownicy firmy próbowali odtworzyć logikę pozostawionego pliku, a zjawisko to przeanalizowali również konsultanci PIRXON podczas Odkrywania Procesów. Wiedza potrzebna do odtworzenia sposobu działania arkusza była już wtedy nieodwracalnie utracona, a firma straciła funkcjonalność, którą wcześniej zapewniał.
Ten przypadek pokazuje, jak łatwo organizacja może uzależnić się od wiedzy jednej osoby. Dopóki rozwiązanie działa, taka zależność może pozostawać niezauważona. Problem pojawia się wtedy, gdy jego autor odchodzi, a wiedza potrzebna do utrzymania lub odtworzenia rozwiązania nie została udokumentowana.
To bardzo dobrze współgra z obserwacją, która przewija się przez cały nasz ebook: proces formalnie jest w systemie, praktycznie działa obok niego. Jeżeli automatyzacja ma przynieść trwały efekt, musi obejmować ten rzeczywisty proces. Nie ten zapisany w dokumentacji.
Paradoks 4. Można zautomatyzować czynność i nie zautomatyzować procesu
Automatyzacja często zaczyna się od najbardziej widocznej czynności manualnej: przepisywania danych, generowania dokumentu, pobierania raportu czy wprowadzania informacji do systemu. To naturalny punkt wyjścia, bo właśnie tam najłatwiej zauważyć czas, który można zaoszczędzić.
Tyle że pojedyncza czynność jest zwykle tylko fragmentem większego procesu. Przed nią ktoś może przygotowywać lub weryfikować dane, a po jej wykonaniu sprawdzać wynik, obsługiwać wyjątki albo przenosić informacje do kolejnego systemu. Jeśli automatyzacja obejmie tylko jeden z tych etapów, może działać poprawnie, ale jej wpływ na cały proces będzie ograniczony.
Dlatego przed określeniem zakresu projektu warto spojrzeć na proces od początku do końca. Sprawdzić, skąd pochodzą dane, kto i w jaki sposób je przygotowuje, jakie działania odbywają się poza głównym systemem, gdzie pojawiają się wyjątki i co dzieje się z wynikiem pracy po wykonaniu automatyzowanej czynności.
Nie chodzi przy tym o to, żeby każdy projekt od razu obejmował cały proces. Czasem automatyzacja jednego etapu jest uzasadniona i przynosi konkretną wartość. Ważne, żeby była świadomą decyzją o zakresie projektu, a nie efektem tego, że pozostała część procesu nie została wcześniej zauważona.
Dlatego sukcesu automatyzacji nie warto mierzyć wyłącznie tym, czy robot wykonuje powierzone mu zadanie. Ważniejsze pytanie brzmi: co dzięki temu zmieniło się w całym procesie?
Paradoks 5. Najlepsze projekty automatyzacji zaczynają się od pytań, nie od odpowiedzi
Zacznij od dobrych pytań i zrozumienia biznesu
Po przeczytaniu poprzednich paradoksów można odnieść wrażenie, że skuteczna automatyzacja wymaga skomplikowanych analiz, rozbudowanych metodyk i wielomiesięcznych przygotowań. W praktyce początek wygląda znacznie prościej.
Udane projekty to takie, w których zaczyna się rozmowę od dobrze zadanych pytań i zrozumienia konkretnego biznesu.
Pytania, które warto zadać przed automatyzacją:
- Jak ten proces wygląda dzisiaj?
- Gdzie pracownicy wykonują pracę poza systemami?
- Które wyjątki przestały być wyjątkami?
- Które czynności istnieją wyłącznie dlatego, że „zawsze tak było”?
- Które założenia projektu są dziś tylko deklaracją, a nie zweryfikowanym faktem?
- Dlaczego tak to robicie?
Przykład z projektu PIRXON: obietnica, która nie została spełniona
W jednym z projektów dane wejściowe docierały w bardzo różnych formatach: jako skany dokumentów, pliki Excel, PDF-y i dokumenty Word. Podczas rozmów o robotyzacji zespół PIRXON wprost zapytał, czy dane da się ujednolicić i sprowadzić do formy cyfrowej – bez tego automatyzacja nie miała większego sensu. Klient zapewnił, że rozmowy z kontrahentami na ten temat są już w toku, i zdecydował się uruchomić prace nad robotem równolegle, nie czekając na ich zakończenie.
Docelowa forma danych ostatecznie nie została wdrożona po stronie kontrahentów w zakładanym terminie. Zespół PIRXON przygotował rozwiązanie kompromisowe, które pozwoliło uruchomić proces mimo niepełnej cyfryzacji danych wejściowych – kosztem wydłużenia harmonogramu względem pierwotnych założeń.
To dobra ilustracja ryzyka, jakie niesie start projektu równolegle z zależnościami pozostającymi poza kontrolą zespołu wdrożeniowego. Deklaracja, że coś zostanie uporządkowane, to nie to samo, co zweryfikowany fakt.
Co te pytania faktycznie zmieniają
Odpowiedzi na te pytania bardzo często zmieniają sposób myślenia o całym projekcie. Okazuje się, że część czynności można całkowicie wyeliminować, inne uprościć, a dopiero pozostałe rzeczywiście warto automatyzować.
Podobny kierunek widać też w publikacjach EY i Microsoft dotyczących wdrożeń RPA. Powodzenie projektu zależy w dużej mierze od właściwego przygotowania organizacji, trafnego wyboru procesu i koncentracji na celu biznesowym, jeszcze zanim padnie pytanie o konkretną technologię.
To, dlatego podczas naszych analiz procesów najpierw chcemy zrozumieć, gdzie organizacja traci czas, gdzie są powtarzalne zadania, gdzie pojawiają się wyjątki, dlaczego ludzie przejmują pracę od systemów i czy założenia, na których ma się opierać projekt, zostały już potwierdzone, czy tylko zadeklarowane. Dopiero wtedy możemy odpowiedzieć na kolejne pytanie: „Czy ten proces rzeczywiście wymaga automatyzacji?”. Bo nie każdy wymaga.
Zobacz swój proces takim, jaki jest naprawdę
Jeżeli po lekturze tego artykułu rozpoznajesz w swojej organizacji opisane paradoksy, wiesz już, dlaczego odpowiednie planowanie decyduje o tym, czy projekt zakończy się sukcesem, czy rozczarowaniem.
Czasami większą wartość przynosi uproszczenie procesu. Czasami zmiana kolejności działań. Czasami usunięcie czynności, które od dawna nie mają już uzasadnienia.
Podczas Odkrywania Procesów wspólnie z klientem analizujemy, jak wygląda proces – nie tylko w dokumentacji i systemach, ale również w codziennej pracy, w miejscach, gdzie pojawiają się ręczne obejścia, wyjątki i dodatkowe czynności wykonywane poza oficjalnym workflow.
Nie proponujemy automatyzacji za wszelką cenę. Szczerze mówimy, gdy nie jest potrzebna. Pracujemy tylko wtedy, gdy ma to uzasadnienie biznesowe.
Jeśli to Ty odpowiadasz za wybór pierwszego procesu do automatyzacji w swojej organizacji, ten krok najbardziej zdecyduje o tym, czy za rok pokażesz zarządowi satysfakcjonujący wynik, czy będziesz musiał tłumaczyć się z jego braku.
