IT-Fachjargon erklärt

ITIL Problem Management

Problem Management ist ein IT-Service-Management-Prozess, der mit der Verwaltung des Lebenszyklus zugrundeliegender „Probleme" beauftragt ist. Das primäre Ziel des Problem Managements besteht darin, das Auftreten von Incidents zu verhindern – und wenn Incidents auftreten, ihr erneutes Auftreten zu vermeiden.

Als IT-Service-Desk-Fachleute möchten wir unseren Nutzern ein Service-Erlebnis bieten und bereitstellen, das schlicht außergewöhnlich ist. Wir können Incidents mit dem Incident-Management-Prozess so schnell wie möglich beheben und den Service wiederherstellen – doch das eigentliche Ziel ist es, gar keine Incidents zu haben. Daher stellen wir Ihnen das Problem Management vor, das Ihnen und Ihrer Organisation hilft, diese Ziele zu erreichen.

Das primäre Ziel des Problem Managements besteht darin, das Auftreten von Incidents zu verhindern – und wenn Incidents auftreten, ihr erneutes Auftreten zu vermeiden. Können Sie sich einen Service Provider vorstellen, der nur reaktiv auf Incidents reagiert, die sich kontinuierlich wiederholen und nie wirklich gelöst werden? Können Sie sich ein Szenario vorstellen, in dem es zur „normalen Geschäftspraxis" wird, dieselben Incidents immer wieder und wieder zu beheben? Mit der Zeit wird die Anzahl der Incidents steigen, die Kosten für das Incident-Management werden zunehmen, die Kunden- und Nutzerzufriedenheit wird drastisch sinken, der Ruf des Service-Desks wird leiden, Shadow-IT-Initiativen werden zur Norm, und das Gesamtergebnis wird eine erhebliche Beeinträchtigung der Geschäftsfähigkeit sein.

Viele Organisationen leiden unnötigerweise, weil sie keinen effektiven Problem-Management-Prozess haben. Häufig liegt das daran, dass IT-Teams Problem Management mit Incident Management verwechseln und dessen Beziehung zum Change Management nicht vollständig verstehen. Diese Prozesse arbeiten zwar Hand in Hand, aber das Ziel des Problem Managements ist es, das Incident Management zu unterstützen, indem Incidents von vornherein verhindert werden – durch den Einsatz des Change-Management-Prozesses!

Behalten Sie beim Lesen dieses Leitfadens den Mehrwert für das Unternehmen im Blick, der entsteht, wenn Sie das Wesentliche für Ihre Organisation tun – und es richtig tun, indem Sie Mitarbeiter, Prozesse, Technologie und Lieferanten einsetzen, um Ihre Ziele zu erreichen. Service-Exzellenz ist eine Reise, die niemals endet und kontinuierlich gepflegt werden muss. Und vor allem: Wenn Sie Verbesserungen in Ihrer gesamten Serviceerbringung feststellen, feiern Sie Ihre Erfolge!

Was ist ITIL Problem Management?

Problem Management ist ein IT-Service-Management-Prozess, der mit der Verwaltung des Lebenszyklus zugrundeliegender „Probleme" beauftragt ist. Erfolg wird erzielt, indem Probleme schnell erkannt und Lösungen oder Workarounds bereitgestellt werden, um die Auswirkungen auf die Organisation zu minimieren und ein erneutes Auftreten zu verhindern. Problem Management versucht außerdem, den Fehler in der IT-Infrastruktur zu finden, der das Problem verursacht und zu den Incidents beiträgt, mit denen Benutzer konfrontiert sein können. Die IT Infrastructure Library (ITIL) enthält folgende Definitionen für die Verwendung in diesem Prozess:

  • Problem: „Die Ursache eines oder mehrerer Incidents. Die Ursache ist zum Zeitpunkt der Erstellung eines Problem-Datensatzes in der Regel nicht bekannt."
  • Fehler: „Ein Designfehler oder eine Fehlfunktion, die zum Ausfall eines oder mehrerer IT-Services oder anderer Konfigurationselemente führt."
  • Bekannter Fehler: „Ein Problem, das eine dokumentierte Grundursache und einen Workaround hat."
  • Grundursache: „Die zugrundeliegende oder ursprüngliche Ursache eines Incidents oder Problems."

