Verliebe dich in das Problem, nicht in die Lösung

Joannes Vermorel

Jeder einzelne SKU erfordert alltägliche, banale Entscheidungen, wie etwa das Nachbestücken von Lagerbeständen oder die Anpassung des zugrunde liegenden Preisschilds. Natürlich ist es arbeitsintensiv, sich ausschließlich auf einen vollständig manuellen Prozess für diese Entscheidungen zu verlassen, weshalb Unternehmen unterschiedlichste softwarebasierte Automatisierungslösungen implementieren. Die am häufigsten angewandte Designstrategie für diese Lösungen besteht darin, mithilfe von Software etwas im Wesentlichen Ähnliches wie die bestehende “human” Praxis zu replizieren.

Dieser Ansatz ist nicht neu. Man könnte behaupten, dass er die von Expertensystemen betonte Perspektive war, die während des zweiten KI-Winters Ende der 1980er und Anfang der 1990er Jahre größtenteils in Ungnade fiel. Doch obwohl der Buzzword expert systems nicht mehr gebräuchlich ist – ich bezweifle, dass es heutzutage noch (bedeutende) Softwareanbieter gibt, die sich als „expert system“ Anbieter bezeichnen – fällt mir auf, dass die zugrunde liegende Perspektive in den meisten Branchen nach wie vor vorherrscht.

Tatsächlich verharren die meisten Softwareanbieter und auch die meisten internen Initiativen in der Perspektive, die bestehende Praxis zu replizieren, die ihrerseits durch das Nachahmen des ursprünglichen voll manuellen Prozesses entstanden ist. Das alte Expertensystem mag durch einen moderneren algorithmischen Gegenpart des deep learning ersetzt worden sein, doch das Gesamtparadigma bleibt (fast) unberührt.

Im supply chain ist dieses Muster auffällig, da nahezu die gesamte Praxis in Vorgehensweisen feststeckt, die in einer Welt entstanden sind, in der es noch keine Computer gab. Zum Beispiel unterscheiden viele – eigentlich die meisten – Unternehmen immer noch das planning team, also die Personen, die die Nachfrageprognose für jedes Produkt erstellen, von dem supply team, also denjenigen, die die Bestellungen auf Basis der Nachfrageprognose aufgeben. Dieser Ansatz entstand aus einer tayloristischen Perspektive, in der die Mitarbeiter so spezialisiert wie möglich sein mussten, um bei ihrer Arbeit maximal leistungsfähig zu sein.

Doch wenn es um supply chain optimization geht, steht der Taylorismus im Widerspruch zur Realität des supply chain. Die Realität diktiert, dass die zukünftige Nachfrage nicht unabhängig von den gegenwärtigen Entscheidungen ist. Wird eine wesentlich größere Bestellung aufgegeben – was zu einem deutlich niedrigeren Stückkaufpreis führt –, kann auch der Verkaufspreis gesenkt werden, womit man potenziell den Markt unterbieten und somit die Nachfrage erheblich steigern kann. In einer Welt ohne Computer war der Taylorismus die am wenigsten schlechte Option, da er zwar nicht besonders effizient, dafür aber enorm skalierbar war. Doch in einer Welt mit Computern erfordert die Situation einen integrierten Ansatz, der solche Rückwirkungen, wenn auch grob, berücksichtigt. Wie das Sprichwort sagt: Lieber ungefähr richtig als genau falsch.

Wenn man Kunden oder Interessenten zu diesem Thema befragt, ist die Situation häufig unklar. Die Lösungen – ursprünglich entworfen, um einen rein manuellen Prozess zu replizieren – sind so lange im Einsatz, dass die grundlegenderen Aspekte des zu lösenden Problems aus dem Blick geraten sind. Allzu oft sind Menschen zu Spezialisten der bestehenden Lösung geworden, anstatt Spezialisten für das Problem zu werden, mit dem sich das Unternehmen konfrontiert sieht. Daher sind bei dem Versuch, die Situation zu verbessern, alle Überlegungen buchstäblich an den wahrgenommenen Mängeln der aktuellen Lösung verankert. Aufgrund dieser Voreingenommenheit wird der Ansatz, das Problem in die Tiefe zu ergründen, sowohl vom Management als auch von den Teams als risikoreich angesehen. Im Gegensatz dazu wird die Möglichkeit, die bestehende Lösung schrittweise zu verbessern, als sicher erachtet; oder zumindest als deutlich sicherer.

