Modèle de données : Traitement des sinistres

Guidewire ClaimCenter
Modèle de données : Traitement des sinistres

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

Bienvenue sur votre ressource dédiée à l'optimisation du traitement des sinistres. Ce modèle présente les attributs de données essentiels à collecter, les activités critiques à suivre et fournit des directives claires pour l'extraction des données. Utilisez-le pour vous assurer de capturer toutes les informations nécessaires à une analyse de processus complète.
  • Attributs recommandés à collecter
  • Activités clés à suivre
  • Guide d'extraction pour Guidewire ClaimCenter
Nouveau dans les journaux d'événements ? Apprenez comment créer un journal d'événements Process Mining.

Attributs de Gestion des Sinistres

Ces champs de données recommandés sont cruciaux pour construire un journal d'événements complet afin d'analyser efficacement vos workflows de traitement des sinistres.
3 Obligatoire 4 Recommandé 15 Facultatif
NomDescription
Heure de l'événement
EventTime
La date et l'heure précises auxquelles l'activité s'est produite.
Description

Ce timestamp marque le moment exact où une activité a été enregistrée dans le système. Il est fondamental pour toute analyse de processus basée sur le temps.

L'ordonnancement chronologique du EventTime pour un identifiant de sinistre unique (Claim ID) permet la reconstitution du flux de processus. La différence de temps entre des événements consécutifs est utilisée pour calculer les temps de cycle, les temps d'attente et les temps de traitement, qui sont essentiels pour l'analyse des performances, l'identification des goulots d'étranglement et la surveillance des SLA.

Pourquoi c'est important

Ce timestamp est essentiel pour ordonner les événements, calculer les temps de cycle et les durées, et identifier les retards dans le processus.

Où obtenir

Se trouve à côté des données d'événement ou d'activité dans les tables d'historique ou d'audit de Guidewire ClaimCenter, souvent en tant que champ 'CreateTime' ou 'UpdateTime'.

Exemples
2023-05-15T09:00:00Z2023-05-16T14:30:15Z2023-06-01T11:20:00Z
Nom de l'activité
ActivityName
Le nom de l'activité ou de l'événement commercial qui s'est produit à un moment précis du cycle de vie du sinistre.
Description

Cet attribut décrit une étape ou un jalon spécifique du processus de sinistres, tels que « Sinistre Créé », « Enquête Démarrée » ou « Paiement Émis ». La séquence de ces activités pour un ID de sinistre donné forme le flux de processus.

L'analyse de la séquence, de la fréquence et de la durée entre les activités est le cœur du Process Mining. Elle permet la découverte de modèles de processus, l'identification des goulots d'étranglement, la détection des boucles de retravail et l'analyse des déviations de processus.

Pourquoi c'est important

Il définit les étapes du processus, permettant la visualisation des cartes de processus et l'analyse des flux de processus et des goulots d'étranglement.

Où obtenir

Cette information est généralement tirée des tables d'événements ou des journaux d'audit de ClaimCenter, souvent en associant des événements système ou des changements de statut spécifiques à des noms d'activité standardisés.

Exemples
Sinistre crééDécision de responsabilité prisePaiement émisSinistre Clos
Numéro de Sinistre
ClaimID
L'identifiant unique pour chaque demande d'indemnisation, servant d'identifiant principal du dossier.
Description

L'ID de sinistre est la pierre angulaire de l'analyse des processus de sinistres, identifiant de manière unique chaque dossier de la soumission à la clôture. Il relie toutes les activités, documents, paiements et communications associés, assurant une vue complète et cohérente du cycle de vie d'un sinistre.

En Process Mining, chaque événement du jeu de données est lié à un ID de sinistre, permettant la reconstruction du flux de processus de bout en bout. Ceci est essentiel pour analyser les temps de cycle, identifier les variantes de processus et suivre le parcours d'un sinistre à travers les différents services et experts en sinistres.

Pourquoi c'est important

C'est la clé fondamentale qui relie tous les événements connexes, permettant de tracer et d'analyser l'intégralité du parcours d'une seule réclamation.

Où obtenir

Ceci est une clé primaire dans Guidewire ClaimCenter, généralement trouvée sous le nom de Claim.ClaimNumber ou un champ similaire dans l'entité centrale Claim.

