Das integrierte BCM-/BIA-DatenmodellVon verteilten Daten zu messbarer Resilienz

Christian Horres

Experte für Business Continuity Management (BCM), Risikomanagement und organisatorische Resilienz, insbesondere im Umfeld kritischer Infrastrukturen. Sein Schwerpunkt liegt auf Business Impact Analysen (BIA), Risikoanalysen sowie dem Aufbau und der Weiterentwicklung von BCM- und Krisenmanagementstrukturen. Im NOVELEDGE-Netzwerk unterstützt er Organisationen bei der praktischen Umsetzung resilienter Strukturen unter Berücksichtigung internationaler Standards wie ISO 22301, ISO 27001 und ISO 31000 und geltender Regulatorik.

Business Continuity Management wird häufig in Dokumenten, Tabellen und Einzelinterviews betrieben. Die entscheidenden Daten existieren jedoch längst – nur verteilt: Produkte und Deckungsbeiträge im ERP, Anlagen im EAM, IT-Services in der CMDB, Rollen im HR-System, Verträge bei Einkauf und Recht, Gebäudeinformationen im Facility Management und Wiederherstellungswerte in Tests oder Störungsprotokollen. Ein integriertes BCM-/BIA-Datenmodell verbindet diese Informationen zu einer belastbaren Entscheidungsgrundlage.

Der Nutzen entsteht dabei nicht durch eine möglichst große Datenbank. Er entsteht durch die richtigen Beziehungen: Welches Produkt hängt von welchem Prozess ab? Welche Aktivität benötigt welche Personen, Gebäude, IT-Services, OT-Anlagen und Lieferanten? Welche Wiederanlaufzeit ist gefordert, welche wird tatsächlich erreicht – und welche wirtschaftlichen, rechtlichen oder gesellschaftlichen Auswirkungen wachsen während einer Unterbrechung?

Dieser Beitrag entwickelt einen organisationsindividuellen Ansatz, der BCMBCM – Business Continuity Management
Managementprozess zur Vorbereitung auf Unterbrechungen sowie zur Fortführung und Wiederherstellung priorisierter Leistungen., BIABIA – Business Impact Analyse
Analyse der zeitabhängigen Auswirkungen von Unterbrechungen als Grundlage für Prioritäten und Wiederherstellungsanforderungen., Risikomanagement und Performance-Messung in einer gemeinsamen Datenlogik zusammenführt. Er ist ausdrücklich kein universelles Fertigmodell. Organisationen unterscheiden sich in Wertschöpfung, Regulierung, Technologie, Begriffswelt und Steuerungslogik. Wer diese Besonderheiten ignoriert, reduziert gerade den Nutzen, den Integration schaffen soll.

Die Kernidee: Die BIA wird vom periodisch ausgefüllten Fragebogen zu einer fachlich verantworteten Auswertung eines lebenden Beziehungsmodells. Automatisierung liefert Fakten und Inkonsistenzen; die Bewertung der maximal tolerierbaren Unterbrechung bleibt eine Managemententscheidung.

Warum eine isolierte BIA zu kurz greift

Die Business Impact Analyse bewertet die Folgen von Unterbrechungen über die Zeit. Sie begründet Prioritäten und Anforderungen an die Wiederherstellung. ISO/TS 22317:2021 beschreibt als Ergebnisse unter anderem die Priorisierung von Produkten und Services, die Bewertung zeitabhängiger Auswirkungen, die Bestimmung der MTPDMTPD – Maximum Tolerable Period of Disruption
Zeitraum, nach dessen Ablauf die Auswirkungen einer Unterbrechung das tolerierte Maß überschreiten., die Festlegung von RTORTO – Recovery Time Objective
Zielzeit für die Wiederaufnahme einer priorisierten Aktivität oder Ressource nach einer Unterbrechung. und gegebenenfalls RPORPO – Recovery Point Objective
Fachlich tolerierbarer Datenverlust, ausgedrückt als Zeitpunkt in der Vergangenheit, zu dem Daten wiederhergestellt sein müssen. sowie die Identifikation von Ressourcen und Abhängigkeiten.^[1]

In der Praxis werden diese Elemente oft getrennt gepflegt. Das Business nennt einen Prozess und ein RTO. Die IT pflegt technische Services und Komponenten. Der Einkauf kennt Lieferverträge und Service Levels. Human Resources kennt Stellen, Rollen und Qualifikationen. Das Facility Management kennt Standorte, Räume und Versorgungsmedien. Diese Sichten sind jeweils richtig, aber allein unvollständig.

Die Folgen der Trennung sind bekannt:

• Wiederanlaufziele werden an Anwendungen vergeben, ohne den unterstützten Business-Service eindeutig zu kennen.
• Ein „zweiter Lieferant“ gilt als Redundanz, obwohl er dieselbe Unterlieferkette, Region, Logistikroute oder Plattform nutzt.
• Vertretungen stehen in Organigrammen, aber Qualifikation, Berechtigung, Schichtverfügbarkeit oder geografische Konzentration bleiben ungeprüft.
• RTOs werden dokumentiert, ohne sie mit gemessenen tatsächlichen Wiederherstellungszeiten zu vergleichen.
• Produkte mit hohem Wertbeitrag werden nicht konsistent mit den technischen und organisatorischen Abhängigkeiten verknüpft, die ihre Lieferfähigkeit bestimmen.

