Wie wir in den ersten und zweiten Artikeln dieser Reihe erläutert haben, ist die Bewertung der Qualität des Problem Managements in einer ITIL-Umgebung nicht immer einfach. Von der richtigen Fragestellung bis zur Festlegung, welche Kennzahlen zur Leistungsmessung herangezogen werden sollen, gibt es viele Variablen zu berücksichtigen. In diesem Artikel werfen wir einen genaueren Blick auf die „Magie“, die bei der Identifizierung der Grundursache eines Problems eine Rolle spielt.
Die wesentlichen Komponenten der Problemanalyse
Es gibt viele Wege, die Grundursache eines Problems zu finden – einige sind offensichtlich erfolgreicher als andere. Ohne ein standardisiertes Rahmenwerk werden unterschiedliche Personen naturgemäß unterschiedliche Vorgehensweisen wählen. Die Wirksamkeit jeder Gruppe von Troubleshootern liegt irgendwo entlang einer Glockenkurve. Den meisten Troubleshooting-Experten kann man mit gutem Gewissen nahezu jede Aufgabe übertragen. Solide Leistungsträger sind für die meisten Aufgaben geeignet, haben jedoch noch Verbesserungspotenzial, und diejenigen mit einem schlechten Troubleshooting-Ruf benötigen wahrscheinlich Unterstützung.
Die Kepner-Tregoe-(KT)-Methode der Problemanalyse wurde in den 1950er-Jahren erforscht und definiert und in den Jahrzehnten danach kontinuierlich weiterentwickelt und getestet. Offensichtlich war dies viele Jahre, bevor Computer allgegenwärtig waren – geschweige denn, bevor ITIL überhaupt für irgendetwas stand.
Es wurde argumentiert, dass eine Methode wie die von KT heute unmöglich für die IT-Branche geeignet sein könne, da weder IT noch ITIL existierten, als die KT-Methode erstmals erforscht wurde. Um zu einem angemesseneren Urteil zu gelangen, ist es entscheidend, die KT-Methode der Problemanalyse genauer zu betrachten. Die wesentlichen Schritte 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 Zielsetzungen und passende Teilschritte, die dabei helfen, die Fragen richtig zu formulieren und Antworten so zu dokumentieren, dass die richtigen Daten erhoben werden. All diese Eingaben fließen in den Denkprozess der Problemanalyse ein. Dies geschieht ohne ein bestimmtes Produkt oder ein konkretes Thema im Blick und ist ITIL sehr ähnlich, das für alle Arten von IT-Organisationen funktioniert. Die Problemanalyse ist ein Ansatz, um Grundursachen für viele unterschiedliche Probleme zu finden – unabhängig von Branche oder Technologie.
Die 3 Auslöser der Problemanalyse
Obwohl die KT-Methode für jede Art von Problem geeignet ist, gibt es bei KT eine sehr spezifische Definition des Begriffs „Problem“, die sehr gut zu ITIL passt. Nach KT müssen drei Kriterien erfüllt sein, bevor wir den Problemanalyseprozess auslösen:
Es sollte eine Lücke zwischen der tatsächlichen Leistung und der gewünschten Leistung bestehen. Das nennen wir eine Abweichung (z. B. Maschine funktioniert nicht, versus Maschine sollte funktionieren).
Die Ursache der Abweichung ist unbekannt (z. B. kein bekannter Fehler).
Es muss ein Bedarf bestehen, die Abweichung zu kennen (z. B. um Maßnahmen ergreifen zu können).
Durch das Durchlaufen eines klar definierten Schrittesets zur Ermittlung der Grundursache können Troubleshooter beginnen, zu kommunizieren und zu dokumentieren, was im Prozess bereits getan wurde und was noch zu tun ist. Ein Beispiel dafür, wie erhobene Daten modelliert werden, um die Symptome eines Problems zu beschreiben, ist in der Abbildung unten dargestellt.
Im nächsten und letzten Artikel werden wir untersuchen, wie die Problemanalyse das zentrale Rahmenwerk bereitstellt, um die Leistung im ITIL Problem Management wirksam zu messen.
