Automatyzacja zaczyna mieć podobne symptomy jak kiedyś blockchain. To słowo może drażnić, bo pojawia się wszędzie. Teraz używa się sformułowania rejestr rozproszony (blockchain to typ takiej technologii), a jak będziemy niedługo mówić na automatyzację?
Systemy do automatyzacji procesów, spraw i decyzji
W tym artykule przedstawię dwa podejścia do automatyzacji, a jest ich dużo więcej. Pierwsze polega na wykorzystaniu systemów przeznaczonych do automatyzacji i uważam je za ciekawsze i trudniejsze. Ciekawsze, bo istnieje oprogramowanie, które w darmowej wersji jest wystarczające do pracy. Trudniejsze, bo są to systemy, w którym chcemy kompleksowo zarządzać procesami, sprawami czy decyzjami z jednego miejsca. Nie jest to już poziom prostych operacji, tylko próbujemy zastąpić człowieka przez instrukcje. Nie jest to również sztuczna inteligencja, ale częściej tradycyjny algorytm, który musimy rozpisać na wszystkie możliwe ścieżki i zdecydować, co ma się stać w każdym przypadku. Nie wyklucza to możliwości zaimplementowania AI, ale nie jest to fundament rozwiązania. Czasami będzie to w pełni automatyczna operacja bez udziału człowieka, czasami człowiek będzie zaangażowany w środku lub na końcu procesu (najważniejsze lub najtrudniejsze zadania).
Wykorzystanie takiego rozwiązania to ważny wybór, bo to kolejny system, a chcemy mieć ich mniej. Trzeba się go nauczyć, rozwijać i naprawiać. Ale może być to dużo tańsze niż rozwijanie tych samych funkcjonalności w systemach głównych (sprzedażowych, szkodowych, CRM-ach itp.). Drugą dużą wartością jest możliwość łączenia danych z różnych systemów, a podejmujemy decyzje, często pracując na wielu systemach, których bezpośrednie połączenie nie uzasadnia się biznesowo (kosztowo). Bardzo istotne jest również zrozumienie, że taki system „pracuje” na naszym głównym systemie, wykonując na nim operacje. Nie dodajemy kolejnego systemu dla konsultantów, underwriterów czy likwidatorów, ale raczej zastępujemy ich operacje przez naszego wirtualnego operatora.
Brzmi podobnie do RPA, prawda? Roboty też mogą wykonywać operacje na podstawie wielu danych z różnych systemów, również są wirtualnym operatorem. Różnica polega na sposobie połączenia. Roboty w RPA pracują na interfejsie użytkownika, czyli jak człowiek, naciskając na konkretny przycisk czy wpisując dane do konkretnych pól. To ma taką wadę, że trudne jest ich zaprojektowanie w taki sposób, aby bezboleśnie reagowały na zmiany w systemie głównym (np. ktoś przeniesie wyświetlanie danych w inne miejsce czy ukryje guzik). Systemy do automatyzacji obsługujące standardy BPMN, CMMN i DMN, o których tutaj piszę, są połączone na warstwie danych (np. przez szynę danych) i są bardziej odporne na zmiany w systemach głównych. Są też stworzone do bardziej skomplikowanych operacji niż typowe RPA.
Kocham swój system
To moje „dziecko” – to często mój produkt, który stworzyłem i zaimplementowałem, obroniłem go wiele razy, przekonałem wiele osób, przeszedłem przez działy bezpieczeństwa i compliance. To często mój ukochany, optymalny proces. To przywiązanie do swoich dzieł. Dzieł, które często stworzyliśmy w konkretnych systemach i narzędziach.
Dlatego drugim popularnym podejściem jest skupić się na jednym systemie, który tworzymy, rozwijamy i kochamy. On ma mieć jak najwięcej. Przykładem może być tu oprogramowanie Guidewire, które w Sollers Consulting mamy okazję wdrażać z największym zespołem w Europie. Niektórzy klienci nieustannie udoskonalają procesy, często posiadając trzy zespoły deweloperskie tylko do rozwoju systemu szkodowego.
Może się to skończyć świetnie funkcjonującym organizmem, w którym taki system sam dokonuje wypłat, sam wysyła wiadomości do klientów, sam interpretuje dane przez nich przesłane. Przyjmuje zdjęcie uszkodzonego auta, jest połączony z silnikiem interpretującym zakres uszkodzeń na podstawie zdjęć (np. Tractable, Audatex, Control Expert), przesyła je do kolejnego połączonego systemu, który określa kosztorys naprawy. Następnie nasz ukochany system na podstawie konfigurowalnych przez siebie zasad ocenia, jaką kwotę ugody zaproponować klientowi, i przesyła mu propozycje.
W takim scenariuszu kluczowe jest utrzymanie wysokich kompetencji do tego systemu w organizacji. Na początku to ojcowie i matki tych automatyzacji będą je rozumieli i kochali, zadbają o ich prawidłową przyszłość i dobrą markę. Z czasem powinni przygotować ich do samodzielnego funkcjonowania poprzez umiejętne przekazanie wiedzy na ich temat wewnątrz organizacji. To często będzie wiedza, gdzie trzeba coś „wyklikać” lub który deweloper najlepiej rozumie pokrętną logikę, konieczną do zaimplementowania w kodzie, aby wszyscy byli zadowoleni. Zarządzanie decyzjami i utrzymywanie kompetencji nie będzie tu tak łatwe jak w przypadku silnika decyzyjnego. Raczej nie będzie tu jednego centralnego panelu do wszystkich decyzji, tylko wiele miejsc, w których się je konfiguruje. Może to wygenerować wyższe koszty operacyjne takiego systemu.
Trochę się tego nazbierało
Spójrzmy jeszcze na aspekt rzeczywistości, w jakiej staramy się automatyzować. Często w naszej organizacji mamy już wiele pozostałości po eksperymentach. Mamy już zaimplementowany RPA w paru miejscach, uczenie maszynowe też już działa, w systemach centralnych zaimplementowaliśmy mnóstwo różnych rozwiązań. Toczą się kolejne POC-e sprawdzające wszystko po kolei, bo chcemy być innowacyjni.
A teraz kolejny projekt, automatyzacja. Wygląda jak każdy inny, znów będzie wesoło. Ale to nie jest taki sam projekt. Wykonując trudne automatyzacje (do prostych mamy RPA), zastępujemy decyzje człowieka, które do tej pory wykonał na podstawie interpretacji różnych danych. Musiał przeczytać trochę dokumentów, spojrzeć w systemie w kilka miejsc lub systemów, czasami spytać kolegę czy koleżankę, co się robi w takiej sytuacji. A w innym oddziale czy regionie na podstawie tych samych danych decyzja byłaby nieco inna. Bo tam jest Roman i tam się to robi inaczej.
Drugi istotny aspekt to skala. Automatyzacja otwiera nam drzwi do masowego podejmowania decyzji. Jeżeli mają być to decyzje zwiększające nam ekspozycje na ryzyko (np. underwritingowe) czy mające wpływ finansowy (np. wypłaty odszkodowań), trzeba zrobić trochę zaworów bezpieczeństwa. Przydałoby się też wszystko bardzo dokładnie wytestować. Nie obędzie się też bez konieczności wprowadzania szybkich zmian. Błędy trzeba pilnie naprawiać, zmiany wdrażać bez zwłoki. To wymaga dobrej organizacji w wytwarzaniu oprogramowania (DevOps), elastycznej infrastruktury (np. chmura), automatyzacji w testach oraz najważniejsze – możliwości dokonywania zmian w procesach przy ograniczonym udziale deweloperów.
Firmy ubezpieczeniowe są na różnych etapach rozwoju DevOps, który wpływa na szybkość wprowadzanych zmian i awaryjność rozwiązań. Źródło: opracowanie własne
Ograniczanie lub wyłączenie deweloperów przy zmianach można uzyskać w obu podejściach. W pierwszym użytkownicy biznesowi przyswajają, jak konfiguruje się silniki decyzyjne – czyli co gdzie ustawić i wpisać. W drugim deweloperzy dbają, aby wszystko, co ważne, dało się później „wyklikać”. Tworzą tabele do zmiany parametrów, a biznes się tego uczy i umiejętnie tym zarządza. W obu można znaleźć mądrość i optymalizacje. Obie koncepcje można też wypróbować i sprawdzić, czy nadają się do naszej organizacji, poprzez umiejętne przeprowadzenie fazy POC.
Bartosz Wasilonek
Senior Consultant w Sollers Consulting
Podejście jest ważne, ale jeszcze ważniejsze są kompetencje i odpowiedni zespół. Przez ostatni rok prowadzimy projekty całkowicie zdalnie, gdzie poziom trudności znacząco się zwiększa. W szczególności dotyczy to projektów, w których jest wiele powiązań i są merytorycznie trudne. Do takich z pewnością należą projekty z obszaru automatyzacji. Często wiele zespołów musi pracować przy bardzo mocnej synchronizacji i komunikacji. Wprowadzenie skutecznej metodyki prowadzenia projektów w trybie zdalnym jest kluczowe. W takich warunkach widać też, jak bardzo metodyki zwinne zwiększają efekt. Rozwój takich kompetencji jak DevOps, umiejętności wdrażania rozwiązań chmurowych, zarządzanie jakością i automatyzacją testów czy kompetencje w zakresie zarządzania jakością danych bardzo pomagają nam w skutecznej implementacji.
Grzegorz Podleśny
Partner w Sollers Consulting
