Agrégation des données au jour à la semaine et au mois

Agrégations au jour, à la semaine et au mois


Accueil » Ressources » Ici

La notion d'agrégation des données au jour, à la semaine ou au mois présente plusieurs difficultés subtiles, à commencer par les définitions respectives du jour, de la semaine et du mois. Cet article présente l'approche adoptée par Lokad pour gérer ces agrégations, à la fois au niveau des données en entrée (données historiques) et au niveau des données en sortie (prévisions). Cet article a également pour but de fournir des conseils pour la gestion - qui est en pratique variée - des conventions d'agrégation de données.


Terminologie : item et commande

Les termes item et commande renvoient à un format de données en entrée (page en anglais) de Lokad. Dans cet article, ces termes doivent être compris tels qu'ils sont définis dans Lokad. Un item représente une cible pour laquelle il faut fournir une prévision. Un item peut être un article, un produit, une SKU, ou un code-barre selon votre activité. Une commande représente une quantité associée à un item à une date donnée dans le passé. Une commande peut être une vente, une livraison au client, ou une consommation selon le contexte.

Les agrégations telles que définies dans Lokad

Lokad se base sur les conventions suivantes :

  • Les jours débutent à 00h00 du matin ; par conséquent, chaque valeur de prévision journalière couvre une période débutant à 00h00 et se terminant à 23h59:59.
  • Les semaines débutent le Lundi ; par conséquent, chaque valeur de prévision hebdomadaire couvre une période débutant un Lundi (inclus) et se terminant un Dimanche (inclus).
  • les mois débutent le 1er du mois ; par conséquent, chaque valeur de prévision mensuelle couvre une période débutant le 1er du mois et se terminant le dernier jour du mois.

Ces conventions de base ne peuvent être changées dans Lokad. Toutefois, nous présentons par la suite un moyen de gérer d'autres conventions dont certaines entreprises peuvent avoir besoin.

Tolérance envers les modèles d'agrégation en entrée

Lokad s'efforce d'être tolérant lors du traitement des données historiques. En particulier, bien que nous recommandions d'appliquer une agrégation à la journée - c'est-à-dire d'additioner toutes les commandes d'une journée donnée en une seule quantité pour un item donné - Lokad accepte également d'autres situations.

Historique de données brutes non agrégées

L'agrégation à la journée réduit la taille du jeu de données à télécharger vers Lokad. Cette réduction ne présente aucun inconvénient du point de vue la précision des prévisions. Cependant, si le jeu de données est relativement petit au départ, alors le gain est négligeable. Par conséquent, Lokad peut également traiter un historique entièrement non agrégé, avec une ligne par transaction. Dans ce cas, les quantités journalières sont calculées comme la somme des valeurs des commandes pour un item donné et un jour donné.

Historique pré-agrégé à la semaine ou au mois

Il arrive parfois que l'historique de données agrégées à la journée n'ait pas été conservé dans le système de l'entreprise dont les données en entrée sont issues, et que seules restent les données agrégées à la semaine ou au mois. Dans ce cas, Lokad est tout à fait capable de traiter des commandes pré-agrégées à la semaine ou au mois.

Si les données sont agrégées à la semaine, Lokad doit alors être restreint à des prévisions classiques hebdomadaires. Nous déconseillons d'utiliser les prévisions journalières, mensuelles ou quantiles, car les résultats statistiques seraient dépourvus de sens. De la même manière, si les données sont agrégées au mois, Lokad doit être restreint à des prévisions mensuelles classiques.

L'inconvénient principal des données pré-agrégées est la contrainte que cela fait peser sur la nature des prévisions pouvant être produites. Il est également un autre inconvénient, qui est une perte mineure de précision. En effet, Lokad est capable d'exploiter des comportements journaliers pour affiner les prévisions, y compris dans le cas de prévisions hebdomadaires ou mensuelles.

Quand commencent les prévisions ?

Pour générer une prévision, Lokad définit un seuil qui représente le présent, c'est-à-dire le point où vont débuter les prévisions. Pour pouvoir déterminer ce seuil, Lokad adopte principalement un point de vue centré sur les données : les prévisions débutent là où les données historiques s'arrêtent. Par exemple, si les données historiques s'arrêtent au 15 mai (inclus), alors les prévisions journalières commenceront le jour suivant, soit le 16 mai.

Le point de vue centré sur les données est pratique, en particulier pour effectuer des comparatifs. Les données peuvent être tronquées à un point donné dans le passé, et Lokad peut ensuite générer des prévisions qui peuvent immédiatement être comparées avec les données historiques non tronquées, puisque les prévisions elles-mêmes portent alors sur le passé.

