Problem Management beginnt mit Mustern, nicht mit Ursachenworkshops

Eine Störung ist behoben, der Nutzer kann weiterarbeiten und das Ticket wird geschlossen. Zwei Wochen später tritt dasselbe Verhalten erneut auf. Wieder wird der Dienst schnell wiederhergestellt, wieder endet die Bearbeitung mit „gelöst“. Operativ ist das nachvollziehbar: Im Incident zählt die schnelle Rückkehr zum Normalbetrieb. Organisatorisch entsteht jedoch eine Lücke, wenn niemand entscheidet, ob die Wiederholung weiter untersucht werden muss.

Problem Management schließt diese Lücke. Es ist nicht die Pflicht, nach jeder Störung einen großen Ursachenworkshop zu veranstalten. Es ist die Fähigkeit, relevante Muster zu erkennen, bekannte Umgehungen verfügbar zu machen und bewusst zu entscheiden, welche Ursachen beseitigt, begrenzt oder vorerst akzeptiert werden.

Für kleine IT-Teams ist genau diese Auswahl entscheidend. Ohne sie wird Problem Management entweder zu Bürokratie oder findet gar nicht statt.

Incident und Problem verfolgen unterschiedliche Ziele

Ein Incident beschreibt eine ungeplante Beeinträchtigung einer Leistung. Sein unmittelbares Ziel ist, die vereinbarte Nutzung möglichst schnell wiederherzustellen. Dafür kann ein Neustart, ein Ausweichweg oder eine temporäre Konfiguration vollkommen richtig sein.

Ein Problem richtet den Blick auf die zugrunde liegende oder noch unbekannte Ursache eines oder mehrerer Incidents. Es fragt:

• Warum tritt die Störung auf oder warum könnte sie erneut auftreten?
• Wie lässt sich ihre Wirkung bis zu einer dauerhaften Lösung begrenzen?
• Welche Änderung wäre notwendig, um die Ursache zu beseitigen?
• Ist diese Änderung angesichts von Nutzen, Risiko und Aufwand sinnvoll?

Beide Arbeiten können parallel laufen und von denselben Personen erledigt werden. Sie sollten gedanklich trotzdem getrennt bleiben. Wer während eines kritischen Incidents eine vollständige Ursachenanalyse erzwingen will, verzögert möglicherweise die Wiederherstellung. Wer nach der Wiederherstellung nie wieder hinsieht, akzeptiert möglicherweise dauerhaft vermeidbare Ausfälle.

FitSM-2 Version 3.0.2 beschreibt Problem Management als leichtgewichtigen Prozess: Probleme werden unter anderem aus Incident-Mustern und Trends erkannt, klassifiziert und priorisiert. Wo eine dauerhafte Lösung noch nicht vorliegt, werden Known Errors und wirksame Workarounds gepflegt. Das ist auch für kleine Teams praktikabel, weil nicht jeder Incident automatisch ein neues Untersuchungsprojekt auslöst.

Wiederholung allein bestimmt noch nicht die Priorität

Ein Fehler, der häufig auftritt und jeweils in Sekunden folgenlos umgangen wird, kann weniger wichtig sein als ein einmaliger Incident mit hoher Wiederholungsgefahr und großer Servicewirkung. Die Auswahl sollte daher mehrere Signale verbinden:

Signal	Leitfrage
Wiederholung	Tritt ein vergleichbares Symptom bei demselben Service, CI oder Ablauf erneut auf?
Wirkung	Welche Nutzer, Geschäftsprozesse, Kosten oder Risiken sind betroffen?
Workaround-Aufwand	Wie viel Unterbrechung und manuelle Arbeit erzeugt jede Wiederherstellung?
Unsicherheit	Ist die Ursache unbekannt und könnte die Wirkung beim nächsten Mal größer sein?
Veränderung	Wird ein geplanter Change, ein Release oder Wachstum das Problem wahrscheinlicher machen?
Erkennbarkeit	Wird die Störung früh bemerkt oder kann sie lange unentdeckt bleiben?

Eine starre Regel wie „ab drei gleichen Tickets entsteht ein Problem“ ist einfach, aber blind für Wirkung und Erkennbarkeit. Besser ist eine regelmäßige kurze Sichtung: Welche Incident-Gruppen verursachten vermeidbare Wiederholungsarbeit, relevante Geschäftsunterbrechung oder erkennbares Zukunftsrisiko?

Erst das Muster beschreiben, dann die Ursache suchen

Teams springen häufig zu früh auf eine technische Erklärung. Drei Verbindungsabbrüche werden dann vorschnell zum „Netzwerkproblem“, obwohl Nutzer, Zeitfenster und betroffene Anwendungen noch nicht verglichen wurden. Eine gute Problemformulierung trennt Beobachtung und Hypothese.

Sie enthält zunächst:

• das wiederkehrende Symptom,
• den betroffenen Service,
• bekannte Zeiten, Nutzergruppen und Komponenten,
• Gemeinsamkeiten und Unterschiede der zugehörigen Incidents,
• die betriebliche Auswirkung,
• den derzeit wirksamen Workaround.

Erst danach folgen mögliche Ursachen. Jede Hypothese sollte durch eine Beobachtung bestätigt oder verworfen werden können. „Vermutlich Netzwerk“ ist keine prüfbare Hypothese. „Die Abbrüche treten nur nach dem Wechsel in das Gäste-WLAN auf; ein Vergleich im internen WLAN soll das bestätigen“ ist es.

Dieser Aufbau schützt vor zwei Fehlern: Das Team optimiert nicht vorschnell an der falschen Stelle, und eine plausible Vermutung wird nicht versehentlich als gesicherte Ursache in Tickets und Kommunikation übernommen.

Konstruiertes Beispiel: Der Neustart war zu erfolgreich

Das folgende Beispiel ist konstruiert.

Die Warteschlange für Versandetiketten bleibt unregelmäßig stehen. Der Service Desk startet einen Dienst neu, wartende Aufträge laufen weiter und das jeweilige Ticket wird geschlossen. Weil die Wiederherstellung nur wenige Minuten dauert, erscheint kein einzelner Incident besonders schwerwiegend.

In einer monatlichen Sichtung erkennt das Team, dass mehrere Tickets dasselbe Symptom und denselben Druckertreiber betreffen. Der Neustart ist ein verlässlicher Workaround, unterbricht aber jedes Mal den Versand und bindet einen Administrator. Als möglicher Auslöser fällt eine bestimmte Auftragsart auf.

Das Team eröffnet eine Problem-Karte. Es dokumentiert den Workaround für den Service Desk, prüft die Auftragsart als Hypothese und klärt mit dem Hersteller ein Treiberupdate. Die dauerhafte Änderung wird nicht während des nächsten Incidents improvisiert, sondern als eigener Change getestet und eingeplant.

Die Wirkung entsteht nicht allein durch eine gefundene „Root Cause“. Bereits die Wiederverwendung des Workarounds und die sichtbare Zuordnung ähnlicher Incidents reduzieren Unsicherheit und Bearbeitungszeit.

Eine Problem-Karte für den Mittelstand

Ein eigenes komplexes Modul im ITSM-Werkzeug ist nicht zwingend. Ein verknüpfter Tickettyp oder eine einfache Liste kann genügen, wenn folgende Angaben gepflegt werden:

Feld	Inhalt
Problemstatement	beobachtbares Muster ohne ungesicherte Ursachenbehauptung
betroffener Service	Leistung und wesentliche Nutzerwirkung
verknüpfte Incidents	belastbare Fälle, nicht nur lose Erinnerungen
Prioritätsgrund	Wirkung, Wiederholung, Aufwand und Veränderungsrisiko
Workaround	sichere Schritte, Grenzen und zuständige Rolle
Known Error	bestätigte Ursache oder ausreichend verstandener Fehlerzustand
Hypothesen und Nachweise	was wird wie geprüft und was wurde verworfen?
Handlungsoptionen	beheben, begrenzen, beobachten, ersetzen oder akzeptieren
Owner und nächster Termin	wer führt die Entscheidung weiter und wann?
Abschlusskriterium	woran ist Lösung oder bewusste Akzeptanz erkennbar?

Eine solche Karte darf offen bleiben. Schlecht ist nicht ein ungelöstes Problem, sondern ein Problem ohne aktuellen Workaround, verantwortliche Entscheidung oder nächsten Prüfpunkt.

Known Error ist kein Eingeständnis des Scheiterns

Nicht jede Ursache kann kurzfristig beseitigt werden. Vielleicht fehlt ein Hersteller-Patch, die betroffene Plattform wird ohnehin abgelöst oder die notwendige Änderung wäre riskanter als der kontrollierte Weiterbetrieb. Dann ist ein bekannter Fehler mit Workaround ein legitimes Ergebnis.

Der Eintrag muss für die Incident-Bearbeitung nutzbar sein:

