Resilienz ist nicht, was die meisten darunter verstehen

Wenn in einem Strategiepapier «Resilience» steht, ist meistens etwas anderes gemeint als das, was die Sicherheitsforschung unter Resilienz versteht. Eine Bestandsaufnahme von Notfallplänen, ein Krisenstab mit Eskalationslogik, Buffer in Lager und Personal, dokumentierte Wiederherstellungszeiten nach einem Ausfall. Das alles existiert legitim und hat seinen Wert. Es ist Robustheit, oder Business Continuity, oder Krisenmanagement. Es ist nicht Resilienz im Sinn, in dem das Konzept entwickelt wurde.

Die Verwechslung ist nicht harmlos. Robustheit und Resilienz verhalten sich unter realer Komplexität unterschiedlich, teilweise gegenläufig. Wer das eine baut und das andere meint, kommt unter Stress in Schwierigkeiten, die im Programm nicht antizipiert wurden.

Was mit «Resilienz» meistens gemeint ist

Wer durch Resilience-Programme in Organisationen geht, findet eine wiederkehrende Inhaltsliste. Krisen-Playbooks, die definieren, wer im Ernstfall welche Rolle einnimmt. IT-Buffer, die Ausfallzeiten begrenzen. Lieferkettendiversifizierung gegen Single-Source-Risiken. Stress-Tests, die Belastbarkeitsreserven prüfen. Mitarbeiter:innen-Schulungen zur «resilienten Arbeitsweise», häufig mit Anteilen aus dem Wellness-Vokabular. Die Liste ist nicht falsch. Es handelt sich hierbei jedoch um Robustheit.

Robustheit ist die Fähigkeit eines Systems, definierte Störungen ohne Funktionsverlust zu absorbieren. Sie wird vorausplanbar gegen vorausgedachte Bedrohungsszenarien gebaut. Wer alle wahrscheinlichen Ausfallpfade kennt, kann das System gegen sie härten: durch Redundanz, durch Buffer, durch geprüfte Wiederanlaufverfahren. Das ist eine ernsthafte und nicht-triviale Disziplin, und sie ist die Voraussetzung jeder funktionierenden Krisenvorsorge.

Robustheit geht an ihre Grenze, sobald die Störung nicht in der Szenarioliste steht. Eine Lieferkettenunterbrechung, die in keiner Risikoliste stand, ein Cyberangriff in einer Form, mit der niemand gerechnet hatte, eine regulatorische Verschärfung über Nacht: die Robustheitslogik kann auf Unbekanntes nicht vorbereiten, weil sie auf Bekanntes optimiert ist. Genau hier setzt der Begriff Resilienz an, und genau hier wird er in der Regel weggesteuert.

Was Resilienz im strengen Sinn heisst

Der Begriff hat eine längere Geschichte als die organisationale Anwendung. Crawford Stanley Holling hat ihn 1973 für ökologische Systeme geprägt: die Fähigkeit eines Ökosystems, Störungen zu absorbieren, ohne in einen qualitativ anderen Zustand zu kippen. Die Ingenieurswissenschaften haben den Begriff in den 1990er-Jahren in einer engeren Form übernommen, näher an Robustheit als an Hollings ursprünglicher Bedeutung. Mit dem Sammelband Resilience Engineering: Concepts and Precepts von Hollnagel, Woods und Leveson 2006 entstand die heute in der Sicherheitsforschung dominante Definition, die Resilienz als Anpassungskapazität im Unerwarteten versteht und nicht als Wiederherstellung nach Bekanntem.

Resilienz, wie Erik Hollnagel den Begriff in dieser Linie verankert hat, ist nicht die Fähigkeit, bekannte Störungen zu absorbieren. Sie ist die Fähigkeit, mit Bedingungen zu funktionieren, die in der Planung nicht antizipiert wurden. Hollnagel macht das an vier Kapazitäten fest: antizipieren, was sich entwickeln kann; monitorieren, was gerade geschieht; reagieren, auf das Unerwartete; lernen, aus dem, was passiert ist. Eine robuste Organisation hat diese vier Kapazitäten ebenfalls, aber sie hat sie auf das Vorhersehbare hin trainiert: Risikoregister für bekannte Szenarien, Dashboards für definierte Indikatoren, Playbooks für vorgedachte Lagen, Lessons Learned aus eingetretenen Vorfällen. Eine resiliente Organisation trainiert dieselben vier Kapazitäten auf das Unerwartete: Antizipation auf Klassen möglicher Störungen statt nur benannter Szenarien, Monitoring auf schwache Signale ausserhalb der Indikatorenliste, Reagieren ohne Playbook, Lernen aus Beinahevorfällen statt erst aus dem Knall. Im Bereich des Vorhersehbaren funktionieren beide. Im Bereich des Unvorhergesehenen unterscheiden sich beide grundsätzlich, weil Resilienz die vier Kapazitäten dort einsetzbar hält, wo die Vorbereitung an ihre Grenze kommt.

David Woods hat dieselbe Eigenschaft mit dem Begriff graceful extensibility zugespitzt: die Frage, wie weit ein System gestreckt werden kann, bevor es bricht, und wie es sich verhält, während es gestreckt wird. Ein robustes System hat eine klare Belastungsgrenze und versagt scharf, sobald sie überschritten wird. Ein resilientes System hat einen ausfransenden Bereich vor der Grenze, in dem es Funktionalität verliert, aber nicht zusammenbricht. Akteure im System haben dort Spielraum für Anpassungen, die das System tragen.

Die Unterscheidung klingt spitzfindig, hat aber operative Konsequenzen. Robustheit ist gegen Listen optimiert: wer die Liste vollständig hat, hat das System abgesichert. Resilienz ist gegen Überraschungen optimiert. Wer Resilienz baut, akzeptiert, dass die Liste niemals vollständig ist, und investiert in Eigenschaften, die jenseits der Liste tragen.

Robustheit ist gegen Listen optimiert. Wer Resilienz baut, akzeptiert, dass die Liste niemals vollständig ist, und investiert in Eigenschaften, die jenseits der Liste tragen.

Voraussetzungen, die im Diskurs oft fehlen

Resilienz im strengen Sinn ist nicht ein einzelner Mechanismus. Sie ist die Eigenschaft eines Systems, die aus mehreren Voraussetzungen entsteht. Drei werden in den gängigen Programmkonzepten unterbelichtet.

Die erste ist Slack, also operativer Spielraum jenseits der reinen Auslastung. Eine Organisation, die ihre Personal- und Materialreserven auf das Notwendige optimiert, hat per Definition keine Kapazität, auf Unerwartetes zu reagieren. Slack ist nicht Verschwendung. Slack ist die Reserve, mit der ein System auf Bedingungen reagieren kann, die nicht in der Auslastungsplanung standen. In effizienzgesteuerten Organisationen ist Slack systematisch wegoptimiert.

Die zweite ist sichere Kommunikation entlang der Hierarchie. Resilienz verlangt, dass schwache Signale aus der Linie nach oben kommen, wenn sie zählen. Eine Organisation, in der das Sprechen über Probleme persönlich riskant ist, kann nicht resilient sein, egal welche Krisen-Playbooks sie hat. Amy Edmondsons Arbeit zu psychologischer Sicherheit liefert dafür die Forschungsgrundlage, die in Resilience-Programmen selten angeschlossen wird.

Die dritte ist Toleranz für Variation. Resiliente Systeme erlauben lokale Anpassungen ihrer Akteure, weil das Skript die Bedingungen vor Ort nie vollständig kennt. Eine Organisation, die jede Abweichung von der Vorgabe als Compliance-Verstoss behandelt, erzieht ihre Linie zum Verstecken der Anpassungsarbeit, von der ihre Sicherheit täglich abhängt. Wer Resilienz im strengen Sinn aufbauen will, akzeptiert, dass Variation kein Defekt ist, sondern die laufende Übersetzung der Vorgabe in die Realität.

Keine dieser drei Voraussetzungen lässt sich in einem Programm-Slide darstellen. Alle drei sind kostspielig, sie verlangen Verzicht auf Maximalauslastung, auf Sanktionsreflexe, auf strikte Verfahrenstreue. Sie sind nicht zertifizierbar. Sie sind die Bedingungen, unter denen Resilienz überhaupt entstehen kann.

Warum die Verwechslung passiert

Wenn die Distinktion klar ist und die Voraussetzungen beschreibbar sind, warum verschwimmt der Begriff dann so konsequent in der organisationalen Anwendung? Die ehrliche Antwort liegt im Anreizsystem, nicht im Konzept.

