ibo Schriftenreihe

Band 7

Axel-Bruno Naumann

Business-Analyse

Systematisches

Anforderungsmanagement

für nutzerorientierte Lösungen

1. Auflage

Verlag Dr. Götz Schmidt, Gießen

ISBN 978-3-945997-13-0

Copyright © 2018

Verlag Dr. Götz Schmidt, Gießen

Vorwort zur 1. Auflage

Meine erste Berührung mit Computern im beruflichen Umfeld liegt fast dreißig Jahre zurück. Die Bedienung des Computers erforderte zwar keine Programmierkenntnisse, erfolgte allerdings mittels Abkürzungen und Codes. Diese waren in eher unübersichtlichen Bildschirmmasken einzugeben. Gut, wenn man die Codes auswendig wusste oder die entsprechende Codetabelle griffbereit hatte. Anforderungen nach intuitiver oder zumindest benutzerfreundlicher Bedienung scheinen damals eine untergeordnete Rolle gespielt zu haben. Die technischen Möglichkeiten haben sich seitdem rasant entwickelt. Die heutigen Funktionalitäten wie z.B. Spracheingabe oder -steuerung gehörten in den Anfangsjahren der Computer noch in Science-Fiction-Filme.

Auch das fachliche Wissen hat sich weiterentwickelt. Nur wenige Personen dürften in der Lage sein, Fach- und IT-Wissen in sich zu vereinen, um die Anforderungen der Anwender IT-technisch umsetzen zu können. Spezialisierung ist gefragt, auf technischer Seite als Entwickler/Programmierer und als Anwender mit der Fokussierung auf fachliche Themenfelder.

Wer verbindet allerdings Fachbereiche, die Anforderungen an IT-Systeme stellen, mit den Personen, die diese Anforderungen technisch umsetzen? An Anforderungen mangelt es nicht. Es mangelt eher an Personen, die in der Lage sind, methodisch-fundiert und systematisch den Weg zu begleiten von der Ermittlung der Anforderungen bis hin zur Nutzung der (IT-)Lösungen, in denen die Anforderungen umgesetzt werden. Hier hat es sich in der Wirtschaftspraxis bewährt, Experten hinzuzuziehen: Business-Analysten, die sich auf Anforderungen spezialisieren.

Dieses Werk soll einen Beitrag dazu leisten, dass Business-Analysten und alle anderen Rollen, die sich mit Anforderungen befassen, erfolgreich unterwegs sind. Das ist ein anspruchsvoller Weg, wie ich finde. Denn es hat sich herausgestellt, dass funktionierende IT-Systeme alleine nur bedingt hilfreich sind. Geschäftsprozesse, organisatorische Fragen und Kosten-Nutzen-Analysen sind nur einige der begleitenden Aspekte, die Business-Analysten beachten sollten.

Die technischen und fachlichen Möglichkeiten werden sich weiter wandeln und erweitern. Solange (IT-)Lösungen noch nicht Anforderungen an sich selbst stellen und diese dann auch noch umsetzen, werden Business-Analysten eine Existenzberechtigung haben. Vielleicht ist das, was heute noch nach Science Fiction klingt, morgen schon Wirklichkeit; sehr wahrscheinlich erscheint mir das allerdings nicht.

Einigen Menschen möchte ich ausdrücklich für ihren Beitrag zu diesem Werk danken. Zunächst danke ich Götz Schmidt für die Gelegenheit, die ibo-Schriftenreihe um einen Band zu erweitern, und für seine zahlreichen Anregungen, die die Inhalte dieses Buchs noch runder machen. Nicht genug danken kann ich den vielen Business-Analysten, die in zahlreichen Workshops und Seminaren durch Erfahrungsaustausch, Fragen und Anregungen meinen Blick auf Business-Analyse geschärft und erweitert haben. Dank auch an Andreas Valentin Schmidt für das Umsetzen meiner Anforderungen hinsichtlich der Grafiken in diesem Buch. Dagmar Hofmann-Kahlke danke ich für ihre fachkundige Umsetzung meiner Anforderungen (Manuskript) in eine lösungsnahe Version (druckfertige Form).

Ein Dankeschön geht an die ibo-Kollegen, die einzelne Abschnitte hinsichtlich Eindeutigkeit und Korrektheit verifiziert haben. Danke an die Kollegen bei ibo für inzwischen zehn Jahre des Austauschs rund um Anforderungen und Business-Analyse. Ein herzliches Dankeschön meiner Familie, die mir Zeit zum Denken, Analysieren und Schreiben eingeräumt hat. Mein Vater hat das Entstehen dieses Buches leider nicht mehr erlebt. Als langjähriger Schriftsetzer und Korrektor hätte er eine besondere Perspektive und Leidenschaft in dieses Buch eingebracht.

Axel-Bruno Naumann

Wettenberg, im Juni 2018

Inhaltsverzeichnis

Cover

Titel

Impressum

G Grundlagen

G.1 Existenzberechtigung der Business-Analyse

G.1.1 Berufsbild Business-Analyse

G.1.2 Fallbeispiel TREND Möbelhäuser

G.2 Anforderungen und Klassifikationsschema

G.2.1 Übersicht

G.2.2 Klassifikationsschema der Anforderungen

G.2.2.1 Geschäftsanforderungen

G.2.2.2 Stakeholder-Anforderungen

G.2.2.3 Lösungsanforderungen

G.2.2.4 Transitionsanforderungen

G.2.3 Annahmen und Restriktionen

G.3 ibo-Anforderungstür®

G.3.1 Übersicht

G.3.1.1 Konzepte

G.3.1.2 Grundprinzipien

G.3.2 Business-Case-Erstellung

G.3.3 Requirements Engineering

G.3.4 Lösungseinführung

G.3.5 Business-Analyse-Planung und -Steuerung

G.4 Rollen und Stellen in der Business-Analyse

Literatur zu Kapitel G

1 Business-Case-Erstellung

1.1 Einleitung

1.1.1 Startpunkte für Veränderungen

1.1.2 Skalierbarkeit von Business Cases

1.1.3 Vier Schritte zur Business-Case-Erstellung

1.2 Leistungspotenziale

1.2.1 Überblick

1.2.2 Problembeschreibung

1.2.2.1 Verbale Bewertung

1.2.2.2 SWOT-Analyse

1.2.2.3 World Café

1.2.2.4 Kompakte Problembeschreibung

1.2.2.5 Ausführliche Problembeschreibung

1.2.3 Linear-kausale Ursachenanalyse

1.2.3.1 5W-Technik (5 Why)

1.2.3.2 Vorgelagerte Ursachen

1.2.3.3 Ishikawa-Diagramm

1.2.4 Komplexe Ursachenanalyse

1.2.4.1 Ursache-Wirkungs-Diagramm

1.2.4.2 Papiercomputer

1.2.4.3 Portfolio-Analyse

1.2.4.4 Schwachstellenanalyse

1.2.5 Zusammenfassung

1.3 Geschäftsanforderungen

1.3.1 Überblick

1.3.2 Zielformulierungsprozess

1.3.2.1 Zielideen suchen

1.3.2.2 Ziele analysieren und Zielstruktur aufbauen

1.3.2.2.1 Lösungen durch Ziele ersetzen

1.3.2.2.2 Muss-Ziele von Kann-Zielen trennen

1.3.2.2.3 Bezug zur Veränderung prüfen

1.3.2.2.4 Redundanzen eliminieren

1.3.2.2.5 Zielwidersprüche beseitigen

1.3.2.2.6 Geeignete Oberbegriffe suchen und vervollständigen

1.3.2.2.7 Ziele operationalisieren

1.3.2.3 Ziele gewichten

1.3.2.4 Zielstruktur entscheiden und im Business Case dokumentieren

1.4 Lösungsansätze

1.4.1 Überblick

1.4.2 Lösungsumfang bestimmen

1.4.2.1 Scope-Modellierung

1.4.2.2 Scope-Modellierung nach außen

1.4.2.3 Scope-Modellierung nach innen

1.4.2.3.1 Organigramm

1.4.2.3.2 SIPOC

1.4.2.3.3 Datenflussdiagramm

1.4.2.3.4 Systemdiagramm

1.4.3 Lösungsvarianten ermitteln

1.4.3.1 Spannbreite möglicher Lösungsvarianten

1.4.3.2 Art der Lösungsvarianten

1.4.3.3 Techniken zur Ermittlung von Lösungsvarianten

1.4.3.4 Empirische, konvergente Techniken zur Ermittlung von Lösungsvarianten

1.4.3.5 Kreative, divergente Techniken zur Ermittlung von Lösungsvarianten

1.4.3.5.1 Mechanismen von Kreativitätstechniken

1.4.3.5.2 Regeln für Kreativitätstechniken

1.4.3.5.3 Brainstorming

1.4.3.5.4 Brainwriting

1.4.3.5.5 Brainstorming paradox (Kopfstand)

1.4.3.5.6 Sechs Hüte (De-Bono-Denkhüte)

1.4.3.5.7 Morphologische Analyse

1.4.3.5.8 Freie Analogie

1.4.3.5.9 Scamper

1.4.3.6 Überkreuz-Workshop

1.4.4 Zusammenfassung

1.5 Empfehlung

1.5.1 Überblick

1.5.2 Entscheidungsanalyse

1.5.2.1 Nicht-monetäre Ergebnisse

1.5.2.2 Kapitalwert, Barwert, Discounted Cashflow

1.5.2.3 Interner Zinsfuß

1.5.2.4 Amortisationsdauer

1.5.2.5 Durchschnittliche Rendite

1.5.2.6 Nutzwert-Analyse

1.5.2.7 Kosten-Nutzen-Analyse

1.5.3 Risikoanalyse

1.5.3.1 Risikoportfolio

1.5.3.2 Risikotabelle

1.6 Business Case

1.7 Zielgruppe

1.8 Handlungskompetenz

1.8.1 Einführung

1.8.2 Geschäftsverständnis

Literatur zu Kapitel 1

2 Requirements Engineering

2.1 Einleitung

2.2 Vorbereitung

2.2.1 Anforderungsquellen

2.2.2 Einflussfaktoren bei der Anforderungsermittlung

2.2.2.1 Menschliche Einflussfaktoren

2.2.2.2 Organisatorische Einflussfaktoren

2.2.2.3 Fachliche/inhaltliche Einflussfaktoren

2.2.3 Ermittlungsinhalte

2.2.3.1 Checkliste mit grundlegenden Fragen

2.2.3.2 Würfel der Ermittlungsinhalte

2.2.4 Wahl der Erhebungstechniken

2.3 Anforderungsermittlung

2.3.1 Erhebung durchführen

2.3.1.1 Befragungstechniken

2.3.1.1.1 Checkliste

2.3.1.1.2 Gliederung

2.3.1.1.3 Interview

