Zum Hauptinhalt springen

Tipps zur Erstellung einer Business Impact Analyse (BIA)

Wie lange könnte ihr Unternehmen ohne IT-Systeme überleben? Drei Tag, drei Stunden oder nur drei Minuten?

Diese Frage wirkt auf den ersten Blick provokant, bringt aber den Kern der Business Impact Analyse (BIA) auf den Punkt: Wie abhängig sind Ihre Geschäftsprozesse von stabiler IT und wie schnell müssen sie im Krisenfall wieder verfügbar sein?

Als Berater für IT-Architektur und Continuity Management begleite ich regelmässig Unternehmen bei der Einführung von Business Continuity Management (BCM). Die Business Impact Analyse ist dabei ein entscheidender Schritt, weil sie Klarheit schafft: Welche Prozesse sind wirklich kritisch, welche Ressourcen unverzichtbar und welche Wiederanlaufzeiten (RTO) akzeptabel?

Blogserie: Business Continuity Management

Dieser Blogartikel ist der Leitartikel einer mehrteiligen Serie der sich an Entscheidungsträger und Fachverantwortliche aus BCM, Risikomanagement, IT und anderen Unternehmensbereichen richtet. Es gibt einen Überblick, wie die einzelnen Elemente des Business Continuity Management Systems aufgebaut sind und gemeinsam zur Stärkung resilienter Geschäftsprozesse beitragen.

Dies ist Teil 2 von 9 der Serie über Business Continuity Management.

Teil 1: Der Aufbau eines Business Continuity Management Systems (BCMS)
Teil 3: Risikoanalyse: Checkliste zur Erstellung einer Risikoanalyse
Teil 4: BCM-Strategie: Ziele und Elemente der BCM-Strategie
Teil 5: Konzeption und Implementierung
Teil 6: Organisation und Prozesse
Teil 7: Business Continuity Pläne BCP: Die Erstellung eines Business Continuity Plans
Teil 8: Tests, Reviews und Training
Teil 9: Pflege und Aktualisierung

Warum eine BIA so wichtig ist

Mit der Business Impact Analyse verschaffen Sie sich ein klares Bild über Ihre Organisation. Sie erkennen, welche Prozesse kritisch sind, welche Ressourcen unverzichtbar sind und wo Abhängigkeiten bestehen. Sie können den Schaden beziffern, der bei einem Ausfall entsteht, sei es finanziell, operativ, regulatorisch oder reputationsbezogen.

Am Ende steht eine sogenannte Heatmap, die Ihnen zeigt, welche Prozesse ab wann kritisch werden und durch welches Szenario. Damit haben Sie nicht nur ein internes Steuerungsinstrument in der Hand, sondern erfüllen auch regulatorische Anforderungen, etwa von FINMA, SBV, DORA oder CRA.

Typische Stolperfallen

Viele BIAs scheitern nicht am guten Willen, sondern an methodischen Schwächen. Häufig sind die Schadensszenarien zu unklar definiert, es werden unterschiedliche Metriken verwendet oder Abhängigkeiten zwischen Prozessen sind nicht bekannt. Auch kommt es vor, dass Ressourcen wie Applikationen oder IT-Services nicht eindeutig erfasst werden. Und wenn Prozessverantwortliche ihre eigene Kritikalität überschätzen, sind die Ergebnisse weder vergleichbar noch praktikabel. Das führt zu langen, mühsamen Analysen, die am Ende keinen Mehrwert bieten.

Ein bewährtes Vorgehen in fünf Phasen

