Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Schmidt, Götz
- Kategorie: Fachliteratur
- Serie: Schriftenreihe ibo
- Sprache: Deutsch
Anforderungen an IT-Systeme, an organisatorische Veränderungen und Geschäftsprozesse spielen im beruflichen Umfeld eine wichtige Rolle. Die Umsetzung dieser Anforderungen ermöglicht es, Arbeitsabläufe zu vereinfachen, zu standardisieren und zu automatisieren. Business-Analyse schlägt die Brücke zwischen Anforderungsstellern und technischen Umsetzern der Anforderungen, zwischen Fachabteilung und IT. Business-Analyse achtet auf ein systematisches Vorgehen, um Anforderungen zu ermitteln, zu analysieren, zu dokumentieren und zu verwalten. Dabei sollte der Nutzen, den Anwender und Kunden erhalten, im Vordergrund stehen. Das Buch bietet konkrete Hilfen für eine professionelle Business-Analyse. Die in der Business-Analyse beteiligten Rollen tragen in der Wirtschaftspraxis unterschiedliche Bezeichnungen. Mit diesem Werk sind neben Business-Analysten, Anforderungsmanagern und Requirements Engineers zum Beispiel auch Fachkoordinatoren und IT-Organisatoren sowie ihre jeweiligen Führungskräfte angesprochen. Der Autor legt darauf Wert, dem Leser sowohl für kleine als auch für umfassende, komplexe Veränderungen die passenden Instrumente und Vorgehensweisen an die Hand zu geben. Business-Analyse kann sowohl bei einem klassischen Vorgehen nach dem sogenannten Wasserfallmodell wie auch in agilen Ansätzen einen wertvollen Beitrag leisten. Gerade agile Vorgehensmodelle spielen in der Softwareentwicklung eine wichtige Rolle. Neben der praxisorientierten Anwendung der Business-Analyse werden auch die Gemeinsamkeiten und Unterschiede zu verwandten Themengebieten wie Projektmanagement und Prozessmanagement herausgearbeitet. Axel-Bruno Naumann ist Trainer und Berater mit langjähriger Praxiserfahrung. Er gliedert das Buch anhand eines durchgehenden Modells. So kann jedes Kapitel in den Gesamtzusammenhang eingeordnet werden. Das Modell bietet eine Vorgehensweise, die sich in der Praxis bewährt hat. Die zugehörigen Instrumente und Methoden werden gut verständlich und anwendungsorientiert dargestellt. Ein durchgehendes Praxisbeispiel und viele Grafiken fördern das Verständnis und erleichtern die Umsetzung in der täglichen Arbeit.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 532
Veröffentlichungsjahr: 2018
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
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
1Business-Case-Erstellung
1.1Einleitung
1.1.1Startpunkte für Veränderungen
1.1.2Skalierbarkeit von Business Cases
1.1.3Vier Schritte zur Business-Case-Erstellung
1.2Leistungspotenziale
1.2.1Überblick
1.2.2Problembeschreibung
1.2.2.1Verbale Bewertung
1.2.2.2SWOT-Analyse
1.2.2.3World Café
1.2.2.4Kompakte Problembeschreibung
1.2.2.5Ausführliche Problembeschreibung
1.2.3Linear-kausale Ursachenanalyse
1.2.3.15W-Technik (5 Why)
1.2.3.2Vorgelagerte Ursachen
1.2.3.3Ishikawa-Diagramm
1.2.4Komplexe Ursachenanalyse
1.2.4.1Ursache-Wirkungs-Diagramm
1.2.4.2Papiercomputer
1.2.4.3Portfolio-Analyse
1.2.4.4Schwachstellenanalyse
1.2.5Zusammenfassung
1.3Geschäftsanforderungen
1.3.1Überblick
1.3.2Zielformulierungsprozess
1.3.2.1Zielideen suchen
1.3.2.2Ziele analysieren und Zielstruktur aufbauen
1.3.2.2.1Lösungen durch Ziele ersetzen
1.3.2.2.2Muss-Ziele von Kann-Zielen trennen
1.3.2.2.3Bezug zur Veränderung prüfen
1.3.2.2.4Redundanzen eliminieren
1.3.2.2.5Zielwidersprüche beseitigen
1.3.2.2.6Geeignete Oberbegriffe suchen und vervollständigen
1.3.2.2.7Ziele operationalisieren
1.3.2.3Ziele gewichten
1.3.2.4Zielstruktur entscheiden und im Business Case dokumentieren
1.4Lösungsansätze
1.4.1Überblick
1.4.2Lösungsumfang bestimmen
1.4.2.1Scope-Modellierung
1.4.2.2Scope-Modellierung nach außen
1.4.2.3Scope-Modellierung nach innen
1.4.2.3.1Organigramm
1.4.2.3.2SIPOC
1.4.2.3.3Datenflussdiagramm
1.4.2.3.4Systemdiagramm
1.4.3Lösungsvarianten ermitteln
1.4.3.1Spannbreite möglicher Lösungsvarianten
1.4.3.2Art der Lösungsvarianten
1.4.3.3Techniken zur Ermittlung von Lösungsvarianten
1.4.3.4Empirische, konvergente Techniken zur Ermittlung von Lösungsvarianten
1.4.3.5Kreative, divergente Techniken zur Ermittlung von Lösungsvarianten
1.4.3.5.1Mechanismen von Kreativitätstechniken
1.4.3.5.2Regeln für Kreativitätstechniken
1.4.3.5.3Brainstorming
1.4.3.5.4Brainwriting
1.4.3.5.5Brainstorming paradox (Kopfstand)
1.4.3.5.6Sechs Hüte (De-Bono-Denkhüte)
1.4.3.5.7Morphologische Analyse
1.4.3.5.8Freie Analogie
1.4.3.5.9Scamper
1.4.3.6Überkreuz-Workshop
1.4.4Zusammenfassung
1.5Empfehlung
1.5.1Überblick
1.5.2Entscheidungsanalyse
1.5.2.1Nicht-monetäre Ergebnisse
1.5.2.2Kapitalwert, Barwert, Discounted Cashflow
1.5.2.3Interner Zinsfuß
1.5.2.4Amortisationsdauer
1.5.2.5Durchschnittliche Rendite
1.5.2.6Nutzwert-Analyse
1.5.2.7Kosten-Nutzen-Analyse
1.5.3Risikoanalyse
1.5.3.1Risikoportfolio
1.5.3.2Risikotabelle
1.6Business Case
1.7Zielgruppe
1.8Handlungskompetenz
1.8.1Einführung
1.8.2Geschäftsverständnis
Literatur zu Kapitel 1
2Requirements Engineering
2.1Einleitung
2.2Vorbereitung
2.2.1Anforderungsquellen
2.2.2Einflussfaktoren bei der Anforderungsermittlung
2.2.2.1Menschliche Einflussfaktoren
2.2.2.2Organisatorische Einflussfaktoren
2.2.2.3Fachliche/inhaltliche Einflussfaktoren
2.2.3Ermittlungsinhalte
2.2.3.1Checkliste mit grundlegenden Fragen
2.2.3.2Würfel der Ermittlungsinhalte
2.2.4Wahl der Erhebungstechniken
2.3Anforderungsermittlung
2.3.1Erhebung durchführen
2.3.1.1Befragungstechniken
2.3.1.1.1Checkliste
2.3.1.1.2Gliederung
2.3.1.1.3Interview
2.3.1.1.4Workshop
2.3.1.2Beobachtungstechniken
2.3.1.2.1Fremdbeobachtung
2.3.1.2.2Selbstbeobachtung
2.3.1.3Weitere Techniken
2.3.2Annahmen, geschäftliche und technische Restriktionen identifizieren
2.3.2.1Annahmen
2.3.2.2Geschäftliche Restriktionen
2.3.2.3Technische Restriktionen
2.3.3Erhebung dokumentieren
2.3.3.1User-Story
2.3.3.2Story-Dekomposition
2.3.3.3Story-Elaboration mit Abnahmekriterien
2.3.3.4Story-Map
2.3.3.5Glossar
2.3.4Ergebnisse der Erhebung bestätigen lassen
2.4Anforderungspriorisierung
2.4.1Überblick
2.4.2Priorisierungskriterien
2.4.3Priorisierungstechniken
2.4.3.1MoSCoW
2.4.3.2Big-Wall-Verfahren
2.4.3.3Planning Poker
2.4.3.4Business Value Game
2.4.3.5Präferenzmatrix
2.4.3.6Abstimmung
2.4.3.7Kano-Modell
2.4.3.8Kano-Analyse
2.4.3.9Magic Estimation
2.4.3.10Team Estimation Game
2.4.3.11Zusammenfassung
2.5Strukturierung
2.5.1Möglichkeiten der Strukturierung
2.5.2Techniken der Spezifizierung und Modellierung
2.5.3Kriterien zur Auswahl von Dokumentationstechniken
2.5.4Prinzipien der Dokumentation
2.5.5Zusammenfassung
2.6Spezifizierung
2.6.1Hauptprobleme mit Anforderungen in natürlicher Sprache
2.6.2Funktionale versus nicht-funktionale Anforderungen
2.6.3Funktionale Anforderungen
2.6.3.1Kurzschema für universelle funktionale Anforderungen
2.6.3.2Schema für nicht-universelle funktionale Anforderungen
2.6.3.3Optionale Ergänzungen
2.6.3.4Abnahmekriterien für funktionale Anforderungen
2.6.4Nicht-funktionale Anforderungen
2.6.4.1Kategorien nicht-funktionaler Anforderungen
2.6.4.2Nicht-funktionale Anforderungen herleiten
2.6.4.3Nicht-funktionale Anforderungen dokumentieren
2.6.5Zusammenfassung
2.7Modellierung
2.7.1Eigenschaften von Modellen
2.7.2Kontextdiagramm
2.7.3Use-Case-Diagramm
2.7.4Use-Case-Beschreibung
2.7.5Prozessmodellierung
2.7.5.1BPMN-Diagramm
2.7.5.2Weitere Notationen zur Prozessmodellierung
2.7.5.2.1Folgeplan
2.7.5.2.2Ereignisgesteuerte Prozesskette
2.7.5.2.3UML-Aktivitätsdiagramm
2.7.5.3Vorgehen und Tipps
2.7.6Datenmodellierung
2.7.7Prototyping
2.7.8Weitere Modelle
2.7.9Zusammenfassung
2.8Verifizierung, Validierung
2.8.1Überblick
2.8.2Verifizierung
2.8.2.1Statische Verifizierungstechniken
2.8.2.2Dynamische Verifizierungstechniken
2.8.2.3Dokumentationsabgleich
2.8.3Validierung
2.8.3.1House of Quality (HoQ)
2.8.3.2Quality Function Deployment (QFD)
2.8.4Zusammenfassung
2.9Genehmigung
2.10Anforderungsmanagement
2.10.1Überblick
2.10.2Anforderungen weiterverwenden
2.11Anforderungsdokument
2.11.1Ausrichtung eines Anforderungsdokuments
2.11.2Gliederung eines Anforderungsdokuments
2.11.3Lastenheft und Pflichtenheft
2.12Zielgruppe
2.13Handlungskompetenz
Literaturzu Kapitel 2
3Lösungseinführung
3.1Einleitung
3.2IT
3.2.1Zuordnung von Anforderungen
3.2.2Transitionsanforderungen
3.3Kultur
3.4Ziele und Struktur
3.4.1Prozesse
3.4.2Lösungsbewertung und Leistungsüberprüfung
3.4.2.1Kennzahlen
3.4.2.2Ist-Werte
3.4.2.3Maßnahmen
3.5Lösung
3.5.1Checkliste
3.5.2Dokumente
3.6Zielgruppe
3.7Handlungskompetenz
Literatur zu Kapitel 3
4Business-Analyse-Planung und -Steuerung
4.1Einleitung
4.2Planung
4.2.1Überblick
4.2.2Stakeholder-Analyse
4.2.2.1Ablauf der Stakeholder-Analyse
4.2.2.2RACI-Matrix und Stakeholder-Tabelle
4.2.2.3Stakeholder-Portfolio
4.2.2.4Persona
4.2.3Aufgaben
4.2.3.1Aufgaben und Ergebnisse
4.2.3.2Zeitaufwand
4.2.3.3Kommunikation
4.2.4Anforderungsmanagement
4.2.4.1Anforderungsrepositorium
4.2.4.2Verfolgbarkeit (Traceability)
4.2.4.3Anforderungsattribute
4.2.4.4Anforderungspriorisierung
4.2.4.5IT-Change-Management
4.3Ist-Erfassung, Diagnose, Steuerung
4.3.1Überblick
4.3.2Aufgabenbericht
4.3.3Taskboard
4.3.4Gruppenprozessanalyse
4.4Zusammenfassung
Literatur zu Kapitel 4
5Business-Analyse in agilen Kontexten
5.1Einleitung
5.2Business-Analysten in Scrum
5.2.1Scrum im Überblick
5.2.2Rollen in Scrum
5.2.3Einsatz von Business-Analysten in Scrum
5.3CONNY-Prinzip für agile Business-Analyse
5.3.1Collaborate and improve continuously
5.3.1.1Collaborative Games
5.3.1.2Retrospektive
5.3.2Only the customer counts
5.3.3Negotiate what is valuable to the customer
5.3.4.1Planungs-Workshop
5.3.4.2Schätzung
5.3.5You should not waste
Literatur zu Kapitel 5
6Business-Analyse in weiteren Kontexten
6.1Einleitung
6.2Organisatorische Einbettung von Business-Analysten
6.3Business-Analysten im Projektmanagement
6.3.1Abgrenzung der Rollen Projektleiter und Business-Analyst
6.3.2Business-Analyse vor Projektstart und nach Projektende
6.3.3Projektleiter und Business-Analyst in Personalunion
6.4Business-Analysten im Prozessmanagement
6.4.1Überblick zu Prozessmanagement
6.4.2Überblick zu Business-Analyse
6.4.3Prozessmanagement und Business-Analyse im Vergleich
6.5Positionierung von Business-Analysten
6.5.1ibo-Positionierungswürfel
6.5.2Business-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:
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
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.
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:
ZeitmangelStakeholder „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.
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.
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 KalenderjahrSteigerung des Bekanntheitsgrads in der Regionhöhere Kundenzufriedenheit, gemessen an weniger Reklamationeneinheitliches 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 Umsatzesbessere Liefer- und Rahmenverträge sowie kulantere Reklamationsbearbeitung zur Steigerung der Kundenzufriedenheitstandardisierte 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,
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:
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
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:
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:
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 erzwingenbestimmte 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,
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.
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:
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,
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:
