Ihr Daten-Template für das KYC-Kunden-Onboarding

Dieses Attribut erfasst den Namen einer Geschäftsaktivität oder eines Systemereignisses, etwa „Antrag eingereicht“, „Compliance-Prüfung initiiert“ oder „Antrag abgelehnt“. Es stellt einen einzelnen Schritt im gesamten Onboarding-Prozess dar.

Die Analyse von Aktivitäten bildet den Kern des Process Mining. Dieses Attribut wird zum Aufbau der Prozesslandkarte verwendet und zeigt den Ablauf zwischen den einzelnen Schritten. Es hilft dabei, die Ereignisabfolge zu erkennen, die Häufigkeit jeder Aktivität zu messen und die häufigsten oder zeitaufwendigsten Tasks zu bestimmen.

Dieses Attribut definiert die Schritte in der Prozesslandkarte und macht es möglich, den Prozessablauf zu visualisieren, zu analysieren und zu verstehen.

Diese Informationen werden typischerweise im Audit Trail von Pega, also in den History Tables, erfasst oder aus den Statusänderungen des Cases abgeleitet.

Der Kundenantrag ist die primäre Case-Kennung. Sie fasst alle zugehörigen Aktivitäten und Ereignisse für den Onboarding-Prozess eines einzelnen Kunden zusammen. Jeder Antrag durchläuft einen Weg von der Einreichung bis zur Genehmigung und Kontoaktivierung oder bis zur Ablehnung.

Im Process Mining ist dieses Attribut entscheidend, um den durchgängigen Weg jedes Antrags zu rekonstruieren. Es ermöglicht Analysten, die vollständige Ereignisabfolge einzusehen, den Status jedes Antrags zu verfolgen und verschiedene Prozesspfade zu vergleichen. Die Analyse anhand dieser ID hilft dabei, häufige Prozessvarianten, Engpässe und Abweichungen vom Standardverfahren zu erkennen.

Diese ID bildet die Grundlage für Process Mining, da sie alle einzelnen Ereignisse zu zusammenhängenden, durchgängigen Prozessinstanzen für die Analyse verbindet.

In Pega ist dies typischerweise die primäre Case-ID. Sie ist häufig als pzInsKey oder als geschäftsfreundliche Entsprechung im zentralen Work Object des Case-Typs verfügbar.

Dieses Attribut erfasst das genaue Datum und die Uhrzeit, zu denen eine Aktivität begonnen hat. Es liefert die chronologische Reihenfolge aller Ereignisse innerhalb eines einzelnen Kundenantrags.

Timestamps sind eine zentrale Grundlage für die leistungsbezogene Prozessanalyse. Sie dienen dazu, die Dauer von Aktivitäten, die Wartezeit zwischen Schritten und die gesamte Durchlaufzeit des Onboarding-Prozesses zu berechnen. Diese Daten sind entscheidend, um Engpässe zu erkennen, die Einhaltung von SLAs zu messen und die Prozesseffizienz zu verstehen.

Timestamps liefern den chronologischen Kontext, der für die Berechnung von Dauern, die Analyse der Prozessleistung und die Erkennung von Verzögerungen erforderlich ist.

Dies ist ein Standardbestandteil des Audit Trails von Pega und wird in History Tables für jedes Ereignis häufig als pxTimeCreated gespeichert.

Wenn der finale Status eines Antrags „Abgelehnt“ lautet, gibt dieses Attribut den konkreten Grund an, etwa „Hintergrundprüfung nicht bestanden“, „Unvollständige Dokumentation“ oder „Hohes Risikoprofil“.

Dieses Attribut ist der wichtigste Faktor für das Dashboard „Analyse der Antragsablehnungen“. Durch die Segmentierung abgelehnter Cases nach Grund kann das Unternehmen die häufigsten Fehlerstellen im Onboarding-Prozess erkennen. Diese Erkenntnisse sind entscheidend, um gezielte Verbesserungen umzusetzen, die Ablehnungsquote zu senken, die Customer Experience zu verbessern und die operative Effizienz zu steigern.

Liefert verwertbare Erkenntnisse zu den Ursachen fehlgeschlagener Anträge und ermöglicht gezielte Prozessverbesserungen, um die Erfolgsquote zu erhöhen.

Dabei handelt es sich wahrscheinlich um eine bestimmte Eigenschaft, die beim Übergang des Cases in den Status „Abgelehnt“ gesetzt wird. Prüfen Sie die Pega-KYC-Dokumentation auf Standardfelder für Ablehnungsgründe.

