Szablon danych do analizy wdrażania klientów KYC
Szablon danych do analizy wdrażania klientów KYC
- Zalecane atrybuty
- Czynności do monitorowania
- Wskazówki dotyczące pobierania danych z ACTICO
Atrybuty procesu wdrażania klientów KYC
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Timestamp wskazujący, kiedy dana czynność się rozpoczęła lub miała miejsce. | ||
| Opis Czas zdarzenia to dokładna data i godzina zarejestrowania czynności w systemie. Określa chronologiczną kolejność wszystkich zdarzeń w ramach jednego wniosku klienta i wyznacza oś czasu onboardingu. Ten atrybut jest niezbędny w analizach opartych na czasie. Służy do obliczania czasu między czynnościami, wykrywania opóźnień i okresów oczekiwania, mierzenia całkowitego czasu obsługi sprawy oraz sprawdzania zgodności z umowami SLA. Na podstawie kolejności timestampów dla danej sprawy narzędzia process mining odtwarzają rzeczywisty przebieg procesu. Dlaczego to ważne Atrybut określa chronologiczną kolejność zdarzeń. Jest niezbędny do obliczania czasu trwania, wykrywania wąskich gardeł i analizy przebiegu procesu w czasie. Skąd pobrać Timestamp powiązany z każdą zarejestrowaną czynnością, znajdujący się w tabelach dziennika zdarzeń ACTICO. Szczegóły można znaleźć w dokumentacji ACTICO. Przykłady 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Nazwa czynności ActivityName | Nazwa konkretnego zdarzenia biznesowego lub zadania wykonanego w procesie onboardingu klienta. | ||
| Opis Ten atrybut zapisuje nazwę każdego kroku lub czynności w procesie KYC, na przykład „Złożenie wniosku”, „Ocena ryzyka” lub „Zatwierdzenie wniosku”. Poszczególne wartości tworzą kolejne elementy mapy procesu. Analiza nazw czynności pozwala wizualizować przebieg procesu, wykrywać czynności częste i rzadkie oraz wskazywać wąskie gardła i pętle poprawek. To podstawa do ustalenia, jakie działania są wykonywane i w jakiej kolejności, co ma znaczenie przy analizie wariantów i kontrolach zgodności. Dlaczego to ważne Atrybut określa kroki na mapie procesu. Pozwala wizualizować jego przebieg, wykrywać odstępstwa oraz analizować częstotliwość i kolejność czynności. Skąd pobrać Informacje te znajdują się zwykle w tabeli dziennika zdarzeń w ACTICO, często w polu opisującym typ zdarzenia lub zadania. Szczegóły można znaleźć w dokumentacji ACTICO. Przykłady Złożenie wnioskuOcena ryzykaZakończenie kontroli zgodnościOdrzucenie wniosku | |||
| Wniosek klienta CustomerApplication | Unikalny identyfikator pojedynczego wniosku o onboarding klienta, używany jako identyfikator sprawy w analizie procesu. | ||
| Opis Wniosek klienta to główny identyfikator sprawy, który łączy wszystkie zdarzenia i czynności związane z onboardingiem danego klienta. Oznacza jeden pełny przebieg procesu KYC, od złożenia wniosku po ostateczną decyzję o jego zatwierdzeniu lub odrzuceniu. W process mining ten atrybut jest niezbędny do odtworzenia całej ścieżki każdego wniosku. Pozwala analitykom śledzić kolejność czynności, mierzyć całkowity czas realizacji i porównywać różne ścieżki, czyli warianty procesu, dla poszczególnych wniosków. Wszystkie zdarzenia z tym samym identyfikatorem wniosku klienta należą do tej samej sprawy. Dlaczego to ważne To podstawowy atrybut w process mining. Łączy powiązane zdarzenia w jedną instancję procesu i umożliwia analizę całego przebiegu onboardingu każdego klienta. Skąd pobrać To klucz główny w głównych tabelach wniosków lub zarządzania sprawami w ACTICO. Dokładne nazwy tabel i pól można znaleźć w dokumentacji ACTICO. Przykłady WN-2023-001234WN-2023-001235WN-2024-000001 | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane zostały ostatnio odświeżone lub pobrane z systemu źródłowego. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z ACTICO. Jest to pole metadanych dotyczące całego zbioru, a nie poszczególnych zdarzeń. Informuje, jak aktualne są dane użyte w analizie. W dashboardach i raportach ta informacja pozwala ocenić aktualność danych. Pomaga określić, na ile bieżące są uzyskane wnioski, i ma znaczenie przy monitorowaniu operacyjnym, gdy potrzebne są dane zbliżone do czasu rzeczywistego. Wyświetlenie znacznika czasu zwiększa przejrzystość i zaufanie do prezentowanych danych. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu można ocenić, czy analiza opiera się na bieżących informacjach. Ma to znaczenie przy podejmowaniu decyzji operacyjnych. Skąd pobrać Wartość jest generowana i zapisywana podczas ekstrakcji, transformacji i ładowania danych (ETL). Wskazuje znacznik czasu pomyślnego zakończenia zadania ETL. Przykłady 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| System źródłowy SourceSystem | System ewidencyjny, z którego pochodzą dane o zdarzeniach. | ||
| Opis Ten atrybut wskazuje system informatyczny, w którym wygenerowano dane. W tym procesie jego wartością będzie zawsze „ACTICO”. W analizach obejmujących kilka systemów pozwala odróżnić źródła danych. W process mining ma znaczenie dla zarządzania danymi i ich weryfikacji. Umożliwia prawidłowe przypisanie danych do źródła, co jest ważne przy łączeniu informacji z różnych systemów w celu uzyskania pełnego obrazu procesu. Pomaga też diagnozować problemy z jakością danych, ponieważ pozwala prześledzić je do systemu, w którym powstały. Dlaczego to ważne Dostarcza informacji o pochodzeniu danych i wspiera zarządzanie nimi oraz śledzenie ich przepływu. Ma to szczególne znaczenie przy łączeniu danych z wielu źródeł. Skąd pobrać Zwykle jest to stała wartość („ACTICO”), dodawana podczas ekstrakcji i transformacji danych w celu oznaczenia zbioru. Przykłady ACTICOPlatforma ACTICOModuł KYC ACTICO | |||
| Czas zakończenia EndTime | Znacznik czasu wskazujący, kiedy zakończono daną czynność. | ||
| Opis Czas zakończenia oznacza moment ukończenia czynności. W połączeniu z czasem rozpoczęcia (EventTime) pozwala dokładnie obliczyć czas trwania każdego zadania, czyli czas jego realizacji. Nie każde zdarzenie ma osobny czas zakończenia, ponieważ niektóre czynności są natychmiastowe. Ten atrybut jest podstawą analizy wydajności, zwłaszcza pomiaru czasu poszczególnych etapów. Umożliwia tworzenie szczegółowych dashboardów wydajności, pomaga wskazać czynności zajmujące najwięcej czasu i służy do obliczania KPI, takich jak „Średni czas weryfikacji dokumentów”. Dlaczego to ważne Pozwala dokładnie obliczyć czas trwania czynności, czyli czas jej realizacji. Jest to potrzebne do wykrywania wąskich gardeł i analizy efektywności wykorzystania zasobów. Skąd pobrać Podobnie jak czas rozpoczęcia, wartość tę zwykle można znaleźć w tabelach dziennika zdarzeń ACTICO. Niektóre systemy zapisują czas rozpoczęcia i zakończenia pojedynczego zdarzenia w osobnych kolumnach. Szczegóły można sprawdzić w dokumentacji ACTICO. Przykłady 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Docelowy termin SLA SlaTargetDate | Termin, do którego powinien zakończyć się proces wdrożenia klienta. | ||
| Opis Docelowy termin SLA to termin zakończenia wdrożenia klienta określony w wewnętrznych umowach o poziomie usług. Często oblicza się go, dodając standardowy czas realizacji do daty złożenia wniosku. Ten atrybut jest niezbędny do monitorowania zgodności z SLA. Porównanie faktycznej daty zakończenia sprawy z docelowym terminem SLA pozwala ustalić, czy sprawę zakończono na czas, czy doszło do przekroczenia SLA. Atrybut stanowi podstawę dashboardu „Realizacja SLA przy wdrażaniu klientów” oraz KPI „Odsetek spraw wdrożeniowych zakończonych w terminie SLA”. Dlaczego to ważne Wyznacza punkt odniesienia do pomiaru terminowości i umożliwia bezpośrednie monitorowanie oraz raportowanie zgodności z SLA. Skąd pobrać Wartość może być zapisana w głównej tabeli spraw ACTICO albo obliczana na podstawie reguł biznesowych, na przykład: data złożenia wniosku + 5 dni roboczych. Przykłady 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Dział Department | Dział lub zespół odpowiedzialny za wykonanie czynności. | ||
| Opis Ten atrybut przypisuje czynność do konkretnej jednostki organizacyjnej, na przykład „Zgodność”, „Zespół ds. wdrożeń” lub „Relacje z klientami”. Pokazuje strukturę organizacyjną procesu. Analiza na poziomie działów pomaga zrozumieć, jak praca jest przekazywana między różnymi częściami organizacji. Ułatwia wykrywanie wąskich gardeł między działami, pomiar ich efektywności i analizę przydziału zasobów w zespołach. Dashboardy można filtrować według działu, aby menedżerowie mogli sprawdzić wyniki swojego zespołu. Dlaczego to ważne Dodaje do analizy wymiar organizacyjny. Pozwala wykrywać opóźnienia między działami i oceniać wyniki poszczególnych zespołów. Skąd pobrać Informacja może być zapisana bezpośrednio przy danych zdarzenia albo uzyskana przez połączenie danych użytkowników z tabelą kadrową, która przypisuje użytkowników do działów. Szczegóły można sprawdzić w dokumentacji ACTICO. Przykłady ComplianceZespół ds. wdrożeńObsługa klienta | |||
| Powód odrzucenia RejectionReason | Konkretna przyczyna odrzucenia wniosku klienta. | ||
| Opis Jeśli końcowy status wniosku to „Odrzucony”, ten atrybut wskazuje przyczynę. Przykłady: „Niekompletna dokumentacja”, „Negatywny wynik weryfikacji” lub „Wysoki poziom ryzyka”. Atrybut jest przydatny w analizie przyczyn źródłowych. Analiza częstotliwości poszczególnych powodów odrzucenia pozwala wykryć problemy systemowe w procesie lub w składanych przez klientów dokumentach. Na przykład częste odrzucenia z powodu niekompletnej dokumentacji mogą wskazywać, że instrukcje dotyczące wniosku są niejasne. Atrybut bezpośrednio wspiera dashboard „Odsetek i przyczyny odrzuceń wniosków”. Dlaczego to ważne Wyjaśnia przyczyny odrzucenia wniosków. Umożliwia analizę przyczyn źródłowych, ograniczenie liczby odrzuceń i usprawnienie procesu. Skąd pobrać Zwykle znajduje się w głównej tabeli spraw lub wniosków ACTICO i jest wypełniany tylko wtedy, gdy status wniosku to „Odrzucony”. Przykłady Niekompletna dokumentacjaNieudana weryfikacja tożsamościTrafienie na liście sankcyjnejWysoki wynik oceny ryzyka | |||
| Poziom ryzyka RiskLevel | Obliczony poziom ryzyka wniosku klienta, na przykład niski, średni lub wysoki. | ||
| Opis Ten atrybut określa kategorię ryzyka przypisaną klientowi. Często wpływa ona na zakres i szczegółowość kolejnych etapów procesu KYC. W przypadku klienta wysokiego ryzyka mogą być wymagane dodatkowe kontrole i zatwierdzenia, których nie stosuje się wobec klienta niskiego ryzyka. W process mining poziom ryzyka jest przydatnym wymiarem porównawczym. Pozwala sprawdzić, czy proces przebiega różnymi ścieżkami zależnie od poziomu ryzyka, zgodnie z założeniami. Można na przykład zweryfikować, czy wszyscy klienci wysokiego ryzyka przechodzą rozszerzoną analizę due diligence. Atrybut wspiera dashboard „Przebieg procesu oceny ryzyka”. Dlaczego to ważne Pozwala dzielić sprawy według poziomu ryzyka i sprawdzać, czy proces jest odpowiednio dostosowany do różnych profili ryzyka, zgodnie z wymogami dotyczącymi zgodności. Skąd pobrać To ważna informacja zapisywana na poziomie sprawy w głównej tabeli wniosków ACTICO. Przykłady NiskiŚredniWysoki | |||
| Status wniosku ApplicationStatus | Końcowy wynik lub bieżący stan wniosku o wdrożenie klienta. | ||
| Opis Ten atrybut wskazuje końcowy wynik sprawy, zwykle „Zatwierdzony” lub „Odrzucony”. Może też określać status spraw w toku. To ważny wymiar analizy wyników. Ustalenie, dlaczego wnioski są zatwierdzane lub odrzucane, jest jednym z głównych celów process mining w obszarze KYC. Atrybut pozwala filtrować mapę procesu i porównywać typowy przebieg wniosków zatwierdzonych i odrzuconych. Dzięki temu można wykrywać wzorce prowadzące do niepożądanych wyników. Atrybut stanowi też podstawę do obliczania KPI „Odsetek odrzuconych wniosków”. Dlaczego to ważne Określa wynik każdej sprawy, umożliwia porównanie pomyślnych i niepomyślnych przebiegów procesu oraz obliczenie odsetka odrzuceń. Skąd pobrać To atrybut na poziomie sprawy, często dostępny w głównej tabeli spraw lub wniosków ACTICO. Określa końcowy status wniosku. Przykłady ZatwierdzonyOdrzuconyW tokuOczekuje na informacje | |||
| Użytkownik rozpoczynający InitiatingUser | Identyfikator lub nazwa użytkownika, który wykonał czynność. | ||
| Opis Ten atrybut wskazuje konkretnego użytkownika lub agenta systemowego odpowiedzialnego za wykonanie czynności. Łączy etapy procesu z osobami lub zespołami, które je zrealizowały. Analiza wydajności według użytkownika jest częstą potrzebą. Atrybut pozwala tworzyć dashboardy pokazujące rozkład obciążenia, czas realizacji zadań przez poszczególne osoby oraz porównanie wyników użytkowników i zespołów. Pomaga wskazać osoby osiągające dobre wyniki, a także te, które mogą potrzebować dodatkowego szkolenia. Ułatwia również analizę przydziału i wykorzystania zasobów. Dlaczego to ważne Łączy czynności w procesie z konkretnymi użytkownikami. Umożliwia analizę wyników poszczególnych osób i zespołów oraz pomaga wykrywać potrzeby szkoleniowe i nierównomierne obciążenie zasobów. Skąd pobrać Zwykle jest zapisywany przy każdym zdarzeniu w dzienniku zdarzeń ACTICO lub w tabelach historii transakcji. Szczegóły można sprawdzić w dokumentacji ACTICO. Przykłady jan.kowalskianna.nowakSYSTEM_USER | |||
| Czy czynność jest poprawką IsRework | Obliczany wskaźnik określający, czy czynność jest powtórzeniem wcześniejszego etapu lub częścią pętli poprawek. | ||
| Opis Ten atrybut logiczny oznacza czynności wykonywane po raz drugi lub kolejny w ramach tej samej sprawy, na przykład ponowną „Weryfikację dokumentów” po prośbie o dodatkowe informacje. Wskazuje poprawki, które często obniżają efektywność procesu. Wykrywanie poprawek jest jednym z głównych celów process mining. Wskaźnik pozwala je mierzyć, na przykład przy obliczaniu KPI „Odsetek dokumentów wymagających poprawek”. Na mapie procesu można wyróżnić pętle poprawek i zobaczyć, w których miejscach proces wraca do wcześniejszych etapów. Ułatwia to wykrywanie problemów z jakością lub obszarów, w których nie udaje się wykonać pracy poprawnie za pierwszym razem. Dlaczego to ważne Wskazuje powtarzające się czynności, dzięki czemu można bezpośrednio mierzyć straty efektywności i wykrywać problemy z jakością lub jasnością działań. Skąd pobrać To obliczany atrybut. Reguły wykrywania powtórzonych czynności w ramach tej samej sprawy definiuje się w narzędziu process mining lub podczas transformacji danych. Przykłady truefalse | |||
| Czy czynność jest zautomatyzowana IsAutomated | Wskaźnik określający, czy czynność wykonał automatycznie system, czy ręcznie użytkownik. | ||
| Opis Ten atrybut logiczny odróżnia zadania wykonywane przez użytkownika od tych realizowanych automatycznie przez system, na przykład automatycznej weryfikacji lub oceny ryzyka. Analiza atrybutu pomaga ocenić skuteczność automatyzacji. Umożliwia porównanie czasu realizacji czynności automatycznych i ręcznych, wskazuje etapy procesu nadal wykonywane głównie ręcznie oraz może ujawnić możliwości dalszej automatyzacji, która poprawi efektywność i ograniczy koszty operacyjne. Dlaczego to ważne Odróżnia zadania wykonywane przez ludzi od zadań systemowych. Pozwala mierzyć wpływ automatyzacji i wskazywać możliwości dalszego usprawnienia pracy. Skąd pobrać Wartość można wywnioskować z atrybutu „InitiatingUser”, na przykład gdy użytkownikiem jest „SYSTEM”, albo odczytać z osobnego wskaźnika w dzienniku zdarzeń. Szczegóły można sprawdzić w dokumentacji ACTICO. Przykłady truefalse | |||
| Kraj Country | Kraj zamieszkania klienta składającego wniosek o wdrożenie. | ||
| Opis Ten atrybut określa kraj klienta, który może znacząco wpływać na przebieg procesu KYC. W różnych jurysdykcjach obowiązują odmienne wymogi regulacyjne, które mogą wymagać dodatkowych lub innych etapów procesu. Analiza procesu według kraju pozwala porównywać wyniki w różnych regionach. Może ujawnić, że wnioski z niektórych krajów regularnie wymagają więcej czasu lub częściej są odrzucane. Może to wskazywać na utrudnienia regulacyjne albo specyficzne wyzwania rynkowe. Taki widok geograficzny pomaga organizacjom działającym globalnie ujednolicać procesy z uwzględnieniem lokalnych wymogów dotyczących zgodności. Dlaczego to ważne Dodaje do analizy wymiar geograficzny. Pomaga zrozumieć różnice w przebiegu i wynikach procesu w poszczególnych jurysdykcjach. Skąd pobrać To podstawowa informacja o kliencie, zapisywana na poziomie sprawy lub klienta w systemie ACTICO. Przykłady USADEUGBRSGP | |||
| Status SLA SlaState | Obliczany status informujący, czy sprawa spełnia wymagania SLA, przekroczyła termin lub jest zagrożona przekroczeniem. | ||
| Opis Ten atrybut określa, jak sprawa wypada w odniesieniu do umowy o poziomie usług. Jest obliczany przez porównanie czasu zakończenia sprawy, a w przypadku otwartych spraw bieżącego czasu, z wartością „SlaTargetDate”. Atrybut upraszcza raportowanie SLA, zamieniając porównanie dat na czytelny status. Dashboardy mogą przedstawiać go na przykład na wykresach kołowych lub wskaźnikach pokazujących odsetek spraw, w których termin został dotrzymany lub przekroczony. Atrybut wspiera dashboard „Realizacja SLA przy wdrażaniu klientów” i bezpośrednio służy do obliczania KPI „Odsetek spraw wdrożeniowych zakończonych w terminie SLA”. Dlaczego to ważne Jasno określa zgodność każdej sprawy z SLA, upraszcza raportowanie i ułatwia prezentację wyników w odniesieniu do założonych celów. Skąd pobrać To obliczany atrybut, którego wartość wynika z reguł biznesowych porównujących znacznik czasu zakończenia sprawy z wartością „SlaTargetDate”. Przykłady Termin dotrzymanyTermin przekroczonyZagrożenie przekroczeniem terminu | |||
| Typ klienta CustomerType | Kategoria klienta, na przykład osoba fizyczna lub firma. | ||
| Opis Ten atrybut dzieli wnioskodawców na kategorie, na przykład osoby fizyczne i podmioty gospodarcze. Przebieg procesu KYC często znacznie się różni w zależności od typu klienta. Wdrożenie firmy jest zwykle bardziej złożone. Podział według typu klienta pozwala osobno analizować i porównywać różne procesy w tym samym zbiorze danych. Analitycy mogą wyświetlić na mapie procesu tylko klientów z kategorii „Firma”, aby sprawdzić ich specyficzne problemy, wąskie gardła i czas realizacji. Wyników nie zniekształcają wtedy znacznie prostsze procesy dotyczące osób fizycznych. Dlaczego to ważne Pozwala analizować proces osobno dla różnych kategorii klientów, których przebieg i stopień złożoności mogą się znacznie różnić. Dzięki temu wyniki analizy są dokładniejsze. Skąd pobrać To podstawowy atrybut zapisany na poziomie sprawy lub klienta w ACTICO. Przykłady Osoba fizycznaFirmaMała firma | |||
Czynności w procesie wdrażania klientów KYC
| Działanie | Opis | ||
|---|---|---|---|
| Ocena ryzyka | Ta czynność oznacza uruchomienie silnika decyzyjnego ACTICO w celu obliczenia oceny lub poziomu ryzyka dla wniosku klienta. Jest to podstawowa funkcja systemu, rejestrowana jako jawne zdarzenie podczas wykonania zestawu reguł oceny ryzyka. | ||
| Dlaczego to ważne Ocena ryzyka to ważny punkt decyzyjny, który często wyznacza dalszy przebieg procesu. Analiza tej czynności pomaga zrozumieć, jak poziom ryzyka wpływa na warianty procesu i czas ich realizacji. Skąd pobrać To podstawowe zdarzenie w ACTICO, które powinno być zapisane w dziennikach decyzji lub wykonania. Zawierają one zwykle identyfikator sprawy, wykonane reguły i wynikową ocenę ryzyka. Rejestrowanie Zdarzenie rejestrowane przez silnik decyzyjny ACTICO po zakończeniu oceny ryzyka. Typ zdarzenia explicit | |||
| Odrzucenie wniosku | Oznacza ostateczną decyzję o odrzuceniu wniosku klienta i zakończeniu procesu onboardingu. To ważny status końcowy, rejestrowany jako końcowa zmiana statusu rekordu wniosku. | ||
| Dlaczego to ważne To główne zdarzenie kończące proces niepowodzeniem. Analiza spraw zakończonych tą czynnością pomaga zrozumieć odsetek odrzuceń i ich przyczyny oraz poprawić ogólną skuteczność procesu. Skąd pobrać Informację można wywnioskować z końcowego pola statusu w głównej tabeli wniosków lub spraw. Warto szukać końcowego statusu, takiego jak „Odrzucony” lub „Zamknięty, odrzucony”. Rejestrowanie Końcowy status sprawy w danych głównych zostaje zmieniony na „Odrzucony”. Typ zdarzenia inferred | |||
| Przesłanie dokumentów przez klienta | Ta czynność ma miejsce, gdy klient przesyła wymagane dokumenty tożsamości i dokumenty uzupełniające przez portal lub inny kanał zintegrowany z ACTICO. Każde przesłanie dokumentu jest zwykle rejestrowane jako osobne, jawne zdarzenie w systemie zarządzania dokumentami lub dzienniku sprawy. | ||
| Dlaczego to ważne To ważny etap zależny od klienta. Śledzenie tego zdarzenia jest niezbędne do pomiaru czasu reakcji klienta i analizy długości późniejszej weryfikacji dokumentów. Skąd pobrać Warto sprawdzić dzienniki zdarzeń dotyczące obsługi dokumentów lub załączników do sprawy. Często są one zapisywane w osobnych tabelach zarządzania dokumentami lub materiałami dowodowymi w bazie ACTICO. Rejestrowanie Zdarzenie rejestrowane przez system po dołączeniu dokumentu do sprawy. Typ zdarzenia explicit | |||
| Rozpoczęcie kontroli zgodności | Oznacza rozpoczęcie ręcznej weryfikacji przez dział zgodności, zwykle w przypadku wniosków wysokiego ryzyka lub oznaczonych do kontroli. Czynność tę można zazwyczaj wywnioskować ze zmiany statusu sprawy na „Oczekuje na kontrolę zgodności” lub przypisania jej do kolejki pracownika działu zgodności. | ||
| Dlaczego to ważne Ta czynność wyznacza początek pomiaru wąskiego gardła w kontroli zgodności. Czas do „Zakończenie kontroli zgodności” jest istotnym KPI, który pomaga wykryć opóźnienia na tym ważnym etapie. Skąd pobrać Informację można wywnioskować z historii statusów wniosku lub ścieżki audytowej. Warto sprawdzić timestamp zmiany statusu na „Kontrola zgodności w toku” albo przypisania sprawy do grupy użytkowników odpowiedzialnej za zgodność. Rejestrowanie Wnioskowane na podstawie zmiany statusu sprawy na „Oczekuje na kontrolę zgodności” lub przypisania jej do zespołu ds. zgodności. Typ zdarzenia inferred | |||
| Zakończenie kontroli zgodności | Oznacza zakończenie ręcznej weryfikacji przez dział zgodności i podjęcie decyzji o zatwierdzeniu, odrzuceniu lub dalszych działaniach. Czynność tę można wywnioskować ze zmiany statusu sprawy z „Oczekuje na kontrolę zgodności” na kolejny status, na przykład „Zatwierdzono pod względem zgodności”. | ||
| Dlaczego to ważne To zdarzenie zamyka etap kontroli zgodności. Jest niezbędne do obliczenia całkowitego czasu kontroli i analizy przepustowości zespołu. Skąd pobrać Informację można wywnioskować z dziennika historii statusów wniosku. Warto sprawdzić timestamp opuszczenia przez sprawę statusu „Kontrola zgodności w toku”, co oznacza podjęcie decyzji. Rejestrowanie Wnioskowane na podstawie zmiany statusu sprawy z „Oczekuje na kontrolę zgodności” na „Zatwierdzono pod względem zgodności” lub podobny. Typ zdarzenia inferred | |||
| Zakończenie onboardingu klienta | To ostatnia czynność w procesie. Oznacza pełne zakończenie onboardingu klienta i zamknięcie sprawy. Można ją wywnioskować z końcowego statusu, takiego jak „Onboarding zakończony” lub „Zamknięty, zatwierdzony”. | ||
| Dlaczego to ważne Jako główne zdarzenie kończące pomyślny proces czynność ta jest niezbędna do obliczenia całkowitego czasu onboardingu wszystkich klientów. Jej timestamp końcowy pozwala analizować najprostszą ścieżkę. Skąd pobrać Informację można wywnioskować z końcowego pola statusu sprawy klienta. Warto sprawdzić timestamp zmiany statusu sprawy na końcowy status oznaczający pomyślne zakończenie. Rejestrowanie Wnioskowane na podstawie końcowej zmiany statusu sprawy na „Zakończona” lub „Zamknięta”. Typ zdarzenia inferred | |||
| Zatwierdzenie wniosku | Ta czynność oznacza ostateczną decyzję biznesową o zatwierdzeniu wniosku klienta i rozpoczęciu onboardingu. To ważny etap, zwykle rejestrowany jako osobna, końcowa zmiana statusu w cyklu życia wniosku. | ||
| Dlaczego to ważne Ten etap poprzedza utworzenie konta i oznacza pomyślny wynik procesu. Analiza czasu potrzebnego na jego osiągnięcie pomaga określić czas realizacji najprostszej ścieżki. Skąd pobrać Informację można wywnioskować z końcowego pola statusu w głównej tabeli wniosków lub spraw. Warto szukać statusu „Zatwierdzony”, „Zatwierdzenie zakończone” lub podobnego statusu końcowego oznaczającego pozytywny wynik. Rejestrowanie Końcowy status sprawy w danych głównych zostaje zmieniony na „Zatwierdzony”. Typ zdarzenia inferred | |||
| Złożenie wniosku | Ta czynność rozpoczyna proces onboardingu KYC, gdy system ACTICO formalnie otrzymuje wniosek nowego klienta. Jest rejestrowana jako jawne zdarzenie, zwykle z dokładnym timestampem utworzenia nowej sprawy lub rekordu wniosku. | ||
| Dlaczego to ważne Jako główne zdarzenie rozpoczynające proces czynność ta jest niezbędna do obliczenia całkowitego czasu onboardingu i śledzenia liczby wniosków. Jej timestamp stanowi punkt odniesienia dla późniejszych pomiarów wyników procesu. Skąd pobrać Zwykle jest to jawny wpis w dzienniku tworzenia wniosku lub sprawy w ACTICO. Warto sprawdzić tabele dotyczące zdarzeń złożenia wniosku albo timestamp utworzenia głównego rekordu sprawy. Rejestrowanie Zdarzenie rejestrowane podczas tworzenia nowej sprawy dotyczącej wniosku. Typ zdarzenia explicit | |||
| Prośba o dodatkowe informacje | Zdarzenie oznacza, że osoba weryfikująca, często z działu zgodności lub oceny ryzyka kredytowego, potrzebuje od klienta dodatkowych informacji lub dokumentów. Zwykle jest rejestrowane jawnie, ponieważ wiąże się z wysłaniem powiadomienia do klienta i wstrzymaniem sprawy. | ||
| Dlaczego to ważne Ta czynność często prowadzi do ponownej pracy i wydłużenia czasu realizacji. Śledzenie jej częstotliwości i wpływu pomaga wskazać, co należy poprawić podczas wstępnego zbierania danych. Skąd pobrać Zdarzenie jest prawdopodobnie jawnie rejestrowane w historii sprawy lub dzienniku komunikacji. Warto szukać wpisów takich jak „Wysłano prośbę o informacje” albo zmian statusu na „Oczekuje na informacje od klienta”. Rejestrowanie Jawne zdarzenie wywołane przez użytkownika, na przykład „Wyślij prośbę o informacje”, jest zapisywane w ścieżce audytowej sprawy. Typ zdarzenia explicit | |||
| Rozpoczęcie kontroli w bazach zewnętrznych | Oznacza rozpoczęcie automatycznej lub ręcznej kontroli, na przykład sprawdzenia AML lub historii kredytowej. Zdarzenie jest często rejestrowane jawnie, gdy system uruchamia kontrolę, która może korzystać z usług zewnętrznych dostawców. | ||
| Dlaczego to ważne Rozpoczęcie kontroli w bazach zewnętrznych to ważny etap procesu należytej staranności. Śledzenie tej czynności pomaga zrozumieć zależności i czas oczekiwania na dane od zewnętrznych dostawców. Skąd pobrać Warto szukać wpisów w dziennikach systemowych lub ścieżce audytowej, które wskazują uruchomienie procedur sprawdzających. Często są one powiązane z identyfikatorem głównej sprawy dotyczącej wniosku. Rejestrowanie Zdarzenie rejestrowane, gdy silnik workflow uruchamia wywołania usług sprawdzających dane w bazach zewnętrznych. Typ zdarzenia explicit | |||
| Utworzenie konta | Po zatwierdzeniu wniosku następuje techniczne utworzenie konta klienta w systemie bankowości podstawowej lub systemie zarządzania użytkownikami. ACTICO często rejestruje to jako jawne zdarzenie po otrzymaniu potwierdzenia powodzenia z systemu docelowego. | ||
| Dlaczego to ważne Ta czynność potwierdza, że proces zakończył się konkretnym wynikiem biznesowym. Czas od „Zatwierdzenie wniosku” do „Utworzenie konta” może ujawnić opóźnienia integracji lub nieefektywność końcowych etapów udostępniania konta. Skąd pobrać Informacji należy szukać w dziennikach integracji lub interfejsów systemowych ACTICO, które zapisują wyniki wywołań systemów zewnętrznych w celu utworzenia konta. Rejestrowanie Zdarzenie rejestrowane po otrzymaniu pomyślnej odpowiedzi API z głównego systemu obsługi kont. Typ zdarzenia explicit | |||
| Weryfikacja tożsamości | Automatyczna lub ręczna kontrola tożsamości klienta na podstawie zewnętrznych lub wewnętrznych źródeł danych. Często jest rejestrowana jako jawne zdarzenie, gdy system wywołuje API zewnętrznej usługi weryfikacyjnej i otrzymuje odpowiedź. | ||
| Dlaczego to ważne To ważny etap zapewnienia zgodności. Analiza czasu trwania i wyników weryfikacji pomaga wykryć zależności od usług zewnętrznych oraz wąskie gardła w procesie. Skąd pobrać Informacje te znajdują się zwykle w dziennikach integracji lub specjalnych tabelach zdarzeń, które zapisują wyniki kontroli automatycznych i wywołań usług zewnętrznych powiązanych ze sprawą. Rejestrowanie Zdarzenie rejestrowane po wywołaniu zintegrowanej usługi zewnętrznej weryfikującej tożsamość. Typ zdarzenia explicit | |||
| Wstępna weryfikacja wniosku | Pierwsza weryfikacja złożonego wniosku, wykonywana automatycznie przez regułę lub przez pracownika, aby sprawdzić jego kompletność i podstawowe kryteria kwalifikacji. Czynność tę często można wywnioskować ze zmiany statusu wniosku, na przykład z „Złożony” na „W trakcie weryfikacji”. | ||
| Dlaczego to ważne Analiza czasu potrzebnego na wstępną weryfikację pomaga wykryć opóźnienia na początku procesu. Pokazuje też, ile wniosków przechodzi ten etap bez problemów. Skąd pobrać Informację można wywnioskować z tabel historii statusów lub dzienników audytowych powiązanych ze sprawą klienta. Należy porównać timestamp zmiany statusu z „Nowy” lub „Złożony” na „Weryfikacja”. Rejestrowanie Wykryj zmianę statusu z „Złożony” na „W trakcie weryfikacji” w dzienniku historii sprawy. Typ zdarzenia inferred | |||
| Zakończenie weryfikacji dokumentów | Ta czynność oznacza zakończenie przez pracownika weryfikacji dokumentów przesłanych przez klienta. Zwykle można ją wywnioskować ze zmiany statusu dokumentu lub całej sprawy, na przykład na „Dokumenty zweryfikowane” albo „Weryfikacja zakończona”. | ||
| Dlaczego to ważne To ważny etap przy pomiarze efektywności obsługi dokumentów. Czas od „Przesłanie dokumentów przez klienta” do tej czynności jest istotnym KPI, który pomaga wykryć opóźnienia w pracy ręcznej. Skąd pobrać Informację można wywnioskować z dzienników historii statusów sprawy lub poszczególnych dokumentów. Zmiana statusu dokumentu z „Oczekuje na weryfikację” na „Zatwierdzony” lub „Zweryfikowany” wskazuje na wykonanie tej czynności. Rejestrowanie Wnioskowane na podstawie zmiany statusu dokumentu na „Zweryfikowany” lub „Sprawdzony”. Typ zdarzenia inferred | |||
Instrukcje pobierania danych
Kroki
- Uzyskaj uprawnienia administratora: Zaloguj się do platformy ACTICO, na przykład Visual Modeler lub dedykowanej konsoli administracyjnej, używając danych logowania z uprawnieniami do dostępu do eksportu danych i jego konfiguracji.
- Znajdź moduł eksportu: Przejdź do obszaru administracji lub konfiguracji systemu. Znajdź sekcję dotyczącą ścieżek audytu, rejestrowania zdarzeń lub eksportu danych. Może być oznaczona jako „Audit Export” lub „Business Object Export”.
- Utwórz konfigurację eksportu: Rozpocznij tworzenie nowej definicji eksportu. Nadaj konfiguracji opisową nazwę, na przykład
KYC_Onboarding_ProcessMind_Export. - Określ źródło danych: Wskaż główny eksportowany obiekt biznesowy, czyli
CustomerApplication. Ustaw filtr zakresu dat, aby ograniczyć eksport, na przykład do ostatnich 6 miesięcy. Dzięki temu rozmiar pliku i obciążenie systemu pozostaną pod kontrolą. - Skonfiguruj plik wyjściowy: Wybierz format CSV. Określ nazwę pliku, na przykład
kyc_event_log.csv, i sprawdź, czy separatorem jest przecinek. Upewnij się, że pola tekstowe są ujmowane w cudzysłowy, aby poprawnie obsłużyć znaki specjalne. - Wskaż identyfikator sprawy: Ustaw unikatowy identyfikator obiektu biznesowego
CustomerApplicationjako identyfikator sprawy na potrzeby analizy process mining. Dzięki temu wszystkie powiązane zdarzenia zostaną przypisane do jednej sprawy onboardingowej. - Zdefiniuj mapowanie atrybutów: Dla każdej wymaganej kolumny dziennika zdarzeń wskaż odpowiadający jej atrybut w modelu obiektów biznesowych ACTICO. Uwzględnij identyfikator sprawy, nazwę czynności, znaczniki czasu oraz inne zalecane atrybuty, takie jak status czy poziom ryzyka.
- Skonfiguruj mapowanie zdarzeń: To najważniejszy etap. Utwórz osobną regułę lub mapowanie dla każdej z 14 czynności biznesowych. Wykorzystaj wyzwalacze systemowe, takie jak utworzenie obiektu dla zdarzenia „Złożono wniosek”, zmiany statusu dla etapów workflow, takich jak „Zatwierdzono wniosek”, oraz określone wzorce komunikatów w dzienniku audytowym dla zdarzeń technicznych, takich jak „Przeprowadzono weryfikację tożsamości”.
- Zapisz i sprawdź konfigurację: Po zdefiniowaniu wszystkich mapowań zapisz plik konfiguracji. Użyj dostępnych narzędzi walidacyjnych ACTICO, aby sprawdzić składnię i ścieżki atrybutów.
- Uruchom eksport i monitoruj jego przebieg: Uruchom zadanie eksportu. Śledź jego postęp w harmonogramie zadań systemu lub interfejsie monitorowania. Po zakończeniu sprawdź dzienniki pod kątem błędów.
- Pobierz i przygotuj plik: Pobierz wynikowy plik CSV ze wskazanej lokalizacji na serwerze. Przed przesłaniem go do ProcessMind otwórz plik, sprawdź jego strukturę oraz upewnij się, że formaty dat i znaczników czasu są spójne i prawidłowo odczytane.
Konfiguracja
- Poziom rejestrowania zdarzeń audytowych: Ustaw szczegółowy poziom rejestrowania w całym systemie, na przykład INFO lub FINE. Mniej szczegółowy poziom, taki jak WARNING lub ERROR, nie zarejestruje wymaganych zmian statusu i wykonań reguł potrzebnych do analizy process mining.
- Źródło danych eksportu: Jako główne źródło danych skonfiguruj obiekt biznesowy
CustomerApplication. Aby zarejestrować wszystkie istotne zdarzenia, może być konieczne połączenie z powiązanymi obiektami, takimi jakCustomerDocument. - Filtr zakresu dat: Zawsze stosuj filtr zakresu dat, aby kontrolować ilość eksportowanych danych. Do wstępnej analizy zaleca się okres od 3 do 6 miesięcy. W środowisku produkcyjnym zakres można dostosować do potrzeb biznesowych i wydajności systemu.
- Logika mapowania zdarzeń: Dokładność ekstrakcji zależy w dużej mierze od sposobu mapowania zdarzeń. Zmiany statusu (
on="StatusChange") często służą do identyfikacji etapów biznesowych. Jawne wpisy w dzienniku (on="LogEntry") przydają się przy zdarzeniach technicznych i wywołaniach usług. Wykonania reguł (on="RuleExecution") pozwalają rejestrować etapy podejmowania decyzji. - Format wyjściowy: Wybierz format CSV, który jest szeroko obsługiwany. Prawidłowo skonfiguruj separatory i ujmowanie tekstu w cudzysłowy, aby uniknąć problemów z odczytem danych.
- Wymagania wstępne: Ta metoda wymaga uprawnień administratora platformy ACTICO. Do prawidłowej konfiguracji niezbędna jest dobra znajomość modelu obiektów biznesowych KYC, w tym odpowiednich pól statusu i nazw atrybutów.
Przykładowe zapytanie xml
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration> Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby odpowiednio przygotować dane i szybciej usprawnić proces onboardingu klientów KYC w ACTICO.
Usprawnij onboarding klientów KYC i skróć go do 24 godzin
Ogranicz rezygnacje i fałszywe alarmy, aby onboarding przebiegał bez przeszkód.
Karta kredytowa nie jest wymagana. Usprawnianie procesów można rozpocząć już dziś.