Projektergebnisse

learn menu

Das Ziel von die Quantitative Supply Chain ist es, umsetzbare Entscheidungen zu liefern – vorgeschlagene Mengen für Bestellaufträge sind ein archetypisches Beispiel. Im Folgenden erläutern wir die spezifische Form und den Bereitstellungsmechanismus dieser Entscheidungen. Klare Erwartungen an die Liefergegenstände zu setzen, ist ein wichtiger Schritt auf der Reise, die die Quantitative Supply Chain repräsentiert. Außerdem sind die optimierten numerischen Ergebnisse nicht der einzige erwünschte Output: Verschiedene weitere Ergebnisse, insbesondere das Monitoring der Datenqualität und Management-KPIs, sollten ebenfalls zum Liefergegenstand gehören. In der Praxis hängen die Liefergegenstände einer Initiative der Quantitative Supply Chain von der Flexibilität der eingesetzten Softwarelösung ab, die die Initiative unterstützt. Dennoch werden sie in erster Linie durch ihre Intention definiert, welche technologieneutral ist.

Skripte als Liefergegenstand

Die Quantitative Supply Chain legt Wert auf vollautomatisierte Datenpipelines. Dies impliziert nicht, dass das Software-Setup autonom laufen soll – ein hoher Grad an enger Überwachung ist natürlich wünschenswert, wann immer eine groß angelegte supply chain in Betracht gezogen wird. Dennoch wird erwartet, dass die Datenpipeline in dem Sinne vollautomatisch ist, dass kein einzelner Schritt in der Pipeline tatsächlich von einer manuellen Operation abhängt. Tatsächlich, wie im Manifest dargelegt, führt die Einbeziehung manueller Operationen in die Verarbeitung von supply chain Daten dazu, dass die Lösung in der Praxis einfach nicht skaliert.

In direktem Zusammenhang mit dieser Erkenntnis sind die Liefergegenstände einer Initiative der Quantitative Supply Chain stets komplette Softwarepakete. Dies bedeutet nicht, dass erwartet wird, dass das verantwortliche Team alles neu implementieren muss: Eine Softwarelösung, die der Quantitative Supply Chain gewidmet ist, bietet die Möglichkeit, sich ausschließlich auf die wesentlichen Aspekte von supply chain challenges zu konzentrieren. Alle technischen Details – wie beispielsweise die Nutzung verteilt rechnender Ressourcen, die automatisch innerhalb einer cloud computing Plattform zugeteilt werden – sollen abstrahiert werden. Das Team muss sich nicht mit diesen Angelegenheiten befassen, da diese Aspekte von den entsprechenden Tools eigenständig verwaltet werden.

Die Liefergegenstände werden als Skripte realisiert, die typischerweise in einer Programmiersprache geschrieben sind, welche die supply chain Anforderungen erfüllt und gleichzeitig ein hohes Maß an Produktivität bietet. Der Begriff “Skript” wird hier anstelle von “Quellcode” verwendet, wobei beide Begriffe eng miteinander verknüpft sind: Ein “Skript” hebt die Idee eines hohen Abstraktionsgrads und den Fokus auf die eigentliche Aufgabe hervor, während “Quellcode” eine detailliertere Perspektive darstellt, die eine genaue Abbildung der zugrundeliegenden Rechenhardware zum Ziel hat. Für die Quantitative Supply Chain ist offensichtlich die supply chain Perspektive von größter Bedeutung, nicht die Rechenhardware, welche nur einen sekundären technischen Aspekt darstellt.

Im letzten Jahrzehnt hat der Erfolg von WYSIWYG (what-you-see-is-what-you-get) Benutzeroberflächen für Endkunden-Apps dazu geführt, dass viele software vendors versucht haben, diesen Ansatz im supply chain Bereich durch eine WYSIWYG-Lösung für Planung und Optimierung nachzuahmen. Allerdings zeigt die nahezu systematische Misserfolgsgeschichte dieser Schnittstellen, dass supply chains komplex sind und der Notwendigkeit programmgesteuerter Werkzeuge nicht entkommen können. Nach unserer Erfahrung ist es höchst illusorisch, von einem Drag-and-Drop-Tool zu erwarten, dass es die komplexen Nichtlinearitäten – wie etwa bei überlappenden MOQ (Mindestbestellmengen) – korrekt abbildet. Programmgesteuerte Ausdrucksfähigkeit ist erforderlich, da sich das supply chain Problem ansonsten nicht einmal im Tool formulieren lässt.

Aus der Perspektive des Endnutzers entsprechen Skripte naturgemäß nicht den greifbaren Ergebnissen, die supply chain Praktiker von einer Initiative der Quantitative Supply Chain erwarten würden. Die Benutzer interagieren stattdessen mit dashboards, die konsolidierte KPIs und Tabellen mit den vorgeschlagenen Entscheidungen enthalten. Diese Dashboards sind jedoch transient und austauschbar – sie werden schlichtweg durch erneutes Ausführen der Skripte auf den relevanten supply chain Daten erzeugt. Auch wenn der Unterschied subtil ist, ist es wichtig, das Skript, welches den tatsächlichen Liefergegenstand darstellt, nicht mit dessen numerischer Darstellung zu verwechseln, die üblicherweise vom Endnutzer der Lösung wahrgenommen wird.

Dashboards zur Daten-Gesundheit

Bevor optimierte Entscheidungen für den supply chain bereitgestellt werden, muss sichergestellt werden, dass die vom System, das die Initiative der Quantitative Supply Chain unterstützt, verarbeiteten Daten sowohl numerisch als auch semantisch korrekt sind. Der Zweck der Dashboards zur Überwachung der Datenqualität, oder einfach Dashboards zur Daten-Gesundheit, besteht darin, ein hohes Maß an Vertrauen in die Korrektheit der Daten zu gewährleisten – eine Voraussetzung, die essenziell für die Genauigkeit aller von der Lösung zurückgegebenen numerischen Ergebnisse ist. Diese Dashboards unterstützen zudem das supply chain Team dabei, die Qualität der vorhandenen Daten zu verbessern.

Numerische Fehler sind leicht erkennbar: Die aus dem ERP exportierte CSV-Datei zeigt, dass das Produkt ABC 42 Einheiten auf Lager hat, während die ERP-Webkonsole lediglich 13 Einheiten ausweist. Hier wird deutlich, dass es Diskrepanzen gibt, wo eigentlich identische Zahlen erwartet werden. Die Dashboards zur Daten-Gesundheit beheben diese relativ offensichtlichen Probleme, indem sie überprüfen, dass Datenaggregate innerhalb der erwarteten numerischen Bereiche liegen.

Semantische Fehler sind subtiler und in der Praxis deutlich schwerer zu identifizieren. Der Großteil der Arbeit in der Datenaufbereitung besteht tatsächlich darin, alle semantischen Fehler zu erkennen und zu beheben. Zum Beispiel könnte das Feld stockinv im ERP als der vorhandene Bestand dokumentiert sein. Daraus schließt das supply chain Team, dass dieser Wert niemals negativ sein kann, denn wenn diese Einheiten physisch im Regal vorhanden sind, muss es sich um eine positive Zahl handeln. Allerdings kann auch die ERP-Dokumentation etwas irreführend sein, sodass dieser Wert treffender als “stock available” bezeichnet worden wäre, da – sobald ein stock-out eintritt und der Kunde einen rückständiger Auftrag erteilt – der Wert negativ werden kann, um widerzuspiegeln, dass eine gewisse Anzahl an Einheiten bereits einem Kunden zugeordnet ist. Dieses Beispiel verdeutlicht einen semantischen Fehler: Die Zahl an sich ist nicht falsch – jedoch ist das Verständnis der Zahl ungenau. In der Praxis können solche semantischen Annäherungen zahlreiche inkonsistente Verhaltensweisen hervorrufen, die wiederum fortlaufende Reibungskosten innerhalb der supply chain verursachen.

Die Dashboards zur Daten-Gesundheit fassen Zahlen zusammen, die es dem Unternehmen ermöglichen, sofort zu entscheiden, ob den Daten ausreichend vertraut werden kann oder nicht. Da die Lösung täglich für Produktionszwecke eingesetzt wird, ist es unabdingbar, dass ein signifikantes Datenproblem nahezu sofort entdeckt wird. Andernfalls besteht die Gefahr, dass die supply chain tagelang – wenn nicht wochenlang – auf fehlerhaften Daten operiert. In diesem Zusammenhang gleicht das Dashboard zur Daten-Gesundheit einer Ampel: Grün heißt freigeben, Rot heißt stoppen.

Darüber hinaus enthält eine umfangreiche supply chain in der Regel einen unvermeidbaren Anteil an beschädigten oder anderweitig fehlerhaften Daten. Diese Daten resultieren aus fehlerhaften manuellen Eingaben oder aus seltenen Sonderfällen in den firmeneigenen Systemen. Für jede umfangreiche supply chain ist es in der Praxis unrealistisch, eine hundertprozentige Datenkorrektheit zu erwarten. Stattdessen muss sichergestellt werden, dass die Daten so genau sind, dass die durch Fehler entstehenden Reibungskosten nahezu vernachlässigbar bleiben.

Daher wird außerdem erwartet, dass die Dashboards zur Daten-Gesundheit Statistiken über die identifizierten Datenfehler sammeln. Diese Statistiken sind entscheidend dafür, zu belegen, dass den Daten vertraut werden kann. Zu diesem Zweck wird häufig ein Supply Chain Scientist hinzugezogen, um fundierte Alarmgrenzwerte festzulegen, die typischerweise mit einem harten Stopp der Lösung einhergehen. Hierbei ist Vorsicht geboten: Sind die Grenzwerte zu niedrig, wird die Lösung unbrauchbar, weil sie zu häufig wegen „identifizierter Datenprobleme“ angehalten wird; sind sie hingegen zu hoch, können die durch Datenfehler entstehenden Reibungskosten erheblich werden und somit den Nutzen der Initiative untergraben.

Über die Rot-Grün-Signalisierung hinaus sollen die Dashboards zur Daten-Gesundheit auch priorisierte Einblicke in die Bemühungen zur Datenverbesserung bieten. Tatsächlich können zwar viele Datenpunkte fehlerhaft sein, dennoch sind sie oft unerheblich. So spielt es beispielsweise keine Rolle, wenn der Einkaufspreis eines Produkts falsch angegeben ist, sofern die Marktnachfrage für dieses Produkt bereits vor Jahren verschwunden ist, da es keine weiteren Bestellaufträge mehr geben wird.

Die Quantitative Supply Chain betont, dass die feingranulare Auflösung von Datenfehlern – die mitunter einen erheblichen manuellen Aufwand erfordert – in Relation zu den geschätzten finanziellen Auswirkungen des Fehlers selbst bzw. den mit der Korrektur verbundenen Arbeitskosten priorisiert werden sollte. Denn je nach Situation variieren die Kosten für die Behebung eines einzelnen fehlerhaften Datenpunkts enorm und müssen in der vorgeschlagenen Priorisierung berücksichtigt werden. Schließlich kann der Prozess der Datenverbesserung eingestellt werden, wenn die Korrekturkosten als teurer angesehen werden als die durch die Fehler verursachten supply chain Kosten.

Priorisierte Entscheidungs-Dashboards

Wie wir gesehen haben, können nur supply chain decisions wirklich aus einer quantitativen Perspektive bewertet werden. Es überrascht daher nicht, dass einer der wichtigsten operativen Liefergegenstände einer Initiative der Quantitative Supply Chain die Dashboards sind, welche die als finales numerisches Ergebnis der gesamten Datenpipeline ermittelten Entscheidungen zusammenfassen. Ein solches Dashboard kann so einfach sein wie eine Tabelle, die für jedes Produkt die exakte Menge in Einheiten auflistet, die sofort nachbestellt werden soll. Sind MOQs (Mindestbestellmengen) oder andere Bestellrestriktionen vorhanden, so könnten die vorgeschlagenen Mengen größtenteils null betragen, bis die entsprechenden Schwellenwerte erreicht werden.

