Vorfall: Incident und Problem

ITIL® gibt im  Rahmen von Good Practices die grobe Richtung vor. Es gibt Prozesse und Rollen die vorgehalten werden müssen. Wie genau, das ist Sache der eigenen Organisation. Auch finden sich in den Büchern einige Anmerkungen Anekdoten oder sogar manchmal (unpassende) Verallgemeinerungen, die einen guten Hinweis darauf geben, wie es um Prozesse und Funktionen in Wirklichkeit bestellt ist. Bei Anfängern oder Personen, die ITIL nur vom Hörensagen kennen, taucht immer wieder eine Frage auf: „Wie wird denn aus einem Incident ein Problem?“. Die kurze Antwort ist: „Gar nicht“. Die längere Antwort ist wie folgt…

Eigentlich ist das Verhältnis von Incident und Problem recht gut in der Literatur erläutert und sollte in einem Foundation Kurs vermittelt werden. Wer ITIL nicht mag: Unbedingt einen ITIL Foundation Kurs mitmachen, dem Trainer viel Fragen stellen und mit einer eigenen Meinung herausgehen. Die Kurse sind kurz und günstig. Aber zurück zu diesem Artikel. Folgen wir dem ITIL Glossar findet sich:

• Incident: Eine nicht geplante Unterbrechung oder eine Qualitätsminderung eines IT Service
• Problem: Die Ursache für einen oder mehrere Incidents

Also: „Gestern konnte ich noch Drucken, heute nicht mehr.“ Dies ist ein Incident, Umgehungslösung für den heutigen Tag ist die Benutzung eines lokalen Tintenstrahldruckers. Als Problem stellt sich irgendwann eine nicht funktionierender Druck-Server heraus. Soweit so gut. Formulieren wir die anfängliche Frage doch einmal um: „Wie kommt es dazu, dass sich jemand einer Ursachenanalyse annimmt?“

Nun wäre der Punkt gekommen Anekdoten aus dem IT-Leben vor ITIL auszubreiten, den Platz spare ich mir, bzw. fordere Euch auf diese Anekdoten als Kommentar zu hinterlassen 🙂

In der Welt von ITIL-isierten ITs gibt es zwei übliche Vorgehensweisen. Zum Einen hätten wir eine Störung, deren Auswirkung und Dringlichkeit (Priorität) so hoch ist, dass der Incident Manager zu seinem Kollegen Problem Manager geht und ihn mehr oder weniger freundlich Bittet was dagegen zu tun. Man könnte denken: Ist ja wie in der Nicht-ITIL-Welt! Stimmt nicht so ganz:

1. Es entscheidet die vergebene Priorität was Wichtig ist,
2. dann sind die beiden „Manager“ für den Prozess (also den Output) verantwortlich und nicht etwa für ein Team,
3. meistens wird der Incident Manager dazu genötigt einen kurzen Abschlussbericht inkl. Ursache und Lösung des strukturellen Fehlers anzufertigen

Also

1. Wir entscheiden nicht mehr aus dem Bauch heraus was Wichtig oder gar eine Katastrophe ist
2. wir vermeiden Ping-Pong, dem Problem Manager ist es egal welches Team „Schuld“ hat und
3. kümmern uns um den Vorfall auch wenn der erste Rauch verzogen ist und eine gute Umgehungslösung bereits wirkt.

Die zweite Vorgehensweise ist jeden Abend im Ticket Tool die Top-10-Incidents zum Beispiel nach Priorität oder nach Menge von Incidents pro CI (IT System) heraus zu suchen und diese an das Problem Management zu übergeben.  Dies sorgt im Laufe der Zeit dafür, dass strukturelle Fehler beseitigt werden, die nur kleine Auswirkungen haben. Aber auch kleine Verzögerungen im Arbeitsalltag vieler Mitarbeiter kosten Geld und die Reputation der hauseigenen IT.

Zum Schluss noch etwas mehr Praxis: Leider funktioniert Problem Management oft nicht gut oder nur innerhalb eng miteinander arbeitender Teams. Wenn Euch ein ITIL Consultant als Lösung für ein nicht funktionierende Problem Management mit Prozessbildchen kommt, setzt ihn vor die Tür. Prozess ist Erstmal nicht wichtig. Simple Vorgehensweisen tun es auch für den Anfang. Benötigt wird eine kommunikative Person als Problem Manager, die einmal die Woche zum CIO muss. Der ITIL Consultant sollte lieber dem CIO erläutern, dass das Argument „meine Leute haben Wichtigeres zu tun“ dumm ist. Wichtiger als Ursachenanalyse? Seid ihr noch bei Trost?