Das integrierte Datenmodell löst diese Probleme nicht automatisch. Es macht sie jedoch sichtbar, prüfbar und entscheidbar.

Normativer Rahmen: Was gefordert ist – und was der Modellansatz ergänzt

ISO 22301:2019 ist die internationale Anforderungsnorm für ein BCMSBCMS – Business Continuity Management System
Managementsystem, mit dem eine Organisation ihr BCM plant, betreibt, überwacht und fortlaufend verbessert.. Sie verlangt ein systematisches Managementsystem, das geplant, betrieben, überwacht, überprüft und fortlaufend verbessert wird.^[2] ISO 22313:2020 erläutert die Anwendung und betont, dass das Vorgehen von Umfeld und Komplexität der Organisation abhängt.^[3] Genau diese Kontextabhängigkeit ist für die Datenarchitektur zentral.

ISO/TS 22317:2021 konkretisiert den BIA-Prozess, schreibt aber ausdrücklich kein einheitliches Verfahren für alle Organisationen vor. Die Auswahl der Methode soll zu Größe, Sektor, geografischem Umfeld, Zielen, Ressourcen und Einschränkungen passen.^[1] Für Lieferketten erweitert ISO/TS 22318:2021 die Continuity-Perspektive auf Lieferantenbeziehungen und die fortgesetzte Bereitstellung von Produkten, Services und Ressourcen.^[4] ISO/TS 22330:2018 adressiert die Vorbereitung, Unterstützung und Wiederherstellung der Belegschaft.^[5] ISO/TS 22331:2018 behandelt die Bestimmung und Auswahl von Business-Continuity-Strategien.^[6]

Für Deutschland bietet der BSI-Standard 200-4 eine ausführliche Umsetzungssystematik. Er unterscheidet Schadensszenarien – also Auswirkungskategorien einer Prozessunterbrechung – von Ausfallszenarien, beispielsweise dem Ausfall von Gebäude, Personal, Dienstleistern oder IT. Er empfiehlt organisationsindividuell definierte Schadenskategorien und verknüpft BIA, Soll-Ist-Vergleich, Risikoanalyse, Leistungsüberprüfung und kontinuierliche Verbesserung.^[7]

Wichtig ist die Abgrenzung: Die Normen begründen die Notwendigkeit von Analyse, Priorisierung, Ressourcen- und Abhängigkeitsbetrachtung sowie Leistungsbewertung. Das hier vorgeschlagene integrierte Datenmodell ist eine mögliche technische und organisatorische Umsetzung – keine zusätzliche normative Pflicht.

Die Architektur: fünf Schichten statt eines neuen Datensilos

1. Quellsysteme: Fakten dort belassen, wo sie entstehen

Das BCM sollte nicht zum parallelen Stammdatensystem für die gesamte Organisation werden. Führende Daten bleiben möglichst in ihren Ursprungssystemen. Das BCM-Modell übernimmt nur die für Analyse und Entscheidung erforderlichen Attribute, ihre Herkunft und ihren Aktualitätsstand.

Für Produkte ist der Gross Profit häufig aussagekräftiger als reiner Umsatz, weil er den Beitrag zur Deckung der Fixkosten und zum Ergebnis besser annähert. Er darf jedoch nicht zur alleinigen Kritikalitätskennzahl werden: Gesetzliche Aufgaben, Sicherheit, Versorgungspflichten, Kundenvertrauen oder irreversible Folgeschäden können Produkte mit geringem finanziellen Beitrag dennoch hochkritisch machen.

2. Schnittstellen und UIDs: Integration beginnt mit Identität

Der technische Transport kann über APIsAPI – Application Programming Interface
Programmierschnittstelle für den strukturierten Austausch von Daten oder Funktionen zwischen Systemen., Ereignisse, Dateiimporte oder ETLETL – Extract, Transform, Load
Verfahren zum Entnehmen, regelbasierten Umwandeln und Laden von Daten aus Quell- in Zielsysteme.-Prozesse erfolgen. Entscheidend ist nicht die Technologie, sondern die kontrollierte Bedeutung der Daten. Ein Prozess namens „Auftragsabwicklung“ in einer BIA-Tabelle, ein ähnlich benannter Service im ERP und ein Kürzel in der CMDB sind ohne Zuordnung zunächst drei Datensätze – auch wenn Menschen vermuten, dass sie dasselbe meinen.

Jedes relevante Objekt benötigt deshalb eine stabile UIDUID – Unique Identifier
Dauerhafte eindeutige Objektkennung, die Beziehungen auch bei Umbenennungen oder Systemwechseln stabil hält.. Die UID ersetzt nicht die fachliche Bezeichnung; sie stellt sicher, dass Umbenennungen, Reorganisationen oder Sprachvarianten die Beziehung nicht zerstören. Zu jedem Objekt gehören mindestens:

• UID, Objekttyp und fachliche Bezeichnung,
• führendes System und verantwortliche Rolle,
• Gültigkeitszeitraum, letzte Prüfung und Datenstand,
• Status – etwa geplant, aktiv, auslaufend oder stillgelegt,
• Vertraulichkeits- und Zugriffsanforderungen,
• Verknüpfungen zu Dokumenten und Nachweisen.

Die Integrationsschicht muss außerdem Übersetzungen dokumentieren: Welches Feld aus welchem System wird auf welches BCM-Attribut abgebildet? Welche Einheit gilt? Wie werden Konflikte behandelt? Wird ein leerer Wert als „nicht vorhanden“, „nicht erhoben“ oder „nicht anwendbar“ interpretiert? Ohne diese Regeln wirkt Integration präzise, erzeugt aber lediglich schneller uneindeutige Ergebnisse.

3. Semantisches Kernmodell: Objekte plus gerichtete Beziehungen

Das Herzstück ist kein Formular, sondern ein Beziehungsmodell. Eine sinnvolle Mindeststruktur umfasst:

• Produkte und Services: Was liefert die Organisation an Kunden, Bürger, Partner oder interne Empfänger?
• Prozesse und Aktivitäten: Welche wertschöpfenden und unterstützenden Tätigkeiten ermöglichen diese Leistung?
• Ressourcen: Welche Rollen, Informationen, Business Applications und IT-Services, Maschinen beziehungsweise OT-Anlagen, Gebäude und externen Leistungen werden benötigt?
• Abhängigkeiten: In welcher Richtung, Stärke, zeitlichen Reihenfolge und Kapazität wirken die Beziehungen?
• Anforderungen und Nachweise: Welche Zeitziele, Mindestkapazitäten, Verträge, Strategien, Pläne, Übungen und Messergebnisse gehören dazu?

Eine Beziehung sollte mehr aussagen als „A hängt von B ab“. Benötigt werden beispielsweise Abhängigkeitsart, Mindestkapazität, zeitlicher Vorlauf, Substituierbarkeit, gemeinsame Fehlerursache, Gültigkeit und Evidenz. Erst dadurch lässt sich prüfen, ob zwei Lieferanten echte Redundanz bilden oder nur zwei Verträge auf dieselbe verwundbare Quelle verweisen.

Zeitabhängige Impacts: Aus einem Grenzwert wird eine Wirkungskurve

Auswirkungen wachsen selten linear. Ein Ausfall kann zunächst durch Bestand, Puffer oder manuelle Verfahren aufgefangen werden und später sprunghaft eskalieren. In anderen Fällen entsteht der größte Schaden sofort, etwa bei Gefährdung von Menschen, Verletzung harter Meldefristen oder unwiederbringlichem Datenverlust.

Das Datenmodell sollte deshalb nicht nur eine Kritikalitätsklasse speichern, sondern Impact-Werte an organisationsspezifischen Zeithorizonten – zum Beispiel 2 Stunden, 8 Stunden, 24 Stunden, 3 Tage, 7 Tage und 30 Tage. Geeignete Auswirkungsdimensionen sind unter anderem:

• Finanzen und Liquidität,
• Recht, Regulierung und Vertrag,
• Gesundheit, Sicherheit und Umwelt,
• Kunden, Bürger oder Versorgungsempfänger,
• Reputation und strategische Handlungsfähigkeit,
• operative Rückstände und Wiederanlaufaufwand.

Schwellenwerte müssen organisationsspezifisch kalibriert sein. Ein pauschales „Schaden größer als eine Million Euro = sehr hoch“ kann für ein Unternehmen existenzbedrohend und für ein anderes unwesentlich sein. Finanzielle Schwellen lassen sich beispielsweise an Risikotragfähigkeit, Ergebnis, Liquidität oder Gross Profit ausrichten. Der Beitrag Financial Impact in der Business Impact Analysis vertieft diese Herleitung.

MTPD, RTO, RTA und SLA richtig verbinden

Die Zeitgrößen erfüllen unterschiedliche Funktionen:

• MTPDMTPD – Maximum Tolerable Period of Disruption
  Zeitraum, nach dessen Ablauf die Auswirkungen einer Unterbrechung das tolerierte Maß überschreiten.: Zeitpunkt, nach dem die Auswirkungen einer Unterbrechung nicht mehr tolerierbar sind. Diese Grenze wird aus der Impact-Entwicklung und dem akzeptierten Toleranzniveau abgeleitet.
• RTORTO – Recovery Time Objective
  Zielzeit für die Wiederaufnahme einer priorisierten Aktivität oder Ressource nach einer Unterbrechung.: Zielzeit für die Wiederaufnahme einer priorisierten Aktivität. Sie muss innerhalb der MTPD liegen und realistische Sicherheitsmargen berücksichtigen.
• RPORPO – Recovery Point Objective
  Fachlich tolerierbarer Datenverlust, ausgedrückt als Zeitpunkt in der Vergangenheit, zu dem Daten wiederhergestellt sein müssen.: fachlich tolerierbarer Datenverlust, als Zeitpunkt in der Vergangenheit ausgedrückt.
• RTARTA – Recovery Time Actual
  Tatsächlich erreichte Wiederherstellungszeit aus Test, Übung oder realem Ereignis.: tatsächlich erreichte Wiederherstellungszeit aus Test, Übung oder realem Ereignis. Der BSI-Ansatz nutzt sie im Soll-Ist-Vergleich ergänzend zum RTO.^[7]
• SLASLA – Service Level Agreement
  Vertragliche Vereinbarung über messbare Leistungsmerkmale eines Services; nicht automatisch identisch mit dem fachlich benötigten RTO.: vertragliche Leistungszusage. Sie kann mit dem fachlichen RTO übereinstimmen, muss es aber nicht.

Die Schreibweise MTWDMTWD – organisationsspezifisch verwendete Zeitabkürzung
Nicht einheitlich verwendete Abkürzung; ihre lokale Bedeutung muss eindeutig definiert und einem kontrollierten Zeitbegriff zugeordnet werden. wird in einzelnen Organisationen verwendet, ist aber kein einheitlicher Leitbegriff der hier herangezogenen ISO- und BSI-Quellen. Wer MTWD intern nutzt, sollte die lokale Definition dokumentieren und eindeutig auf MTPD oder einen anderen kontrollierten Begriff abbilden. Sonst werden scheinbar identische Zeitwerte verglichen, die fachlich etwas Unterschiedliches ausdrücken.

Der stärkste Prüfpunkt des Modells ist die Konsistenz über Abhängigkeiten: Wenn ein Prozess ein RTO von vier Stunden hat, ein zwingend benötigter externer Service aber vertraglich erst nach acht Stunden wiederhergestellt wird, besteht eine belegbare Fähigkeitslücke. Das Tool darf diese Lücke markieren; über Akzeptanz, Strategie oder Investition entscheidet die verantwortliche Führung.

Lieferanten: Substituierbarkeit statt Checkbox „Redundanz vorhanden“

Lieferantenbeziehungen benötigen mehr als Name, Vertragsnummer und Ampelfarbe. Für jedes bezogene Produkt oder jede Leistung sollten mindestens erfasst werden:

• eindeutig beschriebenes Produkt beziehungsweise Service und unterstützte interne Leistung,
• SLA, zugesagte und nachgewiesene Wiederherstellungszeit, Eskalationsweg und verknüpfte Dokumente,
• Produkt- oder Leistungskomplexität, Qualifizierungs- und Wechselaufwand,
• Substituierbarkeit innerhalb der benötigten Zeit und Kapazität,
• alternative Lieferanten einschließlich ihrer tatsächlichen Unabhängigkeit,
• Standorte, Transportwege, kritische Unterlieferanten und Konzentrationsrisiken,
• Bestand, Reichweite, Wiederbeschaffungszeit und mögliche Produktalternativen.

Forschung zu Liefernetzwerken zeigt, dass Störungen über Input-Output-Beziehungen weitergegeben werden können und dass die Vorteilhaftigkeit von Single- oder Multi-Sourcing vom Risikokontext abhängt.^[8] „Zwei Lieferanten“ ist daher noch keine belastbare Strategie. Entscheidend ist, ob die Alternative bei derselben Störung verfügbar, rechtzeitig qualifiziert, logistisch erreichbar und mengenmäßig ausreichend ist.

HR, IT, OT, Gebäude und Produkte: Kritikalität ist relational

Rollen und Qualifikationen

Bei personellen Ressourcen geht es nicht um die pauschale Aussage „Mitarbeitende erforderlich“, sondern um Rollenfähigkeit: Welche Rolle muss im Mindestbetrieb besetzt sein? Welche Qualifikation, Zertifizierung, Berechtigung, Erfahrung, Sprache oder Sicherheitsfreigabe ist dafür erforderlich? Wie viele Rolleninhaber werden je Schicht oder Standort benötigt und welche gleichwertige Vertretung ist vorgesehen?

Auf der Ressourcenebene der BIA sollte grundsätzlich die benötigte Rolle erfasst werden, nicht der Name einer Person. Rollenprofile können notwendige Fähigkeiten, Qualifikationen, Zertifizierungen, Berechtigungen, Mindestbesetzungen und Vertretungsanforderungen enthalten. Die Zuordnung konkreter Personen verbleibt – soweit betrieblich erforderlich – im geschützten führenden HR-System und wird nicht unnötig in das BCM-/BIA-Modell kopiert. Das folgt dem Grundsatz der Datenminimierung und reduziert die Verarbeitung personenbezogener Daten.

Fachliche Rollenanforderungen der BIA sind von Governance-Verantwortlichkeiten zu unterscheiden. Verantwortlichkeiten wie Process Owner, Freigabe, Pflege oder Eskalation werden separat modelliert und mit den betreffenden Objekten verknüpft. Personenbezogene Gesundheits- oder Privatdaten gehören nicht in das BCM-Modell, sofern dafür keine eindeutige Rechtsgrundlage und belegte Notwendigkeit besteht.

IT und OT getrennt modellieren

IT und OT sollten nicht zu einer gemeinsamen Ressourcenkategorie verschmolzen werden. Die IT-Sicht beginnt bei den vom Business benötigten Business Applications und führt über IT-Services zu Plattformen, Netzen, Identitäten, Datenbanken und Infrastruktur. Die OT-Sicht beginnt bei Maschinen, Produktionsanlagen, Steuerungen und Sensorik und beschreibt die dafür erforderlichen OT-Services, Betriebsparameter und sicheren Zustände.

Die getrennten Sichten werden dort verbunden, wo reale Abhängigkeiten bestehen: Eine Maschine kann beispielsweise eine Business Application, einen IT-Service, ein Netz oder einen Identitätsdienst benötigen; umgekehrt kann eine Anwendung von Daten oder Zuständen der Produktion abhängen. Solche IT-OT-Abhängigkeiten werden als gerichtete Beziehungen modelliert, ohne IT und OT fachlich gleichzusetzen.

Die CMDB ist eine wichtige Quelle für Business Applications, IT-Services und technische Beziehungen, aber nicht automatisch die Wahrheit über Business-Kritikalität. EAM- und OT-nahe Systeme liefern ergänzend Informationen über Maschinen, Anlagenzustände, Wartung und physische Abhängigkeiten. Die BIA begründet, warum und wie schnell die unterstützte Leistung benötigt wird. Beide Sichten müssen über gemeinsame Identitäten und klar zugeordnete Verantwortlichkeiten verbunden werden.

Gebäude und gemeinsame Versorgung

Ein Ausweichstandort ist nur dann wirksam, wenn Zugang, Arbeitsplätze, Energie, Telekommunikation, Spezialanlagen, Sicherheitsanforderungen und Personalverfügbarkeit zusammenpassen. Das Modell sollte deshalb auch gemeinsame Fehlerursachen abbilden: zwei Gebäude am selben Stromknoten, zwei Rechenzentren in derselben Gefahrenzone oder mehrere Anlagen mit demselben nicht verfügbaren Ersatzteil.

Produkte und Gross Profit

Die Priorisierung beginnt sinnvoll bei den Produkten und Services, die den Zweck der Organisation erfüllen. Finanzdaten aus dem ERP können sichtbar machen, welcher Gross Profit in welchem Zeitraum gefährdet ist. Anschließend wird über die Beziehungsstruktur nachvollziehbar, welche Prozesse, Rollen, Business Applications und IT-Services, Maschinen und OT-Services, Gebäude sowie Lieferanten diesen Wertbeitrag ermöglichen. So wird aus einer abstrakten Prozesskritikalität eine wirtschaftlich und operativ erklärbare Entscheidung.

Risikomanagement integrieren: Einzelrisiken und systemische Risiken

BIA und Risikoanalyse beantworten unterschiedliche Fragen. Die BIA fragt: Welche Auswirkungen hat eine Unterbrechung über die Zeit – unabhängig von ihrer Ursache? Die Risikoanalyse fragt: Welche Unsicherheiten oder Ereignisse können Ziele beeinträchtigen, wie wahrscheinlich oder plausibel sind sie, und welche Kontrollen wirken? ISO 31000:2018 betont, dass Risikomanagement auf Wertschaffung und -schutz ausgerichtet, in die Organisation integriert und an ihren Kontext angepasst sein soll.^[9]

Im integrierten Modell werden beide Sichten über dieselben Objekte verbunden:

• Einzelrisiko auf Objektebene: beispielsweise Ausfallwahrscheinlichkeit einer Anlage, Lieferanteninsolvenz oder Verlust einer Schlüsselqualifikation.
• Kontroll- und Fähigkeitsdaten: Wartung, Bestand, Redundanz, Backup, Vertrag, Notverfahren, getestete RTA.
• Systemisches Risiko: Kaskaden, Konzentrationen und gemeinsame Fehlerursachen, die erst aus dem Netzwerk der Abhängigkeiten sichtbar werden.
• Impact-Kontext: zeitabhängige Auswirkungen und MTPD aus der BIA.

Eine dreijährige Forscher-Praxis-Kooperation mit der Stadt Malmö entwickelte eine Methode, um Risiko- und Vulnerabilitätsbewertung mit BIA zu verbinden. Die Autoren heben Synergien hervor, betonen aber zugleich die Notwendigkeit, die Methode an Bedürfnisse und Einschränkungen der Anwender anzupassen.^[10] Das stützt den Grundgedanken dieses Beitrags: Integration ist sinnvoll, Standardisierung ohne Kontext nicht.

