Kostenreduzierung durch prozessbasierte Risikoanalyse – Teil 2
Im Teil 1 der prozessbasierten Risikoanalyse habe ich beschrieben, wie wir die Risikoanalyse der Prozesse erstellen. Wir wissen nun, welche Prozessteile – Aktivitäten, Subprozesse und Throwing Events – potenziell gefährdet sind. Im zweiten Teil schlagen wir jetzt über die Detailbetrachtung dieser Aktivitäten den Bogen zu den betroffenen technischen Komponenten.
Detailbetrachtung der Aktivitäten
Wir lassen uns nun von unser Modellierungs-Software einen Bericht generieren, der die identifizierten Prozessteile der gesamten Prozesslandschaft auflistet. Basierend auf der Risikokennzahl scheint mir eine Liste in absteigender Reihenfolge sinnvoll. So stehen die riskantesten Aktivitäten oben. Die sollten wir uns zuerst im Detail betrachten.
Zum Vergrößern anklicken: Bericht über alle gefährdeten Aktivitäten
Wie ich schon ansprach können wir letztlich nicht die Prozessteile selbst schützen, sondern nur die daran beteiligten technischen Einrichtungen. Diese müssen nun erarbeitet werden. Hierfür gibt es mehrere Möglichkeiten. Aktivitätsdiagramm oder Robustness Diagram scheinen mir gleichermaßen geeignet. Wichtig ist eben, dass man nun die einzelnen Aktionen der Aktivität und ihren Zugriff auf technische Einrichtungen detailliert aufzeigt. Beginnen wir mit den riskantesten Aktivitäten oben auf unserem Aktivitätenbericht.
Zum Vergrößern anklicken: Drilldown von Aktivitäten zu technischen Komponenten
In diesem Beispiel habe ich ein Robustness Diagram gewählt. Die nach links drehenden Kreise sind Controller. Sie symbolisieren die Aktionen innerhalb der Aktivität. Sie greifen auf Entitäten zu. Das sind die Kreise mit dem Unterstrich, welche die technischen Komponenten symbolisieren. Und um die geht es bei all unseren Absicherungsbemühungen.
Zweite Risikoanalyse: Die Entitäten
Auch dieser Analyseschritt verwendet wieder die Risikokennzahl. Wenn wir zu einer Aktivität ein Robustness Diagram modellieren, übernimmt das Modellierungstool die Risikokennzahl der Aktivität in alle Entitäten, die wir diesem Diagramm hinzufügen. Damit wären folglich alle technischen Komponenten einer Aktivität gleichsam gefährdet. Ist das aber so? Wahrscheinlich nicht. Wir müssen also für alle Entitäten des Robustness Diagrams überlegen, ob sie gefährdet sind oder nicht. Die Gefährdung unproblematischer Entitäten setzen wir auf NEIN, sie werden nicht weiter betrachtet.
Kleiner Hinweis: Falls Sie in dem Robustness Diagram keine Entität als gefährdet einstufen, ist entweder die darüber liegende Aktivität irrtümlicherweise als gefährdet eingestuft worden, oder Sie haben in dem Robustness Diagram eine Entität übersehen. Das hier vorgestellte Prinzip besagt, dass es zumindest eine schützenswerte Entität geben muss.
Nachdem wir nun für alle Aktivitäten eine derartige Detailbetrachtung vorgenommen haben, können wir uns die wirklich gefährdeten Entitäten / Komponenten unseres Unternehmens bzw. Behörde auflisten lassen. Auch das sollte wieder nach Prioritäten erfolgen. Um die Priorität zu ermitteln, müssen wir noch berücksichtigen, ob eine technische Komponente innerhalb mehrerer Aktivitäten eingebunden ist. Daraus ergibt sich das Gesamtrisiko.
Wir müssen uns das so vorstellen:
Zum Vergrößern anklicken: Ermittlung des Gesamtrisikos
Wird eine Entität von mehreren Aktivitäten verwendet, addiere ich die jeweiligen Risikokennzahlen. Das ergibt das Gesamtrisiko. Aufgrund dieses Gesamtrisikos kann das Modellierungssystem nun einen Bericht generieren, der die Wichtigkeiten klar erkennen lässt.
Zum Vergrößern anklicken: Bericht aller gefährdeter Komponenten
Jetzt haben wir einen detaillierten Blick auf unsere technischen Einrichtungen. Die Komponenten, die in diesem Bericht aufgelistet werden, müssen wirklich geschützt werden. An eben diesen Stellen ist der reibungslose Ablauf unserer Prozesse angreifbar.
Das Vorgehen noch mal im Überblick
Lassen Sie mich die einzelnen Schritte kurz zusammenfassen:
Analyse der Geschäftsprozesse in BPMN (Teil 1)
Beurteilung des Einzelrisikos jeder Aktivität (Teil 1)
Ggf. Untersuchung der Subprozesse (Teil 1)
Bericht aller gefährdeten Aktivitäten nach Risikokennzahl
Detailbetrachtung der gefährdeten Aktivitäten
Gefährdungsbeurteilung der Entitäten
Bericht über alle gefährdeten Entitäten nach Gesamtrisiko
Vorteil dieses Vorgehens
Dieser prozessorientierte Ansatz fokussiert die unternehmenskritischen Prozessteile und leitet auf dieser Basis die schützenswerten technischen Einrichtungen ab. Wie spielt dieser Ansatz mit herkömmlichen Sicherheitsstrategien zusammen? Ich möchte mit diesem Vorgehen nicht die typischen Sicherheitsstrategien in Frage stellen. Ich möchte sie lediglich etwas zielgerichteter auf die Problemfelder losgehen lassen.
Statt riesige Gesamtsysteme mit enormem Aufwand abzuriegeln, sind wir nun in der Lage, kleinere Systemeinheiten effektiv zu schützen. Einerseits reduzieren wir sozusagen die Länge des Zauns, den wir um das Haus ziehen müssen. Andererseits frieden wir nicht mehr alle Häuser ein, sondern konzentrieren uns auf die wesentlichen. Das führt zu signifikanter Kostenreduzierung.
Nicht zuletzt möchte ich mich bei meinem Freund Philippe Back bedanken. Er spielt meinen intellektuellen Sparringpartner und hat mir geholfen, meine Ideen zu sortieren.
Ich freue mich auf Ihre Anregungen.
Update
Ich habe für diesen Ansatz ein kleines Szenario durchmodelliert. Finden Sie hier das end-to-end example of this process based risk analysis approach (auf Englisch).