Die fehlenden Bausteine – Teil 1: Datenqualität

Begriffe vor dem Lesen

• Governance — Gemeinsame Regeln, Rollen und Nachweise, damit Daten verantwortbar genutzt werden.
• verantwortliche Person — Fachlich verantwortliche Person oder Rolle, die Zweck, Bedeutung und Freigabe klärt.
• technischer Betreiber — Technische Rolle, die Plattform, Zugriff, Betrieb oder Umsetzung betreut.
• Nachweis — Nachvollziehbarer Nachweis zu Entscheidung, Prüfung, Umsetzung oder Ausnahme.

Ausgangslage

Fehlende Governance-Schleifen schließen — Fixes brauchen Ursache und Feedback.

Was diese Serie klärt

• Orientierung: Die fehlenden Bausteine – Teil 1: Datenqualität
• Vertiefung: Die fehlenden Bausteine – Teil 2: Vertrauenswürdige Kennzahlen
• Abschluss mit betreibbaren Next Steps über The Missing Pieces – Teil 6: Datenlebenszyklus & Stilllegung

Begriffe und Kürzel vor dem Lesen

• verantwortliche Person — Person oder Rolle mit der Pflicht, Bedeutung, Nutzung, Risiko und Freigabe für ein Datenprodukt oder eine Kennzahl zu entscheiden.
• Metadata — Daten über Daten: Definition, verantwortliche Person, Quelle, Aktualität, Qualität, Klassifikation, Lineage, Status.
• Data Catalog — Auffindbarkeitsschicht für Assets, Begriffe, Owner und Richtlinien — eine Anwendung von Metadata, nicht Metadata selbst.
• Nachweis — Nachweis, dass Kontrolle, Entscheidung oder Test stattfand — Zeitstempel, verantwortliche Person, prüfbare Artefakte.
• Data Vereinbarung — Vereinbarung zwischen Anbieter und Nutzer: Felder, Bedeutung, Qualität, Aktualität, Änderungsvorlauf, Kontakte.
• Lineage — Woher Daten kommen und wohin sie fließen — für Impact-Analyse bei Änderungen.

Lesepfad

1. Die fehlenden Bausteine – Teil 1: Datenqualität
2. Die fehlenden Bausteine – Teil 2: Vertrauenswürdige Kennzahlen
3. Die fehlenden Bausteine – Teil 3: Data Verantwortung & Stewardship
4. Die fehlenden Bausteine – Teil 4: Metadaten, Katalog & Lineage
5. The Missing Pieces – Teil 5: Richtlinien- & Zugriffs-Governance
6. The Missing Pieces – Teil 6: Datenlebenszyklus & Stilllegung

Die Beispiele sind Lehrfälle (keine Kundendaten). Ersetzt Tabellen-, Report-, Pfad- und Toolnamen durch eure Catalog-, BI-, Ticket- und Prozessquellen.

Daten können besser werden, während die Ursache unverändert bleibt

Im Vertriebs-Dashboard wird die Lieferquote grün — weil die Pipeline fehlende Termine nachträglich füllt. Im ERP bleiben die leeren Liefertermine. Die Zahl sieht besser aus; die Ursache ist unverändert.

Bronze-, Silver- und Gold-Schichten sowie Tests sind sinnvoll. Sie schaffen Nachvollziehbarkeit in der Plattform. Sie beantworten aber nicht die Governance-Frage:

Verbessern wir den Prozess, der fehlerhafte Daten erzeugt – oder werden wir nur immer besser darin, seine Fehler downstream zu kompensieren?

Eine Transformation kann einen falschen Wert korrigieren. Sie kann fehlende Daten ergänzen, ungültige Statuswerte ummappen oder Ausnahmen abfangen. Dadurch steigt die Qualität des nachgelagerten Datensatzes.

Der Geschäftsprozess, die Eingabemaske, die Schnittstelle oder das Quellsystem, das den Fehler erzeugt hat, kann dabei jedoch unverändert bleiben.

Genau diese Unterscheidung ist der Ausgangspunkt dieses Playbooks.

Transformation ist nicht das Problem

Transformationen sind ein unverzichtbarer Bestandteil moderner Datenarchitekturen. Viele Regeln gehören dauerhaft in die Datenplattform, weil sie keinen Fehler reparieren, sondern Daten für einen neuen Zweck nutzbar machen.

Die relevante Frage ist daher nicht:

Sollten wir weniger transformieren?

Sondern:

Erzeugt diese Transformation neuen fachlichen Wert – oder kompensiert sie dauerhaft ein Problem, das an seiner Entstehungsstelle behoben werden sollte?

Wenn aus einem temporären Fix eine dauerhafte Abhängigkeit wird

Ein Downstream-Fix kann vollkommen richtig sein. Ein Bericht, eine Abrechnung oder ein regulatorischer Prozess kann nicht immer warten, bis ein operatives System angepasst wurde. Eine Transformationsregel kann die Auswirkungen eines Fehlers schnell begrenzen und den Geschäftsbetrieb schützen.

Das Problem entsteht, wenn der temporäre Charakter verloren geht.

Ein typisches Muster sieht so aus:

Der ursprüngliche Fehler ist für die Nutzer möglicherweise nicht mehr sichtbar. Gleichzeitig bleibt die Quelle unverändert und produziert weiterhin dieselbe Abweichung.

Mit jeder zusätzlichen Schicht entstehen neue Abhängigkeiten:

• dieselbe fachliche Annahme wird an mehreren Stellen implementiert,
• Änderungen müssen mehrfach nachvollzogen werden,
• unterschiedliche Teams können unterschiedliche Korrekturen entwickeln,
• die ursprüngliche Ursache wird im Datenfluss immer schwerer erkennbar,
• neue Data Products übernehmen möglicherweise nur einen Teil der vorhandenen Reparaturlogik.

So kann eine erfolgreiche kurzfristige Maßnahme langfristig zu technischer und fachlicher Schuld werden.

Erkennen ist nicht dasselbe wie Beheben

Data-Quality-Werkzeuge und Tests sind wichtig, weil sie Probleme sichtbar und messbar machen.

Microsoft Purview beschreibt Data Quality als die Bewertung und Überwachung von Datenbeständen, um gezielte Verbesserungsmaßnahmen zu ermöglichen. dbt Data Tests prüfen definierte Annahmen über Quellen und Modelle und liefern die Datensätze zurück, die eine Erwartung verletzen. Source Freshness überwacht zusätzlich, ob Quelldaten innerhalb eines erwarteten Zeitfensters aktualisiert wurden.

Diese Funktionen beantworten wichtige Fragen:

• Sind Pflichtfelder vollständig?
• Sind Schlüssel eindeutig?
• Liegen Werte innerhalb eines gültigen Bereichs?
• Stimmen Beziehungen zwischen Datensätzen?
• Sind Daten aktuell genug?
• Wo und seit wann tritt eine Abweichung auf?

Sie beantworten jedoch nicht automatisch:

• Warum erzeugt der Prozess den Fehler?
• Wer besitzt den verursachenden Geschäftsprozess?
• Muss die Eingabevalidierung, Schnittstelle oder Anwendung angepasst werden?
• Bis wann soll die Ursache behoben sein?
• Wann kann die temporäre Transformationsregel wieder entfernt werden?

Das ist keine Schwäche einzelner Produkte. Es ist die Grenze zwischen technischer Erkennung und organisatorischer Ursachenbehebung.

Der fehlende Feedback Loop

Nachhaltige Datenqualität benötigt einen geschlossenen Kreislauf zwischen Datenplattform und Entstehungsprozess.

Ein mögliches Zielmodell besteht aus sieben Schritten:

1. Erkennen
   Das Problem wird über Profiling, Regeln, Tests, Monitoring oder Nutzerfeedback sichtbar.

2. Auswirkung eindämmen
   Eine temporäre Transformation, Quarantäne-Regel oder fachliche Ausnahme schützt nachgelagerte Prozesse.

3. Verantwortung zuweisen
   Quellsystem, Geschäftsprozess und verantwortlicher Owner werden identifiziert.

4. Ursache analysieren
   Es wird geprüft, warum der Fehler entsteht: fehlende Validierung, unklare Prozessregel, Schnittstellenproblem, Bedienfehler oder falsche Systemlogik.

5. An der Quelle beheben
   Prozess, Anwendung, Schnittstelle oder Validierung werden so angepasst, dass der Fehler nicht weiter erzeugt wird.

6. Validieren und überwachen
   Die Verbesserung wird nachgewiesen und über einen definierten Zeitraum beobachtet.

7. Temporären Fix entfernen
   Nicht mehr benötigte Reparaturlogik wird kontrolliert aus der Pipeline entfernt.

Der letzte Schritt ist besonders wichtig. Bleibt eine alte Korrektur nach dem Source Fix bestehen, kann sie selbst neue Fehler erzeugen oder zukünftige Daten falsch interpretieren.

Welche Rolle spielt der Data Steward?

Der Data Steward sollte nicht automatisch jede technische oder fachliche Ursache selbst beheben. Er ist auch nicht zwingend der Owner des Quellsystems.

Seine zentrale Aufgabe kann darin bestehen, den Qualitätsprozess über Systemgrenzen hinweg steuerbar zu machen:

• Qualitätsproblem und Business Impact dokumentieren,
• betroffene Datenprodukte und Verbraucher identifizieren,
• Source Owner und Process Owner einbinden,
• temporäre Korrektur transparent machen,
• Status, Priorität und Zieltermin nachverfolgen,
• Validierung der Source-Korrektur koordinieren,
• Entscheidung über den Rückbau des Workarounds nachvollziehbar machen.

Damit wird Stewardship mehr als die Pflege eines Katalogeintrags. Es wird zur Verbindung zwischen technischer Beobachtung und fachlicher Verantwortung.

Die eigentliche Änderung bleibt dort, wo sie hingehört:

• Der Process Owner verantwortet den Geschäftsprozess.
• Der System verantwortliche Person verantwortet die Anwendung oder Schnittstelle.
• Das Data Team schützt die Datenprodukte und setzt notwendige temporäre Kontrollen um.
• Der Data Steward koordiniert Definition, Transparenz, Eskalation und Nachverfolgung.

Temporäre Korrekturen brauchen einen Lebenszyklus

Ein Fix sollte nicht nur aus SQL, einer Mapping-Tabelle oder einer zusätzlichen Business Rule bestehen. Er benötigt Governance-Metadaten.

Mindestens folgende Informationen sollten nachvollziehbar sein:

Ein Ablaufdatum muss nicht bedeuten, dass eine Regel automatisch gelöscht wird. Es kann zunächst ein verpflichtendes Review auslösen.

Der wesentliche Punkt ist: Ein temporärer Fix darf nicht unsichtbar zu einem dauerhaften Bestandteil der Architektur werden.

Nicht jeder Fehler kann sofort an der Quelle gelöst werden

Auch ein geschlossenes Governance-Modell braucht Pragmatismus.

Eine Source-Korrektur kann aus guten Gründen Zeit benötigen:

• ein externes SaaS-System lässt sich nur eingeschränkt anpassen,
• eine Lieferantenschnittstelle liegt außerhalb der eigenen Kontrolle,
• eine Legacy-Anwendung wird erst später ersetzt,
• historische Daten bleiben trotz Prozessverbesserung fehlerhaft,
• regulatorische oder operative Fristen erfordern eine sofortige Absicherung.

In solchen Fällen kann eine dauerhafte oder langfristige Transformation die wirtschaftlich sinnvollste Lösung sein.

Entscheidend ist, dass diese Entscheidung bewusst getroffen wird:

Nicht jeder Downstream-Fix ist schlechte Architektur. Problematisch wird er, wenn niemand mehr weiß, warum er existiert, wer ihn verantwortet und ob er noch benötigt wird.

Praktische Leitfragen für Teams

Bei jeder neuen Data-Quality-Regel oder Reparaturtransformation können fünf Fragen helfen:

1. Ist das eine fachliche Transformation oder die Reparatur eines vermeidbaren Fehlers?
2. Kann die Ursache im Quellsystem oder Geschäftsprozess beeinflusst werden?
3. Wer besitzt die Ursachenbehebung – nicht nur den Downstream-Fix?
4. Hat die temporäre Korrektur ein Review-Datum und ein definiertes Zielbild?
5. Wie wird nachgewiesen, dass der Fix später entfernt oder vereinfacht werden kann?

Diese Fragen ersetzen keine Data-Quality-Plattform. Sie ergänzen sie um Verantwortung und Lebenszyklus.

Fazit

Moderne Datenplattformen können Datenqualität innerhalb einer Pipeline deutlich verbessern. Tests, Profiling, Monitoring und Transformationen sind dafür unverzichtbar.

Doch eine hochwertige Gold-Tabelle beweist nicht automatisch, dass der erzeugende Geschäftsprozess hochwertige Daten liefert.

Die fehlende Komponente ist häufig nicht noch ein weiterer Test oder eine weitere Transformationsschicht. Es ist der geschlossene Feedback Loop:

Detect the issue. Contain the impact. Assign ownership. Fix the source. Validate the result. Remove the workaround.

Die entscheidende Frage lautet deshalb:

Verbessern wir die Systeme, die Daten erzeugen – oder kompensieren wir nur immer effizienter ihre wiederkehrenden Probleme?

Weiterführende Ressourcen

• Databricks: What is the medallion lakehouse architecture?
• dbt Developer Hub: Add data tests to your DAG
• dbt Developer Hub: Source freshness
• Microsoft Learn: Overview of data quality in Microsoft Purview Unified Catalog
• Microsoft Learn: Data quality actions in Unified Catalog
• IBM: What is data quality?
• IBM: What is root cause analysis?