3.6 Erstdiagnose, Lösung und funktionale Eskalation (Teil 2/2)

Funktionale Eskalation

Kann ein Incident mit den vorhandenen Kenntnissen oder Berechtigungen nicht gelöst werden, wird er an eine geeignete Fachgruppe weitergegeben.

Dies bezeichnet ITIL als funktionale Eskalation.

Gründe können sein:

fehlendes Fachwissen

fehlende Zugriffsrechte

notwendige Herstellerunterstützung

Spezialwerkzeuge erforderlich

komplexe Infrastruktur

sicherheitsrelevante Vorfälle

mehrere betroffene Systeme

Eine Eskalation bedeutet nicht, dass jemand einen Fehler gemacht hat.

Sie dient dazu, den Incident möglichst effizient dort bearbeiten zu lassen, wo die passende Kompetenz vorhanden ist.

Typischer Eskalationsweg

Benutzer
      │
      ▼
Service Desk
      │
      ▼
2nd Level Support
      │
      ▼
3rd Level / Spezialisten
      │
      ▼
Hersteller oder Lieferant

Nicht jeder Incident durchläuft alle Ebenen.

Je besser Wissen dokumentiert wird, desto häufiger kann bereits der Service Desk helfen.

Warme und kalte Übergabe

Eine funktionale Eskalation sollte möglichst vollständig vorbereitet sein.

Kalte Übergabe

Das Ticket wird lediglich weitergeleitet.

Beispiel:

"Bitte prüfen."

Nachteile:

erneute Rückfragen

doppelte Arbeit

längere Bearbeitungszeit

Warme Übergabe

Die Situation wird vollständig beschrieben.

Beispiel:

bereits geprüfte Schritte

Messergebnisse

Logauszüge

bisherige Vermutungen

aktuelle Auswirkungen

gewünschte Unterstützung

Dadurch kann das nächste Team unmittelbar weiterarbeiten.

Merke

Eine gute Eskalation spart oft mehr Zeit als eine schnelle Eskalation.

Ticket-Pingpong vermeiden

Ein häufiger Fehler ist das ständige Weiterreichen zwischen Teams.

Beispiel:

Service Desk → Netzwerk → Server → Datenbank → Netzwerk

Jede Weiterleitung kostet Zeit.

Vor einer Eskalation sollte geprüft werden:

Ist wirklich das richtige Team ausgewählt?

Wurden genügend Informationen gesammelt?

Wurden bekannte Lösungen geprüft?

Sind alle notwendigen Daten vorhanden?

Swarming

Moderne IT-Organisationen arbeiten häufig mit Swarming.

Dabei arbeiten mehrere Spezialisten gleichzeitig an einem Incident.

Vorteile:

weniger Wartezeit

kein Ticket-Pingpong

schneller Wissensaustausch

bessere Zusammenarbeit

Dieses Vorgehen eignet sich besonders für:

Major Incidents

komplexe Cloud-Infrastrukturen

kritische Produktionssysteme

Workaround

Ein Workaround stellt den Service vorübergehend wieder her, ohne die eigentliche Ursache dauerhaft zu beseitigen.

Beispiele:

alternativer Drucker

Webversion statt Desktop-App

Ersatzserver

Neustart eines Dienstes

manuelle Verarbeitung

Der Benutzer kann weiterarbeiten.

Die Ursache kann später untersucht werden.

Dauerhafte Lösung

Eine dauerhafte Lösung beseitigt die eigentliche Ursache.

Beispiele:

Softwarefehler behoben

fehlerhafte Firewall-Regel korrigiert

Zertifikat erneuert

Speicher erweitert

Hardware ersetzt

Workaround oder Lösung?

Workaround	Dauerhafte Lösung
schnell	nachhaltig
Ursache bleibt bestehen	Ursache beseitigt
reduziert Auswirkungen	verhindert Wiederholung
oft Minuten	häufig Stunden oder Tage

Wann endet ein Incident?

Der Incident endet, wenn der vereinbarte Service wieder verfügbar ist.

Nicht erforderlich ist:

vollständige Ursachenanalyse

Softwarekorrektur

Herstellerupdate