Exemples
000-123-45678000-987-65432001-456-11223
Cause du sinistre
LossCause
La raison ou la cause spécifique de l'événement de perte (sinistre) (ex : Collision, Incendie, Dégâts des eaux).
Description

Cet attribut offre un contexte détaillé sur la raison du dépôt de la réclamation. La cause du sinistre dicte souvent les étapes d'enquête requises, le type d'experts nécessaires et la complexité globale du dossier.

L'analyse du processus par cause du sinistre peut révéler des schémas cachés. Par exemple, les réclamations liées aux « Dégâts des eaux » peuvent présenter un taux de retouche plus élevé ou nécessiter davantage l'intervention de spécialistes, comparativement aux réclamations pour « Vol ». Ces informations clés aident à élaborer des procédures de traitement plus spécialisées et efficientes.

Pourquoi c'est important

Fournit un contexte sur la nature du sinistre, permettant d'analyser comment différentes causes de pertes impactent le flux et la durée du processus.

Où obtenir

Il s'agit d'un champ standard de l'entité Claim, généralement appelé 'LossCause'.

Exemples
CollisionIncendieDégât des eauxVol
Expert en sinistres désigné
AssignedAdjuster
Le nom ou l'ID de l'utilisateur assigné pour gérer le sinistre ou une activité spécifique.
Description

Cet attribut permet d'identifier le gestionnaire de sinistres individuel responsable d'une réclamation à un moment donné. Un gestionnaire peut être affecté à l'ensemble du dossier ou à des tâches spécifiques de celui-ci.

L'analyse par gestionnaire de sinistres est essentielle pour équilibrer la charge de travail, optimiser la gestion de la performance et identifier les besoins en formation. Elle permet de répondre à des questions clés telles que : « Quels gestionnaires ont la charge de travail la plus élevée ? », « Y a-t-il des écarts de performance entre les gestionnaires ? » et « Le travail est-il réparti équitablement ? ».

Pourquoi c'est important

Suit l'implication des utilisateurs, permettant l'analyse de la charge de travail, la comparaison des performances et l'identification des goulots d'étranglement liés aux ressources.

Où obtenir

Disponible dans l'entité Sinistre ou Exposition de ClaimCenter, souvent lié à l'objet Utilisateur (par ex., Claim.Assignee).

Exemples
j.doem.smiths.jones
Statut du Sinistre
ClaimStatus
Le statut global du sinistre au moment de l'événement (ex : Ouvert, Clos, Refusé).
Description

Cet attribut reflète l'état global de la réclamation. Les statuts clés incluent « Open », « Closed », « Denied » et « Reopened ». Le statut final d'une réclamation est une métrique de résultat essentielle.

Le suivi des changements de statut de la réclamation aide à définir les jalons et les résultats clés du processus. Il est utilisé pour identifier la résolution finale d'une réclamation, calculer les taux de rejet et analyser la fréquence des réclamations rouvertes après leur clôture, ce qui indique souvent des problèmes de processus ou une insatisfaction client.

Pourquoi c'est important

Indique l'issue d'une réclamation, essentielle pour analyser les taux de rejet, les modèles de clôture et les fréquences de réouverture des réclamations.

Où obtenir

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

Exemples
OuvertClôturéRefuséRouvert
Type de Sinistre
ClaimType
La catégorie du sinistre d'assurance, telle que Automobile, Biens ou Responsabilité civile.
Description

Le type de sinistre représente une classification fondamentale, établie selon la ligne d'activité concernée ou la nature de la perte. Les différentes catégories de sinistres suivent fréquemment des processus distincts, présentent des niveaux de complexité variables et sont soumises à des réglementations spécifiques.

Une segmentation de l'analyse des processus par type de sinistre est donc indispensable pour obtenir des informations exploitables. Cette approche permet de comparer les performances des processus sur diverses lignes d'activité, de détecter les goulets d'étranglement propres à chaque type et d'adapter les initiatives d'amélioration des processus aux particularités de chaque catégorie de sinistre.

Pourquoi c'est important

Permet la segmentation des sinistres, car les différents types (par ex., automobile vs. immobilier) suivent souvent des processus distincts et ont des objectifs de performance variés.

Où obtenir

Dérivé de l'entité Policy ou Claim dans ClaimCenter, souvent basé sur le code de la ligne d'activité (LOB).

