Produktorientierte Lieferung für supply chain - Vorlesung 1.3

00:22 Einführung
02:40 Warum ein Produkt? Weil Kapitalismus
08:18 Was soll das Produkt machen?
10:05 Software-Skalennachteile
12:50 Kaufen wir ein SCO-Produkt von der Stange
21:58 SCM vs SCO
25:58 Intermezzo
28:21 SCO ist nicht Ihr durchschnittliches Softwareprodukt
33:26 Software-Zutaten für SCO
42:49 Doch Tabellenkalkulationen sind nicht das Endspiel
46:51 Auch Python ist nicht das Endspiel
58:52 SC ist keine Abteilung der IT
01:03:19 Zusammenfassend gilt: Zwei Herausforderungen sind zu überwinden
01:07:04 Kommende Vorlesung und Fragen aus dem Publikum

Beschreibung

Das Ziel einer die Quantitative Supply Chain Initiative ist entweder, eine Softwareanwendung zu liefern oder zu verbessern, die einen Umfang routinemäßiger Entscheidungen (z. B. Inventar Lagerauffüllungen, Preisaktualisierungen) automatisiert. Die Anwendung wird als ein zu entwickelndes Produkt betrachtet. Die supply chain theory hilft uns dabei, eine Anwendung zu liefern, die das Unternehmen in Richtung supply chain performance steuert, während sie mit allen Einschränkungen, die die Produktion mit sich bringt, vereinbar ist.

Vollständiges Transkript

Hallo zusammen, vielen Dank, dass ihr an dieser supply chain Vorlesungsreihe teilnehmt. Ich bin Joannes Vermorel und präsentiere “Produktorientierte Lieferung für supply chain Optimierung.”

Zunächst, wenn ich von einem Produkt spreche, meine ich ein Softwareprodukt. Für diejenigen unter euch, die schon einmal das Privileg hatten, einen Blick unter die Haube einer modernen Unternehmens-Anwendung zu werfen, könnte das eine ziemliche Erfahrung sein.

Für diejenigen, die mit den Werken von H.P. Lovecraft vertraut sind, gibt es einige beunruhigende Ähnlichkeiten. Lovecraft hat eine Reihe von Romanen verfasst, und eines der wiederkehrenden Themen ist die Idee des verbotenen Wissens. Es ist nicht so, dass das Universum nicht erkennbar wäre – es ist das, aber das Einzige, was die Menschheit bewahrt, ist Unwissenheit. Unwissenheit ist kein Problem; sie ist genau das, was uns vor einem Universum schützt, das zu furchteinflößend für unseren Verstand ist. Diese Idee wurde in viele moderne Spiele recycelt, insbesondere in Rollenspielen, in denen Charaktere zusätzlich zu den traditionellen Lebenspunkten auch Vernunftpunkte haben. Wenn man bestimmte Dinge tut, die die Vernunft schädigen, verliert man Vernunftpunkte. Die Herausforderung bei enterprise software besteht darin, sie zu erstellen, ohne dabei den Verstand zu verlieren – eine der Voraussetzungen, um dem Unternehmen Mehrwert zu bieten. Also, lasst uns fortfahren.

Warum ein Produkt und insbesondere ein Softwareprodukt? Werfen wir einen genauen Blick darauf, wie supply chains traditionell funktionieren. Früher waren viele Menschen vor Ort tätig, die Dinge bewegten, Pakete sortierten, Fahrzeuge fuhren und alle manuellen Arbeiten verrichteten. Ebenso waren viele Menschen in der Produktion sowie in den Geschäften involviert. Was in den letzten Jahrzehnten allmählich geschah, ist, dass die Zahl der Arbeitnehmer in handwerklichen Berufen kontinuierlich abgenommen hat. Heutzutage ist die Produktion weitgehend automatisiert. Es gibt immer noch einige Branchen, wie etwa die Textilindustrie, in denen es schwierig ist, alles zu automatisieren – weshalb diese Branchen dorthin gezogen sind, wo Arbeitskräfte am billigsten sind. Die Realität ist, dass der Bedarf an reiner Arbeitskraft enorm gesunken ist.

Man landet in einer ziemlich merkwürdigen Situation, in der – wenn man in die Zukunft blickt, in der autonome Fahrzeuge bevorstehen – viele Unternehmen mehr Büroangestellte haben werden, die mit Excel spreadsheets die supply chain steuern, als es Arbeiter mit blauen Kragen vor Ort gibt, die die manuellen Arbeiten verrichten. Darauf beziehe ich mich, wenn ich von Schreibtischarbeit spreche.

Ein weiterer merkwürdiger Aspekt ist, dass supply chains in vielen Unternehmen bereits seit mindestens zwei Jahrzehnten digitalisiert sind. Es ist nicht so, als würden wir Software in supply chains einführen; supply chains werden bereits durch Software gesteuert und betrieben. Aber wenn man die Rolle des Menschen in diesen Softwaresystemen betrachtet, werden Menschen buchstäblich als menschliche Koprozessoren in einem durchschnittlichen supply chain System eingesetzt. Es gibt bestimmte Arten von Operationen, die die reguläre CPU, der Prozessor der Maschine, nicht ausführen kann, und daher wird die gesamte Aufgabe an den Menschen delegiert. In Verbindung mit simplen numerical recipes, wie zum Beispiel der ABC analysis, min-max Lagerhaltung und ähnlichen Rezepten, verbringen die Menschen ihre Tage mit dem Löschen von Bränden. Sie befassen sich stetig mit Ausnahmen und Bedingungen, die nicht ins Standardgerüst passen.

Aus Kostensicht handelt es sich hierbei ausschließlich um operative Ausgaben (OpEx). Man muss jeden Tag eine Armee von Angestellten bezahlen, die alle alltäglichen Entscheidungen treffen, die das Unternehmen täglich zu bewältigen hat. Dazu gehören etwa, was gekauft werden soll, wo das Inventar platziert wird, ob eine Einheit von einem warehouse in ein Geschäft verlagert werden soll, und viele weitere routinemäßige Entscheidungen. Die Menschen treffen diese Entscheidungen und löschen Brände, um die Unzulänglichkeiten der vom System naiv generierten automatischen Entscheidungen auszugleichen.

Mein Vorschlag für euch heute lautet, dass wir von OpEx zu Investitionsausgaben (CapEx) übergehen wollen. Das ist der ganze Sinn dieser produktorientierten Lieferung. Wir wollen ein Asset aufbauen, und warum? Weil es kapitalistisch ist. Wenn man sich die 100 profitabelsten Unternehmen der Welt heutzutage ansieht, sind die Hälfte von ihnen, gemessen am Gewinn, Softwareunternehmen. Sie repräsentieren das Wesen ultra-kapitalistischer Unternehmen, bei denen man eine Vorabinvestition tätigt und am Ende mit einem Gerät oder Artefakt dasteht, das mit minimalen zusätzlichen Investitionen einen Mehrwert generiert.

Kommen wir zurück zum Thema meiner vorherigen Vorlesung: Wir benötigen Robotisierung, um das Management wieder unter Kontrolle zu bringen. Automatisierung und der Mensch sollten zusammenarbeiten; der Mensch sollte nicht dazu da sein, die Unzulänglichkeiten dummer Inventarstrategien wie min-max auszugleichen. Stattdessen sollte er dazu beitragen, Mehrwert zu schaffen, numerische Rezepte zu verbessern und als Stratege zu agieren. Es gab ein altes IBM-Motto, das besagte: “Maschinen sollen arbeiten; Menschen sollen denken.” Genau diese Denkweise steckt in dieser Präsentation. Wir wollen die supply chain in ein kapitalistisches Asset verwandeln, und dazu müssen wir die supply chain in eine Maschine verwandeln, die ein Softwareprodukt liefert.

