Fachliche offene Punkte (BQ)

Status: Entwurf · Stand: 2026-04-29

Lebende Liste fachlicher Fragen, die mit den Stakeholdern (siehe ../10-business/03-stakeholders.md) zu klären sind. Jeder Punkt blockiert eine konkrete Spec-/UI-/Berechnungs-Entscheidung.

Format: BQ = Business Question. ID-Reihenfolge ist stabil; gelöste Punkte werden als „Gelöst:“-Block belassen, nicht entfernt.

Übersicht

ID	Frage	Status	Stakeholder	Bezug
BQ-01	Mandats-Pricing pro Modul — wie verdient die Holding?	offen — mit Stakeholdern klären	Holding-GL, Tochter-GL, Mandats-Vertrieb	Wertversprechen, Modul-Konfigurator, Berechnung
BQ-02	Mandatsvertrag — Laufzeit, Kündigung, Exklusivität, Modul-Ausstieg, Eigentümerwechsel	offen — mit Stakeholdern klären	Recht, Holding-GL, Mandats-Vertrieb	Case-Lebenszyklus, Stammdaten
BQ-03	Annahmen-Governance — Wer pflegt zentrale Defaults, Frequenz, Versionierung, Override	offen — mit Stakeholdern klären	Modellierer (Controlling), Holding-GL, Auditor	Berechnung, Case-Lebenszyklus
BQ-04	Mieter-Anschlussquote — Verantwortung, Plan-vs.-Ist-Tracking, Schwellen, Hebel	zurückgestellt — mit Stakeholdern klären, sobald Mieterstrom-Modul detailliert wird	ad hoc immobilien, ad hoc best services, Mandats-Vertrieb	UC Liegenschafts-Bewertung, Energie-Objekte
BQ-05	Datenhoheit zwischen Töchtern — wer sieht welche Margen-Beiträge in Portfolio-Aggregations?	offen — mit Stakeholdern klären	Holding-GL, Tochter-GL, Auditor	UC Portfolio-Aggregation, Rollen und Berechtigungen
BQ-06	Angebot-Subtypen (`service` / `material`) — Diskriminator-Attribut oder separate Entity-Types?	offen — abhängig von Attribut-Divergenz	Fachmodellierer, Holding-Controlling	Entitäten-Katalog
BQ-07	Liegenschaft-Typen und Pflichtattribute — welche `property_type`-Werte, welche Pflichtfelder je Typ?	offen — mit Stakeholdern klären	ad hoc immobilien, Mandats-Vertrieb	Liegenschaft-Objekte, Entitäten-Katalog
BQ-08	Bewirtschaftung nach Renovierung — im Case-Status/Phase oder eigene `operation_period`-Entität?	offen — fachliches Lifecycle-Design	Fachmodellierer, ad hoc immobilien	Case-Objekte, Case-Lebenszyklus
BQ-09	Module — eigener Entity-Type mit Pricing/Konditionen oder nur `enum_set` auf `case.module_selection`?	offen — abhängig von BQ-01 (Pricing-Komplexität)	Holding-GL, Mandats-Vertrieb, Fachmodellierer	Entitäten-Katalog, BQ-01
BQ-10	Modulwechsel-Audit — Modul-Hinzunahme/-Kündigung: neuer Folge-Case oder Erweiterung des laufenden Case?	offen — mit Stakeholdern klären	Mandats-Vertrieb, Recht, Holding-GL	Case-Lebenszyklus, Stammdaten-Lifecycle
BQ-11	Case-Status-Workflow — welche Status-Übergänge sind fachlich zugelassen?	offen — vor Implementierung zu fixieren	Fachmodellierer, Holding-GL	Case-Objekte, Case-Lebenszyklus

BQ-01 · Mandats-Pricing pro Modul

Status: offen — mit Stakeholdern klären Verantwortlich für Klärung: Christian Gehrt (Holding-Steuerung), Tochter-GL je Modul, Mandats-Vertrieb

