Il Suo Template Dati per l'Onboarding Clienti KYC
Il Suo Template Dati per l'Onboarding Clienti KYC
- Attributi consigliati da raccogliere
- Attività chiave da tracciare
- Guida all'estrazione per ACTICO
Attributi di Onboarding Clienti KYC
| Nome | Descrizione | ||
|---|---|---|---|
| Nome attività ActivityName | Il nome dello specifico evento aziendale o dell'attività eseguita all'interno del processo di onboarding del cliente. | ||
| Descrizione Questo attributo registra il nome di ogni passaggio o attività che si verifica durante il processo KYC, come 'Domanda Inviata', 'Valutazione del Rischio Eseguita' o 'Domanda Approvata'. Fornisce i blocchi costitutivi sequenziali della mappa del processo. L'analisi del Nome Attività consente la visualizzazione del flusso del processo, l'identificazione di attività frequenti o rare e il rilevamento di colli di bottiglia o cicli di rilavorazione. È una pietra miliare per comprendere quali azioni vengono eseguite e in quale ordine, il che è cruciale per l'analisi delle varianti e i controlli di conformità. Perché è importante Definisce i passaggi nella mappa di processo, consentendo la visualizzazione del flusso di processo, l'identificazione delle deviazioni e l'analisi della frequenza e della sequenza delle attività. Dove trovare Questa informazione si trova tipicamente in una tabella di log degli eventi all'interno di ACTICO, spesso in un campo che descrive il tipo di evento o attività. Consultare la documentazione ACTICO. Esempi Domanda InviataValutazione del Rischio EseguitaRevisione Conformità CompletataRichiesta Rifiutata | |||
| Richiesta Cliente CustomerApplication | L'identificatore unico per una singola domanda di onboarding cliente, che funge da ID caso per l'analisi del processo. | ||
| Descrizione La Domanda Cliente è l'identificatore primario del caso che raggruppa tutti gli eventi e le attività relative al percorso di onboarding di un singolo cliente. Rappresenta una singola istanza completa del processo KYC, dalla presentazione iniziale alla decisione finale di approvazione o rifiuto. Nel process mining, questo attributo è essenziale per ricostruire il percorso end-to-end di ogni domanda. Consente agli analisti di tracciare la sequenza delle attività, misurare i tempi di ciclo totali e confrontare diversi percorsi di processo, o varianti, intrapresi dalle varie domande. Tutti gli eventi che condividono lo stesso ID Domanda Cliente sono considerati parte dello stesso caso. Perché è importante Questo è l'attributo fondamentale per il process mining, poiché collega tutti gli eventi correlati in un'unica istanza di processo coesa, consentendo un'analisi end-to-end dell'esperienza di onboarding di ogni cliente. Dove trovare Questa è una chiave primaria nelle tabelle principali delle domande o della gestione dei casi all'interno di ACTICO. Consultare la documentazione ACTICO per nomi specifici di tabelle e campi. Esempi APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| Timestamp Evento EventTime | Il timestamp che indica quando una specifica attività è iniziata o si è verificata. | ||
| Descrizione Event Time è la data e l'ora precise in cui un'attività è stata registrata nel sistema. Fornisce l'ordine cronologico per tutti gli eventi all'interno di un singolo caso di richiesta cliente, formando la timeline del percorso di onboarding. Questo attributo è fondamentale per tutte le analisi basate sul tempo. Viene utilizzato per calcolare i tempi di ciclo tra le attività, identificare ritardi e tempi di attesa, misurare la durata complessiva del caso e verificare la conformità con gli Service Level Agreement (SLA). La sequenza di questi "timestamp" per un dato caso consente agli strumenti di Process Mining di ricostruire l'esatto flusso di processo così come è avvenuto. Perché è importante Questo attributo fornisce l'ordine cronologico degli eventi, essenziale per calcolare le durate, scoprire i colli di bottiglia e analizzare la timeline del processo. Dove trovare Situato nelle tabelle dei log degli eventi di ACTICO, questo è il "timestamp" associato a ogni attività registrata. Consultare la documentazione di ACTICO. Esempi 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Sistema di Origine SourceSystem | Il sistema di registrazione da cui provengono i dati dell'evento. | ||
| Descrizione Questo attributo identifica il sistema informativo sorgente dove sono stati generati i dati. Per questo processo, sarà costantemente 'ACTICO', ma in analisi più ampie che coinvolgono più sistemi, aiuta a differenziare le origini dei dati. Nel contesto del process mining, è cruciale per la governance e la validazione dei dati. Garantisce che i dati siano correttamente attribuiti alla loro fonte, il che è importante quando si uniscono dati da diversi sistemi per creare una visione olistica del processo. Aiuta anche nella risoluzione dei problemi di qualità dei dati tracciandoli fino al sistema di origine. Perché è importante Fornisce un contesto essenziale sull'origine dei dati, garantendo la lineage dei dati e la governance, il che è fondamentale quando si combinano dati da più fonti. Dove trovare Questo è tipicamente un valore statico ('ACTICO') aggiunto durante il processo di estrazione e trasformazione dei dati per etichettare il dataset. Esempi ACTICOPiattaforma ACTICOModulo KYC Actico | |||
| Ultimo `Data Update` LastDataUpdate | Il `timestamp` che indica l'ultima volta che i `dati` sono stati aggiornati o estratti dal sistema sorgente. | ||
| Descrizione Questo attributo registra la data e l'ora dell'ultima estrazione di dati da ACTICO. È un campo di metadati che si applica all'intero dataset, anziché a singoli eventi, fornendo contesto sulla freschezza dell'analisi. Nelle dashboard e nei report, questa informazione è vitale per gli utenti per comprendere quanto siano attuali i dati. Aiuta a gestire le aspettative sulla tempestività degli insight ed è cruciale per il monitoraggio operativo dove i dati quasi in tempo reale sono importanti. La visualizzazione di questo timestamp garantisce trasparenza e fiducia nei dati presentati. Perché è importante Indica la freschezza dei dati, consentendo agli utenti di capire se stanno analizzando informazioni aggiornate, il che è fondamentale per il processo decisionale operativo. Dove trovare Questo valore viene generato e memorizzato durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati. Riflette il timestamp quando il lavoro ETL è stato completato con successo. Esempi 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Data Obiettivo SLA SlaTargetDate | La data entro cui si prevede il completamento del processo di onboarding del cliente. | ||
| Descrizione La Data Obiettivo SLA è la scadenza per il completamento dell'onboarding di un cliente, come definito dagli accordi sui livelli di servizio interni. Questa data è spesso calcolata in base alla data di presentazione della domanda più un tempo di elaborazione standard. Questo attributo è essenziale per monitorare la conformità SLA. Confrontando la data di completamento effettiva di un caso con la sua Data Obiettivo SLA, il sistema può determinare se il caso è stato completato in tempo o ha violato l'SLA. Questa è la base per la dashboard 'Performance SLA Onboarding' e il KPI 'Tasso di Aderenza SLA Onboarding'. Perché è importante Fornisce il benchmark per misurare le prestazioni puntuali, consentendo il monitoraggio e la reportistica diretta della conformità SLA. Dove trovare Questo potrebbe essere memorizzato come campo nella tabella principale del caso in ACTICO o potrebbe essere derivato in base a regole aziendali (ad esempio, Data di Presentazione + 5 giorni lavorativi). Esempi 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Dipartimento Department | Il reparto o il team aziendale responsabile dell'esecuzione dell'attività. | ||
| Descrizione Questo attributo assegna un'attività a una specifica unità organizzativa, come 'Conformità', 'Team Onboarding' o 'Relazioni Clienti'. Fornisce un contesto organizzativo al flusso di processo. L'analisi a livello di reparto è cruciale per comprendere come il lavoro viene passato tra diverse parti dell'organizzazione. Aiuta a identificare i colli di bottiglia inter-dipartimentali, misurare l'efficienza dipartimentale e analizzare l'allocazione delle risorse tra i team. Le dashboard possono essere filtrate per reparto per fornire ai manager una visione delle prestazioni specifiche del loro team. Perché è importante Fornisce una dimensione organizzativa per l'analisi, consentendo l'identificazione di ritardi tra i reparti e la valutazione delle prestazioni a livello di team. Dove trovare Questa informazione potrebbe essere memorizzata direttamente con i dati dell'evento o derivata unendo i dati utente con una tabella anagrafica HR che mappa gli utenti ai reparti. Consultare la documentazione ACTICO. Esempi ComplianceTeam di OnboardingServizio clienti | |||
| Livello di Rischio RiskLevel | Il livello di rischio calcolato della domanda del cliente, come Basso, Medio o Alto. | ||
| Descrizione Questo attributo rappresenta la categoria di rischio valutata di un cliente, che spesso determina la complessità e il rigore del successivo processo KYC. Un cliente ad alto rischio potrebbe richiedere controlli e approvazioni aggiuntive rispetto a uno a basso rischio. Nel process mining, il Livello di Rischio è una potente dimensione per l'analisi comparativa. Consente agli analisti di verificare se il processo segue correttamente percorsi diversi in base al rischio, come previsto. Ad esempio, si può verificare che tutti i clienti ad alto rischio subiscano un passaggio di due diligence migliorata. È fondamentale per la dashboard 'Flussi di Processo Valutazione del Rischio'. Perché è importante Consente la segmentazione dei casi in base al rischio, permettendo di analizzare se il processo si adatta correttamente ai diversi profili di rischio come richiesto dalle politiche di conformità. Dove trovare Questo è un dato chiave memorizzato a livello di caso nella tabella principale delle domande all'interno di ACTICO. Esempi BassoMedioElevato | |||
| Motivo del Rigetto RejectionReason | Il motivo specifico fornito quando una domanda del cliente viene rifiutata. | ||
| Descrizione Quando lo stato finale di una domanda è 'Rifiutato', questo attributo fornisce la causa sottostante. Esempi includono 'Documentazione Incompleta', 'Controllo Precedenti Fallito' o 'Profilo ad Alto Rischio'. Questo è un attributo vitale per l'analisi delle cause profonde. Analizzando la frequenza delle diverse ragioni di rifiuto, l'azienda può identificare problemi sistemici nel processo o con le presentazioni dei clienti. Ad esempio, un numero elevato di rifiuti dovuti a documentazione incompleta potrebbe indicare che le istruzioni per la domanda non sono chiare. Questo supporta direttamente la dashboard 'Tasso di Rifiuto delle Domande e Motivi'. Perché è importante Fornisce il 'perché' dietro i rifiuti delle domande, consentendo l'analisi delle cause profonde per ridurre il tasso di rifiuto e migliorare l'efficienza del processo. Dove trovare Solitamente si trova nella tabella principale del caso o della domanda in ACTICO, spesso popolato solo quando lo Stato della Domanda è 'Rifiutato'. Esempi Documentazione IncompletaVerifica Identità FallitaCorrispondenza SanzioniPunteggio di Rischio Elevato | |||
| Ora di Fine EndTime | Il timestamp che indica quando una specifica attività è stata completata. | ||
| Descrizione L'Ora di Fine segna il completamento di un'attività. Abbinata all'Ora di Inizio (EventTime), consente il calcolo della durata precisa di ogni attività, nota come tempo di elaborazione. Non tutti gli eventi hanno un'ora di fine distinta, poiché alcuni possono essere istantanei. Questo attributo è fondamentale per l'analisi delle prestazioni, in particolare per misurare quanto tempo richiede ogni passaggio. Consente la creazione di dashboard di performance dettagliate, aiuta a identificare quali attività consumano più tempo ed è essenziale per il calcolo di KPI come il 'Tempo Medio di Revisione Documenti'. Perché è importante Consente il calcolo di durate precise delle attività (tempo di elaborazione), cruciale per identificare i "bottleneck" delle prestazioni e analizzare l'efficienza delle risorse. Dove trovare Come l'ora di inizio, questo si trova tipicamente nelle tabelle dei log degli eventi di ACTICO. Alcuni sistemi memorizzano gli orari di inizio e fine in colonne separate per un singolo record di evento. Consultare la documentazione di ACTICO. Esempi 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Stato Richiesta ApplicationStatus | L'esito finale o lo stato attuale della domanda di onboarding del cliente. | ||
| Descrizione Questo attributo indica l'esito finale di un caso, tipicamente 'Approvato' o 'Rifiutato'. Può anche mostrare lo stato dei casi in corso. Questa è una dimensione critica per l'analisi basata sui risultati. Comprendere perché le domande vengono approvate o rifiutate è un obiettivo chiave del process mining KYC. Questo attributo consente di filtrare la mappa del processo per vedere i percorsi tipici delle domande approvate rispetto a quelle rifiutate, aiutando a identificare i modelli di processo che portano a risultati indesiderati. È anche la base per il calcolo del KPI 'Tasso di Rifiuto delle Domande'. Perché è importante Definisce l'esito di ogni caso, consentendo un'analisi comparativa tra istanze di processo riuscite e non riuscite e il calcolo dei tassi di rifiuto. Dove trovare Questo è un attributo a livello di caso, spesso presente nella tabella principale del caso o della domanda in ACTICO. Riflette lo stato finale della domanda. Esempi ApprovatoRifiutatoIn CorsoInformazioni in Sospeso | |||
| Utente Iniziatore InitiatingUser | L'ID utente o il nome del dipendente che ha eseguito l'attività. | ||
| Descrizione Questo attributo identifica lo specifico utente o agente di sistema responsabile dell'esecuzione di un'attività. Collega i passaggi del processo agli individui o ai team che li hanno eseguiti. L'analisi delle prestazioni per utente è un requisito comune. Questo attributo consente la creazione di dashboard che mostrano la distribuzione del carico di lavoro, i tempi di elaborazione individuali e i confronti delle prestazioni tra utenti o team. Aiuta a identificare gli individui ad alte prestazioni e coloro che potrebbero richiedere formazione aggiuntiva, ed è fondamentale per comprendere l'allocazione e l'utilizzo delle risorse. Perché è importante Collega le attività di processo a utenti specifici, consentendo l'analisi delle prestazioni per individuo o team e aiutando a identificare le esigenze di formazione o gli squilibri delle risorse. Dove trovare Tipicamente memorizzato insieme a ogni evento nei log degli eventi o nelle tabelle della cronologia delle transazioni di ACTICO. Consultare la documentazione ACTICO. Esempi john.doejane.smithSYSTEM_USER | |||
| È Automatizzato IsAutomated | Un indicatore che segnala se un'attività è stata eseguita automaticamente dal sistema o manualmente da un utente. | ||
| Descrizione Questo attributo booleano distingue tra le attività eseguite da un utente umano e quelle eseguite dall'automazione del sistema, come un controllo automatico dei precedenti o la valutazione del rischio. L'analisi di questo attributo aiuta a valutare l'efficacia delle iniziative di automazione. Consente un confronto dei tempi di elaborazione tra passaggi automatizzati e manuali, identifica quali parti del processo sono ancora prevalentemente manuali e può evidenziare opportunità per ulteriore automazione per migliorare l'efficienza e ridurre i costi operativi. Perché è importante Distingue tra attività umane e di sistema, fondamentale per misurare l'impatto dell'automazione e identificare opportunità di futuri guadagni di efficienza. Dove trovare Questo può essere inferito dall'attributo 'InitiatingUser' (ad esempio, se l'utente è 'SYSTEM') o potrebbe essere un flag dedicato nel log degli eventi. Consultare la documentazione ACTICO. Esempi truefalse | |||
| È una Rilavorazione IsRework | Un flag calcolato che identifica se un'attività è un passaggio ripetuto o parte di un ciclo di rilavorazione. | ||
| Descrizione Questo attributo booleano segnala le attività che vengono eseguite per una seconda o successiva volta all'interno dello stesso caso, come una 'Revisione Documenti' che avviene dopo una richiesta di maggiori informazioni. Identifica le istanze di rilavorazione, che sono tipicamente una fonte di inefficienza del processo. Identificare la rilavorazione è un obiettivo primario del process mining. Questo flag consente la quantificazione della rilavorazione, come il calcolo del KPI 'Tasso di Rilavorazione Documenti'. Nella mappa del processo, i cicli di rilavorazione possono essere evidenziati per mostrare dove il processo sta tornando su se stesso. Questo aiuta a individuare problemi di qualità o aree in cui il processo non è 'giusto la prima volta'. Perché è importante Evidenzia le istanze di lavoro ripetuto, consentendo la misurazione diretta dell'inefficienza del processo e l'identificazione di attività con problemi di qualità o chiarezza. Dove trovare Questo è un attributo calcolato. La logica è definita all'interno dello strumento di process mining o durante la trasformazione dei dati per rilevare attività ripetute all'interno dello stesso caso. Esempi truefalse | |||
| Paese Country | Il paese di residenza del cliente che richiede l'onboarding. | ||
| Descrizione Questo attributo specifica il paese del cliente, che può avere un impatto significativo sul processo KYC. Diverse giurisdizioni hanno requisiti normativi diversi, che possono innescare passaggi di processo aggiuntivi o alternativi. L'analisi del processo per paese consente un confronto delle prestazioni tra diverse regioni. Può aiutare a identificare se alcuni paesi sperimentano costantemente tempi di ciclo più lunghi o tassi di rifiuto più elevati, indicando potenzialmente attriti normativi o sfide di mercato specifiche. Questa visione geografica è importante per le organizzazioni globali che mirano a standardizzare i processi rispettando le esigenze di conformità locali. Perché è importante Fornisce una dimensione geografica per l'analisi, aiutando a comprendere le variazioni di processo e le differenze di performance tra le diverse giurisdizioni normative. Dove trovare Questo è un dato fondamentale del cliente memorizzato a livello di caso o cliente all'interno del sistema ACTICO. Esempi Stati UnitiDEUGBRSGP | |||
| Stato SLA SlaState | Uno stato calcolato che indica se il caso ha rispettato, violato o è a rischio di violare il suo SLA. | ||
| Descrizione Questo attributo fornisce una valutazione categorica delle prestazioni di un caso rispetto al suo Service Level Agreement. È derivato confrontando il tempo di completamento del caso (o il tempo corrente per i casi aperti) con la 'SlaTargetDate'. Questo attributo semplifica la reportistica SLA convertendo i confronti delle date in uno stato di facile comprensione. Le dashboard possono usarlo per visualizzazioni chiare come grafici a torta o indicatori che mostrano la percentuale di casi 'Rispettati' versus 'Violati'. È un elemento chiave per la dashboard 'Performance SLA Onboarding' e supporta direttamente il KPI 'Tasso di Aderenza SLA Onboarding'. Perché è importante Fornisce uno stato chiaro e categorico di conformità SLA per ogni caso, semplificando la reportistica e consentendo una facile visualizzazione delle prestazioni rispetto agli obiettivi. Dove trovare Questo è un attributo calcolato derivato dalla logica aziendale che confronta il timestamp di completamento del caso con la 'SlaTargetDate'. Esempi RaggiuntoViolatoA Rischio | |||
| Tempo di Elaborazione ProcessingTime | La durata del tempo trascorso lavorando attivamente su un'attività. | ||
| Descrizione Il Tempo di Elaborazione è la durata calcolata dal momento di inizio al momento di fine di un'attività. Questa metrica rappresenta il 'tempo di contatto' o il tempo di lavoro attivo, in contrasto con il tempo di attesa tra le attività. Questo è un KPI critico per misurare l'efficienza operativa. Tempi di elaborazione elevati per determinate attività sono chiari indicatori di colli di bottiglia o di attività eccessivamente complesse. Aggregando questa metrica, i manager possono identificare quali passaggi consumano più risorse e dar loro priorità per iniziative di miglioramento dei processi o di automazione. È un componente fondamentale delle dashboard di performance. Perché è importante Misura la durata effettiva del lavoro di un'attività, aiutando a individuare le attività inefficienti che consumano più tempo e risorse. Dove trovare Questa è una metrica calcolata, derivata sottraendo l'Ora di Inizio ('EventTime') dall'Ora di Fine ('EndTime') per ogni attività. Esempi 864000003600000600000 | |||
| Tipo cliente CustomerType | Categorizzazione del cliente, come Individuale o Aziendale. | ||
| Descrizione Questo attributo classifica il richiedente in diverse categorie, ad esempio una persona fisica rispetto a un'entità aziendale. Il processo KYC spesso differisce significativamente tra questi tipi, con l'onboarding aziendale molto più complesso. L'utilizzo del Tipo Cliente come dimensione consente una chiara separazione e confronto di questi processi distinti all'interno dello stesso dataset. Gli analisti possono filtrare la mappa del processo per visualizzare solo i clienti 'Aziendali' per comprenderne le sfide uniche, i colli di bottiglia e i tempi di ciclo, senza che i dati siano distorti dal processo per i clienti 'Individuali' molto più semplice. Perché è importante Consente la segmentazione del processo per diverse categorie di clienti, che spesso hanno flussi di processo e complessità molto diverse, portando a un'analisi più accurata. Dove trovare Questo è un attributo fondamentale memorizzato a livello di caso o cliente all'interno di ACTICO. Esempi IndividualeAziendalePiccola Impresa | |||
Attività di Onboarding Clienti KYC
| Activity | Descrizione | ||
|---|---|---|---|
| Documenti Cliente Caricati | Questa attività si verifica quando il cliente fornisce l'identificazione richiesta e i documenti di supporto tramite un portale o altro canale integrato con ACTICO. Ogni upload di documento viene solitamente acquisito come evento distinto ed esplicito nella gestione dei documenti del sistema o nel log del caso. | ||
| Perché è importante Questo segna una milestone chiave dipendente dal cliente. Tracciare questo evento è cruciale per misurare i tempi di risposta del cliente e analizzare la durata della successiva fase di revisione dei documenti. Dove trovare Cercare i log degli eventi relativi alla gestione dei documenti o agli allegati al caso di richiesta. Questi sono spesso registrati in tabelle dedicate alla gestione di documenti o evidenze all'interno del database ACTICO. Acquisisci Evento registrato dal sistema quando un documento viene allegato al caso. Tipo di evento explicit | |||
| Domanda Inviata | Questa attività segna l'inizio del processo di onboarding KYC quando una nuova domanda cliente viene formalmente ricevuta dal sistema ACTICO. È acquisita come evento esplicito, tipicamente registrato con un timestamp preciso al momento della creazione di un nuovo caso o record di applicazione. | ||
| Perché è importante Essendo l'evento di inizio primario, questa attività è essenziale per calcolare il tempo di ciclo complessivo dell'onboarding e monitorare il volume delle richieste. Serve come "timestamp" di riferimento per tutte le successive misurazioni delle prestazioni del processo. Dove trovare Questa è tipicamente una voce esplicita in un log di creazione di domande o casi all'interno di ACTICO. Cercare tabelle relative agli eventi di presentazione delle domande o al timestamp di creazione del record del caso primario. Acquisisci Evento registrato alla creazione di una nuova istanza di caso di richiesta. Tipo di evento explicit | |||
| Onboarding Cliente Completato | Questa è l'attività finale del processo, che significa che il cliente è completamente onboardato e il caso di domanda è chiuso. Questo è inferito da uno stato finale e terminale come 'Onboarded' o 'Chiuso - Approvato' applicato al caso. | ||
| Perché è importante Essendo l'evento di fine primario di successo, questa attività è essenziale per calcolare il tempo di ciclo end-to-end per tutti i clienti onboarded con successo. Fornisce il "timestamp" finale per l'analisi del percorso felice. Dove trovare Deducibile dal campo dello stato finale del caso di richiesta cliente. Cercare un "timestamp" associato al passaggio del caso a uno stato di successo terminale. Acquisisci Deducibile da un aggiornamento finale dello stato del caso a 'Completato' o 'Chiuso'. Tipo di evento inferred | |||
| Revisione Conformità Avviata | Segna l'inizio della fase di revisione manuale da parte del dipartimento di conformità, spesso per richieste ad alto rischio o contrassegnate. Questo è tipicamente deducibile da un cambiamento nello stato del caso a 'In Attesa di Revisione Conformità' o dall'assegnazione del caso alla coda di lavoro di un funzionario di conformità. | ||
| Perché è importante Questa attività è il punto di partenza per misurare il collo di bottiglia della conformità. Il tempo trascorso fino a 'Revisione Conformità Completata' è un KPI critico per identificare i ritardi in questa fase cruciale. Dove trovare Deducibile dalla cronologia dello stato della richiesta o dal log di audit. Cercare un "timestamp" associato a un cambiamento di stato a 'In Revisione Conformità' o all'assegnazione a un gruppo di utenti correlato alla conformità. Acquisisci Deducibile dal cambiamento di stato del caso a 'In Attesa di Conformità' o dall'assegnazione al team di conformità. Tipo di evento inferred | |||
| Revisione Conformità Completata | Segna la fine della revisione manuale da parte del dipartimento di conformità, con una decisione di approvare, rifiutare o richiedere ulteriori azioni. Questa attività è deducibile da un cambiamento dello stato del caso da 'In Attesa di Revisione Conformità' a uno stato successivo come 'Conformità Approvata'. | ||
| Perché è importante Questo è l'evento di chiusura per la fase di revisione della conformità. È essenziale per calcolare la durata totale della revisione della conformità e analizzare il throughput del team. Dove trovare Deducibile dal log storico dello stato della richiesta. Cercare il "timestamp" quando il caso esce da uno stato 'In Revisione Conformità', indicando che è stata presa una decisione. Acquisisci Deducibile dal cambiamento di stato del caso da 'In Attesa di Conformità' a 'Conformità Approvata' o simile. Tipo di evento inferred | |||
| Richiesta Approvata | Questa attività rappresenta la decisione aziendale finale di approvare la domanda del cliente per l'onboarding. È una milestone chiave, tipicamente acquisita come modifica di stato distinta e finale nel ciclo di vita dell'applicazione. | ||
| Perché è importante Questa milestone è un precursore della creazione dell'account e significa un risultato di successo. Analizzare il tempo per raggiungere questo punto è cruciale per comprendere la durata del 'percorso felice'. Dove trovare Deducibile dal campo dello stato finale nella tabella principale dell'applicazione o del caso. Cercare uno stato come 'Approvato', 'Approvazione Completata' o uno stato positivo terminale simile. Acquisisci Lo stato finale del caso è aggiornato a 'Approvato' nei dati anagrafici del caso. Tipo di evento inferred | |||
| Richiesta Rifiutata | Rappresenta la decisione finale di rifiutare la domanda del cliente, terminando il processo di onboarding. Questo è uno stato finale critico, catturato tramite una modifica dello stato finale sul record dell'applicazione. | ||
| Perché è importante Questo è l'evento finale di fallimento primario. L'analisi dei casi che terminano con questa attività è cruciale per comprendere i tassi di rifiuto, le ragioni del fallimento e migliorare il rendimento complessivo del processo. Dove trovare Deducibile dal campo dello stato finale nella tabella principale dell'applicazione o del caso. Cercare uno stato terminale come 'Rifiutato', 'Respinto' o 'Chiuso - Rifiutato'. Acquisisci Lo stato finale del caso è aggiornato a 'Rifiutato' nei dati anagrafici del caso. Tipo di evento inferred | |||
| Valutazione del Rischio Eseguita | Questa attività rappresenta l'esecuzione del motore decisionale di ACTICO per calcolare un punteggio o una valutazione di rischio per la domanda del cliente. Essendo una funzione centrale del sistema, questa viene acquisita come evento esplicito quando il set di regole di valutazione del rischio viene eseguito. | ||
| Perché è importante La valutazione del rischio è un punto decisionale cruciale che spesso detta il percorso di processo successivo. L'analisi di questa attività aiuta a capire come i livelli di rischio influenzano le varianti e le tempistiche del processo. Dove trovare Questo è un evento centrale all'interno di ACTICO e dovrebbe essere registrato nei log di decisione o esecuzione. Questi log tipicamente contengono l'ID del caso, le regole eseguite e il punteggio di rischio risultante. Acquisisci Evento registrato dal motore decisionale ACTICO al completamento della valutazione del rischio. Tipo di evento explicit | |||
| Account Creato | Dopo l'approvazione, questa attività segna la creazione tecnica dell'account del cliente nel sistema bancario centrale o di gestione utenti. Questo è spesso un evento esplicito registrato da ACTICO dopo aver ricevuto una conferma di successo dal sistema a valle. | ||
| Perché è importante Questa attività conferma che il processo ha portato a un risultato aziendale tangibile. Il tempo da 'Domanda Approvata' a 'Account Creato' può rivelare ritardi di integrazione o inefficienze nei passaggi finali di provisioning. Dove trovare Questa informazione si troverebbe probabilmente nei log di integrazione o di interfaccia di sistema all'interno di ACTICO, che registrano l'esito delle chiamate a sistemi esterni per il provisioning degli account. Acquisisci Evento registrato al ricevimento di una risposta API di successo dal sistema di conto principale. Tipo di evento explicit | |||
| Controlli Background Avviati | Questo rappresenta il punto in cui vengono avviati i controlli in background automatizzati o manuali, come screening AML o della storia creditizia. Questo viene spesso registrato come evento esplicito quando il sistema attiva questi controlli, che possono coinvolgere fornitori di servizi esterni. | ||
| Perché è importante L'avvio dei controlli background è una tappa significativa nel processo di "due diligence". Monitorare questo aiuta a comprendere le dipendenze e i tempi di consegna associati ai fornitori di dati esterni. Dove trovare Cercare registrazioni nei log di sistema o in una traccia di audit che indichino l'attivazione delle procedure di screening background. Questi sono spesso collegati all'ID del caso di richiesta principale. Acquisisci Evento registrato quando il motore del "workflow" avvia chiamate ai servizi di controllo background. Tipo di evento explicit | |||
| Informazioni aggiuntive richieste | Rappresenta un evento in cui un revisore, spesso in ambito di conformità o sottoscrizione, richiede maggiori informazioni o documentazione al cliente. Questa azione viene solitamente acquisita esplicitamente in quanto spesso implica l'invio di una notifica al cliente e la sospensione del caso. | ||
| Perché è importante Questa attività è un fattore primario di rilavorazione e aumento dei tempi di ciclo. Monitorarne la frequenza e l'impatto è essenziale per identificare le aree in cui la raccolta iniziale dei dati può essere migliorata. Dove trovare Questo è probabilmente un evento esplicito registrato nella cronologia del caso o nel log delle comunicazioni. Cercare eventi come 'RFI Inviata' (Richiesta di Informazioni) o una modifica di stato specifica come 'In Attesa di Informazioni Cliente'. Acquisisci Un evento esplicito attivato dall'utente, come 'Invia RFI', viene registrato nel log di audit del caso. Tipo di evento explicit | |||
| Revisione Documenti Completata | Questa attività significa che un agente ha terminato la revisione dei documenti presentati dal cliente. Viene tipicamente inferita da una modifica dello stato sul documento o sul caso complessivo, come 'Documenti Verificati' o 'Revisione Completata'. | ||
| Perché è importante Questa è una milestone chiave per misurare l'efficienza del processo di gestione dei documenti. Il tempo tra 'Documenti Cliente Caricati' e questa attività è un KPI critico per identificare i ritardi di elaborazione manuale. Dove trovare Deducibile dai log storici dello stato per il caso di richiesta o per i singoli documenti. Un cambiamento nello stato di un documento da 'In Attesa di Revisione' ad 'Approvato' o 'Riveduto' indica questa attività. Acquisisci Deducibile da un cambiamento nello stato del documento a 'Verificato' o 'Riveduto'. Tipo di evento inferred | |||
| Revisione Iniziale Richiesta | Rappresenta la prima revisione della domanda presentata, sia da una regola automatizzata che da un agente umano, per verificare la completezza e l'idoneità di base. Questa attività è spesso inferita da una modifica dello stato dell'applicazione, ad esempio da 'Inviata' a 'In Revisione'. | ||
| Perché è importante Analizzare il tempo necessario per completare questa prima revisione aiuta a identificare i ritardi iniziali di elaborazione. Fornisce anche intuizioni su quante richieste superano questo primo controllo senza problemi. Dove trovare Deducibile dalle tabelle di cronologia dello stato o dai log di audit associati al caso di richiesta cliente. Confrontare il "timestamp" quando lo stato cambia da uno stato 'nuovo' o 'inviato' a uno stato di 'revisione'. Acquisisci Rileva il cambiamento di stato da 'Inviato' a 'In Revisione' nel log storico del caso. Tipo di evento inferred | |||
| Verifica Identità Eseguita | Rappresenta un controllo automatizzato o manuale per convalidare l'identità del cliente rispetto a fonti di dati esterne o interne. Questo viene spesso registrato come evento esplicito quando viene effettuata una chiamata API a un servizio di verifica di terze parti e viene ricevuta una risposta. | ||
| Perché è importante Questa attività è un passaggio di conformità critico. L'analisi della sua durata e dei suoi risultati aiuta a identificare le dipendenze da servizi esterni e potenziali colli di bottiglia nel processo di verifica. Dove trovare Questa informazione si trova tipicamente nei log di integrazione o in tabelle di eventi specifiche che registrano i risultati dei controlli automatizzati e delle chiamate a servizi di terze parti collegati al caso della domanda. Acquisisci Evento registrato da una chiamata di integrazione a un servizio di verifica dell'identità di terze parti. Tipo di evento explicit | |||
Guide all'Estrazione
Fasi
- Ottenere Accesso Amministrativo: Accedere alla piattaforma ACTICO, come il Visual Modeler o una console di amministrazione dedicata, utilizzando credenziali con permessi sufficienti per accedere e configurare le esportazioni di dati.
- Individuare il Modulo di Esportazione: Navigare all'area di amministrazione o configurazione del sistema. Trovare la sezione responsabile dei registri di audit, del logging o delle esportazioni di dati. Questa potrebbe essere etichettata come 'Audit Export' o 'Business Object Export'.
- Creare una Nuova Configurazione di Esportazione: Avviare il processo per creare una nuova definizione di esportazione. Fornire un nome descrittivo per la configurazione, ad esempio, 'KYC_Onboarding_ProcessMind_Export'.
- Definire la Fonte di Dati: Specificare l'oggetto di business primario da esportare, che è il
CustomerApplication. È fondamentale applicare un filtro per intervallo di date per limitare la portata dell'esportazione, ad esempio, gli ultimi 6 mesi, per garantire dimensioni dei file gestibili e prestazioni. - Configurare il File di Output: Impostare il formato di output su CSV. Definire il nome del file, ad esempio,
kyc_event_log.csv, e confermare il delimitatore, tipicamente una virgola. Assicurarsi che i campi di testo siano correttamente quotati per gestire caratteri speciali. - Mappare l'Identificatore del Caso: Designare l'identificatore univoco per l'oggetto di business
CustomerApplicationcome ID del caso per l'analisi di Process Mining. Questo collega tutti gli eventi correlati a un singolo caso di onboarding. - Definire le Mappature degli Attributi: Per ogni colonna richiesta nel log degli eventi, mapparla all'attributo corrispondente nel modello di oggetto di business di ACTICO. Questo include l'ID del caso, il nome dell'attività, i "timestamp" e altri attributi raccomandati come lo stato o il livello di rischio.
- Configurare le Mappature degli Eventi: Questo è il passaggio più critico. Creare una regola o una mappatura specifica per ciascuna delle 14 attività di business. Utilizzare trigger di sistema come la creazione dell'oggetto per 'Richiesta Inviata', i cambiamenti di stato per i passaggi del "workflow" come 'Richiesta Approvata', e specifici schemi di messaggi di log di audit per eventi tecnici come 'Verifica Identità Eseguita'.
- Salvare e Convalidare la Configurazione: Dopo aver definito tutte le mappature, salvare il file di configurazione. Utilizzare qualsiasi strumento di convalida disponibile all'interno di ACTICO per verificare errori di sintassi o percorsi di attributi errati.
- Eseguire e Monitorare l'Esportazione: Eseguire il lavoro di esportazione. Monitorarne il progresso tramite lo scheduler dei lavori del sistema o l'interfaccia di monitoraggio. Verificare i log per eventuali errori al completamento.
- Recuperare e Preparare il File: Scaricare il file CSV risultante dal percorso di output designato sul server. Prima di caricarlo su ProcessMind, aprire il file per verificarne la struttura e assicurarsi che i formati di "timestamp" e data siano coerenti e correttamente analizzati.
Configurazione
- Livello Log di Audit: Il livello di logging di audit a livello di sistema deve essere impostato su un'impostazione dettagliata, come INFO o FINE. Un livello meno dettagliato, come WARNING o ERROR, non acquisirà i necessari cambiamenti di stato e le esecuzioni di regole richieste per il Process Mining.
- Fonte Dati Esportazione: La fonte di dati primaria dovrebbe essere configurata per utilizzare l'oggetto di business
CustomerApplication. Potrebbe essere necessario unire o fare riferimento a oggetti correlati, comeCustomerDocument, per acquisire tutti gli eventi pertinenti. - Filtro Intervallo Date: Utilizzare sempre un filtro per l'intervallo di date per controllare la quantità di dati estratti. Per l'analisi iniziale, si raccomanda un periodo da 3 a 6 mesi. In produzione, questo può essere regolato in base alle esigenze aziendali e alle prestazioni del sistema.
- Logica di Mappatura Eventi: L'accuratezza dell'estrazione dipende fortemente da come vengono mappati gli eventi. I cambiamenti di stato (
on="StatusChange") sono comuni per inferire i passaggi di business. Le voci di log esplicite (on="LogEntry") sono utili per eventi tecnici o chiamate di servizio. Le esecuzioni di regole (on="RuleExecution") sono ideali per catturare i passaggi decisionali. - Formato di Output: Selezionare CSV come formato di output per un'ampia compatibilità. Assicurarsi che la configurazione per delimitatori e virgolette di testo sia impostata correttamente per prevenire problemi di parsing dei dati.
- Prerequisiti: Questo metodo richiede autorizzazioni amministrative per la piattaforma ACTICO. Una comprensione approfondita del modello di oggetto di business KYC, inclusi tutti i campi di stato e i nomi degli attributi pertinenti, è essenziale per una configurazione accurata.
a Query di Esempio config
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration>