Prévisions probabilistes des délais d'approvisionnement

L’exactitude de l’estimation d’un délai d'approvisionnement est corrélée à celle du stock nécessaire pour réponde à la demande à venir. Le moteur de prévisions de Lokad offre un mode de « prévision du délai d'approvisionnement » parfaitement adapté à ce type d’estimation. En effet, les délais d'approvisionnement doivent être prévus de la même façon que la demande. De plus, les délais d'approvisionnement présentent certaines particularités statistiques telles que la saisonnalité ou l’effet des jours de la semaine. Les prévisions de délai d'approvisionnement produites par le moteur de prévisions de Lokad sont « probabilistes » : elles représentent la probabilité de chaque délai d'approvisionnement exprimé en jours. Dans le présent article, nous détaillons la syntaxe utilisée pour calculer les prévisions de délai d'approvisionnement via Lokad.

Syntaxe générale

Le moteur de prévisions dispose d’une fonction spéciale désignée sous le terme « fonction d’appel » dans la terminologie Envision. La syntaxe est la suivante :

// "PO" pour PurchaseOrders (commandes d'achat)
Leadtime = forecast.leadtime(
category: C1, C2, C3, C4
hierarchy: H1, H2, H3, H4
supplier: Supplier
offset: 0
present: (max(Orders.Date) by 1) + 1
leadtimeDate: PO.Date
leadtimeValue: PO.ReceivedDate - PO.Date + 1
leadtimeSupplier: PO.Supplier)

À la différence des fonctions classiques, les fonctions d’appel utilisent des arguments « nommés » et non des arguments « positionnels ». Ces arguments nommés sont plus adaptés aux fonctions complexes car ils rendent le code source plus lisible, sans trop de verbosité supplémentaire. Ils fonctionnent comme des arguments de fonction normaux et permettent donc d’utiliser les expressions Envision.

La fonction renvoie le vecteur Leadtime, qui est du type « distribution » (voir également L’algèbre des distributions). Les distributions appartiennent à un type de données avancé qui représente les fonctions $p : \mathbb{Z} \to \mathbb{R}$. Plus spécifiquement, le moteur de prévisions renvoie des « variables aléatoires », c’est à dire des distributions « positives » dont la « masse » est égale à 1. Dans le cas présent, $p(k)$ représente la probabilité d’un délai d'approvisionnement de $k$ jours. Chaque article, au sens Envision, est associé à sa propre distribution.

La syntaxe forecast.leadtime complète comprend de nombreux arguments mais seuls deux sont obligatoires :

• present : une valeur de date scalaire ;
• leadtimeDate : un vecteur de date spécifique à un article ;
  

La valeur present correspond à la date du premier jour concerné par les prévisions, à condition que les données soient complètes jusqu’au jour précédent. En effet, certaines entreprises ferment le dimanche par exemple et, si la date la plus récente trouvée dans les données est un samedi, les prévisions doivent-elles démarrer le dimanche ou le lundi ? Dans l’exemple ci-dessus, nous utilisons max(Orders.Date) + 1, en faisant l'hypothèse que des commandes sont passées chaque jour et que les dernières données d’entrées datent de la veille.

leadtimeDate et leadtimeValue doivent appartenir à la même table spécifique à un article, ce qui se traduit par Id, * dans la terminologie Envision. Les dates correspondent au jours à partir desquels les délais d'approvisionnement sont observés. Les valeurs doivent être exprimées en jours. Les fractions de jours ne sont pas prises en charge. Cette table contient l'historique des délais d'approvisionnement prévus par le moteur de prévisions.

Lorsque leadtimeValue n'est pas fourni, les durées successives entre les dates leadtimeDate sont utilisées en tant que valeurs des délais. Ce fonctionnement est conçu pour prévoir le délai « de commande » ; ces prévisions sont généralement séparées de celles du délai « d'approvisionnement ».

Dans l’idéal, l’historique est aussi long que possible même si, en pratique, les avantages sont limités au delà de 5 ans d’historique. Le moteur de prévisions traite indifféremment les historiques longs et courts. Lorsque l’historique est long les points de données les plus anciens disparaissent dans la non-pertinence statistique.

En plus de ces arguments obligatoires, l’exactitude des prévisions peut être grandement améliorée en fournissant plus de données au moteur de prévisions. La section suivante l’explique en détails.

Catégories et hiérarchie

Les catégories et la hiérarchie jouent un rôle similaire du point de vue du moteur de prévisions : elles l’aident à gérer des données historiques rares. En effet, pour un article donné, le nombre de délais d'approvisionnement constatés peut être très limité, seuls quelque-uns par an parfois. Dans ce cas, la prévision d’un délai d'approvisionnement futur uniquement à partir des donnés disponibles pour l’article en question est relativement inexacte car l’estimation est très perturbée.

Le moteur de prévisions de Lokad résout ce problème en exploitant les corrélations qui existent entre les délais d'approvisionnement constatés. Cependant, puisque les délais d'approvisionnement sont rares, les corrélations sont difficiles à établir uniquement à partir de leurs valeurs. Par conséquent, le moteur de prévisions essaie d’exploiter les relations entre articles.

La « hiérarchie » est prévue pour une organisation hiérarchique des articles (arborescence). Le moteur de prévisions peut prendre en charge jusqu’à 4 niveaux de hiérarchie. Lorsqu’il existe plusieurs niveaux de hiérarchie, ces derniers doivent être fournis au moteur de prévisions par ordre d’importance décroissant (le premier argument doit représenter le niveau le plus élevé). Le moteur de prévisions ne peut gérer plusieurs hiérarchies.

Les « catégories » sont prévues pour différentes catégorisations d’articles pertinentes dans le cadre de prévisions. En pratique, les catégories peuvent être utilisées pour illustrer des attributs d’articles relativement divers comme la marque, le matériau ou la couleur. Les catégories peuvent également servir à représenter une hiérarchie secondaire. Le moteur de prévisions peut prendre en charge jusqu’à 4 attributs de catégorie distincts.

En pratique, nous vous recommandons d’utiliser une hiérarchie « canonique » et une catégorisation des articles utilisée classiquement dans votre domaine d’activité. Le moteur de prévisions résiste bien aux perturbations. Ainsi, même si ce n’est pas bon de lui fournir des données de mauvaise qualité, il vaut presque toujours mieux lui indiquer une catégorie qui n’est, en fait, pas utilisée en interne, que lui fournir uniquement des délais d'approvisionnement constatés.

Fournisseur

Le choix du fournisseur joue souvent un rôle important dans l’estimation du délai d'approvisionnement. Les données sur les fournisseurs peuvent être transmises au moteur de prévisions de deux façons complémentaires.

Tout d’abord, l’historique des délais d'approvisionnement constatés peut être « catégorisé par fournisseur ». C’est l’objectif de l'argument leadtimeSupplier. Lorsque cet argument est présent, le moteur de prévisions exploite cette information pour déterminer si les délais d'approvisionnement associés à un fournisseur donné sont corrélés ou non. Les informations sur les fournisseurs affinent les données par rapport à une simple hiérarchie d’articles ou à des catégories, car les articles peuvent être issus de fournisseurs différents en fonction du temps.

Ensuite, il est possible d’indiquer au moteur de prévisions le « fournisseur à utiliser pour l’expédition suivante ». C’est l’objectif de l'argument supplier. Lorsque cet argument est présent, le moteur de prévisions peut anticiper des modifications soudaines du délai d'approvisionnement d’un article dues à un changement de fournisseur. Naturellement, le moteur de prévisions ne peut exploiter cette information que si l’historique des délais d'approvisionnement est correctement catégorisé par fournisseurs, comme indiqué ci-dessus.

Décalages de délai d'approvisionnement

Par défaut, les prévisions commencent au jour present (présent). Cependant, parfois, il peut être nécessaire de les faire démarrer plus tard. Si les délais d'approvisionnement sont saisonniers, leur date de début peut avoir des conséquences significatives sur la distribution de la valeur. Les propriétés offset permettent de gérer ce cas. Cette propriété facultative attend un vecteur numérique de la table « items » (articles). Les valeurs de ce vecteur représentent les décalages, en jours, à prendre en compte pour les prévisions des délais d'approvisionnement. Par exemple, si le décalage d’un article est de 10, le premier jour de la prévision du délai d'approvisionnement sera present + 10. Lorsque offset n’est pas inclus, tous les décalages sont considérés comme nuls.