Il Suo Template dei dati per la gestione dei sinistri

Sinistri FINEOS
Il Suo Template dei dati per la gestione dei sinistri

Il Suo Template dei dati per la gestione dei sinistri

Questo Template offre un approccio strutturato alla raccolta dei dati essenziali necessari per un'analisi efficace del processo di gestione dei sinistri. Illustra gli attributi principali e le attività chiave da monitorare, insieme a indicazioni pratiche per estrarre queste informazioni dai sistemi di origine. Lo utilizzi per preparare il Suo Event Log e accelerare il percorso verso una gestione dei sinistri ottimizzata.
  • Attributi consigliati per un'analisi dettagliata
  • Attività chiave della gestione dei sinistri da monitorare
  • Indicazioni pratiche per l'estrazione dei dati
Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Attributi della gestione dei sinistri

Questi sono i campi dati consigliati da includere nell’Event Log per un’analisi completa dei Workflow di gestione dei sinistri.
5 Obbligatorio 8 Consigliato 9 Facoltativo
Nome Descrizione
ID sinistro
ClaimId
L’identificativo univoco di un singolo sinistro assicurativo, che funge da identificativo principale del caso per l’analisi dei processi.
Descrizione

Il Claim ID è la chiave fondamentale che collega tutte le attività, gli eventi e i dati lungo l’intero ciclo di vita di un sinistro. Garantisce che ogni punto di contatto, dalla presentazione iniziale alla chiusura definitiva, possa essere tracciato in modo coerente come parte di un unico caso.

Nel process mining, questo attributo è essenziale per ricostruire il percorso end-to-end di ogni sinistro. Consente di analizzare i flussi di processo, calcolare i tempi complessivi di risoluzione e individuare le variazioni nel modo in cui vengono gestiti i diversi sinistri.

Perché è importante

È l’identificativo principale che collega tutti gli eventi correlati in un’unica istanza di processo, rendendo possibile l’analisi end-to-end del ciclo di vita del sinistro.

Dove reperirlo

È una chiave primaria nelle principali tabelle di gestione dei casi di sinistro all’interno di FINEOS Claims.

Esempi
CL-2023-001234CL-2023-005678CL-2024-009101
Nome dell’attività
ActivityName
Il nome dello specifico evento aziendale o Task che si è verificato in un determinato momento del processo di gestione dei sinistri.
Descrizione

Questo attributo descrive una singola fase o tappa del processo di gestione dei sinistri, come ‘Sinistro presentato’, ‘Revisione iniziale completata’ o ‘Pagamento emesso’. Ogni attività rappresenta un’azione distinta eseguita sul sinistro.

Analizzare la sequenza e la frequenza di queste attività è alla base del process mining. Consente di evidenziare il flusso di processo effettivo, individuare i colli di bottiglia in cui il lavoro si accumula e mettere in luce i percorsi comuni o eccezionali seguiti dai sinistri.

Perché è importante

Definisce le fasi del processo, consentendo di visualizzare la mappa del processo e analizzare i pattern del Workflow e le deviazioni.

Dove reperirlo

Viene normalmente ricavato dagli event log, dalle modifiche dello stato dei Task o dagli audit trail all’interno del sistema FINEOS Claims.

Esempi
Sinistro registratoPerdita valutataPagamento autorizzatoSinistro chiuso
Orario dell’evento
EventTime
Il timestamp che indica quando si è verificata una specifica attività o un determinato evento.
Descrizione

Event Time registra la data e l’ora esatte in cui si è svolta un’attività di gestione dei sinistri. Questi dati cronologici sono fondamentali per ordinare correttamente gli eventi e comprendere la sequenza temporale di un sinistro.

Nell’analisi, questo timestamp viene utilizzato per calcolare durate, tempi di ciclo e tempi di attesa tra le diverse fasi. È essenziale per individuare i ritardi, misurare le performance rispetto agli SLA e comprendere la dinamica temporale del processo.

Perché è importante

Questo timestamp fornisce l’ordine cronologico degli eventi, essenziale per calcolare tutte le metriche basate sul tempo, come il tempo di ciclo, e individuare i colli di bottiglia.

Dove reperirlo

Queste informazioni sono normalmente disponibili come timestamp di creazione o aggiornamento associato a ciascun evento o registrazione di stato in FINEOS Claims.

Esempi
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
Sistema di origine
SourceSystem
Identifica il sistema IT dal quale sono stati estratti i dati.
Descrizione

Questo attributo specifica l'origine dei dati di processo. Per questa analisi sarà sempre «FINEOS Claims», ma in un ambiente con più sistemi è fondamentale per tracciare la provenienza dei dati e garantirne la qualità.

In un contesto analitico più ampio, consente di distinguere i processi che possono estendersi su più sistemi e di assicurare che i dati siano interpretati correttamente in base alla loro origine.

Perché è importante

Fornisce un contesto essenziale sull'origine dei dati, indispensabile per la governance dei dati, la validazione e l'integrazione con altri sistemi.

Dove reperirlo

Si tratta generalmente di un valore statico aggiunto durante l'estrazione dei dati per identificare l'origine del dataset.

