Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Problemi e soluzioni comuni
Problemi comuni relativi ai dati
La cronologia della domanda ha formati di data misti
I sistemi di origine possono esportare le date come DD/MM/YYYY MM/DD/YYYY, o YYYY-MM-DD, a volte, all'interno dello stesso file. Il sistema potrebbe analizzarle in modo errato, assegnando gli ordini a mesi errati.
Correzione: standardizza i formati delle date nel processo di esportazione. Se non riesci a controllare l'origine, aggiungi la convalida della data nel tuo flusso di dati SQL.
Quantità negative nella cronologia degli ordini
Le note di credito, i resi o gli storni possono apparire come quantità negative. Queste possono distorcere le medie della domanda e confondere il modello.
Correzione: filtrare solo in base alle quantità positive o filtrare in base allo stato dell'ordine (ad esempio, solo Paid/Invoiced gli ordini).
I conteggi dei record non corrispondono al tuo sistema di origine
La causa più comune è la collisione di chiavi composite: se due record condividono lo stesso identificatore univoco, uno sovrascrive l'altro.
Può verificarsi anche se i criteri di filtro nella mappatura dei dati escludono i record che ti aspetti di vedere.
Fornisci un esempio specifico di prodotto+sito e il numero di record previsto in modo che il team possa tracciare la discrepanza.
Nel sistema vengono visualizzati gli ordini che non esistono nell'ERP (o viceversa)
Gli ordini evasi o rimossi tra una serie e l'altra del rapporto scompariranno dall'aggiornamento successivo, ma potrebbero comunque apparire nelle eccezioni generate dai dati del giorno precedente.
Gli ordini appena creati verranno visualizzati solo al successivo aggiornamento dei dati.
Questo è il comportamento previsto: le eccezioni verranno aggiornate nel ciclo di valutazione successivo dopo il caricamento di nuovi dati.
I file di input del piano includono prodotti provenienti da altri stabilimenti o unità aziendali
Se le esportazioni del sistema di origine includono prodotti che non rientrano nell'ambito del progetto di previsione:
Il sistema filtrerà automaticamente in base alla descrizione del prodotto. Solo i prodotti presenti nel file principale del prodotto verranno inclusi nella previsione. Tuttavia, se una grande percentuale del file di input non rientra nell'ambito di applicazione (ad esempio, oltre il 50% delle righe), ciò indica che l'esportazione della fonte deve essere rafforzata.
Controlla regolarmente il tasso di copertura del tuo prodotto. Dopo ogni caricamento dei dati, verifica quale percentuale di prodotti nei file di input relativi alle vendite e alle previsioni corrisponde all'anagrafica del prodotto. Se la copertura scende al di sotto dell'80%, verifica se l'ambito di esportazione alla fonte è cambiato o se è necessario aggiornare il product master.
Out-of-scope i prodotti inseriti nel piano possono causare un aumento dei totali. Se i tuoi file EDI o SIOP includono prodotti di altri stabilimenti, il segnale previsionale aggregato sarà più alto di quanto dovrebbe essere. Assicuratevi che i file di input del piano siano filtrati in base allo stesso ambito del prodotto principale prima del caricamento.
Problemi comuni relativi alle eccezioni e alle raccomandazioni
Lo stesso prodotto+sito appare più volte nell'elenco delle eccezioni
Ciò può accadere quando la regola sottostante genera un'eccezione separata per ogni data valida nell'orizzonte di proiezione.
Contatta il tuo team di supporto per modificare la regola in modo da contrassegnare solo la prima data di violazione per prodotto+sito.
La raccomandazione non corrisponde a ciò che vedo nel grafico
La raccomandazione viene generata da un agente AI che analizza i dati disponibili al momento della creazione dell'eccezione. Se i dati sono cambiati da allora, la raccomandazione può fare riferimento a ordini o quantità che non sono più correnti.
Controlla la data e l'ora dell'eccezione: se risale a più di un giorno, la raccomandazione potrebbe essere obsoleta.
Se la raccomandazione è chiaramente sbagliata (ad esempio, ignora un ordine di grandi dimensioni visibile nel grafico), fornisci un feedback utilizzando il pollice rivolto verso il basso e segnala l'eccezione specifica al tuo team di assistenza.
La data di impatto o la data di scadenza sembrano errate
La data di impatto indica quando inizia l'emissione dell'inventario (ad esempio, quando inizia l'esaurimento delle scorte o quando l'eccesso supera la soglia).
La data di scadenza deve tenere conto dei tempi di consegna, in modo da avere il tempo di agire prima che il problema si concretizzi. Se Act By è uguale alla data di impatto, il lead time potrebbe non essere incluso: segnalalo al tuo team di supporto.
Consigli e ordini di riferimento che non riesco a trovare nell'ERP
Le istantanee ERP cambiano ogni giorno. Un ordine a cui si fa riferimento nella raccomandazione di ieri potrebbe essere stato evaso, annullato o riprogrammato nella gestione ERP odierna.
Si tratta di una limitazione nota dei dati. ERP-based È possibile aggiungere dati storici sul consumo per fornire un contesto migliore.
Problemi di precisione comuni
La previsione è significativamente peggiore di una media mobile semplice
Se la tua previsione ASC sta scendendo fino a raggiungere una media mobile a 6 mesi sul WAPE aggregato, verifica queste cause comuni:
Troppi prodotti di bassa gamma. volume/inactive I prodotti con una domanda scarsa e intermittente sono difficili da battere per qualsiasi modello rispetto alla media semplice. Utilizza una regola di preelaborazione per limitare la previsione a prodotti con una cronologia della domanda significativa (ad esempio, almeno 6 mesi di domanda diversa da zero).
Formazione sulla storia vecchia o contaminata. Se la cronologia degli ordini risale a molti anni fa, i vecchi modelli di domanda potrebbero non riflettere la realtà attuale. Prendi in considerazione una regola di preelaborazione per limitare la cronologia degli allenamenti ai 3-5 anni più recenti o per sostituire i periodi anomali (ad esempio, COVID) con valori normalizzati.
La domanda aumenta a causa di ordini una tantum. Un singolo ordine all'ingrosso di grandi dimensioni può creare una falsa tendenza al rialzo nei dati di allenamento. Utilizza una regola di preelaborazione per limitare i valori anomali della domanda mensile a un multiplo della media finale (ad esempio, 5x).
Regole di consenso applicate nella direzione sbagliata. L'agente LLM può interpretare erroneamente il linguaggio delle regole. «Riduzione del 27%" può essere applicato come aumento. Convalida sempre i risultati del consenso rispetto ai valori di riferimento confrontando prodotti e mesi specifici. Usa un linguaggio di moltiplicazione esplicito («moltiplica per 0,725") anziché un linguaggio direzionale («diminuzione del 27,5% «).
Over-forecasting distorsione (previsione sistematicamente superiore a quella effettiva)
Una propensione positiva significa che stai ordinando più del necessario in tutto il catalogo. Cause comuni:
Il modello viene addestrato in un periodo di crescita. Se gli ultimi anni hanno mostrato una crescita che non continua, il modello estrapola una tendenza che non esiste più.
Le regole di consenso stanno accumulando aggiustamenti verso l'alto. Diverse regole che aumentano ciascuna la previsione (tendenza all'esaurimento delle scorte, aumento del trend, aumento stagionale) possono aggravarsi. Verifica quali regole sono attive e verifica se si applicano tutte agli stessi prodotti.
Deleted/discontinued prodotti ancora in oggetto. I prodotti la cui domanda è ancora in fase di previsione mostreranno una sovraprevisione sistematica.
Under-forecasting distorsione (previsione sistematicamente inferiore a quella effettiva)
Una distorsione negativa significa che si prevede costantemente una domanda inferiore a quella effettiva, con conseguente potenziale esaurimento delle scorte e accelerazione dei costi. Cause comuni:
I segnali previsionali esterni non vengono incorporati. Se sono caricati gli input del piano (ad esempio, previsioni EDI dei clienti, piani di produzione SIOP) ma le regole di consenso non li applicano, la previsione utilizza per impostazione predefinita la baseline statistica, che potrebbe non catturare i segnali di domanda visti dai pianificatori. Verifica che le regole di consenso stiano effettivamente modificando l'output confrontando l'esportazione con l'esportazione delle previsioni (baseline). ConsensusForecast Se sono identiche, le regole non funzionano.
Combinazioni sparse prodotto×sito che riducono l'aggregato. Se si effettua una previsione in base alla granularità prodotto×sito ma molte combinazioni hanno una domanda pari a zero o prossima allo zero, il modello produce piccole previsioni diverse da zero per le combinazioni inattive. Queste cifre non si sommano molto singolarmente, ma collettivamente trascinano la previsione totale al di sotto dei valori effettivi. Utilizza una regola di preelaborazione per escludere le combinazioni con una cronologia della domanda insufficiente o utilizza la compilazione condizionale a zero negli input del piano per segnalare esplicitamente «nessuna domanda prevista» per le combinazioni inattive.
Il modello non ha catturato un recente trend di crescita. I modelli statistici ponderano i dati storici. Se la tua attività è cresciuta in modo significativo negli ultimi mesi ma il modello ha anni di riduzione dei volumi, sarà in ritardo rispetto alla tendenza. Questo in genere migliora nel tempo man mano che il modello accumula dati più recenti. Nel frattempo, considera una regola di consenso che utilizzi una media finale dei valori effettivi recenti come base per le settimane di previsione esterne.
Year-over-year discrepanza nella stagionalità. Se il modello della domanda di quest'anno è diverso dagli anni precedenti (ad esempio, aumento stagionale anticipato, lancio di nuovi prodotti), il modello potrebbe essere sottostimato durante il periodo divergente. Verifica se l'underbias è concentrato in settimane o mesi specifici che differiscono dal modello dell'anno precedente.
L'accuratezza delle previsioni diminuisce notevolmente su orizzonti più lunghi
È normale che la precisione peggiori all'aumentare dell'orizzonte di previsione: la settimana 1 è sempre più accurata della settimana 8. Tuttavia, se il degrado è più marcato del previsto:
I segnali esterni aiutano solo a breve termine. Se hai regole di consenso che incorporano le previsioni dei clienti (EDI) per le prime settimane, la precisione sarà notevolmente migliore a breve termine e diminuirà quando le regole smetteranno di applicarsi. Ciò è prevedibile: prendete in considerazione la possibilità di estendere le regole ad altre settimane con un approccio 50/50 misto (ad esempio, combinando segnali esterni e valori di riferimento per settimane a medio termine).
La linea di base ritorna a una media a lungo termine su orizzonti più lunghi. I modelli statistici diventano meno sicuri su orizzonti più lunghi e tendono verso la media storica. Se la domanda recente è superiore alla media storica, le ultime settimane appariranno poco distorte. Si tratta di un comportamento del modello, non di un problema di configurazione.
La volatilità della domanda rende intrinsecamente più difficili gli orizzonti più lunghi. Se la tua domanda presenta un'elevata variabilità da settimana a settimana (coefficiente di variazione > 0,5), anche un modello perfetto mostrerà un errore elevato su orizzonti più lunghi. Concentrate la valutazione dell'accuratezza sulle prime 3-4 settimane, che è la finestra di pianificazione attuabile per la maggior parte delle operazioni.
La previsione esterna (EDI/customer previsione) non migliora la precisione se utilizzata nelle regole di consenso
Se hai aggiunto regole di consenso per incorporare previsioni esterne ma la precisione non è migliorata:
Il segnale esterno potrebbe non coprire un numero sufficiente di prodotti. L'EDI o le previsioni dei clienti in genere coprono solo un sottoinsieme del catalogo dei prodotti (spesso il 30-50%). I prodotti senza segnale esterno utilizzano ancora la linea di base. Controlla il tasso di copertura: se è inferiore al 50%, l'impatto sulla precisione aggregata sarà limitato.
Il segnale esterno potrebbe non essere sufficientemente preciso da aiutarti. Misura l'accuratezza della previsione esterna in modo indipendente prima di utilizzarla nelle regole. Se il suo WAPE è peggiore rispetto alla linea di base, incorporarlo danneggerà anziché aiutare. Valuta la possibilità di limitare la regola a siti o prodotti specifici in cui il segnale esterno è chiaramente migliore (ad esempio, WAPE ponderato in termini di volume inferiore al 50%).
Il segnale esterno non riporta zeri. Molti sistemi EDI inviano record solo per i prodotti con ordini attivi: omettono i prodotti con domanda zero anziché riportare esplicitamente zero. Se la tua regola di consenso dice «quando EDI = 0, imposta la previsione su 0", non verrà mai attivata perché non ci sono zero record. È necessario generare zero record sintetici in fase di preelaborazione per le combinazioni prodotto×sito che non hanno alcun segnale esterno E nessuna cronologia delle vendite recenti.
La precisione del segnale esterno varia in base all'orizzonte. Le previsioni dei clienti sono in genere più accurate per l'immediata settimana successiva (essenzialmente ordini confermati) e si deteriorano rapidamente. Una regola che utilizza il segnale esterno direttamente per tutte le settimane può compromettere la precisione su orizzonti più lunghi. Prendi in considerazione un approccio a più livelli: sostituzione diretta per le settimane 1-3, misto per le settimane 4-6, valore di base solo per le settimane 7+.
Le regole di pianificazione non entrano in vigore
Se una regola di consenso non sembra modificare la previsione:
La regola potrebbe essere stata sostituita da una regola con priorità più alta. Le regole vengono applicate in ordine di priorità. Una regola successiva può annullare una regola precedente. Controlla l'ordine delle regole.
La condizione della regola potrebbe non corrispondere a nessun prodotto. Se la regola fa riferimento a un attributo del prodotto (ad esempio, product_group_id) che non è presente nei metadati dell'articolo, non corrisponderà silenziosamente a nulla.
Il linguaggio delle regole è stato interpretato erroneamente. L'agente LLM genera codice dal linguaggio naturale. Una formulazione ambigua può produrre risultati inaspettati. Sii il più specifico e letterale possibile. Usa nomi di campo esatti, moltiplicatori espliciti e condizioni chiare.
L'output del piano di consenso è identico alla previsione di base
Se l' ConsensusForecast esportazione ha gli stessi valori dell'esportazione Forecast (baseline), le regole di consenso non sono state eseguite. Cause comuni:
Mancata corrispondenza delle dimensioni nel join. Il motore di consenso unisce gli input del piano alla baseline su colonne di dimensioni (ID prodotto, ID sito, data). Se i nomi delle colonne sono diversi tra gli input della baseline e quelli del piano (ad esempio, baseline utilizza item_id mentre EDI utilizza product_id), l'unione non produce corrispondenze e tutte le regole rientrano nell'impostazione predefinita della baseline. Verifica che la mappatura delle dimensioni nella configurazione del flusso di dati sia mappata correttamente tra i due schemi.
Mancata corrispondenza del formato della data. La baseline può memorizzare le date come 2026-03-02 mentre gli input del piano le memorizzano come 2026-03-02. T00:00:00.000Z Se l'iscrizione richiede una corrispondenza esatta, le date che tengono conto del fuso orario e che non utilizzano il fuso orario non corrisponderanno. Verifica che le colonne relative alle date siano convertite nello stesso formato prima di iscriverti.
Gli input del piano non sono stati caricati. Verifica che i file di input del tuo piano (EDI, SIOP, ecc.) siano stati inseriti correttamente. Controllate il numero di record nel sistema: se mostrano zero righe per l'input del piano, è possibile che il file non sia stato caricato.
Il consensus forecast_id corrisponde al forecast_id di base. Se entrambe le esportazioni condividono lo stesso forecast_id, il motore di consenso ha prodotto una copia diretta della baseline senza elaborazione. Ciò indica un problema a livello di sistema: contatta il tuo team di supporto con forecast_id e demand_plan_run_id.
Le regole di consenso si applicano a prodotti o siti errati
Se una regola che dovrebbe applicarsi solo a siti o categorie di prodotti specifici riguarda l'intero catalogo:
La condizione del site/product filtro può fare riferimento alla colonna sbagliata. Se la tua regola dice «applica ai siti in [elenco]» ma il codice generato controlla una colonna che non esiste o ha valori diversi, il filtro può passare silenziosamente tutte le righe. Verifica controllando a campione alcuni prodotti specifici che NON dovrebbero essere interessati dalla regola.
L'ordine di priorità delle regole può essere invertito. Le regole vengono applicate come una catena in cui le regole successive sostituiscono quelle precedenti. Se una regola generale (ad esempio, «usa la linea di base per tutto») viene applicata dopo una regola specifica (ad esempio, «usa l'EDI per questi 50 siti»), la regola generale annullerà quella specifica. Assicurati che le descrizioni delle regole indichino chiaramente l'ordine di priorità.
I valori di previsione sono frazionari (ad esempio 2.500,37 unità)
I modelli statistici producono valori continui, non numeri interi. Se la tua azienda tratta unità intere, confezioni o quantità minime d'ordine:
Aggiungi una regola di arrotondamento come fase finale del consenso. Una semplice regola di «arrotondamento al numero intero più vicino» applicata dopo tutte le altre regole di consenso ripulirà i valori frazionari. I valori inferiori a 0,5 verranno arrotondati a zero, il che è appropriato per combinazioni a domanda molto bassa.
Valuta la possibilità di arrotondare alle quantità operative. Se i tuoi prodotti vengono spediti in confezioni standard (ad esempio, scatole da 12, pallet da 48), l'arrotondamento alla dimensione valida più vicina può migliorare sia l'usabilità che l'accuratezza della previsione. A tal fine sono necessari i dati relativi alle dimensioni delle confezioni presenti nella scheda tecnica del prodotto. Condividi il tuo MOQ o i dati sulle dimensioni delle confezioni con il tuo team di supporto per esplorare questa opzione.
La copertura del prodotto diminuisce notevolmente dopo l'aggiunta delle regole di preelaborazione
Le regole di preelaborazione che filtrano i dati di formazione (ad esempio, «solo prodotti previsti con almeno 8 settimane di domanda diversa da zero») possono ridurre drasticamente il numero di prodotti nella previsione se i dati sono scarsi a livello di prodotto×sito:
Verifica la granularità. Un prodotto può avere 52 settimane di domanda a livello di prodotto, ma solo 3 settimane per ogni singola combinazione prodotto×sito. Una soglia minima di cronologia applicata a livello di prodotto×sito escluderà la maggior parte delle combinazioni. Valuta invece di applicare la soglia a livello di prodotto o di abbassarla in modo significativo.
Effettua il test prima della distribuzione. Prima di attivare una regola di preelaborazione, conta quante combinazioni prodotto×sito superano il filtro rispetto al totale attuale. Se viene escluso più del 20%, è probabile che la regola sia troppo aggressiva. Iniziate con una soglia moderata e inasprite gradualmente.
