Ich möchte lernen, wie man die richtigen Fragen stellt.
Diese Antwort höre ich oft in meinen Trainings, wenn ich in der Vorstellungsrunde frage, was Teilnehmer von einem Business Analyse Kurs erwarten. Das ist nachvollziehbar, denn auch ich stehe als Business Analyst regelmäßig vor der Herausforderung, eine Lösung in einem Geschäftsumfeld finden zu müssen, in dem ich nicht alle Details kenne – manchmal sogar, wenn mir kaum mehr als die Überschrift des Themas genannt wird. Um die nötigen Informationen zu finden, muss man die richtigen Fragen stellen. Aber wie?
Ehrlich gesagt wusste ich lange Zeit nicht, was ich darauf antworten sollte. Kurz schöpfte ich Hoffnung, als ich im Buch Business Analysis for Practitioners: A Practice Guide (Project Management Institute, 2015) ein Kapitel mit der Überschrift „How to Ask the ‘Right’ Questions“ fand (siehe 4.5.2.2). Die Antwort lautete:
The right question is not known until after the question is answered and analyzed.
WAS? „Die richtige Frage ist erst bekannt, nachdem sie gestellt und die Antwort analysiert wurde.“ Ist das nicht ein Henne-Ei-Problem? Wie soll man wissen, was man fragen muss, wenn man die Antwort noch nicht kennt und deshalb nicht wissen kann, ob es die richtige Frage war?
Die gute Nachricht: Struktur hilft! Man hat keine Garantie, dass jede Frage die richtige ist, aber mit der richtigen Struktur steigt die Wahrscheinlichkeit, zielgerichtet die passenden Informationen zu erhalten. Analyse ist nämlich ein iterativer Prozess aus Fragen, Analysieren und Nachhaken. Hier kommt die Anforderungshierarchie des IIBA (International Institute of Business Analysis) ins Spiel, die wie ein Kompass den Weg durch diesen Prozess weist.
Die IIBA-Anforderungshierarchie: Ein Leitfaden für gezielte Fragen
Der IIBA schlägt eine Anforderungshierarchie vor, die mir in meiner täglichen Arbeit als Business Analyst Orientierung gibt. Sie unterteilt Anforderungen in drei Ebenen: Business Requirements, Stakeholder Requirements, Solution Requirements.
Jede Ebene hat ihren Fokus und erfordert spezifische Fragen, die Business Analysten helfen, systematisch vorzugehen. Schauen wir uns die Ebenen und die dazugehörigen Fragen an:
1. Business Requirements: Das große „Warum“
Business Requirements beschreiben die übergeordneten Ziele einer Initiative. Sie beantworten die Frage: Warum machen wir das überhaupt? Was wollen wir damit erreichen? Diese Ebene ist strategisch und gibt allen Beteiligten Orientierung.
Beispiele für Fragen:
Eine Möglichkeit, Business Requirements zu dokumentieren, ist ein sogenannter „Elevator Pitch“ – eine kurze, prägnante Erklärung, die man jemandem im Aufzug geben könnte. Ein Beispiel aus einem vergangenen Projekt (aus Vertraulichkeitsgründen verallgemeinert):
„Terminmanagement Neu“ ist eine IT-Lösung, mit der Mitarbeiter in der Hotline, an der Verkaufsstelle, im Backoffice, im technischen Außendienst, sowie Kunden selbst über eine Online-Plattform relevante Liefer- und Servicetermine initial vereinbaren, nachträglich anpassen oder ändern können. Die Termininformation wird automatisch an die benötigten Stellen und Systeme weitergeleitet.
Das Ziel ist, die Terminvereinbarungsquote bei Bestellungen von 60 % auf mindestens 80 % zu erhöhen. Erwartete Vorteile sind die Reduktion von Stornos, ein frühzeitiges Erkennen potenzieller Stornos (es besteht eine hohe Korrelation zwischen mangelnder Terminvereinbarung und späterem Storno), die Entlastung des Dispatchings und eine bessere Ressourcenplanung im technischen Außendienst.
Klar und offen kommunizierte, mit Stakeholdern abgestimmte Business Requirements helfen, den Umfang der Initiative zu managen, da alle an derselben Vision arbeiten.
Meine Tipps:
Fehlende Business Requirements führen oft dazu, dass Stakeholder unterschiedliche Vorstellungen von der Lösung haben, was unweigerlich zu späteren Konflikten führt.
2. Stakeholder Requirements: Das „Was“ der Nutzer
Stakeholder Requirements beschreiben, was verschiedene Stakeholder (z. B. Endnutzer, Manager, IT-Teams) von der Lösung erwarten. Diese Ebene fokussiert sich darauf, was Stakeholder tun müssen, um die Business Requirements zu erfüllen, und impliziert die Frage, wer die Stakeholder sind.
Beispiele für Fragen:
Beispiele für Stakeholder Requirements, passend zum den obigen Business Requirements:
- User müssen eine Liste möglicher Termine ermitteln können, wenn sie Bestellungen mit Terminvereinbarung erfassen.
- User müssen aus den angebotenen Terminen einen auswählen und als Teil der Bestellung speichern können.
- Kunden müssen in der Bestellbestätigung über den vereinbarten Termin informiert werden.
- Kunden müssen den Termin ihrer Bestellung auf der Online-Plattform einsehen können.
- Kunden müssen ihre Erreichbarkeitsdaten (Telefon, E-Mail) bearbeiten können.
- Kunden müssen eine Terminerinnerung per SMS erhalten können.
Mein Tipp:
3. Solution Requirements: Das „Wie“ der Umsetzung
Solution Requirements spezifizieren, wie die Lösung funktionieren soll. Sie unterteilen sich in funktionale (was die Lösung tut) und nicht-funktionale Anforderungen (Rahmenbedingungen und Qualitätsansprüche). Diese Ebene ist detailliert und richtet sich an Entwickler und technische Teams.
Solution Requirements werden aus den Stakeholder Requirements durch Analyse abgeleitet und beschreiben die technische Architektur aus einer Überblicksperspektive. Der Business Analyst agiert hier als Brückenbauer zwischen Fachbereichen und Entwicklern. In einfachen Projekten mit einem einzigen betroffenen System mag dies unkompliziert sein, aber oft sind mehrere Systeme involviert, die zusammen das große Bild der Lösung ergeben.
Beispiele für Fragen:
Ein Beispiel für Solution Requirements im Projekt Terminmanagement Neu:
Das System für die Bestelleingabe muss die Schnittstelle zur Generierung von Vertragsschreiben erweitern, um folgende Daten zu übergeben:
- Vereinbarter Termin (falls vorhanden)
- Geschäftsfall-ID
- Erfasste Erreichbarkeitsdaten, d.h.:
- Name der Ansprechperson
- Mobilnummer der Ansprechperson
Mein Tipp:
Wie stellt man also die richtigen Fragen?
Um die richtigen Fragen zu stellen und die Anforderungshierarchie effektiv zu nutzen, hier einige Tipps aus meiner Erfahrung:
Bonustipp: Unsere Trainings bei der SkillsUpgrade Academy bieten praxisnahe Übungen in all diesen Bereichen!
Fazit: Struktur führt zu Klarheit
Die Kunst, die richtige Frage zu stellen, ist keine Magie – sie ist ein erlernbarer Prozess, der durch Struktur und Übung verbessert wird. Die IIBA-Hierarchie von Business, Stakeholder und Solution Requirements ist ein bewährtes Werkzeug, das dir als Business Analyst hilft, systematisch vorzugehen, Klarheit zu schaffen und Initiativen zum Erfolg zu führen. Wie oben erwähnt, finden wir die richtigen Fragen oft erst durch das Fragen selbst – doch mit der richtigen Struktur wird dieser Weg deutlich einfacher.
Möchtest du lernen, die richtigen Fragen zu stellen, Anforderungen präzise zu erheben und das passende Modell für jede Situation auszuwählen?
Buche ein Training bei der SkillsUpgrade Academy oder lerne uns in einem Impulsvortrag kennen, und starte Deine Reise zu mehr Klarheit und Erfolg in der Business Analyse!
Hast Du schon einmal erlebt, wie die richtige Frage einen Durchbruch im Projekt brachte? Teile Deine Erfahrungen in den Kommentaren oder kontaktiere mich direkt!