Esempi
Sinistri FINEOSFINEOS Claims v11.2
Ultimo aggiornamento dei dati
LastDataUpdate
Indicazione temporale dell'ultima volta in cui i dati relativi a questo evento sono stati aggiornati dal sistema di origine.
Descrizione

Questo attributo indica la data e l'ora in cui i dati sono stati estratti o aggiornati più di recente. È importante per comprendere il livello di aggiornamento e l'attualità dei dati analizzati.

Questa informazione è fondamentale per la governance dei dati e consente agli utenti di sapere se stanno esaminando i dati di processo più recenti. Aiuta a gestire le aspettative sulla latenza dei dati ed è essenziale per la reportistica relativa a processi quasi in tempo reale.

Perché è importante

Indica il livello di aggiornamento dei dati, consentendo agli utenti di comprendere il periodo coperto dall'analisi e il momento dell'ultimo aggiornamento.

Dove reperirlo

Questo timestamp viene generalmente generato e memorizzato dallo strumento di estrazione dei dati o dall'ETL al termine di un job di caricamento dei dati.

Esempi
2024-05-21T02:00:00Z2024-05-22T02:00:00Z
Canale di presentazione
SubmissionChannel
Il metodo o il canale attraverso il quale il sinistro è stato inizialmente presentato.
Descrizione

Questo attributo registra la modalità di ricezione del sinistro, ad esempio tramite un portale online, via e-mail, per posta o attraverso un agente. Canali di presentazione diversi possono incidere significativamente sulla qualità dei dati e sui tempi di elaborazione iniziali.

L'analisi del processo in base al canale di presentazione aiuta a determinare se alcuni canali consentano un'elaborazione più rapida, comportino tassi più elevati di rilavorazione, ad esempio a causa di informazioni mancanti, o producano risultati migliori. Queste informazioni possono orientare gli investimenti nell'ottimizzazione dei canali, per esempio migliorando i moduli online allo scopo di ridurre gli errori.

Perché è importante

Aiuta a determinare se alcuni canali di acquisizione consentano un'elaborazione più efficiente o comportino tassi più elevati di rilavorazione, fornendo indicazioni per la strategia e gli investimenti sui canali.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. L'informazione viene generalmente acquisita durante la fase di apertura del sinistro e memorizzata nella scheda principale del sinistro.

Esempi
Portale onlinePostaBrokerTelefono
Data obiettivo di risoluzione
ResolutionTargetDate
La data entro la quale si prevede di risolvere il sinistro, sulla base degli SLA o dei requisiti normativi.
Descrizione

Questo attributo rappresenta la scadenza per il completamento del processo di gestione del sinistro, definita dagli accordi sul livello di servizio (SLA) o dai requisiti normativi. Costituisce il riferimento rispetto al quale misurare le prestazioni effettive.

Questa data è essenziale per monitorare la conformità agli SLA. Confrontando la data effettiva di chiusura del sinistro con la Data obiettivo di risoluzione, è possibile calcolare il tasso di conformità agli SLA, individuare i sinistri a rischio di violazione dello SLA e analizzare le cause alla radice dei ritardi che determinano la non conformità.

Perché è importante

Costituisce il riferimento per misurare la conformità agli SLA. Consente di individuare i sinistri in ritardo e analizzare le ragioni dei ritardi.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Questa data viene spesso calcolata mediante regole di business basate sulla data e sul tipo di presentazione del sinistro.

Esempi
2023-11-15T23:59:59Z2024-01-30T23:59:59Z
Gravità del sinistro
ClaimSeverity
Una classificazione della complessità del sinistro o del suo potenziale impatto finanziario, ad esempio basso, medio o alto.
Descrizione

La Gravità del sinistro esprime una valutazione della complessità, dell'urgenza o dell'esposizione finanziaria del sinistro. I sinistri ad alta gravità possono richiedere più fasi, verifiche specialistiche o tempi di elaborazione più lunghi rispetto a quelli a bassa gravità.

L'analisi del processo per livello di gravità aiuta a comprendere se l'allocazione delle risorse e la progettazione del processo siano adeguate ai diversi livelli di complessità. Può rivelare se i sinistri ad alta gravità subiscano ritardi sproporzionati o se quelli a bassa gravità siano sottoposti a un'elaborazione eccessiva, consentendo una migliore segmentazione del processo e una gestione più efficace delle risorse.

Perché è importante

La segmentazione per gravità aiuta a verificare se il processo assegna correttamente la priorità ai sinistri ad alto impatto e a individuare i livelli di complessità che generano colli di bottiglia.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Può trattarsi di un campo dedicato oppure di un valore derivato da altri attributi, come l'importo stimato del danno.

Esempi
BassaMediaAltaComplessa
Liquidatore assegnato
AssignedAdjuster
Il nome o l'ID del liquidatore o dell'utente responsabile dell'attività.
Descrizione

Questo attributo identifica la persona o il team che ha eseguito una specifica attività nel processo di gestione dei sinistri. È il principale elemento di collegamento tra le attività di processo e le risorse umane.

L'analisi dei dati per Liquidatore assegnato è fondamentale per comprendere la distribuzione del carico di lavoro, le prestazioni individuali e l'efficienza delle risorse. Può evidenziare i liquidatori sovraccarichi, individuare opportunità di formazione attraverso il confronto delle prestazioni e supportare strategie più efficaci di allocazione delle risorse per bilanciare i carichi di lavoro.

Perché è importante

Questo attributo collega le fasi del processo alle persone che le eseguono, consentendo di analizzare il carico di lavoro, valutare l'efficienza delle risorse e confrontare le prestazioni.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. L'informazione è generalmente memorizzata nei campi relativi alla titolarità dell'attività o all'assegnazione dell'utente associati agli eventi del sinistro.

Esempi
John SmithEmily JonesADJ-4561
Ora di fine
EndTime
Il timestamp che indica quando una specifica attività o un evento è stato completato.
Descrizione

L'attributo Ora di fine registra il momento preciso in cui termina un'attività. Insieme all'Ora di inizio (EventTime), consente di calcolare con precisione quanto tempo è stato necessario per completare ogni fase, ovvero il relativo tempo di elaborazione.

Nell'analisi, questo dato è fondamentale per distinguere il tempo di elaborazione attivo dal tempo di attesa inattivo. Consente di creare analisi dettagliate dei colli di bottiglia, mostrando quali attività specifiche richiedono più tempo e dove si formano le code tra una fase e l'altra.

Perché è importante

Consente di calcolare con precisione il tempo di elaborazione di ogni attività, un elemento fondamentale per identificare le fasi inefficienti e misurare l'utilizzo delle risorse.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. L'informazione potrebbe essere disponibile negli event log oppure può essere ricavata dall'ora di inizio dell'evento successivo.

Esempi
2023-10-26T11:30:00Z2023-10-26T15:00:15Z2023-10-27T17:00:00Z
Reparto
Department
Il reparto o l'unità aziendale responsabile della gestione dell'attività o del sinistro.
Descrizione

Questo attributo specifica l'unità organizzativa, ad esempio «Acquisizione iniziale», «Unità investigativa» o «Reparto pagamenti», responsabile di una determinata attività o titolare del sinistro in una specifica fase.

L'analisi del processo per reparto è fondamentale per comprendere i passaggi di consegne tra funzioni, che sono spesso una fonte di ritardi. Aiuta a individuare i reparti che costituiscono colli di bottiglia, a misurare l'efficienza dei reparti e ad analizzare l'allocazione delle risorse all'interno dell'organizzazione.

Perché è importante

Consente di analizzare le prestazioni per unità organizzativa, mettendo in evidenza i ritardi nei passaggi di consegne tra reparti e i colli di bottiglia dipartimentali.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Può essere associato al profilo utente del liquidatore assegnato o alla coda alla quale è assegnata un'attività.

Esempi
Acquisizione e registrazioneUnità investigazioni specialiElaborazione dei pagamentiValutazione medica
Stato del sinistro
ClaimStatus
Lo stato attuale o storico del sinistro al momento dell'evento.
Descrizione

Lo Stato del sinistro indica la fase del ciclo di vita in cui si trova il sinistro, ad esempio «Aperto», «In attesa di informazioni», «Approvato», «Respinto» o «Chiuso». Questo attributo fornisce una fotografia della situazione del sinistro in un determinato momento.

Nell'analisi di processo, i cambiamenti di stato corrispondono spesso direttamente alle attività di processo. Monitorare lo stato è fondamentale per comprendere gli esiti dei sinistri, individuare i colli di bottiglia nei quali i sinistri rimangono bloccati a lungo in uno stato specifico e analizzare le ragioni degli esiti finali, come «Respinto» o «Chiuso».

Perché è importante

Questo attributo è fondamentale per comprendere gli esiti dei sinistri, filtrare i casi attivi rispetto a quelli chiusi e individuare le fasi in cui i sinistri rimangono bloccati.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. È un campo fondamentale della scheda principale del sinistro, aggiornato durante tutto il suo ciclo di vita.

Esempi
RegistratoIn fase di revisionePagamento in sospesoChiuso: pagatoChiuso: respinto
Tipo di sinistro
ClaimType
La categoria del sinistro assicurativo, ad esempio invalidità, danni materiali o responsabilità civile.
Descrizione

Il Tipo di sinistro classifica i sinistri in base alla natura della polizza o del danno. Tipi di sinistro diversi seguono spesso varianti di processo specifiche, sono soggetti a requisiti normativi differenti e richiedono una gestione specializzata.

Si tratta di una dimensione fondamentale per l'analisi comparativa. Filtrando o segmentando la vista del processo per Tipo di sinistro, gli analisti possono individuare colli di bottiglia specifici, confrontare le prestazioni tra le diverse categorie e adattare le iniziative di miglioramento alle esigenze peculiari di ciascun tipo di sinistro. Questo consente di verificare se alcuni tipi di sinistro siano intrinsecamente meno efficienti da gestire.

Perché è importante

Consente di segmentare il processo per confrontare le prestazioni e individuare le differenze tra le varie categorie di sinistri, favorendo interventi di miglioramento più mirati.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Si tratta di un attributo fondamentale del sinistro, generalmente impostato al momento della registrazione e memorizzato nella tabella principale del caso.