Proaktives vs. reaktives Problem Management

Problem Management kann entweder reaktiv oder proaktiv sein.

  • Reaktives Problem Management ist die Problemlösungsreaktion, die eintritt, wenn ein oder mehrere Incidents auftreten.
  • Proaktives Problem Management befasst sich mit der Identifizierung und Lösung von Problemen, bevor Incidents aufgetreten sind. Diese Aktivität ist mit Continual Service Improvement (CSI) verbunden.

Der Mehrwert des Problem Managements für das Unternehmen

Der Problem-Management-Prozess arbeitet in Verbindung mit Incident- und Change Management, um dem Unternehmen auf vielfältige Weise Mehrwert zu bieten. Das primäre Ziel des Problem Managements ist es, die Auswirkungen von Problemen auf das Unternehmen zu minimieren und ein erneutes Auftreten zu verhindern. Bei erfolgreichem Einsatz werden Ausfallzeiten und Unterbrechungen reduziert. Weitere Vorteile umfassen:

  • Erhöhte Service-Verfügbarkeit
  • Verbesserte Servicequalität
  • Verkürzte Problemlösungszeiten
  • Reduzierung der Anzahl von Incidents
  • Gesteigerte Produktivität
  • Reduzierte Kosten
  • Verbesserte Kundenzufriedenheit

Die Einführung und Implementierung von ITIL-Prozessen und -Technologie minimiert das Chaos, mit dem IT-Organisationen in einem sich rasch verändernden Technologieumfeld konfrontiert sein können. Obwohl Problem Management ein eigenständiger Prozess ist, ist er auf einen effektiven Incident-Management-Prozess und die richtigen Werkzeuge angewiesen – Werkzeuge, die eine gemeinsame Schnittstelle, Zugang zu verfügbarem Wissen, Configuration-Management-Informationen und die Interaktion mit anderen verwandten ITIL-Prozessen umfassen. Dies stellt sicher, dass Probleme identifiziert werden, relevante Details enthalten und so schnell wie möglich bearbeitet werden. ITIL bietet Organisationen keine genaue Methode zur Einführung des Problem Managements, sondern einen strukturierten Rahmen, der an individuelle Geschäftsanforderungen und -rahmenbedingungen angepasst werden muss. Regelmäßige Anpassungen dieser internen ITIL-Prozesse werden letztendlich die Agilität unterstützen, den Geschäftswert demonstrieren und Organisationen dabei helfen, in ihrem Marktumfeld wettbewerbsfähig zu bleiben.

Prozessablauf des Problem Managements

Wie funktioniert Problem Management? ITIL Problem Management geht über die bloße Lösung von Incidents hinaus – es berücksichtigt den gesamten Lebenszyklus eines Problems. Der Prozessablauf des Problem-Management-Lebenszyklus kann so strukturiert werden, dass er Probleme verwaltet, die zunächst von Benutzern oder Service-Desk-Technikern als Incidents gemeldet werden – über ein Self-Service-Portal, telefonisch, per E-Mail oder persönlich – sowie potenzielle Probleme, die automatisch von ITSM-Mitarbeitern oder -Technologie erkannt werden, bevor ein Incident auftritt. Der Umfang des Problem-Management-Prozessablaufs umfasst:

1) Problemerkennung

