Projektleistungen

Das Ziel der quantitativen Logistik ist, umsetzbare Entscheidungen zu liefern. Das Paradebeispiel solcher Entscheidungen sind Mengen für Bestellungen. Weiter unten erklären wir die spezifische Form und die Lieferung solcher Entscheidungen. Klare Erwartungen bezüglich der Leistungen zu schaffen, ist ein wichtiger Schritt auf der Reise, die die quantitative Logistik darstellt. Außerdem sind die optimierten numerischen Ergebnisse nicht die einzige erwünschte Ausgabe: einige der Ausgaben, vor Überwachung der Datenintegrität und KPIs für das Management sollten die Leistungen auch einschließen. In der Praxis hängen die Leistungen des quantitativen Logistikprojekts von der Flexibilität der Softwarelösung ab, auf der das Projekt läuft. Dennoch werden sie vorrangig von ihrem Ziel definiert, das von der benutzten Technik unabhängig ist.

Skripte als Leistungen

Die quantitative Logistik konzentriert sich auf komplett automatisierte Datenpipelines. Dies bedeutet nicht, dass das Software-Setup autonom läuft. Selbstverständlich ist ein hoher Grad genauer Überwachung immer wünschenswert, wenn es um eine Lieferkette bedeutenden Ausmaßes geht. Dennoch wird erwartet, dass die Datenpipeline komplett automatisiert wird, sodass kein einziger Schritt darin von manuellen Eingriffen abhängt. So wie im Manifest erläutert, lassen sich Lösungen, die bei der Datenverarbeitung von Lieferketten auf manuelle Eingriffe zurückgreifen, in der Praxis nicht skalieren.

Als direkte Folge dieser Erkenntnis bestehen die Leistungen bei Lieferkettenprojekten stets aus einer Software. Dies bedeutet jedoch nicht, dass das Team alles erneut implementieren muss: eine für die quantitative Logistik spezifische Softwarelösung bietet die Möglichkeit, sich strikt auf die relevanten Aspekte der Herausforderungen bei Lieferketten zu konzentrieren. Es wird erwartet, dass alle damit verbundenen technischen Aufgaben im Hintergrund, wie etwa die Nutzung -verteilter Rechenressourcen, die innerhalb von einer Cloud-Computing-Plattform automatisch zugeteilt werden, abstrahiert werden können. Das Team muss sich nicht um solche Dinge kümmern, da erwartet wird, dass diese Aspekte vom ¬Tool selbst übernommen werden.

Die Projektleistungen werden in Form von Skripten materialisiert, die gewöhnlich in einer Programmiersprache geschrieben sind, die die Anforderungen der Lieferkette bei hoher Produktivität erfüllen kann. Der Begriff „Skript“ wird hier dem Begriff „Quellcode“ vorgezogen, doch beide Begriffe sind eng miteinander verbunden: ein „Skript“ steht für die Idee einer hohen Abstraktion und den Fokus auf die eigentliche Aufgabe, während sich der „Quellcode“ auf eine tiefere Ebene konzentriert, die vielmehr versucht, die Rechenhardware genau widerzuspiegeln. Für die quantitative Logistik ist selbstverständlich die Perspektive der Lieferkette von größerer Bedeutung und die Rechenhardware stellt einen zweitrangigen technischen Aspekt dar.

Im letzten Jahrzehnt hat der Erfolg von WYSIWYG (Echtbilddarstellung) Benutzeroberflächen viele Anbieter von Logistiksoftware dazu geführt, diesen Ansatz mit einer WYSIWYG-Lösung für die Lieferkettenplanung und -Optimierung nachzuahmen. Doch die Lektion aus dem praktisch systematischen Versagen solcher Oberflächen ist, dass Lieferketten komplex sind und es daher nötig ist Programmiertools nicht außer Acht zu lassen. Unserer Erfahrung nach ist es bestenfalls eine Wahnvorstellung zu erwarten, dass ein Drag-and-Drop-Tool in der Lage ist, die komplexen nichtlinearen Verhältnisse von etwa überlappenden MOQs (Mindestbestellmengen) darzustellen. Die Ausdrucksfähigkeit der Programmiersprache ist erforderlich, da ansonsten nicht einmal die eigentliche Herausforderung der Lieferkette im Tool ausgedrückt werden kann. Natürlich sind Skripte, aus der Sicht der des Endnutzers, nicht, was Fachkräfte der Lieferkette als greifbare Leistung des Lieferkettenprojekts erwarten würden. Die Interaktion findet mit Dashboards statt, die konsolidierte KPIs und Tabellen enthalten, in denen die vorgeschlagenen Entscheidungen vorkommen. Doch diese Dashboards sind kurzlebig und praktisch nur als Einweg-Dashboards zu benutzen. Sie werden lediglich durch die Ausführung des Skripts auf den relevanten Logistikdaten erhalten. Da die Unterscheidung etwas subtil ist, ist es von Bedeutung, Skripte, die die tatsächliche Leistung darstellen, nicht mit seinen numerischen Ausdrücken, also was man als Endnutzer einer Lösung sieht, zu verwechseln.

