Votre modèle de données d'intégration client KYC
Votre modèle de données d'intégration client KYC
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide pour l'extraction de données
Attributs d'intégration client KYC
| Nom | Descriptionn | ||
|---|---|---|---|
| Demande client CustomerApplication | L'identifiant unique pour le parcours d'intégration d'un seul client, servant d'identifiant principal du dossier. | ||
| Descriptionn La Demande Client est l'identifiant central qui regroupe toutes les activités et En Pourquoi est-ce important ? : C'est l'ID de Dossier essentiel qui relie tous les Source des données : Ceci est généralement la clé primaire dans l'entité principale de gestion des dossiers ou de gestion du cycle de vie client de Fenergo. Exemples APP-2023-00123APP-2023-00124APP-2023-00125 | |||
| Heure de début EventStartTime | L'horodatage indiquant le début officiel d'une activité ou d'un événement. | ||
| Descriptionn Cet En Pourquoi est-ce important ? : Cet horodatage est indispensable pour ordonner les Source des données : Situé dans la piste d'audit de Fenergo, le journal d'événements ou les tables d'historique de workflow, souvent étiqueté comme 'Horodatage', 'StartDate' ou 'CreationDate'. Exemples 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| Nom de l'activité ActivityName | Le nom de l'événement commercial ou de la tâche spécifique qui s'est produit à un moment donné du processus d'intégration. | ||
| Descriptionn Le nom de l'activité décrit une étape unique ou un jalon dans le parcours d'intégration client, tel que 'Filtrage Initial Effectué' ou 'Demande Approuvée'. Cette séquence d'activités sert de base à la cartographie des processus. L'analyse de cet Pourquoi est-ce important ? : Cet Source des données : Ces informationsns se trouvent généralement dans les tables de Exemples Données et documents demandésExamen de conformité initiéDemande Approuvée | |||
| Dernière mise à jour des données LastDataUpdate | L'horodatage de la dernière actualisation ou extraction des données de ce processus. | ||
| Descriptionn Cet Dans les Pourquoi est-ce important ? : Fournit un contexte essentiel sur la la réactualisation des données, garantissant que les utilisateurs comprennent à quel point l'analyse des processus est actuelle. Source des données : Cette valeur est générée et estampillée sur le jeu de données pendant le processus d'extraction, de transformation et de chargement ( Exemples 2024-05-21T02:00:00Z2024-05-22T02:00:00Z | |||
| Système source SourceSystem | Le système d'enregistrement à partir duquel les données ont été extraites. | ||
| Descriptionn Cet Son utilisation principale dans l'analyse est de filtrer les Pourquoi est-ce important ? : Identifie l'origine des données, ce qui est impératif pour la gouvernance des données, la validation et pour s'assurer que l'analyse est basée sur la bonne source. Source des données : Ceci est typiquement une valeur statique ajoutée pendant le processus d'extraction des données pour étiqueter l'origine des enregistrements. Exemples FenergoFenergo CLM | |||
| Date cible SLA SlaTargetDate | La date à laquelle le dossier d'intégration client devrait être finalisé. | ||
| Descriptionn La date cible du SLA représente la date limite convenue pour l'achèvement de l'ensemble du processus d'intégration pour une demande client. C'est un repère critique par rapport auquel la performance réelle est mesurée. Cet Pourquoi est-ce important ? : Définit la date d'achèvement cible, essentielle pour le suivi de la conformité SLA et la priorisation des dossiers en retard. Source des données : Cette date est souvent calculée en fonction de la date de soumission de la demande et des règles métier configurées dans le module de gestion des SLA de Fenergo. Exemples 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| Département de l'utilisateur UserDepartment | Le département ou l'unité commerciale auquel appartient l'utilisateur initiateur. | ||
| Descriptionn Cet Cette dimension est indispensablele pour analyser les transferts de processus entre différents départements et identifier les points de blocage interfonctionnels. Elle contribue directement au le Pourquoi est-ce important ? : Permet l'analyse de la performance du processus par département, mettant en évidence les transferts interdépartementaux, les retards et la répartition de la charge de travail. Source des données : Ceci peut nécessiter une jointure à partir d'une table distincte d'utilisateurs ou de données de référence RH en utilisant l'ID 'InitiatingUser'. Fenergo peut également stocker ceci dans le cadre du profil de l'utilisateur. Exemples ComplianceOnboarding clientAssurance Qualité | |||
| Heure de fin EventEndTime | Le 'horodatage' indiquant quand une activité ou un 'event' a été terminé. | ||
| Descriptionn Cet En Pourquoi est-ce important ? : Permet le calcul des temps de traitement des activités, ce qui est indispensable pour identifier les tâches longues et les points de blocage de performance. Source des données : Situé dans la piste d'audit de Fenergo ou les tables d'historique de workflow, souvent étiqueté comme 'EndDate', 'CompletionDate', ou dérivé de l'heure de début de l'événement suivant. Exemples 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| Score de Risque RiskScore | Un score numérique représentant le niveau de risque calculé du client. | ||
| Descriptionn Le Score de Risque est une mesure quantitative du risque potentiel associé à un client, calculée à partir de divers facteurs tels que la juridiction, l'industrie et les résultats de filtrage. Le moteur de règles de Fenergo calcule généralement ce score. Cet Pourquoi est-ce important ? : Quantifie le risque client, permettant d'analyser comment les niveaux de risque impactent la durée du processus, les retouches et les résultats. Source des données : C'est un résultat clé du module d'évaluation des risques client de Fenergo. Il est stocké sur le dossier ou l'entité client. Exemples 154585 | |||
| Statut de la demande ApplicationStatus | Le résultat actuel ou final de la demande client. | ||
| Descriptionn Cet C'est une dimension majeure pour l'analyse des résultats. Elle permet de filtrer et de comparer les flux de processus en fonction de leur résultat final, ce qui est indispensable pour le Pourquoi est-ce important ? : Définit l'issue d'un dossier, permettant une analyse puissante pour comparer les parcours des demandes approuvées et rejetées et comprendre les taux de réussite. Source des données : Ceci est généralement le statut final enregistré sur l'entité de dossier dans le système de gestion des dossiers de Fenergo. Exemples ApprouvéRejetéConformité en attenteClôturé | |||
| Utilisateur initiateur InitiatingUser | L'identifiant ou le nom de l'utilisateur qui a effectué l'activité. | ||
| Descriptionn Cet L'analyse par utilisateur aide à comprendre la répartition de la charge de travail, la performance individuelle et à identifier les besoins en formation. C'est indispensable pour le Pourquoi est-ce important ? : Suit quel utilisateur a effectué une action, permettant l'analyse de la répartition de la charge de travail, de la performance de l'équipe et de l'allocation des ressources. Source des données : Ces informationsns sont généralement stockées dans les journaux d'audit ou les tables d'historique des tâches de Fenergo, aux côtés des détails de l' Exemples j.doea.smithSYSTEM | |||
| Canal de demande ApplicationChannel | Le canal par lequel la demande client a été soumise. | ||
| Descriptionn Cet Cette dimension est utilisée dans le Pourquoi est-ce important ? : Identifie la source des demandes, permettant l'analyse de l'efficacité du canal, du coût et de l'expérience client. Source des données : Ces informationsns peuvent être saisies dans un formulaire de saisie de données initial dans Fenergo ou transmises par un système en amont. Exemples Portail en ligneSuccursaleGestionnaire de RelationApplication mobile | |||
| Est Automatisé IsAutomated | Un indicateur booléen indiquant si l'activité a été réalisée par un système plutôt que par un utilisateur humain. | ||
| Descriptionn Cet L'analyse de cet indicateur est indispensablele pour comprendre le niveau d'automatisation du processus. Elle aide à quantifier l'impact de l'automatisation sur l'efficacité, les coûts et la rapidité, et identifie les opportunités d'automatisation supplémentaire. Pourquoi est-ce important ? : Distingue les activités humaines et système, ce qui est indispensable à l'analyse de l'automatisation et la compréhension des coûts de ressources. Source des données : Ceci est généralement dérivé à partir du champ 'InitiatingUser'. Une liste d'ID d'utilisateurs système connus est utilisée pour définir cet indicateur sur vrai. Exemples truefaux | |||
| Est conforme aux SLA IsSlaCompliant | Un indicateur booléen indiquant si le dossier a été terminé dans le délai cible de son SLA. | ||
| Descriptionn Cet Ce champ calculé simplifie le suivi et le reporting SLA. Il permet une agrégation facile pour calculer le KPI global 'Taux de résolutionpect des SLA' et pour filtrer afin d'analyser les caractéristiques de processus des dossiers conformes versus non conformes. Pourquoi est-ce important ? : Mesure directement la performance SLA, permettant un calcul facile du KPI de Taux de Respect SLA et le filtrage des dossiers non conformes. Source des données : Ceci est dérivé en comparant l'horodatage de l'activité finale du dossier (par exemple, 'Demande Approuvée', 'Demande Rejetée') avec la 'SlaTargetDate'. Exemples truefaux | |||
| Est un reprises IsRework | Un indicateur booléen indiquant si une activité fait partie d'une boucle de reprises. | ||
| Descriptionn Cet Identifier les reprises est indispensable pour comprendre l'inefficacité du processus et les frictions. Cet indicateur permet le calcul direct du KPI 'Taux de Boucle de Retravail' et aide à visualiser et quantifier l'impact des étapes répétitives et inutiles dans le flux de processus. Pourquoi est-ce important ? : Met en évidence les boucles de reprise inefficaces dans le processus, aidant à quantifier le gaspillage et à identifier les domaines d'amélioration pour augmenter les taux de réussite dès la première fois. Source des données : Cet indicateur est dérivé à l'aide de techniques de Exemples truefaux | |||
| ID client CustomerId | Un identifiant unique pour le client ou l'entité juridique en cours d'intégration. | ||
| Descriptionn L'ID Client est la référence unique de l'entité client dans le système de données de référence. Alors que le numéro de demande est l'ID du dossier pour le processus, l'ID Client relie l'activité d'intégration à un client spécifique. Cet Pourquoi est-ce important ? : Relie le processus d'intégration à une entité client unique, permettant une analyse orientée client et l'enrichissement des données. Source des données : Cet ID est stocké sur l'enregistrement du client ou de l'entité juridique dans Fenergo et associé au dossier d'intégration. Exemples CUST-98765CUST-98766CUST-98767 | |||
| Motif de refus RejectionReason | Un code ou une description expliquant pourquoi une demande a été rejetée. | ||
| Descriptionn Lorsqu'une demande a le statut final 'Rejetée', cet C'est un Pourquoi est-ce important ? : Fournit un aperçu critique des raisons d'échec des applications, permettant une analyse des causes profondes pour réduire les taux de rejet. Source des données : Généralement disponible dans un code de raison ou un champ de notes associé au statut de rejet final dans le Exemples Correspondance aux sanctionsDocuments invalidesViolation de politiqueClient a retiré sa demande | |||
| Nombre de demandes d'informations supplémentaires AdditionalInfoRequestCount | Le nombre total de fois où des informations supplémentaires ont été demandées pour une demande. | ||
| Descriptionn Cette métrique compte les occurrences de l'activité 'Informations Supplémentaires Demandées' pour chaque cas. Un nombre plus élevé signifie plus de communication aller-retour, ce qui peut retarder le processus et entraîner une mauvaise expérience client. Cet Pourquoi est-ce important ? : Quantifie les frictions client et les retards de processus causés par des informations initiales incomplètes, aidant ainsi à améliorer l'étape de collecte des données. Source des données : Il s'agit d'une métrique calculée, dérivée en comptant le nombre d' Exemples 013 | |||
| Pays Country | Le pays de résidence ou la juridiction de la demande client. | ||
| Descriptionn Cet L'analyse du processus par pays permet des comparaisons juridictionnelles du temps de cycle, des niveaux de risque et de la complexité du processus. Elle aide à comprendre comment les différences régionales impactent la performance opérationnelle et à assurer la Pourquoi est-ce important ? : Permet la segmentation du processus en fonction de la géographie, ce qui est indispensable pour analyser l'impact réglementaire et la performance régionale. Source des données : Ces informationsns font partie des Exemples États-UnisGBRSGPDEU | |||
| Responsable du dossier CaseOwner | L'utilisateur ou l'équipe principale responsable de la gestion de la demande tout au long de son cycle de vie. | ||
| Descriptionn Le Responsable de dossier est l'individu ou le groupe à qui est attribuée la responsabilité principale d'un dossier d'intégration. Cette personne est généralement redevable de sa réalisation rapide et réussie. Cet Pourquoi est-ce important ? : Identifie la personne ou l'équipe responsable d'un dossier, permettant l'analyse de la performance des gestionnaires de dossiers. Source des données : Ceci est généralement un champ spécifique sur l'entité de dossier principale dans Fenergo, indiquant l'affectation du dossier. Exemples s.jonesintégration_team_am.chen | |||
| Type de client CustomerType | La classification du client en cours d'intégration, telle qu'Individu, Entreprise ou Fiducie. | ||
| Descriptionn Cet L'analyse du processus par type de client aide à identifier les différences de performance entre les segments. Elle est indispensablele pour le Pourquoi est-ce important ? : Permet la comparaison de la performance des processus entre différents segments de clientèle, qui ont souvent des complexités et des SLA variés. Source des données : Ces informationsns sont généralement stockées sur l'entité client ou client dans Fenergo et liées au dossier de demande. Exemples ParticulierEntrepriseFiduciePartenariat | |||
Activités d'intégration client KYC
| Activité | Descriptionn | ||
|---|---|---|---|
| Demande Approuvée | Cette activité représente la décision finale d'approuver la demande d'intégration du client. Elle est déduite du changement de statut du dossier vers un état final 'Approuvé' ou 'Intégration Approuvée'. | ||
| Pourquoi est-ce important ? : Ce jalon clé signifie un résultat réussi avant les étapes finales d'activation de compte. Il est indispensable pour calculer les taux d'approbation et analyser les propriétés des clients intégrés avec succès. Source des données : Déduit de l'historique du dossier ou du journal d'audit en trouvant l'horodatage du changement de statut final vers 'Approved' ou un état positif terminal similaire. Capture Identifiez l'horodatage du changement de statut final vers 'Approved'. Type d'événement inferred | |||
| Demande Rejetée | Cette activité est un `événement` terminal représentant la décision finale de rejeter la demande du client. Elle est déduite du changement de statut du dossier vers un état final 'Rejeté' ou 'Refusé'. | ||
| Pourquoi est-ce important ? : En tant que point final clé du processus, cette activité est fondamentale pour le calcul du « Taux de rejet des demandes » et l'analyse des raisons d'échec. Elle aide à identifier les points de rejet courants et à améliorer la qualité des demandes. Source des données : Déduit du journal d'audit du dossier en capturant l'horodatage lorsque le statut final passe à 'Rejected'. La raison du rejet est souvent stockée dans un champ lié. Capture Identifiez l'horodatage du changement de statut final vers 'Rejected'. Type d'événement inferred | |||
| Dossier clos | C'est l'activité finale, signifiant que le dossier d'intégration est administrativement clos dans Fenergo, sans autre action attendue. Cela s'applique aux demandes approuvées et rejetées et est déduit d'un statut final 'Clos'. | ||
| Pourquoi est-ce important ? : Cette activité sert de point final définitif pour l'ensemble du processus. Elle garantit des calculs précis du temps de cycle pour tous les dossiers, quel que soit leur résultat, et confirme que le processus est terminé. Source des données : Déduit du journal d'audit des dossiers Fenergo en identifiant l'horodatage lorsque le statut du dossier est défini comme 'Closed', 'Completed' ou un autre état terminal. Capture Identifiez l'horodatage du changement de statut final vers 'Closed' ou 'Completed'. Type d'événement inferred | |||
| Dossier créé | Cette activité marque le début du processus d'intégration KYC lorsqu'une nouvelle demande client est formellement créée dans Fenergo. Il s'agit généralement d'un `événement` explicite enregistré avec un horodatage spécifique lors de la première sauvegarde du dossier. | ||
| Pourquoi est-ce important ? : En tant qu'événement de départ, cette activité est indispensablele pour calculer le temps de cycle global d'intégration et analyser le débit. Elle fournit la base de toutes les mesures de processus ultérieures et du suivi des SLA. Source des données : Ceci est généralement capturé à partir de l'horodatage de création de l'entité de dossier principale dans Fenergo, souvent trouvé dans les tables liées aux dossiers d'intégration client ou aux Capture Utilisez l'horodatage de création de l'enregistrement du dossier d'intégration. Type d'événement explicit | |||
| Évaluation des risques terminée | Représente l'achèvement du processus interne de classification des risques, où un niveau de risque est attribué au client en fonction de divers facteurs. Ceci est déduit d'un changement de statut ou du renseignement d'un champ d'évaluation des risques. | ||
| Pourquoi est-ce important ? : C'est un jalon décisionnel clé qui détermine souvent le chemin du Source des données : Déduit du journal d'historique du dossier en identifiant le moment où le dossier passe à un statut comme 'Risk Assessed' ou lorsque le champ final 'Customer Risk Rating' est renseigné avec une valeur. Capture Utilisez l'horodatage lorsque le champ d'évaluation des risques est finalisé ou qu'un statut connexe est défini. Type d'événement inferred | |||
| Examen de conformité initié | Cette activité marque le début de l'examen par le service de la `conformité`, une étape critique et souvent longue. Elle est déduite lorsque le dossier est assigné à la file d'attente de travail de la `conformité` ou que son statut passe à 'En Attente d'Examen de Conformité'. | ||
| Pourquoi est-ce important ? : Cette activité est le point de départ pour mesurer le KPI 'Temps Moyen d'Examen de Conformité'. Elle aide à identifier combien de temps les dossiers attendent avant d'être traités activement par l'équipe de Source des données : Déduit du journal d'audit des dossiers Fenergo en capturant l'horodatage du changement de statut vers 'In Compliance Review' ou de l'assignation du dossier à un responsable ou une équipe de conformité. Capture Identifiez l'horodatage du changement de statut vers 'Under Compliance Review' ou de l'événement d'assignation. Type d'événement inferred | |||
| Examen de conformité terminé | Marque l'approbation formelle par le département de conformité, indiquant que toutes les exigences réglementaires ont été satisfaites. Ceci est déduit d'un achèvement de tâche ou d'un changement de statut vers 'Compliance Approved'. | ||
| Pourquoi est-ce important ? : En tant qu'étape majeure, l'achèvement de cette activité est indispensable pour le temps de cycle global. C'est le point final pour mesurer le « Temps moyen d'examen de conformité » et identifier les points de blocage dans la fonction de conformité. Source des données : Déduit de l'horodatage d'achèvement de la tâche 'Compliance Review' au sein du workflow Fenergo ou de l'événement de mise à jour du statut dans l'historique du dossier. Capture Utilisez l'horodatage de l'achèvement de la tâche d'examen de la Type d'événement inferred | |||
| Examen des documents terminé | Signifie l'achèvement du processus manuel ou automatisé de vérification de l'authenticité et de l'exactitude de tous les documents client soumis. Cet événement est généralement déduit de l'achèvement d'une tâche de `workflow` ou d'un changement de statut dans Fenergo. | ||
| Pourquoi est-ce important ? : C'est un jalon critique où de nombreux retards se produisent. L'analyse de la durée et des résultats de cette activité aide à identifier les points de blocage dans le traitement des documents et soutient des KPI comme le 'Taux de réussite au premier passage'. Source des données : Déduit de l'horodatage d'achèvement de la tâche 'Document Verification' dans le workflow du dossier ou d'une mise à jour de statut vers 'Documents Approved' dans le journal d'historique du dossier. Capture Utilisez l'horodatage de l'achèvement de la tâche d'examen des documents ou un changement de statut connexe. Type d'événement inferred | |||
| Compte Activé | Indique que le compte du client a été créé et activé avec succès dans le système bancaire central ou le système en aval pertinent après approbation. Cela peut être déduit d'une mise à jour de statut finale dans Fenergo après approbation. | ||
| Pourquoi est-ce important ? : Cette activité confirme le transfert réussi du processus d'intégration au statut de client actif. La mesure du temps entre l'approbation et l'activation peut révéler des retards dans la mise en place opérationnelle. Source des données : Ceci peut être déduit d'un statut de dossier tel que 'Compte Actif' ou 'Intégration Terminée'. Il pourrait également s'agir d'un Capture Recherchez un changement de statut post-approbation ou un événement de journal de succès d'intégration. Type d'événement inferred | |||
| Dépistage initial effectué | Représente l'achèvement des vérifications préliminaires automatisées ou manuelles, telles que la validation de données de base ou le filtrage des listes de sanctions. Ceci est souvent déduit d'un changement de statut dans le `workflow` du dossier Fenergo, par exemple, le passage de 'Nouveau' à 'Filtrage Terminé'. | ||
| Pourquoi est-ce important ? : Le suivi de ce jalon précoce aide à identifier les problèmes initiaux de qualité des Source des données : Déduit de l'historique du dossier ou du journal d'audit en identifiant l'horodatage lorsque le statut du dossier passe à un état indiquant que le screening est terminé, tel que 'Screening Passed' ou 'Awaiting Documents'. Capture Identifiez un changement de statut vers 'Screening Complete' ou similaire à partir de l'historique du dossier. Type d'événement inferred | |||
| Documents Reçus | Cette activité indique que le client a téléchargé ou soumis les documents requis, qui sont maintenant disponibles dans Fenergo pour examen. Ceci est généralement déduit lorsque le statut du dossier est mis à jour en 'Documents Reçus' ou 'En Attente de Révision'. | ||
| Pourquoi est-ce important ? : Ceci marque la fin de la période d'attente du client et le début du cycle d'examen interne. C'est impératif pour mesurer les temps de réponse du client et les temps d'attente dans les files de traitement internes. Source des données : Déduit de la piste d'audit du dossier, qui enregistre l'horodatage d'un changement de statut vers 'Documents Received' ou un état similaire. Il peut également être lié à des événements d'upload de documents. Capture Identifiez l'horodatage du changement de statut vers 'Documents Received' ou 'Ready for Review'. Type d'événement inferred | |||
| Données et documents demandés | Cet `événement` signifie que le système ou un agent d'intégration a formellement demandé des informations et des documents nécessaires au client. Il est souvent capturé comme un `événement` explicite lorsqu'un `template` de communication standardisé est envoyé. | ||
| Pourquoi est-ce important ? : Cette activité marque le début d'une phase dépendante du client. Mesurer le temps entre ce point et la réception des documents est indispensable pour analyser le parcours client et identifier les retards de communication. Source des données : Capturé à partir d'un journal d'événements associé aux communications client ou d'un journal d'achèvement de tâche pour 'Request Documents'. Il peut également être déduit d'un changement de statut vers 'Awaiting Customer Information'. Capture Recherchez un événement enregistré pour la communication client ou l'achèvement d'une tâche. Type d'événement explicit | |||
| Informations complémentaires demandées | Représente une boucle de reprises où l'équipe d'intégration doit revenir vers le client pour des clarifications ou des documents manquants. Il s'agit d'un événement explicite, généralement enregistré lorsqu'une communication est envoyée au client. | ||
| Pourquoi est-ce important ? : Cette activité est un indicateur principal d'inefficacité du processus et d'une mauvaise expérience client. Le suivi de sa fréquence aide à identifier les causes profondes du reprises et soutient le KPI 'Taux de Boucle de Retravail'. Source des données : Capturé à partir d'un journal d'événements des communications client ou d'un changement de statut vers 'Awaiting Additional Information'. Le premier est plus précis pour capturer le moment exact de la demande. Capture Trouvez les événements de communication enregistrés ou un changement de statut vers 'Pending Customer Response'. Type d'événement explicit | |||
| Vérifications d'antécédents initiées | Cette activité marque le moment où les vérifications externes d'antécédents, de LBA ou de crédit sont déclenchées. Il s'agit souvent d'un `événement` explicite enregistré lorsqu'une intégration avec un service tiers est appelée. | ||
| Pourquoi est-ce important ? : Le suivi de l'initiation et de l'achèvement de ces vérifications est indispensable à comprendre les retards causés par des dépendances externes. Cela aide à isoler le temps de processus interne du temps d'attente externe. Source des données : Généralement capturé à partir des journaux système qui enregistrent les appels API aux fournisseurs de filtrage externes ou à partir de la création d'une tâche spécifique de 'Vérification d'Antécédents' au sein du dossier Fenergo. Capture Trouvez les journaux pour les intégrations de services externes ou la création d'une tâche de 'Screening'. Type d'événement explicit | |||
Guides d'extraction
Étapes
- Accéder au module de Reporting : Connectez-vous à l'application Fenergo avec un compte utilisateur disposant des autorisations suffisantes pour le module Reporting & Analytics. Naviguez vers le module, généralement situé dans le menu principal de l'application.
- Créer un nouveau rapport : Lancez la création d'un nouveau rapport personnalisé. Sélectionnez un nom et une description qui identifient clairement son objectif, par exemple, 'Journal d'événements d'Onboarding KYC pour Process Mining'.
- Définir la source de données principale : Sélectionnez l'objet de données ou la vue principale qui capture les informations du cycle de vie des dossiers. Il s'agit souvent d'une vue préconfigurée comme
[CaseWorkflowHistory]ou[LifecycleEventsView]. Cet objet doit contenir les identifiants de dossier, les noms ou statuts d'événements, et les horodatages. - Configurer les colonnes de rapport (Attributs) : Utilisez l'interface du générateur de rapports pour ajouter des colonnes. Mappez les champs source du modèle de données Fenergo aux attributs de journal d'événements requis. Par exemple, mappez le
CaseIDde Fenergo àCustomerApplication,EventHorodatageàEventStartTime, etEventPerformeràInitiatingUser. - Construire la logique d'activité : C'est l'étape la plus critique. Le rapport doit être configuré pour générer une ligne distincte pour chacune des 14 activités requises. Ceci est réalisé en créant des blocs logiques ou des ensembles de données filtrés pour chaque activité et en les combinant à l'aide d'une fonction UNION ou équivalente dans le générateur de rapports.
- Définir la logique 'Case Created' : Créez le premier bloc. Filtrez la source de données pour l'événement initial de création de dossier. Cela est souvent basé sur l'horodatage le plus ancien associé au dossier ou à un type d'événement nommé 'Case Created'. Mappez la
CreationDateà l'EventStartTime. - Définir la logique d'activité basée sur le statut : Pour les activités déduites des changements de statut (par exemple, 'Documents Received', 'Application Approved'), créez des blocs séparés. Filtrez la source de données sur la valeur spécifique du champ
Statuset utilisez laStatusChangeDatecommeEventStartTime. - Définir la logique d'activité basée sur les tâches : Pour les activités liées aux tâches de workflow (par exemple, 'Compliance Review Completed'), créez des blocs qui filtrent sur le
TaskNameet laTaskCompletionDate. Utilisez la date de fin commeEventStartTime. - Définir les filtres de rapport globaux : Appliquez des filtres au niveau du rapport pour définir la portée des données. Définissez une
Plage de datesspécifique pour l'EventStartTimeafin d'éviter les exportations excessivement volumineuses. Une période de 3 à 6 mois est recommandée pour l'analyse initiale. Filtrez pour le type de dossier spécifique, tel que 'KYC Customer Onboarding'. - Exécuter et prévisualiser le rapport : Exécutez le rapport dans l'interface utilisateur (UI) de Fenergo. Prévisualisez les 100 à 200 premières lignes pour vous assurer que la structure des données est correcte, que toutes les colonnes sont renseignées comme prévu et que différentes activités sont présentes.
- Exporter les données : Exportez les résultats complets du rapport vers un fichier CSV ou Excel. Il s'agit du fichier de journal d'événements brut.
- Préparation finale des données : Ouvrez le fichier CSV exporté. Si les colonnes
SourceSystemetLastDataUpdaten'ont pas pu être générées directement par le rapport, ajoutez-les manuellement. Définissez 'Fenergo' commeSourceSystempour toutes les lignes et l'horodatage de l'exportation commeLastDataUpdate.
Configuration
- Prérequis : L'utilisateur doit avoir accès au module Reporting et Analytics de Fenergo avec les permissions nécessaires pour créer et exécuter des rapports personnalisés.
- Sources de données principales : Le rapport doit être principalement construit à partir des objets de gestion des dossiers et d'historique de workflow de Fenergo. Les sources courantes incluent
[CaseDetails],[CaseStatusHistory]et[WorkflowTaskHistory]. Les noms exacts peuvent varier en fonction de votre configuration Fenergo. - Plage de dates : Il est impératif de définir un filtre de plage de dates sur l'horodatage des événements pour gérer la performance. Commencez par une période récente de 3 à 6 mois. Pour l'analyse historique, exécutez le rapport par lots (par exemple, trimestriellement ou annuellement).
- Filtres clés : Filtrez toujours par le type de processus ou de dossier spécifique, tel que 'KYC Customer Onboarding', pour exclure les données non pertinentes. Vous pourriez également avoir besoin de filtrer par type d'entité juridique ou juridiction selon vos objectifs d'analyse.
- Définition de l'activité : Chaque activité doit être définie à l'aide de critères de filtre spécifiques sur des champs comme
Status,TaskNameou un champEventTypedédié. S'appuyer sur ces champs est indispensable pour isoler chaque événement unique dans le processus. - Considérations de performance : Les rapports qui unissent de nombreuses sources de données ou qui scannent une large plage de dates peuvent être lents. Planifiez l'exécution du rapport pendant les heures creuses si possible. Évitez d'inclure des colonnes inutiles dans l'exportation, car cela augmente le temps de traitement.
a Exemple de requête config
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'