Was macht dieses Produkt eigentlich? Es stellt sich heraus, dass es etwas ziemlich Einfaches tut: Es trifft Entscheidungen. Nicht willkürliche, offene Entscheidungen, sondern die banalen, routinemäßigen Entscheidungen, wie beispielsweise, was produziert werden soll, wie viele Einheiten bei einem Lieferanten gekauft und wie viele Einheiten von einem Ort zu einem anderen verschoben werden sollen. Auf den ersten Blick mag es so erscheinen, als seien im supply chain Management viele Entscheidungen involviert. Betrachtet man jedoch die Aufgaben, so erfordert selbst die komplexeste supply chain nur wenige Dutzend unterschiedliche Entscheidungstypen, die jeden Tag getroffen werden müssen. Das ist nicht überwältigend, sondern angesichts der bloßen Anzahl der Funktionen durchaus vernünftig. Interessanterweise sind diese Entscheidungen weitgehend exklusiv, sodass es Grenzen dafür gibt, was mit einem Divide-and-Conquer-Ansatz erreicht werden kann. Sobald man sich entschieden hat, 100 Einheiten von einem Lieferanten zu kaufen, kann nicht ein anderes Teilsystem 200 Einheiten stattdessen bestellen. Irgendwann muss man sich darüber klar werden, wie viele Einheiten gekauft und von einem Ort zu einem anderen bewegt werden sollen. Diese Entscheidungen sind diskret, in ihrem Umfang begrenzt und weitgehend gegenseitig ausschließend. Was wir wollen, ist eine Software, die jeden Tag in völlig automatisierter Weise Bestellentscheidungen generiert.

Eine Sache, von der ich glaube, dass sie oft falsch verstanden wird, ist der Begriff der Software-Skalennachteile. Während Skaleneffekte den meisten bekannt sind, gilt in der Software das Gegenteil: Das Hinzufügen eines Viertels mehr Funktionen kann die Kosten verdoppeln. Dieses Konzept erklärt, warum kleine Startups mit großen Unternehmen konkurrieren können – weil sie sich auf einen kleineren Funktionsumfang konzentrieren, können die Kosten, ihr Produkt auf den Markt zu bringen, erheblich geringer sein als bei einem großen Unternehmen.

Mit dem Gedanken der Skalennachteile im Hinterkopf müssen wir entscheiden, ob wir unser supply chain Optimierungsprodukt bauen, kaufen oder einen anderen Ansatz wählen. Wenn wir uns entscheiden, das Produkt von einem Anbieter zu kaufen, müssen wir die Funktionen berücksichtigen, die der Softwareanbieter liefern muss, um den Markt zu bedienen.

Betrachten wir also den Kauf eines supply chain Optimierungsprodukts von der Stange. Auf diesen Folien gebe ich einen Überblick über nur einen winzigen Bruchteil all der Dinge, die wir angehen müssen. Ich habe aus erster Hand Erfahrung damit, denn als ich Lokad im Jahr 2008 gründete, begann ich mit einem kleinen Softwareprodukt, das eher auf Vorhersagen als auf supply chain Optimierung ausgerichtet war. Als ich mit Kunden zu arbeiten begann, stellte ich fest, dass es so viele Funktionen und Möglichkeiten gab, die mir fehlten, und als ich zu weiteren Kunden wechselte, entdeckte ich noch mehr fehlende Fähigkeiten. Es schien ein endloser Prozess zu sein, ständig neue Anforderungen zu entdecken.

Werfen wir einen Blick auf die Kernfunktionen. Zunächst gibt es Unternehmen, die entweder B2C oder B2B sind und in ihrem supply chain Management völlig unterschiedliche Muster aufweisen. Beispielsweise haben B2B-Unternehmen typischerweise weniger Kunden, aber diese Kunden bestellen wesentlich größere Mengen. Dies schafft verschiedene Risikotypen, wie etwa das Risiko, einen einzigen Kunden zu verlieren, der einen bedeutenden Anteil am Umsatz des Unternehmens ausmacht. Dann gibt es noch komplexere Geschäftsmodelle wie B2B2C oder B2B2B.

Betrachten Sie die verschiedenen Arten von Standorten, die abgedeckt werden müssen, wie Geschäfte, Lagerhäuser und Produktionsstätten. Jeder Standorttyp bringt seine eigenen Herausforderungen mit sich. Geschäfte beispielsweise neigen zu Inventarungenauigkeiten, selbst mit RFID-Technologie, einfach weil Kunden Produkte umstellen können. Lagerhäuser und Produktionsstätten, wie Betriebe in der Landwirtschaft oder im Bergbau, haben ihre eigenen spezifischen Probleme und Unwägbarkeiten in Bezug auf den Ernteertrag.

Supply chain Netzwerke können unterschiedliche Ebenen, oder Stufen, aufweisen, die von Ein-Ebenen- bis zu Mehr-Ebenen-Systemen reichen. Die Komplexität, eine supply chain zu managen, nimmt deutlich zu, je mehr Stufen vorhanden sind. Die Netzwerktopologie ist ein weiterer wichtiger Aspekt. Eine Baumtopologie ist der klassische Vorwärts-supply chain Pfad, bei dem wenige Produktionsstätten an mehrere Lager versenden, die wiederum zahlreiche Geschäfte beliefern. Allerdings können auch andere Topologien existieren, wie gerichtete azyklische Graphen (DAGs), bei denen ein Geschäft von mehreren Lagern bedient werden kann.

Im Grunde genommen ist es also nicht nur ein Baum im Sinne von Graphen, es kann sich vernetzen, obwohl es immer noch nur vorwärts geht. Aber dasselbe kann bei einem Directed Acyclic Graph (DAG) vorkommen, wenn man mehrere Lieferanten hat. Man kann sogar Schleifen in seinem supply chain Graph haben, die entstehen, sobald Reparaturen anfallen. Zum Beispiel gibt es in der Bergbauindustrie oder in der aviation Branche eine Menge Reparaturschleifen mit reparaturfähiger Ausrüstung.

Nun, das Inventar selbst hat nicht nur eine Art; es variiert stark. Man kann nicht einfach sagen: “Oh, ich habe die Vorstellung, dass ich SKUs besitze, und das war’s.” Nein, nicht ganz, denn zunächst einmal gibt es Rohstoffe, die buchstäblich in Mengen wie Gramm, Kilogramm oder Volumen gemessen werden. Dann gibt es die Einheiten, die die schönen, sauberen Einheiten sind und überwiegend verwendet werden. Aber dann kann es auch sehr häufig große Bestände geben, zum Beispiel in der Pharmaindustrie oder im Lebensmittelgeschäft, wo die Charge spezifische Verfallsdaten hat. Außerdem kann es komplett serialisierte Inventare geben, bei denen jede einzelne Einheit ihre eigene Seriennummer hat. In Bezug auf die supply chain Optimierung ändert dies das Spiel vollkommen, sodass es ein ganz anderes Problem ist, wenn man sich jedes dieser Dinge anschaut.

Dann gibt es natürlich all die Probleme von Marktplätzen. Bei Lokad haben wir Kunden in buchstäblich jeder erdenklichen Situation. Wir haben Kunden, die auf einem Drittanbieter-Marktplatz verkaufen, sie können einen eigenen Marktplatz haben oder beides. Es kann etwas Sekundäres sein, um so die Dinge zu liquidieren, die sie nicht verkauft haben. Es gibt viele Situationen.

Denken Sie nun beispielsweise einen Moment darüber nach, was eine Bestellung ist. Es gibt die Spot-Bestellung, bei der man im Grunde etwas direkt am Schalter kauft und es sofort besitzt. Aber dann gibt es auch eine Bestellung, bei der es heißt: “Ich kaufe es, aber ich möchte nicht, dass es sofort geliefert wird; ich möchte, dass es in einem Monat geliefert wird.” Offensichtlich ist das aus Sicht der supply chain Optimierung ein völlig anderes Spiel, denn wenn man im Voraus weiß, dass man zu einem bestimmten Datum eine bestimmte Menge liefern muss, will man das nicht vorhersagen, sondern anders behandeln.

Und dann gibt es noch eine konfigurierte Bestellung, und das ist beispielsweise der Fall, wenn man online einen Computer kauft und auswählen kann, wie viel Speicher, wie viel Festplatte, welchen Typ von Betriebssystem, welche Sprache für den Computer eingerichtet werden soll und wie die Tastatur sein wird, unter anderem. Man kann also einen umfangreichen Konfigurator haben, und das verändert die Landschaft erneut. Das passiert auch bei Dingen wie Fahrrädern oder Autos und ändert die Landschaft völlig, da es einem Optionen und Ansätze bietet, um das Problem der supply chain Optimierung auf völlig andere Weise zu betrachten.

