IT-Hub / ITSM

Zweck und Übersicht des Hubs

Der IT-Hub ist das operative IT-Zentrum nach dem ITIL-Framework. Von hier erreichen Sie die Betriebskonsole von Service Desk und NOC, die Bearbeitung von Incidents, Anfragen, Problems und Changes, die Knowledge Base, die Dashboards und das Reporting. Er ist das tägliche Werkzeug der Operatoren (L1/L2/L3), Teamleiter und IT-Manager und der Zugangspunkt zu den Leitungsansichten des Service.

Diese Seite ist in Abschnitte gegliedert: zuerst die Seiten des Hubs (Landing Page, Betriebskonsole, Change, Problem, Major Incident, Knowledge Base, Voicemail), dann die übergreifenden Modals für Tickets (Editor, Composer, Inspector, Taxonomien, interne Notizen, Anhänge, Links, Massenaktionen, Playbook, KB, Dashboard, Qualitätskontrolle, historische Daten). Die Seiten ITOM, Events&AIOps, Operations Cockpit, IT Report Center und Customer Service werden hier erwähnt, aber auf den jeweiligen Seiten beschrieben.

Landing Page des IT-Hub

Wozu es dient. Die Einstiegsseite des Hubs: Sie zeigt die Schnellaktionen des Hubs und die Kacheln (Tiles) zu den operativen, Leitungs- und Reporting-Seiten.

Wann Sie es verwenden. Zu Beginn Ihrer IT-Sitzung, um den Arbeitsbereich auszuwählen, oder um die übergreifenden Aktionen zu starten (KB, CMDB, Qualitätskontrolle, Taxonomien).

Wie Sie es öffnen. Über die Home von Core (Kachel IT Hub) oder über die Werkzeugleiste „IT Hub“ auf den Seiten des Hubs.

Was es anzeigt. Im Kopfbereich ein Hero Strip mit dem Titel „IT Hub — Centro operativo IT · Network Operations · Service Desk · Operations & ITSM“ und die Schnellaktionen des Hubs:

Knowledge Base — öffnet die KB der Domäne IT.
CMDB / Assets — öffnet das zentrale CMDB.
Historische Daten — öffnet das Modal der archivierten Daten (Cold Store); erfordert einen ausgewählten Kunden (siehe Historische Daten).
Qualitätskontrolle — für berechtigte Rollen sichtbar; öffnet das Qualitäts-Review geschlossener Tickets (siehe Qualitätskontrolle).
Taxonomien — für Administratoren sichtbar; öffnet das Modal Ticket-Taxonomien (Ticket-Taxonomien).

Darunter sind die Kacheln in drei Abschnitte gruppiert:

Betrieb (CORE) — drei Hauptkacheln:

NOC · Network Operations — operative Queue mit Tier-Filter L1/L2/L3: Monitoring, Triage, Untersuchung, Eskalation.
Service Desk · Support & Anfragen — Service-Desk-Queue mit Tier-Filter L1/L2/L3: Triage, Resets, Incident/Problem, Katalog. (Die interne Domäne bleibt OPS.)
Customer Service · Gruppen pro Kunde — Tickets CS-* in den dedizierten Gruppen des Kunden (Customer Service, Enterprise Service und ICC).

Service-Leitung — drei Cockpits (sichtbar für Manager-/Direktorrollen, *:MGR):

NOC Service Director — P1/War Room live, SLA pro Kunde, Schichtabdeckung, Eskalation, Team-Broadcast.
Service Desk Director — FCR, AHT, Volumen pro Kanal, CSAT, Queue-Zeiten, Performance der Analysten.
Customer Service Director — Leitung der Kundenlinie über die kundenspezifischen Gruppen.

Operative Werkzeuge & Reporting — kompakte Kacheln: ITOM, Events & AIOps, Problem Management, Change Management, IT Operations Dashboard, IT Report Center, Voicemail.

Jede Kachel zeigt Symbol, Status-Badge (LIVE/NEW/…) und eine Feature-Zeile (die Tags der Hauptfunktionen). Am Seitenende befindet sich das einheitliche Bottom Dock mit Softphone, Chat und Präsenz.

Wie Sie es bedienen. Klicken Sie auf die Kachel des gewünschten Bereichs; die Schnellaktionen im Kopfbereich öffnen die jeweiligen Modals/Seiten. Welche Kacheln und Aktionen sichtbar sind, hängt von der Rolle ab (RBAC): Die Landing Page filtert die Kacheln nach den Zugriffsprofilen des Benutzers und dem erforderlichen Tier.

Was danach passiert. Die Navigation führt zur gewählten Seite bzw. Konsole; der Sitzungsstatus (aktueller Kunde/Tenant) wird an die Zielseiten übergeben.

Hinweise. Die Hub-KPIs wurden bewusst von der Landing Page entfernt: In der tenantübergreifenden Ansicht wären sie nicht aussagekräftig; die Kennzahlen befinden sich auf den eigenen Seiten (NOC-Konsole, SLA-Dashboard, Cockpits).

Betriebskonsole L1/L2/L3 (NOC und Service Desk)

