ALM Kaffeekränzchen II – Incidents und Problems
Richtiges ITIL braucht Problem Management: Unterschied zwischen Incident und Problem.
Der Begriff des Incidents mag den meisten bekannt sein. Warum aber auch eine weitergehende Differenzierung zum Problem sehr viel Sinn macht, wird folgend erklärt.
Incident
Ein Incident ist eine unerwartete Störung eines Service (Beeinträchtigung, Unterbrechung). Salopp gesagt, der Anwender kann nicht arbeiten. Incidents sind immer reaktiv. Der Incident ist vom Service Request und Request Fulfillment abzugrenzen, die i.d.R. standardisierte, bekannte Aktivitäten beinhalten.
Der Incident wird i.d.R. vom 1st Level Support bearbeitet. Ziel ist die möglichst rasche Wiederherstellung des Service mit einer Lösung, wenn die Störung in der Known-Error Datenbank (Knowledge Base) gefunden wird, oder mit einem Workaround; Hauptsache. der Anwender kann wieder arbeiten.
Incident Bearbeitung steht i.d.R unter SLAs und kennt Eskalationsszenarien. Die Kundenzufriedenheit hat Priorität.
Problem
Ein Problem hingegen zielt auf die Ursache einer Störung innerhalb der IT-Infrastruktur, um diese zu beheben und die so gefundene Lösung in die Known-Error Datenbank einzutragen.
Ein Problem kann als Reaktion auf einen oder mehreren Incidents reaktiv sein, aber es beinhaltet auch proaktive Maßnahmen (regelmäßige Reviews) zur Vermeidung von (weiteren) Incidents. Hierzu gehören Maßnahmen, die innerhalb der IT-Infrastruktur vorgenommen werden müssen. Daher ist das Problem die Schnittstelle zum Change-Management. Problems werden i.d.R. vom 2nd, Changes vom 3rd Level Support bearbeitet.
Solange die Ursache eines Problems nicht gefunden wird, tauchen immer neue Incidents hierzu auf, die an das bereits vorhandene Problem angeheftet werden.
Da die Dauer einer solchen Root Cause Analysis nicht vorab bekannt ist, steht ein Problem i.d.R. nicht unter SLAs. Die Qualität der gefundenen Lösung hat Priorität.
Risiken bei fehlender Unterscheidung
- Aktivitäten zur Lösung von Incidents können längere Serviceunterbrechungen zur Folge haben, wenn anstelle der Wiederherstellung des normalen Betriebes eine Ursachenanalyse durchgeführt wird
- Incidents werden zu früh geschlossen (SLA!), es werden keine tiefergehenden Maßnahmen zur Ermittlung der Ursache und der Lösung geführt; es wird kein Eintrag in die Known-Error Datenbank erzeugt; daher tauchen ähnliche Incidents immer wieder auf.
- Incidents werden offengelassen, damit eine Ursachenanalyse durchgeführt werden kann. Dadurch ist meist nicht mehr erkennbar, wann der Service wieder verfügbar ist. SLA Ziele werden nicht erreicht, obwohl möglicherweise der Anwender wieder arbeiten kann. Diese Langläufer Incidents werden immer mehr, man muss sie regelmäßig bereinigen.
- Es tauchen Wünsche auf, zusätzliche Status oder Prioritäten einzuführen, um die SLA Uhr trotzdem zu stoppen.
- Es tauchen Wünsche auf, weitere Incidents einer Serie an den ersten anzuheften, womit dieser eigentlich zu einem Inkognito-Problem wird. Programmtechnisch entsteht so im Laufe der Zeit ein Monster.
Vorteile der Unterscheidung
Werden Incident und Problem voneinander getrennt, so können Support-Mitarbeiter im Rahmen des Incident Management das Ziel einer raschen Wiederherstellung erfüllen und zugleich in einem separaten, parallel ablaufenden Problem Management Prozess eine Ursachenanalyse durchführen und das Problem lösen.
