BCM aus der Praxis

Was ich als IT-Leiter über Business Continuity Management gelernt habe

Vom Auftraggeber zum Moderator

Business-Continuity-Workshops beginnen häufig gleich.

Die Teilnehmer kommen aus unterschiedlichen Bereichen des Unternehmens, begrüßen sich, holen sich einen Kaffee und werfen einen Blick auf die Agenda. Manche sind neugierig. Andere haben bereits ähnliche Workshops erlebt und fragen sich, was diesmal anders sein soll. Hin und wieder hört man Sätze wie: „Das wird doch wieder so ein Dokumentationsthema.“ Oder: „Unsere Prozesse kennen wir doch längst.“

Nach ein bis zwei Stunden verändert sich das Gespräch häufig. Jemand aus dem Fachbereich beschreibt seinen Prozess, kommt an einer Stelle ins Stocken und sagt dann sinngemäß: „Moment mal. Das läuft doch alles über das ERP.“ Ab diesem Punkt hört das Gespräch auf, sich um einzelne Abteilungen zu drehen. Einkauf, Produktion und IT erkennen, wie viele ihrer eigenen Prozesse an genau diesem einen System hängen. Aus getrennten Beiträgen wird eine gemeinsame Diskussion.

Diese Entwicklung hat mich in den vergangenen Jahren immer wieder fasziniert. Kein Workshop gleicht dem anderen. Trotzdem gibt es Muster, die sich immer wieder wiederholen. Der Weg, den viele Workshops nehmen, ähnelt sich dabei oft erstaunlich.

Als ich meine ersten Berührungspunkte mit Business Continuity Management hatte, habe ich diese Entwicklung kaum wahrgenommen. Ich saß als Vertreter der IT mit am Tisch, beantwortete Fragen zu Systemen, Infrastruktur und technischen Abhängigkeiten und nahm die Ergebnisse des Workshops mit in meinen Verantwortungsbereich. Für mich stand vor allem das Ziel im Vordergrund: Am Ende sollte eine belastbare Grundlage entstehen, aus der sich konkrete Maßnahmen ableiten ließen.

Einige Jahre später änderte sich meine Rolle grundlegend. Ich moderierte die Workshops selbst und stellte viele der Fragen, die ich früher beantwortet hatte. Damit veränderte sich auch mein Blick auf Business Continuity Management. Zum ersten Mal interessierte mich nicht nur das Ergebnis, sondern der Weg dorthin.

Die meisten Unternehmen verfügen bereits über erstaunlich viel Wissen. Die Verantwortlichen kennen ihre Prozesse, wissen um kritische Lieferanten, benennen technische Risiken und können sehr genau erklären, welche Folgen ein längerer Ausfall hätte. Dieses Wissen ist vorhanden – allerdings verteilt auf viele Menschen, Abteilungen und Erfahrungen. Jeder kennt einen Teil des Gesamtbildes. Kaum jemand kennt das gesamte Bild. Der ERP-Moment aus dem Workshop ist dafür typisch: Jede Abteilung kannte ihren eigenen Ausschnitt. Erst im Gespräch wurde daraus ein gemeinsames Bild.

Eine zweite Beobachtung kam mit der Zeit hinzu. Obwohl sich Unternehmen, Branchen und Organisationsstrukturen deutlich unterschieden, griffen wir in den Workshops immer wieder auf dieselben Hilfsmittel zurück. Whiteboards wurden fotografiert, Tabellen erweitert, Moderationskarten sortiert und Prozessübersichten mehrfach überarbeitet. Vieles funktionierte, manches war improvisiert und erstaunlich vieles entstand immer wieder neu.

Irgendwann stellte ich mir deshalb eine einfache Frage.

Wenn sich die Gespräche und ihre Anforderungen so oft ähneln, warum beginnen wir jedes Mal wieder bei null?

Damals ahnte ich nicht, dass aus dieser einfachen Beobachtung einmal ein eigenes Projekt entstehen würde.

