Problem-Management: Von der Stoerung zur nachhaltigen Ursachenbehebung

Warum “Ticket schliessen” nicht reicht

Stell dir folgendes Muster vor: Jeden Montagmorgen zwischen 08:00 und 08:15 Uhr melden drei bis vier Mitarbeitende, dass sie sich nicht am Terminalserver anmelden koennen. Der Support-Mitarbeiter startet den Citrix-Dienst neu, alle koennen wieder arbeiten, Ticket auf “geloest” gesetzt. Das passiert seit acht Wochen. Aus Sicht des Incident-Managements ist das ein Erfolg: Wiederherstellungszeit unter 15 Minuten, SLA eingehalten. Aus Sicht des Problem-Managements ist es ein Totalversagen, weil niemand fragt, warum das jeden Montag passiert.

Genau das ist die Kernidee, die ITIL 4 mit der Trennung von Incident-Management und Problem-Management transportiert: Incident-Management kaempft gegen Symptome, Problem-Management gegen Ursachen. Wer nur Symptome behandelt, produziert einen wachsenden Berg an wiederkehrenden Stoerungen, steigende Ticketzahlen und irgendwann eine IT-Abteilung, die nur noch Feuer loescht statt Infrastruktur zu verbessern. In einem Schweizer KMU mit knappen IT-Ressourcen ist das besonders teuer: Jede Stunde, die in wiederkehrende Bagatell-Stoerungen fliesst, fehlt fuer Projekte, Patching oder Security-Haertung.

Dieser Artikel zeigt dir, wie du Problem-Management so aufsetzt, dass es nicht zur Alibi-Uebung wird, sondern echte Wirkung entfaltet: von der sauberen Abgrenzung zum Incident-Management ueber strukturierte Root-Cause-Analyse bis zur Known-Error-Datenbank und der Trend-Analyse aus deinen eigenen Ticketdaten.

Incident- vs. Problem-Management: die Abgrenzung, die oft schiefgeht

Der haeufigste Fehler in kleineren IT-Teams: Incident- und Problem-Management werden von denselben Personen im selben Ticket-Flow erledigt, ohne begriffliche Trennung. Das fuehrt dazu, dass Ursachenanalyse nie priorisiert wird, weil der naechste Incident schon in der Warteschlange wartet.

Ein Incident kann geschlossen werden, ohne dass die Ursache bekannt ist (“Server neu gestartet, Fehler weg”). Ein Problem bleibt dagegen offen, bis entweder die Ursache behoben ist oder ein dauerhafter Workaround dokumentiert und akzeptiert wurde. Diese Trennung ist keine Buerokratie um der Buerokratie willen: Sie stellt sicher, dass jemand explizit die Verantwortung traegt, tiefer zu graben, auch wenn der akute Druck weg ist, sobald der Dienst wieder laeuft.

Der Problem-Management-Lebenszyklus

ITIL 4 beschreibt den Prozess grob in folgenden Phasen, die sich in der Praxis meist so abbilden lassen:

1. Problemidentifikation – ausgeloest durch wiederkehrende Incidents, durch proaktive Trendanalyse, durch Lieferanten-Hinweise (z. B. Herstellerbulletin zu einem bekannten Bug) oder durch Monitoring-Alarme.
2. Problem-Logging – Erfassung als eigener Datensatz, verknuepft mit allen zugehoerigen Incidents (nicht als Kommentar in einem Incident-Ticket versteckt).
3. Kategorisierung und Priorisierung – nach Impact (wie viele Nutzer/Prozesse betroffen) und Dringlichkeit (Frequenz, Trend steigend/fallend).
4. Root-Cause-Analyse – strukturierte Ursachenermittlung, siehe naechster Abschnitt.
5. Known-Error-Erfassung – sobald Ursache und Workaround bekannt sind, Eintrag in die KEDB.
6. Loesungsplanung – Change-Request fuer die dauerhafte Behebung, ueber den regulaeren Change-Management-Prozess.
7. Problem-Abschluss und Review – nach erfolgreicher Umsetzung des Fixes und Bestaetigung, dass die Incidents ausbleiben.