Rückblickend ist die Geschichte der Unternehmenssoftware leider voll von Geschichten über Anbieter, die ihre „neue Art“ der Arbeitsweise aufgezwungen haben, die sich als weitaus mühsamer und deutlich starrer erwies als die alten Prozesse; was weder zu Produktivitätsgewinnen noch zu Effizienzsteigerungen führte – oft sogar zu negativen Ergebnissen. Anekdotisch beobachte ich, dass die meisten Unternehmen, die große supply chains betreiben, in den letzten zwei Jahrzehnten ihre weißen Arbeitskräfte – die ihre supply chains unterstützen – nicht wesentlich reduziert haben, während die blue-collars durch bessere Anlagen oder bessere Lagerhäuser aggressiv automatisiert wurden. Diese unglücklichen Ereignisse haben im Ökosystem eine gesunde Portion Skepsis gegenüber jenen erschöpfenden „reorgs“ ausgelöst, die einzig darauf abzielen, mit einer neuen Softwarelösung konform zu gehen.

Ich stelle jedoch auch fest, dass Supply Chain-Führungskräfte in der Regel die Risiken, die mit jeglicher „smarter“ Software – also Software, deren Korrektheit nicht vollständig und prägnant spezifizierbar ist – verbunden sind, stark unterschätzen. Tatsächlich sind die meisten Unternehmenssoftwares nichts weiter als CRUD Apps, also fleißige Buchhalter langweiliger Auflistungen wie: Rechnungen, Lieferanten, Produkte, Zahlungen usw.

Geschäftlichen Erfolg mit „dummer“ Software zu erzielen, ist bereits sehr schwierig – viele Ecommerce-Unternehmen haben schon Mühe, eine gute Verfügbarkeit ihres Web-Frontends aufrechtzuerhalten – aber sobald launische Softwarekomponenten wie machine learning Bausteine ins Spiel kommen, wird es viel schwieriger, erfolgreich zu sein. Nur wenige Unternehmen kommunizieren offen zu diesem Thema, doch immer wenn machine learning involviert ist, dominieren Misserfolge das Feld. Allerdings ist die Situation nicht so düster, wie es scheint, denn die Nachteile sind begrenzt, während die Vorteile es nicht sind.

So sind langfristig diejenigen Unternehmen, die am meisten versuchen und scheitern, letztlich auch die erfolgreichsten.

Dennoch sind Software-Risiken sehr real, und es macht sicherlich keinen Sinn, diese Risiken noch weiter zu erhöhen. Doch das Festhalten am Paradigma, einen inzwischen veralteten manuellen Prozess zu replizieren, führt zwangsläufig zu einer Reihe zufälliger Komplikationen. Zum Beispiel, da das planning team und das supply team getrennt sind, entsteht eine ganze Klasse von Problemen, die einzig und allein dazu dienen, diese Teams synchron zu halten. Als Faustregel in der Softwareentwicklung gilt: Eine Aufblähung der Anforderungen um 25 % führt zu einer Kostensteigerung von 200 %. Die Behebung dieser Komplikationen erhöht die Kosten drastisch, weshalb in der Praxis das Risiko steigt, da Unternehmen – eine vernünftige Reaktion – Initiativen beenden, die ihr Budget oder ihre Fristen sprengen.

Wenn man sich also der halbhundertjährigen Frage stellt, ob die Software an die Organisation angepasst werden soll oder die Organisation an die Software, ist es klug, intellektuell mit einem unbeschriebenen Blatt zu beginnen und zunächst herauszufinden, was die übergeordneten Probleme sind, die gelöst werden müssen. Wird die Leistung in Prozent gemessen? Oder in Dollar? Berücksichtigen wir dabei korrekt die langfristigen Implikationen? Etwa, indem wir die Kunden darin schulen, ausschließlich während des Ausverkaufs zu kaufen. Nutzt der Ansatz menschliche Eingaben oder verbraucht er diese lediglich? Wird die Praxis von Gewohnheiten getrieben oder von unbarmherziger Notwendigkeit? Etwa zwei Modekollektionen pro Jahr gegenüber zwei Ernten pro Jahr.

Das tiefgehende Verständnis des zu lösenden Problems – das das Problem selbst eindeutig von seiner derzeitigen Lösung unterscheidet – ist der Schlüssel, um herauszufinden, ob die bestehende Lösung bewahrt werden sollte oder ob sie vereinfacht werden muss, um neuere Softwarefunktionen zu ermöglichen, die eine einfachere, direktere Lösung des Problems vorsehen.