00:00:06 Herausforderungen der Datenverarbeitung in supply chains und Lokads Terabyte Skalierbarkeit.
00:00:38 Verbesserungen in Lokads Verarbeitungskapazität im vergangenen Jahr.
00:01:33 Erklärung der Lokad-Plattform und ihrer Skriptsprache Envision.
00:03:55 Vergleich von Envision mit anderen Programmiersprachen wie Python.
00:06:27 Wesentliche Erkenntnisse und Durchbrüche, die zu Lokads Verbesserungen geführt haben.
00:08:00 Tabellarische vs. spaltenbasierte Speicherung in Datenbanken und deren Effizienzen.
00:10:36 Herausforderungen und Kosten, die mit der Verarbeitung großer Datenmengen verbunden sind.
00:12:04 Die Auswirkungen der Terabyte-Verarbeitung auf Supply Chain Scientists und die Arbeitseffizienz.
00:14:10 Praktische Vorteile einer schnelleren Verarbeitung und dem Umgang mit größeren Datensätzen.
00:15:30 Bedeutung, Randfälle auszuschließen, und die Gefahr langer Prozesse in Initiativen der die Quantitative Supply Chain.
00:17:43 Bedeutung eines iterativen Ansatzes zur Bewältigung realer Eventualitäten.
00:20:47 Herausforderungen und Implikationen der großflächigen Datenverarbeitung in der supply chain Optimierung.
00:21:10 Die Auswirkungen der Terabyte-Skalierbarkeit auf Lokads Perspektive und die Zukunft der supply chain Optimierung.
00:24:41 Abschließende Gedanken und potenzielle Ansätze zur Verbesserung der supply chain Optimierung.
Zusammenfassung
Kieran Chandler interviewt Joannes Vermorel, Gründer von Lokad, über supply chain Optimierung und den Umgang mit riesigen Datensätzen. Lokad hat seine Verarbeitungskapazität seit 2017 um das 20-fache gesteigert, indem die domänenspezifische Sprache Envision für großflächige Datenverarbeitung eingesetzt wurde. Envision vereinfacht verteiltes Rechnen im Kontext von supply chains im Vergleich zu generischen Programmiersprachen. Lokads Fortschritte haben die Datenverarbeitungszeiten von Stunden auf Minuten reduziert, wodurch Supply Chain Scientists effizienter arbeiten können. Vermorel betont die Bedeutung von Agilität und iterativer Optimierung für erfolgreiche supply chain Initiativen. Lokads Terabyte-Skalierbarkeit ermöglicht einen ganzheitlicheren Ansatz zur Optimierung und plant, die Ausdrucksfähigkeit in Envision-Skripten zu verbessern, um reale supply chain Situationen besser abzubilden.
Erweiterte Zusammenfassung
In diesem Interview bespricht Kieran Chandler, der Moderator, mit Joannes Vermorel, dem Gründer von Lokad, einem Softwareunternehmen, das sich auf supply chain Optimierung spezialisiert hat, die Herausforderungen beim Umgang mit gewaltigen Datenmengen in der supply chain Branche und Lokads Entwicklungen in der Terabyte-Skalierbarkeit.
Joannes erwähnt, dass 2018 ein Jahr der Skalierbarkeit für Lokad war, da das Unternehmen seine Verarbeitungskapazität im Vergleich zum Vorjahr um den Faktor 20 gesteigert hat. Diese Verbesserung hat es Lokad ermöglicht, Multi-Terabyte-Datensätze relativ mühelos zu verarbeiten, angesichts des aktuellen Stands der Technik.
Das Unternehmen hat dies durch die Entwicklung der Solocat-Plattform erreicht, die für die die Quantitative Supply Chain Optimierung konzipiert wurde. Die Plattform nutzt Lokads domänenspezifische Skriptsprache namens Envision. Envision ist darauf ausgelegt, die spezifischen Anforderungen von supply chain Problemen zu adressieren und großflächige Datenverarbeitung zu ermöglichen.
Vor 2018 konnte ein einzelnes Envision-Skript nur auf einer einzigen Maschine ausgeführt werden, obwohl die Plattform mehrere Terabytes an Daten speichern konnte. Das Unternehmen hatte ein gewisses Maß an Skalierbarkeit erreicht, indem es machine learning Berechnungen über mehrere Maschinen verteilt hat. Allerdings waren Aufgaben wie das Sortieren von Daten weiterhin auf eine einzige leistungsstarke 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 eine automatische Parallelisierung über mehrere CPUs und sogar ganze Maschinenfarmen. Dadurch können Aufgaben wie das Sortieren von Daten nun deutlich schneller erledigt werden, indem die Rechenleistung von Dutzenden von Maschinen genutzt wird.
Beim Vergleich von Envision mit generischen Programmiersprachen wie Python, Java, C++ und C# erklärt Joannes, dass Envision eine domänenspezifische Sprache ist, die auf die Bewältigung von supply chain Problemen zugeschnitten ist. Während generische Programmiersprachen die Möglichkeit bieten, nahezu 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 Details, wodurch es leichter wird, verteiltes Rechnen zu handhaben und großflächige Daten im Kontext der supply chain Optimierung zu verarbeiten. Dieser spezialisierte Ansatz ermöglicht es Lokad, die Skalierbarkeit zu verbessern und Terabytes an Daten effektiver zu verarbeiten als mit generischen Programmiersprachen.
Sie diskutieren die Software des Unternehmens, Envision, ihre Vorteile und wie aktuelle Fortschritte die supply chain Analytik verbessert haben.
Envision ist eine Skriptsprache, die speziell für supply chain Probleme entwickelt wurde, was sie einfacher und effizienter in der Anwendung macht als andere universelle Programmiersprachen. Sie opfert etwas Ausdruckskraft zugunsten der Simplizität, doch da sie sich auf eine bestimmte Art von Problem konzentriert, ist dieser Kompromiss akzeptabel. Vermorel vergleicht die Benutzerfreundlichkeit von Envision mit dem Erstellen fortgeschrittener Excel-Tabellen mit ausgefeilten Durchschnittsberechnungen, Sortierungen und Suchen.
Vor einem Jahr hatte Lokad bereits einen spaltenbasierten Ansatz zur Datenspeicherung für Big-Data-Analysen implementiert, der eher für Batch-Analysen als für Echtzeitverarbeitung geeignet ist. Dieser Ansatz speichert Daten spaltenweise statt zeilenweise, was eine effizientere Verarbeitung von Operationen ermöglicht, die nur wenige Spalten betreffen. Der Nachteil dabei ist jedoch, dass das Hinzufügen neuer Zeilen bedeutet, mit jeder einzelnen Spalte arbeiten zu müssen, was die Echtzeitverarbeitung weniger effizient macht.
Beim Gespräch über die Kosten, die mit der Verarbeitung großer Datenmengen verbunden sind, betont Vermorel, dass die teuerste Ressource der Supply Chain Scientist (oder Data Scientist) ist, da sie knapp sind, spezielles Wissen erfordern und umfangreich geschult werden müssen. Daher zielt Lokad darauf ab, die Zeit dieser Wissenschaftler zu optimieren, indem die für die Datenverarbeitung aufgewendete Zeit reduziert wird.
Früher dauerte die Verarbeitung von Terabytes an Daten Stunden, aber aktuelle Fortschritte haben diese Zeit auf Minuten reduziert. Dies ermöglicht es Supply Chain Scientists, sich auf ihre Aufgaben zu konzentrieren und schneller zum nächsten Schritt überzugehen, anstatt auf Ergebnisse zu warten. Allerdings bedeutet dies auch, dass sie weniger Pausen haben.
Der Durchbruch, größere Datensätze schneller zu verarbeiten, hat mehrere praxisnahe Vorteile. Er ermöglicht es Unternehmen, ihre supply chains effizienter und effektiver zu analysieren und zu optimieren, was letztlich ihre gesamten Abläufe verbessert.
Sie sprechen die Herausforderungen der Optimierung, die Bedeutung von Agilität und den notwendigen iterativen Ansatz zur Bewältigung realer Eventualitäten an.
Vermorel sieht die Hauptgefahr bei der Umsetzung einer Initiative der die Quantitative Supply Chain darin, wie lange es dauert, das System zu perfektionieren, da es entscheidend ist, alle Randfälle zu berücksichtigen, um manuelle Eingriffe zu vermeiden. Je länger es dauert, desto wahrscheinlicher ist es, dass das Projekt mit Störungen konfrontiert wird, wie IT- oder ERP Upgrades oder dramatischen geschäftlichen Transformationen, die frühere Arbeiten obsolet machen können.
Um erfolgreich zu sein, müssen supply chain Optimierungsinitiativen schnell in Produktion gehen, was Agilität erfordert. Vermorel erklärt, dass, obwohl es vielleicht wie viel erscheinen mag, in wenigen Monaten viel zu erreichen, ein zu langwieriger Prozess das Scheitern des Projekts riskiert. Er betont den iterativen Ansatz zur Optimierung, der notwendig ist, aufgrund der unvorhersehbaren Natur von supply chains und realen Eventualitäten, die numerical recipes aus der Bahn werfen können.
Iterative Optimierung ist unerlässlich, um den endlosen Strom von Überraschungen zu bewältigen, die mit dem Management von supply chains einhergehen. Vermorel erklärt, dass supply chains komplex sind, mit mehreren Märkten, Ländern, Lieferanten und Produktlinien. Es ist unmöglich, im Voraus alle potenziellen technischen Herausforderungen zu erörtern und aufzulisten, weshalb Agilität entscheidend ist, wenn numerical recipes angepasst werden müssen.
Kieran fragt Vermorel daraufhin nach den Auswirkungen der Terabyte-Skalierbarkeit auf Lokad und dessen zukünftigen Ausblick. Vermorel erklärt, dass das Unternehmen enorme Fortschritte in der Skalierbarkeitsverarbeitung gemacht hat, die neue Möglichkeiten für supply chain Optimierung eröffnen. Er stellt klar, dass Skalierbarkeit nicht nur darin besteht, mit größeren Unternehmen umzugehen, sondern auch eine netzwerkweite Optimierung zu erreichen.
Vermorel hebt hervor, dass echte Optimierung erfordert, das gesamte Netzwerk als eine Einheit zu betrachten, anstatt jeden Laden oder Lieferanten isoliert zu optimieren. Die Terabyte-Skalierbarkeit ermöglicht es Lokad, die Optimierung ganzheitlicher anzugehen, was wiederum hilft, Probleme innerhalb der supply chain zu vermeiden.
Für die Zukunft plant Lokad, seine Fortschritte in der Skalierbarkeit zu nutzen, um die Ausdrucksfähigkeit zu verbessern, sodass komplexe reale Situationen in ihren Envision-Skripten flüssiger und direkter abgebildet werden können. Dies wird die Entwicklung von numerical recipes erleichtern, die reale supply chain Situationen effektiv adressieren.
Das Interview schließt mit der Betonung von Vermorel ab, die Bedeutung von Agilität, iterativer Optimierung und ganzheitlichen Ansätzen im supply chain Management hervorzuheben.
Vollständiges Transkript
Kieran Chandler: Heute bei Lokad TV werden wir das enorme Volumen an Daten verstehen, das in einer supply chain verwaltet wird, und außerdem erörtern, wie Lokad Terabyte-Skalierbarkeit entwickelt hat, um damit umzugehen. Also, Joannes, heute sprechen wir ein wenig über die Forschung und Entwicklung bei Lokad im vergangenen Jahr. Woran hast du 2018 gearbeitet?
Joannes Vermorel: 2018 war für uns das Jahr der Skalierbarkeit. Wir haben fast ununterbrochen daran gearbeitet, die Skalierbarkeit zu erhöhen. Im Vergleich zum gleichen Datum des letzten Januars haben wir unsere Verarbeitungskapazität im Wesentlichen um den Faktor 20 gesteigert, was uns in die Lage versetzt, Multi-Terabyte-Datensätze relativ mühelos zu verarbeiten. Angesichts des heutigen Technologiestandes gibt es kein einfaches Terabyte-Processing, aber es kann dennoch relativ unkompliziert gestaltet 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 supply chain Optimierung entwickelt wurde. Technisch ist sie über Skripte zugänglich, die in unserer eigens entwickelten Skriptsprache namens Envision geschrieben sind. Diese Sprache ist nicht nur darauf ausgelegt, die spezifischen Anforderungen der supply chain Optimierung zu adressieren, sondern auch großflächige Verarbeitung zu ermöglichen. Bis letztes Jahr konnte ein einzelnes Konto eines unserer Kunden mehrere Terabytes an Daten enthalten, aber ein einzelnes Skript oder Code-Stück würde auf einer einzigen Maschine ausgeführt werden. Wir hatten bereits Scale-out implementiert, sodass man bestimmte Berechnungen, wie zum Beispiel machine learning, über viele Maschinen verteilen konnte. Allerdings geschah das Sortieren der Daten im Großen und Ganzen immer noch auf einer einzigen leistungsstarken Maschine. Im Jahr 2018 haben wir eine vollständig aktualisierte Architektur für die Backend-Ausführungslogik von Envision-Skripten eingeführt. Heutzutage erfolgt die automatische Parallelisierung nicht nur über mehrere Prozessoren und CPUs, sondern auch über eine Maschinenflotte. Das bedeutet, dass ein einzelnes Skript, das eine einfache Operation durchführt, wie das Sortieren der Daten nach Datum, Produkt, Geschäft oder Preis, über eine Flotte von Dutzenden von Maschinen viel schneller ablaufen kann.
Kieran Chandler: Sprechen wir ein wenig über Envision. Wie trägt Envision dazu bei, diese Verbesserungen zu ermöglichen und die Skalierbarkeit zu steigern, im Vergleich zur Arbeit mit anderen Programmiersprachen wie Python oder Ähnlichem?
Joannes Vermorel: Envision ist eine domänenspezifische Programmiersprache, während Python, Java, C++ und C# generische Programmiersprachen sind. Mit einer generischen Programmiersprache hat man die Möglichkeit, so ziemlich alles zu machen, aber der Preis dafür ist, dass zahlreiche technische Details in die Programmierumgebung einfließen. Zum Beispiel kann man mit Python verteiltes Rechnen durchführen, aber man muss den Code so schreiben, dass spezifische Bibliotheken und Frameworks genutzt werden, um diese Berechnungen über eine Maschinenflotte auszuführen. Außerdem muss man selbst einen Cluster von Maschinen konfigurieren, damit die verteilte Logik umgesetzt werden kann. Wenn mehrere gleichzeitige Programme, sei es wegen verschiedener Skripte oder Benutzer, denselben Cluster nutzen, wird es komplexer. Unterschiedliche Anforderungen… Nun, wir müssen alle nötigen Verbindungen bereitstellen, um die Ressourcen wie Bandbreite, Festplatten, CPUs und dergleichen zu teilen. Und genau das macht Envision auf eine völlig integrierte Weise für Sie. Was man dabei jedoch einbüßt, ist ein Großteil der Ausdruckskraft, was in Ordnung ist, denn Envision kann trotzdem überleben. Es ist nicht fehlerhaft, obwohl es einiges an Ausdruckskraft eingebüßt hat, weil wir uns auf eine bestimmte Art von Problem spezialisieren, nämlich supply chain Probleme. Wir versuchen also nicht, jedes einzelne Problem zu lösen. Wir versuchen nicht, eine Engine zu schreiben, um Schach zu spielen oder 3D-Modellierung zu betreiben. Es ist sehr auf spezifische Problemstellungen ausgerichtet.
Kieran Chandler: Also sagen Sie, dass es viel einfacher ist, Envision zu verwenden, als eine andere Art von Programmiersprache?
Joannes Vermorel: Genau. Ich meine, ein Skript zu schreiben, das Tabellen mit mehreren Milliarden Zeilen verarbeitet, um die Art von Analysen durchzuführen, die man im Kontext einer supply chain erwarten würde, wie zum Beispiel die Abschätzung der Kosten und Auswirkungen von stockouts in einem großen Netzwerk in den letzten drei Jahren, das kann man buchstäblich mit nur einem Dutzend Codezeilen machen. Aber Code, der einfach zu schreiben ist. Wenn ich sage, einfach zu schreiben, meine ich, dass es nie wirklich einfach ist, Code zu schreiben, aber es ist nicht schwieriger als zum Beispiel das Erstellen einer fortgeschrittenen Excel-Tabelle, die ausgefallene Durchschnitte, Sortierungen und Suchen über die Daten durchführt.
Kieran Chandler: Okay, und was waren einige der zentralen Erkenntnisse und Durchbrüche, die zu diesen Verbesserungen geführt haben?
Joannes Vermorel: Nur um zu verstehen, wo wir angefangen haben: Vor einem Jahr hatte Lokad bereits viele Big-Data-Zutaten parat. Eine davon ist ein spaltenorientierter Ansatz zur Datenspeicherung. Also, um es kurz zu machen, traditionelle SQL-Datenbanken verwenden eine tabellarische Speicherung. Das bedeutet, dass wenn du eine Tabelle hast, du Zeilen von Daten speicherst, und wenn du eine Zeile hast, sitzt sie zusammen – und das ist deine Einheit. Im Grunde macht das tabellarische Datenbanken sehr effizient beim Durchführen kleiner Updates oder beim zeilenweisen Lese-/Schreibzugriff.
Im Gegensatz dazu wurde im Laufe der letzten Jahrzehnte, wann immer du eine großangelegte data analysis durchführen wolltest, ein spaltenorientierter Ansatz entwickelt. Grundsätzlich, wenn du eine Tabelle hast – sagen wir, du hast eine Tabelle mit 20 Spalten – wirst du die Daten spaltenweise speichern. Was bedeutet das? Es bedeutet, dass wenn du eine Operation durchführst, wie zum Beispiel: “Ich habe den Stückpreis, und ich habe die Menge. Angenommen, du hast eine Tabelle, die die sales history repräsentiert. Jetzt möchtest du den Gesamtumsatz wissen – was musst du tun? Du musst den Preis mit der Menge multiplizieren und die Summe davon über die ganze Tabelle bilden.” Nun, es stellt sich heraus, dass deine Tabelle vielleicht 20 Spalten hat, aber die Operation, die ich gerade beschrieben habe, berührt nur zwei Spalten. Bei einer spaltenorientierten Speicherung ist der Hauptvorteil, dass jede Operation, die nur wenige Spalten berührt, diese wenigen Spalten verarbeitet und der Rest einfach ignoriert werden kann. Bei einem tabellarischen Format hingegen sind die anderen Spalten immer komplett involviert, und du kannst sie nicht wirklich überspringen.
Aber der Nachteil könnte sein, dass wenn du zusätzliche Zeilen hinzufügst, also in Echtzeit arbeitest, du bei einem spaltenorientierten Ansatz, wenn du eine Zeile hinzufügst, mit jeder einzelnen Spalte arbeiten musst.
Kieran Chandler: Also, wenn du eine Zeile hinzufügst, musst du 20 Spalten berühren, was es relativ ineffizient macht. Spaltenorientierte Speicherung eignet sich eher für Batch-Analysen, also nicht genau in Echtzeit, sondern für die Art von Analysen, an denen du für supply chain interessiert bist. Es kann jede Minute aktualisiert werden, aber nicht jede Millisekunde. Lass uns ein wenig über die mit Rechenleistung verbundenen Kosten und die Verarbeitung großer Datenmengen sprechen. Wie hat sich die Implementierung der Terabyte-Skalierbarkeit auf die Kosten der Datenverarbeitung ausgewirkt?
Joannes Vermorel: Tatsächlich, ziemlich viel. Die teuersten Ressourcen, wenn du versuchst, eine groß angelegte supply chain zu optimieren, sind die Supply Chain Scientists. Diese Personen sind nicht umsonst, und es ist eine Herausforderung, Personen mit dem richtigen Talent zu finden und auszubilden. Die knappe Ressource sind nicht CPUs, Festplatten oder Bandbreite, die von deiner bevorzugten Cloud-Computing-Plattform günstig bereitgestellt werden können, sondern vielmehr die talentierten Leute, die an dem Problem arbeiten müssen.
Wenn du in den Bereich der Terabyte-Verarbeitung eintauchst, ist alles langsam. Das Verarbeiten eines Terabytes an Daten kann ziemlich lange dauern, besonders wenn du nicht-triviale Berechnungen durchführst, die probabilistische Kalkulationen mit Zufallsvariablen beinhalten. Das könnte Stunden dauern, aber jetzt dauert es Minuten. Für Supply Chain Scientists bedeutet das, dass sie sich auf die Aufgabe konzentrieren können, die Ergebnisse erhalten und zum nächsten Projekt übergehen, anstatt darauf warten zu müssen, dass die Ergebnisse fertig sind. Wenn überhaupt, ist es also schlechte Nachricht für unsere Supply Chain Scientists, denn sie bekommen weniger Kaffeepausen.
Kieran Chandler: Was bedeutet dieser Durchbruch für die reale Welt? Offensichtlich sind wir in der Lage, mit viel größeren Datensätzen zu arbeiten und sie wesentlich schneller zu verarbeiten, aber gibt es noch weitere Vorteile, die wir beobachten können?
Joannes Vermorel: Ja, eine der Hauptgefahren oder Ursachen für das Scheitern quantitativer supply chain Initiativen ist die Zeit, die benötigt wird, um alles richtig hinzubekommen, um es zum Laufen zu bringen und vollständig auszureifen, sodass keine Randfälle übrigbleiben. Mit der Fähigkeit, größere Datensätze schneller zu verarbeiten, können wir diese Probleme jetzt effizienter angehen, was letztlich zu besseren supply chain Entscheidungen führt.
Kieran Chandler: Eure Systeme sind gut, aber es gibt immer noch eine Person, die rein manuell arbeitet. Das erfordert viel Arbeitskraft, um alle Randfälle manuell durchzugehen, die nicht richtig gehandhabt werden. Das untergräbt irgendwie den Sinn, fortgeschrittene maschinelle Lernautomatisierung zur Optimierung einzusetzen. Die Gefahr besteht darin, dass der Prozess, alle Randfälle zu eliminieren und das numerische Entscheidungsrezept wirklich zu schärfen, zu lange dauern kann.
Joannes Vermorel: Ja, und diese Verzögerung ist fatal, denn irgendwann verlieren die Leute das Vertrauen in den Erfolg der Initiative. Wenn du langsam bist, besteht die Chance, dass die IT irgendwo in der Mitte gestört wird. Zum Beispiel, wenn dein Projekt zwei Jahre dauert, besteht eine Chance von eins zu drei, dass es mitten drin ein ERP-Upgrade geben wird. Du beginnst, die supply chain zu optimieren, und dann gibt es eine massive Veränderung in der Unternehmensstrategie. Vieles von dem, was du gemacht hast, fällt auseinander, nur weil alle Systeme verändert werden.
Je länger du wartest, desto mehr Dinge können dein Projekt stören. Das Geschäft selbst kann sich dramatisch wandeln, wodurch deine früheren Arbeiten im Lichte der neuen Geschäftsveränderungen obsolet werden. Es gibt viele treibende Kräfte, die Druck darauf ausüben, das Produkt schnell in Produktion zu bringen. Wenn du nicht innerhalb weniger Monate Erfolg hast, steht die Wahrscheinlichkeit gut, dass deine Initiative scheitert. Genau hier ist Agilität absolut erforderlich.
Es mag nach viel klingen – ein paar Monate –, aber wenn du Terabytes an Daten bearbeitest und es Stunden dauert, ein Ergebnis zu erhalten, optimierst du im schlimmsten Fall deine numerischen Rezepte ein- oder zweimal am Tag. Die Dinge beginnen sehr langsam zu werden.
Kieran Chandler: Also sprichst du hier einen iterativen Ansatz an, um die supply chain zu optimieren. Warum gibt es einen so iterativen Ansatz? Warum kannst du nicht einfach einen Knopf drücken, deep learning einsetzen, um zu lernen und eine gute Prognose sowie gute Ergebnisse zu erzielen?
Joannes Vermorel: Die Realität findet immer einen Weg, dir in den Weg zu kommen. Die supply chain dreht sich wirklich darum, mit realen Eventualitäten umzugehen. Es gibt so viele Randfälle, die einfach aus dem Gewebe der Realität entstehen. Zum Beispiel beginnst du mit der Berechnung einer idealen Bestellmenge – sagen wir 80 Einheiten. Es ist die beste Bestellmenge, aber Paletten gibt es nur mit null Einheiten oder 100 Einheiten, weil sie auf einer Palette gepackt werden. 80 ist keine Option – was machst du also?
Es gibt Dutzende solcher Situationen. Du denkst vielleicht, dass der Wert deines Inventars im Laufe der Zeit allmählich verfällt, aber das tut er nicht. Warum? Weil es eine shelf-life mit einem spezifischen Datum gibt. Sobald du die Haltbarkeitsgrenze erreichst, sinkt dein inventory value von einem bestimmten Wert auf null oder sogar negativ, weil du nun dafür bezahlen musst, diesen wertlosen Bestand zu entsorgen.
Die Realität ist, dass supply chains komplex sind. Wenn wir von Unternehmen sprechen, die in vielen Märkten, in mehreren Ländern, mit vielen Lieferanten und potenziell Dutzenden von Produktlinien operieren, dann gibt es zahlreiche Komplikationen. Es ist Wunschdenken zu glauben, dass du dich einfach in einen Raum setzen und mit dem Team alle technischen Herausforderungen brainstormen kannst, die im Laufe der Initiativen auftauchen werden. Du kannst nicht einfach sagen: Setz dich mit deinem supply chain Team hin und lass uns alle kleinen Dinge auflisten, die das numerische Rezept, das die optimierten supply chain Entscheidungen generiert, entgleisen lassen. Die Realität überrascht dich, weil du bizarre Dinge entdecken wirst, wie zum Beispiel, dass ein bestimmtes Land eine merkwürdige Steuer auf etwas erhebt. Um auf deine anfängliche Frage zum iterativen Ansatz zurückzukommen: Der einzige Weg, mit diesem endlosen Strom an Überraschungen umzugehen, besteht darin, äußerst agil zu sein und dein numerisches Rezept anzupassen, wenn du auf etwas Unerwartetes stößt.
Kieran Chandler: Jetzt konzentrieren wir uns auf die Terabyte-Skalierbarkeit und fassen alles zusammen. Wie verändert das die Perspektive von Lokad, und was bedeutet das für die Zukunft?
Joannes Vermorel: Wir haben enorme Verbesserungen in Bezug auf die Skalierbarkeit der Verarbeitung erzielt. Diese Entwicklung eröffnet viele Möglichkeiten, die uns zuvor unzugänglich waren. Es geht nicht nur darum, sich mit größeren Unternehmen auseinanderzusetzen – es gibt zahlreiche Möglichkeiten zu tricksen, zum Beispiel. Betrachte ein großes Einzelhandelsnetzwerk: Wenn dein Ansatz, ein groß angelegtes Einzelhandelsnetzwerk zu optimieren, darin besteht, jeden Markt isoliert zu bearbeiten, und du hast sagen wir 200 Märkte, dann würdest du nur 200 Maschinen benötigen – eine pro Markt – und es würde skalieren. Aber diese Methode bringt nicht die supply chain Verbesserung, die du suchst, weil du nicht auf Netzwerkebene optimierst. Du optimierst lokal jeden Laden in Isolation und ignorierst dabei völlig, was im Rest des Netzwerks passiert.
Kieran Chandler: Also würden diese 200 Maschinen nicht miteinander kommunizieren?
Joannes Vermorel: Genau. Wenn du unabhängige silos hast, ist es sehr einfach, deine Verarbeitung zu skalieren. Aber die Herausforderung entsteht, wenn du anfängst, dein Netzwerk als eine Einheit zu betrachten, in der alles miteinander verbunden ist. Du kannst tatsächlich Inventar und Materialien über das Netzwerk in nahezu beliebiger Weise verschieben. Obwohl es viele Möglichkeiten gibt, die nicht profitabel sind und keinen Sinn ergeben, ist es möglich. Und einige dieser subtilen Wege könnten sehr gute und profitable Ideen sein. Du brauchst ein System, das alles auf einmal, auf monolithische Weise verarbeiten kann. Was bedeutet das für die Zukunft? Es bedeutet, dass sich zahlreiche Möglichkeiten für eine bessere, ganzheitliche Optimierung eröffnen. Der Fluch der supply chain Optimierung besteht darin, dass du die Probleme nicht wirklich löst – du verlagert sie nur. Du kannst einen Bereich optimieren, aber das Problem wird entweder weitergereicht oder geht zurück an den Lieferanten. Ein weiterer Aspekt ist, dass wir, da wir in der Skalierbarkeit erheblich Fortschritte gemacht haben, vermutlich versuchen werden, wieder zu mehr Ausdruckskraft zurückzukehren. Im Grunde streben wir danach, komplexe Situationen, die in der realen Welt vorkommen, direkter und fließender in diesen Envision-Skripten abzubilden. Dadurch wird es einfacher, numerische Rezepte zu liefern, die gut dazu passen, reale Situationen zu adressieren.
Kieran Chandler: Das klingt großartig. Wir müssen das jetzt zusammenfassen, aber danke für deine Zeit heute. Das ist alles für diese Woche. Vielen Dank fürs Zuschauen, und wir sehen uns beim nächsten Mal wieder. Tschüss fürs Erste.
