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 sind die drei Saeulenprozesse, mit denen du als IT-Allrounder tagtaeglich arbeitest.

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

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.

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.

Ticketsystem – das Herzstuck im Alltag

Ohne Ticketsystem ist ITIL Theorie. Jedes Incident, jedes Problem, jeder Change gehoert in ein Ticket.

Gaengige Ticketsysteme fuer KMU

SLA – Service Level Agreement

Ein SLA ist die vertragliche (oder interne) Vereinbarung ueber Reaktions- und Loesungszeiten. Typisches Beispiel:

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

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 drei Prozesse

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 → Problem geschlossen

Das ist der Kreislauf, wie du aus Feuerloeschen zu nachhaltiger IT-Qualitaet kommst.

Verwandte Themen

• 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