Esempi
Invalidità a breve termineInvalidità a lungo termineAssicurazione sulla vitaMorte accidentale
Area geografica del cliente
CustomerRegion
L'area geografica o lo Stato di residenza del richiedente o del contraente della polizza.
Descrizione

Questo attributo indica la posizione geografica associata al sinistro, che può basarsi sull'indirizzo del richiedente o sul luogo in cui si è verificato il danno.

L'analisi geografica può evidenziare differenze regionali nei tipi e nella frequenza dei sinistri, nonché nell'efficienza di elaborazione. Può aiutare a determinare se alcuni uffici regionali ottengano risultati migliori di altri o se fattori specifici del luogo, come normative o eventi meteorologici, incidano sul processo di gestione dei sinistri. Ciò consente una gestione e un'allocazione delle risorse più mirate.

Perché è importante

Consente la segmentazione geografica per individuare differenze nelle prestazioni regionali, variazioni nella conformità o colli di bottiglia specifici di una determinata area.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. L'informazione deriva generalmente dai dati relativi all'indirizzo del contraente o del richiedente memorizzati nel sistema.

Esempi
Nord-estCaliforniaMidwestFL
Data del danno
LossDate
La data in cui si è verificato l'evento che ha dato origine al sinistro assicurativo.
Descrizione

La Data del danno indica quando si è verificato l'incidente effettivo, ad esempio un infortunio o un sinistro. È distinta dalla data di presentazione del sinistro e può rappresentare un fattore importante per la validazione e la gestione del sinistro.

Questo attributo fornisce un contesto prezioso. L'intervallo tra la Data del danno e la data di «Presentazione del sinistro», ovvero il ritardo nella denuncia, può costituire un indicatore chiave delle prestazioni. L'analisi di questo intervallo può far emergere problemi nei processi di denuncia e il loro impatto sull'intero ciclo di vita del sinistro.

Perché è importante

Fornisce un contesto importante e consente di calcolare il ritardo nella denuncia, cioè il tempo trascorso tra il danno e la presentazione del sinistro, che può incidere sulla complessità e sugli esiti del sinistro.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Questa data è un campo standard acquisito durante la fase di «Prima denuncia del danno» o di registrazione del sinistro.

Esempi
2023-10-152023-09-012024-02-20
È rilavorazione
IsRework
Un flag booleano che indica se un'attività costituisce una ripetizione o una rilavorazione.
Descrizione

Questo attributo calcolato contrassegna le attività che rappresentano una rilavorazione, come un secondo evento «Richiesta di informazioni aggiuntive» per lo stesso sinistro. Generalmente viene identificato rilevando attività ripetute o cicli all'indietro nel flusso di processo.

Contrassegnare esplicitamente la rilavorazione semplifica le analisi incentrate sull'inefficienza. Consente di quantificare facilmente il tasso di rilavorazione, un indicatore chiave delle prestazioni. I Dashboard possono utilizzare questo flag per visualizzare la frequenza e l'impatto della rilavorazione, aiutando a individuare le cause alla radice di questi cicli inefficienti.

Perché è importante

Contrassegna direttamente i cicli inefficienti del processo, rendendo semplice calcolare il tasso di rilavorazione e analizzare i fattori che determinano la ripetizione delle attività.

Dove reperirlo

Viene ricavato durante l'analisi di Process Mining identificando le attività ripetute per lo stesso caso. Ad esempio, contrassegnando la seconda occorrenza di «Indagine avviata».

Esempi
truefalse
Importo del danno
LossAmount
L'importo finanziario stimato o accantonato associato al danno.
Descrizione

L'Importo del danno rappresenta la stima iniziale o la riserva finanziaria accantonata per un sinistro. Questo valore può essere aggiornato durante le attività di indagine e valutazione del sinistro.

Questi dati finanziari sono fondamentali per segmentare i sinistri e comprendere la correlazione tra impatto finanziario e comportamento del processo. Ad esempio, consentono di rispondere a domande come: i sinistri di valore più elevato richiedono più tempo per essere gestiti o comportano una maggiore rilavorazione? Sono inoltre un input essenziale per le previsioni finanziarie e la gestione del rischio.

Perché è importante

Fornisce un contesto finanziario al processo, consentendo di analizzare l'impatto del valore del sinistro sui tempi di elaborazione, sulla complessità e sui percorsi di processo.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. L'informazione si trova generalmente nelle tabelle finanziarie o relative alle riserve collegate al sinistro.

Esempi
5000.00150000.00250.50
Importo del pagamento
PaymentAmount
L'importo effettivamente corrisposto per il sinistro.
Descrizione

L'Importo del pagamento è la somma finale erogata al momento della liquidazione e dell'approvazione del sinistro. Per i sinistri con più pagamenti, può rappresentare una singola transazione di pagamento.

Questo attributo è essenziale per la riconciliazione finanziaria e per analizzare gli esiti economici del processo. Consente di confrontare la stima iniziale del danno con l'importo finale corrisposto. Nell'analisi di processo, aiuta a comprendere l'impatto finanziario delle diverse varianti o decisioni di processo.

Perché è importante

Tiene traccia dell'esito finanziario del processo, un elemento fondamentale per misurare le prestazioni finanziarie e analizzare il valore dei sinistri.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Questi dati si trovano nelle tabelle delle transazioni di pagamento collegate al caso del sinistro.

