Kontrollzentrum

Diese Seite erklärt den realen Dashboard-Bereich Kontrollzentrum. Sie beschreibt, wie offene Alerts, Prioritaeten, Severity-Filter und Resolve-Flow zusammenhelfen, Risiken frueh sichtbar und bearbeitbar zu machen.

Rolle

Frueherkennungs- und Priorisierungszentrale für offene Risiken und Warnlagen.

Wichtig für

Tagespriorisierung, Eskalation, schnelle Lageprüfung und strukturierte Rückspruenge in Fachmodule.

Nicht allein zuständig für

die eigentliche fachliche Behebung ohne Rückkopplung in Integrationen, Einstellungen, Rechtliches oder andere Bereiche.

Was dieser Bereich im Produkt wirklich macht

Kontrollzentrum ist die verdichtete Risikosicht des Systems. Das Modul buendelt offene Hinweise, priorisiert sie nach Schweregrad und macht daraus eine bearbeitbare Queue statt einer verstreuten Menge einzelner Warnungen.

In der aktuellen UI besteht der Bereich aus KPI-Karten, einer Alert Queue, Severity-Filtern und einem direkten Resolve-Flow. Dadurch ist die Seite weder normales Reporting noch nur ein To-do-Block, sondern ein operativer Übergabepunkt für kritische und mittlere Themen.

Wie die Seite aufgebaut ist

Offene Aufgaben

Zeigen die Gesamtmenge offener Alerts.

Prioritätskarten

Trennen kritische, mittlere und niedrige Hinweise.

Alert Queue

Listet Herkunft, Titel, Priorität, Zeit und Aktion.

Severity-Filter

Schalten gezielt zwischen all, critical, medium und low um.

Bereichsspalte

Zeigt, aus welchem Modul oder Systemtyp ein Alert stammt.

Zeitspalte

Hilft, Frische und Dringlichkeit zeitlich einzuordnen.

Resolve-Button

Markiert einen Alert aktiv als erledigt.

Empty State

Kommuniziert, wenn aktuell keine offenen Alerts sichtbar sind.

Was dieser Bereich öffentlich und intern beeinflusst

Intern stark priorisierend

Das Kontrollzentrum beeinflusst, welche Risiken zuerst behandelt werden und wie schnell Teams auf kritische Warnlagen reagieren.

Extern indirekt qualitaetsrelevant

Kunden sehen diese Seite nicht, merken aber ihre Wirkung dort, wo Probleme frueher entdeckt und vor groesseren Auswirkungen bearbeitet werden.

Wichtige Abgrenzung

Das Kontrollzentrum zeigt und priorisiert Probleme. Die eigentliche Fachbearbeitung passiert danach im zuständigen Modul.

Was sieht der Kunde davon?

Indirekt in frueherer Reaktion

Kunden merken das Kontrollzentrum dort, wo Risiken oder Stoerungen frueher erkannt und nicht erst spaet sichtbar werden.

Im Eindruck geordneter Aufsicht

Ein Team mit klarer Warnlogik arbeitet weniger reaktiv und kann kritische Punkte strukturierter behandeln.

Praktische Übersetzung in Kundensprache

Gute Alert-Logik sagt: Probleme werden frueh gesehen statt zufaellig entdeckt.

Klare Priorisierung sagt: Kritische Themen gehen nicht im Alltag unter.

Saubere Bearbeitung sagt: Hinweise werden nicht nur angezeigt, sondern wirklich geschlossen.

Screenshots und visuelle Orientierung

Diese Bildplätze sind wieder als Screenshot-Layer vorbereitet. Beim Kontrollzentrum sind vor allem KPI-Karten, Filter und die Alert Queue wichtig, weil sie den Charakter der Seite als Priorisierungsmodul am klarsten zeigen.

Empfehlung: lieber Prioritaetskarten und Queue getrennt zeigen, damit Lagebild und operative Liste klar bleiben.

