Prévision des délais de livraison - Cours 5.3

00:00 Introduction
02:55 Le cas des délais de livraison
09:25 Délais de livraison du monde réel (1/3)
12:13 Délais de livraison du monde réel (2/3)
13:44 Délais de livraison du monde réel (3/3)
16:12 L’histoire jusqu’à présent
19:31 ETA : dans 1 heure
22:16 CPRS (récapitulatif) (1/2)
23:44 CPRS (récapitulatif) (2/2)
24:52 Validation croisée (1/2)
27:00 Validation croisée (2/2)
27:40 Lissage des délais de livraison (1/2)
31:29 Lissage des délais de livraison (2/2)
40:51 Composition du délai de livraison (1/2)
44:19 Composition du délai de livraison (2/2)
47:52 Délai de livraison quasi saisonnier
54:45 Modèle de délai de livraison log-logistique (1/4)
57:03 Modèle de délai de livraison log-logistique (2/4)
01:00:08 Modèle de délai de livraison log-logistique (3/4)
01:03:22 Modèle de délai de livraison log-logistique (4/4)
01:05:12 Modèle de délai de livraison incomplet (1/4)
01:08:04 Modèle de délai de livraison incomplet (2/4)
01:09:30 Modèle de délai de livraison incomplet (3/4)
01:11:38 Modèle de délai de livraison incomplet (4/4)
01:14:33 Demande sur le délai de livraison (1/3)
01:17:35 Demande sur le délai de livraison (2/3)
01:24:49 Demande sur le délai de livraison (3/3)
01:28:27 Modularité des techniques prédictives
01:31:22 Conclusion
01:32:52 Prochain cours et questions du public

Description

Les délais de livraison sont un aspect fondamental de la plupart des situations de la supply chain. Les délais de livraison peuvent et doivent être prévus, tout comme la demande. Des modèles de prévision probabilistes, dédiés aux délais de livraison, peuvent être utilisés. Une série de techniques est présentée pour élaborer des prévisions probabilistes de délai de livraison à des fins de supply chain. Combiner ces prévisions, délai de livraison et demande, est un élément essentiel de la modélisation prédictive en supply chain.

Transcription complète

Bienvenue dans cette série de cours sur la supply chain. Je suis Joannes Vermorel et aujourd’hui je vais présenter “Prévision des délais de livraison”. Les délais de livraison, et plus généralement tous les retards applicables, sont un aspect fondamental de la supply chain lorsqu’il s’agit d’équilibrer l’offre et la demande. Il faut tenir compte des délais impliqués. Par exemple, considérons la demande pour un jouet. L’anticipation correcte du pic saisonnier de la demande avant Noël n’a pas d’importance si les marchandises sont reçues en janvier. Les délais de livraison régissent les détails de la planification autant que la demande.

Les délais de livraison varient ; ils varient beaucoup. C’est un fait, et je vais présenter quelques preuves dans un instant. Cependant, à première vue, cette proposition est déconcertante. Il n’est pas clair pourquoi les délais de livraison devraient varier autant en premier lieu. Nous disposons de processus de fabrication qui peuvent fonctionner avec moins d’un micromètre de tolérance. De plus, dans le cadre du processus de fabrication, nous pouvons contrôler un effet, par exemple l’application d’une source de lumière, jusqu’à une microseconde. Si nous pouvons contrôler la transformation de la matière jusqu’au micromètre et jusqu’à la microseconde, avec suffisamment de dévouement, nous devrions être en mesure de contrôler le flux des demandes avec un degré de précision comparable. Ou peut-être pas.

Cette façon de penser pourrait expliquer pourquoi les délais de livraison semblent être si peu appréciés dans la littérature sur la supply chain. Les livres sur la supply chain et, par conséquent, les logiciels de supply chain ne reconnaissent guère l’existence des délais de livraison au-delà de les introduire en tant que paramètre d’entrée pour leur modèle d’inventaire. Pour ce cours, il y aura trois objectifs :

Nous voulons comprendre l’importance et la nature des délais de livraison. Nous voulons comprendre comment les délais de livraison peuvent être prévus, avec un intérêt particulier pour les modèles probabilistes qui nous permettent d’embrasser l’incertitude. Nous voulons combiner les prévisions de délai de livraison avec les prévisions de demande de manière intéressante pour la supply chain.

Selon la littérature dominante sur la supply chain, les délais de livraison ne valent guère plus qu’une ou deux notes de bas de page. Cette affirmation peut sembler exagérée, mais je crains que ce ne soit pas le cas. Selon Google Scholar, un moteur de recherche spécialisé dans la littérature scientifique, la requête “prévision de la demande” pour l’année 2021 renvoie 10 500 articles. Un examen rapide des résultats indique que la grande majorité de ces entrées traitent en effet de la prévision de la demande dans toutes sortes de situations et de marchés. La même requête, également pour l’année 2021, sur Google Scholar pour “prévision des délais de livraison” renvoie 71 résultats. Les résultats de la requête de prévision des délais de livraison sont si limités qu’il ne faut que quelques minutes pour passer en revue une année entière de recherche.

Il s’avère qu’il n’y a qu’une douzaine d’entrées qui traitent réellement de la prévision des délais de livraison. En effet, la plupart des correspondances se trouvent dans des expressions comme “prévision de longs délais de livraison” ou “prévision de courts délais de livraison” qui font référence à une prévision de la demande, et non à une prévision des délais de livraison. Il est possible de répéter cet exercice avec “prédiction de la demande” et “prédiction des délais de livraison” et d’autres expressions similaires et d’autres années. Ces variations donnent des résultats similaires. Je laisserai cela comme exercice au public.

Ainsi, en estimation approximative, nous avons environ mille fois plus d’articles sur la prévision de la demande que sur la prévision des délais de livraison. Les livres sur la supply chain et les logiciels de supply chain suivent le mouvement, reléguant les délais de livraison au rang de citoyen de seconde classe et d’aspect insignifiant. Cependant, le personnel de la supply chain qui a été présenté dans cette série de cours raconte une histoire différente. Ce personnel peut représenter des entreprises fictives, mais il reflète des archétypes de la supply chain. Ils nous parlent de la sorte de situation qui devrait être considérée comme typique. Voyons ce que ce personnel nous dit en ce qui concerne les délais de livraison.

Paris est une marque de mode fictive qui exploite son propre réseau de vente au détail. Paris passe des commandes auprès de fournisseurs étrangers, avec des délais de livraison longs et parfois supérieurs à six mois. Ces délais de livraison ne sont que partiellement connus, et pourtant la nouvelle collection doit arriver en magasin au bon moment tel que défini par l’opération marketing associée à la nouvelle collection. Les délais de livraison des fournisseurs nécessitent une anticipation appropriée ; en d’autres termes, ils nécessitent une prévision.

Amsterdam est une entreprise fictive de produits de grande consommation spécialisée dans la production de fromages, de crèmes et de beurre. Le processus d’affinage du fromage est connu et maîtrisé, mais il varie, avec des écarts de quelques jours. Pourtant, quelques jours correspondent précisément à la durée des promotions intenses déclenchées par les chaînes de vente au détail qui se trouvent être le principal canal de vente d’Amsterdam. Ces délais de fabrication nécessitent une prévision.

Miami est une entreprise fictive de maintenance, de réparation et de révision (MRO) de l’aviation. Chaque avion de ligne a besoin de milliers de pièces chaque année pour continuer à voler. Une seule pièce manquante risque d’immobiliser l’avion. La durée de réparation d’une pièce réparable, également appelée temps de rotation (TAT), définit quand la pièce réparable redevient utilisable. Cependant, le TAT varie de quelques jours à plusieurs mois, en fonction de l’ampleur des réparations, qui ne sont pas connues au moment où la pièce est retirée de l’avion. Ces TAT nécessitent une prévision.

San Jose est une entreprise fictive de commerce électronique qui distribue une variété de meubles et d’accessoires pour la maison. Dans le cadre de son service, San Jose s’engage à fournir une date de livraison pour chaque transaction. Cependant, la livraison elle-même dépend d’entreprises tierces qui sont loin d’être parfaitement fiables. Ainsi, San Jose a besoin d’une estimation éclairée de la date de livraison qui peut être promise pour chaque transaction. Cette estimation éclairée est implicitement une prévision des délais de livraison.

Enfin, Stuttgart est une entreprise fictive du marché secondaire de l’automobile. Elle exploite des succursales qui effectuent des réparations de voitures. Le prix d’achat le plus bas des pièces automobiles peut être obtenu auprès de grossistes qui proposent des délais de livraison longs et quelque peu irréguliers. Il existe des fournisseurs plus fiables mais plus chers et plus proches. Choisir le bon fournisseur pour chaque pièce nécessite une analyse comparative appropriée des délais de livraison respectifs associés à différents fournisseurs.

Comme nous pouvons le voir, chaque personnel de la chaîne d’approvisionnement présenté jusqu’à présent nécessite l’anticipation d’au moins un, et souvent plusieurs, délais de livraison. Bien qu’on puisse soutenir que la prévision de la demande nécessite plus d’attention et d’efforts que la prévision des délais de livraison, au final, les deux sont nécessaires pour presque toutes les situations de chaîne d’approvisionnement.

Ainsi, examinons quelques délais de livraison réels dans le monde réel. À l’écran se trouvent trois histogrammes qui ont été tracés en compilant les délais de livraison observés associés à trois pièces mécaniques. Ces pièces sont commandées auprès du même fournisseur situé en Europe occidentale. Les commandes proviennent d’une entreprise également située en Europe occidentale. L’axe des x indique la durée des délais de livraison observés exprimée en jours, et l’axe des y indique le nombre d’observations exprimé en pourcentage. Dans la suite, tous les histogrammes adopteront les mêmes conventions, avec l’axe des x associé à des durées exprimées en jours et l’axe des y reflétant la fréquence. À partir de ces trois distributions, nous pouvons déjà faire quelques observations.

Premièrement, les données sont rares. Nous n’avons que quelques dizaines de points de données, et ces observations ont été recueillies sur plusieurs années. Cette situation est typique ; si l’entreprise ne passe commande qu’une fois par mois, il faut près d’une décennie pour recueillir plus de 100 observations de délais de livraison. Ainsi, quoi que nous fassions en termes de statistiques, cela devrait être orienté vers les petits nombres plutôt que les grands nombres. En effet, nous aurons rarement le luxe de traiter avec de grands nombres.

Deuxièmement, les délais de livraison sont erratiques. Nous avons des observations allant de quelques jours à un trimestre. Bien qu’il soit toujours possible de calculer un délai de livraison moyen, il serait imprudent de se fier à une valeur moyenne quelconque pour l’une de ces pièces. Il est également clair que aucune de ces distributions n’est même vaguement normale.

Troisièmement, nous avons trois pièces qui sont plus ou moins comparables en taille et en prix, et pourtant les délais de livraison varient beaucoup. Bien qu’il puisse être tentant de regrouper ces observations pour rendre les données moins rares, il est évidemment imprudent de le faire, car cela mélangerait des distributions qui sont très différentes. Ces distributions n’ont pas la même moyenne, la même médiane, ni même le même minimum ou maximum.

Jetons un coup d’œil à un deuxième lot de délais de livraison. Ces durées reflètent le temps nécessaire pour réparer trois pièces d’avion distinctes. La première distribution semble avoir deux modes plus une queue. Lorsqu’une distribution présente deux modes, cela suggère généralement l’existence d’une variable cachée qui explique ces deux modes. Par exemple, il peut y avoir deux types distincts d’opérations de réparation, chaque type étant associé à son propre délai de livraison. La deuxième distribution semble avoir un seul mode plus une queue. Ce mode correspond à une durée relativement courte, d’environ deux semaines. Il peut refléter un processus où la pièce est d’abord inspectée, et parfois la pièce est jugée utilisable sans aucune intervention supplémentaire, d’où un délai beaucoup plus court. La troisième distribution semble être entièrement étalée, sans mode ou queue évidents. Il peut y avoir plusieurs processus de réparation en jeu ici qui sont regroupés. La rareté des données, avec seulement quelques dizaines d’observations, rend difficile d’en dire plus. Nous reviendrons sur cette troisième distribution plus tard dans cette leçon.

Enfin, jetons un coup d’œil à deux délais de livraison reflétant les retards d’expédition de Taïwan vers la côte ouest des États-Unis, que ce soit par avion ou par mer. Sans surprise, les avions cargo sont plus rapides que les navires cargo. La deuxième distribution semble suggérer qu’il arrive parfois qu’un envoi par mer manque son navire d’origine, puis soit expédié avec le prochain navire, ce qui double presque le délai. Le même phénomène pourrait se produire avec l’envoi par avion, bien que les données soient si limitées que ce ne soit qu’une supposition. Soulignons que n’avoir accès qu’à quelques observations n’est pas inhabituel en ce qui concerne les délais de livraison. Ces situations sont fréquentes. Il est important de garder à l’esprit que dans cette leçon, nous cherchons des outils et des instruments qui nous permettent de travailler avec les données de délai de livraison dont nous disposons, même avec seulement quelques observations, et non pas avec les données de délai de livraison que nous souhaiterions avoir, comme des milliers d’observations. Les écarts courts dans les deux distributions suggèrent également un schéma cyclique jour de la semaine, bien que la visualisation de l’histogramme actuelle ne soit pas appropriée pour valider cette hypothèse.

À partir de cette brève revue des délais de livraison du monde réel, nous pouvons déjà comprendre certains des phénomènes sous-jacents qui sont en jeu. En effet, les délais de livraison sont très structurés ; les retards ne se produisent pas sans raison, et ces causes peuvent être identifiées, décomposées et quantifiées. Cependant, les détails de la décomposition du délai de livraison ne sont souvent pas enregistrés dans les systèmes informatiques, du moins pas encore. Même lorsque l’on dispose d’une décomposition approfondie du délai de livraison observé, comme cela peut être le cas dans certaines industries comme l’aviation, cela ne signifie pas que les délais de livraison peuvent être parfaitement anticipés. Les sous-segments ou les phases à l’intérieur du délai de livraison sont susceptibles de présenter leur propre incertitude irréductible.

Cette série de conférences sur la supply chain présente mes points de vue et mes connaissances à la fois sur l’étude et la pratique de la supply chain. J’essaie de rendre ces conférences quelque peu indépendantes, mais elles ont plus de sens lorsqu’elles sont regardées dans l’ordre. Le reste de cette conférence dépend d’éléments qui ont été précédemment présentés dans cette série, bien que je fournirai un rappel dans une minute.

Le premier chapitre est une introduction générale au domaine et à l’étude de la supply chain. Il clarifie la perspective qui sous-tend cette série de conférences. Comme vous l’avez peut-être déjà deviné, cette perspective diverge considérablement de ce qui serait considéré comme la perspective dominante sur la supply chain.

Le deuxième chapitre présente une série de méthodologies. En effet, la supply chain défie les méthodologies naïves. Les supply chains sont composées de personnes qui ont leurs propres agendas ; il n’y a pas de neutralité dans la supply chain. Ce chapitre aborde ces complications, y compris mon propre conflit d’intérêts en tant que PDG de Lokad, une entreprise de logiciels spécialisée dans l’optimisation prédictive de la supply chain.

Le troisième chapitre présente une série de “personae” de la supply chain. Ces personae sont des entreprises fictives que nous avons brièvement examinées aujourd’hui, et elles sont destinées à représenter des archétypes de situations de supply chain. Le but de ces personae est de se concentrer exclusivement sur les problèmes, en reportant la présentation des solutions.

Le quatrième chapitre passe en revue les sciences auxiliaires de la supply chain. Ces sciences ne concernent pas directement la supply chain en tant que telle, mais elles doivent être considérées comme essentielles pour une pratique moderne de la supply chain. Ce chapitre comprend une progression à travers les couches d’abstraction, en commençant par le matériel informatique jusqu’aux problématiques de cybersécurité.

Le cinquième et présent chapitre est consacré à la modélisation prédictive. La modélisation prédictive est une perspective plus générale que la prévision ; il ne s’agit pas seulement de prévoir la demande. Il s’agit de concevoir des modèles qui peuvent être utilisés pour estimer et quantifier les facteurs futurs de la supply chain qui nous intéresse. Aujourd’hui, nous nous penchons sur les délais de livraison, mais de manière plus générale, dans la supply chain, tout ce qui n’est pas connu avec un degré de certitude raisonnable mérite une prévision.

Le sixième chapitre explique comment les décisions optimisées peuvent être calculées en utilisant des modèles prédictifs, et plus spécifiquement, des modèles probabilistes qui ont été introduits dans le cinquième chapitre. Le septième chapitre revient à une perspective largement non technique afin de discuter de l’exécution réelle d’une initiative de supply chain quantitative.

Aujourd’hui, nous nous concentrons sur les délais de livraison. Nous venons de voir pourquoi les délais de livraison sont importants, et nous venons de passer en revue une courte série de délais de livraison réels. Ainsi, nous aborderons les éléments de la modélisation des délais de livraison. Comme j’adopterai une perspective probabiliste, je réintroduirai brièvement le Continuous Rank Probability Score (CRPS), une mesure pour évaluer la qualité d’une prévision probabiliste. J’introduirai également la validation croisée et une variante de la validation croisée adaptée à notre perspective probabiliste. Avec ces outils en main, nous présenterons et évaluerons notre premier modèle probabiliste non naïf pour les délais de livraison. Les données sur les délais de livraison sont rares, et le premier point à l’ordre du jour est de lisser ces distributions. Les délais de livraison peuvent être décomposés en une série de phases intermédiaires. Ainsi, en supposant que certaines données de délai de livraison décomposées sont disponibles, nous avons besoin de quelque chose pour recomposer ces délais de livraison tout en préservant l’aspect probabiliste.

Ensuite, nous réintroduirons la programmation différentiable. La programmation différentiable a déjà été utilisée dans cette série de cours pour prévoir la demande, mais elle peut également être utilisée pour prévoir les délais de livraison. Nous le ferons, en commençant par un exemple simple destiné à capturer l’impact du Nouvel An chinois sur les délais de livraison, un schéma typique observé lors de l’importation de marchandises d’Asie.

Nous poursuivrons ensuite avec un modèle probabiliste paramétrique pour les délais de livraison, en utilisant la distribution log-logistique. Là encore, la programmation différentiable sera essentielle pour apprendre les paramètres du modèle. Nous étendrons ensuite ce modèle en tenant compte des observations de délai de livraison incomplètes. En effet, même les bons de commande qui ne sont pas encore finalisés nous donnent des informations sur le délai de livraison.

Enfin, nous réunirons une prévision probabiliste des délais de livraison et une prévision probabiliste de la demande dans une seule situation de réapprovisionnement des stocks. Ce sera l’occasion de démontrer pourquoi la modularité est une préoccupation essentielle en matière de modélisation prédictive, plus importante encore que les détails des modèles eux-mêmes.

Dans la leçon 5.2 sur la prévision probabiliste, nous avons déjà introduit certains outils pour évaluer la qualité d’une prévision probabiliste. En effet, les métriques de précision habituelles comme l’erreur quadratique moyenne ou l’erreur absolue moyenne ne s’appliquent qu’aux prévisions ponctuelles, pas aux prévisions probabilistes. Pourtant, ce n’est pas parce que nos prévisions deviennent probabilistes que la précision au sens général devient sans importance. Nous avons simplement besoin d’un instrument statistique qui se trouve être compatible avec la perspective probabiliste.

Parmi ces instruments, il y a le Score de Probabilité de Rang Continu (CRPS). La formule est donnée à l’écran. Le CRPS est une généralisation de la métrique L1, c’est-à-dire l’erreur absolue, mais pour les distributions de probabilité. La saveur habituelle du CRPS compare une distribution, nommée F ici, avec une observation, nommée X ici. La valeur obtenue à partir de la fonction CRPS est homogène à l’observation. Par exemple, si X est un délai de livraison exprimé en jours, alors la valeur CRPS est également exprimée en jours.

Le CRPS peut être généralisé pour la comparaison de deux distributions. C’est ce qui est fait à l’écran. Il s’agit simplement d’une variation mineure de la formule précédente. L’essence de cette métrique reste inchangée. Si F est la vraie distribution des délais de livraison et F_hat est une estimation de la distribution des délais de livraison, alors le CRPS est exprimé en jours. Le CRPS reflète la quantité de différence entre les deux distributions. Le CRPS peut également être interprété comme la quantité minimale d’énergie nécessaire pour transporter toute la masse de la première distribution de manière à ce qu’elle prenne la forme exacte de la deuxième distribution.

Nous disposons maintenant d’un instrument pour comparer deux distributions de probabilité unidimensionnelles. Cela deviendra intéressant dans un instant lorsque nous introduirons notre premier modèle probabiliste pour les délais de livraison.

Avoir une métrique pour mesurer la qualité d’une prévision probabiliste n’est pas tout à fait suffisant. La métrique mesure la qualité sur les données que nous avons ; cependant, ce que nous voulons vraiment, c’est être en mesure d’évaluer la qualité de notre prévision sur des données que nous n’avons pas. En effet, ce sont les délais de livraison futurs qui nous intéressent, pas les délais de livraison qui ont déjà été observés dans le passé. Notre capacité à modéliser pour qu’un modèle performe bien sur les données que nous n’avons pas s’appelle la généralisation. La validation croisée est une technique générale de validation de modèle précisément destinée à évaluer la capacité d’un modèle à bien généraliser.

Dans sa forme la plus simple, la validation croisée consiste à partitionner les observations en un petit nombre de sous-ensembles. Pour chaque itération, un sous-ensemble est mis de côté et appelé sous-ensemble de test. Le modèle est ensuite généré ou entraîné sur les autres sous-ensembles de données, appelés sous-ensembles d’entraînement. Après l’entraînement, le modèle est validé par rapport au sous-ensemble de test. Ce processus est répété un certain nombre de fois, et la bonté moyenne obtenue sur toutes les itérations représente le résultat final de la validation croisée.

