Votre modèle de données pour la gestion des sinistres

Guidewire ClaimCenter
Votre modèle de données pour la gestion des sinistres

Votre modèle de données pour la gestion des sinistres

Bienvenue dans votre ressource dédiée à l’optimisation de la gestion des sinistres. Ce modèle présente les attributs de données essentiels à collecter, les activités importantes à suivre et des indications claires pour l’extraction des données. Utilisez-le pour vous assurer de recueillir toutes les informations nécessaires à une analyse complète des processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d’extraction pour Guidewire ClaimCenter
Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Attributs de la Gestion des sinistres

Ces champs de données recommandés sont essentiels pour constituer un journal d’événements complet et analyser efficacement vos flux de travail de gestion des sinistres.
3 Obligatoire 4 Recommandé 14 Facultatif
Nom Description
Heure de l’événement
EventTime
Date et heure précises auxquelles l’activité s’est produite.
Description

Cet horodatage indique le moment exact où l’activité a été enregistrée dans le système. Il est indispensable à toute analyse temporelle des processus.

Le classement chronologique des valeurs EventTime pour un Claim ID donné permet de reconstituer le flux du processus. L’écart entre deux événements consécutifs sert à calculer les délais de cycle, les temps d’attente et les temps de traitement, qui sont essentiels pour analyser la performance, identifier les goulots d’étranglement et suivre les SLA.

Pourquoi c’est important

Cet horodatage est essentiel pour ordonner les événements, calculer les délais de cycle et les durées, et identifier les retards dans le processus.

Où les obtenir

Il se trouve avec les données d’événements ou d’activités dans les tables d’historique ou d’audit de Guidewire ClaimCenter, souvent sous la forme d’un champ « CreateTime » ou « UpdateTime ».

Exemples
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Identifiant du sinistre
ClaimID
Identifiant unique de chaque sinistre d’assurance, utilisé comme identifiant principal du dossier.
Description

Le Claim ID est la clé de voûte de l’analyse du processus de gestion des sinistres. Il identifie de manière unique chaque dossier, de sa soumission à sa clôture. Il relie toutes les activités, tous les documents, paiements et échanges associés, afin de fournir une vision complète et cohérente du cycle de vie du sinistre.

Dans le Process Mining, chaque événement du jeu de données est associé à un Claim ID, ce qui permet de reconstituer le flux du processus de bout en bout. Cette association est essentielle pour analyser les délais de cycle, identifier les variantes du processus et suivre le parcours d’un sinistre entre les différents services et gestionnaires.

Pourquoi c’est important

Il s’agit de la clé fondamentale qui relie tous les événements associés et permet de retracer et d’analyser l’intégralité du parcours d’un sinistre donné.

Où les obtenir

Il s’agit d’une clé primaire dans Guidewire ClaimCenter, généralement présente sous la forme de Claim.ClaimNumber ou d’un champ similaire dans l’entité Claim principale.

Exemples
000-123-45678000-987-65432001-456-11223
Nom de l’activité
ActivityName
Nom de l’activité métier ou de l’événement survenu à un moment précis du cycle de vie du sinistre.
Description

Cet attribut décrit une étape ou une étape clé précise du processus de gestion des sinistres, comme « Claim Created », « Investigation Started » ou « Payment Issued ». La séquence de ces activités pour un Claim ID donné constitue le flux du processus.

L’analyse de la séquence, de la fréquence et de la durée entre les activités est au cœur du Process Mining. Elle permet de découvrir les modèles de processus, d’identifier les goulots d’étranglement, de détecter les boucles de reprise et d’analyser les écarts du processus.

Pourquoi c’est important

Il définit les étapes du processus et permet de visualiser les cartes de processus, ainsi que d’analyser le flux et les goulots d’étranglement.

Où les obtenir

Il est généralement dérivé des tables d’événements ou des journaux d’audit de ClaimCenter, souvent en associant certains événements système ou changements de statut à des noms d’activité standardisés.

Exemples
Sinistre crééDécision de responsabilité prisePaiement émisSinistre clôturé
Cause du sinistre
LossCause
Raison ou cause précise de l’événement à l’origine du dommage, par exemple collision, incendie ou dégât des eaux.
Description

Cet attribut fournit un contexte détaillé sur la raison de la déclaration du sinistre. La cause du dommage détermine souvent les étapes d’instruction nécessaires, le type d’experts à mobiliser et la complexité globale du sinistre.

L’analyse du processus par cause du sinistre peut révéler des tendances difficiles à détecter. Par exemple, les sinistres liés à un « dégât des eaux » peuvent présenter davantage de reprises ou nécessiter l’intervention de spécialistes plus souvent que les sinistres liés à un « vol ». Ces analyses contribuent à concevoir des procédures de traitement plus spécialisées et plus efficaces.

Pourquoi c’est important

Fournit un contexte sur la nature du sinistre et permet d’analyser l’incidence des différentes causes sur le déroulement et la durée du processus.

Où les obtenir

Il s’agit d’un champ standard de l’entité Claim, généralement nommé « LossCause ».

Exemples
CollisionIncendieDégât des eauxVol
Gestionnaire de sinistre affecté
AssignedAdjuster
Nom ou identifiant de l’utilisateur chargé de traiter le sinistre ou une activité donnée.
Description

Cet attribut identifie le gestionnaire de sinistre responsable d’un dossier à un moment donné. Un gestionnaire peut être affecté à l’ensemble du sinistre ou à certaines tâches seulement.

L’analyse par gestionnaire de sinistre affecté est essentielle pour équilibrer la charge de travail, suivre les performances et repérer les besoins de formation. Elle permet notamment de répondre aux questions suivantes : « Quels gestionnaires ont le plus grand nombre de dossiers ? », « Existe-t-il des écarts de performance entre les gestionnaires ? » et « La charge de travail est-elle répartie équitablement ? »

Pourquoi c’est important

Suit l’implication des utilisateurs et permet d’analyser la charge de travail, de comparer les performances et d’identifier les goulots d’étranglement liés aux ressources.

Où les obtenir

Disponible dans l’entité Claim ou Exposure de ClaimCenter, souvent associé à l’objet User, par exemple Claim.Assignee.

Exemples
j.doem.smiths.jones
Statut du sinistre
ClaimStatus
Statut global du sinistre au moment de l’événement, par exemple ouvert, clôturé ou refusé.
Description

Cet attribut reflète l’état général du sinistre. Les principaux statuts sont « Open », « Closed », « Denied » et « Reopened ». Le statut final d’un sinistre constitue un indicateur de résultat essentiel.

Le suivi des changements de statut du sinistre permet de définir les principales étapes et les résultats du processus. Il sert à identifier la résolution finale d’un sinistre, à calculer les taux de refus et à analyser la fréquence des réouvertures après clôture, qui peut révéler des problèmes de processus ou une insatisfaction des clients.

Pourquoi c’est important

Indique le résultat d’un sinistre, ce qui est essentiel pour analyser les taux de refus, les schémas de clôture et la fréquence des réouvertures.

Où les obtenir

Il s’agit d’un champ central de l’entité Claim, généralement nommé « State » ou « Status ».

Exemples
OuvertClôturéRefuséRouverte
Type de sinistre
ClaimType
Catégorie du sinistre d’assurance, par exemple automobile, habitation ou responsabilité civile.
Description

Le type de sinistre constitue une catégorisation fondamentale fondée sur la branche d’activité ou la nature du dommage. Les différents types de sinistres suivent souvent des processus distincts, présentent des niveaux de complexité différents et sont soumis à des réglementations spécifiques.

La segmentation de l’analyse du processus par type de sinistre est essentielle pour obtenir des résultats pertinents. Elle permet de comparer les performances entre différentes branches d’activité, d’identifier les goulots d’étranglement propres à chaque type et d’adapter les initiatives d’amélioration aux caractéristiques de chaque catégorie de sinistre.

Pourquoi c’est important

Permet de segmenter les sinistres, car les différents types, par exemple automobile et habitation, suivent souvent des processus distincts et répondent à des objectifs de performance différents.

Où les obtenir

Dérivé de l’entité Policy ou Claim dans ClaimCenter, souvent à partir du code Line of Business (LOB).

Exemples
Automobile particulièreDommages aux biens professionnelsResponsabilité civile généraleAccidents du travail
Date cible de résolution
ResolutionTargetDate
Date à laquelle le sinistre doit être résolu conformément aux SLA internes ou réglementaires.
Description

