(Gastbeitrag von Dr. Christian Zänker)

Die Umsetzung des Business Continuity Managements leidet oftmals an mangelnder Effizienz, weil seine Schnittstellen unzureichend genutzt und nicht eindeutig definiert sind.  Ungeklärte Verantwortlichkeiten und Kompetenzen zwischen den Steuerungsfunktionen im Unternehmen führen zu Reibungsverlusten und beeinträchtigen die Qualität der erhobenen Daten und der auf ihrer Basis ermittelten Anforderungen.

Für BCM stellt sich zudem das Problem, dass es in vielen Organisationen hierarchisch zu tief aufgehängt ist. Andererseits verleitet der Bedarf an unterschiedlichsten Informationsinputs dazu, in andere Kompetenzbereiche „hineinregieren“ zu wollen, ohne das notwendige standing zu haben.

Es erscheint daher zielführend, BCM auf seine Kernkompetenzen zu konzentrieren und es organisch (im Sinne einer betriebseigenen Ablauforganisation) in bestehende Strukturen einzupassen. Als Querschnittsfunktion kann BCM für die betroffenen Organisationseinheiten Mehrwert generieren und so die Anerkennung erlangen, die es zur Erfüllung seiner Aufgaben benötigt. Ich werde dies am Beispiel des Zusammenspiels von Risikoanalyse, Business Impact Analyse und Service Level Agreement erläutern.

Konkurrierende Ansätze führen zu abnehmender Akzeptanz

Jedem BCM Manager dürfte die Klage der betroffenen Linienmanager bekannt sein, wenn er daran geht, seine Datenbasis zu erheben: „Nun kommt Ihr schon wieder und wir sollen Euch zum dritten oder vierten mal die selben Fragen beantworten, die uns bereits Eure Kollegen zum wiederholten Mal gestellt haben.“

Und sie haben Recht! Neben BCM werden Daten zu Prozessen und Ressourcen von opRisk, IT-Risk, Orga, Prozessmanagement, Compliance, Information Security, IT Service und SLA Management benötigt und diese gehen dazu auf ihre jeweiligen Ansprechpartner zu: den BCC, den DORM, den Prozess Owner, den System Owner und den Application Owner etc.

Dies führt zu sinkender Akzeptanz bei den betroffenen Partnern. Nicht vorhandene Evidenz, Inkonsistenz in der Datenaufbereitung und fehlende Transparenz der Datenverarbeitung führen dazu, dass an verschiedenen Stellen unterschiedliche Informationen „gepflegt“ werden und jeder nur die eigenen Daten als valide erachtet.

Bestimmung des Schadensausmaßes

Nehmen wir die Risikoanalyse als Beispiel. Das Risiko Management verfügt heute über ein ebenso fundiertes wie differenziertes Instrumentarium zur Erhebung und Bewertung der unterschiedlichsten Risiken. Sie greifen auf Risikokataloge und Schadensdatenbestände zurück, die mit Hilfe mathematischer oder statistischer Berechnungsmethoden ausgewertet werden. opRisk geht längst über die alt bekannte Faustformel: Risiko = Eintrittswahrscheinlichkeit x Schadensausmaß hinaus.

Wenn wir heute von einem Gebäudeausfallszenarium sprechen, ergibt sich das jeweilige Schadensausmaß selbstredend aus der Wertigkeit der in diesem Gebäude erbrachten Prozesse. Gleiches gilt für die anderen drei klassischen Ausfallszenarien Personal-, IT- und Schnittstellenausfall. Hierzu greift man unter anderem auf das Controlling und auf betriebswirtschaftliche Berechnungen zurück. Welchen Anteil hat jeder der betroffenen Geschäftsprozesse am Betriebsergebnis z.B. der letzten drei Jahre? Oder wie hoch war der jeweilige Anteil am Gewinn vor Zinsen, Steuern, Abschreibungen? Wie sind die Risiken aus Compliance-Verletzungen, Reputationsschäden oder Verlust der strategischen Steuerungsfähigkeit des Unternehmens zu bewerten?

Diese Daten werden für das BCM benötigt und üblicherweise im Rahmen der BIA abgefragt. Sie werden allerdings auch jährlich im Rahmen der Risk Assessments durch das opRisk für alle Prozesse und nicht nur für die Prozesse im BCM Fokus erhoben. Wer bedenkt, mit welch groben Rastern BCM in der Regel die Frage der Schadensbewertung angeht: Finanzieller Schaden: > 500T, > 1 Mio., > 5 Mio. etc., oder Schadenskategorien bewertet: unbedeutend, störend, kritisch, katastrophal, sollte schnell erkennen, wo die Kompetenz für die Erhebung und Aufbereitung dieser Daten liegen sollte.

