Jak nie zawalić wdrożenia projektu RPA w 5 krokach

Jak nie zawalić wdrożenia projektu RPA?

Robotic Process Automation to technologia, która cały czas zyskuje na zainteresowaniu wśród przedstawicieli firm mających na celu optymalizację procesów, poprawienie wskaźników wydajności oraz uzyskanie wymiernych korzyści finansowych.

Popularność narzędzi RPA wynika również z faktu, iż niektórzy producenci oferują bezkosztowy dostęp do oprogramowania (wystarczy spełnić pewne warunki). To wszystko sprawia, że technologia jest coraz lepiej znana i rozumiana.

Dostawcy RPA bardzo często promują swoje produkty jako rozwiązania typu low code lub no code, przekonując w ten sposób, że nawet osoby bez doświadczenia w obszarze IT, np. w pisaniu programów, mogą bez większego problemu zaangażować się w budowanie robotów software’owch.

Niestety nie do końca mogę zgodzić się z taką opinią, ponieważ nie każda osoba z biznesu chcąca tworzyć roboty będzie do tego zdolna.

Dlaczego producenci tak przedstawiają swoje produkty? Cóż, jest to zwykły zabieg marketingowy, aby łatwiej przekonać potencjalnego klienta do oferowanego rozwiązania.

Brak doświadczenia w programowaniu lub konstruowaniu algorytmów, to nie jedyna przeszkoda, która może rozłożyć na łopatki cały projekt wdrażania Robotic Process Automation w przedsiębiorstwie.

Na jakie więc inne aspekty związane z budowaniem botów należy zwrócić uwagę, aby nie zawalić projektu?

Jeśli słuchasz naszych podcastów to zapewne obiło Ci się o uszy określenie cykl życia robotów. Nie wchodząc za bardzo w szczegóły, najważniejszymi jego etapami są identyfikacja pomysłu i jego analiza, projektowanie i budowanie robota, testowanie, a następnie wdrożenie i utrzymanie. No i oczywiście tzw. delisting, czyli odesłanie robota na emeryturę. Mając na uwadze wspomniane fazy projektu wskażę Ci jakie błędy są najczęściej popełniane.

Akceptuj pomysły, które przeszły wstępną selekcję

W ramach analizy procesu należy zajmować się tylko zidentyfikowanymi, potencjalnymi obszarami do automatyzacji, które zostały już sprawdzone zarówno pod kątem możliwości ich zrobotyzowania (proces zestandaryzowany, elektroniczna forma danych, oparty o reguły, duży wolumen itd.)  oraz opłacalności, np. szacowana oszczędność na poziomie 3 FTEs.

Jeśli widzisz, że proces wymaga zoptymalizowania i „wygładzenia”, to pod żadnym pozorem nie akceptuj go jako potencjalnego kandydata do automatyzacji. Jeśli to zrobisz, prosisz się o kłopoty.

Dokumentacja, czyli kompas w podróży do RPA

Etap analizy to również gromadzenie, weryfikowanie istotnych informacji związanych z procesem, które następnie przybiorą formę dokumentacji procesowej PDD (Process Definition Document). Zawiera ona najważniejsze wskazówki, czyli m.in. mapę procesu w jego obecnym stanie, mapę procesu prezentującą stan docelowy, dokładne opisanie danych na wejściu oraz na wyjściu procesu, zestawienie stosowanych aplikacji, jak ma wyglądać obsługa błędów i wyjątków itd.

Zdarza się, że analityk biznesowy lub inna osoba odpowiedzialna za przygotowanie wspomnianej dokumentacji wybiera drogę na skróty i przegląda istniejące procedury, na podstawie których później tworzy PDD. Jest to ryzykowne zwłaszcza wtedy, kiedy posiadana dokumentacja jest przestarzała i różni się od realiów biznesowych.

Stąd rzeczą niezmiernie istotną na etapie tworzenia dokumentacji jest ścisła współpraca analityka biznesowego z tzw. SME (Subject Matter Expert), czyli osobą znającą proces od podszewki. Jej zaangażowanie w tej fazie jest kluczowe.

Pomyśl, zanim zrobisz

Kiedy cała dokumentacja spłynie do dewelopera RPA, ten powinien najpierw przeanalizować zebrane informacje, a następnie zaprojektować rozwiązanie i to jeszcze zanim siądzie do budowania robota.

Niestety wielu świeżo upieczonych deweloperów chce jak najszybciej stworzyć „arcydzieło” swojego życia, co w konsekwencji sprawia, że budowanie robota przeciąga się w czasie, ciągle czegoś brakuje, o czymś nie pomyślano, coś działa nie tak jak powinno.

Deweloper powinien solidnie przestudiować dokumentację, wyjaśnić wszelkie wątpliwości z analitykiem oraz ekspertem procesu i dopiero wtedy przystąpić do projektowania rozwiązania dbając o to, aby charakteryzowało się m.in. klarowną logiką działania, elastycznością, łatwością utrzymania i rozbudowy.

Buduj i testuj

Dla dewelopera RPA tworzenie robota to najciekawszy etap pracy. Teraz tworzy to, co zostało wcześniej udokumentowane i zaprojektowane. Etap o tyle przyjemny, że większość z dostępnych rozwiązań RPA pozwala budować boty z gotowych aktywności, predefiniowanych komponentów. Oczywiście nie obejdzie się bez definiowania zmiennych czy argumentów.

Niemniej jednak warto pamiętać o tym, żeby nie budować wszystkiego od początku zwłaszcza, jeśli mamy za sobą pierwsze udane wdrożenia. W takim przypadku wykorzystać należy już opracowane rozwiązania, a zaoszczędzony czas poświęcić na ich ewentualne dostosowanie do bieżącego przypadku.

Tworząc robota nie należy skupiać się tylko i wyłącznie na tzw. happy path, czyli idealnym przebiegu procesu. Trzeba również zająć się obsługą błędów i wyjątków. Jeśli to zostanie zignorowane, to ani robot, ani deweloper nie przysporzą sobie zwolenników.

Dlatego tak ważne jest budowanie oparte o spójną logikę procesu, a następnie testowanie każdego pojedynczego komponentu oraz całego rozwiązania. Istotne jest, aby na etapie testów zaangażować przedstawicieli biznesu, bo to oni najlepiej znają proces. Druga sprawa, to zadbanie o odpowiednią liczbę scenariuszy, aby przetestować wszelkie możliwe sytuacje.

Początkujący deweloperzy RPA powinni również zweryfikować czy występują jakiekolwiek różnice pomiędzy środowiskiem deweloperskim/testowym, a środowiskiem produkcyjnym, gdzie ostatecznie robot będzie pełnił swoje zadanie.

Trzymaj rękę na pulsie

Kiedy gotowy robot trafia do produkcji zdarza się, że deweloperzy (zwłaszcza ci z niewielkim doświadczeniem) myślą, że po zbudowaniu i wdrożeniu rozwiązania mogą teraz o nim zapomnieć.

Nic z tego. Dla powodzenia całego przedsięwzięcia niezbędne jest utrzymywanie właściwego stanu technicznego robota oraz jego dalsze rozwijanie (np. jeśli wymaga tego zmiana warunków otoczenia biznesowego lub systemowego). Dlatego na tym etapie od dewelopera będzie się wymagać ciągłego rozwiązywania wszelkich pojawiających się problemów, które są nieodłącznym elementem funkcjonowania robota w środowisku produkcyjnym.

Warto również zadbać o tzw. Business Continuity Plan (BCP) na wypadek awarii robota, aby zapewnić ciągłość procesu (być może musi być czasowo wykonywany manualnie), jego całkowitego wyłączenia (przejście na emeryturę) lub zamiany innym rozwiązaniem automatyzującym proces.

Przedstawione powyżej aspekty prawidłowego wdrażania Robotic Process Automation z pewnością nie wyczerpują tematu, ale mogą stanowić istotny drogowskaz zwłaszcza dla osób rozpoczynających przygodę z robotami.

Ponieważ w proces budowania robotów najczęściej zaangażowany jest wieloosobowy zespół, dlatego zawsze należy zadbać o właściwy poziom komunikacji między członkami ekipy oraz walidować wyniki każdego etapu, zanim przejdzie się do realizacji kolejnego.

Uzbrojeni w taką wiedzę i dysponujący najnowszymi technologiami RPA, śmiało możemy przystąpić do budowania robotów.