La date cible de résolution correspond à l’échéance fixée pour la clôture du sinistre. Elle est souvent déterminée par la juridiction, le type de sinistre et les conditions de la police. Elle sert de référence pour mesurer les performances et la conformité.

Cet attribut est essentiel à la création de Dashboards et de KPI de respect des SLA. En comparant la date réelle de clôture du sinistre à cette date cible, l’analyse peut signaler automatiquement les sinistres en retard, mesurer le taux de respect des délais et identifier les types de sinistres ou les services qui peinent à atteindre leurs objectifs.

Pourquoi c’est important

Constitue la référence pour mesurer le respect des Service Level Agreements (SLA) et identifier les sinistres susceptibles d’être traités en retard.

Où les obtenir

Il peut s’agir d’un champ personnalisé ou d’une valeur dérivée de règles métier configurées dans ClaimCenter, éventuellement liées à des indicateurs spécifiques des sinistres.

Exemples
2023-06-142023-07-202023-08-28
Date du sinistre
LossDate
Date à laquelle s’est produit l’incident ou le dommage à l’origine du sinistre.
Description

La date du sinistre correspond à la date de l’événement réel, par exemple un accident de voiture ou un dommage matériel, à l’origine de la déclaration. Elle se distingue de la date de déclaration ou de création du sinistre.

Le délai entre la date du sinistre et l’activité « Claim Created », appelé délai de déclaration, constitue un KPI important. Son analyse peut fournir des indications sur le comportement des clients et sur l’efficacité des canaux de première déclaration de sinistre.

Pourquoi c’est important

Fournit un contexte essentiel sur l’origine du sinistre et permet d’analyser le délai de déclaration, c’est-à-dire le temps écoulé entre l’incident et la déclaration.

Où les obtenir

Il s’agit d’un champ de date fondamental de l’entité Claim, souvent nommé « LossDate ».

Exemples
2023-05-102023-04-202023-05-28
Demande d’informations répétée
RepeatedInfoRequestFlag
Indicateur précisant si « Additional Info Requested » s’est produit plusieurs fois pour le même sinistre.
Description

Cet indicateur booléen prend la valeur true lorsqu’un sinistre comporte plusieurs activités « Additional Info Requested ». Cette situation révèle souvent des inefficacités lors de la collecte initiale des informations.

Cet attribut alimente directement le KPI « Repeated Info Request Rate ». Il permet de quantifier les lacunes de la collecte initiale des faits, susceptibles d’entraîner des retards importants et de mécontenter les clients. L’analyse des sinistres associés à cet indicateur peut contribuer à améliorer les listes de contrôle et les procédures des gestionnaires afin que toutes les informations nécessaires soient demandées dès le départ.

Pourquoi c’est important

Identifie les inefficacités liées à une collecte d’informations incomplète au premier passage, qui entraîne des retards et des reprises dans le processus.

Où les obtenir

Calculé dans l’outil de Process Mining en comptant les occurrences de l’activité « Additional Info Requested » pour chaque cas.

Exemples
truefalse
Dernière mise à jour des données
LastDataUpdate
Horodatage indiquant la dernière actualisation ou extraction des données depuis le système source.
Description

Cet attribut fournit l’horodatage de l’extraction la plus récente des données depuis le système source. Il s’agit d’un champ de métadonnées essentiel pour évaluer la fraîcheur de l’analyse.

Les Dashboards et les analyses doivent afficher cette information de manière visible afin que les utilisateurs connaissent l’actualité des données. Elle permet de déterminer si les analyses reflètent l’état actuel des opérations ou si elles reposent sur des données plus anciennes.

Pourquoi c’est important

Indique la fraîcheur des données afin que les utilisateurs sachent dans quelle mesure l’analyse du processus est à jour.

Où les obtenir

Cette valeur est générée et enregistrée pendant le processus ETL. Elle correspond à l’horodatage du chargement des données.

Exemples
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Est automatisé
IsAutomated
Indicateur précisant si une activité a été exécutée automatiquement par le système ou par un utilisateur humain.
Description

Cet attribut booléen distingue les activités exécutées par le système, par exemple la création automatique d’une provision ou la génération d’une correspondance, de celles réalisées manuellement par un gestionnaire de sinistre.

Son analyse est essentielle pour comprendre le niveau d’automatisation du processus de gestion des sinistres. Elle permet d’identifier les points nécessitant une intervention manuelle, de mesurer l’efficacité des initiatives de traitement automatisé de bout en bout et de repérer de nouvelles possibilités d’automatisation en ciblant les tâches répétitives fondées sur des règles qui sont encore réalisées par des personnes.