Die buchbaren Module (Verwaltung, Mieterstrom + Messdienst, Messdienst standalone, Abrechnung, Energieberatung, Versicherung, Mieter Access) sind benannt — aber die Geschäftslogik innerhalb jedes Moduls ist offen. Pro Modul muss feststehen, wie die Holding (bzw. die durchführende Tochter) verdient.

Pricing-Schema-Optionen:

Schema	Bedeutung	Beispiel
Festpreis	fester €-Betrag pro Wohneinheit + Monat oder pro Liegenschaft + Monat	Verwaltung 25 €/WE/Monat
Cost-Plus	Selbstkosten der Tochter plus festen Aufschlag-Prozentsatz	Bauleistung Materialeinkauf + 18 %
% am Ertrag	Provision auf Bruttoerlös des Moduls	1,0–5,0 ct/kWh aus Mieterstrom-Verkauf
Mischform	Grundgebühr + variable Komponente	Abrechnung 0,56 €/WE/Monat + 12 % Mahnpauschale

Erfragt werden muss pro Modul:

Welches Schema gilt? (eines aus Tabelle oder Mix)
Wer setzt den Preis fest — zentrale Holding-Liste oder Verhandlungsspielraum pro Mandat?
Gibt es Volumen-Staffeln (kleine Liegenschaft vs. > 50 WE)?
Wie verhalten sich interne (Tochter) vs. externe Provider preislich? Margenwirkung in der Doppelsicht (Eigentümer vs. Holding)?
Müssen Pricing-Werte versionierbar sein (alte Mandate behalten alten Preis)?

Datenmodell-Konsequenz: eigenes module_pricing (Stammdaten-Entity) mit Modul-Schlüssel, Schema-Typ, Schema-Parametern, Gültigkeitsfenster (valid_from/valid_to, siehe Bitemporalität OP-32). Calculation-Engine resolved den anwendbaren Pricing-Eintrag pro Case zum Mandats-Stichtag.

BQ-02 · Mandatsvertrag — Laufzeit, Kündigung, Exklusivität

Status: offen — mit Stakeholdern klären Verantwortlich für Klärung: Recht (extern), Christian Gehrt, Mandats-Vertrieb

Die mandat-Entity ist heute weder vertraglich rahmengebend noch lebenszyklus-modelliert. Folgende Punkte sind offen:

Frage	Optionen	Wirkung in der Workbench
Mindestlaufzeit pro Modul	uniform vs. modulspezifisch (Mieterstrom 10 J., Verwaltung 1 J.)	`mandat_modul.min_term_years`, Solver-Constraint
Kündigungsfrist	uniform (z. B. 3 Monate) vs. modulspezifisch	`mandat_modul.notice_period_months`
Kündigungsgrund-Pflicht	ja/nein, ggf. nur für ordentliche Kündigung	Audit-Pflicht im Folge-Case
Exklusivität pro Modul	Bündel-Pflicht vs. Modul-frei wählbar	Prüfung beim Konfigurator-Schritt
Modul-Ausstieg während Laufzeit	Pönale-Modell, Restrückbau zu Lasten von wem (Eigentümer / Holding / Tochter)?	eigene Cashflow-Position im Folge-Case
Eigentümerwechsel der Liegenschaft	Mandat folgt der Liegenschaft (Käufer übernimmt) vs. Mandat erlischt	Stammdaten-Lifecycle für `eigentuemer`-Wechsel
Vertragslokalisierung	ein Vertrag pro Mandat oder ein Rahmenvertrag plus Modul-Anlagen	Dokument-Anhänge (`DDM_ATTACHMENT`)

Erfragt werden muss bei Recht und Holding-GL:

