Kitabı oku: «Business-Analyse»

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.