Projektergebnisse

Das Ziel der Quantitativen Supply Chain besteht darin, umsetzbare Entscheidungen zu liefern - die vorgeschlagenen Mengen für Bestellpositionen sind ein archetypisches Beispiel. Im Folgenden klären wir die spezifische Form und den Liefermechanismus dieser Entscheidungen weiter. Die Festlegung klarer Erwartungen an die Ergebnisse ist ein wichtiger Schritt auf der Reise, die die Quantitative Supply Chain darstellt. Darüber hinaus sind die optimierten numerischen Ergebnisse nicht der einzige wünschenswerte Output: Mehrere andere Outputs, insbesondere die Überwachung der Datenintegrität und Management-KPIs, sollten ebenfalls in den Ergebnissen enthalten sein. In der Praxis hängen die Ergebnisse einer Quantitativen Supply Chain-Initiative von der Flexibilität der verwendeten Softwarelösung ab, die die Initiative unterstützt. Dennoch werden sie hauptsächlich durch ihre Absicht definiert, die unabhängig von der verwendeten Technologie ist.

Skripte als Ergebnisse

Die Quantitative Supply Chain legt den Schwerpunkt auf vollautomatisierte Datenpipelines. Dies bedeutet nicht, dass das Software-Setup autonom ausgeführt werden soll. Eine hohe Überwachung ist natürlich wünschenswert, wenn eine Supply Chain im großen Maßstab betrachtet wird. Dennoch wird erwartet, dass die Datenpipeline vollständig automatisiert ist, in dem Sinne, dass kein einzelner Schritt in der Pipeline von einer manuellen Operation abhängt. Tatsächlich skaliert die Lösung gemäß dem Manifest einfach nicht in der Praxis, wenn manuelle Operationen zur Unterstützung der Verarbeitung von Supply Chain-Daten erforderlich sind.

Als direkte Konsequenz dieser Erkenntnis sind die Ergebnisse einer Quantitativen Supply Chain-Initiative unweigerlich ganze Softwarelösungen. Dies bedeutet nicht, dass das verantwortliche Team erwartet wird, alles neu zu implementieren: Eine Softwarelösung, die sich auf Quantitative Supply Chain konzentriert, bietet die Möglichkeit, sich ausschließlich auf die relevanten Aspekte von Supply Chain-Herausforderungen zu konzentrieren. Alle technischen Details auf niedriger Ebene, wie die Nutzung von verteilten Rechenressourcen, die innerhalb einer Cloud Computing Plattform automatisch zugewiesen werden, sollen abstrahiert werden. Das Team muss sich nicht mit solchen Angelegenheiten befassen, da erwartet wird, dass diese Aspekte angemessen von den Tools selbst verwaltet werden.

Die Ergebnisse werden als Skripte materialisiert, die in der Regel in einer Programmiersprache geschrieben sind, die den Anforderungen der Supply Chain gerecht wird und gleichzeitig ein hohes Maß an Produktivität bietet. Der Begriff “Skript” wird hier anstelle von “Quellcode” verwendet, aber die beiden Begriffe sind eng miteinander verbunden: Ein “Skript” betont die Idee eines hohen Abstraktionsgrads und einer Fokussierung auf die Aufgabe selbst, während ein “Quellcode” eine Perspektive auf niedrigerer Ebene betont, die eine genaue Reflexion der Hardware darstellen soll. Für die Quantitative Supply Chain ist offensichtlich die Perspektive der Supply Chain am wichtigsten, nicht die Hardware, die ein technischer Aspekt von sekundärer Bedeutung ist.

In den letzten zehn Jahren haben viele Lieferanten von Supply Chain-Software versucht, den Erfolg von WYSIWYG (What-You-See-Is-What-You-Get)-Benutzeroberflächen für Endkunden-Apps mit einer WYSIWYG-Lösung für die Planung und Optimierung von Supply Chains nachzuahmen. Die Lehre aus dem nahezu systematischen Scheitern dieser Art von Schnittstellen ist jedoch, dass Supply Chains komplex sind und nicht auf programmatische Tools verzichten können. Aus unserer Erfahrung ist es illusorisch zu erwarten, dass ein Drag-and-Drop-Tool in der Lage ist, die komplexen Nichtlinearitäten, die beispielsweise bei überlappenden MOQ (Mindestbestellmengen) auftreten, angemessen abzubilden. Programmatische Ausdruckskraft ist erforderlich, da die Supply Chain-Herausforderung sonst nicht einmal innerhalb des Tools ausgedrückt werden kann.

