Główne techniczne bolączki przy budowie robotów i wdrażaniu narzędzi RPA (i jak je naprawić)

Wdrażanie narzędzi RPA i wykorzystanie ich do bardziej złożonych procesów - bez względu na to co mówią ich dostawcy - w 95 na 100 przypadków kończy się pisaniem kodu (te 5 pozostałe przypadki, to proste roboty, które przynoszą zwykle małą wartość biznesową). To, dla osób zajmujących się RPA i mających swoje korzenie w IT truizm, jednak dla biznesu jest to spore zaskoczenie.

No bo przecież obiecywano im (tj. biznesowi), że roboty nie będą wymagały IT, że wystarczy poklikać a tutaj:

• trzeba zebrać wymagania - co robot ma robić,
• trzeba je zakodować,
• i na koniec trzeba przetestować robota.

To wszystko trwa i kosztuje (zarobki deweloperów RPA - zwłaszcza tych bardziej doświadczonych są niemałe).

Ale to nie jest najgorsze - skoro robot=kod, to powinien być on co do zasady dobrze napisany, dobrze udokumentowany, dobrze przetestowany i dobrze zarządzany (w szczególności w kontekście wprowadzanych w nim zmian).

I tutaj dochodzimy do wielu bolączek związanych z realizacją robotyzacji (jeżeli chcemy do niej podejść "na poważnie" i mieć więcej niż jednego robota. Okazuje się bowiem, że:

• Brakuje standardów kodowania robotów. Każdy deweloper (a na pewno każdy team) - trochę inaczej podchodzi do określonych zagadnień związanych zarówno z kodowaniem funkcjonalności robota (nawet jak pracują na tej samej platformie), ale również tak "trywialnymi" zagadnieniami jak nazywanie zmiennych, komentarz itp. To oczywiście bardzo skutecznie utrudnia późniejsze utrzymanie (i rozwój/zmiany) robota.
• Brakuje integracji narzędzi do wersjonowania kodu (takich jak np. Git lub klasyczny SVN) z narzędziami do RPA (problem ten występuje nawet w narzędziach z górnej półki).
• Brakuje dobrego przetestowania robotów - często organizacje potrafią mnie na prawdę mocno zaskoczyć ;) - prosto ze środowiska deweloperskiego roboty trafiają na produkcję, gdzie w trybie "operacji na żywym organizmie" poprawia się wykryte błędy (gorzej, z tymi błędami, które nie zostaną wykryte w obecności deweloperów, tylko odezwą się za jakiś czas ;)).
• Występują niespójności między środowiskiem testowym i produkcyjny - i robot, który bez problemu dział na testach - po uruchomieniu na produkcji staje (bardzo często jest pochodna braku goveranace w zakresie wdrażania robotów - bo na produkcji ktoś grał "małą poprawkę", ale zapomniał / świadomie pominął ją na testach - i to wystarczyło...). Co więcej często rodzi to dalsze konsekwencje, bo znane są przypadki, kiedy deweloper RPA zaczyna poprawiać niedziałającego robota na środowisku produkcyjnym (bo przecież nie ma czasu, klient czeka, jest presja) - i co prawdo robot działa za moment na produkcji, ale kod robota z produkcji nie zgadza się z kodem robota na środowisku deweloperskim - co rodzi nowe ryzyka...
• Brak dobrego przygotowania danych testowych (często jest to pochodna słabej analizy przedwdrożeniowej).
• Brak zarządzania środowiskiem deweloperskim - w szczególności brak kopii zapasowych. Znane są przypadki, kiedy "szewc bez budów chodzi" i często z przyczyn pozamerytorycznych deweloperzy RPA pracują na prowizorycznym środowisku (które miało być tylko "na moment", ale zostało z nimi na dłużej) i co więcej któregoś razu nadchodzi moment, w którym odmawia ono współpracy. I niezwykle trudno jest przywrócić jego działania, bez posiadania kopii bezpieczeństwa.
• Próbuje się  załatwić wszystkie bolączki biznesowe jednego rodzaju typem robotów (tj. pracującymi z nadzorem) - zapominając, że do dyspozycji są także roboty typu "unattended" (pracujące bez nadzoru).

Jakie może być podejście do rozwiązania przynajmniej części bolączek (tak, aby nie zabiły kosztowo i czasowo robotyzacji)? Proponuję podzielić deweloperów na Master Team (zwykle wystarczą 2, max. 3 osoby) i pozostałe (wchodzące zwykle w jeden zespół roboczy). W Master Team powinny znaleźć się osoby z największym doświadczeniem w zakresie RPA. To one powinny ustalać standardy, opracowywać Governance (nadzór) w zakresie wdrażania i rozwoju robotów, ustalać podejście do zarządzania środowiskami (powinno być: deweloperskie, testowe i produkcyjne). Osoby z pozostałych teamów powinny przestrzegać wypracowanych zasad i ew. raportować zastosowane od nich odstępstwa (z dobrym uzasadnieniem, dlaczego się je wprowadziło).

Na koniec jeszcze jedna uwaga. Jakiś czas temu w magazynie Forbes, było podane, że ponad połowa niepowodzeń w realizacji projektów technologicznych jest w rzeczywistości spowodowana złym zarządzaniem, a tylko 3% spowodowane jest problemami technicznymi. Dlatego oczywiście należy pamiętać o rzeczach przedstawionych w tym wpisie, ale przede wszystkim należy zadbać o dobrą strategię robotyzacji (a przynajmniej ustalenie kluczowych rzeczy dotyczących robotyzacji na poziomie zarządczym) i absorpcję robotów.