Terabyte-Skalierbarkeit für Supply Chains

00:00:06 Herausforderungen bei der Verarbeitung von Supply Chain-Daten und die Terabyte-Skalierbarkeit von Lokad.
00:00:38 Verbesserungen der Verarbeitungskapazität von Lokad im letzten Jahr.
00:01:33 Erklärung von Lokads Plattform und ihrer Skriptsprache Envision.
00:03:55 Vergleich von Envision mit anderen Programmiersprachen wie Python.
00:06:27 Schlüsselerkenntnisse und Durchbrüche, die zu den Verbesserungen von Lokad geführt haben.
00:08:00 Tabellarische vs. spaltenorientierte Speicherung in Datenbanken und ihre Effizienz.
00:10:36 Herausforderungen und Kosten im Zusammenhang mit der Verarbeitung großer Datenmengen.
00:12:04 Die Auswirkungen der Terabyte-Verarbeitung auf Supply Chain-Experten und die Arbeitsleistung.
00:14:10 Praktische Vorteile einer schnelleren Verarbeitung und Handhabung größerer Datensätze.
00:15:30 Bedeutung der Beseitigung von Randfällen und Gefahr langer Prozesse bei quantitativen Supply Chain-Initiativen.
00:17:43 Bedeutung eines iterativen Ansatzes zur Bewältigung realer Herausforderungen.
00:20:47 Herausforderungen und Auswirkungen der Verarbeitung großer Datenmengen auf die Optimierung der Lieferkette.
00:21:10 Auswirkungen der Terabyte-Skalierbarkeit auf Lokads Perspektive und die Zukunft der Lieferkettenoptimierung.
00:24:41 Schlussgedanken und potenzielle Möglichkeiten zur Verbesserung der Lieferkettenoptimierung.

Zusammenfassung

Kieran Chandler interviewt Joannes Vermorel, den Gründer von Lokad, über die Optimierung der Lieferkette und den Umgang mit großen Datensätzen. Lokad hat seine Verarbeitungskapazität seit 2017 um das 20-fache erhöht und nutzt dafür ihre domänenspezifische Sprache Envision für die Verarbeitung großer Datenmengen. Envision vereinfacht im Vergleich zu generischen Programmiersprachen die verteilte Datenverarbeitung im Kontext der Lieferkette. Lokads Fortschritte haben die Verarbeitungszeiten von Stunden auf Minuten reduziert, was es Supply Chain-Experten ermöglicht, effizienter zu arbeiten. Vermorel betont die Bedeutung von Agilität und iterativer Optimierung für erfolgreiche Lieferketteninitiativen. Lokads Terabyte-Skalierbarkeit ermöglicht einen ganzheitlicheren Ansatz für die Optimierung und plant, die Ausdruckskraft in Envision-Skripten zu verbessern, um reale Lieferkettenprobleme besser anzugehen.

Erweiterte Zusammenfassung

In diesem Interview diskutiert Kieran Chandler, der Moderator, mit Joannes Vermorel, dem Gründer von Lokad, einem Softwareunternehmen, das sich auf die Optimierung der Lieferkette spezialisiert hat. Sie sprechen über die Herausforderungen bei der Verarbeitung großer Datenmengen in der Lieferkettenbranche und die Entwicklungen von Lokad in Bezug auf Terabyte-Skalierbarkeit.

Joannes erwähnt, dass 2018 ein Jahr der Skalierbarkeit für Lokad war, wobei das Unternehmen seine Verarbeitungskapazität im Vergleich zum Vorjahr um den Faktor 20 erhöht hat. Diese Verbesserung hat es Lokad ermöglicht, mehrere Terabyte große Datensätze relativ problemlos zu verarbeiten, wenn man den aktuellen Stand der Technologie berücksichtigt.

Das Unternehmen hat dies durch die Entwicklung der Solocat-Plattform erreicht, die für die Optimierung der quantitativen Lieferkette konzipiert ist. Die Plattform nutzt Lokads domänenspezifische Skriptsprache namens Envision. Envision ist darauf ausgelegt, den spezifischen Anforderungen von Lieferkettenproblemen gerecht zu werden und die Verarbeitung großer Datenmengen zu erleichtern.