Resilienz im strengen Sinn ist schlecht messbar, schlecht reportbar und schlecht über Quartal hinaus planbar. Sie verlangt Investitionen, deren Auszahlung in Form von vermiedenen Krisen erfolgt, die nicht eingetreten sind. Eine vermiedene Krise lässt sich schwer als KPI ausweisen. Eine Geschäftsleitung, die in Resilienz investiert, finanziert eine Eigenschaft, die sie nicht messen und nicht zeigen kann.

Robustheit ist demgegenüber freundlicher. Krisen-Playbooks sind dokumentierbar, Stress-Tests bestehbar, Buffer quantifizierbar, Wiederherstellungszeiten benchmarkbar. Wer Robustheit baut, kann das im Quartalsreporting zeigen. Wer Resilienz baut, muss erklären, was nicht passiert ist, weil es nicht passiert ist.

Das Anreizgefälle erklärt, warum «Resilience» im organisationalen Diskurs zu dem geworden ist, was Reporting-fähig ist. Reporting-fähig ist überwiegend Robustheit. Es ist nicht Bosheit. Es ist Strukturlogik. Eine Geschäftsleitung optimiert das, was sie zeigen kann. Was sich nicht zeigen lässt, fällt aus dem Programm, auch wenn es seinen Namen behält.

Das wurde nach 2020 in einer Welle organisationaler «Resilience»-Programme sichtbar. Die Pandemie hatte in vielen Branchen Lieferkettenlücken offengelegt, die Programme richteten sich auf deren Schliessung: Multi-Sourcing, Sicherheitslager, lokale Produktionskapazitäten. All das ist sinnvoll, all das ist Robustheit. Was in den wenigsten dieser Programme entstand, war die Fähigkeit, die nächste unvorhergesehene Störung früher zu erkennen und schneller umzulernen, bevor sie zur Krise wird. Das ist die Resilienzfrage. Sie wurde nicht gestellt, weil sie sich nicht in Roadmap-Form bringen lässt.

Wie sich die Verwechslung erkennen lässt

Wenn ein «Resilience-Programm» auf dem Tisch liegt, sind die diagnostischen Fragen nicht schwer. Erstens: wo werden im Programm Reserven aufgebaut, und wo werden die bestehenden Effizienzprogramme entsprechend angepasst? Zweitens: wo werden Mechanismen zur sicheren Meldung schwacher Signale beschrieben, und wo werden Sanktionslogiken überarbeitet, die diese Meldungen heute teuer machen? Drittens: wo wird Toleranz für lokale Anpassung explizit gemacht, und wo werden Compliance-Erwartungen neu kalibriert, damit die Anpassung sichtbar bleiben darf?

Wenn alle Antworten leer bleiben, ist das Programm nicht Resilienz. Es ist Robustheit unter neuem Etikett. Was nicht heisst, dass es nichts wert wäre. Es heisst, dass die Organisation eine Lücke hat, von der sie nichts weiss, weil das Etikett sie unsichtbar macht.

Wovon der Begriff zu retten wäre

Wer den Begriff retten will, muss zwei Dinge tun. Das erste ist semantisch: Resilienz und Robustheit auseinanderhalten, auch wenn das in Strategiedokumenten anstrengender ist. Was Robustheit ist, soll Robustheit heissen. Was Business Continuity ist, soll Business Continuity heissen. Resilienz reserviert für das, was Hollnagel und Woods damit gemeint haben.

Das zweite ist organisational: Resilienz als Eigenschaft mit ihren Voraussetzungen ernst nehmen, also Slack im System, sichere Kommunikation, Toleranz für Variation. Und akzeptieren, dass diese Voraussetzungen nicht in dem Reporting-Format sichtbar werden, in dem die Organisation sonst Erfolg misst. Wer das nicht akzeptieren kann, sollte den Begriff fallen lassen, statt ihn weiter zu verwässern. Robustheit verdient eigene Anerkennung. Sie braucht das Resilienzetikett nicht.

Quellen

• Erik Hollnagel – Safety-II in Practice: Developing the Resilience Potentials, Routledge 2018
• Erik Hollnagel, David Woods & Nancy Leveson (Hrsg.) – Resilience Engineering: Concepts and Precepts, Ashgate 2006
• David D. Woods – «Four concepts for resilience and the implications for the future of resilience engineering», Reliability Engineering & System Safety 141 (2015)
• C. S. Holling – «Resilience and stability of ecological systems», Annual Review of Ecology and Systematics 4 (1973)
• Amy C. Edmondson – The Fearless Organization, Wiley 2018