Business Impact Analyse: Kritische Geschäftsprozesse identifizieren

Die wenigsten Unternehmen können spontan sagen, welche drei Geschäftsprozesse 80% ihres Umsatzes erzeugen. Noch weniger haben diese Prozesse in den letzten 12 Monaten getestet. Eine Business Impact Analysis (BIA) schafft genau diese Klarheit – und sie muss weder kompliziert noch teuer sein. Hier erfährst du, wie du anfängst.

Die Frage, die fast niemand beantworten kann

Stell dir vor, dein ERP-System fällt morgen früh um 8 Uhr aus. Komplett. Keine Bestellungen, keine Lagerverwaltung, keine Rechnungsstellung.

Wie lange kannst du so weiterarbeiten, bevor echte Schäden entstehen?

...

Wenn du jetzt zögern musstest, bist du in guter Gesellschaft. Wir stellen diese Frage regelmässig in Workshops. Die Antworten reichen von "ein paar Stunden" bis "keine Ahnung, das IT hat das irgendwo dokumentiert". Beides ist problematisch.

Das "keine Ahnung" ist offensichtlich. Aber auch "ein paar Stunden" hilft nicht, wenn sich herausstellt, dass du in Wirklichkeit nur 30 Minuten hast, bevor Kundenbestellungen verloren gehen.

Was ist eine Business Impact Analysis?

Eine Business Impact Analysis (BIA) ist im Kern eine systematische Bestandsaufnahme. Sie beantwortet drei Fragen:

  1. Welche Geschäftsprozesse sind wirklich kritisch? (Nicht alle – nur die, bei denen ein Ausfall existenzbedrohend wäre)

  2. Wie lange kann jeder Prozess maximal ausfallen? (In Stunden, nicht in vagen Begriffen wie "kurz")

  3. Welche Abhängigkeiten bestehen? (Systeme, Lieferanten, Personen)

Das klingt simpel. Ist es auch. Die Schwierigkeit liegt nicht in der Methodik, sondern darin, dass diese Fragen in vielen Unternehmen nie systematisch gestellt werden.

Warum IT-Leute die falschen Fragen stellen

Klassische Disaster Recovery beginnt bei den IT-Systemen: "Wir haben Backups für Server X, Failover für Datenbank Y, RPO von 4 Stunden, RTO von 8 Stunden."

Das klingt professionell. Ist es auch – technisch gesehen.

Aber hier liegt das Problem: Wenn dein ERP ausfällt, interessiert deine Kunden nicht dein RTO. Sie wollen wissen: Kann ich bestellen? Wann kommt meine Lieferung? Bekomme ich Support?

Ein Unternehmen, mit dem wir gearbeitet haben, hatte einen perfekten IT-Disaster-Recovery-Plan. Alle Systeme abgesichert, regelmässige Backup-Tests, alles dokumentiert. Dann fiel ein kritischer Lieferant durch einen Cyberangriff aus. Die Produktion stand still – nicht weil die eigene IT versagte, sondern weil niemand daran gedacht hatte, alternative Beschaffungswege zu planen.

Der DR-Plan half nicht. Weil das Problem nicht IT war. Es war fehlende Business-Prozess-Redundanz.

Der richtige Einstieg: Drei Fragen für morgen

Du musst nicht mit einem 6-monatigen BIA-Projekt starten. Beginne mit diesen drei Fragen – am besten morgen in deiner nächsten Geschäftsleitungssitzung:

Die drei Kernfragen einer Business Impact Analysis

1. Welche drei Prozesse erzeugen 80% unseres Umsatzes?

Nicht IT-Systeme. Geschäftsprozesse.

Bei einem Handelsunternehmen könnte das sein: Auftragserfassung, Lagerverwaltung, Versand. Bei einem Softwareunternehmen: Plattform-Verfügbarkeit, Kundensupport, Abrechnungslauf.

Die meisten Führungsteams können diese Frage nach kurzer Diskussion beantworten. Das Problem: Sie haben es nie explizit festgehalten.

2. Wie lange kann jeder dieser Prozesse ausfallen, bevor echter Schaden entsteht?

"Echter Schaden" heisst: Kunden verlieren, Vertragsstrafen zahlen, Reputationsschaden erleiden.

Sei konkret. "Auftragserfassung kann 2 Stunden ausfallen, danach verlieren wir Bestellungen." Oder: "Versand kann 24 Stunden pausieren, weil wir Puffer im Lager haben, aber danach wird es kritisch."

Diese Zeitfenster – in der Fachsprache "Recovery Time Objectives" (RTO) – sind der Ausgangspunkt für alles Weitere.

