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

Kategoria II
Wiedza
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)?

Warto zastanowić się, jak docelowo ma wyglądać docelowy model robotyzacji organizacji - z perspektywy mechanizmów zarządzania, nadzorowania, raportowania i narzędzi informatycznych. 

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ę :).