Bis es so weit war, vergingen allerdings noch etliche Workshops – und die Frage, die mich zuerst beschäftigte, war eine andere: warum der Einstieg in dieses Thema so vielen Unternehmen schwerfällt.

Warum der erste Schritt der schwerste ist

In den Gesprächen vor einem Workshop höre ich häufig ähnliche Sätze.

„Das Thema steht schon länger auf unserer Liste.“

„Eigentlich wollten wir das schon im letzten Jahr angehen.“

„Uns fehlt nur noch die Zeit.“

Selten sagt jemand, dass Business Continuity Management unwichtig sei. Im Gegenteil. Die meisten Unternehmen wissen sehr genau, warum sie sich mit Ausfällen, kritischen Prozessen und Notbetrieb beschäftigen sollten. Trotzdem vergeht zwischen dieser Erkenntnis und dem ersten Workshop oft erstaunlich viel Zeit.

Ich habe mich lange gefragt, woran das liegt.

An fehlendem Interesse liegt es nach meiner Erfahrung nur selten. Die Gründe sind meist deutlich pragmatischer. Im Tagesgeschäft konkurriert BCM mit Projekten, deren Nutzen unmittelbar sichtbar ist. Ein neues ERP-Modul, eine Cloud-Migration oder der Austausch einer Infrastruktur versprechen konkrete Ergebnisse. Business Continuity Management dagegen beschäftigt sich mit Ereignissen, von denen alle hoffen, dass sie niemals eintreten. Es ist verständlich, dass andere Themen zunächst dringender erscheinen.

Hinzu kommt ein zweiter Eindruck, den ich in vielen Gesprächen erlebt habe. BCM wirkt größer, als es tatsächlich ist. Begriffe wie Business Impact Analyse, Recovery Time Objective oder Notbetriebsplanung vermitteln schnell das Gefühl, dass zunächst eine umfangreiche Methodik verstanden werden muss, bevor überhaupt begonnen werden kann. Manche Unternehmen suchen deshalb zuerst nach der passenden Software. Andere beschäftigen sich intensiv mit Normen oder Vorlagen. Wieder andere verschieben das Thema, weil der Einstieg komplizierter erscheint, als er eigentlich ist.

Diese Wahrnehmung verändert sich häufig schon im ersten Workshop.

Sobald die Beteiligten beginnen, über ihre tägliche Arbeit zu sprechen, treten die Fachbegriffe in den Hintergrund. Dann geht es nicht mehr um Standards oder Definitionen. Es geht um Fragen wie: Welche Aufgaben müssen morgen unbedingt funktionieren? Was würde passieren, wenn ein Lieferant mehrere Tage ausfällt? Welche Arbeit könnten wir vorübergehend auch ohne IT erledigen? Wer könnte einen Kollegen vertreten, wenn spezielles Wissen kurzfristig fehlt?

Fast alle diese Fragen können die Teilnehmer beantworten. Nicht vollständig, nicht immer sofort – aber deutlich besser, als sie selbst zunächst vermuten.

Besonders deutlich wurde das in einem Workshop, in dem alle Prozesse gemeinsam bewertet wurden, statt jeden Bereich für sich entscheiden zu lassen, was bei ihm kritisch ist. Ein Fachbereich stufte den Ausfall seines Ticketsystems als hoch kritisch ein. Ein Teilnehmer aus einem anderen Bereich fragte nur: Ist das wirklich vergleichbar mit einem ausfallenden Zahlungsverkehr? Die Antwort war Nein. Für sich genommen hätte jeder Bereich seine eigene Einschätzung für richtig gehalten. Erst im Vergleich zeigte sich, was tatsächlich kritisch war – und was nur so gewirkt hatte, weil niemand es neben etwas anderes gestellt hatte.

Solche Situationen haben meinen Blick auf den Einstieg in BCM verändert. Die größte Hürde besteht aus meiner Sicht nicht darin, Methoden zu vermitteln oder Werkzeuge bereitzustellen. Schwieriger ist es, den ersten gemeinsamen Termin zu organisieren und den Raum für genau diese Vergleiche zu schaffen. Ist dieser Schritt erst einmal gemacht, entwickelt sich vieles überraschend schnell.

