So implementieren Sie einen Datenqualitätsprozess

Data Quality (DQ) in Data-Warehouse-Systemen wird immer wichtiger. Steigende regulatorische Anforderungen, aber auch die wachsende Komplexität von Data-Warehouse-Lösungen, zwingen Unternehmen, eine Data-Quality-Initiative zu intensivieren (bzw. zu starten).

Der Schwerpunkt dieses Artikels liegt auf „traditionellem“ Data Warehousing, aber die Datenqualität ist auch ein Thema in „moderneren“ Konzepten wie Data Lakes. Es zeigt einige wichtige Punkte, die zu berücksichtigen sind, sowie einige häufige Fallstricke, die es bei der Implementierung einer Datenqualitätsstrategie zu vermeiden gilt. Der Teil zur Auswahl der richtigen Technologie/des richtigen Tools zum Erstellen eines DQ-Frameworks wird nicht behandelt.

Eines der hinderlichsten Probleme eines DQ-Projekts ist die Tatsache, dass es auf den ersten Blick viel Arbeit für die Fachbereiche erzeugt, ohne zusätzliche Funktionalität bereitzustellen. Eine Datenqualitätsinitiative hat in der Regel nur dann starke Befürworter, wenn:

• Es gibt Datenqualitätsprobleme mit schwerwiegenden Auswirkungen auf das Geschäft.
• Aufsichtsbehörden setzen Datenqualitätsstandards durch (z. B. BCBS 239 in der Finanzbranche).

Die Behandlung von DQ ist ähnlich wie beim Testen in der Softwareentwicklung – wenn einem Projekt die Zeit und/oder das Budget ausgeht, wird dieser Teil tendenziell zuerst reduziert.

Das ist natürlich nicht die ganze Wahrheit. Ein gutes Datenqualitätssystem hilft, Fehler frühzeitig zu erkennen und beschleunigt so den Prozess der Bereitstellung von Daten mit „gut genug“ Qualität für die Benutzer.

Begriffsdefinitionen

Vor der Diskussion des Themas ist ein gemeinsames Verständnis der verwendeten Begriffe wichtig.

DataWarehouse (DWH)

Ein Data Warehouse (DWH) ist ein nicht betriebsbereites System, das hauptsächlich zur Entscheidungsunterstützung verwendet wird. Es konsolidiert die Daten der operativen Systeme (alle oder eine kleinere Teilmenge) und stellt abfrageoptimierte Daten für die Benutzer des DWH-Systems bereit. Das Data Warehouse sollte im Unternehmen „eine einzige Version der Wahrheit“ bereitstellen. Ein Data Warehouse ist normalerweise aus Stufen/Schichten aufgebaut:

Die Betriebsdaten werden weitgehend unverändert in einer Staging-Schicht gespeichert. Die Kernschicht enthält konsolidierte und vereinheitlichte Daten. Die nächste optionale Stufe ist ein Ableitungsbereich , der abgeleitete Daten (z. B. eine Kundenbewertung für Verkäufe) und Aggregationen bereitstellt. Die Datamart-Schicht enthält Daten, die für eine bestimmte Benutzergruppe optimiert sind. Data Marts enthalten oft Aggregationen und viele abgeleitete Metriken. Data-Warehouse-Anwender arbeiten oft nur mit der Data-Mart-Schicht.

Zwischen jeder Phase findet eine Art Datentransformation statt. Normalerweise wird ein Data Warehouse regelmäßig mit Delta-Extraktionen der Betriebsdaten geladen und enthält Algorithmen zur Aufbewahrung historischer Daten.

Datenqualität

Datenqualität wird normalerweise als Maß dafür definiert, wie gut ein Produkt die Benutzeranforderungen erfüllt. Verschiedene Benutzer haben möglicherweise unterschiedliche Anforderungen an ein Produkt, daher hängt die Implementierung von der Perspektive des Benutzers ab, und es ist wichtig, diese Anforderungen zu identifizieren.

Datenqualität bedeutet nicht, dass die Daten vollständig oder nahezu fehlerfrei sein müssen – es hängt von den Anforderungen der Benutzer ab. Ein „gut genug“-Ansatz ist eine gute Wahl für den Anfang. Heutzutage haben größere Unternehmen „eine Daten- (oder Informations-) Regierungspolitik“, und die Datenqualität ist ein Teil davon. Eine Data Government Policy sollte beschreiben, wie Ihr Unternehmen mit Daten umgeht und sicherstellt, dass die Daten die richtige Qualität haben und Datenschutzbestimmungen nicht verletzt werden.

