Die letzten paar Jahre waren nicht gut zu supply chains. Tatsächlich scheint das Einzige, was nie knapp war, die Kräfte der Disruption zu sein: Lockdowns, Kriege, Inflation etc. Infolgedessen ist ein neu entdecktes Interesse an ‘widerstandsfähigen’ supply chains entstanden. Natürlich haben die üblichen Verdächtigen – Berater, Professoren und software vendors (einschließlich meiner Wenigkeit) – damit beschäftigt, ‘Lösungen’ zu finden, die wenigstens den Einfluss dieser Disruptionen abschwächen und bestenfalls ganze Klassen von Disruptionen gänzlich eliminieren. Meine beiläufigen Beobachtungen deuten jedoch darauf hin, dass diese ‘Lösungen’, gleichgültig wie hoch ihr vermeintlicher Wert ist, meist nichts weiter als Wunschdenken darstellen.

Allegorie für die tägliche Arbeit eines Nachfrage- und supply planners

Tatsächlich habe ich im letzten Jahrzehnt beobachtet, dass die meisten supply chain-Direktoren und ihre Teams bereits in Mikrokrisen versunken sind – selbst in Zeiträumen, die weitgehend frei von groß angelegten Disruptionen sind. Daher haben die meisten supply chain-Abteilungen nicht einmal den Luxus, über Krisenmanagement (oder irgendeinen groß angelegten strategischen Plan) nachzudenken: Sie sind völlig damit beschäftigt, einen unaufhörlichen Strom von Bränden zu bekämpfen.

Vor einigen Jahrzehnten prägte die Softwareindustrie einen Begriff, der genau dieses Problem beschreibt: fehlende Bandbreite, wenn das Management nicht einmal leisten kann, über ein weiteres Problem nachzudenken, weil seine Aufmerksamkeit bereits auf zu viele Probleme verteilt ist. Was den Begriff der Bandbreite sowohl für die Software- als auch für die supply chain so relevant macht, ist, dass in beiden Fällen die übliche Unternehmensreaktion bei übermäßiger Arbeitslast – also mehr Menschen einzusetzen – nicht funktioniert. Das ist das Wesen von Brooks’ Law: Zusätzliche Arbeitskraft zu einem bereits im Verzug befindlichen Softwareprojekt hinzuzufügen, verzögert es nur noch weiter. In der Softwareindustrie – einem Sektor, der einige der profitabelsten Unternehmen, die jemals in freien Märkten operiert haben, hervorgebracht hat – ist dieses Bandbreitenproblem besonders tückisch. Selbst wenn das Unternehmen profitabel genug wäre, um sowohl die Belegschaft als auch das Management zu verdoppeln, würde das am Problem nichts ändern 1.

Vielleicht überraschend (oder vielleicht auch nicht) ist die Ursache für diesen endlosen Strom von supply chain-Mikrokrisen fast ausschließlich in der Software zu finden. Entgegen der Erwartung ist es nicht der Krieg in der Ukraine oder die Möglichkeit eines weiteren in Asien, der der supply chain-Abteilung die Bandbreite entzieht, sondern typischerweise Probleme, die man am besten als “völlig anekdotisch” beschreiben würde, etwa dass das WMS nicht synchron mit dem ERP läuft (…schon wieder); oder das Herumschwatzen mit der IT, um ein zusätzliches kundenspezifisches Datenbankfeld für “reservierte” Bestände zu erhalten 2; oder das Hinterherjagen völlig unzumutbarer Prognosen, wie sie der S&OP Prozess liefert.

In einer Galerie bandbreitenraubender Software sind analytische Produkte mit Abstand die schlimmsten Übeltäter. Diese Werkzeuge – besonders die Planungsprogramme – erfordern häufig nicht nur erheblichen Personaleinsatz, sondern erzeugen auch ihre eigene kleine Bürokratie. Infolgedessen behebt das Management der supply chain nicht nur softwarebezogene Probleme, sondern auch prozessbedingte, die durch die Bürokratie selbst entstehen. Dieser Prozess wird frustrierend reflexhaft und verschwendet immer mehr Bandbreite.

Lokad, als Teil dieses analytischen Software-Ökosystems, ist von diesem Problem nicht ausgenommen. Vor einigen Jahren haben wir jedoch das Gegenmittel im vierten Punkt unseres Manifests 3 entwickelt: Kontrolle zu haben erfordert die Automatisierung jeder banalen Aufgabe. Wir erkannten, dass ein sorgfältiges Gleichgewicht zwischen Management und Optimierung gefunden werden muss. Zum Beispiel, wenn die Erstellung der täglichen Kauf-/Produktionsaufträge das gesamte Bandbreitenbudget der supply chain-Abteilung verschlingt, bleibt nichts im Budget für Verbesserungen (sei es bezüglich Resilienz oder anderen Aspekten).

