Ja. In bemerkenswertem Ausmaß. Und ich hätte es mir niemals getraut, diese Meinung zu äußern, als ich Lokad vor fast einem Jahrzehnt gründete.

Mit Kompilierung meine ich die Kunst, Compiler zu entwickeln, das heißt, Computerprogramme, die Quellcode in eine andere Sprache übersetzen. Nur wenige Menschen außerhalb der Reihen der Programmierer wissen, was ein Compiler macht, und nur wenige innerhalb der Reihen der Programmierer wissen, wie ein Compiler entworfen wird. Zunächst erscheinen Kompilierungsfragen (um es milde auszudrücken) weit entfernt von supply chain-Angelegenheiten. Doch heutzutage ist es bei Lokad genau die Kompilierungsarbeit, die den Tag rettet; ein supply chain-Projekt nach dem anderen.

Schamloser Hinweis: Softwareingenieure mit Kompilierungsfähigkeiten wachsen nicht auf Bäumen, und wir stellen ein. Möchtest du an Dingen arbeiten, die wirklich wichtig sind? Nun, das nächste Mal, wenn dein Flug verspätet ist, weil ein Teil fehlte, oder das nächste Mal, wenn das Medikament, das du suchst, nicht vorrätig ist, denke daran, dass du einen Unterschied hättest machen können, indem du Lokad beitrittst :-)

Supply chains sind komplex, verdammt komplex. Die Globalisierung hat die Bezugsquellen vervielfacht, aber Verzögerungen sind länger und unvorhersehbarer denn je. Auch Vertriebskanäle werden vervielfacht: Es gibt stationäre Geschäfte, Onlineshops, Marktplätze, Wiederverkäufer, Großhändler, … Und jetzt, dank Amazon, erwartet jeder, überall, dass alles über Nacht bestellt und geliefert wird. Die Erwartungen an supply chains sind höher als je zuvor.

Die Herangehensweise an supply chain-Probleme mit etwas weniger als der vollständigen Ausdruckskraft einer Programmiersprache funktioniert nicht. So wie auch Lego-Programmierung nicht zustande kommt, passen supply chain challenges nicht in Checkboxen und Dropdown-Menüs. Dies hindert software vendors allerdings nicht daran, es zu versuchen. Lösungen, die mehr als 1000 Tabellen enthalten, wobei jede Tabelle durchschnittlich etwa 100 Felder umfasst, sind allzu verbreitet. Und obwohl das Kundenunternehmen nur etwa 1% des Funktionsumfangs der Lösung nutzt, muss es trotzdem mit ihrer allgegenwärtigen Komplexität zurechtkommen.

Die Kompilierung rettet den Tag, weil sie ein enormes Wissen und Know-how liefert, wenn es darum geht, qualitativ hochwertige Abstraktionen zu entwickeln, die als leistungsstarke Werkzeuge zur Lösung statistischer und kombinatorischer Probleme (und noch vielem mehr in der Tat) gedacht sind. Und die meisten supply chain challenges sind gerade statistisch und kombinatorisch. So ist es uns beispielsweise bei Lokad gelungen, durch die Einführung einer Algebra der Verteilungen komplizierte lead time Probleme, die unseren direkteren Ansätzen durch vorgefertigte Softwarefunktionen widerstanden, “in den Griff zu bekommen.”

Was Sprachfeatures von beispielsweise den üblichen App-Features (wysiwyg) unterscheidet, ist, dass Sprachfeatures viel weniger empfindlich auf die Spezifika einer gegebenen Herausforderung reagieren als ihre App-Feature-Pendants. Nehmen wir zum Beispiel eine Situation, in der Ihre Out-of-Stock-Erkennungslogik im spezifischen Fall ultra-saisonaler Produkte nach hinten losgeht. Wenn das Feature durch ein Sprachkonstrukt bereitgestellt wird, können Sie den Datenumfang immer so weit einschränken, bis das Feature genau dort funktioniert, wo es soll; möglicherweise durch eine ad-hoc numerische Analyse, die den Umfang dynamisch anpasst. Im Gegensatz dazu sind Sie bei einem App-Feature an die eingebauten Filteroptionen gebunden. App-Features passen nur, wenn Ihre Probleme eng umrissen und klar definiert sind, was in der supply chain-Optimierung eigentlich selten der Fall ist.

In supply chain glänzt Programmierbarkeit, weil:

  • Probleme sind sowohl hochgradig numerisch als auch sehr strukturiert
  • supply chains sind modular und diese Modularität muss genutzt werden
  • Die Anzahl der Variablen ist signifikant, aber nicht überwältigend
  • Die Passgenauigkeit der Problemform ist entscheidend

Es ist etwas amüsant zu sehen, wie viele Softwareanbieter dazu neigen, die Programmierbarkeit allmählich neu zu erfinden. Während die Benutzeroberfläche in Tiefe und Komplexität wächst, mit der Möglichkeit, Filter, Optionen, Pre- oder Post-Process-Hooks, vorgefertigte Alarme, KPI-Monitore hinzuzufügen, wird die Benutzeroberfläche nach und nach zu etwas Programmierbarem und erreicht den Punkt, an dem nur ein Programmierer sie tatsächlich verstehen kann (genau wegen seiner bestehenden Programmierfähigkeiten). Programmierbar, ja, aber auf eine höchst verschlungene Weise.

Die Kompilierung ist die Kunst, Ingenieursfähigkeiten zu verstärken: Man muss Abstraktionen und Sprachkonstrukte entwickeln, die das Denken bei der Lösung von Problemen vereinfachen. Wie Brian Kernighan berühmt schrieb: Jeder weiß, dass Debugging doppelt so schwierig ist wie das eigentliche Schreiben eines Programms. Wenn du also so clever wie möglich bist, wenn du es schreibst, wie sollst du es dann jemals debuggen? Die gleiche Logik gilt für die supply chain-Optimierung, denn sie ist im Wesentlichen dasselbe wie das Schreiben von Code. Nun, bei Lokad ist es buchstäblich dasselbe.

Die konventionelle IT-Weisheit besagt, dass man zuerst die einfachen Teile automatisieren sollte, damit menschliche Experten sich um die komplexeren Elemente kümmern können. Doch in supply chain schlägt dieser Ansatz jedes Mal fehl. Die komplexesten Teile von supply chain sind fast immer die kostspieligsten, diejenigen, die dringend Aufmerksamkeit benötigen. Die einfachen Teile können sich selbst über min/max Lagerbestände oder Kanban regeln. So wie man keine Software für autonome Autos bauen würde, indem man Software für automatische Zugbetriebe verfeinert, kann man schwierige supply chain-Probleme nicht angehen, indem man Software verfeinert, die ursprünglich zur Lösung einfacher Herausforderungen entwickelt wurde.

Natürlich ist die Kompilierung allein nicht ausreichend, um mit supply chain challenges umzugehen. Machine learning, Big-Data-Verarbeitung und eine beträchtliche Menge an menschlichen Fähigkeiten sind ebenfalls erwähnenswert. In allen Fällen hilft es jedoch erheblich, sorgfältig hochwertige Abstraktionen zu erstellen. Machine learning ist erheblich einfacher, wenn die Eingangsdaten gut vorbereitet sind. Big-Data-Verarbeitung gestaltet sich auch viel unkomplizierter, wenn sich die Berechnungen leicht einem hohen Grad an Parallelisierung unterwerfen lassen.