Vor 2018 konnte ein einzelnes Envision-Skript nur auf einer einzigen Maschine ausgeführt werden, obwohl die Plattform mehrere Terabyte an Daten speichern konnte. Das Unternehmen hatte bereits eine gewisse Skalierbarkeit durch die Verteilung von Berechnungen für maschinelles Lernen auf mehrere Maschinen implementiert. Aufgaben wie das Sortieren von Daten waren jedoch immer noch auf eine große Maschine beschränkt.

Im Jahr 2018 führte Lokad eine vollständig aktualisierte Architektur für die Backend-Ausführungslogik von Envision-Skripten ein. Die neue Architektur ermöglicht die automatische Parallelisierung über mehrere CPUs und sogar über ganze Maschinenflotten. Dadurch können Aufgaben wie das Sortieren von Daten nun viel schneller durchgeführt werden, indem die Rechenleistung von Dutzenden von Maschinen genutzt wird.

Bei einem Vergleich von Envision mit generischen Programmiersprachen wie Python, Java, C++ und C# erklärt Joannes, dass Envision eine domänenspezifische Sprache ist, die speziell für die Bewältigung von Lieferkettenproblemen entwickelt wurde. Während generische Programmiersprachen die Möglichkeit bieten, fast alles zu tun, erfordern sie oft komplexere Konfigurationen und ein tieferes Verständnis spezifischer Bibliotheken und Frameworks, um verteiltes Rechnen zu ermöglichen.

Envision hingegen vereinfacht diese technischen Aspekte und erleichtert verteiltes Rechnen und die Verarbeitung großer Datenmengen im Kontext der Lieferkettenoptimierung. Dieser spezialisierte Ansatz ermöglicht es Lokad, die Skalierbarkeit zu verbessern und Terabyte an Daten effektiver zu verarbeiten als mit generischen Programmiersprachen.

Sie diskutieren die Software des Unternehmens, Envision, ihre Vorteile und wie sich die jüngsten Fortschritte auf die Lieferkettenanalyse ausgewirkt haben.

Envision ist eine Skriptsprache, die speziell für Lieferkettenprobleme entwickelt wurde und einfacher und effizienter zu verwenden ist als andere allgemeine Programmiersprachen. Sie opfert etwas an Ausdruckskraft für Einfachheit, aber da sie sich auf einen bestimmten Problemtyp konzentriert, ist dieser Kompromiss akzeptabel. Vermorel vergleicht die Benutzerfreundlichkeit von Envision mit dem Schreiben von fortgeschrittenen Excel-Tabellen mit ausgeklügelten Durchschnitts-, Sortier- und Suchfunktionen.

Vor einem Jahr hatte Lokad bereits einen spaltenorientierten Ansatz für die Datenspeicherung bei der Analyse großer Datenmengen implementiert, der sich eher für die Stapelverarbeitung als für die Echtzeitverarbeitung eignet. Bei diesem Ansatz werden Daten spaltenweise anstatt zeilenweise gespeichert, was eine effizientere Verarbeitung von Operationen ermöglicht, die nur wenige Spalten betreffen. Der Nachteil besteht jedoch darin, dass das Hinzufügen neuer Zeilen die Arbeit mit jeder einzelnen Spalte erfordert, was für die Echtzeitverarbeitung weniger effizient ist.

Bei der Diskussion der mit der Verarbeitung großer Datenmengen verbundenen Kosten betont Vermorel, dass der teuerste Ressourcenfaktor der Lieferkettenwissenschaftler (oder Datenwissenschaftler) ist, da sie knapp sind, spezifisches Wissen erfordern und umfangreiche Schulungen benötigen. Daher zielt Lokad darauf ab, die Nutzung der Zeit dieser Wissenschaftler zu optimieren, indem sie die Zeit für die Datenverarbeitung reduziert.

