Seien wir ehrlich... 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.

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 null – 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 – und das ist bereits mehrfach vorkommen – nützt dir deine Multi-Cloud-Strategie wenig. Besonders wenn deine Applikation nicht wirklich provider-agnostisch designed wurde.

(Spoiler: 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? Backups sind nicht wiederherstellbar wegen veralteter Verschlüsselungskeys. Oder 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.

Die versteckten Kosten, die niemand trackt

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? Welche Deals sind geplatzt?

• Regulatorische Konsequenzen: In der Schweiz sind ab Oktober 2025 Meldepflichten durchsetzbar – nicht melden kostet dich 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.

Was du morgen anders machen kannst

Hier sind vier Fragen, die du diese Woche stellen solltest:

1. Welche 3 Geschäftsprozesse erzeugen 80% unseres Umsatzes? Starte dort. Nicht bei der IT-Infrastruktur.

2. Was passiert, wenn unser wichtigster Cloud-Dienst für 48 Stunden ausfällt? Nicht theoretisch. Konkret. Wer tut was? Können wir manuell weiterarbeiten?

3. Haben wir in den letzten 12 Monaten einen Recovery-Test durchgeführt? Nicht einen Backup-Test. Einen echten Business-Recovery-Test mit allen Beteiligten.

4. 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.

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 (~CHF 180K Tagesumsatz). Wenn der Hauptshop auf AWS ausfällt:

• Option 1 (Aktivierung: 30 Min): Notfall-Landingpage auf Azure mit "Jetzt telefonisch bestellen" + 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.

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 "Good Enough" 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, bist du nicht allein. Aber du weisst jetzt, wo du anfangen musst.

(Und wenn du merkst, dass ihr Unterstützung braucht, um das systematisch anzugehen – dafür machen wir das hier.)

Weiterlesen

• Warum die meisten Risikoanalysen scheitern – Ein pragmatischer Ansatz

• NIS2-Richtlinie für Schweizer Unternehmen – Der ultimative Umsetzungsleitfaden

• Ist es günstiger, nach einer Ransomware-Attacke zu recovern? – Die echten Kosten von Unvorbereitung