Kostenreduzierung durch prozessbasierte Risikoanalyse – Teil 1
Unsere Welt ist nahezu durchgängig technisiert. Man muss es wohl konstatieren: Unser Leben hängt im hohen Maß vom Funktionieren technischer Einrichtungen ab. Um den reibungslosen Ablauf zu gewährleisten, müssen diese Einrichtungen gegen verschiedenste Risiken abgesichert werden. Das ist sehr aufwendig und teuer. Derzeit ist die Risikoanalyse auf die technischen Einrichtungen fixiert. Alle im Einsatz befindlichen Geräte und Installationen werden gegen alle erdenklichen Risiken geschützt. Im Folgenden möchte ich einen anderen Ansatz skizzieren, der sich der Absicherung technischer Einrichtungen nicht von der Hardware-Seite sondern vom Geschäftsprozess nähert.
Hintergrund ist die Frage, wie wir die Kosten der Absicherung senken können. Wie wäre es, wenn man die zu schützenden “Areale” möglichst klein halten könnte? Man also keinen Zaun um das gesamte Gebäude, sondern nur um das eine wertvolle Buch ziehen müsste. Wie wäre es, wenn man nicht mehr 20 Häuser, sondern nur noch zehn schützen müsste? Man also die Anzahl der schützenswerten Objekte reduzieren könnte. Ich denke, dass sich die Kosten der Schutzmaßnahmen dadurch erheblich reduzieren ließen.
Mit diesem prozess-orientierten Ansatz betrachte ich nicht generell alle technischen Komponenten und ihre Risikofaktoren. Stattdessen filtere ich die Prozessbestandteile heraus, die wirklich wichtig sind. Und nur die darin eingebundenen technischen Einrichtungen gilt es zu schützen. Das allerdings mit allen möglichen Mitteln.
Geschäftsprozessmodellierung und erste Risikoanalyse
Bei der Frage nach dem Risiko gibt es verschiedene Aspekte zu bedenken:
Wie hoch ist die Wahrscheinlichkeit, dass ein Risiko eintritt?
Wie groß ist der Schaden, der bei Eintreten entsteht?
Im ersten Schritt modelliere ich die Geschäftsprozesse. Ich nutze dafür zumeist die BPMN. Zwecks Risikoanalyse beurteile ich bei jeder Aktivität bzw. bei jedem Subprozess die Wahrscheinlichkeit, dass an dieser Stelle ein Zwischenfall eintritt, und die Schadenschwere, falls es zu einem Schaden kommt. Für die Wahrscheinlichkeit und die Schadenschwere vergebe ich werte von 1 bis 5. 1 steht für eine äußerst geringe Wahrscheinlichkeit bzw. geringe Schadenschwere. 5 beschreibt eine sehr hohe Wahrscheinlichkeit oder extrem schwere Schadenauswirkungen. So ermittle ich das Einzelrisiko (= Eintrittswahrscheinlichkeit * Schadenschwere).
Zum Vergrößern anklicken: Risikoanalyse der einzelnen Aktivitäten und Subprozesse
In diesem kleinen Beispiel sehen wir ein Einzelrisiko mit mittlerer Eintrittswahrscheinlichkeit und eher minderer Auswirkung. Diese Risikoeinschätzung müssen wir für alle Aktivitäten und Subprozesse vornehmen, die sich innerhalb des Verantwortungsbereichs des betrachteten Unternehmens / der Behörde befinden. Das sind nicht notwendigerweise nur die Aktivitäten, die innerhalb der Organisation selbst (Pool) durchgeführt werden. Das können auch Prozessschritte sein, die externe Teilnehmer durchlaufen, aber dabei Mittel einsetzen, die von dem Unternehmen / der Behörde zur Verfügung gestellt werden.
Beispiel: Im Rahmen des Prozesses “Internetverbindung herstellen” liegt die Aktivität “In das Internet einwählen” bei einem externen Teilnehmer wie bspw. einer Privatperson. Zur Einwahl verwendet diese Privatperson ein Modem, das von einer Telefongesellschaft bereitgestellt wird. Möchte die Telefongesellschaft ihre Prozesse absichern, darf diese extern ausgeführte Aktivität nicht vernachlässigt werden. Der Prozess oder sogar das ganze Unternehmen könnten sonst durch ein manipuliertes Modem sabotiert werden.
Wenn man in BPMN intensiv mit sogenannten “Throwing Events” (also sendenden Ereignissen) arbeitet, müssen diese gegebenenfalls in die Risikoanalyse einbezogen werden, da sich dahinter implizit auch eine Aktivität verbirgt – nämlich die des Sendens. Und das erfolgt in der Regel mittels technischer Einrichtungen, die wir ja schützen möchten.
Zum Vergrößern anklicken: Ein Throwing Event beinhaltet auch eine Aktivität.
Im Folgenden möchte ich mich aber aus Gründen der Einfachheit auf Aktivitäten und Subprozesse beschränken.
Risikokennzahl
In der gesamten Prozesslandschaft kann eine Aktivität oder ein Subprozess in mehreren Prozessen erscheinen. Das hat Auswirkungen auf die Risikorelevanz. Je mehr Prozesse eine bestimmte Aktivität einbinden, desto wichtiger wird sie. Ich multiplizieren das Einzelrisiko der Aktivität also mit der Anzahl ihrer Verwendungen. Dies ergibt die Risikokennzahl der betrachteten Aktivität.
Zum Vergrößern anklicken: Formel zur Berechnung der Risikokennzahl
Zum Vergrößern anklicken: Ermittlung der Risikokennzahl
In diesem Beispiel wird der Subprozess in zwei Prozessen verwendet. Wir multiplizieren also das Einzelrisiko mit 2 und erhalten eine Risikokennzahl von 12.
Besonderheit Subprozess
Subprozesse fassen in der Regel mehrere Aktivitäten zusammen und werden zwecks Übersichtlichkeit in der Geschäftsprozessmodellierung verwendet. Für unsere Risikoanalyse bedeutet das, dass die für den Subprozess ermittelte Risikokennzahl auf all seine Aktivitäten übertragen wird. Leider ist unsere Risikoanalyse damit noch nicht abgeschlossen. Wir müssen uns nun die einzelnen Aktivitäten des Subprozesses ansehen und beurteilen, ob sie jeweils gefährdet sind oder nicht. Nicht-gefährdete Aktivitäten werden später nicht weiter betrachtet und daher entsprechend gekennzeichnet (bspw. durch einen Boolean: [Gefährdung = NEIN]). Gefährdete Aktivitäten behalten die Risikokennzahl des Subprozesses.
Zum Vergrößern anklicken: Risikobeurteilung der Aktivitäten innerhalb eines Subprozesses
Erster Zwischenstand
Wenn wir diese Schritte für unsere gesamte Prozesslandschaft durchgeführt haben, wissen wir, welches die gefährdeten Aktivitäten sind. Aufgrund der Risikokennzahl können wir zwischen risikoreichen und risikoarmen Prozessschritten unterscheiden. In einem weiteren Schritt müssen wir uns dann den technischen Einrichtungen nähern. Zu diesem Zweck werden wir die gefährdeten Aktivitäten von innen betrachten. Lesen Sie weiter im Teil 2 dieser prozessbasierten Risikoanalyse.Weiter zu Teil 2 der prozessbasierten Risikoanalyse: Identifizieren der schützenswerten technischen Komponenten >>