Existiert bereits ein Standard-Mandatsvertrag oder muss er parallel entworfen werden?
Sind individuelle Verhandlungen pro Mandat zulässig oder gilt das Standard-Set zwingend?
Wie wird ein Mandat formal beendet (Schreibform, Frist, Annahme durch Holding)?
Gibt es regulatorische Mindest-/Maximalfristen (z. B. AGB-Recht für Verbraucher-Eigentümer vs. B2B)?

Datenmodell-Konsequenz: neue Stammdaten-Entity mandate_contract mit Vertragsparametern, plus mandat_modul für die Modul-Bestellung pro Mandat (mit Laufzeit, Kündigungs-Status, Aktivitäts-Fenster).

BQ-03 · Annahmen-Governance — Defaults, Versionierung, Override

Status: offen — mit Stakeholdern klären Verantwortlich für Klärung: Controlling/Modellierer, Holding-GL, Auditor

Modelle nutzen Annahmen (Strompreis-Pfad, Zinssatz, Inflation, EEG-Vergütung, Materialkosten-Index, Mietausfall-Quote, Anschlussquoten). Offen:

Frage	Auswirkung
Pflege-Verantwortung zentral (Holding-Modellierer) vs. tochter-eigene Sets vs. Kommissions-Set?	RBAC auf `assumption_set`
Aktualisierungsfrequenz quartalsweise / jährlich / anlassbezogen?	Workflow + Erinnerungs-Job
Versionierung der Annahmen-Sets — bekommt jeder freigegebene Case einen Snapshot des aktiven Sets?	bitemporal (OP-32) auf `assumption_set`
Override pro Case — darf der Analyst Default-Annahmen für einen einzelnen Case verändern? Mit Begründungs-Pflicht? Mit Approval?	Service-Layer-Regel + Audit
Sensitivitäts-Defaults — welche Spreizung wird automatisch als Worst/Best/Realistisch gerechnet (z. B. Strompreis ±20 %)?	im `assumption_set` als Triplet pro Annahme
Annahmen-Quellen-Pflicht — muss jede Default-Annahme eine Quelle/Herleitung haben (für Auditor)?	zusätzliche Pflichtfelder

Erfragt werden muss bei Controlling und Holding-GL:

Gibt es heute schon Excel-basierte Annahmen-Sammlungen, die als V1-Seed dienen können?
Wer übernimmt operativ die Pflege im Tagesgeschäft?
Wie wird der Auditor sich später überzeugen können, dass eine alte Empfehlung „mit den damaligen Annahmen” korrekt war?

Datenmodell-Konsequenz: Stammdaten-Entities assumption_set (versioniert, bitemporal, mit valid_from/valid_to) und assumption_value (Schlüssel, Wert mit Einheit, Quelle, Worst/Best/Realistisch-Spreizung). Snapshot beim Case-Freigabe, parallel zum decision_threshold_set aus BQ-01-naher Logik.

BQ-04 · Mieter-Anschlussquote — Plan, Ist, Verantwortung

Status: zurückgestellt — wird bei Detaillierung des Mieterstrom-Moduls aufgegriffen Verantwortlich für Klärung: ad hoc immobilien (Verwaltung), ad hoc best services (Abrechnung), Mandats-Vertrieb

Die Mieterstrom-Wirtschaftlichkeit hängt sensibel an der Anschlussquote (% der WE, die einen Mieterstrom-Vertrag abschließen). Heute weder im Datenmodell noch im Workflow verortet.

Offene Punkte für die spätere Klärung:

Wer schließt operativ mit dem Mieter ab — ad hoc immobilien, ad hoc best services, externe Vertriebler?
Plan-Quote in V1 — Stammdaten-Default je Liegenschaftstyp, Eigentümer-Override, oder pro Case Annahmen-Schieber?
Ist-Quote-Tracking — wird die Anschlussquote als Stammdatum auf der Liegenschaft gepflegt? Ändert das den aktiv-Case rückwirkend (Re-Berechnung)?
Schwelle für Wirtschaftlichkeits-Knick — unter welcher Quote wird Mieterstrom automatisch unrentabel und die Workbench warnt?
Hebel zur Steigerung — modelliert die Workbench Marketing-Maßnahmen, Tarif-Diskonts, Anschluss-Boni als eigene Kostenpositionen?