Wozu es dient. Die Konsole zur Bearbeitung der Tickets in der Queue, die NOC und Service Desk über dieselbe Layout-Engine gemeinsam nutzen. Sie können die Queue überwachen, ein Ticket auswählen, seine Details sehen und mit Schnellaktionen und Kontextwerkzeugen handeln. Ein einziger Bildschirm deckt über den Tier-Filter alle drei Ebenen (L1/L2/L3) ab.

Wann Sie es verwenden. Sie ist den ganzen Tag der Arbeitsplatz des Operators: Übernahme, Diagnose, Eskalation, Lösung.

Wie Sie es öffnen. Über die Landing Page des IT Hub, Kacheln NOC oder Service Desk. Die Problem-Konsole (Problem Management Console) verwendet dasselbe Layout.

Was es anzeigt. Ein Layout mit drei Bereichen:

Queue (links) — die Liste der Tickets mit:
- Schnellfiltern: Alle, P1/P2, Meine, Unassigned, + L2/L3;
- Suche nach Schlüssel, Betreff oder CI;
- automatischer Aktualisierung alle 60 Sekunden (mit Uhrzeit der letzten Aktualisierung und Zähler).
Detail (Mitte) — das ausgewählte Ticket mit allen Daten; von hier öffnen Sie den Editor (Ticket-Editor) und die Aktionen.
Werkzeuge (rechts) — Kontext-Tabs, die sich je nach Tier ändern.

Oben eine KPI-Leiste. Für NOC L1: Offene Tickets, Aktive P1/P2, SLA-Verletzungen, MTTR (Min.), Heute gelöst.

Die Schnellaktionen (L1): Übernehmen (mir zuweisen), Escalate L2/L3 (Team GRP-NOC_L2), Lösen, Major Incident eröffnen (MIM-Eskalation). Die Werkzeuge L1: Verknüpfte CIs (CMDB Explorer), Runbook (KB NOC L1, Incident-Playbook), Monitoring (Grafana, Alertmanager), SLA-Timer (Restzeit), Dashboard (öffnet das KPI-Dashboard als Modal).

Beim Wechsel zum Tier L2 ändern sich KPIs, Aktionen und Werkzeuge: KPIs Offene Incidents, Offene P1/P2, Change Window, MTTR, Root-Cause pending; Aktionen Take ownership, Escalate L3, RCA starten (5-Why + Timeline), Change eröffnen (RFC → CAB), Escalate MIM; Werkzeuge RCA Workspace (Timeline Builder, 5-Why-Vorlage), Change Mgmt (CAB-Kalender, neuer RFC), Runbook L2/L3.

Unten die Links zu Service Topology und ITOM Health sowie das Bottom Dock mit Softphone (SIP), Chat und Präsenz.

Wie Sie es bedienen. Sie filtern und suchen in der Queue, wählen ein Ticket (Detail in der Mitte), handeln über die Schnellaktionen oder öffnen den Editor für die vollständige Bearbeitung; die Werkzeuge rechts geben Zugriff auf CMDB, Runbooks, Monitoring und SLA. Bei Mehrfachauswahl stehen die Massenaktionen zur Verfügung (Massenaktionen).

Was danach passiert. „Übernehmen“ weist das Ticket dem Operator zu; „Escalate“ verschiebt es an das nächsthöhere Team; „Lösen“ schließt es; „Major Incident eröffnen“ startet die MIM-Workbench (Major Incident Workbench). Jede Aktion aktualisiert Queue, KPIs, Timeline und Benachrichtigungen.

Hinweise. Tier-Filter und Eskalationsmatrizen, Teamnamen (GRP-NOC_*, GRP-OPS-*) und Queues werden zentral gesteuert; die automatische Aktualisierung hält die Queue aktuell, ohne die Seite neu zu laden.

Ticket-Editor

Das meistgenutzte Fenster in ganz exoCortex Core: Wir beschreiben es in zwei Abschnitten.

Wozu es dient, wann und wie Sie es öffnen

Wozu es dient. Der Ticket-Editor ist der Bearbeitungsbereich (Drawer) für ein einzelnes Ticket: Sie können alle Daten lesen, den Status ändern (Workflow-Übergänge), Felder bearbeiten, kommentieren, Anhänge und interne Notizen verwalten sowie SLA, Timeline, verknüpfte Tickets und den Audit-Trail einsehen.

Wann Sie es verwenden. Immer wenn Sie ein Ticket übernehmen oder aktualisieren: Übernahme, Fortschrittsmeldung, Informationsanfrage, Lösung, Abschluss.

Wie Sie es öffnen. Durch Klick auf ein Ticket in einer beliebigen Liste (Betriebskonsole, Queues, Suchergebnisse, Widgets) oder mit der Tastenkombination ⌘O (Strg+O), die einen Picker zur Eingabe des Ticketschlüssels öffnet.

