Incident-Management-Lösung ohne geeignetes Backup – die Folgen oder wie hätte man es besser machen können

In meinem letzten Blogeintrag habe ich noch über das Fehlen des Problemmanagers und die daraus aus meiner Sicht zu empfehlenden Schritte berichtet. Dabei war eine meiner Empfehlungen, einen umfassenden Incident-Management Prozess zu etablieren. Hier scheint meine Empfehlung zu knapp ausgefallen zu sein, wie eine aktuelle Kundensituation beweist.

Wie vorteilhaft ist es doch, einen Incidentprozess mit einem passenden IT-Tool zu unterstützen. Dies ist in allen Belangen von Vorteil, da somit Incidents effizient und nachhaltig bearbeitet werden können.  Auch der Problem Management Prozess kann aus solch einer Lösung seine Vorteile ziehen und die Aufarbeitung seiner Erkenntnisse mit maschineller Unterstützung datentechnisch detailliert begründen.

 

Was aber passiert, wenn die beste Dokumentation von Prozessen besteht, aber das Betriebshandbuch für die IT-Lösung nur rudimentär existiert: Man hofft insgeheim, dass der Worst-Case-Fall nie eintreten mag – der Ausfall des IT-Tools für den Incidentprozess. Und in diesem Fall trafen mehrere Problemstellungen zusammen: Der Anwendungsverantwortliche verlässt das Unternehmen und wegen Personalmangel findet nur eine rudimentäre Übergabe an den Nachfolger statt. Dieser hat nur noch einen Bruchteil der Zeit für die Wartung des Systems.

 

Das unvermeidliche passiert: Über Monate hinweg bauen sich wegen einer nicht ausreichend leistungsfähigen Datenbank Inkonsistenzen im Datenbestand unbemerkt auf. Und dann folgt der Systemausfall. Alle Sicherungen der letzten Tage, Wochen und Monate können nicht genutzt werden, da diese wegen eines falschen und nicht vollständig getesteten Sicherungskonzeptes unbrauchbar sind. Und eine explizite Sicherung der Datenbank war gar nicht im Konzept erhalten. Viele werden sagen: „Dies ist doch gar nicht möglich, da kennt jemand das 1x1 der Sicherung der Datenbankanwendungen nicht“ Sicherlich mögen diese Spezialisten nicht unrecht haben, aber geschehen ist es dennoch.

 

Und die Konsequenz: Tagelanger Systemausfall, das System wurde von Grund auf neu installiert und parametrisiert. Im Anschluss wurden mit großem Aufwand die historischen Informationen aus den Fragmenten der alten Sicherungen wieder hergestellt - Gesamtaufwand bis weitestgehend wieder auf alle Daten zugegriffen werden konnte beträgt mehrere Wochen.

 

Alle sind sich einig: Da hat man einen dokumentierten, von einem IT-Tool unterstützten Prozess der aber nur in seiner Gesamtheit so gut ist wie das schwächste Glied in der Kette.

 

Von daher bedenken Sie immer:
Auch wenn man eine detaillierte ausgereifte Prozessbeschreibung erstellt, sichert dies noch lange nicht den Erfolg in der Einführung und der Umsetzung der Prozesse im Arbeitsalltag. Sorgen Sie auch dafür das Themen, wie ein vollumfängliches und durch Tests abgenommenes Betriebshandbuch für den Prozess unterstützende Tools umgesetzt werden.

 

Und wenn man dies dann durch regelmäßige Reviews qualitätsgesichert, sollte einem erfolgreichen Lebenszyklus des entsprechenden Prozesses nichts mehr im Wege stehen.

 

Autor: Alexander Reinhard

April 2018

Abonnieren Sie

http://www.itil.de/rss/blog

unseren Blog itil.de

Unsere Mission

Wir leisten einen Beitrag zu besserem IT Service Management durch die pragmatische Auseinander-setzung mit ITIL und verwandten Themen.

Werbung

Wollen Sie ITIL-Experte werden? Dann lassen Sie sich zertifizieren bei

expertplace academy
expertplace academy
ITSM Consulting
ITSM Consulting