Es mindert nicht die Bedeutung der Business Impact Analyse, wenn der Business Impact an anderer Stelle erhoben wird!

Für Prozesse, deren Schadensausfallwirkung so schwerwiegend ist, dass nach allen Präventionsmaßnahmen das Restrisiko immer noch als untragbar erscheint, wird im opRisk als zusätzliche Maßnahme BCM definiert, um bei eintretendem Ereignis, die Schadensauswirkung zu minimieren. Diese Prozesse werden an das BCM weitergegeben und dort der Business Impact Analyse unterzogen. In der BIA wird die Schadensentwicklung im zeitlichen Verlauf bewertet und festgestellt, ab welcher vordefinierter Zeitperiode das missionskritische Schadensausmaß erreicht wird, und das Wiederanlaufziel sowie die hierfür benötigten Ressourcen festgesetzt.

Um einen beliebten Einwand an dieser Stelle aufzugreifen: es stimmt, irgendwann wird jeder Prozess kritisch, sonst könnte man ihn per se einstellen. Aber BCM als Notfallplanung bezieht sich auf die Prozesse, die in einer festgesetzten Zeitspanne wiederanlaufen müssen, z.B. 4h – 8h – 24h – 72h – 120h. Dies ist zu planen, zu implementieren und zu testen, damit diese kritischen Prozesse in der geforderten Wiederanlaufzeit aufgenommen werden können. Für alle nicht kritischen Prozesse, oder solche, die erst nach z.B. zwei Wochen kritisch werden, werden die Wiederanlaufmaßnahmen im Notfall durch das zentrale Krisenmanagement eingeleitet. Man kann sie ja nicht auf unabsehbare Zeit ruhen lassen. Hierfür bedarf es aber keiner kostenintensiven Notfallvorsorgemaßnahmen, sondern allenfalls der Dokumentation der Anforderungen im Normalprozess. Dies ist die Schnittstelle zur Orga respektive zum Prozessmanagement.

Auch die Prozesse, die im Risk Assessment nicht als kritisch eingestuft werden, gehen bei diesem Ansatz nicht verloren, sondern werden priorisiert und wenn sie Abhängigkeiten zu kritischen Prozessen aufweisen, wie bisher durch die BIA erfasst und als Zuliefer- oder Weiterverarbeitsungsprozesse ins BCM integriert.

Kritische Ressourcen und Service Level

In den meisten Organisationen werden die Anforderungen an die IT, intern wie extern, über Service Level Agreements (SLA) zwischen der Produktion und der IT als zentralem Service Provider vereinbart. Diese Anforderungen beziehen sich auf die Verfügbarkeit im Normalprozess (Availability). Sie ist die wichtigste Schnittstelle des BCM und sollte deswegen im organisationseigenen Prozessablauf mit höchster Priorität definiert werden.

Auch hier möchte ich einen gängigen Einwand aufgreifen: ja, BCM behandelt den Notbetrieb und Availability den Normalbetrieb. Durch die unterschiedlichen Service Level wird für jede einzelne IT-Anwendung festgelegt, wie schnell die Störung im Normalprozess behoben werden muss, damit es erst gar nicht zum Notfall in der Prozessabwicklung kommt. Auch hier liefert die BIA den Anforderungskatalog für alle IT-Anwendungen, die zur Durchführung der kritischen Prozesse benötigt werden. Dieser wird nicht erst festgelegt, wenn der jeweilige IT Service Manager den verantwortlichen System bzw. Application Owner im Geschäftsbereich besucht und fragt, welchen Service Level hätten Sie denn gerne? Aber leider laufen in der Praxis die Informations- und Anforderungsstränge nur allzu oft unverbunden nebeneinander her.

Durch die definierte Schnittstelle von BIA und SLA oder besser Service Level Request (SLR), Prozessanforderungen, die erst einmal gestellt, verhandelt, vereinbart (SLA) und bezahlt werden müssen, muss gewährleistet werden, dass auch das Ausfallszenarium IT-Ausfall in das SLA einfließt. Wie gesagt, ist in den gängigen SLA nur die Availability geregelt. Das Disaster Recovery, der IT Notfall oder auch K-Fall, bleibt zumeist ausgespart. Weil sich bei einem IT-Notfall keine Wiederanlaufzeit garantieren lässt, sollte durch BCM in den SLA nicht nur das Wiederanlaufziel, Recovery Time Objective (sic!), Aufnahme finden, sondern auch beinhaltet sein, dass der RTO als Priorisierung in der Wiederanlaufreihenfolge für den K-Fall Rechnung getragen wird.

