Problèmes courants et solutions correspondantes

Cela est le plus souvent dû à des collisions de clés composites : si deux enregistrements partagent le même identifiant unique, l'un remplace l'autre.

Cela peut également se produire si les critères de filtre du mappage des données excluent les enregistrements que vous vous attendez à voir.

Les commandes traitées ou supprimées entre les séries de rapports disparaîtront lors de la prochaine actualisation, mais peuvent toujours apparaître dans les exceptions générées à partir des données de la veille.

Les commandes nouvellement créées n'apparaîtront pas avant la prochaine actualisation des données.

Le système filtrera automatiquement vers le produit principal. Seuls les produits présents dans votre fiche principale de produit seront inclus dans les prévisions. Toutefois, si un pourcentage important de votre fichier d'entrée est hors de portée (par exemple, plus de 50 % des lignes), cela indique que l'exportation source doit être resserrée.

Vérifiez régulièrement le taux de couverture de votre produit. Après chaque chargement de données, vérifiez quel pourcentage de produits dans vos fichiers d'entrée de ventes et de prévisions correspond au produit principal. Si la couverture tombe en dessous de 80 %, vérifiez si la zone d'exportation source a changé ou si le produit principal doit être mis à jour.

Out-of-scope les produits figurant dans les entrées du plan peuvent entraîner des totaux gonflés. Si vos fichiers EDI ou SIOP incluent des produits provenant d'autres usines, le signal de prévision global sera plus élevé qu'il ne devrait l'être. Assurez-vous que les fichiers d'entrée du plan sont filtrés selon la même gamme de produits que votre produit principal avant le chargement.

Vérifiez l'horodatage de l'exception. Si elle date de plus d'un jour, la recommandation est peut-être périmée.

Si la recommandation est clairement erronée (par exemple, si elle ignore une commande importante visible dans le graphique), faites part de vos commentaires en utilisant le pouce vers le bas et signalez l'exception spécifique à votre équipe d'assistance.

La date d'impact indique le début du problème de stock (par exemple, lorsque la rupture de stock commence ou que l'excédent dépasse le seuil).

La date limite de traitement doit tenir compte du délai afin que vous ayez le temps d'agir avant que le problème ne se matérialise. Si Act By est égal à la date d'impact, le délai peut ne pas être intégré. Signalez-le à votre équipe d'assistance.

Trop de volume/inactive produits bas de gamme dans le champ d'application. Il est difficile, quel que soit le modèle, de battre une simple moyenne pour les produits dont la demande est faible et intermittente. Utilisez une règle de prétraitement pour limiter la prévision aux produits dont l'historique de la demande est significatif (par exemple, au moins 6 mois de demande non nulle).

Formation sur l'histoire viciée ou contaminée. Si l'historique de vos commandes remonte à de nombreuses années, les anciens modèles de demande peuvent ne pas refléter la réalité actuelle. Envisagez une règle de prétraitement pour limiter l'historique d'entraînement aux 3 à 5 dernières années ou pour remplacer les périodes anormales (par exemple, COVID) par des valeurs normalisées.

La demande augmente en raison des commandes ponctuelles. Une seule commande groupée importante peut créer une fausse tendance à la hausse des données de formation. Utilisez une règle de prétraitement pour plafonner les valeurs de demande mensuelles anormales à un multiple de la moyenne finale (par exemple, 5x).

Les règles du consensus ne sont pas appliquées dans le bon sens. L'agent LLM peut mal interpréter le langage des règles. La « diminution de 27 % » peut être appliquée comme une augmentation. Validez toujours les résultats du consensus par rapport à la base de référence en comparant des produits et des mois spécifiques. Utilisez un langage de multiplication explicite (« multiplier par 0,725 ») plutôt qu'un langage directionnel (« diminuer de 27,5 % »).

Le modèle est entraîné sur une période de croissance. Si les dernières années ont montré une croissance qui ne se poursuit pas, le modèle extrapole une tendance qui n'existe plus.

Les règles de consensus cumulent les ajustements à la hausse. Plusieurs règles qui, chacune, augmentent les prévisions (biais de rupture de stock, accélération de la tendance, hausse saisonnière) peuvent s'aggraver. Vérifiez quelles règles sont actives et vérifiez si elles s'appliquent toutes aux mêmes produits.

Deleted/discontinued produits toujours concernés. Les produits dont la demande est en baisse et qui sont toujours en cours de prévision feront l'objet d'une surestimation systématique.

Les signaux de prévision externes ne sont pas incorporés. Si des entrées de plan (par exemple, des prévisions clients EDI, des plans de production SIOP) sont chargées mais que vos règles de consensus ne les appliquent pas, la prévision utilise par défaut la base statistique, qui peut ne pas capturer les signaux de demande visibles par vos planificateurs. Vérifiez que les règles de consensus modifient réellement la sortie en comparant l' ConsensusForecast exportation à l'exportation des prévisions (référence). S'ils sont identiques, les règles ne sont pas applicables.

