Was vorher fertig sein muss
Ein validiertes Causal Loop Diagram mit identifizierten Feedback Loops, Stocks und Flows liegt vor, das als Strukturvorlage für das quantitative Modell dient.
Stocks und Flows sind als Diagramm mit Einheiten, Anfangswerten und vermuteten Raten skizziert.
Was vor Start vorliegen muss
System-Dynamics-Tool (Vensim, Stella, Simantics System Dynamics, AnyLogic, BPTK-Py); Datenquellen für Anfangswerte und Raten; Versionskontrolle (Git, Modell-Dateien plus Skripte); Tabellenkalkulation für Datenaufbereitung.
Ein Modeler mit System-Dynamics-Erfahrung (lead); ein bis zwei Domain Experts für Raten und Annahmen; ein Daten-Owner für Anfangs- und Validierungsdaten; ein Stakeholder oder Auftraggeber für Szenario-Auswahl und Interpretation.
Frage und Zeithorizont; CLD und Stock-and-Flow-Skizze; verfügbare historische Daten zur Kalibrierung; bekannte Politik-Optionen; akzeptierte Unsicherheitsspanne; Reporting-Format.
Mehrere Tage bis Wochen
Modellordner im Repo mit /model, /data, /scenarios, /docs. Tool installiert und lizensiert. Datenset für Kalibrierung importiert. Frage und Zeithorizont sichtbar in der Modell-Doku.
Die eine Frage, die diese Methode beantwortet
Welche dynamischen Effekte und Politik-Hebel werden sichtbar, wenn die qualitative Struktur als quantitatives Modell über den Zeithorizont gerechnet wird?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Frage und Zeithorizont fixieren | Halber Tag | Konkret formulierte Politik- oder Strategie-Frage festlegen. Zeithorizont in Schritten (z. B. monatlich, 10 Jahre). Erfolgsbild für das Modell: was muss am Ende beantwortbar sein? | Wenn die Frage „wie sieht die Zukunft aus“ lautet, ist sie nicht beantwortbar. Frage muss vergleichende Form haben: Effekt einer Maßnahme A vs. B im Horizont. |
2Phase 2: Modell implementieren | 3-7 Tage | Stocks und Flows in Tool eintragen. Gleichungen für Raten formulieren. Hilfsvariablen, Lookups, Time Delays modellieren. Einheiten konsistent halten. Modell durchrunnen lassen ohne Fehler. | Einheiten-Check ist Pflicht. Ein einziges Mismatch zerstört die Aussagekraft. Tools haben oft eingebauten Units-Check, der nicht abgeschaltet werden darf. |
3Phase 3: Kalibrierung | 2-5 Tage | Modell gegen historische Daten laufen lassen (Hindcast). Parameter so anpassen, dass Verlauf realistisch passt. Fit-Metriken (z. B. RMSE) dokumentieren. Bei Mismatch Struktur statt Parameter prüfen. | Wer nur Parameter feinjustiert, um Daten zu passen (Overfitting), erhält keinen Prognosewert. Mismatch zeigt oft fehlende Loops, die zuerst strukturell ergänzt werden müssen. |
4Phase 4: Sensitivitätsanalyse | 1-2 Tage | Für 5-10 zentrale Parameter Bandbreiten definieren. Sensitivitäts-Runs (Monte Carlo oder strukturierte Tornado-Analyse) laufen lassen. Robuste vs. fragile Parameter identifizieren. | Wer einzelne Punktprognosen kommuniziert, suggeriert Präzision, die das Modell nicht liefert. Sensitivität gehört in jeden Output, sonst wird das Modell als Orakel missverstanden. |
5Phase 5: Szenarien und Politik-Tests | 1-3 Tage | Pro Szenario klare Parametereinstellung und Zeitachse definieren. Mindestens 3 Szenarien (Baseline, Maßnahme A, Maßnahme B). Ergebnisse als Verlaufskurven, nicht nur Endpunkte. | Endpunkt-Tabellen lügen oft: Maßnahmen wirken kurzfristig anders als langfristig. Verlaufskurve zeigt Overshoots, Delays und Reaktionen, die im Endpunkt verschwinden. |
6Phase 6: Interpretation und Reporting | Halber Tag | Ergebnisse mit Annahmen, Sensitivität und Limitationen dokumentieren. Stakeholder-Workshop für Interpretation. Modell mit Daten und Skripten als reproducible Bundle archivieren. | Wer das Modell ohne Annahmen-Disclosure präsentiert, lädt zur Fehlinterpretation ein. Annahmen müssen so prominent wie Ergebnisse kommuniziert werden. |
Was am Ende rauskommt
Repository mit Modell-Datei (Vensim mdl, Stella isd, Python notebook), Daten-Set, Szenario-Konfigurationen, Sensitivitäts-Reports, Verlaufskurven (Plots), Annahmen-Doku und Stakeholder-Briefing.
Modell mit SemVer im Git-Repo. Pro Major-Release strukturelle Änderungen dokumentiert. Daten-Snapshots datiert, nicht überschrieben. Szenario-Dateien als getrennte Files mit Beschreibung.
Kompakte Arbeitsvorlage für System Dynamics Simulation mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# System Dynamics Simulation Arbeitsvorlage
## Ziel
Quantitatives Simulationsmodell aus Stocks, Flows und Feedback Loops.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Simulationsmodell:
- Szenarienberichte:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Simulation — Förderprogramm Wärmepumpen Sachsen 2026-2040 (Modell v0.4, 18.05.2026)
**Frage**: Wie stark senkt eine Erhöhung der Investitionsförderung von 30% auf 45% den CO2-Ausstoß im Wohngebäudebestand bis 2040 verglichen mit dem Baseline-Pfad?
**Zeithorizont**: 2026-2040, monatliche Schritte.
**Stocks**: Anzahl Wärmepumpen, Anzahl Gasheizungen, CO2-kumuliert.
**Flows**: Installationsrate, Stilllegungsrate, Heizbedarf.
**Schlüsselparameter**: Installationsrate (200-650/Monat je Förderhöhe), Lebensdauer (18 Jahre), Heizbedarf (saisonal).
**Kalibrierung**: Hindcast 2018-2025, RMSE 4.2% bei Wärmepumpen-Bestand. Akzeptabel.
**Szenarien**:
- Baseline: 30% Förderung, kumulierter CO2 bis 2040: 84 Mt.
- Szenario A: 45% Förderung ab 2027, kumuliert 71 Mt (−15%).
- Szenario B: 45% + Gas-Abschaltung 2035: 58 Mt (−31%).
**Sensitivität**: Robust gegen Heizbedarfsvariation (±10% liefert ±2 Mt). Fragil gegen Installationskapazität (±20% liefert ±9 Mt). Politik-Empfehlung: Förderung allein begrenzt wirksam, Engpass ist Handwerkerkapazität.
**Limitationen**: Modell ignoriert Strompreis-Rückkopplungen und Wärmenetz-Konkurrenz.Symptome erkennen, gegensteuern
Stakeholder zitieren eine einzige Zahl („minus 15%“) ohne Bandbreite.
Ergebnisse immer als Bandbreite mit Sensitivität präsentieren. Punktwert in Reports ohne Confidence-Intervall ist verboten.
Modell läuft, aber Werte erscheinen plausibel obwohl Einheiten nicht passen (z. B. Monat vs. Jahr).
Tool-eigenen Units-Check aktivieren und nie deaktivieren. Bei Migration zwischen Tools manuell prüfen. Plausibilitäts-Check gegen externe Benchmark.
Modell passt perfekt auf Historie, Prognosen für Folgejahre weichen massiv ab.
Train-Test-Split: Kalibrierung auf älteren Daten, Validierung auf jüngeren. Bei strukturellem Mismatch Loops ergänzen, nicht weiter Parameter justieren.
Modell zeigt linearen Verlauf, Realität zeigt Sättigung oder Oscillation.
CLD und Stock-and-Flow zurückprüfen. Häufig fehlen Balancing Loops (Kapazitätsgrenzen, Sättigung). Strukturproblem, nicht Parameter.
Stakeholder lesen Plots und ziehen falsche Schlüsse über Wirkmechanismen.
Zu jedem Szenario kurze Erläuterung der Wirkmechanik (welche Loops dominieren wann). Stakeholder-Workshop statt PDF-Versand.
Sechs Monate später kann niemand das Modell mit denselben Annahmen neu rechnen.
Modell, Daten und Skripte versioniert ablegen. README mit Reproduktions-Befehl. Tool-Version in Doku fixieren.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.