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 da Guidewire ClaimCenter
Attributi della gestione dei sinistri
| Nome | Descrizione | ||
|---|---|---|---|
| ID sinistro ClaimID | L'identificativo univoco di ogni sinistro assicurativo, che funge da identificativo principale del caso. | ||
| Descrizione Il Claim ID è l'elemento fondamentale per l'analisi del processo di gestione dei sinistri e identifica univocamente ogni caso dalla presentazione alla chiusura. Collega tutte le attività, i documenti, i pagamenti e le comunicazioni associate, garantendo una visione completa e coerente del ciclo di vita del sinistro. Nel Process Mining, ogni evento del dataset è associato a un Claim ID, consentendo di ricostruire il flusso del processo end-to-end. Questo è essenziale per analizzare i tempi di ciclo, identificare le varianti del processo e seguire il percorso di un sinistro tra diversi reparti e liquidatori. Perché è importante È la chiave fondamentale che collega tutti gli eventi correlati, rendendo possibile tracciare e analizzare l'intero percorso di un singolo sinistro. Dove reperirlo Si tratta di una chiave primaria in Guidewire ClaimCenter, generalmente presente come Claim.ClaimNumber o in un campo analogo dell'entità Claim principale. Esempi 000-123-45678000-987-65432001-456-11223 | |||
| Nome dell'attività ActivityName | Il nome dell'attività aziendale o dell'evento che si è verificato in un determinato momento del ciclo di vita del sinistro. | ||
| Descrizione Questo attributo descrive uno specifico passaggio o una milestone del processo di gestione dei sinistri, come "Claim Created", "Investigation Started" o "Payment Issued". La sequenza di queste attività per un determinato Claim ID costituisce il flusso del processo. L'analisi della sequenza, della frequenza e della durata tra le attività è il fulcro del Process Mining. Consente di individuare i modelli di processo, identificare i colli di bottiglia, rilevare i cicli di rilavorazione e analizzare le deviazioni dal processo. Perché è importante Definisce i passaggi del processo, consentendo di visualizzare le mappe di processo e analizzare il flusso del processo e i colli di bottiglia. Dove reperirlo In genere deriva dalle tabelle degli eventi o dagli audit log di ClaimCenter, spesso mappando specifici eventi di sistema o variazioni di stato su nomi standardizzati delle attività. Esempi Sinistro creatoDecisione sulla responsabilità presaPagamento emessoSinistro chiuso | |||
| Orario dell'evento EventTime | La data e l'ora precise in cui si è verificata l'attività. | ||
| Descrizione Questo Timestamp indica il momento esatto in cui un'attività è stata registrata nel sistema. È fondamentale per tutte le analisi di processo basate sul tempo. L'ordinamento cronologico di EventTime per un singolo Claim ID consente di ricostruire il flusso del processo. La differenza di tempo tra eventi consecutivi viene utilizzata per calcolare tempi di ciclo, tempi di attesa e tempi di elaborazione, elementi essenziali per l'analisi delle prestazioni, l'identificazione dei colli di bottiglia e il monitoraggio degli SLA. Perché è importante Questo Timestamp è essenziale per ordinare gli eventi, calcolare tempi di ciclo e durate e identificare i ritardi nel processo. Dove reperirlo Si trova insieme ai dati degli eventi o delle attività nelle tabelle dello storico o di audit di Guidewire ClaimCenter, spesso in un campo come "CreateTime" o "UpdateTime". Esempi 2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z | |||
| Causa del sinistro LossCause | La ragione o causa specifica dell'evento dannoso, ad esempio Collision, Fire o Water Damage. | ||
| Descrizione Questo Attributo fornisce un contesto dettagliato sul motivo per cui è stato presentato il sinistro. La causa del danno determina spesso le fasi di istruttoria necessarie, il tipo di esperti richiesti e la complessità complessiva del sinistro. L'analisi del processo per Causa del sinistro può rivelare schemi nascosti. Per esempio, i sinistri legati a «Water Damage» potrebbero presentare un tasso più elevato di rilavorazione o richiedere un maggiore coinvolgimento di specialisti rispetto ai sinistri per «Theft». Questi insight aiutano a creare procedure di gestione più specializzate ed efficienti. Perché è importante Fornisce un contesto sulla natura del sinistro e consente di analizzare l'impatto delle diverse cause del danno sul flusso e sulla durata del processo. Dove reperirlo È un campo standard dell'entità Claim, generalmente denominato «LossCause». Esempi CollisioneIncendioDanno da acquaFurto | |||
| Liquidatore assegnato AssignedAdjuster | Il nome o l'ID dell'utente assegnato alla gestione del sinistro o di una specifica attività. | ||
| Descrizione Questo Attributo identifica il liquidatore responsabile di un sinistro in un determinato momento. Un liquidatore può essere assegnato all'intero sinistro oppure a specifiche attività al suo interno. L'analisi per Liquidatore assegnato è fondamentale per bilanciare i carichi di lavoro, gestire le prestazioni e individuare opportunità di formazione. Aiuta a rispondere a domande come: «Quali liquidatori hanno il maggior numero di sinistri in gestione?», «Esistono differenze nelle prestazioni tra i liquidatori?» 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 reperirlo Disponibile nell'entità Claim o Exposure di ClaimCenter, spesso collegato 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 Open, Closed o Denied. | ||
| Descrizione Questo Attributo riflette lo stato generale del sinistro. Gli stati principali includono «Open», «Closed», «Denied» e «Reopened». Lo stato finale di un sinistro è un indicatore fondamentale del risultato. Monitorare le variazioni di Claim Status aiuta a definire le principali tappe e gli esiti del processo. Viene utilizzato per identificare la risoluzione finale di un sinistro, calcolare i tassi di rifiuto e analizzare la frequenza con cui i sinistri vengono riaperti dopo la chiusura, un fenomeno che spesso indica problemi di processo o insoddisfazione dei clienti. Perché è importante Indica l'esito di un sinistro, un'informazione essenziale per analizzare i tassi di rifiuto, i modelli di chiusura e la frequenza di riapertura dei sinistri. Dove reperirlo È un campo fondamentale dell'entità Claim, generalmente denominato «State» o «Status». Esempi ApertoChiusoRespintoRiaperto | |||
| Tipo di sinistro ClaimType | La categoria del sinistro assicurativo, ad esempio Auto, Property o Liability. | ||
| Descrizione Claim Type rappresenta la classificazione fondamentale di un sinistro in base al ramo assicurativo o alla 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 Claim Type è essenziale per ottenere insight significativi. Consente di confrontare le prestazioni del processo tra diversi rami assicurativi, individuare i colli di bottiglia specifici di ciascun tipo e adattare le iniziative di miglioramento alle caratteristiche peculiari di ogni categoria di sinistro. Perché è importante Consente di segmentare i sinistri, poiché tipi diversi, ad esempio Auto e Property, seguono spesso processi differenti e hanno obiettivi di prestazione diversi. Dove reperirlo Derivato dall'entità Policy o Claim in ClaimCenter, spesso in base al codice Line of Business (LOB). Esempi Auto privataProperty commercialeResponsabilità 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 è la data dell'evento effettivo, ad esempio un incidente stradale o un danno a un immobile, per il quale viene presentato il sinistro. È distinta dalla data di denuncia o di creazione del sinistro. L'intervallo tra la Data del sinistro e l'attività «Claim Created», noto come ritardo di denuncia, è un KPI importante. La sua analisi può fornire insight sul comportamento dei clienti e sull'efficacia dei canali di prima denuncia del sinistro. Perché è importante Fornisce un contesto essenziale sull'origine del sinistro e aiuta ad analizzare il ritardo di denuncia, cioè il tempo trascorso tra l'incidente e la presentazione del sinistro. Dove reperirlo È 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 la quale si prevede che il sinistro venga risolto in base agli SLA interni o normativi. | ||
| Descrizione La Data obiettivo di risoluzione è una scadenza fissata per la chiusura del sinistro, spesso determinata da fattori quali giurisdizione, tipo di sinistro e condizioni della polizza. Funge da riferimento per misurare le prestazioni e la Conformità. Questo Attributo è fondamentale per creare Dashboard e KPI sull'aderenza agli SLA. Confrontando la data effettiva di «Claim Closed» con la data obiettivo, l'analisi può segnalare automaticamente i sinistri in ritardo, misurare il tasso di rispetto delle scadenze e individuare i tipi di sinistro o i reparti che faticano a raggiungere i propri obiettivi. Perché è importante Rappresenta il riferimento per misurare l'aderenza al Service Level Agreement (SLA) e individuare i sinistri a rischio di ritardo. Dove reperirlo Potrebbe trattarsi di un campo personalizzato o di un valore derivato in base alle regole aziendali configurate in ClaimCenter, eventualmente collegato a metriche specifiche 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 manualmente da un utente. | ||
| Descrizione Questo Attributo booleano distingue tra le attività eseguite dal sistema, come la creazione automatica di una riserva o la generazione di comunicazioni da parte del sistema, e quelle svolte manualmente da un liquidatore. L'analisi di questo Attributo è fondamentale per comprendere il livello di automazione del processo di gestione dei sinistri. Aiuta a individuare i punti in cui è necessario un intervento manuale, misurare l'efficacia delle iniziative di straight-through processing e trovare nuove opportunità di automazione identificando le attività ripetitive e basate su regole che attualmente vengono svolte da persone. Perché è importante Distingue tra attività guidate dal sistema e attività svolte da persone, un elemento fondamentale per analizzare l'automazione e individuare i colli di bottiglia manuali. Dove reperirlo Spesso deve essere ricavato. Per esempio, gli eventi registrati da un utente «system» Generico possono essere contrassegnati come automatizzati. Esempi truefalse | |||
| È rilavorazione IsRework | Un indicatore che specifica se un'attività rappresenta un ciclo di rilavorazione, cioè il 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 «Investigation Completed» a «Investigation Started», la seconda attività «Investigation Started» viene contrassegnata come rilavorazione. Individuare la rilavorazione è fondamentale per far emergere inefficienze del processo e problemi di qualità. La Dashboard Rework and Rejection Frequency utilizza questa metrica per quantificare la frequenza con cui i sinistri si discostano dal «percorso ideale». Analizzare le cause della rilavorazione può portare a miglioramenti significativi nella qualità e nella velocità del processo. Perché è importante Mette in evidenza inefficienze del processo e problemi di qualità contrassegnando esplicitamente le attività che fanno parte di un ciclo di rilavorazione. Dove reperirlo Viene calcolato nello strumento di Process Mining analizzando la sequenza delle attività per ogni caso. Esempi truefalse | |||
| Importo del pagamento PaymentAmount | L'importo effettivamente pagato per un'attività di pagamento. | ||
| Descrizione Questo Attributo registra il valore di ogni singolo pagamento effettuato per un sinistro. Un singolo sinistro può prevedere più pagamenti nel corso del suo ciclo di vita. È un'informazione essenziale per l'analisi finanziaria nel contesto del Process Mining. Può essere utilizzata per monitorare l'importo totale liquidato per sinistro, analizzare i tempi di approvazione dei pagamenti in base all'importo e collegare le inefficienze del processo ai risultati finanziari. Per esempio, tempi di ciclo più lunghi potrebbero essere correlati a pagamenti totali più elevati. Perché è importante Tiene traccia delle transazioni finanziarie relative a un sinistro e consente di analizzare gli importi dei pagamenti e la loro relazione con le attività del processo. Dove reperirlo 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 monetario totale richiesto inizialmente dal contraente. | ||
| Descrizione Questo Attributo rappresenta il valore del danno dichiarato dal richiedente. Spesso si tratta di una stima iniziale, che può cambiare durante l'istruttoria del sinistro e la definizione delle riserve. L'analisi dell'Importo richiesto aiuta a segmentare i sinistri in base all'impatto finanziario. I sinistri di importo elevato seguono spesso un processo più rigoroso e complesso rispetto a quelli di importo ridotto. Il confronto tra processi relativi a diverse fasce di valore può rivelare opportunità per semplificare la gestione dei sinistri minori o applicare controlli più stringenti a quelli di importo maggiore. Perché è importante Consente di segmentare i sinistri in base al valore finanziario, poiché quelli di importo elevato possono seguire processi diversi e più complessi. Dove reperirlo Queste informazioni potrebbero non corrispondere a un singolo campo, ma essere ricavate 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 le attività con una durata misurabile, come «Investigation» o «Document Review». Sebbene molte attività di Process Mining siano istantanee e sia quindi sufficiente StartTime, le attività con un inizio e una fine distinti sono rappresentate in modo più accurato utilizzando entrambi i timestamp. Questo Attributo consente di calcolare con precisione il tempo di elaborazione dell'attività, distinto dal tempo di attesa. Aiuta a identificare le attività specifiche che richiedono più tempo, invece di limitarsi a osservare lunghi ritardi tra fasi diverse. Perché è importante Consente di misurare con precisione il tempo necessario per completare un'attività, separando il tempo di elaborazione dal tempo di attesa. Dove reperirlo Potrebbe essere necessario ricavarlo individuando un evento successivo che concluda logicamente l'attività, ad esempio il passaggio di stato da «In Progress» a «Completed». 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 liquidatore assegnato, ad esempio «Auto Claims», «Property Claims» o «Special Investigations Unit». 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 allocare le risorse in modo più efficace all'interno dell'organizzazione che gestisce i sinistri. Perché è importante Fornisce un contesto organizzativo che consente di analizzare le prestazioni dei diversi team e di mettere in evidenza i problemi nei passaggi di consegne tra reparti. Dove reperirlo Queste informazioni sono generalmente associate al profilo dell'utente o del gruppo assegnato in ClaimCenter. Esempi Divisione sinistri autoUnità sinistri propertyUnità investigazioni speciali (SIU) | |||
| Richiesta ripetuta di informazioni RepeatedInfoRequestFlag | Un indicatore che specifica se «Additional Info Requested» si è verificato più di una volta per lo stesso sinistro. | ||
| Descrizione Questo indicatore booleano viene impostato su true se per un sinistro si è verificata più di un'attività «Additional Info Requested». Questo scenario segnala spesso inefficienze nella fase iniziale di raccolta delle informazioni. Questo Attributo supporta direttamente il KPI «Repeated Info Request Rate». Aiuta a quantificare il problema della raccolta iniziale incompleta dei dati, che può causare ritardi significativi e frustrazione nei clienti. Analizzare i sinistri contrassegnati da questo indicatore può contribuire a migliorare checklist e procedure per i liquidatori, così da richiedere tutte le informazioni necessarie in un'unica fase. Perché è importante Individua le inefficienze nelle situazioni in cui la raccolta delle informazioni non viene completata al primo tentativo, causando ritardi e rilavorazioni. Dove reperirlo Calcolato nello strumento di Process Mining contando le occorrenze dell'attività «Additional Info Requested» per caso. Esempi truefalse | |||
| Sistema di origine SourceSystem | Il sistema dal quale sono stati estratti i dati. | ||
| Descrizione Questo attributo identifica l'origine dei dati degli eventi. In un moderno ecosistema aziendale, gli eventi relativi ai sinistri possono provenire da più sistemi, come un sistema core quale Guidewire, un sistema di gestione documentale o un portale clienti. Specificare il sistema di origine è fondamentale per la governance dei dati, la risoluzione delle incoerenze e la comprensione del panorama tecnologico del processo. Aiuta a distinguere i passaggi del processo core dalle attività di supporto provenienti dai sistemi periferici. Perché è importante Identifica l'origine dei dati, un elemento fondamentale per la governance dei dati e per le analisi che coinvolgono più sistemi integrati. Dove reperirlo In genere si tratta di un valore statico aggiunto durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati. Esempi Guidewire ClaimCenter v10API del portale clientiDocumentum | |||
| Stato della giurisdizione JurisdictionState | Lo stato o la giurisdizione che disciplina il sinistro e determina i requisiti normativi applicabili. | ||
| Descrizione Questo Attributo specifica la giurisdizione legale, ad esempio lo stato degli Stati Uniti, in base alla quale viene gestito il sinistro. Le normative assicurative possono variare significativamente tra le diverse giurisdizioni e incidere sulle fasi obbligatorie del processo, sulle tempistiche delle comunicazioni e sulla documentazione. È un Attributo essenziale per il monitoraggio della Conformità. Analizzare il processo per giurisdizione consente di verificare il rispetto dei requisiti normativi specifici di ciascuno stato. Può inoltre spiegare variazioni nei tempi di ciclo o nei percorsi del processo determinate da vincoli legali anziché da inefficienze operative. Perché è importante È fondamentale per l'analisi della Conformità, poiché giurisdizioni diverse applicano normative diverse che incidono sul processo di gestione dei sinistri. Dove reperirlo Un campo standard dell'entità Claim, generalmente denominato «JurisdictionState». Esempi CANYTXFL | |||
| Stato SLA SLAState | Indica se il sinistro è stato chiuso entro la relativa data obiettivo di risoluzione. | ||
| Descrizione Questo Attributo calcolato fornisce uno stato categoriale dell'aderenza agli SLA per ogni sinistro chiuso. Viene ricavato confrontando il timestamp dell'attività «Claim Closed» con la «Resolution Target Date». Questo Attributo supporta direttamente la Dashboard «Claim Resolution Target Adherence», semplificando l'analisi in categorie chiare come «On Time» o «Late». Consente di filtrare e aggregare facilmente i dati per calcolare il tasso complessivo di aderenza agli SLA e analizzare in dettaglio le cause dei ritardi. Perché è importante Fornisce un esito chiaro e categoriale dell'aderenza agli SLA, semplificando il filtraggio, l'aggregazione e l'analisi delle prestazioni puntuali. Dove reperirlo Campo calcolato: IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late'). Esempi Nei tempi previstiIn ritardo | |||
| Tipo di polizza PolicyType | Il tipo specifico di polizza assicurativa in base alla quale è stato presentato il sinistro. | ||
| Descrizione Policy Type fornisce una classificazione più dettagliata rispetto a Claim Type e identifica lo specifico prodotto assicurativo, ad esempio «Homeowners», «Commercial Auto» o «Cyber Liability». Questo livello di dettaglio può rivelare variazioni del processo legate a prodotti specifici. L'analisi del processo per Policy Type aiuta a individuare inefficienze specifiche dei prodotti. Per esempio, i sinistri relativi a una polizza appena lanciata potrebbero seguire un processo meno maturo e causare ritardi. Questa analisi può orientare la progettazione dei prodotti e le iniziative di standardizzazione dei processi. Perché è importante Consente di analizzare il processo per specifici prodotti assicurativi e di individuare variazioni nella gestione legate alle caratteristiche della polizza. Dove reperirlo Queste informazioni si trovano nell'entità Policy, collegata a Claim. Esempi Polizza multirischio abitazioneResponsabilità civile auto commercialeTrasporti marittimi interni | |||
| 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 fornisce il timestamp dell'estrazione più recente dei dati dal sistema di origine. È un campo di metadati essenziale per comprendere l'attualità dell'analisi. Le Dashboard e le analisi dovrebbero mostrare queste informazioni in modo evidente, affinché gli utenti siano consapevoli dell'aggiornamento dei dati. Ciò consente di valutare se gli insight riflettono lo stato attuale delle operazioni o si basano su dati meno recenti. Perché è importante Indica l'attualità dei dati e permette agli utenti di comprendere quanto sia aggiornata l'analisi del processo. Dove reperirlo 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 passività potenziale o un tipo di perdita nell'ambito del sinistro, ad esempio danni al veicolo o lesioni. In Guidewire si tratta di un evento esplicito. | ||
| Perché è importante Le esposizioni sono fondamentali per la segmentazione e l'analisi dei sinistri. Monitorarne la creazione aiuta a comprendere le variazioni del processo in base alla complessità del sinistro e al tipo di perdita. Dove reperirlo Acquisita dal CreateTime di un nuovo record nella tabella cc_exposure. Ogni record è collegato a un singolo Claim ID. Acquisizione Individuare il Timestamp di creazione di un nuovo record nella tabella dell'entità Exposure. Tipo di evento explicit | |||
| Pagamento approvato | Rappresenta l'approvazione formale di un pagamento di liquidazione. Si tratta di un evento di audit critico, acquisito esplicitamente quando un utente autorizzato approva la transazione. | ||
| Perché è importante Questa milestone fondamentale sblocca il passaggio finale del pagamento. Analizzare il tempo prima e dopo questa attività aiuta a isolare i ritardi causati dai Workflow di approvazione o dalla disponibilità dei responsabili. Dove reperirlo Spesso si tratta di un evento esplicito registrato nella tabella cc_history e relativo a un'entità cc_check o cc_transaction, che registra la variazione di stato da "Pending Approval" ad "Approved". Acquisizione Monitorare l'evento di variazione dello stato ad "Approved" per una specifica transazione di pagamento. Tipo di evento explicit | |||
| Pagamento emesso | Questa attività indica il passaggio finale del processo di pagamento, quando il pagamento viene ufficialmente emesso e inviato al sistema finanziario. Si tratta di una transazione finanziaria esplicita e registrata. | ||
| Perché è importante Questa attività è fondamentale per misurare l'efficienza del processo di invio del pagamento. Aiuta a distinguere i ritardi nell'approvazione da quelli relativi all'effettiva erogazione dei fondi. Dove reperirlo Acquisita dall'IssueDate o da una variazione di stato a "Issued" o "Submitted" sull'entità cc_check o cc_transaction. Spesso si tratta di un evento esplicito con Timestamp. Acquisizione Individuare l'IssueDate o il Timestamp della variazione di stato a "Issued" nel record del pagamento. Tipo di evento explicit | |||
| Riserva iniziale impostata | Indica la creazione della prima transazione di riserva finanziaria per un'esposizione, stimando il costo potenziale del sinistro. Si tratta di un evento finanziario critico, acquisito esplicitamente. | ||
| Perché è importante Questa milestone è fondamentale per l'analisi finanziaria e per comprendere con quale rapidità viene valutata la passività potenziale. I ritardi possono influire sulla pianificazione e sulla rendicontazione finanziaria. Dove reperirlo L'evento viene acquisito dalla creazione del primo record cc_reserveline associato a un'esposizione del sinistro. Il CreateTime della transazione costituisce il Timestamp dell'evento. Acquisizione Individuare il Timestamp minimo di creazione di tutte le reserve line per le esposizioni di un determinato sinistro. Tipo di evento explicit | |||
| Sinistro chiuso | Indica la chiusura corretta di un sinistro dopo il completamento di tutte le attività e dei pagamenti. È il principale evento finale positivo, dedotto da una variazione dello stato principale del sinistro. | ||
| Perché è importante In quanto evento finale principale, questa attività è essenziale per calcolare il tempo di ciclo end-to-end e misurare il rispetto degli SLA. Indica il completamento del ciclo di vita del sinistro. Dove reperirlo Deducibile dalla variazione del campo State della tabella cc_claim a "Closed". Il Timestamp dell'evento è il CloseDate del record del sinistro. Acquisizione Individuare il momento in cui il campo dello 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 posizione di sinistro in Guidewire ClaimCenter. Viene registrata esplicitamente quando una nuova entità Claim viene salvata per la prima volta nel database. | ||
| Perché è importante In quanto evento di inizio principale, questa attività è essenziale per misurare il tempo di ciclo completo del sinistro. Fornisce la base di riferimento per tutti i KPI successivi relativi a prestazioni e durata. Dove reperirlo Si tratta di un evento esplicito acquisito dal CreateTime della tabella cc_claim. La creazione di un nuovo record con un Claim ID univoco costituisce il trigger dell'evento. Acquisizione Individuare il Timestamp di creazione del nuovo record nella tabella dell'entità Claim di base. Tipo di evento explicit | |||
| Sinistro negato | Rappresenta la decisione finale di negare un sinistro e costituisce il punto terminale del processo. L'evento viene dedotto dalla variazione dello stato del sinistro a uno stato chiuso con motivo "Denied". | ||
| Perché è importante Si tratta di un evento di esito critico. Analizzare la frequenza, i motivi e i percorsi di processo che portano ai dinieghi aiuta a individuare problemi nell'acquisizione del sinistro, nell'indagine o nell'interpretazione della polizza. Dove reperirlo Deducibile dalla variazione del campo State della tabella cc_claim a "Closed", insieme al valore "Denied" o a un valore analogo nel campo CloseReason. Il Timestamp dell'evento è il CloseDate. Acquisizione Filtrare le variazioni dello stato del sinistro a "Closed" quando il codice motivo indica un diniego. Tipo di evento inferred | |||
| Decisione sulla responsabilità presa | Indica il momento in cui viene determinata la responsabilità o la colpa relativa a un'esposizione. In genere questo evento viene dedotto da una variazione dello stato dell'entità Exposure. | ||
| Perché è importante Si tratta di una milestone decisionale critica che condiziona 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 reperirlo Deducibile dalla tabella cc_history monitorando una variazione nel campo State o in un campo personalizzato relativo allo stato della responsabilità sull'entità cc_exposure. Il Timestamp del record storico indica il momento dell'evento. Acquisizione Monitorare gli audit log o le tabelle dello storico per rilevare gli aggiornamenti allo stato o allo stato della responsabilità dell'esposizione. Tipo di evento inferred | |||
| Indagine avviata | Indica l'inizio formale della fase di indagine per un sinistro o un'esposizione. Spesso viene dedotta dalla creazione della prima Activity, ovvero Task, relativa all'indagine in Guidewire. | ||
| Perché è importante Questa attività segna l'inizio di una fase fondamentale e spesso lunga. Analizzare il tempo che precede l'avvio dell'indagine e la durata dell'indagine stessa consente di individuare i principali colli di bottiglia. Dove reperirlo Deducibile dal CreateTime di un record cc_activity il cui ActivityPattern è correlato all'indagine, ad esempio "Initial Investigation" o "Contact Witness". Acquisizione Individuare la prima creazione di un Task con un pattern o un oggetto correlato all'indagine. Tipo di evento inferred | |||
| Informazioni aggiuntive ricevute | Indica il completamento di una richiesta di informazioni aggiuntive. Viene acquisita quando la Activity, ovvero il Task, corrispondente alla richiesta di informazioni viene contrassegnata come "Completed". | ||
| Perché è importante Questo è il punto finale del KPI "Additional Info Gathering Cycle Time". I tempi lunghi tra la richiesta e la ricezione sono tra le cause più comuni di ritardo nel processo di gestione dei sinistri. Dove reperirlo Acquisita dal CloseTime di un record cc_activity il cui ActivityPattern è correlato a una richiesta di informazioni. Lo stato dell'attività deve essere "Completed". Acquisizione Individuare il Timestamp di completamento di un Task per la richiesta di informazioni esterne. Tipo di evento explicit | |||
| Informazioni aggiuntive richieste | Rappresenta una richiesta inviata al richiedente o a una terza parte per ottenere ulteriori informazioni o documentazione. In genere viene acquisita come Activity, ovvero Task, esplicita creata in ClaimCenter. | ||
| Perché è importante Questa attività costituisce il punto di partenza per misurare il KPI "Additional Info Gathering Cycle Time". La frequenza elevata di questi eventi può segnalare processi FNOL incompleti o inefficienze nella raccolta delle informazioni. Dove reperirlo Acquisita dal CloseTime di un record cc_activity il cui ActivityPattern è correlato alla richiesta di documentazione o informazioni a una parte esterna. Acquisizione Individuare la creazione di un Task per la richiesta di informazioni esterne. Tipo di evento explicit | |||
| Liquidazione calcolata | Questa attività rappresenta il momento in cui viene determinato l'importo della liquidazione, ma il pagamento non è ancora stato approvato. Può essere dedotta dalla creazione di un pagamento con stato "Pending Approval". | ||
| Perché è importante Segna il passaggio dalla valutazione al pagamento. Costituisce il punto di partenza per misurare il KPI "Payment Authorization Lead Time" e individuare i ritardi nella catena di approvazione. Dove reperirlo Deducibile dal CreateTime di un record cc_check o cc_transaction il cui stato iniziale è "Pending Approval" o uno stato analogo precedente ad "Approved". Acquisizione Individuare la creazione di un record di pagamento o transazione con uno stato precedente all'approvazione. Tipo di evento inferred | |||
| Sinistro assegnato | Rappresenta l'assegnazione di un sinistro a uno specifico utente, ovvero il liquidatore, o a un gruppo incaricato della gestione. In genere viene dedotta monitorando le variazioni nei campi di assegnazione dell'entità Claim. | ||
| Perché è importante Il monitoraggio delle assegnazioni è fondamentale per analizzare il carico di lavoro dei liquidatori, individuare i colli di bottiglia nel routing e misurare il tempo necessario alla prima azione da parte dell'incaricato. Dove reperirlo Deducibile dalla tabella cc_history monitorando le variazioni nei campi AssignedUser o AssignedGroup associati a uno specifico Claim ID. Il Timestamp della variazione indica il momento in cui si è verificato l'evento. Acquisizione Monitorare gli audit log o le tabelle dello storico per rilevare gli aggiornamenti ai campi di assegnazione del sinistro. Tipo di evento inferred | |||
| Sinistro riaperto | Rappresenta il passaggio di un sinistro dallo stato "Closed" allo stato "Open" per svolgere ulteriori attività. L'evento viene dedotto da una specifica sequenza di variazioni 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 inefficienze di processo, con conseguente aumento dei costi. Dove reperirlo Deducibile dalla tabella cc_history identificando una variazione del campo State dell'entità cc_claim da "Closed" nuovamente a "Open" o a un altro stato attivo. Acquisizione Monitorare il campo dello stato principale del sinistro per rilevare il passaggio da uno stato chiuso a uno aperto. Tipo di evento inferred | |||
Guide all’estrazione
Passaggi
- Verifica dei prerequisiti: verifichi di disporre delle autorizzazioni e delle credenziali necessarie per accedere al database del data mart Guidewire DataHub / InfoCenter con privilegi di sola lettura. 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, come DBeaver, SQL Server Management Studio o strumenti analoghi, per stabilire una connessione 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, le tabelle principali presentano suffissi come _dim (dimensione) e _fact (fatto). Questo La aiuterà a convalidare i nomi segnaposto di tabelle e colonne presenti nello script fornito.
- Preparazione della query SQL: copi lo script SQL completo fornito nella sezione della query nell’editor del Suo client SQL.
- Personalizzazione dei segnaposto: esamini attentamente lo script e sostituisca tutti i valori segnaposto. Sono inclusi il nome del database/schema, ad esempio [YourDataMart], i parametri dell’intervallo di date ('[StartDate]', '[EndDate]') e gli eventuali valori di configurazione specifici del sistema, come modelli di attività e codici di stato.
- Esecuzione della query: esegua la query SQL modificata sul data mart. Il tempo di esecuzione può variare in base all’intervallo di date selezionato e al volume di dati presenti nel Suo sistema.
- Verifica iniziale dei dati: al termine della query, esamini le prime centinaia di righe del set di risultati. Verifichi che le colonne ClaimID, ActivityName ed EventTime siano valorizzate come previsto e che siano presenti diversi tipi di attività.
- Esportazione in CSV: esporti l’intero set di risultati dal Suo client SQL in un file CSV. Assegni al file un nome descrittivo, ad esempio guidewire_claimcenter_event_log.csv.
- Formattazione per ProcessMind: si assicuri che il file CSV sia salvato con codifica UTF-8. Verifichi che contenga una riga di intestazione corrispondente agli alias delle colonne utilizzati 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 il reporting e l’analisi, separato dal database di produzione live di ClaimCenter.
- Autorizzazioni necessarie: accesso di sola lettura al database SQL che ospita il data mart. Le serviranno un nome utente, una password e i dettagli di connessione, tra cui indirizzo del server e nome del database.
- Stato dei processi ETL: l’accuratezza dell’estrazione dipende dall’esecuzione corretta e puntuale 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, è consigliabile 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. Deve adattare i valori nelle clausole WHERE alla configurazione della Sua organizzazione. Sono inclusi:
- i nomi di ActivityPattern, ad esempio 'fnol', 'investigation', 'Request additional information'
- i codici ClaimStatus, ExposureStatus e CloseReason, ad esempio 'denied', 'closed'
- i codici TransactionStatus, ad esempio 'pendingapproval', 'approved', 'issued'
- Prestazioni: l’interrogazione di grandi tabelle storiche o di audit può richiedere molte risorse. Per dataset molto estesi, è consigliabile eseguire la query negli orari di minore utilizzo. Si assicuri che le colonne ClaimID o ClaimNumber siano indicizzate nelle tabelle pertinenti.
a 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 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 esatti del database CDA esposti nella condivisione. Gli schemi CDA e i nomi delle colonne possono variare in base al tenant, alla release, alla configurazione e al modello di condivisione dei dati. Sostituisca ogni oggetto o colonna segnaposto tra parentesi quadre con l’oggetto corrispondente del Suo ambiente. Non presuma che i nomi delle entità operative di ClaimCenter siano esposti invariati in Snowflake.
- Individui l’origine per la creazione del sinistro, lo storico delle assegnazioni, la creazione delle esposizioni, le transazioni delle riserve, le attività, lo storico degli stati delle esposizioni, lo storico degli stati dei pagamenti e lo storico degli stati dei sinistri. Se la condivisione non espone tabelle storiche o record di audit, configuri un’origine approvata che conservi il valore precedente, il nuovo valore, il timestamp dell’evento e l’autore per ogni transizione di stato richiesta.
- Si connetta alla condivisione CDA Snowflake utilizzando un client Snowflake, un worksheet, un notebook o uno strumento di esecuzione SQL autorizzato. Ove possibile, utilizzi un ruolo di sola lettura. Imposti nella query i timestamp di inizio e fine dell’analisi utilizzando [Start timestamp] e [End timestamp], quindi applichi l’eventuale filtro aziendale o di unità operativa approvato tramite [Company filter].
- Sostituisca i segnaposto delle origini nella query con nomi di oggetti e colonne CDA verificati. La query crea 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 verifichi lo schema dei risultati. L’output deve contenere ClaimID, ActivityName, EventTime, AssignedAdjuster, ClaimType, ClaimStatus e LossCause. ClaimID, ActivityName ed EventTime sono obbligatori per ProcessMind. Conservi una riga per evento e non aggreghi gli eventi per sinistro.
- Convalidi timestamp, transizioni di stato, modifiche alle assegnazioni, gestione dei duplicati e conteggi delle attività prima dell’esportazione. Confermi che i timestamp degli eventi utilizzino un fuso orario coerente e che gli eventi multipli con lo stesso timestamp restino su righe separate quando rappresentano attività aziendali distinte.
- Esporti il risultato in formato CSV UTF-8 o in un altro formato tabellare supportato da ProcessMind. Mappi ClaimID come identificativo del caso, ActivityName come attività ed EventTime come timestamp dell’evento. Mantenga gli Attributi consigliati come ulteriori Attributi dell’evento e carichi il file in ProcessMind senza aggiungere attività dedotte al di fuori di questa estrazione.
Configurazione
- Connessione e autorizzazione: utilizzi la condivisione dati Snowflake fornita da Guidewire tramite un account Snowflake, un ruolo, un warehouse e un percorso di rete autorizzati. Dal punto di vista del consumatore, CDA è di sola lettura. L’accesso necessario dipende dalla configurazione del Suo 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 origini tra parentesi quadre con oggetti verificati nella Sua condivisione CDA. La query non presuppone intenzionalmente nomi universali di tabelle o colonne ClaimCenter, poiché le strutture CDA variano in base alla release 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 dello storico degli eventi e una durata della query accettabile. Filtri i record di origine in base al timestamp dell’evento pertinente, non soltanto alla data di creazione del sinistro, per evitare di 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. Quando disponibili, questi valori possono essere acquisiti dallo snapshot relativo al momento dell’evento. Se sono esposti solo i valori dello stato corrente, documenti tale limitazione, poiché gli Attributi storici potrebbero non riflettere il valore al momento dell’evento.
- Filtri: applichi [Company filter] solo dopo aver confermato la colonna specifica del tenant corrispondente all’azienda, all’organizzazione, all’unità operativa o all’entità giuridica. Non filtri per tipo di documento, a meno che la configurazione ClaimCenter non esponga un campo verificato relativo al tipo di documento e alle attività richieste.
- Storico degli eventi: per identificare 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.
- Deduplicazione: utilizzi, quando disponibile, un identificativo verificato dell’evento di origine. La query usa ROW_NUMBER solo come salvaguardia configurabile. Non deduplichi gli eventi esclusivamente in base a ClaimID e timestamp quando attività distinte possono legittimamente verificarsi nello stesso momento.
- Prestazioni: limiti l’intervallo di date, selezioni solo le colonne necessarie, filtri ogni origine in base al relativo timestamp dell’evento e utilizzi un warehouse Snowflake di dimensioni adeguate. Per volumi elevati, valuti la materializzazione 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 i timestamp CDA sono memorizzati in UTC, nell’ora locale o in varianti di timestamp Snowflake.
- Prerequisiti: verifichi che nella condivisione siano inclusi i dati finanziari, delle attività, delle assegnazioni, delle esposizioni, dei pagamenti e dello storico degli stati di ClaimCenter e che i criteri di conservazione preservino le transizioni storiche necessarie.
a 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 on-premise 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 dalla Sua implementazione ClaimCenter. Mappi le entità relative a sinistri, esposizioni, attività, assegnazioni, riserve, pagamenti, storico degli stati e utenti o gruppi ai segnaposto presenti nella query. Poiché i nomi fisici e le strutture di audit variano in base all’implementazione e alla versione, sostituisca ogni segnaposto solo dopo averlo convalidato rispetto al catalogo del database e al modello dati ClaimCenter.
- Definisca il periodo di estrazione utilizzando [Start date parameter] e [End date parameter]. Utilizzi una sovrapposizione temporale, ad esempio uno o due giorni prima dell’inizio richiesto, quando 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.
- Esegua l’istruzione SQL completa con privilegi di sola lettura. Ogni attività viene emessa come riga di evento esplicita. La query non affida a ProcessMind il compito di dedurre gli eventi dopo l’acquisizione. Gli eventi dedotti dalle modifiche dei campi vengono derivati all’interno dell’istruzione SQL dai record storici o di audit pertinenti.
- Convalidi le mappature delle origini per ogni attività. Confermi che la creazione del sinistro utilizzi il primo record Claim salvato, che l’assegnazione utilizzi le modifiche alle assegnazioni, che la creazione dell’esposizione utilizzi i record di creazione dell’esposizione, che la riserva iniziale utilizzi la prima transazione di riserva per esposizione, che le indagini e le richieste di informazioni utilizzino i record delle attività, che la responsabilità utilizzi la transizione di stato dell’esposizione configurata, che la liquidazione utilizzi uno stato di pagamento in attesa di approvazione e che l’approvazione e l’emissione del pagamento utilizzino i relativi stati di audit finanziario.
- Normalizzi l’output secondo la struttura richiesta dell’Event Log. ClaimID deve essere l’identificativo del caso, ActivityName deve contenere esattamente uno dei quattordici nomi di attività documentati ed EventTime deve essere un timestamp. Conservi gli Attributi consigliati, tra cui AssignedAdjuster, ClaimType, ClaimStatus e LossCause, quando la mappatura dell’origine li rende disponibili.
- Esamini gli eventi duplicati e il loro ordinamento. Se l’origine contiene più righe di audit per la stessa transizione aziendale, applichi la chiave di deduplicazione specifica dell’implementazione nella relativa espressione di tabella comune. Non accorpi eventi aziendali distinti che presentano timestamp o identificativi di origine differenti.
- Esporti il risultato in formato CSV 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 i timestamp includano le informazioni sul fuso orario oppure utilizzi 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 timestamp dell’evento.
Configurazione
- Accesso al database: utilizzi un account di sola lettura autorizzato a interrogare le tabelle operative, storiche, delle attività e delle transazioni finanziarie necessarie di ClaimCenter. Non conceda privilegi di scrittura, modifica dello schema o amministrazione per l’estrazione.
- 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 i relativi segnaposto con nomi verificati nell’implementazione di destinazione. Non presuma che il nome logico di un’entità Guidewire corrisponda al nome della tabella fisica del 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 una finestra di sovrapposizione quando gli eventi possono essere registrati dopo la creazione del sinistro o quando i sinistri riaperti si estendono su più periodi di reporting.
- Filtri: applichi [Company Code filter], [Document Type filter], giurisdizione, linea di business o altri filtri specifici dell’organizzazione solo dopo averne confermato le colonne fisiche e il significato aziendale. Eviti di escludere i sinistri privi di pagamento o di esposizione, poiché tali record 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à descritte come dedotte vengono generate in SQL dalle transizioni di stato, assegnazione, storico o attività dell’origine. ProcessMind non deriverà questi eventi da altre righe dopo l’acquisizione.
- Prestazioni: limiti il periodo di estrazione, selezioni solo le colonne necessarie, filtri le tabelle di origine prima dei join e verifichi gli indici sugli identificativi dei sinistri, sugli identificativi delle esposizioni, sui timestamp degli eventi, sui campi di stato e sugli identificativi delle transazioni. Ove disponibile, esegua le estrazioni di grandi dimensioni su una replica per il reporting.
- Coerenza: utilizzi un livello di isolamento delle transazioni adeguato al reporting e acquisisca un punto di estrazione coerente. Eviti di leggere le tabelle mentre un processo finanziario o un aggiornamento massivo degli stati è stato solo parzialmente confermato.
- Fusi orari: documenti il fuso orario del database e converta tutti i timestamp di origine in un unico fuso orario concordato prima dell’esportazione. Non combini timestamp locali dell’applicazione e timestamp del server del database.
- Prerequisiti: verifichi che siano disponibili i moduli ClaimCenter necessari, le autorizzazioni finanziarie, la conservazione dei dati di audit o dello storico e la connettività al database. Se la conservazione dello storico o dell’audit è disabilitata, le attività dedotte corrispondenti non possono essere ricostruite in modo affidabile.
- Configurazione di convalida: registri per ogni esportazione la versione di ClaimCenter, la piattaforma del database, la mappatura dello schema, il timestamp dell’estrazione, i parametri di data, i filtri e il numero di righe.
a 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 per iniziare?
Utilizzi questo Template per preparare i Suoi dati all’analisi e ottenere insight sulla gestione dei sinistri. Inizi oggi stesso a ottimizzare i Suoi Workflow.
Accelerare la gestione dei sinistri e risolvere i casi più rapidamente
Elimini gli arretrati, prevenga le frodi e punti a una gestione straight-through del 70%.
Non è richiesta alcuna carta di credito; la configurazione richiede solo pochi minuti.