Früher dauerte die Verarbeitung von Terabyte an Daten Stunden, aber durch die jüngsten Fortschritte hat sich diese Zeit auf Minuten reduziert. Dies ermöglicht es Lieferkettenwissenschaftlern, sich auf ihre Aufgaben zu konzentrieren und schneller zum nächsten Schritt überzugehen, anstatt auf Ergebnisse zu warten. Es bedeutet jedoch auch, dass sie weniger Gelegenheiten für Pausen haben.

Der Durchbruch bei der schnelleren Verarbeitung größerer Datensätze hat mehrere Vorteile in der realen Welt. Unternehmen können ihre Lieferketten effizienter und effektiver analysieren und optimieren, was letztendlich ihre gesamten Betriebsabläufe verbessert.

Sie gehen auf die Herausforderungen der Optimierung ein, die Bedeutung von Agilität und den iterativen Ansatz, der erforderlich ist, um mit realen Eventualitäten umzugehen.

Vermorel identifiziert die Hauptgefahr bei der Umsetzung einer quantitativen Lieferketteninitiative in der Zeit, die benötigt wird, um das System zu perfektionieren, da es entscheidend ist, alle Randfälle zu behandeln, um manuelle Eingriffe zu vermeiden. Je länger es dauert, desto wahrscheinlicher ist es, dass das Projekt Störungen wie IT- oder ERP-Upgrades oder dramatische Geschäftstransformationen erfährt, die vorherige Arbeit obsolet machen können.

Um erfolgreich zu sein, müssen Optimierungsinitiativen für Lieferketten schnell in die Produktion gebracht werden, was Agilität erfordert. Vermorel erklärt, dass es zwar viel klingen mag, dies in wenigen Monaten zu erreichen, aber zu lange dauern kann und das Projekt gefährdet. Er betont den iterativen Ansatz zur Optimierung, der aufgrund der unvorhersehbaren Natur von Lieferketten und realen Eventualitäten, die numerische Rezepte beeinträchtigen können, notwendig ist.

Iterative Optimierung ist entscheidend, um den endlosen Strom von Überraschungen im Lieferkettenmanagement zu bewältigen. Vermorel erklärt, dass Lieferketten komplex sind und mehrere Märkte, Länder, Lieferanten und Produktlinien umfassen. Es ist unmöglich, alle potenziellen technischen Herausforderungen im Voraus zu brainstormen und aufzulisten, daher ist Agilität entscheidend, um numerische Rezepte zu korrigieren.

Kieran fragt dann Vermorel nach der Auswirkung der Terabyte-Skalierbarkeit auf Lokad und deren zukünftige Aussichten. Vermorel erklärt, dass das Unternehmen enorme Fortschritte bei der Skalierbarkeit der Verarbeitung gemacht hat, was neue Möglichkeiten für die Optimierung der Lieferkette eröffnet. Er stellt klar, dass Skalierbarkeit nicht nur darin besteht, mit größeren Unternehmen umzugehen, sondern auch darin, eine Netzwerkoptimierung auf Ebene des gesamten Netzwerks zu erreichen.

Vermorel betont, dass eine echte Optimierung die Betrachtung des gesamten Netzwerks als eine einzige Einheit erfordert, anstatt jede Filiale oder jeden Lieferanten isoliert zu optimieren. Die Terabyte-Skalierbarkeit ermöglicht es Lokad, die Optimierung ganzheitlicher anzugehen, was wiederum hilft, Probleme nicht einfach in der Lieferkette zu verschieben.

In Zukunft plant Lokad, seine Fortschritte bei der Skalierbarkeit zu nutzen, um die Ausdruckskraft zu verbessern und so flüssigere und direktere Möglichkeiten zu schaffen, komplexe reale Situationen in ihren Envision-Skripten widerzuspiegeln. Dies wird es erleichtern, numerische Rezepte zu entwickeln, die reale Lieferketten-Situationen effektiv bewältigen.

