Šablona dat pro KYC onboarding zákazníků
Šablona dat pro KYC onboarding zákazníků
- Doporučené atributy pro záznam událostí
- Hlavní aktivity, které je třeba v průběhu procesu sledovat
- Praktické pokyny k extrakci dat
Atributy KYC onboardingu zákazníků
| Název | Popis | ||
|---|---|---|---|
|
Aktivita
ActivityName
|
Název konkrétní události nebo úkolu, který proběhl v rámci onboardingu. | ||
|
Popis
Tento atribut zaznamenává název obchodní činnosti nebo systémové události, například „Žádost odeslána“, „Zahájena kontrola shody“ nebo „Žádost zamítnuta“. Představuje jeden krok v celém procesu onboardingu zákazníka. Analýza činností je základem process mining. Tento atribut slouží k vytvoření mapy procesu, která znázorňuje návaznost jednotlivých kroků. Pomáhá určit pořadí událostí, měřit četnost jednotlivých činností a zjistit, které úkoly jsou nejčastější nebo trvají nejdéle.
Proč je to důležité
Tento atribut určuje kroky v mapě procesu a umožňuje průběh procesu zobrazit, analyzovat a pochopit.
Kde data získat
Tyto informace se obvykle zaznamenávají v auditní stopě Pega (tabulkách historie) nebo je lze odvodit ze změn stavu případu.
Příklady
Provedena úvodní kontrolaKontrola shody dokončenaŽádost schválena
|
|||
|
Čas zahájení
EventTime
|
Časové razítko označující začátek činnosti nebo události. | ||
|
Popis
Tento atribut zaznamenává přesné datum a čas zahájení činnosti. Určuje chronologické pořadí všech událostí v rámci jedné žádosti zákazníka. Časová razítka jsou základem analýzy výkonnosti procesu. Slouží k výpočtu délky činností, čekání mezi kroky a celkové doby průchodu onboardingem od začátku do konce. Tyto údaje pomáhají odhalit úzká místa, měřit plnění SLA a porozumět efektivitě procesu.
Proč je to důležité
Časová razítka poskytují chronologický kontext potřebný k výpočtu dob trvání, analýze výkonnosti procesu a odhalení zpoždění.
Kde data získat
Jde o standardní součást auditní stopy Pega. V tabulkách historie bývá u každé události často uvedeno jako pxTimeCreated.
Příklady
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
|
|||
|
Žádost zákazníka
CustomerApplication
|
Jedinečný identifikátor každého případu onboardingu zákazníka. | ||
|
Popis
Žádost zákazníka je hlavním identifikátorem případu, který sdružuje všechny související činnosti a události v rámci onboardingu jednoho zákazníka. Každá žádost prochází cestou od podání až po schválení a aktivaci účtu, nebo zamítnutí. V process mining je tento atribut nezbytný pro rekonstrukci celé cesty každé žádosti. Analytici díky němu mohou zobrazit úplnou posloupnost událostí, sledovat stav jednotlivých žádostí a porovnávat různé průběhy. Analýza případů podle tohoto ID pomáhá odhalit časté varianty procesu, úzká místa a odchylky od standardního postupu.
Proč je to důležité
Toto ID je základem process mining, protože propojuje jednotlivé události do souvislých instancí procesu od začátku do konce, které lze analyzovat.
Kde data získat
V Pega jde obvykle o hlavní ID případu, často dostupné jako pzInsKey nebo pod srozumitelnějším obchodním názvem v hlavním objektu případu.
Příklady
APP-2023-00123APP-2023-00124APP-2023-00125
|
|||
|
Čas ukončení
EndTime
|
Časové razítko označující dokončení činnosti nebo události. | ||
|
Popis
Tento atribut zaznamenává přesné datum a čas ukončení činnosti. Spolu s časem zahájení slouží k výpočtu doby zpracování jednotlivých činností. Samostatný čas ukončení umožňuje přesnější analýzu výkonnosti. Pomáhá rozlišit dobu aktivního zpracování, tedy čas mezi zahájením a ukončením činnosti, od čekání, které trvá od ukončení jedné činnosti do zahájení další. Díky tomu lze určit skutečná úzká místa a odlišit je od čekání ve frontě.
Proč je to důležité
Umožňuje přesně vypočítat dobu zpracování činnosti, což je důležité pro podrobnou analýzu výkonnosti a odhalování úzkých míst.
Kde data získat
Tento údaj může být dostupný v auditní stopě Pega. Pokud chybí, lze jako čas ukončení aktuální události použít čas zahájení následující události.
Příklady
2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
|
|||
|
Cílové datum SLA
SlaTargetDate
|
Datum, do kterého má být případ onboardingu zákazníka dokončen. | ||
|
Popis
Tento atribut uchovává cílové datum dokončení žádosti stanovené dohodou o úrovni služeb (SLA). SLA se může lišit podle typu zákazníka, míry rizika nebo produktu. Toto datum je důležité pro dashboard „Sledování plnění SLA“ a související KPI. Slouží jako měřítko pro porovnání se skutečným datem dokončení. Analýza případů, které cílové datum SLA nesplní, pomáhá odhalit systémová zpoždění a určit, které změny procesu mají přednost, aby byly dodrženy závazky vůči zákazníkům.
Proč je to důležité
Poskytuje měřítko pro hodnocení včasného dokončení, které je důležité pro spokojenost zákazníků i řízení provozu.
Kde data získat
Pega obsahuje vestavěný rámec pro správu SLA. Toto datum se obvykle ukládá ve vlastnostech, jako je pySLAGoal, nebo ve vlastní vlastnosti SLA případu.
Příklady
2023-11-10T17:00:00Z2023-11-15T17:00:00Z
|
|||
|
Důvod zamítnutí
RejectionReason
|
Uvádí důvod zamítnutí žádosti. | ||
|
Popis
Pokud je konečný stav žádosti „Zamítnuto“, tento atribut uvádí konkrétní důvod, například „Neúspěšné prověření“, „Neúplná dokumentace“ nebo „Vysoká míra rizika“. Tento atribut je hlavním podkladem pro dashboard „Analýza zamítnutých žádostí“. Rozdělení zamítnutých případů podle důvodu pomáhá firmě zjistit, ve kterých částech onboardingu žádosti nejčastěji neprojdou. Tyto poznatky umožňují cíleně upravit proces, snížit míru zamítnutí, zlepšit zákaznickou zkušenost a zvýšit efektivitu provozu.
Proč je to důležité
Ukazuje, proč žádosti neprojdou, a umožňuje cíleně upravit proces tak, aby se zvýšila úspěšnost.
Kde data získat
Pravděpodobně jde o konkrétní vlastnost nastavenou při přechodu případu do stavu „Zamítnuto“. Standardní pole pro důvod zamítnutí najdete v dokumentaci Pega KYC.
Příklady
Nález na sankčním seznamuNesoulad v dokumentaciIdentifikace politicky exponované osobyNedostatek informací
|
|||
|
Míra rizika
RiskLevel
|
Vypočítaná míra rizika žádosti zákazníka. | ||
|
Popis
Tento atribut vyjadřuje vyhodnocené riziko spojené se zákazníkem, obvykle označené jako „Nízké“, „Střední“ nebo „Vysoké“. Míru rizika zpravidla určuje automatizovaný nástroj pro výpočet skóre na základě údajů o zákazníkovi a výsledků prověření. Míra rizika výrazně ovlivňuje průběh procesu. U žádostí s vysokým rizikem jsou často nutné další kroky hloubkové kontroly, například rozšířená kontrola shody, což prodlužuje dobu průchodu. Analýza podle míry rizika pomáhá vysvětlit tyto rozdíly a ověřit, zda kontroly rizik fungují účinně a nezpůsobují zbytečná zpoždění.
Proč je to důležité
Vysvětluje rozdíly v průběhu a délce procesu, protože míra rizika často určuje požadovaný rozsah hloubkové kontroly.
Kde data získat
Jde o vypočítanou vlastnost případu, kterou naplňuje rozhodovací pravidlo nebo model pro výpočet skóre v Pega. Podrobnosti najdete v dokumentaci Pega KYC.
Příklady
NízkáStředníVysoká
|
|||
|
Oddělení
WorkGroup
|
Oddělení nebo funkční tým odpovědný za činnost. | ||
|
Popis
Tento atribut určuje organizační jednotku nebo tým, do kterého patří uživatel provádějící činnost, například „Tým prověřování“, „Kontrola shody“ nebo „Provoz onboardingu“. Analýza procesu podle oddělení je důležitá pro dashboard „Rozložení pracovní zátěže podle oddělení“. Manažeři díky ní vidí, jak práce přechází mezi týmy, mohou odhalit úzká místa na rozhraní týmů a posoudit rozdělení zdrojů v celém procesu onboardingu. Pomáhá také zlepšit předávání práce a vyrovnat pracovní zátěž.
Proč je to důležité
Umožňuje analyzovat průběh procesu a úzká místa mezi různými organizačními jednotkami a podporuje řízení zdrojů i zlepšování organizace.
Kde data získat
Tyto informace jsou obvykle součástí profilu uživatele v Pega (záznam Operator ID) a lze je propojit s údaji o událostech. Příslušnou vlastností může být pyWorkGroup.
Příklady
Úvodní prověřeníKontrola shodyAktivace účtu
|
|||
|
Stav žádosti
ApplicationStatus
|
Konečný výsledek nebo aktuální stav žádosti zákazníka. | ||
|
Popis
Tento atribut uvádí celkový stav žádosti na konci procesu, například „Schváleno“, „Zamítnuto“ nebo „Staženo“. U probíhajících případů může zachycovat také poslední známý stav. Jde o důležitý rozměr analýzy výsledků. V dashboardu „Analýza zamítnutých žádostí“ slouží k rozdělení případů do skupin a zjištění, proč končí určitým výsledkem. Analýza průběhů vedoucích k různým stavům pomáhá určit osvědčené postupy u schválených případů a hlavní příčiny zamítnutí.
Proč je to důležité
Určuje obchodní výsledek případu a umožňuje porovnat úspěšné a neúspěšné průběhy.
Kde data získat
V Pega jde obvykle o konečný stav případu (pyStatusWork) v objektu případu.
Příklady
SchválenoZamítnutoČeká se na kontrolu shodyZákazník žádost stáhl
|
|||
|
Uživatel
OperatorId
|
Jedinečný identifikátor uživatele, který činnost provedl. | ||
|
Popis
Tento atribut uchovává ID zaměstnance nebo systémového uživatele odpovědného za konkrétní úkol v procesu KYC, například pracovníka kontroly shody nebo automatizovaného nástroje pro prověřování. U automatizovaných kroků může jít o ID systémového nebo servisního účtu. Analýza podle uživatele pomáhá porozumět rozložení pracovní zátěže, individuální výkonnosti a potřebám školení. Lze ji využít také při zkoumání odchylek od procesu, protože ukáže, kteří uživatelé nebo týmy se podílejí na nestandardních průbězích.
Proč je to důležité
Tento atribut propojuje činnosti procesu s konkrétními uživateli nebo týmy a umožňuje analyzovat pracovní zátěž, hodnotit výkonnost a kontrolovat shodu.
Kde data získat
Jde o standardní pole v auditní stopě Pega. V tabulkách historie se obvykle ukládá jako pxUpdateOperator nebo podobná vlastnost.
Příklady
j.doe@acmebank.comkyc_analyst_04system_auto_agent
|
|||
|
Automatizovaná činnost
IsAutomated
|
Příznak určující, zda činnost provedl systém, nebo člověk. | ||
|
Popis
Tento logický atribut má hodnotu true, pokud činnost provedl automatizovaný nástroj, například systém pro prověřování nebo systémové pravidlo. Pokud ji provedl člověk, má hodnotu false. Rozlišení automatizovaných a manuálních činností je důležité pro analýzu automatizace. Pomáhá měřit účinnost stávající automatizace, určit manuální úkoly vhodné k budoucí automatizaci a porozumět spolupráci lidí a systémů v procesu.
Proč je to důležité
Rozlišuje činnosti prováděné lidmi od činností prováděných systémy, což je základem analýzy i plánování automatizace.
Kde data získat
Tento údaj lze odvodit z ID uživatele přiřazeného k události. Pokud OperatorId odpovídá známému systémovému nebo servisnímu účtu, příznak se nastaví na true.
Příklady
truefalse
|
|||
|
Doba průchodu
CycleTime
|
Celková doba od podání žádosti po její konečné vyřízení. | ||
|
Popis
Tato vypočítaná metrika měří dobu průchodu každé žádosti zákazníka od první události po poslední. Obvykle se počítá jako rozdíl mezi časovým razítkem poslední a první činnosti v daném případu. Doba průchodu je hlavním KPI efektivity procesu a zákaznické zkušenosti. V dashboardu „Analýza celkové doby průchodu onboardingem“ slouží ke sledování průměrné doby zpracování, odhalování dlouho trvajících případů a vyhodnocování dopadu změn procesu v čase.
Proč je to důležité
Tento KPI přímo měří celkovou rychlost a efektivitu onboardingu z pohledu zákazníka.
Kde data získat
Tato metrika se v nástroji process mining vypočítá jako rozdíl mezi nejvyšším a nejnižším časovým razítkem pro každé ID případu.
Příklady
5 dní 4 hodiny12 dní 1 hodina2 dny 8 hodin
|
|||
|
ID zákazníka
CustomerId
|
Jedinečný identifikátor zákazníka, který prochází onboardingem. | ||
|
Popis
Tento atribut obsahuje jedinečné ID, které propojuje žádost se záznamem zákazníka v systému kmenových dat. Označuje osobu nebo organizaci, na kterou se proces KYC vztahuje. ID žádosti sleduje průběh procesu, zatímco ID zákazníka umožňuje analyzovat více žádostí téhož zákazníka nebo doplnit procesní data o údaje, jako je zákaznický segment či historie. Díky tomu lze onboarding analyzovat z pohledu zákazníka.
Proč je to důležité
Propojuje procesní data s kmenovými daty zákazníků a umožňuje podrobnější analýzu podle jejich vlastností a historie.
Kde data získat
Jde o základní vlastnost případu KYC, která jej propojuje s datovým modelem zákazníka v Pega nebo v externím CRM.
Příklady
CUST-98765CUST-98766CUST-98767
|
|||
|
Opakované zpracování
IsRework
|
Příznak určující, zda je činnost součástí smyčky opakovaného zpracování. | ||
|
Popis
Tento logický atribut má hodnotu true, pokud se konkrétní činnost, například „Kontrola dokumentů“, v rámci jednoho případu opakuje. Často k tomu dochází po událostech, jako je „Vyžádány další informace“. Odhalení opakovaného zpracování pomáhá najít neefektivní místa procesu a překážky pro zákazníka. Dashboard „Opakované zpracování a smyčky v procesu“ pomocí tohoto atributu měří četnost a dopad opakovaných činností. Jejich omezení bývá důležitým cílem, protože zkracuje dobu zpracování, snižuje provozní náklady a zlepšuje zákaznickou zkušenost.
Proč je to důležité
Upozorňuje na neefektivní části procesu, nadbytečné úkoly a smyčky, které patří mezi hlavní cíle zlepšování procesů.
Kde data získat
Tento příznak se odvozuje při analýze dat kontrolou opakovaných názvů činností v rámci stejného ID případu. Například když se podruhé objeví „Kontrola dokumentů dokončena“.
Příklady
truefalse
|
|||
|
Poslední aktualizace dat
LastDataUpdate
|
Časové razítko poslední aktualizace nebo extrakce dat. | ||
|
Popis
Tento atribut uvádí, kdy byla data naposledy extrahována ze zdrojového systému. V rámci jednoho načtení dat bývá jeho hodnota obvykle stejná u všech záznamů. Časové razítko pomáhá určit, jak aktuální jsou analyzovaná data. Uživatelé díky němu vědí, k jakému okamžiku se analýza procesu vztahuje a kdy se očekává další aktualizace. To je důležité pro dashboardy, které slouží ke sledování provozu.
Proč je to důležité
Informuje uživatele o aktuálnosti dat, aby věděli, zda analýza zachycuje současný stav, nebo dřívější období.
Kde data získat
Tato hodnota se generuje a přidává k datové sadě během procesu extrakce, transformace a načítání dat (ETL).
Příklady
2023-11-01T02:00:00Z2023-11-02T02:00:00Z
|
|||
|
Produkt, který zákazník využívá
OnboardedProduct
|
Finanční produkt, o který zákazník žádá. | ||
|
Popis
Tento atribut určuje produkt nebo službu, pro kterou zákazník prochází onboardingem, například „Osobní bankovní účet“, „Firemní úvěr“ nebo „Investiční služby“. Produkt může ovlivnit průběh onboardingu, protože různé produkty mohou podléhat odlišným regulatorním požadavkům a mít různou náročnost. Analýza podle produktu pomáhá zjistit, zda některé produktové řady mají delší dobu průchodu nebo vyšší míru zamítnutí. Tyto poznatky lze využít ke zlepšení procesu pro konkrétní produkty.
Proč je to důležité
Umožňuje analyzovat proces podle produktové řady a odhalit rozdíly ve výkonnosti i možnosti zlepšení.
Kde data získat
Jde o vlastnost případu, která se vybírá na začátku procesu podání žádosti.
Příklady
Běžný účetSpráva majetkuÚvěrový rámec pro podnikání
|
|||
|
Stav dokumentů
DocumentStatus
|
Aktuální stav dokumentů dodaných zákazníkem. | ||
|
Popis
Tento atribut sleduje stav dokumentů požadovaných v procesu KYC. Může nabývat hodnot jako „Čeká se na zákazníka“, „Přijato“, „Ověřeno“ nebo „Zamítnuto“. Během jednoho případu se může změnit několikrát. Atribut je důležitý pro dashboard „Průchodnost a stav onboardingu“ a analýzu „Rychlost ověření dokumentů“. Umožňuje podrobně sledovat jednu z nejčastějších oblastí s úzkými místy. Pokud firma sleduje, jak dlouho dokumenty zůstávají v jednotlivých stavech, může odhalit zpoždění při jejich dodání zákazníkem nebo při interní kontrole.
Proč je to důležité
Zpřehledňuje dílčí proces práce s dokumenty a pomáhá odhalit a řešit častá zpoždění při jejich ověřování.
Kde data získat
Pravděpodobně jde o vlastnost souvisejícího datového objektu nebo seznamu stránek připojeného k hlavnímu případu, který sleduje jednotlivé požadované dokumenty. Podrobnosti najdete v dokumentaci Pega KYC.
Příklady
Čeká se na nahráníPřijato, čeká na kontroluSchválenoZamítnuto, je třeba doplnit informace
|
|||
|
Stav SLA
SlaStatus
|
Určuje, zda byl případ dokončen v cílovém termínu SLA. | ||
|
Popis
Tento atribut označuje každý dokončený případ jako „Včas“ nebo „Opožděně“ podle porovnání skutečného času dokončení s „Cílovým datem SLA“. Jde o hlavní metriku dashboardu „Sledování plnění SLA“ a KPI „Míra plnění SLA“. Přehledně ukazuje, jak si proces vede ve srovnání se závaznými úrovněmi služeb. Analýza vlastností opožděných případů pomáhá odhalit hlavní příčiny zpoždění a omezit riziko budoucího nesplnění SLA.
Proč je to důležité
Přímo měří plnění závazků, což je důležité pro řízení provozu, shodu i spokojenost zákazníků.
Kde data získat
Hodnota se odvozuje porovnáním časového razítka poslední činnosti případu s polem SlaTargetDate. Pokud je případ dokončen po cílovém termínu, stav je „Opožděně“.
Příklady
VčasOpožděněOhroženo
|
|||
|
Typ případu
CaseType
|
Konkrétní typ případu onboardingu KYC. | ||
|
Popis
Tento atribut zařazuje žádost o onboarding do kategorie, například „Fyzická osoba“, „Firemní klient“ nebo „Klient s vysokým čistým jměním“. Různé typy případů často procházejí odlišnými variantami procesu s různými kroky, SLA a mírou rizika. Analýza procesu podle typu případu umožňuje smysluplnější srovnání výkonnosti. Pomáhá zjistit, zda se některé typy onboardingu častěji zpožďují nebo zamítají. Toto rozdělení je důležité pro přizpůsobení změn procesu potřebám různých zákaznických cest.
Proč je to důležité
Rozděluje procesní data do samostatných kategorií a umožňuje přesnější a relevantnější analýzu výkonnosti.
Kde data získat
V Pega jde obvykle o název třídy instance případu nebo o vyhrazenou vlastnost případu, která určuje jeho typ.
Příklady
Onboarding fyzické osobyOnboarding firemního klientaZjednodušená hloubková kontrola
|
|||
|
Zdrojový systém
SourceSystem
|
Určuje systém, ze kterého data pocházejí. | ||
|
Popis
Tento atribut označuje zdrojovou aplikaci, ve které byla událost zaznamenána. V tomto procesu by jeho hodnota byla vždy „Pega KYC“. Pokud všechna data pocházejí z jednoho systému, může se tento atribut zdát nadbytečný. Je však důležitý pro správu dat a nezbytný při propojování údajů z více systémů. Umožňuje určit původ dat a pomáhá řešit problémy s jejich integrací.
Proč je to důležité
Poskytuje důležitý kontext o původu dat, podporuje jejich správu a umožňuje analýzu napříč více zdrojovými systémy.
Kde data získat
Obvykle jde o statickou hodnotu, která se k datové sadě přidává během extrakce a transformace dat, aby označila jejich původ.
Příklady
Pega KYCPega CLM
|
|||
|
Země zákazníka
CustomerCountry
|
Země, ve které má zákazník bydliště nebo sídlo. | ||
|
Popis
Tento atribut uchovává zemi spojenou se zákazníkem, který prochází onboardingem. Jde o důležitý vstup pro posouzení rizika a určení požadovaného rozsahu hloubkové kontroly. Analýza země zákazníka může odhalit důležité souvislosti. Některé jurisdikce mohou znamenat vyšší riziko a vést k delšímu a složitějšímu onboardingu. Toto členění umožňuje porovnávat výkonnost podle zeměpisné oblasti a pomáhá zajistit efektivní plnění regionálních požadavků na shodu.
Proč je to důležité
Umožňuje geografickou analýzu procesu, která často souvisí s regulatorními požadavky a mírou rizika.
Kde data získat
Jde o vlastnost datového objektu zákazníka přiřazeného k případu.
Příklady
USADEUSGPGBR
|
|||
Aktivity KYC onboardingu zákazníků
| Aktivita | Popis | ||
|---|---|---|---|
|
Dokumenty přijaty
|
Označuje okamžik, kdy zákazník do systému nahrál nebo jinak dodal všechny požadované dokumenty. Obvykle se zaznamená jako výslovná událost při připojení nových příloh k případu v Pega. | ||
|
Proč je to důležité
Jde o důležitý milník, od kterého se začínají počítat lhůty SLA pro kontrolu a ověření dokumentů. Prodlevy před tímto okamžikem závisí na zákazníkovi, prodlevy po něm už na interním zpracování.
Kde data získat
Událost se výslovně zaznamená v tabulkách příloh Pega (pc_link_attachment nebo pc_data_workattach), když se k případu připojí nový dokument.
Zachycení
Časem události je časové razítko vytvoření příslušného objektu přílohy propojeného s případem.
Typ události
explicit
|
|||
|
Kontrola shody dokončena
|
Tato aktivita označuje dokončení kontroly týmem odpovědným za shodu a vydání doporučení. Zaznamená se změnou stavu případu, který tím opustí fázi kontroly shody. | ||
|
Proč je to důležité
Tato událost ukončuje měření KPI Doba kontroly shody. Analýza doby do tohoto okamžiku je důležitá pro zefektivnění kontroly.
Kde data získat
Událost se odvozuje ze změny stavu případu (pyStatusWork) z „Pending-Compliance“ na „Pending-Final-Decision“, „Resolved-Approved“ nebo podobný stav.
Zachycení
Zjistěte časové razítko dokončení fáze kontroly shody nebo přiřazení v historii případu.
Typ události
inferred
|
|||
|
Onboarding dokončen
|
Tato aktivita označuje úspěšné dokončení celého procesu KYC onboarding. Zaznamená se, když případ v Pega dosáhne konečného stavu vyřešení, který potvrzuje úspěšné dokončení a provedení všech navazujících kroků. | ||
|
Proč je to důležité
Jde o hlavní koncovou událost úspěšného procesu. Je nezbytná pro výpočet celkové doby zpracování u všech úspěšně onboardovaných zákazníků.
Kde data získat
Událost se odvozuje z časového razítka, kdy je stav vyřešení případu (pyStatusWork) nastaven na konečnou úspěšnou hodnotu, například „Resolved-Completed“.
Zachycení
V tabulce History-Work zjistěte časové razítko posledního stavu „Resolved-Completed“.
Typ události
inferred
|
|||
|
Provedeno posouzení rizik
|
Tato aktivita označuje dokončení posouzení a vyhodnocení rizika zákazníka na základě údajů z žádosti a ověření. Jde o důležitý milník, který se obvykle zaznamená při vyřešení fáze nebo kroku posouzení rizik v případu Pega. | ||
|
Proč je to důležité
Jde o důležitý milník z hlediska shody s předpisy. Analýza délky a výsledku této aktivity pomáhá pochopit efektivitu řízení rizik a jeho vliv na průběh procesu.
Kde data získat
Událost se odvozuje z dokončení konkrétní fáze nebo toku v modelu případu Pega, které vede ke změně stavu zaznamenané v auditní stopě.
Zachycení
Událost se odvozuje ze změny pyStatusWork po fázi posouzení rizik, například při přechodu na „Pending-Compliance-Review“.
Typ události
inferred
|
|||
|
Žádost podána
|
Tato aktivita označuje založení nového případu onboardingu zákazníka v systému Pega. Zaznamená se při oficiálním zahájení nového případu zákaznické žádosti, ať už prostřednictvím zákaznického portálu, interním uživatelem nebo automatickým načtením dat. | ||
|
Proč je to důležité
Jde o hlavní počáteční událost celého procesu onboardingu. Je nezbytná pro měření doby zpracování od začátku do konce a analýzu počtu i průběhu podaných žádostí.
Kde data získat
Jde o výslovně zaznamenanou událost v auditní stopě Pega, která zachycuje vytvoření nového pracovního objektu (případu). Vyhledejte první záznam pro ID případu v tabulce pc_history_work.
Zachycení
Čas se získá z časového razítka vytvoření případu v tabulce pc_work nebo z prvního záznamu v auditní stopě.
Typ události
explicit
|
|||
|
Žádost schválena
|
Označuje konečné rozhodnutí schválit žádost zákazníka o onboarding. Jde o důležitý obchodní milník, který se odvozuje z přechodu případu do konečného stavu úspěšného vyřešení. | ||
|
Proč je to důležité
Jde o důležitý milník, který odděluje úspěšné případy od neúspěšných. Předchází závěrečným krokům aktivace účtu a často se od něj měří doba rozhodování.
Kde data získat
Událost se odvozuje z časového razítka, kdy je stav vyřešení případu (pyStatusWork) nastaven na konečnou úspěšnou hodnotu, například „Resolved-Completed“ nebo „Resolved-Approved“.
Zachycení
V auditní stopě případu zjistěte poslední aktualizaci pyStatusWork, která označuje úspěšné vyřešení.
Typ události
inferred
|
|||
|
Žádost zamítnuta
|
Označuje konečné rozhodnutí zamítnout žádost zákazníka, čímž se proces onboardingu ukončí. Událost se odvozuje z přechodu případu do konečného stavu neúspěšného vyřešení. | ||
|
Proč je to důležité
Jde o hlavní koncovou událost neúspěšného procesu. Je důležitá pro analýzu podílu zamítnutých žádostí a pochopení příčin neúspěchu pomocí atributů, jako je „Důvod zamítnutí“.
Kde data získat
Událost se odvozuje z časového razítka, kdy je stav vyřešení případu (pyStatusWork) nastaven na konečnou neúspěšnou hodnotu, například „Resolved-Rejected“.
Zachycení
Najděte poslední změnu pyStatusWork v auditní stopě případu, která označuje zamítnutí.
Typ události
inferred
|
|||
|
Zahájena kontrola shody
|
Tato aktivita označuje začátek formální kontroly týmem odpovědným za shodu. Jde o důležitou a často zdlouhavou část procesu. Zaznamená se při přiřazení případu do pracovní fronty tohoto týmu nebo při odpovídající změně stavu. | ||
|
Proč je to důležité
Tato událost zahajuje měření KPI Doba kontroly shody. Pomáhá měřit dobu této důležité, často ruční fáze a odhalit její úzká místa.
Kde data získat
Událost se odvozuje ze změny stavu případu (pyStatusWork) na „Pending-Compliance“ nebo z vytvoření přiřazení v pracovní frontě týmu odpovědného za shodu.
Zachycení
Zjistěte časové razítko přiřazení případu do pracovní fronty týmu odpovědného za shodu nebo změny stavu, která označuje začátek kontroly.
Typ události
inferred
|
|||
|
Kontrola dokumentů dokončena
|
Tato aktivita označuje dokončení kontroly dokumentů dodaných zákazníkem, kterou provedl pracovník odpovědný za shodu nebo automatizovaný proces. Událost se odvozuje ze změny stavu případu nebo dokumentu, která potvrzuje dokončení kontroly. | ||
|
Proč je to důležité
Tím se uzavírá KPI Doba ověřování dokumentů. Analýza doby potřebné k dokončení tohoto kroku odhalí neefektivitu při ruční nebo automatizované kontrole.
Kde data získat
Událost se odvozuje ze změny stavu případu (pyStatusWork) z „Pending-Review“ na „Review-Complete“ nebo „Pending-Checks“ v auditní stopě.
Zachycení
Zjistěte časové razítko změny stavu případu (pyStatusWork), která označuje dokončení dílčího procesu ověřování dokumentů.
Typ události
inferred
|
|||
|
Provedena úvodní kontrola
|
Označuje dokončení úvodní, často automatizované kontroly úplnosti údajů v žádosti a základních podmínek způsobilosti. Tato událost se obvykle odvozuje ze změny stavu případu, například z „New“ na „Pending-Documents“. | ||
|
Proč je to důležité
Analýza doby strávené v této úvodní fázi pomáhá odhalit počáteční úzká místa při ověřování údajů nebo spouštění automatických pravidel, která mohou zdržet celý proces.
Kde data získat
Událost se odvozuje ze změny vlastnosti stavu případu (pyStatusWork) zaznamenané v auditní stopě Pega (tabulka History-Work).
Zachycení
Zjistěte časové razítko změny pyStatusWork ze stavu „New“ nebo „Submitted“ na „ScreeningComplete“ či podobný stav.
Typ události
inferred
|
|||
|
Účet aktivován
|
Tato aktivita označuje úspěšné vytvoření a aktivaci účtu zákazníka v hlavním bankovním systému nebo navazujícím systému. Často se odvozuje z poslední aktualizace stavu případu v Pega po úspěšném schválení. | ||
|
Proč je to důležité
Jde o okamžik, kdy zákazník i firma získají očekávanou hodnotu. Doba mezi událostmi „Žádost schválena“ a „Účet aktivován“ ukazuje efektivitu předávání mezi systémy.
Kde data získat
Událost se odvozuje z konkrétního stavu případu (pyStatusWork), například „Resolved-AccountActive“, nebo z příznaku nastaveného v případu prostřednictvím integrace a zaznamenaného v auditní stopě.
Zachycení
Zjistěte časové razítko aktualizace vlastnosti případu, která označuje aktivaci účtu v navazujícím systému.
Typ události
inferred
|
|||
|
Vyžádány další informace
|
K této aktivitě dochází, když kontrolor, obvykle z týmu odpovědného za shodu, potřebuje od zákazníka další informace nebo vysvětlení. Událost se často zaznamená přímo při odeslání konkrétní korespondence z případu. | ||
|
Proč je to důležité
Tato aktivita je hlavním ukazatelem opakované práce a smyček v procesu. Sledování její četnosti je důležité pro měření podílu žádostí zpracovaných správně napoprvé a odhalení nejasných požadavků.
Kde data získat
Událost může být výslovně zaznamenána v auditní stopě jako „Send Correspondence“. Lze ji také odvodit ze změny stavu na „Pending-Customer-Info“.
Zachycení
Událost se zaznamená při vytvoření konkrétního objektu korespondence nebo akce toku, kterou zahájil pracovník případu.
Typ události
explicit
|
|||
|
Vyžádány dokumenty
|
K této aktivitě dochází, když systém nebo pracovník zjistí, že zákazník musí dodat konkrétní dokumenty, aby bylo možné pokračovat. Zaznamená se při vytvoření korespondence nebo při změně stavu případu na „Pending-Customer-Docs“ či podobný stav. | ||
|
Proč je to důležité
Sledování této aktivity pomáhá měřit, jak dlouho zákazníkům trvá odpovědět, a zjistit, zda se proces často zastavuje kvůli čekání na dokumenty. Předchází KPI Doba ověřování dokumentů.
Kde data získat
Událost může být zaznamenána přímo jako korespondence (pc_link_attachment) nebo odvozena ze změny stavu případu (pyStatusWork) v auditní stopě.
Zachycení
Událost se odvozuje ze změny pyStatusWork na „Pending-Documents“ či podobný stav. Může být také spojena s výslovnou událostí „Send Correspondence“.
Typ události
inferred
|
|||
|
Zahájeno prověřování
|
Označuje zahájení externího nebo interního prověřování zákazníka, které může zahrnovat integraci se službami třetích stran. Obvykle se odvozuje ze změny stavu, která ukazuje, že případ čeká na výsledky prověření. | ||
|
Proč je to důležité
Tato aktivita pomáhá oddělit dobu čekání na externí služby. Umožňuje analyzovat výkonnost služeb třetích stran a jejich vliv na celkovou dobu onboardingu.
Kde data získat
Událost se odvozuje ze změny stavu případu (pyStatusWork) na „Pending-Background-Check“ či podobný stav zaznamenaný v tabulce History-Work systému Pega.
Zachycení
Zjistěte časové razítko aktualizace pyStatusWork, která označuje zahájení prověřování.
Typ události
inferred
|
|||
Návody k extrakci dat
Chcete začít?
Tato datová šablona vám poskytne pevný základ pro zlepšování procesu KYC onboardingu zákazníků. Začněte odhalovat neefektivity a podporovat shodu ještě dnes.
Zjednodušte KYC onboarding a omezte prodlevy
Zjednodušte KYC, zkraťte onboarding na 24 hodin a podpořte shodu.
Bez platební karty, nastavení zvládnete za několik minut