Überblick und Qualität ab Tag 1

Begriffe vor dem Lesen

• Unbekannte Quelle — System, Datei, API oder Export, dessen Bedeutung, Rechte, Qualität und verantwortliche Person noch nicht sauber geklaert sind.
• Source Umfang — Festlegung, welche Objekte geladen, uebersprungen oder spaeter geprueft werden.
• personenbezogene Daten — Personally Identifiable Information: personenbezogene oder personenbeziehbare Daten.
• Beschreibungsvertrag — Mindestbeschreibung für Zweck, fachliche Ebene, Felder, verantwortliche Person, Qualität und Grenzen.
• verantwortliche Person — Rolle, die Bedeutung, Nutzung und Risiko fachlich akzeptiert.

Qualität, Quellkorrektur und AI-Nutzung

Datenqualität muss sichtbar machen, wo ein Problem behoben wurde. Wenn der Fehler im Quellsystem entsteht, ist die beste Behebung eine Korrektur an der Quelle oder mindestens ein dokumentierter Quellbefund mit Owner. Wenn ETL oder ELT Werte nachgelagert bereinigt, schätzt, mappt oder filtert, braucht diese Änderung Evidence: Regel, Grund, betroffene Felder, Version und erlaubte Nutzung.

Das ist besonders wichtig für AI. Retrieval, Training, Features und Agenten sehen oft nur das nachgelagerte Ergebnis. Ohne Kennzeichnung wissen sie nicht, ob ein Wert beobachtet, korrigiert, geschätzt, defaulted oder ausgeschlossen wurde. Governance muss Unsicherheit und Herkunft erhalten, statt sie hinter einem sauber wirkenden Datensatz zu verstecken.

Ein Überblick über eine unbekannte Quelle ist kein Observability-Kauf und kein vollständiges Warehouse-Profil. Es ist ein Job: Form sehen, Hypothesen notieren, drei Regeln schreiben, die den Grain der Frage schützen. Profiling beweist nicht, dass die Pipeline gut genug für den Close ist.

Zweck, Population und Körnung vor dem Test: Qualität beginnt vor dem ersten Test. Die drei Schleifen: Profiling, Validierung, Observability. Produktnamen vs. Fähigkeiten: Metadaten-Tools.

← Vorheriger Teil · Nächster Teil →

Problem

Vier Verwechslungen:

• Catalog = Überblick. Metadatenimport ohne Frage zählt Objekte, erklärt Won nicht.
• Profil = Qualität. Nullrate 2 % ist Beschreibung, keine Akzeptanz.
• Observability zuerst. Anomalie-Produkte lohnen, wenn ein Produkt kaputtgehen kann — nicht am Start.
• Testbibliothek als Onboarding. Ohne Zweck und Grundgesamtheit sind Tests Theater — Qualität vor dem Test.

PII-Gates aus Teil 3 bleiben stehen: kein Profil mit echten Mails im Catalog.

Entscheidung

Werkzeuge nach Job, nicht nach Logo:

Drei bis fünf Regeln, die den Grain schützen — Salesforce-Pipeline:

1. Opportunity-Id eindeutig im Slice.
2. Stage und CloseDate gesetzt für die Population der Frage.
3. Account existiert (Referenz).
4. Frische: SystemModstamp nicht älter als die vereinbarte Schwelle.
5. Stage nur aus dem vereinbarten Enum — neue Werte sind Triage, keine stille Anpassung.

Negative Amounts ohne Retouren-Kontext sind zuerst Hypothese. Finance erklärt Gutscheine oder Fehler — dann Regel. Das Profil hat gefragt; der Owner hat akzeptiert.

Sizing

Anwendungsbeispiel: Freshness grün, Forecast falsch

Lehrfall. Der Job ist grün. Stage enthält einen neuen Wert Verbal Commit. Amount ist in 8 % der offenen Zeilen null. Engineering will 40 Generic-not-null-Tests.

Korrektur:

• Freshness bleibt Observability — sie beweist keinen Forecast.
• Neuer Stage-Wert: Sales Ops (Experte) erklärt; verantwortliche Person entscheidet, ob Enum erweitert oder Quelle korrigiert wird.
• Null-Amount: Grundgesamtheit prüfen (entwurfene Deals?). Dann eine Regel für die offene Pipeline, nicht für alle historischen Rows.
• Drei Tests an der fachlichen Ebene, nicht vierzig am Raw.

Betriebsablauf (nummeriert)

1. Nur Include-Kandidaten profilieren — Sample, Sandbox, keine PII-Previews.
2. Hypothesen notieren: Keys, Nulls, Enums, Orphans, Verzug.
3. Mit der Hilfskarte klären, was legitim ist — Teil 2.
4. Owner akzeptiert 3–5 Regeln; Custodian implementiert (dbt DQ Rules).
5. Drift: neue Enums und Null-Sprünge als Triage, nicht als stilles Absenken.
6. Observability erst, wenn der Slice Consumer hat.

Handoffs

Anti-Patterns (und warum sie scheitern)

• Nur Profiling. Scheitert, weil Beschreibung keine Akzeptanz ist.
• Observability ohne Produkt. Scheitert als Tool ohne Adressat.
• Tests ohne Zweck. Scheitert am Close trotz grüner Scores.
• Voller Scan als Überblick. Scheitert an Kosten und personenbezogene Daten.
• Catalog-Produkt als Architektur. Scheitert — Fähigkeiten zählen, Metadaten-Tools.
• 80 Raw-Tests. Scheitert an Rauschen; der fachliche Ebene bleibt ungeschützt.

Umsetzung im Alltag

Dieser Einstieg ist kein Kalenderzwang und keine Leseliste. Nimm einen echten Fall, an dem sich die Entscheidung prüfen lässt.

Arbeitsweise: Nutze den verlinkten Plan als Arbeitsfläche für Owner, Termine und offene Punkte. Die fachliche Entscheidung muss trotzdem in der Story verständlich bleiben.

• Arbeitsplan — Governance Project Anfrageweg
• Lernpfad — Governance Project Anfrageweg

Starte mit dem kleinsten Fall, der fachlich wichtig genug ist. Prüfe danach, ob die Entscheidung wirklich auffindbar, umsetzbar und auditierbar ist. Rollenklärung: Wer hilft wem an der Quelle.

30 Tage: Ein Sample-Profil des Slices. Drei Grain-Regeln live. Freshness getrennt von fachlicher Validierung.

90 Tage: Eine Drift-Triage hat eine Regel verschärft oder eine legitime Ausnahme dokumentiert — nicht still ignoriert.

Checkliste

• Überblick läuft auf Include-Sample, nicht auf dem Org-Dump.
• Profiling-Fragen und akzeptierte Regeln sind getrennt.
• 3–5 Regeln schützen die fachliche Ebene der Frage.
• personenbezogene Daten-Samples sind nicht im Profilbericht.
• Observability ist dem Produkt nachgeordnet.
• Neue Enums sind Triage.

Artefakt

Profil- und Regelblatt (Seite 4): Hypothesen, Population, 3–5 Regeln, Runner (dbt/Soda/…), Drift-Weg. Hängt am Source Scope.

Tools

• Source Umfang Builder
• dbt DQ Rules Generator
• dbt DQ Macro Generator
• Schema YML Editor

Weiterführend

• Qualität beginnt vor dem ersten Test
• Profiling, Validierung und Observability
• Metadaten-Tools und Produktkategorien
• Quality Gates und Verträge