Quality Foundations — Binom Governance

Teil 1

Quality Foundations — Datenqualität verständlich machen

Diese Serie erklärt Data Quality so, dass Fachbereiche, Stewards und technische Teams dieselbe Sprache nutzen können.

Begriffe vor dem Lesen

Data Quality / DQ — Eignung von Daten für einen konkreten Zweck, nicht nur ein technischer Score.
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

Ein Datensatz kann technisch gültig sein und trotzdem für eine Entscheidung unbrauchbar. Pflichtfelder sind gefüllt, Datentypen stimmen, die Pipeline ist grün. Trotzdem fehlt vielleicht eine relevante Kundengruppe, eine Periode ist falsch abgegrenzt oder ein Status bedeutet im Fachbereich etwas anderes als im Report.

Das Problem ist nicht “zu wenig Testing”. Das Problem ist, dass Qualität ohne Zweck nicht bewertbar ist.

Zusätzliche Begriffe

Data Quality — Eignung von Daten für einen konkreten Zweck.
Quality Rule — prüfbare Regel, zum Beispiel Vollständigkeit, Gültigkeit oder Aktualität.
Prüfpunkt — Entscheidungspunkt, an dem ein Ergebnis warnen, stoppen oder freigegeben werden kann.
Data Vereinbarung — Vereinbarung zwischen Producer und Nutzer über Struktur, Bedeutung, Qualität und Änderung.
Proof / Nachweis — Beleg, dass Regel, Prüfung und Entscheidung stattgefunden haben.

Lesepfad

Der Kern

Data Quality beantwortet immer die Frage: Sind diese Daten für diese Entscheidung gut genug?

Dafür braucht es Zweck, Regel, Schwelle, Owner, Reaktion und Nachweis. Ein Test ohne Reaktion ist Beobachtung. Eine Definition ohne Test ist Hoffnung. Ein Nachweis ohne Entscheidung ist Archiv.

Für den Vertrieb

Quality-Projekte lassen sich gut verkaufen, wenn sie an einer konkreten Entscheidung hängen: Close, Forecast, Bestand, Lieferung, Kundenkommunikation oder regulatorisches Reporting. Dann wird aus “wir machen Data Quality” ein verständlicher Projektzuschnitt.

Teil 2

Wann Quality Gates greifen müssen

Diese Story erklärt, wann ein Quality Gate sinnvoll ist und wann eine Warnung reicht.

Ausgangslage

Viele Teams starten mit der Idee, jede Regel hart zu blockieren. Das klingt konsequent, führt aber schnell zu Frust. Andere Teams lassen alles nur warnen; dann werden kritische Fehler zwar gesehen, aber nicht verhindert.

Das Problem ist nicht die Regel. Das Problem ist die falsche Reaktion.

Begriffe vor dem Lesen

Soft Prüfpunkt — warnt und erzeugt Nacharbeit, blockiert aber nicht automatisch.
Hard Prüfpunkt — stoppt Veröffentlichung, Verarbeitung oder Nutzung.
Materialität — Bedeutung eines Fehlers für Entscheidung, Pflicht oder Schaden.
Exception — befristete Ausnahme mit verantwortliche Person, Grund und Ablaufdatum.

Die Regel

Ein Hard Gate gehört an Stellen, an denen falsche Daten einen materiellen Schaden auslösen können: falscher Abschluss, falsche regulatorische Meldung, falsche Kundenkommunikation, unzulässiger Zugriff oder gefährliche operative Entscheidung.

Ein Soft Gate reicht, wenn die Daten weiter nutzbar sind, aber Nacharbeit oder Beobachtung brauchen.

Für den Vertrieb

Im Angebot sollte klar sein, welche Gates geliefert werden und warum. “Wir bauen 200 Tests” ist schwach. “Wir sichern drei kritische Entscheidungen mit passenden Gates und Ausnahmen” ist verständlich.

Warum das wichtig ist

Wann Quality Gates greifen müssen darf kein abstrakter Governance-Satz bleiben innerhalb der Serie Quality Foundations. Der Nutzen entsteht erst, wenn ein Team versteht, welche Entscheidung geschützt wird, wer fachlich zuständig ist, welche Daten oder Prozesse betroffen sind und woran man später erkennt, dass die Vereinbarung wirklich umgesetzt wurde.

Konkretes Beispiel

Ein Fachbereich bereitet einen Report, ein Datenprodukt, einen Workflow oder eine Übergabe an einen Kunden vor. Zuerst wirkt alles geklärt: Es gibt eine Quelle, eine Kennzahl, eine Regel oder einen bestehenden Prozess. Im Review zeigt sich aber, dass verschiedene Teams unterschiedliche Definitionen, Aktualisierungszyklen, Freigaben oder Nachweise meinen. Genau an dieser Stelle hilft Governance: Aus einer allgemeinen Diskussion wird eine konkrete Vereinbarung mit Zweck, Owner, Umsetzung und prüfbarer Evidence.

Mini-Check

Welche fachliche Entscheidung schützt diese Story?
Welche Rolle akzeptiert das Ergebnis aus fachlicher Sicht?
Welches System, welcher Datensatz, Report oder Prozess ist betroffen?
Welcher Nachweis zeigt, dass die Vereinbarung umgesetzt wurde?
Was passiert, wenn die Regel nicht eingehalten werden kann?

Teil 3

Quality Anti-Patterns stoppen

Diese Story sammelt Fehlmuster, die Data Quality gut aussehen lassen, aber im Alltag nicht helfen.

Ausgangslage

Ein Dashboard zeigt hohe Quality Scores. Trotzdem trauen Fachbereiche den Daten nicht. Das passiert, wenn Tests viele technische Details prüfen, aber die eigentliche Entscheidung nicht schützen.

Begriffe vor dem Lesen

Quality Score — verdichteter Qualitätswert; hilfreich als Signal, gefährlich als alleinige Freigabe.
Anti-Pattern — wiederkehrendes Muster, das plausibel klingt, aber schlechte Ergebnisse erzeugt.
verantwortliche Person — Rolle, die die fachliche Nutzbarkeit akzeptiert oder ablehnt.

Häufige Anti-Patterns

Tests ohne Zweck
Gesamtscore statt kritischer Teilmenge
Prüfpunkt ohne Ausnahmeweg
technische Regel ohne fachlichen verantwortliche Person
Screenshot als Nachweis ohne Entscheidung
Katalog-Vollständigkeit als Ersatz für Vertrauen

Für den Vertrieb

Diese Anti-Patterns sind gute Gesprächsöffner. Sie machen Probleme nachvollziehbar, ohne jemanden bloßzustellen.

Warum das wichtig ist

Quality Anti-Patterns stoppen darf kein abstrakter Governance-Satz bleiben innerhalb der Serie Quality Foundations. Der Nutzen entsteht erst, wenn ein Team versteht, welche Entscheidung geschützt wird, wer fachlich zuständig ist, welche Daten oder Prozesse betroffen sind und woran man später erkennt, dass die Vereinbarung wirklich umgesetzt wurde.

Konkretes Beispiel

Ein Fachbereich bereitet einen Report, ein Datenprodukt, einen Workflow oder eine Übergabe an einen Kunden vor. Zuerst wirkt alles geklärt: Es gibt eine Quelle, eine Kennzahl, eine Regel oder einen bestehenden Prozess. Im Review zeigt sich aber, dass verschiedene Teams unterschiedliche Definitionen, Aktualisierungszyklen, Freigaben oder Nachweise meinen. Genau an dieser Stelle hilft Governance: Aus einer allgemeinen Diskussion wird eine konkrete Vereinbarung mit Zweck, Owner, Umsetzung und prüfbarer Evidence.

Mini-Check

Welche fachliche Entscheidung schützt diese Story?
Welche Rolle akzeptiert das Ergebnis aus fachlicher Sicht?
Welches System, welcher Datensatz, Report oder Prozess ist betroffen?
Welcher Nachweis zeigt, dass die Vereinbarung umgesetzt wurde?
Was passiert, wenn die Regel nicht eingehalten werden kann?

Teil 4

Quality in den Betrieb übergeben

Diese Story schließt die Quality-Foundation-Serie ab. Sie zeigt, wie aus Regeln ein betreibbarer Ablauf wird.

Ausgangslage

Ein Projekt endet mit dokumentierten Quality Rules. Danach ändern sich Quellen, Jobs laufen später, Fachbereiche melden Ausnahmen und niemand weiß, wer reagieren muss. Qualität stirbt nicht beim Design, sondern im Betrieb.

Begriffe vor dem Lesen

Operations — laufender Betrieb von Datenprodukten, Regeln, Incidents und Ausnahmen.
Alert — Signal, dass eine Regel verletzt oder ein Zustand riskant ist.
Runbook — kurze Anleitung, wer bei welchem Ereignis was tut.
Exception Register — Liste befristeter Ausnahmen mit Owner und Ablaufdatum.

Der Handoff

Ein Quality-Handoff braucht:

Regel und Zweck
verantwortliche Person für fachliche Bewertung
technischer Betreiber für technische Reaktion
Alert mit Schweregrad
Ausnahmeweg
Nachweisort
Review-Takt

Für den Vertrieb

Ein Quality-Projekt ist erst vollständig, wenn die Übergabe in den Betrieb Teil des Angebots ist. Sonst verkauft man Tests, aber kein Vertrauen.

Warum das wichtig ist

Quality in den Betrieb übergeben darf kein abstrakter Governance-Satz bleiben innerhalb der Serie Quality Foundations. Der Nutzen entsteht erst, wenn ein Team versteht, welche Entscheidung geschützt wird, wer fachlich zuständig ist, welche Daten oder Prozesse betroffen sind und woran man später erkennt, dass die Vereinbarung wirklich umgesetzt wurde.

Konkretes Beispiel

Ein Fachbereich bereitet einen Report, ein Datenprodukt, einen Workflow oder eine Übergabe an einen Kunden vor. Zuerst wirkt alles geklärt: Es gibt eine Quelle, eine Kennzahl, eine Regel oder einen bestehenden Prozess. Im Review zeigt sich aber, dass verschiedene Teams unterschiedliche Definitionen, Aktualisierungszyklen, Freigaben oder Nachweise meinen. Genau an dieser Stelle hilft Governance: Aus einer allgemeinen Diskussion wird eine konkrete Vereinbarung mit Zweck, Owner, Umsetzung und prüfbarer Evidence.

Mini-Check

Welche fachliche Entscheidung schützt diese Story?
Welche Rolle akzeptiert das Ergebnis aus fachlicher Sicht?
Welches System, welcher Datensatz, Report oder Prozess ist betroffen?
Welcher Nachweis zeigt, dass die Vereinbarung umgesetzt wurde?
Was passiert, wenn die Regel nicht eingehalten werden kann?