Das Interview endet mit Vermorel, der die Bedeutung von Agilität, iterativer Optimierung und ganzheitlichen Ansätzen im Lieferkettenmanagement betont.

Vollständiges Transkript

Kieran Chandler: Heute bei Lokad TV werden wir das Ausmaß der Datenmenge verstehen, die innerhalb einer Lieferkette verwaltet wird, und auch besprechen, wie Lokad die Terabyte-Skalierbarkeit entwickelt hat, um damit umzugehen. Also, Joannes, heute werden wir ein wenig über die Forschung und Entwicklung sprechen, die bei Lokad im letzten Jahr durchgeführt wurde. Woran haben Sie 2018 gearbeitet?

Joannes Vermorel: 2018 war für uns das Jahr der Skalierbarkeit. Wir haben fast kontinuierlich ein Jahr lang daran gearbeitet, die Skalierbarkeit zu erhöhen. Im Vergleich zum gleichen Datum im letzten Januar haben wir unsere Verarbeitungskapazität um etwa den Faktor 20 erhöht, was es uns ermöglicht, relativ problemlos mehrere Terabyte große Datensätze zu verarbeiten. Es gibt keine einfache Terabyte-Verarbeitung angesichts der heutigen Technologie, aber sie kann dennoch relativ einfach gemacht werden.

Kieran Chandler: Ein Faktor von 20 klingt nach einer unglaublich großen Verbesserung. Welche Schritte mussten Sie unternehmen, um diese Verbesserung zu erreichen?

Joannes Vermorel: Lokad ist eine Plattform, die für die Optimierung von Lieferketten entwickelt wurde. Technisch gesehen ist es über Skripte zugänglich, die in unserer eigenen hausgemachten Skriptsprache namens Envision geschrieben sind. Diese Sprache ist nicht nur darauf ausgelegt, den Anforderungen der Lieferkettenoptimierung gerecht zu werden, sondern auch die Verarbeitung im großen Maßstab zu erleichtern. Bis zum letzten Jahr konnte ein einzelnes Konto eines unserer Kunden mehrere Terabyte an Daten enthalten, aber ein einzelnes Skript oder ein Stück Code wurde auf einer einzelnen Maschine ausgeführt. Wir hatten bereits Scale-Out implementiert, also die Idee, dass Sie die Berechnung auf viele Maschinen für bestimmte Komponenten wie maschinelles Lernen verteilen können. Aber im Allgemeinen, wenn Sie nur die Daten sortieren, geschah dies auf einer großen Maschine. Im Jahr 2018 haben wir eine komplett aktualisierte Architektur für die Backend-Ausführungslogik für Envision-Skripte eingeführt. Heutzutage gibt es automatische Parallelisierung nicht nur über mehrere Prozessoren und CPUs, sondern auch über eine Flotte von Maschinen. Das bedeutet, dass ein einzelnes Skript, das eine einfache Operation durchführt, wie zum Beispiel das Sortieren der Daten nach Datum, Produkt, Geschäft oder Preis, auf einer Flotte von Dutzenden von Maschinen stattfinden kann, was es viel schneller macht.

Kieran Chandler: Sprechen wir ein wenig über Envision. Wie trägt Envision dazu bei, diese Verbesserungen und die Skalierbarkeit im Vergleich zur Arbeit mit anderen Programmiersprachen wie Python oder ähnlichem zu verbessern?

