Datenaufbereitung

Wenn wir bei Lokad ein probabilistisches Projekt im Bereich Lieferkette aufnehmen, setzen wir etwa 80% unserer Ressourcen auf die „Datenaufbereitung“, auch als „Datenbereinigung“ oder „Datenvorverarbeitung“ bekannt. Dennoch verstehen viele, sogar Fachkräfte, nicht die Notwendigkeit dieser Arbeit. Wie wir aber im Laufe der Jahren beobachten konnten, gehen Fehler bei der Optimierung von Lieferketten an erster Stelle auf Problemen in Bezug auf die Daten zurück. Dies geschieht in praktisch allen Branchen, von Frischkost zu Luft- und Raumfahrt. Während manche Fehler im Bereich Lieferkette Schlagzeilen schreiben, werden die meisten Fehler unter dem Teppich gekehrt. Dennoch ist es von großer Bedeutung, aus solchen Fehlern zu lernen, um diese nicht zu wiederholen.

Datenbasierte Fehler

Projekte zur Optimierung von Lieferketten scheitern häufig. Nach Erzählungen aus Lokads Kundenstamm, dürfte sich die Fehlerrate bei Initiativen zur softwareunterstützten Optimierung von Lieferketten in den meisten Branchen wahrscheinlich über 80% befinden. Einige Anbieter würden sogar zugeben, dass ein Misserfolg als „normales“ Ergebnis für Ihre Kunden gilt. Ein Paradoxon moderner Lieferketten ist, dass die physische Bewegung von Lagerbeständen zwischen Kontinenten weniger Risiken birgt, als die Bewegung von Lagerbestandsdaten zwischen Computern, die nur einen Meter weiter stehen.

Wenn hier etwas schief läuft, haben weder der Kunde, noch der Anbieter eine großen Anreiz, etwas offenzulegen. Daher wird die große Mehrheit von Fehlern diskret vergessen und es wird nie wieder darüber gesprochen. Ab und zu sind diese Fehler jedoch so beeindruckend, dass Sie in die Nachrichten gelangen:

• The last days of Target Canada with SAP
• The debacle of Nike with i2
• The FoxMeyer Drugs' Bankruptcy
• The Cisco 2001 inventory disaster
  

Obwohl diese Fehler keine eindeutige Erklärung haben, sind die getroffenen Entscheidungen bezüglich Lieferketten, jedes Mal, wenn etwas mit den Daten extrem schief läuft, äußerst schlecht.

Doch die meisten Fehler sind gewöhnlich nicht so erstaunend. Normalerweise behalten sich die Zuständigen für Lieferketten ein gesundes Misstrauen gegenüber den Zahlen des neuen, und theoretisch besseren, Anbietersystems vor. Sie verlassen sich auf Ihre Excel-Blätter und legen das System nach einigen Monaten still. Somit ist dem Unternehmen kein Schaden entstanden, doch es wurde Zeit und Energie verschwendet.

Die Interpretation von Daten ist schwer

Historische Unternehmensdaten sind äußerst anspruchsvoll und subtil. Diese Aspekte sind oft nicht sehr intuitive und werden daher nicht selten missverstanden. Unserer Erfahrung nach stammen alle Probleme mit Daten, die so oft in Lieferketteninitiativen auftreten, von eben diesem Missverständnis.

Lassen Sie uns dies am Beispiel einer Verkaufshistorie veranschaulichen: In einer Tabelle erscheint die Menge an Einheiten, die in den letzten Jahren verkauft wurden, pro Produkt und pro Tag. Diese Verkaufshistorie sollte Ihnen einen Einblick in die Richtung verschaffen, in die sich das Unternehmen bewegt.

Dies ist jedoch nicht der Fall, denn:

• Die Historie kann Pakete enthalten, wobei ein Produkt zu einem Paket anderer Produkte gehört, so dass eventuell die Zahlen sinken, obwohl das Unternehmen einen Aufwärtstrend erfährt.
• Die Historie enthält vielleicht Rückgaben, die einen Großteil des Umsatzes ausmachen könnten. So kann es sein, dass die Zahlen gut aussehen, obwohl das Geschäft einen Abwärtstrend erfährt, weil die Rücksendungen steigen.
• Möglicherweise enthält die Historie Aktionen, bei denen Margen geopfert wurden, um den Bestand zu liquidieren, so dass der erzeugte Bedarf für den Bedarf nach Ware zum Vollpreis nicht repräsentativ ist.
  

Beziehen wir uns dann auf die Menge pro Tag, stehen wir erneut vor den eigenen Mehrdeutigkeiten. Mit Tag kann der Zeitpunkt gemeint sein, an dem:

