Was ist eine Business Analyse?

Wie hier erkenntlich ist, gibt es vor der Durchführung des eigentlichen Projekts vorgelagerte Phasen, in denen die Vorbereitungen für das Projekt getroffen werden. Das kann sein

• Eine Evaluierung auf Machbarkeit und Kostenabschätzung auf Grund einer Idee und einer darauf folgenden Entscheidung
• Eine Anfrage mit konkreten Anforderungen mit folgendem Angebot und darauf folgendem Auftrag

Gleichgültig wie es genau zu einem Projekt kommt, muss in der Vorphase geklärt werden, was der Zweck des Projekts ist, also was damit geschaffen werden soll.

In diesem Kapitel beschäftigen wir uns mit der Disziplin der Business Analyse. Diese zeigt einen Weg auf, wie unter Berücksichtigung aller Stakeholder-Bedürfnisse, unter laufender Kontrolle des Nutzens und mittels Sammlung und Strukturierung von Anforderungen ein Leistungskatalog entsteht, der in Folge in einem Projekt umgesetzt werden kann.

Wie ist der Ablauf der Business Analyse?

Um den Ablauf einer Business Analyse zu verdeutlichen, wollen wir diesen anhand eines Beispiels durchgehen.

Erster Schritt ist es zu ermitteln, was die Zielsetzung aus der gesamten Unternehmenssicht ist. Dies wird auch Business-Ebene, Geschäftssicht oder Business-Sicht genannt; in diesem Beispiel soll ein neuer Vertriebsweg durch eine Online-Bestellplattform geschaffen werden:

Ergebnis dieses Schritts sind die sogenannten Business Requirements, also die Anforderungen aus der Unternehmenssicht. Sind diese bekannt, ist im zweiten Schritt zu überlegen und zu hinterfragen, was die Stakeholder (also alle vom Projekt betroffenen oder im Projekt beteiligten Personen und Gruppen) benötigen, damit die Zielsetzung des Unternehmens erreicht werden kann und wie das Ziel umgesetzt werden könnte.

Der Stakeholder „Online-Kunde“ bringt die Anforderung „ich möchte eine Bestellung tätigen können“ ein:

Entsprechend werden diese Anforderungen Stakeholder Requirements genannt. Diese sind meist noch vage und eher beispielhaft und bedürfen daher eine Präzisierung, beispielsweise durch eine Prozess- oder Ablaufbeschreibung:

Erst wenn die Ebenen der Geschäftssicht und die daraus abgeleiteten Anforderungen der Stakeholder bekannt sind, kann die Frage „Wie sieht eine passende Lösung aus?“ gestellt werden:

Diese sogenannten Solution Requirements legen nun die Anforderungen an eine Lösung fest, welche wiederum die Stakeholder und Business Requirements erfüllt:

Jetzt können Lösungsvorschläge gemacht werden, von denen im Idealfall eine Lösung als „die am besten geeignete“ ausgewählt wird. Nach dieser Entscheidung kann es (aus Sicht der Business Analyse) in die Umsetzung gehen.

In der Realität sind wir jetzt dort, was die obige Abbildung zeigt: entweder ist damit die Vorprojektphase abgeschlossen und es gibt genügend Information für eine Entscheidung zur Durchführung eines Projekts oder die erarbeiteten Solution Requirements werden an potentielle Auftragnehmer zur Angebotslegung übermittelt, woraus in Folge meist eine Beauftragung eines Projekts resultiert.

Was ist die Hierarchie der Anforderungen?

Der Wert des oben beschriebenen Ablaufs liegt darin, dass man die Analyse am richtigen Ende beginnt. Wird beispielsweise schon zu Beginn die Frage gestellt „was soll die Lösung können?“ so ist dies zwei Ebenen zu tief, denn diese Frage lässt sich erst dann richtig beantworten 

• wenn zuerst bekannt ist, was die Zielsetzung ist (=Business Requirements) 
• und dann bekannt ist, welche Stakeholder was tun können müssen (=Stakeholder Requirements), um die Business Requirements zu erreichen
• und dann bekannt ist, was die dafür vorgesehene Lösung können muss, um die Stakeholder und die Business Requirements zu erfüllen

Die Anforderungen aus Business Analyse-Sicht haben damit eine gewisse Hierarchie, die sich wie folgt darstellen lässt:

Die Stakeholder Requirements stellen dabei eine Art Brücke zwischen den Business Requirements und den Solution Requirements dar. Es ist üblich, dass die Solution Requirements in funktionale und in sogenannten nicht-funktionale Anforderungen unterteilt werden.

