Il Suo Template dei dati per la gestione dei sinistri
Il Suo Template dei dati per la gestione dei sinistri
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l'estrazione da Duck Creek Claims
Attributi della gestione dei sinistri
| Nome | Descrizione | ||
|---|---|---|---|
| ID sinistro ClaimId | L'identificativo univoco di un singolo sinistro assicurativo, utilizzato come identificativo principale del caso. | ||
| Descrizione Il Claim ID è la chiave fondamentale che collega tutti gli eventi e le attività associati a un singolo sinistro assicurativo, dall'invio alla chiusura. Garantisce che l'intero ciclo di vita del sinistro possa essere monitorato in modo coerente. Nell'analisi di Process Mining, questo Attributo è essenziale per costruire la vista del caso, consentendo agli analisti di seguire il percorso completo di ogni sinistro, misurare i tempi di ciclo end-to-end e analizzare le varianti di processo. Perché è importante È il Case ID essenziale che collega tutti gli eventi correlati nel processo, consentendo una visione completa, end-to-end, del ciclo di vita del sinistro. Dove reperirlo È una chiave primaria nell'entità o nella tabella principale dei sinistri all'interno di Duck Creek Claims. Consulti la documentazione del sistema per conoscere il nome specifico della tabella e del campo. Esempi CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Nome dell'attività ActivityName | Il nome dell'attività aziendale o dell'evento che si è verificato in un determinato momento per un sinistro. | ||
| Descrizione Questo Attributo descrive uno specifico passaggio o Task eseguito nel processo di gestione dei sinistri, come 'Claim Submitted', 'Adjuster Assigned' o 'Payment Issued'. Ogni attività rappresenta un punto distinto nel ciclo di vita del sinistro. L'analisi della sequenza e della frequenza di queste attività costituisce il nucleo del Process Mining. Consente di individuare i modelli di processo, identificare i colli di bottiglia, rilevare i cicli di rilavorazione e analizzare le deviazioni del processo rispetto a un modello standard. Perché è importante Il Nome dell'attività definisce i passaggi del flusso di processo, elemento fondamentale per individuare, analizzare e monitorare il processo di gestione dei sinistri. Dove reperirlo In genere deriva dagli Event Log, dai nomi delle transazioni o dai record delle modifiche di stato all'interno di Duck Creek Claims. Potrebbe essere necessario effettuare una mappatura a partire da più campi o tabelle di origine. Esempi Sinistro inviatoPerito assegnatoIndagine avviataPagamento emessoSinistro chiuso | |||
| Ora dell'evento EventTime | Il timestamp che indica quando si è verificata una specifica attività o un determinato evento. | ||
| Descrizione L'Ora dell'evento fornisce la data e l'ora precise di ogni attività registrata nel ciclo di vita del sinistro. Queste informazioni temporali sono fondamentali per l'analisi delle prestazioni. Nell'analisi, questo timestamp 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. Costituisce la base di qualsiasi metrica di processo basata sul tempo. Perché è importante Questo timestamp è fondamentale per calcolare tutte le metriche basate sul tempo, come tempi di ciclo e durate, consentendo l'analisi delle prestazioni e l'identificazione dei colli di bottiglia. Dove reperirlo È un campo timestamp standard associato ai log degli eventi o delle transazioni in Duck Creek Claims. Cerchi campi come 'CreateDate', 'Timestamp' o 'EventDate'. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Gravità del sinistro ClaimSeverity | Una classificazione della complessità finanziaria o operativa del sinistro, ad esempio Bassa, Media o Alta. | ||
| Descrizione La Gravità del sinistro fornisce un'indicazione dell'impatto o della complessità previsti per un sinistro. Può basarsi sulla stima iniziale del danno, sulla natura dell'incidente o su altre regole aziendali predefinite. Questo Attributo è essenziale per l'analisi delle prestazioni, poiché i sinistri ad alta gravità richiedono generalmente più passaggi, tempi di elaborazione più lunghi e risorse specializzate. Segmentare i KPI per gravità aiuta a definire obiettivi realistici e a comprendere in che modo la complessità incida sull'efficienza e sugli esiti del processo. Perché è importante Aiuta a segmentare i sinistri in base alla complessità, consentendo un'analisi più approfondita delle prestazioni e un benchmarking realistico dei tempi di ciclo e dei costi. Dove reperirlo Consulti la documentazione di Duck Creek Claims. Potrebbe trattarsi di un campo dedicato oppure di un valore derivato dall'importo della riserva iniziale del danno. Esempi BassaMediaAltaCatastrofica | |||
| Importo del danno LossAmount | L'importo finanziario stimato o effettivo del danno segnalato nel sinistro. | ||
| Descrizione Questo Attributo rappresenta il valore stimato iniziale del danno associato al sinistro. È una metrica finanziaria fondamentale, che spesso influenza l'instradamento, la gravità e il livello di indagine richiesto per il sinistro. Nell'analisi, l'importo del danno viene utilizzato per segmentare i sinistri e comprendere la correlazione tra impatto finanziario e comportamento del processo. Ad esempio, i sinistri di valore più elevato possono seguire percorsi diversi o presentare tempi di ciclo più lunghi. Fornisce un contesto finanziario essenziale ai dati operativi del processo. Perché è importante Fornisce il contesto finanziario del sinistro, consentendo di analizzare in che modo il suo valore incida sul percorso di elaborazione, sulla durata e sull'esito. Dove reperirlo Consulti la documentazione di Duck Creek Claims. È un campo finanziario fondamentale del sinistro, spesso denominato 'Reported Loss' o 'Initial Reserve'. Esempi 1500.0025000.50125000.00 | |||
| Perito assegnato AssignedAdjuster | Il nome o l'ID del perito responsabile della gestione del sinistro durante una determinata attività. | ||
| Descrizione Questo Attributo identifica l'utente o la risorsa che esegue un'attività. Può cambiare durante il ciclo di vita del sinistro, quando il caso viene trasferito tra periti o team diversi. È essenziale per analizzare le prestazioni delle risorse, la distribuzione del carico di lavoro e i passaggi di consegne. I Dashboard incentrati sulla produttività dei periti, sulla variabilità del carico di lavoro e sull'identificazione dei colli di bottiglia fanno spesso ampio affidamento su questo Attributo per comprendere come il lavoro viene assegnato ed elaborato dai singoli operatori. Perché è importante Consente di analizzare le prestazioni delle risorse, il bilanciamento del carico di lavoro e i modelli di collaborazione, aiutando a individuare i colli di bottiglia e le esigenze formative. Dove reperirlo Consulti la documentazione di Duck Creek Claims. Cerchi i campi relativi all'utente, al responsabile o all'assegnatario nelle tabelle collegate ai Task, agli eventi o all'entità principale del sinistro. Esempi John SmithJane DoeRobert Brownadjuster_1138 | |||
| Reparto Department | Il reparto o il team responsabile dell'attività o del sinistro in un determinato momento. | ||
| Descrizione Questo Attributo specifica il gruppo funzionale o il reparto, come 'Initial Intake', 'Investigation Unit' o 'Settlement Team', che gestisce il sinistro. Fornisce un contesto organizzativo al flusso del processo. L'analisi per reparto è fondamentale per comprendere le prestazioni del processo a livello aggregato. Aiuta a individuare i colli di bottiglia tra reparti, misurare l'efficienza dei team e comprendere come il lavoro fluisce all'interno dell'organizzazione. Perché è importante Consente di analizzare le prestazioni per area funzionale, evidenziando i passaggi di consegne tra reparti e i colli di bottiglia specifici dei team. Dove reperirlo Consulti 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 property - danno ingenteUnità investigazioni specialiElaborazione dei pagamenti | |||
| Stato del sinistro ClaimStatus | Lo stato complessivo del sinistro in un determinato momento, ad esempio Aperto, In sospeso o Chiuso. | ||
| Descrizione Lo Stato del sinistro rappresenta la condizione corrente del sinistro nel suo ciclo di vita. Fornisce una sintesi di alto livello della posizione del sinistro nel processo complessivo. Questo Attributo è utile per creare viste di alto livello dell'inventario dei sinistri e per filtrare i casi. È particolarmente importante per identificare l'esito finale di un sinistro, ad esempio 'Closed - Paid' o 'Closed - Denied', elemento essenziale per analizzare gli esiti e comprendere i tassi di rifiuto. Perché è importante Fornisce una fotografia dello stato corrente e dell'esito finale del sinistro, elementi fondamentali per l'analisi degli esiti e il filtraggio dei casi. Dove reperirlo Consulti la documentazione di Duck Creek Claims. È un campo fondamentale del record principale del sinistro. Esempi ApertoIn sospeso: in attesa di informazioniChiuso: liquidatoChiuso: respinto | |||
| Tipo di sinistro ClaimType | La categoria del sinistro assicurativo, ad esempio Auto, Property o Liability. | ||
| Descrizione Il Tipo di sinistro classifica i sinistri in base al ramo di attività o alla natura del danno. È una dimensione fondamentale per segmentare e analizzare i dati dei sinistri. Questo Attributo viene utilizzato per confrontare le prestazioni del processo tra diversi tipi di sinistro. Ad esempio, un sinistro 'Auto - Total Loss' segue un processo molto diverso e presenta KPI differenti rispetto a un sinistro 'Property - Water Damage'. L'analisi per Tipo di sinistro fornisce il contesto necessario e consente confronti più significativi delle prestazioni, oltre a iniziative di miglioramento del processo mirate. Perché è importante È una dimensione critica per segmentare l'analisi, poiché i diversi tipi di sinistro presentano spesso processi, SLA e livelli di complessità distinti. Dove reperirlo Consulti la documentazione di Duck Creek Claims. Si tratta di un Attributo fondamentale del record principale del sinistro. Esempi Auto privata - collisioneProperty commerciale - incendioIndennizzo per infortuni sul lavoroResponsabilità civile generale | |||
| Data obiettivo di risoluzione ResolutionTargetDate | La data entro la quale si prevede di risolvere il sinistro, sulla base degli SLA o degli obiettivi interni. | ||
| Descrizione Questo Attributo memorizza la scadenza per la chiusura del sinistro. La data viene spesso determinata da requisiti normativi, accordi sul livello di servizio (SLA) o indicatori chiave di prestazione (KPI) interni e può variare in base al tipo o alla gravità del sinistro. Costituisce la base per calcolare il KPI 'On-Time Claim Resolution Rate' e supportare il Dashboard 'Claim Resolution Target Adherence'. Consente di monitorare proattivamente i sinistri a rischio di violazione dello SLA e aiuta a stabilire le priorità del lavoro. Perché è importante Consente di misurare le prestazioni rispetto agli accordi sul livello di servizio (SLA) e agli obiettivi interni, con un impatto diretto sulla soddisfazione dei clienti e sulla conformità. Dove reperirlo Consulti la documentazione di Duck Creek Claims. Potrebbe trattarsi di un campo specifico relativo alla data SLA oppure di un valore calcolato in base alla data di invio del sinistro e alle regole aziendali. Esempi 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
| È automatizzata IsAutomated | Un flag booleano che indica se l'attività è stata eseguita automaticamente dal sistema, senza intervento umano. | ||
| Descrizione Questo flag distingue tra le attività completate dagli utenti e quelle eseguite dall'automazione di sistema, come le notifiche automatiche, la validazione iniziale dei dati o le fasi di straight-through processing. L'analisi di questo attributo è fondamentale per comprendere il livello di automazione del processo di gestione dei sinistri. Consente di misurare l'impatto delle iniziative di automazione, individuare ulteriori opportunità di automazione e verificare che le fasi automatizzate funzionino come previsto senza generare problemi nelle fasi successive. Perché è importante Consente di misurare l'impatto dell'automazione sull'efficienza e sui costi e di individuare opportunità di straight-through processing. Dove reperirlo Queste informazioni possono essere dedotte dall'utente associato a un evento, ad esempio 'SYSTEM' o 'BATCH', oppure da un flag specifico presente nel record dell'evento. Esempi truefalse | |||
| È rielaborazione IsRework | Un flag calcolato che indica se un'attività fa parte di un ciclo di rielaborazione. | ||
| Descrizione Questo attributo booleano viene impostato su true se un'attività viene ripetuta per un sinistro dopo che si sono già verificate altre attività differenti. Ad esempio, quando il processo passa da 'Loss Assessed' nuovamente a 'Investigation Started'. Questo attributo è essenziale per quantificare e analizzare le rielaborazioni. Supporta il KPI 'Claim Rework Rate' e il Dashboard 'Claim Rework & Reprocessing Patterns', consentendo di filtrare direttamente e mettere in evidenza le attività e i casi che coinvolgono rielaborazioni. In questo modo è possibile individuare inefficienze e problemi di qualità nel processo. Perché è importante Quantifica le rielaborazioni a livello di attività, rendendo semplice misurare, visualizzare e analizzare le cause e gli effetti delle inefficienze di processo. Dove reperirlo Non è un campo del sistema di origine. Viene calcolato durante la preparazione dei dati mediante algoritmi che rilevano sequenze ripetute di attività all'interno di un caso. Esempi truefalse | |||
| Importo della liquidazione SettlementAmount | L'importo finanziario finale concordato per liquidare il sinistro. | ||
| Descrizione Questo Attributo registra il valore della liquidazione calcolato e autorizzato al pagamento. È una metrica fondamentale basata sull'esito di ogni sinistro che comporta un pagamento. Questo Attributo è essenziale per l'analisi finanziaria e per Dashboard come 'Payment Authorization & Issuance Time'. Può essere confrontato con l''Loss Amount' iniziale per analizzare l'accuratezza delle riserve ed è fondamentale per comprendere gli esiti finanziari del processo di gestione dei sinistri. Perché è importante Rappresenta il principale esito finanziario di un sinistro, essenziale per la reportistica finanziaria e per analizzare l'accuratezza delle stime iniziali del danno. Dove reperirlo Consulti la documentazione di Duck Creek Claims. Queste informazioni sono generalmente memorizzate nelle tabelle delle transazioni finanziarie o dei pagamenti associate al sinistro. Esempi 1450.7522000.00115800.20 | |||
| La risoluzione è avvenuta nei tempi previsti IsOnTimeResolution | Un flag calcolato che indica se un sinistro è stato chiuso entro o prima della data obiettivo di risoluzione. | ||
| Descrizione Questo attributo booleano viene ricavato confrontando il timestamp dell'attività 'Claim Closed' con la 'ResolutionTargetDate' del sinistro. Indica ogni sinistro come risolto nei tempi previsti (true) oppure in ritardo (false). Questo attributo supporta direttamente il KPI 'On-Time Claim Resolution Rate'. Consente di aggregare e visualizzare facilmente il rispetto degli SLA nei Dashboard e permette di analizzare in dettaglio le caratteristiche ricorrenti dei sinistri in ritardo, ad esempio specifici tipi di sinistro, reparti o percorsi di processo. Perché è importante Misura direttamente la conformità agli SLA a livello di singolo sinistro, consentendo filtri efficaci e un'analisi delle cause principali dei sinistri oltre la scadenza. Dove reperirlo Non è un campo del sistema di origine. Viene calcolato durante la preparazione dei dati confrontando il timestamp dell'attività finale con il campo 'ResolutionTargetDate'. Esempi truefalse | |||
| Motivo del rifiuto RejectionReason | Il motivo specifico per cui un sinistro è stato negato o rifiutato. | ||
| Descrizione Quando viene presa la decisione di negare un sinistro, questo Attributo fornisce la motivazione alla base della decisione. In genere viene selezionato da un elenco predefinito di codici o descrizioni. L'analisi dei motivi di rifiuto è fondamentale per il Dashboard 'Claim Decision & Rejection Insights'. Aiuta a individuare problemi ricorrenti nelle richieste, potenziali schemi fraudolenti o aree in cui il linguaggio della polizza potrebbe non essere chiaro. Queste informazioni possono guidare i miglioramenti del processo di raccolta iniziale o delle regole di sottoscrizione. Perché è importante Spiega perché i sinistri vengono rifiutati, fornendo insight utili per migliorare la raccolta iniziale, ridurre gli invii non validi e individuare opportunità di formazione. Dove reperirlo Consulti la documentazione di Duck Creek Claims. Questo campo viene generalmente compilato quando lo stato del sinistro passa a 'Denied' o a uno stato analogo. Esempi Evento non copertoPolizza scadutaSinistro duplicatoFrode sospetta | |||
| Numero di polizza PolicyNumber | L'identificativo univoco della polizza assicurativa nell'ambito della quale è stato presentato il sinistro. | ||
| Descrizione Questo Attributo collega il sinistro alla polizza assicurativa di origine. Fornisce il contesto relativo alla copertura, alle condizioni e al cliente associati al sinistro. Sebbene non venga sempre utilizzato direttamente nell'analisi del flusso di processo, il Numero di polizza è prezioso per arricchire i dati del sinistro. Consente di effettuare join con i dati delle polizze e dei clienti, per analizzare come le prestazioni del processo varino in base al segmento di clientela, al tipo di polizza o all'anzianità della polizza, offrendo una visione aziendale più completa. Perché è importante Collega il sinistro al cliente e alla polizza, consentendo un'analisi più ampia dell'impatto delle prestazioni del processo sui diversi segmenti di clientela o tipi di polizza. Dove reperirlo Consulti la documentazione di Duck Creek Claims. È un campo di riferimento standard dell'entità principale del sinistro. Esempi PA-987654321CP-123456789WC-555444333 | |||
| Ora di fine EndTime | Il timestamp che indica quando un'attività è stata completata. | ||
| Descrizione Questo attributo indica l'ora di completamento di un'attività. Mentre StartTime indica quando è iniziata un'attività, EndTime fornisce l'altro elemento necessario per calcolare la durata di quella specifica attività. Nel Process Mining, disporre sia dell'ora di inizio sia dell'ora di fine delle attività consente un'analisi molto più approfondita delle prestazioni. Permette di calcolare con precisione il 'Processing Time', cioè il tempo di lavoro effettivo su un'attività, distinguendolo dal 'Waiting Time', ovvero 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à, distinguendo il tempo di lavoro effettivo dal tempo di inattività o attesa, elemento essenziale per un'analisi accurata dei colli di bottiglia. Dove reperirlo Può essere disponibile come campo timestamp separato negli Event Log oppure può essere ricavato dallo StartTime dell'attività successiva nella sequenza dello stesso caso. Esempi 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Sistema di origine SourceSystem | Il sistema dal quale sono stati estratti i dati dell'evento. | ||
| Descrizione Questo Attributo identifica l'applicazione di origine in cui sono stati generati i dati del sinistro. In questo contesto, il valore sarà sempre 'Duck Creek Claims'. Sebbene possa sembrare ridondante se tutti i dati provengono da un unico sistema, è fondamentale per la governance dei dati, la tracciabilità e gli scenari in cui in futuro i dati potrebbero essere uniti da più sistemi. Fornisce il contesto sull'origine e sulla struttura dei dati. Perché è importante Fornisce informazioni essenziali sulla provenienza dei dati e sul contesto, fondamentali per la governance dei dati e la risoluzione dei problemi, soprattutto in ambienti con più sistemi integrati. Dove reperirlo In genere è un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per indicarne l'origine. Esempi Sinistri Duck Creek | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Il timestamp dell'aggiornamento più recente dei dati provenienti dal sistema di origine. | ||
| Descrizione Questo Attributo indica quando il dataset è stato aggiornato l'ultima volta. Fornisce un riferimento per valutare l'aggiornamento dei dati analizzati. Nei Dashboard e nelle analisi, viene utilizzato per informare gli utenti sulla datazione degli insight. Aiuta a comprendere se le transazioni più recenti sono incluse nella vista del processo. Perché è importante Informa gli utenti sull'aggiornamento dei dati, un elemento fondamentale per interpretare l'analisi e prendere decisioni tempestive. Dove reperirlo Questo timestamp viene generato durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati e viene generalmente memorizzato nei metadati del dataset. Esempi 2024-05-21T02:00:00Z | |||
Attività di gestione dei sinistri
| Attività | Descrizione | ||
|---|---|---|---|
| Decisione sul sinistro presa | Questa attività rappresenta la decisione ufficiale sul sinistro, ad esempio 'Approved', 'Partially Approved' o 'Denied'. È una tappa decisiva, dedotta dalla modifica dello stato a uno stato decisionale finale. | ||
| Perché è importante È una tappa decisionale fondamentale. Il tempo che precede questo momento e l'esito della decisione sono elementi centrali per l'analisi del processo e dell'efficienza. Dove reperirlo Deducibile dalla modifica di un campo dedicato 'Claim Decision' o 'Claim Status' a uno stato terminale come 'Approved' o 'Denied'. Viene acquisito il timestamp della modifica. Acquisizione Deducibile 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 di liquidazione calcolato. Spesso è un passaggio distinto che coinvolge un responsabile o un'autorità separata, acquisito come transazione esplicita di approvazione. | ||
| Perché è importante È un punto di controllo fondamentale e un potenziale collo di bottiglia prima del pagamento. La durata da 'Claim Decision Made' a questo punto viene misurata dal KPI 'Average Claim Approval Time'. Dove reperirlo In genere si tratta di un evento esplicito in un Workflow o in un modulo finanziario, in cui un utente con autorizzazioni specifiche approva il pagamento. Dovrebbe essere presente in un log delle approvazioni. Acquisizione Evento esplicito di approvazione registrato in un Workflow o in un log delle transazioni. Tipo di evento explicit | |||
| Pagamento emesso | Questa attività segna l'esecuzione della transazione finanziaria per il pagamento del sinistro. È un evento chiaro ed esplicito, generato quando il pagamento viene inviato tramite assegno, EFT o altri metodi. | ||
| Perché è importante Indica il completamento dell'obbligazione finanziaria relativa a un sinistro approvato. Il tempo tra 'Payment Authorized' e 'Payment Issued' rivela l'efficienza del reparto finanziario. Dove reperirlo Acquisito dalla tabella delle transazioni finanziarie in Duck Creek Claims, che registra tutti i pagamenti in uscita con uno specifico codice di transazione e timestamp. Acquisizione Quando il pagamento viene elaborato, viene creata una voce distinta nel log delle transazioni finanziarie. Tipo di evento explicit | |||
| Sinistro chiuso | Questa è l'attività finale e segna la chiusura amministrativa della pratica del sinistro dopo l'emissione del pagamento o la liquidazione del sinistro. Viene acquisita tramite l'aggiornamento finale dello stato a 'Closed'. | ||
| Perché è importante Questa attività segna la conclusione positiva del processo. Costituisce il punto finale per il calcolo dell''Average End-to-End Claim Cycle Time' e di altre metriche chiave di durata. Dove reperirlo Deducibile dal timestamp della modifica finale dello stato a 'Closed' o 'Settled' nella tabella principale dei dati del sinistro. Acquisizione Deducibile dal fatto che lo stato finale del sinistro sia impostato su 'Closed'. Tipo di evento inferred | |||
| Sinistro inviato | Questo è il primo evento e rappresenta la ricezione da parte dell'assicuratore della First Notice of Loss (FNOL). In genere viene acquisito 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 vita del sinistro. Analizzare il tempo che intercorre tra questo evento e gli eventi successivi è fondamentale per comprendere la durata complessiva dell'elaborazione e l'efficienza della raccolta iniziale. Dove reperirlo Di norma si tratta di un evento esplicito registrato in una tabella di log dei sinistri o della FNOL, quando viene creato per la prima volta un nuovo record di sinistro in Duck Creek Claims. Acquisizione Evento registrato alla creazione iniziale di un nuovo record di sinistro. Tipo di evento explicit | |||
| Sinistro rifiutato | Questa attività rappresenta una conclusione alternativa del processo, in cui il sinistro viene ufficialmente rifiutato. Viene acquisita quando lo stato finale del sinistro viene impostato su 'Denied' o 'Rejected'. | ||
| Perché è importante Si tratta di un esito critico che richiede un'analisi distinta. Comprendere perché e quando i sinistri vengono rifiutati aiuta a migliorare i processi iniziali e a gestire la conformità. Dove reperirlo Deducibile dal timestamp della modifica finale dello stato del sinistro a 'Denied', 'Rejected' o 'Closed without Payment' nella tabella dell'entità sinistro. Acquisizione Deducibile dal fatto che lo stato finale del sinistro corrisponda a un motivo di rifiuto. Tipo di evento inferred | |||
| Danno valutato | Questa tappa segna il momento in cui le riserve finanziarie vengono impostate o aggiornate sulla base dei risultati dell'indagine. Indica la stima dell'impatto finanziario del sinistro e viene acquisita quando gli importi delle riserve vengono inseriti o modificati. | ||
| Perché è importante Si tratta di un punto di controllo finanziario critico del processo. Analizzare quando si verifica consente di comprendere la rapidità e l'accuratezza della valutazione finanziaria. Dove reperirlo Spesso si tratta di una transazione finanziaria esplicita registrata nel log delle transazioni finanziarie del sinistro o nella tabella della cronologia delle riserve all'interno di Duck Creek Claims. Acquisizione Transazione finanziaria registrata per l'impostazione o l'aggiornamento delle riserve del sinistro. Tipo di evento explicit | |||
| Indagine avviata | Questa attività indica l'inizio della fase formale di indagine sul sinistro. Spesso viene dedotta dalla modifica dello stato del sinistro a 'Under Investigation' o a uno stato analogo. | ||
| Perché è importante Segna l'inizio di una fase ad alto impiego di risorse. Misurare la durata dell'indagine è fondamentale per il KPI 'Average Investigation Duration' e aiuta a gestire una parte critica del processo. Dove reperirlo Deducibile dal timestamp dell'aggiornamento dello stato del sinistro a 'Investigation in Progress' o 'Pending Inspection' nel campo principale relativo allo stato del sinistro. Acquisizione Derivato da una modifica dello stato del sinistro che indica l'inizio delle attività di indagine. Tipo di evento inferred | |||
| Indagine completata | Rappresenta la conclusione delle attività di indagine, quando sono stati raccolti tutti gli elementi necessari. In genere viene dedotta quando lo stato del sinistro passa da 'Under Investigation' a uno stato decisionale come 'Pending Decision'. | ||
| Perché è importante Il completamento dell'indagine è una tappa fondamentale, poiché sblocca le fasi decisionali e di liquidazione. Eventuali ritardi in questa fase hanno un impatto significativo sulle attività successive. Dove reperirlo Deducibile dal timestamp dell'aggiornamento dello stato del sinistro da uno stato di 'investigation' a uno stato di 'review' o 'decision'. Acquisizione Derivato da una modifica dello stato del sinistro che indica la conclusione delle attività di indagine. Tipo di evento inferred | |||
| Informazioni aggiuntive ricevute | Segna la ricezione delle informazioni richieste, consentendo la prosecuzione della gestione del sinistro. Può essere registrato manualmente dal perito oppure automaticamente, se le informazioni vengono inviate tramite un portale digitale. | ||
| Perché è importante Il tempo tra 'Information Requested' e 'Information Received' rappresenta un periodo di attesa critico. Analizzare questa durata aiuta a individuare le dipendenze esterne e i colli di bottiglia nella comunicazione. Dove reperirlo Può trattarsi di un evento esplicito proveniente dall'integrazione con un sistema di gestione documentale, di una registrazione manuale nel log oppure di una modifica di stato effettuata dal perito al ricevimento dei documenti. Acquisizione Evento registrato al caricamento di un documento o all'inserimento manuale da parte di un perito. Tipo di evento explicit | |||
| Informazioni aggiuntive richieste | Questa attività si verifica quando il perito stabilisce che sono necessarie ulteriori informazioni e invia una richiesta al contraente o a una terza parte. Spesso si tratta di un evento esplicito collegato al modulo di comunicazione o corrispondenza del sistema. | ||
| Perché è importante Un'elevata frequenza di questa attività può indicare problemi nel processo iniziale di raccolta dei dati. Introduce inoltre tempi di attesa significativi, incidendo sulla durata complessiva del ciclo. Dove reperirlo Acquisito dai log relativi alle comunicazioni in uscita, ad esempio lettere ed e-mail, oppure da una specifica transazione 'Request for Information' in Duck Creek Claims. Acquisizione Registrato quando viene generata una corrispondenza o un'attività per richiedere informazioni. Tipo di evento explicit | |||
| Liquidazione calcolata | Dopo una decisione di approvazione, questa attività rappresenta il calcolo dell'importo finale della liquidazione o del pagamento. Può essere un passaggio esplicito oppure essere dedotta dalla finalizzazione degli importi di pagamento nel modulo finanziario del sistema. | ||
| Perché è importante Questa attività è fondamentale per misurare il KPI 'Settlement Rework Rate'. La presenza di più occorrenze di questo evento per un singolo sinistro indica inefficienze, errori o negoziazioni nella fase di liquidazione. Dove reperirlo Può trattarsi di una voce esplicita nel log delle transazioni oppure essere dedotta dagli aggiornamenti del campo 'Settlement Amount' nei dati finanziari del sinistro. I log di audit di questo campo costituiscono la fonte principale. Acquisizione Evento registrato quando l'importo finale del pagamento viene calcolato e salvato. Tipo di evento explicit | |||
| Perito assegnato | Questo evento registra l'assegnazione di un perito o responsabile della gestione al sinistro registrato. Il sistema registra l'assegnazione, creando un chiaro punto di passaggio di consegne e stabilendo la responsabilità per il ciclo di vita del sinistro. | ||
| Perché è importante È fondamentale per analizzare l'allocazione delle risorse, il carico di lavoro dei periti e i ritardi nell'assegnazione dei sinistri. Si tratta di un punto di passaggio di consegne rilevante, che può introdurre tempi di attesa. Dove reperirlo Viene monitorato tramite l'aggiornamento del campo 'Assigned Adjuster' nella tabella principale dei dati del sinistro. Il timestamp è disponibile nella cronologia o nel log di audit di questo campo. Acquisizione Registrato in una traccia di audit quando il campo del perito viene compilato o modificato. Tipo di evento explicit | |||
| Revisione iniziale completata | Rappresenta il completamento della prima revisione completa del sinistro da parte del perito assegnato. In genere viene dedotto quando lo stato del sinistro cambia dopo l'assegnazione, ad esempio passando da 'Assigned' a 'Under Review' o 'Investigation'. | ||
| Perché è importante Questa tappa aiuta a misurare il tempo necessario al perito per compiere la prima azione e può indicare potenziali arretrati nel suo carico di lavoro. È il primo importante punto di controllo guidato da un operatore. Dove reperirlo Viene dedotto da una modifica del campo relativo allo stato del sinistro, ad esempio dal passaggio a 'Initial Review Complete' o 'Pending Information'. Viene utilizzato il timestamp della modifica di stato. Acquisizione Deducibile dalla modifica del campo relativo allo stato del sinistro successiva all'assegnazione del perito. Tipo di evento inferred | |||
| Sinistro registrato | Segna l'accettazione e la registrazione formale del sinistro inviato, momento in cui viene assegnato ufficialmente un Claim ID 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 processi successivi, come l'assegnazione del perito. Il tempo tra l'invio e la registrazione può indicare problemi nella qualità iniziale dei dati o nel carico del sistema. Dove reperirlo Viene dedotto dal timestamp in cui viene generato il Claim ID principale e lo stato del sinistro passa da 'pending' o 'submitted' a 'open' o 'registered' nella tabella principale dell'entità sinistro. Acquisizione Derivato dal timestamp di creazione del record principale del sinistro o da una modifica dello stato a 'Open'. Tipo di evento inferred | |||
Guide all'estrazione
Passaggi
- Acceda all'utility di configurazione di Duck Creek Data Hub: acceda all'ambiente Duck Creek e apra l'applicazione Data Hub. Sono necessarie autorizzazioni adeguate per creare o modificare le configurazioni di esportazione dei dati.
- Crei un nuovo job di esportazione dei dati: nell'utility Data Hub, avvii la procedura per creare un nuovo job di esportazione. Gli assegni un nome descrittivo, ad esempio ProcessMind_Claims_Event_Log_Export.
- Definisca la fonte dei dati: configuri il job affinché si connetta al database SQL principale di Data Hub. Dovrà indicare 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 per la definizione della query del job di esportazione. Copi lo script completo dalla sezione della query riportata di seguito e lo incolli nell'editor delle query.
- 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 per specificare l'intervallo di date desiderato. 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, come ClaimId, ActivityName ed EventTime, siano mappate correttamente alle colonne del file di output. I nomi delle intestazioni nel 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 verrà salvato il file CSV generato. Verifichi che il sistema disponga delle autorizzazioni di scrittura necessarie.
- Pianifichi il job di esportazione: configuri la pianificazione del job. Per l'analisi iniziale può eseguirlo manualmente. Per il monitoraggio continuativo, imposti una pianificazione ricorrente, ad esempio giornaliera o settimanale.
- Esegua il job e recuperi il file: esegua il job per generare l'Event Log. Al termine, recuperi il file CSV dalla destinazione specificata al passaggio 8.
- Prepari il caricamento: prima di caricare il file in ProcessMind, apra il CSV per un controllo finale. Verifichi che le intestazioni siano corrette, che il formato della data sia coerente (YYYY-MM-DD HH:MI:SS) e che i dati siano quelli attesi.
Configurazione
- Prerequisiti: è necessario avere accesso al modulo Duck Creek Data Hub. L'utente o l'account di servizio che esegue il job di esportazione deve disporre delle autorizzazioni di lettura sulle tabelle del database sottostante al Data Hub, ad esempio [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim] e [DataHubSchema].[DimStatusHistory].
- Configurazione dell'intervallo di date: la query utilizza i parametri @StartDate e @EndDate. È fondamentale impostarli per definire la finestra di estrazione. Per una prima analisi, si consiglia un periodo di 6-12 mesi, così da includere un numero sufficiente di casi completati e in corso.
- Filtri: la query include il segnaposto /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ all'interno della Common Table Expression (CTE). Rimuova il commento e modifichi questa riga per filtrare specifiche linee di business, ad esempio 'Personal Auto' o 'Commercial Property', riducendo il volume dei dati e concentrando l'analisi.
- Ciclo di aggiornamento del Data Hub: tenga presente la latenza dei dati del Data Hub. I dati non sono in tempo reale e vengono generalmente aggiornati secondo una pianificazione, ad esempio ogni notte. I dati estratti saranno aggiornati fino all'ultimo aggiornamento del Data Hub completato correttamente.
- Formato di output: il job di esportazione deve produrre un file piatto, preferibilmente CSV. Verifichi che il qualificatore di testo sia impostato sulle virgolette doppie (") per gestire eventuali virgole presenti nei campi dati.
a 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 dispone di tutto ciò che Le serve per iniziare a ottimizzare la gestione dei sinistri. Inizi oggi stesso il percorso con i Suoi dati e porti alla luce informazioni di valore.
Elimini gli arretrati dei sinistri: ottimizzi subito la gestione dei Suoi sinistri
Raggiunga il 70% di straight-through processing, riducendo costi e ritardi.
Prova gratuita di 14 giorni, senza carta di credito.