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

Dieses Attribut enthält den Namen einer Geschäftsaktivität oder eines System-Events, zum Beispiel „Antrag eingereicht“, „Compliance-Prüfung eingeleitet“ oder „Antrag abgelehnt“. Es steht für einen einzelnen Schritt im gesamten Kunden-Onboarding-Prozess.

Die Analyse von Aktivitäten bildet den Kern des Process Mining. Mit diesem Attribut wird die Prozesslandkarte erstellt, die den Ablauf zwischen den einzelnen Schritten zeigt. So lassen sich die Ereignisfolge nachvollziehen, die Häufigkeit jeder Aktivität messen und besonders häufige oder zeitaufwendige Aufgaben ermitteln.

Dieses Attribut legt die Schritte in der Prozesslandkarte fest und ermöglicht es, den Prozessablauf zu visualisieren, zu analysieren und nachzuvollziehen.

Diese Informationen werden üblicherweise im Audit-Trail von Pega (Verlaufstabellen) erfasst oder lassen sich aus den Statusänderungen des Cases ableiten.

Der Kundenantrag ist der primäre Case-Bezeichner. Er fasst alle zugehörigen Aktivitäten und Events für den Onboarding-Prozess eines einzelnen Kunden zusammen. Jeder Antrag durchläuft einen Prozess, der mit der Einreichung beginnt und entweder mit der Genehmigung und Kontoaktivierung oder mit der Ablehnung endet.

Im Process Mining ist dieses Attribut entscheidend, um den gesamten Ablauf jedes Antrags zu rekonstruieren. Es ermöglicht Business-Analysten, die vollständige Ereignisfolge 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 von der Standardvorgehensweise zu erkennen.

Diese ID bildet die Grundlage für Process Mining: Sie führt einzelne Events zu zusammenhängenden, durchgängigen Prozessinstanzen zusammen, die sich analysieren lassen.

In Pega ist dies in der Regel die primäre Case-ID. Sie ist häufig als pzInsKey oder unter einer geschäftsfreundlichen Bezeichnung im Work-Objekt des Haupt-Case-Typs verfügbar.

Dieses Attribut erfasst Datum und Uhrzeit, zu denen eine Aktivität begonnen hat. Es legt die zeitliche Reihenfolge aller Events innerhalb eines Kundenantrags fest.

Timestamps sind eine wichtige Grundlage für die leistungsbezogene Prozessanalyse. Anhand dieser Werte lassen sich die Dauer von Aktivitäten, die Wartezeit zwischen Schritten und die gesamte Durchlaufzeit des Onboarding-Prozesses berechnen. Diese Daten sind entscheidend, um Engpässe zu erkennen, die SLA-Einhaltung zu messen und die Prozesseffizienz zu beurteilen.

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

Dieser Wert ist üblicherweise Teil des Audit-Trails von Pega und findet sich für jedes Event häufig als pxTimeCreated in den Verlaufstabellen.

Wenn der endgültige Status eines Antrags „Abgelehnt“ lautet, enthält dieses Attribut den konkreten Grund, zum Beispiel „Hintergrundprüfung nicht bestanden“, „Unvollständige Unterlagen“ oder „Hohes Risikoprofil“.

Dieses Attribut ist die wichtigste Grundlage für das Dashboard „Analyse abgelehnter Anträge“. Durch die Aufschlüsselung abgelehnter Cases nach Gründen kann das Unternehmen die häufigsten Fehlerquellen im Onboarding-Prozess ermitteln. Diese Erkenntnisse sind entscheidend, um gezielte Verbesserungen umzusetzen, die Ablehnungsquote zu senken, die Customer Experience zu verbessern und die betriebliche Effizienz zu steigern.

Zeigt konkrete Gründe für das Scheitern von Anträgen auf und ermöglicht gezielte Prozessverbesserungen, um die Erfolgsquote zu erhöhen.

Dabei handelt es sich wahrscheinlich um eine bestimmte Eigenschaft des Cases, die gesetzt wird, wenn sein Status auf „Abgelehnt“ wechselt. Informationen zu standardmäßigen Feldern für Ablehnungsgründe finden Sie in der Pega-KYC-Dokumentation.

Dieses Attribut gibt die Organisationseinheit oder das Team an, dem der ausführende Benutzer angehört, zum Beispiel „Screening-Team“, „Compliance“ oder „Onboarding-Betrieb“.

Die Analyse nach Abteilungen ist entscheidend für das Dashboard „Arbeitslast nach Abteilung“. Sie hilft Führungskräften nachzuvollziehen, wie die Arbeit zwischen Teams verteilt wird, teamübergreifende Engpässe zu erkennen und die Ressourcenzuweisung im gesamten Onboarding-Prozess zu beurteilen. Das ist wichtig, um Übergaben zu verbessern und Arbeitslasten auszugleichen.

