Votre modèle de données pour le traitement des sinistres

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

Votre modèle de données pour le traitement des sinistres

Retrouvez ici les ressources nécessaires pour optimiser le traitement des sinistres. Ce modèle présente les attributs de données essentiels à collecter, les activités importantes à suivre et des consignes claires pour extraire les données. Utilisez-le pour recueillir toutes les informations nécessaires à une analyse complète du processus.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Consignes d’extraction pour Guidewire ClaimCenter
Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Attributs du traitement 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 traitement des sinistres.
3 Obligatoire 4 Recommandé 14 Facultatif
Nom Description
Heure de l’événement
EventTime
La date et l’heure précises auxquelles l’activité a eu lieu.
Description

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

L’ordre chronologique des EventTime pour un même ID de sinistre permet de reconstituer le flux du processus. L’écart entre deux événements consécutifs sert à calculer les temps de cycle, les temps d’attente et les durées de traitement, des mesures essentielles pour analyser les performances, repérer les goulots d’étranglement et suivre les SLA.

Pourquoi est-ce important ?

Cet horodatage est essentiel pour ordonner les événements, calculer les temps de cycle et les durées, et repérer les retards dans le processus.

Où trouver ces données

Cette information figure avec les données d’événement ou d’activité dans l’historique ou les tables d’audit de Guidewire ClaimCenter, souvent dans un champ nommé « CreateTime » ou « UpdateTime ».

Exemples
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
ID de sinistre
ClaimID
Identifiant unique de chaque sinistre, qui sert d’identifiant principal du cas.
Description

L’ID de sinistre est la clé de voûte de l’analyse du processus de traitement des sinistres : il identifie chaque cas de manière unique, de sa soumission à sa clôture. Il relie toutes les activités, tous les documents, paiements et échanges associés, pour donner une vue complète et cohérente du cycle de vie du sinistre.

En process mining, chaque événement du jeu de données est associé à un ID de sinistre, ce qui permet de reconstituer le flux de travail de bout en bout. C’est indispensable pour analyser les temps de cycle, repérer les variantes du processus et suivre le parcours d’un sinistre entre les différents services et gestionnaires.

Pourquoi est-ce important ?

Cette clé fondamentale relie tous les événements associés et permet de retracer et d’analyser le parcours complet d’un sinistre.

Où trouver ces données

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

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

Cet attribut décrit une étape ou un jalon précis du processus de gestion des sinistres, par exemple « Sinistre créé », « Enquête commencée » ou « Paiement effectué ». La succession de ces activités pour un ID de sinistre donné constitue le flux du processus.

L’analyse de leur ordre, de leur fréquence et du temps écoulé entre elles est au cœur du Process Mining. Elle permet de découvrir les modèles de processus, de repérer les goulots d’étranglement, de détecter les boucles de reprise et d’analyser les écarts du processus.

Pourquoi est-ce important ?

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

Où trouver ces données

Cette information est généralement extraite des tables d’événements ou des journaux d’audit de ClaimCenter, en associant souvent des événements système ou des changements de statut précis à des noms d’activité normalisés.

Exemples
Sinistre crééDécision sur la responsabilité prisePaiement émisSinistre clôturé
Cause du sinistre
LossCause
Raison ou cause précise du sinistre, par exemple une collision, un incendie ou un dégât des eaux.
Description

Cet attribut précise la raison de la déclaration du sinistre. La cause détermine souvent les étapes d’enquête nécessaires, le type d’experts requis et la complexité globale du dossier.

L’analyse du processus par cause du sinistre peut révéler des tendances moins visibles. Par exemple, les sinistres liés à un dégât des eaux peuvent nécessiter davantage de reprises ou l’intervention de plus de spécialistes que les sinistres liés à un vol. Ces résultats aident à définir des procédures de traitement plus spécialisées et efficaces.

Pourquoi est-ce important ?

Précise 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ù trouver ces données

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

