Business Continuity Management: Flussdiagramm des BCM-Prozesses

Was ist business continuity management: flussdiagramm des bcm-prozesses?

Der Business-Continuity-Prozess hält eine Organisation lieferfähig, während etwas kaputt ist. Er ist nicht dasselbe wie Disaster Recovery. Disaster Recovery ist die technische Arbeit an Systemen und Daten (Umschaltung, Backups, Wiederanlaufzeiten, Wiederherstellungspunkte) und damit ein Baustein der Kontinuität, nicht die Kontinuität selbst. Viele Auslösungen haben mit IT überhaupt nichts zu tun: Ein Gebäude ist nicht zugänglich, ein Single-Source-Lieferant fällt aus, Unwetter oder Arbeitskampf nehmen Ihnen den größten Teil einer Schicht. Die Frage, die dieser Prozess beantwortet, lautet nicht „Wann läuft das System wieder?“, sondern „Wie bedienen wir unsere Kunden, bis es wieder läuft?“

Die Abgrenzung zu den Nachbarprozessen sollte man deutlich aussprechen, denn Diagramme, die sie verwischen, werden in der echten Störung ignoriert. Eine einzelne Betriebsstörung innerhalb der normalen Toleranzen gehört ins Incident Management, das den Service gegen ein SLA wiederherstellt. Ein bestätigter Cyberangriff gehört in die Incident Response, die Eindämmung, Beweissicherung und Meldepflichten verantwortet. Der technische Wiederanlauf gehört in das Disaster-Recovery-Handbuch. Business Continuity liegt über allen dreien: Der Prozess stellt fest, dass die Störung eine Schwelle überschritten hat, priorisiert, welche Geschäftsaktivitäten zuerst geschützt werden, und fährt den Notbetrieb, der das Geschäft zusammenhält, während die technischen Teams arbeiten.

Kontinuitätsprozesse scheitern meist an vier vorhersehbaren Stellen, und das Diagramm unten ist so gezeichnet, dass es genau diese schließt. Die Auslösung verzögert sich, weil vorher nie festgelegt wurde, wer auslösen darf und nach welchen Kriterien. Die Prioritäten setzt am Ende, wer am lautesten eskaliert, statt der Wiederanlaufzeiten, die in der Business Impact Analyse längst stehen. Der Notbetrieb existiert auf dem Papier, aber die Papierformulare, die Offline-Daten und die manuellen Freigabegrenzen, die er voraussetzt, wurden nie vorbereitet. Und die Rückkehr in den Normalbetrieb erfolgt ohne vereinbarte Kriterien, sodass das Geschäft mit einem Rückstand weiterläuft, für den sich niemand verantwortlich fühlt. Fünf Bahnen (Notfallteam, Fachbereichsleitungen, BCM-Koordination, Kommunikation und Geschäftsleitung) tragen den Ablauf über fünf Phasen, mit zwei Entscheidungen: ob der Notfallplan ausgelöst wird und ob der Normalbetrieb wieder aufgenommen wird.

Was dieses Flussdiagramm abdeckt

In dieser Vorlage

• Fünf Swimlanes mit einem benannten Verantwortlichen für jeden Schritt (Notfallteam, Fachbereichsleitungen, BCM-Koordination, Kommunikation und Geschäftsleitung) über fünf Phasen: Bewertung und Auslösung, Mobilisierung, Notbetrieb, Überwachung und Prüfung sowie Wiederherstellung und Auswertung.
• Ein messbarer Einstieg: „Störung an die Bereitschaftsleitung gemeldet“ führt auf „Betroffene Standorte und Funktionen bestätigen“ und dann auf „Auswirkung gegen Auslöseschwellen bewerten“, sodass der Auslöser an der Business Impact Analyse geprüft und nicht nach Gefühl beurteilt wird.
• Die Entscheidung „Notfallplan auslösen?“, deren Zweig Unter Schwelle in „Im Normalbetrieb bearbeiten“ läuft und bei Eskalation zur erneuten Bewertung zurückführt. Ein Beinaheereignis wird also weiter beobachtet statt vergessen.
• Die Mobilisierung nach der Auslösung: „Notfallteam einberufen“, „Kritische Funktionen nach BIA priorisieren“, „Beschäftigte informieren und Vollzähligkeit prüfen“ in der Bahn Kommunikation und „Notfallbudget und Vollmachten freigeben“ in der Bahn der Geschäftsleitung.
• Der eigentliche Notbetrieb: „Notbetrieb und manuelle Abläufe aktivieren“, „Ausweichstandorte und Homeoffice organisieren“ und „Kunden und Stakeholder informieren“: die Schritte, die Kontinuität von technischem Wiederanlauf unterscheiden.
• Ein Statuszyklus mit kontrolliertem Ausstieg: „Lage in festgelegten Intervallen prüfen“ mündet in „Normalbetrieb wieder aufnehmen?“, wo Noch nicht auf „Notbetrieb verlängern“ und zurück zur nächsten Prüfung führt, während Wiederaufnehmen über Wiederherstellung und Abarbeitung der Rückstände, Auflösung des Notfallteams, Bestätigung der Rückkehr zum Regelbetrieb und Nachbereitung bis zu „BIA und Notfallplan aktualisieren“ läuft.

