Change, Problem, Incident – wenn die Lösung das Problem ist

„Nein, wir haben keine Probleme“, „davon habe ich nichts gewusst“, „unser System ist fehlerfrei“, „es gibt Wichtigeres zu tun, wir haben keine Zeit dafür“. Derartige Aussagen habe ich im IT-Service-Management (ITSM) schon häufig gehört. Und vielleicht sind auch dem einen oder anderen Leser diese Überzeugungen bekannt. Gerade für ein so diffiziles Thema wie das CPI-Management (Changes, Problems und Incidents) ist es jedoch entscheidend, dass der alltägliche Service-Betrieb auf einem soliden Fundament aufbaut. Im Idealfall gilt: Normalbetrieb statt Dauerkrise.

Keine ITSM-Prozesse, keine Verbesserungen

Theoretisch sollten Incidents, Probleme und Changes in einem harmonischen Einklang sein und Hand in Hand arbeiten – das Best-Case-Szenario. Aber so reibungslos läuft es leider nur selten ab. In einigen Organisationen fehlt es an den notwendigen Prozessen, oder das Thema wird nur halbherzig gelebt. Meine persönlichen Favoriten sind diese drei Denkfehler, die eine Verbesserung blockieren.

1. Etwas nicht wahrhaben wollen

Bei einem Unternehmen hat sich in einer Analyse gezeigt, dass die Versionierung der Serversysteme veraltet ist und auch schon in der Vergangenheit zu vermehrten Incidents geführt hat. Aber was noch viel gravierender ist: Veraltete Systeme sind ein sehr hohes IT-Security-Risiko!

Da fragt man sich zwangsläufig: Wieso lässt man es so weit kommen? Die Antwort darauf dürfte keinem gefallen: „Es läuft doch, und es ist noch nichts passiert! Außerdem haben wir aktuell keine Ressource, die sich dem Thema annehmen kann.“ Das Problem war bekannt und die Sicherheitsbeauftragten haben täglich auf das Risiko hingewiesen, aber da noch nichts passiert war, wollte man das Risiko nicht wahrhaben. Es ist keine gute Strategie, mit offenen Augen ins Messer zu laufen!

2. Bloß nicht zu viel kommunizieren

Donnerstag, 08:30 Uhr, und die Telefone beim First Level Support laufen heiß. Hunderte Anwender beschweren sich, dass die Software nicht mehr läuft: Entweder erscheint „503 (Service Unavailable)“, oder der Ladekreis dreht sich ewig. Nichts läuft mehr, und alle sind genervt. Nachdem sich der erste Sturm gelegt hat, das System wieder hochgefahren wurde und sich die Wogen geglättet haben, kam die Information, dass gestern Changes eingeleitet wurden.

Was jedoch niemand bedacht hatte: Bei der letzten Change-Implementierung wurde ein CronJob eingespielt, der alle 24 Stunden ausgelöst wird und mit einem neuen Change kollidierte– und da hatten wir den Salat. Die Gretchenfrage: Wieso wussten wir nichts von einem so großen Change? Wir hätten doch alle Betroffenen proaktiv informieren können. In der Tat: Mit einem anständigen Change-Plan oder einem etablierten Kommunikationsprozess hätte man alle Beteiligten informieren und Konflikte vermeiden können.

3. Dokumentation ist zu aufwändig

In einem Projekt haben wir mittels der Status-Quo-Analyse herausgefunden, dass 35 Prozent der Incidents meist den gleichen oder einen ähnlichen Auslöser aufweisen. Auf den ersten Blick hatte es den Anschein, dass die Ursache des Problems noch nicht gelöst und ständig Workarounds genutzt wurden – an sich nicht wirklich problematisch. Was aber nach weiterer Nachforschung ans Licht kam, war, dass es keine Dokumentation gab. Jeder noch so gleiche Incident wurde jedes Mal neu bearbeitet.

Irgendwo in einem alten Teams-Chat wurde dann die Lösung gefunden. So entwickelte sich aus einem Incident, der innerhalb von 15 Minuten von einer Person mit ausreichender Dokumentation hätte behoben werden können, ein langer Kommunikationsweg zwischen mehreren Personen über drei Tage. Hier wurden viel zu viele Ressourcen und Stunden investiert. Einfacher wäre es gewesen, wenn man einen Incident angelegt hätte, auf den alle Beteiligten Zugriff haben. Alles gut zu dokumentieren und zu verwahren ist wichtig, denn man weiß nie, wann diese Daten wieder benötigt werden.

Diese drei Denkweisen wirken bisweilen banal, aber sie finden sich immer noch in vielen IT-Organisationen. Insofern kommt es im ersten Schritt der Verbesserung nicht darauf an, Strukturen und Tools im ITSM zu verändern, sondern die Einstellung der Verantwortlichen zu prüfen und gegebenenfalls anzupassen. Incidents und Probleme sind keine Schande, sondern eine Steilvorlage für die Optimierung. Denn wenn das Fundament bröckelt, kann sich aus einem scheinbar kleinen Vorfall sehr schnell eine große Krise entwickeln.

Quelle Titelbild: AdobeStock/Andreas Prott