UiPath- pierwsze wrażenia

Ależ ja lubię uczyć się nowego softu. Poważnie. Biorę sobie do łapki trial, dokumentację i spędzam weekend ucząc się czegoś nowego. Szczerze mówiąc jest to jedna z ciekawszych aktywności, które realizuję podczas tygodniowego cyklu. Po za tym to jest nudno. Praca, dom, trochę posiedzę w kuchni, łyknę w miesiącu z dwie książki, doszła jeszcze siłownia, która mam nadzieję, nie zniknie mi z oczu. Czasami coś napiszę, bo udało mi się zauważyć ciekawe zjawisko, co za tym idzie poświęcę się analizie i opiszę jak to widzę.

Ostatnimi czasy do biblioteki softu, z którym pracować potrafię, doszedł Axshare. Takie śliczne narzędzie do makietowania UI. Tworzy się lub korzysta z gotowych assetów i ogarnia wizualizację. Szczerze polecam, każdemu, kto projektuje sobie aplikację. Jeden obraz wart jest więcej niż tysiąc słów. Makietki, makietami. Ważny temat, szczególnie teraz, gdy strona wizualna jest o wiele ważniejsza dla końcowego użytkownika niż backend. Jakoś tak się przyjęło i bardzo dobrze, że doświadczenie płynące z pracy ma być czymś przyjemnym, a nie koniecznością i to co najmniej trudną w odbiorze. Znak czasów i postępu. Może dlatego, że backend pisze się o wiele łatwiej niż kiedyś i można poświęcić czas a skorzystanie z frontowych bibliotek, żeby było przyjemniej. No cóż, czasy brzydkich okienek odeszły i niech zostaną pogrzebane na cmentarzu historii IT. Niech sobie tam w spokoju leżą i nigdy nie powstają z grobów. I tak za chwilę do pobliskiej kwatery złożymy to co robimy aktualnie, na rzecz AR. Dajmy chwilę na hardware i okienka będą lada moment wyświetlane prosto na oczy. To dopiero będą czasy 😉

Nie chcę pisać o doświadczeniach, a przynajmniej nie bezpośrednio. W ten weekend dodałem do mojej biblioteczki program UiPath. Zapytacie się co to jest i o co chodzi? Już z przyjemnością opowiadam co to za zabawka i dlaczego będzie jednym z najważniejszych rozwiązań najbliższych kilku lat.

Najpierw rys historyczny.

Mniej więcej dwie dekady temu, okazało się, że można szybciej pracować dzięki komputerom. Dwie dekady temu pojawiły się pierwsze systemy informatyczne, które robiły coś i zastępowały papier. Rozwiązania miały być rewolucyjne i pozwalać na zmniejszenie kosztów ludzkich. Trochę tak się stało. Dlaczego trochę? Bo w zasadzie zwiększyła się efektywność pracy. Oznacza to, że na godzinę można zrobić więcej niż kiedyś. Tak też, ludzi pracujących jest mniej więcej tyle samo, ale wykonują oni pracę lepiej, szybciej, co za tym idzie więcej wytwarzają i zarabiają dla mitycznego pracodawcy.

Od tych dwóch dekad napisano miliony linii kodu, robiących różne rzeczy. Od ścieżek procesowych, przez przetwarzania danych, po samoobsługę. Powoli papier odchodzi do lamusa i jest takim złem koniecznym, które trochę wymagane jest przez prawo, w niektórych przypadkach lub zaszłości historyczne, gdzie to umowy są skonstruowane tak jak kiedyś się to robiło. Taka era przejściowa, która za chwilę powinna się skończyć i wtedy otworzymy szampana. Będzie miło.

Jest oczywiście pewien problem. Języki programowania oraz metody tworzenia tych rozwiązań powodują, że obserwujemy ciągłą ewolucję. To co było super 10-15 lat temu, aktualnie jest rozwiązaniem archaicznym. Trochę tak jak byśmy przesiedli się z samochodu na konia. Podobna skala zmian.

Kiedyś oprogramowanie nie było integrowane między sobą. Dokumentacje w mrokach dziejów znikają, a ciągły rozwój tych głównych dla danej firmy systemów powoduje, że najstarszy góral nie wie co tam w końcu siedzi. Prawda jest taka, że wiele z systemów chociażby klasy CRM jest nie do ruszenia. To co można zrobić, to spróbować wypuścić interfejsy i jakoś się integrować. Mniej lub bardziej inteligentnie. Pod spodem ciągle będą te archaizmy.

Rozwiązań jest kilka. Taki bardzo rygorystycznym jest oczywiście zaoranie, zasypanie solą i zbudowanie czegoś nowego. Tu jednak są problemy natury technicznej, organizacyjnej, a czasami i nawet prawnej.

Wyobraźcie sobie, np. zastąpienie systemu do zarządzania dostawami w obrębie łańcucha dostaw, który obsługuje 500 fabryk na całym świecie. Można robić to stopniowo i przepinać systemy po kawałku, można zrobić to jednym cięciem i obserwować jak świat zaczął płonąć. Na końcu jeszcze się dowiemy, że poprzedni system w jednym z IFów miał zaszyte, że jeśli Bangladesz to paczka musi mieć opis „B”, a reszta świata ma „A”, bo tam jest takie prawo i tego wymaga.

W jednym zdaniu. Złożoność tego jak działa aktualny soft w dużych firmach, koszty jego zmiany, czy nawet rozszerzenia, w porównaniu do korzyści krótko terminowych. Kurczę. Może się nie opłacać. Wprowadzić sporo zamieszania.

Z drugiej strony jest konieczność optymalizacji. Taka potrzeba mówiąca o tym, że jeśli mamy 100 ludzi przepisujących dane między systemami, to może byśmy chcieli ich mieć 10? Dlaczego by nie? Idziemy z tym do IT i mówią, że kosztować to nas będzie tyle ile płacimy tym ludziom przez 3 lata, tak, żeby zrobić to po bożemu. Jaka jest konsekwencja? Nie robimy i trzymamy 100 ludzi przez 5 lat. Tak mniej więcej to wygląda w korporacjach.

Co to RPA?

Kiedyś o tym pisałem. Tutaj.

Teraz poklikałem nieco w soft, ciut poczytałem i jestem mądrzejszy.

Zacznijmy od kosztów.

Sam soft nie jest szczególnie drogi. Przy wyborze, warto spojrzeć na to ile kosztuje licencja, jak wyglądają rozszerzenia, czy można dodać coś od siebie, np. kawałek kodu w C# lub Java, czy jest integracja z różnymi API, co to pozwolą nam rozszerzyć moce robota o dodatkowe fajne tematy.

Implementacja też nie jest jakoś szczególnie kosztowna. Dobrze by było mieć serwer, który posiada trochę wolnego procesora i RAMu, ale nie koniecznie. RPA robione za pomocą chociażby UiPatch, można odpalić na maszynie wirtualnej. Powiedzmy, że kupujemy sobie dobrego MacBooka i stawiamy na tym parę maszynek. Będzie zasuwać.

Prawda jest taka, że z tą maszyną Jabłka to żartuję. RPA działa na maszynie klienckiej. Ta widoczna część jego pracy to dosłownie klikanie po okienkach. Zaznaczanie, kopiowanie, wklejanie. Cała robota sprowadza się do tego, że zastępujemy żywego człowieka maszyną. Brzmi w zasadzie fajnie. Kosztuje jednak zasoby. Maszyna może klikać bez przerwy i ciągle wykorzystywać zasoby sprzętowe, ergo trzeba mieć dobre maszyny.

Pod spodem oczywiście mamy normalną obsługę baz danych, możemy podpiąć sobie plik płaski, ściągać dane z API. Bardzo nowocześnie to wygląda. Ba, napiszemy kawałek kodu w jakiś fajnym języku, żeby się wykonał.

W wielkim skrócie, dostajemy klikadło, które zmniejsza koszt produkcji programu. Chciałbym być w pełni uczciwy wobec wszechświata. To nie jest rewolucja. To wszystko da się robić conajmniej od 10 lat. Teraz dzieje się to prościej. Wizualnie, bez konieczności pisania kodu. UiPath ułatwia życie. Chwała mu za to. Dzięki temu zawód programisty za jakiś czas będzie tańszy. Nie, żebym płakał, chociaż trochę tak jest. Kiedyś była klasa Java.Robot, teraz jest ładne GUI.

Co nam UiPatch daje?

