Ihr KYC-Onboarding Daten-Template

Dieses Attribut erfasst den Namen einer Geschäftsaktivität oder eines Systemereignisses, wie z.B. 'Antrag eingereicht', 'Compliance-Prüfung initiiert' oder 'Antrag abgelehnt'. Es repräsentiert einen einzelnen Schritt im gesamten Kunden-Onboarding-Prozess.

Die Analyse von Aktivitäten ist die Grundlage für Process Mining. Dieses Attribut wird verwendet, um die Prozesskarte zu erstellen, die den Fluss zwischen verschiedenen Schritten zeigt. Es hilft, die Reihenfolge der Ereignisse zu identifizieren, die Häufigkeit jeder Aktivität zu messen und festzustellen, welche Aufgaben am häufigsten oder zeitaufwendigsten sind.

Dieses Attribut definiert die Schritte in der Prozesskarte und ermöglicht so die Visualisierung, Analyse und das Verständnis des Prozessflusses.

Diese Information wird in der Regel im Audit-Trail von Pega (History-Tabellen) erfasst oder kann aus den Statusänderungen des Falls abgeleitet werden.

Der Kundenantrag ist der primäre Case-Identifikator, der alle zusammenhängenden Aktivitäten und Ereignisse für die Onboarding-Prozess eines einzelnen Kunden gruppiert. Jeder Antrag durchläuft einen Pfad von der Einreichung bis zur Genehmigung und Kontoaktivierung oder Ablehnung.

Im Process Mining ist dieses Attribut wichtig für die Rekonstruktion der End-to-End-Prozesses jedes Antrags. Es ermöglicht Analysten, die vollständige Abfolge von Ereignisse anzuzeigen, den Status jedes Antrags zu verfolgen und verschiedene Pfade zu vergleichen. Die Analyse von Fälle basierend auf dieser ID hilft, gängige Prozessvarianten, Engpässe und Abweichungen vom Standardverfahren zu identifizieren.

Diese ID ist die Grundlage für Process Mining, da sie alle einzelnen Ereignisse zu kohärenten, End-to-End-Prozessinstanzen für die Analyse verbindet.

Dies ist in der Regel die primäre Case-ID in Pega, oft zugänglich als pzInsKey oder ein geschäftsfreundliches Äquivalent im Haupt-Case-Typ Work Object.

Dieses Attribut erfasst das genaue Datum und die Uhrzeit, zu der eine Aktivität begann. Es liefert die chronologische Reihenfolge für alle Ereignisse innerhalb eines einzelnen Kundenantragsfalls.

Zeitstempels sind wesentlich für die leistungsbezogene Prozessanalyse. Sie werden verwendet, um die Dauer von Aktivitäten, die Wartezeit zwischen Schritten und die gesamte End-to-End-Durchlaufzeit des Onboarding-Prozesses zu berechnen. Diese Daten sind wichtig für die Identifizierung von Engpässen, die Messung der SLA-Einhaltung und das Verständnis der Prozesseffizienz.

Zeitstempels liefern den chronologischen Kontext, der zur Berechnung von Dauern, zur Analyse der Prozessleistung und zur Identifizierung von Verzögerungen erforderlich ist.

Dies ist ein Standardbestandteil des Audit-Trails von Pega, oft als pxTimeCreated in History-Tabellen für jedes Event zu finden.

Wenn der finale Status eines Antrags 'Abgelehnt' ist, liefert dieses Attribut den spezifischen Grund, wie z.B. 'Hintergrundprüfung fehlgeschlagen', 'Unvollständige Dokumentation' oder 'Hohes Risikoprofil'.

Dieses Attribut ist der zentrale Faktor für das Dashboard 'Analyse der Antragsablehnungen'. Durch die Segmentierung abgelehnter Fälle nach Gründen kann das Unternehmen die häufigsten Fehlerpunkte im Onboarding-Prozess identifizieren. Diese Erkenntnis ist maßgeblich für die Implementierung gezielter Verbesserungen, um die Ablehnungsrate zu reduzieren, die Kundenerfahrung zu verbessern und die operative Effizienz zu steigern.

Liefert konkrete Optimierungspotenziale darüber, warum Anträge scheitern, und ermöglicht gezielte Prozessoptimierungen zur Erhöhung der Erfolgsquote.

