Beiträge

Das Buch: UX für Führungskräfte – Besser führen, entspannter leben

In Kürze

Bernd Lohmeyer hat sein erstes Buch veröffentlicht: UX für Führungskräfte – Besser führen, entspannter leben. Das Buch stellt UX in einem übergreifenden Zusammenhang dar. Es richtet sich insbesondere an Führungskräfte, die einen neuen Denkansatz kennen lernen möchten. Dabei erleben sie nicht nur die Bedeutung von UX und deren zugrunde liegende Denkweise in Bezug auf innovative Services und digitalen Wandel. Sie erfahren darüber hinaus auch, was sie für das persönliche Leben als Entscheider und Führungskraft von UX-Strategien ableiten können. Und wer sagt eigentlich, dass man Unternehmenskultur nicht genauso wie ein Killer-Produkt gestalten kann?

Die Qualität der Services drückt die Wertschätzung aus, mit der wir den Menschen begegnen.

Aus dem Vorwort

Weiterlesen

Teile diesen Beitrag:

Open Space – Stammtisch Hamburg

Mit der Open Space – Methodik geben Sie Ihrem Thema neuen Wind.

Haben Sie ein Thema, dass Ihnen unter den Nägeln brennt? Haben Sie keine Ahnung, wie Sie das angehen sollen? Dann besuchen Sie doch mal eine solche Veranstaltung in Ihrer Nähe. Stellen Sie Ihr Thema zur Diskussion. Sie werden sich wundern, mit wie viel neuen Ideen und Anregungen Sie nachhause gehen.

Alexander Schilling, Berater für Brand, Design und Change, hatte in den Räumlichkeiten von eparo zum Open Space-Stammtisch Hamburg eingeladen.

Open Space – Methodik

Weiterlesen

Teile diesen Beitrag:

Use Cases richtig schreiben: White Paper zum Download

Use Cases begegnen uns in fast allen IT-Projekten. Besonders größere Vorhaben kommen ohne sie nicht aus. Dieses White Paper beleuchtet einige Aspekte der Use Case-Modellierung für Fachanwendungen.

Use Cases richtig schreiben

Das Thema Use Cases begegnet uns in unseren Projekten immer wieder. Leider gibt es darum häufig viel Ärger und Missverständnisse: Die Menge der Use Cases ufert aus und wird unübersichtlich. Viele Use Cases sind unverständlich geschrieben und werden schlichtweg nicht gelesen.

Das muss nicht sein! Ich habe ein White Paper erstellt, indem ich Antworten gebe auf die folgenden Fragen: Weiterlesen

Teile diesen Beitrag:

Poster download: Over-all product flow

You can write books and books about all the artifacts your project members are supposed to produce. And there are thousands of them out there. Such a document could be even another product of your project. But -hand on heart- will anyone care? I thought it might be better designing a poster. It shows the product flow on a high level. According to the feedback I got so far from the business users they like it. It helps them to understand the meaning of their contribution in terms of the big picture. OK, that was my intention.

Download poster

Click image to download over-all product flow (pdf-file, 1,1 MB)

Download poster (pdf-file, 1,1 MB)

Weiterlesen

Teile diesen Beitrag:

Tool Set für Fachspezifikation: Alles von Anforderungen bis Aktivitäten

Eine Fachspezifikation beschreibt die fachlichen Anforderungen und Probleme, die es in einem Projekt zu lösen gilt. Es ist nicht notwendigerweise ein einziges großes Dokument. Ganz im Gegenteil: Es ist sehr viel sinnvoller, die verschiedenen Aspekte in unterschiedlichen Dokumenten und Modellen zu beschreiben.

Im Folgenden möchte ich eine Werkzeugpalette vorstellen, die meines Erachtens alle Mittel bereitstellt, um auch komplexe Zusammenhänge verständlich zu beschreiben. Es ist eine Kombination aus Textdokumenten, BPMN und UML. Wenn ich sage „verständlich beschreiben“, meine ich, dass die Dokumentation von den Projektbeteiligten verstanden werden muss. Das schließt die Auftraggeber und Fachabteilung gleichermaßen ein wie Designer und IT-Architekten. Denn nur, was verstanden wird, kann auch umgesetzt werden. Fehlt es an einer breiten Verständnisbasis, sind einerseits die Ziele unklar. Andererseits wäre es somit purer Zufall, wenn die Projektergebnisse (z.B. eine Software-Lösung) die ursprünglich erhobenen Anforderungen erfüllen.

Die folgenden Modelle und Dokumente müssen nicht in der hier vorgestellten Reihenfolge erstellt werden. Sie entstehen häufig parallel. Bei der Arbeit an einem Teil ergeben sich Aspekte, die Auswirkungen auf andere Modelle / Dokumente haben. Und nicht immer braucht man in jedem Projekt alle hier beschriebenen Artefakte. Man muss also immer wieder prüfen, was wirklich erforderlich ist. Es gilt: So wenig wie möglich, so viel wie nötig. Weiterlesen

Teile diesen Beitrag:

Bessere Risikoprävention durch dynamische Schutzmaßnahmen

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.

Ausgangslage

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.

Weiterlesen

Teile diesen Beitrag:

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

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

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:

Das Eiserne Dreieck: Ignorieren auf eigene Gefahr

In einem kurzen Video spricht Philippe Back über die drei Aspekte im Projektgeschäft. Das Video ist in Englisch. Ich möchte den Beitrag allen Projektmanagern wärmstens empfehlen. Wenn es im Projekt schief geht, ist das Eiserne Dreieck vermutlich missachtet worden. Ich möchte Philippes Vortrag kurz zusammenfassen.

Die drei Ecken (Aspekte) sind:

  • Scope (also das, was vom Projekt geleistet werden soll)
  • Qualität
  • Zeit

Weiterlesen

Teile diesen Beitrag: