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.