Dies wäre wahrscheinlich eine spezifische Eigenschaft, die für den Fall festgelegt wird, wenn er in den Status 'Abgelehnt' übergeht. Konsultieren Sie die Pega KYC-Dokumentation für standardmäßige Ablehnungsgrundfelder.

Dieses Attribut identifiziert die Organisationseinheit oder den Antrag bearbeitet.as Team, zu dem der ausführende Benutzer gehört, wie 'Screening-Team', 'Compliance' oder 'Onboarding-Operationen'.

Die Analyse des Prozesses nach Abteilung ist maßgeblich für das Dashboard 'Arbeitslastverteilung nach Abteilung'. Sie hilft Managern zu verstehen, wie Arbeit zwischen verschiedenen Teams fließt, funktionsübergreifende Engpässe zu identifizieren und die Ressourcenverteilung über den gesamten Onboarding-Prozess zu bewerten. Sie ist maßgeblich für die Optimierung von Übergaben und die Auslastung der Arbeitslasten.

Es ermöglicht die Analyse des Prozessflusses und von Engpässe zwischen verschiedenen Geschäftseinheiten und unterstützt das Ressourcenmanagement sowie die organisatorische Optimierung.

Diese Information ist in der Regel mit dem Benutzerprofil in Pega (Operator ID-Datensatz) verbunden und kann mit den Event-Daten verknüpft werden. Die Eigenschaft könnte pyWorkGroup sein.

Dieses Attribut speichert die ID des Mitarbeiters oder Systembenutzers, der für die Durchführung einer spezifischen Aufgabe im KYC-Prozess verantwortlich ist, wie z.B. ein Compliance Officer oder ein automatisierter Screening Bot. Bei automatisierten Schritten könnte dies eine System- oder Servicekonto-ID sein.

Die Analyse nach Benutzer hilft, die Arbeitslastverteilung, die individuelle Leistung und den Schulungsbedarf zu verstehen. Sie kann auch verwendet werden, um Prozessabweichungen zu untersuchen, indem identifiziert wird, welche Benutzer oder Teams an nicht-standardisierten Prozessabläufen beteiligt sind.

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

Dies ist ein Standardfeld im Audit-Trail von Pega, in der Regel gespeichert als pxUpdateOperator oder eine ähnliche Eigenschaft in History-Tabellen.

Dieses Attribut gibt den Gesamtstatus des Antrags am Ende des Prozesses an, wie z.B. 'Genehmigt', 'Abgelehnt' oder 'Zurückgezogen'. Es kann auch den letzten bekannten Status für laufende Fälle widerspiegeln.

Dies ist eine kritische Dimension für die Ergebnisanalyse. Sie wird direkt im Dashboard 'Analyse der Antragsablehnungen' verwendet, um Fälle zu segmentieren und zu verstehen, warum bestimmte Resultate auftreten. Die Analyse von Prozessabläufen, die zu unterschiedlichen Status führen, hilft, Best Practices für genehmigte Fälle und Grundursachen für abgelehnte Fälle zu identifizieren.

Es definiert das Geschäftsergebnis eines Falles und ermöglicht eine leistungsfundierte Analysen, die erfolgreiche Pfade mit nicht erfolgreichen vergleicht.

Dies ist in der Regel der finale Status (pyStatusWork) des Case Work Objects in Pega.

Dieses Attribut erfasst das genaue Datum und die Uhrzeit, zu der eine Aktivität endete. Es wird in Verbindung mit der Startzeit verwendet, um die Bearbeitungszeit für einzelne Aktivitäten zu berechnen.

Eine separate Endzeit ermöglicht eine genauere Leistungsanalyse. Sie hilft, zwischen aktiver Bearbeitungszeit (Dauer zwischen Start- und Endzeit) und Wartezeit (Dauer zwischen der Endzeit einer Aktivität und der Startzeit der nächsten) zu unterscheiden. Dies ist maßgeblich, um echte Engpässe zu identifizieren und sie von Warteschlangen abzugrenzen.

Ermöglicht die präzise Berechnung der Aktivitätsbearbeitungszeit, die für eine detaillierte Leistungsfähigkeit-Analyse und Bottleneck-Identifikation notwendig ist.

Dies kann im Audit-Trail von Pega verfügbar sein oder muss möglicherweise abgeleitet werden, indem die Startzeit des nachfolgenden Ereignisse als Endzeit des aktuellen Ereignisse verwendet wird.

