Datenqualifikation ist entscheidend
Wikipedia listet sieben Schritte für einen Datenanalyse Prozess: Datenanforderungen, Datensammlung, Datenverarbeitung, Datenbereinigung, explorative Datenanalyse, Datenmodellierung und schließlich die Erzeugung von Produktionsergebnissen. Wenn Lokad den Lagerbestand prognostiziert, Preise optimiert oder wann immer wir irgendeine Art von Handelsoptimierung angehen, ist unser Prozess dem oben beschriebenen sehr ähnlich. Allerdings gibt es einen weiteren wesentlichen Schritt, der typischerweise mehr als die Hälfte des gesamten Aufwands erfordert, der normalerweise vom Lokad-Team geleistet wird und der nicht einmal Teil der obigen Liste ist. Dieser Schritt ist die Datenqualifikation.
Nun, da „Big Data“ zu einem Schlagwort geworden ist, versuchen zahllose Unternehmen, mehr mit ihren Daten zu machen. Die Datenqualifikation ist wahrscheinlich die zweitgrößte Ursache für Projektfehlschläge, gleich nach unklaren oder unvernünftigen Geschäftszielen – was immer passiert, wenn eine Initiative von der „Lösung“ ausgeht, anstatt vom „Problem“ auszugehen. Lassen Sie uns etwas Licht auf diesen geheimnisvollen Schritt der „Datenqualifikation“ werfen.
Daten als Nebenprodukt von Geschäftsapplikationen
Der überwiegende Teil der Geschäftsoftware ist darauf ausgelegt, Unternehmen zu betreiben: Das Kassensystem soll den Kunden das Bezahlen ermöglichen; das Warehouse Management System dient dazu, Produkte zu kommissionieren und zu lagern; die Webkonferenz-Software ermöglicht es Menschen, ihre Meetings online abzuhalten, etc. Solche Software könnte auch Daten erzeugen, aber Daten sind nur ein sekundäres Nebenprodukt des primären Zwecks dieser Software.
Die genannten Systeme sind darauf ausgelegt, das Geschäft zu betreiben, und folglich wird, wenn eine Fachkraft zwischen besseren Abläufen oder besseren Daten wählen muss, immer der bessere Betrieb bevorzugt. Zum Beispiel: Wenn ein Barcode beim Scannen an der Kasse Ihres lokalen Hypermärkte ausfällt, wird der Kassierer stets ein Produkt wählen, das zufällig den gleichen Preis hat, und es zweimal scannen; manchmal haben sie sogar einen Spickzettel, auf dem alle Barcodes zusammengetragen sind. Der Kassierer hat recht: Die Nummer-1-Priorität besteht darin, dem Kunden unter allen Umständen das Bezahlen zu ermöglichen. Die Erstellung genauer Lagerbestandsaufzeichnungen ist kein unmittelbares Ziel im Vergleich zum dringenden Bedarf, eine Kundenreihe zu bedienen.
Man könnte argumentieren, dass das Problem beim Barcode-Scannen eigentlich ein Problem der Datenbereinigung ist. Die Situation ist jedoch recht subtil: Die Aufzeichnungen bleiben bis zu einem gewissen Grad korrekt, da der dem Kunden in Rechnung gestellte Betrag stimmt und ebenso die Anzahl der Artikel im Warenkorb. Das naive Herausfiltern aller verdächtigen Datensätze würde den meisten Analysen mehr schaden als nützen.
Dennoch stellen wir fest, dass Unternehmen – und auch ihre Softwareanbieter – viel zu oft dieses grundlegende Muster für nahezu alle generierten Geschäftsdaten begeistert ignorieren, indem sie direkt von der Datenverarbeitung zur Datenbereinigung springen.
Datenqualifikation bezieht sich auf die Semantik der Daten
Das Ziel des Schritts der Datenqualifikation ist es, die Semantik der Daten zu klären und gründlich zu dokumentieren. Meistens, wenn (große) Unternehmen Lokad tabellarische Datendateien senden, schicken sie uns auch eine Excel-Tabelle, in der jeder in den Dateien enthaltenen Spalte eine kurze Dokumentationszeile zugeordnet wird, typischerweise wie: Price: der Preis des Produkts. Allerdings lässt eine so knappe Dokumentationszeile eine Vielzahl von Fragen offen:
- Welche Währung gilt für das Produkt?
- Ist es ein Preis mit oder ohne Steuern?
- Gibt es eine andere Variable (wie einen Rabatt), die den tatsächlichen Preis beeinflusst?
- Ist es wirklich derselbe Preis für das Produkt in allen Kanälen?
- Soll der Preiswert auch für Produkte, die noch nicht verkauft wurden, sinnvoll sein?
- Gibt es Randfall-Situationen, wie Nullen, um fehlende Werte darzustellen?
Daten sind auch hervorragende Kandidaten für semantische Mehrdeutigkeiten, wenn eine orders-Tabelle eine date-Spalte enthält, da sich die Datums-/Zeitangabe auf den Zeitpunkt beziehen kann von:
- der Warenkorbüberprüfung
- der Zahlungserfassung
- der Zahlungsabwicklung
- der Erstellung der Bestellung im Buchhaltungssystem
- dem Versand
- der Lieferung
- dem Abschluss der Bestellung
Eine solche Kurzliste deckt jedoch kaum die tatsächlichen Besonderheiten ab, die in realen Situationen auftreten. Kürzlich, zum Beispiel, stellten wir während der Zusammenarbeit mit einem der größten europäischen Online-Unternehmen fest, dass die mit Bestellungen verknüpften Daten je nach Herkunftsland der Zuliefererfabriken nicht dieselbe Bedeutung hatten. Europäische Lieferanten versandten per LKW, und das Datum spiegelte die Ankunft im Lager wider; während asiatische Lieferanten – nun ja, per Schiff – lieferten und das Datum die Ankunft im Hafen widerspiegelte. Diese kleine Abweichung führte typischerweise zu einem Unterschied von mehr als 10 Tagen in der lead time-Berechnung.
Bei geschäftsbezogenen Datensätzen hängt die Semantik der Daten nahezu immer von den zugrunde liegenden Unternehmensprozessen und -praktiken ab. Dokumentationen, die sich auf solche Prozesse beziehen – wenn es sie überhaupt gibt – konzentrieren sich typischerweise auf das, was für das Management oder die Prüfer von Interesse ist, jedoch sehr selten auf die Vielzahl winziger Elemente, die in der IT-Landschaft des Unternehmens existieren. Aber der Teufel steckt im Detail.
Datenqualifikation ist nicht dasselbe wie Datenbereinigung
Datenbereinigung (oder -säuberung) macht in den experimentellen Wissenschaften am meisten Sinn, wo bestimmte Datenpunkte (Ausreißer) entfernt werden müssen, weil sie die Experimente fälschlicherweise „verbiegen“ würden. Zum Beispiel könnten Diagrammmessungen in einem optischen Experiment schlicht einen Defekt im optischen Sensor widerspiegeln, anstatt etwas, das tatsächlich für die Studie relevant ist.
Dieser Prozess spiegelt jedoch nicht wider, was typischerweise bei der Analyse von Geschäftsdaten benötigt wird. Ausreißer können bei der Verarbeitung der Überreste einer misslungenen Datenbankwiederherstellung auftreten, aber meist sind Ausreißer marginal. Die (geschäftsmäßige) Integrität der überwiegenden Mehrheit der derzeit in Produktion befindlichen Datenbanken ist ausgezeichnet. Fehlerhafte Einträge gibt es, aber die meisten modernen Systeme leisten gute Arbeit darin, die häufigsten Fehler zu verhindern und sind auch sehr unterstützend, wenn es darum geht, sie nachträglich zu beheben. Die Datenqualifikation unterscheidet sich jedoch wesentlich darin, dass das Ziel nicht darin besteht, Datenpunkte zu entfernen oder zu korrigieren, sondern vielmehr darin, die Daten als Ganzes zu beleuchten, sodass die nachfolgende Analyse wirklich Sinn ergibt. Das Einzige, was durch den Prozess der Datenqualifikation „verändert“ wird, ist die ursprüngliche Datendokumentation.
Die Datenqualifikation macht den Großteil des Aufwands aus
Bei der Arbeit an Dutzenden von datengesteuerten Projekten in den Bereichen Handel, Luft- und Raumfahrt, Gastgewerbe, Bioinformatik und Energie haben wir festgestellt, dass die Datenqualifikation stets der anspruchsvollste Schritt des Projekts war. Machine learning Algorithmen mögen anspruchsvoll erscheinen, aber solange die Initiative innerhalb der bekannten Grenzen von Regressions- oder Klassifikationsproblemen bleibt, ist der Erfolg im Machine Learning größtenteils eine Frage des vorangegangenen Fachwissens. Dasselbe gilt für die Big Data Verarbeitung.
Datenqualifikationsprobleme sind tückisch, weil man nicht weiß, was einem fehlt: Dies ist die semantische Lücke zwischen der „wahren“ Semantik, wie sie in Bezug auf die von den vorhandenen Systemen erzeugten Daten verstanden werden sollte, und der „tatsächlichen“ Semantik, wie sie von den Personen wahrgenommen wird, die die Datenanalyse durchführen. Was man nicht weiß, kann einem schaden. Manchmal macht die semantische Lücke die gesamte Analyse völlig ungültig.
Wir stellen fest, dass die meisten IT-Fachleute die Tiefe der Eigenheiten, die mit den meisten realen Geschäftsdaten einhergehen, bei Weitem unterschätzen. Die meisten Unternehmen verfügen nicht einmal über eine vollständige Dokumentationszeile pro Tabellenspalte. Dennoch stellen wir typischerweise fest, dass selbst bei einer halben Seite Dokumentation pro Feld die Dokumentation noch weit davon entfernt ist, gründlich zu sein.
Eine der (vielen) Herausforderungen, mit denen Lokad konfrontiert wird, ist, dass es schwierig ist, für etwas zu berechnen, das nicht einmal als Bedarf wahrgenommen wird. Deshalb schaufeln wir häufig die Arbeit der Datenqualifikation unter dem Deckmantel noblerer Aufgaben wie der „statistischen Algorithmusoptimierung“ oder ähnlicher wissenschaftlich klingender Aufgaben.
Die Realität der Arbeit besteht jedoch darin, dass die Datenqualifikation nicht nur arbeitsintensiv ist, sondern auch an sich eine wirklich herausfordernde Aufgabe darstellt. Sie ist eine Mischung aus dem Verständnis des Geschäfts, dem Verständnis dafür, wie Prozesse sich über viele Systeme erstrecken – von denen einige unweigerlich von der veralteten Art sind – und dem Überbrücken der Kluft zwischen den Daten, wie sie austreten, und den Erwartungen der Machine Learning Pipeline.
Die meisten Unternehmen investieren in der Tat viel zu wenig in die Datenqualifikation. Zusätzlich dazu, dass es sich um eine unterschätzte Herausforderung handelt, führt die Investition von Talenten in die Datenqualifikation nicht zu einer beeindruckenden Demo oder gar tatsächlichen Zahlen. Infolgedessen eilen Unternehmen zu den späteren Phasen des Datenanalyseprozesses, nur um sich schließlich in Melasse wiederzufinden, weil nichts so funktioniert, wie erwartet. Es gibt keine schnelle Lösung für ein tatsächliches Verständnis der Daten.
