Votre modèle de données pour l’intégration client KYC

Cet attribut indique le nom d’une activité métier ou d’un événement système, par exemple « Demande soumise », « Examen de conformité lancé » ou « Demande rejetée ». Il correspond à une étape du processus global d’intégration du client.

L’analyse des activités est au cœur du Process Mining. Cet attribut sert à construire la carte du processus et à visualiser les enchaînements entre les étapes. Il permet de repérer la séquence des événements, de mesurer la fréquence de chaque activité et d’identifier les tâches les plus courantes ou les plus longues.

Cet attribut définit les étapes de la carte du processus et permet ainsi de visualiser, d’analyser et de comprendre le flux de travail.

Ces informations sont généralement consignées dans l’historique d’audit de Pega (tables d’historique) ou peuvent être déduites des changements d’état du cas.

La demande client est l’identifiant principal du cas. Elle regroupe toutes les activités et tous les événements liés au parcours d’intégration d’un client. Chaque demande suit un chemin qui va de son envoi à son approbation et à l’activation du compte, ou à son rejet.

En Process Mining, cet attribut est essentiel pour reconstituer le parcours complet de chaque demande. Il permet aux analystes de consulter la séquence complète des événements, de suivre l’état de chaque demande et de comparer les différents parcours. L’analyse des cas à partir de cet identifiant aide à repérer les variantes courantes du processus, les goulots d’étranglement et les écarts par rapport à la procédure standard.

Cet identifiant est la base du Process Mining : il relie chaque événement à une instance de processus cohérente, de bout en bout, pour permettre son analyse.

Il s’agit généralement de l’ID de cas principal dans Pega, souvent accessible sous le nom pzInsKey ou sous un nom plus parlant pour les équipes métier dans l’objet de travail du type de cas principal.

Cet attribut enregistre la date et l’heure précises auxquelles une activité a commencé. Il permet de remettre dans l’ordre chronologique tous les événements d’un même cas de demande client.

Les horodatages sont indispensables à l’analyse des performances des processus. Ils servent à calculer la durée des activités, le temps d’attente entre les étapes et le temps de cycle total de bout en bout du processus d’intégration. Ces données sont essentielles pour repérer les goulots d’étranglement, mesurer le respect des SLA et comprendre l’efficacité du processus.

Les horodatages fournissent le contexte chronologique nécessaire au calcul des durées, à l’analyse des performances du processus et à la détection des retards.

Cette information figure généralement dans l’historique d’audit de Pega, souvent sous la forme de pxTimeCreated dans les tables d’historique de chaque événement.

Cet attribut contient la date cible de fin d’une demande, définie par l’accord de niveau de service (SLA). Le SLA peut varier selon le type de client, le niveau de risque ou le produit.

Cette date est essentielle au Dashboard « Suivi du respect des SLA » et à l’indicateur clé de performance associé. Elle sert de référence pour comparer la date réelle de fin à la date prévue. L’analyse des cas qui dépassent l’échéance du SLA aide à repérer les retards systémiques et à prioriser les améliorations du processus afin de respecter les engagements de service.

Elle sert de référence pour mesurer le respect des délais, un facteur important pour la satisfaction client et le contrôle opérationnel.

Pega intègre un cadre de gestion des SLA. La date est généralement enregistrée dans des propriétés telles que pySLAGoal ou dans une propriété de SLA définie pour le cas.

Cet attribut indique l’état global de la demande à la fin du processus, par exemple « Approuvé », « Rejeté » ou « Retiré ». Pour les cas en cours, il peut également refléter le dernier état connu.

Il s’agit d’une dimension essentielle pour l’analyse des résultats. Elle est utilisée directement dans le Dashboard « Analyse des rejets de demandes » pour segmenter les cas et comprendre les raisons des différents résultats. L’analyse des flux de processus qui mènent à chaque état aide à repérer les bonnes pratiques pour les cas approuvés et les causes profondes des rejets.

Cet attribut définit le résultat métier d’un cas et permet de comparer les parcours qui aboutissent à ceux qui échouent.

Il s’agit généralement de l’état final (pyStatusWork) de l’objet de travail du cas dans Pega.

Cet attribut enregistre la date et l’heure précises auxquelles une activité s’est terminée. Associé à l’heure de début, il permet de calculer la durée de traitement de chaque activité.