Aus Sicht des Endbenutzers sind Skripte nicht das, was Supply Chain-Experten als greifbaren Output der Quantitativen Supply Chain-Initiative erwarten würden. Die Benutzer werden mit Dashboards interagieren, die konsolidierte KPIs und Tabellen enthalten, in denen vorgeschlagene Entscheidungen zusammengefasst werden. Diese Dashboards sind jedoch vorübergehend und austauschbar. Sie werden lediglich durch erneutes Ausführen der Skripte auf den relevanten Supply Chain-Daten erstellt. Obwohl der Unterschied etwas subtil ist, ist es wichtig, das Skript, das den eigentlichen Output darstellt, nicht mit seinem numerischen Ausdruck zu verwechseln, der typischerweise das ist, was ein Endbenutzer der Lösung sehen kann.

Dashboards zur Datenintegrität

Bevor wir optimierte Entscheidungen für die Supply Chain liefern können, müssen wir sicherstellen, dass die von dem System verarbeiteten Daten, das die Quantitative Supply Chain-Initiative unterstützt, sowohl numerisch als auch semantisch korrekt sind. Der Zweck der Dashboards zur Datenintegrität oder einfach Datenintegritäts-Dashboards besteht darin, ein hohes Maß an Vertrauen in die Korrektheit der Daten zu gewährleisten, was natürlich eine wesentliche Anforderung für die Genauigkeit aller numerischen Ergebnisse ist, die von der Lösung zurückgegeben werden. Diese Dashboards unterstützen auch das Supply Chain-Team dabei, die Qualität der vorhandenen Daten zu verbessern.

Numerische Fehler sind einfach: Die aus dem ERP exportierte CSV-Datei zeigt an, dass das Produkt ABC 42 Einheiten auf Lager hat, während die ERP-Webkonsole nur 13 Einheiten auf Lager meldet. Hier ist offensichtlich, dass wir abweichende Zahlen haben, wo sie gleich sein sollten. Die Dashboards zur Datenintegrität beheben diese relativ offensichtlichen Probleme, indem sie einfach überprüfen, ob die Datenaggregate innerhalb der erwarteten numerischen Bereiche bleiben.

Semantische Fehler sind subtiler und in der Praxis viel schwieriger zu lokalisieren. Die meiste Arbeit bei der Datenbereitung besteht tatsächlich darin, alle semantischen Fehler zu identifizieren und zu beheben. Zum Beispiel: Das Feld “stockinv” im ERP könnte als der Lagerbestand dokumentiert sein. Das Supply Chain-Team geht also davon aus, dass diese Menge niemals negativ sein kann, weil offensichtlich, wenn diese Einheiten physisch erreichbar im Regal sind, es sich um eine positive Menge handeln muss. Die Dokumentation des ERP könnte jedoch auch leicht irreführend sein, und diese Menge wäre treffender als “verfügbarer Bestand” bezeichnet worden, da bei einem Fehlbestand und der Ausstellung eines rückständigen Auftrags die Menge negativ werden kann, um anzuzeigen, dass bereits eine bestimmte Anzahl von Einheiten einem Kunden zugesagt wurde. Dieser Fall veranschaulicht einen semantischen Fehler: Die Zahl an sich ist nicht falsch - es ist das Verständnis der Zahl, das ungefähr ist. In der Praxis können semantische Annäherungen viele inkonsistente Verhaltensweisen erzeugen, die wiederum laufende Reibungskosten in der Supply Chain verursachen.

Die Dashboards zur Datenintegrität konsolidieren Zahlen, die es dem Unternehmen ermöglichen, vor Ort zu entscheiden, ob die Daten als ausreichend gut angesehen werden können oder nicht. Tatsächlich ist es unerlässlich, dass ein erhebliches Datenproblem durch eine nahezu sofortige Inspektion identifiziert wird, da die Lösung täglich für Produktionszwecke verwendet wird. Andernfalls besteht die Gefahr, dass die Supply Chain über Tage oder sogar Wochen hinweg auf fehlerhaften Daten betrieben wird. In dieser Hinsicht ähnelt das Dashboard zur Datenintegrität einer Ampel: Grün bedeutet Durchfahrt, Rot bedeutet Stopp.

Darüber hinaus gibt es bei einer beträchtlichen Supply Chain in der Regel eine unvermeidliche Menge an korrupten oder anderweitig falschen Daten. Diese Daten entstehen durch fehlerhafte manuelle Eingaben oder durch seltene Ausnahmefälle in den Unternehmenssystemen selbst. In der Praxis ist es bei einer beträchtlichen Supply Chain unvernünftig zu erwarten, dass die Supply Chain-Daten zu 100% korrekt sind. Stattdessen müssen wir sicherstellen, dass die Daten genau genug sind, um die durch diese Fehler verursachten Reibungskosten nahezu zu vernachlässigen.

Daher wird erwartet, dass die Dashboards zur Datenintegrität auch Statistiken über die identifizierten Datenfehler sammeln. Diese Statistiken sind entscheidend, um festzustellen, ob den Daten vertraut werden kann. Zu diesem Zweck wird häufig ein Supply Chain Scientist hinzugezogen, um gut gewählte Alarmgrenzwerte festzulegen, die in der Regel mit einem harten Stopp der Lösung verbunden sind. Bei der Festlegung der Grenzwerte muss Vorsicht walten, da die Lösung unbrauchbar wird, wenn sie zu niedrig sind und zu häufig wegen “identifizierter Datenprobleme” gestoppt wird. Wenn sie jedoch zu hoch sind, können die durch Datenfehler verursachten Reibungskosten erheblich werden und die Vorteile der Initiative selbst untergraben.

Darüber hinaus sollen die Dashboards zur Datenintegrität auch priorisierte Einblicke in die Bemühungen zur Verbesserung der Daten bieten. Tatsächlich können viele Datenpunkte falsch sein, aber auch unbedeutend. Es spielt zum Beispiel keine Rolle, ob der Kaufpreis eines Produkts falsch ist, wenn die Marktnachfrage nach diesem Produkt vor Jahren verschwunden ist, da es keine weiteren Bestellungen für dieses Produkt geben wird.

Die Quantitative Supply Chain betont, dass die detaillierte Auflösung der Datenfehler, die möglicherweise eine erhebliche Menge an manueller Arbeit erfordert, gegenüber der geschätzten finanziellen Auswirkung des Datenfehlers im Verhältnis zu den Arbeitskosten für die Korrektur priorisiert werden sollte. Tatsächlich variiert je nach Situation der mit der Korrektur eines einzelnen fehlerhaften Datenpunkts verbundene Kosten enorm und muss bei der vorgeschlagenen Priorisierung berücksichtigt werden. Schließlich kann der Datenverbesserungsprozess gestoppt werden, wenn die Korrekturkosten als teurer angesehen werden als die durch diese Fehler verursachten Supply Chain-Kosten.

Priorisierte Entscheidungs-Dashboards

Wie wir gesehen haben, können nur Supply Chain-Entscheidungen wirklich aus quantitativer Sicht bewertet werden. Daher ist es nicht überraschend, dass eines der wichtigsten operativen Ergebnisse einer Quantitative Supply Chain-Initiative die Dashboards sind, die die als endgültiges numerisches Ergebnis der gesamten Datenpipeline erhaltenen Entscheidungen zusammenfassen. Ein solches Dashboard kann so einfach sein wie eine Tabelle, in der für jedes Produkt die genaue Menge in Einheiten aufgelistet ist, die sofort nachbestellt werden soll. Wenn Mindestbestellmengen (MOQs) vorhanden sind - oder andere Bestellbeschränkungen - können die vorgeschlagenen Mengen die meiste Zeit null sein, bis die richtigen Schwellenwerte erreicht sind.

Vereinfachend nehmen wir hier an, dass diese numerischen Ergebnisse in ein Dashboard eingebunden sind, das eine spezifische Form einer Benutzeroberfläche ist. Das Dashboard selbst ist jedoch nur eine Option, die relevant sein kann oder auch nicht. In der Praxis wird erwartet, dass die Software, die die Quantitative Supply Chain-Initiative unterstützt, hochflexibel ist, d.h. programmatisch flexibel ist und viele Möglichkeiten bietet, diese Ergebnisse in verschiedenen Datenformaten zu verpacken. Zum Beispiel können die numerischen Ergebnisse in flachen Textdateien konsolidiert werden, die automatisch in das primäre ERP importiert werden sollen, das zur Verwaltung der Vermögenswerte des Unternehmens verwendet wird.

Während das Format der Entscheidungen stark von der behandelten Supply Chain-Aufgabe abhängt, erfordern die meisten Aufgaben eine Priorisierung dieser Entscheidungen. Zum Beispiel kann der Vorgang der Berechnung der vorgeschlagenen Mengen für eine Bestellung durch eine priorisierte Liste der zu erwerbenden Einheiten zerlegt werden. Die profitabelste Einheit wird an erster Stelle eingestuft. Da der Bestand mit abnehmenden Erträgen einhergeht, deckt die zweite Einheit, die für dasselbe Produkt erworben wird, einen abnehmenden Anteil der Marktnachfrage ab. Daher muss die zweite Einheit für dieses Produkt möglicherweise nicht der zweite Eintrag in der Gesamtliste sein. Stattdessen kann die zweitprofitabelste Einheit mit einem anderen Produkt verbunden sein usw. Die priorisierte Liste der zu erwerbenden Einheiten ist konzeptionell endlos: Es ist immer möglich, eine weitere Einheit zu kaufen. Da die Marktnachfrage endlich ist, würden alle gekauften Einheiten nach einem bestimmten Punkt zu totem Bestand werden. Um diese Prioritätsliste in die endgültigen Kaufmengen umzuwandeln, ist nur ein Abbruchkriterium einzuführen und die Mengen pro Produkt zusammenzufassen. In der Praxis erschweren nichtlineare Bestellbeschränkungen diese Aufgabe weiter, aber um der Einfachheit willen lassen wir diese Beschränkungen in diesem Stadium der Diskussion beiseite.

Die Priorisierung von Entscheidungen ist aus Sicht der quantitativen Supply Chain eine sehr natürliche Operation. Da jede Entscheidung mit einem finanziellen Ergebnis in Dollar verbunden ist, ist es einfach, die Entscheidungen von der profitabelsten bis zur am wenigsten profitablen zu rangieren. Daher kann erwartet werden, dass viele, wenn nicht die meisten, der Dashboards, die die vorgeschlagenen Supply-Chain-Entscheidungen zusammenstellen, in der Praxis priorisierte Listen von Entscheidungen sind. Diese Dashboards enthalten Listen mit hochprofitablen Entscheidungen, die oben aufgeführt sind, und sehr unrentable Entscheidungen, die unten aufgeführt sind. Alternativ können Supply-Chain-Praktiker beschließen, die Listen zu kürzen, wenn Entscheidungen unrentabel sind. Es gibt jedoch häufig Erkenntnisse, die gewonnen werden können, wenn Entscheidungen untersucht werden, die knapp unterhalb der Rentabilitätsschwelle liegen - auch wenn das Unternehmen offensichtlich nicht erwartet wird, auf diese unrentablen Einträge zu reagieren.

Um solche entscheidungsgetriebenen Dashboards bereitzustellen, muss die Softwarelösung, die die quantitative Supply Chain unterstützt, eine große Anzahl möglicher Entscheidungen numerisch untersuchen können. Zum Beispiel sollte die Lösung in der Lage sein, die finanziellen Auswirkungen des Kaufs jeder einzelnen Einheit, Einheit für Einheit, für jedes einzelne Produkt an jedem einzelnen Standort zu berücksichtigen. Nicht überraschend erfordert diese Operation möglicherweise erhebliche Rechenressourcen. Glücklicherweise sind heutzutage Computerhardware in der Lage, selbst die größten globalen Lieferketten zu bewältigen. Vorausgesetzt, die zugrunde liegende Softwarelösung ist für die quantitative Supply Chain geeignet, sollte die Skalierbarkeit der Datenverarbeitung für Supply-Chain-Teams kein Problem darstellen.

