Alles jeden Tag aktualisieren

Joannes Vermorel

Lokad’s supply chain practice besteht darin, alle data pipelines – Prognosen eingeschlossen – mindestens einmal täglich zu aktualisieren, selbst bei monatlichen oder vierteljährlichen Berechnungen. Für viele Praktiker mag diese Vorgehensweise kontraintuitiv erscheinen. Warum vierteljährliche Prognosen öfter als einmal pro Quartal aktualisieren? Was ist mit numerischen Instabilitäten? Was ist mit der dabei entstehenden Reibung? Dies widerspricht den meisten etablierten supply chain practices, insbesondere denen von Unternehmen, die einen S&OP Prozess implementiert haben. Doch eine Dekade an Erfahrung hat uns gelehrt, dass das Nichtbefolgen dieser „Refresh all the things“-Praxis das Rezept für einen unendlichen Strom von Produktionsproblemen ist. Im Kern muss dieses Problem frontal und umfassend angegangen werden – durch ein versioned stateless design der Software, die für die predictive optimization der supply chain verantwortlich ist. Dieser Punkt wird im Folgenden ausführlicher behandelt, aber beginnen wir mit einem genaueren Blick auf das Problem selbst.

In der Welt der Enterprise Software treten ständig Probleme, Fehlfunktionen, Bugs und sonstige Schwierigkeiten auf. Dies gilt besonders für supply chains, bei denen die applicative landscape in der Regel eine zusammengewürfelte Ansammlung von Softwarekomponenten (ERP, EDI, MRP, WMS, OMS, ecommerce etc.) ist, die über Jahrzehnte zusammengefügt wurde: Jede App ist eine potenzielle Fehlerquelle, da sie mit vielen anderen Apps interagiert¹. Jede Änderung an einer dieser Apps kann an anderer Stelle etwas kaputtmachen, also nicht nur die App selbst beeinträchtigen. Nicht alle Unternehmen sind gleich, was das Management ihrer applicative landscape betrifft; aber bei über 1000 Mitarbeitern haben selbst die am besten geführten Unternehmen mehr als einen softwaregetriebenen supply chain “glitch” pro Tag.

So stehen auch relativ große Unternehmen vor einem unendlichen Strom von Softwareproblemen, die behoben werden müssen. Die Zuständigkeit für die Lösung dieser Probleme variiert. Die Verantwortung kann bei der IT-Abteilung, einem Drittanbieter, einem Betriebsteam, einem Lieferanten etc. liegen. Doch sobald eines dieser Probleme „angeblich“ behoben ist, bedarf es 5 bis 10 Runden², um sicherzugehen, dass das Problem wirklich gelöst ist. Tatsächlich sind die meisten Probleme edge-cases, die sich zu jedem Zeitpunkt zeigen können – oder eben auch nicht. So mag ein Problem als gelöst erscheinen, weil es nach einer Korrektur verschwand, was aber noch nicht heißen muss, dass es endgültig behoben ist. Supply chains sind komplexe Systeme, die aus vielen voneinander abhängigen Komponenten bestehen, von denen manche nicht einmal vollständig in der Kontrolle des Unternehmens liegen (z. B. EDI mit Lieferanten). Menschen scheitern routinemäßig daran, endgültige Lösungen zu liefern – nicht weil sie faul oder inkompetent sind, sondern schlichtweg wegen der unreduzierbaren Komplexität.

Infolgedessen, wenn eine Datenpipeline nach einem Produktionsvorfall täglich ausgeführt wird, dauert es 5 bis 10 Tage, bis sie wieder stabil ist. Wird die Datenpipeline monatlich betrieben, dauert derselbe Behebungsprozess 5 bis 10 Monate. Es zählt die Anzahl der Runden, nicht die verstrichene Zeit. Es bedarf mehrerer Durchläufe, um mit Sicherheit feststellen zu können, dass der edge-case behoben wurde. Als anekdotischer Beleg hatten wir bei Lokad einen Fehler in der Jobplanung im Zusammenhang mit Zeitumstellungen, dessen Behebung zwei Jahre dauerte – gerade weil die Bedingungen, die den Fehler auslösten, so selten waren: zweimal im Jahr pro Zeitzone. Zwar sind gewisse Probleme – wie Zeitumstellungen – von Natur aus selten, doch lassen sich die meisten Probleme „auf Abruf“ reproduzieren, indem man einfach die Frequenz der „Runden“ erhöht.