Une heure de fin distincte permet d’analyser les performances avec plus de précision. Elle aide à distinguer le temps de traitement actif, entre le début et la fin d’une activité, du temps d’attente, entre la fin d’une activité et le début de la suivante. Cette distinction est essentielle pour repérer les véritables goulots d’étranglement et les différencier des files d’attente.

Elle permet de calculer précisément la durée de traitement des activités, indispensable à l’analyse détaillée des performances et à la détection des goulots d’étranglement.

Cette information peut figurer dans l’historique d’audit de Pega. À défaut, elle peut être déduite en utilisant l’heure de début de l’événement suivant comme heure de fin de l’événement en cours.

Lorsque l’état final d’une demande est « Rejeté », cet attribut en précise le motif, par exemple « Vérification des antécédents échouée », « Documents incomplets » ou « Profil à risque élevé ».

Cet attribut est le principal indicateur du Dashboard « Analyse des rejets de demandes ». En répartissant les cas rejetés selon leur motif, l’entreprise peut repérer les causes d’échec les plus fréquentes dans le processus d’intégration. Ces informations permettent de cibler les améliorations pour réduire le taux de rejet, améliorer l’expérience client et accroître l’efficacité opérationnelle.

Il précise les raisons de l’échec des demandes et permet de cibler les améliorations du processus pour augmenter le taux de réussite.

Il s’agit probablement d’une propriété spécifique définie sur le cas lorsque son état passe à « Rejeté ». Consultez la documentation de Pega KYC pour connaître les champs standard associés aux motifs de rejet.

Cet attribut représente le risque évalué pour le client, généralement classé comme « Faible », « Moyen » ou « Élevé ». Le niveau de risque est habituellement déterminé par un moteur de notation automatisé, à partir des données du client et des résultats des vérifications.

Le niveau de risque influe fortement sur le déroulement du processus. Les demandes à risque élevé nécessitent souvent des vérifications complémentaires, comme un examen de conformité approfondi, ce qui allonge le temps de cycle. L’analyse du processus par niveau de risque aide à justifier ces différences et à vérifier l’efficacité des contrôles sans entraîner de retards excessifs.

Il permet d’expliquer les différences de parcours et de durée, car le niveau de risque détermine souvent le degré de vigilance requis.

Il s’agit d’une propriété calculée sur le cas, renseignée par une règle de décision ou un modèle de notation Pega. Consultez la documentation de Pega KYC.

Cet attribut identifie l’unité organisationnelle ou l’équipe à laquelle appartient l’utilisateur qui a effectué l’activité, par exemple « Équipe de vérification », « Conformité » ou « Opérations d’intégration ».

L’analyse du processus par service est essentielle au Dashboard « Répartition de la charge de travail par service ». Elle aide les responsables à comprendre comment le travail passe d’une équipe à l’autre, à repérer les goulots d’étranglement entre services et à évaluer la répartition des ressources dans l’ensemble du processus d’intégration. Elle permet aussi d’optimiser les transferts de dossiers et d’équilibrer les charges de travail.

Cet attribut permet d’analyser le flux du processus et les goulots d’étranglement entre les différentes unités opérationnelles, afin de mieux gérer les ressources et d’optimiser l’organisation.

Cette information est généralement associée au profil de l’utilisateur dans Pega (enregistrement Operator ID) et peut être jointe aux données d’événement. La propriété peut être pyWorkGroup.

Cet attribut contient l’ID de l’employé ou de l’utilisateur système chargé d’effectuer une tâche précise dans le processus KYC, par exemple un responsable conformité ou un robot de vérification automatisée. Pour les étapes automatisées, il peut s’agir de l’ID d’un compte système ou de service.

L’analyse par utilisateur permet de comprendre la répartition de la charge de travail, les performances individuelles et les besoins de formation. Elle peut aussi aider à examiner les écarts du processus en identifiant les utilisateurs ou les équipes associés à des parcours non standard.

Cet attribut relie les activités du processus à des personnes ou à des équipes précises, ce qui permet d’analyser la charge de travail, d’évaluer les performances et d’effectuer des contrôles de conformité.

Il s’agit d’un champ standard de l’historique d’audit de Pega, généralement enregistré sous le nom pxUpdateOperator ou dans une propriété similaire des tables d’historique.