Die numerischen Ergebnisse transparent machen

Systeme, die in der Supply Chain und auch in anderen Bereichen abfällig als Black Boxes bezeichnet werden, sind Systeme, die Ausgaben generieren, die von den Praktikern, die mit diesen Systemen interagieren, nicht erklärt werden können. Die quantitative Supply Chain, mit ihrem spezifischen Fokus auf eine automatisierte Datenpipeline, läuft auch Gefahr, das zu liefern, was Supply-Chain-Teams als “Black Boxes” klassifizieren würden. Tatsächlich sind die finanziellen Auswirkungen von Supply-Chain-Entscheidungen für ein Unternehmen sehr wichtig, und während ein neueres System die Situation verbessern kann, kann es auch potenziell Katastrophen verursachen. Obwohl Automatisierung sehr wünschenswert ist, bedeutet dies nicht, dass von dem Supply-Chain-Team erwartet wird, dass es ein gründliches Verständnis dafür hat, was von der Datenpipeline, die die quantitative Supply Chain-Initiative unterstützt, geliefert wird.

Der Begriff “Whiteboxing” bezieht sich auf den Aufwand, der erforderlich ist, um die Lösung vollständig transparent zum Nutzen der Supply-Chain-Teams zu machen. Dieser Ansatz betont, dass keine Technologie von Natur aus transparent ist. Transparenz ist das Ergebnis einer spezifischen Anstrengung, die Teil der Initiative selbst ist. Selbst eine einfache lineare Regression kann in der Praxis verwirrende Ergebnisse erzeugen. Abgesehen von einigen Ausnahmetalenten haben die meisten Menschen kein intuitives Verständnis dafür, was die “erwartete” Ausgabe des linearen Modells ist, wenn 4 oder mehr Dimensionen involviert sind. Dennoch beinhalten Supply-Chain-Probleme oft Dutzende, wenn nicht Hunderte von Variablen. Daher sind selbst vereinfachte statistische Modelle de facto Black Boxes für Supply-Chain-Praktiker. Natürlich bleiben die Praktiker bei der Verwendung von Machine-Learning-Algorithmen, wie es von der quantitativen Supply Chain empfohlen wird, noch mehr im Dunkeln.

Während der Black-Box-Effekt ein echtes Problem ist, liegt die realistische Lösung nicht darin, die Datenverarbeitung in Berechnungen zu vereinfachen, die sofort intuitiv für den menschlichen Verstand sind. Dieser Ansatz ist ein Rezept für extreme Ineffizienz, das alle Vorteile der modernen Rechenressourcen zunichte macht, die zur Bewältigung der rohen Komplexität moderner Lieferketten genutzt werden können. Die Vereinfachung des Prozesses ist nicht die Antwort. Das Whiteboxing ist es.

Selbst die komplexesten Empfehlungen für die Lieferkette können für Supply-Chain-Praktiker weitgehend transparent gemacht werden, indem die inneren Berechnungen mit gut gewählten finanziellen Indikatoren aufgeschlüsselt werden, die die wirtschaftlichen Treiber repräsentieren, die die Empfehlung selbst unterstützen. Anstatt nur eine nackte Tabelle mit zwei Spalten Produkt und Menge als vorgeschlagene Bestellung anzuzeigen, sollte die Tabelle ein paar Spalten enthalten, die die Entscheidungsfindung unterstützen. Diese zusätzlichen Spalten können den aktuellen Bestand, die Gesamtnachfrage der letzten Monate, die erwartete Lieferzeit, die erwarteten finanziellen Kosten bei Nichtbestellung (wenn keine Bestellung erfolgt), die erwarteten finanziellen Kosten bei Überbestand (Risiko, das mit der vorgeschlagenen Bestellung verbunden ist), usw. enthalten. Die Spalten sind so gestaltet, dass das Supply-Chain-Team schnelle Plausibilitätsprüfungen der vorgeschlagenen Mengen durchführen kann. Über die Spalten kann das Team schnell Vertrauen in die numerischen Ergebnisse aufbauen und auch einige Schwächen einer Lösung identifizieren, die weiter verbessert werden muss.

