Warum Process Impact Mapping beim Geschäftsprozess beginnt — nicht beim System

Die meisten Risikoanalysen beginnen mit der falschen Frage: „Welche Systeme haben wir?“

Das klingt vernünftig, ist aber ein rein technischer Startpunkt. Am Ende steht eine Inventarliste von Servern und Anwendungen der niemand ansieht, was sie für das Geschäft tatsächlich bedeutet. Ein Server ist ein Server. Ob an ihm die Kaffeekasse hängt oder die Fertigungssteuerung, die pro Ausfalltag sechsstellige Beträge kostet, kann uns die Liste nicht verraten.

Im letzten Beitrag hatte ich argumentiert, dass Risikomanagement an seinen Brüchen scheitert. Eben an den Übergängen zwischen diesen getrennten Prozessen. Der erste Baustein, um das zu vermeiden ist, die Business Impact Analysis. In PRISM nenne ich sie Process Impact Mapping, kurz PIM. Und sie beginnt damit, dass sie die erste Frage umdreht.

Der umgedrehte Startpunkt

Klassische Verfahren beginnen mit der Asset-Identifikation: Man erfasst zuerst die Technik und fragt später, wozu sie gut ist. Das ist ein technischer Einstieg, und er hat eine unangenehme Nebenwirkung. Assets werden um ihrer selbst willen erfasst, gleichrangig und ohne inneren Kompass dafür, welche tatsächlich wichtig sind. So wird dann oft auch der Schutzbedarf für die Assets erhoben.

PIM beginnt am anderen Ende: bei den eigentlichen Geschäftsprozessen. Nicht: „Welche Systeme haben wir?“, wird gefragt, sondern: „Was muss laufen, damit das Unternehmen Geld verdienen kann?“. Der Effekt ist aber grundlegend. Assets werden nicht mehr isoliert inventarisiert, sondern danach eingeordnet, welche kritischen Prozesse sie tragen. Ein System erbt seine Wichtigkeit von der Geschäftsfunktion, die auf ihm ruht und nicht von seinen technischen Daten.

Das ist mehr als eine Reihenfolge-Frage. Es entscheidet, worüber am Ende überhaupt gesprochen werden kann. Wer mit Systemen beginnt, landet bei einer Technikliste, die der Vorstand nicht lesen und hören will. Wer mit Prozessen beginnt, landet bei Aussagen über Umsatz, Lieferfähigkeit und Vertragsstrafen, also bei Dingen, über die im Vorstand ohnehin gesprochen wird.

Die Fragen, die zählen

PIM stellt nacheinander einige einfache, aber unbequeme Fragen. Was muss laufen: Von der Auftragsannahme über die Fertigung bis hin zur Zahlung? Welche Prozesse dürfen wie lange ausfallen, bevor es ernsthaft wehtut? Und, die wohl am meisten übersprungene Frage: Was kostet uns z.B. ein Tag Stillstand, in Euros?

Hinter diesen Fragen steckt mehr, als es scheint. „Wie lange darf ein Prozess ausfallen?“ zerfällt bei genauerem Hinsehen in mehrere Kennzahlen, die das Business-Continuity-Handwerk seit Langem kennt: die maximal tolerierbare Ausfallzeit, ab der ein Schaden irreversibel wird; die Wiederanlaufzeit, in der ein Prozess zurück sein muss; und der tolerierbare Datenverlust, also wie viel Arbeit man im schlimmsten Fall verschmerzen kann, bevor die Wiederherstellung ansetzt. Diese Größen klingen technisch, sind aber im Kern zutiefst betriebswirtschaftlich: Sie bemessen, wie die Puffer eines Geschäfts.

Die dritte Frage allerdings ist die eigentliche Trennlinie zur klassischen BIA. Dort bleibt der Schaden im Normalfall sehr vage ausgedrückt: „Hoch“, „Geschäftskritisch“ oder „Schwerwiegend“. In PIM wird er allerdings beziffert. Und das ändert alles, denn mit Zahlen kann man weiterrechnen und mit Farben nicht.

Ehrliche Zahlen sind Bereiche

Jetzt kommt der Punkt, an dem PIM sich von scheingenauer Zahlenspielerei unterscheidet. Beziffert wird nicht mit einer einzelnen, präzise wirkenden Zahl, sondern sie wird als Bereich formuliert: ein Minimum, ein wahrscheinlichster Wert, ein Maximum. Drei Punkte statt einem.

