PARADIGMES DE PROGRAMMATION POUR LA SUPPLY CHAIN (RÉSUMÉ DE LA LECTURE 1.4)

Les problèmes de la supply chain sont complexes et tenter de les résoudre sans les outils de programmation appropriés - dans le contexte d’une entreprise à grande échelle - s’avère une expérience d’apprentissage coûteuse. L’optimisation efficace de la supply chain - un réseau éparpillé de complexités physiques et abstraites - nécessite une série de paradigmes de programmation modernes, agiles et innovants qui sont essentiels pour l’identification, la prise en compte et la résolution réussie de la vaste gamme de problèmes inhérents à la supply chain.

Regarder la Conférence

Analyse Statique

On n’a pas besoin d’être un programmeur pour penser comme un, et une analyse appropriée des problèmes de la supply chain est mieux abordée avec une mentalité de programmation, pas seulement des outils de programmation. Les solutions logicielles traditionnelles (telles que les ERP) sont conçues de manière à ce que les problèmes soient résolus au moment de l’exécution plutôt qu’au moment de la compilation¹.

C’est la différence entre une solution réactive et une solution proactive. Cette distinction est cruciale car les solutions réactives tendent à être beaucoup plus coûteuses que les solutions proactives, tant sur le plan financier que sur le plan de la bande passante. Ces coûts largement évitables sont précisément ce que vise à éviter une mentalité de programmation, et l’analyse statique est l’expression de ce cadre.

L’analyse statique consiste à inspecter un programme (dans ce cas, l’optimisation) sans l’exécuter, afin d’identifier les problèmes potentiels avant qu’ils n’affectent la production. Lokad aborde l’analyse statique à travers Envision, son langage spécifique au domaine (DSL). Cela permet d’identifier et de corriger les erreurs au niveau de la conception (dans le langage de programmation) aussi rapidement et facilement que possible.

Considérons une entreprise en train de construire un entrepôt. On ne construit pas d’abord l’entrepôt et ensuite on réfléchit à son agencement. Au contraire, l’arrangement stratégique des allées, des rayonnages et des quais de chargement serait envisagé à l’avance, afin d’identifier les goulots d’étranglement potentiels avant la construction. Cela permet une conception optimale - et donc un flux optimal - dans l’entrepôt futur. Ce plan minutieux est analogue à la forme d’analyse statique que Lokad réalise grâce à Envision.

L’analyse statique, telle que décrite ici, modéliserait la programmation sous-jacente de l’optimisation et identifierait tout comportement potentiellement antagoniste dans la recette avant de l’installer. Ces tendances antagonistes pourraient inclure un bogue qui entraîne la commande accidentelle de beaucoup plus de stock que nécessaire. Par conséquent, de tels bogues seraient éliminés du code avant d’avoir la chance de semer le chaos.

Programmation en tableau

Dans l’optimisation de la supply chain, le respect des délais est essentiel. Par exemple, dans une chaîne de vente au détail, les données doivent être consolidées, optimisées et transmises au système de gestion d’entrepôt dans une fenêtre de 60 minutes. Si les calculs prennent trop de temps, l’exécution de toute la supply chain peut être compromise. La programmation en tableau résout ce problème en éliminant certaines classes d’erreurs de programmation et en garantissant la durée des calculs, offrant ainsi aux praticiens de la supply chain un horizon temporel prévisible pour le traitement des données.

Également connue sous le nom de programmation de trames de données, cette approche permet d’effectuer des opérations directement sur des tableaux de données, plutôt que sur des données isolées. Lokad le fait en exploitant Envision, son DSL. La programmation en tableau peut simplifier la manipulation et l’analyse des données, par exemple en effectuant des opérations sur des colonnes entières de données plutôt que sur des entrées individuelles dans chaque table. Cela augmente considérablement l’efficacité de l’analyse et réduit ainsi les chances d’erreurs de programmation.

Considérons un responsable d’entrepôt qui dispose de deux listes : la liste A contient les niveaux de stock actuels, et la liste B contient les expéditions entrantes pour les produits de la liste A. Au lieu de passer en revue chaque produit un par un et d’ajouter manuellement les expéditions entrantes (liste B) aux niveaux de stock actuels (liste A), une méthode plus efficace consisterait à traiter les deux listes simultanément, ce qui vous permettrait de mettre à jour les niveaux de stock pour tous les produits en une seule fois. Cela permettrait de gagner du temps et des efforts, et c’est essentiellement ce que cherche à faire la programmation en tableau².