Rückblickend hätte ich mir diesen unkomplizierten Einstieg selbst gewünscht, als ich noch auf der anderen Seite des Tisches saß. Vielleicht wäre mir damals schneller klar geworden, dass Business Continuity Management weniger mit Formularen beginnt als mit den richtigen Fragen – und mit der Gelegenheit, sie im selben Raum zu stellen wie alle anderen.

Was mich dabei am meisten überrascht: Kein Bereich hatte falsch eingeschätzt. Jede Bewertung war für sich genommen nachvollziehbar. Erst als alle Einschätzungen nebeneinander lagen, veränderte sich das Bild.

Solche Vergleiche veränderten nicht nur, wie ein Prozess bewertet wurde. Sie veränderten auch, wie ich über den Notbetrieb selbst nachdachte – ein Thema, das lange einfacher wirkte, als es ist.

Der Notbetrieb ist auch nur ein Prozess

„Dann arbeiten wir eben mit Handlieferscheinen.“

Diesen Satz habe ich in Workshops schon häufig gehört.

Auf den ersten Blick klingt er beruhigend. Es gibt offensichtlich einen Plan für den Fall, dass das ERP-System nicht zur Verfügung steht. Der Betrieb kann weiterlaufen, wenn auch eingeschränkt. Dafür ist ein Notbetrieb schließlich gedacht.

In diesem Moment wirkt die Lösung vollständig. Erst die folgenden Fragen zeigen, wie viele Entscheidungen hinter diesem einen Satz stecken.

Mit den nächsten Fragen verändert sich die Stimmung häufig.

Wo liegen die Handlieferscheine?

Reichen sie für mehrere Tage?

Kann jeder Mitarbeiter sie ausfüllen oder nur diejenigen, die damit bereits Erfahrung haben?

Wer sammelt die ausgefüllten Formulare ein?

Und wie gelangen die Informationen später wieder vollständig in das ERP-System?

Die Antworten fallen oft sehr unterschiedlich aus. Manche Unternehmen haben diese Abläufe bereits detailliert beschrieben und regelmäßig überprüft. In anderen Fällen zeigt sich, dass zwar Einigkeit über den grundsätzlichen Ablauf besteht, viele praktische Fragen aber noch nie gemeinsam betrachtet wurden. Nicht selten ist bekannt, dass mit Handlieferscheinen gearbeitet werden soll – aber nicht, wer sie verwaltet, wer ihre Vollständigkeit kontrolliert oder wie die während des Notbetriebs entstandenen Informationen später wieder zusammengeführt werden.

Für mich gehören diese Momente zu den spannendsten Erkenntnissen eines Workshops – auch, weil sie mein eigenes Bild vom Notbetrieb infrage gestellt haben. Ich habe einige Jahre beim Militär gedient, und dort war die Sache einfach: Fällt der Panzer aus, kämpft man eben zu Fuß weiter, langsamer, aber im Grunde derselbe Auftrag mit anderen Mitteln. Dieses Bild hatte ich lange auf Business Continuity Management übertragen, ohne es zu hinterfragen. Erst als ich sah, wie viele Abhängigkeiten sich allein aus einem Prozess wie der Warenverfügbarkeit ableiten lassen – man wird beim Aufzählen fast schwindelig –, wurde mir klar, wie sehr dieses Bild in die Irre führt. Ein Notbetrieb ist nicht derselbe Auftrag mit weniger Ausrüstung. Er ist ein eigener Prozess – mit eigenen Verantwortlichkeiten, eigenen Arbeitsschritten und eigenen Risiken.

Anfangs sprechen die Teilnehmer über den Ausfall eines Systems. Wenig später sprechen sie darüber, wie sie im Notbetrieb tatsächlich arbeiten würden. Aus einer technischen Fragestellung wird eine organisatorische – es geht nicht mehr nur um Software oder Infrastruktur, sondern um Menschen, Material, Abläufe und Kommunikation.

Dabei zeigt sich ein Muster, das ich in vielen Unternehmen beobachtet habe. Fast immer existieren bereits gute Ideen für den Notbetrieb. Die Mitarbeiter wissen, wie sie sich im Ernstfall behelfen würden. Dieses Wissen ist wertvoll, weil es aus praktischer Erfahrung entstanden ist. Gleichzeitig wird deutlich, dass improvisierte Lösungen allein selten ausreichen, wenn ein Ausfall nicht nur Stunden, sondern Tage andauert.

Ein Notbetrieb muss deshalb dieselben Fragen beantworten wie jeder andere Geschäftsprozess: Wer übernimmt welche Aufgabe, welche Informationen werden benötigt, und wer sorgt dafür, dass am Ende alles wieder vollständig in den regulären Prozess zurückfließt?

Erst wenn diese Fragen beantwortet sind, wird aus einer guten Idee ein belastbarer Notbetrieb.

Dadurch hat sich auch mein eigenes Verständnis von Business Continuity Management verändert. Früher dachte ich bei einem Notfallplan vor allem an Dokumente, Checklisten und Ausweichverfahren. Heute denke ich zuerst an Menschen, die unter ungewohnten Bedingungen zusammenarbeiten müssen. Der eigentliche Notbetrieb beginnt nicht mit einem Formular. Er beginnt damit, dass jeder weiß, welche Aufgabe er in diesem Moment übernimmt.

Mit jedem Workshop sammelten wir mehr Informationen, hielten Entscheidungen fest und ergänzten neue Erkenntnisse. Irgendwann entstand dabei eine ganz praktische Herausforderung: Wie lassen sich all diese Informationen so erfassen und weiterentwickeln, dass sie im nächsten Workshop nicht wieder von vorne beginnen?

Diese Frage beschäftigte mich in den folgenden Workshops immer wieder – dort verschob sich der Blick allerdings noch einmal: weg vom einzelnen Prozess, hin zu der Frage, wessen Einschätzung am Ende eigentlich zählt.

Wenn aus vielen Erkenntnissen ein gemeinsames Bild werden muss

Am Anfang eines Workshops arbeiten wir häufig mit einer Tabletop-Übung.

In kurzer Zeit werden unterschiedliche Szenarien durchgespielt. Die Teilnehmer diskutieren, welche Auswirkungen ein Ausfall hätte, welche Bereiche betroffen wären und wie das Unternehmen reagieren könnte. Für viele ist das der erste Moment, in dem Business Continuity Management nicht mehr wie eine abstrakte Anforderung wirkt, sondern wie eine ganz praktische Fragestellung.

Nach dieser ersten Übung beginnt die eigentliche Arbeit.

Fast immer startet sie aus der Perspektive des eigenen Fachbereichs. Das ist weder überraschend noch falsch. Jeder Teilnehmer kennt seine Prozesse am besten und beurteilt sie aus seiner täglichen Verantwortung heraus. Deshalb fallen zu Beginn häufig Sätze wie: „Ich weiß gar nicht, was das mit uns zu tun hat.“ Oder später: „Das haben wir doch bereits im Team besprochen.“

Beides stimmt. Der Fachbereich hat seine Hausaufgaben gemacht. Die Bewertung ist in sich schlüssig.

Nur mit einer Frage wurde sie bisher nie konfrontiert: Hält sie auch stand, wenn man sie neben die Bewertungen aller anderen Bereiche legt?

Genau hier verändert sich die Diskussion. An diesem Punkt zeigt sich häufig, dass eine Einschätzung, die für den eigenen Bereich völlig richtig war, im Vergleich mit dem Unternehmen als Ganzes eine andere Bedeutung bekommt. Nicht weil sie falsch gewesen wäre. Sondern weil sie nie an etwas anderem gemessen wurde als am eigenen Bereich.