Über die Jahre hat sich ein Vorgehen in fünf klaren Phasen bewährt:

  1. Vorbereitung
    Zuerst definiere ich gemeinsam mit meinen Kunden die relevanten Schadensszenarien – etwa Ausfall von IT, Personal, Gebäuden oder Lieferanten. Ergänzt werden sie durch externe Risiken wie Cyberangriffe, geopolitische Ereignisse oder Naturkatastrophen. Anschliessend legen wir Schadenkategorien und Metriken fest, erstellen den BIA-Fragebogen und beschränken den Umfang bewusst auf die wichtigsten Prozesse.
  2. Pilotphase
    Ich empfehle, mit einem einzelnen Prozess zu starten, der als wichtig eingestuft wird. In dieser Pilot-BIA wird der Fragebogen getestet und gegebenenfalls angepasst. In einem Kick-off-Meeting erläutere ich allen Prozessverantwortlichen Ziele, Vorgehen und Metriken und stelle die Ergebnisse der Pilotanalyse als Beispiel vor.
  3. Hauptphase
    Nun folgt die Durchführung der Interviews mit allen relevanten Prozessverantwortlichen. Gemeinsam analysieren wir die Prozesse anhand des Fragebogens und lassen die Ergebnisse jeweils durch die Vorgesetzten prüfen.
  4. Konsolidierung
    Danach werden die Ergebnisse konsolidiert. Das zentrale Ergebnis ist eine UnternehmensHeatmap, die auf einen Blick zeigt, welche Prozesse aus welchem Grund kritisch sind und wie sich die Kritikalität über die Zeit entwickelt.
  5. Vernehmlassung und Abschluss
    Zum Schluss validieren die Prozessverantwortlichen die konsolidierten Ergebnisse. Ich bereite ein Management Summary vor, das die Kernergebnisse und Handlungsempfehlungen enthält. Daraus ergeben sich Sofortmassnahmen, die Entwicklung einer übergeordneten BCM-Strategie sowie die Erstellung oder Aktualisierung von Business Continuity Plänen.

Details zur Umsetzung

Die fünf Phasen klingen in der Übersicht einfach. In der Praxis entscheidet jedoch die konsequente und saubere Umsetzung darüber, ob Sie am Ende wirklich ein belastbares Steuerungsinstrument haben oder nur eine Sammlung unvollständiger Tabellen. Deshalb möchte ich die einzelnen Schritte hier vertiefen und praxisnah erläutern.

1. Klare Definition der Schadensszenarien

Ein häufiger Stolperstein liegt in der ungenauen Definition der Szenarien. Damit Ergebnisse vergleichbar sind, müssen die Szenarien so konkret wie möglich beschrieben werden.

Ein IT-Ausfall bedeutet zum Beispiel nicht einfach, dass «die Systeme nicht funktionieren». Gemeint ist, dass sämtliche zentralen IT-Services, inklusive Kommunikation, für Tage bis Wochen nicht verfügbar sind, während Gebäude, Mitarbeitende und Partner intakt bleiben. Ähnlich präzise sollten auch andere Szenarien beschrieben werden:

  • Personalausfall: Schlüsselpersonen oder ein grosser Teil der Belegschaft sind für längere Zeit nicht erreichbar, auch nicht telefonisch.
  • Gebäudeausfall: Der Hauptstandort ist zerstört oder unzugänglich, während andere Gebäude in der Region intakt bleiben.
  • Lieferantenausfall: Ein kritischer Partner fällt plötzlich aus, die Dauer der Störung ist nicht absehbar.
  • Weitere externe Risiken: Je nach Umfeld müssen auch Cyberangriffe, Datenabflüsse, geopolitische Disruptionen oder Naturereignisse berücksichtigt werden.

Durch diese Klarheit schaffen Sie die Grundlage für strukturierte Interviews und vermeiden endlose Diskussionen über Annahmen.

Zur einfacheren Darstellung der Schadenszenarien, z. B. in der Heatmap, werden Icons verwendet.

2. Schadenkategorien