Das Erweitern der Dashboards zu Whiteboxing-Zwecken ist teilweise eine Kunst. Das Generieren von Millionen von Zahlen ist einfach, selbst wenn nur die Rechenressourcen eines Smartphones zur Verfügung stehen. Das Generieren von 10 Zahlen, die es wert sind, täglich betrachtet zu werden, ist jedoch sehr schwierig. Die Kernherausforderung besteht daher darin, ein Dutzend oder weniger KPIs zu identifizieren, die ausreichen, um Licht auf die empfohlenen Entscheidungen in der Lieferkette zu werfen. Gute KPIs erfordern in der Regel viel Arbeit; sie sollten keine naiven Definitionen sein, die in der Lieferkette in der Regel irreführend sind. Zum Beispiel kann selbst eine so einfache Spalte wie der “Einheitskaufpreis” sehr irreführend sein, wenn der Lieferant Mengenrabatte anbietet, wodurch der Kaufpreis von der gekauften Menge abhängt.

Strategische Dashboards

Während der Fokus auf Entscheidungen im kleinen Maßstab notwendig ist - da dies einer der wenigen Ansätze ist, der sich für quantitative Leistungsbewertungen eignet - muss die Lieferkette möglicherweise auch in größerem, stärker disruptivem Maße angepasst werden, um die Leistung auf das nächste Level zu bringen. Zum Beispiel erhöht der Kauf von mehr gut ausgewählten Lagerbeständen marginal den Servicegrad. Irgendwann ist das Lager jedoch voll und es kann keine zusätzliche Einheit gekauft werden. In dieser Situation sollte über ein größeres Lager nachgedacht werden. Um die Auswirkungen dieser Einschränkung zu bewerten, können wir die Lagerkapazitätsbeschränkung aus den Berechnungen entfernen und den Gesamtfinanzvorteil des Betriebs mit einem beliebig großen Lager bewerten. Das Supply-Chain-Management kann dann den finanziellen Indikator im Auge behalten, der mit den Reibungskosten verbunden ist, die durch die Lagerkapazität selbst entstehen, und dann entscheiden, wann es an der Zeit ist, die Lagerkapazität zu erhöhen.

Typischerweise arbeiten Lieferketten auf der Grundlage zahlreicher Einschränkungen, die nicht täglich überarbeitet werden können. Diese Einschränkungen können das Betriebskapital, die Lagerkapazität, Verzögerungen im Transport, die Produktionsdurchsatzrate usw. umfassen. Jede Einschränkung ist mit einem impliziten Opportunitätskosten für die Lieferkette verbunden, die sich in der Regel in mehr Beständen, mehr Verzögerungen oder mehr Lagerbeständen niederschlagen. Die Opportunitätskosten können durch die Leistungsgewinne bewertet werden, die durch das Entfernen oder Abschwächen der Einschränkung selbst erzielt würden. Während einige dieser Simulationen möglicherweise schwierig umzusetzen sind, sind sie häufig nicht schwieriger als die Optimierung der Routineentscheidungen, d.h. die Festlegung der Bestellmengen.

Die Quantitative Supply Chain betont, dass die Opportunitätskosten, die mit diesen Einschränkungen verbunden sind, Teil der Produktionsdatenpipeline sein sollten und in der Regel mit dedizierten Dashboards materialisiert werden sollten, die speziell dazu dienen, dem Supply-Chain-Management dabei zu helfen, größere Veränderungen in ihrer Lieferkette in Betracht zu ziehen. Diese Art von Dashboards werden als strategische Dashboards bezeichnet. Dieser Ansatz unterscheidet sich von der traditionellen Lieferkettenpraxis, die ad hoc-Initiativen betont, wenn das Gefühl besteht, dass die Lieferkette kurz vor einer Betriebsgrenze steht. Die von strategischen Dashboards gelieferten KPIs werden täglich oder bei Bedarf häufiger aktualisiert, genau wie der Rest der Datenpipeline. Sie müssen keine Last-Minute-Anstrengungen unternehmen, da sie auf dem neuesten Stand sind und von den Erkenntnissen einer langfristigen Initiative profitieren können.

