Drei-Säulen-Architektur der Workbench

Status: Entwurf

Die Workbench-Oberfläche folgt einem Drei-Säulen-Modell. Jede Säule adressiert eine eigene mentale Haltung des Nutzers — operative Verwaltung, analytische Überblick und explorative Planung. Sie teilen denselben Datensatz, aber nutzen grundlegend verschiedene UI-Paradigmen.

Drei-Säulen-Architektur Übersicht

A · Operativer Verwaltungs-Core (System of Record)

Fokus: Vertragsverwaltung, Stammdaten, Abrechnungen, Instandhaltung — alles, was schnell gefunden, gepflegt und belegt sein muss.

Nutzer: Stammdatenpfleger, Verwalter.

UI-Paradigma: Master-Detail + kompakte Datentabelle

Datentabellen mit tausenden Zeilen müssen schnell filterbar sein: nach Standort, Restlaufzeit, Leerstand, Status.
Spalten-Alignment-Konvention: Zahlen/Geld rechts, Text links, monospaced Zahlen.
Tabellen sortieren und filtern statt paginieren und scrollen.

Objekt-Cockpit

Jede Liegenschaft / jedes Stammdatum öffnet ein Objekt-Cockpit in der Detail-View:

Sidebar oder Tab-Struktur bündelt alle Dokumente, historische Reparaturberichte und aktuelle Mietverhältnisse an einem Ort.
Audit-Trail direkt zugänglich — kein Kontextwechsel für „wer hat das wann geändert?”.
Aktionen (Archivieren, Hard-Delete, Relate) bleiben im Cockpit, kein Formular-Popup auf separater Seite.

B · Analyse- & Dashboard-Bereich (System of Insights)

Fokus: Performance-Überblick, KPI-Verdichtung — Rendite, Instandhaltungskosten vs. Budget, Sanierungsstau.

Nutzer: Management, Analyst (Portfolio-Sicht).

UI-Paradigma: Dashboard mit Drill-Down

Das Dashboard trennt zwischen Holding-Level (Gesamtportfolio) und Subfirmen-Level (einzelne Gesellschaften).
Charts sind interaktiv: Klick auf einen Balken (z. B. „Sanierungsbedarf Region X”) springt direkt in die betroffene Objektliste in Säule A — kein Kontextwechsel, kein neues Tab.
KPIs mit Drill-Down-Pfad sind immer als solche erkennbar (Hover-Cursor, Unterstrich).

Level-Umschalter

Holding-Level und Subfirmen-Level schalten per Kontext-Pill oben im Dashboard — kein Modus-Dialog, sofort greifbar. Beide Levels teilen dieselbe Seite, nur die Aggregationsebene wechselt.

Verwandte Screens: ../20-screens/02-dashboard.md

C · Exploratives Simulations-Tool (System of Innovation / Planning)

Fokus: Szenarienrechnung und Constraint-geführte Optimierung — „Was passiert, wenn wir Sanierung X in Objekt Y machen unter Z€ Budget?”

Nutzer: Analyst, Modellierer.

UI-Paradigma: Canvas / Workspace im „Entwurfs-Modus”

Der Nutzer verlässt die Datenbank-Ansicht und wechselt in einen Entwurfs-Modus — mentale Haltung: Skizzieren, nicht Pflegen.

Split-Screen

Split-Screen Simulation-Controls und Echtzeit-Visualisierung

Rechte Seite re-kalkuliert bei jeder Regler-Bewegung; kein „Berechnen”-Button.
Split-Screen-Breite ist per Drag adjustierbar.

Constraint-Chips

Der Nutzer definiert Anforderungen als Constraint-Chips (Tags):

[ Budget < 500 k€ ]   [ Rendite > 4 % ]   [ Energieklasse ≥ B ]   [ + Constraint ]
   ↑ grün / gelöst       ↑ grün              ↑ gelb / offen          ↑ hinzufügen

Chips sind AND-verknüpft.
Bei Konflikten zwischen Chips zeigt das System direkt an, welcher Constraint die Optimierung verhindert (Chip wechselt Farbe + Tooltip erklärt den Konflikt).
Gelöste Constraints werden grün, offene gelb, konfliktverursachende rot.

Szenarien-Freeze

Wenn ein Szenario als tragendes Szenario markiert wird, wandert es zurück in Säule A (als fachlich festgelegter Case) und Säule B (erscheint im Dashboard). Die drei Säulen sind damit kein One-Way-Flow, sondern ein Kreislauf.

Navigationsprinzip zwischen den Säulen

Die drei Säulen sind in der App-Shell als Top-Level-Navigationsbereiche verankert (nicht als Tabs innerhalb einer Seite):

Säule	Nav-Label	Icon-Metapher
A · Verwaltungs-Core	„Bestände”	Datenbank/Tabelle
B · Dashboard	„Portfolio”	Balkendiagramm
C · Simulation	„Szenarien”	Regler/Slider

Kontextübergreifende Aktionen (z. B. Drill-Down von B nach A, Freeze von C nach A) nutzen Deep-Links, die den Zielkontext mitgeben — kein manuelles Navigieren.