Checkliste Incident-Priorität: Unterschied zwischen den Versionen

Aus IT Process Wiki
Keine Bearbeitungszusammenfassung
 
KKeine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
'''ITIL-Prozess''': [[Service Support]] - [[Service Desk and Incident Management]]
<seo metakeywords="incident priorisierung, incident priorisierung itil, incident priorität, major incident, Incident eskalation" metadescription="Richtlinie Incident-Priorisierung: Zuordnung von Prioritäten zu Incidents, Definition von Major Incidents und Incident-Eskalation." />
<imagemap>
Image:ITIL-Wiki-english.jpg|Checkliste Incident Priorität - Vorlage Incident Priorisierung
default [https://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Priority this Page in English]
desc none
</imagemap>
<br style="clear:both;"/>


'''Checklisten-Kategorie''': [[ITIL-Checklisten#Checklisten für Service Desk and Incident Management|Checklisten für Service Desk and Incident Management]]
'''ITIL-Prozess''': [[ITIL V3 Service Operation - Servicebetrieb]] - [[Incident Management]]


'''Checklisten-Kategorie''': [[ITIL-Checklisten#Checklisten ITIL V3 Service Operation (Servicebetrieb)|Checklisten ITIL V3 Service Operation (Servicebetrieb)]]


Die Priorität eines Incidents setzt sich aus den folgenden Angaben zusammen:
'''Quelle''': Checkliste "Richtlinie Incident-Priorisierung" aus der [https://de.it-processmaps.com/produkte/itil-prozesslandkarte.html ITIL-Prozesslandkarte V3]


* Dringlichkeit (verfügbare Zeit bis zur Lösung des Incidents), z.B.
<p>&nbsp;</p>
** 1: bis 0,5 h
 
** 2: bis 2,0 h
Die ''Richtlinie Incident-Priorisierung'' beschreibt die Regeln für die Zuordnung von ''Prioritäten zu Incidents'' und definiert, welche Incidents als ''Major Incidents'' zu behandeln sind. Da die Eskalationsregeln für Incidents in der Regel auf Prioritäten basieren, ist die Zuordnung der richtigen Priorität maßgeblich für die angemessene ''Eskalation von Incidents''.
** 3: bis 6,0 h
 
* Schweregrad (verursachter Schaden für das Unternehmen), z.B.
<p>&nbsp;</p>
** 1: „Hoch“ (Unterbrechung kritischer Unternehmensprozesse)
 
** 2: „Normal“ (Unterbrechung der Arbeit einzelner Mitarbeiter)
'''Die Priorität eines Incidents ergibt sich in der Regel aus der Bewertung von Incident-Auswirkung und Incident-Dringlichkeit, wobei
** 3: „Niedrig“ (Behinderung der Arbeit einzelner Mitarbeiter, Weiterarbeiten mit Umgehungslösung möglich)
* Dringlichkeit ''("Urgency")'' ausdrückt, wie schnell der Incident gelöst werden muss, und
* Priorität (z.B. in Stufen 1, 2 und 3): Ergibt sich aus der Kombination von Dringlichkeit und Schweregrad
* Auswirkung ''("Impact")'' ausdrückt, wie umfangreich der Incident ist und welcher (potentielle) Schaden durch den Incident verursacht werden kann.
 
<p>&nbsp;</p>
 
==== Incident-Dringlichkeit (Dringlichkeits-Kategorien) ====
 
Dieser Abschnitt gibt Dringlichkeits-Kategorien vor. Die Definitionen müssen auf die jeweilige Organisation genau abgestimmt sein, deshalb ist die folgenden Tabelle lediglich ein Beispiel:
 
<p>&nbsp;</p>
 
Um die ''Incident-Dringlichkeit'' zu bestimmen, wähle die höchste zutreffende Kategorie:
 
<p>&nbsp;</p>
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
|-
! width="25%" style="background:#ffcc66;" | Kategorie
! width="75%" style="background:#ffffcc;" | Beschreibung
|-
| valign="top" | '''Hoch (H)'''
|
* Mitarbeiter können ihre Aufgaben nicht erfüllen
* Kunden sind in irgendeiner Weise akuten Nachteilen ausgesetzt
|-
| valign="top" | '''Mittel (M)'''
|
* Mitarbeiter können ihre Aufgaben nicht wie vorgesehen erfüllen
* Kunden erfahren Einschränkungen beim Komfort
|-
| valign="top" | '''Niedrig (N)'''
|
* Mitarbeiter können ihre Aufgaben erfüllen, jedoch nur mit zusätzlichem Aufwand
* Kunden erfahren Einschränkungen beim Komfort, jedoch nur in geringem Umfang
|}
 
<p>&nbsp;</p>
 
==== Incident-Auswirkung (Auswirkungs-Kategorien)====
 
Dieser Abschnitt gibt Auswirkungs-Kategorien vor. Die Definitionen müssen auf die jeweilige Organisation genau abgestimmt sein, deshalb ist die folgenden Tabelle lediglich ein Beispiel:
 
<p>&nbsp;</p>
 
Um die ''Incident-Auswirkung'' zu bestimmen, wähle die höchste zutreffende Kategorie:
 
<p>&nbsp;</p>
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
|-
! width="25%" style="background:#ffcc66;" | Kategorie
! width="75%" style="background:#ffffcc;" | Beschreibung
|-
| valign="top" | '''Hoch (H)'''
|
* Eine große Anzahl von Benutzern ist betroffen
* Eine große Anzahl von Kunden ist betroffen
* Der finanzielle Schaden durch den Incident ist voraussichtlich höher als (zum Beispiel) 10.000 EUR
* Eine Beschädigung der Reputation des Unternehmens in großem Umfang ist wahrscheinlich
* Es besteht Gefahr für Leib und Leben
|-
| valign="top" | '''Mittel (M)'''
|
* Eine mäßige Anzahl von Benutzern ist betroffen
* Eine mäßige Anzahl von Kunden ist betroffen
* Der finanzielle Schaden durch den Incident liegt voraussichtlich zwischen (zum Beispiel) 1.000 EUR und 10.000 EUR
* Eine Beschädigung der Reputation des Unternehmens in mäßigem Umfang ist wahrscheinlich
|-
| valign="top" | '''Niedrig (N)'''
|
* Eine minimale Anzahl von Benutzern ist betroffen
* Eine minimale Anzahl von Kunden ist betroffen
* Der finanzielle Schaden durch den Incident ist voraussichtlich weniger als (zum Beispiel) 1.000 EUR
* Eine Beschädigung der Reputation des Unternehmens ist nur in minimalem Umfang zu erwarten
|}
 
<p>&nbsp;</p>
 
==== Incident-Priorität (Prioritäts-Kategorien) ====
 
Die ''Priorität eines Incidents'' leitet sich aus Dringlichkeit und Auswirkung ab. Wenn, wie oben dargestellt, Klassen zur Bestimmung von Dringlichkeit und Auswirkung definiert sind, kann eine Dringlichkeits-Auswirkungs-Matrix ("Urgency-Impact Matrix") verwendet werden, um Klassen von Prioritäten festzulegen, wie im folgenden Beispiel:
 
<p>&nbsp;</p>
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
|-
!style="background:#ffffff;" colspan="2" rowspan="2"| 
!style="background:#f2f2f2;" colspan="3"| Auswirkung
|-
| H
| M
| N
|-
|rowspan="3" | '''Dringlichkeit'''
|H
| style="background:#e36c0a;" | 1
| style="background:#fabf8f;" | 2
| style="background:#fbd4b4;" | 3
|-
|M
| style="background:#fabf8f;" | 2
| style="background:#fbd4b4;" | 3
| style="background:#fde9d9;" | 4
|-
|N
| style="background:#fbd4b4;" | 3
| style="background:#fde9d9;" | 4
|5
|}
 
<p>&nbsp;</p>
 
{| border="1" cellpadding="5" cellspacing="0" align="center"
|-
!style="background:#f2f2f2;" | Prioritäts-Code
!style="background:#f2f2f2;" | Beschreibung
!style="background:#f2f2f2;" | Reaktionszeit-Vorgabe
!style="background:#f2f2f2;" | Lösungszeit-Vorgabe
|-
| style="background:#e36c0a;" |'''1'''
|Kritisch
|Sofort
|1 Stunde
|-
| style="background:#fabf8f;" |'''2'''
|Hoch
|10 Minuten
|4 Stunden
|-
| style="background:#fbd4b4;" |'''3'''
|Mittel
|1 Stunde
|8 Stunden
|-
| style="background:#fde9d9;" |'''4'''
|Niedrig
|4 Stunden
|24 Stunden
|-
|'''5'''
|Sehr niedrig
|1 Tag
|1 Woche
|}
 
<p>&nbsp;</p>
 
==== Kriterien für die Behandlung eines Incidents als Major Incident ====
 
''Major Incidents'' erfordern die Etablierung eines Major Incident Teams und werden durch den Prozess „Behebung von Major Incidents“ behandelt. Über das oben gezeigte Schema hinaus ist es oft angeraten, zusätzliche und leicht verständliche Indikatoren zur Bestimmung von Major Incidents zu definieren (s. dazu auch die Erläuterungen weiter unten). Beispiele für solche Indikatoren sind:
 
# Bestimmte (Gruppen von) geschäftskritischen Services, Anwendungen oder Infrastruktur-Komponenten sind nicht verfügbar und die voraussichtliche Zeit bis zur Wiederherstellung ist zu lang oder unbekannt (hier ist zu spezifizieren, welche Services, Anwendungen oder Infrastruktur-Komponenten zutreffen)
# Bestimmte (Gruppen von) geschäftskritischen Prozessen ("Vital Business Functions") sind betroffen und die voraussichtliche Zeit bis zur Wiederherstellung der vollständigen Leistungsfähigkeit dieser Prozesse ist übermäßig lang oder unbekannt (hier ist zu spezifizieren, welche geschäftskritischen Prozesse zutreffen)
 
<p>&nbsp;</p>
 
==== Bestimmung von Major Incidents ====
 
Die Bereitstellung klarer Richtlinien zum Bestimmen von Major Incidents ist oft ein schwieriges Unterfangen, aber der 1st Level Support entwickelt zumeist einen "sechsten Sinn" für diese. Im Zweifelsfall ist es auch besser, auf der sicheren Seite zu bleiben.
 
Ein ''Major Incident'' ist durch seine großen Auswirkungen charakterisiert, insbesondere auch auf Kunden. Beispiele hierfür sind:
 
* Die Netzwerkanbindung fällt aus und damit ist die Kommunikation des Unternehmens mit der Außenwelt unterbrochen.
* Ein Web-Server fällt wegen unerwartet hoher Belastung aus, z.B. weil viele Kunden zugreifen, um Tickets zu reservieren; dadurch wird es vielen Kunden unmöglich, Tickets zu erwerben.
* Eine zentrale Datenbank stellt sich als korrupt heraus.
* Mehrere für das Geschäft wichtige Server sind von einem Virus befallen.
* Vertrauliche Informationen zu einer größeren Zahl von Kunden sind in die Öffentlichkeit gelangt.
 
Darüber hinaus sind alle Katastrophenfälle (die von der IT-Service-Continuity-Strategie und unterstützenden ITSCM-Plänen behandelt werden) als Major Incidents zu bewerten. Zu beachten ist auch, dass unkritische Incidents durch Fehler oder zu lange Inaktivität zu Major Incidents werden können.
 
<p>&nbsp;</p>
 
'''Die wichtigsten Eigenschaften, an denen sich Major Incidents erkennen lassen, sind unter anderem:'''
 
* Eine signifikante Anzahl von Kunden bzw. von wichtigen Kundengruppen ist betroffen.
* Die Kosten bzw. aus dem Incident resultierenden Verluste für Kunden und/oder die Service-Organisation sind beträchtlich.
* Die Reputation des Service-Providers wird wahrscheinlich beschädigt.
 
UND
 
* Der Arbeits- und Zeitaufwand zur Lösung des Incidents ist vermutlich groß und es ist sehr wahrscheinlich, dass bestehende Service-Level-Vereinbarungen verletzt werden.
 
Ein Major Incident ist in aller Regel auch mit der Priorität "Kritisch" oder "Hoch" versehen.
 
<p>&nbsp;</p>
<!-- Diese Seite liegt in folgenden Kategorien: -->
[[Kategorie:Checkliste (ITIL)|Incident Priorität]]
[[Kategorie:Incident Management|Incident Priorität]]
<!-- keine Inhalte nach diesem Kommentar! -->

Version vom 23. September 2011, 10:42 Uhr

<seo metakeywords="incident priorisierung, incident priorisierung itil, incident priorität, major incident, Incident eskalation" metadescription="Richtlinie Incident-Priorisierung: Zuordnung von Prioritäten zu Incidents, Definition von Major Incidents und Incident-Eskalation." />

Checkliste Incident Priorität - Vorlage Incident Priorisierung
Checkliste Incident Priorität - Vorlage Incident Priorisierung


ITIL-Prozess: ITIL V3 Service Operation - Servicebetrieb - Incident Management

Checklisten-Kategorie: Checklisten ITIL V3 Service Operation (Servicebetrieb)

Quelle: Checkliste "Richtlinie Incident-Priorisierung" aus der ITIL-Prozesslandkarte V3

 

Die Richtlinie Incident-Priorisierung beschreibt die Regeln für die Zuordnung von Prioritäten zu Incidents und definiert, welche Incidents als Major Incidents zu behandeln sind. Da die Eskalationsregeln für Incidents in der Regel auf Prioritäten basieren, ist die Zuordnung der richtigen Priorität maßgeblich für die angemessene Eskalation von Incidents.

 

Die Priorität eines Incidents ergibt sich in der Regel aus der Bewertung von Incident-Auswirkung und Incident-Dringlichkeit, wobei

  • Dringlichkeit ("Urgency") ausdrückt, wie schnell der Incident gelöst werden muss, und
  • Auswirkung ("Impact") ausdrückt, wie umfangreich der Incident ist und welcher (potentielle) Schaden durch den Incident verursacht werden kann.

 

Incident-Dringlichkeit (Dringlichkeits-Kategorien)

Dieser Abschnitt gibt Dringlichkeits-Kategorien vor. Die Definitionen müssen auf die jeweilige Organisation genau abgestimmt sein, deshalb ist die folgenden Tabelle lediglich ein Beispiel:

 

Um die Incident-Dringlichkeit zu bestimmen, wähle die höchste zutreffende Kategorie:

 

Kategorie Beschreibung
Hoch (H)
  • Mitarbeiter können ihre Aufgaben nicht erfüllen
  • Kunden sind in irgendeiner Weise akuten Nachteilen ausgesetzt
Mittel (M)
  • Mitarbeiter können ihre Aufgaben nicht wie vorgesehen erfüllen
  • Kunden erfahren Einschränkungen beim Komfort
Niedrig (N)
  • Mitarbeiter können ihre Aufgaben erfüllen, jedoch nur mit zusätzlichem Aufwand
  • Kunden erfahren Einschränkungen beim Komfort, jedoch nur in geringem Umfang

 

Incident-Auswirkung (Auswirkungs-Kategorien)

Dieser Abschnitt gibt Auswirkungs-Kategorien vor. Die Definitionen müssen auf die jeweilige Organisation genau abgestimmt sein, deshalb ist die folgenden Tabelle lediglich ein Beispiel:

 

Um die Incident-Auswirkung zu bestimmen, wähle die höchste zutreffende Kategorie:

 

Kategorie Beschreibung
Hoch (H)
  • Eine große Anzahl von Benutzern ist betroffen
  • Eine große Anzahl von Kunden ist betroffen
  • Der finanzielle Schaden durch den Incident ist voraussichtlich höher als (zum Beispiel) 10.000 EUR
  • Eine Beschädigung der Reputation des Unternehmens in großem Umfang ist wahrscheinlich
  • Es besteht Gefahr für Leib und Leben
Mittel (M)
  • Eine mäßige Anzahl von Benutzern ist betroffen
  • Eine mäßige Anzahl von Kunden ist betroffen
  • Der finanzielle Schaden durch den Incident liegt voraussichtlich zwischen (zum Beispiel) 1.000 EUR und 10.000 EUR
  • Eine Beschädigung der Reputation des Unternehmens in mäßigem Umfang ist wahrscheinlich
Niedrig (N)
  • Eine minimale Anzahl von Benutzern ist betroffen
  • Eine minimale Anzahl von Kunden ist betroffen
  • Der finanzielle Schaden durch den Incident ist voraussichtlich weniger als (zum Beispiel) 1.000 EUR
  • Eine Beschädigung der Reputation des Unternehmens ist nur in minimalem Umfang zu erwarten

 

Incident-Priorität (Prioritäts-Kategorien)

Die Priorität eines Incidents leitet sich aus Dringlichkeit und Auswirkung ab. Wenn, wie oben dargestellt, Klassen zur Bestimmung von Dringlichkeit und Auswirkung definiert sind, kann eine Dringlichkeits-Auswirkungs-Matrix ("Urgency-Impact Matrix") verwendet werden, um Klassen von Prioritäten festzulegen, wie im folgenden Beispiel:

 

Auswirkung
H M N
Dringlichkeit H 1 2 3
M 2 3 4
N 3 4 5

 

Prioritäts-Code Beschreibung Reaktionszeit-Vorgabe Lösungszeit-Vorgabe
1 Kritisch Sofort 1 Stunde
2 Hoch 10 Minuten 4 Stunden
3 Mittel 1 Stunde 8 Stunden
4 Niedrig 4 Stunden 24 Stunden
5 Sehr niedrig 1 Tag 1 Woche

 

Kriterien für die Behandlung eines Incidents als Major Incident

Major Incidents erfordern die Etablierung eines Major Incident Teams und werden durch den Prozess „Behebung von Major Incidents“ behandelt. Über das oben gezeigte Schema hinaus ist es oft angeraten, zusätzliche und leicht verständliche Indikatoren zur Bestimmung von Major Incidents zu definieren (s. dazu auch die Erläuterungen weiter unten). Beispiele für solche Indikatoren sind:

  1. Bestimmte (Gruppen von) geschäftskritischen Services, Anwendungen oder Infrastruktur-Komponenten sind nicht verfügbar und die voraussichtliche Zeit bis zur Wiederherstellung ist zu lang oder unbekannt (hier ist zu spezifizieren, welche Services, Anwendungen oder Infrastruktur-Komponenten zutreffen)
  2. Bestimmte (Gruppen von) geschäftskritischen Prozessen ("Vital Business Functions") sind betroffen und die voraussichtliche Zeit bis zur Wiederherstellung der vollständigen Leistungsfähigkeit dieser Prozesse ist übermäßig lang oder unbekannt (hier ist zu spezifizieren, welche geschäftskritischen Prozesse zutreffen)

 

Bestimmung von Major Incidents

Die Bereitstellung klarer Richtlinien zum Bestimmen von Major Incidents ist oft ein schwieriges Unterfangen, aber der 1st Level Support entwickelt zumeist einen "sechsten Sinn" für diese. Im Zweifelsfall ist es auch besser, auf der sicheren Seite zu bleiben.

Ein Major Incident ist durch seine großen Auswirkungen charakterisiert, insbesondere auch auf Kunden. Beispiele hierfür sind:

  • Die Netzwerkanbindung fällt aus und damit ist die Kommunikation des Unternehmens mit der Außenwelt unterbrochen.
  • Ein Web-Server fällt wegen unerwartet hoher Belastung aus, z.B. weil viele Kunden zugreifen, um Tickets zu reservieren; dadurch wird es vielen Kunden unmöglich, Tickets zu erwerben.
  • Eine zentrale Datenbank stellt sich als korrupt heraus.
  • Mehrere für das Geschäft wichtige Server sind von einem Virus befallen.
  • Vertrauliche Informationen zu einer größeren Zahl von Kunden sind in die Öffentlichkeit gelangt.

Darüber hinaus sind alle Katastrophenfälle (die von der IT-Service-Continuity-Strategie und unterstützenden ITSCM-Plänen behandelt werden) als Major Incidents zu bewerten. Zu beachten ist auch, dass unkritische Incidents durch Fehler oder zu lange Inaktivität zu Major Incidents werden können.

 

Die wichtigsten Eigenschaften, an denen sich Major Incidents erkennen lassen, sind unter anderem:

  • Eine signifikante Anzahl von Kunden bzw. von wichtigen Kundengruppen ist betroffen.
  • Die Kosten bzw. aus dem Incident resultierenden Verluste für Kunden und/oder die Service-Organisation sind beträchtlich.
  • Die Reputation des Service-Providers wird wahrscheinlich beschädigt.

UND

  • Der Arbeits- und Zeitaufwand zur Lösung des Incidents ist vermutlich groß und es ist sehr wahrscheinlich, dass bestehende Service-Level-Vereinbarungen verletzt werden.

Ein Major Incident ist in aller Regel auch mit der Priorität "Kritisch" oder "Hoch" versehen.