Exemples
CollisionIncendieDégât des eauxVol
Expert en sinistres affecté
AssignedAdjuster
Nom ou ID de l’utilisateur chargé du sinistre ou d’une activité précise.
Description

Cet attribut identifie l’expert en sinistres chargé d’un dossier à un moment donné. Un expert peut être affecté à l’ensemble du dossier ou à certaines tâches seulement.

L’analyse par expert en sinistres affecté est essentielle pour équilibrer la charge de travail, suivre les performances et repérer les besoins de formation. Elle permet de répondre à des questions telles que : « Quels experts ont le plus de dossiers à traiter ? », « Les performances varient-elles d’un expert à l’autre ? » et « Le travail est-il réparti équitablement ? ».

Pourquoi est-ce important ?

Suit la participation des utilisateurs afin d’analyser la charge de travail, de comparer les performances et de repérer les goulots d’étranglement liés aux ressources.

Où trouver ces données

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 général du sinistre au moment de l’événement, par exemple ouvert, clôturé ou refusé.
Description

Cet attribut indique l’état général du sinistre. Les principaux statuts sont « Ouvert », « Clôturé », « Refusé » et « Réouvert ». Le statut final d’un sinistre est un indicateur de résultat essentiel.

Le suivi des changements de statut permet de définir les principaux jalons et résultats du processus. Il sert à déterminer l’issue finale d’un sinistre, à calculer les taux de refus et à analyser la fréquence des réouvertures après clôture, souvent révélatrices de problèmes de processus ou d’insatisfaction des clients.

Pourquoi est-ce important ?

Indique l’issue du sinistre, une information essentielle pour analyser les taux de refus, les modalités de clôture et la fréquence des réouvertures.

Où trouver ces données

Champ central de l’entité Claim, généralement nommé « State » ou « Status ».

Exemples
OuvertClôturéRefuséRéouvert
Type de sinistre
ClaimType
Catégorie du sinistre, par exemple automobile, habitation ou responsabilité civile.
Description

Le type de sinistre est une catégorie fondamentale, définie selon le secteur 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.

Pour obtenir des résultats pertinents, il est essentiel de segmenter l’analyse du processus par type de sinistre. Cela permet de comparer les performances entre secteurs d’activité, de repérer les goulots d’étranglement propres à chaque type et d’adapter les initiatives d’amélioration aux caractéristiques de chaque catégorie de sinistres.

Pourquoi est-ce 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ù trouver ces données

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

Exemples
Automobile individuelleBiens commerciauxResponsabilité civile généraleAccidents du travail
Automatisé
IsAutomated
Indique si une activité a été réalisée automatiquement par le système ou par un utilisateur.
Description

Cet attribut booléen distingue les activités exécutées par le système, comme la création automatique de provisions ou l’envoi de courriers générés par le système, de celles réalisées manuellement par un expert en sinistres.

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

Pourquoi est-ce important ?

Distingue les activités réalisées par le système de celles effectuées par des personnes, ce qui est essentiel pour analyser l’automatisation et repérer les goulots d’étranglement liés aux interventions manuelles.

Où trouver ces données

Cette information doit souvent être déduite. Par exemple, les événements enregistrés par un utilisateur système générique peuvent être considérés comme automatisés.

Exemples
truefalse
Date cible de résolution
ResolutionTargetDate
Date à laquelle le sinistre devrait être résolu, conformément aux SLA internes ou réglementaires.
Description

La date cible de résolution est l’échéance fixée pour la clôture du sinistre. Elle dépend souvent de facteurs tels que 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 pour créer des Dashboards et des indicateurs de suivi des SLA. En comparant la date réelle de clôture du sinistre à la date cible, l’analyse peut signaler automatiquement les dossiers en retard, mesurer le taux de clôture dans les délais et repérer les types de sinistres ou les services qui peinent à atteindre leurs objectifs.