Die kontinuierliche Überprüfung der end-to-end Datenpipelines ist der einzige Weg, um sicherzustellen, dass Probleme in einem angemessenen Zeitrahmen behoben werden. Eine seltene Ausführung führt zwangsläufig dazu, dass das System standardmäßig defekt ist. Unternehmen, die sporadisch Datenpipelines betreiben – etwa vierteljährliche – enden unweigerlich in großen Bürokratien, die einzig darauf ausgerichtet sind, die Pipeline einmal pro Quartal wiederzubeleben. Schlimmer noch, meist ist das Ganze so dysfunktional, dass die Bürokratie den Großteil des Quartals damit verbringt, die „Aktualisierung“ für das nächste Quartal vorzubereiten. Im Gegensatz dazu benötigen die Echtzeit-Pipelines – wie das Betreiben von Webseiten für die Unternehmenswebsite – kaum jemanden, der ständig daran arbeitet.

Bei Lokad haben wir vor mehr als einem Jahrzehnt aus purer Notwendigkeit auf tägliche Aktualisierungen (oder öfter) gesetzt. Seitdem haben wir keinen anderen Weg gefunden, um aus supply chain-Sicht eine anständige Servicequalität zu gewährleisten. Vermutlich gibt es keinen. Predictive Analytics sind komplex und daher anfällig für „Bugs“ aller Art. Tägliche Aktualisierungen stellen sicher, dass Probleme prompt behoben werden, anstatt ewig in einem Schwebezustand zu verharren ³. In dieser Hinsicht sind unsere Erkenntnisse alles andere als originell. Netflix war ein Vorreiter im Chaos Engineering nach ähnlicher Denkweise: Um ein robustes System zu entwickeln, muss es Stress ausgesetzt werden; ohne Stress findet Robustheit nie ihren Weg ins Ingenieursdenken. Die meisten ernstzunehmenden Softwareunternehmen – insbesondere die GAFAM – haben noch strengere Varianten dieses Ansatzes übernommen.

Darüber hinaus führen seltene Aktualisierungen der Datenpipelines nicht nur zu Produktionsproblemen aus supply chain-Sicht, sondern unterstreichen auch eine ganze Reihe von schlechten Praktiken und schlechten Technologien.

Wenn Prognosen nur selten aktualisiert werden, ist es sehr verlockend, sie manuell anzupassen. Tatsächlich verzögern sich Prognosen die meiste Zeit absichtlich aufgrund der seltenen Aktualisierung. Schon ein Blick auf die gestrigen Daten ermöglicht es dem Nachfrageplaner eine Prognose zu verbessern, die das System vor drei Wochen erstellt hat. Doch diese Arbeit des Nachfrageplaners bringt dem Unternehmen keinen dauerhaften Mehrwert: Sie ist nicht akkretiv. Wenn die numerischen Rezepte, die die Prognosen erzeugen, so mangelhaft sind, dass manuelle Überschreibungen notwendig werden, dann müssen diese numerischen Rezepte verbessert werden. Kann der Softwareanbieter den Fix nicht liefern, 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ührt man die Prognose zweimal aus, erhält man zwei unterschiedliche Ergebnisse. Das ist eine gute Sache⁴. Instabile numerische Modelle sind für die supply chain schädlich, da sie zu Kettenreaktionen führen: Sobald ein Produktionsauftrag oder eine Bestellung erteilt wurde, ist das Unternehmen an die Folgen dieses Auftrags gebunden. Wird ein Auftrag erteilt, sollte das aus besseren Gründen geschehen als aufgrund numerischer Instabilität. Je eher das Unternehmen instabile numerische Rezepte aus seiner supply chain practice eliminiert, desto besser. Der Versuch, das zugrunde liegende Problem durch Reduzierung der Aktualisierungshäufigkeit zu verschleiern, ist Unsinn: Numerische Instabilität verschwindet nicht, nur weil man aufhört, darauf zu achten. Wenn die numerischen Rezepte so mangelhaft sind, dass sie von einem Tag auf den anderen keine starke Konsistenz⁵ aufrechterhalten können, sind bessere numerische Rezepte erforderlich. Und falls ein Softwareanbieter mitten im Problem steckt und keinen tiefgreifenden Fix liefern kann, braucht das Unternehmen ebenfalls einen besseren Anbieter.

