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

Ein genauerer Blick darauf, wie Problemmanagement betrieben wird

Zu verstehen, wie Analysten und Ingenieure an Problemen arbeiten, die Ursachen finden und geeignete Maßnahmen ergreifen, klingt nach einer einfachen Aufgabe. Sobald man Zugang zu der Anwendung hat, die für die Dokumentation des ITIL-Problemmanagements verwendet wird, kann der Inhalt der Fälle gelesen werden. Alles, was man dazu braucht, ist der Zugang zum Case Management Tool und einige Fähigkeiten, dieses Tool zu benutzen.

Fragt man jedoch die Problem-Manager, wie sie mit Problemen umgehen, werden in der Regel die tatsächlichen Verfahren aufgedeckt, die beschreiben, welche Schritte sie bei der Suche nach und der Bearbeitung von Problemen unternehmen. Diese dokumentierten Prozesse und Verfahren sind sehr hilfreich: Die Erwartungen an die Schritte, die zu unternehmen sind, um bei Problemen, die Aufmerksamkeit erfordern, voranzukommen, sind sehr klar festgelegt.

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

• Anzahl der offenen Problemtickets (Rückstand) pro Gruppe von Anwendungen, über die Zeit betrachtet
• Durchschnittliches Alter der offenen Problemtickets, oft über einen längeren Zeitraum betrachtet
• Durchschnittliche Zeit bis zum Auffinden der Grundursache bei Problemtickets
• Anzahl der wiederkehrenden Probleme

In Anbetracht der Ziele des Problemmanagements, nämlich die Ursachen von Problemen zu finden und proaktiv Maßnahmen zu ergreifen, um künftige Vorfälle und Probleme zu vermeiden, wie gut geben die obigen Beispiele Aufschluss darüber, wie erfolgreich ein Team bei der Erreichung dieser Ziele ist? Verlangen wir das eine, messen aber etwas ganz anderes?

Eine Erfahrung aus dem wahren Leben

Ungefähr zwei Tage nach einer Bewertung der Handhabung des Problem-Managements in einer globalen IT-Abteilung eines weltweit tätigen Unternehmens beschlossen wir, eine Pause einzulegen, um unsere Ergebnisse unter den Teilnehmern an der Bewertung zu vergleichen. Zu den zu prüfenden Feldern gehörten die Ticket-Zusammenfassung und die Problembeschreibung sowie die einzelnen Fortschrittsaktualisierungen und die Lösungsbeschreibungen.

Bei den meisten Problemtickets wurde in der Zusammenfassung klar angegeben, welche Anwendung oder Hardware betroffen war und was damit nicht in Ordnung war, gefolgt von einigen zugrunde liegenden Daten in der detaillierten Problembeschreibung. Weitere Aktualisierungen geben in der Regel an, wie das Problem im Laufe der Zeit die Verfahrensschritte des Problem-Managements durchläuft und in der Beschreibung der Lösung seinen Abschluss findet.

Obwohl es sich hier um einen Einzelfall zu handeln scheint, ist dies ein Muster, das das Team, das die Bewertung durchführte, beobachtet hat. In Gesprächen über andere Erfahrungen wurde das folgende Bild erstellt, das die Beobachtungen darstellt:

Dies wirft eine Reihe von Fragen darüber 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 die Experten sicher, dass sie die richtigen Daten zur richtigen Zeit gesammelt haben?
• Wie sieht die Magie aus? Welche undokumentierten Schritte wurden unternommen? Welche undokumentierten Überlegungen wurden angestellt?
• Welche anderen Ursachen wurden in Betracht gezogen?
• Wie groß war das Vertrauen des Lösungsteams, dass die gefundene Ursache wirklich die "wahre Ursache" war?
• Welche Nebenwirkungen können die zur Behebung des Problems ergriffenen Maßnahmen haben?

