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ę.

Duma

Muszę przyznać, że będąc przed trzydziestką i popijając bananowego Nesquik`a można dojść do ciekawych wniosków. Prawdą jest, że ostatnie tygodnie są niesamowicie intensywne i trudne psychicznie. Całe dnie na pełnych obrotach, praktycznie zero chęci do jakiegokolwiek relaksu. W zasadzie jest to typowy objaw do bycia PO projektu, który się kończy. Kurczy się czas, terminy gonią, królewski skarbiec świeci pustkami. Każdy kto robił projekty IT wie z czym to się je. Czytaj dalej Duma

O wiertarce i kosteczce

Mamy tendencję do skrajności. Zdecydowanie.

Ciężko mi odszukać w pamięci firmę, szczególnie z tych dużych, gdzie w odpowiedni sposób rozwiązywany był sposób kosztów.

Z jednej strony mamy rozdawnictwo totalne. Z drugiej oglądanie każdej złotówki. Rozumiem, że ciężko w tym wszystkim dokopać się do złotego środka. Jeśli nie kontrolujemy to popłyniemy z kosztami. Z drugiej strony nadmierna kontrola potrafi przejść miejscami poza granice absurdu. Szczególnie jeśli koszt tego o co toczy się spór jest tańszy niż godziny pracy ludzi zaangażowanych w proces.

Pozwolę sobie przytoczyć dwie zasłyszane historie jako przejawy absurdalne, skrajne i niestety z życia wzięte. Rzecz jasna nie będę rozwodził się nad tym kiedy i gdzie to się wydarzyło. Jeśli czytając poniższy tekst stwierdzasz, że jest o Twojej firmie. Cóż. Nie potwierdzę, że o niej piszę ale z drugiej strony, możesz się zastanowić.

Historia pewnej wiertarki.

Opowieść zasłyszana z pewnego źródła, że tak powiem, naocznego świadka. Rzecz miała miejsce pięknego lata na południu naszego nieszczęśliwego kraju. Pewien deweloper złapał za nogi papieża, Boga i kurę wydalającą złote jajca.

Udało mu się załapać na budowę kilku bloków na osiedlu, no powiedzmy, dla trochę zamożniejszej klienteli. Z różnych powodów mieli państwo szanowni problem z czasem. Robotę musieli skończyć szybko, więc stwierdzili, że z kosztami nie będą się liczyć.

Na budowie jak to na budowie, pracowało kilkudziesięciu panów zasuwających na dwie zmiany z taczkami. Do tego dochodził jakiś kierownik jeden z drugim. Jak to też na budowie, no cóż, czasami coś tam zniknie. A to ktoś potrzebuje kilka cegieł na działkę, trochę farby do pokoju, jakiś klej, wiertło. Nie żebym pochwalał. Taka po prostu rzeczywistość.

Budowa szła w najlepsze. Panowie pracujący dostali przyrzecznie, że niczego im do pracy nie zabraknie. Jak by co się stało to dawaj do mnie, jadę do sklepu, kupię, będzie nówka sztuka.

No to chłopcy początkowo nieśmiało. Zagadali o łopatę, potem o jakieś kielnie. Tak od słowa do słowa stwierdzili, że no kurczę, ja proszę, on lata. Przynosi nowe w folii, o nic nie pyta. Sprawdźmy jak to będzie z czymś mocniejszym.

Poszedł pierwszy śmiałek do majstra i mówi.

– Panie majster, wiertarka się zepsuła.

Na co majster mu odpowiada.

– Dobra, już jadę za godzinę będziesz miał nową.

Robota szła w najlepsze. Budynki się pobudowały. Stan idealny. Igła. Prosto, równo. Chłopakom żal było kończyć.

No i przyszedł taki jeden mądry i zaczął koszty liczyć.

Każdy wiedział, że coś tam musiało zniknąć.

Liczą, liczą. Jakieś tam materiały na działkę wzięli. Trochę narzędzi. Wydaje się być dobrze.

Aż tu nagle jak nie pieprznie grom z nieba jasnego.

Okazało się, że skoro firma hojna to i ludzie kreatywni.

W przeciągu miesiąca zużywało się około 300 wiertarek. Tak, tak. Dobrze czytacie. 300 sztuk w miesiącu. Ludzi do roboty było kilkudziesięciu. Wychodziło po kilka sztuk na głowę. Co się z nimi działo? Tajemnica. Chociaż pewnie nie wielka.

O jednej małej kosteczce

Z placu budowy przenosimy się do korporacji. Wiecie. Lider blebleble, nowoczesność w domu i zagrodzie i takie tam.

Był sobie taki, zwykły deweloper (tym razem nie budowlany). Ten z przedziału 10K. Nie za biedny, nie za bogaty ale wie co robić, jak robić i na czym.

To taki gość przed którym Jsony się kłaniają.

No i facet zasuwał w klimatyzowanym budynku. Wygodne krzesło. Pyszna kawa. Ciasteczko. Wiecie jak to jest.

Co jakiś czas task w Jirze wpadał. Popatrzył, poklikał i jest.

Dlaczego o gościu piszę? Powtarzając, o facecie z kategorii 10K.

Cóż, historia zasłyszana też od świadka naocznego.

Człowiek ów miał się projektem zająć. Jako, że znał się na robocie to nie poprosił o podwyżkę ale o to, żeby dorzucić mu do komputerka kość RAMu. Wiecie, taka mała kostka do liczenia rzeczy. Jako osoba doświadczona, wiedział po prostu, że mu maszyna nie uciągnie. Po prostu się nie da. Co tu się oszukiwać.

Poszedł do szefa.

Szef mu mówi, a weź się zastanów? Na co Ci to? Przecież to koszty są.

No to Pan programista wraca do biureczka i pracuje grzecznie. GUI się wywala. Poczta się nie otwiera ale zasuwa.

Wkurw go łapie. Do wyższego idzie.

– Panie dyrektor, taką jedną kosteczkę za dwie stówki.

– Kasy nie ma. Dasz sobie radę. Wszyscy dają to co ty wydziwiasz.

No i wraca. Zasuwa po godzinach bo musi na maszynę czekać. Dzielny jest, bardzo.

Wiecie co się stało potem drogi czytelniku. Programista 10K stał się programistą 15K w innej firmie. Dostał i7 w maszynie, kosteczek do woli, monitorek śliczny.

Co na to dyrektor i kierownik? Wiecie co? Dali sobie radę. Kupili consulting za 100 razy tyle ile kosteczka kosztowała. Projekt się zrobił. Sukces na slajdzie. Też można.

No i co?

Powyższe sytuacje są przejaskrawione do granic percepcji ludzkiego oka.

Tylko wiecie co. Tak było, nie zmyślam.

Mamy tutaj dwie różne kategorie patrzenia na koszty. Z jednej strony kompletną i bezmyślną rozrzutność. Oczywiście, połączoną z działalnością niemalże przestępczą. Choć jak to mówią „okazja czyni złodzieja”.

Z drugiej strony zupełnie absurdalny sposób radzenia sobie z kosztami czyli unikanie wydawania capexu na poziomie debilnym. Jeśli specjalista zarabiający dwie średnie mówi, że czegoś potrzebuje i kosztuje to 5% jego pensji, a do tego dasz mu to raz, a on będzie szczęśliwy przez najbliższe dwa lata. Nie bądź głupi.

Rozrzutność kontra skąpstwo. Szczerze jestem ciekaw czy macie podobne historie w swojej pamięci. Sekcja komentarzy jak zawsze stoi otworem.

 

Jak się robi RPA?

Posiadam dosyć interesującą cechę związaną z aspektami korporacyjnymi.

Cechę. Hehe… no nie jedną. Raczej taki zestaw.

Po pierwsze jestem cholernie leniwy. Tak. Jeśli mam dwa razy zrobić dokładnie to samo, a nie jest to parzenie kawy to mnie trafia w środku. Stąd szybko opanowałem Crona. Good bless Linux.

Duo. Jestem ignorantem. Nie lubię bawić się małymi i nie istotnymi rzeczami. Wolę tematy, które są duże. Nie chodzi tutaj o to, że lubię spijać śmietankę z dużych projektów. Raczej, nie lubię poświęcania czasu na małe rzeczy. Podobno jest taka zasada, że 10% tematów przynosi 90% zysków. Chyba tak jest, może proporcja inna. Nie ważne.

Trzecie. Przecież ja jestem programistą, dobra bardziej analitykiem niż programistą. Nie ważne. Po mimo wszystko wolę jak się do mnie mówi Jsonem niż durnym korpomailem.

Na koniec dochodzi do tego, że ja jednak kumam ten biznes. Wiem, że trzeba zarabiać, a to się robi na różne sposoby. Niekiedy trzeba uciąć gałąź, która przynosi największe straty. Można też wzmocnić stronę, która będzie przynosić najwięcej złotówek. Różnie można.

Co dalej. A RPA z tytułu.

Znowu się rozgadałem…

Dobra. Dam Wam przepis na wdrożenie robotów RPA w Waszej firmie. Przepis jest gratis.

Zaczynacie od znalezienia w firmie lub poza nią 2-3 deweloperów. Wybieracie ludzi komunikatywnych. Gburów odrzucacie. Dlaczego? Bo ten człowiek nie ma siedzieć w flanelowej koszuli i zasuwać na klawiaturze tylko pozwać Wasze procesy, gadać z operacjami i mając doświadczenie jako programista dodać kilka groszy do projektu. Ma pomóc liderowi projektu to wszystko rozwinąć.

Potem wybieracie kilka takich chamów jak ja. Dajecie im raport z czynności manualnych. Kilka dni na poagregowanie i ruszenie dupska do operacji. Tak to ma wyglądać. Wsadzacie w auta ludzi, którzy usprawniają sobie każdy kawałek pracy, olewają drobnicę, znają się na biznesie i potrafią gadać z deweloperem jak z kolegą ze szkolnej ławki. Oni mają za zadanie pojechać, napić się wódki z ludźmi, pogadać z nimi, zaskarbić sobie sympatię i poznać ręczne procesy.

Taki człowiek jak sobie 2-3 dni poogląda co to się tak naprawdę robi w ekipie operacyjnej to będzie miał dość. Dajcie mu przetrzeźwieć, potem pozbierajcie w kupę nagrania, zdjęcia i wnioski.

Pozbierane w kupę spostrzeżenia tego biednego włóczykija wysyłacie do dewelopera. Chłopaki i dziewczyny siadają razem i robią robota. Ciągle korygują się z operacjami. Taki Agile. Dosłownie.

Wiecie co z tego dostaniecie?

Jakieś 70-80% procesu szybsze o 70-80%.

Mało?

Dajcie chwilę na rozpracowanie deweloperom tematu.

Operacje znajdą za chwilę błędy i podrzucą co by tu jeszcze można było zrobić.

Biedny PO z nudów zajmie się kolejnymi wymaganiami, żeby uwolnić następną grupę ludzi od roboty głupiego.

Wiem. To wszystko brzmi bardzo trywialnie. Jak dobra zabawa.

Pod spodem oczywiście jest kasa. RPA ma proste zadanie. Ma minimalizować koszty. Każdy rekord przerobiony przez RPA będzie zrobiony lepiej. Będzie tańszy. Lepszy jakościowo. Zawsze na czas. Nie będzie zależny od humorków, pogody, katarku.

Co będziesz musiał jednak mieć?

Oczywiście narzędzie. Jakiś soft. Nie wiem, nie znam się jeszcze na tyle, żeby powiedzieć, że A jest lepsze od B. Nic nie polecę.

Równie ważne jest to, żeby mieć odpowiednich ludzi. Przykro mi. Jeśli myślałeś, że kupisz kilku ludzi i będą sobie siedzieć i dziergać to się mylisz. Musisz każdemu z tych deweloperów i PO płacić. Coraz to lepiej. Może i z każdym zakończonym sukcesem jakaś małą podwyżka? Stówka więcej? Może premia? Po kwartale dasz im 5% zaoszczędzonej kasy do podziału? Nie istotne jest jak. Najważniejsze, żeby doceniać tych ludzi finansowo. Inaczej wrócisz do szukania na rynku lub robótek ręcznych. Co wolisz?

Z RPA mam coraz to lepsze doświadczenia. Uczę się tej technologii, zrobiłem dopiero 5 robotów. Przynajmniej w roli tego PO co to wymyśli i mówi jak ma być, a niekiedy wjedzie do dewelopera i powie mu, że ma inny pomysł i zrób to tak.

Po kilku miesiącach widzę wiele plusów. Ogrom. Głownie od strony jakościowej i kosztowej. Wszak jakość to i koszty. Jak by nie było.

Czy warto?

Nie zawsze. Jak masz małą firmę to Cię koszty zabiją.

Sensowne jest robienie jednego robota dla zadań co najmniej 1 osoby w skali miesiąca. Musisz pooglądać i policzyć. Robot będzie robił za darmo przez cały rok. Raz musisz zapłacić PO i deweloperowi potem już czysty zysk. Dla mniejszych zadań? Na upartego można.

Jakieś rady na początek?

Pamiętaj, że robot może trafić na coś z czym nie da sobie rady. Miej plan na obsługę błędów.

Maszyna wirtualna może się wywalić. Komunikacja zepsuć. Pamiętaj o monitoringu i planie awaryjnym. Bez tego nawet nie zaczynaj robotyzacji. Nie dojrzałeś do tego jeśli myślisz, że wszystko będzie super.

Małe rzeczy! Z tym oglądaniem procesów, wybieraniem największego i zwalnianiem piętra ludzi to żartowałem oczywiście. Zacznij od czegoś małego. Daj organizacji miesiąc, może dwa na naukę. Niech zrozumieją jak to działa. Co się może zepsuć. Nie licz na to, że będzie to koparka. Kupię, wsadzę człowieka i będzie kopać. Dojrzej.

W sumie tyle. O RPA na pewno będę jeszcze pisał. Temat jest dla mnie czymś ciekawym. Nie jest to AI, raczej całkiem nieźle zrobione algorytmy decyzyjne, które biegają po ekranie i udają, że się znają.

Bawcie się dobrze.

O co chodzi z tymi taczkami?

Mogę śmiało powiedzieć, że w prowadzeniu biznesu nie mam doświadczenia. Nigdy nie nazywałem się firmą, nie miałem spółki. Jakoś tak wyszło. Za to zrobiłem kilkadziesiąt projektów. Większość z nich była projektami umocowanymi w IT. Z tym to ja mam doświadczenia. Często w roli żagla, steru i okrętu. Teraz nieco mniej. Product Ownerem jestem. Wiem, słabo, nudno i w ogóle jakoś tak nie fajnie. Szkoda.

Do rzeczy.

Biznes jak i każdy duży projekt to coś co się zaczyna i w sumie to nie kończy. Ciągle coś dorabiamy, zmieniamy, koncepcje nam się zmieniają, bo przecież ciągle się uczymy. Zmienia się też rynek. Doskonali technologia. Rzeczy, które kiedyś były trudne do wykonania, teraz są jakoś tak łatwiejsze, bardziej dostępne.

Dobrym przykładem jest RPA. Przed tą technologią można było robić dokładnie to samo ale trochę trudniej. Mniej graficznie. Java.Robot. Można było.

To o czym będę teraz pisał tyczy się projektów. Odniosę się jednak do doświadczenia z rynku. Czegoś mocno oddalonego od branży, w której pracuję. Pogadam trochę o tym jak dzisiaj działają sieci kurierskie.

Mamy na rynku kilku mocnych graczy. Oczywiście Pocztę Polską. Jest też InPost i powiedzmy DHL. Kilka firm, które niby robi to samo, każda z nich trochę inaczej ale, ale. Co mnie to obchodzi? Ja jestem klient Janusz. Kupię coś na allegro i ma do mnie dotrzeć. Ma się to stać tak, żebym nie zauważył procesu. Płacę, podaję adres i czekam na SMS. Względnie sprawdzę sobie status na stronie. To wszystko.

Dlaczego wymieniłem te kilka firm przy temacie projektów długoterminowych?

Metodologia Agile mówi wprost, że nie robimy rewolucji. Działamy ewolucyjnie. Oznacza to, że robimy wolniej za to dokładniej. Skupiamy się na detalach, dopieszczamy, olewamy małe rzeczy, z których nie ma uzysku. Na koniec dnia produkt ma być na tyle dobry, żeby nie było potrzeby pokazywać jak z niego korzystać. Ma się sam bronić.

Co na to Poczta?

Wiecie co? No przecież skąd macie wiedzieć?

Poczta Polska chyba zrozumiała manifest Agile.

Jestem ich klientem od lat. Trochę z przymusu, choć ostatnio z przyjemności.

Okazuje się, ze Polska Poczta nieustannie się doskonali. Ma oczywiście niewątpliwą przewagę związaną z dostępnością placówek ale poszła o krok dalej. Dostaliśmy całkiem ciekawą hybrydę tradycji z nowoczesnością. Są kurierzy, są placówki, nadal te durne kwity awizo w skrzynce i jednocześnie SMSki. Oczywiście standardem jest to, że mamy też tracking.

Potem jest DHL i InPost. Co z tymi firmami? Weszły z fajną obsługą naście lat temu. Pokazali, że poczta może przyjść do blaszanej puszki lub Pan może do domu dostarczyć za jakieś 20 PLNów.

Poczta przez ostatnie kilkanaście lat bardzo się rozwinęła. Dostosowała się do rynku. Wdraża nowe, działające rozwiązania.

DHL i InPost? Tam się nic nie zmienia. Co gorsza, dlatego, że się nie zmienia to tak naprawdę cała obsługa marnieje. Wiem. Chatboty są. Co z tego? Ja nie chcę gadać z Chatbotem. Nie interesuje mnie jego zaawansowana integracja z systemem trackingowym czy też udawana elokwencja. No, dobra. Technicznie mnie interesuje. Ale teraz jestem klientem.

Widzisz, drogi czytelniku. Mam marne doświadczenia. DHL mnie okłamał. InPost mnie okłamał. Poczta nigdy.

Serio.

Jak to się ma do projektów?

Poczta, mam wrażanie, że tworzy rozwiązanie. Jedno, małe. Przyzwyczaja się do niego. Uczy siebie i klientów. Daje sobie przestrzeń na jakieś błędy. Poprawia je. Komercjalizuje i zabiera się za kolejne.

Co z konkurencją? Staracie się mam wrażenie zrobić takie same błędy jakie ja popełniłem w ostatnim projekcie. Chciałem mieć wszystko, szybko i dobrze. Tak to się nie da. No nie. Problem polega na tym, że dzisiaj tak się nie da. Zachowujecie się jak robotnicy, którym płaci się za godzinę. Zasuwacie z taczkami ale nic nie dowozicie. Właśnie tak mnie okłamaliście. Powiedzieliście, że będzie, nie byliście.

Proponuję Wam zrobić to co jak zrobię za chwilę. Zatrzymam się. Spojrzę na to co już zrobiłem, na to co jeszcze mam do zrobienia. Potem plany na przyszłość wrzucę na półkę. Zacznę naprawiać błędy. Pozwolę sobie na 2-3 miesiące nie myślenia o nowym tylko o tym co zrobić, żeby stare działało i nie przynosiło strat. Potem przyjdzie moment na nowe i lepsze.

Poczta to potrafi. Nigdy mnie nie okłamali.

Z tego miejsca chciałbym pozdrowić mocno zestresowanego Pana kierownika sortowni DHL z Warszawy. Jeszcze raz dziękuję, że przyjechałeś do mnie tylko po to, żeby naprawić błąd procesów w swojej firmie.

Również korzystając z okazji. Procesowcy DHLa, wstydźcie się.