Szablon danych do onboardingu klientów KYC

Pega KYC
Szablon danych do onboardingu klientów KYC

Szablon danych do onboardingu klientów KYC

Ten szablon pokazuje, jakie dane zebrać do analizy procesu onboardingu klientów KYC. Zawiera listę potrzebnych atrybutów i działań, które warto rejestrować w dzienniku zdarzeń. Znajdą tu Państwo również praktyczne wskazówki dotyczące pozyskiwania danych, które ułatwią rozpoczęcie analizy process mining.
  • Zalecane atrybuty dziennika zdarzeń
  • Najważniejsze działania do śledzenia w procesie
  • Praktyczne wskazówki dotyczące pozyskiwania danych
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty onboardingu klientów KYC

Poniżej przedstawiono zalecane pola dziennika zdarzeń. Zawierają informacje potrzebne do analizy procesu onboardingu klientów KYC.
3 Wymagane 7 Zalecane 11 Opcjonalne
Nazwa Opis
Czas rozpoczęcia
EventTime
Znacznik czasu wskazujący, kiedy rozpoczęła się czynność lub wystąpiło zdarzenie.
Opis

Ten atrybut zapisuje dokładną datę i godzinę rozpoczęcia czynności. Pozwala ustalić chronologiczną kolejność wszystkich zdarzeń w ramach jednego wniosku klienta.

Znaczniki czasu są niezbędne do analizy wydajności procesu. Służą do obliczania czasu trwania czynności, oczekiwania między krokami oraz całkowitego czasu realizacji onboardingu. Dane te pomagają wykrywać wąskie gardła, mierzyć dotrzymywanie SLA i oceniać sprawność procesu.

Dlaczego to ważne

Znaczniki czasu zapewniają kontekst chronologiczny potrzebny do obliczania czasu trwania, analizy wydajności procesu i wykrywania opóźnień.

Skąd pobrać

To standardowy element historii audytowej Pega. W tabelach historii dla każdego zdarzenia często występuje jako pxTimeCreated.

Przykłady
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
Czynność
ActivityName
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w procesie onboardingu.
Opis

Ten atrybut zapisuje nazwę czynności biznesowej lub zdarzenia systemowego, na przykład „Złożono wniosek”, „Rozpoczęto kontrolę zgodności” albo „Odrzucono wniosek”. Oznacza pojedynczy krok w całym procesie onboardingu klienta.

Analiza czynności stanowi podstawę process mining. Atrybut ten służy do budowania mapy procesu, która pokazuje przepływ między kolejnymi krokami. Pomaga ustalić kolejność zdarzeń, zmierzyć częstotliwość poszczególnych czynności i wskazać zadania, które występują najczęściej lub trwają najdłużej.

Dlaczego to ważne

Ten atrybut określa kroki na mapie procesu, dzięki czemu można zobrazować, analizować i zrozumieć przebieg procesu.

Skąd pobrać

Te informacje są zwykle zapisywane w historii audytowej Pega (tabelach historii) lub można je odtworzyć na podstawie zmian statusu sprawy.

Przykłady
Przeprowadzenie wstępnej weryfikacjiZakończenie kontroli zgodnościZatwierdzenie wniosku
Wniosek klienta
CustomerApplication
Unikalny identyfikator sprawy dotyczącej onboardingu każdego klienta.
Opis

Wniosek klienta to główny identyfikator sprawy, który łączy wszystkie powiązane działania i zdarzenia dotyczące onboardingu jednego klienta. Każdy wniosek przechodzi ścieżkę od złożenia do zatwierdzenia i aktywacji konta albo odrzucenia.

W process mining ten atrybut pozwala odtworzyć pełny przebieg każdej sprawy. Analitycy mogą przeglądać kolejność zdarzeń, śledzić status wniosków i porównywać ich ścieżki. Analiza spraw według tego identyfikatora pomaga wykrywać typowe warianty procesu, wąskie gardła i odstępstwa od standardowej procedury.

Dlaczego to ważne

Ten identyfikator stanowi podstawę process mining, ponieważ łączy poszczególne zdarzenia w spójne, kompleksowe instancje procesu, które można analizować.

Skąd pobrać

W Pega jest to zwykle główny identyfikator sprawy, dostępny często jako pzInsKey lub jego odpowiednik zrozumiały dla użytkowników biznesowych w obiekcie roboczym głównego typu sprawy.

Przykłady
APP-2023-00123APP-2023-00124APP-2023-00125
Czas zakończenia
EndTime
Znacznik czasu wskazujący, kiedy zakończyła się czynność lub zdarzenie.
Opis

Ten atrybut zapisuje dokładną datę i godzinę zakończenia czynności. W połączeniu z czasem rozpoczęcia pozwala obliczyć czas realizacji poszczególnych czynności.

Osobny czas zakończenia umożliwia dokładniejszą analizę wydajności. Pozwala odróżnić czas aktywnej pracy, czyli czas między rozpoczęciem a zakończeniem czynności, od czasu oczekiwania, czyli czasu między zakończeniem jednej czynności a rozpoczęciem kolejnej. Dzięki temu można wskazać rzeczywiste wąskie gardła i odróżnić je od kolejek.

Dlaczego to ważne

Pozwala dokładnie obliczyć czas realizacji czynności, co jest niezbędne do szczegółowej analizy wydajności i wykrywania wąskich gardeł.

Skąd pobrać

Informacja może być dostępna w historii audytowej Pega. Jeśli jej tam nie ma, czas zakończenia bieżącego zdarzenia można ustalić na podstawie czasu rozpoczęcia kolejnego.

Przykłady
2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
Dział
WorkGroup
Dział lub zespół funkcyjny odpowiedzialny za daną czynność.
Opis

Ten atrybut wskazuje jednostkę organizacyjną lub zespół, do którego należy użytkownik wykonujący czynność, na przykład „Zespół weryfikacji”, „Zespół ds. zgodności” lub „Operacje onboardingu”.

Analiza procesu według działu jest niezbędna na dashboardzie „Rozkład obciążenia według działu”. Pomaga kierownikom zrozumieć przepływ pracy między zespołami, wykrywać wąskie gardła na styku różnych funkcji i oceniać przydział zasobów w całym procesie onboardingu. Ułatwia też usprawnianie przekazywania zadań i równoważenie obciążenia.

Dlaczego to ważne

Umożliwia analizę przebiegu procesu i wąskich gardeł między jednostkami biznesowymi, wspierając zarządzanie zasobami i usprawnianie organizacji.

Skąd pobrać

Informacje te są zwykle powiązane z profilem użytkownika w Pega (rekordem Operator ID) i można je połączyć z danymi o zdarzeniach. Właściwością może być pyWorkGroup.

Przykłady
Wstępna weryfikacjaKontrola zgodnościAktywacja konta
Poziom ryzyka
RiskLevel
Obliczony poziom ryzyka wniosku klienta.
Opis

Ten atrybut określa ocenione ryzyko związane z klientem, zwykle klasyfikowane jako „Niskie”, „Średnie” lub „Wysokie”. Poziom ryzyka jest zazwyczaj ustalany przez automatyczny mechanizm oceny na podstawie danych klienta i wyników weryfikacji.

Poziom ryzyka wpływa na przebieg procesu. Wnioski wysokiego ryzyka często wymagają dodatkowych czynności sprawdzających, takich jak rozszerzona kontrola zgodności, co wydłuża czas realizacji. Analiza procesu według poziomu ryzyka pomaga uzasadnić te różnice i sprawdzić, czy mechanizmy kontroli ryzyka działają skutecznie, nie powodując niepotrzebnych opóźnień.

Dlaczego to ważne

Wyjaśnia różnice w przebiegu i czasie trwania procesu, ponieważ poziom ryzyka często określa wymagany zakres analizy due diligence.

Skąd pobrać

To obliczana właściwość sprawy, której wartość ustala reguła decyzyjna lub model oceny w Pega. Szczegóły można znaleźć w dokumentacji Pega KYC.

Przykłady
NiskieŚrednieWysokie
Przyczyna odrzucenia
RejectionReason
Określa przyczynę odrzucenia wniosku.
Opis

Jeśli końcowy status wniosku to „Odrzucony”, ten atrybut podaje konkretną przyczynę, na przykład „Negatywny wynik weryfikacji przeszłości”, „Niekompletna dokumentacja” lub „Wysoki poziom ryzyka”.

Atrybut ten jest podstawą dashboardu „Analiza odrzuconych wniosków”. Podział odrzuconych spraw według przyczyny pozwala ustalić, na których etapach onboardingu najczęściej dochodzi do niepowodzeń. Dzięki temu można wdrożyć ukierunkowane usprawnienia, ograniczyć liczbę odrzuceń, poprawić obsługę klienta i zwiększyć sprawność operacji.

Dlaczego to ważne

Pokazuje, dlaczego wnioski są odrzucane, i pomaga dobrać usprawnienia procesu, które zwiększą odsetek spraw zakończonych powodzeniem.

Skąd pobrać

Prawdopodobnie jest to właściwość ustawiana w sprawie przy zmianie jej statusu na „Odrzucony”. Informacje o standardowych polach przyczyny odrzucenia można znaleźć w dokumentacji Pega KYC.

Przykłady
Wykryto na liście sankcyjnejNiezgodność w dokumentacjiWykryto osobę zajmującą eksponowane stanowisko polityczne (PEP)Niewystarczające informacje
Status wniosku
ApplicationStatus
Ostateczny wynik lub bieżący status wniosku klienta.
Opis