• der Kunde die Bestellung aufgegeben hat
• der Kunde eine Vorbestellung bestätigt hat
• das Produkt Versand wurde
• die Bestellung im ERP angekommen ist
• die Bestellung im ERP zuletzt geändert wurde
• die Zahlung vom Kunden erhalten wurde
• usw.
  

Alle Varianten sind richtig, doch jede von ihnen birgt Besonderheiten. Dennoch ist es oft genug verlocken zu denken, es handle sich ja um eine einfache gute alte Verkaufshistorie. Wenn historische Verkaufsdaten im Spiel sind, ist selten etwas einfach.

Außerdem werden diese Einzigartigkeiten exponentiell größer mit einer umfangreicheren Auswirkung, wenn sie kombiniert werden. Kaum etwas ist bei der Schaffung von Überbeständen schädlicher als eine Verzerrung in Form eines Aufwärtstrends, die den Umsatz aufbläst, im Zusammenhang mit einer Verzerrung in Form eines Abwärtstrends, die den eintreffenden Bestand kleiner erscheinen lässt.

Als Faustregel haben wir bei Lokad beobachtet, dass eine gute Dokumentierung der Daten oft mit einer Beschreibung auf einer knappen Seite pro Spalte je Tabelle einhergeht. Dennoch freuen wir uns schon, wenn uns bereits eine Zeile pro Spalte (pro Datenfeld) am Anfang eines Projekts zur Verfügung steht.

Doch oft verfehlt die Dokumentation, sofern es eine gibt, das Thema. Es ist außer Frage, dass ein Spalte namens OrderDate Datumsangaben beinhaltet. Klar ist auch, dass eine Spalte namens StatusCode eine kurze Codeliste enthält. Die meisten technischen Dokumentationen konzentrieren sich auf EDV-Aspekte und lassen dabei die Unternehmensprobleme außer Acht. Doch es sind genau diese Aspekte, die aus der Sicht der Perspektive besonders interessant sind.

In der Informatik gibt es den Spruch: Garbage In, Garbage Out. Das heißt, dass bei sinnlosen Eingabedaten die Ergebnisse auch keinen Sinn ergeben werden. Daher ist eines der Hauptziele, wenn Lokad an einer neuen Lieferkette arbeitet, die Date aufzuschlüsseln und die Erkenntnisse zu dokumentieren. Die meisten unserer Kunden sind von der Menge an Dokumentation, die Lokad bei der Überprüfung ihrer Systeme, Daten und Prozesse erstellt, überrascht. Doch unsere Erfahrung zeigt, dass es nie ein Fehler war, zu viel zu dokumentieren.

Keine zwei Setups sind genau gleich

Eine der häufigsten Fragen, die im Laufe eines quantitativen Logistikprojekts gestellt werden, ist: Ist die Optimierung mit System X kompatibel? Die kurze Antwort lautet fast immer ja, aber die längere Antwort wäre ja, aber mit etwas Aufwand. Daten zu verschieben ist ziemlich einfach. Schon seit Jahrzehnten besteht das FTP Datenübertragungsprotokoll und sogar mit einer bescheidenen Internetverbindung kann man ziemliche Datenmengen verschieben. Doch die eigentliche Herausforderung besteht darin, die verarbeiteten Daten komplett zu verstehen. Gerade hier ist es für Unternehmen nicht immer einfach zu stehen, wie flexibel IT-Systeme tatsächlich sind. Während Unternehmenssysteme für die Fachkräfte recht starr erscheinen, sind sie es eigentlich selten.

In der Tat stehen Softwareanbieter seit Jahrzehnten im Wettbewerb auf Flexibilität, weshalb Systeme, die Workflows auf nur eine Art zulassen, eher die Ausnahme sind. Die meisten Systeme bieten unzählige Möglichkeiten, dasselbe Ergebnisse zu erreichen. Folglich ist die Datenaufbereitung, auch wenn Daten aus derselben Quelle oder Software bezogen werden, selten gleich. In der Tat hängt die Datenaufbereitung stark von den Praktiken und Workflows des Unternehmens ab und so können Datensätze verschiedener Unternehmen nicht auf dieselbe Art und Weise gedeutet werden. Anfänglich können diese Unterschiede klein erscheinen, doch aus der Perspektive der Optimierung von Lieferketten, entsteht dadurch oft eine Kluft zwischen der Optimierungslogik und den tatsächlichen Bedürfnissen des Unternehmens.

Strategie ist gleich Daten

Die meisten Führungskräfte verlassen sich drauf, dass Ihr Team die Unternehmensstrategie umsetzt, auch wenn diese nicht formalisiert oder niedergeschrieben wurde. Doch die quantitative Optimierung räumt impliziten Zielen keinen Platz ein: Die aus Eingabedaten erstellten Zahlen stellen den aktuellen numerischen Rahmen dar. Folglich sind die anfänglichen Ergebnisse von quantitativen Optimierungslösung verblüffend: Zutreffend in vielen Aspekten, während sie gleichzeitig viele andere verfehlen.

Da die genauen Unternehmensziele selten vom Anfang an festgelegt werden, benötigt man oft die ersten Ergebnisse der quantitativen Optimierungslogik, um festzustellen, was fehlt. Es kann sein, dass:

• manche Kunden VIP sind und höhere Service Level benötigen
• manche Produkte der Obsoleszenz nahe sind und ein deutlich höheres Risiko für den Lagerbestand darstellen
• manche Lieferanten MOQs sowohl pro SKU, als auch für Bestellungen haben
• manche Lager fast voll sind und neue Bestellungen sich in Grenzen halten müssen
• usw.
  

Um solche Herausforderungen zu überwinden, sind zusätzliche Daten nötig, die, wie die Unternehmen dann verstehen, nirgends zu finden sind, außer evtl. auf verschiedenen Excel-Blätter verteilt im gesamten Unternehmen. Allzu oft wird Excel-Blättern zu wenig Bedeutung beigemessen und viele von Ihnen werden letzten Endes in E-Mail-Postfächern archiviert.

Folglich müssen nicht nur die Transaktionen, wie die aus dem ERP, vorbereitet werden, sondern auch High-Level-Daten, die die Unternehmensstrategie formen. Falls das nicht komplex genug wäre, ist die Aufbereitung dieser High-Level-Daten oft noch schwieriger. Im Gegensatz zu den Transaktionsdaten wird allgemein nicht mit vielem Aufwand an einer konsistenten unternehmensweiten Umsetzung gearbeitet. So kommt es nicht selten vor, dass man bei Beginn der Aufbereitung dieser Daten bemerkt, dass die High-Level-Unternehmensstrategie teilweise für einige Grenzfälle nicht sinnvoll ist.

Damit die Optimierungslogik mit dem Unternehmen übereinstimmt, ist die einfachste Weise gewöhnlich, alles erneut in Euro, Dollar oder in der entsprechenden Währung auszudrücken. Dies hat nichts mit einer höheren Bedeutung einer finanziellen Perspektive zu tun, sondern hängt lediglich damit zusammen, dass dies die einzige Einheit ist, die konsistent über das gesamte Unternehmen ohne, oder mit weniger, Koordination zwischen den Teams, benutzt werden kann. In der Praxis kommt es im Unternehmen zu Reibungen, wenn dort bereits mit nicht-finanziellen Kennzahlen - oder noch schlimmer, ohne Kennzahlen - gearbeitet wurde.

Es gibt nie genug Dokumentation

Das Geheimnis einer guten Datenaufbereitung ist eine gute Dokumentation. Dies ist einfach, doch es wird oft übersehen oder als nicht dringend oder nicht bedeutend abgelegt. Dennoch zeigt unsere Erfahrung bei Lokad, dass eine gute Dokumentation der Daten dringend und ausschlaggebend ist.

Insbesondere muss die Dokumentation für jede einzelne Datenquelle und jedes Datenfeld eine Antwort auf die Frage warum liefern. Die Dokumentation der Bedeutung von Daten ist ein Schlüsselfaktor, um sicherzustellen, dass die Daten zu einem späteren Zeitpunkt richtig verarbeitet werden. Trotzdem gibt häufig die Dokumentation, sofern eine besteht, lediglich die Feldnamen wieder.


Die Dokumentation der Eingabedaten sollte nicht als IT-Element betrachtet werden, sondern als eine Anlage aus der Sicht des Unternehmens. Unabhängig davon, wie motiviert und unterstützend Ihre IT-Abteilung ist, haben diese selten den notwendigen Einblick in das Unternehmen, um die Daten tiefgreifender zu verstehen.

Daher verbringen wir bei Lokad vom Anfang an bei neuen Kunden viel Zeit mit der Erstellung von Dokumentation. Gewöhnlich erstellen wir einige Teile nach jeder Besprechung mit unserem Kunden, der uns den notwendigen Einblick in das Unternehmen verschafft. Der Wert dieses Prozesses ist gewöhnlich nicht immer von Anfang an ersichtlich, da anfänglich andere Dinge wichtiger zu sein scheinen. Doch nach Verlauf einiger Wochen, vergisst man einige subtile Details bezüglich der Daten, so dass eine geschriebene Dokumentation den einzigen Weg darstellt, immer wieder auf dieselben Probleme zu treffen.