Lesezeit 6 Minuten
Weil Datenqualität noch vorrangig als IT-Thema betrachtet wird, starten Projekte regelmässig mit der Auswahl einer Softwarelösung. Ansätze, die aus einem solchen Aktionismus „Wir müssen unsere Datenqualität steigern“ entstehen, können zwar kurzfristig die Datenqualität steigern, aber fast nie die Datenqualität dauerhaft halten.
Um eine nachhaltig hohe Datenqualität zu erreichen, empfehlen wir ein Vorgehen nach folgendem Schema:
In Ihrem Unternehmen existieren hunderte Geschäftsobjekte mit tausenden Attributen. Wo sollten Sie beginnen?
Suchen Sie sich einen kritischen Geschäftsprozess, der gerade im Fokus steht.
Das kann ein Prozess sein, der gerade für ein Problem im Unternehmen sorgt oder ein Prozess, der durch externe Faktoren im Fokus steht (z. B. dem Datenschutz oder Supply Chain Gesetzen). Ermitteln Sie die verwendeten Geschäftsobjekte und Attribute, also die Daten, die für diesen Prozess wichtig sind. Identifizieren Sie, wenn möglich, die Verantwortlichen dieser Geschäftsobjekte und Attribute.
Für den Erfolg eines Datenqualitätsprogrammes ist es wichtig, eine unternehmensweite gemeinsame Sicht auf die verwendeten Begriffe und Konzepte zu bekommen. Das beliebteste Beispiel für Begriffsdefinitionen ist hier: „Was ist ein Kunde?“ – unterschiedliche Abteilungen, z. B. Marketing, Vertrieb, Finanzbuchhaltung oder HR, werden den Begriff unterschiedlich verwenden. Der Aufbau und die Einführung eines solchen Glossars – häufig unter dem englischen Begriff Business Glossary bekannt – ist langwierig, aber ein absolutes Muss. Starten kann hier mit einfachen Mitteln wie Excel oder einer Sharepoint / Confluence Seite. Wichtig ist, dass alle Betroffenen darauf zugreifen und bei der Definition mitarbeiten können. Später geht dieses Glossar im Metadatenmanagement oder einem Datenkatalog auf.
Datenqualität ist definiert als „fit for purpose“ – im Deutschen etwa „für den Zweck der Nutzung geeignet“. Datenqualität vergleicht somit den IST Zustand der Daten zu einem gegebenen SOLL Zustand der Daten. Hier stößt man auf die erste Hürde bei der Einführung der Datenqualität – meist sind die Prozesse noch dokumentiert – aber einzelne Geschäftsregeln oder Geschäftsprozessregeln liegen nicht mehr vor. In diesem Schritt entscheidet es sich, ob das DQ-Programm erfolgreich sein wird.
Bei IT gesteuerten Datenqualitätsprojekten überspringt man fast immer diesen Schritt und beginnt sofort mit dem nächsten Schritt, der Erstellung von a priori Datenqualitätsregeln, z. B. ob das Format einer Telefonnummer korrekt ist oder die Strasse zur Postleitzahl gehört. Die meisten dieser erstellten Regeln sind aber nicht kritisch für den Geschäftsprozess.
Bei fachlich getriebenen Projekten sollte man mit der Definition relevanter Geschäftsregeln beginnen und dann schrittweise die fehlenden Regeln des Geschäftsprozesses ergänzen.
Man kann diesen Schritt verlassen, wenn man eine ausreichende Anzahl von Geschäftsregeln erstellt hat.
In diesem Schritt wechselt die Aufgabe von der Fach- in die IT-Abteilung. Es geht um das Mapping von Geschäfts- auf Datenobjekte. Für jedes Attribut, das im Geschäftsprozess verwendet wird, muss ein Stammspeicherplatz identifiziert werden, der Ort, aus dem die späteren Prozessschritte die Werte ziehen.
Hier hilft ein konzeptuelles oder logisches Datenmodell bei der Diskussion zwischen Fach- und IT-Abteilung, das auch die Grundlage für die Einführung von Datenkatalog-Software sein sollte.
Neben dem logischen muss auch das Mapping zum physischen Datenmodell um gesetzt werden, da die Datentabellen und -felder für die Datenqualitätsmessung benötigt werden.
Am Ende dieses Schrittes ist bekannt, wo die Stammdaten und Prozessdaten der ausgewählten Geschäftsobjekte und des betrachteten Geschäftsprozesses gespeichert sind.
Datenqualitätsregeln messen das Einhalten von Geschäfts- oder Geschäftsprozessregeln. Geschäftsregeln beschreiben das WAS und die DQ-Regeln das WIE der Messung.
Der Schritt der DQ-Regel Erstellung ist zwar überwiegend technisch und in der IT-Abteilung angesiedelt, sollte aber unbedingt durch die Fachabteilung begleitet werden. Ob eine DQ-Regel das korrekte Ergebnis liefert, ist im Regelfall nur durch die Fachseite einschätz- und überprüfbar.
DQ-Regeln können auf zwei Ebenen beschrieben werden, einer eher fachlich abstrakten, losgelöst von einer Softwarelösung, oder direkt in einer IT-Lösung entwickelt und dokumentiert werden. Das fachliche Dokumentieren in einer Metadatenmanagementlösung ist zwar ein Mehraufwand, der aber bei größeren Unternehmen oder noch unklarer Softwareunterstützung akzeptiert werden soll. Spätestens bei einem Wechsel der IT-Lösung zahlt sich der Mehraufwand aus, da man auf die intellektuelle Leistung der Regelbeschreibung zurückgreifen kann und „nur“ die Entwicklungsleistung erbringen muss.
Falls Sie es in den Phasen vorher noch nicht gemacht haben, kommt jetzt der Schritt, in dem Sie die Verantwortlichen für die Daten und die Pflege benennen müssen. In prozessorientierten Unternehmen wird häufig der Prozesseigner auch zum Dateneigner benannt. Schwierig ist die Zuordnung von querschnittlichen Geschäftsobjekten, wie Geschäftspartner oder Material. Große Unternehmen setzen hier auf zentrale oder dezentrale Data Stewardship Organisationseinheiten.
Es ist wichtig, dass Sie für jede DQ-Regel auch eine Pflegeanweisung erstellen. Nichts ist frustrierender als Fehler aufgezeigt zu bekommen ohne eine Anleitung, wie man sie behebt.
Am Anfang wird man auf etablierte Transaktionen, z. B. im ERP zurückgreifen, aber spätestens, wenn es um Massenveränderungen geht, sollte man über eine IT Unterstützung nachdenken.
Relevant, gerade am Anfang, sind auch die Messzyklen. Häufig möchte man nahe Realtime die Datenfehler entdecken – bedenken Sie aber, dass Sie den Pflegenden auch die Zeit für die Fehlerbehebung gegeben müssen. Beim Start werden tausende – manchmal auch Millionen – von Fehlern angezeigt. Hier benötigt man eine Priorisierung, in welcher Reihenfolge sie abzuarbeiten sind. Am Anfang sollten nicht zu häufig Datenfehler zur Berichtigung gegeben werden. Um die Pflegenden nicht zu frustrieren, sondern zu motivieren „Meine Arbeit reduziert die Fehler nach und nach“.
Die bisherigen Schritte befassen sich mit dem Bearbeiten von Datenfehlern, die bereits entstanden sind. Es ist ein Reagieren auf hoffentlich frühzeitig, erkannte Fehler. Nach der 1-10-100 Regel ist die Korrektur von Fehlern 100x teurer als die Fehlervermeidung direkt bei der Erfassung. Moderne Datenmanagementplattformen erlauben, nicht nur für Stammdaten, sondern auch für Transaktionen, eine Überprüfung der eingegebenen Werte. Die Einführung von aktivem Datenmanagement benötigt Zeit, da Geschäftsprozesse angepasst und die Mitarbeiter Kompetenz in diesen neuen Vorgängen aufgebaut werden müssen. Fehlerhaftes Prozessdesign legt ganze Prozesse lahm, und es gibt meist keine Workarounds. Insofern muss der Einsatz von aktivem Datenmanagement wohlüberlegt werden und ist keine Allzweckwaffe gegen die Vermeidung von Datenfehlern, die schnell eingeführt werden sollte.
Neben diesen Schritten gibt es noch weitere Werkzeuge, die variabel in den Prozessschritten eingesetzt werden können.
Das automatische Datenprofiling erzeugt schnell quantitative Aussagen zu einem Datenbestand. Wie viele Felder sind leer, welche Formate sind in den Feldern gespeichert, gibt es Duplikate und Abhängigkeiten?
Solche Aussagen können schon relativ früh das Bauchgefühl zur wahrgenommenen Datenqualität stützen, aber auch dafür sorgen, dass man die Phase der Geschäftsregel -Erstellung überspringt, da man ja bereits sehr viele Datenfehler identifiziert hat. Automatisches Datenprofiling sollte zur Unterstützung, aber nicht als Ausgangspunkt eine DQ-Analyse genutzt werden.
Tue Gutes und sprich darüber – mit der Visualisierung der Datenqualität sollte relativ früh begonnen werden, um im Unternehmen das Gefühl zur Datenqualität mit Fakten zu unterstützen oder zu widerlegen. Wichtig ist auch hier, dass man erst nach der Phase der Geschäftsregel-Erstellung damit beginnen sollte, um nicht nur Formatfehler zu melden.
Datenqualitätsprojekte müssen von Fach- und IT-Abteilung gemeinsam betrieben werden.
Es ist wichtig, die Grundlagen – Glossar und Geschäftsregeln – zu dokumentieren
Verantwortliche müssen benannt werden
Die Softwareunterstützung ist erst nach der fachlichen Beschreibung wichtig
Ich hoffe, Ihnen hat diese Übersicht in die Einführung von Datenqualitätsprojekten gefallen. Natürlich gibt es in jedem Schritt noch eine Vielzahl an Fragen, die beantwortet werden müssen, die im Rahmen eines solchen Blogs nicht beleuchtet werden können; die genannten Voraussetzungen stellen aber das Minimum dar, das vorhanden sein muss. Auch sollte ein DQ-Projekt in einem größeren Rahmen betrachtet werden: