00:22 Einführung
02:40 Warum ein Produkt? Weil Kapitalismus
08:18 Was soll das Produkt tun?
10:05 Software-Skalennachteile
12:50 Kaufen wir ein SCO-Produkt von der Stange
21:58 SCM vs SCO
25:58 Zwischenspiel
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 Python ist auch nicht das Endspiel
58:52 SC ist keine Abteilung der IT
01:03:19 Zusammenfassend: Zwei Herausforderungen, die es zu überwinden gilt
01:07:04 Kommende Vorlesung und Fragen des Publikums
Beschreibung
Das Ziel einer die Quantitative Supply Chain Initiative besteht darin, entweder eine Softwareanwendung bereitzustellen oder zu verbessern, die einen Umfang routinemäßiger Entscheidungen robotisiert (z. B. Lager replenishments, Preisaktualisierungen). Die Anwendung wird als ein zu entwickelndes Produkt betrachtet. Die supply chain theory soll uns dabei helfen, eine Anwendung bereitzustellen, die das Unternehmen in Richtung supply chain performance lenkt, während sie mit allen Zwängen, die die Produktion mit sich bringt, vereinbar ist.
Vollständiges Transkript
Hallo zusammen, vielen Dank, dass ihr an dieser Reihe von supply chain Vorlesungen teilnehmt. Ich bin Joannes Vermorel, und ich werde “Product-oriented Delivery for Supply Chain Optimization” präsentieren.
Zunächst, wenn ich von einem Produkt spreche, meine ich ein Softwareprodukt. Für diejenigen unter euch, die jemals das Privileg hatten, einen Blick unter die Haube eines modernen Enterprise piece of software 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 kann erkannt werden. Es ist vielmehr so, dass das Einzige, was die Menschheit bewahrt, die Unwissenheit ist. Unwissenheit ist dabei nicht das Problem; sie ist gerade das, was uns vor einem Universum schützt, das zu furchterregend für unseren Verstand ist. Diese Idee fand ihre Wiederverwertung in vielen modernen Spielen, insbesondere in Rollenspielen, in denen Charaktere zusätzlich zu den traditionellen Gesundheitswerten auch Verstandspunkte besitzen. Wenn man bestimmte Dinge tut, die dem eigenen Verstand schaden, verliert man Verstandspunkte. Die Herausforderung bei enterprise software besteht darin, sie zu erschaffen und dabei den eigenen Verstand zu bewahren – eine der Voraussetzungen, um im Unternehmen Mehrwert zu schaffen. Also, lasst uns fortfahren.
Warum ein Produkt, und insbesondere ein Softwareprodukt? Schauen wir uns genauer an, wie supply chains traditionell funktionieren. Traditionell waren viele Menschen vor Ort tätig, die Dinge bewegten, Pakete sortierten, Fahrzeuge fuhren und alle manuellen Arbeiten verrichteten. Zudem waren viele Menschen in der Produktion sowie in den Geschäften involviert. In den letzten Jahrzehnten hat sich jedoch allmählich gezeigt, dass die Zahl der Arbeitnehmer in Blue-Collar-Jobs stetig zurückgeht. Heutzutage ist die Produktion stark automatisiert. Es gibt zwar noch einige Branchen, wie die Textilindustrie, in denen es schwierig ist, alles zu automatisieren – weshalb diese Branchen dorthin verlagert wurden, wo Arbeitskräfte am günstigsten sind –, aber die Realität ist, dass der Bedarf an roher Arbeitskraft enorm reduziert wurde.
Am Ende ergibt sich eine recht eigenartige Situation, bei der, wenn man die nahende Ära autonomer Fahrzeuge betrachtet, viele Unternehmen mehr Büroangestellte haben werden, die mit Excel-Tabellen den supply chain steuern, als es Arbeiter gibt, die die manuellen Tätigkeiten vor Ort ausführen. Darauf beziehe ich mich, wenn ich von Verwaltungsarbeit spreche.
Ein weiterer merkwürdiger Aspekt ist, dass supply chains bei vielen Unternehmen seit mindestens zwei Jahrzehnten digitalisiert sind. Es ist nicht so, dass wir Software in supply chains einführen – supply chains werden bereits über Software gesteuert und betrieben. Betrachtet man die Rolle der Menschen in diesen Softwaresystemen, werden sie buchstäblich als menschliche Co-Prozessoren im durchschnittlichen supply chain-System eingesetzt. Es gibt spezifische Vorgänge, die der herkömmliche CPU, also der Prozessor in der Maschine, nicht ausführen kann, weshalb die gesamte Aufgabe an einen Menschen delegiert wird. In Verbindung mit einfachen numerical recipes, wie ABC analysis und min-max Inventar sowie ähnlichen Rezepten, verbringen Menschen ihre Tage damit, Probleme zu beheben, da sie ständig mit Ausnahmen und Bedingungen zu tun haben, die nicht in den Standardrahmen passen.
Aus Kostensicht handelt es sich hierbei ausschließlich um operationelle Ausgaben (OpEx). Man muss täglich eine Armee von Sachbearbeitern bezahlen, um all die banalen Entscheidungen zu treffen, die das Unternehmen täglich fällen muss. Dazu gehören etwa, was gekauft werden soll, wo das Inventar platziert wird, ob eine Einheit von einem warehouse in ein Geschäft verlagert wird, und viele andere Routineentscheidungen. Die Menschen treffen diese Entscheidungen und bekämpfen kontinuierlich Probleme, um den Unzulänglichkeiten der automatisch und naiv generierten Entscheidungen des Systems entgegenzuwirken.
Mein Vorschlag an Sie heute ist, dass wir von OpEx zu Kapitalausgaben (CapEx) übergehen wollen. Das ist der ganze Sinn dieses produktorientierten Ansatzes. Wir wollen ein Asset aufbauen, und warum? Weil es kapitalistisch ist. Wenn man sich die 100 profitabelsten Unternehmen der Welt heutzutage ansieht, ist die Hälfte von ihnen – gemessen am Gewinn – ein Softwareunternehmen. Sie verkörpern das Wesen ultra-kapitalistischer Firmen, bei denen zunächst eine Investition getätigt wird und aus der ein Artefakt entsteht, das mit minimalem zusätzlichen Aufwand einen Mehrwert generiert.
Um auf das Thema meiner vorherigen Vorlesung zurückzukommen: Wir benötigen Robotisierung, um das Management wieder in die Kontrolle zu bringen. Automatisierung und Menschen sollten Hand in Hand arbeiten; die Menschen sollen nicht damit beschäftigt sein, die Unzulänglichkeiten einfacher Inventarrichtlinien wie min-max zu kompensieren. Stattdessen sollten sie Mehrwert schaffen, numerical recipes verbessern und als Strategen agieren. Es gab ein altes IBM-Motto, das lautete: “Machines should work; people should think.” Genau diese Denkweise liegt dieser Präsentation zugrunde. Wir wollen die supply chain in ein kapitalistisches Asset verwandeln, und dazu muss die supply chain in eine Maschine umgewandelt werden, die ein Softwareprodukt liefert.
Was macht dieses Produkt eigentlich? Es stellt sich heraus, dass es etwas recht Simples tut: Es trifft Entscheidungen. Nicht willkürliche, offene Entscheidungen, sondern die banalen, routinemäßigen Entscheidungen – wie etwa, was produziert werden soll, wie viele Einheiten von einem Lieferanten gekauft werden sollen und wie viele Einheiten von einem Standort zum anderen bewegt werden sollen. Auf den ersten Blick mag es scheinen, als ob im supply chain Management viele Entscheidungen getroffen werden müssten. Betrachtet man jedoch die Aufgaben, so erfordert selbst die komplexeste supply chain jeden Tag nur einige Dutzend Arten von Entscheidungen. Das ist nicht überwältigend und erscheint angesichts der Anzahl der Funktionen durchaus vernünftig. Interessanterweise sind diese Entscheidungen weitgehend exklusiv, sodass es Grenzen gibt, was mit einem Divide-and-Conquer-Ansatz erreicht werden kann. Sobald Sie sich entschieden haben, 100 Einheiten von einem Lieferanten zu kaufen, kann ein anderes Subsystem nicht stattdessen 200 Einheiten erwerben. Irgendwann muss man sich darüber festlegen, wie viele Einheiten gekauft und von einem Standort zum anderen bewegt werden.
Ein Punkt, der in Bezug auf Software oft missverstanden wird, ist das Konzept der Skalennachteile. Während Skaleneffekte den meisten Menschen bekannt sind, trifft in der Software das Gegenteil zu, denn das Hinzufügen von nur einem Viertel 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, um ihr Produkt auf den Markt zu bringen, erheblich geringer sein als bei einem großen Unternehmen.
Mit dem Konzept der Skalennachteile im Hinterkopf müssen wir entscheiden, ob wir unser supply chain Optimierungsprodukt selbst entwickeln, kaufen oder einen anderen Ansatz wählen. Wenn wir uns dafür 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 fertigen supply chain Optimierungsprodukts. Auf diesen Folien gebe ich einen Überblick über nur einen winzigen Bruchteil all der Aspekte, die wir angehen müssen. Ich habe aus erster Hand Erfahrung damit, denn als ich 2008 Lokad gründete, begann ich mit einem kleinen Softwareprodukt, das eher auf Vorhersagen als auf supply chain Optimierung ausgerichtet war. Als ich mit Kunden arbeitete, stellte ich fest, dass es so viele Funktionen und Fähigkeiten gab, die mir fehlten, und je weiter ich mit weiteren Kunden zusammenarbeitete, desto mehr fehlende Fähigkeiten entdeckte ich. Es schien ein endloser Prozess zu sein, ständig neue Anforderungen zu entdecken.
Schauen wir uns nun die Kernfunktionen an. Zunächst gibt es Unternehmen, die B2C oder B2B sind und völlig unterschiedliche Muster im supply chain Management aufweisen. Beispielsweise haben B2B-Unternehmen in der Regel weniger Kunden, diese jedoch bestellen in viel größeren Mengen. Dies bringt unterschiedliche Risiken mit sich, wie etwa das Risiko, einen einzelnen Kunden zu verlieren, der einen erheblichen Anteil am Umsatz des Unternehmens ausmacht. Zudem existieren komplexere Geschäftsmodelle wie B2B2C oder B2B2B.
Betrachten Sie die verschiedenen Arten von Standorten, die abgedeckt werden müssen, wie etwa Geschäfte, Lager und Produktionsstätten. Jeder Standorttyp bringt seine eigenen Herausforderungen mit sich. Geschäfte sind beispielsweise anfällig für Inventarungenauigkeiten, selbst mit RFID-Technologie, einfach weil Kunden Produkte verschieben können. Lager und Produktionsstätten wie landwirtschaftliche Betriebe oder Bergbaubetriebe haben ihre eigenen spezifischen Probleme und Unsicherheiten bei der Produktionsausbeute.
Supply chain Netzwerke können unterschiedliche Ebenen oder Stufen aufweisen – von Ein-Stufen- bis hin zu Mehrstufen-Systemen. Die Komplexität beim Management der supply chain steigt erheblich, je mehr Stufen vorhanden sind. Auch die Netzwerktopologie ist ein wichtiger Aspekt: Eine Baumtopologie ist der klassische Vorwärts-supply chain Pfad, bei dem einige Produktionsstätten mehrere Lager beliefern, die wiederum zahlreiche Geschäfte versorgen. Es können jedoch auch andere Topologien existieren, wie etwa gerichtete azyklische Graphen (DAGs), bei denen ein Geschäft von mehreren Lagern bedient wird.
Im Grunde genommen ist es also nicht nur ein Baum im Sinne von Graphen – es kann sich wieder verbinden, obwohl es immer noch nur vorwärts geht. Dasselbe kann auch bei einem Directed Acyclic Graph (DAG) vorkommen, wenn mehrere Lieferanten ins Spiel kommen. Man kann sogar Schleifen im supply chain Graph haben, die entstehen, sobald Reparaturen erforderlich werden. Zum Beispiel gibt es in der Bergbauindustrie oder in der aviation Industrie zahllose Reparaturschleifen bei reparaturfähiger Ausrüstung.
Das Inventar selbst besitzt nicht nur eine einzige Natur; es variiert stark. Man kann nicht einfach sagen: “Oh, ich habe diese Idee, dass ich SKUs besitze und damit ist alles erledigt.” Nein, denn erstens gibt es Rohmaterialien, die buchstäblich in Mengen wie Gramm, Kilogramm oder Volumen gemessen werden. Dann gibt es die Einheiten, die als ordentlich definierte, fast makellose Größen vorkommen. Darüber hinaus existiert in Bereichen wie der Pharma- oder Lebensmittelbranche oftmals Inventar, das sehr häufig anfallen kann, wobei die jeweilige Charge mit spezifischen Verfallsdaten versehen ist. Außerdem kann es vollständig serialisiertes Inventar geben, bei dem jede einzelne Einheit ihre eigene Seriennummer hat. Im Hinblick auf die supply chain Optimierung verändert das die Spielregeln komplett, sodass es ein völlig anderes Problem darstellt, wenn man all diese Aspekte betrachtet.
Natürlich gibt es darüber hinaus all die Probleme der Marktplätze. Bei Lokad haben wir Kunden in buchstäblich jeder erdenklichen Situation. Einige Kunden verkaufen über einen Drittanbieter-Marktplatz, andere betreiben ihren eigenen Marktplatz oder beides. Manchmal dient ein zusätzlicher Marktplatz auch dazu, nicht verkaufte Waren zu liquidieren. Es gibt viele unterschiedliche Szenarien.
Betrachten Sie zum Beispiel einmal, was eine Bestellung überhaupt ist. Es gibt die Spot-Bestellung, bei der man im Grunde sofort etwas kauft, und es gehört einem. Aber es kann auch eine Bestellung geben, bei der heißt: “Ich kaufe es, möchte aber nicht, dass es sofort geliefert wird; ich möchte, dass die Lieferung erst in einem Monat erfolgt.” Aus der Perspektive der supply chain Optimierung ist das natürlich ein völlig anderes Szenario, denn wenn man im Voraus weiß, dass zu einem bestimmten Datum eine bestimmte Menge geliefert werden muss, möchte man das nicht vorhersagen – es ist etwas grundlegend Anderes.
Und dann gibt es noch die konfigurierte Bestellung, wie wenn man online einen Computer kauft und auswählen kann, wie viel Speicher, welche Festplattengröße, welchen Typ Betriebssystem, in welcher Sprache der Computer eingerichtet werden soll und wie die Tastatur beschaffen ist, neben weiteren Optionen. So entsteht ein umfangreicher Konfigurator, der die Gegebenheiten erneut verändert. Dies tritt auch bei Fahrrädern oder Autos auf und verändert die Landschaft völlig, da er Optionen und Herangehensweisen bietet, um das supply chain Optimierungsproblem auf völlig andere Weise zu betrachten.
Selbst bei Preisen kann es einen einheitlichen Stückpreis geben, der flach, super einfach und super linear ist, aber das ist nicht alles. Man kann Mengenrabatte haben, zum Beispiel, wenn man zehn Einheiten kauft, erhält man einen Rabatt. Oder man kann loyalty Programme haben, bei denen einige Kunden mit einer Loyalty-Karte einen Rabatt erhalten können, aber nur bei bestimmten Produktarten oder unter bestimmten Bedingungen. Und dann kann es sogar im B2B-Bereich sehr häufig verhandelte Dinge geben, das heißt, es ist buchstäblich eine Transaktion, bei der viele Dinge verkauft werden, aber man hat einen regulären Katalogpreis. Ein Anbieter kann jedoch einem Kunden einen Preisnachlass einräumen, weil dieser wichtig ist, und so wird es gehandhabt. Fazit: Ich spreche jetzt seit kaum ein paar Minuten und habe nur das Kernstück behandelt. Ich habe noch nicht einmal angefangen, die unverzichtbaren Elemente zu berühren. Also halte kurz inne und überlege, wie ein fertiges Enterprise-Software-Produkt, das supply chain optimization liefern soll, aussehen könnte. Die Anzahl der Features, die abgedeckt werden müssen, ist buchstäblich verrückt, und wenn man versucht, all diese Dinge in einen Monolithen zu packen, verliert man buchstäblich den Verstand. Wir kommen zurück zu der Idee, dass es nicht so ist, dass das Universum nicht erkennbar wäre, sondern dass man, wenn man der nackten Wahrheit des Universums ausgesetzt wird, den Verstand verliert.
Also, wir haben ein großes Problem, und hier müssen wir zwischen supply chain management und supply chain optimization unterscheiden. Diese Unterscheidung habe ich bereits in einer meiner vorherigen Vorlesungen eingeführt. Es herrscht ein großes Durcheinander zwischen der Management-Seite und der Optimierungs-Seite. Management dreht sich um Buchhaltung, unterstützende Workflows und hauptsächlich um Dateneingabeprozesse. Wenn du all die Dinge darstellen möchtest, die ich gerade beschrieben habe, ist das ein weites Feld, aber machbar. Ein „dickes“ ERP kann das leisten. Ja, du wirst am Ende 10.000 Tabellen haben, es wird ziemlich hässlich, aber es ist möglich. Aber täusche dich nicht, das ERP (das eigentlich ERM, Enterprise Resource Management, heißen sollte) wird nicht viel leisten. Es wird lediglich diese Dinge nachverfolgen. So wirst du Unmengen von Entitäten haben – MOQs, check; Mengenrabatte, check; Filialen, check; Lagerhäuser, check – aber du brauchst keinerlei Intelligenz. Es geht lediglich darum, banale digitale Gegenstücke zu haben, die die Daten widerspiegeln und die Dateneingabe ins System ermöglichen, und das war’s.
Das ist möglich, da wir hier ein wenig bei der Regel „ein Viertel mehr Features verdoppeln die Kosten“ schummeln können. Es gibt etwas, das ich dazu nicht wirklich erwähnt habe: Es funktioniert, wenn du deine Features vollständig getrennt hältst. Solange die Features nicht miteinander interagieren, ist es in Ordnung; du bist nicht diesem Fluch mangelnder Skaleneffekte ausgeliefert. Aus der Perspektive der Dateneingabe gibt es kein Problem. Du brauchst nicht die Benutzeroberfläche, die es dir ermöglicht, die MOQs mit dem zu verbinden, was dich beim Hinzufügen einer zusätzlichen Filiale ins Netzwerk unterstützt. Diese beiden Dinge können völlig getrennt behandelt werden.
Wenn es jedoch um supply chain optimization geht, ist das nicht der Fall. Wenn du MOQs hast, werden diese tiefgreifende Auswirkungen darauf haben, wie oft du bestellst und wie häufig du Dinge von deinem Lager zu deinen Filialen lieferst. Es gibt zahlreiche weitreichende Konsequenzen. Man kann die Dinge nicht trennen, denn letztlich ist deine supply chain nur ein System, in dem alles auf alles einwirkt. Aus der Perspektive der supply chain optimization hast du also buchstäblich das Problem, dass all diese Komponenten miteinander verbunden werden müssen, wenn du Optimierung liefern willst – und genau hier scheitert es.
Auf der Management-Seite kannst du potenziell mit einem Produkt enden. Allerdings lautet die Antwort für supply chain optimization, dass du es nicht kannst. Ich meine, du kannst so tun, als ob, aber buchstäblich, das geht nicht. Sogar bei Lokad, das nicht als ein vorausschauendes Unternehmen gestartet ist, das sich auf predictive supply chain optimization spezialisiert, sondern eher als Forecasting-as-a-Service. Wenn du auf den Lokad-Blog von 2008 zurückgehst, habe ich ursprünglich mit time series Forecasting begonnen, was gravierend fehlgeleitet war. Trotzdem habe ich auf diese Weise angefangen. Selbst beim Forecasting von Zeitreihen, das nur ein winziger Teil des gesamten Problems ist, ist es unüberschaubar. Das ist meine Schlussfolgerung, nachdem ich über 12 Jahre in diesem Geschäft war.
Wenn wir in die spezielle Welt der Softwareproduktion zurückkehren müssen, handelt es sich um etwas sehr Einzigartiges. Es sei denn, du wurdest selbst als Softwareingenieur ausgebildet und kennst die Art und Weise, wie große, erfolgreiche Softwareunternehmen Software produzieren, dann weißt du vermutlich sehr wenig darüber. Es stellt sich heraus, dass es eine sehr spezifische Welt ist, die mit zahlreichen völlig kontraproduktiven Aspekten aufwartet. Traditionelle Unternehmen, insbesondere solche mit einem klassischen Maschinenbau- oder Marketing-Mindset, haben immense Schwierigkeiten, überhaupt zu begreifen, wie Software funktioniert.
Wir werden diese Aspekte in zukünftigen Vorlesungen detaillierter behandeln, aber es gibt ein Buch, das ich wirklich mag, von Joel Spolsky, einem ehemaligen Microsoft-Mitarbeiter, der in den frühen Teams von Microsoft Excel gearbeitet hat. Er ist auch Mitbegründer von Stack Overflow und Trello. Im Jahr 2004, als ich noch Student war, habe ich sein Buch und seinen Blog gelesen. Das Buch trägt den Titel “Joel on Software” und vermittelt auf humorvolle Weise, wie das Führen eines erfolgreichen Softwaregeschäfts aussieht. Es unterscheidet sich sehr von dem, was die meisten Menschen außerhalb dieser Branche erwarten. Ich werde die Details zu diesem Buch in der Videobeschreibung hinzufügen.
Aber denken wir daran, dass supply chain optimization nicht dein durchschnittliches Softwareprodukt ist. Normalerweise, wenn du es mit einem durchschnittlichen Softwareprodukt zu tun hast – ich meine, ja, je nach Art des Softwareprodukts gibt es einige widrige Verhaltensweisen. Wenn du es mit einem sozialen Netzwerk zu tun hast, kann es passieren, dass viele Menschen hasserfüllte Inhalte posten, was ein ganz anderes Spiel ist. Wenn es jedoch um klassische Enterprise-Software wie Microsoft Word oder Excel geht, handelt es sich um ein Produkt, bei dem du das richtige Design haben möchtest, es aber keinerlei Notfälle gibt. Bei traditionellen Softwareprodukten ist es in Ordnung, Jahre damit zu verbringen, dein Design und dein Produkt zu verfeinern. Es ist eine langfristige Investition, und du musst Jahrzehnte vorausdenken. Es gibt keinen Grund, in Bezug auf die Entwicklung etwas zu überstürzen. Supply chain optimization funktioniert jedoch nicht so. Du hast nicht die Wahl, denn ständig passieren Dinge und das Terrain ist sehr rau.
Du kannst extreme Situationen haben, wie die Pandemie oder andere Probleme wie Ransomware, die die Hälfte deines Netzwerks lahmlegen können. Du musst kluge Entscheidungen treffen, um das Beste aus den Kapazitäten herauszuholen, die dir noch zur Verfügung stehen. Du könntest mit einer Flottensperrung aufgrund tragischer Zwischenfälle, politischen Maßnahmen wie Zöllen, die deine Strategie stören, oder natürlichen disasters wie Tsunamis oder Bränden und Hitzewellen, wie etwa in Kalifornien oder Australien, konfrontiert werden. Diese Ereignisse passieren, und wenn sie eintreten, musst du in der Lage sein, buchstäblich innerhalb von Stunden zu reagieren.
Du hast dein Softwareprodukt, aber du musst Veränderungen herbeiführen, und du möchtest programmatische Veränderungen einleiten. Denke daran, wenn du in der Mentalität bist, ein Software-Asset zu liefern, hast du ein kleines Team, das die Software betreibt, die wiederum deine supply chain antreibt. Du hast nicht eine Armee von Sachbearbeitern, die den ganzen Tag Feuer löschen. Selbst wenn du eine Armee von Sachbearbeitern hättest, müsstest du sie schulen, und wenn etwas völlig Unerwartetes passiert, hast du am Ende eine Armee, die für diese spezifische Situation nicht geschult ist. Meiner Erfahrung nach gilt: Je mehr Menschen du managen musst, desto länger dauert es, etwas zu erreichen.
Erst vor ein paar Tagen hat ein Frachtschiff aufgrund schlechter Wetterbedingungen über 1.800 Container verloren. Solche Dinge passieren einfach, und du kannst nicht hoffen, sie zu eliminieren. Supply chain ist nicht wie die Fertigung, bei der du eine Produktionsstätte haben kannst, in der alles streng kontrolliert wird. Per Definition finden supply chains in einer weiten Welt statt, in der du die Elemente meistens nicht kontrollieren kannst. Es gibt so viele Kräfte außerhalb deiner Kontrolle, dass du in der Lage sein musst, mit überraschenden Ereignissen umzugehen. Du weißt bereits, dass Überraschungen passieren werden, also musst du vorbereitet sein. Vorbereitung bedeutet nicht, alles sorgfältig geplant zu haben; es geht darum, ein System zu besitzen, in dem du, falls nötig, innerhalb von Stunden reagieren kannst. Das ist das Wesentliche dessen, was du tun kannst, um das Problem realistisch anzugehen.
Nun, was brauchen wir an Software-Zutaten für supply chain optimization? Zuerst benötigen wir vielseitigen Datenspeicher, um all die unterschiedlichen Arten von Datenquellen abzubilden. Es gibt so viele Dinge, die wir darstellen wollen, daher benötigen wir in dieser Hinsicht etwas sehr Vielseitiges, mit viel Struktur und Vielfalt.
Zweitens brauchst du programmierbare Logik. Ich komme zurück auf diese Idee: Wenn du keine programmierbare Logik hast, wie gehst du dann mit all diesen Problemen um? Wie fügst du all diese Dinge zusammen? Du kannst kein fertiges Produkt kaufen, das für dich alles vorkonfiguriert hat; das funktioniert nicht.
Als Nächstes brauchst du vielseitige Benutzeroberflächen, denn die Art und Weise, wie du deine Probleme betrachten möchtest, wird von Situation zu Situation enorm variieren. Die KPIs werden von Unternehmen zu Unternehmen völlig unterschiedlich sein, daher benötigst du eine vielseitige Benutzeroberfläche, in der du die Zahlen auf jede beliebige Weise präsentieren kannst; andernfalls wird es eine große Einschränkung darstellen.
Du möchtest auch kollaborative Fähigkeiten, denn supply chain ist definitionsgemäß Teamarbeit. Es sind viele Menschen involviert, und es ist verteilt, daher müssen kollaborative Fähigkeiten im Zentrum stehen.
Zum Schluss – und das ist vielleicht umstrittener – möchtest du programmierbare Möglichkeiten, die auch für Personen zugänglich sind, die keine ausgebildeten Softwareingenieure sind. Dies ist aus mehreren Gründen wichtig. Erstens gibt es nicht viele ausgebildete Softwareingenieure auf dem Arbeitsmarkt, sodass es sehr wettbewerbsintensiv ist, sie einzustellen. Zweitens erfordert es enorm viel Aufwand und Engagement, um ein talentierter Softwareingenieur zu werden, sodass es schwierig ist, gleichzeitig ein supply chain specialist zu sein.
Es ist nicht sehr häufig, Menschen zu finden, die über doppelte Kompetenzen in beiden Bereichen verfügen. Das Gleiche würde gelten, wenn du jemanden suchst, der sowohl Programmierer als auch Jurist oder Programmierer und Arzt ist. Ja, du wirst einige Leute mit diesen Fähigkeiten finden, aber kannst du das im großen Stil umsetzen oder jedes Jahr zuverlässig mehr von ihnen einstellen, wenn du ein großes Unternehmen bist? Nach meiner Erfahrung, Lokad seit einem Jahrzehnt zu leiten, funktioniert das einfach nicht.
Du möchtest etwas Programmierbares, aber du musst kein professionell ausgebildeter Softwareingenieur sein, um mit der Programmierung umzugehen. Denke daran, du brauchst jemanden mit supply chain Kompetenz, denn du musst in der Lage sein, innerhalb von Stunden Programmierkorrekturen an deinem System vorzunehmen, ohne ein Ticket zu eröffnen und es an die IT weiterzuleiten. Wenn du es auf diese Weise tun musst, dauert es Wochen, um Probleme zu beheben – nicht Stunden. Also, welche Art von Software kann das Problem tatsächlich lösen?
Nun, Excel kann es. Es ist nicht schön, und es mag sich nicht wie der Höhepunkt moderner Software anfühlen, aber es erfüllt seinen Zweck. Es erfüllt alle Kriterien.
Vielseitiger Datenspeicher? Ja, bis zu einem gewissen Grad kannst du in Excel eine Menge Daten jeglicher Art unterbringen. Programmierbare Logik? Absolut, Excel ist vollständig programmierbar. Vielseitige Benutzeroberfläche? Ja, du kannst Balkendiagramme, Liniendiagramme und zahlreiche Möglichkeiten zur Darstellung von Daten nutzen. Was Benutzeroberflächen angeht, ist es sehr vielseitig. Es mag nicht das Ausgereifteste sein, aber in puncto Vielseitigkeit kann es viel leisten.
Hinsichtlich der kollaborativen Fähigkeiten ist es etwas primitiv. Es gibt einige Versionen von Excel, die online sind und etwas besser funktionieren, aber grundsätzlich kannst du deine Tabellenkalkulationen teilen. Das Problem bei den mangelnden kollaborativen Features liegt nicht darin, dass es sich um eine Desktop-App handelt. Das Problem ist die Denkweise, die hinter Tabellenkalkulationen steckt, welche sich nicht für intensive Teamarbeit eignet. Üblicherweise ist es so, dass wenn ein Kollege ein sehr komplexes Sheet erstellt hat, es einfacher ist, das Sheet neu zu erstellen, als zu versuchen, herauszufinden, was er getan hat. Das Problem bei den fehlenden kollaborativen Features ist also die Denkweise, die mit Tabellenkalkulationen einhergeht und von Natur aus starke Grenzen für die Zusammenarbeit aufweist.
Allerdings ist Excel völlig zugänglich für Nicht-Entwickler, und es existiert sogar Visual Basic for Applications für kompliziertere Aufgaben. In Bezug auf die Zutaten erfüllt Excel alle Anforderungen, was meiner Meinung nach weitgehend den operativen Erfolg in den meisten supply chains erklärt.
Nach meiner Erfahrung werden die meisten supply chains weltweit – von den kleinsten Unternehmen bis zu den größten und von denen, die noch keinen Cent in Enterprise-Software investiert haben, bis zu denen, die Millionen von Dollar in komplizierte Enterprise-Software für supply chain optimization investiert haben – von Excel angetrieben. Es gibt nur sehr wenige Ausnahmen. Manchmal verwenden Leute Excel, um Min-Max-Einstellungen in anderer Software zu überarbeiten, aber die Pflege dieser Einstellungen wird an diejenigen delegiert, die mit Excel arbeiten.
Excel treibt die Welt der supply chain heute an, und ich glaube, das ist kein Zufall. Im Kern gehen Tabellenkalkulationen grundlegende viele der richtigen Probleme an. Viele andere Optionen werden als überlegen dargestellt, scheitern aber per se, wenn du nicht programmieren kannst. Wenn du nicht programmieren kannst, heißt das, dass du im Falle eines größeren Problems oder einer Notlage Pech hast. Die Leute greifen in Situationen, in denen eine vielseitige Benutzeroberfläche fehlt oder eine Lösung für Nicht-Entwickler nicht zugänglich ist, auf Excel-Tabellen zurück. Wenn nur ein IT-Team Ergebnisse liefern kann, öffnen die Leute zunächst vielleicht Tickets und warten geduldig – aber innerhalb von drei Monaten greift vermutlich jeder wieder auf Excel-Tabellen zurück, weil es schneller ist. Excel ist nicht das Endspiel, aber was auch immer wir als überlegenes Ersatzprodukt anbieten, es muss die richtigen Kriterien 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 mit einer Million Zeilen zurechtkommen. Leistungsprobleme treten schnell auf, wenn man im großen Maßstab arbeitet. Programmierbare Logik in Excel ist möglich, aber sie ist sehr fragil und empfindlich. Wenn Sie versehentlich einen Fehler oder Bug in Ihrer Tabelle einführen, wird es zum Albtraum, diesen zu debuggen und die Fehlerquelle genau zu identifizieren. Die Logik wird endlos dupliziert, was zu Tausenden von Kopien derselben Logik führt und es schwierig macht, Fehler zu erkennen und zu beheben.
Die Benutzeroberfläche ist nicht ideal, da sie nicht vollständig web-basiert ist und die Daten immer mit der Oberfläche verflochten sind. Kollaborative Möglichkeiten existieren, aber sie sind unordentlich. Zusammenarbeit sollte auf der Ebene der programmierbaren Logik erfolgen. Viele supply chain optimization Anbieter bieten Zusammenarbeit an den Ergebnissen an, wie das manuelle Anpassen von Prognosen und das Ermöglichen der Teilnahme mehrerer Personen. Dies ist jedoch der falsche Ansatz. Kollaborationen müssen stattfinden, aber sie müssen auf der logischen Ebene, also auf der Ebene der programmierbaren Logik erfolgen. Excel ist sehr zugänglich für Nicht-Entwickler, aber wenn Sie etwas etwas Komplizierteres tun wollen, wird es herausfordernd. Im supply chain management wollen wir uns mit allen möglichen Zukünften auseinandersetzen, was bedeutet, mit probabilistic forecasts, Zufallsvariablen und der Bewältigung von Unsicherheiten zu 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, da man ein Asset aufbauen möchte, dessen Wert im Laufe der Zeit steigt. Mit Tabellenkalkulationen ist dies schwer zu erreichen, und es ist schwierig, etwas wirklich Präzises zu erstellen – zumindest im Sinne eines Softwareprodukts.
Die Schlagwörter 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 ich finde, es ist eine brillante Sprache. Ich unterrichte es sogar meiner 10-jährigen Tochter. Es gibt jedoch mehrere Gründe, warum Python nicht die beste Wahl für das supply chain management ist. Erstens erfordert es Softwareingenieure. Obwohl Python eine der zugänglichsten Programmiersprachen ist, benötigt man ein Softwareentwicklungsteam, wenn man etwas Komplexeres tun möchte – was Herausforderungen schafft, wenn man Personen benötigt, die sowohl supply chain Experten als auch Softwareingenieure sind.
Python verfügt über schöne Funktionen, aber die Art und Weise, wie Abhängigkeiten gehandhabt werden, ist ziemlich komplex, und das Paketmanagement ist mangelhaft. Pakete sind Bausteine, die zusätzliche Fähigkeiten bieten, und wenn Sie sagen, dass Sie Python nutzen möchten, geht es nicht nur um die Sprache, sondern auch um das gesamte Ökosystem von Paketen, an denen Sie interessiert sind, wie NumPy, Pandas, TensorFlow und SciPy – alles sind Drittanbieter-Abhängigkeiten oder Softwarebibliotheken. Das Paketmanagement war über ein Jahrzehnt hinweg schlecht, und obwohl es sich verbessert, schreitet der Fortschritt langsam voran. Es gibt viele Aspekte des Systemdesigns, die es schwierig machen, Verbesserungen vorzunehmen.
Die Leistung ist ebenfalls schlecht, hauptsächlich durch das Design bedingt. Die Rechenleistung bezieht sich auf die Qualität der Arbeit, die Python leistet, um die rohe Rechenleistung Ihres Computers auszuschöpfen. Überraschenderweise leistet Microsoft Excel in dieser Hinsicht einen viel besseren Job. Excel ist hoch optimiert, nutzt Multi-CPU- und Multi-Core-Systeme und betreibt nativ kompilierte Logik. 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 es einigen akzeptabel erscheinen mag, angesichts der Leistungsfähigkeit moderner Computer, ist es nicht ideal für Unternehmen mit Transaktionsvolumen von über 50 Millionen Dollar. Man möchte etwas, das von Anfang an eine gute Leistung liefert.
Die Idee, eine Drittanbieter-Bibliothek wie NumPy zu verwenden, um das Leistungsdefizit von Python auszugleichen, fügt nur zusätzliche Komplexität hinzu. Vielleicht 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 die Softwareentwicklung.
Wenn man versucht, Python-Lösungen für echtes supply chain management zu implementieren, treten verschiedene Probleme auf – wie Nullreferenz-Ausnahmen, Out-of-Memory-Ausnahmen und lange Rechenzeiten. Möglicherweise warten Sie 20 Minuten, bis eine Berechnung abgeschlossen ist, ohne sicher zu sein, ob sie jemals fertig wird oder ob Sie den Prozess einfach beenden und neu starten sollten. Ich weiß es einfach nicht, deshalb möchte man etwas, bei dem man eine sehr, sehr gute Vorstellung davon hat, wie viel Zeit die Fertigstellung in Anspruch nehmen wird. Übrigens, wenn ich zu Excel zurückkomme: Heutzutage gibt Excel bei Operationen, die etwas Zeit in Anspruch nehmen, einen ziemlich zuverlässigen Indikator, eine Fortschrittsanzeige, wie viel Zeit es dauern wird. Also nochmal: Man möchte – und das ist Teil dessen, was ich als Produktionsbereitschaft bezeichne – etwas haben, das, weil die von Ihnen produzierte Software höchstwahrscheinlich unbeaufsichtigt läuft, beispielsweise nachts oder während eines nächtlichen Batch-Prozesses, rund läuft. Man möchte etwas, das keinen Data Scientist erfordert, um das Ganze zu überwachen.
Und nochmal, wenn Sie schon das Problem mit Data Scientists haben, dann benötigen Sie die dritte Kompetenz: supply chain expert, Softwareentwicklungsexperte und jetzt einen Data Scientist-Experten. Es ist möglich, all diese drei Qualitäten in einer Person zu vereinen, aber viel Glück, mehr als eine Person pro Jahr einzustellen – selbst wenn Sie ein großes Unternehmen sind, das all diese Fähigkeiten besitzt. Es ist einfach super selten.
Wir wollen also etwas haben, das sich verbessert. Übrigens ist das erste, was wir verbessern wollen, die defense in depth. Ransomware nimmt zu, und wann immer Sie etwas Programmierbares in Ihrem Unternehmen einsetzen, setzen Sie sich Ransomware aus. Denn plötzlich, wenn ein Programm vorhanden ist, kann das Programm auf dem Rechner Unmengen an Dingen tun – inklusive der Übernahme des Rechners selbst. Ich weiß, dass es unzählige Möglichkeiten gibt, die Probleme zu mildern; Sie können Dinge in einer Sandbox ausführen, Einschränkungen vornehmen, begrenzte Rechte vergeben, und es gibt unzählige Wege, die Probleme einzuschränken. Dennoch, wann immer Sie etwas wie eine generische Programmiersprache für allgemeine Zwecke verwenden, ist Ihre Angriffsfläche – und das ist ein technischer Begriff – absolut gigantisch.
Im Grunde genommen, wann immer Sie solchen Code einbinden, setzen Sie sich massiv Sicherheitsproblemen aus. Und denken Sie daran, dass in einem regulären Softwareentwicklungsunternehmen der Code in der Regel einem Peer-Review unterzogen wird. Sie überprüfen also den Code, es gibt einen Code-Review-Prozess, jemand erstellt den Code, und ein Kollege überprüft ihn, um sicherzustellen, dass es keine Unstimmigkeiten gibt. Aber wenn ich daran denke, dass Software robust sein muss und man innerhalb von Stunden reagieren können muss, werden Sie aus Sicht der supply chain optimization nicht in der Lage sein, einen Code-Review-Prozess einzuführen. Das ist einfach nicht kompatibel mit den Verzögerungen und Notfällen, denen Sie begegnen werden.
Sie benötigen also etwas, das Ihnen von vornherein eine tiefenverteidigte Sicherheit bietet. Dann möchten Sie etwas mit transparenter Leistung haben, bei dem ja, Dinge Zeit in Anspruch nehmen können, aber Sie die Kontrolle behalten. Sie müssen im Voraus wissen, wie viel Zeit es in Anspruch nehmen wird. Wenn Sie das nicht haben, setzen Sie sich unzähligen, sehr dummen Problemen aus – wie etwa, dass Sie ein zwei Stunden langes Zeitfenster hatten, um Ergebnisse zu liefern, und Sie kommen zu spät. Und wissen Sie was? Die Lastwagen sind bereits abgefahren. Es ist zu spät. Also brauchen Sie etwas, das sich darum kümmert.
Und dasselbe gilt für transparente Upgrades. Das ist die Schönheit von Excel. Sie müssen sich nicht um die Wartung von Excel kümmern. Microsoft schloss vor Jahrzehnten einen Pakt in Blut, der besagte: Wenn Sie eine Excel-Tabelle erstellt haben, wird jede zukünftige Version von Excel, die auf den Markt kommt, Ihre Tabellen unterstützen. Und das Erstaunlichste ist, dass – wenn man sich Excel heutzutage anschaut – viele konkurrierende Excel-Formate von Mitbewerbern unterstützt werden, die es gar nicht mehr gibt. Sie können immer noch Tabellen lesen, die mit Lotus Notes und ähnlichem erstellt wurden. Microsofts Wertversprechen in Bezug auf transparente Upgrades besteht also darin, dass die von Ihnen erstellte Logik für immer funktioniert, und ja, sie werden Excel noch über Jahrzehnte hinweg verbessern, aber wissen Sie was? Es ist geregelt. Das sieht man nicht beim Übergang von Python 2 zu Python 3 – das war ein Albtraum und dauerte ein Jahrzehnt. Python ist also für vieles großartig, aber stellen Sie sich vor, dass diese Upgrades in den schlechtesten Momenten stattfinden – in denen Sie die schlimmste Pandemie, den schlimmsten Zoll, den schlimmsten Notfall haben und alles einsatzbereit sein muss. Sie können es sich nicht leisten, eine sechsmonatige Ausfallzeit zu haben, nur weil Sie ein Upgrade vornehmen müssen. Das ist nicht mit supply chain optimization vereinbar.
Nun müssen wir darüber nachdenken, was wäre, wenn wir tatsächlich etwas in Betracht ziehen würden, das speziell für supply chain entwickelt werden könnte? Das wird das Thema der nächsten Vorlesung sein.
Außerdem ist supply chain nicht die Abteilung der IT. Wenn ich von einer produktorientierten Lieferung spreche, dann ist es nicht so, dass die Software nur ein Mittel und kein Selbstzweck ist. Sie werden Ihre Software nicht als Lizenzen oder gegen eine Gebühr verkaufen, wie es beispielsweise Microsoft tut. In dieser Vision, die ich in dieser Vorlesung vor Ihnen entwerfe, ist die IT für die Kernpraktiken verantwortlich – für die wesentlichen IT-Praktiken, wie etwa was in Bezug auf Sicherheit, Backups, Kerninfrastruktur, Ihr Netzwerk, die Verwaltung und Synchronisation aller Daten auf Unternehmensebene zu tun ist – und für die Bereitstellung aller Anleitung und Betreuung.
Aber die Idee ist, dass supply chain die supply chain Entscheidungen selbst in die Hand nehmen muss. Sie müssen all die Apparate besitzen, die diese supply chain Entscheidungen generieren – das ist ihr Kerneigentum. In der vorherigen Vorlesung habe ich definiert, was den Supply Chain Scientist ausmacht: Der Supply Chain Scientist ist jemand, der die numerischen Entscheidungen, die durch den Code erzeugt wurden, besitzt. Es ist kein System, das Entscheidungen trifft; es sind numerische Rezepte, die von einem oder mehreren Supply Chain Scientists niedergeschrieben wurden, und diese Supply Chain Scientists besitzen gemeinsam diese numerischen Entscheidungen. Sie übernehmen die Verantwortung dafür, und es ist die Aufgabe der supply chain, sicherzustellen, dass alle Entscheidungen im Unternehmen konsistent sind. Wenn eine Promotion läuft oder ein großer Marketingschub stattfindet, müssen die Dinge rechtzeitig produziert werden, damit sie bereitgestellt werden können. Sie wollen nicht in einer katastrophalen Situation landen, in der Sie etwas pushen, während Sie sich bereits in einer nahezu stock-out Situation befinden – in der Sie Geld für einen Marketingschub ausgeben, für etwas, das Sie nicht einmal verkaufen können, weil Sie weder über den Bestand noch die Kapazität zur Herstellung oder zur rechtzeitigen Bereitstellung des Services verfügen.
Also, wir haben zwei Abteilungen, die sehr unterschiedliche Schwerpunkte haben. In meiner idealen Vorstellung davon, wie die IT department sein sollte, ist die IT-Abteilung nicht eine Abteilung, in der Sie Tickets weiterleiten. So funktioniert das nicht. Die IT-Abteilung ist für die Kerninfrastruktur verantwortlich. Es ist die Art von Sache, die die ganze Zeit nahtlos funktioniert. Man achtet nicht einmal darauf – so wie man gar nicht auf das Wi-Fi achtet, solange es funktioniert; man bemerkt es nur, wenn es nicht funktioniert. Eine gute IT-Abteilung liefert die gesamte Infrastruktur, sodass man sie kaum bemerkt. Man merkt nicht einmal, dass sie existiert, weil alles einfach funktioniert, genauso wie Ihre E-Mails einwandfrei laufen. Darum geht es bei guter Core IT. Und dann sind da die IT-Leute, die zu Ihnen kommen und Ihnen helfen, all die Praktiken zu etablieren, die Ihnen zur Hand gehen. Programmierbare Logik ist etwas schwierig, also fragen Sie sich manchmal, woher Sie das Coaching bekommen, um in Sachen Programmierung ein wenig besser zu werden? Nun, die Antwort lautet: Es sollte die IT sein. Sie sollten nicht kommen und sagen: “Wir werden es für Sie programmieren”, sondern vielmehr: “Wir werden Sie coachen, damit Sie es tatsächlich selbst implementieren können. Wir helfen Ihnen mit ein paar Konzepten, vielleicht auch mit einigen Dingen, die etwas technischer sind, als sie sein sollten.” Manchmal tritt zufällige Komplexität auf, und da ist die IT, um Sie zu unterstützen. Aber grundsätzlich sind sie nicht da, um die Arbeit für Sie zu erledigen. Sie sollten Mentoren und Coaches sein, die dafür sorgen, dass niemand einen fatalen Fehler macht, der das ganze Unternehmen – IT-seitig – Risiken wie Ransomware oder ein systemisches Risiko aussetzt.
Als Lackmustest gilt: Wenn Ihre Interaktion zwischen IT und supply chain über Dokumente läuft, in denen Sie Spezifikationen oder Anforderungen auflisten, ist das nicht der richtige Weg, um eine gute Beziehung zwischen diesen beiden Abteilungen zu pflegen. Wenn ich von einer guten Beziehung spreche, meine ich etwas, das dem Unternehmen tatsächlich einen Mehrwert bietet.
Zusammenfassend haben wir hier zwei Herausforderungen von der traditionellen Seite des supply chain management, die vielleicht schon Programmierung betrieben haben – allerdings nur am Rande mit Excel-Tabellen, ohne überhaupt zu erkennen, dass dies bereits eine Form der Programmierung ist. Sie müssen Ihre Ängste überwinden. Sie müssen daran denken, dass die Welt von morgen – Ihre Abteilung – dafür verantwortlich sein wird, ein Produkt zu liefern, das wie ein Softwareprodukt läuft, und das ist eine enorme Veränderung. Ja, aber es ist etwas, mit dem Sie umgehen können. Warum? Denn wenn Sie die richtigen Werkzeuge haben, ist zwar Programmierung involviert, aber sie ist nicht grundlegend oder radikal schwieriger als Excel. Noch einmal: Die Herausforderung liegt nicht in der technischen Komplexität des Werkzeugs; sie liegt 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 vornherein eine komplizierte supply chain haben.
Für den Teil des Publikums, der vielleicht eher auf der Data Scientist-Seite oder der IT-Seite steht, muss man die Selbstüberschätzung überwinden. Ich habe immer wieder Data Scientists gesehen – und ich schließe mich selbst in diese Kategorie ein – die zu zuversichtlich waren, einen Prototyp in die Produktion zu überführen.
So, das ist die Art von Situation, und man muss in der Lage sein, schnell zu reagieren. Es geht um Angst und Selbstüberschätzung. Vielen Dank für Ihre Zeit.
Nun werde ich mir die Fragen im Chat anschauen.
Frage: Kann die Software die Entscheidung darüber treffen, bei welchem Lieferanten eine Zusatzbestellung aufgegeben wird, falls für morgen mehr benötigt wird? Zum Beispiel könnten in australischen Büros 200-Gramm-Schalen mit Erdbeeren von 10 Lieferanten geliefert werden, die am selben Tag dieselben Produkte an das Distributionszentrum bringen.
Absolut, und hier müssen wir zwischen den beiden Seiten des supply chain managements und der supply chain Optimierung unterscheiden. Es gibt die supply chain management Seite, in der wortwörtlich alle data pipelines vorhanden sind, einschließlich EDI, womit man eine elektronische Bestellung an einen Lieferanten ohne menschliches Zutun übermitteln kann. So hat man eine elektronische End-to-End-Brücke. Aber das bedeutet dann, dass man auf der Optimierungsseite eine Software benötigt, die kontinuierlich über den Tag läuft und zu einem bestimmten Zeitpunkt die Management-Seite benachrichtigen kann mit der Meldung, “Bitte führen Sie diese Bestellung aus.” Und dann sorgt die Management-Seite, die von der IT betreut wird, lediglich dafür, dass diese Bestellung vollständig ausgeführt wird. Es handelt sich dabei rein um Transaktionsabwicklung; es ist keine Intelligenz mehr im Spiel. Man hat eine Bestellung erhalten, in der eine bestimmte Menge angegeben ist, und es ist die Optimierungsseite, die sicherstellt, dass, wenn man eine bestimmte Menge generiert, alle Vorgaben eingehalten werden – wie die genaue Liste der Lieferanten, die überhaupt berechtigt sind, diese Produkte zu liefern, ob noch Lagerbestand vorhanden ist und wie man die richtige Wahl zwischen allen konkurrierenden Lieferanten trifft, usw. Es kann eine Menge passieren. Absolut, ja, aber wir müssen buchstäblich die alltägliche Ausführung, den transaktionalen Teil, der auf der supply chain management Seite liegt, von dem Optimierungselement trennen, das zu dem Zeitpunkt ins Spiel kommt, an dem man entscheidet, dass nachbestellt werden muss.
Frage: Wissen Sie, dass Sie derzeit mit den eSports World Championships konkurrieren?
Nein, ich konkurriere derzeit nicht mit diesen eSports Championships, aber das ist sehr cool. Übrigens spielen wir bei Lokad häufig Dota 2, sodass auch das Management-Team mitspielt. Einige unserer Mitarbeiter möchten League of Legends spielen, aber als CEO des Unternehmens lehne ich das entschieden ab.
Frage: Ich habe gesehen, dass viele Unternehmen überhaupt kein ERP oder WMS haben und dass das Management an der supply chain Optimierung arbeitet.
Nun, absolut. Man kann die supply chain Optimierung nicht vom ersten Tag an vermeiden; man muss diese Entscheidungen treffen. supply chain Optimierung gab es schon, bevor irgendeine Art von supply chain management Software eingesetzt wurde. Selbst als wir vor 60 Jahren noch keine Software hatten, mussten die Menschen Entscheidungen treffen. supply chain Optimierung war also längst Realität – die Menschen machten es mit Stift und Papier. Wenn man sich die frühesten Arbeiten zur supply chain anschaut, wie die Wilson-Formel, auch bekannt als die EOQ-Formel, dann ist diese Formel über ein Jahrhundert alt. Sie geht klar der Software voraus. Also ja, supply chain Optimierung ist etwas, das vom ersten Tag an stattfindet, egal ob man in seinem Unternehmen Software hat oder nicht.
Nun, tatsächlich benötigt man ordentliche IT-Systeme, 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 – eventuell unterstützt durch Barcodes und andere Hilfsmittel. Es geht also um banale Aufgaben, nämlich darum, die Daten abzubilden. Das Problem ist, dass die Leute etwas wollen, das sowohl supply chain management als auch supply chain Optimierung übernimmt, und infolgedessen landet man mit einem Produkt, das überkompliziert, meist extrem fehlerhaft ist und unschöne Features wie Alarme und Ausnahmen besitzt, die man eigentlich vermeiden sollte. Ich werde in einer späteren Vorlesung darauf zurückkommen.
Grundsätzlich ist es heutzutage, falls man noch keines installiert hat, eine Frage von Wochen, ein WMS oder ein ERP einzuführen. Wenn man bereits eines hat, kann es Monate dauern, sofern man dieses System von seinen Entscheidungen entkoppeln muss.
Frage: Wann wird das Management des Unternehmens erkennen, dass es Zeit ist, von der reinen Verfolgung von Informationen zur Optimierung von supply chain Entscheidungen überzugehen und sich letztlich auf supply chain Optimierung zu konzentrieren?
Zunächst einmal muss man überhaupt erkennen, dass es zwei Probleme gibt und dass dieselbe Software nie beide Ansätze abdecken kann. Ich denke, das ist die große Illusion, und Softwareanbieter haben in diesem Bereich für enorme Verwirrung gesorgt. Wenn man sich die größten ERP-Anbieter anschaut, vermitteln sie die Botschaft, dass ihre Lösung supply chain Optimierung bietet, aber alles, was sie tatsächlich liefern und was ihr Produkt leistet, liegt auf der Seite des supply chain managements – etwas, das weitaus weniger attraktiv erscheint, da dort keine KI oder echte Intelligenz im Spiel ist. In der Softwarewelt spricht man von CRUD-Apps (Create, Read, Update, Delete). ERPs sind im Grunde gewaltige Sammlungen von CRUD-Bildschirmen, bei denen jeder einzelne Bildschirm Zeilen in einer relationalen Datenbank erstellen, lesen, aktualisieren oder löschen kann – und damit ist es getan. Ein ERP ist, vereinfacht gesagt, 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 nun auf Ihre Frage zum Management zurückkomme, liegt das Problem darin, dass, wenn man als Manager die Broschüre des ERP-Anbieters liest und dieser einem verspricht, dass das System die supply chain optimiert, die Antwort lautet: Nein, absolut nicht. Was es tun wird, ist die Produktivität zu steigern und eine präzise Buchführung der supply chain sicherzustellen. Das ist schon viel, da es Diebstahl, Schwund, fehlplatzierte Güter erheblich reduzieren und die Produktivität in einem Lager etwa durch Barcodes verbessern kann. Diese Produkte bieten einen erheblichen Mehrwert. Ich möchte den Wert, den ein ERP oder WMS mit sich bringt, keineswegs schmälern – er ist enorm, aber es geht dabei nicht um supply chain Optimierung. Ein WMS beispielsweise ist per Design etwas, das sich um das Lager kümmert; es interessiert sich nicht für die gesamte supply chain, zu der auch Kunden und Lieferanten gehören. Es ist von vornherein auf bestimmte Standorte ausgerichtet und nicht auf die gesamte Kette.
Frage: Wie kann man einen reibungslosen Übergang von Python zu Envision schaffen bzw. beide 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 ein besseres Verständnis dafür bekommen, wovon ich spreche – anhand von echten Codebeispielen.
Historisch gesehen haben wir Python und Envision zusammen genutzt, da Envision zu Beginn nur sehr begrenzte Möglichkeiten bot, sodass viele Funktionen fehlten und wir in vielen Situationen auf Python zurückgreifen mussten. Im Laufe der Jahre haben wir die Fähigkeiten von Envision schrittweise erweitert, sodass der Bedarf an Python-Komponenten nach und nach entfiel. Es waren nicht nur Python-Komponenten; es war auch eine Reihe von Tools, die miteinander verbunden werden mussten, wie beispielsweise Airflow.
Übrigens wurde die Syntax von Envision absichtlich in vielerlei Hinsicht an die von 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 man, wenn man mit Python vertraut ist, Envision in einer Woche erlernen kann. Es gibt feine und tiefgreifende Unterschiede, aber was die Syntax betrifft, gibt es viele Gemeinsamkeiten. Python hat viele Vorzüge, wie zum Beispiel Einfachheit und Reinheit im Design. Auch wenn ich sage, dass Python nicht alle Kriterien erfüllt und in der Produktion schwerwiegende, nicht wiederherstellbare Probleme verursachen kann, heißt das nicht, dass Python ohne Vorzüge ist. Das will ich nicht behaupten. Ich glaube, dass Python viele Vorzüge hat. Nochmals: Wir sprechen hier spezifisch darüber, wie man supply chains in der Produktion betreibt, was ein ganz spezielles Problem darstellt.
Frage: Wie würden Sie einen Kunden verstehen lassen, 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 Mehrwert, und nun wollen wir auf das nächste ERP umsteigen, das supply chain Optimierung bietet.” Das ist eine schreckliche Situation für mich, denn ich muss dem Kunden klarmachen, dass er nicht ein Produkt sucht, sondern zwei: eines, das sein ERP ersetzt und die Management-Seite besser abwickelt, und eines, das die Optimierung übernimmt.
Wenn man an diese legacy ERPs denkt, habe ich großen Respekt vor ihnen, insbesondere vor diesen AS/400-Produkten mit Kommandozeilenterminal auf altmodischen IBM-Mainframes. Vom Management-Aspekt her leisten sie in der Regel eine sehr ordentliche Arbeit. Was die Kunden tatsächlich suchen, ist vielleicht eher eine Web-Oberfläche statt einer Kommandozeile, aber wird dies ihre Teams vor Ort produktiver machen? Das bezweifle ich. Kommandozeilen mit textbasierten Terminalen können unglaublich flink und produktiv sein – ganz ohne Ablenkungen.
Es ist also ziemlich schwierig, weil wir all den Unsinn entwirren müssen, der von unseren Wettbewerbern propagiert wird. Darüber hinaus müssen wir erklären, dass das ERP die supply chain nicht optimieren wird und dass es so etwas wie KI oder Blockchain nicht gibt, sondern lediglich Klassen statistischer Modelle. Leider verlieren wir in diesem Stadium die meisten unserer Interessenten. Das ist einer der Gründe, warum ich diese Vorlesungen überhaupt halte, denn es dauert Stunden, den Kern des Problems zu erfassen und zu erklären, warum wir das Problem so sehen müssen, wie ich es tue.
Frage: Was empfehlen Sie als Plattform, um der Komplexität der Planung mehrerer Produkte mit probabilistischer Nachfrageverteilung zu begegnen?
Nun, Lokad natürlich. Aber bedenken Sie, dass ich als CEO von Lokad und Mehrheitsinhaber des Unternehmens einen Interessenkonflikt in meiner Meinung habe. Ich bin fest davon überzeugt, dass Lokad die Plattform ist, die Sie benötigen – aber bitte verstehen 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 entwickelt, um mit probabilistischer Nachfrageverteilung umzugehen – und es geht nicht nur um probabilistische Nachfrageverteilung. Es berücksichtigt auch stochastische Durchlaufzeit-Verteilungen, stochastische Rücklaufverteilungen und mehr. Wir müssen alle möglichen Zukünfte mit Wahrscheinlichkeiten betrachten, unter Berücksichtigung aller Arten von Unsicherheiten. Die Nachfrage ist dabei sehr wichtig, in der Regel die wichtigste, aber sie ist nicht die einzige.
Ich glaube, ich habe alle Fragen durchgegangen. Ich überprüfe noch einmal, ob ich etwas verpasst habe… Keine weiteren Fragen. Also, vielen Dank an alle, die sich diese Vorlesung angesehen haben, und bis nächste Woche, am selben Tag, zur gleichen Zeit. Bis bald. Auf Wiedersehen.
Referenzen
- Joel on Software: Und zu unterschiedlichsten und gelegentlich verwandten Themen, die für Softwareentwickler, Designer und Manager sowie für diejenigen, die – ob aus Glück oder Pech – in irgendeiner Weise mit ihnen zusammenarbeiten, von Interesse sein werden – von Joel Spolsky, 2004