Mit der Zeit wurde mir klar, dass genau darin die eigentliche Leistung eines Workshops liegt. Er nimmt niemandem seine fachliche Einschätzung weg. Er stellt sie neben die der anderen – und macht sichtbar, was erst im Vergleich sichtbar wird. Business Continuity Management beginnt fast immer mit dem eigenen Bereich. Es funktioniert aber erst, wenn dieser Blick überwunden wird. BCM ist am Ende kein Instrument, um den eigenen Bereich zu bewerten. Es ist ein Instrument für das Unternehmen als Ganzes.

Gleichzeitig entstand eine ganz praktische Herausforderung.

Je mehr Bereiche verglichen wurden, desto mehr Informationen kamen zusammen. Bewertungen wurden angepasst, Notbetriebsabläufe konkretisiert, Entscheidungen mussten Monate später noch nachvollziehbar sein. Neue Teilnehmer sollten verstehen können, warum eine Einstufung so und nicht anders getroffen worden war. Und niemand wollte einen Vergleich, der bereits gemeinsam entschieden worden war, beim nächsten Workshop erneut führen.

Was am Anfang noch als Whiteboard und Moderationskarten funktionierte, stieß hier an eine Grenze. Der Vergleich zwischen Bereichen ließ sich fotografieren. Er ließ sich nicht dauerhaft fortschreiben.

Mit der Zeit veränderte sich die Frage, mit der alles begonnen hatte. Nicht mehr: Wie sammeln wir genug Informationen? Sondern: Wie behalten wir eine Struktur, in der sich Bewertungen unterschiedlicher Bereiche jederzeit gegeneinander abgleichen lassen – auch Monate später, auch mit neuen Teilnehmern, auch nach dem dritten oder vierten Workshop?

Damals begann ich, darüber nachzudenken, ob sich diese Arbeit anders unterstützen ließe.

Diese Überlegung blieb zunächst vage. Konkret wurde sie erst an einem Punkt, den jeder Workshop-Moderator kennt: wenn der Raum sich leert und die eigentliche Arbeit erst beginnt.

Wenn der Workshop vorbei ist, beginnt die eigentliche Arbeit

Am Ende eines erfolgreichen Workshops herrscht oft eine besondere Stimmung.

Die wichtigsten Prozesse sind bewertet. Risiken wurden diskutiert. Der Notbetrieb ist beschrieben und erste Maßnahmen sind vereinbart. Die Teilnehmer verlassen den Raum mit dem Gefühl, gemeinsam einen wichtigen Schritt gemacht zu haben.

Auf dem Tisch bleiben Whiteboards, Moderationskarten, Notizen und eine Excel-Datei.

Ich habe in den vergangenen Jahren vermutlich hunderte Fotos von Whiteboards gemacht. Sie liegen bis heute irgendwo in meiner iCloud, fein säuberlich einsortiert – und in den allermeisten Fällen nie wieder geöffnet. Nach wenigen Tagen fehlte fast immer derselbe Teil: nicht das Bild, sondern das, was dazu gesagt wurde. Ein Foto zeigt ein Ergebnis. Es zeigt nicht, warum es zustande kam.

Nach jedem Workshop stellte ich mir dieselbe Frage: Wie soll daraus ein dauerhaft gepflegtes Business Continuity Management entstehen? Die Ergebnisse waren wertvoll. Sie enthielten Entscheidungen, Begründungen und Zusammenhänge, die in vielen Stunden gemeinsamer Arbeit entstanden waren. Gleichzeitig verteilten sie sich auf unterschiedliche Dokumente und Formate. Notizen erklärten Entscheidungen, die später kaum noch jemand nachvollziehen konnte. Mit jedem weiteren Workshop wuchs die Menge der Informationen – und damit auch der Aufwand, sie aktuell zu halten.

Besonders beschäftigt hat mich dabei ein Gedanke. Irgendwann würde ein BCM-Verantwortlicher diese Unterlagen übernehmen. Er sollte Prozesse ergänzen, Bewertungen anpassen, Maßnahmen nachverfolgen und neue Erkenntnisse einarbeiten. Ich konnte ihm erklären, was gepflegt werden musste. Ich konnte aber nicht überzeugend beantworten, wie das mit den vorhandenen Arbeitsmitteln dauerhaft funktionieren sollte. Die eigentliche Herausforderung lag also nicht im Workshop selbst, sondern in allem, was danach kommen musste.

