Die Planung der Business-Analyse umfasst die drei Komponenten Stakeholder-Analyse, Aufgaben und Anforderungsmanagement.
Stakeholder-Analyse
In der Stakeholder-Analyse klären Business-Analysten, wer durch eine Veränderung betroffen ist, wer auf sie Einfluss nimmt und welche Stakeholder für die Business-Analyse zu berücksichtigen sind. Die beste, technisch umgesetzte Veränderung droht an mangelnder Akzeptanz zu scheitern, wenn Personen sich übergangen fühlen, nicht ausreichend berücksichtigt wurden oder ihre Anforderungen nicht einbringen konnten.
Aufgaben
Die Planung der Aufgaben unterscheidet sich je nach dem gewählten Vorgehensmodell. In klassischen Vorgehensmodellen (z.B. Projekte nach Wasserfallprinzip) werden die künftigen Aufgaben der Business-Analyse vergleichsweise ausführlich vorab geplant, indem die Inhalte der Aufgaben beschrieben, Dauer und Termine festgelegt werden. Häufig wird die Planung formal abgenommen und später auch formal überprüft.
In agilen Vorgehensmodellen wird in der Regel lediglich die anstehende Iteration fein geplant. Weitere Iterationen werden umso gröber geplant, je weiter sie in der Zukunft liegen.
Anforderungsmanagement
Die Planung des Anforderungsmanagements umfasst unter anderem Überlegungen, in welchen Dokumenten Anforderungen hinterlegt werden und welche Software-Tools zur Verwaltung der Anforderungen genutzt werden. Sinnvollerweise planen Business-Analysten auch vorab, welche Attribute sie neben der eigentlichen Anforderung erfassen und verwalten wollen. Häufig genutzte Attribute sind eine eindeutige ID, Angaben zur Quelle der Anforderung, zum Versionsverlauf, zum Autor, zum Status der Anforderung.
Die Verfolgbarkeit (Traceability) der Anforderungen erfasst ihren Lebenszyklus, von ihrem Entstehen bis zu ihrem Ende (z.B. durch Umsetzung und Archivierung). Business-Analysten können die Verfolgbarkeit von Anforderungen unterschiedlich intensiv betreiben. Daher sollten sie vorab planen, in welcher „Ausbaustufe“ sie Traceability durchführen wollen.
Weiter ist festzulegen, wie mit Änderungen von Anforderungen umgegangen werden soll. Während agile Vorgehensmodelle eine Veränderung von vornherein vorsehen und akzeptieren, findet im Rahmen klassischer Vorgehensmodelle häufig ein explizites IT-Change-Management statt. In der Planung des IT-Change-Managements wird unter anderem festgelegt, wie über Änderungen entschieden wird und wie Anforderungen formal geändert werden (z.B. Prozess mit Change Request).
Ist-Erfassung
Die Ist-Erfassung ermittelt und dokumentiert Kennzahlen für eine effiziente und effektive Performance der Business-Analyse. Dies können z.B. Termine, Änderungshäufigkeit der Anforderungen, Anzahl benötigter Review-Zyklen für Anforderungsdokumente sein.
Diagnose
Die Diagnose vergleicht die Werte der Planung mit den Ergebnissen der Ist-Erfassung. Typische Fragen insbesondere bei Abweichungen sind:
Wie war das Vorgehen?
Wo bestehen Probleme in der Business-Analyse?
Wo liegen Chancen für Verbesserungen?
Steuerung
Die Steuerung greift in die aktuelle Business-Analyse ein, um ungewollten Abweichungen von der Planung zu begegnen. Dazu ergreifen Business-Analysten korrigierende Maßnahmen, um sicherzustellen, dass Leistung, Qualität und Termine eingehalten werden.
Vorbeugende Maßnahmen mindern bei künftigen Abweichungen deren Eintrittswahrscheinlichkeit oder deren negative Auswirkung. Schließlich wird durch eine kontinuierliche Verbesserung der Business-Analyse das Vorgehen beziehungsweise 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