Datenintegritäts-Dashboards

Bevor man sich überhaupt überlegt, optimierte Entscheidungen zur Lieferkette zu liefern, muss die semantische und numerische Korrektheit der Daten, die vom System, auf dem das Projekt der quantitativen Logistik läuft, überprüft werden. Das Ziel des Beobachtungs-Dashboards der Datenintegrität, oder einfach Datenintegritäts-Dashboards, ist, ein hohes Maß an Vertrauen auf die Korrektheit der Daten zu schaffen, was eine wesentliche Anforderung für die Genauigkeit aller numerischen Ergebnisse der Lösung ist. Diese Dashboards helfen auch dem Lieferkettenteam, die Qualität der vorhandenen Daten zu verbessern.

Numerische Fehler sind recht klar: die aus dem ERP exportierte CSV-Datei zeigt, dass für Produkt ABC 42 Einheiten im Bestand vorhanden sind, während die ERP Web-Konsole nur 13 Einheiten Bestand anzeigt. Hier fällt auf, dass Zahlen, die gleich sein sollten, abweichen. Das Datenintegritäts-Dashboard behandelt dieses Problem, indem es überprüft, dass die Datenaggregate innerhalb der erwarteten numerischen Bereiche liegen.

Semantische Fehler sind subtiler und in der Praxis schwerer festzustellen. In der Phase der Datenaufbereitung wird die meiste Arbeit der Feststellung und Lösung aller semantischen Fehler gewidmet. Zum Beispiel: Womöglich wird das Feld stockinv im ERP als Warenbestand dokumentiert. Daher geht das Lieferkettenteam davon aus, dass diese Menge nie negativ sein kann, da, wenn sich diese Einheiten physisch in den Regalen befinden, diese Menge logischerweise positiv sein muss. Doch die Dokumentation des ERP kann auch etwas irreführend sein und diese Menge sollte passender als verfügbarer Bestand bezeichnet werden, denn, wenn bei einem Fehlbestand durch einen Kunden ein Auftragsrückstand entsteht, kann die Menge negativ werden, um auf eine bestimmte Anzahl an Einheiten, die ein Kunde vorbestellt hat, zu weisen. Dieser Fall veranschaulicht einen semantischen Fehler: Die Zahl stimmt nicht per se nicht, sondern das am Verständnis der geschätzten Zahl. In der Praxis kann die semantische Annäherung zu vielen inkonsistenten Verhaltensweisen führen, was zu ständigen Friktionskosten in der Lieferkette führen kann.

Datenintegritäts-Dashboards konsolidieren Zahlen, wodurch das Unternehmen direkt entscheiden kann, ob die Daten gut genug zuverlässig sind oder nicht. Da die Lösung täglich im Zusammenhang mit der Produktion im Einsatz sein wird, ist es von höchster Bedeutung, dass wichtige Datenprobleme durch eine praktisch sofortige Überprüfung festgestellt werden können. Andernfalls kann die Lieferkette tagelang, oder gar wochenlang auf fehlerhaften Daten laufen. Was dies betrifft, funktioniert das Datenintegritäts-Dashboard wie eine Ampel: bei grün geht es weiter, wie rot wird angehalten.