Ten atrybut wskazuje ogólny status wniosku po zakończeniu procesu, na przykład „Zatwierdzony”, „Odrzucony” lub „Wycofany”. W przypadku trwających spraw może też odzwierciedlać ostatni znany status.

To ważny wymiar analizy wyników. Na dashboardzie „Analiza odrzuconych wniosków” służy do podziału spraw na grupy i ustalenia przyczyn poszczególnych wyników. Analiza ścieżek prowadzących do różnych statusów pomaga wskazać dobre praktyki w zatwierdzonych sprawach i źródłowe przyczyny odrzuceń.

Dlaczego to ważne

Określa wynik biznesowy sprawy, umożliwiając porównanie ścieżek zakończonych powodzeniem z tymi, które zakończyły się niepowodzeniem.

Skąd pobrać

W Pega jest to zwykle końcowy status sprawy (pyStatusWork) w obiekcie roboczym.

Przykłady
ZatwierdzonyOdrzuconyOczekuje na kontrolę zgodnościWycofany przez klienta
Termin docelowy SLA
SlaTargetDate
Data, do której należy zakończyć sprawę dotyczącą onboardingu klienta.
Opis

Ten atrybut przechowuje docelową datę zakończenia wniosku określoną w umowie o gwarantowanym poziomie usług (SLA). Termin może zależeć od takich czynników jak typ klienta, poziom ryzyka lub produkt.

Data ta jest niezbędna na dashboardzie „Monitorowanie realizacji SLA” i dla powiązanego z nim KPI. Stanowi punkt odniesienia przy porównywaniu z faktyczną datą zakończenia. Analiza spraw, w których nie dotrzymano terminu SLA, pomaga wykrywać systemowe opóźnienia i ustalać priorytety usprawnień, aby wywiązywać się z zobowiązań wobec klientów.

Dlaczego to ważne

Stanowi punkt odniesienia przy ocenie terminowości, która ma istotne znaczenie dla zadowolenia klientów i kontroli operacji.

Skąd pobrać

Pega ma wbudowany mechanizm zarządzania SLA. Termin jest zwykle przechowywany we właściwościach takich jak pySLAGoal lub we własnej właściwości SLA zdefiniowanej dla sprawy.

Przykłady
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
Użytkownik
OperatorId
Unikalny identyfikator użytkownika, który wykonał czynność.
Opis

Ten atrybut przechowuje identyfikator pracownika lub użytkownika systemowego odpowiedzialnego za wykonanie konkretnego zadania w procesie KYC, na przykład pracownika ds. zgodności lub automatycznego bota weryfikującego. W przypadku kroków automatycznych może to być identyfikator konta systemowego lub serwisowego.

Analiza według użytkownika pomaga ocenić rozkład obciążenia, indywidualne wyniki i potrzeby szkoleniowe. Ułatwia też badanie odstępstw od procesu przez wskazanie użytkowników lub zespołów zaangażowanych w niestandardowe ścieżki.

Dlaczego to ważne

Ten atrybut łączy czynności w procesie z konkretnymi osobami lub zespołami, umożliwiając analizę obciążenia, ocenę wyników i kontrolę zgodności.

Skąd pobrać

To standardowe pole w historii audytowej Pega, zwykle zapisywane jako pxUpdateOperator lub podobna właściwość w tabelach historii.

Przykłady
j.doe@acmebank.comanalityk_kyc_04systemowy_agent_automatyczny
Czas realizacji
CycleTime
Łączny czas od złożenia wniosku do ostatecznego rozstrzygnięcia.
Opis

Ta obliczana miara określa całkowity czas realizacji każdego wniosku klienta, od pierwszego do ostatniego zdarzenia. Zwykle oblicza się ją jako różnicę między znacznikiem czasu ostatniej czynności a znacznikiem pierwszej czynności w danej sprawie.

Czas realizacji to podstawowy KPI sprawności procesu i jakości obsługi klienta. Na dashboardzie „Analiza całkowitego czasu realizacji onboardingu” służy do monitorowania średniego czasu obsługi, wykrywania długo trwających spraw i śledzenia wpływu usprawnień procesu.

Dlaczego to ważne

Ten KPI bezpośrednio mierzy ogólną szybkość i sprawność onboardingu z perspektywy klienta.

Skąd pobrać

Narzędzie process mining oblicza tę miarę jako różnicę między najpóźniejszym a najwcześniejszym znacznikiem czasu dla każdego identyfikatora sprawy.

Przykłady
5 dni 4 godziny12 dni 1 godzina2 dni 8 godzin
Czy czynność jest zautomatyzowana
IsAutomated
Flaga wskazująca, czy czynność wykonał system, czy człowiek.
Opis

Ten atrybut logiczny ma wartość true, jeśli czynność wykonał agent automatyczny, na przykład mechanizm weryfikacji lub reguła systemowa, a wartość false, jeśli wykonał ją użytkownik.

