KURZBESCHREIBUNG
Im Zuge des Problem Managements werden Probleme erkannt, registriert, klassifiziert, analysiert und Schritte zu deren Lösung durchgeführt. Das Problem Management sucht strukturelle Lösungen zur Verbesserung der Infrastruktur und Vermeidung von Incidents. Es stellt ebenfalls Workarounds und Informationen über Known Errors bereit und hat das Ziel, Störungen zu verhindern und deren Auftreten zu minimieren. Hier eine bespielhafte Prozessbeschreibung.
PROZESSZIELE
Das Ziel des Problem Management Prozesses ist es, die Anzahl der Incidents zu minimieren und so die Verfügbarkeit der Services zu verbessern.
PROZESS-INPUT
- Incidents
- Informationen aus Trend Analysen (Bspw. aus dem Capacity-, Availability- oder Incident Management)
- Informationen von Spezialisten
- Major Incidents
- SLA Bruch
PROZESS-OUTPUT
Behobene Ursachen der Probleme Workarounds Einträge in KEDB – Known Errors Problem Management Berichte RfCsKRITISCHE ERFOLGSFAKTOREN
- Effizientes IT Service Management Tool mit der
- Möglichkeit zum automatisierten Workflow
- Angemessene Service Level Agreements (SLAs)
- Klar definierte Verantwortungsbereiche
- Wissensdatenbank mit Informationen zu Known Errors
NUTZEN
Höhere Anwenderzufriedenheit Rechtzeitige Erkennung von erforderlichen Verbesserungen Geringere Auswirkungen von IT-Störungen auf den Geschäftsbetrieb Einhaltung von SLAs Dokumentationen von Known Errors und Workarounds
PROZESSKENNZAHLEN / MESSGRÖSSEN
- Problemtickets pro Monat [Stck] Definition: Die Anzahl der neu erkannten Probleme und die Anzahl der gelösten Probleme (pro Monat)
- Geschlossene Problemtickets pro Monat [Stck] Definition: Anzahl der geschlossenen Problemtickets pro Monat
- Störungen pro Monat [Stck] Definition: Die Anzahl der registrierten Interaction Tickets mit der Kategorie “Request for Incident Resolution” (pro Monat)
- Backlog Problemtickets [Stck] Definition: Die Anzahl der Probleme, deren Status noch nicht “Gelöst” ist (pro Monat)
- Anzahl reaktiver Problemtickets pro Monat [Stck] Definition: Anzahl der neu eröffneten Problemtickets der Problem Category “reactive”, pro Monat
- Anzahl proaktiver Problemtickets pro Monat [Stck] Definition: Anzahl der neu eröffneten Problemtickets der Problem Category “proactive”, pro Monat
- Anzahl der offenen Problemtickets mit Status “Deadline Overdue” pro Monat [Stck] Definition: Anzahl der offenen Problemtickets, pro Monat bei denen die “Deadline” überschritten wurde
SCHNITTSTELLEN
CONFIGURATION MANAGEMENT
Das Configuration Management stellt dem Problem Management die nötigen Informationen über CIs und CI-Strukturen zur Verfügung. Dies ist wichtig für die Bearbeitung der Problemtickets.
CHANGE UND RELEASE MANAGEMENT
Aus dem Problem Management werden RfCs an das Change und Release Management gestellt, um Changes durchzuführen, die zur Lösung des Problems führen können. Mögliche Probleme und Known Errors, die im Rahmen der Rollout Tests im Vorfeld eines Releases festgestellt werden, werden dem Problem Management vom Release Management über die geeignete IT-Order gemeldet.
INCIDENT MANAGEMENT
Der Problem Management Prozess setzt den Prozess Incident Management voraus. Das Incident Management stellt dem Problem Management grundlegende Daten für die Trendanalyse und weitere Auswertungen zur Verfügung. Durch eine möglichst genaue Kategorisierung, Störungs- und Lösungsbeschreibung in den Incident-Tickets wird die Arbeit des Problem Management Prozesses erleichtert. Das Incident Management kann den Problem Management Prozess direkt anstoßen und jeder Major Incident muss in einem Problemticket untersucht werden.
AVAILABILITY MANAGEMENT
Das Problem Management nutzt Informationen bzw. Analysen aus dem Availability Management, um Probleme in den Services hinsichtlich Verfügbarkeit frühzeitig erkennen zu können. Mögliche Probleme hinsichtlich Verfügbarkeit werden dem Problem Management vom Availability Management mitgeteilt.
CAPACITY MANAGEMENT
Das Problem Management nutzt Informationen bzw. Analysen aus dem Capacity Management, um Probleme in den Services hinsichtlich Kapazitäten frühzeitig erkennen zu können. Mögliche Probleme hinsichtlich Kapazität werden dem Problem Management vom Capacity Management mitgeteilt.
SERVICE LEVEL MANAGEMENT
Jedes gebrochene SLA wird im Problem Management untersucht, um die Ursache dafür zu finden und eine Lösung zu erarbeiten. ROLLENBESCHREIBUNG SPEZIALIST Dokument hinterlegen für die Rollenbeschreibung Spezialist
Problemmanager ROLLENBESCHREIBUNG
Der Problemmanager ist verantwortlich für die effektive Durchführung des Problem Management Prozesses sowie für das entsprechende Berichtswesen.
VERANTWORTLICHKEITEN
Der Problemmanager trägt die Verantwortung für den gesamten Problem Management Prozess, insbesondere für die Performance und die Ergebnisse.
AUFGABEN
Überwachung aller Problemtickets erste Eskalationsstufe im Rahmen der hierarchischen Eskalation strategische Verantwortung für den Problem Management Prozess Verantwortung für die Qualität und die Anpassung des Prozesses an die Bedürfnisse der Geschäftsprozesse Entwicklung und Pflege des Problem Management Systems (IT Service Management Tool)
BEFUGNISSE
Leitungsfunktion für alle Prozess-Beteiligten des Problem Management Prozesses Fachliche Verantwortung für die Problemmanageren
DEFINITIONEN
INCIDENT
Ein Incident ist ein Ereignis, das den Standardbetrieb eines Services beeinflusst und tatsächlich oder potenziell eine Unterbrechung oder Beeinträchtigung der Service-Qualität zur Folge hat. Ein Incident ist eine außergewöhnliche, aber beherrschbare Abweichung vom Normalbetrieb.
PROBLEM
Ein Problem ist die unbekannte Ursache eines oder mehrerer existierender oder potenzieller Incidents. Probleme können durch das Auftreten mehrerer Incidents mit gleichen Symptomen oder auch durch das Auftreten eines Major Incidents identifiziert werden (Reaktives Problem Management). Probleme können auch vor dem Auftreten von Incidents identifiziert werden (Proaktives Problem Management).
PROBLEM TASK
Ein Problem Task ist eine Zuweisung von Aufgaben innerhalb eines Problemtickets an bestimmte Spezialisten aus dem entsprechenden Fachgebiet. WORKAROUND Ein Workaround ist eine Vorgehensweise, welche zur Beseitigung der vorliegenden Störung führt. Er wird im Allgemeinen genutzt, um Incidents so schnell wie möglich zu beheben, gilt allerdings nicht als endgültige und permanente Lösung des Problems.
KNOWN ERROR
Ein Known Error bezeichnet ein Problem, dessen Ursache bekannt ist. Besteht zu
einem Problem ein Known Error, existiert parallel zu den Informationen im IT Service Management Tool ein Fehler-Eintrag in der Wissensdatenbank.
PROZESSABLAUF PROZESSBESCHREIBUNG
PROAKTIVES DURCHFÜHREN VON TRENDANALYSEN
WAS IST ZU TUN?
Der Problemmanager nutzt Informationen von Interaction Tickets der Kategorie „Request for Incident Resolution“ oder aus dem Capacity- / Availability Management, um Probleme in den Services zu erkennen.
WIE IST ES ZU
TUN? Nutzung der Such- und Reportingfunktion des IT Service Management Tools Entgegennahme von Analysen aus dem Capacity- / Availability Management
VERANTWORTLICHE ROLLE
Problemmanager
INPUT
- Incidents aus dem Incident
- Management Analysen aus dem Capacity- / Availability Management
OUTPUT
Identifiziertes Problem
ERSTELLUNG EINES PROBLEMTICKETS
WAS IST ZU TUN?
Nach der Identifizierung eines Problems durch proaktive Trendanalysen oder reaktive Berichte von Spezialisten oder dem Incident Management erstellt der Problemmanager ein Problemticket im IT Service Management Tool.
WIE IST ES ZU TUN?
Registrierung des Problems im IT Service Management Tool Ausfüllen der Pflichtfelder im Problemticket (Priorisierung & Kategorisierung & Severity) Verknüpfung des Problemtickets mit den dazugehörigen Interaction Tickets Zuweisung von Tasks an den geeignetsten Spezialisten zur Ursachenforschung (bezogen auf Fähigkeit und Verfügbarkeit)
VERANTWORTLICHE ROLLE
Problemmanager
INPUT
Identifizierung eines Problems durch einen Incident (Severity = 14 Tage um das Problem zu analysieren) Major Incident (Severity = 7 Tage um das Problem zu analysieren) SLA Bruch (Severity = 7 Tage um das Problem zu analysieren) Hinweis auf mögliches Problem durch Spezialist / Proaktive Identifikation eines Problems (Severity = 28 Tage um Problem zu analysieren / 14 bzw. 7 Tage falls ein Major Incident oder SLA Bruch innerhalb dieser Zeit zu erwarten ist)
OUTPUT
- Problemticket
- Zugewiesene Tasks an Spezialisten
URSACHENFORSCHUNG UND LÖSUNGSIMPLEMENTIERUNG
WAS IST ZU TUN?
Der Spezialist überprüft die Details des Problems und versucht die Ursache des Problems zu finden. Der Spezialist erstellt ggf. Workarounds, um vorhandene Incidents zu lösen und dokumentiert erkannte Ursachen (Known Errors) in der Wissensdatenbank. Anschließend folgt die Implementierung der vorgeschlagenen Lösung, ggf. durch das Change Management.
WIE IST ES ZU TUN?
Prüfung des Problems und Forschen nach der Ursache Erstellung eines Workarounds und Eintrag in die Wissensdatenbank Evaluierung und Dokumentation möglicher Lösungsansätze innerhalb des Problemtickets Implementierung der Lösung ggf. mittels Change Management (RfC) Ein RfC ist notwendig, wenn durch die Implementierung o ein Service während der Servicezeit nicht mehr verfügbar sein wird o sich die Funktionalität eines Service ändern wird o die CMDB ein Update benötigt
VERANTWORTLICHE ROLLE
Spezialist
INPUT
Task innerhalb eines Problemtickets
OUTPUT
- RfC an das Change Management
- Eintrag in der Wissensdatenbank
- Workaround für das Incident Management
- Lösung des Problems
ÜBERWACHUNG
WAS IST ZU TUN?
Überwachung von Problemtickets.
WIE IST ES ZU TUN?
Regelmäßige Prüfung der offenen Problemtickets hinsichtlich des Status und der verstrichenen Zeit bis zum Zieldatum Eskalation eines Problemtickets an den Problemmanager, wenn kein Fortschritt bei der Bearbeitung des Problemtickets erzielt wird (ersichtlich aus Updates und Dokumentation im Ticket)
VERANTWORTLICHE ROLLE
Problemmanager
INPUT
Übersicht der offenen Problemtickets
OUTPUT
Information an Problemmanager
ESKALATION
WAS IST ZU TUN?
Prüfung der eskalierten Problemtickets durch den Problemmanager und Entscheidung darüber, wie mit dem Problemticket weiter zu verfahren ist.
WIE IST ES ZU TUN?
Rücksprache mit dem Problemmanager zum aktuellen Stand des Problemtickets und Entscheidung mit Hilfe von Spezialisten, wie mit dem Problemticket weiter zu verfahren ist.
VERANTWORTLICHE ROLLE
Problemmanager
INPUT
Eskalierte Problemtickets
OUTPUT
Entscheidung zur Bearbeitung des Problemtickets
SCHLIESSEN DES ProblemticketS
WAS IST ZU TUN?
Nachdem ein Spezialist die Ursachenforschung eines Problems abgeschlossen hat, prüft der Problemmanager das Ergebnis, um zu bestimmen, ob eine dauerhafte Lösung vorgeschlagen oder bereits implementiert wurde und schließt anschließend das Problemticket oder kennzeichnet einen „Dead End“ Status.
WIE IST ES ZU TUN?
Prüfung der dauerhaften Lösung auf tatsächliche Problembehebung Erneute Zuweisung von Tasks im Falle einer ungenügenden Lösung des Problems Schließen des Problems mit zeitgleicher Information des Service Desk im Falle eines reaktiv erkannten Problems Periodische Prüfung der Problemtickets mit Status „Dead End“ o Der Status „Dead End“ wird dadurch definiert, dass es nicht möglich ist, das Problem zu lösen, da entweder dessen Ursache nicht gefunden werden kann oder es momentan keinen Vorschlag für eine permanente Lösung gibt.
VERANTWORTLICHE ROLLE
Problemmanager
INPUT
Abschluss des Problem Tasks durch Spezialisten Implementierung der vorgeschlagenen Lösung des Problems Information des Change Managements über erfolgreich implementierten Change
OUTPUT
Gelöstes Problemticket – Problemticket mit Status „Dead End“
Quelle: IT Service Management Forum