Dieses Attribut identifiziert die Organisationseinheit oder das Team, dem der ausführende Benutzer angehört, etwa „Screening-Team“, „Compliance“ oder „Onboarding Operations“.

Die Analyse des Prozesses nach Abteilung ist für das Dashboard „Arbeitslastverteilung nach Abteilung“ entscheidend. Sie hilft Führungskräften zu verstehen, wie die Arbeit zwischen verschiedenen Teams fließt, funktionsübergreifende Engpässe zu erkennen und die Ressourcenverteilung im gesamten Onboarding-Prozess zu bewerten. Damit lassen sich Übergaben gezielt verbessern und Arbeitslasten ausgleichen.

Ermöglicht die Analyse von Prozessabläufen und Engpässen zwischen verschiedenen Geschäftsbereichen und unterstützt so das Ressourcenmanagement sowie die Optimierung der Organisation.

Diese Informationen sind typischerweise dem Benutzerprofil in Pega, dem Operator-ID-Datensatz, zugeordnet und können mit den Ereignisdaten verknüpft werden. Die Eigenschaft kann pyWorkGroup sein.

Dieses Attribut gibt den Gesamtstatus des Antrags am Ende des Prozesses an, etwa „Genehmigt“, „Abgelehnt“ oder „Zurückgezogen“. Bei laufenden Cases kann es auch den zuletzt bekannten Status abbilden.

Für die Ergebnisanalyse ist dies eine zentrale Dimension. Im Dashboard „Analyse der Antragsablehnungen“ wird das Attribut direkt verwendet, um Cases zu segmentieren und zu verstehen, warum bestimmte Ergebnisse eintreten. Die Analyse der Prozessabläufe, die zu unterschiedlichen Status führen, hilft dabei, Best Practices für genehmigte Cases und die Ursachen abgelehnter Cases zu erkennen.

Es definiert das Geschäftsergebnis eines Cases und ermöglicht aussagekräftige Vergleiche zwischen erfolgreichen und nicht erfolgreichen Prozesspfaden.

Dies ist typischerweise der finale Status (pyStatusWork) des Work Objects eines Cases in Pega.

Dieses Attribut speichert die ID des Mitarbeiters oder Systembenutzers, der für die Ausführung eines bestimmten Tasks im KYC-Prozess verantwortlich ist, etwa eines Compliance-Beauftragten oder eines automatisierten Screening-Bots. Bei automatisierten Schritten kann dies die ID eines System- oder Servicekontos sein.

Die Analyse nach Benutzer hilft dabei, die Arbeitslastverteilung, die individuelle Leistung und den Schulungsbedarf zu verstehen. Außerdem lässt sich damit die Ursache von Prozessabweichungen untersuchen, indem die an nicht standardmäßigen Prozessabläufen beteiligten Benutzer oder Teams identifiziert werden.

Dieses Attribut verknüpft Prozessaktivitäten mit bestimmten Personen oder Teams und ermöglicht so die Analyse der Arbeitslast, die Leistungsbewertung und Compliance-Prüfungen.

Dies ist ein Standardfeld im Audit Trail von Pega und wird in History Tables typischerweise als pxUpdateOperator oder als ähnliche Eigenschaft gespeichert.

Dieses Attribut erfasst das genaue Datum und die Uhrzeit, zu denen eine Aktivität beendet wurde. Zusammen mit der Startzeit dient es zur Berechnung der Bearbeitungszeit einzelner Aktivitäten.

Eine separate Endzeit ermöglicht eine präzisere Leistungsanalyse. Sie hilft dabei, aktive Bearbeitungszeit, also die Dauer zwischen Startzeit und Endzeit, von Wartezeit, also der Dauer zwischen der Endzeit einer Aktivität und der Startzeit der nächsten, zu unterscheiden. Das ist entscheidend, um tatsächliche Engpässe zu erkennen und von Warteschlangen abzugrenzen.

Ermöglicht die präzise Berechnung der Bearbeitungszeit von Aktivitäten. Das ist für eine detaillierte Leistungsanalyse und die Erkennung von Engpässen entscheidend.

Diese Information kann im Audit Trail von Pega verfügbar sein. Andernfalls muss sie abgeleitet werden, indem die Startzeit des folgenden Ereignisses als Endzeit des aktuellen Ereignisses verwendet wird.