Trochę o tym było powyżej. Sam soft, z wbudowanymi elementami daje nam bardzo podstawowe narzędzia. Niech jednak nikogo nie zwiedzie to, że są podstawowe. Można bardzo dużo dzięki nim zrobić i do większości zadań nie będzie potrzeba korzystania z rozszerzeń, nawet nie trzeba znać się na programowaniu! Trzeba trochę logiki i może zrozumienia BPMNa?

  1. Pętle
  2. Połączenia do źródeł danych
  3. Obsługa peryferii
  4. Odczyt i zapis do plików
  5. Podstawowa integracja z API
  6. Bramki decyzyjne
  7. Obsługa zmiennych
  8. Podstawowe komendy systemowe
  9. Obsługa kolejek
  10. Obsługa wyjątków

W ogromnym skrócie tyle.

Nie wnikając w detale. Tyle wystarczy do postawienia robota i patrzenia jak sobie radzi na ekranie. Możemy na podstawie informacji z bazy danych, zakolejkować przeniesienie informacji z systemu „A” do systemu „B”, gdzie robot zacznie od pobrania informacji, wrzucenia ich w kolejkę, klikania między „A” i „B” i zwracania komunikatu do bazy, co udało mu się zrobić z danym rekordem. I tak kolejka może biegać sobie do zakończenia rekordów w bazie, ustawić robota w stan oczekiwania, żeby co jakiś czas sprawdzał, czy to prawda, że w bazie nadal pusto.

Jak wygląda sama praca?

Polecam oczywiście ściągnąć sobie wersję Trial i samemu zobaczyć jak się pracuje.

W wielkim skrócie. Rysujemy proces. Najpierw korzystamy z gotowych bloków logicznych, żeby zaprojektować przepływ pracy w naszym robocie. Najczęściej będziemy pobierać jakieś dane, potem otwierać docelowy program o ile już nie jest otwarty i coś na nim robić. To wszystko zapętlamy do wyczerpania rekordów. Zakładamy w międzyczasie na kolejnych krokach obsługę błędów i jeśli potrzebujemy to zwrotek np. do bazy danych.

Oczywiście nie jest to trudna praca. Wymaga jednak tego, żeby usiąść do tablicy i narysować przepływ pracy, zrobić rozsądne kroki, odpowiednio zamodelować wejścia i wyjścia. Cóż, dostajemy do zrobienia taką w pełni techniczną pracę polegającą na dobrym zaprojektowaniu procesu.

Jak już mamy ogólny obrazek to wchodzimy w detale każdego z kroków. W podobny sposób możemy zagnieździć w nim elementy logiczne, które pozwolą na kontrolę przebiegu procesu. Wszystko dzieje się za każdym razem w ten sam sposób. Przeciągamy klocki i układamy je w odpowiedniej kolejności na ekranie. Reagujemy na wejście i wyjście, zakładamy działania związane z samą logiką procesu.

Fajnym i jednocześnie archaicznym rozwiązaniem jest obsługa peryferiów w postaci myszki i klawiatury. Możemy ustawić kursor w miesjcu o współrzędnych X:Y i kliknąć. Przydatne jeśli w kontekście danego okna nie możemy zidentyfikować elementu formularza i automatycznie z niego skorzystać. Wtedy pozostaje metoda bardzo tradycyjna czyli kliknęcie. Oczywiście nie polecam jako rozwiązanie idealne. Wręcz przeciwnie, raczej jako zło konieczne. Niemniej da się.

Niech jednak nikogo, kto czyta ten tekst nie zwiedzie prostota opisu. Przeciąganie klocków brzmi fajnie i przyjemnie. Nic bardziej mylnego. Każdy, nawet najłatwiejszy robot to dziesiątki, jak nie setki bloków poukładanych obok siebie. To, że nie trzeba napisać IFa lub FORa, nie oznacza, że jest to trywialna praca. Wizualizacja pomaga oczywiście programiście widzieć swoje rozwiązanie oraz pracować na nim intuicyjnie. Nie zmienia to faktu, że jest to nadal praca skomplikowana, wymagająca skupienia. Oszczędza się trochę czasu, to prawda. Może popełnia się mniej błędów? Też jest to możliwe. Powiedzmy, że jest taniej o jakieś 20% czasu w kontekście pisania wszystkiego od początku do końca za pomocą zwykłego IDE.