Systemische Risiken lassen sich nicht angemessen als Summe isolierter Ampeln beschreiben. Ein Lieferant kann einzeln unkritisch erscheinen, aber als gemeinsame Quelle für zehn kritische Services zum Konzentrationspunkt werden. Umgekehrt kann ein technisch hochkritisches Objekt durch wirksame Alternativen, Puffer und schnelle Umschaltung systemisch gut beherrscht sein.

Vom Analysemodell zur BCM-Strategie

ISO/TS 22317 ordnet die BIA zeitlich vor der Auswahl von Business-Continuity-Strategien ein.^[1] Das Datenmodell schafft dafür einen nachvollziehbaren Übergang:

1. Anforderung: Produkt, Service oder Aktivität benötigt innerhalb einer definierten Zeit ein bestimmtes Mindestleistungsniveau.
2. Ist-Fähigkeit: Ressourcen und Abhängigkeiten liefern derzeit eine gemessene oder belastbar geschätzte Wiederherstellungsfähigkeit.
3. Lücke: RTA, SLA, Kapazität oder Substitutionszeit verfehlen die Anforderung.
4. Optionen: Vermeiden, reduzieren, übertragen, vorsorgen, substituieren, redundant auslegen, manuell überbrücken oder bewusst akzeptieren.
5. Entscheidung: Auswahl anhand von Wirksamkeit, Umsetzbarkeit, Nebenwirkungen, Kosten und verbleibendem Risiko.
6. Nachweis: Plan, Test, Übung oder reales Ereignis aktualisiert die tatsächliche Fähigkeit und schließt den Regelkreis.

Strategien werden damit nicht mehr nur einem Prozessdokument zugeordnet. Sie wirken auf konkrete Knoten und Beziehungen: zusätzlicher Bestand auf eine Lieferabhängigkeit, Cross-Training auf eine Rollenlücke, Failover auf einen IT-Service, mobile Technik auf eine Anlage, Ausweichfläche auf einen Standort oder eine vertraglich gesicherte Kapazität auf einen externen Service.

Governance und Datenqualität: Wer entscheidet was?

Ein integriertes Modell benötigt klare Entscheidungsrechte. Ohne Governance entsteht entweder eine zentrale Datenpflege, die fachlich überfordert ist, oder eine verteilte Pflege ohne gemeinsame Regeln.

Datenqualität sollte nicht abstrakt als „gut“ oder „schlecht“ bezeichnet werden. Sie lässt sich je Attribut und Beziehung anhand konkreter Dimensionen prüfen:

• Vollständigkeit: Sind alle priorisierten Produkte, Aktivitäten und zwingenden Ressourcen erfasst?
• Aktualität: Liegt die letzte fachliche Bestätigung innerhalb des festgelegten Intervalls?
• Konsistenz: Passen RTO, RTA, SLA, Kapazität und abhängige Zeitziele logisch zusammen?
• Eindeutigkeit: Existieren Dubletten oder konkurrierende Identitäten?
• Nachweisbarkeit: Sind Aussagen durch Verträge, Tests, Pläne oder Messdaten belegt?
• Verantwortung: Ist eine aktive Rolle für Entscheidung und Pflege benannt?

Automatisierte Schnittstellen verbessern vor allem Aktualität und Vollständigkeit. Sie ersetzen weder fachliche Definitionen noch Freigaben. Für MTPD, Toleranzschwellen und akzeptierte Restrisiken bleibt menschliches Urteil unverzichtbar.

BCM-Wirksamkeit messen: operativ, ökonomisch und organisational

ISO 22301 verlangt die Überwachung, Messung, Analyse und Bewertung des Managementsystems.^[2] Das integrierte Datenmodell ermöglicht eine mehrstufige Messung, die Aktivität nicht mit Wirkung verwechselt.

1. Operative Wirksamkeit: Erfüllt die Fähigkeit die Anforderung?

• Anteil priorisierter Aktivitäten mit vollständig verknüpften Ressourcen und Ownern,
• Anteil der Tests und Ereignisse mit RTA ≤ RTO,
• maximale und mediane Abweichung zwischen RTA und RTO,
• Anteil kritischer Lieferbeziehungen mit nachgewiesener Substitutionsoption,
• Anteil kritischer Rollen mit qualifizierter, verfügbarer Vertretung,
• Zahl offener Single Points of Failure und Alter der Maßnahmen,
• Datenfrische, Regelverletzungen und ungeklärte Zuordnungen.

Ein hoher Dokumentationsgrad ist dabei nur ein Frühindikator. Entscheidend ist, ob die Organisation in Übungen und Ereignissen das definierte Mindestleistungsniveau innerhalb der Zielzeit erreicht.

2. Ökonomische Wirksamkeit: Welchen erwarteten Verlust verändert BCM?

Die ökonomische Betrachtung verbindet Risiko, zeitabhängige Impacts und Kosten. Für ein relevantes Störungsszenario kann der erwartete Verlust vereinfacht als Eintrittsmaß multipliziert mit dem über die Unterbrechungsdauer integrierten Impact modelliert werden. Die ökonomische Wirkung einer Strategie ist dann die Differenz zwischen erwarteten Verlusten ohne und mit Maßnahme – abzüglich Einführungs- und Betriebskosten.

