Problèmes courants et solutions correspondantes

Cela est le plus souvent dû à des collisions de touches 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 filtrage du mappage des données excluent les enregistrements que vous vous attendez à voir.

Les commandes traitées ou supprimées entre deux séries de rapports disparaîtront lors de la prochaine actualisation, mais elles 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 fichier principal 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 de la 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 le périmètre d'exportation de la source a changé ou si le product master doit être mis à jour.

Out-of-scope les produits contenus dans les entrées du plan peuvent entraîner une augmentation des totaux. Si vos fichiers EDI ou SIOP incluent des produits provenant d'autres usines, le signal de prévision global sera supérieur à ce qu'il devrait être. Assurez-vous que les fichiers d'entrée du plan sont filtrés selon le même type de produit que celui de 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), envoyez des 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 d'expiration doit tenir compte du délai afin que vous ayez le temps d'agir avant que le problème ne se concrétise. Si Act By est égal à la date d'impact, il est possible que le délai ne soit pas intégré. Signalez-le à votre équipe d'assistance.

Trop de volume/inactive produits bas de gamme dans le champ d'application. Les produits dont la demande est faible et intermittente sont difficiles à surpasser pour un modèle donné par une simple moyenne. Utilisez une règle de prétraitement pour étendre les prévisions aux produits présentant un historique de demande significatif (par exemple, au moins 6 mois de demande non nulle).

Formation sur des antécédents périmés ou contaminés. 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 de commandes uniques. Une seule commande groupée importante peut créer une fausse tendance à la hausse des données d'entraînement. Utilisez une règle de prétraitement pour plafonner les valeurs de demande mensuelles anormales à un multiple de la moyenne finale (par exemple, 5 fois).

Les règles consensuelles s'appliquaient dans le mauvais sens. L'agent LLM peut mal interpréter le langage des règles. La « diminution de 27 % » peut être appliquée sous forme d'augmentation. Validez toujours le résultat consensuel 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 la croissance des dernières années ne se poursuit pas, le modèle extrapole une tendance qui n'existe plus.

Les règles consensuelles s'accompagnent d'ajustements à la hausse. Plusieurs règles qui augmentent chacune 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 vous avez des entrées de plan (par exemple, des prévisions clients EDI, des plans de production SIOP) chargées mais que vos règles de consensus ne les appliquent pas, les prévisions sont établies par défaut sur la base statistique de référence, qui peut ne pas prendre en compte les signaux de demande que voient vos planificateurs. Vérifiez que les règles de consensus modifient réellement le résultat en comparant l' ConsensusForecast exportation à l'exportation Forecast (ligne de base). Si elles sont identiques, les règles ne s'appliquent pas.

Les rares combinaisons produit×site font baisser l'agrégat. Si vous faites des prévisions selon une granularité produit × site mais que de nombreuses combinaisons présentent une demande nulle ou proche de zéro, le modèle produit de petites prévisions différentes de zéro pour les combinaisons inactives. Ils ne s'additionnent pas beaucoup individuellement, mais font glisser collectivement les prévisions totales 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 affiche 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 des derniers chiffres réels comme plancher pour les semaines de prévision extérieures.

Year-over-year inadéquation de la 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 plus précoce, lancement de nouveaux produits), le modèle peut sous-estimer les prévisions pendant la période divergente. Vérifiez si le sous-biais se concentre 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 disposez de règles consensuelles qui intègrent les prévisions clients (EDI) pour les premières semaines, la précision sera nettement meilleure à court terme et diminuera lorsque les règles cesseront de s'appliquer. Cela est attendu. Envisagez d'étendre les règles pour couvrir un plus grand nombre de semaines avec 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 semaines extérieures apparaîtront sous-biaisées. Il s'agit d'un problème de comportement de modèle et non d'un problème de configuration.

La volatilité de la demande complique par nature les horizons à long terme. Si votre demande présente une forte variabilité d'une semaine à l'autre (coefficient de variation supérieur à 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, période 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 assez précis pour vous aider. Mesurez la précision des prévisions externes de manière indépendante avant de les utiliser dans les règles. Si son WAPE est inférieur à la valeur de référence, son incorporation fera du mal au lieu de l'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 signale 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 dont la demande est nulle au lieu de signaler explicitement zéro. Si votre règle de consensus indique « lorsque EDI = 0, réglez les prévisions sur 0 », elle ne se déclenchera jamais car il n'y a aucun enregistrement. Vous devez générer des enregistrements synthétiques nuls lors du prétraitement pour les combinaisons produit×site qui n'ont aucun signal externe ET aucun historique des ventes récent.

La précision du signal externe varie en fonction de l'horizon. Les prévisions des clients sont généralement les plus précises pour la semaine suivante (essentiellement des 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 par étapes : remplacement direct pendant les semaines 1 à 3, mixte pendant les semaines 4 à 6, valeur de 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 antérieure. 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 langage 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.

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

Incompatibilité du format de date. La base de référence peut stocker les dates au 02/03/2026 tandis que les entrées du plan les stockent au 02/03/2026. T00:00:00.000Z Si la jointure nécessite une correspondance exacte, les dates sensibles au fuseau horaire et les dates naïves ne correspondront pas. Vérifiez que les colonnes de date sont converties au 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'ils n'affichent aucune ligne pour une entrée de plan, le fichier n'a peut-être pas pu être chargé.

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

La condition 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 qui possède des valeurs différentes, le filtre peut transmettre toutes les lignes en silence. Vérifiez en vérifiant ponctuellement 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 où les règles ultérieures remplacent les précédentes. Si une règle générale (par exemple, « utiliser la 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 convient aux 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, caisses de 12, palettes de 48), l'arrondissement 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 notice de produit. Partagez votre MOQ ou les données relatives à la taille du pack 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 toute combinaison produit × site individuel. Un seuil d'historique minimum appliqué au niveau du produit × 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 de déployer. 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 indulgent et resserrez progressivement.