Um die Auswirkungen eines Ereignisses systematisch bewerten zu können, ist eine Einteilung in klar definierte Schadenkategorien notwendig. In der Praxis unterscheide ich fünf Dimensionen, die zusammen ein vollständiges Bild ergeben:

  • Finanzieller Schaden: Direkte Kosten wie Umsatzverluste, Vertragsstrafen oder Wiederherstellungskosten, aber auch indirekte Auswirkungen wie entgangene Geschäftsmöglichkeiten oder Wertverluste durch Reputationsschäden.
  • Operativer Schaden: Einschränkungen in Prozessen, Produktionsstillstände oder fehlende Ressourcen, die die Leistungserbringung unmittelbar beeinträchtigen.
  • Rechtlicher und regulatorischer Schaden: Folgen durch Verstösse gegen Gesetze oder branchenspezifische Vorschriften, z. B. Datenschutz oder Compliance-Vorgaben.
  • Imageschaden: Vertrauensverlust bei Kunden, Partnern oder Investoren, oft verschärft durch negative Medienberichte oder Social Media Reaktionen.
  • Zeitlicher Schaden: Verzögerungen bei der Wiederherstellung von Prozessen, verpasste Lieferfristen oder nicht eingehaltene regulatorische Deadlines.

Diese Kategorisierung sorgt dafür, dass nicht nur die offensichtlichen finanziellen Verluste betrachtet werden, sondern auch die weniger greifbaren, aber oft genauso kritischen Schäden.

3. Schadenmetriken

Die Kategorisierung allein reicht nicht aus – ohne messbare Metriken bleibt die Bewertung zu vage. Deshalb definiere ich für jede Schadenkategorie konkrete Schwellenwerte, die auf die Unternehmensgrösse und Branche zugeschnitten sind.

  • Finanzieller Schaden: Stufe 1 entspricht einem Verlust bis 100’000 CHF, Stufe 2 reicht von 0,5 bis 1 Mio. CHF, Stufe 3 liegt im zwoschen 1 und 5 Mio. CHF, und Stufe 4 bedeutet Verluste über 5 Mio. CHF, was die Existenz des Unternehmens gefährden kann.
  • Operativer Schaden: Stufe 1 bedeutet Einschränkungen für wenige Stunden, Stufe 2 einen Tagesausfall, Stufe 3 mehrere Tage Produktionsstillstand, und Stufe 4 beschreibt den Ausfall von Kernprozessen über eine Woche oder länger, wodurch zentrale Geschäftsziele nicht mehr erreicht werden können.
  • Rechtlicher Schaden: Skala von internen Richtlinienverstössen (Stufe 1) bis hin zu behördlichen Sanktionen oder Lizenzentzug (Stufe 3). Stufe 4 bedeutet gravierende Verstösse mit internationalen Konsequenzen, z. B. Verlust von Zulassungen, massiven Strafen oder gerichtlichen Auflagen, die das Geschäftsmodell infrage stellen.
  • Reputationsschaden: Stufe 1 betrifft die Wahrnehmung bei einzelnen Kunden, Stufe 2 hat regionale Auswirkungen, Stufe 3 betrifft das nationale oder gar internationale Ansehen des Unternehmens, und Stufe 4 steht für einen irreversiblen Reputationsverlust, der das Vertrauen von Kunden, Partnern, Investoren oder der Öffentlichkeit dauerhaft zerstört.
  • Zeitlicher Schaden: Skala von kurzfristigen Verzögerungen (Stufe 1) bis hin zu systemkritischen Terminüberschreitungen bei regulatorischen Fristen (Stufe 3). Stufe 4 bedeutet, dass Fristen in kritischen Projekten oder regulatorischen Vorgaben dauerhaft nicht eingehalten werden können, was zu erheblichen Sanktionen oder zum Verlust von Marktanteilen führt.

Die Zuordnung zu diesen Metriken erfolgt gemeinsam mit den Fach- und Prozessverantwortlichen. Wichtig ist, dass alle dieselben Skalen anwenden. Nur so wird die spätere Konsolidierung zu einer Heatmap möglich, die das Management als Entscheidungsgrundlage nutzen kann.

Eine Heatmap für ein KMU-Industriebetrieb könnte zum Beispiel so aussehen:

4. Der BIA-Fragebogen als zentrales Werkzeug