Cet attribut booléen prend la valeur « vrai » si l’activité a été exécutée par un agent automatisé, comme un moteur de vérification ou une règle système, et « faux » si elle a été effectuée par une personne.

Distinguer les activités automatisées des activités manuelles est essentiel pour analyser l’automatisation. Cela permet de mesurer l’efficacité de l’automatisation existante, de repérer les tâches manuelles qui pourraient être automatisées et de comprendre les interactions entre les personnes et les systèmes dans le processus.

Il distingue les activités effectuées par des personnes de celles prises en charge par des systèmes, une distinction fondamentale pour toute initiative ou analyse de l’automatisation.

Cet attribut peut être déduit de l’ID utilisateur associé à l’événement. Si OperatorId correspond à un compte système ou à un compte d’agent connu, l’attribut prend la valeur « vrai ».

Cet attribut indique la date et l’heure de la dernière extraction des données depuis le système source. Sa valeur est généralement identique pour tous les enregistrements d’un même chargement de données.

Cet horodatage permet de savoir si les données analysées sont à jour. Les utilisateurs peuvent ainsi connaître la date de référence de l’analyse du processus et savoir quand la prochaine mise à jour est prévue. Cette information est essentielle pour les Dashboards de suivi opérationnel.

Il renseigne les utilisateurs sur la date des données et leur permet de savoir si l’analyse reflète la situation actuelle ou une période antérieure.

Cette valeur est générée et ajoutée au jeu de données lors du processus d’extraction, de transformation et de chargement des données (ETL).

Cet attribut suit l’état des documents requis pour le processus KYC. Il peut prendre des valeurs telles que « En attente du client », « Reçu », « Vérifié » ou « Rejeté ». Cet état peut changer plusieurs fois au cours d’un même cas.

Cet attribut est essentiel au Dashboard « Volume et état des intégrations » et à l’analyse « Vitesse de vérification des documents ». Il permet d’examiner en détail l’un des principaux goulots d’étranglement du processus. En suivant la durée pendant laquelle les documents restent dans chaque état, l’entreprise peut repérer les retards liés à leur envoi par le client ou à leur examen en interne.

Il donne une visibilité sur le sous-processus de traitement des documents et aide à repérer et à résoudre les retards fréquents lors de leur vérification.

Il s’agit probablement d’une propriété d’un objet de données associé au cas principal, ou d’une liste de pages qui lui est rattachée, permettant de suivre chaque document requis. Consultez la documentation de Pega KYC.

Cet attribut classe chaque cas terminé comme « Dans les délais » ou « En retard », en comparant son horodatage réel de fin à sa « Date cible du SLA ».

Il s’agit de la métrique principale du Dashboard « Suivi du respect des SLA » et de l’indicateur clé de performance « Taux de respect des SLA ». Il donne une vue claire et immédiate des performances par rapport aux engagements de service. L’analyse des caractéristiques des cas en retard aide à repérer les causes profondes des retards et à réduire le risque de non-respect futur des SLA.

Il mesure directement le respect des engagements, un élément important pour la gestion opérationnelle, la conformité et la satisfaction client.

Cet attribut est calculé en comparant l’horodatage de la dernière activité du cas au champ SlaTargetDate. Si le cas est terminé après la date cible, son état est « En retard ».

Cet attribut est l’ID unique qui relie la demande à la fiche client dans le système de données de référence. Il désigne la personne ou l’organisation concernée par le processus KYC.

L’ID de demande permet de suivre le processus, tandis que l’ID client permet d’analyser plusieurs demandes d’un même client ou d’enrichir les données du processus avec des attributs propres au client, comme son segment ou son historique. Il est ainsi possible d’analyser le processus d’intégration du point de vue du client.

Il relie les données du processus aux données de référence du client et permet ainsi d’enrichir l’analyse à partir des attributs et de l’historique du client.

Il s’agit d’une propriété centrale du cas KYC, qui le relie au modèle de données client dans Pega ou dans un CRM externe.

Cet attribut indique le pays associé au client en cours d’intégration. Cette information est prise en compte dans l’évaluation des risques et la détermination du niveau de vigilance requis.