Außerdem kommt bei einer Lieferkette beträchtlicher Größe immer eine gewisse Anzahl beschädigter oder anderweitig fehlerhafte Daten vor. Diese Daten kommen durch fehlerhafte manuelle Angaben oder durch seltene Grenzfälle im eigenen Unternehmenssystem zustande. In der Praxis, kann man nicht davon ausgehen, dass die Daten der Lieferkette zu 100 % genau sind. Stattdessen muss sichergestellt werden, dass die Daten genau genug sind, um die Friktionskosten, die durch solche Fehler entstehen, praktisch unbedeutend zu halten.

Daher wird von Datenintegritäts-Dashboards erwartet, dass sie Statistiken der erkannten Datenfehler sammeln. Diese Statistiken sind helfen sicherzustellen, dass man sich auf die Daten verlassen kann. Hierfür muss der Supply Chain Scientist gewöhnlich gut gewählte Warngrenzwerte erstellen, die normalerweise die Lösung zum Halt bringen. Dennoch müssen die Grenzwerte gut gewählt werden, da bei zu niedrigen Grenzwerten die Lösung unbrauchbar ist, da sie wegen „gefundener Datenproblemen“ angehalten wird. Bei zu hohen Grenzwerten hingegen werden die Friktionskosten, die durch Datenfehler entstehen, zu hoch und übertreffen die Vorteile des gesamten Projekts.

Abgesehen von der Rot-Grün-Signalisierung sollen Datenintegritäts-Dashboards auch einen priorisierten Einblick in die Bemühungen der Datenverbesserung bieten. So können viele Datenpunkte falsch sein, aber keine Folgen mit sich bringen. Beispielsweise ist es unwichtig, ob der Kaufpreis eines Produkts falsch ist, wenn die Marktnachfrage für dieses Produkt seit Jahren verschwunden ist, da keine weiteren Bestellungen für dieses Produkt aufgegeben werden.

Die quantitative Logistik unterstreicht die Priorisierung einer verfeinerten Lösung von Datenfehlern, die eine bedeutende Menge manueller Arbeit bedürfen kann, im Zusammenhang mit den erwarteten finanziellen Auswirkungen des eigentlichen Fehlers bezüglich der Arbeitskosten, die mit der Behebung des Fehlers zusammenhängen. In der Tat variieren die Kosten, die durch die Behebung eines einzelnen falschen Datenpunks entstehen, enorm je nach Fall, weshalb diese auch bei der vorgeschlagenen Priorisierung berücksichtigt werden müssen. Zuletzt kann der Datenverbesserungsprozess angehalten werden, wenn die Kosten der Problembehebung höher geschätzt werden, als die Kosten der Lieferkette, die durch den Fehler entstehen.

Dashboards für priorisierte Entscheidungen

Wie bereits gesehen, können nur Entscheidungen bezüglich der Lieferkette aus einer quantitativen Perspektive bewertet werden. Daher ist es nicht verwunderlich, dass eine der Schlüsselleistung eines quantitativen Logistikprojekts ein Dashboard ist, das die Entscheidungen, die als finale numerische Ergebnisse der gesamten Datenpipeline erhalten werden, konsolidiert. Ein solches Dashboard kann auch lediglich eine Tabelle sein, die für jedes Produkt, die genaue Liefermenge zur sofortigen Bestellung auflistet. Wenn MOQs (Mindestbestellmengen), oder andere Bestellbedingungen bestehen, können die vorgeschlagenen Bestellmengen auch meistens gleich null sein, bis die nötigen Schwellen erreicht werden.

Der Einfachheit halber gehen wir davon aus, dass die numerischen Ergebnisse in einem Dashboard gesammelt werden, was eine bestimmte Form einer Benutzeroberfläche darstellt. Doch das Dashboard selbst ist nur eine Option, die relevant sein kann, oder auch nicht. In der Praxis wird erwartet, dass die Software, auf der das quantitative Logistikprojekt läuft, sehr flexible ist, was die Programmierung betrifft, sodass sie viele Möglichkeiten bietet, diese Ergebnisse in verschiedenen Datenformaten zu liefern. So können beispielsweise numerische Ergebnisse in Flachtextdateien konsolidiert werden, die zum automatischen Import in das primäre ERP gedacht sind, in dem die Aktiva des Unternehmens verwaltet werden.

