Ein typisches Bild aus dem Alltag: Der Drucker im Lager fällt jeden Montag aus. Die Anmeldung am Warenwirtschaftssystem hängt immer wieder, und jedes Mal hilft ein Neustart. Für den Service Desk ist das Routine, für die Mitarbeitenden ist es lästig. Genau hier setzt Problem Management an: Es fragt nicht nur, wie der Betrieb wieder läuft, sondern warum dieselbe Störung immer wieder auftritt.
Dieser Beitrag erklärt, was Problem Management nach ITIL 4 bedeutet, wie es sich vom Incident Management unterscheidet und wie Sie es auch mit einem kleinen IT-Team einführen.
Was ist Problem Management?
ITIL ist eine Sammlung von Empfehlungen für den Betrieb von IT-Diensten (IT-Service-Management). Die Begriffe in diesem Beitrag folgen der Fassung ITIL 4. Problem Management ist dort eine eigene Praxis, also ein abgegrenzter Aufgabenbereich mit eigenen Zielen.
Nach der Beschreibung des Zertifizierungsanbieters PeopleCert soll Problem Management die Wahrscheinlichkeit und die Auswirkungen von Störungen verringern. Dazu ermittelt es tatsächliche und mögliche Ursachen von Störungen und verwaltet Umgehungslösungen (Workarounds) und bekannte Fehler (Known Errors). Quelle: PeopleCert, ITIL 4 Practitioner: Problem Management.
Vereinfacht gesagt: Eine Störung (Incident) ist das, was jemand bemerkt, etwa „Das Postfach lädt nicht“. Das Problem ist die Ursache dahinter, etwa ein voller Datenträger auf dem Server. Eine Ursache kann viele Störungen auslösen. Deshalb lohnt es sich, sie einmal gründlich zu suchen, statt dieselbe Störung immer wieder neu zu bearbeiten.
Zwei Begriffe kommen dabei immer wieder vor:
- Umgehungslösung (Workaround): ein Weg, mit dem Anwenderinnen und Anwender weiterarbeiten können, obwohl die Ursache noch nicht beseitigt ist. Beispiel: ein Dienst wird neu gestartet.
- Bekannter Fehler (Known Error): eine erkannte und dokumentierte Ursache, für die die dauerhafte Lösung noch aussteht. Wir empfehlen, ihn zusammen mit der Umgehungslösung festzuhalten, damit der Service Desk bei der nächsten Meldung sofort weiß, was zu tun ist.
Abgrenzung zum Incident Management
Incident Management und Problem Management arbeiten eng zusammen, verfolgen aber verschiedene Ziele. Das Incident Management soll laut PeopleCert die negativen Auswirkungen von Störungen gering halten, indem es den normalen Betrieb so schnell wie möglich wiederherstellt. Quelle: PeopleCert, ITIL 4 Practitioner: Incident Management.
| Merkmal | Incident Management | Problem Management |
|---|---|---|
| Leitfrage | Wie läuft es wieder? | Warum ist es passiert, und wie verhindern wir die Wiederholung? |
| Ziel | normalen Betrieb schnell wiederherstellen | Wahrscheinlichkeit und Auswirkungen von Störungen verringern |
| Auslöser | eine gemeldete oder erkannte Störung | wiederkehrende Störungen, eine schwere Einzelstörung oder ein Hinweis auf eine mögliche Ursache |
| Ergebnis | wiederhergestellter Dienst, eventuell mit Umgehungslösung | gefundene Ursache, dokumentierter bekannter Fehler, Vorschlag für eine dauerhafte Änderung |
In kleinen Teams arbeiten oft dieselben Personen in beiden Bereichen. Das ist kein Hindernis. Wichtig ist, dass beide Aufgaben getrennt sichtbar sind. Sonst geht die Ursachensuche im Tagesgeschäft unter, weil die nächste Störung immer dringender wirkt.
Wann wird aus Störungen ein Problem?
Nicht jede Störung braucht eine Ursachenanalyse. Wir empfehlen, ein Problem anzulegen, wenn mindestens eines davon zutrifft:
- Dieselbe oder eine sehr ähnliche Störung tritt mehrfach auf.
- Eine einzelne Störung hatte erhebliche Folgen, zum Beispiel einen längeren Ausfall eines wichtigen Systems.
- Die Überwachung (Monitoring) zeigt ein Muster, bevor Anwenderinnen und Anwender etwas bemerken, etwa einen stetig volllaufenden Speicher.
- Ein Hersteller meldet einen Fehler, der auch Ihre Systeme betreffen kann.
Die letzten beiden Punkte zeigen: Problem Management kann auch vorbeugend arbeiten. Es sucht dann nach möglichen Ursachen, bevor daraus eine Störung wird.
Ablauf in fünf Schritten
Der folgende Ablauf ist ein Vorschlag für kleine und mittlere Unternehmen. Er lässt sich mit einem vorhandenen Ticketsystem umsetzen.
- Erfassen: Legen Sie ein eigenes Problem-Ticket an und verknüpfen Sie alle zugehörigen Störungen damit. So sehen Sie, wie oft die Ursache schon Arbeit verursacht hat.
- Bewerten: Schätzen Sie ab, wie viele Personen betroffen sind und wie stark die Arbeit beeinträchtigt wird. Danach richtet sich die Reihenfolge.
- Ursache suchen: Sammeln Sie Fakten aus Protokollen, Änderungsverlauf und Überwachung. Einfache Methoden reichen oft aus, etwa die Frage „Warum?“ mehrmals hintereinander zu stellen, bis eine beeinflussbare Ursache sichtbar wird.
- Umgehungslösung festhalten: Dokumentieren Sie, was bis zur dauerhaften Lösung hilft. Der Service Desk kann damit künftige Meldungen schneller bearbeiten.
- Dauerhaft beheben: Die eigentliche Lösung ist meist eine Änderung, etwa ein Update, eine neue Einstellung oder ein Austausch von Hardware. Solche Änderungen sollten geplant, bewertet und freigegeben werden. In ITIL 4 ist dafür die Praxis Change Enablement zuständig. Sie soll laut PeopleCert unter anderem sicherstellen, dass Risiken bewertet und Änderungen genehmigt werden.
Schließen Sie das Problem erst, wenn die Änderung umgesetzt ist und die Störung in einem vereinbarten Zeitraum nicht mehr auftritt. Ein geschlossenes Ticket allein sagt noch nichts darüber, ob die Ursache wirklich beseitigt ist.
Kennzahlen: messen, was sich verbessern soll
Kennzahlen helfen nur, wenn sie zu Ihrer Umgebung passen. Übernehmen Sie deshalb keine pauschalen Zielwerte aus anderen Unternehmen. Wir empfehlen, zuerst einige Wochen lang den Ist-Stand zu erfassen und Ziele daraus abzuleiten. Geeignete Messgrößen sind zum Beispiel:
- wiederkehrende Störungen je System oder Dienst, etwa E-Mail, Dateiablage oder Warenwirtschaft;
- Zahl und Alter offener Probleme;
- Anteil der Störungen, für die eine dokumentierte Umgehungslösung vorlag;
- Zahl der Probleme, deren dauerhafte Lösung umgesetzt und überprüft wurde.
Wichtiger als einzelne Werte ist die Entwicklung über mehrere Monate. Sinkt die Zahl der Wiederholungen bei einem System, zeigt das, dass die Ursachenarbeit dort wirkt.
Rollen in einem kleinen IT-Team
Problem Management braucht keine eigene Abteilung. Es braucht aber eine Person, die dafür verantwortlich ist, dass offene Probleme nicht liegen bleiben. Diese Person muss nicht jede Analyse selbst machen. Sie sorgt dafür, dass Fachleute einbezogen werden, Ergebnisse dokumentiert sind und Änderungen umgesetzt werden.
Planen Sie dafür feste Zeit ein, zum Beispiel einen regelmäßigen Termin, in dem offene Probleme besprochen werden. Wenn ein externer Dienstleister Teile Ihrer IT betreut, gehört er in diese Runde. Viele Ursachen liegen an der Schnittstelle zwischen eigenen Systemen und betreuten Diensten.
Problem Management und NIS2
Unternehmen, die unter die NIS2-Regeln fallen, müssen nach § 30 BSI-Gesetz geeignete Risikomanagementmaßnahmen ergreifen. Dazu zählen unter anderem die Bewältigung von Sicherheitsvorfällen, die Aufrechterhaltung des Betriebs und Verfahren, mit denen die Wirksamkeit der Maßnahmen bewertet wird.
Problem Management ist im Gesetz nicht ausdrücklich genannt. Eine dokumentierte Ursachenanalyse kann aber helfen, Vorfälle nachvollziehbar aufzuarbeiten und Verbesserungen zu belegen. Ob und wie Ihr Unternehmen betroffen ist, klären Sie am besten gesondert. Einen Einstieg bietet unsere Seite zu NIS2 und Risikomanagement. Wie Sie sich auf schwerwiegende Sicherheitsvorfälle vorbereiten, beschreibt unser Beitrag zum Incident Response Plan.
Unterstützung durch die GSL Groß GmbH
Die GSL Groß GmbH betreut kleine und mittelständische Unternehmen in Rheinland-Pfalz und Hessen von Idar-Oberstein aus; im Raum Darmstadt arbeitet sie dafür mit einem Partnersystemhaus zusammen. Mit unseren Managed Services übernehmen wir den laufenden Betrieb Ihrer IT zum monatlichen Festpreis. Managed Services bedeutet: Ein Dienstleister übernimmt vereinbarte IT-Aufgaben dauerhaft. Bei akuten Störungen erreichen Sie unseren Support.
Sie möchten wiederkehrende Störungen in Ihrem Unternehmen strukturiert angehen? Sprechen Sie uns an.