Diese Arbeiten gehören häufig bereits zum Problem Management oder Change Management.

Dokumentation der Lösung

Eine gute Abschlussdokumentation enthält:

tatsächliche Ursache (falls bekannt)

durchgeführte Maßnahmen

verwendeten Workaround

endgültige Lösung

betroffene Systeme

notwendige Folgearbeiten

Dadurch können ähnliche Incidents später schneller gelöst werden.

Wissen zurückführen

Jeder gelöste Incident kann neues Wissen erzeugen.

Geeignete Ergebnisse:

neuer Knowledge-Artikel

aktualisierte Checkliste

neue Automatisierung

Anpassung eines Runbooks

Verbesserung einer Monitoring-Regel

Dadurch profitieren zukünftige Bearbeiter.

KI-Unterstützung

KI kann unterstützen bei:

ähnlichen Tickets

Knowledge-Artikeln

Loganalyse

Fehlermeldungen

Lösungsvorschlägen

Zusammenfassungen

Die Verantwortung bleibt jedoch beim Menschen.

KI ersetzt keine technische Bewertung.

Typische Diagnosefehler

Fehler 1

Zu früh auf eine Ursache festlegen.

Fehler 2

Mehrere Änderungen gleichzeitig durchführen.

Fehler 3

Logs nicht prüfen.

Fehler 4

Monitoring ignorieren.

Fehler 5

Keine Dokumentation.

Fehler 6

Ticket ohne ausreichende Informationen eskalieren.

Fehler 7

Workaround als endgültige Lösung betrachten.

Fehler 8

Bekannte Lösungen nicht verwenden.

Fehler 9

Symptom und Ursache verwechseln.

Fehler 10

Benutzer nicht über den aktuellen Stand informieren.

Praxisbeispiel

Meldung

Benutzer können sich nicht anmelden.

Erstdiagnose:

mehrere Benutzer betroffen

Active Directory erreichbar

DNS funktioniert

Zertifikat abgelaufen

Workaround

Anmeldung über Ersatzdienst möglich.

Dauerhafte Lösung

Neues Zertifikat installiert.

Folgearbeit

Monitoring erweitert, damit Zertifikatsabläufe künftig frühzeitig erkannt werden.

Checkliste Erstdiagnose

Checkliste funktionale Eskalation

richtige Fachgruppe

vollständige Ticketinformationen

bisherige Maßnahmen dokumentiert

Messergebnisse beigefügt

aktueller Status beschrieben

nächster Schritt definiert

Checkliste Abschluss

Bedeutung für Fachinformatiker für Systemintegration

Im Berufsalltag besteht die wichtigste Aufgabe häufig nicht darin, möglichst viele Systeme zu kennen.

Entscheidend ist vielmehr eine strukturierte Vorgehensweise.

Ein guter Fachinformatiker:

beobachtet zuerst,

dokumentiert sauber,

prüft systematisch,

nutzt vorhandenes Wissen,

eskaliert zielgerichtet,

kommuniziert verständlich,

und sorgt dafür, dass gewonnene Erkenntnisse dauerhaft dokumentiert werden.

Dadurch werden Incidents schneller gelöst und wiederkehrende Fehler langfristig reduziert.

Zusammenfassung

Ticket übernehmen

↓

Symptom verstehen

↓

Umfang bestimmen

↓

Änderungen, Monitoring und Logs prüfen

↓

Hypothesen testen

↓

Workaround oder Lösung durchführen

↓

Falls nötig funktional eskalieren

↓

Service wiederherstellen

↓

Lösung dokumentieren

↓

Wissen in Knowledge Base übernehmen

Verwandte Seiten

3.4 Tickets vollständig erfassen und kategorisieren

3.5 Auswirkungen, Dringlichkeit und Priorität

3.7 Ownership, hierarchische Eskalation und Major Incidents

Problem Management

Knowledge Management

Continual Improvement

Quellen

PeopleCert – ITIL 4 / ITIL 5 Incident Management

PeopleCert – ITIL 4 / ITIL 5 Service Desk

ITIL Practice Guides (Incident Management, Knowledge Management)

Framework-Stand: ITIL Version 5
Fachlicher Stand: August 2026