Der Workflow von der BIA über die SLR zu den SLA wird wiederum von BCM mit der BIA Gap-Analyse geschlossen. Diese vergleicht unter anderem die in der BIA erhobenen Anforderungen an die IT mit den in den SLA definierten IT-Services und überprüft, ob diese abgedeckt sind, oder ob sich hierbei Lücken, Gaps ergeben, die als objektive Risiken an die Geschäftsbereichsleitung und an das opRisk gemeldet werden. Hier schießt sich logisch der Kreis.

Ablaufplanung eines BCM Workflow

Diese drei unabhängig von einander ablaufenden Prozesse, die von unterschiedlichen Steuerungsfunktionen verantwortet werden, gilt es in eine zeitliche Abfolge zu bringen, damit der oben skizzierte logische Zusammenhang sich in einer definierten Ablaufplanung widerspiegelt.

Hierbei ist das wichtigste Datum der Abschluss der SLA, der zumeist auf den Sommer festgesetzt wird, damit die vereinbarten Services umgesetzt werden und ab dem Folgejahr greifen können. Wenn nun die SLA z.B. zum 30.06. jedes Jahres geschlossen sein müssen, werden die SLR in der Regel drei bis vier Monate vorab, also zum 1. März abgefragt. Damit steht auch der Termin, zu dem die BIA bzw. das BIA update abgeschlossen sein muss: der 28. Februar.

Üblicherweise werden die Risk Assessments im Frühjahr oder Herbst durchgeführt. In dem hier ausgeführten Beispiel, müsste also mit opRisk eine Vereinbarung herbeigeführt werden, dass die Ergebnisse der Risikoanalyse zum Jahresende an BCM geliefert werden, d.h. dass das Risk Assessment im Herbst einsetzen müsste.

Ein Weniger kann ein Mehr bedeuten

Wenn man von Seiten BCM anerkennen würde, dass die Schadensauswirkung der einzelnen Prozesse vom Risikomanagement im Rahmen der Risk Assessments erhoben wird,  und vom opRisk festgesetzt wird, für welche Prozesse BCM eingeführt werden muss, um das Prozessausfallrisiko zu begrenzen, würde dies zu einer wünschenswerten Verbesserung der Prozessabläufe und zur Vermeidung redundanter Datenerhebungen führen.

Das Risiko Management erhebt die Schadenswirkung und übergibt die Prozesse an das BCM zur Business Impact Analyse. opRisk hat nicht die Kompetenz zu beurteilen, ob und wie für diese Prozesse eine Notfallplanung umgesetzt werden muss oder ob es ausreichend sein kann, den Wiederanlauf im Rahmen des Krisenmanagements anzustoßen. Die Notfallplanung und die Bereitstellung der Ressourcen für den Notfall zu steuern, ist die Kompetenz des BCM.

Die Bewertung der Umsetzung erfolgt im Rahmen der BIA Gap-Analyse, die ich nicht auf die IT begrenzt sehen will. Die Zur Verfügung Stellung von IT wie non-IT Ressourcen muss über SLA geregelt werden. Ein einleuchtendes Beispiel ist die Bereitstellung von Notfallarbeitsplätzen extern im Rahmen einer Disaster Recovery Site oder intern in Form eines Arbeitsplatz-Sharing.

Die Umsetzung der Anforderungen wird nach Abschluss der BIA Gap-Analyse vom Sommer als effektive Maßnahme zur Risikominderung noch vor Durchführung des nächsten Risk Assessments im Herbst an das opRisk reportet, oder aber als bestehendes Gap, als objektiviertes Risiko, eskaliert.

Die Notfallanforderungen der Geschäftsbereiche zu erheben und ihre Umsetzung in den SLA zu prüfen, ist Kernkompetenz des BCM. Sie wird umso effektiver und effizienter wahrgenommen, je mehr man sich der Produktivität der eigenen Schnittstellen bewusst wird und versucht, BCM nicht aus dem Baukasten zu modellieren, sondern in die Betriebsabläufe zu integrieren. Hierdurch kann BCM nicht nur die Entwicklung von Notfallfähigkeit in der Linienorganisation steuern, sondern zeitgleich dem Risikomanagement und dem IT Service Management die Informationen zur Verfügung stellen, die diese aus sich heraus nicht generieren können.

Dies ist ein Beispiel, wie BCM durch Selbstbeschränkung zur Effizienzsteigerung beitragen und Anerkennung für die Erbringung seiner Leistungen erringen kann.

bcm-news dankt Herrn Dr. Zänker ganz herzlich für diesen Gastbeitrag. Sie haben auch eine Idee oder bereits einen Text für einen Gastbeitrag in den bcm-news? Nehmen Sie einfach Kontakt auf: admin@bcm-news.de