Il Suo template dati per la gestione dei sinistri
Il Suo template dati per la gestione dei sinistri
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione dei dati da Guidewire ClaimCenter
Attributi per la gestione dei sinistri
| Nome | Descrizione | ||
|---|---|---|---|
| ID del sinistro ClaimID | Identificativo univoco di ogni sinistro assicurativo, utilizzato come identificativo principale del caso. | ||
| Descrizione L’ID del sinistro è il riferimento fondamentale per analizzare il processo di gestione dei sinistri: identifica in modo univoco ogni caso, dall’invio alla chiusura. Collega tutte le attività, i documenti, i pagamenti e le comunicazioni associati, offrendo una visione completa e coerente del ciclo di vita del sinistro. Nel Process Mining, ogni evento del set di dati è associato a un ID del sinistro, così da poter ricostruire il flusso del processo dall’inizio alla fine. Questo è essenziale per analizzare i tempi di ciclo, individuare le varianti del processo e seguire il percorso di un sinistro tra reparti e periti diversi. Perché è importante È la chiave fondamentale che collega tutti gli eventi correlati e consente di ricostruire e analizzare l’intero percorso di un singolo sinistro. Dove reperirli È una chiave primaria in Guidewire ClaimCenter, generalmente presente come Claim.ClaimNumber o in un campo simile nell’entità principale Claim. Esempi 000-123-45678000-987-65432001-456-11223 | |||
| Nome dell’attività ActivityName | Nome dell’attività aziendale o dell’evento verificatosi in un determinato momento del ciclo di vita del sinistro. | ||
| Descrizione Questo attributo descrive una fase o una tappa specifica del processo di gestione dei sinistri, ad esempio «Sinistro creato», «Avvio dell’indagine» o «Pagamento emesso». La sequenza di queste attività per un determinato ID del caso costituisce il flusso del processo. L’analisi della sequenza, della frequenza e della durata delle attività è alla base del Process Mining. Consente di individuare i modelli di processo, i colli di bottiglia, i cicli di rilavorazione e le deviazioni del processo. Perché è importante Definisce le fasi del processo e consente di visualizzare le mappe di processo e analizzare il flusso del processo e i colli di bottiglia. Dove reperirli In genere, si ricava dalle tabelle degli eventi o dai registri di audit di ClaimCenter, associando specifici eventi di sistema o cambiamenti di stato a nomi di attività standardizzati. Esempi Sinistro creatoDecisione sulla responsabilità presaPagamento emessoSinistro chiuso | |||
| Ora dell’evento EventTime | La data e l’ora esatte in cui si è verificata l’attività. | ||
| Descrizione Questo timestamp indica il momento esatto in cui l’attività è stata registrata nel sistema. È un dato fondamentale per tutte le analisi dei processi basate sul tempo. L’ordinamento cronologico di EventTime per un singolo ID del caso consente di ricostruire il flusso del processo. La differenza di tempo tra eventi consecutivi serve a calcolare i tempi di ciclo, di attesa e di elaborazione, essenziali per analizzare le prestazioni, individuare i colli di bottiglia e monitorare gli SLA. Perché è importante Questo timestamp è essenziale per ordinare gli eventi, calcolare i tempi di ciclo e le durate e individuare i ritardi nel processo. Dove reperirli Si trova insieme ai dati degli eventi o delle attività nelle tabelle della cronologia o di audit di Guidewire ClaimCenter, spesso in un campo denominato «CreateTime» o «UpdateTime». Esempi 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| Causa del sinistro LossCause | La causa specifica dell’evento che ha provocato il danno, ad esempio collisione, incendio o danni causati dall’acqua. | ||
| Descrizione Questo attributo fornisce informazioni dettagliate sul motivo per cui è stato presentato il sinistro. La causa del danno determina spesso le fasi di indagine necessarie, il tipo di esperti richiesti e la complessità complessiva del sinistro. Analizzare il processo per causa del sinistro può far emergere schemi nascosti. Per esempio, i sinistri dovuti a danni causati dall’acqua potrebbero presentare più rilavorazioni o richiedere un maggiore coinvolgimento di specialisti rispetto ai sinistri per furto. Queste informazioni aiutano a definire procedure di gestione più mirate ed efficienti. Perché è importante Fornisce informazioni sulla natura del sinistro e consente di analizzare come le diverse cause del danno influiscano sul flusso e sulla durata del processo. Dove reperirli È un campo standard dell’entità Claim, in genere denominato «LossCause». Esempi CollisioneIncendioDanni causati dall’acquaFurto | |||
| Perito assegnato AssignedAdjuster | Il nome o l’ID dell’utente incaricato di gestire il sinistro o una specifica attività. | ||
| Descrizione Questo attributo identifica il perito responsabile del sinistro in un determinato momento. Il perito può essere assegnato all’intero sinistro o a singole attività al suo interno. L’analisi per perito assegnato è fondamentale per bilanciare i carichi di lavoro, gestire le prestazioni e individuare opportunità di formazione. Aiuta a rispondere a domande come: «Quali periti hanno il maggior numero di sinistri da gestire?», «Le prestazioni variano da un perito all’altro?» e «Il lavoro è distribuito in modo uniforme?». Perché è importante Tiene traccia del coinvolgimento degli utenti e consente di analizzare i carichi di lavoro, confrontare le prestazioni e individuare i colli di bottiglia legati alle risorse. Dove reperirli Disponibile nell’entità Claim o Exposure di ClaimCenter, spesso collegata all’oggetto User, ad esempio Claim.Assignee. Esempi j.doem.smiths.jones | |||
| Stato del sinistro ClaimStatus | Lo stato complessivo del sinistro al momento dell’evento, ad esempio aperto, chiuso o respinto. | ||
| Descrizione Questo attributo riflette lo stato generale del sinistro. Tra gli stati principali figurano «Aperto», «Chiuso», «Respinto» e «Riaperto». Lo stato finale del sinistro è un indicatore fondamentale del risultato. Tenere traccia dei cambiamenti di stato del sinistro aiuta a definire le tappe e i risultati principali del processo. Consente di individuare l’esito finale del sinistro, calcolare i tassi di rifiuto e analizzare la frequenza delle riaperture dopo la chiusura, spesso indicative di problemi nel processo o di insoddisfazione dei clienti. Perché è importante Indica l’esito del sinistro ed è essenziale per analizzare i tassi di rifiuto, le modalità di chiusura e la frequenza delle riaperture. Dove reperirli È un campo fondamentale dell’entità Claim, in genere denominato «State» o «Status». Esempi ApertoChiusoRespintoRiaperto | |||
| Tipo di sinistro ClaimType | La categoria del sinistro assicurativo, ad esempio auto, immobili o responsabilità civile. | ||
| Descrizione Il tipo di sinistro è una classificazione fondamentale, basata sul ramo assicurativo o sulla natura del danno. I diversi tipi di sinistro seguono spesso processi distinti, presentano livelli di complessità differenti e sono soggetti a normative diverse. Segmentare l’analisi del processo per tipo di sinistro è essenziale per ottenere informazioni significative. Consente di confrontare le prestazioni dei diversi rami assicurativi, individuare i colli di bottiglia specifici per ciascun tipo e adattare le iniziative di miglioramento alle caratteristiche di ogni categoria di sinistro. Perché è importante Consente di segmentare i sinistri, poiché le diverse tipologie, ad esempio auto e immobili, seguono spesso processi differenti e hanno obiettivi di prestazione diversi. Dove reperirli Ricavato dall’entità Policy o Claim in ClaimCenter, spesso in base al codice del ramo assicurativo (LOB). Esempi Auto privateImmobili commercialiResponsabilità civile generaleIndennizzo per infortuni sul lavoro | |||
| Data del sinistro LossDate | La data in cui si è verificato l’incidente o il danno che ha dato origine al sinistro. | ||
| Descrizione La data del sinistro è quella in cui si è verificato l’evento, ad esempio un incidente stradale o un danno a un immobile, per il quale viene presentata la richiesta di risarcimento. È diversa dalla data in cui il sinistro è stato segnalato o creato. L’intervallo tra la data del sinistro e l’attività «Sinistro creato», noto come ritardo nella segnalazione, è un KPI importante. Analizzarlo può fornire indicazioni sul comportamento dei clienti e sull’efficacia dei canali di prima segnalazione del sinistro. Perché è importante Fornisce un contesto essenziale sull’origine del sinistro e aiuta ad analizzare il ritardo nella segnalazione, ovvero il tempo che intercorre tra l’incidente e l’invio della richiesta. Dove reperirli È un campo data fondamentale dell’entità Claim, spesso denominato «LossDate». Esempi 2023-05-102023-04-202023-05-28 | |||
| Data obiettivo di risoluzione ResolutionTargetDate | La data entro cui si prevede di risolvere il sinistro, secondo gli SLA interni o normativi. | ||
| Descrizione La data obiettivo di risoluzione è la scadenza fissata per la chiusura del sinistro, spesso determinata da fattori quali la giurisdizione, il tipo di sinistro e le condizioni della polizza. Costituisce un valore di riferimento per misurare le prestazioni e la conformità. Questo attributo è fondamentale per creare Dashboard e KPI sul rispetto degli SLA. Confrontando la data effettiva dell’attività «Sinistro chiuso» con la data obiettivo, l’analisi può segnalare automaticamente i sinistri in ritardo, misurare la percentuale di chiusure puntuali e individuare i tipi di sinistro o i reparti che faticano a rispettare le scadenze. Perché è importante È il valore di riferimento per misurare il rispetto degli accordi sul livello del servizio (SLA) e individuare i sinistri a rischio di ritardo. Dove reperirli Può essere un campo personalizzato o un valore ricavato dalle regole aziendali configurate in ClaimCenter, eventualmente in relazione a specifiche metriche dei sinistri. Esempi 2023-06-142023-07-202023-08-28 | |||
| È automatizzato IsAutomated | Un indicatore che specifica se un’attività è stata eseguita automaticamente dal sistema o da un utente. | ||
| Descrizione Questo attributo booleano distingue le attività eseguite dal sistema, ad esempio la creazione automatica di riserve o la generazione di comunicazioni, da quelle svolte manualmente da un perito. Analizzare questo attributo è fondamentale per comprendere il livello di automazione del processo di gestione dei sinistri. Aiuta a individuare i punti in cui è più frequente l’intervento manuale, misurare l’efficacia delle iniziative di elaborazione automatizzata dall’inizio alla fine e trovare nuove opportunità di automazione, identificando le attività ripetitive e basate su regole che oggi vengono svolte da persone. Perché è importante Distingue le attività svolte dal sistema da quelle svolte da persone, un aspetto fondamentale per analizzare l’automazione e individuare i colli di bottiglia dovuti al lavoro manuale. Dove reperirli Spesso è necessario ricavarlo. Per esempio, gli eventi registrati da un utente di sistema generico possono essere contrassegnati come automatizzati. Esempi truefalse | |||
| È una rilavorazione IsRework | Un indicatore che specifica se un’attività fa parte di un ciclo di rilavorazione, ovvero un ritorno a una fase precedente del processo. | ||
| Descrizione Questo attributo calcolato contrassegna le attività che fanno parte di un ciclo di rilavorazione. Per esempio, se il processo passa da «Indagine completata» a «Avvio dell’indagine», la seconda attività «Avvio dell’indagine» viene contrassegnata come rilavorazione. Individuare le rilavorazioni è fondamentale per far emergere inefficienze del processo e problemi di qualità. La Dashboard sulla frequenza di rilavorazioni e rifiuti utilizza questa metrica per quantificare quanto spesso i sinistri si discostano dal percorso ottimale. Analizzare le cause delle rilavorazioni può migliorare notevolmente la qualità e la velocità del processo. Perché è importante Mette in evidenza le inefficienze del processo e i problemi di qualità, contrassegnando esplicitamente le attività che fanno parte di un ciclo di rilavorazione. Dove reperirli Viene calcolato nello strumento di Process Mining analizzando la sequenza delle attività per ciascun caso. Esempi truefalse | |||
| Giurisdizione JurisdictionState | Lo stato o la giurisdizione a cui è soggetto il sinistro e che ne determina i requisiti normativi. | ||
| Descrizione Questo attributo specifica la giurisdizione legale, ad esempio lo stato degli Stati Uniti, in cui viene gestito il sinistro. Le normative assicurative possono variare notevolmente da una giurisdizione all’altra e incidere sulle fasi richieste, sui tempi di comunicazione e sulla documentazione. È un attributo essenziale per monitorare la conformità. Analizzare il processo per giurisdizione consente di verificare il rispetto dei requisiti normativi specifici di ciascuno stato. Può inoltre spiegare le differenze nei tempi di ciclo o nei percorsi del processo dovute a vincoli legali, anziché a inefficienze operative. Perché è importante È fondamentale per l’analisi della conformità, poiché le normative variano da una giurisdizione all’altra e incidono sul processo di gestione dei sinistri. Dove reperirli È un campo standard dell’entità Claim, in genere denominato «JurisdictionState». Esempi CANYTXFL | |||
| Importo del pagamento PaymentAmount | L’importo effettivamente pagato per un’attività di pagamento. | ||
| Descrizione Questo attributo registra l’importo di ogni singolo pagamento effettuato per un sinistro. Nel corso del suo ciclo di vita, un sinistro può comportare più pagamenti. È essenziale per l’analisi finanziaria nell’ambito del Process Mining. Può essere utilizzato per calcolare l’importo totale pagato per ciascun sinistro, analizzare i tempi di approvazione dei pagamenti in base all’importo e collegare le inefficienze del processo ai risultati economici. Per esempio, i sinistri con tempi di ciclo lunghi potrebbero essere associati a pagamenti complessivi più elevati. Perché è importante Tiene traccia delle transazioni finanziarie relative a un sinistro e consente di analizzare gli importi dei pagamenti e il loro rapporto con le attività del processo. Dove reperirli Si trova nelle entità relative ai pagamenti collegate al sinistro, spesso in una tabella delle transazioni o degli assegni. Esempi 4500.00125000.00500.00 | |||
| Importo richiesto ClaimedAmount | L’importo totale inizialmente richiesto dall’assicurato. | ||
| Descrizione Questo attributo rappresenta il valore del danno dichiarato dal richiedente. Spesso si tratta di una stima iniziale, che può cambiare durante l’indagine e la definizione delle riserve. Analizzare l’importo richiesto aiuta a segmentare i sinistri in base all’impatto economico. I sinistri di importo elevato seguono spesso un processo più rigoroso e complesso rispetto a quelli di importo ridotto. Confrontare i processi per fasce di importo può rivelare opportunità per semplificare la gestione dei sinistri minori o applicare controlli più rigorosi a quelli di importo maggiore. Perché è importante Consente di segmentare i sinistri in base al valore economico, poiché quelli di importo elevato possono seguire processi diversi e più complessi. Dove reperirli Potrebbe non corrispondere a un singolo campo: può essere ricavato dalle stime iniziali del danno registrate nelle esposizioni. Esempi 5000.00150000.00750.50 | |||
| Ora di fine EndTime | Il timestamp che indica quando un’attività è stata completata. | ||
| Descrizione L’ora di fine indica il completamento di un’attività, soprattutto per quelle di cui è possibile misurare la durata, come «Indagine» o «Revisione dei documenti». Molte attività analizzate con il Process Mining sono istantanee, perciò è sufficiente StartTime; per quelle con un inizio e una fine distinti, invece, è preferibile registrare entrambi i timestamp. Questo attributo consente di calcolare con precisione il tempo di elaborazione dell’attività, distinguendolo dal tempo di attesa. Aiuta a individuare le attività che richiedono più tempo, anziché limitarsi a rilevare lunghe attese tra una fase e l’altra. Perché è importante Consente di misurare con precisione il tempo necessario per completare un’attività, distinguendo il tempo di elaborazione da quello di attesa. Dove reperirli Potrebbe essere necessario ricavarlo individuando un evento successivo che segni logicamente la conclusione dell’attività, ad esempio il passaggio di stato da «In corso» a «Completato». Esempi 2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z | |||
| Reparto Department | L’unità aziendale o il reparto responsabile della gestione dell’attività relativa al sinistro. | ||
| Descrizione Questo attributo indica il reparto o il team di appartenenza del perito assegnato, ad esempio «Sinistri auto», «Sinistri immobiliari» o «Unità investigazioni speciali». Fornisce un contesto organizzativo al processo. L’analisi per reparto è fondamentale per comprendere le prestazioni del processo a livello organizzativo. Aiuta a individuare i ritardi nei passaggi di consegne tra reparti, confrontare l’efficienza dei team e distribuire le risorse in modo più efficace nell’organizzazione che gestisce i sinistri. Perché è importante Fornisce un contesto organizzativo, consentendo di analizzare le prestazioni dei diversi team e mettendo in evidenza i problemi nei passaggi di consegne tra reparti. Dove reperirli Queste informazioni sono in genere associate al profilo dell’utente o del gruppo assegnato in ClaimCenter. Esempi Divisione sinistri autoUnità sinistri immobiliariUnità investigazioni speciali (SIU) | |||
| Richiesta ripetuta di informazioni RepeatedInfoRequestFlag | Un indicatore che specifica se l’attività «Informazioni aggiuntive richieste» si è verificata più di una volta per lo stesso sinistro. | ||
| Descrizione Questo indicatore booleano assume il valore true se per un sinistro si è verificata più di un’attività «Informazioni aggiuntive richieste». Spesso, questa situazione segnala inefficienze nella fase iniziale di raccolta delle informazioni. Questo attributo supporta direttamente il KPI sul tasso di richieste ripetute di informazioni. Aiuta a quantificare il problema della raccolta iniziale incompleta dei dati, che può causare ritardi significativi e insoddisfazione dei clienti. Analizzare i sinistri contrassegnati con questo indicatore può aiutare a migliorare le liste di controllo e le procedure per i periti, così da richiedere tutte le informazioni necessarie in un’unica volta. Perché è importante Individua le inefficienze dovute a una raccolta incompleta delle informazioni al primo tentativo, che causa ritardi e rilavorazioni. Dove reperirli Viene calcolato nello strumento di Process Mining contando le occorrenze dell’attività «Informazioni aggiuntive richieste» per ciascun caso. Esempi truefalse | |||
| Sistema di origine SourceSystem | Il sistema da cui sono stati estratti i dati. | ||
| Descrizione Questo attributo identifica l’origine dei dati degli eventi. In un’architettura aziendale moderna, gli eventi relativi ai sinistri possono provenire da più sistemi, ad esempio da un sistema centrale come Guidewire, da un sistema di gestione documentale o da un portale clienti. Specificare il sistema di origine è fondamentale per la governance dei dati, la risoluzione dei problemi di incoerenza e la comprensione dell’architettura tecnologica del processo. Aiuta a distinguere le fasi principali del processo dalle attività di supporto svolte nei sistemi periferici. Perché è importante Identifica l’origine dei dati, un’informazione fondamentale per la governance dei dati e per le analisi che coinvolgono più sistemi integrati. Dove reperirli In genere, è un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento dei dati (ETL). Esempi Guidewire ClaimCenter v10API del portale clientiDocumentum | |||
| Stato SLA SLAState | Indica se il sinistro è stato chiuso entro la data obiettivo di risoluzione. | ||
| Descrizione Questo attributo calcolato indica, con una categoria, il rispetto degli SLA per ciascun sinistro chiuso. Si ricava confrontando il timestamp dell’attività «Sinistro chiuso» con la «Data obiettivo di risoluzione». Questo attributo supporta direttamente la Dashboard sul rispetto della data obiettivo di risoluzione dei sinistri, semplificando l’analisi con categorie chiare come «Puntuale» o «In ritardo». Consente di applicare filtri e aggregare i dati per calcolare il tasso complessivo di rispetto degli SLA e approfondire le cause dei ritardi. Perché è importante Fornisce un esito chiaro e categorizzato sul rispetto degli SLA, facilitando il filtraggio, l’aggregazione e l’analisi delle chiusure puntuali. Dove reperirli Campo calcolato: IF (ActualCloseDate <= ResolutionTargetDate, 'Puntuale', 'In ritardo'). Esempi PuntualeIn ritardo | |||
| Tipo di polizza PolicyType | Il tipo specifico di polizza assicurativa in base alla quale è stato presentato il sinistro. | ||
| Descrizione Il tipo di polizza offre una classificazione più dettagliata rispetto al tipo di sinistro e specifica il prodotto assicurativo, ad esempio «Abitazione», «Responsabilità civile auto commerciale» o «Responsabilità civile informatica». Questo livello di dettaglio può rivelare differenze nei processi legate a specifici prodotti. Analizzare il processo per tipo di polizza aiuta a individuare inefficienze specifiche dei prodotti. Per esempio, i sinistri relativi a una polizza appena lanciata potrebbero seguire un processo meno consolidato e subire ritardi. I risultati dell’analisi possono orientare la progettazione dei prodotti e le iniziative di standardizzazione dei processi. Perché è importante Consente di analizzare il processo per specifici prodotti assicurativi e individuare differenze nella gestione legate alle caratteristiche della polizza. Dove reperirli Queste informazioni si trovano nell’entità Policy, collegata a Claim. Esempi Polizza multirischio per proprietari di abitazioniResponsabilità civile auto commercialeAssicurazione trasporti terrestri | |||
| Ultimo aggiornamento dei dati LastDataUpdate | Il timestamp che indica quando i dati sono stati aggiornati o estratti per l’ultima volta dal sistema di origine. | ||
| Descrizione Questo attributo indica il timestamp dell’estrazione più recente dei dati dal sistema di origine. È un campo di metadati essenziale per capire quanto siano aggiornate le analisi. Le Dashboard e le analisi dovrebbero mostrare questa informazione in modo ben visibile, così che gli utenti sappiano a quando risalgono i dati. In questo modo è possibile valutare se le informazioni riflettono lo stato attuale delle attività o si basano su dati meno recenti. Perché è importante Indica quanto sono aggiornati i dati, aiutando gli utenti a capire quanto siano attuali le analisi del processo. Dove reperirli Questo valore viene generato e memorizzato durante il processo ETL e rappresenta il timestamp del caricamento dei dati. Esempi 2024-07-28T04:00:00Z2024-07-29T04:00:00Z | |||
Attività di gestione dei sinistri
| Attività | Descrizione | ||
|---|---|---|---|
| Esposizione creata | Questa attività indica la creazione di un’esposizione, che rappresenta una specifica potenziale passività o tipologia di perdita associata al sinistro, ad esempio danni al veicolo o lesioni. In Guidewire è un evento esplicito. | ||
| Perché è importante Le esposizioni sono fondamentali per segmentare e analizzare i sinistri. Monitorarne la creazione aiuta a comprendere le variazioni del processo in base alla complessità del sinistro e alla tipologia di perdita. Dove reperirli L’evento viene registrato a partire da CreateTime di un nuovo record nella tabella cc_exposure. Ogni record è collegato a un singolo ID del sinistro. Acquisizione Individuare la data e l’ora di creazione di un nuovo record nella tabella dell’entità Exposure. Tipo di evento explicit | |||
| Pagamento approvato | Indica l’approvazione formale di un pagamento di liquidazione. È un evento di audit cruciale e viene registrato esplicitamente quando un utente autorizzato approva la transazione. | ||
| Perché è importante Questa tappa fondamentale consente di procedere con il pagamento finale. Analizzare i tempi prima e dopo questa attività aiuta a isolare i ritardi causati dai flussi di approvazione o dalla disponibilità dei responsabili. Dove reperirli Spesso è un evento esplicito registrato nella tabella cc_history e associato a un’entità cc_check o cc_transaction, che documenta il passaggio di stato da "Pending Approval" ad "Approved". Acquisizione Monitorare il passaggio di stato ad "Approved" per una specifica transazione di pagamento. Tipo di evento explicit | |||
| Pagamento emesso | Questa attività segna la fase finale del processo di pagamento: il pagamento viene emesso ufficialmente e inviato al sistema finanziario. È una transazione finanziaria esplicita e registrata. | ||
| Perché è importante Questa attività è fondamentale per misurare l’efficienza dell’invio dei pagamenti. Aiuta a distinguere i ritardi di approvazione da quelli relativi all’effettiva erogazione dei fondi. Dove reperirli L’evento viene registrato a partire da IssueDate o da un passaggio di stato a "Issued" o "Submitted" nell’entità cc_check o cc_transaction. Spesso è un evento esplicito con data e ora. Acquisizione Individuare IssueDate o la data e l’ora del passaggio di stato a "Issued" nel record del pagamento. Tipo di evento explicit | |||
| Prima riserva impostata | Indica la creazione della prima transazione di riserva finanziaria per un’esposizione, che stima il costo potenziale del sinistro. È un evento finanziario cruciale e viene registrato esplicitamente. | ||
| Perché è importante Questa tappa è fondamentale per l’analisi finanziaria e per capire con quale rapidità viene valutata la potenziale passività. I ritardi possono incidere sulla pianificazione e sulla rendicontazione finanziaria. Dove reperirli L’evento viene registrato quando viene creato il primo record cc_reserveline associato a un’esposizione del sinistro. La data e l’ora dell’evento corrispondono a CreateTime della transazione. Acquisizione Individuare la data e l’ora di creazione più remote tra tutte le righe di riserva relative alle esposizioni di un determinato sinistro. Tipo di evento explicit | |||
| Sinistro chiuso | Indica la chiusura del sinistro dopo il completamento di tutte le attività e i pagamenti. È il principale evento di conclusione positiva e si deduce da una modifica dello stato principale del sinistro. | ||
| Perché è importante In quanto evento finale principale, questa attività è essenziale per calcolare il tempo di ciclo dall’inizio alla fine e misurare il rispetto degli SLA. Indica il completamento del ciclo di vita del sinistro. Dove reperirli Si deduce dal passaggio del campo State della tabella cc_claim a "Closed". La data e l’ora dell’evento corrispondono a CloseDate nel record del sinistro. Acquisizione Individuare quando il campo di stato principale del sinistro viene aggiornato a "Closed". Tipo di evento inferred | |||
| Sinistro creato | Questa attività indica la prima denuncia del sinistro (FNOL) e la creazione ufficiale di una nuova pratica in Guidewire ClaimCenter. Viene registrata esplicitamente quando una nuova entità Claim viene salvata per la prima volta nel database. | ||
| Perché è importante In quanto evento iniziale principale, questa attività è essenziale per misurare il tempo di ciclo del sinistro dall’inizio alla fine. Costituisce la base di riferimento per tutti i successivi KPI di prestazione e durata. Dove reperirli È un evento esplicito, registrato a partire da CreateTime della tabella cc_claim. L’evento viene attivato dalla creazione di un nuovo record con un ID del sinistro univoco. Acquisizione Individuare la data e l’ora di creazione del nuovo record nella tabella dell’entità Claim di base. Tipo di evento explicit | |||
| Sinistro respinto | Indica la decisione definitiva di respingere un sinistro e costituisce il punto terminale del processo. Si deduce dal passaggio del sinistro a uno stato di chiusura con motivazione "Denied". | ||
| Perché è importante È un evento cruciale per l’esito del processo. Analizzare la frequenza dei rifiuti, le relative motivazioni e i percorsi che li precedono aiuta a individuare problemi nella ricezione del sinistro, nell’indagine o nell’interpretazione della polizza. Dove reperirli Si deduce dal passaggio del campo State della tabella cc_claim a "Closed", insieme al valore "Denied" o a un valore simile nel campo CloseReason. La data e l’ora dell’evento corrispondono a CloseDate. Acquisizione Filtrare i passaggi di stato dei sinistri a "Closed" per i quali il codice motivazione indica un rifiuto. Tipo di evento inferred | |||
| Decisione sulla responsabilità presa | Indica il momento in cui viene determinata la responsabilità o la colpa per un’esposizione. In genere si deduce da una modifica dello stato dell’entità Exposure. | ||
| Perché è importante È una tappa decisionale cruciale, che precede le fasi di liquidazione e pagamento. Analizzare il tempo necessario per arrivare a questa decisione aiuta a individuare i colli di bottiglia nelle fasi di indagine e valutazione. Dove reperirli Si deduce dalla tabella cc_history monitorando una modifica dello stato o di un campo personalizzato relativo alla responsabilità nell’entità cc_exposure. La data e l’ora del record della cronologia indicano il momento dell’evento. Acquisizione Monitorare i registri di audit o le tabelle della cronologia per rilevare gli aggiornamenti allo stato o alla responsabilità dell’esposizione. Tipo di evento inferred | |||
| Importo della liquidazione calcolato | Questa attività indica il momento in cui viene determinato l’importo della liquidazione, prima che il pagamento sia approvato. Si può dedurre dalla creazione di un pagamento con stato "Pending Approval". | ||
| Perché è importante Segna il passaggio dalla valutazione al pagamento. È il punto di partenza per misurare il KPI "Tempo di attraversamento per l’autorizzazione del pagamento" e individuare i ritardi nella catena di approvazione. Dove reperirli Si deduce da CreateTime di un record cc_check o cc_transaction il cui stato iniziale è "Pending Approval" o uno stato simile precedente ad "Approved". Acquisizione Individuare la creazione di un record di pagamento o transazione con uno stato precedente all’approvazione. Tipo di evento inferred | |||
| Indagine avviata | Indica l’inizio formale della fase di indagine per un sinistro o un’esposizione. Spesso si deduce dalla creazione della prima "Activity" (attività) relativa all’indagine in Guidewire. | ||
| Perché è importante Questa attività segna l’inizio di una fase cruciale, spesso lunga. Analizzare il tempo che precede l’avvio dell’indagine e la durata dell’indagine stessa permette di individuare i principali colli di bottiglia. Dove reperirli Si deduce da CreateTime di un record cc_activity il cui ActivityPattern è relativo all’indagine, ad esempio "Initial Investigation" o "Contact Witness". Acquisizione Individuare la prima creazione di un’attività con uno schema o un oggetto relativo all’indagine. Tipo di evento inferred | |||
| Informazioni aggiuntive ricevute | Indica il completamento di una richiesta di informazioni aggiuntive. Viene registrato quando la "Activity" (attività) corrispondente alla richiesta di informazioni viene contrassegnata come "Completed". | ||
| Perché è importante Questo evento conclude la misurazione del KPI "Tempo di ciclo per la raccolta di informazioni aggiuntive". Gli intervalli prolungati tra la richiesta e la ricezione sono una causa frequente di ritardo nella gestione dei sinistri. Dove reperirli L’evento viene registrato a partire da CloseTime di un record cc_activity il cui ActivityPattern riguarda una richiesta di informazioni. Lo stato dell’attività deve essere "Completed". Acquisizione Individuare la data e l’ora di completamento di un’attività per richiedere informazioni a una parte esterna. Tipo di evento explicit | |||
| Informazioni aggiuntive richieste | Indica una richiesta inviata al richiedente o a una terza parte per ottenere ulteriori informazioni o documenti. In genere viene registrata come "Activity" (attività) esplicita creata in ClaimCenter. | ||
| Perché è importante Questa attività segna l’inizio della misurazione del KPI "Tempo di ciclo per la raccolta di informazioni aggiuntive". Una frequenza elevata può indicare procedure FNOL incomplete o una raccolta delle informazioni inefficiente. Dove reperirli L’evento viene registrato a partire da CreateTime di un record cc_activity il cui ActivityPattern riguarda la richiesta di documenti o informazioni a una parte esterna. Acquisizione Individuare la creazione di un’attività per richiedere informazioni a una parte esterna. Tipo di evento explicit | |||
| Sinistro assegnato | Indica l’assegnazione di un sinistro a un utente specifico (perito) o a un gruppo incaricato della gestione. In genere si deduce monitorando le modifiche ai campi di assegnazione dell’entità Claim. | ||
| Perché è importante Monitorare le assegnazioni è fondamentale per analizzare il carico di lavoro dei periti, individuare i colli di bottiglia nell’instradamento e misurare il tempo necessario al responsabile assegnato per compiere la prima azione. Dove reperirli Si deduce dalla tabella cc_history monitorando le modifiche ai campi AssignedUser o AssignedGroup associati a uno specifico ID del sinistro. La data e l’ora della modifica indicano quando si è verificato l’evento. Acquisizione Monitorare i registri di audit o le tabelle della cronologia per rilevare gli aggiornamenti ai campi di assegnazione del sinistro. Tipo di evento inferred | |||
| Sinistro riaperto | Indica il passaggio di un sinistro dallo stato "Closed" allo stato "Open" per svolgere ulteriori attività. Si deduce da una specifica sequenza di modifiche di stato. | ||
| Perché è importante Questa attività indica una rilavorazione. Un numero elevato di sinistri riaperti segnala problemi nella liquidazione iniziale, danni non rilevati o altre criticità del processo, con conseguente aumento dei costi e dell’inefficienza. Dove reperirli Si deduce dalla tabella cc_history individuando il passaggio del campo State dell’entità cc_claim da "Closed" a "Open" o a un altro stato attivo. Acquisizione Monitorare il campo di stato principale del sinistro per rilevare il passaggio da uno stato chiuso a uno aperto. Tipo di evento inferred | |||
Guide per l’estrazione
Passaggi
- Verifica dei prerequisiti: verifichi di disporre delle autorizzazioni e delle credenziali necessarie per accedere in sola lettura al database del data mart di Guidewire DataHub / InfoCenter. Si assicuri che i processi ETL che alimentano il data mart dei sinistri siano eseguiti correttamente e che i dati siano aggiornati.
- Connessione al database: utilizzi un client SQL standard, ad esempio DBeaver, SQL Server Management Studio o uno strumento analogo, per connettersi al server del database del data mart.
- Esplorazione dello schema: prima di eseguire la query completa, acquisisca familiarità con lo schema del data mart. Individui le tabelle principali relative a sinistri, esposizioni, attività e transazioni finanziarie. In genere, i nomi delle tabelle principali terminano con suffissi come _dim (dimensione) e _fact (fatto). Questo passaggio Le consentirà di verificare i nomi segnaposto di tabelle e colonne nello script fornito.
- Preparazione della query SQL: copi l’intero script SQL fornito nella sezione della query nell’editor del client SQL.
- Personalizzazione dei segnaposto: riveda attentamente lo script e sostituisca tutti i valori segnaposto. Sono inclusi il nome del database o dello schema (ad es. [YourDataMart]), i parametri dell’intervallo di date ('[StartDate]', '[EndDate]') e gli eventuali valori di configurazione specifici del sistema (ad es. modelli di attività e codici di stato).
- Esecuzione della query: esegua la query SQL modificata sul data mart. La durata può variare in base all’intervallo di date selezionato e al volume di dati del sistema.
- Verifica iniziale dei dati: al termine della query, controlli le prime centinaia di righe del risultato. Verifichi che le colonne ClaimID, ActivityName ed EventTime contengano i valori previsti e che siano presenti diversi tipi di attività.
- Esportazione in CSV: esporti l’intero risultato dal client SQL in un file CSV. Assegni al file un nome descrittivo, ad esempio guidewire_claimcenter_event_log.csv.
- Preparazione per ProcessMind: verifichi che il file CSV sia salvato con codifica UTF-8 e contenga una riga di intestazione corrispondente agli alias delle colonne nella query SQL. Il file è ora pronto per essere caricato in ProcessMind.
Configurazione
- Origine dei dati: data mart dei sinistri di Guidewire DataHub/InfoCenter. Si tratta di un database dimensionale preaggregato, progettato per la reportistica e l’analisi e distinto dal database di produzione ClaimCenter in tempo reale.
- Autorizzazioni necessarie: accesso in sola lettura al database SQL che ospita il data mart. Sono necessari nome utente, password e dettagli di connessione, come indirizzo del server e nome del database.
- Stato dei processi ETL: l’accuratezza dell’estrazione dipende dalla corretta esecuzione e dalla puntualità dei processi ETL di Guidewire che alimentano il data mart. Verifichi l’ora dell’ultima esecuzione completata correttamente per valutare l’aggiornamento dei dati.
- Filtro per intervallo di date: la query fornita include clausole WHERE con i segnaposto '[StartDate]' e '[EndDate]'. Per gestire le prestazioni, si consiglia di iniziare con un intervallo limitato, ad esempio 3-6 mesi. Il filtro per data viene applicato a CreateTime del sinistro.
- Valori specifici della configurazione: Guidewire è altamente configurabile. Dovrà modificare i valori nelle clausole WHERE in base alla configurazione della Sua organizzazione. Sono inclusi:
- i nomi di ActivityPattern (ad es. 'fnol', 'investigation', 'Request additional information')
- i codici ClaimStatus, ExposureStatus e CloseReason (ad es. 'denied', 'closed')
- i codici TransactionStatus (ad es. 'pendingapproval', 'approved', 'issued')
- Prestazioni: le query su tabelle di cronologia o di audit di grandi dimensioni possono richiedere molte risorse. Per insiemi di dati molto estesi, si consiglia di eseguire la query nelle fasce orarie di minore attività. Verifichi che le colonne ClaimID o ClaimNumber siano indicizzate nelle tabelle pertinenti.
Query di esempio sql
-- This query extracts a process mining event log for claims processing from a Guidewire DataHub/InfoCenter Data Mart.
-- Replace placeholders: [YourDataMart], [StartDate], [EndDate], and any configuration-specific string literals.
WITH ClaimHistory AS (
-- Pre-process claim history to identify status changes, especially for Reopened events.
SELECT
ClaimID,
Status,
UpdateTime,
LAG(Status, 1) OVER (PARTITION BY ClaimID ORDER BY UpdateTime) AS PreviousStatus
FROM [YourDataMart].[dbo].[ClaimHistory_dim] -- Placeholder for claim history/audit table
),
BaseClaims AS (
-- Select the set of claims to be analyzed based on a date range.
SELECT
c.ClaimID AS ClaimPublicID, -- Using PublicID as it's often the user-facing ID
c.ClaimNumber AS ClaimID,
c.AssignedAdjusterName AS AssignedAdjuster,
c.PolicyType AS ClaimType,
c.ClaimStatus AS ClaimStatus,
c.LossCause AS LossCause,
c.CreateTime
FROM [YourDataMart].[dbo].[Claim_dim] c
WHERE c.CreateTime >= '[StartDate]' AND c.CreateTime < '[EndDate]'
)
-- 1. Claim Created
SELECT
bc.ClaimID AS ClaimID,
'Claim Created' AS ActivityName,
bc.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
UNION ALL
-- 2. Claim Assigned
-- This captures the first assignment event from the history table.
SELECT
bc.ClaimID,
'Claim Assigned' AS ActivityName,
MIN(ch.UpdateTime) AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ClaimHistory_dim] ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.EventType = 'Assignment' -- Assumes an EventType column exists to identify assignment changes
GROUP BY bc.ClaimID, bc.AssignedAdjuster, bc.ClaimType, bc.ClaimStatus, bc.LossCause
UNION ALL
-- 3. Exposure Created
SELECT
bc.ClaimID,
'Exposure Created' AS ActivityName,
e.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Exposure_dim] e ON bc.ClaimPublicID = e.ClaimID
UNION ALL
-- 4. Initial Reserve Set
-- Finds the very first reserve transaction for any exposure on the claim.
SELECT
x.ClaimID,
'Initial Reserve Set' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY t.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Reserve'
) x
WHERE x.rn = 1
UNION ALL
-- 5. Investigation Started
-- Finds the creation of the first investigation-related activity.
SELECT
x.ClaimID,
'Investigation Started' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY a.CreateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Investigation%'
) x
WHERE x.rn = 1
UNION ALL
-- 6. Additional Info Requested
SELECT
bc.ClaimID,
'Additional Info Requested' AS ActivityName,
a.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%'
UNION ALL
-- 7. Additional Info Received
SELECT
bc.ClaimID,
'Additional Info Received' AS ActivityName,
a.CompletionTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Activity_dim] a ON bc.ClaimPublicID = a.ClaimID
WHERE a.ActivityPatternName LIKE '%Request%Information%' AND a.CompletionTime IS NOT NULL
UNION ALL
-- 8. Liability Decision Made
-- Captures when an exposure's liability decision is first set.
SELECT
x.ClaimID,
'Liability Decision Made' AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
bc.ClaimID,
eh.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause,
ROW_NUMBER() OVER(PARTITION BY bc.ClaimID ORDER BY eh.UpdateTime) as rn
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[ExposureHistory_dim] eh ON bc.ClaimPublicID = eh.ClaimID
WHERE eh.LiabilityDecision IS NOT NULL AND eh.PreviousLiabilityDecision IS NULL -- Captures the first time it was set
) x
WHERE x.rn = 1
UNION ALL
-- 9. Settlement Calculated
-- Captures the creation of a payment transaction that is pending approval.
SELECT
bc.ClaimID,
'Settlement Calculated' AS ActivityName,
t.CreateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.TransactionStatus = 'PendingApproval'
UNION ALL
-- 10. Payment Approved
SELECT
bc.ClaimID,
'Payment Approved' AS ActivityName,
t.ApprovalDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.ApprovalDate IS NOT NULL AND t.TransactionStatus = 'Approved'
UNION ALL
-- 11. Payment Issued
SELECT
bc.ClaimID,
'Payment Issued' AS ActivityName,
t.IssueDate AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
bc.ClaimStatus,
bc.LossCause
FROM BaseClaims bc
JOIN [YourDataMart].[dbo].[Transaction_fact] t ON bc.ClaimPublicID = t.ClaimID
WHERE t.TransactionType = 'Payment' AND t.IssueDate IS NOT NULL AND t.TransactionStatus = 'Issued'
UNION ALL
-- 12. Claim Denied
SELECT
bc.ClaimID,
'Claim Denied' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Denied' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 13. Claim Closed
SELECT
bc.ClaimID,
'Claim Closed' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Closed' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.Status = 'Closed' AND ch.PreviousStatus <> 'Closed'
AND NOT EXISTS (SELECT 1 FROM [YourDataMart].[dbo].[Claim_dim] c2 WHERE c2.ClaimID = bc.ClaimPublicID AND c2.CloseReason = 'Denied')
UNION ALL
-- 14. Claim Reopened
SELECT
bc.ClaimID,
'Claim Reopened' AS ActivityName,
ch.UpdateTime AS EventTime,
bc.AssignedAdjuster,
bc.ClaimType,
'Open' AS ClaimStatus, -- Overriding status for clarity
bc.LossCause
FROM BaseClaims bc
JOIN ClaimHistory ch ON bc.ClaimPublicID = ch.ClaimID
WHERE ch.PreviousStatus = 'Closed' AND ch.Status <> 'Closed'; Passaggi
- Verifichi che la Sua organizzazione disponga di una condivisione dati Snowflake attiva di Guidewire Cloud Data Access (CDA) per l’ambiente ClaimCenter e richieda all’amministratore di Guidewire Cloud l’identificativo dell’account Snowflake, il database, lo schema, il warehouse, il ruolo, il metodo di autenticazione e la configurazione di rete autorizzata.
- Verifichi gli oggetti e le colonne CDA esposti nella condivisione. Gli schemi CDA e i nomi delle colonne possono variare in base al tenant, alla versione, alla configurazione e al modello di condivisione dei dati. Sostituisca ogni segnaposto tra parentesi quadre nella query con l’oggetto corrispondente del Suo ambiente. Non presuma che i nomi delle entità operative di ClaimCenter siano esposti in Snowflake senza modifiche.
- Individui le fonti per la creazione dei sinistri, la cronologia delle assegnazioni, la creazione delle esposizioni, le transazioni di riserva, le attività, la cronologia degli stati delle esposizioni, la cronologia degli stati dei pagamenti e la cronologia degli stati dei sinistri. Se la condivisione non espone tabelle di cronologia o record di audit, configuri una fonte approvata che conservi, per ogni transizione di stato richiesta, il valore precedente, il nuovo valore, la data e ora dell’evento e l’autore.
- Si connetta alla condivisione Snowflake CDA tramite un client, un foglio di lavoro, un notebook o uno strumento di esecuzione SQL autorizzato. Ove possibile, utilizzi un ruolo di sola lettura. Imposti nella query le date e le ore di inizio e fine dell’analisi usando [Start timestamp] e [End timestamp] e applichi eventuali filtri approvati per azienda o unità aziendale tramite [Company filter].
- Sostituisca i segnaposto delle fonti nella query con nomi di oggetti e colonne CDA verificati. La query genera esplicitamente righe per tutte le 14 attività richieste: Claim Created, Claim Assigned, Exposure Created, Initial Reserve Set, Investigation Started, Additional Info Requested, Additional Info Received, Liability Decision Made, Settlement Calculated, Payment Approved, Payment Issued, Claim Denied, Claim Closed e Claim Reopened.
- Esegua la query e controlli lo schema del risultato. L’output deve contenere ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus e LossCause. Per ProcessMind sono obbligatori ClaimID, ActivityName ed EventTime. Mantenga una riga per ogni evento e non aggreghi gli eventi per sinistro.
- Convalidi le date e le ore, le transizioni di stato, le modifiche di assegnazione, la gestione dei duplicati e il numero di attività prima dell’esportazione. Verifichi che le date e le ore degli eventi utilizzino un fuso orario coerente e che gli eventi con la stessa data e ora restino su righe separate quando corrispondono ad attività aziendali distinte.
- Esporti il risultato in formato CSV con codifica UTF-8 o in un altro formato tabellare supportato da ProcessMind. Mappi ClaimID come identificativo del caso, ActivityName come attività ed EventTime come data e ora dell’evento. Mantenga gli attributi consigliati come attributi aggiuntivi degli eventi e carichi il file in ProcessMind senza aggiungere attività dedotte che non rientrano in questa estrazione.
Configurazione
- Connessione e autorizzazioni: utilizzi la condivisione dati Snowflake fornita da Guidewire tramite un account, un ruolo, un warehouse e un percorso di rete Snowflake autorizzati. Dal punto di vista dell’utente, CDA consente solo la lettura. L’accesso necessario dipende dalla configurazione del tenant e può includere l’autorizzazione a interrogare il database condiviso e gli schemi o le viste specifici.
- Configurazione degli oggetti di origine: sostituisca tutti i riferimenti alle fonti tra parentesi quadre con oggetti verificati nella condivisione CDA. La query non presume intenzionalmente l’esistenza di nomi universali per tabelle o colonne ClaimCenter, poiché le strutture CDA esposte variano in base alla versione e al tenant.
- Intervallo di date: inizi con un periodo da tre a sei mesi per la convalida e l’analisi operativa. Utilizzi un intervallo più ampio solo dopo aver verificato la capacità del warehouse, la conservazione della cronologia degli eventi e la durata accettabile della query. Filtri i record di origine in base alla data e ora dell’evento pertinente, non solo alla data di creazione del sinistro, per non escludere le attività successive.
- Output obbligatorio: ClaimID, ActivityName ed EventTime devono essere presenti e non nulli per ogni riga di evento. ActivityName deve utilizzare le etichette esatte previste dal modello di processo ProcessMind.
- Output consigliato: includa AssignedAdjuster, ClaimType, ClaimStatus e LossCause. Se disponibili, questi valori possono provenire dall’istantanea relativa al momento dell’evento. Se sono esposti solo i valori dello stato corrente, documenti questa limitazione, poiché gli attributi storici potrebbero non corrispondere ai valori presenti al momento dell’evento.
- Filtri: applichi [Company filter] solo dopo aver verificato la colonna specifica del tenant relativa ad azienda, organizzazione, unità aziendale o entità giuridica. Non filtri per tipo di documento, a meno che la configurazione di ClaimCenter non esponga un campo verificato relativo al tipo di documento e pertinente alle attività richieste.
- Cronologia degli eventi: per individuare le transizioni sono necessari dati storici o di audit relativi ad assegnazioni, indagini, richieste di informazioni, decisioni sulla responsabilità, stati dei pagamenti e riaperture dei sinistri. Le sole tabelle dello stato corrente non consentono di ricostruire in modo affidabile gli eventi precedenti.
- Eliminazione dei duplicati: ove disponibile, utilizzi un identificativo verificato dell’evento di origine. La query usa ROW_NUMBER solo come misura di sicurezza configurabile. Non elimini i duplicati basandosi esclusivamente su ClaimID e data e ora quando possono verificarsi legittimamente attività distinte nello stesso momento.
- Prestazioni: limiti l’intervallo di date, selezioni solo le colonne necessarie, filtri ogni fonte in base alla data e ora dell’evento e utilizzi un warehouse Snowflake di dimensioni adeguate. Per volumi elevati, valuti la creazione di una vista degli eventi convalidata o un’estrazione incrementale.
- Fuso orario: uniformi EventTime a un unico fuso orario documentato. Prima di caricare l’Event Log, verifichi se le date e le ore CDA sono memorizzate in UTC, nell’ora locale o in varianti del tipo timestamp di Snowflake.
- Prerequisiti: verifichi che la condivisione includa i dati richiesti di ClaimCenter relativi a finanze, attività, assegnazioni, esposizioni, pagamenti e cronologia degli stati e che le politiche di conservazione mantengano le transizioni storiche necessarie.
Query di esempio sql
WITH
params AS (
SELECT
TO_TIMESTAMP_TZ('[Start timestamp]') AS start_ts,
TO_TIMESTAMP_TZ('[End timestamp]') AS end_ts
),
claim_created AS (
SELECT
CAST(c.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Created' AS ActivityName,
CAST(c.[Claim created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(c.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(c.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(c.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(c.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(c.[Claim event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim source object] c
CROSS JOIN params p
WHERE c.[Claim created timestamp column] >= p.start_ts
AND c.[Claim created timestamp column] < p.end_ts
AND [Company filter]
),
claim_assigned AS (
SELECT
CAST(h.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Assigned' AS ActivityName,
CAST(h.[Assignment event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(h.[New assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(h.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(h.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(h.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(h.[Assignment event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim assignment history object] h
CROSS JOIN params p
WHERE h.[Assignment event timestamp column] >= p.start_ts
AND h.[Assignment event timestamp column] < p.end_ts
AND h.[New assigned adjuster column] IS DISTINCT FROM h.[Previous assigned adjuster column]
AND [Company filter]
),
exposure_created AS (
SELECT
CAST(e.[Claim ID column] AS VARCHAR) AS ClaimID,
'Exposure Created' AS ActivityName,
CAST(e.[Exposure created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(e.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(e.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(e.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(e.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(e.[Exposure event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure source object] e
CROSS JOIN params p
WHERE e.[Exposure created timestamp column] >= p.start_ts
AND e.[Exposure created timestamp column] < p.end_ts
AND [Company filter]
),
initial_reserve_set AS (
SELECT
CAST(r.[Claim ID column] AS VARCHAR) AS ClaimID,
'Initial Reserve Set' AS ActivityName,
CAST(r.[Reserve transaction timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(r.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(r.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(r.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(r.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(r.[Reserve transaction identifier column] AS VARCHAR) AS SourceEventID
FROM [Your reserve transaction source object] r
CROSS JOIN params p
WHERE r.[Reserve transaction timestamp column] >= p.start_ts
AND r.[Reserve transaction timestamp column] < p.end_ts
AND r.[Reserve transaction sequence or first reserve indicator column] = [Value identifying first reserve]
AND [Company filter]
),
investigation_started AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Investigation Started' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured investigation activity value]'
AND [Company filter]
),
additional_info_requested AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Requested' AS ActivityName,
CAST(a.[Activity created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity created timestamp column] >= p.start_ts
AND a.[Activity created timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND [Company filter]
),
additional_info_received AS (
SELECT
CAST(a.[Claim ID column] AS VARCHAR) AS ClaimID,
'Additional Info Received' AS ActivityName,
CAST(a.[Activity completion timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(a.[Activity assigned user column] AS VARCHAR) AS AssignedAdjuster,
CAST(a.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(a.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(a.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(a.[Activity identifier column] AS VARCHAR) AS SourceEventID
FROM [Your activity source object] a
CROSS JOIN params p
WHERE a.[Activity completion timestamp column] >= p.start_ts
AND a.[Activity completion timestamp column] < p.end_ts
AND a.[Activity category or type column] = '[Configured additional information request value]'
AND a.[Activity status column] = '[Configured completed status value]'
AND [Company filter]
),
liability_decision_made AS (
SELECT
CAST(eh.[Claim ID column] AS VARCHAR) AS ClaimID,
'Liability Decision Made' AS ActivityName,
CAST(eh.[Exposure status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(eh.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(eh.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(eh.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(eh.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(eh.[Exposure status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your exposure status history object] eh
CROSS JOIN params p
WHERE eh.[Exposure status event timestamp column] >= p.start_ts
AND eh.[Exposure status event timestamp column] < p.end_ts
AND eh.[New exposure status column] = '[Configured liability decision status value]'
AND eh.[New exposure status column] IS DISTINCT FROM eh.[Previous exposure status column]
AND [Company filter]
),
settlement_calculated AS (
SELECT
CAST(pay.[Claim ID column] AS VARCHAR) AS ClaimID,
'Settlement Calculated' AS ActivityName,
CAST(pay.[Payment created timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(pay.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(pay.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(pay.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(pay.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(pay.[Payment identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment source object] pay
CROSS JOIN params p
WHERE pay.[Payment created timestamp column] >= p.start_ts
AND pay.[Payment created timestamp column] < p.end_ts
AND pay.[Payment status column] = '[Configured pending approval status value]'
AND [Company filter]
),
payment_approved AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Approved' AS ActivityName,
CAST(ph.[Payment approval timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Approving user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment approval timestamp column] >= p.start_ts
AND ph.[Payment approval timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured approved status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
payment_issued AS (
SELECT
CAST(ph.[Claim ID column] AS VARCHAR) AS ClaimID,
'Payment Issued' AS ActivityName,
CAST(ph.[Payment issued timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ph.[Issuing user column] AS VARCHAR) AS AssignedAdjuster,
CAST(ph.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ph.[Claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ph.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ph.[Payment status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your payment status history object] ph
CROSS JOIN params p
WHERE ph.[Payment issued timestamp column] >= p.start_ts
AND ph.[Payment issued timestamp column] < p.end_ts
AND ph.[New payment status column] = '[Configured issued status value]'
AND ph.[New payment status column] IS DISTINCT FROM ph.[Previous payment status column]
AND [Company filter]
),
claim_denied AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Denied' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND ch.[Claim closure reason column] = '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_closed AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Closed' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[New claim status column] = '[Configured closed status value]'
AND COALESCE(ch.[Claim closure reason column], '') <> '[Configured denied reason value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
claim_reopened AS (
SELECT
CAST(ch.[Claim ID column] AS VARCHAR) AS ClaimID,
'Claim Reopened' AS ActivityName,
CAST(ch.[Claim status event timestamp column] AS TIMESTAMP_TZ) AS EventTime,
CAST(ch.[Assigned adjuster column] AS VARCHAR) AS AssignedAdjuster,
CAST(ch.[Claim type column] AS VARCHAR) AS ClaimType,
CAST(ch.[New claim status column] AS VARCHAR) AS ClaimStatus,
CAST(ch.[Loss cause column] AS VARCHAR) AS LossCause,
CAST(ch.[Claim status event identifier column] AS VARCHAR) AS SourceEventID
FROM [Your claim status history object] ch
CROSS JOIN params p
WHERE ch.[Claim status event timestamp column] >= p.start_ts
AND ch.[Claim status event timestamp column] < p.end_ts
AND ch.[Previous claim status column] = '[Configured closed status value]'
AND ch.[New claim status column] = '[Configured open status value]'
AND ch.[New claim status column] IS DISTINCT FROM ch.[Previous claim status column]
AND [Company filter]
),
all_events AS (
SELECT * FROM claim_created
UNION ALL SELECT * FROM claim_assigned
UNION ALL SELECT * FROM exposure_created
UNION ALL SELECT * FROM initial_reserve_set
UNION ALL SELECT * FROM investigation_started
UNION ALL SELECT * FROM additional_info_requested
UNION ALL SELECT * FROM additional_info_received
UNION ALL SELECT * FROM liability_decision_made
UNION ALL SELECT * FROM settlement_calculated
UNION ALL SELECT * FROM payment_approved
UNION ALL SELECT * FROM payment_issued
UNION ALL SELECT * FROM claim_denied
UNION ALL SELECT * FROM claim_closed
UNION ALL SELECT * FROM claim_reopened
),
deduplicated_events AS (
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause,
SourceEventID,
ROW_NUMBER() OVER (
PARTITION BY ActivityName, COALESCE(SourceEventID, ClaimID || '|' || TO_VARCHAR(EventTime))
ORDER BY EventTime
) AS duplicate_rank
FROM all_events
WHERE ClaimID IS NOT NULL
AND ActivityName IS NOT NULL
AND EventTime IS NOT NULL
)
SELECT
ClaimID,
ActivityName,
EventTime,
AssignedAdjuster,
ClaimType,
ClaimStatus,
LossCause
FROM deduplicated_events
WHERE duplicate_rank = 1
ORDER BY ClaimID, EventTime, ActivityName; Passaggi
- Verifichi che l’accesso diretto in lettura al database operativo Guidewire ClaimCenter installato localmente sia autorizzato, che la piattaforma del database e la versione dello schema siano documentate e che sia disponibile una connessione di sola lettura. Non interroghi il database di produzione senza una finestra di estrazione approvata.
- Individui le tabelle fisiche e le colonne utilizzate dall’implementazione di ClaimCenter. Mappi le entità relative a sinistri, esposizioni, attività, assegnazioni, riserve, pagamenti, cronologia degli stati e utenti o gruppi ai segnaposto della query. Poiché i nomi fisici e le strutture di audit variano in base all’implementazione e alla versione, sostituisca ciascun segnaposto solo dopo averlo verificato nel catalogo del database e nel modello dati di ClaimCenter.
- Definisca il periodo di estrazione usando [Start date parameter] e [End date parameter]. Se le modifiche di stato, il completamento delle attività o le transazioni finanziarie possono essere registrati al di fuori del periodo principale di creazione del sinistro, includa un intervallo di sovrapposizione, ad esempio uno o due giorni prima della data di inizio richiesta.
- Esegua l’intera istruzione SQL con privilegi di sola lettura. Ogni attività viene restituita come riga di evento esplicita. Dopo l’acquisizione, ProcessMind non deduce gli eventi. Gli eventi dedotti dalle modifiche dei campi vengono ricavati all’interno dell’istruzione SQL dai record di cronologia o di audit pertinenti.
- Convalidi la mappatura delle fonti per ogni attività. Verifichi che la creazione del sinistro utilizzi il primo record Claim salvato, che l’assegnazione si basi sulle modifiche di assegnazione, che la creazione dell’esposizione utilizzi i relativi record di creazione, che la riserva iniziale corrisponda alla prima transazione di riserva per esposizione, che le indagini e le richieste di informazioni utilizzino i record delle attività, che la responsabilità si basi sulla transizione di stato configurata per l’esposizione, che la liquidazione utilizzi uno stato di pagamento in attesa di approvazione e che l’approvazione e l’emissione del pagamento utilizzino i rispettivi stati di audit finanziario.
- Normalizzi l’output secondo la struttura richiesta per l’Event Log. ClaimID deve essere l’identificativo del caso, ActivityName deve contenere esattamente uno dei quattordici nomi di attività documentati ed EventTime deve essere una data e ora. Mantenga gli attributi consigliati, tra cui AssignedAdjuster, ClaimType, ClaimStatus e LossCause, quando la mappatura della fonte li rende disponibili.
- Controlli i duplicati e l’ordine degli eventi. Se la fonte contiene più righe di audit per la stessa transizione aziendale, applichi la chiave di deduplicazione specifica dell’implementazione nella CTE pertinente. Non accorpi eventi aziendali distinti con date e ore o identificativi di origine diversi.
- Esporti il risultato in formato CSV con codifica UTF-8 o in un altro formato tabellare supportato da ProcessMind. Includa una riga di intestazione con ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus e LossCause. Si assicuri che le date e le ore includano il fuso orario o utilizzino in modo coerente il fuso orario documentato del database. Carichi il file in ProcessMind e mappi ClaimID come identificativo del caso, ActivityName come attività ed EventTime come data e ora dell’evento.
Configurazione
- Accesso al database: utilizzi un account di sola lettura autorizzato a interrogare le tabelle operative, le tabelle di cronologia, le tabelle delle attività e le tabelle delle transazioni finanziarie necessarie di ClaimCenter. Per l’estrazione non conceda privilegi di scrittura, modifica dello schema o amministrazione.
- Mappatura dello schema: sostituisca [Your claim table], [Your exposure table], [Your activity table], [Your reserve table], [Your payment table], [Your claim history table], [Your exposure history table] e gli altri segnaposto con nomi verificati nell’implementazione di destinazione. Non presuma che il nome logico di un’entità Guidewire corrisponda al nome della tabella fisica nel database.
- Intervallo di date: inizi con dati relativi a un periodo da tre a sei mesi. Utilizzi [Start date parameter] e [End date parameter] e includa un intervallo di sovrapposizione quando gli eventi possono essere registrati dopo la creazione del sinistro o quando i sinistri riaperti si estendono su più periodi di rendicontazione.
- Filtri: applichi [Company Code filter], [Document Type filter], i filtri per giurisdizione, ramo assicurativo o altri criteri specifici dell’organizzazione solo dopo averne verificato le colonne fisiche e il significato aziendale. Eviti di escludere i sinistri senza pagamenti o senza esposizioni, poiché sono necessari per un’analisi completa del ciclo di vita.
- Nomi delle attività: mantenga esattamente i quattordici valori ActivityName definiti nella query, affinché ProcessMind riceva etichette degli eventi coerenti.
- Semantica degli eventi: le attività indicate come dedotte vengono generate in SQL a partire dalle transizioni di stato, assegnazione, cronologia o attività delle fonti. Dopo l’acquisizione, ProcessMind non ricava questi eventi da altre righe.
- Prestazioni: limiti il periodo di estrazione, selezioni solo le colonne necessarie, filtri le tabelle di origine prima delle join e verifichi la presenza di indici sugli identificativi dei sinistri e delle esposizioni, sulle date e ore degli eventi, sui campi di stato e sugli identificativi delle transazioni. Se disponibile, esegua le estrazioni di grandi dimensioni su una replica per la reportistica.
- Coerenza: utilizzi un livello di isolamento delle transazioni adatto alla reportistica e definisca un limite temporale coerente per l’estrazione. Eviti di leggere le tabelle mentre un’elaborazione finanziaria in blocco o un aggiornamento massivo degli stati è ancora in corso.
- Fusi orari: documenti il fuso orario del database e converta tutte le date e ore di origine in un unico fuso orario concordato prima dell’esportazione. Non mescoli l’ora locale dell’applicazione con quella del server del database.
- Prerequisiti: verifichi che siano disponibili i moduli ClaimCenter necessari, le autorizzazioni finanziarie, la conservazione dei dati di audit o di cronologia e la connettività al database. Se la conservazione della cronologia o dei dati di audit è disattivata, non sarà possibile ricostruire in modo affidabile le attività dedotte corrispondenti.
- Configurazione della convalida: registri per ogni esportazione la versione di ClaimCenter, la piattaforma del database, la mappatura dello schema, la data e ora di estrazione, i parametri di data, i filtri e il numero di righe.
Query di esempio sql
WITH
claim_created AS (
SELECT
c.[Claim ID column] AS ClaimID,
CAST('Claim Created' AS VARCHAR(100)) AS ActivityName,
c.[Claim Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim table] c
WHERE c.[Claim Created Timestamp column] >= [Start date parameter]
AND c.[Claim Created Timestamp column] < [End date parameter]
),
claim_assigned AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Assigned' AS VARCHAR(100)) AS ActivityName,
h.[Assignment Change Timestamp column] AS EventTime,
h.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim assignment history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Assignment Change Timestamp column] >= [Start date parameter]
AND h.[Assignment Change Timestamp column] < [End date parameter]
AND h.[Assigned Adjuster column] IS NOT NULL
),
exposure_created AS (
SELECT
e.[Claim ID column] AS ClaimID,
CAST('Exposure Created' AS VARCHAR(100)) AS ActivityName,
e.[Exposure Created Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure table] e
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = e.[Claim ID column]
WHERE e.[Exposure Created Timestamp column] >= [Start date parameter]
AND e.[Exposure Created Timestamp column] < [End date parameter]
),
initial_reserve_set AS (
SELECT
x.ClaimID,
CAST('Initial Reserve Set' AS VARCHAR(100)) AS ActivityName,
x.EventTime,
x.AssignedAdjuster,
x.ClaimType,
x.ClaimStatus,
x.LossCause
FROM (
SELECT
r.[Claim ID column] AS ClaimID,
r.[Reserve Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause,
ROW_NUMBER() OVER (
PARTITION BY r.[Exposure ID column]
ORDER BY r.[Reserve Timestamp column], r.[Reserve Transaction ID column]
) AS reserve_sequence
FROM [Your reserve transaction table] r
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = r.[Claim ID column]
WHERE r.[Reserve Timestamp column] >= [Start date parameter]
AND r.[Reserve Timestamp column] < [End date parameter]
) x
WHERE x.reserve_sequence = 1
),
investigation_started AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Investigation Started' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Investigation activity type value])
),
additional_info_requested AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Requested' AS VARCHAR(100)) AS ActivityName,
a.[Activity Created Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Created Timestamp column] >= [Start date parameter]
AND a.[Activity Created Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
),
additional_info_received AS (
SELECT
a.[Claim ID column] AS ClaimID,
CAST('Additional Info Received' AS VARCHAR(100)) AS ActivityName,
a.[Activity Completed Timestamp column] AS EventTime,
a.[Assigned User column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your activity table] a
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = a.[Claim ID column]
WHERE a.[Activity Completed Timestamp column] >= [Start date parameter]
AND a.[Activity Completed Timestamp column] < [End date parameter]
AND a.[Activity Type column] IN ([Additional information request activity type value])
AND a.[Activity Status column] = [Completed activity status value]
),
liability_decision_made AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Liability Decision Made' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your exposure status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Exposure Status column] IN ([Liability decision status value])
),
settlement_calculated AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Settlement Calculated' AS VARCHAR(100)) AS ActivityName,
p.[Payment Status Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Payment Status Timestamp column] >= [Start date parameter]
AND p.[Payment Status Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Pending approval payment status value]
),
payment_approved AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Approved' AS VARCHAR(100)) AS ActivityName,
p.[Approval Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment approval history table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Approval Timestamp column] >= [Start date parameter]
AND p.[Approval Timestamp column] < [End date parameter]
AND p.[Approval Status column] = [Approved payment status value]
),
payment_issued AS (
SELECT
p.[Claim ID column] AS ClaimID,
CAST('Payment Issued' AS VARCHAR(100)) AS ActivityName,
p.[Issued Timestamp column] AS EventTime,
p.[Approved By column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
c.[Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your payment issuance table] p
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = p.[Claim ID column]
WHERE p.[Issued Timestamp column] >= [Start date parameter]
AND p.[Issued Timestamp column] < [End date parameter]
AND p.[Payment Status column] = [Issued payment status value]
),
claim_denied AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Denied' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] = [Denied status reason value]
),
claim_closed AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Closed' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND h.[New Claim Status column] = [Closed claim status value]
AND h.[Status Reason column] <> [Denied status reason value]
),
claim_reopened AS (
SELECT
h.[Claim ID column] AS ClaimID,
CAST('Claim Reopened' AS VARCHAR(100)) AS ActivityName,
h.[Status Change Timestamp column] AS EventTime,
c.[Assigned Adjuster column] AS AssignedAdjuster,
c.[Claim Type column] AS ClaimType,
h.[New Claim Status column] AS ClaimStatus,
c.[Loss Cause column] AS LossCause
FROM [Your claim status history table] h
INNER JOIN [Your claim status history table] previous_h
ON previous_h.[Claim ID column] = h.[Claim ID column]
AND previous_h.[Status Change Timestamp column] = (
SELECT MAX(prior_h.[Status Change Timestamp column])
FROM [Your claim status history table] prior_h
WHERE prior_h.[Claim ID column] = h.[Claim ID column]
AND prior_h.[Status Change Timestamp column] < h.[Status Change Timestamp column]
)
INNER JOIN [Your claim table] c
ON c.[Claim ID column] = h.[Claim ID column]
WHERE h.[Status Change Timestamp column] >= [Start date parameter]
AND h.[Status Change Timestamp column] < [End date parameter]
AND previous_h.[New Claim Status column] = [Closed claim status value]
AND h.[New Claim Status column] = [Open claim status value]
)
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_assigned
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM exposure_created
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM initial_reserve_set
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM investigation_started
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_requested
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM additional_info_received
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM liability_decision_made
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM settlement_calculated
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_approved
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM payment_issued
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_denied
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_closed
UNION ALL
SELECT ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus, LossCause FROM claim_reopened
ORDER BY ClaimID, EventTime, ActivityName; È pronto a iniziare?
Utilizzi questo template per preparare i dati all’analisi e ottenere informazioni utili sulla gestione dei sinistri. Inizi oggi a ottimizzare i flussi di lavoro.
Accelera la gestione dei sinistri e risolva i casi più rapidamente
Riduca gli arretrati, prevenga le frodi e punti a una gestione automatizzata dall’inizio alla fine del 70% dei casi.
Non è richiesta una carta di credito e la configurazione richiede solo pochi minuti.