Warum dass? Weil ein Ausfalltag eben nicht immer gleich teuer ist. Ein schwacher Produktionstag kostet etwas anders als bei einem Spitzentag mitten in der Hochsaison. Eine Vertragsstrafe greift vielleicht oder vielleicht auch nicht, je nachdem, welcher Kunde betroffen ist. Diese Spanne ist keine Schwäche der Schätzung sondern im Gegenteil. Sie ist die ehrliche Wahrheit über ihre Unsicherheiten. Wer stattdessen eine einzige Zahl hinschreibt, tut nur so, als wüsste er es genau und verliert dabei aber genau die Informationen, die später zählen.

Diese Drei-Punkt-Schätzung in PRISM ist kein Stilmittel, sondern ein Prinzip. Sie ist die Voraussetzung dafür, dass die spätere Quantifizierung überhaupt funktionieren kann: Aus Minimum, wahrscheinlichstem Wert und Maximum lassen sich Wahrscheinlichkeitsverteilungen formen. Mit Verteilungen kann man die Monte-Carlo-Simulation durchrechnen. Ohne Bereiche auch keine Verteilungen und ohne Verteilungen auch keine belastbaren Ergebnisse. Der Bereich ist also nicht nur optisches Beiwerk, sondern das zentrale Fundament.

Wie das konkret aussieht

Machen wir es greifbar an einem Fertiger mit CNC-Produktion. In der Ausfall-Kostenrechnung, das ist einer der Kernschritte von PIM, werden die einzelnen Kostenbestandteile eines Stillstandstages sauber getrennt und jeweils als Kostenbereich erfasst.

Entgangener Umsatz: an einem schwachen Tag vielleicht 100.000,- €, im Normalfall 120.000,- €, an Spitzentagen 160.000,- €. Weiterlaufende Fixkosten: 40.000,- bis 55.000,- €, je nachdem, ob Überstunden anfallen oder nicht. Vertragsstrafen: im Glücksfall null, typischerweise aber 25.000,- €. Im Eskalationsfall sogar 50.000,- €. Dazu noch die Krisenkosten für Sonderschichten und Nacharbeit.

Summiert ergibt das nicht eine Zahl, sondern einen Korridor: Grob: 145.000,- € an einem glimpflichen Tag und rund 200.000,- € im wahrscheinlichsten Fall, bis hin zu 285.000,- € im schlechtesten Fall. Diese drei Zahlen sagen zusammen mehr aus als jeder Einzelwert in der Lage sein kann. Sie zeigen nicht nur, womit zu rechnen ist, sondern auch, wie weit die Spanne reicht.

Das Ergebnis dieses Durchgangs ist ein Prozess-Register: jede kritische Funktion mit ihrer Ausfalltoleranz, ihrer Wiederanlaufzeit, ihrem tolerierbaren Datenverlust, den stützenden IT- und OT-Systemen und ihren Ausfallkosten in Euro pro Tag, durchgängig und als Bereiche. Eine kompakte, geschäftsnahe Landkarte dessen, was tatsächlich auf dem Spiel steht.

Warum hier kein Bruch entsteht

Und jetzt der Punkt, der die ganze Reihe zusammenhält. Diese Euro-pro-Zeiteinheit-Bereiche sind keine Sackgasse in einem BIA-Dokument, das anschließend in der Schublade verschwindet. Sie sind exakt die Größen, die die spätere Quantifizierung als Eingabe benötigt.

Der Übergang ist verblüffend einfach und direkt. Der Schaden eines Vorfalls ist im Kern nichts anderes als Ausfallkosten pro Tag, multipliziert mit der Dauer des Ausfalls. Wenn eine Ransomware die Fertigung für geschätzt drei bis zehn Tage lahmlegt, dann ergibt sich der direkte Schaden, indem man die bereits erhobenen €/Tag-Bereiche mit dieser Ausfalldauer verrechnet. Damit wird aus 200.000,- € pro Tag und fünf Tagen ein wahrscheinlicher Schaden von einer Million. Die Ränder der Spanne ergeben sich dann genauso. Kein neues Interview, keine neue Skala, keine Übersetzung. Was PIM erhoben hat, rechnet die Quantifizierung einfach weiter. Die Zeitspannen kann man natürlich an seine Gegebenheiten anpassen. Also die Euro-pro-Zeiteinheit.

Das ist der Unterschied zwischen einem Datensatz, der durchfließt, und einem, der an der nächsten Projektgrenze verebbt und stirbt. Die Zahl, die im ersten Schritt geschäftsnah erhoben wurde, ist im letzten Schritt der Rohstoff der Euro-Verlustverteilung. Genau dort, wo klassische Ansätze ihren Bruch haben, hat PIM eine elegante Brücke.

Ein Nebeneffekt: Der Risikoappetit bekommt eine Einheit

Es gibt einen zweiten, oft unterschätzten Gewinn. Sobald Schäden in Euro vorliegen, kann auch der Risikoappetit also die Frage, wie viel Risiko ein Unternehmen zu tragen bereit ist, in Euro formuliert werden, anstatt in Ampelfarben.

