Robotyzacja, czyli jak wprowadzić zrobotyzowaną automatyzację procesów (RPA)

RPA (Robotic Process Automation), inaczej zrobotyzowana automatyzacja procesów, to nic innego jak powierzenie powtarzalnych, wieloseryjnych czynności/procesów oprogramowaniu, zamiast wyspecjalizowanego pracownika. Przynosi to wymierne korzyści, zarówno firmie, jak i samym pracownikom, którzy mogą poświęcić swój czas na inne, bardziej kreatywne zadania. Do samego zagadnienia RPA warto jednak czasem podejść niekonwencjonalnie. Opowiem Wam krótką historię o tym, jak RPA wprowadziliśmy w T-Mobile. 

Jeszcze 4 lata temu, dziś dobrze wszystkim znany skrót RPA, kojarzył mi się co najwyżej z apartheidem, Przylądkiem Igielnym i złotymi Krugerrandami. Zajmowałem się wówczas automatyzacją, ale testów. W organizacji tak dużej, jak T-Mobile, w której liczba systemów idzie w dziesiątki (by nie powiedzieć, że setki) wykonanie pełnego zakresu automatycznych testów regresji przy ciągle zwiększających się wymaganiach czasowych nie było łatwe. 

Duża liczba systemów, różne technologie, duże znaczenie danych testowych i presja czasu, to tylko niektóre wyzwania, z którymi musieliśmy się mierzyć. Odpowiedzią na wymagania naszej organizacji było wdrożenie platformy automatyzacji testów. 

Wśród wielu wymagań było również takie, by automaty można było uruchamiać z HP ALM. Był to jeden z elementów, który już na wstępnie popchnął nas w stronę technologii Microsoft, gdyż VisualBasic oferował najłatwiejszą metodę integracji. Nasza platforma kolejkowała zlecane zadania, dystrybuowała je do stacji wykonawczych w zależności od technologii testowanego systemu, serwowała dane testowe i robiła dokumentację przebiegu testów. Do tego należy doliczyć moduł zarządzania platformą i kontroli wersji skryptów. Na marginesie - aplikacje webowe testowaliśmy przy pomocy Selenium, natomiast okienka w HP UFT. Wróćmy jednak do RPA… 

Robotyzacja w T-Mobile wykiełkowała jako oddolna odpowiedź na nagłą potrzebę biznesową. Nasz system CRM przy pewnych typach procesów był bardzo niewdzięczny i czasochłonny w obsłudze. Ktoś wówczas postawił bardzo celne pytanie: „czy tymi automatami do testowania można „przeklikać” sprawy dla klientów?”. Odpowiedź rzecz jasna brzmiała: „TAK”.

Przesadnie sprawę upraszczając, różnicą jest jedynie środowisko. Automat do testów funkcjonalnych ma za zadanie wykonanie akcji na GUI systemu na środowisku testowym, dokładnie takich samych, jakie po wdrożeniu ma robić osoba obsługująca system na środowisku produkcyjnym. Tą właśnie metodą upewniamy się ze dana funkcjonalność działa. Czemu więc nie wykorzystać możliwości narzędzi testujących, by realizować procesy biznesowe na PROD? I do tego działając na 30 wątków jednocześnie!

Skopiowaliśmy główne mechanizmy platformy testującej i osadziliśmy je na nowym środowisku. Dodaliśmy zwiększoną kontrolę dostępu, nowe mechanizmy uruchamiania procesów i pobierania danych wejściowych oraz raportowania wyników. Powstał nowy framework dla Selenium. To był początek platformy robotyzacji o wdzięcznej nazwie Tapir (w T-Mobile jest tradycja, by nadawać systemom nazwy ze świata zwierząt).

Kilka słów od strony technologii: mózgiem Tapira jest baza danych Microsoft. Tam znajdują się kolejki, konfiguracje, dane testowe, skrypty, logi, raporty itd. Środowisko działania robotów to stacje wirtualne WIN10 osadzone na VmWare. Dostajemy się do nich przez Citrixa. Na stacjach VDI pracuje aplikacja Client (VisualBasic) pytająca DB o zadania odpowiednie do swojej konfiguracji. Taka architektura pozwala nam na łatwe skalowanie środowiska wykonawczego, a tym samym umożliwia szybkie zwiększenie wydajności całej platformy. 

Za kontakt z robotami opowiada front Tapira napisany w Angularze. Użytkownik znajdzie tu listę wszystkich dostępnych robotów w zależności od posiadanych uprawnień. Może pobrać szablon wymagany dla konkretnego procesu, dokonać walidacji poprawności danych przed uruchomieniem robota i śledzić postępy pracy. W razie błędów również tu dostępne są ich szczegóły. Na obecną chwilę w ramach Tapira pracuje już ponad 30 robotów!

