Votre modèle de données d'intégration client KYC

Cet attribut enregistre le nom d'une activité commerciale ou d'un événement système, tel que « Demande soumise », « Revue de conformité initiée » ou « Demande rejetée ». Il représente une seule étape dans le processus global d'intégration client.

L'analyse des activités est l'essence du Process Mining. Cet attribut est utilisé pour construire la cartographie des processus, montrant le flux entre les différentes étapes. Il aide à identifier la séquence des événements, à mesurer la fréquence de chaque activité et à déterminer quelles tâches sont les plus courantes ou les plus chronophages.

Cet attribut définit les étapes de la cartographie des processus, rendant possible la visualisation, l'analyse et la compréhension du flux de processus.

Cette information est généralement capturée dans la piste d'audit de Pega (tables d'historique) ou peut être dérivée des changements de statut du cas.

La demande client est l'identifiant de dossier principal qui regroupe toutes les activités et événements liés pour le parcours d'intégration d'un client unique. Chaque demande suit un chemin de la soumission à l'approbation et l'activation du compte, ou au rejet.

En Process Mining, cet attribut est indispensable pour reconstituer le parcours complet de chaque demande. Il permet aux analystes de visualiser la séquence complète des événements, de suivre le statut de chaque demande et de comparer différents chemins. L'analyse des cas basée sur cet ID aide à identifier les variantes de processus courantes, les points de blocage et les écarts par rapport à la procédure standard.

Cet ID est la base du Process Mining, car il connecte tous les événements individuels en instances de processus cohérentes et complet pour l'analyse.

C'est typiquement l'ID de cas principal dans Pega, souvent accessible sous pzInsKey ou un équivalent métier convivial dans l'objet de travail du type de cas principal.

Cet attribut enregistre la date et l'heure précises du début d'une activité. Elle fournit l'ordre chronologique de tous les événements au sein d'un cas de demande client unique.

Les horodatages sont fondamentaux pour l'analyse des processus liée à la performance. Ils sont utilisés pour calculer la durée des activités, le temps d'attente entre les étapes et le temps de cycle complet total du processus d'intégration. Ces données sont indispensables pour identifier les points de blocage, mesurer le respect des SLA et comprendre l'efficacité des processus.

Les horodatages fournissent le contexte chronologique nécessaire pour calculer les durées, analyser la performance des processus et identifier les retards.

C'est une partie standard de la piste d'audit de Pega, souvent trouvée sous pxTimeCreated dans les tables d'historique pour chaque événement.

Cet attribut stocke la date d'achèvement cible pour une demande, telle que définie par l'accord de niveau de service (SLA). Le SLA peut varier en fonction de facteurs tels que le type de client, le niveau de risque ou le produit.

Cette date est indispensablele pour le tableau de bord de « Suivi de la conformité SLA » et le KPI associé. Elle sert de référence par rapport à laquelle la date d'achèvement réelle est comparée. L'analyse des cas qui ne respectent pas leur objectif SLA aide à identifier les retards systémiques et à prioriser les améliorations de processus pour assurer la conformité aux engagements de service.

Il fournit la référence pour mesurer la performance dans les délais, ce qui est indispensable pour la satisfaction client et le contrôle opérationnel.

Pega intègre un cadre de gestion des SLA. Cette date est généralement stockée dans des propriétés comme pySLAGoal ou une propriété SLA définie sur le cas.

Cet attribut identifie l'unité organisationnelle ou l'équipe à laquelle appartient l'utilisateur exécutant, comme « Équipe de filtrage », « Conformité » ou « Opérations d'intégration ».

L'analyse du processus par département est indispensablele pour le tableau de bord de « Distribution de la charge de travail par département ». Elle aide les managers à comprendre comment le travail circule entre les différentes équipes, à identifier les points de blocage transversaux et à évaluer l'allocation des ressources sur l'ensemble du processus d'intégration. C'est la clé pour optimiser les transferts et équilibrer les charges de travail.

Il permet l'analyse du flux de processus et des points de blocage entre différentes unités commerciales, soutenant la gestion des ressources et l'optimisation organisationnelle.

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

