Business-Continuity-Plan für kleine Organisationen: Handlungsfähig bleiben, wenn Unerwartetes passiert

Als ich den Begriff Business Continuity Plan, kurz BCP, zum ersten Mal hörte, stellte ich mir ein dickes Dokument vor, das Banken, große Unternehmen und Teams mit niemals leeren Besprechungsräumen besitzen. Störungen wählen Organisationen jedoch nicht nach ihrer Größe aus. Ein kleiner Onlineshop kann keine Bestellungen mehr annehmen, weil sein Administratorkonto gesperrt ist; eine Agentur kann Arbeit verlieren, weil ihr wichtigster Laptop ausfällt; und ein Heimserver kann interne Dienste allein wegen eines mehrstündigen Stromausfalls lahmlegen.

Ein BCP ist keine Vorhersage, dass Probleme sicher eintreten werden. Es ähnelt eher einer Notfalltasche zu Hause: Hoffentlich muss sie nie geöffnet werden, doch wenn die Lage schlecht ist, müssen wir nicht in Panik alles von Grund auf zusammensuchen. Für kleine Organisationen ist ein einfacher Plan, den das Team versteht und tatsächlich getestet hat, viel nützlicher als ein formales Dokument, das nur in einem Drive-Ordner liegt.

Was schützt ein BCP eigentlich?

Business Continuity bezeichnet die Fähigkeit einer Organisation, wichtige Funktionen während einer Störung aufrechtzuerhalten und sich anschließend mit klarer Richtung zu erholen. Störungen können Ransomware, ein Internetausfall, ein Konfigurationsfehler, ein kleiner Brand, eine Überschwemmung, die Erkrankung einer Schlüsselperson oder Probleme bei einem Zahlungsdienstleister sein.

Es geht nicht darum, alles perfekt weiterlaufen zu lassen. Das ist selbst für große Unternehmen teuer. Realistischer ist es, drei Fragen zu beantworten: Welche Dienste sind am wichtigsten, wie lange dürfen sie ausfallen, und was tut das Team während der Störung?

BCP wird oft mit Disaster Recovery gleichgesetzt. Beides hängt zusammen, ist aber nicht dasselbe. Disaster Recovery ist technischer: eine Datenbank wiederherstellen, einen Server ersetzen oder ein Backup zurückspielen. BCP ist weiter gefasst: Kunden informieren, Entscheidungen zuordnen, Arbeit umverteilen und das Unternehmen dazu befähigen, weiterhin zu helfen, vielleicht auf einem einfacheren Weg.

Mit Prozessen beginnen, nicht mit Vorlagen

Ein naheliegender Fehler ist, eine BCP-Vorlage herunterzuladen und auf der ersten Seite den Unternehmensnamen einzutragen. Das Dokument sieht dann zwar ordentlich aus, beantwortet aber womöglich keine realen Bedingungen. Besser ist es, zunächst die täglichen Aktivitäten abzubilden, die die Organisation am Leben halten.

Ein Onlineshop hängt zum Beispiel von seinem Produktkatalog, Marketplace-Konto, Business-WhatsApp, Zahlungs-Gateway, Bestelldaten und der Person ab, die den Versand erledigt. Ein Designstudio hängt vielleicht stärker von Projektdateien, Kundengesprächen, Arbeitsgeräten und seinem Rechnungssystem ab. Schreiben Sie diese Dinge auf und markieren Sie, was Kunden oder den Cashflow sofort beeinträchtigen würde, wenn es ausfiele.

Stellen Sie sich ein Café vor, dessen Espressomaschine kaputtgeht. Es kann vielleicht weiterhin andere Getränke verkaufen, Zahlungen annehmen und Kunden die Situation erklären. Fallen aber auch Kasse, Zutatenbestand und Bestellkommunikation aus, wird das Problem deutlich größer. Dieselbe Denkweise hilft dabei, Kernfunktionen von unterstützenden Funktionen zu unterscheiden.

Vernünftige Zeitgrenzen festlegen

Zwei einfache Begriffe helfen bei der Priorisierung. Das Recovery Time Objective, kurz RTO, ist die maximale Zeit, in der ein Dienst nicht verfügbar sein darf. Das Recovery Point Objective, kurz RPO, beschreibt die Datenmenge, deren Verlust noch akzeptabel ist.

Bestelldaten könnten zum Beispiel ein RPO von einer Stunde haben, weil ständig neue Bestellungen eingehen. Backups oder Synchronisationen müssen dann häufig genug laufen, damit der Datenverlust eine Stunde nicht überschreitet. Ein Unternehmensblog kann dagegen ein RTO von zwei Tagen ohne große Folgen haben. Nicht jedes System muss in fünf Minuten wiederhergestellt werden; ein erzwungenes Ziel erhöht nur Kosten und Komplexität.