Dieses Attribut repräsentiert das bewertete Risiko, das mit dem Kunden verbunden ist, oft kategorisiert als 'Niedrig', 'Mittel' oder 'Hoch'. Das Risikolevel wird in der Regel von einer automatisierten Scoring-Engine basierend auf KundenDaten und Screening-Resultaten bestimmt.

Das Risikolevel ist ein starker Treiber der Prozessvariation. Anträge mit hohem Risiko erfordern oft zusätzliche Due-Diligence-Schritte, wie z.B. eine erweiterte Compliance-Prüfung, was zu längeren Durchlaufzeiten führt. Die Analyse des Prozesses nach Risikolevel hilft, diese Variationen zu rechtfertigen und sicherzustellen, dass Risikokontrollen effektiv arbeiten, ohne unnötige Verzögerungen zu verursachen.

Erklärt Variationen im Prozesspfad und in der Dauer, da das Risikolevel oft das erforderliche Maß an Due Diligence bestimmt.

Dies wäre eine berechnete Eigenschaft des Falls, die durch eine Pega-Entscheidungsregel oder ein Scoring-Modell gefüllt wird. Konsultieren Sie die Pega KYC-Dokumentation.

Dieses Attribut speichert das Ziel-Abschlussdatum für einen Antrag, wie es durch das Service Level Agreement (SLA) definiert ist. Das SLA kann je nach Faktoren wie Kundentyp, Risikolevel oder Produkt variieren.

Dieses Datum ist wichtig für das Dashboard 'SLA-Einhaltungs-Tracking' und den zugehörigen KPI. Es dient als Benchmark, mit dem das tatsächliche Abschlussdatum verglichen wird. Die Analyse von Fällen, die ihr SLA-Ziel verfehlen, hilft, systemische Verzögerungen zu identifizieren und Prozessoptimierungen zu priorisieren, um die Einhaltung der Service-Verpflichtungen zu sicherstellen.

Es bietet den Benchmark zur Messung der On-Time-Leistungsfähigkeit, was wichtig für Kundenzufriedenheit und operative Steuerung ist.

Pega hat ein integriertes SLA-Management-Framework. Dieses Datum wird in der Regel in Eigenschaften wie pySLAGoal oder einer benutzerdefinierten SLA-Eigenschaft des Case gespeichert.

Dieses Attribut verfolgt den Status der für den KYC-Prozess erforderlichen Dokumente mit Werten wie 'Kunde ausstehende Zahlungen identifizieren.end', 'Erhalten', 'Verifiziert' oder 'Abgelehnt'. Dieser Status kann sich innerhalb eines einzelnen Falls mehrmals ändern.

Dies ist ein Schlüsselattribut für das Dashboard 'Onboarding-Durchsatz & Status' und die Analyse der 'Dokumentenprüfungsgeschwindigkeit'. Es ermöglicht eine detaillierte Ansicht eines der häufigsten Engpassbereiche. Durch die Verfolgung, wie lange Dokumente in jedem Status verbleiben, kann das Unternehmen Verzögerungen bei der Kundeneinreichung oder den Antrag bearbeitet.er internen Überprüfung identifizieren.

Bietet Transparenz im Sub-Prozess der Dokumentenbearbeitung und hilft, häufige Verzögerungen bei der Dokumentenprüfung zu identifizieren und zu beheben.

Dies wäre wahrscheinlich eine Eigenschaft eines verwandten Datenobjekts oder einer Seitenliste, die mit dem Hauptfall verknüpft ist und jedes erforderliche Dokument verfolgt. Konsultieren Sie die Pega KYC-Dokumentation.

Dieses Attribut kategorisiert den Onboarding-Antrag, zum Beispiel 'Privatkunde', 'Firmenkunde' oder 'Vermögender Privatkunde'. Verschiedene Case-Typn folgen oft unterschiedlichen Prozessvarianten mit verschiedenen Schritten, SLAs und Risikoprofilen.

Die Analyse des Prozesses nach Case-Typ ermöglicht einen aussagekräftigeren Leistungsvergleich. Sie hilft zu verstehen, ob bestimmte Onboarding-Typn anfälliger für Verzögerungen oder Ablehnungen sind. Diese Segmentierung ist maßgeblich, um Prozessoptimierungen an die spezifischen Bedürfnisse verschiedener Customer Journeys anzupassen.