Datenqualität ist ein Dauerthema. Eine DQ-Schaltungsschleife muss implementiert werden (siehe nächstes Kapitel). Regulatorische Anforderungen und Compliance-Regeln wirken sich ebenfalls auf die erforderliche Datenqualität aus, wie TCPA (US Telephone Consumer Protection Act) oder GDPR in Europa für Datenschutzfragen, aber auch branchenspezifische Regeln wie Solvency II für Versicherungen in der EU, BCBS 239 und andere für das Bankwesen und so weiter.

Datenqualitätsschleife

Wie bei allen Qualitätsthemen handelt es sich bei DQ um eine fortlaufende Aktivität, die darauf abzielt, eine zufriedenstellende Qualität aufrechtzuerhalten. Als Ergebnis eines DQ-Projekts muss eine Schaltungsschleife ähnlich der folgenden implementiert werden:

Die Schritte innerhalb dieser Schleife werden in den nächsten Kapiteln beschrieben.

Datenqualitätsrollen

Um eine erfolgreiche DQ-Initiative umzusetzen, werden die folgenden Rollen benötigt:

• Dateneigentümer. Ein Data Owner ist für die Datenqualität, aber auch für den Datenschutz verantwortlich. Der Dateneigentümer „besitzt“ eine Datendomäne, kontrolliert den Zugriff und ist dafür verantwortlich, die Datenqualität sicherzustellen und Maßnahmen zur Behebung von Ergebnissen zu ergreifen. In größeren Organisationen ist es üblich, mehrere Dateneigentümer zu finden. Datendomänen können beispielsweise Marketingdaten, Kontrolldaten usw. sein. Wenn in einem Unternehmen mehr als ein Dateneigentümer existiert, sollte es eine Person (einen Dateneigentümer oder eine andere Person) geben, die für den gesamten Datenqualitätsprozess verantwortlich ist. Ein Dateneigentümer sollte eine starke Autorität haben, um die Datenqualität durchzusetzen und den DQ-Prozess zu unterstützen; Daher sind Dateneigentümer oft hochrangige Interessengruppen. Ein gutes Verständnis der Geschäftsdomäne sowie gute Kommunikationsfähigkeiten sind wichtig.
• Datenverwalter. Ein Datenverwalter hilft bei der Umsetzung der Datenqualität innerhalb eines Unternehmens, indem er Datennutzer bei Fragen zur Interpretation von Daten/des Datenmodells, Datenqualitätsproblemen usw. unterstützt. Datenverwalter sind häufig Mitarbeiter des Dateneigentümers oder können in einem Kompetenzzentrum für Datenqualität organisiert werden oder ein DQ-Team. Datenverwalter können einen IT- oder betriebswirtschaftlichen Hintergrund haben, sollten aber beide Seiten kennen. Analytische Fähigkeiten zusammen mit einem guten Verständnis der Geschäftsdomäne, die sie unterstützen, kombiniert mit starken Kommunikationsfähigkeiten, sind die Hauptvoraussetzungen für einen erfolgreichen Datenverwalter.
• Datennutzer. Dies sind Data-Warehouse-Benutzer, die mit Daten arbeiten. Datennutzer arbeiten typischerweise mit der Data-Mart-Schicht und sind für die Arbeitsergebnisse mit den Daten verantwortlich. Datennutzer stellen sicher, dass es angemessene Datenqualitätsprüfungen für die von ihnen benötigte Qualitätsstufe gibt. Datennutzer benötigen ein starkes Verständnis ihrer Daten, ihres Geschäftsbereichs und die erforderlichen analytischen Fähigkeiten, um Daten zu interpretieren. Es ist vernünftig, unter den Datennutzern in jeder Geschäftseinheit einige Personen zu finden, die für Datenqualitätsprobleme verantwortlich sind.

Um den Erfolg sicherzustellen, ist es wichtig, dass diese Rollen in den frühen Phasen Ihres DQ-Projekts klar definiert und in Ihrer Organisation weithin akzeptiert sind. Ebenso wichtig ist es, für diese Rollen kompetente Datenspezialisten zu finden, die das Projekt unterstützen.

