Budowa sprawnie działającego procesu scoringowego może być prosta, pod warunkiem, że dysponujemy odpowiednim narzędziem. Pośród wielu wyzwań z tym związanych, ważną kwestią jest elastyczność procesu, czyli możliwość realizacji odpowiednich procedur w odpowiednim czasie i we współpracy z odpowiednimi systemami. Rzadko kiedy możemy zupełnie uniezależnić się od systemów zewnętrznych, a jednocześnie zawsze musimy pamiętać o ryzyku, jakie one niosą oraz przemyśleć rozwiązania potencjalnie napotkanych problemów.
Jakie możliwości w zakresie elastycznego podejścia do procesów oferuje nam PS CLEMENTINE PRO 3.0? W tym artykule porozmawiamy o sposobach wyzwalania zadań oraz metodach dostosowywania procedur do wymagań biznesowych.
Automatyzacja procesów cyklicznych - harmonogram zadań
Wiele niezbędnych do skutecznego wykorzystywania modeli analitycznych procesów wymaga regularnego wykonywania rutynowych procedur. W przypadku danych pozyskiwanych z serwisów zewnętrznych jedną z takich kluczowych kwestii jest zadbanie o ich poprawność.
W ostatnim wpisie poruszyliśmy wątek pozyskiwania bieżących danych na temat epidemii COVID-19 z zewnętrznych serwisów opartych o REST API. Takie dane dla firm i instytucji związanych z ochroną zdrowia są nieocenioną wartością. Jednocześnie wiąże się z nimi szereg ryzyk. Wystarczy jedynie wspomnieć, że są one zbierane i publikowane przez setki odrębnych od siebie instytucji z całego świata, które funkcjonują w dynamicznej, intensywnie zmieniającej się rzeczywistości. W takiej sytuacji nietrudno o ludzkie błędy na różnych etapach tych działań. Zdarzają się sytuacje, gdy po kilku dniach publikowane są sprostowania do wcześniej raportowanej liczby zakażeń, która okazała się błędna. Nie sposób ręcznie weryfikować każdego dnia, czy któraś z wcześniej opublikowanych informacji nie uległa aktualizacji.
Znacznie prostsze i skuteczniejsze jest stworzenie procesu, który będzie automatycznie weryfikował poprawność posiadanych historycznych danych na temat pandemii w stosunku do tych aktualnie dostępnych na serwisie REST API . Po stworzeniu takiego strumienia wystarczyłoby utworzyć na jego podstawie zadanie wewnątrz Managera PS CLEMENTINE PRO i skonfigurować analogicznie, jak na Rys. 1. W poniższym przykładzie wybrane zadanie byłoby uruchamiane codziennie o 5:00.
Rys 1. Zadanie skonfigurowane przy użyciu harmonogramu uruchamiania
Jak widać powyżej, harmonogramowanie daje możliwości elastycznego podejścia do wykonywania regularnych procedur – od uruchamiania interwałowego (np. co 10 minut, co godzinę), przez cotygodniowe (np. we wtorki i czwartki co dwa tygodnie), po comiesięczne (np. ostatniego dnia miesiąca w czerwcu i grudniu albo w pierwszy poniedziałek każdego miesiąca).
Oczywiście tak skonfigurowane zadanie nie musi składać się jedynie z pojedynczego strumienia – realne procesy zwykle są znacznie bardziej skomplikowane i składają się z wielu etapów. Zadania w PS CLEMENTINE PRO mogą składać się z wielu strumieni, z których każdy odpowiada za osobne działania. Wykonywane są one w ustalonej w zadaniu kolejności.
Rys 2. Zadanie złożone z kilku strumieni
Wyzwalanie zadań przez web service
Powyżej wskazaliśmy, w jaki sposób zadbać o uruchomienie zadania w określonym momencie oraz jak uruchomić kilka strumieni następujących po sobie. Zadanie złożone z kilku strumieni będzie skuteczne w tworzeniu złożonych procedur, jednak ma pewien minus – a jest nim niska elastyczność. Konfigurując zadanie w taki sposób musimy na wstępie zadeklarować ustawienia parametrów z jakimi zostaną uruchomione poszczególne strumienie. Oznacza to, że w trakcie wykonywania tej procedury, nie możemy już zmienić ustalonych raz parametrów. Oczywiście nie zawsze potrzebujemy dynamicznie zmieniać wartości parametrów w trakcie trwania procesu, jednak czasem jest to bardzo pomocna funkcjonalność.
Rys 3. Okno konfiguracji parametrów uruchomienia strumienia
Załóżmy, że w ramach procesu kontroli jakości danych chcielibyśmy nie tylko weryfikować wstecznie ich poprawność, ale też oceniać, czy niektóre z danych, które otrzymaliśmy w ramach bieżącego zasilenia nie wyglądają podejrzanie. Załóżmy, że otrzymujemy z serwisu dzisiejsze dane o nowych zakażeniach w Niemczech i okazuje się, że mają one wartości ujemne zamiast dodatnich. Czy powinniśmy je bezrefleksyjnie wprowadzić do naszych systemów i używać do scoringu? Co prawda pewnie wszyscy zazdrościmy naszym sąsiadom wysokiej jakości służby zdrowia, ale chyba nawet u nich nie ma się co spodziewać takich sytuacji ;) Oczywiście dla zabezpieczenia się przed takimi sytuacjami niezbędne jest stworzenie zadania, które regularnie weryfikuje otrzymywane dane pod kątem potencjalnych błędów. Może ono np. zawierać zestaw reguł, które dane muszą spełnić, aby zostać uznane za poprawne.
Rys 4. Węzły definiujące zestaw przykładowych reguł oceniających podejrzane rekordy
Te, które nie spełniają tych reguł, są selekcjonowane a następnie przesyłane do dalszej weryfikacji w ramach kolejnego zadania. W jaki sposób? Wartości w poszczególnych rekordach zostają zastosowane jako parametry uruchomienia kolejnego zadania. Ile podejrzanych rekordów, tyle uruchomień zadania. W ramach tego zadania można dla każdego podejrzanego rekordu porównać dane otrzymane z pierwotnego serwisu z danymi dostępnymi na innych serwisach. Jeśli okazałoby się, że inne serwisy podają inne, bardziej wiarygodne dane – to takimi danymi można by było zastąpić nasze pierwotnie otrzymane informacje.
Aby uruchomić zadanie, które jest za to odpowiedzialne z odpowiednimi ustawieniami parametrów, należałoby wykorzystać możliwość uruchomienia zadania przy pomocy opcji Webservice. Umożliwia ona odebranie komunikatu SOAP lub REST, zawierającego informacje o oczekiwanych parametrach uruchomienia. Odpowiednie okna informacji o zadaniu (w Managerze) zawierają pełną specyfikację komunikatów (wraz z adresem usługi), których odebranie wyzwoli uruchomienie zadania.
Rys 5. Specyfikacja koperty SOAP umożliwiającej uruchomienie zadania dla określonych wartości parametrów
Wysłanie komunikatu SOAP do tak utworzonej usługi umożliwiają omawiane w poprzednim wpisie wyjściowe węzły PS SOAP/PS REST. Wystarczy dołączyć je na końcu naszego strumienia i odpowiednio skonfigurować.
Podkreślmy jeszcze, że dzięki wykorzystaniu parametrów zadania oraz ich dynamicznemu zastosowaniu do tworzenia komunikatów SOAP/REST, możemy uruchomić proces weryfikacyjny jedynie dla tych rekordów, które są podejrzane. Pozostałe, poprawne rekordy mogą swobodnie uczestniczyć w dalszych etapach przygotowania do scoringu. Dzięki temu nie tylko skracamy czas wykonywania procesów, ale także nie blokujemy niepotrzebnie innych procedur, co miałoby miejsce, gdybyśmy wykorzystywali jedynie „sztywne” podejście do tworzenia zadań złożonych z wielu strumieni.
Co jednak w sytuacji, gdy żaden z rekordów nie został wskazany jako podejrzany i nasz węzeł nie prześle dalej żadnego komunikatu?
Warunkowe wykonywanie kroków
PS CLEMENTINE PRO 3.0 daje możliwości bardzo elastycznego podejścia do tworzonych procesów. Na szczególną uwagę zasługują skrypty strumieni, które we współpracy z pythonowym Modeler API gwarantują bardzo dużą dowolność w sterowaniu procedurami.
Załóżmy, że w przykładzie omawianym w poprzednim punkcie chcielibyśmy rozróżnić 2 sytuacje:
- W pierwszej sytuacji zakładamy, że nasze reguły wykryły podejrzane rekordy. Zostały one następnie wykorzystane do stworzenia komunikatów SOAP, które uruchomiły dalsze zadania mające na celu weryfikację poprawności wprowadzanych danych i przygotowanie ich do scoringu.
- W drugiej natomiast okazało się, że nie wykryliśmy żadnych podejrzanych rekordów. W związku z tym węzeł PS SOAP na końcu strumienia otrzymał pusty zbiór danych, więc nie wysłał żadnego komunikatu i nie uruchomił żadnego kolejnego zadania.
Skupimy się teraz na punkcie nr 2. W takiej sytuacji nasze procedury zatrzymałyby się na tym etapie i trzeba by w jakiś sposób przekazać dalej informację o sukcesie, która uruchomiłaby kolejne działania w ramach przygotowania do scoringu. Jedną z dostępnych możliwości byłoby napisanie skryptu Pythona, który po etapie oceny regułami sprawdziłby, czy zostały wykryte jakieś podejrzane rekordy, czy nie. Jeśli nie byłyby wykryte żadne rekordy, skrypt nie wykonywałby części strumienia odpowiedzialnej za tworzenie i wysłanie komunikatu SOAP do kolejnego zadania (porównującego dane z tymi w innych serwisach - Zadanie 1 na Rys. 6), a wykonałby tylko węzeł uruchamiający zadanie następujące już po etapie weryfikacji (pomijając omawianą wcześniej procedurę - Zadanie 2 na Rys. 6).
Rys 6. Strumień wykorzystujący warunkowe wykonywanie węzłów
Jak widać, wykorzystywanie skryptów Pythona pozwala znacząco rozszerzyć możliwość działania PS CLEMENTINE PRO i dostosować system do konkretnych sytuacji i warunków biznesowych. W skryptach można odwoływać się zarówno do wartości konkretnych komórek w tabelach (a także ich atrybutów tj. liczba wierszy itd.), jak i do ustawień właściwości węzłów, do parametrów strumienia, wartości globalnych wyliczonych w trakcie procesu, ale także do wartości zewnętrznych takich jak data czy godzina. Do wykorzystania tych możliwości niezbędna jest przynajmniej podstawowa znajomość Pythona oraz Modeler API – obu z nich można się nauczyć podczas organizowanych przez naszą firmę szkoleń. Dla użytkowników, którzy nie znają języka Python, dostępna jest opcja wykonywania strumienia w oparciu o warunki, zaimplementowana na zakładce Wykonywanie w Trybie: Wykonanie w pętli / warunkowe. W tym wariancie warunki ograniczone są jednak do wartości z określonej komórki w tabeli, wartości globalnych lub parametrów strumienia.
Wprowadzanie danych za pomocą plików
W omawianej przez nas sytuacji wspominaliśmy, że w ramach procesu podejrzane rekordy są weryfikowane poprzez automatyczne porównanie danych z tymi, dostępnymi w innych źródłach zewnętrznych. Co jednak w sytuacji, gdy pozostałe źródła również podają informacje, które przez nasze reguły są uznawane za podejrzane? Co jeśli wykorzystaliśmy już wszystkie możliwości automatycznej weryfikacji, a jednak dalej nasze procesy nie mogą zaakceptować takich danych? Każdy taki system ma swoje granice – rzadko kiedy jesteśmy w stanie automatycznie poradzić sobie z wszystkimi sytuacjami. Czasem zaangażowanie człowieka jest niezbędne dla zapewnienia poprawności działania. W takiej sytuacji jak powyżej, moglibyśmy poinformować jednego z pracowników naszej firmy o podejrzanych rekordach, które wymagają „ręcznego” zweryfikowania poprawności. Ten z kolei, dysponując wiedzą ekspercką, miałby możliwość sprawdzenia tych informacji w źródłach niedostępnych albo trudno dostępnych dla systemów informatycznych, jednak możliwych do analizowania przez niego samego. Do takich źródeł należą przede wszystkim dane w nieustrukturyzowanej formie np. tekst w serwisach internetowych, obrazy czy wideo. Co prawda, istnieją sposoby maszynowego eksplorowania tych źródeł w poszukiwaniu odpowiednich informacji, jednak czasami jest to zwyczajnie nieopłacalne ze względu na różnorodność źródeł, czy po prostu na stosunkowo rzadkie wykorzystywanie tych narzędzi. Czasem po prostu lepiej przejrzeć kilka witryn instytucji publicznych, doniesień medialnych czy raportów, niż tworzyć skomplikowane algorytmy przetwarzające takie dane do odpowiedniej formy i ekstraktujące potrzebne informacje.
Po „ręcznym” sprawdzeniu takich informacji, pracownik może je wprowadzić do systemu. Oczywiście ten proces również mógłby zrealizować na wiele sposobów – wprowadzać dane poprzez parametry odpowiednio skonfigurowanego zadania, czy po prostu poprzez napisanie zapytania SQL modyfikującego odpowiednie tabele w bazie danych. PS CLEMENTINE PRO oferuje w tym zakresie dodatkową opcję, która w określonych sytuacjach może być bardzo korzystna.
Monitor Plików, bo o nim mowa, to wariant wyzwolenia zadania ilekroć w wybranym przez nas folderze pojawi się nowy plik. Dodatkowo, można dość szczegółowo określić maskę pliku, który ma wywoływać uruchomienie zadania – np. tak, aby zadanie wyzwalały jedynie pliki zawierające słowo „raport” albo rozszerzenie „.csv”.
Rys 7. Typ wyzwalania - Monitor Plików
Co więcej, można określić czy dodawany w taki sposób plik ma wziąć udział w uruchamianym procesie, czy ma pełnić jedynie rolę „wyzwalacza” zadania. Wprowadzenie pliku do procesu jest możliwe przy użyciu specjalnego typu parametru (Rys. 8). Po zakończeniu procesu można zautomatyzować przeniesienie pliku do archiwum poprzez napisanie krótkiego skryptu Pythona w strumieniu Modelera.
Wprowadzenie pliku do procesu przy użyciu parametru
Wykorzystanie tej opcji w analizowanym przez nas przypadku mogłoby przyspieszyć ręczną pracę nad wprowadzeniem danych do systemu, a także uchronić nas przed dodatkowymi błędami w trakcie tego działania. Dodatkowo już przy projektowaniu tego procesu zyskujemy pełną kontrolę nad tym, jakie procedury mają zostać wyzwolone poprzez umieszczenie pliku w określonym folderze. Nic nie stoi na przeszkodzie, aby takie proste działanie uruchomiło cały ciąg procesów, o których pracownik weryfikujący dane oraz przygotowujący plik nie musi wiedzieć i nie musi mieć kompetencji w tym zakresie. Im więcej elementów „zdejmiemy z barków” pracownika, tym bardziej redukujemy ryzyko, że do naszego modelu scoringowego trafią dane, które już na wstępie obarczone są błędem prowadzącym do niepoprawnych rezultatów.
Analizy prezentowane w tym artykule zostały zrealizowane przy pomocy PS CLEMENTINE PRO
Podsumowując – PS CLEMENTINE PRO 3.0 to system, którego głównym celem jest wspieranie automatyzacji procesów. Jego nowo zaimplementowane funkcjonalności zarówno pomagają w integracji z systemami zewnętrznymi, jak i zwiększają możliwości adaptacji procedur do skomplikowanych wymagań biznesowych. Odpowiednie połączenie poszczególnych funkcjonalności i komponentów rozwiązania pozwala na stworzenie procesów odpornych na błędy i maksymalizujących szanse na poprawne i skuteczne wykorzystanie modeli scoringowych.