• Welche Symptome passen zu diesem Fehler?
• Wie wird die Zuordnung bestätigt?
• Welche Schritte stellen den Service sicher wieder her?
• Welche Nebenwirkungen oder Grenzen besitzt der Workaround?
• Wann darf nicht weiter improvisiert, sondern muss eskaliert werden?
• Welche dauerhafte Entscheidung ist offen?

Eine „Known Error Database“ kann im kleinen Betrieb eine gefilterte Wissensliste sein. Entscheidend ist nicht die Bezeichnung, sondern dass der Service Desk sie bei einem passenden Incident findet. Der Beitrag „Ein Ticketsystem löst keine organisatorischen Probleme“ zeigt, warum ein Werkzeug ohne vereinbarten Arbeitsfluss keine Wirkung erzeugt.

Ursachenanalyse darf nicht zur Schuldfrage werden

Bei menschlichen Handlungen ist die Versuchung groß, den Abschluss mit „Bedienfehler“ oder „Administratorfehler“ zu beschleunigen. Damit bleibt häufig unklar, warum der Fehler möglich, plausibel oder unbemerkt war. Fehlende Schutzmechanismen, unklare Oberflächen, Zeitdruck und widersprüchliche Anweisungen gehören zur Systembetrachtung.

Google beschreibt in seiner Postmortem-Kultur eine lernorientierte Nachbereitung ohne persönliche Schuldzuweisung. Diese Perspektive bedeutet nicht, Verantwortung aufzulösen oder vorsätzliches Verhalten zu ignorieren. Sie verhindert, dass die Analyse bei der zuletzt handelnden Person endet, obwohl organisatorische und technische Bedingungen unverändert bleiben.

Ein aufwendiges Postmortem ist nicht für jedes Problem nötig. Für größere oder besonders lehrreiche Störungen sollte die Nachbereitung jedoch Entscheidungen, Annahmen, Beiträge zum Verlauf und konkrete Folgemaßnahmen nachvollziehbar festhalten.

Dauerhafte Lösung ist eine wirtschaftliche Entscheidung

Eine gefundene Ursache rechtfertigt noch nicht automatisch einen Change. Die Abhilfe kann hohe Kosten, eigene Risiken oder wenig Restnutzen besitzen. Deshalb gehören Problem Management und Change Management zusammen, sind aber nicht identisch.

Vor der dauerhaften Abhilfe sollten mindestens verglichen werden:

• erwartete weitere Incident-Wirkung ohne Änderung,
• laufender Aufwand des Workarounds,
• Kosten und Risiko der Änderung,
• Test- und Rückfallmöglichkeit,
• Restlebensdauer der betroffenen Plattform,
• Abhängigkeiten zu Roadmap und Lifecycle.

Diese Entscheidung kann lauten: jetzt beheben, beim nächsten Release mitnehmen, durch Überwachung begrenzen, bis zur Ablösung akzeptieren oder den Service grundlegend ändern. Der Problem-Owner bereitet sie vor; die fachlich und finanziell befugte Rolle entscheidet.

Erfolg misst sich nicht an geschlossenen Problemen

Viele geschlossene Problem-Tickets können auf gute Arbeit oder auf oberflächliche Abschlüsse hinweisen. Bessere Fragen sind:

• Treten die zugeordneten Incidents nach der Maßnahme weiterhin auf?
• Wird ein vorhandener Workaround schneller und sicherer angewendet?
• Sinkt die wiederkehrende Unterbrechung des betroffenen Services?
• Werden Problem-Changes wie geplant umgesetzt und überprüft?
• Bleiben offene Probleme ohne Owner oder nächsten Entscheid liegen?
• Welche neuen Muster werden durch Monitoring und Ticketdaten sichtbar?

ISO/IEC 20000-1:2018 stellt Service Management in einen Rahmen aus Planung, Erbringung, Bewertung und fortlaufender Verbesserung. Die Norm schreibt nicht die hier vorgeschlagene Problem-Karte vor. Sie unterstützt aber den Grundgedanken: Wiederkehrende Störungen sind nicht nur einzelne operative Fälle, sondern Eingangsdaten für die Verbesserung einer Leistung.

Der pragmatische Start ist eine halbe Stunde pro Monat. Gruppieren Sie die Incidents der wichtigsten Services nach wiederkehrenden Symptomen. Wählen Sie genau ein Muster mit relevanter Wirkung oder wiederkehrendem Aufwand. Dokumentieren Sie Workaround, Owner, nächste Hypothese und Entscheidungstermin. Wenn daraus ein verlässlicher Lern- und Entscheidungsfluss entsteht, besitzt das Team bereits funktionierendes Problem Management – auch ohne eigenes Gremium und großes Prozesshandbuch.