Der Fragebogen ist das zentrale Werkzeug, um die relevanten Informationen strukturiert zu erfassen. Er deckt drei Dimensionen ab:

  1. Allgemeine Prozessinformationen: Zweck, Prozesstyp, Verantwortliche, Mitarbeitende (FTE), Abhängigkeiten zu vor- und nachgelagerten Prozessen, benötigte IT-Services und Kommunikationsmittel.
  2. Fragen zu Schadensszenarien und Ressourcen: etwa ob Notfallpläne vorhanden sind, ein Notbetrieb möglich ist, Umschaltprozeduren existieren oder welche Minimalanforderungen für den Betrieb gelten.
  3. Eruierung des Business Impact: hier wird der Schaden über die Zeitachse bewertet, ergänzt durch Schlüsselfaktoren wie RTO, RPO, alternative Prozesse oder vorhandene Notfallkonzepte.

Aus diesen Antworten ergibt sich ein Gesamtbild, das ich im Anschluss mit den Prozessverantwortlichen verdichte. Besonders wichtig ist die Einschätzung des Recovery Time Objective (RTO) und des Recovery Point Objective (RPO). Zusätzlich ziehe ich den Maximum Tolerable Period of Disruption (MTPD) heran. Das ist die Grenze, ab der ein Prozessausfall die Existenz des Unternehmens gefährden könnte.

Ob der BIA-Fragebogen mit einfachen Werkzeugen erstellt (Word, Excel, Power BI) oder in einem BIA Tool umgesetzt wird hängt von den Präferenzen und Möglichkeiten der Unternehmungen ab. Wichtig sind die Qualität und Aktualität der Informationen.

5. Die mutmasslich wichtigsten Prozesse

Eine vollständige Erfassung aller Prozesse gleich zu Beginn ist weder praktikabel noch zielführend. Deshalb konzentriere ich mich zuerst auf die «mutmasslich wichtigsten Prozesse». Diese finden sie in Gesprächen mit langjährigen Mitarbeitenden bzw. Vorgesetzten schnell. Subprozesse können später ergänzt werden, sobald das Fundament gelegt ist. Dieser pragmatische Ansatz stellt sicher, dass wir schnell greifbare Ergebnisse vorliegen haben.

6. Pilotprozess

Bevor die Breite der Organisation einbezogen wird, wähle ich einen einzelnen Prozess für einen Pilotlauf aus. Entscheidend ist, dass er für das Unternehmen bedeutend ist und der verantwortliche Prozess-Owner bereit ist, aktiv mitzuarbeiten. Dieser Pilotprozess dient als Testfeld, um die Methodik zu validieren und Vertrauen aufzubauen.

7. Pilot-BIA

Gemeinsam mit dem Prozessverantwortlichen führe ich für den Pilotprozess eine vollständige BIA durch. Dabei überprüfen wir, ob die Fragen verständlich sind, die Metriken praktikabel und die Szenarien realistisch. Die gewonnenen Erkenntnisse helfen, den Fragebogen zu schärfen. Gleichzeitig dienen die Ergebnisse als anschauliches Beispiel für andere Prozessverantwortliche.

8. Kickoff Meeting mit den Prozessverantwortlichen

Nach der Pilotphase lade ich alle beteiligten Verantwortlichen zu einem Kickoff ein. In diesem Meeting erläutere ich den Sinn und Zweck der BIA, stelle die Methodik vor und gehe auf die definierten Szenarien sowie Metriken ein. Durch die Präsentation der Pilot-BIA können die Teilnehmenden sehen, wie die Resultate aussehen und welchen Nutzen sie haben. Dieses gemeinsame Verständnis ist entscheidend für den Erfolg der Hauptphase.

9. Gemeinsame Durchführung der BIA

In den anschliessenden Interviews werden die Prozesse mithilfe des Fragebogens detailliert analysiert. Ich betone stets, dass es in der BIA um ausserordentliche, existenzielle Ereignisse geht und nicht um kleinere Störungen, die im Availability Management behandelt werden. Damit verhindere ich, dass Verantwortliche ihre Prozesse überbewerten oder falsche Prioritäten setzen.

