Problem Record - Checkliste

 

Abb. 1: Problem Record
(YaSM-Checkliste / Dokument-Vorlage)

Definition: Ein Problem Record ist ein Datensatz mit allen Angaben zu einem Problem, in dem der Verlauf des Problems von der Ersterfassung bis zur Schließung dokumentiert ist. Ein Problem ist definiert als die zugrundeliegende Ursache eines oder mehrerer (potentieller) Incidents, auch wenn die Ursache bei der Erstellung eines Problem Records oft noch nicht bekannt ist. In vielen Fällen wird eine Umgehungslösung (Workaround) für ein Problem bereitgestellt, solange eine vollständige Lösung noch nicht verfügbar ist.

Verbundener YaSM Service-Management-Prozess: Lösen von Problemen

Weitere Checklisten und Dokument-Vorlagen: Service-Management-Checklisten

 

Ein Problem Record enthält üblicherweise die folgenden Informationen:

 

Problem Record - Inhalte

Inhalt	Beschreibung
Eindeutige Problem-ID	In der Regel wird die ID automatisch von der Anwendung vergeben, die zum Managen der Problems verwendet wird.
Status des Problems	Statuswerte können beispielsweise sein: "Vorgeschlagen", "Offen", "Zurückgestellt", "Geschlossen" usw.
Erfassung des Problems	Datum und Uhrzeit der Erfassung des Problems.
Verantwortlich (Problem-Owner)	Der / die Problem-Verantwortliche (in vielen Fällen der Problem Manager) trägt die Gesamtverantwortung für die Lösung des Problems, selbst wenn es im Verlauf seines Lebenszyklus Spezialisten übertragen wird, deren Fachkenntnisse für bestimmte Aufgaben benötigt werden.
Zuständige(r) Bearbeiter(in)	Das Problem kann im Verlauf seines Lebenszyklus unterschiedlichen Bearbeitenden zugewiesen werden, falls im Zuge der Problemlösung für bestimmte Aufgaben spezielles Fachwissen benötigt wird.
Klasse bzw. Kategorie	Die Klassifizierung von Problems ist eine Möglichkeit, Problems in Kategorien einzuteilen. Dies erleichtert zum einen das Auffinden bekannter Probleme im Zusammenhang mit dem Lösen von Incidents, und zum anderen die Analyse offener Problems. Das verwendete Klassifikationsschema kann je nach Organisation unterschiedlich sein, aber oft werden Problems z.B. nachfolgenden Kriterien klassifiziert: betroffene(r) Service(s) betroffene(r) Kunde(n) betroffene(r) Standort(e) betroffene Infrastruktur-Komponente(n) und Subkomponente(n) (d.h. Konfigurationselemente) Art des Symptoms (z.B. "Hardware-Fehler", "Software-Fehler", "Verminderte Leistung", "Sicherheitsproblem" usw.) Bearbeitungszustand (z.B. "Wird derzeit analysiert", "Zugrundeliegende Ursache identifiziert", "Lösung in der Entwicklung", "Zugrundeliegende Ursache behoben" usw.) Verfügbarkeit einer Umgehungslösung bzw. eines Workarounds (z.B. "Kein Workaround", "Workaround in Entwicklung", "Workaround bereitgestellt" usw.).
Symptome	Symptom-Beschreibung.
Priorisierung	Die Priorität wird häufig durch Prioritäten-Codes ausgedrückt, wie z.B. "Kritisch", "Hoch", "Mittel", "Niedrig", "Sehr niedrig"). Die Priorität ergibt sich aus der Kombination von Dringlichkeit und Auswirkung, wobei Dringlichkeit die verfügbare Zeit bis zur Lösung des Problems und Auswirkung den (potentiellen) Schaden für das Unternehmen ausdrückt. Problems sollten auf die gleiche Weise wie Service Incidents priorisiert werden, damit sie einander leicht zugeordnet werden können (ein Beispiel für ein Priorisierungsschema finden Sie in der Checkliste "Incident- und Service-Request-Richtlinie").
Links zu weiteren Records	Links zu anderen Problem Records: Falls es Problems gibt, die mit dem vorliegenden in Zusammenhang stehen. Links zu relevanten Incident Records: Falls es (offene oder behobene) Incidents gibt, die mit dem Problem in Zusammenhang stehen. Links zu relevanten Event Records: Falls das Problem auf einem Event beruht, der von einem Monitoring-System gemeldet worden ist. Links zu relevanten Change Records: Falls das Problem mit einem (kürzlich implementierten) Change in Zusammenhang steht.
Eskalation	Funktionale Eskalation: Funktionale Eskalationen (Weiterleitung des Problems an spezialisierte Bearbeiter) müssen aufgezeichnet werden. Hierarchische Eskalation: Problems, die über die Standardverfahren nicht gelöst werden können, müssen eskaliert werden, zum Beispiel zum obersten Management. Solche Eskalationen müssen aufgezeichnet werden.
Status-Änderungen	In diesem Abschnitt sind Statusänderungen des Problems aufzuzeichnen (z.B. von "Offen" auf "Gelöst").
Ursache	Dieser Abschnitt beschreibt die zugrundeliegende Ursache eines Problems. Oftmals ist die Ursache zum Zeitpunkt der Erstellung des Problem Records nicht bekannt, sondern wird erst im Verlauf der Problem-Diagnose identifiziert.
Workaround	Solange wie es noch keine vollständige Lösung gibt, kann für das Problem ein Workaround (temporäre Umgehungslösung) bereitgestellt werden. Die Spezifizierung eines Workarounds enthält üblicherweise Voraussetzungen für den Einsatz des Workarounds Anweisungen zur Implementierung des Workarounds Anweisungen zur Deinstallation bzw. zum Rückgängigmachen des Workarounds Situationen, in denen der Workaround nicht angewandt werden sollte. Dieser Abschnitt kann auch einen Verweis auf ein Incident-Modell enthalten, insbesondere wenn in dem Incident-Modell beschrieben ist, wie ein bestimmter Typ von Service-Incident mittels dieses Workarounds behoben werden kann.
Aktivitäts-Protokoll bzw. Aufgabenliste	In den meisten Systemen zum Managen von Problems ist es möglich, ein einfaches Protokoll der zur Lösung des Problems unternommenen Schritte aufzuzeichnen. Manche Systeme bieten auch die Möglichkeit, den Problems "Aufgaben" zuzuweisen. Ähnlich den Problems, denen sie zugeordnet sind, werden die Aufgaben in der Regel über Attribute beschrieben, wie beispielsweise Bezeichnung, Beschreibung, verantwortlicher Mitarbeiter, Priorität usw. und enthalten eine eigene Statushistorie und ein eigenes Aktivitätsprotokoll.
Angaben zum Problem-Abschluss	Lösungstyp: Behebung der zugrundeliegenden Ursache oder Bereitstellung eines Workarounds (bei manchen Problems ist es wirtschaftlich nicht sinnvoll, die zugrundeliegende Ursache zu beheben; in solchen Fällen besteht die "Lösung" in der Bereitstellung eines Workarounds). Kunden-Feedback: Gegebenenfalls Bestätigung seitens des Kunden oder Nutzers, dass das Problem gelöst worden ist.
Zusatz-Informationen	Anmerkungen und Zusatzinformationen.