2.3.1.1.4 Workshop

2.3.1.2 Beobachtungstechniken

2.3.1.2.1 Fremdbeobachtung

2.3.1.2.2 Selbstbeobachtung

2.3.1.3 Weitere Techniken

2.3.2 Annahmen, geschäftliche und technische Restriktionen identifizieren

2.3.2.1 Annahmen

2.3.2.2 Geschäftliche Restriktionen

2.3.2.3 Technische Restriktionen

2.3.3 Erhebung dokumentieren

2.3.3.1 User-Story

2.3.3.2 Story-Dekomposition

2.3.3.3 Story-Elaboration mit Abnahmekriterien

2.3.3.4 Story-Map

2.3.3.5 Glossar

2.3.4 Ergebnisse der Erhebung bestätigen lassen

2.4 Anforderungspriorisierung

2.4.1 Überblick

2.4.2 Priorisierungskriterien

2.4.3 Priorisierungstechniken

2.4.3.1 MoSCoW

2.4.3.2 Big-Wall-Verfahren

2.4.3.3 Planning Poker

2.4.3.4 Business Value Game

2.4.3.5 Präferenzmatrix

2.4.3.6 Abstimmung

2.4.3.7 Kano-Modell

2.4.3.8 Kano-Analyse

2.4.3.9 Magic Estimation

2.4.3.10 Team Estimation Game

2.4.3.11 Zusammenfassung

2.5 Strukturierung

2.5.1 Möglichkeiten der Strukturierung

2.5.2 Techniken der Spezifizierung und Modellierung

2.5.3 Kriterien zur Auswahl von Dokumentationstechniken

2.5.4 Prinzipien der Dokumentation

2.5.5 Zusammenfassung

2.6 Spezifizierung

2.6.1 Hauptprobleme mit Anforderungen in natürlicher Sprache

2.6.2 Funktionale versus nicht-funktionale Anforderungen

2.6.3 Funktionale Anforderungen

2.6.3.1 Kurzschema für universelle funktionale Anforderungen

2.6.3.2 Schema für nicht-universelle funktionale Anforderungen

2.6.3.3 Optionale Ergänzungen

2.6.3.4 Abnahmekriterien für funktionale Anforderungen

2.6.4 Nicht-funktionale Anforderungen

2.6.4.1 Kategorien nicht-funktionaler Anforderungen

2.6.4.2 Nicht-funktionale Anforderungen herleiten

2.6.4.3 Nicht-funktionale Anforderungen dokumentieren

2.6.5 Zusammenfassung

2.7 Modellierung

2.7.1 Eigenschaften von Modellen

2.7.2 Kontextdiagramm

2.7.3 Use-Case-Diagramm

2.7.4 Use-Case-Beschreibung

2.7.5 Prozessmodellierung

2.7.5.1 BPMN-Diagramm

2.7.5.2 Weitere Notationen zur Prozessmodellierung

2.7.5.2.1 Folgeplan

2.7.5.2.2 Ereignisgesteuerte Prozesskette

2.7.5.2.3 UML-Aktivitätsdiagramm

2.7.5.3 Vorgehen und Tipps

2.7.6 Datenmodellierung

2.7.7 Prototyping

2.7.8 Weitere Modelle

2.7.9 Zusammenfassung

2.8 Verifizierung, Validierung

2.8.1 Überblick

2.8.2 Verifizierung

2.8.2.1 Statische Verifizierungstechniken

2.8.2.2 Dynamische Verifizierungstechniken

2.8.2.3 Dokumentationsabgleich

2.8.3 Validierung

2.8.3.1 House of Quality (HoQ)

2.8.3.2 Quality Function Deployment (QFD)

2.8.4 Zusammenfassung

2.9 Genehmigung

2.10 Anforderungsmanagement

2.10.1 Überblick

2.10.2 Anforderungen weiterverwenden

2.11 Anforderungsdokument

2.11.1 Ausrichtung eines Anforderungsdokuments

2.11.2 Gliederung eines Anforderungsdokuments

2.11.3 Lastenheft und Pflichtenheft

2.12 Zielgruppe

2.13 Handlungskompetenz

Literatur zu Kapitel 2

3 Lösungseinführung

3.1 Einleitung

3.2 IT

3.2.1 Zuordnung von Anforderungen

3.2.2 Transitionsanforderungen

3.3 Kultur

3.4 Ziele und Struktur

3.4.1 Prozesse

3.4.2 Lösungsbewertung und Leistungsüberprüfung

3.4.2.1 Kennzahlen

3.4.2.2 Ist-Werte

3.4.2.3 Maßnahmen

3.5 Lösung

3.5.1 Checkliste

3.5.2 Dokumente

3.6 Zielgruppe

3.7 Handlungskompetenz

Literatur zu Kapitel 3

4 Business-Analyse-Planung und -Steuerung

4.1 Einleitung

4.2 Planung

4.2.1 Überblick

4.2.2 Stakeholder-Analyse

4.2.2.1 Ablauf der Stakeholder-Analyse

4.2.2.2 RACI-Matrix und Stakeholder-Tabelle

4.2.2.3 Stakeholder-Portfolio

4.2.2.4 Persona

4.2.3 Aufgaben

4.2.3.1 Aufgaben und Ergebnisse

4.2.3.2 Zeitaufwand

4.2.3.3 Kommunikation

4.2.4 Anforderungsmanagement

4.2.4.1 Anforderungsrepositorium

4.2.4.2 Verfolgbarkeit (Traceability)

4.2.4.3 Anforderungsattribute

4.2.4.4 Anforderungspriorisierung

4.2.4.5 IT-Change-Management

4.3 Ist-Erfassung, Diagnose, Steuerung

4.3.1 Überblick

4.3.2 Aufgabenbericht

4.3.3 Taskboard

4.3.4 Gruppenprozessanalyse

4.4 Zusammenfassung

Literatur zu Kapitel 4

5 Business-Analyse in agilen Kontexten

5.1 Einleitung

5.2 Business-Analysten in Scrum

5.2.1 Scrum im Überblick

5.2.2 Rollen in Scrum

5.2.3 Einsatz von Business-Analysten in Scrum

5.3 CONNY-Prinzip für agile Business-Analyse

5.3.1 Collaborate and improve continuously

5.3.1.1 Collaborative Games

5.3.1.2 Retrospektive

5.3.2 Only the customer counts

5.3.3 Negotiate what is valuable to the customer

5.3.4 Not feasible = not necessary

5.3.4.1 Planungs-Workshop

5.3.4.2 Schätzung

5.3.5 You should not waste

Literatur zu Kapitel 5

6 Business-Analyse in weiteren Kontexten

6.1 Einleitung

6.2 Organisatorische Einbettung von Business-Analysten

6.3 Business-Analysten im Projektmanagement

6.3.1 Abgrenzung der Rollen Projektleiter und Business-Analyst

6.3.2 Business-Analyse vor Projektstart und nach Projektende

6.3.3 Projektleiter und Business-Analyst in Personalunion

6.4 Business-Analysten im Prozessmanagement

6.4.1 Überblick zu Prozessmanagement

6.4.2 Überblick zu Business-Analyse

6.4.3 Prozessmanagement und Business-Analyse im Vergleich

6.5 Positionierung von Business-Analysten

6.5.1 ibo-Positionierungswürfel

6.5.2 Business-Analyst-Canvas

Literatur zu Kapitel 6

Anhang: Personenzertifizierungen

Glossar

Literaturverzeichnis

Stichwortverzeichnis

G Grundlagen
G.1 Existenzberechtigung der Business-Analyse

G.1.1 Berufsbild Business-Analyse

Das Berufsbild der Business-Analyse hat sich in den letzten Jahren zunehmend etabliert. Immer häufiger werden Business-Analysten in unterschiedlichen Unternehmen und Branchen eingesetzt. Allerdings ist dieses Aufgabenfeld noch nicht so bekannt, standardisiert und etabliert wie zum Beispiel Projektmanagement oder Prozessmanagement.

Dabei gibt es gleich mehrere Gründe, die als Existenzberechtigung der Business-Analyse dienen können:

 zunehmender Grad der Technisierung und der Automatisierung in Unternehmen

 hohe Spezialisierung der Mitarbeiter in verschiedenen Disziplinen

 neutrale, möglichst objektive Beurteilung von Veränderungen

 effiziente Nutzung von Ressourcen, insbesondere in der IT-Entwicklung

 zunehmende Veränderungsgeschwindigkeit und Komplexität im Umfeld der Unternehmen

 steigende und sich schnell wandelnde Erwartungen der Kunden.

Im Folgenden wird erläutert, weshalb die Rolle eines Business-Analysten für Unternehmen wertvoll sein kann.

Zunehmender Grad der Technisierung und der Automatisierung in Unternehmen

Unter den Schlagwörtern Digitalisierung und Automatisierung wird in vielen Branchen der zunehmende Einsatz von IT und Technologie verstanden. Wo vor einigen Jahren noch manuelle Tätigkeiten vorherrschten oder Aufgaben IT-unterstützt erledigt wurden, dominieren immer stärker Maschinen und technische Systeme. Roboter übernehmen in produzierenden Unternehmen immer mehr Aufgaben, leistungsfähige IT-Systeme drängen die menschliche Arbeit in Dienstleistungsunternehmen zurück.

Auch die IT selbst verändert sich massiv, vom Betrieb eigener Rechenzentren zum Cloud Computing, von Desktop PC zu mobilen Endgeräten, von Über-Nacht-Verarbeitung der Daten (Batchlauf) zu Echtzeit- oder Neartime-Daten, von Eigenentwicklungen zu Software as a Service.

Die Programmierung von Anwendungen wie auch die Entwicklung neuer technischer Lösungen wird durch Anforderungen ausgelöst. Diese Anforderungen stammen aus sehr unterschiedlichen Quellen. Häufig sind es Ziele des Managements oder Wünsche der Anwender (Mitarbeiter, Kunden), die umgesetzt werden sollen. Die Umsetzung erfolgt nicht durch diejenigen, die eine Anforderung haben, sondern durch technische Experten, meistens IT-Spezialisten. Business-Analysten können dazu beitragen, dass Änderungsvorhaben effektiv und effizient umgesetzt werden, indem sie als methodische Experten für Anforderungen eingesetzt werden.

Hohe Spezialisierung der Mitarbeiter in verschiedenen Disziplinen

