Alles täglich aktualisieren

Joannes Vermorel

Lokads Supply Chain-Praxis besteht darin, alle Datenpipelines - einschließlich Prognosen - mindestens einmal täglich zu aktualisieren, auch bei monatlichen oder vierteljährlichen Berechnungen. Für viele Praktiker mag diese Praxis kontraintuitiv erscheinen. Warum vierteljährliche Prognosen öfter als einmal pro Quartal aktualisieren? Was ist mit numerischen Instabilitäten? Was ist mit der damit verbundenen Reibung? Dies widerspricht den meisten etablierten Supply Chain-Praktiken, insbesondere denen von Unternehmen, die einen S&OP Prozess implementiert haben. Doch ein Jahrzehnt Erfahrung hat uns gelehrt, dass das Nichtbefolgen dieser “Alles aktualisieren” Praxis das Rezept für eine endlose Reihe von Produktionsproblemen ist. Im Kern muss dieses Problem frontal und tiefgreifend durch ein versioniertes zustandsloses Design der Software, die für die vorhersagende Optimierung der Supply Chain verantwortlich ist, angegangen werden. Dieser Punkt wird im Folgenden genauer erläutert, aber beginnen wir damit, das Problem selbst genauer zu betrachten.

In der Welt der Unternehmenssoftware treten Probleme / Störungen / Fehler / Probleme ständig auf. Dies gilt insbesondere für Supply Chains, bei denen die Anwendungslandschaft in der Regel eine willkürliche Sammlung von Softwarekomponenten (ERP, EDI, MRP, WMS, OMS, E-Commerce usw.) ist, die im Laufe von Jahrzehnten zusammengefügt wurden: Jede Anwendung ist eine potenzielle Quelle von Problemen, da sie letztendlich mit vielen anderen Anwendungen interagiert¹. Jede Änderung, die an einer dieser Anwendungen vorgenommen wird, birgt die Gefahr, etwas an anderer Stelle zu zerstören, d.h. nicht nur die Anwendung selbst zu zerstören. Nicht alle Unternehmen sind gleich, wenn es um das Management ihrer Anwendungslandschaft geht, aber ab einer Größe von 1000 Mitarbeitern haben selbst die am besten geführten Unternehmen mehr als eine softwaregesteuerte Supply Chain “Störung” pro Tag.

Daher sehen sich größere Unternehmen mit einem endlosen Strom von Softwareproblemen konfrontiert, die gelöst werden müssen. Die Verantwortung für die Behebung solcher Probleme liegt bei der IT-Abteilung, einem Drittanbieter, einem operativen Team, einem Lieferanten usw. Sobald jedoch eines dieser Probleme “angeblich” behoben ist, sind 5 bis 10 Durchläufe erforderlich², um sicherzustellen, dass das Problem wirklich behoben ist. Tatsächlich handelt es sich bei den meisten Problemen um Randfälle, die sich zu einem bestimmten Zeitpunkt zeigen können oder auch nicht. Daher kann ein Problem als gelöst erscheinen, weil es nach Anwendung einer Art Lösung verschwunden ist, dies ist jedoch möglicherweise noch nicht der Fall. Supply Chains sind komplexe Systeme, die viele voneinander abhängige Teile umfassen, von denen einige nicht einmal vollständig unter der Kontrolle des Unternehmens stehen (d.h. EDI mit Lieferanten). Menschen scheitern routinemäßig daran, endgültige Lösungen zu liefern, nicht weil sie faul oder inkompetent sind, sondern einfach aufgrund der unvermeidlichen Umgebungscomplexität.

Als Folge dauert es bei einem täglichen Durchlauf nach einem Produktionsvorfall 5 bis 10 Tage, um die Stabilität wiederherzustellen. Wenn der Daten-Pipeline monatlich ausgeführt wird, dauert der gleiche Auflösungsprozess 5 bis 10 Monate. Es kommt auf die Anzahl der Durchläufe an, nicht auf die reine Zeit. Es sind mehrere Durchläufe erforderlich, um sicherzustellen, dass der Sonderfall behoben ist. Als beispielhafte Evidenz hatten wir bei Lokad einen Jobplanungsfehler im Zusammenhang mit der Zeitumstellung, der zwei Jahre dauerte, um behoben zu werden, genau weil die Bedingungen, die das Problem auslösten, so selten waren - zweimal im Jahr pro Zeitzone. Während bestimmte Probleme wie Zeitumstellungen von Natur aus selten sind, können die meisten Probleme durch einfaches Erhöhen der Häufigkeit der “Durchläufe” reproduziert werden.

Die ständige Herausforderung der end-to-end Daten-Pipelines ist der einzige Weg, um sicherzustellen, dass Probleme innerhalb eines angemessenen Zeitrahmens behoben werden. Eine seltenere Ausführung führt zwangsläufig dazu, dass der Zustand des Systems standardmäßig “defekt” ist. Unternehmen, die intermittierende Daten-Pipelines betreiben - beispielsweise vierteljährliche - enden zwangsläufig mit großen Bürokratien, die nur dazu da sind, die Pipeline einmal pro Quartal wieder zum Leben zu erwecken. Schlimmer noch, das Ganze ist in der Regel so dysfunktional, dass die Bürokratie den Großteil des Quartals damit verbringt, die “Aktualisierung” des nächsten Quartals sicherzustellen. Im Gegensatz dazu benötigen Echtzeit-Pipelines wie die Bereitstellung von Webseiten für die Unternehmenswebsite kaum jemanden, der daran arbeitet.

Bei Lokad haben wir uns vor mehr als einem Jahrzehnt aus purer Notwendigkeit für tägliche Aktualisierungen (oder mehr) entschieden. Seitdem haben wir keine andere Möglichkeit gefunden, eine angemessene Servicequalität aus Sicht der Supply Chain zu erreichen. Es gibt wahrscheinlich keine andere Möglichkeit. Predictive Analytics sind komplex und daher anfällig für alle Arten von “Fehlern”. Tägliche Aktualisierungen stellen sicher, dass Probleme zeitnah behoben werden, anstatt für immer in der Schwebe zu bleiben³. In dieser Hinsicht sind unsere Erkenntnisse alles andere als originell. Netflix hat das ganze Feld des Chaos Engineering auf ähnliche Weise pioniert: Um ein robustes System zu entwickeln, muss Stress angewendet werden; ohne Stress findet Robustheit nie Eingang in das Engineering-Mindset. Die meisten seriösen Softwareunternehmen - insbesondere die GAFAM - haben noch strengere Varianten dieses Ansatzes übernommen.

Darüber hinaus führen seltenere Aktualisierungen der Daten-Pipeline nicht nur zu Produktionsproblemen aus Sicht der Supply Chain, sondern betonen auch eine ganze Reihe von schlechten Praktiken und schlechten Technologien.

Wenn Prognosen selten aktualisiert werden, ist es äußerst verlockend, sie manuell anzupassen. Tatsächlich bleiben Prognosen die meiste Zeit absichtlich stehen, genau aufgrund der seltenen Aktualisierung. Daher kann der Nachfragespezialist allein durch einen Blick auf die Daten von gestern eine Prognose verbessern, die vor drei Wochen vom System erstellt wurde. Doch diese Arbeit des Nachfragespezialisten liefert dem Unternehmen keinen dauerhaften Mehrwert: Sie ist nicht wertsteigernd. Wenn die numerischen Rezepte, die die Prognosen generieren, so schlecht sind, dass sie manuelle Anpassungen benötigen, müssen diese numerischen Rezepte behoben werden. Wenn der Softwareanbieter die Korrektur nicht liefern kann, dann benötigt das Unternehmen einen besseren Anbieter.

Häufige Aktualisierungen der Prognosen verschärfen die numerischen Instabilitäten der zugrunde liegenden statistischen Modelle, d.h. führen zu zwei unterschiedlichen Ergebnissen bei zweifacher Durchführung der Prognose. Das ist gut⁴. Instabile numerische Modelle sind schädlich für die Supply Chain aufgrund von Ratscheneffekten: Sobald eine Produktions- oder Bestellposition übergeben ist, ist das Unternehmen mit den Konsequenzen dieser Bestellung konfrontiert. Wenn eine Bestellung übergeben wird, sollte dies aus besseren Gründen geschehen als aufgrund numerischer Instabilität. Je früher das Unternehmen instabile numerische Rezepte aus seiner Supply Chain-Praxis eliminiert, desto besser. Der Versuch, das zugrunde liegende Problem durch Reduzierung der Häufigkeit der Prognoseaktualisierung zu verschleiern, ist unsinnig: Numerische Instabilität verschwindet nicht, nur weil das Unternehmen beschließt, nicht mehr darauf zu schauen. Wenn die numerischen Rezepte so schlecht sind, dass sie keine starke Konsistenz⁵ von einem Tag zum nächsten aufrechterhalten können, werden bessere numerische Rezepte benötigt. Auch hier, wenn ein Softwareanbieter mitten im Problem steckt und keine umfassende Lösung liefern kann, dann benötigt das Unternehmen ebenfalls einen besseren Anbieter.