Im Gegenteil, wenn alle banalen Aufgaben vollständig automatisiert sind, wird der supply chain-Organisation eine enorme Bandbreite freigesetzt. Dieser Prozess benötigt jedoch Zeit. Es ist kein Zufall, dass es meist etwa ein Jahr dauert, bis Lokad, nachdem es mit der Arbeit für einen Kunden begonnen hat, sich direkt auf ein als strategisch geltendes Thema (wie Resilienz) konzentrieren kann. Lokad muss nicht nur in Produktion gehen (was etwa 6 Monate dauert), sondern die Organisation muss auch lernen, die Kontrolle über alle Prozesse, die nun automatisiert wurden, abzugeben (was weitere 6 Monate erfordert, in größeren Organisationen sogar noch mehr).

Durch die Automatisierung der banalen Entscheidungen gewinnen supply chain-Teams jedoch etwas zurück, das sie vor Jahrzehnten verloren hatten, als ihre Organisation digitalisierte: die Fähigkeit, ihre Kämpfe auszuwählen. Dies ist wahrscheinlich der wichtigste Vorteil der Automatisierung und übertrumpft die reinen Produktivitätsgewinne. Ich behaupte nicht, dass der Übergang zu einer digitalen supply chain in den 1980er und 1990er Jahren, betrieben durch eine Sammlung von ERPs, MRPs und APSs, nicht der richtige Schritt war. Kurz gesagt: Obwohl dieser digitale Weg notwendig war, brachte er gravierende Nachteile mit sich. Unternehmen im freien Markt waren noch nie so verankert in ihrer eigenen anwendungsbezogenen Landschaft, in der Migrationen und Upgrades typischerweise in Jahren gemessen werden. Viele supply chains sind so lange in ihrem “digitalen Feuerlöschmodus” gefangen, dass sich nur wenige Mitarbeiter daran erinnern, den Arbeitstag ohne einen endlosen Strom von Warnungen, Ausnahmen und Problemen begonnen zu haben. Ganz zu schweigen von dem entsprechend endlosen Strom an Meetings, um besagte Warnungen, Ausnahmen und Probleme zu klären. All diese Prozesse verursachen Grundkosten in Bezug auf Bandbreite, und die mentale Belastung läuft ständig weiter.

Als anekdotischer Beweis wollen wir betrachten, dass Henry Ford in weniger als 5 Jahren (1903 bis 1908) von null auf den Model T kam. Ford revolutionierte die industrielle Produktion, indem er im Zuge dessen mehr als ein Dutzend Modelle einführte (Model A, Model B, Model C etc.), während er gleichzeitig mit einem sich ständig verändernden Spiel von Angebot und Nachfrage jonglierte. Ford hatte es auch nicht leicht: Die Panik von 1907 war eine der größten und schwerwiegendsten Finanzkrisen aller Zeiten. Heutzutage schaffen es viele (oder die meisten?) Unternehmen nach 5 Jahren „Business as usual“ nicht einmal, das Upgrade ihres ERP abzuschließen.

Daher muss eine supply chain, um resilient zu werden, Bandbreite freisetzen. Resilienz ist ein schwieriges, schwer fassbares Thema, weshalb viel Bandbreite benötigt wird – was es umso herausfordernder macht. Schlimmer noch, die Knappheit an verfügbarer Bandbreite in supply chain, wie die Softwareindustrie bereits vor Jahrzehnten entdeckte, lässt sich nicht einfach durch das Verteilen großer Geldsummen beheben 4. Vielmehr ist der beste Weg zur Resilienz ein indirekter: Automatisieren Sie rücksichtslos banale Entscheidungen, um sich die Freiheit zu verschaffen, strategische Entscheidungen zu denken und umzusetzen – Resilienz eingeschlossen.


  1. Anekdotisch ist Brooks’ Law wahrscheinlich einer der Hauptgründe, warum ich nicht versuchte, von Venture Capitalists Kapital für Lokad zu akquirieren. Die meisten der Probleme, denen sich Lokad gegenübersieht – die prädiktive Optimierung von supply chains – lassen sich nicht dadurch lösen, dass man einfach über mehr Kapital verfügt: Wenn man nicht weiß, in welche Richtung man gehen soll, ist jegliche Beschleunigung sinnlos. ↩︎

  2. Bitte eröffnen Sie ein Ticket. ↩︎

  3. Das Manifest der Quantitative Supply Chain, von Joannes Vermorel, Mai 2017 ↩︎

  4. Ich bin zuversichtlich, dass meine Kollegen aus dem Bereich Enterprise Software das Gegenteil behaupten werden, solange ihnen das Geld in die Hände geworfen wird. ↩︎