Update!

Das Dilemma der Datenqualität

Zugegeben – Datenqualität ist irgendwie ähnlich spannend wie der Bau einer Bodenplatte bei einem Haus. Allerdings ist auch bei der Bodenplatte ein Nachbessern nur schwer möglich – wenn erstmal ein Haus drauf steht. Ähnlich ist es bei der Datenqualität von IT Systemen. Allerdings kommt bei letzterem  noch erschwerend hinzu, dass die IT-Systeme fortlaufende umgebaut werden.  Datenqualität ist daher in fast allen gewachsenen IT-Systemen ein großes Problem.

XX alles nachfolgende grundlegend überarbeiten XX

Viele Systeme werden über die zeit massiv umgebaut und erweitert. Dabei werden alte Datenbestände auch um zusätzliche Attribute erweitert. Eine Konsistenzprüfung kann aufgrund der unvollständigen alten Daten oftmals nicht eingeführt werden, da sonst veraltete Datenbestände vollständig nachgepflegt werden müssen.

Da die IT Verantwortlichen die schlechte Datenqualität als Fehler der Fachseite sehen und parallel in Umsetzungszeit und -kosten gedrückt werden, wird hier meist keine Arbeit investiert und die Daten – insbesondere bei größeren Systemen – sind einfach nicht zuverlässig gefüllt.

Die Lösung wird in der Praxis dann meist auf die nachgelagerten Systeme verschoben, die die unvollständigen Daten weiterverarbeiten müssen. Aber auch das kann teuer sein. Werden unzuverlässige Daten in mehreren Systemen weiterverarbeitet, muss in jedes der nachgelagerten Systeme eine Routine zum Fehlerhandling implementiert werden. Und bei weiteren Änderungen in den Quellsystemen sind oftmals weitere Änderungen in allen nachgelagerten Systemen erforderlich – statt die Ursache an der Wurzel zu beseitigen.

Im Ergebnis werden durch das pragmatischen Vorgehen und das Verantwortungsvakuum Wegs die Nachteile aus beiden Welten kombiniert: Die Stammdaten aus dem liefernden System sind falsch und die Schnittstelen der Syeteme sind fehleranfällig.

Dabei wird es oft bereits als Fortschritt gewertet, wenn man die unbrauchbaren Datensätze verwirft, worunter meist der wirtschaftliche Zweck leidet. Im einfachen Fall fehlen einige Datensätze bei Marketingmaßnahmen. Im schlimmsten Fall ist durch lückenhafte Reports kein klarer Blick mehr auf den aktuellen Stand mehr möglich. Auf dauert schafft man sich mit dem Quellsystem ein ‚untotes Monster‘, da sich keiner an einen Systemwechsel wagt, weil eine Datenübernahme in ein neues System mit unvorstellbaren Kosten verbunden ist. Konsolidierungsprojekte nach Fusionen scheitern.

Der Königsweg wäre, nur die relevanten Informationen nach und nach zu korrigieren. Die Korrektur soll dabei nach und nach erfolgen und nicht ‚en block‘. Auf diese Weise vermeidet man Belastungsspitzen in den Teams aber auch die unnötige Arbeit veralteter Daten zu korrigieren, die gar nicht mehr benötigt werden. Gleichzeitig sollen die Projekte die internen IT Abteilungen nach Möglichkeit nicht weiter belasten.

In der Praxis sind solche Produkte durchaus umsetzbar. Der Zugriff erfolgt dabei nach Möglichkeit über bestehende Schnittstellen, die z.B. Daten in Folgesysteme ausleiten. Im Anschluss werden diese Daten validiert. Die Evaluierungslogik kann dabei meist auf Basis der technischen Dokumentation unter Hinzuziehung der Fachabteilung bei sehr geringer Belastung der IT umgesetzt werden.

Fehlerhafte Datensätze werden dann je nach Fehlerart und Zuständigkeit an die richtige Fachabteilung zur Korrektur weitergeleitet. Nach einer bestimmten Zeit können die Daten erneut abgerufen und validiert werden. Nach der erfolgreichen Korrektur können die Daten in das Folgesystem wieder eingespeist werden.

Florian Müller-SchunkDas Dilemma der Datenqualität