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.

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.

Imperatyw dopasowania w sferze rozwoju oprogramowania zmaterializował się w postaci zwinnych metod rozwoju oprogramowania. W sferze architektury IT zwinność sięgać musi znacznie dalej – powinna objawiać się niezależnie od procesów rozwoju oprogramowania. Chodzi wszak o to, żeby nie trzeba było uruchamiać zwinnego projektu, żeby w pośredni sposób uzyskać zwinność – powinna być ona wbudowana w reguły konstrukcji rozwiązań tak, aby istnieć niezależnie od procesów rozwoju oprogramowania.

Termin „agile” zrobił zawrotną karierę. Już nie tylko proces wytwórczy oprogramowania jest zwinny – zwinne są także projekty, nawet bez komponentu informatycznego. W praktyce jednak znaczenie tego terminu jest wypaczone, wręcz wykoślawione aż do granic karykatury. Kiedy słyszę „nasz projekt robimy w trybie agile” to już wiem, że w projekcie nie do końca znany jest cel, a jego zakres jest mglisty nawet dla największych optymistów. Chciałbym, aby architekturę nie spotkał ten sam los „zwinności” karykaturalnej.

Podstawą Agile Architecture jest zdolność do użycia rozwiązania lub komponentu na nowe sposoby, nie przewidziane podczas projektowania takiego rozwiązania czy komponentu. Brzmi prawie jak herezja inżynierska – wszak informatyka to nie magiczna różdżka zmieniająca coś bez zmieniania. Jak więc uzyskać zdolność dopasowania rozwiązań informatycznych? Jak sprawić, aby architektura była naprawdę zwinna?

Wiele lat temu propagowałem zwinność (agility) na poziomie architektury, także korporacyjnej. Po latach dochodzę do wniosku, że wtedy było za wcześnie. Gospodarka była wtedy wyrozumiała, konkurencja mniejsza i presja biznesu pozostawiała IT sporo komfortu. Można było wydawać miliony na „zabawy w EA” – próbować metod i narzędzi, weryfikować w boju wizje „odtechnologiczne”. Obecne z warunków otoczenia rynkowego firm usunięto łagodność i pobłażliwość, a biznes stał się do szpiku pragmatyczny.

Przez lata spędzone w bardzo różnych organizacjach przyglądałem się sposobom działania ludzi, którzy na wizytówkach mieli napisane Architekt Korporacyjny (Enterprise Architect). Patrząc na poczynania takich ludzi – nie wszystkich, ale jednak znakomitej większości – można byłoby uznać, że EA (Enterprise Architecture) jest martwe, a podtrzymywanie EA przy życiu doprowadzi do Apokalipsy Zombie. W rzeczywistości jednak nie EA jest złe – to „metodycy od EA” sprowadzają na EA apokalipsę.