Die zunehmende Spezialisierung betrifft sowohl die Fachabteilungen, in denen das Tagesgeschäft abgewickelt wird, als auch die Entwicklungsabteilungen. Das führt nahezu automatisch dazu, dass sich die Mitarbeiter in den verschiedenen Organisationseinheiten immer weiter auseinanderleben. Das beginnt bei einer unterschiedlichen Sprache – oft verstehen sich Anwender und Entwickler gar nicht mehr, weil jeder für den jeweils anderen „Fachchinesisch“ spricht. Aber auch die Denkweisen entwickeln sich oft in ganz andere Richtungen. Schließlich sind die Interessenlagen fast immer sehr unterschiedlich, was ebenfalls das gegenseitige Verständnis erschwert. Und nicht zuletzt machen die steigende Komplexität und die rasante Entwicklung der Technik die wechselseitige Verständigung immer schwieriger. Sich in eine Disziplin hineinzudenken bzw. einzuarbeiten erfordert immer mehr Zeit. Die fachlichen Aspekte zu durchdringen wird genauso herausfordernd wie den Überblick im IT- und Technologieumfeld zu behalten. Aus all diesen Gründen liegen fachliche Anforderungen „nicht auf der Hand“, und wenn sie bekannt sind, sind sie damit noch lange nicht für „Außenstehende“ verständlich; dies gilt auch für die Umsetzer und Entwickler von Lösungen zu diesen Anforderungen. Wegen dieser Verständigungsschwierigkeiten wird die Rolle des Business-Analysten immer wichtiger. Er dient als Brückenbauer zwischen Fachabteilung und IT.

Abb. G.01: Business-Analysten als Dolmetscher und Brückenbauer

Neben den Unterschieden zwischen Fachabteilung und IT gibt es oft auch Verständnishürden zwischen den Fachabteilungen selbst. Dies kann bei gemeinsamen Vorhaben, bei denen Anforderungen aus mehreren Fachabteilungen eingebracht werden, die Zusammenarbeit erschweren, wenn die Fachabteilungen die jeweils andere „Seite“ weder sachlich-fachlich verstehen noch deren Interessenlage nachvollziehen können oder wollen.

In beiden Fällen, also bei der Abstimmung der Fachabteilung mit der IT und bei der Kommunikation der Fachabteilungen untereinander, können Business-Analysten als „Dolmetscher“ und „Brückenbauer“ eine wesentliche Rolle spielen. Eine ihrer zentralen Aufgaben ist es, Anforderungen zu verstehen, zu hinterfragen, zu klären, zu dokumentieren, an Dritte zu kommunizieren und dafür zu sorgen, dass die Anforderungen den Zielen des Unternehmens dienen und dann auch zielgerichtet umgesetzt werden.

Neutrale, möglichst objektive Beurteilung von Veränderungen

Anforderungen und ihre Auswirkungen auf IT-Systeme, Geschäftsprozesse oder organisatorische Aspekte machen nicht an Abteilungsgrenzen Halt. Werden die Auswirkungen analysiert, die eine geplante Veränderung mit sich bringt, ergeben sich meistens sowohl positive als auch negative Effekte. Was für einen Fachbereich gut sein mag, kann durchaus für einen anderen Bereich mit Nachteilen verbunden sein. Business-Analysten nehmen grundsätzlich eine neutrale, ganzheitliche und fachbereichsübergreifende Perspektive ein. Eine Verbesserung an einer Stelle darf nur dann zu Verschlechterungen oder zu unerwünschten Änderungen an anderen Stellen im Unternehmen führen, wenn aus gesamtbetrieblicher Sicht die Vorteile deutlich überwiegen. Der Business-Analyst muss versuchen, mit allen Beteiligten gemeinsam Lösungen zu finden, die für das Unternehmen zielführend sind und die von allen mitgetragen werden können.

Aus der neutralen Position des Business-Analysten können auch die Wechselwirkungen mit anderen Projekten, mit anderen Vorhaben oder mit Geschäftsprozessen überprüft werden. Dies kann die Priorisierung der Anforderungen, deren Abstimmung im Gesamtkontext des Unternehmens und die effiziente Nutzung von Ressourcen erleichtern und verbessern.

Effiziente Nutzung von Ressourcen, insbesondere in der IT-Entwicklung

In den meisten Unternehmen gibt es mehr Anforderungen als durch bestehende Ressourcen, sei es interne oder externe IT-Entwicklung, zeitnah umgesetzt werden können. Eine Priorisierung der Anforderungen ist deswegen ein wesentlicher Bestandteil der Business-Analyse. Dabei sind die unterschiedlichen Interessen der Fachabteilungen zu berücksichtigen, die verständlicherweise meistens ihre eigenen Anforderungen höher priorisieren als die der anderen Fachabteilungen. Hinzu kommen technische Rahmenbedingungen, die eine rein fachliche Priorisierung der Anforderungen nicht zulassen. Auch hier erleichtert die neutrale Rolle des Business-Analysten eine sachgerechte und zielführende Lösung, die von allen getragen werden kann.

Zunehmende Veränderungsgeschwindigkeit und Komplexität im Umfeld der Unternehmen

Gesetzliche und regulatorische Auflagen, seien sie national oder international, nehmen in vielen Branchen zu. Das Wettbewerbsumfeld wird für viele Unternehmen schwieriger, sei es durch kleine und spezialisierte Mitbewerber oder durch große internationale Konzerne. Die technologischen Möglichkeiten nehmen ständig zu. Schnelle Produktentwicklungen oder -weiterentwicklungen, z.B. mittels agiler Vorgehensmodelle wie Scrum, werden immer häufiger eingesetzt.

Alle diese Entwicklungen führen dazu, dass die begrenzten Ressourcen bestmöglich genutzt werden – auch dabei kann der Business-Analyst einen wertvollen Beitrag leisten, weil er die Instrumente kennt, mit denen komplexe Problemstellungen effizient bearbeitet werden können.

Ein Stillstand eines Unternehmens ist in vielen Fällen ein Rückschritt, wenn das Umfeld sich weiterentwickelt. Daraus leitet sich ein weiterer Aspekt für die Existenzberechtigung der Business-Analyse ab.

Steigende und sich schnell wandelnde Erwartungen der Kunden

Steigende Erwartungen der Kunden sind wahrscheinlich die größte Herausforderung für Unternehmen. Mehr denn je müssen Erwartungen und Anforderungen externer Kunden an Produkte und Dienstleistungen erfüllt werden, wenn ein Unternehmen im Markt bestehen will. Durch die Spezialisierung in verschiedenen Disziplinen (siehe oben) haben meistens nur noch vergleichsweise wenige Mitarbeiterinnen und Mitarbeiter einen direkten Kontakt zum Kunden und kennen so aus erster Hand die Erwartungen. Aber nicht nur die Anforderungen der externen „richtigen“ Kunden müssen umgesetzt werden. Auch Abteilungen, die nicht direkt mit externen Kunden zu tun haben, tragen zur Wertschöpfung bei und haben Anforderungen, die erfüllt werden müssen.

Interne und externe Kunden haben steigende und sich wandelnde Erwartungen an Produkte und Dienstleistungen. Bei internen Kunden sind dies in der Regel (Zwischen-)Ergebnisse anderer Abteilungen, die als Input für die eigene Arbeit dienen. Letztlich dienen auch die „internen Kunden“ fast alle dem Markt, das heißt dem externen Kunden. Bei internen wie bei externen Kunden arbeiten Business-Analysten als Brückenbauer und Dolmetscher, um eine effektive und effiziente Zusammenarbeit zu gewährleisten. Sie helfen, dass aus Schnittstellen zwischen Abteilungen Nahtstellen werden.

Im Zentrum des unternehmerischen Handelns sollte jedoch der externe Kunde stehen und die Anforderungen im Unternehmen sollten sich an seinen Erwartungen ausrichten.

Die oben genannten Gründe für den Einsatz von Business-Analysten lassen sich nicht immer klar voneinander trennen. In Summe verdeutlichen sie aber, dass Business-Analysten in Unternehmen sehr wertvolle und nützliche Funktionen erfüllen können. Analog zu der Spezialisierung in verschiedenen Disziplinen erscheint es sinnvoll, dass sich Personen auf das Ermitteln, Dokumentieren und Analysieren von Anforderungen und auf die neutrale Unterstützung bei der Entwicklung von Lösungen spezialisieren sollten. Immer mehr Unternehmen erkennen diesen Nutzen, den Business-Analyse ihnen bringen kann.

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 TREND Möbelhäuser

Die Konzepte der Business-Analyse werden anhand eines durchgängigen Beispiels veranschaulicht.

Die Möbelhauskette TREND vertreibt in ihren neun Filialen das folgende Sortiment: Möbel für Wohnzimmer, Dielen, Schlafzimmer, Küchen, für Bäder, Kinder- und Jugendzimmer, für Gärten und für Büros; daneben werden Leuchten verkauft, Dekoration, Textilien und Teppiche, Utensilien für Essen und Trinken, Kochen und für Aufbewahrung.

Das inhabergeführte Unternehmen hat sich in den letzten vierzig Jahren einen guten Namen in den jeweiligen Regionen gemacht. Die Filialen punkten mit persönlicher Beratung und kundenfreundlichem Service.

Dennoch machen die Mitbewerber dem Management Sorgen. Gerade schwedische Mitbewerber binden junge und kaufkräftige Kunden an sich. Dies bestätigen die Verkäufer in den TREND-Filialen, wenn sie nach der Altersstruktur ihrer Kunden befragt werden.

Als eine Ursache für diese Entwicklung wird der bisherige Internetauftritt vermutet (das Sortiment in den Filialen soll zu einem späteren Zeitpunkt auf Attraktivität überprüft werden). Auf der gemeinsamen Internetseite werden im Wesentlichen nur die Standorte der Filialen, ihre Öffnungszeiten und allgemeine Kontaktdaten (Telefon, Fax, E-Mail) genannt. Die wichtigsten Markenhersteller der Produkte sind nur namentlich aufgeführt. Interessenten können sich aber keine Produkte auf der Internetseite ansehen, geschweige denn bestellen. Dies verwundert vermutlich junge bzw. internetaffine Kunden und lässt sie zu anderen Möbelhäusern wechseln.

In der Hauptverwaltung arbeiten ca. 100 Personen: neben der Geschäftsführung sind dort die Buchhaltung, das Marketing, die zentrale IT-Abteilung, der zentrale Einkauf, Personalabteilung, Organisationsabteilung und das Gebäudemanagement angesiedelt (vgl. Abb. G.03).

Die neun Filialen sind nahezu gleich aufgestellt: neben den Verkäufern (inzwischen Kundenbetreuer genannt, die wechselnd auch an den Kassen eingesetzt werden), gibt es das lokale Lager, die Filialleitung mit Sekretariat, einen lokalen EDV-Techniker und eine Imbissecke, die den Kunden Getränke und eine kleine Auswahl an kalten und heißen Gerichten anbietet.

Abb. G.03: Organigramm der TREND Möbelhäuser

