Data-Governance-Serie Teil 2 – Warum das Reparieren von Berichten nicht die Datenprobleme löst
Karlsruhe, 27.05.2026 (PresseBox) - Unternehmen begeben sich oft auf eine Data‑Governance‑Reise, weil Datenprobleme sichtbar werden. Häufig hat eine Führungskraft einen Bericht gesehen, dem sie nicht vertraut, und eine Data‑Engineer/Scientist‑ oder Data‑Warehouse‑Rolle zieht los, um im Dschungel der Unternehmensprozesse das „Datenproblem“ zu beheben.
Ursachen finden
Das „Datenproblem“ kann viele Quellen haben:
- Erfassung: Regeln fehlen technisch, Daten werden inkonsistent erfasst (z. B. „DE“, „Ger“, „Germany“).
- Bewegung/Transformation: Fehler in ETL (falsche Joins) oder Spaltenmissbrauch (Telefonnummer in address2).
- Semantik: Begriffe werden unterschiedlich verstanden (z. B. „Unit“).
- Drift: System‑Upgrades verändern Felder; vormals vorhandene Werte gehen verloren.
- Konsum: Der Bericht beantwortet nicht die gestellte Frage.
Symptompatches im Data Warehouse
Überlebende Entwickler:innen kehren oft frustriert von der Expedition im Datenschungel zurück zurück: Mehr Probleme aufgedeckt, Bericht wird im Warehouse nur so korrigiert, dass er „richtig aussieht“. Solche kurzfristigen Patches brechen zwar akute Konflikte, skalieren aber nicht. Data Governance durchbricht diesen Zyklus, weil sie Daten als unternehmensweiten Vermögenswert behandelt: Quellen werden verbessert, Bedeutungen dokumentiert und Verantwortliche benannt.
Der richtige Ansatz
Viele Probleme lassen sich kurzfristig in ETL lösen. Wenn Sie jedoch Systeme integrieren und die Organisation digitalisieren wollen, greifen Patches zu kurz: Drift und semantische Unterschiede wirken sich dann weitreichend aus. Das führt zu einem Wandel: Weg von bottom‑up‑Ad‑hoc‑Fixes hin zu einem top‑down‑Ansatz, in dem Daten zentrale Assets sind und Qualität zur organisatorischen Aufgabe wird. Quellen müssen korrigiert, Interpretation dokumentiert und Ownership definiert sein — das ist der Beginn der Data‑Governance‑Reise.
Der richtige Ansatz richtet sich an den strategischen Zielen des Unternehmens aus. Wer wirklich datengetrieben werden will, definiert konkrete, realistische Ziele: welche Prozesse und Datenbereiche zuerst, mit welchem Zeithorizont. Besser: zentrale Kernprozesse in 1–2 Jahren dokumentieren und integrieren, statt perfekte Daten überall zu fordern.
Kurzstarter‑Checkliste (3 Schritte)
Wähle einen kritischen Prozess und kartiere die Hauptdatenquellen.
Dokumentiere 5–10 zentrale Definitionen für diesen Bereich und notiere die Verantwortlichen.
Bestimme eine(n) Data Steward und miss zwei einfache Erfolgskennzahlen über 6 Monate (z. B. Anteil regelkonformer Datensätze, Anzahl gemeldeter Vorfälle).
Nächster Artikel
Im nächsten Beitrag bespreche ich verschiedene Datenarten innerhalb einer Organisation und wie sie bei Data Governance zusammenspielen.
Autor: Benjamin Kettner
