Beratung vereinbaren
|
Beratung vereinbaren

Inside Forecasting: Was starke Prognoseanwendungen wirklich ausmacht

Kilian Schneider von HMS Analytical Software GmbH
Kilian Schneider

Veröffentlicht am 24. März 2026

Warum Zeitreihenprognosen in der Praxis selten ein reines Modellproblem sind

Zeitreihenprognosen werden häufig als klar definierte Machine-Learning-Aufgabe verstanden: Daten werden gesammelt und aufbereitet, Modelle trainiert, Forecasts generiert und über Metriken bewertet.

In Forecasting-Projekten zeigt sich jedoch, dass Prognosen selten isoliert als Modelloutput betrachtet werden. Sie sind in vielen Organisationen eine Grundlage für geschäftskritische Entscheidungen und damit automatisch Gegenstand intensiver Prüfung und Diskussion.

Ein zentrales Spannungsfeld entsteht dabei oft aus zwei Faktoren:

  • Forecasts werden über verschiedene Länder und Business Units hinweg benötigt, die jeweils eigene Anforderungen und Datenstände besitzen.
  • Neue Forecasting-Lösungen werden mit bestehendem Tooling verglichen, häufig anhand derselben Evaluationsmetrik.

Die technische Modellqualität ist damit nur ein Teil des Gesamtbildes. Entscheidend ist, ob Forecasts in der Organisation akzeptiert und nutzbar gemacht werden können.

Die folgenden Erkenntnisse basieren auf Projekterfahrungen aus der Entwicklung und Umsetzung von Forecasting-Lösungen in regulierten Unternehmensumgebungen bei HMS Analytical Software GmbH.

Management Summary: Was starke Prognoseanwendungen tatsächlich auszeichnet

Erfolgreiche Prognoseanwendungen zeichnen sich nicht allein durch eine beispielsweise hohe Genauigkeit aus, sondern durch Eigenschaften, die eine Nutzung im operativen Umfeld ermöglichen.

Drei Aspekte stechen aus den Projekterfahrungen besonders hervor:

  1. Akzeptanz entsteht durch Nachvollziehbarkeit, insbesondere dann, wenn Forecasts von bisherigen Planungen abweichen.
  2. Lokale Datenquellen sind geschäftlich relevant und müssen in ein generalisiertes Modellierungsframework integrierbar sein.
    Beispiel: Im Projektkontext wurde deutlich, dass Länder und Business Units häufig zusätzliche Datentöpfe besitzen, die in globalen Datensätzen nicht enthalten sind.
    Typische Beispiele für lokale Datenquellen können etwa regionale Preisaktionen, länderspezifische Vertriebsstrukturen, lokale Marketingkampagnen oder manuell gepflegte Absatzannahmen sein, die im globalen Reporting nicht abgebildet werden
  3. Forecast-Qualität darf nicht über eine einzelne Metrik entschieden werden, sondern muss über Validierung und Plausibilisierung abgesichert werden.

Zusätzlich muss eine Grundsatzentscheidung getroffen werden: Soll ein Forecast mittels unabhängigen und allgemeinen Ansatzes entstehen oder auf einzelne Business-Anforderungen angepasst werden? Die Antwort beeinflusst Akzeptanz und Governance der gesamten Lösung.

In HMS-Projekten zeigte sich dabei, dass technische Forecast-Qualität allein selten ausreicht, wenn die organisatorische Einbettung und die Vergleichbarkeit mit bestehenden Prozessen nicht geklärt sind.

Technischer Deep Dive: Wie Forecasting-Projekte in Enterprise-Umgebungen umgesetzt werden

Welche Plattformen und Technologien in Forecasting-Projekten genutzt werden

Die betrachteten Projekte wurden auf unterschiedlichen Plattformen umgesetzt. Genutzt wurden unter anderem:

Plattformen

  • Palantir Foundry
  • AWS
  • Snowflake
  • Databricks (inkl. MLflow)

Infrastruktur und Orchestrierung

  • CloudFormation
  • Lambda
  • Glue Jobs
  • Step Functions
  • Bash-Skripte

