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
Häufige Datenprobleme
Die Nachfragehistorie hat gemischte Datumsformate
Quellsysteme exportieren Daten möglicherweise als DD/MM/YYYY MM/DD/YYYY, oder YYYY-MM-DD, manchmal innerhalb derselben Datei. Das System analysiert diese möglicherweise falsch und ordnet Bestellungen falschen Monaten zu.
Fix: Standardisieren Sie die Datumsformate in Ihrem Exportprozess. Wenn Sie die Quelle nicht kontrollieren können, fügen Sie Ihrer Datenfluss-SQL eine Datumsüberprüfung hinzu.
Negative Mengen in der Bestellhistorie
Gutschriften, Rücksendungen oder Stornierungen können als negative Mengen erscheinen. Diese können die Durchschnittswerte der Nachfrage verfälschen und das Modell verwirren.
Fix: Filtern Sie nur nach positiven Mengen oder filtern Sie nach Bestellstatus (z. B. nur Paid/Invoiced Bestellungen).
Die Anzahl der Datensätze entspricht nicht Ihrem Quellsystem
Am häufigsten verursacht durch Kollisionen zusammengesetzter Schlüssel — wenn zwei Datensätze dieselbe eindeutige ID haben, überschreibt einer den anderen.
Kann auch auftreten, wenn die Filterkriterien in der Datenzuordnung Datensätze ausschließen, die Sie erwarten.
Geben Sie ein Beispiel für ein bestimmtes Produkt und eine bestimmte Website sowie die erwartete Anzahl an Datensätzen an, damit das Team die Diskrepanz nachvollziehen kann.
Bestellungen erscheinen im System, die in ERP nicht existieren (oder umgekehrt)
Bestellungen, die zwischen den Berichtsläufen ausgeführt oder entfernt wurden, verschwinden bei der nächsten Aktualisierung, können aber dennoch als Ausnahmen erscheinen, die anhand der Daten des Vortages generiert wurden.
Neu erstellte Bestellungen werden erst bei der nächsten Datenaktualisierung angezeigt.
Dies ist ein erwartetes Verhalten — Ausnahmen werden im nächsten Testzyklus nach dem Laden neuer Daten aktualisiert.
Die Eingabedateien für den Plan enthalten Produkte aus anderen Werken oder Geschäftsbereichen
Wenn Ihre Quellsystemexporte Produkte enthalten, die nicht in den Umfang Ihres Prognoseprojekts fallen:
Das System filtert automatisch nach dem Produktmaster. Nur Produkte, die in Ihrer Produktstammdatei 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 verschärft werden muss.
Überprüfen Sie regelmäßig Ihren Produktabdeckungsgrad. Überprüfen Sie nach jedem Laden der Daten, wie viel Prozent der Produkte in Ihren Umsatz- und Prognoseeingabedateien mit dem Produktmaster übereinstimmen. Wenn die Abdeckung unter 80% fällt, prüfen Sie, ob sich der Umfang des Quell-Exports geändert hat oder ob der Produktmaster aktualisiert werden muss.
Out-of-scope Produkte in den Planeingaben können zu überhöhten Gesamtwerten 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 Planeingabedateien auf denselben Produktumfang wie Ihr Produktmaster gefiltert wurden.
Häufige Probleme mit Ausnahmen und Empfehlungen
Dasselbe Produkt+dieselbe Website erscheinen mehrfach in der Ausnahmeliste
Dies kann passieren, wenn die zugrunde liegende Regel für jedes qualifizierende Datum im Projektionshorizont eine separate Ausnahme generiert.
Wenden Sie sich an Ihr Support-Team, um die Regel so anzupassen, dass nur das früheste Verstoßdatum pro Produkt+Website angezeigt wird.
Die Empfehlung entspricht nicht dem, was ich in der Tabelle sehe
Die Empfehlung wird von einem KI-Agenten generiert, der die Daten analysiert, die zum Zeitpunkt der Erstellung der Ausnahme verfügbar waren. Wenn sich die Daten seitdem geändert haben, kann sich die Empfehlung auf Bestellungen oder Mengen beziehen, die nicht mehr aktuell sind.
Überprüfe den Zeitstempel auf 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 im Diagramm sichtbar ist), geben Sie Feedback, indem Sie die Daumen nach unten drücken, und melden Sie die spezifische Ausnahme Ihrem Support-Team.
Das Datum der Auswirkung oder das Verfallsdatum scheinen falsch zu sein
Das Gültigkeitsdatum gibt an, wann das Problem mit dem Lagerbestand beginnt (z. B. wenn der Lagerbestand beginnt oder der Überschuss den Schwellenwert überschreitet).
Das Verfallsdatum sollte die Vorlaufzeit berücksichtigen, damit Sie Zeit haben, zu handeln, bevor das Problem auftritt. Wenn Act By dem Datum entspricht, an dem das Problem behoben wurde, wird die Vorlaufzeit möglicherweise nicht berücksichtigt. Teilen Sie dies Ihrem Support-Team mit.
Empfehlungen beziehen sich auf Bestellungen, die ich in ERP nicht finden kann
ERP-Snapshots ändern sich täglich. Eine Bestellung, auf die in der gestrigen Empfehlung Bezug genommen wurde, wurde im heutigen ERP-Lauf möglicherweise ausgeführt, 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äufige Probleme mit der Genauigkeit
Die Prognose ist deutlich schlechter als ein einfacher gleitender Durchschnitt
Wenn Ihre ASC-Prognose beim aggregierten WAPE unter einen gleitenden 6-Monats-Durchschnitt fällt, überprüfen Sie die folgenden häufigen Ursachen:
Zu viele volume/inactive Produkte mit niedrigem Marktanteil im Leistungsumfang. Bei Produkten mit geringer, intermittierender Nachfrage ist es für jedes Modell schwierig, einen einfachen Durchschnitt zu übertreffen. Verwenden Sie eine Vorverarbeitungsregel, um die Prognose auf Produkte mit einer aussagekräftigen Nachfragehistorie auszudehnen (z. B. seit mindestens 6 Monaten mit einer Nachfrage, die nicht Null ist).
Schulung zum Thema veraltete oder kontaminierte 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 die Trainingshistorie auf die letzten 3—5 Jahre zu beschränken oder ungewöhnliche Perioden (z. B. COVID) durch normalisierte Werte zu ersetzen.
Die Nachfrage steigt aufgrund einmaliger Bestellungen. Eine einzige große Großbestellung kann zu einem falschen Aufwärtstrend in den Trainingsdaten führen. Verwenden Sie eine Vorverarbeitungsregel, um anomale monatliche Bedarfswerte auf ein Vielfaches des nachfolgenden Durchschnitts zu begrenzen (z. B. das Fünffache).
Konsensregeln wurden in die falsche Richtung angewendet. Der LLM-Agent kann die Regelsprache falsch interpretieren. „Um 27% verringern“ kann als Erhöhung verwendet werden. Vergleichen Sie stets die Ergebnisse, die im Konsens erzielt wurden, mit dem Ausgangswert, indem Sie bestimmte Produkte und Monate vergleichen. Verwenden Sie eine explizite Multiplikationssprache („mit 0,725 multiplizieren“) und nicht eine direktionale Sprache („um 27,5% verringern“).
Over-forecasting Verzerrung (die Prognose ist systematisch höher als die tatsächlichen Werte)
Eine positive Verzerrung bedeutet, dass Sie im gesamten Katalog mehr bestellen als nötig. Häufige Ursachen:
Das Modell wird in einer 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.
Bei den Konsensregeln handelt es sich um stapelweise Aufwärtsanpassungen. Mehrere Regeln, die die Prognose jeweils erhöhen (Tendenz zum Fehlbestand, Trendschub, saisonaler Anstieg), können sich verschärfen. Überprüfe, welche Regeln aktiv sind, und überprüfe, ob sie alle für dieselben Produkte gelten.
Deleted/discontinued Produkte, die noch im Geltungsbereich enthalten sind. Bei Produkten mit nachlassender Nachfrage, die noch prognostiziert werden, wird es zu einer systematischen Überprognose kommen.
Under-forecasting Verzerrung (die Prognosen liegen systematisch unter den tatsächlichen Werten)
Eine negative Tendenz bedeutet, dass Sie durchweg weniger als die tatsächliche Nachfrage prognostizieren, was zu potenziellen Fehlmengen und steigenden Kosten führt. Häufige Ursachen:
Externe Prognosesignale werden nicht berücksichtigt. Wenn Sie Planeingaben (z. B. EDI-Kundenprognosen, SIOP-Produktionspläne) geladen haben, Ihre Konsensregeln sie jedoch nicht anwenden, wird für die Prognose standardmäßig der statistische Basiswert verwendet, der möglicherweise die Nachfragesignale, die Ihre Planer sehen, nicht erfasst. Stellen Sie sicher, dass die Konsensregeln die Ausgabe tatsächlich ändern, indem Sie den Export mit dem ConsensusForecast Prognoseexport (Basisexport) vergleichen. Wenn sie identisch sind, werden die Regeln nicht ausgelöst.
Sparsame Kombinationen aus Produkt und Standort ziehen das Aggregat nach unten. Wenn Sie Prognosen mit der Granularität von Produkt × Standort erstellen, aber viele Kombinationen keine oder nahezu keine Nachfrage haben, erstellt das Modell kleine Prognosen ungleich Null für inaktive Kombinationen. Diese summieren sich für sich genommen nicht zu viel, aber zusammengenommen ziehen sie die Gesamtprognose unter die tatsächlichen Werte. Verwenden Sie eine Vorverarbeitungsregel, um Kombinationen mit unzureichender Bedarfshistorie auszuschließen, oder verwenden Sie die bedingte Nullfüllung in Ihren Planeingaben, um explizit zu signalisieren, dass für inaktive Kombinationen kein Bedarf zu erwarten ist.
Das Modell hat einen aktuellen Wachstumstrend nicht erfasst. Statistische Modelle gewichten historische Daten. Wenn Ihr Unternehmen in den letzten Monaten erheblich gewachsen ist, das Modell jedoch seit Jahren mit geringerem Volumen verwendet wird, hinkt es dem Trend hinterher. Dies verbessert sich in der Regel im Laufe der Zeit, wenn das Modell neuere Daten sammelt. Ziehen Sie in der Zwischenzeit eine Konsensregel in Betracht, bei der der nachfolgende Durchschnitt der jüngsten Istwerte als Untergrenze für die Wochen verwendet wird, die außerhalb der Prognose liegen.
Year-over-year Nichtübereinstimmung der Saisonalität. Wenn sich das diesjährige Nachfragemuster von den Vorjahren unterscheidet (z. B. früherer saisonaler Anstieg, Markteinführung neuer Produkte), kann es sein, dass das Modell während des abweichenden Zeitraums zu wenig prognostiziert hat. Prüfen Sie, ob sich die zu unterschätzende Tendenz auf bestimmte Wochen oder Monate konzentriert, die vom Muster des Vorjahres abweichen.
Bei längeren Zeithorizonten verschlechtert sich die Prognosegenauigkeit erheblich
Es ist normal, dass sich die Genauigkeit mit steigendem Prognosehorizont verschlechtert — Woche 1 ist immer genauer als Woche 8. Wenn die Verschlechterung jedoch stärker als erwartet ist:
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. Dies ist zu erwarten — ziehen Sie in Betracht, die Regeln auf weitere Wochen auszudehnen, und zwar mit einem kombinierten Ansatz (z. B. 50/50 Mischung aus externen Signalen und Ausgangswerten für mittelfristige Wochen).
Bei längeren Zeithorizonten wird der Ausgangswert wieder auf einen langfristigen Durchschnitt zurückgesetzt. Statistische Modelle verlieren bei längeren Zeithorizonten an Selbstvertrauen und tendieren eher zum historischen Mittelwert. Liegt die jüngste Nachfrage über dem historischen Mittelwert, werden die äußeren Wochen als unterbewertet erscheinen. Dies ist ein Modellverhalten, kein Konfigurationsproblem.
Die Volatilität der Nachfrage macht längere Horizonte von Natur aus schwieriger. Wenn Ihre Nachfrage von Woche zu Woche eine hohe Variabilität aufweist (Variationskoeffizient > 0,5), weist selbst ein perfektes Modell bei längeren Horizonten hohe Fehler auf. Konzentrieren Sie sich bei der Bewertung der Genauigkeit auf die ersten 3—4 Wochen, was für die meisten Operationen das umsetzbare Planungsfenster ist.
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 (oft 30— 50%). Produkte ohne externes Signal verwenden immer noch den Basiswert. Prüfen Sie Ihre Abdeckungsrate — wenn sie unter 50% liegt, sind die Auswirkungen 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, bevor Sie sie in Regeln verwenden. Wenn der WAPE schlechter als der Ausgangswert ist, 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 mit Nullnachfrage aus, anstatt explizit Null zu melden. Wenn Ihre Konsensregel lautet: „Wenn EDI = 0, Prognose auf 0 setzen“, wird sie niemals 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 bei 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, bei der das externe Signal direkt für alle Wochen verwendet wird, kann die Genauigkeit bei längeren Zeithorizonten beeinträchtigen. Ziehen Sie einen abgestuften Ansatz in Betracht: Direkter Ersatz für die Wochen 1—3, gemischt für die Wochen 4—6, Ausgangswert nur für 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 entspricht möglicherweise keinem Produkt. Wenn die Regel auf ein Produktattribut (z. B. product_group_id) verweist, das nicht in den Artikelmetadaten enthalten ist, stimmt es stillschweigend mit nichts überein.
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.
Das Ergebnis des Konsensplans ist identisch mit der Basisprognose
Wenn der ConsensusForecast Export dieselben Werte wie der Prognoseexport (Basisexport) hat, wurden die Konsensregeln nicht ausgeführt. Häufige Ursachen:
Die Dimensionen stimmen in der Verknüpfung nicht überein. Die Konsensus-Engine verknüpft Planeingaben anhand von Dimensionsspalten (Produkt-ID, Standort-ID, Datum) mit dem Basisplan. Wenn sich die Spaltennamen zwischen den Baseline- und den Planeingaben unterscheiden (z. B. verwendet Baseline item_id, während EDI product_id verwendet), führt die Verknüpfung zu keinen Übereinstimmungen und alle Regeln entsprechen dem Baseline-Standard. Stellen Sie sicher, dass die Dimensionszuordnung in Ihrer Datenflusskonfiguration den beiden Schemas korrekt zugeordnet ist.
Das Datumsformat stimmt nicht überein. Der Basisplan kann Daten als 2026-03-02 speichern, während Planeingaben sie als 2026-03-02 speichern. T00:00:00.000Z Wenn für die Verknüpfung eine exakte Übereinstimmung erforderlich ist, stimmen Zeitzonendaten und Zeitzonenangaben nicht überein. Vergewissern Sie sich, dass Datumsspalten in dasselbe Format konvertiert wurden, bevor Sie sie verknüpfen.
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 für eine Planeingabe keine Zeilen angezeigt werden, konnte die Datei möglicherweise nicht geladen werden.
Die Konsensus-Forecast_ID entspricht der Baseline forecast_id. Wenn beide Exporte dieselbe Forecast_ID verwenden, erstellte die Konsensus-Engine eine direkte Kopie des Basiswerts ohne Verarbeitung. Dies weist auf ein Problem auf Systemebene hin. Wenden Sie sich mit der 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 in Ihrer Regel „Auf Websites in [list] anwenden“ steht, der generierte Code jedoch eine Spalte überprüft, die nicht existiert oder andere Werte hat, übergibt der Filter möglicherweise stillschweigend alle Zeilen. Überprüfen Sie dies, indem Sie einige bestimmte Produkte, die NICHT von der Regel betroffen sein sollten, stichprobenartig überprüfen.
Die Reihenfolge der Regelprioritäten kann umgekehrt sein. Regeln werden als Kette angewendet, wobei spätere Regeln frühere Regeln überschreiben. Wenn eine allgemeine Regel (z. B. „Basisregel für alles 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 in Ihren Regelbeschreibungen die Prioritätsreihenfolge eindeutig angegeben ist.
Die Prognosewerte sind fraktionell (z. B. 2.500,37 Einheiten)
Statistische Modelle erzeugen kontinuierliche Werte, keine ganzen Zahlen. Wenn Ihr Unternehmen ganze Einheiten, Kartonpackungen oder Mindestbestellmengen anbietet:
Fügen Sie als letzten Konsensschritt eine Rundungsregel hinzu. Eine einfache Regel „Auf nächste Ganzzahl runden“, die nach allen anderen Konsensregeln angewendet wird, bereinigt Bruchwerte. Werte unter 0,5 werden auf Null gerundet, was für Kombinationen mit sehr geringer Nachfrage geeignet ist.
Erwägen Sie, auf betriebsbereite Größen zu runden. Wenn Ihre Produkte in Standardpackungsgrößen versendet werden (z. B. Kartons mit 12 Stück, Paletten mit 48), kann das Runden auf die nächste gültige Packungsgröße sowohl die Benutzerfreundlichkeit als auch die Genauigkeit der Prognose verbessern. Dazu sind Angaben zur Packungsgröße in Ihrem Produktmaster erforderlich. Teilen Sie Ihrem Support-Team Ihre MOQ- oder Packungsgrößendaten mit, um diese Option zu prüfen.
Nach dem Hinzufügen von Regeln für die Vorverarbeitung sinkt der Produktumfang erheblich
Regeln für die Vorverarbeitung, die die Trainingsdaten filtern (z. B. „Prognostizieren Sie nur Produkte, deren Nachfrage mindestens 8 Wochen lang nicht Null ist“), können die Anzahl der Produkte in der Prognose drastisch reduzieren, wenn Ihre Daten auf der Ebene „Produkt × Standort“ spärlich sind:
Prüfen Sie die Granularität. Ein Produkt kann 52 Wochen lang auf Produktebene nachgefragt werden, bei einer Kombination aus Produkt und Standort jedoch nur 3 Wochen. Ein Mindestwert für die Historie auf der Ebene Produkt × Standort 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. Zählen Sie, bevor Sie eine Vorverarbeitungsregel aktivieren, im Vergleich zu Ihrer aktuellen Gesamtzahl, wie viele Kombinationen aus Produkt und Standort den Filter bestehen. Wenn mehr als 20% ausgeschlossen werden, ist die Regel wahrscheinlich zu aggressiv. Beginnen Sie mit einem milden Schwellenwert und verschärfen Sie ihn schrittweise.
