Messung der Qualität des Problemmanagements in einer ITIL-Umgebung

Ein genauerer Blick auf die Durchführung des Problemmanagements

Zu verstehen, wie Analysten und Ingenieure an Problemen arbeiten, Ursachen finden und entsprechende Maßnahmen einleiten, klingt nach einer einfachen Aufgabe. Sobald man Zugriff auf die Anwendung zur Dokumentation des ITIL-Problemmanagements hat, kann der Fallinhalt gelesen werden. Es scheint lediglich den Zugriff auf das Fallmanagement-Tool und einige Fähigkeiten zur Nutzung dieses Tools zu erfordern.

Fragt man jedoch Problemmanager, wie sie Probleme handhaben, werden typischerweise die wahren Verfahren aufgedeckt, die beschreiben, welche Schritte sie bei der Problemfindung und -bearbeitung unternehmen. Diese dokumentierten Prozesse und Verfahren sind sehr hilfreich: Erwartungen an die Schritte, die zur Bearbeitung von Problemen, die Aufmerksamkeit erfordern, unternommen werden müssen, sind sehr klar definiert.

Das Lesen von Problemtickets oder das Befragen von Problemmanagern, wie sie die Schritte in den Verfahren ausfüllen, scheint ein logischer nächster Schritt zu sein, um mehr darüber zu erfahren, wie im Problemmanagement Wert geschaffen wird, da hier Informationen gesammelt, Daten analysiert und Schlussfolgerungen gezogen werden. Wie wird also die Leistung des Problemmanagements gemessen? Viele Organisationen scheinen zeitbezogene Parameter rund um die Probleme zu messen oder die Anzahl der Problemtickets in einem bestimmten Status zu zählen. Beispiele hierfür sind:

• Anzahl der offenen Problem-Tickets (Backlog) pro Anwendungsgruppe im Zeitverlauf
• Durchschnittliches Alter offener Problem-Tickets, oft im Zeitverlauf betrachtet
• Durchschnittliche Zeit bis zur Findung der Ursache in Problem-Tickets
• Anzahl wiederkehrender Probleme

Angesichts der Ziele des Problemmanagements: Ursachen von Problemen zu finden und proaktiv Maßnahmen zu ergreifen, um zukünftige Vorfälle und Probleme zu vermeiden – wie gut zeigen die obigen Beispiele, wie erfolgreich ein Team diese Ziele erreicht? Fragen wir nach dem einen und messen etwas völlig anderes?

Eine Praxiserfahrung

Nach etwa zwei Tagen einer Bewertung, wie das Problemmanagement in einer globalen IT-Abteilung eines weltweit tätigen Unternehmens gehandhabt wurde, beschlossen wir, eine Pause einzulegen, um unsere Ergebnisse unter den Teilnehmern der Bewertung zu vergleichen. Zu den Feldern, die zur Überprüfung herangezogen wurden, gehörten die Ticketzusammenfassung und die Problembeschreibung sowie individuelle Fortschrittsaktualisierungen und die Beschreibungen der Problemlösung.

Das beobachtete Muster war, dass in den meisten Problemtickets die Zusammenfassung klar die betroffene Anwendung oder Hardware und deren Fehlerzustand angab, gefolgt von einigen zugrunde liegenden Daten in der detaillierten Problembeschreibung. Weitere Aktualisierungen zeigten typischerweise, wie das Problem im Laufe der Zeit die prozeduralen Schritte des Problemmanagements durchlief und in der Lösungsbeschreibung zu einem Abschluss kam.

Obwohl dies wie ein Einzelfall erscheint, repräsentiert es das Muster, das im Bewertungsteam beobachtet wurde. Im Gespräch über andere Erfahrungen entstand das folgende Bild, das die beobachteten Sachverhalte darstellt:

Dies wirft eine Reihe von Fragen dazu auf, wie Schlussfolgerungen gezogen und Maßnahmen ergriffen oder geplant wurden:

• Welche Daten müssen gesammelt werden, um eine Ursache effektiv zu finden?
• Wie stellen Experten sicher, dass sie die richtigen Daten zum richtigen Zeitpunkt gesammelt haben?
• Wie sieht die „Magie“ aus? Welche nicht dokumentierten Schritte wurden unternommen? Welche nicht dokumentierten Denkprozesse fanden statt?
• Welche anderen Ursachen wurden in Betracht gezogen?
• Welches Maß an Vertrauen hatte das lösende Team, dass die gefundene Ursache wirklich die „wahre Ursache“ war?
• Welche Nebenwirkungen könnten die zur Behebung des Problems ergriffenen Maßnahmen verursacht haben?

