Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Häufige Probleme und Lösungen
Allgemeine Datenprobleme
Die Nachfragehistorie hat gemischte Datumsformate
Quellsysteme können Daten als DD/MM/YYYY, MM/DD/YYYY, oder YYYY-MM-DD, manchmal innerhalb derselben Datei exportieren. Das System analysiert diese Daten möglicherweise falsch und ordnet Bestellungen falschen Monaten zu.
Behebung: Standardisieren Sie Datumsformate in Ihrem Exportprozess. Wenn Sie die Quelle nicht kontrollieren können, fügen Sie Ihrer Datenfluss-SQL eine Datumsvalidierung hinzu.
Negative Mengen in der Bestellhistorie
Gutschriften, Rücksendungen oder Stornierungen können als negative Mengen angezeigt werden. Diese können die Durchschnittswerte der Nachfrage verzerren und das Modell verwirren.
Lösung: Filtern Sie nur nach positiven Mengen oder filtern Sie nach Auftragsstatus (z. B. nur Paid/Invoiced Bestellungen).
Die Anzahl der Datensätze stimmt nicht mit Ihrem Quellsystem überein
Wird am häufigsten durch Kollisionen zusammengesetzter Schlüssel verursacht. Wenn zwei Datensätze dieselbe eindeutige Kennung haben, überschreibt einer den anderen.
Kann auch auftreten, wenn die Filterkriterien in der Datenzuordnung Datensätze ausschließen, die Sie erwarten.
Geben Sie ein konkretes Beispiel für ein Produkt und eine Website sowie Ihre erwartete Anzahl an Datensätzen an, damit das Team die Diskrepanz nachvollziehen kann.
Bestellungen werden im System angezeigt, die nicht in ERP existieren (oder umgekehrt)
Bestellungen, die zwischen Berichtsläufen ausgeführt oder entfernt wurden, verschwinden bei der nächsten Aktualisierung, können aber weiterhin in Ausnahmen erscheinen, die anhand der Daten des Vortages generiert wurden.
Neu erstellte Bestellungen werden erst bei der nächsten Datenaktualisierung angezeigt.
Dies ist erwartetes Verhalten — Ausnahmen werden im nächsten Bewertungszyklus aktualisiert, nachdem neue Daten geladen wurden.
Die Eingabedateien für Pläne enthalten Produkte aus anderen Werken oder Geschäftsbereichen
Wenn Ihre Exporte aus dem Quellsystem Produkte enthalten, die nicht in den Rahmen Ihres Prognoseprojekts fallen, gehen Sie wie folgt vor:
Das System filtert automatisch nach dem Produktmaster. Nur Produkte, die in Ihrer Produktmasterdatei enthalten sind, werden in die Prognose aufgenommen. Wenn jedoch ein großer Prozentsatz Ihrer Eingabedatei außerhalb des Gültigkeitsbereichs liegt (z. B. mehr als 50% der Zeilen), deutet dies darauf hin, dass der Quellexport eingeschränkt werden muss.
Überprüfen Sie regelmäßig Ihren Produktdeckungsgrad. Überprüfen Sie nach jedem Laden der Daten, wie viel Prozent der Produkte in Ihren Eingabedateien für Verkäufe und Prognosen dem Produktmaster entsprechen. Wenn die Abdeckung unter 80% fällt, untersuchen Sie, ob sich der Umfang des Quellexports geändert hat oder ob der Produktmaster aktualisiert werden muss.
Out-of-scope Produkte, die in den Planeingaben enthalten sind, können zu überhöhten Gesamtsummen führen. Wenn Ihre EDI- oder SIOP-Dateien Produkte aus anderen Werken enthalten, ist das aggregierte Prognosesignal höher als es sein sollte. Stellen Sie vor dem Laden sicher, dass die Eingabedateien für den Plan nach demselben Produktumfang wie Ihr Produktmaster gefiltert wurden.
Häufige Probleme mit Ausnahmen und Empfehlungen
Das gleiche Produkt und dieselbe Website erscheinen mehrfach in der Ausnahmeliste
Dies kann passieren, wenn die zugrunde liegende Regel für jedes Qualifikationsdatum im Projektionshorizont eine separate Ausnahme generiert.
Wenden Sie sich an Ihr Support-Team, um die Regel so anzupassen, dass nur das früheste Datum des Verstoßes pro Produkt und Website gekennzeichnet wird.
Die Empfehlung stimmt nicht mit dem überein, was ich in der Tabelle sehe
Die Empfehlung wird von einem KI-Agenten generiert, der die zum Zeitpunkt der Erstellung der Ausnahme verfügbaren Daten analysiert. Wenn sich die Daten seitdem geändert haben, bezieht sich die Empfehlung möglicherweise auf Bestellungen oder Mengen, die nicht mehr aktuell sind.
Prüfen Sie den Zeitstempel der Ausnahme — wenn sie älter als einen Tag ist, ist die Empfehlung möglicherweise veraltet.
Wenn die Empfehlung eindeutig falsch ist (z. B. ignoriert sie eine große Bestellung, die in der Tabelle sichtbar ist), geben Sie Feedback, indem Sie die Daumen nach unten drücken, und melden Sie die spezifische Ausnahme Ihrem Support-Team.
Das Auswirkungsdatum oder das „Bis“ -Datum scheint falsch
Das Wirksamkeitsdatum gibt an, wann das Problem mit dem Lagerbestand beginnt (z. B. wenn der Lagerbestand einsetzt oder die Überschreitung den Schwellenwert überschreitet).
Bei der Angabe des Mindesthaltbarkeitsdatums sollte die Vorlaufzeit berücksichtigt werden, sodass Sie Zeit haben, zu handeln, bevor das Problem eintritt. Wenn „Bis“ dem Datum der Auswirkung entspricht, wird die Vorlaufzeit möglicherweise nicht berücksichtigt. Melden Sie dies Ihrem Support-Team.
Empfehlungen, Referenzaufträge, die ich im ERP nicht finden kann
ERP-Schnappschüsse ändern sich täglich. Eine Bestellung, auf die in der gestrigen Empfehlung verwiesen wurde, wurde im heutigen ERP-Lauf möglicherweise erfüllt, storniert oder verschoben.
Dies ist eine bekannte ERP-based Datenbeschränkung. Historische Verbrauchsdaten können hinzugefügt werden, um einen besseren Kontext zu bieten.
Häufig auftretende Probleme mit der Genauigkeit
Die Forecast ist deutlich schlechter als ein einfacher gleitender Durchschnitt
Wenn Ihre ASC-Prognose beim aggregierten WAPE-Wert auf einen gleitenden 6-Monats-Durchschnitt fällt, überprüfen Sie die folgenden häufigen Ursachen:
Zu viele volume/inactive Produkte mit geringem Umfang im Anwendungsbereich. Produkte mit geringer, schwankender Nachfrage sind für jedes Modell kaum zu übertreffen. Verwenden Sie eine Vorverarbeitungsregel, um die Prognose auf Produkte mit aussagekräftiger Nachfragehistorie (z. B. mindestens 6 Monate mit einer Nachfrage ungleich Null) auszudehnen.
Schulung zu veralteter oder kontaminierter Historie. Wenn Ihre Bestellhistorie viele Jahre zurückreicht, spiegeln alte Nachfragemuster möglicherweise nicht die aktuelle Realität wider. Erwägen Sie eine Vorverarbeitungsregel, um den Trainingsverlauf auf die letzten 3—5 Jahre zu beschränken oder ungewöhnliche Perioden (z. B. COVID) durch normalisierte Werte zu ersetzen.
Die Nachfrage ist aufgrund einmaliger Bestellungen stark angestiegen. Eine einzige große Großbestellung kann zu einem falschen Aufwärtstrend bei den Trainingsdaten führen. Verwenden Sie eine Vorverarbeitungsregel, um anomale monatliche Bedarfswerte auf ein Vielfaches des letzten Durchschnitts zu begrenzen (z. B. das Fünffache).
Konsensregeln, die in die falsche Richtung angewendet wurden. Der LLM-Agent kann die Regelsprache falsch interpretieren. „Verringerung um 27%“ kann als Erhöhung angewendet werden. Vergleichen Sie immer die Ergebnisse, die im Konsens erzielt wurden, mit dem Ausgangswert, indem Sie bestimmte Produkte und Monate miteinander vergleichen. Verwenden Sie eine explizite Multiplikationssprache („mit 0,725 multiplizieren“) statt einer Richtungssprache („Verringerung um 27,5%“).
Over-forecasting Verzerrung (die Prognose ist systematisch höher als die tatsächlichen Werte)
Eine positive Tendenz bedeutet, dass Sie im gesamten Katalog mehr bestellen, als Sie benötigen. Häufige Ursachen:
Das Modell wurde für eine Wachstumsphase trainiert. Wenn in den letzten Jahren ein Wachstum zu verzeichnen war, das sich nicht fortsetzt, extrapoliert das Modell einen Trend, der nicht mehr existiert.
Die Konsensregeln sehen immer mehr Anpassungen nach oben vor. Mehrere Regeln, die jeweils die Prognose erhöhen (Fehlbestände, Trendschub, saisonaler Anstieg), können sich verschärfen. Überprüfe, welche Regeln aktiv sind, und prüfe, ob sie alle für dieselben Produkte gelten.
Deleted/discontinued Produkte, die noch in den Geltungsbereich fallen. Bei Produkten mit nachlassender Nachfrage, für die immer noch Prognosen vorliegen, wird es zu einer systematischen Überschätzung kommen.
Under-forecasting Verzerrung (Prognose, die systematisch unter den tatsächlichen Werten liegt)
Eine negative Tendenz bedeutet, dass Sie durchweg weniger prognostizieren als die tatsächliche Nachfrage, was zu potenziellen Fehlbeständen und zu beschleunigten Kosten führen kann. Häufige Ursachen:
Externe Prognosesignale werden nicht berücksichtigt. Wenn Sie Planeingaben (z. B. EDI-Kundenprognosen, SIOP-Produktionspläne) geladen haben, diese aber in Ihren Konsensregeln nicht angewendet werden, wird für die Prognose standardmäßig der statistische Basiswert verwendet, der möglicherweise keine Nachfragesignale erfasst, die Ihren Planern angezeigt werden. Stellen Sie sicher, dass Konsensregeln die Ausgabe tatsächlich verändern, indem Sie den ConsensusForecast Export mit dem Forecast (Baseline) -Export vergleichen. Wenn sie identisch sind, werden die Regeln nicht ausgelöst.
Sparsame Produkt×Site-Kombinationen ziehen das Aggregat nach unten. Wenn Sie Prognosen mit einer Granularität zwischen Produkt und Standort erstellen, bei vielen Kombinationen jedoch kein oder nahezu kein Bedarf besteht, erstellt das Modell kleine Prognosen für inaktive Kombinationen, die nicht bei Null liegen. Diese summieren sich einzeln nicht zu viel, sondern ziehen zusammen die Gesamtprognose unter die tatsächlichen Werte. Verwenden Sie eine Vorverarbeitungsregel, um Kombinationen mit unzureichender Bedarfshistorie auszuschließen, oder verwenden Sie bedingte Nullfüllungen in Ihren Planeingaben, um ausdrücklich zu signalisieren, dass für inaktive Kombinationen kein Bedarf erwartet wird.
Das Modell hat einen aktuellen Wachstumstrend nicht erfasst. Statistische Modelle gewichten historische Daten. Wenn Ihr Unternehmen in den letzten Monaten stark gewachsen ist, das Modell jedoch seit Jahren weniger Volumen aufweist, hinkt es dem Trend hinterher. Dies verbessert sich in der Regel im Laufe der Zeit, da das Modell neuere Daten sammelt. In der Zwischenzeit sollten Sie eine Konsensregel in Betracht ziehen, die einen letzten Durchschnitt der aktuellen Istwerte als Untergrenze für die äußeren Prognosewochen verwendet.
Year-over-year Diskrepanz zwischen den Saisonalitäten. Wenn sich das diesjährige Nachfragemuster von dem der Vorjahre unterscheidet (z. B. früherer saisonaler Anstieg, Einführung neuer Produkte), kann es sein, dass das Modell in dem abweichenden Zeitraum zu wenig prognostiziert. Prüfen Sie, ob sich die zu geringe Tendenz auf bestimmte Wochen oder Monate konzentriert, die sich vom Muster des Vorjahres unterscheiden.
Forecast Prognosegenauigkeit verschlechtert sich auf längere Sicht erheblich
Es ist normal, dass sich die Genauigkeit mit zunehmendem Prognosezeitraum verschlechtert — Woche 1 ist immer genauer als Woche 8. Wenn die Degradation jedoch stärker als erwartet ausfällt:
Externe Signale helfen nur kurzfristig. Wenn Sie Konsensregeln haben, die Kundenprognosen (EDI) für die ersten Wochen beinhalten, wird die Genauigkeit kurzfristig deutlich besser sein und abnehmen, wenn die Regeln nicht mehr gelten. Das ist zu erwarten — erwägen Sie, die Regeln mit einem gemischten Ansatz auf weitere Wochen auszudehnen (z. B. 50/50 Mischung aus externen Signalen und Basiswerten für mittelfristige Wochen).
Bei längeren Zeithorizonten wird der Ausgangswert wieder auf einen langfristigen Durchschnitt zurückgesetzt. Statistische Modelle verlieren auf längere Sicht an Selbstvertrauen und tendieren zum historischen Mittelwert. Wenn die Nachfrage in letzter Zeit über dem historischen Mittelwert liegt, werden die äußeren Wochen als unvoreingenommen erscheinen. Dies ist ein Modellverhalten, kein Konfigurationsproblem.
Die Volatilität der Nachfrage macht längere Zeithorizonte naturgemäß schwieriger. Wenn Ihre Nachfrage von Woche zu Woche stark schwankt (Variationskoeffizient > 0,5), weist selbst ein perfektes Modell auf längere Sicht hohe Fehler auf. Konzentrieren Sie sich bei der Genauigkeitsbeurteilung auf die ersten 3—4 Wochen, die für die meisten Operationen das entscheidende Planungsfenster sind.
Externe Prognosen (EDI/customer Prognosen) verbessern die Genauigkeit nicht, wenn sie in Konsensregeln verwendet werden
Wenn Sie Konsensregeln hinzugefügt haben, um externe Prognosen einzubeziehen, sich die Genauigkeit jedoch nicht verbessert hat:
Das externe Signal deckt möglicherweise nicht genügend Produkte ab. EDI- oder Kundenprognosen decken in der Regel nur einen Teil Ihres Produktkatalogs ab (häufig 30-50%). Produkte ohne externes Signal verwenden immer noch den Basiswert. Überprüfen Sie Ihren Abdeckungsgrad — wenn er unter 50% liegt, ist die Auswirkung auf die Gesamtgenauigkeit begrenzt.
Das externe Signal ist möglicherweise nicht genau genug, um Abhilfe zu schaffen. Messen Sie die Genauigkeit der externen Prognose unabhängig voneinander, bevor Sie sie in Regeln verwenden. Wenn der WAPE schlechter ist als der Ausgangswert, schadet es eher, ihn einzubeziehen, als dass er hilft. Erwägen Sie, die Regel auf bestimmte Standorte oder Produkte zu beschränken, bei denen das externe Signal nachweislich besser ist (z. B. volumengewichteter WAPE unter 50%).
Das externe Signal meldet keine Nullen. Viele EDI-Systeme senden nur Datensätze für Produkte mit aktiven Bestellungen. Sie lassen Produkte ohne Nachfrage weg, anstatt explizit Null zu melden. Wenn Ihre Konsensregel besagt: „Wenn EDI = 0 ist, setzen Sie die Prognose auf 0“, wird sie nie ausgelöst, da es keine Nulldatensätze gibt. Für Kombinationen aus Produkt und Standort, die kein externes Signal UND keine aktuelle Verkaufshistorie haben, müssen Sie in der Vorverarbeitung synthetische Nulldatensätze generieren.
Die Genauigkeit des externen Signals variiert je nach Horizont. Kundenprognosen sind in der Regel für die unmittelbar nächste Woche am genauesten (im Wesentlichen bestätigte Bestellungen) und verschlechtern sich schnell. Eine Regel, die das externe Signal direkt für alle Wochen verwendet, kann die Genauigkeit auf längere Sicht beeinträchtigen. Ziehen Sie einen mehrstufigen Ansatz in Betracht: direkter Ersatz für die Wochen 1—3, gemischt für die Wochen 4—6, nur der Ausgangswert für die Wochen 7+.
Planungsregeln treten nicht in Kraft
Wenn eine Konsensregel die Prognose nicht zu ändern scheint:
Die Regel wurde möglicherweise durch eine Regel mit höherer Priorität außer Kraft gesetzt. Regeln werden in der Reihenfolge ihrer Priorität angewendet. Eine spätere Regel kann eine frühere rückgängig machen. Überprüfen Sie die Reihenfolge der Regeln.
Die Regelbedingung stimmt möglicherweise mit keinem Produkt überein. Wenn die Regel auf ein Produktattribut (z. B. product_group_id) verweist, das nicht in den Artikelmetadaten enthalten ist, entspricht sie stillschweigend nichts.
Die Regelsprache wurde falsch interpretiert. Der LLM-Agent generiert Code aus natürlicher Sprache. Mehrdeutige Formulierungen können zu unerwarteten Ergebnissen führen. Seien Sie so spezifisch und wörtlich wie möglich. Verwenden Sie exakte Feldnamen, explizite Multiplikatoren und klare Bedingungen.
Die Ergebnisse des Konsensplans sind identisch mit der Basisprognose
Wenn der ConsensusForecast Export dieselben Werte wie der Forecast (Baseline) -Export hat, wurden die Konsensregeln nicht ausgeführt. Häufige Ursachen:
Die Dimensionen stimmen in der Verknüpfung nicht überein. Die Consensus Engine verknüpft die Planeingaben anhand der Dimensionsspalten (Produkt-ID, Standort-ID, Datum) mit dem Basisplan. Wenn sich die Spaltennamen zwischen der Basislinie und den Planeingaben unterscheiden (z. B. verwendet Baseline item_id, EDI verwendet product_id), führt die Verknüpfung zu keinen Übereinstimmungen und alle Regeln werden mit dem Basisplanstandard übernommen. Stellen Sie sicher, dass die Dimensionszuordnung in Ihrer Datenflusskonfiguration den beiden Schemas korrekt zugeordnet ist.
Das Datumsformat stimmt nicht überein. In der Basislinie werden Daten möglicherweise als 2026-03-02 gespeichert, während in Planeingaben sie als 2026-03-02 gespeichert werden. T00:00:00.000Z Wenn für die Verknüpfung eine exakte Übereinstimmung erforderlich ist, stimmen zeitzonenabhängige und zeitzonennaive Daten nicht überein. Vergewissern Sie sich, dass die Datumsspalten in dasselbe Format konvertiert wurden, bevor Sie eine Verbindung herstellen.
Die Planeingaben wurden nicht geladen. Stellen Sie sicher, dass Ihre Planeingabedateien (EDI, SIOP usw.) erfolgreich aufgenommen wurden. Überprüfen Sie die Anzahl der Datensätze im System. Wenn dort keine Zeilen für eine Planeingabe angezeigt werden, konnte die Datei möglicherweise nicht geladen werden.
Die Consensus forecast_id entspricht der Baseline forecast_id. Wenn beide Exporte dieselbe forecast_id verwenden, hat die Consensus Engine ohne Verarbeitung eine direkte Kopie der Baseline erstellt. Dies deutet auf ein Problem auf Systemebene hin. Wenden Sie sich mit den Angaben forecast_id und demand_plan_run_id an Ihr Support-Team.
Konsensregeln gelten für falsche Produkte oder Websites
Wenn eine Regel, die nur für bestimmte Websites oder Produktkategorien gelten sollte, den gesamten Katalog betrifft:
Die site/product Filterbedingung verweist möglicherweise auf die falsche Spalte. Wenn Ihre Regel „Auf Websites in [Liste] anwenden“ lautet, der generierte Code jedoch eine Spalte überprüft, die nicht existiert oder andere Werte hat, kann es sein, dass der Filter automatisch alle Zeilen durchlässt. Überprüfe das, indem du stichprobenartig einige bestimmte Produkte überprüfst, die NICHT von der Regel betroffen sein sollten.
Die Reihenfolge der Regelpriorität kann umgekehrt werden. Regeln werden als Kette angewendet, wobei spätere Regeln frühere Regeln überschreiben. Wenn eine allgemeine Regel (z. B. „für alles den Basiswert verwenden“) nach einer bestimmten Regel angewendet wird (z. B. „EDI für diese 50 Websites verwenden“), macht die allgemeine Regel die spezifische Regel rückgängig. Stellen Sie sicher, dass Ihre Regelbeschreibungen die Prioritätsreihenfolge eindeutig angeben.
Prognosewerte sind Bruchzahlen (z. B. 2.500,37 Einheiten)
Statistische Modelle erzeugen kontinuierliche Werte, keine ganzen Zahlen. Wenn Ihr Unternehmen ganze Einheiten, Kartonpackungen oder Mindestbestellmengen verkauft:
Fügen Sie als letzten Konsensschritt eine Rundungsregel hinzu. Eine einfache Regel „Auf die nächste Ganzzahl runden“, die nach allen anderen Konsensregeln angewendet wird, bereinigt Bruchzahlen. Werte unter 0,5 werden auf Null gerundet, was für Kombinationen mit sehr geringer Nachfrage angemessen ist.
Erwägen Sie, auf betriebsbereite Mengen zu runden. Wenn Ihre Produkte in Standardverpackungsgrößen geliefert werden (z. B. Kartons mit 12 Stück, Paletten mit 48 Stück), kann eine Rundung auf die nächstgelegene gültige Packungsgröße sowohl die Benutzerfreundlichkeit als auch die Genauigkeit der Prognose verbessern. Dazu sind Daten zur Packungsgröße in Ihrem Produktmaster erforderlich. Teilen Sie Ihrem Support-Team Ihre MOQ- oder Packungsgrößendaten mit, um diese Option zu prüfen.
Die Produktabdeckung nimmt nach dem Hinzufügen von Vorverarbeitungsregeln erheblich ab
Durch Regeln zur Vorverarbeitung, bei denen die Trainingsdaten gefiltert werden (z. B. „nur Produkte prognostizieren, für die mindestens 8 Wochen kein Bedarf besteht“), kann die Anzahl der Produkte in der Prognose drastisch reduziert werden, wenn Ihre Daten auf der Ebene „Produkt × Standort“ nur spärlich sind:
Überprüfen Sie die Granularität. Ein Produkt kann auf Produktebene 52 Wochen nachgefragt werden, bei jeder Kombination aus Produkt und Standort jedoch nur 3 Wochen. Ein Mindestschwellenwert für die Historie, der auf der Ebene „Produkt × Standort“ gilt, schließt die meisten Kombinationen aus. Erwägen Sie, den Schwellenwert stattdessen auf Produktebene anzuwenden oder den Schwellenwert deutlich zu senken.
Testen Sie vor der Bereitstellung. Bevor Sie eine Vorverarbeitungsregel aktivieren, zählen Sie, wie viele Produkt×Site-Kombinationen den Filter bestehen, im Vergleich zu Ihrer aktuellen Gesamtzahl. Wenn mehr als 20% ausgeschlossen werden, ist die Regel wahrscheinlich zu aggressiv. Beginnen Sie mit einem milden Schwellenwert und ziehen Sie ihn schrittweise an.
