# PRECOG · BFSI Data Governance Discovery Playbook ## Über dieses Playbook Strukturiert 8 Painpoint-Cluster mit Symptomsprache, Discovery-Fragen und regulatorischen Hebeln für Bank- und Versicherungskontexte. Kein Framework-Marketing — pure Gesprächssteuerung für Sales & Consulting. Nutze es als Quick-Referenz im Kundengespräch. ## Quick-Reference: 8 Cluster | Cluster | # Painpoints | Kernfrage | Top-Regulatorik | |---------|-------------|-----------|-----------------| | Governance | 15 | Wer entscheidet wirklich über Datenstandards? | MaRisk, EU AI Act, DORA | | Quality | 5 | Warum gilt DQ als IT-Projekt statt Fachaufgabe? | BCBS 239, Solvency II | | Architecture | 31 | Folgt Architektur Geschäftszielen oder Tool-Pitches? | DORA, MaRisk | | Mesh | 12 | Plattform-Team: Enabler oder neuer Bottleneck? | EU AI Act, DSGVO | | MDM | 7 | Quelle "der Master" — und was bei Ausfall? | BCBS 239, Solvency II | | Metadata | 15 | Glossar und technische Metadaten: ein oder zwei Universen? | DSGVO, EU AI Act | | Security | 4 | Wer hat echten Zugriff — und wird es auditiert? | DORA, MaRisk, DSGVO | | Regulation | 6 | Erfüllung: Fachprozess oder Compliance-Theater? | BCBS 239, Solvency II, DORA | --- ## Cluster 1: Governance ### Häufige Symptome im Kundegespräch - Governance-Richtlinien werden verabschiedet, aber niemand kontrolliert die Einhaltung. - Der Data Council trifft sich halbjährlich — Beschlüsse verdunsten im E-Mail-Traktus. - RACI bleibt auf PowerPoint stehen; Business Owner delegieren alles an IT. - Governance wird als IT-Projekt gebudgetet, nicht als Fachbereichsaufgabe. ### 5 Discovery-Fragen 1. "Wie wird durchgesetzt, dass Business-Stammdaten vom Fachbereich gepflegt werden?" 2. "Was passiert konkret bei Verstößen gegen Datenstandards — Eskalationspfade oder nur Verweise?" 3. "Wie misst der CDO den Reinertrag von Data Governance — außer implementierten Richtlinien?" 4. "Wer ist Decision-Maker für Datenstandards: CDO, Chief Risk Officer oder das Fachvorstandspult?" 5. "Wann wurde die letzte Revision Ihrer Governance-Richtlinien durchgeführt — nicht nur verabschiedet?" ### Top-3 Sofortmaßnahmen 1. **Governance-Light-Start:** Data Council mit Quarterly Business Review und klaren Escalation-Leveln zum Vorstand. 2. **RACI-Mapping für Top-20-Datenbereiche** (Kunde, Vertrag, Risiko, Kapital) — regulatorisch kritische Domänen zuerst. 3. **Executive Data Dashboard:** Board-ready Report mit Standards-Einhaltungsrate, Issue-to-Resolution-Time, Business Owner Response Rate. ### Regulatorischer Hebel MaRisk BaM 4.2 und DORA Art. 5(3) fordern nachweisbare Governance-Struktur mit klarer Verantwortung — auditierbar, nicht deklaratorisch. Die Lücke zwischen erklärter und durchgesetzter Governance ist dein Hebel. ### Empfohlene Tools Collibra (Policy & Ownership), Informatica DGC (Governance Workflow), MANTA (DataOps-nahe Governance) --- ## Cluster 2: Quality ### Häufige Symptome im Kundegespräch - DQ-Metriken werden berechnet — aber niemand handelt daraus. - DQ-Chacks laufen im Batch; Fachbereiche sehen Ergebnisse erst am Montag. - Es gibt DQ-Regeln pro System, aber keine übergreifende Konsistenzprüfung. - DQ wird als IT-Projekt behandelt; die Fachbereiche verweisen zurück. ### 5 Discovery-Fragen 1. "Wie viele DQ-Regeln haben letzten Quartal zu einem Geschäftsentschluss geführt?" 2. "Wer entscheidet bei Konflikten um Datenqualität: IT oder das Risk-Pult?" 3. "Wie schnell merkt ein Fachbereich, dass seine KPI-Qualität eingebrochen ist?" 4. "Welche DQ-Probleme führten bereits zu regulatorischen Nachlässen?" 5. "Wie sieht der Escalation-Pfad bei kritischen DQ-Regelverletzungen aus?" ### Top-3 Sofortmaßnahmen 1. **DQ-Monitoring als Fachprozess:** DQ-Business-Owner statt IT-Steuermann; monatlicher Review mit Risk/Finance. 2. **Fach-Dashboard mit Live-Fail-Rates** — nicht IT-intern, sondern für den Entscheidungsträger. 3. **Top 3 DQ-Regeln priorisieren** (Kreditportfolio, Solvency-II-QR). ### Regulatorischer Hebel BCBS 239(10) und Solvency II Art. 43 verlangen Datenqualitätsrahmen als Geschäftsprozess — nicht IT-Projekt. Das schafft regulatorischen Imperativ für DQ als Fachaufgabe. ### Empfohlene Tools Ataccama (DQ mit Business-Integration), Informatica DQM, Collibra DQ --- ## Cluster 3: Architecture ### Häufige Symptome im Kundegespräch - Architektur folgt Tool-Käufen — nicht Geschäftszielen. - Jede neue Plattform bringt Silo-Tabellen und Master-Daten-Chaos. - 47 Point-to-Point-Integrations zwischen Systemlandschaften, niemand kennt alle. - Architekturentscheidungen ohne Input aus Risk, Finance oder Compliance. ### 5 Discovery-Fragen 1. "Wie viele Plattformen betreiben Sie parallel für Datenintegration?" 2. "Welche regulatorischen Risiken entstehen durch Ihre aktuellen Architektur-Kompromisse?" 3. "Wie sieht Ihre Data Lineage von Systemquelle bis Regulator-Report aus?" 4. "Wer entscheidet über Architekturstandards: Enterprise Architecture, CDO oder Fachvorstand?" 5. "Für wie viele Datenbereiche existiert keine durchgängige Data Lineage?" ### Top-3 Sofortmaßnahmen 1. **Architektur-Blueprint mit 18-Monats-Roadmap** — regulatorische Datenpfade priorisieren. 2. **Data-Lineage-Pilot für Solvency II oder BCBS 239**: vollautomatisiert von Quelle bis Report. 3. **Plattform-Konsolidierung:** Top-5 Redundanzen durch gemeinsame Integrationslayer ersetzen (Databricks + Denodo). ### Regulatorischer Hebel DORA Art. 5(1) und MaRisk BaM 4.2 fordern nachweisbare IT-Architektur mit durchgehender Datenlinie bis zum Management-Report — nur mit kontrollierter Architektur erfüllbar. ### Empfohlene Tools Snowflake + Databricks (Foundation), Denodo (Virtual Layer), Collibra (Architecture Catalog) --- ## Cluster 4: Mesh ### Häufige Symptome im Kundesprach - Plattform-Team wird zum Engpass statt Enabler. - Domänen bauen eigene Data Products mit eigenen Tools und Standards. - Data Products existieren auf Papier, werden aber nicht produktiv genutzt. - Plattform zu zentralistisch für Governance oder zu dezentralistisch für Mesh. ### 5 Discovery-Fragen 1. "Wie viele Data Products werden tatsächlich im Geschäftsprozess genutzt?" 2. "Wer stellt Platform-Komponenten bereit: zentralisiert, federiert, oder selbst? Wie sehen die SLOs aus?" 3. "Wie gewährleisten Sie Governance über Domänen-Grenzen hinweg?" 4. "Was ist Time-to-First-Value für ein neues Data Product in Ihrem Kontext?" 5. "Wie messen Sie Mesh-Erfolg: nach Produkten, genutzten Domains oder regulatorischer Erfüllung?" ### Top-3 Sofortmaßnahmen 1. **Platform-as-a-Product** mit SLA-basierter Self-Service — Enabler statt Gatekeeper. 2. **Domänen-Pilot:** 2–3 regulatorisch kritische Domänen priorisieren (Risk, Finance). 3. **Mesh-Governance:** Vereinheitlichte Data Contracts + Domain-Level Policy Enforcement via Collibra/Ataccama. ### Regulatorischer Hebel EU AI Act(52–56) und DORA verlangen durchgängige Nachverfolgbarkeit über Systemgrenzen hinweg — ein Data Mesh darf regulatorische Kontrolle nicht aufbrechen, sondern muss sie per Design ermöglichen. ### Empfohlene Tools Databricks (Data Product Foundation), Denodo (Cross-Domain Vizzz), Collibra (Mesh Governance) --- ## Cluster 5: MDM ### Häufige Symptome im Kundesprach - Mehrere Master-Quellen ohne Survivorship-Regel. - Stammdaten-Mapping als Dauerprojekt ohne Abschluss. - Jedes System hat eigene Kunden-Sicht; keine will die andere Quelle akzeptieren. - MDM steht, aber Fachbereiche pflegen weiter eigene Excel-Master. ### 5 Discovery-Fragen 1. "Wie viele Master-Sichten pro Datenentität existieren in Ihrer Organisation?" 2. "Welche Survivorship-Regel gilt bei Widersprüchen — und wie wird sie durchgesetzt?" 3. "Wer ist autoritativer Source of Truth für Kunde, Vertrag, Produkt?" 4. "Wie schnell propagiert sich ein Master-Daten-Update auf alle abhängigen Systeme?" 5. "Welche regulatorischen Reports basieren auf nicht-konsistenten Master-Daten?" ### Top-3 Sofortmaßnahmen 1. **Survivorship-Rules für Top-5-Entitäten** (Kunde, Vertrag, Produkt, Gegenpartei, Sicherung). 2. **MDM-Onboarding als Fachprozess:** IT-Workarounds unterbinden. 3. **Master-Daten-Qualitätsmonitoring** mit Alert bei Survivorship-Violation. ### Regulatorischer Hebel BCBS 239(7), Solvency II Art. 43 und MaRisk BaM 4.2.1 verlangen konsistente, eindeutige Datenquellen — multiple Masters sind ein Compliance-Risiko. ### Empfohlene Tools Informatica MDM, Alation (Metadata-driven), Collibra (MDM Governance) --- ## Cluster 6: Metadata ### Häufige Symptome im Kundesprach - Business-Glossar und technische Metadaten in zwei Universen. - Catalog von der IT gepflegt — "nicht verständlich" für Fachabteilungen. - Metadata importiert, nie kuratiert: kein menschlicher Touch. - Catalog hat Tausende Assets — aber niemand findet Gesuchtes. ### 5 Discovery-Fragen 1. "Wie viele Datenbereiche haben durchgängige technische und geschäftliche Metadaten-Abdeckung?" 2. "Wer kuratiert Metadaten: automatisiert, von der IT oder gemeinsam mit Fachbereichen?" 3. "Wie verknüpfen Sie Business-Glossar-Einträge mit technischen Assets?" 4. "Wie viele Catalog-Assets werden regelmäßig von der Fachabteilung genutzt?" 5. "Wo klappt regulatorische Data Lineage bereits, wo nicht?" ### Top-3 Sofortmaßnahmen 1. **Metadata als gemeinsame Aufgabe:** IT liefert Rohdaten, Fachbereiche kuratieren Business-Bedeutung. 2. **Glossar-Catalog-Integration** via Collibra/Alation (automatischer Link). 3. **Active Metadata Monitoring:** Usage-Metriken für Catalog; Top-50 Assets manuell kuratieren. ### Regulatorischer Hebel DSGVO Art. 30 und EU AI Act Art. 10–12 verlangen Nachverfolgbarkeit und Metadata-Kuration — ohne kuratierte Metadaten nicht erfüllbar. ### Empfohlene Tools Alation (Metadata Fabric), Collibra (Business-Tech-Integration), MANTA/Atlan (Active Metadata) --- ## Cluster 7: Security ### Häufige Symptome im Kundesprach - DBA-Vollzugriff auf alle Produktivdaten ohne zeitliche Begrenzung oder Audit. - Datenklassifizierung als Liste — Zugriffskontrollen basieren noch auf Rollen aus 2018. - Sensitive Data verteilt im Lake, nirgends systematisch maskiert/verschlüsselt. - Access Reviews jährlich: alles wird wieder freigegeben. ### 5 Discovery-Fragen 1. "Wie wirkt sich Ihre Datenklassifizierung direkt auf Zugriffskontrollen aus?" 2. "Welche Mechanismen existieren für just-in-time vs. permanente Berechtigungen?" 3. "Wie oft werden Access Reviews durchgeführt — und was passiert mit Overprivileged-Accounts?" 4. "Wo liegen sensitive Daten systematisch — und sind sie maskiert/verschlüsselt?" 5. "Least-Privilege über alle Plattformen: IAM, RBAC, ABAC oder Kombination?" ### Top-3 Sofortmaßnahmen 1. **Datenklassifizierung + Access Mapping** für Top-20 regulatorisch kritische Bereiche. 2. **Dynamic Data Masking** nach Klassifizierung — keine manuelle Policy pro System. 3. **Quarterly Access Reviews mit automatischer Entprivilegierung** via Immuta/Denodo. ### Regulatorischer Hebel DORA(18–21), DSGVO Art. 32 und MaRisk BaA 4.6.1 fordern strenge Zugriffskontrollen, Masking und Least-Privilege — permanente DBA-Rechte sind kein Compliance-Weg. ### Empfohlene Tools Immuta (Policy-based Access), Denodo (Dynamic Masking), Snowflake (Row/Column Security) --- ## Cluster 8: Regulation ### Häufige Symptome im Kundesprach - Erfüllung in Silos: Risk tut BCBS, Finance tut IFRS9, IT tut Integration. - BCBS 239 als Audit-Projekt mit Checkliste — kein durchgehender Datenprozess. - Regulatorischer Report aus Excel-Sheet eines Angestellten. - Compliance prüft Dokumentation, nicht die Datenbasis selbst. ### 5 Discovery-Fragen 1. "Wie viele regulatorische Reports basieren auf manuell gepflegten Excelsheets?" 2. "Wo existiert Data Lineage über Systemgrenzen bereits automatisiert?" 3. "Wie wird regulatorische Datenqualität kontinuierlich statt nur fristgerecht sichergestellt?" 4. "Wer prüft die regulatorische Datenbasis: Compliance, CDO oder Fachvorstand?" 5. "Welche datenbasierten Non-Compliance-Finde gab es in den letzten 3 Jahren?" ### Top-3 Sofortmaßnahmen 1. **Regulatory-Priorisierung:** Top-3 Reports mit höchstem Daten-Risiko identifizieren und automatisieren. 2. **End-to-End Data Lineage** für regulatorische Reports: technisch hergeleitet, nicht manuell dokumentiert. 3. **DQ Framework eingebettet in Reporting-Pipelines** als Gate vor Publikation. ### Regulatorischer Hebel BCBS 239(7–10), Solvency II Art. 43–45, DORA Art. 5(3): Datenqualität, Lineage und Accountability sind regulatorisch verbindlich mit konkreten Sanktionsrisiken. Kein IT-Use-Case — Compliance-Grundlage. ### Empfohlene Tools Collibra (Regulatory Mapping), Ataccama (DQ für Pipelines), Informatica (Report Automation) --- ## Sales-Eskalationsmuster Wechsle Governance→Quality, wenn der Kunde sagt "wir haben Policies, aber die Fachbereiche halten sich nicht daran" — das ist ein Adoption-Problem. Wechsle zu Quality→Mesh, wenn Silo-Daten und Plattform-Chaos als Grundursache erkennbar sind: Governance allein funktioniert dann nicht. Switch zu Mesh→Architecture, wenn das Plattform-Team zum Bottleneck wird oder jedes Team eigene Tools baut — dann braucht es einen Architektur-Reset, bevor neue Governance-Richtlinien Sinn machen.