Esempi
4850.00145000.000.00
Motivo del rifiuto
DenialReason
Un codice o una descrizione che spiega perché un sinistro è stato rifiutato.
Descrizione

Quando l'esito di un sinistro è «Rifiutato», questo attributo fornisce il motivo specifico della decisione. Tra i motivi possibili rientrano «Non coperto dalla polizza», «Sospetta frode» o «Informazioni incomplete».

Si tratta di un attributo essenziale per l'analisi delle cause alla radice dei rifiuti dei sinistri. Analizzando la frequenza dei diversi motivi di rifiuto, l'organizzazione può individuare problemi ricorrenti nel processo di presentazione, aree di confusione dei clienti riguardo alla copertura della polizza o potenziali esigenze formative per i liquidatori. Queste informazioni possono portare a iniziative volte a ridurre il tasso di rifiuto e migliorare la soddisfazione dei clienti.

Perché è importante

È fondamentale per l'analisi delle cause alla radice dei processi non riusciti e aiuta a individuare opportunità per ridurre i rifiuti dei sinistri e migliorare la qualità dell'acquisizione.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Si tratta generalmente di un campo strutturato o di un codice selezionato durante l'esecuzione dell'attività «Sinistro rifiutato».

Esempi
Esclusione dalla polizzaInformazioni non forniteSinistro duplicatoFrode sospetta
Motivo della riapertura
ReopenReason
Un codice o una descrizione che spiega perché un sinistro chiuso è stato riaperto.
Descrizione

Questo attributo registra il motivo per cui un sinistro è passato dallo stato «Chiuso» a uno stato nuovamente attivo. Tra i motivi più comuni rientrano la ricezione di nuove informazioni, un ricorso presentato dal richiedente o la correzione di un errore.

L'analisi dei motivi di riapertura è un modo diretto per misurare la qualità e la definitività del processo. Un numero elevato di sinistri riaperti, soprattutto per determinati motivi, indica che la chiusura iniziale non era corretta. Questi dati possono evidenziare le debolezze nelle fasi di indagine o di decisione e fornire obiettivi chiari per il miglioramento del processo, così da garantire la corretta chiusura dei sinistri al primo tentativo.

Perché è importante

Fornisce una visione diretta dei casi di inefficienza del processo in cui un sinistro è stato chiuso prematuramente o in modo errato, evidenziando opportunità per migliorare la risoluzione al primo tentativo.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Questo motivo viene generalmente registrato quando un utente esegue l'azione «Riapri sinistro» nel sistema.

Esempi
Ricorso presentatoNuova documentazione medica ricevutaCorrezione di un errore amministrativoAdeguamento del pagamento necessario
Numero di polizza
PolicyNumber
L'identificativo univoco della polizza assicurativa nell'ambito della quale viene presentato il sinistro.
Descrizione

Il Numero di polizza identifica il contratto assicurativo che copre il sinistro. Collega il sinistro a uno specifico cliente, alle condizioni della polizza e ai dettagli della copertura.

Sebbene non sia direttamente un attributo di processo, fornisce un contesto aziendale essenziale. Consente di aggregare i dati dei sinistri per polizza o cliente, un'operazione utile per analizzare la frequenza dei sinistri, l'esperienza del cliente e individuare le polizze che generano un volume elevato di sinistri complessi.

Perché è importante

Fornisce un contesto aziendale fondamentale, collegando il sinistro a uno specifico contratto del cliente e consentendo un'analisi del processo incentrata sul cliente.

Dove reperirlo

Consulti la documentazione di FINEOS Claims. Si tratta di un dato fondamentale, acquisito al momento della registrazione del sinistro e memorizzato nella scheda principale del sinistro.

Esempi
POL-987654321POL-123456789
Stato SLA
SLAState
Uno stato calcolato che indica se un sinistro completato ha rispettato la relativa data obiettivo di risoluzione.
Descrizione

Questo attributo fornisce uno stato chiaro e categoriale delle prestazioni rispetto allo SLA per ogni sinistro. Viene ricavato confrontando la data di «Chiusura del sinistro» con la «Data obiettivo di risoluzione» e classificando l'esito come «In tempo» o «In ritardo».

Semplifica la reportistica e l'analisi del rispetto degli SLA. Invece di lavorare con date non elaborate, gli analisti possono utilizzare questa semplice categoria per creare Dashboard che mostrano il tasso di conformità agli SLA, filtrare tutti i sinistri in ritardo e analizzarne le caratteristiche comuni, nonché monitorare nel tempo le tendenze delle prestazioni rispetto agli SLA. Supporta direttamente il Dashboard e il KPI relativi al rispetto degli SLA.

Perché è importante

Fornisce un indicatore chiaro e semplice delle prestazioni rispetto allo SLA per ogni caso, rendendo facile misurare e analizzare il tasso di conformità agli SLA.

Dove reperirlo

È un campo calcolato ottenuto confrontando il timestamp dell'attività finale con «ResolutionTargetDate» per ogni caso.

Esempi
Nei tempi previstiIn ritardo
Obbligatorio Consigliato Facoltativo

Attività di gestione dei sinistri

