00:00:06 Défis du traitement des données supply chain et la scalabilité en téraoctets de Lokad.
00:00:38 Améliorations de la capacité de traitement de Lokad au cours de l’année écoulée.
00:01:33 Explication de la plateforme de Lokad et de leur langage de script Envision.
00:03:55 Comparaison d’Envision avec d’autres langages de programmation tels que Python.
00:06:27 Aperçus clés et percées ayant conduit aux améliorations de Lokad.
00:08:00 Stockage tabulaire vs. stockage en colonne dans les bases de données et leurs efficacités.
00:10:36 Défis et coûts associés au traitement de grandes quantités de données.
00:12:04 L’impact du traitement en téraoctets sur les Supply Chain Scientist et l’efficacité au travail.
00:14:10 Avantages concrets du traitement plus rapide et de la gestion d’ensembles de données plus volumineux.
00:15:30 Importance d’éliminer les cas particuliers et le danger des processus trop longs dans les initiatives de la Supply Chain Quantitative.
00:17:43 Importance d’une approche itérative pour faire face aux aléas du monde réel.
00:20:47 Défis et implications du traitement de données à grande échelle dans l’optimisation de la supply chain.
00:21:10 L’impact de la scalabilité en téraoctets sur les perspectives de Lokad et l’avenir de l’optimisation de la supply chain.
00:24:41 Réflexions finales et pistes potentielles pour améliorer l’optimisation de la supply chain.
Résumé
Kieran Chandler interviewe Joannes Vermorel, fondateur de Lokad, au sujet de l’optimisation de la supply chain et de la gestion de vastes ensembles de données. Lokad a multiplié par 20 sa capacité de traitement depuis 2017, en utilisant son langage spécifique, Envision, pour le traitement de données à grande échelle. Envision simplifie le calcul distribué dans le contexte de la supply chain par rapport aux langages de programmation génériques. Les avancées de Lokad ont réduit les temps de traitement des données, passant des heures aux minutes, permettant ainsi aux Supply Chain Scientist de travailler plus efficacement. Vermorel souligne l’importance de l’agilité et de l’optimisation itérative pour réussir les initiatives de la supply chain. La scalabilité en téraoctets de Lokad permet une approche plus holistique de l’optimisation et prévoit d’améliorer l’expressivité des scripts Envision pour mieux répondre aux situations réelles de supply chain.
Résumé Étendu
Dans cette interview, Kieran Chandler, l’animateur, discute avec Joannes Vermorel, le fondateur de Lokad, une entreprise de logiciels spécialisée dans l’optimisation de la supply chain. Ils abordent les défis liés à la gestion de vastes volumes de données dans l’industrie de la supply chain et les développements de Lokad en scalabilité en téraoctets.
Joannes mentionne que 2018 a été une année de scalabilité pour Lokad, l’entreprise ayant augmenté sa capacité de traitement d’un facteur 20 par rapport à l’année précédente. Cette amélioration a permis à Lokad de gérer des ensembles de données multi-téraoctets avec une relative aisance, compte tenu de l’état actuel de la technologie.
L’entreprise a réalisé cela en développant la plateforme Solocat, conçue pour l’optimisation de la Supply Chain Quantitative. La plateforme utilise le langage de script spécifique à domaine de Lokad, appelé Envision. Envision est conçu pour répondre aux besoins spécifiques des problèmes de supply chain et faciliter le traitement de données à grande échelle.
Avant 2018, un seul script Envision ne pouvait être exécuté que sur une seule machine, même si la plateforme pouvait contenir plusieurs téraoctets de données. L’entreprise avait mis en place un certain niveau de scalabilité en distribuant les calculs de machine learning sur plusieurs machines. Cependant, des tâches comme le tri des données étaient encore limitées à une seule machine puissante.
En 2018, Lokad a déployé une architecture entièrement mise à niveau pour la logique d’exécution backend des scripts Envision. La nouvelle architecture permet une parallélisation automatique sur plusieurs processeurs et même sur des flottes entières de machines. Par conséquent, des tâches telles que le tri des données peuvent désormais être effectuées beaucoup plus rapidement en utilisant la puissance de traitement de dizaines de machines.
En comparant Envision aux langages de programmation génériques tels que Python, Java, C++ et C#, Joannes explique qu’Envision est un langage spécifique à domaine, adapté pour traiter les problèmes de supply chain. Alors que les langages de programmation génériques offrent la capacité de faire presque n’importe quoi, ils nécessitent souvent des configurations plus complexes et une compréhension approfondie de bibliothèques et de frameworks spécifiques pour réaliser du calcul distribué.
En revanche, Envision simplifie ces aspects techniques, facilitant ainsi la gestion du calcul distribué et le traitement de données à grande échelle dans le contexte de l’optimisation de la supply chain. Cette approche spécialisée permet à Lokad d’améliorer la scalabilité et de gérer plus efficacement des téraoctets de données par rapport à l’utilisation de langages de programmation génériques.
Ils discutent du logiciel de l’entreprise, Envision, de ses avantages et de la manière dont les récentes avancées ont amélioré l’analytique de la supply chain.
Envision est un langage de script spécialement conçu pour les problèmes de supply chain, le rendant plus simple et plus efficace à utiliser que d’autres langages de programmation à usage général. Il sacrifie une partie de son expressivité au profit de la simplicité, mais comme il se concentre sur un type de problème spécifique, ce compromis est acceptable. Vermorel compare la facilité d’utilisation d’Envision à la rédaction de feuilles Excel avancées avec des moyennes sophistiquées, des tris élégants et des recherches complexes sur les données.
Il y a un an, Lokad avait déjà mis en place une approche en colonnes pour le stockage des données dans le cadre de l’analytique du big data, qui convient mieux à l’analyse par lots plutôt qu’au traitement en temps réel. Cette approche stocke les données par colonne, plutôt que par ligne, permettant un traitement plus efficace des opérations qui ne concernent que quelques colonnes. Toutefois, l’inconvénient est que l’ajout de nouvelles lignes nécessite de travailler sur chaque colonne, ce qui la rend moins efficace pour le traitement en temps réel.
Lorsqu’il s’agit des coûts associés au traitement de grandes quantités de données, Vermorel souligne que la ressource la plus chère est le Supply Chain Scientist (ou data scientist), car ils sont rares, nécessitent des connaissances spécifiques et requièrent une formation approfondie. En conséquence, Lokad vise à optimiser l’utilisation du temps de ces scientifiques en réduisant le temps consacré au traitement des données.
Auparavant, le traitement de téraoctets de données prenait des heures, mais les récentes avancées ont réduit ce délai à quelques minutes. Cela permet aux Supply Chain Scientist de rester concentrés sur leurs tâches et de passer plus rapidement à l’étape suivante, plutôt que d’attendre les résultats. Cependant, cela signifie également qu’ils ont moins d’opportunités de pauses.
La percée consistant à traiter des ensembles de données plus volumineux plus rapidement présente plusieurs avantages concrets. Elle permet aux entreprises d’analyser et d’optimiser leur supply chain de manière plus efficace, améliorant ainsi l’ensemble de leurs opérations.
Ils abordent les défis de l’optimisation, l’importance de l’agilité et l’approche itérative nécessaire pour faire face aux aléas du monde réel.
Vermorel identifie le principal danger dans la mise en œuvre d’une initiative de la Supply Chain Quantitative comme étant le temps nécessaire pour perfectionner le système, car il est crucial de prendre en charge tous les cas particuliers afin d’éviter une intervention manuelle. Plus cela prend du temps, plus il est probable que le projet rencontre des disruptions, telles que des mises à niveau informatiques ou d’ERP, ou encore des transformations d’entreprise radicales, pouvant rendre le travail antérieur obsolète.
Pour réussir, les initiatives d’optimisation de la supply chain doivent être mises en production rapidement, ce qui nécessite de l’agilité. Vermorel explique que, bien que cela puisse sembler beaucoup à accomplir en quelques mois, trop de temps passé risque de faire échouer le projet. Il insiste sur l’approche itérative de l’optimisation, nécessaire en raison du caractère imprévisible des supply chain et des aléas du monde réel pouvant faire dérailler les recettes numériques.
L’optimisation itérative est essentielle pour gérer l’afflux constant de surprises inhérentes à la gestion de la supply chain. Vermorel explique que les supply chain sont complexes, impliquant de multiples marchés, pays, fournisseurs et gammes de produits. Il est impossible de prévoir et d’énumérer tous les défis techniques potentiels à l’avance, si bien que l’agilité est cruciale lors de l’ajustement des recettes numériques.
Kieran demande ensuite à Vermorel quel est l’impact de la scalabilité en téraoctets sur Lokad et ses perspectives d’avenir. Vermorel déclare que l’entreprise a réalisé d’énormes améliorations en matière de scalabilité de traitement, ce qui ouvre de nouvelles opportunités pour l’optimisation de la supply chain. Il précise que la scalabilité ne consiste pas seulement à gérer des entreprises de plus grande taille, mais aussi à atteindre une optimisation au niveau du réseau.
Vermorel souligne que la véritable optimisation exige de considérer l’ensemble du réseau comme une entité unique, plutôt que d’optimiser chaque magasin ou fournisseur isolément. La scalabilité en téraoctets permet à Lokad d’aborder l’optimisation de manière plus holistique, ce qui aide à empêcher que les problèmes ne soient simplement déplacés en aval de la supply chain.
À l’avenir, Lokad prévoit d’utiliser ses progrès en scalabilité pour améliorer l’expressivité, permettant des moyens plus fluides et directs de refléter des situations complexes du monde réel dans leurs scripts Envision. Cela facilitera le développement de recettes numériques qui répondent efficacement aux situations réelles de supply chain.
L’interview se conclut avec Vermorel soulignant l’importance de l’agilité, de l’optimisation itérative et des approches holistiques de la gestion de la supply chain.
Transcription Complète
Kieran Chandler: Aujourd’hui sur Lokad TV, nous allons comprendre l’ampleur des données gérées au sein d’une supply chain et également discuter de la manière dont Lokad a développé une scalabilité en téraoctets pour y faire face. Alors, Joannes, aujourd’hui nous allons parler un peu des recherches et développements effectués chez Lokad au cours de l’année écoulée. Sur quoi avez-vous travaillé en 2018 ?
Joannes Vermorel: 2018 a été l’année de la scalabilité pour nous. Nous avons travaillé presque sans interruption pendant un an pour augmenter la scalabilité. Par rapport à la même date en janvier dernier, nous avons augmenté notre capacité de traitement d’un facteur de 20, ce qui nous place bien dans la capacité de traiter des ensembles de données multi-téraoctets avec une relative facilité. Le traitement en téraoctets n’est jamais simple compte tenu de l’état actuel de la technologie, mais il peut tout de même être rendu relativement simple.
Kieran Chandler: Un facteur de 20 semble être une amélioration incroyablement importante. Quelles démarches avez-vous dû entreprendre pour atteindre cette amélioration ?
Joannes Vermorel: Lokad est une plateforme conçue pour l’optimisation de la supply chain. Techniquement, elle est accessible via des scripts écrits dans notre propre langage de script maison, appelé Envision. Ce langage est conçu non seulement pour répondre spécifiquement aux besoins de l’optimisation de la supply chain, mais aussi pour faciliter le traitement de données à grande échelle. Jusqu’à l’année dernière, un seul compte pour l’un de nos clients pouvait contenir plusieurs téraoctets de données, mais un seul script ou morceau de code était exécuté sur une seule machine. Nous avions déjà mis en place le scale-out, permettant ainsi de distribuer le calcul sur de nombreuses machines pour des composants spécifiques tels que le machine learning. Cependant, de manière générale, lorsque vous triez simplement les données, cela se faisait sur une grande machine. En 2018, nous avons déployé une architecture entièrement mise à niveau pour la logique d’exécution backend des scripts Envision. De nos jours, vous bénéficiez d’une parallélisation automatique non seulement sur plusieurs processeurs et CPUs, mais aussi sur une flotte de machines. Cela signifie qu’un seul script qui effectue une opération simple, telle que le tri des données par date, produit, magasin ou prix, peut s’exécuter sur une flotte de dizaines de machines, rendant ainsi le processus beaucoup plus rapide.
Kieran Chandler: Parlons un peu d’Envision. Comment Envision contribue-t-il à ces améliorations et à l’augmentation de la scalabilité par rapport à l’utilisation d’autres langages de programmation comme Python ou quelque chose de ce genre ?
Joannes Vermorel: Envision est un langage de programmation spécifique à domaine, tandis que Python, Java, C++ et C# sont des langages de programmation génériques. Avec un langage générique, vous avez la capacité de faire pratiquement n’importe quoi, mais le prix à payer est que certaines subtilités techniques surgissent dans l’environnement de programmation. Par exemple, vous pouvez réaliser du calcul distribué avec Python, mais vous devez rédiger votre code de manière à tirer parti de bibliothèques et de frameworks spécifiques pour que ces calculs se répartissent sur une flotte de machines. De plus, vous devrez configurer vous-même un cluster de machines pour exécuter cette logique distribuée. Si vous avez plusieurs programmes concurrents s’exécutant sur le même cluster parce que vous avez différents scripts ou différents utilisateurs, cela devient plus complexe. Besoins différents… Eh bien, il faut que toute l’infrastructure soit en place pour partager les ressources, comme la bande passante, les disques, les CPUs, et ainsi de suite. Et c’est précisément ce que fait Envision de manière entièrement intégrée pour vous. Ainsi, vous perdez beaucoup d’expressivité, ce qui est acceptable, car, encore une fois, Envision peut tenir le coup. Il n’est pas défectueux, malgré une perte d’expressivité, parce que nous sommes spécialisés dans un type de problème spécifique, essentiellement les problèmes de supply chain. Nous ne cherchons donc pas à résoudre chaque problème. Nous ne cherchons pas à écrire un moteur pour jouer aux échecs ou pour faire de la modélisation 3D. Il est très orienté vers des types de problèmes spécifiques.
Kieran Chandler: D’accord, donc ce que vous dites, c’est qu’il est beaucoup plus simple d’utiliser Envision plutôt qu’un autre type de langage de programmation ?
Joannes Vermorel: Exactement. Je veux dire, écrire un script qui traite des tableaux contenant plusieurs milliards de lignes pour réaliser le type d’analyse que l’on attend dans le contexte de la supply chain, comme estimer le coût et l’impact des ruptures de stock sur un grand réseau pour les trois dernières années, est quelque chose que vous pourriez faire avec seulement une dizaine de lignes de code. Un code qui est facile à écrire. Quand je dis facile à écrire, je veux dire qu’il n’est jamais simple d’écrire du code, mais ce n’est pas plus difficile que, disons, rédiger une feuille Excel avancée qui réalise des moyennes sophistiquées, des tris élégants et des recherches complexes sur les données.
Kieran Chandler: D’accord, et quelles ont été certaines des idées clés et percées qui ont conduit à ces améliorations?
Joannes Vermorel: Juste pour comprendre d’où nous partions, il y a un an, Lokad disposait déjà de nombreux ingrédients de big data. L’un d’entre eux consiste à adopter une approche par colonnes pour le stockage des données. Bref, pour faire court, les bases de données SQL traditionnelles adoptent un stockage tabulaire. Cela signifie que lorsque vous avez une table, vous stockez des lignes de données, et si vous avez une ligne, elle est regroupée, et c’est votre unité. Fondamentalement, cela rend les bases de données tabulaires très efficaces pour effectuer de petites mises à jour ou une lecture/écriture ligne par ligne.
En revanche, au cours des dernières décennies, chaque fois que vous souhaitez réaliser une analyse de données, ce qui a été développé, c’est une approche par colonnes. Donc, fondamentalement, lorsque vous avez une table, disons une table avec 20 colonnes, vous allez stocker les données regroupées par colonne. Alors, qu’est-ce que cela signifie ? Cela signifie que lorsque vous effectuez une opération, par exemple : “J’ai le prix par unité, et j’ai la quantité. Supposons que vous ayez une table qui représente lsales history. Maintenant, vous voulez connaître le montant total des ventes, alors que devez-vous faire ? Vous devez multiplier le prix par la quantité et faire la somme de le tout à travers la table.” Eh bien, il s’avère que votre table peut avoir 20 colonnes, mais l’opération que je viens de décrire ne touche que deux colonnes. Ainsi, si vous disposez d’un stockage par colonnes, l’avantage principal est que toute opération ne touchant que quelques colonnes verra ces quelques colonnes traitées, et le reste pourra être tout simplement ignoré. Si vous avez un format tabulaire, eh bien, les autres colonnes restent complètement présentes, et vous ne pouvez pas vraiment les ignorer.
Mais l’inconvénient pourrait être que si vous ajoutez des lignes supplémentaires, si vous travaillez en temps réel, en adoptant une approche par colonnes, si vous ajoutez une ligne, vous devez traiter chaque colonne.
Kieran Chandler: Donc, lorsque vous ajoutez une ligne, vous devez toucher 20 colonnes, ce qui le rend relativement inefficace. Le stockage par colonnes est plus adapté à l’analyse par lots, pas exactement en temps réel, mais plutôt au type d’analyses qui vous intéresse pour la supply chain. Il peut être actualisé chaque minute, mais pas toutes les millisecondes. Parlons un peu des coûts associés à la puissance de traitement et au travail avec de grandes quantités de données. Comment la mise en œuvre d’une scalabilité à l’échelle du téraoctet a-t-elle affecté les coûts de traitement des données?
Joannes Vermorel: En réalité, énormément. Les ressources les plus coûteuses lorsque vous tentez d’optimiser une supply chain à grande échelle sont les Supply Chain Scientist. Ces personnes ne sont pas gratuites, et il est difficile de trouver et de former des individus dotés du talent approprié. La ressource rare n’est pas constituée des CPU, des disques ou de la bande passante, qui peuvent être obtenus à moindre coût via votre plateforme cloud computing préférée, mais bien des personnes talentueuses que vous devez mobiliser pour résoudre le problème.
Lorsque vous entrez dans le domaine du traitement en téraoctets, tout est lent. Traiter un téraoctet de données peut prendre un temps considérable, surtout si vous effectuez des calculs non triviaux impliquant des calculs probabilistes avec des variables aléatoires. Cela pourrait prendre des heures, mais maintenant, cela prend des minutes. Pour les Supply Chain Scientist, cela signifie qu’ils peuvent rester concentrés sur leur tâche, obtenir les résultats et passer à autre chose au lieu d’être coincés à attendre les résultats. Donc, le cas échéant, c’est une mauvaise nouvelle pour nos Supply Chain Scientist car ils auront moins de pauses café.
Kieran Chandler: Qu’est-ce que cette avancée signifie pour le monde réel? Évidemment, nous sommes capables de travailler avec des ensembles de données beaucoup plus volumineux et de les traiter beaucoup plus rapidement, mais y a-t-il d’autres avantages que nous constatons?
Joannes Vermorel: Oui, l’un des dangers clés, ou des causes profondes de l’échec des initiatives de la Supply Chain Quantitative, est le temps nécessaire pour bien faire les choses, pour les faire fonctionner et les parfaire afin de ne pas avoir de cas particuliers résiduels. Avec la capacité de traiter des ensembles de données plus volumineux plus rapidement, nous pouvons désormais résoudre ces problèmes de manière plus efficace, ce qui conduit en fin de compte à de meilleures décisions supply chain.
Kieran Chandler: Vos systèmes sont bons, mais il reste encore une personne qui demeure entièrement manuelle. Cela nécessite beaucoup de main-d’œuvre pour passer manuellement en revue tous les cas particuliers qui ne sont pas correctement gérés. Cela va quelque peu à l’encontre de l’objectif d’avoir une automatisation avancée de machine learning pour l’optimisation. Le danger est que le processus visant à éliminer tous les cas particuliers, afin d’affiner véritablement la recette numérique de prise de décision, peut prendre trop de temps.
Joannes Vermorel: Oui, et ce retard est fatal car, à un moment donné, les gens perdent confiance dans le succès de l’initiative. Si vous êtes lent, il y a de fortes chances que l’informatique soit perturbée en cours de route. Par exemple, si votre projet prend deux ans, il y a une chance sur trois qu’une mise à niveau de l’ERP intervienne au milieu. Vous commencez à optimiser la supply chain, puis une modification massive intervient dans la vision de l’entreprise. Une grande partie de ce que vous avez fait s’effondre simplement parce que tous les systèmes sont en cours de changement.
Plus vous attendez, plus les choses peuvent perturber votre projet. L’entreprise elle-même peut subir une transformation dramatique qui rend votre travail antérieur obsolète au regard des nouveaux changements commerciaux. Il existe de nombreuses forces motrices qui exercent une pression pour mettre le produit en production rapidement. Si vous ne pouvez pas réussir en quelques mois, il y a de fortes chances que votre initiative échoue. C’est là que l’agilité est absolument nécessaire.
Cela peut sembler beaucoup, quelques mois, mais lorsque vous traitez des téraoctets de données et qu’il faut des heures pour obtenir un résultat, vous ajustez essentiellement vos recettes numériques une ou deux fois par jour au pire. Les choses commencent à devenir très lentes.
Kieran Chandler: Ce à quoi vous faites allusion, c’est une sorte d’approche itérative pour optimiser la supply chain. Pourquoi y a-t-il une telle approche itérative? Pourquoi ne pouvez-vous pas simplement appuyer sur un bouton, utiliser deep learning pour apprendre et obtenir une bonne prévision et de bons résultats?
Joannes Vermorel: La réalité a une manière de se mettre en travers de votre chemin. La supply chain consiste réellement à gérer les contingences du monde réel. Il y a tant de cas particuliers qui émergent tout simplement du tissu même de la réalité. Par exemple, vous commencez à calculer une quantité idéale à commander, disons 80 unités. C’est la meilleure quantité à commander, mais les palettes ne se présentent qu’en 0 unité ou 100 unités parce qu’elles sont emballées sur une palette. 80 n’est pas une option, alors que faites-vous?
Il y a des dizaines de situations comme celle-ci. Vous pourriez penser que la valeur de vos stocks se déprécie progressivement avec le temps, mais ce n’est pas le cas. Pourquoi? Parce qu’il y a une durée de vie avec une date spécifique. Lorsque vous atteignez la limite de durée de vie, la valeur de vos stocks chute de quelque chose à zéro, voire devient négative, car vous devez désormais payer pour éliminer ces stocks sans valeur.
La réalité est que les supply chains sont complexes. Si nous parlons d’entreprises opérant sur de nombreux marchés, dans plusieurs pays, avec de nombreux fournisseurs, potentiellement des dizaines de gammes de produits, il y a beaucoup de complications. C’est un vœu pieux de croire que vous pouvez simplement vous asseoir dans une pièce et faire un brainstorming avec l’équipe sur tous les défis techniques qui émergeront au fil des initiatives. Vous ne pouvez pas simplement dire… Asseyez-vous avec votre équipe supply chain et dites : listons toutes les petites choses qui vont dérailler la recette numérique qui génère les décisions supply chain optimisées. La réalité, comme toujours, a une manière de vous surprendre car vous allez découvrir des choses bizarres, comme par exemple un certain pays ayant une taxe étrange sur quelque chose. Pour revenir à votre question initiale sur l’approche itérative, la seule façon de faire face à ce flux infini de surprises est d’être extrêmement agile pour corriger votre recette numérique lorsque vous faites face à l’inattendu.
Kieran Chandler: Concentrons-nous maintenant sur la scalabilité en téraoctets et commençons à rassembler le tout. Comment cela change-t-il les perspectives pour Lokad, et qu’est-ce que cela signifie pour l’avenir?
Joannes Vermorel: Nous avons réalisé d’énormes améliorations en termes de traitement scalable. Ce développement ouvre de nombreuses possibilités qui nous étaient auparavant inaccessibles. Il ne s’agit pas seulement de gérer des entreprises plus importantes, il existe de nombreuses façons de tricher, par exemple. Considérez un grand réseau de distribution. Si votre approche pour optimiser un réseau de distribution à grande échelle consiste à traiter chaque marché isolément, et si vous avez, disons, 200 marchés, vous n’auriez besoin que de 200 machines, une par marché, et cela se mettrait à l’échelle. Toutefois, cette méthode ne donnera pas l’amélioration de la supply chain que vous recherchez car vous n’optimisez pas à l’échelle du réseau. Vous optimisez localement chaque magasin de manière isolée, ignorant complètement ce qui se passe dans le reste du réseau.
Kieran Chandler: Donc ces 200 machines ne communiqueraient pas entre elles?
Joannes Vermorel: Exactement. Si vous avez des silos, il est très facile de mettre à l’échelle votre traitement. Mais le défi survient lorsque vous commencez à envisager votre réseau comme une seule entité où tout est connecté. Vous pouvez en fait expédier des stocks et des matériaux à travers le réseau de pratiquement toutes les manières souhaitées. Bien qu’il existe de nombreuses méthodes qui ne sont pas profitables et qui n’ont pas de sens, c’est possible. Et certaines de ces méthodes subtiles pourraient être de très bonnes idées et rentables. Vous avez besoin d’un système capable de traiter le tout d’un coup, de manière monolithique. Qu’est-ce que cela signifie pour l’avenir? Cela signifie que cela ouvre une multitude de possibilités pour une optimisation plus holistique. La malédiction de l’optimisation de la supply chain, c’est que vous ne résolvez pas les problèmes; vous les déplacez simplement. Vous pouvez examiner une zone et l’optimiser, mais tout ce que vous faites, c’est déplacer le problème en aval ou le renvoyer au fournisseur. Une autre perspective est que, maintenant que nous avons considérablement gagné en scalabilité, nous essaierons probablement de revenir à l’expressivité. Fondamentalement, nous visons à exprimer des situations complexes qui se produisent dans le monde réel de manière plus directe et fluide dans ces scripts Envision. De cette façon, il est plus facile de fournir des recettes numériques adaptées pour traiter des situations réelles.
Kieran Chandler: Cela semble génial. Nous allons devoir conclure ici, mais merci pour votre temps aujourd’hui. C’est tout pour cette semaine. Merci beaucoup de nous avoir regardés, et nous nous reverrons la prochaine fois. Au revoir pour l’instant.