Antworten auf diese Fragen können einen guten Einblick geben, wie bei einem beliebigen Ticket im Problem Management Wert geschaffen wurde. Die Antworten auf diese Fragen hängen in der Regel nicht mit zeitlichen oder numerischen Parametern der Problem-Management-Verfahren zusammen. Es geht vielmehr um die Qualität der Datenerfassung und die Qualität der Denkprozesse der beteiligten Personen.

Wiederkehrende Probleme in den Griff bekommen – Stabilität erreichen.

Manche mögen behaupten, dass, wenn „Magie“ gut gemacht wird, das Unternehmen eine geringe Anzahl wiederkehrender Probleme sehen wird, was oben als Leistungsindikator für das Problemmanagement angegeben wurde. Das stimmt!

Leider.

Was ein Unternehmen durch wiederkehrende Probleme erhält, ist die Botschaft, dass der Problemmanagementprozess bei der ersten Problemstellung keine gute (oder nicht gute genug) Arbeit bei der Suche nach der Grundursache geleistet hat. Da das Wiederauftreten Wochen oder Monate dauern kann, ist dies ein nachlaufender und ungenauer Indikator für die Leistung des Problemmanagements. Was wirklich benötigt wird, ist eine Möglichkeit, die Leistung (und damit den Wert) des Problemmanagements so zu messen, dass ein Unternehmen vorhersagen kann, dass die Anzahl der wiederkehrenden Probleme sinken wird. Mit anderen Worten: Was sind die führenden Leistungsindikatoren für das Problemmanagement?

Maßnahmen zu finden, die anzeigen, wie gut Probleme gelöst wurden, mag bei einfachen (wenig kritischen) Problemen, bei denen ein Wiederauftreten zwar unerwünscht, aber nicht katastrophal wäre, nur eine geringe Wirkung haben. Einige Unternehmen haben gelegentlich kritische Vorfälle und Probleme, bei denen sie am Rande eines katastrophalen Geschäftsereignisses stehen, das mit einem oder mehreren IT-bezogenen Ereignissen verbunden ist, und sie beschließen, diese Erfahrung nie wieder zu machen! Das Messen wiederkehrender Probleme und Trends ist wahrscheinlich keine ausreichend gute Metrik.

Eine Best Practice für „Magie“?

Fragt man Ingenieure und Analysten nach ihren internen Denkprozessen bei der Bearbeitung von Problemtickets, erhält man viele verschiedene Antworten. Dies unterscheidet sich völlig davon, wenn dieselbe Zielgruppe gefragt wird, wie eine bestimmte Anwendung oder Hardware konfiguriert werden soll. Es ist heutzutage offensichtlich, dass ein gemeinsamer Ansatz zur Konfiguration einer Anwendung oder eines Hardwareteils viele Vorteile hat:

• Eine „beste Konfiguration“ für das verwendete Asset reduziert Variationen
• Ein gemeinsames Verständnis, wie Assets zur gesamten Infrastruktur Wert beitragen, hilft beim Kapazitätsmanagement
• Es vereinfacht die Kommunikation darüber, wie Assets konfiguriert oder geändert werden
• Es ermöglicht eine nahtlose und qualitativ hochwertige Übergabe und Wartung

Angesichts dieser Faktoren ist es bemerkenswert, dass es oft keinen gemeinsamen Ansatz für die Problembehandlung gibt. Infolgedessen bleibt dies „Magie“.

Wenn eine Best Practice zur Ermittlung von Grundursachen für Probleme etabliert ist, bietet sie sehr ähnliche Vorteile wie eine Best Practice zur Konfiguration eines Assets. Außerdem würde sie eine neue Sprache für die Fehlerbehebung mit einer Terminologie ermöglichen, die die Dokumentation dessen, wie die „Magie“ aussieht und wie Schlussfolgerungen gezogen werden, erlaubt.

Wie sieht die „Magie“ aus?

Es gibt viele Wege, die Grundursache eines Problems zu finden. Einige sind erfolgreicher als andere, und verschiedene Personen (ohne einen Standardrahmen) haben naturgemäß unterschiedliche Ansätze. Die Effektivität jeder Gruppe von Fehlerbehebern liegt irgendwo auf einer Glockenkurve. Fehlerbehebungsexperten haben einen guten Ruf und können mit Zuversicht jede Aufgabe übernehmen. Solide Leistungsträger sind für die meisten Aufgaben gut geeignet und haben Raum zur Verbesserung, und diejenigen mit einem schlechten Ruf in der Fehlerbehebung benötigen wahrscheinlich Hilfe.