Questi sono i passaggi chiave del processo e le principali tappe da acquisire nell’Event Log per una corretta individuazione del processo e dei colli di bottiglia.
6 Consigliato 9 Facoltativo
Attività Descrizione
Decisione sul sinistro presa
È la tappa decisiva in cui l’assicuratore prende una decisione formale: approvare, approvare parzialmente o respingere il sinistro. Viene quasi sempre registrata come modifica esplicita dello stato in FINEOS, verso una condizione come ‘Approvato’, ‘Respinto’ o ‘Liquidato’.
Perché è importante

Si tratta di una tappa fondamentale che determina il percorso successivo del processo, relativo al pagamento o alla chiusura. È essenziale per misurare il tempo necessario a prendere una decisione e analizzare gli esiti dei sinistri.

Dove reperirlo

Viene dedotto dal timestamp nella tabella dello storico degli stati del sinistro corrispondente a uno stato decisionale finale, ad esempio ‘Approvato’, ‘Rifiutato’ o ‘Respinto’.

Acquisizione

Timestamp della modifica dello stato ad ‘Approvato’ o ‘Respinto’.

Tipo di evento inferred
Pagamento autorizzato
Rappresenta l’approvazione formale dell’importo della liquidazione calcolato, affinché possa essere pagato. Spesso è una fase distinta dalla decisione sul sinistro e richiede l’autorizzazione di un responsabile o di un team specifico. Viene registrata tramite una modifica dello stato come ‘Approvato per il pagamento’.
Perché è importante

Questa attività è fondamentale per il KPI ‘Tempo di ciclo dell’autorizzazione del pagamento’. I ritardi tra la decisione e l’autorizzazione possono rappresentare un collo di bottiglia nascosto significativo, con ripercussioni sulla soddisfazione dei clienti.

Dove reperirlo

Viene dedotto dal timestamp della modifica dello stato a ‘Pagamento in attesa’, ‘Pronto per il pagamento’ o ‘Pagamento autorizzato’ nello storico degli stati del sinistro.

Acquisizione

Timestamp della modifica dello stato ad ‘Approvato per il pagamento’ o a uno stato analogo.

Tipo di evento inferred
Pagamento emesso
Indica il momento in cui il pagamento viene effettivamente elaborato e inviato al richiedente o al fornitore. In FINEOS, ciò avviene spesso tramite un’integrazione con un sistema finanziario e viene registrato come voce di log della transazione o come aggiornamento dello stato finale del pagamento.
Perché è importante

È un momento decisivo per il cliente. Analizzare il tempo che intercorre tra l’autorizzazione e l’emissione aiuta a semplificare il processo di pagamento e a migliorare l’esperienza del cliente.

Dove reperirlo

Può trattarsi di un evento esplicito proveniente da una tabella del log delle transazioni di pagamento all’interno di FINEOS o da un sistema integrato di contabilità fornitori. Anche una modifica dello stato a ‘Pagato’ rappresenta una probabile fonte.

Acquisizione

Utilizzi la data della transazione dal registro dei pagamenti oppure il timestamp della modifica dello stato a ‘Pagato’.

Tipo di evento explicit
Sinistro chiuso
Indica lo stato finale e terminale di un sinistro nel sistema, dopo il completamento di tutte le attività, incluso il pagamento o il respingimento. L’evento viene acquisito quando lo stato del sinistro viene aggiornato a ‘Chiuso’ o ‘Finalizzato’ in FINEOS.
Perché è importante

Questa attività rappresenta il principale evento di fine del processo. Il tempo che intercorre tra ‘Sinistro presentato’ e ‘Sinistro chiuso’ è un KPI fondamentale per misurare le performance e l’efficienza complessive del processo.

Dove reperirlo

Viene dedotto dal timestamp della modifica finale dello stato a ‘Chiuso’ nel log dello storico degli stati del sinistro. È l’ultimo aggiornamento di stato registrato per un sinistro completato con successo.

Acquisizione

Timestamp della modifica finale dello stato a ‘Chiuso’ o ‘Finalizzato’.

Tipo di evento inferred
Sinistro presentato
Indica la ricezione iniziale di un sinistro da parte dell’organizzazione, spesso attraverso canali diversi come portali web, e-mail o posta. Rappresenta il punto di avvio del processo di gestione dei sinistri e viene normalmente registrato quando la First Notice of Loss (FNOL) viene inserita in un’area di staging o direttamente in FINEOS.
Perché è importante

Questa attività rappresenta il principale evento di avvio del processo. Analizzare il tempo che intercorre tra la presentazione e la registrazione aiuta a individuare i ritardi nell’inserimento dei dati e nella configurazione iniziale del sinistro, con un impatto sul tempo di ciclo complessivo.

Dove reperirlo

Probabilmente viene acquisito dalla data di creazione della registrazione iniziale della notifica del sinistro o dell’inserimento della FNOL in FINEOS. Può trattarsi di un evento esplicito dell’event log oppure di un evento dedotto dal timestamp più antico associato al Claim ID.

Acquisizione

Utilizzi il timestamp di creazione della First Notice of Loss (FNOL) o della registrazione iniziale del sinistro.

Tipo di evento inferred
Sinistro registrato
Rappresenta la creazione formale della registrazione del sinistro all’interno del sistema FINEOS. A questo punto viene assegnato ufficialmente un Claim ID univoco e il caso viene aperto formalmente per l’elaborazione. L’evento viene normalmente acquisito dal timestamp di creazione dell’oggetto principale del sinistro.
Perché è importante

Si tratta di una tappa fondamentale, che trasforma il sinistro da semplice notifica a caso attivo. Costituisce un punto di partenza affidabile per misurare il ciclo di elaborazione interno.

Dove reperirlo

Deriva dal timestamp di creazione dell’entità principale del caso di sinistro nel database FINEOS. La maggior parte degli oggetti fondamentali del sistema dispone di una ‘data di creazione’ registrata a fini di audit.

Acquisizione

Utilizzi il timestamp di creazione della registrazione principale del caso di sinistro.

Tipo di evento explicit
Accertamento avviato
Rappresenta l’inizio della fase formale di accertamento o valutazione del sinistro. Spesso viene registrato quando il sinistro viene assegnato a un investigatore o quando il suo stato viene modificato esplicitamente in ‘In fase di accertamento’ in FINEOS.
Perché è importante

Questa tappa segna l’inizio di una parte potenzialmente lunga e complessa del processo. Monitorarne l’orario di avvio è essenziale per misurare la durata e l’efficienza della fase di accertamento.

Dove reperirlo

Viene dedotto dal timestamp della modifica dello stato a ‘In fase di accertamento’ o ‘Valutazione in corso’. Può anche essere collegato alla data di assegnazione del ruolo di investigatore al sinistro.

Acquisizione

Timestamp della modifica dello stato del sinistro a ‘In fase di accertamento’.

Tipo di evento inferred
Accertamento completato
Indica che tutte le attività di accertamento necessarie sono concluse e che il sinistro è pronto per la decisione finale. Viene dedotto dalla modifica dello stato da ‘In fase di accertamento’ a uno stato successivo, come ‘In attesa di decisione’ o ‘Pronto per la valutazione’.
Perché è importante

Questa attività segna la fine della fase di raccolta delle evidenze. Analizzare il tempo che intercorre tra ‘Accertamento avviato’ e questo momento aiuta a individuare i colli di bottiglia nel processo di valutazione.

Dove reperirlo

Viene dedotto dal timestamp della modifica dello stato del sinistro da ‘In fase di accertamento’ a uno stato che indica il passaggio successivo alla fase decisionale o di valutazione.

Acquisizione

Timestamp della modifica dello stato del sinistro da ‘In fase di accertamento’ a ‘Pronto per la decisione’.

Tipo di evento inferred
Informazioni aggiuntive ricevute
Indica la ricezione dei documenti o delle informazioni richiesti, consentendo la ripresa della gestione del sinistro. L’evento viene normalmente dedotto quando lo stato del sinistro passa da ‘In attesa di informazioni’ a uno stato attivo, come ‘In revisione’ o ‘Pronto per la valutazione’.
Perché è importante

Misurare il tempo che intercorre tra la richiesta e la ricezione delle informazioni evidenzia i ritardi esterni. Segnala inoltre la ripresa dell’elaborazione interna, risultando quindi fondamentale per analizzare i tempi di attesa e i blocchi del processo.

Dove reperirlo

Viene dedotto dal timestamp della modifica dello stato del sinistro da una condizione di ‘In attesa’ a una condizione ‘Attiva’ o ‘In corso’. Anche un evento di caricamento di un documento associato può fornire un timestamp specifico.

Acquisizione

Timestamp della modifica dello stato da ‘In attesa di informazioni’ a uno stato di elaborazione attivo.

Tipo di evento inferred
Informazioni aggiuntive richieste
Questa attività si verifica quando il responsabile della gestione dei sinistri stabilisce che sono necessarie ulteriori informazioni da parte del richiedente o di terzi per procedere. In FINEOS viene spesso registrata tramite la modifica dello stato a ‘In attesa di informazioni’ oppure mediante la registrazione di uno specifico evento di comunicazione in uscita.
Perché è importante

Si tratta di un’attività fondamentale per analizzare le rilavorazioni e i cicli di processo. Un’elevata frequenza di questo evento suggerisce problemi nella raccolta iniziale dei dati e può rappresentare una fonte significativa di ritardi.

Dove reperirlo

Viene dedotto dalla modifica dello stato del sinistro a ‘In attesa di informazioni’ o a uno stato analogo. Potrebbe anche corrispondere a un evento esplicito registrato quando dal sistema viene generata una comunicazione con la richiesta di informazioni.

Acquisizione

Timestamp della modifica dello stato a ‘In attesa di informazioni’ o voce di log relativa alla lettera o all’e-mail di richiesta delle informazioni.

Tipo di evento inferred
Liquidazione calcolata
Si verifica dopo una decisione di approvazione, quando viene calcolato l’importo esatto del pagamento sulla base dei massimali di polizza, delle franchigie e delle perdite valutate. Probabilmente viene registrato quando l’importo finale del pagamento o della liquidazione viene inserito e confermato in FINEOS.
Perché è importante

Questa attività separa la fase di calcolo da quelle di approvazione e autorizzazione del pagamento. Aiuta ad analizzare l’efficienza del team finanziario nel finalizzare gli importi da pagare.