Während das Format der Entscheidungen stark von der konkreten Aufgabe der Lieferkette abhängt, bedürfen die meisten Aufgabe einer Priorisierung dieser Entscheidungen. So kann die Berechnung der vorgeschlagenen Mengen für eine Bestellung über eine Prioritätenliste der Einheiten, die gekauft werden sollen, aufgeschlüsselt werden. Hier werden die rentableren Einheiten als erstes gelistet. Da Bestand auch mit geringen Renditen verbunden ist, wird die zweite Einheit, die vom demselben Produkt erworben wird, einer verminderten Fraktion der Marktnachfrage zugeordnet. Daher kann es sein, dass die zweite Einheit für dieses Produkt nicht den zweiten Eintrag der allgemeinen Liste darstellt. Stattdessen kann die Einheit mit der zweithöchsten Rendite einem anderen Produkt entsprechen, usw. Die Prioritätenliste der zu erwerbenden Einheiten nimmt konzeptuell kein Ende, da es immer möglich ist, eine weitere Einheit zu kaufen. Da die Marktnachfrage jedoch endlich ist, würden alle Einheiten ab einem gewissen Punkt toten Bestand darstellen. Aus dieser Prioritätenliste erhält man die finalen Mengen für den Einkauf durch die Einführung eines Stopp-Kriteriums und die Summe der Mengen pro Produkt. In der Praxis erschweren nichtlineare Bedingungen diese Aufgabe weiter, doch der Einfachheit halber, lassen wir diese Bedingungen zu diesem Zeitpunkt noch aus der Diskussion.

Die Priorisierung von Entscheidungen stellt einen sehr natürlichen Vorgang aus der Sicht der quantitativen Logistik dar. Da jeder Entscheidung ein finanzielles Ergebnis, das in Euro ausgedrückt wird, zugeordnet wird, ist die Einordnung der rentabelsten oder am wenigsten rentablen Option ziemlich unkompliziert. Daher kann man von vielen, wenn nicht von allen Dashboards, die die vorgeschlagenen Entscheidungen bezüglich der Lieferkette kompilieren, erwarten, dass sie in der Praxis eine Prioritätenliste der Entscheidungen darstellen. Diese Dashboards enthalten eine Liste mit äußerst rentablen Entscheidungen an der Spitze und sehr unrentablen Entscheidungen am Ende. Alternativ, können Fachkräfte der Lieferkette die Liste kürzen, wenn die Entscheidungen nicht rentabel sind. Doch auch von der Überprüfung solcher Entscheidungen, die sich unterhalb der Rentabilitätsgrenze befinden, kann man Erkenntnisse gewinnen, auch wenn das Unternehmen selbstverständlich diesen unrentablen Entscheidungen nicht nachgeht.

Zur Lieferung dieser Art entscheidungsbasierter Dashboards, muss die Softwarelösung, die die quantitative Logistik unterstützt, eine ungeheure Anzahl möglicher Entscheidungen numerisch untersuchen. So sollte die Lösung beispielsweise die finanziellen Auswirkungen vom Kauf jeder einzelnen Einheit jedes einzelnen Produkts in jeder einzelnen Niederlassung berücksichtigen können. Daher ist es nicht verwunderlich, dass dieser Vorgang einer bedeutenden Menge an Rechenressourcen bedarf. Doch heutzutage schafft Hardware zum Glück sogar die größten weltweiten Lieferketten. Geht man davon aus, dass die Architektur der Softwarelösung, auf der alles läuft, der quantitativen Logistik angepasst ist, sollte die Skalierbarkeit der Datenverarbeitung kein Thema sein, was die Lieferkettenteams betrifft.

White-Box für numerische Ergebnisse

Systeme, die in der Logistik oder in anderen Bereichen, spöttisch als Black Boxes bezeichnet werden, sind solche, deren Ausgaben nicht von deren Fachkräften erklärt werden können. Bei der quantitativen Logistik mit ihrem Fokus auf einer automatisierten Datenpipeline besteht auch das Risiko, die von den Fachkräften der Lieferkette genannten „Black Boxes“ zu liefern. In der Tat sind die finanziellen Zusammenhänge der Lieferkette für ein Unternehmen äußerst wichtig, und obwohl ein neueres System eine Situation verbessern kann, kann es potentiell auch zu einem Desaster führen. Dass Automatisierung besonders wünschenswert ist, bedeutet nicht, dass das Lieferkettenteam die von der Datenpipeline gelieferten Daten für das Projekt quantitativer Logistik nicht genau verstehen muss.

