Kein Modell repariert schlechte Daten

Die Mängel, die im Tagesgeschäft nie aufgefallen sind

Typisch sind Freitextfelder, die als Sammelbecken dienen, Platzhalterwerte wie 999 oder ein Datum weit in der Zukunft, gemischte Einheiten in derselben Spalte, also Stück neben Karton, und Adressen, die je nach Erfassungsjahr in einer oder in vier Spalten stehen. Nichts davon ist ein Fehler im Sinne des Vorsystems, alles davon verschiebt eine Auswertung.

Der zweite Block betrifft Zeit. Erfassungszeitpunkt und Ereigniszeitpunkt werden häufig im selben Feld geführt, Zeitzonen und Sommerzeit werden unterschiedlich behandelt, und Nachbuchungen tragen das Datum der Buchung statt das des Vorgangs. Für einen Monatsbericht spielt das keine Rolle, für ein Modell, das aus Reihenfolgen lernt, kippt damit die Grundlage.

Dubletten schließlich entstehen selten durch doppelte Eingabe, sondern durch mehrere führende Systeme. Derselbe Kunde existiert im Vertrieb, im Service und in der Abrechnung, mit drei Schreibweisen und ohne gemeinsamen Schlüssel. Jede Auswertung über Kundenverhalten zählt damit dieselbe Person mehrfach, und zwar systematisch bei den großen Kunden, weil die in mehr Systemen vorkommen.

Fehlende Historie ist der teuerste Mangel

Die meisten betrieblichen Systeme überschreiben. Ein Kundensegment, ein Lieferstatus, ein Risikokennzeichen steht im Satz und wird bei Änderung ersetzt. Damit lässt sich nachträglich nicht mehr rekonstruieren, welchen Stand ein Datensatz zu einem bestimmten Zeitpunkt hatte, und genau das braucht jedes Modell, das aus der Vergangenheit lernen soll.

Die Folge heißt Leakage und ist tückisch, weil sie sich als besonders gutes Ergebnis tarnt. Wenn das heutige Segment eines Kunden in eine Prognose über sein damaliges Verhalten einfließt, nutzt das Modell Wissen aus der Zukunft. Im Test sieht das hervorragend aus, im Betrieb bricht die Trefferquote ein, weil dieses Wissen zum Entscheidungszeitpunkt schlicht noch nicht existiert.

Der Ausweg ist unspektakulär: Änderungen mitschreiben, statt sie zu überschreiben, und Merkmale immer zum passenden Zeitschnitt zusammenführen. Wer das erst nach dem ersten Modell merkt, wartet auf neue Historie, und die entsteht nur so schnell, wie die Zeit vergeht.

Datenverträge machen Zuständigkeit verbindlich

Ein Datenvertrag ist eine schriftliche Zusage der liefernden Seite an die nutzende: welche Felder es gibt, was sie bedeuten, welche Pflichtfelder gefüllt sind, welche Wertebereiche gelten, wie oft geliefert wird und wie lange vorher eine Änderung angekündigt wird. Das Entscheidende ist der letzte Punkt, denn stille Schemaänderungen sind die häufigste Ursache dafür, dass eine funktionierende Strecke ohne erkennbaren Anlass falsche Ergebnisse liefert.

Der Vertrag lohnt sich erst, wenn er maschinell geprüft wird. Beim Laden wird gegen die zugesagte Struktur getestet, und was abweicht, geht in Quarantäne statt still in die Zielstruktur. Eine Abweichung wird damit zum Vorgang mit Adressat, und nicht zu einer Zeile in einem Protokoll, das niemand liest.

Prüfregeln gehören in die Strecke

Fünf Regelarten decken den größten Teil ab: Vollständigkeit der Pflichtfelder, Eindeutigkeit der Schlüssel, zulässiger Wertebereich, Aktualität der Lieferung und Referenzintegrität gegen die Stammdaten. Dazu kommt eine Verteilungsprüfung, die anschlägt, wenn sich Mittelwert, Anteil leerer Felder oder die Zahl unterschiedlicher Ausprägungen einer Spalte deutlich verschiebt.

Wichtig ist die Reaktion. Fehlerhafte Sätze werden weder verworfen noch stillschweigend korrigiert, sondern in einen Quarantänebereich geschrieben, aus dem die verantwortliche Fachseite sie einsehen kann. Erst dadurch wird sichtbar, wie viel jeden Tag hinten herunterfällt, und erst diese Zahl bewegt jemanden dazu, die Ursache im Vorsystem zu beheben.