Die Kraftstoffkosten pro Meile an einem Distributionsstandort, Elm Yard, stiegen über zwei Monate hinweg um 9 %. Die Telematikplattform, die dieselben Lkw im selben Zeitraum erfasste, zeigte keine Veränderung bei der Fahrleistung, keine neuen Routen und keine Veränderung der Leerlaufzeit. Keine der beiden Zahlen war falsch.
Diese Kombination ist der Fehlermodus, um den es in diesem Artikel geht: keine beschädigten Daten, sondern zwei Systeme, die jeweils aus ihrer eigenen verlässlichen Datenquelle heraus korrekte Daten liefern und nie darauf ausgelegt waren, miteinander zu harmonieren. Die Tankkarten-Plattform erfasst, was über die Karte eines Fahrers abgerechnet wurde. Die Telematik-Plattform erfasst, wo ein Lkw physisch unterwegs war. Beide haben ihre Aufgabe erfüllt, und die Diskrepanz lag im Raum dazwischen und nicht in einem der beiden Systeme.
Der Standardvergleich erfolgt von Aggregat zu Aggregat: die gesamten Kraftstoffausgaben dieses Monats gegenüber denen des Vormonats, die Gesamtkilometerleistung dieses Monats gegenüber der des Vormonats. Dieser Vergleich verbirgt genau die Art von Unstimmigkeit, um die es hier geht, weil er die einzelnen Transaktionen und Fahrten hinter den Gesamtwerten nie berücksichtigt. Zwei Aggregate können aus Gründen auseinanderdriften, die nichts mit der Datenqualität und alles mit Definitionen, Zeitplänen und Geschäftsregeln zu tun haben, die niemand an einer zentralen Stelle festgehalten hat.
Teams, die nur Gesamtsummen vergleichen, bemerken eine Diskrepanz erst Tage oder Wochen, nachdem sie begonnen hat, Kosten zu verursachen. Bis eine aggregierte Zahl fehlerhaft erscheint, läuft die zugrunde liegende Diskrepanz meist schon eine Weile unbemerkt mit. Genau das ist bei Elm Yard passiert.
Warum die Zahlen nicht übereinstimmen: die vier Mechanismen hinter systemübergreifenden Diskrepanzen
Systemübergreifende Diskrepanzen entstehen durch vier Mechanismen, und fast jeder Fall, der rätselhaft erscheint, lässt sich auf einen davon zurückführen: Timing- und Latenzverzögerungen, unterschiedliche Geschäftslogik zwischen Systemen, Schema- oder Kategorisierungsdrift und doppelte oder unvollständige Datensätze.
Timing- und Latenzverzögerungen sind am einfachsten zu erklären und am leichtesten falsch zu diagnostizieren. Der Tankkarten-Feed von Elm Yard verbuchte Transaktionen noch am selben Tag, an dem ein Fahrer die Karte durchzog. Der Telematik-Kilometer-Feed wurde über einen nächtlichen Batch aktualisiert. Ein Lkw, der am Montagabend betankt wurde, wies den passenden Kilometerstand erst nach dem Durchlauf des Batches am Dienstagmorgen auf – eine Verzögerung von einem Tag, die das Team zunächst als echte Diskrepanz interpretierte und der es eine ganze Woche lang nachging, bevor jemand die beiden Aktualisierungszeitpläne direkt verglich.
Eine abweichende Geschäftslogik ist unauffälliger und schwerer zu erkennen, da beide Systeme genau wie vorgesehen funktionieren können. Die Rollup-Abfrage für Kraftstoffausgaben filterte strikt nach den Merchant Category Codes 5541 und 5542, den beiden mit „Kraftstoff“ gekennzeichneten Codes. Als der Autohof in der Nähe von Elm Yard eine Kaffeebar eröffnete, stufte das Kartennetzwerk den Händler unter MCC 5499, „Convenience Store“, neu ein. Die Kraftstofftransaktionen flossen weiterhin genau wie zuvor in den Rohdaten-Feed ein; sie fielen lediglich aus dem „Kraftstoffkosten“-Bucket heraus, den die Abfrage des Finanzteams erfassen sollte, da eine in einer Abfrage verborgene Regel nicht mehr mit einer Regel übereinstimmte, die das Kartennetzwerk stillschweigend geändert hatte.
Schema- und Kategorisierungsabweichungen treten auch an weniger offensichtlichen Stellen auf. Derselbe Mechanismus – eine Definition verschiebt sich, ohne dass jemand beschlossen hat, sie zu verschieben – kann über Nacht dazu führen, dass eine verschobene Geofence-Grenze in einem Dispositionssystem als „außerhalb des Standorts“-Verweilzeit-Flag gekennzeichnet wird. Die Dispositionsplattform ist nicht ausgefallen. Die Definition, wo das Betriebsgelände endet, verschob sich um einige Fuß, und alles Nachgelagerte übernahm diese Verschiebung.
Doppelte oder unvollständige Datensätze runden die Liste ab, und sie verhalten sich anders als die anderen drei, da zwei Datensätze existieren und keiner von beiden technisch falsch ist. Einige Fahrer von Elm Yard erfassen den Kilometerstand immer noch manuell auf Papier, anstatt sich auf die Telematikeinheit zu verlassen. Diese manuellen Einträge liegen nahe an den Telematikwerten für dieselbe Fahrt, sind jedoch selten exakt und weichen um ein paar Zehntelmeilen oder eine gerundete Startzeit ab. Das Löschen des Datensatzes, der „überzählig“ aussieht, verwirft Informationen; ein Quasi-Duplikat erfordert eine andere Lösung als ein echtes Duplikat.
Verfolgt man eines dieser vier weit genug zurück, laufen sie auf dieselbe Ursache hinaus. Oberflächlich betrachtet sieht jeder dieser Fälle wie ein Problem mit der Datenqualität aus. Im Grunde handelt es sich um eine Definition, einen Zeitplan oder eine Geschäftsregel, die in einem System geändert wurde und im anderen nicht, ohne dass jemand darauf achtet, dass beide voneinander abweichen.
Denken Sie einen Moment darüber nach: Welche dieser vier Möglichkeiten ist höchstwahrscheinlich bereits unentdeckt in den Systemen aktiv, die Ihr eigenes Team jeden Monat abgleicht?
Was eine unentdeckte Diskrepanz kostet, bevor sie jemand als Datenproblem bezeichnet
Das Team von Elm Yard verbrachte sechs Wochen damit, ein Datenartefakt als operativen Trend zu betrachten, bevor überhaupt jemand die Vergleichsmethode selbst hinterfragte. In diesem sechswöchigen Zeitfenster sind die tatsächlichen Kosten entstanden – nicht durch den Wert von 9 % selbst, sondern durch jede Entscheidung, die getroffen wurde, während das Team den Wert für real hielt.
Die Wartungsabteilung zog zwei Fahrzeuge zur Überprüfung ein, nachdem beide in diesem Zeitraum als „hoher Kraftstoffverbrauch“ gekennzeichnet worden waren. Die Mechaniker fanden an keinem der beiden Lkw einen Fehler. Die Kennzeichnungen waren auf eine Phantom-Differenz von 9 % zwischen zwei Systemen zurückzuführen und nicht auf Vorgänge in den Lkw, und die Werkstatt verlor Stunden mit der Diagnose von Geräten, die nie das Problem waren.
Die Anomalie stieg in der Hierarchie so weit nach oben, dass die Führungsebene begann, Argumente für eine Nachverhandlung des Vertrags mit dem Tankkartenanbieter auszuarbeiten – basierend auf einem Kostentrend, der gar nicht existierte. Eine Verhandlung mit einem Anbieter, die auf einem Datenartefakt beruht, lässt sich nur mit hohen Kosten rückgängig machen, sobald sie erst einmal in Gang gesetzt wurde – und diese wäre beinahe über einen Entwurf hinausgegangen.
Dies ist kein Problem, das auf ein einzelnes Flottenteam beschränkt ist. Gartner schätzt die durchschnittlichen jährlichen Kosten schlechter Datenqualität für Unternehmen auf Millionenhöhe, und Untersuchungen von Forrester zu diesem Thema haben ergeben, dass ein bedeutender Anteil der Datenexperten Verluste von 25 Millionen US-Dollar oder mehr meldet, die auf dieselbe Ursache zurückzuführen sind: Daten, die nutzbar aussahen und nie mit den Systemen abgeglichen wurden, mit denen sie übereinstimmen sollten.
Die am wenigsten sichtbaren Kosten überdauern den Vorfall selbst. Sobald sich ein Routing- oder Finanzteam an einem falschen Trend die Finger verbrannt hat, beginnt es, auch echte Signale aus denselben Systemen abzutun. Eine berechtigte Anomalie sechs Monate später wird mit einem Achselzucken statt einer Untersuchung abgetan, weil sich die letzte als gegenstandslos herausgestellt hat – und dieser Vertrauensverlust ist schwerer zu reparieren, als die ursprüngliche Diskrepanz zu finden war.
Hier gibt es auch einen Aspekt des Audit-Risikos – einen, der für Analytics-Führungskräfte wichtiger ist als für das Team vor Ort. Eine Diskrepanz dieser Größenordnung blieb sechs Wochen lang unentdeckt, beeinflusste eine Wartungsentscheidung und erreichte beinahe einen Anbietervertrag. Das ist eine Lücke in der Nachvollziehbarkeit, nach der sich ein Prüfer irgendwann erkundigen wird – nicht, weil jemand etwas falsch gemacht hat, sondern weil niemand aufzeigen konnte, wann die beiden Systeme begannen voneinander abzuweichen, oder warum es sechs Wochen dauerte, bis dies bemerkt wurde. Sechs Wochen sind eine lange Zeit, in der ein Phantom-Trend unangefochten bleibt, und genau deshalb beginnt der nächste Abschnitt mit dem Design und nicht mit Tools.
Was ein resilientes Erkennungsdesign anders macht
Ein robustes Erkennungsdesign vergleicht einzelne Datensätze zwischen zwei Systemen und gibt aus, was übereinstimmte, was nicht und warum. Es beschränkt sich nie auf den Vergleich zweier aggregierter Summen, denn genau in den Summen verbarg sich die Elm-Yard-Diskrepanz sechs Wochen lang.
Der Leitfaden zum Source-to-Target Mapping von Alteryx geht direkt auf diese Art von System-zu-System-Diskrepanzen ein: wie Felder zwischen verschiedenen Systemen verschoben, transformiert und manchmal unbemerkt verworfen werden. Es ist lesenswert, unabhängig davon, welche Tools ein Team letztendlich zur Behebung des darin beschriebenen Problems verwendet.
Teams, die bereits versuchen, Daten über ERP-, Lager- und Flottensysteme hinweg in einer vergleichbaren Ansicht zu vereinheitlichen, finden möglicherweise auch die Ressourcen zur Lieferkettenanalyse von Alteryx als nützliche weiterführende Lektüre – nicht speziell als Lösung für den Fall Elm Yard, sondern als Kontext dazu, was die Vereinheitlichung dieser Art von Daten aus mehreren Systemen eigentlich beinhaltet.
Auf Elm Yard angewendet bedeutet ein Vergleich auf Datensatzebene, den Feed der Tankkartentransaktionen über die Fahrzeug-ID und ein Zeitstempelfenster mit dem Telematik- und Dispositionsereignisprotokoll zu verknüpfen, anstatt die gesamten Treibstoffausgaben dieses Monats mit der Gesamtkilometerleistung dieses Monats zu vergleichen. Sobald dieser Join ausgeführt wird, werden die nicht übereinstimmenden Datensätze zum Gegenstand der Untersuchung anstelle der aggregierten Lücke. Ein Tool, das entwickelt wurde, um Datensätze quellenübergreifend zu vergleichen sowie Übereinstimmungen und Nicht-Übereinstimmungen zwischen Datasets zu identifizieren, liefert drei Ergebnisse: Datensätze, die übereinstimmten, Datensätze, die nur im Tankkarten-Feed vorhanden waren, und Datensätze, die nur im Telematik-Feed vorhanden waren. In dieser zweiten Kategorie – Tankkartentransaktionen ohne Telematik-Übereinstimmung – wären die per MCC neu klassifizierten Belastungen direkt an Tag eins aufgetaucht, anstatt erst sechs Wochen später als vager Trend.
Für die manuell geführten Kilometerprotokolle ist ein anderer Ansatz erforderlich, da sie in keinem der beiden Systeme fehlen. Sie stimmen einfach nie exakt überein. Der Abgleich von von Fahrern eingegebenen Kilometerständen mit Telematik-Datensätzen erfordert ein Tool, das nicht identische Duplikate über verschiedene Eingabedateien hinweg identifizieren kann und dabei einen konfigurierbaren Ähnlichkeitsschwellenwert statt einer Regel für exakte Übereinstimmungen verwendet. Das ist der Unterschied zwischen dem Erkennen von „diese beiden Datensätze beschreiben dieselbe Fahrt“ und der Forderung, dass „diese beiden Datensätze identisch sein müssen“, was die manuellen Protokolle nie sein werden.
Auch nicht jedes scheinbare Duplikat ist tatsächlich eines. Ein Tool, das dazu entwickelt wurde, eindeutige von doppelten Datensätzen zu trennen, ist hier hilfreich, doch seine eigene Dokumentation enthält einen ehrlichen Hinweis: Zwei Datensätze, die identisch aussehen – derselbe Name, ähnliche ungefähre Werte –, beschreiben möglicherweise nicht tatsächlich dasselbe. Das sollte zur Überprüfung durch eine Person gekennzeichnet werden, anstatt automatisch aufgelöst zu werden.
Die Profilierung der Felder jeder Quelle vor jeglichen Vergleichsläufen hätte das MCC-Problem frühzeitig statt erst nach sechs Wochen aufgedeckt. Die Profilierung auf Spaltenebene, die Nullwerte, eindeutige Werte, Wertebereiche sowie Min- und Max-Werte abdeckt, weist genau auf die Art von unbemerkter Änderung hin, die das Fuel-Spend-Rollup betroffen hat: Eine Wertemenge eines Felds verschiebt sich, ohne dass jemand eine Abfrage bearbeitet. Bevor irgendetwas davon verglichen wird, stellt das Standardisieren von Groß-/Kleinschreibung, Zeichensetzung und Codes über beide Feeds hinweg sicher, dass ein Formatierungsunterschied gar nicht erst mit einer echten Diskrepanz verwechselt wird.
Nichts davon läuft eigenständig. Jeder Baustein hier, die Verknüpfung, der Ähnlichkeitsabgleich, die Duplikatsprüfung, das Profil, ist etwas, das ein Team für seine eigenen beiden Systeme konfiguriert, und kein Feature, das eine Umgebung scannt und unbeaufsichtigt Rückmeldung erstattet. Das Designprinzip ist wichtiger als jedes einzelne Tool: vergleichen Sie Datensätze, nicht Gesamtsummen, und bauen Sie den Vergleich so auf, dass er kontinuierlich läuft, statt darauf zu warten, dass jemandem auffällt, dass eine Zahl nicht stimmt.
So rüsten Sie die Erkennung in bereits bestehende Systeme nach
Die Nachrüstungserkennung erfordert keinen Austausch des Tankkartensystems, der Telematikplattform oder der zugehörigen Dispositions- und Wartungssysteme. Dafür ist eine geplante Vergleichsebene zwischen ihnen erforderlich, die es zuvor nicht gab und die den Join automatisch ausführt, anstatt darauf zu warten, dass eine Person einmal im Monat die Summen stichprobenartig überprüft.
Die Systeme existieren bereits. Was fehlt, ist ein Workflow, der nach einem Zeitplan ausgeführt wird, nicht eine neue Datenquelle. Die Erstellung dieses Workflows läuft auf drei Schritte hinaus.
Standardisieren Sie Händler- und Kategoriecodes sowie Zeitstempel in beiden Feeds, bevor Sie diese zuerst verknüpfen, damit eine Neuklassifizierung wie die MCC-Änderung den Vergleich nicht ein zweites Mal unbemerkt unbrauchbar machen kann. Führen Sie als Nächstes den Verknüpfungs- oder Fuzzy-Match-Vergleich nach einem Zeitplan aus, der daran gekoppelt ist, wie oft die zugrunde liegenden Daten tatsächlich aktualisiert werden – und zwar nächtlich passend zum Telematik-Batch-Zyklus, statt nach dem Rhythmus, den ein Audit-Kalender zufällig vorgibt. Leiten Sie nicht übereinstimmende Datensätze zuletzt an einen bestimmten, namentlich genannten Eigentümer zur Überprüfung weiter, anstatt sie in einem Export landen zu lassen, den niemand öffnet. Dieser dritte Schritt macht den Unterschied aus, ob eine Diskrepanz innerhalb von Tagen oder erst nach Wochen erkannt wird: Eine Datei mit nicht übereinstimmenden Datensätzen, der kein Name zugewiesen ist, verhält sich genauso wie der Export, den bei Elm Yard sechs Wochen lang niemand überprüft hat.
Mit dem Anwachsen der Datenmengen gewinnt das Argument an Gewicht, dieses System eher früher als später zu implementieren. Untersuchungen von McKinsey zur Nutzung von Unternehmensdaten und KI bis zum Jahr 2030 bestätigen diesen Trend: Angesichts der Zunahme von Datenvolumina und KI-gestützten Use Cases wird es immer wichtiger – und keineswegs weniger relevant –, nachzuverfolgen, wie sich Daten zwischen Systemen bewegen und wie sie definiert sind. Manuelle, Ad-hoc-Vergleiche lassen sich bei diesem Wachstum nicht sinnvoll skalieren. Eine geplante, automatisierte Vergleichsebene wird umso wertvoller, je stärker sowohl die Anzahl der Systeme als auch das durch sie fließende Datenvolumen ansteigen.
Eine sprachbasierte Unterstützung wie Ask Alteryx kann einem Team helfen, einen solchen Vergleichs-Workflow schneller zu erstellen oder zu konfigurieren. Dies gilt insbesondere für Data Analysts, die eine Verknüpfung nicht per Hand programmieren möchten. Man sollte diese Funktion eher als Hilfsmittel bei der Workflow-Erstellung betrachten als etwas, das Diskrepanzen eigenständig aufdeckt, denn diesen Schritt erledigt derzeit kein Tool automatisch. Sobald eine Diskrepanz auf eine Änderung des Workflows oder der Definition zurückgeführt wird, können filterbare Audit-Protokolle dabei helfen, aufzuzeigen, was wann geändert wurde – was für die Person, die sich für die sechswöchige Lücke rechtfertigen muss, von größerer Bedeutung ist als für die oder den Data Analyst, der die Verknüpfung ausführt.
Nichts davon ist die eine richtige Antwort. Teams, deren Vergleichslogik wirklich komplex ist, große Datenmengen umfasst oder bereits im Verantwortungsbereich des Data Engineering liegt, sind mit einer codebasierten Pipeline, etwa auf Basis von Python, dbt oder SQL, womöglich besser beraten als mit einem Low-Code-Vergleichs-Workflow. Entscheidend ist die Frage, wer aktuell für die Logik zuständig ist. Handelt es sich dabei um eine/n Data Analyst, die oder der die Aufgabe erledigt, wenn es ihre/seine Zeit erlaubt, so schließt ein automatisierter Workflow eine echte Lücke. Betreibt ein Data-Engineering-Team hingegen bereits eine eigene Pipeline, so ist diese wahrscheinlich der richtige Ort für den Vergleich und nicht ein zusätzliches Tool, das obendrauf gesetzt wird.
Beginnen Sie mit der Verknüpfung, die Sie noch nicht ausgeführt haben
Der schnellste Weg, um festzustellen, ob dieses Fehlerbild bereits in Ihren eigenen Systemen auftritt, ist die Durchführung eine einzigen Verknüpfung auf Datensatzebene zwischen zwei Systemen, die eigentlich übereinstimmen sollten, und die anschließende Analyse der Abweichungen. Keine vollständige Prüfung. Eine Verknüpfung, zwei Systeme, ein ehrlicher Blick auf die nicht übereinstimmende Ausgabe.
Alteryx One wurde speziell für solche systemübergreifenden Vergleichsaufgaben entwickelt: Zusammenführen, Abgleichen, Profilieren und Bereinigen von Daten – ganz ohne das Schreiben von individuellem Code. Dies ist besonders wichtig für Teams, in denen die Vergleichslogik in der Verantwortung der Data Analysts liegt und nicht im Backlog der Data Engineers.
Starten Sie eine kostenlose Testversion von Alteryx One und führen Sie den Vergleich mit Ihren eigenen zwei Systemen durch. Sollte es Diskrepanzen geben, bleiben diese nicht sechs Wochen lang unentdeckt.