Besonderheit — mehrere Tickets. Der Editor verwaltet bis zu 6 gleichzeitig geöffnete Tickets, jedes in einem eigenen Reiter (Tab) oben. Sie wechseln zwischen den Tickets per Klick oder mit ⌘Tab. Ein Reiter mit ungespeicherten Änderungen zeigt die Markierung „geändert“ (dirty). Jedes Ticket schließen Sie über das „x“ am Reiter.

Anzeigemodi. Der Drawer unterstützt drei Modi: seitlich angedockt (Side-by-Side), Breitbild (Fokus) und minimiert (PIP) unten. Esc minimiert den Drawer (Collapse), ohne dass Inhalte verloren gehen.

Was es anzeigt: Statusleiste und interne Tabs

Unter den Ticket-Reitern befindet sich eine Statusleiste mit den wichtigsten Attributen und Schnellsteuerungen: aktueller Status und Übergangs-Schaltflächen (Bestätigung mit ⌘↵); Priorität (Highest/High/Medium/Low/Lowest); Bearbeiter (Steuerelement „Zuweisen“, das die Benutzerauswahl öffnet); Anzeigen für Queue/Team, Typ und Schlüssel.

Der Hauptbereich ist in interne Tabs gegliedert:

Detail — die Felder des Tickets: Betreff, Beschreibung (reiner Text), Priorität und die benutzerdefinierten Felder (Custom Fields) des Issue Type, aus dem Katalog geladen und zusammen mit den anderen bearbeitbar. Speichern mit ⌘S.
Timeline — der chronologische Verlauf der Ereignisse (Anlage, Übergänge, Kommentare, Änderungen).
Kommentare — der Kommentarverlauf (Autor, Datum), in Markdown dargestellt, mit Eingabebereich und der Schaltfläche Kommentar senden (nur mit einem Entwurf aktiv).
SLA — die zugeordneten SLA mit Live-Countdown.
Linked — die verknüpften Objekte (Tickets, Anrufe, Chats, Links) mit Datum und Herkunft; Sie fügen sie mit dem Link Picker hinzu (Ticket verknüpfen).
Anhänge — die Liste der Dateien mit Anzeigen, Herunterladen, Löschen und Hochladen; Anhänge sind unveränderlich (zum „Ändern“ löschen Sie die Datei und laden sie neu hoch).
Interne Notizen — dem Team vorbehaltene Anmerkungen (Interne Notizen).
Audit — die Lifecycle-Timeline.
Postmortem — der Tab für das Post-Incident-Review bei Typen, die es vorsehen (Major Incident, SOC Incident).

Betrifft das Ticket ein CI bzw. einen Host, steht Console PAM zur Verfügung (privilegierter Zero-Knowledge-Zugriff auf das System).

Wie Sie es bedienen und was danach passiert

Status ändern: Wählen Sie den Übergang; der Workflow geht weiter, die Timeline erfasst das Ereignis, und Benachrichtigungen und Automatisierungen werden ausgelöst (Zuweisungen, SLA, Eskalationen).
Felder bearbeiten: Bearbeiten Sie die Felder im Tab Detail und speichern Sie mit ⌘S; die Änderungen werden gesammelt übertragen. Beschreibung und Kommentare sind reiner Text (Single Source): Was Sie schreiben, wird genauso gespeichert und wieder angezeigt.
Kommentieren: Schreiben Sie im Tab Kommentare und senden Sie ab; der Kommentar wird in den Verlauf übernommen und gemäß der Benachrichtigungsmatrix gemeldet.
Anhänge verwalten / zuweisen: über die jeweiligen Tabs bzw. Steuerelemente.

Tastenkombinationen: ⌘O Picker öffnen · ⌘S speichern · ⌘↵ Übergang · Esc minimieren · ⌘Tab nächstes Ticket.

Hinweise. Die verfügbaren Aktionen (Übergänge, Feldbearbeitung, Löschen von Anhängen, Sichtbarkeit interner Notizen) hängen von den Berechtigungen der Rolle ab. Der Tab Postmortem erscheint nur bei Typen, die ihn vorsehen.

Composer, Ticket anlegen

Wozu es dient. Das Fenster, in dem der Operator ein neues Ticket anlegt (im Auftrag eines Benutzers/Kunden oder aufgrund eines Anrufs/Chats).

Wann Sie es verwenden. Beim Eröffnen eines neuen Falls: Anruf beim Service Desk, Anfrage per Chat, zu überwachende Meldung, manuelles Anlegen von Incident/Request/Change.

Wie Sie es öffnen. Über die Schaltfläche zum Anlegen in Listen/Cockpits oder mit Strg+N. Der Kontext kann aus einem aktiven Chat oder Anruf übernommen werden: Melder, Betreff, Beschreibung, CI, Anhänge, zugehöriger Incident, Typ.

Was es anzeigt. Ein zentriertes Modal (mit Fokusmodus im Breitbild und PIP unten links) in drei Schritten mit schrittweiser Einblendung:

Identify — Zielprojekt/-Tenant, Kanal, Antragsteller (Reporter).
Classify — Ticket-Typ (Issue Type) und Domäne (Menü gefiltert nach Domänenbereich), Priorität und Kategorie.
Detail — Betreff, Beschreibung, spezifische Felder, Anhänge, gegebenenfalls eine erste interne Notiz.

