In thinkBI Folge 43 greife ich einen Gedanken aus dem gemeinsamen Workshop mit Jasmin Simader auf. Ihr Quality-Dashboard für Power BI macht Eigenschaften eines semantischen Modells sichtbar und eröffnet damit eine wichtige Frage: Was müssen Nutzer über ihre Datengrundlage wissen, bevor sie auf dieser Basis entscheiden?
Schlechte Daten sind in vielen Organisationen kein neues Problem. Menschen haben bereits mit ihnen gearbeitet, ihre Schwächen gekannt und Entscheidungen getroffen. Dieses Erfahrungswissen kann erstaunlich viel auffangen. Es ist aber an Personen und Nähe zur Entstehung der Daten gebunden.
Genau darin liegt die eigentliche Spannung. Solange dieselbe Person Daten erfasst, aufbereitet und auswertet, kennt sie viele Unschärfen aus dem Arbeitsprozess. Sobald ein Bericht für andere bereitgestellt wird, verschwindet dieser Kontext. Der Nutzer sieht einen präzisen Wert, aber nicht automatisch, wie belastbar seine Grundlage ist.
Datenqualität ist deshalb nicht nur die Frage, ob Daten richtig oder falsch sind. Sie ist auch eine Frage der sichtbaren Unsicherheit und der Verantwortung für ihre Kommunikation.
Qualitätsindikatoren schaffen noch keine Wahrheit
Ein Quality-Dashboard kann zunächst quantitative Merkmale untersuchen. Wie häufig ist eine Spalte gefüllt? Wie viele unterschiedliche Ausprägungen enthält sie? Entsprechen Werte einem erwarteten Format? Bei E-Mail-Adressen, Telefonnummern oder Datumswerten lassen sich formale Regeln prüfen. Auch Datentypen, Pflichtfelder und zulässige Längen liefern Anhaltspunkte.
Solche Prüfungen sind nützlich, weil sie einen bisher diffusen Eindruck beobachtbar machen. Eine auffällige Leerrate oder unerwartete Werteverteilung kann auf ein Problem hinweisen. In Power BI lassen sich diese Hinweise so visualisieren, dass sie nicht nur in einem technischen Prüfprotokoll verbleiben.
Aber ein gefülltes Feld ist noch kein fachlich richtiger Wert. Eine formal gültige E-Mail-Adresse muss nicht aktuell sein. Eine plausible Zahl kann im falschen fachlichen Zusammenhang stehen. Quantitative Prüfungen zeigen Merkmale der Datengrundlage; sie ersetzen nicht die Klärung, welche Aussage für welchen Zweck belastbar sein muss.
Datenqualität ist daher immer an Nutzung gebunden. Erst wenn wir wissen, welche Entscheidung eine Information unterstützen soll, können wir beurteilen, welche Fehler relevant sind und welche Toleranz vertretbar ist.
Die Quelle trägt einen Teil der Verantwortung
Viele Qualitätsprobleme entstehen nicht im Dashboard. Sie entstehen bei der Erfassung oder weil die Erfassung gar nicht für die spätere Analyse gestaltet wurde.
Ein ERP-System kann Datentypen, Pflichtfelder und Eingabestrukturen vorgeben. Damit verhindert es bestimmte Fehler bereits an der Quelle. In einem CRM-System landen wichtige Informationen dagegen häufig in Freitextfeldern, weil Nutzer ihre Beobachtung schnell festhalten wollen. Das ist für den operativen Vorgang verständlich, erschwert aber eine strukturierte analytische Nutzung.
Die BI-Strecke kann solche Daten bereinigen, vereinheitlichen und für eine Auswertung nutzbar machen. Dadurch entsteht allerdings leicht eine zweite Wirklichkeit: Im analytischen System liegen korrigierte Merkmale vor, im operativen System bleiben die ursprünglichen Fehler bestehen.
Das wird spätestens dann problematisch, wenn ein Unternehmen auf Basis der Analyse eine Kundengruppe identifiziert, die operative Selektion aber im CRM ausführen möchte. Die im BI-System erreichte Qualität steht dort nicht zur Verfügung. Die Korrektur hat den Bericht verbessert, aber nicht den Informationskreislauf.
Deshalb braucht Datenqualität einen Rückweg. Bereinigte Informationen oder erkannte Fehler müssen, wo es fachlich und technisch sinnvoll ist, wieder an die Quelle oder an die verantwortlichen Prozesse zurückgegeben werden. Reverse ETL ist dafür ein möglicher technischer Ansatz. Entscheidend ist der organisatorische Gedanke dahinter. Eine Qualitätsprüfung sollte nicht nur anzeigen, dass etwas falsch ist. Sie sollte Verbesserung ermöglichen.
Eine robuste Datenstrecke muss mit Fehlern umgehen können
Zwischen Quelle und semantischem Modell liegen weitere Prüfstellen. Transformationen können Erwartungen an Werte und Strukturen testen. Fehlerhafte Datensätze lassen sich aussteuern, statt einen gesamten Ladeprozess zum Abbruch zu bringen. Anschließend können sie gezielt geprüft, korrigiert und erneut verarbeitet werden.
Das ist besonders relevant, weil analytische Plattformen Daten oft zunächst großzügiger aufnehmen als operative Systeme. Textfelder haben möglicherweise keine enge Längenbegrenzung, und ein Staging-Bereich wird bewusst tolerant gestaltet, damit die Anlieferung nicht an jedem abweichenden Wert scheitert. Diese Toleranz ist betrieblich hilfreich. Sie darf aber nicht mit geprüfter Qualität verwechselt werden.
Ein stabiler Ladeprozess ist nicht automatisch ein Nachweis guter Daten. Er zeigt zunächst nur, dass die Daten verarbeitet werden konnten. Die Qualitätslogik muss zusätzlich festlegen, welche Abweichungen sichtbar, ausgesteuert oder zurückgemeldet werden.
Der notwendige Reifegrad verändert sich
Nicht jedes BI-Vorhaben beginnt mit einem vollständigen System aus Qualitätsregeln, Monitoring und Rückkopplung. Gerade im Self-Service BI geht es häufig zunächst darum, Daten zu erkunden, Zusammenhänge zu verstehen und Anforderungen überhaupt erst zu entdecken. In dieser Phase kann eine enge formale Absicherung mehr Aufwand erzeugen, als der noch offene Erkenntnisprozess rechtfertigt.
Das ist kein Argument gegen Datenqualität. Es ist ein Argument für einen angemessenen Reifegrad.
Entscheidend ist, wie weit sich Nutzung und Datenentstehung voneinander entfernen. Wer die Daten selbst aufbereitet, kennt viele Schwächen unmittelbar. Wer nur noch einen fertigen Bericht konsumiert, braucht diese Kenntnis in anderer Form. Dann muss der Anbieter der Information verständlich machen, wie es um Vollständigkeit, Aktualität, Plausibilität und fachliche Eignung steht.
Mit der Reichweite eines Datenprodukts wächst daher auch die Pflicht zur Qualitätstransparenz. Was im kleinen Erkundungsmodell noch persönliches Kontextwissen sein kann, muss bei einer breiteren Nutzung zu einer nachvollziehbaren Eigenschaft der bereitgestellten Information werden.
Datenqualität bedeutet nicht, vor jeder Analyse perfekte Daten zu verlangen. Sie bedeutet, ihre Grenzen zu kennen, sie für andere sichtbar zu machen und aus erkannten Fehlern einen Verbesserungsprozess entstehen zu lassen. Die entscheidende Frage lautet deshalb nicht nur, sind unsere Daten gut? sondern, Wissen die Menschen, wie gut sie für ihre konkrete Entscheidung sind?
🎧 Die komplette Folge findest du im thinkBI Podcast.
Musik: Great Podcast Intro (short & long) von Lundstroem
Quelle: freemusicarchive.org (Creative Commons) – https://freemusicarchive.org/music/lundstroem/songs-for-leona/great-podcast-intro-both-short-and-long-version-included/