Der Begriff White-Boxing bezieht sich auf den Aufwand, der nötig ist, um die Lösung zum Vorteil des Lieferkettenteams von Design auf komplett transparent zu gestalten. Durch diesen Ansatz wird unterstrichen, dass keine Technik von Design auf transparent ist. Vielmehr ist Transparenz das Endergebnis eines bestimmten Aufwands, das auch als Teil des Projekts gilt. Sogar eine einfache lineare Regression kann erstaunliche Ergebnisse in der Praxis erzeugen. Doch abgesehen von einigen wenigen Personen, verstehen die meisten nicht intuitiv, welche Ausgabe bei einem linearen Modell „erwartet“ wird, wenn 4 oder mehr Dimensionen im Spiel sind. Und bei Lieferkettenproblemen sind oft dutzende Variablen, wenn nicht sogar hunderte, im Spiel. Daher sind sogar vereinfachende statistische Modelle de facto Black-Boxes für Fachkräfte der Lieferkette. Wenn noch Algorithmen für maschinelles Lernen benutzt werden, wie es von der quantitativen Logistik empfohlen wird, sind die Fachkräfte noch weiter im Unklaren.

Obwohl der Black-Box-Effekt ein tatsächliches Problem darstellt, besteht eine realistische Lösung nicht darin, die Datenverarbeitung so zu vereinfachen, dass sie sofort verständlich sind. Dieser Ansatz ist ein Rezept für extreme Ineffizienz, die die Vorteile von modernen Rechenressourcen, die zum Verständnis der Komplexität moderner Lieferketten genutzt werden können, zerstört. Die Vereinfachung des Verfahrens ist nicht Lösung, sondern White-Boxing.

Auch die komplexesten Empfehlungen für die Lieferketten können für Fachkräfte der Lieferkette bedeutend transparent gestaltet werden, indem die internen Berechnungen mit gut gewählten finanziellen Kennzahlen, die die finanziellen Treiber zur Unterstützung der eigentlichen Empfehlung darstellen, aufzuschlüsseln. Beispielsweise sollte eine Tabelle statt lediglich zwei Spalten für Produkte und die vorgeschlagene Menge für den Kauf anzuzeigen, auch einige Spalten enthalten, die zur Entscheidungsfindung beitragen. Diese zusätzlichen Spalten können den aktuellen Bestand, den Gesamtbedarf des letzten Monats, die erwartete Durchlaufzeit, die erwarteten finanziellen Kosten, die durch einen Fehlbestand entstehen würden (wenn keine Bestellung aufgegeben wird), die erwarteten finanziellen Kosten, die durch Überbestände entstehen würden (Risiko der vorgeschlagenen Bestellung), usw. Die Spalten werden eingebaut, sodass das Lieferkettenteam rasch die Plausibilitätsprüfung für die vorgeschlagenen Mengen durchführen kann. Durch die Spalten gewinnt das Team schnell Vertrauen in die numerischen Ausgaben und kann auch die Schwächen einer Lösung mit Verbesserungspotential erkennen.

Die Ausbreitung des Dashboards, um White-Boxes zu erhalten ist teilweise eine eigene Kunst. Millionen von Nummern zu erzeugen ist einfach, sogar mit weniger Rechenressourcen als die eines Smartphones. Doch die Generierung von 10 Zahlen, die es wert sind, täglich beobachtet zu werden, ist kompliziert. Daher liegt die Herausforderung darin, höchstens ein dutzend KPIs zu erkennen, die ausreichende Einblicke in die vorgeschlagenen Entscheidungen der Lieferkette ermöglichen. Gute KPIs erfordern gewöhnlich jede Menge Arbeit. Sie sollten sich nicht auf naive Definitionen beschränken, die gewöhnlich im Bereich der Lieferkette in die Irre führen. So kann schon eine simple Spalte wie „Einheitskaufpreis“ irreführend sein, wenn der Lieferant Mengenrabatte bietet, wodurch der Einheitskaufpreis von der gekauften Menge abhängen würde.

Strategische Dashboards