En réalité, la programmation en tableau facilite la parallélisation et la distribution du calcul des vastes quantités de données impliquées dans l’optimisation de la supply chain. En répartissant le calcul sur plusieurs machines, les coûts peuvent être réduits et les temps d’exécution raccourcis.

Compatibilité matérielle

L’un des principaux obstacles à l’optimisation de la supply chain est le nombre limité de scientifiques de la supply chain. Ces scientifiques sont responsables de la création de recettes numériques qui prennent en compte les stratégies des clients, ainsi que les manœuvres antagonistes des concurrents, afin de produire des informations exploitables.

Non seulement ces experts peuvent être difficiles à trouver, mais une fois qu’ils le sont, ils doivent souvent surmonter plusieurs obstacles matériels qui les séparent de l’exécution rapide de leurs tâches. La compatibilité matérielle - la capacité des différents composants d’un système à se mélanger et à fonctionner ensemble - est essentielle pour éliminer ces obstacles. Trois ressources informatiques fondamentales sont considérées ici :

• Calcul : La puissance de traitement d’un ordinateur, fournie par le CPU ou le GPU.
• Mémoire : La capacité de stockage des données d’un ordinateur, hébergée dans la RAM ou la ROM.
• Bande passante : Le débit maximal auquel les informations (données) peuvent être transférées entre différentes parties d’un ordinateur, ou à travers un réseau d’ordinateurs.

Le traitement de grands ensembles de données est généralement un processus long, ce qui entraîne une productivité plus faible alors que les ingénieurs attendent l’exécution des tâches. Dans une optimisation de la supply chain, on pourrait stocker des extraits de code (représentant des étapes de calcul intermédiaires courantes) sur des disques à semi-conducteurs (SSD). Cette simple étape permet aux scientifiques de la supply chain d’exécuter des scripts similaires avec seulement de légères modifications beaucoup plus rapidement, ce qui augmente considérablement la productivité.

Dans l’exemple ci-dessus, on a utilisé une astuce mémoire bon marché pour réduire la charge de calcul : le système note que le script en cours de traitement est presque identique aux précédents, ce qui permet d’effectuer le calcul en quelques secondes au lieu de plusieurs dizaines de minutes.

Ce type de compatibilité matérielle permet aux entreprises de tirer le meilleur parti de leurs investissements.

Programmation probabiliste

Il existe un nombre infini de résultats futurs possibles, mais ils ne sont pas tous également probables. Étant donné cette incertitude irréductible, les outils de programmation doivent adopter un paradigme de prévision probabiliste. Bien qu’Excel ait historiquement été la base de nombreuses supply chains, il ne peut pas être déployé à grande échelle en utilisant des prévisions probabilistes, car ce type de prévision nécessite la capacité de traiter l’algèbre des variables aléatoires³.

En résumé, Excel est principalement conçu pour des données déterministes (c’est-à-dire des valeurs fixes, telles que des nombres entiers statiques). Bien qu’il puisse être modifié pour effectuer certaines fonctions de probabilité, il lui manque les fonctionnalités avancées - ainsi que la flexibilité et l’expressivité globale - nécessaires pour faire face à la manipulation complexe des variables aléatoires que l’on rencontre dans la prévision de la demande probabiliste. En revanche, un langage de programmation probabiliste - tel qu’Envision - est mieux adapté pour représenter et traiter les incertitudes que l’on rencontre dans la supply chain.

Prenons l’exemple d’un magasin de pièces détachées automobiles qui vend des plaquettes de frein. Dans ce scénario hypothétique, les clients doivent acheter des plaquettes de frein par lots de 2 ou 4 à la fois, et le magasin doit tenir compte de cette incertitude lors de la prévision de la demande.

Si le magasin a accès à un langage de programmation probabiliste (au lieu d’une multitude de feuilles de calcul), il peut estimer beaucoup plus précisément la consommation totale en utilisant l’algèbre des variables aléatoires - généralement absente dans les langages de programmation généraux.

Programmation différentiable

Dans le contexte de l’optimisation de la supply chain, la programmation différentiable permet à la recette numérique d’apprendre et de s’adapter en fonction des données qui lui sont fournies. La programmation différentiable, combinée à une descente de gradient stochastique, permet à un scientifique de la supply chain de découvrir des schémas et des relations complexes au sein de la supply chain. Les paramètres sont appris à chaque nouvelle itération de programmation, et ce processus est répété des milliers de fois. Cela est fait pour minimiser la divergence entre le modèle de prévision actuel et les données passées⁴.

La cannibalisation et la substitution - au sein d’un seul catalogue - sont deux problèmes de modélisation qui méritent d’être examinés dans ce contexte. Dans les deux scénarios, plusieurs produits se disputent les mêmes clients, ce qui présente une couche complexe de complexité de prévision. Les effets en aval de ces forces ne sont généralement pas capturés par les prévisions traditionnelles de séries chronologiques, qui considèrent principalement la tendance, la saisonnalité et le bruit pour un seul produit, sans tenir compte de la possibilité d’interaction(s).

La programmation différentiable et la descente de gradient stochastique peuvent être utilisées pour résoudre ces problèmes, par exemple en analysant les données historiques des transactions liant les clients et les produits. Envision est capable d’effectuer une telle analyse - appelée analyse d’affinité - entre les clients et les achats en lisant des fichiers plats simples contenant une profondeur historique suffisante : transactions, dates, produits, clients et quantités d’achat⁵.

En utilisant seulement quelques lignes de code, Envision peut déterminer l’affinité entre un client et un produit, ce qui permet au scientifique de la supply chain d’optimiser davantage la recette numérique qui fournit la recommandation d’intérêt⁶.

Versioning du code et des données

Un élément négligé de la viabilité de l’optimisation à long terme est de s’assurer que la recette numérique - y compris chaque extrait de code et chaque donnée - peut être sourcée, suivie et reproduite⁷. Sans cette capacité de versioning, la capacité de rétro-ingénierie de la recette est grandement réduite lorsque des exceptions frustrantes se produisent inévitablement (heisenbugs dans les cercles informatiques).

Les heisenbugs sont des exceptions gênantes qui causent des problèmes dans les calculs d’optimisation, mais disparaissent lorsque le processus est relancé. Cela peut les rendre extraordinairement difficiles à résoudre, ce qui entraîne l’échec de certaines initiatives et le retour à des feuilles de calcul Excel pour la supply chain. Pour éviter les heisenbugs, il est nécessaire de pouvoir reproduire intégralement la logique et les données de l’optimisation. Cela nécessite de versionner tout le code et les données utilisés dans le processus, en veillant à ce que l’environnement puisse être reproduit dans les mêmes conditions qu’à n’importe quel point antérieur dans le temps.

Programmation sécurisée

Au-delà des heisenbugs indésirables, la numérisation accrue de la supply chain entraîne une vulnérabilité conséquente aux menaces numériques, telles que les cyberattaques et les rançongiciels. Il existe deux vecteurs principaux - généralement involontaires - de chaos à cet égard : le(s) système(s) programmable(s) que l’on utilise et les personnes que l’on autorise à les utiliser. En ce qui concerne ces dernières, il est très difficile de tenir compte de l’incompétence accidentelle (sans parler des actes de malveillance intentionnelle) ; en ce qui concerne les premiers, les choix intentionnels de conception sont primordiaux pour contourner ces mines terrestres.

Plutôt que d’investir des ressources précieuses dans l’augmentation de l’équipe de sécurité informatique (en prévision d’un comportement réactif, tel que la lutte contre les incendies), des décisions prudentes lors de la phase de conception du système de programmation peuvent éliminer des classes entières de maux de tête en aval. En supprimant les fonctionnalités redondantes - comme une base de données SQL dans le cas de Lokad - on peut prévenir des catastrophes prévisibles - comme une attaque par injection SQL. De même, opter pour des couches de persistance en mode ajout uniquement (comme le fait Lokad) rend la suppression de données (par un ami ou un ennemi) beaucoup plus difficile⁸.

Bien qu’Excel et Python aient leurs avantages, ils ne disposent pas de la sécurité de programmation nécessaire pour protéger tout le code et les données nécessaires au type d’optimisation de la supply chain évolutive discuté dans ces conférences.

Notes