Business Analyst
Der Business Analyst strukturiert fachliche Komplexität.
Er übersetzt unklare Bedürfnisse, Prozesse und Rahmenbedingungen in überprüfbare, umsetzbare Anforderungen.
Ein guter Business Analyst reduziert Interpretationsspielraum – bevor er teuer wird.
1. Kurzdefinition
Ein Business Analyst (BA) klärt:
- Was ist das Problem?
- Wer ist betroffen?
- Welche Prozesse sind involviert?
- Welche Randbedingungen gelten?
- Wann gilt etwas als „fertig“?
Er sorgt dafür, dass Teams nicht Annahmen implementieren, sondern klare Anforderungen.
2. Was macht ein Business Analyst konkret?
2.1 Anforderungen strukturieren
- Fachliche Anforderungen präzisieren
- Widersprüche identifizieren
- Unklare Begriffe klären
- Annahmen explizit machen
- Nicht-Funktionale Anforderungen (NFRs) sichtbar machen
2.2 Prozesse analysieren
- Ist-Prozesse dokumentieren
- Schwachstellen identifizieren
- Soll-Prozesse modellieren
- Schnittstellen klären
Gerade bei Integrations- oder Legacy-Systemen ist das entscheidend.
2.3 Stakeholder moderieren
- unterschiedliche Interessen sichtbar machen
- Konflikte fachlich strukturieren
- Entscheidungsgrundlagen liefern
- Komplexität reduzieren
Der BA ist Vermittler – nicht Entscheider.
2.4 Akzeptanzkriterien definieren
- überprüfbare Kriterien formulieren
- Edge Cases berücksichtigen
- Business-Regeln explizit machen
- Testbarkeit sicherstellen
Unklare Akzeptanzkriterien sind eine Hauptquelle für Rework.
3. Was ein Business Analyst nicht ist
- kein Ersatz für den Product Owner
- kein Ticket-Schreiber
- kein Mini-Projektmanager
- kein technischer Architekt
- kein „Dokumentationsbeauftragter“
Ein BA strukturiert – er priorisiert nicht.
4. Wann ist die Rolle sinnvoll?
Ein Business Analyst ist besonders wertvoll bei:
- komplexen Geschäftsprozessen
- vielen Stakeholdern
- regulatorischen Anforderungen
- Legacy-Migrationen
- Integrationsprojekten
- fachlich komplexen Domänen
In kleinen, hochfokussierten Produktteams kann die Rolle durch PO + Senior Developer abgedeckt werden.
5. Schnittstellen der Rolle
PO / PM
- Abstimmung über Prioritäten
- Klarheit vor Umsetzung
- Risiko-Transparenz
Team
- Umsetzbare Anforderungen
- Reduktion von Interpretationsspielraum
- weniger Nacharbeit
Fachbereich
- Strukturierung von Bedarf
- Prozessanalyse
- Erwartungsklärung
6. Typische Reibungsfelder
BA vs. PO
Wer entscheidet – wer strukturiert?
BA vs. Entwickler
Detailtiefe vs. pragmatische Umsetzung
BA vs. Management
Dokumentationsaufwand vs. Geschwindigkeit
Wenn Rollen nicht klar getrennt sind, entstehen Doppelarbeit und Konflikte.
7. Business Analyst im Qualitätskontext
Stufe 1:
- oft nicht notwendig
Stufe 2:
- hilfreich bei wachsender Komplexität
Stufe 3:
- relevant für klare Anforderungen und geringere Rework-Rate
Stufe 4–5:
- essenziell für Traceability und regulatorische Nachweisbarkeit
Unklare Anforderungen sind einer der teuersten Qualitätsfehler.
Kernaussage
Der Business Analyst reduziert Unklarheit.
Er verschiebt Aufwand von:
„Nacharbeiten“
zu
„Vorher klären“.
Das wirkt langsamer – ist aber langfristig günstiger.