Tägliche Aktualisierungen aller Datenpipelines mögen in Bezug auf Rechenressourcen extravagant erscheinen. Betrachtet man jedoch moderne Hardware und gut konzipierte Software, sind diese Kosten gering – selbst bei anspruchsvollen Rezepten wie probabilistischen Prognosen⁶. Darüber hinaus sehen sich supply chains routinemäßig außergewöhnlichen Bedingungen gegenüber, die sofortige großflächige Korrekturen erfordern. Kann das Unternehmen nicht alle supply chain-Zahlen in weniger als 60 Minuten aktualisieren, bleibt garantiert hin und wieder ein Notfall unadressiert, was vor Ort Chaos verursacht. Die zuvor diskutierte Regel der 5 bis 10 Runden gilt weiterhin: Sobald ein Fix gefunden wurde, bedarf es mehrerer Durchläufe – möglicherweise mit variierenden Einstellungen – um sicherzustellen, dass diese Notfallkorrektur wirkt. Ist die Datenpipeline zu kostspielig, um sie „on demand“ auszuführen, wird die Produktion als Prüfstand genutzt und es bricht Chaos aus.

Aus produktivitätsbezogener Sicht beseitigen tägliche Aktualisierungen die Toleranz gegenüber fehlerhaften Setups, die kontinuierlich unbrauchbare Ergebnisse liefern. Auch hier gilt: es ist eine gute Sache. Es gibt keinen Grund, ein numerisches Rezept zu tolerieren, das ständig Müll produziert. Demand Planning ist keine künstlerische Schöpfung, die sich der numerischen Analyse entzieht. Dysfunktionale numerische Rezepte sollten als Software-Bugs behandelt und entsprechend behoben werden. Allerdings erfordert die Lösung des Problems meist weitaus mehr Überlegungen, als auf einen ad hoc manuellen Override zurückzugreifen. Die meisten Unternehmen fragen sich, warum ihre supply chain-Teams immer wieder zu ihren Spreadsheets zurückkehren. Es stellt sich heraus, dass oft die Spreadsheets der einzige Ort sind, an dem die numerischen Korrekturen – die bereits Teil der Systeme sein sollten – überhaupt implementiert werden, gerade weil ein schnelles Iterieren über ein Spreadsheet unproblematisch ist (im Gegensatz zum Iterieren über das zugrunde liegende Enterprise-System).

Allerdings sind tägliche (oder häufigere) Aktualisierungen nur ein betrieblicher Aspekt des Problems. Im Hinblick auf das Softwaredesign muss dieser Ansatz durch eine erste Schlüsselzutat ergänzt werden: Statelessness. Eine Datenpipeline sollte keine vorverarbeiteten Daten verwenden, sondern jedes Mal mit den rohen Transaktionsdaten neu starten. Tatsächlich ist es sehr wahrscheinlich, dass jeder Bug oder jede Fehlfunktion die vorverarbeiteten Daten korruptiert und das Unternehmen für einen unbestimmten Zeitraum zurückhält: Die Logik mag behoben sein, aber die fehlerhaften Daten bleiben bestehen. Die Lösung ist einfach: Die Datenpipeline sollte keinen Zustand besitzen, d.h. keinerlei vorverarbeitete Daten jeglicher Art. Ein Neustart stellt sicher, dass alle Korrekturen unmittelbar in vollem Umfang übernommen werden.

Im Gegenzug ergänzt Versioning, ein weiteres Prinzip des Softwaredesigns und die zweite wesentliche Zutat, die Statelessness des Systems – genauer gesagt, das Daten-Versioning. Wenn die Datenpipeline selbst keinen Zustand hat, sollte es ausreichen, die Logik der Pipeline – die als versioned Quellcode vorliegt – mit den Eingangsdaten zu kombinieren, um ein während der Ausführung der Pipeline aufgetretenes Problem exakt reproduzieren zu können. Anders ausgedrückt, es macht Probleme reproduzierbar. Um dies zu erreichen, muss jedoch eine exakte Kopie der Daten bewahrt werden, so wie sie während der Ausführung der Datenpipeline vorlagen. Mit anderen Worten, die Daten sollten zusammen mit dem Code versioniert werden. Das Daten-Versioning stellt sicher, dass Korrekturen unter exakt denselben Bedingungen getestet werden können, die das jeweilige Problem ursprünglich ausgelöst haben.

Lokad wurde auf Grundlage dieser Prinzipien entwickelt. Wir setzen auf eine end-to-end tägliche Aktualisierung von allem. Unsere Datenpipelines sind stateless und versioned – sowohl die Logik als auch die Daten. Wie sieht es bei Ihrem Unternehmen aus?