Die Funktionsblöcke im Detail

1. Früherkennungsmodul für operative Risiken

Das Kontrollzentrum ist in der aktuellen UI kein allgemeines Dashboard, sondern eine Früherkennungsschicht für offene Risiken, Warnsignale und Aufgaben mit Priorität. Es sammelt systemrelevante Hinweise an einem Ort, damit Teams sie nicht nur zufällig in einzelnen Fachmodulen entdecken.

Pflegt

offene Alerts mit Priorität, Herkunft und Bearbeitungsstatus.

Beeinflusst

wie früh Risiken erkannt und an den richtigen Bereich zurückgespielt werden.

Häufig verwechselt mit

der Übersicht. Das Kontrollzentrum fokussiert Risiken und Warnlagen, nicht den Gesamtzustand des Studios.

Vorhanden: KPI-Karten, Alert Queue, Prioritätsfilter und Resolve-Flow.

Wirkung: Risiken werden als handhabbare Aufgaben sichtbar.

Praxis: stark für Inhaber, Manager und alle, die schnell auf kritische Hinweise reagieren müssen.

2. KPI-Karten für Gesamt und Prioritätsstufen

Die obere Kartenreihe zeigt offene Aufgaben insgesamt sowie die Verteilung nach kritisch, mittel und niedrig. Damit wird die Alert-Lage sofort lesbar, noch bevor einzelne Einträge betrachtet werden.

Pflegt

das schnelle Lagebild über Menge und Schärfe der offenen Alerts.

Beeinflusst

wie schnell Teams zwischen Sofortthemen und planbaren Hinweisen unterscheiden.

Häufig verwechselt mit

dekorativen Countern. In Wirklichkeit strukturieren sie die gesamte Bearbeitungsreihenfolge.

Vorhanden: Gesamt, Kritisch, Mittel, Niedrig.

Wirkung: Prioritätslage wird in einem Blick erfassbar.

Praxis: hilfreich für Tagesstart, Eskalation und schnelle Lageprüfung.

3. Severity-Filter für konkrete Priorisierung

Die Queue kann nach Alle, Kritisch, Mittel und Niedrig gefiltert werden. Dadurch ist das Modul nicht nur passiv lesbar, sondern aktiv auf Dringlichkeit steuerbar.

Pflegt

die fokussierte Sicht auf Alerts nach Schweregrad.

Beeinflusst

welche Aufgaben zuerst auf dem Tisch landen.

Häufig verwechselt mit

kleinen Komfort-Buttons. Tatsächlich definieren sie den operativen Fokus der Seite.

Vorhanden: all, critical, medium und low.

Wirkung: Alerts werden nach Dringlichkeit sofort sortier- und lesbar.

Praxis: wichtig, damit kritische Themen nicht in allgemeiner Menge untergehen.

4. Alert Queue als zentrale Arbeitsliste

Der Hauptblock der Seite ist eine tabellarische Alert Queue. Sie zeigt Herkunftsbereich, Alert-Titel, Priorität, Zeitpunkt und eine direkte Aktion zur Bearbeitung.

Pflegt

die konkrete Arbeitsliste offener systemrelevanter Hinweise.

Beeinflusst

wie klar Ursache und Bearbeitungsbedarf pro Alert verstanden werden.

Häufig verwechselt mit

einer simplen Aufgabenliste. In Wirklichkeit ist es die verdichtete Risikowarteschlange des Systems.

Vorhanden: Bereich, Eintrag, Priorität, Zeit und Aktion.

Wirkung: Teams erhalten einen direkten Einstieg in offene Warnlagen.

Praxis: geeignet für schnelle Lageklärung und operative Nachsteuerung.

5. Herkunftslogik über mehrere Produktbereiche