Business Continuity Management lebt nicht von einer einmaligen Analyse. Es lebt davon, dass Informationen über Jahre aktuell bleiben. Prozesse verändern sich. Verantwortlichkeiten wechseln. Systeme werden ersetzt. Neue Risiken kommen hinzu. Ein BCM, das nach dem Workshop nicht weiterentwickelt wird, verliert mit der Zeit seinen Wert.

Aus dieser Überlegung entstand die Idee, die Workshop-Ergebnisse in einer gemeinsamen Struktur zusammenzuführen – nicht als Ersatz für den Workshop, sondern als Arbeitsgrundlage für die Zeit danach. Am Anfang dachte ich dabei erstaunlich wenig an Software. Ich dachte an Kontinuität. Ich wollte verhindern, dass Entscheidungen verloren gehen, Zusammenhänge erneut diskutiert werden müssen oder der nächste Verantwortliche wieder bei null beginnt.

Erst als ich versuchte, diese Anforderungen mit den vorhandenen Werkzeugen abzubilden, wurde mir klar, dass sie dafür nicht ausgelegt waren. Excel war hervorragend für Listen. Fotos dokumentierten einen Moment. Textdokumente hielten Entscheidungen fest. Aber keines dieser Werkzeuge verband Prozesse, Risiken, Notbetrieb und Maßnahmen zu einem gemeinsamen Gesamtbild.

Im Nachhinein überrascht mich, dass die größte Herausforderung anschließend gar nicht die Programmierung war. Schwieriger war es, aus den Erfahrungen der vergangenen Workshops eine Struktur zu entwickeln, die einfach genug für den Alltag und gleichzeitig belastbar genug für ein langfristiges BCM sein würde.

An diesem Punkt bekam das Projekt einen unerwarteten Begleiter. Nicht in Form eines weiteren Moderators oder Entwicklers, sondern durch Künstliche Intelligenz. Sie schrieb den Workshop nicht für mich und entwickelte auch nicht die fachlichen Inhalte. Stattdessen stellte sie immer wieder dieselben unbequemen Fragen, die auch ein kritischer Auditor gestellt hätte – und zwang mich damit, viele Entscheidungen noch einmal zu überdenken.

Diese Fragen blieben nicht auf die ersten Konzepte beschränkt. Sie begleiteten die gesamte Entwicklung – und veränderten dabei nicht nur das Werkzeug, sondern auch meinen Blick auf die Zusammenarbeit mit Künstlicher Intelligenz.

Mein unbequemster Auditor

Als die ersten Versionen des Werkzeugs entstanden, war ich überzeugt, dass der schwierigste Teil hinter mir lag. Die Anforderungen kamen aus echten Workshops, die Struktur war aus vielen Diskussionen entstanden, die Funktionen orientierten sich an den Fragen, die in der Praxis immer wieder auftauchten. Ich hatte das Gefühl, die wichtigsten Herausforderungen verstanden zu haben.

Dann begann ich, Künstliche Intelligenz in die Entwicklung einzubeziehen – nicht damit sie Code schreibt oder fachliche Entscheidungen trifft, sondern damit sie etwas übernimmt, das in Projekten oft zu kurz kommt: unbequeme Fragen stellen.

Mit der Zeit entwickelte sich daraus eine klare Arbeitsteilung. Ich war der Architekt und derjenige, der die Anforderungen aus den Workshops kannte. Gleichzeitig war ich der härteste Kritiker im Raum. Die KI übernahm die Rolle, die in kleinen Projekten oft fehlt: Sie testete Annahmen, stellte Qualität infrage und zwang mich, Entscheidungen immer wieder zu begründen.

Der Unterschied wurde mir erst richtig bewusst, als ich beide Arbeitsweisen verglich. Wer die KI nur nach einer fertigen Lösung fragt, bekommt etwas Funktionierendes. Wer sie stattdessen führt, ihr eine Rolle gibt und ihre Antworten selbst kritisch prüft, bekommt etwas anderes: Qualität, die auch unter ungewöhnlichen Bedingungen Bestand hat.