Der Einfachheit halber nehmen wir hier an, dass diese numerischen Ergebnisse in einem Dashboard zusammengeführt werden, welches eine spezifische Form der Benutzeroberfläche darstellt. Das Dashboard selbst ist jedoch nur eine von mehreren möglichen Optionen. In der Praxis wird erwartet, dass die Software, die die Initiative der Quantitative Supply Chain unterstützt, hochgradig flexibel – also programmgesteuert flexibel – ist und zahlreiche Möglichkeiten bietet, diese Ergebnisse in verschiedenen Datenformaten aufzubereiten. So können die numerischen Ergebnisse beispielsweise in flachen Textdateien konsolidiert werden, die automatisch in das primäre ERP importiert werden, das zur Verwaltung der Unternehmensressourcen eingesetzt wird.

Während das Format der Entscheidungen stark von der bearbeiteten supply chain Aufgabe abhängt, erfordern die meisten Aufgaben eine Priorisierung dieser Entscheidungen. So kann etwa der Vorgang zur Berechnung der vorgeschlagenen Mengen für einen Bestellauftrag durch eine prioritized list der zu erwerbenden Einheiten untergliedert werden. Die profitabelste Einheit wird an erster Stelle eingereiht. Da der Lagerbestand mit abnehmendem Ertrag einhergeht, deckt die zweite für dasselbe Produkt erworbene Einheit nur einen abnehmenden Anteil der Marktnachfrage ab. Daher muss die zweite Einheit dieses Produkts nicht zwangsläufig der zweite Eintrag in der Gesamtliste sein. Stattdessen kann die zweitprofitabelste Einheit einem anderen Produkt zugeordnet werden. Die [prioritized list] der zu erwerbenden Einheiten ist konzeptionell unendlich – es ist stets möglich, eine weitere Einheit zu kaufen. Um diese Prioritätenliste in die finalen Bestellmengen zu überführen, bedarf es lediglich der Einführung eines Abbruchkriteriums und der Aufsummierung der mengenmäßigen Bestellungen pro Produkt. In der Praxis erschweren nichtlineare Bestellrestriktionen diese Aufgabe zusätzlich, aber der Einfachheit halber lassen wir diese an dieser Stelle außer Acht.

Die Priorisierung von Entscheidungen ist aus der Perspektive der Quantitative Supply Chain eine ganz natürliche Operation. Da jede Entscheidung mit einem finanziellen Ergebnis in Dollar ausgedrückt wird, ist es relativ einfach, die Entscheidungen von der profitabelsten bis zur unprofitabelsten zu ordnen. So ist in der Praxis zu erwarten, dass viele – wenn nicht sogar die meisten – der Dashboards, welche die vorgeschlagenen supply chain decisions zusammenstellen, als priorisierte Listen von Entscheidungen vorliegen. Diese Dashboards enthalten Listen, in denen hochprofitable Entscheidungen oben und sehr unprofitable unten aufgeführt sind. Alternativ können supply chain Praktiker entscheiden, die Listen zu kürzen, sobald Entscheidungen unprofitabel werden. Dennoch bietet die Möglichkeit, Entscheidungen knapp unterhalb der Profitabilitätsschwelle zu inspizieren, häufig zusätzliche Erkenntnisse – selbst wenn das Unternehmen erwartungsgemäß nicht auf diese unprofitablen Einträge reagiert.

Um diese Art von entscheidungsgetriebenen Dashboards bereitstellen zu können, muss die Softwarelösung, die die Quantitative Supply Chain unterstützt, numerisch eine enorme Anzahl möglicher Entscheidungen durchrechnen. So sollte die Lösung beispielsweise in der Lage sein, die finanziellen Auswirkungen des Einkaufs jeder einzelnen Einheit – Einheit für Einheit – für jedes Produkt an jedem Standort zu berücksichtigen. Nicht überraschend kann dieser Ablauf erhebliche Rechenressourcen erfordern. Glücklicherweise ist die heutige Rechenhardware in der Lage, selbst mit den größten globalen supply chains umzugehen. Vorausgesetzt, die zugrunde liegende Softwarelösung ist angemessen auf die Quantitative Supply Chain ausgerichtet, sollte die Skalierbarkeit der Datenverarbeitung für die supply chain Teams kein Thema bleiben.

