Als die Pandemie im Frühjahr 2020 die Schweiz erreichte, hatten die wenigsten Organisationen einen Pandemieplan. Es gab ihn dort, wo Aufsicht oder Konzernvorgaben ihn verlangten, etwa bei Banken und Versicherern oder in kritischen Infrastrukturen, die spätestens nach der Schweinegrippe von 2009 ihre BCM-Ordner ergänzt hatten. Diese Pläne waren keine Alibi-Dokumente, und sie beschrieben doch fast durchweg dieselbe falsche Lage: eine Influenza-Welle mit einigen Wochen hoher Personalausfälle und danach der Rückkehr zum Normalbetrieb. Die Pandemie, die dann kam, hielt sich nicht an das Szenario. Die Belegschaft war zum grössten Teil gesund, durfte aber nicht ins Gebäude. Der Ausweichstandort, die klassische Antwort des BCM auf den Verlust eines Gebäudes, hatte darauf keine Antwort: Das Problem war nicht der Standort, es war die Annahme, dass Arbeit Menschen in einem Gebäude versammelt. Und diese Annahme galt am Ausweichstandort genauso. Dazu kam, dass sich ein Ende, ab dem man zum Normalbetrieb hätte zurückkehren können, über Monate nicht einmal datieren liess.
Getragen hat die Organisationen in jenen Wochen, die mit Plan wie die ohne, etwas, das in keinem Ordner stand: die Fähigkeit, sich schnell umzubauen. Dieser Umbau sah je nach Branche völlig verschieden aus. Dienstleistungsbetriebe stellten innert Tagen auf Heimarbeit um. Produktionsbetriebe, für die das keine Option war, trennten Schichten und entwickelten Schutzkonzepte, um überhaupt weiterarbeiten zu dürfen. Die Gastronomie improvisierte Take-away und Lieferdienste, und wo selbst das nicht reichte, weil das Geschäftsmodell behördlich stillgelegt war, entschied die Anpassungsfähigkeit immerhin darüber, in welchem Zustand ein Betrieb die Zwangspause überstand. Zur Ehrlichkeit gehört dabei: In der Schweiz federte der Staat einen grossen Teil des Schadens ab, schnell, mit viel Geld und erstaunlich unbürokratisch, von der ausgeweiteten Kurzarbeit bis zu Covid-Krediten, die per halbseitigem Formular flossen. Das relativiert die Leistung der Betriebe weniger, als es scheint, denn auch das war Dehnfähigkeit, diesmal die einer Verwaltung, die ihre eigenen Verfahren weit über den Normalmodus hinaus streckte. Ob eine Organisation gut durch diesen Frühling kam, entschied sich jedenfalls kaum daran, ob ein Pandemieplan vorlag. Trotzdem nannte manche das hinterher stolz ihre Business Continuity. An dieser Stelle beginnt die Verwechslung, um die es hier geht.
Business Continuity Management und Resilience Engineering tauchen in Strategiepapieren und Ausschreibungen zunehmend als austauschbare Begriffe auf. Sie sind es jedoch nicht. Business Continuity beantwortet die Frage: Wie schnell sind wir wieder da, wenn eintritt, was wir uns vorstellen konnten? Resilience Engineering beschäftigt sich mit der anderen Frage: Was tun wir, wenn eintritt, was wir uns nicht vorstellen konnten? Die eine Disziplin plant die Rückkehr. Die andere baut die Fähigkeit, sich zu dehnen.
Was Business Continuity kann
Zuerst das Positive, denn diese Verwechslung ist kein Anlass, auf das BCM einzuschlagen. Business Continuity Management ist ein reifes Handwerk mit einer eigenen Norm, der ISO 22301. Eine Business Impact Analyse klärt, welche Prozesse wie lange stillstehen dürfen, bevor der Schaden untragbar wird. Daraus entstehen Wiederanlaufziele: die RTO legt fest, nach welcher Zeit ein Prozess wieder laufen muss, die RPO, wie viele Daten dabei höchstens verloren gehen dürfen. Dazu kommen Szenarien, Pläne und Übungen.
Der eigentliche Wert dieser Arbeit liegt darin, dass Entscheidungen vor der Krise fallen statt während ihr. Welcher Prozess zuerst wiederkommt und wer das entscheidet, will niemand um drei Uhr morgens zum ersten Mal durchdenken. Eine Organisation, die ohne diese Vorarbeit in einen Ausfall stolpert, verliert Stunden mit Fragen, die sich in einer ruhigen Sitzung hätten klären lassen. Auch der Pandemieplan von 2019 war in diesem Sinn kein Fehler. Für eine Influenza-Welle wäre er brauchbar gewesen.
Das Problem beginnt erst, wenn diese Arbeit als Beleg für etwas herhalten muss, das sie nicht ist.
Vier Bedeutungen eines Worts
David Woods, einer der Begründer des Resilience Engineering, hat 2015 in einem kurzen Aufsatz sortiert, was Menschen meinen, wenn sie «Resilienz» sagen. Er fand vier verschiedene Konzepte unter demselben Wort. Das erste ist Rebound: Ein System federt nach einer Störung zurück in seinen Ausgangszustand. Das zweite ist Robustheit: Ein System hält definierte Belastungen aus, ohne seine Funktion zu verlieren. Das dritte nennt er graceful extensibility, die Fähigkeit eines Systems, sich zu dehnen, wenn eine Überraschung an die Grenzen des Vorgesehenen stösst. Das vierte ist sustained adaptability, die Fähigkeit, diese Anpassungsfähigkeit über Zeit und über verändernde Bedingungen hinweg zu erhalten.
Mit dieser Sortierung wird die Verwechslung präzise benennbar. Business Continuity institutionalisiert die ersten beiden Bedeutungen: Sie definiert, welche Belastungen das System aushalten muss (Robustheit), und plant den Weg zurück in den bekannten Zustand (Rebound). Resilience Engineering meint die letzten beiden. Es fragt, was ein System tut, wenn die Störung das Szenario verlässt, und was eine Organisation braucht, damit diese Dehnfähigkeit nicht mit der nächsten Reorganisation verschwindet. Wer «resilient» sagt und ein BCM-Zertifikat zeigt, redet also nicht einfach ungenau. Er beantwortet eine andere Frage als die gestellte.
Die Pandemie war der Lehrfall für den Unterschied, gerade weil sie kein Ereignis im Sinne der Pläne war. Ein Rechenzentrumsbrand hat einen Zeitpunkt, einen Umfang und ein Ende; danach wird wiederhergestellt. Die Pandemie hatte nichts davon. Sie verschob die Randbedingungen über Monate und immer wieder neu, und einen bekannten Zustand, zu dem man hätte zurückkehren können, gab es nicht; ein Teil der Verschiebung, etwa die Heimarbeit, blieb gleich ganz. Die Rebound-Logik griff ins Leere, weil kein Punkt existierte, zu dem sich zurückfedern liess. Was trug, war die dritte Bedeutung von Woods‘ Liste: Organisationen, die sich dehnen konnten. Woods hat auch einen Namen für das Gegenteil: brittleness, die Sprödigkeit von Systemen, die an der Grenze ihres Entwurfsbereichs nicht nachgeben, sondern brechen.
Was Resilience Engineering stattdessen aufbaut
Wenn Resilienz nicht im Ordner liegt, wo dann? Erik Hollnagel hat die Antwort als vier Potenziale beschrieben, die eine Organisation entwickeln kann. Die Fähigkeit zu reagieren, auch auf das, wofür kein Plan existiert. Die Fähigkeit zu beobachten, also schwache Signale zu sehen, bevor sie zu Lagen werden; die Organisationen, die im Februar 2020 ihre Lieferketten und ihre Heimarbeits-Kapazität prüften, taten genau das. Die Fähigkeit zu lernen, und zwar auch aus dem, was gut ging: Wer nach der ersten Welle auswertete, warum die improvisierte Umstellung funktioniert hatte, konnte in der zweiten darauf bauen. Und die Fähigkeit zu antizipieren, was nicht Vorhersage bedeutet, sondern die Bereitschaft, mit Überraschung zu rechnen.
Keines dieser Potenziale lässt sich als Dokument ablegen. Sie stecken in Reserven, die eine straffe Kostenrechnung als Ineffizienz ausweisen würde, in Leuten, die ihre Prozesse gut genug kennen, um von ihnen abweichen zu können, und in einer Führung, die Improvisation nicht als Kontrollverlust behandelt. Das macht sie schwer vorzeigbar. Ein Zertifikat kann man rahmen, Anpassungsfähigkeit sieht man erst, wenn sie gebraucht wird.
Ein Zertifikat kann man rahmen. Anpassungsfähigkeit sieht man erst, wenn sie gebraucht wird.
Wo die Verwechslung schadet
Harmlos wäre das alles, wenn es nur um Wortwahl ginge. Es geht um mehr, und zwar an drei Stellen.
Die erste ist der Nachweis. Gegenüber Verwaltungsrat, Regulator oder Kundschaft wird das BCM-Zertifikat als Beleg für «Resilienz» eingereicht, und der Empfänger versteht darunter meist mehr als Rebound und Robustheit. Selbst die Norm lädt zu diesem Schluss ein: ISO 22301 trägt «Security and resilience» im Titel. Der Fehlschluss hat dieselbe Struktur wie einer, über den ich hier letzte Woche geschrieben habe («Was ein gutes Audit kann»): Ein bestandenes Audit belegt die Auditierbarkeit einer Organisation, nicht ihre Sicherheit. Ein BCM-Zertifikat belegt die Planbarkeit der geplanten Fälle, nicht die Anpassungsfähigkeit in den ungeplanten.
Die zweite Stelle ist das Budget. Wo Resilienz als erledigt gilt, weil das BCM steht, konkurriert die Anpassungs-Kapazität nicht einmal mehr um Mittel. Reserven und Leute, die mehr als eine Rolle beherrschen, erscheinen in keinem Ordner als Pflicht und verlieren deshalb gegen jede Effizienzrunde. Die Ironie daran: Je straffer eine Organisation auf ihre definierten Szenarien optimiert, desto spröder wird sie an deren Rändern. Man kann sich Robustheit erkaufen und mit derselben Rechnung Dehnfähigkeit abschaffen.
Die dritte Stelle sind die Übungen. Eine BCM-Übung, die jedes Jahr nach Drehbuch gelingt, prüft das Drehbuch, und auch das hat seinen Wert. Nur darf man das Ergebnis nicht als Aussage über Überraschungsfestigkeit lesen. Der Unterschied zeigt sich an einer einzigen Frage: Wann hat eine Übung die Organisation zuletzt an eine Stelle geführt, an der der Plan nicht weiterwusste? Wo diese Stellen systematisch vermieden werden, übt die Organisation das Bestehen der Übung.
Beides, aber als das, was es ist
Es braucht beides, und zwar unverwechselt. Business Continuity ist die Hygiene-Schicht, analog zur Compliance im Verhältnis zum tatsächlichen Sicherheitsgeschehen: notwendig, wertvoll, und systematisch unzuständig für die Überraschung. Resilience Engineering ist keine bessere Version davon, es ist die Arbeit an der anderen Frage. Eine Organisation, die beides auseinanderhält, kann ihren BCM-Ordner pflegen und gleichzeitig wissen, dass er über ihre Dehnfähigkeit nichts aussagt.
Der Pandemieplan von 2019 gehörte in den Ordner, und der Ordner hat seinen Platz. Aber was Organisationen im Frühjahr 2020 getragen hat, stand nicht im Ordner. Es sass in den Leuten, in den Reserven und in der Erlaubnis, vom Plan abzuweichen. Wer heute über die Resilienz seiner Organisation Auskunft geben will, sollte deshalb nicht zuerst zeigen, was er wiederherstellen kann. Er sollte zeigen, wo er sich zuletzt gedehnt hat.
Gedanken dazu? Schreib’s auf LinkedIn.
Kommentare gibt’s hier nicht – aber Diskussionen sehr gerne, dort wo eh alle sind.
Diskussion auf LinkedInQuellen
- David D. Woods – Four Concepts for Resilience and the Implications for the Future of Resilience Engineering, Reliability Engineering & System Safety 141, 2015 (Hauptquelle)
- Erik Hollnagel – Safety-II in Practice: Developing the Resilience Potentials, Routledge 2018
- ISO 22301:2019 – Security and resilience – Business continuity management systems – Requirements