Heute schon das Vertrauen in DQM erhöht?

May 10, 2010 by · 1 Comment
Filed under: Deutsch 

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

In der letzten Zeit wurde einige Blogposts veröffentlicht, in denen ein Pranger als Mittel zur Verbesserung der Datenqualität diskutiert wurden. Hier sind einige englisch-sprachige Beispiele:

  • A Data Quality Riot Act von Rob Paller
  • The Poor Data Quality Jar
  • The Scarlet DQ, beide von Jim Harris auf OCDQBlog
  •  

      Picture by Okinawa Soba, taken from flickr with a cc license

    Bei diesen Beiträge hatte ich das Gefühl, dass die Reaktion zwar menschlich verständlich ist, aber der Sache eher schadet. Um die Diskussion dazu weiter zu führen, möchte ich meine Gedanken zum “Vertrauen in DQM” etwas weiter ausführen und freue mich über Kommentare und andere Sichtweisen.

    Das Problem, das ich mit dem “öffentlichen Anprangern” aus den Posts von Rob und Jim sehe: Ein solches Vorgehen wird nur unter engen Bedingungen funktionieren – wenn das Anprangern mit einem Augenzwinkern erfolgt. Am einfachsten ist es, wenn der “Beschuldigte” von sich aus versteht, was falsch gelaufen ist – dann kann der “Anschiss” so übertrieben sein, dass er nicht ernst genommen werden kann und es so zu keinem persönlichen Angriff kommt, aber der Hinweis trotzdem aufgegriffen wird.

    Damit das funktioniert, sehe ich zwei Möglichkeiten: Man ist so witzig, dass ein “Anschiss” an einen neuen Kollegen zu einem Schmunzeln führt – ich selbst bekomme das mit Sicherheit nicht hin. Zudem birgt es das Risiko, dass das Ganze nach hinten losgeht und man dann sein Verhalten mit dem Vorgesetzten des Kollegen besprechen muss. Nach meinen Erfahrungen werden solche Gespräche immer humorloser, je weiter es in der Firmenhierarchie nach oben geht. Insgesamt sehr riskant, sich auf sein komödiantisches Talent zu verlassen.

    Damit bleibt die zweite Möglichkeit – das Anprangern erfolgt nur in Ausnahmefällen und erst, nachdem man Vertrauen in DQM aufgebaut und den Beteiligten klar ist, das es um die Verbesserung der Datenqualität geht und nicht darum, jemandem die Schuld für Probleme in die Schuhe zu schieben.

    Leider nimmt man sich selten genug Zeit zum Aufbau des dafür erforderlichen Vertrauens, vielmehr kann mühselig aufgebautes Vertrauen mit einer unbedachten Äußerung wieder verspielt werden. Hier sind ein paar Ideen, Vertrauen in DQM zu schaffen:

    • eine Beurteilung sollte so spät wie möglich erfolgen – man sollte erst versuchen herauszufinden, warum Leute bestimmte Vorgehen gewählt haben, bevor man sie als Idioten bezeichnet
    • Man kann gerne zugeben, auch nicht alles zu wissen und laufend dazuzulernen, in dem man mit so vielen Leuten wie möglich spricht, die verschiedene Blickwinkel auf ein Thema haben
    • Unterstützen Sie die Leute bei der Lösung derer Probleme – dann ist die Bereitschaft größer, auch bei DQ Problemen zu helfen
    • Datenqualität muss abhängig vom Zuhörer erklärt werden – ein Fachbereich interessiert sich nicht für referentielle Integrität, wenn man ihm nicht erklärt, was das in seiner täglichen Arbeit bedeutet
    • Seien Sie nicht zu akademisch in Ihren DQ Anforderungen – es macht keinen Sinn, bei kaum verwendeten Daten eine perfekte Datenqualität zu verlangen

    Selbst mit dieser Grundeinstellung muss ich oft erst einmal den Kopf darüber schütteln, auf welche schwachsinnigen Dinge einige Benutzer kommen. Dann frage ich mich aber, welche Reaktion ich ernten würde, den Benutzer damit ein wenig aufzuziehen. In den meisten Fällen gehe ich dann etwas vorsichtiger vor und diskutiere über die Auswirkungen der Fehler anstatt persönliche Schuld zu suchen. Das ist kurzfristig nicht ganz so befriedigend wie “Luft abzulassen”, hat aber langfristig viel bessere Erfolgsaussichten. Wie reagieren Sie in solchen Situationen, welche Erfahrungen haben Sie gesammelt?

    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.

    Der DQ Kreislauf – ein Vorgehen bei DQ Problemen

    March 29, 2010 by · Leave a Comment
    Filed under: Deutsch 

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

    In den letzten Beiträgen habe ich einige Aspekte dargestellt, die beim Aufbau einer DQ Initiative relevant sind. Dieser Artikel beschreibt, wie man bei konkreten DQ Problemen vorgehen sollte.

    Einordnung

    Der Deming-Kreis ist ein bewährter, vier-stufiger Prozess, der üblicher Weise zur Qualitäts-Verbesserung eingesetzt wird. Er ist nach seinen Phasen auch als PDCA bekannt:

    • Plan
      Erkennen von Verbesserungspotentialen, die Analyse des aktuellen Zustands sowie das Entwickeln eines neuen Konzeptes
    • Do
      Ausprobieren und praktisches Optimieren des Konzeptes mit schnell realisierbaren, einfachen Mitteln
    • Check
      Überprüfung des realisierten Prozessablaufs und seiner Resultate
    • Act
      Untersuchung der Abweichungen und deren Ursachen, die dann wieder in eigenen PDCA-Schritten bearbeitet werden

    (Basierend auf dem Wikipedia Artikel zum Demingkreis.)

    Überblick

    Der DQ Kreislauf ist ein Anwendung dieser allgemeinen Vorgehensweise auf DQ Probleme. Diesen Rahmen habe ich bei mehreren Kunden mit gutem Erfolg eingesetzt. Die Grundsätze sind recht einfach, stellen aber eine gute Checkliste dar, um alle erforderlichen Punkte auch abzuhaken und so eine nachhaltige Lösung der DQ Probleme sicherzustellen.

    Der DQ Kreislauf hat die gleichen Phasen wie der Deming Kreis. Er beschreibt, wie man mit einem einzelnen identifizierten DQ Problem umgeht. Dies bedeutet, dass es zeitgleich mehrere DQ Kreisläufe in unterschiedlichen Phasen geben, die jeder ein einzelnes Problem zum Schwerpunkt haben.

    Die obige Beschreibung bezieht sich auf “identifizierte DQ Probleme”. Um diese “Problemidentifizierung” einzubeziehen, gibt es eine weitere “Init”-Phase, die einen neuen DQ Kreislauf auslöst:

    DQ_Cycle  Somit besteht der DQ Kreislauf aus folgenden Phasen

    • Init: Ein neues DQ Problem wird identifiziert.
    • Plan: Das Problem wird analysiert und eine Vorgehensweise zur Korrektur festgelegt.
    • Do: Die falschen Daten werden korrigiert.
    • Check: Es wird geprüft, ob das DQ Problem durch die Maßnahmen auch tatsächlich gelöst ist
    • Act: Es werden präventive Maßnahmen erarbeitet und umgesetzt, um ein neues Auftreten des Problems zu verhindern.

    Details zu den einzelnen Phasen werden in folgenden Beiträgen diskutiert.

    5 Aspekte beim Aufbau einer Datenqualitäts-Feuerwehr

    March 15, 2010 by · 1 Comment
    Filed under: Deutsch 

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

    In einem meiner letzten Beiträge benutzte ich das Bild von Feuerbrünsten im Mittelalter und stellte Bezüge zum “DQM Mittelalter” her. Am Beispiel einer Feuerwehr betrachte ich einige Elemente, um sich aus dem Mittelalter in die Neuzeit zu bewegen.

    Photo by Infidelic

    Im folgenden werden fünf wichtige Elemente dargestellt, die Sie beim Aufbau einer “Datenqualitäts-Feuerwehr” berücksichtigen sollten.

    Feuerwehrmänner

    Natürlich gibt es keine Feuerwehr ohne Feuerwehrleute, deren wichtigste Aufgabe das Löschen von Feuern ist und die die dafür erforderlichen Kenntnisse und Fähigkeiten besitzen.

    Bezogen auf Datenqualität bedeutet dies, dass es jemanden gibt, der sich bei Datenqualitäts-Bränden um das Löschen kümmert. Dies beutet nicht, dass dies die einzige Aufgabe dieser Person sein muss – in jedem Dorf gibt es “Freiwillige Feuerwehren”, nur größere Städte (=Unternehmen) können sich eine Berufs-Feuerwehr (= eine DQ Abteilung) leisten.

    Feueralarm

    Wenn jemand einen Brand sieht, schreit er “Feuer”, ruft bei Feuerwehr über “112” an oder nutzt einen mechanischen Brandmelder. Übertragen auf Datenqualität bedeutet dies, dass es eine Möglichkeit zur Alarmierung der DQ Feuerwehr geben muss. Im einfachsten Fall ist dies eine E-Mail-Adresse, die dann aber meist Bestandteil eines Ticketing-Systems ist. (Es sei angemerkt, dass das Melden eines Problems so einfach wie möglich sein sollte, auch wenn für die Verfolgung eines Problems ein komplexeres System genutzt wird.)

    Im Mittelalter gab es in den Städten oft einen Nachtwächter, der auch nach Bränden Ausschau gehalten hat. Bezogen auf DQ bedeutet dies, dass die DQ Abteilung auch selbst nach Problemen suchen sollte. Nach meiner Erfahrung sollte jedoch der Schwerpunkt auf der Lösung von Problemen gelegt werden (siehe “Brandbekämpfung” weiter unten), insbesondere zu Beginn einer DQ-Initiative.

    Ein letzter Punkt: Heute gibt es Geräte, die automatisch einen Feueralarm auslösen: Hoffentlich haben Sie bei sich zu Hause einen Rauchmelder installiert! Bei einer etablierten DQ Initiative sollte man also über automatische Messungen nachdenken, die bei Bedarf einen DQ Alarm auslösen.

    Brandbekämpfung

    Um ein Feuer zu löschen,  wird ein Feuerwehrmann etablierte Verfahren anwenden. Wenn Sie sich den Wikipedia-Artikel über Brandbekämpfung ansehen, so gibt es eine Menge von wichtigen Fragestellungen und je nach Art des Feuers unterschiedliche Vorgehensweisen. Es steckt eine Menge mehr dahinter, als ein wenig Wasser auf ein Feuer zu werfen!

    Auch die Bearbeitung von DQ Problemen erfordert eine einheitliche Vorgehensweise. Wie üblich bei Qualitätsthemen orientiert sich diese Vorgehensweise am Deming-Kreis (auch als “Plan – Do – Check – Act” bekannt). Dieses Thema möchte in einem folgenden Blogeintrag genauer behandeln.

    Feuerwehrautos

    Kinder sind fasziniert von Feuerwehrautos und Leiterwagen – das sichtbarste Beispiel für die Werkzeuge, die Feuerwehrleute zum Löschen von Bränden einsetzen.

    Auch das Datenqualitätsmanagement benötigt professionelle Werkzeuge zur Erfüllung der Aufgaben. Dies sind zum einen allgemeine Analysewerkzeuge (wie ein SQL-Abfrage-Tool oder “graphischere” BI-Werkzeuge), zum anderen spezielle DQ spezielle Werkzeuge (z. B. Profiling- oder Dubletten-Tools oder spezielle Werkzeuge für Adressqualität).

    Auch hierzu meine eigenen Erfahrungen: Die Anschaffung eines Werkzeugs (auch oder gerade, wenn es teuer ist) wird nicht wie von Zauberhand Ihre Datenqualitäts-Probleme lösen – schließlich gilt auch hier “a fool with a tool is still a fool”. Natürlich benötigt DQM Werkzeuge, aber eine DQM Initiative ist sehr viel mehr als ein Werkzeug-Auswahlverfahren. Es bedarf immer wieder langwieriger Diskussion, um andere Aspekte stärker in den Vordergrund zu holen.

    Vorbeugender Brandschutz

    Eine der größten Verbesserungen im Vergleich zum Mittelalter resultiert aus der Verhütung von Bränden. Dazu gehören der Wechsel von leicht brennbaren Baustoffen wie Holz zu feuerfesten Werkstoffen wie Stein und Stahl, das Entfernen von Brandherden wie offenen Feuerstellen und die Aufklärung der Menschen über das richtigen Verhalten mit Feuer.

    Nach dem Löschen eines DQ-Brands sollte daher die Frage diskutiert werden, wie das DQ Problem hätte verhindert werden können und daraus Schlussfolgerungen für andere Bereichen gezogen werden. Es ist nicht einfach, für solche vorbeugenden Maßnahmen Unterstützung zu erhalten – oftmals werden solche Maßnahmen als eine weitere, ungeliebte Pflichtaufgabe gesehen. Es erfordert gutes “Verkaufsgeschick” aus dem DQ-Team – dabei ist hilfreich, wenn man in vorangegangenen Problemlösungs-Maßnahmen Goodwill aufbauen konnte.

    Welche anderen Aspekte sind Ihrer Ansicht nach beim Aufbau einer DQ Initiative wichtig? Zu welchen Bereichen möchten Sie in Zukunft weiterführende Beiträge lesen? Ich freue mich über Ihr Feedback in den Kommentaren.Danke im Voraus!

    Putzige Sachen: Datum im Neuner-Komplement

    March 5, 2010 by · 1 Comment
    Filed under: Deutsch 

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

     
    Forto von Picture Taker 2, flickr.com

    Dies ist ein Eintrag, aus dem hoffentlich eine ganze Serie von putzigen Sachen wird, die mir so über den Weg laufen: Seltsame Formate, Verschlüsselungen oder Datenmodellierungs-Entscheidungen.

    Dieser Eintrag beschreibt ein Datumsformat, das wir als ‘Neuner-Komplement’ bezeichnen. Ich konnte dazu nichts bei Wikipedia finden, und Google lieferte nur einen Verweis auf eine obskure IBM-Dokumentation.

    Beobachtung

    In einer SAP Maske gab es ein Datumsfeld “Gültig Bis”. Hier kann man ein Datum eingeben, bis zu dem eine Information gültig ist (z.B. bis ‘31.12.2006’). In der Datenbank konnten wir schnell eine ‘VALIDTO’ Spalte finden, dort standen aber seltsame Werte wie ‘79938768 ‘, die nicht wie ein Datum aussahen. Die Spalte war als CHAR(8) definiert, was nicht ungewöhnlich für Datums-Felder ist: Speichert man das Datum im Format ‘YYYYMMDD’, so kann man mit einer normalen numerischen Sortierung auch die entsprechenden Daten (Datümer 😉 ?) sortieren. In diesem Fall wäre das obige Beispiel-Datum als ‘20061231’ abgelegt.

    Es hat eine Weile gedauert, bis wir hinter die seltsamen Werte in der Datenbank kamen: Man muss dann YYYYMMDD von 99999999 abziehen. Hier ist die vollständige Ableitung:

    Datum 31.12.2006
    im Format YYYYMMDD 20061231
       
    8 Neunen 99999999
    minus formatiertes Datum 20061231
    Datum im Neuner-Komplement 79938768

    Wenn man die Werte in der Datenbank wieder in das richtige Format konvertieren will, kann man die gleichen Schritte in umgekehrter Reihenfolge durchführen (d.h. wenn man den Wert von 8 Neunen abzieht, erhält man ein Datum im  YYYYDDMM-Format).

    Und wozu ist das gut?

    Auf Nachfragen wurde folgende Erklärung für dieses Format geliefert: Das neuste Datum steht so an erster Stelle, so dass man damit eine absteigende Sortierreihenfolge simulieren kann, wenn diese nicht direkt unterstützt wird, etwa bei der Definition von Indices.

    Dies könnte durchaus sein, schließlich ist dieses Format im SAP Kontext aufgefallen und SAP hat eine komplexe Abstaktionsschicht über die verschiedenen Datenbanksysteme gelegt. Ich hege immer noch die Vermutung, dass die SAP eine datenbankunabhängige Indizierung der Datenbank implementiert hat, auch wenn heute SAP-Indices in der Regel direkt auf der Datenbank umgesetzt werden.

    Mir ist aber nicht klar, wozu die Definition einer absteigender Reihenfolge in einen Index wichtig sein soll. Ich habe eine Frage auf StackOverflow dazu gestellt, und die Antworten darauf schildern ziemlich obskure Situationen. Solange Sachen wie Cluster-Tabellen keine Rollen spielten, sollte die Reihenfolge eines Index nicht wichtig sein. Egal ob man eine Sortierung mit ORDER BY, eine Suche nach einem Wert mit binäre Suche oder dem Durchwandern eines B-Baum vornimmt, sollte die Sortierreihenfolge keinen wesentlichen Einfluss auf die Leistung haben.

    Es wäre sehr interessant, die Performance einer "normalen" Ablage als Datum und eines aufsteigenden Indexes auszuprobieren. Ich bin mir ziemlich sicher, dass man heutzutage keine großen Unterschiede feststellen kann. Vermutlich gibt es für dieses Format also nur Gründe, die heute nicht mehr zutreffen. Wahrscheinlich stammt das Format werden von einigen "alte COBOL-Mainframe-Programmierern" aus den Tagen, als man nur sequentiellen Zugriff auf eine Band-Datei zur Verfügung hatte …

    Feuersbrünste und DQM

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

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

    Wenn man sich mit dem Mittelalter beschäftigt, stößt man immer wieder auf riesige Brände, die ganze Städte vernichten. Ein Beispiel ist der “Große Brand von London”, eine Feuersbrunst, die vom 2. bis 5. September 1666 vier Fünftel der City of London, darunter die meisten mittelalterlichen Bauten, zerstörte und etwa 100.000 Einwohner obdachlos machte.


    Quelle: Wikipedia, Great Fire London

    Heute gibt es zahlreiche Vorschriften zum Brandschutz, so dass Feuer viel seltener als früher auftreten. Und im Fall eines Falles hat jede Stadt und jedes Dorf eine Berufs- oder freiwillige Feuerwehr, die im Notfall schnell eingreifen und weitreichende Schäden verhindern kann.

    Diese Erkenntnis lässt sich auch auf das Datenqualitätsmanagement übertragen.

    DQM Mittelalter

    Immer wieder treten Probleme auf, die aus einer schlechten Datenqualität resultieren. Meist kommen diese Probleme bei wichtigen Projekten ans Tageslicht (z.B. bei Migrationen oder Prozessoptimierungen), bei Personalveränderungen oder bei Themen mit einer hohen Sichtbarkeit bei der Unternehmensführung. Um die Projektziele zu erreichen, muss sich dann um die DQ-Probleme gekümmert werden. Nachdem die unmittelbaren, drängenden Probleme gelöst und die naheliegenden Ziele erreicht sind, wird dann keine Notwendigkeit gesehen, ein regelmäßiges DQM einzuführen. Bis dann der nächste DQ-Notfalleinsatz ansteht …

    Bei diesem “Ad-Hoc DQM” gibt es viele Probleme, einige Beispiele:

    • Bearbeitung von DQ-Themen durch verschiedene Abteilungen im Unternehmen
    • Kein einheitliches Vorgehen, keine einheitlichen Werkzeuge
    • Investitionen in DQ-Werkzeuge rechnen sich meist nicht für eine einzelne Maßnahme oder sind zu zeitaufwändig, können aber bei mehrfachem Einsatz sehr nützlich sein
    • Keine Planbarkeit von Budgets und Ressourcen, deswegen oft externe Unterstützung erforderlich
    • Nur die wichtigsten Symptome werden beseitigt, ohne die Ursachen auszuräumen
    • Keine präventiven Maßnahmen
    • Bei jedem Probleme wird “wieder von vorne angefangen”, dadurch hohe wiederkehrende Kosten

    Modernes DQM

    Es macht daher sehr viel Sinn, eine Einheit zu etablieren, die als primäre Aufgabe ein regelmäßiges, aktives Datenqualitätsmanagement durchführt. Zu den Aufgaben dieser Einheit ist die Festlegung von einheitliches Prozessen und die Etablierung einer technischen Plattform, um auf dieser Basis eine kontinuierliche Überwachung und Verbesserung der Datenqualität zu erreichen. Die zahlreichen dabei auftretenden Aspekte werden in folgenden Posts weiter diskutiert werden.

    DQM und Migrationen

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

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

    Bei Migrationen werden oft ehrgeizige Ziele zur Verbesserung der Datenqualität verfolgt. Im Projektalltag bleibt davon meist nicht viel nach und nach der Migration hat man sich dann nicht nur mit dem alten Datenschrott herumzuschlagen, sondern in durch die Migration sind noch neue Probleme hinzugekommen. Das muss aber nicht sein: Mit einer expliziten Begleitung der Migration durch DQM kann die Datenqualität tatsächlich verbessert werden – zur Entlastung des Migrations-Projekts und zum Nutzen des Unternehmens.

    Verschlimmerung der DQ-Probleme bei Migrationen

    Ein typischer Anknüpfungspunkt für Maßnahmen zur Verbesserung der Datenqualität sind Migrationen von einem alten System zu einem neuen, etwa von einem selbst-entwickeltem, Host-basiertem System zu einer Standardsoftware wie SAP R/3. Beim Start eines solchen Projekts gibt es meist ehrgeizige Ziele:

    • Man will (endlich!) den alten Datenschrott loswerden,
    • in das neue System kommen nur saubere Daten,
    • auf der neuen, guten Grundlage wird das Entstehen neuen Datenschrotts durch umfangreiche Maßnahmen verhindert.

    Die Realität sieht dann leider meist anders aus: Unter dem zunehmenden Druck, einen Migrations-Termin zu halten, bleibt am Ende nur noch “Augen zu” und die Daten werden “so gut es halt geht” in das neue System “reingedrückt”. Wenn man Pech hat, produziert man damit “das Schlechteste aus beiden Welten”: Der alte Datenschrott wurde doch übernommen, durch die Migration sind neue Probleme entstanden und im neuen System ist man erst mal damit beschäftigt, den Betrieb am laufen zu halten, anstatt sich über Qualitäts-Maßnahmen Gedanken zu machen.

    In den folgenden Abschnitten werden Ideen vorgestellt, wie diese Verschlimmerung verhindert werden kann und durch eine Zusammenarbeit von Migrations-Projekt und DQM tatsächlich sogar eine Verbesserung der Datenqualität erreicht werden kann – zum Vorteil beider Parteien.

    DQM vor Migration

    Bereits vor der tatsächlichen Migration kann DQM wichtige Aufgaben zur Unterstützung des Migrations-Projekts und zur Vorbereitung der Zeit nach der Migration:

    • DQ-Problemaufnahme
      Bereits bekannte oder im Laufe der Migration aufkommende oder festgestellte Datenqualitäts-Probleme (z.B. Datensätze, die nicht oder nur unvollständig migriert werden können; Warnungen beim Import in das neue System) werden aufgenommen.
    • Priorisierung der DQ-Probleme
      In einem zweiten Schritt werden die gesammelten Probleme priorisiert, um zwischen wichtigen Problemen zu unterscheiden, die vor der Migration bearbeitet werden müssen und solchen, die etwas weniger dringlich sind.
    • Bearbeitung der wichtigsten DQ-Probleme
      Mit zunehmenden Projektdruck wird man sich in der Bearbeitung auf die Probleme konzentrieren, die Migrations-verhindernd sind und diese im Rahmen dezidierter DQ-Maßnahmen nach dem Standard-DQ-Vorgehen (DQM Kreislauf) bearbeiten.
    • Verfolgung der DQ-Probleme
      Mit Hilfe eines DQM Cockpits, das im Migrations-Projekt implementiert oder durch neue Messgrößen erweitert wird, kann die Entwicklung der DQ-Probleme verfolgt werden. Somit kann sichergestellt werden, dass die Bearbeitung der Probleme Fortschritte macht, bereits bearbeitete Probleme nicht erneut aufflammen und die Anzahl der Problemfälle insgesamt in ein für die Migration akzeptables Maß gebracht werden kann.
    • Erarbeitung von Maßnahmen im neuen System zur Prävention neuer DQ-Probleme
      Beim Entwurf des neuen Systems können DQ-Aspekte durch DQM mit eingebracht werden oder präventive Maßnahmen umgesetzt werden. Wenn es im alten System z.B. regelmäßig Probleme mit falschen Postleitzahlen gegeben hat, kann eine Funktion zur postalischen Prüfung integriert werden.

    Am Anfang der Zusammenarbeit gibt es oft Vorbehalte durch das Projekt, das in DQM eine weitere “Problemquelle” sieht. Sobald es aber DQM gelingt, das Projekt bei der Abarbeitung von Probleme zu entlasten, kann DQM schnell eine das Projekt unterstützende Funktion wahr nehmen, aus der beide Seiten Nutzen ziehen.

    DQM während Migration

    Bei einer Migration treten immer Probleme auf. Dabei kann es sich um Probleme handeln, die im Vorwege schon bekannt waren, aber nicht als Migrations-verhindernd eingestuft worden. Nicht immer lässt sich das Migrations-Szenario im Vorwege zu 100% durchspielen, so dass auch neue, unerwartete Probleme auftreten. Nur in ganz extremen Fällen führen diese Probleme zum Abbruch der Migration, im Normalfall müssen sie im Nachgang beseitigt werden. Auch hier kann DQM bei der Problemaufnahme, -Priorisierung und -Verfolgung unterstützen.

    Eine weitere Möglichkeit zur Unterstützung des Projekts durch DQM kann darin bestehen, DQM-Werkzeuge (wie eine dezidierte Analyse-Umgebung) zum Abgleich der Daten vor und nach der Migration zu nutzen und so bei der Abnahme der Migration beizutragen.

    DQM nach Migration

    Das Migrations-Projekt endet meist recht schnell nach der Migration, und viele Ressourcen stehen kurzfristig nicht mehr zur Verfügung. Es ist daher sehr wichtig, dass die Arbeit von DQM nach der Migration nicht beendet ist:

    • Bearbeitung noch offener DQ-Probleme
      Sowohl die vor der Migration schon bekannten, aber zurückgestellten Probleme als auch die neuen, in der Migration entstandenen Probleme sind zu bearbeiten. Auch hier kann wieder auf das Standard-DQ-Vorgehen zurück gegriffen werden.
    • Laufende Verfolgung aller DQ-Probleme
      Das bestehende DQM Cockpit ist – soweit sinnvoll -  auf das neue System anzupassen und entsprechend der neuen Probleme zu erweitern. Damit ist es möglich, eine laufende Verfolgung des Bearbeitungsfortschritts aller Probleme und DQ-Messgrößen zu verfolgen. Oft resultieren daraus auch präventive Maßnahmen im neuen System.

    Auch hier ist das Projekt meist dankbar dafür, für bestimmte Problemfälle einen definierten Empfänger zu haben. (Dies darf natürlich nicht dazu führen, dass alle Probleme zu DQ-Problemen erklärt werden und DQM Aufgaben erhält, die nicht geleistet werden können.)

    In vielen Fällen ist die Nachverfolgung der Themen aus der Migration und die Bearbeitung neuer Probleme der Einstieg in ein dauerhaftes, nachhaltiges Datenqualitäts-Management.

    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.