Exemples
Automobile personnelleBiens commerciauxResponsabilité civile généraleIndemnisation des travailleurs
Date cible de résolution
ResolutionTargetDate
La date à laquelle le sinistre est censé être résolu conformément aux SLA internes ou réglementaires.
Description

La Date Cible de Résolution est une échéance fixée pour la clôture des sinistres, souvent déterminée par des facteurs tels que la juridiction, le type de sinistre et les termes de la police. Elle sert de référence pour mesurer la performance et la conformité.

Cet attribut est essentiel pour construire des dashboards et des KPI de conformité SLA. En comparant la date réelle de 'Sinistre Clos' à cette date cible, l'analyse peut automatiquement signaler les sinistres en retard, mesurer les taux de performance en temps voulu et identifier quels types de sinistres ou services ont des difficultés à atteindre leurs objectifs.

Pourquoi c'est important

C'est la référence pour mesurer le respect des accords de niveau de service (SLA) et identifier les réclamations qui risquent d'être en retard.

Où obtenir

Il peut s'agir d'un champ personnalisé ou d'une valeur dérivée selon les règles métier configurées dans ClaimCenter, potentiellement liée à des métriques de sinistre spécifiques.

Exemples
2023-06-142023-07-202023-08-28
Date du sinistre
LossDate
La date à laquelle l'incident ou le sinistre qui a déclenché la demande d'indemnisation est survenu.
Description

La Date de Perte est la date de l'événement réel (ex : accident de voiture, dommages matériels) pour lequel le sinistre est déclaré. Ceci est distinct de la date à laquelle le sinistre a été déclaré ou créé.

Le décalage temporel entre la Date de Perte et l'activité 'Sinistre Créé' (connu sous le nom de délai de déclaration) est un KPI important. L'analyse de ce délai peut fournir des informations précieuses sur le comportement des clients et l'efficacité des canaux de première déclaration de sinistre.

Pourquoi c'est important

Fournit un contexte crucial sur l'origine du sinistre et aide à analyser le délai de déclaration (temps entre l'incident et la soumission du sinistre).

Où obtenir

Il s'agit d'un champ de date fondamental sur l'entité Claim, souvent nommé 'LossDate'.

Exemples
2023-05-102023-04-202023-05-28
Demande d'informations répétée
RepeatedInfoRequestFlag
Un indicateur signalant si l'activité « Informations supplémentaires demandées » est survenue plus d'une fois pour le même sinistre.
Description

Ce drapeau booléen est défini sur vrai si une réclamation comporte plus d'une activité « Demande d'informations supplémentaires ». Ce scénario indique souvent des inefficacités dans la phase initiale de collecte d'informations.

Cet attribut soutient directement le KPI « Taux de demandes d'informations répétées ». Il aide à quantifier le problème d'une collecte initiale de faits incomplète, ce qui peut entraîner des retards importants et la frustration des clients. L'analyse des réclamations avec ce drapeau peut aider à améliorer les listes de contrôle et les procédures pour les gestionnaires de sinistres afin de s'assurer que toutes les informations nécessaires sont demandées en une seule fois.

Pourquoi c'est important

Identifie les inefficacités lorsque la collecte d'informations n'est pas complète dès la première fois, ce qui entraîne des retards de processus et du retravail.

Où obtenir

Calculé au sein de l'outil de Process Mining en comptant les occurrences de l'activité « Informations supplémentaires demandées » par dossier.

Exemples
truefaux
Département
Department
L'unité commerciale ou le service responsable du traitement de l'activité de sinistre.
Description

Cet attribut précise le département ou l'équipe du gestionnaire de sinistres assigné, par exemple « Sinistres automobiles », « Sinistres immobiliers » ou « Unité des enquêtes spéciales ». Il offre un éclairage sur le contexte organisationnel du processus.

L'analyse par département est essentielle pour comprendre la performance du processus au niveau organisationnel. Elle permet d'identifier les retards de transfert inter-départementaux, de comparer l'efficacité entre les équipes et d'allouer les ressources de manière plus efficace au sein de l'organisation des sinistres.

Pourquoi c'est important

Fournit un contexte organisationnel, permettant une analyse des performances entre les différentes équipes et mettant en évidence les problèmes de transfert interdépartemental.