Rozróżnienie czynności automatycznych i ręcznych jest niezbędne do analizy automatyzacji. Pozwala ocenić skuteczność obecnych rozwiązań, wskazać zadania ręczne, które warto zautomatyzować, oraz zrozumieć współpracę ludzi i systemów w procesie.

Dlaczego to ważne

Rozróżnia czynności wykonywane przez ludzi od tych realizowanych przez systemy. To podstawa analizy automatyzacji i planowania jej wdrożenia.

Skąd pobrać

Wartość można ustalić na podstawie identyfikatora użytkownika powiązanego ze zdarzeniem. Jeśli OperatorId odpowiada znanemu kontu systemowemu lub agenta, flaga otrzymuje wartość true.

Przykłady
truefalse
Czy wystąpiła ponowna praca
IsRework
Flaga wskazująca, czy czynność jest częścią pętli ponownej pracy.
Opis

Ten atrybut logiczny ma wartość true, jeśli konkretna czynność, na przykład „Weryfikacja dokumentów”, występuje w tej samej sprawie więcej niż raz. Często dzieje się tak po zdarzeniu takim jak „Poproszono o dodatkowe informacje”.

Wykrywanie ponownej pracy pomaga wskazać nieefektywne elementy procesu i trudności, z którymi mierzy się klient. Dashboard „Ponowna praca i pętle w procesie” wykorzystuje ten atrybut do określenia częstotliwości i wpływu ponownej pracy. Jej ograniczenie często stanowi jeden z celów, ponieważ skraca czas obsługi, obniża koszty operacyjne i poprawia jakość obsługi klienta.

Dlaczego to ważne

Ujawnia nieefektywne elementy procesu, zbędne zadania i pętle, które warto objąć działaniami usprawniającymi.

Skąd pobrać

Flaga jest wyliczana podczas analizy danych przez sprawdzenie, czy nazwy czynności powtarzają się w ramach tego samego identyfikatora sprawy. Przykładem jest drugie wystąpienie czynności „Zakończono weryfikację dokumentów”.

Przykłady
truefalse
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu ostatniego odświeżenia lub pobrania danych.
Opis

Ten atrybut wskazuje, kiedy ostatnio pobrano dane z systemu źródłowego. Zwykle ma tę samą wartość dla wszystkich rekordów w ramach jednego załadowania danych.

Znacznik czasu pozwala ocenić aktualność analizowanych danych. Użytkownicy mogą sprawdzić, na ile aktualna jest analiza procesu i kiedy można spodziewać się kolejnej aktualizacji. Ma to znaczenie przy monitorowaniu operacji na dashboardach.

Dlaczego to ważne

Informuje użytkowników o aktualności danych i pozwala ocenić, czy analiza odzwierciedla bieżący stan, czy wcześniejszy okres.

Skąd pobrać

Wartość jest generowana i zapisywana w zbiorze danych podczas procesu ekstrakcji, transformacji i ładowania danych (ETL).

Przykłady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
Identyfikator klienta
CustomerId
Unikalny identyfikator klienta obejmowanego onboardingiem.
Opis

Ten atrybut to unikalny identyfikator łączący wniosek z rekordem klienta w systemie danych podstawowych. Wskazuje osobę lub organizację, której dotyczy proces KYC.

Identyfikator wniosku pozwala śledzić proces, a identyfikator klienta umożliwia analizę wielu wniosków tego samego klienta oraz wzbogacenie danych o procesie o informacje dotyczące klienta, takie jak segment lub historia. Dzięki temu można analizować onboarding z perspektywy klienta.

Dlaczego to ważne

Łączy dane o procesie z danymi podstawowymi klienta, umożliwiając dokładniejszą analizę uwzględniającą jego cechy i historię.

Skąd pobrać

To podstawowa właściwość sprawy KYC, która łączy ją z modelem danych klienta w Pega lub zewnętrznym systemem CRM.

Przykłady
CUST-98765CUST-98766CUST-98767
Kraj klienta
CustomerCountry
Kraj zamieszkania klienta lub rejestracji jego firmy.
Opis

Ten atrybut przechowuje kraj powiązany z klientem obejmowanym onboardingiem. Informacja ta jest ważna przy ocenie ryzyka i ustalaniu wymaganego zakresu analizy due diligence.

Analiza kraju klienta może ujawnić istotne zależności. Niektóre jurysdykcje mogą wiązać się z wyższym ryzykiem, a w konsekwencji z dłuższym i bardziej złożonym onboardingiem. Ten wymiar umożliwia geograficzną analizę wydajności i pomaga sprawdzić, czy wymogi dotyczące zgodności w poszczególnych regionach są spełniane sprawnie.

Dlaczego to ważne

Umożliwia analizę geograficzną procesu, często powiązaną ze złożonością regulacyjną i poziomem ryzyka.

Skąd pobrać

To właściwość obiektu danych klienta powiązanego ze sprawą.

