10 dobrych praktyk RPA

Istotą kodeksów dobrych praktyk jest to, że nie są to normy narzucane w drodze ustawowej lub innych przepisów, lecz ustanawiane przez przedsiębiorców na bazie ich doświadczeń. Czy w zakresie współpracy pomiędzy dostawcami rozwiązań RPA (producenci platform programistycznych, firmy doradcze, deweloperzy) a odbiorcami tych rozwiązań warto stosować zasady współpracy, które zweryfikowała praktyka?

Najogólniej rzecz ujmując wydaje się, że tak. Pewne sprawdzone metody współpracy i prowadzenia projektów automatyzacji prowadzą do eliminowania wielu ryzyk, w tym głównego z nich, a mianowicie niepowodzenia takiego projektu.

Nie jest dobrze przeceniać wartości automatyzacji, gdyż taka transformacja dla firmy nie jest prosta, jednak realistyczna współpraca pomiędzy dostawą i odbiorcą programu robotyzacji gwarantuje skuteczniejsze wykorzystanie jej potencjału.

Kodeks dobrych praktyk robotyzacji

Przedstawiamy listę 10 najważniejszych aspektów współpracy z dostawcami rozwiązań RPA, przygotowanych w oparciu o doświadczenia ekspertów Crowe.

1. Wspólne planowanie podejmowanych działań

Jest takie powiedzenie „Having no plan is a plan to fail”. Nie zaleca się rozpoczynania procesu robotyzacji bez wspólnego opracowania wysokiej jakości planu. Robotyzacja to nie tylko robot softwarowy, to również środowisko jego pracy, osoby współpracujące, procesy zachodzące równolegle, jak również nowe kompetencje, która temu towarzyszą. Właściwe zidentyfikowanie wszelkich ograniczeń i możliwości, jak również wszelkich elementów tego procesu warunkuje poprawne sformułowanie rozwiązania.

Dostawca rozwiązania powinien jasno przedstawić wymogi technologiczne związane z instalacją systemu RPA zarówno w formule on-premise, jak i cloud. Kwestie z tym związane w zakresie koniecznych nakładów, zapewnienia bezpieczeństwa, dostępności i utrzymywalności zasobów nierzadko mogą stanowić oddzielny projekt informatyczny towarzyszący procesowi robotyzacji.

2. Dokumentowanie procesu robotyzacji

Zadania realizowane w ramach automatyzacji powinny być udokumentowane, począwszy od charakterystyki procesu, który ma podlegać robotyzacji. Opis powinien objąć mapę działań oraz ich szczegółowy przebieg, łącznie z charakterystyką metryk procesu, możliwymi wyjątkami od reguł, jak również sposobami radzenia sobie z potencjalnymi błędami.

Taki opis stanowić może część Planu Ciągłości Działania (ang. Business Continuity Plan). W przypadku awarii robotów, z pomocą PCD można - za pomocą zapisanych instrukcji - kontynuować proces manualnie, bez istotnych zagrożeń dla jego realizacji. W tym kontekście istotne jest również zapewnienie dokumentacji w zakresie tworzenia kodu robota, chociażby na prozaiczny wypadek odejścia z pracy programisty, który go tworzył.

3. Realistyczne przedstawienie możliwości robota

Robotyzacja ma swoje ograniczenia - techniczne, zasobowe, procesowe, efektywnościowe, czasowe i szereg innych. Uczciwe przedstawienie funkcjonalności robota jest fundamentem zrozumienia jego szerokich możliwości, ale i naturalnych ograniczeń. Robot nie podejmuje niestandardowej decyzji, może sobie nie poradzić z odczytaniem pliku tekstowego – pomimo najlepszego OCR, jak również sam się niczego nie nauczy.

Konieczność trenowania i kontroli robota w jego codziennej pracy, poprawianie kodu w przypadku zmian przebiegu procesu, koszty związane z outsourcingiem w przypadku braku własnych programistów powinny być jasno zasygnalizowane na początku projektu automatyzacji. Unikniemy w ten sposób nieporozumień związanych z oczekiwaniami i efektywnością całego projektu.

4. Czytelność i prostota tworzonych rozwiązań

Zrozumiałość i przejrzystość tworzonego skryptu są nie do przecenienia w zakresie możliwości doskonalenia, modułowości, przejmowania ról, komunikacji i ciągłego rozwoju automatyzacji. Czytelność oznacza tutaj to, na ile stworzony kod pozwala na rozumienie tego, do czego dany robot został zaprogramowany. Prostota rozwiązania pozwala na oszczędności w zakresie poszukiwania błędów czy utrzymania poprawnego działania robota w środowisku jego pracy.

Upraszczanie zadań i rozwiązań w robotyzacji jest nieodzowne. Wszędzie tam, gdzie to możliwe dobrze jest redukować, eliminować niepotrzebną złożoność. Ograniczy to potencjał błędów w kodowaniu, poprawi jego efektywność, ale również wpłynie dobrze na sprawność zautomatyzowanych procesów.

5. Modułowość proponowanego rozwiązania

Modułowość oznacza tu możliwość rozłożenia kompleksowego programu robotyzacji na mniejsze, niezależne moduły lub podprocesy. Są dwa podstawowe atuty takiego podejścia. Po pierwsze zwykle w procesach mają miejsce powtarzalne czynności, jak np. zalogowanie się do systemu księgowego. Bardziej efektywne jest tworzenie niezależnego kodu i dodanie go do biblioteki rozwiązań niż programowanie za każdym razem nowego fragmentu robota. Takie podejście podnosi również użyteczność i efektywność pracy programisty.

