Archiv der Kategorie: Business Analyse

Ein Bauplan der funktionalen Architektur des BABOK 3.0

Bauplan der funktionalen Architektur der BABOK AufgabenDer BABOK® Guide (Guide to the Business Analysis Body of Knowlegde®) des International Institut of Business AnalysisTM ist sicherlich das international anerkannte Standardwerk für Business Analysten, Systemanalysten und Anforderungsmanager. In seiner Version 3.0, die im April dieses Jahres veröffentlicht wurde, werden 30 unterschiedliche Aufgaben eines Business Analysten sehr strukturiert und ausführlich beschrieben. Die Aufgaben sind in sechs Wissensgebieten zusammengefasst.

Für jede Aufgabe ist ausführlich dargestellt,

  • wozu sie gebraucht wird
  • was der Inhalt der Aufgabe ist
  • welche Inputs gebraucht werden und welche Outputs entstehen
  • welche Leitfäden und Werkzeuge genutzt werden können
  • welche Techniken zu der Aufgabe passen
  • und welche Personengruppen beteiligt sind.

30 unterschiedliche Aufgaben sind ganz schön viel. Ich habe bisher in meiner Praxis noch nicht erlebt, dass in einem Projekt alle diese Aufgaben wirklich umgesetzt wurden. Zumindest nicht explizit.

So klar und ausführlich die einzelnen Aufgaben auch beschrieben sind, mir hat jedoch eines gefehlt: der Überblick, wie diese Aufgaben zusammen wirken. Schließlich machen die Aufgaben isoliert keinen Sinn. Sie sind über ihre Eingaben und Ausgaben miteinander vernetzt und bilden gemeinsam das System Business Analyse. Doch wie sieht dieses System aus? Im BABOK gibt es in der Einleitung eine Grafik, die auf sehr abstrakter Ebene Beziehungen zwischen den Wissensgebieten skizziert. Diese Grafik ist allerdings sehr allgemein gehalten und war mir nicht aussagekräftig genug, um einen fundierten Überblick zu bekommen. Diese Flughöhe war mir zu hoch.


“Ein Bauplan der funktionalen Architektur des BABOK 3.0” weiterlesen …

Hey Joe, Dr. No und das Business Model Canvas

Unüberdachte Anforderungen an die IT führen zu Frustration und BlockierenKennen Sie Hey Joe und Dr. No? Fachbereiche wünschen sich oft einen Hey Joe in der IT-Abteilung. Jemanden, den man unkompliziert anfragen kann: „Hey Joe, kannst Du nicht mal schnell …“.

Junge Mitarbeiter in der IT sind anfangs oft sehr eifrig und lassen alles fallen und liegen um ihrem Kunden seinen dringenden Wunsch zu erfüllen. Leider führt diese falsch gehandhabte Agilität zu oft dazu, dass die Fachbereiche sich zu wenig Gedanken über ihren wirklichen Bedarf machen. Die schnell mal so an die IT gestellten Anforderungen sind häufig unklar und leider meistens zu kurz gedacht. In der Folge sind teure und aufwändige Nacharbeiten erforderlich. Diese verschlingen Budgets, binden wertvolle Ressourcen und behindern in der Folge wirkliche Innovationen im Unternehmen, die für den Geschäftserfolg wichtig wären.
“Hey Joe, Dr. No und das Business Model Canvas” weiterlesen …

Gastartikel auf business24.ch: Hilfe! Wo ist eigentlich unser Problem?

Business24Probleme sind uns unangenehm. Deshalb sprechen wir nicht gerne darüber. In Veränderungsprozessen ist es aber wichtig, dass Probleme klar und offen angesprochen werden, ohne Schuldzuweisungen. Denn ohne ein gemeinsames Problemverständnis kann man auch nicht gemeinsam an einer Lösung arbeiten.

Lesen Sie dazu meinen Artikel auf business24.ch:
Hilfe! Wo ist eigentlich unser Problem?

Wie gehen Sie mit den Problemen um, die durch Projekte gelöst werden sollen?
Offen auf den Tisch oder lieber unter den Teppich?

Gastbeitrag bei microTOOL: Mit 80 km/h rückwärts aus dem Kontext gerissen

Herzlichen Dank an Michael Schenkel von microTOOL für die Möglichkeit einen Gastbeitrag im microTOOL-Blog zu platzieren:  Mit 80 km/h rückwärts aus dem Kontext gerissen

microTOOL ist ein Hersteller von Tools für Requirements Engineering, Softwareentwicklung und Projektmanagement und wird im Mai seine 25. Anwenderkonferenz halten. Ich bin sicher, die Vorträge werden wieder sehr interessant werden.

Anforderungen oder Erwartungen – woran wird ein Projektergebnis wirklich gemessen?

