Większość dużych organizacji już częściowo zaangażowała się w automatyzację procesów biznesowych. Udostępnienie za darmo przez Microsoft platformy RPA Power Automate Desktop oraz informacja, że w przyszłości będzie preinstalowana z systemem Windows 10 oznacza, że technologia RPA będzie szerzej obecna.
Na podstawie doświadczeń swoich oraz organizacji, z którymi współpracowałem, postanowiłem podzielić się praktycznymi radami, na co warto zwrócić uwagę w przygodzie z automatyzacją. Moje rady przydadzą się osobom związanym z wytwarzaniem automatyzacji procesów biznesowych.
W kontaktach z osobami związanymi z automatyzacją z różnych organizacji często jestem zaskoczony, gdy mogę pomóc, zwracając jedynie uwagę na wbudowaną funkcjonalność platformy, której te osoby używają.
Nie powinno być to jednak zaskoczeniem. Z raportu The 2019 Feature Adoption Report przeprowadzonego przez Pendo wynika, że nawet 80 proc. funkcjonalności programów jest używana rzadko bądź nigdy. Co to znaczy?
Może to wskazywać na brak wartości danych funkcjonalności dla użytkownika. Jednak w przypadku RPA wydaje mi się, że często ludzie nie zdają sobie sprawy z ich istnienia bądź z wartości, jaką przynosi ich zastosowanie.
Użycie produktów RPA skupia się głównie na funkcjonalności automatyzowania interfejsów użytkownika, co jest ich kluczową zaletą. Takie podejście umożliwia automatyzację prawie każdego systemu, którego nie można zautomatyzować w inny sposób.
Jednak większość czołowych platform RPA umożliwia m.in. także takie funkcjonalności jak:
Z doświadczenia wiem, że zespół automatyzacyjny doskonale znający swoje narzędzia i umiejętnie wykorzystujący wszystkie jego możliwości jest w stanie produkować roboty stabilniejsze, o lepszej jakości i w krótszym czasie. W rezultacie praca zespołu przynosi większy zysk dla biznesu, lepszą współpracę i redukuje frustrację podczas wytwarzania robotów.
- Dla człowieka, który dysponuje tylko młotkiem, wszystko, co spotyka zaczyna wyglądać jak gwóźdź - mówi popularne powiedzenie. Automatyzacja procesów biznesowych to szeroki temat. Dlatego trudno oczekiwać, by jedno rozwiązanie, jakim jest RPA, było odpowiedzią na wszystkie problemy.
RPA jest niesamowitym narzędziem, jednak nie zawsze jest odpowiednim dla danego problemu. Dlatego przy automatyzowaniu procesów biznesowych na dużą skalę, warto posiadać stack technologiczny umożliwiający wytworzenie rozwiązania pod konkretny proces lub problem.
Przykład. Firma postanowiła stworzyć Email Approval Workflow na ich platformie RPA. Niestety, rozwiązanie to nie posiadało wielu funkcjonalności dostępnych w nowoczesnym workflow oraz było kosztowne w utrzymaniu ze względu na wysokie wykorzystanie licencji. Organizacja działała też na platformie Office 365, więc naturalnym krokiem była rezygnacja z customowego rozwiązania na platformie RPA na rzecz Flow na platformie Power Automate. Takie podejście okazało się bardziej ekonomiczne i oferowało więcej możliwości, ponieważ narzędzie lepiej rozwiązywało problem.
Przykładowymi platformami komplementarnymi do RPA są:
Naturalnym rozwiązaniem są inne platformy typu Low Code, stworzone, aby utrzymać doskonałą szybkość dostarczania automatyzacji opartych na kilku platformach w tym RPA.
Każde wytworzenie automatyzacji zaczyna się od analizy procesu pod kątem automatyzacji. Od selekcji jednego procesu z tysięcy istniejących w organizacji, po analizę czy proces jest stabilny, powtarzalny i jesteśmy w stanie go wykonać.
To kluczowy element, któremu warto poświęcić dużo uwagi. Prosta analiza procesu może odpowiadać na następujące pytania:
Są to podstawowe pytania, które powinniśmy zadać przed przystąpieniem do tworzenia robota.
Jednak osiągniemy dużo więcej, posiadając osobę z kompetencjami do analizy procesów oraz dobrze znającą technologie używane w organizacji do automatyzacji
Taki analityk może zapewnić nam takie informacje jak:
Powyższe przykładowe pytania pokazują, jak wiele informacji jesteśmy w stanie zebrać. Dzięki nim możemy podejmować lepsze decyzje związane z selekcją procesów i maksymalizowaniem zysków z automatyzacji.
Nie jestem zwolennikiem ustalania pełnego governance oraz wszystkich zasad wytwarzania robotów na etapie POC bądź na samym początku implementacji. Preferuję rozwijanie całego modelu operacyjnego razem z rozwojem implementacji.
To są pewne procesy wewnętrzne związane z wytwarzaniem automatyzacji, które warto ustalić z myślą o ich skalowalności. Pominięcie tego kroku może przysporzyć więcej pracy w przyszłości i wymóc na nas większe zmiany. Oznacza to, że jeśli bieżący proces nie będzie działał poprawnie przy większej liczbe robotów, konieczna będzie jego zmiana, co może okazać się problemem, gdyż aktualnie mamy pod opieką wiele robotów.
Prostym przykładem z życia jest zwyczaj trzymania danych o automatyzacjach takich jak zyski, zautomatyzowane systemy czy udziałowcy w plikach Word czy PowerPoint. Często zdarza się, że takie dane trzymane są tylko w lokalnych plikach w dokumentach takich jak PDD i SDD. To rozwiązanie może być komfortowe przy kilku bądź kilkunastu automatyzacjach, lecz nie przy tysiącu.
Tam, gdzie liczba automatyzacji jest wysoka, potrzebujemy wiedzy o tym jakie procesy, części organizacji zostały już zautomatyzowane? Jakie zyski zostały osiągnięte, jakie procesy były analizowane, lecz zostały odrzucone. Jakie procesy będą dotknięte aktualizacją jednej z aplikacji, za jakie procesy był odpowiedzialny człowiek, który właśnie zmienia role/pracę?
Wytworzenie automatyzacji to dopiero początek. Aby osiągnąć zamierzone efekty, proces musi być wykonywany, co za tym idzie zarządzany i aktualizowany. Zarządzanie dużą liczbą zautomatyzowanych procesów może iść gładko bądź opornie, co spowoduje większe koszty ich utrzymania.
Jednym ze sposobów na sprawne utrzymywanie procesów jest stworzenie wewnętrznych standardów, biorąc pod uwagę potrzeby zespołu utrzymującego, już na początku przy analizie procesu oraz w czasie wytwarzania automatyzacji.
Wymagania i możliwości zespołu utrzymującego powinny być udokumentowane i na bieżąco aktualizowane. Dzięki temu analityk wie, czy wymagania biznesu odnośnie czasu lub częstotliwości wykonywania procesu są osiągalne. Wie, czy może zaproponować lepsze rozwiązanie. Może zamieścić informacje, w jaki sposób proces w przyszłości rozbudować czy zmieniać, tak by deweloper wziął to pod uwagę przy automatyzacji. Wszystkie informacje o udziałowcach, zespołach operacyjnych pracujących z daną automatyzacją powinny być udokumentowane w razie potrzeby kontaktu.
Deweloper powinien być świadomy wszystkich wymagań, standardów nałożonych przez zespół utrzymujący, by wydawać rozwiązania niewymagające zmian. Powinien również konsultować swoje kreatywne rozwiązania z zespołem, który dany proces od niego przejmuje i pozostawać z nim w stałym kontakcie.