Votre modèle de données d'onboarding 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'onboarding client.

L'analyse des activités est le cœur du Process Mining. Cet attribut est utilisé pour construire la carte 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 carte 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 cas principal qui regroupe toutes les activités et événements liés pour le parcours d'onboarding 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 essentiel pour reconstituer le parcours de bout en bout 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 goulots d'étranglement et les déviations 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 de bout en bout 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 capture la date et l'heure précises du début d'une activité. Il 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 de bout en bout total du processus d'onboarding. Ces données sont essentielles pour identifier les goulots d'étranglement, 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 essentielle pour le dashboard 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 essentiel 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'onboarding ».

L'analyse du processus par département est essentielle pour le dashboard 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 goulots d'étranglement transversaux et à évaluer l'allocation des ressources sur l'ensemble du processus d'onboarding. C'est la clé pour optimiser les transferts et équilibrer les charges de travail.

Il permet l'analyse du flux de processus et des bottlenecks 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 capture 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 crucial pour identifier les vrais goulots d'étranglement, en les distinguant des files d'attente.

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

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 dashboard 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'onboarding. Cet insight est crucial 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 actionnables 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 est un puissant moteur 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 critique pour l'analyse des résultats. Il est utilisé directement dans le dashboard 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 déviations 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 fraîcheur 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 critique 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 crucial 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 fondamental 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, ce drapeau 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 retravail est essentielle pour repérer les inefficacités de processus et les points de friction pour le client. Le dashboard « Retravail et boucles de processus » utilise cet attribut pour quantifier la fréquence et l'impact du retravail. La réduction du retravail 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 centrée sur le client du processus d'onboarding.

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 au sein de Pega ou à un CRM externe.

Cet attribut stocke le pays associé au client en cours d'onboarding. 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'onboarding 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'onboarding, 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 dashboard « Débit et statut d'onboarding » 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 complété 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 dashboard 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 crucial 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 crucial 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 de bout en bout 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 dashboard d'« Analyse du temps de cycle global d'onboarding » 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 critique qui mesure directement la vitesse et l'efficacité globales du processus d'onboarding 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.

Cette métrique calcule le temps de travail actif pour un événement, mesuré comme la différence entre son heure de fin et son heure de début. Elle représente le temps pendant lequel une ressource était activement engagée dans une tâche.

Le temps de traitement, également connu sous le nom de temps de cycle d'une activité, est essentiel pour une analyse de performance détaillée. Il aide à distinguer les tâches longues (temps de traitement élevé) des longues files d'attente (temps d'attente élevé). Cela permet des efforts d'amélioration plus ciblés, tels que la fourniture de meilleurs outils pour accélérer une tâche par opposition à la réaffectation des ressources pour réduire une file d'attente.

Mesure la durée de travail active des activités, aidant à distinguer entre les tâches inefficaces et les problèmes de ressources ou de file d'attente.

Cette métrique est calculée comme (Heure de fin - Heure de début) pour chaque événement. Elle nécessite la disponibilité des deux champs d'horodatage.

Cet attribut catégorise la demande d'onboarding, 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'onboarding sont plus sujets aux retards ou aux rejets. Cette segmentation est cruciale 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.