The DQ Cycle – a Procedure for dealing with Data Quality issues

March 29, 2010 by · 2 Comments
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

In the past, I have outlined elements to take into account when starting a DQ initiative. This post describes how to deal with Data Quality issues.

Some Background

The Deming Cycle is an established iterative four-step problem-solving process typically used in business process improvement. It is also know as PDCA for its four phases:

  • Plan
    Establish the objectives and processes necessary to deliver expected results.
  • Do
    Implement the new processes, often on a small scale if possible.
  • Check
    Measure the new processes and compare the results against the expected results.
  • Act
    Analyze the differences to determine their cause. Each will be part of either one or more of the PDCA steps.

(Adapted from the wikipedia article on PDCA.)

Overview

The DQ Cycle is an adaption of this general framework to Data Quality. I’ve used this framework at a number of customers with good success. The general idea is pretty simple and easy to follow, but it is an excellent reminder to make sure you’ve crossed all the T’s and dotted all the I’s.

The DQ cycle has the same phases as the Deming cycle. It describes how to deal with a single DQ problem that has been identified. This means that there may be a number of DQ cycles going on at the same time, each cycle dealing with its problem, and each of these cycles may be at different points in the cycle.

As you may have noted, the description started with the term “DQ problem that has been identified”. In order to accommodate this “problem identification”, there is an additional “Init” phase that kicks off a new DQ cycle:

 DQ_Cycle

So we end up with these phases:

  • Init: A new DQ problem is identified
  • Plan: You analyze the problem and decide on a course of action
  • Do: The bad data is corrected
  • Check: You verify that the DQ problem is resolved
  • Act: You identify and implement measures to prevent the problem from re-occurring

These phases will be described in more detail in the following posts.

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 Elements of Building a Data Quality Fire Department

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

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

In one of my last posts, I painted a picture of the Data Quality Middle Ages and the resulting fire storms. This post explores the elements on how to move from the Middle Ages into modern times, using a Fire Department as a metaphor.

Photo by Infidelic

Here are 5 important elements that you should have in mind when building your Data Quality Fire Department.

Firemen

Of course, there is no fire department without any firemen. Foremost, a fireman’s job is to know how to do the firefighting and be trained to do it properly.

For data quality, that means that there has to be at least one person in the organization that is dealing with data quality fires on a regular basis. This doesn’t have to be that person’s only responsibility, as evidenced by the fact the smaller towns only have a voluntary fire department. Only larger towns (larger companies) can afford a large staff (department) of dedicated firemen (DQ professionals).

Fire Alarms

When someone sees a fire, he cries out “fire”, calls 911 or uses some kind of fire alarm system like a manual pull station. For data quality, this means that whoever sees a data quality problem must have some way of notifying the DQ professionals that there is an issue. This can be as simple as a mail-address, but can quickly grow into some form of issue tracking system. (It should be noted that the notification should be as simple as possible, even if for tracking purposes a more elaborate system is used.)

Fires may also be spotted by a dedicated person to look out for a fire like a night watchman. For data quality, this means that the DQ department should of course look for data quality issues on their own. In my experience however, the focus should be on solving problems (see “Firefighting” further down), especially at the start of a DQ initiative.

One more point: Today, there are automatic devices to detect fires. (BTW: You should have a smoke detector installed in your home!) For a more advanced DQ initiative, this means that there are some automatic DQ measurements taken that may also result into DQ Alarms to be raised.

Firefighting

In order to extinguish a fire, fireman follow a procedure. If you look at the Wikipedia article on firefighting, there are a lot of issues to take into account and different ways to attack a fire. It’s certainly not as simple as dumping some water in the vicinity of a fire!

For data quality, there has to be a procedure as well. As with a lot of quality processes, this is usually a DQ-specific adaption of the Deming cycle or “plan – do – check – act”. There is a lot to discuss here, and I will cover the “DQ Cycle” in a future blog post in more detail.

Fire Trucks

The thing that fascinates kids the most about fireman is the fire truck – an the most visible example of the tools that a fireman needs to do his job.