Whiteboxing der numerischen Ergebnisse

Systeme, die in der supply chain – und auch in anderen Bereichen – abschätzig als Black Boxes bezeichnet werden, sind Systeme, die Ausgaben erzeugen, welche von den Anwendern nicht nachvollziehbar erklärt werden können. Die Quantitative Supply Chain, mit ihrem spezifischen Fokus auf eine automatisierte Datenpipeline, läuft ebenfalls Gefahr, etwas zu liefern, was supply chain Teams als „Black Boxes“ einstufen würden. Denn die finanziellen Implikationen von supply chain decisions sind für ein Unternehmen von großer Bedeutung und obwohl ein moderneres System die Situation verbessern kann, kann es möglicherweise auch Disasters hervorrufen. Nur weil Automatisierung sehr wünschenswert ist, bedeutet das nicht, dass vom supply chain Team nicht erwartet wird, ein tiefgehendes Verständnis dafür zu haben, was von der Datenpipeline, die die Initiative der Quantitative Supply Chain unterstützt, geliefert wird.

Der Begriff whiteboxing bezieht sich auf den Aufwand, der notwendig ist, um die Lösung vollständig transparent zum Vorteil von supply chain-Teams zu machen. Dieser Ansatz betont, dass keine Technologie von Natur aus transparent ist. Transparenz ist das Endergebnis eines spezifischen Aufwands, der Teil der Initiative selbst ist. Selbst eine einfache lineare Regression kann in der Praxis verblüffende Ergebnisse liefern. Abgesehen von einigen Ausnahmen haben die meisten Menschen kein intuitives Verständnis dafür, was der „erwartete“ Output des linearen Modells ist, wenn vier oder mehr Dimensionen beteiligt sind. Dennoch beinhalten supply chain Probleme oft Dutzende von Variablen, wenn nicht gar Hunderte. Somit sind selbst vereinfachte statistische Modelle de facto Black Boxes für supply chain Praktiker. Natürlich, wenn Machine-Learning-Algorithmen verwendet werden, wie es von der Quantitative Supply Chain empfohlen wird, lassen sie die Practitioners noch mehr im Dunkeln.

Obwohl der Black-Box-Effekt ein reales Problem darstellt, liegt eine realistische Lösung nicht darin, die Datenverarbeitung auf Berechnungen zu vereinfachen, die für den menschlichen Geist sofort intuitiv nachvollziehbar sind. Dieser Ansatz ist ein Rezept für extreme Ineffizienz, der alle Vorteile moderner Rechenressourcen zunichtemacht, die genutzt werden können, um die rohe Komplexität moderner supply chain zu bewältigen. Den Prozess zu vereinfachen, ist nicht die Lösung. Whiteboxing hingegen ist es.

Selbst die komplexesten supply chain Empfehlungen können für supply chain Practitioners weitgehend transparent gemacht werden, indem die inneren Berechnungen einfach in gut gewählte finanzielle Indikatoren zerlegt werden, die die wirtschaftlichen Treiber repräsentieren, welche die Empfehlung selbst unterstützen. Zum Beispiel sollte anstelle der reinen Darstellung einer schlichten Tabelle mit den zwei Spalten Produkt und Menge als vorgeschlagene Bestellung die Tabelle einige zusätzliche Spalten enthalten, die die Entscheidungsfindung unterstützen. Diese zusätzlichen Spalten können den aktuellen Lagerbestand, die Gesamtnachfrage des letzten Monats, die erwartete Lieferzeit, die erwarteten finanziellen Kosten eines Stock out (falls keine Bestellung erfolgt), die erwarteten finanziellen Kosten von Overstocks (Risiko, das mit der vorgeschlagenen Bestellung verbunden ist) usw. umfassen. Die Spalten sind so gestaltet, dass sie dem supply chain Team schnelle Plausibilitätsprüfungen der vorgeschlagenen Mengen ermöglichen. Durch die Spalten kann das Team rasch Vertrauen in das numerische Ergebnis aufbauen und auch einige Schwächen einer Lösung erkennen, die weiterer Verbesserung bedarf.