Selbst bei Preisen kann es einen Stückpreis geben, der flach, super einfach und super linear ist, aber das ist nicht alles. Man kann Preisstaffelungen haben, zum Beispiel, wenn man zehn Einheiten kauft, dann erhält man einen Rabatt. Oder man kann Loyalty–Programme haben, bei denen einige Kunden mit einer Loyalitätskarte einen Rabatt bekommen können, aber nur bei bestimmten Produkttypen oder nur unter bestimmten Bedingungen. Und außerdem kann es im B2B-Bereich sehr häufig verhandelte Konditionen geben, sodass es buchstäblich eine Transaktion ist, bei der vieles verkauft wird, obwohl ein regulärer Katalogpreis besteht. Allerdings kann ein Anbieter einem Kunden einen Nachlass gewähren, weil dieser wichtig ist – so macht man das eben. Letztendlich: Ich spreche nun seit wenigen Minuten und habe erst den Kern abgedeckt. Ich habe noch nicht einmal angefangen, die unverzichtbaren Dinge anzusprechen. Also macht kurz Pause und überlegt, wie ein fertiges Enterprise-Software-Produkt, das supply chain Optimierung liefern soll, aussehen wird. Die Anzahl der Funktionen, die abgedeckt werden müssen, ist buchstäblich Wahnsinn, und wenn man darüber nachdenkt, all diese Dinge zu einem Monolithen zusammenzufügen, verliert man buchstäblich den Verstand. Wir kommen zurück zu der Idee, dass es nicht so ist, dass das Universum nicht erkannt werden kann, sondern dass man den Verstand verliert, wenn man der nackten Wahrheit des Universums ausgesetzt ist.

Also, wir haben ein großes Problem, und hier müssen wir zwischen supply chain management und supply chain Optimierung unterscheiden. Diese Unterscheidung habe ich bereits in einem meiner früheren Vorträge eingeführt. Es herrscht große Verwirrung zwischen der Management-Seite und der Optimierungs-Seite. Management dreht sich um Buchhaltung, unterstützende Arbeitsabläufe und vor allem um Dateneingabeprozesse. Wenn man all die Dinge darstellen möchte, die ich gerade beschrieben habe, ist das ein weites Feld, aber es ist machbar. Ein „fettes“ ERP kann das leisten. Ja, am Ende hat man 10.000 Tabellen, es wird ziemlich hässlich, aber es ist möglich. Aber irrt euch nicht, das ERP (das eigentlich ERM, Enterprise Resource Management, heißen sollte) wird nicht viel tun. Es dient lediglich dazu, diese Dinge nachzuverfolgen. So werdet ihr eine Menge Entitäten haben – MOQs, abgehakt; Preisstaffelungen, abgehakt; Ladengeschäfte, abgehakt; Lagerhäuser, abgehakt – aber ihr benötigt keinen Funken Intelligenz. Es geht nur darum, alltägliche digitale Entsprechungen zu haben, die die Daten abbilden und es ermöglichen, sie in das System einzugeben, und das war’s.

Das ist möglich, weil wir hier ein wenig bei der Regel „eine Viertel mehr Funktionen verdoppeln die Kosten“ schummeln können. Es gibt etwas, das ich dazu eigentlich nicht erwähnt habe: Es funktioniert, wenn ihr eure Funktionen völlig voneinander trennt. Solange die Funktionen nicht miteinander interagieren, ist das in Ordnung; ihr seid nicht diesem Fluch der abnehmenden Skaleneffekte unterworfen. Aus der Sicht der Dateneingabe gibt es kein Problem. Ihr braucht nicht die Benutzeroberfläche, die es euch ermöglicht, die MOQs mit dem, was es euch erlaubt, einen zusätzlichen Laden ins Netzwerk aufzunehmen, zu steuern. Diese beiden Dinge können völlig getrennt voneinander ablaufen.

Wenn es jedoch um supply chain Optimierung geht, gilt das nicht. Wenn ihr MOQs habt, haben diese tiefgreifende Auswirkungen darauf, wie oft ihr bestellt und wie oft ihr Dinge von eurem Lager zu euren Ladengeschäften liefert. Es gibt viele weitreichende Konsequenzen. Man kann die Dinge nicht trennen, denn letztlich ist eure supply chain nur ein System, in dem alles alles beeinflusst. Aus der Perspektive der supply chain Optimierung habt ihr also buchstäblich das Problem, dass all diese Dinge miteinander verknüpft sein müssen, wenn ihr Optimierung liefern wollt – und genau da gerät alles ins Wanken.

Auf der Management-Seite kann man möglicherweise mit einem Produkt enden. Bei der supply chain Optimierung lautet die Antwort jedoch: Man kann es nicht. Ich meine, man kann so tun, als ob, aber buchstäblich, man kann es nicht. Selbst bei Lokad, das nicht als ein voraussagendes Unternehmen begann, das sich auf predictive supply chain Optimierung spezialisiert hat, sondern vielmehr als Forecasting as a Service. Wenn man auf den Lokad-Blog von 2008 zurückblickt, habe ich anfänglich mit der Zeitreihen–Prognose begonnen, was allerdings stark fehlgeleitet war. Trotzdem – so habe ich angefangen. Selbst bei der Zeitreihenprognose, die nur ein winziger Teil des gesamten Problems ist, ist es unbeherrschbar. Das ist mein Fazit, nachdem ich über 12 Jahre in diesem Geschäft bin.

Wenn wir in die spezifische Welt der Softwareentwicklung zurückkehren, ist das etwas ganz Besonderes. Es sei denn, ihr wurdet selbst als Softwareingenieur ausgebildet und kennt euch damit aus, wie große, erfolgreiche Softwareunternehmen Software produzieren – dann wisst ihr wahrscheinlich sehr wenig darüber. Es stellt sich heraus, dass es eine ganz spezielle Welt ist, mit vielen weitgehend kontraintuitiven Aspekten. Traditionelle Unternehmen, besonders solche mit einer klassischen Maschinenbau- oder Marketing-Mentalität, tun sich enorm schwer, überhaupt zu begreifen, wie Software funktioniert.

Diese Aspekte werden wir in zukünftigen Vorträgen ausführlicher behandeln, aber es gibt ein Buch, das mir wirklich gut gefällt, verfasst von Joel Spolsky, einem ehemaligen Microsoft-Mitarbeiter, der in den frühen Teams von Microsoft Excel arbeitete. Er ist außerdem Mitbegründer von Stack Overflow und Trello. Im Jahr 2004, als ich noch Student war, las ich sein Buch und seinen Blog. Das Buch trägt den Titel “Joel on Software” und vermittelt auf humorvolle Weise einen Eindruck davon, wie man ein erfolgreiches Softwaregeschäft führt. Es unterscheidet sich stark von dem, was die meisten Menschen außerhalb dieser Branche erwarten. Die Details zu diesem Buch werde ich in der Videobeschreibung ergänzen.

Aber lasst uns daran denken, dass supply chain Optimierung nicht euer durchschnittliches Softwareprodukt ist. Normalerweise, wenn ihr es mit einem durchschnittlichen Softwareprodukt zu tun habt – ich meine, ja, je nach Art des Softwareprodukts gibt es auch oppositionelles Verhalten. Wenn ihr es beispielsweise mit einem sozialen Netzwerk zu tun habt, können viele Menschen hasserfüllte Inhalte posten, was ein ganz anderes Spiel ist. Bei klassischer Unternehmenssoftware, wie Microsoft Word oder Excel, handelt es sich dagegen um ein Produkt, bei dem ihr das richtige Design haben wollt, aber bei dem es keinerlei Notfall gibt. Bei traditionellen Softwareprodukten ist es in Ordnung, Jahre darauf zu verwenden, euer Design und Produkt zu verfeinern. Es ist eine langfristige Investition, und ihr müsst Jahrzehnte vorausplanen. Es gibt keinen Grund, in der Entwicklung etwas zu überstürzen. Allerdings funktioniert supply chain Optimierung so nicht. Ihr habt keine Wahl, denn ständig passiert etwas, und das Terrain ist sehr rau.

Es kann zu extremen Situationen kommen, wie der Pandemie oder anderen Problemen wie Ransomware, die die Hälfte eures Netzwerks lahmlegen können. Ihr müsst kluge Entscheidungen treffen, um die Kapazitäten, die euch noch zur Verfügung stehen, optimal zu nutzen. Ihr könntet mit Flottenstilllegungen aufgrund tragischer Vorfälle, mit politischen Maßnahmen wie Zöllen, die eure Strategie stören, oder mit natürlichen Katastrophen wie Tsunamis oder Bränden und Hitzewellen, wie sie in Kalifornien oder Australien vorkommen, konfrontiert werden. Diese Ereignisse passieren, und wenn sie eintreten, müsst ihr buchstäblich innerhalb weniger Stunden reagieren können.