Die strategischen Dashboards unterstützen den Entscheidungsprozess des Supply-Chain-Managements. Da sie Teil der Datenpipeline sind, bleiben die KPIs bei einer schnelleren Marktentwicklung als üblich auf dem neuesten Stand zur aktuellen Situation des Unternehmens. Dieser Ansatz vermeidet die traditionellen Fallstricke ad hoc-Untersuchungen, die bereits überfälligen Problemen weitere Verzögerungen hinzufügen. Dieser Ansatz mildert auch das alternative Problem weitgehend ab, nämlich hastige strategische Entscheidungen, die sich als unrentabel erweisen - ein bedauerlicher Zustand, der von Anfang an hätte erkannt werden können.

Inspektor-Dashboards

Lieferketten sind sowohl komplex als auch unvorhersehbar. Diese Eigenschaften machen das Debuggen der Datenpipeline zu einer furchterregend herausfordernden Aufgabe. Dennoch ist diese Datenpipeline das Rückgrat der Quantitative Supply Chain-Initiative. Datenverarbeitungsfehler oder Bugs können überall in der Datenpipeline auftreten. Schlimmer noch, die häufigste Art von Problem ist nicht die falsche Formel, sondern die mehrdeutige Semantik. Zum Beispiel kann die Variable stockinv am Anfang der Pipeline auf den verfügbaren Bestand verweisen (wo negative Werte möglich sind), während sie später mit einer Interpretation des Bestands vor Ort verwendet wird (wo positive Werte erwartet werden). Die mehrdeutige Interpretation der Variablen stockinv kann eine Vielzahl von falschen Verhaltensweisen erzeugen, von Systemabstürzen - die offensichtlich sind und daher nur mäßig schädlich - bis hin zu einer stillen und weit verbreiteten Korruption der Lieferkettenentscheidungen.

Da Lieferketten fast immer aus einer einzigartigen Mischung von im Laufe der Jahre eingerichteten Softwarelösungen bestehen, besteht keine Hoffnung, Zugang zu einer “bewährten” Softwarelösung zu erhalten, die frei von Fehlern ist. Tatsächlich treten die meisten Probleme an den Systemgrenzen auf, wenn Daten aus verschiedenen Systemen abgeglichen werden oder sogar nur Daten aus verschiedenen Modulen innerhalb desselben Systems abgeglichen werden. Daher muss das Tooling unabhängig davon, wie bewährt die Softwarelösung sein mag, den Debugging-Prozess problemlos unterstützen, da solche Probleme unweigerlich auftreten.

Der Zweck der Inspektor-Dashboards besteht darin, detaillierte Ansichten für eine genaue Untersuchung der Lieferkettendatensätze bereitzustellen. Diese Dashboards sind jedoch keine einfachen Drill-Downs, um die Eingabedatentabellen zu inspizieren. Ein solcher Drill-Down oder ähnliche Ansätze zum Zerlegen der Daten würden den Punkt verfehlen. Lieferketten drehen sich um Flüsse: Materialfluss, Zahlungsfluss usw. Einige der schwerwiegendsten Datenprobleme treten auf, wenn die Kontinuität des Flusses “logisch” verloren geht. Wenn beispielsweise Waren von Lager A nach Lager B transportiert werden, fehlen möglicherweise einige Produktbuchungen in der Datenbank von Lager B, was zu subtilen Datenkorruptionen führt, da Einheiten aus Lager A in Lager B empfangen werden, ohne ordnungsgemäß mit ihrem Produkt verknüpft zu werden. Wenn numerische Ergebnisse seltsam erscheinen, sind diese Inspektor-Dashboards die erste Wahl für den Supply Chain Scientist, um eine schnelle Stichprobendatenuntersuchung durchzuführen.

