Service-Management-Checklisten: Unterschied zwischen den Versionen

Aus YaSM Service-Management-Wiki
Keine Bearbeitungszusammenfassung
Keine Bearbeitungszusammenfassung
Zeile 5: Zeile 5:
<meta property="og:title" content="YaSM-Checklisten | YaSM Service-Management-Wiki" />
<meta property="og:title" content="YaSM-Checklisten | YaSM Service-Management-Wiki" />
<meta property="og:description" content="Checklisten ('YaSM-Dokumentvorlagen') enthalten detaillierte Erläuterungen der verschiedenen Dokumente und Records ('Datenobjekte'), die von den YaSM-Prozessen erzeugt werden." />
<meta property="og:description" content="Checklisten ('YaSM-Dokumentvorlagen') enthalten detaillierte Erläuterungen der verschiedenen Dokumente und Records ('Datenobjekte'), die von den YaSM-Prozessen erzeugt werden." />
<meta property="og:site_name" content="YaSM">
<meta property="og:site_name" content="YaSM Service Management">
<meta property="og:type" content="article" />
<meta property="og:type" content="article" />
<meta property="fb:admins" content="100002035253209" />
<meta property="fb:admins" content="100002035253209" />
Zeile 14: Zeile 14:
<link href="https://plus.google.com/100916307096177053362/posts" rel="publisher" />
<link href="https://plus.google.com/100916307096177053362/posts" rel="publisher" />
</itpmch>
</itpmch>
<html><div class="floatright"><div class="noresize"><map name="ImageMap_yasm-wiki-teilen"><area href="https://www.linkedin.com/shareArticle?url=https%3A%2F%2Fyasm.com%2Fwiki%2Fde%2Findex.php%2FYaSM-Checklisten&hl=de_DE&source=YaSM-Wiki" class="plainlinks" rel="nofollow" shape="rect" coords="55,0,99,36" alt="diese Seite auf LinkedIn teilen" title="diese Seite auf LinkedIn teilen"/><area href="https://twitter.com/intent/tweet?url=https%3A%2F%2Fyasm.com%2Fwiki%2Fde%2Findex.php%2FYaSM-Checklisten&text=%23YaSMwiki%20%7C%20YaSM-Checklisten%20-%20Beispiel%3A%20Checkliste%20Incident%20Record%0A%E2%96%BA&lang=de&via=yasmcom" class="plainlinks" rel="nofollow" shape="rect" coords="97,0,140,36" alt="diese Seite auf Twitter teilen" title="diese Seite auf Twitter teilen"/></map><img alt="diese Seite teilen" src="https://yasm.com/wiki/de/img/yasm-wiki/YaSM-Wiki-teilen.png" width="140" height="36" usemap="#ImageMap_yasm-wiki-teilen"/></div></div>
<html><div class="noresize"><a href="https://yasm.com/wiki/en/index.php/Service_Management_Checklists"><img src="https://yasm.com/wiki/de/img/yasm-wiki/YaSM-Wiki-English.png" width="140" height="36" style="float:right;" alt="in English" title="This page in English" /></a></div><br style="clear:both;"/>
<div class="noresize"><a href="https://yasm.com/wiki/en/index.php/YaSM_Checklists"><img src="https://yasm.com/wiki/de/img/yasm-wiki/YaSM-Wiki-English.png" width="140" height="36" style="float:left;" alt="in English" title="This page in English" /></a></div><br style="clear:both;"/>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p><span id="md-webpage-description" itemprop="description">YaSM-Checklisten ('YaSM-Dokumentvorlagen') enthalten detaillierte Erläuterungen der verschiedenen Dokumente und Records ('Datenobjekte'), die in den <a href="https://yasm.com/wiki/de/index.php/YaSM-Prozesse" title="YaSM Service-Management-Prozesse">Service-Management-Prozessen</a> erzeugt werden.</span>
<p><span id="md-webpage-description" itemprop="description">YaSM-Checklisten ('YaSM-Dokumentvorlagen') enthalten detaillierte Erläuterungen der verschiedenen Dokumente und Records ('Datenobjekte'), die in den <a href="https://yasm.com/wiki/de/index.php/YaSM-Prozesse" title="YaSM Service-Management-Prozesse">Service-Management-Prozessen</a> erzeugt werden.</span>
Zeile 28: Zeile 27:
Da die Checklisten Microsoft-Word&trade;-Dokumente sind, können sie in vielen Fällen als Vorlagen oder Templates genutzt werden, wenn bestimmte Service-Management-Dokumente erstellt werden müssen.
Da die Checklisten Microsoft-Word&trade;-Dokumente sind, können sie in vielen Fällen als Vorlagen oder Templates genutzt werden, wenn bestimmte Service-Management-Dokumente erstellt werden müssen.


Die [https://yasm.com/de/produkte/yasm-prozesslandkarte YaSM&reg;-Prozesslandkarte] enthält 75 Checklisten, eine für jedes <i>YaSM-Datenobjekt</i>. Zusätzlich gibt es 19 Checklisten für die <i>Service-Management-Richtlinien</i>.
Die [https://yasm.com/de/produkte/yasm-prozesslandkarte YaSM&reg;-Prozesslandkarte] enthält 76 Checklisten, eine für jedes <i>YaSM-Datenobjekt</i>. Zusätzlich gibt es 19 Checklisten für die <i>Service-Management-Richtlinien</i>.
 
<p>&nbsp;</p>


==<span id="yasm-checkliste-beispiel">Beispiel: YaSM-Checkliste "Incident Record"</span>==
==<span id="yasm-checkliste-beispiel">Beispiel: YaSM-Checkliste "Incident Record"</span>==
Zeile 36: Zeile 33:
<html><p><b>Checkliste/ Dokument-Vorlage:</b> <span id="checkliste-incident-record">Incident Record</span></p>
<html><p><b>Checkliste/ Dokument-Vorlage:</b> <span id="checkliste-incident-record">Incident Record</span></p>
<p><b>Verbundener YaSM-Prozess</b>: <a href="https://yasm.com/wiki/de/index.php/LP4.6:_L%C3%B6sen_von_Incidents_und_Service_Requests" title="Prozess-Beschreibung: LP4.6: Lösen von Incidents und Service Requests">LP4.6: Lösen von Incidents und Service Requests</a></html>
<p><b>Verbundener YaSM-Prozess</b>: <a href="https://yasm.com/wiki/de/index.php/LP4.6:_L%C3%B6sen_von_Incidents_und_Service_Requests" title="Prozess-Beschreibung: LP4.6: Lösen von Incidents und Service Requests">LP4.6: Lösen von Incidents und Service Requests</a></html>
<p>&nbsp;</p>


===<span id="incident-record-definition">Incident Record: Definition</span>===
===<span id="incident-record-definition">Incident Record: Definition</span>===
Zeile 44: Zeile 39:
<html><div itemscope itemtype="https://schema.org/ImageObject">
<html><div itemscope itemtype="https://schema.org/ImageObject">
<a href="https://yasm.com/wiki/de/img/yasm-checklisten/Yasm-checklisten-dokument-vorlagen.jpg" title="YaSM-Checkliste/ Dokument-Vorlage | Incident Record." itemprop="contentUrl">
<a href="https://yasm.com/wiki/de/img/yasm-checklisten/Yasm-checklisten-dokument-vorlagen.jpg" title="YaSM-Checkliste/ Dokument-Vorlage | Incident Record." itemprop="contentUrl">
<img style="margin:5px 0px 30px 30px; float:right;" src="https://yasm.com/wiki/de/img/yasm-checklisten/Yasm-checklisten-dokument-vorlagen.jpg" width="442" height="687" title="YaSM-Checkliste/ Dokument-Vorlage | Incident Record" alt="YaSM-Dokument-Vorlagen und Checklisten. - Beispiel: Incident Record Template." />
<img style="margin:5px 0px 20px 20px; float:right;" src="https://yasm.com/wiki/de/img/yasm-checklisten/Yasm-checklisten-dokument-vorlagen.jpg" width="442" height="687" title="YaSM-Checkliste/ Dokument-Vorlage | Incident Record" alt="YaSM-Dokument-Vorlagen und Checklisten. - Beispiel: Incident Record Template." />
<meta itemprop="caption" content="YaSM-Checkliste/ Dokument-Vorlage | Incident Record" />
<meta itemprop="caption" content="YaSM-Checkliste/ Dokument-Vorlage | Incident Record" />
<meta itemprop="width" content="442" />
<meta itemprop="width" content="442" />
Zeile 51: Zeile 46:
<meta itemprop="keywords" content="Checkliste Incident Record" /></a></div>
<meta itemprop="keywords" content="Checkliste Incident Record" /></a></div>


<p>Ein <i>Incident Record</i> ist ein Datensatz mit allen Angaben zu einem Incident, in dem der Lebenszyklus des Incidents von der Ersterfassung bis zur Lösung dokumentiert ist. Ein <i>Incident</i> ist definiert als ungeplante Unterbrechung oder Qualitätsminderung eines IT-Services. Auch ein Ereignis, das in der Zukunft einen IT-Service beeinträchtigen könnte, ist ein Incident (z.B. der Ausfall einer Festplatte in einem RAID-Verbund).<p></html>
<p style="word-wrap:normal;">Ein&nbsp;<i>Incident&nbsp;Record</i> ist ein Datensatz mit allen Angaben zu einem Incident, in dem der Lebenszyklus des Incidents von der Ersterfassung bis zur Lösung dokumentiert ist. Ein <i>Incident</i> ist definiert als ungeplante Unterbrechung oder Qualitäts&shy;minderung eines IT-Services. Auch ein Ereignis, das in der Zukunft einen IT-Service beeinträchtigen könnte, ist ein Incident (z.B. der Ausfall einer Festplatte in einem RAID-Verbund).<p><br style="clear:both;"/></html>
 
<p>&nbsp;</p>


===<span id="inhalte-incident-record">Typische Inhalte eines Incident Records</span>===
===<span id="inhalte-incident-record">Typische Inhalte eines Incident Records</span>===
Zeile 64: Zeile 57:
<p><b><span itemprop="itemListElement">Eindeutige Incident-ID</span></b></p>
<p><b><span itemprop="itemListElement">Eindeutige Incident-ID</span></b></p>
<ul><li itemprop="description">In der Regel wird die ID automatisch von der Anwendung vergeben, die zum Managen der Incidents verwendet wird.</li></ul>
<ul><li itemprop="description">In der Regel wird die ID automatisch von der Anwendung vergeben, die zum Managen der Incidents verwendet wird.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Status des Incidents</span></b></p>
<p><b><span itemprop="itemListElement">Status des Incidents</span></b></p>
<ul><li itemprop="description">Statuswerte können beispielsweise sein: "Gemeldet", "Offen", "Behoben", "Abgeschlossen" usw.</li></ul>
<ul><li itemprop="description">Statuswerte können beispielsweise sein: "Gemeldet", "Offen", "Behoben", "Abgeschlossen" usw.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Erfassung des Incidents</span></b></p>
<p><b><span itemprop="itemListElement">Erfassung des Incidents</span></b></p>
<ul><li itemprop="description">Datum und Zeitpunkt der Erfassung des Incident.</li></ul>
<ul><li itemprop="description">Datum und Zeitpunkt der Erfassung des Incident.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Auftreten des Incidents</span></b></p>
<p><b><span itemprop="itemListElement">Auftreten des Incidents</span></b></p>
<ul><li itemprop="description">Datum und Zeitpunkt, wann der Incident aufgetreten ist.</li></ul>
<ul><li itemprop="description">Datum und Zeitpunkt, wann der Incident aufgetreten ist.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Art der Benachrichtigung</span></b></p>
<p><b><span itemprop="itemListElement">Art der Benachrichtigung</span></b></p>
<ul><li itemprop="description">Z.B. per Telefon, E-Mail, Intranet-Portal, Event-Überwachungs-System.</li></ul>
<ul><li itemprop="description">Z.B. per Telefon, E-Mail, Intranet-Portal, Event-Überwachungs-System.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Kontaktdaten</span></b></p>
<p><b><span itemprop="itemListElement">Kontaktdaten</span></b></p>
<ul><li itemprop="description">Kontaktdaten des Melders/Anwenders und Kommunikationsweg für Rückmeldungen.</li></ul>
<ul><li itemprop="description">Kontaktdaten des Melders/Anwenders und Kommunikationsweg für Rückmeldungen.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Angaben zur Berechtigung</span></b></p>
<p><b><span itemprop="itemListElement">Angaben zur Berechtigung</span></b></p>
<ul><li itemprop="description">Gegebenenfalls Angaben darüber, wie festgestellt wurde, dass der Anfordernde die Berechtigung hat, den Incident zu melden.</li></ul>
<ul><li itemprop="description">Gegebenenfalls Angaben darüber, wie festgestellt wurde, dass der Anfordernde die Berechtigung hat, den Incident zu melden.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Incident-Verantwortlicher (Incident-Owner)</span></b></p>
<p><b><span itemprop="itemListElement">Incident-Verantwortlicher (Incident-Owner)</span></b></p>
<ul><li itemprop="description">Der Incident-Verantwortliche trägt die Gesamtverantwortung für die Behebung des Incidents, selbst wenn dieser im Verlauf seines Lebenszyklus anderen Support-Mitarbeitern oder -Teams  zur Durchführung bestimmter Aufgaben übertragen wird.</li></ul>
<ul><li itemprop="description">Der Incident-Verantwortliche trägt die Gesamtverantwortung für die Behebung des Incidents, selbst wenn dieser im Verlauf seines Lebenszyklus anderen Support-Mitarbeitern oder -Teams  zur Durchführung bestimmter Aufgaben übertragen wird.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Zuordnung</span></b></p>
<p><b><span itemprop="itemListElement">Zuordnung</span></b></p>
<ul><li itemprop="description">Mitarbeiter oder Support-Team, dem der Incident zugeordnet ist. Der Incident kann im Verlauf seines Lebenszyklus unterschiedlichen Personen oder Teams zugewiesen werden.</li></ul>
<ul><li itemprop="description">Mitarbeiter oder Support-Team, dem der Incident zugeordnet ist. Der Incident kann im Verlauf seines Lebenszyklus unterschiedlichen Personen oder Teams zugewiesen werden.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Incident-Klassifizierung</span></b></p>
<p><b><span itemprop="itemListElement">Incident-Klassifizierung</span></b></p>
<ul><li itemprop="description">Die Klassifizierung von Incidents ist eine Möglichkeit, Incidents in Kategorien einzuteilen. Dies erleichtert zum einen ihre Zuordnung zu den richtigen Support-Mitarbeitern bzw. -Teams und zum anderen die Erstellung von Statistiken sowie die Analyse aufgetretener Incidents.</li></ul>
<ul><li itemprop="description">Die Klassifizierung von Incidents ist eine Möglichkeit, Incidents in Kategorien einzuteilen. Dies erleichtert zum einen ihre Zuordnung zu den richtigen Support-Mitarbeitern bzw. -Teams und zum anderen die Erstellung von Statistiken sowie die Analyse aufgetretener Incidents.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Incident-Kategorisierung</span></b></p>
<p><b><span itemprop="itemListElement">Incident-Kategorisierung</span></b></p>
<ul><li itemprop="description">Das verwendete Klassifikationsschema kann je nach Organisation unterschiedlich sein, aber oft werden Incidents z.B. nach folgenden Kriterien klassifiziert: <br>&bull; betroffene(r) Service(s) <br>&bull; betroffene(r) Kunde(n) <br>&bull; betroffene(r) Standort(e) <br>&bull; betroffene Infrastruktur-Komponente(n) und Sub-Komponente(n) (d.h. Konfigurationselemente) <br>&bull; Art von Symptom (z.B. "Hardware-Fehler", "Software-Fehler", "verminderte Leistung", "Sicherheitsproblem" usw.).</li></ul>
<ul><li itemprop="description">Das verwendete Klassifikationsschema kann je nach Organisation unterschiedlich sein, aber oft werden Incidents z.B. nach folgenden Kriterien klassifiziert: <br>&bull; betroffene(r) Service(s) <br>&bull; betroffene(r) Kunde(n) <br>&bull; betroffene(r) Standort(e) <br>&bull; betroffene Infrastruktur-Komponente(n) und Sub-Komponente(n) (d.h. Konfigurationselemente) <br>&bull; Art von Symptom (z.B. "Hardware-Fehler", "Software-Fehler", "verminderte Leistung", "Sicherheitsproblem" usw.).</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Symptome</span></b></p>
<p><b><span itemprop="itemListElement">Symptome</span></b></p>
<ul><li itemprop="description">Symptom-Beschreibung.</li></ul>
<ul><li itemprop="description">Symptom-Beschreibung.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Priorität</span></b></p>
<p><b><span itemprop="itemListElement">Priorität</span></b></p>
<ul><li itemprop="description">Die Priorität wird häufig durch Prioritäts-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 <br>&bull; Dringlichkeit die verfügbare Zeit bis zur Lösung des Problems und<br> &bull; Auswirkung den (potentiellen) Schaden für das Unternehmen ausdrückt.<br>Ein Beispiel für ein Priorisierungsschema finden Sie in der Checkliste "Incident und Service-Request-Richtlinie".<br>Für wiederholt auftretende Incidents sind die Priorisierungsregeln üblicherweise in den entsprechenden Incident-Modellen beschrieben bzw. konfiguriert.</li></ul>
<ul><li itemprop="description">Die Priorität wird häufig durch Prioritäts-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 <br>&bull; Dringlichkeit die verfügbare Zeit bis zur Lösung des Problems und<br> &bull; Auswirkung den (potentiellen) Schaden für das Unternehmen ausdrückt.<br>Ein Beispiel für ein Priorisierungsschema finden Sie in der Checkliste "Incident und Service-Request-Richtlinie".<br>Für wiederholt auftretende Incidents sind die Priorisierungsregeln üblicherweise in den entsprechenden Incident-Modellen beschrieben bzw. konfiguriert.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Kennzeichnung als Major (d.h. schwerwiegender) Incident</span></b></p>
<p><b><span itemprop="itemListElement">Kennzeichnung als Major (d.h. schwerwiegender) Incident</span></b></p>
<ul><li itemprop="description">Diese Kennzeichnung gibt an, dass ein Incident als Major Incident behandelt wird.</li></ul>
<ul><li itemprop="description">Diese Kennzeichnung gibt an, dass ein Incident als Major Incident behandelt wird.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Zeitvorgabe für die Behebung des Incidents</span></b></p>
<p><b><span itemprop="itemListElement">Zeitvorgabe für die Behebung des Incidents</span></b></p>
<ul><li itemprop="description">Dies ist die vorgegebene Zeitspanne, die zur Lösung des Incidents gemäß Zusagen in den entsprechenden Service-Definitionen und -Vereinbarungen zur Verfügung steht. Soll-Lösungszeiten werden in der Regel anhand der Priorität des Incidents festgelegt.</li></ul>
<ul><li itemprop="description">Dies ist die vorgegebene Zeitspanne, die zur Lösung des Incidents gemäß Zusagen in den entsprechenden Service-Definitionen und -Vereinbarungen zur Verfügung steht. Soll-Lösungszeiten werden in der Regel anhand der Priorität des Incidents festgelegt.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Incident-Modell(e)</span></b></p>
<p><b><span itemprop="itemListElement">Incident-Modell(e)</span></b></p>
<ul><li itemprop="description">Anwendbare(s) Incident-Modell(e).</li></ul>
<ul><li itemprop="description">Anwendbare(s) Incident-Modell(e).</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Links to related incident records</span></b></p>
<p><b><span itemprop="itemListElement">Links to related incident records</span></b></p>
<ul><li itemprop="description">If similar outstanding incidents exist to which the new incident can be attributed in this case, one incident is usually declared the "master incident".</li></ul>
<ul><li itemprop="description">If similar outstanding incidents exist to which the new incident can be attributed in this case, one incident is usually declared the "master incident".</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Links zu relevanten Event Records</span></b></p>
<p><b><span itemprop="itemListElement">Links zu relevanten Event Records</span></b></p>
<ul><li itemprop="description">Falls der Incident auf einem Event beruht, der von einem Monitoring-System gemeldet worden ist.</li></ul>
<ul><li itemprop="description">Falls der Incident auf einem Event beruht, der von einem Monitoring-System gemeldet worden ist.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Links zu relevanten Problem Records</span></b></p>
<p><b><span itemprop="itemListElement">Links zu relevanten Problem Records</span></b></p>
<ul><li itemprop="description">Falls es Problems gibt, die mit dem vorliegenden Incident zusammenhängen; insbesondere kann ein Problem Record einen geeigneten Workaround enthalten.</li></ul>
<ul><li itemprop="description">Falls es Problems gibt, die mit dem vorliegenden Incident zusammenhängen; insbesondere kann ein Problem Record einen geeigneten Workaround enthalten.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Links zu relevanten Change Records</span></b></p>
<p><b><span itemprop="itemListElement">Links zu relevanten Change Records</span></b></p>
<ul><li itemprop="description">Falls während der Lösung des Incidents Requests for Change eingereicht wurden.<br>&bull; Falls der Incident mit einem (kürzlich implementierten) Change in Zusammenhang steht.</li></ul>
<ul><li itemprop="description">Falls während der Lösung des Incidents Requests for Change eingereicht wurden.<br>&bull; Falls der Incident mit einem (kürzlich implementierten) Change in Zusammenhang steht.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Funktionale Eskalationen</span></b></p>
<p><b><span itemprop="itemListElement">Funktionale Eskalationen</span></b></p>
<ul><li itemprop="description">Funktionale Eskalationen (Weiterleitungen des Incidents an bestimmte Support-Mitarbeiter oder Teams von Spezialisten) müssen aufgezeichnet werden.</li></ul>
<ul><li itemprop="description">Funktionale Eskalationen (Weiterleitungen des Incidents an bestimmte Support-Mitarbeiter oder Teams von Spezialisten) müssen aufgezeichnet werden.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Hierarchische Eskalationen</span></b></p>
<p><b><span itemprop="itemListElement">Hierarchische Eskalationen</span></b></p>
<ul><li itemprop="description">Incidents mit hoher Priorität oder solche, die innerhalb der vereinbarten Zeit nicht behoben werden konnten, lösen in der Regel hierarchische Eskalationen aus, zum Beispiel an das oberste Management. Solche Eskalationen müssen aufgezeichnet werden.</li></ul>
<ul><li itemprop="description">Incidents mit hoher Priorität oder solche, die innerhalb der vereinbarten Zeit nicht behoben werden konnten, lösen in der Regel hierarchische Eskalationen aus, zum Beispiel an das oberste Management. Solche Eskalationen müssen aufgezeichnet werden.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Statusänderungen</span></b></p>
<p><b><span itemprop="itemListElement">Statusänderungen</span></b></p>
<ul><li itemprop="description">In diesem Abschnitt sind Statusänderungen bei den Incidents zu vermerken (zum Beispiel von "Offen" auf "Gelöst").</li></ul>
<ul><li itemprop="description">In diesem Abschnitt sind Statusänderungen bei den Incidents zu vermerken (zum Beispiel von "Offen" auf "Gelöst").</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Aktivitätsprotokoll/ Aufgabenliste</span></b></p>
<p><b><span itemprop="itemListElement">Aktivitätsprotokoll/ Aufgabenliste</span></b></p>
<ul><li itemprop="description">In den meisten Systemen zum Managen von Incidents ist es möglich, die zur Behebung des Incidents unternommenen Schritte in einem einfachen Protokoll aufzuzeichnen. Manche Systeme bieten auch die Möglichkeit, den Incidents "Aufgaben" zuzuweisen. Ähnlich den Incidents, 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.</li></ul>
<ul><li itemprop="description">In den meisten Systemen zum Managen von Incidents ist es möglich, die zur Behebung des Incidents unternommenen Schritte in einem einfachen Protokoll aufzuzeichnen. Manche Systeme bieten auch die Möglichkeit, den Incidents "Aufgaben" zuzuweisen. Ähnlich den Incidents, 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.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Abschluss des Incidents</span></b></p>
<p><b><span itemprop="itemListElement">Abschluss des Incidents</span></b></p>
<ul><li itemprop="description">Angaben zum Abschluss des Incidents.</li></ul>
<ul><li itemprop="description">Angaben zum Abschluss des Incidents.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Art der Lösung</span></b></p>
<p><b><span itemprop="itemListElement">Art der Lösung</span></b></p>
<ul><li itemprop="description">Beseitigung der zugrundeliegenden Ursache oder Anwendung eines Workarounds. Falls der Incident mittels eines Workarounds behoben wurde, Angabe des verwendeten Workarounds.</li></ul>
<ul><li itemprop="description">Beseitigung der zugrundeliegenden Ursache oder Anwendung eines Workarounds. Falls der Incident mittels eines Workarounds behoben wurde, Angabe des verwendeten Workarounds.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Erstellte Problems</span></b></p>
<p><b><span itemprop="itemListElement">Erstellte Problems</span></b></p>
<ul><li itemprop="description">Ein Problem Record ist beispielsweise zu erstellen,<br>&bull; falls zu erwarten ist, dass der Incident erneut auftritt, so dass vorbeugende Maßnahmen notwendig sind<br>&bull; falls der Incident nicht vollständig verstanden wurde<br>&bull; falls ein neuer Workaround während der Incident-Behebung entwickelt wurde.</li></ul>
<ul><li itemprop="description">Ein Problem Record ist beispielsweise zu erstellen,<br>&bull; falls zu erwarten ist, dass der Incident erneut auftritt, so dass vorbeugende Maßnahmen notwendig sind<br>&bull; falls der Incident nicht vollständig verstanden wurde<br>&bull; falls ein neuer Workaround während der Incident-Behebung entwickelt wurde.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Kunden-Feedback</span></b></p>
<p><b><span itemprop="itemListElement">Kunden-Feedback</span></b></p>
<ul><li itemprop="description">Bestätigung seitens des Kunden oder Nutzers, dass der Incident behoben wurde; gegebenenfalls Ergebnisse einer Zufriedenheitsumfrage.</li></ul>
<ul><li itemprop="description">Bestätigung seitens des Kunden oder Nutzers, dass der Incident behoben wurde; gegebenenfalls Ergebnisse einer Zufriedenheitsumfrage.</li></ul>
<p><br></p>
<p><b><span itemprop="itemListElement">Zusatzinformationen</span></b></p>
<p><b><span itemprop="itemListElement">Zusatzinformationen</span></b></p>
<ul><li itemprop="description">Anmerkungen und Zusatzinformationen.</li></ul>
<ul><li itemprop="description">Anmerkungen und Zusatzinformationen.</li></ul>
</div><!-- end of schema.org/ItemList --><p></html>
</div><!-- end of schema.org/ItemList --><p></html>
<p>&nbsp;</p>


===Zu beachten===
===Zu beachten===
Zeile 186: Zeile 149:
   <meta itemprop="isBasedOnUrl" content="https://yasm.com/de/produkte/yasm-prozesslandkarte" />
   <meta itemprop="isBasedOnUrl" content="https://yasm.com/de/produkte/yasm-prozesslandkarte" />
   <meta itemprop="inLanguage" content="de" />
   <meta itemprop="inLanguage" content="de" />
   <link  itemprop="citation" href="https://yasm.com/wiki/en/index.php/YaSM_Checklists" />
   <link  itemprop="citation" href="https://yasm.com/wiki/en/index.php/Service_Management_Checklists" />
   <link itemprop="publisher" href="https://yasm.com/de/#YaSMBrand" />
   <link itemprop="publisher" href="https://yasm.com/de/#YaSMBrand" />
   <link itemprop="copyrightHolder creator" href="https://yasm.com/de/kontakt#ITProcessMapsOrg" />
   <link itemprop="copyrightHolder creator" href="https://yasm.com/de/kontakt#ITProcessMapsOrg" />

Version vom 15. Mai 2019, 10:48 Uhr

in English


 

YaSM-Checklisten ('YaSM-Dokumentvorlagen') enthalten detaillierte Erläuterungen der verschiedenen Dokumente und Records ('Datenobjekte'), die in den Service-Management-Prozessen erzeugt werden.

Auf dieser Seite: Beispiel - Checkliste Incident Record

 

YaSM-Dokument-Vorlagen

Jede Checkliste beschreibt die typischen Inhalte eines YaSM-Dokuments oder -Records, wie im folgenden Beispiel, der Checkliste Incident Record gezeigt wird.

Da die Checklisten Microsoft-Word™-Dokumente sind, können sie in vielen Fällen als Vorlagen oder Templates genutzt werden, wenn bestimmte Service-Management-Dokumente erstellt werden müssen.

Die YaSM®-Prozesslandkarte enthält 76 Checklisten, eine für jedes YaSM-Datenobjekt. Zusätzlich gibt es 19 Checklisten für die Service-Management-Richtlinien.

Beispiel: YaSM-Checkliste "Incident Record"

Checkliste/ Dokument-Vorlage: Incident Record

Verbundener YaSM-Prozess: LP4.6: Lösen von Incidents und Service Requests

Incident Record: Definition


Ein Incident Record ist ein Datensatz mit allen Angaben zu einem Incident, in dem der Lebenszyklus des Incidents von der Ersterfassung bis zur Lösung dokumentiert ist. Ein Incident ist definiert als ungeplante Unterbrechung oder Qualitäts­minderung eines IT-Services. Auch ein Ereignis, das in der Zukunft einen IT-Service beeinträchtigen könnte, ist ein Incident (z.B. der Ausfall einer Festplatte in einem RAID-Verbund).


Typische Inhalte eines Incident Records


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

 

Eindeutige Incident-ID

  • In der Regel wird die ID automatisch von der Anwendung vergeben, die zum Managen der Incidents verwendet wird.

Status des Incidents

  • Statuswerte können beispielsweise sein: "Gemeldet", "Offen", "Behoben", "Abgeschlossen" usw.

Erfassung des Incidents

  • Datum und Zeitpunkt der Erfassung des Incident.

Auftreten des Incidents

  • Datum und Zeitpunkt, wann der Incident aufgetreten ist.

Art der Benachrichtigung

  • Z.B. per Telefon, E-Mail, Intranet-Portal, Event-Überwachungs-System.

Kontaktdaten

  • Kontaktdaten des Melders/Anwenders und Kommunikationsweg für Rückmeldungen.

Angaben zur Berechtigung

  • Gegebenenfalls Angaben darüber, wie festgestellt wurde, dass der Anfordernde die Berechtigung hat, den Incident zu melden.

Incident-Verantwortlicher (Incident-Owner)

  • Der Incident-Verantwortliche trägt die Gesamtverantwortung für die Behebung des Incidents, selbst wenn dieser im Verlauf seines Lebenszyklus anderen Support-Mitarbeitern oder -Teams zur Durchführung bestimmter Aufgaben übertragen wird.

Zuordnung

  • Mitarbeiter oder Support-Team, dem der Incident zugeordnet ist. Der Incident kann im Verlauf seines Lebenszyklus unterschiedlichen Personen oder Teams zugewiesen werden.

Incident-Klassifizierung

  • Die Klassifizierung von Incidents ist eine Möglichkeit, Incidents in Kategorien einzuteilen. Dies erleichtert zum einen ihre Zuordnung zu den richtigen Support-Mitarbeitern bzw. -Teams und zum anderen die Erstellung von Statistiken sowie die Analyse aufgetretener Incidents.

Incident-Kategorisierung

  • Das verwendete Klassifikationsschema kann je nach Organisation unterschiedlich sein, aber oft werden Incidents z.B. nach folgenden Kriterien klassifiziert:
    • betroffene(r) Service(s)
    • betroffene(r) Kunde(n)
    • betroffene(r) Standort(e)
    • betroffene Infrastruktur-Komponente(n) und Sub-Komponente(n) (d.h. Konfigurationselemente)
    • Art von Symptom (z.B. "Hardware-Fehler", "Software-Fehler", "verminderte Leistung", "Sicherheitsproblem" usw.).

Symptome

  • Symptom-Beschreibung.

Priorität

  • Die Priorität wird häufig durch Prioritäts-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.
    Ein Beispiel für ein Priorisierungsschema finden Sie in der Checkliste "Incident und Service-Request-Richtlinie".
    Für wiederholt auftretende Incidents sind die Priorisierungsregeln üblicherweise in den entsprechenden Incident-Modellen beschrieben bzw. konfiguriert.

Kennzeichnung als Major (d.h. schwerwiegender) Incident

  • Diese Kennzeichnung gibt an, dass ein Incident als Major Incident behandelt wird.

Zeitvorgabe für die Behebung des Incidents

  • Dies ist die vorgegebene Zeitspanne, die zur Lösung des Incidents gemäß Zusagen in den entsprechenden Service-Definitionen und -Vereinbarungen zur Verfügung steht. Soll-Lösungszeiten werden in der Regel anhand der Priorität des Incidents festgelegt.

Incident-Modell(e)

  • Anwendbare(s) Incident-Modell(e).

Links to related incident records

  • If similar outstanding incidents exist to which the new incident can be attributed in this case, one incident is usually declared the "master incident".

Links zu relevanten Event Records

  • Falls der Incident auf einem Event beruht, der von einem Monitoring-System gemeldet worden ist.

Links zu relevanten Problem Records

  • Falls es Problems gibt, die mit dem vorliegenden Incident zusammenhängen; insbesondere kann ein Problem Record einen geeigneten Workaround enthalten.

Links zu relevanten Change Records

  • Falls während der Lösung des Incidents Requests for Change eingereicht wurden.
    • Falls der Incident mit einem (kürzlich implementierten) Change in Zusammenhang steht.

Funktionale Eskalationen

  • Funktionale Eskalationen (Weiterleitungen des Incidents an bestimmte Support-Mitarbeiter oder Teams von Spezialisten) müssen aufgezeichnet werden.

Hierarchische Eskalationen

  • Incidents mit hoher Priorität oder solche, die innerhalb der vereinbarten Zeit nicht behoben werden konnten, lösen in der Regel hierarchische Eskalationen aus, zum Beispiel an das oberste Management. Solche Eskalationen müssen aufgezeichnet werden.

Statusänderungen

  • In diesem Abschnitt sind Statusänderungen bei den Incidents zu vermerken (zum Beispiel von "Offen" auf "Gelöst").

Aktivitätsprotokoll/ Aufgabenliste

  • In den meisten Systemen zum Managen von Incidents ist es möglich, die zur Behebung des Incidents unternommenen Schritte in einem einfachen Protokoll aufzuzeichnen. Manche Systeme bieten auch die Möglichkeit, den Incidents "Aufgaben" zuzuweisen. Ähnlich den Incidents, 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.

Abschluss des Incidents

  • Angaben zum Abschluss des Incidents.

Art der Lösung

  • Beseitigung der zugrundeliegenden Ursache oder Anwendung eines Workarounds. Falls der Incident mittels eines Workarounds behoben wurde, Angabe des verwendeten Workarounds.

Erstellte Problems

  • Ein Problem Record ist beispielsweise zu erstellen,
    • falls zu erwarten ist, dass der Incident erneut auftritt, so dass vorbeugende Maßnahmen notwendig sind
    • falls der Incident nicht vollständig verstanden wurde
    • falls ein neuer Workaround während der Incident-Behebung entwickelt wurde.

Kunden-Feedback

  • Bestätigung seitens des Kunden oder Nutzers, dass der Incident behoben wurde; gegebenenfalls Ergebnisse einer Zufriedenheitsumfrage.

Zusatzinformationen

  • Anmerkungen und Zusatzinformationen.

Zu beachten


  • Für bestimmte Typen von wiederholt auftretenden Incidents beschreiben Incident-Modelle, wie diese Incidents zu beheben sind. In vielen Fällen wird die Handhabung solcher Incidents von entsprechend konfigurierten Tools unterstützt (zum Beispiel kann es Schnellverfahren zur leichten Erstellung bestimmter Typen von Incident Records geben).
  • 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 Incident Record zur YaSM-Prozesslandkarte.

Von:  Stefan Kempter Autor: Stefan Kempter, IT Process Maps GbR  und  Andrea Kempter Koautor: Andrea Kempter, IT Process Maps GbR, IT Process Maps.

 

YaSM-Dokumentvorlagen  › Beispiel: YaSM-Checkliste 'Incident Record'