Konektory do process mining: kiedy warto z nich korzystać

Co obiecują konektory do process mining i ile kosztują?

Gotowe konektory do process mining mają zapewnić szybką drogę od systemu źródłowego do analizy: połączenie z aplikacją, pobranie danych i ich cykliczne odświeżanie. Takie rozwiązanie może się sprawdzić, jeśli konektor obsługuje dany system i odpowiada wymaganiom dotyczącym danych. Nie zawsze jednak wystarczy podłączyć go i uruchomić. Nadal trzeba sprawdzić konfigurację systemu, model danych, wymagania bezpieczeństwa oraz pytania, na które ma odpowiedzieć analiza.

Budowa lub konfiguracja konektora może wymagać mapowania pól, weryfikacji wyników i dostosowania do niestandardowych workflow lub zmian w systemie. Zespół danych może już utrzymywać sprawdzone zbiory danych, więc nowy konektor może powielać pracę zamiast wykorzystywać istniejące rozwiązania.

Konektor wymaga również bieżącej obsługi. Ktoś musi utrzymywać przepływ danych, rozwiązywać problemy po zmianach i rozumieć, jak konektor przekształca dane. Jeśli te prace opóźniają pierwszą analizę, wygoda korzystania z konektora ma swoją cenę.

Co musi zapewnić konektor

Obietnica jest prosta: wskaż system, naciśnij przycisk, pobierz sformatowane dane i ustaw harmonogram odświeżania. Gotowe. Większość pracy kryje się w tym, czego ta krótka wersja nie uwzględnia.

• System nie jest standardowy. Konektory powstają z myślą o konkretnych wersjach określonego oprogramowania, a firmy wprowadzają własne modyfikacje: dodają pola, zmieniają workflow i przebudowują tabele. System rozwijany przez dekadę nie będzie odpowiadał instalacji wzorcowej.
• Konektor ma obsługiwać wszystko. Konektor zaprojektowany z myślą o każdej możliwej analizie rozrasta się, by obsłużyć przypadki brzegowe, które nigdy nie wystąpią, a mimo to może nie odpowiadać na konkretne pytanie.
• Labirynt wielu tabel. Większość konektorów wymaga kilku powiązanych tabel źródłowych. Trzeba wtedy zrozumieć proces biznesowy, model danych konektora, model danych systemu źródłowego oraz sposób, w jaki te modele się ze sobą łączą.
• Trudno zaufać rozwiązaniu typu black box. Gdy coś przestaje działać, nie widać, co dzieje się w środku. Czy problem tkwi w danych źródłowych, błędnym przekształceniu danych przez konektor, czy w konfiguracji? Bez wglądu w działanie konektora trudno znaleźć przyczynę i wyjaśnić wyniki osobom, które mają na ich podstawie podjąć działania.
• Ogólne nazwy wymagają dodatkowego tłumaczenia. Jeśli konektor używa nazwy „Order Confirmation”, a zespół mówi „Sales Acknowledgment”, każda kolejna rozmowa wymaga wyjaśnienia, o co chodzi.

Rzeczywisty koszt

Prace techniczne również obciążają budżet, choć rzadko są uwzględnione w zaplanowanej pozycji kosztowej.

• Czas. Miesiące poświęcone na pobieranie danych zamiast na analizę.
• Pieniądze. Licencje na konektory i honoraria konsultantów za konfigurację.
• Utracone możliwości. Ulepszenia czekają, aż powstanie przepływ danych.
• Motywacja. Zespoły tracą zapał, gdy projekt grzęźnie na etapie przygotowania danych.
• Zaufanie. Gdy pierwszy projekt przekracza budżet i harmonogram, interesariusze zaczynają kwestionować wartość process mining.

Jednej z organizacji, z którą współpracowaliśmy, dostawca obiecał „pierwsze wnioski w trzy tygodnie” dzięki konektorowi SAP. Po osiemnastu miesiącach firma nadal poprawiała jakość danych. Nie zawsze tak się dzieje, ale to częsty scenariusz. Dlatego przed rekomendacją konektora pytamy o jego koszt.

Kiedy konektor się opłaca?

Konektory mogą się sprawdzić, gdy potrzebne jest częste, regularne pobieranie dużych ilości danych, a system źródłowy jest dobrze obsługiwany. Mogą być też odpowiednie w środowiskach regulowanych, gdzie organizacja wymaga kontrolowanego przepływu danych oraz ustalonych procedur bezpieczeństwa i nadzoru.

W takich przypadkach korzyść wynika z wielokrotnego pobierania tych samych danych. Konektor może ograniczyć powtarzalną pracę ręczną, o ile obsługuje konfigurację systemu i odpowiada wymaganiom dotyczącym danych.

