RegułyChaosu

Gdyby Straton z Sardes żył współcześnie, nie zaś prawe dwa tysiące lat temu, mógłby zmienić swój epigram. Rzecz o RPA (ang. Robotic Process Automation), najnowszym trzyliterowym skrócie, którym – jak chyba każdym nowym, trzyliterowym skrótem – zachwyca się część branży „informatycznej”, zachwytem napędzanym budżetami marketingowymi uznanych dostawców technologii. Fajna, nośna koncepcja, tylko to wykonanie…

Rozumiejąc reguły rządzące rozwojem Wikipedii, można z dużą dozą pewności przyjąć, że – w odniesieniu do nowych technologii – daty rozwoju opisu terminu w Wikipedii odzwierciedlają oś czasu rozwoju tego pojęcia. Wpis o RPA w Wikipedii zainicjowany 27 sierpnia 2015 r. W ciągu zaledwie trzech lat doczekaliśmy się wielu platform RPA, mamy już ekspertów od RPA, akademie RPA, a nawet konferencje wymiany doświadczeń z RPA z udziałem obcokrajowców (skoro obcokrajowiec, to bez wątpienia wiele w tej sprawie zrobił). No cóż… Sama koncepcja RPA, czyli zrzucenie na jakieś oprogramowanie realizacji czynności powtarzalnie wykonywanych na aplikacjach takich jak CRM czy ERP, jest świeżym, twórczym rozszerzeniem wykorzystywanej już wcześniej techniki, użytkowo znanej pod nazwą „makra w Excelu” – zarejestrowania sekwencji działań (na jednym arkuszu kalkulacyjnym) i umożliwienia odtwarzania jej w nieco zmienionych warunkach (na innym arkuszu kalkulacyjnym, jednak o odpowiednio adekwatnej strukturze). Taka technika znalazła szerokie zastosowanie w automatyzacji testów graficznych interfejsów użytkowników. Do takiej koncepcji można dojść zaczynając z różnych miejsc – od „ciężkiej integracji” (np. webMethods), integracji desktopowych (np. Jakada), czy wspomnianych już środowisk automatyzacji testów (np. Selenium). Każdą z tych ścieżek dostrzeżemy u dostawców „technologii RPA”, różniących się feature’ami – pochodnymi punktów wyjścia sprzedażowej podróży do koncepcji RPA. W przytłaczającej większości „platformy RPA” są więc starymi gratami, dla których znaleziono nowy kontekst. Podróże te często oferują przeróżne legendy (np. client-side vs. server-side RPA) uzasadniające taki czy inny wybór.

Anatomia RPA

Dlaczego RPA może być przydatne? Potrzebujemy RPA, bo nie umiemy zautomatyzować działań powtarzalnych przy użyciu dostępnych narzędzi? Dzięki RPA jest taniej? Czemu ma służyć – zastąpieniu „przeklepywania” danych z jednego systemu do drugiego (prosta i tania integracja)? Zatwierdzania dokumentów w obiegach elektronicznych (skoro automat, to taki punkt decyzyjny jest zbędny, czyli błędny proces)? Raportowania wystąpień określonych zdarzeń w ramach biznesu firmy? W praktyce do tego właśnie sprowadzają się wdrożenia i – mimo ekspertów, akademii i konferencji – nie ma doświadczeń z RPA wykraczających choćby na krok w świat wspomnianych wcześniej legend. Są jednak doświadczenia z tych przeprowadzonych już wdrożeń i sprowadzają się one do kilku elementów:

• Prowadzenie współczesnego biznesu jest coraz bardziej chaotyczne. Wielu obszarów działania nie da się oprzeć o procesy biznesowe (w znaczeniu BPMN), bo charakteryzują się za dużą zmiennością – daje się jednak skutecznie działać w tych obszarach opierając się o odpowiedzi na zdarzenia.
• Stosowanie automatyzacji opiera się o pewność działania robota, a ta zależy od jakości i wiarygodności danych. Słaba jakość danych jest poważnym ograniczeniem stosowania automatyzacji.
• Bardzo łatwo jest przygotować prototyp robota, który będzie poprawnie działać w określonym scenariuszu. Niezwykle trudno jest przygotować robota, który będzie poprawnie działał w warunkach rzeczywistych (wyjątków, wariantów, niepewności danych).
• W rzeczywistych problemach relatywnie szybko trzeba przejść z techniki „nagraj makro” do środowiska pracy na kodzie programu robota. Niesione na sztandarach “no code” kończy się bardzo szybko, a jego używanie w analogicznym tempie nabiera cech działań magicznych (w znaczeniu braku możliwości odróżnienia odpowiednio zaawansowanej technologii od magii), niezrozumiałych dla użytkownika.