Czy polecam programistom? Raczej tak. Interfejs jest przyjemny dla oka. Nie znalazłem wersji ciemniej. To ogromna wada. Poważnie! 😉 Liczba i rodzaj gotowych komponentów powinna wystarczyć do stworzenia mniej lub bardziej zaawansowanego robota. Sam robot pozwala się sprawnie implementować po stronie serwera czy też maszyny wirtualnej. Jednocześnie nie chcę powiedzieć, że jest to rozwiązanie idealne. Może są jakieś lepsze, mające lepszą bibliotekę „klocków”, pozwalające się lepiej dogadać z chociażby customowym kawałkiem kodu. Warto, tak czy inaczej, spojrzeć na UiPath, chociażby ze względu na całkiem niezłą dokumentację, popularność i liczbę przykładów, kursów itp. Tak dla poznania rozwiązania, nie koniecznie, żeby się specjalizować w nim.

Co to oznacza dla biznesu?

Myślę, że jedną fajną rzecz. Do korzystania z UiPath, nie trzeba być programistom. Konieczna jest znajomość podstaw projektowania oprogramowania, raczej dobra znajomość notacji BPMN, przyda się też trochę wiedzy na temat baz danych i organizacji informacji w nich. Czy coś ponad to? Nie bardzo.

Nie musisz być programistom, który zasuwa na co dzień w czarnym IDE, żeby zrobić robota. Przynajmniej takiego prostego.

Wiedza techniczna jest oczywiście istotna i bez niej może być trudniej, ale bez przesady.

Może to skutkować, a przynajmniej powinno, utworzeniem po stronie biznesowej, jednostek produkujących RPA na potęgę. Ma to ogromne konsekwencje organizacyjne. IT może zajmować się „grubą” integracją, czy tworzeniem rozwiązań docelowych. Taka z resztą powinna być ich rola.

Biznes jako taki, szczególnie ten projektujący procesy, może w trakcie kolejnych zmian, spojrzeć na to co stworzył i spróbować własnymi, trochę wyspecjalizowanymi rękami, odciążyć organizację od pracy ludzkiej.

Ostatecznie kto jak nie ludzie od procesów wiedzą co jest czynnością powtarzalną, którą może w ten sam sposób co człowiek, zrealizować robot? Przynajmniej tak powinno być.

Jeśli teraz czyta mnie ktoś kto zajmuje się w swojej korporacji procesami, to niech chwilę się zatrzyma. Jeśli w ostatnim półroczu stworzyłeś proces, który wymaga ludzi do czytania danych z systemu lub pliku i za pomocą prostego algorytmu karze im coś kliknąć, wkleić lub napisać, to zastanów się czy nie popełniłeś/łaś błędu. Ten proces można zaadresować w RPA, dzięki temu uwolnić część zasobów, a nie oszukujmy się taki jest cel optymalizacji. Nie mówię i wyrzucaniu ludzi z pracy. Dajcie im ciekawszą robotę, taką, gdzie bezduszna maszyna nie powinna być decydentem. Coś na tyle złożonego, że algorytm jest zbyt trudny do wyjaśnienia w kilku zdaniach.

Zupełnie poważnie mówię też o odseparowaniu się od IT i stworzeniu w ramach struktur biznesowych zespołu, który optymalizuje procesy w ten właśnie sposób. Taka jednostka w jednej osobie mogłaby odwiedzać zespoły operacyjne, tworzyć RPA i całkiem nieźle bawić się w pracy. Doświadczenie mówi, że zespołu IT mają inną percepcję na jakość. Nie mówię, że jest źle. Dla IT jest dobrze jeśli program zachowa się zgodnie z założeniem. Jak ma strzelać błędem to niech strzela. Dla biznesu ważniejsza jest efektywność procesu. To ile się przetworzy pozytywnie i ile dzięki temu zaoszczędzimy w dłuższej perspektywie czasu. Dlatego też kawałek biznesu, będący blisko operacji i procesów i jednocześnie produkujący RPA jest świetnym rozwiązaniem. Taka przyszłość na najbliższe 5-6 lat.