Bezug: Berechnungs-Sensitivität (Worst-Case = niedrige Quote), Risikobetrachtung in ../60-rules-and-calculation/03-decision-criteria.md, und ein Anschluss-Tracking-Feature im UC-04-Lebenszyklus.

Begründung Zurückstellung: das Mieterstrom-Modul-Modell ist als Excel-Tapete vorhanden (Quelle Kickoff 2026-04-24), der Anschlussquoten-Mechanismus ist aber nicht der V1-blockierende Punkt. V1 startet mit einer konfigurierbaren Annahmen-Schieber-Quote (siehe BQ-03), Ist-Tracking folgt sobald reale Mandate aktiv sind.

BQ-05 · Datenhoheit zwischen Töchtern — Portfolio-Margen-Sichtbarkeit

Status: offen — mit Stakeholdern klären Verantwortlich für Klärung: Christian Gehrt (Holding-GL), Tochter-GL, Auditor

In UC-03 (Portfolio-Aggregation) konsolidiert die Holding Margen-Beiträge aller Töchter. Unklar ist, welche Tochter welche Beiträge der anderen Töchter sehen darf.

Drei Optionen stehen zur Wahl:

Option	Beschreibung	Implikation
Holding-Privileg	Nur Holding-GL und Auditor sehen Einzel-Beiträge, Töchter sehen nur ihren eigenen	Einfachste RBAC-Umsetzung
Anonymisiertes Aggregat	Andere Töchter erscheinen als zusammengefasster „Sonstige”-Beitrag	Mittlere Komplexität; Algorithmus muss k-Anonymität sicherstellen
Voll transparent	Alle Töchter sehen alle Einzel-Beiträge	Kulturell und rechtlich riskant — braucht explizite Freigabe aller Beteiligten

Erfragt werden muss bei Holding-GL und Tochter-GFs:

Ist Transparenz zwischen Töchtern politisch gewollt oder explizit unerwünscht?
Gibt es Vertragsklauseln zur Vertraulichkeit von Margen-Daten zwischen Töchtern?
Gilt eine einheitliche Policy oder unterschiedlich je Tochter-Paarung?

Datenmodell-Konsequenz: entweder ACL-Einträge pro Report-View je Tochter-Principal, oder dedizierte portfolio_report-Views mit Holding-Only-Filter, oder Aggregations-Masking im Service-Layer vor Auslieferung.

BQ-06 · Angebot-Subtypen — Diskriminator vs. separate Entity-Types

Status: offen — abhängig von Attribut-Divergenz Verantwortlich für Klärung: Fachmodellierer (Controlling), Holding-Steuerung

offer hat heute ein kind-Attribut (service | material). Offen ist, ob Service-Angebote und Material-Angebote mittelfristig so unterschiedliche Pflichtfelder bekommen, dass zwei separate DDM_ENTITY_TYPE-Einträge sinnvoller wären.

Ansatz	Vorteil	Nachteil
Diskriminator-Attribut (`kind` auf `offer`)	Ein Typ, einfaches RBAC, einfache Abfragen	Pflichtfelder je `kind` brauchen bedingte Validierung (OP-14 CEL)
Separate Entity-Types (`service_offer`, `material_offer`)	Klare Trennung, unterschiedliche Attribute ohne Bedingungslogik	Doppelter RBAC-Aufwand, Relations müssen beide Typen referenzieren

Erfragt werden muss bei Controlling und Fachmodellierer:

Welche Attribute sind für Material-Angebote zwingend (z. B. Lieferant, Artikelnummer, Mengeneinheit)?
Welche Attribute sind für Service-Angebote zwingend (z. B. Leistungsort, FTE-Anteil, SLA)?
Divergieren Lebenszyklus-Status-Workflows zwischen den beiden Typen?

