Czy siedzimy na bombie zegarowej - czyli jak duże rozczarowanie może nas spotkać po wdrożeniu narzędzi Robotic Process Automation?

Łatwo zauważyć, że RPA stało się obecnie bardzo modne. Każdy chce mieć swoje roboty :). A konsultanci i firmy IT jeszcze to nakręcają (licząc na własne zyski) i formułują podobnie brzmiące komunikaty: "Drogi biznesie, wdróż (nasze) RPA, a Twoje problemy (same) znikną". RPA ma być kolejną "magiczną różdżką", dzięki której biznes ma działać szybciej, lepiej, taniej. Ale czy tak rzeczywiście będzie? Czy za chwilę nie przeżyjemy kolejnego bolesnego rozczarowania?

Z jednej strony firma Gartner zauważa, że aż 96% jej klientów, którzy wdrożyli u siebie wdrożenia klasy RPA są z nich zadowoleni - czyli dzięki tym rozwiązaniom uzyskują realną wartość. Ale jednocześnie w raporcie "Get ready for robots" przygotowanym przez firmę EY (do niedawna Ernst and Young) przedstawione są informacje, że od 30 do 50% przedsięwzięć dotyczących implementacji RPA kończy się niepowodzeniem.

Z czego może wynikać taka rozbieżność rezultatów? Najprawdopodobniej Gartner badał organizacje, które są na etapie PoC (Proof of Concept) i bardzo starannie dobierały obszar pilotażu - a więc nie była to próbka reprezentatywna wyzwań związanych z wdrażaniem RPA. Natomiast analiza EY została dokonana z szerszej perspektywy.

Co może być źródłem rozczarowań podczas wdrażania narzędzi Robotic Process Automation? W praktyce okazuje się, że nie będzie tak tanio jak obiecywali dostawcy/konsultanci, na co złoży się  wiele powodów (przynajmniej część z nic przedstawiam poniżej). Po drugie: dużo więcej wysiłku trzeba będzie włożyć w efektywne utrzymanie całego środowiska robotów niż pierwotnie obiecywano (w szczególności jeżeli rośnie zakres stosowania robotów w przedsiębiorstwie). Po trzecie: w wielu wypadkach roboty okazują się jeszcze bardzo mało elastyczne, przynajmniej w stosunku do początkowych obietnic ze strony dostawców. Wreszcie często na końcu mamy do czynienia z  sytuacją, w której sam biznes sobie z robotami nie poradzi (w szczególności z robotyzacją kolejnych grup procesów lub wprowadzaniem zmian w już zrobotyzowanych procesach) i potrzebne będzie istotne wsparcie ze strony IT.

Jakie są źródła niepowodzeń przy wdrażaniu RPA? Na podstawie kilku źródeł (m. in. raportów EY, McKinsey, UiPath) oraz analiz własnych przygotowałem zestawienie kilkunastu najważniejszych ich przyczyn rozczarowań. Lista nie jest oczywiście zamknięta - będę wdzięczny za Państwa uwagi w komentarzach.

1. Zbyt duże obietnice składane na początku przez dostawców i konsultantów. Wiadomo, że tworzy się nowy rynek i trzeba za wszelką cenę na niego wejść (RPA lepiej się teraz sprzedaje aniżeli np. BPMS) - ale to prowadzi do patologii: nierealnych, a wręcz czasami nieuczciwych deklaracji odnośnie do efektów wdrożenia tej klasy narzędzi;
2. Problemy z elastycznością botów. Mitem jest (na ten moment), że boty się uczą i są elastyczne. Tak nie jest i długo jeszcze nie będzie. Okazuje się, że drobna zmiana w procesie, która od człowieka wymaga tylko przeczytania zaktualizowanej instrukcji stanowiskowej albo spytania kolegi "jak to zrobić" w przypadku wykorzystania botów wiąże się z pracochłonnymi i czasochłonnym przeprogramowaniem;
3. Problemy z niedoszacowaniem faktycznej liczby kombinacji procesu. Nawet trywialny wydawałoby się proces może mieć kilkanaście różnych wariantów przebiegu. Człowiek z większością sobie (dość szybko) poradzi, robot wymaga odpowiedniego przygotowania;
4. Problemy z obsługą sytuacji wyjątkowych (np. cyberatak). Na skutek zaistnienia określonych zdarzeń zdarzają się sytuacje, w których następuje konieczność odstępstwa od przyjętych reguł. Człowiek sobie z tym poradzi. W przypadku robotów (dobrze wdrożonych) nastąpi przeskalowanie zagadnienia do człowieka (nadzorcy) - ale proszę sobie wyobrazić, co się będzie działo, jeżeli środowisko zostało źle skonfigurowane? 
5. Problemy ze skalowalnością zastosowania robotów. Zupełnie innych sił i środków potrzeba na automatyzację kilku procesów, innych - dla kilkunastu procesów, a jeszcze innych (zdecydowanie większych - bo wzrost ma charakter nie liniowy, a wykładniczy) - przy kilkudziesięciu. Proszę pamiętać, że TCA obejmuje nie tylko implementację, licencje, ale również późniejsze zmiany w środowisku zrobotyzowanym. Do tego przy tak złożonych pracach kluczowe jest wykorzystanie dedykowanych analityków (o ile przy PoC można się bez nich obejść lub ich rolę pełnią konsultanci firm doradczych, to docelowo są oni niezbędni);
6. Problemy z nieustrukturalizowanymi danymi. Okazuje się, że jeszcze długa droga jest do w pełni efektywnego i wiarygodnego przetwarzania danych mających postać nieustrukturalizowaną (np. załączniki do maili w postaci skanów);
7. Problemy z zapewnieniem odpowiedniego poziomu bezpieczeństwa. Okazuje się, że robot ma uprawnienia, którymi nie dysponuje żaden pracownik (robot jest przecież "sumą" n pracowników, a więc ma co najmniej n grup uprawnień). W praktyce taka sytuacja przyprawia o intensywny i długotrwały ból głowy specjalistów w departamentach odpowiedzialnych za bezpieczeństwo;
8. Narzędzia w obszarze RPA nie są tak dojrzałe jak obiecują to ich dostawcy (chociaż mocno to się zmienia - patrząc na czynione inwestycje w ten obszar, realizowane chociażby przez fundusze Venture Capital);
9. Dostawcy poszczególnych platform RPA zaczynają się specjalizować i szukać nisz. Może się okazać, że produkt, który został wybranych przez firmę jako podstawa do automatyzacji i robotyzacji zacznie ewoluować w stronę, która nie będzie już dla firmy odpowiednia;
10. Dołożenie na istniejące systemy (często legacy) warstwy RPA powoduje duże wyzwanie od strony architektonicznej i często wydajnościowej. To z kolei jest kolejnym źródłem bólu głowy w departamentach IT. Wymaga bowiem z ich strony dodatkowego wysiłku - a często departamenty IT nie mają jeszcze doświadczeń z postępowaniem ze złożonymi środowiskami RPA;
11. Nawet niewielka modyfikacja infrastruktury znajdującej się pod systemami legacy, na które nałożone są rozwiązania RPA może stać się źródłem szeregu zmian w wyższych warstwach -  np. aktualizacja starego serwera aplikacyjnego/serwera bazy danych pociąga za sobą konieczność przeportowania aplikacji - a to wiązać się może z bardzo istotną koniecznością przebudowania robotów. Tutaj pojawiają się kwestie komunikacji, priorytetów, budżetu na styku Biznes-IT (np. kto ma zapłacić za zmianę w robotach, na ile zmiana ta została wywołana aktualizacją warstwy infrastruktury IT?);
12. Większość wdrożeń RPA odbywa się w warstwie interfejsu użytkownika z wykorzystaniem zwirtualizowanych stacji roboczych. Problemy komunikacyjne na linii Biznes-IT mogą skutecznie utrudnić przygotowanie i rozwój niezbędnej infrastruktury informatycznej;
13. W praktyce po pierwszych spektakularnych redukcjach liczby etatów  (FTE) może się okazać, że im dalej w las, tym gorzej. Może się okazać, że wprowadzenie 100 botów nie zastąpi 200 ludzi (jak pierwotnie obiecywano) - wyniki mogą być dużo słabsze od planowanych. Może się bowiem okazać, że człowiek faktycznie wykonywał faktycznie dużo więcej czynności, aniżeli zostało objętych robotyzacją;
14. Postrzeganie wdrożenia RPA jako przedsięwzięcia o charakterze stricte informatycznym. Dodatkowo ma być ono proste, łatwe i przyjemne - bez wysiłku ze strony organizacji; a już w szczególności firma nie będzie musiała nic optymalizować, zmieniać. Oczywiście można tak do tego podejść, ale to pozwoli tylko zebrać "najniższej wiszące owoce" - czyli może się okazać, że ze względu na wyżej wymienione problemy cały business case wdrożenia RPA się zawali;
15. Próba zastosowania klasycznych metod wdrażania i dokumentowania systemów przy wdrażaniu RPA. W tym przypadku zdecydowanie lepiej do tego nadaje się dobrze wdrożone podejście zwinne;
16. Brak doświadczeń z budowaniem centrów doskonałości RPA. Część organizacji podejmuje działania w tym zakresie, po czym okazuje się, że brak jest im niezbędnych kompetencji;
17. Brak doświadczenia i kompetencji po stronie konsultantów wdrażających RPA (proszę nie mylić konsultanta ds. RPA z juniorem-programistą który "tworzy kod").
18. Aspekty ludzkie przy wdrażaniu RPA (np. kiedy menedżer uświadomi sobie, że podlegać będzie mu po wdrożeniu RPA tylko 30 pracowników, a nie 70 - czyli będzie dwa razy mniej ważny);
19. Sztuczna inteligencja jest obecnie mocno przereklamowana. Obecnie (prawie) wszystkie rozwiązania klasy Cognitive RPA "działają dobrze jedynie w PowerPoincie" albo są dopiero w fazie Research&Development. 

Co to wszystko oznacza i co nas czeka? Czy problemy na obecnym etapie z implementacją RPA spowodują odwrót od tej koncepcji? 

Pewnie kilka(dziesiąt/set) firm (piszę o polskiej perspektywie) dotknie RPA po czym się z tego wycofa (za moment usłyszymy "u nast to nie działa") -  przy czym będę raczej obstawał, że źródłem problemów (i rozczarowań) było wdrożenie, a nie sama idea robotyzacji procesów. Część firm wytrwa i te będą zbierać za jakiś czas tego owoce. 

Stawiam bowiem tezę, że mimo pierwszych (nawet bolesnych i kosztowanych) rozczarowań nie ma odwrotu od zaawansowanej automatyzacji i robotyzacji. Ale być może trzeba będzie przejść ścieżkę opisaną przez jednego z CIO odnośnie do wdrażania na masową skalę RPA, która jest opisana w materiale firmy McKinsey: "Rozbiliśmy się, spaliliśmy [pierwsze podejście] i teraz wskrzeszamy RPA!".