Verlieben Sie sich in das Problem, nicht in die Lösung
Jeder einzelne SKU erfordert banale tägliche Entscheidungen, wie zum Beispiel das Hinzufügen von mehr Lagerbestand oder das Ändern des zugrunde liegenden Preisschildes. Natürlich ist es arbeitsintensiv, für diese Entscheidungen einen vollständig manuellen Prozess beizubehalten, und Unternehmen haben verschiedene softwarebasierte Automatisierungslösungen übernommen. Die häufigste Designstrategie für diese Lösungen besteht darin, durch Software etwas zu replizieren, das im Wesentlichen der bestehenden “menschlichen” Praxis ähnelt.
Dieser Ansatz ist nicht neu. Man könnte sogar sagen, dass er von Expertensystemen betont wurde, die während des zweiten KI-Winters Ende der 1980er und Anfang der 1990er Jahre weitgehend in Ungnade gefallen sind. Während das Schlagwort Expertensysteme nicht mehr existiert - ich glaube nicht, dass es heute noch einen (bedeutenden) Softwareanbieter gibt, der sich als “Expertensystem”-Anbieter bezeichnet - fällt mir dennoch auf, dass die zugrunde liegende Perspektive in den meisten Branchen vorherrscht.
Tatsächlich bleiben die meisten Softwareanbieter und auch die meisten internen Initiativen in der Perspektive stecken, die bestehende Praxis zu replizieren, die selbst durch Nachahmung des ursprünglich vollständig manuellen Prozesses entstanden ist. Das alte Expertensystem wurde möglicherweise durch einen moderneren Deep Learning Algorithmus ersetzt, aber das Gesamtbildparadigma bleibt (nahezu) unberührt.
In der Supply Chain ist dieses Muster bemerkenswert, weil fast die gesamte Praxis auf Ansätzen beruht, die in einer Welt entstanden sind, in der Computer noch nicht existierten. Zum Beispiel unterscheiden viele - die meisten - Unternehmen das Planungsteam, die Personen, die die Nachfrageprognose für jedes Produkt erstellen, vom Beschaffungsteam, den Personen, die die Bestellungen auf der Grundlage der Nachfrageprognose weitergeben. Dieser Ansatz entstand aus einer tayloristischen Perspektive, bei der die Mitarbeiter so spezialisiert wie möglich sein mussten, um in ihrem Job maximal leistungsfähig zu sein.
Doch wenn es um Supply Chain-Optimierung geht, steht der Taylorismus im Widerspruch zur Realität der Supply Chain. Die Realität legt nahe, dass zukünftige Nachfrage nicht unabhängig von aktuellen Entscheidungen ist. Wenn eine viel größere Bestellung aufgegeben wird - was zu einem viel niedrigeren Stückpreis führt - kann auch der Verkaufspreis gesenkt werden, was potenziell den Markt übertrifft und somit die Nachfrage erheblich steigert. In einer Welt ohne Computer war der Taylorismus die am wenigsten schlechte Option, weil er zwar nicht sehr effizient war, aber enorm skalierbar war. Doch in einer Welt mit Computern erfordert die Situation einen integrierteren Ansatz, der solche Rückkopplungen, wenn auch grob, berücksichtigt. Wie das Sprichwort sagt, ist es besser, ungefähr richtig zu sein als genau falsch.
Bei der Untersuchung von Kunden oder Interessenten in dieser Angelegenheit ist die Situation häufig unklar. Die Lösungen - ursprünglich entwickelt, um einen rein manuellen Prozess zu replizieren - sind seit so langer Zeit im Einsatz, dass die Menschen den Blick für die grundlegenden Aspekte des Problems verloren haben, das sie zu lösen versuchen. Zu oft sind die Menschen Spezialisten für die vorhandene Lösung geworden, anstatt Spezialisten für das Problem des Unternehmens zu werden. Daher sind bei dem Versuch, die Situation zu verbessern, alle Gedanken buchstäblich in dem verankert, was als Fehler der aktuellen Lösung wahrgenommen wird. Aufgrund dieser Voreingenommenheit werden Ansätze, die das Problem gründlich überdenken, sowohl von der Geschäftsleitung als auch von ihren Teams als riskant wahrgenommen. Im Gegensatz dazu werden die Optionen zur schrittweisen Verbesserung der bestehenden Lösung als sicher oder zumindest viel sicherer angesehen.
Bei genauerer Betrachtung ist die Geschichte der Unternehmenssoftware leider voll von Geschichten über Anbieter, die ihre “neue Art” der Dinge durchgesetzt haben, die sich als viel mühsamer und starrer erwiesen haben als die alten Prozesse und keinerlei Produktivitätssteigerungen brachten oder sogar negative Auswirkungen hatten. Anekdotisch beobachte ich, dass die meisten Unternehmen, die große Lieferketten betreiben, ihre Büroangestellten - die ihre Lieferketten unterstützen - in den letzten beiden Jahrzehnten nicht wesentlich reduziert haben, während die Arbeiter in den Fabriken oder Lagern durch bessere Anlagen oder bessere Lagerhäuser aggressiv automatisiert wurden. Diese bedauerlichen Ereignisse haben im Ökosystem eine gesunde Portion Skepsis gegenüber diesen anstrengenden “Reorgs” für die Einhaltung einer neuen Softwarelösung hervorgerufen.
Allerdings stelle ich auch fest, dass Supply Chain-Manager die Risiken, die mit jeder “intelligenten” Software verbunden sind - das heißt, mit jeder Software, deren Korrektheit nicht vollständig und präzise spezifiziert werden kann - in der Regel stark unterschätzen. Tatsächlich sind die meisten Unternehmenssoftware nichts weiter als CRUD -Anwendungen, d.h. gewissenhafte Buchhalter für banale Auflistungen wie Rechnungen, Lieferanten, Produkte, Zahlungen usw.
Es ist bereits sehr schwierig, mit “dummer” Software geschäftlichen Erfolg zu erzielen - viele E-Commerce-Unternehmen haben bereits Schwierigkeiten, eine gute Verfügbarkeit für ihre Web-Frontend aufrechtzuerhalten - aber immer wenn komplizierte Softwarekomponenten wie Machine Learning involviert sind, wird der Erfolg viel schwieriger. Nur wenige Unternehmen kommunizieren offen zu diesem Thema, aber immer wenn Machine Learning involviert ist, dominieren die Misserfolge das Feld. Die Situation ist jedoch nicht so düster, wie es scheinen mag, denn die Nachteile sind begrenzt, während die Vorteile es nicht sind.
Langfristig gesehen sind Unternehmen, die am meisten versuchen und scheitern, auch diejenigen, die am meisten Erfolg haben.
Dennoch sind Softwarerisiken sehr real, und es macht sicherlich keinen Sinn, diese Risiken noch weiter zu erhöhen. Das Festhalten am Paradigma der Reproduktion einer mittlerweile veralteten manuellen Praxis führt zwangsläufig zu einer Reihe von zufälligen Komplikationen. Zum Beispiel treten eine ganze Reihe von Problemen auf, um die Teams der Planung und der Lieferung synchron zu halten, da sie getrennt sind. Als Faustregel in der Softwareentwicklung erhöht eine Aufblähung der Anforderungen um 25% die Kosten um 200%. Die Lösung dieser Komplikationen erhöht die Kosten drastisch und damit in der Praxis das Risiko, da Unternehmen - eine vernünftige Reaktion - Initiativen beenden, die ihre Budgets oder ihre Fristen sprengen.
Daher ist es ratsam, bei der Frage, ob die Software an die Organisation angepasst werden soll oder ob die Organisation an die Software angepasst werden soll, intellektuell bei einem leeren Blatt anzufangen und zunächst herauszufinden, welche hochrangigen Probleme gelöst werden müssen. Wird die Leistung in Prozent gemessen? Oder in Dollar? Berücksichtigen wir die langfristigen Auswirkungen richtig? Wie zum Beispiel Kunden darauf zu trainieren, nur während des Verkaufs zu kaufen. Nutzt der Ansatz menschliche Eingaben oder verbraucht er nur diese Eingaben? Wird die Praxis von Gewohnheiten oder von zwingender Notwendigkeit getrieben? Wie zum Beispiel zwei Modekollektionen pro Jahr im Vergleich zu zwei Ernten pro Jahr.
Das genaue Verständnis des zu lösenden Problems - das das Problem selbst klar von seiner gegenwärtigen Lösung unterscheidet - ist der Schlüssel, um herauszufinden, ob die bestehende Lösung erhalten bleiben sollte oder ob sie vereinfacht werden sollte, um neuere Softwarefunktionen zu nutzen, die eine einfachere und direktere Lösung des Problems erfordern.