Pourquoi c’est important

Distingue les activités pilotées par le système de celles réalisées par des personnes, ce qui est essentiel pour analyser l’automatisation et identifier les goulots d’étranglement manuels.

Où les obtenir

Cette valeur doit souvent être déduite. Par exemple, les événements enregistrés par un utilisateur générique « system » peuvent être considérés comme automatisés.

Exemples
truefalse
Est une reprise
IsRework
Indicateur précisant si une activité correspond à une boucle de reprise, c’est-à-dire à un retour à une étape précédente du processus.
Description

Cet attribut calculé signale les activités qui font partie d’une boucle de reprise. Par exemple, si le processus passe de « Investigation Completed » à « Investigation Started », la seconde activité « Investigation Started » est signalée comme une reprise.

L’identification des reprises est fondamentale pour révéler les inefficacités du processus et les problèmes de qualité. Le Dashboard « Rework and Rejection Frequency » s’appuie sur cette mesure pour quantifier la fréquence à laquelle les sinistres s’écartent du parcours nominal. L’analyse des causes des reprises peut entraîner des améliorations importantes de la qualité et de la rapidité du processus.

Pourquoi c’est important

Met en évidence les inefficacités du processus et les problèmes de qualité en signalant explicitement les activités qui font partie d’une boucle de reprise.

Où les obtenir

Cette valeur est calculée dans l’outil de Process Mining en analysant la séquence des activités pour chaque cas.

Exemples
truefalse
Heure de fin
EndTime
Horodatage indiquant la fin d’une activité.
Description

L’heure de fin marque l’achèvement d’une activité, en particulier pour les tâches dont la durée peut être mesurée, comme « Investigation » ou « Document Review ». De nombreuses activités de Process Mining sont instantanées, et StartTime suffit alors. En revanche, les activités qui comportent un début et une fin distincts sont mieux représentées par les deux horodatages.

Cet attribut permet de calculer précisément le temps de traitement d’une activité, indépendamment du temps d’attente. Il aide à identifier les tâches qui prennent réellement du temps, plutôt que de simplement constater de longs délais entre différentes étapes.

Pourquoi c’est important

Permet de mesurer précisément le temps nécessaire à l’achèvement d’une activité, en distinguant le temps de traitement du temps d’attente.

Où les obtenir

Cette valeur peut devoir être déduite en recherchant un événement ultérieur qui clôt logiquement l’activité, par exemple le passage du statut « In Progress » à « Completed ».

Exemples
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Juridiction compétente
JurisdictionState
État ou juridiction régissant le sinistre et déterminant les exigences réglementaires applicables.
Description

Cet attribut précise la juridiction légale, par exemple l’État américain, dans laquelle le sinistre est traité. Les réglementations d’assurance peuvent varier considérablement d’une juridiction à l’autre et avoir une incidence sur les étapes requises, les délais de communication et les documents à fournir.

Cet attribut est essentiel au suivi de la conformité. L’analyse du processus par juridiction permet de vérifier le respect des exigences réglementaires propres à chaque État. Elle peut également expliquer les variations de durée de traitement ou de parcours du processus qui résultent de contraintes légales plutôt que d’une inefficacité opérationnelle.

Pourquoi c’est important

Essentiel à l’analyse de la conformité, car les différentes juridictions appliquent des réglementations distinctes qui influencent le traitement des sinistres.

Où les obtenir

Champ standard de l’entité Claim, généralement nommé « JurisdictionState ».

Exemples
CANYTXFL
Montant déclaré
ClaimedAmount
Montant total initialement réclamé par le titulaire de la police.
Description

Cet attribut représente la valeur du dommage déclarée par le demandeur. Il s’agit souvent d’une première estimation, susceptible d’évoluer au cours de l’instruction du sinistre et de la constitution des provisions.

L’analyse du montant déclaré permet de segmenter les sinistres selon leur impact financier. Les sinistres de montant élevé suivent souvent un processus plus rigoureux et plus complexe que ceux de faible montant. La comparaison des processus par tranche de valeur peut révéler des possibilités de simplification pour les petits sinistres ou justifier des contrôles plus stricts pour les montants élevés.

