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 d'extraction pour ACTICO
Attributs d'intégration client KYC
| Nom | Descriptionn | ||
|---|---|---|---|
| Demande client CustomerApplication | L'identifiant unique pour une seule demande d'intégration client, servant d'ID de dossier pour l'analyse de processus. | ||
| Descriptionn La demande client est l'identifiant de dossier principal qui regroupe tous les événements et activités liés au parcours d'intégration d'un seul client. Elle représente une instance complète du processus KYC, de la soumission initiale à la décision finale d'approbation ou de rejet. En Process Mining, cet attribut est indispensable pour reconstruire le parcours complet de chaque demande. Il permet aux analystes de suivre la séquence des activités, de mesurer les temps de cycle totaux et de comparer les différents chemins de processus, ou variantes, empruntés par diverses demandes. Tous les événements partageant le même ID de demande client sont considérés comme faisant partie du même dossier. Pourquoi est-ce important ? : C'est l'attribut clé pour le Process Mining, car il connecte tous les événements liés en une seule instance de processus cohérente, permettant une analyse complet de l'expérience d'intégration de chaque client. Source des données : C'est une clé primaire dans les tables principales de l'application ou de gestion des dossiers au sein d'ACTICO. Consultez la documentation ACTICO pour les noms spécifiques des tables et des champs. Exemples APP-2023-001, 2, 3, 4APP-2023-001235APP-2024-000001 | |||
| Heure de l'événement EventTime | L'horodatage indiquant quand une activité spécifique a commencé ou s'est produite. | ||
| Descriptionn L'heure de l'événement ( Cet attribut est indispensable pour toutes les analyses temporelles. Il est utilisé pour calculer les temps de cycle entre les activités, identifier les retards et les temps d'attente, mesurer la durée globale du cas et vérifier la conformité aux accords de niveau de service (SLA). La séquence de ces horodatages pour un cas donné permet aux outils de Pourquoi est-ce important ? : Cet attribut fournit l'ordre chronologique des événements, ce qui est indispensable pour calculer les durées, identifier les points de blocage et analyser la chronologie du processus. Source des données : Situé dans les tables de journaux d'événements d'ACTICO, c'est l'horodatage associé à chaque activité enregistrée. Consultez la documentation ACTICO. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| Nom de l'activité ActivityName | Le nom de l'événement commercial ou de la tâche spécifique effectuée dans le processus d'intégration client. | ||
| Descriptionn Cet attribut enregistre le nom de chaque étape ou activité qui se produit pendant le processus KYC, telle que 'Demande soumise', 'Évaluation des risques effectuée' ou 'Demande approuvée'. Il fournit les blocs de construction séquentiels de la carte de processus. L'analyse du nom de l'activité facilite la visualisation du flux de processus, l'identification des activités fréquentes ou rares et la détection des points de blocage ou des boucles de reprise. C'est une élément central pour comprendre quelles actions sont effectuées et dans quel ordre, ce qui est impératif pour l'analyse des variantes et les contrôles de conformité. Pourquoi est-ce important ? : Il définit les étapes de la carte de processus, pour visualiser du flux de processus, l'identification des écarts et l'analyse de la fréquence et de la séquence des activités. Source des données : Cette information se trouve généralement dans une table de journal d'événements au sein d'ACTICO, souvent dans un champ décrivant le type d'événement ou de tâche. Consultez la documentation ACTICO. Exemples Demande soumiseÉvaluation des risques effectuéeExamen de conformité terminéDemande Rejetée | |||
| Dernière mise à jour des données LastDataUpdate | L'horodatage indiquant la dernière fois que les données ont été actualisées ou extraites du système source. | ||
| Descriptionn Cet attribut consigne la date et l'heure de la dernière extraction de données d'ACTICO. C'est un champ de métadonnées qui s'applique à l'ensemble du jeu de données, plutôt qu'aux événements individuels, fournissant un contexte sur la récence de l'analyse. Dans les dashboards et les rapports, cette information est fondamentale pour que les utilisateurs comprennent la réactualisation des données. Elle aide à gérer les attentes concernant la pertinence des informations et est indispensablele pour le suivi opérationnel où les données quasi-temps réel sont importantes. L'affichage de cet horodatage garantit la transparence et la confiance dans les données présentées. Pourquoi est-ce important ? : Indique la la réactualisation des données, permettant aux utilisateurs de comprendre s'ils analysent des informations à jour, ce qui est indispensable pour la prise de décision opérationnelle. Source des données : Cette valeur est générée et stockée pendant le processus d'extraction, de transformation et de chargement des données (ETL). Elle reflète l'horodatage lorsque le travail ETL a été terminé avec succès. Exemples 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| Système source SourceSystem | Le système source dont proviennent les données d'événements. | ||
| Descriptionn Cet attribut identifie le système d'information source où les données ont été générées. Pour ce processus, ce sera systématiquement 'ACTICO', mais dans des analyses plus larges impliquant plusieurs systèmes, il aide à différencier les origines des données. Dans un contexte de Process Mining, il est impératif pour la gouvernance et la validation des données. Il garantit que les données sont correctement attribuées à leur source, ce qui est important lors de la fusion de données provenant de différents systèmes pour créer une vue d'ensemble complète du processus. Il aide également à résoudre les problèmes de qualité des données en les retraçant jusqu'au système d'origine. Pourquoi est-ce important ? : Fournit un contexte essentiel sur l'origine des données, assurant la traçabilité et la gouvernance des données, ce qui est critique lors de la combinaison de données provenant de sources multiples. Source des données : C'est typiquement une valeur statique ('ACTICO') ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'ensemble de données. Exemples ACTICOPlateforme ACTICOModule KYC Actico | |||
| Date cible SLA SlaTargetDate | La date à laquelle le processus d'intégration client devrait être terminé. | ||
| Descriptionn La date cible SLA est la date limite pour l'achèvement de l'intégration d'un client, telle que définie par les accords de niveau de service internes. Cette date est souvent calculée sur la base de la date de soumission de la demande plus un temps de traitement standard. Cet attribut est indispensable pour le suivi de la conformité SLA. En comparant la date d'achèvement réelle d'un dossier à sa date cible SLA, le système peut déterminer si le dossier a été achevé à temps ou s'il a enfreint le SLA. C'est la base du tableau de bord 'Performance SLA de l'intégration' et du KPI 'Taux d'adhésion SLA de l'intégration'. Pourquoi est-ce important ? : Fournit la référence pour mesurer la performance dans les délais, permettant un suivi et un reporting directs de la conformité SLA. Source des données : Ceci peut être stocké comme un champ dans la table principale des dossiers dans ACTICO ou pourrait être dérivé sur la base de règles métier (par exemple, Date de soumission + 5 jours ouvrables). Exemples 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| Département Department | Le département ou l'équipe commerciale responsable de l'exécution de l'activité. | ||
| Descriptionn Cet attribut assigne une activité à une unité organisationnelle spécifique, telle que 'Conformité', 'Équipe d'intégration' ou 'Relations Clients'. Il fournit un contexte organisationnel au flux de processus. L'analyse au niveau du département est indispensablele pour comprendre comment le travail est transféré entre les différentes parties de l'organisation. Elle aide à identifier les points de blocage interdépartementaux, à mesurer l'efficacité départementale et à analyser l'allocation des ressources entre les équipes. Les dashboards peuvent être filtrés par département pour fournir aux managers une vue de la performance spécifique de leur équipe. Pourquoi est-ce important ? : Fournit une dimension organisationnelle pour l'analyse, permettant l'identification des retards interdépartementaux et l'évaluation de la performance au niveau des équipes. Source des données : Cette information pourrait être stockée directement avec les données d'événements ou dérivée en joignant les données utilisateur à une table de données de référence RH qui mappe les utilisateurs aux départements. Consultez la documentation ACTICO. Exemples ComplianceÉquipe d'intégrationService client | |||
| Heure de fin EndTime | L'horodatage indiquant la date et l'heure de réalisation d'une activité spécifique. | ||
| Descriptionn L'heure de fin marque la fin d'une activité. Associée à l'heure de début ((EventTime)), elle permet le calcul de la durée précise de chaque tâche, connue sous le nom de temps de traitement. Tous les événements n'ont pas une heure de fin distincte, certains pouvant être instantanés. Cet attribut est indispensable pour l'analyse des performances, en particulier pour mesurer le temps que prend chaque étape. Il permet la création de dashboards de performance détaillés, aide à identifier les activités qui prennent le plus de temps et est indispensable pour calculer des KPI tels que le 'temps moyen d'examen des documents'. Pourquoi est-ce important ? : Permet le calcul de durées d'activité précises (temps de traitement), ce qui est impératif pour identifier les points de blocage de performance et analyser l'efficacité des ressources. Source des données : Comme l'heure de début, cela se trouve généralement dans les tables de journaux d'événements d'ACTICO. Certains systèmes stockent les heures de début et de fin dans des colonnes distinctes pour un seul enregistrement d'événement. Consultez la documentation ACTICO. Exemples 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| Motif de refus RejectionReason | La raison spécifique fournie lorsqu'une demande client est rejetée. | ||
| Descriptionn Lorsque le statut final d'une demande est 'Rejetée', cet attribut fournit la cause sous-jacente. Par exemple : 'Documentation incomplète', 'Échec de la vérification des antécédents' ou 'Profil à haut risque'. C'est un attribut essentiel pour l'analyse des causes profondes. En analysant la fréquence des différentes raisons de rejet, l'entreprise peut identifier les problèmes systémiques dans le processus ou avec les soumissions des clients. Par exemple, un nombre élevé de rejets dus à une documentation incomplète pourrait indiquer que les instructions de la demande ne sont pas claires. Ceci contribue directement au le tableau de bord 'Taux de rejet des demandes et raisons'. Pourquoi est-ce important ? : Fournit le 'pourquoi' des rejets de demandes, permettant une analyse des causes profondes pour réduire le taux de rejet et améliorer l'efficacité du processus. Source des données : Généralement disponible dans la table principale des dossiers ou des demandes dans ACTICO, souvent rempli uniquement lorsque le statut de la demande est 'Rejetée'. Exemples Documentation incomplèteVérification d'identité échouéeCorrespondance aux sanctionsScore de risque élevé | |||
| Niveau de risque RiskLevel | Le niveau de risque calculé de la demande client, tel que Faible, Moyen ou Élevé. | ||
| Descriptionn Cet attribut représente la catégorie de risque évaluée d'un client, qui détermine souvent la complexité et la rigueur du processus KYC ultérieur. Un client à haut risque peut nécessiter des vérifications et des approbations supplémentaires par rapport à un client à faible risque. En Process Mining, le niveau de risque est une dimension puissante pour l'analyse comparative. Il permet aux analystes de vérifier si le processus suit correctement différents chemins en fonction du risque, comme prévu. Par exemple, on peut vérifier que tous les clients à haut risque subissent une étape de diligence raisonnable renforcée. Il est indispensable pour le tableau de bord 'Flux de processus d'évaluation des risques'. Pourquoi est-ce important ? : Permet la segmentation des cas en fonction du risque, permettant d'analyser si le processus s'adapte correctement aux différents profils de risque comme l'exigent les politiques de conformité. Source des données : C'est un point de données clé stocké au niveau du dossier dans la table principale des applications au sein d'ACTICO. Exemples FaibleMoyenÉlevé | |||
| Statut de la demande ApplicationStatus | Le résultat final ou l'état actuel de la demande d'intégration client. | ||
| Descriptionn Cet attribut indique la disposition finale d'un dossier, généralement 'Approuvé' ou 'Rejeté'. Il peut également montrer le statut des dossiers en cours. C'est une dimension majeure pour l'analyse basée sur les résultats. Comprendre pourquoi les demandes sont approuvées ou rejetées est un objectif clé du Process Mining KYC. Cet attribut permet de filtrer la carte de processus pour visualiser les parcours typiques des demandes approuvées versus rejetées, aidant à identifier les modèles de processus qui mènent à des résultats indésirables. C'est également la base pour calculer le KPI 'Taux de rejet des demandes'. Pourquoi est-ce important ? : Définit le résultat de chaque cas, permettant une analyse comparative entre les instances de processus réussies et infructueuses et le calcul des taux de rejet. Source des données : C'est un attribut au niveau du dossier, souvent trouvé dans la table principale des dossiers ou des demandes dans ACTICO. Il reflète le statut final de la demande. Exemples ApprouvéRejetéEn coursInformations en attente | |||
| Utilisateur initiateur InitiatingUser | L'ID utilisateur ou le nom de l'employé qui a effectué l'activité. | ||
| Descriptionn Cet attribut identifie l'utilisateur ou l'agent système spécifique responsable de l'exécution d'une activité. Il relie les étapes du processus aux individus ou aux équipes qui les ont effectuées. L'analyse des performances par utilisateur est une exigence courante. Cet attribut permet la création de dashboards qui montrent la répartition de la charge de travail, les temps de traitement individuels et les comparaisons de performances entre les utilisateurs ou les équipes. Il aide à identifier les individus très performants ainsi que ceux qui pourraient nécessiter une formation supplémentaire, et il est indispensable pour comprendre l'allocation et l'utilisation des ressources. Pourquoi est-ce important ? : Relie les activités de processus à des utilisateurs spécifiques, permettant une analyse des performances par individu ou par équipe et aidant à identifier les besoins de formation ou les déséquilibres de ressources. Source des données : Typiquement stocké à côté de chaque événement dans le journal d'événements ou les tables d'historique des transactions d'ACTICO. Consultez la documentation ACTICO. Exemples john.doejane.smithUTILISATEUR_SYSTÈME | |||
| Est Automatisé IsAutomated | Un indicateur signalant si une activité a été effectuée automatiquement par le système ou manuellement par un utilisateur. | ||
| Descriptionn Cet attribut booléen distingue les tâches exécutées par un utilisateur humain et celles effectuées par l'automatisation du système, telles qu'une vérification des antécédents automatisée ou une notation des risques. L'analyse de cet attribut aide à évaluer l'efficacité des initiatives d'automatisation. Elle permet de comparer les temps de traitement entre les étapes automatisées et manuelles, identifie les parties du processus qui sont encore très manuelles et peut mettre en évidence les opportunités d'automatisation supplémentaire pour améliorer l'efficacité et réduire les coûts opérationnels. Pourquoi est-ce important ? : Distingue les tâches humaines des tâches système, ce qui est impératif pour mesurer l'impact de l'automatisation et identifier les opportunités de gains d'efficacité futurs. Source des données : Ceci peut être déduit de l'attribut 'InitiatingUser' (par exemple, si l'utilisateur est 'SYSTEM') ou il peut s'agir d'un indicateur dédié dans le journal d'événements. Consultez la documentation ACTICO. Exemples truefaux | |||
| Est un reprises IsRework | Un indicateur calculé qui identifie si une activité est une étape répétée ou fait partie d'une boucle de reprises. | ||
| Descriptionn Cet attribut booléen signale les activités qui sont effectuées pour la deuxième ou une fois ultérieure au sein du même dossier, comme un 'Examen des documents' qui se produit après une demande d'informations supplémentaires. Il identifie les instances de reprises, qui sont généralement une source d'inefficacité du processus. L'identification du reprises est un objectif principal du Process Mining. Cet indicateur permet de quantifier les reprises, comme le calcul du KPI 'Taux de reprises des documents'. Dans la carte de processus, les boucles de reprise peuvent être mises en évidence pour montrer où le processus revient sur lui-même. Cela aide à identifier les problèmes de qualité ou les domaines où le processus n'est pas 'bon du premier coup'. Pourquoi est-ce important ? : Met en évidence les cas de travail répété, permettant la mesure directe de l'inefficacité des processus et l'identification des activités présentant des problèmes de qualité ou de clarté. Source des données : C'est un attribut calculé. La logique est définie dans l'outil de Process Mining ou pendant la transformation des données pour détecter les activités répétées au sein du même dossier. Exemples truefaux | |||
| État du SLA SlaState | Un statut calculé indiquant si le cas a respecté, enfreint ou risque d'enfreindre son SLA. | ||
| Descriptionn Cet attribut fournit une évaluation catégorique de la performance d'un dossier par rapport à son accord de niveau de service (SLA). Il est dérivé en comparant le temps d'achèvement du dossier (ou le temps actuel pour les dossiers ouverts) à la 'SlaTargetDate'. Cet attribut simplifie le reporting SLA en convertissant les comparaisons de dates en un statut facile à comprendre. Les dashboards peuvent l'utiliser pour des visualisations claires comme des diagrammes circulaires ou des jauges montrant le pourcentage de dossiers 'Respectés' versus 'Violés'. Il est indispensable pour le tableau de bord 'Performance SLA de l'intégration' et contribue directement au le KPI 'Taux d'adhésion SLA de l'intégration'. Pourquoi est-ce important ? : Fournit un statut clair et catégorique de la conformité SLA pour chaque cas, simplifiant la création de rapports et permettant une visualisation facile de la performance par rapport aux objectifs. Source des données : C'est un attribut calculé dérivé de la logique métier qui compare l'horodatage d'achèvement du dossier avec la 'SlaTargetDate'. Exemples AtteintDépasséÀ risque | |||
| Pays Country | Le pays de résidence du client demandant l'intégration. | ||
| Descriptionn Cet attribut spécifie le pays du client, ce qui peut avoir un impact significatif sur le processus KYC. Différentes juridictions ont des exigences réglementaires différentes, ce qui peut déclencher des étapes de processus supplémentaires ou alternatives. L'analyse du processus par pays permet de comparer les performances entre les différentes régions. Elle peut aider à identifier si certains pays connaissent constamment des temps de cycle plus longs ou des taux de rejet plus élevés, indiquant potentiellement des frictions réglementaires ou des défis spécifiques du marché. Cette vue géographique est importante pour les organisations mondiales qui visent à standardiser les processus tout en respectant les besoins de conformité locaux. Pourquoi est-ce important ? : Fournit une dimension géographique pour l'analyse, aidant à comprendre les variations de processus et les différences de performance entre les diverses juridictions réglementaires. Source des données : C'est un élément central d'informations client stocké au niveau du dossier ou du client au sein du système ACTICO. Exemples États-UnisDEUGBRSGP | |||
| Type de client CustomerType | Catégorisation du client, telle que Particulier ou Entreprise. | ||
| Descriptionn Cet attribut classe le demandeur en différentes catégories, par exemple, une personne physique versus une entité corporative. Le processus KYC diffère souvent significativement entre ces types, l'intégration corporative étant beaucoup plus complexe. L'utilisation du type de client comme dimension permet une séparation et une comparaison claires de ces processus distincts au sein du même ensemble de données. Les analystes peuvent filtrer la carte de processus pour afficher uniquement les clients 'Entreprise' afin de comprendre leurs défis uniques, leurs points de blocage et leurs temps de cycle, sans que les données ne soient faussées par le processus client 'Individuel' beaucoup plus simple. Pourquoi est-ce important ? : Permet la segmentation du processus pour différentes catégories de clients, qui ont souvent des flux de processus et des complexités très différents, ce qui conduit à une analyse plus précise. Source des données : C'est un attribut clé stocké au niveau du dossier ou du client au sein d'ACTICO. Exemples ParticulierEntreprisePetite Entreprise | |||
Activités d'intégration client KYC
| Activité | Descriptionn | ||
|---|---|---|---|
| Demande Approuvée | Cette activité représente la décision commerciale finale d'approuver la demande du client pour l'intégration. C'est un jalon clé, généralement capturé comme un changement de statut distinct et final dans le cycle de vie de la demande. | ||
| Pourquoi est-ce important ? : Ce jalon est un précurseur à la création de compte « what-if »gnifie un résultat positif. L'analyse du temps nécessaire pour atteindre ce point est indispensablele pour comprendre la durée du 'chemin idéal'. Source des données : Déduit du champ de statut final dans l'application principale ou la table de cas. Recherchez un statut tel que 'Approuvé', 'Approbation Complète' ou un état terminal positif similaire. Capture Le statut final du dossier est mis à jour à 'Approuvé' dans les données de référence du dossier. Type d'événement inferred | |||
| Demande Rejetée | Représente la décision finale de rejeter la demande du client, mettant fin au processus d'intégration. C'est un état final critique, capturé via un changement de statut final sur l'enregistrement de la demande. | ||
| Pourquoi est-ce important ? : C'est l'événement de fin d'échec principal. L'analyse des dossiers qui se terminent par cette activité est indispensablele pour comprendre les taux de rejet, les raisons de l'échec et améliorer le rendement global du processus. Source des données : Déduit du champ de statut final dans l'application principale ou la table de cas. Recherchez un statut terminal tel que 'Rejeté', 'Refusé' ou 'Clôturé - Rejeté'. Capture Le statut final du dossier est mis à jour à 'Rejeté' dans les données de référence du dossier. Type d'événement inferred | |||
| Demande soumise | Cette activité marque le début du processus d'intégration KYC lorsqu'une nouvelle demande client est officiellement reçue par le système ACTICO. Elle est capturée comme un événement explicite, généralement enregistrée avec un horodatage précis lors de la création d'un nouveau dossier ou enregistrement de demande. | ||
| Pourquoi est-ce important ? : En tant qu'événement de début principal, cette activité est indispensablele pour calculer le temps de cycle global d'intégration et suivre le volume des applications. Elle sert de référence temporelle pour toutes les mesures de performance de processus ultérieures. Source des données : C'est typiquement une entrée explicite dans un journal de création de demande ou de dossier au sein d'ACTICO. Recherchez des tables liées aux événements de soumission de demande ou à l'horodatage de création de l'enregistrement du dossier principal. Capture Événement enregistré lors de la création d'une nouvelle instance de cas d'application. Type d'événement explicit | |||
| Documents client téléchargés | Cette activité se produit lorsque le client fournit l'identification requise et les documents justificatifs via un portail ou un autre canal intégré à ACTICO. Chaque téléchargement de document est généralement capturé comme un événement distinct et explicite dans la gestion des documents du système ou le journal des dossiers. | ||
| Pourquoi est-ce important ? : Ceci marque un jalon clé dépendant du client. Le suivi de cet événement est impératif pour mesurer les temps de réponse client et analyser la durée de la phase d'examen des documents ultérieure. Source des données : Recherchez les journaux d'événements liés à la gestion des documents ou aux pièces jointes au cas d'application. Ceux-ci sont souvent enregistrés dans des tables dédiées à la gestion des documents ou des preuves dans la base de données ACTICO. Capture Événement enregistré par le système lorsqu'un document est joint au cas. Type d'événement explicit | |||
| Évaluation des risques effectuée | Cette activité représente l'exécution du moteur de décision d'ACTICO pour calculer un score ou une évaluation de risque pour la demande client. En tant que fonction principale du système, elle est capturée comme un événement explicite lorsque l'ensemble de règles d'évaluation des risques est exécuté. | ||
| Pourquoi est-ce important ? : L'évaluation des risques est un point de décision pivot qui dicte souvent le chemin de processus ultérieur. L'analyse de cette activité aide à comprendre comment les niveaux de risque influencent les variantes de processus et les délais. Source des données : C'est un événement central au sein d'ACTICO et il devrait être enregistré dans les journaux de décision ou d'exécution. Ces journaux contiennent généralement l'ID de dossier, les règles exécutées et le score de risque résultant. Capture Événement enregistré par le moteur de décision ACTICO à la fin de l'évaluation des risques. Type d'événement explicit | |||
| Examen de conformité initié | Marque le début de la phase d'examen manuel par le département de conformité, souvent pour les applications à haut risque ou signalées. Cela est généralement déduit d'un changement de statut du cas à 'En attente d'examen de conformité' ou de l'affectation du cas à la file d'attente de travail d'un agent de conformité. | ||
| Pourquoi est-ce important ? : Cette activité est le point de départ pour mesurer le goulot d'étranglement de la conformité. Le temps écoulé jusqu'à l''Examen de conformité terminé' est un KPI clé pour identifier les retards dans cette étape cruciale. Source des données : Déduit de l'historique du statut de l'application ou de la piste d'audit. Recherchez un horodatage associé à un changement de statut vers 'En examen de conformité' ou à une affectation à un groupe d'utilisateurs lié à la conformité. Capture Déduit d'un changement de statut du cas à 'En attente de conformité' ou d'une affectation à l'équipe de conformité. Type d'événement inferred | |||
| Examen de conformité terminé | Marque la fin de l'examen manuel par le département de conformité, avec une décision d'approuver, de rejeter ou de demander une action supplémentaire. Cette activité est déduite d'un changement de statut du cas de 'En attente d'examen de conformité' à un état ultérieur comme 'Conformité approuvée'. | ||
| Pourquoi est-ce important ? : C'est l'événement de clôture de l'étape d'examen de conformité. Il est indispensable pour calculer la durée totale de l'examen de conformité et analyser le débit de l'équipe. Source des données : Déduit du journal d'historique du statut de l'application. Recherchez l'horodatage lorsque le cas quitte un état 'En examen de conformité', indiquant qu'une décision a été prise. Capture Déduit d'un changement de statut du cas de 'En attente de conformité' à 'Conformité approuvée' ou similaire. Type d'événement inferred | |||
| Intégration client terminée | C'est l'activité finale du processus, signifiant que le client est entièrement intégré et que le dossier de la demande est clôturé. Ceci est déduit d'un statut final et terminal comme 'Intégré' ou 'Fermé - Approuvé' appliqué au dossier. | ||
| Pourquoi est-ce important ? : En tant qu'événement de fin de succès principal, cette activité est indispensablele pour calculer le temps de cycle complet pour tous les clients intégrés avec succès. Elle fournit l'horodatage final pour l'analyse des chemins heureux. Source des données : Déduit du champ de statut final du cas d'application client. Recherchez un horodatage associé au passage du cas à un statut de succès terminal. Capture Déduit d'une mise à jour finale du statut du cas à 'Terminé' ou 'Clôturé'. Type d'événement inferred | |||
| Compte Créé | Après approbation, cette activité marque la création technique du compte client dans le système bancaire central ou le système de gestion des utilisateurs. Il s'agit souvent d'un événement explicite enregistré par ACTICO après avoir reçu une confirmation de succès du système aval. | ||
| Pourquoi est-ce important ? : Cette activité confirme que le processus a abouti à un résultat commercial tangible. Le temps écoulé entre 'Demande approuvée' et 'Compte créé' peut révéler des retards d'intégration ou des inefficacités dans les étapes finales de provisionnement. Source des données : Cette information serait probablement trouvée dans les journaux d'intégration ou d'interface système au sein d'ACTICO, qui enregistrent le résultat des appels vers des systèmes externes pour le provisionnement de comptes. Capture Événement enregistré après la réception d'une réponse API réussie du système de compte principal. Type d'événement explicit | |||
| Examen des documents terminé | Cette activité signifie qu'un agent a terminé l'examen des documents soumis par le client. Elle est généralement déduite d'un changement de statut sur le document ou le dossier global, tel que 'Documents vérifiés' ou 'Examen terminé'. | ||
| Pourquoi est-ce important ? : C'est un jalon clé pour mesurer l'efficacité du processus de traitement des documents. Le temps entre 'Documents clients téléchargés' et cette activité est un KPI clé pour identifier les retards de traitement manuel. Source des données : Déduit des journaux d'historique de statut pour le cas d'application ou pour les documents individuels. Un changement de statut d'un document de 'En attente d'examen' à 'Approuvé' ou 'Examiné' indique cette activité. Capture Déduit d'un changement de statut du document à 'Vérifié' ou 'Examiné'. Type d'événement inferred | |||
| Examen initial de la demande | Représente le premier examen de la demande soumise, soit par une règle automatisée, soit par un agent humain, pour vérifier l'exhaustivité et l'éligibilité de base. Cette activité est souvent déduite d'un changement de statut de la demande, par exemple, de 'Soumise' à 'En révision'. | ||
| Pourquoi est-ce important ? : L'analyse du temps nécessaire pour réaliser ce premier examen aide à identifier les retards de traitement initiaux. Elle fournit également des informations sur le nombre d'applications qui passent cette première étape sans problème. Source des données : Déduit des tables d'historique de statut ou des journaux d'audit associés au cas d'application client. Comparez l'horodatage lorsque le statut passe d'un état 'nouveau' ou 'soumis' à un état 'en examen'. Capture Détecter le changement de statut de 'Soumis' à 'En cours d'examen' dans le journal d'historique du cas. Type d'événement inferred | |||
| Informations complémentaires demandées | Représente un événement où un examinateur, souvent en conformité ou en souscription, demande plus d'informations ou de documentation au client. Cette action est généralement capturée explicitement car elle implique souvent l'envoi d'une notification au client et la mise en pause du dossier. | ||
| Pourquoi est-ce important ? : Cette activité est un moteur principal de reprises et d'augmentation des temps de cycle. Le suivi de sa fréquence et de son impact est indispensable pour identifier les domaines où la collecte de données initiale peut être améliorée. Source des données : C'est probablement un événement explicite enregistré dans l'historique du dossier ou le journal de communication. Recherchez des événements comme 'RFI Envoyée' (Demande d'informations) ou un changement de statut spécifique comme 'Informations client en attente'. Capture Un événement explicite déclenché par l'utilisateur, tel que 'Envoyer une demande d'informations', est enregistré dans la piste d'audit du dossier. Type d'événement explicit | |||
| Vérification d'identité effectuée | Représente un contrôle automatisé ou manuel pour valider l'identité du client par rapport à des sources de données externes ou internes. Ceci est souvent enregistré comme un événement explicite lorsqu'un appel d'API à un service de vérification tiers est effectué et qu'une réponse est reçue. | ||
| Pourquoi est-ce important ? : Cette activité est une étape de conformité critique. L'analyse de sa durée et de ses résultats aide à identifier les dépendances vis-à-vis des services externes et les points de blocage potentiels dans le processus de vérification. Source des données : Cette information se trouve généralement dans les journaux d'intégration ou les tables d'événements spécifiques qui enregistrent les résultats des contrôles automatisés et des appels de services tiers liés au dossier de la demande. Capture Événement enregistré suite à un appel d'intégration vers un service tiers de vérification d'identité. Type d'événement explicit | |||
| Vérifications d'antécédents initiées | Ceci représente le point où les vérifications des antécédents automatisées ou manuelles, telles que les screenings AML ou d'historique de crédit, sont démarrées. Ceci est souvent enregistré comme un événement explicite lorsque le système déclenche ces vérifications, ce qui peut impliquer des fournisseurs de services externes. | ||
| Pourquoi est-ce important ? : L'initiation des vérifications d'antécédents est une étape importante dans le processus de diligence raisonnable. Le suivi de cette étape aide à comprendre les dépendances et les délais associés aux fournisseurs de données externes. Source des données : Recherchez dans les journaux système ou la piste d'audit les enregistrements indiquant le déclenchement des procédures de vérification des antécédents. Ceux-ci sont souvent liés à l'identifiant du cas d'application principal. Capture Événement enregistré lorsque le moteur de Type d'événement explicit | |||
Guides d'extraction
Étapes
- Obtenir un accès administratif : Connectez-vous à la plateforme ACTICO, telle que le Visual Modeler ou une console d'administration dédiée, en utilisant des identifiants avec des permissions suffisantes pour accéder et configurer les exportations de données.
- Localiser le module d'exportation : Naviguez vers la zone d'administration ou de configuration du système. Recherchez la section responsable des pistes d'audit, de la journalisation ou des exportations de données. Celle-ci peut être intitulée 'Audit Export' ou 'Business Object Export'.
- Créer une nouvelle configuration d'exportation : Initiez le processus de création d'une nouvelle définition d'exportation. Donnez un nom descriptif à la configuration, par exemple, 'KYC_Onboarding_ProcessMind_Export'.
- Définir la source de données : Spécifiez l'objet métier principal à exporter, qui est le
CustomerApplication. Il est indispensable d'appliquer un filtre de plage de dates pour limiter la portée de l'exportation, par exemple, les 6 derniers mois, afin de garantir des tailles de fichier et des performances gérables. - Configurer le fichier de sortie : Définissez le format de sortie sur CSV. Définissez le nom du fichier, par exemple,
kyc_event_log.csv, et confirmez le délimiteur, généralement une virgule. Assurez-vous que les champs de texte sont correctement encadrés pour gérer les caractères spéciaux. - Mapper l'identifiant de cas : Désignez l'identifiant unique de l'objet métier
CustomerApplicationcomme identifiant de cas (ID de cas) pour l'analyse deProcess Mining. Cela relie tous les événements connexes à un seul cas d'intégration. - Définir les mappages d'attributs : Pour chaque colonne requise dans le journal d'événements, mappez-la à l'attribut correspondant dans le modèle d'objet métier ACTICO. Cela inclut l'identifiant de cas (ID de cas), le nom de l'activité (activity name), les horodatages (horodatages) et d'autres attributs recommandés comme le statut (status) ou le niveau de risque (risk level).
- Configurer les mappages d'événements : C'est l'étape la plus critique. Créez une règle ou un mappage spécifique pour chacune des 14 activités métier. Utilisez des déclencheurs système tels que la création d'objet pour 'Application Submitted', les changements de statut pour les étapes de
workflowcomme 'Application Approved', et des modèles de messages de journal d'audit spécifiques pour les événements techniques comme 'Identity Verification Performed'. - Sauvegarder et valider la configuration : Après avoir défini tous les mappages, sauvegardez le fichier de configuration. Utilisez tous les outils de validation disponibles dans ACTICO pour vérifier les erreurs de syntaxe ou les chemins d'attributs incorrects.
- Exécuter et surveiller l'exportation : Exécutez la tâche d'exportation. Surveillez sa progression via le planificateur de tâches du système ou l'interface de surveillance. Vérifiez les journaux pour toute erreur après l'achèvement.
- Récupérer et préparer le fichier : Téléchargez le fichier CSV résultant depuis le chemin de sortie désigné sur le serveur. Avant de le télécharger vers ProcessMind, ouvrez le fichier pour vérifier sa structure et assurez-vous que les formats d'horodatage (horodatage) et de date sont cohérents et correctement analysés.
Configuration
- Niveau de journalisation d'audit : Le niveau de journalisation d'audit à l'échelle du système doit être défini sur un paramètre détaillé, tel que INFO ou FINE. Un niveau moins détaillé comme WARNING ou ERROR ne capturera pas les changements de statut et les exécutions de règles nécessaires pour le
Process Mining. - Source de données d'exportation : La source de données principale doit être configurée pour utiliser l'objet métier
CustomerApplication. Vous devrez peut-être joindre ou référencer des objets associés, tels queCustomerDocument, pour capturer tous les événements pertinents. - Filtre de plage de dates : Utilisez toujours un filtre de plage de dates pour contrôler la quantité de données extraites. Pour une analyse initiale, une période de 3 à 6 mois est recommandée. Pour la production, cela peut être ajusté en fonction des besoins de l'entreprise et des performances du système.
- Logique de mappage des événements : La précision de l'extraction dépend fortement de la façon dont les événements sont associés. Les changements de statut (
on="StatusChange") sont courants pour l'inférence des étapes métier. Les entrées de journal explicites (on="LogEntry") sont utiles pour les événements techniques ou d'appel de service. Les exécutions de règles (on="RuleExecution") sont idéales pour capturer les étapes de décision. - Format de sortie : Sélectionnez CSV comme format de sortie pour une large compatibilité. Assurez-vous que la configuration des délimiteurs et de l'encadrement du texte est correctement définie pour éviter les problèmes d'analyse des données.
- Prérequis : Cette méthode nécessite des permissions administratives pour la plateforme ACTICO. Une compréhension approfondie du modèle d'objet métier KYC, y compris tous les champs de statut et les noms d'attributs pertinents, est indispensablele pour une configuration précise.
a Exemple de requête config
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration>