20. Feb 2012
Am Freitag hatte ich die Gelegenheit, die msg systems AG in die Usability-Thematik einzuführen: Ein Tag Usability
Das war ein spannender Tag mit zwölf tollen Teilnehmern und viel Spaß. Neben den Grundlagen haben wir uns auch mit den ökonomischen Aspekten beschäftigt. Usability rechnet sich nämlich. Wir haben den Return On Investment hinsichtlich folgender Dimensionen beleuchtet:
Durch die Dynamisierung der Schutzmaßnahmen kann man auch einer heterogenen Risikolage Herr werden. Bei gleichem Investment kann das Sicherheitsniveau und damit der Return On Investment signifikant gesteigert werden. Dieser Artikel basiert darauf, dass wir uns der Risikolage eines Unternehmens von den Prozessen her nähern: Kostenreduzierung durch prozessbasierte Risikoanalyse.
Zu oft ist die genaue Risikolage eines Unternehmens nur unzulänglich bekannt. Man weiß, dass die Anlagen des Unternehmens einem Risiko unterliegen. Schließlich sind technische Einrichtungen in ihrer Gesamtheit immer irgendwie gefährdet. Wo aber genau die Risiken liegen und welcher Art diese sind, ist oft unklar. Daher wird dem allgemeinen Risiko mit einer großen Feuerpatsche entgegen getreten. Oder lassen Sie es mich anders ausdrücken: Das Unternehmen breitet über den gesamten Anlagenpark eine gleichbleibend stabile (oder eher instabile) “Feuerdecke” aus.
XING bietet eine sehr interessante Powersuche. Sie stellt neben der Erweiterten Suche ein gutes Akquisemittel dar. Leider ist diese Kernfunktionalität sehr versteckt. Noch ein Hinweis: Nachrichten an Mitglieder, mit denen man nicht direkt verbunden ist, können als Spam betrachtet werden. Also mit Bedacht nutzen!
XING ist ja unbestritten im deutschsprachigen Bereich die Business-Plattform. Nach dem letzten Redesign hat sich am äußeren Erscheinungsbild viel getan. Es sind aber auch neue Funktionen hinzugekommen. Sehr begrüßenswert finde ich die sogenannte Powersuche. Sie soll dem Anwender helfen, andere Mitglieder zu finden, die…
In two preceding articles (Cost cutting by process based risk analysis – Part 1 and Part 2) I have described a process based method that helps us to identify mission critical activities und sub processes. The idea is to find a way that enables us to focus our protective measures on the technical equipment, which is involved in those critical activities. Thereby, we could reduce measures to those sensitive entities rather than protecting any equipment around our premises.
As I was asked for an end-to-end example several times I designed a small process, which is about controlling a business premises of a small refinery. This company has three risks to take care of. In case it happens (not very likely, though) a fire is a massive danger because it could destroy the entire company. An accident regarding an oil leakage is much more probable to happen. But let us assume that the company is able to handle it on its own. Therefore, the severity is not too high. As the company secures its premises with a fence, which is electronically controlled, we will have to manage alarms of that kind as well. This process is located at the central guard duty, which is operated by the company.
Please, consider this as an example. I know it lacks real world’s complexity. No refinery will work that simply. But, as I said, this is only a construct to provide an understanding of this approach. Weiterlesen
In the first part of this process based risk analysis example we have identified risky activities and separated them from the activities that we consider to be at no risk. Now we will inspect the remaining endangered activities in more detail. We want to find out, which technical entities are involved and what their technical risk is. The intention is to identify technical entities that we have to protect and to separate entities that we may ignore. That gives us the capability to reduce the amount of protective measures. The result will be a list of sensitive key entities and their technical risk.
We have identified three critical activities so far: Alarm company’s fire fighters, alarm city fire department and alarm company’s security service. If those activities cannot be performed properly our company has a serious problem.
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. Weiterlesen
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.
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.
Our world depends on technology almost entirely. One will have to say: Our life does not go smoothly without technical equipment and devices. That said, we must protect those devices against a various number of risks or threats. That is expensive and costly. At present risk analysis is mainly focussed on technical boxes. Every single device is protected against any risk you can think of. At least they try to do so. In the following I will sketch an approach that narrows towards the problem from the business processes point of view rather than hardware.
In that context I wonder whether there is a way to cut down costs of protective measures. What, if we could minimize areas to be protected? What, if we could decrease the number of areas to be protected? We would have to protect only one single room rather than the entire house. We would have to protect only ten houses instead of twenty. I think, the costs of our protective measures would drop dramatically.
With this process oriented approach I do not look at all technical components and their risk factors. Instead of that, I filter those parts of the process that are really important. And only the technical components that are involved in those parts have to be guarded – by all means possible. Weiterlesen
In Part 1 of this process based risk analysis approach I have described, how we rate the risk of the processes. Now we know which parts are potentially endangered – activities, sub processes and throwing events. In the second part of this article we will come towards the technical components affecting by a detailed view into these very activities.
To achieve a better overview, now, we use our modelling software to generate a report over all activities that we have identified throughout the entire universe of our processes. A list in descending order based on the process risk is apparently useful. Thus, you will find the most risky activities at the top of the list. Let us start to analyse those in detail.
Use Cases gehören zum Alltag der IT. Kein größeres Projekt kommt ohne sie aus. Die ganze Welt schreibt Use Cases. Wirklich? Dass ich diesen Artikel schreibe, mag erkennen lassen, dass ich da meine Zweifel habe. Meine These: Viele sogenannte Use Cases sind gar keine. Ich möchte im Folgenden darstellen, wie ich dazu komme. Da das Thema umfangreich ist, teile ich die Betrachtung in zwei Artikel auf:
Der Begriff Use Case lässt sich im Deutschen am besten mit Anwendungsfall übersetzen. Hier passt die wortgetreue Übersetzung sogar ganz gut. Ein Use Case beschreibt, wie ein Nutzer (Aktor) mit einem System in Interaktion tritt, um ein bestimmtes Ziel zu erreichen. Wenn ich hier vom Erreichen eines Ziels spreche, so steckt dahinter zweifelsohne eine Intention. Und die können nur Menschen bzw. Gruppen von Menschen haben. Genau genommen können Use Cases aber auch die Interaktion zwischen verschiedenen Systemen beschreiben. Diese spezielle Form von Use Cases möchte ich hier nicht diskutieren. Mir geht es an dieser Stelle ausschließlich um die Use Cases, die beschreiben, wie ein menschlicher User mit einem System interagiert, um ein fachliches Ziel zu erreichen. Warum ich das fachliche Ziel hervorhebe, lege ich später dar. Weiterlesen
Linen Theme by The Theme Foundry
Copyright © 2012 Bernd Lohmeyer. Alle Rechte vorbehalten.