Funktionale Anforderungen sind all jene, wo das zu konstruierende System eine Funktionalität ausübt, d.h. eine Reaktion auf ein Ereignis erfolgt. Nicht-Funktionale Anforderungen sind all jene, die zusätzlich beschreiben, wie sich die Funktionalitäten verhalten sollen. Das können Anforderungen an ein Zeitverhalten, Anforderungen an die Sicherheit oder Anforderungen an Bedienung und Aussehen und dergleichen sein.

In der unten stehenden Abbildung taucht eine neue Kategorie der Anforderungen auf, die sogenannten Transition Requirements. Diese sind ausschließlich dazu da, um den Übergang von einer bestehenden Situation in die neue Situation zu begleiten.

Transition Requirements können notwendige Schulungen für ein neues System, die Änderungen von Personen und deren Rollen oder organisatorische Änderungen ebenso umfassen wie beispielsweise die erforderliche Übernahme von bestehenden Daten und Informationen. 

Das Weckersymbol in obigen Abbildung deutet an, dass diese Kategorie von Anforderungen nur für die Übergangsphase benötigt wird, d.h. bis die neue Lösung implementiert ist und verwendet wird. Im Gegensatz dazu bleiben die Business, Stakeholder und Solution Requirements solange aktuell, solange die neue Lösung zum Einsatz kommt, da ja auch davon auszugehen ist, dass die Lösung mit der Zeit weiterentwickelt wird.

Was ist ein Lastenheft und Pflichtenheft?

In der Praxis trifft man häufig auf Projekte, die nicht in diesem Ausmaß vorbereitet sind. Das resultiert unter anderem dadurch, dass das Wissen um die Notwendigkeit einer ausreichenden Vorarbeit und die Kenntnis einer professionellen Anforderungserhebung (noch) nicht ausreichend verbreitet und etabliert sind.

Oft erstellen Fachabteilungen Anforderungskataloge, die zwar sachlich gut aufbereitet sind, aber inhaltlich nicht die Qualität haben, die eine strukturierte Darstellung von Anforderungen benötigt. Die Folge sind Lücken, Widersprüche, nicht ausreichend formulierte Details, Lösungsideen anstelle von Anforderungen und dergleichen mehr.

Fazit ist dann oft, dass die eigentlichen Anforderungen erst im tatsächlichen Umsetzungsprojekt erhoben und dokumentiert werden müssen. Dadurch ergeben sich im Projektverlauf oft Änderungen und Präzisierungen, die unter Umständen den ja bereits vorgegebenen und vereinbarten Zeit- und Kostenrahmen beeinflussen können, weil sich der geplante Leistungsumfang verändert (vergleiche wiederum magisches Dreieck u.ä.).

Die Kenntnis der Qualität der Leistungsbeschreibung ist daher für einen Projektmanager wichtig, um die Konsequenzen auf den Zeit- und Kostenrahmen abschätzen zu können und mit seiner Unterschrift auf dem Projektauftrag deren mögliche Einhaltung zu bestätigen (vergleiche Projektdefinition).

Was ist ein Lastenheft?

Abhilfe und Verbesserung können der Einsatz agiler Methoden (Stichwort „änderungsanfällig“) oder eine gute Vorbereitung, beispielsweise eben mit der Business Analyse, bringen. Auch hier ist immer darauf zu achten, dass eine angemessene Vorgangsweise gewählt wird und der Aufwand für die Vorbereitung auch wirtschaftlich verträglich bleibt. 

Ungeachtet dessen bleibt es immer in der Verantwortung des Auftraggebers (!), dessen Wünsche und Bedürfnisse (= Anforderungen) ausreichend präzise und genau zu formulieren. Dieses Ergebnis wird Lastenheft genannt und ist wie folgt definiert:

Ein Lastenheft

• Beschreibt die „Gesamtheit der Forderungen an die Lieferungen und Leistungen eines Auftragnehmers“ (Definition nach DIN 69905)
• Ist vom Auftraggeber zu formulieren
• Dient als Grundlage zur Einholung von Angeboten
• Wird auch gelegentlich als Leistungsverzeichnis (LV) bezeichnet

Ein Lastenheft soll im Wesentlichen folgende Inhalte umfassen:

• Die Spezifikation des zu erstellenden Produkts (die „Last“)
• Die Anforderungen an das Produkt bei seiner Verwendung (z.B. Rechner- und Betriebssystemumgebung)
• Rahmenbedingungen für das Produkt und für die Leistungserbringung (z.B. einzuhaltende Normen)
• Vertragliche Konditionen (z.B. Erbringen von Teilleistungen, Gewährleistungsanforderungen, Risikomanagement usw.)
• Anforderungen an den Auftragnehmer (z.B. Zertifizierung nach ISO 9001)
• Anforderungen an das Projektmanagement des Auftragnehmers (z.B. Projektdokumentation, Qualitätsmanagement)

Das Lastenheft ist damit die Grundlage für alle folgenden Tätigkeiten. Es ist klar, dass je besser die Anforderungen an die zu erstellende Leistung beschrieben sind desto besser auch die Abwicklung der Umsetzung vor sich gehen kann. 

Je genauer und vollständiger die Leistungsbeschreibung samt erforderlichen Randbedingungen erfolgt, desto genauer ist es möglich, einen Zeit- und Kostenrahmen abzuschätzen und diesen im Projekt auch einzuhalten. Die Business Analyse liefert hierzu einen Ansatz, wie a) ein Lastenheft (Solution Requirements) gemäß obiger Definitionen erstellt werden kann und b) sich darin die Berücksichtigung aller Anforderungen inklusive des Unternehmensnutzens wiederfindet.

Was ist ein Pflichtenheft?

Das Lastenheft beschreibt „nur“ WAS die Anforderungen an die zu erstellende Leistung sind, auf das WIE wird nicht eingegangen. Das ist Aufgabe des Pflichtenhefts:

• Bildet die Grundlage für die vertraglich festgehaltenen und bindenden Leistungen eines Auftragnehmers
• Beinhaltet „die vom Auftragnehmer erarbeiteten Realisierungsvorgaben“ (Definition nach DIN 69905)
• Beschreibt die Umsetzung des vom Auftraggeber vorgegebenen Lastenheftes und ist somit die organisatorische und/oder technische Vorgabe zur Realisierung eines Projekts
• Wird gelegentlich auch als Fachfeinkonzept bezeichnet

Ein Pflichtenheft

Im Gegensatz zum Lastenheft sind die Inhalte daher präzise, vollständig und nachvollziehbar dokumentiert sowie mit technischen Festlegungen verknüpft, welche z.B. die Betriebs- und Wartungsumgebung festlegen.

Das Pflichtenheft beschreibt somit, wie der Auftragnehmer die Leistung zu erbringen gedenkt. Bei Großprojekten kann die Erstellung und vertragliche Vereinbarung des Pflichtenhefts selbst ein kleines Projekt sein.

Mindestbestandteil eines Pflichtenhefts ist ein Projektstrukturplan mit den zugehörigen Arbeitspaketen. In der einfachsten Form beinhaltet das Pflichtenheft die Benennung des Liefertermins und des Preises. 

Ausführliche Pflichtenhefte können auch die vollständige Projektplanung einschließlich Termin- und Ressourcenplänen umfassen. In solchen Fällen können Pflichtenhefte viele hundert Seiten umfassen – allerdings sind etwa 60…80 Seiten jene psychologische Grenze, was für einen Mitarbeiter einer Fachabteilung noch überschaubar ist! Hier macht eine Aufteilung auf mehrere Dokumente Sinn.

Im Gegensatz zu einer technischen Spezifikation beschreibt das Pflichtenheft die geplante Leistung als „Black Box“, enthält also in der Regel nicht die technische Lösung der Aufgabenstellung. 

Strukturbeispiel

Nach VDI/VDE 3694 (Lastenheft/Pflichtenheft für den Einsatz von Automatisierungssystemen) sind Lastenhefte und Pflichtenhefte wie folgt aufgebaut:

• Einführung in das Projekt
• Veranlassung, Zielsetzung des Vorhabens, Projektumfeld, wesentliche Aufgaben, Eckdaten für das Projekt (Termine, Kosten, Ressourcen)
• Beschreibung der Ausgangssituation (Ist-Zustand)
• Prozessbeschreibung (regulärer und irregulärer Betrieb), bestehendes System, Organisation (Strukturen, Berichtswesen), Istzustand der Daten
• Aufgabenstellung (Soll-Zustand)
• Anforderungsbeschreibung nach Teilaufgaben, Ablaufbeschreibungen, Datenmodell-Sollzustand
• Schnittstellen
• Mensch-Maschine, Rechner-Rechner
• Anforderungen an die Systemtechnik
• Datenverarbeitung (Erfassung, Funktionen, Ausgabe), Datenspeicherung, Software, Hardware
• Anforderungen für die Inbetriebnahme und den Einsatz (Nutzung)
• Dokumentation, Geräteaufstellung und Montage, Inbetriebnahme, Probebetrieb und Abnahmen, Schulungen, Betriebsablauf, Instandhaltung und Softwarepflege
• Anforderungen an die Qualität
• Software-Qualität (Merkmale, Sicherung, Nachweise), Hardware-Qualität)
• Anforderungen an die Projektabwicklung
• Projektorganisation (Personal, Zuständigkeiten), Projektdurchführung (Planung, Steuerung, Überwachung), Konfigurationsmanagement (Änderungsdienst, Versionsverwaltung)