Definieren Sie die Regeln

Suchen und implementieren Sie nützliche DQ-Prüfungen/Regeln. Das Definieren von DQ-Regeln erfordert ein gutes Verständnis Ihres Data Warehouse und seiner Verwendung.

Wie finde ich DQ-Regeln?

Wie bereits erwähnt, sind die Datennutzer (und der Dateneigentümer) für die Datennutzung und damit auch für die erforderliche Datenqualität verantwortlich. Datennutzer sollten ihre Daten gut verstehen, damit sie den besten Input für nützliche Datenqualitätsregeln geben können.

Sie sind auch diejenigen, die die Ergebnisse der Datenqualitätsregeln analysieren, daher ist es immer eine gute Idee, sie ihre eigenen Regeln definieren zu lassen. Dadurch wird die Akzeptanz weiter erhöht, das Ergebnis der einer Datennutzungseinheit zugeordneten DQ-Regeln zu prüfen und zu bewerten (siehe Kapitel „Analysieren“).

Der Nachteil dieses Ansatzes besteht darin, dass Datennutzer normalerweise nur die Data-Mart-Schicht kennen, nicht aber die früheren Schichten des Data Warehouse. Wenn Daten in den „unteren“ Stufen beschädigt wurden, wird dies nicht erkannt, wenn nur die „oberste“ Schicht Ihres Data Warehouse überprüft wird.

Fehler angehen

Welche bekannten Fehler können in einem Data Warehouse auftreten?

• Falsche Transformationslogik im Data Warehouse
  • Je komplexer Ihre IT-Landschaft ist, desto komplexer ist tendenziell auch die Transformationslogik. Dies sind die häufigsten DQ-Probleme, und die Auswirkung solcher Fehler können „verlorene“ Daten, Duplikate, falsche Werte usw. sein.
• Instabiler Ladevorgang oder falsche Handhabung von Lasten
  • Das Laden eines Data Warehouse kann ein komplexer Prozess sein, der Fehler in der Definition der Job-Orchestrierung enthalten kann (Jobs starten zu früh oder zu spät, Jobs werden nicht ausgeführt usw.). Fehler aufgrund manueller Eingriffe (z. B. einige Jobs werden übersprungen, einige Jobs werden mit dem falschen Fälligkeitsdatum oder mit den Datendateien von gestern gestartet) treten häufig auf, wenn der Ladeprozess aufgrund einer Störung außerhalb des Bandes läuft.
• Falsche Datenübertragung von Datenquellen
  • Die Datenübertragung wird häufig als Aufgabe des Quellsystems implementiert. Anomalien oder Unterbrechungen in den Auftragsabläufen können dazu führen, dass leere oder unvollständige Daten geliefert werden.
• Falsche Betriebsdaten
  • Die Daten im operativen System enthalten bisher nicht erkannte Fehler. Es mag seltsam klingen, aber es ist eine Binsenweisheit in Data-Warehouse-Projekten, dass man die Qualität der Betriebsdaten oft erst sieht, wenn die Daten in ein DWH aufgenommen werden.
• Fehlinterpretation von Daten
  • Die Daten sind korrekt, aber die Benutzer wissen nicht, wie sie sie richtig interpretieren sollen. Dies ist ein sehr häufiger „Fehler“, der nicht ausschließlich ein Problem der Datenqualität ist, sondern etwas, das mit Data Governance zu tun hat und eine Aufgabe für die Datenverwalter ist.

Diese Probleme werden häufig von Personen verursacht, denen das entsprechende Know-how und die erforderlichen Fähigkeiten zum Definieren, Implementieren, Ausführen und Arbeiten mit einer Data-Warehouse-Lösung fehlen.

Dimensionen der Datenqualität

DQ-Dimensionen sind eine gängige Methode, um DQ-Prüfungen zu identifizieren und zu gruppieren. Es gibt viele Definitionen, und die Anzahl der Dimensionen variiert erheblich: Sie können 16 oder sogar mehr Dimensionen finden. Aus praktischer Sicht ist es weniger verwirrend, mit ein paar Dimensionen zu beginnen und bei Ihren Benutzern ein allgemeines Verständnis dafür zu finden.

