Immer wieder wird bei Organisationen das Thema "Notfall" diskutiert, also der "Plan B", der zum Tragen kommen und den Betrieb sichern soll, falls "Plan A", also der reguläre Betrieb, steht. Aber wer macht schon eine Notfallübung und simuliert den Ernstfall?
Bei Pannen, die aufgrund der Auswirkungen und Größe in der ganzen Republik bekannt werden - siehe der Ausfall der Lufthansa-Systeme am Flughafen Frankfurt wegen eines Kabelschadens - wird das Thema in der Öffentlichkeit schnell und umfassend aufgenommen. Schadenfreude, Kopfschütteln und Kritik an der Kompetenz der Verantwortlichen wird in aller Deutlichkeit geäußert. Es wird die Frage aufgeworfen, wie dies passieren konnte und warum für solche - durchaus nicht völlig unwahrscheinlichen - Fälle keine Vorsorge getroffen wurde.
Nach bisherigem Kenntnisstand scheint es diesen Vorfall gegeben zu haben, der zum Ausfall führte:
Ein Glasfaserkabel für die Verbindung vom LH-Rechenzentrum an den Flughafen, das an der Bahntrasse entlang verlegt war, wurde von einer Bohrung durchtrennt, obwohl es zur Sicherheit 5 Meter tief (!) verlegt war. Offensichtlich gab es keine Informationen für den Bautrupp, dass dort ein Kabel liegt.
Ist das in Zeiten der präzisen Kartierung von Wasserleitungen, Rohren und diversen Kabeln mit Geoinformationssystemen eine erstaunliche Tatsache, oder einfach menschliches Versagen?
Wenn die ersten Informationen richtig sind, gab es für diesen Notfall des Ausfalls des Kabels sogar eine Umleitung, aber auch diese fiel hier aus. Murphys Law lässt grüßen! Details sind noch offen, die Untersuchungen für den Vorfall laufen noch. Man darf auf das Ergebnis gespannt sein, die Wahrheit ist vermutlich bitter oder der Grund trivial.
Vermutlich wäre die mangelnde Redundanz aufgefallen, wenn wirklich einmal der Fall geübt worden wäre. Aber fand diese denn einmal statt? Oder gab es nur eine Planung, die in einer "Schreibtischübung" von der Logik, Rollen, Prozessen und dem vermuteten Ablauf her bewertet wurde, aber es wurde nie wirklich real der "Stecker gezogen", um die Belastbarkeit der Pläne und Systeme zu testen?
Was sind mögliche Gründe für einen solchen Vorfall, was finden wir in der Praxis vor?
Das Thema ist vielschichtig. Wie schon im Jahr-2000-Umstellungsprozess deutlich wurde, liegt oft zu wenig Information dazu vor, was in der komplexen und gewachsenen Architektur und der Software wirklich vorhanden ist und was die konkreten Abhängigkeiten sind. Die Dokumentation ist vernachlässigt, das Wissen zu der Technik und den Systemen ging mit den Experten in Rente und man ließ Systeme laufen aus Angst, die Effekte der Abschaltung nicht zu beherrschen. Das ist heute nicht anders. Aus Angst und Unsicherheit zu den Folgewirkungen und Abhängigkeiten werden Übungen selten bis nie "live" durchgeführt.
Und ist ein richtig guter "Plan B" zu erwarten, wenn "Plan A" schon nicht hinreichend dokumentiert ist?
Personelle und inhaltliche Fragen zur Steuerung durch das Management stellen sich, an welchen Themen werden die besten Experten angesetzt?
Auch menschliche Motive sind zu beobachten! Wer will sich schon mit alten Leitungen und Dokumentation des Status quo befassen, wenn er mit neuer Technologie arbeiten kann? Neuland zu entdecken oder gar zu entwickeln, ist eben sexy, das Bestehende zu sichern, gut zu dokumentieren und die Stabilität zu ermöglichen, hat weniger Charme. Das fängt schon bei der Softwareentwicklung an, wo Eigenschaften der Sicherheit und Resilienz weniger Priorität bekommen im Vergleich zur Funktionalität, die im nächsten Scrum-Standup dann mit Applaus bedacht wird.
Den Standard ISO 25010 heranzuziehen und zu leben, ist einem in der Praxis selten begegnet, stellt er doch die internationale Norm für Qualitätskriterien von Software, IT-Systemen und Software-Engineering dar. Ihn zu befolgen, könnte sich ja auszahlen, aber ist das heute Gegenstand in der Ausbildung? Stichwort Ausbildung: Kennen die heutigen Fachinformatiker und Hochschulabgänger die ISO 25010, kennen sie die auch bestehenden, ggf. alten Systeme? Die IT-Welt ist sehr dynamisch.
Die Außenwirkung und das Ansehen der relevanten Mitarbeiter ist oft ungerecht verteilt, es ist in den neuen Themen meist größer und bringt Interesse und Anerkennung. Ganz anders sieht es bei den Kollegen aus, die sich mit den Dingen beschäftigen, die schon immer da sind und geräuschlos optimiert und abgesichert werden. Diese Mitarbeiter bleiben meist im Hintergrund.
Kosten- und Zeitgründe in der IT führen in der Regel dazu, nur den Betrieb sicherzustellen, die Kostenplanung geht - völlig zu Unrecht - oft davon aus, dass Betriebskosten für die Infrastruktur degressiven Charakter über die Laufzeit haben, größere Summen und Kapazitäten werden meist nur für neue Systeme bewilligt. Laut einer Capgemini-Studie aus 2021 sind die Kennzahlen für die IT-Kosten seit Jahren für viele Unternehmen stabil oder es wurde gespart, nur knapp die Hälfte hat ihre Ausgaben erhöht. Will man damit dem Digitalisierungstrend gewachsen bleiben?
Und Architektur- und Dokumentationssünden der Vergangenheit - die keiner offen zugeben will - können unter Kostendruck nicht geheilt werden.
Zudem geht die Produktion vor, die Kosten eines Tages "Ausfall" lassen sich sehr genau berechnen. Bei einem vereinfachten Beispiel würde ein Tag Ausfall gut 400.000 Euro kosten, wenn angenommen wird, dass an 240 Tagen im Jahr produziert wird bei 100 Mio. Umsatz! Mögliche Folgewirkungen wie Werkzeugschäden bei Stillstand sind hier noch gar nicht beachtet.
Und noch dazu sind Just-in-Time-Lieferungen an das Produktionsband ebenso gefährdet. Diese müssten dann für einen geplanten Stillstand vorproduziert werden, was natürlich organisiert werden kann. Aber trotz guter Planung muss das ggf. in den Abend- oder Nachstunden erfolgen mit erhöhten Personalkosten und Planungsaufwand. Aber bei optimierten Prozessen ohne Produktions- und Lagerpuffer kann dies wieder zu Lagerproblemen führen, da keine Ware abfließt. Der Werkleiter muss das bei seiner Entscheidung zu einem Notfalltag zur Übung beachten, aber der "Ernstfall" nimmt darauf keine Rücksicht.
Erst hinterher zeigt sich, wie wichtig es gewesen wäre, gut vorbereitet zu sein! Vorher haben es die Verantwortlichen oft schwer, Zeit und Budgets bewilligt zu bekommen. Wenn es dann "kracht", wird gern auf höhere Gewalt verwiesen, ein natürliches Betriebsrisiko, was man eben nicht völlig umgehen könne. Und dann geht es weiter wie zuvor!
Menschlich ist es zudem, nach einem Vorfall anzunehmen, dass man jetzt ja wieder "erst mal seine Ruhe habe, das passiert ja nicht jeden Tag", also ein ganz normales Risiko. Eine trügerische Annahme, die von der Versicherung sicher nicht geteilt wird und in der aktuellen Welt der vielfältigen Cyberattacken falsch ist, viele Unternehmen berichten von mehrfachen Attacken im Jahr! Lt. einer Studie aus der Schweiz wurde ein Unternehmen 10-mal angegriffen.
Was lernen wir daraus und was kann verbessert werden?
Zunächst gilt es einen kulturellen Wandel zu fördern, die Abhängigkeit von den IT-Systemen und der Infrastruktur ist immens, ein Unternehmen lässt sich heute nicht mehr mit Papier und Bleistift steuern. Der Ausfall einer ERP- oder MES-Lösung ließe im Nu alle Bänder stillstehen und sofort zu LKW-Staus bei der Anlieferung und Versand führen.
Die Betriebssicherheit sowie das Bewusstsein für Risiken und deren Bewältigung sind zu erhöhen. Mit Hilfe der Einführung eines ISMS (Informationssicherheits-managementsystem) nach ISO 27001 oder gem. TISAX® kann die Informationssicherheit gefördert werden, auch die Cybersicherheit ist zu fördern. Mittels strukturierter Business-Impact-Analysen und Business Continuity Standards gem. ISO 22301 oder BSI-Standard 200-4 können Risikobewusstsein und Risikomanagement unterstützt werden.
Personelle und technische Ressourcen sind auch auf den Risikofall hin zu planen, bislang übliche Budgetannahmen sollten hinterfragt werden.
Und das Management sollte realistischere Erwartungen aufbauen, was die Kosten und Risiken betrifft, einen Notfalltag zu machen oder dies zu unterlassen. Ein Notfall nimmt darauf ja auch keine Rücksicht!
Bei der Feuerwehr sieht es jeder als Selbstverständlichkeit an, dass bei Feuer richtig und schnell zu handeln ist, um das Schlimmste zu verhindern. Daher finden laufend Übungen statt, um das Verhalten zu schulen, die Technik zu prüfen, die Wirksamkeit der Prozesse sicherzustellen und reaktionsschnell zu bleiben.
Aber bei der internen IT und der Infrastruktur soll es dann im Notfall mit "Plan B" klappen, ohne den Fall auch nur einmal geübt zu haben?
Link zum Artikel in der Süddeutschen Zeitung: http://sz.de/1.5752725