Ermöglicht die Analyse von Prozessabläufen und Engpässen zwischen verschiedenen Geschäftseinheiten und unterstützt so das Ressourcenmanagement und die organisatorische Optimierung.

Diese Informationen sind üblicherweise dem Benutzerprofil in Pega (Operator-ID-Datensatz) zugeordnet und lassen sich mit den Event-Daten verknüpfen. Die Eigenschaft kann pyWorkGroup lauten.

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

Der Status ist eine wichtige Dimension für die Ergebnisanalyse. Im Dashboard „Analyse abgelehnter Anträge“ dient er dazu, Cases zu segmentieren und die Gründe für bestimmte Ergebnisse zu untersuchen. Die Analyse der Prozessabläufe, die zu den verschiedenen Statuswerten führen, hilft dabei, bewährte Vorgehensweisen bei genehmigten Anträgen und die Ursachen für Ablehnungen zu erkennen.

Das Attribut legt das Geschäftsergebnis eines Cases fest und ermöglicht den Vergleich erfolgreicher und nicht erfolgreicher Prozesspfade.

Dies ist üblicherweise der endgültige Status (pyStatusWork) des Case-Work-Objekts in Pega.

Dieses Attribut speichert die ID des Mitarbeitenden oder Systembenutzers, der für eine bestimmte Aufgabe im KYC-Prozess verantwortlich ist, zum Beispiel eines Compliance-Beauftragten oder eines automatisierten Screening-Bots. Bei automatisierten Schritten kann es sich um die ID eines System- oder Servicekontos handeln.

Die Analyse nach Benutzern hilft dabei, die Arbeitsverteilung, die individuelle Leistung und den Schulungsbedarf zu beurteilen. Außerdem lassen sich Prozessabweichungen untersuchen, indem ermittelt wird, welche Benutzer oder Teams an nicht standardmäßigen Prozessabläufen beteiligt sind.

Dieses Attribut ordnet Prozessaktivitäten bestimmten Personen oder Teams zu 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 Verlaufstabellen üblicherweise als pxUpdateOperator oder in einer ähnlichen Eigenschaft gespeichert.

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

Eine separate Endzeit ermöglicht eine genauere Leistungsanalyse. Sie hilft dabei, die aktive Verarbeitungszeit (zwischen Start- und Endzeit) von der Wartezeit (zwischen der Endzeit einer Aktivität und der Startzeit der nächsten) zu unterscheiden. So lassen sich tatsächliche Engpässe von Warteschlangen abgrenzen.

Ermöglicht die genaue Berechnung der Verarbeitungszeit von Aktivitäten, eine wichtige Grundlage für detaillierte Leistungsanalysen und die Ermittlung von Engpässen.

Die Endzeit ist möglicherweise im Audit-Trail von Pega verfügbar. Andernfalls lässt sie sich ableiten, indem die Startzeit des nachfolgenden Events als Endzeit des aktuellen Events verwendet wird.

Dieses Attribut gibt das bewertete Risiko des Kunden an, das häufig als „Niedrig“, „Mittel“ oder „Hoch“ eingestuft wird. Die Risikostufe wird üblicherweise von einer automatisierten Bewertungslogik anhand der Kundendaten und Screening-Ergebnisse ermittelt.

Die Risikostufe beeinflusst maßgeblich den Prozessablauf. Bei Anträgen mit hohem Risiko sind häufig zusätzliche Sorgfaltsprüfungen erforderlich, etwa eine vertiefte Compliance-Prüfung. Dadurch verlängert sich die Durchlaufzeit. Die Analyse nach Risikostufe hilft, diese Unterschiede nachzuvollziehen und sicherzustellen, dass die Risikokontrollen wirksam sind, ohne unnötige Verzögerungen zu verursachen.

Erklärt Unterschiede im Prozessablauf 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. Weitere Informationen finden Sie in der Pega-KYC-Dokumentation.

Dieses Attribut speichert das im Service Level Agreement (SLA) festgelegte Zieldatum für den Abschluss eines Antrags. Das SLA kann je nach Kundentyp, Risikostufe oder Produkt variieren.

Das Datum ist eine wichtige Grundlage für das Dashboard „SLA-Einhaltung verfolgen“ und die zugehörige KPI. Es dient als Vergleichswert für das tatsächliche Abschlussdatum. Die Analyse von Cases, bei denen das SLA-Ziel verfehlt wurde, hilft dabei, systematische Verzögerungen zu erkennen und Prozessverbesserungen zu priorisieren, damit Servicevereinbarungen eingehalten werden.

Das Datum dient als Vergleichswert für die Messung der Termintreue, die für die Kundenzufriedenheit und die operative Steuerung entscheidend ist.

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

Dieses boolesche Attribut ist wahr, wenn ein automatisierter Agent, etwa eine Screening-Engine oder eine Systemregel, die Aktivität ausgeführt hat. Wurde sie von einem Menschen ausgeführt, ist der Wert falsch.

Die Unterscheidung zwischen automatisierten und manuellen Aktivitäten ist für die Automatisierungsanalyse entscheidend. Sie hilft dabei, die Wirksamkeit bestehender Automatisierungen zu messen, manuelle Aufgaben mit Automatisierungspotenzial zu ermitteln und das Zusammenspiel menschlicher und technischer Akteure im Prozess zu verstehen.

Das Attribut unterscheidet menschlich ausgeführte von systemgesteuerten Aktivitäten und bildet damit eine wichtige Grundlage für Automatisierungsinitiativen und -analysen.

Der Wert lässt sich aus der dem Event zugeordneten Benutzer-ID ableiten. Entspricht die OperatorId einem bekannten System- oder Agentenkonto, wird dieses Attribut auf wahr gesetzt.

Dieses Attribut kategorisiert den Onboarding-Antrag, zum Beispiel als „Privatkunde“, „Firmenkunde“ oder „Kunde mit hohem Nettovermögen“. Für verschiedene Case-Typen gelten häufig unterschiedliche Prozessvarianten mit abweichenden Schritten, SLAs und Risikoprofilen.

Die Analyse nach Case-Typ ermöglicht aussagekräftigere Leistungsvergleiche. Sie zeigt, ob bestimmte Onboarding-Typen häufiger von Verzögerungen oder Ablehnungen betroffen sind. Diese Segmentierung ist entscheidend, um Prozessverbesserungen auf die spezifischen Anforderungen der verschiedenen Kundenprozesse abzustimmen.

Ermöglicht die Aufteilung der Prozessdaten in verschiedene Kategorien und damit eine genauere und aussagekräftigere Leistungsanalyse.

Dies ist üblicherweise der Klassenname der Case-Instanz in Pega oder eine eigene Eigenschaft des Cases, die seinen Typ festlegt.

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

Das Attribut ist wichtig für das Dashboard „Onboarding-Durchsatz und -Status“ sowie für die Analyse „Geschwindigkeit der Dokumentenprüfung“. Es ermöglicht eine detaillierte Betrachtung eines der häufigsten Engpassbereiche. Wenn erfasst wird, wie lange Unterlagen in den einzelnen Status verbleiben, lassen sich Verzögerungen bei der Einreichung durch den Kunden oder bei der internen Prüfung erkennen.

Macht den Teilprozess der Dokumentenbearbeitung transparent 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 Datenobjekts oder einer Seitenliste des Haupt-Cases, in der jedes erforderliche Dokument erfasst wird. Weitere Informationen finden Sie in der Pega-KYC-Dokumentation.

Dieses Attribut enthält die eindeutige ID, über die der Antrag mit einem Kundendatensatz im Stammdatensystem verknüpft wird. Es bezeichnet die Person oder Organisation, für die der KYC-Prozess durchgeführt wird.

Während die Antrags-ID den Prozess erfasst, ermöglicht die Kunden-ID Analysen über mehrere Anträge desselben Kunden hinweg. Außerdem lassen sich die Prozessdaten um kundenspezifische Attribute wie Segment oder Historie ergänzen. So kann der Onboarding-Prozess aus Kundensicht betrachtet werden.

Verknüpft die Prozessdaten mit den Kundenstammdaten und ermöglicht so detailliertere Analysen anhand von Kundenattributen und der Kundenhistorie.

Dies ist eine zentrale Eigenschaft des KYC-Cases, über die er mit dem Kundendatenmodell in Pega oder einem externen CRM verknüpft wird.

Dieses Attribut enthält das Land des Kunden, für den das Onboarding durchgeführt wird. Die Angabe ist eine wichtige Grundlage für die Risikobewertung und die Festlegung des erforderlichen Umfangs der Sorgfaltsprüfung.

Die Analyse nach Kundenland kann wichtige Muster aufzeigen. Bestimmte Länder können mit einem höheren Risiko verbunden sein, was zu längeren und komplexeren Onboarding-Prozessen führt. Diese Dimension ermöglicht geografische Leistungsvergleiche 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 Kundendatenobjekts, das dem Case zugeordnet ist.

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 gleich.