Dieses Attribut beschreibt das bewertete Risiko des Kunden, das häufig als „Niedrig“, „Mittel“ oder „Hoch“ kategorisiert wird. Die Risikostufe wird normalerweise von einer automatisierten Bewertungs-Engine anhand von Kundendaten und Screening-Ergebnissen bestimmt.

Die Risikostufe beeinflusst die Prozessvariante maßgeblich. Für Anträge mit hohem Risiko sind häufig zusätzliche Sorgfaltspflichten erforderlich, etwa eine erweiterte Compliance-Prüfung. Dadurch verlängern sich die Durchlaufzeiten. Die Analyse nach Risikostufe hilft, diese Abweichungen zu begründen und sicherzustellen, dass Risikokontrollen wirksam sind, ohne unnötige Verzögerungen zu verursachen.

Erklärt Unterschiede im Prozesspfad und in der Dauer, da die Risikostufe häufig den erforderlichen Umfang der Sorgfaltsprüfung bestimmt.

Dies wäre eine berechnete Eigenschaft des Cases, die durch eine Pega-Entscheidungsregel oder ein Bewertungsmodell befüllt wird. Prüfen Sie die Pega-KYC-Dokumentation.

Dieses Attribut speichert das im Service Level Agreement (SLA) festgelegte Zieldatum für den Abschluss eines Antrags. Das SLA kann von Faktoren wie Kundentyp, Risikostufe oder Produkt abhängen.

Dieses Datum ist für das Dashboard „Überwachung der SLA-Einhaltung“ und die zugehörige KPI entscheidend. Es dient als Referenzwert für den Vergleich mit dem tatsächlichen Abschlussdatum. Die Analyse von Cases, die ihr SLA-Ziel verfehlen, hilft dabei, systematische Verzögerungen zu erkennen und Prozessverbesserungen zu priorisieren, damit Servicezusagen eingehalten werden.

Es liefert den Referenzwert für die Messung der termingerechten Leistung, die für Kundenzufriedenheit und operative Steuerung entscheidend ist.

Pega verfügt über ein integriertes Framework für das SLA-Management. Dieses Datum wird typischerweise in Eigenschaften wie pySLAGoal oder in einer benutzerdefinierten SLA-Eigenschaft des Cases gespeichert.

Dieses Attribut bezeichnet das Produkt oder die Dienstleistung, für die der Kunde aufgenommen wird, etwa „Bankkonto für Privatkunden“, „Unternehmenskredit“ oder „Investmentdienstleistungen“.

Das Produkt kann den Onboarding-Prozess beeinflussen, da für verschiedene Produkte unterschiedliche regulatorische Anforderungen und Komplexitätsgrade gelten können. Die Analyse nach Produkt zeigt, ob bestimmte Produktlinien längere Durchlaufzeiten oder höhere Ablehnungsquoten aufweisen. Daraus ergeben sich Erkenntnisse für die produktspezifische Prozessoptimierung.

Ermöglicht die Segmentierung der Prozessanalyse nach Produktlinie und macht Leistungsunterschiede sowie Optimierungsmöglichkeiten sichtbar.

Dies wäre eine Eigenschaft des Cases, die zu Beginn des Antragsprozesses ausgewählt wird.

Dieses Attribut kategorisiert den Onboarding-Antrag, zum Beispiel als „Privatkunde“, „Firmenkunde“ oder „Vermögende Privatperson“. Verschiedene Case-Typen folgen häufig unterschiedlichen Prozessvarianten mit abweichenden Schritten, SLAs und Risikoprofilen.

Die Analyse nach Case-Typ ermöglicht aussagekräftigere Leistungsvergleiche. Sie zeigt, ob bestimmte Arten des Onboardings häufiger von Verzögerungen oder Ablehnungen betroffen sind. Diese Segmentierung ist entscheidend, um Prozessverbesserungen auf die jeweiligen Anforderungen der unterschiedlichen Kundenwege abzustimmen.

Ermöglicht die Segmentierung der Prozessdaten in klar abgegrenzte Kategorien und damit eine präzisere und relevantere Leistungsanalyse.

Dies ist typischerweise der Klassenname der Case-Instanz in Pega oder eine eigene Eigenschaft des Cases, die dessen Typ definiert.

Dieses Attribut verfolgt den Status der für den KYC-Prozess erforderlichen Dokumente. Mögliche Werte sind etwa „Beim Kunden ausstehend“, „Eingegangen“, „Verifiziert“ oder „Abgelehnt“. Der Status kann sich innerhalb eines einzelnen Cases mehrfach ändern.