Pourquoi est-ce important ?

Sert de référence pour mesurer le respect des accords de niveau de service (SLA) et repérer les sinistres susceptibles d’être en retard.

Où trouver ces données

Il peut s’agir d’un champ personnalisé ou d’une valeur calculée selon les règles métier configurées dans ClaimCenter, éventuellement à partir de mesures propres aux 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 lui-même, par exemple un accident de voiture ou un dommage matériel. Elle diffère de la date de déclaration ou de création du dossier.

L’intervalle entre la date du sinistre et l’activité « Sinistre créé », appelé délai de déclaration, est un indicateur clé de performance. Son analyse peut éclairer les comportements des clients et l’efficacité des canaux de première déclaration de sinistre.

Pourquoi est-ce important ?

Apporte un contexte essentiel sur l’origine du sinistre et permet d’analyser le délai entre l’incident et la déclaration.

Où trouver ces données

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
Indique si l’activité « Informations complémentaires demandées » s’est produite plusieurs fois pour un même sinistre.
Description

Cet indicateur booléen prend la valeur vraie lorsqu’un sinistre comporte plusieurs activités « Informations complémentaires demandées ». Cette situation révèle souvent des lacunes dans la collecte initiale des informations.

Cet attribut alimente directement l’indicateur de performance « Taux de demandes d’informations répétées ». Il permet de mesurer le problème des vérifications initiales incomplètes, qui peuvent entraîner des retards importants et mécontenter les clients. L’analyse des sinistres signalés peut aider à améliorer les listes de contrôle et les procédures des experts, afin que toutes les informations nécessaires soient demandées en une seule fois.

Pourquoi est-ce important ?

Repère les inefficacités dues à une collecte d’informations incomplète dès la première demande, qui entraîne des retards et des reprises.

Où trouver ces données

Calculé dans l’outil de Process Mining en comptant, pour chaque cas, les occurrences de l’activité « Informations complémentaires demandées ».

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

Cet attribut indique l’horodatage de la dernière extraction des données depuis le système source. Ce champ de métadonnées est essentiel pour savoir si l’analyse repose sur des données récentes.

Les Dashboards et les analyses doivent afficher clairement cette information afin que les utilisateurs sachent de quand datent les données. Ils peuvent ainsi déterminer si les résultats reflètent l’état actuel des opérations ou s’ils reposent sur des données plus anciennes.

Pourquoi est-ce important ?

Indique la fraîcheur des données et permet aux utilisateurs de savoir si l’analyse du processus est à jour.

Où trouver ces données

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
État de la juridiction
JurisdictionState
État ou juridiction régissant le sinistre et déterminant les exigences réglementaires applicables.
Description

Cet attribut précise la juridiction compétente, par exemple l’État américain, dans laquelle le sinistre est traité. La réglementation de l’assurance varie considérablement d’une juridiction à l’autre et peut influer 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 aussi expliquer les différences de temps de cycle ou de parcours du processus dues à des contraintes juridiques plutôt qu’à des inefficacités opérationnelles.

Pourquoi est-ce important ?

Essentiel à l’analyse de la conformité, car les réglementations qui influent sur le traitement des sinistres varient selon les juridictions.

Où trouver ces données

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

Exemples
CANYTXFL
Heure de fin
EndTime
L’horodatage indiquant la fin d’une activité.
Description

L’heure de fin marque l’achèvement d’une activité, en particulier lorsqu’il s’agit d’une tâche dont la durée peut être mesurée, comme une enquête ou l’examen d’un document. Dans le Process Mining, de nombreuses activités sont instantanées et un StartTime suffit. Pour celles qui ont un début et une fin distincts, il est préférable d’utiliser les deux horodatages.

Cet attribut permet de calculer précisément la durée de traitement d’une activité, indépendamment du temps d’attente. Il aide à repérer les tâches qui prennent réellement du temps, plutôt que de constater uniquement de longs délais entre les étapes.

Pourquoi est-ce important ?

Il permet de mesurer précisément le temps nécessaire à l’achèvement d’une activité et de distinguer la durée de traitement du temps d’attente.

Où trouver ces données

Il peut être nécessaire de déduire cette information à partir d’un événement ultérieur qui marque logiquement la fin de l’activité, par exemple le passage du statut « En cours » à « Terminé ».

Exemples
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Montant du paiement
PaymentAmount
Montant effectivement versé au titre d’une activité de paiement.
Description

Cet attribut enregistre le montant de chaque paiement effectué pour un sinistre. Un même dossier peut donner lieu à plusieurs paiements au cours de son cycle de vie.

Il est essentiel à l’analyse financière dans le cadre 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 relier les inefficacités du processus aux résultats financiers. Par exemple, les sinistres dont le temps de cycle est long peuvent être associés à des paiements totaux plus élevés.

Pourquoi est-ce important ?

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

Où trouver ces données

Figure 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
Montant réclamé
ClaimedAmount
Montant total initialement réclamé par le souscripteur.
Description

Cet attribut correspond au montant du dommage déclaré 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 réclamé permet de segmenter les sinistres selon leur impact financier. Les dossiers portant sur des montants élevés suivent souvent un processus plus rigoureux et complexe que ceux portant sur de faibles montants. La comparaison des processus selon les tranches de montant peut révéler des possibilités de simplifier le traitement des petits sinistres ou de renforcer les contrôles pour les dossiers plus importants.

Pourquoi est-ce important ?

Permet de segmenter les sinistres selon leur montant, car les dossiers portant sur des montants élevés peuvent suivre des processus différents et plus complexes.

Où trouver ces données

Cette information ne figure pas nécessairement dans un champ unique. Elle peut être calculée à partir des premières estimations de dommages enregistrées pour les expositions.

Exemples
5000.00150000.00750.50
Reprise
IsRework
Indique si une activité fait partie d’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 « Enquête terminée » à « Enquête commencée », la seconde activité « Enquête commencée » est signalée comme une reprise.

Repérer les reprises est essentiel pour mettre au jour les inefficacités du processus et les problèmes de qualité. Le Dashboard consacré à la fréquence des reprises et des refus s’appuie sur cette mesure pour quantifier les écarts par rapport au « parcours nominal ». L’analyse des causes des reprises peut améliorer sensiblement la qualité et la rapidité du processus.

Pourquoi est-ce 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ù trouver ces données

Cette valeur est calculée dans l’outil de Process Mining à partir de la séquence d’activités de chaque cas.

Exemples
truefalse
Service
Department
L’unité opérationnelle ou le service chargé de traiter l’activité liée au sinistre.
Description

Cet attribut indique le service ou l’équipe auquel appartient l’expert affecté, par exemple « Sinistres automobiles », « Sinistres habitation » ou « Unité spéciale d’enquête ». Il situe le processus dans son contexte organisationnel.

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

Pourquoi est-ce important ?

Situe le processus dans son contexte organisationnel, permet de comparer les performances des équipes et met en évidence les difficultés liées aux transferts entre services.

Où trouver ces données

Cette information est généralement associée au profil de l’utilisateur ou du groupe affecté dans ClaimCenter.

Exemples
Service des sinistres automobilesUnité des sinistres habitationUnité spéciale d’enquête (SIU)
Statut du SLA
SLAState
Indique si le sinistre a été clôturé avant la date cible de résolution.
Description

Cet attribut calculé indique, sous forme de catégorie, si chaque sinistre clôturé respecte le SLA. Il est obtenu en comparant l’horodatage de l’activité « Sinistre clôturé » à la « Date cible de résolution ».

Cet attribut alimente directement le Dashboard « Respect de la date cible de résolution des sinistres » en répartissant les résultats dans des catégories claires, comme « Dans les délais » ou « En retard ». Il facilite le filtrage et l’agrégation des données pour calculer le taux global de respect des SLA et examiner les causes des retards.

Pourquoi est-ce important ?

Indique clairement, sous forme de catégorie, si le SLA a été respecté, ce qui facilite le filtrage, l’agrégation et l’analyse des clôtures dans les délais.

Où trouver ces données

Champ calculé : IF (ActualCloseDate <= ResolutionTargetDate, 'Dans les délais', 'En retard').

Exemples
Dans les délaisEn retard
Système source
SourceSystem
Le système dont les données ont été extraites.
Description

Cet attribut indique l’origine des données d’événement. Dans une grande entreprise, les événements liés aux sinistres peuvent provenir de plusieurs systèmes : le système central Guidewire, un système de gestion documentaire ou encore un portail client.

Préciser le système source est essentiel pour la gouvernance des données, la résolution des incohérences et la compréhension de l’environnement technologique du processus. Cela permet de distinguer les étapes principales du processus des activités de soutien réalisées dans des systèmes périphériques.

Pourquoi est-ce important ?

Indique l’origine des données, une information essentielle pour leur gouvernance et pour les analyses portant sur plusieurs systèmes intégrés.

Où trouver ces données

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

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 apporte une classification plus détaillée que le type de sinistre et précise le produit d’assurance concerné, par exemple « Assurance habitation », « Assurance automobile commerciale » ou « Responsabilité civile cyber ». Ce niveau de détail peut révéler des différences de processus propres à certains produits.

L’analyse du processus par type de police aide à repérer les inefficacités propres à chaque produit. Par exemple, les sinistres liés à une police récemment lancée peuvent suivre un processus moins éprouvé et entraîner des retards. Ces résultats peuvent éclairer la conception des produits et les efforts de normalisation des processus.

Pourquoi est-ce important ?

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

Où trouver ces données

Cette information se trouve dans l’entité Policy, liée à Claim.

Exemples
Assurance multirisque habitationResponsabilité civile automobile commercialeAssurance maritime intérieure
Obligatoire Recommandé Facultatif

Activités de traitement des sinistres

Voici les principales étapes du processus et les jalons importants à consigner dans votre journal d’événements pour découvrir et analyser précisément le traitement des sinistres.
7 Recommandé 7 Facultatif
Activité Description
Paiement approuvé
Cette activité correspond à 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 est-ce important ?

Cette étape importante permet de passer au paiement final. L’analyse du temps écoulé avant et après cette activité aide à isoler les retards liés au flux d’approbation ou à la disponibilité des responsables.

Où trouver ces données

Il s’agit souvent d’un événement explicite enregistré dans la table cc_history pour une entité cc_check ou cc_transaction, qui consigne le changement de statut de « En attente d’approbation » à « Approuvé ».

Données à recueillir

Suivez le changement de statut vers « Approuvé » 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 : le paiement est officiellement émis et transmis au système financier. Il s’agit d’une transaction financière explicite et enregistrée.
Pourquoi est-ce important ?

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

Où trouver ces données

L’événement est enregistré à partir de IssueDate ou d’un changement de statut vers « Émis » ou « Soumis » dans l’entité cc_check ou cc_transaction. Il s’agit souvent d’un événement explicite horodaté.

Données à recueillir

Repérez IssueDate ou l’horodatage du changement de statut vers « Émis » dans l’enregistrement du paiement.

Type d’événement explicit
Poste de responsabilité créé
Cette activité indique la création d’un poste de responsabilité, qui correspond à une responsabilité potentielle ou à un type de perte précis dans le cadre du sinistre (par exemple, des dommages au véhicule ou des blessures). Il s’agit d’un événement explicite dans Guidewire.
Pourquoi est-ce important ?

Les postes de responsabilité sont essentiels pour segmenter et analyser les sinistres. Le suivi de leur création permet de comprendre les variantes du processus selon la complexité du sinistre et le type de perte.

Où trouver ces données

L’événement est enregistré à partir de CreateTime d’un nouvel enregistrement dans la table cc_exposure. Chaque enregistrement est associé à un seul ID de sinistre.

Données à recueillir

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

Type d’événement explicit
Première provision définie
Cet événement marque la création de la première transaction de provision financière pour un poste de responsabilité, afin d’estimer le coût potentiel du sinistre. Il s’agit d’un événement financier important, enregistré explicitement.
Pourquoi est-ce important ?

Cette étape est essentielle à l’analyse financière et permet de comprendre à quelle vitesse la responsabilité potentielle est évaluée. Les retards peuvent nuire à la planification et au reporting financiers.

Où trouver ces données

Cet événement est enregistré lors de la création du premier enregistrement cc_reserveline associé à un poste de responsabilité du sinistre. CreateTime de la transaction fournit l’horodatage de l’événement.

Données à recueillir

Recherchez l’horodatage de création le plus ancien parmi toutes les lignes de provision des postes de responsabilité d’un sinistre donné.

Type d’événement explicit
Sinistre clôturé
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 en cas de résolution favorable, déduit d’un changement du statut principal du sinistre.
Pourquoi est-ce important ?

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

Où trouver ces données

Déduite du passage du champ State de la table cc_claim à « Closed ». CloseDate de l’enregistrement du sinistre fournit l’horodatage de l’événement.

Données à recueillir

Repérez 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 dans Guidewire ClaimCenter. Elle est enregistrée explicitement lors de la première sauvegarde d’une nouvelle entité Claim dans la base de données.
Pourquoi est-ce important ?

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

Où trouver ces données

Cet événement explicite est enregistré à partir de CreateTime dans la table cc_claim. La création d’un nouvel enregistrement doté d’un ID de sinistre unique déclenche l’événement.

Données à recueillir

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

Type d’événement explicit
Sinistre refusé
Correspond à la décision finale de refuser un sinistre et marque la fin du processus. Cet événement est déduit du passage du sinistre à un statut fermé avec le motif « Refusé ».
Pourquoi est-ce 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 conduisent permet de repérer les problèmes liés à la réception des sinistres, à l’enquête ou à l’interprétation des polices.

Où trouver ces données

Déduite du passage du champ State de la table cc_claim à « Closed », associé à la valeur « Denied » ou à une valeur similaire dans le champ CloseReason. CloseDate fournit l’horodatage de l’événement.

Données à recueillir

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

Type d’événement inferred
Décision sur la responsabilité prise
Indique le moment où la responsabilité ou la faute est déterminée pour un poste de responsabilité. Cet événement est généralement déduit d’un changement de statut de l’entité Exposure.
Pourquoi est-ce important ?

Cette décision importante conditionne les étapes de règlement et de paiement. L’analyse du délai nécessaire pour la prendre permet de repérer les goulots d’étranglement dans les phases d’enquête et d’évaluation.

Où trouver ces données

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

Données à recueillir

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

Type d’événement inferred
Enquête commencée
Indique le début officiel de la phase d’enquête sur un sinistre ou un poste de responsabilité. Cet événement est souvent déduit de la création de la première « Activity » (tâche) liée à l’enquête dans Guidewire.
Pourquoi est-ce important ?

Cette activité marque le début d’une phase importante, souvent longue. L’analyse du délai avant le début de l’enquête et de sa durée permet de repérer les principaux goulots d’étranglement.

Où trouver ces données

Déduite de CreateTime d’un enregistrement cc_activity dont ActivityPattern est lié à une enquête (par exemple, « Enquête initiale », « Contacter un témoin »).

Données à recueillir

Repérez la première création d’une tâche dont le modèle ou l’objet est lié à une enquête.

Type d’événement inferred
Informations complémentaires demandées
Cette activité correspond à une demande d’informations ou de documents complémentaires adressée au demandeur ou à un tiers. Elle est généralement enregistrée comme une « Activity » (tâche) créée explicitement dans ClaimCenter.
Pourquoi est-ce important ?

Cette activité marque le début de la mesure du KPI « Temps de cycle de collecte des informations complémentaires ». Des occurrences fréquentes peuvent révéler des processus FNOL incomplets ou une collecte d’informations inefficace.

Où trouver ces données

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

Données à recueillir

Repérez la création d’une tâche de demande d’informations à un tiers.

Type d’événement explicit
Informations complémentaires reçues
Marque la fin d’une demande d’informations complémentaires. L’événement est enregistré lorsque l’« Activity » (tâche) correspondante est marquée comme « Terminée ».
Pourquoi est-ce important ?

Cette activité marque la fin du KPI « Temps de cycle de collecte des informations complémentaires ». Les longs délais entre la demande et la réception sont une cause fréquente de ralentissement du traitement des sinistres.

Où trouver ces données

L’événement est enregistré à partir de CloseTime d’un enregistrement cc_activity dont ActivityPattern concerne une demande d’informations. Le statut de l’activité doit être « Terminée ».

Données à recueillir

Repérez l’horodatage de fin d’une tâche de demande d’informations à un tiers.

Type d’événement explicit
Montant du règlement calculé
Cette activité correspond au moment où le montant du règlement est déterminé, mais pas encore approuvé pour paiement. Elle peut être déduite de la création d’un paiement au statut « En attente d’approbation ».
Pourquoi est-ce important ?

Elle marque le passage de l’évaluation au paiement. C’est le point de départ de la mesure du KPI « Délai d’autorisation du paiement », qui met en évidence les retards dans la chaîne d’approbation.

Où trouver ces données

Déduite de CreateTime d’un enregistrement cc_check ou cc_transaction dont le statut initial est « En attente d’approbation » ou un statut similaire avant « Approuvé ».

Données à recueillir

Repérez la création d’un enregistrement de paiement ou de transaction dont le statut indique que l’approbation n’a pas encore été donnée.

Type d’événement inferred
Sinistre attribué
Cette activité correspond à l’attribution d’un sinistre à un utilisateur précis (gestionnaire de sinistres) ou à un groupe chargé de son traitement. Elle est généralement déduite du suivi des modifications des champs d’attribution de l’entité Claim.
Pourquoi est-ce 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’acheminement et mesurer le délai avant la première action du responsable désigné.

Où trouver ces données

Déduite de la table cc_history en suivant les modifications des champs AssignedUser ou AssignedGroup associés à un ID de sinistre donné. L’horodatage de la modification indique le moment où l’événement s’est produit.

Données à recueillir

Surveillez les journaux d’audit ou les tables d’historique pour repérer les mises à jour des champs d’attribution des sinistres.

Type d’événement inferred
Sinistre rouvert
Correspond au passage d’un sinistre du statut « Closed » au statut « Open » pour effectuer des travaux supplémentaires. Cet événement est déduit d’une séquence précise de changements de statut.
Pourquoi est-ce important ?

Cette activité signale une reprise. Un nombre élevé de sinistres rouverts peut révéler des problèmes lors du règlement initial, des dommages non pris en compte ou d’autres défaillances du processus, qui augmentent les coûts et réduisent l’efficacité.

Où trouver ces données

Déduite de la table cc_history en repérant le passage du champ State de l’entité cc_claim de « Closed » à « Open » ou à un autre statut actif.

Données à recueillir

Surveillez le champ de statut principal du sinistre pour repérer le passage d’un statut fermé à un statut 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 mieux comprendre le traitement de vos sinistres. Commencez dès aujourd’hui à optimiser vos flux de travail.

Accélérez le traitement des sinistres et résolvez les dossiers plus rapidement

Résorbez les retards, prévenez la fraude et visez un traitement automatisé de bout en bout à 70 %.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.