Die Instandhaltung der Optimierung

Joannes Vermorel

Die Gebühren, die Lokad seinen Unternehmenskunden berechnet, sind unkompliziert¹: eine monatliche Pauschale für eine Mischung aus Software+Experten². Zur Überraschung einiger bleiben unsere monatlichen Gebühren im Laufe der Zeit konstant, anstatt am Ende der Onboarding-Phase abrupt zu sinken. Die meisten sind jedoch nicht überrascht, da es in der Welt der enterprise software nur ein weiterer Montag ist, wenn man erneut eine absurde Demonstration von Gier seitens eines Anbieters erlebt. Dabei handelt es sich allerdings nicht um ein Lehrbuchbeispiel rücksichtsloser Habgier. Vielmehr ist diese Gebühr das, was notwendig ist, um eine nachhaltige supply chain performance zu erreichen.

Der profitabelste Weg für Anbieter von enterprise software ist, und war schon immer, take the money and run. Vorauszahlungen für Lizenzen gleichen dem Gelddrucken. Im Vergleich zur Lizenzierung ist die Integration mühsamer. Die Risiken sind höher und die Margen dünner. Infolgedessen vergeben große Anbieter diesen Teil meist vollständig an Subunternehmer, indem sie ein Netzwerk von Integratoren aufbauen, die den Druck für sie aushalten können. Aus Sicht des Anbieters ist jedoch der weitaus unprofitabelste Teil die Instandhaltung. Anekdotisch gesehen ist dies der Grund, weshalb Anbieter trotz erheblicher Instandhaltungsgebühren weiterhin Upgrades für ihre Kunden vorschreiben. Die Instandhaltungsgebühren, obwohl erheblich, kommen nicht einmal annähernd an das heran, was erforderlich wäre, um ihre eigenen veralteten Systeme zu unterstützen.

Die Optimierung der supply chain ist allerdings ein Sonderfall, da Anbieter (nicht Lokad) es geschafft haben, die Instandhaltung auszuschließen. Dieser “Erfolg” ist jedoch sicherlich nicht derjenige, den ihre Kunden sich vorgestellt hatten.

Seit den 1980er Jahren liefern Anbieter (wie Lokad, jedoch Jahrzehnte früher) Software, um supply chain decisions zu automatisieren³. Seitdem hat fast jedes große Unternehmen nicht nur eine, sondern oft mehrere solche Lösungen erworben. Selbst ERPs, was für Enterprise Resource Planning steht, erhielten in den 1990er Jahren ihren Namen aus diesem Bestreben, den “Planning”-Teil zu automatisieren. Andernfalls würden ERPs ERMs heißen, was für Enterprise Resource Management steht.

Dennoch fand die Automatisierung von supply chain decisions nicht statt. Die Systeme wurden zwar implementiert, sammeln aber entweder Staub oder weichen von ihrer ursprünglichen Mission ab⁴. Infolgedessen werden die meisten supply chains immer noch über spreadsheets verwaltet, was beweist, dass, selbst wenn diese Optimierungslösungen anfangs als Erfolg gewertet wurden, etwas bei der Instandhaltung schiefgelaufen ist.

Diese Fehler sind aus der Sicht von Softwareanbietern profitabel. Der Anbieter behält die Lizenzgebühren, möglicherweise in Form einer mehrjährigen Verpflichtung (im Falle von SaaS). Da die Lösungen – zumindest der Optimierungsteil – nicht funktionieren, ist nur wenig oder gar keine Instandhaltung erforderlich. Die Kunden kümmern sich nicht um Softwarefunktionen, die sie sowieso nicht nutzen, und üben daher kaum Druck auf den Anbieter aus. Von der ursprünglichen Lösung bleibt nur ein Fragment in Gebrauch – üblicherweise ein schmales Dateneingabegateway, um grundlegende Automatisierungsregeln zu verwalten, die in Unternehmenssysteme integriert sind (z. B. min/max Einstellungen für SKUs).

Andererseits gelingt es Lokad, automatisierte supply chain decisions in Produktionsqualität zu liefern. Allerdings erfordert dies fortlaufende Anstrengungen eines für den Kunden zuständigen Teams – der supply chain scientists in Lokad parlance – um dies zu ermöglichen. Der Scientist ist dafür verantwortlich, die numerische Rezeptur zu entwickeln und anschließend zu warten, die die interessierenden supply chain decisions generiert.

Die resultierende numerische Rezeptur kann unbeaufsichtigt bleiben. Das ist im Grunde genommen, was “production-grade” Automatisierung im Kontext der Optimierung der supply chain bedeutet. Somit kann der supply chain scientist jederzeit aus dem Spiel genommen werden, ohne dem Unternehmen zu schaden.

