Business-Case-Entwicklung

Aus einem routinemäßigen Partner-Review wurde ein Business Case für Resilienz über 1,05 Mio. €

508 Tsd. € bis 1,05 Mio. €: modellierter erwarteter Jahresverlust, jetzt beziffert und schrittweise abgebaut
< 4 Std.: Wiederherstellungszeit laut Konzept, vorher gab es keine getestete Wiederherstellung
8 → 1: Systeme, die an einer ungeschützten Datenbank hängen

Eine Zwei-mal-zwei-Matrix aus Aufwand und Nutzen mit verstreuten Punkten in kalten Farben; der Quadrant mit wenig Aufwand und hohem Nutzen ist violett hinterlegt, und ein einzelner pink umrandeter Punkt darin trägt die Beschriftung „fund this“.

Fallakte

Branche: Vermittler von Fördermitteln für Energieeffizienz
Region: Deutschland
Leistung: Resilienz & Business Continuity
Team: Wayne ArendseLeiter Delivery & TransformationYurii KotulaCEO & Leiter Engineering
Systeme: Acht vernetzte Systeme
eine selbst gehostete WordPress-Datenbank als einzige verbindliche Datenquelle
regulatorischer Rahmen: DSGVO Art. 32 / NIS2

Über den Kunden

Ein deutscher Dienstleister, der staatliche Förderung für Energieeffizienz vermittelt. Immobilieneigentümer übergeben ihm ihre Anträge auf Zuschüsse und Kredite, und der Kunde führt sie in ihrem Auftrag durch das Verfahren. Es geht um Fördermittel mit harten behördlichen Fristen, strengen Vorgaben zur Dokumentation und null Toleranz für Fehler in der Verwaltung.

Der Technologie-Stack ist ausgereift und sauber gebaut. Das Team ist schlank, rund 24 Personen, und optimiert unermüdlich. Der Auftrag zu Beginn war bescheiden: die Systemlandschaft prüfen und Verbesserungen am Leistungsangebot empfehlen.

Das geschäftliche Problem

Unter der Oberfläche fand die Diagnose einen strukturellen Engpass. Dieses schlanke Unternehmen trug das Risikoprofil eines zwanzigmal größeren Betriebs. Der Grund war nicht, was es gebaut hatte, sondern wen seine Ausfälle treffen.

Ein technischer Ausfall bleibt hier nicht intern. Er kann einen Eigentümer seinen Zuschuss oder Kredit kosten, also Geld, das er womöglich schon einem Auftragnehmer zugesagt hat. Das ist Haftung gegenüber Dritten, keine bloße Unannehmlichkeit. Allein deshalb ist Disaster Recovery nicht mehr freiwillig, sondern Pflicht, und zwar längst überfällig.

Was auf dem Spiel stand

508 Tsd. € bis 1,05 Mio. € modellierter erwarteter Jahresverlust durch die Lücke bei DR/BCP, nach Wahrscheinlichkeit gewichtet über drei Ausfallszenarien.
Eine zentrale Datenbank als einzige verbindliche Datenquelle für acht Systeme, ohne erkennbares Failover.
Drei regulatorische Rahmen greifen gleichzeitig: Artikel 32 DSGVO, die NIS2-Richtlinie und eine stillschweigende Treuepflicht gegenüber den Endkunden, deren Förderung von der Plattform abhängt.

Was nicht funktionierte

Eine zentrale Datenbank als SPOF für acht vernetzte Systeme, ohne erkennbare Redundanz
Der Papierkorb im CRM mit 90 Tagen Aufbewahrung ist kein Backup; Daten, die ein KI-Agent beschädigt, lassen sich mit Bordmitteln nicht wiederherstellen
Im Korrektur-Flow von Power Automate konnten Dokumente unbemerkt verloren gehen
Ein bestimmter Entwickler verantwortete die meisten offenen Punkte zur Wiederherstellung, über alle kritischen Systeme hinweg
Keine getestete Wiederherstellung für das zentrale System; sie hätte vermutlich Tage gedauert

Vorgehen bei der Diagnose

Wir haben jedes System und sein konkretes Risiko bei der Wiederherstellung erfasst und es dann beziffert, gestützt auf dokumentierte Muster aus echten Vorfällen statt auf Vermutungen.

Strategie
Wie viel Geld steht auf dem Spiel?
Der Engpass wurde beziffert, nicht nur benannt. Zuverlässigkeit war unbemerkt zum eigentlichen Produkt geworden.
- 508 Tsd. € bis 1,05 Mio. € modellierter erwarteter Jahresverlust
- Zuverlässigkeit als Wettbewerbsvorteil, nicht als Compliance-Kosten
- Der klarste ROI liegt in vermiedenen Verlusten, nicht in gesparter Zeit
Abläufe
Wo steckt das Risiko wirklich?
Acht Systeme erfasst; für eine Wiederherstellung müssen alle wieder laufen, in der richtigen Reihenfolge.
- Eine zentrale Datenbank als Single Point of Failure für die gesamte Systemlandschaft
- Stellen in der Dokumenten-Pipeline, an denen Daten unbemerkt verloren gehen
- Die Wiederherstellung aller kritischen Systeme hängt an einer Person
Technologie
Wie wird das System robust, ohne den Betrieb zu stören?
Die Architektur war gut durchdacht. Die Lücken lagen in der Wiederherstellung, nicht im laufenden Betrieb. Deshalb musste nichts herausgerissen werden, was funktionierte.
- Ergänzungen auf der Ebene der Wiederherstellung, kein Austausch auf der Ebene des laufenden Betriebs
- Unabhängige Backups außerhalb jedes Anbieter-Tenants
- Getestete statt nur angenommene Wiederherstellung

Was sich geändert hat

Erst wurde das Risiko beziffert, dann eine Lösung vorgeschlagen
Ein versicherungsmathematisches Modell für den erwarteten Verlust (Wahrscheinlichkeit × Kosten über drei Ausfallszenarien) brachte 508 Tsd. € bis 1,05 Mio. € schwarz auf weiß. Die Geschäftsführung konnte jetzt auf Basis von Zahlen entscheiden, nicht aus Angst.
Sechs praktische Maßnahmen, die nichts Funktionierendes ersetzen
Nächtliches verschlüsseltes Backup auf einen unabhängigen VPS in Deutschland, CRM-Backup über einen Drittanbieter auf unabhängigen Speicher, Dead-Letter-Monitoring für jeden Flow in Power Automate, M365-Backup außerhalb des Tenants, Zapier-Konfigurationen mit Versionskontrolle in Gitea und ein Developer Runbook, dem jeder fähige Entwickler folgen kann.
Ein Runbook ersetzt die Abhängigkeit von einer Schlüsselperson
Schritt-für-Schritt-Anleitung zur Wiederherstellung aller fünf kritischen Systeme, Pair Programming bei kritischen Flows. Die Wiederherstellung hängt nicht mehr davon ab, ob eine bestimmte Person freitags um 2 Uhr nachts erreichbar ist.

Entscheidungen

Das Risiko beziffern, nicht nur behaupten
Ein versicherungsmathematisches Modell für den erwarteten Verlust, kalibriert auf die tatsächliche Architektur. Zahlen statt Angst.
Ergänzen statt ersetzen
Die Ebene der Wiederherstellung reparieren, den funktionierenden Betrieb unangetastet lassen. Der regulatorische Workflow bleibt, das Risiko nicht.
Unabhängigkeit statt Vertrauen in Anbieter
Backups außerhalb jedes Anbieter-Tenants. Ein Papierkorb ist eine Rückgängig-Funktion, keine Wiederherstellung.
Runbook statt Heldentum
Die Wiederherstellung hängt an einem Dokument, dem jeder fähige Entwickler folgen kann, und nicht daran, ob eine bestimmte Person erreichbar ist.

Ergebnisse

Kennzahl	Vorher	Nachher
Wiederherstellungszeit des zentralen Systems	Keine getestete Wiederherstellung; vermutlich Tage	< 4 Std. (laut Konzept)
Jährliches Risiko	508 Tsd. € bis 1,05 Mio. €, weder beziffert noch abgesichert	Beziffert, in Phasen geplant, Abbau läuft
Wiederherstellung von CRM- und SaaS-Daten	Über den Papierkorb hinaus nicht möglich	Jeder Zeitpunkt der letzten 30 Tage
Abhängigkeit von einer Schlüsselperson bei der Wiederherstellung	Ein bestimmter Entwickler nötig	Jeder Entwickler kann jedes System wiederherstellen
Kontinuität nach DSGVO Art. 32 / NIS2	Für die 8 Systeme nicht nachweisbar	Für alle 8 nachweisbar (laut Konzept)

Strike Team

Erfahrene Engineering-Leads finden in einer Engineering Diagnostic zum Festpreis den eigentlichen Engpass und bleiben, bis er behoben ist. Project Rescue, Fractional CTO, Architektur und Business Cases.

Mehr zum Strike Team