Des combinaisons produit/site éparses qui réduisent l'agrégat vers le bas. Si vous établissez des prévisions selon la granularité produit par site mais que de nombreuses combinaisons présentent une demande nulle ou quasi nulle, le modèle produit de petites prévisions non nulles pour les combinaisons inactives. Ils ne totalisent pas grand-chose individuellement, mais collectivement, ils font glisser le total des prévisions en dessous des prévisions réelles. Utilisez une règle de prétraitement pour exclure les combinaisons dont l'historique des demandes est insuffisant, ou utilisez le remplissage conditionnel à zéro dans les entrées de votre plan pour signaler explicitement « aucune demande attendue » pour les combinaisons inactives.

Le modèle n'a pas reflété une tendance de croissance récente. Les modèles statistiques pondèrent les données historiques. Si votre entreprise a connu une croissance significative au cours des derniers mois, mais que le modèle a connu des années de baisse des volumes, il sera à la traîne par rapport à la tendance. Cela s'améliore généralement au fil du temps à mesure que le modèle accumule des données plus récentes. Dans l'intervalle, envisagez une règle consensuelle qui utilise une moyenne secondaire des données réelles récentes comme plancher pour les semaines de prévisions extérieures.

Year-over-year inadéquation de saisonnalité. Si la structure de la demande de cette année diffère de celle des années précédentes (par exemple, hausse saisonnière antérieure, lancements de nouveaux produits), le modèle peut sous-estimer les prévisions pendant la période divergente. Vérifiez si le biais secondaire est concentré sur des semaines ou des mois spécifiques qui diffèrent de la tendance de l'année précédente.

Les signaux externes ne sont utiles qu'à court terme. Si vous avez des règles consensuelles qui intègrent les prévisions clients (EDI) pour les premières semaines, la précision sera sensiblement meilleure à court terme et diminuera lorsque les règles cesseront de s'appliquer. C'est normal. Envisagez d'étendre les règles à un plus grand nombre de semaines grâce à une approche mixte (par exemple, 50/50 combinaison d'un signal externe et d'une base de référence pour les semaines à moyen terme).

Le niveau de référence revient à une moyenne à long terme à des horizons plus longs. Les modèles statistiques deviennent moins fiables à long terme et tendent vers la moyenne historique. Si la demande récente est supérieure à la moyenne historique, les dernières semaines sembleront sous-biaisées. Il s'agit d'un problème de comportement du modèle et non d'un problème de configuration.

La volatilité de la demande complique fondamentalement les horizons à long terme. Si votre demande présente une forte variabilité d'une semaine à l'autre (coefficient de variation > 0,5), même un modèle parfait affichera une erreur élevée à plus long terme. Concentrez l'évaluation de la précision sur les 3 à 4 premières semaines, qui constituent la fenêtre de planification exploitable pour la plupart des opérations.

Le signal externe peut ne pas couvrir suffisamment de produits. L'EDI ou les prévisions clients ne couvrent généralement qu'un sous-ensemble de votre catalogue de produits (souvent 30 à 50 %). Les produits sans signal externe utilisent toujours la ligne de base. Vérifiez votre taux de couverture : s'il est inférieur à 50 %, l'impact sur la précision globale sera limité.

Le signal externe n'est peut-être pas suffisamment précis pour vous aider. Mesurez la précision de la prévision externe de manière indépendante avant de l'utiliser dans des règles. Si son WAPE est inférieur à la valeur de référence, son incorporation fera mal au lieu d'aider. Envisagez de limiter la règle à des sites ou à des produits spécifiques où le signal externe est manifestement meilleur (par exemple, un WAPE pondéré en fonction du volume inférieur à 50 %).

Le signal externe ne rapporte pas de zéros. De nombreux systèmes EDI n'envoient des enregistrements que pour les produits dont les commandes sont actives. Ils omettent les produits pour lesquels la demande est nulle au lieu de signaler explicitement zéro. Si votre règle de consensus indique « lorsque EDI = 0, définissez la prévision sur 0 », elle ne se déclenchera jamais car il n'y a aucun enregistrement. Vous devez générer des enregistrements zéro synthétiques lors du prétraitement pour les combinaisons produit/site qui n'ont aucun signal externe ET aucun historique de ventes récent.

La précision du signal externe varie selon l'horizon. Les prévisions des clients sont généralement plus précises pour la semaine prochaine (essentiellement pour les commandes confirmées) et se dégradent rapidement. Une règle qui utilise le signal externe directement pendant toutes les semaines peut nuire à la précision à plus long terme. Envisagez une approche progressive : remplacement direct pour les semaines 1 à 3, mélange pour les semaines 4 à 6, référence uniquement pour les semaines 7 et plus.

La règle a peut-être été remplacée par une règle de priorité plus élevée. Les règles sont appliquées par ordre de priorité. Une règle ultérieure peut annuler une règle précédente. Vérifiez l'ordre des règles.

La condition de la règle peut ne correspondre à aucun produit. Si la règle fait référence à un attribut de produit (par exemple, product_group_id) qui ne figure pas dans les métadonnées de l'article, il ne correspondra à rien en silence.

Le libellé des règles a été mal interprété. L'agent LLM génère du code à partir du langage naturel. Une formulation ambiguë peut produire des résultats inattendus. Soyez aussi précis et littéral que possible. Utilisez des noms de champs exacts, des multiplicateurs explicites et des conditions claires.

Inadéquation des dimensions dans la jointure. Le moteur de consensus joint les entrées du plan à la référence dans les colonnes de dimensions (ID du produit, ID du site, date). Si les noms des colonnes diffèrent entre la référence et les entrées du plan (par exemple, la référence utilise item_id tandis que l'EDI utilise product_id), la jointure ne produit aucune correspondance et toutes les règles passent à la valeur de référence par défaut. Vérifiez que le mappage des dimensions dans la configuration de votre flux de données correspond correctement aux deux schémas.

Incompatibilité du format de date. La base de référence peut stocker les dates sous la forme 2026-03-02 tandis que les entrées du plan les stockent sous la forme 2026-03-02. T00:00:00.000Z Si la jointure nécessite une correspondance exacte, les dates tenant compte du fuseau horaire et celles ne correspondant pas au fuseau horaire ne correspondront pas. Vérifiez que les colonnes de date sont converties dans le même format avant de les joindre.

Les entrées du plan ne sont pas chargées. Vérifiez que les fichiers d'entrée de votre plan (EDI, SIOP, etc.) ont été correctement ingérés. Vérifiez le nombre d'enregistrements dans le système : s'il n'affiche aucune ligne pour une entrée de plan, le fichier n'a peut-être pas pu être chargé.

Le forecast_id consensuel correspond au forecast_id de référence. Si les deux exportations partagent le même forecast_id, le moteur de consensus a produit une copie directe de la référence sans traitement. Cela indique un problème au niveau du système. Contactez votre équipe d'assistance avec le forecast_id et le demand_plan_run_id.

L'état du site/product filtre peut faire référence à la mauvaise colonne. Si votre règle indique « appliquer aux sites de [liste] » mais que le code généré vérifie une colonne qui n'existe pas ou dont les valeurs sont différentes, le filtre peut transmettre silencieusement toutes les lignes. Vérifiez en repérant quelques produits spécifiques qui ne devraient PAS être concernés par la règle.

L'ordre de priorité des règles peut être inversé. Les règles sont appliquées sous la forme d'une chaîne dans laquelle les règles ultérieures remplacent les règles précédentes. Si une règle générale (par exemple, « utiliser une base de référence pour tout ») est appliquée après une règle spécifique (par exemple, « utiliser l'EDI pour ces 50 sites »), la règle générale annulera la règle spécifique. Assurez-vous que les descriptions de vos règles indiquent clairement l'ordre de priorité.

Ajoutez une règle d'arrondissement comme étape finale du consensus. Une simple règle « arrondir à l'entier le plus proche » appliquée après toutes les autres règles de consensus nettoiera les valeurs fractionnaires. Les valeurs inférieures à 0,5 seront arrondies à zéro, ce qui est approprié pour les combinaisons à très faible demande.

Envisagez d'arrondir aux quantités opérationnelles. Si vos produits sont expédiés dans des emballages standard (par exemple, des caisses de 12, des palettes de 48), le fait d'arrondir au format d'emballage valide le plus proche peut améliorer à la fois la facilité d'utilisation et la précision des prévisions. Cela nécessite que les données relatives à la taille de l'emballage figurent dans votre fiche produit. Partagez vos données relatives au MOQ ou à la taille de l'emballage avec votre équipe d'assistance pour explorer cette option.

Vérifiez la granularité. Un produit peut avoir 52 semaines de demande au niveau du produit, mais seulement 3 semaines pour une combinaison produit/site individuelle. Un seuil d'historique minimum appliqué au niveau du produit par site exclura la plupart des combinaisons. Envisagez plutôt d'appliquer le seuil au niveau du produit ou de l'abaisser de manière significative.

Testez avant le déploiement. Avant d'activer une règle de prétraitement, comptez le nombre de combinaisons produit/site qui passent le filtre par rapport à votre total actuel. Si plus de 20 % sont exclus, la règle est probablement trop agressive. Commencez par un seuil clément et resserrez-le progressivement.