L’analyse du pays du client peut révéler des tendances importantes. Certaines juridictions peuvent présenter un risque plus élevé et entraîner des processus d’intégration plus longs et plus complexes. Cette dimension permet d’analyser les performances par zone géographique et de vérifier que les exigences régionales de conformité sont respectées efficacement.

Il permet d’analyser le processus par zone géographique, un facteur souvent lié à la complexité réglementaire et au niveau de risque.

Il s’agit d’une propriété de l’objet de données client associé au cas.

Cet attribut précise le produit ou le service pour lequel le client est en cours d’intégration, par exemple « Compte bancaire de détail », « Prêt aux entreprises » ou « Services d’investissement ».

Le produit peut influer sur le processus d’intégration, car les exigences réglementaires et le niveau de complexité varient d’un produit à l’autre. L’analyse du processus par produit aide à repérer les gammes dont le temps de cycle est plus long ou le taux de rejet plus élevé, et à déterminer comment optimiser les processus propres à chaque produit.

Il permet de segmenter l’analyse du processus par gamme de produits, de repérer les écarts de performance et de cerner les possibilités d’optimisation.

Il s’agit d’une propriété du cas, sélectionnée au début du processus de demande.

Cet attribut booléen prend la valeur « vrai » si une activité précise, comme « Examen des documents », se produit plusieurs fois dans un même cas. Il peut notamment être déclenché par un événement tel que « Informations complémentaires demandées ».

Repérer les reprises est essentiel pour détecter les inefficacités du processus et les difficultés rencontrées par le client. Le Dashboard « Reprises et boucles du processus » utilise cet attribut pour mesurer leur fréquence et leur impact. Réduire les reprises est souvent un objectif important : cela accélère le traitement, diminue les coûts opérationnels et améliore l’expérience client.

Il met en évidence les inefficacités du processus, les tâches redondantes et les boucles, autant de cibles prioritaires pour améliorer le processus.

Cet attribut est calculé lors de l’analyse des données en recherchant les activités répétées pour un même ID de cas. Par exemple, si « Examen des documents terminé » apparaît une deuxième fois.

Cet attribut précise l’application source dans laquelle l’événement a été enregistré. Pour ce processus, sa valeur serait toujours « Pega KYC ».

Cet attribut peut sembler redondant lorsque toutes les données proviennent d’un seul système. Il reste toutefois essentiel à la gouvernance des données et devient indispensable lorsque des données issues de plusieurs systèmes sont intégrées. Il permet de connaître clairement leur provenance et facilite le diagnostic des problèmes d’intégration.

Il précise l’origine des données, contribue à leur gouvernance et permet de les analyser lorsqu’elles proviennent de plusieurs systèmes sources.

Il s’agit généralement d’une valeur statique ajoutée au jeu de données lors de l’extraction et de la transformation des données pour en indiquer l’origine.

Cette métrique calculée mesure la durée de bout en bout de chaque demande client, du premier au dernier événement. Elle correspond généralement à la différence entre l’horodatage de la dernière activité et celui de la première activité d’un cas donné.

Le temps de cycle est un indicateur clé de performance (KPI) de l’efficacité du processus et de l’expérience client. Le Dashboard « Analyse du temps de cycle global de l’intégration » permet de suivre les durées moyennes de traitement, de repérer les cas qui s’éternisent et de mesurer l’effet des initiatives d’amélioration du processus au fil du temps.

Cet indicateur clé de performance mesure directement la rapidité et l’efficacité globales du processus d’intégration du point de vue du client.

Cette métrique est calculée dans l’outil de Process Mining en soustrayant, pour chaque ID de cas, l’horodatage minimum de l’horodatage maximum.

Cet attribut classe la demande d’intégration, par exemple « Client particulier », « Client entreprise » ou « Particulier fortuné ». Les différents types de cas suivent souvent des variantes distinctes du processus, avec des étapes, des SLA et des profils de risque différents.

L’analyse du processus par type de cas permet de comparer les performances de façon plus pertinente. Elle aide à déterminer si certains types d’intégration sont davantage sujets aux retards ou aux rejets. Cette segmentation est essentielle pour adapter les améliorations du processus aux besoins propres à chaque parcours client.

Il permet de répartir les données du processus en catégories distinctes et d’analyser les performances avec plus de précision et de pertinence.

Il s’agit généralement du nom de classe de l’instance de cas dans Pega ou d’une propriété dédiée qui définit le type du cas.