Datenqualität ist ein Organisationsproblem

Das Muster ist in vielen Organisationen dasselbe. Ein Bericht liefert widersprüchliche Zahlen, eine Auswertung scheitert an Dubletten, ein KI-Projekt kommt nicht voran, weil die Daten „nicht sauber“ sind. Also wird ein Datenqualitätsprojekt aufgesetzt, meist in der IT oder im BI-Team. Es bereinigt, dedupliziert, ergänzt Pflichtfelder. Ein halbes Jahr später ist die Qualität wieder da, wo sie war.

Meine These: Das liegt nicht an schlechter Technik und auch nicht an nachlässigen Menschen. Schlechte Daten sind in den meisten Fällen die logische Folge davon, wie Verantwortung und Anreize in einer Organisation verteilt sind. Wer das Problem technisch löst, behandelt das Symptom.

Die Asymmetrie: Wer Daten erzeugt, nutzt sie selten

Daten entstehen überwiegend als Nebenprodukt der eigentlichen Arbeit. Die Vertriebsmitarbeiterin pflegt das CRM, weil sie muss, nicht weil sie die Daten braucht. Der Sachbearbeiter füllt ein Formularfeld aus, dessen Zweck ihm niemand erklärt hat. Genutzt werden diese Daten später an ganz anderer Stelle: im Controlling, in der Planung, in einem Analysemodell.

Daraus entsteht eine Asymmetrie. Die Erzeugenden tragen den Aufwand sorgfältiger Erfassung, spüren aber die Folgen schlechter Qualität nicht. Die Nutzenden spüren die Folgen, haben aber keinen Einfluss auf die Erfassung. Unter diesen Bedingungen ist das Pflichtfeld mit dem Eintrag „Sonstiges“ keine Nachlässigkeit, sondern eine vernünftige Abwägung.

Definitionen sind politisch

Der zweite Grund liegt tiefer. Viele Qualitätsprobleme sind in Wahrheit Definitionskonflikte. Zählt ein Kunde, der seit zwei Jahren nichts gekauft hat, noch als Kunde? Wird Umsatz bei Auftragseingang oder bei Rechnungsstellung gebucht? Gehört ein Projekt zur Abteilung, die es beantragt hat, oder zu der, die es umsetzt?

Diese Fragen klingen technisch, entscheiden aber über Budgets, Erfolge und Zuständigkeiten. Deshalb werden sie selten geklärt, und das Data Warehouse übernimmt am Ende zwei Definitionen nebeneinander. Das ist eine Form von politischem Widerstand, der sich als Datenproblem tarnt.

Qualität ist relativ zum Zweck

Joseph M. Juran (1904–2008), in Rumänien geboren und in den USA aufgewachsen, gehört zu den Begründern des modernen Qualitätsmanagements. Seine Arbeit prägte ab den 1950er Jahren insbesondere die japanische Industrie. Juran definierte Qualität nicht als Fehlerfreiheit an sich, sondern als „fitness for use“: Eignung für den Verwendungszweck. Ein Produkt ist gut, wenn es für das, wofür es gebraucht wird, taugt.

Dasselbe gilt für Daten. Die Informatiker Richard Wang und Diane Strong haben 1996 in einer vielzitierten Studie Datennutzende befragt, was für sie gute Daten ausmacht, und festgestellt, dass Korrektheit nur eine von vielen Anforderungen ist. In der Praxis werden heute meist diese Qualitätsdimensionen unterschieden:

• Vollständigkeit: Sind alle benötigten Werte vorhanden, oder fehlen etwa Postleitzahlen?
• Korrektheit: Stimmen die Werte mit der Wirklichkeit überein, wohnt die Kundin also tatsächlich unter dieser Adresse?
• Konsistenz: Passen die Daten in verschiedenen Systemen zusammen, oder hat derselbe Kunde im CRM einen anderen Namen als in der Buchhaltung?
• Aktualität: Sind die Daten für den Zweck aktuell genug? Eine Adresse von vor fünf Jahren taugt nicht für den Versand.
• Eindeutigkeit: Ist jedes Objekt nur einmal erfasst, oder gibt es Dubletten?

Keine dieser Dimensionen ist ein Selbstzweck. Eine Adressdatenbank mit veralteten Einträgen kann für eine grobe regionale Auswertung gut genug und für die Rechnungsstellung unbrauchbar sein.

Daraus folgt: Datenqualität lässt sich nicht zentral und abstrakt festlegen. Sie muss dort definiert werden, wo man den Zweck kennt, und das ist der Fachbereich.

Datenverantwortung als Rolle

Etablierte Data-Governance-Ansätze, etwa das Handbuch DAMA-DMBOK der internationalen Data Management Association, unterscheiden deshalb mehrere Rollen und legen die fachliche Verantwortung bewusst nicht in die IT:

Solche Rollen scheitern allerdings, wenn sie nur auf dem Papier stehen. Eine Data Ownership ohne Zeit, Befugnis und Anerkennung ist eine zusätzliche Aufgabe, die bei der nächsten Priorisierung wegfällt.

Was stattdessen hilft

• Qualität an der Quelle messen und zurückspiegeln. Die Erzeugenden sehen, wie vollständig und korrekt ihre Daten sind und wofür sie genutzt werden.
• Die Kosten beim Verursacher sichtbar machen. Solange Nacharbeit anonym im Controlling anfällt, bleibt sie folgenlos.
• Definitionen mit Verantwortlichen festhalten. Ein Glossar, in dem jede zentrale Kennzahl eine Definition und einen Owner hat, ist wertvoller als jedes Bereinigungsskript.
• Vereinbarungen zwischen Erzeugenden und Nutzenden. In der Datenwelt heißen sie inzwischen Data Contracts. Ähnlich wie ein Liefervertrag zwischen Unternehmen legen sie fest, wer welche Daten in welcher Struktur und Qualität liefert, wie schnell Fehler behoben werden und wer informiert wird, bevor sich etwas ändert. Der Kern ist nicht die Technik, sondern dass sich zwei Seiten, die bisher nichts voneinander wussten, ausdrücklich aufeinander verpflichten.
• Bereinigung als Übergang, nicht als Lösung. Sie schafft einen sauberen Ausgangspunkt, verhindert aber keine neuen Fehler.

Fazit

Datenqualität ist kein Zustand, den man einmal herstellt, sondern das Ergebnis täglicher Arbeit vieler Menschen. Sie wird besser, wenn diese Menschen verstehen, wofür ihre Daten gebraucht werden, wenn Definitionen geklärt sind und wenn jemand im Fachbereich dafür einsteht. Technik unterstützt das, ersetzt es aber nicht.

Zum Weiterlesen

• DAMA International (2017). DAMA-DMBOK: Data Management Body of Knowledge (2. Aufl.). Technics Publications. Das Standardwerk zu Data Governance, Rollen und Datenqualität.
• Wang, R. Y. & Strong, D. M. (1996). Beyond Accuracy: What Data Quality Means to Data Consumers. Journal of Management Information Systems, 12(4), 5–33.
• Juran, J. M. & De Feo, J. A. (2010). Juran’s Quality Handbook (6. Aufl.). McGraw-Hill.