Der Timestamp zeigt, wie aktuell die analysierten Daten sind. Benutzer können damit einschätzen, ob die Prozessanalyse den aktuellen Stand abbildet und wann die nächste Datenaktualisierung zu erwarten ist. Das ist besonders für Dashboards zur operativen Überwachung wichtig.

Das Attribut informiert Benutzer über die Aktualität der Daten. So können sie einschätzen, ob die Analyse den aktuellen Stand oder einen früheren Zeitraum abbildet.

Dieser Wert wird während des ETL-Prozesses (Extraktion, Transformation und Laden) erzeugt und dem Datensatz hinzugefügt.

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 Events wie „Zusätzliche Informationen angefordert“ ausgelöst.

Das Erkennen von Nacharbeit ist wichtig, um Ineffizienzen und Reibungspunkte für Kunden aufzudecken. Das Dashboard „Nacharbeit und Schleifen im Prozess“ verwendet dieses Attribut, um Häufigkeit und Auswirkungen von Nacharbeit zu quantifizieren. Nacharbeit zu reduzieren ist oft ein wichtiges Ziel, denn dadurch verkürzen sich Bearbeitungszeiten, sinken Betriebskosten und verbessert sich die Customer Experience.

Macht Ineffizienzen, redundante Aufgaben und Schleifen im Prozess sichtbar, die wichtige Ansatzpunkte für Prozessverbesserungen sind.

Dieses Attribut wird während der Datenanalyse abgeleitet, indem wiederholte Aktivitätsnamen innerhalb derselben Case-ID ermittelt werden. Ein Beispiel wäre ein zweites Auftreten von „Dokumentenprüfung abgeschlossen“.

Dieses Attribut gibt das Produkt oder die Dienstleistung an, für das beziehungsweise die das Onboarding durchgeführt wird, zum Beispiel „Privatkonto“, „Unternehmenskredit“ oder „Anlageberatung“.

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 hilft dabei, Produktlinien mit längeren Durchlaufzeiten oder höheren Ablehnungsquoten zu erkennen und Erkenntnisse für die Optimierung der jeweiligen Prozesse zu gewinnen.

Ermöglicht die Prozessanalyse nach Produktlinie und zeigt Leistungsunterschiede sowie Optimierungsmöglichkeiten auf.

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

Dieses Attribut gibt die Quellanwendung an, in der das Event erfasst wurde. Bei diesem Prozess lautet 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 wichtig und wird bei der Integration von Daten aus mehreren Systemen unverzichtbar. Es schafft Klarheit über die Herkunft der Daten und erleichtert die Fehlersuche bei Problemen mit der Datenintegration.

Das Attribut liefert wichtige Informationen zur Datenherkunft, unterstützt die Data Governance und ermöglicht Analysen über mehrere Quellsysteme hinweg.

Dieser statische Wert wird üblicherweise während der Datenextraktion und -transformation hinzugefügt, um die Herkunft des Datensatzes zu kennzeichnen.

Dieses Attribut stuft jeden abgeschlossenen Case als „Fristgerecht“ oder „Verspätet“ ein. Grundlage ist der Vergleich zwischen dem tatsächlichen Abschluss-Timestamp und dem „SLA-Zieldatum“.

Es ist die zentrale Kennzahl für das Dashboard „SLA-Einhaltung verfolgen“ und die KPI „SLA-Einhaltungsquote“. Sie zeigt auf einen Blick, wie die Leistung im Vergleich zu den vereinbarten Service Levels ausfällt. Die Analyse verspäteter Cases hilft dabei, die Ursachen von Verzögerungen zu ermitteln und das Risiko künftiger SLA-Verstöße zu verringern.

Misst direkt die Einhaltung von Vereinbarungen und ist damit entscheidend für die operative Steuerung, Compliance und Kundenzufriedenheit.

Der Wert wird ermittelt, indem der Timestamp der letzten Case-Aktivität mit dem Feld SlaTargetDate verglichen wird. Liegt der Abschlusszeitpunkt nach dem Zieltermin, lautet der Status „Verspätet“.

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

Die Zykluszeit ist eine zentrale Kennzahl für Prozesseffizienz und Customer Experience. Im Dashboard „Analyse der gesamten Onboarding-Durchlaufzeit“ dient sie dazu, die durchschnittlichen Bearbeitungszeiten zu überwachen, lang laufende Cases zu erkennen und die Auswirkungen von Prozessverbesserungen im Zeitverlauf nachzuverfolgen.

Diese wichtige KPI misst direkt die Gesamtgeschwindigkeit und Effizienz des Onboarding-Prozesses aus Kundensicht.

Diese Kennzahl wird im Process-Mining-Tool berechnet, indem für jede Case-ID der kleinste Timestamp vom größten abgezogen wird.