Das Pflichtenheft beinhaltet zusätzlich:

• Systemtechnische Lösungen
• Gliederung und Beschreibung der systemtechnischen Lösung für die Themen aus der Aufgabenstellung (Strukturplan, Eingangsgrößen, Datenflüsse, Ausgangsgrößen, Speicher, Funktionsbeschreibung)
• Systemtechnik (Ausprägung)
• Software, Datenverwaltungs-/Datenbanksystem, notwendige Gerätetechnik, technische Angaben für das Gesamtsystem (Antwortzeit, Verfügbarkeit)

Was ist BABOK?

Der BABOK^® (Abk. für Business Analysis Body Of Knowledge) ist der Leitfaden für die Business Analyse. Er liegt seit Frühjahr 2015 in der Version 3 vor und wird vom IIBA, dem International Institute for Business Analysis, herausgegeben.

Der BABOK (IIBA, 2015) ist vergleichbar mit beispielsweise dem PMBOK (Project Management Body Of Knowledge (siehe Projektmanagement-Organisationen) oder ähnlichen Werken wie dem BPM CBOK (Abk. für Business Process Management Common Body Of Knowledge, einem Leitfaden für das Prozessmanagement).

Der BABOK besitzt folgende Struktur:

1. Einführung
2. Grundlegende Konzepte
3. Business Analyse – Planung und Überwachung
4. Erhebung von Anforderungen und Zusammenarbeit
5. Lebenszyklus von Anforderungen
6. Strategie-Analyse
7. Anforderungs-Analyse und Entwurfsdefinition
8. Lösungsüberprüfung
9. Kompetenzen
10. Techniken
11. Perspektiven

Die Kapitel 3 bis 8 werden als die sechs Wissensgebiete der Business Analyse bezeichnet (vergleiche dazu z.B. Wissensfelder des PMBOK). Diese können innerhalb eines Projekts oder außerhalb eines Projekts, z.B. als Vorbereitung eines solchen sowie zur kontinuierlichen Verbesserung und Unternehmensentwicklung, eingesetzt werden.

Innerhalb der Wissensgebiete beschreiben einzelne Aufgaben, Tasks genannt, die im Laufe einer Business Analyse durchzuführenden Tätigkeiten. Jeder Task ist mit einem Zweck, einer Beschreibung der Tätigkeiten, den notwendigen Inputs, Richtlinien und Werkzeuge, empfohlenen Techniken, betroffenen Stakeholdern und dem Output beschrieben.

Was ist Planung und Überwachung?

Die Reihenfolge der Tasks ist nicht festgelegt – manche Tasks kommen nur einmal zur Anwendung, manche Tasks werden während der Business Analyse mehrfach wiederholt. Etliche Tasks benötigen Ergebnisse (Outputs) von anderen Tasks und müssen daher darauf warten oder werden bewusst mit unvollständigen Inputs begonnen.

Das hat einen iterativen Charakter, weil auch in der Business Analyse nicht von Beginn an alles vorliegt und klar ist, sondern erst entwickelt, verfeinert und nach und nach vervollständigt werden muss.

Nicht zuletzt deshalb widmet der BABOK® der Planung ein eigenes Kapitel. Geplant werden

3.1 der Vorgang der Business Analyse an sich
3.2 die Zusammenarbeit mit Stakeholdern
3.3 der Umgang mit und die Dokumentation von Anforderungen
3.4 der Umgang (Speicherung und Zugriff) mit Informationen
3.5 die Performanz-Steuerung und Verbesserung

Beispielhaft betrachten wir 3.2 Zusammenarbeit mit Stakeholdern detaillierter, weil eine vergleichbare Planung auch Grundbestandteil der Projektdefinitions-Phase ist (und natürlich die diesbezüglichen Ergebnisse aus der Business Analyse mit in das Umsetzungsprojekt genommen werden können).

Was ist Plan Stakeholder Engagement?

Zweck von Plan Stakeholder Engagement ist eine Planung, wie die Zusammenarbeit mit den Stakeholdern gestaltet werden soll. Das erfordert naturgemäß eine Stakeholder-Analyse zwecks Feststellung, welche Stakeholder vom Vorhaben betroffen sind und wie deren Verhältnis zur Vorhaben ist (vergleiche dazu PM-102 Stakeholder-Management).

Inputs für die Stakeholder-Analyse sind

• Die Ziele des Vorhabens aus Unternehmenssicht (die Business Needs), um daraus die betroffenen Stakeholder abzuleiten
• Die Business Analyse-Planung aus Task 3.1 zwecks Konsistenz der gesamten Vorgangsweise

Die zugrundeliegenden Ideen und Vorgangsweise sind denen unter Projekthandbuch – Stakeholder und Stakeholder-Management sehr ähnlich:

• Erstellen einer bestmöglich vollständigen Liste an betroffenen Personen und Gruppen
• Verständnis, wer die Stakeholder sind, wie diese vom Vorhaben betroffen sind, deren Einstellung zum Vorhaben und deren Einfluss auf das Vorhaben

Daraus ergibt sich als Output des Tasks

• Eine Stakeholder-Liste mit den obigen Parametern
• Ein Kommunikationsplan mit Inhalten wie „welche Informationen müssen kommuniziert werden“, „wie erfolgt die Kommunikation“ (schriftlich, mündlich) oder „wo, wie oft und wann erfolgt die Kommunikation“ (z.B. wegen geografischer Abhängigkeiten)

Hilfreich dazu sind unter anderem die Strategie des Vorhabens sowie die Beschreibung des derzeitigen Zustands. An Techniken werden unter anderem empfohlen

• Brainstorming zwecks Erstellung der Stakeholder-Liste
• Dokumenten-Analyse, um organisatorische Rahmenbedingungen berücksichtigen zu können
• Interviews zwecks Informationsbeschaffung und Verständnis
• Organigramme und Prozessbeschreibungen
• Umfragen und Workshops

Die Rolle des Projektmanagers kann sowohl bei der Identifikation und Bewertung von Stakeholdern unterstützend agieren und/oder das Stakeholder-Management mit dem Business Analysten teilen.

Ausdrücklich wird auch darauf hingewiesen, dass es sich bei Plan Stakeholder Engagement um einen Task handelt, der sich durch die gesamte Business Analyse-Aktivität zieht. Dies ist dadurch begründet, dass es sich auch hier zu Beginn nur um einen ersten Ansatz handelt, der durch neue Erkenntnisse und Fortschreiten der Aktivitäten verfeinert und adaptiert wird. Es können neue Stakeholder dazukommen oder bestehende entfallen, es können sich Einfluss und deren Einstellung ändern etc.

In einem eigenen Task (4.5 Manage Stakeholder Collaboration) wird – u.a. mit den Ergebnissen der Stakeholder-Planung – das Engagement der Stakeholder zwecks gemeinsamer Zielerreichung gemanagt. 

Weitere Task-Adressaten der Stakeholder-Planungsergebnisse sind unter anderem

• 3.1 Planung des Business Analyse-Vorgehens (d.h. die Ergebnisse der Stakeholder-Analyse beeinflussen wiederum die Vorgangsweise)
• 4.1 und 4.2 für die Erhebung der (Stakeholder) Requirements
• 6.4 Strategie des Vorhabens (auch hier gibt es eine gegenseitige Abhängigkeit, da ja die Strategie zunächst auch zur Beurteilung der Stakeholder dient)

Was ist die Erhebung von Anforderungen und Zusammenarbeit?

Dieses Wissensgebiet umfasst die Erhebung von Informationen, die Prüfung auf deren Gültigkeit und die Kommunikation der Ergebnisse. Dazu gibt es die Tasks

4.1 Vorbereitung für die Erhebung
4.2 Durchführung der Erhebung
4.3 Überprüfung der Ergebnisse 
4.4 Kommunikation der Ergebnisse
4.5 Management der Zusammenarbeit

Aus den Planungsergebnissen ist mittlerweile bekannt, wer die betroffenen Stakeholder sind und wie die Vorgangsweise gestaltet werden soll. Die Vorgänge der Erhebung und der Kommunikation können allerdings auch ungeplant stattfinden, beispielsweise bei Gesprächen, die außerhalb von geplanten Workshops stattfinden.

Der Task der Vorbereitung stellt sicher, dass die Stakeholder alle für die Erhebung notwendigen Informationen besitzen. Dazu gehören beispielsweise die Erklärung der Vorgangsweise und die Klärung von Erwartungshaltungen. Ebenso werden hier die Logistik oder die eingesetzten Techniken festgelegt.

Die Ergebnis-Überprüfung ist dazu da, um unter allen Stakeholdern ein gleiches Verständnis der Erhebungen zu gewährleisten. Parallel dazu muss der Business Analyst die Ergebnisse auf mögliche Lücken oder Widersprüche zu anderen Anforderungen überprüfen.

Die Kommunikation der Ergebnisse wurde ja bereits in 3.2 Plan Stakeholder Engagement geplant. In diesem Task geht es nun um deren Umsetzung. 4.5 entspricht im Wesentlichen dem Stakeholder-Management, nämlich der kontinuierlichen Überprüfung, ob sich Stakeholder oder deren Rollen, Einfluss und Einstellung geändert haben.

Was ist der Lebenszyklus von Anforderungen?

Als Lebenszyklus bezeichnet man allgemein eine Phase, die sich von Beginn eines Themas bis zu dessen Ende zieht. Bei einer Software-Entwicklung beginnt beispielsweise der Lebenszyklus mit den ersten Ideen und Anforderungen, setzt sich über Entwurf, Implementierung, Test und Inbetriebnahme fort, wiederholt sich dann in der Wartungsphase und endet mit Außerbetriebnahme der Software.

Auch Anforderungen haben einen Lebenszyklus. Dieser beginnt analog mit deren erstem Auftauchen, sei es ein Unternehmensziel oder eine konkrete Anforderung. Er setzt sich während der Entwicklung der Lösung fort und endet erst, wenn die Lösung und die dazu gehörenden Anforderungen nicht mehr benötigt werden. Das bedeutet, dass Anforderungen nach der Implementierung einer Lösung nicht einfach archiviert werden, sondern weiterhin gemanagt werden müssen.

Für den Lebenszyklus von Anforderungen sieht der BABOK die folgenden Tasks vor:

5.1 Abgleich der Anforderungen
5.2 Wartung der Anforderungen
5.3 Priorisierung der Anforderungen
5.4 Management von Änderungen an Anforderungen
5.5 Überprüfung von Anforderungen

Der Abgleich von Anforderungen (engl. Trace Requirements) sorgt dafür, dass die erhobenen Anforderungen mit allen anderen Informationen konsistent sind. Das umfasst beispielsweise den Abgleich der Übereinstimmung zwischen Solution, Stakeholder und Business Requirements (vergleiche Hierarchie der Anforderungen).  Naturgemäß handelt es sich hierbei auch um einen Task, der im Laufe einer Business Analyse immer wieder durchgeführt wird.

Die Wartung von Anforderungen betrifft nicht nur die wiederkehrende Prüfung, ob einmal erhobene, geprüfte und kommunizierte Anforderungen und Ziele noch immer gültig sind, sondern auch eine entsprechende Pflege, damit zumindest ein Teil (in anderen Vorhaben) wiederverwendet werden kann (engl. Re-Use).

Mit der Priorisierung wird die Wichtigkeit von Anforderungen, die diese für Stakeholder haben, bestimmt. Die Priorisierung kann Einfluss auf den Wert einer Anforderung oder auf die Reihenfolge der Umsetzung haben (vergleiche Priorisierung von Anforderungen im Product Backlog von agilen Methoden).

Das Änderungsmanagement ist mit dem Änderungsmanagement im Projektmanagement vergleichbar (siehe Change Management). Auch hier werden die Auswirkungen einer Änderung auf Zeit, Kosten, deren Risiken und dergleichen beurteilt und einer Entscheidungsinstanz vorgelegt. Wie solche Prozesse vor sich gehen und wer die Entscheidungsinstanzen sind, wurde in 3.3 „Umgang mit und Dokumentation von Anforderungen“ festgelegt.

Bisher wurden die Anforderungen „nur“ erhoben, auf Widersprüche etc. überprüft und auf gleiches Verständnis bei allen Stakeholdern gebracht. Jetzt müssen die Anforderungen noch in 5.5 von den Stakeholdern bestätigt werden und können ab dann für die Lösungsfindung verwendet werden.

Was ist Strategie-Analyse?

Business Analyse ist – ebenso wie Projektmanagement – immer mit Veränderungen verbunden. Schließlich dienen ja auch Projekte dazu, um etwas Neues entstehen zu lassen.

Die Business Analyse ist – im Gegensatz zum Projektmanagement – üblicherweise im Vorfeld eines Projekts angesiedelt und dient zur Unterstützung von Veränderungen und deren Definition in Form von Lösungen.

“Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value”.

IIBA, 2015

Es geht also vorrangig um den Nutzen, den eine Veränderung mit sich bringen soll und den Weg dorthin, um diesen zu erreichen. Dafür ist eine Strategie hilfreich, wie diese im Wissensgebiet Strategie-Analyse beschrieben ist:

6.1 Analyse des Ist-Zustands
6.2 Definition des Soll-Zustands
6.3 Risikomanagement
6.4 Festlegung der Strategie

Bevor es an die Entwicklung einer Strategie gehen kann, ist das Wissen um den Ist-Zustand erforderlich. Daraus ergibt sich, warum eine Veränderung notwendig ist und was mit dieser erreicht werden soll.

Bei der darauf folgenden Definition des (gewünschten) Soll-Zustands ist die Festlegung der Erfolgskriterien ausschlaggebend. Zu berücksichtigen sind dabei auch die Ressourcenverfügbarkeit und eine gemeinsame Vision des Ergebnisses.

Hier begegnen uns als Ergebnis der Ist-Zustands-Analyse die Business Requirements, die in Folge zur Definition des Soll-Zustands führen.

Risikomanagement wird explizit als eigener Task betrieben. Es geht dabei genauso um 

• Die Beurteilung der Auswirkungen, wenn ein Risiko eintritt
• Die Wahrscheinlichkeit, dass ein Risiko eintritt 
• Und um den möglichen Zeitpunkt eines Risikoeintritts

Die Veränderungs-Strategie kann naturgemäß sinnvoll nur dann bestimmt werden, wenn der Ist-Zustand und der Soll-Zustand bekannt sind. Aufgabe dieses Tasks ist es, verschiedene Wege aufzuzeigen und dann den am besten geeigneten Weg auszuwählen.

Was ist Anforderungs-Analyse und Entwurfsdefinition?

In diesem Wissensgebiet wird nun detailliert auf die Methodik der Anforderungserhebung und –dokumentation eingegangen. Es finden sich folgende Tasks im BABOK:

7.1 Spezifikation und Modellierung
7.2 Verifikation von Anforderungen
7.3 Validierung von Anforderungen
7.4 Festlegen der Anforderungs-Architektur
7.5 Beschreiben von Entwurfs-Optionen
7.6 Bewertung und Lösungsvorschläge

Seit der BABOK-Version 3 ist auch die der Erhebungsphase angegliederte Entwurfsphase Bestandteil der Business Analyse. Wenngleich auch das Design selbst nicht im Vordergrund steht, ist es ein ständiger Begleiter der Anforderungen, um die Definition von Lösungen zu unterstützen.

Anforderungen müssen nicht nur erhoben, sondern auch dokumentiert werden. Diesen Task übernimmt 7.1 Spezifikation und Modellierung von Anforderungen. Als Modellierung wird die grafisch dargestellte und textlich  beschriebene Dokumentation von Anforderungen bezeichnet. Inputs dazu sind die Ergebnisse der Erhebungen, in diesem Fall sowohl bereits bestätigte (confirmed) als auch noch unbestätigte (unconfirmed) Anforderungen.

Nachdem die Anforderungen geeignet dokumentiert sind, müssen diese wiederum einer Überprüfung unterzogen werden. Die Verifikation dient dabei der Sicherstellung, dass die Anforderungen formalen Qualitätskriterien genügen und dem beabsichtigten Zweck dienen. Bei der Validierung werden die Anforderungen gegen die Business Requirements und gegen den Nutzen geprüft.

Bei der Beschreibung von Entwurfs-Optionen werden neben dem Design Lösungsansätze entwickelt, die Anforderungen werden einzelnen Lösungskomponenten zugeordnet und mögliche Chancen zur Verbesserung können sich auftun.

Schließlich werden die einzelnen Lösungsvorschläge in 7.6 auf deren Wert hin überprüft und davon wird ein Lösungsvorschlag zur Umsetzung ausgewählt.

Was ist Lösungsüberprüfung?

Mit dem Task 7.6 wurde der bestmögliche Lösungsvorschlag ausgewählt. Danach kann es an die tatsächliche Umsetzung in einem Projekt gehen. Die Umsetzung selbst und alle davor notwendigen Aktivitäten (Angebotseinholung, Beauftragung, Pflichtenhefterstellung etc.) sind nicht (mehr) Teil der Business Analyse. 

Gleichzeitig ist die Business Analyse mit der Lösungsentscheidung nicht zu Ende. Sie setzt wieder dort ein, wo eine Lösung implementiert ist und diese nun auf deren Brauchbarkeit und Verbesserungspotential untersucht wird. Ebenso bedeutet das nicht, dass die Business Analyse während der Projektumsetzung völlig untätig ist. 

Ähnlich wie ein Projektmanager die Analyse-Phase unterstützt, begleitet die Business Analyse die Umsetzung insbesondere mit dem Augenmerk auf Änderungen und auf Konsistenz mit den Anforderungen und mit dem Nutzen. Ferner kann es sein, dass eine Lösung nicht zu einem einzelnen Zeitpunkt vollständig implementiert wird, sondern dass es mehrere aufeinanderfolgende Teillösungen gibt (vergleiche Meilensteine und agile Vorgangsweise).

Die Arbeitsteilung könnte entsprechend wie folgt dargestellt werden:

Für die Phase nach der Implementierung gibt es folgende Tasks:

8.1 Performanz-Messung
8.2 Performanz-Analyse
8.3 Analyse von Lösungseinschränkungen
8.4 Analyse von Unternehmenseinschränkungen
8.5 Verbesserungsempfehlungen

Die Business Analyse geht also nicht davon aus, dass etwas analysiert, danach umgesetzt wird und damit alles in Ordnung sei. Vielmehr war ja auch die in 7.6 vorgeschlagene Lösung die nach gründlicher Arbeit bestmögliche Alternative – ob diese aber tatsächlich auch all das erfüllt, was an Vorhaben geplant war, bedarf zumindest einer Überprüfung.

In 8.1 wird der Nutzen, den die implementierte Lösung bringt, gemessen. Eine solche Beurteilung ist nicht unbedingt trivial, kann sich aber an Unternehmenszielen oder an der Beurteilung von Stakeholdern orientieren.

Die gemessenen Ergebnisse sind in 8.2 zu bewerten. Die Werte alleine haben noch keine ausreichende Aussagekraft, sie müssen erst interpretiert, zusammengefasst und aufbereitet werden. Hilfreich dabei ist die Orientierung am in 6.2 definierten Soll-Zustand.

Wie gut nun die Lösung tatsächlich ihre Leistung erbringt und ob es Einschränkungen seitens der Lösung oder seitens des Unternehmens gibt, wird in 8.3 und 8.4 untersucht. Dabei können auch Einflüsse außerhalb des Unternehmens von Relevanz sein.

Aus den vorangegangenen Analysen kann sich in 8.5 eine Empfehlung für Verbesserungen anschließen. Diese Empfehlung kann sowohl Änderungen an der Lösung als auch Anpassungen im Unternehmen beinhalten.

Was sind Kompetenzen?

Business Analysten brauchen – ähnlich einem Projektmanager – eine Vielzahl an Kompetenzen, um alle Vorgänge bestmöglich durchführen zu können.

Der BABOK listet dazu die notwendigen Kompetenzen in sechs Kategorien auf:

• Analytisches Denken und Problemlösungsfähigkeit
• Verhaltenskompetenzen 
• Geschäftskenntnis
• Kommunikationsfähigkeit
• Interaktionskompetenzen
• Werkzeuge und Technologien

Es lassen sich damit sozusagen „technische Kompetenzen“ (Analytisches Denken und Problemlösungsfähigkeit, Geschäftskenntnis, Werkzeuge und Technologien) und „soziale Kompetenzen“ (Verhalten, Kommunikation und Interaktion) unterscheiden.

Was sind Techniken?

Ganze 50 Techniken stehen laut BABOK dem Business Analysten zur Verfügung, um die einzelnen Tasks zu unterstützen. Im BABOK sind die Techniken eher rudimentär beschrieben und benötigen zu deren Anwendung ein vertieftes Spezialwissen. Bei den einzelnen Tasks ist jeweils eine Auswahl an Techniken aufgelistet, die zur Unterstützung des Tasks dienen können.

Techniken sind dabei nicht nur als „reine“ Techniken (wie etwa eine SWOT-Analyse oder diverse Modellierungstechniken) zu verstehen, sondern umfassen auch Aspekte wie Umfragen, die Verwendung eines Begriffsverzeichnisses oder die Ablaufbeschreibung von Reviews.

Was sind Perspektiven?

Perspektiven schaffen spezielle Sichtweisen auf häufig vorkommende Themen in der Business Analyse. Dabei werden die Bereiche

• Agile Methoden
• Business Intelligence
• Informationstechnologie
• Geschäftsarchitektur
• Geschäftsprozessmanagement

näher beleuchtet. Dazu gibt es wieder eine Auswahl von (speziellen) Methoden und Techniken, eine Liste an (zusätzlichen) Kompetenzen sowie eine Beschreibung der spezifischen Auswirkungen auf die verschiedenen Wissensgebiete.

Was ist PMI-PBA?

Eine vom PMI im Jahr 2014 durchgeführte Studie identifizierte mangelhaftes Anforderungsmanagement als die zweithäufigste Ursache von Projektfehlschlägen. 

Um bei der Überwindung dieser Herausforderung zu helfen, hat das PMI sein Angebot auf das Anforderungsmanagement erweitert. Dazu wurde das Online-Wissensportal „Requirements Management Knowledge Center of Excellence“ sowie der Kompetenznachweis „Professional in Business Analysis (PMI-PBA)^SM“ eingeführt.

Der PMI-PBA erfüllt das Bedürfnis von Unternehmen, ihr Anforderungsmanagement zu verbessern. Der Kompetenznachweis zielt auf die spezifische Rolle ab, die Geschäftsanalysten bei der Ermittlung der betrieblichen Anforderungen spielen, um sicherzustellen, dass ihre Projekte und Programme die erwarteten Vorteile liefern und die geschäftlichen Zielsetzungen erreichen.

Damit ist das Thema Business Analyse auch „offiziell“ mit dem Projektmanagement eng und untrennbar verbunden.