Où obtenir

Cette information est généralement associée au profil de l'utilisateur ou du groupe assigné au sein de ClaimCenter.

Exemples
Division des sinistres automobilesUnité des sinistres immobiliersUnité des Enquêtes Spéciales (UES)
Dernière mise à jour des données
LastDataUpdate
Le timestamp indiquant la dernière actualisation ou extraction des données du système source.
Description

Cet attribut fournit l'horodatage de la dernière extraction de données du système source. Il s'agit d'un champ de métadonnées essentiel pour évaluer l'actualité de l'analyse.

Les dashboards et les analyses devraient afficher cette information de manière visible afin que les utilisateurs soient conscients de la fraîcheur des données. Cela aide à déterminer si les informations reflètent l'état actuel des opérations ou si elles sont basées sur des données plus anciennes.

Pourquoi c'est important

Indique la fraîcheur des données, garantissant que les utilisateurs comprennent l'actualité de l'analyse des processus.

Où obtenir

Cette valeur est générée et stockée pendant le processus ETL ; elle représente le timestamp du chargement des données.

Exemples
2024-07-28T04:00:00Z2024-07-29T04:00:00Z
Est Automatisé
IsAutomated
Un indicateur spécifiant si une activité a été réalisée automatiquement par le système ou par un utilisateur humain.
Description

Cet attribut booléen permet de distinguer les activités exécutées par un système (par exemple, la création automatique de réserves, la correspondance générée par le système) de celles effectuées manuellement par un gestionnaire de sinistres.

L'analyse de cet attribut est essentielle pour comprendre le niveau d'automatisation dans le processus de traitement des réclamations. Elle aide à identifier les points chauds d'intervention manuelle, à mesurer l'efficacité des initiatives de traitement direct (straight-through processing) et à découvrir de nouvelles opportunités d'automatisation en ciblant les tâches répétitives et basées sur des règles actuellement exécutées par des humains.

Pourquoi c'est important

Permet de distinguer les activités automatisées de celles qui sont réalisées manuellement, un élément clé pour analyser l'automatisation et identifier les goulots d'étranglement humains.

Où obtenir

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

Exemples
truefaux
Est une reprise
IsRework
Un indicateur signalant si une activité représente une boucle de retravail, c'est-à-dire un retour à une étape antérieure du processus.
Description

Cet attribut calculé signale les activités qui font partie d'une boucle de retouche. Par exemple, si le processus passe de « Investigation Completed » à nouveau à « Investigation Started », la deuxième activité « Investigation Started » serait signalée comme une retouche.

L'identification des retouches est fondamentale pour déceler les inefficacités de processus et les problèmes de qualité. Le dashboard « Fréquence des retouches et des rejets » s'appuie sur cette métrique pour quantifier la fréquence à laquelle les réclamations s'écartent du « chemin idéal » (happy path). L'analyse des causes de ces retouches peut conduire à des améliorations significatives de la qualité et de la rapidité des processus.

Pourquoi c'est important

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

Où obtenir

Ceci est calculé au sein de l'outil de Process Mining en analysant la séquence d'activités pour chaque cas.

Exemples
truefaux
État de juridiction
JurisdictionState
L'état ou la juridiction régissant le sinistre, qui dicte les exigences réglementaires.
Description

