Stell dir vor: Dein wichtigstes IT-System fällt aus. Der Cloud-Provider hat Probleme. Oder Ransomware. Oder irgendwas Unerwartetes.
Die klassische Frage lautet: "Wie schnell können wir wiederherstellen?"
Die bessere Frage lautet: "Wie können wir weiterarbeiten, während wir wiederherstellen?"
Das ist der Unterschied zwischen Disaster Recovery und Minimum Viable Operations.
Das Problem mit perfekter Redundanz
Jeder möchte 100% Verfügbarkeit. Klar.
Aber reden wir mal über Kosten.
Um ein System wirklich zu 100% redundant zu machen, brauchst du:
- Doppelte Infrastruktur (zweites Rechenzentrum, zweiter Cloud-Provider)
- Aktive Datenreplikation in Echtzeit
- Automatisierte Failover-Mechanismen
- Regelmässige Tests der Failover-Szenarien
- Personal, das beide Umgebungen kennt
Für ein mittelständisches Unternehmen mit CHF 50M Umsatz? Das kostet schnell CHF 200K-500K pro Jahr. Pro kritischem System.
Und hier ist die unbequeme Wahrheit: Die meisten Unternehmen haben nicht ein kritisches System, sondern fünf oder zehn. Perfekte Redundanz für alles ist schlicht unbezahlbar.
Die 70%-Regel
Hier kommt der pragmatische Ansatz:
70% Kapazität innerhalb von 30 Minuten schützt mehr Umsatz als 100% Kapazität nach 48 Stunden.
Lass das kurz sacken.
Wenn du bei einem Ausfall 48 Stunden brauchst, um wieder zu 100% zu kommen, hast du 48 Stunden lang null Umsatz gemacht. Bei einem E-Commerce-Unternehmen mit CHF 180K Tagesumsatz sind das CHF 360K Verlust.
Wenn du stattdessen innerhalb von 30 Minuten auf 70% Kapazität umschalten kannst, verlierst du vielleicht CHF 15K während der Umschaltung und arbeitest dann mit reduzierter Kapazität weiter.
Das ist MVO: Nicht perfekt, aber funktionierend.
Was ist Minimum Viable Operations?
MVO ist die Antwort auf die Frage: "Mit welcher reduzierten Kapazität können wir weiterarbeiten, während wir das eigentliche Problem lösen?"
Es geht nicht darum, alles perfekt am Laufen zu halten. Es geht darum, das Minimum zu definieren, das den Geschäftsbetrieb aufrecht erhält.
Für jeden kritischen Prozess definierst du:
Das Schöne daran: MVO zwingt dich, zwischen Nice-to-Have und Must-Have zu unterscheiden. Diese Klarheit ist auch im Normalbetrieb wertvoll.
Wie du MVO definierst: 4 Schritte
Schritt 1: Identifiziere kritische Prozesse
Starte nicht bei der IT. Starte beim Geschäft.
Frag dich:
- Welche Prozesse erzeugen direkt Umsatz?
- Welche Prozesse haben regulatorische Konsequenzen bei Ausfall?
- Welche Prozesse betreffen Kunden direkt?
Typische Kandidaten:
- Bestellannahme und -verarbeitung
- Produktion (bei Fertigungsunternehmen)
- Zahlungsverkehr
- Kundenservice (für kritische Anfragen)
- Lieferketten-Koordination
Wenn du bereits eine Business Impact Analyse gemacht hast, nutze diese als Grundlage.
Schritt 2: Definiere das Minimum
Für jeden kritischen Prozess: Was ist das absolute Minimum, um weiterzuarbeiten?
Konkrete Fragen:
- Minimum-Kapazität: Mit wie viel Prozent der normalen Kapazität können wir operieren, ohne existenzielle Schäden zu erleiden?
- Nice-to-Have vs. Must-Have: Welche Features sind Komfort, welche sind existenziell?
- Manuelle Workarounds: Wenn System X ausfällt – können wir manuell weiterarbeiten? Mit welchen Tools? Wie lange ist das tragbar?
- Priorität bei Ressourcenknappheit: Wenn wir nur 50% Personal haben – wer arbeitet an was?
Ein Beispiel aus der Praxis:
Produktion bei einem Industrieunternehmen:
- Normal: 1000 Einheiten/Tag mit vollautomatisierter Fertigung
- MVO: 700 Einheiten/Tag mit reduzierter Qualitätsprüfung (nur Stufe 1+2, nicht Stufe 3) und manueller Verpackung
- Was wegfällt: Stufe-3-Qualitätsprüfung, automatisierte Verpackung
- Was bleibt: Kernproduktion, Basis-Qualitätskontrolle
- Akzeptable Dauer: 5 Tage
Schritt 3: Entwickle Fallback-Optionen
Jetzt wird es konkret: Was ist Plan B, wenn die primäre Methode ausfällt?
Fallback-Optionen Template:
Fragen für jede Fallback-Option:
- Alternative Technologie: Wenn System A ausfällt, welche andere Plattform können wir nutzen?
- Alternative Lieferanten: Wenn Lieferant X nicht liefert, gibt es Lieferant Y?
- Manuelle Prozesse: Können wir temporär manuell arbeiten?
- Reduced-Feature-Mode: Können wir mit 70% Funktionalität weitermachen?
- Aktivierungszeit: Wie schnell können wir umschalten? Wer entscheidet?
Schritt 4: Teste regelmässig
Ein MVO-Plan, der nie getestet wird, ist nur eine Hoffnung.
Test-Szenarien definieren:
Wichtig bei Tests:
- Tests sollten angekündigt sein (keine Überraschung), aber mit realem Zeitdruck
- Dokumentiere: Was hat funktioniert? Was nicht?
- Nach jedem Test: Plan aktualisieren, Fallback-Optionen verbessern
- Teste auch: Wer trifft Entscheidungen? Wer kommuniziert?
Einen vertieften Blick bietet unser Artikel Business Impact Analyse: Kritische Geschäftsprozesse identifizieren.
Praxis-Beispiel: MVO in Aktion
Ein E-Commerce-Unternehmen mit CHF 45M Jahresumsatz (~CHF 180K Tagesumsatz). Der Hauptshop läuft auf AWS.
Die Ausgangslage:
- Shop auf AWS EU-Central-1
- Keine Fallback-Optionen definiert
- Bei AWS-Ausfall: Totalausfall
Nach MVO-Definition:
Fallback-Strategie:
- Option 1 (Aktivierung: 30 Min): Notfall-Landingpage auf Azure mit "Jetzt telefonisch bestellen" + Hotline-Aufstockung. Ermöglicht reduzierte Bestellabwicklung.
- Option 2 (Aktivierung: 2 Std): Basis-Shop auf Azure mit reduzierten Features (nur Hauptprodukte, kein Customization). Ermöglicht ~70% normale Kapazität.
Kosten der Vorbereitung:
- Notfall-Landing-Page + Azure-Setup: CHF 15K einmalig
- Jährliche Wartung: CHF 5K
- Hotline-Aufstockungsvereinbarung: CHF 3K/Jahr
Resultat beim ersten Ausfall:
- AWS-Ausfall dauerte 6 Stunden
- Nach 30 Min: Hotline aktiv, Notfall-Seite online
- Nach 2 Std: Basis-Shop auf Azure
- Umsatzverlust: CHF 15K (statt geschätzte CHF 45K bei Totalausfall)
ROI: Die Investition von CHF 23K amortisierte sich beim ersten Vorfall dreifach.
Die mentale Umstellung
MVO erfordert ein Umdenken bei vielen Führungskräften.
Alte Denkweise: "Bei einem Ausfall müssen wir so schnell wie möglich wieder zu 100% kommen."
Neue Denkweise: "Bei einem Ausfall müssen wir so schnell wie möglich funktionierend weitermachen – auch wenn es nicht perfekt ist."
Das fühlt sich anfangs unbequem an. Niemand möchte Kunden sagen "Unser Shop ist gerade eingeschränkt verfügbar". Aber es ist besser als "Unser Shop ist überhaupt nicht verfügbar".
Häufige Einwände (und warum sie nicht stimmen)
"Unsere Kunden erwarten 100% Verfügbarkeit."
Tun sie das? Oder erwarten sie, dass du bei Problemen transparent kommunizierst und trotzdem eine Lösung anbietest? Die Erfahrung zeigt: Kunden sind erstaunlich tolerant gegenüber temporären Einschränkungen – wenn du proaktiv kommunizierst und eine Alternative anbietest.
"Manuelle Workarounds sind zu fehleranfällig."
Ja, sie sind fehleranfälliger als automatisierte Systeme. Aber ein fehleranfälliger Prozess, der läuft, ist besser als ein perfekter Prozess, der nicht läuft. Du planst MVO ja nicht für den Dauerbetrieb – sondern für die Überbrückung.
"Das ist zu aufwendig zu dokumentieren."
Ein 5-seitiger MVO-Plan, der quartalsweise getestet wird, schlägt jeden 50-seitigen Plan, der nie getestet wird. Halte es einfach. Eine Tabelle pro kritischem Prozess reicht.
Die kurze Version
- MVO beantwortet: Mit welcher Mindest-Kapazität können wir weiterarbeiten?
- Die 70%-Regel: 70% sofort schützt mehr Umsatz als 100% nach 48 Stunden
- Nice-to-Have vs. Must-Have: MVO zwingt zur Klarheit
- Fallback-Optionen: Für jeden kritischen Prozess Plan B (und C) definieren
- Testen, testen, testen: Ein MVO-Plan ohne Test ist nur Hoffnung
Was jetzt?
Nimm dir einen kritischen Geschäftsprozess. Nur einen.
Beantworte diese Fragen:
- Was ist die Normal-Kapazität?
- Was ist das absolute Minimum (MVO)?
- Was kann wegfallen?
- Was muss bleiben?
- Wie lange ist MVO akzeptabel?
Wenn du das für einen Prozess durchgedacht hast, hast du das Prinzip verstanden. Dann machst du das für die restlichen kritischen Prozesse.
(Und wenn du merkst, dass ihr Unterstützung braucht, um das systematisch für alle kritischen Prozesse durchzuarbeiten – dafür sind wir da.)
Weiterlesen
- Warum deine Business Continuity Pläne im Ernstfall versagen – Das Problem mit traditioneller DR
- Die 5 Dimensionen operativer Resilienz – Das vollständige Framework
- Business Impact Analyse: Kritische Geschäftsprozesse identifizieren – Der erste Schritt
