Template di dati: Gestione dei sinistri

L'ID Sinistro è l'identificativo chiave del case che collega tutte le attività, gli eventi e i data point per un singolo sinistro assicurativo, dalla presentazione alla chiusura.

Nel process mining, questo attributo è cruciale per ricostruire il percorso end-to-end di ogni sinistro. Permette di aggregare tutti gli eventi correlati in un unico case coeso, consentendo l'analisi dei cycle time, delle varianti di processo e dei colli di bottiglia per i singoli sinistri.

Questa è la chiave essenziale per tracciare il ciclo di vita di un sinistro. Senza un Claim ID univoco, è impossibile collegare i vari passaggi del processo in un percorso coerente per l'analisi.

Questo è tipicamente il 'CaseNumber' sull'oggetto Case o un campo ID univoco personalizzato sull'oggetto 'Claim' (FinancialServicesCloud.Claim).

Questo attributo descrive un singolo step o milestone nel processo di gestione dei sinistri, come 'Sinistro Presentato', 'Revisione Iniziale Eseguita' o 'Pagamento Effettuato'. Costituisce la spina dorsale della process map.

L'analisi della sequenza e della frequenza delle attività aiuta a identificare i percorsi di processo più comuni (varianti), a scoprire deviazioni dal processo standard e a individuare le attività che vengono ripetute frequentemente, indicando rework.

Definisce il 'cosa' nel processo, consentendo la visualizzazione del flusso di processo e l'identificazione di colli di bottiglia, loop di rilavorazione e variazioni di processo.

Derivato dai cambiamenti al campo 'Stato' sull'oggetto Sinistro/Caso, o dal 'Soggetto' di record di Task o Event correlati.

L'Ora dell'Evento fornisce la data e l'ora precise per ogni attività nel ciclo di vita del sinistro. Questi dati temporali sono essenziali per ordinare gli eventi cronologicamente e calcolare le durate.

Nell'analisi, i timestamp sono utilizzati per calcolare tutte le metriche legate al tempo, inclusi i tempi di ciclo tra le attività, i tempi di attesa e la durata totale del caso. Sono fondamentali per creare un'animazione dinamica del processo e per identificare quando e dove si verificano i ritardi.

Questo attributo fornisce la tempistica di ogni event, rendendo possibile calcolare le durate, analizzare le performance del processo nel tempo e identificare i colli di bottiglia temporali.

Per i cambiamenti di stato, si tratta del 'CreatedDate' dalla cronologia dei campi dell'oggetto (es. CaseHistory). Per le attività, è il 'CompletedDateTime' o il 'CreatedDate'.

Questo attributo specifica l'applicazione o la piattaforma sorgente da cui i dati sono stati estratti. Per questo processo, sarà costantemente 'Salesforce Financial Services Cloud'.

Sebbene possa sembrare costante, tracciare esplicitamente il sistema sorgente è una best practice, specialmente in ambienti dove i dati potrebbero essere integrati da più sistemi. Assicura chiarezza sulla provenienza dei dati ed è utile per la data governance e la validazione.

Conferma la provenienza dei dati, cruciale per la data governance, il troubleshooting e l'integrazione di dati da più sistemi aziendali.

Questo è tipicamente un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per etichettare l'origine del dataset.

Questo attributo indica la data e l'ora dell'ultima estrazione dei dati da Salesforce Financial Services Cloud. Fornisce il contesto per l'attualità dei dati analizzati.

È importante per gli utenti delle dashboard comprendere quanto sia aggiornata l'analisi. Aiuta a gestire le aspettative sulla tempestività dei dati ed è cruciale per validare che le data pipeline funzionino come previsto.

Fornisce un contesto cruciale sull'attualità dei dati, assicurando che analisti e utenti aziendali siano consapevoli di quanto sia aggiornata la vista del processo.

Questo valore viene generato e 'timbrato' sul dataset dallo strumento di estrazione dati o dal processo ETL al momento dell'esecuzione.

Questo attributo indica come un sinistro è stato inizialmente segnalato, ad esempio, tramite web portal, mobile app, telefonata o email. Il canale di presentazione può influire significativamente sulla qualità delle informazioni iniziali e sui successivi step di elaborazione.

L'analisi dei sinistri per canale di presentazione aiuta a comprendere i modelli di domanda e l'efficienza dei diversi metodi di acquisizione. Il dashboard 'Claims Throughput & Volume' utilizza questo attributo per tracciare quanti sinistri provengono da ciascun canale nel tempo, il che può informare le decisioni di allocazione delle risorse e di investimento tecnologico.

Aiuta a valutare l'efficienza dei diversi canali di acquisizione e a capire se alcuni canali portano a maggiori rilavorazioni o a tempi di ciclo più lunghi.

Questo è tipicamente un campo picklist personalizzato sull'oggetto Claim/Case, spesso etichettato come 'Origine' o 'Canale'.

Questo attributo specifica l'unità di business o il dipartimento assegnato al sinistro, come 'Rami Persona', 'Auto Commerciale' o 'Unità Investigazioni Speciali'.

Analizzare il processo per dipartimento aiuta a identificare le differenze di performance tra i team, a comprendere come sono distribuiti i carichi di lavoro e a individuare deviazioni di processo o colli di bottiglia specifici per dipartimento. Questa dimensione è preziosa in dashboard come 'Claim SLA Compliance Overview' per vedere come si stanno comportando le diverse parti dell'organizzazione.

Consente di confrontare le prestazioni tra diverse unità di business, aiutando a identificare le best practice e ad allocare le risorse in modo più efficace.

Questo potrebbe essere un campo personalizzato sull'oggetto Claim/Case o inferito dal profilo o dal ruolo dell'utente assegnato nell'oggetto User.

Questo attributo rappresenta l'ammontare totale del risarcimento o dei danni richiesti dal cliente all'inizio del processo. Questo valore spesso influenza la complessità del sinistro, il livello di controllo richiesto e il percorso di elaborazione che segue.

L'analisi delle metriche di processo basate sul valore del sinistro può rivelare modelli importanti. Ad esempio, i sinistri di valore più elevato potrebbero avere tempi di ciclo più lunghi, comportare più passaggi o essere indirizzati a team specializzati. Questo aiuta a impostare SLA realistici e nella previsione delle riserve finanziarie.

Fornisce il contesto finanziario per ogni caso, permettendo di analizzare come il valore del sinistro influenzi la complessità del processo, la durata e i risultati.

Questo sarebbe un campo valuta personalizzato sull'oggetto 'Sinistro' in Financial Services Cloud, ad esempio 'ClaimedAmount__c'.

Questo attributo identifica il singolo perito di sinistri responsabile di un'attività o del case nel suo complesso. È tipicamente derivato dal proprietario del claim case o dalla persona che ha completato un Task specifico.

L'analisi delle performance per perito è cruciale per la gestione operativa. Dashboards come 'Adjuster Workload & Performance' utilizzano questo attributo per tracciare il volume dei sinistri, i case attivi e i cycle time per persona, supportando una distribuzione bilanciata del carico di lavoro e identificando opportunità di coaching.

Questo attributo è essenziale per analizzare le performance di team e individuali, gestire i carichi di lavoro e identificare best practice o esigenze formative.

Questo è il campo 'OwnerId' sull'oggetto Case o Claim, che si collega all'oggetto User per ottenere il nome del perito.

L'attributo End Time registra il momento esatto in cui un'attività si conclude. Mentre lo Start Time (EventTime) segna l'inizio, l'End Time fornisce l'altro limite necessario per misurare quanto tempo ha impiegato un'attività per essere completata.

Nell'analisi, disporre sia di uno Start Time che di un End Time consente il calcolo preciso dei tempi di elaborazione delle attività, distinguendoli dai tempi di attesa tra un'attività e l'altra. Questo è fondamentale per la creazione di dashboard come 'Process Step Duration Breakdown' e per individuare le inefficienze all'interno di specifici Task, non solo tra di essi.

Permette il calcolo preciso del tempo di elaborazione attivo per ciascuna attività, fondamentale per distinguere il tempo a valore aggiunto dal tempo di attesa.

Derivato dai dati di timestamp. Ad esempio, se 'Revisione Iniziale Eseguita' è innescata da un cambio di stato, l'EndTime potrebbe essere il timestamp del successivo cambio di stato.

Lo Stato del Sinistro fornisce un'istantanea della fase in cui si trova il sinistro nel suo ciclo di vita, ad esempio 'Nuovo', 'In indagine', 'In attesa cliente' o 'Chiuso'. È un attributo chiave per comprendere lo stato attuale del processo.

Questo attributo è ampiamente utilizzato in dashboard operative come l''Open Claims Ageing Report' per visualizzare il carico di lavoro attuale e identificare i sinistri che rimangono bloccati in un determinato stato per troppo tempo. L'analisi delle transizioni tra gli stati è anche un metodo primario per definire le attività nella mappa di processo.

Fornisce visibilità in tempo reale sullo stato attuale dei sinistri attivi, aiutando a gestire gli arretrati e a identificare i casi bloccati.

Questo è il campo 'Status' standard sull'oggetto Case o Claim.

Il Tipo di Sinistro è una dimensione critica per segmentare e analizzare il processo di gestione dei sinistri. Diversi tipi di sinistri spesso seguono processi distinti, presentano complessità diverse e sono soggetti a SLA differenti.

Filtrando o confrontando le performance in base al Tipo di Sinistro, gli analisti possono scoprire colli di bottiglia specifici per tipo, valutare la conformità con gli SLA mirati e comprendere come le variazioni di processo differiscono tra le categorie. È utilizzato in dashboard come 'Claim SLA Compliance Overview' e 'Claim Rejection Reason Analysis' per fornire intuizioni più mirate.

Consente la segmentazione dei sinistri per confrontare i processi, identificare problemi specifici per tipo e personalizzare le iniziative di miglioramento.

Questo è spesso un campo 'Type' standard o un campo picklist personalizzato sull'oggetto Case o Claim.

La Data del Danno registra quando si è verificato l'evento coperto dalla polizza assicurativa. Questa è distinta dalla data di presentazione del sinistro.

Questo attributo è importante per la compliance e per analizzare il tempo di latenza tra l'incidente e la sua segnalazione. Grandi intervalli possono talvolta indicare potenziali problemi o richiedere procedure di gestione diverse. Fornisce un contesto prezioso per comprendere la cronologia completa degli eventi.

Aiuta ad analizzare il ritardo tra un incidente e la sua segnalazione, che può influenzare l'indagine e la liquidazione.

Questo sarebbe un campo data personalizzato sull'oggetto 'Sinistro', ad esempio 'DateOfLoss__c'.

La Data Obiettivo SLA è una data calcolata o impostata manualmente che rappresenta la scadenza per la risoluzione del sinistro. È il benchmark rispetto al quale viene misurata la tempestività.

Questo attributo è essenziale per monitorare le performance rispetto agli impegni presi con i clienti o i regolatori. È la base per il KPI 'SLA Adherence Rate' e il dashboard 'Claim SLA Compliance Overview', permettendo all'organizzazione di tracciare quale percentuale di sinistri viene risolta in tempo e di identificare quali tipi di sinistri o dipartimenti stanno faticando a raggiungere i loro obiettivi.

Definisce l'obiettivo di performance per il tempo di risoluzione dei sinistri, consentendo la misurazione diretta della conformità agli SLA.

Questo è tipicamente un campo formula personalizzato o un campo data sull'oggetto Claim/Case, calcolato in base alla data di presentazione e al tipo di sinistro.

Questa metrica misura la durata complessiva di una pratica di sinistro, dalla sua presentazione iniziale alla chiusura definitiva. Viene calcolata come la differenza tra il timestamp dell'ultimo evento e quello del primissimo evento associato a un determinato ID Sinistro.

È uno dei KPI più importanti per la performance di processo, trattato direttamente dal KPI 'Tempo Medio di Ciclo del Sinistro' e dalla dashboard 'Tempo di Ciclo End-to-End del Sinistro'. Ridurre questo valore è spesso un obiettivo primario nei progetti di ottimizzazione dei processi.

Misura l'efficienza complessiva end-to-end del processo ed è un indicatore chiave dell'esperienza del cliente.

Campo calcolato: Timestamp dell'ultimo evento meno il timestamp del primo evento per ogni 'ClaimId'. Questo è calcolato dallo strumento di Process Mining.

Questa metrica calcola la durata di un singolo passaggio del processo, rappresentando il tempo 'attivo' trascorso lavorandoci. È tipicamente calcolata come la differenza tra l'End Time e lo Start Time di un'attività.

Questa è una metrica fondamentale per l'analisi dei colli di bottiglia. La dashboard 'Process Step Duration Breakdown' si basa su questo calcolo per mostrare quali attività specifiche consumano più tempo, aiutando a concentrare gli sforzi di miglioramento dove avranno il maggiore impatto.

Quantifica il tempo di lavoro effettivo per ogni fase, aiutando a distinguere i colli di bottiglia di elaborazione attiva dai tempi di attesa inattivi.

Campo calcolato: 'EndTime' meno 'EventTime' (StartTime). Questo calcolo viene eseguito all'interno dello strumento di Process Mining o durante la trasformazione dei dati.

Questo flag distingue tra attività completate da periti umani e quelle eseguite da workflow, regole o integrazioni di sistema automatizzati. Ad esempio, una registrazione iniziale del sinistro potrebbe essere completamente automatizzata.

Analizzare l'automazione è fondamentale per comprendere l'efficienza del processo. Aiuta a misurare il successo delle iniziative di automazione, identifica quali passaggi sono buoni candidati per future automazioni e confronta la velocità e la coerenza delle attività automatizzate rispetto a quelle manuali.

Distingue tra attività umane e attività guidate dal sistema, il che è fondamentale per valutare l'impatto e l'efficacia dell'automazione.

Questo è tipicamente derivato. Se l'utente associato a un event è un utente generico di 'Sistema' o 'Integrazione', questo flag è impostato su true.

Questo flag è impostato su true quando un sinistro torna a una fase precedente del processo. Un esempio classico è il passaggio da 'Indagine Completata' a 'Richiesta di Informazioni Aggiuntive'. La logica per identificare il rework è definita in base alla conoscenza del processo.

Questo attributo è fondamentale per la dashboard 'Claims Rework Loop Analysis' e per il KPI 'Rework Rate'. Consente la quantificazione diretta della frequenza e dell'impatto del rework, che è un fattore primario di inefficienza, aumento dei costi e tempi di ciclo più lunghi.

Contrassegna direttamente i loop di processo inefficienti, consentendo una facile quantificazione del rework e un'analisi mirata delle sue cause profonde.

Campo calcolato. Questo è derivato dall'analisi della sequenza di attività per ogni caso. Ad esempio, se 'Attività A' è seguita da 'Attività B' e poi di nuovo da 'Attività A', la seconda istanza di 'A' è un rework.

L'ID Cliente collega il sinistro alla persona o all'organizzazione che lo ha presentato. In Salesforce, si tratta tipicamente di un lookup all'oggetto Account o Contact.

Questo attributo consente una visione del processo di gestione dei sinistri incentrata sul cliente. Può essere utilizzato per analizzare la storia dei sinistri per cliente, identificare i richiedenti abituali e personalizzare il servizio. È inoltre cruciale per collegare i dati dei sinistri con altri dati del cliente da un CRM per una visione aziendale olistica.

Permette un'analisi orientata al cliente, aiutando a comprendere le dinamiche dei sinistri per i singoli clienti e a misurare l'impatto del processo di gestione dei sinistri sulle relazioni con i clienti.

Questo è un campo di ricerca sull'oggetto Claim/Case che punta all'oggetto Account o Contact (ad esempio, 'AccountId' o 'ContactId').

Questo attributo registra l'importo effettivamente pagato al richiedente quando il sinistro viene chiuso e liquidato. Questo importo può differire da quello inizialmente richiesto a causa di valutazioni, franchigie e limiti di polizza.

L'analisi dell'importo liquidato, specialmente in relazione all'importo inizialmente richiesto, fornisce insight sull'accuratezza della valutazione del danno e sugli esiti delle negoziazioni di liquidazione. È una metrica finanziaria critica per comprendere il costo totale dei sinistri.

Rappresenta l'impatto finanziario ultimo di un sinistro, cruciale per l'analisi finanziaria, la costituzione di riserve e la valutazione dell'accuratezza delle stime iniziali delle perdite.

Questo sarebbe un campo valuta personalizzato sull'oggetto 'Sinistro' o su un oggetto 'Pagamento' correlato in Financial Services Cloud.

Questo attributo fornisce il contesto geografico per il sinistro, come lo stato in cui si è verificato il danno o il paese del contraente. Questi dati possono essere derivati dall'indirizzo del contraente o dai dettagli del danno.

L'analisi geografica può rivelare trend regionali nelle tipologie di sinistro, nelle frequenze e nei tempi di elaborazione. Può anche essere utilizzata per valutare le performance tra i diversi uffici regionali e per garantire la conformità con le normative specifiche per località.

Consente l'analisi geografica dei sinistri, evidenziando differenze di prestazione regionali, schemi di frode o impatti di eventi locali.

Tipicamente derivato dai campi indirizzo (es. 'BillingState', 'BillingCountry') sull'oggetto 'Account' o 'Contact' associato.

Quando la decisione finale su un sinistro è 'Rejected', questo attributo fornisce il motivo sottostante, come 'Not Covered by Policy', 'Fraud Suspected' o 'Incomplete Information'.

Questo è l'attributo chiave per la dashboard 'Claim Rejection Reason Analysis'. Analizzando la frequenza dei diversi motivi di rifiuto, spesso segmentati per tipo di sinistro o dipartimento, l'organizzazione può identificare opportunità per migliorare la sottoscrizione, chiarire il linguaggio delle polizze o potenziare il processo di raccolta delle informazioni per ridurre le presentazioni non valide.

Fornisce una visione diretta sul motivo del rifiuto dei sinistri, essenziale per migliorare le politiche di sottoscrizione e ridurre l'elaborazione inutile di richieste non valide.

Questo è tipicamente un campo picklist personalizzato sull'oggetto Claim/Case che diventa obbligatorio quando lo stato viene spostato su 'Rifiutato' o 'Chiuso - Negato'.

Il Numero di Polizza collega il sinistro alla polizza assicurativa attiva del cliente. Questo fornisce un contesto essenziale su copertura, limiti e storico dell'assicurato.

Sebbene non sia sempre un fattore primario del flow di processo, è un dato contestuale chiave. Può essere utilizzato per unire i dati dei sinistri con i dati delle polizze per un'analisi più approfondita, ad esempio per capire se specifici tipi di polizza sono associati a sinistri più frequenti o complessi.

Collega il sinistro alla polizza assicurativa sottostante, consentendo un'analisi più ampia degli schemi di sinistri correlati a specifiche polizze o tipi di copertura.

Questo sarebbe un campo di ricerca (lookup field) sull'oggetto 'Sinistro' che fa riferimento all'oggetto 'InsurancePolicy' in Financial Services Cloud.

Questo attributo è un esito categoriale, tipicamente con valori come 'Rispettato' o 'Violato'. È derivato confrontando la data di completamento effettiva del sinistro (il timestamp dell'attività finale) con la sua 'SlaTargetDate'.

Questa è la metrica principale per il KPI 'SLA Adherence Rate' e per la dashboard 'Claim SLA Compliance Overview'. Fornisce una misura chiara e inequivocabile delle performance rispetto agli obiettivi ed è essenziale per la reportistica di conformità e la gestione operativa.

Fornisce un chiaro indicatore delle prestazioni rispetto agli obiettivi di tempestività, fondamentale per la soddisfazione del cliente e la conformità normativa.

Campo calcolato: Se 'EndTime' dell'evento finale è minore o uguale a 'SlaTargetDate', allora 'Met', altrimenti 'Breached'. Questa logica viene applicata durante la trasformazione dei dati o all'interno dello strumento di Process Mining.