Cet attribut enregistre la date et l'heure précises de fin d'une activité. Il est utilisé en conjonction avec l'heure de début pour calculer le temps de traitement des activités individuelles.

Avoir une heure de fin distincte permet une analyse de performance plus précise. Cela aide à différencier le temps de traitement actif (la durée entre l'heure de début et l'heure de fin) et le temps d'attente (la durée entre l'heure de fin d'une activité et l'heure de début de la suivante). C'est impératif pour identifier les vrais points de blocage, en les distinguant des files d'attente.

Permet le calcul précis du temps de traitement des activités, ce qui est indispensable pour une analyse de performance détaillée et l'identification des points de blocage.

Ceci peut être disponible dans la piste d'audit de Pega ou peut nécessiter d'être dérivé en utilisant l'heure de début de l'événement subséquent comme heure de fin de l'événement actuel.

Lorsqu'une demande a un statut final « Rejeté », cet attribut fournit la raison spécifique, telle que « Vérification d'antécédents échouée », « Documentation incomplète » ou « Profil à haut risque ».

Cet attribut est le principal moteur du tableau de bord d'« Analyse des rejets de demandes ». En segmentant les cas rejetés par raison, l'entreprise peut identifier les points d'échec les plus courants dans le processus d'intégration. Cet insight est impératif pour mettre en œuvre des améliorations ciblées afin de réduire le taux de rejet, d'améliorer l'expérience client et d'augmenter l'efficacité opérationnelle.

Fournit des insights concrètes sur les raisons des échecs de demandes, permettant des améliorations ciblées des processus pour augmenter le taux de succès.

Il s'agirait probablement d'une propriété spécifique définie sur le cas lorsqu'il passe à un statut « Rejeté ». Consultez la documentation Pega KYC pour les champs standard de raison de rejet.

Cet attribut représente le risque évalué associé au client, souvent catégorisé comme « Faible », « Moyen » ou « Élevé ». Le niveau de risque est généralement déterminé par un moteur de notation automatisé basé sur les données client et les résultats de filtrage.

Le niveau de risque influe considérablement sur de variation de processus. Les demandes à haut risque nécessitent souvent des étapes de diligence raisonnable supplémentaires, telles qu'une revue de conformité renforcée, entraînant des temps de cycle plus longs. L'analyse du processus par niveau de risque aide à justifier ces variations et à garantir que les contrôles des risques fonctionnent efficacement sans causer de retards excessifs.

Explique les variations dans le chemin du processus et la durée, car le niveau de risque détermine souvent le niveau de diligence raisonnable requis.

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

Cet attribut indique le statut global de la demande à la fin du processus, tel que « Approuvée », « Rejetée » ou « Retirée ». Il peut également refléter le dernier statut connu pour les cas en cours.

C'est une dimension majeure pour l'analyse des résultats. Il est utilisé directement dans le tableau de bord d'« Analyse des rejets de demandes » pour segmenter les cas et comprendre pourquoi certains résultats se produisent. L'analyse des flux de processus menant à différents statuts aide à identifier les meilleures pratiques pour les cas approuvés et les causes profondes pour les cas rejetés.

Il définit le résultat commercial d'un case, permettant une analyse puissante comparant les parcours réussis aux parcours infructueux.

C'est typiquement le statut final (pyStatusWork) de l'objet de travail du cas dans Pega.

Cet attribut stocke l'ID de l'employé ou de l'utilisateur système responsable de l'exécution d'une tâche spécifique dans le processus KYC, tel qu'un responsable de la conformité ou un robot de filtrage automatisé. Pour les étapes automatisées, cela pourrait être un ID de système ou de compte de service.

L'analyse par utilisateur aide à comprendre la distribution de la charge de travail, la performance individuelle et les besoins en formation. Elle peut également être utilisée pour enquêter sur les écarts de processus en identifiant quels utilisateurs ou équipes sont impliqués dans des flux de processus non standard.

Cet attribut lie les activités de processus à des individus ou des équipes spécifiques, permettant l'analyse de la charge de travail, l'évaluation des performances et les contrôles de conformité.

C'est un champ standard dans la piste d'audit de Pega, généralement stocké comme pxUpdateOperator ou une propriété similaire dans les tables d'historique.

Cet attribut indique l'heure la plus récente à laquelle les données ont été extraites du système source. Elle est généralement la même pour tous les enregistrements au sein d'un seul chargement de données.

Cet horodatage est important pour comprendre la la réactualisation des données analysées. Il permet aux utilisateurs de savoir à quel point l'analyse des processus est actuelle et quand la prochaine mise à jour des données est attendue, ce qui est indispensable pour les dashboards de surveillance opérationnelle.

Informe les utilisateurs sur l'actualité des data, en s'assurant qu'ils comprennent si l'analyse reflète l'état actuel ou une période passée.

Cette valeur est générée et estampillée sur le jeu de données pendant le processus d'extraction, transformation et chargement (ETL) des données.

Cet attribut booléen est vrai si l'activité a été exécutée par un agent automatisé, tel qu'un moteur de filtrage ou une règle système, et faux si elle a été réalisée par un utilisateur humain.

Distinguer les activités automatisées et manuelles est impératif pour l'analyse de l'automatisation. Cela aide à mesurer l'efficacité de l'automatisation existante, à identifier les tâches manuelles qui sont de bons candidats pour une future automatisation, et à comprendre l'interaction entre les acteurs humains et système dans le processus.

Il sépare les activités humaines des activités système, ce qui est indispensable pour toute initiative d'automatisation ou d'analyse.

Ceci peut être dérivé de l'ID utilisateur associé à l'événement. Si l'OperatorId correspond à un compte système ou agent connu, cet indicateur est défini sur vrai.

Cet attribut booléen est vrai si une activité spécifique, telle que la « Revue de documents », se produit plus d'une fois dans le même cas. Il est souvent déclenché par des événements comme « Informations supplémentaires demandées ».

L'identification du reprises est indispensablele pour repérer les inefficacités de processus et les points de blocage pour le client. Le tableau de bord « Retravail et boucles de processus » utilise cet attribut pour quantifier la fréquence et l'impact du reprises. La réduction du reprises est souvent un objectif clé, car elle conduit à un traitement plus rapide, à des coûts opérationnels inférieurs et à une meilleure expérience client.

Met en évidence les inefficacités de processus, les tâches redondantes et les boucles, qui sont les principales cibles d'amélioration des processus.

Ce drapeau est dérivé pendant l'analyse des données en vérifiant les noms d'activités répétés au sein du même ID de cas. Par exemple, si « Revue de documents terminée » apparaît une deuxième fois.

Cet attribut est l'ID unique qui relie la demande à un enregistrement client dans le système de données de référence. Il représente l'entité, qu'il s'agisse d'un individu ou d'une organisation, qui est l'objet du processus KYC.

Alors que l'ID de demande suit le processus, l'ID client permet une analyse sur plusieurs demandes du même client ou pour enrichir les données de processus avec des attributs spécifiques au client comme le segment ou l'historique. Cela permet une vue orientée client du processus d'intégration.

Connecte les data de processus aux data de référence client, permettant une analyse plus riche basée sur les attributs et l'historique du client.

Il s'agirait d'une propriété centrale sur le cas KYC, le reliant au modèle de données client dans Pega ou à un CRM externe.

Cet attribut stocke le pays associé au client en cours d'intégration. Cette information est un intrant clé pour l'évaluation des risques et la détermination du niveau de diligence raisonnable requis.

En analyse, le pays du client peut révéler des modèles importants. Certaines juridictions peuvent être associées à un risque plus élevé, entraînant des processus d'intégration plus longs et plus complexes. Cette dimension permet une analyse de performance basée sur la géographie et aide à garantir que les exigences de conformité régionales sont respectées efficacement.

Permet une analyse géographique du processus, souvent liée à la complexité réglementaire et aux niveaux de risque.

Il s'agirait d'une propriété sur l'objet de données client associé au cas.

Cet attribut spécifie le produit ou le service pour lequel le client est onboardé, tel qu'un « Compte bancaire de détail », un « Prêt aux entreprises » ou des « Services d'investissement ».