La validation croisée est rarement utilisée dans le contexte de la prévision des séries temporelles en raison de la dépendance temporelle entre les observations. En effet, la validation croisée, telle que présentée précédemment, suppose que les observations sont indépendantes. Lorsque des séries temporelles sont impliquées, on utilise plutôt le backtesting. Le backtesting peut être considéré comme une forme de validation croisée qui tient compte de la dépendance temporelle.

La technique de validation croisée comporte de nombreuses variantes qui reflètent un vaste éventail d’angles potentiels qui peuvent nécessiter d’être abordés. Nous n’examinerons pas ces variantes dans le cadre de cette présentation. J’utiliserai une variante spécifique où, à chaque découpage, le sous-ensemble d’entraînement et le sous-ensemble de test ont à peu près la même taille. Cette variante est introduite pour traiter la validation d’un modèle probabiliste, comme nous le verrons avec du code dans une minute.

Revisitons l’un des délais de livraison réels que nous avons déjà vus à l’écran. À gauche, l’histogramme est associé aux troisièmes distributions de temps de réparation de l’aviation. Il s’agit des mêmes observations que celles vues précédemment, et l’histogramme a simplement été étiré verticalement. Ce faisant, les deux histogrammes à gauche et à droite partagent la même échelle. Pour l’histogramme de gauche, nous avons environ 30 observations. Ce n’est pas beaucoup, mais c’est déjà plus que ce que nous aurons fréquemment.

L’histogramme de gauche est appelé distribution empirique. C’est littéralement l’histogramme brut tel qu’obtenu à partir des observations. L’histogramme a un compartiment pour chaque durée exprimée en nombre entier de jours. Pour chaque compartiment, nous comptons le nombre de délais de livraison observés. En raison de la rareté, la distribution empirique ressemble à un code-barres.

Il y a un problème ici. Si nous avons deux délais de livraison observés exactement à 50 jours, est-il logique de dire que la probabilité d’observer soit 49 jours, soit 51 jours est exactement zéro ? Non. De toute évidence, il y a un spectre de durées en cours ; nous n’avons tout simplement pas suffisamment de points de données pour observer la véritable distribution sous-jacente, qui est très probablement beaucoup plus régulière que cette distribution en forme de code-barres.

Ainsi, lorsqu’il s’agit de lisser cette distribution, il existe un nombre indéfini de façons d’effectuer cette opération de lissage. Certaines méthodes de lissage peuvent sembler bonnes mais ne sont pas statistiquement fiables. Comme point de départ, nous aimerions nous assurer qu’un modèle lissé est plus précis que le modèle empirique. Il s’avère que nous avons déjà introduit deux instruments, le CRPS et la validation croisée, qui nous permettront de le faire.

Dans une minute, les résultats sont affichés. L’erreur CRPS associée à la distribution en forme de code-barres est de 1,6 jours, tandis que l’erreur CRPS associée à la distribution lissée est de 1,4 jours. Ces deux chiffres ont été obtenus grâce à la validation croisée. L’erreur plus faible indique que, dans le sens du CRPS, la distribution de droite est la plus précise des deux. La différence de 0,2 entre 1,4 et 1,6 n’est pas énorme ; cependant, la propriété clé ici est que nous avons une distribution lissée qui ne laisse pas de manière erratique certaines durées intermédiaires avec une probabilité nulle. Cela est raisonnable, car notre compréhension des réparations nous dit que ces durées finiraient très probablement par se produire si les réparations sont répétées. Le CRPS ne reflète pas la véritable profondeur de l’amélioration que nous venons d’apporter en lissant la distribution. Cependant, au moins, la réduction du CRPS confirme que cette transformation est raisonnable d’un point de vue statistique.

Jetons maintenant un coup d’œil au code source qui a produit ces deux modèles et affiché ces deux histogrammes. Dans l’ensemble, cela est réalisé en 12 lignes de code si l’on exclut les lignes vides. Comme d’habitude dans cette série de conférences, le code est écrit en Envision, le langage de programmation spécifique au domaine de Lokad dédié à l’optimisation prédictive des chaînes d’approvisionnement. Cependant, il n’y a pas de magie ; cette logique aurait pu être écrite en Python. Mais pour le type de problèmes que nous considérons dans cette conférence, Envision est plus concis et plus autonome.

Passons en revue ces 12 lignes de code. Aux lignes 1 et 2, nous lisons une feuille de calcul Excel qui contient une seule colonne de données. La feuille de calcul contient 30 observations. Ces données sont rassemblées dans un tableau nommé “H” qui a une seule colonne nommée “days”. À la ligne 4, nous construisons une distribution empirique. La variable “R” a le type de données “ranvar”, et du côté droit de l’affectation, la fonction “ranvar” est un agrégateur qui prend les observations en entrée et renvoie l’histogramme représenté par un type de données “ranvar”. En conséquence, le type de données “ranvar” est dédié aux distributions unidimensionnelles d’entiers. Nous avons introduit le type de données “ranvar” lors d’une conférence précédente de ce chapitre. Ce type de données garantit une empreinte mémoire constante et un temps de calcul constant pour chaque opération. L’inconvénient du “ranvar” en tant que type de données est qu’une compression avec perte est impliquée, bien que la perte de données causée par la compression ait été conçue pour être négligeable à des fins de chaîne d’approvisionnement.

À la ligne 5, nous lissons la distribution avec la fonction intégrée appelée “smooth”. Sous le capot, cette fonction remplace la distribution d’origine par un mélange de distributions de Poisson. Chaque compartiment de l’histogramme est transformé en une distribution de Poisson avec une moyenne égale à la position entière du compartiment, et enfin, le mélange attribue un poids à chaque distribution de Poisson proportionnel au poids du compartiment lui-même. Une autre façon de comprendre ce que fait cette fonction “smooth” est de considérer qu’elle équivaut à remplacer chaque observation individuelle par une distribution de Poisson avec une moyenne égale à l’observation elle-même. Toutes ces distributions de Poisson, une par observation, sont ensuite mélangées. Mélanger signifie faire la moyenne des valeurs respectives des compartiments de l’histogramme. Les variables “ranvar” “R” et “S” ne seront pas utilisées à nouveau avant les lignes 14 et 15, où elles sont affichées.

À la ligne 7, nous commençons un bloc Monte Carlo. Ce bloc est une sorte de boucle, et il va être exécuté 100 fois, comme spécifié par les 100 valeurs qui apparaissent juste après le mot-clé Monte Carlo. Le bloc Monte Carlo est destiné à collecter des observations indépendantes qui sont générées selon un processus qui implique un degré d’aléatoire. Vous vous demandez peut-être pourquoi il y a une construction Monte Carlo spécifique dans Envision au lieu d’avoir simplement une boucle, comme c’est généralement le cas avec les langages de programmation courants. Il s’avère qu’avoir une construction dédiée offre des avantages substantiels. Premièrement, cela garantit que les itérations sont vraiment indépendantes, jusqu’aux graines utilisées pour dériver la pseudo-aléatoire. Deuxièmement, cela offre une cible explicite pour la distribution automatisée de la charge de travail sur plusieurs cœurs de CPU ou même sur plusieurs machines.

À la ligne 8, nous créons un vecteur aléatoire de valeurs booléennes dans la table “H”. Avec cette ligne, nous créons des valeurs aléatoires indépendantes, appelées déviations (vrai ou faux), pour chaque ligne de la table “H”. Comme d’habitude avec Envision, les boucles sont abstraites grâce à la programmation par tableau. Avec ces valeurs booléennes, nous partitionnons la table “H” en deux groupes. Cette division aléatoire est utilisée pour le processus de validation croisée.

Aux lignes 9 et 10, nous créons deux “ranvars” nommés “A” et “B”, respectivement. Nous utilisons à nouveau l’agrégateur “ranvar”, mais cette fois, nous appliquons un filtre avec le mot-clé “when” juste après l’appel de l’agrégateur. “A” est généré en utilisant uniquement les lignes où la valeur de “a” est vraie ; pour “B”, c’est l’inverse. “B” est généré en utilisant uniquement les lignes où la valeur de “a” est fausse.

Aux lignes 11 et 12, nous collectons les chiffres d’intérêt du bloc Monte Carlo. Dans Envision, le mot-clé “sample” ne peut être placé que dans un bloc Monte Carlo. Il est utilisé pour collecter les observations faites lors de l’itération de nombreuses fois à travers le processus Monte Carlo. À la ligne 11, nous calculons l’erreur moyenne, exprimée en termes de CRPS, entre deux distributions empiriques : un sous-échantillon de l’ensemble original des délais de livraison. Le mot-clé “sample” spécifie que les valeurs sont collectées au cours des itérations Monte Carlo. L’agrégateur “AVG”, qui signifie “moyenne” du côté droit de l’assignation, est utilisé pour produire une seule estimation à la fin du bloc.

À la ligne 12, nous faisons quelque chose de presque identique à ce qui s’est passé à la ligne 11. Cette fois, cependant, nous appliquons la fonction “smooth” au “ranvar” “B”. Nous voulons évaluer à quel point la variante lissée est proche de la distribution empirique naïve. Il s’avère qu’elle est plus proche, du moins en termes de CRPS, que ses homologues empiriques d’origine.

Aux lignes 14 et 15, nous affichons les histogrammes et les valeurs CRPS. Ces lignes génèrent les figures que nous avons vues dans la diapositive précédente. Ce script nous donne notre référence pour la qualité de la distribution empirique de notre modèle. En effet, bien que ce modèle, celui du “code-barres”, soit sans doute naïf, c’est néanmoins un modèle, et un modèle probabiliste de surcroît. Ainsi, ce script nous donne également un meilleur modèle, du moins au sens du CRPS, grâce à une variante lissée de la distribution empirique d’origine.

En ce moment, en fonction de votre familiarité avec les langages de programmation, cela peut sembler beaucoup à assimiler. Cependant, je tiens à souligner à quel point il est simple de produire une distribution de probabilité raisonnable, même lorsque nous n’avons que quelques observations. Bien que nous ayons 12 lignes de code, seules les lignes 4 et 5 représentent la véritable partie de modélisation de l’exercice. Si nous étions seulement intéressés par la variante lissée, alors le “ranvar” “S” pourrait être écrit avec une seule ligne de code. Ainsi, c’est littéralement une ligne de code : d’abord, appliquer une agrégation de ranvar, et ensuite, appliquer un opérateur de lissage, et c’est tout. Le reste n’est que de l’instrumentation et de l’affichage. Avec les outils appropriés, la modélisation probabiliste, que ce soit pour le délai de livraison ou autre chose, peut être rendue extrêmement simple. Il n’y a pas de grandes mathématiques impliquées, pas d’algorithme grandiose, pas de grands morceaux de logiciel. C’est simple et remarquablement simple.