Ihr habt euer Softwareprodukt, aber ihr müsst Veränderungen herbeiführen, und ihr wollt programmatische Veränderungen umsetzen. Denkt daran, wenn ihr im Modus seid, ein Software-Asset zu liefern, habt ihr ein kleines Team, das die Software betreibt, welche wiederum eure supply chain antreibt. Ihr habt nicht eine Armee von Sachbearbeitern, die den ganzen Tag Brandbekämpfung leisten. Selbst wenn ihr eine Armee von Sachbearbeitern hättet, müsstet ihr diese schulen, und wenn etwas völlig Unerwartetes passiert, landet ihr mit einer Armee, die für diese spezielle Situation nicht trainiert wurde. Meiner Erfahrung nach gilt: Je mehr Menschen ihr managen müsst, desto länger dauert es, etwas zu erreichen.

Vor wenigen Tagen hat ein Frachtschiff über 1.800 Container aufgrund schlechter Wetterbedingungen verloren. Solche Dinge passieren einfach, und ihr könnt nicht hoffen, sie zu eliminieren. Supply chain ist nicht wie die Fertigung, bei der ihr vielleicht einen Produktionsstandort habt, an dem alles streng kontrolliert wird. Per Definition finden supply chains in einer weiten, unkontrollierbaren Welt statt, in der ihr meist keinen Einfluss auf die Elemente habt. Es gibt so viele Kräfte, die außerhalb eurer Kontrolle liegen, dass ihr in der Lage sein müsst, mit überraschenden Ereignissen umzugehen. Ihr wisst bereits, dass Überraschungen passieren werden, also müsst ihr vorbereitet sein. Vorbereitung bedeutet nicht, dass alles akribisch durchgeplant ist – es geht darum, ein System zu haben, in dem ihr, wenn nötig, innerhalb weniger Stunden reagieren könnt. Das ist das Wesentliche davon, wie man das Problem realistisch angehen kann.

Nun, was brauchen wir an Software-Komponenten für supply chain Optimierung? Zunächst benötigen wir vielseitigen Datenspeicher, um all die unterschiedlichen Arten von Datenquellen abzubilden. Es gibt so viele Dinge, die wir darstellen möchten, daher brauchen wir in dieser Hinsicht etwas sehr Vielseitiges mit viel Struktur und Varianz.

Zweitens benötigt ihr programmierbare Logik. Ich komme zurück zu dieser Idee: Wenn ihr keine programmierbare Logik habt, wie bewältigt ihr dann all diese Probleme? Wie fügt ihr all diese Dinge zusammen? Ihr könnt kein fertiges Produkt kaufen, das bereits alles für euch vorprogrammiert hat – das funktioniert einfach nicht.

Als Nächstes braucht ihr vielseitige Benutzeroberflächen, denn die Art und Weise, wie ihr eure Probleme betrachtet, kann von Situation zu Situation enorm variieren. Die KPIs werden von Unternehmen zu Unternehmen völlig unterschiedlich sein, weshalb ihr eine vielseitige Benutzeroberfläche benötigt, mit der ihr die Zahlen auf jede erdenkliche Weise präsentieren könnt; andernfalls stellt das eine große Einschränkung dar.

Ihr benötigt auch kollaborative Fähigkeiten, denn supply chain ist definitionsgemäß Teamarbeit. Es sind viele Menschen beteiligt und es ist verteilt, weshalb kollaborative Fähigkeiten im Mittelpunkt stehen müssen.

Schließlich – und vielleicht etwas umstrittener – benötigt ihr programmierbare Funktionen, die auch für Menschen zugänglich sind, die keine ausgebildeten Softwareingenieure sind. Das ist aus mehreren Gründen wichtig. Erstens gibt es nicht viele ausgebildete Softwareingenieure auf dem Arbeitsmarkt, sodass es sehr wettbewerbsintensiv ist, diese einzustellen. Zweitens erfordert es so viel Mühe und Engagement, ein talentierter Softwareingenieur zu werden, dass es herausfordernd ist, gleichzeitig ein supply chain specialist zu sein.

Es ist nicht sehr üblich, Menschen zu finden, die in beiden Bereichen über Doppelkompetenzen verfügen. Dasselbe würde gelten, wenn ihr jemand sucht, der sowohl Programmierer als auch Jurist ist oder sowohl Programmierer als auch Arzt. Ja, ihr werdet einige Menschen mit diesen Fähigkeiten finden, aber könnt ihr das im großen Maßstab umsetzen oder zuverlässig jedes Jahr mehr von ihnen einstellen, wenn ihr ein großes Unternehmen seid? Nach meiner Erfahrung, Lokad ein Jahrzehnt lang zu führen, funktioniert das einfach nicht.

Ihr wollt etwas Programmierbares, aber ihr müsst kein professionell ausgebildeter Softwareingenieur sein, um mit der Programmierung umzugehen. Denkt daran, ihr braucht jemanden mit supply chain Kompetenz, denn ihr müsst in der Lage sein, innerhalb weniger Stunden programmatische Korrekturen an eurem System vorzunehmen, ohne ein Ticket zu eröffnen und es an die IT weiterzuleiten. Wenn ihr das so machen müsst, dauert es Wochen, Probleme zu beheben – nicht Stunden. Also, welche Art von Software kann das Problem eigentlich lösen?

Naja, Excel kann es. Es ist nicht hübsch und mag sich nicht wie der Gipfel moderner Software anfühlen, aber es erfüllt seinen Zweck. Es trifft alle Anforderungen.

Vielseitiger Datenspeicher? Ja, bis zu einem gewissen Grad kann man in Excel sehr viele Daten jeglicher Art unterbringen. Programmierbare Logik? Absolut, Excel ist völlig programmierbar. Vielseitige Benutzeroberfläche? Ja, man kann Balkendiagramme, Liniendiagramme und viele weitere Möglichkeiten zur Darstellung von Daten erstellen. Was die Benutzeroberflächen betrifft, ist es sehr vielseitig. Es mag nicht das am besten ausgearbeitete sein, aber in Sachen Vielseitigkeit kann es vieles leisten.

In puncto kollaborative Fähigkeiten ist es etwas grob. Es gibt einige Versionen von Excel, die online verfügbar sind und etwas besser funktionieren, aber grundsätzlich könnt ihr eure Tabellenkalkulationen teilen. Das Problem des Mangels an kollaborativen Funktionen liegt nicht daran, dass es sich um eine Desktop-Anwendung handelt. Das Problem liegt in der Denkweise hinter Tabellenkalkulationen, die für intensive Zusammenarbeit nicht geeignet ist. Üblicherweise, wenn ein Kollege eine sehr komplexe Tabelle erstellt hat, ist es einfacher, diese neu zu erstellen, als herauszufinden, was er gemacht hat. Das Problem des Mangels an kollaborativen Funktionen ist also die Denkweise, die mit Tabellenkalkulationen einhergeht und die von Natur aus starke Grenzen für die Zusammenarbeit aufweist.

Allerdings ist Excel völlig zugänglich für Nicht-Entwickler, und es gibt sogar Visual Basic for Applications für komplexere Aufgaben. Was die Komponenten angeht, erfüllt Excel alle Anforderungen, was meines Erachtens weitgehend den operativen Erfolg in den meisten supply chains erklärt.

Meiner Erfahrung nach werden die meisten supply chains weltweit – von den kleinsten Unternehmen bis zu den größten und von denen, die noch nie einen Cent in Unternehmenssoftware investiert haben, bis zu denen, die Millionen von Dollar in komplizierte Unternehmenssoftware für supply chain Optimierung investiert haben – von Excel angetrieben. Es gibt nur sehr wenige Ausnahmen. Manchmal nutzen Menschen Excel, um Min-Max-Einstellungen in anderer Software zu überarbeiten, aber die Wartung dieser Einstellungen wird jenen überlassen, die mit Excel arbeiten.

Excel treibt heute die Welt der supply chain an, und ich glaube, das ist kein Zufall. Im Kern greifen Tabellenkalkulationen viele der richtigen Themen an. Viele andere Optionen werden als überlegen dargestellt, scheitern jedoch von vornherein, wenn ihr nicht programmieren könnt. Wenn ihr nicht programmieren könnt, bedeutet das, dass ihr bei einem größeren Problem oder Notfall kein Glück habt. In Situationen, in denen eine vielseitige Benutzeroberfläche fehlt oder eine Lösung für Nicht-Entwickler nicht zugänglich ist, greifen die Leute auf Excel-Tabellen zurück. Wenn nur ein IT-Team Ergebnisse liefern kann, eröffnen die Leute zunächst Tickets und warten geduldig, aber innerhalb von drei Monaten greifen wahrscheinlich alle wieder auf Excel-Tabellen zurück, weil es schneller geht. Excel ist nicht das Endziel, aber was auch immer wir als überlegenen Ersatz einführen, es muss alle Anforderungen erfüllen.

