Votre modèle de données pour le traitement des sinistres
Votre modèle de données pour le traitement des sinistres
- Attributs recommandés pour la collecte de données sur les sinistres
- Activités clés à suivre dans votre processus de traitement des sinistres
- Guide d'extraction de données étape par étape pour Sapiens ClaimsPro
Attributs de Gestion des sinistres
| Nom | Descriptionn | ||
|---|---|---|---|
| Horodatage de l'événement EventTimestamp | La date et l'heure précises auxquelles une activité ou un *event* spécifique a commencé. | ||
| Descriptionn Le horodatage d'événement enregistre l'heure de début de chaque activité dans le processus de réclamation. Il fournit le contexte chronologique nécessaire pour séquencer les événements et calculer les durées entre eux. Ce horodatage est la base temporelle du log d'événements. Dans l'analyse Process Mining, cet attribut est indispensable pour calculer toutes les métriques liées au temps, y compris les temps de cycle, les temps d'attente et les durées d'activité. Il permet de identifier les points de blocage, d'analyser la performance du processus au fil du temps et de surveiller la conformité aux SLA, en fournissant la base factuelle des événements passés. Pourquoi est-ce important ? : Ce horodatage est indispensable pour ordonner les événements chronologiquement et pour calculer toutes les métriques basées sur la durée, telles que le temps de cycle et les points de blocage. Source des données : Situé dans les tables de journaux d'événements ou de transactions, parallèlement aux informations d'activité ou de changement de statut dans Sapiens ClaimsPro. Exemples 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Nom de l'activité ActivityName | Le nom de l'activité métier ou de l'événement spécifique qui s'est produit à un moment donné du processus de réclamation. | ||
| Descriptionn Cet attribut décrit une seule étape ou tâche effectuée dans le cycle de vie des réclamations, telle que « Réclamation Soumise », « Examen Initial Effectué » ou « Paiement Émis ». Chaque activité représente un point distinct dans le processus qui a un début et potentiellement une heure de fin. L'analyse des activités est le cœur du Process Mining. Elle facilite la visualisation de la cartographie des processus, l'identification des points de blocage entre les étapes, l'analyse de la fréquence des activités et la compréhension des variations de processus. La séquence des activités pour un Claim ID donné constitue la base du flux de processus. Pourquoi est-ce important ? : Il définit les étapes du processus, ce qui est indispensable pour créer la cartographie des processus et identifier les points de blocage ou les inefficacités. Source des données : Généralement dérivé des journaux d'événements, des enregistrements de changement de statut ou des tables d'achèvement de tâches dans Sapiens ClaimsPro. Peut nécessiter une correspondance à partir des codes de statut ou des types de transaction. Exemples Sinistre ComptabiliséEnquête initiéeIndemnisation calculéeSinistre Clos | |||
| Numéro de Sinistre ClaimId | L'identifiant unique pour chaque réclamation d'assurance, servant de *ID de cas* principal pour le suivi du cycle de vie de la réclamation. | ||
| Descriptionn L'ID de sinistre est l'identifiant de dossier clé qui lie tous les événements et activités associés à un sinistre unique. Il garantit que le parcours complet d'un sinistre, de la soumission initiale à la clôture finale, peut être reconstruit et analysé de manière cohérente. En Process Mining, chaque entrée du journal d'événements doit être associée à un ID de sinistre. Cela permet à l'outil de retracer le parcours complet de chaque sinistre, de visualiser les variantes de processus, de calculer les temps de cycle complet et d'identifier les points de blocage ou les écarts par rapport au flux de travail standard. L'analyse des données à travers le prisme de l'ID de sinistre offre une image complète de son parcours. Pourquoi est-ce important ? : Il est indispensable pour regrouper toutes les activités connexes en une seule instance de processus, permettant une analyse complet du cycle de vie des sinistres. Source des données : C'est une clé primaire dans la table de transactions principale des réclamations dans Sapiens ClaimsPro. Consultez la documentation système pour le nom exact de la table et du champ. Exemples CL-2023-001, 2, 3, 4CL-2023-005678CL-2024-009101 | |||
| Expert en sinistres désigné AssignedAdjuster | Le nom ou l'ID de l'expert en sinistres responsable du traitement de la réclamation ou d'une activité spécifique. | ||
| Descriptionn Cet attribut identifie l'utilisateur ou la ressource individuelle qui a effectué une action sur le dossier de sinistre. Le suivi du gestionnaire de sinistres assigné est indispensable pour comprendre la répartition de la charge de travail, la performance individuelle et l'affectation des ressources. En analyse, cela permet de filtrer la cartographie des processus pour observer comment les différents gestionnaires traitent les dossiers, de comparer leurs performances et d'identifier les besoins en formation. C'est un élément clé pour construire le tableau de bord 'Charge d'activité des gestionnaires et départements' et calculer l'indicateur clé de performance (KPI) 'Équilibre de la charge de travail des gestionnaires'. Pourquoi est-ce important ? : Indispensable pour l'analyse des ressources, cela permet d'identifier les déséquilibres de charge de travail, les collaborateurs très performants et les besoins en formation. Source des données : Trouvé dans les journaux d'activité des utilisateurs ou les tables de transactions dans Sapiens ClaimsPro, souvent lié à l'utilisateur qui a créé ou modifié en dernier un enregistrement. Exemples John Smithj.smithUSR-00451 | |||
| Gravité du Sinistre ClaimSeverity | Une classification de la complexité ou de l'impact financier potentiel de la réclamation (par ex., faible, moyen, élevé). | ||
| Descriptionn La gravité d'un sinistre est une évaluation attribuée à un sinistre pour indiquer sa complexité estimée, son risque ou son exposition financière. Cette évaluation détermine souvent le niveau d'examen, l'expérience requise du gestionnaire de sinistres et le workflow qu'il suivra. Cet attribut est indispensable pour le tableau de bord 'Analyse des temps de cycle par gravité des sinistres'. Il aide à comprendre si les sinistres plus complexes sont traités efficacement ou s'ils contribuent de manière disproportionnée à des temps de cycle longs. Il fournit un contexte vital pour les métriques de performance, car un sinistre de gravité élevée est censé prendre plus de temps qu'un sinistre de faible gravité. Pourquoi est-ce important ? : Fournit un contexte essentiel pour l'analyse du temps de cycle, aidant à expliquer pourquoi certains sinistres prennent plus de temps que d'autres « what-if » les cas complexes sont traités efficacement. Source des données : Il peut s'agir d'un champ saisi manuellement ou d'un score dérivé basé sur les caractéristiques de la réclamation dans Sapiens ClaimsPro. Exemples FaibleMoyenÉlevéComplexe | |||
| Heure de fin de l'événement EventEndTime | La date et l'heure précises auxquelles une activité spécifique s'est terminée. | ||
| Descriptionn L'Heure de fin d'événement marque la fin d'une activité. Si certains events sont instantanés (StartTime est égal à EndTime), de nombreuses activités ont une durée. Ce horodatage, lorsqu'il est disponibleble, permet de mesurer précisément le temps qu'a pris chaque étape. Cet attribut est utilisé pour calculer le « temps actif » ou le « temps de traitement » d'une activité, par opposition au « temps d'attente » entre les activités. Il permet de distinguer le temps passé à travailler activement sur une réclamation du temps qu'elle a passé à attendre dans une file d'attente. Ceci est impératif pour identifier les activités spécifiques qui sont particulièrement chronophages. Pourquoi est-ce important ? : Permet le calcul du temps de traitement actif pour les activités individuelles, aidant à distinguer le temps à valeur ajoutée du temps d'attente. Source des données : Peut être disponible dans les mêmes journaux de transactions que l'heure de début, ou peut devoir être déduit de l'heure de début de l'événement suivant. Consultez la documentation de Sapiens ClaimsPro. Exemples 2023-10-26T11:30:00Z2023-10-26T15:00:15Z2023-10-27T13:45:00Z | |||
| Montant de l'indemnisation SettlementAmount | Le montant monétaire final versé au demandeur pour régler la réclamation. | ||
| Descriptionn Cet attribut enregistre le montant de l'indemnisation de la réclamation. C'est une indicateur de résultat majeur qui reflète l'impact financier de la réclamation et les décisions prises pendant le processus. Dans l'analyse de processus, le « Montant de l'Indemnisation » est utilisé dans le tableau de bord « Aperçus Décision et Indemnisation des Réclamations » pour analyser comment les variations de processus ou le comportement des experts peuvent corréler avec les résultats de l'indemnisation. C'est également un élément d'entrée essentiel pour le KPI « Indice de Cohérence du Montant de l'Indemnisation », aidant à identifier les incohérences dans les décisions d'indemnisation pour des types de réclamations similaires. Pourquoi est-ce important ? : C'est une métrique de résultat essentielle. L'analyser en fonction des variantes de processus peut révéler comment les inefficacités ou les écarts de processus impactent les résultats financiers. Source des données : Trouvé dans les tables de transactions financières ou de paiement associées au sinistre dans Sapiens ClaimsPro. Exemples 5000.001250.75250000.00 | |||
| Service assigné AssignedDepartment | Le service ou l'équipe responsable du traitement de la réclamation à une étape donnée. | ||
| Descriptionn Cet attribut indique l'unité opérationnelle ou l'équipe, telle que 'Réception initiale', 'Sinistres complexes' ou 'UES (Unité d'Enquêtes Spéciales)', à laquelle un dossier ou une activité est assignée. Il permet une analyse du processus du point de vue départemental. L'analyse par département aide à identifier les points de blocage spécifiques à certaines équipes, à comprendre les transferts entre départements et à évaluer l'efficacité de chaque service. C'est un élément essentiel pour le tableau de bord 'Charge d'activité des gestionnaires et départements' et pour l'analyse de processus organisationnels de niveau supérieur. Pourquoi est-ce important ? : Permet d'analyser la performance des processus et les transferts entre différentes équipes, révélant ainsi les points de blocage organisationnels. Source des données : Souvent associé au profil de l'utilisateur dans le système ou attribué directement à l'obj« what-if »nistre. Consultez la documentation de Sapiens ClaimsPro. Exemples Division des sinistres automobilesSinistres immobiliersUnité d'enquête spéciale | |||
| Type de Sinistre ClaimType | La catégorie du sinistre d'assurance, telle que Automobile, Biens ou Responsabilité civile. | ||
| Descriptionn Le type de sinistre classifie les sinistres en fonction de la ligne d'affaires ou de la nature de la perte. C'est un attribut de segmentation clé qui dicte souvent le workflow de processus qu'un sinistre suivra et les équipes qui seront impliquées. L'analyse du processus par type de sinistre est indispensablele pour identifier les variations d'efficacité et de procédure entre les différentes lignes d'affaires. Par exemple, le processus pour un sinistre automobile peut être hautement automatisé et rapide, tandis qu'un sinistre de biens commerciaux peut être complexe et lent. Cet attribut est nécessaire pour calculer le KPI 'Indice de cohérence du montant de règlement'. Pourquoi est-ce important ? : Permet de comparer les processus entre différentes lignes d'affaires afin d'identifier les meilleures pratiques et les points de blocage spécifiques à chaque catégorie de sinistre. Source des données : Un champ standard de l'enregistrement principal de la réclamation dans Sapiens ClaimsPro, essentiel à tout système de gestion. Exemples Dommages matériels automobilesResponsabilité civile généraleIndemnisation des travailleursPropriété commerciale | |||
| Canal de soumission SubmissionChannel | La méthode par laquelle la réclamation a été initialement soumise (ex. : portail en ligne, agent, courrier). | ||
| Descriptionn Cet attribut identifie le canal de réception d'une nouvelle demande d'indemnisation. Des canaux différents peuvent avoir un impact significatif sur la qualité initiale des données, ce qui affecte ensuite l'ensemble du processus en aval. L'analyse du processus par canal de soumission permet de répondre aux questions d'efficacité et de qualité. Par exemple, le tableau de bord 'Efficacité des canaux de soumission des sinistres' peut révéler si les dossiers soumis via un portail en ligne ont des temps de cycle plus rapides et des taux de reprise plus faibles que ceux soumis par courrier. Cette information peut orienter les investissements en optimisation des canaux et en transformation digitale. Pourquoi est-ce important ? : Permet d'identifier les canaux d'entrée les plus efficaces pour le traitement, révélant ainsi des opportunités d'automatisation et d'amélioration de l'expérience client. Source des données : Généralement capturé au premier point de contact et stocké comme un champ sur l'enregistrement principal de la réclamation dans Sapiens ClaimsPro. Exemples Portail en ligneAgentCourrierTéléphone | |||
| Date cible de résolution ResolutionTargetDate | La date cible à laquelle la réclamation doit être clôturée, conformément aux accords de niveau de service (*SLA*). | ||
| Descriptionn La Date Cible de Résolution est une date limite fixée pour la clôture d'une réclamation, souvent déterminée par des facteurs tels que le type de réclamation, la juridiction ou les termes de la police. Elle sert de référence pour mesurer la performance et le respect des accords de niveau de service (SLA). Cette date est clée pour le tableau de bord « Conformité SLA de Résolution des Réclamations » et le KPI « Taux de Résolution des Réclamations dans les Délais ». En comparant la date réelle de « Réclamation Clôturée » avec cette cible, le système peut automatiquement classer les réclamations comme « Dans les Délais » ou « En Retard », offrant une vue claire de la performance des SLA. Pourquoi est-ce important ? : C'est la référence pour mesurer la conformité au SLA, permettant de calculer les taux de résolution dans les délais et d'identifier les sinistres à risque de retard. Source des données : Cette date peut être enregistrée dans le dossier principal du sinistre ou dans un module de gestion des SLA associé dans Sapiens ClaimsPro. Exemples 2024-01-152024-03-202024-06-01 | |||
| Date du sinistre LossDate | La date à laquelle l'incident ou l'événement qui a déclenché la réclamation s'est produit. | ||
| Descriptionn La Date de Perte, aussi appelée Date du Sinistre, est la date de l'événement réel (ex. : accident de voiture, dommage matériel) pour lequel la réclamation est effectuée. C'est souvent le point de départ de tout le parcours de la réclamation du point de vue du client. Cet attribut est important pour calculer le délai de déclaration, qui est le temps entre la Date de Perte et la date de « Réclamation Soumise ». L'analyse de ce délai peut fournir des aperçus sur le comportement des clients et identifier des opportunités pour encourager une déclaration plus rapide, ce qui conduit souvent à de meilleurs résultats. Pourquoi est-ce important ? : Définit le début de l'événement du sinistre lui-même, permettant l'analyse du délai de déclaration (temps entre le sinistre et la soumission de la demande). Source des données : Un champ clé de l'enregistrement principal de la réclamation, capturé lors de la première déclaration de sinistre (FNOL). Exemples 2023-10-202023-11-152024-01-05 | |||
| Dernière mise à jour des données LastDataUpdate | Le *horodatage* indiquant quand les *data* ont été rafraîchies ou extraites pour la dernière fois du système source. | ||
| Descriptionn Cet attribut consigne la date et l'heure de la dernière extraction de données de Sapiens ClaimsPro. Il est indispensable pour comprendre la la réactualisation des données analysées et est généralement uniforme pour tous les enregistrements d'un même jeu de données. Dans toute analyse ou tout tableau de bord, cet horodatage fournit un contexte essentiel sur la réactualisation des données. Il aide les utilisateurs à savoir s'ils consultent des informations en temps réel ou un instantané historique, ce qui est indispensable à prendre des décisions opérationnelles en temps opportun. Pourquoi est-ce important ? : Fournit un contexte sur la la réactualisation des données, garantissant que les utilisateurs savent à quel point l'analyse est à jour. Source des données : Cette valeur est générée et estampillée sur le jeu de données lors du processus d'extraction de données (ETL). Exemples 2024-05-21T02:00:00Z2024-05-20T02:00:00Z | |||
| Est un reprises IsRework | Un indicateur booléen calculé qui identifie les activités faisant partie d'une boucle de reprises. | ||
| Descriptionn Cet attribut est défini sur 'true' lorsqu'une activité ou une séquence d'activités est répétée pour le même dossier. Par exemple, si un dossier passe de 'Examen Initial' à 'Informations Supplémentaires Demandées', puis revient à 'Examen Initial', la deuxième instance de l'examen serait signalée comme une reprise. Signaler les reprises est impératif pour quantifier l'inefficacité du processus. Cela alimente le tableau de bord 'Tendances de reprise et de nouvelle soumission des sinistres' et le KPI 'Fréquence des boucles de reprise des sinistres'. En isolant et en analysant ces boucles de reprise, les organisations peuvent identifier les causes profondes, telles qu'une mauvaise qualité des données initiales ou des directives peu claires, et prendre des mesures pour réduire les efforts inutiles. Pourquoi est-ce important ? : Aide à quantifier l'inefficacité d'un processus en identifiant clairement les activités répétitives, ce qui permet de cibler les efforts d'amélioration. Source des données : Ceci ne provient pas du système source. C'est calculé par l'outil de Process Mining en détectant les séquences d'activités répétées au sein d'un même cas. Exemples truefaux | |||
| État du SLA SlaState | Un indicateur calculé signalant si une réclamation clôturée a respecté sa date cible de résolution. | ||
| Descriptionn Cet attribut est dérivé en comparant l'horodatage de l'activité 'Sinistre Clos' avec la 'Date Cible de Résolution'. Il catégorise les sinistres en statuts tels que 'Dans les délais' ou 'En retard', offrant un indicateur clair et immédiat de la performance des SLA. Ce champ calculé est l'élément central du tableau de bord 'Conformité SLA de résolution des sinistres'. Il simplifie l'analyse en permettant aux utilisateurs de filtrer instantanément tous les sinistres en retard et d'explorer les chemins de processus communs ou les points de blocage ayant entraîné le délai. Il contribue directement au le KPI 'Taux de résolution des sinistres dans les délais'. Pourquoi est-ce important ? : Mesure directement la conformité aux SLA, facilitant ainsi le filtrage et l'analyse des sinistres résolus en retard. Source des données : Cet attribut ne provient pas du système source. Il est calculé lors de la transformation des données en comparant l'EventHorodatage de l'activité 'Sinistre Clos' à la Date Cible de Résolution. Exemples Dans les tempsEn retard | |||
| Motif du refus ReasonForRejection | La raison spécifique fournie lorsqu'une réclamation est refusée ou qu'un paiement est rejeté. | ||
| Descriptionn Lorsqu'une décision de sinistre est « Refusée », cet attribut fournit la justification sous-jacente. Il peut s'agir d'un code standardisé ou d'une description en texte libre expliquant pourquoi le sinistre n'a pas été couvert, par exemple « Exclusion de la police », « Manque de preuves » ou « Soupçon de fraude ». Ces informationsns sont précieuses pour le tableau de bord 'Aperçus des décisions et règlements de sinistres'. L'analyse des motifs de rejet permet de déceler des tendances, comme un nombre élevé de refus dû à des informations incomplètes, ce qui pourrait révéler des problèmes dans la phase de collecte des données. Cela contribue à l'analyse des causes profondes des refus de sinistres. Pourquoi est-ce important ? : Fournit un contexte essentiel pour les sinistres refusés, permettant l'analyse des causes profondes afin de réduire les taux de refus et d'améliorer la qualité des soumissions. Source des données : Associé aux activités 'Sinistre refusé' ou 'Décision de sinistre prise', probablement stocké dans un champ de statut ou de code de motif dans Sapiens ClaimsPro. Exemples Exclusion de policeRisque non couvertInformations demandées non fourniesSinistre en double | |||
| Numéro de police PolicyNumber | L'identifiant unique de la police d'assurance sous laquelle le sinistre a été déclaré. | ||
| Descriptionn Le Numéro de Police relie la réclamation au contrat d'assurance spécifique détenu par le demandeur. Cela fournit un contexte essentiel concernant la couverture, les limites et les franchises qui influencent le traitement et les décisions relatives aux réclamations. Bien qu'il ne soit pas toujours utilisé directement dans l'analyse des flux de processus, c'est un attribut essentiel pour toute investigation approfondie. Il permet aux analystes de connecter les data de réclamation aux data de police, offrant une vue plus holistique de la relation client et du profil de risque. Il peut également être utilisé pour agréger les réclamations par police afin d'identifier les polices problématiques ou les tendances. Pourquoi est-ce important ? : Lie le sinistre au contrat d'assurance, permettant une analyse plus approfondie en connectant les données de processus aux détails de la police, tels que la couverture et les limites. Source des données : Un champ standard de l'enregistrement principal de la réclamation dans Sapiens ClaimsPro, le reliant au système d'administration des polices. Exemples POL-987654321POL-1, 2, 3, 456789POL-555444333 | |||
| Statut du Sinistre ClaimStatus | L'état opérationnel actuel de la réclamation (ex. : Ouverte, En attente, Clôturée). | ||
| Descriptionn Cet attribut représente le statut global du dossier de sinistre à tout moment donné. Alors que les activités sont des événements, le statut est l'état du dossier résultant de ces événements. Il offre une synthèse de haut niveau de la position du dossier dans son cycle de vie. L'analyse du statut des sinistres aide à comprendre l'inventaire des dossiers ouverts et leur étape actuelle. Il est utile pour les dashboards opérationnels et pour calculer le KPI 'Score de Transparence du Statut des Sinistres' en suivant la fréquence et la pertinence des mises à jour du statut tout au long du processus. Pourquoi est-ce important ? : Offre une vue d'ensemble de l'état actuel d'un sinistre, utile pour suivre la charge de travail en cours et comprendre la progression du dossier. Source des données : Un champ principal de l'enregistrement de réclamation dans Sapiens ClaimsPro, mis à jour par diverses transactions métier. Exemples OuvertEn attente - Informations requisesClôturé - PayéClôturé - Refusé | |||
| Système source SourceSystem | Identifie le système source d'extraction des données, en l'occurrence Sapiens ClaimsPro. | ||
| Descriptionn Cet attribut fournit un contexte sur l'origine des données du processus. Bien qu'il puisse s'agir d'une valeur constante comme 'Sapiens ClaimsPro' pour cet ensemble de données spécifique, il est impératif dans les environnements où les données sont fusionnées à partir de plusieurs systèmes. Pour l'analyse, il facilite la gouvernance des données, le dépannage et garantit que les informations sont correctement attribuées au système source. C'est un champ clé pour maintenir la traçabilité des données et comprendre le contexte technologique du processus. Pourquoi est-ce important ? : Assure la traçabilité et la traçabilité des données, ce qui est indispensable lorsque les données de plusieurs systèmes sont combinées ou à des fins d'audit. Source des données : C'est généralement une valeur statique ajoutée lors du processus d'extraction, de transformation et de chargement des données (ETL) pour étiqueter l'origine des enregistrements. Exemples Sapiens ClaimsProClaimsPro v10.1 | |||
Activités de Gestion des sinistres
| Activité | Descriptionn | ||
|---|---|---|---|
| Décision sur le Sinistre Prise | La décision officielle d'approuver, d'approuver partiellement ou de refuser la réclamation a été prise et enregistrée par un expert en sinistres autorisé. Il s'agit d'une étape pivot dans le processus. | ||
| Pourquoi est-ce important ? : C'est un point de décision crucial qui détermine le cheminement ultérieur du processus (paiement ou clôture). L'analyse du temps de décision est un indicateur clé de performance. Source des données : Il s'agit probablement d'un événement distinct, enregistré lorsque le champ de disposition ou de décision de la réclamation est renseigné et sauvegardé (par ex. 'Approuvé', 'Refusé'). Capture Horodatage lorsque le champ/statut de décision (par ex., 'Statut de la Réclamation') est défini sur une décision finale comme 'Approuvée' ou 'Refusée'. Type d'événement explicit | |||
| Enquête terminée | Signifie que toutes les activités d'enquête nécessaires ont été conclues et que les conclusions ont été documentées. C'est une condition préalable à la prise d'une décision finale concernant le sinistre. | ||
| Pourquoi est-ce important ? : Cette étape clé marque la fin de la phase de collecte de preuves. Elle permet d'analyser l'efficacité de l'enquête et son impact sur le temps de prise de décision. Source des données : Déduit d'un changement de statut vers 'Investigation terminée' ou 'Décision en attente', ou de l'horodatage de complétion de la tâche d'investigation finale. Capture Horodatage du changement de statut indiquant la fin de l'enquête ou que toutes les sous-tâches d'enquête sont marquées comme terminées. Type d'événement inferred | |||
| Paiement émis | La transaction financière pour payer le montant de l'indemnisation a été exécutée. Cet événement marque le moment où les fonds sont envoyés au demandeur ou au bénéficiaire. | ||
| Pourquoi est-ce important ? : C'est une étape clé, en contact direct avec le client. La durée entre la 'Claim Decision Made' et cette activité influence fortement la satisfaction client. Source des données : Capturé à partir de l'horodatage de l'enregistrement de la transaction de paiement dans le module financier, qui est lié à l'ID du sinistre. Capture Horodatage du journal des transactions de paiement ou de l'enregistrement de l'interface du système financier associé à la réclamation. Type d'événement explicit | |||
| Sinistre Clos | Le dossier de sinistre est officiellement clos dans le système, signifiant que toutes les activités, y compris le paiement ou la communication du refus, sont terminées. Il s'agit du principal événement de fin réussi. | ||
| Pourquoi est-ce important ? : Cette activité marque la fin du processus, permettant le calcul du temps de cycle total complet pour chaque réclamation. Source des données : Déduit de l'horodatage lorsque le statut principal du sinistre est mis à jour vers 'Fermé' ou un statut final équivalent. Capture Horodatage du changement de statut à 'Clôturée' dans le champ de statut principal de la réclamation. Type d'événement inferred | |||
| Sinistre Comptabilisé | Représente la création et l'assignation formelles d'un ID de sinistre unique dans Sapiens ClaimsPro. Cela fait généralement suite à la soumission initiale « what-if »gnifie que le sinistre est officiellement dans le système pour traitement. | ||
| Pourquoi est-ce important ? : Établit le début officiel du traitement interne. La durée entre la « Soumission du sinistre » et cette activité mesure l'efficacité de la prise en charge. Source des données : Déduit de l'horodatage lorsque le statut d'un dossier de sinistre passe d'un état préliminaire (par exemple, 'en attente') à 'enregistré' ou 'ouvert'. Il peut également s'agir d'une entrée de journal explicite. Capture Horodatage du changement de statut de la réclamation à 'Comptabilisée', 'Ouverte', ou un statut actif équivalent. Type d'événement inferred | |||
| Sinistre Déclaré | Marque la réception initiale d'un sinistre, provenant d'un assuré ou d'un tiers, quel que soit le canal de soumission. C'est le point de départ du cycle de vie des sinistres et il est souvent capturé via une intégration ou une saisie manuelle de données. | ||
| Pourquoi est-ce important ? : Cette activité est le principal event de début pour le processus. L'analyse du temps écoulé entre la soumission et l'enregistrement aide à identifier les retards dans la saisie des data et la configuration initiale de la réclamation. Source des données : Probablement capturé à partir de l'horodatage de création du dossier de sinistre initial ou d'un champ 'date de soumission' spécifique dans la table principale des sinistres. Capture L'événement de création du dossier de sinistre dans le système, souvent associé à une entrée de première déclaration de sinistre (FNOL). Type d'événement explicit | |||
| Demande refusée | Le sinistre a été officiellement refusé et le dossier est en cours de prélèvement.paration pour la clôture. Cela fait suite à l'activité « Décision de sinistre prise » où la décision était « Refusé ». | ||
| Pourquoi est-ce important ? : Représente un chemin de processus alternatif clé. L'analyse de ce chemin peut révéler des schémas dans les sinistres refusés et garantir que les procédures appropriées ont été suivies. Source des données : C'est souvent le même événement que 'Réclamation clôturée', mais se distingue par l'attribut de décision finale. Il peut être modélisé comme une activité distincte si la valeur du champ 'Décision' est 'Refusé'. Capture À dériver de l'événement « Sinistre clôturé » lorsque l'attribut de décision finale du sinistre est « Refusé » ou similaire. Type d'événement calculated | |||
| Enquête initiée | Marque le début de la phase d'enquête formelle pour le sinistre. Cela peut impliquer l'affectation de spécialistes, la planification d'inspections ou d'autres activités détaillées de collecte de preuves. | ||
| Pourquoi est-ce important ? : Cette activité marque le début d'une phase critique et souvent chronophage. Mesurer la durée de l'enquête est indispensable pour identifier les principaux points de blocage. Source des données : Probablement déduit d'un changement de statut vers 'En cours d'investigation' ou de la date de création de la première tâche ou affectation liée à l'enquête. Capture Horodatage lorsque le statut de la réclamation est mis à jour vers 'Enquête en cours' ou un état similaire. Type d'événement inferred | |||
| Examen initial effectué | Un gestionnaire de sinistres a effectué la première évaluation des détails du sinistre et de la documentation soumis. Cette étape détermine la validité initiale et les prochaines étapes du sinistre. | ||
| Pourquoi est-ce important ? : Cette étape est indispensablele pour comprendre la rapidité de triage des réclamations. Des retards à ce niveau peuvent impacter significativement le temps de cycle global et la satisfaction client. Source des données : Probablement déduit d'un horodatage associé à un changement de statut vers 'En cours d'examen', 'Examiné', ou à l'achèvement d'une tâche/étape de workflow d'examen initial. Capture Horodatage de fin d'une tâche « Examen initial » ou d'un événement de mise à jour du statut dans le journal d'événements ou le tableau d'historique du sinistre. Type d'événement inferred | |||
| Indemnisation calculée | Suite à une décision d'approbation, le montant final de l'indemnisation payable au demandeur a été calculé. Cette étape précède l'autorisation de paiement. | ||
| Pourquoi est-ce important ? : Mesure l'efficacité de l'étape de calcul financier après qu'une décision a été prise. Des points de blocage à ce niveau peuvent retarder le paiement final. Source des données : Déduit de l'horodatage lorsque le champ 'Montant du règlement' est renseigné et confirmé dans le module financier du système. Capture Horodatage associé à la finalisation du champ 'Montant du Règlement' sur l'enregistrement de la réclamation. Type d'événement inferred | |||
| Informations complémentaires demandées | Le gestionnaire de sinistres a identifié des informations manquantes ou incomplètes et a envoyé une demande à l'assuré ou à un tiers. Cette activité déclenche un état d'attente courant dans le processus. | ||
| Pourquoi est-ce important ? : Cette activité est le début d'une boucle de reprises. Une fréquence élevée indique des problèmes avec la collecte initiale des data, entraînant des retards et une augmentation de l'effort manuel. Source des données : Peut être un événement explicite enregistré lors de l'envoi d'une correspondance ou déduit d'un changement de statut de sinistre vers 'En attente d'informations' ou 'En suspens'. Capture Horodatage du changement de statut de la réclamation vers un état 'Informations en attente' ou enregistrement dans le journal pour une communication sortante. Type d'événement inferred | |||
| Informations supplémentaires reçues | Représente la réception des informations demandées, permettant ainsi la reprise du traitement du sinistre. Cet événement clôt la boucle de reprises initiée par la demande. | ||
| Pourquoi est-ce important ? : L'analyse du temps écoulé entre la demande d'« Informations complémentaires » et cette activité révèle les retards externes et aide à gérer les attentes des clients. Source des données : Déduit du changement de statut du sinistre, passant de 'Informations en attente' à un état actif comme 'Ouvert' ou 'En cours d'examen'. Peut également être lié à un journal de documents entrants. Capture Horodatage du changement de statut d'un état 'En attente' à un état 'Actif', souvent déclenché par un upload de document. Type d'événement inferred | |||
| Paiement autorisé | L'approbation interne a été accordée pour le versement des fonds de règlement. Cela implique souvent la revue et l'autorisation du paiement par un responsable ou un membre distinct de l'équipe financière. | ||
| Pourquoi est-ce important ? : Identifie les retards potentiels dans le workflow d'approbation financière interne, une fois la décision de sinistre prise et le montant calculé. Source des données : Il s'agit probablement d'un événement explicite déclenché par une action d'approbation dans le workflow du système, ou par un changement de statut vers 'En attente de paiement' ou 'Approuvé pour paiement'. Capture Une entrée de journal d'événements explicite ou un horodatage de changement de statut indiquant que le paiement a été approuvé. Type d'événement explicit | |||
| Perte évaluée | L'événement où la valeur financière de la perte a été formellement déterminée et enregistrée. C'est une donnée clé pour le calcul du montant final de l'indemnisation. | ||
| Pourquoi est-ce important ? : Cette étape est indispensablele pour la planification financière et la gestion des réserves. Des retards dans l'évaluation des pertes peuvent bloquer l'ensemble du processus de règlement et de paiement. Source des données : Probablement enregistré comme un horodatage lorsque les champs de réserve financière ou de montant de perte sont finalisés ou approuvés dans le système. Capture Le horodatage associé à la saisie ou à l'approbation finale des champs « Montant de la Perte » ou « Montant de la Réserve ». Type d'événement explicit | |||
| Sinistre rouvert | Une réclamation clôturée a été réactivée pour nouvel examen ou action. Cet événement exceptionnel peut survenir en cas de nouvelles informations ou d'un appel. | ||
| Pourquoi est-ce important ? : Met en lumière les exceptions de processus et les défaillances potentielles dans la gestion initiale des sinistres. Un taux élevé de sinistres rouverts peut révéler des problèmes de qualité de décision ou de communication client. Source des données : Déduit d'un changement de statut de 'Fermé' à 'Ouvert' ou 'En cours d'examen'. Capture Horodatage d'un changement de statut d'un état final/clôturé vers tout état actif/ouvert. Type d'événement inferred | |||
Guides d'extraction
Les méthodes d'extraction pour ce processus sont en cours de validation. Veuillez revenir plus tard ou contactez-nous pour obtenir de l'aide.