Während ein Fokus auf Probleme im kleinen Maßstab nötig ist - da dies eines der wenigen Ansätze ist, die quantitative Leistungsbeurteilung liefert - könnte die Lieferkette auch in bahnbrechenderen Arten angepasst werden müssen, um die Leistung deutlich zu steigern. So erhöht der Kauf mehrerer besser gewählter Bestandseinheiten den Service-Level geringfügig. Doch ab einen gewissen Punkt ist das Lager voll, sodass keine weiteren Einheiten gekauft werden können. In solchen Fällen, sollte ein größeres Lager in Erwägung gezogen werden. Um die Auswirkungen zu beurteilen, wenn diese Beschränkung nicht bestehen würde, könnte die Bedingung der Lagerkapazität von den Berechnungen entfernt werden, sodass die Gesamtvorteile eine beliebig großen Lagers bewerten werden. Das Lieferkettenmanagement kann somit den finanziellen Indikator, der den Friktionskosten zugeordnet ist, im Auge behalten und entscheiden, wann es an der Zeit ist, die Lagerkapazität zu erhöhen.

Gewöhnlich hängen mit den Lieferketten viele Bedingungen zusammen, die nicht täglich überprüft werden können. Diese Bedingungen können sich auf das Umlaufkapital, die Lagerkapazität, Versandverzögerungen, Produktionsdurch, usw. beziehen. Jeder Bedingung werden implizite Opportunitätskosten der Lieferkette zugeordnet, was gewöhnlich mehr Bestand, mehr Verzögerungen oder mehr Fehlbestände mit sich bringt. Opportunitätskosten können über die Leistungssteigerung bewertet werden, die man erhalten könnte, wenn man die eigentliche Bedingung entfernen oder schwächen könnte. Obwohl manche dieser Simulationen schwer umsetzbar sind, sind sie oft schon so einfach wie die Optimierung der Routineentscheidung zu erreichen, z.B. die Festlegung von Bestellmengen.

Die quantitative Logistik unterstreicht, dass Opportunitätskosten, die mit diesen Bedingungen zusammenhängen, Teil der Datenpipeline der Produktion sein sollten und dementsprechend in gezielten Dashboards materialisiert werden müssen, die dem Lieferkettenmanagen ermöglichen zu entscheiden, wann es Zeit für größere Änderungen in ihrer Lieferkette ist. Diese Art von Dashboards wird als strategische Dashboards bezeichnet. Der Ansatz unterscheidet sich von den herkömmlichen Logistikmethoden, die ad hoc Projekte bevorzugen, wenn man das Gefühl hat, dass die Lieferkette an ihre Betriebsgrenzen kommt. So werden die KPIs von strategischen Dashboards täglich, oder gar öfters, falls nötig, aktualisiert, sowie auch die restliche Datenpipeline. Hier müssen keine Bemühungen in der allerletzten Minute unternommen werden, weil man auf dem Laufenden ist und von den Einblicken eines langlebigen Projekts profitieren kann.

Strategische Dashboards unterstützen den Prozess der Entscheidungsfindung im Lieferkettenmanagement. Da sie ein Teil der Datenpipeline sind, stellen die KPIs immer den aktuellen Zustand des Unternehmens dar, auch wenn der Markt sich rascher als sonst verändert. Dieser Ansatz verhindert die Fallstricke, die mit ad hoc Untersuchungen einhergehen, die ausnahmslos weitere Verzögerungen zu bereits überfälligen Problemen erzeugen. Dieser Ansatz lindert auch größtenteils alternative Probleme, was eine voreilige strategische Entscheidung darstellt, die sich als unrentabel entpuppt – ein bedauerlicher Zustand, der vom Anfang an hätte vorhergesagt werden können.

Kontrolleur-Dashboards

Lieferketten sind sowohl komplex als auch schwankend. Diese Eigenschaften machen die Fehlersuche in der Datenpipeline zu einer herausfordernden Aufgabe. Doch gerade diese Datenpipeline stellt das Rückgrat des quantitativen Logistikprojekts dar. Fehler bei der Datenverarbeitung oder Bugs können überall in der Datenpipeline auftreten. Noch schlimmer ist, dass die häufigsten Fehlerarten nicht falsche Formeln sind, sondern mehrdeutige Semantik. Beispielsweise kann sich die Variable stockinv am Anfang der Pipeline auf die Bestandsverfügbarkeit beziehen (wobei auch negative Werte auftreten können), während dieselbe Variable zu einem späteren Zeitpunkt als Warenbestand interpretiert wird (wobei Werte positiv sein sollen). Diese mehrdeutige Interpretation der Variable stockinv kann zu falschen Verhaltensweisen von Systemabstürzen – die offensichtlich, doch nur mäßig schädlich sind – zu einer stillen umfangreichen Beschädigung der Entscheidungen bezüglich der Lieferkette führen.