Przykłady
USADEUSGPGBR
Produkt objęty onboardingiem
OnboardedProduct
Produkt finansowy, o który ubiega się klient.
Opis

Ten atrybut określa produkt lub usługę, z której klient będzie korzystać, na przykład „Rachunek bankowy dla klienta indywidualnego”, „Kredyt dla firmy” lub „Usługi inwestycyjne”.

Produkt może wpływać na przebieg onboardingu, ponieważ poszczególne produkty mogą podlegać różnym wymogom regulacyjnym i mieć różny stopień złożoności. Analiza procesu według produktu pomaga ustalić, czy określone linie produktowe wiążą się z dłuższym czasem realizacji lub większą liczbą odrzuceń. Wyniki wskazują możliwości usprawnienia procesu dla konkretnych produktów.

Dlaczego to ważne

Umożliwia analizę procesu z podziałem na linie produktowe, pokazując różnice w wynikach i możliwości usprawnień.

Skąd pobrać

To właściwość sprawy, której wartość wybiera się na początku składania wniosku.

Przykłady
Rachunek bieżącyZarządzanie majątkiemLinia kredytowa dla firmy
Status dokumentów
DocumentStatus
Bieżący status dokumentów dostarczonych przez klienta.
Opis

Ten atrybut śledzi stan dokumentów wymaganych w procesie KYC. Możliwe wartości to na przykład „Oczekuje na dokumenty od klienta”, „Otrzymano”, „Zweryfikowano” lub „Odrzucono”. Status może zmieniać się wielokrotnie w ramach jednej sprawy.

Atrybut ten jest przydatny na dashboardzie „Przepustowość i status onboardingu” oraz w analizie „Czas weryfikacji dokumentów”. Pozwala szczegółowo przyjrzeć się jednemu z najczęstszych obszarów występowania wąskich gardeł. Śledząc czas spędzony w każdym statusie, można wykryć opóźnienia w przekazywaniu dokumentów przez klientów lub ich wewnętrznej weryfikacji.

Dlaczego to ważne

Pokazuje przebieg podprocesu obsługi dokumentów i pomaga wykrywać oraz usuwać częste opóźnienia w ich weryfikacji.

Skąd pobrać

Prawdopodobnie jest to właściwość powiązanego obiektu danych lub listy stron przypisanej do głównej sprawy, która śledzi wymagane dokumenty. Szczegóły można znaleźć w dokumentacji Pega KYC.

Przykłady
Oczekuje na przesłanieOtrzymano, oczekuje na weryfikacjęZatwierdzonyOdrzucono, wymagane dodatkowe informacje
Status SLA
SlaStatus
Informuje, czy sprawę zakończono w terminie określonym w SLA.
Opis

Ten atrybut klasyfikuje każdą zakończoną sprawę jako „W terminie” lub „Po terminie”, porównując faktyczny znacznik czasu zakończenia z „Termin docelowy SLA”.

To podstawowa miara na dashboardzie „Monitorowanie realizacji SLA” i dla KPI „Odsetek spraw zrealizowanych zgodnie z SLA”. Pokazuje, jak przebiega realizacja zobowiązań dotyczących poziomu usług. Analiza cech spraw zakończonych po terminie pomaga ustalić źródłowe przyczyny opóźnień i ograniczyć ryzyko niedotrzymania SLA w przyszłości.

Dlaczego to ważne

Bezpośrednio mierzy realizację zobowiązań, co ma znaczenie dla zarządzania operacjami, zgodności i zadowolenia klientów.

Skąd pobrać

Wartość ustala się przez porównanie znacznika czasu ostatniej czynności w sprawie z polem SlaTargetDate. Jeśli sprawę zakończono po terminie, jej status to „Po terminie”.

Przykłady
W terminiePo terminieZagrożone niedotrzymaniem terminu
System źródłowy
SourceSystem
Wskazuje system, z którego pochodzą dane.
Opis

Ten atrybut określa aplikację źródłową, w której zarejestrowano zdarzenie. W tym procesie jego wartością będzie zawsze „Pega KYC”.

Może się wydawać zbędny, jeśli wszystkie dane pochodzą z jednego systemu. Jest jednak ważny z punktu widzenia zarządzania danymi i niezbędny przy łączeniu danych z wielu systemów. Pozwala ustalić pochodzenie danych i ułatwia rozwiązywanie problemów z integracją.

Dlaczego to ważne

Dostarcza informacji o pochodzeniu danych, wspiera zarządzanie nimi i umożliwia analizę danych z wielu systemów źródłowych.

Skąd pobrać

Zwykle jest to stała wartość dodawana podczas ekstrakcji i transformacji danych, aby oznaczyć źródło zbioru danych.

Przykłady
Pega KYCPega CLM
Typ sprawy
CaseType
Konkretny typ sprawy dotyczącej onboardingu KYC.
Opis