Joannes Vermorel: Envision ist eine domänenspezifische Programmiersprache, während Python, Java, C++ und C# generische Programmiersprachen sind. Mit einer generischen Programmiersprache haben Sie die Möglichkeit, so ziemlich alles zu tun, aber der Preis, den Sie zahlen müssen, ist, dass bestimmte technische Details in der Programmierumgebung auftauchen. Sie können zum Beispiel mit Python verteiltes Rechnen durchführen, aber Sie müssen Ihren Code so schreiben, dass er von bestimmten Bibliotheken und Frameworks profitiert, um diese Berechnungen auf einer Flotte von Maschinen durchzuführen. Außerdem müssen Sie einen Cluster von Maschinen konfigurieren, damit er diese verteilte Logik ausführen kann. Wenn Sie mehrere gleichzeitige Programme haben, die über denselben Cluster ausgeführt werden, weil Sie verschiedene Skripte oder verschiedene Benutzer haben, wird es komplexer. Unterschiedliche Bedürfnisse… Nun, wir müssen alle erforderlichen Vorkehrungen treffen, um die Ressourcen, wie Bandbreite, Festplatten, CPUs und so weiter, gemeinsam zu nutzen. Und genau das macht Envision auf eine für Sie vollständig integrierte Weise. Was Sie verlieren, ist, dass Sie viel Ausdruckskraft verlieren, was in Ordnung ist, weil Envision trotz des Verlusts einer großen Ausdruckskraft überleben kann. Wir sind auf ein bestimmtes Problem spezialisiert, nämlich Lieferkettenprobleme. Wir versuchen nicht, jedes einzelne Problem zu lösen. Wir versuchen nicht, eine Engine zum Schachspielen oder zur 3D-Modellierung zu schreiben. Es ist sehr auf bestimmte Arten von Problemen ausgerichtet.

Kieran Chandler: Okay, also Sie sagen, dass es viel einfacher ist, Envision zu verwenden als eine andere Art von Programmiersprache?

Joannes Vermorel: Genau. Ich meine, das Schreiben eines Skripts, das Tabellen mit mehreren Milliarden Zeilen verarbeitet, um die Art von Analysen durchzuführen, die man in einem Lieferkettenkontext erwarten würde, wie zum Beispiel die Schätzung der Kosten und Auswirkungen von Fehlbeständen in einem großen Netzwerk für die letzten drei Jahre, ist etwas, das Sie mit nur wörtlich einem Dutzend Codezeilen tun könnten. Aber Code, der einfach zu schreiben ist. Wenn ich sage, dass es einfach zu schreiben ist, meine ich, dass es nie so einfach ist, Code zu schreiben, aber es ist nicht schwieriger als zum Beispiel das Schreiben einer fortgeschrittenen Excel-Tabelle, die ausgefallene Durchschnittswerte, ausgefallene Sortierungen und ausgefallene Suchvorgänge über die Daten durchführt.

Kieran Chandler: Okay, und welche waren einige der wichtigsten Erkenntnisse und Durchbrüche, die zu diesen Verbesserungen geführt haben?

Joannes Vermorel: Um zu verstehen, wo wir angefangen haben, hatte Lokad vor einem Jahr bereits viele Big-Data-Komponenten implementiert. Eine davon ist der spaltenorientierte Ansatz zur Datenspeicherung. Kurz gesagt verwenden herkömmliche SQL-Datenbanken eine tabellarische Speicherung. Das bedeutet, dass Sie, wenn Sie eine Tabelle haben, Zeilen von Daten speichern, und wenn Sie eine Zeile haben, sitzt sie zusammen und das ist Ihre Einheit. Das macht tabellarische Datenbanken effizient bei der Durchführung kleiner Updates oder Lese-/Schreibvorgänge zeilenweise.

Im Gegensatz dazu wurde in den letzten Jahrzehnten für die Analyse großer Datenmengen ein spaltenorientierter Ansatz entwickelt. Wenn Sie also eine Tabelle haben, sagen wir, Sie haben eine Tabelle mit 20 Spalten, dann werden die Daten spaltenweise gespeichert. Was bedeutet das? Das bedeutet, dass wenn Sie eine Operation durchführen, wie zum Beispiel “Ich habe den Stückpreis und ich habe die Menge. Angenommen, Sie haben eine Tabelle, die den Verkaufsverlauf darstellt. Jetzt möchten Sie den Gesamtumsatz wissen, was müssen Sie tun? Sie müssen den Preis mit der Menge multiplizieren und die Summe über die gesamte Tabelle bilden.” Nun, es stellt sich heraus, dass Ihre Tabelle 20 Spalten haben kann, aber die beschriebene Operation betrifft nur zwei Spalten. Wenn Sie eine spaltenorientierte Speicherung haben, ist der Hauptvorteil, dass jede Operation, die nur wenige Spalten betrifft, diese wenigen Spalten verarbeitet werden und der Rest einfach ignoriert werden kann. Wenn Sie ein tabellarisches Format haben, sind die anderen Spalten immer noch vollständig in der Mitte und können nicht übersprungen werden.