Dove reperirlo

Viene dedotto dal timestamp in cui l’importo finale della liquidazione o del pagamento viene inserito o aggiornato nelle registrazioni finanziarie del sinistro.

Acquisizione

Utilizzi il timestamp di ‘ultimo aggiornamento’ del campo relativo all’importo finale della liquidazione.

Tipo di evento inferred
Perdita valutata
Indica che l’impatto economico del sinistro è stato calcolato e registrato. Può includere la valutazione dei danni, delle spese mediche o di altre responsabilità. L’evento viene spesso acquisito quando specifici campi relativi alla valutazione finanziaria vengono compilati e salvati in FINEOS.
Perché è importante

Si tratta di una tappa finanziaria fondamentale. Il tempo necessario per valutare la perdita dopo il completamento dell’accertamento può essere un indicatore delle performance del team di valutazione.

Dove reperirlo

Probabilmente viene dedotto dal timestamp in cui i campi relativi alla riserva finanziaria o alla stima della perdita vengono compilati per la prima volta o finalizzati nel sistema. Potrebbe non essere uno stato distinto, bensì un evento di inserimento dati.

Acquisizione

Utilizzi il timestamp di ‘ultimo aggiornamento’ dei campi relativi alla valutazione finanziaria o alla riserva.

Tipo di evento inferred
Revisione iniziale completata
Indica che un liquidatore o un addetto alla gestione ha completato la prima valutazione della validità del sinistro, dei dettagli e della documentazione necessaria. Spesso viene dedotto da una modifica dello stato in FINEOS, ad esempio dal passaggio da ‘Nuovo’ o ‘Registrato’ a ‘In revisione’ o ‘Assegnato’.
Perché è importante

Monitorare il completamento di questa fase aiuta a misurare il tempo necessario per la prima azione e a individuare gli arretrati nella fase iniziale di triage e assegnazione. I ritardi in questa fase possono prolungare significativamente l’intero ciclo di vita del sinistro.

Dove reperirlo

Viene dedotto dal timestamp della modifica dello stato del sinistro a una condizione che indica il completamento della revisione, ad esempio ‘Revisione iniziale completata’, ‘In attesa di informazioni’ o ‘In fase di accertamento’. Questi dati si trovano normalmente in una tabella dello storico degli stati del sinistro.

Acquisizione

Individui il timestamp della modifica dello stato da ‘Nuovo’ o ‘Aperto’ a uno stato successivo alla revisione.

Tipo di evento inferred
Sinistro respinto
Rappresenta l’esito finale di un sinistro non approvato per il pagamento. L’evento viene acquisito quando lo stato del sinistro viene impostato definitivamente su ‘Respinto’ o ‘Rifiutato’. Costituisce un punto finale alternativo del processo.
Perché è importante

Questa attività rappresenta un punto finale fondamentale del processo. Analizzare i percorsi che conducono al respingimento può offrire insight sulla qualità della raccolta iniziale, sull’interpretazione della polizza o su potenziali schemi fraudolenti.

Dove reperirlo

Viene dedotto dal timestamp in cui lo stato finale del sinistro viene registrato come ‘Respinto’ o ‘Rifiutato’ nella tabella dello storico degli stati.

Acquisizione

Timestamp della modifica finale dello stato a ‘Respinto’ o ‘Rifiutato’.

Tipo di evento inferred
Sinistro riaperto
Si verifica quando un sinistro precedentemente chiuso viene riattivato per ulteriori verifiche o attività, spesso a seguito di un ricorso o di nuove informazioni. L’evento viene acquisito tramite una modifica dello stato da ‘Chiuso’ o ‘Respinto’ a uno stato attivo come ‘In revisione’.
Perché è importante

Monitorare i sinistri riaperti è fondamentale per comprendere le eccezioni e le criticità del processo. Mette in evidenza i casi che non sono stati risolti correttamente al primo tentativo, con un impatto sull’efficienza e sui costi operativi.

Dove reperirlo

Viene dedotto dalla modifica dello stato da una condizione terminale, ad esempio ‘Chiuso’, a una condizione attiva non terminale, come ‘Riaperto’ o ‘In revisione’. È necessario analizzare la sequenza delle modifiche di stato nel tempo.

Acquisizione

Individui il timestamp in cui lo stato passa da una condizione chiusa a una condizione aperta.

Tipo di evento inferred
Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da FINEOS Claims

I metodi di estrazione per questo processo sono attualmente in fase di convalida. Torni a consultare la pagina più avanti oppure ci contatti per ricevere assistenza.

È pronto per iniziare?

Questo Template è stato progettato per semplificare la preparazione dei dati, consentendoLe di passare rapidamente all'individuazione di informazioni utili e al miglioramento delle operazioni di gestione dei sinistri. Inizi oggi a valorizzare i Suoi dati per aumentare l'efficienza e migliorare la soddisfazione degli assicurati.

Accelerare la gestione dei sinistri: inizi oggi

Si unisca ai leader che raggiungono il 70% di elaborazione straight-through in FINEOS.

Inizi la prova gratuita

Non è richiesta alcuna carta di credito; configurazione in pochi minuti.