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

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