Die Kepner-Tregoe (KT)-Methode zur Problemanalyse wurde in den 1950er Jahren erforscht und definiert und seitdem kontinuierlich verfeinert und getestet. Es ist leicht zu erkennen, dass dies viele Jahre vor der Erfindung des Akronyms ITIL war.

Es wurde argumentiert, dass eine Methode, die so lange existiert, für die IT-Branche nicht geeignet sein kann, da weder IT noch ITIL zu der Zeit existierten, als die Methode erstmals erforscht wurde. Es bedarf eines genaueren Blicks auf die KT-Methode zur Problemanalyse, um ein angemesseneres Urteil zu fällen. Die Hauptschritte der Problemanalyse bestehen aus:

• Das Problem beschreiben
• Mögliche Ursachen auflisten
• Mögliche Ursachen bewerten
• Die tatsächliche Ursache nachweisen
• Über die Behebung hinausdenken

Für jeden dieser Schritte gibt es klare Absichten und einige Unterschritte – die durch die Formulierung von Fragen und die Dokumentation der Antworten umgesetzt werden, um die richtigen Daten in den Denkprozess der Problemanalyse einzuspeisen. Dies geschieht alles ohne ein bestimmtes Produkt oder Problem im Sinn, und es ist sehr ähnlich zu ITIL, das für alle Arten von IT-Organisationen funktioniert. Die Problemanalyse ist ein Ansatz zur Ermittlung der Grundursache für viele verschiedene Probleme, unabhängig von Branche oder Technologie.

Jede Art von Problem?

Nun ja… ja! Aber es gibt eine sehr spezifische KT-Definition des Begriffs „Problem“, die anders ist, aber recht gut zu ITIL passt. Laut KT müssen drei Kriterien erfüllt sein, bevor wir den Problemanalyseprozess auslösen:

1. Es sollte eine Lücke zwischen der tatsächlichen und der gewünschten Leistung bestehen. Dies nennen wir eine Abweichung (z. B. Maschine funktioniert nicht, obwohl sie funktionieren sollte);
2. Die Ursache für die Abweichung ist unbekannt (z. B. kein bekannter Fehler);
3. Es muss ein Bedarf bestehen, die Abweichung zu kennen (z. B. um Maßnahmen ergreifen zu können).

Das Ergebnis der Durchführung einer klar definierten Reihe von Schritten zur Ermittlung der Grundursache ist, dass Fehlerbeheber beginnen können, zu kommunizieren und zu dokumentieren, was bereits getan wurde und was im Prozess noch zu tun ist. Ein Beispiel dafür, wie gesammelte Daten textuell modelliert werden, um die Symptome eines Problems zu beschreiben, ist in der Abbildung unten dargestellt.

Bekannte „Magie“

Wenn die Schritte für einen konsistenten und reproduzierbaren Ansatz zur Problemanalyse gut verstanden sind, wird die Messung der Qualität einer gefundenen Grundursache viel einfacher. Wenn die „Magie“ bei der Ermittlung der Grundursache verstanden wird, kann sie dokumentiert, reproduziert, reibungslos übergeben und effizient zeitlich geplant werden; all dies sind Merkmale einer Best Practice.

Sobald eine IT-Supportorganisation einen einheitlichen Ansatz zur Problemanalyse verwendet, kann die unmittelbare Qualität oder der Wert von Einzelpersonen und Teams gemessen werden. Genau das tun KT-Berater, wenn sie die Qualität bestehender Fehlerbehebungsprozesse in einer IT-Supportumgebung bewerten. Durch das Lesen bestehender Incident- und Problemtickets und die Einschätzung, wie stark der Ansatz an einen bekannten Standard angepasst werden muss, können wir helfen, einen grundlegenden Frühindikator für die Qualität der Fehlerbehebung zu generieren.

Als Beispiel: IT-Mitarbeiter, die ihre Synopsis (oder ein gleichwertiges Feld in ihrem Fallmanagement-Tool) konsequent in Bezug auf ein Objekt mit einer Abweichung dokumentieren (die Frage beantwortend: „Was ist falsch mit was?“), verbringen im Durchschnitt etwas mehr als 10 Prozent weniger Zeit, bevor eine Grundursache gefunden wird.

