Datenqualitätsprobleme sind selten unsichtbar. In den meisten Unternehmen ist bekannt, wo Stammdaten lückenhaft sind, welche Kennzahlen regelmäßig diskutiert werden oder an welchen Stellen Daten aus verschiedenen Systemen nicht zusammenpassen. Schwieriger wird es bei der Frage, was danach passiert. Wer entscheidet, ob ein Fehler geschäftskritisch ist? Wer legt fest, welche Qualität für einen bestimmten Datensatz ausreicht? Wer priorisiert die Behebung, wenn mehrere Fachbereiche betroffen sind? Und wer darf verbindlich festlegen, welche Definition künftig gilt?
Technische Systeme können Daten prüfen, Abweichungen erkennen und Alerts auslösen. Sie können aber nicht entscheiden, welche fachliche Bedeutung ein Problem hat. Genau dafür braucht es deshalb klar geregelte Verantwortung.
Data Ownership setzt an diesem Punkt an. Der Begriff ist etwas missverständlich, denn es geht nicht um Eigentum im juristischen Sinn. Gemeint ist die fachliche Verantwortung für einen definierten Datenbereich: für seine Bedeutung, die Qualitätsanforderungen, zulässige Nutzung und die Entscheidungen, die bei Konflikten oder Abweichungen getroffen werden müssen. Ein Data Owner ist damit keine zusätzliche Rolle für das Organigramm, sondern Teil eines funktionierenden Betriebsmodells für Daten.
Viele Qualitätsprobleme werden erst im Reporting oder auf der Datenplattform sichtbar, obwohl ihre Ursache deutlich früher beginnt. Ein Kunde wird im CRM doppelt angelegt oder ein Produkt ohne Warengruppe erfasst. Ein Lieferdatum wird in einem operativen Prozess anders interpretiert als im Reporting. Eine Kennzahl wird technisch korrekt berechnet, obwohl Finance und Vertrieb unterschiedliche Definitionen zugrunde legen.
Datenqualität lässt sich deshalb nicht sinnvoll einer einzigen technischen Instanz zuordnen. Sie entsteht über den gesamten Lebenszyklus hinweg – von der Erfassung im Quellsystem bis zur Nutzung in Reporting, Planung, Analytics oder KI-Anwendungen.
Dabei hilft die Unterscheidung zwischen technischer und fachlicher Datenqualität.
Technische Datenqualität betrifft etwa Verfügbarkeit, Schema, Datentypen, vollständige Loads, Pipeline-Stabilität oder Freshness. Diese Themen liegen typischerweise bei IT und Data Engineering.
Fachliche Datenqualität beantwortet dagegen die Frage, ob Daten für ihren vorgesehenen Zweck korrekt und brauchbar sind. Ist der Kunde dem richtigen Segment zugeordnet? Ist ein Produkt vollständig klassifiziert? Stimmt die Definition eines aktiven Kunden? Ist ein Datenstand aktuell genug, um eine operative Entscheidung zu unterstützen?
Technische Systeme können solche Anforderungen nur prüfen, wenn vorher festgelegt wurde, was fachlich gelten soll. Genau hier beginnt die Verantwortung des Data Owners.
In vielen Governance-Modellen wird der Data Owner als „verantwortlich für eine Datendomäne“ beschrieben. Das ist korrekt, bleibt aber abstrakt, denn in der Praxis ist wichtiger welche Entscheidungen mit dieser Verantwortung verbunden sind.
Ein Data Owner sollte beispielsweise entscheiden oder verbindlich mitentscheiden können,
Das wird besonders relevant, sobald mehrere Bereiche dieselben Daten nutzen. Kundendaten betreffen zum Beispiel Vertrieb, Marketing, Finance und Analytics. Produktdaten fließen in Einkauf, Logistik, Vertrieb und Reporting ein. Sobald diese Bereiche unterschiedliche Anforderungen oder Definitionen haben, reicht operative Datenpflege nicht mehr aus. Es braucht eine Instanz, die eine fachliche Entscheidung herbeiführen kann.
Einer der häufigsten Fehler besteht darin, Ownership formal zu vergeben, ohne die Rolle mit echtem Mandat auszustatten. In einer Governance-Matrix steht dann beispielsweise die Vertriebsleitung als Owner der Kundendomäne. Gleichzeitig ist weder definiert, welche Entscheidungen damit verbunden sind, noch wie viel Zeit für diese Aufgabe vorgesehen ist oder wie Konflikte mit anderen Bereichen gelöst werden. Die Rolle existiert, kann aber kaum wirken.
Ein funktionierendes Ownership-Modell braucht deshalb mindestens drei Dinge:
Mandat: Welche Entscheidungen darf der Owner verbindlich treffen?
Zeit: Ist die Verantwortung im tatsächlichen Aufgabenprofil verankert oder nur zusätzlich vergeben?
Eskalationsweg: Was passiert, wenn Interessen verschiedener Bereiche nicht zusammenpassen?
Gute Governance trennt Verantwortlichkeiten, statt sie in einer Rolle zu bündeln.
Der Data Owner trägt die fachliche Verantwortung. Er oder sie entscheidet über Definitionen, Qualitätsanforderungen und Prioritäten.
Der Data Steward arbeitet näher am täglichen Datenbetrieb. Stewards pflegen Definitionen und Metadaten, begleiten Qualitätsregeln, analysieren Auffälligkeiten und koordinieren Korrekturen.
Die technische Verantwortung liegt bei System Ownern, Data Engineers, BI- oder Plattformteams. Sie sorgt dafür, dass Daten zuverlässig bereitgestellt, transformiert und überwacht werden.
Ein Beispiel macht die Aufteilung greifbarer: Bei acht Prozent der aktiven Produkte fehlt eine gültige Warengruppe. Der Data Steward stellt die Abweichung fest und untersucht, welche Datensätze betroffen sind. Der Data Owner entscheidet, für welche Produktgruppen das Attribut verpflichtend sein muss und welcher Zielwert akzeptabel ist. Der zuständige Fachbereich passt gegebenenfalls den Erfassungsprozess an. Der System Owner sorgt dafür, dass im ERP künftig eine passende Prüfung erfolgt. Keiner dieser Beteiligten kann das Problem allein lösen.
Ein verbreiteter Fehler im Datenqualitätsmanagement besteht auch darin, Qualität als absoluten Wert zu betrachten. Ein Score von 98 Prozent klingt zunächst zwar gut, ohne Kontext sagt er aber wenig aus. Die eigentlich relevante Frage lautet: 98 Prozent wovon – und wofür?
Eine fehlende Telefonnummer kann für eine Finanzanalyse völlig irrelevant sein, während ein fehlender Steuerschlüssel dagegen erhebliche Folgen haben kann. Ein Datenstand von gestern reicht für ein monatliches Management-Reporting möglicherweise aus, wäre für eine operative Disposition aber zu alt.
Qualitätsanforderungen müssen deshalb aus dem Nutzungszweck abgeleitet werden. Typische Dimensionen sind dabei Vollständigkeit, Validität, Konsistenz, Eindeutigkeit, Aktualität und Genauigkeit. Die Aufgabe des Data Owners ist es festzulegen, welche davon relevant sind und welches Qualitätsniveau benötigt wird.
Ein ERP-System kann tausende Attribute enthalten, ein Data Warehouse noch deutlich mehr. Würde für jedes Element ein Owner, ein Steward, ein Quality Target und ein Eskalationsprozess definiert, entstünde vor allem Bürokratie. Praktikabler ist eine risikobasierte Herangehensweise.
Dabei werden zunächst Critical Data Elements identifiziert – also Daten, deren Qualität für wichtige Prozesse, regulatorische Anforderungen, zentrale Reports oder Datenprodukte besonders relevant ist.
Für solche Elemente sollte mindestens geklärt sein:
So wird Governance dort konkret, wo schlechte Daten tatsächlich ein relevantes Risiko darstellen.
Schwieriger wird es, sobald aus einer Abweichung eine konkrete Maßnahme werden soll. Fällt beispielsweise der Anteil korrekt zugeordneter Vertriebsgebiete bei aktiven Kunden von 99 auf 94 Prozent, ist damit zunächst nur bekannt, dass eine definierte Qualitätsgrenze unterschritten wurde. Ob daraus tatsächlich ein geschäftliches Risiko entsteht, wie dringend gehandelt werden muss und wo die Ursache liegt, ist noch offen.
Genau an dieser Stelle braucht Datenqualitätsmanagement einen geregelten Umgang mit Abweichungen. Es muss klar sein, wer die fachliche Relevanz bewertet, wer die Ursachenanalyse übernimmt und wer Änderungen im betroffenen Prozess oder Quellsystem veranlassen kann. Ebenso wichtig ist die Frage, wann ein Problem als gelöst gilt und wie überprüft wird, ob die Korrektur tatsächlich wirkt.
Ein belastbarer Prozess sieht deshalb eher so aus:
Regel definieren → messen → Abweichung erkennen → bewerten → Ursache analysieren → beheben → erneut prüfen
Dazu gehört auch Kapazität für die Behebung. Wenn Qualitätsprobleme regelmäßig erkannt werden, aber niemand Zeit für Analyse und Korrektur eingeplant hat, verliert selbst gutes Monitoring schnell seinen Wert.
In gewachsenen BI- und Data-Warehouse-Landschaften entstehen schnell umfangreiche Korrekturlogiken. Dabei sollte ein Problem möglichst dort behoben werden, wo es entsteht: Ein falsch erfasster Kunde gehört ins CRM, fehlende Produktattribute in den jeweiligen Erfassungsprozess und ein Fehler in der Transformation ins Data-Team.
Hilfreich ist die Unterscheidung zwischen drei Ursachen:
Source Issue: Der Fehler entsteht im Quellsystem oder bei der Datenerfassung.
Processing Issue: Der Fehler entsteht bei Übertragung oder Transformation.
Definition Issue: Die fachliche Regel ist unklar oder wird unterschiedlich interpretiert.
Diese Trennung verhindert, dass Data Engineering dauerhaft fachliche Probleme mit technischen Korrekturen kaschiert – oder umgekehrt jedes Problem pauschal an den Fachbereich zurückgegeben wird.
Data Ownership sollte nicht mit dem Versuch beginnen, sämtliche Unternehmensdaten vollständig zu katalogisieren und Rollen für jede Tabelle zu vergeben. Sinnvoller ist ein klar abgegrenzter Geschäftsbereich, ein Datenprodukt oder ein konkretes Qualitätsproblem.
Dort lässt sich zunächst klären:
Für die wichtigsten Datenelemente sollten anschließend mindestens fachliche Definition, Owner, führendes Quellsystem, Qualitätsregeln, Schwellenwerte und Eskalationswege dokumentiert werden. Für den Einstieg kann es völlig ausreichen, dieses Modell zunächst auf wenige kritische Datenobjekte anzuwenden.
Wichtiger als Vollständigkeit ist, dass die Verantwortung im Alltag greift. Wenn ein Qualitätsproblem auftritt, sollte klar sein, wer bewertet, wer entscheidet und wer die Behebung umsetzt. Nur dann beginnt Data Governance auch wirklich zu wirken.
Data Ownership schafft Klarheit darüber, wer fachliche Entscheidungen zu Daten treffen kann und welche Qualitätsanforderungen verbindlich gelten. Besonders wichtig wird diese Verantwortung dort, wo mehrere Bereiche dieselben Daten nutzen oder Qualitätsprobleme Auswirkungen auf Reporting, Prozesse und Entscheidungen haben.
Wie gut ein Ownership-Modell funktioniert, zeigt sich deshalb nicht in der Rollenbeschreibung, sondern im Umgang mit konkreten Problemen. Zuständigkeiten, Eskalationswege und Entscheidungsbefugnisse müssen so geregelt sein, dass Abweichungen nicht zwischen Fachbereich, IT und Data-Team liegen bleiben.
Gut umgesetzt wird Data Ownership damit zu einem festen Bestandteil des Datenbetriebs. Es verbindet fachliche Verantwortung mit Datenqualität und sorgt dafür, dass Probleme dort gelöst werden, wo ihre Ursache tatsächlich liegt.