LP4.7: Lösen von Problemen: Unterschied zwischen den Versionen
Aus YaSM Service-Management-Wiki
Andrea (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Andrea (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 101: | Zeile 101: | ||
==Prozess-Outputs== | ==Prozess-Outputs== | ||
<html><!-- define schema.org/ | <html><!-- define schema.org/DefinedTermSet --> | ||
<div itemid="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen# | <div itemid="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen#prozess-inputs-outputs" itemscope="itemscope" itemtype="https://schema.org/DefinedTermSet"> | ||
<link itemprop="additionalType" href="http://www.productontology.org/id/Input/output" /> | |||
<meta itemprop="name" content="YaSM-Prozess LP4.7: Dokumente und Records" /> | <meta itemprop="name" content="YaSM-Prozess LP4.7: Dokumente und Records" /> | ||
<meta itemprop="alternateName" content="Problem-Management Prozess-Outputs" /> | <meta itemprop="alternateName" content="Problem-Management Prozess-Outputs" /> | ||
| Zeile 109: | Zeile 110: | ||
<p> </p> | <p> </p> | ||
<dl><dt>Incident-Modell</dt> | <dl> | ||
<dd>Incident-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Incident-Typ. Incident-Modelle dienen dem Zweck, wiederkehrende Incidents effektiv und effizient zu bearbeiten. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Incident-Modell</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">Incident-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Incident-Typ. Incident-Modelle dienen dem Zweck, wiederkehrende Incidents effektiv und effizient zu bearbeiten. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | ||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Problem-Record">Problem Record</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
<dd>Ein Service-Betriebshandbuch spezifiziert die Aktivitäten, die für den Betrieb eines Service und der darunter liegenden Infrastruktur erforderlich sind. Die Informationen im Service-Betriebshandbuch sollen die im Tagesgeschäft anfallenden Aufgaben auf eine für das Betriebspersonal nützliche Weise beschreiben. Einige Anweisungen für den Betrieb bestimmter Anwendungen, Systeme oder Infrastruktur-Komponenten können in separaten technischen Handbüchern oder Standardarbeitsanweisungen ('Standard Operating Procedures, SOP') dokumentiert werden. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Service-Betriebshandbuch</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">Ein Service-Betriebshandbuch spezifiziert die Aktivitäten, die für den Betrieb eines Service und der darunter liegenden Infrastruktur erforderlich sind. Die Informationen im Service-Betriebshandbuch sollen die im Tagesgeschäft anfallenden Aufgaben auf eine für das Betriebspersonal nützliche Weise beschreiben. Einige Anweisungen für den Betrieb bestimmter Anwendungen, Systeme oder Infrastruktur-Komponenten können in separaten technischen Handbüchern oder Standardarbeitsanweisungen ('Standard Operating Procedures, SOP') dokumentiert werden. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
<dd>Eine Anforderung zur Unterstützung bei der Behebung eines Incidents oder Problems. Eine solche Anforderung wird üblicherweise vom Incident- oder Problem-Manager gestellt, wenn weitere technische Expertise für die Behebung von Incidents oder Problems erforderlich ist.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Support-Anfrage</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">Eine Anforderung zur Unterstützung bei der Behebung eines Incidents oder Problems. Eine solche Anforderung wird üblicherweise vom Incident- oder Problem-Manager gestellt, wenn weitere technische Expertise für die Behebung von Incidents oder Problems erforderlich ist.</dd></div> | |||
<dd>Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Vorschlag zur Prozess-Änderung</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.</dd></div> | |||
<dd>Ein Vorschlag zur Änderung eines Service, z.B. zur Verbesserung der Qualität oder Wirtschaftlichkeit des Services. Solche Vorschläge können an jeder Stelle innerhalb oder außerhalb der Service-Provider-Organisation entstehen.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Vorschlag zur Service-Änderung</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">Ein Vorschlag zur Änderung eines Service, z.B. zur Verbesserung der Qualität oder Wirtschaftlichkeit des Services. Solche Vorschläge können an jeder Stelle innerhalb oder außerhalb der Service-Provider-Organisation entstehen.</dd></div> | |||
<dd>Wiederherstellungspläne (Recovery-Pläne) enthalten genaue Anweisungen zu den Maßnahmen, mit denen bestimmte Services und/ oder Systeme nach einem Ausfall wieder hergestellt werden können, was in vielen Fällen auch die Wiederherstellung von Daten zu einem definierten, konsistenten Stand mit einschließt. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
</div><!-- end of schema.org/ | <dt itemprop="name">Wiederherstellungs-Plan</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">Wiederherstellungspläne (Recovery-Pläne) enthalten genaue Anweisungen zu den Maßnahmen, mit denen bestimmte Services und/ oder Systeme nach einem Ausfall wieder hergestellt werden können, was in vielen Fällen auch die Wiederherstellung von Daten zu einem definierten, konsistenten Stand mit einschließt. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
</dl> | |||
</div><!-- end of schema.org/DefinedTermSet --><p> | |||
<p> </p> | <p> </p> | ||
| Zeile 263: | Zeile 267: | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen#LP4.7.4"> | <link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen#LP4.7.4"> | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen#LP4.7.5"> | <link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen#LP4.7.5"> | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen# | <link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP4.7:_L%C3%B6sen_von_Problemen#prozess-inputs-outputs"> | ||
<link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess/Loesen-von-problemen-yasm-lp4-7.jpg" /> | <link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess/Loesen-von-problemen-yasm-lp4-7.jpg" /> | ||
<link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess-definition/was-ist-problem-management-prozess.jpg" /> | <link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess-definition/was-ist-problem-management-prozess.jpg" /> | ||
Version vom 25. Januar 2021, 16:24 Uhr
Prozessname: Lösen von Problemen - Teil von: Service-Lifecycle-Prozesse - Betreiben der Services
Vorhergehender Prozess: Lösen von Incidents und Service Requests
Prozess-Beschreibung
Der Problem-Management-Prozess in YaSM (Abb. 1) sorgt für die Verwaltung aller Probleme über ihren gesamten Lebenszyklus, wobei ein Problem die einem oder mehreren (potentiellen) Incidents zugrundeliegende Ursache ist. Die primäre Aufgabe des Problemlösungsprozesses ist, dem Auftreten von Service Incidents vorzubeugen und die Auswirkungen von Incidents, die nicht verhindert werden können, minimal zu halten.
Kompatibilität: YaSM Problem-Management ist kompatibel mit ISO 20000, dem internationalen Service-Management-Standard (vgl. ISO/IEC 20000-1:2018, Abschnitt 8.6) und eignet sich zur Umsetzung der Practice 'ITIL 4 Problem Management'.
Sub-Prozesse
YaSM's Problem-Management-Prozess beinhaltet die folgenden Sub-Prozesse:
- LP4.7.1: Proaktives Identifizieren von Problemen
- Prozessziel: Die generelle Verfügbarkeit von Services zu verbessern, indem Probleme proaktiv identifiziert werden. Dieser Prozess zielt darauf ab, Probleme zu ermitteln und/ oder Workarounds bereitzustellen, bevor (weitere) Service Incidents auftreten.
- LP4.7.2: Kategorisieren und Priorisieren von Problemen
- Prozessziel: Aufzeichnen und Priorisieren von Problemen mit angemessener Sorgfalt, um eine rasche und effektive Lösung zu ermöglichen.
- LP4.7.3: Analysieren und Lösen von Problemen
- Prozessziel: Identifizieren der zugrundeliegenden Ursachen von Problemen und Bestimmen der zweckdienlichsten und wirtschaftlichsten Problemlösung. Sofern möglich, sollte ein vorläufiger Workaround zur Verfügung gestellt, werden, solange noch keine vollständige Lösung verfügbar ist.
- LP4.7.4: Überwachen offener Probleme
- Prozessziel: Fortwährend offene Problems in Hinsicht auf ihren Implementierungs-Status überwachen, und - falls erforderlich - korrigierende Maßnahmen einleiten.
- LP4.7.5: Schließen von Problemen
- Prozessziel: Sicherstellen, dass die Problemlösung erfolgreich war, und dass alle relevanten Informationen aktuell sind.
Prozess-Outputs
Die folgenden Dokumente und Records werden vom Problem-Management-Prozess erzeugt. YaSM-Datenobjekte [*] sind mit einem Sternsymbol markiert, und andere Objekte werden in grau dargestellt.
- Incident-Modell
- Incident-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Incident-Typ. Incident-Modelle dienen dem Zweck, wiederkehrende Incidents effektiv und effizient zu bearbeiten. [*]
- Problem Record
- 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. [*]
- Service-Betriebshandbuch
- Ein Service-Betriebshandbuch spezifiziert die Aktivitäten, die für den Betrieb eines Service und der darunter liegenden Infrastruktur erforderlich sind. Die Informationen im Service-Betriebshandbuch sollen die im Tagesgeschäft anfallenden Aufgaben auf eine für das Betriebspersonal nützliche Weise beschreiben. Einige Anweisungen für den Betrieb bestimmter Anwendungen, Systeme oder Infrastruktur-Komponenten können in separaten technischen Handbüchern oder Standardarbeitsanweisungen ('Standard Operating Procedures, SOP') dokumentiert werden. [*]
- Support-Anfrage
- Eine Anforderung zur Unterstützung bei der Behebung eines Incidents oder Problems. Eine solche Anforderung wird üblicherweise vom Incident- oder Problem-Manager gestellt, wenn weitere technische Expertise für die Behebung von Incidents oder Problems erforderlich ist.
- Vorschlag zur Prozess-Änderung
- Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.
- Vorschlag zur Service-Änderung
- Ein Vorschlag zur Änderung eines Service, z.B. zur Verbesserung der Qualität oder Wirtschaftlichkeit des Services. Solche Vorschläge können an jeder Stelle innerhalb oder außerhalb der Service-Provider-Organisation entstehen.
- Wiederherstellungs-Plan
- Wiederherstellungspläne (Recovery-Pläne) enthalten genaue Anweisungen zu den Maßnahmen, mit denen bestimmte Services und/ oder Systeme nach einem Ausfall wieder hergestellt werden können, was in vielen Fällen auch die Wiederherstellung von Daten zu einem definierten, konsistenten Stand mit einschließt. [*]
[*] "YaSM-Datenobjekte" sind Dokumente und Records, für die YaSM detaillierte Empfehlungen bereithält: Für jedes YaSM-Objekt gibt es eine Checkliste (siehe Beispiel), die die typischen Inhalte beschreibt, und ein Lifecycle-Diagramm, das darstellt, wie sich der Zustand des Objekts ändert, während es von verschiedenen YaSM-Prozessen erstellt, geändert, gelesen und archiviert wird (siehe Beispiel).
"Andere Objekte" sind eher informelle Daten oder Informationen. Es gibt aus diesem Grund keine zugehörigen Lifecycle-Diagramme oder Checklisten.
Prozess-Kennzahlen
Prozesskennzahlen werden benötigt, wenn gemessen werden soll, ob die Service-Management-Prozesse "zufriedenstellend" laufen.
Vorschläge zu geeigneten Prozess-Kennzahlen entnehmen Sie der Liste von Kennzahlen zum Problemlösungs-Prozess.
Rollen und Verantwortlichkeiten
Prozess-Owner: Problem-Manager
- Der Problem-Manager ist dafür verantwortlich, alle Probleme über ihren gesamten Lebenszyklus zu verwalten, wobei das vorrangige Ziel darin besteht, der Entstehung von Incidents möglichst vorzubeugen und die negativen Auswirkungen von Incidents, die nicht verhindert werden können, gering zu halten. Abgesehen von der Lösung zugrundeliegender Ursachen von (potentiellen) Incidents stellt der Problem-Manager oft auch Workarounds (Umgehungslösungen) zur Verfügung, solange noch keine endgültige Lösung existiert.
| YaSM-Rolle / Sub-Prozess | Problem-Manager | Service-Owner | Techn. Fachexperte | |
|---|---|---|---|---|
| LP4.7.1 | Proaktives Identifizieren von Problemen | AR | - | - |
| LP4.7.2 | Kategorisieren und Priorisieren von Problemen | AR | - | - |
| LP4.7.3 | Analysieren und Lösen von Problemen | AR | R | R |
| LP4.7.4 | Überwachen offener Probleme | AR | - | - |
| LP4.7.5 | Schließen von Problemen | AR | - | - |
Anmerkungen
Basiert auf: Der Problem-Management-Prozess aus der YaSM-Prozesslandkarte.
Von: Stefan Kempter 
und Andrea Kempter , IT Process Maps.
Themenverwandte Artikel
von: Stefan Kempter
Die Betriebsprozesse - insbesondere Incident Management und Problem Management - sind wahrscheinlich die bekanntesten (und in der Praxis am häufigsten umgesetzten) ITSM-Prozesse. [...]
Prozess-Beschreibung › Sub-Prozesse › Prozess-Outputs › Kennzahlen › Rollen