Datenmodell-Konsequenz: bis zur Klärung bleibt kind-Diskriminator auf offer; bei signifikanter Divergenz Migration auf zwei separate Typen (nicht breaking — nur neuer Seed + Daten-Migration).

BQ-07 · Liegenschaft-Typen und Pflichtattribute

Status: offen — mit Stakeholdern klären Verantwortlich für Klärung: ad hoc immobilien, Mandats-Vertrieb

Die property-Entität braucht einen property_type-Wert (Enum). Welche Typen existieren und welche Attribute sind je Typ Pflicht, ist noch nicht fixiert.

Kandidaten für property_type:

residential (Wohngebäude)
commercial (Gewerbe)
mixed_use (Mischnutzung)
land (unbebautes Grundstück)
special (Sonderobjekt — Schule, Krankenhaus, …)

Erfragt werden muss bei ad hoc immobilien:

Welche Typen kommen im Portfolio tatsächlich vor?
Welche Attribute sind je Typ Pflicht (z. B. Wohneinheiten nur für residential/mixed_use)?
Gibt es Typen, auf die bestimmte Module (Mieterstrom, Abrechnung) grundsätzlich nicht buchbar sind?
Gibt es Subtypen (z. B. residential.sozial für Sozialwohnungen mit anderen Mietpreis-Regeln)?

Datenmodell-Konsequenz: property_type wird DDM_ENUM_SET; bedingte Pflichtfelder über DDM_ENTITY_TYPE_ATTRIBUTE.validation_rule mit required_when-CEL-Ausdruck (OP-14).

BQ-08 · Bewirtschaftung nach Renovierung — Case-Phase oder eigene Entität?

Status: offen — fachliches Lifecycle-Design Verantwortlich für Klärung: ad hoc immobilien, Fachmodellierer

Nach Abschluss einer Renovierung oder Modernisierung tritt eine Liegenschaft in eine Bewirtschaftungsphase. Unklar ist, ob dies:

Option	Beschreibung
Case-Status/-Phase	Bewirtschaftung ist ein Status (`betrieb`) innerhalb des laufenden `case` — keine neue Entität
Eigene `operation_period`-Entität	Eigener Entity-Type, der an die Liegenschaft und den abgeschlossenen Case referenziert; hat eigene Attribute (Betriebskosten-Ist, Mieteinnahmen, Anschlussquote)

Erfragt werden muss bei ad hoc immobilien:

Gibt es Fälle, wo nach einem Case mehrere Bewirtschaftungs-Abschnitte folgen (z. B. Zwischenverkauf, Rückkauf)?
Müssen Betriebskosten-Ist-Daten getrennt vom Modell-Case gespeichert und verglichen werden?
Wird die Workbench im Betrieb aktiv für KPI-Tracking genutzt oder endet die Nutzung mit dem Case-Abschluss?

Datenmodell-Konsequenz: bei Option 1 — case.status bekommt Wert betrieb; bei Option 2 — neuer operation_period-Typ mit Relation zu property und FK-ähnlicher Referenz auf case.

BQ-09 · Module — Entity-Type mit Pricing oder nur Codeliste?

Status: offen — abhängig von BQ-01 (Pricing-Komplexität) Verantwortlich für Klärung: Holding-GL, Mandats-Vertrieb, Fachmodellierer

V1-Empfehlung aus dem Entitäten-Katalog: Module sind ein DDM_ENTITY_TYPE (module) mit Pricing-Attributen. Alternative: nur DDM_ENUM_SET module_type auf case.module_selection.

Ansatz	Für	Gegen
Entity-Type `module`	Trägt Pricing-Schema, Gültigkeitsfenster, Konditionen; versionierbar	Overhead für einfache Modul-Auswahl
Enum-Set	Einfach, kein Extra-CRUD	Keine Pricing-Logik, kein Gültigkeitsfenster — alles in Hardcode oder BQ-01 unklar

