Šablona dat pro onboarding zákazníků KYC
Šablona dat pro onboarding zákazníků KYC
Toto je obecná šablona dat pro process mining pro proces Onboarding zákazníků KYC. Podrobnější pokyny najdete v šablonách pro konkrétní systémy.
Vyberte konkrétní systém- Podrobný, ale flexibilní výchozí bod pro jakýkoli systém onboardingu KYC.
- Určuje důležité údaje potřebné pro efektivní mapování a analýzu procesů.
- Univerzální rámec, který můžete použít před přechodem k podrobnostem konkrétního systému.
Atributy onboardingu zákazníků KYC
| Název | Popis | ||
|---|---|---|---|
| Čas zahájení události EventStartTime | Časové razítko označující, kdy konkrétní aktivita začala nebo nastala. | ||
| Popis Čas zahájení události je přesné datum a čas, kdy aktivita začala. Spolu s ID případu a názvem aktivity tvoří jeden ze tří základních údajů pro process mining. Časová razítka umožňují seřadit události v každém případu podle času a rekonstruovat skutečný průběh procesu. Tento atribut je základem veškeré časové analýzy. Slouží k výpočtu délky aktivit, pokud je k dispozici také čas jejich ukončení, čekání mezi aktivitami a celkové doby zpracování registrace zákazníka. Analýza těchto dob pomáhá odhalit úzká místa, měřit dodržování SLA a sledovat celkovou výkonnost procesu. Proč je to důležité Určuje časové pořadí událostí. To je nezbytné pro odhalení modelu procesu a výpočet všech časových ukazatelů výkonnosti. Kde data získat Najdete ho v záznamech událostí, auditních stopách žádostí nebo transakčních tabulkách. Bývá označen jako „Časové razítko“, „Datum vytvoření“ nebo „Čas zahájení“. Příklady 2023-01-15T09:00:00Z2023-03-20T14:35:10Z2023-05-10T11:21:05Z | |||
| ID žádosti CustomerApplicationId | Jedinečný identifikátor žádosti o registraci zákazníka, který slouží jako ID případu pro analýzu procesu. | ||
| Popis ID žádosti zákazníka je jedinečný klíč přiřazený každé nové žádosti o registraci zákazníka. Používá se od jejího zahájení až do dokončení nebo ukončení. Tento identifikátor propojuje všechny aktivity, události a datové body související s jednou registrací zákazníka. Pro process mining jde o nejdůležitější atribut. Díky tomuto ID lze při analýze rekonstruovat celý proces každého zákazníka. Umožňuje sledovat průběh žádosti, vypočítat celkovou dobu jejího zpracování a porovnat její průběh s ostatními žádostmi. Varianty procesu, úzká místa i ukazatele výkonnosti se analyzují pro každou žádost zvlášť. To je možné pouze tehdy, pokud je tento atribut správně určen a použit jako ID případu. Proč je to důležité Je nezbytné seskupit všechny související události do jednoho procesu od začátku do konce. Na tomto základě stojí veškerá analýza process mining. Kde data získat Obvykle se nachází v záhlaví nebo hlavní tabulce systému pro správu žádostí zákazníků či případů. Příklady APP-2023-00123KYC-987654ONB-C-456-7890 | |||
| Název aktivity ActivityName | Název konkrétní obchodní události nebo úkolu v procesu registrace zákazníka. | ||
| Popis Název aktivity označuje konkrétní krok nebo milník v průběhu registrace zákazníka, například „Žádost odeslána“, „Zahájena kontrola shody“ nebo „Žádost schválena“. Každá aktivita představuje konkrétní úkon uživatele nebo systému, který posouvá žádost v procesu dál. Tento atribut je základem pro vizualizaci mapy procesu, která je ústřední součástí process mining. Analýza pořadí a četnosti aktivit pomáhá pochopit skutečný průběh procesu, určit obvyklé cesty, odhalit odchylky a najít místa, kde se práce opakuje nebo vrací k přepracování. Jasné a jednotné názvy aktivit jsou důležité pro vytvoření srozumitelného modelu procesu. Proč je to důležité Určuje jednotlivé kroky procesu a umožňuje zobrazit a analyzovat jeho průběh, úzká místa i odchylky. Kde data získat Najdete ho v záznamech událostí, auditních stopách nebo transakčních tabulkách, které zaznamenávají kroky obchodního procesu. Příklady Provedena úvodní kontrolaVyžádány dokumentyProvedeno posouzení rizikaŽádost schválena | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko označující, kdy byla data naposledy obnovena nebo načtena ze zdrojového systému. | ||
| Popis Tento atribut zaznamenává datum a čas posledního načtení nebo obnovení dat. Není součástí samotného obchodního procesu, ale jde o důležitá metadata pro ověřování a správu dat. Informuje o tom, jak aktuální jsou analyzovaná data. Při analýze procesu je čas poslední aktualizace dat důležitý pro posouzení aktuálnosti získaných poznatků. Pomáhá uživatelům důvěřovat datům, protože ukazuje, jak jsou čerstvá, a předchází chybným závěrům založeným na zastaralých informacích. Při průběžném monitorování lze tento atribut využít k nastavení upozornění na zpožděné nebo neúspěšné aktualizace, a zajistit tak spolehlivost dashboardů process mining. Proč je to důležité Zajišťuje přehled o aktuálnosti datové sady, která je důležitá pro relevanci a přesnost analýzy. Kde data získat Vzniká při procesu extrakce, transformace a načítání dat (ETL). Často se nachází v metadatech datové sady. Příklady 2023-10-27T02:00:00Z2023-10-26T02:00:00Z2023-10-25T02:00:00Z | |||
| Zdrojový systém SourceSystem | Určuje systém evidence, ze kterého pocházejí data o události. | ||
| Popis Atribut Zdrojový systém označuje aplikaci nebo platformu, která vytvořila data pro danou aktivitu. V prostředí s více systémy může proces KYC probíhat v několika z nich, například v CRM při podání žádosti, na specializované platformě KYC při hodnocení rizika a v hlavním bankovním systému při zakládání účtu. Analýza procesu podle zdrojového systému pomáhá pochopit používané technologie a jejich vliv na proces. Může odhalit problémy s integrací, zpoždění při předávání dat mezi systémy nebo rozdíly v tom, jak jednotlivé systémy zaznamenávají informace. Tento pohled ocení týmy IT a zlepšování procesů, které chtějí zjednodušit systémové prostředí podporující registraci zákazníků. Proč je to důležité Ukazuje, kde probíhá každý krok procesu, a pomáhá odhalit neefektivitu mezi systémy i problémy s integrací dat. Kde data získat Často bývá uveden v exportech dat nebo záznamech událostí, zejména v prostředí s více propojenými systémy. Příklady CRM_System_AKYC_Platform_BCoreBanking_Sys_C | |||
| Čas ukončení události EventEndTime | Časové razítko označující, kdy byla konkrétní aktivita dokončena. | ||
| Popis Čas ukončení události označuje přesné datum a čas, kdy aktivita skončila. V kombinaci s časem zahájení události umožňuje přesně vypočítat dobu zpracování každého úkolu. Ne všechny systémy poskytují čas zahájení i ukončení. Některé zaznamenávají pouze jedno časové razítko, které označuje dokončení. Čas ukončení je velmi užitečný při analýze výkonnosti. Umožňuje vytvářet podrobné ukazatele, například „Průměrná doba kontroly shody“, a rozlišit, kolik času zaměstnanec na úkolu aktivně pracoval a jak dlouho úkol čekal ve frontě. Díky tomu lze přesněji určit úzká místa a zaměřit zlepšování procesů buď na kapacitu zdrojů, nebo na předávání práce. Proč je to důležité Umožňuje přesně vypočítat dobu zpracování aktivit a rozlišit aktivní práci od čekání. Kde data získat Najdete ho v záznamech událostí nebo transakčních tabulkách vedle času zahájení. Může být označen jako „Čas ukončení“, „Datum dokončení“ nebo „Upraveno dne“. Příklady 2023-01-15T17:30:00Z2023-03-21T10:15:20Z2023-05-10T11:55:00Z | |||
| ID uživatele UserId | ID nebo jméno zaměstnance či automatizovaného agenta, který provedl aktivitu. | ||
| Popis ID uživatele označuje osobu nebo systémového robota odpovědného za konkrétní aktivitu v procesu. Může jít například o pracovníka odpovědného za shodu, referenta zadávajícího data nebo automatizovaný nástroj pro hodnocení rizika. Pro přesnou analýzu zdrojů je důležité uživatele identifikovat jednotně. Tento atribut nabízí pohled na proces z hlediska lidí. Je nezbytný pro analýzu rozložení pracovní zátěže, výkonnosti jednotlivců a týmů i přidělování zdrojů. Filtrováním mapy procesu podle ID uživatele mohou vedoucí pracovníci zjistit, jak zaměstnanci zpracovávají úkoly, kde je potřeba školení a zda je práce rozložena rovnoměrně. Atribut pomáhá také analyzovat spolupráci a ukazuje, jak se práce předává mezi jednotlivými lidmi. Proč je to důležité Umožňuje analyzovat pracovní zátěž, výkonnost zdrojů a spolupráci. Díky tomu lze lépe řídit zdroje a plánovat školení. Kde data získat Bývá dostupné v auditních stopách systému nebo transakčních záznamech, často u uživatele, který záznam vytvořil nebo naposledy upravil. Příklady john.doeSYSTEM_AUTOuser12345 | |||
| Oddělení uživatele UserDepartment | Obchodní oddělení nebo tým odpovědný za provedení aktivity. | ||
| Popis Oddělení uživatele označuje funkční skupinu nebo tým, do kterého patří uživatel, jenž aktivitu provedl. Může jít například o oddělení „Shoda“, „Registrace klientů“ nebo „Provoz“. Oproti samotnému ID uživatele tak poskytuje širší organizační kontext. Pohled na proces podle oddělení je důležitý pro pochopení spolupráce mezi různými funkcemi a odhalení systémových úzkých míst. Ukazuje předávání práce mezi týmy, které často způsobuje zpoždění a neefektivitu. Tyto informace pomáhají upravit strukturu týmů, vyjasnit odpovědnosti a zlepšit komunikaci, aby registrace zákazníků probíhala plynuleji. Proč je to důležité Umožňuje analyzovat výkonnost procesu a předávání práce mezi týmy a odhalit možnosti, jak zlepšit jejich spolupráci. Kde data získat Často je uvedeno v profilu uživatele propojeném s jeho ID, případně přímo v transakčním záznamu. Příklady CompliancePřímý kontakt se zákazníkyProvoz KYC | |||
| Stav žádosti ApplicationStatus | Konečný výsledek nebo aktuální stav žádosti o registraci zákazníka. | ||
| Popis Stav žádosti označuje její konečný výsledek, například „Schváleno“, „Zamítnuto“ nebo „Staženo“. Vyjadřuje obchodní výsledek procesu a je důležitým ukazatelem výkonnosti. Tento atribut je nezbytný pro analýzu výsledků. Umožňuje porovnat průběh procesů, které vedou ke schválení, s těmi, které končí zamítnutím. Analytici mohou hledat vzorce spojené s vysokou mírou zamítnutí, vypočítat KPI, například „Míra zamítnutí žádostí“, a vytvořit „Analýzu registračního trychtýře“, která ukáže, ve které fázi žadatelé odcházejí. Pochopení důvodů neúspěchu je prvním krokem ke zlepšení procesu a zvýšení úspěšnosti. Proč je to důležité Určuje obchodní výsledek každého případu a umožňuje zjistit, proč jsou žádosti zamítány a jak zvýšit míru schválení. Kde data získat Obvykle se nachází v hlavní tabulce případů nebo žádostí a označuje konečný stav záznamu. Příklady SchválenoZamítnutoProbíháZákazník žádost stáhl | |||
| Typ zákazníka CustomerType | Kategorie zákazníka, například fyzická osoba nebo firma. | ||
| Popis Typ zákazníka rozděluje žadatele do kategorií, například „Fyzická osoba“, „Firma“, „Svěřenský fond“ nebo „Nezisková organizace“. Požadavky na registraci a náročnost procesu se mohou podle typu zákazníka výrazně lišit. Tento atribut slouží k segmentaci analýzy. Filtrováním mapy procesu a KPI podle typu zákazníka mohou organizace odhalit významné rozdíly. Registrace firemního klienta například obvykle zahrnuje složitější kroky, jako je ověření skutečných majitelů, které u fyzické osoby nejsou potřeba. Analýza pomáhá zajistit, aby byla každá varianta procesu co nejefektivnější pro danou skupinu, a ukazuje, kde lze proces zlepšit. Proč je to důležité Umožňuje rozdělit proces podle typu zákazníka a porovnat i zlepšit průběh jeho registrace pro jednotlivé skupiny. Kde data získat Obvykle se zaznamenává na začátku procesu žádosti a ukládá do hlavní tabulky zákazníků nebo žádostí. Příklady Fyzická osobaFirmaSvěřenský fondMalá firma | |||
| Úroveň rizika RiskLevel | Vypočtená klasifikace rizika žádosti zákazníka, například nízká, střední nebo vysoká. | ||
| Popis Úroveň rizika je důležitým výstupem procesu KYC. Zákazníky rozděluje do kategorií podle faktorů, jako jsou obor podnikání, zeměpisná poloha a vzorce transakcí. Tato klasifikace určuje, jak důkladnou kontrolu a hloubkovou prověrku žádost vyžaduje. V process mining slouží tento atribut jako důležitý rozměr pro analýzu shody a variant procesu. Proces u zákazníka s vysokým rizikem by měl být záměrně důkladnější než u zákazníka s nízkým rizikem. Porovnáním skutečného průběhu pro jednotlivé úrovně rizika s očekávanými postupy mohou organizace ověřit dodržování interních pravidel a předpisů. Lze tak například zjistit, zda u zákazníků s vysokým rizikem vždy probíhá rozšířená hloubková kontrola nebo zda se zákazníkům s nízkým rizikem věnuje zbytečně mnoho času. Proč je to důležité Je důležitý pro řízení rizik a dodržování pravidel. Umožňuje ověřit, zda se hloubková kontrola přizpůsobuje rizikovému profilu zákazníka. Kde data získat Vypočítává ho nástroj pro hodnocení rizik nebo ho ručně přiřazuje pracovník odpovědný za shodu. Ukládá se do hlavního záznamu zákazníka nebo žádosti. Příklady NízkéStředníVysokéPEP | |||
| Automatizováno IsAutomated | Příznak určující, zda aktivitu provedl automaticky systém, nebo ručně uživatel. | ||
| Popis Tento logický atribut rozlišuje úkoly provedené softwarem nebo roboty od úkolů, které provedli uživatelé. Automatizované aktivity mohou zahrnovat úvodní ověření dat, kontrolu sankčních seznamů nebo odesílání standardizovaných zpráv. Analýza tohoto atributu je důležitá pro vyhodnocení účinnosti automatizace. Porovnáním rychlosti a výsledků automatizovaných a ručních kroků mohou firmy určit, kde další automatizace sníží náklady a dobu zpracování. Atribut také pomáhá sledovat výkon automatizovaných systémů a ověřit, zda v celém procesu fungují podle očekávání. Proč je to důležité Pomáhá měřit dopad a účinnost automatizace v procesu a hledat možnosti dalšího využití robotizace nebo systémových úprav. Kde data získat Může jít o samostatné pole v záznamu událostí nebo lze hodnotu odvodit z ID uživatele, například pokud je ID „SYSTEM“ nebo „BOT“. Příklady truefalse | |||
| Důvod zamítnutí RejectionReason | Konkrétní důvod uvedený při zamítnutí žádosti zákazníka. | ||
| Popis Pokud je stav žádosti „Zamítnuto“, důvod zamítnutí uvádí konkrétní příčinu, například „Neúplná dokumentace“, „Vysoké riziko“ nebo „Shoda se sankčním seznamem“. Tento atribut doplňuje důležitý kontext k neúspěšným případům. Analýza důvodů zamítnutí je základem dashboardu „Analýza zamítnutých žádostí“. Pomáhá zjistit nejčastější příčiny neúspěchu při registraci zákazníků. Když organizace tyto důvody roztřídí a vyčíslí, může určit, která zlepšení mají přednost. Pokud je například častým důvodem „Neúplná dokumentace“, může se zaměřit na srozumitelnější pokyny pro zákazníky nebo na vylepšení portálu pro odesílání dokumentů. Proč je to důležité Odhaluje příčiny neúspěšných žádostí a umožňuje cíleně snížit míru zamítnutí a zlepšit zákaznickou zkušenost. Kde data získat Obvykle se ukládá do hlavní tabulky žádostí nebo případů a vyplní se při nastavení stavu „Zamítnuto“. Příklady Neúspěšné ověření totožnostiNeúplná dokumentaceVysoké rizikoShoda s PEP | |||
| ID zákazníka CustomerId | Jedinečný identifikátor zákazníka, který prochází registrací. | ||
| Popis ID zákazníka je jedinečný identifikátor, který zůstává stejný napříč různými interakcemi a žádostmi. Zatímco ID žádosti zákazníka sleduje jednu registraci, ID zákazníka může propojit více pokusů o registraci nebo jiné procesy téhož zákazníka. Tento atribut umožňuje analyzovat proces z pohledu zákazníka, nejen jednoho případu. Hodí se pro sledování opakovaných žádostí, analýzu dlouhodobého vztahu se zákazníkem nebo propojení registrace s dalšími procesy, například „Žádost o úvěr“ nebo „Správa účtu“. Pro analýzu jednoho procesu není nezbytný, ale obohacuje data pro složitější object-centric process mining. Proč je to důležité Umožňuje analyzovat proces z pohledu zákazníka a propojit více pokusů o registraci nebo různé procesy, které se ho týkají. Kde data získat Obvykle se nachází v centrálním systému kmenových dat zákazníků a je propojeno se záznamem žádosti. Příklady CUST-1005678943210AENT-4590 | |||
| Kanál podání žádosti ApplicationChannel | Kanál, kterým zákazník podal žádost. | ||
| Popis Tento atribut označuje způsob, jakým zákazník podal žádost, například přes webový portál, mobilní aplikaci nebo na pobočce. Jednotlivé kanály mohou mít odlišný způsob sběru dat i zákaznickou zkušenost. Analýza procesu podle kanálu pomáhá vyhodnotit výkonnost a efektivitu jednotlivých kontaktních míst. Může například odpovědět na otázky: „Zpracovávají se žádosti z mobilní aplikace rychleji než žádosti z webu?“ nebo „Je u žádostí podaných na pobočce častější přepracování?“ Tyto poznatky pomáhají zlepšit zákaznickou cestu napříč kanály a účelněji přidělovat zdroje. Proč je to důležité Umožňuje porovnat efektivitu procesu a zákaznickou zkušenost při podání žádosti přes web, mobilní aplikaci nebo osobně. Kde data získat Obvykle se zaznamenává hned na začátku procesu při vytvoření žádosti. Příklady Webový portálMobilní aplikaceNa pobočce | |||
| Termín SLA SlaTargetDate | Datum, do kterého má být registrace zákazníka dokončena. | ||
| Popis Termín SLA je lhůta pro dokončení registrace zákazníka. Obvykle vychází z interních pravidel nebo smluvních závazků a slouží jako měřítko včasnosti. Tento atribut je základem dashboardu „Sledování plnění SLA“. Porovnáním skutečného data dokončení žádosti s termínem SLA lze vypočítat míru plnění SLA. Analýza případů, u kterých nebyla lhůta dodržena, pomáhá určit konkrétní aktivity nebo oddělení způsobující zpoždění. Díky tomu lze lépe řídit pracovní fronty a přidělování zdrojů, omezit nedodržení SLA a zvýšit spokojenost zákazníků. Proč je to důležité Poskytuje měřítko výkonnosti, podle kterého lze sledovat plnění SLA a určit případy ohrožené zpožděním. Kde data získat Často se vypočítá a uloží do hlavního záznamu žádosti při vytvoření případu, a to podle typu žádosti nebo jiných kritérií. Příklady 2023-01-30T23:59:59Z2023-04-15T23:59:59Z2023-06-01T23:59:59Z | |||
| Země zákazníka CustomerCountry | Země, ve které má zákazník bydliště nebo sídlo. | ||
| Popis Země zákazníka označuje zeměpisnou polohu žadatele. V procesech KYC jde o důležitý údaj, protože předpisy a rizikové faktory se mohou v jednotlivých zemích výrazně lišit. Zeměpisná analýza přináší další důležitý pohled. Požadavky na registraci se mohou lišit podle místních právních předpisů. Filtrováním podle země zákazníka mohou firmy ověřit, zda se správně uplatňují postupy pro jednotlivé jurisdikce. Analýza může také odhalit rozdíly ve výkonnosti, například delší dobu zpracování žádostí ze zemí s vysokým rizikem, která může být důsledkem požadavků na rozšířenou hloubkovou kontrolu. Proč je to důležité Umožňuje analyzovat odchylky a výkonnost procesu podle země, což je důležité pro dodržování místních předpisů. Kde data získat Zaznamenává se při podání žádosti a ukládá do záznamu zákazníka nebo žádosti. Příklady USAGBRSGPDEU | |||
Aktivity při onboardingu zákazníků KYC
| Aktivita | Popis | ||
|---|---|---|---|
| Onboarding dokončen | Jde o poslední činnost procesu. Označuje, že onboarding zákazníka je dokončen a případ žádosti je administrativně uzavřen. Zákazník nyní může provádět transakce. | ||
| Proč je to důležité Jde o konečnou událost úspěšného případu. Celková doba do této činnosti představuje dobu potřebnou k dokončení onboardingu zákazníka. Kde data získat Událost lze odvodit z nastavení konečného stavu případu ve zdrojovém systému, například na „Onboardován“ nebo „Uzavřeno, schváleno“. Zachycení Použijte časové razítko konečného uzavření případu nebo změny stavu na konečný stav „Dokončeno“. Typ události inferred | |||
| Provedeno posouzení rizika | Tato činnost označuje spuštění rozhodovacího nástroje nebo ručního postupu pro výpočet rizikového skóre žádosti zákazníka. Shromažďují se při ní informace potřebné ke klasifikaci úrovně rizika zákazníka. | ||
| Proč je to důležité Výsledek posouzení rizika často určuje další postup, například automatické zpracování bez zásahu nebo ruční kontrolu shody. Kde data získat Jako základní funkce se tato činnost často zaznamenává explicitně při spuštění pravidel pro posouzení rizika nebo vyplnění pole s rizikovým skóre. Zachycení Použijte časové razítko z protokolu spuštění nástroje pro posouzení rizika nebo z auditní stopy pole s rizikovým skóre. Typ události explicit | |||
| Vyžádány další informace | Tato událost nastane, když kontrolující potřebuje od zákazníka další informace nebo dokumenty, aby mohl pokračovat. Vytváří se tím smyčka opakovaného zpracování a interní proces se pozastaví. | ||
| Proč je to důležité Tato činnost často způsobuje neefektivitu a prodlužuje dobu průchodu. Pokud se vyskytuje často, může to ukazovat na problémy s počátečním sběrem údajů. Kde data získat Obvykle se zaznamenává explicitně, protože zahrnuje odeslání oznámení zákazníkovi a objevuje se v protokolech komunikace nebo auditních stopách. Zachycení Použijte časové razítko události „Vyžádání informací“, konkrétní změny stavu nebo zaznamenané komunikace se zákazníkem. Typ události explicit | |||
| Žádost podána | Tato činnost označuje začátek onboardingu zákazníka. Zaznamená se ve chvíli, kdy systém formálně přijme novou žádost zákazníka, ať už přes zákaznický portál, nebo ručním zadáním interním uživatelem. | ||
| Proč je to důležité Jde o hlavní počáteční událost procesu. Analýza počtu a času podání žádostí je základem pro pochopení poptávky a potřebné kapacity. Kde data získat Obvykle se zaznamená v protokolu o vytvoření žádosti nebo jako první položka v auditní stopě systému pro správu případů. Zachycení Použijte časové razítko vytvoření žádosti nebo záznamu případu. Typ události explicit | |||
| Žádost schválena | Tato činnost představuje konečné obchodní rozhodnutí schválit žádost zákazníka o onboarding. Jde o důležitý milník, který označuje úspěšný výsledek procesu KYC. | ||
| Proč je to důležité Jde o důležitou událost potvrzující úspěch a konečný bod rozhodování. Umožňuje analyzovat míru schválení i dobu do schválení. Kde data získat Obvykle se zaznamenává v systému pro správu případů jako samostatná konečná změna stavu v životním cyklu žádosti. Zachycení Určete časové razítko nastavení konečného stavu žádosti na „Schváleno“ nebo na obdobný konečný stav označující úspěch. Typ události inferred | |||
| Žádost zamítnuta | Označuje konečné rozhodnutí žádost zákazníka zamítnout, čímž se onboarding ukončí. Jde o důležitý negativní výsledek procesu. | ||
| Proč je to důležité Jde o důležitou událost neúspěchu. Analýza toho, kdy a proč k zamítnutí dochází, je nezbytná pro zlepšování procesu a pochopení problémů, se kterými se zákazníci setkávají. Kde data získat Událost se zaznamená konečnou změnou stavu záznamu žádosti, například na „Zamítnuto“ nebo „Neschváleno“. Zachycení Určete časové razítko nastavení konečného stavu žádosti na „Zamítnuto“ nebo na obdobný konečný stav označující neúspěch. Typ události inferred | |||
| Zahájena kontrola shody | Tato činnost označuje začátek ruční kontroly oddělením shody. Obvykle se týká žádostí s vysokým rizikem nebo žádostí označených k prověření a představuje předání případu specializovanému týmu. | ||
| Proč je to důležité Sledování této činnosti je důležité pro odhalení úzkých míst při kontrole shody. Doba do jejího dokončení tvoří významnou část celkové doby průchodu. Kde data získat Tuto událost lze často odvodit ze změny stavu případu nebo z auditního záznamu, který ukazuje přiřazení případu do pracovní fronty pracovníka oddělení shody. Zachycení Určete časové razítko změny stavu žádosti na „Čeká se na kontrolu shody“ nebo jejího přiřazení do pracovní fronty oddělení shody. Typ události inferred | |||
| Dokumenty přijaty | Tato činnost označuje okamžik, kdy zákazník dodal požadované doklady totožnosti a podpůrné dokumenty. Dokumenty jsou nyní v systému k dispozici ke kontrole. | ||
| Proč je to důležité Tato událost je důležitá pro měření doby odezvy zákazníka a odhalování zpoždění způsobených žadatelem. Kde data získat Obvykle se zaznamenává jako samostatná explicitní událost v protokolu správy dokumentů nebo v auditní stopě případu při každém nahrání dokumentu. Zachycení Použijte časové razítko vytvoření nebo nahrání příloh dokumentů propojených s žádostí. Typ události explicit | |||
| Kontrola dokumentů dokončena | Tato činnost označuje dokončení kontroly dokumentů, které zákazník předložil. Kontrolu provedl pracovník nebo automatizovaný nástroj. Ověřuje se pravost, platnost a úplnost dokumentů. | ||
| Proč je to důležité Kontrola dokumentů často tvoří významnou část celkové doby zpracování. Analýza tohoto kroku pomáhá určit, zda jsou potřeba další zdroje nebo školení. Kde data získat Tuto událost lze často odvodit ze změny stavu dokumentu nebo celého případu, například na „Dokumenty ověřeny“ nebo „Kontrola dokončena“. Zachycení Určete časové razítko dokončení ruční kontroly nebo změny stavu případu, která potvrzuje úspěšné ověření dokumentů. Typ události inferred | |||
| Kontrola shody dokončena | Označuje konec ruční kontroly oddělením shody. Pracovník oddělení shody rozhodl, zda žádost schválit, zamítnout, nebo vyžádat další kroky. | ||
| Proč je to důležité Tento milník uzavírá důležitou a často dlouhou fázi procesu. Analýza doby do jeho dosažení pomáhá měřit efektivitu týmu pro shodu. Kde data získat Tuto činnost lze obvykle odvodit ze změny stavu případu z „Čeká se na kontrolu shody“ na následující stav, například „Shoda schválena“. Zachycení Použijte časové razítko označení úkolu kontroly shody jako „Dokončeno“ nebo aktualizace stavu případu, která uvádí výsledek kontroly. Typ události inferred | |||
| Provedena úvodní kontrola | Jde o úvodní, často automatizovanou kontrolu žádosti. Ověřuje úplnost údajů, základní způsobilost nebo případnou shodu se sankčními seznamy. V tomto kroku se rychle vyřadí zjevně nezpůsobilé nebo neúplné žádosti. | ||
| Proč je to důležité Tato činnost pomáhá měřit kvalitu přijatých žádostí. Vysoký podíl neúspěšných kontrol může ukazovat na problémy s formulářem nebo pokyny k jeho vyplnění. Kde data získat Obvykle se zaznamená jako automatický krok v historii workflow nebo se odvodí z časné změny stavu, například z „Nová“ na „Úvodní kontrola dokončena“. Zachycení Určete časové razítko dokončení úvodní kontroly nebo ověření, které bývá často označeno změnou stavu. Typ události inferred | |||
| Provedeno ověření totožnosti | Jde o automatickou nebo ruční kontrolu, která ověřuje totožnost zákazníka podle externích či interních zdrojů dat. Je to základní ověřovací krok procesu KYC. | ||
| Proč je to důležité Tato činnost je důležitá pro dodržování požadavků a prevenci podvodů. Neúspěšné ověření může vést k zamítnutí žádosti nebo dalšímu šetření. Kde data získat Často se zaznamená jako explicitní událost při volání API ověřovací služby třetí strany a přijetí její odpovědi. Zachycení Použijte časové razítko z protokolu volání služby pro ověření totožnosti a odpovídající úspěšné nebo neúspěšné odpovědi. Typ události explicit | |||
| Účet vytvořen | Po schválení tato činnost označuje technické vytvoření účtu zákazníka v hlavním bankovním systému nebo systému správy uživatelů. Z žadatele se tak stává aktivní zákazník. | ||
| Proč je to důležité Měří efektivitu předání mezi rozhodovacím procesem a systémy pro technické zřízení účtu. Kde data získat Často se zaznamenává jako explicitní událost v systému onboardingu po potvrzení úspěšného dokončení v navazujícím systému nebo podle data vytvoření účtu v hlavním systému. Zachycení Použijte časové razítko vytvoření účtu z hlavního systému nebo potvrzovací událost zaznamenanou v systému onboardingu. Typ události explicit | |||
| Vyžádány dokumenty | Tato činnost nastane, když systém nebo pracovník zjistí, že k pokračování v ověřování potřebuje od zákazníka konkrétní dokumenty. Označuje odeslání formální žádosti o informace žadateli. | ||
| Proč je to důležité Sledování této události pomáhá pochopit zpoždění způsobená průběhem procesu. Doba mezi touto událostí a událostí „Dokumenty přijaty“ představuje čekání na zákazníka. Kde data získat Událost lze zachytit v protokolech systémové komunikace, e-mailových záznamech nebo změnou stavu případu na „Čeká se na dokumenty“. Zachycení Použijte časové razítko zprávy odeslané zákazníkovi nebo změny stavu na „Čeká se na dokumenty“. Typ události explicit | |||
| Zahájeno prověřování | Označuje zahájení automatického nebo ručního prověřování, například kontrol AML, PEP nebo úvěrové historie. Často se při něm spouští služby externích poskytovatelů. | ||
| Proč je to důležité Prověřování může být významným zdrojem zpoždění. Sledováním jeho zahájení změříte dobu čekání na výsledky od třetích stran. Kde data získat Událost se často zaznamená explicitně při spuštění kontrol systémem nebo se odvodí ze změny stavu, například na „Čeká se na prověření“. Zachycení Použijte časové razítko volání API služby pro prověřování nebo záznam o zahájení kontroly. Typ události explicit | |||
Návody k extrakci dat
Metody extrakce se liší podle systému. Podrobný postup najdete v
Chcete začít?
Vyberte si níže návod pro konkrétní systém a začněte s extrakcí dat, nebo použijte tuto obecnou šablonu jako výchozí předlohu.
Zefektivněte onboarding KYC a zvyšte efektivitu
Funguje s jakýmkoli systémem. Během několika dní odhalte nové poznatky a zlepšete shodu.
Platební kartu nepotřebujete. Přínos uvidíte rychle.