Jeder Vorfall durchläuft eine Reihe von Phasen, bevor er behoben ist. Er beginnt mit der Meldung eines Problems, durchläuft die Phasen der Diagnose und Behebung und endet, sobald der Dienst wieder vollständig hergestellt ist. Dieser Ablauf wird als Lebenszyklus des Vorfallmanagements bezeichnet.
Das Verständnis dieses Lebenszyklus ist entscheidend für ein effizientes Management von IT-Vorfällen. Er bringt Struktur in einen Prozess, der sonst wie ein ständiger Strom zusammenhangloser Anfragen wirken könnte, und hilft den Teams dabei, sich zu organisieren, Prioritäten zu setzen und einheitlich zu handeln.
In diesem Artikel gehen wir auf jeden Teil des Lebenszyklus des Vorfallmanagements ein, erläutern, warum es sich lohnt, diesen zu formalisieren, und skizzieren die wichtigsten Vorteile, die er für IT-Teams und Unternehmen mit sich bringt.
In diesem Artikel erläutern wir, was der Lebenszyklus des Incident Managements ist, warum er für Ihren IT-Betrieb entscheidend ist und wie Sie ihn mithilfe von Best Practices wie „ “ effektiv umsetzen können. Holen Sie sich also eine Tasse Kaffee, lehnen Sie sich zurück und tauchen Sie mit uns in die Welt des Incident Managements ein – ganz ohne Fachjargon und Verwirrung!
Die wichtigsten Erkenntnisse
- Der Lebenszyklus des Incident Managements ist die durchgängige Abfolge von Schritten, die ein IT-Team durchläuft, um jeden Vorfall zu erkennen, zu protokollieren, zu klassifizieren, zu priorisieren, zu beheben, abzuschließen und nachzubewerten.
- Das Überspringen oder Überstürzen einer Phase – insbesondere der Protokollierung und der Nachbesprechung – führt zu wiederkehrenden Vorfällen, die sich im Laufe der Zeit häufen.
- Jede Phase hat konkrete Eingaben, Ausgaben und Fehlerquellen: Ihr Verständnis macht den Unterschied zwischen einem reaktiven und einem strukturierten Service Desk aus.
- InvGate Service Management automatisiert die fehleranfälligsten Schritte des Lebenszyklus – Kategorisierung, Priorisierung, SLA-Verfolgung und Eskalation – ganz ohne Programmieraufwand.
Was ist der Lebenszyklus des Incident Managements in ITIL?
Der ITIL-Lebenszyklus des Incident-Managements bezieht sich auf die Abfolge von Aktivitäten, die eine Organisation zur Bearbeitung von Incidents von der Erkennung bis zum Abschluss durchführt. Er gibt eine Struktur vor, wie Incidents identifiziert, kategorisiert, priorisiert, gelöst und überprüft werden.
Der Lebenszyklus legt fest, wie der Service Desk diese Situationen erfasst, zur Lösung zuweist und das normale Serviceniveau wiederherstellt.
Bevor wir uns mit den einzelnen Phasen befassen, sollte eine Unterscheidung getroffen werden: Ein Incident ist eine ungeplante Unterbrechung oder Beeinträchtigung eines IT-Service. Ein Problem ist die zugrunde liegende Ursache, die einen oder mehrere Incidents hervorruft. Der hier behandelte Lebenszyklus bezieht sich auf Incidents – also den Kreislauf aus sofortiger Reaktion und Behebung. Das Problemmanagement läuft parallel dazu, oft ausgelöst durch Muster, die bei der Auswertung von Vorfällen entdeckt werden, verfolgt jedoch einen anderen Zeitplan und verfolgt ein anderes Ziel.
Das Verständnis dieser Abgrenzung ist wichtig, da sie den Umfang jeder folgenden Phase definiert.
Recommended reading
Read Article
The Incident Management Process: Step-by-Step Guide
Warum der Vorfall-Lebenszyklus wichtig ist: Was ohne ihn schiefgeht
Wenn Teams ohne einen definierten Incident-Lebenszyklus arbeiten, sind die Folgen vorhersehbar:
- Uneinheitliche Reaktion: Verschiedene Mitarbeiter gehen bei derselben Art von Vorfall unterschiedlich vor, was es unmöglich macht, den Prozess zu verbessern oder verlässliche Erwartungen zu formulieren.
- SLA-Verstöße: Ohne Priorisierungsregeln und Eskalationsauslöser warten Vorfälle mit hoher Auswirkung in derselben Warteschlange wie solche mit geringer Auswirkung.
- Keine verwertbaren Daten: Mangelhafte Protokollierung und informelle Abschlüsse führen dazu, dass das Ticketsystem Aufzeichnungen enthält, die keine aussagekräftige Analyse ermöglichen – MTTR-Werte sind unzuverlässig, Muster bleiben unentdeckt und wiederkehrende Vorfälle werden jedes Mal wie neu behandelt.
- Wiederholte Ausfälle: Ohne Nachbetrachtung nach einem Vorfall wird der Kreislauf nicht geschlossen. Die gleichen Ursachen treten erneut auf, und das Team verbraucht seine Kapazitäten mit der Reaktion statt mit der Prävention.
Ein strukturierter Lebenszyklus beseitigt Vorfälle nicht. Er macht jeden Vorfall zu einer Chance, den nächsten zu reduzieren.
7 Schritte im ITIL-Vorfallslebenszyklus
Lassen Sie uns die einzelnen Phasen des ITIL-Lebenszyklus für das Störungsmanagement nacheinander durchgehen. Der Prozess wird oft als Ablauf dargestellt, der mit der Meldung einer Störung beginnt und endet, wenn diese nach Bestätigung durch den Benutzer abgeschlossen wird.
1. Erkennung und Identifizierung
Der erste Schritt im ITIL-Inzident-Lebenszyklus ist die Identifizierung. Hier wird der Inzident erkannt und gemeldet.
Die Erkennung erfolgt über drei Hauptkanäle:
- Automatisierte Überwachungsmeldungen: Das System meldet Anomalien, noch bevor die Benutzer sie bemerken – beispielsweise bei einem Anstieg der Server-Antwortzeiten, wenn ein Dienst nicht mehr erreichbar ist oder wenn die Fehlerquote einen Schwellenwert überschreitet.
- Benutzermeldungen: Ein Benutzer reicht ein Ticket ein oder ruft den Helpdesk an, weil etwas nicht funktioniert.
- Direkte IT-Beobachtung: Ein Teammitglied bemerkt ein Problem bei Routinekontrollen oder während der Bearbeitung einer damit zusammenhängenden Aufgabe.
Eine proaktive Erkennung durch Überwachung ist einer reaktiven Erkennung durch Benutzermeldungen stets vorzuziehen. Wenn Benutzer ein Problem melden, hat der Vorfall sie meist bereits seit einiger Zeit beeinträchtigt.
Zu dieser Phase gehört auch die Überprüfung, ob es sich bei dem Ermittelten tatsächlich um einen Vorfall – also eine ungeplante Dienstunterbrechung – handelt und nicht um eine Serviceanfrage, die einem anderen Workflow folgt.
2. Protokollierung
Ein unvollständiges Ticket ist ein Risiko. Wenn Mitarbeiter mit der Untersuchung eines Vorfalls beginnen, ohne über ausreichende Informationen zu verfügen – wer ihn gemeldet hat, welcher Dienst betroffen ist, wann er begonnen hat, wie viele Nutzer betroffen sind –, verbringen sie den ersten Teil ihrer Diagnosezeit damit, Daten zu sammeln, die bereits bei der Erfassung hätten erfasst werden sollen.
Jedes Vorfall-Ticket sollte mindestens folgende Angaben enthalten:
- Wer hat den Vorfall gemeldet und auf welchem Weg (Portal, Telefon, E-Mail, automatische Benachrichtigung)
- Welcher Dienst oder welche Ressource betroffen ist
- Eine Beschreibung der Symptome (nicht nur „es funktioniert nicht“ – sondern was genau nicht funktioniert)
- Zeitpunkt des ersten Auftretens oder der ersten Meldung
- Vorläufige Einschätzung der Auswirkungen (ein Benutzer, ein Team, eine Abteilung oder das gesamte Unternehmen)
Konsistenz ist ebenso wichtig wie Vollständigkeit. Tickets, in denen für denselben Problemtyp unterschiedliche Begriffe verwendet werden, lassen sich nicht zu aussagekräftigen Berichten zusammenfassen. Wenn ein Mitarbeiter einen VPN-Ausfall als „Netzwerkverbindung“ und ein anderer als „Fernzugriff“ erfasst, werden die Daten fragmentiert. Eine gute Protokollierungsdisziplin in Phase 2 ist die Grundlage für die Zuverlässigkeit aller nachfolgenden Phasen – von der Kategorisierung bis zur Analyse nach dem Vorfall.
3. Kategorisierung
Die Kategorisierung erfolgt bei der Ticketerstellung. Die Kategorien, die Benutzer im Serviceportal auswählen, die von ihnen ausgefüllten Formulare sowie die Struktur des Servicekatalogs beeinflussen alle, wie Vorfälle ab dem Zeitpunkt ihrer Erfassung im System klassifiziert werden.
Aus diesem Grund hängt eine effektive Kategorisierung ebenso sehr von der Servicegestaltung ab wie von den Entscheidungen der Mitarbeiter. Ein gut strukturiertes Portal leitet die Benutzer zum richtigen Service oder Problemtyp weiter und sorgt so für eine zuverlässigere Weiterleitung und Berichterstellung. Sind die Kategorien schlecht konzipiert, verbringen die Mitarbeiter Zeit damit, Tickets neu zu klassifizieren, und die Berichtsdaten verlieren mit der Zeit an Aussagekraft.
Das Ziel besteht darin, Kategorien zu erstellen, die detailliert genug sind, um die Weiterleitung und Trendanalyse zu unterstützen, ohne dabei so granular zu sein, dass Nutzer und Mitarbeiter sie uneinheitlich anwenden. Kategorien wie „Hardware > Drucker“, „Software > E-Mail“ oder „Netzwerk > VPN“ bieten genügend Kontext, um Vorfälle an die richtige Supportgruppe weiterzuleiten und gleichzeitig aussagekräftige Berichte zu erstellen.
Eine genaue Kategorisierung unterstützt mehr als nur die Ticketzuweisung. Sie hilft Service-Desk-Managern dabei, wiederkehrende Probleme zu identifizieren, Vorfalltrends zu analysieren und Vorfälle mit Aktivitäten des Problemmanagements zu verknüpfen. Wenn Teams Vorfälle einheitlich auf dieselbe Weise kategorisieren, werden historische Daten zu einer zuverlässigen Quelle für die Ermittlung von Grundursachen und Möglichkeiten zur Serviceverbesserung.
Mit InvGate Service Management: Administratoren können Servicekataloge, Formulare und Portal-Kategorien entwerfen, die Benutzer von Anfang an zur richtigen Klassifizierung führen. Automatisierte Weiterleitungsregeln können diese Kategorien dann nutzen, um Vorfälle ohne manuellen Eingriff dem entsprechenden Team zuzuweisen.
4. Priorisierung
Nicht alle Vorfälle sind gleich, und sie so zu behandeln, als wären sie es, ist eine der häufigsten Ursachen für die Nichteinhaltung von SLAs. Wenn Teams eine Warteschlange nach Eingangsreihenfolge statt nach Auswirkung abarbeiten, warten kritische Vorfälle hinter solchen mit geringer Auswirkung, SLAs für Vorgänge mit hoher Priorität werden nicht eingehalten, und Dringlichkeit verliert ihre Bedeutung.
ITIL definiert Priorität als das Produkt zweier Variablen:
- Dringlichkeit: Wie schnell muss das Problem behoben werden? Nimmt die Auswirkung mit der Zeit zu?
- Auswirkung: Wie viele Nutzer, Prozesse oder Geschäftsfunktionen sind betroffen?
In der Praxis lässt sich dies in eine Prioritätsmatrix umsetzen: ein Raster, das Kombinationen aus Dringlichkeit und Auswirkung vordefinierten Prioritätsstufen (P1 bis P4 oder Kritisch/Hoch/Mittel/Niedrig) zuordnet, wobei jede Stufe ein entsprechendes SLA-Ziel hat.
DasITIL-Prioritätsmatrix-Handbuch „ “ setzt dieses Modell in die Praxis um – es definiert, was jede Zelle der Matrix hinsichtlich Reaktionszeit, Eskalation und Kommunikationsanforderungen bedeutet. Eng damit verbunden ist die Frage nachden Schweregraden von Vorfällen ( ), die manche Organisationen als parallele Dimension zur Priorität verwalten, insbesondere bei größeren Vorfällen.
Die Priorität muss für alle sichtbar sein, die an der Warteschlange arbeiten – nicht nur für den zugewiesenen Mitarbeiter. Teams, die die relative Priorität über das gesamte Vorfall-Dashboard hinweg einsehen können, treffen bessere Entscheidungen darüber, wer welche Aufgaben übernimmt, ohne auf manuelle Koordination angewiesen zu sein.
5. Untersuchung, Diagnose und Lösung
Dies ist die Phase, in der die eigentliche Arbeit zur Behebung des Vorfalls stattfindet – doch wie effizient sie abläuft, hängt fast ausschließlich von der Qualität aller vorangegangenen Schritte ab.
Tier-1-Mitarbeiter befolgen in der Regel eine festgelegte Abfolge von Erstmaßnahmen, bevor sie den Vorfall eskalieren: Sie überprüfen die Wissensdatenbank auf dokumentierte Lösungen oder Workarounds, führen grundlegende Schritte zur Fehlerbehebung durch und stellen fest, ob das Problem isoliert auftritt oder mehrere Benutzer betrifft. Kann Tier 1 das Problem nicht innerhalb einer festgelegten Zeitspanne beheben, wird der Vorfall an Tier 2 oder Tier 3 eskaliert.
In dieser Phase sind zwei Unterscheidungen von Bedeutung:
- Workaround vs. Lösung: Ein Workaround stellt den Dienst vorübergehend wieder her (Neustart eines Servers, Umleitung des Datenverkehrs auf ein Backup-System), behebt jedoch nicht die zugrunde liegende Ursache. Eine Lösung beseitigt die Ursache. Im Ticket sollte dokumentiert werden, welche der beiden Maßnahmen angewendet wurde.
- Funktionale Eskalation vs. hierarchische Eskalation: Bei einer funktionalen Eskalation wird das Ticket an ein Team weitergeleitet, das über das erforderliche technische Fachwissen verfügt, um den Vorfall zu bearbeiten. Eine hierarchische Eskalation bezieht das Management ein, wenn die Auswirkungen, die Dauer oder die Sichtbarkeit dies rechtfertigen.
Asset-Daten spielen hier eine wichtige unterstützende Rolle. Zu wissen, welches Konfigurationselement betroffen ist – einschließlich seiner Historie, der jüngsten Änderungen und seiner Abhängigkeiten – beschleunigt die Ermittlung der Grundursache oft erheblich.
Mit InvGate Service Management: Die integrierte Wissensdatenbank ermöglicht es den Mitarbeitern, auf frühere Fälle und dokumentierte Lösungen zuzugreifen, ohne die Ticket-Oberfläche verlassen zu müssen, wodurch sich der Zeitaufwand für bereits gelöste Probleme verringert. Automatische Eskalationsregeln leiten das Ticket an die nächste Ebene weiter, wenn vor Ablauf der konfigurierten SLA-Frist keine Aktivität stattfindet. So wird sichergestellt, dass die Zeit, die auf der falschen Ebene verbracht wird, nicht unbemerkt das Zeitfenster für die Lösung schmälert.
Die Plattform ist zudem mit den Asset-Daten aus InvGate Asset Management integriert und zeigt die Historie der betroffenen CI direkt im Ticket an – eine entscheidende Information für eine schnellere Diagnose. Hier zeigen sich auch dieautomatisierten Funktionendes Incident-Management- s von am deutlichsten in Bezug auf die Lösungsgeschwindigkeit.
Recommended reading
Read Article
Ticket Escalation: What is it And How to Automate it in Your Help Desk
6. Abschluss
Das Schließen eines Tickets klingt nach einer administrativen Formalität. Das ist es jedoch nicht. Die Art und Weise, wie ein Vorfall geschlossen wird, bestimmt die Qualität der dabei generierten Daten – und diese Daten bilden die Grundlage für die gesamte Berichtsebene des Vorfallmanagements.
Ein formeller Abschluss erfordert:
- Eine Bestätigung des Nutzers, dass der Dienst zu seiner Zufriedenheit wiederhergestellt wurde, oder ein Timeout-Protokoll (wenn der Nutzer nicht innerhalb von N Tagen reagiert, wird das Ticket nach vorheriger Benachrichtigung automatisch geschlossen)
- Dokumentation der Lösung: Was wurde unternommen, handelte es sich um eine Übergangslösung oder eine dauerhafte Behebung, und was war die Ursache des Vorfalls?
- Beurteilung, ob ein Problem-Eintrag angelegt werden sollte: Handeltees sich bei der Lösungum eine Übergangslösung oder ist dieser Vorfall Teil eines wiederkehrenden Musters, sollte dies das Problemmanagement auslösen
- Genauigkeit der Zeitstempel: Das System sollte sowohl den Zeitpunkt der Lösung als auch den Zeitpunkt des formellen Abschlusses erfassen, da diese Daten direkt in die Kennzahlen des Vorfallmanagements einfließen, wie z. B. in die Berechnungen der MTTR und der SLA-Einhaltung
7. Nachbetrachtung nach dem Vorfall
Die Nachbesprechung ist die Phase, die – wenn sie formalisiert wird – den größten langfristigen Nutzen bringen kann, da hier die in allen vorangegangenen Phasen gesammelten Lebenszyklusdaten zu verwertbaren Erkenntnissen werden.
Wann sollte eine Nachbesprechung nach einem Vorfall durchgeführt werden:
- Obligatorisch bei jedem schwerwiegenden Vorfall
- Empfohlen bei Vorfällen, die zu einer SLA-Verletzung geführt haben
- Empfohlen bei wiederkehrenden Vorfällen – wenn dieselbe Art von Problem innerhalb eines festgelegten Zeitraums drei oder mehr Mal auftritt
Was eine gute Überprüfung beantwortet:
- Wann hat der Vorfall tatsächlich begonnen und wann wurde er erstmals erkannt? (Erkennungslücke)
- In welcher Phase hat das Team die meiste Zeit verbracht? Wo kam es zu Verzögerungen im Prozess?
- War die Priorisierung korrekt, oder wurde der Vorfall im Verhältnis zu seinen tatsächlichen Auswirkungen über- oder unterpriorisiert?
- War die Lösung dauerhaft, oder wurde eine Notlösung angewendet, die das zugrunde liegende Problem ungelöst ließ?
- Gibt es ein Muster – bei diesem Vorfall und ähnlichen Fällen –, das die Eröffnung eines Problem-Eintrags rechtfertigt?
Es lohnt sich, Unterscheidung zwischen einer Nachbetrachtung eines Vorfalls und einer Ursachenanalyse. Eine Nachbesprechung nach einem Vorfall ist prozessorientiert: Sie untersucht, wie das Team den Vorfall über den gesamten Lebenszyklus hinweg bewältigt hat. Eine Ursachenanalyse (RCA) ist technisch ausgerichtet: Sie untersucht, was den Ausfall im zugrunde liegenden System verursacht hat. Beide sind wertvoll, beantworten jedoch unterschiedliche Fragen. Die Nachbesprechung nach einem Vorfall führt oft zu einer Ursachenanalyse, doch es handelt sich nicht um dasselbe Verfahren.
Die Ergebnisse einer Nachbesprechung fließen direkt in das System zurück: Artikel in der Wissensdatenbank werden aktualisiert, Kategorietaxonomien verfeinert, Workflow-Regeln angepasst und, falls erforderlich, wird ein Problem-Eintrag angelegt, um die zugrunde liegende Ursache bis zur Behebung zu verfolgen.
So verwalten Sie den Lebenszyklus von Vorfällen mit InvGate Service Management
Die Verwaltung des Lebenszyklus von Vorfällen über voneinander getrennte Tools hinweg bringt eigene Probleme mit sich. Wenn die Erkennung in einem Überwachungstool erfolgt, die Protokollierung in einemTicketingsystem, das Wissen in einem separaten Wiki gespeichert wird und die Metriken in einer Tabellenkalkulation vorliegen, wird der Lebenszyklus zwar technisch verfolgt, ist aber in der Praxis fragmentiert. Übergaben zwischen den Phasen führen zu Verzögerungen, der Kontext geht zwischen den Systemen verloren, und die fürdie Nachbetrachtung des Vorfallsbenötigten Datenlassen sich nie sauber zusammenführen.
Die Abwicklung des gesamten Lebenszyklus auf einer einheitlichen Plattform verändert die Betriebsdynamik. InvGate Service Management unterstützt den Lebenszyklus durchgängig als ein einziges System:
- Workflow-Automatisierung ohne Programmieraufwand: Jeder Phasenübergang – Zuweisung, Eskalation, Kategorisierung, SLA-Timer, Abschluss – lässt sich durch konfigurierbare Regeln automatisieren, die keine Entwicklungsarbeit erfordern. Dadurch werden die fehleranfälligsten manuellen Schritte aus dem Prozess entfernt.
- SLA-Verfolgung: SLA-Timer laufen automatisch ab dem Zeitpunkt der Ticket-Erstellung. Eskalationsregeln werden ausgelöst, bevor ein Verstoß auftritt, nicht erst danach, sodass Teams Zeit haben, zu reagieren, anstatt nur noch Abhilfe zu schaffen.
- Zentrale Wissensdatenbank: Mitarbeiter greifen direkt über die Ticket-Oberfläche auf dokumentierte Lösungen und Workarounds zu, ohne in ein externes System wechseln zu müssen.
- KI zur Erkennung schwerwiegender Vorfälle: Die Plattform kann Gruppen verwandter Tickets aufzeigen, die auf einen potenziellen schwerwiegenden Vorfall hindeuten, sodass Teams proaktiv eskalieren können, bevor sich die Auswirkungen auf die Nutzer häufen.
- Dashboards zur Lebenszyklus-Performance: Vorfallvolumen, MTTR, SLA-Einhaltung und Eskalationsmuster sind in Echtzeit verfügbar und bilden die Datengrundlage, die die Nachbetrachtung von Vorfällen substanziell statt nur retrospektiv macht.
- Integration von Asset-Daten: Bei Anbindung von InvGate Asset Management wird das von einem Vorfall betroffene Konfigurationselement direkt im Ticket angezeigt – einschließlich seines Verlaufs und der letzten Änderungen –, was die Diagnose in Stufe 5 beschleunigt.
Das Ergebnis ist ein Lebenszyklus, in dem die Phasen miteinander verknüpft sind: Bei der Protokollierung erfasste Daten stehen bei der Diagnose zur Verfügung, die bei der Priorisierung festgelegte SLA-Logik gilt bis zum Abschluss, und die bei der Nachbesprechung nach dem Vorfall angezeigten Kennzahlen spiegeln wider, was in jeder Phase tatsächlich geschehen ist.
Möchten Sie erfahren, wie InvGate Service Management Ihren Lebenszyklus im Vorfallmanagement unterstützt?Die Plattform ist von PeopleCert für ITIL-Best-Practices zertifiziert, einschließlich des Vorfallmanagements. Starten Sie jetzt Ihre kostenlose 30-Tage-Testversion!
Häufige Fehler in den einzelnen Phasen (und wie man sie vermeidet)
Selbst Unternehmen mit einem dokumentierten Incident-Management-Prozess machen immer wieder Fehler. Die meisten Vorfälle werden letztendlich behoben, doch kleine Pannen bei der Erkennung, Triage, Untersuchung oder dem Abschluss führen oft zu längeren Lösungszeiträumen, unnötigen Eskalationen und wiederkehrenden Problemen.
Häufig gestellte Fragen
Welche Phasen umfasst der Lebenszyklus des Vorfallmanagements?
Der Lebenszyklus des Vorfallmanagements umfasst sieben Phasen: Erkennung und Identifizierung, Protokollierung und Aufzeichnung, Klassifizierung und Kategorisierung, Priorisierung, Untersuchung und Behebung, Abschluss sowie Nachbetrachtung. Jede Phase liefert Input für die nächste, und die abschließende Nachbetrachtungsphase fließt in die Prozessverbesserung für zukünftige Vorfälle ein.
Was ist der Unterschied zwischen dem Lebenszyklus des Vorfallmanagements und dem Vorfallmanagementprozess?
Der Lebenszyklus definiert , was in jeder Phasegeschieht – also die Abfolge der Aktivitäten von der Erkennung bis zur Nachbetrachtung. Der Prozess definiert , wie diese Aktivitäten durchgeführt werden – also die Verfahren, Rollen, Verantwortlichkeiten und Werkzeuge, die in jeder Phase zum Einsatz kommen. Der Lebenszyklus ist das Rahmenwerk; der Prozess ist die operative Umsetzung.
Wann sollten Sie eine Nachbesprechung nach einem Vorfall durchführen?
Eine Nachbesprechung ist nach jedem schwerwiegenden Vorfall obligatorisch. Sie wird außerdem dringend empfohlen nach Vorfällen, die zu einer SLA-Verletzung geführt haben oder die einem wiederkehrenden Muster entsprechen – also wenn dieselbe Problemkategorie innerhalb eines definierten Zeitraums mehrfach auftritt. Bei der Nachbesprechung wird der Prozess (die Art und Weise, wie der Vorfall bewältigt wurde) untersucht, nicht nur die technische Ursache.
Wie definiert ITIL die Priorität im Vorfallmanagement?
ITIL berechnet die Priorität als Funktion aus Dringlichkeit (wie schnell das Problem behoben werden muss) und Auswirkung (wie viele Benutzer oder Geschäftsprozesse betroffen sind). Aus dieser Kombination ergibt sich eine Prioritätsstufe – in der Regel P1 bis P4 –, für die jeweils definierte Zielwerte für Reaktions- und Lösungszeiten gelten. In der Praxis wird dies über eine Prioritätsmatrix umgesetzt, die Kombinationen aus Dringlichkeit und Auswirkung bestimmten SLA-Anforderungen zuordnet.