Status-Werte und Lifecycle

(Diese Informationen beinhaltet das Lifecycle-Diagramm zum Problem Record, das in der YaSM®-Prozesslandkarte enthalten ist.)

Zu beachten

• Ein Problem, das eine dokumentierte zugrundeliegende Ursache sowie einen Workaround hat, wird häufig auch als "Known Error" bezeichnet, der als "Known Error Record" in der "Known Error Data Base (KEDB)" abzulegen ist. Da sowohl die zugrundeliegende Ursache als auch der Workaround immer mit einem spezifischen Problem verknüpft sind, wird bei YaSM die Ursache eines Problems und ein möglicher Workaround im Zusammenhang mit einem Problem (d.h. in einem Problem Record) dokumentiert.
• Die Klassifizierung von Problems und Incidents sollte nach den gleichen Regeln erfolgen, damit Problems und Incidents einander leichter zugeordnet werden können. Dies ist beispielsweise im Rahmen der Incident-Behebung zur Identifizierung von bekannten Fehlern und verfügbaren Workarounds wichtig.

 

Anmerkungen

Basiert auf: Checkliste Problem Record zur YaSM-Prozesslandkarte.

Von:  Stefan Kempter   und  Andrea Kempter , IT Process Maps.

 

Definition  › Inhalte  › Klasse bzw. Kategorie  › Priorisierung  › Workaround  › Zu beachten