• Vollständigkeit: Sind alle benötigten Daten vorhanden und zugänglich? Sind alle benötigten Quellen vorhanden und geladen? Sind Daten zwischen den Phasen verloren gegangen?
• Konsistenz: Gibt es fehlerhafte/widersprüchliche/inkonsistente Daten? Beispielsweise muss das Beendigungsdatum eines Vertrags im Zustand „Beendet“ ein gültiges Datum enthalten, das größer oder gleich dem Startdatum des Vertrags ist.
• Eindeutigkeit: Gibt es Duplikate?
• Integrität: Sind alle Daten richtig verknüpft? Gibt es zum Beispiel Bestellungen, die mit nicht existierenden Kunden-IDs verknüpft sind (ein klassisches Problem der referenziellen Integrität)?
• Aktualität: Sind die Daten aktuell? In einem Data Warehouse mit täglichen Updates würde ich beispielsweise erwarten, dass die Daten von gestern heute verfügbar sind.

Auch Daten, die durch den Data-Warehouse -Ladeprozess generiert werden, können hilfreich sein.

• Tabellen mit verworfenen Daten. Ihr Data Warehouse verfügt möglicherweise über Prozesse zum Überspringen/Verzögern von Daten, die aufgrund technischer Probleme (z. B. Formatkonvertierung, fehlende obligatorische Werte usw.) nicht geladen werden können.
• Protokollierungsinformationen. Auffällige Probleme können in Protokolltabellen oder Protokolldateien geschrieben werden.
• Lieferschein. Einige Systeme verwenden „Lieferscheine“ für Daten, die von operativen Systemen bereitgestellt werden (z. B. Anzahl von Datensätzen, Anzahl unterschiedlicher Schlüssel, Summen von Werten). Diese können für Abstimmungsprüfungen (siehe unten) zwischen dem Data Warehouse und den operativen Systemen verwendet werden.

Denken Sie daran, dass jede Datenqualitätsprüfung von mindestens einem Datenbenutzer analysiert werden muss (siehe Kapitel „Analyse“), falls Fehler gefunden werden, wofür Sie jemanden benötigen, der verantwortlich und verfügbar ist, um sich um jede implementierte Prüfung zu kümmern.

In einem komplexen Data Warehouse können Sie am Ende viele (manchmal Tausende) DQ-Regeln haben. Der Prozess zur Ausführung von Datenqualitätsregeln sollte robust und schnell genug sein, um dies zu bewältigen.

Prüfen Sie keine Fakten, die durch die technische Umsetzung garantiert sind. Wenn die Daten beispielsweise in einem relationalen DBMS gespeichert sind, muss nicht geprüft werden, ob:

• Als obligatorisch definierte Spalten enthalten NULL-Werte.
• Die Werte der Primärschlüsselfelder sind in einer Tabelle eindeutig.
• In einer Tabelle mit aktivierter relationaler Integritätsprüfung sind keine Fremdschlüssel vorhanden.

Denken Sie jedoch immer daran, dass sich ein Data Warehouse ständig verändert und dass sich die Datendefinition von Feldern und Tabellen im Laufe der Zeit ändern kann.

Die Haushaltsführung ist sehr wichtig. Regeln, die von verschiedenen Datennutzereinheiten definiert werden, können sich überschneiden und sollten konsolidiert werden. Je komplexer Ihre Organisation ist, desto mehr Haushalt wird benötigt. Dateneigentümer sollten einen Prozess der Regelkonsolidierung als eine Art „Datenqualität für Datenqualitätsregeln“ implementieren. Außerdem können Datenqualitätsprüfungen nutzlos werden, wenn die Daten nicht mehr verwendet werden oder wenn sich ihre Definition geändert hat.

Klassen von Datenqualitätsregeln

Datenqualitätsregeln können basierend auf der Art des Tests klassifiziert werden.

