ITIL-Grundlagen: Incident, Problem, Change

Was ist ITIL – und warum solltest du das kennen?

ITIL steht fuer IT Infrastructure Library und ist das weltweit verbreitetste Rahmenwerk fuer IT-Service-Management (ITSM). Im Kern beschreibt ITIL, wie eine IT-Abteilung ihre Dienste strukturiert betreibt, verbessert und auf Stoerungen reagiert.

Du brauchst kein ITIL-Zertifikat und musst das Rahmenwerk nicht 1:1 implementieren. Aber die Grundkonzepte helfen dir enorm dabei, strukturierter zu arbeiten, Probleme schneller zu loesen und mit dem restlichen Team (oder dem Kunden) eine gemeinsame Sprache zu sprechen.

Die aktuellste Version ist ITIL 4 (seit 2019), die nicht mehr von starren Prozessen, sondern von flexiblen Practices spricht. Im Kern bleibt aber dasselbe: Incident, Problem und Change gehoeren zu den Kern-Practices, mit denen du als IT-Allrounder tagtaeglich arbeitest.

ITIL 4: Service Value System statt drei starre Prozesse

Die Vorgaengerversion ITIL v3 (2011) war in fuenf Lifecycle-Phasen mit rund 26 Prozessen organisiert – ein starres, sehr prozesslastiges Modell. ITIL 4 raeumt damit auf und ersetzt es durch das Service Value System (SVS): ein Rahmenwerk, das zeigt, wie alle Bestandteile einer Organisation – Menschen, Practices, Informationen, Partner – zusammenwirken, um Wert zu schaffen.

Die fuenf Komponenten des SVS

Die sieben Guiding Principles – als Faustregeln fuer den Alltag:

1. Fokus auf Wert (Focus on Value)
2. Dort anfangen, wo du stehst (Start Where You Are)
3. Iterativ vorgehen mit Feedback (Progress Iteratively with Feedback)
4. Zusammenarbeiten und Transparenz foerdern (Collaborate and Promote Visibility)
5. Ganzheitlich denken und arbeiten (Think and Work Holistically)
6. Einfach halten und praktisch bleiben (Keep It Simple and Practical)
7. Optimieren und automatisieren (Optimize and Automate)

Die Service Value Chain besteht aus sechs Aktivitaeten, die je nach Bedarf kombiniert werden: Plan, Improve, Engage, Design & Transition, Obtain/Build, Deliver & Support.

Value Streams: Aktivitaeten + Practices fuer einen konkreten Zweck

Ein Value Stream ist eine Kombination aus Value-Chain-Aktivitaeten und Practices, die auf ein konkretes Szenario zugeschnitten ist. Beispiel fuer “Vorfall beheben”:

Engage (Meldung entgegennehmen)
   → Deliver & Support (Diagnose, Loesung)
   → Improve (Muster erkennen, Known Error dokumentieren)

Genutzte Practices: Incident Management, Monitoring & Event Management,
                     Knowledge Management, Service Desk

Fuer “Change durchfuehren” sieht der Value Stream anders aus (Design & Transition steht im Vordergrund, genutzte Practices sind Change Enablement, Release Management, Deployment Management).

34 Practices statt 3 Prozesse

ITIL 4 kennt keine feste Prozess-Landkarte mehr, sondern 34 Management Practices in drei Gruppen:

Incident Management – Feuer loeschen

Was ist ein Incident?

Ein Incident (dt. Stoerung) ist jede ungeplante Unterbrechung oder Qualitaetsverschlechterung eines IT-Dienstes. Outlook startet nicht, der Drucker reagiert nicht, das ERP-System ist langsam – alles Incidents.

Das Ziel von Incident Management ist klar: Den Dienst so schnell wie moeglich wiederherstellen. Nicht zwingend die Ursache finden (das ist Problem Management), sondern den User wieder arbeitsfaehig machen.

Incident-Lifecycle