Bei den TREND Möbelhäusern reichen die Anforderungen vom Wunsch einer „Auswertung der Verkaufszahlen pro Möbelkategorie je Filiale“ als Ergänzung eines bestehenden Berichtswesens, über die Ablösung des bisherigen Warenwirtschaftssystems durch ein neues, bis hin zu konkreten Inhalten und zum Layout des nächsten Werbeflyers.

G.2 Anforderungen und Klassifikationsschema

G.2.1 Übersicht

Unter dem Begriff Anforderung werden in der Praxis unterschiedliche Wünsche, Bedingungen und Bedürfnisse verstanden, die von kleinen Änderungsideen über grobe Projektvorschläge bis hin zu konkret ausgearbeiteten Lösungsvorschlägen reichen. Werden Anforderungen sinnvoll zusammengefasst, um eine gewünschte Veränderung zu charakterisieren, lässt sich daraus eine zielführende Lösung entwickeln.

Eine Lösung ist die Summe der Veränderungen des Ist-Zustands eines Unternehmens, um einen Bedarf zu decken und/oder Ziele zu erreichen.

Schon seit einiger Zeit werden die Stimmen lauter, die einen Internetshop für die TREND Möbelhäuser vorschlagen. Zu dieser möglichen Lösung werden auch entsprechende Anforderungen genannt wie z.B. Möbelkonfigurator, 3D- Ansicht, Lieferung der Möbel nach Hause oder Abholung in der Filiale.

Eine Anforderung ist

(1) eine von einem Stakeholder benötigte, angeforderte oder gewünschte Beschaffenheit oder Fähigkeit einer Lösung,

(2) eine Beschaffenheit oder Fähigkeit einer Lösung, um Vorgaben von Verträgen, Standards, Spezifikationen oder anderen Dokumenten einzuhalten,

(3) eine Dokumentation der vorgenannten Beschaffenheiten oder Fähigkeiten.

(1) In den TREND Möbelhäusern werden viele Anforderungen von Stakeholdern (Anforderungsstellern) benötigt, z.B. von Filialleitern, Geschäftsführung oder Kunden. Während Management und Führungskräfte Anforderungen tatsächlich anfordern, ist dies bei anderen Stakeholdern nicht unbedingt der Fall. Gerade die Möbelkunden äußern selten aktiv ihre Bedürfnisse. Trotzdem gibt es auch bei ihnen benötigte und gewünschte Beschaffenheiten oder Fähigkeiten einer Lösung. Diese sollten umgesetzt werden. Wie viele Unternehmen lebt auch TREND davon, die Kundenbedürfnisse zu kennen und zu erfüllen.

(2) Aus Verordnungen und Gesetzen (z.B. Steuerrecht, Preisangabenverordnung) ergeben sich weitere Anforderungen, die TREND als Unternehmen zu berücksichtigen und zu erfüllen hat. Daneben gibt es z.B. auch Rahmen- und Lieferverträge mit Möbelherstellern, Großhandel und Logistikern.

(3) Immer wieder kommt es vor, dass die Business-Analysten bei TREND Anforderungen aus (1) oder (2) nicht in den Anforderungsdokumenten berücksichtigen. Dies geschieht in der Regel unbeabsichtigt und kann mehrere Gründe haben:

 Zeitmangel

 Stakeholder „benötigen“ oder „wünschen“ ihre Anforderungen zwar, äußern sie aber nicht tatsächlich und fordern sie damit nicht aktiv an.

 Bei der Fülle der eigentlich zu berücksichtigenden Dokumente und Standards werden einzelne Anforderungen nicht ermittelt. Gesetzestexte und Rahmenverträge sind so umfangreich, dass nicht immer sichergestellt werden kann, dass alle Anforderungen ins Anforderungsdokument übernommen werden.

Von Anforderungen zu unterscheiden sind Annahmen und Restriktionen, die häufig zusammen bzw. „gemischt“ mit Anforderungen während der Anforderungsermittlung von Stakeholdern genannt werden. Annahmen und Restriktionen werden in Kapitel G.2.3 skizziert und in Kapitel 2.3 „Anforderungsermittlung“ näher beschrieben.

G.2.2 Klassifikationsschema der Anforderungen

In den meisten Projekten ist eine große Anzahl von Anforderungen zu berücksichtigen. Auch Anforderungen, die nicht in Projekten umgesetzt werden (sondern z.B. in Einzelmaßnahmen oder im Tagesgeschäft), kommen sprichwörtlich „selten allein“. Deswegen sollten Anforderungen gegliedert werden, um eine Übersicht zu bekommen und Gemeinsamkeiten herauszuarbeiten. Hierzu werden unterschiedliche Kategorisierungen genutzt. Die Tabelle zeigt einige gebräuchliche Anforderungsklassen.

Anforderungen an (Benutzer-) Schnittstellen | Rechtliche Anforderungen
Vertragliche Anforderungen | Systemanforderungen
Marketing-Anforderungen | Produktanforderungen
Komponentenanforderungen | Technische Anforderungen
Anforderungen an die Entwicklung | Anforderungen an Mitarbeiter
Qualitätsanforderungen |

Abb. G.04: Gebräuchliche Anforderungsklassen

Anforderungen können sehr allgemein sein oder sehr speziell. Sehr detaillierte Anforderungen sollten nicht mit groben Anforderungen verglichen werden – die sogenannte Granularität sollte in etwa vergleichbar sein. Ansonsten besteht die Gefahr, dass „Äpfel mit Birnen verglichen“ werden.

Ein Klassifikationsschema der Anforderungen bietet eine Anforderungsstruktur. Die hier zugrunde gelegte Struktur besteht aus vier Anforderungskategorien.

Das im Folgenden erläuterte Klassifikationsschema für Anforderungen bietet Kategorien, die zum einen eine sinnvolle Gruppierung der Anforderungen auf „ihrem Lebensweg“ ermöglichen und zum anderen die Zusammenhänge zwischen den Anforderungen deutlich machen. Dabei werden insbesondere die Fragen „Warum?“, „Was?“ und „Wie?“ beantwortet.

  Warum? Geschäftsanforderungen geben darüber Auskunft, wieso eine Veränderung sinnvoll oder notwendig ist.

  Was? Stakeholder-Anforderungen verdeutlichen, welche Merkmale und Beschaffenheiten eine Lösung bieten soll.

  Wie? Lösungsanforderungen (unterschieden in funktionale und nicht-funktionale Anforderungen) beschreiben, auf welchem Weg eine Lösung die Geschäftsanforderungen erreichen soll und systematisieren dabei die Stakeholder-Anforderungen.

  Transitionsanforderungen bilden insofern eine eigene Kategorie, als sie beschreiben, wie der Übergang vom Ist- zum Soll-Zustand verlaufen soll, nachdem die Lösung zumindest grob beschrieben ist.

Abb. G.05: Klassifikationsschema der Anforderungen

G.2.2.1 Geschäftsanforderungen

Eine Geschäftsanforderung ist eine Aussage zu Zielen und erwünschten Wirkungen. Sie beschreibt die Gründe für eine Veränderung.

In den Geschäftsanforderungen finden sich die „gröbsten“ Aussagen innerhalb der vier Anforderungskategorien. Sie sind damit häufig allgemein gültige Forderungen, die es zu erfüllen gilt und die in vielen Fällen auch mittel- bis langfristig gültig bleiben. Demgegenüber können Anforderungen der anderen Anforderungsklassen in der Regel nach ihrer Umsetzung als erfüllt oder „erledigt“ betrachtet werden.

Geschäftsanforderungen beantworten die Frage „Warum?“: „Warum ist eine Veränderung des Ist-Zustands sinnvoll oder notwendig?“

Inhaber, Filialleiter und Management haben sich in einer ihrer quartalsweisen Führungskräfterunden darauf verständigt, dass für die kommenden Jahre die folgenden Geschäftsanforderungen angestrebt werden sollen:

 10 % mehr Umsatz im Vergleich zum abgelaufenen Kalenderjahr

 Steigerung des Bekanntheitsgrads in der Region

 höhere Kundenzufriedenheit, gemessen an weniger Reklamationen

 einheitliches Auftreten gegenüber den Kunden in allen neun Filialen.

Weitere Ausführungen zu Geschäftsanforderungen finden sich in Kapitel 1.3.

G.2.2.2 Stakeholder-Anforderungen

Eine Stakeholder-Anforderung ist der Bedarf, der sich aus der beruflichen Funktion der Stakeholder ergibt.

Letztlich dienen diese Anforderungen dazu, die Geschäftsanforderungen zu erreichen. Stakeholder-Anforderungen können eine Brücke zwischen Geschäfts- und Lösungsanforderungen schlagen.

Stakeholder-Anforderungen konkretisieren die Geschäftsanforderungen, indem sie die Frage beantworten „Was soll geändert oder erreicht werden, um die Geschäftsanforderungen zu erfüllen?“

Auch wenn der Begriff es suggeriert, Stakeholder-Anforderungen stammen nicht zwangsläufig von Personen oder Personengruppen (Anforderungsstellern); sie können auch aus Dokumenten, Standards oder rechtlichen Vorgaben stammen.

Nach der Führungskräfterunde wurden die Business-Analysten bei TREND beauftragt, Vorschläge dafür zu sammeln, wie die Geschäftsanforderungen erreicht werden können. Die Business-Analysten haben bei verschiedenen Stakeholdern (Filialleiter, Kunden, Mitarbeiter, Lieferanten) eine Liste mit Vorschlägen zusammengetragen, u.a.

 Marketing-Kampagne für einen größeren Bekanntheitsgrad und zur Steigerung des Umsatzes

 bessere Liefer- und Rahmenverträge sowie kulantere Reklamationsbearbeitung zur Steigerung der Kundenzufriedenheit

 standardisierte Geschäftsprozesse für einheitliches Auftreten und Arbeiten (hierbei sind u.a. Vorschriften und Standards zum Arbeitsschutz zu beachten).

Weitere Ausführungen zu Stakeholder-Anforderungen finden sich in Kapitel 2.

G.2.2.3 Lösungsanforderungen

Eine Lösungsanforderung ist eine Beschreibung der Aspekte einer Lösung, die Stakeholder-Anforderungen oder Geschäftsanforderungen erfüllt.

Lösungsanforderungen unterteilen sich in funktionale und nicht-funktionale Anforderungen. Funktionale Anforderungen beschreiben, was eine Lösung leisten soll, wie sie sich verhalten oder wie sie reagieren soll, wie sie beschaffen sein soll und welche Leistungsmerkmale sie erfüllen soll.

Nicht-funktionale Anforderungen beschreiben, unter welchen Bedingungen eine Lösung funktionieren soll.

Stakeholder-Anforderungen liegen häufig nicht in einer angemessenen Qualität und in einem geeigneten Detaillierungsgrad (Granularität) vor, so dass sie nicht direkt zur Umsetzung bzw. Entwicklung einer Lösung verwendet werden können (eine Lösung kann dabei IT-Systeme, organisatorische Änderungen oder die Optimierung von Geschäftsprozessen umfassen).