Die Erweiterung der Dashboards zu Whiteboxing-Zwecken ist teilweise eine Kunst. Es ist einfach, Millionen von Zahlen zu generieren, selbst wenn lediglich die Rechenressourcen zur Verfügung stehen, die auch auf einem Smartphone verfügbar sind. Dennoch ist es sehr schwierig, 10 Zahlen zu erzeugen, die es wert sind, täglich betrachtet zu werden. Somit besteht die Kernherausforderung darin, ein Dutzend oder weniger KPIs zu identifizieren, die ausreichen, um Licht in die empfohlenen supply chain Entscheidungen zu bringen. Gute KPIs erfordern typischerweise viel Arbeit; sie sollten keine naiven Definitionen sein, die in supply chain in der Regel irreführend sind. Zum Beispiel kann selbst eine so einfache Spalte wie der “Stückkaufpreis” äußerst irreführend sein, wenn der Lieferant zufällig Mengenrabatte anbietet, wodurch der Einkaufspreis von der bestellten Menge abhängig wird.

Strategische Dashboards

Obwohl der Fokus auf Entscheidungen im kleinen Maßstab notwendig ist – da es einer der wenigen Ansätze ist, der sich quantitativen Leistungsbewertungen unterzieht – muss die supply chain möglicherweise auch in größerem, disruptiverem Maße angepasst werden, um die Leistung auf das nächste Level zu heben. Zum Beispiel erhöht der Kauf von mehr sorgfältig ausgewählten Lagerbeständen marginal das service level. Allerdings ist das Lager irgendwann voll, und es kann keine zusätzliche Einheit gekauft werden. In dieser Situation sollte ein größeres Lager in Betracht gezogen werden. Um die Auswirkungen der Aufhebung dieser Einschränkung zu bewerten, können wir die Kapazitätsbeschränkung des Lagers aus den Berechnungen entfernen und den insgesamt finanziellen Aufschwung beim Betrieb eines beliebig großen Lagers evaluieren. Das Supply Chain Management kann dann den finanziellen Indikator überwachen, der mit den durch die Lagerkapazität auferlegten Reibungskosten verbunden ist, und entscheiden, wann es Zeit ist, eine Erweiterung der Lagerkapazität in Betracht zu ziehen.

In der Regel arbeiten supply chains auf der Basis zahlreicher Einschränkungen, die nicht täglich überarbeitet werden können. Diese Einschränkungen können unter anderem das Working Capital, die Lagerkapazität, Transportverzögerungen, Produktionsdurchsatz usw. umfassen. Jede Einschränkung ist mit einem impliziten Opportunitätskosten für die supply chain verbunden, die typischerweise in mehr Bestand, mehr Verzögerungen oder mehr Stock-outs mündet. Die Opportunitätskosten können anhand der Leistungsverbesserungen bewertet werden, die durch die Beseitigung oder Abschwächung der Einschränkung erzielt würden. Während einige dieser Simulationen als schwer umsetzbar erscheinen mögen, sind sie häufig nicht schwieriger als die Optimierung der routinemäßigen Entscheidungen, d.h. die Festlegung der Bestellmengen.

Die Quantitative Supply Chain betont, dass die mit diesen Einschränkungen verbundenen Opportunitätskosten Teil der Produktions-Datenpipeline sein sollten und in der Regel mit dedizierten Dashboards materialisiert werden müssen, die speziell dazu gedacht sind, dem Supply Chain Management bei der Entscheidung zu helfen, wann es an der Zeit ist, größere Veränderungen an der supply chain vorzunehmen. Diese Art von Dashboards wird als strategische Dashboards bezeichnet. Dieser Ansatz unterscheidet sich von der traditionellen supply chain Praxis, die ad hoc Initiativen in den Vordergrund stellt, wenn es den Anschein hat, dass die supply chain kurz davor ist, eine Betriebslimitierung zu erreichen. Tatsächlich werden die KPIs, die von strategischen Dashboards geliefert werden, täglich oder bei Bedarf sogar noch häufiger aktualisiert – genau wie der Rest der Datenpipeline. Es muss kein letzter, verzweifelter Kraftakt unternommen werden, da sie stets aktuell sind und bereit dazu, die aus einer langanhaltenden Initiative gewonnenen Erkenntnisse zu nutzen.

