Als 1996 Diane Strong und Richard Wang ihre Studie zum Thema Datenqualität veröffentlichten, definierten sie Datenqualität wie folgt: „data that are fit for use by data consumers“. Wobei „consumers“ diejenigen sind, die die Daten nutzen („those who use the data“). So weit so gut. Heute, 26 Jahre später, lohnt der Blick auf die „data consumers“, also diejenigen, die die Daten nutzen. Man kann auch von Data Quality Stakeholdern sprechen.
Natürlich sind das immer noch die Kollegys, die für ihre täglichen Aufgaben die passenden Daten und Informationen aus verschiedenen Unternehmensapplikationen abrufen und diese dann nutzen.
Zusätzlich gibt es weitere Kategorien von Data Consumers:
Schnittstellen.
Schnittstellen zwischen Systemen benötigen Daten in einer definierten Form. Können über Schnittstellen die Daten nicht zwischen Systemen hin- und her gereicht werden, kommt es zu Fehlern, die oft manuell behoben werden müssen.
Prozesse.
Prozesse sind auf der Ebene der Datenqualität ähnlich wie Schnittstellen zu betrachten. Sollen z.B. bei der Neuanlage von Stammdaten die Daten aus unterschiedlichen Datenquellen zusammengeführt werden und weitere Werte mittels Werte-Tabellen und externen Datenquellen angereichert werden, benötigen diese Prozesse Daten in bestimmten Ausprägungen, damit sie die jeweiligen Quality Gates passieren und den jeweils nächsten Reifegrad erreichen. Stehen die Daten nicht in der erwarteten Ausprägung (Vollständigkeit) zur Verfügung, verzögert sich der gesamte Prozess.
Algorithmen.
In Zeiten der Künstlichen Intelligenz, (predictive) Analytics und anderen Datenthemen, bei denen Algorithmen zu Einsatz kommen, benötigen diese eine gute Datenqualität. Es gibt inzwischen genug Beispiele, was passiert, wenn man Algorithmen mit „falschen“ Daten trainiert. Das für mich einprägendste Beispiel ist der Microsoft Chatbot Tay, der von Trollen durch gezielte Fragen und Aufforderungen die Art von Antworten generierte, die Microsoft sicher nicht haben wollte.
Systeme.
Auch Systeme und Applikationen benötigen die Daten in einer definierten Qualität. Zum einen, weil die Daten in das definierte Datenschema passen müssen. Zum anderen, da in den Applikationen technische Workflows implementiert sind, und diese benötigen die Daten in der entsprechenden Qualität. Andernfalls kommt es auch hier zu Fehlern und Verzögerungen.
Die fünf hier aufgezählten Data Quality Stakeholder (Kollegys, die mit Daten arbeiten; Schnittstellen; Prozesse; Algorithmen und Systeme) brauchen also definitiv eine angemessene Datenqualität.
Meine Fragen an euch: Welche Data Quality Stakeholder neben den hier aufgeführten seht ihr in eurem Umfeld noch? Und habt ihr Beispiele dafür?
Wer nochmal die Studie von Richard Wang und Diane Strong nachlesen möchte (lohnt sich immer wieder), findet diese hier.
Der Artikel wurde ursprünglich auf LinkedIn veröffentlicht. Kommentare gerne dort.