Wünsche, die „menschliche“ Stakeholder äußern, widersprechen sich unter Umständen, weil verschiedene Fachabteilungen unterschiedliche Bedürfnisse haben.

Einige Anforderungen sind schon sehr konkret, ohne den Kontext zu berücksichtigen; andere sind zu allgemein, so dass für eine Umsetzung zu viele Annahmen und Interpretationen benötigt werden.

Nicht-funktionale Anforderungen werden durch Stakeholder häufig nicht genannt, weil sie als selbstverständlich oder „zu technisch“ aufgefasst werden.

Es ist ein wesentliches Aufgabenfeld der Business-Analyse, aus (unzureichenden) Stakeholder-Anforderungen konsistente, klare, zielgerichtete Lösungsanforderungen zu entwickeln, die durch ihre Umsetzung einen (Mehr-)Wert für die Stakeholder erbringen. Dabei sollten funktionale Anforderungen idealerweise technologiefrei sein (das „Was“, nicht das „Wie“ beschreiben). Nichtfunktionale Anforderungen müssen zum Teil Aussagen zu einer Technologie treffen und damit die Lösung einschränken (synonym wird auch von Qualitätsanforderungen oder technischen Anforderungen gesprochen).

Auch in den TREND Möbelhäusern ergeben sich Widersprüche, die gelöst werden müssen: Während die Marketing-Abteilung nur noch auf Online-Werbung setzen möchte, stellen sich die Kollegen der Filialen vor, bestehende Prospekte und Printwerbung zu verbessern. Dabei gibt es schon sehr konkrete Vorschläge: „Das €-Zeichen sollte zur besseren Lesbarkeit hinter und nicht vor dem Preis stehen“.

Aus der IT kommt der Wunsch, das bestehende und in die Jahre gekommene Warenwirtschaftssystem durch ein neues zu ersetzen. Dabei bleibt zunächst völlig unklar, wie das im Detail aussehen könnte und – noch viel wichtiger – ob dieser Wunsch überhaupt zu den Geschäftsanforderungen passt. Auf Nachfrage äußert der IT-Leiter, dass u.a. nicht-funktionale Anforderungen wie „schnelle Antwortzeit“ und „leichte Wartbarkeit“ durch das aktuelle Warenwirtschaftssystem nicht mehr gegeben seien.

Lösungsanforderungen sind typischerweise detaillierter und umfangreicher als Geschäfts- oder Lösungsanforderungen (vgl. Abbildung G.06). Damit beschreiben sie eine Lösung mit mehr Inhalten und konkreter. Je konkreter eine Lösung durch die Lösungsanforderungen beschrieben ist, desto weniger Freiheit bleibt den Umsetzern dieser Lösung.

Business-Analysten sollten allerdings darauf achten, Lösungsanforderungen fachlich zu beschreiben und die konkrete (technische) Umsetzung den (IT-) Experten zu überlassen.

Abb. G.06: Determiniertheit der Lösung und Freiheitsgrad in der Umsetzung der Anforderungen

Determiniertheit im Zusammenhang mit Anforderungen beschreibt, wie stark diese Anforderungen bereits eine Lösung bzw. ihre eigene Umsetzung vorgeben. Anforderungen mit großer Determiniertheit beinhalten bereits Vorgaben, wie sie (technisch) umzusetzen sind. Anforderungen mit schwacher oder keiner Determiniertheit sind lösungs- und umsetzungsneutral beschrieben.

Weitere Ausführungen zu Lösungsanforderungen finden sich in Kapitel 2.

G.2.2.4 Transitionsanforderungen

Eine Transitionsanforderung ist eine Beschreibung der Aspekte einer Lösung, die den Übergang vom Ist-Zustand zum Soll-Zustand ermöglichen.

Transitionsanforderungen sind analog zu Stakeholder- und Lösungsanforderungen zu ermitteln, zu analysieren, zu dokumentieren und zu genehmigen. Das Besondere an Transitionsanforderungen ist, dass sie erst definiert werden können, wenn die Lösung (zumindest grob) beschrieben oder entworfen ist. Transitionsanforderungen sind in der Regel nur für den Übergang vom Ist-Zustand zur (neuen) Lösung gültig und befassen sich damit,

 wie Daten migriert werden sollen

 welche neue Qualifikation oder welche erweiterten Kompetenzen bei den Mitarbeitern notwendig sind, damit sie die Lösung nutzen können

 wie Geschäftsprozesse oder Geschäftsvorgänge fortgeführt werden, die im Ist-Zustand begonnen, aber vor Einführung der Lösung noch nicht abgeschlossen werden.

Sollte ein neues Warenwirtschaftssystem bei TREND eingeführt werden, müssen Transitionsanforderungen an die Überführung der Daten aus dem alten ins neue System definiert werden. Ob die Mitarbeiter ein neues Warenwirtschaftssystem erst nach einer Schulung und einer begleiteten Einführung nutzen können, ergibt sich u.a. aus der Benutzerfreundlichkeit des Systems und aus der optischen und technischen Nähe zum alten Warenwirtschaftssystem. Die Business-Analysten müssten u.a. prüfen, ob eine begonnene Bestellung im neuen System fortgeführt werden kann oder ob sie dort neu angelegt werden muss.

Weitere Ausführungen zu Transitionsanforderungen finden sich in Kapitel 3.2.2.

G.2.3 Annahmen und Restriktionen

Nicht alle Äußerungen seitens der Stakeholder sind tatsächlich Anforderungen.

Eine Annahme ist ein noch nicht überprüfter Einflussfaktor auf eine Lösung, die als Arbeitshypothese in die Untersuchung eingeht.

Die TREND Möbelhäuser vermuten, dass junge Kunden fehlen, da kein Online-Shop vorhanden ist. Daraus ließe sich unmittelbar eine Anforderung nach einer Verkaufsmöglichkeit im Internet ableiten. Sinnvollerweise prüfen Business-Analysten aber zunächst erst einmal diese Annahme und entscheiden dann gemeinsam mit den Stakeholdern, ob sie valide ist und weiterverfolgt werden kann, oder ob sie verworfen werden sollte.

Eine Restriktion ist eine zwingende Vorgabe, die eine Lösung einschränkt oder bestimmte Lösungskomponenten erzwingt.

Restriktionen sind wichtige Informationen. Sie werden häufig nicht in einer Lösung umgesetzt, beeinflussen diese allerdings maßgeblich. Daher sollten sie als Restriktionen kenntlich gemacht werden und nicht mit Anforderungen „vermischt“ werden.

Das Management nannte die zwingende Vorgabe, dass das bestehende Warenwirtschaftssystem nicht abgelöst wird. Zudem soll eine Lösung spätestens in 12 Monaten umgesetzt sein.

Die Unterscheidung zwischen Annahmen und Anforderungen bzw. Restriktionen und Anforderungen ist nicht immer offensichtlich. Business-Analysten fragen besser einmal mehr nach, um herauszufinden, womit sie es gerade zu tun haben.

Weitere Ausführungen zu Annahmen und Restriktionen finden sich in Kapitel 2.3 „Anforderungsermittlung“.

G.3 ibo-Anforderungstür®

G.3.1 Übersicht

Business-Analyse ist eine ganzheitliche Methode, die Veränderungen auf ihren Nutzen prüft, Anforderungen an Veränderungen ermittelt, analysiert und dokumentiert, die Einführung von Lösungen begleitet sowie die Business-Analyse selbst plant und steuert.

Die ibo-Anforderungstür® bildet das grafische Modell für die grundlegende Struktur der Business-Analyse. Sie dient dazu, den Überblick über das gesamte Thema zu gewinnen und zu bewahren. Die ibo-Anforderungstür® hat sich in den letzten Jahren als Rahmenwerk (Framework) mit Vorgehensschritten und verknüpften Techniken in Training und Praxis bewährt und etabliert. Sie dient hier als Leitfaden in der Business-Analyse und als Gliederung für dieses Buch.

G.3.1.1 Konzepte

Vier Konzepte beschreiben die Anwendungsfelder, in denen Business-Analysten tätig werden: Business-Case-Erstellung, Requirements Engineering, Lösungseinführung, Business-Analyse-Planung und -Steuerung.

Das Konzept der Business-Case-Erstellung bietet vier Schritte, in denen vorab untersucht wird, ob es sinnvoll ist, sich weiter und detaillierter mit einem Vorhaben zu beschäftigen. Dazu werden unter anderem Geschäftsanforderungen, wirtschaftliche Aspekte, der Kontext und Risiken betrachtet, die die angedachte Veränderung mit sich bringen kann.

Schwerpunkt der Arbeit von Business-Analysten ist normalerweise das Ermitteln, Dokumentieren und Analysieren von Anforderungen. Im Konzept Requirements Engineering werden sinnvolle Vorgehensschritte beschrieben, die von der Vorbereitung bis hin zur Genehmigung der Anforderungen reichen, so dass diese später umgesetzt und eingeführt werden können. Bildlich gesprochen schlägt im Requirements Engineering das Herz der Business-Analyse.

Das Konzept Requirements Engineering beschreibt den Weg der Anforderungen von der Quelle, also von denjenigen, die Anforderungen einbringen, hin zu Entwicklern und Umsetzern. Bildlich gesprochen ist das der „Hinweg“ der Anforderungen.

Das Konzept Lösungseinführung beschreibt den „Rückweg“. Die Einführung einer neu erstellten oder veränderten Lösung (sei es ein IT-System, ein Geschäftsprozess oder eine andere Veränderung im Unternehmen) muss geplant werden, damit sie möglichst gut ihre gewünschte Wirkung entfalten kann. Business-Analysten sollten die Einführung der Lösung begleiten, da sie sich intensiv mit den Anforderungen an die Lösung auseinandergesetzt haben.

Das Konzept Business-Analyse-Planung und -Steuerung ist das verbindende Konzept zu den drei anderen Konzepten, mit dem gesamten Vorgehen vom Business Case über das Requirements Engineering bis zur Lösungseinführung. Durch die Schritte Planung, Ist-Erfassung, Diagnose und Steuerung soll eine effiziente und effektive Business-Analyse sichergestellt werden.

Die verbindende Klammer zwischen Business-Analyse-Planung und -Steuerung und den drei anderen Konzepten bilden jeweils drei Handlungsfelder:

  Berufliche Handlungskompetenz, die bei der Ausführung der jeweiligen Aufgaben unterstützt (z.B. Geschäftsverständnis bei der Erstellung des Business Case). Zur beruflichen Handlungskompetenz vgl. die Einführung in Kapitel 1.8.1

 Wichtige Zielgruppen für Business-Analysten im jeweiligen Konzept (z.B. Kunden, Management)

  Ergebnistyp des jeweiligen Konzepts (z.B. Business Case als Dokument).

