> For the complete documentation index, see [llms.txt](https://docs.flowlity.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flowlity.com/de/nachfragemanagement/demand/run-forecast-review.md).
# Einen Review der Prognosegenauigkeit durchführen
Legen Sie fest, was gemessen wird und wer beteiligt ist, erstellen Sie dann eine Review-Ansicht, eine Shortlist von SKUs, korrigieren Sie die Inputs und halten Sie Entscheidungen fest.
Diese Anleitung führt Sie durch einen Review-Zyklus im Modul [Bedarf](/de/nachfragemanagement/demand.md).
### Einen Review-Prozess zur Prognosegenauigkeit einrichten
Ein Review der Prognosegenauigkeit ist der wiederkehrende Termin, an dem Ihr Planungsteam prüft, wo die Prognose danebenlag, versteht warum, und korrigiert, woraus das Modell lernt. Die Prognosegenauigkeit bestimmt sowohl den Bestand (zu viel Puffer, wenn die Prognose schwankt oder zu hoch ist) als auch die Verfügbarkeit (Bestandsausfälle, wenn sie zu niedrig ist). Ein kurzer, disziplinierter Review zahlt sich daher meist schnell aus.
#### 1. Was messen wir?
Nutzen Sie zwei Kennzahlen, jede für einen anderen Zweck. Beide sind als KPI-Spalten in der Bedarf-Produktliste verfügbar (siehe [KPIs](/de/konzepte/concepts/kpis.md) und das [Kennzahlen-Glossar](/de/konzepte/concepts/metrics-glossary.md)).
| Kennzahl | Wofür Sie sie nutzen | Worauf Sie achten sollten |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **MAE** (mittlerer absoluter Fehler) | Produkte nach Fehlergröße **ordnen**. Kombinieren Sie ihn mit dem vergangenen Bedarf in Wert, um die geschäftliche Auswirkung zu sehen. | Der MAE wird in Mengeneinheiten ausgedrückt. Vergleichen Sie also Produkte mit ähnlichen Einheiten. |
| **MAPE** (mittlerer absoluter prozentualer Fehler) | Die Genauigkeit als Prozentsatz **kommunizieren**, bei Produkten mit hohem Volumen und regelmäßigem Absatz. | Der MAPE explodiert bei Produkten mit geringem Volumen und intermittierendem Bedarf: 1 verkaufte Einheit bei einer Prognose von 3 ergibt 200 % Fehler, kostet aber fast nichts. |
Einige Regeln machen die Zahlen verlässlich:
* **Mit dem MAE ordnen, nicht mit dem MAPE.** Eine nach MAPE sortierte Liste wird von kleinen, sporadischen Produkten dominiert. Eine nach MAE sortierte Liste bringt die Produkte nach oben, bei denen der Fehler am meisten kostet.
* **Auf der Ebene messen, auf der Sie planen.** Prüfen Sie auf SKU-Ebene, aber schauen Sie auch auf die Ebene der Produktfamilie oder des Modells. Wenn eine neue Variante einer älteren Absatz wegnimmt, sieht jede SKU falsch aus, während die Summe der Familie genau sein kann.
* **Mit Ihrer bisherigen Methode vergleichen.** Wenn Sie eine externe Prognose laden (Budget, Altsystem), stellen Sie sie neben die finale Prognose. So sehen Sie, ob Flowlity die bisherige Arbeitsweise verbessert.
* **Prüfen, ob Ihre Wert-KPIs den richtigen Preis verwenden.** Der Bedarf in Wert sollte den Preis widerspiegeln, zu dem der Bedarf verkauft wird. Fragen Sie im Zweifel Ihren Flowlity-Ansprechpartner, welchen Preis Ihre Wert-KPIs verwenden.
{% hint style="info" %}
Es gibt keinen allgemein „guten" MAPE. Verfolgen Sie den Trend über die Zeit und vergleichen Sie Produktgruppen miteinander, statt einem absoluten Zielwert nachzujagen.
{% endhint %}
#### 2. Welche Artikel kommen zuerst?
Niemand kann Tausende von Prognosen prüfen. Prüfen Sie nach dem Ausnahmeprinzip, ausgehend von der geschäftlichen Auswirkung:
* **Hauptumsatzträger**: die Produkte, die etwa 80 % des Bedarfswerts ausmachen, typischerweise ABC-Klasse A.
* **Neueinführungen**: Produkte mit weniger als etwa sechs Monaten Historie, oft mit der [Bedarfsvorhersagbarkeit](/de/konzepte/concepts/metrics-glossary.md) Niedrig oder Keine.
* **Produkte mit Warnung**: Produkte, die bereits durch eine Flowlity-Warnung oder den Bedarfsanomalie-Agenten markiert sind.
Bevor Sie einzelne SKUs betrachten, **gruppieren Sie die Produktliste nach Hierarchie** (Produktfamilie, Kategorie oder eine beliebige Tag-Kategorie), um zu sehen, welche Gruppen den größten Fehler tragen. Gehen Sie dann nur in diese Gruppen. Zielen Sie auf eine Shortlist von **10 bis 20 Produkten pro Planer und Review**, nach Auswirkung geordnet.
Überspringen Sie Produkte, die in den letzten vier Wochen geprüft wurden, es sei denn, seitdem ist etwas Neues passiert. Die Spalte **Bedarfsüberprüfung** zeigt, wann jedes Produkt zuletzt geprüft wurde.
#### 3. Wer ist beteiligt?
| Rolle | Verantwortung |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Planungs- / Supply-Chain-Team** | Verantwortet den Review. Bereitet die Shortlist vor, diagnostiziert jedes Produkt, entscheidet über die finale Prognose und hält die Entscheidung fest. |
| **Vertriebsteam** | Beratend. Bringt Marktwissen ein (Aktionen, große Einmalaufträge, Einführungen, Ausläufe, Preisänderungen), jeweils mit dem Grund für den Input. |
| **Management** | Prüft monatlich die Genauigkeits-KPIs und zieht die Verantwortlichen zur Rechenschaft. |
Lassen Sie die Entscheidung bei einem Team. Wenn alle die Zahl ändern können, ist niemand für den Fehler verantwortlich.
#### 4. In welchem Rhythmus?
Passen Sie den Review-Rhythmus an das Tempo Ihres Geschäfts an:
* **Starten Sie wöchentlich**, für die ersten ein bis zwei Monate. In einem Review vorgenommene Änderungen werden in der Folgewoche sichtbar, so lernt das Team schnell, was funktioniert.
* **Wechseln Sie zu monatlich**, sobald der Prozess stabil ist.
* **Richten Sie sich nach Ihrem Bestellzyklus.** Geschäftsbereiche mit unterschiedlichen Lieferzeiten oder Bestellrhythmen können in unterschiedlichen Takten laufen. Ein Review zählt nur, wenn er vor der nächsten Bestellentscheidung stattfindet.
* **Planen Sie den Review nach dem Prognoselauf** und vor der Beschaffungsplanung ein, damit Bestellungen auf der geprüften Prognose aufbauen.
#### 5. Wie handeln wir?
Zwei Regeln halten den Review wirksam:
* **Benennen Sie die Ursache, bevor Sie etwas ändern.** Die meisten schlechten Prognosen gehen auf wenige Ursachen zurück, siehe [Prognosefehler diagnostizieren](/de/nachfragemanagement/demand/diagnose-forecast-errors.md).
* **Korrigieren Sie den Input, nicht die Zahl.** Eine manuelle Änderung an Meine Prognose korrigiert eine Zahl für einen Lauf. Der nächste Lauf erzeugt denselben Fehler, weil sich die Historie nicht geändert hat. Die Historie zu bereinigen, ein ähnliches Produkt zu verknüpfen, ein Expertenmodell anzuwenden oder ein Prognoseereignis zu erstellen, korrigiert jeden künftigen Lauf.
Nutzen Sie eine manuelle Überschreibung nur für wirklich neue Informationen, die das Modell nicht kennen kann, und fügen Sie immer einen Kommentar mit der Begründung hinzu.
#### 6. Woran erkennen wir Erfolg?
Verfolgen Sie in Ihrem monatlichen Review eine kleine Auswahl an KPIs. Erfassen Sie in den ersten Wochen eine Ausgangsbasis und vereinbaren Sie dann Zielwerte.
| KPI | Warum er zählt |
| ------------------------------------------------ | ------------------------------------------------------------- |
| Fehler (MAE) bei A-Produkten, nach Produktgruppe | Das Fehlervolumen dort, wo es am meisten zählt |
| MAPE bei A-Produkten mit regelmäßigem Bedarf | Eine verständliche Genauigkeitszahl für das Management |
| Review-Abdeckung | Anteil der Shortlist-Produkte, die tatsächlich geprüft wurden |
| Überschreibungen mit dokumentiertem Grund | Jede manuelle Änderung lässt sich später erklären |
| Einführungen ohne ähnliches Produkt | Neue Produkte, die aus dem Nichts prognostiziert werden |
{% hint style="info" %}
Ein Review der Prognosegenauigkeit zeigt nur einen Teil des Bildes, solange nicht der gesamte Planungskreislauf in Flowlity läuft. Prognoseanpassungen, validierte Bestellungen und Bestand fließen alle in die Projektion von Flowlity zurück. Führen Sie den Review daher zusammen mit der Beschaffungsplanung in der App durch, nicht isoliert.
{% endhint %}
{% hint style="info" %}
Ein hoher Fehler bedeutet nicht automatisch Bestandsausfälle. Die probabilistische Prognose von Flowlity speist den Sicherheitsbestand, und der Puffer wächst mit der Prognoseunsicherheit und der Lieferzeit. Siehe [Einstellungen für den Sicherheitsbestand](/de/konzepte/concepts/buffer-policies.md).
{% endhint %}
### Den Review Schritt für Schritt durchführen
{% stepper %}
{% step %}
#### Eine Ansicht für den Prognose-Review erstellen
Starten Sie unter **Nachfragemanagement** > **Bedarf** mit der Ansicht **🎯 Prognosegenauigkeit** und fügen Sie über die Leiste **Spalten** diese Spalten hinzu (siehe [KPIs](/de/konzepte/concepts/kpis.md)):
* **Vergangener Bedarf** in Wert, letzte 12 Monate: das geschäftliche Gewicht jedes Produkts.
* **Vergangener Bedarf** mit Trend: um steigende oder fallende Produkte zu erkennen.
* **Finale Prognose** für die kommenden Monate.
* **Externe Prognose**, wenn Sie eine laden: zum Vergleich mit Ihrer bisherigen Methode.
* **Finale Prognose MAE** und **Finale Prognose MAPE** für den geprüften Rückblickzeitraum (letzte 30 Tage für einen wöchentlichen Review, letzte 90 Tage für einen monatlichen).
* Ihr **ABC**-Tag und Ihre **Hierarchie**-Tags (Produktfamilie, Kategorie, Modell).
* **Bedarfsüberprüfung**: das Datum der letzten Prüfung.
* **Angewendete Expertenmodelle**: um zu sehen, welche Produkte bereits ein Expertenmodell verwenden.
Filtern Sie zum Start auf aktive Produkte und ABC-Klasse A. Nach einem KPI können Sie über seine Spaltenüberschrift filtern. Speichern Sie das Ganze als benutzerdefinierte Ansicht und setzen Sie das Häkchen bei **Öffentlich machen**, damit das ganze Team dieselbe Liste nutzt (siehe [Ansichten einrichten und verwalten](/de/alltagliche-aufgaben/how-tos/set-up-views.md)).
{% endstep %}
{% step %}
#### Nach Hierarchie gruppieren, um den Fehler zu verorten
Klicken Sie auf **Gruppieren** > **Gruppe hinzufügen** und gruppieren Sie nach einer Hierarchie-Tag-Kategorie, etwa der Produktfamilie. Sie können auch nach Lieferant, Kunde oder Standort gruppieren. Jede Gruppe zeigt Zwischensummen (gewichtete Mittelwerte für MAE und MAPE) und eine **Gesamtsumme**.
Lesen Sie die Gruppen von oben nach unten:
* Beginnen Sie mit den Gruppen, die **hohen Bedarf und hohen MAE** verbinden.
* Behandeln Sie einen sehr hohen MAPE in einer Gruppe mit sehr wenig Bedarf mit niedriger Priorität.
* Eine große Gruppe ohne Hierarchie-Tag ist selbst ein Befund: Vervollständigen Sie die Tags, damit jedes Produkt in einer Gruppe landet.
Fügen Sie eine zweite Gruppierungsebene auf Modell- oder Familienebene hinzu (zum Beispiel die Ebene, die alle Farben oder Versionen eines Modells enthält), damit auslaufende Produkte und ihre Nachfolger zusammen erscheinen.
Speichern Sie die Gruppierung in der Ansicht, damit sie für den nächsten Review bereitsteht.
{% endstep %}
{% step %}
#### Die Shortlist erstellen
Klicken Sie auf **Sortieren** > **Sortierung hinzufügen**, um absteigend nach **MAE** und dann nach vergangenem Bedarf in Wert zu ordnen. Sie können auch Strg (Cmd auf dem Mac) gedrückt halten und auf Spaltenüberschriften klicken, um Sortierungen zu stapeln.
Klappen Sie die Gruppen mit Priorität auf und wählen Sie **10 bis 20 Produkte pro Planer**, nach Auswirkung geordnet. Nehmen Sie Neueinführungen und Produkte aus der Ansicht **🛸 Ausreißer** hinzu, auch wenn sie weiter unten stehen.
Überspringen Sie Produkte, deren Datum in **Bedarfsüberprüfung** weniger als vier Wochen zurückliegt, es sei denn, seitdem ist eine neue Anomalie aufgetreten.
{% endstep %}
{% step %}
#### Jedes Produkt diagnostizieren
Öffnen Sie die Detailansicht jedes Produkts und vergleichen Sie den vergangenen Bedarf, die **Finale Prognose** und, falls vorhanden, die **Externe Prognose**. Aktivieren Sie in der Legende **Unbereinigter vergangener Bedarf (N-1)** und **Unbereinigter vergangener Bedarf (N-2)**, um mit den Vorjahren zu vergleichen. Benennen Sie die Ursache, bevor Sie etwas ändern, siehe [Prognosefehler diagnostizieren](/de/nachfragemanagement/demand/diagnose-forecast-errors.md).
Wenn die Ursache in den Daten nicht sichtbar ist, etwa ein starker Rückgang ohne Bestandsausfall, notieren Sie sie und fragen Sie das Vertriebsteam.
{% endstep %}
{% step %}
#### Den Input korrigieren, nicht die Zahl
Wenden Sie die Korrektur an, die zur Ursache passt:
| Ursache | Korrektur |
| ----------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Bestandsausfall, Ausreißer oder vergangene Aktion in der Historie | Prüfen Sie die Korrektur von Flowlity: behalten, Wert ändern oder löschen ([Bedarfsanomalien untersuchen und beheben](/de/nachfragemanagement/demand/investigate-demand-anomalies.md)). |
| Nachfolgeprodukt mit wenig Historie | Verknüpfen Sie das Produkt, das es ersetzt ([Produktähnlichkeiten](/de/konzepte/concepts/product-similarities.md)). |
| Ganz neues Produkt | Wenden Sie das Expertenmodell **Einführungsmodell** an ([Bedarf](/de/nachfragemanagement/demand.md)). |
| Dauerhafte Änderung von Niveau oder Trend | Wenden Sie ein Expertenmodell an, etwa **Modell Durchschnitt der letzten Perioden** oder **Modell Durchschnitt + Trend** ([Bedarf](/de/nachfragemanagement/demand.md)). |
| Zu wenig Historie für eine verlässliche Prognose | Setzen Sie die **Prognosequelle** in der **Produktstrategie** auf Ihre externe Prognose, bis genug Historie vorhanden ist. |
| Bekanntes zukünftiges Ereignis (Aktion, Störung, Großauftrag) | Erstellen Sie ein Prognoseereignis ([Prognoseereignisse erstellen und anwenden](/de/umsatzoptimierung/promotions/create-forecast-events.md)). |
| Auslaufendes Produkt wird weiter prognostiziert | Legen Sie seinen **Auslauf** unter **Produktstrategie** > **Prognose** fest. Für viele Produkte: **⋮** > **Produktstrategie bearbeiten** > **Lebenszyklus bearbeiten**. |
| Wirklich neue Information, die das Modell nicht kennen kann | Passen Sie Meine Prognose an und fügen Sie einen Kommentar mit dem Grund hinzu. |
| {% endstep %} | |
{% step %}
#### Das Review-Meeting abhalten
Ein Meeting von 45 Minuten reicht meist aus:
| Minuten | Block | So sieht es gut aus |
| ------- | ----------------------------- | ----------------------------------------------------------------------------------------- |
| 30 | Durchgang durch die Shortlist | Für jedes Produkt: Ursache benannt, Korrektur angenommen oder abgelehnt |
| 10 | Input des Vertriebs | Jeder Input gehört, beziffert und kommentiert |
| 5 | Abschluss | Entscheidungen festgehalten, jede offene Aufgabe hat einen Verantwortlichen und ein Datum |
Das Planungsteam leitet und entscheidet. Das Vertriebsteam wird für Marktinput hinzugezogen.
{% endstep %}
{% step %}
#### Entscheidungen festhalten
Klicken Sie in der Produktdetailansicht auf **Prüfen**, um das Prüfdatum zu setzen, und dokumentieren Sie jede Entscheidung im Bereich [Kommentare](/de/konzepte/concepts/comments.md) des Produkts, damit der nächste Prüfer sieht, was getan wurde und warum. Klicken Sie nach einer Änderung eines Inputs auf **Prognose berechnen**, um die neue Prognose vor dem nächsten wöchentlichen Lauf zu sehen (dies verbraucht Credits).
Führen Sie über alle Sitzungen hinweg ein einfaches Review-Protokoll (Produkt, Ursache, Maßnahme, Verantwortlicher). Nach einigen Reviews zeigt es, ob ein Problem vereinzelt oder systematisch ist. Wiederholte Auslauffälle deuten zum Beispiel auf einen Stammdatenprozess hin, der korrigiert werden muss, statt auf einzelne Prognosen.
{% endstep %}
{% step %}
#### Die KPIs monatlich prüfen
Schauen Sie sich einmal im Monat die Genauigkeits-KPIs nach Produktgruppe, die Review-Abdeckung und den Anteil der Überschreibungen mit dokumentiertem Grund an. Entscheiden Sie anhand des Trends, worauf Sie sich als Nächstes konzentrieren und wann Sie vom wöchentlichen zum monatlichen Rhythmus wechseln.
{% endstep %}
{% endstepper %}
{% hint style="info" %}
Der Skill **Prognose-Audit** kann die Shortlist für Sie vorbereiten. Bitten Sie in einem mit Flowlity verbundenen KI-Assistenten: *„Führe ein Prognose-Audit durch"*. Er liefert eine geordnete Liste von Produkten mit dem Grund, warum jedes markiert wurde, und einer vorgeschlagenen Korrektur des Prognose-Inputs. Er liest nur Daten: Der Planer nimmt jeden Vorschlag in der App an oder lehnt ihn ab. Siehe [Skills](/de/ki-and-automatisierungen/co-planner/mcp/skills.md).
{% endhint %}
### Verwandte Seiten
* [Prognosefehler diagnostizieren](/de/nachfragemanagement/demand/diagnose-forecast-errors.md): häufige Ursachen und ihre Korrekturen.
* [Ansichten einrichten und verwalten](/de/alltagliche-aufgaben/how-tos/set-up-views.md): die Review-Ansicht mit ihren Spalten, Filtern und ihrer Gruppierung speichern.
* [Bedarfsanomalien untersuchen und beheben](/de/nachfragemanagement/demand/investigate-demand-anomalies.md): Engpässe, Ausreißer und vergangene Aktionen bereinigen.
* [Prognoseereignisse erstellen und anwenden](/de/umsatzoptimierung/promotions/create-forecast-events.md): bekannte zukünftige Ereignisse in die Prognose aufnehmen.
* [Bedarf](/de/nachfragemanagement/demand.md): Expertenmodelle, Meine Prognose und Prognose berechnen.
* [Kommentare](/de/konzepte/concepts/comments.md): Review-Entscheidungen an einem Produkt festhalten.
* [Bedarfsprognose erklärt](/de/konzepte/concepts/demand-forecasting.md): wie die Prognose entsteht.