Sur ce point, les prévisions classiques et quantiles se comportent de la même manière : la prévision débute toujours le jour qui suit la commande la plus récente trouvée dans les données en entrée.

Dans le cas de prévisions classiques hebdomadaires ou mensuelles, la situation est plus subtile. Supposons par exemple que les données historiques (c'est-à-dire les commandes dans la terminologie de Lokad) s'arrêtent au 15 mai : les prévisions doivent-elles alors commencer le 1er mai ou le 1er juin ? La réponse apportée par Lokad est que les prévisions commencent au 1er mai. En effet, puisque les données sur le mois de mai ne sont encore que partielles, Lokad tronque les données au dernier jour d'avril, afin de pouvoir fournir pour mai une prévisions mensuelle classique normale(*).

(*) Techniquement, il serait possible de créer des modèles de prévision capables d'exploiter les données sur des périodes partielles. Cependant, cela représenterait une fonctionnalité très complexe, qui n'est pas supportée par Lokad à l'heure actuelle.

Données agrégées à la semaine ou au mois

Dans le cas de données agrégées au mois (ou à la semaine), la conduite de Lokad consistant à tronquer les données peut mener à des résultats non souhaités. Supposons par exemple que nous avons un historique de commandes agrégé au mois, avec une unique commande pour chaque 1er jour du mois. Supposons ensuite que le 1er mai 2013 représente la dernière date de l'historique de données. Dans ce cas, Lokad interprète le mois de mai comme n'étant que partiellement observé ; par conséquent, mai se trouve tronqué, et les prévisions commencent le 1er mai. Or, étant donné que, dans ce cas, le point de données du 1er mai constitue à lui seul l'ensemble des commandes de mai, ce comportement n'est pas souhaitable.

Afin d'éviter cette troncature, il est recommandé d'insérer une unique ligne commande - la quantité affectée étant zéro - à la date représentant le dernier jour du mois en cours. Dans cet exemple, l'introduction d'une ligne de commande datée du 31 mai indique à Lokad que le mois de mai est complet, et que, par conséquent, les prévisions doivent démarrer au 1er juin. Une technique similaire, consistant en l'insertion d'une ligne de commande avec une quantité zéro, peut être utilisée pour le même type de problème sur les prévisions hebdomadaires.

Il est à noter qu'ajouter une ligne de commande "factice" de ce type aurait un impact négatif sur les prévisions quantiles effectuées en parallèle des prévisions mensuelles classiques dans Lokad. En pratique, lorsque les données sont agrégées au mois, il ne faut pas utiliser les prévisions quantiles.

Nettoyage des données futures, une exception au point de vue centré sur les données

Il existe une exception au point de vue centrée sur les données : afin de nettoyer les données, Lokad filtre les commandes qui sont datées de plus d'une semaine dans le futur (le futur étant ici défini sur la base de l'horloge interne du serveur de Lokad).

En effet, nous observons régulièrement que certains de nos clients se retrouvent avec des artefacts dans leurs systèmes, datés dans un futur plus ou moins proche. Ces lignes ne sont généralement pas de véritables ventes ou livraisons, mais le résultat de divers tests effectués à un moment ou un autre sur le système de l'entreprise.

A l'évidence, d'un point de vue métier, se baser sur des données historiques qui ne devraient pas encore exister a peu de sens. Par conséquent, Lokad tronque ces données dans une procédure de nettoyage, puis reprend les processus de prévision après coup.

Agrégations alternatives mensuelle ou hebodmadaire

Du point de vue de Lokad, la période mensuelle débute toujours le 1er du mois. Néanmoins, certaines entreprises ont besoin d'appliquer des conventions différentes, en décrétant par exemple que chaque période commence le 25ème jour du mois.

Pour gérer ce type de situations, nous recommandons de pré-agréger les historiques de commandes aux périodes souhaitées. Dans l'exemple cité, la période allant du 25 mai au 24 juin serait agrégée en une seule ligne de commande. Cette ligne représente ainsi la valeur mensuelle sur mesure pour l'item choisi, et doit être positionnée au 1er jour du mois précédant la période d'origine (soit au 1er mai dans le cas présent). Lokad génère ainsi des prévisions débutant au 1er jour du mois, qui peuvent alors être retranscrites et interprétées selon la convention d'origine (par exemple comme correspondant au 25 du mois).

Il est important d'utiliser une date qui précède la période visée ; dans le cas contraire, une partie des données qui en résultent peut se retrouver positionnée trop en avant dans le futur et être tronquées par Lokad en application de la règle de troncature des données futures pour des raisons de nettoyage (cf. ci-dessus).