Die schöne Tabelle kann trotzdem täuschen
Stell dir einen ausdrücklich fiktiven Händler vor, der die Zahl offener Kundenanfragen aus seinem CRM liest. Das Dashboard zeigt 42 Fälle. Drei Mitarbeitende verwenden jedoch unterschiedliche Regeln dafür, wann eine Anfrage als abgeschlossen gilt. Die Zahl ist technisch korrekt aus den gespeicherten Statuswerten berechnet und trotzdem für die Personalplanung kaum brauchbar. Wer allein prüft, ob alle Felder ausgefüllt sind, verfehlt das Problem. Die eigentliche Frage lautet: Was soll die Zahl im Alltag entscheiden helfen, und erfassen die Statuswerte genau dieses Ereignis?
Datenqualität ist somit keine Eigenschaft, die ein Datensatz ein für alle Mal besitzt. Eine Liste mit Postleitzahlen kann für den Versand ausreichend sein, obwohl Telefonnummern fehlen. Für telefonische Rückrufe wäre dieselbe Liste ungeeignet. Lege den Verwendungszweck fest, bevor du pauschal nach „sauberen Daten“ verlangst. Das britische Government Data Quality Framework beschreibt mehrere Dimensionen, darunter Vollständigkeit, Gültigkeit, Genauigkeit, Eindeutigkeit, Konsistenz und Aktualität. Diese Begriffe helfen beim Prüfen; sie ersetzen die konkrete Entscheidung über den benötigten Qualitätsgrad nicht.
Vom Datenfeld zur tatsächlichen Bedeutung
Schreibe für eine wichtige Kennzahl zuerst ihre Definition in einem Satz auf. Welche Einträge gehören hinein, welche nicht, aus welchem System stammen sie, und welcher Zeitpunkt zählt? Beim fiktiven Händler könnte „offene Anfrage“ bedeuten: Eine eingegangene Anfrage ohne dokumentierte Antwort oder begründete Schließung bis zum Tagesende. Damit ist nicht bewiesen, dass alle Mitarbeitenden den Status gleich vergeben. Aber es gibt nun eine Regel, an der sich Einträge und Auswertungen vergleichen lassen. Eine Kennzahl wird nicht schon dadurch verlässlich, dass sie regelmäßig erscheint.
Unterscheide anschließend einen leeren Wert von einem falschen und einem veralteten Wert. Eine fehlende Lieferadresse ist sichtbar. Eine formal gültige Adresse, die nicht mehr zur Bestellung gehört, kann unbemerkt bleiben. Ein Datum im richtigen Format sagt nichts darüber aus, ob das Ereignis tatsächlich an diesem Tag stattfand. Selbst zwei übereinstimmende Systeme können denselben ursprünglichen Fehler übernommen haben. Prüfe deshalb einige Fälle an der Entstehungsstelle, statt ausschließlich zwei Ausgaben miteinander zu vergleichen.
Eine kleine, wiederholbare Prüfung bauen
Nimm eine anstehende Entscheidung und notiere die Daten, auf denen sie beruhen soll. Wähle eine überschaubare Stichprobe aus verschiedenen Tagen, Quellen und Sonderfällen. Halte pro Fall vier Spalten fest: gespeicherter Wert, ursprünglicher Beleg oder Vorgang, festgestellte Abweichung und mögliche Auswirkung auf die Entscheidung. Wenn ein Beleg fehlt, vermerke „nicht prüfbar“, statt den Wert automatisch für richtig oder falsch zu erklären. Das ist eine praktische Arbeitsliste, keine statistische Repräsentativitätsbehauptung.
Bei wiederkehrenden Auswertungen können einfache Regeln Arbeit abnehmen: Pflichtfelder prüfen, unmögliche Datumsfolgen markieren, doppelte IDs suchen und ungewöhnliche Änderungen melden. Ein Test sollte den Fehler sichtbar machen, nicht heimlich einen vermuteten Wert einsetzen. Vor allem bei Datenintegration musst du wissen, ob zwei Felder wirklich dasselbe meinen. „Kunde“ kann im Verkauf eine zahlende Organisation und im Support eine kontaktierende Person bedeuten. Die Namen sind ähnlich, die Einheiten sind verschieden. Eine automatische Zusammenführung ohne Begriffsabgleich produziert dann überzeugend aussehende, aber irreführende Ergebnisse.
Fehler an der Quelle und im Prozess finden
Frage bei jeder Abweichung, wo sie entstanden ist. Wurde die Information nie erfasst, später falsch übertragen, bei einer Umstellung anders definiert oder in der Anzeige missverständlich verdichtet? Eine Korrektur nur im Bericht hilft wenig, wenn das Erfassungsformular denselben Fehler morgen wieder hervorbringt. Lege deshalb für jedes kritische Feld fest, wer seine Bedeutung verantwortet, wer es eingibt und wie eine begründete Korrektur sichtbar bleibt. Ein Änderungsverlauf ist nützlicher als ein still überschriebenes Ergebnis.
Priorisiere nach Schaden und Häufigkeit, nicht nach der Zahl rot markierter Zellen. Eine falsche Rechnungsadresse kann eine konkrete Folge haben; eine leere optionale Notiz vielleicht keine. Bei seltenen, aber folgenreichen Fehlern kann eine zusätzliche Freigabe sinnvoller sein als eine große automatische Bereinigung. Achte auch auf Datenminimierung: Die Qualität verbessert sich nicht dadurch, dass du vorsorglich mehr personenbezogene Angaben sammelst. Erfasse nur, was der Zweck rechtfertigt, und sichere den Zugriff passend zum Inhalt.
Nicht jede Abweichung ist ein Defekt
Wenn Vertrieb und Buchhaltung unterschiedliche Umsatzzahlen zeigen, kann einerseits ein Fehler vorliegen. Andererseits können verschiedene Zeitpunkte, Rückgaben oder Begriffe zugrunde liegen. Lege beide Definitionen nebeneinander, bevor du eine Quelle zum Sieger erklärst. Dokumentiere den Unterschied und die Frage, für welche Entscheidung welche Sicht geeignet ist. In einer Datenbank kann ein Wert konsistent gespeichert sein und dennoch für einen anderen Bericht ungeeignet bleiben. Datenqualität verlangt deshalb auch verständliche Herkunft und Grenzen.
Plane schließlich eine erneute Prüfung ein. Systeme, Angebote und Arbeitsweisen ändern sich, während alte Regeln weiterlaufen. Eine monatliche Stichprobe für wichtige Felder kann mehr bewirken als ein einmaliger großer Aufräumtag. Notiere, ob die Fehlerquote in genau den relevanten Fällen sinkt und ob Entscheidungen dadurch tatsächlich besser vorbereitet werden. Falls sich eine Regel als unpraktisch erweist, passe sie begründet an. Gute Datenqualität heißt nicht Perfektion; sie heißt, die Tragfähigkeit der Daten für ihren Zweck einschätzen und Probleme rechtzeitig beheben zu können. Halte offene Ausnahmen für die nächste Prüfung fest, damit sie nicht still verschwinden.
Häufige Fragen
Sind vollständige Daten automatisch gute Daten?
Nein. Ein Feld kann ausgefüllt und trotzdem falsch, veraltet oder anders gemeint sein. Prüfe einen wichtigen Fall am ursprünglichen Vorgang und frage, welche Entscheidung sich bei einem Fehler ändern würde.
Wo beginne ich bei vielen Fehlern?
Wähle eine anstehende Entscheidung und die wenigen Felder, von denen sie abhängt. Suche dort nach wiederkehrenden Abweichungen und ihrer Entstehungsstelle, bevor du die gesamte Datenbank bereinigst.