Modèle de Données : Traitement des Réclamations
Votre modèle de données pour le traitement des sinistres
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide d'extraction pour Duck Creek Claims
Attributs de Gestion des Sinistres
| Nom | Description | ||
|---|---|---|---|
Heure de l'événement EventTime | L'horodatage indiquant quand une activité ou un événement spécifique s'est produit. | ||
Description L'Heure d'événement fournit la date et l'heure précises de chaque activité enregistrée dans le cycle de vie de la réclamation. Cette information temporelle est cruciale pour l'analyse de performance. En analyse, cet horodatage est utilisé pour calculer les temps de cycle entre les activités, identifier les temps d'attente, mesurer la durée globale du dossier et analyser la performance du processus sur différentes périodes. C'est l'épine dorsale de toute métrique de processus basée sur le temps. Pourquoi c'est important Cet horodatage est crucial pour le calcul de toutes les métriques basées sur le temps, telles que les temps de cycle et les durées, permettant l'analyse de la performance et l'identification des goulots d'étranglement. Où obtenir Il s'agit d'un champ d'horodatage standard associé aux journaux d'événements ou de transactions dans Duck Creek Claims. Recherchez des champs comme 'CreateDate', 'Timestamp' ou 'EventDate'. 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 qui s'est produit à un moment précis pour un sinistre. | ||
Description Cet attribut décrit une étape ou une tâche spécifique effectuée dans le processus de gestion des sinistres, telle que « Claim Submitted », « Adjuster Assigned » ou « Payment Issued ». Chaque activité représente un point distinct dans le cycle de vie du sinistre. L'analyse de la séquence et de la fréquence de ces activités est au 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 écarts de processus par rapport à un modèle standard. Pourquoi c'est important Le nom de l'activité définit les étapes du flux de processus, ce qui est fondamental pour la découverte, l'analyse et le suivi du processus de gestion des sinistres. Où obtenir Généralement dérivé des journaux d'événements, des noms de transactions ou des enregistrements de changement de statut au sein de Duck Creek Claims. Cela peut nécessiter un mappage à partir de plusieurs champs ou tables sources. Exemples Sinistre DéclaréExpert désignéEnquête initiéePaiement émisSinistre Clos | |||
Numéro de Sinistre ClaimId | L'identifiant unique d'un sinistre d'assurance, servant d'identifiant principal de cas. | ||
Description L'ID du sinistre est la clé fondamentale qui relie tous les événements et activités associés à un même sinistre d'assurance, de la soumission à la clôture. Il garantit que le cycle de vie complet d'un sinistre peut être suivi de manière cohérente. Dans l'analyse Process Mining, cet attribut est essentiel pour construire la vue des cas, permettant aux analystes de retracer le parcours complet de chaque sinistre, de mesurer les temps de cycle de bout en bout et d'analyser les variantes de processus. Pourquoi c'est important C'est l'ID de dossier essentiel qui relie tous les événements connexes du processus, permettant une vue complète, de bout en bout, du cycle de vie de la réclamation. Où obtenir Il s'agit d'une clé primaire dans l'entité ou la table principale des réclamations de Duck Creek Claims. Consultez la documentation du système pour connaître le nom spécifique de la table et du champ. Exemples CL-2023-001234CL-2023-005678CL-2024-009101 | |||
Département Department | Le département ou l'équipe responsable de l'activité ou du sinistre à un moment donné. | ||
Description Cet attribut spécifie le groupe fonctionnel ou le département, tel que « Initial Intake », « Investigation Unit » ou « Settlement Team », qui gère le sinistre. Il fournit un contexte organisationnel au flux de processus. L'analyse par département est essentielle pour comprendre la performance des processus à un niveau agrégé. Elle aide à identifier les goulots d'étranglement interdépartementaux, à mesurer l'efficacité au niveau des équipes et à comprendre comment le travail circule au sein de l'organisation. Pourquoi c'est important Permet d'analyser la performance par domaine fonctionnel, mettant en lumière les transferts inter-services et les goulots d'étranglement propres à chaque équipe. Où obtenir Consultez la documentation de Duck Creek Claims. Cette information est souvent associée au profil de l'utilisateur assigné ou à une attribution de file d'attente/groupe de travail. Exemples Sinistres automobilesRéclamations immobilières - Sinistres majeursUnité des enquêtes spécialesTraitement des paiements | |||
Expert en sinistres désigné AssignedAdjuster | Le nom ou l'ID de l'expert en sinistres responsable du traitement du sinistre à une activité donnée. | ||
Description Cet attribut identifie l'utilisateur ou la ressource effectuant une activité. Il peut changer tout au long du cycle de vie du sinistre à mesure que le dossier est transféré entre différents gestionnaires de sinistres ou équipes. C'est essentiel pour analyser la performance des ressources, la répartition de la charge de travail et les transferts. Les dashboards axés sur le débit des gestionnaires, la variance de la charge de travail et l'identification des goulots d'étranglement s'appuient souvent fortement sur cet attribut pour comprendre comment le travail est alloué et traité par les individus. Pourquoi c'est important Permet l'analyse de la performance des ressources, l'équilibrage de la charge de travail et les schémas de collaboration, aidant à identifier les goulots d'étranglement et les besoins en formation. Où obtenir Consultez la documentation de Duck Creek Claims. Recherchez les champs utilisateur, propriétaire ou cessionnaire dans les tables liées aux tâches de réclamation, aux événements ou à l'entité de réclamation principale. Exemples John SmithJane DoeRobert Brownadjuster_1138 | |||
Gravité du Sinistre ClaimSeverity | Une classification de la complexité financière ou opérationnelle de la réclamation, telle que Faible, Moyenne ou Élevée. | ||
Description La Gravité du Sinistre indique l'impact ou la complexité anticipée d'un sinistre. Elle peut être basée sur l'estimation initiale de la perte, la nature de l'incident ou d'autres règles métier prédéfinies. Cet attribut est essentiel pour l'analyse de la performance, car les sinistres de gravité élevée nécessitent généralement plus d'étapes, des délais de traitement plus longs et des ressources spécialisées. La segmentation des KPI par gravité aide à fixer des objectifs de performance réalistes et à comprendre comment la complexité affecte l'efficacité du processus et ses résultats. Pourquoi c'est important Permet de segmenter les sinistres par complexité, ce qui permet une analyse de performance plus nuancée et une évaluation comparative réaliste des durées de cycle et des coûts. Où obtenir Consultez la documentation de Duck Creek Claims. Il peut s'agir d'un champ dédié ou dérivé du montant initial de la réserve de sinistre. Exemples FaibleMoyenÉlevéCatastrophique | |||
Montant de la perte LossAmount | Le montant financier estimé ou réel de la perte déclarée dans le sinistre. | ||
Description Cet attribut représente le Loss Amount initial estimé associé au sinistre. C'est un indicateur financier clé qui influence souvent l'acheminement, la gravité et le niveau d'enquête requis pour le sinistre. Dans l'analyse, le Loss Amount est utilisé pour segmenter les sinistres et comprendre comment l'impact financier est corrélé au comportement du processus. Par exemple, les sinistres de valeur plus élevée peuvent suivre des parcours différents ou avoir des temps de cycle plus longs. Il fournit un contexte financier crucial aux data opérationnelles du processus. Pourquoi c'est important Fournit un contexte financier à la réclamation, permettant d'analyser comment la valeur d'une réclamation impacte son parcours de traitement, sa durée et son résultat. Où obtenir Consultez la documentation de Duck Creek Claims. Il s'agit d'un champ financier fondamental de la réclamation, souvent désigné par 'Sinistre déclaré' ou 'Réserve initiale'. Exemples 1500.0025000.50125000.00 | |||
Statut du Sinistre ClaimStatus | Le statut global du sinistre à un moment donné, tel que Ouvert, En attente ou Clos. | ||
Description Le Statut du Sinistre représente l'état actuel du sinistre dans son cycle de vie. Il fournit un résumé de haut niveau de la position du sinistre dans le processus global. Cet attribut est utile pour créer des vues d'ensemble de l'inventaire des sinistres et pour filtrer les dossiers. Il est particulièrement important pour identifier le résultat final d'un sinistre (ex. : 'Clos - Réglé', 'Clos - Refusé'), ce qui est essentiel pour l'analyse des résultats et la compréhension des taux de rejet. Pourquoi c'est important Fournit un aperçu de l'état actuel et du résultat final de la réclamation, crucial pour l'analyse des résultats et le filtrage des cas. Où obtenir Consultez la documentation de Duck Creek Claims. Il s'agit d'un champ fondamental de l'enregistrement principal de la réclamation. Exemples OuvertEn attente - Informations requisesClos - RégléClôturé - Refusé | |||
Type de Sinistre ClaimType | La catégorie du sinistre d'assurance, telle que Automobile, Biens ou Responsabilité civile. | ||
Description Le Type de Sinistre classe les sinistres en fonction de la ligne d'activité ou de la nature de la perte. C'est une dimension fondamentale pour segmenter et analyser les données de sinistre. Cet attribut est utilisé pour comparer la performance des processus entre différents types de sinistres. Par exemple, un sinistre de type 'Automobile - Perte Totale' suit un processus très différent et a des KPI distincts d'un sinistre de type 'Immobilier - Dégâts des Eaux'. L'analyse par Type de Sinistre fournit un contexte et permet des comparaisons de performance plus significatives ainsi que des initiatives d'amélioration de processus sur mesure. Pourquoi c'est important C'est une dimension essentielle pour segmenter l'analyse, car les différents types de sinistres ont souvent des processus, des SLA et des niveaux de complexité distincts. Où obtenir Consultez la documentation de Duck Creek Claims. Il s'agit d'un attribut essentiel de l'enregistrement principal de la réclamation. Exemples Automobile personnelle - CollisionPropriété Commerciale - IncendieIndemnisation des travailleursResponsabilité civile générale | |||
Date cible de résolution ResolutionTargetDate | La date cible à laquelle le sinistre devrait être résolu, basée sur les SLA ou les objectifs internes. | ||
Description Cet attribut stocke la date limite de clôture du sinistre. Cette date est souvent déterminée par les exigences réglementaires, les accords de niveau de service (SLA) ou les indicateurs clés de performance (KPI) internes, et peut varier en fonction du type ou de la gravité du sinistre. C'est la base pour le calcul du KPI « Taux de résolution des sinistres dans les délais » et le support du dashboard « Respect de l'objectif de résolution des sinistres ». Cela permet un suivi proactif des sinistres risquant de ne pas respecter leur SLA et aide à prioriser le travail. Pourquoi c'est important Permet la mesure de la performance par rapport aux accords de niveau de service (SLA) et aux objectifs internes, ce qui impacte directement la satisfaction client et la conformité. Où obtenir Consultez la documentation de Duck Creek Claims. Il peut s'agir d'un champ de date SLA spécifique ou d'une valeur calculée en fonction de la date de soumission de la réclamation et des règles métier. Exemples 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
Dernière mise à jour des données LastDataUpdate | L'horodatage de la dernière actualisation des données depuis le système source. | ||
Description Cet attribut indique la dernière date de mise à jour du dataset. Il fournit un point de référence sur l'actualité des data analysées. Dans les dashboards et l'analyse, il est utilisé pour informer les utilisateurs de la récence des insights. Il aide à gérer les attentes quant à l'inclusion des dernières transactions dans la vue du processus. Pourquoi c'est important Informe les utilisateurs sur la fraîcheur des données, ce qui est essentiel pour interpréter l'analyse et prendre des décisions opportunes. Où obtenir Cet horodatage est généré pendant le processus d'extraction, de transformation et de chargement (ETL) des données et est généralement stocké dans les métadonnées du dataset. Exemples 2024-05-21T02:00:00Z | |||
Est automatisé IsAutomated | Un indicateur booléen signalant si l'activité a été effectuée automatiquement par le système sans intervention humaine. | ||
Description Ce flag distingue les tâches effectuées par des utilisateurs humains de celles exécutées par l'automatisation du système, telles que les notifications automatiques, la validation initiale des data ou les étapes de traitement direct. L'analyse de cet attribut est essentielle pour comprendre le niveau d'automatisation dans le processus de gestion des sinistres. Elle aide à mesurer l'impact des initiatives d'automatisation, à identifier les opportunités d'automatisation supplémentaires et à garantir que les étapes automatisées fonctionnent comme prévu sans créer de problèmes en aval. Pourquoi c'est important Permet de mesurer l'impact de l'automatisation sur l'efficacité et les coûts, et d'identifier les opportunités de traitement direct. Où obtenir Cette information peut être déduite de l'« user » associé à un event (par exemple, « SYSTEM » ou « BATCH »), ou d'un flag spécifique sur l'enregistrement de l'event. Exemples truefaux | |||
Est-ce une reprise IsRework | Un indicateur calculé signalant si une activité fait partie d'une boucle de retravail. | ||
Description Cet attribut booléen est défini sur true si une activité est répétée pour un sinistre après que d'autres activités différentes se soient déjà produites. Par exemple, si le processus passe de « Loss Assessed » à nouveau à « Investigation Started ». Cet attribut est essentiel pour quantifier et analyser le retravail. Il soutient le KPI « Taux de retravail des sinistres » et le dashboard « Modèles de retravail et de retraitement des sinistres » en permettant le filtrage et la mise en évidence directe des activités et des dossiers impliquant un retravail. Cela aide à identifier les inefficacités et les problèmes de qualité dans le processus. Pourquoi c'est important Quantifie la reprise au niveau de l'activité, facilitant la mesure, la visualisation et l'analyse des causes et des impacts des inefficacités de processus. Où obtenir Ce n'est pas un champ du système source. Il est calculé lors de la préparation des données à l'aide d'algorithmes qui détectent les séquences d'activités répétées au sein d'un dossier. Exemples truefaux | |||
Heure de Fin EndTime | L'horodatage indiquant quand une activité a été achevée. | ||
Description Cet attribut marque le EndTime d'une activité. Alors que StartTime indique quand une activité a commencé, EndTime fournit l'autre côté du calcul de la durée pour cette tâche spécifique. En Process Mining, disposer à la fois d'un StartTime et d'un EndTime pour les activités permet une analyse de performance bien plus approfondie. Cela permet le calcul précis du « Processing Time » (le temps de travail actif sur une tâche) versus le « Waiting Time » (le temps passé entre les tâches). Cette distinction est cruciale pour identifier précisément les goulots d'étranglement. Pourquoi c'est important Permet le calcul de temps de traitement précis pour chaque activité, distinguant le temps de travail actif du temps d'inactivité/d'attente, ce qui est crucial pour une analyse précise des goulots d'étranglement. Où obtenir Peut être disponible comme champ d'horodatage distinct dans les journaux d'événements ou peut être dérivé comme le StartTime de l'activité suivante dans la séquence pour le même cas. Exemples 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
Montant de l'indemnisation SettlementAmount | Le montant financier final convenu pour régler le sinistre. | ||
Description Cet attribut enregistre la valeur du règlement qui a été calculé et autorisé pour le paiement. C'est un indicateur clé basé sur les résultats pour chaque sinistre donnant lieu à un paiement. Cet attribut est crucial pour l'analyse financière et pour des dashboards comme « Temps d'autorisation et d'émission des paiements ». Il peut être comparé au « Loss Amount » initial pour analyser la précision des provisions et est fondamental pour comprendre les résultats financiers du processus de gestion des sinistres. Pourquoi c'est important Représente le résultat financier clé d'un sinistre, essentiel pour les rapports financiers et l'analyse de la précision des estimations initiales des pertes. Où obtenir Consultez la documentation de Duck Creek Claims. Ces informations sont généralement stockées dans les tables de transactions financières ou liées aux paiements associées à la réclamation. Exemples 1450.7522000.00115800.20 | |||
Motif de refus RejectionReason | Le motif spécifique de refus ou de rejet d'un sinistre. | ||
Description Lorsqu'une décision est prise de refuser une réclamation, cet attribut fournit la raison sous-jacente à cette décision. Elle est généralement sélectionnée à partir d'une liste prédéfinie de codes ou de descriptions. L'analyse des motifs de rejet est essentielle pour le dashboard 'Aperçus des décisions et rejets de réclamations'. Elle aide à identifier les problèmes courants liés aux soumissions, les schémas de fraude potentiels, ou les zones où le langage de la police d'assurance peut être peu clair. Ces informations peuvent permettre des améliorations dans le processus de saisie ou les règles de souscription. Pourquoi c'est important Explique pourquoi les réclamations sont refusées, fournissant des informations exploitables pour améliorer le processus d'admission, réduire les soumissions invalides et identifier les opportunités de formation. Où obtenir Consultez la documentation de Duck Creek Claims. Ce champ est généralement renseigné lorsque le statut d'une réclamation passe à 'Refusée' ou à un état similaire. Exemples Péril non couvertPolice expiréeRéclamation DupliquéeFraude présumée | |||
Numéro de police PolicyNumber | L'identifiant unique de la police d'assurance sous laquelle le sinistre a été déclaré. | ||
Description Cet attribut relie le sinistre à la police d'assurance d'origine. Il fournit un contexte sur la couverture, les conditions et le client associés au sinistre. Bien qu'il ne soit pas toujours utilisé directement dans l'analyse des flux de processus, le numéro de police est inestimable pour enrichir les data du sinistre. Il permet de les joindre aux data de police et de client pour analyser comment la performance du processus varie selon le segment de clientèle, le type de police ou l'âge de la police, offrant ainsi une vue métier plus globale. Pourquoi c'est important Lie la réclamation au client et à la police, permettant une analyse plus large de l'impact de la performance des processus sur différents segments de clientèle ou types de police. Où obtenir Consultez la documentation de Duck Creek Claims. Il s'agit d'un champ de référence standard sur l'entité de réclamation principale. Exemples PA-987654321CP-123456789WC-555444333 | |||
Résolution dans les délais IsOnTimeResolution | Un indicateur calculé qui indique si une réclamation a été clôturée à la date cible de résolution ou avant. | ||
Description Cet attribut booléen est dérivé en comparant le timestamp de l'activité « Claim Closed » avec la « ResolutionTargetDate » pour ce sinistre. Il marque chaque sinistre comme étant dans les délais (true) ou en retard (false). Cet attribut soutient directement le KPI « Taux de résolution des sinistres dans les délais ». Il permet une agrégation et une visualisation faciles du respect des SLA dans les dashboards, et facilite l'analyse en profondeur pour identifier les caractéristiques communes des sinistres en retard (par exemple, types de sinistres spécifiques, départements ou parcours de processus). Pourquoi c'est important Mesure directement la conformité aux SLA au niveau de chaque réclamation, permettant un filtrage puissant et une analyse des causes profondes pour les réclamations en retard. Où obtenir Ce n'est pas un champ du système source. Il est calculé lors de la préparation des données en comparant l'horodatage de l'activité finale au champ 'ResolutionTargetDate'. Exemples truefaux | |||
Système source SourceSystem | Le système à partir duquel les données d'événement ont été extraites. | ||
Description Cet attribut identifie l'application source d'où proviennent les data du sinistre. Dans ce contexte, il s'agira systématiquement de « Duck Creek Claims ». Bien que cela puisse sembler redondant si toutes les data proviennent d'un seul système, c'est crucial pour la data governance, la traçabilité et dans les scénarios où les data pourraient être fusionnées de plusieurs systèmes à l'avenir. Cela fournit un contexte sur l'origine et la structure des data. Pourquoi c'est important Fournit une traçabilité des données et un contexte essentiel, cruciaux pour la gouvernance des données et le dépannage, en particulier dans les environnements avec 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 et de transformation des données pour étiqueter leur origine. Exemples Duck Creek Claims | |||
Temps de traitement ProcessingTime | La durée du travail actif pour une activité spécifique, calculée en soustrayant l'heure de début de l'heure de fin. | ||
Description Le temps de traitement, également connu sous le nom de temps actif ou temps de manipulation, mesure le temps pendant lequel une ressource a travaillé activement sur une tâche spécifique. Il est calculé en soustrayant le StartTime du EndTime d'une activité. Cette métrique est une composante essentielle de l'analyse des performances. Elle aide à distinguer entre les inefficacités causées par des tâches longues (temps de traitement élevé) et les retards dus à l'attente de ressources ou d'informations (temps d'attente élevé). Ceci est crucial pour identifier la véritable source des goulots d'étranglement. Pourquoi c'est important Mesure le temps de travail actif pour une activité, aidant à distinguer entre les tâches inefficaces et les longs temps d'attente dans l'analyse des goulots d'étranglement. Où obtenir Ce n'est pas un champ du système source. Il est calculé lors de la préparation des données en soustrayant le 'StartTime' du 'EndTime' pour chaque activité. Exemples 360086400300 | |||
Activités de Gestion des Sinistres
| Activité | Description | ||
|---|---|---|---|
Décision sur le Sinistre Prise | Cette activité représente la décision officielle concernant le sinistre, telle que « Approved », « Partially Approved » ou « Denied ». Il s'agit d'un jalon essentiel déduit d'un changement de statut vers une décision finale. | ||
Pourquoi c'est important C'est une étape décisionnelle clé. Le temps qui précède ce moment et l'issue de la décision sont essentiels à l'analyse et à l'efficacité du processus. Où obtenir Déduit d'un changement dans un champ dédié 'Décision de sinistre' ou 'Statut de sinistre' vers un état terminal comme 'Approuvé' ou 'Refusé'. L'horodatage de ce changement est enregistré. Capture Déduit d'une mise à jour du statut principal ou du champ de décision du sinistre. Type d'événement inferred | |||
Paiement autorisé | Représente l'approbation formelle du montant d'indemnisation calculé à verser. Il s'agit souvent d'une étape distincte impliquant un responsable ou une autorité indépendante, enregistrée comme une transaction d'approbation explicite. | ||
Pourquoi c'est important C'est un point de contrôle crucial et un goulot d'étranglement potentiel avant le paiement. Le délai entre la 'Décision sur la réclamation prise' et ce point est mesuré par le KPI 'Temps moyen d'approbation des réclamations'. Où obtenir Il s'agit généralement d'un événement explicite dans un workflow ou un module financier où un utilisateur avec des permissions spécifiques approuve le paiement. On le trouverait dans un journal d'approbations. Capture Un événement d'approbation explicite enregistré dans un workflow ou un journal de transactions. Type d'événement explicit | |||
Paiement émis | Cette activité marque l'exécution de la transaction financière visant à régler le sinistre. Il s'agit d'un event clair et explicite, généré lorsque le paiement est envoyé par chèque, virement EFT ou d'autres méthodes. | ||
Pourquoi c'est important Cela signifie l'achèvement de l'obligation financière pour une réclamation approuvée. Le temps écoulé entre le 'Paiement autorisé' et le 'Paiement émis' révèle l'efficacité du service financier. Où obtenir Capturé à partir de la table des transactions financières dans Duck Creek Claims, qui enregistre tous les paiements sortants avec un code de transaction et un horodatage spécifiques. Capture Une entrée distincte est créée dans le journal des transactions financières lors du traitement d'un paiement. Type d'événement explicit | |||
Sinistre Clos | Il s'agit de l'activité finale, marquant la clôture administrative du dossier de réclamation après l'émission du paiement ou le règlement de la réclamation. Elle est enregistrée par la mise à jour finale du statut à 'Closed'. | ||
Pourquoi c'est important Cette activité marque la fin réussie du processus. C'est le point final pour le calcul du « Temps de cycle moyen de traitement de bout en bout d'un sinistre » et d'autres indicateurs clés de durée. Où obtenir Déduit de l'horodatage du changement de statut final vers 'Clôturé' ou 'Réglé' dans la table de données principale du sinistre. Capture Déduit du statut final du sinistre défini comme 'Clôturé'. Type d'événement inferred | |||
Sinistre Déclaré | C'est le premier événement, représentant la Première Déclaration de Sinistre (PDS) reçue par l'assureur. Il est généralement capturé comme une transaction explicite lorsqu'un agent ou un assuré saisit les informations initiales de la réclamation dans le système. | ||
Pourquoi c'est important Cette activité marque le début de tout le cycle de vie du sinistre. L'analyse du temps écoulé entre cet event et les autres est cruciale pour comprendre la durée totale de traitement et l'efficacité de la prise en charge. Où obtenir Il s'agit généralement d'un événement explicite enregistré dans une table de journal des réclamations ou des PDS lorsqu'un nouveau dossier de réclamation est créé pour la première fois dans Duck Creek Claims. Capture Événement enregistré lors de la création initiale d'un nouvel enregistrement de réclamation. Type d'événement explicit | |||
Sinistre Refusé | Cette activité représente une fin alternative du processus où le sinistre est officiellement rejeté. Elle est enregistrée lorsque le statut final du sinistre est défini sur « Denied » ou « Rejected ». | ||
Pourquoi c'est important C'est un résultat crucial qui nécessite une analyse distincte. Comprendre pourquoi et quand les sinistres sont rejetés aide à améliorer les processus de prise en charge et à gérer la conformité. Où obtenir Déduit de l'horodatage du changement de statut final du sinistre vers un statut 'Refusé', 'Rejeté' ou 'Clôturé sans paiement' dans la table d'entité des sinistres. Capture Déduit du statut final du sinistre indiquant un motif de refus. Type d'événement inferred | |||
Enquête initiée | Cette activité marque le début de la phase d'enquête formelle du sinistre. Elle est souvent déduite d'un changement de statut du sinistre vers « Under Investigation » ou un état similaire. | ||
Pourquoi c'est important Ceci marque le début d'une phase gourmande en ressources. Mesurer la durée de l'enquête est essentiel pour le KPI 'Durée moyenne de l'enquête' et aide à gérer une partie critique du processus. Où obtenir Déduit de l'horodatage d'une mise à jour du statut du sinistre vers 'Enquête en cours' ou 'Inspection en attente' dans le champ principal de statut du sinistre. Capture Dérivé d'un changement de statut de réclamation indiquant le début des activités d'enquête. Type d'événement inferred | |||
Enquête terminée | Représente la conclusion des activités d'enquête, une fois que tous les faits nécessaires ont été recueillis. Cela est généralement déduit lorsque le statut du sinistre passe de 'En enquête' à un statut de prise de décision, tel que 'Décision en attente'. | ||
Pourquoi c'est important L'achèvement de l'enquête est une étape cruciale qui débloque les phases de décision et de règlement. Les retards à ce stade ont un impact significatif sur les étapes suivantes. Où obtenir Déduit de l'horodatage d'une mise à jour du statut du sinistre, passant d'un état 'enquête' à un état 'examen' ou 'décision'. Capture Dérivé d'un changement de statut de réclamation indiquant la fin des activités d'enquête. Type d'événement inferred | |||
Examen initial terminé | Représente l'achèvement de la première révision complète du sinistre par l'expert en sinistres désigné. Cela est généralement déduit lorsque le statut du sinistre change après l'affectation, par exemple en passant de 'Affecté' à 'En cours d'examen' ou 'En enquête'. | ||
Pourquoi c'est important Ce jalon permet de mesurer le temps de première action d'un expert en sinistres et peut indiquer des retards potentiels dans sa charge de travail. C'est le premier point de contrôle majeur piloté par l'humain. Où obtenir Déduit d'un changement de statut dans le champ de statut du sinistre, par exemple, une transition vers 'Examen initial terminé' ou 'Informations en attente'. L'horodatage de ce changement de statut est utilisé. Capture Déduit d'un changement dans le champ de statut du sinistre après l'affectation de l'expert. Type d'événement inferred | |||
Expert désigné | Cet event capture l'assignation d'un gestionnaire ou d'un expert en sinistres au dossier enregistré. Le système enregistre cette assignation, créant un point de transfert clair et établissant la propriété pour le cycle de vie du sinistre. | ||
Pourquoi c'est important Crucial pour analyser l'allocation des ressources, la charge de travail des experts et identifier les retards dans l'attribution des réclamations. C'est un point de transfert clé qui peut introduire des temps d'attente. Où obtenir Suivi via une mise à jour du champ 'Assigned Adjuster' dans la table principale des données de réclamation. Un historique ou un journal d'audit pour ce champ fournit l'horodatage. Capture Enregistré dans un journal d'audit (audit trail) lorsque le champ de l'expert en sinistres est renseigné ou modifié. Type d'événement explicit | |||
Indemnisation calculée | Suite à une décision d'approbation, cette activité représente le calcul du montant final de l'indemnisation ou du paiement. Il peut s'agir d'une étape explicite ou être déduit de la finalisation des montants de paiement dans le module financier du système. | ||
Pourquoi c'est important Cette activité est cruciale pour mesurer le KPI de 'Taux de Reprise de l'Indemnisation'. De multiples occurrences de cet événement pour un même sinistre indiquent des inefficacités, des erreurs ou des négociations durant la phase d'indemnisation. Où obtenir Peut être une entrée explicite dans le journal de transactions ou déduit des mises à jour du champ 'Montant du Règlement' dans les données financières du sinistre. Les journaux d'audit sur ce champ constituent la source principale. Capture Événement enregistré lorsque le montant final du paiement est calculé et enregistré. Type d'événement explicit | |||
Informations supplémentaires demandées | Cette activité se produit lorsque le gestionnaire de sinistres détermine que des informations supplémentaires sont nécessaires et envoie une demande à l'assuré ou à une tierce partie. Il s'agit souvent d'un event explicite lié au module de communication ou de correspondance du système. | ||
Pourquoi c'est important Une fréquence élevée de cette activité peut indiquer des problèmes dans le processus initial de collecte de données. Elle entraîne également un temps d'attente significatif, impactant la durée totale du cycle. Où obtenir Capturé à partir des journaux de communications sortantes (ex. : lettres, e-mails) ou d'une transaction spécifique de 'Demande d'informations' dans Duck Creek Claims. Capture Enregistré lorsqu'une correspondance ou une tâche de demande d'informations est générée. Type d'événement explicit | |||
Informations supplémentaires reçues | Marque la réception des informations demandées, ce qui permet la poursuite du traitement de la réclamation. Cela peut être enregistré manuellement par l'expert en sinistres ou automatiquement si l'information est soumise via un portail numérique. | ||
Pourquoi c'est important Le temps entre 'Informations Demandées' et 'Informations Reçues' est une période d'attente critique. L'analyse de cette durée permet d'identifier les dépendances externes et les goulots d'étranglement de communication. Où obtenir Il peut s'agir d'un event explicite issu d'une intégration de système de gestion documentaire, ou d'une entrée de log manuelle ou d'un changement de statut effectué par le gestionnaire de sinistres à la réception des documents. Capture Événement enregistré lors du téléchargement d'un document ou de sa saisie manuelle par un expert en sinistres. Type d'événement explicit | |||
Perte évaluée | Ce jalon marque le moment où les réserves financières sont définies ou mises à jour en fonction des conclusions de l'enquête. Il signifie l'estimation de l'impact financier de la réclamation et est enregistré lorsque les montants de réserve sont saisis ou ajustés. | ||
Pourquoi c'est important C'est un point de contrôle financier crucial dans le processus. L'analyse du moment où cela se produit donne un aperçu de la rapidité de l'évaluation financière et de sa précision. Où obtenir Il s'agit souvent d'une transaction financière explicite enregistrée dans le journal des transactions financières de la réclamation ou dans la table d'historique des réserves au sein de Duck Creek Claims. Capture Transaction financière enregistrée pour la constitution ou la mise à jour des provisions de sinistres. Type d'événement explicit | |||
Sinistre Enregistré | Marque l'acceptation formelle et l'enregistrement de la réclamation soumise, moment auquel un ID de réclamation unique est officiellement attribué. Il s'agit souvent d'un événement système automatisé suivant une validation initiale des données. | ||
Pourquoi c'est important Formalise le début du sinistre et déclenche les processus en aval comme l'affectation de l'expert. Le temps écoulé entre la soumission et l'enregistrement peut indiquer des problèmes de qualité des données initiales ou de charge système. Où obtenir Déduit de l'horodatage de la génération de l'ID de sinistre principal et du passage du statut du sinistre de 'en attente' ou 'soumis' à 'ouvert' ou 'enregistré' dans la table d'entité principale du sinistre. Capture Dérivé de l'horodatage de création de l'enregistrement de réclamation principal ou d'un changement de statut vers 'Ouvert'. Type d'événement inferred | |||
Guides d'extraction
Étapes
- Accéder à l'utilitaire de configuration du Data Hub Duck Creek : Connectez-vous à l'environnement Duck Creek et naviguez vers l'application Data Hub. Vous aurez besoin des autorisations appropriées pour créer ou modifier des configurations d'exportation de données.
- Créer une nouvelle tâche d'exportation de données : Dans l'utilitaire Data Hub, lancez le processus de création d'une nouvelle tâche d'exportation. Donnez-lui un nom descriptif, tel que ProcessMind_Claims_Event_Log_Export.
- Définir la source de données : Configurez la tâche pour qu'elle se connecte à la base de données SQL principale du Data Hub. Vous devrez fournir le nom du serveur, le nom de la base de données et les informations d'identification pour un utilisateur disposant d'un accès en lecture aux schémas pertinents.
- Saisir la requête d'extraction : Accédez à la section de définition de la requête de la tâche d'exportation. Copiez le script complet de la section query ci-dessous et collez-le dans l'éditeur de requêtes.
- Définir les paramètres de la requête : Localisez la section des paramètres dans la configuration. Définissez les valeurs des paramètres @StartDate et @EndDate référencés dans la requête pour spécifier la plage de dates d'extraction souhaitée. Par exemple, '2023-01-01' et '2023-12-31'.
- Mapper les colonnes de sortie : Configurez les paramètres du fichier de sortie. Assurez-vous que les colonnes définies dans l'instruction SELECT (ClaimId, ActivityName, EventTime, etc.) sont correctement mappées aux colonnes du fichier de sortie. Les noms d'en-tête du fichier de sortie doivent correspondre exactement à ceux-ci.
- Configurer le fichier de sortie : Spécifiez le format de sortie comme CSV. Définissez la virgule (,) comme délimiteur et l'encodage des caractères en UTF-8 pour assurer la compatibilité avec ProcessMind.
- Définir la destination : Spécifiez le chemin du fichier ou l'emplacement réseau où le fichier CSV généré sera enregistré. Assurez-vous que le système dispose des autorisations d'écriture pour cet emplacement.
- Planifier la tâche d'exportation : Configurez le calendrier de la tâche. Pour une analyse initiale, vous pouvez l'exécuter manuellement. Pour une surveillance continue, configurez une planification récurrente (par exemple, quotidienne ou hebdomadaire).
- Exécuter et récupérer le fichier : Exécutez la tâche pour générer le fichier de log d'événements. Une fois terminée, récupérez le fichier CSV à partir de la destination spécifiée à l'étape 8.
- Préparer l'importation : Avant d'importer dans ProcessMind, ouvrez le fichier CSV pour effectuer une vérification finale. Vérifiez que les en-têtes sont corrects, que le format de date est cohérent (YYYY-MM-DD HH:MI:SS) et que les données sont conformes aux attentes.
Configuration
- Prérequis : L'accès au module Data Hub de Duck Creek est requis. L'utilisateur ou le compte de service exécutant la tâche d'exportation doit disposer de droits de lecture sur les tables de base de données sous-jacentes du Data Hub (par exemple, [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory]).
- Configuration de la plage de dates : La requête utilise les paramètres @StartDate et @EndDate. Il est essentiel de les définir pour délimiter la fenêtre d'extraction. Pour une première analyse, une période de 6 à 12 mois est recommandée afin de capter un nombre suffisant de cas terminés et en cours.
- Filtrage : La requête inclut un placeholder /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ au sein de la Common Table Expression (CTE). Décommentez et modifiez cette ligne pour filtrer des branches d'activité spécifiques (par exemple, 'Personal Auto', 'Commercial Property') afin de réduire le volume de données et cibler l'analyse.
- Cycle de rafraîchissement du Data Hub : Tenez compte de la latence des données du Data Hub. Les données ne sont pas en temps réel et sont généralement rafraîchies selon un calendrier (par exemple, chaque nuit). Les données extraites seront à jour au moment du dernier rafraîchissement réussi du Data Hub.
- Format de sortie : La tâche d'exportation doit être configurée pour produire un fichier plat, de préférence CSV. Assurez-vous que le délimiteur de texte est défini sur les guillemets doubles (") pour gérer les virgules éventuelles dans les champs de données.
a Exemple de requête config
`config
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL;
`