Brzmi to jak niezłe pole do stymulowania konfliktu między biznesem („Potrzebuję!”, „Nawet zrobiłem prototyp – wystarczy go wdrożyć!”) a przedstawicielami IT. RPA ujawnia słabości wcześniejszej kultury użytkowania IT w firmie. Jeśli firma charakteryzowała się dbałością o jakość danych, użytkowanie RPA jest możliwe – w przeciwnym wypadku zaczyna się poszukiwanie winnych tak straszliwych zaniedbań…

W swej esencji RPA jest techniką integracji, przy czym podstawowym środowiskiem jej działania są graficzne interfejsy użytkownika. Integracja nie jest w żadnym wypadku łatwym zadaniem, a już integracja „przez GUI” w szczególności, pamiętając o tym, że żadna z aplikacji posiadanych przez firmę nie była tworzona z myślą o zapewnieniu możliwości wykorzystania robotów. Obietnica RPA brzmi jednak tak: „będziecie mogli działać na każdej aplikacji i będzie to wiarygodne” – w teorii komunikacji marketingowej nazywa się to overpromise. OK, zakładając, że mamy cudowną (ale nie magiczną) technologię automatyzacji, czy nawet „integracji procesów”, to chcąc przy wykorzystaniu RPA realizować zadania wykraczające poza „wyślij mi maila, kiedy przyjdzie faktura do akceptacji”, kilka zagadnień wymaga poważniejszego poraktownia.

Mniej zamieszania

Zagadnienie odpowiedzialności: w czyim imieniu, na czyich uprawnieniach działają roboty? Kto ponosi odpowiedzialność za efekt ich działania? Konkretni użytkownicy, niebędący inżynierami, piszą na swoje potrzeby makra ułatwiające im pracę przez wykonywanie ich w analogicznych sytuacjach. Biorą za to pełna odpowiedzialność. Kto odpowiada za efekt biznesowy makra nagranego przez jednego użytkownika i udostępnionego innym? Co się stanie, kiedy akcje wykonywane prze robota zostaną zinterpretowane „źle” – przy czym „źle” nie musi oznaczać błędnie, bo może to być dokładnie zgodnie z logiką działania aplikacji?

Zagadnienie warunków pracy: jakie warunki działania robota musza być zapewnione? Wszak nie w metodach działania (integracja vs. RPA) sprawa, lecz w otoczeniu tych działań. Rzeczywiste dane są przetwarzane w warunkach dużej złożoności i chaosu, zmienności i niespójności, wariantów i wyjątków. Na to otoczenie RPA nie pomoże, ale musiałoby w nim działać. Jak musiałyby zostać przygotowane aplikacje , na których miałyby działać roboty, aby zapewniały stabilność warunków pracy?

Zagadnienie pragmatyczne: jak dowodzą doświadczenia, w każdym przypadku, kiedy „zwalamy robotę na innych” przykładamy mniejszą wagę do jakości tego, co robimy. Skoro możemy niskim kosztem „kimś” uporządkować, to po co się wysilać na pracę w warunkach porządku? Czy w konsekwencji RPA uznamy, że mamy mandat do zwiększenia niechlujstwa? Niestety, za każdym razem, kiedy tego typu przemiana ma miejsce okazuje się, że nie zwiększa się produktywność – robimy tyle samo, co poprzednio, a wysiłek narzędzi idzie na porządkowanie po nas „sytuacji po”.

Ergo

