Sackgasse BIA? – was für eine Frage, wo doch gerade dieser schöne neue ISO-Standard für die BIA veröffentlicht wurde (ISO/TS 22317:2015). Um es gleich vorwegzuschicken, ich gehöre nicht zu der Fraktion, die die BIA als Zeitverschwendung betrachten. Im Gegenteil, ich halte die Business Impact Analyse für die wesentliche Phase im BCM-Lebenszyklus, um die nachfolgenden Phasen Taktik / Strategie, Notfallplanung sowie Tests und Übungen effektiv und effizient durchführen zu können. Ob eine BIA zum Katalysator oder Bremsklotz im BCM-Lebenszyklus wird, entscheidet der Anwender und nicht die BIA selbst. Weiterlesen…

Eigentlich könnte man meinen, zur Business Impact Analyse ist alles gesagt und geschrieben. Es gilt also nur noch nach Best Practices mit bewährten Templates an die Arbeit zu gehen. Leider zeigt es sich in vielen Projekten immer wieder, dass es gar nicht so einfach ist, den Beginn des roten Fadens für die BIA zu finden. Ja natürlich, für Geschäftsprozesse soll die BIA gemacht werden. So weit so gut. Was aber, wenn die Geschäftsprozesse gar nicht beschrieben sind oder in einer viel zu hohen Detaillierungsebene. Soll die BIA für alle Prozesse gemacht werden, und wenn nicht, welche Geschäftsprozesse können erst mal – oder vielleicht ganz – außen vor gelassen werden? Die ideale Welt für das BCM gibt es nun mal fast nur in der Theorie und den BCM-Standards. Der größte Fehler ist jetzt jedoch, mit großem Tatendrang einfach einmal mit irgendwelchen Prozessen anzufangen. Leider verbaut man sich mit diesem vermeintlich pragmatischen und ungestümen Vorgehen so manche tolle Chance, die sich aus der BIA ergibt. So zum Beispiel die Abhängigkeitsanalyse zwischen den Prozessen. Sind im Unternehmen keine durchgehenden Wertschöpfungsketten beschrieben, eröffnet gerade die BIA die Chance, sich diesem Ziel ein großes Stück zu nähern. Voraussetzung hierfür ist jedoch,  dass in der BIA für die Geschäftsprozesse Vorgänger- und unterstützende Geschäftsprozesse angegeben werden können. Und hierzu benötigt es eine Liste der Prozesse. Die Prozesse in der Prozessliste sollten sich auf einer vergleichbaren Detaillierungsebene befinden und so benannt und beschrieben sein, dass ein einheitliches Verständnis über die Prozessinhalte und Prozessgrenzen besteht. Um jetzt nicht in ein aufwändiges Prozessmanagement abzugleiten, verbunden vielleicht sogar noch mit einer Toolauswahl für das Prozessmanagement, ist Pragmatismus angesagt. Das Vorgehen kann zum Beispiel darin bestehen, von den potentiell kritischen Fachabteilungen sich die maximal fünf bis zehn wichtigsten Aufgaben nennen zu lassen. Eine kleine Beschreibung der Aufgaben nach dem EVA-Prinzip (Eingabe – Verarbeitung – Ausgabe) definiert die Aufgabeninhalte und Schnittstellen. Diese Aufgaben “mutieren” dann in der BIA zu Prozessketten, indem die jeweiligen Vorgänger- und Unterstützungsaufgaben je Aufgabe abgefragt werden. Und schon ist man den Wertschöpfungsketten ein gutes Stück näher gekommen. Die zusätzliche Arbeit für die Erstellung dieser Aufgabenlisten lohnt sich in jedem Fall. Der Anfang vom Faden für die BIA ist damit gefunden und an diesem lässt es sich jetzt gut weiterhangeln, bis aus dem Faden ein Pullover gestrickt ist. Grobmaschig, aber erst einmal wärmend. Um die Details kann sich jetzt das Prozessmanagement kümmern und im nächsten BIA-Aktualisierungslauf werden die Maschen enger geknüpft. Rom ist auch nicht an einem Tag erschaffen worden – aber es gab ein klares Schnittmuster für den Aufbau der Stadt und der Verkehrswege nach dem vorgegangen wurde.