Abb. G.07: ibo-Anforderungstür®

Die angesprochenen Veränderungen können in unterschiedlichen Kontexten (z.B. Projekt oder Tagesgeschäft, Releases oder Einzelmaßnahmen) geschehen oder mit unterschiedlichen Vorgehensmodellen (z.B. Scrum oder Geschäftsprozessoptimierung) vorangetrieben werden.

Die ibo-Anforderungstür® kann an unterschiedlich große Veränderungen angepasst werden. Die Kapitel 1-3 geben Hinweise, wie die ibo-Anforderungstür® bei kleinen, mittleren und großen Veränderungen angewendet

wird. Zudem wird jeweils erläutert, wie das Modell in klassischen Vorgehensmodellen bzw. in agilen Vorgehensmodellen angewendet werden kann. Das Kapitel 5 „Business-Analyse in agilen Kontexten“ fasst wichtige Aspekte zu diesem Thema zusammen.

G.3.1.2 Grundprinzipien

Business-Analyse baut auf drei Grundprinzipien, die sich auch in anderen Aufgabengebieten und Disziplinen bewährt haben. Diese Grundprinzipien werden ebenfalls in der ibo-Anforderungstür® angewandt.

Zu den Grundprinzipien zählen

 das Vorgehen vom Groben zum Detail

 das Vorgehen von den Zielen zur Lösung

 rationales Entscheiden.

Vom Groben zum Detail

Bevor man sich in Details verliert und möglicherweise den Überblick verliert, sollte zunächst das Gesamtbild verstanden werden. Ansonsten besteht die Gefahr, dass man „den Wald vor lauter Bäumen nicht sieht“. Für Business-Analysen gilt deswegen der Grundsatz, erst die Gesamtzusammenhänge (das Big Picture) zu erarbeiten, bevor die Details oder die konkreten Anforderungen untersucht werden.

Der Gesamtüberblick hilft später, die einzelnen Anforderungen in das Gesamtbild einzuordnen. Dann wird auch besser ersichtlich, ob einzelne Anforderungen dazu beitragen, die Geschäftsanforderungen zu erreichen. Zudem fällt es leichter, den Aufwand für die Business-Analyse abzuschätzen, wenn klar ist, wie groß beziehungsweise wie umfangreich das anstehende Vorhaben ist.

Von den Zielen zur Lösung

Maßnahmen zu ergreifen und umzusetzen verspricht oft einen schnellen und gut sichtbaren Erfolg. Dabei tritt allerdings oft das Problem auf, dass diese ergriffenen Maßnahmen sich als nicht zielführend herausstellen. Dann wurden Zeit und Ressourcen verschwendet, manchmal ist sogar eine Verschlimmbesserung die Folge – der neue Zustand ist im Ergebnis schlechter als der alte.

Ziele beschreiben einen zukünftigen Zustand beziehungsweise erwünschte Wirkungen, ohne dabei den Weg zur Umsetzung der Ziele selbst zu beschreiben. Selbst wenn der Weg etwa durch gesetzliche, strategische oder technologische Restriktionen vorgegeben ist, sollten dennoch die Ziele geklärt werden, die am Ende erreicht werden sollen.

Die Lösung ergibt sich aus der Summe der Maßnahmen, die aus einem Ist-Zustand einen künftigen Soll-Zustand entwickeln. Häufig wird bei einer Lösung nahezu zwangsläufig an eine IT-Lösung gedacht, aber nicht alle Anforderungen erfordern unbedingt die IT. Die Business-Analyse sollte in jedem Fall eine ganzheitliche Perspektive einnehmen. Neben technischen Aspekten sollte sie auch prozessuale, strukturelle, strategische und kulturelle Aspekte einer Lösung berücksichtigen. Selbst wenn es auf eine IT-Lösung hinausläuft – was sehr oft der Fall ist – hilft die beste IT-Lösung wenig, wenn ihre Auswirkungen auf Geschäftsprozesse, Aufbauorganisation (zum Beispiel das Organigramm), ihre strategische Relevanz und Akzeptanz bei Beteiligten und Betroffenen nicht analysiert und berücksichtigt wurde.

Rationales Entscheiden

Komplett neue Lösungen zu entwickeln – auf der grünen Wiese neu zu beginnen – kann unter Umständen sehr sinnvoll sein und wirklich innovative und gute Lösungen überhaupt erst möglich machen. Solche Verbesserungen sind manchmal durch ein Vorgehen in kleinen Schritten zur Verbesserung des Ist-Zustands – empirisches Vorgehen – kaum möglich. Gleichwohl setzt die Mehrzahl der Lösungen, die in der Praxis entwickelt werden, auf den Ist-Zustand auf: Bestehende IT-Systeme, vorhandene Geschäftsprozesse, eine existierende Aufbauorganisation sollen dann weiterentwickelt werden.

Wird das Prinzip des rationalen Entscheidens für die Business-Analyse angewendet, steht eine Analyse des Ist-Zustands am Anfang. Aus ihr werden Handlungsfelder und Handlungsoptionen ersichtlich. Zunächst sollten dabei Probleme und deren Ursachen analysiert sowie Ziele formuliert werden. Erst danach sollten Verbesserungsmöglichkeiten des Ist-Zustands ermittelt und Lösungsansätze entwickelt sowie der beste Lösungsansatz weiterverfolgt werden. Rationales Entscheiden bedeutet in diesem Zusammenhang auch, dass nachvollziehbar und mit plausiblen Kriterien aufgezeigt wird, welches der beste Lösungsansatz ist. Jetzt kann entschieden werden, ob „auf der grünen Wiese“ neu gestaltet oder auf dem Bestehenden aufgebaut wird.

Alle drei Prinzipien ziehen sich durch die komplette ibo-Anforderungstür®, finden sich allerdings auch in den einzelnen Konzepten Business-Case-Erstellung, Requirements Engineering, Lösungseinführung und Business-Analyse-Planung und -Steuerung. Hier seien die wichtigsten Anwendungsfelder genannt.

Vom Groben zum Detail wird als Prinzip angewendet, indem zunächst der (gröbere) Business Case erstellt wird, bevor sich Business-Analysten im Requirements Engineering mit den detaillierteren Anforderungen beschäftigen.

Von den Zielen zur Lösung bedeutet, dass die Ziele (Geschäftsanforderungen) frühzeitig im Business Case formuliert werden, ehe über einen Lösungsansatz nachgedacht wird, dieser im Requirements Engineering näher beschrieben wird und die Lösung schließlich genutzt wird (Lösungseinführung).

Rationales Entscheiden findet sich ebenfalls in allen Konzepten wieder. Im Business Case wird beispielsweise zunächst der Ist-Zustand analysiert, bevor Lösungsansätze empfohlen werden. Im Requirements Engineering liegt dem Vorgehen (von der Vorbereitung hin zur Genehmigung) rationales Entscheiden zugrunde. In der Lösungseinführung wird die Wirksamkeit der Lösung geprüft und es wird bewertet, ob die Lösung zielgerichtet ist. In Business-Analyse-Planung und -Steuerung wird die eigene Arbeit als Business-Analyst fortlaufend daraufhin analysiert, ob sie effizient und effektiv funktioniert.

G.3.2 Business-Case-Erstellung

Abb. G.08: Business-Case-Erstellung

„Das Problem zu erkennen, ist wichtiger als die Lösung zu erkennen, denn die genaue Darstellung des Problems führt zur Lösung.“

Albert Einstein

Es gibt viele Ausgangspunkte und Auslöser für Business-Analysen, zum Beispiel:

  intern angestoßene Verbesserungsmaßnahmen

  extern ausgelöste Veränderungen, beispielsweise durch neue oder andersartige Kundenbedürfnisse oder gesetzliche beziehungsweise regulatorische Änderungen

 kleine Veränderungen, die punktuelle Chancen zur Verbesserung wahrnehmen

  große Maßnahmen, die im Rahmen von Projekten umgesetzt werden

 durch Mitarbeiter genannte Anforderungen

 durch Geschäftsführung oder Strategie initiierte Veränderungen

 eine Mischung der vorgenannten Auslöser.

Unabhängig davon, wie die Ausgangslage aussieht, sollte die Business-Analyse zuerst versuchen, das Gesamtbild zu verstehen, ehe sie sich näher mit detaillierteren Anforderungen beschäftigt und nach Wegen zu einer möglichen Lösung sucht. Ein Business Case bietet eine Struktur für ein systematisches Vorgehen an. Vier Vorgehensschritte führen von der Untersuchung und Analyse des Ist-Zustands zur Empfehlung eines Soll-Zustands. Um das Prinzip „Vom Groben zum Detail“ zu beachten, erstellt der Business-Analyst den Business Case auf „größerer Flughöhe“.

Leistungspotenziale

Im ersten Schritt der Business-Case-Erstellung analysieren Business-Analysten die Ist-Situation. Diese wird auf fehlende und bestehende Leistungspotenziale untersucht. Wo liegen aktuell Probleme, die es zu lösen gilt? Welche Ursachen führen zu diesen Problemen?

Fehlende Leistungspotenziale sind in vielen Fällen IT-Systeme beziehungsweise IT-Unterstützung, die neu zu erstellen oder zu verbessern sind. Darüber hinaus sollten allerdings auch Geschäftsprozesse, strukturelle Veränderungen und kulturelle Aspekte berücksichtigt werden.

Bei einer Fokussierung allein auf Schwächen und deren Ursachen übersieht man leicht, welche Leistungspotenziale bereits bestehen. Vorhandene Stärken sollten genutzt und nicht durch Veränderungen (leichtfertig) geopfert werden. Bestehende Leistungspotenziale können analog leistungsfähige IT-Systeme, störungsfreie Geschäftsprozesse, funktionierende Strukturen oder eine positive Kultur sein.

Die TREND Möbelhäuser haben seit einiger Zeit stagnierende und leicht rückläufige Umsätze festgestellt. Auf Vorschlag der Geschäftsführung werden nun Business-Analysten beauftragt, die Ist-Situation näher zu untersuchen. Das Problem ist durch die rückläufigen Umsätze beschrieben. Die Business-Analysten müssen nun die dahinterliegenden Ursachen analysieren.

Sie identifizieren als fehlendes Leistungspotenzial, dass Kunden im Internetauftritt von TREND nicht nach Möbeln suchen, geschweige denn diese kaufen können. Wesentliche bestehende Leistungspotenziale sind die Möbelhäuser, in denen die Kunden einen sehr guten Service erhalten. Diese vorhandenen Leistungspotenziale müssen bei allen geplanten und notwendigen Veränderungen erhalten bleiben.

Geschäftsanforderungen

Wurde die Ist-Situation auf fehlende und bestehende Leistungspotenziale untersucht, werden in einem zweiten Schritt die Geschäftsanforderungen, d.h. die Ziele formuliert. Dadurch wird der Soll-Zustand beschrieben, ohne dass bereits Maßnahmen oder Wege zur Erreichung dieses Soll-Zustands festgelegt werden. Ziele sind erwünschte Wirkungen, erwünschte Ereignisse oder Ergebnisse. Sie beschreiben, was erreicht werden soll, nicht wie es erreicht werden soll. In vielen Fällen lassen sich die Geschäftsanforderungen aus den fehlenden und bestehenden Leistungspotenzialen ableiten.

Aus dem fehlenden Leistungspotenzial „sinkende Umsätze“ formulieren die Business-Analysten „steigende Umsätze“ als eine unter mehreren Geschäftsanforderungen. Aus dem bestehenden Leistungspotenzial „guter Service in den Möbelhäusern“ wird die Geschäftsanforderung, dass dieser Service erhalten bleiben soll, unabhängig davon, welche Veränderungen beziehungsweise Lösungen bei TREND umgesetzt werden.

Die Geschäftsanforderungen sind zu vervollständigen. Die Zielklassen Wirtschaftliche Ziele, Leistungsziele, Kulturelle Ziele und Vorgehensziele können helfen, bisher nicht erkannte Ziele zu erkennen und die Sammlung zu vervollständigen (siehe dazu Kapitel 1.3).

Lösungsansätze

Lösungsansätze beschreiben grobe Wege, wie die Ist-Situation zielgerichtet verbessert und zu einem angestrebten Soll-Zustand geführt werden kann. In vielen Fällen bündeln Lösungsansätze Maßnahmen, die Veränderungen an bestehenden IT-Systemen, Geschäftsprozessen oder der Aufbauorganisation beschreiben. Im Rahmen der Erstellung eines Business Case werden mögliche Lösungsrichtungen formuliert, aus denen nach dem Schritt Empfehlung ein Lösungsansatz gewählt wird, der im Konzept Requirements Engineering detailliert und umsetzungsreif ausgearbeitet wird.

Genauso wie es diverse Ausgangssituationen für die Erstellung eines Business Case gibt, sind auch unterschiedlichste Lösungsansätze denkbar. Häufig sind die folgenden Lösungsrichtungen anzutreffen:

 Make or Buy (eine Lösung selbst erstellen oder kaufen)

 kleine, mittlere oder große Veränderung

 kurz-, mittel- oder langfristige Anpassungen

 Quick Wins (schnelle Verbesserungen).

Unabhängig vom gewählten Lösungsansatz sollte festgelegt und dokumentiert werden, was verändert werden darf, soll oder muss (in Scope), und was nicht verändert werden darf oder soll (out of Scope).

Empfehlung

Im Schritt Empfehlung fließen alle drei vorhergehenden Schritte zusammen. Es wird versucht, aus den erarbeiteten Lösungsansätzen den besten herauszufinden. Dazu wird geprüft, welcher Lösungsansatz voraussichtlich die Geschäftsanforderungen (Ziele) am besten erreichen wird. Neben einer finanziellen Analyse oder Kosten-Nutzen-Analyse wird in den meisten Fällen auch eine Risikoanalyse erstellt, welche Risiken mit den einzelnen Lösungsansätzen verbunden sind.

Handlungsfelder

Die Handlungsfelder bestehen aus den drei Komponenten berufliche Handlungskompetenz, wichtige Zielgruppe und Ergebnistyp. Die Handlungskompetenz der Business-Analysten ist gegeben, wenn sie die betrieblichen Zusammenhänge (Geschäftsverständnis) und das Big Picture verstehen. Wichtige Zielgruppe sind Kunden, seien es interne oder externe, für die eine Veränderung einen Mehrwert erbringen soll. Business-Analysten sind in den wenigsten Fällen in der Position des Entscheiders. Das Management entscheidet aufgrund des Business Case über das weitere Vorgehen. Dies kann ein Gremium sein (beispielsweise der Lenkungsausschuss eines Projekts oder ein Projekt-Portfolio-Board) oder eine Einzelperson (Führungskraft, Sponsor, Auftraggeber).

Alle vier Schritte, von den Leistungspotenzialen bis hin zur Empfehlung, fließen als Ergebnistyp dieses Konzepts im Dokument Business Case zusammen. In der Praxis werden dafür unterschiedliche Bezeichnungen verwendet, z.B. Entscheidungsvorlage, Wirtschaftlichkeitsrechnung oder eben Business Case.

Eine ausführliche Beschreibung des Konzepts Business Case findet sich in Kapitel 1.

G.3.3 Requirements Engineering

Abb. G.09: Requirements Engineering

Das zweite Konzept der ibo-Anforderungstür®ist für viele Business-Analysten das Hauptbetätigungsfeld. Die Bezeichnungen für diesen Teil der Business-Analyse sind vielfältig: Anforderungsanalyse, Anforderungsmanagement, Feinkonzept oder auch fachliche Spezifikation finden sich in der Praxis. Allen gemein ist, dass sie die Aufgaben beschreiben, die mit der Ermittlung von Anforderungen, deren Analyse und Dokumentation verbunden sind.

In diesem Konzept Requirements Engineering wird ein praxisbewährtes sechsstufiges Vorgehensmodell dargestellt, das den Prinzipien „Vom Groben zum Detail“ und „Rationales Entscheiden“ folgt.

Vorbereitung

„In allen Dingen hängt der Erfolg von den Vorbereitungen ab.“

Konfuzius

Die Vorbereitung greift auf die Ergebnisse der Planung aus dem Konzept Business-Analyse-Planung und -Steuerung zurück. Für kleinere Veränderungen wird möglicherweise auf eine Planung und Steuerung der Business-Analyse verzichtet; dann sollte die Vorbereitung allerdings besonders sorgfältig sein.

In der Vorbereitung wird insbesondere der folgende Schritt Anforderungsermittlung detaillierter geplant. Im Sinne einer rollierenden Planung werden die weiteren Schritte erst gröber und dann zunehmend detaillierter vorbereitet.

Zunächst bestimmen Business-Analysten insbesondere die Anforderungsquellen, die Inhalte, die ermittelt werden sollen, und die Techniken, mit denen die Anforderungen erhoben werden. Eine gute Vorbereitung ist für die beteiligten Stakeholder sicht- und spürbar. Die in die Vorbereitung investierte Zeit rentiert sich in vielen Fällen, weil eine strukturierte und ergebnisorientierte Herangehensweise in der Ermittlung die Vollständigkeit und die Qualität der Anforderungen fördert.

Anforderungsermittlung

Sehr gebräuchliche Techniken der Ermittlung von Anforderungen sind Workshops und Interviews. Daneben gibt es weitere bewährte Werkzeuge, die Business-Analysten nutzen können; sie werden in Kapitel 2.3 vorgestellt.

Im Zuge der Anforderungsermittlung werden neben den Anforderungen auch geschäftliche und technische Restriktionen erhoben. Sie sind wichtige Bestandteile für das zu erstellende Anforderungsdokument, sollten aber getrennt von den Anforderungen dokumentiert werden. Die Unterscheidung zwischen Anforderungen und Restriktionen ist nicht immer trennscharf und bedarf daher in vielen Fällen einer Analyse durch die Business-Analysten. Anforderungen beschreiben die zu erstellende Lösung. Sie beziehen sich in vielen Fällen auf eine gewünschte Funktionalität einer Lösung. Restriktionen schränken die Möglichkeiten, eine Lösung zu erstellen, ein oder erzwingen bestimmte Lösungsbestandteile. Eine technische Restriktion kann zum Beispiel sein, dass die Lösung auf einer vorgegebenen technologischen oder IT-Plattform zu entwickeln ist. Eine typische geschäftliche Restriktion erzwingt, dass gesetzliche Bestimmungen einzuhalten sind.

Anforderungspriorisierung

Selbst bei einer vergleichsweise groben Ermittlung der Anforderungen treten in der Regel mehrere Anforderungen zutage. Grundsätzlich besteht natürlich die Möglichkeit, mit allen erhobenen Anforderungen in die weitere Analyse einzusteigen. Manchmal ist es aber besser, erst zu klären, ob alle den gleichen Stellenwert haben oder einige Anforderungen erst einmal zurückgestellt werden.

Agile Vorgehensmodelle setzen per se darauf, nicht gleich alle Anforderungen umzusetzen, sondern schrittweise Teilergebnisse zu produzieren. Dazu werden Anforderungen immer wieder priorisiert, um die wichtigsten und dringlichsten Anforderungen zeitnah zu analysieren und umzusetzen. Zentrales Kriterium der Priorisierung ist in aller Regel der Wert beziehungsweise der Mehrwert für den Kunden. Auch bei klassischen, stufenweisen Vorgehensmodellen fordert das Grundprinzip des rationalen Entscheidens, auf die Anforderungen zu fokussieren, die eine höhere Priorität besitzen als andere.

Unabhängig vom Vorgehensmodell übersteigen normalerweise die Wünsche und Bedürfnisse der Anforderungssteller die vorhandenen Kapazitäten für deren Umsetzung. Daher ist es sinnvoll, „die Spreu vom Weizen zu trennen“ und sich besonders um die Anforderungen zu kümmern, deren Umsetzung am wahrscheinlichsten und sinnvollsten ist, bevor die Anforderungen weiter detailliert und dokumentiert werden. Dazu legen Business-Analysten zusammen mit den Stakeholdern Priorisierungskriterien fest. Zur Priorisierung der Anforderungen können eine oder mehrere Techniken eingesetzt werden (Kapitel 2.4). Ergebnis der Anforderungspriorisierung ist ein klareres Bild, welche Anforderungen zu diesem Zeitpunkt zurückgestellt werden können und welche weiteranalysiert werden sollen.

Strukturierung, Spezifizierung, Modellierung

Business-Analysten stehen verschiedene Techniken zur Dokumentation von Anforderungen zur Verfügung. Grundsätzlich kann unterschieden werden zwischen textlicher Dokumentation von Anforderungen (Spezifizierung) und der Dokumentation von Anforderungen mittels Grafiken beziehungsweise Modellen (Modellierung).

Strukturierung ist die Wahl des passenden Werkzeugs oder eines sinnvollen Mix von Dokumentationstechniken und die Zusammenstellung der „richtigen“ Anforderungen für die Spezifizierung und Modellierung.

Während in der Praxis häufig Anforderungen freihändig in Textform dokumentiert werden, werden in Kapitel 2.6 die Vorteile einer systematischen textlichen Form aufgezeigt. Im darauffolgenden Kapitel 2.7 werden dann standardisierte Modellierungstechniken erläutert, die sich für die Dokumentation von Anforderungen besonders eignen.