Der Nachteil könnte jedoch sein, dass wenn Sie zusätzliche Zeilen hinzufügen, wenn Sie in Echtzeit arbeiten, wenn Sie einen spaltenorientierten Ansatz haben, wenn Sie eine Zeile hinzufügen, müssen Sie mit jeder einzelnen Spalte arbeiten.

Kieran Chandler: Wenn Sie also eine Zeile hinzufügen, müssen Sie 20 Spalten berühren, was relativ ineffizient ist. Die spaltenorientierte Speicherung eignet sich eher für die Stapelverarbeitung von Analysen, nicht unbedingt in Echtzeit, sondern eher für die Art von Analysen, die für die Lieferkette interessant sind. Sie kann alle paar Minuten aktualisiert werden, aber nicht alle Millisekunden. Sprechen wir ein wenig über die Kosten, die mit der Verarbeitungsleistung und der Arbeit mit großen Datenmengen verbunden sind. Wie hat sich die Implementierung der Terabyte-Skalierbarkeit auf die Kosten der Arbeit mit Daten ausgewirkt?

Joannes Vermorel: Tatsächlich ziemlich viel. Die teuersten Ressourcen, wenn Sie eine Lieferkette im großen Maßstab optimieren möchten, sind die Lieferkettenwissenschaftler. Diese Leute sind nicht kostenlos, und es ist eine Herausforderung, Personen mit dem richtigen Talent zu finden und auszubilden. Die knappe Ressource sind nicht CPUs, Festplatten oder Bandbreite, die kostengünstig von Ihrer bevorzugten Cloud-Computing-Plattform bereitgestellt werden können, sondern die talentierten Menschen, die an dem Problem arbeiten müssen.

Wenn Sie in den Bereich der Terabyte-Verarbeitung eintreten, ist alles langsam. Das Verarbeiten eines Terabyte an Daten kann ziemlich lange dauern, insbesondere wenn Sie nicht triviale Berechnungen mit Wahrscheinlichkeitsberechnungen mit Zufallsvariablen durchführen. Dies könnte Stunden dauern, aber jetzt dauert es Minuten. Für Lieferkettenwissenschaftler bedeutet dies, dass sie sich auf die Aufgabe konzentrieren können, die Ergebnisse erhalten und zum nächsten übergehen können, anstatt auf die Ergebnisse warten zu müssen. Also, wenn überhaupt, ist es eine schlechte Nachricht für unsere Lieferkettenwissenschaftler, weil sie weniger Kaffeepausen haben.

Kieran Chandler: Was bedeutet dieser Durchbruch für die reale Welt? Offensichtlich können wir mit viel größeren Datensätzen arbeiten und viel schneller mit ihnen arbeiten, aber gibt es noch andere Vorteile, die wir sehen?

Joannes Vermorel: Ja, eine der Hauptgefahren oder Hauptursachen für das Scheitern quantitativer Lieferketteninitiativen ist die Zeit, die benötigt wird, um es richtig zu machen, um es zum Laufen zu bringen und vollständig zu polieren, damit keine Randfälle zurückbleiben. Mit der Möglichkeit, größere Datensätze schneller zu verarbeiten, können wir diese Probleme jetzt effizienter angehen, was letztendlich zu besseren Entscheidungen in der Lieferkette führt.

Kieran Chandler: Ihre Systeme sind gut, aber es gibt immer noch eine Person, die rein manuell arbeitet. Dies erfordert viel Arbeitskraft, um alle Randfälle manuell zu überprüfen, die nicht ordnungsgemäß behandelt werden. Dies untergräbt irgendwie den Zweck der fortschrittlichen maschinellen Lernautomatisierung zur Optimierung. Die Gefahr besteht darin, dass der Prozess zur Beseitigung aller Randfälle, um das numerische Entscheidungsrezept wirklich zu schärfen, zu lange dauern kann.

Joannes Vermorel: Ja, und diese Verzögerung ist tödlich, denn irgendwann verliert man den Glauben an den Erfolg der Initiative. Wenn man langsam ist, besteht die Gefahr, dass die IT in der Mitte gestört wird. Wenn zum Beispiel Ihr Projekt zwei Jahre dauert, besteht eine Chance von einem Drittel, dass es in der Mitte ein ERP-Upgrade geben wird. Sie beginnen mit der Optimierung der Lieferkette und dann gibt es eine massive Veränderung in der Unternehmensidee. Vieles von dem, was Sie getan haben, fällt auseinander, nur weil alle Systeme geändert werden.

Je länger Sie warten, desto mehr Dinge können Ihr Projekt stören. Das Unternehmen selbst kann eine dramatische Transformation durchlaufen, die Ihre frühere Arbeit angesichts der neuen Geschäftsänderungen überflüssig macht. Es gibt viele treibende Kräfte, die Druck ausüben, um das Produkt schnell in die Produktion zu bringen. Wenn Sie es nicht innerhalb weniger Monate schaffen, besteht die Chance, dass Ihre Initiative scheitert. Hier ist Agilität absolut erforderlich.

Es mag sich nach viel anhören, ein paar Monate, aber wenn Sie Terabyte an Daten berühren und es Stunden dauert, ein Ergebnis zu erhalten, optimieren Sie im schlimmsten Fall Ihre numerischen Rezepte einmal oder zweimal am Tag. Die Dinge fangen an, sehr langsam zu werden.

Kieran Chandler: Also, worauf Sie da eingehen, ist eine Art iterativer Ansatz zur Optimierung der Lieferkette. Warum gibt es einen solchen iterativen Ansatz? Warum können Sie nicht einfach eine Taste drücken, Deep Learning verwenden, um zu lernen und eine gute Prognose und gute Ergebnisse zu erhalten?

Joannes Vermorel: Die Realität hat eine Art, Ihnen im Weg zu stehen. Die Lieferkette hat wirklich mit realen Eventualitäten zu tun. Es gibt so viele Randfälle, die einfach aus dem Gewebe der Realität entstehen. Zum Beispiel berechnen Sie eine ideale Bestellmenge, sagen wir 80 Einheiten. Es ist die beste Menge, die bestellt werden kann, aber Paletten kommen nur in Null-Einheiten oder 100 Einheiten, weil sie über einer Palette verpackt sind. 80 ist keine Option, also was tun Sie?

Es gibt Dutzende von Situationen wie dieser. Sie könnten denken, dass der Wert Ihres Lagerbestands im Laufe der Zeit allmählich abnimmt, aber das ist nicht der Fall. Warum? Weil es ein Haltbarkeitsdatum mit einem bestimmten Datum gibt. Wenn Sie das Haltbarkeitslimit erreichen, sinkt der Lagerwert von etwas auf null oder sogar negativ, weil Sie jetzt dafür bezahlen müssen, diesen wertlosen Bestand zu entsorgen.

Die Realität ist, dass Lieferketten komplex sind. Wenn wir über Unternehmen sprechen, die in vielen Märkten, mehreren Ländern, mit vielen Lieferanten und potenziell Dutzenden von Produktlinien tätig sind, gibt es viele Komplikationen. Es ist Wunschdenken zu glauben, dass Sie sich einfach hinsetzen und mit dem Team alle technischen Herausforderungen brainstormen können, die sich im Laufe der Initiativen ergeben werden. Sie können nicht einfach sagen… Setzen Sie sich mit Ihrem Lieferkettenteam hin und sagen Sie, lassen Sie uns alle kleinen Dinge auflisten, die das numerische Rezept, das die optimierten Entscheidungen der Lieferkette generiert, aus der Bahn werfen werden. Die Realität hat, wie immer, eine Möglichkeit, Sie zu überraschen, denn Sie werden bizarre Dinge entdecken, wie zum Beispiel ein bestimmtes Land, das eine seltsame Steuer auf etwas hat. Wenn wir zu Ihrer ursprünglichen Frage zum iterativen Ansatz zurückkehren, ist der einzige Weg, mit diesem endlosen Strom von Überraschungen umzugehen, äußerst agil zu sein und Ihr numerisches Rezept anzupassen, wenn Sie auf etwas Unerwartetes stoßen.

