Dashboard/docs/SCOPE-ANALYTICS-DASHBOARD.md

Scope: Analytics und Dashboard sind zwei Features

Stand: 29.08.2026. Von den offenen Punkten in Abschnitt 5 ist bisher genau einer entschieden und gebaut: die Navigation (5.5). Alles andere ist mit den Kollegen zu klären, bevor jemand Code anfasst.

---

1. Die Unterscheidung

Bisher wurde dieser Prototyp als „das Dashboard" bezeichnet. Das ist ungenau — es sind zwei Features mit unterschiedlichem Zweck:

	Analytics	Dashboard
Frage	„Warum ist das so?"	„Wie ist meine Lage?"
Charakter	Analysebereich, mehrere Seiten	Begrüßungsbildschirm, eine Seite
Einstieg	bewusst aufgesucht	erste Seite nach dem Login
Bedienung	Zeitraum + fünf Dimensionsfilter, seitenübergreifend	Widgets, je Widget nur Filter/Zeitraum
Inhalt	ausschließlich Auswertungen	Auswertungen und anderes
Zuschnitt	fachlich (Finanzen, Aufträge, Kunden, Team)	rollenbezogen (GF, Büro, Monteur)

Der entscheidende Unterschied: Das Dashboard zeigt die wichtigsten Charts aus Analytics, ist aber nicht darauf beschränkt. Es ist der Ort für alles, was beim Anmelden zählt — auch für Dinge, die keine Auswertung sind: „2 neue Anträge", offene Dokumente, Termine heute, zugewiesene Aufgaben.

Analytics liefert also Bausteine an das Dashboard, deckt es aber nicht ab.

---

2. Was die Software dafür bereits vorsieht

Das ist kein neuer Scope für HiveGrid Cloud — die Architektur ist darauf ausgelegt. Belegt in packages/view-models/src/dashboard/dashboard-page.vm.ts:

type DashboardRoleKey     = "gf" | "office" | "monteur";
type DashboardWidgetDomain = "general" | "sales" | "finance" | "projects"
                           | "tasks" | "hr" | "activity" | "comms" | "schedule";
type DashboardWidgetKind   = "hero" | "kpi" | "list" | "trend" | "chart";

Die Domäne hr und die Art list existieren bereits. „2 neue Anträge" ist damit ein hr/kpi- oder hr/list-Widget im Katalog — kein Sonderfall, sondern der vorgesehene Weg.

Der Designer-Brief P11 nennt die drei Rollen-Layouts sogar konkret:

GF (Begrüßung, Sales-KPIs, Umsatz-Forecast, Projekt-KPIs, Auslastung, offene Mängel, Team-heute) · Büro (Begrüßung, Projekt-KPIs, meine Tasks, Anrufe heute, HR-Anträge) · Monteur (meine Termine heute, meine Projekte, meine Tasks)

HR-Anträge stehen dort bereits im Büro-Dashboard. Die Idee ist also dokumentiert; was fehlt, ist die Verbindung zu unserer Analytics-Arbeit.

---

3. Was das für diesen Prototyp bedeutet

Die fünf Analyse-Seiten sind das Analytics-Feature. Daran ändert sich nichts — Finanzen, Aufträge, Kunden, Team und die Diagrammbausteine bleiben, wie sie sind.

Drei Stellen bekommen einen anderen Zuschnitt:

1. Die Seite „Übersicht" überschneidet sich mit dem Dashboard. Sie ist heute als Einstiegsseite gebaut: Kennzahlenreihe, Handlungsbedarf, Hauptdiagramm. Genau diese Rolle hat in der Software das Dashboard. Zwei Einstiegsseiten nebeneinander wären eine Doppelung.

2. Der Handlungsbedarf ist eigentlich ein Dashboard-Element. „Was ist zu tun" ist die Frage des Begrüßungsbildschirms, nicht der Analyse. Ich habe ihn in der letzten Runde bewusst nach oben auf die Übersicht gezogen, weil dort die Handlungsebene fehlte — unter der neuen Trennung gehört er wahrscheinlich ins Dashboard.