Drugą zaletą jest to, że modułowość wspiera precyzyjne programowanie i testowanie rozwiązania. Jest to szczególnie przydatne w przypadku złożonych procesów, ponieważ można niezależnie przypisać tworzenie i testowanie określonych składników do poszczególnych etapów lub różnych deweloperów.

6. Wspólne testowanie rozwiązania

W praktyce często okazuje się, że pierwotny scenariusz przyjęty do zaprogramowania robota okazuje się bardziej skomplikowany niż pierwotnie zakładano. Proces może obejmować więcej wyjątków, a dane do przetwarzania okazują się być w innym formacie niż przyjęto. Trzeba wyjść z założenia, iż błąd w kodzie powinien zostać zauważony przed produkcyjnym uruchomieniem robota.

Naprzeciw temu wychodzi praktyka skrupulatnego testowania robota przed uruchomianiem w środowisku jego pracy. Najlepiej testować poszczególnych części kodu – sprawdza się tu postulat modularności kodu – co pozwala na wychwycenie błędów na konkretnym etapie jego pracy. Idealnym rozwiązaniem jest, gdy deweloper i tester to dwie różne osoby.

7. Jasne przedstawienie ograniczeń robotyzacji

Bez względu na to, którą platformę RPA wybierzemy, żadna nie będzie idealnym rozwiązaniem. Zawsze występują ograniczenia, a roboty bez względu na to, jak starannie zostaną zaprogramowane, nie będą działać niezawodnie przez cały czas. W trakcie ich pracy wystąpi naturalna konieczność dostosowania ich do zmieniających się warunków wynikających ze zmian w środowisku pracy (update, nowy typ dokumentu).

Przykładem ograniczeń może być rozpoznawanie obrazu, które jest wrażliwe na rozdzielczość ekranu, co może się okazać kłopotliwe w praktyce. Większość narzędzi RPA umożliwia wyodrębnianie tekstu z aplikacji internetowych, natywnie lub za pomocą OCR. Należy pamiętać, że OCR nie jest w stu procentach dokładne. W przypadkach, gdy precyzja jest ważna, oparcie się na obecnej technologii OCR może się okazać ryzykowne.

8. Realna ocena możliwości i czasu zwrotu z inwestycji

Rozpoczęcie dużego procesu robotyzacji wiąże się z koniecznością poniesienia kosztów związanych z przygotowaniem procesu (mapowanie, opomiarowanie, optymalizacja), przygotowaniem środowiska IT, zaprogramowaniem i wdrożeniem robotów, szkoleniami pracowników obsługujących ich pracę, kosztami utrzymania i przeprogramowywania robotów. Najczęściej bywają to koszty kilkudziesięciu tysięcy złotych rocznie, ale jednocześnie są rozwiązania prostsze, których koszt miesięcznej licencji wynosi 200 złotych.

To czy zastąpienie pracy ludzkiej pracą robota – jako główne źródło oszczędności – jest w stanie wygenerować powyższą wartość dodaną w dużej mierze zależy od pracochłonności automatyzowanych procesów oraz efektywności wykorzystania platformy programistycznej.  Rzetelna kalkulacja wartości i kosztów generowanych przez automatyzację pozwoli na realistyczne sformułowanie oczekiwań w tym zakresie.

9. Zarządzanie wprowadzaną zmianą technologiczną

Przejęcie zadań pracowniczych przez programy komputerowe jest niewątpliwie nową jakością w firmie. To, czy będziemy w stanie wzbudzić wystarczające zaangażowanie wśród pracowników, by opór i obawy przed zmianą były jak najmniejsze, zależy w dużej mierze od jakości komunikacji ze strony organizacji, jak i dostawcy rozwiązania.

Panuje powszechne przekonanie, iż większość ludzi nie lubi zmian. Zmiany powodują niechęć i opór. By skutecznie wdrożyć nowe rozwiązanie musimy zapewnić poczucie bezpieczeństwa, a więc informację co wydarzy się dalej oraz – co szczególnie ważne - świadomość, że zawsze można liczyć na wsparcie – m.in. poprzez szkolenia podnoszące kompetencje – jak również rozwianie przekonania, iż „robot zabierze mi pracę”. Dobra współpraca pomiędzy dostawcą RPA a daną organizacją może być niewystarczająca, jeśli brak jest tej współpracy wewnątrz organizacji.

10. Pokazanie potencjału rozwoju robotyzacji

Automatyzację można rozpocząć od zrobotyzowania jednego prostego procesu (lub nawet jego części), tak by był on polem doświadczalnym dla dalszego rozwoju automatyzacji. Taki Proof of Concept - czyli weryfikacja koncepcji ze strony dostawcy rozwiązania - powie nam czy dane automatyzacja zafunkcjonuje poprawnie. Rozpoczęcie robotyzacji nie wymaga budowy nowej strategii firmy, do przetestowania pomysłu wystarczają ogólnodostępne narzędzia w wersji beta i trzydzieści linii kodu pokazującego charakter pracy robota.

Często jest tak, że na samym początku pracownicy zaangażowani w robotyzowany proces są sceptyczni odnośnie tej koncepcji. Jednakże po roku często okazuje się, że ocena ta ulega diametralnej zmianie. Trzeba być na powyższe sytuacje przygotowanym. Po stronie dostawcy rozwiązania leży wskazanie na skutki ewolucyjnego versus rewolucyjnego podejścia do robotyzacji i wybór optymalnej taktyki dla danej organizacji.