Im BARC Data, BI and Analytics Trend Monitor 2026 bewerteten 1.550 Befragte Datenqualitätsmanagement durchschnittlich mit 7,9 von 10 Punkten. Damit teilt sich das Thema den ersten Platz mit Data Security & Privacy. Die Priorität ist seit Jahren bekannt. Vielen Unternehmen fehlt jedoch ein wirksames Vorgehen.
Datenqualitätsmanagement bedeutet, kontinuierlich daran zu arbeiten, Daten für einen konkreten geschäftlichen Zweck verlässlich zu machen. Dazu erarbeitet ein Unternehmen die Anforderungen der Datenkonsumenten, untersucht den Prozess der Datenerzeugung, leitet daraus Veränderungen am Entstehungsprozess ab und überwacht, ob die vereinbarte Qualität erreicht wird.
Die Qualität einer Information ist nie absolut. Datenqualität entscheidet sich sowohl an der Nutzung der Daten als auch an dem Prozess, der den Datenpunkt erzeugt. Wer Nutzung und Entstehung versteht, kann kritische Daten bestimmen und geeignete Maßnahmen auswählen. Erst danach kann der üblicherweise diskutierte Werkzeugkasten des Datenqualitätsmanagements zum Einsatz kommen.
Was ist Datenqualität?
Datenqualität beschreibt, ob Daten für einen konkreten Zweck geeignet sind.
Generische Definitionen und Messmodelle lösen das Grundproblem nicht. Wer Daten als Produkt versteht, muss ihre Qualität aus der vorgesehenen Nutzung ableiten.
Was ist Datenqualitätsmanagement?
Datenqualitätsmanagement (DQM) im Kontext von Enterprise Data Management ist ein umfangreicher Prozess der sicherstellt, dass Daten akkurat, verlässlich und valide sind über ihren gesamten Lebenszyklus hinweg. Es bedient sich sowohl an technischen als auch organisatorischen Maßnahmen. (BARC Definition)
Warum ist Datenqualitätsmanagement wichtig?
Unzuverlässige und widersprüchliche Daten führen zu widersprüchlichen Kennzahlen, manueller Nacharbeit und zeitraubenden Diskussionen. Sie erhöhen zugleich Compliance-Risiken und verursachen fehlerhafte Analysen und Entscheidungen.
Probleme bleiben oft lange unbemerkt. Analysen wirken verlässlich, obwohl die zugrunde liegenden Daten ungeeignet sind. Früher oder später treten aber immer wieder Probleme mit der Datenqualität auf. Wer wiederholt auf fehlerhafte Daten stößt, nutzt dann wieder zunehmend Instinkt und Meinung als Grundlage für Entscheidungen oder bezweifelt sogar datengetriebene Entscheidungen anderer.
Langfristiges Vertrauen in Daten ist das Zwischenziel vieler Unternehmen, um sich zu einer datengetriebenen Organisation zu entwickeln. Die Herausforderung ist zu verstehen, dass eine perfekte Datenqualität unmöglich ist, Fehler sind damit absehbar. Beispiele aus der Praxis zeigen aber, dass es durchaus möglich ist, dennoch Vertrauen in Daten zu schaffen. Ein Betriebsmodell muss die Grundlage für kontinuierliche Qualitätsarbeit bieten: Fehler früh erkennen, zeitnah beheben und ihre Wiederholung verhindern.
Jeder Datensatz bildet nur einen Ausschnitt der Wirklichkeit ab
Im Bereich der industriellen Fertigung gibt es den Begriff des digitalen Zwillings. Er deutet auf einen simplen Grundgedanken hin: Digitale Daten sind in erster Linie ein Werkzeug, um unsere Realität modellhaft im digitalen Raum darzustellen, eine Grundvoraussetzung für den Einsatz von Informationstechnologie im Kontext des Unternehmens.
Ein digitaler Zwilling ist jedoch keine objektive Kopie der Realität. Und so verhält es sich auch mit vielen anderen Datenpunkten, mit denen wir täglich in Kontakt treten. Menschen und Organisationen übersetzen einen Ausschnitt der Wirklichkeit in Begriffe und Strukturen der IT, damit sie Abläufe konsistent, effizient und regelkonform wiederholen können.
Darin liegt eine der Wurzeln vieler Datenqualitätsprobleme: Nicht nur einzelne Werte können falsch sein. Schon das Modell kann für einen bestimmten Zweck unzureichend sein.
Das ist kein rein digitales Problem: Eine Landkarte zeigt nur die Aspekte der Welt, die für ihren Zweck relevant sind. Genauso sind Daten vereinfachte Projektionen der Realität. Ihre Qualität kann nur relativ zu einer Nutzung beurteilt werden. Niemand käme auf die Idee, einen Atlas für Fernfahrer als schlecht zu bezeichnen, nur weil er kleine Wanderwege nicht darstellt.
Drei Fehler führen zu Problemen
Das ist ein konzeptioneller Fehler im Datenmodell. Gehen wir nochmal weg vom Bauplan und zu einem digitalen Datenproblem**:** Das CRM modelliert den „Kunden“ so, dass Sales Opportunities steuern kann. Für Finance fehlen aber möglicherweise Rechtseinheit, Umsatzsteuer-ID oder Vertragsstruktur. Der Datensatz ist dadurch nicht objektiv falsch, sondern für einen anderen Business Outcome unzureichend modelliert.
Weitere Fehler entstehen bei der Erfassung. Auch hier ein Beispiel: Ohne Validierung entstehen oft falsche Kombinationen aus Postleitzahl und Ort. Für den Customer Service bleibt das zunächst unsichtbar. In der Logistik wird daraus eine fehlgeleitete Sendung.
Zu guter Letzt erzeugen schlechte Abläufe schlechte Daten: ein Prozessfehler. Menschen erfassen Informationen anders als erwartet, wenn Zweck, Anforderungen, Zeit, Oberfläche oder Training nicht zum Prozess passen.
Ein Orientierungsmodell für Datenqualitätsmanagement
Datenqualitätsmanagement verbindet drei Aspekte:
- Der fachliche und unternehmerische Aspekt beschreibt sowohl die Entstehung als auch den Impact von Daten(qualität)
- Menschen sind für Datenqualität verantwortlich, daher braucht es eine organisatorische Verankerung in Ablauf- und Aufbauorganisation
- Technologie ist dafür geeignet, Menschen zu entlasten und bei wiederkehrenden Tätigkeiten automatisiert zu unterstützen
Ein Beispiel zeigt, wo die Prioritäten liegen sollten
Bestandssteuerung eines fiktiven Handelsunternehmens
Supa24 ist ein fiktiver, regionaler Einzelhändler im Lebensmittelgeschäft. Ein Zentrallager steuert rund 10.000 der Artikel datenbasiert. Der Einkauf trägt die Verantwortung für die Bestellentscheidung, ist aber auf korrekte Informationen aus der Warenannahme angewiesen.
Eines Tages ereignet sich ein Vorfall, der allerdings erst Wochen später auffällt: Supa24 verkauft Wasser in Sechserpacks, die im Lager normalerweise als eine Packung gezählt werden. Eine studentische Aushilfe erfasst bei einer einzelnen Lieferung die Zahl der einzelnen Flaschen, nicht die Zahl der Sechserpacks, alle anderen Wasserlieferungen in derselben Woche werden korrekt eingetragen. Der Systembestand ist dadurch höher als der tatsächliche Bestand.
Der Einkauf interpretiert den Wert als Überbestand und verschiebt eine spätere Lieferung um unnötige Lagerflächen zu belegen und Kosten zu vermeiden. Das Wasser ist anschließend ausverkauft, Kundinnen und Kunden finden ein Alltagsprodukt nicht vor. Der Filialleiter nimmt entsprechend den Telefonhörer in die Hand und beschwert sich in der Zentrale. Für ihn schaut es so aus, als hätte die Einkaufsabteilung gerade bei so einem wichtigen Artikel eine unnötige Fehlentscheidung zu seinen Lasten getroffen.
Sofort geht der Einkauf von Supa24 auf Ursachenanalyse. Ausgangspunkt ist die Differenz zwischen erwarteten und tatsächlich vorhandenen Packungen. Schnell stellt der verantwortliche Analyst fest: Die angeblichen Bestände haben physisch nie existiert. Der Fehler lässt sich durch den Vergleich von Lieferbeleg und Buchung der Warenannahme auf die falsche Mengeneinheit zurückführen. Das Management stellt dann die offensichtliche Frage: Wie konnte eine einzelne Eingabe ohne Plausibilitätsprüfung eine Bestellentscheidung verändern?
Das Management entscheidet sich, dass dieses Problem geschäftsentscheidend ist und beauftragt den Chief Data Officer, eine Lösung zwischen Einkauf, Logistik und IT zu moderieren. Das Ergebnis ist erstaunlich banal und so oder ähnlich bereits in vielen Warenwirtschaftssystemen umgesetzt: Bei der Warenannahme vergleicht das System jede gebuchte Lieferposition mit der angekündigten Menge auf dem Lieferbeleg. Bei einer Abweichung erhalten die Person in der Warenannahme und die Einkaufsverantwortung vor Abschluss der Buchung einen Hinweis und es wird nochmal nachgezählt. Größere Abweichungen erfordern eine weitere Zählung durch eine dritte Person.
Der Fehler entstand bei der physischen Warenannahme. Das IT-System machte ihn lediglich als falschen Bestand sichtbar. Daher brauchen sie auch die fachlichen Manager, IT-Experten jedoch in vielen Fällen nur zur Unterstützung.
Der Lebenszyklus des Datenqualitätsmanagements
Die sieben grundsätzlichen Phasen von Datenqualitätsmanagement:
- Discover: Baue ein Inventar der relevanten Datenquellen auf.
- Profile: Analysiere die Daten, um ihren Aufbau und eventuelle Anomalien zu erkennen.
- Define & Design: Definiere Regeln und Standards.
- Monitor: Beobachte, wie Regeln und Metriken eingehalten werden
- Identify Issues: Identifiziere und priorisiere Datenqualitätsprobleme
- Remediate: Analysiere den grundlegenden Auslöser und behebe das Problem
- Report: Berichte den Status quo an die beteiligten Stakeholder
Dieser Lebenszyklus ist nach wie vor die Grundlage des Datenqualitätsmanagements. Der Data Quality Lifecycle wird wiederholt, sobald der Abschlussbericht Verbesserungsbedarf zeigt oder ein neues Problem auftritt (iterativer Ansatz).
Wie er genau ausgeführt werden kann und wie er sich dank künstlicher Intelligenz weiterentwickelt, erklärt mein Kollege Timm Grosser im Blogbeitrag Warum Datenqualität von gestern deine KI-Projekte ruiniert und in diesem BARC-Webinar.
Arbeitsteilung im Überblick
Fachliche Verantwortliche definieren die akzeptable Qualität und bewerten die Folgen eines Fehlers. Gleichzeitig gibt es in vielen Unternehmen zentralisierte Teams in Governance und IT, die einen großen Anteil leisten können, um Datenqualität zu verbessern. Allerdings nur dann, wenn alle verstehen, dass zentrale Teams nur unterstützen können und nie verantwortlich sein können für Datenqualität.
Einige Beispiele:
- Governance-Verantwortliche moderieren und übersetzen Anforderungen in gemeinsame Prinzipien, Standards und Entscheidungswege. So entsteht ein kohärentes Gesamtbild mit konsistenten Standards. Das ist essentiell für ein effizientes Arbeiten und Automatisierung.
- Data Engineers implementieren Kontrollen in Datenbeständen und Pipelines.
- Data Stewards überwachen Ergebnisse, koordinieren die Bearbeitung und halten Definitionen und Metadaten aktuell. Idealerweise sitzen Data Stewards daher in der fachlichen Abteilung.
Warum Verantwortlichkeit für Daten so oft fehlschlägt
Ownership für Daten(qualität) scheitert häufig an der logischen Struktur des Problems: Die produzierende Person trägt den Aufwand für bessere Erfassung. Die konsumierende Person trägt die Konsequenz schlechter Qualität.
Wer Daten produziert, ist möglicherweise weniger von ihnen abhängig oder nutzt eine andere Qualitätsdefinition. Viele Programme beantworten dieses Anreizproblem mit Richtlinien, Ownership-Einträgen im Datenkatalog, RACI-Diagrammen oder einem Datenqualitätstool. Diese Instrumente dokumentieren das Problem, lösen aber nicht das Grundproblem, dass der Produzent schlicht keinen rationalen Grund hat, in das Nebenprodukt seiner Prozesse (Daten) zu investieren.
Formale Ownership bleibt wirkungslos, wenn die benannte Person den Entstehungsprozess nicht verändern kann. Entscheidend ist deshalb, woran sich echte Ownership erkennen lässt.
In der Praxis können Sie das in wenigen Minuten selbst überprüfen. Denn echte Ownership erfüllt 3 Bedingungen:
- Ein Owner hat die Autorität, den Prozess zu verändern, der die Information erzeugt.
- Ein Owner hat die Möglichkeit einen Fehler zu sehen, wenn er entsteht oder relevant wird.
- Ein Owner ist betroffen von der Konsequenz, wenn niemand handelt. Sei es direkt oder indirekt bspw. über Incentives oder Verrechnung.
Nur bei einem klaren Ja zu allen drei Bedingungen existiert ein echter Owner.
Die produzierende Seite trägt zu schnell die Schuld
Ein bekanntes Schema bei Datenqualitätsprobleme ist außerdem eine vorschnelle Schuldzuweisung. Die konsumierende Seite sieht eine falsche Information und schließt: Jemand hat diesen Wert eingegeben, also liegt dort die Schuld. Gleichzeitig formuliert sie ihre Qualitätsanforderung häufig erst, nachdem etwas schiefgegangen ist. Niemand kann auf eine Erwartung optimieren, die nie ausgesprochen wurde. Die Verantwortung verläuft deshalb in beide Richtungen.
Die richtige Reihenfolge
Zuerst Requirements-Arbeit: Welche Entscheidung hängt von der Information ab? Welche Elemente können das Ergebnis verändern? Was bedeutet „gut genug“? Was passiert, wenn die Anforderung nicht erfüllt ist? Ohne diese Klarheit sollte noch keine Diskussion über konkrete Kontrollen beginnen.
Danach den Prozess untersuchen, der die Information erzeugt. Dort wird Qualität praktisch entschieden. Erst anschließend folgen Metriken, Lebenszyklus, RACI-Diagramme und Technologie.
Observability: Telemetrie für Daten
Data Observability erweitert das Datenqualitätsmanagement um eine kontinuierliche technische Überwachung. Angelehnt an Systemtelemetrie aus der Softwareentwicklung betrachtet man Entstehung, Speicherung, Verarbeitung und Fluss von Daten wie eine Aneinanderkettung von kleinen Subsystemen, fast so wie eine Produktionsstraße in der Automobilindustrie. Geht einem Roboter das Öl aus oder bleibt eine Karosse irgendwie an einer Befestigung hängen, schlägt ein System Alarm.
Data Observability erkennt und bewertet also Veränderungen, die eine korrekte oder rechtzeitige Datenlieferung gefährden. Mehr Details zum Thema haben wir in der BARC Research Note Observability for AI Innovation dargestellt.
Welche Rolle spielt KI im Datenqualitätsmanagement?
KI verändert, welche Daten und Qualitätsanforderungen Unternehmen berücksichtigen müssen.
Einerseits werden neben strukturierten Tabellen nun auch unstrukturierte Texte, Dokumente, Bilder, Metadaten, Kontext, sowie menschliche Validierung relevant. Außerdem kommen andere Anforderung auf: Fachliche Relevanz und Kontext werden wichtiger, weil formal korrekte Informationen für einen KI-Anwendungsfall trotzdem ungeeignet sein können.
Es entstehen Herausforderungen, die klassische, veraltete Ansätze zum Datenqualitätsmanagement ignorieren: In der BARC-Studie Harnessing Unstructured Data for AI Innovation gaben 70 Prozent von 196 Befragten an, dass weniger als die Hälfte ihrer unstrukturierten Daten für Analytics oder KI auffindbar und nutzbar sei. KI-Readiness lässt sich also nicht auf einzelne klassische Datenqualitätsdimensionen reduzieren.
Weitere Informationen und Analysen dazu enthält die BARC-Studie Harnessing Unstructured Data for AI Innovation.
Wie starten?
Wer lange nach einem Pilotfall suchen muss, hat vermutlich nicht das dringendste Problem gewählt. Wählen Sie ein Problem, das Entscheidungen behindert, Kosten verursacht oder Kunden betrifft. Ein Pilot, der niemandem wehtut, erzeugt keinen Handlungsdruck und überlebt das Tagesgeschäft nicht.
Datenqualitätsarbeit greift häufig über Bereiche hinweg in Arbeitsabläufe ein. Zentrale Teams in IT oder Governance besitzen dafür allein meist nicht genug Autorität. Ein Problem, das die Führung bereits spürt, schafft das Mandat, das in vielen Fällen unverzichtbar ist.
Wie löse ich unser Datenqualitätsproblem?
Datenqualitätsprobleme haben häufig nicht den einen banalen Grund, der mit einem schnellen Softwareupdate erledigt ist. Eine strukturierte Analyse grenzt das Problem ein und schafft die Grundlage für erste Maßnahmen.
3 Fragen klären Nutzung, Entstehung und Verantwortung der betroffenen Information. Die Antworten auf diese Fragen liefern die notwendige Klarheit, um das Problem strukturiert zu lösen.
Frage 1: Wie wird die Information genutzt, und welche Anforderungen folgen daraus?
- Die konsumierende Seite muss sagen, welche Entscheidung oder welcher Prozess von der Information abhängt.
- Sie muss definieren, was „gut genug“ in diesem Zusammenhang bedeutet.
- Nicht ausgesprochene Erwartungen sind keine Anforderungen.
Frage 2: Wie entsteht die Information, und welche Einschränkungen bestehen?
- Den realen Entstehungsprozess ansehen, nicht nur das Datenmodell.
- System, Eingabemaske, Arbeitslast, Zeitdruck, Übergaben, Qualifikation und Training berücksichtigen.
- Prüfen, welche Qualitätsanforderungen unter diesen Bedingungen realistisch erfüllt werden können.
Frage 3: Welche Personen sind beteiligt?
- Produzierende und konsumierende Seite konkret benennen.
- Sichtbar machen, wer den Entstehungsprozess ändern kann, wer das Problem erkennt und wer die Folgen trägt.
- Formale Zuständigkeit und tatsächliche Handlungsmacht auseinanderhalten.
Anschließend lässt sich prüfen, ob Aufwand und Folgen bei unterschiedlichen Beteiligten liegen, bspw. über den genannten Drei-Bedingungen-Test für echte Ownership: Autorität, Sichtbarkeit, Konsequenz.
Wenn niemand den Test besteht, darf die logische Konsequenz nicht sein, dass einfach irgendein plausibler Owner benannt wird. Stattdessen gilt es, einen Mechanismus schaffen, der das Problem beim Prozess-Owner internalisiert. Mögliche Mechanismen sind hier: Zielvereinbarung, Anreiz, geänderter Prozess, transparente Downstream-Auswirkung oder ein klarer Managementauftrag.
Hohe Datenqualität verursacht Aufwand und muss wirtschaftlich begründet sein. Dieses Vorgehen lässt sich nicht beliebig oft wiederholen. Deshalb ist auch die Anforderungsanalyse so entscheidend: nicht alle Datenqualitätsprobleme eines Unternehmens können wirtschaftlich gelöst werden.
Wie bringt mich eine Analyse auf dem Papier weiter?
Sind Nutzung, Anforderungen, Prozess und Verantwortung geklärt, können Unternehmen Datenqualitätsmetriken, Regeln, Schwellenwerte und Eskalationen festlegen. Denn diese setzen nur eine bereits getroffene fachliche und organisatorische Entscheidung um.
So wird Datenqualität wiederholbar
Datenqualität belegt seit Jahren Spitzenplätze im BARC Data, BI & Analytics Trend Monitor. Das zeigt, dass Datenqualitätsmanagement eine klare Priorität ist und vor allem eine große Herausforderung. Generische Kennzahlen und formale Ownership-Einträge schaffen allein noch keine verlässlichen Daten. Tatsächlich entsteht Datenqualität erst, wenn die Organisation für ein konkretes Problem Nutzung, Anforderungen, Entstehungsprozess, Beteiligte und Konsequenzen benennen kann: Erst dann ergeben kritische Daten, Owner, Regeln, Signale und Reaktionen ein funktionierendes System.
Nutzung und Entstehungsprozess bestimmen, welche Qualität eine Information benötigt. Datenqualitätsmanagement verbindet beide Seiten und macht Verbesserung wiederholbar.
Der BARC Data Quality Compass zeigt, wie Unternehmen Anforderungen, Verantwortung und Kontrollen zu einem Betriebsmodell verbinden
FAQ
Was ist Datenqualitätsmanagement?
Datenqualität beschreibt, ob Daten für einen konkreten Zweck geeignet sind. Datenqualitätsmanagement ist die kontinuierliche Arbeit, Anforderungen zu definieren, Daten zu überwachen, Probleme zu priorisieren und Ursachen in Daten und Prozessen zu beseitigen. Dazu gehören Metriken, Regeln und Werkzeuge, aber sie folgen aus der geschäftlichen Nutzung und ersetzen sie nicht.
Warum ist Datenqualitätsmanagement wichtig?
Ungeeignete Daten führen zu falschen Entscheidungen, Prozessfehlern, Nacharbeit, Compliance-Risiken, Kundenproblemen und fehlerhaften KI-Ergebnissen. Besonders gefährlich ist falsche Sicherheit: Berichte und Modelle können technisch funktionieren und dennoch auf Daten beruhen, die für ihren Zweck ungeeignet sind. Ein systematischer Ansatz verbindet Fehler, Geschäftsauswirkung, Verantwortung und Reaktion.
Was sind kritische Daten?
Kritische Daten sind jene Datenelemente, deren Fehler eine Entscheidung, einen Prozess, einen Bericht oder eine KI-Anwendung wesentlich verändern können. Welche Daten kritisch sind, lässt sich daher nur aus ihrer konkreten Nutzung ableiten.
Welche Rolle spielen Datenqualitätsmetriken und Datenqualitätsregeln?
Datenqualitätsmetriken machen sichtbar, ob Daten die vereinbarten Anforderungen erfüllen. Datenqualitätsregeln übersetzen diese Anforderungen in konkrete Prüfungen. Schwellenwerte, Warnungen und Eskalationen legen fest, wie die Organisation auf Abweichungen reagiert.
Was unterscheidet Datenqualität, Datenintegrität und Data Observability?
Datenqualität beschreibt, ob Daten für einen konkreten Zweck geeignet sind. Datenintegrität betrachtet vor allem Korrektheit, Konsistenz und Unversehrtheit. Data Observability überwacht, ob Veränderungen in Datenbeständen und Datenflüssen die korrekte und rechtzeitige Bereitstellung gefährden.
Was sind die wichtigsten Schritte im Datenqualitätsmanagement?
Relevante Quellen identifizieren, Daten und Prozesse analysieren, Anforderungen, Standards und Regeln definieren, Ergebnisse überwachen und Probleme priorisieren, Ursachen beheben und Fortschritt berichten, sowie den Zyklus anhand der Ergebnisse wiederholen und verbessern.
Wer ist für Datenqualität verantwortlich?
Verantwortung ist geteilt, aber nicht beliebig. Der Fachbereich definiert Zweck und akzeptable Qualität. Governance übersetzt Anforderungen in gemeinsame Standards. Data Engineering implementiert Kontrollen. Data Stewards koordinieren die laufende Arbeit. Echte Ownership besteht nur, wenn eine Person oder Rolle den Entstehungsprozess verändern kann, Fehler sieht und die Konsequenz ihres Ausbleibens trägt. Fehlt diese Kombination, muss die Organisation Aufwand und Konsequenz durch einen geeigneten Mechanismus beim Prozess-Owner zusammenführen.
Wie unterstützt Data Observability das Datenqualitätsmanagement?
Data Observability erkennt Veränderungen und Störungen, die eine korrekte und rechtzeitige Datenbereitstellung gefährden. Sie verbessert Erkennung und Reaktion, bestimmt aber nicht allein, welche Qualität fachlich erforderlich ist. Diese Entscheidung bleibt an Nutzung, Business Outcome und Anforderungen gebunden.
