Wir preisen häufig die Vorzüge intuitiven Denkens als leistungsstarkes Werkzeug bei der Entwicklung kreativer Lösungen an. Allerdings macht ein Hammer nicht jedes Problem zu einem Nagel. Oftmals kann kreatives Denken bei der Lösung komplexer, hochriskanter technischer Probleme geradezu schädlich sein. Strukturiertes (oder konvergentes) Denken kann eine Flut von Informationen organisieren, um verdächtige Datenlücken aufzudecken, und bringt Effizienz und Geschwindigkeit in die Problemuntersuchung. Die Verwendung eines konsistenten Ansatzes, der sich auf kritische Daten konzentriert und mit einer visuellen Darstellung dieses Denkens gekoppelt ist, verbessert die Kommunikation und Zusammenarbeit erheblich. Ganz zu schweigen von der deutlichen Beschleunigung der Suche nach der wahren Grundursache.
Hier ist ein Beispiel für Informationen, die in einem typischen Freitextfeld erfasst wurden:
Die DPM-Anwendung ist sowohl auf DC- als auch auf HQ-Seite nicht verfügbar, aber 80 % oder mehr der Daten wurden für 0 bis 4 Stunden in einem oder mehreren DCs nicht aktualisiert. IMOD wurde erst nach Ablauf von 4 Stunden über dieses Problem informiert. Incident Manager für Distribution wurde informiert.
Hier sind dieselben Informationen unter Verwendung eines strukturierten Denkansatzes:
Welches Format ist einfacher zu lesen und zu analysieren? Noch wichtiger: Welches Format zeigt Ihnen, was wir wissen UND was wir wissen müssen?
In einem Freitextfeld neigen wir natürlicherweise dazu, eines von zwei Dingen zu tun: a) Wir geben so viele Informationen wie möglich ein, um den leeren Raum zu füllen – unabhängig davon, ob die Informationen relevant sind oder nicht –, um die gesamte geleistete Arbeit zu zeigen; b) Wir lassen es leer. Dies ist nicht nur ein Problem für eine ordnungsgemäße Grundursachenanalyse (RCA), sondern auch ein Kommunikationsproblem für die Informationsübertragung, für Trendanalysen und für die Verknüpfung von Problemen mit Incidents und umgekehrt.
Das oben gezeigte Format beschreibt einen Teil des von ITIL® anerkannten Kepner-Tregoe-Ansatzes, den wir „Problemspezifikation“ nennen. Die Problembeschreibung (oben) und die acht Felder mit IST/IST-NICHT-Informationen ermöglichen es uns, auf einen Blick zu erkennen, was wir wissen und was wir nicht wissen. Es fördert kritisches Denken, gibt Struktur und erleichtert die Kommunikation.
Die Bedeutung einer qualitativ hochwertigen Problembeschreibung kann nicht hoch genug eingeschätzt werden (und sie ist nicht dasselbe wie der Fall-Titel). In unserer Arbeit mit globalen Support-Organisationen haben wir festgestellt, dass eine durchgängig korrekte Problembeschreibung die durchschnittliche Lösungszeit um 18 % oder mehr reduziert. Eine qualitativ hochwertige Problembeschreibung ist entscheidend für alles, was im RCA-Prozess folgt.
Betrachten Sie diese kursiv gedruckten Problembeschreibungen unterschiedlicher Qualität:
- Server-Probleme – Dies hat ein unklares Objekt und behandelt möglicherweise mehrere Probleme.
- Datenbankserver ausgefallen – Dies ist eine Verbesserung, aber wir können spezifischer sein. Welcher Server ist ausgefallen? Und wissen wir bereits, warum er ausgefallen ist? Wir möchten weiterhin nach dem Warum fragen, bis wir die Antwort nicht mehr kennen.
- Inventar-Datenbankserver hat keinen Speicherplatz mehr – Diese Beschreibung spezifiziert das Problem weiter und bereitet uns auf eine fokussierte Grundursachenanalyse vor. Die Beschreibung ist spezifisch, betrifft ein einzelnes Objekt und einen einzelnen Defekt, und die Ursache ist unbekannt. Hier kann unsere Problemanalyse beginnen.
Eine Anmerkung zur Dokumentation:
Dokumentation ist niemandes Lieblingsaktivität, aber sie ist wichtig. Niemand von uns verbringt gerne viel Zeit mit der Dokumentation, aber ohne sie gibt es kein wiederverwendbares Wissen für unsere Kollegen in der Organisation, keine Prüfspur und kein organisatorisches Lernen. Das Wichtigste ist, sich auf die kritischsten Informationen zu konzentrieren. Was Wissensmanagementsoftware betrifft, ist der Schlüssel, das Tool nach dem Prozess zu modellieren … und nicht umgekehrt.
Ein Engagement für strukturiertes, klares Denken bringt qualitativ hochwertige Ergebnisse, die die kritische IT-Stabilität fördern und echte Kosteneinsparungen erzielen, da wir aufhören, immer wieder dieselben Probleme zu lösen.