Probleme können auf verschiedene Weise erkannt werden, unter anderem als Ergebnis eines Incident-Berichts, einer laufenden Incident-Analyse, einer automatischen Erkennung durch ein Event-Management-Tool oder einer Lieferantenbenachrichtigung. Ein Problem wird häufig erkannt, wenn die Ursache eines oder mehrerer beim Service-Desk gemeldeten Incidents unbekannt ist. Es ist möglich, dass der Service-Desk den Incident gelöst hat und er erneut auftreten kann, die zugrundeliegende Ursache jedoch unbekannt ist – in diesem Fall wird ein Problem-Datensatz erstellt. In anderen Fällen kann es für den Service-Desk offensichtlich sein, dass ein gemeldeter Incident mit einem Problem zusammenhängt. Dieses Problem wurde möglicherweise bereits erfasst – bekanntes Problem – und der Incident kann mit dem bestehenden Problem-Datensatz verknüpft werden. Wurde das Problem noch nicht erfasst, sollte unverzüglich ein Problem-Datensatz erstellt werden, um die Service-Performance sicherzustellen.

2) Problemprotokollierung

Um eine vollständige historische Aufzeichnung zu gewährleisten, müssen alle Probleme – unabhängig von der Methode ihrer Identifizierung und Meldung beim Service-Desk – mit allen relevanten Details protokolliert werden, einschließlich Datum/Uhrzeit, Benutzerinformationen, Beschreibung, zugehörigem Configuration Item aus der CMDB, verknüpften Incidents, Lösungsdetails und Abschlussinformationen.

  • Kategorisierung – Nach der Protokollierung müssen alle geeigneten Kategorien ausgewählt werden, um Häufigkeiten und Problemtrends korrekt zuzuweisen, zu eskalieren und zu überwachen.
  • Priorisierung – Die Zuweisung von Prioritäten ist entscheidend dafür, wie und wann das Problem vom Personal bearbeitet wird. Sie wird durch die Auswirkung bestimmt – die Anzahl der verknüpften Incidents, die Aufschluss über die Anzahl der betroffenen Benutzer oder die Auswirkungen auf das Unternehmen geben kann. Darüber hinaus wird die Dringlichkeit des Problems – wie schnell eine Lösung erforderlich ist – berücksichtigt, um die Priorität festzulegen.

3) Untersuchung und Diagnose

Eine Untersuchung der Grundursache des Problems wird auf der Grundlage der Auswirkung, des Schweregrads und der Dringlichkeit des betreffenden Problems durchgeführt. Gängige Untersuchungstechniken umfassen die Überprüfung der Known-Error-Datenbank (KEDB), um übereinstimmende Probleme und Lösungen zu finden, und/oder die Reproduktion des Fehlers zur Bestimmung der Ursache.

4) Workaround

In einigen Situationen ist es möglich, dem Benutzer, der den mit dem Problem zusammenhängenden Incident erlebt, eine vorübergehende Lösung oder einen Workaround bereitzustellen. Es ist jedoch wichtig, eine dauerhafte Änderungslösung für den vom Problem Management erkannten zugrundeliegenden Fehler anzustreben.

5) Bekannten-Fehler-Datensatz erstellen

Sobald die Untersuchung und Diagnose abgeschlossen ist, ist es wichtig, einen Known-Error-Datensatz zu erstellen. Sollten zukünftig Incidents oder Probleme auftreten, kann der untersuchende Service-Desk-Techniker mithilfe der Known-Error-Datenbank (KEDB) und der zugehörigen Workarounds schneller eine Lösung identifizieren und bereitstellen.

6) Lösung

Nach der Lösung kann die Fehlerbehebung über das standardmäßige Change-Verfahren implementiert und getestet werden, um die Service-Wiederherstellung zu bestätigen. Wenn jedoch eine normale Änderung erforderlich war, wird ein zugehöriger Request for Change (RFC) erstellt und genehmigt, bevor eine Lösung auf das Problem angewendet wird.

7) Abschluss

Nach der Bestätigung, dass der Fehler behoben wurde, können das Problem und alle zugehörigen Incidents geschlossen werden. Der Service-Desk-Techniker sollte sicherstellen, dass die ursprünglichen Klassifizierungsdetails für zukünftige Referenz und Berichterstattung korrekt sind.

  • Major-Problem-Review – Major-Probleme werden durch die Business-Impact-Analyse (BIA) und Risikobewertung (RA) einer Organisation definiert, um Reaktion und Priorität (Auswirkung, Dringlichkeit und Schweregrad des Problems) zu bestimmen. Das Ziel eines Major-Problem-Reviews ist die kontinuierliche Verbesserung des Problem-Management-Prozesses bei der Reaktion auf schwerwiegende Geschäftsprobleme. Ein Überprüfungsprozess kann Dinge identifizieren, die korrekt durchgeführt wurden, Dinge, die fehlerhaft durchgeführt wurden, was verbessert werden kann, zusätzliche Risiken, wie ein erneutes Auftreten verhindert werden kann und die Art der Verantwortung etwaiger Dritter. Diese Überprüfung sollte nicht isoliert stattfinden, sondern im Rahmen von Schulungs- und Sensibilisierungssitzungen mit Teammitgliedern geteilt werden.
  • Problem Control und Error Control – In einigen Situationen können die Begriffe Problem Control und Error Control während des Problem-Management-Lebenszyklus verwendet werden. Problem Control kann in die Untersuchungsphase einbezogen werden mit dem Ziel, die Grundursache des Problems zu finden und es in einen bekannten Fehler umzuwandeln. Dies hilft dem Service-Desk-Techniker, dem Benutzer vorübergehende Workarounds bereitzustellen. Error Control hingegen ist Teil der Lösungsphase mit dem Ziel, bekannte Fehler in Lösungen umzuwandeln und sie bei Bedarf aus der Known-Error-Datenbank (KEDB) zu entfernen.

Miteinander verbundene ITIL-Prozesse: Incident und Change Management

ITIL-Prozesse interagieren während des gesamten Service-Delivery-Lebenszyklus miteinander. Problem Management und Incident Management sind eng miteinander verbunden, aber sie sind nicht dasselbe. Obwohl beide Prozesse von der IT-Abteilung durchgeführt werden, verfolgen sie jeweils unterschiedliche Ziele. Problem Management konzentriert sich darauf, die Auswirkungen eines oder mehrerer Incidents durch die Ermittlung der Grundursache zu verhindern oder zu minimieren. Incident Management zielt darauf ab, einen Incident schnell zu lösen und den Service für die Benutzer zeitnah wiederherzustellen. Die Wiederherstellung des Services im Incident Management bedeutet nicht zwingend, dass der Incident nicht erneut auftreten wird. Die Mehrzahl der Probleme wird als Reaktion auf einen oder mehrere Incidents ausgelöst, aber in einigen Situationen werden Probleme erstellt, wenn Tester ein Release testen – etwa bei der Verwendung des Service-Validation-and-Testing-Prozesses – oder wenn Lieferanten Fehler in ihren Produkten oder Services entdecken.

Obwohl Service Operation nach Stabilität strebt, gibt es Situationen, in denen Änderungen notwendig sind. Aus diesem Grund ist Change Management ebenfalls eng mit Problem Management verbunden. Änderungen können vorab genehmigt sein oder eine Genehmigung erfordern; in beiden Fällen wird ein RFC erstellt, um die erforderliche Änderung zu dokumentieren. Ein Request for Change (RFC) wird häufig während des Problem-Management-Lebenszyklus ausgelöst, wenn neue, verbesserte oder aktualisierte Hardware, Software, Prozesse oder Infrastruktur erforderlich sind, um ein Problem zu lösen.

Weitere wichtige ITIL-Prozessbeziehungen:

  • Configuration Management
  • Service Level Management
  • Availability Management
  • Capacity Management
  • Event Management
  • Service Validation and Testing

Rollen und Verantwortlichkeiten im Problem Management

