Ein Screen beantwortet nicht jede Frage — vom Mega-Dashboard zum Produktportfolio
Ein Dashboard, eine App oder ein Screen kann Monitor, Explore, Story und Self-Service nicht gleichzeitig optimieren. Dieser Deep Dive erklärt, wann Produkte getrennt werden, welche Grundlage sie teilen und wer entscheidet.
Begriffe vor dem Lesen
- Dashboard — Wiederkehrender Entscheidungsschirm mit Zielgruppe, Rhythmus und klarer Leitfrage.
- Report — Darstellung oder Auswertung, die nicht automatisch einen operativen Entscheidungsschirm bildet.
- KPI — Kennzahl mit Definition, verantwortliche Person, Umfang, fachliche Ebene und erlaubter Nutzung.
- Nutzer — Person oder Team, das eine Aussage nutzt und Lücken zurückmelden muss.
- Accessibility / A11y — Barrierefreie Gestaltung, damit Inhalte auch ohne ideale Sicht, Maus oder Farbwahrnehmung nutzbar sind.
Einfach gesagt: Ausgangslage und Leitentscheidung
Ein Screen soll Close, Pipeline und Exception Queue für sales_otc zugleich beantworten — am Ende beantwortet er nichts zuverlässig. Geteilte Business-Wahrheit ist nicht dasselbe wie eine geteilte UI.
Geteilte Wahrheit liegt in Semantic Layer und Katalog; die UI folgt dem Job (Monitor, Explore, Queue). Close, Pipeline und Exception Queue nicht auf einen Screen pressen.
In einem Satz: Geteilte Wahrheit ist kein geteilter Screen.
Ein Screen ist kein Geschäftsmodell
Ein Screen soll Close, Pipeline und Exception Queue für sales_otc zugleich beantworten — am Ende beantwortet er nichts zuverlässig. Geteilte Business-Wahrheit ist nicht dasselbe wie eine geteilte UI.
Geteilte Wahrheit lebt in Metadaten, Katalog-Links und vor allem im Semantic Layer / Metrics Store. Das UI-Portfolio ist, wie verschiedene Jobs diese Wahrheit konsumieren. Alle Jobs in ein Mega-Dashboard zu pressen, wiederholt die Katalog-Illusion auf Präsentationsebene: alles sichtbar, nichts verlässlich.
Ein Job pro Produkt
| Produkttyp | Optimiert für | Bricht, wenn zusätzlich… |
|---|---|---|
| Dashboard / Monitor | Schneller Scan + Schwellen | Tiefes Multi-Dim-Explore |
| Explore / Workbook | Flexible Analyse | Executive-10-Sekunden-Scan |
| Story / Pack | Geführte Argumentation | Live-Ops-Exception-Handling |
| Self-Service-Builder | Erstellung | Zertifizierte Einzelaussage |
| Admin-Cockpit | System-Health | Business-Prozesszustand |
Konkurrieren zwei Zeilen der Tabelle auf einem Screen, Produkte trennen — nicht Tabs stapeln, bis das Briefing kollabiert.
Was geteilt bleiben muss
Screen-Trennung heißt nicht Bedeutungs-Trennung:
- Kennzahlendefinitionen und Korn → Kennzahlenmodell / Metrics Store
- Verantwortung, Klassifikation, Lineage-Zeiger → Metadaten / Katalog
- Zugriffspolicies → Plattform-Durchsetzung
- Freshness- und Qualitätsnachweise → operative Metadaten am Produkt
Ohne diese gemeinsame Grundlage erfindet jeder Screen lokale Wahrheit.
Wer die Trennung entscheidet
- Business- / Data Owner: welche Entscheidungsjobs im Umfang sind und welche Kennzahlen-Aussagen zertifiziert sind
- Analytics Product Owner: welche UI-Produkte existieren, Audience und Abnahmekriterien
- technischer Betreiber: technischer Veröffentlichungspfad, Performance-Budgets, Access-Verdrahtung
- Nutzer verantwortliche Person: bestätigt den Handoff-Pfad (Monitor → Explore → Ticket)
Ein einzelner „BI-Lead“ ohne Entscheidungsrechte für alle Jobs erzeugt Portfolio-Wildwuchs.
Migration vom Mega-Dashboard
- Claims und Audiences auf dem aktuellen Screen inventarisieren.
- Jeden Claim einem Produkttyp zuordnen.
- Einen Primär-Monitor behalten; Explore und Story-Packs herausziehen.
- Doppelte lokale Measures retire; alle Produkte auf dieselben Metric-IDs zeigen.
- Einseitige Portfolio-Map veröffentlichen, damit Requests nicht mehr als „noch eine Kachel“ landen.
Anti-Patterns
- „Eine App fürs Unternehmen“ als Governance-Slogan
- Tabs, die vier Produkttypen ohne eigene verantwortliche Person verstecken
- Geteilte UI mit ungeteilten Kennzahlendefinitionen
- Katalog als UI-Portfolio behandeln
- Explore blockieren, weil der Monitor hübsch bleiben muss
Dashboard operating
Part 3 of 6
View series