Eine schöne Stelle an der Theorie und Praxis auseinanderlaufen sind Störungen deren Ursache nicht ergründet wird. In Kardinalfällen sogar Störungen, die nie behoben werden. In der Theorie hat jede Störung eine Ursache, die dann irgendwann behoben ist. In der Praxis sorgen einige Umstände dafür, dass dem nicht so ist.
Akzeptable Workarounds
Ein Problem von Fehlerbeseitigung ist, dass dadurch Folgefehler entstehen können. Deshalb wird gerade in kritischen Umgebungen nur sehr zögerlich eingegriffen. Wenn ein Fehler durch einen Workaround (Umgehungslösung) so stark abgemildert werden kann, dass er kaum noch auffällt, kann dies die Lösung sein. Bitte daran denken den Workaround dann so zu behandeln, d.h. wirklich auch als Change genehmigen zu lassen.
Incidents verschwinden
Meiner Zeit als Software Engineer habe ich mal gelernt „Fehler verschwinden nie“. Beim Entwickeln einer Software kommt es vor, dass nach einem Probelauf sagen wir 10 Fehler gefunden wurden. Nun nimmt sich der Programmierer des Fehlers #1 an und startet aus Neugier den nächsten Probelauf. Siehe da: Neben Fehler #1 ist auch #7 verschwunden. Was nun? Ordentliche Programmierer lassen Fehler #7 auf der Liste und gehen dem nach. Faule Programmierer streichen Fehler #7 von der Liste als „gelöst“. Mit auch nur etwas Pech taucht Fehler #7 drei Monate später beim Kunden auf.
Gerade beim Betrieb von Desktop-Computern ist es heutzutage üblich recht schnell zum Mittel „Erstmal alles Plattmachen“ zu greifen. Das heißt der Computer wird neu aufgesetzt, der Fehler verschwindet. Die Statistik gibt dieser Vorgehensweise Recht. Leider gibt es ab und zu Fälle in denen der Fehler nach Tagen wieder da ist. Nachdem der Computer drei Mal neu aufgesetzt wurde, sind 8 Arbeitstage vergangen und alle Beteiligten genervt.
Zombie Tickets
Obiges könnte dann in einem Zombie Ticket enden. Ein Untoter, der immer wieder aufsteht. Gründe für Störungen, die man nicht mehr los wird, gibt es viele. Oft liegt es daran, dass dem Vorfall keine Bedeutung zugemessen wurde und nachdem die Sache so richtig angebrannt ist, mag sich keiner mit den Beteiligten zusammensetzen und die Sache aus der Welt schaffen. Mangelndes Interesse der Fachverantwortlichen für Endanwender ist ein häufiger Grund, es kann aber auch am Endanwender liegen. Ich kenne einen Fall, da hat ein Endanwender immer wieder die Nicht-Verfügbarkeit eines Service gemeldet. Dieser Service war von seinem Management abbestellt (bzw. reduziert) worden. Vermittlungsversuche des Service Desks waren nicht erfolgreich. Das Management fand sich nicht zuständig. Wann immer dieser Incident geschlossen wurde, nach 10 Minuten war er wieder gemeldet.
Ist der Fehler wichtig?
Wo wir gerade beim Endanwender sind. Vor allem bei Fehlern, die per E-Mail oder Portal gemeldet werden kommt es erstaunlich oft vor, dass Nachfragen vom Service Desk nicht beantwortet werden. Oftmals haben ITSM Tools Workflows, die nach einigen Tagen Wartezeit ohne Antwort diese Störungen schließen. Da gibt es die lustigsten Geschichten zu erzählen. Ein Anwender meldete ein Druckerproblem via Portal „mein Drucker geht nicht“. Es gab aber nur zentrale Drucker, der Service Desk kannte diese Person und „seinen“ Drucker. Der Agent schaltete sich auf das Druckermanagement-Tool und rief den Benutzer an. Dieser „Nein, alles wieder in Ordnung“. Im Management-Tool sah man hübsch animiert wie Klappen und Schubladen an dem Drucker geöffnet und geschlossen wurden. „Können wir nicht doch helfen?“. „Nein, Nein, alles Prima“. Das Wartungsteam fand eine Laserdrucker ungeeignete Folie um das Druckerinnere gewickelt.
Okay, halten wir aber fest, meist liegt es daran, dass entweder die Störung anderweitig beseitigt wurde. Das ist schlecht für den Service Desk. Oder auch vielfach daran, dass das Problem nicht mehr akut ist. Bedeutet im Klartext bei dem nächsten Quartalsreport gibt es wieder eine Störungsmeldung.
Versionsvielfalt keine Prio
Das letzte was mir zu ungelösten Incidents einfällt: Es gibt natürlich auch Umgebungen mit ungemangten Desktops, da wird sowohl aus dienstlichen Gründen hinzu-installiert, als auch aus fraglichen Gründen z.B. irgendwelche Clipboard-Tools oder auch definitiv un-dienstliche Dinge. Wenn dort ein Fehler auftaucht kann es gut sein, dass sich niemand in der Lage fühlt dem nachzugehen. Das ist genau der Grund warum es in ITIL® neben dem Incident Management noch Release und Change Management gibt .
P.S.: Falls Ihr die die Möglichkeit habt ungelöste Incidents oder Zombies zu analysieren, diese sind ein sehr schöner Indikator: a) für einen schlechten Reifegrad, b) eine zu mächtige interne IT oder c) politisch schweres Terrain. Was von den drei Punkten im argen ist, gilt es dann auf anderen Wegen herauszufinden.
P.P.S.: Ab wann ist denn eigentlich eine Umgebung „kritisch“, so dass man nicht mehr gerne daran ändert? In einem chaotischen Warenlager reißt man gerne schon mal beim Aufstellen eines kleinen Regals ein bestehendes Regal mit dem Hintern um 🙂