Woran werden Projektergebnisse gemessen?Wenn ein Unternehmen Veränderungen in seinen Geschäftsprozessen oder den unterstützenden IT-Systemen durchführen möchte, wird ein Projekt gestartet.  In Anforderungen wird präzise und eindeutig definiert, was in dem Projekt umzusetzen ist. Schnell kommen enorme Listen zusammen. Dabei ist es nicht von Bedeutung, ob die Anforderungen am Anfang des Projektes z.B. in Form eines Lasten- oder Pflichtenheftes spezifiziert werden oder in agilen Projekten iterativ als Backlog entstehen. Formal sind die Anforderungen ausschlaggebend für die vom Projekt zu erbringende Leistung und werden bei der Abnahme als Kriterium herangezogen. Aber wird im Unternehmen das Ergebnis des Projektes wirklich anhand dieser Anforderungen bewertet?
“Anforderungen oder Erwartungen – woran wird ein Projektergebnis wirklich gemessen?” weiterlesen …

Harte und weiche Faktoren einer Veränderung

Für erfolgreiche Veränderungen müssen die Ebenen der weichen und der weichen Faktoren ineinander greifenMarion Winners, Geschäftsführerin der Avenue GmbH, hat in ihrem Blog einen sehr lesenswerten Beitrag zur Zusammenarbeit von Change Management Beratung und Unternehmensberatung geschrieben: Best of both worlds – Change Management Beratung & Unternehmensberatung

Ein Absatz hat mich besonders zum Nachdenken gebracht: „All diese Gelingens-Bedingungen setzen das Bewusstsein des Auftraggebers voraus, dass eine Veränderung immer zwei Ebenen beinhaltet, die bei der Umsetzung berücksichtigt werden sollten. Neben den harten Fakten, der strukturellen oder prozessualen Umsetzung des Fachkonzeptes, unterstützen gerade die weichen Faktoren die Anpassung der Führungskräfteentwicklung und die vorherrschende Denke (Kulturentwicklung) für eine nachhaltige wirksame Stabilisierung des Zielbildes.“


“Harte und weiche Faktoren einer Veränderung” weiterlesen …

Hamburger IT-Kosten explordieren

Die IT-Kosten der Stadt Hamburg laufen drastisch aus dem RuderLaut der am 12.05.2014 im Hamburger Abendblatt und in der Welt erschienenen Artikel von Jens Meyer-Wellmann laufen die IT-Kosten der Stadt Hamburg drastisch aus dem Ruder. Meyer-Wellmann nennt beispielhaft Kostensteigerungen von bis zu 300% und Verzögerungen von über 10 Jahren. Im Schnitt würden sich die Projekte um 3,5 Jahre verspäten und 50% teurer als veranschlagt. Die Ursachen werden in der Planung gesehen: „Dabei zeigt sich, dass die Verspätungen und Kostensteigerungen bei Projekten mit sogenanntem Lastenheft geringer ausfallen als bei Vorhaben, die ohne Lastenheft umgesetzt wurden. „


“Hamburger IT-Kosten explordieren” weiterlesen …

Der Sache gerecht werden. Dann klappt es auch mit dem Projekt.

Das magische Dreieck des Projektmanagements: Das Sachziel ist meist nicht klar genug!

Das magische Dreieck des Projektmanagements ist jedem Projektleiter schon einmal untergekommen. Wer bei Google danach sucht, wird unterschiedliche Varianten finden. Mir persönlich gefällt die Variante am besten, die die konkurrierenden Ziele zeigt, die der Projektleiter unter einen Hut bringen muss:

  • Terminziel
  • Kostenziel
  • Sachziel

Termine und Kosten tauchen  in allen Varianten auf. Das Sachziel wird im IT-Umfeld häufig auf die Funktionalität der IT-Lösung reduziert. Das wird meiner Meinung nach der Sache jedoch nicht gerecht, um die es im Projekt geht.

Wo kommen die Wünsche nach Funktionalität her? Passen die Vorstellungen der Personen, die die Funktionalität definieren, überhaupt zusammen? Ist Funktionalität das Einzige, was man am Ende des Projektes erhält? Oder spielen Faktoren wie zukünftige Erweiterbarkeit, Anpassbarkeit, Verlässlichkeit auch eine Rolle?

“Der Sache gerecht werden. Dann klappt es auch mit dem Projekt.” weiterlesen …

Der Weg ist das Ziel …

„Die Modelle, die meine Kollegen erstellt haben, interessieren mich eigentlich nicht sehr.“ Diese Aussage eines CFOs hat mich vor kurzem etwas irritiert. Bisher war er mit den Prozessdarstellungen seiner Kollegen doch immer sehr zufrieden. „Die Modelle zeigen mir aber, dass meine Kollegen aus den unterschiedlichen Abteilungen intensiv zusammen gearbeitet und gemeinsam eine Lösung entwickelt haben. Da waren alle involviert. Die Kommunikation hat funktioniert. Darauf kommt es mir an. “

Ich kann ihm nur Recht geben. FMC-Lösungsarchitekturen sind immer ein Mittel zum Zweck. Der Nutzen ergibt sich aus dem, was beim Modellieren in den Teams passiert. Wobei die Modelle als solche im Sinne des Wissensmanagements natürlich auch einen hohen Wert haben.