Wie können wir etwas verbessern? In Bezug auf vielseitige Datenspeicherung ist Excel gut, aber nicht sehr skalierbar. Die Verarbeitung von Millionen von Zeilen wird zu einem Problem, selbst mit modernen Excel-Versionen, die eine Million Zeilen handhaben können. Leistungsprobleme treten schnell auf, wenn man in großem Maßstab arbeitet. Programmlogik in Excel ist möglich, aber sie ist sehr fragil und instabil. Wenn Sie versehentlich einen Fehler oder Bug in Ihrer Tabelle einführen, wird das Debuggen und Lokalisieren der Fehlerquelle zu einem Albtraum. Die Logik wird endlos dupliziert, was zu Tausenden von Kopien derselben Logik führt und es schwierig macht, Fehler zu identifizieren und zu beheben.

Die Benutzeroberfläche ist nicht ideal, da sie nicht vollständig webbasiert ist und die Daten stets mit der Oberfläche verflochten sind. Kollaborative Funktionen gibt es zwar, aber sie sind unordentlich. Zusammenarbeit sollte auf der Ebene der programmgesteuerten Logik erfolgen. Viele Anbieter von supply chain optimization bieten Zusammenarbeit an, etwa indem sie Prognosen manuell anpassen und mehreren Personen die Teilhabe ermöglichen. Allerdings ist dies der falsche Ansatz. Zusammenarbeit muss stattfinden, aber sie sollte auf der logischen Ebene, also der Ebene der programmgesteuerten Logik, erfolgen. Excel ist für Nicht-Entwickler sehr zugänglich, aber wenn Sie etwas etwas Komplexeres tun möchten, wird es herausfordernd. Im supply chain management wollen wir uns mit allen möglichen Zukunftsszenarien befassen, was bedeutet, dass wir mit probabilistischen Prognosen, Zufallsvariablen und der Berücksichtigung von Unsicherheiten arbeiten. Zwar ist dies in Excel möglich, aber es ist ziemlich kompliziert. Excel ist einfach für einfache Aufgaben, aber für komplexere Situationen müssen Sie ein Excel-Zauberer werden.

Wartbarkeit ist wichtig, denn Sie wollen ein Asset mit wachsendem Wert im Laufe der Zeit aufbauen. Mit Tabellenkalkulationen ist es schwierig, dies zu erreichen, und es ist schwer, etwas wirklich Präzises zu erstellen – zumindest im Sinne eines Softwareprodukts.

Die Schlagworte des Tages sind AI und Python, mit all den Trends und dem Hype rund um Data Science. Allerdings glaube ich, dass Python im supply chain management Excel unterlegen ist.

Verstehen Sie mich nicht falsch; ich liebe Python und halte es für eine brillante Sprache. Ich unterrichte es sogar meiner 10-jährigen Tochter. Dennoch gibt es mehrere Gründe, warum Python nicht die beste Wahl für supply chain management ist. Erstens erfordert es Softwareingenieure. Obwohl Python eine der zugänglichsten Programmiersprachen ist, benötigt man, wenn man etwas Komplexeres tun möchte, ein Software-Engineering-Team, was zu Herausforderungen führt, wenn man Menschen braucht, die sowohl supply chain-Experten als auch Softwareingenieure sind.

Python hat gute Eigenschaften, aber die Art und Weise, wie Abhängigkeiten gehandhabt werden, ist recht komplex und das Paketmanagement ist mangelhaft. Pakete sind Bausteine, die zusätzliche Fähigkeiten bieten, und wenn Sie sagen, dass Sie Python verwenden möchten, interessiert Sie nicht nur die Sprache, sondern auch das gesamte Ökosystem der Pakete – wie NumPy, Pandas, TensorFlow und SciPy – all diese Drittanbieter-Abhängigkeiten beziehungsweise Softwarebibliotheken. Das Paketmanagement ist seit über einem Jahrzehnt unzureichend, und obwohl sich dies verbessert, geht der Fortschritt nur schleppend voran. Es gibt viele Aspekte des Systemdesigns, die es schwierig machen, es zu erweitern.

Die Leistungsfähigkeit ist ebenfalls schlecht, meist absichtlich so gestaltet. Die Rechenleistung bezieht sich auf die Qualität der Arbeit, die Python leistet, um die rohe Rechenleistung Ihres Computers auszuschöpfen. Überraschenderweise schneidet Microsoft Excel in dieser Hinsicht deutlich besser ab. Excel ist hoch optimiert, nutzt Multi-CPU- und Multi-Core-Systeme und führt nativ kompilierte Logik aus. Microsoft hat viel investiert, um Excel extrem schnell zu machen.

Im Gegensatz dazu hat Python inhärente Probleme, die oft dazu führen, dass die Leistung 100 Mal langsamer ist, als Ihr Rechner theoretisch leisten könnte. Auch wenn das angesichts der Leistungsfähigkeit moderner Computer für manche akzeptabel erscheinen mag, ist es nicht ideal für Unternehmen mit Transaktionsvolumina von über 50 Millionen Dollar. Man möchte etwas, das sofort eine gute Leistung liefert.

Der Gedanke, eine Drittanbieter-Bibliothek wie NumPy zu verwenden, um das Leistungsdefizit von Python auszugleichen, fügt nur zusätzliche Komplexität hinzu. Möglicherweise lösen Sie damit das Leistungsproblem, aber Sie schaffen ein neues Problem, indem Sie die zusätzliche Komplexität von NumPy einführen, mit der Sie sich im Laufe der Zeit auseinandersetzen und die Sie warten müssen. Dies erhöht auch die Anforderungen an den Software-Engineering-Bereich.

Wenn man versucht, Python-Lösungen für echtes supply chain management umzusetzen, treten verschiedene Probleme auf, wie Nullreferenzausnahmen, Out-of-Memory-Ausnahmen und lange Berechnungszeiten. Es kann vorkommen, dass Sie 20 Minuten auf den Abschluss einer Berechnung warten und sich unsicher sind, ob sie jemals fertig wird oder ob Sie den Prozess einfach beenden und neu starten sollten. Ich weiß es einfach nicht, daher möchte man Dinge, bei denen man eine sehr, sehr gute Vorstellung davon hat, wie viel Zeit die Ausführung in Anspruch nehmen wird. Übrigens: Heutzutage gibt Excel, wenn eine Operation etwas Zeit in Anspruch nimmt, einen ziemlich zuverlässigen Indikator, eine Fortschrittsanzeige, die zeigt, wie lange es dauert. Also noch einmal: Man möchte – und das ist ein Teil dessen, was ich als Produktionsbereitschaft bezeichne – etwas, das, weil die von Ihnen produzierte Software höchstwahrscheinlich unbeaufsichtigt läuft, etwa nachts oder während des nächtlichen Batch-Prozesses, keine ständige Betreuung durch einen Data Scientist erfordert.

Und nochmals: Wenn Sie bereits Probleme mit Data Scientists haben, dann benötigen Sie die dritte Kompetenz: supply chain expert, Software-Engineering-Experte und nun einen Data Scientist-Experten. Es ist zwar möglich, all diese drei Eigenschaften in einer Person zu vereinen, aber viel Glück dabei, mehr als eine Person pro Jahr einzustellen, selbst wenn Sie ein großes Unternehmen sind, das über all diese Fähigkeiten verfügt. Das ist einfach extrem selten.

Also wollen wir etwas haben, das sich verbessert. Übrigens: Das Erste, was wir verbessern wollen, ist Defense in Depth. Ransomware nimmt zu, und wann immer Sie etwas Programmierbares in Ihre Organisation einführen, setzen Sie sich dem Risiko von Ransomware aus. Denn plötzlich kann ein Programm, das auf einer Maschine läuft, eine Menge an Dingen tun – etwa die Maschine, auf der es läuft, kapern. Ich weiß, dass es unzählige Möglichkeiten gibt, die Probleme zu mindern; man kann Dinge in einer Sandbox ausführen, Beschränkungen auferlegen, eingeschränkte Rechte vergeben – es gibt viele Wege, die Problematik zu begrenzen. Dennoch: Wann immer Sie etwas wie eine generische, allgemeine Programmiersprache einsetzen, ist Ihre Angriffsfläche – ein technischer Begriff – absolut gigantisch.