Da Lieferketten fast immer als einzigartiger Mix aus Softwarelösungen konzipiert sind, die durch die Jahre hinweg eingerichtet werden, besteht keine Hoffnung, eine „bewährte“ Softwarelösung ohne Bugs zu erhalten. In der Tat treten die meisten Probleme erst auf, wenn das System seine Grenzen bei der Abstimmung von Daten aus verschiedenen Systeme erreicht, oder gar von Daten aus verschiedenen Modulen desselben Systems. Daher muss das Tool in der Lage sein, die Fehlersuche passend zu unterstützen, unabhängig davon, wie erprobt die Softwarelösung ist, da solche Arten von Problemen auftreten.

Ziel des Kontrolleur-Dashboards ist es, feinkörnige Ansichten für eine Minutenkontrolle des Datasets der Lieferkette zu liefern. Dennoch sind diese Dashboards nicht einfache Drilldowns zur Kontrolle der Tabellen der Eingabedaten. Solche Drilldowns, oder ähnliche Slice-and-Dice-Ansätze für Daten würden das Ziel verfehlen. Bei den Lieferketten dreht sich alles um Flüsse und Ströme: Materialflüsse, Zahlungsströme, usw. Einige der wichtigsten Datenprobleme treten auf, wenn die Kontinuität der Flüsse und Ströme „logisch„ verloren geht. Beispielsweise kann Lager B einige Produkteinträge vermissen, wenn Ware von Lager A nach Lager B verschoben wird- Hierdurch kann eine leichte Datenbeschädigung auftreten, da Einheiten aus Lager A im Lager B erhalten werden, ohne ihrem Produkt richtig zugeordnet zu werden. Wenn die numerischen Ergebnissen etwas seltsam erscheinen, ermöglichen diese Kontrolleur-Dashboards den Supply Chain Scientist ein keines Beispiel zur Untersuchung der Daten zu erhalten.

In der Praxis bietet ein Kontrolleur-Dashboard einen niedrigen Ausgangspunkt, wie etwa einen Produktcode oder eine SKU zu nutzen und es konsolidiert auf einem Blick alle Daten, die einen Bezug zu diesem Eingabepunkt haben. Wenn sich Ware zwischen mehreren Niederlassungen bewegt, wie es bei Lieferketten in der Luft- und Raumfahrt der Fall ist, versucht das Kontrolleur-Dashboard gewöhnlich die Bewegungen der Ware nachzuvollziehen, die abgesehen von an mehreren physischen Orten auch in verschiedenen Systemen erfasst wurde. Die Sammlung all dieser Daten an einem Ort ermöglicht dem Supply Chain Scientist zu bewerten, ob die Daten sinnvoll sind: Lässt sich feststellen, woher die Ware, die versandt wird, stammt? Sind Lagerbewegungen im Einklang mit offiziellen Lieferkettenpolitiken? Usw. Das Kontrolleur-Dashboard ist ein Tool zur „Fehlersuche“ da es zur Sammlung von Daten beiträgt, die aus der Perspektive der Lieferkette eng verbunden sind, auch wenn sie es IT-technisch nicht sind.


Die Kontrolleur-Dashboards stellen eine tiefere Ebene der Datenintegritäts-Dashboards dar. Sie konzentrieren sich auf komplett disaggregierte Daten, während Datenintegritäts-Dashboards die Daten aus einer höheren Perspektive betrachten. Außerdem stellen Kontrolleur-Dashboards gewöhnlich einen wesentlichen Teil der Bemühungen dar, White-Boxes zu erhalten. Wenn Fachkräfte der Lieferkette einer seltsam wirkenden Empfehlungen gegenüberstehen, müssen sie genauer auf die SKU oder ein Produkt schauen, um herausfinden zu können, ob die empfohlene Entscheidung vernünftig ist, oder nicht. Kontrolleur-Dashboards sind gewöhnlich gerade hierfür angepasst, da sie viele Zwischenergebnisse einschließen, die zur Berechnung der finalen Empfehlungen beitragen.