Franco T.,
TLDR;
Die meisten Business Continuity Pläne scheitern im Ernstfall: nicht weil sie schlecht geschrieben sind, sondern weil sie das falsche Problem lösen. Traditionelle DR-Pläne fokussieren auf IT-Systeme: Backups, Failover, RTO. Aber wenn dein Cloud-Provider ausfällt oder Ransomware deine Produktion lahmlegt, bringt ein DR-Plan allein dein Geschäft nicht zurück. Die Lösung? Resilienz statt Recovery.
Niemand liest gerne 80-seitige BC-Pläne.
Und das ist genau das Problem.
Wir haben in den letzten Jahren dutzende Business Continuity Konzepte bei Schweizer Unternehmen geprüft. Das Muster ist immer dasselbe: beeindruckende Dokumentation, detaillierte Prozessdiagramme, ordentlich nummerierte Eskalationsketten.
Und dann kommt der Ernstfall.
Plötzlich stellt sich heraus: Die dokumentierte Kontaktperson hat das Unternehmen vor zwei Jahren verlassen. Die Recovery-Schritte beziehen sich auf Server, die längst in die Cloud migriert wurden. Die Eskalationskette passt nicht mehr zur aktuellen Org-Struktur.
Das ist kein Einzelfall. Das ist die Regel.
Das fundamentale Problem: BC als Dokument statt als Fähigkeit
Hier liegt der Denkfehler: Die meisten Unternehmen behandeln Business Continuity als Dokumentationsprojekt. Einmal erstellen, im SharePoint ablegen, fertig.
Das fühlt sich gut an. Man hat etwas "getan". Der Auditor ist zufrieden. Die Geschäftsleitung kann einen Haken setzen.
Aber operative Resilienz funktioniert so nicht. Ein Plan, den niemand kennt und der nie getestet wurde, ist kein Asset. Er ist eine Illusion.
Warum traditionelle DR-Pläne scheitern
Problem 1: IT-Fokus statt Business-Fokus
Klassische Disaster Recovery denkt in Systemen: "Wir haben Backups für Server X, Failover für Datenbank Y, RPO von 4 Stunden, RTO von 8 Stunden."
Das klingt technisch solide.
Aber wenn dein ERP-System ausfällt, interessiert deine Kunden nicht dein RTO. Sie wollen wissen: Kann ich bestellen? Wann kommt meine Lieferung? Bekomme ich Support?
Wir haben das bei einem Industrieunternehmen erlebt. Perfekter IT-DR-Plan. Aber als ihr Hauptlieferant für eine kritische Komponente durch einen Cyberangriff ausfiel, stand die Produktion. Der DR-Plan half nicht, weil das Problem nicht die eigene IT war, sondern fehlende Business-Prozess-Redundanz.
Problem 2: Die Multi-Cloud-Illusion
"Wir fahren Multi-Cloud, also sind wir abgesichert."
Das hören wir oft. Die Realität ist komplizierter.
Wenn mehrere grosse Cloud-Provider gleichzeitig Probleme haben, nützt dir deine Multi-Cloud-Strategie wenig. Besonders wenn deine Applikation nicht provider-agnostisch designed wurde. Die meisten sind es nicht.
Die grossen Cloud-Provider erleben zusammen dutzende Service-Ausfälle pro Jahr. Das ist die neue Normalität. Die Frage ist nicht "ob", sondern "wann" der nächste kommt.
Problem 3: Backups, die nicht funktionieren wenn es zählt
"Wir haben Backups" ist die häufigste Antwort, wenn wir nach Business Continuity fragen.
Aber hier liegt der Haken: Moderne Ransomware zielt gezielt auf Backup-Repositories. Angreifer wissen, dass Backups dein letzter Schutz sind. Wenn die Backups mit verschlüsselt werden, wird die Recovery schwierig.
Das kritischere Problem: Viele Unternehmen führen jahrelang täglich Backups durch. Aber niemand testet jemals einen echten Recovery.
Wenn dann der Ernstfall kommt, sind Backups nicht wiederherstellbar wegen veralteter Verschlüsselungskeys, geänderter Infrastrukturen oder inkompatibler Software-Versionen. Recovery dauert dann Wochen statt Stunden.
Problem 4: Pläne veralten schneller als du sie aktualisierst
Ein BC-Plan von vor drei Jahren ist heute meist Altpapier.
Deine IT-Landschaft ändert sich ständig: Neue SaaS-Tools, Cloud-Migrationen, Remote-Work-Infrastruktur, neue Lieferanten, organisatorische Umstrukturierungen.
Aber dein BC-Plan wird vielleicht einmal pro Jahr überflogen. Wenn überhaupt. Bis zum nächsten Audit ist er längst überholt.
In unserer Erfahrung identifizieren Unternehmen beim ersten systematischen Review nach zwei Jahren durchschnittlich acht bis zwölf kritische Abweichungen zwischen dem Plan und der gelebten Realität. Neue Schlüsselpersonen sind nicht erfasst. Kritische Drittanbieter fehlen. Recovery-Prozeduren beschreiben Systeme, die nicht mehr existieren.
Die versteckten Kosten, die niemand trackt
Ein Ausfall von 48 Stunden fühlt sich nach einem überschaubaren IT-Problem an. Die Rechnung kommt später.
Wenn wir mit CFOs sprechen, rechnen die meisten nur die direkten IT-Ausfallkosten. Das unterschätzt den echten Schaden massiv.
Was oft vergessen wird:
Opportunity Costs: Welche Geschäfte hast du nicht abschliessen können, weil deine Systeme 3 Tage lang nicht liefen? Welche Kunden haben bei der Konkurrenz gekauft?
Reputationsschaden: Wie viele Kunden wechseln dauerhaft zur Konkurrenz, nachdem du 2 Wochen lang nicht lieferfähig warst?
Regulatorische Konsequenzen: In der Schweiz sind ab Oktober 2025 Meldepflichten durchsetzbar. Nicht melden kostet bis zu CHF 100'000 pro Tag. Ähnliche Regelungen kommen EU-weit mit NIS2.
Recovery-Ressourcen: Wie viele Mannstunden fliessen in manuelle Workarounds, Krisenmanagement und Wiederherstellung? Was hätten diese Ressourcen sonst geschaffen?
Für ein typisches Schweizer SME mit CHF 20-100M Jahresumsatz: Ein grösserer Vorfall ohne Vorbereitung kostet schnell CHF 200K-2M, direkt und indirekt.
Der Paradigmenwechsel: Von Recovery zu Resilienz
Die Frage muss anders gestellt werden.
Statt:
"Wie lange dauert die Wiederherstellung unserer Server?"
"Was ist unser Recovery Time Objective?"
"Haben wir genug Backup-Kapazität?"
Frag lieber:
"Welche Geschäftsprozesse erzeugen unseren Umsatz und dürfen niemals ausfallen?"
"Können wir mit 70% Kapazität weiterarbeiten, während wir Probleme lösen?"
"Wo sind unsere echten Dependencies: Lieferanten, Zahlungsdienstleister, kritische Mitarbeiter?"
"Wer entscheidet in einer Krise, und ist diese Person erreichbar?"
Das ist der Unterschied zwischen Disaster Recovery und Resilience Engineering. Der erste Ansatz fragt: "Wann sind die Systeme wieder da?" Der zweite fragt: "Wie viel Schaden entsteht bis dahin, und wie minimieren wir ihn?"
Was du morgen anders machen kannst
Hier sind vier Fragen, die du diese Woche stellen solltest:
Welche 3 Geschäftsprozesse erzeugen 80% unseres Umsatzes? Starte dort. Nicht bei der IT-Infrastruktur.
Was passiert, wenn unser wichtigster Cloud-Dienst für 48 Stunden ausfällt? Nicht theoretisch. Konkret. Wer tut was? Können wir manuell weiterarbeiten?
Haben wir in den letzten 12 Monaten einen Recovery-Test durchgeführt? Nicht einen Backup-Test. Einen echten Business-Recovery-Test mit allen Beteiligten.
Wer entscheidet in einer Krise, und ist diese Person erreichbar? Auch am Wochenende? Im Urlaub? Um 3 Uhr morgens?
Die Antworten zeigen dir, wo du stehst. Wenn du bei einer der Fragen stockst, hast du deinen Startpunkt gefunden.
Erfahrungsgemäss ist Frage 3 die kritischste. Unternehmen, die in den letzten zwei Jahren keinen echten Recovery-Test gemacht haben, entdecken im Ernstfall meistens, dass ihre Backups nicht so zuverlässig sind wie angenommen. Oder dass die Zuständigkeiten unklar sind. Oder beides.
Die 70%-Regel
Hier ist der praktischste Takeaway aus diesem Artikel:
Perfekte Redundanz ist unbezahlbar. Aber 70% Kapazität innerhalb von 30 Minuten schützt mehr Umsatz als 100% Kapazität nach 48 Stunden.
Das nennen wir Minimum Viable Operations (MVO). Für jeden kritischen Geschäftsprozess definierst du: Was ist das absolute Minimum, um weiterzuarbeiten?
Ein Beispiel aus der Praxis: Ein E-Commerce-Unternehmen mit CHF 45M Jahresumsatz, das entspricht CHF 180K Tagesumsatz. Wenn der Hauptshop auf AWS ausfällt:
Option 1 (Aktivierung: 30 Min): Notfall-Landingpage auf Azure mit "Jetzt telefonisch bestellen" und Hotline-Aufstockung
Option 2 (Aktivierung: 2 Std): Basis-Shop auf Azure mit reduzierten Features
Resultat: Statt CHF 180K Tagesverlust nur CHF 15K während der Umschaltung. 92% des Umsatzes geschützt.
Die Investition in diese Fallback-Infrastruktur amortisierte sich beim ersten grösseren Ausfall. Das ist keine Theorie. Das ist eine Entscheidung, die du heute treffen kannst.
Fazit
BC-Pläne scheitern nicht an fehlenden Dokumenten, sondern am falschen Fokus
IT-fokussierte DR löst das falsche Problem, deine Kunden wollen Geschäftskontinuität, nicht Server-Recovery
Die Kosten von Unvorbereitung sind höher als die meisten CFOs rechnen
Der Paradigmenwechsel: Von "Wie stellen wir System X wieder her?" zu "Wie halten wir Geschäftsfunktion Y am Laufen?"
Die 70%-Regel: Schnelle Degraded Operations schlagen perfekte späte Recovery
Wie weiter?
Starte klein. Nimm diese Woche einen kritischen Geschäftsprozess und beantworte ehrlich:
Was passiert, wenn die technische Unterstützung für 24 Stunden ausfällt?
Haben wir einen Plan B?
Wer entscheidet, wann wir auf Plan B umschalten?
Wenn du bei diesen Fragen ins Stocken gerätst, weisst du, wo du anfangen musst. Und wenn du feststellst, dass ihr systematische Unterstützung braucht: dafür sind wir da.
