Zu verstehen, wie Analysten und Ingenieure an Problemen arbeiten, Ursachen finden und entsprechende Ma\u00dfnahmen 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\u00e4higkeiten zur Nutzung dieses Tools zu erfordern. <\/p>\n
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\u00fcssen, sind sehr klar definiert. <\/p>\n
Das Lesen von Problemtickets oder das Befragen von Problemmanagern, wie sie die Schritte in den Verfahren ausf\u00fcllen, scheint ein logischer n\u00e4chster Schritt zu sein, um mehr dar\u00fcber 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\u00e4hlen. Beispiele hierf\u00fcr sind: <\/p>\n
Angesichts der Ziele des Problemmanagements: Ursachen von Problemen zu finden und proaktiv Ma\u00dfnahmen zu ergreifen, um zuk\u00fcnftige Vorf\u00e4lle und Probleme zu vermeiden \u2013 wie gut zeigen die obigen Beispiele, wie erfolgreich ein Team diese Ziele erreicht? Fragen wir nach dem einen und messen etwas v\u00f6llig anderes? <\/p>\n
Nach etwa zwei Tagen einer Bewertung, wie das Problemmanagement in einer globalen IT-Abteilung eines weltweit t\u00e4tigen Unternehmens gehandhabt wurde, beschlossen wir, eine Pause einzulegen, um unsere Ergebnisse unter den Teilnehmern der Bewertung zu vergleichen. Zu den Feldern, die zur \u00dcberpr\u00fcfung herangezogen wurden, geh\u00f6rten die Ticketzusammenfassung und die Problembeschreibung sowie individuelle Fortschrittsaktualisierungen und die Beschreibungen der Probleml\u00f6sung. <\/p>\n
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\u00f6sungsbeschreibung zu einem Abschluss kam. <\/p>\n
Obwohl dies wie ein Einzelfall erscheint, repr\u00e4sentiert es das Muster, das im Bewertungsteam beobachtet wurde. Im Gespr\u00e4ch \u00fcber andere Erfahrungen entstand das folgende Bild, das die beobachteten Sachverhalte darstellt: <\/p>\n
Dies wirft eine Reihe von Fragen dazu auf, wie Schlussfolgerungen gezogen und Ma\u00dfnahmen ergriffen oder geplant wurden:<\/p>\n
Antworten auf diese Fragen k\u00f6nnen einen guten Einblick geben, wie bei einem beliebigen Ticket im Problem Management Wert geschaffen wurde. Die Antworten auf diese Fragen h\u00e4ngen in der Regel nicht mit zeitlichen oder numerischen Parametern der Problem-Management-Verfahren zusammen. Es geht vielmehr um die Qualit\u00e4t der Datenerfassung und die Qualit\u00e4t der Denkprozesse der beteiligten Personen. <\/p>\n
Manche m\u00f6gen behaupten, dass, wenn \u201eMagie\u201c gut gemacht wird, das Unternehmen eine geringe Anzahl wiederkehrender Probleme sehen wird, was oben als Leistungsindikator f\u00fcr das Problemmanagement angegeben wurde. Das stimmt! <\/p>\n
Leider.<\/p>\n
Was ein Unternehmen durch wiederkehrende Probleme erh\u00e4lt, 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\u00fcr die Leistung des Problemmanagements. Was wirklich ben\u00f6tigt wird, ist eine M\u00f6glichkeit, 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\u00fchrenden Leistungsindikatoren f\u00fcr das Problemmanagement? <\/p>\n
Ma\u00dfnahmen zu finden, die anzeigen, wie gut Probleme gel\u00f6st wurden, mag bei einfachen (wenig kritischen) Problemen, bei denen ein Wiederauftreten zwar unerw\u00fcnscht, aber nicht katastrophal w\u00e4re, nur eine geringe Wirkung haben. Einige Unternehmen haben gelegentlich kritische Vorf\u00e4lle und Probleme, bei denen sie am Rande eines katastrophalen Gesch\u00e4ftsereignisses stehen, das mit einem oder mehreren IT-bezogenen Ereignissen verbunden ist, und sie beschlie\u00dfen, diese Erfahrung nie wieder zu machen! Das Messen wiederkehrender Probleme und Trends ist wahrscheinlich keine ausreichend gute Metrik. <\/p>\n
Fragt man Ingenieure und Analysten nach ihren internen Denkprozessen bei der Bearbeitung von Problemtickets, erh\u00e4lt man viele verschiedene Antworten. Dies unterscheidet sich v\u00f6llig 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: <\/p>\n
Angesichts dieser Faktoren ist es bemerkenswert, dass es oft keinen gemeinsamen Ansatz f\u00fcr die Problembehandlung gibt. Infolgedessen bleibt dies \u201eMagie\u201c. <\/p>\n
Wenn eine Best Practice zur Ermittlung von Grundursachen f\u00fcr Probleme etabliert ist, bietet sie sehr \u00e4hnliche Vorteile wie eine Best Practice zur Konfiguration eines Assets. Au\u00dferdem w\u00fcrde sie eine neue Sprache f\u00fcr die Fehlerbehebung mit einer Terminologie erm\u00f6glichen, die die Dokumentation dessen, wie die \u201eMagie\u201c aussieht und wie Schlussfolgerungen gezogen werden, erlaubt. <\/p>\n
Es gibt viele Wege, die Grundursache eines Problems zu finden. Einige sind erfolgreicher als andere, und verschiedene Personen (ohne einen Standardrahmen) haben naturgem\u00e4\u00df unterschiedliche Ans\u00e4tze. Die Effektivit\u00e4t jeder Gruppe von Fehlerbehebern liegt irgendwo auf einer Glockenkurve. Fehlerbehebungsexperten haben einen guten Ruf und k\u00f6nnen mit Zuversicht jede Aufgabe \u00fcbernehmen. Solide Leistungstr\u00e4ger sind f\u00fcr die meisten Aufgaben gut geeignet und haben Raum zur Verbesserung, und diejenigen mit einem schlechten Ruf in der Fehlerbehebung ben\u00f6tigen wahrscheinlich Hilfe. <\/p>\n
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. <\/p>\n
Es wurde argumentiert, dass eine Methode, die so lange existiert, f\u00fcr 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\u00e4llen. Die Hauptschritte der Problemanalyse bestehen aus: <\/p>\n
F\u00fcr jeden dieser Schritte gibt es klare Absichten und einige Unterschritte \u2013 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 \u00e4hnlich zu ITIL, das f\u00fcr alle Arten von IT-Organisationen funktioniert. Die Problemanalyse ist ein Ansatz zur Ermittlung der Grundursache f\u00fcr viele verschiedene Probleme, unabh\u00e4ngig von Branche oder Technologie. <\/p>\n
Nun ja\u2026 ja! Aber es gibt eine sehr spezifische KT-Definition des Begriffs \u201eProblem\u201c, die anders ist, aber recht gut zu ITIL passt. Laut KT m\u00fcssen drei Kriterien erf\u00fcllt sein, bevor wir den Problemanalyseprozess ausl\u00f6sen: <\/p>\n
Das Ergebnis der Durchf\u00fchrung einer klar definierten Reihe von Schritten zur Ermittlung der Grundursache ist, dass Fehlerbeheber beginnen k\u00f6nnen, zu kommunizieren und zu dokumentieren, was bereits getan wurde und was im Prozess noch zu tun ist. Ein Beispiel daf\u00fcr, wie gesammelte Daten textuell modelliert werden, um die Symptome eines Problems zu beschreiben, ist in der Abbildung unten dargestellt. <\/p>\n
Wenn die Schritte f\u00fcr einen konsistenten und reproduzierbaren Ansatz zur Problemanalyse gut verstanden sind, wird die Messung der Qualit\u00e4t einer gefundenen Grundursache viel einfacher. Wenn die \u201eMagie\u201c bei der Ermittlung der Grundursache verstanden wird, kann sie dokumentiert, reproduziert, reibungslos \u00fcbergeben und effizient zeitlich geplant werden; all dies sind Merkmale einer Best Practice. <\/p>\n
Sobald eine IT-Supportorganisation einen einheitlichen Ansatz zur Problemanalyse verwendet, kann die unmittelbare Qualit\u00e4t oder der Wert von Einzelpersonen und Teams gemessen werden. Genau das tun KT-Berater, wenn sie die Qualit\u00e4t bestehender Fehlerbehebungsprozesse in einer IT-Supportumgebung bewerten. Durch das Lesen bestehender Incident- und Problemtickets und die Einsch\u00e4tzung, wie stark der Ansatz an einen bekannten Standard angepasst werden muss, k\u00f6nnen wir helfen, einen grundlegenden Fr\u00fchindikator f\u00fcr die Qualit\u00e4t der Fehlerbehebung zu generieren. <\/p>\n
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: \u201eWas ist falsch mit was?\u201c), verbringen im Durchschnitt etwas mehr als 10 Prozent weniger Zeit, bevor eine Grundursache gefunden wird.<\/p>\n
Das alles mag so einfach klingen, dass es nicht wahr sein kann \u2013 allein die Dokumentation des Objekts und des Fehlers, f\u00fcr die Experten die Grundursache finden wollen, spart etwas mehr als 10 Prozent der Zeit bis zum Abschluss. Nun, Sie k\u00f6nnten Recht haben: Es mag einfach klingen, aber das ist es nicht. Um diesen Denkprozess zu verinnerlichen und reflexartig zu machen, bedarf es einer Verhaltens\u00e4nderung, und in der Hitze des Gefechts, unter Zeit- und anderem Druck des Gesch\u00e4fts, kann dieser einfache Schritt beiseitefallen, wenn er nicht abseits der Hochdruckthemen ge\u00fcbt und unterst\u00fctzt wird. Die Schritte zur Implementierung einer Best Practice f\u00fcr die Fehlerbehebung sind gut verstanden, aber die Umsetzung erfordert dennoch Aufmerksamkeit, Fokus, gute Planung und \u00dcberlegung. Gl\u00fccklicherweise ist Denken einfach, aber Implementierungsteams k\u00f6nnen 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\u00fchrt, und der Erfolg bei der Ermittlung der Grundursache kann je nach Qualit\u00e4t der Daten (und Beobachtbarkeit), die in den Prozess einflie\u00dfen, variieren. <\/p>\n
Letzteres ist ein Schl\u00fcssel zum Erfolg; das blo\u00dfe Ausf\u00fcllen 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 \u00dcberpr\u00fcfung, was sich nicht von der Fehlerbehebung in einer unstrukturierten Umgebung unterscheidet. Die gro\u00dfe Ver\u00e4nderung besteht darin, dass die Denkschritte sichtbar werden und einen Namen erhalten, alles basierend auf einem klaren zugrunde liegenden Plan f\u00fcr die Problemanalyse. Als Ergebnis dessen k\u00f6nnen wir messen und kommunizieren, wo wir stehen und wie wir im Prozess der Grundursachenfindung vorankommen. <\/p>\n
In diesem Fall ist Messen keine Datenbankabfrage, die zeigt, wie viel Zeit oder wie viele Tickets eine bestimmte Reihe von Kriterien erf\u00fcllen. Es f\u00fchrt zu einer Bewertung, die von internen (Fehlerbehebungs-)Experten vorgenommen werden kann, die die Qualit\u00e4t der gesammelten Daten in den einzelnen Schritten der Problemanalyse beurteilen. Eine solche Bewertung wird dann zu einem f\u00fchrenden Leistungsindikator f\u00fcr die Qualit\u00e4t der Problemanalyse. <\/p>\n
Ein Buch \u00fcber das Geigenspiel zu lesen, macht den Leser nicht zu einem gro\u00dfartigen Geiger. Ebenso wird die blo\u00dfe Schulung einer Organisation, wie man besser in der Fehlerbehebung denkt, die Organisation wahrscheinlich nicht zu einer Weltklasse-Gruppe von Fehlerbehebern machen. Es erfordert Aufmerksamkeit, \u00dcbung 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\u00fctzt Investitionen in technische F\u00e4higkeiten und Erfahrungen, die zu einer Belegschaft f\u00fchren, die sich bewusst ist und gut ger\u00fcstet ist, was es braucht, um qualitativ hochwertige L\u00f6sungen f\u00fcr 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\u00e4t im Problemmanagement erm\u00f6glicht. <\/p>\n
Von Berrie Schuurhuis, Kepner-Tregoe<\/p>\n
\u00a0<\/p>\n
Kepner-Tregoe ist f\u00fchrend in der Probleml\u00f6sung. Seit \u00fcber sechs Jahrzehnten hat Kepner-Tregoe Tausenden von Organisationen weltweit geholfen, Millionen von Problemen durch effektivere Ursachenanalyse und bessere Entscheidungsf\u00e4higkeiten zu l\u00f6sen. Kepner-Tregoe arbeitet mit Organisationen zusammen, um Kosten deutlich zu senken und die operative Leistung zu verbessern \u2013 durch Trainings zur Probleml\u00f6sung, Technologie und Beratungsleistungen. <\/p>\n","protected":false},"excerpt":{"rendered":"
Ein genauerer Blick auf die Durchf\u00fchrung des Problemmanagements Zu verstehen, wie Analysten und Ingenieure an Problemen arbeiten, Ursachen finden und entsprechende Ma\u00dfnahmen 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\u00e4higkeiten […]<\/p>\n","protected":false},"author":8,"featured_media":36926,"template":"","white-paper-type":[],"class_list":["post-63762","white-paper","type-white-paper","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\n