Continuer à apprendre avec
LOKAD TV
Demand = forecast.demand( category: C1, C2, C3, C4 hierarchy: H1, H2, H3, H4 label: PlainText demandStartDate: LaunchDate demandEndDate: EndDate horizon: Leadtime offset: 0 present: (max(Orders.Date) by 1) + 1 demandDate: Orders.Date demandValue: Orders.Quantity // « SO » pour stock-outs censoredDemandDate: SO.StartDate, SO.EndDate inflatedDemandDate: TVAds.StartDate, TVAds.EndDate // « Promos » pour promotions promotionDate: Promos.StartDate, Promos.EndDate promotionDiscount: Pros.Discount promotionCategory: Promos.Type)
Demande
, 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é une demande de $k$ unité(s). Chaque article, au sens Envision, est associé à sa propre distribution de la demande.forecast.integral
complète comprend de nombreux arguments mais seuls quatre sont obligatoires :present
: une valeur de date scalaire ;demandDate
: un vecteur de date spécifique à un article ;demandValue
: un vecteur numérique spécifique à un article ;horizon
: un vecteur de distribution.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.demandDate
et demandValue
doivent appartenir à la même table spécifique à un article, ce qui se traduit par [Id, *]
dans la terminologie Envision. Les dates correspondent aux moments auxquels la demande a été constatée par le passé. Les valeurs représentent le niveau de la demande, qui est généralement comptabilisé en « unités » ou en « pièces ». Seuls les niveaux de demande entiers sont pris en charge. Cette table contient l'historique de la demande prévue par le moteur de prévisions. 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.horizon
représente les délais d'approvisionnement probabilistes à utiliser pour prévoir la demande. Les délais d'approvisionnement sont traités comme des données d’entrée du calcul des prévisions intégrées de la demande, bien qu’ils soient eux-même des prévisions. Le moteur de prévisions offre en effet la possibilité de prévoir les délais d'approvisionnement. Les prévisions des délais d'approvisionnement sont découplées des prévisions de la demande, ainsi les distributions des délais d'approvisionnement peuvent être ajustées avant d’être utilisées par le moteur de prévisions.demandStartDate
. Lorsque le début de l’historique est connu, il est souhaitable de fournir cette donnée au moteur de prévisions afin d’améliorer l’exactitude des prévisions associées à la fois aux anciens et nouveaux produits.demandStartDate
permet d’indiquer une date pour chaque article. Cette date représente le jour à partir duquel la demande doit être prise en compte pour l’article. Elle est passée pour les articles qui ont déjà été vendus et future pour ceux qui vont être mis en vente.demandStartDate
présente deux avantages. Bien sûr, le premier est de permettre l’obtention de prévisions associées à un nouveau produit. Dans ce cas, l’argument offset
doit aussi être renseigné. En effet, si le décalage reste à zéro — sa valeur par défaut — la période couverte par les prévisions peut ne pas couvrir la période « active » de l’article.demandStartDate
permet également d’augmenter la précision des prévisions associées à « tous » les articles et pas uniquement à ceux dont le lancement est encore à venir. En effet, une première unité vendue le jour du lancement d’un produit n’a pas la même signification que six mois après ce lancement. Dans le premier cas, les ventes s’annoncent régulières alors que dans le second la demande semble limitée à quelques unités par an. Ainsi, le moteur de prévisions exploite l’argument demandStartDate
pour affiner les prévisions associées à « tous » les articles.censoredDemandDate
et inflatedDemandDate
. Ces derniers attendent un vecteur de date spécifique à un article, c’est à dire (Id, Date)
en termes Envision.censoredDemandDate
, le moteur de prévisions fait l’hypothèse que la demande réelle était supérieure ou égale à la valeur constatée. Aucune hypothèse de volume n’est posée concernant la demande à cette date puisque la valeur réelle ne peut pas être connue. Pourtant, en identifiant le biais, le moteur peut faire appel à des classes d’optimisation adaptées à ce cas. En pratique, la demande est le plus souvent limitée par des « ruptures de stock » lorsqu’elle est observée à travers les ventes, qui ne comptabilisent pas les clients repartis bredouilles. inflatedDemandDate
offre la possibilité d’identifier les dates et les articles pour lesquelles la demande réelle doit être considérée inférieure ou égale à la demande constatée. Ici encore, la demande réelle reste inconnue mais l’identification du biais est déjà très utile au moteur de prévisions. En pratique, la demande est le plus souvent exagérée lorsque le marché est stimulé par un événement temporaire non récurrent : la victoire d’une équipe de sport locale à un championnat national peut avoir des conséquences positives sur les ventes des supermarchés locaux pendant quelques jours. inflatedDemandDate
et censoredDemandDate
peuvent recevoir un ou deux vecteurs. Si deux vecteurs de dates sont fournis, les couples « (start, end) » définissent des segments inclusifs. La première date est la date de début du segment et la seconde celle de fin. Lorsqu'un seul vecteur de date est fourni, les segments utilisés correspondent une journée : les dates donnent les jours exacts où la demande doit être considérée comme limitée ou exagérée.promotionDate
. Ce dernier est utilisé de la même façon que censoredDemandDate
: lorsqu’un seul vecteur de date est fourni, la durée considérée des périodes promotionnelles est d’une journée et, si deux vecteurs sont fournis, le premier représente les dates de début et le second les dates de fin (ces bornes étant incluses dans l’intervalle ainsi défini).promotionDiscount
est facultatif et peut être fourni afin d’aider le moteur de prévisions à connaître « l’intensité » de la promotion en question. Un vecteur numérique est attendu pour cet argument et le moteur de prévisions traite ces données comme des valeurs « ordinales » : plus la ristourne est importante plus l’impact espéré de la promotion est grand. En pratique, c’est le moteur de prévisions qui calcule l’augmentation de la demande à prévoir à partir des augmentations observées lors de promotions précédentes.promotionCategory
est également facultatif et peut être fourni afin de classer les événements promotionnels. Lorsqu’il est fourni, il est utilisé par le moteur de prévisions pour tester les affinités entre événements promotionnels et détecter si des événements d’une même catégorie augmentent de la demande dans les mêmes proportions. Cet argument est similaire à l’argument category
mais s’applique aux promotions et non aux articles.inflatedDemandDate
. Le signalement d’une période via les deux arguments promotionDate
et inflatedDemandDate
a une signification précise : l’augmentation de la demande a été plus importante que prévu et la promotion elle-même doit être considérée comme biaisée.