00:00:06 Les défis du traitement des données de la chaîne d’approvisionnement et la scalabilité téraoctet 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 à d’autres langages de programmation comme Python.
00:06:27 Principales idées et avancées qui ont conduit aux améliorations de Lokad.
00:08:00 Stockage tabulaire par rapport au stockage en colonnes 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 téraoctet sur les scientifiques de la chaîne d’approvisionnement et l’efficacité du travail.
00:14:10 Avantages concrets d’un traitement plus rapide et de la manipulation de jeux de données plus volumineux.
00:15:30 Importance de l’élimination des cas particuliers et danger des processus longs dans les initiatives quantitatives de la chaîne d’approvisionnement.
00:17:43 Importance d’une approche itérative pour faire face aux contingences du monde réel.
00:20:47 Défis et implications du traitement de données à grande échelle dans l’optimisation de la chaîne d’approvisionnement.
00:21:10 Impact de la scalabilité téraoctet sur les perspectives de Lokad et l’avenir de l’optimisation de la chaîne d’approvisionnement.
00:24:41 Réflexions finales et pistes potentielles pour améliorer l’optimisation de la chaîne d’approvisionnement.
Résumé
Kieran Chandler interviewe Joannes Vermorel, fondateur de Lokad, sur l’optimisation de la chaîne d’approvisionnement et la gestion de vastes ensembles de données. Lokad a augmenté sa capacité de traitement de 20 fois depuis 2017, en utilisant leur langage spécifique au domaine, Envision, pour le traitement de données à grande échelle. Envision simplifie le calcul distribué dans le contexte de la chaîne d’approvisionnement par rapport aux langages de programmation génériques. Les avancées de Lokad ont réduit les temps de traitement des données de plusieurs heures à quelques minutes, permettant aux scientifiques de la chaîne d’approvisionnement de travailler plus efficacement. Vermorel souligne l’importance de l’agilité et de l’optimisation itérative pour des initiatives de chaîne d’approvisionnement réussies. La scalabilité téraoctet 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 la chaîne d’approvisionnement.
Résumé étendu
Dans cette interview, Kieran Chandler, l’animateur, discute avec Joannes Vermorel, le fondateur de Lokad, une entreprise spécialisée dans l’optimisation de la chaîne d’approvisionnement. Ils abordent les défis de la gestion de vastes quantités de données dans l’industrie de la chaîne d’approvisionnement et les développements de Lokad en matière de scalabilité téraoctet.
Joannes mentionne que 2018 a été une année de scalabilité pour Lokad, l’entreprise ayant augmenté sa capacité de traitement de 20 fois par rapport à l’année précédente. Cette amélioration a permis à Lokad de gérer des ensembles de données de plusieurs téraoctets avec une relative facilité, compte tenu de l’état actuel de la technologie.
La société 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 au domaine de Lokad appelé Envision. Envision est conçu pour répondre aux besoins spécifiques des problèmes de la chaîne d’approvisionnement et faciliter le traitement de données à grande échelle.
Avant 2018, un seul script Envision pouvait être exécuté sur une seule machine, même si la plateforme pouvait contenir plusieurs téraoctets de données. La société avait mis en place un certain niveau de scalabilité en répartissant les calculs d’apprentissage automatique sur plusieurs machines. Cependant, des tâches telles que le tri des données étaient encore limitées à une seule grande machine.
En 2018, Lokad a déployé une architecture entièrement mise à niveau pour la logique d’exécution en arrière-plan des scripts Envision. La nouvelle architecture permet une parallélisation automatique sur plusieurs processeurs et même sur des flottes entières de machines. En conséquence, des tâches telles que le tri des données peuvent maintenant être effectuées beaucoup plus rapidement en utilisant la puissance de traitement de dizaines de machines.
Lorsqu’il compare Envision à des langages de programmation génériques tels que Python, Java, C++ et C#, Joannes explique qu’Envision est un langage spécifique au domaine conçu pour traiter les problèmes de la chaîne d’approvisionnement. Alors que les langages de programmation génériques offrent la possibilité de faire presque tout, ils nécessitent souvent des configurations plus complexes et une compréhension plus approfondie de bibliothèques et de frameworks spécifiques pour réaliser le calcul distribué.
Envision, en revanche, simplifie ces aspects techniques, ce qui facilite le traitement distribué et le traitement de données à grande échelle dans le contexte de l’optimisation de la chaîne d’approvisionnement. Cette approche spécialisée permet à Lokad d’améliorer la scalabilité et de traiter des téraoctets de données de manière plus efficace que 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écents progrès ont amélioré l’analyse de la chaîne d’approvisionnement.
Envision est un langage de script spécialement conçu pour les problèmes de la chaîne d’approvisionnement, ce qui le rend plus facile et plus efficace à utiliser que d’autres langages de programmation généralistes. Il sacrifie une certaine expressivité pour la simplicité, mais comme il se concentre sur un type spécifique de problème, ce compromis est acceptable. Vermorel compare la facilité d’utilisation d’Envision à l’écriture de feuilles Excel avancées avec des moyennes, des tris et des recherches sophistiqués.
Il y a un an, Lokad avait déjà mis en place une approche colonne pour le stockage des données destinées à l’analyse de big data, qui est plus adaptée à l’analyse par lots qu’au traitement en temps réel. Cette approche stocke les données par colonne, plutôt que par ligne, ce qui permet un traitement plus efficace des opérations qui ne touchent que quelques colonnes. Cependant, l’inconvénient est que l’ajout de nouvelles lignes nécessite de travailler avec chaque colonne, ce qui le rend moins efficace pour le traitement en temps réel.
Lorsqu’il discute des coûts associés au traitement de grandes quantités de données, Vermorel souligne que la ressource la plus coûteuse est le scientifique de la chaîne d’approvisionnement (ou le data scientist), car ils sont rares, nécessitent des connaissances spécifiques et une formation approfondie. Par conséquent, Lokad vise à optimiser l’utilisation du temps de ces scientifiques en réduisant le temps passé sur le traitement des données.
Auparavant, le traitement de téraoctets de données prenait des heures, mais les progrès récents ont réduit ce temps à quelques minutes. Cela permet aux scientifiques de la chaîne d’approvisionnement 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’occasions de faire des pauses.
La percée du traitement de plus grandes quantités de données plus rapidement présente plusieurs avantages concrets. Cela permet aux entreprises d’analyser et d’optimiser leurs chaînes d’approvisionnement de manière plus efficace et plus efficace, améliorant ainsi leurs opérations globales.
Ils abordent les défis de l’optimisation, l’importance de l’agilité et l’approche itérative nécessaire pour gérer les contingences du monde réel.
Vermorel identifie le principal danger de la mise en œuvre d’une initiative de chaîne d’approvisionnement quantitative comme le temps nécessaire pour perfectionner le système, car il est crucial de gérer tous les cas particuliers pour éviter toute intervention manuelle. Plus cela prend de temps, plus le projet risque de faire face à des perturbations, telles que des mises à niveau informatiques ou ERP, ou des transformations commerciales radicales, qui peuvent rendre le travail précédent obsolète.
Pour réussir, les initiatives d’optimisation de la chaîne d’approvisionnement doivent être mises en production rapidement, ce qui nécessite de l’agilité. Vermorel explique que même si cela peut sembler beaucoup à accomplir en quelques mois, prendre trop de temps risque l’échec du projet. Il met l’accent sur l’approche itérative de l’optimisation, qui est nécessaire en raison de la nature imprévisible des chaînes d’approvisionnement et des contingences du monde réel qui peuvent perturber les recettes numériques.
L’optimisation itérative est essentielle pour gérer le flux incessant de surprises liées à la gestion de la chaîne d’approvisionnement. Vermorel explique que les chaînes d’approvisionnement sont complexes, impliquant plusieurs marchés, pays, fournisseurs et lignes de produits. Il est impossible de réfléchir et de répertorier tous les défis techniques potentiels à l’avance, il est donc crucial d’être agile lors de la résolution des recettes numériques.
Kieran demande ensuite à Vermorel quel est l’impact de la scalabilité des téraoctets sur Lokad et ses perspectives d’avenir. Vermorel déclare que l’entreprise a réalisé d’énormes améliorations dans le traitement de la scalabilité, ce qui ouvre de nouvelles opportunités pour l’optimisation de la chaîne d’approvisionnement. Il précise que la scalabilité ne concerne pas seulement les grandes entreprises, mais aussi l’optimisation au niveau du réseau.
Vermorel souligne que la véritable optimisation nécessite de considérer l’ensemble du réseau comme une seule entité, plutôt que d’optimiser chaque magasin ou fournisseur de manière isolée. La scalabilité des téraoctets permet à Lokad d’aborder l’optimisation de manière plus holistique, ce qui aide à éviter que les problèmes ne soient déplacés dans la chaîne d’approvisionnement.
À l’avenir, Lokad prévoit d’utiliser ses gains en scalabilité pour améliorer l’expressivité, permettant ainsi des moyens plus fluides et directs de refléter des situations réelles complexes dans leurs scripts Envision. Cela facilitera le développement de recettes numériques qui traitent efficacement les situations réelles de la chaîne d’approvisionnement.
L’interview se termine par Vermorel soulignant l’importance de l’agilité, de l’optimisation itérative et des approches holistiques de la gestion de la chaîne d’approvisionnement.
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 chaîne d’approvisionnement et discuter également de la façon dont Lokad a développé une scalabilité des téraoctets pour y faire face. Alors, Joannes, aujourd’hui nous allons parler un peu de la recherche et du développement réalisé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 continuellement pendant un an pour augmenter la scalabilité. Comparé à la même date en janvier dernier, nous avons augmenté notre capacité de traitement d’un facteur d’environ 20, ce qui nous permet de traiter relativement facilement des ensembles de données de plusieurs téraoctets. Il n’y a rien de tel que le traitement facile des téraoctets compte tenu de la technologie telle qu’elle est aujourd’hui, mais cela peut encore être relativement simple.
Kieran Chandler: Un facteur de 20 semble être une amélioration incroyablement importante. Quelles étapes avez-vous dû franchir pour atteindre cette amélioration ?
Joannes Vermorel: Lokad est une plateforme conçue pour l’optimisation de la chaîne d’approvisionnement. Techniquement, elle est accessible via des scripts écrits dans notre propre langage de script fait maison appelé Envision. Ce langage est conçu non seulement pour répondre spécifiquement aux besoins de l’optimisation de la chaîne d’approvisionnement, mais aussi pour faciliter le traitement à 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 une mise à l’échelle, donc l’idée était que vous pouviez répartir le calcul sur de nombreuses machines pour des composants spécifiques tels que l’apprentissage automatique. Cependant, en général, lorsque vous triiez simplement les données, cela se passait sur une seule grande machine. En 2018, nous avons déployé une architecture complètement mise à jour pour la logique d’exécution en arrière-plan des scripts Envision. De nos jours, vous avez une parallélisation automatique non seulement sur plusieurs processeurs et CPU, mais aussi sur une flotte de machines. Cela signifie qu’un seul script qui effectue une opération simple, comme trier les données par date, produit, magasin ou prix, peut se produire sur une flotte de dizaines de machines, ce qui le rend beaucoup plus rapide.
Kieran Chandler: Parlons un peu d’Envision. Comment Envision fonctionne-t-il pour apporter ces améliorations et améliorer la scalabilité par rapport au travail avec d’autres langages de programmation comme Python ou quelque chose comme ça ?
Joannes Vermorel: Envision est un langage de programmation spécifique à un domaine, tandis que Python, Java, C++ et C# sont des langages de programmation génériques. Avec un langage de programmation générique, vous avez la capacité de faire à peu près n’importe quoi, mais le prix à payer est que des classes de complexités apparaissent dans l’environnement de programmation. Par exemple, vous pouvez faire du calcul distribué avec Python, mais vous devez écrire votre code de manière à tirer parti de bibliothèques et de frameworks spécifiques pour que ces calculs se fassent sur un ensemble de machines. De plus, vous devrez configurer vous-même un cluster de machines pour qu’il puisse exécuter cette logique distribuée. Si vous avez plusieurs programmes concurrents qui s’exécutent sur le même cluster parce que vous avez différents scripts ou différents utilisateurs, cela devient plus complexe. Différents besoins… Eh bien, nous devons avoir toute l’infrastructure en place pour partager les ressources, vous savez, la bande passante, les disques, les processeurs, et ainsi de suite. Et c’est précisément ce que fait Envision de manière intégrée pour vous. Donc, ce que vous perdez, c’est que vous perdez beaucoup d’expressivité, ce qui est acceptable car, encore une fois, Envision peut survivre. Il n’est pas cassé, malgré avoir perdu beaucoup d’expressivité, car nous sommes spécialisés dans un type spécifique de problème, qui est essentiellement les problèmes de supply chain. Nous n’essayons donc pas de résoudre tous les problèmes. Nous n’essayons pas d’écrire un moteur pour jouer aux échecs ou pour faire de la modélisation 3D. C’est très orienté vers des types spécifiques de problèmes.
Kieran Chandler: D’accord, donc ce que vous dites, c’est que c’est beaucoup plus simple d’utiliser Envision plutôt qu’un autre langage de programmation ?
Joannes Vermorel: Exactement. Je veux dire, écrire un script qui traite des tables contenant plusieurs milliards de lignes pour effectuer le type d’analyse que l’on attendrait dans un contexte de supply chain, comme estimer le coût et l’impact des ruptures de stock sur un vaste réseau au cours des trois dernières années, est quelque chose que vous pourriez faire littéralement avec une douzaine de lignes de code. Mais un code qui est facile à écrire. Quand je dis facile à écrire, je veux dire que ce n’est jamais aussi facile d’écrire du code, mais ce n’est pas plus difficile que, disons, écrire une feuille Excel avancée qui fait des moyennes sophistiquées, des tris sophistiqués et des recherches sophistiquées sur les données.
Kieran Chandler: D’accord, et quelles ont été certaines des idées clés et des avancées qui ont conduit à ces améliorations ?
Joannes Vermorel: Juste pour comprendre d’où nous partions, il y a un an, Lokad avait déjà de nombreux éléments de big data en place. L’un d’entre eux est d’avoir une approche colonne pour le stockage des données. En résumé, 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 stockée ensemble, et c’est votre unité. Fondamentalement, cela rend les bases de données tabulaires très efficaces pour effectuer de petites mises à jour ou des lectures/écritures ligne par ligne.
En revanche, au cours des dernières décennies, chaque fois que vous voulez effectuer une analyse de données volumineuses, ce qui a été développé est une approche colonne. Donc, fondamentalement, lorsque vous avez une table, disons que vous avez 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 unitaire et j’ai la quantité. Disons que vous avez une table qui représente l’historique des ventes. Maintenant, vous voulez connaître le montant total des ventes, que devez-vous faire ? Vous devez multiplier le prix par la quantité et faire la somme de tout cela dans la table.” Eh bien, il se trouve que votre table peut avoir 20 colonnes, mais l’opération que je viens de décrire ne touche que deux colonnes. Donc, si vous avez un stockage par colonne, le principal avantage est que chaque opération qui ne touche que quelques colonnes, ces quelques colonnes seront traitées et le reste peut être simplement ignoré. Si vous avez un format tabulaire, eh bien, les autres colonnes sont toujours complètement au milieu 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, si vous adoptez une approche colonne, si vous ajoutez une ligne, vous devez travailler avec chaque colonne.
Kieran Chandler: Donc, lorsque vous ajoutez une ligne, vous devez toucher 20 colonnes, ce qui le rend relativement inefficace. Le stockage par colonne est plus adapté à l’analyse par lots, pas exactement en temps réel, mais plutôt le type d’analyse qui vous intéresse pour la supply chain. Il peut être actualisé toutes les minutes, 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 de la scalabilité en téraoctets a-t-elle affecté les coûts de travail avec les données ?
Joannes Vermorel: En fait, beaucoup. Les ressources les plus coûteuses lorsque vous essayez d’optimiser une supply chain à grande échelle sont les supply chain scientists. Ces personnes ne sont pas gratuites et il est difficile de trouver et de former des individus ayant le bon talent. La ressource rare n’est pas les CPU, les disques ou la bande passante, qui peuvent être construits à moindre coût à partir de votre plateforme de cloud computing préférée, mais plutôt les personnes talentueuses avec lesquelles vous devez travailler sur 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 certain temps, 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 scientists, cela signifie qu’ils peuvent rester concentrés sur la tâche, obtenir les résultats et passer à autre chose au lieu d’attendre bloqués pour les résultats. Donc, si quoi que ce soit, c’est une mauvaise nouvelle pour nos supply chain scientists car ils ont moins de pauses café.
Kieran Chandler: Que signifie cette avancée pour le monde réel ? Évidemment, nous sommes capables de travailler avec des ensembles de données beaucoup plus importants et de travailler avec eux beaucoup plus rapidement, mais y a-t-il d’autres avantages que nous constatons ?
Joannes Vermorel: Oui, l’un des dangers clés, ou causes profondes de l’échec des initiatives de la supply chain quantitative, est le temps nécessaire pour le faire correctement, pour le faire fonctionner et le rendre complètement abouti afin de ne pas avoir de cas particuliers persistants. Avec la capacité de traiter des ensembles de données plus importants plus rapidement, nous pouvons maintenant résoudre ces problèmes de manière plus efficace, ce qui conduit finalement à de meilleures décisions en matière de supply chain.
Kieran Chandler: Vos systèmes sont bons, mais il y a encore une personne qui reste 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 contredit quelque peu l’objectif d’avoir une automatisation avancée de l’apprentissage automatique pour l’optimisation. Le danger est que le processus d’élimination de tous les cas particuliers, pour affiner réellement la recette numérique de prise de décision, puisse prendre trop de temps.
Joannes Vermorel: Oui, et ce retard est mortel 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’il y ait une mise à niveau ERP en cours de route. Vous commencez à optimiser la supply chain, puis il y a un changement massif dans l’idée de l’entreprise. Une grande partie de ce que vous avez fait s’effondre simplement parce que tous les systèmes sont en train d’être modifiés.
Plus vous attendez, plus de choses peuvent perturber votre projet. L’entreprise elle-même peut subir une transformation radicale qui rend votre travail antérieur obsolète à la lumière des nouveaux changements commerciaux. Il y a beaucoup de forces motrices qui mettent la 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 touchez 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: Donc, ce que vous abordez là, 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 l’apprentissage profond pour apprendre et obtenir une bonne prévision et de bons résultats ?
Joannes Vermorel: La réalité a un moyen de se mettre en travers de votre chemin. La supply chain consiste vraiment à gérer les aléas du monde réel. Il y a tellement de cas particuliers qui émergent simplement de la réalité elle-même. Par exemple, vous commencez à calculer une quantité idéale à commander, disons 80 unités. C’est la meilleure quantité à commander, mais les palettes ne viennent qu’en zéro unité ou 100 unités car elles sont emballées sur une palette. 80 n’est pas une option, que faites-vous ?
Il y a des dizaines de situations comme celle-ci. Vous pourriez penser que la valeur de votre inventaire diminue 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 votre inventaire passe de quelque chose à zéro, voire négative, car vous devez maintenant payer pour vous débarrasser de cet inventaire sans valeur.
La réalité est que les supply chains sont complexes. Si nous parlons d’entreprises qui opèrent sur de nombreux marchés, dans plusieurs pays, avec de nombreux fournisseurs, potentiellement des dizaines de lignes de produits, il y a beaucoup de complications. Il est illusoire de croire que vous pouvez simplement vous asseoir dans une pièce et réfléchir avec l’équipe à tous les défis techniques qui surgiront avec les initiatives. Vous ne pouvez pas simplement dire… Asseyez-vous avec votre équipe de supply chain et dites, listons toutes les petites choses qui vont dérailler la recette numérique qui génère les décisions optimisées de la supply chain. La réalité, comme toujours, a un moyen de vous surprendre car vous allez découvrir des choses bizarres comme un certain pays ayant une étrange taxe sur quelque chose, par exemple. Pour revenir à votre question initiale sur l’approche itérative, la seule façon de faire face à ce flux incessant de surprises est d’être extrêmement agile pour corriger votre recette numérique lorsque vous êtes confronté à quelque chose d’inattendu.
Kieran Chandler: Maintenant, concentrons-nous sur la scalabilité des téraoctets et commençons à rassembler les choses. Comment cela change-t-il les perspectives de Lokad et que cela signifie-t-il pour l’avenir ?
Joannes Vermorel: Nous avons réalisé d’énormes améliorations en termes de scalabilité du traitement. Ce développement ouvre de nombreuses possibilités qui nous étaient auparavant inaccessibles. Il ne s’agit pas seulement de traiter avec de plus grandes entreprises, il y a plein de façons de tricher, par exemple. Prenons en compte un grand réseau de vente au détail. Si votre approche pour optimiser un réseau de vente au détail à grande échelle consiste à traiter chaque marché de manière isolée, et si vous avez, disons, 200 marchés, vous n’auriez besoin que de 200 machines, une par marché, et cela serait scalable. Mais cette méthode ne permettra pas d’obtenir l’amélioration de la supply chain que vous recherchez car vous n’optimisez pas au niveau du réseau. Vous optimisez localement chaque magasin de manière isolée, en 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 indépendants, il est très facile de mettre à l’échelle votre traitement. Mais le défi se pose lorsque vous commencez à considérer votre réseau comme une entité où tout est connecté. Vous pouvez réellement expédier des stocks et des matériaux à travers le réseau de presque n’importe quelle manière. Bien qu’il existe de nombreuses façons qui ne sont pas rentables et n’ont aucun sens, c’est possible. Et certaines de ces subtilités pourraient être de très bonnes idées et rentables. Vous avez besoin d’un système qui peut tout traiter en une seule fois, de manière monolithique. Qu’est-ce que cela signifie pour l’avenir ? Cela signifie que cela ouvre de nombreuses possibilités pour une meilleure optimisation holistique. La malédiction de l’optimisation de la supply chain est que vous ne résolvez pas les problèmes ; vous les déplacez simplement. Vous pouvez regarder une zone et l’optimiser, mais tout ce que vous faites, c’est déplacer le problème plus loin dans la chaîne ou le renvoyer au fournisseur. Une autre possibilité est que maintenant que nous avons considérablement gagné en scalabilité, nous essaierons probablement de revenir à l’expressivité. Fondamentalement, nous cherchons à exprimer de manière plus directe et fluide les situations complexes qui se produisent dans le monde réel dans ces scripts Envision. De cette façon, il est plus facile de fournir des recettes numériques qui correspondent bien aux situations réelles.
Kieran Chandler: Cela semble génial. Nous devons conclure ici, mais merci pour votre temps aujourd’hui. C’est tout pour cette semaine. Merci beaucoup de nous avoir regardés et à la prochaine fois. Au revoir pour le moment.