Im Grunde genommen, wann immer Sie solchen Code einbinden, setzen Sie sich massiv in Bezug auf Sicherheitsprobleme aus. Und denken Sie daran: Wie es typischerweise in einem normalen Software-Engineering-Unternehmen gehandhabt wird, unterzieht man den Code einem Peer-Review. Man überprüft den Code, hat einen Code-Review-Prozess, jemand schreibt den Code, und ein Kollege überprüft ihn, um sicherzustellen, dass keine Schabernack darin versteckt sind. Aber wenn ich daran denke, dass die Software robust sein muss und man innerhalb von Stunden reagieren können muss, werden Sie aus der Perspektive der supply chain optimization niemals einen Code-Review-Prozess haben können. Das ist einfach nicht kompatibel mit den Verzögerungen und Notfällen, denen Sie begegnen werden.

Also benötigen Sie etwas, das Ihnen von vornherein Defense in Depth bietet. Dann möchten Sie etwas mit transparenter Leistung, bei dem ja, Dinge ihre Zeit brauchen können, Sie aber die Kontrolle behalten. Sie müssen im Voraus wissen, wie lange es dauert. Wenn Sie das nicht haben, setzen Sie sich einer Menge sehr dummer Probleme aus, wie etwa ein Zwei-Stunden-Fenster zur Ergebnisauslieferung zu haben und dennoch zu spät zu kommen. Und wissen Sie was? Die LKWs sind schon abgefahren. Es ist zu spät. Sie brauchen also etwas, das das Problem von vornherein löst.

Und genauso verhält es sich bei transparenten Upgrades. Das ist das Schöne an Excel. Man muss sich nicht um die Wartung von Excel kümmern. Microsoft hat vor Jahrzehnten einen Bluteid-Pakt geschlossen, der besagte: Wenn Sie eine Excel-Tabelle erstellt haben, wird jede kommende Excel-Version, die auf den Markt kommt, in der Lage sein, Ihre Tabellen zu unterstützen. Und das Erstaunlichste ist, dass, wenn man sich Excel heutzutage anschaut, es viele konkurrierende Excel-Formate von Wettbewerbern unterstützt, die es gar nicht mehr gibt. Sie können immer noch Tabellenkalkulationen lesen, die mit Lotus Notes und dergleichen erstellt wurden. Microsofts Wertangebot im Hinblick auf transparente Upgrades besteht also darin, dass die von Ihnen erstellte Logik ewig funktionieren wird, und ja, sie werden Excel noch Jahrzehnte lang weiter verbessern – aber wissen Sie was? Es ist geregelt. Das sieht man nicht, wenn man den Übergang von Python 2 zu Python 3 betrachtet; das war ein Albtraum und hat ein Jahrzehnt gedauert. Python ist also großartig für vieles, aber stellen Sie sich vor, dass diese Upgrades in den schlimmsten Momenten erfolgen, in denen Sie die schlimmste Pandemie, den schlimmsten Zoll, den schlimmsten Notfall haben und alles betriebsbereit sein muss. Sie können es sich nicht leisten, sechs Monate Ausfallzeit zu haben, nur weil Sie sich um ein Upgrade kümmern müssen. Das ist einfach nicht kompatibel mit supply chain optimization.

Also müssen wir uns nun überlegen, was wäre, wenn wir tatsächlich etwas in Betracht ziehen würden, das speziell für supply chain entwickelt wird? Das wird das Thema der nächsten Vorlesung sein.

Nun ist supply chain auch nicht die IT-Abteilung. Wenn ich von einer produktorientierten Lieferung spreche, ist es wieder nicht so, dass die Software lediglich ein Mittel zum Zweck, nicht das Ziel, darstellt. Sie werden Ihre Software nicht für Lizenzen oder eine Gebühr verkaufen, wie es beispielsweise Microsoft tut. In dieser Vision, die ich in dieser Vorlesung vor Ihnen skizziere, ist IT verantwortlich für die Kernpraktiken, die grundlegenden IT-Praktiken – also dafür, was Sie in Bezug auf Sicherheit, Backups, Kerninfrastruktur, Ihr Netzwerk, das Management und die Synchronisation aller Daten auf Unternehmensebene tun sollten oder nicht – und für die Bereitstellung sämtlicher Anleitung und Coachings.

Aber die Idee ist, dass supply chain die supply chain-Entscheidungen selbst in die Hand nehmen muss. Sie müssen das gesamte System besitzen, das diese supply chain-Entscheidungen generiert – das ist ihr Kernbesitz. In der vorherigen Vorlesung habe ich erklärt, was den Supply Chain Scientist definiert: Der Supply Chain Scientist ist jemand, der die numerischen Entscheidungen, die durch den Code erzeugt wurden, besitzt. Es handelt sich also nicht um ein System, das Entscheidungen produziert, sondern um numerische Rezepte, die von einem oder mehreren Supply Chain Scientists niedergeschrieben wurden, und diese Supply Chain Scientists besitzen diese numerischen Entscheidungen gemeinsam. Sie übernehmen die Verantwortung dafür, und es liegt in der Pflicht der supply chain, dafür zu sorgen, dass alle Entscheidungen im Unternehmen konsistent sind. Wenn gerade eine Promotion läuft oder ein großer Marketing-Schub erfolgt, müssen die Ergebnisse rechtzeitig produziert werden, damit sie bereit zur Auslieferung sind. Sie wollen nicht in einer katastrophalen Situation enden, in der Sie etwas pushen, während Sie sich bereits in einer nahezu stock-out Situation befinden – in der Sie Geld in einen Marketing-Schub investieren für etwas, das Sie nicht einmal verkaufen können, weil Sie weder den Bestand noch die Kapazität zur Produktion oder zur rechtzeitigen Bereitstellung des Service haben.

Also haben wir zwei Abteilungen mit sehr unterschiedlichen Schwerpunkten. In meiner idealen Vorstellung davon, wie die IT-Abteilung sein sollte, ist die IT-Abteilung keine Einheit, in der man einfach Tickets weiterleitet. So funktioniert das nicht. Die IT-Abteilung kümmert sich um die Kerninfrastruktur. Sie ist so etwas, das stets nahtlos funktioniert. Man nimmt sie gar nicht wahr – genauso wie das WLAN funktioniert. Man achtet nicht auf das WLAN; man bemerkt es nur, wenn es nicht funktioniert. Eine gute IT-Abteilung liefert die gesamte Infrastruktur, sodass man gar nicht erst auf sie aufmerksam wird. Man merkt nicht einmal, dass sie existiert, weil alles einfach funktioniert – genauso wie Ihre E-Mails einwandfrei laufen, usw. Darin liegt die Stärke einer guten Core-IT. Und dann sind da die IT-Leute, die zu Ihnen kommen und Ihnen helfen, all jene Praktiken zu etablieren, die Sie unterstützen. Programmgesteuerte Logik ist etwas anspruchsvoll, daher stellt sich manchmal die Frage, woher man das Coaching bekommt, um programmiertechnisch ein wenig besser zu werden. Die Antwort lautet: Es sollte die IT sein. Sie sollten nicht kommen und sagen: „Wir werden den Code für Sie schreiben“, sondern vielmehr: „Wir werden Sie coachen, damit Sie es selbst umsetzen können. Wir helfen Ihnen mit einigen Konzepten, vielleicht auch mit Dingen, die etwas technischer sind, als sie sein sollten.“ Manchmal gibt es unbeabsichtigte Komplexität, und da ist die IT, um Sie zu unterstützen. Aber grundsätzlich ist sie nicht dazu da, die Arbeit für Sie zu erledigen. Sie sollten als Mentoren und Coaches agieren und sicherstellen, dass niemand einen katastrophalen Fehler macht, der das gesamte Unternehmen etwa einem Risiko von Ransomware oder einem systemischen IT-Risiko aussetzt.

Als Lackmustest gilt: Wenn Ihre Interaktion zwischen IT und supply chain über Dokumente verläuft, in denen Sie Spezifikationen oder Anforderungen auflisten, ist das nicht der richtige Weg, um eine gute Beziehung zwischen diesen beiden Abteilungen zu pflegen. Mit guter Beziehung meine ich etwas, das dem Unternehmen tatsächlich einen Mehrwert bietet.