Kieran Chandler: Nun konzentrieren wir uns auf die Skalierbarkeit im Terabyte-Bereich und bringen alles zusammen. Wie verändert dies die Perspektive von Lokad und was bedeutet es für die Zukunft?

Joannes Vermorel: Wir haben enorme Verbesserungen in Bezug auf die Skalierbarkeit der Verarbeitung vorgenommen. Diese Entwicklung eröffnet uns viele Möglichkeiten, die uns zuvor nicht zugänglich waren. Es geht nicht nur darum, mit größeren Unternehmen umzugehen, es gibt viele Möglichkeiten zu betrügen, zum Beispiel. Betrachten Sie ein großes Einzelhandelsnetzwerk. Wenn Ihr Ansatz zur Optimierung eines groß angelegten Einzelhandelsnetzwerks darin besteht, jeden Markt isoliert zu verarbeiten und wenn Sie zum Beispiel 200 Märkte haben, bräuchten Sie nur 200 Maschinen, eine pro Markt, und es würde skalieren. Aber diese Methode wird nicht die Lieferkettenverbesserung liefern, die Sie suchen, weil Sie nicht auf Netzwerkebene optimieren. Sie optimieren lokal jeden Laden isoliert und ignorieren vollständig, was im Rest des Netzwerks passiert.

Kieran Chandler: Würden diese 200 Maschinen dann nicht miteinander kommunizieren?

Joannes Vermorel: Genau. Wenn Sie unabhängige Silos haben, ist es sehr einfach, Ihre Verarbeitung zu skalieren. Aber die Herausforderung besteht darin, wenn Sie Ihr Netzwerk als eine Einheit betrachten, in der alles miteinander verbunden ist. Sie können tatsächlich Inventar und Materialien auf beliebige Weise im Netzwerk versenden. Obwohl es viele Möglichkeiten gibt, die nicht rentabel sind und keinen Sinn ergeben, ist es möglich. Und einige dieser subtilen Wege könnten sehr gute und profitable Ideen sein. Sie benötigen ein System, das alles auf einmal, auf monolithische Weise, verarbeiten kann. Was bedeutet das für die Zukunft? Es bedeutet, dass es viele Möglichkeiten für eine bessere, ganzheitliche Optimierung eröffnet. Der Fluch der Lieferkettenoptimierung besteht darin, dass Sie die Probleme nicht lösen; Sie verschieben sie nur. Sie können sich einen Bereich ansehen und ihn optimieren, aber alles, was Sie tun, ist, das Problem weiterzugeben oder zurück zum Lieferanten zu geben. Ein weiterer Ansatz ist, dass wir jetzt, da wir signifikant an Skalierbarkeit gewonnen haben, wahrscheinlich versuchen werden, zur Ausdruckskraft zurückzukehren. Im Grunde genommen versuchen wir, komplexe Situationen, die in der realen Welt auftreten, direkter und fließender in diesen Envision-Skripten auszudrücken. Auf diese Weise ist es einfacher, numerische Rezepte zu liefern, die gut geeignet sind, reale Situationen anzugehen.

Kieran Chandler: Das klingt großartig. Wir müssen hier abschließen, aber vielen Dank für Ihre Zeit heute. Das ist alles für diese Woche. Vielen Dank fürs Zuschauen und bis zum nächsten Mal. Tschüss für jetzt.