Beiträge

End-to-end example of process based risk analysis – Part 2

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.

Entities involved in activities

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.

Weiterlesen

Teile diesen Beitrag:

Cost cutting by process based risk analysis – Part 1

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

Teile diesen Beitrag:

Cost cutting by process based risk analysis – Part 2

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.

Detailed view on 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.

Weiterlesen

Teile diesen Beitrag:

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. Weiterlesen

Teile diesen Beitrag:

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.

Weiterlesen

Teile diesen Beitrag:

Use Cases Teil 1: Nutzerziele und fliegende Fische

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:

  1. Differenzierung zwischen Nutzerziel und Unterfunktion.
  2. Wie beschreibe ich ein Nutzerziel (Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem).

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

Teile diesen Beitrag:

Use Cases Teil 2: Pure Fachlichkeit ist keine Lösung – aber ein gutes Problem

Im ersten Teil über Use Cases habe ich dargestellt, dass die richtige Differenzierung zwischen Nutzerzielen und Unterfunktionen nicht ganz leicht aber überaus wichtig ist (Use Cases Teil 1: Nutzerziele und fliegende Fische). Erhebt man Unterfunktionen zu vermeintlichen Nutzerzielen, verlieren wir nicht nur den Überblick, das Projektmanagement kann sogar in große Schwierigkeiten geraten.

Da uns dies (hoffentlich) nicht mehr vorkommt, stellt sich nun die Frage, wie man denn Nutzerziele am besten formuliert. Wie ich schon schrieb, werden da häufig Fehler gemacht. Im Folgenden möchte ich ein paar Tipps geben, wie man diese umgeht.

Lösungs-fixiert?

Weiterlesen

Teile diesen Beitrag:

Was ein gutes Produkt ausmacht: Nutzen + Nutzbarkeit

Im Folgenden möchte ich das Zusammenspiel zwischen Nutzen und Nutzbarkeit, Funktion und Usability, WAS und WIE darstellen. Und letztendlich wird auch noch klar, warum ich „Nutzen zentrierte IT-Beratung“ anbiete.

Usability

Usability gewährleistet, dass ein gestecktes Ziel intuitiv und effizient erreicht wird. Das heißt aber noch nicht, dass das gesteckte Ziel auch den Anforderungen des Nutzers entspricht.

Glücklicherweise tritt die Nutzbarkeit eines Dings / einer Software immer mehr in den Fokus der Betrachtung. Wir sprechen von der Usability oder Nutzbarkeit einer Software. Und wir meinen damit, dass der Nutzer das Produkt gut und intuitiv bedienen kann. Dieser Aspekt ist viel zu lange ignoriert worden. Und wir alle kennen Software-„Lösungen“, bei deren Einsatz sich der Anwender sehr schwer tut – mit allen Konsequenzen wie hoher Fehlerrate, mangelnder Produktivität und Torpedierung der Kundenbindung. Heutzutage ist klar, dass die Nutzbarkeit (Usability) ein unverzichtbares Qualitätskriterium einer Lösung darstellt.

Bei der sehr engagierten Konzentration auf die Nutzbarkeit wird meines Erachtens häufig vernachlässigt, dass eben diese nur eine Seite der Erfolgsmedaille ist. Stellen wir uns folgendes vor: Weiterlesen

Teile diesen Beitrag:

Philippe Back spricht mit Bernd Lohmeyer: Nutzen zentrierter Beratungsansatz und Usability

Philippe Back hat mit mir ein Interview über meinen Nutzen zentrierten Beratungsansatz geführt. In dem Gespräch versuche ich darzustellen, wie ich Unternehmen durch die Kombination von Geschäftsprozessanalyse und Usability helfe, ihre Kundenbindung und die Produktivität ihrer Mitarbeiter zu steigern. Dadurch lassen sich enorme Optimierungspotenziale hinsichtlich des Return On Investment (ROI) entwickeln und ausschöpfen.

Ein paar Stichpunkte:

  • Konzentriere Dich zuerst auf die wirklichen Geschäftsanforderungen.
  • Finde dafür Lösungen, die die Anforderungen erfüllen und einfach zu bedienen sind.
  • Stelle mit Usability Tests sicher, dass das Design wirklich einfach zu bedienen ist.

Weiterlesen

Teile diesen Beitrag: