# Daten-WG Knowledge Kitchen — Volltext-Buendel
Diese Datei buendelt die inhaltlich dichtesten Dokumente der Site in einer
einzigen Markdown-Datei. Der thematische Index mit allen Einzeldateien steht
in https://datenwgknowledgekitchen.com/llms.txt
Konfidenzstufen, die in den Dokumenten auftauchen: A mehrfach belegt /
institutionelle Primaerquelle · B einfach belegt · C schwache Belegbasis ·
M Modellsetzung, nicht quellenbelegt. Die datenjournalistischen Arbeiten sind
als Entwurf gekennzeichnet; Zahlen bitte nur mit Konfidenzstufe und Datenstand
zitieren.
Autor: Michael Tenner, Daten-WG Knowledge Kitchen, https://datenwgknowledgekitchen.com
Nicht enthalten (zu gross fuers Buendel, einzeln unter /md/ abrufbar):
der Power-BI-Einsteiger-Guide, der Microsoft-Fabric-Einsteiger-Guide,
die ChartKitchen-Dokumentation und die Video-Linkliste.
==============================================================================
DOKUMENT: https://datenwgknowledgekitchen.com/md/whitepaper-strommix.md
==============================================================================
# Was braucht ein gesunder Strommix — und was kostet er?
> Interaktives White Paper: ein nachgerechnetes Kostenmodell fuer das deutsche Stromsystem 2045, mit Monte-Carlo-Unsicherheit, Emissionsbilanz und offengelegten Datenluecken.
- **Quelle:** https://datenwgknowledgekitchen.com/whitepaper-strommix.html
- **Markdown-Fassung:** https://datenwgknowledgekitchen.com/md/whitepaper-strommix.md
- **Autor:** Michael Tenner · Daten-WG Knowledge Kitchen
- **Stand der Daten:** 2026-08-19 (Git-Commit-Datum der Quelldaten)
- **Modellstand:** v0.2c
- **Status:** Entwurf. Jede Zahl traegt eine Konfidenzstufe — A/B/C bzw. M fuer Modellsetzung. Ohne die Konfidenzstufe ist eine Zahl aus diesem Dokument nicht zitierfaehig.
- **Zitierhinweis:** Michael Tenner, Daten-WG Knowledge Kitchen, https://datenwgknowledgekitchen.com/whitepaper-strommix.html — Abruf mit Datum angeben. Weiterverwendung mit Quellenangabe erwuenscht; Zahlen bitte mit Konfidenzstufe und Stand uebernehmen.
- **Erzeugt von:** `strommix/scripts/build_md_exports.py` (generierte Datei — nicht von Hand editieren)
- **Simulation:** 1.000 gepaarte Ziehungen je Konfiguration, Basis-Seed 20260815, PRNG mulberry32 (32-Bit, bitidentisch nach JavaScript portierbar)
- **Maschinenlesbare Rohdaten:** `https://datenwgknowledgekitchen.com/strommix/data/model_params.json`, `https://datenwgknowledgekitchen.com/strommix/data/monte_carlo_reference.json`, `https://datenwgknowledgekitchen.com/strommix/data/page_data.json`
---
## Kernaussagen
1. **Der Vergleich ist nicht entschieden.** Die beiden vordersten Pfade — das kernkraftgestuetzte Kostenminimum und der gasgestuetzte 80-%-EE-Pfad — liegen im deterministischen Punktwert 159,0 zu 156,8 EUR/MWh auseinander. Das ist weniger als die Breite der Unsicherheit.
2. **Der Beinahe-Gleichstand vergleicht ungleiche Emissionen.** 28 gegen 107 Mt CO2 pro Jahr. Erst mit Abscheidung auf beiden Seiten wird der Vergleich emissionsaequivalent — und dreht die Richtung.
3. **Ein einziger Modellparameter bewegt das Ergebnis ueber die ganze Breite.** Der mixunabhaengige Sockel im Uebertragungsnetz (Setzung 0,40, Sensitivitaet 0,20–0,60) verschiebt den Abstand zwischen beiden Pfaden von -2,3 bis +4,5 EUR/MWh.
4. **Der CO2-Preis ist der Kipppunkt.** Deterministisch kippt der Vergleich bei 101,8 EUR/t, ueber gepaarte Ziehungen bei rund 152 EUR/t. Der ETS-1-Marktpreis lag bei 74 EUR/t — also unterhalb der Kippmarke; gerechnet wird mit 75 EUR/t.
5. **Das Ist-System ist der teuerste Anker.** 180,8 EUR/MWh bei 136 Mt CO2 — jedes Zielszenario ist billiger und sauberer als der Status quo.
6. **Die Datenbasis der Simulation ist unvollstaendig.** Die Stundenprofile decken 4.416 Stunden ab (`PARTIAL`, H2-2024-basiert (Teilzeitraum)). Netzbetrieb, Redispatch, Verluste, Import, Export und Lastmanagement sind nicht modelliert.
---
## 1 · Ist-Zustand 2025
Quelle der Jahreszahlen: AG Energiebilanzen, STRERZ-Datenblatt 2025 / AGEB-Wintertagung 15.12.2025 (Konfidenz: medium).
| Kennzahl | Wert |
|:---|---:|
| Bruttostromerzeugung inkl. Pumpspeicher | 509,3 TWh |
| Bruttostromerzeugung ohne Pumpspeicher | 502,2 TWh |
| Erneuerbare gesamt | 292,0 TWh |
| Fossil gesamt | 217,3 TWh |
| Kernenergie | 0,0 TWh |
| Import | 76,2 TWh |
| Export | 54,3 TWh |
### Bruttostromerzeugung nach Energietraegern (TWh)
| Energietraeger | TWh | Konfidenz | Anmerkung |
|:---|---:|:---:|:---|
| wind onshore | 110,1 | medium | |
| photovoltaik | 89,5 | medium | |
| erdgas | 84,9 | medium | |
| braunkohle | 75,2 | medium | |
| biomasse | 42,7 | medium | |
| mineraloel sonstige abfall | 28,9 | low | gemeinsam ausgewiesen; im Fossil-Block enthalten, nicht additiv |
| wind offshore | 28,0 | low | Differenzrechnung aus EE-Summe · abgeleitet |
| steinkohle | 25,0–28,0 | low | abgeleitet |
| wasserkraft | 21,0 | low | Differenzrechnung aus EE-Summe · abgeleitet |
| kernenergie | 0,0 | high | |
---
## 2 · Methodik in Kurzfassung
- **Modell:** `scripts/model.py (mix_system, Schritt 3)`, Version 0.2c.
- **Kennzahl:** System-LSCOE in EUR/MWh — Vollkosten des *Systems* (Erzeugung, Speicher, Backup, Netzanteil) je gelieferter MWh, nicht LCOE einzelner Kraftwerke.
- **Unsicherheit:** 1.000 Ziehungen je Konfiguration, Dreieck, Modus = mid, Grenzen = min/max aus data/model_params.json.
- **Gepaarte Ziehungen:** True — je Konfiguration laeuft EIN Ziehungsstrom, jede Ziehung wird auf ALLE Szenarien angewandt (common random numbers). Deshalb sind Rangvergleiche zwischen Szenarien zulaessig, obwohl die Verteilungen breit ueberlappen.
- **Perzentile:** lineare Interpolation zwischen Rangplaetzen, Index = (n-1)*p.
- **CO2-Preis im Basisfall:** 75,0 EUR/t.
- **Lastprofile:** H2-2024-basiert (Teilzeitraum), 4.416 Stunden, Vollstaendigkeit `PARTIAL`.
- **Reproduzierbarkeit:** Basis-Seed 20260815, PRNG mulberry32 (32-Bit, bitidentisch nach JavaScript portierbar) — die Ergebnisse sind aus den veroeffentlichten Rohdaten nachrechenbar.
### Modellannahmen
- Der Dispatch wird je Preset EINMAL mit mittleren Parametern gerechnet und zwischengespeichert; die 1000 Ziehungen wirken nur auf die Kostenseite.
- Damit wirkt die Volllaststunden-Ziehung nur auf die abgeleiteten Kapazitaeten und deren Kosten, nicht auf Erzeugungsmengen, Backup-Bedarf oder Abregelung.
- Gezogen werden CAPEX, Opex, Volllaststunden und der Erdgas-Brennstoffpreis je Technologie; optional WACC (Dreieck 3/5/9 %), CO2-Preis (Dreieck 0/75/400 EUR/t) und ein empirischer CAPEX-Ueberschreitungsfaktor.
- Bauzins- und Ueberschreitungsaufschlag werden nur auf die dafuer geeignete Kostenabgrenzung gelegt (idc_applicable_share / overrun_applicable_share, zwischen den CAPEX-Stuetzstellen linear interpoliert). Fuer Kernkraft heisst das: kein zusaetzlicher Bauzins auf Gesamtprojekt-Anker, kein Ueberschreitungsfaktor auf den bereits eskalierten Hinkley-Point-C-Anker.
- v0.2c (Fix 3): Der Ueberschreitungsaufschlag wird fuer Kernkraft als ABSOLUTER Betrag auf einer einzigen Schaetzbasis gerechnet ((f-1) x 7.500 EUR/kW x Rest-Anteil 0,48/0,50/0,00), nicht multiplikativ auf dem gezogenen CAPEX. Damit ist die Abbildung 'gezogener CAPEX -> effektiver CAPEX' in JEDER Konfiguration monoton nicht fallend (geprueft in validate_model.py und als Testvektor capex_eff_monotonic_nuclear exportiert).
- v0.2c (Fix 1): Das Uebertragungsnetz hat einen mixunabhaengigen Sockel (transmission_socket_share, SETZUNG 0,40 mit Sensitivitaet 0,20-0,60). Der Sockelanteil skaliert mit dem Jahresbedarf, der Rest mit der genutzten fEE-Arbeit.
- v0.2c (Fix 4): Abgeschiedene Menge und Restemission stammen aus EINER Massenbilanz (model.ccs_balance). Die capture_rate-Ziehung bewegt deshalb beide Seiten; captured + residual = Brennstoffeintrag gilt in jeder Ziehung exakt.
- Der Ist-2025-Anker traegt das heutige Netzentgelt statt der Netzinvestition bis 2045 und ist deshalb NICHT direkt mit den Zielszenarien vergleichbar (comparable_to_target_scenarios = false).
- Innerhalb einer Ziehung sind die Parameter ueber alle Presets identisch. Zwischen den Parametern sind die Ziehungen unabhaengig - MIT ZWEI AUSNAHMEN (v0.2c, siehe shared_links): Der Erdgaspreis wird einmal gezogen und von gas_ccgt und gas_ccs geteilt, und der CCS-CAPEX ist ein gezogener Faktor auf den in derselben Ziehung gezogenen GuD-CAPEX. Weitere reale Korrelationen (z. B. hoher CAPEX an guten Standorten) sind NICHT abgebildet - das unterschaetzt die Breite der Verteilung an den Raendern eher, als sie zu uebertreiben.
- Nicht variiert werden: Wetterjahr, Lastprofil, Lebensdauern, Wirkungsgrade, Kernbrennstoff- und Entsorgungskosten, Netzinvestitionsvolumen (ausser ueber den Ueberschreitungsfaktor 'netz').
- Ebenfalls nicht variiert: die H2-Speicherkosten (105 EUR/MWh_H2). Ihre dokumentierte Spanne oeffnet nur nach unten und ist laut Parameternotiz nur bei hoher Zyklenzahl erreichbar - der simulierte Saisonspeicher hat aber genau einen Zyklus im Jahr.
- Batterie, Elektrolyse, H2-Speicher und H2-Turbine haben in den Ueberschreitungsdatensaetzen (Flyvbjerg, Sovacool & Ryu) keine Projektklasse und bleiben deshalb bei Faktor 1,00. Das ist eine LUECKE, keine Messung - das Ueberschreitungs-Szenario ist damit asymmetrisch (siehe limitations.overrun_asymmetry).
### Bewusste Modellentscheidungen
- Kernkraft-Opex absolut in EUR/kW/a (kosten_kernkraft.md 4.2/7.2) - NICHT als CAPEX-Prozentsatz.
- Brennstoff und Entsorgung/Rueckbau als getrennte variable Posten (kosten_kernkraft.md 7.2).
- WACC global (3-9 %, Default 5 % wie GES); IDC-Aufschlag ueber Bauzeit separat.
- CO2-Preis wirkt nur ueber den direkten Emissionsfaktor fossiler Erzeugung; Lebenszyklus-g/kWh nur informativ.
- Backup/Speicher entstehen im Dispatch, nicht als pauschaler Risiko-Aufschlag (risiken_co2.md 9 risiko_aufschlaege_zusammenfassung backup_und_speicher).
- min/mid/max nicht mechanisch kombinieren - siehe scenario_sets (kosten_ee_speicher.md 12 derived_lcoe_selfcheck.warning).
- v0.2/M1: IDC nur auf Overnight-Anker (capex_scope/idc_applicable_share). Die Kernkraft-Anker mid/max enthalten Finanzierung bereits (kosten_kernkraft.md 7.3).
- v0.2/M2: Erdgas-Brennstoffpreis als thermischer Parameter (fuel_eur_mwh_th), Umrechnung ueber den Wirkungsgrad. Damit ist die Asymmetrie 'Gas gratis vs. H2 bezahlt' aufgehoben.
- v0.2/M3: Netzkosten in Uebertragung (328 Mrd., skaliert mit genutzter fEE-Energie) und Verteilnetz (323 Mrd., Sockel, skaliert mit Jahresbedarf) getrennt; Skalierung auf 1,0 gedeckelt.
- v0.2/M5: Restemissionen je Szenario werden ausgewiesen (Mt CO2/a). CCS ist NICHT modelliert.
- v0.2/M6: Ist-2025-Anker mit Kohle-, Biomasse- und Wasserbaendern und heutigen Netzentgelten statt der Netzinvestition bis 2045.
- v0.2/M7: Ueberschreitungsfaktor nur auf Schaetzbasis-Anker (overrun_applicable_share).
- v0.2b: Technologie gas_ccs (Abscheidung an GuD). CAPEX-Faktor 2,0 (NETL 2023), Wirkungsgradverlust 8 pp, Abscheiderate 90 %, Vollkette 50/80/100 EUR/t; die Restemission (49/120/220 g/kWh) traegt weiterhin den vollen CO2-Preis.
- v0.2b: Kontrastverteilung Asien/Golf fuer Kernkraft-CAPEX (1.870/3.150/4.950 EUR/kW, Bauzeit 8 a) - ausschliesslich als eigene Monte-Carlo-Konfiguration, NIE in der Basisspanne (Begruendung kosten_kernkraft.md 7.1, maschinenlesbar hinterlegt).
- v0.2c/1: Auch das Uebertragungsnetz bekommt einen mixunabhaengigen Sockel (transmission_socket_share, SETZUNG 0,20/0,40/0,60 mit Sensitivitaet). Bis v0.2b skalierte der 328-Mrd.-Block linear von null mit der genutzten fEE-Arbeit.
- v0.2c/2: Gemeinsame Rohstoff- und Definitionsziehungen - der Gaspreis wird EINMAL je Ziehung gezogen und von gas_ccgt und gas_ccs geteilt; der CCS-CAPEX ist ein gezogener FAKTOR (capex_factor_on_ccgt) auf den in derselben Ziehung gezogenen GuD-CAPEX.
- v0.2c/3: Der Ueberschreitungsaufschlag wird als absoluter Betrag auf EINER Schaetzbasis gerechnet (overrun_estimate_base_eur_kw = 7.500) mit Rest-Overrun-Anteilen 0,48/0,50/0,00 - damit ist die Abbildung 'gezogener CAPEX -> effektiver CAPEX' monoton und die Doppelzaehlung an den unteren Ankern beseitigt.
- v0.2c/4: Geschlossene CCS-Massenbilanz - abgeschiedene Menge und Restemission werden aus EINEM Brennstoffeintrag gebildet (upstream_share_of_lifecycle); captured + residual = Eintrag gilt exakt, auch unter Ziehung von Wirkungsgrad und Abscheiderate.
---
## 3 · Szenarien im Vergleich
System-LSCOE in EUR/MWh. Spalte *deterministisch* = Punktwert mit mittleren Parametern. Spalte *P50 [P5–P95]* = Median und 90-%-Band aus 1.000 Ziehungen der Konfiguration `base` (WACC fest 5 %, CO2 fest 75 EUR/t, ohne Kostenueberschreitung).
| Szenario | Bedarf TWh | determin. | P50 [P5–P95] | Mt CO2/a | davon abgeschieden | vergleichbar |
|:---|---:|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | 520 | 180,8 | 182,6 [174,3–191,6] | 136,0 | 0,0 | nein |
| GES · Kostenminimum | 950 | 159,0 | 164,9 [154,3–185,9] | 27,9 | 0,0 | ja |
| GES · Kostenminimum (Gas mit CCS) | 950 | 169,6 | 175,9 [164,1–197,0] | 8,3 | 23,9 | ja |
| GES · 80 % EE + Gas | 950 | 156,8 | 158,9 [147,7–171,4] | 106,5 | 0,0 | ja |
| GES · 80 % EE + Gas mit CCS | 950 | 185,0 | 188,6 [171,8–205,6] | 31,7 | 91,2 | ja |
| GES · 80 % EE + H₂ | 950 | 199,5 | 199,5 [189,2–210,5] | 4,8 | 0,0 | ja |
| GES · 100 % Erneuerbare | 950 | 245,2 | 244,7 [227,6–263,0] | 1,3 | 0,0 | ja |
*Hinweis:* `Ist 2025 (Referenzsystem)` ist ein Anker, kein Zielszenario — es ist mit den Zukunftsszenarien nicht rangfaehig (anderer Bedarf, andere Kostenabgrenzung).
### Kostenkomponenten der Zielszenarien (EUR/MWh, deterministisch)
| Szenario | battery | coal band | electrolyser | gas backup | h2 storage | h2 turbine | netz | nuclear | pv | wind offshore | wind onshore |
|:---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
| Ist 2025 (Referenzsystem) | 3,2 | 11,0 | — | 43,1 | — | — | 93,0 | — | 10,2 | 5,0 | 15,3 |
| GES · Kostenminimum | — | — | — | 15,5 | — | — | 29,9 | 99,5 | 2,6 | 5,0 | 6,6 |
| GES · Kostenminimum (Gas mit CCS) | — | — | — | 26,1 | — | — | 29,9 | 99,5 | 2,6 | 5,0 | 6,6 |
| GES · 80 % EE + Gas | 3,5 | — | — | 47,7 | — | — | 36,6 | — | 12,7 | 24,3 | 31,9 |
| GES · 80 % EE + Gas mit CCS | 3,5 | — | — | 75,8 | — | — | 36,6 | — | 12,7 | 24,3 | 31,9 |
| GES · 80 % EE + H₂ | 3,6 | — | 24,4 | 4,5 | 47,5 | 11,8 | 38,4 | — | 12,8 | 24,4 | 32,1 |
| GES · 100 % Erneuerbare | 5,3 | — | 38,9 | 3,7 | 20,1 | 13,3 | 40,0 | — | 22,8 | 43,7 | 57,4 |
### Systemkennzahlen der Szenarien
| Szenario | Gas-Backup TWh/a | Gas-Spitzenlast GW | Abregelung TWh/a | ungedeckt TWh/a |
|:---|---:|---:|---:|---:|
| Ist 2025 (Referenzsystem) | 148,1 | 58,0 | 6,2 | 0,00 |
| GES · Kostenminimum | 69,2 | 53,9 | 64,7 | 0,00 |
| GES · Kostenminimum (Gas mit CCS) | 69,2 | 53,9 | 64,7 | 0,00 |
| GES · 80 % EE + Gas | 264,4 | 137,0 | 140,9 | 0,00 |
| GES · 80 % EE + Gas mit CCS | 264,4 | 137,0 | 140,9 | 0,00 |
| GES · 80 % EE + H₂ | 11,9 | 20,0 | 12,1 | 4,58 |
| GES · 100 % Erneuerbare | 3,2 | 20,0 | 377,6 | 1,29 |
---
## 4 · CO2-Preis als Kipppunkt
- Deterministischer Kipppunkt: **101,8 EUR/t**
- Ueber gepaarte Ziehungen (Median-Delta = 0): **152 EUR/t**
- ETS-1-Marktpreis: 74 EUR/t · Modellwert: 75 EUR/t
- Konfidenz: B
Mit Abscheidung auf beiden Seiten existiert kein Kipppunkt: Der Kernkraft-Pfad liegt bei jedem CO2-Preis vorn (Delta -13,6 EUR/MWh bei 0 EUR/t, -62,9 bei 2.000 EUR/t).
*Methode:* Szenariensatz mittel, WACC 5 %, Netzvariante mid, Uebertragungsnetz-Sockelquote 0,40; variiert wird ausschliesslich der CO2-Preis. Deterministisch per Bisektion, probabilistisch als Median-Delta = 0 ueber 1.000 gepaarte Ziehungen.
### System-LSCOE je CO2-Preisniveau (EUR/MWh)
| CO2 EUR/t | Niveau | Ist 2025 (Referenzsystem) | GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | GES · 100 % Erneuerbare |
|---:|:---|---:|---:|---:|---:|---:|---:|---:|
| 0 | kein CO2-Preis | 161,2 | 156,8 | 168,9 | 148,4 | 182,5 | 199,1 | 245,1 |
| 75 | Modellwert (ETS-1-Marktniveau) | 180,8 | 159,0 | 169,6 | 156,8 | 185,0 | 199,5 | 245,2 |
| 350 | UBA-Klimakostensatz MK 3.2 (1 % Diskontierung) | 252,8 | 167,1 | 172,0 | 187,7 | 194,1 | 200,9 | 245,5 |
| 990 | UBA-Klimakostensatz MK 4.0 (Zentralwert) | 420,2 | 185,9 | 177,6 | 259,4 | 215,5 | 204,1 | 246,4 |
---
## 5 · Rangwahrscheinlichkeiten
Aus den gepaarten Ziehungen: in wie vielen der 1.000 Zukuenfte ist Szenario A guenstiger als B. `entschieden` bedeutet, dass die Wahrscheinlichkeit die selbstgesetzte Schwelle von 95 % ueberschreitet — alles darunter ist ein offener Ausgang, kein Sieg.
### Konfiguration `base` — WACC fest (5 %), CO2 fest (75 EUR/t), ohne Kostenueberschreitung
| A | B | P(A guenstiger) | P(B guenstiger) | Median A−B | P5 … P95 (A−B) | entschieden |
|:---|:---|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | GES · Kostenminimum | 8,5 % | 91,5 % | 17,3 | -3,6 … 29,8 | nein |
| Ist 2025 (Referenzsystem) | GES · Kostenminimum (Gas mit CCS) | 28,0 % | 72,0 % | 6,3 | -14,3 … 18,6 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas | 0,0 % | 100,0 % | 23,4 | 17,7 … 28,6 | ja |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas mit CCS | 81,0 % | 19,0 % | -5,9 | -16,5 … 4,0 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + H₂ | 99,0 % | 1,0 % | -16,9 | -28,0 … -5,4 | ja |
| Ist 2025 (Referenzsystem) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -62,6 | -78,1 … -44,9 | ja |
| GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | 100,0 % | 0,0 % | -11,0 | -13,9 … -8,1 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas | 25,7 % | 74,3 % | 6,4 | -8,5 … 27,7 | nein |
| GES · Kostenminimum | GES · 80 % EE + Gas mit CCS | 94,3 % | 5,7 % | -22,7 | -40,9 … 1,0 | nein |
| GES · Kostenminimum | GES · 80 % EE + H₂ | 99,6 % | 0,4 % | -33,7 | -48,9 … -12,7 | ja |
| GES · Kostenminimum | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -78,2 | -99,2 … -55,2 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | 2,3 % | 97,7 % | 17,4 | 2,6 … 37,8 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas mit CCS | 82,2 % | 17,8 % | -11,7 | -28,3 … 10,4 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + H₂ | 95,8 % | 4,2 % | -22,4 | -39,3 … -1,7 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -66,9 | -88,8 … -44,7 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -29,2 | -37,0 … -21,8 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -40,4 | -50,4 … -29,5 | ja |
| GES · 80 % EE + Gas | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -85,7 | -99,2 … -70,9 | ja |
| GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | 87,4 % | 12,6 % | -10,9 | -26,8 … 4,5 | nein |
| GES · 80 % EE + Gas mit CCS | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -56,6 | -74,3 … -38,1 | ja |
| GES · 80 % EE + H₂ | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -45,3 | -52,5 … -37,9 | ja |
### Konfiguration `wacc` — WACC unsicher (Dreieck 3/5/9 %), CO2 fest
| A | B | P(A guenstiger) | P(B guenstiger) | Median A−B | P5 … P95 (A−B) | entschieden |
|:---|:---|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | GES · Kostenminimum | 37,5 % | 62,5 % | 8,3 | -35,1 … 38,2 | nein |
| Ist 2025 (Referenzsystem) | GES · Kostenminimum (Gas mit CCS) | 54,7 % | 45,3 % | -3,6 | -48,6 … 27,7 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas | 11,0 % | 89,0 % | 18,2 | -5,3 … 35,3 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas mit CCS | 78,8 % | 21,2 % | -12,3 | -44,6 … 10,6 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + H₂ | 95,6 % | 4,4 % | -22,3 | -52,2 … -0,3 | ja |
| Ist 2025 (Referenzsystem) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -71,5 | -117,0 … -36,9 | ja |
| GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | 100,0 % | 0,0 % | -11,5 | -15,9 … -8,2 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas | 22,2 % | 77,8 % | 10,0 | -8,0 … 38,3 | nein |
| GES · Kostenminimum | GES · 80 % EE + Gas mit CCS | 89,3 % | 10,7 % | -20,9 | -40,2 … 5,7 | nein |
| GES · Kostenminimum | GES · 80 % EE + H₂ | 96,7 % | 3,3 % | -31,4 | -47,8 … -3,0 | ja |
| GES · Kostenminimum | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -79,3 | -102,6 … -53,6 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | 2,1 % | 97,9 % | 21,6 | 2,7 … 50,7 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas mit CCS | 75,7 % | 24,3 % | -9,3 | -27,8 … 18,2 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + H₂ | 88,4 % | 11,6 % | -19,8 | -37,9 … 10,0 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -67,3 | -90,7 … -40,6 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -30,7 | -41,9 … -22,2 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -40,6 | -52,0 … -29,2 | ja |
| GES · 80 % EE + Gas | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -89,4 | -115,3 … -69,5 | ja |
| GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | 82,5 % | 17,5 % | -10,0 | -26,1 … 8,2 | nein |
| GES · 80 % EE + Gas mit CCS | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -59,0 | -82,8 … -37,7 | ja |
| GES · 80 % EE + H₂ | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -48,9 | -66,4 … -35,7 | ja |
### Konfiguration `co2` — CO2-Preis unsicher (Dreieck 0/75/400 EUR/t), WACC fest
| A | B | P(A guenstiger) | P(B guenstiger) | Median A−B | P5 … P95 (A−B) | entschieden |
|:---|:---|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | GES · Kostenminimum | 4,8 % | 95,2 % | 33,4 | 0,4 … 73,8 | ja |
| Ist 2025 (Referenzsystem) | GES · Kostenminimum (Gas mit CCS) | 13,4 % | 86,6 % | 23,7 | -10,8 … 67,6 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas | 0,0 % | 100,0 % | 33,6 | 16,7 … 59,2 | ja |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas mit CCS | 32,9 % | 67,1 % | 10,7 | -17,4 … 49,3 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + H₂ | 47,4 % | 52,6 % | 1,4 | -29,4 … 44,7 | nein |
| Ist 2025 (Referenzsystem) | GES · 100 % Erneuerbare | 93,4 % | 6,6 % | -43,2 | -78,0 … 3,6 | nein |
| GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | 100,0 % | 0,0 % | -9,4 | -13,6 … -5,1 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas | 50,9 % | 49,1 % | -0,6 | -20,0 … 23,8 | nein |
| GES · Kostenminimum | GES · 80 % EE + Gas mit CCS | 94,8 % | 5,2 % | -23,8 | -42,5 … 0,8 | nein |
| GES · Kostenminimum | GES · 80 % EE + H₂ | 99,3 % | 0,7 % | -32,5 | -48,3 … -9,0 | ja |
| GES · Kostenminimum | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -76,9 | -99,1 … -51,1 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | 24,0 % | 76,0 % | 9,0 | -12,9 … 34,1 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas mit CCS | 86,3 % | 13,7 % | -14,5 | -31,8 … 8,7 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + H₂ | 94,3 % | 5,7 % | -23,1 | -39,6 … 0,7 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -67,8 | -89,4 … -41,3 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | 99,8 % | 0,2 % | -23,6 | -36,6 … -8,2 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + H₂ | 99,5 % | 0,5 % | -32,3 | -48,9 … -11,5 | ja |
| GES · 80 % EE + Gas | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -77,6 | -97,4 … -53,8 | ja |
| GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | 79,5 % | 20,5 % | -8,7 | -24,2 … 9,2 | nein |
| GES · 80 % EE + Gas mit CCS | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -53,9 | -72,2 … -32,2 | ja |
| GES · 80 % EE + H₂ | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -44,7 | -53,1 … -38,2 | ja |
### Konfiguration `wacc_co2` — WACC und CO2-Preis unsicher
| A | B | P(A guenstiger) | P(B guenstiger) | Median A−B | P5 … P95 (A−B) | entschieden |
|:---|:---|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | GES · Kostenminimum | 20,1 % | 79,9 % | 23,7 | -20,3 … 74,9 | nein |
| Ist 2025 (Referenzsystem) | GES · Kostenminimum (Gas mit CCS) | 33,0 % | 67,0 % | 13,0 | -33,6 … 68,1 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas | 3,1 % | 96,9 % | 28,3 | 2,9 … 59,4 | ja |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas mit CCS | 44,9 % | 55,1 % | 2,9 | -33,7 … 46,8 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + H₂ | 58,6 % | 41,4 % | -6,4 | -42,6 … 43,6 | nein |
| Ist 2025 (Referenzsystem) | GES · 100 % Erneuerbare | 94,0 % | 6,0 % | -54,0 | -103,1 … 1,6 | nein |
| GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | 100,0 % | 0,0 % | -10,0 | -14,7 … -5,3 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas | 40,1 % | 59,9 % | 3,9 | -19,5 … 31,4 | nein |
| GES · Kostenminimum | GES · 80 % EE + Gas mit CCS | 91,0 % | 9,0 % | -21,0 | -41,8 … 6,6 | nein |
| GES · Kostenminimum | GES · 80 % EE + H₂ | 96,8 % | 3,2 % | -29,7 | -47,1 … -5,2 | ja |
| GES · Kostenminimum | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -77,8 | -101,3 … -51,7 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | 17,1 % | 82,9 % | 14,2 | -12,5 … 42,9 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas mit CCS | 78,1 % | 21,9 % | -11,2 | -30,8 … 15,3 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + H₂ | 88,9 % | 11,1 % | -19,3 | -38,2 … 6,3 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -67,7 | -91,1 … -42,2 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | 99,9 % | 0,1 % | -25,4 | -38,9 … -9,2 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + H₂ | 99,6 % | 0,4 % | -33,8 | -50,2 … -12,4 | ja |
| GES · 80 % EE + Gas | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -82,4 | -108,0 … -55,6 | ja |
| GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | 76,1 % | 23,9 % | -8,6 | -25,8 … 10,0 | nein |
| GES · 80 % EE + Gas mit CCS | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -56,7 | -80,6 … -34,7 | ja |
| GES · 80 % EE + H₂ | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -48,7 | -65,5 … -35,0 | ja |
### Konfiguration `overrun` — WACC fest, CO2 fest, mit empirischer Kostenueberschreitung
| A | B | P(A guenstiger) | P(B guenstiger) | Median A−B | P5 … P95 (A−B) | entschieden |
|:---|:---|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | GES · Kostenminimum | 60,3 % | 39,7 % | -1,9 | -15,8 … 12,5 | nein |
| Ist 2025 (Referenzsystem) | GES · Kostenminimum (Gas mit CCS) | 93,6 % | 6,4 % | -14,1 | -27,8 … 1,1 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas | 0,0 % | 100,0 % | 16,3 | 9,3 … 22,4 | ja |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas mit CCS | 99,0 % | 1,0 % | -15,5 | -27,5 … -4,7 | ja |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -21,9 | -34,2 … -9,6 | ja |
| Ist 2025 (Referenzsystem) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -71,0 | -90,0 … -52,6 | ja |
| GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | 100,0 % | 0,0 % | -11,9 | -15,5 … -8,8 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas | 3,2 % | 96,8 % | 18,2 | 2,2 … 33,8 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas mit CCS | 86,8 % | 13,2 % | -13,5 | -33,6 … 6,1 | nein |
| GES · Kostenminimum | GES · 80 % EE + H₂ | 98,2 % | 1,8 % | -19,5 | -35,6 … -4,7 | ja |
| GES · Kostenminimum | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -68,8 | -89,9 … -49,6 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | 0,1 % | 99,9 % | 30,4 | 14,7 … 45,3 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas mit CCS | 56,5 % | 43,5 % | -1,6 | -19,3 … 16,3 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + H₂ | 77,9 % | 22,1 % | -7,5 | -24,3 … 8,1 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -56,8 | -78,5 … -36,9 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -31,7 | -40,7 … -23,6 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -38,1 | -49,8 … -26,9 | ja |
| GES · 80 % EE + Gas | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -87,7 | -103,2 … -71,8 | ja |
| GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | 73,4 % | 26,6 % | -6,4 | -23,2 … 11,2 | nein |
| GES · 80 % EE + Gas mit CCS | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -55,8 | -76,2 … -34,8 | ja |
| GES · 80 % EE + H₂ | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -49,2 | -57,3 … -41,4 | ja |
### Konfiguration `wacc_overrun` — WACC unsicher, mit empirischer Kostenueberschreitung
| A | B | P(A guenstiger) | P(B guenstiger) | Median A−B | P5 … P95 (A−B) | entschieden |
|:---|:---|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | GES · Kostenminimum | 65,7 % | 34,3 % | -12,2 | -61,2 … 21,7 | nein |
| Ist 2025 (Referenzsystem) | GES · Kostenminimum (Gas mit CCS) | 85,7 % | 14,3 % | -24,7 | -75,2 … 11,1 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas | 23,7 % | 76,3 % | 10,1 | -14,6 … 28,2 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas mit CCS | 94,6 % | 5,4 % | -23,7 | -56,6 … 0,4 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + H₂ | 99,0 % | 1,0 % | -28,2 | -57,8 … -6,6 | ja |
| Ist 2025 (Referenzsystem) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -81,6 | -130,1 … -47,7 | ja |
| GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | 100,0 % | 0,0 % | -12,6 | -17,2 … -9,1 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas | 5,1 % | 94,9 % | 22,3 | -0,1 … 51,1 | nein |
| GES · Kostenminimum | GES · 80 % EE + Gas mit CCS | 77,8 % | 22,2 % | -10,9 | -33,5 … 17,7 | nein |
| GES · Kostenminimum | GES · 80 % EE + H₂ | 85,5 % | 14,5 % | -16,1 | -37,5 … 12,0 | nein |
| GES · Kostenminimum | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -69,9 | -94,3 … -45,9 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | 0,2 % | 99,8 % | 35,0 | 11,8 … 65,0 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas mit CCS | 45,6 % | 54,4 % | 1,7 | -20,3 … 30,0 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + H₂ | 59,6 % | 40,4 % | -3,4 | -25,7 … 25,8 | nein |
| GES · Kostenminimum (Gas mit CCS) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -57,4 | -82,6 … -32,3 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -33,4 | -45,0 … -24,4 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -38,6 | -50,7 … -27,9 | ja |
| GES · 80 % EE + Gas | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -92,1 | -118,5 … -72,7 | ja |
| GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | 68,6 % | 31,4 % | -4,7 | -22,6 … 12,5 | nein |
| GES · 80 % EE + Gas mit CCS | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -58,6 | -84,8 … -37,2 | ja |
| GES · 80 % EE + H₂ | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -53,8 | -72,7 … -40,3 | ja |
### Konfiguration `asia` — Kontrast: Kernkraft-CAPEX aus dem Cluster Asien/Golf (1.870/3.150/4.950 EUR/kW, Bauzeit 8 a), WACC fest
| A | B | P(A guenstiger) | P(B guenstiger) | Median A−B | P5 … P95 (A−B) | entschieden |
|:---|:---|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | GES · Kostenminimum | 0,0 % | 100,0 % | 67,6 | 56,9 … 77,1 | ja |
| Ist 2025 (Referenzsystem) | GES · Kostenminimum (Gas mit CCS) | 0,0 % | 100,0 % | 56,6 | 45,8 … 66,6 | ja |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas | 0,0 % | 100,0 % | 23,4 | 17,5 … 28,7 | ja |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas mit CCS | 81,1 % | 18,9 % | -5,6 | -16,3 … 4,6 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + H₂ | 99,0 % | 1,0 % | -17,0 | -28,8 … -5,6 | ja |
| Ist 2025 (Referenzsystem) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -62,3 | -80,2 … -45,6 | ja |
| GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | 100,0 % | 0,0 % | -10,8 | -14,0 … -8,0 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas | 100,0 % | 0,0 % | -44,4 | -55,8 … -31,5 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -73,6 | -88,1 … -57,3 | ja |
| GES · Kostenminimum | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -84,1 | -97,1 … -71,0 | ja |
| GES · Kostenminimum | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -129,4 | -148,5 … -111,2 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | 100,0 % | 0,0 % | -33,6 | -44,7 … -20,6 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -62,9 | -75,6 … -47,9 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -73,2 | -86,9 … -59,5 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -118,7 | -138,7 … -99,4 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -28,8 | -36,9 … -21,7 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -40,2 | -50,9 … -28,4 | ja |
| GES · 80 % EE + Gas | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -85,4 | -100,7 … -71,0 | ja |
| GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | 86,3 % | 13,7 % | -11,0 | -27,7 … 5,4 | nein |
| GES · 80 % EE + Gas mit CCS | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -56,7 | -76,9 … -37,0 | ja |
| GES · 80 % EE + H₂ | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -45,5 | -53,0 … -38,3 | ja |
### Konfiguration `asia_wacc` — Kontrast Asien/Golf mit unsicherem WACC (Dreieck 3/5/9 %)
| A | B | P(A guenstiger) | P(B guenstiger) | Median A−B | P5 … P95 (A−B) | entschieden |
|:---|:---|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | GES · Kostenminimum | 0,0 % | 100,0 % | 63,0 | 42,1 … 78,2 | ja |
| Ist 2025 (Referenzsystem) | GES · Kostenminimum (Gas mit CCS) | 0,0 % | 100,0 % | 51,7 | 29,0 … 67,8 | ja |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas | 10,6 % | 89,4 % | 18,0 | -6,0 … 35,1 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + Gas mit CCS | 79,7 % | 20,3 % | -12,6 | -42,1 … 9,8 | nein |
| Ist 2025 (Referenzsystem) | GES · 80 % EE + H₂ | 96,5 % | 3,5 % | -22,3 | -50,7 … -1,4 | ja |
| Ist 2025 (Referenzsystem) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -71,2 | -117,8 … -37,7 | ja |
| GES · Kostenminimum | GES · Kostenminimum (Gas mit CCS) | 100,0 % | 0,0 % | -11,5 | -15,4 … -8,2 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas | 100,0 % | 0,0 % | -44,9 | -59,8 … -31,9 | ja |
| GES · Kostenminimum | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -76,1 | -97,1 … -57,8 | ja |
| GES · Kostenminimum | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -85,4 | -103,1 … -72,0 | ja |
| GES · Kostenminimum | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -134,4 | -166,4 … -108,9 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas | 100,0 % | 0,0 % | -33,5 | -47,3 … -21,2 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -64,2 | -83,0 … -48,5 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -73,9 | -91,4 … -60,1 | ja |
| GES · Kostenminimum (Gas mit CCS) | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -123,2 | -153,9 … -98,2 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + Gas mit CCS | 100,0 % | 0,0 % | -30,6 | -40,8 … -22,0 | ja |
| GES · 80 % EE + Gas | GES · 80 % EE + H₂ | 100,0 % | 0,0 % | -40,6 | -52,1 … -30,1 | ja |
| GES · 80 % EE + Gas | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -89,5 | -114,1 … -70,4 | ja |
| GES · 80 % EE + Gas mit CCS | GES · 80 % EE + H₂ | 84,4 % | 15,6 % | -9,9 | -26,3 … 6,7 | nein |
| GES · 80 % EE + Gas mit CCS | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -58,7 | -83,2 … -38,7 | ja |
| GES · 80 % EE + H₂ | GES · 100 % Erneuerbare | 100,0 % | 0,0 % | -48,7 | -67,1 … -35,4 | ja |
---
## 6 · Limitationen und Datenluecken
### Modell-Limitationen
- **[hoch] scenarios_not_emission_equivalent** — Die verglichenen Szenarien haben sehr unterschiedliche Restemissionen (1 bis ueber 100 Mt CO2/a). Ein Kostenvergleich in EUR/MWh ist nur unter gleicher Emissionsnebenbedingung eine Aussage ueber Technologien. Seit v0.2b gibt es dafuer die CCS-Varianten - die Szenarien OHNE CCS bleiben untereinander nicht emissionsaequivalent. *(betrifft: alle Szenarien)*
- **[hoch] ccs_storage_availability** — Deutschland hat keine in Betrieb befindliche CO2-Speicherstaette. Die CCS-Varianten unterstellen Export in norwegische/niederlaendische Offshore-Speicher samt Logistik, Genehmigungen und Akzeptanz. Modelliert ist davon NUR der Kostensatz je Tonne - keine Kapazitaetsgrenze, keine Hochlaufkurve, kein Verfuegbarkeitsrisiko. Die jaehrlich einzulagernde Menge steht als `emissions.captured_mt_co2_a` im Ergebnis. *(betrifft: kostenminimum_ccs, ee80_gas_ccs)*
- **[mittel] ccs_cost_band_optimistic** — Der CCS-Vollkettensatz 50/80/100 EUR/t ist die im Repository belegte Spanne. Eine Recherche (2026-08-19, Clean Air Task Force / Carbon Management Europe) nennt fuer europaeische Anlagen mit den derzeit geplanten Speichern rund 70-250 EUR/t. Das Modellband liegt am unteren Rand und beguenstigt den CCS-Pfad. *(betrifft: kostenminimum_ccs, ee80_gas_ccs)*
- **[hoch] ccs_on_full_backup_fleet** — Die CCS-Varianten ruesten den GESAMTEN Backup-Park aus, auch die Stunden mit sehr wenigen Volllaststunden. Weil der CAPEX-Block dabei rund verdoppelt wird, die Anlage aber nur 1.300-1.900 h im Jahr laeuft, faellt der Kapitalanteil je abgeschiedener Tonne sehr hoch aus. Ein real optimiertes System wuerde CCS nur an den hochausgelasteten Bloecken bauen und die Spitzenlast unabgeschieden fahren. Die hier ausgewiesenen Vermeidungskosten sind deshalb eine OBERGRENZE. *(betrifft: kostenminimum_ccs, ee80_gas_ccs)*
- **[mittel] ccs_residual_is_lifecycle** — Die Restemission von Gas+CCS bleibt ein LEBENSZYKLUS-Wert: Seit v0.2c wird sie aus der Massenbilanz gerechnet (Brennstoffeintrag minus abgeschiedene Verbrennungsemissionen), der Eintrag selbst ist aber weiterhin der Lebenszyklus-Faktor inklusive Vorkette. Fuer eine reine ETS-Bepreisung ist der Wert eher zu hoch - dieselbe Richtung wie beim GuD-Proxy, also gegen den CCS-Pfad. Der Vorkettenanteil (upstream_share_of_lifecycle) ist gegen die belegte Restemission von 120 g/kWh KALIBRIERT, nicht eigenstaendig belegt. *(betrifft: kostenminimum_ccs, ee80_gas_ccs)*
- **[hoch] grid_transmission_socket_assumption** — Die mixunabhaengige Sockelquote des Uebertragungsnetzes (v0.2c: 0,40; Sensitivitaet 0,20-0,60) ist eine SETZUNG. Weder NEP 2037/2045 V2025 noch die IMK-Studie teilen die 328 (bzw. 365-392) Mrd. EUR nach Treibern auf - eine belastbare Quote existiert nicht. Die Setzung bewegt den Abstand zwischen dem Kernkraft- und dem gasgestuetzten Pfad unmittelbar; das Ergebnis weist die Differenz zum sockellosen Lauf (v0.2b) je Szenario als detail.netz.socket_effect_eur_mwh aus. *(betrifft: alle Zukunftsszenarien, Kernkraft-Pfad am staerksten)*
- **[mittel] overrun_estimate_base_assumption** — Der empirische Ueberschreitungsfaktor wird seit v0.2c als absoluter Betrag auf EINER Schaetzbasis gerechnet (Kernkraft 7.500 EUR/kW) und nur auf den Rest-Anteil der Eskalation gelegt (0,48/0,50/0,00). Das beseitigt die Nicht-Monotonie und die Doppelzaehlung an den unteren Ankern, ist aber eine Modellstruktur: Die Rest-Anteile sind aus den Eskalationsangaben des eigenen Datensatzes abgeleitet (EPR2 +40 %, Sizewell C +90 %, Lubiatowo Planzahl), der mid-Wert zusaetzlich auf 0,50 abgerundet, damit die Abbildung ueber den gesamten Faktor-Support monoton bleibt. *(betrifft: Konfigurationen mit Kostenueberschreitung)*
- **[mittel] emission_factor_proxy** — Der Emissionsfaktor fuer Gas (0,403 t/MWh_el) und Kohle (0,751 t/MWh_el) ist die UNECE-Lebenszyklus-Untergrenze, kein direkter Verbrennungsfaktor. Fuer die ETS-Bepreisung ueberschaetzt das die CO2-Kosten um rund 10-20 %. *(betrifft: CO2-Kosten und Mt-Ausweis)*
- **[hoch] grid_opex_missing** — Netzbetrieb, Instandhaltung, Verluste und Redispatch sind nicht enthalten - nur die Investitionsannuitaet. Der Netzblock der Zukunftsszenarien ist eine Untergrenze. *(betrifft: alle Zukunftsszenarien)*
- **[hoch] overrun_asymmetry** — Der empirische Ueberschreitungsfaktor ist fuer Batterie, Elektrolyse, H2-Speicher und H2-Turbine NICHT gemessen (Faktor 1,00 = Datenluecke). Das Ueberschreitungs-Szenario stresst deshalb die Kernkraft- und Netzseite staerker als die Speicher-/H2-Seite. *(betrifft: Konfigurationen mit Kostenueberschreitung)*
- **[mittel] grid_allocation_assumption** — Die Aufteilung 328 Mrd. (Uebertragung) / 323 Mrd. (Verteilung) ist quellenbelegt, die ZUORDNUNG der Treiber (Transport vs. Elektrifizierung) ist eine begruendete Modellannahme. Keine raeumliche Netzsimulation, keine ueberproportionale Kostenkurve. *(betrifft: alle Szenarien)*
- **[mittel] gas_price_transfer** — Der Erdgaspreis (20/35/60 EUR/MWh_th) ist eine Marktspanne von August 2026. Die Uebertragbarkeit auf ein Zieljahr 2045 ist nicht belegt (Konfidenz C). *(betrifft: alle Szenarien mit Gas-Backup)*
- **[hoch] h2_initial_fill_free** — Der Saisonspeicher startet in den H2-Presets gefuellt; die Stromkosten dieser Anfangsfuellung liegen ausserhalb des abgedeckten Halbjahres und sind NICHT enthalten. Die H2-Pfade sind insoweit eine Untergrenze - das ist die Gegenrichtung zur Gas-Asymmetrie und bleibt auch nach M2 bestehen. *(betrifft: ee80_h2, ee100)*
- **[mittel] nuclear_base_range_is_western** — Die Kernkraft-Basisverteilung (7.500/12.000/17.500 EUR/kW) enthaelt bewusst kein asiatisches oder Golf-Projekt - Begruendung in kosten_kernkraft.md 7.1 (Uebertragbarkeit). Der Cluster Asien/Golf (1.870-4.950 EUR/kW) ist real und belegt und wird seit v0.2b als EIGENE Monte-Carlo-Konfiguration ('asia', 'asia_wacc') gerechnet - nicht in die Basisspanne gemischt. *(betrifft: alle Szenarien mit Kernkraft)*
- **[hoch] half_year_profile** — Das Stundenprofil deckt nur Jul-Dez 2024 ab (4.416 von 8.784 h) und enthaelt den Sommerueberschuss nicht, aus dem Saisonspeicher befuellt werden. *(betrifft: alle Szenarien, H2-Pfade am staerksten)*
### Dokumentierte Datenluecken
- **gaspreis_erdgas** (`technologies.gas_*.params.fuel_eur_mwh_th`) · Status: GESCHLOSSEN in v0.2 (ausserhalb der Dossiers belegt) — Kein Erdgas-Brennstoffpreis in den Recherche-Dossiers. Seit v0.2 mit einer Marktspanne 20/35/60 EUR/MWh_th parametrisiert (TTF-Notierung, Recherche 2026-08-19, Konfidenz B; Uebertragbarkeit auf 2045 Konfidenz C). Die Nullsetzung war eine Luecke der Recherche, nicht der Welt.
- **netz_opex** (`system.grid (Betrieb, Instandhaltung, Verluste, Redispatch)`) — Fuer das Zielsystem 2045 existiert in keinem Dossier ein Netzbetriebskostensatz. Das Modell enthaelt ausschliesslich die Investitionsannuitaet - der Netzblock der Zukunftsszenarien ist damit eine Untergrenze. Belegt ist nur der Ist-Wert Engpassmanagement (2,776 Mrd. EUR 2024 bzw. 2,7-3,1 Mrd. EUR 2025).
- **ccs_nicht_modelliert** (`technologies.gas_ccs`) · Status: GESCHLOSSEN in v0.2b — Die gepruefte GES-Studie rechnet ihren Gas-Pfad mit CCS. Seit v0.2b existiert die Technologie gas_ccs (CAPEX-Aufschlag, Wirkungsgradverlust, Abscheiderate, Vollketten-Kostensatz je Tonne, Restemission mit CO2-Preis) und wird in den Presets kostenminimum_ccs und ee80_gas_ccs gerechnet. OFFEN BLEIBT die physische Verfuegbarkeit von Transport und Speicherung - siehe ccs_speicher_verfuegbarkeit.
- **ccs_speicher_verfuegbarkeit** (`technologies.gas_ccs.ccs_chain.storage_availability_de`) — Deutschland hat keine in Betrieb befindliche CO2-Speicherstaette. Der CCS-Pfad unterstellt Export in norwegische/niederlaendische Offshore-Speicher samt Logistik, Genehmigungen und Akzeptanz. Im Modell steckt davon nur der Kostensatz je Tonne - keine Kapazitaetsgrenze, keine Hochlaufkurve, kein Verfuegbarkeitsrisiko. SETZUNG (M), Konfidenz C.
- **ccs_kostenband_optimistisch** (`technologies.gas_ccs.params.ccs_cost_eur_t`) — Verwendet wird die im Repository belegte Spanne 50/80/100 EUR/t. Eine Recherche vom 2026-08-19 (Clean Air Task Force; Carbon Management Europe/ZEP) nennt fuer europaeische Anlagen mit den derzeit geplanten Speichern eine Vollkettenspanne von rund 70-250 EUR/t. Das Modellband liegt damit am unteren Rand und beguenstigt den CCS-Pfad.
- **overrun_ungemessen_speicher_h2** (`system.cost_overrun_factors.unmeasured_technologies`) — Batterie, Elektrolyse, H2-Speicher und H2-Turbine haben in Flyvbjerg/Sovacool keine Projektklasse und bleiben bei Faktor 1,00. Das ist eine Luecke, keine Messung - das Ueberschreitungs-Szenario ist deshalb asymmetrisch.
- **emissionsfaktor_direkt** (`technologies.gas_*.params.emission_factor_t_mwh`) — Kein direkter Verbrennungs-Emissionsfaktor in den Dossiers. Als Proxy dient die UNECE-Lebenszyklus-Untergrenze fuer GuD (403 g/kWh). Vor Veroeffentlichung ersetzen.
- **profile_partial** (`data/profiles_2024.json`) — Nur 4.416 von 8.784 Stunden (Jul-Dez 2024); Wind offshore, Wasserkraft und Biomasse fehlen komplett. Alle Dispatch-Ergebnisse sind H2-2024-basiert.
- **offshore_profil** (`technologies.wind_offshore.profile_series`) — Kein Offshore-Profil vorhanden; Uebergangsloesung mit Onshore-Profilform.
- **ges_technologie_split** (`ges_scenario_reconstruction`) — GES veroeffentlicht die Technologie-Aufteilung je Szenario nur als Grafik; der Mix-Test arbeitet daher mit einer rekonstruierten Aufteilung.
- **hydro_biomasse_band** (`technologies (Wasserkraft, Biomasse)`) — Keine Kostenparameter fuer Wasserkraft und Biomasse in den Dossiers; im Mix-Modell nur als optionales Band ohne Kostenansatz fuehrbar.
### Grenze der Quellenpruefung
Volltext-Abruf (WebFetch) war fuer praktisch alle Primaerquellen-Domains durch den Netzwerk-Egress blockiert. Alle Werte stammen aus Suchindex-Zusammenfassungen der genannten Quellen, nicht aus selbst gelesenem PDF-Volltext. Vor Veroeffentlichung am Original nachpruefen.
---
## 7 · Quellenverzeichnis
Konfidenzstufen: **A** mehrfach bestaetigt / institutionelle Primaerquelle · **B** einzelner Treffer, institutionelle Quelle · **C** Branchen-/Marktquelle oder Modellannahme mit schwacher Belegbasis · **M** Setzung/Modellannahme, nicht quellenbelegt.
| Nr. | Titel | Herausgeber | Datum | Konfidenz |
|---:|:---|:---|:---|:---:|
| 1 | [Netzentwicklungsplan Strom 2037 mit Ausblick 2045, Version 2025, 1. Entwurf](https://www.netzentwicklungsplan.de/sites/default/files/2025-12/NEP_2037_2045_V2025_1_Entwurf_0.pdf) | 50Hertz, Amprion, TenneT, TransnetBW | 2025-12 | A |
| 2 | [Bruttostromerzeugung in Deutschland nach Energietraegern (Datenblatt STRERZ) / Jahresauswertung Wintertagung](https://ag-energiebilanzen.de/wp-content/uploads/2025/02/STRERZ-Abgabe-2025-06.pdf) | AG Energiebilanzen e. V. | 2025-12-15 | B |
| 3 | [Comparing the Costs of Intermittent and Dispatchable Electricity Generating Technologies](https://www.aeaweb.org/articles?id=10.1257/aer.101.3.238) | American Economic Review 101(3), S. 238–241 (P. L. Joskow) | 2011-05 | A |
| 4 | [How Big Things Get Done (Megaprojekt-Datenbank, ~16.000 Projekte)](https://budgetoverrun.com/studies/flyvbjerg-megaproject-database) | B. Flyvbjerg / D. Gardner, Currency/Penguin | 2023 | A |
| 5 | [Monitoringbericht zur Energiewende (wiss. Zuarbeit EWI und BET Aachen)](https://www.bundeswirtschaftsministerium.de/Redaktion/DE/Publikationen/Energie/monitoringbericht-energiewende.html) | BMWE | 2025-09-15 | A |
| 6 | [Endlagerung — Statusinformationen Finnland, Frankreich, Deutschland](https://www.base.bund.de/de/endlager/endlager-ausland/finnland/finnland-endlager.html) | Bundesamt fuer die Sicherheit der nuklearen Entsorgung (BASE) | 2026 | A |
| 7 | [Grundsatzeinigung mit der Europaeischen Kommission ueber Eckpunkte der Kraftwerksstrategie (StromVKG)](https://www.bundeswirtschaftsministerium.de/Redaktion/DE/Pressemitteilungen/2026/01/20260115-grundsatzeinigung-mit-europaeischen-kommission-ueber-eckpunkte-der-kraftwerksstrategie.html) | Bundesministerium fuer Wirtschaft und Energie (BMWE) | 2026-01-15 | B |
| 8 | [Erneuerbare-Energien-Gesetz (EEG 2023), §§ 1 und 4 — Ausbauziele](https://www.umweltbundesamt.de/themen/klima-energie/erneuerbare-energien/erneuerbare-energien-gesetz) | Bundesministerium fuer Wirtschaft und Energie / UBA | 2023 | A |
| 9 | [Festlegung der Hoechstwerte 2026 fuer Wind an Land und Solar-Dachanlagen](https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilungen/DE/2025/20251216_Hoechstwerte.html) | Bundesnetzagentur | 2025-12-16 | B |
| 10 | [Ausschreibung Solaranlagen erstes Segment, Gebotstermin 1. Maerz 2026](https://www.bundesnetzagentur.de/DE/Fachthemen/ElektrizitaetundGas/Ausschreibungen/Solaranlagen1/BeendeteAusschreibungen/2026/01032026/start.html) | Bundesnetzagentur | 2026 | B |
| 11 | [Hohes Wettbewerbsniveau bei der Ausschreibung fuer Wind an Land zum 1. Mai 2026](https://www.bundesnetzagentur.de/1110006) | Bundesnetzagentur | 2026-06 | B |
| 12 | [Untersuchung zu Strompreisspitzen waehrend Dunkelflauten 2024 (Pressemitteilung)](https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilungen/DE/2025/20251021_Preisspitzen.html) | Bundesnetzagentur / Bundeskartellamt | 2025-10-21 | A |
| 13 | [Kostensituation der Windenergie an Land - Stand 2025](https://www.windguard.de/veroeffentlichungen.html?file=files%2Fcto_layout%2Fimg%2Funternehmen%2Fveroeffentlichungen%2F2025%2FKostensituation+der+Windenergie+an+Land+%E2%80%93+Stand+2025.pdf) | Deutsche WindGuard i.A. BMWK | 2025-10 | B |
| 14 | [Die Versicherungspflicht von Atomkraftwerken (WD 3 - 330/10)](https://www.bundestag.de/resource/blob/412752/5782d652a8e25945c65d84744d314b88/WD-3-330-10-pdf.pdf) | Deutscher Bundestag, Wissenschaftliche Dienste | 2010 | B |
| 15 | [Wasserstoffspeicherung in Salzkavernen kostet 0,66 bis 1,77 Euro pro Kilogramm (EWI-Analyse)](https://www.pv-magazine.de/2024/03/06/wasserstoffspeicherung-in-salzkavernen-kostet-066-bis-177-euro-pro-kilogramm/) | EWI / referiert in pv magazine Deutschland | 2024-03-06 | B |
| 16 | [Revisiting the Cost Escalation Curse of Nuclear Power: New Lessons from the French Experience](https://shs.hal.science/hal-00780566/) | Economics of Energy & Environmental Policy 4(2) (L. Escobar Rangel, F. Lévêque) | 2015-09 | B |
| 17 | [System LCOE: What are the costs of variable renewables?](https://www.sciencedirect.com/science/article/abs/pii/S0360544213009390) | Energy 63, S. 61–75 (F. Ueckerdt, L. Hirth, G. Luderer, O. Edenhofer) | 2013 | A |
| 18 | [Nuclear reactors' construction costs: The role of lead-time, standardization and technological progress](https://www.sciencedirect.com/science/article/abs/pii/S0301421515001214) | Energy Policy 82, S. 118–130 (M. Berthélemy, L. Escobar Rangel) | 2015-07 | B |
| 19 | [Beyond economies of scale: Learning from construction cost overrun risks and time delays in global energy infrastructure projects](https://www.sciencedirect.com/science/article/pii/S2214629625001380) | Energy Research & Social Science (Sovacool, Ryu) | 2025-03 | A |
| 20 | [Euratom Supply Agency — Annual Report 2024](https://euratom-supply.ec.europa.eu/) | Europaeische Kommission | 2025 | A |
| 21 | [Euro foreign exchange reference rates](https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html) | Europaeische Zentralbank | 2026-03-09 / laufend | B |
| 22 | [20 GW Gaskraftwerke bis 2030 - Was kostet die Erweiterung?](https://foes.de/publikationen/2025/2025-04_FOES_BUND_Kraftwerkskosten.pdf) | FOES i.A. BUND | 2025-04 | B |
| 23 | [Kurzanalyse Stromgestehungskosten und Volllaststunden flexibler Kraftwerke](https://www.ise.fraunhofer.de/content/dam/ise/de/documents/publications/studies/Kurzanalyse_flexibleKraftwerke.pdf) | Fraunhofer ISE (Kost, Sepulveda Schweiger, Thomsen) | 2024/2025 | B |
| 24 | [Stromerzeugung in Deutschland im Jahr 2025 (Jahresauswertung)](https://www.energy-charts.info/downloads/Stromerzeugung_2025.pdf) | Fraunhofer ISE / Energy-Charts (B. Burger) | 2026-01 | A |
| 25 | [Stromgestehungskosten Erneuerbare Energien](https://www.ise.fraunhofer.de/content/dam/ise/de/documents/publications/studies/DE2024_ISE_Studie_Stromgestehungskosten_Erneuerbare_Energien.pdf) | Fraunhofer-Institut fuer Solare Energiesysteme ISE | 2024-07 | B |
| 26 | [Der klimaneutrale Strommix der Zukunft — Eine Szenarioanalyse zu den Kosten des zukuenftigen deutschen Stromsystems](https://global-energy-solutions.org/wp-content/uploads/2026/05/DER-KLIMANEUTRALE-STROMMIX-DER-ZUKUNFT-veroeffentlicht-V1.1.pdf) | Global Energy Solutions e. V. | 2026-07 | C |
| 27 | [How long does it take to build a nuclear reactor?](https://hannahritchie.substack.com/p/nuclear-construction-time) | Hannah Ritchie (Sustainability by Numbers), auf Basis IAEA PRIS | 2023 | B |
| 28 | [Special Report on Solar PV Global Supply Chains](https://www.iea.org/reports/solar-pv-global-supply-chains/executive-summary) | IEA | 2022 | A |
| 29 | [Global Critical Minerals Outlook 2025](https://www.iea.org/reports/global-critical-minerals-outlook-2025) | IEA | 2025 | A |
| 30 | [Projected Costs of Generating Electricity - 2020 Edition](https://www.iea.org/reports/projected-costs-of-generating-electricity-2020) | IEA / OECD NEA | 2020-12 | B |
| 31 | [Netzinvestitionsbedarf bis 2045 (Uebertragungs- und Verteilnetz)](https://www.imk-boeckler.de/) | IMK / Hans-Boeckler-Stiftung | 2025 | B |
| 32 | [Climate Change 2023: Synthesis Report — Summary for Policymakers](https://www.ipcc.ch/report/ar6/syr/summary-for-policymakers/) | IPCC | 2023-03 | A |
| 33 | [Climate Change 2021: The Physical Science Basis — Summary for Policymakers](https://www.ipcc.ch/report/ar6/wg1/chapter/summary-for-policymakers/) | IPCC (WG1) | 2021-08 | A |
| 34 | [Renewable Power Generation Costs in 2024](https://www.irena.org/-/media/Files/IRENA/Agency/Publication/2025/Jul/IRENA_TEC_RPGC_in_2024_Summary_2025.pdf) | IRENA | 2025-07 | B |
| 35 | [Britisches Atomkraftwerk Hinkley Point C verzoegert sich weiter und wird teurer - Atomstrom kostet mindestens 15 Cent pro Kilowattstunde](https://www.iwr.de/news/britisches-atomkraftwerk-hinkley-point-c-verzoegert-sich-weiter-und-wird-teurer-atomstrom-kostet-mindestens-15-cent-pro-kilowattstunde-news39541) | IWR-Pressedienst | 2026-02-23 | B |
| 36 | [Fonds zur Finanzierung der kerntechnischen Entsorgung — Kennzahlen und Jahresergebnis 2025](https://www.kenfo.de/) | KENFO | 2026 | A |
| 37 | [Analysen und Statistiken zu Dunkelflauten in Deutschland](https://www.lbbw.de/artikel/research-studien-2025/dunkelflaute_ake25jccd8_d.html) | LBBW Research | 2025 | B |
| 38 | [Levelized Cost of Energy+ (LCOE+), Version 19.0](https://www.lazard.com/media/sdvdrvc5/lazards-lcoeplus_vf.pdf) | Lazard | 2026-07-13 | B |
| 39 | [Hinkley Point C's cost climbs to GBP35bn with confirmation Unit 1 will power up in 2030](https://www.newcivilengineer.com/latest/hinkley-point-cs-cost-climbs-to-35bn-with-confirmation-unit-1-will-power-up-in-2030-20-02-2026/) | New Civil Engineer | 2026-02-20 | B |
| 40 | [Stuendliche SMARD-Exportdaten Deutschland Jul-Dez 2024 (GitHub-Mirror, Notloesung)](https://github.com/hakimdalim/smard-data-extractor) | SMARD / Bundesnetzagentur, ueber github.com/hakimdalim/smard-data-extractor | 2024 | C |
| 41 | [Ausschreibungsergebnisse 2025](https://www.offshore-stiftung.de/de/Pressemitteilung-Ausschreibungsergebnisse-2025) | Stiftung Offshore-Windenergie | 2025 | B |
| 42 | [Carbon Neutrality in the UNECE Region — Integrated Life-cycle Assessment of Electricity Sources](https://unece.org/sed/documents/2021/10/reports/life-cycle-assessment-electricity-generation-options) | UNECE | 2022 | A |
| 43 | [Methodenkonvention 3.2 zur Ermittlung von Umweltkosten (CO2-Schattenpreise)](https://www.umweltbundesamt.de/publikationen/methodenkonvention-32-methodische-grundlagen) | Umweltbundesamt | 2020 | B |
| 44 | [Kurzstudie Dunkelflauten (Zeitreihenanalyse 2016-2025)](https://www.pv-magazine.de/2026/06/01/uniper-dunkelflauten-sind-regelmaessiger-bestandteil-des-deutschen-stromsystems/) | Uniper SE | 2026-06 | A |
### Anmerkungen zu einzelnen Quellen
- **Nr. 3 · Comparing the Costs of Intermittent and Dispatchable Electricity Generating Technologies** — Begruendet, warum LCOE-Punktwerte fluktuierende und disponible Erzeugung nicht vergleichbar machen — die methodische Referenz fuer den Schritt von LCOE zu Systemkosten. Bibliographische Angaben aus der Verlagsseite, kein Volltext gelesen.
- **Nr. 7 · Grundsatzeinigung mit der Europaeischen Kommission ueber Eckpunkte der Kraftwerksstrategie (StromVKG)** — Zeitschiene und Volumina der Kraftwerksausschreibungen; die Ausgestaltung des Kapazitaetsmechanismus ab 2031 ist darin ausdruecklich noch offen.
- **Nr. 15 · Wasserstoffspeicherung in Salzkavernen kostet 0,66 bis 1,77 Euro pro Kilogramm (EWI-Analyse)** — Originalstudie des EWI sollte noch direkt beschafft werden
- **Nr. 16 · Revisiting the Cost Escalation Curse of Nuclear Power: New Lessons from the French Experience** — Rechnet das franzoesische Programm mit den Daten des Cour-des-Comptes-Berichts nach und findet eine deutlich moderatere Eskalation als Grubler 2010; innerhalb gleicher Baugroesse und Bauart zeigt sich eine Lernkurve. Gegenposition zum „negativen Lernen“. Bibliographie aus Repositorien, kein Volltext gelesen.
- **Nr. 17 · System LCOE: What are the costs of variable renewables?** — Fuehrt die Kennzahl System-LCOE ein und zerlegt Integrationskosten in Profil-, Ausgleichs- und Netzkosten. Die LSCOE-Definition dieses Papiers ist eine engere Systemgrenze als dort — der Unterschied steht in Kapitel 3.
- **Nr. 18 · Nuclear reactors' construction costs: The role of lead-time, standardization and technological progress** — Oekonometrie der Baukosten in Frankreich und den USA: Standardisierung senkt Bauzeit und Kosten, Designwechsel erhoehen beides. Stuetzt die Lesart, dass die Eskalation an Programmorganisation haengt, nicht an der Technologie als solcher.
- **Nr. 26 · Der klimaneutrale Strommix der Zukunft — Eine Szenarioanalyse zu den Kosten des zukuenftigen deutschen Stromsystems** — Volltext-PDF in der Arbeitsumgebung nicht abrufbar (Egress-Policy). Alle Studienwerte stammen aus der Aufbereitung in docs/01 und aus Suchindex-Zusammenfassungen, nicht aus selbst gelesenem Volltext.
- **Nr. 30 · Projected Costs of Generating Electricity - 2020 Edition** — Domain in dieser Session blockiert; LCOE-Calculator unter https://www.oecd-nea.org/lcoe/
- **Nr. 40 · Stuendliche SMARD-Exportdaten Deutschland Jul-Dez 2024 (GitHub-Mirror, Notloesung)** — Primaerquellen (energy-charts, smard.de, OPSD) waren aus der Arbeitsumgebung per Egress-Policy nicht erreichbar.
- **Nr. 44 · Kurzstudie Dunkelflauten (Zeitreihenanalyse 2016-2025)** — Interessenlage: Uniper betreibt konventionelle Kraftwerke. 10-h-Schwelle statt DWD-48-h.
---
## Interaktive Fassung und weiterfuehrende Dateien
- Interaktives White Paper (Charts, Regler, Szenario-Vergleich): https://datenwgknowledgekitchen.com/whitepaper-strommix.html
- Visual Story zum selben Thema (erzaehlerisch): https://datenwgknowledgekitchen.com/strommix-story.html
- Markdown-Fassung der Story: https://datenwgknowledgekitchen.com/md/strommix-story.md
- Parametersatz des Modells: https://datenwgknowledgekitchen.com/strommix/data/model_params.json
- Monte-Carlo-Referenz: https://datenwgknowledgekitchen.com/strommix/data/monte_carlo_reference.json
- Redaktioneller Datensatz: https://datenwgknowledgekitchen.com/strommix/data/page_data.json
- Maschinenlesbarer Index der Kitchen: https://datenwgknowledgekitchen.com/llms.txt
==============================================================================
DOKUMENT: https://datenwgknowledgekitchen.com/md/strommix-story.md
==============================================================================
# Was kostet ein klimaneutrales Stromsystem?
> Visual Story: Eine Studie nennt 125 und 321 Euro je Megawattstunde. Woher kommen solche Zahlen — und wie belastbar sind sie? Eine nachgerechnete Spurensuche mit Bandbreiten statt Schlagzeilen.
- **Quelle:** https://datenwgknowledgekitchen.com/strommix-story.html
- **Markdown-Fassung:** https://datenwgknowledgekitchen.com/md/strommix-story.md
- **Autor:** Michael Tenner · Daten-WG Knowledge Kitchen
- **Stand der Daten:** 2026-08-19 (Git-Commit-Datum der Quelldaten)
- **Modellstand:** v0.2c
- **Status:** Entwurf. Jede Zahl traegt eine Konfidenzstufe — A/B/C bzw. M fuer Modellsetzung. Ohne die Konfidenzstufe ist eine Zahl aus diesem Dokument nicht zitierfaehig.
- **Zitierhinweis:** Michael Tenner, Daten-WG Knowledge Kitchen, https://datenwgknowledgekitchen.com/strommix-story.html — Abruf mit Datum angeben. Weiterverwendung mit Quellenangabe erwuenscht; Zahlen bitte mit Konfidenzstufe und Stand uebernehmen.
- **Erzeugt von:** `strommix/scripts/build_md_exports.py` (generierte Datei — nicht von Hand editieren)
- **Story-Version:** v0.3 (Entwurf)
- **Geprueft gegen:** research/kosten_kernkraft.md, research/kosten_ee_speicher.md, research/ist_zustand_de.md, research/risiken_co2.md, research/review_v09.md, data/model_params.json, data/monte_carlo_reference.json, scripts/model.py
---
## Worum es geht
Die Story nimmt eine oeffentlich diskutierte Studie zum deutschen Strommix und rechnet sie nach — Schritt fuer Schritt, mit offengelegten Annahmen. Sie ist die erzaehlerische Fassung des White Papers (https://datenwgknowledgekitchen.com/whitepaper-strommix.html); die Zahlen stammen aus demselben Modell.
### Ergebnis der Faktenpruefung
| Kategorie | Anzahl Aussagen |
|:---|---:|
| bestaetigt | 7 |
| korrigiert | 11 |
| verworfen | 4 |
| Setzung (Modellannahme) | 6 |
| unverifizierbar | 3 |
### Die Kernaussage in einem Absatz
> Die beiden vorderen Pfade liegen so eng beieinander, dass schon die Wahl der Kennzahl den Sieger wechselt: Im Punktwert kostet der gasgestützte 80-Prozent-Pfad 156,8 Euro je Megawattstunde und das kernkraftgestützte Kostenminimum 159,0 - von 1.000 durchgerechneten Zukünften gehen 257 an die Kernkraft und 743 an den Gas-Pfad. Entschieden ist damit nichts. Nur vergleicht dieser Beinahe-Gleichstand 28 gegen 107 Millionen Tonnen CO2 im Jahr. Verlangt man vom Gas-Pfad dieselbe Emissionsmenge - mit Abscheidung, so wie die geprüfte Studie ihren Gas-Pfad meint -, liegt das Kernkraft-Szenario in 943 von 1.000 Zukünften vorn; nach unserer eigenen Schwelle von 950 ist auch das formal kein entschiedener Vergleich, aber die Richtung dreht sich.
**Vorbehalt (Konfidenz B):** Profile PARTIAL (H2-2024, 4416 h, hochgerechnet). Seit v0.2c hat das Übertragungsnetz einen mixunabhängigen Sockel (Setzung 0,40, Sensitivität 0,20-0,60) - diese eine Setzung bewegt den Abstand zwischen dem Kernkraft- und dem gasgestützten Pfad über die ganze Breite von -2,3 bis +4,5 EUR/MWh. Weiterhin fehlen Netzbetrieb, Redispatch und Verluste; der Netzblock der Zukunftsszenarien bleibt eine Untergrenze. Import, Export und Lastmanagement sind nicht modelliert.
---
## Die Szenarien, um die es geht
System-LSCOE in EUR/MWh bei 75 EUR/t CO2, Modell v0.2c.
| Szenario | determin. | P50 [P5–P95] | Mt CO2/a | Gas-Backup TWh/a | Gas-Spitze GW | rangfaehig |
|:---|---:|---:|---:|---:|---:|:---:|
| Ist 2025 (Referenzsystem) | 180,8 | 183 [174–192] | 136,0 | 148,1 | 58,0 | nein |
| GES - Kostenminimum | 159,0 | 165 [154–186] | 27,9 | 69,2 | 53,9 | ja |
| GES - Kostenminimum (Gas mit CCS) | 169,6 | 176 [164–197] | 8,3 | 69,2 | 53,9 | ja |
| GES - 80 % EE + Gas | 156,8 | 159 [148–171] | 106,5 | 264,4 | 137,0 | ja |
| GES - 80 % EE + Gas mit CCS | 185,0 | 189 [172–206] | 31,7 | 264,4 | 137,0 | ja |
| GES - 80 % EE + H2 | 199,5 | 200 [189–210] | 4,8 | 11,9 | 20,0 | ja |
| GES - 100 % Erneuerbare | 245,2 | 245 [228–263] | 1,3 | 3,2 | 20,0 | ja |
*Der Ist-2025-Anker ist NICHT ranking-fähig: er trägt das heutige Netzentgelt statt der Netzinvestition bis 2045 und seine Bestandsbänder ohne Kapital- und Betriebskosten. Er ist ein Größenordnungs-Bezug, kein fünfter Platz.*
---
## Verworfen: Behauptungen, die die Pruefung nicht ueberstanden haben
- **** — Ungewichtetes Mittel über fünf Projekte mit unterschiedlichen Kostenabgrenzungen, Preisbasen, Baujahren und Blockzahlen. Ohne oekonomische Bedeutung.
- **** — Stack-/Hardwarekosten, keine Systemkosten. FfE 2025 nennt für das Gesamtsystem rund 3120 EUR/kW. dena-Quelle weist gar keine Kosten aus.
- **Das GES-Ergebnis kehrt sich faktisch um** — Unsicherheitsbänder überlappen (Kostenminimum p5-p95 133-190 vs. 80%EE+Gas 132-152); Effekt beruht teilweise auf dem Opex-Artefakt; gegenüber beiden H2-Pfaden bleibt das Kernkraft-Szenario günstiger.
- **Opex = 7 % des (korrigierten) CAPEX** — Betriebskosten skalieren nicht mit den Baukosten. Bei 14667 EUR/kW ergaebe das 128 EUR/MWh reine Betriebskosten.
- **** — Meinungsblog, KI-generiertes Wiki, Blog ohne Peer Review. Für ein Papier mit wissenschaftlichem Anspruch nicht zitierfaehig.
---
## Gegenpositionen, die mitlaufen muessen
Diese Punkte sprechen gegen die eigene Schlussrichtung und gehoeren deshalb zwingend dazu — eine Analyse, die nur ihre eigenen Argumente zeigt, ist Werbung.
- **[A]** Die GES-Studie legt ihre Annahmen ungewöhnlich offen - Basisjahr, Interkonnektor-Deckelung, keine Batterien, keine Wasserstoffimporte als Standardlösung, WACC. Genau diese Transparenz macht diesen Check erst möglich.
- **[A]** Bei drei Prozent Diskontsatz ist Kernkraft in allen von IEA und NEA untersuchten Ländern die günstigste Option, bei zehn Prozent in praktisch keinem. Dieselbe Technologie, dieselben Baukosten - nur eine andere Finanzierungsannahme.
- **[A]** Der globale Median der Bauzeit liegt bei 6,3 Jahren, 68 Prozent aller Reaktoren weltweit wurden in unter acht Jahren gebaut. Für eine Deutschland-Prognose ist der Median allerdings die falsche Kennzahl: Jedes westliche Neubauprojekt der letzten 20 Jahre lag zwischen 10 und 18 Jahren.
- **[A]** Die europäischen Neubauprojekte liegen deutlich unter Hinkley Point C: EPR2 7265 bis 7583 Euro je Kilowatt Overnight, Dukovany 7906 als EPC-Vertrag, Polen 11968, Sizewell C 13472. Die GES-Annahme von 6000 Euro ist keine willkürliche Zahl - sie liegt nur knapp unter dem, was EDF selbst für ein serielles Programm ansetzt.
- **[A]** Bei den Betriebskosten hat die GES-Studie eher zu hoch als zu niedrig gerechnet. Das relativiert die Aussage, sie unterschätze Kernkraft.
- **[B]** Der Round-Trip-Wirkungsgrad der Wasserstoffkette liegt realistisch bei 30 bis 40 Prozent. Für eine Kilowattstunde rückverstromten Strom braucht es zweieinhalb bis dreieinhalb Kilowattstunden erneuerbaren Strom. Genau daraus entsteht die Überkapazität im 100-Prozent-Szenario - dieser Mechanismus ist physikalisch korrekt.
- **[B]** Korea baut günstig, weil eine Baureihe ohne Designänderungen, eine ununterbrochene Lieferkette seit den 1970er Jahren, ein Betreiber, ein Regulator und staatlich gesteuerte Finanzierung zusammenkommen. Aber auch dort wurden Shin Kori 3 und 4 drei beziehungsweise fünf Jahre später fertig, mit rund 30 Prozent Mehrkosten - und derselbe Reaktortyp kostete im Export rund das 2,7-Fache.
- **[A]** Auch der erneuerbare Pfad hat Risiken: der China-Anteil in der Photovoltaik-Lieferkette, kritische Rohstoffe für Batterien und Windkraft, die Verluste der Wasserstoffkette, saisonale Speicherung am teuren Ende der Spanne und Aufwärtsrisiken beim Netzausbau durch Rohstoffpreise, Transformatorenknappheit und Genehmigungsverzüge.
---
## Geprüfte Zahlenbloecke
### Kernkraft: Kosten, Bauzeiten, Referenzprojekte
```json
{
"clusters": [
{
"anchors": [
"APR1400 Inland 1867",
"Shin Hanul 3&4 2720",
"Barakah EPC 3153",
"Barakah gesamt 4945"
],
"capex_eur_kw": [
1870,
4950
],
"caveat": "Voraussetzungen (ununterbrochene Lieferkette, ein Regulator, staatlich gesteuerte Finanzierung, niedrige Bau- und Ingenieurslöhne, eingeschränkte Drittanfechtung) in Deutschland rechtlich nicht herstellbar. Auch hier Verzögerungen: Shin Kori 3/4 3 bzw. 5 Jahre, +30 Prozent Kosten. Export-Aufschlag Faktor 2,7.",
"confidence": "B",
"id": "asien_golf",
"label": "Asien / Golf (Serienbau)"
},
{
"anchors": [
"EPR2 OCC 2020er Preise 7265-7583",
"Dukovany II EPC 7906",
"EPR2 inkl. Finanzierung ca. 10400",
"Lubiatowo-Kopalino 11968",
"Sizewell C 13472"
],
"capex_eur_kw": [
7265,
13472
],
"confidence": "A",
"id": "eu_serie",
"label": "EU-Serie / Vertragspreise"
},
{
"anchors": [
"Vogtle 3&4 13500",
"Flamanville 3 14364",
"Hinkley Point C 17264 nominal / 12408 real GBP2015"
],
"capex_eur_kw": [
13500,
17264
],
"confidence": "A",
"id": "west_foak",
"label": "Westliches Erstprojekt (FOAK)"
}
],
"construction_years": {
"confidence": "A",
"max": 17,
"mid": 12,
"min": 8
},
"fuel_eur_mwh": {
"confidence": "A",
"max": 11,
"mid": 8,
"min": 6
},
"full_load_hours": {
"confidence": "M",
"max": 8000,
"mid": 7500,
"min": 6500
},
"idc_surcharge_pct": {
"confidence": "B",
"empirical_anchor": "EPR2 72,8 Mrd. EUR ohne -> ca. 100 Mrd. EUR mit Finanzierung = +37 Prozent",
"max": 0.55,
"mid": 0.33,
"min": 0.2
},
"independent_benchmarks_eur_mwh": [
{
"confidence": "A",
"range": [
136,
490
],
"source": "Fraunhofer ISE, Stromgestehungskosten, Juli 2024"
},
{
"confidence": "A",
"range": [
122,
190
],
"source": "Lazard LCOE+ v18, Juni 2025 (unsubventioniert, USA)"
},
{
"confidence": "A",
"note": "Einziger real vertraglich fixierter Neubau-Strompreis.",
"source": "Hinkley Point C CfD, indexiert 17.01.2026",
"value": 147
},
{
"confidence": "A",
"note": "Ueberwiegend nicht-westliche Laender, Vorab-Schaetzung.",
"range": [
36,
88
],
"source": "IEA/NEA 2020 bei 7 Prozent Diskontsatz"
}
],
"lcoe_recomputed_eur_mwh": {
"confidence": "B",
"method": "CRF(r,60), Opex 165 EUR/kW/a absolut, 7500 h, Brennstoff 8, Entsorgung 8",
"wacc_5": {
"10275": 110.4,
"12000": 122.5,
"14667": 141.3,
"16000": 150.7,
"17500": 161.3,
"6000": 80.3,
"7500": 90.8
},
"wacc_8": {
"10275": 148.7,
"12000": 167.3,
"14667": 196.0,
"16000": 210.4,
"17500": 226.5,
"6000": 102.6,
"7500": 118.8
}
},
"lead_time_before_concrete_years": {
"confidence": "M",
"max": 12,
"mid": 8,
"min": 5
},
"lifetime_years": 60,
"md_values_for_contrast_only": {
"note": "Nur zum Zeigen des Opex-Artefakts, NICHT als Ergebnis erzaehlen.",
"wacc_5": {
"10275": 166.9,
"14667": 234.0,
"6000": 101.6
},
"wacc_8": {
"10275": 203.4,
"14667": 286.0,
"6000": 122.9
}
},
"model_presets_eur_kw": {
"erstprojekt": 17500,
"eu_mittel": 12000,
"eu_serie": 7500,
"ges_annahme": 6000
},
"opex_eur_kw_a": {
"confidence": "B",
"max": 200,
"mid": 165,
"min": 130,
"note": "ABSOLUT modellieren, nicht als CAPEX-Prozentsatz."
},
"wacc_slider": {
"confidence": "A",
"max": 0.09,
"mid": 0.05,
"min": 0.03
},
"waste_eur_mwh": {
"confidence": "B",
"max": 14,
"mid": 8,
"min": 5
}
}
```
### Elektrolyse und Wasserstoff
```json
{
"confidence": "B",
"eu_actual_2025_eur_kw": {
"alkali": 2075,
"confidence": "B",
"pem": 2196,
"source_id": "global-hydrogen-hub-2025"
},
"ffe_full_system_2025_eur_kw": 3120,
"ffe_note": "FfE Discussion Paper 07/2025: realistische Systemkosten rund 3120 EUR/kW - etwa das Zweieinhalbfache des ueblicherweise Angenommenen. Viele Studien betrachten nur die Hardware (Stack, Gleichrichter, Kompressoren) und blenden Planung, Genehmigung und Installation aus. Reale Projektentwickler-Angaben 2024: 9-13 EUR/kg statt der prognostizierten 2,50-4,50 EUR/kg bis 2030.",
"md_claim_eur_kw": [
800,
1200
],
"md_claim_verdict": "verworfen - Stack-/Hardwarekosten statt Systemkosten; dena-Quelle weist gar keine Kosten aus",
"model_range_eur_kw": {
"confidence": "B",
"max": 2600,
"mid": 2100,
"min": 1200
},
"recommended_upper_reference_eur_kw": 3120,
"statement": "Bei den Elektrolyseuren dreht sich der Vorwurf um: Wer 800 bis 1200 Euro je Kilowatt ansetzt, rechnet nur die Hardware. Mit Planung, Genehmigung und Installation kommt das Muenchner FfE für 2025 auf rund 3120 Euro je Kilowatt. Die GES-Studie rechnet hier also eher zu günstig als zu teuer.",
"status": "MD-Claim verworfen, Richtung dreht sich um",
"study_assumption_eur_kw": 1760
}
```
### ETS, Gas und CCS
```json
{
"additional_finding": "Die Luecke trifft nicht nur die 80-Prozent-Szenarien: In unserem Dispatch braucht auch das GES-Kostenminimum-Szenario 53,9 GW Gas-Spitzenleistung.",
"confidence": "A (ETS1/ETS2-Abgrenzung) / B (Projektion 2030, Restemissionen)",
"correction": "Die EWI-Werte (ca. 120 EUR/t 2027, ca. 205 EUR/t 2035) stammen aus dem ETS 2 (Gebaeude, Verkehr, kleine Industrie). Der ETS 2 betrifft die Stromerzeugung NICHT - dafür gilt ETS 1. Zusätzlich startet ETS 2 nicht 2027, sondern 2028 (Rat 05.11.2025, EP 13.11.2025).",
"cost_impact_eur_mwh_gas": {
"at_126": {
"default": 15.1,
"max": 27.7,
"min": 6.2
},
"at_205": {
"default": 24.6,
"max": 45.1,
"min": 10.0
},
"at_75": {
"default": 9.0,
"max": 16.5,
"min": 3.7
}
},
"ets1_2040_note": "Keine belastbare Projektion - EU-Ziel für 2040 regulatorisch nicht abschliessend festgelegt. Alle 2040-Werte sind Szenario, nicht Prognose.",
"ets1_prices_eur_t": {
"2040": null,
"allzeithoch_feb_2023": 100.34,
"analystenspanne_2030": [
80,
147
],
"konsens_2030": 126,
"mai_2026": 74
},
"gas_ccs_residual_g_co2_kwh": {
"confidence": "B",
"default": 120,
"max": 220,
"min": 49
},
"md_claim": "ETS-Preis laut EWI > 200 EUR/t bis 2035",
"statement": "Dass auf die Restemissionen von Gas mit CCS kein CO2-Preis gelegt wird, ist eine echte Luecke - aber eine kleine: Sie bewegt die Systemkosten um weniger als fünf Euro je Megawattstunde. Und der oft zitierte Preis von über 200 Euro je Tonne stammt aus dem ETS 2, der für Strom gar nicht gilt.",
"status": "Richtung bestätigt, Preisquelle korrigiert, Groesse klein",
"system_impact_eur_mwh_at_10pct_gas_share": [
0.4,
4.5
]
}
```
### CCS — was modelliert ist und was nicht
```json
{
"backup_full_load_hours": {
"ee80_gas": 1930,
"kostenminimum": 1282
},
"confidence": "B",
"decomposition_note": "Die Zerlegung des Aufschlags in Kapazität, Mehrbrennstoff, CCS-Kette und gesparte CO2-Kosten stammte aus dem v0.2b-Lauf und ist mit v0.2c nicht neu gerechnet worden. Sie ist deshalb aus dem Datensatz entfernt; qualitativ bleibt der Befund: Der dominante Posten ist der verdoppelte Kapitalblock, nicht die Abscheidung selbst.",
"delta_eur_mwh": {
"ee80_gas": 28.1,
"kostenminimum": 10.5
},
"implied_abatement_cost_eur_t": {
"ee80_gas": 357,
"kostenminimum": 510
},
"note": "Ein Gaskraftwerk mit Abscheidung kostet in der Anschaffung rund das Doppelte, läuft aber nur 1.300 bis 1.900 Stunden im Jahr. Die impliziten Vermeidungskosten sind eine OBERGRENZE - und zwar für beides, für die Vermeidungskosten und für den Aufschlag selbst: Die Rechnung rüstet den GESAMTEN Backup-Park aus, auch die Blöcke mit sehr wenigen Betriebsstunden. Ein real optimiertes System würde nur die hoch ausgelasteten Blöcke ausrüsten und die Spitzenlast unabgeschieden fahren - dann fällt der Aufschlag kleiner aus, dafür bleibt mehr Restemission.",
"residual_mt_co2_a": {
"ee80_gas": 31.7,
"kostenminimum": 8.3
},
"source": "research/modell_v02c_ergebnis.md 6.5",
"stored_mt_co2_a": {
"ee80_gas": 91.2,
"kostenminimum": 23.9
}
}
```
### CO2-Preis-Sensitivitaet
```json
{
"confidence": "B",
"crossover_kernkraft_vs_gas_eur_t": 101.8,
"crossover_mc_median_eur_t": 152,
"crossover_note": "Diese Marke gilt für den deterministischen Lauf mit den mittleren Annahmen: Darunter ist der gasgestützte Pfad günstiger, darüber das Kernkraft-Szenario. Über die 1.000 gepaarten Ziehungen wird die Median-Differenz erst bei rund 152 Euro je Tonne null. Der ETS-1-Marktpreis von 74 Euro (Mai 2026) und der Modellwert von 75 Euro liegen unter beiden Marken - beim heutigen CO2-Preis führt in dieser Rechnung der Gas-Pfad. Die Marke wandert mit dem Gaspreis und mit der Netzregel; sie ist keine Naturkonstante. Mit Abscheidung auf beiden Seiten gibt es gar keinen Kipppunkt: Dort liegt das Kernkraft-Szenario bei jedem CO2-Preis vorn.",
"ets1_market_may_2026_eur_t": 74,
"levels": [
{
"co2_eur_t": 0,
"ee100": 245.1,
"ee80_gas": 148.4,
"ee80_gas_ccs": 182.5,
"ee80_h2": 199.1,
"ist2025": 161.2,
"kostenminimum": 156.8,
"kostenminimum_ccs": 168.9,
"label": "kein CO₂-Preis"
},
{
"co2_eur_t": 75,
"ee100": 245.2,
"ee80_gas": 156.8,
"ee80_gas_ccs": 185.0,
"ee80_h2": 199.5,
"ist2025": 180.8,
"kostenminimum": 159.0,
"kostenminimum_ccs": 169.6,
"label": "Modellwert (ETS-1-Marktniveau)"
},
{
"co2_eur_t": 350,
"ee100": 245.5,
"ee80_gas": 187.7,
"ee80_gas_ccs": 194.1,
"ee80_h2": 200.9,
"ist2025": 252.8,
"kostenminimum": 167.1,
"kostenminimum_ccs": 172.0,
"label": "UBA-Klimakostensatz MK 3.2 (1 % Diskontierung)"
},
{
"co2_eur_t": 990,
"ee100": 246.4,
"ee80_gas": 259.4,
"ee80_gas_ccs": 215.5,
"ee80_h2": 204.1,
"ist2025": 420.2,
"kostenminimum": 185.9,
"kostenminimum_ccs": 177.6,
"label": "UBA-Klimakostensatz MK 4.0 (Zentralwert)"
}
],
"method": "scripts/model.py, mix_system, Szenariensatz mittel, WACC 5 %, Netzvariante mid, Profil H2-2024; alle Parameter unverändert, variiert wird ausschließlich co2_price. Kipppunkt per Bisektion; der Umschlagpunkt über die gepaarten Ziehungen ist der CO2-Preis, bei dem die Median-Differenz null wird.",
"model_version": "0.2c",
"source_ids": [
"uba-methodenkonvention",
"ews-ets2"
],
"superseded_note": "Dieselbe Marke lag im Panel-Review 05 mit Modellstand v0.1 bei rund 260 Euro je Tonne und in v0.2b bei 47,5 Euro. Der Sturz auf 47,5 kam daher, dass v0.2 dem Gas-Pfad seinen Brennstoff in Rechnung stellt und die Bauzinsen-Doppelzählung bei der Kernkraft entfernt; der Wiederanstieg auf 101,8 kommt vom Übertragungsnetz-Sockel aus v0.2c, der den Kernkraft-Pfad um 6,7 und den Gas-Pfad nur um 2,2 Euro je Megawattstunde verteuert. Beide älteren Zahlen dürfen nur als abgelöste Werte zitiert werden.",
"superseded_v01_estimate_eur_t": 260,
"superseded_v02b_estimate_eur_t": 47.5,
"uba_mk32_1pct_eur_t": 350,
"uba_mk40_central_eur_t": 990,
"uba_note": "Der Abstand zwischen Marktpreis und Klimakostensatz ist keine Rechenfrage, sondern eine Wertentscheidung: 350 Euro je Tonne folgen einer Zeitpräferenzrate von 1 Prozent, die Werte um 990 bis 1.000 Euro gewichten heutige und künftige Generationen gleich.",
"unit_costs": "EUR/MWh Systemkosten"
}
```
### Der Dreissig-Jahres-Plan: Startwerte korrigiert
```json
{
"investment_check": {
"breakdown_bn_eur": {
"generation_storage_electrolysis": 652,
"grid": 760
},
"grid_share_verdict": "M - 760 Mrd. EUR bis 2056 ist eine Extrapolation. Belegte Referenzen: IMK 651 Mrd. EUR bis 2045 (Übertragung 328 + Verteilung 323, Konfidenz A) und NEP 2037/2045 V2025 365-392 Mrd. EUR bis 2045 (nur Übertragung, Konfidenz B).",
"md_total_bn_eur": 1412,
"missing_replacement_capex_bn_eur": {
"battery_phase1_120gwh_at_120": 14,
"confidence": "B",
"note": "Der Plan rechnet ausschliesslich Netto-Zubauten. Phase 3 heisst 'Konsolidierung & Repowering', enthält aber keinen Euro dafür. Realistische Gesamtinvestition eher 1550-1650 Mrd. EUR.",
"pv_stock_110gw_at_420": 46,
"sum": 208,
"wind_offshore_10gw_at_3400": 34,
"wind_onshore_65gw_at_1750": 114
},
"phase_generation_bn_eur": {
"2026-2035": 234.8,
"2036-2045": 226.8,
"2046-2056": 190.3
},
"phase_implied_grid_bn_eur": {
"2026-2035": 180.2,
"2036-2045": 300.2,
"2046-2056": 279.7
},
"reproduced": true
},
"learning_curves": {
"battery_eur_kwh": {
"counter_evidence": [
{
"claim": "Lazard LCOE+ v19 (Juli 2026): Speichersystemkosten seit 2020 um 27 Prozent GESTIEGEN; LCOS 100 MW / 4 h bei 210-292 USD/MWh. Ursachen: Zinsen, Zoelle, Lieferkettendruck, Rechenzentrumsnachfrage.",
"confidence": "A"
},
{
"claim": "Zelle/Pack ist nicht System: Faktor 2,5 bis 3 zwischen Pack-Preis und betriebsbereitem Netzspeicher in Europa. Schluesselfertige 4-h-Systeme in Europa 180-260 EUR/kWh.",
"confidence": "B"
}
],
"supporting_evidence": [
{
"claim": "BNEF Dez. 2025: Pack-Preise auf Rekordtief 108 USD/kWh (minus 8 Prozent), stationaere Packs 70 USD/kWh; berechnete Lernrate rund 18 Prozent je Verdopplung",
"confidence": "A"
},
{
"claim": "IRENA 2024: Batteriespeichersysteme minus 93 Prozent seit 2010, 2024 bei 192 USD/kWh",
"confidence": "B"
}
],
"values": [
200,
150,
120
],
"verdict": "M",
"verdict_detail": "Startwert 200 EUR/kWh liegt korrekt in unserer Modellspanne. Endwert 120 EUR/kWh liegt unterhalb der heutigen Systemkosten-Untergrenze und ist reine Setzung. kosten_ee_speicher.md 6 warnt explizit vor automatischer Lernkurven-Extrapolation nach unten."
},
"electrolyser_eur_kw": {
"reason": "Startwert liegt um Faktor 2,3 unter den europäischen Ist-Systemkosten (ca. 2100 EUR/kW) und um Faktor 3,5 unter der FfE-Vollkostenrechnung (3120 EUR/kW).",
"replacement_proposal": {
"end_2056": [
1200,
1400
],
"start_2026": 2100,
"verdict": "M"
},
"values": [
900,
650,
480
],
"verdict": "verworfen"
},
"gas_eur_kw": {
"note": "Konsistent mit unserem Befund, dass der alte Referenzwert 800 EUR/kW für 2026 um Faktor 2-2,5 zu niedrig ist. Modellspanne 1000/1600/2200.",
"values": [
2200,
2200,
2200
],
"verdict": "B"
},
"pv_eur_kw": {
"caveat": "Die Degression von minus 35 Prozent über 30 Jahre ist etwas ambitionierter als die ISE-Projektion. Zusätzlich liegt der Startwert 650 EUR/kW bereits am optimistischen Ende unserer Modellspanne (600-1000, Default 750).",
"supporting_evidence": [
{
"claim": "Fraunhofer ISE Juli 2024: PV-Freiflaeche 4,1-6,9 ct/kWh heute -> 3,1-5,0 ct/kWh 2045 (minus 24 bis 28 Prozent), auf Basis technologiespezifischer Lernraten",
"confidence": "A"
},
{
"claim": "ITRPV: historische Lernrate der PV-Industrie 26 Prozent je Verdopplung der kumulierten Produktion (1976-2025); zuvor 24,9 Prozent",
"confidence": "B"
},
{
"claim": "IRENA: global rund 500 USD/kW für PV im Jahr 2030 erwartet - mit ausdrücklichem Vorbehalt, dass in Europa und Nordamerika strukturell hoehere Kosten fortbestehen",
"confidence": "B"
}
],
"values": [
650,
500,
420
],
"verdict": "M"
},
"status": "SETZUNG (M) mit teilweise belegbarer Richtung",
"wind_offshore_eur_kw": {
"note": "Modellspanne 2600-4500, Default 3400. Die MD-Werte liegen darin.",
"values": [
3700,
3500,
3400
],
"verdict": "M"
},
"wind_onshore_eur_kw": {
"note": "Plausible Setzung (ausgereifte Technologie), deckt sich mit unserem Modellwert 1790 EUR/kW.",
"values": [
1750,
1750,
1750
],
"verdict": "M/B"
}
},
"lscoe_2056": {
"flh_finding": {
"confidence": "A",
"note": "Ein Befund ZUGUNSTEN des Plans, den das MD selbst verschenkt.",
"statement": "Die 174-TWh-Deckungsluecke ist groesstenteils ein Artefakt der GES-Volllaststunden. Mit unseren Neuanlagen-Werten (PV 1030 h, Wind onshore 2400 h, Wind offshore 3800 h) erzeugt derselbe Anlagenpark 1038 statt 876 TWh - die Luecke schrumpft von 17 auf 1 Prozent."
},
"md_reconstruction": {
"demand_twh": 1050,
"divided_by_demand": 121.5,
"divided_by_generation": 145.7,
"flaw": "Das MD teilt die Gesamtkosten durch den Bedarf (1050 TWh), obwohl nur 876 TWh erzeugt werden. Die Deckungsluecke von 174 TWh (17 Prozent) wird damit implizit zum Nulltarif gedeckt.",
"generation_twh": 876,
"total_cost_bn_eur_a": 127.6
},
"md_value": 121.7,
"our_model": {
"caveats": "Profile PARTIAL (H2-2024, 4416 h, auf ein Jahr hochgerechnet - winterlastig); für Offshore wird ersatzweise das Onshore-Profil verwendet; Erdgas-Brennstoffkosten mit 0 angesetzt (harte Datenluecke) - der Wert ist eine UNTERGRENZE; Import/Export und Lastmanagement nicht modelliert.",
"confidence": "B",
"cost_components_eur_mwh_mittel": {
"battery": 9.7,
"electrolyser": 13.0,
"gas_backup": 11.3,
"h2_storage": 6.4,
"h2_turbine": 6.5,
"netz": 38.6,
"pv": 25.2,
"wind_offshore": 25.3,
"wind_onshore": 26.7
},
"deviation_vs_md_eur_mwh": 41.1,
"engine": "scripts/model.py mix_system",
"guenstig": 106.9,
"inputs": {
"battery_gw": 110,
"battery_gwh": 450,
"co2_price_eur_t": 75,
"demand_twh": 1050,
"electrolyser_gw": 55,
"gas_backup_gw": 45,
"h2_turbine_gw": 45,
"pv_gw": 400,
"wind_offshore_gw": 70,
"wind_onshore_gw": 150
},
"mittel": 162.8,
"mittel_with_md_flh": 148.6,
"teuer": 290.1
},
"recommended_value": {
"confidence": "B",
"is_lower_bound": true,
"mid": 163,
"range": [
107,
290
],
"unit": "EUR/MWh"
}
},
"nuclear_variant": {
"corrected": {
"capex_eur_kw_range": [
12000,
17500
],
"confidence": "B",
"investment_bn_eur": 51.2,
"lcoe_eur_mwh_at_16000": {
"wacc_5": 150.7,
"wacc_8": 210.4
},
"our_model_delta": 2.3,
"our_model_system_lscoe": 165.1
},
"counterposition": "Ein Programm mit nur zwei Blöcken ist die denkbar ungünstigste Konstruktion - genau die Konstellation ohne Serieneffekte. kosten_kernkraft.md 7.1 weist den Low-Fall (7500 EUR/kW) als 'nur erreichbar bei mindestens 6 Blöcken identischer Bauart und Turnkey-Festpreis' aus. Wer Kernkraft fair prüft, muss sie als Programm rechnen. Einziger dokumentierter Serieneffekt: OPG Darlington, minus 32 Prozent vom ersten Block zum Durchschnitt über vier Blöcke.",
"lead_time": {
"confidence": "A",
"statement": "Realistischer Gesamtpfad von der politischen Entscheidung bis zum ersten kommerziellen Block: 18-25 Jahre - inklusive Aufhebung des gesetzlichen Neubauverbots, Behördenaufbau und Standortverfahren. Vergleich: Polen 6 Jahre von der Technologieentscheidung bis zum ersten Beton, Tschechien 5 Jahre von der Vergabe."
},
"md": {
"capex_eur_kw": 16000,
"delta": 7.6,
"gw_each": 1.6,
"investment_bn_eur": 51.2,
"lcoe_eur_mwh": 311.1,
"online": [
2045,
2052
],
"reactors": 2,
"system_lscoe": 129.3,
"wacc": 0.08
},
"robust_finding": "3,2 GW auf über 600 GW Gesamtkapazität sind ein Rundungsfehler. Zwei Blöcke liefern rund 25 TWh pro Jahr bei 1050 TWh Bedarf (2,4 Prozent) - bei 51 Mrd. EUR Kapitalbindung und ohne jeden Beitrag vor 2045. Das ist ein Skalen-Argument, kein Kosten-Argument."
},
"start_2026_corrected": {
"battery": {
"confidence": "A",
"corrected_gw": [
18.5,
20.0
],
"corrected_gwh": [
31.0,
31.5
],
"md_gw": 5,
"md_gwh": 15,
"scope": "alle Groessenklassen inkl. Heimspeicher (MaStR, H1 2026)",
"warning": "Ein kursierender Grossspeicher-Wert von 1,2 GW / 2,4 GWh (Q2 2026) ist laut ist_zustand_de.md 2.2 implausibel niedrig und nicht ohne Pruefung verwendbar. Abgrenzung IMMER mitnennen."
},
"demand_twh": {
"confidence": "A",
"corrected_2024": 518,
"corrected_2025_range": [
512,
526
],
"md": 560,
"note": "Bruttostromverbrauch. Der MD-Startwert liegt 7-9 Prozent zu hoch."
},
"gas_gw": {
"confidence": "B",
"corrected": [
35,
36
],
"md": 30
},
"nuclear_gw": {
"confidence": "A",
"corrected": 0,
"md": 0
},
"pv_gw": {
"as_of": "2026-07",
"confidence": "A",
"corrected": 126.6,
"eoy2025": 117.0,
"md": 110
},
"wind_offshore_gw": {
"as_of": "2026 Jahresmitte",
"confidence": "A",
"corrected": 10.8,
"eoy2025": 9.6,
"md": 10
},
"wind_onshore_gw": {
"as_of": "2026-07",
"confidence": "A",
"corrected": 71.0,
"eoy2025": 68.1,
"md": 65
}
}
}
```
### Die Klimapraemisse
```json
{
"confidence": "A",
"confidence_note": "Substanz Konfidenz A. Der Wortlaut der Zitate ist aus Suchindex-Auszügen rekonstruiert, das PDF war in dieser Arbeitsumgebung nicht abrufbar (Konfidenz B für die wörtliche Fassung).",
"grenze": "Dieses Modell vergleicht Endzustände, keine Transformationspfade. Kumulative Emissionen — nach AR6 die klimarelevante Größe — sind darin nicht bilanziert.",
"k1_fundstelle": "IPCC AR6 Synthesis Report, Summary for Policymakers, A.1",
"k1_zitat": "Human activities, principally through emissions of greenhouse gases, have unequivocally caused global warming, with global surface temperature reaching 1.1 °C above 1850-1900 in 2011-2020.",
"k4_aussage": "Zwischen kumulativen CO₂-Emissionen und dem Anstieg der globalen Oberflächentemperatur besteht ein nahezu linearer Zusammenhang (high confidence). Erst das rechtfertigt es, überhaupt einen einheitlichen Preis je Tonne anzusetzen — unabhängig davon, wo und wann emittiert wird.",
"k4_fundstelle": "IPCC AR6 WG1, Summary for Policymakers, D.1.1 und Abbildung SPM.10",
"restbudget_gt_co2": {
"1_5_grad_50_prozent": 500,
"2_grad_67_prozent": 1150,
"fundstelle": "AR6 Synthesis Report SPM, B.5.2",
"stand": "Anfang 2020"
},
"source_ids": [
"ipcc-ar6-syr",
"ipcc-ar6-wg1"
],
"titel": "Was hier nicht verhandelt wird"
}
```
### Marktdesign — die unbepreiste Voraussetzung
```json
{
"ausschreibung_1": {
"datum": "1. September 2026",
"volumen_gw": 4.5
},
"ausschreibung_2": {
"datum": "8. Dezember 2026",
"volumen_gw": 4.5
},
"bezug_zum_modell": "Unser Modell setzt die Backup-Leistung als Ergebnis des Dispatch, nicht als Marktprozess. Wer die 137 GW Gasleistung des gasgestützten Pfades liest, sollte wissen, in welchem Tempo Deutschland gesicherte Leistung derzeit tatsächlich beschafft.",
"confidence": "A",
"gesamtvolumen_zunaechst_gw": 11,
"gesetz": "StromVKG - Gesetz zur Sicherung der Versorgungssicherheit Strom und zur Bereitstellung neuer Kapazitäten",
"grundsatzeinigung_eu": "2026-01-15",
"inbetriebnahme_spaetestens": 2031,
"kabinettsbeschluss": "2026-05-13",
"koalitionsvertrag_ziel_gw_bis_2030": 20,
"offener_widerspruch": "11 GW Ausschreibungsarchitektur gegen 20 GW Koalitionsvertragsziel; die Ausgestaltung des Kapazitätsmechanismus ist nicht final entschieden.",
"source_ids": [
"bmwe-kraftwerksstrategie"
],
"technologiefokus": "wasserstofffähige Gaskraftwerke, daneben ausdrücklich Speicher und andere steuerbare Anlagen"
}
```
### Dunkelflaute ist zuerst eine Definitionsfrage
```json
{
"confidence": "A",
"definitionen": [
{
"mindestdauer_h": 48,
"quelle": "Deutscher Wetterdienst",
"schwelle": "unter 10 % der Nennleistung"
},
{
"mindestdauer_h": 10,
"quelle": "Uniper-Kurzstudie 2026",
"schwelle": "unter 10 % der installierten Leistung von Wind und PV zusammen, gleitender 6-Stunden-Mittelwert"
}
],
"dezember_2024": "Beim Referenzereignis im Dezember 2024 hat das System die Dunkelflaute technisch bewältigt - Reserven waren vorhanden, es gab keine Versorgungsunterbrechung -, aber zu Day-Ahead-Preisen zeitweise über 1.000 Euro je Megawattstunde. Bundesnetzagentur und Bundeskartellamt fanden keinen Marktmissbrauch, wohl aber ein strukturelles Problem.",
"haeufigkeit_lang": "Ereignisse über 48 Stunden treten rund zwei- bis dreimal im Jahr auf; das längste Ereignis der letzten zehn Jahre dauerte 5,4 Tage.",
"haeufigkeit_uniper": "1.435 Ereignisse über 10 Stunden zwischen 2016 und 2025, mittlere Dauer 12,9 Stunden - also im Mittel öfter als alle drei Tage.",
"interessenlage": "Uniper betreibt konventionelle Kraftwerke und hat ein wirtschaftliches Interesse daran, den Backup-Bedarf zu betonen. Die 10-Stunden-Schwelle ist nicht falsch, sie produziert aber naturgemäß viel höhere Ereigniszahlen als die 48-Stunden-Definition des DWD. Umgekehrt blendet die DWD-Definition Erzeugungslücken von 10 bis 24 Stunden aus, die für den Speicherbedarf sehr wohl zählen.",
"kernaussage": "Es gibt keine einheitliche Definition. Deshalb können beide Seiten mit korrekten Zahlen das Gegenteil behaupten.",
"source_ids": [
"uniper-dunkelflaute-2026",
"lbbw-dunkelflaute-2025",
"bnetza-preisspitzen-2025"
]
}
```
### Kostenueberschreitungen: was die Empirie sagt
```json
{
"capex_effektiv_faktor": 1.3,
"capex_effektiv_median_eur_kw": 15941,
"capex_effektiv_median_v02b_eur_kw": 22770,
"confidence": "B",
"hpc_nominal_eur_kw": 17264,
"rest_anteile": [
0.48,
0.5,
0.0
],
"schaetzbasis_eur_kw": 7500,
"source": "research/modell_v02c_ergebnis.md 4.1-4.4",
"text": "Der empirische Überschreitungsfaktor wird seit v0.2c nicht mehr auf jeden gezogenen Baukostenwert multipliziert, sondern als absoluter Betrag auf einer einzigen Schätzbasis von 7.500 Euro je Kilowatt gerechnet - und nur auf den Teil der Eskalation, der noch aussteht. Auf Anker, die ihre Verteuerung bereits hinter sich haben (Hinkley Point C in laufenden Preisen), kommt gar nichts mehr obendrauf. Ergebnis: Der effektive Baukostenwert liegt im Überschreitungs-Lauf im Median bei 15.941 statt 22.770 Euro je Kilowatt - ein effektiver Faktor von 1,30 statt 1,86, und damit erstmals vollständig unterhalb des teuersten je gebauten westlichen Reaktors (17.264 Euro je Kilowatt)."
}
```
### Netz- und Regelanteil
```json
{
"anteil_am_deterministischen_abstand_pct": 44,
"anteil_am_median_vorsprung_pct": 58,
"confidence": "M",
"median_vorsprung_ccs_paar_eur_mwh": 11.7,
"sensitivitaet_abstand_eur_mwh": [
-2.3,
4.5
],
"sockel_effekt_gas_eur_mwh": 2.2,
"sockel_effekt_kernkraft_eur_mwh": 6.7,
"source": "research/modell_v02c_ergebnis.md 2.3",
"text": "Von den 11,7 Euro je Megawattstunde, mit denen das Kernkraft-Szenario im technologiesymmetrischen Vergleich vorn liegt, stammen 6,7 aus einer einzigen Modellsetzung: dem Anteil des Übertragungsnetzes, der auch ohne wetterabhängige Erzeugung gebaut werden müsste (0,40, Sensitivität 0,20 bis 0,60). Über diese Spanne bewegt sich der Abstand der beiden Pfade um 6,8 Euro je Megawattstunde - mehr als der Abstand selbst. Es ist der einzige Parameter des Modells, der die Rangfolge allein durch seine Wahl dreht."
}
```
### Die geprüfte Studie: Absender und Einordnung
```json
{
"confidence": "C",
"confidence_note": "Angaben zu Trägerschaft und Vereinsgeschichte stammen aus unserem eigenen Grundlagenpapier und sind nicht unabhängig gegengeprüft.",
"fairness_hinweis": "Dass ausgerechnet ein wasserstoffnaher Verein die wasserstofflastigen Pfade als die teuersten ausweist, spricht eher für als gegen die Unbefangenheit der Rechnung.",
"gegruendet": "2020 in Ulm",
"gegruendet_kontext": "initiiert aus dem Umfeld des Forschungsinstituts FAW/n",
"jahresbedarf_twh": 950,
"organisation": "Global Energy Solutions e.V.",
"source_ids": [
"ges-studie-2026"
],
"studie_erschienen": "Juli 2026",
"urspruenglicher_fokus": "grüner Wasserstoff, Methanol und Power-to-X-Importe",
"volltext_status": "Das Studien-PDF war in dieser Arbeitsumgebung nicht abrufbar. Alles, was hier über die Methodik der Studie steht, stützt sich auf unsere eigene, vor Wochen angefertigte Wiedergabe ihrer Annahmetabellen — jede einzelne Zahl daraus ist gegen unabhängige Quellen gehalten, die Studie im Original haben wir nicht gelesen.",
"zieljahr": 2045
}
```
### Was das fuer einen Haushalt bedeutet
```json
{
"confidence": "M",
"guardrail": "Systemkosten, kein Strompreis: Diese Zahlen sagen, was Erzeugung, Speicher, Backup und Netzausbau je Kilowattstunde kosten. Auf einer Stromrechnung stehen zusätzlich Vertrieb, Messung, Steuern und Abgaben, und die Netzkosten werden dort anders verteilt als hier modelliert. Der Haushalts-Anker macht Größenordnungen fühlbar - er ist keine Preisprognose.",
"note": "3.500 Kilowattstunden im Jahr sind die gerundete Referenzgröße für einen Zwei- bis Drei-Personen-Haushalt. Sie ist hier eine Rechenhilfe und keine Messung, deshalb als Setzung gekennzeichnet.",
"umrechnung": "1 Euro je Megawattstunde sind 0,1 Cent je Kilowattstunde - und bei 3.500 Kilowattstunden Jahresverbrauch 3,50 Euro im Jahr.",
"verbrauch_kwh_a": 3500
}
```
### Klimaziel 2045
```json
{
"confidence": "B",
"confidence_note": "Zielwerte aus § 3a KSG, über Suchindex-Auszüge und Sekundärquellen erfasst; der Gesetzestext war in dieser Arbeitsumgebung nicht im Volltext abrufbar. Es ist ein Zielwert, kein Ist-Wert - die tatsächliche Senkenleistung des Sektors liegt derzeit deutlich darunter und war zuletzt sogar negativ.",
"gesetz": "Bundes-Klimaschutzgesetz (KSG), § 3a",
"netto_neutralitaet_jahr": 2045,
"senke_mt_co2_aeq": {
"2030": 25,
"2040": 35,
"2045": 40
},
"source_ids": [
"ksg-3a"
],
"text": "Das Klimaschutzgesetz verlangt für 2045 Netto-Treibhausgasneutralität. Die dafür vorgesehene nationale Senkenleistung aus Landnutzung und Forstwirtschaft steht im selben Gesetz bei 40 Millionen Tonnen CO2-Äquivalent im Jahr - für alle Sektoren zusammen, Industrieprozesse, Landwirtschaft und Abfall eingeschlossen."
}
```
*Die Bloecke sind bewusst als JSON eingebettet: sie sind der unveraenderte, maschinenlesbare Datenstand der Story-Seite — jede Zahl mit Herkunft, Konfidenzstufe und Vorbehalt.*
---
## Quellenverzeichnis
Konfidenzstufen: **A** mehrfach bestaetigt / institutionelle Primaerquelle · **B** einzelner Treffer, institutionelle Quelle · **C** Branchen-/Marktquelle oder Modellannahme mit schwacher Belegbasis · **M** Setzung/Modellannahme, nicht quellenbelegt.
| Nr. | Titel | Herausgeber | Datum | Konfidenz |
|---:|:---|:---|:---|:---:|
| 1 | [Nuclear reactors' construction costs: The role of lead-time, standardization and technological progress](https://doi.org/10.1016/j.enpol.2015.03.015) | Energy Policy 82, S. 118-130 | 2015 | C |
| 2 | [Kraftwerksstrategie / StromVKG - Grundsatzeinigung mit der Europaeischen Kommission und Kabinettsbeschluss](https://www.bundeswirtschaftsministerium.de/Redaktion/DE/Pressemitteilungen/2026/01/20260115-grundsatzeinigung-mit-europaeischen-kommission-ueber-eckpunkte-der-kraftwerksstrategie.html) | Bundesministerium für Wirtschaft und Energie (BMWE) | 2026-01 / 2026-05 | A |
| 3 | [Lithium-Ion Battery Pack Prices Fall to 108 USD per Kilowatt-Hour (Battery Price Survey 2025); berechnete Lernrate rund 18 Prozent](https://about.bnef.com/insights/clean-transport/lithium-ion-battery-pack-prices-fall-to-108-per-kilowatt-hour-despite-rising-metal-prices-bloombergnef/) | BloombergNEF | 2025-12 | A |
| 4 | [Festlegung der Höchstwerte 2026 für Wind an Land und Solar-Dachanlagen](https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilungen/DE/2025/20251216_Hoechstwerte.html) | Bundesnetzagentur | 2025-12-16 | B |
| 5 | [Untersuchung zu Strompreisspitzen während Dunkelflauten 2024 (Pressemitteilung)](https://www.bundesnetzagentur.de/SharedDocs/Pressemitteilungen/DE/2025/20251021_Preisspitzen.html) | Bundesnetzagentur / Bundeskartellamt | 2025-10-21 | A |
| 6 | [Ausschreibung Solaranlagen erstes Segment, Gebotstermin 1. März 2026](https://www.bundesnetzagentur.de/DE/Fachthemen/ElektrizitaetundGas/Ausschreibungen/Solaranlagen1/BeendeteAusschreibungen/2026/01032026/start.html) | Bundesnetzagentur | 2026 | B |
| 7 | [Hohes Wettbewerbsniveau bei der Ausschreibung für Wind an Land zum 1. Mai 2026](https://www.bundesnetzagentur.de/1110006) | Bundesnetzagentur | 2026-06 | B |
| 8 | [Programme d'EPR: la Cour des Comptes publie un rapport critique et recalcule le cout de Flamanville 3](https://www.connaissancedesenergies.org/afp/programme-depr-la-cour-des-comptes-publie-un-rapport-critique-et-recalcule-le-cout-de-flamanville-3-250114) | Cour des Comptes / Connaissance des Energies (AFP) | 2025-01-14 | |
| 9 | [Elektrolysekapazitäten in Deutschland](https://www.dena.de/infocenter/elektrolysekapazitaeten-in-deutschland/) | Deutsche Energie-Agentur (dena) | 2026-04 | A |
| 10 | [Commission approves State aid for the construction and operation of Poland's first nuclear power plant](https://ec.europa.eu/commission/presscorner/detail/en/ip_25_2963) | Europäische Kommission | 2025-12-09 | |
| 11 | [EDF shares its forecasted cost estimate of the EPR2 programme for EUR72.8bn](https://www.edf.fr/en/the-edf-group/dedicated-sections/journalists/all-press-releases/edf-shares-its-forecasted-cost-estimate-of-the-epr2-programme-for-eu728bn) | EDF Groupe (Pressemitteilung) | 2025-12-18 | |
| 12 | [Plant Vogtle Unit 4 begins commercial operation](https://www.eia.gov/todayinenergy/detail.php?id=61963) | U.S. Energy Information Administration | 2024 | |
| 13 | [KHNP signs final contract to build two nuclear reactors at Dukovany (Czechia)](https://www.enerdata.net/publications/daily-energy-news/khnp-signs-final-contract-build-two-nuclear-reactors-dukovany-czechia.html) | Enerdata | 2025-06 | |
| 14 | [Revisiting the Cost Escalation Curse of Nuclear Power: New Lessons from the French Experience](https://ideas.repec.org/a/aen/eeepjl/eeep4-2-escobar.html) | Economics of Energy & Environmental Policy 4(2) | 2015 | C |
| 15 | [Auswirkungen und Preispfade des EU ETS2, Endbericht](https://www.ewi.uni-koeln.de/cms/wp-content/uploads/2025/04/EU-ETS2_Endbericht.pdf) | EWI, Universität zu Köln | 2025-04 | B |
| 16 | [Von der Theorie zur Praxis: Warum grüner Wasserstoff teurer ist als gedacht (Discussion Paper)](https://www.ffe.de/wp-content/uploads/2025/07/Discussion_Paper-Investitionskosten_Elektrolyse-2.pdf) | Forschungsstelle für Energiewirtschaft (FfE), München | 2025-07 | B |
| 17 | [How Big Things Get Done (Megaprojekt-Datenbank, ~16.000 Projekte)](https://budgetoverrun.com/studies/flyvbjerg-megaproject-database) | B. Flyvbjerg / D. Gardner, Currency/Penguin | 2023 | A |
| 18 | [20 GW Gaskraftwerke bis 2030 - Was kostet die Erweiterung?](https://foes.de/publikationen/2025/2025-04_FOES_BUND_Kraftwerkskosten.pdf) | FOES i.A. BUND | 2025-04 | B |
| 19 | [Stromgestehungskosten Erneuerbare Energien](https://www.ise.fraunhofer.de/content/dam/ise/de/documents/publications/studies/DE2024_ISE_Studie_Stromgestehungskosten_Erneuerbare_Energien.pdf) | Fraunhofer ISE | 2024-07 | A |
| 20 | [Kurzanalyse Stromgestehungskosten und Volllaststunden flexibler Kraftwerke](https://www.ise.fraunhofer.de/content/dam/ise/de/documents/publications/studies/Kurzanalyse_flexibleKraftwerke.pdf) | Fraunhofer ISE (Kost, Sepulveda Schweiger, Thomsen) | 2024/2025 | B |
| 21 | [Der klimaneutrale Strommix der Zukunft — Eine Szenarioanalyse zu den Kosten des zukünftigen deutschen Stromsystems](https://global-energy-solutions.org/wp-content/uploads/2026/05/DER-KLIMANEUTRALE-STROMMIX-DER-ZUKUNFT-veroeffentlicht-V1.1.pdf) | Global Energy Solutions e. V. | 2026-07 | C |
| 22 | [Der klimaneutrale Strommix der Zukunft](https://global-energy-solutions.org/wp-content/uploads/2026/05/DER-KLIMANEUTRALE-STROMMIX-DER-ZUKUNFT-veroeffentlicht-V1.1.pdf) | Global Energy Solutions e.V. | 2026-07 | C |
| 23 | [A reply to 'Historical construction costs of global nuclear power reactors'](https://law.stanford.edu/publications/a-reply-to-historical-construction-costs-of-global-nuclear-power-reactors/) | Energy Policy 102, S. 640-643 | 2017 | A |
| 24 | [European electrolyser costs fall in 2025 as manufacturing capacity expands](https://globalhydrogenhub.com/european-electrolyser-costs-fall-in-2025-as-manufacturing-capacity-expands.html) | Global Hydrogen Hub | 2025 | |
| 25 | [The costs of the French nuclear scale-up: A case of negative learning by doing](https://www.sciencedirect.com/science/article/abs/pii/S0301421510003526) | Energy Policy 38(9), S. 5174-5188 | 2010 | A |
| 26 | [Projected Costs of Generating Electricity - 2020 Edition](https://www.iea.org/reports/projected-costs-of-generating-electricity-2020) | IEA / OECD NEA | 2020-12 | B |
| 27 | [Netzinvestitionsbedarf bis 2045 (Uebertragungs- und Verteilnetz)](https://www.imk-boeckler.de/) | IMK / Hans-Böckler-Stiftung | 2025 | B |
| 28 | [Climate Change 2023: Synthesis Report — Summary for Policymakers](https://www.ipcc.ch/report/ar6/syr/summary-for-policymakers/) | IPCC | 2023-03 | A |
| 29 | [Climate Change 2021: The Physical Science Basis — Summary for Policymakers](https://www.ipcc.ch/report/ar6/wg1/chapter/summary-for-policymakers/) | IPCC (WG1) | 2021-08 | A |
| 30 | [Renewable Power Generation Costs in 2024](https://www.irena.org/-/media/Files/IRENA/Agency/Publication/2025/Jul/IRENA_TEC_RPGC_in_2024_Summary_2025.pdf) | IRENA | 2025-07 | B |
| 31 | [Renewable Power Generation Costs in 2024](https://www.irena.org/Publications/2024/Sep/Renewable-Power-Generation-Costs-in-2023) | IRENA | 2025-07 | B |
| 32 | [International Technology Roadmap for Photovoltaic (ITRPV), 16. Ausgabe - Lernrate 26 Prozent 1976-2025](https://www.pv-tech.org/itrpv-2026-solar-industry-maintains-historic-learning-curve-despite-market-turbulence/) | VDMA / ITRPV | 2026 | B |
| 33 | [Britisches Atomkraftwerk Hinkley Point C verzögert sich weiter und wird teurer - Atomstrom kostet mindestens 15 Cent pro Kilowattstunde](https://www.iwr.de/news/britisches-atomkraftwerk-hinkley-point-c-verzoegert-sich-weiter-und-wird-teurer-atomstrom-kostet-mindestens-15-cent-pro-kilowattstunde-news39541) | IWR-Pressedienst | 2026-02-23 | B |
| 34 | [Fonds zur Finanzierung der kerntechnischen Entsorgung — Kennzahlen und Jahresergebnis 2025](https://www.kenfo.de/) | KENFO | 2026 | A |
| 35 | [Apples and oranges: Comparing nuclear construction costs across nations, time periods, and technologies](https://www.sciencedirect.com/science/article/abs/pii/S0301421516306000) | Energy Policy 102, S. 650-654 | 2017 | A |
| 36 | [Bundes-Klimaschutzgesetz (KSG) § 3a - Nationale Klimaschutzziele für den Sektor Landnutzung, Landnutzungsaenderung und Forstwirtschaft](https://www.gesetze-im-internet.de/ksg/__3a.html) | Bundesrepublik Deutschland | 2021/2024 | B |
| 37 | [Levelized Cost of Energy+ (LCOE+), Version 19.0](https://www.lazard.com/media/sdvdrvc5/lazards-lcoeplus_vf.pdf) | Lazard | 2026-07-13 | B |
| 38 | [Levelized Cost of Energy+ (LCOE+), Version 18.0](https://www.lazard.com/media/uounhon4/lazards-lcoeplus-june-2025.pdf) | Lazard | 2025-06-16 | |
| 39 | LCOE+ v19.0 | Lazard | 2026-07 | A |
| 40 | [Analysen und Statistiken zu Dunkelflauten in Deutschland](https://www.lbbw.de/artikel/research-studien-2025/dunkelflaute_ake25jccd8_d.html) | LBBW Research | 2025 | B |
| 41 | [Historical construction costs of global nuclear power reactors](https://www.sciencedirect.com/science/article/pii/S0301421516300106) | Energy Policy 91, S. 371-382 | 2016-04 | A |
| 42 | Isar 2 Baukosten (4,75 Mrd. DM / 1400 MW) | im MD als IAEA INIS angegeben | | C |
| 43 | [Are nuclear power plants too expensive to build?](https://climate.mit.edu/ask-mit/are-nuclear-power-plants-too-expensive-build) | MIT Climate Portal | o.D. | |
| 44 | [Korea to resume construction of Shin Hanul 3&4](https://www.neimagazine.com/news/korea-to-resume-construction-of-shin-hanul-34-10946507/) | Nuclear Engineering International | o.D. | |
| 45 | [Netzentwicklungsplan Strom 2037 mit Ausblick 2045, Version 2025, 1. Entwurf](https://www.netzentwicklungsplan.de/sites/default/files/2025-12/NEP_2037_2045_V2025_1_Entwurf_0.pdf) | 50Hertz, Amprion, TenneT, TransnetBW | 2025-12 | A |
| 46 | [UK Announces Final Investment Decision For GBP38 Billion Sizewell C Nuclear Power Station](https://www.nucnet.org/news/uk-announces-final-investment-decision-for-gbp38-billion-sizewell-c-nuclear-power-station-7-2-2025) | NucNet | 2025-07 | |
| 47 | [Costs and timeframes of construction of nuclear power plants carried out by potential nuclear technology suppliers for Poland](https://pulaski.pl/wp-content/uploads/2021/06/Pulaski_Policy_Paper_No_6_2021_EN-1.pdf) | Casimir Pulaski Foundation, Policy Paper No. 6/2021 | 2021-06 | |
| 48 | [How long does it take to build a nuclear reactor?](https://hannahritchie.substack.com/p/nuclear-construction-time) | Hannah Ritchie (Sustainability by Numbers), auf Basis IAEA PRIS | 2023 | B |
| 49 | [Projected Electricity Costs in International Nuclear Power Markets](https://www.sciencedirect.com/science/article/am/pii/S0301421522001306) | Energy Policy (Elsevier) | 2022 | |
| 50 | [Stündliche SMARD-Exportdaten Deutschland Jul-Dez 2024 (GitHub-Mirror, Notlösung)](https://github.com/hakimdalim/smard-data-extractor) | SMARD / Bundesnetzagentur, über github.com/hakimdalim/smard-data-extractor | 2024 | C |
| 51 | [Beyond economies of scale: Learning from construction cost overrun risks and time delays in global energy infrastructure projects](https://www.sciencedirect.com/science/article/pii/S2214629625001380) | Energy Research & Social Science (Sovacool, Ryu) | 2025-03 | A |
| 52 | [Methodenkonvention 3.2 zur Ermittlung von Umweltkosten (CO2-Schattenpreise)](https://www.umweltbundesamt.de/publikationen/methodenkonvention-32-methodische-grundlagen) | Umweltbundesamt | 2020 | B |
| 53 | [Carbon Neutrality in the UNECE Region — Integrated Life-cycle Assessment of Electricity Sources](https://unece.org/sed/documents/2021/10/reports/life-cycle-assessment-electricity-generation-options) | UNECE | 2022 | A |
| 54 | [Kurzstudie Dunkelflauten (Zeitreihenanalyse 2016-2025)](https://www.pv-magazine.de/2026/06/01/uniper-dunkelflauten-sind-regelmaessiger-bestandteil-des-deutschen-stromsystems/) | Uniper SE | 2026-06 | A |
| 55 | [Kostensituation der Windenergie an Land - Stand 2025](https://www.windguard.de/veroeffentlichungen.html?file=files%2Fcto_layout%2Fimg%2Funternehmen%2Fveroeffentlichungen%2F2025%2FKostensituation+der+Windenergie+an+Land+%E2%80%93+Stand+2025.pdf) | Deutsche WindGuard i.A. BMWK | 2025-10 | B |
### Anmerkungen zu einzelnen Quellen
- **Nr. 1 · Nuclear reactors' construction costs: The role of lead-time, standardization and technological progress** — Oekonometrie über französische und US-amerikanische Reaktoren: Standardisierung senkt Bauzeit und Kosten, Designänderungen erhöhen beides. Ueber Suchindex-Auszüge erfasst, nicht im Volltext gelesen.
- **Nr. 2 · Kraftwerksstrategie / StromVKG - Grundsatzeinigung mit der Europaeischen Kommission und Kabinettsbeschluss** — Termine und Volumina der ersten beiden Ausschreibungsrunden nach research/ist_zustand_de.md 6.2.
- **Nr. 9 · Elektrolysekapazitäten in Deutschland** — Kapazitäts- und Projektdatenbank - weist KEINE Investitionskosten je kW aus. Die Zuordnung im MD ist eine Fehlzuordnung.
- **Nr. 14 · Revisiting the Cost Escalation Curse of Nuclear Power: New Lessons from the French Experience** — Erwiderung auf Grubler 2010: geringere Eskalation als dort berichtet, Belege für Lerneffekte und für eine kostensenkende Wirkung der Standardisierung. Ueber Suchindex-Auszüge erfasst, nicht im Volltext gelesen.
- **Nr. 15 · Auswirkungen und Preispfade des EU ETS2, Endbericht** — ETS 2, NICHT Stromsektor. Im MD fälschlich als Strom-CO2-Preis verwendet.
- **Nr. 16 · Von der Theorie zur Praxis: Warum grüner Wasserstoff teurer ist als gedacht (Discussion Paper)** — PDF in dieser Session durch den Netzwerk-Egress blockiert; Inhalte über Suchindex-Auszüge mit wörtlichen Zitaten verifiziert.
- **Nr. 21 · Der klimaneutrale Strommix der Zukunft — Eine Szenarioanalyse zu den Kosten des zukünftigen deutschen Stromsystems** — Volltext-PDF in der Arbeitsumgebung nicht abrufbar (Egress-Policy). Alle Studienwerte stammen aus der Aufbereitung in docs/01 und aus Suchindex-Zusammenfassungen, nicht aus selbst gelesenem Volltext.
- **Nr. 22 · Der klimaneutrale Strommix der Zukunft** — PDF in dieser Session durch den Netzwerk-Egress blockiert. Alle Aussagen zur Studien-Methodik beruhen auf der MD-Wiedergabe und konnten nicht am Original gegengeprüft werden.
- **Nr. 26 · Projected Costs of Generating Electricity - 2020 Edition** — Domain in dieser Session blockiert; LCOE-Calculator unter https://www.oecd-nea.org/lcoe/
- **Nr. 31 · Renewable Power Generation Costs in 2024** — BESS 192 USD/kWh (2024), minus 93 Prozent seit 2010; PV-Projektion rund 500 USD/kW für 2030 mit ausdrücklichem Europa-/Nordamerika-Vorbehalt.
- **Nr. 36 · Bundes-Klimaschutzgesetz (KSG) § 3a - Nationale Klimaschutzziele für den Sektor Landnutzung, Landnutzungsaenderung und Forstwirtschaft** — Senkenziele 25 Mt (2030), 35 Mt (2040), 40 Mt CO2-Aequivalent (2045). Ueber Suchindex-Auszüge und Sekundaerquellen erfasst, nicht am Gesetzestext im Volltext geprüft.
- **Nr. 39 · LCOE+ v19.0** — Speicherkosten seit 2020 um 27 Prozent gestiegen; LCOS 100 MW / 4 h 210-292 USD/MWh.
- **Nr. 41 · Historical construction costs of global nuclear power reactors** — 349 Reaktoren in 7 Ländern, 58 Prozent aller weltweit gebauten Blöcke, Overnight Construction Cost in konstanten USD 2010. NUR gemeinsam mit den beiden Erwiderungen zitieren.
- **Nr. 42 · Isar 2 Baukosten (4,75 Mrd. DM / 1400 MW)** — Eingangszahl nicht belegbar, Kostenabgrenzung unbekannt.
- **Nr. 50 · Stündliche SMARD-Exportdaten Deutschland Jul-Dez 2024 (GitHub-Mirror, Notlösung)** — Primärquellen (energy-charts, smard.de, OPSD) waren aus der Arbeitsumgebung per Egress-Policy nicht erreichbar.
- **Nr. 54 · Kurzstudie Dunkelflauten (Zeitreihenanalyse 2016-2025)** — Interessenlage: Uniper betreibt konventionelle Kraftwerke. 10-h-Schwelle statt DWD-48-h.
---
## Interaktive Fassung und weiterfuehrende Dateien
- Visual Story (scrollgetriebene Charts): https://datenwgknowledgekitchen.com/strommix-story.html
- Vollstaendige Analyse als interaktives White Paper: https://datenwgknowledgekitchen.com/whitepaper-strommix.html
- Markdown-Fassung des White Papers: https://datenwgknowledgekitchen.com/md/whitepaper-strommix.md
- Datenstand der Story: https://datenwgknowledgekitchen.com/strommix/data/story_data.json
- Maschinenlesbarer Index der Kitchen: https://datenwgknowledgekitchen.com/llms.txt
==============================================================================
DOKUMENT: https://datenwgknowledgekitchen.com/md/rhein-story.md
==============================================================================
# 209 Jahre, ein Fluss, zwei Wahrheiten
> Eine der laengsten Abflussreihen der Welt sagt: Dem Rhein geht es gut. Dieselben Daten sagen das Gegenteil. Beides stimmt — eine Analyse, wie ein Klimasignal im Rauschen untergeht und wie man es trotzdem findet.
- **Quelle:** https://datenwgknowledgekitchen.com/rhein-story.html
- **Autor:** Michael Tenner · Daten-WG Knowledge Kitchen
- **Extrahiert aus:** `rhein-story.html` · Stand 2026-08-16 (Git-Commit-Datum der Quelldatei)
- **Zitierhinweis:** Michael Tenner, Daten-WG Knowledge Kitchen, https://datenwgknowledgekitchen.com/rhein-story.html — Abruf mit Datum angeben. Weiterverwendung mit Quellenangabe erwuenscht.
- **Hinweis fuer Agenten:** Diese Markdown-Fassung enthaelt den Fliesstext der Seite. Interaktive Elemente (Regler, Filter, animierte Charts) sind nur in der HTML-Fassung nutzbar; die zugehoerigen Zahlen stehen hier als Tabelle.
- **Datengrundlage:** Global Runoff Data Centre (GRDC), BfG Koblenz; Originaldaten: WSV, Station KOELN / Rhein (GRDC 6335060), 1816-11-01 bis 2025-12-31, 76.397 gueltige Tageswerte
- **Reproduzierbarkeit:** alle Kennzahlen ueber `src/run_all.py` bzw. `src/export_viz_data.py` aus den GRDC-Rohdaten nachrechenbar. GRDC-Daten duerfen nur nicht-kommerziell genutzt und nicht weitergegeben werden.
---
Eine der längsten Abflussreihen der Welt sagt: Dem Rhein geht es gut. Dieselben Daten sagen das **Gegenteil**. Beides stimmt. Diese Geschichte zeigt, wie ein Klimasignal im Rauschen untergeht — **und wie man es trotzdem findet**.
## „Das gab es doch schon immer“
„Der Rhein trocknet aus!“, sagen die einen. „Panikmache — Dürren und Niedrigwasser gab es schon immer“, sagen die anderen. Wer hat recht?
Beide Seiten argumentieren meist mit Anekdoten: ein trockener Sommer hier, ein historisches Foto dort. Dabei liegt die Antwort längst vor — in einer Messreihe, die seit über zwei Jahrhunderten nicht abgerissen ist. Seit dem 1. November 1816 wird am Pegel Köln täglich der Wasserstand abgelesen — und daraus bestimmt, wie viel Wasser der Rhein wirklich führt. Nicht die Zentimeter-Marke, die die Schlagzeilen zitieren — sondern der **Abfluss in m³/s**, die physikalisch ehrliche Größe.
Und diese Reihe gibt — das ist das Überraschende — **beiden Seiten ein Stück weit recht**. Folgen wir den Daten. In sechs Akten.
### 2.510 Monate Chaos
Jede Zacke ein Monatsmittel. Hochwasser um 1926, 1993, 1995. Dürren 1921, 1947, 2018. Auf den ersten Blick: reines Rauschen.
### Die Jahresmittel glätten das Bild
Verdichtet man jedes Jahr auf einen Wert, bleibt eine Reihe, die um ≈ 2.080 m³/s pendelt — seit über zwei Jahrhunderten.
### Kein nachweisbarer Trend
Die Trendgerade: +9,6 m³/s pro Jahrhundert — statistisch nicht von Null zu unterscheiden (p = 0,83; heißt: Der Befund ist mit reinem Zufall bestens vereinbar). Aber nur im Jahresmittel.
Die Skeptiker haben also recht? **Moment.** Genau deshalb ist der Jahresmittelwert das falsche Suchbild — dazu gleich mehr.
An Heiligabend 1993 steigt der Pegel Köln auf 10,63 Meter, so hoch wie seit 1926 nicht mehr; die Flut überspült die neue Schutzmauer, rund 13.000 Kölner Haushalte sind betroffen — einschließlich der Schäden durch aufsteigendes Grundwasser. Nur 13 Monate später, am 30. Januar 1995, steigt das Wasser noch höher: 10,69 Meter — praktisch auf dem Niveau von 1926 und damit an der Spitze der modernen Messreihe; rund 1.740 Hektar Stadtgebiet stehen unter Wasser. Zwei Extremhochwasser binnen 13 Monaten: Seither gilt Winterhochwasser in Köln als wiederkehrendes Thema.
Archivbild zur Illustration: Rheinhochwasser am Kölner Altstadtufer, April 1983 — der Pegelturm steht mitten im Wasser · Foto: Günter Sers, Deutsches Bundesarchiv, CC BY-SA 3.0 DE, via Wikimedia Commons
## Wer nur den Mittelwert prüft, hat aufgehört zu fragen
Ein Fluss ist keine einzelne Zahl. Bevor wir „kein Trend“ zu den Akten legen, müssen wir wissen, *wie* dieser Fluss seine Wassermengen verteilt.
### Das Rauschen hat eine Form
Sortiert man alle 209 Jahre in Klassen, entsteht eine markante, schiefe Verteilung: ein steiler Berg bei niedrigen Abflüssen, ein langer Schwanz zu den Fluten.
### Mittelwert ≠ Median
Der Mittelwert (2.080) liegt deutlich über dem Median (1.840) — die seltenen Fluten ziehen ihn nach oben. Die Verteilung ist **stark rechtsschief**.
### Die Gauß-Glocke passt nicht
Der Rhein ist nicht „normal“ verteilt, sondern schief: viele mittlere Tage, ein langer Ausläufer seltener Fluten. In solchen Verteilungen können sich die Ränder dramatisch ändern, während der Mittelwert stillhält. Genau dort suchen wir weiter.
### Der alte Jahresgang
So floss der Rhein im 19. Jahrhundert (1821–1900 — hier runde Vergleichsfenster; die Extremwert-Rechnung in den Akten 5–6 nutzt die volle Referenzphase): viel Wasser im Winter und zur Schneeschmelze, ein trockener Spätsommer.
### Der neue Jahresgang kippt
Heute (1991–2025) ist der Januar um +620 m³/s (+29 %) angeschwollen, August und September sind um −330 / −281 m³/s gefallen. Das Muster passt zu einem wärmeren Alpenraum: mehr Regen statt Schnee, früherer Schmelz-Peak. Die alpine Speicherbewirtschaftung wirkt in dieselbe Richtung — an einem einzelnen Pegel lassen sich die Anteile nicht trennen.
### Dieselbe Jahressumme, andere Uhrzeit
Die Jahressumme bleibt fast gleich — deshalb sieht der Mittelwert nichts. **Das Wasser kommt im Winter, wenn niemand es braucht — und fehlt im Spätsommer, wenn Schifffahrt, Industrie und Kraftwerke davon abhängen.**
| Monat | Ø 1821–1900 (m³/s) | Ø 1991–2025 (m³/s) | Differenz |
|:---|---:|---:|---:|
| Jan | 2.168 | 2.787 | +619 |
| Feb | 2.371 | 2.587 | +216 |
| Mär | 2.420 | 2.476 | +56 |
| Apr | 2.199 | 2.088 | -111 |
| Mai | 2.070 | 2.077 | +7 |
| Jun | 2.219 | 2.137 | -82 |
| Jul | 2.115 | 1.845 | -270 |
| Aug | 1.922 | 1.592 | -330 |
| Sep | 1.763 | 1.483 | -280 |
| Okt | 1.697 | 1.515 | -182 |
| Nov | 1.904 | 1.872 | -32 |
| Dez | 2.220 | 2.373 | +153 |
### Zwölf Monate, zwölf Trends
Rechnet man den Trend für jeden Monat einzeln, zerfällt das „kein Trend“-Bild: Wintermonate steigen, Spätsommermonate fallen.
### Das ist kein Zufall
Januar +13,7 % (p = 0,006) · August −9,5 % (p = 0,001) · September −9,3 % (p = 0,002).
Der Test „alle Monate haben denselben Trend“ wird klar verworfen: p = 0,004.
### Warum die Jahresstatistik blind ist
Im Gesamttrend heben sich die gegenläufigen Monats-Signale fast vollständig auf: −0,6 % pro Jahrhundert (p = 0,80). Das „Rauschen“ aus Akt 1 war nie leer — es war die Überlagerung zweier gegenläufiger Signale.
| Monat | Trend %/100 Jahre | p-Wert (HAC) | signifikant (p<0,05) |
|:---|---:|---:|:---:|
| Jan | 13,7 % | 0,0062 | ja |
| Feb | 8,8 % | 0,0464 | ja |
| Mär | 1,2 % | 0,7803 | nein |
| Apr | 0,7 % | 0,8753 | nein |
| Mai | 1,8 % | 0,6052 | nein |
| Jun | -0,6 % | 0,8595 | nein |
| Jul | -6,0 % | 0,0596 | nein |
| Aug | -9,5 % | 0,0014 | ja |
| Sep | -9,3 % | 0,0021 | ja |
| Okt | -5,9 % | 0,1021 | nein |
| Nov | -2,7 % | 0,5447 | nein |
| Dez | 3,8 % | 0,4324 | nein |
### Die alte Spätsommer-Verteilung
Alle Aug/Sep-Tage von 1817–1920 als Verteilungskurve. Die trockensten 5 % lagen unter 1.090 m³/s — per Definition das alte P05.
### Aus P05 wird P14
Dieselbe Kurve für 1976–2025: kaum anders geformt — nur nach links gerutscht. Unter der *alten* 5-%-Schwelle liegen heute 14,3 % aller Tage. Was ein Ausnahmezustand war, ist fast **dreimal so häufig** geworden.
Trockentage klumpen in Dürrephasen: Der Anteil beschreibt das Ausmaß, nicht die Zahl unabhängiger Ereignisse.
### Reine Verschiebung, kein „wilder“ Fluss
Median −11 %, Streuung und Schiefe nahezu unverändert: Die Kurve behält ihre Form und wandert nur. Die Probe darauf: Rechnet man allein mit dieser Lageverschiebung, müssten heute rund 14,6 % der Tage unter dem alten P05 liegen — beobachtet sind es 13,9–14,3 %. Im Alltag ist die Verschiebung unsichtbar; am dünnen linken Rand entscheidet sie alles. Wie stark, zeigt der letzte Akt.
| Periode | Median m³/s | Anteil ≤ 1.090 m³/s (altes P05) |
|:---|---:|---:|
| 1817–1920 (frueh) | 1.690 | 5,0 % (Definition) |
| 1976–2025 (heute) | 1.500 | 14,3 % |
Am 23. Oktober 2018 fällt der Pegel Köln auf 69 Zentimeter — das damalige Rekordtief der modernen Messreihe. Buhnen und Uferbefestigungen liegen trocken; an der Rheingasse taucht zwei Tage zuvor sogar die sonst unsichtbare Mündung des Duffesbach aus dem Flussbett auf. Weil kaum noch Tiefgang bleibt, fahren Frachtschiffe nur mit einem Bruchteil ihrer Ladung. Was 1993 und 1995 zu viel war, ist jetzt zu wenig — sichtbar bis auf den Grund.
Freigelegte Duffesbach-Mündung bei Pegel 72 cm, Oktober 2018 · Foto: Marcus Bentfeld, CC BY-SA 4.0, via Wikimedia Commons
## Schön und gut — aber was heißt das konkret?
Ein paar Prozent Verschiebung klingen harmlos. Sind sie nicht. Denn an den Rändern einer schiefen Verteilung wirkt eine kleine Verschiebung wie ein Hebel.
Wir fitten eine Extremwertverteilung auf die Aug/Sep-Jahresminima der frühen Periode **1817–1920** und fragen: Wie oft treten deren „seltene“ Niedrigwasser-Schwellen in den letzten 50 Jahren (**1976–2025**) tatsächlich auf? Kein Modell-Zirkelschluss — am Ende wird schlicht *gezählt*.
Warum diese beiden Perioden? **1817–1920** ist eine lange Referenzphase vor dem großen alpinen Speicherausbau. **1976–2025** sind schlicht die jüngsten 50 Jahre.
### Die Spätsommer-Minima rutschen ab
Jeder Punkt: das trockenste Aug/Sep-Tagesmittel eines Jahres. Die rote Linie markiert, was früher ein **20-Jahres-Ereignis** war (892 m³/s). Früher (graue Punkte) wurde sie fast nie gerissen — heute reißt sie ständig: Zählen Sie die blauen Punkte darunter.
### Erwartet vs. gezählt
Graue Ringe: so oft *müsste* jede alte Schwelle in 50 Jahren fallen, wenn sich nichts geändert hätte. Rote Punkte: so oft fiel sie *tatsächlich* (1976–2025).
### Je seltener, desto härter der Hebel
Das alte 5-Jahres-Ereignis kommt ×1,9 so oft. Das alte 100-Jahres-Ereignis ×8. Das ist die Arithmetik dünner Verteilungsränder: Eine Lageverschiebung von gut 10 % im Spätsommer vervielfacht genau die Ereignisse, auf die Infrastruktur nie ausgelegt wurde.
Belastbarer Kern: die 5- bis 50-Jahres-Schwellen. Das ×8 beim Jahrhundertereignis (4 gezählte Fälle) ist als Größenordnung zu lesen, nicht als Messwert.
### Und die Hochwasser?
Gleiche Rechnung am oberen Rand: Auch alte Hochwasser-Schwellen fallen öfter — der nassere Winter wirkt. Bei den 5- bis 50-Jahres-Schwellen liegt der Faktor bei ×1,4–2, also deutlich schwächer als beim Niedrigwasser. Und bei den Jahrhundertereignissen (2 statt 0,5) sind die Zahlen zu klein für belastbare Aussagen.
| altes Niedrigwasser-Ereignis | Schwelle m³/s | erwartet in 50 J | gezaehlt | Faktor |
|:---|---:|---:|---:|---:|
| T5 | 1.053 | 10,0 | 19 | ×1,9 |
| T10 | 955 | 5,0 | 12 | ×2,4 |
| T20 | 891 | 2,5 | 11 | ×4,4 |
| T50 | 839 | 1,0 | 6 | ×6,0 |
| T100 | 813 | 0,5 | 4 | ×8,0 |
**Gegenprobe Hochwasser**
| altes Hochwasser-Ereignis | Schwelle m³/s | erwartet in 50 J | gezaehlt | Faktor |
|:---|---:|---:|---:|---:|
| T5 | 7.426 | 10,0 | 14 | ×1,4 |
| T10 | 8.313 | 5,0 | 9 | ×1,8 |
| T20 | 9.085 | 2,5 | 4 | ×1,6 |
| T50 | 9.979 | 1,0 | 2 | ×2,0 |
| T100 | 10.580 | 0,5 | 2 | ×4,0 |
## Wer hat also recht?
Beide — und keiner. Der Rhein trocknet nicht aus: Im Jahresmittel ist ein Klimasignal tatsächlich nicht nachweisbar, es geht im Rauschen unter. Aber bei genauer Betrachtung ist es da — als hochsignifikante Verschiebung der Jahreszeiten (p = 0,004), die ehemals seltene Niedrigwasser vervielfacht.
Was heißt das konkret? **Das alte 10- oder 20-Jahres-Niedrigwasser ist heute ein 4- bis 5-Jahres-Ereignis.** Für Reedereien, Werke, Kraftwerksbetreiber und Kommunen ist es damit kein Ausnahmefall mehr, sondern der neue Normalbetrieb — Ladepläne, Lagerhaltung und Kühlkonzepte müssen darauf ausgelegt sein.
Und **für die alten 50-Jahres-Ereignisse braucht es echte Pläne**: Was einmal in 50 Jahren erwartet war, trat in den letzten 50 Jahren sechsmal ein — im Schnitt also etwa alle acht Jahre. Für die Jahrhundert-Schwelle trägt die Datenlage nur die Richtung, nicht die Zahl: Auch sie fällt deutlich häufiger als früher. Wer Infrastruktur an der Statistik des 19. Jahrhunderts ausrichtet, plant für einen Fluss, den es so nicht mehr gibt.
Und die Verschiebung ist kein abgeschlossenes Kapitel. Sie passt zum Muster eines wärmeren Alpenraums: weniger Wasser wird als Schnee zwischengespeichert, mehr fließt gleich als Regen ab. Die alpine Speicherbewirtschaftung wirkt in dieselbe Richtung — beide Anteile sind mit einem Pegel allein nicht auseinanderzuhalten. Die Szenarien der Internationalen Kommission für die Hydrologie des Rheingebietes (KHR) erwarten, dass sich dieses Muster fortsetzt.
## Rekord-Watch: Tiefstmarke 650 m³/s
Der **Tiefstrekord** für August und September stammt aus dem Dürresommer **1947: 650 m³/s** — der niedrigste Spätsommer-Tageswert der ganzen Reihe (eigene Auswertung der GRDC-Tagesdaten). Im August 2022 verfehlte der Rhein ihn um **2 m³/s**.
Im August 2026 melden Medien erneut Rekord-Tiefstände. Sobald die amtlichen Abflussdaten vorliegen, entscheidet sich, ob eine 79 Jahre alte Marke fällt. Beweisen würde das wenig: Ein Rekord ist nur das, worauf alle schauen.
Am 16. August 2026 unterbietet der Kölner Pegel mit 46 Zentimetern (WSV-Messwert, ungeprüfter Rohwert) den 2018er-Tiefstand nochmals um mehr als 20 Zentimeter — nach einem ungewöhnlich frühen, trockenen Sommer. Am Südbrücken-Pfeiler liegt der Flussgrund frei; Frachtschiffe fahren kaum noch, und wenn, dann fast leer.
Aber Vorsicht, das ist der **Zentimeter-Rekord des Pegels, nicht der Abfluss-Rekord** — ein Teil der Differenz zu 2018 kann auch auf die Eintiefung der Flusssohle zurückgehen. Der Momentan-Abfluss lag am 16. August allerdings zeitweise bei rund **640 m³/s** — erstmals in Reichweite der 650er-Tagesmittel-Marke von 1947. Entschieden wird das erst mit den geprüften Tagesdaten.
Freigelegter Südbrücken-Pfeiler Anfang August 2026 — dahinter Kranhäuser und Dom · Foto: Leuni, CC BY-SA 4.0, via Wikimedia Commons
## Top 50 — wann kamen die Extreme wirklich?
Wären die letzten 30 Jahre pauschal „extremer“, müssten sie die Bestenlisten dominieren. Tun sie nicht — jedenfalls nicht dort, wo alle hinschauen.
Das ist kein Widerspruch zu Akt 6: Eine Bestenliste kürt nur die absolut extremsten Jahre der ganzen Reihe — dass eine *feste* Schwelle heute viel öfter gerissen wird, kann sie prinzipiell nicht zeigen. Beide Rechnungen messen Verschiedenes.
209 Jahre, drei Epochen. Wäre der Fluss stationär, bekäme jede Epoche ihren fairen Anteil an den 50 extremsten Jahren — proportional zu ihrer Länge. Erwartet vs. gezählt:
| Reihe | Epoche | erwartet | gezaehlt |
|:---|:---|---:|---:|
| Top 50 trockenste Jahre | vor 1920 | 24,6 | 29 |
| Top 50 trockenste Jahre | 1920–1995 | 18,2 | 17 |
| Top 50 trockenste Jahre | letzte 30 Jahre | 7,2 | 4 |
| Top 50 groesste Hochwasser | vor 1920 | 24,6 | 20 |
| Top 50 groesste Hochwasser | 1920–1995 | 18,2 | 23 |
| Top 50 groesste Hochwasser | letzte 30 Jahre | 7,2 | 7 |
Die 50 **trockensten Jahre** (gemessen am niedrigsten 7-Tage-Mittel eines Jahres) häufen sich im 19. Jahrhundert — die letzten 30 Jahre sind mit **4 von 50** eher *unter*- als überrepräsentiert. Der Unterschied liegt im Zufallsbereich — in dieselbe Richtung zeigt aber ein zweiter, diesmal signifikanter Befund: Das 100-jährliche *Jahres*-Tief stieg von **476 auf 563 m³/s** (instationäre Extremwert-Schätzung, p = 0,047). Die extremen Jahres-Tiefstwerte sind heute also entschärft, vermutlich durch Regulierung und Speicher. Der Kontrast zum Spätsommer wird dadurch nur schärfer: Selbst mit dieser Stützung häufen sich die Aug/Sep-Niedrigwasser. Die 50 größten **Hochwasser** treffen mit **7 von 50** fast exakt die Erwartung. Genau deshalb brauchte es die Akte 3–6: Das Klimasignal steckt nicht in den Jahres-Bestenlisten, sondern in der Verschiebung der Jahreszeiten — wer nur nach absoluten Rekorden sucht, wird es dort nie finden.
## Was diese Daten *nicht* sagen
Eine Analyse ist nur so glaubwürdig wie ihre Grenzen. Fünf Dinge gehören dazu:
#### Köln ≠ Deutschland
Der Rhein entwässert ein alpines Rieseneinzugsgebiet. Bodenfeuchte und Grundwasser vor Ort sind andere Messgrößen — „Dürre in Deutschland“ misst man nicht am Kölner Pegel.
#### Speicher wirken mit
Alpine Stauseen verlagern Wasser vom Sommer in den Winter — in dieselbe Richtung wie das Klima. Mit einem einzigen Pegel sind beide Effekte nicht sauber trennbar.
#### Pegelstand ≠ Abfluss
Die „Rekord-Zentimeter“ der Schlagzeilen sinken auch durch Sohlerosion. Diese Analyse nutzt durchgehend den Abfluss in m³/s.
#### Gletscher sind der kleinere Hebel
Gletschereis liefert im Jahresmittel nur 1–2 % — an einzelnen extremen Augusttagen aber bis zu einem Drittel bei Basel und, weiter flussab und damit näher an Köln, 17–21 % bei Kaub und Lobith. Der größere Klimahebel bleibt die Schneespeicherung.
#### 209 Jahre sind keine Laborreihe
Abfluss wird nicht direkt gemessen, sondern aus Wasserständen über Abflusskurven abgeleitet. Messpraxis, Rheinkorrektionen und Eichungen haben sich seit 1816 mehrfach geändert. Die GRDC/BfG-Reihe ist geprüft, aber die frühen Jahrzehnte tragen größere Unsicherheit.
## Methoden & Glossar — zum Nachprüfen
Dieser Anhang legt die Begriffe und Verfahren offen, auf denen die sechs Akte beruhen — für alle, die die Kette nicht glauben, sondern prüfen wollen. Sämtliche hier genannten Kennzahlen sind über **src/run_all.py** bzw. **src/export_viz_data.py** aus den GRDC-Rohdaten reproduzierbar.
Der p-Wert ist die Wahrscheinlichkeit, Daten wie die beobachteten (oder extremere) zu sehen, *wenn die Nullhypothese zutrifft* — hier also: wenn es gar keinen Trend gäbe. Er ist keine Wahrscheinlichkeit dafür, dass die Nullhypothese wahr ist.
Deshalb heißt p = 0,83 beim Jahresmittel: **kein nachweisbarer Trend** — nicht „bewiesene Null“. Ein hoher p-Wert ist Abwesenheit von Nachweis, nicht Nachweis von Abwesenheit.
Umgekehrt gilt Vorsicht beim Mehrfachtesten: Bei 12 Einzeltests (den Monats-Trends) sind allein durch Zufall rund 0,6 falschpositive Treffer auf dem 5-%-Niveau zu erwarten. Die Globalaussage hängt deshalb nicht an einzelnen Monaten, sondern am gemeinsamen Wald-Test (χ² ≈ 27; p = 0,004). Von den Einzelmonaten überstehen August und September auch die strenge Bonferroni-Korrektur, Januar (p = 0,006) die mildere FDR-Korrektur, Februar (p = 0,046) keine von beiden.
Abflüsse sind rechtsschief verteilt: Schiefe 2,08, Mittelwert 2.080 m³/s gegenüber Median 1.840 m³/s, Spannweite 401 bis 10.900 m³/s. Wenige sehr große Werte ziehen den Mittelwert nach oben, der Median bleibt liegen.
Eine lognormale Größe ist eine, die nach Logarithmieren annähernd normalverteilt ist. Genau deshalb rechnen wir die Trendregression auf log(Q) statt auf Q: Die Koeffizienten sind dann als **relative Änderung in Prozent** lesbar und die Fehlerstruktur ist näher an den Modellannahmen.
Der didaktische Kern: In schiefen Verteilungen können sich die Ränder stark ändern, während der Mittelwert stillhält. Wer nur auf den Mittelwert schaut, sieht die Bewegung am Rand nicht.
Geschätzt wird ein einziges Modell über alle Monatsmittel: log(Q) ~ Monats-Fixeffekte × Jahrestrend. Die Zeitvariable t ist auf 1921 zentriert und in Jahrhunderten skaliert, die Stichprobe umfasst n = 2.510 Monatsmittel. Der Interaktionsterm erlaubt jedem Monat seinen eigenen Trend.
Monatsabflüsse sind stark autokorreliert — nasse Phasen folgen auf nasse Phasen. Klassische OLS-Standardfehler wären deshalb zu optimistisch und die p-Werte zu klein. Korrigiert wird mit **Newey-West/HAC**, Lag 18.
Ergebnisse je Monat (Trend pro Jahrhundert, HAC-p):
- Januar +13,7 % · p = 0,006
- Februar +8,8 % · p = 0,046
- Juli −6,0 % · p = 0,060
- August −9,5 % · p = 0,001
- September −9,3 % · p = 0,002
Der Gesamttrend über alle Monate liegt bei −0,6 % pro Jahrhundert (p = 0,80) — also praktisch Null. Die entscheidende Frage ist deshalb nicht „gibt es einen Trend?“, sondern „ist der Trend in allen Monaten derselbe?“. Genau das prüft der Wald-Test, und er verwirft die Gleichheit: χ² ≈ 27, p = 0,004.
Daraus folgt der didaktische Schlusspunkt der ganzen Story: Summenstatistiken wie der saisonale Mann-Kendall-Test (p ≈ 0,6) sehen hier nichts — nicht weil nichts da wäre, sondern weil sich gegenläufige Monats-Trends in der Summe gegenseitig aufheben.
Die generalisierte Extremwertverteilung (GEV) beschreibt Blockextrema — hier die Jahres- bzw. Aug/Sep-*Minima* je Jahr, für die Hochwasser-Gegenprobe entsprechend die Jahres-*Maxima*. Minima werden gefittet, indem die Reihe negiert und als Maxima-Problem behandelt wird.
Die Parameter werden über **L-Momente nach Hosking** geschätzt, nicht über Maximum-Likelihood: Die MLE-Schätzung ist auf diesen Daten numerisch instabil und lieferte absurde Return-Level (in einem Lauf ein HQ100 in der Größenordnung 10¹¹ m³/s). L-Momente sind robust und für Reihen dieser Länge die belastbarere Wahl.
Das Return-Level zur Wiederkehrperiode T:
Mit Lageparameter ξ, Skalenparameter α und Formparameter k. Für T ≥ 100 ist die Extrapolation unsicher; empirisch verankert ist der Bereich T5–T50.
Das Verfahren in zwei Schritten. Erstens: Aus der frühen Periode (1817–1920) wird eine GEV gefittet und daraus werden Schwellen abgeleitet — das, was damals ein 5-, 10-, 20-, 50- oder 100-Jahres-Ereignis war. Zweitens: In den 50 Jahren 1976–2025 wird schlicht **gezählt**, wie oft diese feste Schwelle tatsächlich unterschritten (bzw. beim Hochwasser überschritten) wurde. Unter Stationarität wäre 50/T zu erwarten; der Faktor ist gezählt / erwartet.
Ergebnis: Niedrigwasser ×1,9 (T5) bis ×8,0 (T100), Hochwasser ×1,4 bis ×4,0. Beim Niedrigwasser wächst der Faktor monoton mit der Seltenheit, die absolute Zahl der Zusatzereignisse sinkt; beim Hochwasser ist der Verlauf unregelmäßiger.
Die ehrlichen Grenzen: Die Schwelle selbst stammt aus einem Modell — das Argument ist also nicht vollständig modellfrei, nur der Zählschritt ist es. Die Unsicherheit der Schwelle wird nicht in den Faktor propagiert. Und ab T ≥ 50 sind die Zählungen klein (6 bzw. 4 Ereignisse beim Niedrigwasser, 2 beim Hochwasser), sodass Poisson-Rauschen dominiert: Die Faktoren dort sind eine **Größenordnung, kein Messwert**.
Eine Verteilung kann sich auf zwei grundsätzlich verschiedene Arten ändern: in der **Lage** (Parameter μ — die ganze Kurve wandert) oder in **Skala und Form** (σ, Schiefe — die Kurve wird breiter, schwänziger, „wilder“). Der Unterschied ist der häufigste Streitpunkt in der Debatte, weil mehr Überschreitungen einer *festen* Schwelle bereits mechanisch aus einer reinen Lageverschiebung folgen.
Der Befund hier ist eindeutig: August und September zeigen fast reine Lageverschiebung — −13 % auf Monatsebene bzw. −11 % im Median der Tageswerte, bei stabiler Varianz und Schiefe. Im Winter steht eine Lageverschiebung von +620 m³/s bei unveränderter Skala und Form. Die Sommer-GEV-Skala schrumpfte sogar (354 → 222), mutmaßlich durch Speicherpufferung.
Konsistenzprobe: Rechnet man *allein* mit einer lognormalen Lageverschiebung, ergäbe sich eine Unterschreitung des alten P05 von rund 14,6 % — beobachtet sind 13,9–14,3 % (je nach Zählweise: unter bzw. bis einschließlich der Schwelle). Der Fluss wird also nicht wilder, er wandert.
- **NM7Q** — das niedrigste gleitende 7-Tage-Mittel eines Jahres. Der Standard-Kennwert für Niedrigwasser, weil er kurze Messausreißer glättet und trotzdem die Trockenphase abbildet.
- **HQ100 / NQ100** — das 100-jährliche Hochwasser bzw. Niedrigwasser: der Abfluss, der statistisch im Mittel einmal in 100 Jahren erreicht wird (aus der GEV, siehe oben).
- **P05** — das 5-%-Quantil: der Wert, den nur 5 % aller betrachteten Tage unterschreiten. Hier für Aug/Sep der frühen Periode: 1.090 m³/s.
- **Tagesmittel vs. Momentanwert** — diese Analyse arbeitet durchgehend mit geprüften Tagesmitteln. Ein Momentanwert kann kurzzeitig deutlich tiefer liegen als das Tagesmittel desselben Tages; beide sind nicht direkt vergleichbar.
- **Pegelstand (W, in cm) vs. Abfluss (Q, in m³/s)** — gemessen wird der Wasserstand, gebraucht wird die Wassermenge. Die Umrechnung erfolgt über die **W-Q-Beziehung** (Abflusskurve) der Station. Weil sich die Flusssohle eintieft, kann derselbe Abfluss über die Jahrzehnte zu immer niedrigeren Zentimeter-Werten gehören — „Rekord-Pegel“ in der Presse ist deshalb nicht dasselbe wie „Rekord-Abfluss“.
Grundlage ist die Station 6335060 (KOELN / Rhein) des Global Runoff Data Centre, Tageswerte vom 01.11.1816 bis 31.12.2025 mit 76.397 gültigen Werten (Fehlwerte −999 ausgeschlossen). Jahreskennzahlen werden nur für Jahre mit mindestens 360 Tageswerten berechnet, damit angeschnittene Randjahre die Statistik nicht verzerren. Monatsmittel werden aus den Tagesdaten selbst aggregiert.
Zwei Vergleichsfenster, bewusst unterschiedlich gewählt: Der Jahresgang (Akt 3) nutzt die runden Kalenderfenster 1821–1900 gegen 1991–2025. Die Extremwertanalyse (Akte 5–6) braucht möglichst viele Extremjahre und nutzt deshalb die lange Referenzphase 1817–1920 — vor dem großen alpinen Speicherausbau — gegen die jüngsten 50 Jahre 1976–2025.
Homogenitäts-Caveats: Abfluss wird nicht direkt gemessen, sondern über die W-Q-Beziehung aus Wasserständen abgeleitet; Messpraxis, Eichungen und die Rheinkorrektionen haben sich seit 1816 mehrfach geändert. Die GRDC/BfG-Reihe ist geprüft, die frühen Jahrzehnte tragen aber größere Unsicherheit.
Reproduktion: **src/run_all.py** erzeugt alle Kennzahlen als Konsolen-Report, **src/export_viz_data.py** die Datengrundlage dieser Seite. Die Rohdaten selbst sind nicht Teil dieser Seite — GRDC-Daten dürfen nur nicht-kommerziell genutzt und nicht an Dritte weitergegeben werden; Bezug kostenfrei nach Registrierung über [portal.grdc.bafg.de](https://portal.grdc.bafg.de).
---
## Kennzahlen im Ueberblick (maschinenlesbar)
| Kennzahl | Wert |
|:---|---:|
| Trend Jahresmittel | +9,6 m³/s pro Jahrhundert |
| p-Wert Jahresmittel-Trend | 0,83 |
| Gesamttrend ueber alle Monate | -0,6 % pro Jahrhundert (p = 0,8) |
| Wald-Test „alle Monate gleicher Trend“ | p = 0,004 — verworfen |
| Mittelwert / Median Tagesabfluss | 2.080 / 1.840 m³/s |
| Schiefe der Verteilung | 2,08 |
| Spannweite | 401 bis 10.900 m³/s |
| Median Aug/Sep frueh → heute | 1.690 → 1.500 m³/s (-11,2 %) |
| GEV-Referenzperiode / Zaehlperiode | 1817–1920 / 1976–2025 (50 Jahre) |
==============================================================================
DOKUMENT: https://datenwgknowledgekitchen.com/md/koelner-raser-story.md
==============================================================================
# Köln blitzt. 445.483 Mal.
> Ein Jahr Tempoverstöße der Stadt Köln (2025), jeder einzelne mit Uhrzeit, Ort und Herkunft: wann und wo in Köln geblitzt wird, wer ins Netz geht und wie schnell ein neuer Blitzer wirkt.
- **Quelle:** https://datenwgknowledgekitchen.com/koelner-raser-story.html
- **Blogbeitrag:** https://datenwgknowledgekitchen.com/koelner-raser-post.html
- **Autor:** Michael Tenner · Daten-WG Knowledge Kitchen
- **Extrahiert aus:** `koelner-raser-story.html` · Version 3.1 (Karten-Akt, überarbeitet nach Peer-Review) · Stand 2026-09-26
- **Zitierhinweis:** Michael Tenner, Daten-WG Knowledge Kitchen, https://datenwgknowledgekitchen.com/koelner-raser-story.html, Abruf mit Datum angeben. Weiterverwendung mit Quellenangabe erwuenscht.
- **Hinweis fuer Agenten:** Diese Markdown-Fassung enthaelt die Befunde der Seite. Die animierten Charts, die Karte und der durchsuchbare Raser-Atlas (alle 655 Messstellen) sind nur in der HTML-Fassung nutzbar; die zentralen Zahlen stehen hier als Tabelle.
- **Datengrundlage:** Stadt Koeln, Offene Daten Koeln, „Geschwindigkeitsueberwachung Koeln ab 2025“ + Standorttabellen sloc-01/02/04/11, Datenlizenz Deutschland – Zero – 2.0; 451.676 Zeilen, davon 445.483 Tempofaelle (ohne Rotlichtfaelle der Kreuzungsanlagen). Nur die staedtische Ueberwachung, keine Polizeimessungen. Karte: © OpenStreetMap-Mitwirkende (ODbL), Geocodierung Geoapify
- **Reproduzierbarkeit:** `koeln-raser/scripts/build_db.py` (SQLite) → `build_story_data.py` (SQL-Kennzahlen + Karte aus `data/geo/`) → `build_story_html.py`; `check_numbers.py` prueft die Textzahlen gegen die Daten. Geodaten einmalig lokal: `fetch_geo.py` → `check_geo.py`. Jede Zahl stammt aus `koeln-raser/data/story_data.json`.
---
## Prolog · Alle 71 Sekunden
So oft hat es 2025 in Köln im Schnitt geblitzt, Tag und Nacht, das ganze Jahr: 1.221 Fälle am Tag. Die Stadt veröffentlicht jede Verwarnung und jedes Bußgeldverfahren als Zeile: Datum, Uhrzeit, gemessene Geschwindigkeit, vorwerfbare Überschreitung, Fahrzeugart, Messstelle und das Kürzel des Zulassungsbezirks.
Wichtigste Regel: **Ein Blitz zählt nicht die Raser. Er zählt die Raser, die dort vorbeikommen, wo die Stadt gerade misst.**
## Akt 1 · Der Takt
- Feste Anlagen (43 Standorte): **231.143** Fälle, rund um die Uhr, an allen 365 Tagen. Samstags und sonntags lösen sie **45 % öfter** aus als montags (naheliegend: weniger Stau, freiere Fahrt). Hellster Tag: 20. Dezember (1.562 Fälle), zwei Tage nach dem Start zweier neuer Messstellen an der A 4, Anschluss Eifeltor.
- Mobile Messung (600 Standorte): **203.278** Fälle, stark unter der Woche. An **18 Tagen** keine mobile Messung, darunter die komplette Zeit vom 20. bis 31. Dezember.
- Fazit: Die Fallzahl misst mindestens so sehr den Messaufwand wie das Fahrverhalten. Belastbar sind Anteile und die festen Anlagen.
## Akt 2 · Die Uhr (nur feste Anlagen)
| Stunde | Fälle | Anteil ≥ 21 km/h zu viel | Anteil ≥ 31 km/h zu viel |
|---|---:|---:|---:|
| 03 Uhr | 3.628 | 8,0 % | 2,5 % |
| 11 Uhr | 13.595 | 2,5 % | 0,35 % |
| 14 Uhr | 11.992 | 1,7 % | 0,12 % |
Robuster als zwei Einzelstunden: Nacht (22–6 Uhr) gegen Tag (10–18 Uhr), je Anlage bereinigt. Der Anteil ab 21 km/h ist nachts **2,3-mal**, ab 31 km/h **4,1-mal** so hoch. Nur innerorts (Tempo ≤ 50): ab 31 km/h 1,45 % um 3 Uhr gegen 0,10 % um 14 Uhr. In absoluten Zahlen 292 gegen 207 schwere Fälle übers Jahr, nachts aber bei einem Bruchteil des Verkehrs.
## Akt 3 · Die Orte (feste Anlagen)
| Anlage | Limit | Fälle 2025 | Fälle pro Betriebstag |
|---|---:|---:|---:|
| B 55a · Ausfahrt Frankfurter Str. → Olpe (ab 14.08.) | 80 | 25.612 | 186,9 |
| Innere Kanalstraße · Höhe Lentstraße → Niehler Str. (regulär ab 15.05.) | 50 | 24.963 | 107,6 |
| Kaiser-Wilhelm-Ring 17–21 → Christophstr. | 30 | 16.376 | 45,0 |
| A 4 · AS Köln-Eifeltor → Olpe (ab 18.12., nur 9 Tage) | 60 | 1.914 | 212,7 |
Die beiden Spitzenreiter liegen auf derselben Achse (Innere Kanalstraße, Zoobrücke, B 55a), beide in Fahrtrichtung Osten; an der Inneren Kanalstraße stehen sechs Anlagen. Katalogwert aller Fälle: rund **18 Mio. €**, im Schnitt 40 € pro Fall. Das ist keine Einnahme (ohne Gebühren, Rotlicht, Einstellungen, Einsprüche); neun von zehn Fällen sind Verwarnungsgelder.
## Akt 4 · Köln bei Nacht (Karte)
- **Feste Anlagen:** 16 der 43 Anlagen stehen höchstens 3 km vom Dom entfernt und erzeugen 57,8 % aller Fälle fester Anlagen.
- **Mobile Messung:** Messstellen in 78 von 86 Stadtteilen, die meisten in Neustadt/Süd (26), Dellbrück (23) und Mülheim (20).
- **24 Stunden im Zeitraffer:** Um 11 Uhr blitzt es am Durchschnittstag rund 90-mal pro Stunde, mehr als die Hälfte mobil. Um 3 Uhr sind es 13, davon 75 % an festen Anlagen.
- **Wo die Messungen die Schnellsten erwischen:** Anteil der mobilen Fälle mit 21 km/h und mehr zu viel, nur ab 30 solchen Fällen an mindestens 3 Messstellen (46 Stadtteile), in drei Klassen ohne Rangliste. Köln-weit 2,8 %. Oft prägt eine Stelle den Wert: In Merkenich kommen 85 % der schweren Fälle von einer Tempo-10-Strecke, in Eil 94 % von einer Stelle an der Bensberger Straße. Die Werte beschreiben Messstellen, nicht Anwohner.
**Geocodierung:** Die Standorttabellen nennen nur Adressen. Geoapify mit Plausibilitätsprüfung (Straße und Stadtteil müssen passen) plus zweiter Punkt aus OpenStreetMap; alle festen Anlagen und Kreuzungen einzeln geprüft. Von 655 Messstellen: 433 punktgenau (66,1 %), 144 auf Straßenebene bis ±1 km (22,0 %), 52 von Hand verortet (7,9 %), 26 ohne verlässlichen Punkt (7.036 Fälle) weggelassen.
## Akt 5 · Die Lernkurve
| B 55a (Fälle pro Tag) | Woche 0–1 | Woche 12–19 | Veränderung |
|---|---:|---:|---:|
| alle | 443 | 127 | −71 % |
| davon K-Kennzeichen | 201 | 44 | −78 % |
| davon andere | 242 | 82 | −66 % |
| 27 Anlagen im Bestand (Kontrolle) | | | −5 % |
Der Anteil mit 21 km/h und mehr zu viel sinkt an der B 55a von 13,0 % auf 5,9 %. Die Jahreszeit erklärt den Rückgang nicht, die Anlagen im Bestand bleiben stabil. Aber nicht jede neue Anlage wirkt so: Innere Kanalstraße −59 % (größter Teil abrupt Mitte August, Ursache offen), die kleineren neuen Anlagen 2025 zwischen −22 % und +29 %. Was hinter dem Kasten passiert (wieder beschleunigen, ausweichen), zeigen die Daten nicht. Das Kennzeichen nennt den Halter, nicht den Fahrer.
## Akt 6 · Die Ortskundigen
| Messart | Köln (K) | Umland (BM, GL, SU, NE, LEV) | übriges Deutschland | ohne/sonstige |
|---|---:|---:|---:|---:|
| alle | 48,5 % | 19,6 % | 28,8 % | 3,0 % |
| mobil | 60,8 % | 18,1 % | 19,9 % | 1,3 % |
| fest | 37,5 % | 20,9 % | 36,9 % | 4,6 % |
Viel erklärt, wo gemessen wird: feste Anlagen an Hauptachsen mit Einpendlern, mobil vor allem in Wohnstraßen (84 % bei Tempo 30). Dazu eine Hypothese, die zu Akt 5 passt: Einen festen Blitzer kennt, wer von hier ist. 648 verschiedene deutsche Kennzeichen-Kürzel.
## Akt 7 · Wie schnell?
- Häufigster Wert: **6 km/h** zu viel nach Toleranzabzug (20,5 % aller Fälle); darunter praktisch keine Fälle, bei Tempo 30 also erst ab 39 km/h gemessen. Kein Freibrief: Die Schwelle ist Praxis, kein Recht. 68 % der Fälle liegen bei 6–10 km/h.
- **96,9 %** bleiben bei höchstens 20 km/h (keine Punkte), 90,2 % bei höchstens 15 km/h (Verwarnungsgeld). 13.615 Fälle (3,1 %) bringen Punkte.
- 1.697 Fälle erreichen Fahrverbots-Tempo (innerorts ab 31, außerorts ab 41 km/h zu viel); zählt man Tempo 60–80 als innerorts, bis zu 2.307. 61,6 % aller Fälle passieren bei Tempolimit 30.
## Epilog · Die Ausreißer
| Datum | Uhrzeit | Ort | Limit | gemessen | zu viel |
|---|---|---|---:|---:|---:|
| 30.04.2025 | 19:20 | Raderthalgürtel (Vorabend des 1. Mai, Pkw) | 50 | 203 | 146 |
| 17.08.2025 | 06:20 | B 55a, Ausfahrt Frankfurter Str. (drei Tage nach Start) | 80 | 191 | 105 |
| 18.09.2025 | 03:38 | Aachener Straße 327-285 | 50 | 154 | 99 |
| 04.11.2025 | 23:10 | Sachsenring | 30 | 133 | 99 |
## Fazit
Die Summe beschreibt vor allem, wo und wann die Stadt misst. Robust sind die Verhältnisse: nachts deutlich mehr schwere Fälle (2,3- bzw. 4,1-mal, je Anlage bereinigt), ein neuer Blitzer wirkt an der Messstelle (B 55a −71 % bei stabilem Bestand), und 97 % der Fälle liegen höchstens 20 km/h drüber. Eine Frage an die Stadt: Mobil wird zu 90 % tagsüber und zu 80 % werktags gemessen, die schweren Verstöße passieren vor allem nachts.
## Grenzen
Messaufwand ≠ Raserei · keine Verkehrsmengen im Nenner · keine Unfalldaten · nur die Stadt, keine Polizeimessungen · Kennzeichen = Halter · Tempolimit aus Messwert, Überschreitung und Toleranz abgeleitet (stimmt zu 98,2 % mit den Standorttabellen überein) · Bußgeld = Katalogwert, keine Einnahme · Orte teils ungefähr (22 % nur auf Straßenebene, 26 Messstellen ohne Punkt) · Dienststellen-Codes (S-01 fest, S-02 mobil, K-04 Kreuzung) aus dem Verhalten der Daten gedeutet · Presseberichte nannten 451.735 Fälle, Abgrenzung und Datenstand können abweichen.
==============================================================================
DOKUMENT: https://datenwgknowledgekitchen.com/whitepaper-ki-entwicklung-roi.md
==============================================================================
# Zehn Tage bis zum marktfähigen Stand
## Ein Bewertungsmodell für KI-gestützte Software-Entwicklung in festen Frameworks — transparent durchgerechnet an einer realen Fallstudie
**Ein empirisch gestütztes Thesenpapier · Michael Tenner, Daten-WG · Juli 2026 · v2.2**
---
## Management Summary
> **Die Hauptthese [M]:** Unter fünf Randbedingungen — festes Framework,
> Domänenexpertise in der Steuerung, kleine Iterationen, schnelle lokale
> Verifikation, konsequente Versionskontrolle — steigt die Produktivität
> KI-gestützter Entwicklung nicht um Prozente, sondern um Größenordnungen.
> Die Formel lautet nicht „KI schafft das", sondern **KI × Framework ×
> Domänenexpertise × Versionskontrolle**. Dieses Papier belegt das an einem
> vollständig dokumentierten Fall und liefert das Bewertungsmodell dazu.
> Die eigentliche Innovation ist dabei nicht die KI selbst, sondern ihre
> ökonomische Konsequenz: Sie verändert die Kostenstruktur der
> Software-Entwicklung — und zwingt damit die Build-vs.-Buy-Logik zur
> Neubewertung.
*Evidenz-Kennzeichnung in diesem Papier: [M] gemessen · [A] Annahme ·
[S] Schätzung/Modellrechnung · [H] Hypothese — Details unter „Begriffe &
Prämissen".*
**Worum es geht.** Dieses Papier schlägt ein **Bewertungsmodell für
KI-gestützte Software-Entwicklung** vor und rechnet es an einer vollständig
dokumentierten Fallstudie durch: Ein einzelner Controlling-Experte — kein
Entwicklerteam — hat in **zehn Kalendertagen** ein Berichts-Werkzeug für
Microsoft Power BI bis zu einem marktfähigen Entwicklungsstand gebaut.
Derselbe Stand wird — nach drei anerkannten Schätzverfahren — klassisch auf
**14–18 Personenmonate** und **150.000–350.000 €** taxiert [S]. Fallstudie,
Historie und Methodik sind vollständig öffentlich [M].
**Was es tatsächlich gekostet hat.** Rund **20 Stunden dokumentierte
Steuerungszeit** des Fachexperten (Sitzungsprotokolle; Denk- und
Recherchezeit außerhalb der Sitzungen ist nicht erfasst — die
Sensitivitätsrechnung in Kapitel 4 rechnet deshalb bis 120 Stunden durch)
plus etwa 180 € Werkzeugkosten. Je nach Stundensatz (250 €/h extern,
100 €/h intern) liegt der Invest bei **~5.200 €** bzw. **~2.200 €** — ein
Kostenhebel von 29 bis 161 gegenüber dem Wiederbeschaffungswert. Wichtig
zur Einordnung: Dieser Vergleich stellt den erreichten Ist-Stand einem
klassischen Vollprozess gegenüber und ist insoweit asymmetrisch — eine
symmetrische Gegenrechnung (Kapitel 4) drückt den Hebel auf **13 bis 93**,
ändert die Größenordnung der Aussage aber nicht. Bewusst sprechen wir vom
**Kostenhebel (Cost Avoidance)**, nicht von „ROI": Ein ROI setzt
realisierte Erträge voraus; hier werden vermiedene Wiederbeschaffungskosten
ins Verhältnis zum Invest gesetzt (Begriffe & Prämissen).
**Warum das mehr als eine Anekdote ist.** Das Ergebnis beruht nicht auf
Glück, sondern auf drei reproduzierbaren Bedingungen: einem festen
Software-Framework mit klaren Regeln (Kapitel 7), einem Fachexperten, der
präzise formulieren kann, was gebaut werden soll, und disziplinierter
Versionskontrolle, die jeden Schritt prüfbar und rückgängig machbar hält
(Kapitel 8). Wo diese Bedingungen vorliegen, ist das Muster übertragbar —
und dann geraten etablierte Kalküle unter Druck: die
Build-oder-Buy-Entscheidung, die Verhandlungsposition in Lizenzgesprächen
und die Preissetzungsmacht von Software-Anbietern. Zugleich gilt: Die
Evidenzbasis ist **eine einzelne Fallstudie**. Was am Fall gemessen ist und
was daraus abgeleitete Hypothese über mögliche Marktwirkungen ist, wird im
Papier durchgängig getrennt ausgewiesen.
**Für wen das relevant ist.** CFOs und Controlling-Leitungen (Lizenzkosten,
Verhandlungsposition), IT- und BI-Verantwortliche (was intern machbar wird,
Governance in Kapitel 9), Software-Anbieter (wo ihr Geschäftsmodell unter
Druck geraten könnte) und Beratungen (wohin der Wert wandert). Kapitel 12
fasst die Handlungsoptionen je Rolle zusammen.
| Kernergebnis | Wert | Evidenz |
| --- | --- | :-: |
| Tatsächlicher Invest (externer Experte, 250 €/h) | **~5.200 €** | [M] · [A] |
| Tatsächlicher Invest (interner Experte, 100 €/h) | **~2.200 €** | [M] · [A] |
| Klassischer Wiederbeschaffungswert (3 Verfahren, Anhang B) | **150.000–350.000 €** | [S] |
| Kostenhebel, Ist-Stand-Vergleich | **29–67×** (extern) · **69–161×** (intern) | [S] |
| Kostenhebel symmetrisch (gleicher Leistungsumfang, Kapitel 4) | **13–39×** (extern) · **31–93×** (intern) | [S] |
| Kalenderzeit: **10 Tage** | statt geschätzt 6–12 Monaten klassisch | [M] · [S] |
**Die fünf Kernthesen:**
1. **KI × Framework × Domänenexpertise — nicht KI allein:** Feste
Frameworks mit definierten Schnittstellen, Sandbox und
Zertifizierungsregeln reduzieren die Freiheitsgrade so weit, dass
KI-Entwicklung kontrollierbar und reproduzierbar wird. Das ist die
zentrale These dieses Papiers (Kapitel 7). [M]
2. **Git ist das unterschätzte Fundament:** Ohne Versionskontrolle wird
KI-Iterationsgeschwindigkeit zur Haftung. Mit ihr wird jeder Schritt
rückrollbar, prüfbar — und die gesamte Analyse dieses Papiers erst
möglich (Kapitel 8). [M]
3. **Die Build-oder-Buy-Rechnung verschiebt sich** für Framework-Software:
Nach Barwert schlägt der Eigenbau (oder die Adoption eines freien
Community-Builds) das Lizenzmodell ab mittlerer Nutzerzahl deutlich —
eine Rechnung unter offengelegten Annahmen (Kapitel 5). [S]
4. **Verhandlungsmacht-Hypothese:** Ein glaubwürdiges freies Werkzeug
könnte Lizenzverhandlungen zu Gunsten des Kunden verschieben, ohne dass
gewechselt werden muss (Kapitel 6). [H]
5. **Markt-Hypothese:** Open Source und KI könnten sich wechselseitig
verstärken — KI macht Community-Software pflegbar, offener Code macht
KI präzise — und den Entwicklungskosten-Vorsprung kommerzieller
Anbieter verringern (Kapitel 10). [H]
*Zum Evidenzstatus der Thesen:* These 1 und 2 sind am Fall direkt belegt.
These 3 ist eine Rechnung unter offengelegten Annahmen. These 4 und 5
extrapolieren vom Einzelfall auf Markt-Ebene — sie sind als **begründete
Hypothesen über mögliche Auswirkungen** zu lesen, nicht als nachgewiesene
Effekte (Einordnung in Kapitel 6, 10 und 11).
---
## Begriffe & Prämissen — was Sie zum Lesen brauchen
Dieses Papier richtet sich ausdrücklich auch an Leserinnen und Leser ohne
Entwicklungs-Hintergrund. Acht Begriffe genügen:
| Begriff | Bedeutung in diesem Papier |
| --- | --- |
| **Power-BI-Custom-Visual** | Ein Zusatzmodul für Microsofts Berichts-Plattform Power BI, das eigene Diagramm- und Tabellentypen nachrüstet — vergleichbar einer App auf einem Smartphone: läuft nur innerhalb der Plattform, nach deren Regeln. |
| **IBCS** | International Business Communication Standards — ein verbreiteter Notationsstandard für Geschäftsberichte (einheitliche Szenario-Muster, Varianzdarstellungen, „weniger Deko, mehr Aussage"). |
| **KI-gestützte Entwicklung („Vibe Coding")** | Ein Mensch beschreibt in normaler Sprache, was die Software können soll; ein KI-Agent schreibt, testet und dokumentiert den Code. Der Mensch prüft Ergebnisse und steuert nach — er tippt keinen Code. |
| **Product Owner (PO)** | Die steuernde Fachperson: formuliert Anforderungen, beurteilt Ergebnisse, entscheidet Prioritäten. Hier: ein Controlling-/BI-Experte ohne Entwicklerteam. |
| **Open Source (Apache 2.0)** | Der Quellcode ist öffentlich und darf kostenlos genutzt, geprüft und verändert werden. Die Lizenz Apache 2.0 erlaubt auch kommerziellen Einsatz. |
| **Git / Versionskontrolle** | Ein Protokollsystem, das jeden Änderungsschritt („Commit") dauerhaft festhält und rückgängig machbar hält — das Logbuch und Sicherheitsnetz der Software-Entwicklung. |
| **Kostenhebel (Cost Avoidance)** | Verhältnis der vermiedenen Kosten (Wiederbeschaffungswert) zum tatsächlichen Invest. „29×" heißt: Der Wiederbeschaffungswert entspricht dem 29-Fachen des Invests. Bewusst nicht „ROI" genannt — ein ROI setzt realisierte Erträge voraus, hier werden vermiedene Ausgaben verglichen. |
| **Barwert (DCF)** | Zukünftige Zahlungen (z. B. fünf Jahre Lizenzgebühren), mit einem Zinssatz auf heute abgezinst — die betriebswirtschaftlich korrekte Basis für Build-vs-Buy-Vergleiche. |
**Evidenz-Kennzeichnung:** Größere Aussagen tragen in diesem Papier ein
Kürzel: **[M]** = gemessen — aus Git-Historie, Sitzungsprotokollen oder
Rechnungen. **[A]** = Annahme — gesetzt und begründet, z. B. Stundensätze.
**[S]** = Schätzung oder Modellrechnung — aus [M] und [A] abgeleitet, z. B.
Wiederbeschaffungswert, Kostenhebel, Barwerte. **[H]** = Hypothese —
Extrapolation über den Einzelfall hinaus. Die Kürzel machen auf einen Blick
sichtbar, worauf jede Aussage steht.
**Die Prämissen der Rechnung — vorab in aller Klarheit:**
1. **Die Fallstudie ist exemplarisch.** Belegt wird jede Zahl an einem
konkreten Projekt — einem Power-BI-Custom-Visual für Controlling-Berichte.
Das Muster gilt aber für eine ganze Klasse von Software: alles, was
innerhalb eines festen Frameworks mit definierten Schnittstellen lebt
(Office-Add-ins, IDE-Extensions, Plattform-Plugins, interne
Fachwerkzeuge). Wer „Visual" liest, darf „unser Werkzeug X" denken.
2. **Die Projektzahlen sind Messwerte, keine Schätzungen:** Kalendertage,
Commits, Releases und Code-Umfang stammen aus der öffentlichen
Git-Historie; Token- und Werkzeugkosten aus dem Session-Protokoll und
Rechnungen (Anhang A).
3. **Die Stundensätze sind Annahmen:** 250 €/h für einen erfahrenen externen
Berater (Marktsatz), 100 €/h interner Vollkostensatz. Beide Rechnungen
werden durchgängig nebeneinander geführt.
4. **Die klassischen Vergleichskosten sind eine Schätzung** — bottom-up in
Personenmonaten, bewusst als breite Spanne (150–350 T€), ohne eingeholte
Angebote. Die Kernaussagen überleben auch das untere Ende der Spanne.
5. **Der Lizenzvergleich nutzt öffentliche Preisindikationen** kommerzieller
IBCS-Visual-Suiten (7–12 €/Nutzer/Monat), über 5 Jahre mit 8 % abgezinst.
6. **Der Evidenzstand ist eine Fallstudie (n = 1).** Kapitel 1–5 beruhen
auf Messwerten und offengelegten Rechnungen zu diesem einen Projekt.
Kapitel 6, 10 und Teile von 12 leiten daraus Hypothesen über mögliche
Markt- und Verhandlungseffekte ab — sie sind konditional formuliert und
wären erst durch weitere, unabhängige Fälle zu erhärten.
7. **Der Basisvergleich ist bewusst als Ist-Stand-Vergleich gerechnet** —
der klassische Prozess mit vollem Overhead (Doku, QA, Abnahme,
Projektmanagement), der KI-Build im erreichten Stand ohne diese Anteile.
Diese Asymmetrie wird nicht nur benannt, sondern in Kapitel 4
symmetrisch gegengerechnet.
8. **Interessenlage:** Die Daten-WG ist Herausgeberin des beschriebenen
Visuals und berät im Power-BI-Umfeld. Deshalb ist die Methodik offengelegt
und jede Zahl nachrechenbar — das Papier argumentiert mit Belegen, nicht
mit Autorität.
**Leseführung:** Kapitel 1–5 enthalten den belegten Fall und die Rechnungen
(Kosten, Kostenhebel, Barwert). Kapitel 6–9 ordnen ein: Verhandlungsmacht,
warum Framework und Git die Risiken zähmen, Governance und Wartbarkeit.
Kapitel 10 formuliert die Markt-Hypothesen, Kapitel 11–12 klären
Übertragbarkeit, Grenzen und Handlungsoptionen. Anhang A dokumentiert die
Methodik; Anhang B rechnet die Bewertungen nach anerkannten Verfahren vor
(COCOMO II, Function Points, DCF, Lizenzpreisanalogie) und ordnet den Fall
in die Produktivitäts-Literatur ein; ein Quellenverzeichnis schließt das
Papier.
---
## 1 · Der Fall: Was gebaut wurde
ChartKitchen byDatenWG ist ein natives Power-BI-Custom-Visual
(TypeScript/SVG, API 5.11.0, keine externen Laufzeit-Abhängigkeiten) für
Controlling-Berichte in IBCS-inspirierter Notation — quelloffen (Apache 2.0)
und kostenlos.
| Umfang (Stand 15.07.2026, v1.34.1.0) | Wert |
| --- | --- |
| Chart-Modi | 12 (Säulen, Balken, Linie, Wasserfall, integrierte Brücke, Kategorie-Brücke, Tabelle/Matrix, GuV-Statement, KPI-Karten, Pareto, Dumbbell, Slope) |
| Kern-Code | ~10.200 Zeilen |
| Tabelle/Matrix | N-Ebenen-Hierarchie, Scrolling mit fixiertem Header + Σ, Formelzeilen, klappbare Spaltenhierarchie, Suche, Sortierung |
| Lokalisierung | de, en, es, ja — je ~245 Oberflächen-Strings |
| Qualitätssicherung | 80+ Headless-Render-Tests, Microsoft-Lint-Regeln, `npm audit` 0 Findings |
| Distribution | baubarer Quellcode-Export, AppSource-Einreichungspaket, Marken-/Rechtsprüfung |
*Abb. 1 — Die Modus-Galerie des Visuals: 12 klickbare Vorschauen, Schrift-Presets, mehrsprachig.*
*Abb. 2 — Controlling-Tabelle: integrierte Balken, Δ- und Δ%-Spalten, Finanzkonvention (negative Werte in Klammern), Trend-Icons ▲▼● an Materialitätsschwellen.*
---
## 2 · Zeit, Kosten und Arbeitsweise — die tatsächlichen
Die Git-Historie erlaubt eine ehrliche Abgrenzung: erster Commit des Visuals
am **6. Juli 2026**, der beschriebene Stand am **15. Juli 2026**.
*Abb. 3 — 124 Commits, ~60 Releases in 10 Kalendertagen (8 aktive Tage).*
| Kennzahl | Wert |
| --- | --- |
| Dokumentierte Steuerungszeit des PO (Sitzungsprotokolle: Anforderungen, Tests, Feedback) | ~20 h |
| Werkzeugkosten (KI-Abo ~100 $ + 80 € Zusatzbudget) | ~180 € |
| Verarbeitete Tokens | ~1,8 Mrd. (96 % Cache-Lesevorgänge) |
| API-Listenpreis-Äquivalent der Rechenleistung | ~2.900 $ (durch Pauschal-Abo abgedeckt) |
| CO₂-Fußabdruck (Methodik: [Daten-WG-KI-CO₂-Simulator](https://datenwgknowledgekitchen.com/ki-co2-simulator.html), mittleres Szenario) | ~0,2–1,1 t CO₂e ≈ ein Inlandsflug |
Zur Steuerungszeit eine wichtige Präzisierung: **~20 h ist die
dokumentierte Zeit** aus den Sitzungsprotokollen. Nicht erfasst sind
Nachdenken, Recherche und Ideensammlung außerhalb der Sitzungen — sie
lassen sich ehrlicherweise nicht messen. Deshalb rechnet Kapitel 4 die
Sensitivität bis zur sechsfachen Stundenzahl durch.
**Anatomie einer typischen Iteration** — vom Satz zum Release am selben Tag:
Der Product Owner meldet morgens per Screenshot: *„Bei Small Multiples
skalieren die Brücken jede Kachel für sich — das sollte optional eine
gemeinsame Skala können."* Nachmittags ist die Option gebaut, getestet,
lokalisiert und als Release verteilt:
*Abb. 4a — Vorher: Region „Süd" (⅓ des Volumens von „Nord") füllt ihre Kachel genauso aus.*
*Abb. 4b — Nachher (gleicher Tag): optionale gemeinsame Skala — „Süd" ist sichtbar ein Drittel, inklusive der Δ%-Pin-Skalen.*
**Gesamtinvest, zwei Bewertungen:**
- **Externer Product Owner** (erfahrener Berater, 250 €/h):
20 h × 250 € + 180 € = **~5.200 €**
- **Interner Product Owner** (Controller/BI-Verantwortlicher, 100 €/h
Vollkosten): 20 h × 100 € + 180 € = **~2.200 €**
Bemerkenswert an beiden Rechnungen: **Werkzeugkosten sind 3–8 % des Invests —
über 90 % ist Expertenzeit.** Der Engpass ist nicht mehr das
Entwicklungsbudget, sondern die Person, die weiß, was gebaut werden soll.
---
## 3 · Was derselbe Stand klassisch gekostet hätte
Bevor gerechnet wird, lohnt der Blick auf die Prozesse selbst — hier
entsteht der Kostenunterschied, nicht bei den Stundensätzen:
*Abb. 5 — Warum die Kosten unterschiedlich entstehen: Der klassische Prozess durchläuft alle Stufen einmal in Serie; der KI-gestützte Loop durchläuft einen kurzen Zyklus dutzendfach — hier ~60-mal in zehn Tagen. [M]*
Bottom-up geschätzt in Personenmonaten (PM) Entwicklung:
| Block | PM |
| --- | --- |
| Grundgerüst, Build-Pipeline, Settings-Modell | 0,5–1 |
| Säulen/Balken/Linie inkl. Varianz-Panels, Skalen-Sync, YTD | 2–3 |
| Wasserfall + zwei Brücken-Modi | 1–1,5 |
| Tabelle/Matrix (Hierarchie, Scroll-Freeze, Formeln, Matrix-Ausbau) | 2,5–4 |
| KPI-Karten inkl. Bullet/Benchmark | 0,75–1 |
| Small Multiples (Σ-Kachel, Top-N, Zoom, gemeinsame Skalen) | 0,75–1 |
| Landing, In-Chart-Interaktionen, Persistierung/Bookmarks | 0,5–1 |
| Lokalisierung, Barrierefreiheit, Kontrastmodus | 0,5 |
| Test-Harness + Testfälle | 0,75–1 |
| Zertifizierungsvorbereitung, Lizenz/Marken, AppSource-Kit | 0,5–1 |
| **Entwicklung** | **10–14 PM** |
| + Projektrealität (Spezifikation, Reviews, Abstimmung, QA) | **14–18 PM** |
Bewertet zu Marktsätzen: **intern ~130–160 T€** (Senior-Vollkosten 9 T€/PM,
sofern Entwickler mit Power-BI-Visual- *und* Controlling-Erfahrung verfügbar
sind), **extern ~250–400 T€** (900–1.200 €/Tag). Wir rechnen konservativ mit
der Spanne **150–350 T€**. [S] Eine unabhängige Gegenrechnung mit zwei
anerkannten Schätzverfahren (COCOMO II, Function Points) bestätigt die
Spanne — Rechenwege in Anhang B.
**Offen benannt: Dieser Vergleich ist asymmetrisch.** Die klassische Seite
enthält den vollen Prozess-Overhead (Spezifikation, Reviews, QA,
Abnahmetests, Endnutzer-Doku, Projektmanagement); der KI-Build enthält
Endnutzer-Doku, formale Abnahmetests und eine vollständige externe
Review-Runde **noch nicht** (Kapitel 11). Wer nur den Ist-Stand vergleicht,
verschafft der KI-Seite also einen systematischen Vorteil. Deshalb wird der
Kostenhebel in Kapitel 4 zusätzlich symmetrisch gerechnet — mit beiden möglichen
Korrekturen (KI-Seite auf Vollumfang hochgerechnet bzw. klassische Seite um
die fehlenden Anteile gekürzt).
*Abb. 6 — Vier Wege zum selben Stand. Die KI-gestützten Balken sind auf dieser Skala kaum sichtbar — das ist die Aussage.*
---
## 4 · Der Kostenhebel — bewusst kein „ROI"
Vorab die Begriffsklärung, die ein kritischer Leser zu Recht einfordert:
Die folgende Kennzahl ist **kein ROI**. Ein Return on Investment setzt
realisierte Erträge voraus; hier wird der tatsächliche Invest ins
Verhältnis zu **vermiedenen Wiederbeschaffungskosten** gesetzt (Cost
Avoidance). Wir nennen die Kennzahl deshalb durchgängig **Kostenhebel**:
„29×" heißt, der Wiederbeschaffungswert entspricht dem 29-Fachen des
Invests — nicht, dass 29-fache Erträge geflossen sind. Realisiert wird der
Wert erst über Nutzung, Reichweite und vermiedene Lizenzkosten (Kapitel 5).
Wer eine klassische Bezeichnung braucht: ein Wert-/Investitionsfaktor auf
Basis des geschätzten Wiederbeschaffungswerts. [S]
| Kostenhebel | Externer PO (5.200 €) | Interner PO (2.200 €) |
| --- | ---: | ---: |
| vs. 150 T€ (konservativ) | **29×** | **69×** |
| vs. 250 T€ (mittel) | **48×** | **115×** |
| vs. 350 T€ (extern) | **67×** | **161×** |
Effektiver Stundenwert der 20 dokumentierten Steuerungsstunden:
**7.500–17.500 €** — Hebel 30–70 auf den externen Beratersatz, 75–175 auf
den internen. Pro Release: ~85 € (extern) bzw. ~37 € (intern). Pro Zeile
Code: ~0,20–0,50 € — klassisch liegt eine produktive Zeile bei 15–35 €.
Zwei Einordnungen: Der wichtigere Punkt als jede Kennzahl ist, dass ein
Werkzeug **überhaupt entsteht**, das nie ein 250-T€-Budget bekommen hätte.
Und: Der Hebel gehört zur Kombination „Fachexperte + Werkzeug". KI ersetzt
hier das Entwicklerteam — **nicht den Product Owner.**
### Sensitivität: Was, wenn es mehr Stunden waren?
Die 20 h sind dokumentierte Sitzungszeit (Kapitel 2) — undokumentierte
Denk- und Recherchezeit kommt realistisch hinzu. Die Rechnung bricht
dadurch nicht:
| Steuerungszeit | Invest extern | Hebel vs. 150–350 T€ | Invest intern | Hebel vs. 150–350 T€ |
| --- | ---: | ---: | ---: | ---: |
| 20 h (dokumentiert) | 5,2 T€ | 29–67× | 2,2 T€ | 69–161× |
| 40 h | 10,2 T€ | 15–34× | 4,2 T€ | 36–84× |
| 80 h | 20,2 T€ | 7–17× | 8,2 T€ | 18–43× |
| 120 h | 30,2 T€ | 5–12× | 12,2 T€ | 12–29× |
Selbst bei **Versechsfachung** der Stunden bleibt ein Hebel von mindestens
5 (extern) bzw. 12 (intern). Die Aussage hängt nicht an der Präzision der
Stundenerfassung.
### Symmetrie-Check: Kostenhebel mit vergleichbarem Leistungsumfang
Die Tabelle oben vergleicht Ist-Stand gegen Vollprozess (Prämisse 7). Zwei
Korrekturen stellen Symmetrie her:
**Weg A — KI-Seite auf Vollumfang hochrechnen.** Endnutzer-Doku, formale
Abnahmetests und eine externe Review-Runde sind mit derselben Methode
schätzungsweise weitere 15–25 PO-Stunden plus ~100 € Werkzeugkosten
(Erfahrungswert aus den bisherigen Doku- und Testpaketen des Projekts —
eine Schätzung, keine Messung):
| | Externer PO | Interner PO |
| --- | ---: | ---: |
| Invest bei Vollumfang | ~9,0–11,5 T€ | ~3,8–4,8 T€ |
| Hebel vs. 150–350 T€ | **13–39×** | **31–93×** |
**Weg B — klassische Seite um die fehlenden Anteile kürzen** (−10–20 %,
Kapitel 3): Vergleichswert 120–315 T€ gegen den Ist-Stand-Invest:
| | Externer PO (5,2 T€) | Interner PO (2,2 T€) |
| --- | ---: | ---: |
| Hebel vs. 120–315 T€ | **23–61×** | **55–144×** |
**Was sich dadurch ändert — und was nicht:** Die Schlagzeilen-Werte 29–161×
gelten nur für den Ist-Stand-Vergleich. Symmetrisch gerechnet liegt der
Hebel je nach Weg und Besetzung bei **13–144×** — im ungünstigsten Szenario
(externer Satz, Vollumfang, konservativer Vergleichswert) bleibt ein Faktor
**13**. Die Kernaussage übersteht die Korrektur; die Einzelwerte sollten
aber stets mit dieser Einordnung zitiert werden. Nicht hochrechenbar ist
schließlich der Abstimmungsaufwand echter Multi-Stakeholder-Organisationen:
Dieses Projekt wurde von einer Person entschieden — in einer Organisation
mit Gremien und Freigaben kämen PO-Stunden hinzu, die den Faktor weiter
drücken (Kapitel 11).
---
## 5 · Build vs. Buy im Barwertvergleich
Kommerzielle Visual-Suiten kosten grob **7–12 € pro Nutzer und Monat**.
Diskontiert über 5 Jahre (8 %, Annuitätenfaktor 3,99), gegen Eigenbau mit
5,2 T€ Invest und angenommenen 3 T€/Jahr Pflege:
*Abb. 7 — Ab ~150–200 Report-Nutzern ist der Eigenbau nach Barwert klar überlegen.*
| Unternehmensgröße | Lizenz-Barwert (5 J) | Eigenbau-Barwert | NPV-Vorteil |
| --- | ---: | ---: | ---: |
| 50 Nutzer × 8 €/M | 19.200 € | 17.200 € | ~2.000 € |
| 200 Nutzer × 10 €/M | 95.800 € | 17.200 € | **~78.600 €** |
| 1.000 Nutzer × 7 €/M | 335.400 € | 17.200 € | **~318.000 €** |
Payback: 2,6 Monate (200 Nutzer), ~3 Wochen (Konzern). Sensitivität: Selbst
bei verdreifachter Pflege (10 T€/Jahr) bleibt der Mittelstandsfall ~50 T€ im
Plus. Die vollständige Jahr-für-Jahr-Rechnung samt Zins- und
Pflege-Sensitivitäten steht in Anhang B. [S]
**Die Adopter-Perspektive verschärft das Bild:** Wer das freie
Community-Visual einsetzt statt selbst zu bauen, trägt nur die Einführung
(~2 Controller-Tage ≈ 1,5 T€) gegen 19–335 T€ Lizenz-Barwert. Für kleine
Unternehmen — deren reale Alternative oft „keine IBCS-Visuals" ist — ist das
keine Ersparnis, sondern **Zugang zu einer Fähigkeit, die es in ihrer
Preisklasse nicht gab**.
Fairness: Der Vergleich gilt, wo der Funktionsumfang genügt. Kommerzielle
Anbieter verkaufen zusätzlich Reife, SLAs, Zertifizierung, Roadmap. Diese
Lücke adressiert im Community-Modell ein Support-Abo (Kapitel 10).
---
## 6 · Die spieltheoretische Dimension
Ein oft übersehener Wert eines glaubwürdigen freien Werkzeugs realisiert
sich, **ohne dass es eingesetzt wird**: Es verändert die
Verhandlungsposition (BATNA) gegenüber kommerziellen Anbietern. Vorab zur
Einordnung: Das Folgende ist eine **modellhafte Überlegung** nach
Verhandlungslogik — belegt durch keine beobachteten Abschlüsse; die
genannten Beträge sind mögliche Effekte, keine zugesagten Nachlässe. [H]
- Bisher lautete die Alternative in Lizenzverhandlungen: „zahlen oder
verzichten". Mit einer glaubwürdigen freien Option genügt die
**Möglichkeit** des Wechsels: Beim 1.000-Nutzer-Konzern entsprechen
10–20 % Renewal-Nachlass **33–67 T€ Barwert** — allein durch die Existenz
der Alternative im Beschaffungsvergleich.
- **Glaubwürdigkeit ist die Währung:** offener, baubarer Quellcode ✓,
sichtbare Pflege (60 Releases in 10 Tagen) ✓, Zertifizierung und Doku als
nächste Schritte. Der billigste glaubwürdige Zug eines Konzerns: ein Pilot
auf einer einzigen Berichtsseite.
- **Grenzen:** Ohne Zertifizierung bleibt die Karte in vielen Häusern formal
unspielbar; große Berichtsbestände (Wechselkosten) stumpfen sie ab. Am
schärfsten ist sie bei Neueinführungen und auslaufenden Rahmenverträgen.
---
## 7 · Warum das feste Framework der halbe Erfolg ist
Dieses Kapitel enthält die zentrale These des Papiers — sie ist
wissenschaftlich interessanter als jeder Kostenfaktor: **Feste Frameworks
reduzieren die Freiheitsgrade der Entwicklung so stark, dass KI-Arbeit
kontrollierbar und reproduzierbar wird.** Die Wirkungskette lautet:
Framework → Sandbox → kleine Iterationen → lokale Verifikation → Git →
kontrollierbares Risiko. Absolute Produktivitätsfaktoren werden sich mit
jeder Modellgeneration ändern; dieser Mechanismus nicht.
Die verbreitete Sorge gegenüber KI-generiertem Code — „schnell, aber
unsicher und fehlerhaft" — unterschätzt, wie stark ein festes Framework
die Risikoflächen beschneidet. Fünf Mechanismen greifen ineinander, alle
am Fall belegt [M]:
**Mechanismus 1 — Suchraumreduktion.** Ein Power-BI-Visual lebt in einem
vordefinierten Vertrag: eine `update()`-Schnittstelle, deklarative
Capabilities, ein Settings-Modell. Es gibt keine selbstgebaute Netzwerk-,
Persistenz- oder Threading-Schicht, in der sich KI-Fehler verstecken
könnten — die fehleranfälligsten Schichten klassischer Projekte
**existieren gar nicht erst**. Für die KI heißt das: Der Lösungsraum je
Anforderung ist klein, die Varianz zwischen zwei Anläufen gering — genau
das macht Ergebnisse reproduzierbar statt zufällig.
**Mechanismus 2 — Deterministische Schnittstellen.** Jede Anforderung
übersetzt sich mechanisch in „welche Option, welcher Renderer, welche
Persistierung" — keine Architektur-Grundsatzfragen, deren Fehlentscheidung
erst Monate später sichtbar wird. Entwicklung wird zur Folge kleiner,
entscheidbarer Schritte; Konvergenz ist der Normalfall, nicht der
Glücksfall.
**Mechanismus 3 — Sandbox als Schadensdeckel.** Das Visual läuft in einem
isolierten iframe, ohne Netzwerkzugriff, ohne Dateisystem, ohne
Speicher-APIs. Die Microsoft-Zertifizierungsregeln verbieten zusätzlich
`eval`, `innerHTML`, externes Nachladen — Regeln, gegen die automatisiert
geprüft wird (projektweit eingehalten, `npm audit`: 0 Findings). Der
maximale Schadensradius eines KI-Fehlers ist strukturell gedeckelt: **Er
kann ein Chart falsch zeichnen, aber keine Daten exfiltrieren.**
**Mechanismus 4 — Kleine Iterationen.** 124 Commits für ~60 Releases: Die
durchschnittliche Änderung ist klein genug, um per Diff gelesen, verstanden
und notfalls verworfen zu werden. Experimente werden billig, weil Rückwege
garantiert sind (Kapitel 8) — das senkt die Kosten jeder einzelnen
Fehlentscheidung auf Minuten.
**Mechanismus 5 — Lokale Verifikation in Minuten.** Der Headless-Harness
rendert jeden Stand als Bild; Fehler sind *sichtbar* statt latent, 80+
Testfälle mit bekannten Erwartungswerten sichern die Fachlogik. Der
Feedback-Loop schließt sich lokal in Minuten — ohne Deployment, ohne
Testumgebung, ohne Wartezeit.
Als Designregel formuliert: **Wirkt KI-Entwicklung unkontrollierbar, ist
der erste Hebel nicht das bessere Modell, sondern der engere Zaun.**
```mermaid
flowchart LR
A["Fachexperte / Product Owner
Anforderung in Fachsprache"] --> B["KI-Agent
implementiert im Framework-Zaun"]
B --> C["Selbstverifikation
Lint · Render-Tests · Screenshots"]
C -->|Befund| B
C --> D["Release + Bildbeleg
an den PO"]
D -->|"Feedback, oft 1–2 Sätze"| A
B -.->|"Commit je Schritt"| G[("Git-Historie
Checkpoints · Belege · Rücksprung")]
```
*Abb. 8 — Der Loop: klein iterieren, selbst verifizieren, alles versionieren.*
Die Verallgemeinerung: Dieses Risikoprofil haben **alle**
Framework-Ökosysteme mit Sandbox und Zertifizierung — Office-Add-ins,
Browser-Extensions, App-Store-Apps, dbt-Pakete. Dort ist „Vibe Coding"
nicht trotz, sondern **wegen** der Einschränkungen produktionstauglich.
Greenfield-Systeme ohne Zaun haben dieses Sicherheitsnetz nicht — dort
gelten andere Maßstäbe (Kapitel 11).
---
## 8 · Git: das unterschätzte Fundament
Die unbequeme Wahrheit zuerst: **Ohne Versionskontrolle ist Vibe Coding
Müll.** Eine KI, die pro Tag dutzende Änderungen produziert, ist ohne
Rücksprungpunkte kein Beschleuniger, sondern ein unkontrollierbares Risiko —
jede fehlgeschlagene Iteration kontaminiert den Stand, niemand weiß mehr,
was wann warum geändert wurde. Mit Git kehrt sich das um; vier Mechanismen
haben diesen Build getragen:
**1. Checkpoints & Rollback.** Jeder Arbeitsschritt endet in einem Commit
(im Setup sogar erzwungen: ohne Commit + Push endet keine Arbeitssitzung).
Reales Beispiel aus dem Projekt: Ein Design-Experiment — ein Wortmarken-Logo
auf der Startseite — gefiel dem Product Owner nicht. Ein `git revert`,
Release als 1.30.4.0, fünf Minuten, kein Schaden:
```mermaid
gitGraph
commit id: "1.30.2.0 Galerie"
commit id: "1.30.3.0 Wordmark-Experiment"
commit id: "Revert Wordmark" type: REVERSE
commit id: "1.30.4.0 sauberer Stand"
commit id: "1.30.5.0 gestufte Layouts"
```
*Abb. 9 — Experimente werden billig, wenn Rückwege garantiert sind.*
**2. Kleine Commits als Review-Fläche.** 124 Commits für 60 Releases heißt:
Die durchschnittliche Änderung ist klein genug, um per Diff gelesen zu
werden. Das ist die realistische Antwort auf „wer reviewt den KI-Code?" —
nicht Zeile für Zeile alles, sondern **abgegrenzte Diffs mit beschreibenden
Commit-Botschaften**, stichprobenhaft tief geprüft.
**3. Branch-Isolation.** Die gesamte Entwicklung lief auf einem eigenen
Branch — die KI kann nichts „kaputt machen", was nicht explizit
zusammengeführt wird. Für Teams: KI-Arbeit ist damit organisatorisch genauso
integrierbar wie die eines neuen Entwicklers, inklusive Pull-Request-Gate.
**4. Historie als Beweismittel.** Jede Zahl in diesem Papier — Kalendertage,
Commits pro Tag, Release-Frequenz, sogar die Abgrenzung „Visual vs.
Vorarbeiten" — stammt aus `git log`. Versionskontrolle macht KI-Entwicklung
**auditierbar**: Für Wirtschaftsprüfer, für IT-Compliance, für die eigene
Kostenrechnung. Ohne Git wäre dieses Papier Behauptung; mit Git ist es
nachrechenbar. Nach unserer Kenntnis gehört diese Historie zu den ersten
vollständig öffentlichen Entwicklungsprotokollen eines KI-gebauten
Produktionswerkzeugs — jeder der 124 Schritte ist einsehbar. Das ist kein
Nebenprodukt der Fallstudie, sondern ihr zentrales Qualitätsmerkmal.
**Git als Governance-System.** Für Organisationen ist Git damit mehr als
ein Werkzeug — es ist die vorhandene Kontrollinfrastruktur für KI-Arbeit:
*Auditierbarkeit* — jede Änderung ist Urheber, Zeitpunkt und Begründung
zuordenbar, anschlussfähig an Wirtschaftsprüfung und IT-Compliance.
*Nachvollziehbarkeit* — das „Warum" jeder Entscheidung steht in der
Historie, nicht im Kopf einer Person. *Reviewbarkeit* — Pull-Request-Gates
funktionieren für KI-Beiträge unverändert. *Compliance-Anschluss* —
interne Kontrollsysteme docken an bestehende Git-Prozesse an; es braucht
keine neue Infrastruktur, nur Disziplin in der bestehenden. [M]
Praktische Konsequenz für jedes KI-Entwicklungs-Setup: Commit-Pflicht pro
Arbeitsschritt, aussagekräftige Botschaften, eigener Branch, Push als Teil
der Definition-of-Done. Das kostet nichts und entscheidet über
Produktionstauglichkeit.
---
## 9 · Governance, Wartbarkeit, Bus-Faktor — die Risiko-Fragen
Wer über den Einsatz dieses Musters entscheidet, fragt nicht nach Code,
sondern nach Risiko. Die vier Fragen, die dabei regelmäßig zuerst kommen —
und was dieser Fall auf sie antwortet:
**Wer prüft KI-generierten Code?** Drei Schichten, keine davon optional:
(1) *Automatisierte Gates* — Microsoft-Lint-Regeln, Zertifizierungs-Checks
(kein `eval`, kein `innerHTML`, kein Nachladen), `npm audit`; alle liefen
projektweit auf Null Findings. (2) *Abgegrenzte Diffs* — 124 Commits für
60 Releases bedeuten kleine, lesbare Änderungen mit beschreibenden
Botschaften; geprüft wird stichprobenhaft tief statt vollständig
oberflächlich (Kapitel 8). (3) *Fachliche Abnahme am Ergebnis* — der
Product Owner prüft jede Iteration am gerenderten Bild gegen fachliche
Regeln („Bestandsgrößen darf man nicht summieren"). Für Organisationen
heißt das: Der Review-Prozess für KI-Code existiert bereits — es ist der
Pull-Request-Prozess für menschlichen Code, mit strengeren automatischen
Gates.
**Wie werden Halluzinationen abgefangen?** Im Framework-Kontext äußert
sich ein KI-Fehler nicht als plausible Falschbehauptung, sondern als
falsch gezeichnetes Chart oder gebrochener Test — er ist *sichtbar*
(Kapitel 7). Der Headless-Render-Harness erzeugt für jeden Stand
Bildbelege; die fachliche Korrektheit prüft der Domänenexperte, nicht die
KI selbst. Restrisiko bleibt bei subtilen Rechenfehlern, die optisch
plausibel aussehen — dagegen stehen die 80+ Testfälle mit bekannten
Erwartungswerten.
**Wer wartet das in drei Jahren?** Die ehrlichste Antwort: nicht zwingend
dieselbe Person. Die Wartbarkeit hängt an drei Eigenschaften, die
personenunabhängig sind: offener Quellcode (jeder Entwickler *und* jede
künftige KI kann die Codebasis vollständig lesen), lückenlose Git-Historie
mit beschreibenden Commits (das „Warum" jeder Entscheidung ist
dokumentiert) und das Framework selbst (API-Updates von Microsoft sind der
Haupt-Pflegetreiber und betreffen alle Visuals gleich). Die
DCF-Rechnung (Kapitel 5) preist Pflege mit 3 T€/Jahr ein und bleibt bis
10 T€/Jahr robust — das entspricht 12–40 PO-Stunden jährlich mit derselben
Methode.
**Was passiert, wenn der Product Owner geht?** Der klassische Bus-Faktor-1
ist hier in zwei Hälften geteilt: Das *technische* Wissen liegt
vollständig im Repository (Code, Historie, Testfälle, maschinenlesbare
Projekt-Doku) — es ist übertragbar, an Menschen wie an KI-Agenten. Das
*Steuerungs*-Wissen — welche fachlichen Anforderungen als Nächstes
zählen — bleibt personengebunden, wie bei jedem Fachverfahren. Empfehlung
für den Organisationseinsatz: Anforderungen und Abnahme-Entscheidungen im
Repository mitführen (hier geschehen: Backlog und Changelog sind
öffentlich) und früh eine zweite Person in die Steuerung einbinden.
**Grenzen der Qualitätsevidenz — offen benannt:** Die vorliegenden
Qualitätsbelege sind Prozess- und Prüfmetriken (Tests, Lint, Audit,
Release-Historie). Es fehlen: formale Performance- und Speicher-Messungen,
strukturiertes Nutzerfeedback in der Breite und die abgeschlossene
Microsoft-Zertifizierung (eingereicht wird gerade; das Einreichungspaket
ist Teil des Repos). Diese Lücken stehen im öffentlichen Backlog und
gehören in jede seriöse Übernahme-Entscheidung (Kapitel 11).
---
## 10 · Die Marktthese: Open Source × KI wirkt multiplikativ
> **Einordnung — Reichweite dieses Kapitels:** Ab hier verlässt das Papier
> den belegten Einzelfall. Die folgenden Aussagen sind **Hypothesen über
> mögliche Marktwirkungen**, abgeleitet aus einer Fallstudie (n = 1) und
> historischen Analogien. Sie beschreiben, was passieren *könnte*, wenn
> sich das Muster in weiteren Fällen bestätigt — nicht, was nachweislich
> passiert. Wer ausschließlich belegte Aussagen sucht, kann dieses Kapitel
> überspringen — Kapitel 1–9 stehen ohne es. [H]
Die Wirkungskette der Hypothese, Glied für Glied: **KI senkt die
Entwicklungskosten** im gezäunten Anwendungs-Layer (am Fall belegt,
Kapitel 2–4) → **Funktions-Nachbau wird billig**, der Preisaufschlag für
Standard-Features verliert seine Grundlage → **Open-Source-Alternativen
werden dauerhaft pflegbar** und damit erstmals glaubwürdig → **der
zahlungswürdige Rest verschiebt sich zu Support, Haftung und
Integration** → **Anbieter passen Preise oder Geschäftsmodell an**. Nur
das erste Glied ist belegt; jedes weitere ist einzeln plausibel, aber
unbewiesen. [H]
Zur Vorgeschichte: Einzeln waren beide Kräfte für Software-Vendoren
beherrschbar: Open Source
scheiterte im Anwendungs-Layer oft am Pflegeargument („wer wartet das?");
KI-Entwicklung allein blieb ohne offene Referenz-Codebasen auf
Prototypen-Niveau. **Unsere Beobachtung legt nahe, dass sie sich
gegenseitig verstärken:**
- KI macht Community-Software **pflegbar** — ein Ein-Personen-Projekt hat
effektiv ein Entwicklerteam; „Bus-Faktor 1" bedeutet nicht mehr Stillstand.
- Offener Code macht KI **präzise** — jedes offene Projekt ist sofort
erweiterbar, weil das Modell die Codebasis liest wie ein eingearbeiteter
Entwickler.
Träfe das breit zu, geriete der klassische Schutzwall funktionsorientierter
Software-Anbieter („Entwicklung ist teuer, wir haben sie bezahlt, ihr
mietet sie") unter Druck. Am stärksten exponiert wären:
Single-Product-Anbieter mit Funktions-Differenzierung und
Sitzplatz-Preisen. Wenig betroffen: Plattformen (Microsoft gewinnt durch
jedes gute Visual), Daten-/Netzwerk-Lock-in, Haftung als Kaufgrund.
Das historische Muster existiert: Open Source hat die
Infrastruktur-Schicht konsolidiert (Linux, Postgres); überlebt hat das
**Red-Hat-Modell** — Software frei, Erlöse aus Support und Verlässlichkeit.
Unsere Erwartung: Dasselbe Modell erreicht jetzt den Anwendungs-Layer.
**Gegenkräfte, ehrlich benannt:** (1) Vendoren können ebenfalls KI-gestützt
entwickeln — was fällt, ist ihr Preissetzungsspielraum gegen „gut genug und
kostenlos", nicht ihr Produkt. (2) Die kommende Flut KI-gebauter
Wegwerf-Software wertet Vertrauenssignale **auf**: Zertifizierung,
Release-Historie, ein Gesicht dahinter. (3) Ein Marktsegment zahlt dauerhaft
für SLAs und Haftung — es schrumpft, verschwindet nicht.
---
## 11 · Übertragbarkeit — und Grenzen
Drei Zutaten erklären das Ergebnis; fehlt eine, bricht die Rechnung:
1. **Festes Framework** (Kapitel 7) — begrenzte Bug-/Security-Fläche, lokale
Verifikation.
2. **Domänenexpertise in der Steuerung** — Anforderungen in Fachsprache mit
eingebautem Qualitätsmaßstab („Bestandsgrößen darf man nicht summieren").
Der Unterschied zwischen zwei Iterationen und zwanzig.
3. **Selbstverifikation + Versionskontrolle** (Kapitel 8) — der Loop aus Abb. 8.
Wo das Muster trägt und wo nicht — nach den fünf Mechanismen aus
Kapitel 7 beurteilt [S]:
| Systemklasse | Eignung | Begründung |
| --- | :-: | --- |
| Power-BI-Visuals, Office-Add-ins | ✓ | fester API-Vertrag, Sandbox, Zertifizierungsregeln, lokale Verifikation |
| Browser- und IDE-Extensions | ✓ | definierte Manifest-/API-Grenzen, schneller lokaler Test |
| dbt-Pakete, Analytics-Artefakte | ✓ | deklarativer Rahmen, deterministische Prüfung gegen Daten |
| Interne Fachtools mit klarem Rahmen | ✓ | abgegrenzte Fachlogik, Fachexperte als Product Owner verfügbar |
| Greenfield-Plattformen | ✗ | Architektur-Freiheitsgrade sind genau das, was der Zaun wegnimmt |
| Verteilte Systeme | ✗ | Fehlerbilder entstehen im Zusammenspiel, Verifikation ist nicht lokal |
| Embedded / Safety-Critical | ✗ | Normen und formale Nachweise verlangen andere Prozesse |
| Legacy-Monolithen | ✗ | riesiger Kontext, langsame Verifikation — der METR-Befund zeigt die Richtung (Anhang B.6) |
**Offene Punkte dieses Projekts,** die ein 250-T€-Projekt enthalten hätte:
Endnutzer-Doku, formale Abnahmetests mit Anwendern, eine vollständige
adversariale Prüfrunde der jüngsten Pakete. Sie stehen im öffentlichen
Backlog — Transparenz gehört zur Glaubwürdigkeit.
---
## 12 · Was das für Unternehmen bedeuten kann
Die folgenden Ableitungen stehen unter dem Vorbehalt aus Kapitel 10 und
Prämisse 6: Belegt ist der Einzelfall; die Empfehlungen beschreiben
**mögliche Konsequenzen**, deren Tragweite davon abhängt, ob sich das
Muster in weiteren, unabhängigen Fällen bestätigt. Als risikoarme erste
Schritte taugen sie trotzdem — keiner davon setzt voraus, dass die
Marktthese eintrifft.
**CFO / Controlling-Leitung:** Visual- und Werkzeug-Lizenzen gegen die freie
Alternative prüfen — als Wechseloption oder Verhandlungskarte. Ab ~150–200
Nutzern ist der Barwertvorteil erheblich (Kapitel 5).
**IT- / BI-Verantwortliche:** Die Kombination „Framework-Zaun + interner
Fachexperte + KI + Git-Disziplin" ist reproduzierbar — und mit dem internen
100-€-Satz ist die Einstiegshürde vierstellig, nicht sechsstellig.
Kandidaten: alles, was heute als Sitzplatz-Lizenz eingekauft wird, im Kern
aber abgegrenzte Fachlogik ist.
**Software-Anbieter:** Feature-Paritäts-Verteidigung wird teurer als
Differenzierung nach oben (Planung, Writeback, Enterprise-Integration) oder
ein Service-Modell. Die Preissetzung der Basisschicht diszipliniert sich.
**Beratungen:** Der Wert wandert von der Lizenz zur Expertise. Das
tragfähige Modell ist das der Infrastruktur-Welt: Software frei, Erlöse aus
Enablement, Support und Weiterentwicklung — das Abo als formalisierte
Antwort auf die Pflege-Frage.
**Die Handlungsempfehlung in einem Satz:** Unternehmen sollten ihre
Build-vs.-Buy-Entscheidungen für Framework-Software unter den Bedingungen
KI-gestützter Entwicklung neu bewerten — nicht, weil dieser Einzelfall es
erzwingt, sondern weil die Rechenwege dafür jetzt offen vorliegen und ein
Nachrechnen im eigenen Haus wenige Tage kostet, nicht Monate. [S]
> **Dieses Papier behauptet nicht:** dass KI Entwickler ersetzt · dass
> jede Software in zehn Tagen entsteht · dass jeder Fachbereich dieselben
> Ergebnisse erreicht · dass ein Einzelfall einen Markttrend beweist.
>
> **Es zeigt:** einen vollständig dokumentierten Praxisfall [M] · eine
> nachvollziehbare wirtschaftliche Bewertung nach anerkannten
> Verfahren [S] · plausible Konsequenzen für die
> Build-vs.-Buy-Entscheidung [S] · begründete Hypothesen für weitere
> Untersuchung [H].
---
## Einladung: Replizieren, widerlegen, erweitern
Eine Fallstudie beweist keine Regel — sie stellt eine präzise Frage. Die
Antwort entsteht durch Wiederholung: **Wenn Sie ein vergleichbares Vorhaben
umsetzen — in einem anderen Framework, mit einem anderen Fachgebiet, im
Team statt allein —, dokumentieren Sie es nach derselben Methode** (Anhang
A: Git-Historie, Stundenprotokoll, Werkzeugkosten, Bewertungsverfahren aus
Anhang B) und stellen Sie die Ergebnisse neben diese. Bestätigende Fälle
schärfen die Randbedingungen; widersprechende sind mindestens so wertvoll —
sie zeigen, wo der Zaun endet.
Drei Replikationsfragen halten wir für besonders lohnend: Hält der
Kostenhebel in einem zweiten Framework-Ökosystem (Office-Add-in,
dbt-Paket)? Wie stark fällt er, wenn ein Multi-Stakeholder-Team statt
einer Einzelperson steuert? Und wo liegt er bei einem Product Owner ohne
Entwicklungs-Vorerfahrung? Repository, Methodik und dieses Papier sind
öffentlich — Widerspruch ist ausdrücklich erwünscht.
**Kontakt für Replikationen, Kritik und Rückfragen:**
Michael Tenner · [michael.tenner84@gmail.com](mailto:michael.tenner84@gmail.com)
---
## Anhang A · Methodik und Belege
- **Projektdaten:** Git-Historie des öffentlichen Repositories (erster
Visual-Commit 06.07.2026; 124 Commits, ~60 Releases bis 15.07.2026);
Code-Umfang per `wc -l`; Testfälle im Repo. Abb. 1, 2 und 4 sind
unbearbeitete Render-Ausgaben des Test-Harness; Abb. 3, 6 und 7 sind aus
den Rohdaten erstellte Schaubilder; Abb. 5 ist ein Prozess-Schema.
- **Token-/Kostendaten:** Auswertung des Entwicklungs-Session-Protokolls
(4.446 API-Aufrufe; Output 5,3 M, Cache-Write 70,5 M, Cache-Read 1.725 M
Tokens); API-Listenpreise Stand Juni 2026; Abo-Kosten laut Rechnung.
- **Stundensätze:** 250 €/h externer Senior-Berater (Marktsatz), 100 €/h
interner Vollkostensatz (Gehalt + Nebenkosten + Overhead eines erfahrenen
Controllers/BI-Verantwortlichen).
- **CO₂-Schätzung:** Methodik des Daten-WG-KI-CO₂-Simulators (Wh je 1.000
Output-Tokens nach Modellklasse, PUE 1,15–1,56, US-Strommix 300–450 g/kWh);
Cache-Reads mit Faktor 0,1 als preis-analoge Näherung.
- **Klassische Kostenschätzung:** Bottom-up in PM (Kapitel 3), bewertet mit
9 T€/PM intern bzw. 900–1.200 €/Tag extern; keine Anbieterangebote
eingeholt, Spanne bewusst breit.
- **DCF-Annahmen:** Lizenzpreise 7–12 €/Nutzer/Monat (öffentliche
Preisindikationen kommerzieller IBCS-Visuals, volumenabhängig); 8 %
Diskontsatz; 5 Jahre; Pflege Eigenbau 3 T€/Jahr (Sensitivität bis
10 T€/Jahr geprüft).
- **Interessenlage:** Die Daten-WG ist Herausgeberin des beschriebenen
Visuals und erbringt Beratungsleistungen im Power-BI-Umfeld. Alle
Schätzungen sind Größenordnungen, keine Angebote oder Zusicherungen.
## Anhang B · Bewertung nach anerkannten Verfahren — die Rechenwege
Bewertungsstandards für immaterielle Vermögenswerte (IDW S 5 [1],
IVS 210 [2]; bilanziell IAS 38 [3]) kennen drei Verfahrensfamilien:
**kostenorientiert** (Wiederbeschaffungskosten), **kapitalwertorientiert**
(abgezinste künftige Zahlungen, inkl. Lizenzpreisanalogie) und
**marktpreisorientiert** (Vergleichstransaktionen). Dieser Anhang rechnet
die ersten beiden vollständig vor; der Marktpreisansatz scheidet mangels
beobachtbarer Transaktionen einzelner Visuals aus — seine Rolle übernehmen
die öffentlichen Lizenzpreise, die in B.2 und B.3 einfließen.
### B.1 Kostenorientiert: Wiederbeschaffungskosten, drei Schätzverfahren
**Verfahren 1 — Bottom-up-Expertenschätzung** (Kapitel 3): Zerlegung in
zehn Arbeitsblöcke, je Block eine PM-Spanne. Ergebnis: **14–18 PM** inkl.
Projektrealität.
**Verfahren 2 — COCOMO II** (parametrisches Modell, Boehm et al. [4]).
Grundformel:
```
PM = A × Size^E × ∏EM mit A = 2,94; Size in KSLOC;
E = B + 0,01 × ΣSF mit B = 0,91; nominal E ≈ 1,10
```
Eingesetzt mit Size = 10,2 KSLOC (gemessener Kern-Code):
| Szenario | Effort-Multiplikatoren ∏EM | Ergebnis |
| --- | --- | --- |
| Nominal (durchschnittliches Team, Standardbedingungen) | 1,0 | **~38 PM** |
| Angepasst: hohe Team-/Analystenfähigkeit, eingespielte Werkzeugkette, geringe Neuartigkeit | 0,4–0,5 | **15–19 PM** |
Ein PM entspricht in COCOMO II 152 Arbeitsstunden. Das angepasste Szenario
entspricht einem erfahrenen Spezialistenteam — die realistische Besetzung
für ein solches Projekt; das Nominal-Szenario markiert die Obergrenze.
**Verfahren 3 — Function-Point-Analyse** (ISO/IEC 20926 [5]). Da keine
formale Zählung vorliegt, wird per Backfiring aus dem Code-Umfang
geschätzt (Jones [6]: JavaScript-Familie ~40–60 LOC je FP):
```
10.200 LOC ÷ 50 LOC/FP ≈ 204 FP (Bandbreite 170–255 FP)
```
Mit typischen Lieferraten für neue Business-Anwendungen von 8–15 Stunden
je FP (ISBSG-Benchmarks [7]): 204 FP × 8–15 h = 1.630–3.060 h ≈
**11–20 PM** (volle Bandbreite über beide Unsicherheiten: 9–25 PM).
**Triangulation** — Bewertung mit 9 T€/PM intern bzw. 900–1.200 €/Tag
extern (1 PM ≈ 19 Personentage):
| Verfahren | Aufwand | Intern (9 T€/PM) | Extern (900–1.200 €/Tag) |
| --- | --- | ---: | ---: |
| Bottom-up (Kapitel 3) | 14–18 PM | 126–162 T€ | 240–410 T€ |
| COCOMO II, angepasst | 15–19 PM | 135–171 T€ | 255–435 T€ |
| Function Points | 11–20 PM | 100–180 T€ | 190–455 T€ |
| *COCOMO II, nominal (Obergrenze)* | *~38 PM* | *~340 T€* | *~650–870 T€* |
Alle drei Hauptverfahren landen in derselben Größenordnung. Die im Papier
verwendete Spanne **150–350 T€** liegt innerhalb der Triangulation und
ist gegen deren Obergrenzen konservativ; der Abschlag für noch fehlende
Endnutzer-Doku und Abnahmetests (−10–20 %, Kapitel 3) ist dabei bereits
angesprochen.
**Warum COCOMO II und Function Points — und nicht DORA oder SPACE?** Für
einen Wiederbeschaffungswert braucht es Verfahren, die den *Aufwand für
einen definierten Funktionsumfang* schätzen — das leisten parametrische
Modelle (COCOMO II) und funktionale Größenmessung (Function Points).
Moderne Team-Performance-Frameworks wie DORA/Accelerate [14] oder
SPACE [15] messen dagegen Lieferfähigkeit und Entwicklererleben laufender
Organisationen — sie beantworten eine andere Frage und werden hier bewusst
nicht als Kostenmaßstab verwendet. Wichtig außerdem: COCOMO II ist auf
klassische Entwicklung kalibriert (Datenbasis bis ~2000). Es dient in
diesem Papier ausschließlich der **Plausibilisierung der klassischen
Vergleichskosten** — nie der Bewertung des KI-gestützten Wegs selbst.
### B.2 Kapitalwertorientiert: DCF, Jahr für Jahr
Barwertformel und Annuitätenfaktor (Standard-Finanzmathematik, z. B.
Brealey/Myers/Allen [8]):
```
PV = Σ CFt / (1+r)^t AF(r; n) = (1 − (1+r)^−n) / r
AF(8 %; 5 J) = (1 − 1,08^−5) / 0,08 = 3,9927
```
**Rechenbeispiel Mittelstand:** 200 Report-Nutzer, Lizenz 10 €/Nutzer/Monat
= 24.000 €/Jahr, nachschüssig; Eigenbau 5.200 € sofort + 3.000 €/Jahr
Pflege:
| Jahr | Lizenz-Zahlung | Abzinsfaktor (8 %) | Barwert Lizenz | Barwert Pflege |
| --- | ---: | ---: | ---: | ---: |
| 0 | — | 1,0000 | — | 5.200 € (Invest) |
| 1 | 24.000 € | 0,9259 | 22.222 € | 2.778 € |
| 2 | 24.000 € | 0,8573 | 20.576 € | 2.572 € |
| 3 | 24.000 € | 0,7938 | 19.052 € | 2.381 € |
| 4 | 24.000 € | 0,7350 | 17.641 € | 2.205 € |
| 5 | 24.000 € | 0,6806 | 16.334 € | 2.042 € |
| **Σ** | **120.000 €** | | **95.825 €** | **17.178 €** |
**NPV-Vorteil Eigenbau: 95.825 − 17.178 = ~78.600 €.** Payback:
5.200 € ÷ 24.000 €/Jahr ≈ 2,6 Monate.
**Sensitivität** (NPV-Vorteil in T€, gleicher Fall, Diskontsatz ×
Pflegekosten):
| Pflege \ Diskontsatz | 6 % | 8 % | 10 % |
| --- | ---: | ---: | ---: |
| 3 T€/Jahr | +83,3 | +78,6 | +74,4 |
| 6 T€/Jahr | +70,6 | +66,7 | +63,0 |
| 10 T€/Jahr | +53,8 | +50,7 | +47,9 |
Der Vorteil bleibt in jeder Kombination sechsstellig positiv im
Mittelstandsfall — die Entscheidung ist gegen beide Parameter robust.
**Break-even:** Der Eigenbau-Barwert von 17,2 T€ entspricht — je nach
Staffelpreis 8–12 €/Nutzer/Monat — dem Lizenz-Barwert von **30–45
Nutzern**. Darüber gewinnt der Eigenbau.
### B.3 Lizenzpreisanalogie (Relief from Royalty)
Die Lizenzpreisanalogie ist das in IDW S 5 [1] und IVS 210 [2] anerkannte
kapitalwertorientierte Verfahren zur Bewertung des **Vermögenswerts
selbst**: Der Wert des Werkzeugs entspricht den abgezinsten Lizenzzahlungen,
die sein Eigentümer *nicht* leisten muss, abzüglich der Kosten, die er
stattdessen trägt.
```
Wert ≈ PV(vermiedene Lizenzen) − PV(Pflege)
200 Nutzer: 95.825 € − 11.978 € ≈ 84 T€
1.000 Nutzer: 335.400 € − 11.978 € ≈ 323 T€
```
Der Wert ist nutzungsabhängig — dasselbe Visual ist für einen
1.000-Nutzer-Konzern rund viermal so viel „wert" wie für den Mittelstand.
Das erklärt präzise, warum ein und dasselbe freie Werkzeug als
Verhandlungskarte (Kapitel 6) beim Konzern am schärfsten wirkt.
### B.4 Zeitschätzung klassischer Entwicklung — mit Quellen
Die COCOMO-II-Zeitformel [4] liefert die Kalenderzeit unabhängig von der
Teamgröße:
```
TDEV = 3,67 × PM^0,318
15 PM → ~9 Monate 19 PM → ~9,5 Monate 38 PM → ~12 Monate
```
Das deckt sich mit der einfachen Überschlagsrechnung (14–18 PM bei 2
Entwicklern ≈ 7–9 Monate zzgl. Staffing, Reviews, Release-Zyklen) und
begründet die im Papier verwendete Spanne **6–12 Monate**. Zwei
empirische Befunde sprechen dafür, dass diese Schätzung eher zu
optimistisch als zu pessimistisch ist: Große IT-Projekte überschreiten
ihr Budget im Mittel um ~45 % (McKinsey/Oxford [9]), und nur rund ein
Drittel der Software-Projekte wird in Zeit, Budget und Umfang
abgeschlossen (Standish CHAOS [10]). Die 10 Kalendertage des KI-gestützten
Builds stehen einer nach anerkannten Verfahren hergeleiteten klassischen
Laufzeit von **9–12 Monaten** gegenüber — Faktor ~25–35 in der
Kalenderzeit.
### B.5 Einordnung der Verfahren
| Verfahren | Familie (IDW S 5 / IVS 210) | Ergebnis hier |
| --- | --- | --- |
| Bottom-up, COCOMO II, Function Points | kostenorientiert | Wiederbeschaffung 150–350 T€ (konservativ) |
| DCF Build vs. Buy | kapitalwertorientiert | NPV-Vorteil ~79 T€ (200 Nutzer) bis ~318 T€ (1.000 Nutzer) |
| Lizenzpreisanalogie | kapitalwertorientiert | Asset-Wert ~84–323 T€ (nutzungsabhängig) |
| Vergleichstransaktionen | marktpreisorientiert | nicht anwendbar (kein aktiver Markt für Einzel-Visuals) |
Alle Verfahren erzählen dieselbe Geschichte aus verschiedenen Richtungen:
Der geschaffene Wert liegt zwei Größenordnungen über dem Invest von
2,2–5,2 T€ — unabhängig davon, welcher anerkannten Bewertungslogik man
folgt.
### B.6 Einordnung in die Produktivitäts-Literatur
Kontrollierte Studien zu KI-Werkzeugen in der Software-Entwicklung
berichten deutlich kleinere, aber gleichgerichtete Effekte: **+55,8 %**
Geschwindigkeit bei einer abgegrenzten Programmieraufgabe im
Copilot-Experiment (Peng et al. [11]); **20–50 %** Zeitersparnis je nach
Aufgabentyp in Praxisexperimenten (McKinsey [12]); und als wichtiges
Gegen-Ergebnis: Erfahrene Open-Source-Entwickler waren mit KI-Werkzeugen
auf ihren eigenen, großen Codebasen im Mittel **~19 % langsamer**
(METR [13]).
Der hier dokumentierte Fall liegt mit einem Kalenderzeit-Faktor von
~25–35 weit über diesen Werten — er ist ein **Ausreißer am oberen Ende**
und genau deshalb erklärungsbedürftig. Die Erklärung dieses Papiers: Die
Literatur misst überwiegend KI als *Assistenz* in bestehenden Prozessen,
mit Menschen im Schreib-Loop und gewachsenen Codebasen; hier arbeitete KI
als *ausführendes Team* in einem eng gezäunten Framework, mit
Ein-Personen-Entscheidungsstruktur und Greenfield-Start — exakt die
Bedingungen aus Kapitel 7 und 11. Der METR-Befund stützt diese Lesart
spiegelbildlich: Ohne Zaun und mit hohem Kontextaufwand kann der Effekt
sogar negativ werden. Konsequenz: Der Faktor dieses Falls ist **kein
Erwartungswert für beliebige Projekte**, sondern eine Demonstration des
oberen Endes unter günstigen, explizit benannten Bedingungen.
---
## Quellen
1. IDW S 5: *Grundsätze zur Bewertung immaterieller Vermögenswerte.*
Institut der Wirtschaftsprüfer in Deutschland e. V., Düsseldorf
(Stand 2015).
2. IVSC: *International Valuation Standards*, IVS 210 *Intangible Assets.*
International Valuation Standards Council, London (aktuelle Fassung).
3. IAS 38: *Immaterielle Vermögenswerte.* International Accounting
Standards Board (IFRS-Standards).
4. Boehm, B. W.; Abts, C.; Brown, A. W. et al.: *Software Cost Estimation
with COCOMO II.* Prentice Hall, Upper Saddle River, 2000.
5. ISO/IEC 20926:2009: *Software and systems engineering — IFPUG
functional size measurement method.* ISO, Genf.
6. Jones, C.: *Applied Software Measurement: Global Analysis of
Productivity and Quality.* 3. Aufl., McGraw-Hill, New York, 2008
(Backfiring-Tabellen LOC↔FP).
7. ISBSG: *Development & Enhancement Repository* — Branchenbenchmarks zu
Project Delivery Rates (h/FP). International Software Benchmarking
Standards Group, isbsg.org.
8. Brealey, R. A.; Myers, S. C.; Allen, F.: *Principles of Corporate
Finance.* McGraw-Hill (Barwert- und Annuitätenrechnung).
9. Bloch, M.; Blumberg, S.; Laartz, J.: *Delivering large-scale IT
projects on time, on budget, and on value.* McKinsey & Company in
Zusammenarbeit mit der University of Oxford, 2012.
10. The Standish Group: *CHAOS Report* (fortlaufende Studienreihe zu
Erfolgsquoten von Software-Projekten).
11. Peng, S.; Kalliamvakou, E.; Cihon, P.; Demirer, M.: *The Impact of AI
on Developer Productivity: Evidence from GitHub Copilot.*
arXiv:2302.06590, 2023.
12. McKinsey & Company: *Unleashing developer productivity with
generative AI.* 2023.
13. METR: *Measuring the Impact of Early-2025 AI on Experienced
Open-Source Developer Productivity.* 2025.
14. Forsgren, N.; Humble, J.; Kim, G.: *Accelerate — The Science of Lean
Software and DevOps.* IT Revolution Press, 2018 (DORA-Metriken).
15. Forsgren, N.; Storey, M.-A.; Maddila, C. et al.: *The SPACE of
Developer Productivity.* ACM Queue 19(1), 2021.
Hinweis zur Verwendung: [4]–[7] sind Schätz-Benchmarks, keine Messungen
an diesem Projekt; sie dienen der unabhängigen Plausibilisierung der
projektspezifischen Bottom-up-Schätzung. Wo Literaturwerte als Bandbreite
vorliegen, wird durchgängig die Bandbreite — nicht ein Punktwert —
weitergerechnet.
---
*v2.2 — Zahlen Stand 15.07.2026. Feedback und Replikationen willkommen:
Michael Tenner · michael.tenner84@gmail.com*
==============================================================================
DOKUMENT: https://datenwgknowledgekitchen.com/md/pdoom-ki-risiko.md
==============================================================================
# Wie wahrscheinlich ist die KI-Apokalypse? — p(doom) im Ueberblick
> p(doom) ist die geschaetzte Wahrscheinlichkeit, dass KI katastrophal endet. Die Schaetzungen reichen von unter 0,01 % bis ueber 99 % — wer schaetzt was, warum, und was die Streuung ueber die Debatte verraet.
- **Quelle:** https://datenwgknowledgekitchen.com/pdoom-ki-risiko.html
- **Autor:** Michael Tenner · Daten-WG Knowledge Kitchen
- **Extrahiert aus:** `pdoom-ki-risiko.html` · Stand 2026-07-02 (Git-Commit-Datum der Quelldatei)
- **Zitierhinweis:** Michael Tenner, Daten-WG Knowledge Kitchen, https://datenwgknowledgekitchen.com/pdoom-ki-risiko.html — Abruf mit Datum angeben. Weiterverwendung mit Quellenangabe erwuenscht.
- **Hinweis fuer Agenten:** Diese Markdown-Fassung enthaelt den Fliesstext der Seite. Interaktive Elemente (Regler, Filter, animierte Charts) sind nur in der HTML-Fassung nutzbar; die zugehoerigen Zahlen stehen hier als Tabelle.
- **Begleitende Detail-Charts:** https://datenwgknowledgekitchen.com/pdoom-verteilung.html (Verteilung) · https://datenwgknowledgekitchen.com/pdoom-rollen.html (nach Rolle) · https://datenwgknowledgekitchen.com/pdoom-zeitverlauf.html (Zeitverlauf 2011–2025)
---
p(doom) ist die geschätzte Wahrscheinlichkeit, dass KI katastrophal endet. Die Schätzungen von Forschern, CEOs und Prognostikern reichen von unter 0,01 % bis über 99 % — ein Überblick über die Zahl, bei der sich die KI-Welt nicht einig wird. Wichtig: Das hier ist eine kommentierte **Sammlung öffentlicher Aussagen**, keine Messung der tatsächlichen Wahrscheinlichkeit.
**Wie verteilen sich die Schätzungen?** Jeder Balken zählt, wie viele der 57 bezifferten Werte in einen 10-%-Bereich fallen. Auffällig: eine starke Häufung unter 20 % (26 Werte), eine dünne Mitte (30–50 %) — und ein deutlicher hoher Schwanz (18 Werte über 50 %). Genau diese Polarisierung meint „kein Konsens". Lies die Höhe als „so viele **Aussagen** fielen in diesen Bereich" — nicht als Wahrscheinlichkeit; jede Aussage zählt gleich, auch eine Umfrage unter Tausenden so viel wie ein einzelner Tweet. *Tipp: über einen Balken fahren zeigt, wer in dem Bereich liegt.* Quelle: u. a. Wikipedia, PauseAI, AI Impacts, XPT, Metaculus — Stand Juni 2026.
## Eine Zahl, die *alles und nichts* sagt
Stellen Sie sich vor, Sie fragen die Menschen, die eine Technologie bauen, wie hoch die Wahrscheinlichkeit ist, dass genau diese Technologie die Menschheit auslöscht. In den meisten Branchen wäre die Antwort ein empörtes „Null". In der KI-Branche bekommen Sie Zahlen wie 10 %, 25 % — oder 90 %.
Diese Zahl hat sogar einen Namen: **p(doom)**, kurz für „probability of doom". Sie beschreibt die subjektiv geschätzte Wahrscheinlichkeit, dass fortgeschrittene Künstliche Intelligenz zu existenziell katastrophalen Folgen führt — von der Auslöschung der Menschheit über deren dauerhafte Entmachtung bis zum Zivilisationskollaps. Was als Insider-Kürzel in Forenkreisen begann, wurde 2023 nach dem Erscheinen von GPT-4 zum festen Begriff der öffentlichen Debatte.
Das Faszinierende daran: **Es gibt keinen Konsens.** Nicht annähernd.
## Eine Spannweite von *fast 0 bis fast 100 %*
**Die Skeptiker** halten das Risiko für vernachlässigbar. Yann LeCun, lange Chef-KI-Wissenschaftler bei Meta, beziffert es auf unter 0,01 % — seiner Einschätzung nach unwahrscheinlicher als ein tödlicher Asteroideneinschlag. Investor Marc Andreessen liegt nahe null.
**Die Mitte** wird vor allem von breit angelegten Umfragen markiert. In der bislang größten Erhebung von AI Impacts (2023) antworteten 2.778 KI-Forschende: Der Median lag bei 5 %, der Mittelwert bei rund 14 %. Professionelle Prognostiker („Superforecaster") kamen in einer separaten Studie sogar nur auf 0,38 % für eine KI-bedingte Auslöschung; befragte Fachexperten lagen bei etwa 3 %. Die Prognoseplattform Metaculus verortet das gesamte Auslöschungsrisiko bis 2100 bei rund 9 %, davon den Löwenanteil durch KI.
**Die Mahner** sehen es deutlich düsterer. Eliezer Yudkowsky vom Machine Intelligence Research Institute nennt über 95 %, der Forscher Roman Yampolskiy sogar 99,99 %. Auch ernstzunehmende Stimmen aus dem Mainstream der Forschung liegen hoch: Daniel Kokotajlo (ehem. OpenAI) bei 70–80 %, der MIT-Physiker Max Tegmark bei über 90 %.
## Das eigentlich Ungewöhnliche: *Die Bauherren warnen selbst*
Was diese Debatte von vielen anderen Technologie-Diskussionen unterscheidet, ist die Herkunft der Warnungen. Es sind nicht nur externe Kritiker — es sind die **Hersteller selbst**.
Anthropic-CEO Dario Amodei bezifferte das Risiko zuletzt auf 25 %, dass es „richtig, richtig schlecht" läuft — und baut trotzdem weiter an immer leistungsfähigeren Modellen. Elon Musk nennt 10–20 %. Google-Chef Sundar Pichai gibt sich optimistisch, räumt aber ein, das zugrundeliegende Risiko sei „ziemlich hoch". Demis Hassabis und Sam Altman vermeiden konkrete Zahlen, bestätigen aber ein reales, nicht-vernachlässigbares Risiko.
Anders gesagt: Die Anbieter der vielleicht wichtigsten Technologie unserer Zeit haben die Risikohinweise gleich selbst mitgeliefert. Das hat es in dieser Form bei kaum einer anderen Branche gegeben.
Ein Blick auf die **Rollen** deutet eine interessante Tendenz an — die man aber vorsichtig lesen muss: In dieser Sammlung liegen die Hersteller im Schnitt **niedriger** als die unabhängige Forschung (Ø ~17 % gegenüber ~49 %), die professionellen Prognostiker am niedrigsten (Median ~5,5 %). Das ist allerdings **kein belastbarer Gruppenvergleich**: Die Gruppen sind klein und ungleich groß, Personen mit mehreren Aussagen zählen mehrfach, und die Prognostiker beantworteten teils eine **enger gefasste Frage** (Auslöschung bis 2100). Als Hypothese bleibt aber stehen: Wer baut, klingt nicht alarmierter als der Rest — eher im Gegenteil.
**Wer hat am meisten Angst?** p(doom) nach Rolle, sortiert nach Gruppen-Durchschnitt — jeder Punkt eine Schätzung, der Balken der Mittelwert. Oben die unabhängige Forschung, darunter die bauende Industrie, ganz unten die Prognostiker. *Über die Punkte hovern für Person & Jahr.* **Illustrativ, nicht inferenzstatistisch:** kleine, ungleich große Gruppen, Mehrfachnennungen pro Person und teils unterschiedliche Fragestellungen — kein belastbarer Gruppenvergleich.
## Menschen *ändern ihre Meinung*
Diese Zahlen sind keine Naturkonstanten — sie verschieben sich, manchmal erheblich.
Das wohl prominenteste Beispiel ist Geoffrey Hinton, einer der „Paten der KI". Als er 2023 Google verließ, nannte er rund 10 %. Mitte 2024 sprach er von einer „50-50-Chance", dass KI die Menschheit überflügelt. Ende 2024 nannte er, gesamtheitlich betrachtet, wieder 10–20 %. Dan Hendrycks, Direktor des Center for AI Safety, korrigierte seine Einschätzung innerhalb eines Jahres von etwa 20 % auf über 80 % nach oben.
Solche Sprünge sind keine Schwäche der Methode — sie zeigen, wie schnell neue Modellgenerationen die Erwartungen von Fachleuten verändern. Genau das macht die zweite Grafik sichtbar: Sie trägt jede Schätzung als Punkt über ihr **Jahr** auf — fahr mit der Maus über einen Punkt, um zu sehen, **wer wann was** geschätzt hat. Und mit dem Regler darunter trägst du **deine eigene Schätzung** als Linie ein.
**p(doom) im Zeitverlauf.** Jede Schätzung ein Punkt — x = Jahr, y = Wahrscheinlichkeit; die Punkte erscheinen nacheinander. Vor 2023 fast leer, dann der Sprung ab der GPT-4-Zeit und die Aufspreizung über die ganze Skala. Achtung: Das ist auch ein **Erhebungseffekt** — der Begriff p(doom) wurde erst 2023 populär; fehlende Punkte davor heißen nicht „kein Risiko gesehen". *Hover zeigt Person, Jahr & Originalangabe; mit dem Regler trägst du deine eigene Schätzung als Linie ein. „Neu starten" spielt den Aufbau erneut.*
## Wie man diese Zahlen *lesen sollte*
Vorab das Wichtigste: Diese Seite zeigt, *was prominente Stimmen sagen* — nicht, *wie hoch das Risiko tatsächlich ist*. Entsprechend gehören ein paar Einschränkungen dazu, sonst vergleicht man Äpfel mit Birnen:
- **Selektionsverzerrung.** Erfasst ist nur, wer öffentlich eine Zahl nennt — eine selbstselektierte Gruppe rund um die KI-Sicherheits-Debatte. Viele Forschende, die das Risiko für ~0 halten, nennen schlicht keine p(doom) und fehlen hier. „Kaum jemand sagt null" gilt also *für diese Sammlung*, nicht zwingend für alle Fachleute.
- **Ungleiche Evidenzklassen.** Eine kalibrierte Umfrage unter 2.778 Forschenden zählt hier genauso „eins" wie ein einzelner Tweet — Häufigkeiten und Mittelwerte über so verschiedene Quellen sind mit Vorsicht zu genießen.
- **Mehrfachnennungen & Näherung.** Personen mit mehreren Aussagen (z. B. Hinton, viermal) erscheinen mehrfach und wiegen schwerer; Spannen wie „10–90 %" werden auf den Mittelpunkt (50 %) verkürzt — beides verzerrt die Verteilung.
- **Keine einheitliche Definition.** Mal ist „doom" die Auslöschung, mal eine feindliche Machtübernahme, mal nur „sehr großer Schaden".
- **Unterschiedliche Zeithorizonte.** Manche meinen „in den nächsten 30 Jahren", andere „bis zum Jahr 2100".
- **Bedingt vs. unbedingt.** Einige Werte gelten nur unter der Annahme, dass überhaupt eine allgemeine KI (AGI) entsteht.
- **Subjektivität.** Es sind Einschätzungen, keine berechneten Frequenzen — schließlich gibt es keine historischen Daten zu ausgelöschten Zivilisationen.
## Fazit
Die ehrlichste Antwort auf die Frage „Wie wahrscheinlich ist die KI-Katastrophe?" lautet derzeit: **Niemand weiß es genau.** Und unter denen, die sich öffentlich festlegen, hält kaum jemand die Wahrscheinlichkeit für null — wobei man die Selektion mitdenken muss: Wer das Thema für irrelevant hält, nennt selten eine Zahl. Statt auf die „richtige" Prozentzahl zu warten, lohnt es sich, die Debatte darüber ernst zu nehmen, wie wir dieses Risiko klein halten. Dass selbst die optimistischen 5 % aus den großen Umfragen kein achselzuckend hinzunehmender Wert wären, ist dabei eine *Wertung* — keine aus den Daten ableitbare Tatsache.
## Die Rangliste · *63 Schätzungen*
Alle dokumentierten Werte, sortiert von hoch nach niedrig. Die Näherung in Prozent dient nur der Sortierung — bei Spannen ist es der Mittelwert, qualitative Aussagen („>0 %") bleiben ohne Zahl.
| Person / Organisation | Kategorie | Jahr | Angabe | ~ % |
|---|---|---|---|---|
| [Roman Yampolskiy↗](https://www.businessinsider.com/ai-researcher-roman-yampolskiy-lex-fridman-human-extinction-prediction-2024-6) | Forschung | 2024 | 99,9-99,999999% | 99,9 % |
| [Eliezer Yudkowsky↗](https://www.fastcompany.com/90994526/pdoom-explained-how-to-calculate-your-score-on-ai-apocalypse-metric) | Forschung | 2023 | >95% | 97 % |
| [Connor Leahy↗](https://www.youtube.com/watch?v=nUV5-SLdkuQ) | Forschung/Industrie | 2024 | 90%+ | 92 % |
| [Max Tegmark↗](https://x.com/tegmark/status/1917580821101437280) | Forschung | 2025 | >90% | 92 % |
| [Anna Salamon (laut Wikipedia-Sammlung)↗](https://en.wikipedia.org/wiki/P(doom)) | Forschung | 2024 | 85% | 85 % |
| [Andrew Critch↗](https://en.wikipedia.org/wiki/P(doom)) | Forschung | 2024 | 85% | 85 % |
| [Dan Hendrycks↗](https://www.fastcompany.com/90994526/pdoom-explained-how-to-calculate-your-score-on-ai-apocalypse-metric) | Forschung | 2023 | >80% | 82 % |
| [Daniel Kokotajlo↗](https://www.youtube.com/watch?v=htOvH12T7mU) | Forschung | 2025 | 70-80% | 75 % |
| [Daniel Kokotajlo↗](https://www.lesswrong.com/posts/xDkdR6JcQsCdnFpaQ/adumbrations-on-agi-from-an-outsider) | Forschung | 2023 | 70% | 70 % |
| [Zvi Mowshowitz↗](https://www.cognitiverevolution.ai/zvi-mowshowitz-on-longer-timelines-rl-induced-doom-and-why-china-is-refusing-h20s/) | Journalismus | 2025 | 70% | 70 % |
| [Zvi Mowshowitz↗](https://x.com/liron/status/1729274710670893262) | Journalismus | 2023 | 60% | 60 % |
| [Geoffrey Hinton↗](https://xrisknews.com/geoffrey-hintons-pdoom-is-over-50/) | Forschung | 2024 | >50% (eigene Einschaetzung) | 55 % |
| [Holden Karnofsky↗](https://www.alignmentforum.org/posts/rCJQAkPTEypGjSJ8X/how-might-we-align-transformative-ai-if-it-s-developed-very) | Forschung/Industrie | 2022 | 10-90% | 50 % |
| [Jan Leike↗](https://www.fastcompany.com/90994526/pdoom-explained-how-to-calculate-your-score-on-ai-apocalypse-metric) | Forschung | 2023 | 10-90% | 50 % |
| [Geoffrey Hinton↗](https://blog.biocomm.ai/2024/10/24/nobel-laureate-geoff-hintons-pdoom-is-50-50/) | Forschung | 2024 | ~50% ('50-50') | 50 % |
| [Emad Mostaque↗](https://x.com/EMostaque/status/1864266899170767105) | CEO/Industrie | 2024 | 50% | 50 % |
| [Liron Shapira↗](https://lironshapira.substack.com/) | Journalismus | 2024 | 50% (Extinction bis 2050) | 50 % |
| [Geoffrey Miller↗](https://lironshapira.substack.com/) | Forschung | 2024 | ~50% | 50 % |
| [Paul Christiano↗](https://www.lesswrong.com/posts/xWMqsvHapP3nwdSW8/my-views-on-doom) | Forschung | 2023 | ~46% | 46 % |
| [KI-Ingenieure (informelle Umfrage)↗](https://twitter.com/AISafetyMemes/status/1713515843194077583) | Umfrage | 2023 | 40% (Mittelwert) | 40 % |
| [Joep Meindertsma↗](https://pauseai.info/pdoom) | Aktivismus | 2023 | 40% | 40 % |
| [Eli Lifland↗](https://forum.effectivealtruism.org/posts/QeLE22fefLqKfYTW6/eli-lifland-on-navigating-the-ai-alignment-landscape) | Prognose | 2023 | 35% | 35 % |
| [Scott Alexander↗](https://astralcodexten.substack.com/p/why-i-am-not-as-much-of-a-doomer) | Journalismus | 2023 | 33% | 33 % |
| [KI-Sicherheitsforschende (44 Personen)↗](https://web.archive.org/web/20221013014859/https://www.alignmentforum.org/posts/QvwSr5LsxyDeaPK5s/existential-risk-from-ai-survey-results) | Umfrage | 2021 | 30% (Mittelwert) | 30 % |
| [Shane Legg↗](https://www.lesswrong.com/posts/No5JpRCHzBrWA4jmS/q-and-a-with-shane-legg-on-risks-from-ai) | Forschung | 2011 | 5-50% | 27,5 % |
| [Emmett Shear↗](https://www.fastcompany.com/90994526/pdoom-explained-how-to-calculate-your-score-on-ai-apocalypse-metric) | CEO/Industrie | 2023 | 5-50% | 27,5 % |
| [Ajeya Cotra↗](https://venturebeat.com/ai/ai-doom-ai-boom-and-the-possible-destruction-of-humanity) | Forschung | 2023 | 20-30% | 25 % |
| [Dario Amodei↗](https://www.axios.com/2025/09/17/anthropic-dario-amodei-p-doom-25-percent) | CEO/Industrie | 2025 | 25% | 25 % |
| [Dan Hendrycks↗](https://twitter.com/DanHendrycks/status/1642394635657162753) | Forschung | 2023 | ~20% | 20 % |
| [Yoshua Bengio↗](https://www.abc.net.au/news/2023-07-15/whats-your-pdoom-ai-researchers-worry-catastrophe/102591340) | Forschung | 2023 | ~20% | 20 % |
| [Reid Hoffman↗](https://www.pbs.org/video/future-of-ai-1724451272/) | CEO/Industrie | 2024 | 20% | 20 % |
| [Dario Amodei↗](https://x.com/liron/status/1710520914444718459) | CEO/Industrie | 2023 | 10-25% | 17,5 % |
| [Lina Khan↗](https://twitter.com/liron/status/1723458202090774949) | Politik | 2023 | ~15% | 15 % |
| [Elon Musk↗](https://www.businessinsider.com/elon-musk-20-percent-chance-ai-destroys-humanity-2024-3) | CEO/Industrie | 2024 | 10-20% (bis ~30%) | 15 % |
| [Geoffrey Hinton↗](https://robotsgoodorbad.com/what-is-p-doom-ai-robot-doomsday/) | Forschung | 2024 | 10-20% (Gesamteinschaetzung) | 15 % |
| [Elon Musk↗](https://www.axios.com/2025/09/17/anthropic-dario-amodei-p-doom-25-percent) | CEO/Industrie | 2025 | ~10-20% | 15 % |
| [ML-Forschende (AI Impacts Survey 2023)↗](https://wiki.aiimpacts.org/ai_timelines/predictions_of_human-level_ai_timelines/ai_timeline_surveys/2023_expert_survey_on_progress_in_ai) | Umfrage | 2024 | 5% (Median); 14,4% (Mittel) | 14,4 % |
| [ML-Forschende (AI Impacts Survey 2022)↗](https://blog.aiimpacts.org/p/how-bad-a-future-do-ml-researchers) | Umfrage | 2022 | 5% (Median); ~14% (Mittel) | 14 % |
| [Vitalik Buterin↗](https://www.youtube.com/watch?v=hxlcQzvnmWI) | CEO/Industrie | 2025 | 12% | 12 % |
| [Joe Carlsmith↗](https://arxiv.org/abs/2206.13353) | Forschung | 2022 | >10% (2022; vorher ~5% 2021) | 12 % |
| [Toby Ord↗](https://www.abc.net.au/news/2023-10-08/is-there-really-a-1-in-6-chance-of-human-extinction/102942530) | Forschung | 2020 | 10% (nur KI) | 10 % |
| [Geoffrey Hinton↗](https://www.nytimes.com/2023/05/01/technology/ai-google-chatbot-engineer-quits-hinton.html) | Forschung | 2023 | ~10% | 10 % |
| [Vitalik Buterin↗](https://twitter.com/VitalikButerin/status/1729251822391447904) | CEO/Industrie | 2023 | 10% | 10 % |
| [Lex Fridman↗](https://en.wikipedia.org/wiki/P(doom)) | Journalismus | 2024 | 10% | 10 % |
| [Sundar Pichai↗](https://lexfridman.com/sundar-pichai-transcript) | CEO/Industrie | 2025 | ~10% | 10 % |
| [Metaculus (Community-Aggregat)↗](https://arxiv.org/pdf/2503.07341) | Prognose | 2025 | 9% gesamt (~8 Pp. durch KI) | 8 % |
| [Nate Silver↗](https://www.natesilver.net/p/its-time-to-come-to-grips-with-ai) | Journalismus | 2025 | 5-10% | 7,5 % |
| [ML-Forschende (AI Impacts Expert Survey 2016)↗](https://aiimpacts.org/2016-expert-survey-on-progress-in-ai/) | Umfrage | 2016 | 5% (Median) | 5 % |
| [Kevin Roose↗](https://venturebeat.com/ai/ai-doom-ai-boom-and-the-possible-destruction-of-humanity) | Journalismus | 2023 | 5% | 5 % |
| [Benjamin Mann↗](https://en.wikipedia.org/wiki/P(doom)) | CEO/Industrie | 2025 | 0-10% | 5 % |
| [Casey Newton↗](https://en.wikipedia.org/wiki/P(doom)) | Journalismus | 2023 | 5% | 5 % |
| [KI-Domaenenexperten (XPT-Studie)↗](https://static1.squarespace.com/static/635693acf15a3e2a14a56a4a/t/64f0a7838ccbf43b6b5ee40c/1693493128111/XPT.pdf) | Prognose | 2023 | 3% (Ausloeschung) / 12% (Katastrophe) | 3 % |
| [Scott Aaronson↗](https://scottaaronson.blog/) | Forschung | 2023 | ~2% (klassisches AGI-Doom-Szenario) | 2 % |
| [Superforecaster (XPT-Studie)↗](https://static1.squarespace.com/static/635693acf15a3e2a14a56a4a/t/64f0a7838ccbf43b6b5ee40c/1693493128111/XPT.pdf) | Prognose | 2023 | 0,38% | 0,38 % |
| [Yann LeCun↗](https://twitter.com/liron/status/1736555643384025428) | Forschung/Industrie | 2023 | <0,01% | 0,01 % |
| [Marc Andreessen↗](https://a16z.com/ai-will-save-the-world/) | CEO/Industrie | 2023 | ~0% | 0 % |
| [Grady Booch↗](https://en.wikipedia.org/wiki/P(doom)) | Forschung/Industrie | 2023 | ~0% | 0 % |
| [Sam Altman↗](https://blog.samaltman.com/machine-intelligence-part-1) | CEO/Industrie | 2015 | >0% (qualitativ) | — |
| [Sam Altman↗](https://www.safe.ai/work/statement-on-ai-risk) | CEO/Industrie | 2023 | >0% (qualitativ) | — |
| [Stuart Russell↗](https://www.judiciary.senate.gov/) | Forschung | 2023 | qualitativ (keine %-Zahl) | — |
| [Jaan Tallinn↗](https://pdoomfixer.com/what-is-pdoom/) | CEO/Industrie | 2023 | qualitativ (hoch) | — |
| [Demis Hassabis↗](https://www.youtube.com/watch?v=nwUARJeeplA) | CEO/Industrie | 2024 | >0% (qualitativ) | — |
| [Sam Altman↗](https://www.youtube.com/watch?v=rF0tQtDMwHM) | CEO/Industrie | 2025 | >0% (lehnt Zahl ab) | — |
### Quellenhinweis
Zahlen und Belege stammen aus der begleitenden Datentabelle (63 dokumentierte Schätzungen, 2011–2025). Zentrale Sammelquellen: [Wikipedia („P(doom)")](https://en.wikipedia.org/wiki/P(doom)), [PauseAI](https://pauseai.info/pdoom), [AI Impacts Expert Surveys](https://aiimpacts.org/), Forecasting Research Institute (XPT) sowie Berichterstattung u. a. von Axios, Business Insider, ABC News und Fast Company. Stand: Juni 2026. Werte sind Momentaufnahmen öffentlicher Aussagen und können sich ändern — für Veröffentlichungen bitte die Primärquellen prüfen.
==============================================================================
DOKUMENT: https://datenwgknowledgekitchen.com/md/ki-co2-simulator.md
==============================================================================
# Wie viel CO₂ steckt in einem Token? — KI-Energie-Simulator
> Simulator fuer den Energie- und CO₂-Fussabdruck der KI-Nutzung im Unternehmen — pro Token, pro Mitarbeiter und Jahr, und fuer die ganze Organisation. Alle Annahmen editierbar, als Min–Max-Band ausgewiesen.
- **Quelle:** https://datenwgknowledgekitchen.com/ki-co2-simulator.html
- **Autor:** Michael Tenner · Daten-WG Knowledge Kitchen
- **Extrahiert aus:** `ki-co2-simulator.html` · Stand 2026-07-03 (Git-Commit-Datum der Quelldatei)
- **Zitierhinweis:** Michael Tenner, Daten-WG Knowledge Kitchen, https://datenwgknowledgekitchen.com/ki-co2-simulator.html — Abruf mit Datum angeben. Weiterverwendung mit Quellenangabe erwuenscht.
- **Hinweis fuer Agenten:** Diese Markdown-Fassung enthaelt den Fliesstext der Seite. Interaktive Elemente (Regler, Filter, animierte Charts) sind nur in der HTML-Fassung nutzbar; die zugehoerigen Zahlen stehen hier als Tabelle.
- **Methodenstand:** 3. Juli 2026 · Sprachen: DE/EN · rein clientseitig
---
## Was das Werkzeug rechnet
Der Simulator schaetzt Energieverbrauch und CO₂-Ausstoss der KI-Nutzung einer Organisation. Er rechnet **nicht** mit Punktwerten, sondern durchgaengig mit Min–Max-Baendern: jede Eingangsgroesse ist eine Spanne, das Ergebnis ist eine Spanne. Das ist Absicht — die publizierten Messwerte fuer Inferenz-Energie unterscheiden sich um mehr als zwei Groessenordnungen.
Rechenweg: `Tokens × Energie je 1.000 Output-Tokens × PUE × Strommix-Intensitaet`. Dazu Sensitivitaetsanalyse (welcher Parameter treibt das Ergebnis), Materialitaets-Einordnung (Anteil an der Gesamtbilanz), Szenario-Vergleich, Jahresverlauf und Mehrjahres-Projektion mit Effizienz- und Wachstumsannahme.
## Modellklassen — Energie je 1.000 Output-Tokens (Wh)
| Klasse | von | bis |
|:---|---:|---:|
| Effizient (z. B. Haiku-Klasse) | 0,15 | 0,6 |
| Mittel (z. B. Sonnet-Klasse) | 0,6 | 2,5 |
| Gross (z. B. Opus-Klasse) | 2,5 | 8 |
| Reasoning / Extended Thinking | 8 | 22 |
*Die Zuordnung von Modellnamen zu Klassen ist eine Groessenordnungs-Ableitung, keine Herstellerangabe.*
## Strommix-Voreinstellungen (g CO₂e/kWh)
| Region | von | bis |
|:---|---:|---:|
| EU-Durchschnitt (~2025/26) | 180 | 280 |
| Deutschland | 280 | 400 |
| Frankreich (nuklear) | 30 | 80 |
| USA (Durchschnitt) | 300 | 450 |
| Global (Weltdurchschnitt) | 420 | 480 |
| Kohle-intensiv (z. B. PL, Teile Asiens) | 550 | 800 |
| Erneuerbar / Wasserkraft-Region | 10 | 90 |
## Standard-Szenario (Voreinstellung)
| Groesse | Wert |
|:---|---:|
| Modellklasse | Mittel (0,6–2,5 Wh je 1.000 Output-Tokens) |
| Strommix | EU-Durchschnitt (180–280 g CO₂e/kWh) |
| PUE | 1,15–1,56 |
| Output-Anteil an allen Tokens | 30 % |
| Input-/Output-Verhaeltnis | 3:1 |
| Arbeitstage je Jahr | 220 |
| CO₂-Preis (Bewertung) | 8–30 EUR/t |
| Nutzergruppen | 120 Leicht (4.000 Tokens/Tag) · 60 Mittel (20.000) · 20 Intensiv (90.000) · 1 Poweruser (250.000) |
## Anhang: Quellen & Annahmen
| Parameter | Genutzter Bereich | Quelle & Begruendung |
|:---|:---|:---|
| ⚡ Energie je 1.000 Output-Tokens (Modell-Tiers) | 0,15 – 22 Wh, je nach Modellklasse | Abgeleitet aus Googles Vollstack-Messung für einen realen Gemini-Prompt (Median: 0,24 Wh / 0,03 g CO₂e; vor 12 Monaten rund 33× höher), Mistral AI’s eigener Lebenszyklus-Wert (~1,14 g CO₂e je ~400-Token-Antwort) sowie Cross-Modell-Benchmarks wie dem ML.Energy-Leaderboard (Uni Michigan) und dem AI Energy Score (Hugging Face/Salesforce), die für lange Prompts Spannen bis über 29 Wh zeigen. Diese Werte sind pro Prompt veröffentlicht, nicht pro 1.000 Tokens — die Tool-Tiers sind daher eine Größenordnungs-Ableitung. [Google (2025)](https://cloud.google.com/blog/products/infrastructure/measuring-the-environmental-impact-of-ai-inference), [Google Technical Paper](https://services.google.com/fh/files/misc/measuring_the_environmental_impact_of_delivering_ai_at_google_scale.pdf), [CNaught (2026)](https://www.cnaught.com/blog/how-much-carbon-does-ai-actually-use-and-why-its-so-hard-to-find-out) |
| 🏭 PUE (Rechenzentrums-Effizienz) | 1,15 – 1,56 | Uptime Institute Global Data Center Survey 2024/2025: Branchendurchschnitt 1,56 (2024) bzw. 1,54 (2025-Erhebung); neue Großanlagen erreichen 1,3 und teils deutlich weniger. [Uptime Institute (2024)](https://datacenter.uptimeinstitute.com/rs/711-RIA-145/images/2024.GlobalDataCenterSurvey.Report.pdf) |
| 🔌 Strommix — EU-Durchschnitt | 180 – 280 g CO₂/kWh | Ember: EU-Durchschnitt 242 g/kWh (2023), fallend von 292 g (2022); Trend seither weiter rückläufig. [Ember via REGlobal (2024)](https://reglobal.org/coal-continues-to-be-undercut-by-new-wind-and-solar-in-eu-ember/) |
| 🌍 Strommix — Global / Deutschland / Kohle-Beispiel | Global 420–480; Deutschland 280–400; Polen (Kohle-Beispiel) 550–800 g CO₂/kWh | Ember Global Electricity Review 2026: 458 g/kWh weltweit (2025); IEA: 445 g/kWh (2024), Prognose 400 g/kWh (2027). Ember: Deutschland 371 g/kWh, Polen 662 g/kWh (jeweils 2023). [Ember (2026)](https://ember-energy.org/latest-insights/global-electricity-review-2026/electricity-demand-and-supply-trends/), [IEA (2025)](https://www.iea.org/reports/electricity-2025/emissions) |
| 🚗 Auto-Vergleichsfaktor | 150 g CO₂/km (Fahrzeugbestand) | EEA: Neuwagen EU 2025 im Schnitt 96,7 g/km (WLTP-Testwert, nur Neuzulassungen, stark EV-getrieben fallend). Der reale Fahrzeugbestand inkl. älterer Fahrzeuge und Realverbrauch liegt praxisnah spürbar höher — das Tool nutzt dafür 150 g/km als Näherung. [EEA (2026)](https://www.eea.europa.eu/en/newsroom/news/average-co2-emissions-from-new-cars-and-vans-significantly-decreased-in-2025) |
| 🛫 Flug-Vergleichsfaktor | 246 g CO₂e/km (Kurzstrecke/Inland, pro Passagier) | Our World in Data, basierend auf den offiziellen Emissionsfaktoren des UK Department for Energy Security and Net Zero: Inlandsflüge ~246 g CO₂e/Passagier-km, Kurzstrecke ~154 g/km. Das Tool nutzt den höheren Inlandsflug-Wert als griffigen Vergleichspunkt. [Our World in Data](https://ourworldindata.org/travel-carbon-footprint) |
| 📱 Smartphone-Ladung | ~8,5 g CO₂e je Ladung | Eigene Kurzrechnung: ca. 15–20 Wh Akkukapazität ÷ Ladeeffizienz × globaler Strommix-Durchschnitt (Ember, s. o.) ≈ 8–9 g CO₂e pro voller Ladung. |
| 🌳 CO₂-Bindung pro Baum | ~20 kg CO₂/Jahr (Literaturspanne: 10–25 kg) | Breit genutzte Faustregel, u. a. zitiert von Umweltinitiativen; je nach Baumart, Alter und Studie schwankt der Wert erheblich. [Reboxed / Ecologi](https://reboxed.co/blogs/outsidethebox/carbon-neutral-phones-how-planting-trees-can-offset-the-lifetime-carbon-footprint-of-your-phone) |
| 💶 Kompensationspreis (freiwilliger CO₂-Markt) | 8 – 30 €/t CO₂e (Standard-Zertifikate) | 2026-Marktdaten für den freiwilligen CO₂-Markt: durchschnittliche Zertifikatspreise ca. 8–30 €/t, mit großer Spanne je nach Projekttyp und Qualität — von REDD+/Wald-Erhalt (~6 $/t) über Aufforstung/verbessertes Waldmanagement (~15–22 $/t) bis zu technischer CO₂-Entnahme wie Biochar oder Direct Air Capture (170–500+ $/t). Diese Spanne ist bewusst konservativ für „Standard"-Zertifikate gewählt; Premium-Removal-Zertifikate liegen deutlich höher. [Sylvera (2026)](https://www.sylvera.com/blog/carbon-offset-price), [Senken (2026)](https://www.senken.io/academy/carbon-credit-price) |
## Grenzen
- Der Simulator schaetzt **Betriebsenergie der Inferenz**. Training, Herstellung der Hardware und Netzwerk-Overhead sind nicht enthalten.
- Die Energie-je-Token-Werte sind aus Pro-Prompt-Messungen abgeleitet; kein Hersteller publiziert belastbare Pro-Token-Werte je Modell.
- Alle Rechnungen laufen im Browser; es werden keine Daten an einen Server gesendet.
==============================================================================
DOKUMENT: https://datenwgknowledgekitchen.com/md/visual-standards-rechner.md
==============================================================================
# Visual-Standards-Rechner: Paid, Flexibel oder MacGyver?
> Indikations-Rechner: Was kostet die Umsetzung visueller Standards in Power BI mit 3rd-Party-Visuals, Open Source, Deneb oder Core Visuals — über 3, 5 oder 10 Jahre, je Viewer und Jahr, mit K.O.-Kriterien, Bandbreiten statt Punktwerten und Excel-Export.
- **Quelle:** https://datenwgknowledgekitchen.com/visual-standards-rechner.html
- **Autor:innen:** Michael Tenner & Diana Ackermann · Daten-WG Knowledge Kitchen
- **Anlass:** Pre-Conference „Visual Standards in Power BI für Controlling und Finance | Von Paid über Flexibel bis MacGyver", Daten-WG 2026, 14.10.2026, Köln
- **Stand:** v0.20 · 09/2026 (drei Ebenen nach Shneiderman plus ein gefuehrter Einstieg davor; Annahmen-Audit Runde 2 vom 11.09.2026. Pakete A und B: gepaarte Ziehung, Cash-out je Jahr, Amortisation, Stunden und FTE, P50/P75/P90, Ausstiegskosten, Viewer-Deckel, drei neue Anforderungen, Modifier „Organizational Store". Paket C1: Jahresschleife im Rechenkern mit fuenf neuen Annahmen. Paket C2: sieben neue Anforderungen, sechs neue Red Flags, Adoptionsgrad, Semantikmodelle, Verteilweg, Vorlaufzeit, CapEx/OpEx, Stunden-Anker, Unsicherheit im Mengengeruest und Sicherheits-Leiste. v0.13: Entscheidungspfad, Wirkungsgraph, Entscheidungsbaum, ohne die Rechenlogik zu aendern. v0.14: Report-Klassen und IBCS-Pflicht als eigener Kostentreiber. v0.15: Anbieter-Angebote als haerteste Evidenz im Modell. v0.16: gefuehrter Einstieg (Ebene 0) und Lesehilfe, dazu Vereinfachungen in Ebene 1 und 2 ohne Aenderung an Annahmen oder Rechenlogik. v0.17: Inhaltsverzeichnis als mitlaufende Seitenleiste und ein klickbarer Wirkungsgraph, der zugleich zweite Bedienoberflaeche ist. v0.18: die Lizenzmenge kennt die Report-Klassen — Korrektur aus einer unabhaengigen Pruefung, sie wirkt zugunsten von 3rd-Party paid. v0.19: der Wirkungsgraph steht vor den Eingaben statt am Seitenende, das Inhaltsverzeichnis gruppiert nach Seitenbereich. v0.20: Aufraeum-Durchgang vor der 1.0 — Barrierefreiheit, Grenzen-Abschnitt, Pruefinfrastruktur im Repository) · Sprache DE · rein clientseitig, keine Server-Anbindung
- **Zitierhinweis:** Michael Tenner & Diana Ackermann, Daten-WG Knowledge Kitchen, https://datenwgknowledgekitchen.com/visual-standards-rechner.html — Abruf mit Datum angeben.
- **Hinweis fuer Agenten:** Diese Markdown-Fassung beschreibt Modell, Voreinstellungen und Quellenlage. Regler, Simulation, Charts und Export sind nur in der HTML-Fassung nutzbar.
- **Offenlegung:** ChartKitchen byDatenWG, das Beispiel fuer „Open Source / Eigenentwicklung", ist ein Projekt der Autor:innen.
---
## Was das Werkzeug rechnet
Der Rechner vergleicht vier Ansaetze, IBCS-nahe Standard-Charts (Abweichung, Wasserfall, Δ-Tabellen, KPI-Karten, Zeitreihen AC/PY/PL/FC) in Power BI umzusetzen:
| Ansatz | Etikett | Beispiele | Haupt-Kostentreiber |
|:---|:---|:---|:---|
| 3rd-Party paid | Paid | Zebra BI, Inforiver, graphomate | Lizenz je Nutzer, Staffel oder Site-Lizenz |
| Open Source / Eigenentwicklung | Flexibel · fertig | ChartKitchen byDatenWG, Charticulator-Fork | Freigabe, Governance, Wartung, Abkuendigungsrisiko |
| Deneb / Vega | Flexibel · Code | Vega-Lite-Templates, Business Chart Builder | Lernkurve, Template-Pflege, Wartung |
| Core Visuals + SVG | MacGyver | Overlapping Bars, DAX-UDF / SVG-Measures | Workaround-Wartung, Pruefnachweis, Capacity |
Er ist eine **Indikation unter Unsicherheit**, kein Angebot und kein Business Case. Jede Annahme ist eine Dreipunkt-Schaetzung (min · wahrscheinlich · max), aus der per PERT-Verteilung 1.500 Szenarien gezogen werden. Ausgegeben werden P10, P50 und P90.
## Aufbau: ein Einstieg plus drei Ebenen (Overview first, zoom and filter, details on demand)
- **Ebene 0, Einstieg (neu seit v0.16):** sieben kurze Fragen, die vor Ebene 1 stehen und nur bestehende Felder setzen — keine eigene Rechenlogik, keine geaenderte Annahme, kein eigener Zwischenzustand. Ersteller und Viewer (oder ein Preset), Standard-Reports und der Anteil mit IBCS-Bedarf ueber drei Report-Klassen-Vorlagen (operativ 70/20/10, gemischt 45/35/20, Management 20/40/40 — Autoren-Presets, keine Quelle), Betriebsmodell, fuenf haeufige Red Flags (von 17, mit Verweis auf die restlichen in Ebene 2), Lizenz-Anker oder ein Anbieter-Angebot, Horizont, Abschluss mit Zwischenstand. Jede Antwort rechnet sofort im Hintergrund mit. Ein Link mit Einstellungen ueberspringt den Einstieg automatisch; der Einstieg selbst steht nicht im Share-Link (Feldname `sv` bleibt 4) und erscheint nicht im Ausdruck. Ueber die Werkzeugleiste jederzeit neu startbar; der Button „Direkt zum Rechner" (`#wiz-skip`) fuehrt sofort nach Ebene 1.
- **Ebene 1, Ueberblick:** drei Eingaben (Ersteller, Viewer, Betriebsmodell) oder ein Preset, dazu der Lizenz-Anker fuer Paid (Inforiver-Niveau 33 €, Mischpreis 80 €, Zebra-Niveau 170 € — abgeleitet, siehe Voreinstellungen) und der Schalter „Vorlagenbibliothek fuer Deneb und Core vorhanden" (Default aus, weil der IBCS Chart Builder ein eigenes Projekt ist); der Satz nennt, wer bei allen drei Ankern mit und ohne Bibliothek vorn liegt; ein Chart mit den Kosten je Viewer und Jahr als P10–P90-Band je Ansatz; ein Satz mit Rangfolge, Faktoren und der Viewer-Zahl, ab der die Lizenz je Kopf dominiert; zwei Zeilen dazu, was belastbar ist und was nicht.
- **Ebene 2, Eingrenzen:** Mengengeruest komplett (inklusive Report-Klassen und IBCS-Pflicht-Schalter), Anbieter-Angebote, Anforderungen, Red Flags, Ergebnis mit Rangfolge, K.O.-Block und Null-Option. Seit v0.16 steht hier zusaetzlich eine **Lesehilfe** direkt ueber dem Ergebnis, die in vier Klicks zu Entscheidungspfad, Rangfolge mit Baendern, Report-Klassen und Sicherheits-Leiste springt, und das **Glossar „Begriffe kurz erklaert"**, von Ebene 3 hierher vorgezogen und erweitert (Fachbegriffe wie P50, PERT, MoSCoW, K.O., Volumenstaffel, Barwert, Red Flag, Lizenz-Anker werden bei Erstnennung in einem Halbsatz erklaert). Seit v0.17 laeuft links ein **Inhaltsverzeichnis** mit, das alle Abschnitte und die wichtigsten Ergebnis-Bloecke fuehrt und beim Klick auf einen tieferen Eintrag selbst die Ebene wechselt.
- **Ebene 3, Details:** Annahmen mit Badges, Charts und Kostentabelle, Einschaetzung je Ansatz, Monte-Carlo-Seite, Quellen; alles eingeklappt und einzeln zu oeffnen. Seit v0.16 zusaetzlich vier Feineinstellungen, die aus Ebene 2 hierher gewandert sind (Semantikmodelle, Adoptionsgrad, Unsicherheit im Mengengeruest, Stunden-Anker — unveraenderte Voreinstellungen, unveraenderte Rechnung, an ihrer alten Stelle in Ebene 2 steht ein Hinweis). Die Ebene steht im Share-Link. Seit v0.17 ist der Wirkungsgraph hier klickbar und zugleich Bedienoberflaeche (siehe eigener Abschnitt).
## Klickpfad im Detail
0. **Einstieg (Ebene 0):** sieben Schritte wie oben beschrieben; wer den Rechner kennt, klickt „Direkt zum Rechner" und landet in Ebene 1 mit den Standardwerten.
1. **Mengengeruest:** Ersteller, Viewer (bis 10.000+), Standard-Reports (mit Erfahrungswert je Betriebsmodell), **Charts je Report** (seit v0.14 ein berechnetes Feld, siehe Report-Klassen), Chart-Typen, **Chart-Mix nach Komplexitaet** (seit v0.14 ebenfalls berechnet, aus den Report-Klassen abgeleitet; ein Experten-Override kann weiterhin einen einzigen globalen Mix erzwingen — Standard bleibt die Mischung 50 / 35 / 15, fuer die die Panel-Stunden gelten), Horizont 3/5/10 Jahre, **Report-Klassen** (A operativ ohne IBCS-Bedarf, B IBCS-Standard, C IBCS anspruchsvoll — je Anteil, Charts je Report und Chart-Mix einzeln aenderbar) mit dem Schalter **„IBCS verbindlich fuer alle Reports"**, Betriebsmodell (Enterprise BI, Managed Self-Service, Self-Service, stufenlos hybrid), heutiger Ansatz und Bestands-Reports fuer die Migration.
2. **Anbieter-Angebote (seit v0.15):** bis zu drei Angebote (Anbieter, Modell pro Nutzer / Volumenstaffel / Site-Pauschale, Preis, Nutzerzahl, Mindestlaufzeit, Rabatt, Support, Preisgleitklausel, Notiz); maximal eines aktiv. Ab zwei Angeboten eine Vergleichstabelle mit Paid-Gesamtkosten, Kosten je Viewer, Rang und Verhandlungsgrenze.
3. **Anforderungen (MoSCoW):** 27 Kriterien mit Erfuellungsgrad 1 bis 5 je Ansatz, per Klick ueberschreibbar, eigene Zeilen moeglich (starten als „nicht geprueft"). Must mit Erfuellungsgrad 1 ist ein K.O. Seit v0.11 neu: **KI-gestuetzte Erstellung ueber PBIR / Agent-Skills** (cap 2/3/3/4, Could), **Barrierefreiheit** (Tastatur, Screenreader, Kontrast; cap 3/2/2/3, Could) und **Datenexport aus dem Visual** (Excel/CSV; cap 4/3/2/5, Should). Korrigiert: **grosse Datenmengen** von 4/3/2/2 auf 3/3/3/4 — das Datenfenster von 30.000 Zeilen ist das SDK-Limit *jedes* Custom Visuals, `fetchMoreData` hebt es auf 1.048.576 Zeilen und 100 MB an, die Core-Matrix virtualisiert mit einem 500er-Fenster; der behauptete Vorteil von Paid existiert technisch nicht.
4. **Red Flags:** 17 Governance-Schalter (nur zertifizierte Visuals, nur Core Visuals, IBCS-Zertifikat Pflicht, kein Lizenzbudget, Report Server, Embedded/Publish-to-web, Sovereign Cloud, fehlende Desktop-Gruppenrichtlinie, kein externer Dienstleister, seit v0.12 dazu deutsche Beschaffung, Mitbestimmung, Revisions-Einsicht, kein voller Vorsteuerabzug, Budgetfreigabe erst im Folgejahr, Capacity am Limit). Fuenf davon schliessen Ansaetze aus, sechs sind Modifier, der Rest warnt. Daneben steht seit v0.12 der **Verteilweg** (AppSource, Organizational Store, Datei-Import je Bericht) als eigene Auswahl. Sie wirken als K.O.-Filter vor dem Rechnen. Der Schalter „nur zertifizierte Visuals" ist seit v0.11 praeziser beschriftet: das Tenant-Setting „Add and use certified visuals only" gilt fuer **AppSource**-Visuals, nicht fuer Visuals aus dem **Organizational Store**. Dazu gibt es den Modifier **`orgstore`** („OSS-Visual wird ueber den Organizational Store bereitgestellt"): er hebt den K.O. fuer Open Source auf — wie schon `osscert` — und gilt ebenso fuer einen Deneb-Standalone-Build, **senkt aber die Freigabe-Stunden (`govIntake`) nicht**, weil das Security-Review im Haus bleibt. Im Report Server wirkt er nicht („Power BI Report Server doesn't support organizational visuals"); dort bleibt die Warnung stehen. So kippt die Empfehlung nicht still zugunsten von Open Source, sondern erst, wenn der Nutzer den Org-Store-Weg ausdruecklich bestaetigt.
5. **Annahmen:** globale und ansatzspezifische Dreipunkt-Werte mit Quellen-Badge (V verifiziert, S Such-Snippet, F Faustregel, P simuliertes Expertenpanel, E Autoren-Schaetzung, N eigene Aenderung). Dazu seit v0.15 das Badge **A** (Anbieter-Angebot) fuer den Lizenzpreis, wenn ein Angebot aktiv ist — die haerteste Evidenz im Modell, kein Parameter mit eigener Dreipunkt-Schaetzung. Fabric-Capacity mit SKU-Presets F2/F8/F64. Lizenzmodell pro Nutzer, Volumenstaffel oder Site-Lizenz (ein aktives Angebot ersetzt Lizenzmodell und Preis, siehe Kostenkern).
6. **Ergebnis:** Null-Option „kein Standard" als Vergleich ausserhalb der Rangfolge (Status quo mit Ad-hoc-Bau, Wartung, Leserzeit getrennt ausgewiesen, Rueckfragen; Break-even-Minuten Leserzeit), Rangfolge (Kostenverhaeltnis und Anforderungs-Score, Regler 70/30), ausgeschlossene Ansaetze unter dem Strich mit dem Preis der Rahmenbedingung, Konflikt-Boxen, Kostenstruktur, Break-even ueber die Viewer-Zahl mit Verhandlungsgrenze (Indifferenz-Lizenzpreis), Sensitivitaet, kumulierte Kosten, Barwert, Textbausteine zu Vorteilen, Nachteilen und versteckten Kosten, Excel-Export mit Deckblatt. Seit v0.11 zusaetzlich: **Cash-out je Jahr** getrennt nach hart (Auszahlung: Lizenz, Support, Capacity, Kurse, extern beauftragte Stunden) und weich (intern bewertete Zeit), als Tabelle und eigenes Excel-Blatt; **Amortisation gegen den Status quo** (erstes Jahr, in dem die kumulierte Summe unter der Null-Option liegt, mit und ohne Leserzeit), **interne Stunden und FTE** je Ansatz mit Kapazitaetswarnung (Konvention 1.500 h je FTE und Jahr), ein Umschalter fuer die **Entscheidungsgroesse P50 / P75 / P90** (Rangfolge nach P90 = konservativ) und die **Ausstiegskosten** als eigene Kennzahl ausserhalb der Summe und ausserhalb der Rangfolge (Bestand plus Rollout × Wiederverwendungs-Stunden × Komplexitaet × Nachbau-Faktor). Seit v0.13 zusaetzlich Entscheidungspfad, Wirkungsgraph und Entscheidungsbaum (siehe eigener Abschnitt), seit v0.14 die Karte **„Report-Klassen"** mit dem Preis der IBCS-Pflicht, seit v0.15 die **Angebots-Vergleichstabelle**, seit v0.16 die **Lesehilfe** direkt darueber.
7. **Monte-Carlo-Seite:** Schwankungsbreite ±5/10/15/20/25 % um die eigenen Eingaben, wahlweise fuer Mengengeruest und Annahmen oder nur fuer das Mengengeruest, 1.000 bis 10.000 Ziehungen. Erzeugt lokal im Browser eine eigene Auswertungsseite (neuer Tab oder HTML-Datei): Verteilung der Kosten je Viewer, Anteil je Platz 1 bis 4, hart gegen weich, Erstellung gegen Nutzung mal direkt gegen indirekt (2x2 je Ansatz), Rangkorrelationen (Spearman) fuer Mengengeruest und Annahmen, gepaarte Differenz Paid gegen Open Source und eine Skalen-Simulation bei festem Verhaeltnis Ersteller : Viewer (x0,5 bis x10) mit Kipp-Punkt.
## Kostenkern (je Ansatz, Horizont H)
```
Report-Klassen = A operativ ohne IBCS-Bedarf, B IBCS-Standard, C IBCS anspruchsvoll; je Klasse ein Anteil, Charts/Report und Chart-Mix (Default 45/35/20 %, 8/6/5 Charts, Mix 85/15/0 · 40/50/10 · 15/45/40)
Charts/Report (global) und Chart-Mix (global) = mit den Anteilen gewichtetes Mittel der drei Klassen; Experten-Override erzwingt einen einzigen globalen Mix
Klasse A = wird ohne "IBCS verbindlich" in jedem Ansatz mit den Core-Stunden und -Komplexitaetsfaktoren gerechnet ("ansatzunabhaengig"); mit dem Schalter laeuft sie im gewaehlten Ansatz wie B und C
Konformitaet= Konformitaetspruefung je neu gebautem Report der Klassen B/C (ohne Pflicht) bzw. jedem Report (mit Pflicht), plus jaehrliche Stichprobe % aus dem Bestand; Stunden je Pruefung × Stundensatz intern, fuer alle vier Ansaetze gleich
Angebot = ein aktives Anbieter-Angebot ersetzt bei Paid Lizenzmodell, Lizenzpreis bzw. Site-Pauschale, Mindestlaufzeit, Preisgleitklausel und Support als Punktwerte; die Volumenstaffel entfaellt (ein verhandelter Preis wird nicht zweimal rabattiert)
Lizenz = Summe je Jahr: Nutzer × Preis × Staffelfaktor des Jahres (Viewer wachsen ab Jahr 2, Autoren konstant, Preis steigt jaehrlich)
oder Site-Lizenz × Jahre; plus Lizenz-Administration (degressiv, bei Site 0), Support/Sponsoring, Capacity-Aufschlag
Aufbau = (Setup + Eigenentwicklung + Chart-Typen × Stunden erstmalig × Komplexitaetsfaktor) × Stundensatz-Mix
Migration = Bestands-Reports × Charts/Report × Wiederverwendungs-Stunden × Nachbau-Faktor (nur bei Wechsel)
Rollout = (Reports + Nachfrage je 1.000 Viewer + Nachfrage je Ersteller) × Charts/Report × Wiederverwendungs-Stunden × Komplexitaetsfaktor × Lernkurven-Faktor × Betriebsmodell-Faktor
Komplexitaet= (Mix einfach × f_einfach + Mix mittel × 1 + Mix komplex × f_komplex) / (0,5 × f_einfach + 0,35 + 0,15 × f_komplex) je Ansatz; bei 50/35/15 gleich 1
Lernkurve = mittlerer Faktor ueber n Charts je Ersteller nach Wright (Stunden fallen um Lernrate je Verdopplung), Panelwert = 10. Chart, Untergrenze 0,5
Null-Option = Reports × Charts × Stunden ad hoc + Wartung ad hoc + Leserzeit (Viewer × Minuten/Woche) + Rueckfragen; Vergleich ausserhalb der Rangfolge
Schulung = Vorlagen-Bauer × tiefe Schulung + Vorlagen-Nutzer × flache Schulung + Fluktuation × [Bauer × (tiefe Schulung + Einarbeitung) + Nutzer × (flache Schulung + 1/4 Einarbeitung)]
Wartung = (Setup + Entwicklung + Chart-Aufbau + 0,3 × Rollout) × Quote (geplante Anpassungen) × Abklingfaktor-Summe × Varianten-Effekt + Breaking-Updates × Fix-Stunden
Varianten-Effekt = 1 + (Betriebsmodell-Faktor − 1) × Varianten-Anfaelligkeit je Ansatz (eigene Annahme, seit v0.10 nicht mehr aus dem Design-Score)
Vorlagenbibliothek = Schalter; Stunden je Chart × Faktor je Ansatz, Schulung halb so stark
Governance = Freigabe je Visual-Paket (+20 % je weiterem Chart-Typ) + laufende Governance + Pruefnachweis (log-linear nach Organisationsgroesse, 50 bis 5.000 Viewer) + Zugriffs-Governance je 1.000 Viewer (ansatzunabhaengig) + Anwender-Support je 100 Viewer + Konformitaetspruefung IBCS (siehe Report-Klassen)
Risiko = Gefahrenrate je Jahr: Summe_y (1−dep)^y × dep × (Aufbau + 0,6 × bis dahin gebauter Rollout) × Migrationsanteil; in der Simulation ein gezogenes Ereignisjahr
Adoption = Anteil der Charts nach Standard; der Rest kostet Stunden je Chart, Wartungsquote und Rueckfragen der Null-Option (Voreinstellung 100 %, dann wirkungslos)
Modelle = Setup und Erstbau × (1 + Faktor × (Semantikmodelle − 1)); Faktor paid/oss 0,05 · deneb 0,15 · core 0,5
Verteilweg = Faktoren auf Freigabe / laufende Governance / Breaking-Updates / Vorlaufzeit: AppSource 0,5 / 0,7 / 1,0 / 1,0 · Org-Store 1,0 / 1,0 / 0,8 / 1,2 · Datei-Import 0,4 / 1,6 / 1,3 / 0,6 · offen 1,0
Vorsteuer = mit Schalter „kein voller Vorsteuerabzug“: alle harten Auszahlungen (Lizenz, Support, Capacity, Kurse, externe Stunden) × (1 + Satz); interne Zeit bleibt unberuehrt
Budget = mit Schalter „Freigabe erst im Folgejahr“: das erste Jahr bleibt leer, der Betrieb beginnt ein Jahr spaeter, der Horizont bleibt gleich
CapEx/OpEx = aktivierungsfaehig: Setup + Eigenentwicklung + Erstbau der Chart-Typen; alles Uebrige sofort Aufwand. Abschreibung linear ueber 3 oder 5 Jahre
Barwert = Zahlungsstrom je Jahr, abgezinst mit dem Kalkulationszins
```
Interne Stunden werden mit einem Bewertungsfaktor (60 = Kapazitaet frei, 100 = Vollkosten, 150 = verdraengt Fachaufgaben; Bewertungskonvention, in der Simulation konstant) und einer Lohnsteigerung bewertet. Jede Annahme wird je Szenario genau einmal gezogen, globale Annahmen sind zwischen den Ansaetzen identisch (gepaarte Vergleiche).
## Voreinstellungen (Auswahl, min · wahrscheinlich · max)
| Annahme | Wert | Quellenlage |
|:---|:---|:---|
| Stundensatz intern (Vollkosten) | 60 · 82 · 110 €/h | S: Robert Half 2026 (Befragung 06–07/2025, rund 1.500 Befragte): Controller 55.000–89.250 €, Median ≈ 76.500 €. Die alte Begruendung („wer Standards baut, liegt ueber dem Controller") ist widerlegt: StepStone nennt fuer BI-Entwickler Ø 52.800 € |
| Stundensatz extern | 90 · 118 · 210 €/h | S: erstmals ein Power-BI-spezifischer Wert (freelancermap Ø 98 €/h); Freelancer-Kompass 2026 Ø 103 €/h, IT-Branche 95 €/h — erstmals seit Erhebungsbeginn kein Anstieg, 62 % planen keine Erhoehung |
| Lizenz je Nutzer und Jahr (Paid, Einstiegspreis vor Staffel) | 40 · 80 · 150 € | S: Inforiver Analytics+ 2,40–3 $/Monat; Herstellerseiten in der Pruefumgebung nicht abrufbar. **Waehrung:** Listenpreise stehen in USD, gerechnet wird mit 1 $ = 1 €. Das ist kein konservativer, sondern ein einseitiger Fehler — Kursband ueber den Horizont rund 0,78–1,00 €/$, Paid liegt damit bis zu rund 14 % zu hoch. In Euro kontrahieren oder Kursklausel verhandeln |
| Lizenz-Anker Zebra-Niveau (Ebene 1) | 90 · 170 · 300 € (abgeleitet) | S: fuer das Power-BI-Produkt von Zebra ist 09/2026 in fuenf Suchvarianten **kein** Preispunkt mehr auffindbar; „Personal 299 $ / Team 799 $" gehoert zur abgeloesten Paketstruktur (2024). Der Anker ist aus dem Nachbarprodukt Zebra BI for Office abgeleitet (in EUR ausgewiesen: Starter ≈ 70 €, Advanced ≈ 113 € je Nutzer und Jahr) und als Ableitung gekennzeichnet |
| Lizenzpreis-Steigerung (Paid) | 1 · 5 · 15 % p.a. | S: „keine oeffentliche Preiserhoehung auffindbar" ist kein Beleg fuer 0 % — Erhoehungen kommen als **Modellwechsel**. Belegt: Inforiver Developer-Lizenz 11/2023 von 150 auf 245 $/Monat, 02/2024 fuer Neukunden abgeschafft, Bestandskunden ein Jahr zu 2.500 $/Dev, dann Named User; Zebra Paketstruktur 2025 umgestellt; Power BI Pro +40 % zum 01.04.2025. Der Vertice-Index (11,4 bis 16,4 %) misst breite Enterprise-Portfolios inklusive KI-Bundling, nicht Nischen-Visuals — deshalb Modus 5 statt 11 |
| Site-Lizenz je Jahr (Paid) | 12.000 · 40.000 · 96.000 € | S: Inforiver Domain-wide ab 12 k$ verhandelt (2026); das Maximum geht auf 96 k$ zurueck, weil „unlimited users for the entire company" wieder belegt und ab rund 4.000 Nutzern beworben ist |
| Volumenstaffel | −20 % ab 25, −40 % ab 100, −55 % ab 500, −70 % ab 2.000, −80 % ab 5.000 Nutzern, je Jahr | F: Zebra Team-Paket ≈ −46 % ab 5 Nutzern, Inforiver Domain-wide ≈ −80 % ab 2.000 |
| Stunden je Chart-Typ erstmalig (paid / oss / deneb / core) | 2–4–7.5 / 4.5–8.5–14 / 7–12–18 / 10–16–27 h | P: simuliertes Expertenpanel (20 Profile), Median |
| Stunden je Chart bei Wiederverwendung | 0.5–1–2 / 1–2–3.5 / 1–2.5–4.5 / 2–4–6.5 h | P; wichtigster ungemessener Hebel (Faktor 2 Paid zu OSS, Blindschaetzung bestaetigt, Audit haelt 1,4 fuer vertretbar) |
| Schulung Vorlagen-Bauer (paid / oss / deneb / core) | 5–8.5–15 / 8–15–26 / 20–35–58 / 18–28–43 h | P: simuliertes Expertenpanel (20 Profile), Median |
| Einarbeitung bei Fluktuation | 8–16–40 / 12–28–70 / 24–70–180 / 16–50–130 h | E: Autoren-Schaetzung; wirkt voll nur auf Vorlagen-Bauer |
| Wartungsquote p.a. in % (geplante Anpassungen) | 6–10–18 / 12–22–32 / 10–17–27 / 12–30–48 | P, im Audit um den Anteil bereinigt, der in Breaking-Updates steckt |
| Breaking-Updates p.a. / Fix-Stunden | 0.2–1–2 / 0.5–1.5–3 / 1–2–3 / 2–3–5 · 3 / 7 / 6.5 / 9.5 h | P; Deneb 3 Vorfaelle in 24 Monaten, Core 3–4 SVG-Regressionen 2025 belegt |
| Abkuendigungsrisiko p.a. (paid / oss / deneb / core) | 1–2–4 / 3–7–13 / 1–3–6 / **0,5–1,5–3** % | F: Charticulator 12/2023, Bing Maps Visual 10/2025, OKViz Synoptic v1 03/2026; Deneb gesenkt, weil Vega-Lite-Specs das Wirtsvisual ueberleben. Core angehoben: „Microsoft kuendigt nichts ab" ist ueber zehn Jahre die falsche Nullhypothese (Q&A-Erlebnisse enden 02/2027, Bing-Maps-Visual „scheduled for deprecation", R/Python in Embed und Publish-to-web seit 05/2026 leer, Legacy Card → New Card, Legacy-Matrix → pivotTable) |
| Anwender-Support je 100 Viewer und Jahr | 2–4–6 / 2.5–5.5–10 / 3–6–10 / 5–9.5–16 h | P: simuliertes Expertenpanel (20 Profile), Median; OSS im Audit gesenkt |
| Varianten-Anfaelligkeit (0 Vorlagen erzwingen Einheitlichkeit, 1 jeder baut anders) | 0,25 / 0,5 / 0,75 / 0,85 | E: bis v0.9 still aus dem Design-Score abgeleitet, seit v0.10 eigene Annahme |
| Wirkung einer Vorlagenbibliothek (× Stunden je Chart, nur bei Schalter) | 1 / 1 / 0,6 / 0,7 | E: IBCS Chart Builder, vegaviz, DenebIBCS, PowerofBI-UDFs; keine Messung |
| Komplexitaetsfaktor einfach / komplex (× Stunden je Chart) | 0,7 / 1,4 (paid) · 0,7 / 1,6 (oss) · 0,5 / 2,5 (deneb) · 0,4 / 4 (core) | E: Autoren-Schaetzung, keine Quelle; Core + SVG beim Wasserfall am teuersten |
| Lernrate je Verdopplung | 0–5–10 / 5–10–15 / 8–15–25 / 8–15–25 % | F: Wright-Lernkurve, 80–90 % bei manueller Arbeit; keine Messung fuer Power BI |
| Null-Option: Stunden je Chart ad hoc, Wartung, Leserzeit, Rueckfragen | 1–2–4 h · 20–30–45 % · 0,5–2–6 min je Viewer und Woche · 6–12–20 h je 100 Viewer | E: Autoren-Schaetzung; Leserzeit ohne unabhaengige Quelle, deshalb getrennt ausgewiesen |
| Freigabe je Visual-Paket (einmalig) | 4–8–16 / 8–24–60 / 1–4–10 / 0–2–6 h | E; +20 % je weiterem Chart-Typ; zertifiziertes OSS rechnet mit dem Paid-Wert |
| Laufende Governance p.a. | 6–16–42 / 12–30–80 / **8–18–44** / 1–3–10 h | E, log-linear nach Organisationsgroesse (×0,3 bei 50 Viewern bis ×1,3 ab 5.000). Deneb leicht angehoben: 2.0.0 als Release am 08.09.2026 („as published to AppSource"), davor 1.9.1 (31.03.) und 1.9.0 (15.03.2026) — zwei Releases in 2026, davon ein Major mit neuem Template-Format, das die Rezertifizierung durchlaeuft |
| Fluktuation, Lohnsteigerung, Kalkulationszins | 5–11–22 % · **1–3–4,5** % · 5–8–10 % | S (Finance ~10 %, IT 20–22 %) · V (WSI-Tarifarchiv: nominal 2025 +2,6 %, 2026 +3,1 %; Minimum auf 1 %, weil die Freelancer-Saetze 2026 erstmals nicht gestiegen sind) · S (KPMG Kapitalkostenstudie 2025, WACC Ø 8,5 %) |
| Betriebsmodell-Faktoren (Enterprise → Self-Service) | Owner-Anteil 10 → 100 %, Varianten ×1 → ×3, Support ×0,8 → ×1,3, Governance ×1 → ×1,6 | E |
| Reports je Ersteller (Erfahrungswert) | Enterprise ≈ 6, Managed ≈ 4, Self-Service ≈ 2, plus 2 je 1.000 Viewer | E |
| **Wartungs-Trend je Jahr (Kohortenalter)** | 85 · 95 · **103** % | E: v0.12 (C1, B3). Bis v0.11 waren es 80 · 90 · 97 % auf das Kalenderjahr. Lehman und die Code-Decay-Literatur kennen steigende, nicht sinkende Wartung; ueber 100 % ist ausdruecklich zugelassen. Nur zusammen mit der kohortenrichtigen Basis sinnvoll |
| **Rollout-Dauer fuer den heutigen Bestand** | 1 · 2 · 3 Jahre | E: v0.12 (C1, B22). Bis v0.11 landete der komplette Rollout in Jahr 0 — im Grosskonzern-Preset 1.200 Reports × 8 Charts in einem Jahr mit 200 Erstellern, rechnerisch belastbar und betrieblich frei erfunden |
| **Produktivitaetsgewinn je Jahr** (paid / oss / deneb / core) | −1·0·2 / −1·0,5·3 / −2·1,5·6 / −2·1,5·6 % | E: v0.12 (C1, B2). Wirkt nur auf die laufenden internen Stunden (Wartung, Breaking-Fixes, Governance, Anwender-Support, Lizenz-Administration, Nachschulung), nicht auf Rollout, Aufbau, Schulung und Lizenz. Evidenz widerspruechlich: METR-RCT 2025 misst **−19 %** bei +20 % Selbsteinschaetzung, METR-Update 02/2026 +4 bis +20 %, Peng et al. 2023 +55,8 % bei einer Greenfield-Aufgabe. Deshalb negatives Minimum und gedaempfter Modus; die Blindschaetzung (Code 8·15·25 %) ist der Ausreisser nach oben und wurde nicht uebernommen |
| **Streuung des gemeinsamen Team-Faktors** | 5 · 12 · 20 % | E: v0.12 (C1, B28). Ein lognormaler Faktor je Szenario skaliert **alle** internen Stundenannahmen **aller vier Ansaetze** gleichsinnig — ein Team, das beim Setup troedelt, ist auch beim Wiederverwenden langsam. Niveau-Band bis 18 % breiter, Differenz-Band unveraendert eng. Bewertungskonvention: wirkt nur in der Simulation, nicht im Erwartungswert |
| **Bindungsgrad beim Ausstieg** (paid / oss / deneb / core) | 0,8·0,95·1 / 0,6·0,8·0,95 / 0,2·0,4·0,6 / 0,3·0,5·0,7 | E: v0.12 (C1, B4). Anteil des Bestands, der bei einem Wechsel nach dem Horizont neu entstehen muss. Wirkt nur auf die Kennzahl „Ausstieg“, nicht auf Summe und Rangfolge. Begruendung steht in den eigenen Texten des Rechners (Vega-Lite-Specs ueberleben das Wirtsvisual, Paid-Definitionen sind an das Visual gebunden), eine Messung gibt es nicht |
| **Mindestvertragslaufzeit (Paid)** | 1 · 1 · 3 Jahre | E: v0.12 (C1, B23). Die beim Ausstieg noch laufende Restlaufzeit zaehlt in der Kennzahl „Ausstieg“ mit. Die Nischen-Vendoren veroeffentlichen ihre Vertragsbedingungen nicht |
| **Adoptionsgrad (Standardtreue)** | Voreinstellung 100 %; Vorschlag paid 70·85·95, oss 60·80·92, deneb 50·70·85, core 40·65·85 % | E: v0.12 (C2, B5). Fuer die Hoehe gibt es **keine Quelle**, die Mechanik ist der Fund. Gemessene Richtung im Modell: ein niedriger Adoptionsgrad verteuert **Paid** am staerksten (+11,6 % bei den Vorschlagswerten, Mittelstand) und **Core + SVG** fast gar nicht (+0,8 %) — weil der Ad-hoc-Satz der Null-Option unter den Standard-Stunden von Core liegt. Die Synthese erwartete das Gegenteil; bepreist ist nur der Mehraufwand, nicht der Wertverlust uneinheitlicher Charts |
| **Semantikmodelle mit Standard-Charts** | 1 (Voreinstellung); Faktor auf Setup + Erstbau: paid/oss 0,05 · deneb 0,15 · core 0,5 je weiterem Modell | E (Faktoren), belegt in der Richtung: ein Custom Visual ist ein **Tenant**-Objekt, eine DAX-UDF ein **Modell**-Objekt (`functions.tmdl` im Definitionsordner des jeweiligen Semantikmodells, Microsoft Learn). Bei 20 Modellen steigt Core im Mittelstands-Preset um 209 %, Paid um 17 % |
| **Vorlaufzeit bis Produktivfreigabe** | 4·10·26 / 2·6·16 / 1·3·8 / 0·1·3 Wochen | E: v0.12 (C2, B8). **Nicht in den Kosten**, nur in der Anzeige neben „erster Standard-Report ≈ x h“. Belegt ist nur die Zertifizierungs-Wartezeit (Learn: Update-Zertifizierung bis 3 Wochen, Produktion 10–14 Tage) |
| **Nicht abziehbare Vorsteuer** | 19 % (nur mit dem Schalter „kein voller Vorsteuerabzug“) | V: § 12 Abs. 1 UStG Regelsteuersatz; bei gemischter Taetigkeit den Pro-rata-Schluessel eintragen. Reverse Charge ist bei vollem Vorsteuerabzug ein Nullsummenspiel — fuer Bank, Versicherung, Krankenhaus und oeffentliche Hand wird die Umsatzsteuer zu echten Kosten. Trifft Paid am staerksten (Mittelstand +10,1 %, Core +6,7 %) |
| **Fabric-Capacity (Presets)** | F2 2.200 · 2.900 · 3.700 € · F8 8.700 · 11.500 · 14.800 € · F64 70.000 · 92.000 · 118.600 € je Jahr | S: v0.12 (C2, B24), aus dem EUR-Anker 0,2115 €/CU/h West Europe hochgerechnet. **Gegenprobe widerspruechlich:** eine deutsche Quelle nennt 268 €/Monat fuer F2, was sich weder als Pay-as-you-go (309 €) noch als Reserved (182 €) darstellen laesst. Die Capacity-Jahreskosten stehen per Default auf 0, die Presets aendern deshalb keine Preset-Zahl |
| **Komplexitaetsfaktor komplex, angeglichen** | oss 1,4 · 1,9 · 2,9 (vorher 1,3 · 1,6 · 2,2) · core 2,2 · 3,5 · 5,5 (vorher 2,5 · 4 · 6) | E: v0.12 (C1, B26). Mitte zwischen Autoren-Schaetzung und unabhaengiger Blindschaetzung. Die Anhebung bei oss belastet das eigene Projekt der Autoren, die Senkung bei core entlastet den Ansatz, den sonst niemand vertritt |
| **Report-Klassen: Anteile, Charts/Report, Chart-Mix** (A / B / C) | Anteile 45 / 35 / 20 %; Charts/Report 8 / 6 / 5; Chart-Mix einfach/mittel/komplex 85/15/0 · 40/50/10 · 15/45/40 % | E: v0.14, keine Quelle. Eure Eingabe, kein gemessener Erfahrungswert; die drei Vorlagen des Einstiegs (operativ 70/20/10, gemischt 45/35/20, Management 20/40/40) sind ebenfalls Autoren-Presets. Daraus folgt der Default **6,7 Charts je Report** (vorher als fester Wert 6) und der globale Chart-Mix als gewichtetes Mittel |
| **Konformitaetspruefung IBCS je Report** (`ibcsCheckH`) | 0,5 · 1,5 · 4 h | E: v0.14, keine Quelle und keine Messung. Fuer alle vier Ansaetze gleich: die Pruefung eines Reports gegen die IBCS-Regeln ist ein menschlicher Durchgang, unabhaengig vom Werkzeug |
| **Jaehrliche Stichprobe aus dem Bestand** (`ibcsSample`) | 5 · 15 · 30 % | E: v0.14, keine Quelle. 15 % heisst: jeder Report wird im Schnitt alle sieben Jahre erneut geprueft |
Quellenlage aller 58 Annahmen (25 global, 33 je Ansatz; Zaehlung ueber `const GLOBAL` und `const OPTP` im Code, Stand v0.16): **3 verifiziert (V), 9 Such-Snippet (S), 3 Faustregel (F), 9 simuliertes Expertenpanel (P), 34 Autoren-Schaetzung (E)**. Seit v0.14 zaehlen die beiden Annahmen der Konformitaetspruefung (`ibcsCheckH`, `ibcsSample`) zusaetzlich als Autoren-Schaetzung dazu; die Report-Klassen selbst (Anteile, Charts/Report, Chart-Mix je Klasse) stehen nicht in dieser Zaehlung, weil sie Eingaben und keine Dreipunkt-Annahmen mit Quellen-Badge sind — der Sache nach sind auch sie unbelegte Autoren-Presets. Die neue **Sicherheits-Leiste** in Ebene 2 zeigt je Ansatz, wie viel der Kosten daran haengt. Seit v0.15 kommt ein sechstes Badge dazu: **A** (Anbieter-Angebot) markiert in der Sicherheits-Leiste und im Entscheidungspfad, wenn der Lizenzpreis von Paid auf einem eingetragenen Angebot statt auf einem der drei Lizenz-Anker (Snippet) beruht — die haerteste Evidenz im Modell, aber kein eigener Parameter mit Dreipunkt-Schaetzung und deshalb nicht in den 58 mitgezaehlt. Die Quellenliste im Anhang zaehlt unveraendert 39 Eintraege, davon 22 verifiziert (V) und 17 Sekundaer- beziehungsweise Such-Snippet (S). Deshalb Bandbreiten statt Punktwerte, und deshalb steht die Herkunft an jedem Wert.
**Zwei Annahmen stehen bis heute nur im Code und in keiner Annahmen-Tabelle,** obwohl sie spuerbar wirken: die Normierungs-Mischung des Chart-Mix (`cx0` = 50 / 35 / 15 — die Mischung, fuer die die Panel-Stunden je Chart gelten) und der Lernkurven-Anker („der Panelwert ist der 10. Chart je Ersteller"). Sensitivitaet: Anker 10 → 20 hebt die Stunden der Code-Ansaetze um rund 18 %; eine Panel-Mischung 40 / 35 / 25 statt 50 / 35 / 15 senkt den Komplexitaetsfaktor von Core auf 0,76. Beide sind seit v0.11 im Ehrlichkeits-Hinweis der HTML-Fassung benannt.
## Rahmenbedingungen, die das Ergebnis kippen
- **IBCS-Zertifikat Pflicht + kein Lizenzbudget:** unloesbar, keines der betrachteten kostenlosen Visuals ist IBCS-zertifiziert (Zebra BI, Inforiver, graphomate, hi-chart sind es).
- **Nur zertifizierte Visuals im Tenant:** nicht zertifizierte Open-Source-Visuals aus AppSource laden im Service nicht (Microsoft Learn); ChartKitchen ist aktuell nicht zertifiziert. Das Tenant-Setting gilt aber **nicht fuer den Organizational Store**: was die Admins dort freigeben, laedt auch unzertifiziert. Der Modifier `orgstore` hebt den K.O. deshalb auf — ohne die Freigabe-Stunden zu senken und ohne im Report Server zu wirken.
- **Copilot als Must:** Copilot erstellt und bearbeitet Reports nur mit Core Visuals. KI-Readiness entsteht im Datenmodell, nicht im Visual.
- **Report Server, Sovereign Cloud, Publish-to-web, Embedded (app owns data):** ueber AppSource lizenzierte Visuals werden dort nicht durchgesetzt oder nicht unterstuetzt.
- **Ueber 2.000 Nutzer mit Listenpreis:** Hersteller verhandeln Staffeln oder Site-Lizenzen; Lizenzmodell umstellen.
- **IBCS verbindlich fuer alle Reports (seit v0.14):** kein K.O., aber im Enterprise-Preset der groesste einzelne Kostentreiber der Report-Klassen — verlagert die operative Klasse A in den gewaehlten Ansatz und macht die Konformitaetspruefung fuer jeden Report zur Pflicht statt nur fuer die Klassen B und C.
## Grenzen
- Nicht enthalten: Power-BI-Grundlizenzen (fuer alle gleich), Nutzen-Seite (nur als Score und „€ je Anforderungspunkt"), Steuern (§ 50a EStG bei Lizenzen auslaendischer Anbieter), Datenmodell und Datenaufbereitung. **Aktivierung und Abschreibung** sind seit v0.12 als eigene Ausgabe enthalten (CapEx/OpEx-Split, § 248 Abs. 2 HGB / IAS 38 / § 5 Abs. 2 EStG), aber ausdruecklich als Einordnung und nicht als Bilanz- oder Steuerberatung; die Zuordnung im Einzelfall bleibt ungeprueft.
- **Anbieter-Angebote (seit v0.15) werden nicht geprueft.** Waehrung, Menge und Gueltigkeit eines eingetragenen Angebots sind ungepruefte Eingaben; ein Angebot in USD wird wie eines in EUR gerechnet, ein abgelaufenes Angebot bleibt aktiv, bis es geloescht wird. Trotzdem ist ein echtes Angebot die einzige harte Preisquelle im Modell — alles andere bei Paid sind Snippets oder Faustregeln.
- Stunden je Chart, Setup, Schulung, Wartung, Breaking-Updates und Support stammen aus einem simulierten Expertenpanel (20 Rollenprofile, per Sprachmodell unabhaengig geschaetzt, Median je Wert; Rohdaten unter sessions/visual-standards-rechner-reviews/). Das ist strukturierte Meinung, keine Messung, und die wichtigste Stellschraube.
- Preise stammen ueberwiegend aus Such-Auszuegen der Herstellerseiten (Stand 09/2026) und sind vor einer Entscheidung beim Hersteller zu pruefen.
- **Paginated Reports (RDL) sind nicht enthalten.** Power-BI-Custom-Visuals existieren dort nicht — weder gekaufte noch Deneb noch ein Core-Visual aus dem Bericht. Wer ein Berichtsheft druckt oder pixelgenau verschickt, baut es in RDL ein zweites Mal, und zwar bei allen vier Ansaetzen gleichermassen; der Rechner bildet diesen zweiten Bau in keinem Ansatz ab.
- Die **Null-Option** ist der am schwaechsten belegte Teil. Eine unabhaengige Blindschaetzung (09/2026, ohne Kenntnis der gesetzten Werte) kam auf 15 · 30 · 50 % Wartungsquote (hier 20 · 30 · 45), 3 · 8 · 15 Minuten Leserzeit je Viewer und Woche (hier 0,5 · 2 · 6) und 40 · 120 · 300 Stunden Rueckfragen je 100 Viewer und Jahr (hier 6 · 12 · 20). Alle drei hoeheren Werte wuerden die These „ein Standard lohnt sich" stuetzen — genau deshalb stehen sie als Spannweite hier und nicht in den Voreinstellungen.
- Plaetze mit ueberlappenden P10–P90-Baendern sind statistisch nicht unterscheidbar und werden zusammengefasst. Bei kleinen Mengen ist Paid gegen Open Source mit der vorliegenden Evidenz nicht entscheidbar; wer die Rangfolge braucht, muss messen (fuenf Charts mit beiden Werkzeugen bauen), nicht rechnen.
## v0.8: Chart-Mix, Lernkurve, Null-Option
Drei Punkte aus der Grundannahmen-Kritik (`sessions/visual-standards-rechner-audit/grundannahmen-kritik.md`) sind umgesetzt. **Chart-Mix:** drei Komplexitaetsklassen mit Anteilen; je Ansatz zwei Faktoren (einfach, komplex) gegenueber der mittleren Klasse, normiert auf die Standard-Mischung, fuer die die Panel-Stunden gelten. Core + SVG verteuert sich bei Wasserfall und Szenario-Notation um Faktor 4, Paid um 1,4. **Lernkurve:** Stunden je Chart bei Wiederverwendung fallen nach Wright mit der Zahl der Charts je Ersteller; kleine Teams zahlen mehr als den Panelwert, grosse weniger (Grosskonzern Core 0,80, Pilot 1,03). **Null-Option:** Status quo ohne Standard mit Ad-hoc-Bau, Wartung, Rueckfragen und Leserzeit; die Leserzeit ist der am wenigsten belegte Wert und wird getrennt gezeigt, dazu die Minuten je Viewer und Woche, ab denen sich der guenstigste zulaessige Ansatz rechnet. Nicht umgesetzt: Koexistenz, Restwert, Korrelationen, Risikoaversion.
## v0.11: Zeitdynamik, Cash-out und neue Anforderungen (Annahmen-Audit Runde 2)
**Zeitdynamik ueber 3, 5 und 10 Jahre.** Der Rollout entsteht nicht an einem Tag: der Zuwachs (Nachfrage je 1.000 Viewer und je Ersteller) faellt je Jahr an und traegt deshalb die **Lohnsteigerung** des jeweiligen Jahres, statt komplett in Jahr 0 gebucht zu werden. Das Viewer-Wachstum bekommt einen **Deckel** (`S.viewerCap`, Eingabefeld in Schritt 1, Voreinstellung Belegschaft beziehungsweise ersatzweise das Dreifache der heutigen Viewer): ohne ihn waechst ein Grosskonzern bei 30 % Wachstum und zehn Jahren Horizont von 10.000 auf 106.000 Leser, was das obere Band ungleich verzerrt — die Lizenz je Kopf skaliert linear, Governance nur log-linear. **Nicht umgesetzt ist ein Restwert am Horizontende:** durchgerechnet entlastet er Paid am staerksten (Mittelstand −4,8 % gegen Open Source −2,8 %) und liegt im Konzern bei 0,1–0,6 %; wirksam ist statt dessen das Gegenstueck, die Wechselverpflichtung nach dem Horizont, und die steht als **Ausstiegskosten** ausserhalb der Summe.
**Neue Ausgaben.** (1) **Cash-out je Jahr**, getrennt nach hart (Auszahlung: Lizenz, Support, Capacity, Kurskosten, extern beauftragte Stunden) und weich (intern bewertete Zeit) — als Tabelle und als eigenes Excel-Blatt; Jahr 0 ist das Aufbaujahr. (2) **Amortisation gegen den Status quo**: das erste Jahr, in dem die kumulierte Summe eines Ansatzes unter der kumulierten Null-Option liegt, mit und ohne Leserzeit — ohne Leserzeit ist die zweite Zahl die belastbare. (3) **Interne Stunden und FTE** je Ansatz mit **Kapazitaetswarnung**, Konvention 1.500 Stunden je FTE und Jahr, offen benannt. (4) Umschalter fuer die **Entscheidungsgroesse P50 / P75 / P90** („mittlerer Fall / vorsichtig / Worst-Case-nah"); die Rangfolge nach P90 ist die konservative Lesart, der Barwert bleibt Nebenzeile. (5) **Ausstiegskosten** als eigene Kennzahl ausserhalb der Summe und ausserhalb der Rangfolge: Bestand plus Rollout, mal Charts je Report, mal Wiederverwendungs-Stunden, mal Komplexitaetsfaktor, mal Nachbau-Faktor — ohne neue Annahme, genaehert mit den Werten des verlassenen Ansatzes.
**Gepaarte Ziehung als Schalter, Default gepaart.** Je Parameter-ID gibt es einen eigenen Zufallsstrom, den alle vier Ansaetze in einem Szenario teilen; die Differenz zweier Ansaetze wird damit nicht mehr von gemeinsamen Annahmen verrauscht. Das ist ehrlicher und unbequem: der Anteil der Szenarien, in denen Open Source guenstiger ist als Paid, faellt im Mittelstand von rund 12 % auf rund 5 %. **Einschraenkung, die man kennen muss:** die Paarung ist unvollstaendig. Sie wirkt ueber die Parameter-ID, also nur dort, wo beide Ansaetze denselben Parameter haben; ansatzspezifische Parameter ohne Gegenstueck (etwa `lic` oder `licSite`, die es nur bei Paid gibt) ziehen weiterhin aus einem eigenen Strom. Die Differenz ist damit gepaart bereinigt um die geteilten Annahmen, nicht um alle.
**Weitere Aenderungen im Rechenkern:** die Null-Option rechnet mit den **Core-Komplexitaetsfaktoren** des Chart-Mix (sie ist per Definition Core Visuals ad hoc) statt mit einem festen Wert je Chart; die Untergrenze von 50 % gilt jetzt auf dem **Produkt** Vorlagenbibliothek × Lernkurve, nicht mehr nur auf der Lernkurve — vorher fiel die Deneb-Wiederverwendung mit Bibliothek und Maximalwerten auf 0,71 h und damit unter Paid (0,94 h), ein Artefakt zugunsten des eigenen Template-Projekts der Autor:innen.
**Neue Defaults mit Quelle** (Begruendung je Wert in der Tabelle oben): Stundensatz intern 60 · 82 · 110 €/h, Stundensatz extern 90 · 118 · 210 €/h, Lohnsteigerung 1 · 3 · 4,5 %, Lizenzpreis-Steigerung 1 · 5 · 15 %, Lizenz-Anker Zebra-Niveau 90 · 170 · 300 € (abgeleitet), Site-Lizenz 12.000 · 40.000 · 96.000 €, Abkuendigungsrisiko Core 0,5 · 1,5 · 3 %, laufende Governance Deneb 8 · 18 · 44 h.
**Texte richtiggestellt:** die viel zitierten „46 % schneller" stammen nicht von Zebra BI, sondern aus „More than just a standard" (blueforte gemeinsam mit der TU Muenchen, 2019: 90 Studierende, randomisierte Reihenfolge, 140,9 s statt 261,7 s je Aufgabe, rund 61 % weniger Fehler, Eye-Tracking bei sechs Personen) — Auftraggeber ist ein IBCS-Beratungspartner, also interessennah, aber kein Visual-Hersteller, und das Laborsetting liefert eine Obergrenze je Aufgabe, keine Minuten je Woche. Dazu: Waehrungshinweis statt „1 $ ≈ 1 € konservativ", Preiserhoehungen als Modellwechsel, der kostenlose Desktop-Pfad bei `nobudget` (graphomate charts fuer Power BI kostenlos und voll funktionsfaehig, im Service mit Wasserzeichen; Inforiver Premium Matrix auf dem Desktop kostenlos, lizenzpflichtig beim Veroeffentlichen — fuer Pilot und Evaluierung relevant, fuer einen Viewer-Standard nicht), und `cx0` und der Lernkurven-Anker sind benannt.
## v0.12 (Paket C1): der Rechenkern rechnet Jahr fuer Jahr
Bis v0.11 entstand jede Kostenart aus einem **Produkt von Mittelwerten**: Lizenz mal einem Lizenzfaktor, Wartung mal einer Abklingsumme, Rollout komplett in Jahr 0. Das war fuer die nominale Summe brauchbar und fuer alles, was mit Zeit zu tun hat, falsch. Seit v0.12 laeuft `calc()` als **Jahresschleife** ueber den Horizont.
- **Jahr 1 ist Aufbaujahr und erstes Betriebsjahr zugleich.** Es gibt kein separates „Jahr 0“ mehr: Setup, Eigenentwicklung, Erstbau, Erstschulung, Freigabe und Migration stehen im selben Jahr wie der erste Rollout-Jahrgang, die erste Lizenzrechnung und das erste Wartungsjahr. Der Zahlungsstrom `cf` hat damit genau **H Eintraege** (Index 0 = Jahr 1), nicht H+1.
- **`invest`** ist seither definiert als Aufbau + Migration + einmalige Freigabe + Erstschulung + **erster Rollout-Jahrgang** — nicht mehr der gesamte Rollout.
- **Bestand und Kohorten.** Jedes Jahr entsteht ein Jahrgang aus dem gehobenen Altbestand (ueber `rolloutYears` gestreckt) und dem Zuwachs (Nachfrage je 1.000 Viewer und je Ersteller). Gewartet wird **nur der vorhandene Bestand**, und jede Kohorte altert ab ihrem eigenen Entstehungsjahr.
- **Lernkurve auf die kumulierte Zahl gebauter Charts je Ersteller.** `learnSeg(a, b)` ist das Segmentmittel zwischen zwei Staenden; der erste Jahrgang bekommt keinen Rabatt mehr, den niemand erarbeitet hat. Ueber alle Jahrgaenge summiert bleibt der Effekt gleich, nur das Zeitprofil wird richtig.
- **Lizenz je Jahr** mit Staffel und **Mindestpaketen** auf die dann gueltige, gedeckelte Nutzerzahl: gekauft wird nicht je Kopf, sondern in Paketen — unter 5 Nutzern gilt das Team-Paket zu 5, darueber wird auf volle 10 aufgerundet (Zebra BI verkauft keine Einzelplaetze). Bei kleinen Mengen verteuert das die Lizenz spuerbar.
- **Abkuendigung als Gefahrenrate.** Das Ereignis kann in jedem Jahr eintreten (`(1−dep)^y × dep`), und der Schaden bemisst sich am **Bestand dieses Jahres** statt am Endbestand. In der Simulation wird ein Ereignisjahr gezogen. Das kuenstliche Risiko-Jahr `ceil(H/2)` im Zahlungsstrom entfaellt.
- **Mindestvertragslaufzeit** (`minTerm`) und **Bindungsgrad** (`lockIn`) gehen in die Kennzahl „Ausstieg“ ein, nicht in die Summe und nicht in die Rangfolge.
- **`calcSQ()` laeuft auf derselben Jahresachse**, sonst waere die Amortisation gegen zwei verschiedene Zeitachsen gerechnet.
**Fuenf neue Annahmen** (alle Badge E, Werte und Begruendung in der Tabelle oben): `rolloutYears` 1 · 2 · 3 Jahre, `teamSkill` 5 · 12 · 20 % Streuung, `prodGain` je Ansatz −1·0·2 bis −2·1,5·6 %, `lockIn` je Ansatz 0,2·0,4·0,6 bis 0,8·0,95·1, `minTerm` 1 · 1 · 3 Jahre. Dazu geaendert: `maintDecay` von 80 · 90 · 97 auf **85 · 95 · 103 %** und als **Trend je Kohortenalter** statt als Abklingen am Kalenderjahr.
**Der Team-Faktor ist Niveau-Unsicherheit, keine Rangfolgen-Unsicherheit.** Ein lognormaler Faktor je Szenario skaliert alle internen Stundenannahmen **aller vier Ansaetze gleichsinnig**: ein Team, das beim Setup troedelt, ist auch beim Wiederverwenden langsam. Bis v0.11 mittelten sich 15 unabhaengige Stundenannahmen zu einem Portfolioeffekt, den es in der Realitaet nicht gibt. Das Niveau-Band wird dadurch bis 18 % breiter, das Differenz-Band bleibt eng: „so viel kostet es“ wird ehrlicher unsicher, „dieser Ansatz ist guenstiger“ bleibt scharf. Wie `intFactor` ist der Faktor eine Bewertungskonvention — er wirkt nur in der Simulation, nicht im Erwartungswert.
**Grenzaufwand statt Horizontmittel.** Die Anzeige „jeder weitere Report ≈ x h“ zeigte bis v0.11 den Horizontmittelwert und war damit um 3 bis 13 % zu pessimistisch, am staerksten bei den Code-Ansaetzen (Mittelstand Core: 21,2 h angezeigt gegen 18,4 h marginal). Seit v0.12 steht dort der Aufwand am Bestand des letzten Jahres. Das ist der einzige Zeitfehler des Modells, der zugunsten von Paid wirkte — er gehoert korrigiert, gerade weil die Korrektur den Autoren nuetzt.
**Vorher/Nachher (nominale Summe, Erwartungswerte):** Mittelstand Paid **+4,3 %**, OSS **−0,5 %**, Deneb **−1,1 %**, Core **−1,5 %**; Konzern Paid **+0,4 %**, OSS **−2,3 %**, Deneb **−3,3 %**, Core **−4,1 %**. Die Summe aendert sich also kaum — zu billiger Rollout und zu teure Wartung haben sich bis v0.11 gegenseitig aufgehoben. Belastbar werden dadurch erst **Barwert, Zahlungsstrom, Break-even und das Kumulativ-Chart**; im Konzern mit H = 10 verschiebt sich der Barwert um mehrere Prozent je Ansatz.
## v0.12 (Paket C2): sieben Anforderungen, sechs Red Flags, vier neue Ausgaben
**Sieben neue Anforderungen** (Erfuellungsgrad paid / oss / deneb / core):
| Kriterium | Grad | Prio | Belegt? |
|:---|:---|:---|:---|
| Versionshoheit ueber das Visual (`pin`) | 2 / 5 / 3 / 1 | Should | ja: „AppSource Power BI visuals automatically update“; ein .pbiviz im Org-Store wird manuell aktualisiert. Der einzige Hebel, der Breaking-Updates wirklich senkt — und er liegt beim selbst gepflegten .pbiviz, also **beim eigenen Projekt der Autoren**. Deshalb ausdruecklich **ohne** Kostenrabatt: die Kostenfolge ist unbelegt, die Anforderung ist es nicht |
| Reist mit Git und Deployment-Pipeline (`alm`) | 2 / 2 / 4 / 5 | Could | Einzelfakten belegt (Custom Visuals sind tenant-weit registriert, Pipelines arbeiten auf Workspace-Elementen), der Schluss „das Visual reist nicht mit“ ist abgeleitet |
| Zentral per Theme-Datei steuerbar (`themeable`) | 3 / 3 / 3 / 5 | Should | Core belegt; fuer Paid, OSS und Deneb je Implementierung ungeprueft. Bei einem Corporate-Design-Wechsel ist das der Unterschied zwischen einer Datei und 100 Berichten |
| Drilldown, Drillthrough, Berichtsseiten-Tooltip (`drill`) | 4 / 3 / 2 / 5 | Should | eigene, opt-in zu implementierende SDK-Features. Der Deneb-Wert ist **nicht primaer geprueft** (deneb.guide in der Pruefumgebung blockiert). `interact` ist dafuer verengt auf „Auswahl, Cross-Highlight, Standard-Tooltip“ — „alles 4“ verdeckte, dass man nicht von Region auf Land aufreissen kann |
| Mobile Nutzung (`mobile`) | 4 / 3 / 2 / 4 | Could | Microsoft fuehrt mobile Unterstuetzung fuer Custom Visuals als „optional functionality“ mit Failover-Hinweis. Ein IBCS-Wasserfall auf 390 px ist bei jedem Weg eine Designaufgabe, bei einer festen Spec am schmerzhaftesten |
| Kopieren nach PowerPoint und Office (`copyppt`) | 2 / 2 / 3 / 5 | Could | belegt: beim „Copy visual“-Weg sind native und **zertifizierte** Custom Visuals unterstuetzt; eingeschraenkt sind **lizenzierte** Visuals, nicht zertifizierte Custom Visuals und Org-Store-Visuals. Die Einschraenkung trifft ausgerechnet Paid und den eigenen, nicht zertifizierten OSS-Weg |
| Paginated Reports / RDL (`paginated`) | 1 / 1 / 1 / 2 | Could | belegt; Trennschaerfe gering (fast alle 1), Relevanz fuer DACH-Berichtshefte hoch |
**Sechs neue Red Flags.** Bis v0.11 waren alle zehn Schalter Microsoft-Plattform-Schalter — kein einziger bildete die deutsche Entscheidungsrealitaet ab.
- **Deutsche Beschaffung / EU-Datenstandort** (`euonly`) und **Mitbestimmung** (`betriebsrat`), beide als **Warnung**, nicht als K.O.: § 87 Abs. 1 Nr. 6 BetrVG betrifft technische Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung zu ueberwachen; die Rechtsprechung legt „bestimmt“ weit aus, und nutzerbezogene Lizenzpruefung sowie Produkt-Telemetrie koennen darunterfallen. Ein K.O. waere eine Tatsachenbehauptung ueber Hersteller, die niemand belegen kann. **Der Gesetzeswortlaut war in der Pruefumgebung blockiert und ist vor Veroeffentlichung abzugleichen.**
- **Revision verlangt Einsicht in die Rechenlogik** (`revision`), Warnung: Berechnungen im gekauften Visual (Subtotale, Varianzlogik) sind nicht einsehbar; bei Core liegt alles als DAX im Modell; bei Deneb ist der Spec Text, das Vega-Transform aber ein zweiter Rechenort.
- **Kein voller Vorsteuerabzug** (`novat`), Modifier mit Kostenwirkung: erhoeht alle harten Auszahlungen um den nicht abziehbaren Anteil (Feld, Default 19 %). Reverse Charge ist bei vollem Vorsteuerabzug ein Nullsummenspiel — fuer Bank, Versicherung, Krankenhaus und oeffentliche Hand wird die Umsatzsteuer zu echten Kosten. Wirkung im Mittelstands-Preset: Paid **+10,1 %**, Deneb +7,3 %, Core +6,7 %, OSS +5,1 % — Paid am staerksten, weil dort der harte Anteil am groessten ist.
- **Budgetfreigabe erst im Folgejahr** (`budgetnext`), Modifier **mit Verdrahtung im Rechenkern**: das erste Jahr bleibt leer, Lizenz, Setup, Schulung und Rollout beginnen ein Jahr spaeter, der Horizont bleibt gleich. Ohne diese Anbindung waere der Schalter Kosmetik. Wirkung im Mittelstands-Preset rund −11 bis −12 % auf die nominale Summe im Horizont — und ein spaeterer Nutzenbeginn, den die Amortisation gegen die Null-Option sichtbar macht.
- **Capacity laeuft am Limit** (`capAtLimit`, B25), Modifier: Mehrverbrauch ueber der gebuchten SKU wird als Overage zum **dreifachen** Pay-as-you-go-Satz abgerechnet (Learn, Preview). Das ist der reale Grenzpreis der linearen Naeherung. Wirkt nur, wenn Capacity-Jahreskosten eingetragen sind (Default 0).
**Vier neue Eingaben.**
- **Adoptionsgrad** (`adopt`, B5): Anteil der Charts, die tatsaechlich nach dem Standard entstehen; der Rest wird zu Null-Options-Saetzen abgerechnet (Rollout, Wartung, Anwender-Support). Voreinstellung **100 %**, Vorschlagswerte per Knopf. Die gemessene Richtung ist die interessante Nachricht: siehe Tabelle oben.
- **Semantikmodelle** (B6): Multiplikator auf Setup und Erstbau, weil ein Custom Visual ein Tenant-Objekt und eine DAX-UDF ein Modell-Objekt ist. Bei 20 Modellen steigt Core im Mittelstands-Preset um **209 %**, Deneb um 55 %, Paid um 17 %.
- **Verteilweg** (B7): AppSource / Organizational Store / Datei-Import je Bericht, mit Faktoren auf Freigabe, laufende Governance, Breaking-Updates und Vorlaufzeit. Voreinstellung **offen** = alle Faktoren 1, damit sich die Voreinstellung des Rechners nicht still aendert. Der Modifier `orgstore` aus Paket B bleibt bestehen und wird **ergaenzt**, nicht ersetzt: der Verteilweg wirkt auf die Stunden, der Modifier auf den K.O. aus „nur zertifizierte Visuals“. Die Auswahl „Org-Store“ setzt den Modifier mit; wer beides auseinanderlaufen laesst, bekommt einen Konflikt-Hinweis.
- **Vorlaufzeit bis zur Produktivfreigabe** (`leadWeeks`, B8): **nicht in den Kosten**, nur als Anzeige auf der Ergebniskarte — „erster Standard-Report ≈ 82 h Arbeitszeit · fruehestens nach ≈ 12 Wochen“. 82 Stunden lesen sich wie zwei Wochen; real vergehen bei Paid Einkauf, Legal und AVV.
**Vier neue Ausgaben.**
1. **CapEx, OpEx und GuV-Wirkung** (B21): je Ansatz der Split aktivierungsfaehig (Setup, Eigenentwicklung, Erstbau der Chart-Typen) gegen sofort Aufwand (alles Uebrige), mit Schalter „Interne Entwicklungsstunden aktivieren“ und Nutzungsdauer 3 oder 5 Jahre. Im Mittelstands-Preset sind nur **7 bis 11 %** der Kosten ueberhaupt aktivierungsfaehig — das ist selbst die Aussage. Rechtslage: Lizenzen sind nie aktivierbar; selbst erstellte immaterielle Vermoegensgegenstaende sind nach **§ 248 Abs. 2 HGB ein Wahlrecht**, nach **IAS 38** bei erfuellten Kriterien **Pflicht**; **§ 5 Abs. 2 EStG** verbietet den Ansatz in der Steuerbilanz. Pflichthinweis: Aktivierung setzt projektbezogene Stundenerfassung voraus und ist mit dem Abschlusspruefer abzustimmen; forschungsnahe Vorarbeiten sind auch nach IAS 38 Aufwand, und „Setup“ enthaelt beides. Keine Bilanz- oder Steuerberatung. Auch im Excel-Blatt „Cash-out“.
2. **Stunden-Anker** (Autorenwunsch): drei Knoepfe im Mengengeruest setzen die vier ungemessenen Stundengroessen — Stunden je Chart-Typ erstmalig, Stunden je Chart bei Wiederverwendung, Schulung je Vorlagen-Bauer und Wartungsquote — fuer alle vier Ansaetze zugleich. **Panel (Standard)** = simuliertes Expertenpanel, **Blindschaetzung** = unabhaengige Schaetzung ohne Kenntnis der gesetzten Werte, **Konservativ (+50 %)** = Panel × 1,5. Wirkung auf die Summe (Mittelstand, P50): Blindschaetzung Paid −13 %, OSS −22 %, Deneb −8 %, Core −26 %; Konservativ Paid +22 %, OSS +46 %, Deneb +46 %, Core +59 %. Der aktive Anker steht im Ueberblicks-Satz neben Lizenz-Anker und Vorlagenbibliothek und im Share-Link (Feld `ha`). Die Lehre: der Anker verschiebt das **Niveau** stark, die Rangfolge kaum.
3. **Unsicherheit im Mengengeruest** (Autorenwunsch): Schalter 0 / ± 10 / ± 20 % zieht Ersteller, Viewer, Reports, Charts je Report und Chart-Typen je Szenario per PERT um die Eingaben — gepaart ueber alle vier Ansaetze, dieselbe Mechanik wie auf der Monte-Carlo-Seite. Default aus, Share-Link-Feld `mu`. **Die Groessenordnung ist das Ergebnis:** ± 20 % verbreitern das P10–P90-Band nur um rund 1 bis 2 %. Die Unsicherheit dieses Rechners steckt fast vollstaendig in den Annahmen, nicht im Mengengeruest — wer genauer werden will, misst Stunden, nicht Reports.
4. **Sicherheits-Leiste „Wie sicher sind diese Kosten?“** (Autorenwunsch): je Ansatz eine dreiteilige Leiste in Ebene 2, die die P50-Kosten nach der **Herkunft der treibenden Annahmen** aufteilt — *belegt* (Preisliste/Snippet: Lizenz, Support, Capacity, Kurse, externe Stundensaetze), *Faustregel* (Literatur ohne Messung: Abkuendigung), *Schaetzung* (Panel oder Autoren: alle Stundenposten, Governance, Wartungsquote). Keine neue Rechenlogik, nur eine Zuordnung je Kostenkategorie ueber den dominanten Parameter; der extern beauftragte Anteil der Stundenposten laeuft ueber den Marktpreis externer Stunden und zaehlt deshalb als belegt. Im Mittelstands-Preset: **Paid 54 % belegt / 1 % Faustregel / 45 % Schaetzung · OSS 27 / 4 / 69 · Deneb 39 / 1 / 60 · Core 35 / 1 / 64.** Der Satz in Ebene 1 nennt die beiden Zahlen fuer den guenstigsten Ansatz. Das ist die unangenehmste Ausgabe des Rechners: der billigste Weg ist regelmaessig der am schlechtesten belegte.
**Umbenennung.** Das Etikett des Paid-Ansatzes heisst ueberall **„Paid“** — in Charts, Legenden, Tabs, Tabellenkoepfen, Ueberschrift, Konferenztitel und dieser Fassung. Das bis v0.11 verwendete Etikett war eine Wertung, kein Etikett: die Lizenzfrage, der Einkauf und die Mitbestimmung sind an keiner Stelle einfach.
## v0.13: Entscheidungspfad und Wirkungsgraph
v0.13 aendert keine Zahl, sondern zeigt die Mechanik hinter den Zahlen in drei neuen Darstellungen. Der **Entscheidungspfad** (Karte `#decision-path`, Ebene 2, direkt ueber der Ergebnis-Headline) legt die Entscheidung in die sechs Knoten, in denen sie real faellt: Rahmenbedingungen (aktive Red Flags und was sie ausschliessen), Must-Anforderungen (welcher Ansatz an welchem Kriterium scheitert oder nur einen Workaround hat), Verhaeltnis Ersteller : Viewer (aktuelles Verhaeltnis, Kipp-Punkt, Chart-Mix), Lizenz-Anker und Vorlagenbibliothek (wer bei 33 / 80 / 170 € mit und ohne Bibliothek vorn liegt), Betriebsmodell (Self-Service-Anteil, Wirkung auf Varianten, Wartung und Governance, und welcher Ansatz davon am staerksten getroffen wird) und Ergebnis (Kostenrangfolge mit Platzgruppen, gewichteter Rang, Sicherheits-Anteil des Erstplatzierten, Amortisation gegen die Null-Option). Jeder Knoten traegt farbige Chips fuer die Ansaetze, die dort rausfallen oder vorn liegen, und ein Badge **belegt / Faustregel / Meinung**, das sagt, wie sicher der Knoten ist — mit derselben Zuordnung wie die Sicherheits-Leiste (verifiziert und Snippet = belegt, Faustregel = Faustregel, Panel und Autoren-Schaetzung = Meinung). Der **Wirkungsgraph** (Ebene 3, `#d-graph`) ist ein dreispaltiges Sankey-Bild je Ansatz: links die acht Eingaben, in der Mitte sieben Annahmen-Gruppen in der Farbe ihrer dominanten Herkunft, rechts die acht Kostenposten mit Betrag und Anteil; die Baender von der Mitte nach rechts sind so dick wie der Posten und summieren sich auf den P50 des Ansatzes, die duennen Linien links zeigen nur die Zuordnung, die gestrichelten Linien der Stundensaetze skalieren jeden Stundenposten, ohne einen eigenen Betrag zu tragen. Zwei Saetze unter dem Graphen nennen den dominierenden Posten und wie belegt die Gruppe ist, die ihn treibt — im Mittelstand ist das bei allen drei Stunden-Ansaetzen „Stunden je Chart“, eine Gruppe mit null belegten Annahmen. Darunter steht ein **statischer Entscheidungsbaum** ohne Szenariobezug, der dieselbe Kette als druckbares Bild zeigt (Kipp-Punkt-Bereich 1 : 30 bis 1 : 60); der Wirkungsgraph oeffnet sich beim Drucken automatisch. Alle drei Darstellungen ziehen ihre Werte aus den bestehenden Zustaenden (`lastSim`, `lastEv`, `lastRank`, `lastSQ`, `S`) und aus `certSplit`, `licenseBreakEven`, `modeParams` und `paybackYear`; der Share-Link bleibt unveraendert. **Hinweis:** der Kipp-Punkt-Bereich im statischen Entscheidungsbaum (1 : 30 bis 1 : 60) ist fest ins Bild eingezeichnet und wird nicht bei jeder Eingabe neu gerechnet — er weicht seit den Report-Klassen (v0.14) von den tatsaechlich berechneten Kipp-Punkten ab, die deutlich niedriger liegen (siehe v0.14 unten und die Voreinstellungs-Tabelle). Fuer den aktuellen Wert zaehlt die Zahl im Fliesstext von Ebene 1 und im Entscheidungspfad (`#decision-path`), nicht das statische Bild.
## v0.14: Report-Klassen und IBCS-Pflicht
Nicht jeder Report braucht eine IBCS-Spezialgrafik. Seit v0.14 werden die Standard-Reports in drei Klassen geteilt, jede mit eigenem Anteil, eigener Zahl Charts je Report und eigenem Chart-Mix:
| Klasse | Beschreibung | Anteil (Default) | Charts/Report (Default) | Chart-Mix einfach/mittel/komplex (Default) |
|:---|:---|---:|---:|:---|
| A · Operativ | Listen, Tabellen, Statusuebersichten, einfache Balken — ohne IBCS-Bedarf | 45 % | 8 | 85 / 15 / 0 % |
| B · IBCS-Standard | Abweichungsdiagramme, Zeitreihen AC/PY/PL/FC, Tabellen mit integrierten Charts | 35 % | 6 | 40 / 50 / 10 % |
| C · IBCS anspruchsvoll | Wasserfall mit Abweichungen, Kleine Multiples, Kommentierung, Drilldown | 20 % | 5 | 15 / 45 / 40 % |
Charts je Report und der globale Chart-Mix sind seitdem **abgeleitete Groessen** (mit den Klassenanteilen gewichtetes Mittel); ein Experten-Override kann weiterhin einen einzigen globalen Mix fuer alle Klassen erzwingen — Share-Links aus v0.13 und frueher, deren Chart-Mix von 50/35/15 abweicht, laden automatisch in diesen Modus und rechnen unveraendert weiter. Aus den Default-Anteilen folgt **6,7 Charts je Report** (vorher ein fester Wert von 6).
**Klasse A ist ansatzunabhaengig.** Solange IBCS nicht verbindlich ist, wird sie in jedem der vier Ansaetze mit den Stunden und Komplexitaetsfaktoren von **Core Visuals** gerechnet — Erstbau, Rollout, Wartung und Migration dieser Reports kosten deshalb bei Paid, Open Source, Deneb und Core dasselbe (bewertet allerdings mit dem Stundensatz-Mix und der Wartungsquote des jeweiligen Ansatzes, deshalb "aehnlich, aber nicht identisch"). Lizenz, Governance und Anwender-Support laufen weiterhin ueber den vollen Bestand mit.
Der Schalter **„IBCS verbindlich fuer alle Reports"** zieht auch Klasse A in den gewaehlten Ansatz und macht die **Konformitaetspruefung** (`ibcsCheckH` 0,5 · 1,5 · 4 h je Report und Pruefung, `ibcsSample` 5 · 15 · 30 % jaehrliche Stichprobe aus dem Bestand — beide Autoren-Schaetzung, bewusst werkzeugunabhaengig) fuer jeden Report zur Pflicht; ohne den Schalter wird nur geprueft, was zu den Klassen B und C gehoert (Default 55 % der Reports). Ebene 2 zeigt dazu die neue Karte **„Report-Klassen"** mit dem Preis der Pflicht, zerlegt in Pruefprozess (kostet in jedem Ansatz, weil ein menschlicher Durchgang) und Verlagerung (kann entlasten, wenn der Ansatz die operativen Reports guenstiger baut als der Core-Ansatz, den man sonst zusaetzlich pflegen muesste).
**Nachgerechnete Wirkung der IBCS-Pflicht (Erwartungswert ueber den Horizont, Presets Mittelstand und Konzern, 09/2026):**
| Ansatz | Mittelstand (5 J.) | Konzern (5 J.) |
|:---|---:|---:|
| Paid | −9 % (−6.500 €) | −9 % (−64.000 €) |
| Open Source | −1 % (−1.100 €) | −2 % (−10.000 €) |
| Deneb | −1 % (−1.000 €) | −2 % (−12.000 €) |
| Core + SVG | +2 % (+2.000 €) | +2 % (+18.000 €) |
Die Pflicht **senkt** die Kosten bei Paid, Open Source und Deneb, weil die Verlagerung der operativen Reports vom Core-Satz auf den (guenstigeren) eigenen Satz staerker wiegt als der zusaetzliche Pruefaufwand; bei Core + SVG bleibt die Verlagerung per Definition wirkungslos (dort war Klasse A ohnehin schon im eigenen Ansatz), sodass nur der Pruefprozess uebrig bleibt und die Kosten steigen. Die Rangfolge dreht dadurch in keinem der beiden Presets. Die Null-Option kennt die Klassen ebenfalls (jeder Report entsteht ad hoc, die Klassen-Mixe bestimmen nur die Komplexitaet) und hat keine Konformitaetspruefung: ohne Standard gibt es nichts zu pruefen.
## v0.15: Anbieter-Angebote
Bis zu drei echte Angebote lassen sich in Ebene 2 erfassen: Anbieter, Modell (pro Nutzer / Volumenstaffel / Site-Pauschale), Preis, Nutzerzahl, Mindestlaufzeit, Rabatt, Support (enthalten oder Betrag), Preisgleitklausel, Notiz. **Genau eines kann aktiv sein.** Ein aktives Angebot ersetzt im Rechenkern fuer Paid Lizenzmodell, Lizenzpreis bzw. Site-Pauschale, Mindestvertragslaufzeit, Preisgleitklausel und Support als Punktwerte und schaltet die Volumenstaffel ab — ein bereits verhandelter Preis wird nicht ein zweites Mal rabattiert. Neue Rechenwege entstehen dadurch nicht.
Ab zwei Angeboten vergleicht eine Tabelle Gesamtkosten, Kosten je Viewer und Jahr, Rang unter den vier Ansaetzen und die Verhandlungsgrenze (Indifferenz-Lizenzpreis) gegen den guenstigsten Stunden-Ansatz. Ein Angebot bekommt ein eigenes Quellen-Badge **A** und gilt als die haerteste Evidenz im Modell.
**Wichtig fuer die Sicherheits-Leiste:** vor v0.15 zaehlte der Lizenzpreis von Paid immer als belegt (die drei Lizenz-Anker wurden wie Preislisten behandelt). Seit v0.15 zaehlt der Lizenzpreis nur dann als belegt, wenn ein Angebot aktiv ist — die drei Lizenz-Anker sind Such-Snippets, "irgendwo im Netz stand ein Preis" ist kein Beleg fuer den eigenen Preis. Nachgerechnet (Mittelstand-Preset, Mischpreis-Anker): der belegte Anteil von Paid faellt dadurch von rund **50 % auf 19 %**; mit einem eingetragenen Angebot (Beispielrechnung: gleicher Preis, ein Nutzer-Jahr, Support enthalten) steigt er wieder auf rund **50 %**, in der Groessenordnung je nach Angebotskonditionen auch hoeher. Die Kosten selbst aendern sich durch die Badge-Umbuchung nicht — nur die Einordnung, wie sicher sie sind.
Angebote stehen im Share-Link (Felder `of`/`oa`) und in einem eigenen Excel-Blatt „Angebote", mit Datenschutzhinweis, weil das Geschaeftsdaten sind (Anbieter, Preis, Konditionen, Notiz). **Ungeprueft bleiben Waehrung, Menge und Gueltigkeit** eines eingetragenen Angebots.
## v0.16: Gefuehrter Einstieg und Lesehilfe
**Gefuehrter Einstieg (Ebene 0, `body.lv0`, Section `#wizard`):** sieben Fragen als erster Zustand vor Ebene 1 — Ersteller und Viewer (oder ein Preset), Standard-Reports und Report-Klassen ueber drei Vorlagen (operativ 70/20/10, gemischt 45/35/20, Management 20/40/40; Autoren-Presets, keine Quelle), Betriebsmodell, fuenf haeufige Red Flags mit Verweis auf alle 17 in Ebene 2, Preisbasis (Lizenz-Anker oder Angebot), Horizont, Zusammenfassung mit Zwischenstand. Der Einstieg setzt ausschliesslich vorhandene Felder und klickt die vorhandenen Bedienelemente an: keine eigene Rechenlogik, keine geaenderten Annahmen, kein eigener Zwischenzustand — jede Antwort landet sofort in den Eingaben, das Ergebnis rechnet live mit. Er erscheint nur, wenn der Link keine Einstellungen enthaelt (ein Link mit Einstellungen ueberspringt ihn automatisch), wird selbst nicht im Share-Link gespeichert (`sv` bleibt 4), ist ueber die Werkzeugleiste jederzeit neu startbar und im Druck ausgeblendet.
**Lesehilfe (Ebene 2, `#readguide`):** vier Sprungmarken direkt ueber dem Ergebnis — Entscheidungspfad, Rangfolge mit Baendern, Report-Klassen, Sicherheits-Leiste — mit je einem Satz, worauf zu achten ist.
**Vereinfachungen ohne Aenderung an Annahmen oder Rechenlogik:** Fachbegriffe (P50, PERT, MoSCoW, K.O., Volumenstaffel, Barwert, Red Flag, Lizenz-Anker) werden bei Erstnennung in einem Halbsatz erklaert. Das Glossar „Begriffe kurz erklaert" ist von Ebene 3 nach Ebene 2 vorgezogen und erweitert. Vier Feineinstellungen sind von Ebene 2 nach Ebene 3 gewandert — Semantikmodelle, Adoptionsgrad (Standardtreue), Unsicherheit im Mengengeruest, Stunden-Anker —, mit Hinweis an ihrer alten Stelle; ihre Voreinstellungen und die Rechnung bleiben unveraendert.
## v0.17: Inhaltsverzeichnis und klickbarer Wirkungsgraph
v0.17 aendert wieder keine Zahl. Sie loest zwei Probleme, die mit jeder Version groesser geworden sind: die Seite ist lang, und der Wirkungsgraph zeigte zwar, welche Eingabe wo einfliesst, war aber nur ein Bild.
**Inhaltsverzeichnis (`nav#toc`):** eine mitlaufende Seitenleiste links ab Ebene 2 mit 21 Eintraegen — die acht Abschnitte der Seite, die acht wichtigsten Bloecke des Ergebnisses und fuenf Details der Ebene 3 —, gruppiert nach Ebene und mit der aktiven Stelle per `IntersectionObserver`. Ab 1100 px Breite wird `.wrap` zum Grid `214px | minmax(0,1180px)`, die Leiste ist sticky mit eigenem Scrollbereich; darunter klappt sie als Kopfbereich auf und zu. In Ebene 0 und 1 sowie im Druck ist sie ausgeblendet. Ein Eintrag, der auf eine tiefere Ebene zeigt, wird nicht ausgegraut, sondern **wechselt beim Klick die Ebene** und oeffnet ein geschlossenes ``, bevor er springt; ein Chip „Ebene 3" am Eintrag sagt das vorher. Dazu zwei Schalter **„Alles aufklappen"** und **„Alles zuklappen"** — zum Lesen am Stueck und zum Drucken, ohne jedes Detail einzeln anfassen zu muessen.
**Der Wirkungsgraph wird klickbar (`#d-graph`, `#graph-explain`):** jeder Knoten ist `role="button" tabindex="0"` mit `aria-pressed`, per Maus, Enter und Leertaste bedienbar, Escape hebt die Auswahl auf. Eine Auswahl hebt die verbundenen Pfade hervor und blendet den Rest auf Opazitaet .13 zurueck. Darunter erklaert eine Box in ganzen Saetzen, wo die Auswahl einfliesst und wie viel sie ausmacht: die Betraege kommen aus denselben Kategorien wie bisher (`lastSim[key].cats`), die Herkunft aus derselben Zuordnung wie die Sicherheits-Leiste. Fuer Annahmen-Gruppen steht dort zusaetzlich eine **Sensitivitaet**: „alle Annahmen der Gruppe zugleich 10 % hoeher → Gesamtkosten +x €", gerechnet ueber `expected(key, override)` — also exakt der Weg des Tornado-Diagramms, nur gruppenweise statt je Annahme. Fuer Eingaben aus dem Mengengeruest (Ersteller, Viewer, Reports) wird **bewusst keine Zahl** ausgegeben: eine „10 % mehr Viewer"-Sensitivitaet waere nicht dasselbe Experiment und ist im Break-even-Chart ohnehin sauberer zu sehen.
**Der Graph als zweite Bedienoberflaeche (`#graph-pop`):** ein Klick auf einen Knoten oeffnet ein an das Element angedocktes Popup (Dialog mit Fokusfalle; unter 640 px eine vollbreite Karte statt schwebend). Was darin steht, haengt vom Knotentyp ab:
| Knotentyp | Popup zeigt |
| --- | --- |
| Eingabe | das passende **vorhandene** Bedienelement — Zahlenfeld (`#n-creators`), Segment-Schalter (`#horizon-seg`, `#ov-mode-seg`), Report-Klassen (`#rc-sh-*`), Schalter IBCS-Pflicht (`#ibcs-all`) |
| Annahmen-Gruppe | die Annahmen dieser Gruppe als Dreipunkt-Zeilen (min · wahrscheinlich · max) mit Quellen-Badge und Kurzbegruendung, editierbar wie in Ebene 3 |
| Kostenposten | nur die Zusammensetzung, nicht editierbar (ein Posten ist ein Rechenergebnis) |
| abgeleitete Groesse | unveraenderlich, mit Verweis auf die Report-Klassen (Charts je Report, Chart-Mix) |
Jedes Popup zeigt die Wirkung als **„vorher / jetzt / Δ"** fuer den gewaehlten und den guenstigsten zulaessigen Ansatz (P50 ueber den Horizont, „vorher" = Stand beim Oeffnen) und hat einen Knopf **„↺ Zuruecksetzen"** auf genau diesen Stand. Bedient werden ausschliesslich die vorhandenen Felder und Handler per `dispatchEvent`; es entsteht keine neue Rechenlogik, kein neuer Zustand und kein neuer Share-Link-Eintrag (`sv` bleibt 4) — eine Aenderung im Popup wirkt sofort auf Ergebnis und Link, als haette man das Feld im Formular angefasst.
**Drei Einstiege in den Graphen:** ueber das Inhaltsverzeichnis, ueber den Knopf **„🗺 Modell als Karte"** in der Werkzeugleiste und als dritte Option am Ende des gefuehrten Einstiegs. Damit ist der Graph nicht nur Erklaerung am Ende, sondern eine moegliche **Eingabe-Variante am Anfang**: man sieht, welche Groessen es ueberhaupt gibt und woher sie kommen, und kann sie an derselben Stelle setzen.
**Hinweis zur Pruefung:** Die Pruefinfrastruktur liegt seit dem Aufraeum-Durchgang vor der 1.0 im Repository unter `tests/`: `node tests/run-all.js` startet sechs Playwright-Suiten mit zusammen ueber 300 Pruefungen aus dem Repo-Wurzelverzeichnis (Sicherheit und Export, Eingaben und Annahmen, gefuehrter Einstieg, Inhaltsverzeichnis und Graph, Lizenzbasis, Wirkungsgraph-Abschnitt); einzelne Suiten laufen ueber ein Namensmuster. Details in `tests/README.md`. Zuvor lagen die Skripte ausschliesslich im fluechtigen Arbeitsverzeichnis einer Sitzung, und die damalige „grosse Regression" enthielt keine einzige Zusicherung — sie hat Werte gedruckt, aber nie geurteilt. `scripts/validate_html.js` ist ein Pruefer fuer die Kitchen-Seiten; er behandelt sein Dateiargument seit demselben Durchgang korrekt und bricht mit Fehler ab, wenn die uebergebene Datei kein `EPISODES`-Array enthaelt (vorher ignorierte er das Argument und meldete Erfolg fuer eine andere Datei).
## v0.18: Die Lizenzmenge kennt die Report-Klassen
**Woher die Aenderung kommt.** Eine unabhaengige Gegenlesung des Modells (`sessions/visual-standards-rechner-audit/wirkbeziehungen-check.md`, Fund 1, 15.09.2026) hat eine einseitig angewandte Mechanik gefunden: Seit v0.14 laeuft die Klasse A (Default 45 % der Reports, operativ, ohne IBCS-Bedarf) in **jedem** Ansatz ueber Core-Stunden — die Lizenz von 3rd-Party paid wurde aber unveraendert fuer **alle** Viewer berechnet, obwohl ein Teil dieser Leser nie einen Report mit dem gekauften Visual oeffnet. v0.14 hatte die Klassenmechanik auf die Stundenseite gelegt und die Mengenseite der Lizenz nicht angefasst. Der Fehler wirkte **zugunsten der Ansaetze der Autor:innen** (Open Source, Deneb) und gegen Paid; die Korrektur wirkt entsprechend gegen uns. Sie ist trotzdem umgesetzt, weil eine Diskussionsgrundlage, die sich in die eigene Richtung irrt, wertlos ist.
**Die neue Annahme.** `licViewerShare` — „Anteil der Viewer mit Zugriff auf Standard-Reports", **60 · 85 · 100 %**, Badge **E**. Die Mechanik ist per Such-Snippet belegt: Zebra BI beschreibt den Lizenzumfang als „any designer of Zebra BI reports and any end-user, who might access the Zebra BI reports", Inforiver als „all unique users who would create, or view reports created with Inforiver" — der Umfang haengt am **Zugriff auf die Reports**, nicht am Tenant. Die Herstellerseiten selbst waren in der Pruefumgebung blockiert, belegt ist nur der Snippet. Die **Hoehe** ist Autoren-Schaetzung, und der hohe Default ist begruendungspflichtig:
- Der Anteil ist ausdruecklich **nicht** 1 − 45 %. Wer mehrere Reports oeffnet, trifft fast sicher auf einen der Klassen B oder C. Nennenswert unter 85 % kommt nur, wer klar getrennte Lesergruppen hat — Lager- und Betriebsteams gegen Controlling. Daher das Minimum von 60 %.
- Nach oben ist „might access" weit gefasst, ein unlizenzierter Leser bekommt statt des Charts ein Wasserzeichen, und Einkauf und Revision neigen zur Vollabdeckung. Daher das Maximum von 100 % — und genau dort sass das Modell bis v0.17, ohne Regler.
**Rechenweg.** In der Jahresschleife tritt neben die volle, gedeckelte Nutzerzahl `ue` eine zweite, reduzierte Basis `ueL = packU(v*lvs + S.creators)`; die Ersteller zaehlen immer voll, weil sie mit dem Werkzeug bauen. `ueL` traegt die Lizenz (`licY`, nur im Nicht-Site-Zweig), die Lizenz-Administration (`licAdmH` — verwaltet werden die vergebenen Lizenzen) und `licUserYears`. Alles andere bleibt an der vollen Viewer-Zahl `v`: Anwender-Support, laufende Governance, Zugriffs-Governance, Konformitaetspruefung, Leserzeit und die Null-Option. **Genau diese Trennung fehlte bisher** — eine einzige Zahl war zugleich Lizenzbasis, Support-Basis, Governance-Basis und Nutzenbasis.
**Kopplung an die IBCS-Pflicht.** Mit dem Schalter „IBCS verbindlich fuer alle Reports" ist `lvs` zwingend 1. Das macht die zweite Haelfte des Preises dieser Pflicht sichtbar, die bis v0.17 gar nicht im Modell stand: Wer im Enterprise nur IBCS zulaesst, zieht damit auch **jeden Leser** in die Lizenz. Bei Site-Lizenz aendert sich nichts (der Preis haengt dort nicht an der Nutzerzahl, `licAdmH` ist bereits 0); der Code klammert den Fall ausdruecklich, damit auch die Verhandlungsgrenze unveraendert bleibt.
**Wirkung (P50 ueber den Horizont, Default 85 % gegen die alten 100 %):**
| Preset | Paid | Open Source | Deneb | Core | Rangfolge | Abstand von Paid zum besten Stunden-Ansatz |
|:--|--:|--:|--:|--:|:--|:--|
| Pilot (1 / 10) | 39.660 → **38.068** (−4,0 %) | 53.265 | 59.327 | 79.563 | unveraendert | Paid vorn, 13.605 → 15.197 € (+12 %) |
| Mittelstand (3 / 40) | 70.424 → **66.917** (−5,0 %) | 74.480 | 89.562 | 112.474 | unveraendert | Paid vorn, 4.056 → 7.563 € (+86 %) |
| Konzern (25 / 1.500) | 726.050 → **688.008** (−5,2 %) | 531.710 (K.O.) | 613.913 | 803.820 | unveraendert | Paid hinter Deneb, 112.137 → 74.095 € (**−34 %**) |
Die Rangfolge kippt in keinem Preset, aber der Rueckstand von Paid im Konzern schrumpft um ein Drittel. Die Ansaetze Open Source, Deneb und Core sind bitgleich unveraendert — sie haben keine Lizenz.
**Der Kipp-Punkt steigt.** Neu gemessen mit derselben Methode wie bisher (Mischpreis 80 €, Report-Klassen-Default, ohne Vorlagenbibliothek, ohne Red Flags): 1 Ersteller 40 → **51** Viewer, 3 Ersteller 57 → **67** Viewer (1 : 19 → 1 : 22), 25 Ersteller 231 → **273** Viewer (1 : 9 → 1 : 11). Die Spanne verschiebt sich damit von **1 : 9 bis 1 : 19 auf 1 : 11 bis 1 : 22**; mit Vorlagenbibliothek fuer Deneb und Core auf 1 : 10 bis 1 : 20. Paid rechnet sich also ueber einen groesseren Bereich, als der Rechner bis v0.17 ausgewiesen hat.
**Die Staffelklippe — ein Nebeneffekt, der kontraintuitiv ist und trotzdem stimmt.** Volumenstaffeln belohnen Masse. Deshalb kann die kleinere Lizenzbasis in eine **schlechtere** Rabattstufe fallen als die volle und dadurch mehr kosten. Im Konzern-Preset passiert genau das: ab Jahr 4 liegt die volle Nutzerzahl ueber der 2.000er-Grenze und bekommt dort 70 % Nachlass, die reduzierte Basis bleibt darunter bei 55 %.
| Jahr | volle Basis | Stufe | Preiseinheiten | reduzierte Basis | Stufe | Preiseinheiten |
|--:|--:|--:|--:|--:|--:|--:|
| 1 | 1.530 | 0,45 | 688 | 1.280 | 0,45 | 576 |
| 2 | 1.690 | 0,45 | 761 | 1.410 | 0,45 | 635 |
| 3 | 1.870 | 0,45 | 842 | 1.560 | 0,45 | 702 |
| 4 | **2.070** | **0,30** | **621** | 1.730 | 0,45 | **779** |
| 5 | 2.290 | 0,30 | 687 | 1.920 | 0,45 | 864 |
340 Nutzer weniger kosten in Jahr 4 also 157 Preiseinheiten **mehr**. Ueber den Horizont und gewichtet mit der Lizenzpreis-Steigerung steigen die Paid-Kosten im Konzern-Preset dadurch im **Erwartungswert** um 0,2 %, waehrend der **P50 der Simulation** um 5,2 % faellt — in der Simulation wird das Viewer-Wachstum gezogen, die Staffelgrenze wird oft gar nicht ueberschritten. Die Aussage „die Korrektur senkt die Lizenzkosten von Paid" gilt also nicht ausnahmslos. Damit das nicht wie ein Rechenfehler aussieht, warnt die Report-Klassen-Karte in genau diesen Faellen (`staffelCliff()`): sie nennt das erste betroffene Jahr und sagt, dass hier weniger Lizenzen teurer sind. Im Einkaufsgespraech ist das ein Argument, das gegen den Kaeufer laeuft.
**Share-Links.** `sv` steigt von 4 auf 5. Ein Link mit `sv < 5` setzt `licViewerShare` auf 100 % und rechnet damit **exakt** wie in v0.17 weiter; ein Hinweis beim Laden sagt das und nennt den neuen Regler. Dasselbe Muster wie beim Chart-Mix-Override aus v0.14.
**Was dabei offen geblieben ist** (aus derselben Pruefung, nicht umgesetzt): die Beschriftung der Annahme `lic` sagt weiterhin „Ersteller und Viewer zaehlen gleich" statt „Ersteller und die Viewer mit Zugriff". `licenseBreakEven()` mittelt ueber `oss`, `deneb` und `core` **ohne** K.O.-Filter — im Konzern-Preset ist Open Source per Red Flag ausgeschlossen, der ausgewiesene Break-even rechnet trotzdem dagegen und ist dort zu guenstig fuer die Stunden-Seite. Beides ist aelter als v0.18. Die Funde 2 bis 7 der Pruefung (Preiselastizitaet der Report-Menge, Rollout-Tempolimit, Schluesselpersonen-Risiko, Preissprung statt glatter Rate, Wissensverfall durch Fluktuation, mitwachsender Capacity-Verbrauch) sind ebenfalls offen und im Pruefbericht mit Abbildungsvorschlag beschrieben.
## v0.19: Die Karte vor das Gelaende
v0.19 aendert keine Zahl. Sie korrigiert eine Reihenfolge, die dem eigenen Leitbild widersprach.
**Der Wirkungsgraph war am falschen Platz.** Er lag als zugeklapptes `` auf Ebene 3, im Abschnitt „Details", hinter allen Zahlen und Tabellen. Dabei ist er das Gegenteil eines Details: Er zeigt, **welche Groessen es ueberhaupt gibt, woher sie kommen und wohin sie laufen**. Nach Shneiderman gehoert das an den Anfang — „overview first" —, und der Rechner hat es zwei Versionen lang hinten angestellt. Seit v0.19 ist der Graph ein eigener Abschnitt `#s-map` („Woran die Kosten haengen") direkt hinter dem Ueberblick und **vor** den Eingabe-Abschnitten, ab Ebene 2 offen sichtbar, ohne Klick. Die Seite liest sich damit: *Was kostet es* → *woran es haengt* → *eure Zahlen eintragen* → *Ergebnis* → *Details*.
Damit die Karte oben ruhig bleibt, ist der lange Erklaerabsatz unter den Graphen in ein zugeklapptes `` gewandert; sichtbar bleibt eine Zeile Orientierung. Der statische **Entscheidungsbaum** (dieselbe Logik generisch, ohne Szenariobezug) ist bewusst **nicht** mit nach vorne gezogen worden — er ist echtes Detail und haette 556 px SVG vor die Eingaben geschoben. Er steht als zugeklapptes Ebene-3-`` am Ende desselben Abschnitts, inhaltlich neben der Karte, und erscheint im Inhaltsverzeichnis als deren Unterpunkt. Auf Ebene 1 steht eine Zeile mit Sprung auf die Karte; der Klick wechselt die Ebene mit.
**Das Inhaltsverzeichnis gruppiert nach Seitenbereich statt nach Ebene.** Nach Ebene sortiert sprang die Liste (Ebene 2 → Ebene 3 → Ebene 2), weil die Annahmen technisch auf Ebene 3 liegen, inhaltlich aber zu den Eingaben gehoeren. Die Kopfzeilen heissen jetzt **Einstieg · Ueberblick und Karte · Eingaben · Ergebnis · Details**; die Ebene steht weiterhin als leiser Vermerk am einzelnen Eintrag. Jeder Eintrag traegt seine Gruppe selbst — bis v0.18 erbten die Unterpunkte stillschweigend die Gruppe ihres Vorgaengers, was beim Verschieben eines Haupteintrags gekippt waere.
**Ein Fehler dabei gefunden und behoben:** Die Unterpunkte trugen 18 px Luecken, die Fuehrungslinie war zerhackt. Ursache war ein Namenskonflikt — die Eintraege nutzten die Klasse `sub`, die die Seite bereits fuer Untertitel vergibt, und erbten deren `margin-bottom`. Eigener Name `tsub`, Linie laeuft durch.
**Optik der Seitenleiste:** durchgehende Fuehrungslinie statt grauer Kaesten, die aktive Stelle nur ueber Akzentfarbe und eingefaerbtes Linienstueck, der Ebenen-Vermerk ohne Rahmen, und „Alles aufklappen / zuklappen" als leise Fusszeile unter der Liste statt als zwei breite Knoepfe darueber. Die Navigation beginnt damit mit der Navigation.
## v0.20: Aufraeumen vor der 1.0
Keine neue Funktion. Dieser Durchgang hat geprueft, was nicht mehr stimmt, und das Werkzeug benutzbar gemacht.
### Ein neuer Abschnitt: „Was dieser Rechner nicht kann"
`#s-grenzen` steht auf Ebene 2 direkt hinter dem Ergebnis, offen, ohne Klick. Er nennt die Quellenlage (live aus `GLOBAL` und `OPTP` gezaehlt, damit der Absatz nicht veraltet: **58 Annahmen, 12 mit externer Quelle, 46 ohne**), legt offen, dass ChartKitchen byDatenWG und die Deneb-Vorlagen Projekte der Veranstalter sind, listet die **sechs offenen Luecken** aus der unabhaengigen Pruefung mit Groessenordnung und Wirkungsrichtung, sagt, was gar nicht enthalten ist, und schliesst mit der Warnung zum Kipp-Punkt. Der unbequemste Satz darin: **vier der sechs Luecken wirken zugunsten der Ansaetze, die die Autor:innen selbst vertreten** — das Modell ist nicht neutral, sondern hat eine bekannte Schlagseite.
Wer eine Zahl mit Versionsnummer zitiert, soll auf derselben Seite lesen koennen, wo sie systematisch danebenliegt. Bis v0.19 stand das nur in einem Unterordner des Repositories.
### Zwei echte Fehler
- **Die Annahme `lic` war seit v0.18 falsch beschriftet** („Ersteller und Viewer zaehlen gleich"). Zusammen mit zehn weiteren Textstellen — Eingabefeld, gefuehrter Einstieg, Graph-Popup, Glossar, Nachteile von Paid, Methodiktext — und einer **Excel-Formel, die tatsaechlich mit allen Viewern rechnete**, nachgezogen.
- **`licenseBreakEven()` filterte die K.O.-Kriterien nicht** und verglich gegen ausgeschlossene Ansaetze. Im Konzern-Preset verschiebt die Korrektur den Break-even von 692 auf **1.117 Viewer**, im Report-Server-Preset von 236 auf **370**. Die Richtung der Aussagen bleibt. Dieselbe Familie in `drawBreakEven()`: ausgeschlossene Ansaetze werden jetzt ausdruecklich als „nicht waehlbar, nur zum Vergleich" gekennzeichnet statt stillschweigend mitempfohlen; ist Paid selbst ausgeschlossen, steht der Vorbehalt vor den Zahlen statt dahinter.
### Sieben veraltete Zahlen
Unter anderem im statischen Entscheidungsbaum: Kipp-Punkt **1 : 10–1 : 20 → 1 : 12–1 : 26**, mit Zebra-Anker **1 : 15 → 1 : 5–1 : 9** (diese Zahl war nie richtig). Dazu eine Behauptung, die die Rechnung widerlegt: Die Lesehilfe nannte die IBCS-Pflicht „im Enterprise den groessten einzelnen Kostentreiber" — gemessen **senkt** sie die Kosten bei Paid (−4 bis −17 %), Open Source und Deneb und erhoeht sie nur bei Core + SVG (+1 bis +4 %), weil die operativen Reports aus der zweiten Werkzeugkette in den gewaehlten Ansatz wandern.
### Barrierefreiheit und Bedienbarkeit
Erstmals systematisch geprueft (`sessions/visual-standards-rechner-audit/barrierefreiheit-check.md`, alles mit Playwright gemessen). Behoben:
| | vorher | nachher |
|:--|--:|--:|
| Tabulator-Halte gesamt | 1.066 | **604** |
| davon Erfuellungsgrad-Punkte | 540 | **108** (roving tabindex, Pfeiltasten) |
| Spaltenkopf-Kontraste der Anforderungs-Tabelle | 2,17–4,42 : 1 | **5,70–8,16 : 1** |
| Flusstext unter 11 px | 414 Knoten | **2** |
| verwaiste `