Die strategischen Dashboards unterstützen den Entscheidungsfindungsprozess des Supply Chain Managements. Da sie Teil der Datenpipeline sind, bleiben die KPIs stets über die aktuelle Situation des Unternehmens informiert, sobald sich der Markt schneller als üblich entwickelt. Dieser Ansatz vermeidet die herkömmlichen Fallstricke, die mit ad hoc Untersuchungen verbunden sind und die bekanntermaßen weitere Verzögerungen bei bereits überfälligen Problemen mit sich bringen. Außerdem mildert dieser Ansatz weitgehend das alternative Problem ab, nämlich übereilte strategische Entscheidungen, die sich als unrentabel erweisen – ein bedauerlicher Zustand, der von Anfang an hätte absehbar sein können.

Inspektor-Dashboards

Supply chains sind sowohl komplex als auch unberechenbar. Diese Eigenschaften machen das Debugging der Datenpipeline zu einer äußerst herausfordernden Aufgabe. Dennoch ist diese Datenpipeline das Rückgrat der Quantitative Supply Chain Initiative. Fehler in der Datenverarbeitung, oder Bugs, können überall innerhalb der Datenpipeline auftreten. Schlimmer noch, die häufigste Art des Problems ist nicht eine falsche Formel, sondern die mehrdeutige Semantik. Zum Beispiel kann zu Beginn der Pipeline die Variable stockinv den verfügbaren Bestand bezeichnen (wobei negative Werte möglich sind), während später dieselbe Variable mit der Interpretation des vorhandenen Bestands verwendet wird (wo positive Werte erwartet werden). Die mehrdeutige Interpretation der Variable stockinv kann eine Vielzahl falscher Verhaltensweisen hervorrufen, die von Systemabstürzen – die offensichtlich und daher nur mäßig schädlich sind – bis hin zu einer stillen und weitreichenden Korruption der supply chain Entscheidungen reichen.

Da supply chains nahezu immer aus einer einzigartigen Mischung von Softwarelösungen bestehen, die im Laufe der Jahre eingerichtet wurden, gibt es keine Hoffnung, Zugang zu einer „bewährten“ Softwarelösung zu erhalten, die frei von Bugs ist. Tatsächlich entstehen die meisten Probleme an den Systemgrenzen, wenn Daten aus unterschiedlichen Systemen abgeglichen werden oder gar Daten aus verschiedenen Modulen innerhalb desselben Systems in Einklang gebracht werden. Unabhängig davon, wie bewährt die Softwarelösung auch sein mag, muss das Werkzeug in der Lage sein, den Debugging-Prozess effektiv zu unterstützen, da derartige Probleme unvermeidlich auftreten.

Der Zweck der Inspektor-Dashboards besteht darin, detaillierte Ansichten für eine minutengenaue Untersuchung der supply chain Datensätze zu bieten. Allerdings sind diese Dashboards keine einfachen Drill-Downs, um die Eingangsdaten zu inspizieren. Solche Drill-Down- oder ähnliche Slice-and-Dice-Ansätze bei den Daten würden den Kern nicht treffen. Supply chains drehen sich ganz um Flüsse: Materialfluss, Zahlungsfluss usw. Einige der schwerwiegendsten Datenprobleme treten auf, wenn die Kontinuität des Flusses „logisch“ verloren geht. Zum Beispiel, wenn Waren von Lager A zu Lager B transportiert werden, könnte die Datenbank von Lager B einige Produkteinträge vermissen, was zu subtilen Datenkorruptionen führt, da Einheiten, die aus Lager A stammen, in Lager B eingehen, ohne korrekt ihrem Produkt zugeordnet zu werden. Wenn numerische Ergebnisse seltsam erscheinen, sind diese Inspektor-Dashboards die erste Anlaufstelle für den Supply Chain Scientist, um eine schnelle Stichproben-Datenuntersuchung durchzuführen.

