Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Books on Demand
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
Die Business-Analyse ist eine zentrale Aufgabe bei der Entwicklung von Produkten oder Dienstleistungen. Diese Aufgabe wird in vielen Vorgehensmodellen durch die Rolle eines Business-Analysten oder Requirements Engineers wahrgenommen. Doch gerade im Kontext agiler Methoden und Frameworks verschiebt sich sowohl die Aufgabenstellung als auch die Anforderung an die Person(en), welche die Anforderungen an das zu erstellende Produkt erheben. Nicht nur verändern sich Anforderungen im Projektverlauf; es kommen neue hinzu, manche fallen weg oder werden verändert. Zunehmend wird auch mit Ansätzen gearbeitet, welche scheinbar nicht mehr mit der Idee eines Einzelnen oder einer kleinen Gruppe von Experten zu vereinen sind. Ansätze wie Design Thinking, Lean UX, Lego ® Serious Play ® oder Design Sprint werden immer häufiger eingesetzt, wenn es darum geht, Anforderungen zu erarbeiten und festzuhalten. In diesem Buch beschreibt der Autor, der seit Jahren selbst als Berater im Kontext agiler Business-Analyse tätig ist, die Herausforderungen, Vorgehensmodelle und eine mögliche Zukunft für die Rolle des Business-Analysten in einer sich zunehmend verändernden Welt.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 79
Veröffentlichungsjahr: 2021
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Anmerkung:
Prince2, DSDM, AgilePM u.a. sind eingetragene Warenzeichen. Für eine bessere Lesbarkeit wurden entsprechende Vermerke wie (™), © etc. im Buchtext weggelassen. Die entsprechenden Anmerkungen gelten aber stets als mit gemeint.
INHALT
Vorwort
Was ein Business-Analyst macht
Die Rolle des Business-Analysten
Business Analysis Process Model
Investigate Situation
Consider Perspectives
Analyse Needs
Evaluate Options
Define Requirements
Strategische Analyse
Die 4 Ps nach Mintzberg (1994)
SWOT-Analyse
Planning Onion (Planungszwiebel)
Techniken der Business-Analyse
Vision
Kano-Modell
Pet Projects & Communities of Practice
Observations
Prototyping
Funktionale und nicht-funktionale Anforderungen
Business-Analyse und -Projekt
Anforderungsmanagement beim “Wasserfall” und beim “agilen Kontext”
Verschiedene Projektvorgehensmodelle
Beispiel 1: Die Rolle des BA im Rahmen von DSDM®-Projekten
Beispiel 2: Die Rolle des BA im Kontext von Prince2™
Beispiel 3: Die Rolle des BA im Kontext von Scrum
Anforderungsmanagement
3C – Agiler Kontext und “Wasserfall”
Card
Conversation
Confirmation
Umsetzung von 3C im klassischen Kontext
User Storys
Beispiel 1: Agiles Anforderungsmanagement: der Product Backlog in Scrum
Beispiel 2: Die priorisierte Anforderungsliste (Prioritised Requirements List PRL) in DSDM ®
Definition of Done
Agile und nicht-agile Business-Analyse?
Die Methoden
Der Prozess / die Prozesse
Die Rollen
Business-Analyse und Führung
Design Thinking als agile Vorgehensweise in der Business-Analyse
Nachwort
Vorwort
Die Business-Analyse und die Rolle oder Aufgabe des Business-Analysten ist aus klassischem Projektmanagement nicht wegzudenken. In vielen Fällen kommt dem Business- Analysten die Aufgabe zu, das Pflichtenheft entweder selbst zu schreiben oder zumindest zu dessen Entstehung beizutragen.
Die Rolle des Business-Analysten soll dabei sicherstellen, dass die richtigen Anforderungen aufgenommen und schließlich umgesetzt werden können. Damit soll der spätere Nutzen und das Entstehen einer Lösung mit gutem Kosten-Nutzen-Verhältnis sichergestellt werden.
Obwohl dieser Rolle im Rahmen klassischer Projektmanagements eine so gewichtige Aufgabe zufällt – welche mit einem erheblichen Maß an Verantwortung gekoppelt ist – verfügen die wenigsten Menschen, welche diese Aufgabe wahrnehmen, auch über die dazu notwendige Ausbildung und Werkzeuge. Dies, obwohl es sogar ganze Ausbildungsgänge bis hin zur Master-Zertifizierung von verschiedenen Bildungsträgern und Zertifizierern gibt, wie beispielsweise der British Computer Society oder auch von Zertifizierern wie EXIN, welche hier ein weites Spektrum abdecken.
Eine Frage, welche ebenfalls von großer Unsicherheit geprägt ist, ist jene danach, wie die Rolle und Aufgaben eines Business-Analysten im Rahmen agiler Projekt-Vorgehensweisen organisiert wird. Ist doch auch da die Bedeutung, den Kundennutzen zu maximieren – indem unter anderem sichergestellt wird, dass an den richtigen Anforderungen gearbeitet wird – ein Kern-Versprechen.
Im vorliegenden Buch werde ich zunächst in die Rolle des Business-Analysten einführen und einige wichtige Vorgehensweisen und Prozesse im Rahmen seiner Aufgabe darstellen. Danach werden wir die Rolle im Rahmen verschiedener Methoden und Frameworks betrachten. Aus dem Bereich des “klassischen Projektmanagements” werden dabei Aspekte aus dem Kontext von Prince2 berücksichtigt, aus dem Bereich “agiles Projektmanagement” Aspekte der DSDM (Dynamic Systems Development Method), der wohl erfolgreichsten und vollständigsten agilen Projektmanagement-Methodik, und schließlich werden Aspekte von Scrum – als einem Framework, welches die Produkterstellung fokussiert, dabei aber keine vollständige Projektmanagement-Methodik darstellt – behandelt.
Darüber hinaus werden wir eine Business-Analyse im Zusammenhang mit Design Thinking und Lean UX betrachten – zwei Frameworks, die sich ebenfalls im Kontext von Business-Analyse und Produktentwicklung / Innovation ansiedeln.
Was ein Business-Analyst macht
In der Business-Analyse geht es darum, die Grundlage für eine Veränderung zu schaffen, indem Anforderungen, basierend auf den Bedürfnissen und dem Nutzen des Kunden, definiert werden.
Diese Aufgabe wird oft durch eine interne Fachperson durchgeführt, welche eine Art interne Beraterrolle einnimmt. Daneben kommen auch immer wieder externe Berater zum Einsatz, wenn es darum geht, Anforderungen zu erheben und formulieren.
Typische Aufgaben eines Business-Analysten bestehen darin, die aktuelle Situation zu analysieren und darauf basierend Optionen für Veränderungen zu identifizieren und zu evaluieren. Diese Evaluationen bieten die Grundlage für die Verbesserung der Ist-Situation mit dem Ziel einer Erfüllung von Business-Anforderungen und -Nutzen. Dabei gilt es die bestehenden Rahmenbedingungen in Hinblick auf Zeit, Kosten, Qualität und zur Verfügung stehende Ressourcen zu berücksichtigen.
Sie erhalten einen guten Einblick in BA im Kontext von agilen Umgebungen, aber auch in die Wichtigkeit und Nützlichkeit entsprechender Kompetenz im Rahmen von Projektmanagement und Produktentwicklung.
Beste Grüße
Der Autor
Die Rolle des Business-Analysten
Die Aufgaben eines Business-Analysten sind mannigfaltig und in unterschiedlichen Unternehmen und unterschiedlichem Kontext verschieden ausgeprägt. Zu den Aufgaben gehören:
Probleme und Chancen erkennen
Anforderungen ermitteln und dokumentieren
Verschiedene Lösungsansätze festhalten und evaluieren
Lösungsoptionen testen
Lösungen implementieren
Den Nutzen und die erzielte Erfüllung der Anforderungen festhalten – auch über die Grenzen des Umsetzungsprojektes hinaus.
Dies erfordert Menschen, welche als Generalisten breit aufgestellt sind und fähig sind, über den Tellerrand zu schauen. Aber sie sollten auch als Spezialisten in einigen Bereichen in die Tiefe vordringen können, um Zusammenhänge zu verstehen und darauf basierend neue Möglichkeiten zu formulieren. Um diesen Anforderungen gerecht zu werden, ist sowohl das Vorhandensein von analytischen Fähigkeiten als auch eine gute Kommunikation mit den verschiedenen Anspruchsträgern und Spezialisten notwendig.
Dabei nimmt der Business-Analyst auch eine Übersetzerrolle ein. Er muss sicherstellen, dass von Fachabteilung und Spezialisten formulierte oder mit ihnen abgestimmte Anforderungen so formuliert und übermittelt werden, dass diese auch von den Entwicklern verstanden werden. Oft stellt man fest, dass beide “Bereiche” eine völlig unterschiedliche Sprache nutzen. Die Business-Language der Fachabteilung ist oft mit Begrifflichkeiten aus deren Fachgebiet durchsetzt. Entwickler dagegen haben oft einen im Kontext ihrer Entwicklungstätigkeit eingesetzten technischen Sprachgebrauch.
Um seine Aufgaben zielführend wahrnehmen zu können, muss der Business-Analyst die Ziele und Herausforderungen des Unternehmens verstehen und dabei seinen Blick auch über die aktuelle Situation hinaus auf die von der Unternehmung formulierten strategischen Weiterentwicklungen richten. Dabei kann er – je nach seiner Position und Aufgabenstellung – auch in die Entwicklung der Unternehmensstrategie eingebunden sein. In der Zusammenarbeit mit den verschiedenen Stakeholdern muss er die Umsetzung dieser Strategien vorantreiben und überwachen.
Abhängig von den weiterführenden Fähigkeiten, aber auch von den Erfordernissen und Rahmenbedingungen von Unternehmen kommen Business-Analysten in unterschiedlichem Kontext zum Einsatz, was sich auch durch eine Vielzahl von Stellenbezeichnungen zeigt. Dazu gehören beispielsweise “Business Process Analysten”, “Requirements Analyst”, “System Analyst”, “Data Analyst” oder “User Experience Analyst”. Im Kontext von Scrum werden Business-Analysten auch sehr gerne in der Rolle eines “Product Owner” eingesetzt. Natürlich sind für die verschiedenen Aufgabenstellungen in der Praxis oft auch weiterführende Kenntnisse und Fähigkeiten notwendig, welche der Business-Analyst, soweit er sie nicht schon besitzt, erwerben muss.
Business Analysis Process Model
Das Business Analysis Process Model geht auf die British Computer Society (BCS) zurück. Es stellt ein fünfstufiges Modell zur Definition von Anforderungen dar.
Investigate Situationn
In dieser Phase geht es darum, zunächst den Projektumfang zu definieren und dabei die Rahmenbedingungen und das Umfeld, in dem das Projekt durchgeführt wird, zu verstehen. Hier wird die Grundlage für die weiteren Schritte gelegt. Werden diese nicht richtig durchgeführt, besteht das Risiko, dass darauf aufbauende weitere Schritte entweder nicht wirklich das angestrebte Ziel verfolgen oder aber nicht zu zielführenden Ergebnissen kommen, weil beispielsweise bestehende Beschränkungen oder Rahmenbedingungen nicht ausreichend berücksichtigt wurden.
Daneben ist in dieser Phase auch entscheidend, dass die beteiligten Personen und Stellen zu einer gemeinsamen Sprache und einem gemeinsamen Verständnis zu den genannten Positionen kommen. Oft stellt man fest, dass Personen, die in einem Projekt zusammenarbeiten, bereits in dieser frühen Phase – basierend auf ihren Erfahrungen und Ausbildungen – ein sehr unterschiedliches Bild der Situation haben und dabei quasi nur den in ihrem Kontext stehenden Aspekt der Herausforderung wahrnehmen. Dies führt später zu einer Herausforderung in Hinblick auf ein Alignment der beteiligten Personen.
Typische Mittel und Werkzeuge in dieser Phase sind:
Workshops
Shadowing – sowie weitere Methoden, bei denen die Anwender der Ist-Situation beobachtet werden
Interviews
Mindmaps
Consider Perspectives
In der zweiten Phase geht es darum, sich unterschiedliche Perspektiven anzusehen. Beteiligte und Betroffene werden womöglich unterschiedliche Vorstellungen von den zu erreichenden Zielen haben. Dazu gehört auch, dass wir feststellen, welche Stakeholder überhaupt existieren und welche Ziele und Anforderungen sie haben. Dabei gilt es auch zwischen den verschiedenen, sich womöglich widersprechenden oder stark voneinander abweichenden Vorstellungen zu vermitteln oder abzuwägen.
Methoden und Werkzeuge in dieser Phase sind beispielsweise:
Stakeholder-Analyse
Produkt-Struktur-Analyse
Kontext-Diagramme
Analyse Needs
Anschließend werden die Bedürfnisse der Zielgruppe/n analysiert. Dabei können auch weitere Aspekte und Bedürfnisse eine Rolle spielen. Dazu gehört zum Beispiel die strategische Ausrichtung des Unternehmens oder Bereichs. Anforderungen werden miteinander verglichen und gegeneinander evaluiert, bestehende Business Rules und Policies werden berücksichtigt und schließlich soll gemeinsam dargestellt werden, was bereits erreicht wurde und was es noch zu erreichen gilt (Gap Analysis).
Evaluate Options
In dieser Phase werden verschiedene Optionen für eine Umsetzung genauer betrachtet. Zum einen besteht immer die “Null-Option”, also die Möglichkeit, nicht aktiv zu werden. Sie bildet einen wichtigen Vergleichswert in Bezug auf die Nützlichkeit von Alternativen.
In vielen Projekten scheint der Lösungsweg schon festzustehen, noch bevor das Problem ganz erfasst wurde. Alternativen werden oft kaum beachtet, was das Risiko umfasst, dass möglicherweise bessere (günstigere, schnellere, nützlichere) Lösungen nicht berücksichtigt werden. Auch wird oft zu wenig evaluiert, inwiefern Lösungen einen Fortschritt oder Mehrwert gegenüber der “Null-Option” bringen und ob diese Lösungen durch die zu erwartenden Kosten und Risiken gerechtfertigt sind.
In diese Phase gehört auch eine Machbarkeitsprüfung (Feasibility Study). Dazu gehören sowohl der Aspekt der Sinnhaftigkeit und Umsetzbarkeit aus Business- / oder Auftraggebersicht als auch die technische Realisierbarkeit und die sich daraus womöglich ergebenden Risiken.
