Beurteilung der Datenqualität – Verbesserung vs. laufende Überwachung

April 16, 2010 by · 1 Comment
Filed under: Deutsch 

Für englisch-sprachige Leser: There is an English version of this post.

 

Letzte Woche sprach ich mit einem Kunden über die Messung von Datenqualität. Für eine Weile schien es, als ob wir uns auf nichts einigen konnten, bis wir erkannten, dass wir über verschiedene Arten von DQ-Projekte sprechen:

  • Ein Projekt zur Verbesserung der Datenqualität in einem bestimmten Bereich
  • Laufende Überwachung der Datenqualität, um ein akzeptables Niveau sicherzustellen

image

Sobald wir über diese verschiedenen sprachen, kam Vereinbarung sehr leicht.

Verbesserung der Datenqualität

Bei dieser Art von Projekt, gibt es einen wichtigen Grund zur Verbesserung der Datenqualität. Normalerweise startet man mit einer relativ großen Fehlerzahl und muss sich auf ein akzeptables Niveau verbessern. Oftmals bedeutet dies 0 Fehler, oft ist aber auch eine kleine Fehlerzahl akzeptabel (z.B. 10 Datensätze, die ggf. manuell migriert werden können). Beispiele für diese Art von Projekten ist die Einhaltung regulatorischer Anforderungen oder die Migration auf ein anderes System.

Hierbei handelt es sich um ein Projekt im engeren Sinne: Es gibt einen festen Endtermin. Wie so oft muss das Ziel zunächst genauer definiert werden, nachdem das Projekt gestartet ist. Bei DQ Projekten beinhaltet dies die Identifikation relevanter Datenbereiche, die Erarbeitung Regeln, denen die Daten genügen müssen, und ein Verfahren zur Ermittlung der fehlerhaften Datensätze. Am Ende dieser Phase hat man eine Reihe von DQ Messgrößen (siehe meinen Beitrag zur Definition von DQ Messgrößen) und eine idealerweise automatische Möglichkeit zur Durchführung von Messungen für diese Messgrößen. Ein Erfahrungswert aus meinen Projekten: Nach der anfänglichen Definitionsphase hatte man eine Liste von 20 bis etwa 100 Messgrößen, die für den Rest des Projektes relativ stabil war.

Die wichtigsten Fragen, die in dieser Art von DQ-Projekt beantwortet werden müssen:

  • Welche DQ Probleme wurden aufgeworfen, an welchen müssen wir noch arbeiten und welche sind schon gelöst?
  • Sind wir im Plan, um das gesetzte Zielniveau vor dem End-Termin zu erreichen?

Laufende Überwachung der Datenqualität

Im Gegensatz zu Verbesserungs-Projekten gibt es bei der laufenden Überwachung kein Enddatum, es handelt sich um eine kontinuierliche Maßnahme. (Teilweise gehen auch Verbesserungs-Projekte zum Ende in eine Überwachungs-Phase – die meisten Probleme sind bereits gelöst, es muss aber immer noch sichergestellt werden, dass ein akzeptables Niveau gehalten wird.)

Oft sind viele Vorarbeiten für die laufende Überwachung bereits durch ein Verbesserungs-Projekt geleistet. Da in die laufende Überwachung DQ Messgrößen aus mehreren Projekten eingehen, hat man hier oft eine noch größere Zahl an Messgrößen.

Da die Datenqualität meist schon auf einem akzeptablen Niveau ist, stehen hier andere Fragestellungen im Vordergrund:

  • Gab es Veränderungen, die ein Eingreifen erforderlich machen?
  • Wie gut decken die bestehenden Regeln den gesamten Datenhaushalt ab?

Beurteilung von DQ Messungen in verschiedenen DQ-Projektarten

Eine DQ Messgröße kann unabhängig von der Art des Projekts definiert werden, in dem sie verwendet werden soll. Allerdings ist bei der Beurteilung der Projektkontext zu berücksichtigen, so dass bei der Beurteilung unterschiedliche Fragen beantwortet werden müssen. Im laufenden Projekt arbeiten wir noch daran, wie diese Beurteilung sinnvoll erfolgen kann – aber mit den unterschiedlichen Arten von DQ Projekten haben wir eine gemeinsame Basis für die weitere Arbeit geschaffen.

DQ Messgröße – Steckbrief-Beispiel

February 8, 2010 by · 1 Comment
Filed under: Deutsch 