Meldung → Aufnahme → Klassifizierung → Priorisierung → Diagnose → Loesung → Abschluss

1. Meldung & Aufnahme Der User meldet einen Vorfall – per Telefon, E-Mail, Ticketsystem. Du nimmst das Ticket auf und erfasst:

• Betroffener User und Geraet
• Beschreibung des Problems (Was passiert? Seit wann? Wie oft?)
• Auswirkung auf den Betrieb

2. Klassifizierung Welche Kategorie? Netzwerk, Hardware, Software, Sicherheit, Zugriffsberechtigungen?

3. Priorisierung Die Prioritaet ergibt sich aus zwei Faktoren:

Prioritaetsmatrix (Beispiel fuer KMU):

4. Diagnose & Loesung Stufenweise vorgehen: First Level (Standardloesungen, Neustart, Neuanmeldung), Second Level (tiefer Einblick, Remote-Session), Third Level (Hersteller, Entwickler). Sieh dazu auch Troubleshooting-Methodik.

5. Abschluss Immer mit dem User bestaetigen, dass das Problem geloest ist. Dann Ticket schliessen und Loesung dokumentieren.

Praxisbeispiel: Outlook startet nicht

Ticket #1042 – Prio P3
User: Anna M., Buchhaltung
Problem: Outlook oeffnet sich nicht mehr, haengt beim Ladebildschirm.
Geraet: WKST-BUH-03, Windows 11, Office 365

Loesung:
1. Outlook Safe Mode getestet: outlook.exe /safe → startete
2. Add-In deaktiviert (Acrobat PDF Maker)
3. Outlook normal gestartet → funktioniert
4. Loesungsschritt dokumentiert fuer Wissensdatenbank
Dauer: 20 Minuten

Major Incident Management – wenn ein P1 nicht reicht

Nicht jeder P1-Incident ist automatisch ein Major Incident. Ein Major Incident liegt vor, wenn die Auswirkung so gross ist (z.B. komplett ausgefallenes ERP fuer die ganze Firma, Ransomware-Verdacht, Ausfall eines geschaeftskritischen Kern-Dienstes), dass der normale Incident-Prozess nicht mehr ausreicht: Es braucht einen eigenen Kommunikationsstrang, klare Rollen (Major Incident Manager, technische Leads, Kommunikationsverantwortliche) und oft eine laufende “Bridge” (Telefon- oder Teams-Call), in der alle Beteiligten in Echtzeit zusammenarbeiten.

Die wichtigsten Unterschiede zum Standard-Incident: separate Eskalationskette, regelmaessige Status-Updates an Management und Endanwender (statt nur ein Ticket-Kommentar), und ein verpflichtendes Post Implementation Review nach der Behebung. Details zu Rollen, Kommunikationskaskaden und einer Schritt-fuer-Schritt-Checkliste findest du im eigenen Artikel Major Incident Management.

Problem Management – Ursachen dauerhaft beseitigen

Was ist ein Problem?

Ein Problem ist die (noch) unbekannte Ursache fuer einen oder mehrere Incidents. Wenn derselbe Fehler immer wieder auftaucht oder viele User gleichzeitig betrifft, liegt meistens ein Problem dahinter.

Merke: Incidents loeschst du Feuer fuer Feuer. Problem Management loescht die Ursache, damit kein Feuer mehr entsteht.

Proaktiv vs. Reaktiv

Root Cause Analysis (RCA)

Wenn du ein Problem identifiziert hast, gehst du strukturiert auf Ursachensuche. Bewaehrte Techniken:

5-Why-Methode:

Problem: Fileserver nicht erreichbar
→ Warum? Netzwerkdienst ausgefallen
→ Warum? Windows Update hat Netzwerktreiber ersetzt
→ Warum? Update-Ring schliesst Treiber-Updates ein
→ Warum? Keine Ausnahme fuer produktive Server konfiguriert
→ Warum? Update-Richtlinie war nie definiert
Root Cause: Fehlende Update-Richtlinie fuer Server

Fischgraeten-Diagramm (Ishikawa): Kategorisiert moegliche Ursachen nach Mensch, Methode, Maschine, Material, Umgebung.

Fuer groessere oder wiederkehrende Probleme lohnt sich eine vertiefte Analyse mit Pareto-Auswertungen und Fault-Tree-Diagrammen – siehe Problem Management: Root-Cause-Analyse vertieft.

Known Error und Workaround

Sobald du die Ursache kennst, aber noch keinen permanenten Fix hast, wird das Problem zum Known Error. Dokumentiere dann:

• Die bekannte Ursache
• Einen Workaround (temporaere Umgehungsloesung)
• Den geplanten Fix und den Zeithorizont

Known Error #KE-042
Problem: Outlook haengt bei Start wenn Acrobat Add-In aktiv
Ursache: Inkompatibilitaet Adobe Acrobat 2024.003 mit Office Build 16.0.17531
Workaround: Add-In deaktivieren (Datei > Optionen > Add-Ins)
Geplanter Fix: Adobe-Patch erwartet KW 27
Status: Offen

Change Management – Aenderungen kontrolliert durchfuehren

Was ist ein Change?

Ein Change ist jede geplante Aenderung an IT-Systemen, -Diensten oder -Infrastruktur. Updates, neue Software, Firewall-Regelaenderungen, Server-Migrationen – alles laeuft idealerweise als Change.

Das Ziel ist nicht, Aenderungen zu verhindern, sondern sie kontrolliert und nachvollziehbar durchzufuehren, um Risiken zu minimieren.

In ITIL 4 heisst dieser Prozess offiziell Change Enablement – der Begriff unterstreicht, dass Aenderungen ermoeglicht werden sollen, nicht blockiert.

Die drei Change-Typen

Change-Lifecycle

Antrag (RFC) → Bewertung → Genehmigung → Planung → Implementierung → Review → Abschluss

Request for Change (RFC): Formeller Antrag, der beschreibt was geaendert wird, warum, mit welchem Risiko und welchem Rollback-Plan.

Ein einfaches Change-Dokument fuer den KMU-Alltag

Change #CH-2026-045
Datum: 2026-06-28 (Samstag, 08:00–10:00 Uhr)
Beschreibung: Windows Server 2022 – Kumulatives Update KB5040437 einspielen
Betroffene Systeme: SRV-FILE-01, SRV-APP-01
Risiko: Mittel (Neustart erforderlich, Downtime ca. 15 Min. pro Server)
Rollback-Plan: Update deinstallieren via Windows Update History, Restore aus Snapshot
Getestet auf: Testserver SRV-TEST-01 am 2026-06-24 – ok
Genehmigt: Geschaeftsfuehrung informiert, IT-Leiter genehmigt
Ergebnis: Erfolgreich. Beide Server wieder online 09:48 Uhr.

Change Advisory Board (CAB)

Im Enterprise-Bereich gibt es das CAB: ein Gremium aus IT, Fachbereichen und manchmal Geschaeftsleitung, das Normal Changes prueft und freigibt. Im KMU ist das oft eine E-Mail an den Vorgesetzten oder ein kurzes Standup-Meeting.

Nach dem Change: Post Implementation Review und Blameless Postmortem

Ein Change ist nicht abgeschlossen, sobald er technisch durchgefuehrt wurde. Bei Normal Changes mit hoeherem Risiko und immer bei Emergency Changes gehoert ein Post Implementation Review (PIR) dazu: eine kurze, strukturierte Nachbetrachtung, die klaert, ob der Change sein Ziel erreicht hat, ob unerwartete Nebenwirkungen aufgetreten sind und was beim naechsten Mal besser laufen sollte.

Post Implementation Review – Change #CH-2026-045
Ziel erreicht? Ja – Update erfolgreich, keine Fehlfunktion seit 5 Tagen
Abweichungen vom Plan? Downtime 18 statt 15 Minuten (SRV-APP-01
                        brauchte einen zusaetzlichen Neustart)
Unerwartete Nebenwirkungen? Keine
Lessons Learned: Zeitfenster fuer aehnliche Changes kuenftig auf
                 20 Minuten pro Server ansetzen
Folgeaktionen: Keine

Ist ein Change fehlgeschlagen oder hat er einen Major Incident ausgeloest, greift statt eines einfachen PIR oft ein Blameless Postmortem – ein Konzept, das vor allem aus dem Site-Reliability-Engineering-Umfeld (z.B. Google SRE) stammt. Die Grundidee: Der Fokus liegt konsequent auf dem System und den Prozessen, nicht auf der Person, die den Fehler “verursacht” hat. Wer Angst haben muss, fuer einen Fehler an den Pranger gestellt zu werden, meldet Probleme spaeter oder gar nicht mehr – und genau das will man verhindern.

Ein Blameless Postmortem beantwortet typischerweise:

• Was ist passiert (Zeitstrahl, moeglichst faktisch)?
• Welche Ursachen (nicht: welche Person) haben dazu gefuehrt?
• Was hat gut funktioniert (Monitoring hat frueh alarmiert, Rollback griff)?
• Welche konkreten, messbaren Massnahmen verhindern eine Wiederholung?

Service Request Management – die vierte Practice im Alltag

Nicht jede Anfrage im Ticketsystem ist ein Incident. Wenn eine neue Mitarbeiterin einen Laptop braucht, jemand Zugriff auf ein Netzlaufwerk anfordert oder ein Passwort zurueckgesetzt werden soll, ist nichts kaputt – es handelt sich um eine Standardanfrage. Genau dafuer gibt es in ITIL 4 die eigenstaendige Practice Service Request Management (in ITIL v3 noch Teil von “Request Fulfilment”).

Abgrenzung zu Incident Management

Typische Service Requests im KMU

• Benutzerkonto anlegen / deaktivieren (siehe auch IT-Onboarding & Offboarding)
• Zugriff auf Freigabe oder Verteilerliste beantragen
• Neue Hardware bestellen (Laptop, Monitor, Headset)
• Softwarelizenz oder Software-Installation anfordern
• Passwort zuruecksetzen, MFA-Geraet neu registrieren

Self-Service-Katalog statt E-Mail-Wildwuchs

Der Reifegrad zeigt sich daran, ob Service Requests ueber einen Servicekatalog mit klar definiertem Ablauf laufen oder wild per E-Mail eintrudeln. Ein einfacher Katalogeintrag in einem Tool wie Freshservice oder JIRA Service Management sieht strukturell etwa so aus:

service_request: "Neuer Laptop"
kategorie: Hardware
formularfelder:
  - Mitarbeitername
  - Abteilung
  - Geraetetyp (Standard / Power-User)
  - Kostenstelle
genehmigung:
  schritt_1: Vorgesetzter (Budget)
  schritt_2: IT-Leiter (Standardkonform?)
sla_erfuellung: 5 Werktage
automatisierung:
  - Bestellung wird bei Genehmigung automatisch an Lieferant gesendet
  - Ticket fuer Ersteinrichtung wird automatisch an IT-Team zugewiesen

Ticketsystem – das Herzstuck im Alltag

Ohne Ticketsystem ist ITIL Theorie. Jedes Incident, jedes Problem, jeder Change und jede Service Request gehoert in ein Ticket. Einen praxisnahen Vergleich von Tools und Aufbau eines Ticketsystems findest du in Ticketsystem-Grundlagen.

Gaengige Ticketsysteme fuer KMU

SLA, OLA und UC – wer verspricht wem was

Diese drei Begriffe werden gerne durcheinandergeworfen, meinen aber unterschiedliche Vertragsbeziehungen:

Der Zusammenhang: Damit die IT-Abteilung ein SLA gegenueber dem Kunden einhalten kann, braucht sie intern passende OLAs mit den eigenen Teams und UCs mit externen Lieferanten. Ein SLA von “Mailserver in 2 Stunden wiederhergestellt” ist nur haltbar, wenn das Hosting-UC eine Reaktionszeit von deutlich unter 2 Stunden zusichert und das interne Server-Team per OLA ebenso schnell reagiert.

Kunde  <—— SLA (2h Loesungszeit) ——  IT-Abteilung
                                          |
                            OLA (30 Min.) |  UC (1h Reaktionszeit)
                                          |
                            Server-Team        Hosting-Provider

Ein typisches internes SLA fuer den KMU-Alltag:

Internes SLA – IT Support KMU Beispiel AG

P1 (Kritisch):
  Reaktionszeit:   15 Minuten
  Loesungszeit:    2 Stunden
  Eskalation nach: 1 Stunde an IT-Leiter

P2 (Hoch):
  Reaktionszeit:   1 Stunde (Buerozeiten)
  Loesungszeit:    4 Stunden

P3 (Mittel):
  Reaktionszeit:   4 Stunden (Buerozeiten)
  Loesungszeit:    1 Werktag

P4 (Niedrig / Service Request):
  Reaktionszeit:   1 Werktag
  Loesungszeit:    5 Werktage

Kennzahlen (KPIs) fuers ITSM

Ohne Zahlen weisst du nicht, ob deine Prozesse tatsaechlich besser werden. Die folgenden vier Kennzahlen gehoeren zum Standardrepertoire jedes Service Desks.

MTTR – Mean Time To Repair / Resolve

Die durchschnittliche Zeit von der Meldung eines Incidents bis zur Wiederherstellung des Dienstes.

MTTR = Summe aller Loesungszeiten / Anzahl geloester Incidents

Beispiel: 20 Incidents im Monat mit insgesamt 40 Stunden Loesungszeit ergibt eine MTTR von 2 Stunden.

MTBF – Mean Time Between Failures

Die durchschnittliche Zeit zwischen zwei Ausfaellen desselben Systems – ein Mass fuer die Stabilitaet, nicht fuer die Reaktionsgeschwindigkeit.

MTBF = Gesamte Betriebszeit / Anzahl Ausfaelle

Beispiel: Ein Server laeuft 720 Stunden im Monat und faellt dabei zweimal aus, ergibt eine MTBF von 360 Stunden. Zusammen mit der MTTR ergibt sich die Verfuegbarkeit: Verfuegbarkeit = MTBF / (MTBF + MTTR).

First Call Resolution (FCR)

Der Anteil der Tickets, die beim ersten Kontakt geloest werden, ohne Rueckruf, Eskalation oder zweiten Termin.

FCR (%) = (Beim Erstkontakt geloeste Tickets / Gesamtzahl Tickets) × 100

Eine hohe FCR-Quote (Richtwert 70–80% im First Level) senkt die Kosten pro Ticket massiv, weil kein zweiter Bearbeitungsdurchlauf noetig ist.

Change Success Rate

Der Anteil der Changes, die ohne Zwischenfaelle, Rollback oder Folge-Incident abgeschlossen wurden.

Change Success Rate (%) = (Erfolgreiche Changes / Gesamtzahl Changes) × 100

Ein niedriger Wert (deutlich unter 90%) deutet meist auf zu knappe Tests, fehlende Rollback-Plaene oder eine zu oberflaechliche CAB-Pruefung hin.

Richtwerte im Ueberblick

Ein einfaches PowerShell-Beispiel, um die MTTR aus CSV-Ticketexporten zu berechnen:

# Ticketexport mit Spalten "Erstellt" und "Geloest" (Datum/Zeit)
$tickets = Import-Csv .\tickets_juni.csv

$dauerListe = $tickets | ForEach-Object {
    $erstellt = [datetime]$_.Erstellt
    $geloest  = [datetime]$_.Geloest
    ($geloest - $erstellt).TotalHours
}

$mttr = ($dauerListe | Measure-Object -Average).Average
Write-Host "MTTR Juni: $([math]::Round($mttr, 2)) Stunden"

ITIL und Wissensdatenbank

Ein unterschaetzter Aspekt: Die Wissensdatenbank (Knowledge Base). Jede Loesung eines Incidents, jeder Workaround fuer einen Known Error – das ist Wissen, das festgehalten werden sollte. Beim naechsten gleichen Fall loest du das Ticket in 5 Minuten statt 45.

Praktisch umsetzbar mit:

• Einem Wiki wie diesem (guide.sweber.dev)
• Notizen im Ticketsystem selbst (Loesungsfeld ausfuellen!)
• Confluence, Notion, Obsidian oder einfach einem strukturierten Ordner auf dem Fileserver

Sieh dazu auch IT-Dokumentation & Inventar.

Zusammenspiel der Practices

Incident: "Outlook startet bei 3 Usern nicht"
         ↓
Loesung: Workaround → Add-In deaktiviert → Incident geschlossen
         ↓
Muster erkannt: Gleiches Problem nach jedem Update
         ↓
Problem: Root Cause Analysis → Acrobat Add-In inkompatibel
Known Error dokumentiert, Workaround kommuniziert
         ↓
Change: Permanent Fix → Update Adobe Acrobat auf neue Version
RFC erstellt, getestet, genehmigt, deployed
Change abgeschlossen, PIR durchgefuehrt → Problem geschlossen

Das ist der Kreislauf, wie du aus Feuerloeschen zu nachhaltiger IT-Qualitaet kommst. Waechst die Auswirkung eines Incidents waehrenddessen ueber ein normales Mass hinaus, wechselst du in den Major-Incident-Modus mit eigener Kommunikation und Nachbearbeitung. Und nicht jede Anfrage im Ticketsystem durchlaeuft diesen Kreislauf ueberhaupt – viele sind einfache Service Requests mit vordefiniertem Ablauf.

Verwandte Themen

• Major Incident Management – Rollen, Kommunikation und Ablauf bei kritischen Grossstoerungen
• Change Management (ITIL) vertieft – Risikoeinstufung, CAB-Prozesse und Eskalationspfade im Detail
• Problem Management: Root-Cause-Analyse vertieft – Pareto, Fault-Tree-Analyse und weitere RCA-Techniken
• Ticketsystem-Grundlagen – Aufbau, Tools und Kategorisierung im Vergleich
• Troubleshooting-Methodik – Strukturiert vorgehen bei Stoerungen
• IT-Onboarding & Offboarding – Prozesse fuer neue und austretende Mitarbeitende
• IT-Dokumentation & Inventar – Wissensdatenbank und Asset-Verwaltung
• Monitoring-Grundlagen – Proaktiv Probleme erkennen bevor Incidents entstehen

Weiterlernen

• ITIL 4 Offizielle Seite – Axelos – Offizielle Zertifizierungsinfos und Grundlagen
• IT Process Wiki – Incident Management (deutsch) – Detaillierte Prozessbeschreibungen auf Deutsch
• IT Process Wiki – Problem Management (deutsch) – Rollen, Konzepte, Aktivitaetsdiagramme
• mITSM – Change Management ITIL (deutsch) – Praxisorientierte Erklaerung des Change-Prozesses
• Topdesk Blog – Incident-Prioritaetenmatrix (deutsch) – Wie du eine Prioritaetenmatrix aufsetzt
• Atlassian – ITSM Problem Management Guide (englisch) – Moderne Sichtweise auf Problem Management mit Praxisbeispielen
• ITSM.tools – ITIL 4 Service Value System erklaert (englisch) – SVS, Guiding Principles und Value Chain im Detail
• Google SRE Book – Postmortem Culture (englisch) – Ursprung und Praxis des Blameless-Postmortem-Ansatzes