Dennoch ist supply chain ein sich ständig veränderndes Biest, das naturgemäß Folgewirkungen mit sich bringt. Während unsere Algorithmen mit Mengenänderungen zurechtkommen, haben wir noch nicht Algorithmen, die mit all den anderen feinen Veränderungen umgehen können, die notwendig sind, um die numerische Rezeptur in Produktionsqualität zu erhalten.

Infolgedessen bleiben die supply chain scientists mit einer Reihe von Aufgaben zurück, die angegangen werden müssen, sobald Lokad im Einsatz ist:

• Neuere Daten werden verfügbar⁵, und die numerische Rezeptur muss aktualisiert werden, um diese neuen Daten zu nutzen. Umgekehrt werden einige Datenquellen eingestellt, und numerische Abhängigkeiten müssen entsprechend gelöst werden. In großen Unternehmen befindet sich die applicative landscape in ständiger Weiterentwicklung, nicht nur während eines ERP-Upgrades.

• Die Strategie des Unternehmens ändert sich. Die numerische Rezeptur spiegelt die strategische Ausrichtung des Kunden wider, und diese Reflexion geht weit über die reine Auswahl einiger weniger Parameterwerte hinaus. Es ist nicht üblich, dass der supply chain scientist ganze Abschnitte der Rezeptur neu schreibt, um strategische Änderungen zu berücksichtigen, aber gelegentlich kommt es dennoch vor.

• Vertrauen muss aufrechterhalten werden. Die Führungsebene der supply chain benötigt den supply chain scientist, um fortlaufend Nachweise dafür zu erbringen, dass die numerische Rezeptur ordnungsgemäß funktioniert. Von dem Scientist wird erwartet, dass er nicht nur neue Instrumente zur Darstellung frischer oder überarbeiteter Leistungsindikatoren entwickelt, sondern auch alle Fragen beantwortet, die von der Führungsebene eingebracht werden.

• Transparenz muss gewahrt bleiben. Der Scientist ist dafür verantwortlich, die numerische Rezeptur ‘white-boxed’ zu präsentieren. Das bedeutet, Teams so zu schulen, dass sie ein angemessenes Verständnis erlangen, was ihnen wiederum ermöglicht, die Vorteile der durch die numerische Rezeptur bereitgestellten Automatisierung optimal zu nutzen. Wenn Teams rotieren, müssen neue Mitglieder (erneut) geschult werden.

Sollten wir bei einer dieser Aufgaben scheitern, bleibt den supply chain practitioners keine andere Wahl, als auf ihre spreadsheets zurückzugreifen.

Daher, auch wenn die numerische Rezeptur wochenlang unbeaufsichtigt bleiben kann⁶, nimmt ihre Relevanz im Laufe der Zeit unweigerlich ab. Folglich sind fortlaufende Engineering-Ressourcen erforderlich, um die numerische Rezeptur aktuell zu halten. Trotz der jüngsten Fortschritte in artificial intelligence, bleibt es weit jenseits des aktuellen Standes der Technik, eine Software zu entwickeln, die sich selbst warten kann. Es mag umstritten sein zu schreiben, aber die Aufgabe erscheint ebenso schwierig wie die Herausforderung, artificial general intelligence zu erreichen.

Obwohl fortlaufende Beiträge des supply chain scientist erforderlich sind, könnte man meinen, dass diese Bemühungen nach Inbetriebnahme der numerischen Rezeptur zurückgehen. Unsere Erfahrung hat das Gegenteil bewiesen. Die Komplexität der numerischen Rezeptur erweitert sich unweigerlich, um sich an das verfügbare Maß an Engineering-Ressourcen anzupassen⁷.

Im Laufe des letzten Jahrzehnts haben wir wiederholt einen Wendepunkt in Bezug auf Investitionen in Ressourcen beobachtet. Wenn die anfänglich in den Aufbau der Rezeptur investierten Ressourcen⁸ das überschreiten, was das Unternehmen voraussichtlich jährlich in ihre Instandhaltung investieren wird, erhält die Rezeptur nicht die erforderliche Pflege, um ihren Produktionsqualitätsstatus zu bewahren. Das häufigste Symptom dieses Versäumnisses ist ein umfangreicher Rückstand bei all den wichtigen, aber nicht unmittelbar kritischen Themen: Dokumentation, Code-Reviews, Code-Bereinigung, Instrumentierung usw.

Keine Technologie oder kein Prozess garantiert Geschäftserfolg⁹, aber mangelhafte Instandhaltung ist ein bewährtes Rezept, um ein Unternehmen wieder in den Ausgangszustand zurückzuführen – bevor es abschließend in einem Meer von spreadsheets versinkt. Lassen Sie nicht zu, dass Ihr Unternehmen ein weiterer Datenpunkt in unserem wachsenden Verzeichnis von vollkommen vermeidbaren supply chain failures wird.