Kurczę, czytam to co napisałem powyżej i zaczynam się zastanawiać czy nie powinienem jednak wyjść z baz danych i robienia projektów i jednak iść do konsulting. Spokojnie boss, jak pomysł dojrzeje w mojej głowie to dam znać wcześniej 😉

To jeszcze raz, po co?

Bo szybciej i taniej niż grube rozwiązania IT. Istotny jest czas implementacji. Pobieżne przyjrzenie się UiPatch pozwala mi sądzić, że proste procesy (tak około 100 bloków) można zaimplementować w granicach 2 tygodni pracy programisty. W praktyce jeden sprint pozwala dostarczyć jednym człowiekiem jednego robota. Na upartego można stwierdzić, że jedna osoba, miesięcznie dostarcza dwa rozwiązania. I to z testami, pełną implementacją, poprawkami w kluczowych miejscach, dowiezieniem efektywności na akceptowalnym poziomie. po stronie technicznej E2E w dwa tygodnie? Spokojnie się da. Nawet jeśli były by to dwa sprinty, gdzie drugi to stabilizacja i optymalizacja, to nadal po dwóch tygodniach mamy działające rozwiązanie, które tylko szlifujemy. W perspektywie wdrożeń IT trwajacych miesiącami, to jednak robi wrażenie.

Popatrzmy na koszty i zyski.

Koszt jednostkowy:

– 0,4 pensji dewelopera -> jakieś 4 tys. brutto

– maszyna wirtualna -> jednorazowo ok. 5 tys. za fizyczną maszynę, czyli około 1,5 tys. za wirtualną, na której pracuje robot

Zyski:

– minimum 2 etaty, żeby się opłacało -> powiedzmy, że 8 tys. brutto jeśli nie płacimy zbyt dużo za pracę w backoffice

– zwiększenie efektywności pracy (robot nie je, nie śpi, nie pije kawki i wyskakuje na fajka, na L4 też nie wyskoczy)

– zmniejszenie błędów, a to skutkuje zmniejszeniem reklamacji, wzrostem morale w firmie, wzrostem satysfakcji klienta końcowego

Można powiedzieć, że jeden robot zwraca się w najgorszym przypadku po dwóch miesiącach pracy. Potem tylko zarabia na siebie. Nie trzeba go dotykać, karmić (oprócz prądu), w ogóle można o nim zapomnieć. Warto zaznaczyć, że dobra metoda to rozpoczęcie robotyzacji od dużych wolumenów. Jest to rzecz jasna oczywiste, chyba?

 

Wypada w tym momencie skończyć. RPA jest świetną choć nie nową technologią, która usprawnia procesy biznesowe oparte o wiele, niezintegrowanych systemów. Otwarcie trzeba przyznać, że bilans zysków do kosztów może być imponujący, a sama szybkość implementacji rozwiązania potrafi zawrócić w głowie.

Nie można jednak polecić tego wszystkim. Zdecydowanie jest to rozwiązanie dla firm mających kilka systemów, których wymiana na nowsze technicznie wersje jest droga, posiadają wiele zespołów backoffice i konsekwencją tego jest nie akceptowalna skala pomyłek popełnianych przez człowieka lub czas trwania procesu E2E. To nie jest i nigdy nie będzie sensownym rozwiązaniem dla małych firm, z niewielką liczbą systemów i procesów manualnych. Po mimo stosunkowo łatwej implementacji i niskiemu progowi wejścia, może nie być sensu się w to bawić. Samo posiadanie robota, tylko dlatego, że fajnie jest go mieć w firmie, nie jest sensownym pomysłem. Wiem, że na slajdzie wygląda to fajnie. Tylko po co?

Czy jest to technologia, która szybko przestanie być fajna? Uważam, że nie. Z perspektywy korporacji jest to stosunkowo nowy sposób myślenia o budowaniu procesów. Na tyle świeży, że dopiero powstają zespoły robiące RPA, na tyle popularny, że mówi się o tym na zebraniach mądrych głów. Jeśli w przeciągu najbliższych kilku lat, nie znajdzie się ktoś kto wymyśli dobrą i tanią metodę migracji ze starych systemów informatycznych do nowoczesnych rozwiązań to z RPA będzie chleb conajmniej przez dekadę. Oczywiście AI może zjeść kawałek tego chlebowego tornu, ale RPA zawsze będzie tańsze niż AI. Tak to widzę.