Gesamtes Transkript
Conor Doherty: Das ist Supply Chain Breakdown, und in den nächsten 30 oder so Minuten werden wir den Hype um digital twins – insbesondere im supply chain – entlarven. Mein Name ist Conor. Ich bin Kommunikationsdirektor bei Lokad, und zu meiner Linken im Studio sitzt, wie immer, der unergründliche Joannes Vermorel, Lokad’s Gründer und CEO.
Nun, bevor wir anfangen, kommentiert bitte unten – erstens, woher kommt ihr, und zweitens, was haltet ihr von digital twins? Denkt daran, wir sind hier, um über eure Bedenken zu sprechen. Stellt auch eure Fragen, wann immer sie auftauchen. Falls ihr etwas hört, das Joannes sagt, und ihm etwas entgegensetzen wollt, fühlt euch frei, es unten zu posten, und ich werde ihn in etwa 20 Minuten dazu befragen.
Und damit, keine Zeit mehr verlieren. Joannes, nimm den Hype um digital twins raus, denn ich weiß, dass sie schon länger existieren, aber erklär uns: Was ist ein digital twin in einfachen, grundlegenden Worten? Und was ist das Problem, von dem zumindest viele glauben, dass digital twins es lösen sollen?
Joannes Vermorel: Also, was digital twins angeht, würde ich sagen, wenn man die Beratungsvariante nimmt – die ist nicht die, der ich folgen würde – würden sie sagen: Es ist eine genaue Darstellung deines supply chain, vollständig digital, die es dir ermöglicht, so ziemlich alles in die Zukunft zu projizieren. Als hätte man eine vollständige, perfekt genaue Simulation deines gesamten supply chain. Zumindest ist das die ideale Sichtweise für deine digital twins im supply chain.
Und die Idee von digital twins existiert auch in anderen Bereichen, und in anderen Domänen kann man manchmal eine sehr genaue Simulation eines physikalischen Systems haben. Praktisch gesehen ist es aber nur ein neu verpackter Monte-Carlo-Simulator. Diese Simulatoren gibt es seit etwa vier Jahrzehnten. Das einzige entscheidende Merkmal ist, dass sie sehr, sehr einfach zu implementieren sind, und es macht relativ viel Spaß, als Spielzeugprojekt einen Monte-Carlo-Simulator eines Systems zu erstellen, solange man nicht wirklich etwas wie Genauigkeit der Simulationen erwartet.
Conor Doherty: Ich werde sofort einhaken, weil du da ein paar interessante Punkte angesprochen hast. Du hast also mindestens zwei Anwendungen genannt. Eine war, wie digital twins im supply chain-Kontext vermarktet werden könnten – das ist eine Kategorie. Aber du hast gesagt, es gibt eine bereits bestehende oder nachhaltigere Anwendung; du sprachst von physischen Produkten. Könntest du diese Trennung etwas genauer erläutern?
Joannes Vermorel: Ja. Ich meine, die Idee von Simulatoren – es gibt drei Schlüsselaspekte: mikroanalytisch, diskret und stochastisch. Das sind drei Ideen. Wenn Leute an Monte-Carlo-Simulatoren denken, sind das die drei Aspekte, die man berücksichtigt.
Mikroanalytisch bedeutet, dass man sein System in etwas wie Atome oder sehr, sehr kleine Elemente zerlegt, die einfache Verhaltensweisen aufweisen, geregelt von einfachen, vollständig quantifizierbaren Gesetzen. Das ist der mikroanalytische Ansatz. Dann diskret: Für deinen Computer nimmst du an, dass sich alles in schönen, gleichmäßigen Schritten verhält – im supply chain macht das Sinn – auch in Bezug auf die Zeitdimension. Also wirst du sagen: “Okay, ich erstelle einen Simulator, der mit einem Schritt pro Tag arbeitet,” oder so ähnlich.
Und der letzte Punkt ist der stochastische Aspekt: Bei manchen Verhaltensweisen fügt man einfach etwas Zufall hinzu. Deshalb spreche ich von einem Monte-Carlo-Simulator. Du ordnest bestimmten Verhaltensweisen, die zufällige oder stochastische Elemente beinhalten, entsprechende Eigenschaften zu, und dann kannst du deinen Simulator wiederholt viele Male laufen lassen, um angeblich einen zukünftigen Zustand deines supply chain zu projizieren, oder zumindest kann der Simulator in die Zukunft fortschreiten. Und da er als digital twin deines supply chain gedacht ist, stellt er die Zukunft deines supply chain dar.
Conor Doherty: Danke, und ich denke, das wirft noch einmal einen zentralen Punkt auf, wie man die Diskussion unterteilen kann. Wenn Leute darüber sprechen, einen digital twin in der Fertigung oder Reparatur einzusetzen, kann man sagen: “Ich habe einen digital twin. Er ist eine deterministische Darstellung eines kompletten Flugzeugs.” So hat ein A320 ungefähr 320.000 Teile. Man weiß, wie viele Teile es gibt; man kann das modellieren; es ist festgelegt. Das ist eine digitale Replik oder digitale Darstellung eines bekannten, physischen Produkts oder Objekts.
Wie gut kannst du dasselbe Konzept auf ein geografisch verteiltes Netzwerk wie einen supply chain anwenden, das nicht nur physische Teile wie Produkte und Trucks und weiteres umfasst, sondern auch Verhaltensmuster, Tendenzen und Politik – all das, was diese Dinge beeinflusst?
Joannes Vermorel: Das Hauptproblem sind die Gesetze, die deine Atome, deine elementaren Simulationseinheiten, regeln. Wenn du dich in der physischen Welt befindest, kannst du buchstäblich Elektromagnetismus und dergleichen anwenden, um eine physikalisch genaue Entwicklung deines Systems zu erzielen, weil du annimmst, dass, wenn du Dinge weit genug zerlegst, das, was übrig bleibt, sehr, sehr bekannten Gesetzen folgt. Wenn du beispielsweise beschreiben möchtest, wie Flüssigkeit durch verschiedene Rohre fließt, stehen dir die mikrofluidischen Gleichungen zur Verfügung, und du kannst eine Finite-Elemente-Simulation durchführen.
Aber der entscheidende Punkt ist, dass man annimmt, dass es Gesetze gibt, die die Elemente deines Systems nahezu perfekt bestimmen, und dass dann der einzige verbleibende Faktor die Auflösung deiner Simulation ist, die vielleicht nicht ausreicht, um super genau zu sein. Das Problem mit einem digital twin im supply chain ist, dass die Herausforderung nicht wirklich in der Auflösung liegt. Die Herausforderung ist, dass es keineswegs klar ist, ob man überhaupt relevantes Vorwissen über das Verhalten dieser einfachen Einheiten hat, denn diese einfachen Einheiten – sagen wir, du möchtest einen Lieferanten simulieren – sind absolut nicht einfach.
Es gibt keine – du kannst so viele vereinfachte Annahmen über das Verhalten dieses Lieferanten treffen, wie du möchtest, aber nur weil du eine Annahme über dieses Element heraufbeschwörst, heißt das nicht, dass sie wahr ist. Und das Gleiche gilt für alles: Kunden, Lager, Routen, die deinen gesamten supply chain verbinden, etc. Es gibt also wirklich ein grundlegendes Problem: Ja, du kannst einen Simulator erstellen, indem du dein System zerlegst und allen Atomen bestimmte Verhaltensweisen zuschreibst, aber sind diese Verhaltensweisen auch irgendeiner Art von korrekt? Das ist die große, große Herausforderung, und genau das wird bei diesen digital twins im supply chain typischerweise nie diskutiert – die Korrektheit der Modellierung.
Conor Doherty: Korrektheit und andere Metriken – darauf kommen wir zurück – aber ich möchte noch etwas tiefer graben. Tatsächlich werde ich dir eine sehr klare Definition vorlesen. Ob du ihr zustimmst oder nicht, sie ist eindeutig, und ich möchte deine Reaktion dazu hören. Ich werde dir noch nicht verraten, von wem sie stammt – du kannst später raten – aber sie ist pointiert. Zitat: “Digital twins can be used to model the interaction between physical and digital processes all along the supply chain from product ideation and manufacturing to warehousing and distribution, from in-store or online purchases to shipping and returns. Thus digital twins paint a clear picture of an optimal end-to-end supply chain process.” Was ist deine Meinung dazu? Welche Teile widersprechen dir?
Joannes Vermorel: Diese Definition beschreibt nichts als die Absicht. Sie sagt einfach: “Okay, die Absicht ist es, etwas zu haben, das all die in dieser Definition beschriebenen Dinge tut,” also eine end-to-end genaue Darstellung von bla, bla, bla. Das ist die Absicht. Sie sagt nichts darüber, wie es gemacht wird. Und meine Botschaft ist: Das Wie zählt.
Du kannst dir viele unglaubliche Werkzeuge ausdenken oder wünschen. Ich würde gerne wissen – was wäre ein perfekter AI Assistant? Etwas, das eine wesentlich höhere Intelligenz als ein Mensch besitzt und alles, was ein Mensch kann, nur besser macht. Okay, ich habe gerade definiert, was ein perfekter AI Assistant wäre. Bedeutet das, dass es einen gibt, der sofort verfügbar ist? Das Problem ist: Wenn du etwas über seine Absicht definierst, sagt das nichts über die Machbarkeit oder darüber, ob dieses Ding überhaupt existiert.
Also ja, wir haben eine schöne intentionale Definition. Und ich, wenn ich “Monte Carlo Simulator” sage, habe ich genau das Gegenteil gemacht. Ich begann mit: “Okay, was machen Unternehmen hinter den Kulissen, wenn sie das Schlagwort ‚digital twin‘ verwenden?” Und meine Antwort ist, soweit ich beobachten kann: Monte Carlo Simulator. Warum? Weil er extrem einfach zu implementieren ist. Buchstäblich könnte ein Erstsemester in Informatik das in nur wenigen Tagen umsetzen – wahrscheinlich schaffen es sogar die Klugen in einem Nachmittag. Und ja, solange es dir egal ist, ob deine Simulation irgendeine Relevanz für die reale Welt hat, ist es super unkompliziert zu implementieren.
Conor Doherty: Zurückkommend, du redest über die Absicht. Der Zweck, wie ihn viele präsentieren, wäre – um dir etwas entgegenzusetzen – dass viele Anbieter, Berater und Befürworter eines digital twin argumentieren würden, dass ein digital twin die decision-making verbessert, indem er – selbst wenn es durch Monte Carlo geschieht – eine Sandbox bereitstellt, in der du mit scenarios spielen kannst, wie etwa “Was, wenn der Lieferant zu spät kommt? Was, wenn es eine Blockade im Suezkanal gibt?” oder Ähnliches.
Joannes Vermorel: Eine künstliche allgemeine Intelligenz verbessert per Definition die Rentabilität jedes Unternehmens. Wenn du etwas hast, das so intelligent ist wie ein Mensch, aber keinen Lohn bekommt, ja, wird es die Rentabilität steigern. Aber kommen wir zurück zur Frage: Ist dieses System überhaupt verfügbar, und was sind die zugrunde liegenden Techniken? Diese Parteien präsentieren es als gegeben: Es ist bereits da, wir haben es, es besitzt all diese guten Eigenschaften. Aber Moment – was befindet sich unter der Haube?
Und meine Botschaft ist: Soweit ich weiß, hatten buchstäblich alle Unternehmen, die ich gesehen habe und die digital twins vorantreiben, nichts anderes als naive Monte-Carlo-Simulatoren, die in meinem Buch auf Spielzeug-Niveau agieren. Sie sind schick. Es ist genau die nette Übung, die ich Erstsemestern in Informatik geben würde. Ja, es macht Spaß, so etwas zu implementieren, und es ist einfach. Aber das Problem ist: Es ist völlig erfunden.
Ja, du kannst deinen supply chain in eine Liste von SKUs, eine Liste von Kunden, eine Liste von Lieferanten zerlegen und all diesen Entitäten Verhaltensweisen zuweisen und dann die Simulation laufen lassen – absolut. Aber ist es tatsächlich korrekt? Das ist eine sehr große Frage. Ein Vergleich wäre: Nimm einfach SimCity 2000, das Videospiel – ein altes. Sie haben einen Karteneditor. Du kannst buchstäblich eine Karte bearbeiten, die genau wie Paris aussehen würde, alle Straßen exakt so anordnen wie in Paris – fast, denn wieder tritt das Problem der Diskretisierung auf, sodass es nicht exakt dieselben Straßen sind, aber nahe genug. Dann kannst du sagen: “Dieses Gebiet ist Wohngebiet, jenes Industriegebiet, jenes Gewerbegebiet.” Ja, du könntest das tun und dann die Spielsimulation fortschreiten lassen.
Gibt dir das eine genaue Simulation der Zukunft des urbanen Umfelds von Paris? Meine Antwort lautet absolut nicht – vor allem wenn Godzilla auftaucht; das ist ein disaster, das im Spiel passiert. Es liegt nicht daran, dass es sehr einfach zu erstellen ist. Noch einmal: Es ist sehr einfach, Simulatoren zu erstellen, und es macht Spaß. Die Frage ist wirklich: Warum glaubst du überhaupt, dass sie irgendeine Art von Genauigkeit besitzen werden?
In anderen Bereichen wie den Naturwissenschaften – sagen wir, Materialwissenschaften – ist dein Simulator gut, weil er im Grunde den Gesetzen der Physik gehorcht, die sehr gut bekannt und verifiziert sind. Also sind deine Verhaltensweisen im Grunde nicht erfunden: Du nimmst buchstäblich Physiklehrbücher und wendest Elektromagnetismus oder Fluiddynamik o.ä. an, und das sind die Verhaltensweisen, die deine Elemente, deine Atome bestimmen. Aber bei einem digital twin im supply chain musst du diese erfinden und heraufbeschwören – oder sie irgendwie entdecken – was eine sehr, sehr knifflige Angelegenheit ist. Meines Wissens tun die Anbieter von digital twins im supply chain, die das vorantreiben, gar nichts dazu, und das ist der eigentliche Kern der Abschweifung.
Conor Doherty: Du hast Genauigkeit und Korrektheit erwähnt, und um noch einmal zurückzuschlagen – übrigens, diese vorherige Definition stammt von McKinsey, derjenigen, mit der du nicht einverstanden warst. Und von einem zum anderen, denn diese kommt jetzt von BCG – oh, Entschuldigung, möchtest du etwas sagen?
Joannes Vermorel: Nochmals, das Problem ist, dass sie nur die Absicht beschreiben. Wenn es ein Stück Technologie gibt, konzentriere ich mich wirklich darauf, wie es funktioniert. Etwas über die Absicht zu definieren ist nett, aber damit kann man nicht beurteilen, ob es ein gutes Stück Technologie ist oder nicht. Ich habe nichts gegen die Absicht – die ist in Ordnung, ja. Die Frage ist: Hast du eine Definition, die dir ermöglicht, zu erkennen, ob dieses Stück Technologie besser oder schlechter ist als ein anderes für deinen supply chain?
Conor Doherty: In diesem Zusammenhang, laut – wieder, wir zitieren mit Quellen – laut Boston Consulting Group haben Unternehmen mit digital twins ihre Prognosegenauigkeit um 20 bis 30% verbessert. Ich meine, ist das nicht etwas, wofür die meisten Unternehmen brennen würden? Haben sie Unrecht, das zu verfolgen?
Joannes Vermorel: Digital twins sind meines Wissens in keinem forecasting competitions aufgetaucht. Es gibt zahlreiche Forecasting-Wettbewerbe; es gibt Dutzende von Techniken, die in diesen Wettbewerben zur Verbesserung der Prognosen eingesetzt werden. Ich habe noch nie etwas gehört, das in Verbindung mit digital twins in puncto Forecasting steht.
Also, siehst du, das Problem ist für mich, dass sie nicht genau definieren, auf welche Techniken sie sich tatsächlich beziehen – es könnte alles Mögliche sein. Meine Einschätzung – und das ist eine empirische Einschätzung – ist, dass Unternehmen, die digital twins vermarkten, im Grunde genommen Monte-Carlo-Simulatoren bauen, und diese bringen keinen überlegenen Mehrwert hinsichtlich Genauigkeit.
Conor Doherty: Aber man muss zugeben, dass es einen weiteren Punkt gibt, der bedacht werden muss, nämlich ob eine höhere Genauigkeit zwangsläufig zu besseren Entscheidungen führt – also zu dem, was man mit dem digital twin erreichen will. Es gibt also einen instrumentellen Nutzen und dann das, was man tatsächlich erreichen möchte – das Ziel, der Zweck.
Joannes Vermorel: Ja. Wenn wir sagen, dass wir bessere Entscheidungen mit höherer Kapitalrendite wollen, könnte konzeptionell der digitale Zwilling sagen: Wenn ich eine Richtlinie A habe, lasse ich diese durch meinen digitalen Zwilling laufen, bewerte die Kapitalrendite; dann habe ich Richtlinie B, mache dasselbe, und ich werde die Richtlinie wählen, die meine Entscheidung steuert und mir eine überlegene Rendite liefert. Konzeptionell, in Ordnung – warum nicht?
Aber nochmal: All dies hängt davon ab, dass Ihr digitaler Zwilling Ihnen eine korrekte wirtschaftliche Einschätzung liefert. Dieses Genauigkeitsproblem schlägt sich in Dollar nieder: Sie haben eine Kapitalrendite für Richtlinie A, eine Kapitalrendite für Richtlinie B. Aber nochmals: Hat Ihr digitaler Zwilling irgendeine Art von Korrektheit? Warum sollten Sie ihm vertrauen? Das ist eine sehr komplizierte Frage.
Wir können auf SimCity 2000 und Paris zurückgehen. Ich kann das Spiel mit unterschiedlichen Steuerstufen für die Stadt laufen lassen – das existiert im Spiel. Aber wird mir dieses Ding etwas wirklich Genaues über die Stadt Paris sagen? Ich denke, es wäre offensichtlich völlig verrückt zu glauben, dass ein Videospiel genutzt werden kann, um die Entwicklung einer echten Metropole präzise zu modellieren. Das ist genau das gleiche Problem, das ich mit diesen digitalen Zwillingen für die supply chain habe. Solange man nicht viele Faktoren hinzufügt, hat man nur Wunschdenken.
Ja, es wäre super, wenn wir etwas hätten, das all das sehr genau erledigt. Wenn Sie mir sagen, dass diese Monte-Carlo-Simulation etwas Bahnbrechendes sei, das dies ermöglichen würde – ich glaube wirklich nicht. Bestenfalls ist sie nur eine winzige Komponente: super einfach. Das wäre ein bisschen so, als ob man sagt: “Computer werden mit einbezogen.” Ja, wahrscheinlich. Es ist eine gute Idee, Computer einzubeziehen, ebenso wie ein Monte-Carlo-Simulator eine nette Technik ist. Es ist nur eine winzige Komponente; dem stimme ich zu. Es ist einfach sehr, sehr oberflächlich. Es ist ein wenig so, als ob man sagt: “Es wäre besser, für ein Auto Metall zu verwenden.” Sicherlich wird Metall verwendet, aber es bringt Ihnen kein Auto.
Conor Doherty: Ich möchte hier nicht zu lange verweilen, da es Publikumfragen gibt und ich auch über einige der auf LinkedIn erwähnten Punkte sprechen möchte, aber bevor wir weitermachen, noch eine letzte, sozusagen technisch angehauchte Frage. Einer der Gründe, warum digitale Zwillinge so beliebt sind, ist, dass sie hochgelobt und als Mittel zur Bekämpfung von Volatilität und zur Bewältigung von Unsicherheit vermarktet werden. Nun weiß ich, dass für uns bei Lokad und für viele andere Praktiker probabilistische Prognosen der Weg dazu sein werden. Also, auf hoher Ebene: Was sind die Einschränkungen? Wie füllt Ihrer Einschätzung zufolge die probabilistische Prognose die Lücken, die der digitale Zwilling hinterlässt?
Joannes Vermorel: Zunächst einmal ist ein Monte-Carlo-Simulator im Maßstab Ihrer supply chain effektiv nichts anderes als ein probabilistisches Prognosemodell. Das ist buchstäblich das, was er ist. Wenn wir von probabilistischer Prognose sprechen, sind wir nicht sehr spezifisch, welche zugrunde liegenden Modelle tatsächlich verwendet werden. In der Vorlesung gebe ich eine Reihe von Beispielen, wie man diese Modelle aufbauen kann. Aber wenn man einfach “probabilistische Prognose” sagt, sagt man nichts über das Modell selbst aus.
Sie können Ihr probabilistisches Prognosemodell mit einem Monte-Carlo-Simulator aufbauen. Sie lassen die Simulation einfach laufen, sammeln Ihre empirischen Wahrscheinlichkeitsverteilungen, und wenn Sie Ihre Simulation tausendmal ausführen, erhalten Sie schöne mehrdimensionale Histogramme, die Ihnen Ihre Wahrscheinlichkeitsverteilungen liefern – und damit haben Sie Ihre probabilistische Prognose. Es besteht also eine Dualität zwischen einem Monte-Carlo-Simulator und einer probabilistischen Prognose. Aus den Wahrscheinlichkeiten können Sie Abweichungen generieren – das gibt Ihnen diese stochastischen Verhaltensweisen. Aber wenn Sie diese stochastischen Verhaltensweisen haben, können Sie sie ausführen und die Wahrscheinlichkeitsverteilungen erhalten. Grundsätzlich ist es dasselbe.
Es gibt jedoch einen entscheidenden Punkt: Sobald Sie beginnen, Ihren Monte-Carlo-Simulator als eine probabilistische Prognose-Engine zu betrachten, können Sie seine Genauigkeit bewerten – was ebenfalls sehr wichtig ist und was ich bei den Anbietern, die digitale Zwillinge anbieten, als sehr mangelhaft empfinde. Sie erwähnen nie einmal, dass sie eine probabilistische Prognose-Engine besitzen und dass diese daher hinsichtlich der Genauigkeit mit für probabilistische Prognosen relevanten Metriken bewertet werden muss.
Conor Doherty: In Ordnung. Ich weiß, wir könnten ewig darüber sprechen, aber das beworbene Thema waren speziell digitale Zwillinge. Vor ein paar Tagen haben Sie auf LinkedIn eine Umfrage durchgeführt, in der Sie Ihr Publikum gefragt haben: “Was sind die größten Hindernisse für digitale Zwillinge?”, denn viele derjenigen, die zuschauen und dies später sehen werden, sind Unternehmen, die darüber nachdenken, diese Technologie einzuführen oder sie bereits einführen.
In dieser Umfrage gaben 52 % der Befragten an, dass das größte Hindernis unordentliche oder unvollständige Daten seien. Zunächst einmal – und das ist etwas, woran ich mich erinnere, dass Sie es vor ein paar Jahren gesagt haben – angesichts der Größe der Unternehmen, die einen digitalen Zwilling in Betracht ziehen würden, sprechen wir von sehr großen Unternehmen; vermutlich verfügen sie über teure, zuverlässige ERPs. Die Frage lautet also: Wie genau stellen unordentliche oder unvollständige Daten ein Hindernis dar für etwas, das Sie als recht einfach zu implementieren beschrieben haben?
Joannes Vermorel: Hier, wenn Sie unter fehlenden Daten die Verhaltensweisen verstehen – also das, was das Verhalten all dieser Einheiten charakterisiert –, würde ich sagen, ja. Aber es gab meiner Meinung nach nie die Erwartung, in einem ERP die Parameter zu finden, die beispielsweise das Verhalten eines Ihrer Kunden beschreiben könnten. Ich glaube daher nicht, dass das gemeint ist – ganz gewiss.
Meiner Auffassung nach sind Daten immer der Sündenbock. Wenn die Technologie super oberflächlich ist und nicht das liefert, was versprochen wurde, wird unweigerlich die mangelhafte Datenqualität dafür verantwortlich gemacht. Das entspricht keineswegs den Erfahrungen, die wir bei Lokad gemacht haben. Meiner Erfahrung nach verfügen Unternehmen mit einem Jahresumsatz von über einer Milliarde Dollar oder Euro über ausgezeichnete Daten. Sie wissen ziemlich genau, was sie verkaufen, was sie kaufen und genau, was sie auf Lager haben. Ja, hier und da gibt es buchhalterische Fehler, aber wir sprechen hier von etwa 0,1 % Fehlerquote bei buchhalterischen Fehlern.
Insgesamt, was die Genauigkeit der Daten angeht, ist sie perfekt. Der gesamte Warenfluss – von der Beschaffung über den Transport, die Umwandlung bis zur Verteilung – ist nahezu mit Sicherheit bekannt. Die Qualität dieser Daten ist sehr hoch. Ja, einige andere Daten können etwas unschärfer sein, vor allem, wenn es um Werbepläne oder Ähnliches geht, aber die zentrale Transaktionshistorie ist ausgezeichnet. Technisch gesehen ist das Einzige, was Sie wirklich benötigen, um einen Simulator zu bauen. Sie hätten diese Systeme, die sich im Laufe der Zeit entwickeln und Transaktionen erzeugen, und Ihr digitaler Zwilling sollte in der Lage sein, als Spiegelbild dessen in die Zukunft zu blicken und den zukünftigen Zustand Ihrer Systeme vorherzusagen.
Aber das ist nicht der Fall. Das ist das Problem. Laut ihnen tun sie es nicht, und dann wird die Datenqualität verantwortlich gemacht. Immer wenn ich diese Geschichten über Datenprobleme höre, höre ich von einer unzureichenden Technologie, die im Wesentlichen Müll produziert, und die Leute sagen: “Oh, das Ergebnis ist Müll”, aber es muss daran liegen, dass die Eingabe Müll ist – das GIGO-Problem, Garbage In, Garbage Out. Aber was, wenn die Eingabe völlig in Ordnung ist? Meiner Auffassung nach ist die Eingabe nahezu einwandfrei – und das war sie bei der überwiegenden Mehrheit großer Unternehmen in den letzten zwei Jahrzehnten.
Das bedeutet nicht, dass es keine Datenherausforderungen gibt. Eine der zentralen Herausforderungen besteht darin, dass man, wenn man sich ein ERP anschaut, 10.000 Tabellen findet und jede Tabelle etwa 50 Felder hat. Das ist eine gewaltige Herausforderung. Aber das bedeutet nicht, dass die darin enthaltenen Daten Müll sind. Es spiegelt lediglich die Tatsache wider, dass Ihre Geschäftssysteme nicht darauf ausgelegt wurden, Ihnen als data scientist das Leben zu erleichtern, um Ihren Monte-Carlo-Simulator zu entwickeln. Das ist ein völlig anderes Problem.
Conor Doherty: Apropos Probleme, ein weiteres Problem, das von 21 % der Befragten genannt wurde, war eine fragile oder fehlerhafte Modellierung. Sie sagten zuvor, dass die Installation diesbezüglich nicht besonders kompliziert sei – das ist die Art von Sache, die man einem Erstsemester der Informatik zutrauen könnte. Also komme ich noch einmal zur Frage: Wenn Sie milliardenschwere Unternehmen haben und es sich um einen sehr geradlinigen Prozess handelt, warum sagen dann ein Fünftel der Befragten, dass die Modellierung das Problem darstellt?
Joannes Vermorel: Monte-Carlo-Simulatoren sind konzeptionell super einfach und in der Umsetzung extrem unkompliziert. Allerdings werden Sie sehr bald mit grundlegenden Leistungsproblemen konfrontiert. Lassen Sie mich das erklären. Von wie vielen SKUs sprechen wir? Eine Million – ungefähr so viele bei einem Unternehmen mit über einer Milliarde. Nehmen wir an, eine Million SKUs.
Dann, wie viele CPU-Zyklen benötigen wir, um eine SKU nur für das betreffende Verhalten zu simulieren? Nehmen wir an, mindestens 10 CPU-Zyklen – und wir wären super effizient, wenn wir das annehmen. Und wie viele Tage? Nehmen wir an, wir haben einen Simulator, der einen Tag auf einmal durchläuft – 100 Tage. Also sprechen wir von 1 Million mal 1.000 – also einer Milliarde CPU-Operationen – um 100 Tage zu simulieren, grob geschätzt.
Das Problem ist, dass es stochastisch ist – ein mikroanalytischer, diskreter, stochastischer Simulator – sodass Sie Ihre Durchläufe wiederholen müssen. Wie oft müssen Sie Ihre Simulation ausführen, damit Sie einigermaßen verlässliche Statistiken erhalten? Wegen des Auflösungsproblems müssen Sie sie mindestens tausendmal wiederholen. Damit sprechen wir von tausend Milliarden Operationen. Kein Problem für moderne Computer, es sei denn, Sie machen etwas wirklich Anspruchsvolles mit dem Computer und beginnen mit Parallelisierung und Ähnlichem. Wir reden hier von etwa 20 Minuten Rechenzeit – es gibt zahlreiche Lösungen, all dies zu parallelisieren – aber Menschen, die nur einen schnellen und einfachen Simulator verwenden, werden das nicht tun. Also nehmen wir einfach etwas Geradliniges an – in Ordnung. Zwanzig Minuten erscheinen nicht allzu schlecht – außer…
Außer dass Sie jetzt verschiedene Optionen überprüfen möchten. Zum Beispiel: “Sollte ich diese eine Einheit hier oder jene Einheit dort platzieren?” Jede einzelne Option, die Sie untersuchen, bringt diese “Steuer” mit sich, da Sie Ihre Simulation zunächst für den Basisfall ausführen und dann etwas ausprobieren und erneut simulieren müssen. Wenn Sie lediglich eine sehr übergeordnete Fragestellung haben – etwa “Was, wenn sich die Kosten des Working Capital ändern? Ich möchte nur das Ergebnis wissen” – ist das in Ordnung: Sie führen die Simulation zweimal aus, und Sie erhalten den Unterschied.
Aber wenn Sie anfangen, Fragen zu stellen wie “Wie viele Einheiten sollte ich an jedem einzelnen Ladenstandort einsetzen?” dann müssen Sie Ihren Simulator tausende und tausende Male ausführen – einmal für jede einzelne Mikrofrage, die Sie beantworten möchten. Plötzlich wird den Menschen klar: “Oh, 20 Minuten sind so langsam. Ich muss das hunderttausende Male, möglicherweise Millionen – für jede SKU oder so – ausführen.” Dann wird es zu einem großen Problem. Die Lösung wird dann: Dieser mikroanalytische Ansatz, bei dem ich alles auf SKU-Ebene simuliere – ach, das wird so mühsam. “Also werden wir eine Simulation auf einer viel aggregierteren Ebene durchführen.”
Aber nun haben wir ein weiteres großes Problem: Alles hing davon ab, dass die Verhaltensweisen für Ihre Simulationsatome auf SKU-Ebene korrekt sind. Es war bereits eine Herausforderung zu behaupten, dass es einfach sei und dass offensichtliche Verhaltensmuster gelten würden. Wenn Sie auf DC-Ebene aggregieren, was veranlasst Sie zu glauben, dass Sie jemals die richtigen Gesetze finden, die den Zu- und Abfluss in einem Distributionszentrum regeln? Dies ist ein sehr komplexer Teil Ihres Netzwerks. Es gibt keinen Grund, davon auszugehen, dass einfache Gesetze dies regeln würden. Gleiches gilt, wenn wir von einem B2B-Kunden sprechen – einem Kunden, der Tonnen von sehr unterschiedlichen Produkten zu verschiedenen Zeitpunkten bestellt, usw.
So hatten Sie dieses Simulatorproblem. Der Simulator ist auf Mikroebene einfach, aber sehr schnell stoßen Sie auf Leistungsprobleme. Sie können aggregieren, aber wenn Sie aggregieren, wird das Problem, korrekte Verhaltensweisen für Ihren Simulator zu haben, absolut verstärkt.
Conor Doherty: Ich denke, ein wesentlicher Aspekt davon – für den Fall, dass es das erste Mal ist, dass die Leute uns darüber sprechen hören – ist folgender: Wenn Sie von Entscheidungen sprechen, beschränken sich die Entscheidungen im Rahmen von Lokad nicht darauf, “Nun, ich habe eine Einheit; ich sende sie dorthin oder nicht.” Ich meine, es gibt Kombinationen für all diese Entscheidungen. Ich könnte eine Einheit dorthin schicken oder keine. Ich kann eine Einheit dorthin und eine hierher schicken oder keine, oder zwei dorthin und eine hierher, oder liquidieren, oder ich kann den Preis einer Einheit hier an diesem Ort erhöhen. Die lokale Perspektive ist also unglaublich granular, falls es den Leuten nicht klar war, wie detailliert es hier zugeht. Es ist wie unter dem Mikroskop – so granular ist es.
Und übrigens, der Grund, warum wir so granular arbeiten, ist, dass – wenn wir zur Modellierung dieser Verhaltensweisen zurückkehren – wir, um Vertrauen in das wirtschaftliche Ergebnis zu haben, ganz unten ansetzen müssen. Es ist der einzige Bereich, in dem wir tatsächlich nachvollziehen können, wie viel es gekostet hat, dies zu produzieren, wie viel der Kunde für diese eine Einheit zahlt usw.
Joannes Vermorel: Genau. Deshalb arbeiten wir ganz unten. Das Problem bei digitalen Zwilling-Initiativen ist, dass sie sehr schnell – mit ihren Monte-Carlo-Simulatoren – feststellen, dass sie Leistungsprobleme haben, und daher direkt zu einem höheren Aggregationsniveau wechseln, das einfacher zu berechnen ist. Aber dann wird das Problem, diese korrekten Verhaltensweisen zu haben, absolut enorm, und ja, dann haben Sie einen Simulator, der potenziell stark ungenau ist. Es ist nicht einmal klar, warum man dem Simulator überhaupt glauben sollte, weil diese Verhaltensweisen, die diese Einheiten steuern, völlig erfunden sind.
Conor Doherty: Nochmals, wir werden in einem weiteren Vortrag auf den Wert von Entscheidungen zurückkommen – wir haben kürzlich darüber mit Adam Dejans Jr und Warren Powell gesprochen. Wer dazu mehr erfahren möchte, sollte sich das neueste Video hier ansehen. Weiter geht’s: Ein weiteres zentrales Hindernis für die Einführung, das Ihr Publikum erwähnte, war das Change Management. Das ist etwas, das bei nahezu jeder Art von Technologie auftaucht. Aber wenn wir von etwas sprechen – Sie benutzten das Spiegelbild – haben Sie es im Wesentlichen so beschrieben, dass, wenn es gut funktioniert, man ein Spiegelbild von dem hat, was bereits existiert. Also lautet die Frage: Warum sollte ein Spiegelbild eines bereits existierenden Zustands ein umfangreiches Change Management erfordern?
Joannes Vermorel: Wenn Sie etwas hätten – und ich fordere wirklich heraus, dass die Unternehmen, die diese Technologien vorantreiben, es tun – aber wenn Sie etwas hätten, das ein hochdimensionaler Prädiktor für den zukünftigen Zustand Ihrer supply chain ist, was inspirierend genau das ist, was diese digital twins anstreben – dann ist das Interessante, dass, wenn es von Ende zu Ende umgesetzt wird, es keine Silos mehr gibt. Sie können buchstäblich die Auswirkungen jeder einzelnen Richtlinienänderung simulieren, die in jedem Silo durchgeführt werden soll, und dann haben Sie die Rendite für das Unternehmen als Ganzes. Es ist sehr attraktiv. Das bestreite ich nicht. Lokad ist in genau dieselbe Richtung unterwegs.
Was ich nochmals denke – und das erfordert jede Menge Change Management – ist, dass wenn Sie über eine Technologie verfügen, die es Ihnen ermöglicht, alle Silos des Unternehmens zu umgehen, dies überall Herausforderungen schaffen wird. Plötzlich werden Sie feststellen, dass die von, sagen wir, dieser Abteilung übernommene Richtlinie dem Unternehmen als Ganzes eigentlich schadet. Vielleicht verbessert sie die KPIs dieser einen Abteilung, aber das geschieht auf Kosten der Gesamtleistung. Also ja, der Umfang des Change Managements und des Widerstands ist naturgemäß sehr hoch. Dieser Aspekt, denke ich, ist vernünftig.
Conor Doherty: Joannes, wir haben, glaube ich, etwa 35 Minuten gesprochen und es gibt tatsächlich einige offene Fragen. In einem Moment werde ich zu den Fragen des Publikums übergehen. Bitte stellen Sie Ihre Fragen, bevor wir abschließen. Aber als abschließender Gedanke zu diesem Abschnitt – angesichts allem, was wir besprochen haben – was ist Ihr letzter Rat an supply chain Manager und Executives, die entweder dabei sind, diese Technologie einzuführen oder darüber nachdenken, sie einzuführen?
Joannes Vermorel: Man muss wirklich genau hinsehen, was unter der Haube passiert. Meiner Meinung nach ist es – ähnlich wie bei “demand sensing”, es kursieren noch weitere Buzzwords in supply chain Kreisen – dass, denke ich, im Fall von demand sensing nichts dahintersteckt; im Fall von digital twins steckt meistens ein kleines Etwas dahinter: es ist einfach ein Monte Carlo Simulator. Aber man muss wirklich hinterfragen, was unter der Haube steckt.
Ja, man kann darauf alle möglichen ansprechenden Benutzeroberflächen bauen. Man kann schicke Grafiken haben. Wenn man eine Karte einfügt, kann es sogar eine animierte Karte geben und so weiter. Das verkauft einen Traum. Man muss wirklich überprüfen, was in diesem System steckt. Üben Sie mechanische Sympathie aus: Sie sollten von Ihrem Anbieter verlangen, “Bitte sagen Sie mir, warum dieses System funktionieren wird.” Und verwechseln Sie nicht die Absicht. Die Leute sagen: “Das optimiert dies.” Nein, Moment. Sie optimieren den Gewinn – optimieren ist das Ergebnis. Ich frage nicht nach dem Ergebnis. Sie verkaufen mir etwas sehr Positives für das Unternehmen, aber erklären Sie mir, wie das numerisch umgesetzt wird.
Untersuchen Sie es. Wenn Sie am Ende feststellen, dass es sich nur um hartkodierte Regeln handelt, die in einer bestimmten Reihenfolge in diesem Monte Carlo Simulator angewendet werden, dann hat der Kaiser keine Kleider. Es ist einfach sehr, sehr oberflächlich.
Conor Doherty: Um Ihre eigenen Gedanken abzuschließen: Ich sagte zu Beginn, dass dies ein Gespräch ist, das Sie vor meiner Zeit hier geführt haben. Bereits im August 2022 sagten Sie, und ich zitiere, “Meine Wahrnehmung von digital twins ist, dass es nur eines dieser Buzzwords ist. Es sieht aus wie nichts weiter als ein glorifizierter Simulator.” Also, zum Abschluss: Stehen Sie in den letzten drei Jahren zu diesen Worten?
Joannes Vermorel: Da es sich um die Intention – “digital twin” – handelt, habe ich keinen Anbieter gesehen, der tatsächlich etwas von technologischer Substanz vorangetrieben hat. Ich stelle die Intention nicht in Frage. Wenn morgen jemand kommt und sagt, “Ich habe einen digital twin, aber anstatt nur einen super-naiven Monte Carlo Simulator à la Erstsemester-Informatikstudent zu verwenden, habe ich diese erstaunliche neue Technik, und ich gebe Ihnen den Bauplan dieser erstaunlichen neuen Technik; sie ist sehr ausgefeilt und funktioniert in Weisen, die diesem naiven Monte Carlo Ansatz weit überlegen sind,” würde ich sagen, “Ja, absolut, vielleicht ist es tatsächlich relevant.”
Es ist, als ob jemand sagt “AGI ist super gut,” und ich antworte, “Ja, AGI ist super gut. Haben Sie einen?” Also, nochmals: Ich stelle die damit verbundene Intention nicht in Frage. Ich hinterfrage wirklich die dahinterliegenden Techniken. Und bisher, drei Jahre später, habe ich keinen Anbieter gesehen, der mit Techniken aufwartet, die ich als bemerkenswert erachten würde.
Gibt es einen Anbieter – und ich wäre sehr daran interessiert, wenn das Publikum etwas beitragen könnte – der sagen würde, “Joannes, schau dir diese Techniken an, die wirklich bemerkenswert sind; sie treiben den Stand der Technik im Bereich stochastischer Simulationen voran”? Ich wäre ganz Ohr. Das habe ich nicht gesehen.
Conor Doherty: Das ist eine offene Herausforderung. Wenn jemand etwas mit Joannes teilen möchte, vernetzen Sie sich mit ihm und tun Sie es. Jedenfalls, Joannes, ich werde jetzt zu den Fragen des Publikums übergehen. Es gibt ein paar, die noch beantwortet werden müssen. Ich werde – einige davon sind ziemlich lang – vorlesen, also bitte aufmerksam zuhören.
Von Philip: Nehmen wir als Beispiel den Suezkanal-Vorfall. Angenommen, mein Modell schätzt eine einmonatige lead time für den Versand von Waren von Australien nach Frankreich unter Berücksichtigung normaler Verkehrsbedingungen. Was passiert, wenn ein Schiff den Kanal unerwartet blockiert, wie es zuvor geschehen ist? Das Modell könnte diese Störung nicht vorhersagen, und ich würde infolgedessen ernsthafte Verzögerungen und Schwierigkeiten erleiden. Frage: Wie gehen wir in der supply chain Modellierung mit solchen unvorhersehbaren Ereignissen um?
Joannes Vermorel: Das ist eine ausgezeichnete Frage. Hier liefert nämlich der Monte Carlo Simulator einen gar nicht allzu schlechten Einblick, und genau diesen Einblick nutzt Lokad. Es ist ein programmatischer Ansatz. Der Monte Carlo Simulator ist grundlegend ein programmatisches Paradigma: Sie implementieren in einer relativ allgemeinen Programmiersprache Ihre Regeln, die das Verhalten charakterisieren.
Bei Lokad wird es so gehandhabt, dass ein großer Teil der Verhaltensweisen auf historischen Daten erlernt wird. Aber weil es sich um ein Programm handelt, können Sie in dieses Programm eingreifen und absichtliche, programmatische Eingriffe vornehmen. Warum ist das nötig? Weil Sie wirklich sicherstellen müssen, dass Sie die lead times – die prognostizierten lead times – für die Lieferanten, die von dem Problem in diesem Kanal betroffen sein werden, gezielt erhöhen.
Zum Beispiel, wenn Sie Lieferanten in Asien haben, die aber per Luftfracht versenden, möchten Sie deren lead time nicht erhöhen. Da müssen Sie sehr vorsichtig sein und eventuell in den historischen Daten prüfen, wer die Lieferanten waren, deren lead time einem Bootstransport entsprach – oder Sie haben diese Information –, und dann können Sie programmatisch diesen zusätzlichen Impuls einfügen. Ich glaube, dass ein programmatischer Ansatz hier ein Gewinn ist. Im Bereich digital twins bin ich der Meinung, dass man das Problem aus der richtigen Perspektive angeht, nämlich durch programmatische Ansätze, genau wie Lokad es tut. In diesem Bereich ist es gut. Die Situation ist tatsächlich übersichtlicher im Vergleich zu alternativen, nicht-programmatischen Ansätzen, die lediglich Menüs und Schaltflächen zur Abdeckung jeder möglichen Situation erwarten. Wenn Sie Zugriff auf eine Programmiersprache im Kern Ihres Modells haben, können Sie immer maßgeschneiderte Regeln implementieren, die unvorhergesehene Ereignisse abbilden.
Conor Doherty: Danke. Ich mache weiter – von Manuel: “Theoretisch könnte diese Technologie, die digital twins, einen großen Einfluss auf die Entscheidungsunterstützung in der supply chain haben. Was halten Sie von der Entwicklung dieser Technologie und der Realisierung ihres Potenzials?” Ich denke, wir haben das ein wenig behandelt.
Joannes Vermorel: Als inspirierende Richtung ist die Idee, eine End-to-End-Modellierung der supply chain zu haben, großartig. Auch Lokad bewegt sich in diese Richtung. Was sind die Schlüsselkomponenten? Es gibt viele davon: differentiable programming ist eine davon; die Algebra der Zufallsvariablen ist eine weitere; relationale Algebra ist ebenfalls eine davon. Es gibt tonnenweise Komponenten.
Die Idee, Monte Carlo Simulatoren zu verwenden – übrigens, Lokad verfügt beispielsweise auch über Monte Carlo Komponenten – eröffnet einige sehr interessante Möglichkeiten. Wenn Sie absichtlich zufällige Verhaltensweisen in diesen Monte Carlo Prozess einbauen, entsteht ein sehr subtiler Aspekt bei der Fehlersuche. Sie führen Ihr Programm aus: es stürzt ab – das ist schlecht. Sie führen es erneut aus: es stürzt nicht ab – und das ist noch schlimmer, weil ein Fehler intermittierend auftritt, und wenn Sie den Fehler näher untersuchen wollen, ist er verschwunden. Bei Lokad nennen wir diese Probleme “Heisenbugs”. Es ist ein Fehler, der nur sporadisch auftritt; sobald man genauer hinsieht, verschwindet er.
Das ist ein massiver Mangel des klassischen, simplistischen Ansatzes bei Ihrem Monte Carlo Simulator. Es ist etwas, dem die Finanzwelt bereits in den frühen 90er Jahren begegnet ist. Was Sie wollen, ist Pseudo-Zufälligkeit und in der Tat etwas, das völlig deterministisch ist, selbst wenn Sie eine Monte Carlo Simulation durchführen. Es erfordert relativ clevere Tricks. Außerdem möchten Sie, dass diese Deterministik auch beim verteilten Rechnen erhalten bleibt, sodass das Ganze auf vielen CPUs und möglicherweise vielen Maschinen läuft – denn wie ich bereits sagte, wenn Sie einen Einzel-CPU, Single-Threaded-Ansatz haben, stoßen Sie sehr schnell auf Leistungsprobleme. Kein Problem: Sie können auf viele CPUs und viele Maschinen skalieren. Aber das erfordert Werkzeuge, bei denen, wenn Bugs oder Abstürze auftreten, das gesamte System vollkommen deterministisch bleibt.
Meiner Meinung nach gibt es noch viele Dinge, die letztlich entwickelt werden müssen, damit die Anbieter mit ihren digital twins etwas wirklich Substanzielles bieten können. Ich hoffe, dass Lokad zahlreiche davon mitbringt. Was ich sagen möchte – das ist der Kern meiner Kritik – ist, dass die Leute, die sich mit diesem Buzzword präsentieren, nicht viel Substanz liefern. Es ist sehr, sehr oberflächlich, und wenn man hinter die Fassade schaut – fordern Sie eine Demo an – sieht man nur einen sehr simplen, naiven Monte Carlo Simulator, der diese Leistungen nicht erbringen wird.
Conor Doherty: Perfekter Übergang zur dritten Frage, danke. Von Shashank – verzeihen Sie mir, falls ich es falsch ausspreche: “Joannes, wie ist Ihre Ansicht zum Monte Carlo Simulator versus agentischen stochastischen Modellen in supply chain Netzwerken?”
Joannes Vermorel: Es gibt mehrere Blickwinkel. Monte Carlo ist ein sehr nützliches Werkzeug; es ist ein numerischer Trick. Es ist sehr nützlich – ähnlich wie die lineare Algebra, ein super grundlegender, fundamentaler Trick. An sich ist es sehr nützlich. In einem Monte Carlo Simulator liegt jedoch die gesamte Intelligenz in den simulierten Verhaltensweisen, denn im Wesentlichen funktioniert ein Monte Carlo Simulator so: Ich habe eine Million Elemente; ich nehme Element eins; ich wende mein Verhalten an; ich erhalte eine Abweichung – ein nicht-deterministisches Verhalten – sodass ich die Abweichung am Ausgang von Element eins erhalte. Dann wiederhole ich das für Element zwei, drei usw. und wiederhole es über jeden Zeitschritt.
Das Kleingedruckte sind diese Verhaltensweisen, und das ist wirklich, wirklich knifflig. Die positive Seite des numerischen Tricks von Monte Carlo ist, dass er sich wunderbar in die sehr quantitative, hochdimensionale Welt der supply chain einfügt. Wenn wir von agentic AI sprechen – das wären, um konkret zu sein, LLMs – dann befassen sich LLMs andererseits mit Symbolsequenzen. Ein LLM – ein Large Language Model – ist eine Maschine, die zukünftige Sequenzen von Symbolen, sogenannte Tokens, vorhersagt.
In Bezug auf die Übereinstimmung mit den Daten, die Sie haben, ist es wirklich nicht so eindeutig. Ein LLM passt nicht gerade offensichtlich zu Ihrem supply chain System. Meiner Meinung nach werden Monte Carlo Simulatoren auch in 10 Jahren in der zukünftigen state der supply chain Technologien noch präsent sein? Ja, denn sie sind so ein grundlegender Baustein. Es ist, als würde man fragen: “Wird es in Ihren Systemen Quadratwurzeln geben?” Ja. Agentic AI wie LLMs – ich denke, sie haben ihren Platz, aber dieser Platz liegt möglicherweise nicht in der quantitativen Bewertung der supply chain. Ihr Einsatzbereich ist mehr am Rand, wo man mit Kunden, Lieferanten oder potenziell sogar Dritten interagieren muss und textbasierte Gespräche führt. Das ist ein Weg, um einige Daten einzubringen oder Interaktionen abzuschließen, aber es ist nicht der Kern der Optimierung.
Conor Doherty: Danke. Ich mache weiter zu Tao: “Ist Ihrer Ansicht nach das eigentliche Problem bei digital twins, dass die derzeit verwendeten Werkzeuge zur Simulation der supply chain fehlerhaft sind, oder liegt es daran, dass das richtige Werkzeug für die supply chain Optimierung vielleicht überhaupt keinen digital twin benötigt?”
Joannes Vermorel: Es ist genau der erste Grund. Diese Werkzeuge sind fehlerhaft – und zwar in einer sehr spezifischen Weise. Es handelt sich um ein super oberflächliches, leicht zu implementierendes Werkzeug. Man muss bedenken, dass es in der Welt der enterprise software eine Versuchung gibt: Sobald man mit dem Vorstand oder einem CEO ins Geschäft kommt, wird das Preisschild sehr hoch sein – selbst wenn man im Grunde eigentlich nichts verkauft. Es mag seltsam klingen, aber in der enterprise software werden Sie etwas für über 100.000 $ pro Jahr verkaufen, nahezu egal, was Sie tatsächlich anbieten.
Es gibt also einen ständigen Zustrom von Akteuren, die mit sehr einfacher Technologie – super simpel – aufwarten, aber sie haben die Kunst der Verpackung gemeistert. Sie haben Ihren Monte Carlo Simulator – ehrlich gesagt, er ist nichts, ein Nichts-Burger – aber er hat eine schicke Verpackung. Dann setzen Sie, ganz wie in der Definition, die wir erhalten haben, eine Darstellung ein, die lautet: “Wer will nicht etwas haben, das dies und das optimiert und dies und das verbessert, etwa in der Fertigung und überall sonst?” Ja. “Was kostet dieses Widget, das mein ganzes Unternehmen verbessert?” “So-und-so – 100.000 $.” “Okay, es ist super günstig. Probieren wir es aus.”
Aber meine Botschaft lautet: Untersuchen Sie, was unter der Haube steckt. Hat es wirklich Substanz? Verpackung allein reicht nicht. Was ich sehe, ist ein Muster: “digital twin” kam mit einer Verpackung. Sobald Sie einen weiteren Anbieter mit einer Verpackung gesehen haben, ist es ganz einfach, diese Verpackung zu replizieren, denn die Verpackung ist buchstäblich das, was man von außen sieht. Was sich im Inneren befindet – wenn es nur ein Monte Carlo Simulator ist – können Sie einen Softwareingenieur einstellen, und dieses System wird innerhalb weniger Tage implementiert.
Alle diese Zutaten zusammen erzeugen die Versuchung, mit dem richtigen Paket auf den Markt zu gehen, Entscheider auf C-Level flächendeckend anzusprechen, und wenn du Glück hast, schließt du eine Reihe von Deals ab – und dann, bäm, hast du ein Geschäft. Ich sage nur, dass dies typischerweise die Art von Anti-Mustern ist, die ich im Bereich der Unternehmenssoftware sehe.
Conor Doherty: Danke. Und Joannes, das ist die letzte Frage – ich habe das Gefühl, die Antwort ahnen zu können, aber sie stammt von Murthy: “Wie können digitale Zwillinge sich von reaktiven Überwachungswerkzeugen zu proaktiven Entscheidungsagenten in realen Unternehmensökosystemen entwickeln?”
Joannes Vermorel: Zunächst, in dieser Definition und dem technischen Aufbau, den ich gerade vorgestellt habe, was macht den digitalen Zwilling reaktiv statt proaktiv? Konzeptionell nichts. Warum sollte man diesen Simulator – super granular, end-to-end – nicht nutzen, um proaktiv jede einzelne Richtlinie herauszufordern, die man für die supply chain einsetzen möchte? Offensichtlich ist dieses Ding dazu gedacht, proaktiv zu sein.
Also, wenn die Art und Weise, wie es in der Praxis verwendet wird, nicht proaktiv ist, müssen wir uns fragen, warum. Auf dem Papier ein Monte Carlo-Simulator: Du hast etwas, das hinreichend genau und repräsentativ für deine supply chain und deren zukünftigen Zustand ist; du kannst – weil es programmatisch ist – jede beliebige Richtlinie einspeisen. Fantastisch. Das bedeutet, dass du alles hinterfragen kannst; offensichtlich ist es dazu gedacht, proaktiv zu sein.
Aber das ist es nicht. Warum ist das so? Analysiere es aus der Software-Perspektive: Was machen sie, wie wird es implementiert? Das wird dir die Antwort liefern. Die Antwort lautet: Wir sind zurück bei einer Million SKUs, 10 CPU-Zyklen, 100 Tagen usw. Letztlich ergibt sich: Ja, dieses Ding kann dir eine Simulation dessen liefern, was passieren wird, aber sofern du nicht substanzielle ingenieurtechnische Anstrengungen unternimmst – was jene Anbieter nicht tun – erhältst du eine Antwort pro, sagen wir, 20 Minuten oder sogar pro Stunde, wenn es nicht super gut implementiert ist.
Plötzlich wird einem klar, dass ein Problem vorliegt, denn wie kann man etwas vorantreiben, wenn man solch ein Leistungsproblem hat? Ich spreche hier nicht einmal vom Problem der Modellierungsgenauigkeit – es geht um die grundlegende Performance in Bezug auf die benötigten Rechenressourcen. Das ist ein sehr reales Problem. Deshalb landen die Leute bei einem sehr reaktiven Ansatz, weil sie feststellen, dass das Ganze super langsam ist. Im Grunde genommen versucht man, Millionen von Fragen an sein System zu stellen, aber wenn du 20 Minuten auf jede einzelne Antwort warten musst, ist das unglaublich – und du musst diese eine Million Fragen jeden Tag stellen.
Man endet mit sehr grundlegenden Problemen. Wenn du die Daten neu aggregierst, kannst du plötzlich keine Fragen mehr stellen, die wirklich von Bedeutung sind, weil du dich auf einer Aggregationsebene befindest, die die Entscheidungen, die du treffen musst, nicht mehr widerspiegelt, wie zum Beispiel: “Muss ich das produzieren? Muss ich das Inventar dorthin verlagern? Sollte ich den Preis dieser Produkte erhöhen?” Plötzlich macht es auf aggregierter Ebene – etwa wenn du über die Preisgestaltung einer Produktkategorie nachdenkst – eigentlich keinen Sinn zu sagen: “Ich werde den Preis für alle Produkte in dieser Kategorie erhöhen oder senken.” Wahrscheinlich möchtest du basierend auf den Eigenschaften jedes einzelnen Produkts differenzieren. Aber wieder, das widerspricht der Idee, alles zu aggregieren.
Conor Doherty: Als kurzer Hinweis, ich weiß, dass du das Konzept der Entscheidungsoptionen, die dem Fluss physischer Güter innewohnen – deine Definition der supply chain – ausführlich behandelst. Das wird, denke ich, in Vorlesung 1.2, “Supply Chain in a Nutshell,” abgedeckt.
Das ist buchstäblich das Erste – okay. Schau dir jedenfalls die ersten beiden Vorlesungen an, denn dann kommst du zu “die Quantitative Supply Chain in a Nutshell.” Das ist ziemlich gut – besser als nur ziemlich gut. Jedenfalls, Joannes, wir waren eine Stunde unterwegs. Uns gehen die Fragen aus, und nun läuft die Zeit ab. Wie immer, vielen Dank, dass du dabei warst und für deine Antworten.
Und an alle anderen, vielen Dank für eure Teilnahme. Danke für eure Fragen. Falls noch nicht geschehen, folgt Lokad bitte auf LinkedIn. Und falls ihr noch nicht mit uns vernetzt seid, schickt uns eine Kontaktanfrage. Wir diskutieren immer gerne supply chain Probleme. Und in diesem Sinne sage ich zu euch allen: Macht euch wieder an die Arbeit.