In der Praxis bietet ein Inspektor-Dashboard einen niedrigschwelligen Einstiegspunkt, wie beispielsweise einen Produktcode oder eine SKU, und fasst alle Daten, die mit diesem Einstiegspunkt verbunden sind, in einer einzigen Ansicht zusammen. Wenn Waren an vielen Standorten fließen, wie es beispielsweise in aerospace supply chains der Fall ist, versucht das Inspektor-Dashboard in der Regel, die Trajektorien der Waren zu rekonstruieren, die möglicherweise nicht nur mehrere physische Standorte durchlaufen haben, sondern auch durch mehrere Systeme. Durch das Sammeln all dieser Daten an einem Ort wird 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 supply chain Richtlinien überein, etc.? Das Inspektor-Dashboard ist ein „Debugging“-Werkzeug, da es darauf ausgelegt ist, die Daten zusammenzuführen, die eng miteinander verknüpft sind – nicht aus IT-Sicht, sondern aus der Perspektive der supply chain.

Eines der bizarrsten Probleme, denen Lokad bei der Untersuchung von supply chain Datensätzen begegnete, war der Fall der teleportierten Teile. Das Unternehmen – in diesem Fall eine Fluggesellschaft – hatte Flugzeugteile sowohl in Mitteleuropa als auch in Südasien auf Lager. Da die Sicherheit von Flugzeugen eine absolute Voraussetzung für den Betrieb ist, führte das Unternehmen makellose Aufzeichnungen über die Lagerbewegungen all seiner Teile. Dennoch stellte das Lokad-Team mithilfe eines neu entwickelten Inspektor-Dashboards fest, dass einige Teile angeblich in nur 2 oder 3 Minuten von Asien nach Europa und umgekehrt transportiert wurden. Da Flugzeugteile mit Flugzeugen transportiert werden, hätte die Transportzeit mindestens ein Dutzend Stunden betragen müssen – sicherlich nicht Minuten. Wir vermuteten sofort ein Problem mit der Zeitzone oder einer anderen Computerzeit, doch die Zeitaufzeichnungen erwiesen sich ebenfalls als makellos. Bei weiterer Untersuchung der Daten stellte sich dann heraus, dass die teleportierten Teile tatsächlich verwendet und an den Landeorten der Flugzeuge montiert wurden, was umso verwirrender war. Indem man den supply chain Teams selbst einen Blick auf die Inspektor-Dashboards werfen ließ, wurde das Rätsel schließlich gelöst. Die teleportierten Teile waren Flugzeugräder, die aus zwei Halbrädern plus einem Reifen bestanden. Das Rad konnte demontiert werden, indem man die zwei Halbräder und den Reifen auseinander nahm. Im extremsten Fall, wenn sowohl die zwei Halbräder als auch die Reifen entfernt wurden, blieb physisch nichts mehr übrig. Somit konnte das vollständig demontierte Rad überall frei wieder montiert werden, ohne Berücksichtigung seines ursprünglichen Standorts.

Die Inspektor-Dashboards sind das Pendant auf niedriger Ebene zum Data-Health-Dashboard. Sie konzentrieren sich auf vollständig aufgeschlüsselte Daten, während Data-Health-Dashboards in der Regel eine eher übergeordnete Perspektive auf die Daten einnehmen. Außerdem sind Inspektor-Dashboards typischerweise ein integraler Bestandteil des Whiteboxing-Efforts. Wenn man mit einer scheinbar rätselhaften Empfehlung konfrontiert wird, müssen supply chain Practitioners 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 in der Regel genau zu diesem Zweck angepasst, indem viele Zwischenergebnisse einbezogen werden, die zur Berechnung der endgültigen Empfehlung beitragen.