Tägliche Aktualisierungen aller Daten-Pipelines mögen in Bezug auf die Rechenressourcen extravagant erscheinen. Angesichts moderner Hardware und einer ordnungsgemäß gestalteten Software ist dieser Aufwand jedoch gering, selbst wenn anspruchsvolle Rezepte wie die probabilistische Prognose⁶ berücksichtigt werden. Darüber hinaus sehen sich Supply Chains regelmäßig außergewöhnlichen Bedingungen gegenüber, die eine sofortige groß angelegte Korrektur erfordern. Wenn das Unternehmen nicht in der Lage ist, alle seine Supply Chain-Zahlen in weniger als 60 Minuten zu aktualisieren, weil es dies tun muss, bleiben Notfälle garantiert gelegentlich ungelöst und verursachen Chaos vor Ort. Die Regel der 5 bis 10 Runden - zuvor diskutiert - gilt immer noch: Sobald eine Lösung gefunden ist, sind mehrere Durchläufe - möglicherweise mit unterschiedlichen Einstellungen - erforderlich, um das Vertrauen zu gewinnen, dass diese Notfallkorrektur funktioniert. Wenn die Daten-Pipeline also zu teuer ist, um “nach Belieben” ausgeführt zu werden, wird die Produktion als Testgelände genutzt und es wird Chaos entstehen.

Aus produktiver Sicht beseitigen tägliche Aktualisierungen die Toleranz gegenüber schlechten Setups, die ständig schlechte Ergebnisse erzeugen. Wieder einmal ist das eine gute Sache. Es gibt keinen Grund, tolerant gegenüber einem numerischen Rezept zu sein, das Müll erzeugt. Die Bedarfsplanung ist keine Art von künstlerischer Kreation, die sich der numerischen Analyse widersetzt. Dysfunktionale numerische Rezepte sollten als Softwarefehler behandelt und entsprechend behoben werden. Die umfassende Behebung erfordert jedoch oft viel mehr Nachdenken als die Verwendung einer ad hoc-manuellen Übersteuerung. Die meisten Unternehmen fragen sich, warum ihre Supply-Chain-Teams immer wieder zu ihren Tabellenkalkulationen zurückkehren. Es stellt sich heraus, dass die Tabellenkalkulationen häufig der einzige Ort sind, an dem die numerischen Korrekturen - die bereits Teil der Systeme sein sollten - tatsächlich implementiert werden, genau weil das schnelle Iterieren über eine Tabellenkalkulation kein Problem darstellt (im Gegensatz zum schnellen Iterieren über das zugrunde liegende Unternehmenssystem).

Tägliche (oder häufigere) Aktualisierungen sind jedoch nur ein Betriebsaspekt des Problems. In Bezug auf die Softwareentwicklung muss dieser Ansatz durch eine erste Schlüsselkomponente ergänzt werden: Zustandslosigkeit. Eine Datenpipeline sollte keine vorkalkulierten Daten verwenden und jedes Mal von den rohen Transaktionsdaten ausgehen. Tatsächlich besteht die Wahrscheinlichkeit, dass jeder Fehler oder jede Störung die vorkalkulierten Daten verfälscht und das Unternehmen für eine unbestimmte Zeit zurückhält: Die Logik kann behoben werden, aber die fehlerhaften Daten bleiben bestehen. Die Lösung ist einfach: Die Datenpipeline sollte keinen Zustand haben, d.h. keine vorkalkulierten Daten jeglicher Art. Ein Neustart stellt sicher, dass alle Korrekturen sofort optimal genutzt werden.

Versionsverwaltung, ein weiteres Prinzip der Softwareentwicklung und die zweite interessante Komponente, ergänzt die Zustandslosigkeit des Systems: genauer gesagt, die Daten-Versionsverwaltung. Wenn die Datenpipeline selbst keinen Zustand hat, dann sollte es ausreichen, die Logik der Pipeline - die als versionierter Quellcode existiert - und die Eingangsdaten zu kombinieren, um jedes Problem, das während der Ausführung der Pipeline auftritt, genau reproduzieren zu können. Mit anderen Worten, es macht Probleme reproduzierbar. Dies erfordert jedoch, eine exakte Kopie der Daten zu erhalten, wie sie zum Zeitpunkt der Ausführung der Datenpipeline vorlagen. Mit anderen Worten, die Daten sollten zusammen mit dem Code versioniert werden. Die Versionsverwaltung der Daten stellt sicher, dass Korrekturen unter genau denselben Bedingungen getestet werden können, die das ursprüngliche Problem ausgelöst haben.

Lokad wurde um diese Prinzipien herum entwickelt. Wir fördern eine end-to-end tägliche Aktualisierung von allem. Unsere Datenpipelines sind zustandslos und versioniert - sowohl die Logik als auch die Daten. Und wie sieht es bei Ihrem Unternehmen aus?