Business-Analyse. Axel-Bruno Naumann

der Geschäftsprozess der Business-Analyse aktualisiert.

      In der Praxis sind die Schritte Ist-Erfassung, Diagnose und Steuerung kaum voneinander zu trennen. Zudem unterstützen viele Techniken gleichzeitig alle drei Schritte. Daher werden diese drei Schritte in Kapitel 4 eng miteinander verknüpft. Dort findet sich eine ausführliche Beschreibung des Konzepts Business-Analyse-Planung und -Steuerung.

       G.4 Rollen und Stellen in der Business-Analyse

      In diesem einleitenden Kapitel soll ein Überblick über die verschiedenen Bezeichnungen der Personen gegeben werden, die mit Anforderungen befasst sind. Anders als zum Beispiel im Projektmanagement wurden die Rollen- und Stellenbezeichnungen in der Business-Analyse (noch) nicht vereinheitlicht.

      Ein Business-Analyst ist jede Person, die Aufgaben der Business-Analyse ausführt.

      Die Definition berücksichtigt,

       dass Business-Analyse aus Aufgaben mit unterschiedlicher „Flughöhe“ besteht (eher strategischer, taktischer oder operativer Natur)

       dass diese Aufgaben in unterschiedlichen Themenfeldern anfallen, z.B. Automatisierung oder Geschäftsprozessoptimierung

       dass Business-Analyse in unterschiedlichen Kontexten stattfindet, in agilen oder klassischen Projekten, Veränderungsmaßnahmen großen oder mittleren Ausmaßes oder in kleinen Veränderungen im Tagesgeschäft.

      Neben der weit verbreiteten Stellenbezeichnung „Business-Analyst“ gibt es weitere Rollen und Stellen, die verwandte Aufgaben rund um Anforderungen wahrnehmen bzw. die in eine Business-Analyse einbezogen werden. Die Abbildung nennt gebräuchliche Bezeichnungen dieser Personen.

      Abb. G.12: Rollen und Stellen in der Business-Analyse

      Rund um Anforderungen lassen sich zwei Personengruppen unterscheiden:

        Spezialisten, die sich hauptsächlich mit Anforderungen beschäftigen. „Business-Analyst“ ist hierbei eine verbreitete Stellenbezeichnung und wird im weiteren Verlauf des Buches verwendet. Darüber hinaus gibt es noch andere Bezeichnungen für Spezialisten rund um Anforderungen (vgl. linke Spalte der Abbildung G.12).

       Daneben gibt es Personen, die sich als Betroffene/Beteiligte einen Teil ihrer Arbeitszeit mit Anforderungen beschäftigen, sei es in Projekten oder im Tagesgeschäft (vgl. mittleren und rechten Teil der Abbildung G.12).

      Die Aufgaben dieser Personen und ihre Verknüpfung zur Business-Analyse werden insbesondere in den Kapiteln 1 bis 4 erläutert. Die Schwerpunkte einiger Rollen werden im Folgenden skizziert.

      Business-Case-Erstellung

      Bei der Erstellung eines Business Case werden beispielsweise Unternehmensarchitekten oder Business-Planer tätig, die die Verträglichkeit von Lösungsansätzen und -ideen mit Architekturentscheidungen und -vorgaben des Unternehmens abgleichen. Multiprojekt- und Portfoliomanager prüfen, ob verwandte oder widersprüchliche Lösungsansätze vorhanden sind. Sie fügen nach einem erfolgreichen Business Case das Veränderungsvorhaben in das Portfolio aller Vorhaben ein, indem sie es zeitlich und inhaltlich einordnen. Produktmanager entwickeln Vorschläge, wie bestehende Produkte weiterentwickelt oder neue Produkte bzw. Dienstleistungen geschaffen werden sollen.

      In plan-orientierten Vorgehensmodellen (z.B. nach Wasserfall) entscheidet ein Bewilligungsgremium oder Architektur-Board über den Business Case. In wandel-getriebenen (agilen) Vorgehensmodellen liegt diese Kompetenz z.B. beim Product Owner (als zentrale Rolle in Scrum).

      Requirements Engineering

      Je nach Unternehmen und Branche wird anstelle von Business-Analyst eine der anderen Bezeichnungen genutzt, wie z.B. Requirements Engineer, Anforderungsmanager, Systemanalytiker, IT-Koordinator, IT-Organisator. Unternehmen, die sich nach ITIL ausrichten, setzen häufig Demand Manager ein, die Anforderungen aufnehmen und dokumentieren.

      In klassischen Projekten entscheidet ein Lenkungsausschuss oder ein Steering Committee über das Projekt im Allgemeinen und das Anforderungsdokument im Besonderen. In agilen Vorgehen bearbeitet ein Entwicklungsteam die Anforderungen und wird dabei von einem Scrum Master methodisch unterstützt.

      Lösungseinführung

      Bei der Lösungseinführung wird das Ergebnis des Vorhabens in die Linie bzw. in das Tagesgeschäft übergeben. Für prozessorientiert gegliederte Unternehmen spielen die Prozessverantwortlichen eine zentrale Rolle.

      Sind mehrere Business-Analysten in einem Unternehmen tätig, müssen sie als Gruppe oder Team organisiert werden. Dabei können formal feste Rollen wie Senior-Business-Analyst oder Lead-Business-Analyst geschaffen werden. Es kann auch ein Business-Analyse-Center-of-Excellence oder Business-Analyse-Office eingerichtet werden, in dem die Mitarbeiter der Business-Analyse zusammengeführt werden. Ein solches Center of Excellence dient dann auch dem Informationsaustausch, dort werden Lessons Learned gezielt genutzt und es wird die Business-Analyse im Unternehmen weiterentwickelt.

       Literatur zu Kapitel G

      Carkenord, B. A.: Seven Steps to Mastering Business Analysis. Plantation 2009

      International Institute of Business Analysis (IIBA): A Guide to the Business Analysis Body of Knowledge (Babok Guide). Version 3.0, Toronto 2015

      International Institute of Business Analysis (IIBA): Business Analysis Body of Knowledge^® – BABOK 2.0^®. Leitfaden zur Business Analysis. 1. Aufl. in deutsch, Gießen 2012

      Paul, D.; Yeates, D.; Cadle, J. (Editors): Business Analysis. 3rd Edition, London 2014

      Podeswa, H.: The Business Analyst's Handbook. Boston 2008

      Robertson, S.; Robertson, J.: Mastering the Requirements Process. 3^rd Edition, Upper Saddle River 2012