Wann Sie diese Vorlage verwenden sollten

• Sie schreiben oder überarbeiten einen Notfallplan und brauchen eine Seite, die zeigt, wer was in welcher Reihenfolge entscheidet, bevor der Plan unter Druck gelesen wird.
• Sie wollen Auslösebefugnis und Auslöseschwellen vorab festlegen, inklusive Vertretung außerhalb der Geschäftszeiten, damit die erste Stunde nicht mit der Frage vergeht, ob dieser Fall überhaupt zählt.
• Sie trennen Ihren Notfallplan vom IT-Disaster-Recovery-Handbuch, damit jedes Dokument seinen eigenen Geltungsbereich abdeckt und die Übergabe zwischen beiden ausdrücklich beschrieben ist.
• Sie führen eine Notfallübung durch: Die beiden Entscheidungen, die Prüfschleife und die Übergaben zwischen den Bahnen geben Ihnen etwas Konkretes zum Testen, und zum Scheiternlassen.
• Sie briefen Fachbereichsleitungen darauf, was während einer Störung von ihnen erwartet wird, insbesondere auf den manuellen Notbetrieb und die anschließende Nacherfassung.
• Sie bereiten ein BCM-Audit oder einen Resilienz-Fragebogen eines Kunden vor, der einen dokumentierten Prozess mit benannten Verantwortlichen sehen will.

So funktioniert es

1. Benennen Sie die Bahnen nach Ihrer echten Notfallorganisation

   Ersetzen Sie Notfallteam, Fachbereichsleitungen, BCM-Koordination, Kommunikation und Geschäftsleitung durch die Rollen, die es bei Ihnen tatsächlich gibt: Krisenstab, Einsatzleitung, Standortleitung, Resilienzbeauftragter, Bereitschaftsdirektor. Kleinere Organisationen führen die BCM-Koordination häufig mit dem Notfallteam zusammen. Löschen Sie dann die Bahn, statt sie unbesetzt stehen zu lassen.

2. Schreiben Sie Auslösekriterien und Auslösebefugnis auf

   Öffnen Sie „Notfallplan auslösen?“ und hinterlegen Sie Ihren eigenen Test: Die erwartete Ausfalldauer überschreitet die Wiederanlaufzeit einer kritischen Funktion, oder ein Standort beziehungsweise Lieferant fällt länger als eine vereinbarte Frist aus. Benennen Sie, wer auslösen darf, benennen Sie die Vertretung und hinterlegen Sie einen Erreichbarkeitsweg außerhalb der Geschäftszeiten. Ein Auslösekriterium, das erst in einer Sitzung ausgelegt werden muss, wird um drei Uhr nachts nicht angewendet.

3. Hängen Sie Ihre Business Impact Analyse an den Priorisierungsschritt

   „Kritische Funktionen nach BIA priorisieren“ ist nur so gut wie die Analyse dahinter. Listen Sie Ihre kritischen Aktivitäten in der Reihenfolge ihrer Wiederanlaufzeiten und halten Sie fest, wovon jede abhängt: Personen, Gebäude, Systeme, Daten und Lieferanten. Wenn die Abhängigkeiten einer Funktion unbekannt sind, ist genau das die Lücke, auf die die nächste Übung zielen sollte.

4. Machen Sie den Notbetrieb konkret und nachweisbar

   Ersetzen Sie „Notbetrieb und manuelle Abläufe aktivieren“ durch die benannte Ersatzlösung je kritischer Funktion, ihre Kapazitätsgrenze, ihre maximale Laufzeit und das, was vorab vorbereitet sein muss: gedruckte Formulare, Offline-Kopien wichtiger Daten, eine manuelle Freigabegrenze. Ergänzen Sie, wer die manuell erfassten Vorgänge nacherfasst, sobald die Systeme wieder laufen. Im Rückstand zeigt sich das Versagen der Kontinuität am häufigsten.

5. Legen Sie Prüftakt und Rückkehrkriterien fest

   Entscheiden Sie, wie oft „Lage in festgelegten Intervallen prüfen“ ausgelöst wird (anfangs stündlich, später in größeren Abständen) und welche Nachweise „Normalbetrieb wieder aufnehmen?“ verlangt: Kapazität wiederhergestellt, Beschäftigte und Gebäude sicher, Rückstand beziffert und mit einem Verantwortlichen versehen. Eine Rückkehr ohne Kriterien ist der Beginn der zweiten Störung.