Das alles mag so einfach klingen, dass es nicht wahr sein kann – allein die Dokumentation des Objekts und des Fehlers, für die Experten die Grundursache finden wollen, spart etwas mehr als 10 Prozent der Zeit bis zum Abschluss. Nun, Sie könnten Recht haben: Es mag einfach klingen, aber das ist es nicht. Um diesen Denkprozess zu verinnerlichen und reflexartig zu machen, bedarf es einer Verhaltensänderung, und in der Hitze des Gefechts, unter Zeit- und anderem Druck des Geschäfts, kann dieser einfache Schritt beiseitefallen, wenn er nicht abseits der Hochdruckthemen geübt und unterstützt wird. Die Schritte zur Implementierung einer Best Practice für die Fehlerbehebung sind gut verstanden, aber die Umsetzung erfordert dennoch Aufmerksamkeit, Fokus, gute Planung und Überlegung. Glücklicherweise ist Denken einfach, aber Implementierungsteams können abgelenkt werden. Die KT-Denkprozesse, wie die Problemanalyse, sind kein Allheilmittel, das garantiert, dass die Grundursache gefunden wird. Es ist lediglich eine Methode, die bereits sachkundige Experten zum Ziel führt, und der Erfolg bei der Ermittlung der Grundursache kann je nach Qualität der Daten (und Beobachtbarkeit), die in den Prozess einfließen, variieren.

Letzteres ist ein Schlüssel zum Erfolg; das bloße Ausfüllen des Formulars, der Vorlage oder der Tabelle liefert keine gute Grundursache, denn die Problemanalyse basiert auf einem festen Fundament harter Logik, die aktiv genutzt werden muss. Es erfordert immer noch intensive Datenerfassung, Denken und Überprüfung, was sich nicht von der Fehlerbehebung in einer unstrukturierten Umgebung unterscheidet. Die große Veränderung besteht darin, dass die Denkschritte sichtbar werden und einen Namen erhalten, alles basierend auf einem klaren zugrunde liegenden Plan für die Problemanalyse. Als Ergebnis dessen können wir messen und kommunizieren, wo wir stehen und wie wir im Prozess der Grundursachenfindung vorankommen.

In diesem Fall ist Messen keine Datenbankabfrage, die zeigt, wie viel Zeit oder wie viele Tickets eine bestimmte Reihe von Kriterien erfüllen. Es führt zu einer Bewertung, die von internen (Fehlerbehebungs-)Experten vorgenommen werden kann, die die Qualität der gesammelten Daten in den einzelnen Schritten der Problemanalyse beurteilen. Eine solche Bewertung wird dann zu einem führenden Leistungsindikator für die Qualität der Problemanalyse.

Wie geht es von hier aus weiter?

Ein Buch über das Geigenspiel zu lesen, macht den Leser nicht zu einem großartigen Geiger. Ebenso wird die bloße Schulung einer Organisation, wie man besser in der Fehlerbehebung denkt, die Organisation wahrscheinlich nicht zu einer Weltklasse-Gruppe von Fehlerbehebern machen. Es erfordert Aufmerksamkeit, Übung und Engagement, um den Ansatz in die Denkweisen der Einzelpersonen zu integrieren, und die Ergebnisse werden sich auszahlen. Eine Investition in die Suche nach Grundursachen im Problemmanagement unterstützt Investitionen in technische Fähigkeiten und Erfahrungen, die zu einer Belegschaft führen, die sich bewusst ist und gut gerüstet ist, was es braucht, um qualitativ hochwertige Lösungen für komplexe Probleme zu finden. Zu Beginn eines Problemmanagementfalls wird ein Manager (immer noch) nie wissen, wie lange es dauern wird, bis die Grundursache gefunden ist, aber es wird eine klare und geplante Richtung geben und die Ankunftszeit wird vorhersehbarer sein, was die Messung der Qualität im Problemmanagement ermöglicht.

Von Berrie Schuurhuis, Kepner-Tregoe

 

Über Kepner-Tregoe

Kepner-Tregoe ist führend in der Problemlösung. Seit über sechs Jahrzehnten hat Kepner-Tregoe Tausenden von Organisationen weltweit geholfen, Millionen von Problemen durch effektivere Ursachenanalyse und bessere Entscheidungsfähigkeiten zu lösen. Kepner-Tregoe arbeitet mit Organisationen zusammen, um Kosten deutlich zu senken und die operative Leistung zu verbessern – durch Trainings zur Problemlösung, Technologie und Beratungsleistungen.