Pourquoi c’est important

Permet de segmenter les sinistres selon leur valeur financière, car les sinistres de montant élevé peuvent suivre des processus différents et plus complexes.

Où les obtenir

Cette information peut ne pas correspondre à un champ unique. Elle peut être déduite des premières estimations du dommage enregistrées dans les objets Exposure.

Exemples
5000.00150000.00750.50
Montant du paiement
PaymentAmount
Montant effectivement versé pour une activité de paiement.
Description

Cet attribut enregistre la valeur de chaque paiement effectué au titre d’un sinistre. Un même sinistre peut donner lieu à plusieurs paiements au cours de son cycle de vie.

Il est essentiel à l’analyse financière dans le contexte du Process Mining. Il permet de suivre le montant total versé par sinistre, d’analyser les délais d’approbation des paiements selon leur montant et de mettre en relation les inefficacités du processus avec les résultats financiers. Par exemple, les sinistres dont le cycle est long peuvent être associés à des montants totaux plus élevés.

Pourquoi c’est important

Suit les transactions financières liées à un sinistre et permet d’analyser les montants des paiements ainsi que leur relation avec les activités du processus.

Où les obtenir

Se trouve dans les entités liées aux paiements et associées au sinistre, souvent dans une table de transactions ou de chèques.

Exemples
4500.00125000.00500.00
Service
Department
Unité opérationnelle ou service chargé de traiter l’activité liée au sinistre.
Description

Cet attribut indique le service ou l’équipe auquel appartient le gestionnaire de sinistre affecté, par exemple « Auto Claims », « Property Claims » ou « Special Investigations Unit ». Il fournit un contexte organisationnel au processus.

L’analyse par service est essentielle pour comprendre les performances du processus à l’échelle de l’organisation. Elle permet d’identifier les délais lors des transferts entre services, de comparer l’efficacité des équipes et de répartir plus efficacement les ressources au sein de l’organisation chargée des sinistres.

Pourquoi c’est important

Fournit un contexte organisationnel qui permet d’analyser les performances de différentes équipes et de mettre en évidence les problèmes liés aux transferts entre services.

Où les obtenir

Ces informations sont généralement associées au profil de l’utilisateur ou du groupe affecté dans ClaimCenter.

Exemples
Division des sinistres automobilesUnité des sinistres dommages aux biensUnité des enquêtes spéciales (SIU)
Statut du SLA
SLAState
Indique si le sinistre a été clôturé dans le délai cible de résolution.
Description

Cet attribut calculé fournit, pour chaque sinistre clôturé, un statut catégoriel de respect du SLA. Il est obtenu en comparant l’horodatage de l’activité « Claim Closed » à la « Resolution Target Date ».

Cet attribut alimente directement le Dashboard « Claim Resolution Target Adherence » en simplifiant l’analyse au moyen de catégories claires telles que « On Time » ou « Late ». Il facilite le filtrage et l’agrégation nécessaires au calcul du taux global de respect des SLA, ainsi que l’analyse détaillée des causes des retards.

Pourquoi c’est important

Fournit un résultat catégoriel clair sur le respect des SLA et facilite le filtrage, l’agrégation et l’analyse des performances dans les délais.

Où les obtenir

Champ calculé : IF (ActualCloseDate <= ResolutionTargetDate, 'On Time', 'Late').

Exemples
Dans les délaisEn retard
Système source
SourceSystem
Système à partir duquel les données ont été extraites.
Description

Cet attribut identifie l’origine des données d’événements. Dans un environnement d’entreprise moderne, les événements liés aux sinistres peuvent provenir de plusieurs systèmes, comme un système central tel que Guidewire, un système de gestion documentaire ou un portail client.

La précision du système source est essentielle pour la gouvernance des données, le diagnostic des incohérences et la compréhension de l’environnement technologique du processus. Elle permet de distinguer les étapes du processus principal des activités de support réalisées dans des systèmes périphériques.

Pourquoi c’est important

Il identifie l’origine des données, ce qui est essentiel pour la gouvernance des données et les analyses portant sur plusieurs systèmes intégrés.

Où les obtenir

Il s’agit généralement d’une valeur statique ajoutée lors du processus d’extraction, de transformation et de chargement (ETL) des données.

