Was ist ein Incident?

Ich möchte gern eine kleine ‚Was ist…?‘ Serie starten und die erste Frage lautet: Was ist ein Incident?

Viele Organisationen sind in der Vergangenheit mit ITIL gestartet und haben zu Beginn den operativen Betrieb sortiert. Im Ergebnis dieser Initiativen lässt sich häufig ein Service Desk als Single Point of Contact (SPOC) und ein Incident Management Prozess identifizieren. Etwas weniger häufig aber auch regelmäßig sind Problem und Change Management Prozesse sowie Einstiegspunkte in Configuration Management und Request Fulfillment verfügbar.

Was ist ein Incident?

Ein Incident ist eine Beeinträchtigung oder Unterbrechung eines angebotenen Services. Eine Beeinträchtigung liegt dann vor, wenn der Service nach der Vereinbarung zwischen Servicegeber und Servicenehmer (SLA) quantitativ oder qualitativ nicht wie vereinbart genutzt werden kann.

Was ist kein Incident?

Was die Abgrenzung anbelangt, so ergeben sich als wesentlichste Objekte die folgend gelisteten. Dies ist insbesondere deshalb spannend, weil viele Service Desks den Incident Management Prozess für eben diese Objekte mitnutzt.

  • Ein Incident ist kein Problem
  • … weil die Zielstellung im Incident Managemen die schnellstmögliche Wiederherstellung der vereinbarten Servicequalität ist während das Problem Management auf nachhaltige Lösungen fokussiert.
  • Ein Incident ist kein Service Request
  • … weil Incidents unvorhersehbare Beeinträchtigungen von Services sind und Service Requests als Standard Changes planbare Änderungerungen mit niedrigem Risiko abbilden.
  • Ein Incident ist keine Anforderung
  • … weil Fehler für nicht umgesetzte Funktionalitäten keine Fehler sind. Hier ist der Impact insofern besonders groß, als dass die Aktivitäten nicht harmonieren – Incidents werden untersucht und behoben während Anforderungen in einer Konzeptionsphase in Lösungen transformiert, umgesetzt, getestet, an Anwender geschult, dokumentiert und produktiv gesetzt werden.
  • Ein Incident ist kein Change
  • … weil Änderungen an Services weitere Aktivitäten erfordern (Kommunikation von Änderungen, Risikobewertung, Budgetierung, …). Hier liegt aber eine wesentliche Prozessschnittstelle vor, Fehlerbehebung häufig mit Änderungen einhergehen. Changes (ggf. auch Emergency Changes) können also auf Incidents beruhen. Es ist somit vorteilhaft, wenn man diesen Zusammenhang auch nachvollziehen kann.
  • Ein Incident kann eine Anwenderfrage sein
  • … einfach weil der Anwender eine Beeinträchtigung vermutet – getreu dem Motto „Nein, dieser ‚Bug‘ ist ein Feature.“ Das allein stellt so kein Problem dar, Sie werden aber diese Incidents nicht als Beeinträchtigungen der Servicequalität reporten wollen.

Was können Sie mitnehmen?

  1. Der Incident Management Prozess ist aus dem ITIL Portfolio in den meisten IT Organisationen der am weitesten entwickelte. Gut!
  2. Durch die häufig große Akzeptanz sowie organisatorische Prozessenabler (z.B. der Service Desk) werden eine Vielzahl unterschiedlicher Aktivitäten über den Incident Management Prozess gesteuert, was einige unangenehme Nebeneffekte mit sich bringt:
    • Changes werden als Incidents ohne Genehmigung und Planung durchgeführt und führen zu weiteren Fehlern. Relevante Stakeholder sind nicht eingebunden.
    • Die Weiterentwicklung von Services erfolgt zufällig, unpriorisiert und nicht steuerbar operativ. Die Kosten dafür sind unbekannt und nicht ermittelbar – gleiches gilt für den Nutzen.
    • Service Requests werden – ähnlich wie Changes – ohne Genehmigung als Incidents durchgeführt. Im Identity Management beispielsweise führt das zu hohen Aufwänden für die Auditierung von Berechtigungen – oder zum Kontrollverlust.

Sie haben Parallelen erkannt und möchten Lösungsansätze evaluieren? Gerne können Sie mich ansprechen – am einfachsten über eine der Varianten unter Kontakt .

Ähnliche Artikel

  • ITSM & ITIL – Von Allem etwas… Von unterschiedlichen Projekttypen - erstmal ohne ITIL In der IT Welt findet man typischerweise Technologieprojekte bei denen innovative und unbekannte Technologien erst auf Herz und […]
  • ITSM Trends 2014 Zum Start ins Jahr 2014 möchte ich gern meine Zusammenstellung der wahrscheinlichen Entwicklungen in diesem Jahr bringen. Standards, Standards, Standards Kein wirklich neuer Hut aber im […]
  • Schatten IT – gestern, heute und morgen Während Schatten IT durch zunehmende Standardisierung in Lösungen und Prozessen über die letzten Jahre einem eher rückläufigen Trend unterworfen war, wächst mit BYOD ein neuer Trend mit […]

Hinterlassen Sie einen Kommentar