Ermöglicht die Segmentierung der ProzessDaten in verschiedene Kategorien, wodurch eine genauere und relevantere Leistungsfähigkeit-Analyse ermöglicht wird.

Dies ist in der Regel der Klassenname der Case-Instanz in Pega oder eine dedizierte Eigenschaft des Falls, die seinen Typ definiert.

Diese berechnete Metrik misst die End-to-End-Dauer für jeden Kundenantrag, vom ersten Event bis zum letzten. Sie wird in der Regel als Differenz zwischen dem Zeitstempel der letzten Aktivität und der initialen Aktivität für einen gegebenen Fall berechnet.

Die Durchlaufzeit ist ein primärer Key Leistungsfähigkeit Indicator (KPI) für Prozesseffizienz und Kundenerfahrung. Sie wird im Dashboard 'Gesamtanalyse der Onboarding-Durchlaufzeit' verwendet, um durchschnittliche Bearbeitungszeiten zu überwachen, langlaufende Fälle zu identifizieren und die Auswirkungen von Prozessoptimierungsinitiativen über die Zeit zu verfolgen.

Dies ist ein kritischer KPI, der den Antrag bearbeitet.irekt die Gesamtgeschwindigkeit und Effizienz des Onboarding-Prozesses aus Kundensicht misst.

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

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

Die Unterscheidung zwischen automatisierten und manuellen Aktivitäten ist maßgeblich für die Automatisierungsanalyse. Sie hilft, die Effektivität bestehender Automatisierung zu messen, manuelle Aufgaben zu identifizieren, die gute KandiDaten für zukünftige Automatisierung sind, und die Interaktion zwischen menschlichen und Systemakteuren im Prozess zu verstehen.

Es trennt von Menschen gesteuerte Aktivitäten von systemgesteuerten, was grundlegend für jede Automatisierungsinitiative oder Analyse ist.

Dies kann aus der mit dem Event verbundenen Benutzer-ID abgeleitet werden. Wenn die OperatorId einem bekannten System- oder Agentenkonto entspricht, wird dieses Flag auf Ja gesetzt.

Dieses Boolean-Attribut ist wahr, wenn eine bestimmte Aktivität: wie etwa die „Dokumentenprüfung“: mehr als einmal innerhalb desselben Case vorkommt. Auslöser sind oft Ereignisse wie „Zusätzliche Informationen angefordert“.

Das Identifizieren von Nacharbeit ist maßgeblich, um Ineffizienzen und Reibungspunkte im Prozess aufzudecken. Das Dashboard „Process Rework and Loops“ verwendet dieses Attribut, um Häufigkeit und Auswirkungen von Rework messbar zu machen. Da weniger Nacharbeit zu schnelleren Durchlaufzeiten, niedrigeren Kosten und einer besseren Customer Experience führt, ist ihre Reduzierung meist ein vorrangiges Ziel.

Hebt Prozessineffizienzen, redundante Aufgaben und Schleifen hervor, die primäre Ziele für die Prozessoptimierung sind.

Dieses Flag wird während der Datenanalyse abgeleitet, indem auf wiederholte Aktivitätsnamen innerhalb derselben Case-ID geprüft wird. Zum Beispiel, wenn 'Dokumentenprüfung abgeschlossen' ein zweites Mal erscheint.

Dieses Attribut ist die eindeutige ID, die den Antrag mit einem Kundenstamm im MasterDatensystem verknüpft. Es repräsentiert die Entität, ob eine Einzelperson oder eine Organisation, die Gegenstand des KYC-Prozesses ist.

Während die Antrags-ID den Prozess verfolgt, ermöglicht die Kunden-ID eine Analyse über mehrere Anträge desselben Kunden hinweg oder den Antrag bearbeitet.ie Anreicherung der ProzessDaten mit kundenspezifischen Attributen wie Segment oder Historie. Dies ermöglicht eine kundenorientierte Sichtweise des Onboarding-Prozesses.

Verbindet die ProzessDaten mit den KundenstammDaten und ermöglicht eine vollständigere Analyse basierend auf Kundenattributen und -historie.

Dies wäre eine Kerneigenschaft des KYC-Falls, die ihn mit dem KundenDatenmodell innerhalb von Pega oder einem externen CRM verknüpft.

Dieses Attribut speichert das Land, das mit dem zu onboardenden Kunden verbunden ist. Diese Information ist ein wichtiger Input für die Risikobewertung und die Bestimmung des erforderlichen Due Diligence-Levels.

In der Analyse kann das Land des Kunden wichtige Muster aufdecken. Bestimmte Jurisdiktionen können mit höherem Risiko verbunden sein, was zu längeren und komplexeren Onboarding-Prozessen führt. Diese Dimension ermöglicht eine geografisch basierte Leistungsanalyse und hilft sicherzustellen, dass regionale Compliance-Anforderungen effizient erfüllt werden.

Ermöglicht eine geografische Analyse des Prozesses, die oft mit regulatorischer Komplexität und Risikostufen verbunden ist.

Dies wäre eine Eigenschaft des KundenDatenobjekts, das mit dem Fall verknüpft ist.

Dieses Attribut gibt den aktuellsten Zeitpunkt an, zu dem die Daten aus dem Quellsystem extrahiert wurden. Er ist in der Regel für alle Datensätze innerhalb eines einzigen Datenladevorgangs gleich.

Dieser Zeitstempel ist wichtig, um die Aktualität der analysierten Daten zu verstehen. Er ermöglicht es Benutzern zu wissen, wie aktuell die Prozessanalyse ist und wann die nächste Datenaktualisierung erwartet wird, was für operative Monitoring-Dashboards wichtig ist.

Informiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie verstehen, ob die Analyse den aktuellen Zustand oder eine vergangene Periode widerspiegelt.

Dieser Wert wird während des Datenextraktions-, Transformations- und Ladeprozesses (ETL) generiert und in den Datensatz zugewiesen.

Dieses Attribut spezifiziert das Produkt oder den Antrag bearbeitet.ie Dienstleistung, für die der Kunde onboarded wird, wie z.B. ein 'Retail Bank Account', 'Corporate Loan' oder 'Investition Dienste'.

Das Produkt kann den Onboarding-Prozess beeinflussen, da verschiedene Produkte unterschiedliche regulatorische Anforderungen und Komplexitäten haben können. Die Analyse des Prozesses nach Produkt hilft festzustellen, ob bestimmte Produktlinien längere Durchlaufzeiten oder höhere Ablehnungsraten aufweisen, und liefert Erkenntnisse für die Produktspezifische Prozessoptimierung.

Ermöglicht die Segmentierung der Prozessanalyse nach Produktlinie, wodurch Leistungsfähigkeit-Unterschiede und Optimierungsmöglichkeiten aufgedeckt werden.

Dies wäre eine Eigenschaft des Falls, ausgewählt zu Beginn des Antragsprozesses.

Dieses Attribut spezifiziert die Quellanwendung, in der den Antrag bearbeitet.as Event aufgezeichnet wurde. Für diesen Prozess wäre der Wert konsistent 'Pega KYC'.

Obwohl es redundant erscheinen mag, wenn alle Daten aus einem System stammen, ist dieses Attribut wichtig für die Daten Governance und wird vital, wenn Daten aus mehreren Systemen integriert werden. Es stellt ... sicher Klarheit über die Datenherkunft und hilft bei der Fehlerbehebung bei Datenintegrationsproblemen.

Es liefert wesentlichen Kontext zur Datenherkunft, stellt ... sicher Daten Governance und ermöglicht Analysen über mehrere Quellsysteme hinweg.

Dies ist in der Regel ein statischer Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.

Dieses Attribut kategorisiert jeden abgeschlossenen Fall als 'Pünktlich' oder 'Spät', basierend auf einem Vergleich zwischen seinem tatsächlichen Abschluss-Zeitstempel und seinem 'SLA-Zieldatum'.

Dies ist die Kernmetrik für das Dashboard 'SLA-Einhaltungs-Tracking' und den KPI 'SLA-Quote'. Es bietet eine klare Übersicht über die Leistung im Vergleich zu Service-Level-Verpflichtungen. Die Analyse der Merkmale verspäteter Fälle hilft, die Grundursachen für Verzögerungen zu identifizieren und Risiken zukünftiger SLA-Verstöße zu mindern.

Misst direkt die Leistungsfähigkeit im Vergleich zu Verpflichtungen, was wichtig für operatives Management, Compliance und Kundenzufriedenheit ist.

Dies wird abgeleitet, indem der Zeitstempel der finalen Case-Aktivität mit dem Feld SlaTargetDate verglichen wird. Wenn die Abschlusszeit nach dem Ziel liegt, ist der Status 'Spät'.