Exemples
Guidewire ClaimCenter v10API du portail clientDocumentum
Type de police
PolicyType
Type précis de police d’assurance au titre de laquelle le sinistre a été déclaré.
Description

Le type de police fournit une classification plus détaillée que le type de sinistre en précisant le produit d’assurance concerné, par exemple « Homeowners », « Commercial Auto » ou « Cyber Liability ». Ce niveau de détail peut révéler des variations de processus liées à certains produits.

L’analyse du processus par type de police aide à repérer les inefficacités propres à certains produits. Par exemple, les sinistres liés à une police récemment lancée peuvent suivre un processus moins mature et entraîner des retards. Cette analyse peut guider la conception des produits et les efforts de standardisation des processus.

Pourquoi c’est important

Permet d’analyser le processus pour des produits d’assurance précis et d’identifier les différences de traitement liées aux caractéristiques des polices.

Où les obtenir

Ces informations se trouvent dans l’entité Policy, qui est liée à Claim.

Exemples
Multirisque habitationResponsabilité civile automobile professionnelleTransport maritime intérieur
Obligatoire Recommandé Facultatif

Activités de la Gestion des sinistres

Voici les principales étapes du processus et les jalons importants à enregistrer dans votre journal d’événements pour reconstituer et analyser précisément le processus de gestion des sinistres.
7 Recommandé 7 Facultatif
Activité Description
Exposition créée
Cette activité correspond à la création d’une exposition, qui représente un engagement potentiel précis ou un type de perte couvert par le sinistre, par exemple des dommages au véhicule ou des blessures. Il s’agit d’un événement explicite dans Guidewire.
Pourquoi c’est important

Les expositions sont fondamentales pour segmenter et analyser les sinistres. Le suivi de leur création permet de comprendre les variations du processus selon la complexité du sinistre et le type de perte.

Où les obtenir

L’événement est extrait du CreateTime d’un nouvel enregistrement dans la table cc_exposure. Chaque enregistrement est rattaché à un Claim ID unique.

Collecte

Identifiez l’horodatage de création d’un nouvel enregistrement dans la table de l’entité Exposure.

Type d’événement explicit
Paiement approuvé
Cette activité représente l’approbation officielle d’un paiement de règlement. Il s’agit d’un événement d’audit important, enregistré explicitement lorsqu’un utilisateur habilité approuve la transaction.
Pourquoi c’est important

Cette étape clé débloque l’étape finale du paiement. L’analyse du temps avant et après cette activité permet d’isoler les retards liés aux flux de travail d’approbation ou à la disponibilité des responsables.

Où les obtenir

Il s’agit souvent d’un événement explicite enregistré dans la table cc_history et lié à une entité cc_check ou cc_transaction, qui consigne le changement de statut de « Pending Approval » à « Approved ».

Collecte

Suivez l’événement de changement de statut vers « Approved » pour une transaction de paiement donnée.

Type d’événement explicit
Paiement émis
Cette activité marque la dernière étape du processus de paiement, lorsque le paiement est officiellement émis et transmis au système financier. Il s’agit d’une transaction financière explicite et enregistrée.
Pourquoi c’est important

Cette activité est essentielle pour mesurer l’efficacité du processus d’émission des paiements. Elle permet de distinguer les retards d’approbation des retards liés à l’émission effective des fonds.

Où les obtenir

L’événement est extrait de l’IssueDate ou d’un changement de statut vers « Issued » ou « Submitted » sur l’entité cc_check ou cc_transaction. Il s’agit souvent d’un événement explicite horodaté.

Collecte

Identifiez l’IssueDate ou l’horodatage du changement de statut vers « Issued » sur l’enregistrement du paiement.

Type d’événement explicit
Réserve initiale définie
Cette activité marque la création de la première transaction de réserve financière pour une exposition, afin d’estimer le coût potentiel du sinistre. Il s’agit d’un événement financier important, enregistré explicitement.
Pourquoi c’est important

Cette étape est essentielle pour l’analyse financière et pour comprendre la rapidité avec laquelle l’engagement potentiel est évalué. Les retards peuvent avoir une incidence sur la planification et le reporting financiers.

Où les obtenir

L’événement est extrait de la création du premier enregistrement cc_reserveline associé à une exposition du sinistre. Le CreateTime de la transaction constitue l’horodatage de l’événement.

Collecte

Trouvez l’horodatage de création minimal de toutes les lignes de réserve associées aux expositions d’un sinistre donné.

Type d’événement explicit
Sinistre clôturé
Cette activité marque la clôture réussie d’un sinistre, une fois toutes les activités et tous les paiements terminés. Il s’agit du principal événement de fin réussi, déduit d’un changement du statut principal du sinistre.
Pourquoi c’est important

En tant qu’événement de fin principal, cette activité est essentielle pour calculer le délai de cycle de bout en bout et mesurer le respect des SLA. Elle signale la fin du cycle de vie du sinistre.

Où les obtenir

L’événement est déduit du changement du champ State de la table cc_claim vers « Closed ». L’horodatage de l’événement est le CloseDate de l’enregistrement du sinistre.

Collecte

Identifiez le moment où le champ de statut principal du sinistre est mis à jour vers « Closed ».

Type d’événement inferred
Sinistre créé
Cette activité correspond à la première déclaration de sinistre (FNOL) et à la création officielle d’un nouveau dossier de sinistre dans Guidewire ClaimCenter. Elle est enregistrée explicitement lorsqu’une nouvelle entité Claim est sauvegardée pour la première fois dans la base de données.
Pourquoi c’est important

En tant qu’événement de début principal, cette activité est essentielle pour mesurer le délai de cycle de bout en bout du sinistre. Elle constitue la référence pour tous les KPI ultérieurs de performance et de durée.

Où les obtenir

Il s’agit d’un événement explicite extrait du CreateTime de la table cc_claim. La création d’un nouvel enregistrement doté d’un Claim ID unique déclenche l’événement.

Collecte

Identifiez l’horodatage de création du nouvel enregistrement dans la table de l’entité Claim principale.

Type d’événement explicit
Sinistre refusé
Cette activité représente la décision finale de refuser un sinistre et constitue le point terminal du processus. L’événement est déduit du passage du statut du sinistre à un état fermé, avec le motif « Denied ».
Pourquoi c’est important

Il s’agit d’un événement de résultat important. L’analyse de la fréquence des refus, de leurs motifs et des parcours qui y mènent permet d’identifier les problèmes liés à la réception du sinistre, à l’instruction ou à l’interprétation de la police.

Où les obtenir

L’événement est déduit du changement du champ State de la table cc_claim vers « Closed », associé à la valeur « Denied » ou à une valeur similaire dans le champ CloseReason. L’horodatage de l’événement est le CloseDate.

Collecte

Filtrez les changements de statut des sinistres vers « Closed » lorsque le code motif indique un refus.

Type d’événement inferred
Décision de responsabilité prise
Cette activité indique le moment où la décision concernant la responsabilité ou la faute a été prise pour une exposition. L’événement est généralement déduit d’un changement de statut de l’entité Exposure.
Pourquoi c’est important

Il s’agit d’une étape de décision essentielle, qui conditionne les phases de règlement et de paiement. L’analyse du délai nécessaire pour parvenir à cette décision permet d’identifier les goulots d’étranglement lors de l’instruction et de l’évaluation.

Où les obtenir

L’événement est déduit de la table cc_history en suivant une modification du champ State ou d’un champ personnalisé de statut de responsabilité sur l’entité cc_exposure. L’horodatage de l’enregistrement d’historique indique le moment de l’événement.

Collecte

Surveillez les journaux d’audit ou les tables d’historique pour détecter les mises à jour de l’état ou du statut de responsabilité de l’exposition.

Type d’événement inferred
Informations complémentaires demandées
Cette activité représente une demande envoyée au déclarant ou à un tiers pour obtenir des informations ou des documents supplémentaires. Elle est généralement enregistrée comme une Activity, c’est-à-dire une tâche créée dans ClaimCenter.
Pourquoi c’est important

Cette activité constitue le point de départ du KPI « Additional Info Gathering Cycle Time ». Une fréquence élevée peut signaler des processus FNOL incomplets ou une collecte d’informations inefficace.

Où les obtenir

L’événement est extrait du CreateTime d’un enregistrement cc_activity dont l’ActivityPattern concerne une demande de documents ou d’informations auprès d’un tiers.

Collecte

Identifiez la création d’une tâche destinée à demander des informations externes.

Type d’événement explicit
Informations complémentaires reçues
Cette activité marque la clôture d’une demande d’informations complémentaires. Elle est enregistrée lorsque l’Activity correspondante, c’est-à-dire la tâche de demande d’informations, est marquée comme « Completed ».
Pourquoi c’est important