Für das Dashboard „Onboarding-Durchsatz und -Status“ sowie die Analyse „Geschwindigkeit der Dokumentenprüfung“ ist dies ein wichtiges Attribut. Es ermöglicht eine detaillierte Betrachtung eines der häufigsten Engpassbereiche. Durch die Erfassung der Verweildauer von Dokumenten in den einzelnen Status können Verzögerungen bei der Einreichung durch den Kunden oder bei der internen Prüfung erkannt werden.

Schafft Transparenz über den Teilprozess der Dokumentenbearbeitung und hilft dabei, häufige Verzögerungen bei der Dokumentenprüfung zu erkennen und zu beheben.

Dabei handelt es sich wahrscheinlich um eine Eigenschaft eines zugehörigen Data Objects oder einer Page List, die mit dem zentralen Case verknüpft ist und jedes erforderliche Dokument verfolgt. Prüfen Sie die Pega-KYC-Dokumentation.

Diese berechnete Kennzahl misst die durchgängige Dauer jedes Kundenantrags, vom ersten bis zum letzten Ereignis. Sie wird normalerweise als Differenz zwischen dem Timestamp der letzten Aktivität und dem Timestamp der ersten Aktivität eines Cases berechnet.

Die Durchlaufzeit ist eine zentrale KPI für Prozesseffizienz und Customer Experience. Im Dashboard „Analyse der gesamten Onboarding-Durchlaufzeit“ wird sie verwendet, um durchschnittliche Bearbeitungszeiten zu überwachen, lang laufende Cases zu erkennen und die Auswirkungen von Prozessverbesserungen im Zeitverlauf zu verfolgen.

Dies ist eine zentrale KPI, die Geschwindigkeit und Effizienz des gesamten Onboarding-Prozesses aus Sicht des Kunden direkt misst.

Diese Kennzahl wird im Process-Mining-Tool berechnet, indem für jede Case-ID die Differenz zwischen dem maximalen und dem minimalen Timestamp gebildet wird.

Dieses boolesche Attribut ist wahr, wenn die Aktivität von einem automatisierten Agenten, etwa einer Screening-Engine oder einer Systemregel, ausgeführt wurde, und falsch, wenn sie von einem menschlichen Benutzer ausgeführt wurde.

Die Unterscheidung zwischen automatisierten und manuellen Aktivitäten ist für die Automatisierungsanalyse entscheidend. Sie hilft dabei, die Wirksamkeit bestehender Automatisierung zu messen, manuelle Tasks mit Potenzial für eine künftige Automatisierung zu erkennen und das Zusammenspiel menschlicher und systemischer Akteure im Prozess zu verstehen.

Trennt menschlich gesteuerte von systemgesteuerten Aktivitäten und bildet damit eine zentrale Grundlage für jede Automatisierungsinitiative und -analyse.

Dieses Kennzeichen kann aus der dem Ereignis zugeordneten Benutzer-ID abgeleitet werden. Entspricht die OperatorId einem bekannten System- oder Agentenkonto, wird der Wert auf wahr gesetzt.

Dieses boolesche Attribut ist wahr, wenn eine bestimmte Aktivität, etwa „Dokumentenprüfung“, innerhalb desselben Cases mehr als einmal auftritt. Häufig wird es durch Ereignisse wie „Zusätzliche Informationen angefordert“ ausgelöst.

Die Erkennung von Nacharbeit ist entscheidend, um Ineffizienzen und Reibungspunkte für Kunden sichtbar zu machen. Das Dashboard „Nacharbeit und Schleifen im Prozess“ verwendet dieses Attribut, um Häufigkeit und Auswirkungen von Nacharbeit zu quantifizieren. Die Reduzierung von Nacharbeit ist häufig ein wichtiges Ziel, da sie zu kürzeren Bearbeitungszeiten, niedrigeren Betriebskosten und einer besseren Customer Experience führt.

Macht Ineffizienzen, redundante Tasks und Schleifen im Prozess sichtbar, die zu den wichtigsten Ansatzpunkten für Prozessverbesserungen gehören.

Dieses Kennzeichen wird während der Datenanalyse abgeleitet, indem wiederholte Aktivitätsnamen innerhalb derselben Case-ID geprüft werden. Ein Beispiel ist das erneute Auftreten von „Dokumentenprüfung abgeschlossen“.