Für englisch-sprachige Leser: There is an English version of this post.

Im letzen Blogpost wurden die Elemente eines Steckbriefs für DQ Messgrößen vorgestellt. Diese Elemente sollen mit Hilfe eines ausführlichen Beispiels verdeutlicht werden.

1. Bezeichnung

Grundlage der weiteren Diskussion ist folgende Regel:

  • Messgröße 1: Partner, die keine Postanschrift besitzen
    Diese Messgröße wird im folgenden genauer beschrieben.

Weitere, einfache Regeln:

  • Messgröße 2: Kunden, bei denen Anzeichen für eine Dublette vorliegen
  • Messgröße 3: Aktive Baufinanzierungs-Darlehen, bei denen für das Besicherungsobjekt kein Beleihungswert vorliegt.

2. Datenregel

Allen Partnern (Datensätze in der Tabelle BUT000) sind normalerweise Adressen (Tabelle ADRC) mit Hilfe der Tabelle BUT021_FS (Adressverwendung BUT021_FS–ADRVERW = “WAGA”) zugeordnet werden. Von der Messgröße werden Partner erfasst, bei denen keine Verknüpfung in der BUT021_FS vorkommt oder kein gültiger Satz in der BUT021_FS (aktuelles Datum zwischen DATE_FROM und DATE_TO) vorliegt.

Dabei sind nur solche Partner relevant, die Hauptdarlehenspartner eines Darlehens sind. (Für diese Partner gibt es einen Satz in der Tabelle VDGPO mit SNUMOBJ = ‘VD’ und ROLETYP=’TR0100’.)

3. Auswirkungen der Regelverletzungen

  • Bei Partnern ohne Adresse gibt es keine Möglichkeit, Schreiben (Informationen, Einladungen, etc.) zu versenden(Prozess kann nicht durchgeführt werden).
  • Wenn an einen Partner ohne Adresse eine Mahnung versendet werden soll, muss die Adresse erst aufwändig ermittelt werden (Prozess kann nur mit zusätzlichem Aufwand durchgeführt werden).
  • Bei Kunden ohne Anschrift ist die Bestimmung der Region nicht möglich, die ein wichtiges Kriterium bei der Ermittlung des Kundenratings darstellt. Die Risikobewertung des Kunden ist daher ungenau (ungenaue Kennzahl).
  • Kontobewegungen von Kunden aus dem Ausland müssen gemäß AWG/AWV gemeldet werden. Ohne deutsche Anschrift kann nicht ausgeschlossen werden, dass der Kunde im Ausland wohnt (Verletzung gesetzlicher Vorschriften).

4. Fehler-Ursachen

Die Erfassung einer Postanschrift erfolgt im SAP Geschäftspartner (Transaktionen BUP1 und BUP2). Eine erfasste Anschrift muss zusätzlich über den Reiter “Adressübersicht” als “Postanschrift” dem Partner zugeordnet werden. Teilweise wird bei der Neuanlage eines Partners versäumt, diese Zuordnung vorzunehmen.

Diese Zuordnung ist zeitabhängig, d.h. sie kann mit einem Anfangs- und Endedatum versehen werden. Wenn bei der Erfassung bekannt ist, dass ein baldiger Umzug bevorsteht (z.B. wenn der Partner ein Immobilien-Darlehen aufnimmt), wird ein Beziehungsende erfasst, ohne die anschließend neu geltende Adresse zu erfassen. Wenn dies vor Ablauf der Gültigkeit der alten Adresse nicht nachgeholt wird, verliert die alte Adresse ihre Gültigkeit und der Partner besitzt keine gültige Postanschrift.

5. Vorgehen zur Korrektur der fehlerhaften Datensätze

  • Wenn zu einem Partner keine Postanschrift erfasst wurde, so ist durch einen Sachbearbeiter in Abteilung A in der SAP Transaktion BUP2 die Standardanschrift über den Reiter “Adressübersicht” dem Partner als Postanschrift ohne festes Enddatum zuzuordnen.
  • Wenn die Postanschrift erfasst wurde, diese aber ihre Gültigkeit verloren hat, ist zunächst zu prüfen, ob eine neue Standardanschrift zugeordnet wurde. Ist dies der Fall, ist diese wie oben beschreiben auch als Postanschrift zu übernehmen.
  • Ist auch keine neue Standardanschrift erfasst worden, so ist über die zuständige Filiale, die ggf. Kontakt mit dem Kunden aufnimmt, die korrekte Anschrift zu ermitteln und zu erfassen.

