Il Suo template dati per la gestione dei sinistri

Guidewire ClaimCenter
Il Suo template dati per la gestione dei sinistri

Il Suo template dati per la gestione dei sinistri

Questa risorsa dedicata La aiuta a ottimizzare la gestione dei sinistri. Il template descrive gli attributi essenziali da raccogliere e le attività principali da monitorare, oltre a fornire indicazioni chiare sull’estrazione dei dati. Lo utilizzi per acquisire tutte le informazioni necessarie a un’analisi completa del processo.
  • Attributi consigliati da raccogliere
  • Attività principali da monitorare
  • Indicazioni per l’estrazione dei dati da Guidewire ClaimCenter
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi per la gestione dei sinistri

Questi campi dati consigliati sono fondamentali per creare un Event Log completo e analizzare in modo efficace i flussi di lavoro della gestione dei sinistri.
3 Obbligatorio 4 Consigliato 14 Facoltativo
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
Obbligatorio Consigliato Facoltativo

Attività di gestione dei sinistri

Questi sono i passaggi principali del processo e le tappe significative da registrare nell’Event Log per individuare e analizzare con precisione il processo di gestione dei sinistri.
7 Consigliato 7 Facoltativo
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
Consigliato Facoltativo

Guide per l’estrazione

Come estrarre i dati da Guidewire ClaimCenter

È 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.

Inizi la prova gratuita.

Non è richiesta una carta di credito e la configurazione richiede solo pochi minuti.