Dieses Attribut ist die eindeutige ID, die den Antrag mit einem Kundendatensatz im Stammdatensystem verknüpft. Es bezeichnet die Person oder Organisation, die Gegenstand des KYC-Prozesses ist.

Während die Antrags-ID den Prozess verfolgt, ermöglicht die Kunden-ID Analysen über mehrere Anträge desselben Kunden hinweg. Außerdem können die Prozessdaten mit kundenspezifischen Attributen wie Segment oder Historie angereichert werden. So entsteht eine kundenorientierte Sicht auf den Onboarding-Prozess.

Verknüpft die Prozessdaten mit den Kundendaten und ermöglicht dadurch umfassendere Analysen auf Grundlage von Kundenattributen und -historie.

Dies wäre eine zentrale Eigenschaft des KYC-Cases, die ihn mit dem Kundendatenmodell in Pega oder einem externen CRM verknüpft.

Dieses Attribut speichert das Land, das dem aufgenommenen Kunden zugeordnet ist. Diese Information ist eine wichtige Eingabe für die Risikobewertung und die Bestimmung des erforderlichen Umfangs der Sorgfaltsprüfung.

In der Analyse kann das Kundenland wichtige Muster sichtbar machen. Bestimmte Rechtsordnungen können mit einem höheren Risiko verbunden sein und zu längeren sowie komplexeren Onboarding-Prozessen führen. Diese Dimension ermöglicht eine geografische Leistungsanalyse und hilft dabei, regionale Compliance-Anforderungen effizient einzuhalten.

Ermöglicht die geografische Analyse des Prozesses, die häufig mit regulatorischer Komplexität und Risikostufen zusammenhängt.

Dies wäre eine Eigenschaft des mit dem Case verknüpften Kundendatenobjekts.

Dieses Attribut gibt an, wann die Daten zuletzt aus dem Quellsystem extrahiert wurden. Innerhalb eines einzelnen Datenladevorgangs ist der Wert normalerweise für alle Datensätze identisch.

Dieser Timestamp ist wichtig, um die Aktualität der analysierten Daten einzuschätzen. Er zeigt, wie aktuell die Prozessanalyse ist und wann die nächste Datenaktualisierung erwartet wird. Das ist besonders für Dashboards zur operativen Überwachung relevant.

Informiert Nutzer über die Aktualität der Daten und stellt sicher, dass sie erkennen, ob die Analyse den aktuellen Zustand oder einen vergangenen Zeitraum abbildet.

Dieser Wert wird während des ETL-Prozesses zur Datenextraktion, -transformation und -ladung erzeugt und dem Datensatz hinzugefügt.

Dieses Attribut bezeichnet die Quellanwendung, in der das Ereignis erfasst wurde. Für diesen Prozess wäre der Wert durchgehend „Pega KYC“.

Auch wenn dieses Attribut bei Daten aus nur einem System überflüssig erscheinen mag, ist es für die Data Governance entscheidend und wird bei der Integration mehrerer Systeme unverzichtbar. Es schafft Klarheit über die Herkunft der Daten und unterstützt die Fehleranalyse bei Problemen in der Datenintegration.

Es liefert wichtigen Kontext zur Datenherkunft, unterstützt die Data Governance und ermöglicht Analysen über mehrere Quellsysteme hinweg.

Dies ist typischerweise ein statischer Wert, der während der Datenextraktion und -transformation ergänzt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Dieses Attribut kategorisiert jeden abgeschlossenen Case als „Pünktlich“ oder „Verspätet“. Grundlage ist der Vergleich zwischen dem tatsächlichen Abschluss-Timestamp und dem „SLA-Zieldatum“.

Dies ist die zentrale Kennzahl für das Dashboard „Überwachung der SLA-Einhaltung“ und die KPI „SLA-Einhaltungsquote“. Sie bietet einen klaren Überblick über die Leistung im Verhältnis zu Servicezusagen. Die Analyse der Merkmale verspäteter Cases hilft dabei, die Ursachen von Verzögerungen zu erkennen und das Risiko künftiger SLA-Verletzungen zu verringern.

Misst die Leistung direkt im Verhältnis zu den eingegangenen Verpflichtungen und ist damit für operative Steuerung, Compliance und Kundenzufriedenheit entscheidend.

Dieser Wert wird abgeleitet, indem der Timestamp der letzten Case-Aktivität mit dem Feld SlaTargetDate verglichen wird. Liegt die Abschlusszeit nach dem Ziel, lautet der Status „Verspätet“.