Ten atrybut określa kategorię wniosku o onboarding, na przykład „Klient indywidualny”, „Klient korporacyjny” lub „Klient zamożny”. Różne typy spraw często przebiegają według odmiennych wariantów procesu, z innymi krokami, SLA i profilami ryzyka.

Analiza procesu według typu sprawy pozwala rzetelniej porównywać wyniki. Pomaga ustalić, czy onboarding określonych grup klientów częściej wiąże się z opóźnieniami lub odrzuceniami. Taki podział ułatwia dopasowanie usprawnień do potrzeb poszczególnych ścieżek klienta.

Dlaczego to ważne

Pozwala podzielić dane o procesie na odrębne kategorie, co umożliwia dokładniejszą i bardziej miarodajną analizę wydajności.

Skąd pobrać

W Pega jest to zwykle nazwa klasy instancji sprawy lub dedykowana właściwość określająca jej typ.

Przykłady
Onboarding klienta indywidualnegoOnboarding klienta korporacyjnegoUproszczona analiza due diligence
Wymagane Zalecane Opcjonalne

Działania w procesie onboardingu klientów KYC

To najważniejsze etapy i punkty kontrolne, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odtworzyć przebieg onboardingu klientów KYC i uzyskać szczegółowe wnioski.
8 Zalecane 6 Opcjonalne
Działanie Opis
Odrzucenie wniosku
Oznacza ostateczną decyzję o odrzuceniu wniosku klienta i zakończeniu procesu onboardingu. Zdarzenie można wywnioskować ze zmiany statusu sprawy na końcowy status oznaczający niepowodzenie.
Dlaczego to ważne

To główne zdarzenie oznaczające niepowodzenie procesu. Jest niezbędne do analizy odsetka odrzuconych wniosków i ustalenia przyczyn, na przykład na podstawie atrybutu „Rejection Reason”.

Skąd pobrać

Zdarzenie można wywnioskować ze znacznika czasu ustawienia statusu końcowego sprawy (pyStatusWork) na wartość oznaczającą niepowodzenie, na przykład „Resolved-Rejected”.

Rejestrowanie

Znajdź ostatnią zmianę wartości pyStatusWork, która oznacza odrzucenie sprawy w jej historii audytowej.

Typ zdarzenia inferred
Otrzymanie dokumentów
Oznacza moment, w którym klient przesłał do systemu wszystkie wymagane dokumenty. Zwykle jest rejestrowane jako jawne zdarzenie w chwili dodania nowych załączników do sprawy w Pega.
Dlaczego to ważne

To ważny etap, od którego zaczyna się pomiar czasu realizacji SLA dotyczących przeglądu i weryfikacji dokumentów. Opóźnienia przed tym momentem zależą od klienta, a późniejsze od organizacji.

Skąd pobrać

Zdarzenie jest jawnie rejestrowane w tabelach załączników Pega (pc_link_attachment lub pc_data_workattach), gdy nowy dokument zostaje powiązany ze sprawą.

Rejestrowanie

Zdarzeniem jest znacznik czasu utworzenia odpowiedniego obiektu załącznika powiązanego ze sprawą.

Typ zdarzenia explicit
Przeprowadzenie oceny ryzyka
To działanie oznacza zakończenie oceny ryzyka klienta i nadanie oceny na podstawie danych z wniosku oraz weryfikacji. Jest to ważny etap, zwykle rejestrowany po zakończeniu etapu lub kroku oceny ryzyka w sprawie Pega.
Dlaczego to ważne

To ważny etap związany ze zgodnością. Analiza czasu trwania i wyniku tego działania pozwala ocenić sprawność zarządzania ryzykiem i jego wpływ na przebieg procesu.

Skąd pobrać

Zdarzenie można wywnioskować z zakończenia określonego etapu lub przepływu w modelu sprawy Pega, które powoduje zmianę statusu zapisaną w ścieżce audytu.

Rejestrowanie

Zdarzenie można wywnioskować ze zmiany pyStatusWork po etapie oceny ryzyka, na przykład na „Pending-Compliance-Review”.

Typ zdarzenia inferred
Rozpoczęcie kontroli zgodności
To działanie oznacza rozpoczęcie formalnej kontroli przez zespół ds. zgodności. Jest to ważna i często długotrwała część procesu. Zdarzenie jest rejestrowane, gdy sprawa trafia do kolejki zespołu ds. zgodności lub jej status zostaje odpowiednio zmieniony.
Dlaczego to ważne

To zdarzenie rozpoczyna pomiar KPI dotyczącego czasu kontroli zgodności. Pomaga mierzyć czas i wykrywać wąskie gardła na tym ważnym, często ręcznym etapie.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu sprawy (pyStatusWork) na „Pending-Compliance” lub z utworzenia przypisania w kolejce zadań zespołu ds. zgodności.

Rejestrowanie

Należy ustalić znacznik czasu przypisania sprawy do kolejki zespołu ds. zgodności lub zmiany statusu oznaczającej rozpoczęcie kontroli.

