step2.at

Das Erkennen und Registrieren eines Problems ist die eine Seite - die viel wichtigere ist aber, die Ursache zu finden und eine Lösung zu erarbeiten.

Es ist davon auszugehen, daß du Ursache bei Problemen nicht ohne weiteres zu finden ist (denn ansonsten wäre das Problem schon lange gelöst). Es gilt also, spezielle Techniken und Tools anzuwenden, um eine möglichst effektive und effiziente Ursachen-Analyse durchzuführen.

Entsprechend der nachfolgenden Grafik befinden wir uns im Schritt “Problem Control” mit dem Ziel eine Ursache für das Problem zu finden.

Vortrag während der itSMF Fusion 2008 von Jay Long (gesehen im Blog IT´s About Uptime)

Oft verwendete Hilfsmittel zur Ursachen-Ermittlung:

• Recherche in den vorhandenen Wissendatenbanken (u.a. in Incidents und Known Errors)
• Fehler chronologisch nachstellen (im Detail inkl. Ablauf-Protokoll), um die Ursache besser eingrenzen zu können
• Brarinstorming - kein Kommentar ;–> Wikipedia
• “Pain Value” Analyse - (aus ITIL v3) berücksichtigt mehrerer Faktoren (Anzahl betroffene User, Dauer des Ausfalls, Kosten des Ausfalls, etc.) und versucht so die Priorisierung zu verfeinern (behandelt also nur indirekt die Ursache) –> Link
• “Kepner & Tregoe” Methode - Problem definieren, im Detail beschreiben, mögliche Ursache identifizieren, was ist wahrscheinlich, überprüfen. –> Wikipedia, dazu im Problem Mgmnt Blog, itsmsolutions Beitrag, kepner-tregoe.com
• Ursache-Wirkung (Ishikawa)-Diagram - kein Kommentar
  ;–> Wikipedia, itsmsolutions Beitrag

Eine Methode die von vielen Praktikern favorisiert wird ist die “5 Whys” Methode - übersetzt 5 x Warum. Es ähnelt ein klein wenig an Kindererziehung, aber das Ziel ist event. das gleiche - Finde heraus was wirklich dahinter steckt! Hier einige Referenzen dazu: wie immer gibt es alles bei Wikipedia, aber auch Hank Marquis von itsmsolution hat eine kurze Zusammenfassung, genauso wie Dennis Powell im StockSafe Blog.

!! >> Für eine möglichst effiziente Recherche in bereits bekannten Themen ist die laufende Pflege der Wissendatenbanken bzw. der Known Error Datenbank wichtit. Darauf ist bei der Umsetzung der Prozesse zu achten.

!! >> Um Problem nachvollziehen zu können ist meist ein Test-System hilfreich (ähnlich wie auch beim Test von Changes). Daraus  ergibt sich, bei so vielen Systemen wie möglich, zumindet eine 2-System Landschaft.

!! >> Ziel ist es Ursachen zu finden und Probleme zu lösen - immer die für die Organisation und das Problem geeignete Methode auswählen. Auf keinen Fall mit blindem Aktionismus an das Thema ran gehen.

weitere Referenzen:

• Problem Management Blog von Ronald Bartels

Bleiben Sie up-to-date und lesen Sie auch die nächsten Folgen! Einfach den Feed abonnieren