Il Suo Template Dati per l'Onboarding Cliente KYC
Il Suo Template Dati per l'Onboarding Cliente KYC
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione dei dati
Attributi di Onboarding Cliente KYC
| Nome | Descrizione | ||
|---|---|---|---|
| Nome attività ActivityName | Il nome dello specifico evento o attività aziendale che si è verificato in un determinato momento all'interno del processo di onboarding. | ||
| Descrizione Il Nome Attività descrive un singolo passaggio o traguardo nel percorso di onboarding del cliente, come 'Screening Iniziale Eseguito' o 'Richiesta Approvata'. Questa sequenza di attività costituisce la base della mappa di processo.\n\nL'analisi di questo attributo consente la visualizzazione del flusso di processo, l'identificazione di percorsi comuni e alternativi e la misurazione della frequenza di ogni passaggio. È fondamentale per comprendere quali azioni vengono eseguite e in quale ordine. Perché è importante Questo attributo definisce i passaggi del processo, consentendo la creazione di una mappa di processo e l'analisi del flusso di processo e delle sue variazioni. Dove trovare Queste informazioni si trovano tipicamente nelle tabelle di Esempi Dati e Documenti RichiestiRevisione Conformità AvviataRichiesta Approvata | |||
| Ora di Inizio EventStartTime | Il timestamp che indica quando un'attività o un evento è ufficialmente iniziato. | ||
| Descrizione Questo attributo registra la data e l'ora precise in cui una specifica attività è iniziata. Fornisce l'ordine cronologico necessario per ricostruire il flusso di processo ed è essenziale per tutte le analisi basate sul tempo.\n\nNel Process Mining, l'ora di inizio viene utilizzata per calcolare la durata delle attività, il tempo di attesa tra esse e il tempo di ciclo complessivo del caso. Costituisce la spina dorsale temporale dell'Event Log ed è critico per l'analisi delle prestazioni e dei colli di bottiglia. Perché è importante Questo timestamp è critico per ordinare gli eventi cronologicamente e calcolare tutte le metriche basate sul tempo come i tempi di ciclo e le durate. Dove trovare Situato nel registro di audit, log eventi o tabelle di cronologia del workflow di Fenergo, spesso etichettato come 'Timestamp', 'StartDate' o 'CreationDate'. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Richiesta Cliente CustomerApplication | L'identificatore unico per un singolo percorso di onboarding del cliente, che funge da identificatore primario del caso. | ||
| Descrizione L'Applicazione Cliente è l'identificatore centrale che raggruppa tutte le attività e gli eventi correlati per il processo di onboarding KYC di un singolo cliente. Consente il tracciamento end-to-end di una richiesta dalla presentazione iniziale alla risoluzione finale, sia che venga approvata, rifiutata o chiusa.\n\nNel Process Mining, questo attributo è fondamentale per ricostruire l'intero percorso di ogni applicazione. Permette l'analisi dei flussi di processo, dei tempi di ciclo, delle variazioni e dei colli di bottiglia su base per applicazione, fornendo una visione chiara di come vengono gestiti i singoli casi. Perché è importante Questo è l'ID Caso essenziale che collega tutti gli eventi correlati, rendendo possibile analizzare il processo di onboarding del cliente end-to-end. Dove trovare Questa è tipicamente la chiave primaria nell'entità di gestione dei casi o del ciclo di vita del cliente di Fenergo. Esempi APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Sistema di Origine SourceSystem | Il sistema di origine da cui sono stati estratti i dati. | ||
| Descrizione Questo attributo identifica il sistema di origine per i Perché è importante Identifica l'origine dei dati, cruciale per la data governance, la validazione e per assicurarsi che l'analisi si basi sulla fonte corretta. Dove trovare Questo è tipicamente un valore statico aggiunto durante il processo di estrazione dei dati per etichettare l'origine dei record. Esempi FenergoFenergo CLM | |||
| Ultimo `Data Update` LastDataUpdate | Il timestamp che indica l'ultima volta in cui i dati di questo processo sono stati aggiornati o estratti. | ||
| Descrizione Questo attributo registra la data e l'ora dell'ultimo aggiornamento dei Perché è importante Fornisce un contesto cruciale sull'attualità dei dati, garantendo che gli utenti comprendano quanto sia aggiornata l'analisi del processo. Dove trovare Questo valore viene generato e marcato sul set di Esempi 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Data Obiettivo SLA SlaTargetDate | La data entro cui si prevede il completamento del caso di onboarding del cliente. | ||
| Descrizione La Data Obiettivo SLA rappresenta la scadenza concordata per il completamento dell'intero processo di onboarding per una richiesta cliente. È un benchmark critico rispetto al quale viene misurata la performance effettiva.\n\nQuesto attributo è essenziale per la Perché è importante Definisce la data di completamento prevista, cruciale per monitorare la conformità SLA e prioritizzare i casi in ritardo. Dove trovare Questa data è spesso calcolata in base alla data di presentazione della richiesta e alle regole aziendali configurate all'interno del modulo di gestione SLA di Fenergo. Esempi 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Ora di Fine EventEndTime | Il `timestamp` che indica quando un'attività o un `event` è stato completato. | ||
| Descrizione Questo attributo registra la data e l'ora precise in cui una specifica attività è terminata. Completa l'ora di inizio per definire la durata attiva di un'attività.\n\nNel Process Mining, l'ora di fine viene utilizzata con l'ora di inizio per calcolare il tempo di elaborazione per ciascuna attività. Questo è essenziale per identificare quali passaggi del processo consumano più tempo e per analizzare l'efficienza delle risorse. Perché è importante Consente il calcolo dei tempi di elaborazione delle attività, fondamentale per identificare i task a lunga esecuzione e i bottleneck di performance. Dove trovare Situato nel registro di audit di Fenergo o nelle tabelle di cronologia del workflow, spesso etichettato come 'EndDate', 'CompletionDate', o derivato dal tempo di inizio dell'evento successivo. Esempi 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Punteggio di Rischio RiskScore | Un punteggio numerico che rappresenta il livello di rischio calcolato del cliente. | ||
| Descrizione Il Punteggio di Rischio è una misura quantitativa del rischio potenziale associato a un cliente, calcolato in base a vari fattori come giurisdizione, settore e risultati dello screening. Il motore di regole di Fenergo tipicamente calcola questo punteggio.\n\nQuesto attributo consente la correlazione tra livelli di rischio e comportamento del processo. Ad esempio, l'analisi può rivelare se i clienti ad alto rischio sperimentano tempi di ciclo più lunghi o richiedono più interventi manuali, il che è utile per la Perché è importante Quantifica il rischio del cliente, consentendo l'analisi di come i livelli di rischio influenzano la durata del processo, le rilavorazioni e i risultati. Dove trovare Questo è un output chiave del modulo di Valutazione del Rischio Cliente di Fenergo. È memorizzato sul caso o sull'entità cliente. Esempi 154585 | |||
| Reparto Utente UserDepartment | Il dipartimento o l'unità aziendale a cui appartiene l'utente che ha avviato il processo. | ||
| Descrizione Questo attributo fornisce il contesto organizzativo per l'utente che ha eseguito un'attività, come 'Conformità', 'Operazioni Onboarding' o 'Vendite'. Spesso è derivato dalle informazioni del profilo utente.\n\nQuesta dimensione è cruciale per analizzare i passaggi di processo tra diversi dipartimenti e identificare i colli di bottiglia interfunzionali. Supporta direttamente la Perché è importante Consente l'analisi delle prestazioni del processo per dipartimento, evidenziando passaggi di consegne interdipartimentali, ritardi e distribuzione del carico di lavoro. Dove trovare Questo potrebbe dover essere unito da una tabella separata di Esempi ComplianceOnboarding ClienteAssicurazione Qualità | |||
| Stato Richiesta ApplicationStatus | L'esito attuale o finale della richiesta del cliente. | ||
| Descrizione Questo attributo indica la disposizione della richiesta alla fine del processo o il suo stato attuale se in corso. I valori comuni includono 'Approvato', 'Rifiutato' o 'In Corso'.\n\nQuesta è una dimensione critica per l'analisi dei risultati. Consente di filtrare e confrontare i flussi di processo in base al loro risultato finale, il che è essenziale per la Perché è importante Definisce l'esito di un caso, consentendo un'analisi potente per confrontare i percorsi delle richieste approvate rispetto a quelle rifiutate e comprendere i tassi di successo. Dove trovare Questo è tipicamente lo stato finale registrato sull'entità caso nel sistema di gestione dei casi di Fenergo. Esempi ApprovatoRifiutatoIn Attesa di ConformitàChiuso | |||
| Utente Iniziatore InitiatingUser | L'ID utente o il nome della persona che ha eseguito l'attività. | ||
| Descrizione Questo attributo identifica lo specifico dipendente o utente di sistema responsabile dell'esecuzione di una determinata attività o evento. Può essere un ID utente unico, un nome o un ruolo.\n\nL'analisi per utente aiuta a comprendere la distribuzione del carico di lavoro, le prestazioni individuali e a identificare le esigenze di formazione. È fondamentale per la Perché è importante Traccia quale utente ha eseguito un'azione, consentendo l'analisi della distribuzione del carico di lavoro, delle prestazioni del team e dell'allocazione delle risorse. Dove trovare Queste informazioni sono tipicamente memorizzate nei log di audit o nelle tabelle di cronologia delle attività di Fenergo insieme ai dettagli dell'evento, spesso come 'UserID', 'UserName' o 'ModifiedBy'. Esempi j.doea.smithSYSTEM | |||
| Canale di Richiesta ApplicationChannel | Il canale attraverso cui è stata inviata la richiesta del cliente. | ||
| Descrizione Questo attributo identifica la fonte di presentazione della richiesta, ad esempio, tramite un portale online, una filiale fisica o tramite un responsabile delle relazioni. La fonte può influenzare la qualità dei Perché è importante Identifica la fonte delle richieste, consentendo l'analisi dell'efficienza del canale, dei costi e dell'esperienza del cliente. Dove trovare Queste informazioni potrebbero essere acquisite in un modulo di immissione Esempi Portale OnlineBranchResponsabile Relazioni con il ClienteApp Mobile | |||
| È Automatizzato IsAutomated | Un flag booleano che indica se l'attività è stata eseguita da un sistema anziché da un utente umano. | ||
| Descrizione Questo attributo distingue tra attività eseguite automaticamente dal sistema (es. screening iniziale, controlli di sistema) e quelle eseguite manualmente da un utente. Questo è spesso determinato verificando se l'utente esecutore è un account di sistema o di servizio.\n\nL'analisi di questo flag è cruciale per comprendere il livello di automazione nel processo. Aiuta a quantificare l'impatto dell'automazione su efficienza, costi e velocità, e identifica opportunità per ulteriore automazione. Perché è importante Distingue tra attività umane e di sistema, il che è vitale per l'analisi dell'automazione e la comprensione dei costi delle risorse. Dove trovare Questo è tipicamente derivato in base al campo 'InitiatingUser'. Un elenco di ID utente di sistema noti viene utilizzato per impostare questo flag su true. Esempi truefalse | |||
| È Conforme agli SLA IsSlaCompliant | Un flag booleano che indica se il caso è stato completato entro la data obiettivo SLA. | ||
| Descrizione Questo attributo è un indicatore binario delle prestazioni SLA per un caso completato. È impostato su 'vero' se il timestamp dell'attività finale di chiusura è uguale o precedente alla 'SlaTargetDate', e 'falso' altrimenti.\n\nQuesto campo calcolato semplifica il monitoraggio e il reporting degli SLA. Consente una facile aggregazione per calcolare il KPI generale 'Tasso di Aderenza SLA' e per filtrare per analizzare le caratteristiche del processo dei casi conformi rispetto a quelli non conformi. Perché è importante Misura direttamente le prestazioni degli SLA, consentendo un facile calcolo del KPI del tasso di aderenza agli SLA e il filtraggio dei casi non conformi. Dove trovare Questo è derivato confrontando il timestamp dell'attività finale del caso (es. 'Richiesta Approvata', 'Richiesta Rifiutata') con la 'SlaTargetDate'. Esempi truefalse | |||
| È una Rilavorazione IsRework | Un flag booleano che indica se un'attività fa parte di un ciclo di rilavorazione. | ||
| Descrizione Questo attributo identifica le attività che rappresentano un passo indietro nel processo, come il ritorno a 'Revisione Documenti' dopo che una 'Revisione Conformità' è già iniziata, o qualsiasi occorrenza di 'Informazioni Aggiuntive Richieste'.\n\nIdentificare le rilavorazioni è fondamentale per comprendere l'inefficienza e l'attrito del processo. Questo flag consente il calcolo diretto del KPI 'Tasso di Cicli di Rilavorazione' e aiuta a visualizzare e quantificare l'impatto di passaggi dispendiosi e ripetitivi nel flusso di processo. Perché è importante Evidenzia cicli di rilavorazione inefficienti nel processo, aiutando a quantificare gli sprechi e identificare aree di miglioramento per aumentare i tassi di successo al primo tentativo. Dove trovare Questo flag è derivato utilizzando tecniche di Process Mining che analizzano la sequenza delle attività. Ad esempio, se 'Attività A' è seguita da 'Attività B' e poi 'Attività A' appare di nuovo per lo stesso caso, la seconda 'Attività A' è una rilavorazione. Esempi truefalse | |||
| ID Cliente CustomerId | Un identificatore unico per il cliente o l'entità legale in fase di onboarding. | ||
| Descrizione L'ID Cliente è il riferimento unico per l'entità cliente nel sistema di dati master. Mentre il numero di applicazione è l'ID del caso per il processo, l'ID Cliente collega l'attività di onboarding a un cliente specifico.\n\nQuesto attributo consente di analizzare la cronologia di onboarding di un singolo cliente, ad esempio, se ha subito più processi di onboarding nel tempo. Consente anche di unire i dati di processo con altri dati relativi al cliente per una visione aziendale più completa. Perché è importante Collega il processo di onboarding a un'entità cliente unica, consentendo analisi incentrate sul cliente e arricchimento dei dati. Dove trovare Questo ID è memorizzato nel record del cliente o dell'entità legale all'interno di Fenergo e associato al caso di onboarding. Esempi CUST-98765CUST-98766CUST-98767 | |||
| Motivo del Rigetto RejectionReason | Un codice o una descrizione che spiega perché una richiesta è stata rifiutata. | ||
| Descrizione Quando lo stato finale di una richiesta è 'Rifiutato', questo attributo fornisce il motivo specifico. Gli esempi includono 'Verifica Antecedenti Fallita', 'Documentazione Incompleta' o 'Profilo di Rischio Elevato'.\n\nQuesto è un attributo vitale per l'analisi delle cause alla radice delle richieste fallite. Supporta direttamente la Perché è importante Fornisce insight critici sul motivo per cui le richieste falliscono, consentendo l'analisi delle cause profonde per ridurre i tassi di rifiuto. Dove trovare Tipicamente trovato in un campo di codice motivo o note associato allo stato di rifiuto finale nel Esempi Rilevamento SanzioniDocumenti InvalidiViolazione della PoliticaCliente ha Ritirato | |||
| Numero Richieste Info Agg. AdditionalInfoRequestCount | Il numero totale di volte in cui sono state richieste informazioni aggiuntive per una richiesta. | ||
| Descrizione Questa metrica conta le occorrenze dell'attività 'Informazioni Aggiuntive Richieste' per ogni caso. Un conteggio più alto indica più comunicazioni avanti e indietro, il che può ritardare il processo e portare a una scarsa esperienza del cliente.\n\nQuesto attributo supporta direttamente il KPI 'Casi con Richieste di Informazioni Aggiuntive'. Viene utilizzato per identificare le richieste con richieste eccessive, che possono indicare problemi con la raccolta Perché è importante Quantifica l'attrito del cliente e i ritardi di processo causati da informazioni iniziali incomplete, contribuendo a migliorare la fase di raccolta dei dati. Dove trovare Questa è una metrica calcolata, derivata dal conteggio del numero di eventi 'Informazioni Aggiuntive Richieste' per ogni ID 'CustomerApplication'. Esempi 013 | |||
| Paese Country | Il paese di domicilio o giurisdizione per la richiesta del cliente. | ||
| Descrizione Questo attributo specifica il paese associato al cliente, che spesso determina le specifiche regole normative e i fattori di rischio applicabili al processo di onboarding.\n\nL'analisi del processo per paese consente confronti giurisdizionali di tempi di ciclo, livelli di rischio e complessità del processo. Aiuta a comprendere come le differenze regionali influiscono sulle prestazioni operative e a garantire la conformità alle normative locali. Perché è importante Consente la segmentazione del processo in base alla geografia, fondamentale per analizzare l'impatto normativo e le prestazioni regionali. Dove trovare Queste informazioni fanno parte dei Esempi Stati UnitiGBRSGPDEU | |||
| Proprietario caso CaseOwner | L'utente o il team principale responsabile della gestione della richiesta lungo il suo ciclo di vita. | ||
| Descrizione Il Responsabile del Caso è l'individuo o il gruppo a cui è assegnata la responsabilità principale per un caso di onboarding. Questa persona è tipicamente responsabile del suo completamento tempestivo e di successo.\n\nQuesto attributo aiuta ad analizzare il carico di lavoro e le prestazioni a livello di responsabile del caso. Può essere utilizzato per vedere se alcuni responsabili del caso hanno tempi di ciclo più lunghi o tassi di rifiuto più elevati, indicando potenzialmente esigenze di formazione o squilibri di risorse. Perché è importante Identifica la persona o il team responsabile di un caso, consentendo l'analisi delle prestazioni dei case manager. Dove trovare Questo è solitamente un campo specifico sull'entità caso primaria in Fenergo, che indica l'assegnazione del caso. Esempi s.jonesonboarding_team_am.chen | |||
| Tempo di Elaborazione ProcessingTime | La durata del tempo trascorso lavorando attivamente su un'attività. | ||
| Descrizione Il Tempo di Elaborazione, noto anche come tempo attivo, è la durata calcolata tra il timestamp di inizio e fine di una singola attività. Rappresenta il tempo in cui una risorsa è stata attivamente impegnata in un compito. Questa metrica è fondamentale per l'analisi delle prestazioni. Viene utilizzata nelle dashboard di analisi dei bottleneck per individuare quali attività specifiche sono le più dispendiose in termini di tempo, aiutando a concentrare gli sforzi di miglioramento dove avranno il maggiore impatto. Perché è importante Questa metrica calcolata misura il tempo di lavoro attivo per ciascuna attività, il che è cruciale per identificare i colli di bottiglia delle prestazioni. Dove trovare Calcolato come la differenza tra 'EventEndTime' e 'EventStartTime' (EndTime - StartTime). Esempi 86400000360000018000000 | |||
| Tipo cliente CustomerType | La classificazione del cliente in fase di onboarding, come Individuo, Azienda o Trust. | ||
| Descrizione Questo attributo segmenta i clienti in diverse categorie in base alla loro struttura legale o alla relazione con l'istituzione finanziaria. Diversi tipi di clienti spesso seguono percorsi di onboarding distinti con complessità e requisiti di due diligence variabili.\n\nL'analisi del processo per Tipo Cliente aiuta a identificare le differenze di performance tra i segmenti. È fondamentale per la Perché è importante Consente il confronto delle prestazioni del processo tra diversi segmenti di clienti, che spesso presentano complessità e SLA variabili. Dove trovare Queste informazioni sono tipicamente memorizzate sull'entità cliente o del cliente all'interno di Fenergo e collegate al caso di richiesta. Esempi IndividualeAziendaleTrustPartnership | |||
Attività di Onboarding Cliente KYC
| Activity | Descrizione | ||
|---|---|---|---|
| Caso Chiuso | Questa è l'attività finale, che significa che il caso di onboarding è amministrativamente chiuso in Fenergo, senza ulteriori azioni previste. Questo si applica sia alle richieste approvate che a quelle rifiutate ed è dedotto da uno stato finale 'Chiuso'. | ||
| Perché è importante Questa attività funge da punto finale definitivo per l'intero processo. Assicura calcoli precisi del tempo di ciclo per tutti i casi, indipendentemente dal loro esito, e conferma che il processo si è concluso. Dove trovare Inferito dal log di audit del caso Fenergo identificando il timestamp quando lo stato del caso viene impostato su 'Chiuso', 'Completato' o un altro stato terminale. Acquisisci Identificare il timestamp del cambiamento di stato finale a 'Chiuso' o 'Completato'. Tipo di evento inferred | |||
| Caso creato | Questa attività segna l'inizio del processo di onboarding KYC quando una nuova richiesta cliente viene formalmente creata in Fenergo. È tipicamente un evento esplicito registrato con un timestamp specifico quando il record del caso viene salvato per la prima volta. | ||
| Perché è importante Come evento di inizio, questa attività è essenziale per calcolare il tempo di ciclo complessivo di onboarding e analizzare il throughput. Fornisce la base per tutte le misurazioni di processo successive e il tracciamento degli SLA. Dove trovare Questo viene tipicamente acquisito dal timestamp di creazione dell'entità caso primaria in Fenergo, spesso trovato in tabelle relative a casi o Acquisisci Utilizzi il timestamp di creazione del record del caso di onboarding. Tipo di evento explicit | |||
| Revisione Conformità Avviata | Questa attività segna l'inizio della revisione da parte del dipartimento di conformità, una fase critica e spesso prolungata. Viene dedotto quando il caso è assegnato alla coda di lavoro della conformità o il suo stato cambia a 'In Attesa di Revisione Conformità'. | ||
| Perché è importante Questa attività è il punto di partenza per misurare il KPI 'Tempo Medio di Revisione Conformità'. Aiuta a identificare quanto tempo i casi attendono prima di essere attivamente elaborati dal team di conformità. Dove trovare Inferito dal log di audit del caso Fenergo catturando il timestamp del cambiamento di stato a 'In Revisione Conformità' o l'assegnazione del caso a un funzionario o team di conformità. Acquisisci Identificare il timestamp del cambiamento di stato a 'Sotto Revisione Conformità' o evento di assegnazione. Tipo di evento inferred | |||
| Revisione Conformità Completata | Contrassegna l'approvazione formale da parte del dipartimento di conformità, indicando che tutti i requisiti normativi sono stati soddisfatti. Questo è inferito dal completamento di un task o da un cambiamento di stato a 'Conformità Approvata'. | ||
| Perché è importante Come tappa fondamentale, il completamento di questa attività è critico per il tempo di ciclo complessivo. È il punto finale per misurare il 'Tempo Medio di Revisione della Conformità' e identificare i bottleneck all'interno della funzione di conformità. Dove trovare Inferito dal timestamp di completamento del task 'Compliance Review' all'interno del workflow Fenergo o dall'evento di aggiornamento dello stato nella cronologia del caso. Acquisisci Utilizzi il timestamp di completamento dell'attività di revisione conformità o l'aggiornamento dello stato. Tipo di evento inferred | |||
| Revisione Documenti Completata | Indica il completamento del processo manuale o automatico di verifica dell'autenticità e correttezza di tutti i documenti cliente inviati. Questo evento è solitamente dedotto dal completamento di un'attività del workflow o da un cambiamento di stato in Fenergo. | ||
| Perché è importante Questo è un traguardo critico dove si verificano molti ritardi. L'analisi della durata e dei risultati di questa attività aiuta a individuare i colli di bottiglia nell'elaborazione dei documenti e supporta KPI come il 'Tasso di Superamento al Primo Tentativo'. Dove trovare Inferito dal timestamp di completamento del task 'Document Verification' nel workflow del caso o da un aggiornamento dello stato a 'Documenti Approvati' nel log della cronologia del caso. Acquisisci Utilizzi il timestamp di completamento dell'attività di revisione documenti o un cambiamento di stato correlato. Tipo di evento inferred | |||
| Richiesta Approvata | Questa attività rappresenta la decisione finale di approvare la richiesta di onboarding del cliente. Viene dedotto dal cambiamento di stato del caso a uno stato finale 'Approvato' o 'Onboarding Approvato'. | ||
| Perché è importante Questo traguardo chiave significa un esito positivo prima dei passaggi finali di attivazione dell'account. È essenziale per calcolare i tassi di approvazione e analizzare le proprietà dei clienti onboardati con successo. Dove trovare Inferito dalla cronologia del caso o dal log di audit trovando il timestamp del cambiamento di stato finale a 'Approvato' o a uno stato positivo terminale simile. Acquisisci Identificare il timestamp del cambiamento di stato finale a 'Approvato'. Tipo di evento inferred | |||
| Richiesta Rifiutata | Questa attività è un evento terminale che rappresenta la decisione finale di rifiutare la richiesta del cliente. Viene dedotto dal cambiamento di stato del caso a uno stato finale 'Rifiutato' o 'Declinato'. | ||
| Perché è importante Come punto finale chiave del processo, questa attività è vitale per calcolare il 'Tasso di Rifiuto delle Richieste' e analizzare le ragioni del fallimento. Aiuta a identificare i punti di rifiuto comuni e a migliorare la qualità delle richieste. Dove trovare Inferito dal log di audit del caso catturando il timestamp quando lo stato finale cambia in 'Rifiutato'. La ragione del rifiuto è spesso memorizzata in un campo correlato. Acquisisci Identificare il timestamp del cambiamento di stato finale a 'Rifiutato'. Tipo di evento inferred | |||
| Valutazione del Rischio Completata | Rappresenta il completamento del processo interno di classificazione del rischio, in cui al cliente viene assegnato un rating di rischio basato su vari fattori. Questo viene dedotto da un cambiamento di stato o dalla compilazione di un campo di rating del rischio. | ||
| Perché è importante Questo è un traguardo chiave per il processo decisionale che spesso determina il successivo percorso del Dove trovare Inferito dal log della cronologia del caso identificando quando il caso passa a uno stato come 'Rischio Valutato' o quando il campo finale 'Customer Risk Rating' viene popolato con un valore. Acquisisci Utilizzi il timestamp quando il campo del rating di rischio è finalizzato o uno stato correlato è impostato. Tipo di evento inferred | |||
| Account Attivato | Indica che l'account del cliente è stato creato e attivato con successo nel sistema bancario centrale o in un sistema a valle pertinente dopo l'approvazione. Questo può essere inferito da un aggiornamento finale dello stato in Fenergo post-approvazione. | ||
| Perché è importante Questa attività conferma il passaggio riuscito dal processo di onboarding allo stato di cliente attivo. Misurare il tempo dall'approvazione all'attivazione può rivelare ritardi nella configurazione operativa. Dove trovare Questo può essere dedotto da uno stato del caso come 'Account Attivo' o 'Onboarding Completato'. Potrebbe anche essere un evento esplicito registrato da un'integrazione con un sistema a valle. Acquisisci Cercare un cambiamento di stato post-approvazione o un evento di log di successo dell'integrazione. Tipo di evento inferred | |||
| Dati e Documenti Richiesti | Questo evento significa che il sistema o un agente di onboarding ha formalmente richiesto informazioni e documentazione necessarie al cliente. È spesso acquisito come evento esplicito quando viene inviato un `template` di comunicazione standardizzato. | ||
| Perché è importante Questa attività segna l'inizio di una fase dipendente dal cliente. Misurare il tempo da questo punto fino alla ricezione dei documenti è fondamentale per analizzare il percorso del cliente e identificare i ritardi di comunicazione. Dove trovare Catturato da un log eventi associato alle comunicazioni del cliente o da un log di completamento attività per 'Richiesta Documenti'. Può anche essere inferito da un cambiamento di stato a 'In Attesa di Informazioni dal Cliente'. Acquisisci Cercare un evento registrato per la comunicazione del cliente o il completamento di un task. Tipo di evento explicit | |||
| Documenti Ricevuti | Questa attività indica che il cliente ha caricato o inviato i documenti richiesti, che sono ora disponibili in Fenergo per la revisione. Ciò viene tipicamente dedotto quando lo stato del caso viene aggiornato a 'Documenti Ricevuti' o 'In Attesa di Revisione'. | ||
| Perché è importante Questo segna la fine del periodo di attesa del cliente e l'inizio del ciclo di revisione interno. È cruciale per misurare i tempi di risposta del cliente e i tempi di coda di elaborazione interna. Dove trovare Inferito dal registro di audit del caso, che registra il timestamp di un cambiamento di stato a 'Documenti Ricevuti' o uno stato simile. Può anche essere legato a eventi di caricamento documenti. Acquisisci Identificare il timestamp del cambiamento di stato a 'Documenti Ricevuti' o 'Pronti per la Revisione'. Tipo di evento inferred | |||
| Informazioni aggiuntive richieste | Rappresenta un ciclo di rilavorazione in cui il team di onboarding deve ricontattare il cliente per chiarimenti o documenti mancanti. Questo è un evento esplicito, tipicamente registrato quando viene inviata una comunicazione al cliente. | ||
| Perché è importante Questa attività è un indicatore primario di inefficienza del processo e di scarsa esperienza del cliente. Il monitoraggio della sua frequenza aiuta a identificare le cause alla radice delle rilavorazioni e supporta il KPI 'Tasso di Cicli di Rilavorazione'. Dove trovare Catturato da un log eventi di comunicazioni del cliente o da un cambiamento di stato a 'In Attesa di Informazioni Aggiuntive'. Il primo è più preciso per catturare il momento esatto della richiesta. Acquisisci Trovare eventi di comunicazione registrati o un cambiamento di stato a 'In Attesa di Risposta del Cliente'. Tipo di evento explicit | |||
| Screening Iniziale Eseguito | Rappresenta il completamento dei controlli preliminari automatici o manuali, come la convalida dei dati di base o lo screening delle liste di sanzioni. Questo viene spesso dedotto da un cambiamento di stato all'interno del workflow del caso Fenergo, ad esempio, il passaggio da 'Nuovo' a 'Screening Completato'. | ||
| Perché è importante Il monitoraggio di questo primo traguardo aiuta a identificare problemi di qualità dei Dove trovare Inferito dalla cronologia del caso o dal log di audit identificando il timestamp quando lo stato del caso passa a uno stato che indica che lo screening è completo, come 'Screening Superato' o 'In Attesa di Documenti'. Acquisisci Identificare il cambiamento di stato a 'Screening Completato' o simile dalla cronologia del caso. Tipo di evento inferred | |||
| Verifiche Background Avviate | Questa attività segna il punto in cui vengono attivati controlli esterni di background, AML o di credito. È spesso un evento esplicito registrato quando viene richiamata un'integrazione con un servizio di terze parti. | ||
| Perché è importante Tracciare l'inizio e il completamento di questi controlli è vitale per comprendere i ritardi causati da dipendenze esterne. Aiuta a isolare il tempo di processo interno dal tempo di attesa esterno. Dove trovare Tipicamente acquisito dai log di sistema che registrano le chiamate API a fornitori di screening esterni o dalla creazione di un'attività specifica di 'Verifica Antecedenti' all'interno del caso Fenergo. Acquisisci Trovare log per integrazioni di servizi esterni o la creazione di un task di 'Screening'. Tipo di evento explicit | |||
Guide all'Estrazione
Fasi
- Accedere al Modulo di Reporting: Acceda all'applicazione Fenergo con un account utente che abbia permessi sufficienti per il modulo Reporting & Analytics. Navighi al modulo, tipicamente presente nel menu principale dell'applicazione.
- Creare un Nuovo Report: Avvii la creazione di un nuovo report personalizzato. Selezioni un nome e una descrizione che identifichino chiaramente il Suo scopo, ad esempio, 'Log Eventi Onboarding KYC per Process Mining'.
- Definire la Sorgente Dati Primaria: Selezioni l'oggetto dati principale o la vista che cattura le informazioni sul ciclo di vita del caso. Si tratta spesso di una vista preconfigurata come
[CaseWorkflowHistory]o[LifecycleEventsView]. Questo oggetto dovrebbe contenere identificatori di caso, nomi o stati degli eventi e timestamp. - Configurare le Colonne del Report (Attributi): Utilizzi l'interfaccia del builder di report per aggiungere colonne. Mappi i campi di origine dal modello dati di Fenergo agli attributi del log eventi richiesti. Ad esempio, mappi
CaseIDdi Fenergo aCustomerApplication,EventTimestampaEventStartTimeeEventPerformeraInitiatingUser. - Costruire la Logica delle Attività: Questo è il passaggio più critico. Il report deve essere configurato per generare una riga separata per ciascuna delle 14 attività richieste. Ciò si ottiene creando blocchi logici o set di dati filtrati per ogni attività e combinandoli utilizzando una funzione UNION o equivalente all'interno del builder di report.
- Definire la Logica 'Caso Creato': Crei il primo blocco. Filtri la sorgente dati per l'evento iniziale di creazione del caso. Questo si basa spesso sul timestamp più antico associato al caso o su un tipo di evento denominato 'Case Created'. Mappi la
CreationDateaEventStartTime. - Definire la Logica delle Attività Basata sullo Stato: Per le attività inferite dai cambiamenti di stato (ad esempio, 'Documenti Ricevuti', 'Richiesta Approvata'), crei blocchi separati. Filtri la sorgente dati sul valore specifico del campo
Statuse utilizzi laStatusChangeDatecomeEventStartTime. - Definire la Logica delle Attività Basata sui Task: Per le attività legate ai task del workflow (ad esempio, 'Revisione Conformità Completata'), crei blocchi che filtrano su
TaskNameeTaskCompletionDate. Utilizzi la data di completamento comeEventStartTime. - Impostare i Filtri del Report Globale: Applichi filtri a livello di report per definire l'ambito dei dati. Imposti un
Intervallo di Datespecifico perEventStartTimeper evitare esportazioni eccessivamente grandi. Un periodo di 3-6 mesi è raccomandato per l'analisi iniziale. Filtri per il tipo di caso specifico, come 'Onboarding Cliente KYC'. - Eseguire e Visualizzare in Anteprima il Report: Esegua il report all'interno dell'interfaccia utente di Fenergo. Visualizzi in anteprima le prime 100-200 righe per assicurarsi che la struttura dei dati sia corretta, tutte le colonne siano popolate come previsto e siano presenti diverse attività.
- Esportare i Dati: Esporti i risultati completi del report in un file CSV o Excel. Questo è il file di log eventi grezzo.
- Preparazione Finale dei Dati: Apra il file CSV esportato. Se le colonne
SourceSystemeLastDataUpdatenon potessero essere generate direttamente dal report, le aggiunga manualmente. Imposti 'Fenergo' comeSourceSystemper tutte le righe e il timestamp di esportazione comeLastDataUpdate.
Configurazione
- Prerequisiti: L'utente richiede l'accesso al modulo Fenergo Reporting & Analytics con permessi per creare ed eseguire report personalizzati.
- Sorgenti Dati Principali: Il report dovrebbe essere costruito principalmente dagli oggetti di gestione dei casi e dalla cronologia del workflow di Fenergo. Le sorgenti comuni includono
[CaseDetails],[CaseStatusHistory]e[WorkflowTaskHistory]. I nomi esatti possono variare in base alla configurazione di Fenergo. - Intervallo di Date: È fondamentale impostare un filtro per intervallo di date sul timestamp dell'evento per gestire le prestazioni. Inizi con un periodo recente di 3-6 mesi. Per l'analisi storica, esegua il report a lotti (ad esempio, trimestralmente o annualmente).
- Filtri Chiave: Filtri sempre per il processo o il tipo di caso specifico, come 'Onboarding Cliente KYC', per escludere dati irrilevanti. Potrebbe anche essere necessario filtrare per tipo di entità legale o giurisdizione a seconda degli obiettivi della Sua analisi.
- Definizione Attività: Ogni attività deve essere definita utilizzando criteri di filtro specifici su campi come
Status,TaskNameo un campoEventTypededicato. Affidarsi a questi campi è fondamentale per isolare ogni evento unico nel processo. - Considerazioni sulle Prestazioni: I report che uniscono molte sorgenti di dati o scansionano un ampio intervallo di date possono essere lenti. Se possibile, pianifichi l'esecuzione del report durante le ore di minor traffico. Eviti di includere colonne non necessarie nell'esportazione, poiché ciò aumenta il tempo di elaborazione.
a Query di Esempio config
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'