Die Antworten auf diese Fragen können einen guten Einblick in die Art und Weise geben, wie im Problem Management für ein bestimmtes Ticket Werte geschaffen wurden. Die Antworten auf diese Fragen beziehen sich in der Regel nicht auf den Zeitplan oder numerische Parameter im Zusammenhang mit den Problemmanagementverfahren. Sie beziehen sich auf die Qualität der Datenerfassung und die Qualität der Denkprozesse der beteiligten Personen.

Erhalten Sie Kontrolle über wiederkehrende Probleme - erhalten Sie Stabilität.

Manch einer mag behaupten, dass, wenn die "Magie" gut gemacht ist, das Unternehmen eine geringe Anzahl wiederkehrender Probleme zu verzeichnen hat, was oben als Leistungsindikator für das Problemmanagement angegeben wurde. Das ist richtig!

Leider.

Was ein Unternehmen durch wiederkehrende Probleme erhält, ist die Botschaft, dass der Problem-Management-Prozess bei der Suche nach der Grundursache nicht gut (oder gut genug) gearbeitet hat, als das Problem zum ersten Mal auftrat. Da das erneute Auftreten von Problemen Wochen oder Monate dauern kann, ist dies ein verzögerter 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 Problem-Managements so zu messen, dass ein Unternehmen in der Lage ist, vorherzusagen, dass die Zahl der wiederkehrenden Probleme zurückgehen wird. Mit anderen Worten: Was sind die führenden Leistungsindikatoren für das Problemmanagement?

Die Suche nach Maßnahmen, die anzeigen, wie gut Probleme gelöst wurden, kann sich bei einfachen Problemen (mit geringer Auswirkung) nur geringfügig auswirken, da ein erneutes Auftreten nicht gerne gesehen wird, aber auch nicht katastrophal wäre. In einigen Unternehmen kommt es gelegentlich zu kritischen Vorfällen und Problemen, bei denen sie am Rande eines katastrophalen Geschäftsereignisses balancieren, das mit einem oder mehreren IT-bezogenen Ereignissen zusammenhängt, und sie beschließen, diese Erfahrung nie wieder zu machen! Die Messung von wiederkehrenden Problemen und Trends ist wahrscheinlich nicht gut genug.

Eine bewährte Praxis für die Zauberei?

Fragt man Ingenieure und Analysten nach ihren internen Denkprozessen bei der Bearbeitung von Problemtickets, erhält man viele verschiedene Antworten. Das ist etwas völlig anderes, als wenn man dieselbe Zielgruppe fragt, wie man eine bestimmte Anwendung oder Hardware konfiguriert. Heutzutage ist es ganz offensichtlich, dass ein gemeinsamer Ansatz für die Konfiguration einer Anwendung oder eines Stücks Hardware viele Vorteile hat:

• Eine "beste Konfiguration" für das eingesetzte Asset reduziert die Variation
• Ein gemeinsames Verständnis des Mehrwerts von Anlagen für die gesamte Infrastruktur 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 wie Magie.

Wenn ein bewährtes Verfahren für die Suche nach den Ursachen von Problemen eingeführt wird, bietet es ähnliche Vorteile wie ein bewährtes Verfahren für die Konfiguration einer Anlage. Außerdem würde dies eine neue Sprache für die Fehlersuche mit einer Terminologie ermöglichen, die es erlaubt, zu dokumentieren, wie die "Magie" aussieht und wie Schlussfolgerungen gezogen werden.

Wie sieht die "Magie" aus?

Es gibt viele Möglichkeiten, die Ursache eines Problems zu finden. Einige sind erfolgreicher als andere, und verschiedene Menschen (ohne einen Standardrahmen) haben natürlich verschiedene Ansätze. Die Effektivität einer Gruppe von Fehlersuchern liegt irgendwo entlang einer Glockenkurve. Experten auf dem Gebiet der Fehlerbehebung haben einen guten Ruf und können mit gutem Gewissen mit jeder Aufgabe betraut werden. Solide Leistungsträger sind für die meisten Aufgaben gut geeignet und können sich noch verbessern, und diejenigen mit einem schlechten Ruf bei der Fehlerbehebung brauchen wahrscheinlich Hilfe.

Die Kepner-Tregoe (KT)-Methode für die Problemanalyse wurde in den 1950er Jahren erforscht und definiert und seither immer weiter verfeinert und getestet. Es ist leicht zu erkennen, dass dies viele Jahre vor der Erfindung des Akronyms ITIL geschah.

Es wurde argumentiert, dass eine Methode, die es schon so lange gibt, nicht für die IT-Branche geeignet sein kann, da es zu der Zeit, als die Methode erstmals erforscht wurde, weder IT noch ITIL gab. Ein genauerer Blick auf die KT-Methode zur Problemanalyse hilft, ein angemesseneres Urteil zu fällen. Die wichtigsten Schritte der Problemanalyse bestehen aus:

• Beschreiben Sie das Problem
• Auflistung möglicher Ursachen
• Bewertung der möglichen Ursachen
• Der Nachweis der wahren Ursache
• Über die Fixierung hinaus denken

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

Gibt es ein Problem?

Nun... ja! Aber es gibt eine sehr spezifische KT-Definition des Begriffs "Problem", die anders ist, aber sehr gut zu ITIL passt. Nach KT müssen drei Kriterien erfüllt sein, bevor wir den Prozess der Problemanalyse einleiten:

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

Das Ergebnis des Durchlaufens einer klar definierten Reihe von Schritten zur Ermittlung der Grundursache ist, dass die Problemlöser damit beginnen können, zu kommunizieren und zu dokumentieren, was bereits getan wurde und was in diesem Prozess noch zu tun ist. Ein Beispiel dafür, wie gesammelte Daten textuell modelliert werden, um die Symptome eines Problems zu beschreiben, finden Sie in der folgenden Abbildung.

Bekannte Magie

Wenn die Schritte für einen konsistenten und wiederholbaren Ansatz zur Problemanalyse gut verstanden werden, wird die Messung der Qualität einer gefundenen Ursache viel einfacher. Wenn die Magie der Ursachensuche verstanden ist, kann sie dokumentiert, reproduziert, reibungslos übergeben und zeitlich effizient gesteuert werden - alles Merkmale einer Best Practice.

Sobald eine IT-Support-Organisation beginnt, einen einheitlichen Ansatz zur Problemanalyse zu verwenden, kann die unmittelbare Qualität oder der Wert von Einzelpersonen und Teams gemessen werden. Dies ist genau das, was KT-Berater tun, wenn sie die Qualität der bestehenden Fehlerbehebungsprozesse in einer IT-Supportumgebung bewerten. Durch das Durchlesen bestehender Incident- und Problem-Tickets und durch die Einschätzung, wie stark der Ansatz im Vergleich zu einem bekannten Standard strukturiert werden muss, können wir helfen, einen Basisindikator für die Qualität der Fehlerbehebung zu erstellen.

Ein Beispiel: IT-Mitarbeiter, die ihre Synopsis (oder ein entsprechendes Feld in ihrem Fallmanagement-Tool) konsequent in Form eines Objekts mit einer Abweichung dokumentieren (und damit die Frage beantworten: "Was stimmt mit was nicht?"), scheinen im Durchschnitt etwas mehr als 10 Prozent weniger Zeit zu benötigen, bevor eine Grundursache gefunden wird.

Es mag sich so einfach anhören, dass dies nicht wahr sein kann - allein die Dokumentation des Objekts und des Fehlers, für den die Experten die Ursache finden wollen, spart etwas mehr als 10 Prozent der Zeit bis zum Abschluss. Nun, Sie könnten Recht haben: Es mag einfach klingen, ist es aber nicht. Um diesen Denkprozess einzuprägen und reflexiv zu machen, ist eine Verhaltensänderung erforderlich, und in der Hitze des Gefechts, unter Zeit- und anderem Druck seitens des Unternehmens kann dieser einfache Schritt in Vergessenheit geraten, wenn er nicht geübt und unterstützt wird, ohne dass die Probleme unter hohem Druck stehen. Die Schritte zur Umsetzung einer bewährten Methode zur Fehlerbehebung sind bekannt, aber die Änderung erfordert Aufmerksamkeit, Konzentration, gute Planung und Nachdenken. Zum Glück ist das Denken einfach, aber die Implementierungsteams können sich ablenken lassen. Die KT-Denkprozesse sind, wie die Problemanalyse, kein Allheilmittel, das garantiert, dass die Ursache gefunden wird. Es handelt sich lediglich um eine Methode, die bereits sachkundige Experten zum Ziel führt, und der Erfolg bei der Suche nach der Ursache kann von der Qualität der Daten (und der Beobachtbarkeit) abhängen, die in den Prozess einfließen.

Letzteres ist eine wichtige Voraussetzung für den Erfolg; das bloße Ausfüllen eines Formulars, einer Vorlage oder einer Kalkulationstabelle reicht nicht aus, um die Ursache zu finden, denn die Problemanalyse baut auf einem festen Fundament harter Logik auf, die aktiv genutzt werden muss. Sie erfordert nach wie vor intensives Sammeln, Nachdenken und Überprüfen von Daten, was sich nicht von der Fehlersuche in einer unstrukturierten Umgebung unterscheidet. Die große Veränderung besteht darin, dass die Denkschritte sichtbar werden und einen Namen erhalten, und das alles auf der Grundlage eines klaren Plans für die Problemanalyse. Auf diese Weise können wir messen und mitteilen, wo wir uns befinden und wie wir bei der Suche nach der Ursache vorankommen.

In diesem Fall handelt es sich bei der Messung nicht um eine Datenbankabfrage, die zeigt, wie viel Zeit oder wie viele Tickets einen bestimmten Satz von Kriterien erfüllen. Es handelt sich vielmehr um eine Bewertung, die von internen (Problemlösungs-)Experten vorgenommen werden kann, die die Qualität der in den einzelnen Schritten der Problemanalyse gesammelten Daten beurteilen. Eine solche Bewertung wird dann zu einem führenden Leistungsindikator für die Qualität der Problemanalyse.

Wie geht es jetzt weiter?

Die Lektüre eines Buches über das Geigenspiel macht den Leser nicht zu einem großartigen Geigenspieler. In ähnlicher Weise ist es unwahrscheinlich, dass eine bloße Schulung einer Organisation, wie man bei der Fehlersuche besser denken kann, die Organisation in eine Weltklasse-Gruppe von Fehlersuchern verwandelt. Es erfordert Aufmerksamkeit, Übung und Hingabe, um den Ansatz in die Denkweise des Einzelnen einzubetten, und die Ergebnisse werden sich auszahlen. Die Investition in die Ursachenforschung im Problem Management unterstützt Investitionen in technische Fähigkeiten und Erfahrungen, die zu einer Belegschaft führen, die weiß und gut ausgerüstet ist, was nötig ist, um qualitativ hochwertige Lösungen für komplexe Probleme zu finden. Zu Beginn eines Problem-Management-Falles wird ein Manager (noch) nicht wissen, wie lange es dauern wird, bis die Ursache gefunden ist, aber es wird eine klare und geplante Richtung geben und die Ankunftszeit wird besser vorhersehbar sein, was die Messung der Qualität im Problem-Management ermöglicht.

Von Berrie Schuurhuis, Kepner-Tregoe

 

Über Kepner-Tregoe

Kepner-Tregoe ist führend auf dem Gebiet der Problemlösung. Seit mehr als sechs Jahrzehnten hat Kepner-Tregoe Tausenden von Unternehmen weltweit geholfen, Millionen von Problemen durch eine effektivere Ursachenanalyse und Entscheidungsfindung zu lösen. Kepner-Tregoe arbeitet mit Unternehmen zusammen, um Kosten erheblich zu senken und die betriebliche Leistung zu verbessern durch
Problemlösungsschulung, Technologie und Beratungsdienste.