Verifizierung, Validierung

Grundsätzlich sollten erhobene und dokumentierte Anforderungen geprüft werden. Fehler im Anforderungsdokument können sich ansonsten bis in die Lösung fortsetzen.

Verifizierung ist die formale Überprüfung von Anforderungen auf Fehler, Redundanzen, Lücken und Widersprüche. Im Sinne des Vier-Augen-Prinzips sollte idealerweise nicht allein der Autor des Anforderungsdokuments die Anforderungen überprüfen. Grundsätzlich können das auch die Stakeholder tun. Es hat sich bewährt, dass ein oder mehrere weitere Business-Analysten (sogenannte Peers) die Verifizierung übernehmen. Da hier die rein formale Überprüfung der Anforderungen im Vordergrund steht, benötigen die Prüfer in den meisten Fällen keine detaillierten fachlichen oder inhaltlichen Kenntnisse. Ganz im Gegenteil kann ein neutraler (nicht „betriebsblinder“) Blick sogar sehr hilfreich sein.

Validierung ist die Überprüfung der Anforderungen dahingehend, ob sie zielgerichtet sind. Business-Analysten sollten einerseits prüfen, dass keine übertriebenen Anforderungen eingebracht werden (Goldrandlösung). Andererseits überprüfen sie, ob die Ziele mit den Anforderungen voraussichtlich erreicht werden können. Die Validierung führt die Geschäftsanforderungen, die das „Warum“ und damit die erwünschten Wirkungen beschreiben, mit den Stakeholder-Anforderungen und Lösungsanforderungen zusammen, die den Weg zum Ziel beschreiben („Was“ und „Wie“).

Genehmigung

Genehmigung ist die formale oder informale Abnahme der dokumentierten Anforderungen für die weiteren Schritte, insbesondere für die Umsetzung. Business-Analysten haben in den seltensten Fällen das Recht, selbst Anforderungen zu genehmigen. In klassischen Vorgehensmodellen genehmigt das Gremium (zum Beispiel Lenkungsausschuss) oder die Person (zum Beispiel Sponsor), die dem Projekt vorsteht. In agilen Vorgehensmodellen wird die Genehmigung meistens durch eine Rolle durchgeführt; in Scrum zum Beispiel durch den Product Owner.

Anforderungsmanagement

Im Laufe der Business-Analyse werden in der Regel viele Anforderungen ermittelt und weiter analysiert. Es ist sinnvoll, diese Anforderungen über deren gesamten Lebenszyklus hinweg zu verwalten, sodass sie genutzt, gepflegt und bei Bedarf weiterverwendet werden können.

Handlungsfelder

Als berufliche Handlungskompetenz hilft Business-Analysten Teamarbeit und Konfliktmanagement. Viele Aufgaben im Requirements Engineering werden gemeinsam angegangen, beispielsweise in Workshops. Wenn dabei Anforderungen und Interessen nicht übereinstimmen, können schnell Konflikte entstehen. Dann sind Kenntnisse im Konfliktmanagement hilfreich.

Die Stakeholder – also diejenigen, die ein eigenes Interesse an der Lösung haben – sind eine wichtige Zielgruppe, da deren Anforderungen zu ermitteln, zu priorisieren und zu genehmigen sind. Ihre Beteiligung und Einbindung in die Business-Analyse entscheidet in vielen Veränderungen über den Erfolg und die Akzeptanz der zu entwickelnden Lösung.

Alle Schritte im Konzept des Requirements Engineering schlagen sich im Ergebnistyp Anforderungsdokument nieder. Abhängig vom Lösungsumfang und Lösungsansatz und auch abhängig vom Vorgehensmodell und den Standards im Unternehmen können diese Dokumente unterschiedlich strukturiert und unterschiedlich umfangreich sein. In agilen Vorgehensmodellen entsteht möglicherweise kein Anforderungsdokument im herkömmlichen Sinne, sondern die Anforderungen sind wenig strukturiert und wenig detailliert dokumentiert, zum Beispiel in Form von physischen Boards (etwa auf Pinnwänden) oder mithilfe entsprechender Tools auf elektronischen Boards.

Eine ausführliche Beschreibung des Konzepts Requirements Engineering findet sich in Kapitel 2.

G.3.4 Lösungseinführung

Abb. G.10: Lösungseinführung

„Papier ist geduldig, der Leser nicht.“

Von Unbekannt

Mit dem Konzept Business-Case-Erstellung wird eine Veränderung vorbereitet und u.a. auf Sinnhaftigkeit und Wirtschaftlichkeit untersucht. Requirements Engineering liefert als Ergebnistyp ein Anforderungsdokument. Beide Konzepte beschäftigen sich mit dem zentralen Anliegen der Business-Analyse, Anforderungen zu ermitteln und zu dokumentieren, die eine Lösung und damit eine Veränderung der Ist-Situation beschreiben.

Die Umsetzung dieser Anforderungen ist nicht mehr Bestandteil der Business-Analyse. Abhängig von der Art der beschriebenen Lösung setzen andere Rollen diese um. In vielen Fällen entwickeln Mitarbeiterinnen und Mitarbeiter der IT-Abteilung entsprechende Applikationen, Systeme sowie Infrastruktur und sorgen dafür, dass sie bereitgestellt werden.

Business-Analysten spielen eine wichtige Rolle auf dem „Hinweg“, dem Weg der Anforderungen von den Anforderungsstellern zu den Umsetzern. Es erscheint logisch und sinnvoll, dass Business-Analysten auch den „Rückweg“ begleiten sollten, den Weg der entwickelten/umgesetzten Lösung von der IT-Abteilung zu den Anforderungsstellern bzw. Nutzern dieser Lösung.

Das Konzept der Lösungseinführung in der ibo-Anforderungstür® beschreibt Aspekte, bei denen Business-Analysten sinnvoll zum Einsatz kommen, da sie mindestens mit den Anforderungen und häufig auch mit der Lösung vertraut sind.

So sollte durch die Bewertung der Lösung untersucht werden, ob die Lösung die Verbesserungen erbringt, die über die Geschäftsanforderungen im Business Case definiert wurden. Eine anschließende bzw. fortlaufende Leistungsüberprüfung stellt sicher, dass die Lösung auch künftig einen (Mehr-)Wert erbringt.

Eine Ermittlung, Dokumentation und Umsetzung von Transitionsanforderungen, die den Übergang vom Ist- zum Soll-Zustand beschreiben, erleichtert die Einführung der Lösung. Dazu gehören insbesondere Überlegungen,

 wie mit Daten im Ist (bzw. in den Altsystemen) umgegangen wird, z.B. Migration auf die neue Lösung

 welche organisatorischen Veränderungen der Betroffenen und Beteiligten sinnvoll und notwendig sind, z.B. Information oder Schulungen

 wie Aufgaben, Geschäftsvorfälle und Geschäftsprozesse fortgeführt werden, die im Ist (bzw. in den Altsystemen) begonnen wurden, aber vor Lösungseinführung nicht beendet wurden.

In vielen Unternehmen reichen die Umsetzungskapazitäten nicht aus, um alle Anforderungen zeitnah zu realisieren. Business-Analysten können durch eine Zuordnung von Anforderungen zu Releases dabei mitwirken, gezielt Mehrwert zu schaffen, auch wenn nicht alle Anforderungen „sofort“ umgesetzt werden können oder sollen.

Mit der Einführung der Lösung verschieben sich häufig die Verantwortlichkeiten. Personen, die für die Entwicklung der Lösung verantwortlich waren, haben ihren Beitrag geleistet. Wurde die Lösung im Rahmen eines Projekts entwickelt, so neigt sich dieses dem Ende entgegen oder wurde beendet und der Projektleiter trägt (künftig) keine Verantwortung mehr. Dennoch ist immer sicherzustellen, dass der Betrieb der Lösung technisch verantwortet und weiter begleitet wird. Dieser Übergang von „Build“ to „Run“ funktioniert in vielen IT-Bereichen gut oder ist zumindest hinreichend geregelt. Die Übernahme von Verantwortung auf fachlicher Seite ist nicht immer gleich gut geregelt. Business-Analysten unterstützen eine möglichst reibungslose Einführung und ein klares Rollenverständnis, indem sie beispielsweise Prozessverantwortliche oder Fachbereichsleiter darauf hinweisen, dass „jemand den Hut aufhaben“ sollte.

Handlungsfelder

Als berufliche Handlungskompetenz hilft Business-Analysten Change Management, um Veränderungen auch kulturell zu begleiten.

Wichtige Zielgruppe sind Beteiligte, die mit der neuen oder veränderten Lösung umgehen müssen.

Ergebnistyp dieses Konzepts ist eine Lösung, die erfolgreich eingeführt und weiter begleitet wird.

Eine ausführliche Beschreibung des Konzepts Lösungseinführung findet sich in Kapitel 3.

G.3.5 Business-Analyse-Planung und -Steuerung

Die drei Konzepte Business-Case-Erstellung, Requirements Engineering und Lösungseinführung der ibo-Anforderungstür® bilden eine sinnvolle Reihenfolge, um den Grundprinzipien „Vom Groben zum Detail“, „Von den Zielen zur Lösung“ und „Rationales Entscheiden“ zu folgen.

Abb. G.11: Business-Analyse-Planung und -Steuerung

Das Konzept Business-Analyse-Planung und -Steuerung „begleitet“ die anderen drei Konzepte und soll sicherstellen, dass die Business-Analyse selbst effektiv und effizient durchgeführt wird. Dies gilt für Business-Analysten, die alleine eine Veränderung begleiten, ebenso wie für ein Team von Business-Analysten, das zum Beispiel in einem Projekt zusammenarbeitet.

  Planung ist die geistige Vorwegnahme zukünftigen Handelns. In diesem Sinne strukturieren Business-Analysten ihre künftigen Tätigkeiten und stimmen deren Umfang und Inhalt ab.

  Ist-Erfassung ermittelt den Status und Fortschritt der Tätigkeiten, abhängig von der Planung hinsichtlich Leistung, Qualität und Termin.

  Diagnose prüft, ob es Abweichungen zwischen Ist-Werten und Plan-Werten gibt. Bei Abweichungen suchen Business-Analysten in diesem Schritt nach Ursachen und Zusammenhängen.

 Steuerung ergreift Maßnahmen, um bei einer festgestellten Abweichung mögliche Nachteile zu minimieren. Bei kritischen Abweichungen ist möglicherweise eine Eskalation an Führungskraft oder Projektleiter der Business-Analysten notwendig. In jedem Fall sollten Business-Analysten Lessons Learned betreiben, d.h. aus „der Vergangenheit lernen“, Bewährtes für weitere Business-Analysen standardisieren und begangene Fehler für die Zukunft vermeiden.

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 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. 3rd Edition, Upper Saddle River 2012

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.