• Prüfung der Datenqualität. Der „normale“ Fall, Daten innerhalb einer Data-Warehouse-Schicht (siehe Abbildung 1) entweder innerhalb einer Tabelle oder einer Gruppe von Tabellen zu prüfen.
• Versöhnung. Regeln, die prüfen, ob Daten korrekt zwischen Data-Warehouse-Schichten transportiert wurden (siehe Abbildung 1). Diese Regeln werden hauptsächlich verwendet, um die DQ-Dimension „Vollständigkeit“ zu überprüfen. Bei der Abstimmung kann eine einzelne Zeile oder ein zusammengefasster Ansatz verwendet werden. Die Überprüfung einzelner Zeilen ist viel detaillierter, aber Sie müssen die Transformationsschritte (Datenfilterung, Änderungen der Feldwerte, Denormalisierung, Verknüpfungen usw.) zwischen den verglichenen Schichten reproduzieren. Je mehr Ebenen Sie übersprungen haben, desto komplexer muss die Transformationslogik implementiert werden. Daher ist es eine gute Wahl, einen Abgleich zwischen jeder Schicht und ihrem Vorgänger durchzuführen, anstatt das Staging mit der Datamart-Schicht zu vergleichen. Wenn Transformationen in Abstimmungsregeln implementiert werden müssen, verwenden Sie die Spezifikation, nicht den Data-Warehouse-Code! Suchen Sie für den zusammenfassenden Abgleich aussagekräftige Felder (z. B. Zusammenfassung, Anzahl unterschiedlicher Werte usw.).
• Überwachung. Ein Data Warehouse enthält normalerweise historische Daten und wird mit Delta-Extrakten von Betriebsdaten geladen. Es besteht die Gefahr einer langsam größer werdenden Lücke zwischen dem Data Warehouse und den Betriebsdaten. Die Erstellung zusammengefasster Zeitreihen von Daten hilft bei der Identifizierung solcher Probleme (z. B. Vergleich der Daten des letzten Monats mit den Daten des aktuellen Monats). Datennutzer mit guten Kenntnissen ihrer Daten können nützliche Maßnahmen und Schwellenwerte für Überwachungsregeln bereitstellen.

So quantifizieren Sie ein Datenqualitätsproblem

Nachdem Sie definiert haben, was überprüft werden soll, müssen Sie angeben, wie die identifizierten Probleme quantifiziert werden sollen. Angaben wie „fünf Datenzeilen verletzen die DQ-Regel mit der ID 15“ machen für die Datenqualität wenig Sinn.

Folgende Teile fehlen:

• Wie man die erkannten Fehler quantifiziert/zählt. Sie können die „Anzahl der Zeilen“ zählen, aber Sie können auch eine monetäre Skala verwenden (z. B. Exposition). Denken Sie daran, dass monetäre Werte unterschiedliche Vorzeichen haben können, also müssen Sie untersuchen, wie Sie sie sinnvoll zusammenfassen können. Sie könnten erwägen, beide Quantifizierungseinheiten (Anzahl der Zeilen und Zusammenfassung) für eine Datenqualitätsregel zu verwenden.
• Bevölkerung. Wie viele Einheiten werden von der Datenqualitätsregel geprüft? „Fünf Datenzeilen von fünf“ hat eine andere Qualität als „fünf von 5 Millionen“. Die Grundgesamtheit sollte unter Verwendung der gleichen Quantifizierung(en) wie für die Fehler gemessen werden. Es ist üblich, das Ergebnis einer Datenqualitätsregel als Prozentsatz anzuzeigen. Die Population darf nicht mit der Anzahl der Zeilen einer Tabelle identisch sein. Wenn eine DQ-Regel nur eine Teilmenge der Daten prüft (z. B. nur gekündigte Verträge in der Vertragstabelle), sollte der gleiche Filter angewendet werden, um die Grundgesamtheit zu messen.
• Definition des Ergebnisses. Auch wenn eine Datenqualitätsprüfung Probleme findet, muss dies nicht immer einen Fehler verursachen. Für die Datenqualität ist ein Ampelsystem (rot, gelb, grün) mit Schwellenwerten zur Bewertung von Befunden sehr hilfreich. Zum Beispiel Grün: 0–2 %, Gelb: 2–5 %, Rot: über 5 %. Denken Sie daran, dass Datenbenutzereinheiten, die dieselben Regeln verwenden, sehr unterschiedliche Schwellenwerte für eine bestimmte Regel haben können. Einer Marketingabteilung macht es vielleicht nichts aus, wenn ein paar Aufträge verloren gehen, während eine Buchhaltungseinheit vielleicht sogar Cent stört. Es sollte möglich sein, Schwellenwerte in Prozent oder in absoluten Zahlen festzulegen.
• Sammeln Sie Beispielfehlerzeilen. Es hilft, wenn eine Datenqualitätsregel eine Stichprobe der erkannten Fehler liefert – normalerweise reichen die (geschäftlichen!) Schlüssel und die überprüften Datenwerte aus, um den Fehler zu untersuchen. Es empfiehlt sich, die Anzahl der geschriebenen Fehlerzeilen für eine Datenqualitätsregel zu begrenzen.
• Manchmal finden Sie möglicherweise „bekannte Fehler“ in den Daten, die nicht behoben werden, aber durch nützliche Datenqualitätsprüfungen gefunden werden. Für diese Fälle empfiehlt sich die Verwendung von Whitelists (Schlüssel von Datensätzen, die bei einer Datenqualitätsprüfung übersprungen werden sollen).

Andere Metadaten

Metadaten sind wichtig, um die „Analyse“ zu steuern und die Phasen des Datenqualitätsregelkreises zu überwachen.

• Geprüfte Artikel. Es hilft, die geprüfte(n) Tabelle(n) und Feld(er) einer Datenqualitätsregel zuzuordnen. Wenn Sie über ein erweitertes Metadatensystem verfügen, kann dies hilfreich sein, um dieser Regel automatisch Datenbenutzer und einen Dateneigentümer zuzuweisen. Aus regulatorischen Gründen (z. B. BCBS 239) ist zudem nachzuweisen, wie die Daten durch DQ geprüft werden. Das automatische Zuweisen von Regeln zu Datennutzern/Dateneigentümern über die Datenherkunft (*) könnte jedoch ein zweischneidiges Schwert sein (siehe unten).
• Datennutzer. Jeder DQ-Regel muss mindestens ein Datennutzer/eine Datennutzereinheit zugeordnet sein, die das Ergebnis während der Phase „Analysieren“ überprüft und entscheidet, ob und wie ein Befund ihre Arbeit mit den Daten beeinflusst.
• Eigentümer der Daten. Jeder DQ-Regel muss ein Dateneigentümer zugewiesen sein.

(*) Die Datenherkunft zeigt den Datenfluss zwischen zwei Punkten. Mit Data Lineage können Sie alle Datenelemente finden, die ein bestimmtes Zielfeld in Ihrem Warehouse beeinflussen.

Die Verwendung von Data Lineage zum Zuweisen von Benutzern zu Regeln kann problematisch sein. Wie bereits erwähnt, kennen Fachanwender in der Regel nur die Data-Mart-Schicht (und das Betriebssystem), nicht aber die unteren Ebenen des Data Warehouse. Durch die Zuordnung über die Datenherkunft werden Datenbenutzern Regeln zugewiesen, mit denen sie nicht vertraut sind. Für die unteren Ebenen kann IT-Personal benötigt werden, um eine Feststellung der Datenqualität zu bewerten. In vielen Fällen kann ein manuelles Mapping oder ein gemischter Ansatz (Mapping via Data Lineage nur innerhalb des Data Mart) helfen.

Datenqualität messen

Die Messung der Datenqualität bedeutet, dass die verfügbaren Datenqualitätsregeln ausgeführt werden, was automatisch erfolgen sollte, ausgelöst durch die Ladeprozesse des Data Warehouse. Wie wir bereits gesehen haben, kann es eine bemerkenswerte Anzahl von Datenqualitätsregeln geben, sodass die Überprüfungen zeitaufwändig sind.

In einer perfekten Welt würde ein Data Warehouse nur geladen, wenn alle Daten fehlerfrei sind. In der realen Welt ist dies selten der Fall (realistisch gesehen ist es fast nie der Fall). Abhängig von der allgemeinen Ladestrategie Ihres Data Warehouse sollte der Datenqualitätsprozess den Ladeprozess bestimmen oder nicht (letzteres ist viel wahrscheinlicher). Es ist ein gutes Design, Datenqualitätsprozesse (Job-Netzwerke) parallel und mit den „normalen“ Data-Warehouse-Ladeprozessen zu verknüpfen.

Wenn es definierte Service-Level-Agreements gibt, achten Sie darauf, die Data-Warehouse-Lasten nicht mit den Datenqualitätsprüfungen zu konterkarieren. Fehler/Abbrüche in Datenqualitätsprozessen sollten den regulären Ladeprozess nicht stoppen. Unerwartete Fehler innerhalb der Datenqualitätsprozesse sollten gemeldet und für die Phase „Analysieren“ (siehe nächstes Kapitel) aufgezeigt werden.