Nicht jede dieser Situationen war angenehm. An einem Punkt wollte ich das Werkzeug in mehrere Klassen und einen eigenen Installer aufteilen – aus meiner Erfahrung heraus schien mir das die sauberere Lösung. Die KI widersprach. Ihr Argument war nicht technischer, sondern praktischer Natur: Eine einzige HTML-Datei sei für den Anwender am einfachsten, gerade weil sie ohne Installation auskomme – und die damit verbundenen Sicherheitsfragen ließen sich im Nachhinein bearbeiten. Ich hielt zunächst wenig davon. Am Ende setzten wir genau das um, arbeiteten die Sicherheitsthemen sorgfältig nach – und die einfache Lösung erwies sich als die richtige.

Was passiert, wenn ein Projekt aus einer älteren Version importiert wird? Wie lassen sich versehentliche Datenverluste vermeiden? Welche Informationen fehlen einem neuen BCM-Verantwortlichen, wenn er ein bestehendes Projekt übernimmt? Solche Fragen stellte die KI immer wieder, und nicht selten hatte ich zunächst keine gute Antwort. Manche betrafen die Software, viele jedoch das fachliche Konzept dahinter: Warum wird diese Information überhaupt gespeichert? Reicht diese Bewertung wirklich aus? Ist diese Entscheidung auch in einem Jahr noch nachvollziehbar?

Je länger die Entwicklung dauerte, desto seltener hatte ich das Gefühl, mit einer Programmierhilfe zu arbeiten. Es fühlte sich eher an, als säße bei jeder Entscheidung ein kritischer Auditor mit am Tisch – einer, der sich nicht dafür interessierte, wie elegant eine Funktion umgesetzt war, sondern ob sie auch unter ungewöhnlichen Bedingungen Bestand haben würde.

Diese Arbeitsweise hat das Projekt stärker verändert als jede einzelne Funktion. Viele Ideen, die zunächst plausibel wirkten, verschwanden wieder. Andere wurden mehrfach überarbeitet, nicht weil sie technisch falsch waren, sondern weil sie den Anforderungen aus den Workshops nicht dauerhaft gerecht wurden.

In den vergangenen Jahren wurde häufig darüber diskutiert, ob KI Menschen ersetzen könne. Meine Erfahrung war eine andere: Die größte Stärke lag nicht darin, Antworten zu liefern, sondern darin, Fragen zu stellen, auf die ich selbst nicht gekommen wäre – und zwar nur, solange jemand diese Fragen auch führte und beantworten musste.

Vielleicht passt genau das auch zu Business Continuity Management. Ein guter Workshop lebt nicht davon, dass der Moderator alle Antworten kennt, sondern davon, dass die richtigen Fragen gestellt werden. Die KI hat das BCM Starter Kit nicht entwickelt. Sie hat geholfen, es immer wieder zu hinterfragen – so wie ein Workshop nicht die fertige Lösung liefert, sondern den Rahmen, in dem sie entsteht.

Heute ist das Projekt als Open Source veröffentlicht. Nicht, weil ich glaube, dass es die eine richtige Lösung für Business Continuity Management ist, sondern weil Transparenz schon immer ein zentraler Bestandteil guter BCM-Arbeit war – Entscheidungen müssen nachvollziehbar sein, Abläufe müssen überprüft werden können, und Software wird besser, wenn andere sie hinterfragen dürfen.

Rückblickend war das die wichtigste Erkenntnis dieser Reise: Business Continuity Management entsteht nicht durch Dokumente, Werkzeuge oder Normen. Es entsteht dort, wo Menschen bereit sind, die richtigen Fragen zu stellen – und Antworten gemeinsam weiterzuentwickeln.

Das daraus entstandene BCM Starter Kit ist als Open Source verfügbar: [github.com/riemer-consulting/bcm-starter-kit]