Jeder Schritt hat eine Statusanzeige (offen/in Arbeit/abgeschlossen). Daneben das Panel AI Copilot: Titelvorschlag, Prioritätsvorschlag, Kategorisierung, Duplikaterkennung, passende KB-Artikel und Runbooks.

Wie Sie es bedienen. Füllen Sie die drei Schritte aus (der Typ bestimmt die Pflichtfelder — Serviceanfragen). Mehrere Entwürfe: bis zu 5 Entwürfe gleichzeitig, serverseitig und lokal gespeichert, mit automatischem Speichern alle 3 Sekunden. Absenden mit Strg+Enter oder über die Schaltfläche: Das Ticket wird angelegt; eine eventuelle erste interne Notiz wird unmittelbar danach hinzugefügt. Tastenkombinationen: Strg+N neuer Entwurf · Strg+S speichern · Strg+Enter absenden · Esc minimieren.

Was danach passiert. Das Ticket tritt in den Workflow seines Typs ein, wird gemäß den Routing-Regeln der Domäne an die zuständige Queue bzw. das zuständige Team geleitet, und die Benachrichtigungen werden erzeugt. Sie können das Ticket sofort im Editor öffnen (Ticket-Editor).

Hinweise. Der Ziel-Tenant muss konkret sein: Platzhalterwerte (*, __ALL__) werden abgelehnt. Ohne Angabe einer Domäne wird kein Standardtyp erzwungen.

Ticket-Vorschau

Wozu es dient. Zeigt ein Ticket schreibgeschützt mit Vorschau, Druck und Export an, ohne es zur Bearbeitung zu öffnen.

Wann Sie es verwenden. Für einen schnellen Blick, zum Drucken oder um den Link zu einem Ticket zum Teilen zu kopieren.

Wie Sie es öffnen. Über die Vorschauaktion in Listen und Widgets.

Was es anzeigt. Die Daten und Kommentare des Tickets: Betreff, Antragsteller, Status, Priorität, Beschreibung und Kommentarverlauf.

Wie Sie es bedienen. Schaltflächen für Druck/Export und Link kopieren.

Was danach passiert. Die Daten werden nicht verändert (schreibgeschützt). Zum Bearbeiten wechseln Sie in den Editor.

Hinweise. Kommentare sind optional (ohne Kommentare bleibt die Ansicht gültig).

Ticket-Taxonomien

Wozu es dient. Legt die Service-Kategorien und -Unterkategorien fest, mit denen der Composer Tickets klassifiziert. Es ist das Konfigurationswerkzeug der globalen Taxonomie.

Wann Sie es verwenden. Wenn der Administrator Klassifizierungskategorien für Tickets anlegen oder ändern muss.

Wie Sie es öffnen. Über die Aktion Taxonomien im Hero-Bereich der IT-Landing-Page (für Administratoren sichtbar).

Was es anzeigt. Den globalen Baum Category/Subcategory mit den vorhandenen Einträgen und den Steuerelementen zum Anlegen, Ändern und Entfernen.

Wie Sie es bedienen. Sie fügen Kategorien und Unterkategorien hinzu oder ändern sie; diese füllen die Auswahl „Typ/Kategorie“ im Composer (Composer, Ticket anlegen) und werden für Routing und Reporting verwendet.

Was danach passiert. Die Änderungen stehen im Composer und in den Klassifizierungswerkzeugen zur Verfügung; die Taxonomien sind eine einzige Quelle.

Hinweise. Es handelt sich um eine administrative Funktion.

Interne Notizen

Wozu es dient. Verwaltet die dem Team vorbehaltenen Anmerkungen zu einem Ticket, die für den Antragsteller nicht sichtbar sind.

Wann Sie es verwenden. Um Bearbeitungsinformationen, Hypothesen, Kontakte oder sensible Details festzuhalten, die nicht in der Kommunikation mit dem Benutzer erscheinen sollen.

Wie Sie es öffnen. Über den Tab Interne Notizen im Editor (Ticket-Editor).

Was es anzeigt. Die Liste der internen Notizen des Tickets mit Autor und Datum und den Eingabebereich für eine neue Notiz.

Wie Sie es bedienen. Fügen Sie eine Notiz hinzu; sie bleibt nur für Operatoren/Teams mit Berechtigung sichtbar.

Was danach passiert. Die Notiz wird am Ticket erfasst (getrennter Kanal von den öffentlichen Kommentaren) und trägt zur internen Nachverfolgbarkeit bei.

Hinweise. Die Sichtbarkeit interner Notizen hängt von den Berechtigungen der Rolle ab.

Anhangs-Viewer

Wozu es dient. Damit können Sie die Anhänge eines Tickets anzeigen, drucken und herunterladen, ohne sie zum Öffnen lokal speichern zu müssen.

Wann Sie es verwenden. Um während der Bearbeitung eine angehängte Datei (Bild, PDF, Log) zu prüfen.

Wie Sie es öffnen. Über die Aktion Anzeigen im Tab Anhänge des Editors oder an allen Stellen, an denen ein Anhang angezeigt wird.

Was es anzeigt. Die Vorschau der Datei mit den Befehlen zum Drucken und Herunterladen.

Wie Sie es bedienen. Öffnen Sie den Anhang, sehen Sie ihn ein, und drucken oder laden Sie ihn bei Bedarf herunter.

Was danach passiert. Die Datei wird nicht verändert (Anhänge sind unveränderlich).

Hinweise. Um einen Anhang zu „ändern“, löschen Sie ihn und laden eine neue Version hoch.

Ticket verknüpfen

Wozu es dient. Erstellt eine Verknüpfung zwischen Tickets (typisierte Beziehung: z. B. „dupliziert“, „blockiert“, „zugehörig“).

Wann Sie es verwenden. Um ein Ticket mit anderen in Beziehung zu setzen (Incidents zum selben Problem, doppelte Anfragen, Abhängigkeiten).

Wie Sie es öffnen. Über den Tab Linked im Editor.

Was es anzeigt. Den Verknüpfungstyp, ein Suchfeld für das Zielticket (das Quellticket ist ausgeschlossen, um Selbstverknüpfungen zu vermeiden) und einen optionalen Kommentar.

Wie Sie es bedienen. Wählen Sie den Typ, suchen und wählen Sie das Zielticket und bestätigen Sie.

Was danach passiert. Die Verknüpfung wird erstellt, und der Tab Linked des Tickets wird neu geladen und zeigt die neue Beziehung.

Hinweise. Der Katalog der Link-Typen ist eine einzige Quelle; Selbstverknüpfungen werden verhindert.

Massenaktionen

Wozu es dient. Führt Aktionen für mehrere ausgewählte Tickets auf einmal aus: Massenschließung und Masseneskalation.

Wann Sie es verwenden. Um mehrere gleichartige Tickets gesammelt abzuarbeiten (z. B. eine Reihe erledigter Alerts schließen oder eine Gruppe von Tickets an dasselbe Team eskalieren).

Wie Sie es öffnen. Wählen Sie mehrere Tickets in der Queue bzw. Liste aus und wählen Sie die Massenaktion.

Was es anzeigt. Die Liste der ausgewählten Tickets, die Auswahl der Aktion (schließen/eskalieren) und die erforderlichen Parameter (Lösung beim Schließen, Zielteam bei der Eskalation — aus dem Kontext bereitgestellt, nicht fest codiert).

Wie Sie es bedienen. Bestätigen Sie die Aktion: Schließen schließt die ausgewählten Tickets, Eskalieren hebt sie auf die nächste Ebene. Eine gültige Auswahl ist erforderlich.

Was danach passiert. Die Tickets werden gesammelt aktualisiert; Queue und KPIs werden neu geladen; jede Änderung wird im Audit erfasst.

Hinweise. Die verfügbaren Lösungen und Teams ergeben sich aus der Tenant-Konfiguration.

Playbook Launcher

Wozu es dient. Listet die für den Kontext der Seite oder des Tickets passenden Playbooks/Runbooks auf und führt sie aus.

Wann Sie es verwenden. Um ein standardisiertes Verfahren (Diagnose, Remediation, Kommunikation) auf einen Incident oder ein CI anzuwenden.

Wie Sie es öffnen. Über die Schnellaktion Playbook der Verwaltungsseiten oder über das im Bottom Dock registrierte Symbol.

Was es anzeigt. Die passenden Playbooks, gefiltert nach Domäne und Tag und für den Tenant freigegeben, mit der Möglichkeit, Kontext-Input anzugeben (z. B. das betroffene CI).

Wie Sie es bedienen. Wählen Sie ein Playbook und führen Sie es als Dry-run (Simulation) oder mit Ausführen (echte Ausführung) aus; dabei wird die Playbook-API verwendet.

Was danach passiert. Die Ausführung bewirkt ihre Effekte (automatische Aktionen, Aktualisierungen an Ticket/CI) und protokolliert das Ergebnis.

Hinweise. Der Tenant ist der der Sitzung und wird nicht manuell angegeben; sensible Aktionen sind durch Schutzschranken gesichert.

Knowledge Base

Wozu es dient. Sucht und zeigt Knowledge-Base-Artikel direkt während der Bearbeitung an, für schnelle Lösungen und KB-Deflection.

Wann Sie es verwenden. Während Triage/Diagnose, um ein Verfahren oder einen hilfreichen Artikel zu finden, ohne die Seite zu verlassen.

Wie Sie es öffnen. Über die Schnellaktion KB in den Werkzeugen der Betriebskonsole oder an Stellen, die die KB-Suche integrieren.

Was es anzeigt. Ein Suchfeld und die Ergebnisliste; wenn Sie einen Artikel auswählen, die Artikelansicht mit Titel, Metadaten und Text.

Wie Sie es bedienen. Geben Sie eine Suchanfrage ein und suchen Sie; öffnen Sie den Artikel und lesen Sie ihn; mit „Zurück“ kehren Sie zur Liste zurück.

Was danach passiert. Der Artikel kann den Fall lösen (Deflection) oder die nötigen Schritte liefern; die KB speist auch die Vorschläge des AI Copilot im Composer.

Hinweise. Der Such-Endpoint ist kanonisch; die vollständige KB verwalten Sie auf der eigenen Seite (Knowledge Base).

KPI-Dashboard

Wozu es dient. Öffnet ein redaktionelles KPI-Dashboard als Overlay, ohne eine separate Seite zu öffnen.

Wann Sie es verwenden. Um die KPIs eines Bereichs (z. B. NOC L1 Monitoring) kurz einzusehen, während Sie in der Konsole arbeiten.

Wie Sie es öffnen. Über die Schnellaktion KPI-Dashboard öffnen in den Werkzeugen der Konsole.

Was es anzeigt. Den aus echten Daten erzeugten redaktionellen Bericht: KPIs, Trends, Aufschlüsselungen.

Wie Sie es bedienen. Öffnen Sie es und sehen Sie die Diagramme und Werte ein; es ersetzt die früheren separaten Dashboards.

Was danach passiert. Die Daten werden nicht verändert (schreibgeschützt); beim Schließen kehren Sie zur Konsole zurück.

Hinweise. Ist die Laufzeitumgebung des Berichts nicht verfügbar, schlägt das Modal ausdrücklich fehl (Fail-Loud), ohne Scheindaten.

Change Management

Wozu es dient. Steuert den Lebenszyklus von Infrastruktur-Changes nach ITIL: Standard (vorab genehmigt, ohne CAB), Normal (CAB-Genehmigung) und Emergency (eCAB-Genehmigung), mit den Change-Freeze-Fenstern.

Wann Sie es verwenden. Um Changes zu erfassen, zu bewerten, zu genehmigen und zu planen sowie CAB-Sitzungen und Sperrfenster zu verwalten.

Wie Sie es öffnen. Über die Landing Page des IT Hub, Kachel Change Management, oder über die Betriebskonsole (Aktion „Change eröffnen“ im Tier L2).

Was es anzeigt. Eine KPI-Zeile und vier Tabs:

Liste — die Changes mit Status, Typ, Risiko, Zeitfenster und Ergebnis.
CAB — die Agenda des Change Advisory Board: zu besprechende RFCs, Teilnehmende, Abstimmungen (Typ IT-CAB-MEETING).
Calendar Window — der Kalender der Change-Fenster (Monatsraster) mit dem „vorgeschlagenen Fenster“.
Audit Trail — die Spur der Aktionen an den Changes.

Wie Sie es bedienen. Sie legen einen Change (RFC) an bzw. bewerten ihn, bringen ihn zur Genehmigung ins CAB und planen das Ausführungsfenster; aus jedem Change öffnen Sie den Editor, um ihn fortzuschreiben und die Genehmigungen zu erfassen (Change-Genehmigung (CAB)).

Was danach passiert. Ein Normal Change erfordert vor der Ausführung die CAB-Genehmigung; ein Emergency Change folgt dem eCAB-Verfahren (nachträgliche Genehmigung). Während eines Freeze können Changes ohne ausdrückliche Freigabe des Change Managers nicht genehmigt werden.

Hinweise. CAB-Sitzungen können periodisch erzeugt werden; Protokoll und Abstimmungsergebnis werden am jeweiligen IT-CAB-MEETING festgehalten.

Change-Genehmigung (CAB)

Wozu es dient. Erfasst die Genehmigungsentscheidung zu einem Change (typischerweise ein Normal Change im CAB).

Wann Sie es verwenden. In der CAB-/eCAB-Sitzung, wenn der Change auf Genehmigung wartet und Sie zu den Genehmigenden gehören.

Wie Sie es öffnen. Über den Tab CAB oder den Editor des Change (Tab Genehmigungen). Es ist dasselbe Modal wie unter Genehmigung beschrieben, hier auf Changes angewendet.

Was es anzeigt und wie Sie es bedienen. Die Genehmigungskette mit den Schritten und ihrem Status sowie die Entscheidungen Genehmigen / Ablehnen / Informationen anfordern / Delegieren, mit Kommentar. Falls erforderlich, die Signatur.

Was danach passiert. Die Genehmigung des letzten Schritts gibt die Ausführung des Change im geplanten Fenster frei; eine Ablehnung schickt ihn zurück; alle Entscheidungen werden gemeldet und protokolliert.

Hinweise. CAB-/eCAB-Regeln und Freezes beeinflussen das Ergebnis (siehe Cockpits und Leitungsansichten/IT-Prozesse).

Problem Management Console

Wozu es dient. Verwaltet Problems und die Ursachenanalyse (RCA) bis hin zu Known Errors mit dokumentiertem Workaround.

Wann Sie es verwenden. Wenn mehrere Incidents eine gemeinsame Ursache haben oder um eine strukturierte Ursachenanalyse durchzuführen.

Wie Sie es öffnen. Über die Landing Page des IT Hub, Kachel Problem Management.

Was es anzeigt. Das Queue-Layout der Betriebskonsole (KPIs, Liste mit automatischer Aktualisierung alle 60 s), spezialisiert auf Problems, mit Verknüpfung zum CAB-Kalender und zu den zugehörigen Incidents. Es stellt die RCA (5-Why + Engine) und die Known Error DB (KEDB) bereit.

Wie Sie es bedienen. Sie eröffnen ein Problem, führen die RCA durch (5-Why-Vorlage, Timeline) und dokumentieren Grundursache und Workaround; aus einem Problem stufen Sie einen Known Error hoch und erstellen den zugehörigen KB-Artikel.

Was danach passiert. Ein veröffentlichter Known Error stellt den Workaround dem First Level zur Verfügung (KB-Deflection) und verkürzt die Lösungszeit wiederkehrender Incidents. Die Vorlage KEDB erfasst: Symptom, Root Cause, temporärer Workaround, dauerhafter Fix / zugehöriger Change, betroffene CIs, zugehörige Incidents.

Hinweise. Die RCA kann auch aus dem Tier L2 der Betriebskonsole gestartet werden (Aktion „RCA starten“).

Major Incident Workbench

Wozu es dient. Die Zentrale für das Management von Krisen (Major Incidents): Sie koordiniert War Room, Updates, Maßnahmen und Abschluss.

Wann Sie es verwenden. Wenn ein Major Incident ausgerufen wird (manuell oder per automatischer Regel, wenn ein P1-Incident 30 Minuten überschreitet).

Wie Sie es öffnen. Über die Aktion Major Incident eröffnen/eskalieren in der Betriebskonsole oder über direkte Links.

Was es anzeigt. Den Titel Major Incident Workbench, die Schaltfläche Resolve Major Incident, den Bereich Impact und vier Tabs:

Timeline — der chronologische Verlauf der Ereignisse des Incidents.
Actions — die Action Items, die während der Krise zugewiesenen Maßnahmen.
Comms — die Kommunikation (Updates an Stakeholder/Kunden).
Postmortem — das Post-Incident-Review.

Vorhanden ist die Incident Bridge (Schaltfläche Config MI / Bridge bearbeiten): Link zum Krisen-Call, Incident Commander, Teilnehmende, Timeline der Updates in Echtzeit. Der Abschnitt Linked tickets zeigt die mit dem Incident verknüpften Tickets.

Wie Sie es bedienen. Sie öffnen bzw. aktualisieren die Bridge, erfassen Action Items und Kommunikation und aktualisieren die Timeline; zum Abschluss klicken Sie auf Resolve Major Incident.

Was danach passiert. Nach der Lösung ist ein PIR (Post-Incident Review) verpflichtend, das im Tab Postmortem ausgefüllt wird. Die Updates gehen gemäß den eingestellten Kommunikationswegen an die Stakeholder.

Hinweise. Schwellenwerte und Klassifizierung der Major Incidents (P0–P3) konfigurieren Sie im Modal Config MI (Konfiguration Major Incident (Config MI)) und auf der Seite Admin MI Config (Admin MI Config).

Konfiguration Major Incident (Config MI)

Wozu es dient. Konfiguriert die Parameter der Major Incidents: Auslöseschwellen und Klassifizierung des Schweregrads.

Wann Sie es verwenden. Beim Setup oder bei der Überprüfung der MIM-Richtlinien.

Wie Sie es öffnen. Über die Schaltfläche Config MI in der Major Incident Workbench oder über die Seite Admin MI Config (Admin MI Config).

Was es anzeigt und wie Sie es bedienen. Die Schwellenparameter (z. B. die Zeit, nach der ein P1-Incident zum Major Incident wird) und die Klassifizierung P0–P3 (Klassifizierung von Major Incidents). Sie legen sie fest und speichern.

Was danach passiert. Die automatischen Regeln zum Anlegen von Major Incidents verwenden diese Parameter.

Hinweise. Es handelt sich um eine administrative Funktion.

Knowledge Base

Wozu es dient. Die vollständige Verwaltung der Knowledge Base: Suche, Artikel, Redaktion, Nutzungsanalyse und Administration. Sie speist den Self-Service und die KB-Deflection.

Wann Sie es verwenden. Um KB-Artikel (Typ IT-KB) zu suchen, zu erstellen, zu aktualisieren und zu analysieren.

Wie Sie es öffnen. Über die Aktion Knowledge Base auf der IT-Landing-Page oder über die Kachel KB.

Was es anzeigt. Fünf Tabs:

Search — Artikelsuche mit Suchfeld, Ergebnissen und Test einer Suchanfrage (um zu prüfen, was der Benutzer finden würde) sowie Vorschlägen.
Articles — die Liste der Artikel mit Filter nach Kategorie und die Liste der Kategorien; Schaltfläche Neuer Artikel.
Editor — das Verfassen des Artikels: 1 zusammenfassender Satz, Kategorie, Tags, Text, Anhänge und Veröffentlichungsstatus.
Analytics — die Nutzungskennzahlen (Anzahl Artikel, Artikel pro Kategorie).
Admin — die Administration der KB (Kategorien, Gültigkeit pro Land — z. B. „IT, FR, DE“).

Wie Sie es bedienen. Sie suchen und lesen; mit Redaktionsberechtigung erstellen oder aktualisieren Sie einen Artikel (Zusammenfassung, Kategorie, Tags, Text, Anhänge) und veröffentlichen ihn; im Tab Search testen Sie die Wirksamkeit der Suche; Analytics misst die Nutzung.

Was danach passiert. Veröffentlichte Artikel stehen im KB-Modal (Knowledge Base), in der Triage (Deflection) und im Self-Service zur Verfügung; die Gültigkeit pro Land steuert ihre Sichtbarkeit.

Hinweise. Es gibt eine öffentliche Ansicht (Domänen-KB, Artikel und öffentliche KB) für die externe Einsichtnahme.

Domänen-KB, Artikel und öffentliche KB

Domänen-KB — die Ansicht der Artikel gefiltert nach Domäne (IT/NOC/OPS/ITSM), erreichbar über die KB-Aktion des Hubs.
KB-Artikel — die Detail- und Redaktionsseite des einzelnen Artikels mit Kategorie, Tags, Autor und Text.
Öffentliche KB — die öffentliche Ansicht der für externe Leser bestimmten Artikel.

Voicemail

Wozu es dient. Sammelt die an den Service Desk geleiteten Sprachnachrichten (Benutzer / IT-Meldungen) und ermöglicht es, sie anzuhören, ihre Transkription zu lesen und sie in Tickets umzuwandeln.

Wann Sie es verwenden. Um Voicemails zu bearbeiten, die außerhalb der Geschäftszeiten eingegangen sind oder wenn das Softphone nicht angenommen hat.

Wie Sie es öffnen. Über die Landing Page des IT Hub, Kachel Voicemail (mit Zähler ungelesener Voicemails).

Was es anzeigt. Die Voicemail-Inbox mit Audioplayer, KI-Transkription (Whisper), Risk Scoring (Claude) und dem im Softphone integrierten Rückruf.

Wie Sie es bedienen. Sie hören bzw. lesen die Voicemail, bewerten das Risiko, rufen den Absender mit einem Klick zurück (Softphone-Rückruf) oder eröffnen aus dem Inhalt ein Ticket.

Was danach passiert. Der Rückruf startet einen Anruf; das Eröffnen eines Tickets führt zum Composer mit dem Kontext der Voicemail.

Hinweise. Die Seite wird mit den verknüpften Bereichen geteilt (gleicher kanonischer Endpoint).

Qualitätskontrolle

Wozu es dient. Führt das Qualitäts-Review geschlossener Tickets durch: Dokumentation, Ownership, SLA-Einhaltung, Prozess, Ergebnis und Sicherheit.

Wann Sie es verwenden. Für stichprobenartige oder systematische Qualitätsprüfungen geschlossener IT-Tickets.

Wie Sie es öffnen. Über die Aktion Qualitätskontrolle auf der IT-Landing-Page (sichtbar für Rollen mit Berechtigung zur Qualitätskontrolle).

Was es anzeigt und wie Sie es bedienen. Die Liste der zu prüfenden geschlossenen Tickets und das Raster der Qualitätskriterien; Sie bewerten jedes Kriterium und erfassen das Ergebnis des Reviews.

Was danach passiert. Die Ergebnisse fließen in die Qualitätskennzahlen des Service ein und können nicht konforme Tickets wieder öffnen bzw. kennzeichnen (QC-Gate).

Hinweise. Diese Funktion ist Qualitäts- und Managementrollen vorbehalten.

Historische Daten

Wozu es dient. Zeigt archivierte historische Daten, die nicht mehr in der operativen Datenbank vorhanden sind.

Wann Sie es verwenden. Um Tickets/Daten abzurufen, die über das operative Zeitfenster hinaus archiviert wurden.

Wie Sie es öffnen. Über die Aktion Historische Daten auf der IT-Landing-Page.

Was es anzeigt und wie Sie es bedienen. Die Suchoberfläche für das historische Archiv; ein ausgewählter Kunde ist erforderlich (ist der Kontext „Alle Tenants“ / *, fordert das Modal Sie zur Auswahl auf).

Was danach passiert. Die Ergebnisse werden schreibgeschützt aus dem Cold Archive angezeigt.

Hinweise. Betrifft Daten, die gemäß der Archivierungsrichtlinie ins historische Archiv verschoben wurden.

Mit dem Hub verknüpfte Seiten (an anderer Stelle beschrieben)

Von der IT-Landing-Page erreichen Sie auch Seiten, die an anderer Stelle behandelt werden, auf die hier verwiesen wird: ITOM und Events & AIOps (NOC, Observability und ITOM), IT Operations Dashboard / Operations Cockpit und die Ansichten Service Director (Cockpits und Leitungsansichten), IT Report Center (Cockpits und Leitungsansichten/Reporting), Customer Service (Customer Service, Enterprise Service und ICC), CMDB / Assets (Asset Management und CMDB).