Beachten Sie, dass eine Datenqualitätsregel aufgrund unerwarteter Fehler abstürzen kann (möglicherweise wurde die Regel selbst falsch implementiert oder die zugrunde liegende Datenstruktur hat sich im Laufe der Zeit geändert). Es wäre hilfreich, wenn Ihr Datenqualitätssystem einen Mechanismus zum Deaktivieren solcher Regeln bereitstellen würde, insbesondere wenn Ihr Unternehmen nur wenige Veröffentlichungen pro Jahr hat.

DQ-Prozesse sollten so früh wie möglich ausgeführt und gemeldet werden – idealerweise direkt nach dem Laden der geprüften Daten. Dies hilft, Fehler beim Laden des Data Warehouse (einige komplexe Warehouse-Systemladevorgänge haben eine Dauer von mehreren Tagen) so früh wie möglich zu erkennen.

Analysieren

„Analysieren“ bedeutet in diesem Zusammenhang, auf Erkenntnisse zur Datenqualität zu reagieren. Dies ist eine Aufgabe für die zugeordneten Datennutzer und den Dateneigentümer.

Die Art und Weise, wie Sie reagieren, sollte von Ihrem Datenqualitätsprojekt klar definiert sein. Datennutzer sollten verpflichtet werden, eine Regel mit Befunden (zumindest Regeln mit roter Ampel) zu kommentieren und darzulegen, welche Maßnahmen zum Umgang mit dem Befund ergriffen werden. Der Dateneigentümer muss informiert werden und sollte gemeinsam mit dem/den Datennutzer(n) entscheiden.

Folgende Aktionen sind möglich:

• Schwerwiegendes Problem: Das Problem muss behoben und das Laden der Daten wiederholt werden.
• Problem ist akzeptabel: Versuchen Sie, es für zukünftige Datenladevorgänge zu beheben, und behandeln Sie das Problem innerhalb des Data Warehouse oder der Berichterstellung.
• Defekte DQ-Regel: Korrigieren Sie die problematische DQ-Regel.

In einer perfekten Welt wäre jedes Datenqualitätsproblem behoben. Mangelnde Ressourcen und/oder Zeit führen jedoch häufig zu Problemumgehungen.

Um rechtzeitig reagieren zu können, muss das DQ-System die Datennutzer über „ihre“ Regeln mit Befunden informieren. Die Verwendung eines Datenqualitäts-Dashboards (möglicherweise mit dem Senden von Nachrichten, dass etwas aufgetreten ist) ist eine gute Idee. Je früher die Nutzer über Befunde informiert werden, desto besser.

Das Datenqualitäts-Dashboard sollte Folgendes enthalten:

• Alle Regeln, die einer bestimmten Rolle zugewiesen sind
• Die Ergebnisse der Regeln (Ampel, Kennzahlen und Beispielzeilen) mit der Möglichkeit, Regeln nach Ergebnis und Datendomäne zu filtern
• Ein obligatorischer Kommentar, den Datenbenutzer für Befunde eingeben müssen
• Eine Funktion zum optionalen „Überstimmen“ des Ergebnisses (wenn die Datenqualitätsregel beispielsweise Fehler aufgrund einer fehlerhaften Implementierung meldet). Wenn mehr als einem Geschäftsbereich die gleiche Datenqualitätsregel zugewiesen ist, gilt „Überschreiben“ nur für den Geschäftsbereich des Datennutzers (nicht für das gesamte Unternehmen).
• Nicht ausgeführte oder abgebrochene Regeln anzeigen

Das Dashboard sollte auch den aktuellen Status des letzten Data-Warehouse-Ladevorgangs anzeigen und den Benutzern eine 360-Grad-Sicht auf den Data-Warehouse-Ladevorgang geben.

Der Dateneigentümer ist dafür verantwortlich, dass jeder Befund kommentiert wurde und der Status der Datenqualität (ursprünglich oder überschrieben) für alle Datennutzer mindestens gelb ist.

Für einen schnellen Überblick würde es helfen, eine Art einfache KPIs (Key Performance Indicators) für Datennutzer/Dateneigentümer aufzubauen. Es ist recht einfach, eine allgemeine Ampel für die Ergebnisse aller zugeordneten Regeln zu haben, wenn jeder Regel die gleiche Gewichtung gegeben wird.

