Votre modèle de données pour la gestion des sinistres
Votre modèle de données pour la gestion des sinistres
- Attributs recommandés à collecter
- Activités clés à suivre
- Conseils d’extraction pour Duck Creek Claims
Attributs de gestion des sinistres
| Nom | Description | ||
|---|---|---|---|
| Heure de l’événement EventTime | Horodatage indiquant le moment où une activité ou un événement précis s’est produit. | ||
| Description L’heure de l’événement indique la date et l’heure précises de chaque activité enregistrée au cours du traitement du sinistre. Ces informations temporelles sont essentielles à l’analyse des performances. Cet horodatage sert à calculer les temps de cycle entre les activités, à repérer les temps d’attente, à mesurer la durée totale de chaque dossier et à analyser les performances du processus sur différentes périodes. Il constitue la base de tout indicateur de processus lié au temps. Pourquoi est-ce important ? Cet horodatage est indispensable au calcul de tous les indicateurs temporels, notamment les temps de cycle et les durées. Il permet d’analyser les performances et de repérer les goulots d’étranglement. Où trouver ces données 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 tels que « CreateDate », « Timestamp » ou « EventDate ». Exemples 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| ID de sinistre ClaimId | Identifiant unique d’un sinistre, utilisé comme identifiant principal du dossier. | ||
| Description L’identifiant du sinistre est la clé principale qui relie tous les événements et activités associés à un même sinistre, de sa déclaration à sa clôture. Il permet de suivre l’ensemble du traitement de manière cohérente. Dans une analyse de Process Mining, cet attribut est essentiel pour construire la vue par dossier. Les analystes peuvent ainsi retracer le parcours complet de chaque sinistre, mesurer les temps de cycle de bout en bout et étudier les variantes du processus. Pourquoi est-ce important ? Il s’agit de l’ID de cas essentiel qui relie tous les événements associés au processus et permet de suivre l’ensemble du traitement du sinistre, de bout en bout. Où trouver ces données Il s’agit d’une clé primaire dans l’entité ou la table principale des sinistres de Duck Creek Claims. Consultez la documentation du système pour connaître le nom exact de la table et du champ. Exemples CL-2023-001234CL-2023-005678CL-2024-009101 | |||
| Nom de l’activité ActivityName | Nom de l’activité métier ou de l’événement survenu à un moment précis dans le traitement d’un sinistre. | ||
| Description Cet attribut décrit une étape ou une tâche précise du traitement d’un sinistre, comme « Sinistre déclaré », « Gestionnaire de sinistre affecté » ou « Paiement effectué ». Chaque activité correspond à un moment distinct du traitement. L’analyse de l’ordre et de la fréquence de ces activités est au cœur du Process Mining. Elle permet de découvrir des modèles de processus, de repérer les goulots d’étranglement et les boucles de reprise, et d’analyser les écarts par rapport à un modèle standard. Pourquoi est-ce important ? Le nom de l’activité définit les étapes du flux du processus. Il est indispensable pour découvrir, analyser et suivre le traitement des sinistres. Où trouver ces données Généralement extrait des journaux d’événements, des noms de transactions ou des enregistrements de changement de statut dans Duck Creek Claims. Il peut être nécessaire d’associer des champs ou des tables provenant de plusieurs sources. Exemples Sinistre déclaréGestionnaire de sinistre affectéEnquête commencéePaiement effectuéSinistre clôturé | |||
| Gestionnaire affecté AssignedAdjuster | Nom ou identifiant du gestionnaire chargé du sinistre au moment d’une activité donnée. | ||
| Description Cet attribut identifie l’utilisateur ou la ressource qui réalise une activité. Il peut changer au cours du traitement du sinistre, lorsque le dossier est transféré entre différents gestionnaires ou équipes. Il est essentiel pour analyser la performance des ressources, la répartition de la charge de travail et les transferts de dossiers. Les Dashboards consacrés au volume de dossiers traités par gestionnaire, aux écarts de charge et aux goulots d’étranglement s’appuient souvent sur cet attribut pour comprendre comment le travail est réparti et effectué. Pourquoi est-ce important ? Cet attribut permet d’analyser la performance des ressources, l’équilibre de la charge de travail et les modes de collaboration. Il aide à repérer les goulots d’étranglement et les besoins de formation. Où trouver ces données Consultez la documentation de Duck Creek Claims. Recherchez les champs d’utilisateur, de responsable ou d’affectataire dans les tables liées aux tâches et aux événements du sinistre, ou à l’entité principale du sinistre. Exemples John SmithJane DoeRobert Brownadjuster_1138 | |||
| Gravité du sinistre ClaimSeverity | Classification de la complexité financière ou opérationnelle du sinistre, par exemple faible, moyenne ou élevée. | ||
| Description La gravité du sinistre donne une indication de son impact ou de sa complexité prévisible. Elle peut être déterminée à partir de l’estimation initiale des dommages, de la nature de l’incident ou d’autres règles métier prédéfinies. Cet attribut est essentiel à l’analyse des performances : les sinistres graves nécessitent généralement davantage d’étapes, des délais de traitement plus longs et des ressources spécialisées. La segmentation des indicateurs selon la gravité aide à fixer des objectifs réalistes et à comprendre l’incidence de la complexité sur l’efficacité et les résultats du processus. Pourquoi est-ce important ? Cet attribut permet de segmenter les sinistres selon leur complexité, pour analyser les performances plus finement et comparer de manière réaliste les temps de cycle et les coûts. Où trouver ces données Consultez la documentation de Duck Creek Claims. Il peut s’agir d’un champ dédié ou d’une valeur calculée à partir du montant initial de la provision pour sinistre. Exemples FaibleMoyenÉlevéCatastrophique | |||
| Montant du préjudice LossAmount | Montant financier estimé ou réel du préjudice déclaré au titre du sinistre. | ||
| Description Cet attribut correspond à l’estimation initiale du préjudice associé au sinistre. Il s’agit d’une métrique financière importante, qui influe souvent sur l’orientation du dossier, sa gravité et le niveau d’investigation requis. L’analyse du montant du préjudice permet de segmenter les sinistres et d’étudier le lien entre leur impact financier et le déroulement du processus. Par exemple, les sinistres de montant élevé peuvent suivre des parcours différents ou présenter des temps de cycle plus longs. Cet attribut apporte un contexte financier essentiel aux données opérationnelles du processus. Pourquoi est-ce important ? Apporte un contexte financier au sinistre et permet d’analyser l’incidence de son montant sur son parcours de traitement, sa durée et son issue. Où trouver ces données Consultez la documentation Duck Creek Claims. Ce champ financier central de la fiche du sinistre est souvent appelé « Reported Loss » ou « Initial Reserve ». Exemples 1500.0025000.50125000.00 | |||
| Service Department | Service ou équipe responsable de l’activité ou du sinistre à un moment donné. | ||
| Description Cet attribut indique le groupe fonctionnel ou le service chargé du sinistre, par exemple « Collecte initiale », « Unité d’enquête » ou « Équipe de règlement ». Il situe le flux du processus dans l’organisation. L’analyse par service est essentielle pour comprendre les performances à l’échelle de l’organisation. Elle aide à repérer les goulots d’étranglement entre services, à mesurer l’efficacité des équipes et à comprendre la circulation du travail dans l’organisation. Pourquoi est-ce important ? Cet attribut permet d’analyser les performances par domaine fonctionnel et de repérer les transferts entre services ainsi que les goulots d’étranglement propres à chaque équipe. Où trouver ces données Consultez la documentation de Duck Creek Claims. Cette information est souvent associée au profil de l’utilisateur affecté ou à l’affectation à une file d’attente ou à un groupe de travail. Exemples Sinistres automobilesSinistres immobiliers, dommages importantsUnité des enquêtes spécialesTraitement des paiements | |||
| Statut du sinistre ClaimStatus | Statut général du sinistre à un moment donné, par exemple ouvert, en attente ou clôturé. | ||
| Description Le statut du sinistre indique où celui-ci en est dans son cycle de vie. Il donne une vue d’ensemble de son avancement dans le processus. Cet attribut permet de créer des vues synthétiques du stock de sinistres et de filtrer les dossiers. Il est particulièrement utile pour repérer l’issue finale d’un sinistre, par exemple « Clôturé, indemnisation versée » ou « Clôturé, refusé », ce qui est essentiel pour analyser les résultats et comprendre les taux de rejet. Pourquoi est-ce important ? Donne un aperçu de l’état actuel et de l’issue finale du sinistre, utile pour analyser les résultats et filtrer les dossiers. Où trouver ces données Consultez la documentation Duck Creek Claims. Il s’agit d’un champ fondamental de la fiche principale du sinistre. Exemples OuvertEn attente d’informationsClôturé, régléClôturé, refusé | |||
| Type de sinistre ClaimType | Catégorie du sinistre, par exemple automobile, immobilier ou responsabilité civile. | ||
| Description Le type de sinistre classe les dossiers selon la branche d’activité ou la nature du dommage. Il s’agit d’une dimension fondamentale pour segmenter et analyser les données de sinistres. Cet attribut permet de comparer les performances du processus selon le type de sinistre. Par exemple, un sinistre automobile avec perte totale suit un processus très différent d’un dégât des eaux dans un bien immobilier, et les indicateurs associés ne sont pas les mêmes. L’analyse par type de sinistre apporte du contexte, permet des comparaisons plus pertinentes et aide à adapter les initiatives d’amélioration des processus. Pourquoi est-ce important ? Cette dimension est essentielle pour segmenter les analyses, car les types de sinistres peuvent correspondre à des processus, des accords de niveau de service et des niveaux de complexité différents. Où trouver ces données Consultez la documentation de Duck Creek Claims. Il s’agit d’un attribut essentiel de l’enregistrement principal du sinistre. Exemples Automobile personnelle, collisionBien immobilier commercial, incendieAccidents du travailResponsabilité civile générale | |||
| Automatisé IsAutomated | Indicateur booléen précisant si l’activité a été exécutée automatiquement par le système, sans intervention humaine. | ||
| Description Cet indicateur distingue les tâches effectuées par des utilisateurs de celles prises en charge automatiquement par le système, comme l’envoi de notifications, la validation initiale des données ou les étapes de traitement de bout en bout sans intervention manuelle. L’analyse de cet attribut est essentielle pour comprendre le degré d’automatisation du processus de gestion des sinistres. Elle permet de mesurer les effets des initiatives d’automatisation, de repérer d’autres possibilités d’automatisation et de vérifier que les étapes automatisées fonctionnent comme prévu sans entraîner de problèmes en aval. Pourquoi est-ce important ? Permet de mesurer les effets de l’automatisation sur l’efficacité et les coûts, et de repérer les possibilités de traitement de bout en bout sans intervention manuelle. Où trouver ces données Cette information peut être déduite de l’utilisateur associé à un événement, par exemple « SYSTEM » ou « BATCH », ou provenir d’un indicateur spécifique de l’enregistrement de l’événement. Exemples truefalse | |||
| Date cible de résolution ResolutionTargetDate | Date à laquelle le sinistre devrait être résolu, selon les accords de niveau de service (SLA) ou les objectifs internes. | ||
| Description Cet attribut indique la date limite de clôture du sinistre. Elle 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. Elle peut varier selon le type ou la gravité du sinistre. Cette date sert à calculer le KPI « Taux de résolution des sinistres dans les délais » et alimente le Dashboard « Respect des délais cibles de résolution des sinistres ». Elle permet de surveiller les sinistres susceptibles de dépasser leur SLA et de prioriser le travail. Pourquoi est-ce important ? Permet de mesurer les résultats au regard des accords de niveau de service (SLA) et des objectifs internes, qui ont une incidence directe sur la satisfaction client et la conformité. Où trouver ces données Consultez la documentation Duck Creek Claims. Il peut s’agir d’un champ de date SLA dédié ou d’une date calculée à partir de la date de déclaration du sinistre 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 | Horodatage de la dernière actualisation des données depuis le système source. | ||
| Description Cet attribut indique la date de la dernière mise à jour du jeu de données. Il permet de savoir à quel point les données analysées sont récentes. Dans les Dashboards et les analyses, il informe les utilisateurs de la date des dernières données disponibles. Ils peuvent ainsi savoir si les transactions les plus récentes figurent dans la vue du processus. Pourquoi est-ce important ? Cet attribut renseigne les utilisateurs sur la fraîcheur des données, un élément important pour interpréter les analyses et prendre des décisions au bon moment. Où trouver ces données Cet horodatage est généré lors du processus d’extraction, de transformation et de chargement des données (ETL). Il est généralement stocké dans les métadonnées du jeu de données. Exemples 2024-05-21T02:00:00Z | |||
| Heure de fin EndTime | Horodatage indiquant la fin d’une activité. | ||
| Description Cet attribut indique l’heure à laquelle une activité s’est achevée. StartTime indique le début de l’activité, tandis que EndTime fournit l’autre borne nécessaire au calcul de sa durée. En Process Mining, disposer des heures de début et de fin des activités permet d’analyser les performances avec précision. On peut ainsi calculer la « Durée de traitement », c’est-à-dire le temps de travail effectif consacré à une tâche, et la distinguer du « Temps d’attente » entre deux tâches. Cette distinction est essentielle pour repérer correctement les goulots d’étranglement. Pourquoi est-ce important ? Permet de calculer précisément la durée de traitement des activités et de distinguer le temps de travail effectif du temps d’inactivité ou d’attente, une distinction essentielle pour repérer les goulots d’étranglement. Où trouver ces données Peut figurer dans un champ d’horodatage distinct du journal d’événements ou être déduit du StartTime de l’activité suivante dans la séquence du même dossier. Exemples 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
| Montant de l’indemnisation SettlementAmount | Montant final convenu pour régler le sinistre. | ||
| Description Cet attribut enregistre le montant de l’indemnisation calculé et autorisé au paiement. Il s’agit d’une métrique importante pour mesurer l’issue de chaque sinistre donnant lieu à un paiement. Cet attribut est essentiel à l’analyse financière et à des Dashboards tels que « Délai d’autorisation et d’émission du paiement ». La comparaison avec le montant initial du préjudice permet d’évaluer la précision des provisions. Il est également indispensable pour comprendre les résultats financiers du processus de gestion des sinistres. Pourquoi est-ce important ? Représente le principal résultat financier d’un sinistre. Cet attribut est essentiel aux rapports financiers et à l’analyse de la précision des estimations initiales du préjudice. Où trouver ces données Consultez la documentation Duck Creek Claims. Ces informations sont généralement stockées dans les tables des transactions financières ou des paiements associées au sinistre. Exemples 1450.7522000.00115800.20 | |||
| Motif du rejet RejectionReason | Motif précis pour lequel un sinistre a été refusé ou rejeté. | ||
| Description Lorsqu’une décision de refus est prise, cet attribut en indique le motif. Celui-ci est généralement choisi dans une liste prédéfinie de codes ou de descriptions. L’analyse des motifs de rejet est essentielle au Dashboard « Analyse des décisions et des rejets de sinistres ». Elle permet de repérer les problèmes récurrents dans les déclarations, les éventuels schémas de fraude ou les clauses de police qui manquent de clarté. Ces constats peuvent guider l’amélioration du processus de déclaration ou des règles de souscription. Pourquoi est-ce important ? Explique les motifs de refus des sinistres et fournit des pistes concrètes pour améliorer leur déclaration, réduire les dossiers non valides et repérer les besoins de formation. Où trouver ces données Consultez la documentation Duck Creek Claims. Ce champ est généralement renseigné lorsque le statut du sinistre passe à « Refusé » ou à un état similaire. Exemples Événement non couvertPolice expiréeSinistre en doubleFraude présumée | |||
| Numéro de police PolicyNumber | Identifiant unique de la police d’assurance au titre de laquelle le sinistre a été déclaré. | ||
| Description Cet attribut relie le sinistre à la police d’assurance correspondante. Il apporte des informations sur la couverture, les conditions et le client associés au sinistre. Même s’il n’est pas toujours utilisé directement pour analyser le flux du processus, le numéro de police enrichit considérablement les données sur les sinistres. Il permet de les rapprocher des données sur les polices et les clients afin d’étudier les variations de performance selon le segment de clientèle, le type de police ou son ancienneté, et d’obtenir une vision plus complète de l’activité. Pourquoi est-ce important ? Relie le sinistre au client et à sa police, ce qui permet d’analyser plus largement les effets de la performance du processus selon les segments de clientèle et les types de police. Où trouver ces données Consultez la documentation Duck Creek Claims. Il s’agit d’un champ de référence standard de l’entité principale du sinistre. Exemples PA-987654321CP-123456789WC-555444333 | |||
| Reprise IsRework | Indicateur calculé précisant si une activité fait partie d’une boucle de reprise. | ||
| Description Cet attribut booléen prend la valeur true lorsqu’une activité est répétée pour un sinistre après l’exécution d’autres activités. Par exemple, lorsque le processus revient de « Préjudice évalué » à « Enquête commencée ». Cet attribut est essentiel pour quantifier et analyser les reprises. Il alimente le KPI « Taux de reprise des sinistres » et le Dashboard « Reprises et retraitements des sinistres », qui permettent de filtrer et de mettre en évidence les activités et les dossiers concernés. Ces analyses aident à repérer les inefficacités et les problèmes de qualité du processus. Pourquoi est-ce important ? Quantifie les reprises au niveau des activités et facilite la mesure, la visualisation et l’analyse des causes et des effets des inefficacités du processus. Où trouver ces données Ce champ ne provient pas 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 dans un dossier. Exemples truefalse | |||
| Résolution dans les délais IsOnTimeResolution | Indicateur calculé précisant si le sinistre a été clôturé au plus tard à la date cible de résolution. | ||
| Description Cet attribut booléen est calculé en comparant l’horodatage de l’activité « Sinistre clôturé » à la ResolutionTargetDate du sinistre. Il indique si chaque sinistre a été résolu dans les délais (true) ou en retard (false). Cet attribut alimente directement le KPI « Taux de résolution des sinistres dans les délais ». Il facilite l’agrégation et la visualisation du respect des SLA dans les Dashboards, et permet d’examiner les dossiers en détail pour repérer les caractéristiques communes des sinistres en retard, comme certains types de sinistres, services ou parcours. Pourquoi est-ce important ? Mesure directement le respect des SLA pour chaque sinistre et permet de filtrer les dossiers en retard et d’en analyser les causes profondes. Où trouver ces données Ce champ ne provient pas du système source. Il est calculé lors de la préparation des données en comparant l’horodatage de la dernière activité au champ ResolutionTargetDate. Exemples truefalse | |||
| Système source SourceSystem | Système dont proviennent les données d’événements extraites. | ||
| Description Cet attribut identifie l’application source d’où proviennent les données du sinistre. Dans ce contexte, sa valeur sera toujours « Duck Creek Claims ». Même si cet attribut peut sembler redondant lorsque toutes les données proviennent d’un seul système, il est essentiel à la gouvernance des données et à leur traçabilité, notamment si des données issues d’autres systèmes sont intégrées par la suite. Il précise l’origine et la structure des données. Pourquoi est-ce important ? Cet attribut fournit des informations essentielles sur la provenance des données et leur contexte. Il est important pour la gouvernance des données et le diagnostic des problèmes, en particulier dans les environnements où plusieurs systèmes sont intégrés. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données pour en indiquer la provenance. Exemples Duck Creek Claims | |||
Activités de gestion des sinistres
| Activité | Description | ||
|---|---|---|---|
| Décision concernant le sinistre prise | Cette activité correspond à la décision officielle concernant le sinistre, par exemple « Approved », « Partially Approved » ou « Denied ». Cette étape déterminante est déduite du passage à un statut de décision définitif. | ||
| Pourquoi est-ce important ? Cette étape importante de prise de décision est au cœur de l’analyse du processus et de son efficacité. Le délai pour y parvenir et l’issue de la décision sont tous deux déterminants. Où trouver ces données Déduit du passage d’un champ dédié « Claim Decision » ou « Claim Status » à un état final tel que « Approved » ou « Denied ». L’horodatage de ce changement est enregistré. Données à recueillir Déduit de la mise à jour du statut principal ou du champ de décision du sinistre. Type d’événement inferred | |||
| Paiement autorisé | Cet événement correspond à l’autorisation officielle de verser le montant calculé pour le règlement. Il s’agit souvent d’une étape distincte, prise en charge par un responsable ou une autre autorité, et enregistrée comme une transaction d’approbation explicite. | ||
| Pourquoi est-ce important ? Il s’agit d’un point de contrôle important et d’un goulot d’étranglement potentiel avant le paiement. L’indicateur « Délai moyen d’approbation des sinistres » mesure le temps écoulé entre « Claim Decision Made » et cette étape. Où trouver ces données Il s’agit généralement d’un événement explicite dans un flux de travail ou un module financier, au cours duquel un utilisateur disposant des autorisations requises approuve le paiement. L’événement figure dans un journal des approbations. Données à recueillir Événement d’approbation explicite enregistré dans un flux de travail ou un journal des transactions. Type d’événement explicit | |||
| Paiement effectué | Cette activité marque l’exécution de la transaction financière destinée à régler le sinistre. Il s’agit d’un événement explicite, généré lorsque le paiement est envoyé par chèque, par transfert électronique de fonds ou par un autre moyen. | ||
| Pourquoi est-ce important ? Cet événement marque l’exécution de l’obligation financière liée à un sinistre approuvé. Le délai entre « Payment Authorized » et « Payment Issued » permet d’évaluer l’efficacité du service financier. Où trouver ces données Événement extrait de la table des transactions financières de Duck Creek Claims, qui consigne tous les paiements sortants avec un code de transaction et un horodatage spécifiques. Données à recueillir Une entrée distincte est créée dans le journal des transactions financières lorsque le paiement est traité. Type d’événement explicit | |||
| Sinistre clôturé | Il s’agit de la dernière activité : la clôture administrative du dossier après l’émission du paiement ou le règlement du sinistre. Elle est enregistrée lors du passage final du statut à « Closed ». | ||
| Pourquoi est-ce important ? Cette activité marque la fin du processus. Elle sert de point final pour calculer le « Temps de cycle moyen de bout en bout d’un sinistre » et d’autres indicateurs de durée importants. Où trouver ces données Déduit de l’horodatage du passage final du statut à « Closed » ou « Settled » dans la table principale des données du sinistre. Données à recueillir Déduit du statut final du sinistre, défini sur « Closed ». Type d’événement inferred | |||
| Sinistre déclaré | Il s’agit du premier événement : l’assureur reçoit la déclaration initiale de sinistre (FNOL). Il est généralement enregistré comme une transaction explicite lorsqu’un agent ou un assuré saisit les premières informations sur le sinistre dans le système. | ||
| Pourquoi est-ce important ? Cette activité marque le début du traitement du sinistre. L’analyse du temps écoulé entre cet événement et les suivants permet de comprendre la durée totale du traitement et l’efficacité de la collecte initiale. Où trouver ces données Il s’agit généralement d’un événement explicite enregistré dans une table de journal des sinistres ou des FNOL, au moment de la création d’un nouveau dossier dans Duck Creek Claims. Données à recueillir Événement enregistré lors de la création initiale d’un nouveau dossier de sinistre. Type d’événement explicit | |||
| Sinistre refusé | Cette activité marque une autre issue possible du processus : le refus officiel du sinistre. Elle est enregistrée lorsque le statut final du sinistre passe à « Denied » ou « Rejected ». | ||
| Pourquoi est-ce important ? Cette issue doit faire l’objet d’une analyse distincte. Comprendre pourquoi et à quel moment les sinistres sont refusés aide à améliorer la collecte initiale des informations et à gérer la conformité. Où trouver ces données Déduit de l’horodatage du passage du statut final du sinistre à « Denied », « Rejected » ou « Closed without Payment » dans la table des sinistres. Données à recueillir Déduit du statut final du sinistre, qui indique un refus. Type d’événement inferred | |||
| Enquête commencée | Cette activité marque le début de la phase d’enquête officielle sur le sinistre. Elle est souvent déduite du passage du statut du sinistre à « Under Investigation » ou à un statut équivalent. | ||
| Pourquoi est-ce important ? Cette étape ouvre une phase qui mobilise beaucoup de ressources. Mesurer la durée de l’enquête est essentiel pour suivre l’indicateur « Durée moyenne de l’enquête » et gérer cette partie importante du processus. Où trouver ces données Déduit de l’horodatage de la mise à jour du statut du sinistre à « Investigation in Progress » ou « Pending Inspection » dans le champ de statut principal. Données à recueillir Déduit d’un changement de statut du sinistre indiquant le début des activités d’enquête. Type d’événement inferred | |||
| Enquête terminée | Cet événement marque la fin des activités d’enquête, une fois tous les faits nécessaires réunis. Il est généralement déduit du passage du statut du sinistre de « Under Investigation » à un statut de décision, comme « Pending Decision ». | ||
| Pourquoi est-ce important ? La fin de l’enquête permet d’engager la prise de décision et le règlement du sinistre. Tout retard à cette étape a des répercussions importantes sur les étapes suivantes. Où trouver ces données Déduit de l’horodatage du passage du statut du sinistre d’un état « investigation » à un état « review » ou « decision ». Données à recueillir Déduit d’un changement de statut du sinistre indiquant la fin des activités d’enquête. Type d’événement inferred | |||
| Examen initial terminé | Cet événement correspond à la fin du premier examen complet du sinistre par le gestionnaire qui lui a été affecté. Il est généralement déduit d’un changement de statut après l’affectation, par exemple de « Assigned » à « Under Review » ou « Investigation ». | ||
| Pourquoi est-ce important ? Cette étape permet de mesurer le délai avant la première intervention du gestionnaire et peut révéler une accumulation de dossiers. Il s’agit du premier point de contrôle important nécessitant une intervention humaine. Où trouver ces données Déduit d’un changement du champ de statut du sinistre, par exemple le passage à « Initial Review Complete » ou « Pending Information ». L’horodatage de ce changement est utilisé. Données à recueillir Déduit d’un changement du statut du sinistre après l’affectation d’un gestionnaire. Type d’événement inferred | |||
| Gestionnaire de sinistre affecté | Cet événement correspond à l’affectation d’un gestionnaire ou d’un expert au sinistre enregistré. Le système consigne cette affectation, qui marque clairement le transfert du dossier et désigne la personne responsable de son suivi. | ||
| Pourquoi est-ce important ? Cet événement est important pour analyser la répartition des ressources et la charge de travail des gestionnaires, ainsi que pour repérer les retards d’affectation. Ce transfert de responsabilité peut entraîner un temps d’attente. Où trouver ces données L’événement est suivi au moyen d’une mise à jour du champ « Assigned Adjuster » dans la table principale des données de sinistre. L’horodatage figure dans l’historique ou le journal d’audit de ce champ. Données à recueillir Consigné dans un journal d’audit lorsque le champ du gestionnaire est renseigné ou modifié. Type d’événement explicit | |||
| Informations complémentaires demandées | Cette activité a lieu lorsque le gestionnaire estime qu’il lui faut des informations supplémentaires et en fait la demande à l’assuré ou à un tiers. Elle correspond souvent à un événement explicite lié au module de communication ou de correspondance du système. | ||
| Pourquoi est-ce important ? Une fréquence élevée de cette activité peut révéler des lacunes dans la collecte initiale des données. Elle entraîne aussi un temps d’attente important, qui allonge le temps de cycle global. Où trouver ces données Événement extrait des journaux de communications sortantes, par exemple des lettres ou des courriels, ou d’une transaction « Request for Information » dans Duck Creek Claims. Données à recueillir Enregistré lors de la création d’une correspondance ou d’une tâche de demande d’informations. Type d’événement explicit | |||
| Informations complémentaires reçues | Cet événement marque la réception des informations demandées et permet de poursuivre le traitement du sinistre. Le gestionnaire peut le consigner manuellement, ou le système peut l’enregistrer automatiquement si les informations sont transmises via un portail numérique. | ||
| Pourquoi est-ce important ? Le délai entre « Information Requested » et « Information Received » correspond à une période d’attente importante. Son analyse permet de repérer les dépendances externes et les goulots d’étranglement dans les échanges. Où trouver ces données Il peut s’agir d’un événement explicite issu de l’intégration avec un système de gestion documentaire, d’une saisie manuelle dans le journal ou d’un changement de statut effectué par le gestionnaire à la réception des documents. Données à recueillir Événement enregistré lors de l’importation d’un document ou de sa saisie manuelle par un gestionnaire. Type d’événement explicit | |||
| Montant du règlement calculé | Après l’approbation du sinistre, cette activité correspond au calcul du montant définitif du règlement ou du paiement. Elle peut constituer une étape explicite ou être déduite de la validation des montants dans le module financier du système. | ||
| Pourquoi est-ce important ? Cette activité est importante pour mesurer l’indicateur « Taux de reprise du règlement ». Si elle se produit plusieurs fois pour un même sinistre, cela peut signaler des inefficacités, des erreurs ou des négociations lors du règlement. Où trouver ces données L’événement peut correspondre à une entrée explicite dans le journal des transactions ou être déduit des mises à jour du champ « Settlement Amount » dans les données financières du sinistre. Les journaux d’audit de ce champ constituent la principale source. Données à recueillir Événement enregistré lorsque le montant définitif du paiement est calculé et enregistré. Type d’événement explicit | |||
| Montant du sinistre évalué | Cette étape marque la définition ou la mise à jour des provisions financières à partir des conclusions de l’enquête. Elle correspond à l’estimation de l’impact financier du sinistre et est enregistrée lorsque les montants des provisions sont saisis ou modifiés. | ||
| Pourquoi est-ce important ? Il s’agit d’un point de contrôle financier important. Analyser le moment où il intervient permet d’évaluer la rapidité et la précision de l’estimation financière. Où trouver ces données Il s’agit souvent d’une transaction financière explicite enregistrée dans le journal des transactions financières du sinistre ou dans la table d’historique des provisions de Duck Creek Claims. Données à recueillir Transaction financière enregistrée lors de la définition ou de la mise à jour des provisions du sinistre. Type d’événement explicit | |||
| Sinistre enregistré | Cet événement marque l’acceptation officielle et l’enregistrement du sinistre. Un identifiant de sinistre unique lui est alors attribué. Il s’agit souvent d’un événement automatique du système, déclenché après la validation initiale des données. | ||
| Pourquoi est-ce important ? Il officialise l’ouverture du sinistre et déclenche les étapes suivantes, comme l’affectation à un gestionnaire. Le délai entre la déclaration et l’enregistrement peut révéler des problèmes de qualité des données initiales ou de charge du système. Où trouver ces données Cet événement est déduit de l’horodatage de création de l’identifiant principal du sinistre et du passage de son statut de « en attente » ou « déclaré » à « ouvert » ou « enregistré » dans la table principale des sinistres. Données à recueillir Déduit de l’horodatage de création du dossier principal du sinistre ou du passage de son statut à « Ouvert ». Type d’événement inferred | |||
Guides d’extraction
Étapes
- Accédez à l’utilitaire de configuration Duck Creek Data Hub : Connectez-vous à l’environnement Duck Creek, puis ouvrez l’application Data Hub. Vous devez disposer des autorisations nécessaires pour créer ou modifier des configurations d’exportation de données.
- Créez une tâche d’exportation : Dans l’utilitaire Data Hub, lancez la création d’une nouvelle tâche d’exportation. Donnez-lui un nom explicite, par exemple ProcessMind_Claims_Event_Log_Export.
- Définissez la source de données : Configurez la tâche pour qu’elle se connecte à la base de données SQL principale de Data Hub. Indiquez le nom du serveur, celui de la base de données et les identifiants d’un utilisateur disposant d’un accès en lecture aux schémas concernés.
- Saisissez la requête d’extraction : Ouvrez la section de définition des requêtes de la tâche d’exportation. Copiez le script complet figurant dans la section de requête ci-dessous et collez-le dans l’éditeur.
- Définissez les paramètres de la requête : Repérez la section des paramètres dans la configuration. Définissez les valeurs des paramètres @StartDate et @EndDate utilisés dans la requête afin de préciser la période d’extraction souhaitée. Par exemple, '2023-01-01' et '2023-12-31'.
- Associez les colonnes de sortie : Configurez les paramètres du fichier de sortie. Vérifiez que les colonnes définies dans l’instruction SELECT (ClaimId, ActivityName, EventTime, etc.) sont correctement associées aux colonnes du fichier. Les noms d’en-tête du fichier doivent correspondre exactement à ces noms.
- Configurez le fichier de sortie : Choisissez le format CSV. Définissez la virgule (,) comme séparateur et UTF-8 comme encodage afin d’assurer la compatibilité avec ProcessMind.
- Définissez la destination : Indiquez le chemin d’accès ou l’emplacement réseau où le fichier CSV généré sera enregistré. Vérifiez que le système dispose des droits d’écriture nécessaires à cet emplacement.
- Planifiez la tâche d’exportation : Configurez son calendrier. Pour une première analyse, vous pouvez l’exécuter manuellement. Pour un suivi régulier, prévoyez une exécution récurrente, par exemple quotidienne ou hebdomadaire.
- Exécutez la tâche et récupérez le fichier : Lancez la tâche pour générer le journal d’événements. Une fois l’exécution terminée, récupérez le fichier CSV à l’emplacement indiqué à l’étape 8.
- Préparez l’importation : Avant d’importer le fichier dans ProcessMind, ouvrez-le pour effectuer une dernière vérification. Assurez-vous 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 : Vous devez avoir accès au module Duck Creek Data Hub. L’utilisateur ou le compte de service qui exécute la tâche d’exportation doit disposer d’un accès en lecture aux tables sous-jacentes de la base de données Data Hub, par exemple [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim] et [DataHubSchema].[DimStatusHistory].
- Configuration de la période : La requête utilise les paramètres @StartDate et @EndDate. Il est essentiel de les définir pour préciser la période d’extraction. Pour une première analyse, une période de 6 à 12 mois est recommandée afin de couvrir suffisamment de cas terminés et en cours.
- Filtres : La requête contient l’espace réservé /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ dans l’expression de table commune (CTE). Supprimez les marqueurs de commentaire et modifiez cette ligne pour filtrer certaines branches d’activité, par exemple 'Personal Auto' ou 'Commercial Property', réduire le volume de données et cibler l’analyse.
- Cycle d’actualisation de Data Hub : Tenez compte du délai d’actualisation des données de Data Hub. Les données ne sont pas disponibles en temps réel et sont généralement actualisées selon un calendrier, par exemple chaque nuit. L’extraction reflétera les données de la dernière actualisation réussie de Data Hub.
- Format de sortie : Configurez la tâche d’exportation pour produire un fichier plat, de préférence au format CSV. Définissez le guillemet double (") comme caractère de délimitation du texte afin de gérer les virgules présentes dans les champs.
Exemple de requête sql
-- 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;Prêt à commencer ?
Ce modèle contient tout ce dont vous avez besoin pour commencer à optimiser la gestion de vos sinistres. Lancez-vous dès aujourd’hui dans l’analyse de vos données et découvrez des pistes d’amélioration.
Résorbez les retards dans le traitement des sinistres : optimisez votre processus dès maintenant
Atteignez 70 % de traitement sans intervention, pour réduire les coûts et les délais.
Essai gratuit de 14 jours, sans carte bancaire.