Wie kommen Sie aus den Catch 22 des Problem Managements heraus?

Wie wir alle wissen, erlebte das Ende der 1980er Jahre nicht nur den Aufstieg der Guns N‘ Roses, die ersten Welttourneen von Madonna und Michael Jackson, sondern – was wohl noch wichtiger ist – das Erscheinen von ITIL.

Dank dieses neuen Frameworks stellt die IT ihren Anwendern und Kunden nun Services (statt Technologie) zur Verfügung, und alle sind sich einig, dass Service-Störungen schlecht sind und so schnell wie möglich behoben werden sollten.

Wir werden später auf diese beiden Aspekte zurückkommen, und wir werden sehen, wie sie die Quelle allen Übels sind.

Wenn ein Problem auftaucht

Das Thema könnte so aussehen, als sollte es von einem Psychologen und nicht von einem IT-Menschen angegangen werden: Wir Menschen haben enorme Schwierigkeiten damit, einen offensichtlichen Schmerz unbehandelt zu lassen, selbst für das Versprechen einer späteren Verbesserung.

Wenn man darüber nachdenkt, ist dies der Ursprung unseres Catch 22 (catch 22; eine paradoxe Situation, aus der ein Individuum aufgrund widersprüchlicher Regeln oder Einschränkungen nicht entkommen kann).

Wenn wir die ITIL Best Practices in einer Organisation implementieren, richten wir Practices (früher hießen sie Prozesse) ein, weil wir

• effizienter sein wollen,
• besser strukturiert sein wollen,
• die Kontrolle über unsere Infrastruktur gewinnen wollen,
• Geld sparen wollen,
• die Kundenzufriedenheit erhöhen wollen.

Catch-22

Auch wenn das ultimative Ziel aller Practices darin besteht, unsere Kunden glücklich zu machen, sind einige von ihnen benutzerorientierter als andere.

An dieser Stelle geraten wir in Schwierigkeiten: Wir investieren all unsere Ressourcen in die benutzerorientiertesten Practices, was uns unbewaffnet zurücklässt, wenn wir Zeit und Energie in weniger benutzerorientierte, aber ebenso (oder sogar mehr) wichtige Practices investieren sollten.

Die Konzentration auf die am meisten benutzerorientierten Practices ist eine naheliegende Entscheidung.
Wenn Benutzer den Service Desk unter Druck setzen, oder wenn ein Vorfall die Produktion beeinträchtigt, oder wenn Kunden hinter Ihrer Tür auf die nächste Version Ihres Produkts warten, wollen Sie etwas unternehmen.

Es ist menschlich sehr schwierig (in manchen Situationen wage ich zu behaupten, sogar unmöglich), diese Aktivitäten zugunsten anderer, die keinen unmittelbaren Effekt haben, zurückzustellen.

Das führt dazu, dass wir am Ende all unsere Zeit und Energie in die Brandbekämpfung investieren, so dass wir gar nicht die Möglichkeit haben, uns zu fragen, warum wir überhaupt so viele Brände haben.

Und hier finden wir unseren „catch 22“: Serviceunterbrechungen (Vorfälle) sind schlecht und sollten so schnell wie möglich behoben werden.

Wir konzentrieren uns so sehr auf den zweiten Teil des Satzes, dass wir den ersten vergessen.

Wenn wir uns einig sind, dass Vorfälle schlecht sind, dass sie einen sehr negativen Einfluss auf die Kundenzufriedenheit haben, dann sollten wir doch versuchen, sie zu vermeiden, oder nicht?

Und wenn wir sie nicht ganz vermeiden können, sollten wir versuchen, ihre Auswirkungen zu minimieren, wie es das Ziel des Problem-Managements ist.

Darin sind wir uns alle einig, aber es ist leichter gesagt als getan, denn wir sind auch nur Menschen und so verstrickt in den „so schnell wie möglich gelöst„-Teil des Satzes.

Keine magische Lösung, aber ….

Das war’s also, es gibt keinen Ausweg, wirklich?
Sind wir dazu verdammt, dieses Fass zu leeren, ohne jemals in der Lage zu sein, den Hahn abzudrehen, der es füllt?

Nun, hoffentlich nicht. Aber wie ich schon sagte, es gibt keine magische Lösung.
Oder zumindest keine, von der ich weiß (wenn Sie eine bereit haben, zögern Sie nicht, sie mit uns zu teilen).
Aber wir können daran arbeiten, und den Durchfluss des Wasserhahns reduzieren.

In einer idealen Welt, so könnte man meinen, sollte eine Organisation zwei getrennte Teams haben, die an Vorfällen und Problemen arbeiten, um zu vermeiden, dass man in den oben erwähnten „catch 22“ hineingezogen wird.

Doch so einfach sind die Dinge leider nicht.

Vorfälle und Probleme sind eng miteinander verknüpft

Der erste Grund, der uns in den Sinn kommt, um die Unmöglichkeit getrennter Teams zu rechtfertigen, ist, dass wir nicht genug Arbeitskräfte haben, um ein Team ausschließlich der Problemlösung zu widmen.

Wenn dies in den meisten Situationen zutrifft, würden wir diese beiden Aktivitäten wahrscheinlich ohnehin nicht strikt trennen, da sie eng miteinander verbunden sind.

In der Tat sind die technischen Kenntnisse und Fähigkeiten, die benötigt werden, praxisübergreifend.
Man lernt eine Menge nützlicher Dinge, um Probleme zu beheben und Workarounds zu dokumentieren, während man an Vorfällen arbeitet und umgekehrt.

Völlig getrennte Gruppen sind also wahrscheinlich nicht die beste Lösung.
Aber temporäre Teams könnten es sein.

In der Tat sollte die Einrichtung eines temporären Teams (mit den richtigen Fähigkeiten), das an einem oder mehreren Problemen arbeitet, den Mitgliedern des Teams den Druck ersparen, der vom Vorfall-Management ausgeht, unter der Bedingung, dass das temporäre Team an einem bestimmten Ort arbeiten kann.

Klare Umsetzung der drei Phasen des Problem-Managements

Eine klare Umsetzung der drei Phasen des Problem Managements, wie sie in ITIL 4 vorgeschlagen werden, kann Ihnen ebenfalls helfen, sich in die richtige Richtung zu bewegen.

Da jede Phase einen klar definierten Output hat, ist es relativ einfach, die verschiedenen Phasen verschiedenen Gruppen anzuvertrauen, was auch eine gute Möglichkeit sein kann, die Arbeitslast zu verteilen und so die Zeit zu finden, die wir schmerzlich vermissen.

1. Die Phase der Problemidentifikation

Sowohl die proaktive als auch die reaktive Phase sollte meiner Meinung nach von Personen durchgeführt werden, die sowohl technische als auch funktionale Fähigkeiten besitzen. Sie sollten sowohl ein gutes Verständnis für die Organisation als auch eine klare Vorstellung von der technischen Infrastruktur haben, auf der unsere Dienste basieren.

Beides ist notwendig, um existierende und potentielle Probleme zu erkennen und so den gewünschten Output zu produzieren: vollständige und gut dokumentierte Problemaufzeichnungen.

Die Priorisierung der Problemaufzeichnungen sollte zwischen der Phase der Problemidentifikation und der Phase der Problemkontrolle stattfinden. Dies ist wichtig, um den Druck zu reduzieren (es gibt immer zu viel zu tun) und sicherzustellen, dass wir unsere begrenzten Ressourcen bestmöglich nutzen.

2. Die Phase der Problemkontrolle

Sie sollte von kreativen, breit denkenden, erfahrenen Technikern durchgeführt werden.
Ausgehend von Problemaufzeichnungen analysieren sie die Probleme und dokumentieren ihre Erkenntnisse.
Dadurch werden die Probleme auf den Status eines bekannten Fehlers gebracht.

Das erwartete Ergebnis dieser zweiten Phase sind Workaround-Lösungen, die helfen, Vorfälle schneller zu lösen (und damit die Zufriedenheit der Benutzer zu verbessern und etwas Zeit für unsere technischen Mitarbeiter freizusetzen, um das Ende des Catch 22 zu sehen).

3. Fehlerkontrolle

Dies ist die dritte und letzte Phase der Problem-Management-Praxis.

Eine wichtige Aktivität dieser Phase ist wieder die der Priorisierung.
Bekannte Fehler können eine ganze Weile offen bleiben, und da sich dieser Umstand zwangsläufig ändert, sollte diese Priorisierungsaktivität regelmäßig durchgeführt werden.

Die Priorität von bekannten Fehlern sollte von einem Team von Personen bewertet werden.
Dabei müssen mehrere Kriterien berücksichtigt werden, wie:

• Auswirkung auf die Kundenzufriedenheit,
• Kosten der Anwendung des aktuellen Workarounds,
• Kosten der endgültigen Lösung,
• technische Machbarkeit der endgültigen Lösung,
• Einfluss auf eingesetzte Partnerprodukte.

Sobald bekannte Fehler priorisiert sind, kann die Arbeit an der endgültigen Lösung oder an der Verbesserung des Workarounds beginnen.

Hoffentlich inspiriert Sie dieser strukturierte Ansatz des Problem-Managements so sehr, dass Sie ihn an Ihre eigene Organisation anpassen und so aus den „Catch 22 des Problem-Managements“ herauskommen können.

Kaïs Albassir

ITIL expert
Kaïs‘ erste Begegnung mit ITIL war mit der Version 2. Seitdem arbeitete er als Software-Berater, bevor er sich von der Technik zurückzog. In den letzten 10 Jahren hat Kaïs Organisationen dabei geholfen, mit ITIL zu beginnen oder ihren Reifegrad zu erhöhen.
Er ist auch ein zertifizierter ITIL-Trainer.