Die Durchführung der Business Impact Analyse ist die aufwändigste Phase bei der Implementierung eines BCM. Die Fachbereiche müssen eingebunden werden, viele Daten erhoben und dokumentiert werden, Abhängigkeiten analysiert und Entscheidungen getroffen werden. Obwohl dies umfangreiche Aktivitäten sind, sollte eine BIA innerhalb eines überschaubaren und möglichst kurzen Zeitraums abgeschlossen sein. Denn sonst holen die laufenden Änderungen in der Organisation die erreichten Ergebnisse wieder ein. Mit dem Ergebnis, dass das Implementierungsprojekt fortwährend Schleifen in der BIA-Phase dreht und nicht zu den nächsten entscheidenden Phasen Strategie, Planung und Tests kommt. Ein häufiger Grund für endlose BIA-Projekte ist “Verzetteln”, mangelnder Pragmatismus und die leichtfertige Übernahme von Aufgaben.

Fünf häufige Showstopper sind

1. Der Versuch Prozessmanagement zu betreiben:
   es liegen für die BIA keine dokumentierten Prozesse vor oder das neue Prozessmodell ist seit Jahren in Arbeit. In einem BIA-Projekt wird es nicht gelingen “by the way” Prozessmodellierung mit zu betreiben. Insbesondere, wenn andere Projekte sich daren bereits die Zähne ausgebissen haben. Für die BIA reicht die Definition der Hauptaufgaben je Organisationseinheit aus. Maximal 10 bis 15 je Bereich. Die Abhängigkeiten erheben wir dann im Rahmen der BIA. Wenn das Prozessmodell des Unternehmens dann einmal steht, sollten die beiden Modelle konsolidiert werden.
2. die Versuchung IT-Architekturmanagement zu betreiben:
   In der BIA benötigen wir die IT-Anwendungsebene, um den Link zwischen den Prozessen / Hauptaufgaben und der IT abzubilden. Schwierig genug eine abgestimmte IT-Anwendungsliste (IT-Services) zu generieren, mit der die Fachabteilungen und die IT leben können. In der BIA geht die Fachabteilung vereinfachend davon aus, dass die IT-Anwendungen / IT-Services voll funktionsfähig zur Verfügung gestellt werden. Das heisst mit den aktuellen und korrekten Daten, den Vor- und Schnittstellenprogrammen, den Batch-Programmen und der IT-Infrastruktur bestehend aus Servern und Netzwerk. Im Rahmen des ITSCM werden die Abhängigkeiten von der Ebene der IT-Anwendungen auf die darunter liegenden Schichten der IT-Architektur abgebildet und Kritikalitäten vererbt.
3. die Versuchung Risikomanagement zu betreiben:
   Das Risikomanagement ist in vielen Unternehmen bereits etabliert. Im BCM werfen wir mit unserer Brille einen Blick auf die Risiken des Unternehmens, die zu einer Geschäftsunterbrechung führen können. Das Ziel des BCM ist es, Notfallpläne für das Eintreten dieser Risiken zu entwickeln. Die quantitative Sicht auf die Risiken zur Ermittlung der Eigenkapitalvorsorge liegt weiterhin im klassischen Risikomanagement. BCM kann hier unterstützen, wird das Risikomanagement aber nicht ersetzen.
4. Methodenverliebtheit und fehlender Pragmatismus:
   Es lassen sich viele tolle und komplexe Methoden zur Impact-Analyse und Festlegung der kritischen Prozesse erfinden. Monte-Carlo-Simulationen und komplizierte Scoring-Verfahren lassen eine BIA schön kompliziert aussehen – und täuschen darüber hinweg, dass es am Ende des Tages doch nur Experteneinschätzungen sind, da uns Erfahrungswerte fehlen. Komplizierte Methoden machen die bIA für die Fachbereiche aufwändiger und unverständlicher. Dem Management die Ergebnisse und die Herleitung in kurzer Zeit zu vermitteln ist beinahe unmöglich. Keep it as simple as possible!
5. Gutmütigkeit und fehlende Härte:
   “das kann das BCM ja gerade mal mitmachen”, ist ein häufiger und sehr gefährlicher Satz. Eine saubere Abgrenzung zu den angrenzenden Bereichen ist elementar wichtig. Dies benötigt zuweilen Härte und führt zu Konflikten. Aber ansonsten machen wir im BCM einfach mal (IT-) Risikomanagement, Safety & Security, Umzugs- und Facility Management und viele weitere Themen einfach mal mit – ohne aber das Personal, Budget und die Zeit hierfür zu bekommen. Uns unser eigentliches Thema bleibt auf der Strecke liegen. Gehen Sie auf die anderen Bereiche zu, bleiben Sie aber hart und kompromisslos, wenn es an die Übernahme deren Aufgaben geht.

Welche Showstopper haben Sie in Ihren Projekten erlebt? Ich freue mich auf Ihre Kommentare!