A DQ professional also needs some tools. There are some general purpose tools to analyze data (a SQL query tool,  more “clickable” tools like BI tools). There are also some DQ specific tools (for example, profiling tools, tools to find duplicates, tools focused on address quality).

Again, I would like to offer a word of caution: Buying a tool (especially if it is quite expensive) will not magically solve your data quality issues – after all, “a fool with a tool is still a fool”. Certainly, some tools are needed, but a DQ initiative is so much more than a tool selection process. I constantly have long discussions with clients in order to de-emphasize the tool aspect when starting a DQ initiative.

Fire Prevention

One of the biggest improvements compared to the Middle Ages comes from preventing fires and pre-planning in case a fire happens. This includes switching form easily flammable building materials like wood to fire-resistant materials such as steel or firewalls, minimizing ignition sources and educating people about the proper emergency behavior.

As after fires, DQ should try to determine how a DQ problem could have been prevented and apply that lesson in other areas. This is often tricky to sell, as other (yet unaffected) departments often look to data quality as just one more unloved requirement. It requires an excellent “sales pitch” from the DQ team, and it is always helpful to have built some goodwill by having solved earlier issues.

What other aspects do you think are important when building a DQ initiative? Which areas would you like to see highlighted in future posts? Let me know in the comments! Thanks.

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!

Wild stuff: Nines complement date format

March 5, 2010 by · 7 Comments
Filed under: English 

For German readers: Es gibt eine deutsche Version dieses Blogeintrags.

 
Photo from Picture Taker 2 at flickr.com

This is the first in what I hope to be a series of some wild stuff I have to deal with: Strange formats, encodings and data modeling decisions that I or others come across. 

This post is about a date format that we are calling Nine’s complement. I couldn’t find anything about this on wikipedia, and googling I could only find some mention in an obscure IBM documentation.

What we found

Here’s what we found: In one of SAP’s screens you have a ‘valid to’ date field. You can enter some date until the business information was valid (like ‘31.12.2006’). When we looked for the corresponding field in the database, the column was easy to find (called VALIDTO), but it contained values like ‘79938768’ that surely didn’t look like a date. Also the column was defined as a CHAR(8) field. CHAR(8) is not unusual in itself for a date column, storing the date in a format like ‘YYYYMMDD’ so you can sort a date by sorting a number. In that way, ‘31.12.2006’ would be stored as ‘20061231’.

It took some asking around to figure out what was going on with the strange values we were seeing in the database. What you do is you take the YYYYMMDD-format and subtract that from 99999999. Here is the whole story:

Date 31.12.2006
as YYYYMMDD 20061231
   
8 Nines: 99999999
minus Date-String 20061231
Date in Nine’s Complement 79938768

 

In order to convert the values found in the database back into a proper date, you can perform the same operations in reverse (i.e. subtract the value from ‘8 Nines’, and you get a date in the YYYYDDMM-format).

But why?

The “official” reason behind this format is that you reverse the sorting order of the dates, so that the most recent date comes first. This way, you can simulate a descending sort order in a database that does not support this concept.

As we were working with an SAP system and SAP has built an abstraction layer on top of the underlying databases, that may well be the case here. Some of the code dates back to the early 1980s, and databases were quite different back then. Sometimes I think that they even built there own database independent indexing mechanism, although these days most indexes defined in SAP correspond to indexes on the database level.

However, it is still not clear to me why defining a descending sort order in an index is important . I’ve asked a question on StackOverflow about why you would defined a descending order in an index definition, and the answers pointed to reasonably obscure situations that do not apply to the situation we were seeing. Unless there is stuff like clustered tables involved, the ordering of an index shouldn’t be important, if you’re doing an order, a binary search or traversing a b-tree, the order would not have a material effect on performance.

It would be quite interesting to evaluate the performance impacts of a “normal” date storage and a regular ascending index. I’m quite confident that there will not be much of a difference. So I can only assume that if there was a reason in the past to do this, the reasoning no longer applies. However, my guess is that someone optimized something that didn’t need to be optimized. Probably some “old COBOL mainframe programmer” from back in the days when all you could do was sequential access to a file …

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 …