Wichtig: Schritt 5 und 6 muessen nicht in dieser Reihenfolge starr ablaufen. Oft existiert ein Known Error mit Workaround monatelang, bevor der Change fuer den echten Fix budgetiert und umgesetzt wird — das ist legitim, solange der Workaround dokumentiert und fuer den Service Desk auffindbar ist.

Root-Cause-Analyse: 5-Why in der Praxis

Die 5-Why-Methode (entwickelt bei Toyota) ist simpel, aber wirkungsvoll, wenn man zwei Fallstricke vermeidet: oberflaechliches Abbrechen nach der ersten Antwort und das Verwechseln von Symptom-Ketten mit echten Ursachenketten.

Beispiel aus dem Alltag eines Schweizer KMU mit lokalem Fileserver:

1. Warum konnten Mitarbeitende am Montag nicht auf die Freigabe \\fs01\projekte zugreifen? → Weil der Freigabedienst (Server-Dienst) auf FS01 nicht reagierte.
2. Warum reagierte der Dienst nicht? → Weil der Server unter hoher Speicherauslastung stand und ins Swapping geriet.
3. Warum war der Speicher ausgelastet? → Weil der Antiviren-Scan jeden Montag um 08:00 Uhr vollstaendig startet und parallel mit dem Backup-Job laeuft.
4. Warum ueberschneiden sich beide Jobs? → Weil die Backup-Software nach dem letzten Update ihren Standard-Zeitplan zurueckgesetzt hat, ohne dass jemand es bemerkte.
5. Warum wurde das nicht bemerkt? → Weil es keinen Change-Review-Schritt gibt, der Zeitplaene nach Updates automatisiert gegenprueft.

Root Cause ist hier nicht “Server war ueberlastet” (Symptom), sondern das fehlende Post-Update-Verification-Verfahren. Der dauerhafte Fix ist entsprechend nicht “mehr RAM einbauen” (behandelt nur das Symptom), sondern ein Zeitplan-Redesign plus ein Checklisten-Schritt im Change-Prozess.

5-Why funktioniert gut bei linearen, klar nachvollziehbaren Ursachenketten mit einer Hauptursache. Bei komplexeren Stoerungen mit mehreren moeglichen Einflussfaktoren (z. B. “Intermittierende Netzwerkausfaelle im gesamten Buero”) stoesst die Methode an Grenzen, weil sie keine Verzweigungen abbildet. Dort hilft das Ishikawa-Diagramm.

Root-Cause-Analyse: Ishikawa/Fishbone-Diagramm

Das Ishikawa-Diagramm (auch Fishbone- oder Ursache-Wirkungs-Diagramm genannt, entwickelt von Kaoru Ishikawa) visualisiert moegliche Ursachen entlang mehrerer Kategorien, die sich wie Gräten an einem Fischskelett zur Hauptlinie (dem Problem) hin ausrichten. In der IT hat sich eine Anpassung der klassischen 6M-Kategorien bewaehrt:

• Mensch (Fehlbedienung, fehlende Schulung, Fluktuation)
• Methode/Prozess (fehlender Change-Review, keine Eskalationsregel)
• Maschine/Hardware (Alterung, Kapazitaetsgrenzen, Firmware-Bugs)
• Material/Software (fehlerhafte Patches, inkompatible Treiberversionen)
• Umgebung (Stromausfall, Klimaanlage, Netzwerktopologie)
• Messung/Monitoring (fehlende Metriken, falsch konfigurierte Schwellwerte)

Praktisches Vorgehen im Team-Workshop (30-60 Minuten):

1. Problem klar und neutral formulieren (nicht “Server XY ist kaputt”, sondern “Wiederkehrende Verbindungsabbrueche zu Terminalserver TS02, montags 08:00-08:15 Uhr”).
2. Die sechs Kategorien als Aeste an eine horizontale Linie zeichnen (Whiteboard, Miro, oder einfach Flipchart).
3. Brainstorming pro Kategorie: Alle moeglichen Ursachen sammeln, ohne sofort zu bewerten.
4. Fuer jede genannte Ursache mit 5-Why nachhaken, bis eine plausible Wurzel erreicht ist.
5. Ursachen priorisieren (z. B. per Punktabfrage im Team) und die wahrscheinlichsten zuerst mit Daten (Logs, Monitoring, Performance-Counter) verifizieren.

Known-Error-Datenbank (KEDB) aufbauen

Ein Known Error ist laut ITIL ein Problem mit dokumentierter Root Cause und einem Workaround. Die KEDB ist der zentrale, durchsuchbare Speicher fuer diese Eintraege und wird sowohl von Incident- als auch von Problem-Management genutzt.

Minimale Struktur eines KEDB-Eintrags, die sich in praktisch jedem Ticketsystem (Jira Service Management, OTRS, Zammad, ServiceNow) als Feldset abbilden laesst:

So ein Eintrag laesst sich in vielen Ticketsystemen per API pflegen. Ein einfaches Beispiel fuer eine Abfrage gegen eine KEDB, die als SQL-Tabelle in einer selbstgebauten Loesung liegt (etwa als Ergaenzung zu einem einfachen Ticketsystem):

CREATE TABLE dbo.KnownErrors (
    KeId            INT IDENTITY(1,1) PRIMARY KEY,
    Titel           NVARCHAR(200) NOT NULL,
    BetroffeneCIs   NVARCHAR(400),
    RootCause       NVARCHAR(MAX),
    Workaround      NVARCHAR(MAX),
    Status          VARCHAR(20) NOT NULL DEFAULT 'offen',
    ChangeTicket    VARCHAR(30),
    ErstelltAm      DATETIME2 DEFAULT SYSDATETIME(),
    LetzterReview   DATETIME2
);

-- Known Errors finden, die seit 90 Tagen keinen Review hatten
SELECT KeId, Titel, Status, LetzterReview
FROM dbo.KnownErrors
WHERE Status <> 'behoben'
  AND (LetzterReview IS NULL OR LetzterReview < DATEADD(DAY, -90, SYSDATETIME()))
ORDER BY LetzterReview ASC;

Fuer die meisten KMU reicht anfangs auch eine sauber gepflegte Liste im Ticketsystem selbst (z. B. als eigener Issue-Typ “Known Error” mit Verlinkung zu Incidents) – die Tabelle oben zeigt lediglich das Datenmodell, falls du eine eigene Reporting-Schicht brauchst.

Workaround-Dokumentation: der unterschaetzte Baustein

Ein Workaround ist eine Loesung, die die Auswirkung eines Incidents oder Problems reduziert oder eliminiert, ohne die Root Cause zu beseitigen. Viele Teams dokumentieren Workarounds schlecht, weil sie als “provisorisch” gelten – dabei koennen sie Monate oder Jahre im Einsatz bleiben.

Gute Workaround-Dokumentation beantwortet immer:

• Wann anwenden? Klare Symptome/Trigger, die eindeutig erkennbar sind.
• Wie genau ausfuehren? Schritt-fuer-Schritt, so dass auch ein Junior-Supporter oder der Bereitschaftsdienst um 2 Uhr nachts es ohne Rueckfrage umsetzen kann.
• Welche Risiken/Nebenwirkungen? Z. B. “Dienst-Neustart trennt aktive Sitzungen, informiere Nutzer vorher wenn moeglich.”
• Wie lange gueltig? Verweis auf den Known-Error-Eintrag und den geplanten dauerhaften Fix.

Beispiel fuer einen dokumentierten Workaround als PowerShell-Snippet, das der Service Desk direkt ausfuehren kann, inklusive Protokollierung fuer die spaetere Trend-Analyse:

# Workaround zu KE-2026-014: TermService haengt nach Backup/AV-Ueberschneidung
# Ausfuehren auf TS02 mit lokalem Admin-Konto

$logPath = "\\fs01\it-logs\workaround-KE-2026-014.csv"
$eintrag = [PSCustomObject]@{
    Zeitstempel = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
    Ausgefuehrt = $env:USERNAME
    Server      = $env:COMPUTERNAME
}

Restart-Service -Name TermService -Force -ErrorAction Stop
$eintrag | Export-Csv -Path $logPath -Append -NoTypeInformation -Encoding UTF8

Write-Host "Workaround ausgefuehrt und protokolliert: $($eintrag.Zeitstempel)"

Diese Protokollierung ist gleichzeitig die Datengrundlage fuer den naechsten Schritt: den Nachweis, ob das Problem wirklich haeufiger wird, seltener wird, oder ob der spaetere Fix tatsaechlich gewirkt hat.

Proaktives vs. reaktives Problem-Management

Reaktives Problem-Management reagiert auf bereits eingetretene Incidents und untersucht deren Symptome, um die Ursache freizulegen – getrieben durch offene Incidents und die Vermeidung von Wiederholung. Proaktives Problem-Management dagegen ist eine kontinuierliche Taetigkeit, die versucht, Schwachstellen zu erkennen, bevor daraus Incidents entstehen, indem Incident-Datensaetze, Betriebslogs und andere Datenquellen auf Muster und Trends untersucht werden.

In der Praxis vieler KMU existiert nur reaktives Problem-Management, weil schlicht die Zeit fuer proaktive Analyse fehlt. Das ist verstaendlich, aber teuer: Ein einziger proaktiv verhinderter Major Incident (siehe dazu Major-Incident-Management) spart oft mehr Aufwand als Monate an reaktiver Feuerwehr.

Trend-Analyse aus Ticket-Daten

Die meisten Ticketsysteme (egal ob Jira Service Management, OTRS, Zammad oder eine Eigenentwicklung) erlauben Exporte oder direkte Abfragen. Wichtige Kennzahlen fuer die Trend-Analyse:

• Ticketvolumen pro Kategorie ueber Zeit – steigt eine Kategorie (z. B. “Drucker”, “VPN-Verbindung”) kontinuierlich an?
• Wiederholrate pro Configuration Item – welcher Server, welche Anwendung, welches Geraet verursacht ueberproportional viele Tickets?
• Zeitliche Muster – haeufen sich Stoerungen zu bestimmten Uhrzeiten, Wochentagen oder nach bestimmten Events (Patch-Dienstag, Monatsabschluss im ERP)?
• Mean Time Between Failures (MTBF) pro Known Error – wird der Abstand zwischen Wiederholungen kuerzer (Verschlechterung) oder laenger (Workaround wirkt)?

Beispiel fuer eine Abfrage, wenn deine Ticketdaten in einer SQL-Datenbank liegen (z. B. Reporting-Export aus dem Ticketsystem):

-- Top-Ursachen fuer wiederkehrende Incidents der letzten 90 Tage
SELECT
    ConfigurationItem,
    KategorieName,
    COUNT(*) AS AnzahlTickets,
    MIN(ErstelltAm) AS ErsteMeldung,
    MAX(ErstelltAm) AS LetzteMeldung,
    DATEDIFF(DAY, MIN(ErstelltAm), MAX(ErstelltAm)) AS ZeitraumTage
FROM dbo.Tickets
WHERE ErstelltAm >= DATEADD(DAY, -90, SYSDATETIME())
  AND TicketTyp = 'Incident'
GROUP BY ConfigurationItem, KategorieName
HAVING COUNT(*) >= 3
ORDER BY AnzahlTickets DESC;

Wenn du statt SQL nur Zugriff auf CSV-Exporte hast, reicht auch ein PowerShell-Einzeiler fuer eine schnelle Uebersicht:

Import-Csv -Path .\tickets_export.csv |
    Where-Object { [datetime]$_.ErstelltAm -ge (Get-Date).AddDays(-90) } |
    Group-Object ConfigurationItem |
    Sort-Object Count -Descending |
    Select-Object -First 10 Name, Count |
    Format-Table -AutoSize

Fuer Teams mit Zugriff auf Log-Analytics (z. B. Microsoft Sentinel oder Azure Monitor bei M365-lastigen Umgebungen) laesst sich eine aehnliche Analyse auch gegen Sign-in- oder Service-Health-Logs fahren, um Korrelationen zwischen Cloud-Ereignissen und internen Tickets zu erkennen:

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType != 0
| summarize FehlerAnzahl = count() by bin(TimeGenerated, 1h), AppDisplayName
| where FehlerAnzahl > 20
| order by TimeGenerated desc

Entscheidungsbaum: Ist das ein Fall fuer Problem-Management?

Um zu vermeiden, dass jeder Einzelfall im Problem-Management landet und der Prozess dadurch verwaesst, hilft folgender Ablauf:

1. Ist der Incident bereits mehrfach aufgetreten (>= 3x in 30 Tagen) oder wird ein signifikanter Impact erwartet? Nein → normales Incident-Handling, kein Problem-Ticket noetig. Ja → weiter zu 2.
2. Ist die Root Cause bereits bekannt und in der KEDB dokumentiert? Ja → Workaround aus KEDB anwenden, Incident mit Known Error verknuepfen, kein neues Problem-Ticket. Nein → weiter zu 3.
3. Reicht die Kapazitaet fuer eine strukturierte Root-Cause-Analyse (5-Why/Ishikawa) in dieser Woche? Nein → Problem-Ticket mit niedriger Prioritaet anlegen und einreihen, Workaround dokumentieren falls vorhanden. Ja → sofort Root-Cause-Analyse starten.
4. Wurde die Root Cause verifiziert (mit Logs/Daten, nicht nur Vermutung)? Nein → weiter analysieren, ggf. Ishikawa-Workshop ansetzen. Ja → Known-Error-Eintrag anlegen, Change fuer dauerhaften Fix planen.

Schnittstellen zu anderen Prozessen

Problem-Management funktioniert nicht isoliert. Die wichtigsten Schnittstellen:

• Change-Management: Der dauerhafte Fix eines Known Error läuft fast immer ueber einen regulaeren Change-Request, inklusive Risikoabschaetzung und ggf. CAB-Freigabe (siehe Change-Management vertieft).
• Major-Incident-Management: Ein Major Incident zieht praktisch immer ein nachgelagertes Problem-Ticket nach sich, oft mit einem Post-Incident-Review als Ausgangspunkt fuer die Root-Cause-Analyse (siehe Major-Incident-Management).
• Monitoring: Gute Monitoring-Daten (siehe Monitoring-Grundlagen) sind die wichtigste Datenquelle fuer proaktives Problem-Management.
• Dokumentation/Inventar: Ohne sauber gepflegtes Configuration-Item-Inventar (siehe IT-Dokumentation und Inventar) laesst sich weder Impact-Analyse noch Trend-Analyse pro Asset sinnvoll durchfuehren.
• Troubleshooting-Methodik: Die systematische Fehlersuche im Einzelfall (siehe Troubleshooting-Methodik) liefert oft die Rohdaten fuer die spaetere Root-Cause-Analyse im Problem-Management.

Fallstricke aus der Praxis

• Problem-Tickets, die nie geschlossen werden: Ohne Owner und Review-Rhythmus sammeln sich offene Probleme endlos an. Definiere ein maximales Alter (z. B. 90 Tage), nach dem ein Problem-Ticket im naechsten Review zwingend neu bewertet wird.
• Root Cause = “menschlicher Fehler”: Wie oben erwaehnt fast immer ein Zeichen fuer eine zu frueh abgebrochene Analyse.
• KEDB und Wiki sind getrennte Systeme: Wenn Workarounds im Wiki stehen, aber Known Errors im Ticketsystem, findet der Service Desk um 2 Uhr nachts nichts. Verlinke konsequent beide Richtungen.
• Kein Zusammenhang zwischen Trend-Analyse und Kapazitaetsplanung: Steigende Ticketzahlen zu einem System sind oft ein Fruehindikator fuer bevorstehende Kapazitaetsprobleme (Storage, RAM, Lizenzlimits) – nicht nur ein Qualitaetsproblem.
• Fehlende Verifikation nach dem Fix: Ein Change wird umgesetzt, das Problem-Ticket geschlossen, aber niemand prueft nach 30/60/90 Tagen, ob die urspruenglichen Incidents tatsaechlich ausbleiben.

Weiterlernen

• ITIL 4 Problem Management – IT Process Wiki – kompakte deutschsprachige Prozessuebersicht mit Rollen und Kennzahlen
• Atlassian: Problemmanagement in ITIL – praxisnaher Leitfaden mit Implementierungstipps
• Known Error – Wikipedia – Hintergrund und Definition des Known-Error-Konzepts
• Microsoft Learn: KQL-Abfragesprache Uebersicht – Referenz fuer Log-Analytics-Abfragen wie im Trend-Analyse-Beispiel oben
• Ursache-Wirkungs-Diagramm – Wikipedia – vertiefende Erklaerung des Ishikawa-Diagramms mit 6M-Kategorien

Videos

YouTube