Klar definierte Rollen und Verantwortlichkeiten sind entscheidend für die effektive Umsetzung eines erfolgreichen Problem-Management-Prozesses. Das Problem-Management-Team setzt sich aus folgenden Rollen zusammen:

1) Problem Manager

Ein Problem Manager ist eine designierte Person, die möglicherweise auch für andere organisatorische Rollen verantwortlich ist. Dieser Verantwortliche des Problem-Management-Prozesses ist für alle Aspekte seiner Koordination zuständig, einschließlich:

  • Funktion als Schnittstelle zu den für die Problemlösung verantwortlichen Mitarbeitern
  • Sicherstellung, dass Probleme innerhalb ihres SLA gelöst werden
  • Verantwortung für und Verwaltung der Known-Error-Datenbank (KEDB)
  • Abschluss von Problemen
  • Koordination des Major-Problem-Reviews

Hinweis: Der Problem Manager und der Incident Manager sollten nicht dieselbe Person sein, da mögliche Konflikte im Ausführungsfokus entstehen können.

2) Problemlösungsteam

Die Lösung von Problemen kann von internen technischen Support-Teammitgliedern oder externen Lieferanten bzw. Anbietern übernommen werden. In Situationen, in denen ein schwerwiegendes oder größeres Problem auftritt, kann der Problem Manager ein dediziertes Problem-Management-Team zusammenstellen, das aus Ressourcen mit spezifischem Fachwissen besteht.

Feature-Checkliste für Problem-Management-Software

Für IT-Organisationen, die Problem-Management-Software und/oder IT-Service-Management-Suiten mit Problem-Management-Funktionen evaluieren, sind die folgenden Features wichtig – wenn nicht sogar unverzichtbar – für die effektive Unterstützung zentraler Prozesse.

Problem-Management-Software sollte Administratoren mindestens in die Lage versetzen:

  • Problemmanagement-Prozesse zu konfigurieren
  • Incident-Kategorisierung zu konfigurieren
  • Problem-Datensätze zu erstellen, zu ändern, zu lösen und zu schließen
  • ITIL oder andere branchenübliche Best-Practice-Frameworks zu implementieren
  • Den Status automatisch zu aktualisieren oder alle verknüpften Incidents bei Problem-Aktualisierung/-Abschluss zu schließen
  • Probleme mit CIs, Incidents und Change Requests zu verknüpfen
  • Auswirkung und Dringlichkeit eines Problems zuzuweisen
  • Zwischen Problemen und bekannten Fehlern zu unterscheiden
  • Aufgaben automatisch oder manuell Einzelpersonen oder Teams zuzuweisen
  • Die Aufzeichnung historischer Daten in einem Audit-Log zu automatisieren
  • Eindeutige Datensatznummern für jeden Problem-Datensatz zu generieren
  • Mit Incident-, Change-, Configuration- und Knowledge Management zu integrieren
  • Die Problembehebung basierend auf Geschäftsregeln und SLAs zu automatisieren
  • Wissens-Artefakte im Zusammenhang mit Problemen und bekannten Fehlern zu dokumentieren und zu verwalten
  • Betroffene CIs innerhalb eines Problem-Datensatzes anzuzeigen
  • Arbeitszeiten zu erfassen
  • Mit Wissensdatenbanken von Drittanbietern zu verknüpfen
  • Flexible Feldkonfigurationen zu verwenden, einschließlich Freitext, Dropdown-Menü, Datum/Uhrzeit, Anhänge und Screenshots
  • Vorlagen für wiederkehrende Probleme zu erstellen
  • Nach Lösungen, Workarounds und bekannten Fehlern zu suchen
  • Root-Cause-Analysen zu dokumentieren
  • Problem-Such- und Berichtsfunktionen zu nutzen

Dieser Inhalt erschien ursprünglich auf Cherwell.com, vor der Übernahme durch Ivanti.