DQ Messgröße – 5 Steckbrief-Elemente

February 1, 2010 by · 2 Comments
Filed under: Deutsch 

Für englisch-sprachige Leser: There is an English version of this post.

Dass eine DQ Messgröße einen aussagekräftigen Namen erhalten muss, ist wohl klar. Was sonst noch dazu gehört, wird in diesem Artikel genauer betrachtet. In einem folgenden Eintrag werden die Elemente an einem Beispiel weiter diskutiert.

1. Bezeichnung der DQ Messgröße

Eine aussagekräftige, einheitliche Bezeichnung erleichtet die Kommunikation zwischen den Beteiligten. Sie sollte die Messgröße knapp, aber möglichst genau beschreiben.

2. Beschreibung der Datenregel

Die Beschreibung der einzuhaltenden Datenregel muss so detailliert sein, dass die genaue Umsetzung der Prüfung abgeleitet werden kann und somit die DQ Messgröße mit Hilfe eines SQL Statements oder eines Programms umgesetzt werden kann. Dabei verwendete allgemeine Begriffe (z.B. ‘Kunde’) sind zu definieren, z.B. in einem allgemeinen Abschnitt der Dokumentation oder in einem Business-Glossar.

Nach Möglichkeit ist diese Regel zusammen mit dem betroffenen Fachbereich zu erarbeiten und meist in einem iterativen Prozess zu schärfen. Die dabei ermittelten Ausnahmen (d.h. Konstellationen bei denen eine Verletzung der Regel keinen Fehler darstellt) sind ebenfalls festzuhalten.

3. Auswirkungen der Regelverletzungen

Für eine Priorisierung bei mehreren DQ-Problemen ist es wichtig, die Folgen von Regelverletzungen zu kennen. Erste Ansatzpunkte:

  • Entstehen direkte Folgekosten durch die Regelverletzungen?
  • Werden gesetzliche Vorschriften verletzt?
  • Können Prozesse nicht oder nur mit zusätzlichem Aufwand oder Kosten durchgeführt werden?
  • Können Kennzahlen nicht bestimmt werden oder werden durch Regelverletzungen ungenau oder unzuverlässig?

Nach Möglichkeit sind qualitative und quantitative Folgen so genau wie möglich anzugeben. Hierfür ist es wichtig, einen guten Überblick über die Prozesse und Datenbewirtschaftung des Unternehmens zu haben und mit den verschiedenen Fachbereichen die Auswirkungen von Regelverletzungen zu erarbeiten. Um Management-Unterstützung für die Beseitigung von DQ-Problemen zu erhalten, ist es unerlässlich, die Folgen des Nicht-Handelns aufzuzeigen.

4. Fehler-Ursachen

Um einen Ansatz zur Korrektur und zur dauerhaften Beseitigung des DQ-Problems zu haben, ist es wichtig zu ermitteln, wo das DQ-Problem entsteht. In welchem System sind fehlerhafte Eingaben erfolgt oder benötigte Angaben unterblieben? U.U. muss man dabei mehrere Schritte in der Datenbewirtschaftungskette zurückgehen, um zur eigentlichen Fehler-Ursache zu kommen.

Die genaue Beschreibung der Fehler-Ursachen stellt eine wertvolle Hilfe bei der Definition von Präventionsmaßnahmen dar, mit denen nach einer Korrektur das erneute Auftreten des DQ-Problems verhindert werden soll.

5. Vorgehen zur Korrektur der fehlerhaften Datensätze

Den Abschluss bildet eine Beschreibung, wie fehlerhafte Datensätze korrigiert werden können:

  • Wenn Angaben fehlen oder falsch sind, wie können die korrekten Werte bestimmt werden? Können die Werte aus dem Internet (z.B. fehlerhafte Postleitzahlen) oder der Kundenakte entnommen werden? Muss gar der Kunde direkt angesprochen werden?
  • Werden diese Angaben von einem Benutzer erfasst werden? Welche Programme, Menüpunkte, Transaktionen etc. können dazu verwendet werden?
  • Gibt es ein Korrektur-Programm, mit dem eine maschinelle Korrektur bei großen Datenmengen erfolgen kann?

Mit diesen Informationen kann bei Auftreten von Fehlern schnell reagiert werden.