Cet attribut précise la juridiction légale (par exemple, l'État américain) sous laquelle la réclamation est traitée. Les réglementations d'assurance peuvent varier considérablement d'une juridiction à l'autre, ce qui impacte les étapes de processus requises, les délais de communication et la documentation.

Ceci est un attribut essentiel pour le suivi de la conformité. L'analyse du processus par juridiction garantit que les exigences réglementaires spécifiques à l'État sont respectées. Elle peut également expliquer les variations dans les temps de cycle ou les chemins de processus qui sont dictées par des contraintes légales plutôt que par une inefficacité opérationnelle.

Pourquoi c'est important

Crucial pour l'analyse de la conformité, car différentes juridictions sont soumises à des réglementations distinctes qui impactent le processus de traitement des sinistres.

Où obtenir

Un champ standard de l'entité Sinistre, généralement nommé 'JurisdictionState'.

Exemples
CANYTXFL
Heure de fin
EndTime
L'horodatage indiquant quand une activité a été achevée.
Description

L'Heure de Fin marque l'achèvement d'une activité, en particulier pour les tâches ayant une durée mesurable, comme l'« Enquête » ou la « Révision de documents ». Bien que de nombreuses activités de Process Mining soient instantanées (StartTime est suffisant), les activités ayant un début et une fin distincts sont mieux représentées avec les deux timestamps.

Cet attribut permet le calcul précis du temps de traitement d'une activité, distinct du temps d'attente. Il aide à identifier quelles tâches spécifiques sont chronophages, plutôt que de simplement observer de longs délais entre différentes étapes.

Pourquoi c'est important

Il permet la mesure précise du temps nécessaire à la réalisation d'une activité, en distinguant le temps de traitement du temps d'attente.

Où obtenir

Cette information peut être dérivée en identifiant un événement subséquent qui conclut logiquement l'activité (par exemple, un changement de statut de 'En cours' à 'Terminé').

Exemples
2023-05-15T17:00:00Z2023-05-16T15:00:00Z2023-06-02T10:00:00Z
Montant du paiement
PaymentAmount
Le montant réel versé pour une activité de paiement.
Description

Cet attribut enregistre la valeur de chaque paiement individuel effectué pour une réclamation. Une réclamation unique peut donner lieu à plusieurs paiements au cours de son cycle de vie.

Ceci est essentiel pour l'analyse financière dans le contexte du Process Mining. Il peut être utilisé pour suivre le montant total versé par réclamation, analyser les délais d'approbation des paiements en fonction de leur montant, et associer les inefficacités de processus aux résultats financiers. Par exemple, les réclamations présentant des cycles de traitement longs pourraient être corrélées à des paiements totaux plus élevés.

Pourquoi c'est important

Suit les transactions financières au sein d'un sinistre, permettant l'analyse des montants de paiement et de leur relation avec les activités du processus.

Où obtenir

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

Exemples
4500.00125000.00500.00
Montant réclamé
ClaimedAmount
Le montant monétaire total initialement réclamé par le preneur d'assurance.
Description

Cet attribut représente la valeur du sinistre telle que déclarée par le demandeur. Il s'agit souvent d'une estimation initiale qui peut évoluer à mesure que la réclamation est examinée et que les réserves sont constituées.

L'analyse du montant réclamé aide à segmenter les réclamations en fonction de leur impact financier. Les réclamations de grande valeur suivent souvent un processus plus rigoureux et complexe que celles de faible valeur. La comparaison des processus pour différentes tranches de valeur peut révéler des opportunités de rationalisation du traitement pour les petites réclamations ou d'application de contrôles plus stricts pour les plus importantes.

Pourquoi c'est important

Permet de segmenter les sinistres par valeur financière, car les sinistres à forte valeur peuvent suivre des processus différents, plus complexes.

Où obtenir

Cette information n'est peut-être pas un champ unique, mais elle peut être dérivée des estimations initiales de perte enregistrées sur les expositions.

Exemples
5000.00150000.00750.50
Statut SLA
SLAState
Indique si la réclamation a été clôturée dans le respect de sa date cible de résolution.
Description

Cet attribut calculé fournit un statut catégoriel de conformité aux SLA pour chaque réclamation clôturée. Il est dérivé en comparant l'horodatage de l'activité « Claim Closed » avec la « Resolution Target Date ».

Cet attribut soutient directement le dashboard « Respect de l'objectif de résolution des réclamations » en simplifiant l'analyse en catégories claires comme « On Time » ou « Late ». Il permet un filtrage et une agrégation faciles pour calculer le taux global de respect des SLA et pour approfondir les raisons des retards.

Pourquoi c'est important

Fournit un résultat clair et catégorique pour le respect des SLA, facilitant ainsi le filtrage, l'agrégation et l'analyse de la performance à temps.

Où obtenir

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

Exemples
À tempsEn retard
Système source
SourceSystem
Le système d'où les data ont été extraites.
Description

Cet attribut détermine la source des données d'événement. Dans un environnement d'entreprise moderne, les événements liés à une réclamation peuvent provenir de divers systèmes : un système central comme Guidewire, un système de gestion documentaire ou un portail client, par exemple.

La spécification du système source est cruciale pour la gouvernance des données, le dépannage des incohérences de données et la compréhension de l'architecture technologique du processus. Elle permet de distinguer les étapes fondamentales du processus des activités de support issues des systèmes périphériques.

Pourquoi c'est important

Permet d'identifier l'origine des données, essentiel pour leur gouvernance et pour les analyses impliquant plusieurs systèmes intégrés.

Où obtenir

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

Exemples
Guidewire ClaimCenter v10API du portail clientDocumentum
Temps de traitement
ProcessingTime
La durée passée à travailler activement sur une activité.
Description

Le temps de traitement mesure le temps pendant lequel une activité est activement travaillée, calculé comme la différence entre son heure de fin et son heure de début. Ceci est distinct du temps de cycle, qui inclut les périodes d'attente.

Cette métrique calculée est vitale pour l'analyse des performances car elle isole l'effort réel requis pour une tâche du temps d'inactivité ou d'attente. Elle aide à identifier avec précision les étapes qui sont véritablement chronophages et où des gains d'efficacité peuvent être réalisés par le biais de la formation, de meilleurs outils ou de la refonte des processus.

Pourquoi c'est important

Mesure le temps de travail actif d'une activité, permettant de distinguer le temps à valeur ajoutée du temps d'attente.

Où obtenir

Champ calculé : EndTime - StartTime. Nécessite que les deux timestamps soient disponibles dans les données source.

Exemples
PT8HPT15MP2D
Type de police
PolicyType
Le type spécifique de police d'assurance en vertu de laquelle la demande d'indemnisation a été déposée.
Description

Le type de police offre une classification plus granulaire que le type de sinistre, détaillant le produit d'assurance spécifique, tel que « habitation », « automobile commerciale » ou « cyber-responsabilité ». Ce niveau de détail peut révéler des variations de processus liées à des produits spécifiques.

L'analyse du processus par type de police aide à découvrir les inefficacités spécifiques à un produit. Par exemple, les sinistres pour une police nouvellement lancée peuvent suivre un processus moins mature, entraînant des retards. Cette analyse peut éclairer la conception des produits et les efforts de standardisation des processus.

Pourquoi c'est important

Permet d'analyser les processus pour des produits d'assurance spécifiques, aidant ainsi à identifier les variations de traitement basées sur les particularités des polices.

Où obtenir

Cette information se trouve dans l'entité Policy, laquelle est liée à l'entité Claim.

Exemples
Multirisque HabitationResponsabilité civile automobile commercialeAssurance maritime intérieure
Obligatoire Recommandé Facultatif

Activités de Gestion des Sinistres

Voici les étapes clés du processus et les jalons importants à capturer dans votre journal d'événements pour une découverte et une analyse précises des processus de sinistres.
7 Recommandé 7 Facultatif
ActivitéDescription
Exposition créée
Cette activité signifie la création d'une exposition, qui représente une responsabilité potentielle spécifique ou un type de perte dans le cadre du sinistre (ex : dommages au véhicule, blessures). C'est un événement explicite dans Guidewire.
Pourquoi c'est important

Les expositions sont fondamentales pour la segmentation et l'analyse des sinistres. Suivre leur création aide à comprendre les variations de processus en fonction de la complexité du sinistre et du type de perte.

Où obtenir

Collecté à partir de la valeur CreateTime d'un nouvel enregistrement dans la table cc_exposure. Chaque enregistrement est rattaché à un unique Claim ID.

Capture

Identifier le timestamp de création d'un nouvel enregistrement dans la table d'entité Exposure.

Type d'événement explicit
Paiement approuvé
Représente l'approbation formelle d'un paiement de règlement. C'est un événement d'audit critique et il est explicitement capturé lorsqu'un utilisateur avec autorité approuve la transaction.
Pourquoi c'est important

Ce jalon clé permet de débloquer l'étape finale du paiement. L'analyse du temps avant et après cette activité aide à isoler les retards causés par les workflows d'approbation ou la disponibilité des gestionnaires.

Où obtenir

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

Capture

Suivre l'événement de changement de statut à 'Approuvé' pour une transaction de paiement spécifique.

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

Cette activité est cruciale pour mesurer l'efficacité du processus d'envoi des paiements. Elle aide à différencier les retards d'approbation des retards dans l'émission réelle des fonds.

Où obtenir

Collecté à partir de la IssueDate ou d'un changement de statut à 'Issued' ou 'Submitted' sur l'entité cc_check ou cc_transaction. C'est souvent un event horodaté explicite.

Capture

Identifier l'IssueDate ou le timestamp du changement de statut à 'Issued' sur l'enregistrement de paiement.

Type d'événement explicit
Réserve initiale établie
Marque la création de la première transaction de réserve financière pour une exposition, estimant le coût potentiel de la réclamation. Il s'agit d'un événement financier critique, et il est enregistré explicitement.
Pourquoi c'est important

Ce jalon est essentiel pour l'analyse financière et pour comprendre la rapidité d'évaluation de la responsabilité potentielle. Les retards peuvent avoir un impact sur la planification financière et le reporting.

Où obtenir

Cet événement est capturé lors de la création du premier enregistrement cc_reserveline associé à une exposition sur la réclamation. Le CreateTime de la transaction est l'horodatage de l'événement.

Capture

Trouver le timestamp de création minimum de toutes les lignes de réserve pour les expositions d'un sinistre donné.

Type d'événement explicit
Sinistre Clos
Marque la clôture réussie d'une réclamation après l'achèvement de toutes les activités et de tous les paiements. C'est l'événement de fin principal, déduit d'un changement dans le statut principal de la réclamation.
Pourquoi c'est 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 l'adhésion aux SLA. Elle marque l'achèvement du cycle de vie du sinistre.

Où obtenir

Déduit d'un changement dans le champ State de la table cc_claim passant à 'Closed'. Le timestamp de l'événement est le CloseDate de l'enregistrement de réclamation.

Capture

Identifier le moment où le champ du statut maître de la réclamation est mis à jour à 'Closed'.

Type d'événement inferred
Sinistre créé
Cette activité marque la première déclaration de sinistre (FNOL) et la création officielle d'un nouveau dossier de sinistre dans Guidewire ClaimCenter. Elle est capturée explicitement lorsqu'une nouvelle entité de sinistre est enregistré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 temps de cycle de bout en bout du sinistre. Elle fournit la base de référence pour tous les KPI de performance et de durée suivants.

Où obtenir

C'est un événement explicite capturé à partir du CreateTime de la table cc_claim. La création d'un nouvel enregistrement avec un Claim ID unique sert de déclencheur d'événement.

Capture

Identifier le timestamp de création du nouvel enregistrement dans la table d'entité de base Claim.

Type d'événement explicit
Sinistre Refusé
Représente la décision finale de refuser un sinistre, servant de point d'arrivée terminal pour le processus. Cet événement est déduit du statut du sinistre passant à un état fermé avec un motif « Refusé ».
Pourquoi c'est important

C'est un événement de résultat critique. L'analyse de la fréquence, des raisons et des chemins de processus menant aux refus aide à identifier les problèmes liés à la réception de la réclamation, à l'enquête ou à l'interprétation de la politique.

Où obtenir

Déduit d'un changement dans le champ State de la table cc_claim passant à 'Closed', combiné au champ CloseReason qui a la valeur 'Denied' ou une valeur similaire. Le timestamp de l'événement est le CloseDate.

Capture

Filtrer les changements de statut des sinistres vers 'Clos' lorsque le code de raison indique un refus.

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

C'est un jalon décisionnel critique qui précède les phases de règlement et de paiement. L'analyse du temps nécessaire pour parvenir à cette décision aide à identifier les goulots d'étranglement dans les étapes d'enquête et d'évaluation.

Où obtenir

Déduit de la table cc_history en suivant un changement dans le champ State ou un champ de statut de responsabilité personnalisé sur l'entité cc_exposure. Le timestamp de l'enregistrement d'historique indique l'heure de l'événement.

Capture

Surveiller les journaux d'audit ou les tables d'historique afin de détecter les mises à jour de l'état de l'exposition ou de son statut de responsabilité.

Type d'événement inferred
Enquête initiée
Indique le début formel de la phase d'investigation pour une réclamation ou une exposition. Cela est souvent déduit de la création de la première Activity (tâche) liée à l'investigation dans Guidewire.
Pourquoi c'est important

Cette activité marque le début d'une phase clé, souvent longue. L'analyse du temps écoulé jusqu'au début de l'enquête et de la durée de l'enquête elle-même révèle des goulots d'étranglement majeurs.

Où obtenir

Déduit du CreateTime d'un enregistrement cc_activity où l'ActivityPattern est lié à l'investigation (par exemple, 'Initial Investigation', 'Contact Witness').

Capture

Identifier la première création d'une tâche dont le modèle ou le sujet est lié à une investigation.

Type d'événement inferred
Indemnisation calculée
Cette activité représente le moment où un montant de règlement a été déterminé mais n'a pas encore été approuvé pour paiement. Elle peut être déduite de la création d'un paiement en état d'« Approbation en attente ».
Pourquoi c'est important

Marque la transition de l'évaluation au paiement. C'est le point de départ pour mesurer le KPI 'Payment Authorization Lead Time', révélant les retards dans la chaîne d'approbation.

Où obtenir

Déduit du CreateTime d'un enregistrement cc_check ou cc_transaction dont le statut initial est 'Pending Approval' ou un état similaire avant 'Approved'.

Capture

Identifier la création d'un enregistrement de paiement ou de transaction en statut pré-approuvé.

Type d'événement inferred
Informations supplémentaires demandées
Représente une demande envoyée au demandeur ou à un tiers pour obtenir plus d'informations ou de documentation. Ceci est généralement enregistré comme une « Activité » (tâche) explicite créée dans ClaimCenter.
Pourquoi c'est important

Cette activité est le point de départ pour mesurer le KPI du « Temps de Cycle de Collecte d'Informations Supplémentaires ». Des occurrences fréquentes peuvent signaler des processus FNOL incomplets ou une collecte d'informations inefficace.

Où obtenir

Capturé à partir du CreateTime d'un enregistrement cc_activity où le ActivityPattern est lié à la demande de documentation ou d'informations auprès d'une partie externe.

Capture

Identifier la création d'une tâche de demande d'informations externes.

Type d'événement explicit
Informations supplémentaires reçues
Marque l'achèvement d'une demande d'informations complémentaires. Cela est enregistré lorsque l'Activity (tâche) correspondante est marquée comme 'Completed'.
Pourquoi c'est important

Ce jalon marque la fin de l'indicateur clé de performance (KPI) 'Temps de cycle de collecte d'informations supplémentaires'. Des délais importants entre la demande et la réception sont des causes fréquentes de retard dans le traitement des sinistres.

Où obtenir

Capturé à partir du CloseTime d'un enregistrement cc_activity où le ActivityPattern est lié à une demande d'informations. Le statut de l'activité doit être 'Completed'.

Capture

Identifier le timestamp de complétion d'une tâche de demande d'informations externes.

Type d'événement explicit
Sinistre Attribué
Représente l'affectation d'un sinistre à un utilisateur (expert) ou à un groupe spécifique pour traitement. Cela est généralement déduit en surveillant les modifications des champs d'affectation sur l'entité Sinistre.
Pourquoi c'est important

Le suivi des affectations est essentiel pour analyser la charge de travail des experts, identifier les goulots d'étranglement de l'acheminement et mesurer le délai de première action effectuée par le gestionnaire assigné.

Où obtenir

Déduit de la table cc_history en suivant les changements apportés aux champs AssignedUser ou AssignedGroup associés à un ID de réclamation spécifique. Le timestamp du changement indique le moment où l'événement s'est produit.

Capture

Surveiller les journaux d'audit ou les tables d'historique afin de détecter les mises à jour des champs d'affectation des sinistres.

Type d'événement inferred
Sinistre rouvert
Représente un sinistre passant d'un état « fermé » à un état « ouvert » pour effectuer un travail supplémentaire. Cet événement est déduit d'une séquence spécifique de changement de statut.
Pourquoi c'est important

Cette activité signale un retravail. Un volume élevé de sinistres rouverts indique des problèmes avec le règlement initial, des dommages non détectés ou d'autres défaillances de processus, entraînant une augmentation des coûts et une inefficacité.

Où obtenir

Déduit de la table cc_history en identifiant un changement dans le champ State de l'entité cc_claim de 'Closed' à 'Open' ou à un autre état actif.

Capture

Surveiller le champ de statut principal du sinistre afin de détecter une transition d'un état fermé vers un état ouvert.

Type d'événement inferred
Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Guidewire ClaimCenter