Erfragt werden muss:

Haben Module eigene konfigurierbare Konditionen (Mindestlaufzeit, Kündigungsfristen) — wenn ja, muss BQ-02 zuerst geklärt werden?
Sollen Pricing-Parameter pro Modul direkt in der Workbench pflegbar sein (Admin-UI)?
Reicht für V1 ein fest einkodiertes Modul-Set, das sich selten ändert?

Entscheidungsreihenfolge: BQ-01 → BQ-02 → dann BQ-09 final beantworten.

BQ-10 · Modulwechsel-Audit — neuer Folge-Case oder Erweiterung?

Status: offen — mit Stakeholdern klären Verantwortlich für Klärung: Mandats-Vertrieb, Recht, Holding-GL

Wenn ein Eigentümer während eines laufenden Mandats ein Modul hinzunimmt oder kündigt: Empfehlung aus dem Katalog ist ein neuer Folge-Case — aber noch nicht entschieden.

Option	Vorteil	Nachteil
Neuer Folge-Case	Klare Audit-Spur, eigenes Berechnungs-Szenario, unveränderliches Original	Mehr Case-Overhead, UI muss Folge-Kette navigierbar machen
Erweiterung des laufenden Case	Einfacher für den Nutzer	Ändert historische Modell-Ausgangslage, erschwert Nachvollziehbarkeit

Erfragt werden muss bei Mandats-Vertrieb und Recht:

Ist ein Modulwechsel vertraglich als Vertragsänderung oder als Neuvertrag zu werten (→ BQ-02)?
Muss das ursprüngliche Case-Szenario nach einem Modulwechsel unverändert lesbar bleiben?
Wie oft sind Modulwechsel in der Praxis zu erwarten (seltene Ausnahme vs. regulärer Vorgang)?

Datenmodell-Konsequenz: bei Folge-Case — case.predecessor_case_id-Relation; bei Erweiterung — case_module_change-Log-Tabelle als Audit-Ergänzung ohne neues Case-Objekt.

BQ-11 · Case-Status-Workflow — erlaubte Übergänge

Status: offen — vor Implementierung zu fixieren Verantwortlich für Klärung: Fachmodellierer, Holding-GL

DDM_ENTITY.status für case hat Kandidaten-Werte (draft, approved, active, closed, …). Welche Übergänge fachlich erlaubt sind und welche Rollen sie auslösen dürfen, ist noch nicht fixiert.

Offene Punkte:

Frage	Auswirkung
Welche Status-Werte gibt es für `case`?	`DDM_STATUS_TRANSITION`-Seed (OP-48)
Wer darf `draft → approved` auslösen?	RBAC-Bindung — Holding-GL oder Tochter-GL?
Gibt es einen `under_review`-Status vor `approved`?	Ggf. Stewardship-Inbox (OP-35, V2)
Kann ein `approved`-Case wieder auf `draft` zurückgesetzt werden?	Audit-Pflicht + Begründung
Was passiert beim Case-Abschluss — Status `closed` oder Archivierung?	Unterschiedliche Soft-Delete-Semantik
Gibt es `cancelled` als eigenen Status (abgebrochen, nie aktiv)?	Reporting-Filterbarkeit

Erfragt werden muss bei Holding-GL und Fachmodellierer:

Gibt es heute einen analogen Prozess (Excel-Freigabe-Workflow), der den fachlichen Lifecycle abbildet?
Wer muss einen Case formal freigeben, bevor Empfehlungen an den Eigentümer gehen?
Soll ein archivierter Case reaktivierbar sein?

Datenmodell-Konsequenz: Status-Werte als DDM_ENUM_SET case_status; erlaubte Übergänge in DDM_STATUS_TRANSITION (per OP-48); Rollen-Bindung über required_role-Spalte.