Kategorien
ITIL

Prozessbeschreibung Problemmanagement

Prozess Pyramide

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.

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 RfCs

    KRITISCHE 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

Von Michael

wohnhaft in München
arbeite bei der Landeshauptstadt München

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert