In der Vergangenheit wurden die Aufgaben rund um Anforderungen von anderen Rollen ausgeführt, z.B. von
Organisatoren, die Änderungen an Aufbau- und Prozessorganisation in Unternehmen begleiten
IT-Koordinatoren, die als Bindeglied zwischen Fachabteilung und IT-Abteilung fungieren
Projektleitern, die sich neben anderen Aufgaben im Projekt um Anforderungen kümmern.
Auch Personen mit anderen Rollenbezeichnungen als „Business-Analyst“ übernehmen solche Aufgaben. Gebräuchliche Bezeichnungen sind zum Beispiel Requirements Engineer, Anforderungsmanager, Business Consultant sowie die schon erwähnten Organisatoren, IT-Koordinatoren und Projektleiter. Im Folgenden wird die Bezeichnung Business-Analyst genutzt, die verwandte Rollen mit einschließt.
Die folgende Abbildung G.02 fasst weitere Gründe für den Einsatz von Business-Analysten zusammen und nennt gebräuchliche Gegenargumente, auf die im Weiteren eingegangen wird.
| Pro Business-Analyse | Contra Business-Analyse |
| Fester und zentraler Ansprechpartner für Anforderungen | Zusätzlicher Aufwand (Zeit, Kosten, Ressourcen) |
| Qualitätssicherung der Anforderungen | Hohe Veränderungsrate der Anforderungen |
| Strukturiertes Vorgehensmodell | Externer Blick – keine Kenntnisse aus erster Hand |
| Kenntnisse aktueller Methoden | Keine operative Erfahrung |
| Hohes Maß an Erfahrung durch Spezialisierung auf Anforderungen | Weitere Rolle und zusätzliche Schnittstelle |
| Neutrale Beratung des Fachbereichs | Weder Fachbereich noch IT zugehörig |
| „Blick über den Tellerrand“ eines Fachbereichs hinaus | Mangelnde Akzeptanz in der IT und im Fachbereich |
| Zeit- und Kostenersparnis durch qualitativ gute Anforderungen | Zusätzliche Bürokratie (hoher Administrationsaufwand und Dokumentationsaufwand) |
| Objektivität gegenüber allen Anforderungen | Bevormundung des Fachbereichs |
| Frühzeitiges Erkennen von Zusammenhängen | Stille-Post-Effekt |
| Kosten-Nutzen-Analyse der Anforderungen vor deren Umsetzung | |
| Zeitliche Freistellung für Business-Analyse-Aufgaben | |
| Entlastung von IT und Fachbereich | |
| Abgleich der Anforderungen mit Zielen und dadurch zielführende Lösungen |
Abb. G.02: Pro- und Contra-Argumente zu Business-Analyse
Gegenargumente und ihre Entkräftung
Zusätzlicher Aufwand
Der Aufbau von Stellen bzw. Rollen für Business-Analysten verursacht (Personal-)Kosten und verbraucht Ressourcen. Allerdings wird dieser Aufwand durch professionelle Business-Analyse wieder „eingespielt“. Die Spezialisierung auf die Aufgabenfelder rund um Anforderungen macht deren Management effektiver und effizienter.
Hohe Veränderungsrate der Anforderungen
Das kann auch als Pro-Argument aufgefasst werden, denn Business-Analysten unterstützen in der Begrenzung von Anforderungen, falls Änderungen nicht sinnvoll sind, und sie begleiten die Aktualisierung von Anforderungen, falls eine Änderung einen Mehrwert bietet.
Keine Kenntnisse aus erster Hand
Business-Analysten haben tatsächlich oft weder das detaillierte Fachwissen noch die Erfahrungen wie der anfordernde Fachbereich. Diese Neutralität schützt allerdings vor „Betriebsblindheit“ und erlaubt eine andere Perspektive auf die Anforderungen. Gemäß dem Motto „Vier Augen sehen mehr als zwei“ forciert dieser neutrale Blick, die Anforderungen zielgerichtet, umfassend und in einer sinnvollen Detaillierung zu erfassen.
Keine operative Erfahrung
Auch hier hilft ein „unverstellter Blick“, Anforderungen zu ermitteln und zu dokumentieren. Anforderer, die beispielsweise lange für Geschäftsprozesse zuständig sind, neigen dazu, viele Sachverhalte als selbstverständlich vorauszusetzen. Dies kann leicht zu Lücken oder Missverständnissen bei der Ermittlung und Dokumentation von Anforderungen führen. Ein „unvoreingenommener“ Business-Analyst kann hier korrigierend wirken.
Zusätzliche Schnittstelle
Durch eine Bündelung der Aufgaben, die rund um Anforderungen anfallen, können beim Einsatz von Business-Analysten Schnittstellen sogar verringert werden. Mit einem zentralen Ansprechpartner für Anforderungen haben sowohl der Fachbereich als auch die Systementwickler/Lösungsbauer weniger Schnittstellen als wenn „jeder mit jedem“ spricht.
Weder Fachbereich noch IT zugehörig
Eine neutrale Positionierung von Business-Analysten bringt durchaus Herausforderungen mit sich. Dem stehen jedoch alle die genannten Vorteile gegenüber, die aus einer neutralen Rolle erwachsen.
Mangelnde Akzeptanz
Skepsis und Widerstand sind fast immer zu erwarten, wenn Veränderungen oder Neuerungen eingeführt werden. Aber „gute Arbeit zahlt sich aus“. Wenn Business-Analysten ihren Job gut machen, wächst die Akzeptanz in der IT und im Fachbereich. Dabei hilft ein gesundes Maß an Selbstvermarktung, indem den übrigen Beteiligten die Vorteile bewusst gemacht werden, die die Business-Analyse mit sich bringt.
Zusätzliche Bürokratie
Professionelle Business-Analyse setzt und nutzt Standards, zum Beispiel durch ein strukturiertes Vorgehen oder zur Dokumentation von Anforderungen. Es gilt, das richtige Maß aus Standards und Pragmatismus zu finden und hohen Administrations- und Dokumentationsaufwand zu vermeiden. Eine übertriebene Business-Analyse, die sich in starren Regelungen und dem Ausfüllen von Templates verliert, wird wenig Akzeptanz finden. Es hat sich bewährt, den Prozess und die Standards der Business-Analyse mit ihren „Kunden“ (insbesondere Fachbereich und IT) abzustimmen und weiterzuentwickeln.
Bevormundung des Fachbereichs
Business-Analysten sollten eine neutrale Haltung einnehmen. Die inhaltliche Verantwortung für die Anforderungen tragen die Anforderungssteller, die Verantwortung für die (IT-)Lösung tragen die Entwickler. Business-Analysten sind Berater und Dienstleister auf dem Weg zu qualitativ guten Anforderungen. Sie tragen die Verantwortung, dass dieser Weg strukturiert und systematisch gegangen wird.
Stille-Post-Effekt
Business-Analysten sind kommunikationsstark. Dies gilt sowohl für das Zuhören als auch für das Kommunizieren rund um Anforderungen. Missverständnisse in der menschlichen Kommunikation lassen sich nie ganz ausschließen. Professionelle Business-Analyse hilft dabei, diese Missverständnisse bei den Anforderungen aufzudecken und zu minimieren.
G.1.2 Fallbeispiel