Vereinfachte Entscheidungslogik:
BCM-Nettonutzen = vermiedener erwarteter Verlust − annualisierte Strategie- und Betriebskosten

Diese Rechnung ist kein exakter Zukunftswert. Sie zwingt jedoch zu transparenten Annahmen: Welche Szenarien werden betrachtet? Welche Wahrscheinlichkeit oder Frequenz ist belastbar? Wie verläuft der Impact über die Zeit? Welche Unsicherheit besteht? Welche Nebenwirkungen erzeugt die Maßnahme? Wo Wahrscheinlichkeitsdaten fehlen, sind Bandbreiten und Sensitivitätsanalysen seriöser als Scheingenauigkeit.

Forschungsarbeiten zu Resilienzstrategien unterscheiden beispielsweise anfänglichen, maximalen und gesamten Performance-Verlust über die Zeit. Diese Größen können unterschiedlich auf dieselbe Strategie reagieren.^[11] Ein zusätzlicher Puffer kann den ersten Einbruch reduzieren, ohne den langfristigen Wiederanlauf zu beschleunigen. Genau deshalb sollten Investitionsentscheidungen nicht auf einem einzigen Kennwert beruhen.

3. Organisationale Performance: Wie verändert sich Leistung nach der Störung?

Organisationale Resilienz kann als beobachteter Performance-Verlauf vor, während und nach einer Belastung untersucht werden. Dafür sind mindestens eine relevante Leistungsgröße, ein Referenzverlauf und ein Zeitfenster erforderlich. Ilseven und Puranam zeigen, dass die Wahl des Gegenfaktums und des Beobachtungsfensters die Messung wesentlich beeinflusst.^[12]

Geeignete Ergebnisgrößen können je nach Organisation sein:

• Tiefe des Leistungseinbruchs,
• Zeit bis zum Mindestleistungsniveau und bis zum Normalniveau,
• kumulierte nicht erbrachte Leistung beziehungsweise „Fläche“ des Performance-Verlusts,
• Qualität, Sicherheit und Verpflichtungserfüllung während des Notbetriebs,
• Rückstand und Nachholaufwand nach Wiederaufnahme,
• Lern- und Anpassungswirkung nach dem Ereignis.

Aktuelle Forschung warnt zugleich vor einer unkritischen Verdichtung organisationaler Resilienz zu einem universellen Score. Ein Scoping Review identifizierte unterschiedliche Messinstrumente und zwei dominante Logiken: kontextsensitive Diagnose von Resilienzpotenzialen und standardisiertes Benchmarking organisationaler Fähigkeiten.^[13] Für das BCM bedeutet das: Ein Dashboard darf verdichten, muss aber die zugrunde liegenden Zeiten, Impacts, Abhängigkeiten und Evidenzen zugänglich halten.

Pragmatische Einführung: klein beginnen, anschlussfähig wachsen

1. Zweck und Scope festlegen: Mit einem Produkt, Service oder einer Wertschöpfungskette beginnen, nicht mit sämtlichen Unternehmensdaten.
2. Begriffe und Entscheidungsebenen klären: Was bedeutet Produkt, Prozess, Aktivität, Service, Ressource, MTPD und RTA in dieser Organisation?
3. Minimalmodell definieren: Nur Objekte, Beziehungen und Attribute aufnehmen, die eine konkrete BCM-Entscheidung unterstützen.
4. Quellen und Owner zuordnen: Für jedes Attribut führendes System, Verantwortliche, Aktualisierungsregel und Qualitätskriterium festlegen.
5. UIDs und Mapping aufbauen: Zunächst für den gewählten Scope; Dubletten und ungeklärte Zuordnungen sichtbar lassen.
6. BIA und Soll-Ist-Vergleich pilotieren: Wirkungskurven, Zeitziele und vorhandene Fähigkeiten miteinander prüfen.
7. Strategien und Maßnahmen verknüpfen: Jede Maßnahme muss auf eine konkrete Lücke oder Risikoexposition zurückführen.
8. Durch Tests und Ereignisse lernen: RTA, Mindestleistung und reale Einschränkungen zurück in das Modell spielen.
9. Iterativ erweitern: Weitere Produkte, Abhängigkeitsebenen und Schnittstellen erst aufnehmen, wenn Nutzen und Verantwortlichkeit geklärt sind.

Ein solcher Pilot darf bewusst unvollständig sein. Unvollständigkeit ist beherrschbar, wenn sie transparent ist. Gefährlicher ist ein umfassend wirkendes Modell, dessen Daten veraltet, widersprüchlich oder nicht verantwortet sind.

Grenzen und typische Fehlannahmen