10. Review & Vernehmlassung der BIA-Ergebnisse

Nach Abschluss der Interviews lasse ich die Resultate jeweils durch die Vorgesetzten der Prozessverantwortlichen prüfen. Dieses Review stellt sicher, dass die Ergebnisse nicht nur fachlich, sondern auch hierarchisch abgestützt sind. So gewinnen sie an Verbindlichkeit im Unternehmen.

11. Konsolidierung der Ergebnisse

Alle Einzelanalysen werden nun zu einem Gesamtbild verdichtet. Dabei entstehen Übersichten, in denen die wichtigsten Abhängigkeiten, kritischen Ressourcen und Bedrohungen dargestellt sind. Das zentrale Instrument dieser Phase ist die Unternehmens-Heatmap, welche die Kritikalität aller Prozesse über die Zeitachse abbildet. Diese Visualisierung macht deutlich, wo die grössten Risiken liegen und welche Prozesse als Erstes geschützt werden müssen.

Der Hauptprozess 1 ist bei einem «Ausfall IT» bereits nach 1 Tag «kritisch» wegen betrieblichen und potenziellem finanziellen Schaden in der Höhe von > 5 Mio., ausgelöst durch die Subprozesse 1_A, 1_B und 1_C. Im Hauptprozess 2 ist der Imageschaden das Hauptproblem. Taktgeber sind die Szenarien «Ausfall IT» und «Ausfall Personen». «Wahrnehmbar» ab dem ersten Tag, «Nachhaltig» ab dem 5 Ausfalltag, ausgelöst durch den Subprozess 2_B.

12. Vernehmlassung der konsolidierten Ergebnisse

Bevor die Ergebnisse finalisiert werden, bespreche ich sie nochmals im Kreis aller Prozessverantwortlichen. Diese gemeinsame Vernehmlassung sorgt dafür, dass alle Beteiligten ihre Prozesse im Kontext der Gesamtorganisation sehen. Eventuelle Missverständnisse oder Ergänzungen können hier adressiert werden, bevor das Management die Resultate erhält.

13. Abschlusspräsentation Management

Für die Unternehmensleitung bereite ich ein Management Summary vor. Darin präsentiere ich die Heatmap, die zentralen Erkenntnisse und konkrete Empfehlungen. Dazu gehören Sofortmassnahmen wie technische Redundanzen oder organisatorische Anpassungen, aber auch die Ausarbeitung einer umfassenden BCM-Strategie und die Erstellung bzw. Aktualisierung von Business Continuity Plänen.

Kontinuität statt Einmalprojekt

Eine Business Impact Analyse ist kein Dokument, das man einmal erstellt und dann ablegt. Sie muss regelmässig überprüft und aktualisiert werden, sei es jährlich, nach organisatorischen Veränderungen oder bei neuen regulatorischen Anforderungen. Nur dann bleibt sie ein wirksames Steuerungsinstrument.

Fazit

Die Business Impact Analyse ist weit mehr als eine Checkliste. Sie ist ein strategisches Steuerungsinstrument, das Ihnen hilft, klare Prioritäten zu setzen, Risiken zu verstehen und regulatorischen Anforderungen gerecht zu werden. Wenn Sie pragmatisch starten, methodisch konsequent vorgehen und die Ergebnisse regelmässig aktualisieren, schaffen Sie eine solide Basis, um Ihr Unternehmen auch in Ausnahmesituationen handlungsfähig zu halten.

Martin Zwyssig, Mitglied der Geschäftsleitung, Bereichsleiter Services

Martin Zwyssig ist Mitgründer der Firma In&Out und Mitglied der Geschäftsleitung. Er beschäftigt sich seit mehr als 35 Jahren mit Business- und IT Service Continuity Management in verschiedenen Branchen.

Martin Zwyssig per E-Mail kontaktieren
LinkedIn Profil besuchen