Le produit peut influencer le processus d'intégration, car différents produits peuvent avoir des exigences réglementaires et une complexité différentes. L'analyse du processus par produit aide à identifier si des lignes de produits spécifiques ont des temps de cycle plus longs ou des taux de rejet plus élevés, fournissant des insights pour l'optimisation des processus spécifiques aux produits.

Permet de segmenter l'analyse de processus par ligne de produits, révélant les différences de performance et les opportunités d'optimisation.

Il s'agirait d'une propriété sur le cas, sélectionnée au début du processus de demande.

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

C'est un attribut clé pour le tableau de bord « Débit et statut d'intégration » et l'analyse de la « Vitesse de vérification des documents ». Il permet une vue granulaire de l'une des zones de goulot d'étranglement les plus courantes. En suivant le temps que les documents restent dans chaque statut, l'entreprise peut identifier les retards dans la soumission client ou la revue interne.

Offre une visibilité sur le sous-processus de traitement des documents, aidant à identifier et à résoudre les retards courants dans la vérification des documents.

Il s'agirait probablement d'une propriété sur un objet de données lié ou une liste de pages associée au cas principal, suivant chaque document requis. Consultez la documentation Pega KYC.

Cet attribut catégorise chaque cas terminé comme « À temps » ou « En retard » en se basant sur une comparaison entre son horodatage d'achèvement réel et sa « Date cible SLA ».

C'est la métrique centrale pour le tableau de bord de « Suivi de la conformité SLA » et le KPI de « Taux de conformité SLA ». Il offre une vue claire et d'un coup d'œil de la performance par rapport aux engagements de niveau de service. L'analyse des caractéristiques des cas en retard aide à identifier les causes profondes des retards et à atténuer les risques de futures violations des SLA.

Mesure directement la performance par rapport aux engagements, ce qui est impératif pour la gestion opérationnelle, la conformité et la satisfaction client.

Ceci est dérivé en comparant l'horodatage de l'activité finale du cas avec le champ SlaTargetDate. Si le temps d'achèvement est après la cible, le statut est « En retard ».

Cet attribut spécifie l'application source où l'événement a été enregistré. Pour ce processus, la valeur serait constamment « Pega KYC ».

Même si cela peut sembler redondant si toutes les données proviennent d'un seul système, cet attribut est impératif pour la gouvernance des données et devient vital lors de l'intégration de données provenant de plusieurs systèmes. Il assure la clarté sur la provenance des données et aide à résoudre les problèmes d'intégration des données.

Il fournit un contexte essentiel sur l'origine des data, assurant la gouvernance des data et permettant l'analyse sur plusieurs systèmes sources.

Il s'agit généralement d'une valeur statique ajoutée pendant le processus d'extraction et de transformation des données pour étiqueter l'origine du jeu de données.

Cette métrique calculée mesure la durée complet pour chaque demande client, du tout premier événement au dernier. Elle est généralement calculée comme la différence entre l'horodatage de l'activité finale et l'activité initiale pour un cas donné.

Le temps de cycle est un indicateur clé de performance (KPI) principal pour l'efficacité des processus et l'expérience client. Il est utilisé dans le tableau de bord d'« Analyse du temps de cycle global d'intégration » pour surveiller les temps de traitement moyens, identifier les cas de longue durée et suivre l'impact des initiatives d'amélioration des processus au fil du temps.

C'est un KPI clé qui mesure directement la vitesse 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 prenant la différence entre les horodatages maximum et minimum pour chaque ID de cas.

Cet attribut catégorise la demande d'intégration, par exemple, « Client individuel », « Client entreprise » ou « Particulier fortuné ». Différents types de cas suivent souvent des variations de processus distinctes avec des étapes, des SLA et des profils de risque différents.

L'analyse du processus par type de cas permet une comparaison plus pertinente de la performance. Elle aide à comprendre si certains types d'intégration sont plus sujets aux retards ou aux rejets. Cette segmentation est indispensablele pour adapter les améliorations de processus aux besoins spécifiques des différents parcours clients.

Permet la segmentation des data de processus en catégories distinctes, ce qui permet une analyse de performance plus précise et pertinente.

C'est typiquement le nom de la classe de l'instance de cas dans Pega, ou une propriété dédiée sur le cas qui définit son type.