Layanan: data pesanan
Ein kompaktes Format wie dieses reicht als Ausgangspunkt. Entscheidend ist, dass die Zahlen von den Menschen vereinbart werden, die das Geschäft führen, und nicht allein von technischen Mitarbeitenden festgelegt werden.

Einen Ausweichweg vorbereiten, den Menschen nutzen können
Technologie ist oft ein wichtiger Teil eines BCP, doch ein guter Plan hängt nicht vollständig von Technologie ab. Kennt das Team die Kontaktnummern wichtiger Kunden, wenn das Bürointernet ausfällt? Gibt es einen Ersatzkanal für die Kommunikation, wenn das E-Mail-Konto Probleme macht? Ist ein sicherer Notfallzugang verfügbar, wenn die einzige Person mit allen Passwörtern nicht erreichbar ist?
Erstellen Sie eine Liste mit Kontakten, wichtigen Konten, Dienstleistern und Eskalationsschritten, auf die mehr als eine berechtigte Person sicher zugreifen kann. Ein Passwortmanager mit kontrolliertem gemeinsamem Zugriff ist wesentlich besser als Zugangsdaten, die nur in persönlichen Notizen stehen. Wenden Sie für wichtige Daten die 3-2-1-Backup-Regel an: drei Datenkopien auf zwei Arten von Medien, davon eine Kopie an einem anderen Ort.
Der Ausweichweg darf auch manuell sein. Fällt das Rechnungssystem aus, kann das Team Transaktionen auf einem einfachen Formular erfassen und nach der Wiederherstellung in das System eintragen. Das ist vielleicht nicht so elegant wie Automatisierung, aber das Vertrauen der Kunden zu erhalten ist wichtiger, als auf perfekte Verhältnisse zu warten.

Rollen und Kommunikation klären
Während einer Störung ist ein Informationsvakuum oft schädlicher als die Störung selbst. Kunden, die nicht wissen, was geschieht, treffen ihre eigenen Annahmen. Ein BCP muss daher festlegen, wer die Störung bestätigt, wer Dienstleister kontaktiert, wer Kunden informiert und wer berechtigt ist, den Dienst wieder als normal zu erklären.
Bereiten Sie außerdem sachliche Nachrichtenvorlagen vor. Eine ehrliche, kurze Nachricht genügt meist: den betroffenen Dienst erläutern, den Zeitpunkt der nächsten Aktualisierung nennen und den weiterhin aktiven Hilfekanal angeben. Versprechen Sie keine Wiederherstellungszeit, wenn das Team dafür keine belastbare Grundlage hat. Solche kleine Klarheit zeigt, dass die Organisation die Kontrolle behält.

Mit kleinen Szenarien testen
Ein Plan, der nie getestet wird, ist nur eine Annahme. Es ist nicht nötig, auf eine teure Großsimulation zu warten. Wählen Sie alle paar Monate ein Szenario, etwa eine nicht erreichbare Datenbank, ein gesperrtes primäres E-Mail-Konto oder einen Stromausfall während der Arbeitszeit. Lassen Sie das Team 30 Minuten lang die notwendigen Schritte besprechen.
Bei einfachen Übungen treten meist Lücken zutage, die beim Schreiben des Dokuments nicht sichtbar waren: Ein Backup wurde noch nie erfolgreich wiederhergestellt, eine Dienstleisternummer hat sich geändert, oder nur eine Person kennt den Speicherort der DNS-Konfiguration. Halten Sie diese Erkenntnisse fest, verbessern Sie den Plan und weisen Sie Verantwortung zu. Ein BCP ist ein lebendiges Dokument; es muss sich mit Systemen, Teams und Arbeitsweisen verändern.

Klein anfangen und den Plan pflegen
Für eine kleine Organisation ist ein genutzter BCP auf ein oder zwei Seiten wertvoller als ein verwirrendes Dokument mit hundert Seiten. Beginnen Sie mit den drei wichtigsten Diensten, legen Sie einfache RTO- und RPO-Ziele fest, bereiten Sie Kontakte und Arbeitsalternativen vor und führen Sie dann eine Übung durch. Anschließend können Sie nach und nach Details ergänzen.
Störungen lassen sich vielleicht nicht vollständig vermeiden, so wie wir Regen nicht aufhalten können. Wir können aber sicherstellen, dass das Dach nicht leckt, eine Taschenlampe bereitliegt und jeder im Haus weiß, wo sie ist. Darin liegt der Wert eines Business-Continuity-Plans: Er macht eine Organisation nicht immun gegen Probleme, sondern hilft ihr, ruhig, ehrlich und handlungsfähig zu bleiben, wenn Probleme eintreten. Wenn Sie bereits einen einfachen Wiederherstellungsprozess haben, teilen Sie in den Kommentaren, welcher Teil am schwierigsten vorzubereiten war.