Jeder Alert träegt einen Source-Wert. Dadurch ist sofort sichtbar, aus welchem Bereich oder welchem Systemtyp ein Problem stammt. Das Kontrollzentrum bleibt damit kein isolierter Space, sondern ein Sammelpunkt für Hinweise anderer Module.

Pflegt

die Rückverbindung vom Alert zum Ursprungsbereich.

Beeinflusst

wie schnell Teams den richtigen Fachbereich öffnen.

Häufig verwechselt mit

einer kosmetischen Spalte. Eigentlich ist sie die Navigationshilfe zur Ursache.

Vorhanden: source_type bzw. Bereichsherkunft pro Alert.

Wirkung: Warnungen können fachlich eingeordnet statt nur abgehakt werden.

Praxis: stark für zielsichere Rücksprünge in andere Module.

6. Resolve-Flow statt nur Lesen

Die Seite erlaubt nicht nur das Lesen offener Warnungen. Mit "Als erledigt markieren" kann ein Alert direkt in einen erledigten Status überführt werden. Das macht das Kontrollzentrum zu einem operativen Clearing-Modul.

Pflegt

den Übergang von offen zu erledigt für Alerts.

Beeinflusst

wie sauber Risiken geschlossen und aus der offenen Lage entfernt werden.

Häufig verwechselt mit

einem simplen Close-Button. Tatsächlich ändert er den offenen Systemstatus eines Hinweises.

Vorhanden: resolve API-Flow mit Version und Status resolved.

Wirkung: offene Hinweise verschwinden nicht nur optisch, sondern werden statusbezogen bearbeitet.

Praxis: wichtig für klares Abarbeiten statt Alert-Stau.

7. Empty State für saubere Alert-Lage

Wenn keine Alerts offen sind oder nach dem Filter nichts mehr bleibt, zeigt die Seite einen klaren Empty State. Das signalisiert, dass gerade keine offenen Warnlagen im sichtbaren Bereich bestehen.

Pflegt

die sichtbare Rückmeldung, wenn aktuell keine relevanten Alerts vorliegen.

Beeinflusst

wie sicher Teams die aktuelle Lage als sauber interpretieren können.

Häufig verwechselt mit

einem leeren Tabellenrest. Der Empty State ist Teil der Lagekommunikation.

Vorhanden: "Keine offenen Alerts" bei leerem Filter- oder Gesamtergebnis.

Wirkung: die Seite kommuniziert auch Ruhe oder bereinigte Lage klar.

Praxis: hilfreich für Tagesabschluss oder nach systematischer Abarbeitung.

8. Alert als Startpunkt, nicht als Endpunkt

Ein Alert im Kontrollzentrum ist selten die eigentliche Lösung. Meist ist er der Startpunkt für die Rückkehr in Profile, Einstellungen, Integrationen, Rechtliches oder andere Fachmodule. Genau deshalb ist die Seite so wertvoll: Sie verdichtet, ohne die Ursache zu verstecken.

Pflegt

den Startpunkt für Folgearbeit in anderen Modulen.

Beeinflusst

wie gut Teams symptomatische Warnungen in echte Ursachenarbeit übersetzen.

Häufig verwechselt mit

dem finalen Ort der Problemlösung. Das Modul priorisiert und verweist, es ersetzt nicht den Fachbereich.

Vorhanden: Title-, Source- und Prioritätslogik für Rücksprünge in andere Bereiche.

Wirkung: das Kontrollzentrum wird zum Navigator für Folgeaktionen.

Praxis: besonders wichtig bei wiederkehrenden oder systemweiten Risiken.

Was diese Seite technisch in Daten und Aktionen verbindet

Der Bereich Kontrollzentrum verbindet offene Alerts aus der API mit Prioritaetsfiltern, KPI-Zaehlungen und einem Resolve-Flow. In der aktuellen JS-Logik arbeiten dafür apiAlerts, activeFilter, Prioritaetsmetadaten, Renderlogik für die Tabelle und ein API-Statuswechsel nach resolved zusammen.

Alert State
Jeder Alert traegt publicId, source, title, priority, createdAt, actionType, payload und version als bearbeitbaren Datensatz.
Severity Logic
critical, medium und low steuern sowohl KPI-Karten als auch die fokussierte Ansicht über Filterbuttons.
Resolve Flow
Beim Schliessen wird ein API-Call mit Version und status=resolved ausgelöst und die Liste danach neu geladen.
Queue Rendering
Alerts werden zeitlich sortiert und als offene Warteschlange mit Source, Title, Priority und Zeitpunkt gerendert.

Praktisch ist diese Seite damit kein generischer Statusscreen, sondern ein operativer Risk Queue Layer für systemweite Warnlagen. Genau deshalb eignet sie sich gut für AI-Assistants: Alerts sind knapp, strukturiert und über Prioritaet sowie Herkunft interpretierbar.

Empfohlene Reihenfolge bei der Bearbeitung

  1. 1 Zuerst die KPI-Karten lesen, um die aktuelle Risikolage insgesamt zu verstehen.
  2. 2 Dann mit dem Severity-Filter auf kritische Alerts fokussieren, bevor mittlere oder niedrige Themen bearbeitet werden.
  3. 3 Danach pro Alert den Herkunftsbereich und Titel lesen, um die echte Ursache fachlich einzuordnen.
  4. 4 Erst anschliessend in das zuständige Fachmodul wechseln und die eigentliche Bearbeitung durchführen.
  5. 5 Den Alert nur dann als erledigt markieren, wenn das zugrunde liegende Thema wirklich geklärt wurde.
  6. 6 Zum Schluss erneut prüfen, ob die Queue sauber aktualisiert wurde und keine weitere Warnlage offen bleibt.

Häufige Fehler auf dieser Seite

Alerts nur als optische Warnung lesen und nicht als Startpunkt für echte Ursachenarbeit.
Kritische und niedrige Themen gleich behandeln statt sauber nach Priorität zu trennen.
Alerts als erledigt markieren, bevor der zugrunde liegende Fachbereich wirklich korrigiert wurde.
Die Herkunftsspalte ignorieren und dadurch im falschen Modul nach der Ursache suchen.
Das Kontrollzentrum mit der Übersicht verwechseln und Warnlagen dadurch unterschätzen.
Eine leere Queue als allgemeine Systemgesundheit lesen, obwohl nur der aktuelle offene Alertbestand gemeint ist.

Fragen und Antworten

Ist das Kontrollzentrum dasselbe wie die Übersicht?
Nein. Die Übersicht zeigt den Gesamtzustand und nächste Schritte, während das Kontrollzentrum auf Risiken, Warnlagen und priorisierte Alerts fokussiert ist.
Warum sind die Prioritätsfilter so wichtig?
Weil sie helfen, kritische Themen sofort zu isolieren und nicht in einer gemischten Aufgabenmenge untergehen zu lassen.
Löst das Kontrollzentrum Probleme direkt?
Nicht inhaltlich. Es zeigt und priorisiert Hinweise, aber die eigentliche Fachbearbeitung passiert danach im passenden Modul.
Was bedeutet "Als erledigt markieren"?
Der offene Alert wird statusbezogen als resolved geschlossen und aus der offenen Lage entfernt, wenn das zugrunde liegende Thema bearbeitet wurde.
Ist eine leere Queue immer ein gutes Zeichen?
Sie zeigt, dass aktuell keine offenen Alerts sichtbar sind. Das ist hilfreich, ersetzt aber keine fachliche Prüfung anderer Module.

Weiter im Guide Center

Das Kontrollzentrum wird erst richtig stark, wenn Alerts nicht nur gelesen, sondern sauber in die zuständigen Fachbereiche zurückgespielt werden. Die folgenden Guides helfen, diese Rückspruenge im richtigen Kontext zu verstehen.

Alle Admin-Guides ansehen