• „Automatisierte Daten sind objektiv.“ Sie sind nur so belastbar wie Definition, Quelle, Mapping und Aktualität.
• „Je mehr Daten, desto besser.“ Jedes Attribut erzeugt Pflegeaufwand. Ohne Entscheidungszweck wird es Datenballast.
• „Das Tool berechnet die MTPD.“ Es kann Impacts und Schwellen visualisieren; die Toleranzentscheidung bleibt fachlich und managerial.
• „Redundanz ist eine Anzahl.“ Zwei abhängige Alternativen können denselben Ausfallpfad besitzen.
• „RTO ist Wiederherstellungsfähigkeit.“ RTO ist das Ziel, RTA beziehungsweise getestete Fähigkeit ist der Nachweis.
• „Ein Resilienzscore genügt.“ Ein Gesamtscore kann Unterschiede zwischen Vorbereitung, Reaktion, Wiederherstellung und Anpassung verdecken.

Fazit: Das Datenmodell ist Entscheidungsinfrastruktur

Ein organisationsindividuelles integriertes BCM-/BIA-Datenmodell verbindet vorhandene Daten so, dass aus ihnen nachvollziehbare Prioritäten, Fähigkeitslücken und Strategien entstehen. Es führt ERP, EAM, CMDB, HR, IT, OT, Lieferanten, Gebäude, Produkte und Dokumente nicht in einem neuen Monolithen zusammen, sondern schafft einen gemeinsamen semantischen Bezugsrahmen.

Der eigentliche Fortschritt liegt in drei Übergängen:

1. von isolierten Listen zu gerichteten Abhängigkeiten,
2. von Zielwerten zu nachgewiesener tatsächlicher Fähigkeit,
3. von BCM-Aktivität zu messbarer operativer, ökonomischer und organisationaler Wirkung.

Damit wird die BIA nicht abgeschafft und auch nicht vollständig automatisiert. Sie wird besser vorbereitet, konsistenter aktualisiert und enger mit realen Entscheidungen verbunden. Die Technik liefert Transparenz. Verantwortung, Toleranz und Strategie bleiben Aufgaben der Organisation.

Begriffshilfe: Fachbegriffe mit einem Fragezeichen lassen sich mit Maus, Tastatur oder durch Antippen direkt im Lesefluss erklären. Das zentrale NOVELEDGE-Glossar wird unabhängig von diesem Beitrag gepflegt.

Quellen

Die normativen Inhalte werden sinngemäß wiedergegeben; aus kostenpflichtigen Normen wird nicht wörtlich zitiert. Wissenschaftliche Aussagen sind auf die jeweils zugänglichen Abstracts oder Volltexte begrenzt.

1. ISO/TS 22317:2021, Security and resilience — Business continuity management systems — Guidelines for business impact analysis. ISO Online Browsing Platform. Zur ersten Fundstelle im Text.
2. ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements, einschließlich Amendment 1:2024. Normseite bei ISO. Zur ersten Fundstelle im Text.
3. ISO 22313:2020, Security and resilience — Business continuity management systems — Guidance on the use of ISO 22301. Normseite bei ISO. Zur Fundstelle im Text.
4. ISO/TS 22318:2021, Security and resilience — Business continuity management systems — Guidelines for supply chain continuity management. Normseite bei ISO. Zur Fundstelle im Text.
5. ISO/TS 22330:2018, Security and resilience — Business continuity management systems — Guidelines for people aspects of business continuity. Normseite bei ISO. Zur Fundstelle im Text.
6. ISO/TS 22331:2018, Security and resilience — Business continuity management systems — Guidelines for business continuity strategy. Normseite bei ISO. Zur Fundstelle im Text.
7. Bundesamt für Sicherheit in der Informationstechnik (2023), BSI-Standard 200-4: Business Continuity Management. PDF beim BSI. Zur ersten Fundstelle im Text.
8. Birge, J. R.; Capponi, A.; Chen, P.-C. (2023), „Disruption and Rerouting in Supply Chain Networks“, Operations Research, 71(2), 750–767. DOI: 10.1287/opre.2022.2409. Zur Fundstelle im Text.
9. ISO 31000:2018, Risk management — Guidelines. Normseite bei ISO. Zur Fundstelle im Text.
10. Hassel, H.; Cedergren, A. (2021), „Integrating risk assessment and business impact assessment in the public crisis management sector“, International Journal of Disaster Risk Reduction, 56, 102136. DOI: 10.1016/j.ijdrr.2021.102136. Zur Fundstelle im Text.
11. Baghersad, M.; Zobel, C. W. (2022), „Organizational Resilience to Disruption Risks: Developing Metrics and Testing Effectiveness of Operational Strategies“, Risk Analysis, 42(3), 561–579. DOI: 10.1111/risa.13769. Zur Fundstelle im Text.
12. Ilseven, E.; Puranam, P. (2021), „Measuring organizational resilience as a performance outcome“, Journal of Organization Design, 10, 127–137. DOI: 10.1007/s41469-021-00107-1. Zur Fundstelle im Text.
13. Lo, H.-H.; Chuang, S. (2026), „A scoping review of organizational resilience measurement – instruments, indicators, and implications“, Safety Science, 196, 107114. DOI: 10.1016/j.ssci.2026.107114. Zur Fundstelle im Text.