Co po PoC (Proof of Concept) - czyli czy, jak i kiedy kontynuować wdrożenie narzędzi RPA (Robotic Process Automatic)?

Zgodnie z wieloma rekomendacjami dostawców narzędzi RPA (Robotic Process Automation) i firm doradczych organizacje, które rozważają wykorzystanie u siebie robotów zaczynają od pilotażu (realizacji Proof of Concept - PoC).

Zwykle na tym etapie PoC wykazuje to co ma wykazać, czyli że robotyzacja procesów jest opłacalna, korzyści będą duże, a koszty (stosunkowo) niewielkie - a już na pewno zdecydowanie mniejsze aniżeli zakładane benefity.

Na tym etapie prac organizacja "dorabia się" maksymalnie 2-3 robotów (a często pozostaje przy słownie JEDNYM robocie). Jednocześnie, ponieważ organizacja nie ma kompetencji wewnętrznych, prace te najczęściej realizowane są przez konsultantów zewnętrznych - za darmo (aby np. pozyskać referencję), lub za symboliczną opłatę (firmy wdrożeniowe liczą bowiem, że odzyskają poniesione koszty w przyszłości, przy budowie i utrzymaniu kolejnych robotów).

Decydenci w organizacjach, na tym etapie, są zachwyceni uzyskanymi rezultatami (co więcej, mogą pochwalić się "rynkowi" że też mają roboty) i często zapada decyzja o uruchomieniu projektu wdrażania robotów na szerszą skalę.

Od tego momentu nagle zaczynają się mnożyć problemy.

Po pierwsze niezbędna jest w wielu wypadkach dedykowana struktura organizacyjna - okazuje się bowiem, że nie da się wdrażać robotów na potrzeby całej firmy "przy okazji" (a ciężko i drogo jest robić wszystko konsultantami zewnętrznymi). Tutaj pojawiają się kwestie etatów (i pozyskania pracowników do obsadzenia tych etatów - w wielu przypadkach nie jest to łatwe). 

Dodatkowo kluczowe staje się zamodelowanie (i optymalizacja) robotyzowanych procesów - bo "gołym okiem" widać, że inaczej będziemy mieli zrobotyzowany bałagan (a to zaczyna być groźne z perspektywy biznesowej - np. w przypadku błędu robota zmultiplikowane konsekwencje mogą być bardzo poważne). Oczywiście część firm powie, że nie trzeba modelować i optymalizować procesów przed ich robotyzacją (bo to wiąże się z kosztami i czasem) - ale takie podejście sprawdza się przy małej liczbie, stosunkowo prostych procesów.

Wreszcie okazuje się, że trzeba zakupić (za spore środki) narzędzie (najlepiej to, które było stosowane podczas PoC). No i trzeba zapłacić deweloperom robotów (często zewnętrznym) za ich pracę.

To wszystko powoduje, że nagle pogarszają się parametry finansowe przedsięwzięcia "robotyzacji" naszego biznesu. A równolegle okazuje się, że liczba procesów, które nadają się potencjalnie do robotyzacji (czyli mają charakter masowy, obsługuje je spora liczba osób i nie są zautomatyzowane innymi metodami) nie jest aż tak duża. 

Skutkuje to tym, że po fazie entuzjazmu zaczyna się szukać wyjścia z tej niezbyt komfortowej sytuacji - łącznie z rozważaniem możliwość zakończenia prac dotyczących robotyzacji...

Czy można jakoś zapobiec temu scenariuszowi (zanim się on zmaterializuje)?

Po pierwsze warto zastanowić się, jak docelowo ma wyglądać model robotyzacji organizacji (który może być ujęty w strategii robotyzacji)? W tym celu trzeba odpowiedzieć sobie na szereg pytań:

1. Czy faktycznie procesy, które chcemy zrobotyzować nie da się zautomatyzować w inny sposób (np. za pomocą platformy BPMS czy też API)? Osobiście jestem zwolennikiem, że trzeba sprawdzić inne scenariusze automatyzacji i dopiero jak nie ma wyboru, sięgnąć po robotyzację. Jeżeli "da się" - to może nie wdrażajmy robotyzacji.
2. Czy faktycznie mamy dość procesów, które nadają się do robotyzacji (w jej obecnym wydaniu, kiedy nie mówimy jeszcze o automatyzacji kognitywnej) - z wyłączeniem tych, które występują w pierwszym punkcie?
3. Czy chcemy budować kompetencje wewnętrzne dotyczące robotyzacji procesów, czy zdamy się na dostawców zewnętrznych (ale z pełnymi tego konsekwencjami - czyli godzimy się, że będą pobierać opłaty za tworzenie robotów, ale i zmiany w już istniejących robotach)?
4. Czy dopuszczamy lokalne podejście do budowy robotów (np. w poszczególnych komórkach), czy wszystko ma być scentralizowane (np. w Center of Excellence)? Pamiętajmy - centralizacja to bezpieczeństwo, standaryzacja ale dłuższy Time2Market i często wyższe koszty.
5. Jak podejść do nadzorowania coraz większej liczby robotów - kto ma to wykonywać, jakie dashbordy są do tego potrzebne, co zrobić z nie dotrzymaniem SLA przez roboty? 
6. Jak rozłożyć koszty istniejących robotów i zmian w tych robotach, pomiędzy departamenty biznesowe (czyli jak podejść do alokacji kosztów robotyzacji)? Czy IT ma jakoś partycypować w tych kosztach - np. przy zakupie licencji na narzędzia do wirtualizacji środowisk na potrzeby robotyzacji?
7. Jak zapewnimy audytowalność prac realizowanych przez roboty (jest to mało popularne zagadnienie, ale istotne z perspektywy odpowiedzialności i audytów)?
8. Jakie narzędzie do robotyzacji jest nam faktycznie potrzebne - czy takie, z górnej półki - czy może framework open source, który może nie jest ładny i modny (i nie dostaniemy nagrody na najlepsze wdrożenie), ale jest tani?
9. Czy dopuszczamy dokładnie jedno narzędzie do robotyzacji w firmie, czy może jednak dwa narzędzia (w zależności od typu robotyzowanego procesu i przewidywanego uzysku - możemy wybrać tańsze lub droższe narzędzie)?
10. Jakie KPI mają obowiązywać w kontekście robotyzacji (i dlaczego nie mogą to być wyłącznie KPI dotyczące "cięcia kosztów")?

Oczywiście oprócz tych kwestii zarządczo-organizacyjnych dochodzą kwestie techniczne, wcale nie mniej trywialne.

Jak widać rozpoczynając prace w zakresie robotyzacji warto przemyśleć szereg zagadnień, zanim podejmie się jakąkolwiek decyzję. Jest to bowiem zgodne z jednym z 7 nawyków skutecznego działania - czyli "zaczynaj z wizją końca". Czego Państwu serdecznie życzę :).