Może więc niech RPA robi to, co miało robić – automatyzować powtarzalną pracę pod kontrolą autora robota i na jego odpowiedzialność? Otoczenie biznesowe firm ewoluuje. Coraz większa część działań rutynowych nie będzie się opierać na procesach (zdeterminowana sekwencja przyczyn i skutków), a na interakcjach (odpowiedź na zdarzenie). Jeśli ku temu zmierza świat, to cóż począć, trzeba się dostosować, tylko pamiętając o wszystkich aspektach, nie tylko narzędziu do uruchamiania robota.

Pomimo całego szyderstwa – zarówno tego powyżej, jak i innego nasuwającego się – trend jest jasny. Zmierzamy ku rzeczywistości, w której umiejętność programowania, a przynajmniej myślenia w reżimie programowania, staje się umiejętnością fundamentalną. W sumie to przecież tylko język komunikacji z innymi bytami, w tym przypadku nie Homo sapiens, prawda? To taka właśnie umiejętność powinna być fundamentem działań w sferze RPA.

Na dzisiaj mamy już ogólne pojęcie, czym jest privacy by design i czym może zaskoczyć, jednak – pragmatycznie – na czym powinniśmy się skupić, być świadomymi podczas prac projektowych, być wyczulonymi lub wręcz podejrzliwymi? Innymi słowy, jak odnaleźć te dane, które powinniśmy traktować ze szczególną pieczołowitością?

Miałem przyjemność uczestniczyć niedawno w Warsaw Alfresco Day, w czasie którego George Parapadakis snuł opowieści o przygotowaniach do RODO – na przykładach. Zaczął od „ankiety” wśród uczestników, na ile – w ich opinii – reprezentowane przez nich firmy są przygotowane i będą do 25 maja 2018 r. Moim zdaniem w tej ankiecie zabrakło jednego pytania: „Ile osób spośród państwa uważa, że absolutnie nikt nie będzie gotowy do RODO?” Mimo badań twierdzących inaczej, w odpowiedzi na takie pytanie ja podniósłbym rękę. Dlaczego tak uważam na przykładzie jednego z wymagań stawianych przez RODO / GDPR, Privacy by Design.

Zaznajomieni z tematem RODO / GDPR wiedzą, że jednym z wymogów formalnych wprowadzanych przez tę legislację jest obowiązek stosowania privacy by design i privacy by default. Legislacja nie określa jednak, czym są te terminy. Rzecz jasna, Internet oferuje wiele stron odnoszących się do tych terminów, ale na pytanie „to co mam konkretnie zrobić?” bezpośredniej odpowiedzi raczej brak. Ja potrzebowałem takich odpowiedzi. Jak więc podejść do privacy by design z perspektywy architektury?

W ramach marketingu terminu „cyfrowa transformacja” pierwsze skrzypce grają firmy technologiczne, opowiadając jak to wiele można zrobić takim, czy innym narzędziem. Zupełnie nie o narzędzia to chodzi. Bez wątpienia, w Digital Transformation jest dużo Digital, ale – nawet jeśli potężne – Digital to tylko narzędzie, a nie cel.

Pracuję ostatnio dla firmy, która nie tyle potrzebuje cyfrowej transformacji, co błaga o nią. Firmy, choć mają osobowość prawną, nie mają jednak prawa głosu w podejmowaniu decyzji o jej losach – robią to ludzie pracujący dla takie firmy. Przyglądałem się nieco mechanizmom gaszenia potrzeb firm.

No dobrze, może trochę przesadziłem z tym odkrywaniem. Ale tylko trochę. Prowadziłem niedawno kilka wystąpień o tematyce nawiązującej do zwinności w architekturze. Poza innymi ciekawymi dyskusjami często wracaliśmy także do zagadnień SOA. Kilka myśli cieszyło się szczególnym powodzeniem.

Jest takie branżowa prawda: aplikacje się zmieniają, dane pozostają. Dane – ich modelowanie, sposoby przetwarzania i składowania – mają już najdłuższą historię. Wszak to, co robimy, IT (Information Technology) to praktyka przetwarzania informacji. Tym niemniej, jak pokazuje praktyka, kiedy po raz pierwszy wprowadzimy do jakiegoś systemu określoną strukturę danych, nie tylko pozostaje ona taką samą, ale jeszcze ma tendencje do „infekowania” sobą wszystkiego dookoła. W takich warunkach dopasowanie jest co najmniej trudne – warunki antyzwinności.