Comment obtient-on un envoi avec six mois de retard ? La réponse est évidente : un jour à la fois. Plus sérieusement, les délais de livraison peuvent généralement être décomposés en une série de retards. Par exemple, un délai de livraison du fournisseur peut être décomposé en un retard d’attente lorsque la commande est mise en attente dans une file d’attente, suivi d’un retard de fabrication lorsque les marchandises sont produites, et enfin suivi d’un retard de transit lorsque les marchandises sont expédiées. Ainsi, si les délais de livraison peuvent être décomposés, il est également intéressant de pouvoir les recomposer.

Si nous vivions dans un monde hautement déterministe où l’avenir pouvait être précisément anticipé, alors recomposer les délais de livraison ne serait qu’une question d’addition. En revenant à l’exemple que je viens de mentionner, composer le délai de livraison de la commande serait la somme du retard d’attente en jours, du retard de fabrication en jours et du retard de transit en jours. Cependant, nous ne vivons pas dans un monde où l’avenir peut être précisément anticipé. Les distributions de délai de livraison du monde réel que nous avons présentées au début de cette leçon soutiennent cette proposition. Les délais de livraison sont erratiques et il y a peu de raisons de croire que cela changera fondamentalement dans les décennies à venir.

Ainsi, les délais de livraison futurs doivent être abordés comme des variables aléatoires. Ces variables aléatoires embrassent et quantifient l’incertitude au lieu de la rejeter. Plus précisément, cela signifie que chaque composante du délai de livraison doit également être modélisée individuellement en tant que variable aléatoire. En revenant à notre exemple, le délai de livraison de la commande est une variable aléatoire, et il est obtenu comme la somme de trois variables aléatoires respectivement associées au retard d’attente, au retard de fabrication et au retard de transit.

La formule pour la somme de deux variables aléatoires indépendantes, unidimensionnelles et à valeurs entières est présentée à l’écran. Cette formule indique simplement que si nous obtenons une durée totale de Z jours, et si nous avons K jours pour la première variable aléatoire X, alors nous devons avoir Z moins K jours pour la deuxième variable aléatoire Y. Ce type de sommation est connu, en général, en mathématiques sous le nom de convolutions.

Bien qu’il semble qu’il y ait un nombre infini de termes dans cette convolution, en pratique, nous ne nous soucions que d’un nombre fini de termes. Tout d’abord, toutes les durées négatives ont une probabilité nulle ; en effet, des retards négatifs signifieraient revenir dans le temps. Deuxièmement, pour les retards importants, les probabilités deviennent si petites que, pour des fins pratiques de la chaîne d’approvisionnement, elles peuvent être approximées de manière fiable comme des zéros.

Mettons ces convolutions en pratique. Considérons un temps de transit qui peut être décomposé en deux phases : un retard d’expédition suivi d’un retard de dédouanement. Nous voulons modéliser ces deux phases avec deux variables aléatoires indépendantes, puis recomposer le temps de transit en ajoutant ces deux variables aléatoires.

À l’écran, les histogrammes à gauche sont produits par le script à droite. À la ligne 1, le retard d’expédition est modélisé comme une convolution d’une distribution de Poisson plus une constante. La fonction Poisson renvoie un type de données “ranvar” ; en ajoutant trois, on décale la distribution vers la droite. Le “ranvar” résultant est assigné à la variable “C”. Ce “ranvar” est affiché à la ligne 3. On peut le voir à gauche comme l’histogramme le plus haut. Nous reconnaissons la forme d’une distribution de Poisson qui a été décalée vers la droite de quelques unités, trois unités dans ce cas. À la ligne deux, le dédouanement douanier est modélisé comme un mélange d’une Dirac à zéro et d’une Poisson à cinq. La Dirac à zéro se produit quatre-vingts pour cent du temps ; c’est ce que signifie cette constante 0,8. Elle reflète les situations où la plupart du temps, les marchandises ne sont même pas inspectées par les douanes et passent sans aucun retard notable. Alternativement, vingt pour cent du temps, les marchandises sont inspectées en douane, et le retard est modélisé comme une distribution de Poisson avec une moyenne de cinq. Le “ranvar” résultant est assigné à une variable nommée “D”. Ce “ranvar” est affiché à la ligne quatre et peut être vu à gauche comme l’histogramme du milieu. Cet aspect asymétrique reflète que la plupart du temps, les douanes n’ajoutent aucun retard.

Enfin, à la ligne cinq, nous calculons C plus D. Cette addition est une convolution, car à la fois C et D sont des “ranvars”, pas des nombres. Il s’agit de la deuxième convolution dans ce script, car une convolution a déjà eu lieu à la ligne un. Le “ranvar” résultant est affiché et est visible à gauche comme le troisième et plus bas histogramme. Cet histogramme est similaire au premier, sauf que la queue se propage beaucoup plus loin vers la droite. Une fois de plus, nous voyons qu’avec quelques lignes de code, nous pouvons aborder des effets réels non triviaux, tels que les retards de dédouanement.

Cependant, deux critiques pourraient être formulées à propos de cet exemple. Premièrement, il ne dit pas d’où viennent les constantes ; en pratique, nous voulons apprendre ces constantes à partir de données historiques. Deuxièmement, bien que la distribution de Poisson ait l’avantage de la simplicité, elle peut ne pas être une forme très réaliste pour la modélisation des délais de livraison, en particulier dans les situations à queue grasse. Nous allons donc aborder ces deux points dans l’ordre.

Pour apprendre les paramètres à partir des données, nous allons revoir un paradigme de programmation que nous avons déjà introduit dans cette série de cours, à savoir la programmation différentiable. Si vous n’avez pas regardé les cours précédents de ce chapitre, je vous invite à les consulter après la fin de la présente leçon. La programmation différentiable est présentée en détail dans ces cours.

La programmation différentiable est une combinaison de deux techniques : la descente de gradient stochastique et la différentiation automatique. La descente de gradient stochastique est une technique d’optimisation qui ajuste les paramètres une observation à la fois dans la direction opposée des gradients. La différentiation automatique est une technique de compilation, comme dans le compilateur d’un langage de programmation ; elle calcule les gradients pour tous les paramètres qui apparaissent dans un programme général.

Illustrons la programmation différentiable avec un problème de délai de livraison. Cela servira soit de rappel, soit d’introduction, selon votre familiarité avec ce paradigme. Nous voulons modéliser l’impact du Nouvel An chinois sur les délais de livraison associés aux importations en provenance de Chine. En effet, lorsque les usines ferment pendant deux ou trois semaines pour le Nouvel An chinois, les délais de livraison s’allongent. Le Nouvel An chinois est cyclique ; il se produit chaque année. Cependant, il n’est pas strictement saisonnier, du moins pas au sens du calendrier grégorien.

Aux lignes un à six, nous introduisons quelques fausses commandes d’achat avec quatre observations, avec à la fois une date de commande et une date de réception. En pratique, ces données ne seraient pas codées en dur, mais nous chargerions ces données historiques à partir des systèmes de l’entreprise. Aux lignes huit et neuf, nous calculons si le délai de livraison chevauche le Nouvel An chinois. La variable “T.overlap_CNY” est un vecteur booléen ; elle indique si l’observation est impactée par le Nouvel An chinois ou non.

À la ligne 12, nous introduisons un bloc “autodiff”. La table T est utilisée comme table d’observation, et il y a 1000 époques. Cela signifie que chaque observation, donc chaque ligne de la table T, va être visitée mille fois. Une étape de la descente de gradient stochastique correspond à une exécution de la logique dans le bloc “autodiff”.

Aux lignes 13 et 14, deux paramètres scalaires sont déclarés. Le bloc “autodiff” apprendra ces paramètres. Le paramètre A reflète le délai de livraison de base sans l’effet du Nouvel An chinois, et le paramètre B reflète le retard supplémentaire associé au Nouvel An chinois. À la ligne 15, nous calculons X, la prédiction du délai de livraison de notre modèle. Il s’agit d’un modèle déterministe, pas probabiliste ; X est une prévision de délai de livraison ponctuelle. Le côté droit de l’affectation est simple : si l’observation chevauche le Nouvel An chinois, alors nous retournons la valeur de base plus la composante du Nouvel An ; sinon, nous retournons uniquement la valeur de base. Comme le bloc “autodiff” ne prend qu’une seule observation à la fois, à la ligne 15, la variable T.overlap_CNY fait référence à une valeur scalaire et non à un vecteur. Cette valeur correspond à la ligne d’observation choisie dans la table T.

Les paramètres A et B sont enveloppés dans la fonction exponentielle “exp”, qui est une astuce de programmation différentiable. En effet, l’algorithme qui pilote la descente de gradient stochastique a tendance à être relativement conservateur en ce qui concerne les variations incrémentielles des paramètres. Ainsi, si nous voulons apprendre un paramètre positif qui peut devenir plus grand que, disons, 10, envelopper ce paramètre dans un processus exponentiel accélère la convergence.

À la ligne 16, nous retournons une erreur quadratique moyenne entre notre prédiction X et la durée observée, exprimée en jours (T.days). Encore une fois, à l’intérieur de ce bloc “autodiff”, T.days est une valeur scalaire et non un vecteur. Comme la table T est utilisée comme table d’observation, la valeur de retour est traitée comme la perte qui est minimisée par la descente de gradient stochastique. La différenciation automatique propage les gradients de la perte vers les paramètres A et B. Enfin, à la ligne 19, nous affichons les deux valeurs que nous avons apprises, respectivement pour A et B, qui sont la valeur de base et la composante du Nouvel An de notre délai de livraison.

Cela conclut notre réintroduction de la programmation différentiable en tant qu’outil polyvalent qui apprend des motifs statistiques. À partir de là, nous revisiterons les blocs “autodiff” avec des situations plus élaborées. Cependant, soulignons une fois de plus que même si cela peut sembler un peu accablant, il ne se passe rien de vraiment compliqué ici. On peut soutenir que la partie de code la plus compliquée de ce script est la mise en œuvre sous-jacente de la fonction “ChineseYearStart”, appelée à la ligne huit, qui fait partie de la bibliothèque standard Envision. En quelques lignes de code, nous introduisons un modèle avec deux paramètres et apprenons ces paramètres. Encore une fois, cette simplicité est remarquable.

Les délais de livraison sont souvent à queue grasse ; c’est-à-dire que lorsqu’un délai de livraison s’écarte, il s’écarte beaucoup. Ainsi, afin de modéliser le délai de livraison, il est intéressant d’adopter des distributions qui peuvent reproduire ces comportements à queue grasse. La littérature mathématique présente une liste étendue de telles distributions, et plusieurs d’entre elles conviendraient à notre objectif. Cependant, simplement parcourir le paysage mathématique nous prendrait des heures. Soulignons simplement que la distribution de Poisson n’a pas de queue grasse. Ainsi, aujourd’hui, je vais choisir la distribution log-logistique, qui se trouve être une distribution à queue grasse. La justification principale de ce choix de distribution est que les équipes de Lokad modélisent les délais de livraison à l’aide de distributions log-logistiques pour plusieurs clients. Cela fonctionne bien avec un minimum de complications. Gardons à l’esprit, cependant, que la distribution log-logistique n’est en aucun cas une solution miracle, et qu’il existe de nombreuses situations où Lokad modélise les délais de livraison différemment.

À l’écran, nous avons la fonction de densité de probabilité de la distribution log-logistique. Il s’agit d’une distribution paramétrique qui dépend de deux paramètres, alpha et beta. Le paramètre alpha est la médiane de la distribution, et le paramètre beta régit la forme de la distribution. À droite, une courte série de formes peut être obtenue grâce à différentes valeurs de beta. Bien que cette formule de densité puisse sembler intimidante, c’est littéralement du matériel de manuel, tout comme la formule pour calculer le volume d’une sphère. Vous pouvez essayer de déchiffrer et de mémoriser cette formule, mais ce n’est même pas nécessaire ; vous devez simplement savoir qu’une formule analytique existe. Une fois que vous savez que la formule existe, la retrouver en ligne prend moins d’une minute.

Notre intention est d’utiliser la distribution log-logistique pour apprendre un modèle de délai de livraison probabiliste. Pour ce faire, nous allons minimiser la log-vraisemblance. En effet, dans la conférence précédente de ce cinquième chapitre, nous avons vu qu’il existe plusieurs mesures appropriées pour la perspective probabiliste. Il y a peu de temps, nous avons revisité le CRPS (Continuous Ranked Probability Score). Ici, nous revisitons la log-vraisemblance, qui adopte une perspective bayésienne.

En résumé, étant donné deux paramètres, la distribution log-logistique nous indique la probabilité d’observer chaque observation telle qu’elle se trouve dans l’ensemble de données empiriques. Nous voulons apprendre les paramètres qui maximisent cette vraisemblance. Le logarithme, donc la log-vraisemblance plutôt que la simple vraisemblance, est introduit pour éviter les sous-flux numériques. Les sous-flux numériques se produisent lorsque nous traitons de très petits nombres, très proches de zéro ; ces très petits nombres ne se comportent pas bien avec la représentation en virgule flottante couramment utilisée dans le matériel informatique moderne.

Ainsi, afin de calculer la log-vraisemblance de la distribution log-logistique, nous appliquons le logarithme à sa fonction de densité de probabilité. L’expression analytique est donnée à l’écran. Cette expression peut être mise en œuvre, et c’est exactement ce qui est fait dans les trois lignes de code ci-dessous.

À la première ligne, la fonction “L4” est introduite. L4 signifie “log-vraisemblance de la log-logistique” - oui, il y a beaucoup de L et beaucoup de logs. Cette fonction prend trois arguments : les deux paramètres alpha et beta, plus l’observation x. Cette fonction renvoie le logarithme de la vraisemblance. La fonction L4 est décorée avec le mot-clé “autodiff” ; ce mot-clé indique que cette fonction est destinée à être différenciée par différenciation automatique. En d’autres termes, les gradients peuvent remonter de la valeur de retour de cette fonction à ses arguments, les paramètres alpha et beta. Techniquement, le gradient remonte également à l’observation x ; cependant, comme nous allons conserver les observations immuables pendant le processus d’apprentissage, les gradients n’auront aucun effet sur les observations. À la troisième ligne, nous obtenons la transcription littérale de la formule mathématique juste au-dessus du script.

Mettons maintenant les choses ensemble avec un script qui apprend les paramètres d’un modèle de délai de livraison probabiliste basé sur la distribution log-logistique. Aux lignes un et trois, nous générons notre jeu de données d’entraînement fictif. Dans des contextes réels, nous utiliserions des données historiques au lieu de générer des données fictives. À la première ligne, nous créons une “ranvar” qui représente la distribution d’origine. Dans le cadre de l’exercice, nous voulons apprendre à retrouver ces paramètres, alpha et beta. La fonction log-logistique fait partie de la bibliothèque standard d’Envision et elle renvoie une “ranvar”. À la deuxième ligne, nous créons la table “H”, qui contient 1 000 entrées. À la troisième ligne, nous tirons 1 000 déviations échantillonnées au hasard à partir de la distribution d’origine “R”. Ce vecteur “H.days” représente l’ensemble de données d’entraînement.

À la sixième ligne, nous avons un bloc “autodiff” ; c’est là que l’apprentissage a lieu. Aux lignes sept et huit, nous déclarons deux paramètres, alpha et beta, et afin d’éviter les problèmes numériques tels que la division par zéro, des bornes sont appliquées à ces paramètres. Alpha doit rester supérieur à 0,01 et beta doit rester supérieur à 1,0. À la ligne neuf, nous renvoyons la perte, qui est l’opposé de la log-vraisemblance. En effet, par convention, les blocs “autodiff” minimisent la fonction de perte, et donc nous voulons maximiser la vraisemblance, d’où le signe moins. La fonction “log_likelihood.logistic” fait partie de la bibliothèque standard d’Envision, mais en réalité, il s’agit simplement de la fonction “L4” que nous avons implémentée dans la diapositive précédente. Ainsi, il n’y a pas de magie ici ; c’est toute la différenciation automatique qui permet au gradient de remonter de la perte aux paramètres alpha et beta.

Aux lignes 11 et 12, la distribution d’origine et la distribution apprise sont tracées. Les histogrammes sont limités à 200 ; cette limite rend l’histogramme un peu plus lisible. Nous y reviendrons dans un instant. Si vous vous demandez quelle est la performance de la partie “autodiff” de ce script, il faut moins de 80 millisecondes pour s’exécuter sur un seul cœur de CPU. La programmation différentiable n’est pas seulement polyvalente ; elle utilise également efficacement les ressources informatiques fournies par le matériel informatique moderne.

À l’écran, nous avons les deux histogrammes produits par notre script que nous venons de passer en revue. En haut, la distribution d’origine avec ses deux paramètres d’origine, alpha et beta, à 80 et 4 respectivement. En bas, la distribution apprise avec deux paramètres appris grâce à la programmation différentiable. Ces deux pics à l’extrême droite sont associés aux queues que nous avons tronquées, car ces queues s’étendent assez loin. Au fait, bien que cela soit rare, il arrive que certains biens soient reçus plus d’un an après leur commande. Ce n’est pas le cas pour tous les secteurs, certainement pas pour les produits laitiers, mais pour les pièces mécaniques ou électroniques, cela arrive occasionnellement.

Bien que le processus d’apprentissage ne soit pas exact, nous obtenons des résultats à moins de un pour cent des valeurs des paramètres d’origine. Cela démontre, au moins, que cette maximisation de la log-vraisemblance par la programmation différentiable fonctionne en pratique. La distribution log-logistique peut être appropriée ou non ; cela dépend de la forme de la distribution des délais de livraison à laquelle vous êtes confronté. Cependant, nous pouvons pratiquement choisir n’importe quelle autre distribution paramétrique. Tout ce qu’il faut, c’est une expression analytique de la fonction de densité de probabilité. Il existe une vaste gamme de telles distributions. Une fois que vous avez une formule de manuel, une mise en œuvre simple grâce à la programmation différentiable fait généralement le reste.

Les délais de livraison ne sont pas seulement observés une fois que la transaction est finalisée. Pendant que la transaction est encore en cours, vous savez déjà quelque chose ; vous avez déjà une observation de délai de livraison incomplète. Supposons que vous avez passé une commande il y a 100 jours. Les marchandises n’ont pas encore été reçues ; cependant, vous savez déjà que le délai de livraison est d’au moins 100 jours. Cette durée de 100 jours représente la limite inférieure pour un délai de livraison qui n’a pas encore été observé complètement. Ces délais de livraison incomplets sont souvent très importants. Comme je l’ai mentionné au début de cette conférence, les ensembles de données sur les délais de livraison sont souvent clairsemés. Il n’est pas rare de disposer d’un ensemble de données qui ne comprend que quelques observations. Dans ces situations, il est important de tirer le meilleur parti de chaque observation, y compris celles qui sont encore en cours.

Prenons l’exemple suivant : nous avons au total cinq commandes. Trois commandes ont déjà été livrées avec des valeurs de délai de livraison très proches de 30 jours. Cependant, les deux dernières commandes sont en attente depuis respectivement 40 jours et 50 jours. Selon les trois premières observations, le délai de livraison moyen devrait être d’environ 30 jours. Cependant, les deux dernières commandes qui sont encore incomplètes réfutent cette hypothèse. Les deux commandes en attente à 40 et 50 jours suggèrent un délai de livraison nettement plus long. Ainsi, nous ne devrions pas ignorer les dernières commandes simplement parce qu’elles sont incomplètes. Nous devrions exploiter cette information et mettre à jour notre croyance vers des délais de livraison plus longs, peut-être 60 jours.

Revisitons notre modèle probabiliste de délai de livraison, mais cette fois, prenons en compte les observations incomplètes. En d’autres termes, nous voulons traiter les observations qui sont parfois seulement une limite inférieure pour le délai de livraison final. Pour ce faire, nous pouvons utiliser la fonction de distribution cumulative (CDF) de la distribution log-logistique. Cette formule est écrite à l’écran ; encore une fois, il s’agit de matériel de manuel. La CDF de la distribution log-logistique bénéficie d’une expression analytique simple. Dans la suite, je ferai référence à cette technique comme la “technique de probabilité conditionnelle” pour traiter les données censurées.

Sur la base de cette expression analytique de la CDF, nous pouvons revisiter la log-vraisemblance de la distribution log-logistique. Le script à l’écran fournit une implémentation révisée de notre précédente implémentation L4. À la ligne un, nous avons pratiquement la même déclaration de fonction. Cette fonction prend un quatrième argument supplémentaire, une valeur booléenne nommée “is_incomplete” qui indique, comme son nom l’indique, si l’observation est incomplète ou non. Aux lignes deux et trois, si l’observation est complète, alors nous revenons à la situation précédente avec la distribution log-logistique régulière. Ainsi, nous appelons la fonction de log-vraisemblance qui fait partie de la bibliothèque standard. J’aurais pu répéter le code de la précédente implémentation L4, mais cette version est plus concise. Aux lignes quatre et cinq, nous exprimons la log-vraisemblance d’observer finalement un délai de livraison supérieur à l’observation incomplète actuelle, “X”. Cela est réalisé grâce à la CDF et, plus précisément, au logarithme de la CDF.

Nous pouvons maintenant répéter notre configuration avec un script qui apprend les paramètres de la distribution log-logistique, mais cette fois en présence de délais de livraison incomplets. Le script à l’écran est presque identique au précédent. Aux lignes un à trois, nous générons les données ; ces lignes n’ont pas changé. Soulignons que H.N est un vecteur auto-généré qui est créé implicitement à la ligne deux. Ce vecteur numérote les lignes générées, en commençant à un. La version précédente de ce script n’utilisait pas ce vecteur auto-généré, mais actuellement, le vecteur H.N apparaît à la fin de la ligne six.

Les lignes cinq et six sont en effet les plus importantes. Ici, nous censurons les délais de livraison. C’est comme si nous faisions une observation de délai de livraison par jour et tronquions les observations qui sont trop récentes pour être informées. Cela signifie, par exemple, qu’un délai de livraison de 20 jours initié il y a sept jours apparaît comme un délai de livraison incomplet de sept jours. À la fin de la ligne six, nous avons généré une liste de délais de livraison où certaines des observations récentes (celles qui se termineraient au-delà de la date actuelle) sont incomplètes. Le reste du script est inchangé, sauf à la ligne 12, où le vecteur H.is_complete est passé comme quatrième argument de la fonction de log-vraisemblance. Ainsi, nous appelons, à la ligne 12, la fonction de programmation différentiable que nous venons d’introduire il y a une minute.

Enfin, à l’écran, les deux histogrammes sont produits par ce script révisé. Les paramètres sont toujours appris avec une grande précision, alors que nous sommes maintenant en présence de nombreux délais de livraison incomplets. Afin de valider que le traitement des temps incomplets n’était pas une complication inutile, j’ai réexécuté le script, mais cette fois avec une variation modifiée avec la surcharge à trois arguments de la fonction de log-vraisemblance (celle que nous avons utilisée initialement et supposée que toutes les observations sont complètes). Pour alpha et beta, nous obtenons les valeurs affichées en bas de l’écran. Comme prévu, ces valeurs ne correspondent pas du tout aux valeurs originales d’alpha et de beta.

Dans cette série de conférences, ce n’est pas la première fois qu’une technique a été introduite pour traiter les données censurées. Dans la deuxième conférence de ce chapitre, la technique de masquage de perte a été introduite pour traiter les ruptures de stock. En effet, nous voulons généralement prédire la demande future, pas les ventes futures. Les ruptures de stock introduisent un biais à la baisse, car nous ne pouvons pas observer toutes les ventes qui se seraient produites si la rupture de stock ne s’était pas produite. La technique de probabilité conditionnelle peut être utilisée pour traiter la demande censurée comme c’est le cas avec les ruptures de stock. La technique de probabilité conditionnelle est un peu plus complexe que le masquage de perte, il ne devrait donc probablement pas être utilisé si le masquage de perte est suffisant.

Dans le cas des délais de livraison, la rareté des données est la principale motivation. Nous pouvons avoir si peu de données qu’il peut être crucial de tirer le meilleur parti de chaque observation, même les observations incomplètes. En effet, la technique de probabilité conditionnelle est plus puissante que le masquage de perte dans le sens où elle exploite les observations incomplètes au lieu de les rejeter simplement. Par exemple, s’il y a une unité en stock et que cette unité en stock est vendue, alors, en suggérant une rupture de stock, la technique de probabilité conditionnelle utilise toujours l’information selon laquelle la demande était supérieure ou égale à un.

Ici, nous obtenons un avantage surprenant de la modélisation probabiliste : cela nous donne une manière élégante de traiter la censure, un effet qui se produit dans de nombreuses situations de la chaîne d’approvisionnement. Grâce à la probabilité conditionnelle, nous pouvons éliminer des classes entières de biais systématiques.

Les prévisions des délais de livraison sont généralement destinées à être combinées avec les prévisions de la demande. En effet, considérons maintenant une situation simple de réapprovisionnement des stocks, comme illustré à l’écran.

Nous proposons un seul produit et le stock peut être réapprovisionné en passant commande auprès d’un seul fournisseur. Nous recherchons une prévision qui soutiendrait notre décision de passer commande ou non auprès du fournisseur. Nous pouvons passer commande maintenant et, si nous le faisons, les marchandises arriveront au moment indiqué comme “première arrivée”. Plus tard, nous aurons une autre opportunité de passer commande. Cette opportunité ultérieure se produit à un moment indiqué comme “prochaine commande” et, dans ce cas, les marchandises arriveront au moment indiqué comme “deuxième arrivée”. La période indiquée comme “fenêtre de responsabilité” est la période qui importe pour notre décision de réapprovisionnement.

En effet, quoi que nous décidions de commander n’arrivera pas avant le premier délai de livraison. Ainsi, nous avons déjà perdu le contrôle sur le service de la demande pour tout ce qui se produit avant la première arrivée. Ensuite, comme nous aurons une autre opportunité de passer commande, le service de la demande après la deuxième arrivée ne relève plus de notre responsabilité ; c’est la responsabilité de la prochaine commande. Ainsi, passer commande en ayant l’intention de servir la demande au-delà de la deuxième arrivée devrait être reporté jusqu’à la prochaine opportunité de commande.

Afin de soutenir la décision de réapprovisionnement, deux facteurs doivent être prévus. Premièrement, nous devons prévoir le stock attendu à l’arrivée du premier délai. En effet, si au moment de la première arrivée, il reste encore beaucoup de stock, il n’y a aucune raison de passer commande maintenant. Deuxièmement, nous devons prévoir la demande attendue pour la durée de la fenêtre de responsabilité. Dans une configuration réelle, nous devrions également prévoir la demande au-delà de la fenêtre de responsabilité afin d’évaluer le coût de possession des marchandises que nous commandons maintenant, car il peut y avoir des restes qui se prolongent sur des périodes ultérieures. Cependant, pour des raisons de concision et de timing, nous allons nous concentrer aujourd’hui sur le stock attendu et la demande attendue en ce qui concerne la fenêtre de responsabilité.

Ce script met en œuvre les facteurs ou prévisions de la fenêtre de responsabilité que nous venons de discuter. Il prend en entrée une prévision probabiliste du délai de livraison et une prévision probabiliste de la demande. Il renvoie deux distributions de probabilités, à savoir le stock disponible à l’arrivée et la demande éligible telle que définie par la fenêtre de responsabilité.

Aux lignes un et deux, nous définissons les échéanciers, qui commencent le 1er janvier et se terminent le 1er mars. Dans une configuration de prédiction, cette chronologie ne serait pas codée en dur. À la ligne quatre, un modèle de demande probabiliste simpliste est introduit : une distribution de Poisson répétée jour après jour pendant toute la durée de cette chronologie. La demande sera en moyenne d’une unité par jour. J’utilise ici un modèle simpliste pour la demande dans un souci de clarté. Dans une configuration réelle, nous utiliserions par exemple un ESSM (Ensemble State Space Model). Les modèles d’espace d’état sont des modèles probabilistes, et ils ont été introduits dans la toute première conférence de ce chapitre.

À la ligne cinq, un autre modèle probabiliste simpliste est introduit. Ce deuxième modèle est destiné aux délais de livraison. Il s’agit d’une distribution de Poisson décalée de sept jours vers la droite. Le décalage est effectué par une convolution. À la ligne six, nous définissons le stock initial disponible. À la ligne sept, nous définissons le cycle de commande. Cette valeur est exprimée en jours et caractérise quand la prochaine commande aura lieu.

De la ligne 9 à 16, nous avons un bloc Monte Carlo qui représente la logique centrale du script. Plus tôt dans cette conférence, nous avons déjà introduit un autre bloc Monte Carlo pour soutenir notre logique de validation croisée. Ici, nous utilisons cette construction à nouveau, mais dans un but différent. Nous voulons calculer deux variables aléatoires reflétant respectivement le stock disponible à l’arrivée et la demande éligible. Cependant, l’algèbre des variables aléatoires n’est pas assez expressive pour effectuer ce calcul. Nous utilisons donc un bloc Monte Carlo à la place.

Dans la troisième conférence de ce chapitre, j’ai souligné qu’il existe une dualité entre les prévisions probabilistes et les simulations. Le bloc Monte Carlo illustre cette dualité. Nous commençons par une prévision probabiliste, la transformons en une simulation, puis convertissons les résultats de la simulation en une autre prévision probabiliste.

Jetons un coup d’œil aux détails. À la ligne 10, nous générons une trajectoire pour la demande. À la ligne 11, nous générons la date d’arrivée de la première commande, en supposant que nous passons commande aujourd’hui. À la ligne 12, nous générons la date d’arrivée de la deuxième commande, en supposant que nous passons commande un cycle de commande à partir de maintenant. À la ligne 13, nous calculons ce qui reste en stock à la première date d’arrivée. Il s’agit du stock initial moins la demande observée pendant la durée du premier délai de livraison. Le max zéro indique que le stock ne peut pas être négatif. En d’autres termes, nous supposons que nous n’avons aucun retard. Cette hypothèse de l’absence de retard peut être modifiée. Le cas du retard est laissé en exercice à l’audience. Comme indice, la programmation différentiable peut être utilisée pour évaluer le pourcentage de la demande non satisfaite qui se transforme avec succès en retards, en fonction du nombre de jours restant avant la disponibilité renouvelée du stock.

Revenons au script, à la ligne 14, nous calculons la demande éligible, qui est la demande qui se produit pendant la fenêtre de responsabilité. Aux lignes 15 et 16, nous collectons deux variables aléatoires d’intérêt grâce au mot-clé “sample”. Contrairement au premier script Envision de cette conférence, qui traitait de la validation croisée, nous cherchons ici à collecter des distributions de probabilités à partir de ce bloc Monte Carlo, pas seulement des moyennes. Aux lignes 15 et 16, la variable aléatoire qui apparaît à droite de l’affectation est un agrégateur. À la ligne 15, nous obtenons une variable aléatoire pour le stock disponible à l’arrivée. À la ligne 16, nous obtenons une autre variable aléatoire pour la demande qui se produit dans la fenêtre de responsabilité.

Aux lignes 18 et 19, ces deux variables aléatoires sont affichées. Maintenant, prenons une pause d’une seconde et réexaminons ce script dans son ensemble. Les lignes un à sept sont simplement dédiées à la configuration des fausses données. Les lignes 18 et 19 ne font que afficher les résultats. La seule logique réelle se trouve sur les huit lignes entre les lignes 9 et 16. En fait, toute la logique réelle est située, en un sens, aux lignes 13 et 14.

Avec seulement quelques lignes de code, moins de 10 peu importe comment nous comptons, nous combinons une prévision probabiliste du délai de livraison avec une prévision probabiliste de la demande afin de composer une sorte de prévision probabiliste hybride d’une signification réelle pour la supply chain. Notons qu’il n’y a rien ici qui dépende vraiment des spécificités de la prévision du délai de livraison ou de la prévision de la demande. Des modèles simples ont été utilisés, mais des modèles sophistiqués auraient pu être utilisés à la place. Cela n’aurait rien changé. La seule exigence est d’avoir deux modèles probabilistes afin de pouvoir générer ces trajectoires.

Enfin, à l’écran, les histogrammes produits par le script. L’histogramme supérieur représente le stock disponible à l’arrivée. Il y a environ 30% de chances de faire face à un stock initial nul. En d’autres termes, il y a environ 30% de chances qu’une rupture de stock se soit produite le dernier jour juste avant la première date d’arrivée. La valeur moyenne du stock pourrait être d’environ cinq unités. Cependant, si nous devions juger cette situation par sa moyenne, nous interpréterions sérieusement mal la situation. Une prévision probabiliste est essentielle pour refléter correctement la situation initiale du stock.

L’histogramme inférieur représente la demande associée à la fenêtre de responsabilité. Nous avons environ 10% de chances de faire face à une demande nulle. Ce résultat peut également être perçu comme surprenant. En effet, nous avons commencé cet exercice avec une demande stationnaire de Poisson d’une unité par jour en moyenne. Nous avons sept jours entre les commandes. S’il n’y avait pas eu de temps de cycle variable, il aurait dû y avoir moins de 0,1% de chances d’obtenir une demande nulle sur sept jours. Cependant, le script prouve que cette occurrence est beaucoup plus fréquente. La raison en est qu’une petite fenêtre de responsabilité peut se produire si le premier temps de cycle est plus long que d’habitude et si le deuxième temps de cycle est plus court que d’habitude.

Faire face à une demande nulle sur la fenêtre de responsabilité signifie que le stock disponible est susceptible de devenir assez élevé à un moment donné. Selon la situation, cela peut être critique ou non, mais cela peut l’être, par exemple, s’il existe une limite de capacité de stockage ou si le stock est périssable. Une fois de plus, la demande moyenne, probablement autour de huit, ne donne pas un aperçu fiable de ce à quoi ressemblait la demande. Rappelons que nous avons obtenu cette distribution très asymétrique à partir d’une demande stationnaire initiale, une unité par jour en moyenne. C’est l’effet du temps de cycle variable en action.

Cette configuration simple démontre l’importance des temps de cycle dans les situations de réapprovisionnement des stocks. Du point de vue de la supply chain, isoler les prévisions de temps de cycle des prévisions de demande est, au mieux, une abstraction pratique. La demande quotidienne n’est pas ce qui nous intéresse vraiment. Ce qui est vraiment intéressant, c’est la composition de la demande avec le temps de cycle. Si d’autres facteurs stochastiques étaient présents, tels que les arriérés ou les retours, ces facteurs feraient également partie du modèle.

Le présent chapitre de cette série de conférences est intitulé “Modélisation prédictive” au lieu de “Prévision de la demande”, comme cela serait généralement le cas dans les manuels de supply chain grand public. La raison de ce titre de chapitre devrait devenir progressivement évidente à mesure que nous avançons dans la présente conférence. En effet, du point de vue de la supply chain, nous voulons prévoir l’évolution du système de la supply chain. La demande est certainement un facteur important, mais ce n’est pas le seul facteur. D’autres facteurs variables tels que le temps de cycle doivent être prévus. Plus important encore, tous ces facteurs doivent finalement être prévus ensemble.

En effet, nous devons rassembler ces composantes prédictives pour soutenir un processus de prise de décision. Ainsi, ce qui importe n’est pas de chercher un modèle de prévision de la demande en tant que tel. Cette tâche est largement une chimère, car la précision supplémentaire sera obtenue de manière contraire aux intérêts de l’entreprise. Plus de sophistication signifie plus d’opacité, plus de bugs, plus de ressources informatiques. En règle générale, plus le modèle est sophistiqué, plus il devient difficile de le combiner avec succès opérationnellement avec un autre modèle. Ce qui importe, c’est d’assembler une collection de techniques prédictives qui peuvent être combinées à volonté. C’est ce que la modularité signifie du point de vue de la modélisation prédictive. Dans cette conférence, une demi-douzaine de techniques ont été présentées. Ces techniques sont utiles car elles abordent des aspects critiques du monde réel tels que les observations incomplètes. Elles sont également simples ; aucun des exemples de code présentés aujourd’hui ne dépasse 10 lignes de logique réelle. Plus important encore, ces techniques sont modulaires, comme des briques Lego. Elles fonctionnent bien ensemble et peuvent être presque indéfiniment recombinées.

L’objectif final de la modélisation prédictive pour la supply chain, tel qu’il devrait être compris, est l’identification de telles techniques. Chaque technique devrait être, en soi, une opportunité de revoir tout modèle prédictif préexistant afin de simplifier ou d’améliorer ce modèle.

En conclusion, bien que le temps de cycle soit largement ignoré par la communauté universitaire, il peut et devrait être prévu. En examinant une courte série de distributions de temps de cycle du monde réel, nous avons identifié deux défis : premièrement, les temps de cycle varient ; deuxièmement, les temps de cycle sont rares. Ainsi, nous avons introduit des techniques de modélisation adaptées pour traiter les observations de temps de cycle qui se révèlent à la fois rares et erratiques.

Ces modèles de temps de cycle sont probabilistes et sont, dans une large mesure, la continuation des modèles qui ont été progressivement introduits tout au long de ce chapitre. Nous avons également vu que la perspective probabiliste offre une solution élégante au problème des observations incomplètes, un aspect presque omniprésent dans la supply chain. Ce problème se produit chaque fois qu’il y a des ruptures de stock et chaque fois qu’il y a des commandes en attente. Enfin, nous avons vu comment composer une prévision probabiliste du temps de cycle avec une prévision probabiliste de la demande afin de créer le modèle prédictif dont nous avons besoin pour soutenir un processus de prise de décision ultérieur.

La prochaine conférence aura lieu le 8 mars. Ce sera un mercredi à la même heure, 15h heure de Paris. La conférence d’aujourd’hui était technique, mais la prochaine sera largement non technique, et je parlerai du cas du Supply Chain Scientist. En effet, les manuels de supply chain grand public abordent la supply chain comme si les modèles de prévision et les modèles d’optimisation émergeaient et fonctionnaient comme par magie, en ignorant complètement leur composante “wetware”, c’est-à-dire les personnes responsables. Ainsi, nous examinerons de plus près les rôles et responsabilités du Supply Chain Scientist, une personne chargée de diriger l’initiative de la supply chain quantitative.

Maintenant, je vais passer aux questions.

Question : Que se passe-t-il si quelqu’un veut conserver son stock pour une innovation ultérieure ou pour d’autres raisons que le juste-à-temps ou d’autres concepts ?

C’est en effet une question très importante. Le concept est généralement abordé par le biais de la modélisation économique de la supply chain, que nous appelons techniquement les “facteurs économiques” dans cette série de conférences. Ce que vous demandez, c’est s’il vaut mieux ne pas servir un client aujourd’hui parce qu’à un moment ultérieur, il y aura une opportunité de servir la même unité à une autre personne qui compte davantage pour une raison quelconque. En essence, ce que vous dites, c’est qu’il y a plus de valeur à capturer en servant un autre client plus tard, peut-être un client VIP, qu’en servant un client aujourd’hui.

Cela peut être le cas, et cela arrive. Par exemple, dans l’industrie de l’aviation, supposons que vous êtes un fournisseur de MRO (Maintenance, Repair, and Overhaul). Vous avez vos clients VIP habituels - les compagnies aériennes que vous servez régulièrement avec des contrats à long terme, et ils sont très importants. Lorsque cela se produit, vous voulez vous assurer que vous pourrez toujours servir ces clients. Mais que se passe-t-il si une autre compagnie aérienne vous appelle et demande une unité ? Dans ce cas, ce qui va se passer, c’est que vous pourriez servir cette personne, mais vous n’avez pas de contrat à long terme avec elle. Donc, ce que vous allez faire, c’est ajuster votre prix de manière à ce qu’il soit très élevé, en vous assurant d’obtenir suffisamment de valeur pour compenser la rupture de stock potentielle à un moment ultérieur. En conclusion de cette première question, je pense que ce n’est pas vraiment une question de prévision mais plutôt une question de modélisation adéquate des facteurs économiques. Si vous voulez conserver le stock, ce que vous voulez, c’est générer un modèle - un modèle d’optimisation - où la réponse rationnelle n’est pas de servir le client qui demande une unité tant que vous avez encore du stock en réserve.

Au fait, une autre situation typique est lorsque vous vendez des kits. Un kit est un assemblage de plusieurs pièces vendues ensemble, et il ne vous reste qu’une seule pièce qui ne vaut qu’une petite fraction de la valeur totale du kit. Le problème, c’est que si vous vendez cette dernière unité, vous ne pouvez plus construire votre kit et le vendre à son prix total. Ainsi, vous pourriez être dans une situation où vous préférez conserver l’unité en stock uniquement pour pouvoir vendre le kit ultérieurement, potentiellement avec une certaine incertitude. Mais encore une fois, cela se résume aux facteurs économiques, et c’est ainsi que j’aborderais cette situation.

Question : Au cours des dernières années, la plupart des retards de la supply chain sont survenus en raison de la guerre ou de la pandémie, ce qui est très difficile à prévoir car nous n’avions jamais connu de telles situations auparavant. Qu’en pensez-vous ?

Je pense que les délais de livraison ont toujours varié. Je suis dans le monde de la supply chain depuis 2008, et mes parents travaillaient déjà dans la supply chain 30 ans avant moi. Autant que nous nous en souvenions, les délais de livraison ont toujours été erratiques et variables. Il se passe toujours quelque chose, qu’il s’agisse d’une manifestation, d’une guerre ou d’un changement de tarifs. Oui, les deux dernières années ont été extrêmement erratiques, mais les délais de livraison variaient déjà beaucoup.

Je suis d’accord que personne ne peut prétendre être capable de prévoir la prochaine guerre ou pandémie. Si cela était possible de prédire ces événements mathématiquement, les gens ne se lanceraient pas dans des guerres ou n’investiraient pas dans la supply chain ; ils joueraient simplement en bourse et deviendraient riches en anticipant les mouvements du marché.

En fin de compte, ce que vous pouvez faire, c’est planifier l’inattendu. Si vous n’êtes pas sûr de l’avenir, vous pouvez en réalité augmenter les variations dans vos prévisions. C’est le contraire d’essayer de rendre vos prévisions plus précises - vous préservez vos attentes moyennes, mais vous augmentez simplement la queue afin que les décisions que vous prenez en fonction de ces prévisions probabilistes soient plus résilientes face aux variations. Vous avez conçu vos variations attendues pour être plus grandes que ce que vous voyez actuellement. En fin de compte, l’idée que les choses soient faciles ou difficiles à prévoir vient d’une perspective de prévision ponctuelle, où vous aimeriez jouer le jeu comme s’il était possible d’avoir une anticipation précise de l’avenir. Ce n’est pas le cas - il n’y a pas de telle chose qu’une anticipation précise de l’avenir. La seule chose que vous pouvez faire, c’est travailler avec des distributions de probabilité avec une grande dispersion qui manifeste et quantifie votre ignorance de l’avenir.

Au lieu de peaufiner les décisions qui dépendent de l’exécution minutieuse du plan exact, vous tenez compte et planifiez un degré intéressant de variation, rendant vos décisions plus robustes face à ces variations. Cependant, cela ne s’applique qu’au type de variation qui n’affecte pas votre supply chain de manière trop brutale. Par exemple, vous pouvez gérer des délais de livraison plus longs de la part des fournisseurs, mais si votre entrepôt a été bombardé, aucune prévision ne vous sauvera dans cette situation.

Question : Pouvons-nous créer ces histogrammes et calculer le CRPS dans Microsoft Excel, par exemple, en utilisant des compléments Excel comme itsastat ou qui héberge de nombreuses distributions ?

Oui, vous le pouvez. L’un d’entre nous chez Lokad a en fait produit une feuille de calcul Excel qui représente un modèle probabiliste pour une situation de réapprovisionnement des stocks. Le cœur du problème est qu’Excel n’a pas de type de données histogramme natif, donc tout ce que vous avez dans Excel, ce sont des nombres - une cellule, un nombre. Il serait élégant et simple d’avoir une valeur qui est un histogramme, où vous avez un histogramme complet emballé dans une seule cellule. Cependant, autant que je sache, cela n’est pas possible dans Excel. Néanmoins, si vous êtes prêt à consacrer environ 100 lignes pour représenter l’histogramme, bien qu’il ne soit pas aussi compact et pratique, vous pouvez mettre en œuvre une distribution dans Excel et faire de la modélisation probabiliste. Nous posterons le lien vers l’exemple dans la section des commentaires.

Gardez à l’esprit que c’est une tâche relativement laborieuse car Excel n’est pas idéalement adapté à cette tâche. Excel est un langage de programmation et vous pouvez tout faire avec, vous n’avez donc même pas besoin d’un complément pour y parvenir. Cependant, cela sera un peu verbeux, donc ne vous attendez pas à quelque chose de super soigné.

Question : Le délai de livraison peut être décomposé en composantes telles que le délai de commande, le délai de production, le délai de transport, etc. Si l’on souhaite un contrôle plus granulaire sur les délais de livraison, comment cette approche changerait-elle ?

Tout d’abord, nous devons considérer ce que signifie avoir plus de contrôle sur le délai de livraison. Souhaitez-vous réduire le délai de livraison moyen ou réduire la variabilité du délai de livraison ? De manière intéressante, j’ai vu de nombreuses entreprises réussir à réduire le délai de livraison moyen, mais en échange d’une certaine variation supplémentaire du délai de livraison. En moyenne, le délai de livraison est plus court, mais de temps en temps, il est beaucoup plus long.

Dans cette leçon, nous nous engageons dans un exercice de modélisation. En soi, il n’y a pas d’action ; il s’agit simplement d’observer, d’analyser et de prédire. Cependant, si nous pouvons décomposer le délai de livraison et analyser la distribution sous-jacente, nous pouvons utiliser la modélisation probabiliste pour évaluer quelles composantes varient le plus et lesquelles ont le plus grand impact négatif sur notre supply chain. Nous pouvons nous engager dans des scénarios “et si” avec ces informations. Par exemple, prenez une partie de votre délai de livraison et demandez-vous : “Et si la queue de ce délai de livraison était un peu plus courte, ou si la moyenne était un peu plus courte ?” Vous pouvez ensuite recomposer tout, relancer votre modèle prédictif pour l’ensemble de votre supply chain et commencer à évaluer l’impact.

Cette approche vous permet de raisonner par morceaux sur certains phénomènes, y compris les phénomènes erratiques. Ce ne serait pas tant un changement d’approche qu’une continuation de ce que nous avons fait, qui mène au chapitre 6, qui traite de l’optimisation des décisions réelles basées sur ces modèles probabilistes.

Question : Je pense que cela offre la possibilité de recalculer nos délais de livraison dans SAP afin de fournir un délai plus réaliste et d’aider à minimiser notre système de pull-in et de pull-out. Est-ce possible ?

Avertissement : SAP est un concurrent de Lokad dans l’espace de l’optimisation de la supply chain. Ma réponse initiale est non, SAP ne peut pas le faire. La réalité est que SAP dispose de quatre solutions distinctes qui traitent de l’optimisation de la supply chain, et cela dépend de la pile technologique dont vous parlez. Cependant, toutes ces piles ont en commun une vision centrée sur les prévisions ponctuelles. Tout dans SAP a été conçu sur la base que les prévisions seront précises.

Oui, SAP dispose de certains paramètres à régler, comme la distribution normale dont j’ai parlé au début de cette leçon. Cependant, les distributions des délais de livraison que nous avons observées ne suivaient pas une distribution normale. À ma connaissance, les configurations SAP courantes pour l’optimisation de la supply chain adoptent une distribution normale pour les délais de livraison. Le problème est qu’au fond, le logiciel repose sur une hypothèse mathématique largement incorrecte. Vous ne pouvez pas vous remettre d’une hypothèse mathématique largement incorrecte qui va directement au cœur de l’architecture de votre logiciel en réglant un paramètre. Théoriquement, cela est possible, mais en pratique, cela pose tellement de problèmes que la question est : pourquoi voudriez-vous vraiment le faire ?

Pour adopter une perspective probabiliste, vous devez être totalement engagé, ce qui signifie que vos prévisions sont probabilistes et que vos modèles d’optimisation utilisent également des modèles probabilistes. Le problème ici est que même si nous pouvions régler la modélisation probabiliste pour obtenir des délais de livraison légèrement meilleurs, le reste de la pile technologique SAP reviendra aux prévisions ponctuelles. Quoi qu’il arrive, nous réduirons ces distributions à des points. L’idée selon laquelle vous pourriez approximer cela par une moyenne est préoccupante et tout simplement fausse. Donc, techniquement, vous pourriez régler les délais de livraison, mais vous allez rencontrer tellement de problèmes après cela que cela pourrait ne pas valoir l’effort.

Question : Il y a des situations où vous commandez les mêmes pièces à différents fournisseurs. C’est une information importante à prendre en compte dans la prévision des délais de livraison. Faites-vous des prévisions des délais de livraison par article ou existe-t-il des situations où vous regroupez les articles par famille ?

C’est une question remarquablement intéressante. Nous avons deux fournisseurs pour le même article. La question sera de savoir quelle est la similitude entre les articles et les fournisseurs. Tout d’abord, nous devons examiner la situation. Si un fournisseur se trouve à côté et que l’autre fournisseur se trouve de l’autre côté du monde, vous devez vraiment considérer ces choses séparément. Mais supposons la situation intéressante où les deux fournisseurs sont assez similaires et qu’il s’agit du même article. Devriez-vous regrouper ces observations ou non ?

La chose intéressante est qu’avec la programmation différentiable, vous pouvez composer un modèle qui donne un certain poids au fournisseur et un certain poids à l’article et laisser la magie de l’apprentissage faire sa magie. Il s’adaptera à la question de savoir si nous devons accorder plus de poids à la composante article du délai de livraison ou à la composante fournisseur. Il se peut que deux fournisseurs qui fournissent à peu près le même type de produits aient un certain biais où un fournisseur est, en moyenne, un peu plus rapide que l’autre. Mais il y a des articles qui prennent certainement plus de temps, et donc si vous choisissez les articles, il n’est pas très clair qu’un fournisseur est plus rapide que l’autre car cela dépend vraiment des articles que vous regardez. Vous avez très probablement très peu de données si vous désagrégiez tout pour chaque fournisseur et chaque article. Ainsi, la chose intéressante, et ce que je recommanderais ici, serait d’élaborer un programme différentiable. Nous pourrions effectivement essayer de revoir cette situation lors d’une prochaine conférence, une situation où vous placez certains paramètres au niveau de la pièce et certains paramètres au niveau du fournisseur. Ainsi, vous avez un nombre total de paramètres qui n’est pas le nombre de pièces multiplié par le nombre de fournisseurs ; ce serait le nombre de pièces plus le nombre de fournisseurs, ou peut-être plus le nombre de fournisseurs multiplié par les catégories, ou quelque chose de similaire. Vous n’explosez pas votre nombre de paramètres ; vous ajoutez simplement un paramètre, un élément qui a une affinité avec le fournisseur, et cela vous permet de faire une sorte de mélange dynamique basé sur vos données historiques.

Question : Je pense que la quantité commandée et les produits commandés ensemble peuvent également avoir un impact sur le délai de livraison final. Pourriez-vous expliquer la complexité de l’inclusion de toutes les variables dans ce type de problème ?

Dans le dernier exemple, nous avions deux types de durée : le cycle de commande et le délai de livraison lui-même. Le cycle de commande est intéressant car il est incertain uniquement dans la mesure où nous n’avons pas encore pris la décision. C’est fondamentalement quelque chose que vous pouvez décider à peu près à n’importe quel moment, donc le cycle de commande est entièrement interne et de votre propre création. Ce n’est pas la seule chose dans la supply chain qui est comme ça ; les prix sont les mêmes. Vous avez la demande, vous observez la demande, mais vous pouvez en fait choisir le prix que vous voulez. Certains prix sont évidemment déraisonnables, mais c’est la même chose - c’est de votre propre création.

Le cycle de commande est de votre propre création. Maintenant, ce que vous dites, c’est qu’il y a une incertitude quant au moment exact de la prochaine commande en raison du délai de livraison, car vous ne savez pas exactement quand vous allez commander. En effet, vous avez tout à fait raison. Ce qui se passe, c’est que lorsque vous avez la capacité de mettre en œuvre cette modélisation probabiliste, soudainement, comme discuté dans le sixième chapitre de cette série de cours, vous ne voulez pas dire que le cycle de commande est de sept jours. Au lieu de cela, vous voulez adopter une politique de réapprovisionnement qui maximise le retour sur investissement pour votre entreprise. Ainsi, ce que vous pouvez faire, c’est planifier l’avenir de manière à ce que si vous réapprovisionnez maintenant, vous pouvez prendre une décision maintenant, puis appliquer votre politique jour après jour. À un moment donné dans le futur, vous effectuez une nouvelle commande, et maintenant ce que vous avez est une sorte de situation de “serpent qui se mord la queue” car la meilleure décision de commande pour aujourd’hui dépend de la décision de la prochaine décision de commande, celle que vous n’avez pas encore prise. Ce genre de problème est connu sous le nom de problème de politique, et c’est un problème de décision séquentielle. En réalité, ce que vous voulez vraiment, c’est élaborer une sorte de politique, un objet mathématique qui régit votre processus de prise de décision.

Le problème de l’optimisation de la politique est assez compliqué, et j’ai l’intention de le couvrir dans le sixième chapitre. Mais en fin de compte, si nous revenons à votre question, nous avons deux composantes distinctes. Nous avons la composante qui varie indépendamment de ce que vous faites, le délai de livraison qui est le délai de livraison de votre fournisseur, puis vous avez le temps de commande, qui est quelque chose qui est vraiment piloté en interne par votre processus et qui doit être traité comme une question d’optimisation.

Pour conclure cette réflexion, nous constatons une convergence de l’optimisation et de la modélisation prédictive. En fin de compte, les deux finissent par être à peu près la même chose car il y a des interactions entre les décisions que vous prenez et ce qui se passe dans le futur.

C’est tout pour aujourd’hui. N’oubliez pas, le 8 mars, à la même heure de la journée, ce sera un mercredi, 15 heures. Merci et à la prochaine fois.