Il s’agit du point final du KPI « Additional Info Gathering Cycle Time ». Les délais importants entre la demande et la réception sont une source fréquente de retard dans le traitement des sinistres.

Où les obtenir

L’événement est extrait du CloseTime d’un enregistrement cc_activity dont l’ActivityPattern concerne une demande d’informations. Le statut de l’activité doit être « Completed ».

Collecte

Identifiez l’horodatage d’achèvement d’une tâche destinée à demander des informations externes.

Type d’événement explicit
Instruction commencée
Cette activité indique le début officiel de la phase d’instruction d’un sinistre ou d’une exposition. Elle est souvent déduite de la création de la première Activity liée à l’instruction dans Guidewire.
Pourquoi c’est important

Cette activité marque le début d’une phase essentielle, souvent longue. L’analyse du délai avant le début de l’instruction et de sa durée permet de révéler les principaux goulots d’étranglement.

Où les obtenir

L’événement est déduit du CreateTime d’un enregistrement cc_activity dont l’ActivityPattern est lié à l’instruction, par exemple « Initial Investigation » ou « Contact Witness ».

Collecte

Identifiez la première création d’une tâche dont le modèle ou l’objet est lié à l’instruction.

Type d’événement inferred
Montant du règlement calculé
Cette activité correspond au moment où le montant du règlement a été déterminé, mais pas encore approuvé pour paiement. Elle peut être déduite de la création d’un paiement à l’état « Pending Approval ».
Pourquoi c’est important

Elle marque le passage de l’évaluation au paiement. Elle constitue le point de départ du KPI « Payment Authorization Lead Time » et permet de repérer les retards dans la chaîne d’approbation.

Où les obtenir

L’événement est déduit du CreateTime d’un enregistrement cc_check ou cc_transaction dont le statut initial est « Pending Approval » ou un état similaire précédant « Approved ».

Collecte

Identifiez la création d’un enregistrement de paiement ou de transaction dans un statut préalable à l’approbation.

Type d’événement inferred
Sinistre attribué
Cette activité représente l’attribution d’un sinistre à un utilisateur précis, généralement un gestionnaire de sinistres, ou à un groupe chargé de son traitement. Elle est généralement déduite du suivi des modifications apportées aux champs d’attribution de l’entité Claim.
Pourquoi c’est important

Le suivi des attributions est essentiel pour analyser la charge de travail des gestionnaires de sinistres, repérer les goulots d’étranglement dans l’orientation des dossiers et mesurer le délai avant la première intervention du responsable désigné.

Où les obtenir

L’événement est déduit de la table cc_history en suivant les modifications des champs AssignedUser ou AssignedGroup associés à un Claim ID précis. L’horodatage de la modification indique le moment où l’événement s’est produit.

Collecte

Surveillez les journaux d’audit ou les tables d’historique pour détecter les mises à jour des champs d’attribution du sinistre.

Type d’événement inferred
Sinistre rouvert
Cette activité représente le passage d’un sinistre de l’état « Closed » à l’état « Open » afin d’effectuer des travaux supplémentaires. L’événement est déduit d’une séquence précise de changements de statut.
Pourquoi c’est important

Cette activité signale une reprise du traitement. Un volume élevé de sinistres rouverts peut indiquer des problèmes liés au règlement initial, des dommages non pris en compte ou d’autres défaillances du processus, avec à la clé une hausse des coûts et une baisse de l’efficacité.

Où les obtenir

L’événement est déduit de la table cc_history en identifiant le passage du champ State de l’entité cc_claim de « Closed » à « Open » ou à un autre état actif.

Collecte

Surveillez le champ de statut principal du sinistre pour détecter le passage d’un état fermé à un état ouvert.

Type d’événement inferred
Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de Guidewire ClaimCenter

Prêt à commencer ?

Utilisez ce modèle pour préparer vos données à l’analyse et obtenir une meilleure visibilité sur votre gestion des sinistres. Commencez dès aujourd’hui à optimiser vos flux de travail.

Accélérez la gestion des sinistres et résolvez les dossiers plus rapidement

Éliminez les retards accumulés, prévenez la fraude et visez 70 % de traitement de bout en bout sans intervention.

Démarrer l’essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes.