Il template dei dati per la gestione delle richieste di risarcimento
Il template dei dati per la gestione delle richieste di risarcimento
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione dei dati da Duck Creek Claims
Attributi per la gestione delle richieste di risarcimento
| Nome | Descrizione | ||
|---|---|---|---|
| ID del sinistro ClaimId | Identificativo univoco di un singolo sinistro assicurativo, utilizzato come identificativo principale del caso. | ||
| Descrizione L’ID del sinistro è la chiave fondamentale che collega tutti gli eventi e le attività relativi a un singolo sinistro assicurativo, dalla denuncia alla chiusura. Consente di seguire in modo coerente l’intero ciclo di gestione del sinistro. Nell’analisi di Process Mining, questo attributo è essenziale per creare la vista del caso e permette agli analisti di ricostruire l’intero percorso di ogni sinistro, misurare i tempi di ciclo dall’inizio alla conclusione e analizzare le varianti del processo. Perché è importante È l’ID caso fondamentale che collega tutti gli eventi correlati del processo e consente di visualizzare l’intero ciclo di gestione del sinistro, dall’inizio alla conclusione. Dove reperirli È una chiave primaria nell’entità o nella tabella principale dei sinistri in Duck Creek Claims. Per individuare il nome specifico della tabella e del campo, consultare la documentazione del sistema. Esempi CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Nome dell’attività ActivityName | Nome dell’attività aziendale o dell’evento verificatosi in un determinato momento per un sinistro. | ||
| Descrizione Questo attributo descrive una specifica fase o attività svolta nell’ambito della gestione del sinistro, ad esempio «Sinistro denunciato», «Liquidatore assegnato» o «Pagamento emesso». Ogni attività rappresenta un momento distinto del ciclo di gestione del sinistro. L’analisi della sequenza e della frequenza di queste attività è alla base del Process Mining. Consente di individuare i modelli di processo, i colli di bottiglia e i cicli di rilavorazione, nonché di rilevare gli scostamenti del processo rispetto a un modello standard. Perché è importante Il nome dell’attività definisce le fasi del flusso del processo ed è fondamentale per individuare, analizzare e monitorare la gestione dei sinistri. Dove reperirli In genere si ricava dai registri degli eventi, dai nomi delle transazioni o dai record delle modifiche di stato in Duck Creek Claims. Potrebbe essere necessario associare più campi o tabelle di origine. Esempi Sinistro denunciatoLiquidatore assegnatoAccertamento avviatoPagamento emessoSinistro chiuso | |||
| Ora dell’evento EventTime | Data e ora che indicano quando si è verificata una specifica attività o un evento. | ||
| Descrizione L’ora dell’evento indica la data e l’ora esatte di ogni attività registrata nel ciclo di gestione del sinistro. Queste informazioni temporali sono fondamentali per l’analisi delle prestazioni. Nell’analisi, questo dato viene utilizzato per calcolare i tempi di ciclo tra le attività, individuare i tempi di attesa, misurare la durata complessiva del caso e analizzare le prestazioni del processo in periodi diversi. È alla base di qualsiasi indicatore temporale del processo. Perché è importante Questa data e ora sono fondamentali per calcolare tutti gli indicatori temporali, come i tempi di ciclo e le durate, e consentono di analizzare le prestazioni e individuare i colli di bottiglia. Dove reperirli È un campo standard di data e ora associato ai registri degli eventi o delle transazioni in Duck Creek Claims. Cercare campi come «CreateDate», «Timestamp» o «EventDate». Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Gravità del sinistro ClaimSeverity | Classificazione della complessità finanziaria o operativa del sinistro, ad esempio bassa, media o alta. | ||
| Descrizione La gravità del sinistro indica l’impatto o la complessità previsti. Può basarsi sulla stima iniziale del danno, sulla natura dell’incidente o su altre regole aziendali predefinite. Questo attributo è fondamentale per l’analisi delle prestazioni, poiché i sinistri gravi richiedono in genere più passaggi, tempi di gestione più lunghi e risorse specializzate. Segmentare gli indicatori in base alla gravità aiuta a definire obiettivi realistici e a capire come la complessità incide sull’efficienza e sui risultati del processo. Perché è importante Consente di segmentare i sinistri in base alla complessità, per un’analisi più approfondita delle prestazioni e un confronto realistico dei tempi di ciclo e dei costi. Dove reperirli Consultare la documentazione di Duck Creek Claims. Potrebbe trattarsi di un campo dedicato oppure di un valore ricavato dall’importo iniziale della riserva per il sinistro. Esempi BassaMedioAltoCatastrofico | |||
| Importo del danno LossAmount | L’importo finanziario stimato o effettivo del danno segnalato nella richiesta di risarcimento. | ||
| Descrizione Questo attributo indica il valore inizialmente stimato del danno associato alla richiesta di risarcimento. È un indicatore finanziario importante, che spesso influisce sull’instradamento e sulla gravità della richiesta, nonché sul livello di indagine necessario. Nell’analisi, l’importo del danno serve a segmentare le richieste e a capire come l’impatto finanziario si correla al comportamento del processo. Per esempio, le richieste di importo più elevato possono seguire percorsi diversi o avere tempi di ciclo più lunghi. Fornisce un contesto finanziario essenziale per interpretare i dati operativi del processo. Perché è importante Fornisce il contesto finanziario della richiesta e consente di analizzare come il suo valore influisca sul percorso di elaborazione, sulla durata e sull’esito. Dove reperirli Consulti la documentazione di Duck Creek Claims. È un campo finanziario essenziale della richiesta, spesso denominato «Danno segnalato» o «Riserva iniziale». Esempi 1500.0025000.50125000.00 | |||
| Liquidatore assegnato AssignedAdjuster | Nome o ID del liquidatore responsabile della gestione del sinistro durante una determinata attività. | ||
| Descrizione Questo attributo identifica l’utente o la risorsa che svolge un’attività. Può cambiare nel corso del ciclo di gestione del sinistro, quando il caso passa da un liquidatore o team a un altro. È essenziale per analizzare le prestazioni delle risorse, la distribuzione del carico di lavoro e i passaggi di consegne. Le Dashboard dedicate al numero di pratiche gestite dai liquidatori, alle variazioni del carico di lavoro e all’individuazione dei colli di bottiglia si basano spesso su questo attributo per capire come il lavoro viene assegnato e svolto. Perché è importante Consente di analizzare le prestazioni delle risorse, l’equilibrio dei carichi di lavoro e le modalità di collaborazione, aiutando a individuare i colli di bottiglia e le esigenze di formazione. Dove reperirli Consultare la documentazione di Duck Creek Claims. Cercare i campi relativi all’utente, al responsabile o all’assegnatario nelle tabelle delle attività, degli eventi o dell’entità principale del sinistro. Esempi John SmithJane DoeRobert Brownadjuster_1138 | |||
| Reparto Department | Reparto o team responsabile dell’attività o del sinistro in un determinato momento. | ||
| Descrizione Questo attributo specifica il gruppo funzionale o il reparto che gestisce il sinistro, ad esempio «Raccolta iniziale», «Unità accertamenti» o «Team liquidazioni». Fornisce un contesto organizzativo al flusso del processo. L’analisi per reparto è fondamentale per comprendere le prestazioni del processo nel suo complesso. Aiuta a individuare i colli di bottiglia tra reparti, misurare l’efficienza dei team e capire come il lavoro si sposta all’interno dell’organizzazione. Perché è importante Consente di analizzare le prestazioni per area funzionale e mette in evidenza i passaggi di consegne tra reparti e i colli di bottiglia specifici dei team. Dove reperirli Consultare la documentazione di Duck Creek Claims. Queste informazioni sono spesso associate al profilo dell’utente assegnato o all’assegnazione a una coda o a un gruppo di lavoro. Esempi Sinistri autoSinistri immobiliari - danni ingentiUnità investigazioni specialiElaborazione dei pagamenti | |||
| Stato della richiesta di risarcimento ClaimStatus | Lo stato complessivo della richiesta di risarcimento in un determinato momento, ad esempio aperta, in sospeso o chiusa. | ||
| Descrizione Lo stato della richiesta di risarcimento indica la fase corrente del suo ciclo di vita e offre una sintesi generale della posizione della pratica nel processo. Questo attributo è utile per creare viste di sintesi dell’inventario delle richieste e per filtrare le pratiche. È particolarmente importante per individuare l’esito finale di una richiesta, ad esempio «Chiusa - Pagata» o «Chiusa - Respinta», informazione essenziale per l’analisi degli esiti e per comprendere i tassi di rifiuto. Perché è importante Fornisce un quadro dello stato attuale e dell’esito finale della richiesta di risarcimento, fondamentale per l’analisi degli esiti e il filtraggio delle pratiche. Dove reperirli Consulti la documentazione di Duck Creek Claims. È un campo fondamentale nel record principale della richiesta di risarcimento. Esempi ApertaIn sospeso - In attesa di informazioniChiusa - LiquidataChiusa - Respinta | |||
| Tipo di sinistro ClaimType | Categoria del sinistro assicurativo, ad esempio auto, proprietà o responsabilità civile. | ||
| Descrizione Il tipo di sinistro classifica i sinistri in base al ramo assicurativo o alla natura del danno. È una dimensione fondamentale per segmentare e analizzare i dati dei sinistri. Questo attributo consente di confrontare le prestazioni del processo tra diverse tipologie di sinistro. Ad esempio, un sinistro «Auto - perdita totale» segue un processo molto diverso da un sinistro «Proprietà - danni da acqua» e presenta indicatori differenti. L’analisi per tipo di sinistro fornisce il contesto necessario per confronti più significativi e iniziative di miglioramento mirate. Perché è importante È una dimensione fondamentale per segmentare l’analisi, poiché i diversi tipi di sinistro presentano spesso processi, livelli di servizio e gradi di complessità distinti. Dove reperirli Consultare la documentazione di Duck Creek Claims. È un attributo fondamentale del record principale del sinistro. Esempi Auto privata - collisioneProprietà commerciale - incendioIndennizzo per infortuni sul lavoroResponsabilità civile generale | |||
| Data obiettivo di risoluzione ResolutionTargetDate | La data entro cui si prevede di risolvere la richiesta di risarcimento, in base agli SLA o agli obiettivi interni. | ||
| Descrizione Questo attributo registra la scadenza per la chiusura della richiesta di risarcimento. La data è spesso stabilita da requisiti normativi, accordi sui livelli di servizio (SLA) o indicatori chiave di prestazione interni (KPI) e può variare in base al tipo o alla gravità della richiesta. È il riferimento per calcolare il KPI «Tasso di risoluzione delle richieste entro i termini» e alimentare la Dashboard «Rispetto degli obiettivi di risoluzione delle richieste». Consente di monitorare in anticipo le richieste a rischio di superare i termini previsti dagli SLA e aiuta a stabilire le priorità di lavoro. Perché è importante Consente di misurare i risultati rispetto agli accordi sui livelli di servizio (SLA) e agli obiettivi interni, con un impatto diretto sulla soddisfazione dei clienti e sulla conformità. Dove reperirli Consulti la documentazione di Duck Creek Claims. Potrebbe trattarsi di un campo specifico per la data SLA oppure di una data calcolata a partire dalla data di invio della richiesta e dalle regole aziendali. Esempi 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| È automatizzata IsAutomated | Indicatore booleano che specifica se l’attività è stata eseguita automaticamente dal sistema, senza intervento umano. | ||
| Descrizione Questo indicatore distingue le attività completate dagli utenti da quelle eseguite automaticamente dal sistema, come l’invio di notifiche, la convalida iniziale dei dati o le fasi di elaborazione senza intervento manuale. L’analisi di questo attributo è fondamentale per comprendere il livello di automazione del processo di gestione delle richieste. Aiuta a misurare l’impatto delle iniziative di automazione, individua ulteriori opportunità e permette di verificare che le fasi automatizzate funzionino come previsto, senza creare problemi nelle fasi successive. Perché è importante Aiuta a misurare l’impatto dell’automazione su efficienza e costi e individua opportunità per elaborare le richieste senza intervento manuale. Dove reperirli Queste informazioni potrebbero essere dedotte dall’utente associato a un evento, ad esempio «SYSTEM» o «BATCH», oppure da un indicatore specifico nel record dell’evento. Esempi truefalse | |||
| È una rilavorazione IsRework | Indicatore calcolato che specifica se un’attività fa parte di un ciclo di rilavorazione. | ||
| Descrizione Questo attributo booleano viene impostato su true se un’attività viene ripetuta per una richiesta di risarcimento dopo che si sono già svolte altre attività. Per esempio, quando il processo torna da «Danno valutato» a «Indagine avviata». Questo attributo è essenziale per quantificare e analizzare le rilavorazioni. Supporta il KPI «Tasso di rilavorazione delle richieste» e la Dashboard «Schemi di rilavorazione e rielaborazione delle richieste», consentendo di filtrare e mettere in evidenza le attività e le pratiche interessate. Aiuta così a individuare inefficienze e problemi di qualità nel processo. Perché è importante Quantifica le rilavorazioni a livello di attività e ne facilita la misurazione, la visualizzazione e l’analisi delle cause e degli effetti delle inefficienze di processo. Dove reperirli Non è un campo del sistema di origine. Viene calcolato durante la preparazione dei dati con algoritmi che rilevano sequenze di attività ripetute all’interno di una pratica. Esempi truefalse | |||
| Importo della liquidazione SettlementAmount | L’importo finale concordato per liquidare la richiesta di risarcimento. | ||
| Descrizione Questo attributo registra l’importo della liquidazione calcolato e autorizzato per il pagamento. È un indicatore fondamentale dell’esito per ogni richiesta che comporta un pagamento. È essenziale per l’analisi finanziaria e per Dashboard come «Tempi di autorizzazione ed emissione dei pagamenti». Può essere confrontato con l’«Importo del danno» iniziale per valutare l’accuratezza delle riserve ed è indispensabile per comprendere gli esiti finanziari del processo di gestione delle richieste. Perché è importante Rappresenta il principale esito finanziario di una richiesta di risarcimento ed è essenziale per la rendicontazione finanziaria e per analizzare l’accuratezza delle stime iniziali del danno. Dove reperirli Consulti la documentazione di Duck Creek Claims. Queste informazioni sono in genere registrate nelle tabelle delle transazioni finanziarie o dei pagamenti associate alla richiesta. Esempi 1450.7522000.00115800.20 | |||
| Motivo del rifiuto RejectionReason | Il motivo specifico per cui una richiesta di risarcimento è stata respinta o rifiutata. | ||
| Descrizione Quando viene presa la decisione di respingere una richiesta di risarcimento, questo attributo ne indica il motivo. In genere, il valore viene selezionato da un elenco predefinito di codici o descrizioni. L’analisi dei motivi di rifiuto è fondamentale per la Dashboard «Analisi delle decisioni e dei rifiuti delle richieste di risarcimento». Aiuta a individuare problemi ricorrenti nelle richieste, possibili schemi di frode o casi in cui il testo della polizza potrebbe risultare poco chiaro. Queste informazioni possono orientare il miglioramento del processo di acquisizione o delle regole di sottoscrizione. Perché è importante Spiega perché le richieste vengono respinte e offre indicazioni utili per migliorare il processo di acquisizione, ridurre le richieste non valide e individuare le esigenze di formazione. Dove reperirli Consulti la documentazione di Duck Creek Claims. In genere, questo campo viene compilato quando lo stato della richiesta passa a «Respinta» o a uno stato equivalente. Esempi Evento non copertoPolizza scadutaRichiesta duplicataFrode sospetta | |||
| Numero di polizza PolicyNumber | L’identificativo univoco della polizza assicurativa in base alla quale è stata presentata la richiesta di risarcimento. | ||
| Descrizione Questo attributo collega la richiesta di risarcimento alla polizza assicurativa di origine. Fornisce informazioni sulla copertura, sulle condizioni e sul cliente associati alla richiesta. Anche se non viene sempre utilizzato direttamente nell’analisi dei flussi di processo, il numero di polizza è prezioso per arricchire i dati delle richieste. Consente di collegarli ai dati delle polizze e dei clienti e di analizzare come i risultati del processo variano in base al segmento di clientela, al tipo di polizza o alla sua anzianità, offrendo una visione aziendale più completa. Perché è importante Collega la richiesta di risarcimento al cliente e alla polizza, consentendo un’analisi più ampia dell’impatto dei risultati del processo sui diversi segmenti di clientela e tipi di polizza. Dove reperirli Consulti la documentazione di Duck Creek Claims. È un campo di riferimento standard nell’entità principale della richiesta. Esempi PA-987654321CP-123456789WC-555444333 | |||
| Ora di fine EndTime | L’indicazione temporale che specifica quando è stata completata un’attività. | ||
| Descrizione Questo attributo indica l’ora di completamento di un’attività. Se StartTime indica quando è iniziata, EndTime fornisce l’altro dato necessario per calcolare la durata della singola attività. Nel Process Mining, disporre sia dell’ora di inizio sia di quella di fine delle attività consente un’analisi molto più approfondita dei risultati. Permette di calcolare con precisione il «Tempo di elaborazione», cioè il tempo di lavoro effettivo su un’attività, distinguendolo dal «Tempo di attesa», ossia il tempo trascorso tra un’attività e l’altra. Questa distinzione è fondamentale per individuare con precisione i colli di bottiglia. Perché è importante Consente di calcolare con precisione i tempi di elaborazione delle attività e di distinguere il lavoro effettivo dai tempi di inattività o attesa, un aspetto essenziale per individuare correttamente i colli di bottiglia. Dove reperirli Potrebbe essere disponibile come campo temporale separato nei log degli eventi oppure si può ricavare dall’ora di inizio (StartTime) dell’attività successiva nella sequenza della stessa pratica. Esempi 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Risolta nei termini IsOnTimeResolution | Indicatore calcolato che specifica se la richiesta di risarcimento è stata chiusa entro la data obiettivo di risoluzione. | ||
| Descrizione Questo attributo booleano si ricava confrontando l’indicazione temporale dell’attività «Richiesta chiusa» con la «ResolutionTargetDate» della pratica. Indica se la richiesta è stata risolta nei termini (true) o in ritardo (false). Questo attributo alimenta direttamente il KPI «Tasso di risoluzione delle richieste entro i termini». Consente di aggregare e visualizzare facilmente il rispetto degli SLA nelle Dashboard e di analizzare i dati a un livello più dettagliato per individuare le caratteristiche ricorrenti delle richieste in ritardo, ad esempio determinati tipi di richiesta, reparti o percorsi di processo. Perché è importante Misura direttamente il rispetto degli SLA per ogni richiesta e consente di filtrare i dati e analizzare le cause profonde dei ritardi. Dove reperirli Non è un campo del sistema di origine. Viene calcolato durante la preparazione dei dati confrontando l’indicazione temporale dell’attività finale con il campo «ResolutionTargetDate». Esempi truefalse | |||
| Sistema di origine SourceSystem | Sistema da cui sono stati estratti i dati degli eventi. | ||
| Descrizione Questo attributo identifica l’applicazione di origine dei dati del sinistro. In questo contesto, il valore sarà sempre «Duck Creek Claims». Anche se può sembrare ridondante quando tutti i dati provengono da un unico sistema, è fondamentale per la governance dei dati, la tracciabilità e gli eventuali scenari futuri in cui i dati potrebbero essere uniti a quelli di altri sistemi. Fornisce informazioni sull’origine e sulla struttura dei dati. Perché è importante Fornisce informazioni essenziali sulla provenienza e sul contesto dei dati, fondamentali per la governance e la risoluzione dei problemi, soprattutto negli ambienti con più sistemi integrati. Dove reperirli In genere è un valore statico aggiunto durante l’estrazione e la trasformazione dei dati per indicarne l’origine. Esempi Duck Creek Claims | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Data e ora dell’ultimo aggiornamento dei dati dal sistema di origine. | ||
| Descrizione Questo attributo indica quando il set di dati è stato aggiornato l’ultima volta e fornisce un riferimento per valutarne l’aggiornamento. Nelle Dashboard e nelle analisi, informa gli utenti sulla data a cui risalgono le informazioni. Aiuta inoltre a capire se la vista del processo include le transazioni più recenti. Perché è importante Informa gli utenti sull’aggiornamento dei dati, un aspetto fondamentale per interpretare l’analisi e prendere decisioni tempestive. Dove reperirli Questa data e ora vengono generate durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) e sono in genere memorizzate nei metadati del set di dati. Esempi 2024-05-21T02:00:00Z | |||
Attività di gestione delle richieste di risarcimento
| Attività | Descrizione | ||
|---|---|---|---|
| Decisione sul sinistro presa | Questa attività rappresenta la decisione ufficiale sul sinistro, ad esempio «Approvato», «Approvato parzialmente» o «Respinto». È una tappa decisiva, dedotta dal passaggio a uno stato che indica la decisione finale. | ||
| Perché è importante È una tappa fondamentale del processo decisionale. Il tempo necessario per arrivarci e l’esito della decisione sono elementi centrali per analizzare il processo e la sua efficienza. Dove reperirli Si deduce dalla modifica di un campo dedicato, come «Decisione sul sinistro» o «Stato del sinistro», che passa a uno stato finale quale «Approvato» o «Respinto». Viene registrata la data e l’ora della modifica. Acquisizione Si deduce dall’aggiornamento dello stato principale o del campo decisionale del sinistro. Tipo di evento inferred | |||
| Pagamento autorizzato | Rappresenta l’approvazione formale del pagamento dell’importo calcolato per la liquidazione. Spesso è un passaggio distinto, che coinvolge un responsabile o un’autorità separata, e viene registrato come transazione di approvazione esplicita. | ||
| Perché è importante È un punto di controllo fondamentale e un possibile collo di bottiglia prima del pagamento. L’indicatore «Tempo medio di approvazione dei sinistri» misura il tempo che intercorre tra «Decisione sul sinistro presa» e questa fase. Dove reperirli Di solito è un evento esplicito in un flusso di lavoro o in un modulo finanziario, in cui un utente con autorizzazioni specifiche approva il pagamento. È registrato nel registro delle approvazioni. Acquisizione Evento di approvazione esplicita registrato in un flusso di lavoro o in un registro delle transazioni. Tipo di evento explicit | |||
| Pagamento emesso | Questa attività segna l’esecuzione della transazione finanziaria per pagare il sinistro. È un evento esplicito e ben definito, generato quando il pagamento viene inviato tramite assegno, trasferimento elettronico di fondi o un altro metodo. | ||
| Perché è importante Segna l’adempimento dell’obbligo finanziario relativo a un sinistro approvato. Il tempo tra «Pagamento autorizzato» e «Pagamento emesso» indica l’efficienza dell’ufficio finanziario. Dove reperirli Si rileva dalla tabella delle transazioni finanziarie di Duck Creek Claims, che registra tutti i pagamenti in uscita con un codice di transazione specifico e la relativa data e ora. Acquisizione La transazione viene registrata nel registro finanziario quando il pagamento è elaborato. Tipo di evento explicit | |||
| Sinistro chiuso | È l’attività finale e segna la chiusura amministrativa della pratica dopo l’emissione del pagamento o la liquidazione del sinistro. Viene registrata con l’aggiornamento finale dello stato a «Chiuso». | ||
| Perché è importante Questa attività segna la conclusione positiva del processo. È il punto finale per calcolare il «Tempo medio di ciclo del sinistro dall’inizio alla conclusione» e altri indicatori di durata fondamentali. Dove reperirli Si deduce dalla data e ora della modifica finale dello stato a «Chiuso» o «Liquidato» nella tabella principale dei dati del sinistro. Acquisizione Si deduce dal fatto che lo stato finale del sinistro è impostato su «Chiuso». Tipo di evento inferred | |||
| Sinistro denunciato | È il primo evento e corrisponde alla ricezione da parte dell’assicuratore della prima denuncia di sinistro (First Notice of Loss, FNOL). In genere viene registrato come transazione esplicita quando un agente o un contraente inserisce nel sistema le informazioni iniziali sul sinistro. | ||
| Perché è importante Questa attività segna l’inizio dell’intero ciclo di gestione del sinistro. Analizzare il tempo che intercorre tra questo evento e quelli successivi è fondamentale per comprendere la durata complessiva della gestione e l’efficienza della raccolta iniziale. Dove reperirli Di solito è un evento esplicito registrato in una tabella dei sinistri o del registro FNOL, quando viene creato per la prima volta un nuovo record di sinistro in Duck Creek Claims. Acquisizione Evento registrato al momento della creazione iniziale di un nuovo record di sinistro. Tipo di evento explicit | |||
| Sinistro respinto | Questa attività rappresenta un esito alternativo del processo: il sinistro viene respinto ufficialmente. L’evento viene registrato quando lo stato finale del sinistro è impostato su «Respinto» o «Rifiutato». | ||
| Perché è importante È un esito importante, da analizzare separatamente. Capire perché e quando i sinistri vengono respinti aiuta a migliorare la raccolta iniziale e a gestire la conformità. Dove reperirli Si deduce dalla data e ora della modifica dello stato finale del sinistro a «Respinto», «Rifiutato» o «Chiuso senza pagamento» nella tabella delle entità dei sinistri. Acquisizione Si deduce dal fatto che lo stato finale del sinistro indica un rifiuto. Tipo di evento inferred | |||
| Accertamento avviato | Questa attività segna l’inizio della fase formale di accertamento del sinistro. Spesso si deduce dal passaggio dello stato del sinistro a «In fase di accertamento» o a uno stato analogo. | ||
| Perché è importante Segna l’inizio di una fase che richiede molte risorse. Misurare la durata dell’accertamento è fondamentale per l’indicatore «Durata media dell’accertamento» e aiuta a gestire una fase critica del processo. Dove reperirli Si deduce dalla data e ora dell’aggiornamento dello stato del sinistro a «Accertamento in corso» o «In attesa di ispezione» nel campo principale dello stato del sinistro. Acquisizione Si ricava da una modifica dello stato del sinistro che indica l’inizio delle attività di accertamento. Tipo di evento inferred | |||
| Accertamento completato | Indica la conclusione delle attività di accertamento, una volta raccolti tutti gli elementi necessari. In genere si deduce dal passaggio dello stato del sinistro da «In fase di accertamento» a uno stato decisionale, come «In attesa di decisione». | ||
| Perché è importante Il completamento dell’accertamento è una tappa fondamentale, perché consente di avviare le fasi decisionali e di liquidazione. Eventuali ritardi in questa fase hanno ripercussioni significative sulle fasi successive. Dove reperirli Si deduce dalla data e ora dell’aggiornamento dello stato del sinistro da uno stato di «accertamento» a uno di «revisione» o «decisione». Acquisizione Si ricava da una modifica dello stato del sinistro che indica la conclusione delle attività di accertamento. Tipo di evento inferred | |||
| Danno valutato | Questa tappa segna il momento in cui le riserve finanziarie vengono definite o aggiornate sulla base dei risultati dell’accertamento. Indica la stima dell’impatto economico del sinistro e viene registrata quando gli importi delle riserve sono inseriti o modificati. | ||
| Perché è importante È un punto di controllo finanziario fondamentale del processo. Analizzare quando si verifica permette di valutare la rapidità e l’accuratezza della stima economica. Dove reperirli Spesso è una transazione finanziaria esplicita, registrata nel registro delle transazioni finanziarie del sinistro o nella tabella della cronologia delle riserve di Duck Creek Claims. Acquisizione Transazione finanziaria registrata per definire o aggiornare le riserve del sinistro. Tipo di evento explicit | |||
| Importo della liquidazione calcolato | Dopo l’approvazione, questa attività rappresenta il calcolo dell’importo definitivo della liquidazione o del pagamento. Può essere un passaggio esplicito oppure si può dedurre dalla definizione degli importi finali nel modulo finanziario del sistema. | ||
| Perché è importante Questa attività è fondamentale per misurare l’indicatore «Tasso di rilavorazione della liquidazione». Se l’evento si verifica più volte per lo stesso sinistro, può indicare inefficienze, errori o trattative durante la fase di liquidazione. Dove reperirli Può trattarsi di una registrazione esplicita nel registro delle transazioni oppure si può dedurre dagli aggiornamenti del campo «Importo della liquidazione» nei dati finanziari del sinistro. I registri di controllo di questo campo sono la fonte principale. Acquisizione Evento registrato quando l’importo definitivo del pagamento viene calcolato e salvato. Tipo di evento explicit | |||
| Informazioni aggiuntive ricevute | Segna la ricezione delle informazioni richieste, che consente di proseguire la gestione del sinistro. Il liquidatore può registrare l’evento manualmente oppure il sistema può farlo in automatico se le informazioni vengono inviate tramite un portale digitale. | ||
| Perché è importante Il tempo tra «Informazioni richieste» e «Informazioni ricevute» è un periodo di attesa importante. Analizzarne la durata aiuta a individuare le dipendenze esterne e i colli di bottiglia nelle comunicazioni. Dove reperirli Può essere un evento esplicito proveniente dall’integrazione con un sistema di gestione documentale oppure una registrazione manuale o una modifica di stato inserita dal liquidatore alla ricezione dei documenti. Acquisizione Evento registrato al caricamento di un documento o all’inserimento manuale da parte di un liquidatore. Tipo di evento explicit | |||
| Liquidatore assegnato | Questo evento registra l’assegnazione di un liquidatore o responsabile al sinistro registrato. Il sistema memorizza l’assegnazione, segnando un chiaro passaggio di consegne e definendo chi è responsabile della gestione del sinistro. | ||
| Perché è importante È fondamentale per analizzare l’allocazione delle risorse e il carico di lavoro dei liquidatori, nonché per individuare ritardi nell’assegnazione dei sinistri. È un passaggio di consegne importante, che può introdurre tempi di attesa. Dove reperirli Si rileva tramite l’aggiornamento del campo «Liquidatore assegnato» nella tabella principale dei dati dei sinistri. La data e l’ora sono disponibili nella cronologia o nel registro di controllo del campo. Acquisizione Registrato nel registro di controllo quando il campo del liquidatore viene compilato o modificato. Tipo di evento explicit | |||
| Prima revisione completata | Indica il completamento della prima revisione approfondita del sinistro da parte del liquidatore assegnato. In genere si deduce dal cambiamento dello stato del sinistro dopo l’assegnazione, ad esempio da «Assegnato» a «In revisione» o «In fase di accertamento». | ||
| Perché è importante Questa tappa consente di misurare il tempo necessario al liquidatore per intervenire per la prima volta e può segnalare eventuali arretrati nel suo carico di lavoro. È il primo importante punto di controllo affidato a una persona. Dove reperirli Si deduce da una modifica del campo relativo allo stato del sinistro, ad esempio il passaggio a «Prima revisione completata» o «In attesa di informazioni». Si utilizza la data e l’ora della modifica. Acquisizione Si deduce dalla modifica dello stato del sinistro successiva all’assegnazione del liquidatore. Tipo di evento inferred | |||
| Richiesta di informazioni aggiuntive | Questa attività si verifica quando il liquidatore stabilisce che servono altre informazioni e invia una richiesta al contraente o a una terza parte. Spesso è un evento esplicito collegato al modulo di comunicazione o corrispondenza del sistema. | ||
| Perché è importante Una frequenza elevata di questa attività può indicare problemi nella raccolta iniziale dei dati. Inoltre, introduce tempi di attesa significativi, incidendo sul tempo di ciclo complessivo. Dove reperirli Si rileva dai registri delle comunicazioni in uscita, ad esempio lettere ed e-mail, oppure da una specifica transazione «Richiesta di informazioni» in Duck Creek Claims. Acquisizione Registrato quando viene generata una comunicazione o un’attività per richiedere informazioni. Tipo di evento explicit | |||
| Sinistro registrato | Segna l’accettazione e la registrazione formale del sinistro presentato, con l’assegnazione ufficiale di un ID sinistro univoco. Spesso si tratta di un evento automatico del sistema, successivo alla convalida iniziale dei dati. | ||
| Perché è importante Formalizza l’avvio del sinistro e attiva le fasi successive, come l’assegnazione a un liquidatore. Il tempo tra la denuncia e la registrazione può segnalare problemi nella qualità iniziale dei dati o nel carico del sistema. Dove reperirli Si deduce dall’ora e dalla data di generazione dell’ID sinistro principale e dal passaggio dello stato del sinistro da «in attesa» o «presentato» a «aperto» o «registrato» nella tabella principale delle entità dei sinistri. Acquisizione Si ricava dalla data e ora di creazione del record principale del sinistro o dal passaggio dello stato a «Aperto». Tipo di evento inferred | |||
Guide all’estrazione dei dati
Passaggi
- Acceda all’utilità di configurazione di Duck Creek Data Hub: acceda all’ambiente Duck Creek e apra l’applicazione Data Hub. Per creare o modificare le configurazioni di esportazione dei dati, sono necessarie le autorizzazioni appropriate.
- Crei un nuovo processo di esportazione dei dati: nell’utilità Data Hub, avvii la procedura per creare un nuovo processo di esportazione. Assegni un nome descrittivo, ad esempio ProcessMind_Claims_Event_Log_Export.
- Definisca l’origine dei dati: configuri il processo per connettersi al database SQL principale di Data Hub. Dovrà specificare il nome del server, il nome del database e le credenziali di un utente con accesso in lettura agli schemi pertinenti.
- Inserisca la query di estrazione: apra la sezione di definizione della query nel processo di esportazione. Copi lo script completo dalla sezione della query riportata di seguito e lo incolli nell’editor.
- Imposti i parametri della query: individui la sezione dei parametri nella configurazione. Definisca e imposti i valori dei parametri @StartDate e @EndDate richiamati nella query, così da specificare l’intervallo di date da estrarre. Ad esempio, '2023-01-01' e '2023-12-31'.
- Mappi le colonne di output: configuri le impostazioni del file di output. Verifichi che le colonne definite nell’istruzione SELECT (ClaimId, ActivityName, EventTime e così via) siano associate correttamente alle colonne del file. Le intestazioni del file di output devono corrispondere esattamente a questi nomi.
- Configuri il file di output: specifichi CSV come formato di output. Imposti la virgola (,) come delimitatore e la codifica dei caratteri su UTF-8, per garantire la compatibilità con ProcessMind.
- Definisca la destinazione: specifichi il percorso del file o la posizione di rete in cui salvare il file CSV generato. Verifichi che il sistema disponga delle autorizzazioni di scrittura necessarie.
- Pianifichi il processo di esportazione: configuri la pianificazione del processo. Per l’analisi iniziale, può eseguirlo manualmente. Per il monitoraggio continuativo, imposti una pianificazione ricorrente, ad esempio giornaliera o settimanale.
- Esegua il processo e recuperi il file: avvii il processo per generare l’event log. Al termine, recuperi il file CSV dalla destinazione specificata al passaggio 8.
- Prepari il file per il caricamento: prima di caricarlo in ProcessMind, apra il file CSV ed esegua un controllo finale. Verifichi che le intestazioni siano corrette, che il formato della data sia uniforme (YYYY-MM-DD HH:MI:SS) e che i dati siano visualizzati come previsto.
Configurazione
- Prerequisiti: è necessario poter accedere al modulo Duck Creek Data Hub. L’utente o l’account di servizio che esegue il processo di esportazione deve disporre delle autorizzazioni di lettura sulle tabelle del database sottostante a Data Hub, ad esempio [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory].
- Configurazione dell’intervallo di date: la query utilizza i parametri @StartDate e @EndDate. È fondamentale impostarli per definire l’intervallo di estrazione. Per la prima analisi, si consiglia un periodo di 6-12 mesi, così da includere un numero sufficiente di casi completati e in corso.
- Filtri: nella Common Table Expression (CTE), la query include il segnaposto /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */. Rimuova i commenti e modifichi questa riga per filtrare specifiche linee di business, ad esempio 'Personal Auto' o 'Commercial Property', riducendo così il volume dei dati e concentrando l’analisi.
- Ciclo di aggiornamento di Data Hub: tenga conto della latenza dei dati in Data Hub. I dati non sono aggiornati in tempo reale e vengono in genere aggiornati secondo una pianificazione, ad esempio ogni notte. I dati estratti saranno aggiornati fino all’ultimo aggiornamento completato correttamente in Data Hub.
- Formato di output: il processo di esportazione deve generare un file semplice, preferibilmente CSV. Imposti le virgolette doppie (") come qualificatore di testo per gestire eventuali virgole nei campi.
Query di esempio sql
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL; È pronto a iniziare?
Con questo template ha tutto ciò che serve per iniziare a ottimizzare la gestione delle richieste di risarcimento. Avvii oggi il percorso di analisi dei dati e faccia emergere informazioni preziose.
Azzerare gli arretrati nella gestione dei sinistri: ottimizzi subito il processo
Raggiunga il 70% di gestione automatizzata senza interventi manuali, riducendo costi e ritardi.
Prova gratuita di 14 giorni, senza carta di credito.