Modello di Dati: Gestione Sinistri
Il tuo Data Template per la Gestione dei Sinistri
- Attributi consigliati da raccogliere
- Attività chiave da monitorare
- Guida all'estrazione per Duck Creek Claims
Attributi di Gestione dei Sinistri
| Nome | Descrizione | ||
|---|---|---|---|
Activity Name ActivityName | Il nome dell'attività o dell'evento di business che si è verificato in un momento specifico per un sinistro. | ||
Descrizione Questo attributo descrive una fase o un'attività specifica eseguita all'interno del processo di gestione dei sinistri, come 'Sinistro Presentato', 'Perito Assegnato' o 'Pagamento Emesso'. Ogni attività rappresenta un punto distinto nel ciclo di vita del sinistro. L'analisi della sequenza e della frequenza di queste attività è il cuore del Process Mining. Permette la scoperta di modelli di processo, l'identificazione di colli di bottiglia, il rilevamento di cicli di rilavorazione e l'analisi delle deviazioni di processo rispetto a un modello standard. Perché è importante Il Nome Attività definisce le fasi del flusso di processo, ed è fondamentale per la scoperta, l'analisi e il monitoraggio del processo dei sinistri. Dove trovare Tipicamente derivato da log di eventi, nomi di transazioni o record di cambio di stato all'interno di Duck Creek Claims. Ciò potrebbe richiedere un'operazione di mapping da più campi o tabelle sorgente. Esempi Sinistro PresentatoLiquidatore AssegnatoIndagine avviataPagamento EmessoSinistro Chiuso | |||
ID Sinistro ClaimId | L'identificativo unico per un singolo sinistro assicurativo, che funge da identificativo primario del case. | ||
Descrizione L'ID Sinistro è la chiave fondamentale che collega tutti gli eventi e le attività associati a un singolo sinistro assicurativo, dalla presentazione alla chiusura. Assicura che l'intero ciclo di vita di un sinistro possa essere tracciato in modo coerente. Nell'analisi di process mining, questo attributo è essenziale per costruire la vista del caso, permettendo agli analisti di tracciare il percorso completo di ogni sinistro, misurare i tempi di ciclo end-to-end e analizzare le varianti di processo. Perché è importante Questo è l'ID Case fondamentale che collega tutti gli eventi correlati nel processo, consentendo una visione completa e end-to-end del ciclo di vita del sinistro. Dove trovare Questa è una chiave primaria nell'entità o tabella principale dei sinistri all'interno di Duck Creek Claims. Consultare la documentazione di sistema per il nome specifico della tabella e del campo. Esempi CL-2023-001234CL-2023-005678CL-2024-009101 | |||
Ora Evento EventTime | Il timestamp che indica quando una specifica attività o un evento si è verificato. | ||
Descrizione L'Ora Evento fornisce la data e l'ora precise per ogni attività registrata nel ciclo di vita del sinistro. Questa informazione temporale è fondamentale per l'analisi delle prestazioni. Nell'analisi, questo timestamp viene utilizzato per calcolare i tempi di ciclo tra le attività, identificare i tempi di attesa, misurare la durata complessiva del caso e analizzare le prestazioni del processo in diversi periodi di tempo. È la spina dorsale di qualsiasi metrica di processo basata sul tempo. Perché è importante Questo timestamp è cruciale per calcolare tutte le metriche basate sul tempo, come tempi di ciclo e durate, permettendo l'analisi delle performance e l'identificazione dei colli di bottiglia. Dove trovare Questo è un campo timestamp standard associato ai log di eventi o transazioni in Duck Creek Claims. Si possono cercare campi come 'CreateDate', 'Timestamp' o 'EventDate'. Esempi 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
Dipartimento Department | Il dipartimento o il team responsabile dell'attività o del sinistro in un dato momento. | ||
Descrizione Questo attributo specifica il gruppo funzionale o il dipartimento, come 'Acquisizione Iniziale', 'Unità di Investigazione' o 'Team di Liquidazione', che gestisce il sinistro. Fornisce un contesto organizzativo al flusso di processo. L'analisi per dipartimento è fondamentale per comprendere le performance del processo a livello aggregato. Aiuta a identificare i colli di bottiglia inter-dipartimentali, misurare l'efficienza a livello di team e comprendere come il lavoro fluisce attraverso l'organizzazione. Perché è importante Consente l'analisi delle prestazioni per area funzionale, evidenziando i passaggi tra dipartimenti e i colli di bottiglia specifici dei team. Dove trovare Consultare la documentazione di Duck Creek Claims. Questa informazione è spesso associata al profilo dell'utente assegnato o a un'assegnazione a coda/gruppo di lavoro. Esempi Sinistri AutoSinistri Danni - Grande EntitàUnità Investigativa SpecialeElaborazione del Pagamento | |||
Gravità del Sinistro ClaimSeverity | Una classificazione della complessità finanziaria o operativa del sinistro, come Bassa, Media o Alta. | ||
Descrizione La Gravità del Sinistro fornisce un'indicazione dell'impatto o della complessità previsti di un sinistro. Può essere basata sulla stima iniziale della perdita, sulla natura dell'incidente o su altre regole aziendali predefinite. Questo attributo è vitale per l'analisi delle prestazioni, poiché i sinistri ad alta gravità richiedono tipicamente più passaggi, tempi di elaborazione più lunghi e risorse specializzate. Segmentare i KPI per gravità aiuta a stabilire obiettivi di performance realistici e a capire come la complessità influisce sull'efficienza e sui risultati del processo. Perché è importante Aiuta a segmentare i sinistri per complessità, consentendo un'analisi delle prestazioni più sfumata e un benchmarking realistico dei tempi di ciclo e dei costi. Dove trovare Consultare la documentazione di Duck Creek Claims. Questo potrebbe essere un campo dedicato o derivato dall'importo della riserva iniziale di perdita. Esempi BassaMediaAltoCatastrofico | |||
Importo del Danno LossAmount | L'importo finanziario stimato o effettivo della perdita riportato nel sinistro. | ||
Descrizione Questo attributo rappresenta il valore iniziale stimato del danno associato al sinistro. È una metrica finanziaria chiave 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 come l'impatto finanziario si correla con il comportamento del processo. Ad esempio, i sinistri di valore più elevato possono seguire percorsi diversi o avere tempi di ciclo più lunghi. Fornisce un contesto finanziario cruciale ai dati del processo operativo. Perché è importante Fornisce il contesto finanziario del sinistro, consentendo di analizzare come il valore di una pratica influenzi il suo percorso di elaborazione, la durata e l'esito. Dove trovare Consultare la documentazione di Duck Creek Claims. Questo è un campo finanziario centrale relativo al sinistro, spesso denominato 'Danno Dichiarato' o 'Riserva Iniziale'. Esempi 1500.0025000.50125000.00 | |||
Liquidatore Assegnato AssignedAdjuster | Il nome o l'ID del liquidatore del sinistro responsabile della gestione della pratica in una data attività. | ||
Descrizione Questo attributo identifica l'utente o la risorsa che esegue un'attività. Può cambiare lungo il ciclo di vita del sinistro, man mano che il case viene passato tra diversi periti o team. Questo è essenziale per analizzare le performance delle risorse, la distribuzione del carico di lavoro e i passaggi di consegne (handoffs). Le dashboard focalizzate sulla produttività dei periti, la variazione del carico di lavoro e l'identificazione dei colli di bottiglia spesso si basano fortemente su questo attributo per comprendere come il lavoro viene allocato ed elaborato dagli individui. Perché è importante Consente l'analisi delle prestazioni delle risorse, del bilanciamento del carico di lavoro e dei modelli di collaborazione, contribuendo a identificare i colli di bottiglia e le esigenze di formazione. Dove trovare Consultare la documentazione di Duck Creek Claims. Cercare i campi utente, proprietario o assegnatario nelle tabelle relative alle attività del sinistro, agli eventi o all'entità principale del sinistro. Esempi John SmithJane DoeRobert Brownadjuster_1138 | |||
Stato del Sinistro ClaimStatus | Lo stato complessivo del sinistro in un dato momento, come Aperto, In Sospeso o Chiuso. | ||
Descrizione Lo Stato del Sinistro rappresenta lo stato attuale del sinistro nel suo ciclo di vita. Fornisce un riepilogo di alto livello sulla 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 (es. 'Chiuso - Pagato', 'Chiuso - Rifiutato'), essenziale per l'analisi degli esiti e la comprensione dei tassi di rifiuto. Perché è importante Fornisce un'istantanea dello stato attuale e dell'esito finale del sinistro, fondamentale per l'analisi dei risultati e per il filtro dei casi. Dove trovare Consultare la documentazione di Duck Creek Claims. Questo è un campo fondamentale nel record principale del sinistro. Esempi ApertoIn Attesa - Informazioni RichiesteChiuso - LiquidatoChiuso - Rifiutato | |||
Tipo di Sinistro ClaimType | La categoria del sinistro assicurativo, come Auto, Danni (a beni) o Responsabilità Civile. | ||
Descrizione Il Tipo di Sinistro classifica i sinistri in base alla linea di business o alla natura della perdita. Questa è una dimensione fondamentale per segmentare e analizzare i dati dei sinistri. Questo attributo è utilizzato per confrontare le prestazioni dei processi tra diversi tipi di sinistri. Ad esempio, un sinistro 'Auto - Danno Totale' segue un processo molto diverso e ha KPI diversi rispetto a un sinistro 'Proprietà - Danno Idrico'. L'analisi per Tipo di Sinistro fornisce contesto e consente confronti di performance più significativi e iniziative di miglioramento dei processi personalizzate. Perché è importante Questa è una dimensione fondamentale per segmentare l'analisi, poiché diverse tipologie di sinistro presentano spesso processi, SLA e livelli di complessità distinti. Dove trovare Consultare la documentazione di Duck Creek Claims. Questo è un attributo centrale nel record principale del sinistro. Esempi Auto Personale - CollisioneProprietà Commerciale - IncendioInfortuni sul LavoroResponsabilità civile generale | |||
Data Obiettivo di Risoluzione ResolutionTargetDate | La data obiettivo entro cui il sinistro dovrebbe essere risolto, in base agli SLA o agli obiettivi interni. | ||
Descrizione Questo attributo memorizza la scadenza per la chiusura del sinistro. Questa data è spesso determinata da requisiti normativi, Service Level Agreement (SLA) o Key Performance Indicator (KPI) interni, e può variare in base al tipo o alla gravità del sinistro. Questa è la base per il calcolo del KPI 'Tasso di Risoluzione Puntuale dei Sinistri' e per supportare la dashboard 'Claim Resolution Target Adherence'. Consente un monitoraggio proattivo dei sinistri a rischio di violazione del loro SLA e aiuta a dare priorità al lavoro. Perché è importante Consente la misurazione delle prestazioni rispetto agli accordi sul livello di servizio (SLA) e agli obiettivi interni, il che incide direttamente sulla soddisfazione del cliente e sulla conformità. Dove trovare Consultare la documentazione di Duck Creek Claims. Questo potrebbe essere un campo data SLA specifico o calcolato in base alla data di presentazione del sinistro e alle regole aziendali. Esempi 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
È automatizzato IsAutomated | Un flag booleano che indica se l'attività è stata eseguita automaticamente dal sistema senza intervento umano. | ||
Descrizione Questo indicatore distingue tra le attività completate da utenti umani e quelle eseguite dall'automazione di sistema, come notifiche automatiche, convalida iniziale dei dati o passaggi di elaborazione diretta (straight-through processing). L'analisi di questo attributo è fondamentale per comprendere il livello di automazione nel processo di gestione dei sinistri. Permette di misurare l'impatto delle iniziative di automazione, identificare opportunità per un'ulteriore automazione e garantire che i passaggi automatizzati funzionino come previsto senza generare problemi a valle. Perché è importante Aiuta a misurare l'impatto dell'automazione su efficienza e costi, e a identificare opportunità per il straight-through processing. Dove trovare Questa informazione può essere dedotta dall''utente' associato a un evento (es. 'SYSTEM' o 'BATCH'), oppure da un flag specifico presente nel record dell'evento. Esempi truefalse | |||
È rilavorazione IsRework | Un flag calcolato che indica se un'attività fa parte di un ciclo di rilavorazione. | ||
Descrizione Questo attributo booleano è impostato su true se un'attività viene ripetuta per un sinistro dopo che altre attività, diverse, si sono già verificate. Ad esempio, se il processo passa da 'Danno Valutato' a 'Indagine Iniziata'. Questo attributo è essenziale per quantificare e analizzare la rilavorazione. Supporta il KPI 'Tasso di Rilavorazione dei Sinistri' e la dashboard 'Claim Rework & Reprocessing Patterns' permettendo di filtrare e evidenziare direttamente le attività e i case che comportano rilavorazioni. Questo aiuta a individuare inefficienze e problemi di qualità nel processo. Perché è importante Quantifica il rework a livello di attività, facilitando la misurazione, visualizzazione e analisi delle cause e degli impatti delle inefficienze di processo. Dove trovare Questo non è un campo del sistema sorgente. Viene calcolato durante la preparazione dei dati utilizzando algoritmi che rilevano sequenze ripetute di attività all'interno di un case. Esempi truefalse | |||
È risoluzione nei tempi previsti IsOnTimeResolution | Un flag calcolato che indica se un sinistro è stato chiuso entro o prima della sua data obiettivo di risoluzione. | ||
Descrizione Questo attributo booleano è derivato confrontando il timestamp dell'attività 'Sinistro Chiuso' con la 'ResolutionTargetDate' per quel sinistro. Contrassegna ogni sinistro come in tempo (true) o in ritardo (false). Questo attributo supporta direttamente il KPI 'Tasso di Risoluzione Puntuale dei Sinistri'. Consente una facile aggregazione e visualizzazione dell'aderenza agli SLA nelle dashboard, e abilita l'analisi di drill-down per identificare le caratteristiche comuni dei sinistri in ritardo (ad esempio, tipi di sinistro specifici, dipartimenti o percorsi di processo). Perché è importante Misura direttamente la conformità SLA a livello di singolo sinistro, consentendo un filtraggio potente e un'analisi delle cause profonde per i sinistri in ritardo. Dove trovare Questo non è un campo del sistema sorgente. Viene calcolato durante la preparazione dei dati confrontando il timestamp dell'attività finale con il campo 'ResolutionTargetDate'. Esempi truefalse | |||
Importo di Liquidazione SettlementAmount | L'importo finanziario finale concordato per liquidare il sinistro. | ||
Descrizione Questo attributo registra il valore dell'indennizzo calcolato e autorizzato per il pagamento. Questa è una metrica chiave basata sul risultato per ogni sinistro che si conclude con un pagamento. Questo attributo è cruciale per l'analisi finanziaria e per dashboard come 'Payment Authorization & Issuance Time'. Può essere confrontato con l'iniziale 'Importo del Danno' per analizzare l'accuratezza delle riserve ed è fondamentale per comprendere i risultati finanziari del processo di gestione dei sinistri. Perché è importante Rappresenta l'esito finanziario chiave di un sinistro, essenziale per la rendicontazione finanziaria e per analizzare l'accuratezza delle stime iniziali di perdita. Dove trovare Consultare la documentazione di Duck Creek Claims. Questa informazione è tipicamente memorizzata nelle tabelle relative a transazioni finanziarie o pagamenti associate al sinistro. Esempi 1450.7522000.00115800.20 | |||
Motivo del Rigetto RejectionReason | Il motivo specifico per cui un sinistro è stato negato o rigettato. | ||
Descrizione Quando viene presa la decisione di negare un sinistro, questo attributo fornisce il motivo sottostante a tale decisione. Solitamente viene selezionato da un elenco predefinito di codici o descrizioni. L'analisi dei motivi di rifiuto è fondamentale per la dashboard 'Claim Decision & Rejection Insights'. Aiuta a identificare criticità comuni nelle richieste, potenziali schemi di frode o aree in cui il linguaggio della polizza potrebbe essere poco chiaro. Queste informazioni possono guidare miglioramenti nel processo di acquisizione o nelle regole di sottoscrizione. Perché è importante Spiega perché i sinistri vengono rifiutati, fornendo insight attuabili per migliorare il processo di acquisizione, ridurre le richieste non valide e identificare opportunità di formazione. Dove trovare Consultare la documentazione di Duck Creek Claims. Questo campo viene solitamente compilato quando lo stato di un sinistro passa a 'Rifiutato' o a uno stato simile. Esempi Non un Rischio CopertoPolizza ScadutaSinistro DuplicatoSospetto di Frode | |||
Numero di Polizza PolicyNumber | L'identificativo unico della polizza assicurativa sotto la quale è stato presentato il sinistro. | ||
Descrizione Questo attributo collega il sinistro alla polizza assicurativa di origine. Fornisce contesto su copertura, termini e cliente associati al sinistro. Sebbene non sempre utilizzato direttamente nell'analisi del flusso di processo, il Numero di Polizza è inestimabile per arricchire i dati del sinistro. Consente di integrare i dati di polizza e cliente per analizzare come le performance del processo variano in base al segmento di clientela, al tipo di polizza o all'anzianità della polizza, offrendo una visione di business più olistica. Perché è importante Collega il sinistro al cliente e alla polizza, consentendo un'analisi più ampia di come le performance del processo influiscono sui diversi segmenti di clientela o tipi di polizza. Dove trovare Consultare la documentazione di Duck Creek Claims. Questo è un campo di riferimento standard sull'entità principale del sinistro. Esempi PA-987654321CP-123456789WC-555444333 | |||
Ora Fine EndTime | Il timestamp che indica quando un'attività è stata completata. | ||
Descrizione Questo attributo segna il tempo di completamento di un'attività. Mentre StartTime indica quando un'attività è iniziata, EndTime fornisce il dato complementare per il calcolo della durata di quella specifica task. Nel Process Mining, avere sia un tempo di inizio che di fine per le attività consente un'analisi delle performance molto più approfondita. Permette il calcolo preciso del 'Tempo di Elaborazione' (il tempo di lavoro attivo su una task) rispetto al 'Tempo di Attesa' (il tempo trascorso tra le task). Questa distinzione è cruciale per identificare accuratamente i colli di bottiglia. Perché è importante Consente il calcolo di tempi di elaborazione precisi per le attività, distinguendo il tempo di lavoro effettivo dal tempo di inattività/attesa, il che è fondamentale per un'analisi accurata dei colli di bottiglia. Dove trovare Può essere disponibile come campo timestamp separato nei log degli eventi o può essere derivato come StartTime dell'attività successiva nella sequenza per lo stesso case. Esempi 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
Sistema di Origine SourceSystem | Il sistema da cui sono stati estratti i dati evento. | ||
Descrizione Questo attributo identifica l'applicazione sorgente da cui provengono i dati del sinistro. In questo contesto, sarà sempre 'Duck Creek Claims'. Sebbene possa sembrare ridondante se tutti i dati provengono da un unico sistema, è cruciale per la governance dei dati, la tracciabilità e in scenari in cui i dati potrebbero essere uniti da più sistemi in futuro. Fornisce contesto sull'origine e la struttura dei dati. Perché è importante Fornisce la tracciabilità e il contesto essenziali dei dati, elementi cruciali per la data governance e la risoluzione dei problemi, specialmente in ambienti con sistemi multipli integrati. Dove trovare Questo è tipicamente un valore statico aggiunto durante il processo di estrazione e trasformazione dei dati per etichettare l'origine delle informazioni. Esempi Duck Creek Claims | |||
Tempo di Elaborazione ProcessingTime | La durata del lavoro attivo per una specifica attività, calcolata come Ora di Fine meno Ora di Inizio. | ||
Descrizione Il Tempo di Elaborazione, noto anche come tempo attivo o tempo di gestione, misura quanto a lungo una risorsa ha lavorato attivamente su un'attività specifica. Viene calcolato sottraendo lo StartTime dall' EndTime di un'attività. Questa metrica è una componente fondamentale dell'analisi delle performance. Aiuta a distinguere tra inefficienze causate da attività di lunga durata (tempo di elaborazione elevato) e ritardi dovuti all'attesa di risorse o informazioni (tempo di attesa elevato). Questo è cruciale per individuare la vera origine dei colli di bottiglia. Perché è importante Misura il tempo di lavoro attivo per un'attività, aiutando a distinguere tra attività inefficienti e lunghi tempi di attesa nell'analisi dei colli di bottiglia. Dove trovare Questo non è un campo del sistema sorgente. Viene calcolato durante la preparazione dei dati sottraendo lo 'StartTime' dall''EndTime' per ciascuna attività. Esempi 360086400300 | |||
Ultimo Aggiornamento Dati LastDataUpdate | Il timestamp dell'ultimo aggiornamento dei dati dal sistema sorgente. | ||
Descrizione Questo attributo indica quando il dataset è stato aggiornato l'ultima volta. Fornisce un punto di riferimento per la freschezza dei dati analizzati. Nelle dashboard e nell'analisi, viene utilizzato per informare gli utenti sulla tempestività delle informazioni. Aiuta a gestire le aspettative riguardo all'inclusione delle transazioni più recenti nella visualizzazione del processo. Perché è importante Informa gli utenti sulla freschezza dei dati, un'informazione fondamentale per interpretare l'analisi e prendere decisioni tempestive. Dove trovare Questo timestamp viene generato durante il processo di estrazione, trasformazione e caricamento dei dati (ETL) e di solito è memorizzato nei metadati del dataset. Esempi 2024-05-21T02:00:00Z | |||
Attività di Gestione dei Sinistri
| Activity | Descrizione | ||
|---|---|---|---|
Decisione sul Sinistro Presa | Questa attività rappresenta la decisione ufficiale sul sinistro, come 'Approvato', 'Parzialmente Approvato' o 'Negato'. Questo è un traguardo cruciale dedotto da un cambiamento dello stato di decisione finale. | ||
Perché è importante Questa è una tappa fondamentale nel processo decisionale. Il tempo impiegato per raggiungere questo punto e l'esito della decisione sono elementi centrali per l'analisi del processo e il miglioramento dell'efficienza. Dove trovare Deducibile da una modifica in un campo dedicato alla 'Decisione sinistro' o allo 'Stato sinistro' a uno stato terminale come 'Approvato' o 'Rifiutato'. Viene acquisito il timestamp di questa modifica. Acquisisci Deducibile da un aggiornamento al campo di stato primario o di decisione del sinistro. Tipo di evento inferred | |||
Pagamento Autorizzato | Rappresenta l'approvazione formale dell'importo di liquidazione calcolato da versare. Spesso si tratta di un passaggio distinto che coinvolge un manager o un'autorità separata, registrato come una transazione di approvazione esplicita. | ||
Perché è importante Questo rappresenta un punto di controllo fondamentale e un potenziale collo di bottiglia prima dell'erogazione del pagamento. La durata che intercorre tra la 'Decisione sul Sinistro Presa' e questo punto è misurata dal KPI 'Tempo Medio di Approvazione del Sinistro'. Dove trovare Questo è tipicamente un evento esplicito all'interno di un workflow o di un modulo finanziario, dove un utente con permessi specifici approva il pagamento. Si troverebbe in un registro delle approvazioni. Acquisisci Un evento di approvazione esplicito registrato in un workflow o 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 Questo indica il completamento dell'obbligo finanziario per un sinistro approvato. Il tempo che intercorre tra 'Pagamento Autorizzato' e 'Pagamento Emesso' rivela l'efficienza del reparto finanziario. Dove trovare Catturato dalla tabella delle transazioni finanziarie in Duck Creek Claims, che registra tutti i pagamenti in uscita con un codice di transazione e un timestamp specifici. Acquisisci Viene creata una voce di log per una transazione finanziaria separata quando il pagamento viene elaborato. Tipo di evento explicit | |||
Sinistro Chiuso | Questa è l'attività finale, che segna la chiusura amministrativa della pratica del sinistro dopo che il pagamento è stato emesso o la pratica è stata liquidata. Viene registrata tramite l'aggiornamento finale dello stato a 'Chiuso'. | ||
Perché è importante Questa attività segna la conclusione positiva del processo. È il punto finale per il calcolo del 'Tempo di Ciclo Medio End-to-End del Sinistro' e di altre metriche chiave di durata. Dove trovare Deducibile dal timestamp della modifica dello stato finale a 'Chiuso' o 'Liquidato' nella tabella dati principale del sinistro. Acquisisci Deducibile dal fatto che lo stato finale del sinistro sia impostato su 'Chiuso'. Tipo di evento inferred | |||
Sinistro Presentato | Questo è il primo evento, che rappresenta la ricezione della Prima Notifica di Sinistro (FNOL) da parte dell'assicuratore. Viene tipicamente registrato come una transazione esplicita quando un agente o un assicurato inserisce le informazioni iniziali del sinistro nel sistema. | ||
Perché è importante Questa attività segna l'inizio dell'intero ciclo di vita del sinistro. Analizzare il tempo che intercorre tra questo evento e altri è fondamentale per comprendere la durata totale dell'elaborazione e l'efficienza di acquisizione. Dove trovare Questo è di solito un evento esplicito registrato in una tabella di log dei sinistri o FNOL quando un nuovo record di sinistro viene creato per la prima volta in Duck Creek Claims. Acquisisci Evento registrato alla creazione iniziale di un nuovo record di sinistro. Tipo di evento explicit | |||
Sinistro Rifiutato | Questa attività rappresenta una conclusione alternativa al processo in cui il sinistro viene ufficialmente negato. Questo viene registrato quando lo stato finale del sinistro è impostato su 'Negato' o 'Rifiutato'. | ||
Perché è importante Questo è un esito cruciale che richiede un'analisi separata. Comprendere il motivo e il momento in cui i sinistri vengono negati aiuta a migliorare i processi di acquisizione iniziale e a gestire la compliance. Dove trovare Deducibile dal timestamp della modifica dello stato finale del sinistro a uno stato 'Rifiutato', 'Respinto' o 'Chiuso senza pagamento' nella tabella dell'entità del sinistro. Acquisisci Deducibile dal fatto che lo stato finale del sinistro sia un motivo di rifiuto. Tipo di evento inferred | |||
Danno Valutato | Questa tappa fondamentale segna il momento in cui le riserve finanziarie vengono impostate o aggiornate in base ai risultati dell'indagine. Indica la stima dell'impatto finanziario del sinistro e viene registrato quando gli importi delle riserve vengono inseriti o adeguati. | ||
Perché è importante Questo è un punto di controllo finanziario cruciale all'interno del processo. Analizzare il momento in cui si verifica offre una chiara comprensione della velocità e dell'accuratezza della valutazione finanziaria. Dove trovare Questa è spesso una transazione finanziaria esplicita registrata nel log delle transazioni finanziarie del sinistro o nella tabella dello storico delle riserve all'interno di Duck Creek Claims. Acquisisci 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 di indagine formale del sinistro. Spesso è dedotta da un cambiamento dello stato del sinistro a 'In Indagine' o uno stato simile. | ||
Perché è importante Questo segna l'inizio di una fase ad alta intensità di risorse. Misurare la durata dell'indagine è fondamentale per il KPI 'Durata Media dell'Indagine' e contribuisce a gestire una parte critica del processo. Dove trovare Deducibile dal timestamp di un aggiornamento dello stato del sinistro a 'Indagine in corso' o 'Ispezione in attesa' nel campo principale dello stato del sinistro. Acquisisci Derivato da un cambiamento nello stato del sinistro che indica l'inizio delle attività di indagine. Tipo di evento inferred | |||
Indagine completata | Rappresenta la conclusione delle attività di indagine, una volta raccolti tutti i fatti necessari. Ciò si deduce tipicamente quando lo stato del sinistro passa da 'Sotto Indagine' a uno stato decisionale come 'Decisione in Sospeso'. | ||
Perché è importante Il completamento dell'indagine è un traguardo fondamentale che sblocca le fasi decisionali e di liquidazione. I ritardi in questa fase si ripercuotono significativamente sulle attività a valle. Dove trovare Deducibile dal timestamp di un aggiornamento dello stato del sinistro da uno stato di 'indagine' a uno stato di 'revisione' o 'decisione'. Acquisisci Derivato da un cambiamento nello stato del sinistro che indica la fine delle attività di indagine. Tipo di evento inferred | |||
Informazioni Aggiuntive Ricevute | Segna la ricezione delle informazioni richieste, che consente di proseguire la gestione del sinistro. Questo potrebbe essere registrato manualmente dal liquidatore o automaticamente se le informazioni vengono inviate tramite un portale digitale. | ||
Perché è importante Il tempo tra 'Informazioni Richieste' e 'Informazioni Ricevute' è un periodo di attesa critico. L'analisi di questa durata aiuta a identificare dipendenze esterne e colli di bottiglia nella comunicazione. Dove trovare Può essere un evento esplicito derivante dall'integrazione con un sistema di gestione documentale, o una registrazione manuale o un cambio di stato effettuato dal gestore del sinistro al ricevimento dei documenti. Acquisisci Evento registrato al caricamento di un documento o all'inserimento manuale da parte di un liquidatore. Tipo di evento explicit | |||
Informazioni Aggiuntive Richieste | Questa attività si verifica quando il perito determina che sono necessarie maggiori informazioni e invia una richiesta al titolare della polizza o a una terza parte. Spesso è un evento esplicito collegato al modulo di comunicazione o corrispondenza del sistema. | ||
Perché è importante L'alta frequenza di questa attività può indicare problemi nel processo iniziale di raccolta dati. Comporta anche tempi di attesa significativi, influenzando il tempo di ciclo complessivo. Dove trovare Catturato dai log relativi alle comunicazioni in uscita (es. lettere, email) o da una specifica transazione 'Richiesta di Informazioni' in Duck Creek Claims. Acquisisci Registrato quando viene generata una corrispondenza o un'attività per la richiesta di informazioni. Tipo di evento explicit | |||
Liquidatore Assegnato | Questo evento registra l'assegnazione di un gestore del sinistro alla pratica registrata. Il sistema traccia tale assegnazione, creando un chiaro punto di trasferimento di responsabilità e definendo la titolarità per l'intero ciclo di vita del sinistro. | ||
Perché è importante Cruciale per analizzare l'allocazione delle risorse, il carico di lavoro del perito e identificare i ritardi nell'assegnazione dei sinistri. È un punto di passaggio fondamentale che può introdurre tempi di attesa. Dove trovare Tracciato tramite un aggiornamento del campo 'Assigned Adjuster' nella tabella principale dei dati del sinistro. Uno storico o log di audit per questo campo fornisce il timestamp. Acquisisci Registrato nel registro di controllo quando il campo del liquidatore viene compilato o modificato. Tipo di evento explicit | |||
Liquidazione Calcolata | Dopo una decisione di approvazione, questa attività riguarda il calcolo dell'importo finale del risarcimento o del pagamento. Può essere un passaggio esplicito oppure dedotto dalla finalizzazione degli importi nel modulo finanziario del sistema. | ||
Perché è importante Questa attività è fondamentale per misurare il KPI 'Tasso di Rilavorazione della Liquidazione'. Molteplici occorrenze di questo evento per un singolo sinistro indicano inefficienze, errori o negoziazioni nella fase di liquidazione. Dove trovare Può essere una voce esplicita nel log delle transazioni o dedotta dagli aggiornamenti al campo 'Importo di Liquidazione' nei dati finanziari del sinistro. I log di audit su questo campo sono la fonte primaria. Acquisisci Evento registrato quando l'importo finale del pagamento viene calcolato e salvato. Tipo di evento explicit | |||
Revisione iniziale completata | Rappresenta il completamento della prima revisione completa del sinistro da parte del liquidatore assegnato. Ciò si deduce tipicamente quando lo stato del sinistro cambia dopo l'assegnazione, passando, ad esempio, da 'Assegnato' a 'In Revisione' o 'In Indagine'. | ||
Perché è importante Questa tappa fondamentale aiuta a misurare il tempo impiegato per la prima azione da parte di un gestore del sinistro e può indicare potenziali arretrati nel loro carico di lavoro. Rappresenta il primo importante punto di controllo a gestione umana. Dove trovare Deducibile da una modifica di stato nel campo 'stato del sinistro', ad esempio, una transizione a 'Revisione iniziale completata' o 'Informazioni in attesa'. Il timestamp di questa modifica di stato viene utilizzato. Acquisisci Deducibile da una modifica nel campo 'stato del sinistro' dopo l'assegnazione del perito. Tipo di evento inferred | |||
Sinistro Registrato | Segna l'accettazione formale e la registrazione del sinistro presentato, momento in cui viene assegnato ufficialmente un ID univoco al sinistro. Si tratta spesso di un evento di sistema automatizzato a seguito della convalida iniziale dei dati. | ||
Perché è importante Formalizza l'inizio del sinistro e attiva processi a valle come l'assegnazione del perito. Il tempo tra la presentazione e la registrazione può indicare problemi di qualità iniziale dei dati o di carico del sistema. Dove trovare Deducibile dal timestamp in cui viene generato l'ID sinistro primario e lo stato del sinistro passa da 'in sospeso' o 'inviato' a 'aperto' o 'registrato' nella tabella dell'entità del sinistro principale. Acquisisci Derivato dal timestamp di creazione del record del sinistro principale o da un cambio di stato a 'Aperto'. Tipo di evento inferred | |||
Guide all'Estrazione
Fasi
- Accedere alla Duck Creek Data Hub Configuration Utility: Effettuare il login all'ambiente Duck Creek e navigare all'applicazione Data Hub. Saranno necessarie le autorizzazioni appropriate per creare o modificare le configurazioni di esportazione dei dati.
- Creare un nuovo job di esportazione dati: All'interno della utility Data Hub, avviare il processo per creare un nuovo job di esportazione. Assegnargli un nome descrittivo, come ProcessMind_Claims_Event_Log_Export.
- Definire la sorgente dati: Configurare il job per connettersi al database SQL primario del Data Hub. Sarà necessario fornire il nome del server, il nome del database e le credenziali di un utente con accesso in lettura agli schemi pertinenti.
- Inserire la query di estrazione: Navigare alla sezione di definizione della query del job di esportazione. Copiare lo script completo dalla sezione query sottostante e incollarlo nell'editor di query.
- Impostare i parametri della query: Individuare la sezione parametri nella configurazione. Definire e impostare i valori per i parametri @StartDate e @EndDate a cui si fa riferimento nella query per specificare l'intervallo di date di estrazione desiderato. Ad esempio, '2023-01-01' e '2023-12-31'.
- Mappare le colonne di output: Configurare le impostazioni del file di output. Assicurarsi che le colonne definite nell'istruzione SELECT (ClaimId, ActivityName, EventTime, ecc.) siano mappate correttamente alle colonne nel file di output. I nomi delle intestazioni nel file di output devono corrispondere esattamente a questi nomi.
- Configurare il file di output: Specificare il formato di output come CSV. Impostare il delimitatore su una virgola (,) e la codifica dei caratteri su UTF-8 per garantire la compatibilità con ProcessMind.
- Definire la destinazione: Specificare il percorso del file o la posizione di rete in cui verrà salvato il file CSV generato. Assicurarsi che il sistema abbia i permessi di scrittura per questa posizione.
- Pianificare il job di esportazione: Configurare la pianificazione del job. Per un'analisi iniziale, è possibile eseguirlo manualmente. Per il monitoraggio continuo, impostare una pianificazione ricorrente (ad esempio, giornaliera o settimanale).
- Eseguire e recuperare il file: Eseguire il job per generare il file di log degli eventi. Una volta completato, recuperare il file CSV dalla destinazione specificata al punto 8.
- Preparare per l'upload: Prima di caricare su ProcessMind, aprire il file CSV per effettuare un controllo finale. Verificare che le intestazioni siano corrette, che il formato della data sia consistente (YYYY-MM-DD HH:MI:SS) e che i dati appaiano come previsto.
Configurazione
- Prerequisiti: È richiesto l'accesso al modulo Duck Creek Data Hub. L'utente o l'account di servizio che esegue il job di esportazione deve disporre dei permessi di lettura sulle tabelle del database sottostanti al Data Hub (es. [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory]).
- Configurazione 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 per acquisire un numero sufficiente di casi completati e in corso.
- Filtraggio: La query include un placeholder /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ all'interno della Common Table Expression (CTE). Decommentare e modificare questa riga per filtrare specifiche linee di business (es. 'Personal Auto', 'Commercial Property') per ridurre il volume di dati e focalizzare l'analisi.
- Ciclo di Refresh del Data Hub: Tieni presente la latenza dei dati del Data Hub. I dati non sono in tempo reale e vengono tipicamente aggiornati secondo una pianificazione (es. ogni notte). I dati estratti saranno aggiornati all'ultimo refresh completato del Data Hub.
- Formato di Output: Il job di esportazione deve essere configurato per produrre un file flat, preferibilmente CSV. Assicurati che il qualificatore di testo sia impostato su doppie virgolette (") per gestire eventuali virgole all'interno dei campi di dati.
a Query di Esempio config
`config
-- 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;
`