Typ zdarzenia inferred
Zakończenie kontroli zgodności
To działanie oznacza zakończenie kontroli przez zespół ds. zgodności i wydanie rekomendacji. Jest rejestrowane jako zmiana statusu sprawy, która opuszcza etap kontroli zgodności.
Dlaczego to ważne

To zdarzenie kończy pomiar KPI dotyczącego czasu kontroli zgodności. Analiza czasu do tego momentu jest niezbędna do usprawnienia kontroli.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu sprawy (pyStatusWork) z „Pending-Compliance” na przykład na „Pending-Final-Decision” lub „Resolved-Approved”.

Rejestrowanie

Należy ustalić znacznik czasu zakończenia etapu kontroli zgodności lub przypisania w historii sprawy.

Typ zdarzenia inferred
Zakończenie onboardingu
To działanie oznacza pomyślne zakończenie całego procesu onboardingu KYC. Jest rejestrowane, gdy sprawa w Pega otrzymuje końcowy status rozwiązania wskazujący na pomyślne zakończenie i wykonanie wszystkich działań w systemach docelowych.
Dlaczego to ważne

To główne zdarzenie oznaczające pomyślne zakończenie procesu. Jest niezbędne do obliczenia czasu realizacji od początku do końca dla wszystkich klientów, których onboarding zakończył się powodzeniem.

Skąd pobrać

Zdarzenie można wywnioskować ze znacznika czasu ustawienia statusu końcowego sprawy (pyStatusWork) na wartość oznaczającą powodzenie, na przykład „Resolved-Completed”.

Rejestrowanie

Należy ustalić znacznik czasu ostatniego statusu „Resolved-Completed” w tabeli History-Work.

Typ zdarzenia inferred
Zatwierdzenie wniosku
Oznacza ostateczną decyzję o zatwierdzeniu wniosku klienta o onboarding. To ważny etap biznesowy, który można wywnioskować z ustawienia końcowego statusu sprawy oznaczającego pomyślne zakończenie.
Dlaczego to ważne

To ważny etap oddzielający sprawy zakończone powodzeniem od nieudanych. Poprzedza końcowe działania związane z aktywacją konta i jest częstym punktem pomiaru czasu podejmowania decyzji.

Skąd pobrać

Zdarzenie można wywnioskować ze znacznika czasu ustawienia statusu końcowego sprawy (pyStatusWork) na wartość oznaczającą powodzenie, na przykład „Resolved-Completed” lub „Resolved-Approved”.

Rejestrowanie

Należy znaleźć w ścieżce audytu sprawy ostatnią aktualizację pyStatusWork oznaczającą pomyślne zakończenie.

Typ zdarzenia inferred
Złożenie wniosku
To działanie oznacza utworzenie nowej sprawy onboardingowej klienta w systemie Pega. Jest rejestrowane w chwili oficjalnego rozpoczęcia obsługi wniosku, przez portal klienta, użytkownika wewnętrznego lub automatyczny kanał przekazywania danych.
Dlaczego to ważne

To główne zdarzenie rozpoczynające cały proces onboardingu. Jest niezbędne do pomiaru czasu realizacji od początku do końca oraz analizy liczby i wzorców składania wniosków.

Skąd pobrać

To jawne zdarzenie rejestrowane w ścieżce audytu Pega podczas tworzenia nowego obiektu pracy (sprawy). Należy znaleźć pierwszy wpis dotyczący identyfikatora sprawy w tabeli pc_history_work.

Rejestrowanie

Znacznik czasu można pobrać z chwili utworzenia sprawy w tabeli pc_work lub z pierwszego wpisu w ścieżce audytu.

Typ zdarzenia explicit
Aktywacja konta
To działanie oznacza pomyślne utworzenie i aktywację konta klienta w systemie bankowym lub innym systemie docelowym. Często można je wywnioskować z końcowej aktualizacji statusu sprawy w Pega po jej zatwierdzeniu.
Dlaczego to ważne

To moment, w którym klient i firma uzyskują wymierną korzyść. Czas między zdarzeniami „Zatwierdzenie wniosku” i „Aktywacja konta” pokazuje sprawność przekazywania danych między systemami.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu sprawy (pyStatusWork) na przykład na „Resolved-AccountActive” lub z ustawienia flagi w sprawie przez integrację, zapisanego w ścieżce audytu.

Rejestrowanie

Należy ustalić znacznik czasu aktualizacji właściwości sprawy wskazującej, że konto w systemie docelowym jest aktywne.

Typ zdarzenia inferred
Prośba o dodatkowe informacje
Zdarzenie występuje, gdy osoba kontrolująca, zwykle z zespołu ds. zgodności, potrzebuje od klienta dodatkowych informacji lub wyjaśnień. Często jest rejestrowane jawnie, gdy użytkownik wysyła korespondencję ze sprawy.
Dlaczego to ważne