Przed podjęciem decyzji warto sprawdzić, które wersje i konfiguracje systemu obsługuje konektor, jakie dane pobiera, jak radzi sobie z modyfikacjami i kto będzie odpowiadać za jego utrzymanie. Konektor jest przydatny tylko wtedy, gdy pasuje do sposobu pracy systemów i zespołów.

Kiedy konektor może być zbędny?

Jeśli po raz pierwszy sprawdzają Państwo konkretne zagadnienie dotyczące procesu, mogą jeszcze nie wiedzieć, jakich danych potrzeba ani czy analiza okaże się przydatna. Budowa cyklicznego przepływu danych, zanim pozna się odpowiedzi na te pytania, może oznaczać dodatkową pracę, zanim będzie wiadomo, co warto zautomatyzować.

Konektor może też obejmować tylko część procesu realizowanego w kilku systemach. Nadal może być konieczne połączenie danych, ujednolicenie nazw i weryfikacja wyników. Konektor do jednej aplikacji nie rozwiązuje automatycznie wszystkich problemów związanych z przygotowaniem danych.

Do pierwszej analizy może wystarczyć dostępny eksport, który pozwoli sprawdzić postawione pytanie. Zbiór danych można uzupełnić, gdy będzie wiadomo, czego w nim brakuje.

Nawet jeśli konektor spełnia wymagania, wiąże się z trzema kosztami:

• Powielanie pracy. Wiele organizacji ma już uporządkowane, przygotowane dane w hurtowni lub jeziorze danych. Zespół danych przez lata rozwiązywał problemy z ich jakością. Konektor zaczyna od zera i może wprowadzić niespójności względem danych, którym firma już ufa.
• Pułapka ETL. Konektory zwykle korzystają z własnych narzędzi dostawcy. Zespół musi więc poznać zastrzeżony system zamiast używać infrastruktury, którą już obsługuje i zna.
• Uzależnienie od dostawcy. Zastąpienie przepływu danych, którego budowa zajęła sześć miesięcy, jest kosztowne. Warto wziąć to pod uwagę przed rozpoczęciem prac.

Pobieranie danych w czasie rzeczywistym wpływa również na samą analizę. Przy stale zmieniającym się zbiorze trudniej ustalić punkt odniesienia, przepływ danych wymaga ciągłego monitorowania, rosną koszty obliczeń, a porównywanie okresów staje się mniej oczywiste. Jeśli do odpowiedzi na pytanie wystarczy comiesięczne odświeżanie, stały przepływ danych zwiększa koszty, ale nie dostarcza dodatkowych informacji.

Jak działają szablony danych?

Szablony danych pozwalają zacząć od danych, które już są dostępne, zamiast od gotowego konektora. Określają pola potrzebne do analizy w formacie, który mogą przygotować Państwo lub zespół danych.

Zacznij od poradnika dotyczącego procesu

W poradnikach dotyczących ulepszania procesów można wyszukać proces lub system. Każdy poradnik dotyczy jednego procesu albo procesu realizowanego w jednym systemie. Opisuje wyzwania, cele, działania i wymagania dotyczące danych, a także zawiera szablon Excel do pobrania.

Jeśli danego procesu nie ma na liście, można skorzystać z ogólnego szablonu danych. W obu przypadkach kolumny odpowiadają wymaganiom analizy, więc zespół uzupełnia je na podstawie eksportu, zamiast projektować strukturę danych od podstaw.

Zacznij od Excela

W wielu analizach wystarczy arkusz zawierający Case ID, Timestamp i nazwę Activity oraz inne atrybuty istotne dla danego pytania. Wystarczy wyeksportować dostępne dane, uporządkować je zgodnie z szablonem, przesłać plik i rozpocząć analizę.

Do sprawdzenia pomysłu nie potrzeba kompletnego, zautomatyzowanego przepływu danych. Pierwszy zbiór danych może wymagać dopracowania. To część procesu poznawania wymagań analizy.

Pierwszy raz pracują Państwo z dziennikiem zdarzeń? Dowiedzcie się, jak utworzyć dziennik zdarzeń. W poradniku znajdą Państwo przykłady w Excelu i SQL.

Zacznij od jednej tabeli

W większości analiz celowo korzystamy z formatu opartego na jednej tabeli.

1. Łatwo ją sprawdzić. Arkusz można otworzyć i od razu zobaczyć, co zawiera.
2. Łatwo ją przygotować. Przed pierwszą analizą nie trzeba łączyć tabel ani zarządzać relacjami między nimi.
3. Etap process mining i tak łączy dane. Narzędzia wczytujące kilka tabel tworzą jeden dziennik zdarzeń przed rozpoczęciem analizy.

Jeśli wymaga tego analiza, w ProcessMind można pracować z wieloma tabelami, różnymi perspektywami i różnymi procesami. Nie trzeba jednak od nich zaczynać. Warto zacząć od najprostszego zbioru danych, który pozwala odpowiedzieć na pytanie.

Współpracuj z zespołem danych

Zespół danych zna konfigurację systemów, wie, które pola są wiarygodne i jakie dane są już dostępne. Jasny szablon określa konkretne wymagania, nie zmuszając zespołu do poznawania zastrzeżonego modelu danych.

Zespół może korzystać ze znanych narzędzi i infrastruktury, w tym SQL, istniejących platform ETL, hurtowni danych i jezior danych. Dzięki temu można wykorzystać sprawdzone dane zamiast tworzyć równoległy przepływ.

Praktyczne wskazówki dotyczące przygotowania dziennika zdarzeń zawiera dokumentacja przygotowania danych.

Skorzystaj z mapowania wspomaganego przez AI

Nazwy kolumn w eksporcie mogą się różnić od nazw w szablonie. Podczas przesyłania pliku ProcessMind często rozpoznaje pola takie jak Case ID, Timestamp i Activity. Jeśli pole zostanie przypisane nieprawidłowo, można poprawić mapowanie ręcznie.

Dzięki temu można przejść od dostępnego eksportu do analizy bez konieczności wcześniejszego formatowania każdego pliku źródłowego.

Jak w praktyce aktualizować dane?

Zaplanowane odświeżanie przydaje się, gdy trzeba regularnie monitorować proces. Ciągłe aktualizacje nie zawsze są jednak potrzebne, by odpowiedzieć na pierwsze pytanie lub porównać wyniki w czasie.

W wielu analizach łatwiej interpretować stabilny zbiór danych odświeżany według ustalonego harmonogramu. Można wyznaczyć punkt odniesienia, wprowadzić zmianę i porównać wyniki z tym punktem. Częstotliwość odświeżania zależy od tego, jak często zmienia się proces i jak szybko trzeba reagować.

Na początek warto ustalić, jak często analiza wymaga nowych danych. Jeśli wystarczy aktualizacja co miesiąc lub kwartał, przepływ danych w czasie rzeczywistym może zwiększyć nakład pracy, nie poprawiając jakości decyzji.

Co zrobić, jeśli później potrzebna będzie automatyzacja?

Gdy wiadomo już, jakich danych potrzeba i że analiza jest przydatna, zespół danych może przygotować powtarzalny proces wczytywania. ProcessMind udostępnia do tego REST API. Zaplanowane już przez zespół zadanie może przesłać eksport jako nowy zbiór danych lub aktualizację istniejącego. Przegląd API opisuje uwierzytelnianie i dostępne endpointy.

Produkt celowo nie ma wbudowanego harmonogramu. Harmonogram, dane uwierzytelniające i monitorowanie pozostają w infrastrukturze obsługiwanej przez zespół. Nie trzeba więc konfigurować ani nadzorować drugiego rozwiązania.

Nie trzeba automatyzować procesu, zanim będzie wiadomo, co warto zautomatyzować. Zacznijcie Państwo od eksportu, zweryfikujcie analizę, a potem zdecydujcie, czy warto zbudować cykliczny przepływ danych. Jeśli powstanie, warto wziąć pod uwagę kwestie opisane w artykule ETL w process mining.

Kiedy warto wybrać dostawcę z gotowymi konektorami?

Dostawca gotowych konektorów może być lepszym wyborem, jeśli potrzebne jest wspierane, cykliczne pobieranie danych z obsługiwanego systemu, a konektor odpowiada wymaganiom dotyczącym konfiguracji i nadzoru. Ma to szczególne znaczenie przy częstym pobieraniu danych lub w regulowanych środowiskach, gdzie organizacja wymaga określonego sposobu integracji.

Przed podjęciem decyzji warto zapytać, jakie systemy obsługuje konektor, jak radzi sobie z modyfikacjami, jakiego utrzymania wymaga oraz czy można sprawdzić i ponownie wykorzystać pobrane dane. Jeśli celem jest sprawdzenie pierwszej analizy, prostszym początkiem może być dostępny eksport i szablon danych.

Kompromis jest prosty: dopasowany konektor może ograniczyć powtarzalną pracę związaną z pobieraniem danych, a szablon pozwala zacząć od danych, które już są dostępne, bez rozpoczynania od projektu konektora. Dane pozostają Państwa własnością, bez uzależnienia od dostawcy. Decyzję o automatyzacji można podjąć później.