Statt „wir wollen keine roten Risiken“ wird daraus eine handhabbare Staffelung: Ein jährlicher Erwartungsschaden unterhalb einer bestimmten Schwelle gilt als akzeptabel und wird nur beobachtet; darüber wird gehandelt, mit klaren Fristen für die Maßnahmen. Das mag technisch klingen, ist aber genau die Sprache, mit der ein Vorstand entscheiden kann. „Reduzieren wir das eine Risiko von Rot auf Gelb“ rechtfertigt kein Budget. „Wir senken den zu erwarteden Schaden um 1,5 Millionen mit einer Investition von 180.000“ aber schon. Der geschäftsnahe Startpunkt macht diese Sprache überhaupt erst möglich.

Der Ablauf in fünf Schritten

Damit das nicht abstrakt bleibt, lohnt ein Blick auf den tatsächlichen Ablauf. PIM ist kein monatelanges Projekt, sondern eine strukturierte Folge von Schritten, die sich in überschaubarer Zeit mit den richtigen Leuten im Raum durchführen lässt.

Zuerst die Wertschöpfungskette. Man skizziert top-down, welche Geschäftsprozesse überhaupt existieren. Vom eingehenden Kundenauftrag bis zur Zahlung. Das ist bewusst grob und schnell; es geht darum, das Gesamtbild zu sehen und nicht jedes einzelne Detail.

Dann die Kritikalität. Welche dieser Prozesse sind wirklich geschäftstragend? Hier fällt die erste Priorisierung. Nicht jeder Prozess ist gleich wichtig, und das darf man ruhig auch aussprechen.

Der dritte Schritt ist das Herzstück: die Ausfall-Kostenrechnung. Für die kritischen Prozesse werden die Kosten eines Ausfalltages oder -Stunden als Bereich erfasst. Genau die Min/ML/Max-Zerlegung aus dem Beispiel oben. Das ist der Schritt, der am meisten Substanz liefert und deshalb auch die meiste Sorgfalt verdient.

Viertens die System-Abhängigkeiten. Erst jetzt erst, und das ist die bewusste Umkehr,  kommen die Systeme ins Spiel: Welche IT- und OT-Systeme tragen den kritischen Prozess? Wo gibt es einzelne Ausfallpunkte, deren Verlust den ganzen Prozess stoppen können oder korrumpieren? Welche externen Abhängigkeiten bestehen, etwa zu Cloud-Diensten oder Lieferanten? Die Technik wird hier nicht um ihrer selbst willen erfasst, sondern als Stütze eines Geschäftswerts.

Und fünftens der tolerierbare Datenverlust. Wie viel Arbeit darf im schlimmsten Fall verloren gehen, bevor die Wiederherstellung ansetzt? Auch hier wird mit Bereichen gearbeitet. Und ja, auch das prozessabhängig. Eine Qualitätsprüfung mit compliance-relevanten Protokollen verträgt praktisch keinen Datenverlust, während eine Buchhaltung mit einem Tagesabschluss auskommt.

Am Ende dieser fünf Schritte steht das sogenannte Prozess-Register. Kompakt, geschäftsnah, und vollständig genug, um die nächsten Schichten zu tragen. Der ganze Aufwand ist überschaubar, weil man sich auf das Kritische konzentriert und das Unwichtige bewusst grob lässt.

Der Sonderfall OT: Warum Verfügbarkeit hier besonders wichtig ist

Nun ein Wort zu einer Umgebung, die mir besonders am Herzen liegt und in der PIM seine Stärke voll ausspielen kann: die operative Technik in der Produktion. Denn hier zeigt sich, warum der geschäftsnahe Startpunkt kein akademisches Feinschmeckerthema ist.

In der klassischen IT dominiert oft die Vertraulichkeit. Daten dürfen nicht in falsche Hände geraten. In der OT, bei Steuerungen und Leitsystemen an der Fertigungslinie, kehrt sich die Rangfolge um: Hier zählt vor allem die Verfügbarkeit und die Safety. Steht die Linie, entsteht Schaden nicht abstrakt und irgendwann, sondern unmittelbar und messbar. Jede Stunde Stillstand hat seinen Preis und den kann man beziffern. Genau diese Beträge sind es, die eine rein technische Asset-Liste niemals sichtbar macht, die PIM aber ins Zentrum stellt.