Czas transformacji Agile w T-Mobile to dla robotyzacji czas rozwoju. RPA w tej chwili to dedykowany Squad produktowy w ramach Tribe’u Digital Experience. W ramach nowych struktur rozwijamy w dalszym ciągu nasze pierwsze dziecko – Tapira. Jest to rozwiązanie „uszyte na miarę” i w swoim obszarze spisuje się bardzo dobrze. Zerowe koszty licencji nie pozostają tu bez znaczenia.

Nasze horyzonty są jednak szersze. Wkroczyliśmy do nowych obszarów firmy, m. in. Call Center. Po raz kolejny postanowiliśmy zaproponować rozwiązanie własnej produkcji. „Na słuchawkach” jednak mamy do czynienia z inną specyfiką realizowanych zadań. Nie ma tu długich procesów dla dużych klientów, spotkamy natomiast bardzo dużo krótszych interakcji z systemami. Tu potrzebne było lekkie narzędzie z szybkim dostępem, pozwalające korzystać często, ale na małej ilości danych.

Po burzliwych rozmowach postawiliśmy kolejny raz na dość niekonwencjonalne rozwiązanie – plugin do przeglądarki. To rozwiązanie pozwala mieć swojego robotycznego asystenta zawsze pod ręką. Pierwsze roboty w obrębie pluginu są już na produkcji i przynoszą wymierne korzyści. Tę platformę postanowiliśmy nazwać Kapibara.

Od strony technologicznej Kapibara powstawała w całkowicie nowej rzeczywistości. Nie tylko mindsetowej, ale również i technologicznej. W firmie kończono właśnie wdrażać Kopernika - naszą chmurę prywatną opartą o technologię Kubernetes. W zespole wszyscy wiedzieliśmy od początku, że nasze nowe produkty będziemy chcieli realizować w oparciu o promowane obecnie w naszej firmie podejście mikroserwisowe oraz technologie chmurowe. 

Dlatego Kapibara powstała jako łatwo skalowalne REST API napisane w technologii Java Spring, przy użyciu kontenerów Docker. Źródłem danych jest baza MySQL na OpenStack. Publikowanie image dockerowych zostało zautomatyzowane w procesie CI/CD. Dodatkowo przy pomocy Ranchera jesteśmy w stanie zarządzać wielkością środowiska.

Przyjemną rzeczą jest to, że nasze zwierzątka od początku się polubiły i współpracują ze sobą. Część procesów wystartowanych w Kapibarze kończy się akcją realizowaną na GUI przez robota w Tapirze. 

Obecnie wchodzimy w kolejny obszar robotyzacji - rozpoznawanie skanów. Identyfikujemy procesy i testujemy różne rozwiązania. To kolejny krok w cyfrowej transformacji naszej firmy. Nadal wiele procesów biznesowych opiera się o papier a współczesna technologia potrafi całkiem skutecznie radzić sobie z rozpoznawałam nawet odręcznego pisma. Pracujemy nad stworzeniem rozwiązania automatycznego, które będzie potrafiło w wygodny sposób współpracować z człowiekiem i zwracać się do swojego operatora o pomoc w sytuacji, gdy samo nie poradzi sobie z wykonywanym zadaniem.

W przeciwieństwie do Tapira i Kapibary, w przypadku tego obszaru, zanosi się jednak na zakup komercyjnej licencji ze względu na niewystarczające możliwości darmowych silników OCR. Nasze rozwiązania są otwarte na integracje i na obecną chwilę stawiamy na synergię rozwiązań własnych i półkowych. Mamy już „na warsztacie” pierwsze procesy i muszę przyznać, że temat wygląda bardzo obiecująco. Na szczegóły jednak jeszcze za wcześnie.

Obecnie niemal każdy mój dzień pracy zaczynam od spojrzenia na tablicę monitoringu pracy robotów. Widnieje na niej 50 kafli, które zmieniając kolor informują o statusie danego robota. To bardzo budujące uczucie być częścią zespołu, który stosując niecodzienne, wypracowane samemu podejście, powołał do życia dziesiątki robotycznych pomocników, którzy na co dzień wyręczają naszych kolegów w monotonnych czynnościach. Większość firm dookoła pływa tylko na flagowych okrętach pod banderami UiPath, Bleu Prism, Automation Anywhere czy WorkFusion. My zbudowaliśmy własną łódź i popłynęliśmy niejako pod prąd. Dobrodziejstwo wszechstronności oprogramowania open source pozwala nam stale zwiększać możliwości naszego jachtu. Rejs przebiega bez większych zakłóceń.