UC-05 · Modellpflege

Status: Entwurf · V1

Pflege der Berechnungs- und Beziehungslogik (Modelle), mit denen Cases gerechnet werden — nicht zu verwechseln mit KI-Modellen oder Datenbankschemata.

Trigger

Neue Berechnungslogik gefordert (z. B. neue Fördersystematik)
Existierende Logik ändert sich (Steuersatz, Förderhöhe, Kennzahlen-Definition)
Neuer Case-Typ wird eingeführt (z. B. „Mieter-Access-Wirtschaftlichkeit” oder „Renditerechner für Eigentümer-Erwerb”)

Akteur

Primär: Modellierer (Controlling, Wirtschaftsanalytik)
Mitwirkend: Fachexperten je Tochter (validieren Formeln), Recht/Steuer (bei regulatorischen Modellen)
Freigabe: Management

Ablauf

1. Anlage / Ableitung

Modellierer legt ein neues Modell an oder klont eine bestehende Version. Klonen erhält Historie und Vergleichbarkeit.

2. Kompletter Editor (Low-Code)

In der Modell-UI definiert der Modellierer:

Eingangs-Entitäten (welche Stammdaten gehen ein? Liegenschaft, Provider, Material, …)
Parameter (Annahmen, die der Analyst pro Case setzt: Strompreis, Eigenverbrauchsquote)
Formeln (Wie wird CapEx berechnet? Wie OpEx? Wie Erlöse?)
Constraints (Min-/Max-Werte, Validierungen, Plausibilitätsregeln)
Ergebnis-Kennzahlen (was rechnet das Modell aus? Cashflow, IRR, Amortisation, …)

Implementierung der Modellsprache offen — Kandidaten: JSON-Logic, TypeScript-Regel-Kern, eigenes DSL. Siehe ../60-rules-and-calculation/01-rule-engine-intent.md.

3. Testfälle / Golden Data

Pro Modell mindestens ein Golden-Data-Testfall: vorbereitete Eingangswerte → erwartete Ergebnisse. Verhindert, dass Modell-Änderungen unbemerkt frühere Ergebnisse brechen.

4. Trockenlauf

Modellierer testet das Modell gegen einen oder mehrere existierende Cases — ohne diese zu verändern. Sieht: würde mein neues Modell andere Ergebnisse liefern? Wo sind die Differenzen?

5. Review

Fachexperte (z. B. Energie-Tochter für PV-Formeln, Steuer für steuerliche Auswirkungen) reviewt. Kommentare, Änderungswünsche.

6. Freigabe

Management gibt das Modell frei. Status released. Erst dann wählbar in neuen Cases. Bestehende Cases bleiben auf ihrer Modellversion stabil (Snapshot bei Case-Freigabe).

7. Migration alter Cases (optional)

Wenn ein Modell tiefgreifend geändert wurde, kann Modellierer alte Cases auf neue Version migrieren — explizit, mit Audit-Trail. Defaultmäßig nicht automatisch.

Lebenszyklus eines Modells

draft → review → released → produktiv → deprecated → archived

draft: in Bearbeitung
review: Fachexperte prüft
released: freigegeben, in neuen Cases wählbar
produktiv: aktiv genutzt in lebenden Cases
deprecated: nicht mehr für neue Cases, nur noch für laufende
archived: aus dem aktiven Katalog

(Detail: ../40-workflows/03-modell-lifecycle.md)

Modell-Bibliothek

Mehrere Modelle koexistieren:

pro Case-Typ ein oder mehrere Modelle
pro Modell mehrere Versionen
ggf. branchen-/regulatorisch spezifische Varianten

Beteiligte Fachobjekte

Modell (mit case_type-Zuordnung)
ModellVersion
Parameter
Formel
Constraint
Testfall mit Golden-Data