Zusammenfassend haben wir hier zwei Herausforderungen auf Seiten des traditionellen supply chain management, das vielleicht schon programmiert hat – wenn auch nur am Rande mit Excel-Tabellen, ohne überhaupt zu realisieren, dass das schon eine Form des Programmierens ist. Sie müssen Ihre Ängste überwinden. Sie müssen daran denken, dass die Welt von morgen, also Ihre Abteilung, dafür verantwortlich sein wird, ein Produkt bereitzustellen, das wie ein Softwareprodukt läuft – und das ist ein enormer Wandel. Ja, aber es ist etwas, mit dem Sie zurechtkommen können. Warum? Weil, wenn Sie die richtigen Werkzeuge haben, ja, es ist Programmierung involviert, aber es ist grundsätzlich nicht radikal schwieriger als Excel. Noch einmal: Die Herausforderung liegt nicht in der technischen Komplexität des Werkzeugs, sondern buchstäblich in der Komplexität der supply chain selbst. Das Problem ist schwierig – nicht, weil Ihr Werkzeug schwer zu handhaben ist, sondern weil Sie von Anfang an eine komplizierte supply chain haben.

Für den Teil des Publikums, der vielleicht eher auf der Data Scientist- oder IT-Seite steht, gilt es, Überkonfidenz zu überwinden. Ich habe immer wieder Data Scientists gesehen – und ich schließe mich selbst in diese Kategorie ein – die zu selbstsicher in ihrer Fähigkeit waren, einen Prototyp in die Produktion zu überführen. Das ist schwierig, und supply chains haben die Angewohnheit, einem auf die überraschendste Weise in die Quere zu kommen. Ich kann mich nur an eine Anekdote erinnern, bei der wir vor Jahren mit einem führenden europäischen E-Commerce-Unternehmen für Autoersatzteile begannen. Wir kümmerten uns um deren Teile-Nachschubbestellungen mit unserer Forecasting-Technologie, machten Vorschläge für den Nachschub von Autoteilen. In der darauffolgenden Woche stellten wir fest, dass alle unsere Prognosen um den Faktor zwei danebenlagen. Die Nachfrage hatte sich verdoppelt. Es stellte sich heraus, dass ihr größter Konkurrent beschlossen hatte, gleichzeitig in mehrere Länder vorzustoßen – buchstäblich genau in dem Moment, als wir mit unserer Prognose begannen, hatte einer der Konkurrenten beschlossen, in allen nationalen Fernsehsendern aufzutreten und seinen Service online zu präsentieren. Das Interessante daran war, dass mein Kunde dem nicht einmal bewusst war, und sie hatten bessere Ergebnisse bei der Suchmaschinenoptimierung. Sie waren in Bezug auf SEO besser optimiert, sodass die Leute im Grunde die TV-Werbung des Konkurrenten sahen, sich aber nicht automatisch an den Namen des Konkurrenten erinnerten. Also gingen sie zu Google und gaben “car parts” ein, bis sie auf der Website meines Kunden landeten. Um zu demonstrieren, wie großartig Lokad ist, lagen wir in der ersten Woche, als wir starteten, um den Faktor zwei daneben und dachten: “Was zum Teufel geht hier vor?” Wir mussten alles überarbeiten, denn wenn sich die Nachfrage verdoppelt, dann verdoppelt nicht alles; manche Dinge steigen um das Zehnfache, und vieles bleibt unberührt.

Das ist also die Art von Situation, in der man schnell reagieren können muss. Darum geht es: Angst und Überkonfidenz. Vielen Dank für Ihre Zeit.

Nun werde ich mir die Fragen im Chat anschauen.

Question: Kann die Software die Entscheidung treffen, bei welchem Lieferanten eine zusätzliche Bestellung aufgegeben werden soll, falls für morgen mehr benötigt wird? Zum Beispiel könnten 200-Gramm-Schalen mit Erdbeeren in Büros in Australien von 10 Lieferanten beliefert werden, die am selben Tag die gleichen Produkte an das Distributionszentrum liefern.

Absolut, und hier müssen wir zwischen den beiden Seiten des supply chain management und der supply chain optimization unterscheiden. Es gibt die supply chain management-Seite, die buchstäblich alle data pipelines umfasst, einschließlich EDI, über die man eine elektronische Bestellung an einen Lieferanten ohne menschliches Eingreifen übermitteln kann. So hat man eine elektronische End-to-End-Brücke. Aber das bedeutet auch, dass man auf der Optimierungsseite eine Software benötigt, die den ganzen Tag über kontinuierlich läuft und irgendwann die management-Seite benachrichtigen kann mit der Nachricht, “Bitte führen Sie diesen Auftrag aus.” Und dann stellt die management-Seite, die von der IT verwaltet wird, einfach sicher, dass dieser Auftrag vollständig ausgeführt wird. Es ist einfach eine Frage reiner Transaktionalität; es steckt keine Intelligenz dahinter. Man hat einen Auftrag erhalten, der “diese Menge” angibt, und es ist die Optimierungsseite, die dafür verantwortlich ist, dass beim Generieren einer bestimmten Menge alle Vorgaben eingehalten werden – etwa die exakte Liste der Lieferanten, die überhaupt berechtigt sind, diese Produkte zu bedienen, ob sie noch Lagerbestand haben und wie die richtige Wahl zwischen all den konkurrierenden Lieferanten getroffen wird, etc. Es können viele Dinge gleichzeitig eine Rolle spielen. Absolut, ja, aber wir müssen die alltägliche Ausführung – den transaktionalen Teil, der auf der supply chain management-Seite liegt – von dem Optimierungsaspekt trennen, der zu dem Zeitpunkt hinzukommt, in dem man entscheidet, dass man mehr nachbestellen muss.

Question: Wissen Sie, dass Sie momentan mit den eSports World Championships konkurrieren?

Nein, ich konkurriere derzeit nicht mit diesen eSports Championships, aber es ist sehr cool. Übrigens, bei Lokad spielen wir häufig Dota 2, weshalb auch das Management-Team mitspielt. Einige unserer Mitarbeiter möchten League of Legends spielen, aber als CEO des Unternehmens lehne ich das entschieden ab.

Question: Ich habe gesehen, dass viele Unternehmen zunächst weder ein ERP noch ein WMS besitzen und dass das Management an supply chain optimization arbeitet.

Nun, absolut. Supply chain optimization kann man von Tag eins nicht vermeiden; diese Entscheidungen müssen getroffen werden. Supply chain optimization gab es schon, bevor irgendeine Art von supply chain management-Software vorhanden war. Selbst wenn man 60 Jahre in die Vergangenheit blickt, als es noch keine Software gab, mussten die Menschen Entscheidungen treffen. Supply chain optimization war also bereits Realität; die Menschen machten es damals mit Stift und Papier. Wenn man sich die frühesten Arbeiten im Bereich supply chain anschaut, wie die Wilson-Formel, auch bekannt als die EOQ Formel, ist diese schon ein Jahrhundert alt. Sie geht eindeutig der Software voraus. Also ja, supply chain optimization ist etwas, das von Anfang an stattfindet, unabhängig davon, ob in Ihrem Unternehmen Software vorhanden ist oder nicht.

Nun, tatsächlich, man muss über adäquate IT-Systeme verfügen, aber es erfordert eine völlig andere Denkweise. Supply chain management dreht sich darum, alltägliche Aufgaben sehr gut zu erledigen – wie beispielsweise die Dateneingabe, möglicherweise unterstützt durch Barcodes und andere Hilfsmittel. Es geht um ganz gewöhnliche Aufgaben, also lediglich um die Darstellung der Daten. Das Problem ist, dass die Menschen etwas wollen, das sowohl supply chain management als auch supply chain optimization abdeckt, und infolgedessen erhält man ein Produkt, das überkompliziert ist, meist voller Fehler steckt und über ungewollte Funktionen wie Alarmmeldungen und Ausnahmebehandlungen verfügt, die man vermeiden sollte. Darauf werde ich in einer späteren Vorlesung noch zurückkommen.

Grundsätzlich ist es heutzutage, ein WMS oder ein ERP einzuführen – falls Sie noch keines haben – innerhalb weniger Wochen machbar. Haben Sie bereits eines, kann es Monate dauern, wenn Sie dieses System von Ihren Entscheidungsprozessen entkoppeln müssen.

Question: Wann kann das Management eines Unternehmens erkennen, dass es an der Zeit ist, von der reinen Verfolgung von Informationen zur Optimierung von supply chain-Entscheidungen überzugehen und sich letztlich auf supply chain optimization zu konzentrieren?