6. Üben Sie das Diagramm und veröffentlichen Sie eine freigegebene Fassung

   Gehen Sie es mit jeder Bahn durch und korrigieren Sie die Schritte auf das, was die Leute wirklich tun. Spielen Sie es anschließend als Planübung mit einem Szenario ohne IT-Bezug durch: Standortausfall oder Lieferantenausfall. Halten Sie fest, was die Übung verändert, führen Sie es in „BIA und Notfallplan aktualisieren“ zurück und veröffentlichen Sie die abgestimmte Fassung, damit alle sehen, welche Revision gilt.

Häufig gestellte Fragen

Worin unterscheiden sich Business Continuity und IT-Disaster-Recovery?

Business Continuity hält die Geschäftstätigkeit während einer Störung aufrecht: Personen, Gebäude, Lieferanten, Kunden, manueller Notbetrieb. Disaster Recovery stellt Technik wieder her: Systeme, Anwendungen und Daten, gemessen an Wiederanlaufzeit (RTO) und Wiederherstellungspunkt (RPO). Disaster Recovery ist eine Fähigkeit, die Kontinuität unterstützt, und kein Ersatz dafür. Ein Notfallplan wird auch bei Ereignissen ohne jede technische Ursache ausgelöst, etwa wenn ein Gebäude nicht nutzbar ist oder ein kritischer Lieferant ausfällt; und selbst während eines IT-Ausfalls lautet die Kontinuitätsfrage, wie das Geschäft weiterläuft, während das DR-Team arbeitet. In diesem Diagramm steckt der Unterschied in „Notbetrieb und manuelle Abläufe aktivieren“: Der technische Wiederanlauf läuft parallel, nach seinem eigenen Handbuch.

Wer entscheidet über die Auslösung des Notfallplans?

Eine benannte Rolle mit delegierter Befugnis, plus eine Vertretung für Zeiten außerhalb der Geschäftszeiten. In diesem Diagramm liegt die Entscheidung bei der BCM-Koordination, die dokumentierte Kriterien anwendet; unmittelbar danach gibt die Geschäftsleitung Notfallbudget und Vollmachten frei. Viele Organisationen legen die Auslösung stattdessen auf einen Bereitschaftsdirektor oder eine Krisenstabsleitung. Wichtiger als der Titel ist, dass die Kriterien vor dem Ereignis schriftlich vorliegen und objektiv genug sind, damit eine einzelne Person sie nachts anwenden kann. Auslösen ist eine Geschäftsentscheidung mit Kosten. Der häufigere Fehler ist jedoch, zu spät auszulösen und die ersten Stunden in der Diskussion zu verlieren.

Was sind Auslöseschwellen und woher kommen sie?

Sie kommen aus der Business Impact Analyse. Für jede kritische Aktivität hält die BIA fest, wie lange sie unterbrochen sein darf, bevor die Folgen untragbar werden (die maximal tolerierbare Ausfallzeit) und eine Wiederanlaufzeit innerhalb dieser Grenze. Eine Auslöseschwelle macht aus diesen Zahlen einen Auslöser: Ist zu erwarten, dass die Störung die Wiederanlaufzeit einer kritischen Aktivität überschreitet, wird der Plan ausgelöst. Regulierte Unternehmen bekommen ein Äquivalent teilweise von außen vorgegeben; DORA verpflichtet Finanzunternehmen in der EU etwa dazu, kritische oder wichtige Funktionen zu identifizieren und Wiederherstellungsziele dafür festzulegen.

Wie lange darf der Notbetrieb laufen, bevor in den Normalbetrieb zurückgekehrt wird?

So lange, wie die Rückkehrkriterien nicht erfüllt sind. Deshalb enthält das Diagramm eine Schleife statt einer festen Dauer. „Lage in festgelegten Intervallen prüfen“ und „Notbetrieb verlängern“ existieren, weil Ersatzlösungen ein Haltbarkeitsdatum haben: manuelle Verarbeitungskapazität, Ausweichflächen und Kundengeduld nehmen ab, und der Rückstand wächst die ganze Zeit. Setzen Sie den Prüftakt am Anfang eng und dehnen Sie ihn, sobald sich die Lage stabilisiert, und behandeln Sie die Rückkehr als Entscheidung, die jemand zeichnet, statt als schleichendes Zurückfallen in alte Gewohnheiten.

Sind wir mit dieser Vorlage ISO-22301-konform?

Nein. Die ISO 22301 ist die internationale Norm für Business-Continuity-Managementsysteme, und die Konformität hängt am gesamten System (Verpflichtung der Leitung, Business Impact Analyse und Risikobeurteilung, dokumentierte Pläne und Verfahren, Übungen und Tests, Leistungsbewertung und Verbesserung) und nicht an einem einzelnen Diagramm. Eine klare Prozesslandkarte mit benannten Verantwortlichen unterstützt mehrere dieser Anforderungen und ist im Audit oder im Kundenfragebogen ein brauchbarer Nachweis, sie ist aber ein Bestandteil des Managementsystems und nicht sein Beleg. Im deutschsprachigen Raum lohnt zusätzlich der Blick in den BSI-Standard 200-4, der denselben Ablauf für den IT-Grundschutz beschreibt.