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.
Poznaj swoje narzędzia
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:
- Używanie/eksponowanie Web Services
- Automatyzowanie baz danych
- Podłączanie się do lokalnych API takich jak COM
- Rozszerzanie funkcjonalności platformy RPA za pomocą .NET
- Używanie JavaScript przy problematycznych aplikacjach webowych
- Podłączanie istniejących bibliotek np. .NET, by wykorzystać ich funkcjonalność w RPA
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.
Wybierz właściwe narzędzia do problemu
- 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ą:
- Platformy Integracyjne takie jak PowerAutomate/Zapier/IFTTT
- Miejsce do przechowywania plików/danych dostępnych dla pracowników jak Intranet/SharePoint/PowerBI
- Budowanie interfejsów użytkowników jak PowerApps
- Cognitive Services/Machine Learning jak Azure Cognitive Services/ Power Automate AI Builder
Naturalnym rozwiązaniem są inne platformy typu Low Code, stworzone, aby utrzymać doskonałą szybkość dostarczania automatyzacji opartych na kilku platformach w tym RPA.
Zadbaj o dobre kompetencje analizy procesów biznesowych
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:
- Czy proces w istniejącej formie da się zautomatyzować?
- Ile zajmie wytworzenie takiej automatyzacji?
- Jakie zyski osiągniemy z powodu automatyzacji?
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:
- Skąd wzięły się dane w tym procesie?
- Jakie są procesy poprzedzające/następujące po tym?
- Czy jesteśmy w stanie zmienić ten proces, aby zmaksymalizować zysk z użycia robota. W jaki sposób udziałowcy procesu z nim współpracują?
- Czy proces może dostarczyć czegoś więcej, szybciej lub w bardziej dostępnej formie?
- Czy proces występuje w podobnej formie w innym miejscu w organizacji np. w innym kraju?
- Czy jesteśmy w stanie użyć istniejących automatyzacji do rozwiązania tego problemu lub jego części?
- Jak obecna biblioteka automatyzacji jest w stanie przyspieszyć dostarczenie tego rozwiązania?
- Jakie zyski są niemierzalne, np. podniesienie satysfakcji pracowników poprzez automatyzację nielubianych części procesu?
- Jak mierzalne są zyski, które są nie tylko zautomatyzowanymi godzinami pracy, ale mogą ujawnić się dopiero po czasie w innym procesie?
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.
Działaj teraz, ale z myślą o przyszłości
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ę?
Myśl o zarządzaniu automatyzacją już na początku
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.
