Von Andrew Vermes, Kepner-Tregoe
Jeden Tag haben wir diese „Homer-Simpson“-Momente: Sie schauen auf ein neues Projekt und haben das Gefühl, dass wahrscheinlich etwas schiefgehen wird, aber aus verschiedenen Gründen (Zeit, Stress, Budget) tun Sie nichts. Und dann passiert es … D’oh!
Was schätzen Sie: Wie viel Prozent der Themen/Probleme/negativen Ereignisse hätten Sie kommen sehen können? In einem aktuellen Webcast, in dem wir IT-Service-Profis diese Frage gestellt haben, antworteten sie überwältigend, dass ein erheblicher Anteil der Probleme hätte verhindert werden können – mit Angaben zwischen 20 % und 85 %.
IT-Incidents sind wie Zecken: Vieles spielt sich unter der Oberfläche ab. Bleibt ein Zeckenbiss unbemerkt, können Wochen, Monate oder Jahre vergehen – und in den schlimmsten Fällen wird dann Borreliose diagnostiziert. Wie bei Zeckenbissen sind es die kleinen, nadelstichartigen Störungen, die größere Probleme ankündigen. Vorbeugen ist am besten. Sie müssen bereit und vorbereitet sein – nicht nur, um den ersten „Biss“ zu verhindern, sondern auch, um Maßnahmen für den Fall der Fälle zu ergreifen, die das Problem abmildern, sobald es eingetreten ist.
Warum unnötige Risiken eingehen? Betrachten Sie einen IT-Incident und seine Auswirkungen, wie in dieser Grafik dargestellt. Die Risiken entwickeln sich weiter und können enorm sein.
Warum gehen Menschen also Risiken ein? Die Konsequenzen werden nicht ausreichend erkannt und angemessen bewertet. Während die Kosten der Incident-Bearbeitung häufig gemessen werden (Teile, Arbeitszeit, Anfahrt zur Behebung des Problems), ist es schwierig, die tatsächlichen Kosten für den Ruf einer Organisation nach einer Ausfallzeit zu beziffern. Haben Sie Kunden dauerhaft verloren? Was ist sonst noch passiert? Verlorene Arbeitszeit ist schwer zu beziffern. Der Produktivitätsverlust kann enorm sein, doch die Gründe, nicht proaktiv und präventiv zu handeln, sind tatsächlich ziemlich schwach. Wenn Sie die Kosten von Incidents und die verschiedenen Kosten durch verlorene Arbeit zusammenrechnen, ist das erschreckend. Risikomanagement lohnt sich.
Stabilität und Konsistenz sind der Weg, um den größtmöglichen Nutzen aus der Arbeit zu ziehen. Um konsistent zu arbeiten, ist es notwendig, Risiken zu managen. Ob Sie Kepner-Tregoe-Methoden der Potenzialproblem-Analyse (PPA) oder eine andere Methode wie FMEA verwenden (die ebenfalls wirksam ist, aber länger dauert): Es ist entscheidend, dies vorauszusehen und Risikomanagement umzusetzen.
Manchmal lohnt es sich, einen Schritt zurückzutreten und zu bewerten, was zuerst angegangen werden muss, bevor man in die Risikoanalyse einsteigt. Möchte ich eine Risikobewertung durchführen oder sollte ich die getroffene Entscheidung überprüfen? Sollten wir Risiken antizipieren oder sollten wir ein konkretes Problem lösen?
Wenn die Risikoanalyse das Richtige ist, gehen Sie weiter vor, indem Sie diese vier Fragen stellen:
1. Was könnte bei dieser Aktivität oder diesem Prozessschritt schiefgehen?
2. Warum könnte das passieren?
3. Wie können wir das verhindern?
4. Welche Maßnahmen für den Fall der Fälle bzw. Backup-Pläne sind erforderlich, wenn die Präventivmaßnahme scheitert?
Allzu oft ist die Risikoanalyse zu stark vereinfacht. Wenn wir zum Beispiel fragen: Was könnte schiefgehen? Dann ist unsere Antwort eindimensional: Ein Upgrade könnte fehlschlagen. Wenn wir fragen: Was werden wir tun? Dann stellen wir uns eine einzige Vorgehensweise vor: es zurückrollen.
Leider reicht das möglicherweise nicht aus. Risiken granularer und detaillierter zu planen, ist deutlich wirksamer. Im selben Beispiel halten wir konkret fest: Wir haben 12 Stunden Zeit, um unsere Storage-Management-Software auf Release 5.20 zu aktualisieren.
1. Was könnte schiefgehen?
- Es ist nicht genug Zeit, um das Upgrade in 12 Stunden durchzuführen
- Die Systemadministratoren könnten einen Fehler machen, der Zeit kostet
- Ein Bug im Upgrade-Skript führt dazu, dass das Upgrade fehlschlägt
- Ein latenter Fehler in den Maschinen der Kunden führt dazu, dass das Upgrade fehlschlägt
2. Warum?
- Das Root-Dateisystem ist zu klein, wir können bestehende Patches nicht zurücknehmen, es gibt latente Beschädigungen der Patch-Dateien
- Die Systemadministratoren sind abgelenkt, es gibt Lücken in den zu befolgenden Upgrade-Prozeduren, etwas Unerwartetes tritt auf
3. Wie können wir das verhindern (Präventivmaßnahmen)?
- Das Upgrade vorab üben
- Das Upgrade für Systemadministratoren priorisieren, Prozeduren erstellen und testen, die Systemadministratoren die Übung durchführen lassen
- Probleme in der Support-Datenbank prüfen und das Upgrade überprüfen
- Die Maschine prüfen, beim Test eine Kopie der Kundenumgebung verwenden, die Maschine in Festplattenlayout und Architektur identisch machen, verifizieren, dass das Upgrade auf dem aktuellen Betriebssystem läuft
4. Welche Maßnahmen für den Fall der Fälle/Backup-Pläne sind erforderlich, wenn wir nicht in 12 Stunden upgraden
- Das Upgrade abbrechen, den Originalzustand wiederherstellen und die Funktionalität testen
- Die Schwere des Fehlers bewerten und das Upgrade abbrechen, wenn es nicht rechtzeitig wieder auf Kurs gebracht werden kann
- So viele Daten wie möglich über den Upgrade-Fehler sammeln und in Support-Datenbanken nach weiteren Informationen suchen
- Versuchen, das Problem zu beheben, oder das Upgrade abbrechen
Wirksames Risikomanagement erfordert Aufmerksamkeit für Details. Bevor Sie eine bedeutende Maßnahme ergreifen, lohnt es sich, die Details der Risikobewertung zu prüfen und zu handeln, wenn irgendein Teil vage oder interpretationsfähig ist.
Wann eine Risikoanalyse durchgeführt werden sollte
Im ITIL-Framework ist eine Risikoanalyse angezeigt, sobald eine Lösung oder ein Workaround identifiziert wurde und bevor sie umgesetzt wird (siehe gelbe PPA in der ITIL-Grafik).
Dasselbe Timing gilt in Fertigungssituationen und in anderen Unternehmen. Bevor Sie eine bedeutende Maßnahme ergreifen, die voraussichtlich die Art Ihres Prozesses verändert, führen Sie eine detaillierte Risikoanalyse durch und protokollieren Sie die Risiken der vorgeschlagenen Präventiv- und Maßnahmen-für-den-Fall-der-Fälle-Aktionen sowie der tatsächlich umgesetzten. Neben der Vorbereitung auf und der Vermeidung von Risiken erhöhen Sie damit auch die Aussagekraft künftiger Risikoanalysen.
Aber warum warten? Risikomanagement muss nicht erst beginnen, wenn Veränderungen geplant werden. Kleine Störungen können größeren Incidents vorausgehen. Das sind die Ausgangspunkte für Proaktivität. In jedem komplexen System passieren ständig kleine Dinge. Fast jeden Tag ist manches ein wenig „off“. Es lohnt sich, sie zu beachten, bevor es viele Störungen gibt und die Situation eskaliert und schwierig wird. Sobald ein Problem besteht, ist es schwieriger, im Nachhinein diese kleinen Dinge zu finden, wenn sie zuvor nicht festgehalten wurden.
Gut eingespielte Event-Management-Systeme achten auf Störungen – aber was überwachen Sie? Woher wissen Sie, welche Variabilitäten wichtig sind? Eine Möglichkeit ist, Nutzer zu bitten, Ihnen zu melden, wenn kleine Dinge passieren – selbst wenn nichts schiefläuft. Indem Sie die Anomalien, die Nutzer betreffen, früher bemerken, können Dinge bereinigt werden, bevor es kritisch wird. IT-Support-Mitarbeitende, die regelmäßig Probleme bearbeiten, können proaktive Tickets nutzen, um kleine Störungen zu dokumentieren: kein Problem gemeldet, aber wir haben ungewöhnliches Verhalten festgestellt. Protokollieren Sie es und betreiben Sie Risikomanagement. Proaktive Tickets können die Zuverlässigkeit erheblich verbessern. Proaktivität ist wie eine Versicherung. Besser, man hat sie, als ohne sie zurechtkommen zu müssen.
Erste Schritte
Probieren Sie es selbst aus: Risiken proaktiv zu managen, ist praktikabel. Überlegen Sie, welche drei Dinge in Ihrer Arbeit am wichtigsten sind, wählen Sie eines aus und betreiben Sie Risikomanagement. Wenn etwas nicht stimmig wirkt, eröffnen Sie einen Fall oder dokumentieren Sie es. Sie werden feststellen, dass es in Zukunft nützlich sein kann.