Umsetzung und Modellierung

  • Python
  • PySpark
  • Jupyter
  • Optuna

Forecasting-Methoden

  • ARIMA
  • Prophet
  • Random Forest
  • XGBoost
  • LightGBM
  • CatBoost

Die Kombination dieser Technologien spiegelt typische HMS-Projektanforderungen wider: Forecasting muss nicht nur modelliert, sondern als reproduzierbarer End-to-End-Prozess in bestehende Datenplattformen integriert werden.

Die Methoden zeigen, dass Forecasting in der Praxis häufig sowohl klassische Zeitreihenverfahren als auch Machine-Learning-Modelle umfasst – abhängig von Datenlage, Zielbild und Skalierungsanforderungen.

Warum Explainable AI für Zeitreihenprognosen ein Akzeptanzfaktor ist

Ein zentrales Learning aus dem Projektkontext lautet:

Verständnis führt zu Akzeptanz.

Forecasting-Systeme werden nicht automatisch akzeptiert, nur weil sie mathematisch oder statistisch überzeugend wirken. Besonders dann, wenn eine neue Applikation mit bestehenden Prozessen oder Tools verglichen wird, entsteht Erklärungsbedarf.

Im Projektkontext wurde daher empfohlen, Lösungen frühzeitig „zum Anfassen“ bereitzustellen, etwa durch:

  • erklärende Komponenten (XAI)
  • Visualisierungen
  • Simulationsoptionen zur Interaktion und Einflussnahme

Explainable AI für Zeitreihenprognosen wird damit nicht als Zusatz verstanden, sondern als Voraussetzung, um Forecasts in die Entscheidungslogik des Business integrieren zu können.

Aus HMS-Sicht ist Explainability damit kein optionales Feature, sondern ein zentrales Element der Produktakzeptanz in Forecasting-Systemen.

Forecast-Differenzen erklären: Warum Abweichungen nicht automatisch Modellfehler sind

Ein wiederkehrender praktischer Mechanismus ist der Vergleich neuer Forecasting-Lösungen mit vorhandenem Tooling, häufig anhand identischer Evaluationsmetriken.

Dieser Vergleich entsteht typischerweise aus Business-Sicht: Der Erfolg eines neuen Tools wird daran bewertet, ob es gemessen an der bestehenden Metrik mindestens gleichwertig oder besser ist als das bisherige Verfahren.

Gleichzeitig wurde klar formuliert:

Niemals auf eine einzige Evaluationsmetrik verlassen.

Aus Data-Science-Perspektive reicht eine einzelne Kennzahl nicht aus, um Prognosequalität umfassend zu bewerten. Forecasts sollten zusätzlich gegen tatsächliche Werte validiert werden, beispielsweise stichprobenartig über Plots, und gegen eine größere Anzahl an Metriken.

Abweichungen zwischen einer neuen Forecasting-Lösung und einem bestehenden Vergleichstool sind dabei nicht zwingend ein Hinweis auf schlechte Modellierung.

Ebenso können Differenzen zwischen Forecast und tatsächlichen Werten unterschiedliche Ursachen haben, die über eine einzelne Evaluationsmetrik hinausgehen.

In den Projekten zeigte sich, dass solche Abweichungen häufig aus strukturellen Unterschieden zwischen den Tools entstehen , etwa durch:

  • unterschiedliche Modellierungsansätze und –mechansimen
  • unterschiedliche Datengrundlage (global vs. Lokal)
  • unterschiedliche Datenvorverarbeitung

Forecast-Differenzen zu erklären bedeutet daher, jeweils klar zu benennen, welcher Vergleich vorgenommen wird: Gegen ein bestehendes Tool, gegen tatsächliche Werte oder entlang unterschiedlicher Datenkontexte.

Forecast-Revisionen: Warum Forecasting ohne Feedback kaum produktiv wird

Ein weiteres Learning aus den Projekten war, dass Forecasting-Systeme langfristig nur dann funktionieren, wenn Feedbackprozesse vorgesehen sind.

Erfolgreiche Applikationen leben von Feedback der Nutzer und des Business. Gleichzeitig sollte früh definiert werden:

  • wann Feedback abgegeben wird
  • wie Feedback einfließt
  • wie sich Nutzung und Verantwortung einer zentralen Forecasting- bzw. Analytics-Funktion zwischen den lokalen Ländern oder Business Units verteilt

Die Erfahrung zeigte zudem, dass Business-Nutzung oft erst dann entsteht, wenn das Business selbst Verantwortung für die Forecasting-Lösung übernimmt – beispielsweise finanziell oder organisatorisch.

Forecast-Revisionen sind damit weniger ein Sonderfall als eine erwartbare Konsequenz realer Nutzung.

Business-Story vs. unabhängige Prognose: Die zentrale Governance-Frage

Eine der wichtigsten fachlichen Entscheidungen betrifft die Ausrichtung der Prognose:

Soll das Forecasting-System eine unabhängige Vorhersage liefern oder soll es Business-Erwartungen berücksichtigen?

Im Projektkontext wurde diese Entscheidung explizit als Spannungsfeld formuliert:

  • Einbau von Business-Story bzw. Business-Expectations
  • unabhängige Vorhersageresultate
  • oder eine Mischung aus beiden Ansätzen

Die Klärung dieser Frage wurde als Grundlage für Akzeptanz bewertet. Ohne diese Entscheidung bleibt unklar, nach welchen Kriterien ein Forecast „richtig“ ist.

Diese Entscheidung hat sich in HMS-Projekten als zentrale Weichenstellung erwiesen, sowohl für die Modelllogik als auch für die spätere Nutzung durch Fachbereiche.

Warum lokale Datenquellen Forecasting-Projekte oft entscheiden

Forecasting-Projekte starten häufig mit globalen Datenquellen, beispielsweise Sales-Zahlen. Gleichzeitig verfügen Länder und Business Units häufig über zusätzliche lokale Datentöpfe.

Im Projektkontext wurde klar benannt, dass das Business häufig erwartet, dass diese lokalen Datenquellen beispielsweise als Indikatoren in Forecasts einfließen.

Eine Forecasting-Lösung sollte daher in der Lage sein, ein breites Spektrum lokaler Datenquellen in ein generalisiertes Modellierungsframework zu integrieren.

Systemische Einordnung: Betrieb, Skalierung und Stabilität aus Projekterfahrung

Warum ein unscharfes Zielbild im Forecasting zu falschen Erwartungen führt

Forecasting-Projekte können nur dann sinnvoll umgesetzt werden, wenn ein Zielbild definiert ist. In einem Projektkontext wurde explizit benannt, dass das angestrebte Zielbild zunächst unklar war, sowohl in Bezug auf Automatisierung und Standardisierung als auch auf die zugrunde liegende Datengrundlage.

Im Forecasting betrifft die Zieldefinition nicht nur technische Anforderungen, sondern vor allem die Frage, was als „gute“ Prognose gilt:
Soll primär eine Metrik optimiert werden?
Soll das bestehende Tool ersetzt oder ergänzt werden?
Oder steht Transparenz über Prognoseverhalten im Vordergrund?

Die Projekterfahrung zeigte, dass insbesondere die Erwartungshaltung des internen Kunden präzisiert werden muss, bevor Modellierung sinnvoll bewertet werden kann.

Warum Datenzugriff im Forecasting mehr ist als ein technisches Detail

Ein wiederkehrendes Hindernis im Projektverlauf war die Unsicherheit über die Datengrundlage sowie Verzögerungen durch Zugriffs- und Berechtigungsfragen.

Aus Kundensicht steht dabei vor allem eine andere Erwartung im Vordergrund:
Die relevanten Daten sollen vollständig, aktuell und zuverlässig verfügbar sein – insbesondere dann, wenn Prognosen als Entscheidungsgrundlage dienen.

Die Projekterfahrung lässt sich in einem Satz zusammenfassen:

Ohne Daten keine Ergebnisse.

Für die Umsetzung bedeutet das zweierlei:

  • Aus Kundensicht: Sicherstellung von Verfügbarkeit, Zugänglichkeit und Qualität der Daten.
  • Aus Implementierungssicht: Datenprobleme früh sichtbar machen und Verzögerungen transparent adressieren.

Forecasting-Systeme sind damit unmittelbar abhängig von organisatorisch geklärtem Datenzugriff – nicht nur von Modellqualität.

Warum Ergebnisdarstellung manchmal wichtiger ist als Infrastruktur

In einem Proof-of-Concept-Kontext wurde als Empfehlung formuliert: mehr Fokus auf Plots und Ergebnisdarstellung, weniger Fokus auf Infrastruktur.

Diese Beobachtung ist fachlich relevant, weil sie verdeutlicht, dass Forecasting-Projekte nicht allein über technische Eleganz bewertet werden, sondern über die Frage, ob Ergebnisse für Stakeholder nachvollziehbar und bewertbar sind.

Fazit

Starke Prognoseanwendung entstehen nicht nur durch die Wahl eines einzelnen Algorithmus, sondern durch die Fähigkeit, Forecasts nachvollziehbar, vergleichbar und organisatorisch anschlussfähig zu machen.

Die Projekterfahrungen zeigen: Akzeptanz entsteht durch Verständnis, Prognosequalität darf nicht über eine einzelne Metrik bewertet werden, und lokale Datenquellen sind häufig entscheidend für die tatsächliche Nutzbarkeit von Forecasting-Systemen.

HMS positioniert Forecasting daher nicht als reines Modellthema, sondern als Zusammenspiel aus Datenintegration, Modellierung, Validierung und Business-Akzeptanz.


Explainable AI für Zeitreihenprognosen bedeutet im Projektkontext, dass Forecasts so aufbereitet werden, dass Anwender sie nachvollziehen können – etwa durch erklärende Komponenten oder Interaktionsmöglichkeiten.
Weil Forecasts häufig mit bestehenden Lösungen verglichen werden und Abweichungen erklärt werden müssen. Verständnis wurde explizit als Grundlage für Akzeptanz beschrieben.
Forecast-Differenzen entstehen häufig durch unterschiedliche Modellierungsansätze, Datengrundlagen oder Datenaufbereitungen zwischen Tools. Sie sind daher nicht automatisch ein Hinweis auf ein schlechtes Modell und sollten immer im Kontext mehrerer Evaluationsmetriken und tatsächlicher Werte bewertet werden.
Weil eine einzelne Metrik keine vollständige Aussage über Forecast-Qualität erlaubt. Forecasts sollten zusätzlich gegen tatsächliche Werte validiert werden, beispielsweise durch Plots, oder gegen eine größere Anzahl an Metriken.
Forecast-Revisionen entstehen im Projektkontext insbesondere durch Feedback und durch die iterative Anpassung einer Applikation. Erfolgreiche Lösungen wurden explizit als feedbackgetrieben beschrieben.
Lokale Datenquellen sind häufig entscheidend, weil Länder und Business Units zusätzliche Datentöpfe besitzen und deren Einbindung erwartet wird.
Weil sie bestimmt, ob Forecasts als objektive Modellprognose oder als Business-orientierte Planung verstanden werden. Diese Klärung wurde als Grundlage für Akzeptanz benannt.
Im Projektkontext wurden u. a. Python, PySpark und Plattformen wie AWS, Snowflake, Databricks und Palantir Foundry eingesetzt.
Genannt wurden ARIMA, Prophet, Random Forest sowie Boosting-Modelle wie XGBoost, LightGBM und CatBoost.
Weil ein unscharfes Zielbild die Umsetzung erschwert und eine Weiterentwicklung weniger wahrscheinlich macht. Zielklarheit wurde explizit als elementar beschrieben.
Kilian Schneider
Senior Data Scientist

Fragen zum Artikel?

Wir geben gerne Antworten.
Kontaktieren Sie uns
© 2024 – 2026 HMS Analytical Software
chevron-down