To działanie jest głównym wskaźnikiem poprawek i pętli w procesie. Śledzenie jego częstotliwości jest niezbędne do pomiaru odsetka spraw obsłużonych poprawnie za pierwszym razem i wykrywania niejasnych wymagań.

Skąd pobrać

Może to być jawne zdarzenie „Send Correspondence” zapisane w ścieżce audytu. Można je też wywnioskować ze zmiany statusu na „Pending-Customer-Info”.

Rejestrowanie

Zdarzenie można zarejestrować na podstawie utworzenia określonego obiektu korespondencji lub działania w przepływie zainicjowanego przez pracownika obsługującego sprawę.

Typ zdarzenia explicit
Prośba o dokumenty
To działanie ma miejsce, gdy system lub pracownik ustali, że do dalszej obsługi potrzebne są dokumenty od klienta. Można je wykryć na podstawie utworzenia korespondencji lub zmiany statusu sprawy na przykład na „Pending-Customer-Docs”.
Dlaczego to ważne

Śledzenie tego zdarzenia pozwala zmierzyć czas odpowiedzi klientów i sprawdzić, czy proces często zatrzymuje się z powodu oczekiwania na dokumenty. Jest to zdarzenie poprzedzające KPI dotyczący czasu weryfikacji dokumentów.

Skąd pobrać

Może to być jawne zdarzenie korespondencji (pc_link_attachment) lub zdarzenie wywnioskowane ze zmiany statusu sprawy (pyStatusWork) zapisanej w ścieżce audytu.

Rejestrowanie

Zdarzenie można wywnioskować ze zmiany pyStatusWork na „Pending-Documents” lub podobny status. Można je też powiązać z jawnym zdarzeniem „Send Correspondence”.

Typ zdarzenia inferred
Przeprowadzenie wstępnej weryfikacji
Oznacza zakończenie wstępnej, często zautomatyzowanej kontroli kompletności danych we wniosku i podstawowych kryteriów kwalifikacji. Zdarzenie to zwykle wnioskuje się na podstawie zmiany statusu sprawy, na przykład z „New” na „Pending-Documents”.
Dlaczego to ważne

Analiza czasu trwania tego etapu pozwala wykryć wczesne wąskie gardła związane z walidacją danych lub wykonywaniem reguł automatycznych, które mogą opóźnić cały proces.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu sprawy (pyStatusWork) zapisanej w ścieżce audytu Pega (tabela History-Work).

Rejestrowanie

Należy ustalić znacznik czasu zmiany pyStatusWork ze stanu „New” lub „Submitted” na „ScreeningComplete” albo podobny.

Typ zdarzenia inferred
Rozpoczęcie kontroli przeszłości
Oznacza rozpoczęcie zewnętrznej lub wewnętrznej kontroli klienta, która może obejmować integrację z usługami zewnętrznymi. Zdarzenie zwykle można wywnioskować ze zmiany statusu wskazującej, że sprawa oczekuje na wyniki kontroli.
Dlaczego to ważne

To działanie pozwala oddzielić czas oczekiwania na podmioty zewnętrzne. Ułatwia analizę jakości ich usług i wpływu na całkowity czas onboardingu.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu sprawy (pyStatusWork) na „Pending-Background-Check” lub podobny, zapisanej w tabeli History-Work w Pega.

Rejestrowanie

Należy ustalić znacznik czasu aktualizacji pyStatusWork wskazującej rozpoczęcie kontroli przeszłości.

Typ zdarzenia inferred
Zakończenie przeglądu dokumentów
To działanie oznacza zakończenie przeglądu dokumentów przesłanych przez klienta przez specjalistę ds. zgodności lub proces automatyczny. Zdarzenie można wywnioskować ze zmiany statusu sprawy lub dokumentu wskazującej, że przegląd dobiegł końca.
Dlaczego to ważne

To zdarzenie kończy pomiar KPI dotyczącego czasu weryfikacji dokumentów. Analiza czasu realizacji tego etapu pozwala wykryć nieefektywności w ręcznym lub automatycznym przeglądzie.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu sprawy (pyStatusWork) w ścieżce audytu ze stanu „Pending-Review” na „Review-Complete” lub „Pending-Checks”.

Rejestrowanie

Należy ustalić znacznik czasu zmiany statusu sprawy (pyStatusWork), która oznacza zakończenie podprocesu weryfikacji dokumentów.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje pozyskiwania danych

Jak pobrać dane z Pega KYC

Jak zacząć?

Ten szablon danych stanowi punkt wyjścia do usprawniania procesu onboardingu klientów KYC. Pozwala wykrywać nieefektywności i wspierać zgodność.

Usprawnij onboarding KYC i ogranicz opóźnienia

Uprość onboarding KYC, skróć go do 24 godzin i popraw zgodność.

Rozpocznij bezpłatny okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.