In der Praxis bietet ein Inspektor-Dashboard einen Einstieg auf niedriger Ebene, wie z.B. einen Produktcode oder eine SKU, und konsolidiert alle Daten, die mit diesem Einstiegspunkt verbunden sind, in einer einzigen Ansicht. Wenn Waren durch viele Standorte fließen, wie es zum Beispiel in der Luft- und Raumfahrt-Lieferkette der Fall ist, versucht das Inspektor-Dashboard in der Regel, die Trajektorien der Waren wiederherzustellen, die nicht nur durch mehrere physische Standorte, sondern auch durch mehrere Systeme gegangen sein können. Durch die Zusammenführung all dieser Daten an einem Ort ist es dem Supply Chain Scientist möglich zu beurteilen, ob die Daten sinnvoll sind: Ist es möglich, den Ursprung der versandten Waren zu identifizieren? Stimmen die Lagerbewegungen mit den offiziellen Lieferkettenrichtlinien überein usw.? Das Inspektor-Dashboard ist ein “Debugging”-Tool, da es darauf ausgelegt ist, die eng miteinander verbundenen Daten zusammenzuführen, nicht aus IT-Sicht, sondern aus Sicht der Lieferkette.

Eines der bizarrsten Probleme, mit denen Lokad bei der Untersuchung von Lieferketten-Datensätzen konfrontiert wurde, war der Fall der teleportierten Teile. Das Unternehmen - in diesem Fall eine Fluggesellschaft - hatte Flugzeugteile sowohl in Kontinentaleuropa als auch in Südasien gelagert. Da die Flugsicherheit eine absolute Voraussetzung für den Betrieb ist, führte das Unternehmen für alle seine Teile eine einwandfreie Lagerbewegungsdokumentation. Mit einem neu entwickelten Inspektor-Dashboard stellte das Lokad-Team jedoch fest, dass sich einige Teile angeblich in nur 2 oder 3 Minuten von Asien nach Europa und umgekehrt bewegten. Da Flugzeugteile mit dem Flugzeug transportiert wurden, wäre eine Transportzeit von mindestens einigen Stunden zu erwarten gewesen - sicherlich nicht Minuten. Wir vermuteten sofort ein Problem mit der Zeitzone oder einer anderen Computerzeit, aber auch die Zeitprotokolle erwiesen sich als einwandfrei. Bei weiterer Untersuchung der Daten stellte sich dann heraus, dass die teleportierten Teile tatsächlich verwendet und an Flugzeugen an ihrem Landeort montiert wurden, was umso verwirrender war. Indem wir den Supply-Chain-Teams ermöglichten, selbst einen Blick auf die Inspektor-Dashboards zu werfen, wurde das Rätsel schließlich gelöst. Die teleportierten Teile waren Flugzeugräder, die aus zwei Halbrädern und einem Reifen bestanden. Das Rad konnte demontiert werden, indem die beiden Halbräder und der Reifen auseinandergenommen wurden. Im extremsten Fall, wenn die beiden Halbräder und der Reifen entfernt wurden, blieb nichts Physisches übrig. Das vollständig demontierte Rad konnte daher frei an jedem beliebigen Ort wieder montiert werden, ohne Rücksicht auf seinen ursprünglichen Standort.

Die Inspektor-Dashboards sind das Gegenstück auf niedriger Ebene zum Daten-Gesundheits-Dashboard. Sie konzentrieren sich auf vollständig disaggregierte Daten, während Daten-Gesundheits-Dashboards in der Regel eine höhere Sicht auf die Daten einnehmen. Außerdem sind Inspektor-Dashboards in der Regel ein integraler Bestandteil des Whiteboxing-Ansatzes. Wenn sie mit einer scheinbar verwirrenden Empfehlung konfrontiert werden, müssen Supply-Chain-Praktiker einen genauen Blick auf eine SKU oder ein Produkt werfen, um herauszufinden, ob die empfohlene Entscheidung vernünftig ist oder nicht. Das Inspektor-Dashboard wird typischerweise für diesen Zweck angepasst, indem viele Zwischenergebnisse einbezogen werden, die zur Berechnung der endgültigen Empfehlung beitragen.