Grundlagen
Was macht ein Business Analyst?
Ein Business Analyst klärt, welches Problem ein Vorhaben lösen soll und welche Lösung dem Unternehmen tatsächlich nützt. Der Beitrag beschreibt Aufgaben, Ergebnisse und Abgrenzungen der Rolle.
4 Min. Lesezeit
Die Rolle im Kern
Ein Business Analyst sorgt dafür, dass ein Vorhaben das richtige Problem löst und dass die gewählte Lösung im Betrieb tatsächlich Nutzen bringt. Er arbeitet an der Schnittstelle zwischen Fachbereich, IT und Management und übersetzt Bedürfnisse in Anforderungen, die sich umsetzen, prüfen und priorisieren lassen. Der BABOK Guide des International Institute of Business Analysis (IIBA) beschreibt Business Analysis sinngemäss als Praxis, Veränderungen zu ermöglichen, indem Bedürfnisse definiert und Lösungen empfohlen werden, die für Stakeholder einen Wert schaffen.
Im Alltag heisst das: Ein Business Analyst klärt zuerst das «Warum» und das «Was», bevor andere über das «Wie» entscheiden. Oft begleitet er ein Vorhaben vom Projektanfang bis zur Einführung. Je nach Organisation heisst die Rolle auch Business Engineer, Fachanalyst oder IT-Business-Analyst.
Die zentralen Aufgaben
Die Aufgaben verschieben sich je nach Projektphase und Vorgehensmodell. Einige Tätigkeiten kommen aber in nahezu jedem Mandat vor.
Ausgangslage und Ziele klären
Am Anfang steht die Frage, welches Problem gelöst oder welche Chance genutzt werden soll. Der Business Analyst grenzt den Umfang ab, beschreibt den heutigen Zustand und formuliert gemeinsam mit den Verantwortlichen messbare Ziele. Ohne diese Klärung entstehen später Diskussionen über Anforderungen, die eigentlich Diskussionen über Ziele sind.
Stakeholder identifizieren und einbinden
Eine Stakeholder-Analyse zeigt, wer betroffen ist, wer entscheidet und wer die fachlichen Details kennt. Sie macht sichtbar, wessen Sicht noch fehlt und wo Interessen kollidieren. Der Business Analyst plant Interviews, Workshops und Reviews so, dass die richtigen Personen zur richtigen Zeit beteiligt sind.
Prozesse und Daten analysieren
Viele Anforderungen ergeben sich erst aus dem Verständnis der Abläufe. Der Business Analyst modelliert Ist- und Soll-Prozesse, etwa mit BPMN, und identifiziert Medienbrüche, Doppelerfassungen und unklare Zuständigkeiten. Ebenso wichtig sind die Daten: welche Informationen wo entstehen, wer sie pflegt und welche Systeme sie nutzen.
Anforderungen erheben, dokumentieren und priorisieren
Aus Zielen und Prozessen leitet der Business Analyst fachliche Anforderungen ab, zum Beispiel als Use Cases, als User Stories mit Akzeptanzkriterien oder als Geschäftsregeln. Er achtet darauf, dass jede Anforderung eindeutig, prüfbar und auf ein Ziel zurückführbar ist. Gemeinsam mit Product Owner oder Auftraggeber priorisiert er nach Nutzen, Risiko und Abhängigkeiten.
Lösungsoptionen bewerten
Nicht jedes Problem verlangt eine neue Software. Der Business Analyst vergleicht Optionen wie eine Prozessanpassung, die Konfiguration einer bestehenden Anwendung, Standardsoftware oder eine Eigenentwicklung und legt Vor- und Nachteile offen. Das Ergebnis ist eine Entscheidungsgrundlage. Die Entscheidung selbst trifft der Auftraggeber.
Umsetzung und Abnahme begleiten
Während der Entwicklung beantwortet der Business Analyst fachliche Fragen, klärt Abweichungen und führt Änderungen an den Anforderungen nach. Er arbeitet eng mit dem Testmanagement zusammen, damit die Testfälle die fachlichen Erwartungen abdecken. Nach der Einführung prüft er, ob die ursprünglichen Ziele erreicht wurden.
Typische Ergebnisse
Welche Artefakte entstehen, hängt vom Vorhaben und vom Vorgehensmodell ab. Häufig gehören dazu:
- Problem- und Zielbeschreibung mit Abgrenzung des Umfangs
- Stakeholder-Analyse und Kommunikationsplan
- Ist- und Soll-Prozessmodelle, etwa in BPMN
- Fachliches Glossar und Datenmodell
- Anforderungsspezifikation oder strukturiertes Product Backlog mit Akzeptanzkriterien
- Bewertung von Lösungsoptionen als Entscheidungsgrundlage
- Fachliche Abnahmekriterien als Grundlage für den Test
Die Dokumentation muss für die Beteiligten brauchbar sein. Ein laufend gepflegtes Backlog eignet sich dafür oft besser als ein umfangreiches Pflichtenheft.
Woran Sie gute Business Analysis erkennen
Die Ziele sind messbar formuliert, und jede Anforderung lässt sich auf ein Ziel zurückführen und testen. Fachbereich und IT verwenden dieselben Begriffe. Entscheidungen über den Umfang sind dokumentiert und begründet.
Abgrenzung zu anderen Rollen
In Projekten überschneiden sich Rollen. Eine klare Abgrenzung verhindert, dass Aufgaben doppelt erledigt werden oder liegen bleiben.
- Projektleitung: verantwortet Termine, Kosten, Ressourcen und Risiken. Der Business Analyst liefert ihr die fachliche Grundlage.
- Product Owner: verantwortet in Scrum den Wert des Produkts und die Reihenfolge im Product Backlog. Der Business Analyst unterstützt mit Analyse, Refinement und Akzeptanzkriterien, die Entscheidung bleibt beim Product Owner.
- Requirements Engineer: konzentriert sich auf das systematische Ermitteln, Dokumentieren, Prüfen und Verwalten von Anforderungen an ein System. Die Unterschiede beschreibt der Beitrag Business Analysis vs. Requirements Engineering.
- Lösungsarchitektur: entscheidet über die technische Umsetzung. Der Business Analyst beschreibt, was die Lösung fachlich leisten muss.
Scrum kennt die Rolle des Business Analyst nicht ausdrücklich. In agilen Teams ist sie dennoch verbreitet, häufig als Teil des Entwicklungsteams oder als enge Unterstützung des Product Owner. Auch SAFe sieht keine eigene Rolle dafür vor, die Tätigkeiten fallen aber auf mehreren Ebenen an.
Fähigkeiten, auf die es ankommt
Methodenkenntnis ist die Grundlage. Im Alltag entscheiden aber oft andere Fähigkeiten über die Qualität der Arbeit.
- Analytisches Denken: Zusammenhänge erkennen, Widersprüche aufdecken, Annahmen von Fakten trennen.
- Moderation: Workshops leiten und zu Ergebnissen führen, auch wenn Interessen auseinandergehen.
- Präzises Schreiben: Anforderungen so formulieren, dass Fachbereich, Entwicklung und Test sie gleich verstehen.
- Domänenwissen: die Fachsprache und die Regeln der Branche kennen, etwa im Versicherungs- oder Bankenumfeld.
- Neutralität: Optionen fair darstellen, auch wenn eine davon den Erwartungen einzelner Beteiligter widerspricht.
Als Nachweis der Methodenkompetenz gelten die Zertifizierungen des IIBA (ECBA, CCBA, CBAP) sowie für das Anforderungshandwerk der IREB CPRE. Ein Zertifikat ersetzt keine Projekterfahrung, schafft aber ein gemeinsames Vokabular im Team.
Business Analysis mit KOVALI
KOVALI unterstützt Unternehmen in der Schweiz bei der Business Analysis: von der Klärung der Ausgangslage über die Prozessanalyse bis zu Anforderungen, mit denen Entwicklung und Test arbeiten können. Mehr zum Vorgehen finden Sie unter Business Analysis & Requirements Engineering. Für ein erstes Gespräch über Ihr Vorhaben erreichen Sie uns über die Kontaktseite.