Persönlich denke ich, dass die Berechnung eines Gesamtwerts der Datenqualität für eine bestimmte Datendomäne ziemlich komplex und tendenziell kabbalistisch ist, aber Sie könnten zumindest die Anzahl der Gesamtregeln gruppiert nach Ergebnis für eine Datendomäne zeigen (z. B. „100 DQ-Regeln mit 90 % grünen, 5 % gelben und 5 % roten Ergebnissen“).

Es ist die Aufgabe des Dateneigentümers sicherzustellen, dass die Feststellungen behoben und die Datenqualität verbessert werden.

Prozesse verbessern

Da sich die Data-Warehouse-Prozesse häufig ändern, muss auch der Datenqualitätsmechanismus gewartet werden.

Ein Dateneigentümer sollte sich immer um die folgenden Punkte kümmern:

• Halten Sie es auf dem Laufenden. Änderungen im Data Warehouse müssen im Datenqualitätssystem erfasst werden.
• Erweitern. Implementieren Sie neue Regeln für Fehler, die noch nicht durch Datenqualitätsregeln abgedeckt sind.
• Rationalisieren. Deaktivieren Sie nicht mehr benötigte Datenqualitätsregeln. Konsolidieren Sie sich überschneidende Regeln.

Überwachung von Datenqualitätsprozessen

Die Überwachung des gesamten Datenqualitätsprozesses hilft, ihn im Laufe der Zeit zu verbessern.

Sehenswert wären:

• Die Abdeckung Ihrer Daten mit Datenqualitätsregeln
• Der Prozentsatz der Datenqualitätsergebnisse innerhalb der aktiven Regeln im Laufe der Zeit
• Die Anzahl aktiver Datenqualitätsregeln (Behalten Sie es im Auge – ich habe gesehen, wie Datennutzer ihre Ergebnisse lösten, indem sie einfach immer mehr Datenqualitätsregeln deaktivierten.)
• Die Zeit, die innerhalb eines Datenladevorgangs benötigt wird, um alle Befunde bewertet und behoben zu haben

Fazit

Viele der folgenden Punkte sind bei jeder Art von Projekt wichtig.

Erwarten Sie Widerstand. Wie wir gesehen haben, wird Datenqualität oft als zusätzliche Belastung ohne neue Funktionalität angesehen, wenn es kein dringendes Qualitätsproblem gibt. Beachten Sie, dass dies zu zusätzlicher Arbeitsbelastung für die Datennutzer führen kann. In vielen Fällen können Ihnen Compliance- und regulatorische Anforderungen dabei helfen, die Benutzer davon zu überzeugen, dass dies eine unvermeidliche Anforderung ist.

Finden Sie einen Sponsor. Wie oben erwähnt, ist DQ kein Verkaufsschlager, daher wird ein starker Sponsor/Stakeholder benötigt – je höher im Management, desto besser.

Finden Sie Verbündete. Wie beim Sponsor wäre jeder, der die Idee einer starken Datenqualität teilt, am hilfreichsten. Die DQ-Schaltungsschleife ist ein fortlaufender Prozess und braucht Menschen, um die Schaltungsschleife am Leben zu erhalten.

Fangen Sie klein an. Wenn es bisher keine DQ-Strategie gab, suchen Sie nach einer Geschäftseinheit, die eine bessere Datenqualität benötigt. Erstellen Sie einen Prototyp, um ihnen die Vorteile besserer Daten zu zeigen. Wenn Ihre Aufgabe darin besteht, eine bestimmte Datenqualitätsstrategie zu verbessern oder sogar zu ersetzen, prüfen Sie, ob die Dinge gut funktionieren/in der Organisation akzeptiert werden, und behalten Sie sie bei.

Verlieren Sie nicht das Gesamtbild aus den Augen. Auch wenn Sie klein anfangen, denken Sie daran, dass einige Punkte, insbesondere die Rollen, Voraussetzungen für eine erfolgreiche DQ-Strategie sind.

Einmal implementiert, nicht mehr loslassen. Der Datenqualitätsprozess muss Teil der Data-Warehouse-Nutzung sein. Im Laufe der Zeit geht der Fokus auf die Datenqualität ein wenig verloren, und es liegt an Ihnen, ihn aufrechtzuerhalten.