Votre Template de Données pour l'Intégration Client KYC
Votre Template de Données pour l'Intégration Client KYC
- Attributs recommandés à collecter
- Activités clés à suivre
- Guide pour l'extraction de `données`
Attributs d'Onboarding Client KYC
| Nom | Description | ||
|---|---|---|---|
| Demande client CustomerApplication | L'identifiant unique pour le parcours d'intégration d'un seul client, servant d'identifiant principal du dossier. | ||
| Description La Demande Client est l'identifiant central qui regroupe toutes les activités et En Pourquoi c'est important C'est l'ID de Dossier essentiel qui relie tous les Où obtenir 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`. | ||
| Description Cet En Pourquoi c'est important Cet horodatage est critique pour ordonner les Où obtenir Situé dans la piste d'audit de Fenergo, le journal d'événements ou les tables d'historique de workflow, souvent étiqueté comme 'Timestamp', '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. | ||
| Description 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 constitue la base de la cartographie des processus. L'analyse de cet Pourquoi c'est important Cet Où obtenir Ces informations 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 | Le `timestamp` de la dernière actualisation ou extraction des `données` de ce `processus`. | ||
| Description Cet Dans les Pourquoi c'est important Fournit un contexte crucial sur la fraîcheur des données, garantissant que les utilisateurs comprennent à quel point l'analyse des processus est actuelle. Où obtenir Cette valeur est générée et estampillée sur le jeu de 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. | ||
| Description Cet Son utilisation principale dans l'analyse est de filtrer les Pourquoi c'est important Identifie l'origine des données, ce qui est crucial pour la gouvernance des données, la validation et pour s'assurer que l'analyse est basée sur la bonne source. Où obtenir 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é. | ||
| Description 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 c'est important Définit la date d'achèvement cible, cruciale pour le suivi de la conformité SLA et la priorisation des dossiers en retard. Où obtenir 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 Utilisateur UserDepartment | Le département ou l'unité commerciale auquel appartient l'utilisateur initiateur. | ||
| Description Cet Cette dimension est cruciale pour analyser les transferts de processus entre différents départements et identifier les goulots d'étranglement interfonctionnels. Elle soutient directement le Pourquoi c'est important Permet l'analyse de la performance du processus par département, mettant en évidence les transferts inter-départementaux, les retards et la répartition de la charge de travail. Où obtenir Ceci peut nécessiter une jointure à partir d'une table distincte d'utilisateurs ou de Exemples ComplianceOnboarding clientAssurance Qualité | |||
| Heure de fin EventEndTime | Le 'timestamp' indiquant quand une activité ou un 'event' a été complété. | ||
| Description Cet En Pourquoi c'est important Permet le calcul des temps de traitement des activités, ce qui est fondamental pour identifier les tâches longues et les goulots d'étranglement de performance. Où obtenir 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. | ||
| Description 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 c'est 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. Où obtenir 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. | ||
| Description Cet C'est une dimension critique 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 essentiel pour le Pourquoi c'est 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. Où obtenir 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éEn attente de conformitéClôturé | |||
| Utilisateur initiateur InitiatingUser | L'identifiant ou le nom de l'utilisateur qui a effectué l'activité. | ||
| Description 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 essentiel pour le Pourquoi c'est 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. Où obtenir Ces informations 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. | ||
| Description Cet Cette dimension est utilisée dans le Pourquoi c'est important Identifie la source des demandes, permettant l'analyse de l'efficacité du canal, du coût et de l'expérience client. Où obtenir Ces informations peuvent être saisies dans un formulaire de saisie de Exemples Portail en ligneFilialeGestionnaire de RelationMobile App | |||
| 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. | ||
| Description Cet L'analyse de cet indicateur est cruciale 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 c'est important Distingue les activités humaines et système, ce qui est vital pour l'analyse de l'automatisation et la compréhension des coûts de ressources. Où obtenir 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é complété dans le délai cible de son SLA. | ||
| Description Cet Ce champ calculé simplifie le suivi et le reporting SLA. Il permet une agrégation facile pour calculer le KPI global 'Taux de respect des SLA' et pour filtrer afin d'analyser les caractéristiques de processus des dossiers conformes versus non conformes. Pourquoi c'est important Mesure directement la performance SLA, permettant un calcul facile du KPI de Taux de Respect SLA et le filtrage des dossiers non conformes. Où obtenir 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 retravail IsRework | Un indicateur booléen indiquant si une activité fait partie d'une boucle de retravail. | ||
| Description Cet Identifier le retravail est essentiel 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 c'est important Met en évidence les boucles de retravail 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. Où obtenir 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'onboarding. | ||
| Description L'ID Client est la référence unique de l'entité client dans le système de Cet Pourquoi c'est important Relie le processus d'onboarding à une entité client unique, permettant une analyse centrée sur le client et l'enrichissement des données. Où obtenir 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. | ||
| Description Lorsqu'une demande a le statut final 'Rejetée', cet C'est un Pourquoi c'est 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. Où obtenir Généralement trouvé dans un code de raison ou un champ de notes associé au statut de rejet final dans le Exemples Correspondance 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. | ||
| Description Cette métrique compte les occurrences de l'activité 'Informations Supplémentaires Demandées' pour chaque dossier. 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 c'est 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. Où obtenir 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. | ||
| Description 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 c'est important Permet la segmentation du processus en fonction de la géographie, ce qui est essentiel pour analyser l'impact réglementaire et la performance régionale. Où obtenir Ces informations 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. | ||
| Description 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 c'est important Identifie la personne ou l'équipe responsable d'un dossier, permettant l'analyse de la performance des gestionnaires de dossiers. Où obtenir Ceci est généralement un champ spécifique sur l'entité de dossier principale dans Fenergo, indiquant l'affectation du dossier. Exemples s.jonesonboarding_team_am.chen | |||
| Temps de traitement ProcessingTime | Le temps passé à travailler activement sur une activité. | ||
| Description Le Temps de traitement, également connu sous le nom de temps actif, est la durée calculée entre l'horodatage de début et de fin d'une seule activité. Il représente le temps pendant lequel une ressource a été activement engagée dans une tâche. Cette métrique est fondamentale pour l'analyse de performance. Elle est utilisée dans les dashboards d'analyse des goulots d'étranglement pour repérer quelles activités spécifiques sont les plus chronophages, aidant ainsi à concentrer les efforts d'amélioration là où ils auront le plus d'impact. Pourquoi c'est important Cette mesure calculée évalue le temps de travail actif pour chaque activité, ce qui est crucial pour identifier les goulots d'étranglement de performance. Où obtenir Calculé comme la différence entre 'EventEndTime' et 'EventStartTime' (EndTime - StartTime). Exemples 86400000360000018000000 | |||
| Type de client CustomerType | La classification du client en cours d'intégration, telle qu'Individu, Entreprise ou Fiducie. | ||
| Description Cet L'analyse du processus par type de client aide à identifier les différences de performance entre les segments. Elle est essentielle pour le Pourquoi c'est 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. Où obtenir Ces informations 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'Onboarding Client KYC
| Activité | Description | ||
|---|---|---|---|
| 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 c'est important Ce jalon clé signifie un résultat réussi avant les étapes finales d'activation de compte. Il est essentiel pour calculer les taux d'approbation et analyser les propriétés des clients intégrés avec succès. Où obtenir 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 c'est important En tant que point final clé du processus, cette activité est vitale 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. Où obtenir 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 c'est 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é. Où obtenir 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 c'est important En tant qu'événement de départ, cette activité est essentielle pour calculer le temps de cycle global d'onboarding et analyser le débit. Elle fournit la base de toutes les mesures de processus ultérieures et du suivi des SLA. Où obtenir 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 c'est important C'est un jalon décisionnel clé qui détermine souvent le chemin du Où obtenir 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 c'est 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 Où obtenir 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 c'est important En tant qu'étape majeure, l'achèvement de cette activité est essentiel pour le temps de cycle global. C'est le point final pour mesurer le « Temps moyen d'examen de conformité » et identifier les goulots d'étranglement au sein de la fonction de conformité. Où obtenir 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 c'est 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 goulots d'étranglement dans le traitement des documents et soutient des KPI comme le 'Taux de réussite au premier passage'. Où obtenir 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 c'est 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. Où obtenir 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 c'est important Le suivi de ce jalon précoce aide à identifier les problèmes initiaux de qualité des Où obtenir 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 c'est important Ceci marque la fin de la période d'attente du client et le début du cycle d'examen interne. C'est crucial pour mesurer les temps de réponse du client et les temps d'attente dans les files de traitement internes. Où obtenir 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 c'est 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 essentiel pour analyser le parcours client et identifier les retards de communication. Où obtenir 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 retravail 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 c'est 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 retravail et soutient le KPI 'Taux de Boucle de Retravail'. Où obtenir 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 des 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 c'est important Le suivi de l'initiation et de l'achèvement de ces vérifications est vital pour comprendre les retards causés par des dépendances externes. Cela aide à isoler le temps de processus interne du temps d'attente externe. Où obtenir 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,EventTimestampà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 crucial 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 essentiel 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]'