3. Was passiert, wenn [kritischer Cloud-Dienst/Lieferant/Person] morgen nicht verfügbar ist?

Hier wird es unangenehm. Weil die ehrliche Antwort oft ist: "Dann haben wir ein Problem."

  • Was passiert, wenn Microsoft 365 für 48 Stunden ausfällt?

  • Was passiert, wenn dein Hauptlieferant für Rohmaterial plötzlich nicht mehr liefern kann?

  • Was passiert, wenn die eine Person, die das kritische Legacy-System kennt, krank wird?

Diese Abhängigkeiten – intern und extern – sind oft die grössten blinden Flecken.

Die 70%-Regel: Perfekt ist der Feind von gut

Hier ein Gedanke, der gegen die Intuition geht: Du brauchst keine 100% Verfügbarkeit für kritische Prozesse.

Was du brauchst, ist die Fähigkeit, mit reduzierter Kapazität weiterzuarbeiten.

Ein Beispiel: Dein Online-Shop verarbeitet normalerweise 1.000 Bestellungen pro Stunde. Wenn dein primäres System ausfällt und du innerhalb von 30 Minuten auf ein Fallback-System wechseln kannst, das 700 Bestellungen pro Stunde schafft – dann hast du 70% deines Umsatzes geschützt.

Das ist oft besser als die Alternative: 48 Stunden warten, bis das primäre System wiederhergestellt ist.

Wir nennen das "Minimum Viable Operation" (MVO). Für jeden kritischen Prozess solltest du definieren: Was ist das absolute Minimum, um weiterzuarbeiten?

Der häufigste Fehler: Nicht testen

Business Impact Analysen sind wertlos, wenn sie in einer Schublade verstauben.

Wir haben Unternehmen gesehen, die jahrelang täglich Backups durchgeführt haben. Aber niemand hat jemals einen Recovery-Test gemacht. Als dann der Ernstfall kam, stellte sich heraus: Die Backups waren nicht wiederherstellbar. Verschlüsselungskeys veraltet. Software-Versionen inkompatibel.

Der Plan sah gut aus. Er funktionierte nur nicht.

Ein einfacher Test, den du in den nächsten 14 Tagen machen kannst:

  1. Nimm ein nicht-kritisches System offline

  2. Beobachte: Wer wird informiert? Wie schnell? Wer entscheidet?

  3. Dokumentiere, was passiert

Dieser Mini-Test zeigt mehr Schwachstellen auf als jede Risikoanalyse auf dem Papier.

Was eine BIA nicht ist (und nicht sein sollte)

Eine Business Impact Analysis ist kein 100-seitiges Dokument, das ein externer Berater erstellt und das dann niemand liest.

Sie ist auch kein einmaliges Projekt.

Eine gute BIA ist:

  • Kompakt: 5-10 Seiten für die kritischen Prozesse reichen

  • Aktuell: Mindestens jährlich überprüft, besser quartalsweise

  • Operativ: Die Ergebnisse führen zu konkreten Massnahmen

  • Getestet: Nicht nur dokumentiert, sondern regelmässig validiert

Der nächste Schritt

Wenn du nach dem Lesen dieses Artikels eine Sache tust, dann diese:

Plane für die kommende Woche ein 60-minütiges Meeting mit deiner Geschäftsleitung. Agenda: Die drei Fragen von oben.

  • Welche drei Prozesse erzeugen 80% unseres Umsatzes?

  • Wie lange kann jeder Prozess maximal ausfallen?

  • Was passiert, wenn [kritische Abhängigkeit] morgen ausfällt?

Die Antworten werden nicht perfekt sein. Das müssen sie auch nicht. Der Wert liegt darin, diese Fragen überhaupt zu stellen – und die Antworten festzuhalten.

Das ist der erste Schritt zu echter operativer Resilienz. Nicht mehr Dokumentation. Sondern Klarheit über das, was wirklich zählt.

Weiterführend

Dieser Artikel basiert auf dem ODCUS Whitepaper "Resilience Engineering für Business Continuity", das die Business Impact Analysis im Kontext eines vollständigen 5-Dimensionen-Frameworks behandelt.

Betrifft dich das Thema?

Erfahre mehr zu unseren Dienstleistungen rund um das Thema oder vereinbare unkompliziert ein Gespräch.

Kontaktiere uns!

Grabenstrasse 15a

6340 Baar

Switzerland

+41 43 217 86 70

Copyright © 2025 ODCUS | Alle Rechte vorbehalten.

Impressum