3. Charts müssen als Widgets einzeln funktionieren. Gute Nachricht: Sie tun es bereits. Die Diagrammkomponenten unter components/charts/ sind reine Komponenten, die ihre Daten als Prop bekommen — sie hängen an keiner Seite. Was nicht mitwandert, ist die Kartenhülle ChartCard: Ihr ⋯-Menü und das Ausblenden sind Analytics-Logik; im Dashboard macht das die Widget-Registry.

   Zu beachten ist der Bruch im Bedienmodell: In Analytics wirkt eine Filterleiste auf alle Karten gleichzeitig. Im Dashboard trägt jedes Widget seinen eigenen Zeitraum (P11: „Edit = nur Widget-Filter/Zeitraum"). Ein Chart, das aus Analytics ins Dashboard gehoben wird, verliert den globalen Filter und braucht einen eigenen — sonst zeigt es stillschweigend einen anderen Zeitraum als die Nachbarkachel.

---

4. Wie die beiden zusammenhängen

Analytics (ein Menüpunkt, Reiter innen)      Dashboard (eigener Menüpunkt)
├── Übersicht        ← Rolle unklar,  ┐      ├── Begrüßung
├── Finanzen           siehe 5.1      │      ├── KPI-Kacheln      ┐ aus dem
├── Aufträge                          ├──────┤ Trend-Charts       ┤ Analytics-
├── Kunden                            │      ├── Listen           ┘ Katalog
└── Team               (Daten: v2)    ┘      ├── HR-Anträge       ┐ NICHT aus
                                             ├── Meine Aufgaben   ┤ Analytics
                                             └── Termine heute    ┘

Die Kennzahl-Definitionen aus KPI-KATALOG.md und die Diagrammregeln aus DESIGN-SYSTEM.md gelten für beide Features. Ein Umsatzchart im Dashboard rechnet und aussieht wie dasselbe Chart in Analytics — sonst widersprechen sich zwei Seiten derselben Anwendung.

---

5. Offene Punkte

Nicht entschieden. Reihenfolge nach Tragweite:

5.1 Was wird aus der Seite „Übersicht"?

• A: Sie wird das Dashboard. Analytics startet dann bei Finanzen.
• B: Sie bleibt als Analytics-Einstieg, verliert aber Handlungsbedarf und Begrüßungscharakter und wird zur reinen Kennzahlen-Zusammenfassung.
• C: Sie entfällt; Analytics besteht aus vier fachlichen Seiten.

5.2 Welche Analytics-Charts werden Dashboard-Widgets? Der Katalog braucht eine Auswahl. Nicht jedes Chart taugt als Kachel — der Vertriebstrichter etwa lebt von der Übergangsquote und wird klein unlesbar.

5.3 Wo lebt der Handlungsbedarf? Vermutlich Dashboard. Dann fehlt Analytics die Handlungsebene — bewusst akzeptieren oder anders lösen.

5.4 Zeitraum-Modell im Dashboard. Globaler Filter wie in Analytics oder pro Widget wie in P11? Die Software hat sich für „pro Widget" entschieden; das ist beim Übertragen zu beachten.

5.5 Navigation — entschieden am 29.08.2026. Analytics ist ein einzelner Menüpunkt in der Seitenleiste, gleichrangig neben Dashboard. Die fünf Analyse-Seiten sind darin über Reiter erreichbar, nicht als Unterpunkte in der Navigation. Das Dashboard bleibt als eigener Menüpunkt daneben. Umgesetzt; siehe NAVIGATION.md.

Offen bleibt daran nur 5.1: Wenn die Übersichtsseite zum Dashboard wird, verliert der Analytics-Bereich seinen ersten Reiter.

5.6 Team-Seite. Unabhängig davon offen, weil Zeiterfassung im v2-Backlog steht — siehe DATENMODELL.md.

---

6. Bis zur Klärung

Am Code ändert sich nichts. Der Prototyp bleibt in seinem jetzigen Zuschnitt brauchbar: Die Diagrammbausteine, Kennzahl-Definitionen und Regeln gelten unabhängig davon, wie die beiden Features später geschnitten werden. Die Übersichtsseite ist im Zweifel der Entwurf für das Dashboard — dann wäre sie nicht falsch, sondern nur am falschen Ort.