Zunächst einmal muss man überhaupt erkennen, dass es zwei Probleme gibt und dass dasselbe Stück Software niemals beide Perspektiven abdecken kann. Ich denke, das ist die große Illusion, und Softwareanbieter sind in diesem Bereich unglaublich verwirrend. Wenn Sie sich die größten ERP-Anbieter ansehen, dann lautet deren Botschaft supply chain optimization, aber alles, was sie tatsächlich liefern und was ihr Produkt wirklich leistet, bewegt sich auf der supply chain management-Seite, die weitaus weniger attraktiv ist, weil dort keine KI oder echte Intelligenz im Spiel ist. In der Softwarewelt spricht man hier von CRUD-Apps (Create, Read, Update, Delete). ERPs sind einfach gigantische Sammlungen von CRUD-Bildschirmen, bei denen jeder einzelne Bildschirm in der Lage ist, Zeilen aus einer relationalen Datenbank zu erstellen, abzurufen, zu aktualisieren oder zu löschen – und das war’s auch schon. Ein ERP ist im Grunde, vereinfacht ausgedrückt, eine Sammlung von Tausenden von Tabellen für verschiedene Entitäten. Für jede logisch gruppierbare Entität gibt es ein oder zwei Bildschirme – und das war’s. Wenn ich also auf Ihre Frage bezüglich des Managements zurückkomme, besteht das Problem darin, dass, wenn Sie als Manager die Broschüre des ERP-Anbieters lesen, diese Ihnen verspricht, Ihre supply chain zu optimieren, die Antwort lautet: Nein, absolut nicht. Was es bewirkt, ist, die Produktivität zu steigern und eine genaue Buchführung Ihrer supply chain sicherzustellen. Das allein ist schon sehr wertvoll, da es Diebstahl, Schwund und verlegte Waren dramatisch reduzieren und die Produktivität im Lager mithilfe von Barcodes verbessern kann. Diese Produkte bieten einen enormen Mehrwert. Ich möchte den Wert, den ein ERP oder WMS an sich liefert, keineswegs schmälern; er ist enorm, aber es geht nicht um supply chain optimization. Ein WMS beispielsweise ist per Design etwas, das sich um das Lager kümmert; es befasst sich nicht mit der gesamten supply chain, die auch Kunden und Lieferanten umfasst. Es ist von vornherein auf bestimmte Standorte fokussiert und nicht auf die komplette Kette.

Question: Wie können Sie nahtlos von Python zu Envision übergehen oder die beiden zusammenarbeiten lassen?

Wir haben sie historisch in einigen Situationen zusammenarbeiten lassen. Für das Publikum: Envision ist eine domänenspezifische Programmiersprache, die von Lokad entwickelt wurde und ausschließlich für die predictive optimization von supply chains konzipiert ist. In der nächsten Vorlesung werde ich Envision demonstrieren, damit die Leute eine bessere Vorstellung davon bekommen, wovon ich spreche – mit echten Codebeispielen.

Historisch gesehen haben wir Python und Envision zusammen eingesetzt, weil Envision zu Beginn sehr eingeschränkte Möglichkeiten hatte, sodass vieles fehlte und wir in vielen Situationen auf Python zurückgegriffen haben. Im Laufe der Jahre haben wir die Fähigkeiten von Envision nach und nach erweitert, sodass der Bedarf an Python-Komponenten schrittweise entfiel. Es sind nicht nur Python-Komponenten; es handelt sich auch um eine Reihe von Werkzeugen, die miteinander verbunden werden müssen, wie etwa Airflow.

Übrigens wurde die Syntax von Envision absichtlich in vielerlei Hinsicht an Python angelehnt. Ich habe mich bewusst dafür entschieden, die Syntax von Envision so zu gestalten, dass sie Python-Programmierer nicht vor den Kopf stößt, sodass, wenn man mit Python vertraut ist, man Envision in einer Woche erlernen kann. Es gibt dabei subtile und tiefgreifende Unterschiede, aber was die Syntax angeht, gibt es viele Gemeinsamkeiten. Python hat viele Vorzüge, wie etwa Einfachheit und Reinheit im Design. Auch wenn ich sage, dass Python nicht alle Anforderungen erfüllt und in der Produktion schwerwiegende, nicht zu beheben Probleme verursachen kann, heißt das nicht, dass Python ohne Vorzüge ist. Das ist nicht, was ich sagen möchte. Ich bin überzeugt, dass Python viele Vorzüge besitzt. Nochmals: Wir sprechen hier speziell darüber, wie man supply chains in der Produktion betreibt, was ein sehr spezifisches Problem darstellt.

Question: Wie würden Sie einem Kunden klarmachen, dass sein ERP nichts optimiert?

Das ist sehr schwierig, denn ehrlich gesagt, ist die schlimmste Situation, wenn ein Interessent zu mir kommt und sagt: “Unser ERP, ein Legacy-ERP, bringt keinen Nutzen, und jetzt wollen wir zum nächsten ERP wechseln, das supply chain optimization liefert.” Das ist eine furchtbare Situation für mich, denn ich muss dem Kunden erklären, dass das, wonach er sucht, nicht ein Produkt, sondern zwei Produkte sind: eines, das sein ERP ersetzt und den management-Aspekt besser abwickelt, und ein weiteres, das die Optimierung übernimmt.

Wenn man an diese Legacy-ERPs denkt, habe ich großen Respekt vor ihnen, besonders vor diesen AS/400-Produkten mit einem Kommandozeilen-Terminal auf altmodischen IBM-Mainframes. Was den management-Aspekt betrifft, leisten sie meist einen sehr guten Job. Was die Kunden wirklich suchen, könnte eine Web-Oberfläche anstelle einer Kommandozeile sein, aber wird dies ihre Teams vor Ort produktiver machen? Daran zweifle ich. Kommandozeilen mit textbasierten Terminals können unglaublich schnell und produktiv sein – ohne jegliche Ablenkung.

Also, es ist ziemlich schwierig, denn wir müssen all den Unsinn entwirren, den unsere Wettbewerber verbreiten. Darüber hinaus müssen wir erklären, dass das ERP die supply chain nicht optimiert und dass es so etwas wie KI oder Blockchain nicht gibt, sondern nur Klassen statistischer Modelle. Leider verlieren wir in dieser Phase die meisten unserer Interessenten. Das ist einer der Gründe, warum ich diese Vorlesungen überhaupt halte – denn es dauert Stunden, bis man alles im Detail durchdrungen hat und erklären kann, warum wir das Problem so sehen müssen, wie ich es sehe.

Question: Was ist Ihre Empfehlung für eine Plattform, um die Komplexität der Planung mehrerer Produkte mit probabilistischer Nachfrageverteilung anzugehen?

Nun, Lokad natürlich. Aber bedenken Sie, dass ich als CEO von Lokad und Mehrheitsgesellschafter des Unternehmens in meiner Meinung einen Interessenkonflikt habe. Ich bin fest davon überzeugt, dass Lokad die Plattform ist, die Sie brauchen, aber bitte berücksichtigen Sie, dass es auch das Unternehmen ist, das ich besitze und leite. Ich werde mein Bestes tun, in dieser Hinsicht objektiv zu bleiben.

Übrigens wurde Lokad buchstäblich dafür entwickelt, mit probabilistischer Nachfrageverteilung umzugehen – und es geht nicht nur um probabilistische Nachfrageverteilung. Es berücksichtigt auch stochastische lead time Verteilungen, stochastische Rücklaufverteilungen und mehr. Wir müssen alle möglichen Zukünfte mit Wahrscheinlichkeiten betrachten und dabei alle Arten von Unsicherheiten berücksichtigen. Die Nachfrage ist ein sehr wichtiger Aspekt, in der Regel der wichtigste, aber sie ist nicht der einzige.

Ich glaube, ich habe alle Fragen behandelt. Ich überprüfe nur noch, ob ich etwas übersehen habe… Keine weiteren Fragen. Also, vielen Dank an alle, die diese Vorlesung angeschaut haben, und bis nächste Woche, am selben Tag, zur selben Zeit. Bis bald. Auf Wiedersehen.

Referenzen

• Joel on Software: Und zu vielfältigen und gelegentlich verwandten Themen, die für Softwareentwickler, Designer und Manager sowie für jene, die – ob durch Glück oder Pech – in irgendeiner Weise mit ihnen zusammenarbeiten, von Interesse sein werden – von Joel Spolsky, 2004