Dazu kommt eine Besonderheit, die man in der OT nicht ignorieren darf: Sicherheit im Sinne von Security und Sicherheit im Sinne von Safety, dem Schutz von Mensch und auch der Anlage selbst, können in Konflikt geraten. Eine Schutzmaßnahme, die ein IT-System einfach neu startet, kann an einer laufenden Anlage gefährlich sein. Deshalb ist es doppelt wichtig, dass die Kritikalität eines OT-Prozesses von Anfang an klar und beziffert vorliegt: Sie steuert nicht nur, wie viel Analyseaufwand ein Prozess bekommt, sondern auch, mit welcher Umsicht man später über Gegenmaßnahmen nachdenkt. Ein geschäftsnah erhobenes Prozess-Register ist hier die Grundlage für Entscheidungen, bei denen mehr auf dem Spiel steht als bloß Daten.

Eine Analogie: die Inventur und der Notfallplan

Vielleicht wird der Unterschied an einem Bild klarer. Stell dir zwei Menschen vor, die dasselbe Haus beschreiben sollen. Der erste macht eine Inventur: Er zählt jede Lampe, jeden Stuhl, jedes Kabel, jedes Gerät. Am Ende hat er eine vollständige und korrekte Liste aber keine Ahnung, was passiert, wenn das Wasser ausfällt.

Der zweite fragt anders: Was muss in diesem Haus funktionieren, damit man darin leben kann? Heizung im Winter, Wasser, Strom für den Kühlschrank. Er landet bei einer viel kürzeren Liste die aber jeden Eintrag mit einer Konsequenzen verknüpft: Fällt das aus, passiert jenes, und es kostet so viel. Seine Liste ist nicht vollständiger, im Gegenteil, aber sie ist entscheidungsrelevanter.

Die klassische, systemzentrierte Analyse ist die Inventur. PIM ist ein anderer Ansatz. Er strebt nicht nach Vollständigkeit um jeden Preis, sondern nach größtmöglicher Relevanz: Was trägt das Geschäft tatsächlich, und was kostet der Ausfall? Eine kurze Liste mit Konsequenzen schlägt eine lange Liste ohne. Und weil jeder Eintrag eine Euro-Konsequenz hat, weiß man von Anfang an, wo man genauer hinschauen muss und wohin nicht.

These

Wer die Risikoanalyse beim Geschäftsprozess beginnt statt beim System, gewinnt zweierlei. Erstens Management-Relevanz von der ersten Minute an. Der Vorstand sieht sofort Euros, nicht Server, und bleibt daher im Gespräch präsent. Zweitens, einen durchgehenden Datensatz, der die nachfolgenden Schritte trägt, anstatt an den Projekt- und Prozessgrenzen zu zerbrechen.

Beginne beim Geschäftsprozess, nicht beim System. Der Vorstand sieht dann Euros statt Server und der Datensatz trägt alles bis hin zur Quantifizierung.

Woher wir das wissen

Der Ansatz ist nicht aus der Luft gegriffen. Die drei Kennzahlen der Ausfalltoleranz: Maximal tolerierbare Ausfallzeit, Wiederanlaufzeit und tolerierbarer Datenverlust sind der etablierte Kern jeder Business Impact Analysis nach den einschlägigen Normen. Neu ist auch nicht, dass man sie erhebt, sondern dass man sie konsequent an Euro-Bereiche koppelt und diese Bereiche unverändert bis in die Quantifizierung weiterreicht.

Auch die Drei-Punkt-Schätzung ist etabliert. Sie stammt ursprünglich aus dem Projektmanagement, wo man mit ihr Aufwände unter Unsicherheit geschätzt hat und sie ist die natürliche Eingabe für die Verteilungen, mit denen spätere Monte-Carlo Simulationen berechnet werden können. PIM erfindet hier nichts es verbindet nur Bewährtes so, dass der Bruch zwischen Geschäftssicht und Quantifizierung gar nicht erst entstehen kann.

Bleibt nur festzuhalten: Die Qualität der Bereiche hängt natürlich an der Qualität der Gespräche und der Erhebung. Wer die Prozessverantwortlichen schlecht befragt, bekommt schlechte Spannen und keine Methode der Welt kann das dann hinterher reparieren. Der Bereich macht die Unsicherheiten deutlich sichtbar und er beseitigt sie nicht. Aber eine sichtbare, dokumentierte Unsicherheit ist einer hinter einem Punktwert versteckten, immer überlegen.

Was kommt noch

Mit dem Prozess-Register als Fundament treffen die kritischen Prozesse im nächsten Schritt auf die Bedrohungen: Was kann passieren, und mit welcher Wahrscheinlichkeit? Und vor allem: Wie tief muss man überhaupt reinschauen? Denn nicht jeder Prozess verdient dieselbe Analysetiefe. Das ist dann das Layer 2, das eigentliche Risk Assessment, und der Leitgedanke lautet: Tiefe folgt dem Geschäftswert.

Vorher aber die Frage an dich: Beginnt eure Risikoanalyse beim System oder beim Geschäftsprozess und steht am Ende ein Euro-Betrag, oder eine Farbe?