sgo-verein.ch › wp-content › uploads › sites › 2 › ...business analysis body of knowledge...

BABOK®

Leitfaden zur Business-Analyse BABOK® Guide 3.0

Deutsche Übersetzung von:

A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE®

Verlag Dr. Götz Schmidt, Gießen 2017

v3

International Institute of Business Analysis, Toronto, Ontario, Canada.

©2005, 2006, 2008, 2009, 2015 International Institute of Business Analysis. All rights reser-ved.

Version 1.0 and 1.4 published 2005. Version 1.6 Draft published 2006. Version 1.6 Finalpublished 2008. Version 2.0 published 2009. Version 3.0 published 2015.

This document is provided to the business analysis community for educational purposes.IIBA® does not warrant that it is suitable for any other purpose and makes no expressed orimplied warranty of any kind and assumes no responsibility for errors or omissions. No liabilityis assumed for incidental or consequential damages in connection with or arising out of theuse of the information contained herein.

IIBA®, the IIBA® logo, BABOK® and Business Analysis Body of Knowledge® are registeredtrademarks owned by International Institute of Business Analysis. CBAP® is a registered certi-fication mark owned by International Institute of Business Analysis. Certified Business AnalysisProfessional, EEP and the EEP logo are trademarks owned by International Institute of BusinessAnalysis.

Archimate® is a registered trademark of The Open Group in the US and other countries.

Business Model Canvas is copyrighted by BusinessModelGeneration.com and released underCreative Commons license.

CMMI® is a registered trademark of Carnegie Mellon University.

COBIT® is a trademark of the Information Systems Audit and Control Association and the ITGovernance Institute.

Mind Map® is a registered trademark of the Buzan Organization.

Scaled Agile Framework® and SAFe™ are trademarks of Scaled Agile, Inc.

TOGAF® is a registered trademark of The Open Group in the US and other countries.

Unified Modelling Language™ and UML® are trademarks of the Object Management Group.

Zachman Framework for Enterprise Architecture is a trademark of the Zachman Institute forFramework Advancement.

No challenge to the status or ownership of these or any other trademarked terms containedherein is intended by the International Institute of Business Analysis.

Dieses Werk ist die deutsche Übersetzung vonBABOK® v3

A GUIDE TO THE BUSINESS ANALYSIS BODY OFKNOWLEDGE®

des IIBA® International Institute of Business AnalysisTM

Übersetzt und bearbeitet durch: EABA European Association of Business Analysis

IIBA® Chapter ÖsterreichIIBA® Chapter Schweiz

Österreichische Vereinigung für Organisation und ManagementSchweizerische Gesellschaft für Organisation

Verantwortliche Übersetzer:Gerd Nanz, Götz Schmidt

Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. JedeVerwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohneZustimmung von IIBA®, vertreten durch EABA, unzulässig und strafbar. Dasgilt insbesondere für Vervielfältigungen, Übersetzungen und die Speicherungund Verarbeitung in elektronischen Systemen.

Die in dieser Arbeit wiedergegebenen Gebrauchsnamen, Warennamen usw.sind auch ohne besondere Kennzeichnung nach der Warenzeichen- und Mar-kenschutzgesetzgebung als geschützt zu betrachten.

Amerikanische FassungBABOK® V3 A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE®

ISBN-13: 978-1-927584-02-6

Deutsche FassungDas Copyright der deutschen Übersetzung liegt bei© International Institute of Business Analysis 2017

Deutsche Übersetzung:ISBN: 978-3-945997-03-1

Vorwort VI

Kapitel 1: Einleitung 1

1.1 Zweck des BABOK®-Leitfadens 11.2 Was ist Business-Analyse? 21.3 Wer ist ein Business-Analyst? 31.4 Aufbau des BABOK®-Leitfadens 4

Kapitel 2: Schlüsselkonzepte der Business-Analyse 13

2.1 Kernkonzept-Modell der Business-Analyse 142.2 Kernbegriffe 172.3 Klassifikationsschema von Anforderungen 182.4 Stakeholder 192.5 Anforderungen und Designs 22

Kapitel 3: Planung und Überwachung der Business-Analyse 25

3.1 Ansatz der Business-Analyse planen 283.2 Einbindung der Stakeholder planen 363.3 Steuerung der Business-Analyse planen 433.4 Informationsmanagement der Business-

Analyse planen 493.5 Leistungsverbesserungen der

Business-Analyse ermitteln 55

I

Inhaltsverzeichnis

Kapitel 4: Erhebung und Zusammenarbeit 61

4.1 Erhebung vorbereiten 654.2 Erhebung durchführen 704.3 Erhebungsergebnisse bestätigen 764.4 Business-Analyse-Informationen

kommunizieren 794.5 Zusammenarbeit mit Stakeholdern

managen 83

Kapitel 5: Management des Anforderungs-Lebenszyklus 89

5.1 Anforderungen rückverfolgen 935.2 Anforderungen pflegen 985.3 Anforderungen priorisieren 1025.4 Änderungen von Anforderungen

beurteilen 1085.5 Anforderungen genehmigen 112

Kapitel 6: Strategische Analyse 117

6.1 Ist-Zustand analysieren 1216.2 Soll-Zustand definieren 1306.3 Risiken bewerten 1416.4 Change-Strategie definieren 147

Kapitel 7: Anforderungsanalyse und Design-Definition 157

7.1 Anforderungen spezifizieren und modellieren 161

7.2 Anforderungen verifizieren 1677.3 Anforderungen validieren 1717.4 Anforderungsarchitektur definieren 1747.5 Design-Optionen definieren 180

II

Inhaltsverzeichnis

7.6 Nutzenpotential analysieren und Lösung empfehlen 185

Kapitel 8: Lösungsbewertung 193

8.1 Lösungs-Performance 1978.2 Leistungskennzahlen analysieren 2018.3 Einschränkungen der Lösung beurteilen 2068.4 Einschränkungen des Unternehmens

beurteilen 2118.5 Maßnahmen zur Steigerung des Nutzens

der Lösung empfehlen 217

Kapitel 9: Basiskompetenzen 223

9.1 Analytisches Denken und Problemlösung 2239.2 Verhalten 2309.3 Geschäftsverständnis 2369.4 Kommunikationsfähigkeit 2419.5 Interaktionsfähigkeit 2459.6 Werkzeuge und Technologie 250

Kapitel 10: Techniken 257

10.1 Akzeptanz- und Bewertungskriterien 25710.2 Backlog Management 26110.3 Balanced Scorecard 26410.4 Benchmarking und Marktanalyse 26710.5 Brainstorming 26910.6 Betriebliche Fähigkeitsanalyse 27210.7 Business Case 27710.8 Darstellung des Geschäftsmodells 28010.9 Analyse der Geschäftsregeln 28510.10 Gemeinschaftliche Spiele 288

III

Inhaltsverzeichnis

10.11 Begriffsmodellierung 29110.12 Data Dictionary 29310.13 Datenflussdiagramme 29510.14 Data Mining 30010.15 Datenmodellierung 30410.16 Entscheidungsanalyse 30910.17 Entscheidungsmodellierung 31310.18 Dokumentenanalyse 31810.19 Schätzung 32010.20 Finanzanalyse 32410.21 Fokusgruppen 33010.22 Funktionale Gliederung 33310.23 Glossar 33710.24 Schnittstellenanalyse 33910.25 Interview 34210.26 Item Tracking 34610.27 Lessons Learned 34810.28 Kennzahlen und Key-Performance-

Indikatoren 34910.29 Mind Mapping 35310.30 Analyse nicht-funktionaler

Anforderungen 35610.31 Beobachtung 35910.32 Organisationsmodellierung 36210.33 Priorisierung 36610.34 Prozessanalyse 36910.35 Prozessmodellierung 37310.36 Prototyping 38010.37 Reviews 38310.38 Risikoanalyse und -management 38710.39 Rollen- und Zuständigkeitsmatrix 39110.40 Ursachenanalyse 394

IV

Inhaltsverzeichnis

10.41 Scope-Modellierung (Modellierung der Systemgrenzen) 397

10.42 Sequenzdiagramme 40110.43 Stakeholder-Listen, -Karten oder

Personas 40510.44 Statusmodellierung 40910.45 Umfrage oder Fragebogen 41310.46 SWOT-Analyse 41610.47 Use Cases und Szenarien 41910.48 User Stories 42310.49 Anbieter-Assessment 42510.50 Workshops 427

Kapitel 11: Perspektiven 43111.1 Die agile Perspektive 43211.2 Die Business-Intelligence-Perspektive 44811.3 Die Informationstechnologie-Perspektive 46311.4 Die Geschäftsarchitektur-Perspektive 48011.5 Die Business-Process-Management-

Perspektive 498

Anhang A: Glossar 519

Anhang B: Techniken mit Aufgabenzuordnung 537

Anhang C: Contributors 557

Anhang D: Summary of Changes from 567BABOK® Guide v2.0

Stichwortverzeichnis 577

V

Inhaltsverzeichnis

Das im Oktober 2003 in Toronto, Kanada, gegründete IIBA® (InternationalInstitute of Business AnalysisTM) unterstützt die Community der Business-Analystendabei,

• den Wert und die Arbeit der Business-Analysten bewusst zu machen und deren Leistung anzuerkennen

• einen „Business Analysis Body of Knowledge® (BABOK®)“ zu erarbeiten• ein Forum zur Weiterentwicklung und zum Wissensaustausch für den Beruf des Business-Analysten zu schaffen

• fachlich qualifizierte Experten der Business-Analyse anzuerkennen und diese Anerkennung durch ein international etabliertes Zertifikat zu

bescheinigen.

Das Body of Knowledge Committee wurde im Januar 2004 gebildet, um einenglobalen Standard für den Beruf des Business-Analysten zu entwerfen. Im Januar2005 hat das IIBA® die Version 1.0 des „A Guide to the Business Analysis Bodyof Knowledge®“ mit einem Gliederungsvorschlag und zentralen Definitionenveröffentlicht und dazu Feedback und Kommentare eingeholt. Die im Oktober2005 veröffentlichte Version 1.4 enthielt bereits vorläufige Inhalte zu einzelnenWissensgebieten. Die im Juni 2006 als Entwurf veröffentlichte Version 1.6 (aktua-lisiert im Oktober 2008) beinhaltete detaillierte Informationen zu den meistenWissensgebieten.

Die Version 2.0 entstand mithilfe von Arbeitsgruppen, Experten der Business-Analyse und Feedback aus öffentlichen Reviews. Version 2.0 führte neue Konzepteein wie zum Beispiel das Klassifikationsschema von Anforderungen und Input-Out-put-Modelle. Version 2.0 wurde 2009 veröffentlicht und entwickelte sich zu einemglobal anerkannten Standard für die praktische Arbeit der Business-Analyse.

Auf der Grundlage der Version 2.0 hat das IIBA® erneut umfangreiches Feedbackvon Fachexperten und angrenzenden Berufsgruppen eingeholt. Das Body ofKnowledge Committee arbeitete mit Expertenteams daran, die Inhalte zu über-prüfen und zu aktualisieren. Dieser überarbeitete Entwurf des „A Guide to theBusiness Analysis Body of Knowledge® (BABOK®)“ wurde für ein umfassendesReview freigegeben. Tausende Rückmeldungen flossen in die hier vorliegendeVersion 3.0 ein.

Ziele der Revision des BABOK® waren es,• neue Konzepte und Praktiken zu berücksichtigen, die seit der letzten Version entstanden waren

VI

Vorwort

• dabei die größere Reichweite der Business-Analyse und die Weiterentwicklung des Fachgebietes zu berücksichtigen

• Lessons Learned der Nutzer der vorhergehenden Version zu berück-sichtigen

• die Lesbarkeit und Anwendbarkeit zu steigern• die Konsistenz und Qualität von Text und Abbildungen zu verbessern• die Wissensgebiete besser zu integrieren und Überschneidungen zu beseitigen

• Konsistenz mit anderen Standards zu verbessern, die im Zusammen-hang mit der Business-Analyse stehen.

Die wichtigsten Änderungen dieser Version sind: • die Berücksichtigung des Business Analysis Core Concept ModelTM

(BACCMTM)• der größere Einfluss der Rolle der Business-Analyse bei der Schaffung besserer Ergebnisse

• die Integration von Perspektiven, in denen spezialisierte Wege beschrieben werden, auf denen der Business-Analyst für ein Unter-nehmen Werte schaffen kann

• neue und erweiterte grundlegende Kompetenzen, aus denen die unterschiedlichen Sets von Fähigkeiten des Business-Analysten deutlichwerden

• neue Techniken, die sich in der Praxis der Business-Analyse entwickelt haben oder in sie übernommen wurden.

Diese Publikation ersetzt die Version 2.0 des „A Guide to the Business AnalysisBody of Knowledge® (BABOK®)“.

Der BABOK® -Leitfaden enthält die Beschreibung allgemein akzeptierter Praktikenin Bereich der Business-Analyse. Der Inhalt dieser Version wurde durch Reviewsvon Praktikern, Erhebungen in der Community der Business-Analyse und durchBeratungen mit Experten des Fachgebietes überprüft und verifiziert. IIBA® verfügtüber Daten, mit denen sich zeigen lässt, dass die hier beschriebenen Aufgabenund Techniken von der Mehrheit der praktizierenden Business-Analysten genutztwerden. So ist die Behauptung berechtigt, dass die hier beschriebenen Aufgabenund Techniken in nahezu allen Kontexten, in denen Business-Analysen stattfinden,genutzt werden können.

Der BABOK®-Leitfaden soll aber nicht den Eindruck erwecken, als wenn die hierbeschriebenen Praktiken immer und unter allen Umständen auch umgesetztwerden müssen. Immer müssen die konkreten Bedingungen beachtet werden,unter denen Business-Analyse stattfindet. Auch können derzeit noch nicht all-gemein akzeptierte Praktiken ebenso nützlich oder sogar nützlicher sein als die

Vorwort

VII

hier beschriebenen. Wenn solche Praktiken sich weiter verbreiten, werden sie inspätere Auflagen des BABOK®-Leitfadens aufgenommen. Das IIBA® ermutigtalle Praktiker der Business-Analyse, für neue Entwicklungen und Ideen offen zusein, und ermuntert zu Innovation in diesem Gebiet.

Das IIBA® und die Community der Business-Analyse möchten allen danken, diefür die Entwicklung dieser Version Zeit und Mühen aufgewendet haben, aberauch jenen, die auf anderen Wegen informelles Feedback gegeben haben.

Die deutsche Fassung des IIBA® BABOK® wurde von den Österreichischen undSchweizer Chaptern des IIBA®‚ der „Österreichische Vereinigung für Organisationund Management“ (ÖVO) und „Schweizerische Gesellschaft für Organisationund Management“ (SGO) übersetzt. Federführend verantwortlich für die Über-setzung sind Gerd Nanz und Götz Schmidt. Folgende Personen haben Teile derVersion 3.0 übersetzt: Jean-Claude Brunner, Wolfgang Lachkovics, Frederik Muth,Gerd Nanz, Axel-Bruno Naumann, Götz Schmidt, David Steinmetz. An den fach-lichen Reviews waren neben den oben genannten Übersetzern folgende Personenbeteiligt: Peter Gerstbach, Linda Perkal, Jörg Rainer, Michael Reiter, Sonja Schuster,Michael Zambiasi.

Dieser BABOK® ist die Basis für die individuelle Zertifizierung von Business-Ana-lysten in den deutschsprachigen Ländern. Die Zertifizierung wird gemeinsammit dem IIBA® vorgenommen, so dass es weltweit einen Standard und eineglobal akzeptierte individuelle Zertifizierung zum Business-Analysten gibt.

Hinweis: In diesem Leitfaden wird immer nur die männliche Form verwendet(z.B. Experte, Analytiker, Projektmanager). Dies geschieht ausschließlich ausGründen der sprachlichen Qualität des Textes. Selbstverständlich sind in all diesenFällen auch die weiblichen Adressaten oder Rollen gemeint.

Hier wird der Begriff „Organization“ mit Organisation übersetzt. Organisationsteht für jedes System, in dem Business-Analyse stattfindet oder stattfindenkann. Zu dem Begriff Organisation gehören in dieser Publikation neben Unter-nehmen auch Behörden, Verwaltungen, Vereine, gemeinnützige Einrichtungenusw. Damit können allerdings Verwechslungen mit dem strukturellen BegriffOrganisation (gleichbedeutend mit Struktur, Aufbau, Prozessorganisation) ent-stehen.

Vorwort

VIII

1

Der Leitfaden zur Business-Analyse (Guide to the Business Analysis Body ofKnowledge®, BABOK® Guide) ist der weltweit anerkannte Standard für die Praxisder Business-Analyse. Der BABOK®-Leitfaden beschreibt die Wissensgebiete derBusiness-Analyse (knowledge areas), Aufgaben (tasks), zugrunde liegende Basis-kompetenzen (underlying competencies), Techniken (techniques) und Perspektiven(perspectives), die dazu dienen, die Business-Analyse zu bewältigen.

Zweck des BABOK®-LeitfadensDer wesentliche Zweck dieses Leitfadens ist es, die Berufspraxis der Business-Analyse zu definieren und eine Zusammenstellung allgemein akzeptierter Praktikenanzubieten. Der Leitfaden hilft Praktikern, die Fähigkeiten zu diskutieren und zudefinieren, die notwendig sind, um Business-Analyse effektiv durchzuführen. Erhilft ebenfalls allen, die mit Business-Analysten zusammenarbeiten oder diesebeschäftigen, zu verstehen, welche Fähigkeiten und welches Wissen sie voneinem erfahrenen Business-Analysten erwarten können.

Business-Analyse ist ein weit gefasstes Berufsbild, in dem Business-Analystenfür verschiedene Vorhaben in Unternehmen tätig werden können. Praktikerkönnen dabei unterschiedliche Kompetenzen, Fähigkeiten, Begrifflichkeiten,Eigenschaften sowie unterschiedliches Wissen einsetzen, wenn sie Aufgabender Business-Analyse ausüben. Der BABOK®-Leitfaden enthält einen allgemeinenBezugsrahmen (framework) für alle relevanten Perspektiven. Er beschreibt dazudie Aufgaben der Business-Analyse, die ausgeübt werden, um eine Veränderungangemessen zu analysieren oder die Notwendigkeit einer Veränderung zu bewer-ten. Die konkrete Ausprägung dieser Aufgaben, ihre Reihenfolge und ihre relativeWichtigkeit mögen dabei durchaus variieren, je nachdem, wer ein Vorhabenübernimmt oder um welches Vorhaben es sich im einzelnen Fall handelt.

Die sechs Wissensgebiete des BABOK®-Leitfadens (Planung und Überwachungder Business-Analyse, Erhebung und Zusammenarbeit, Management des Anfor-derungs-Lebenszyklus, Strategische Analyse, Anforderungsanalyse und Design -

Einleitung1

1.1

Definition, Lösungsbewertung) beschreiben die Ausübung der Business-Analyseinnerhalb eines Projektes oder bei der Weiterentwicklung oder kontinuierlichenVerbesserung eines Unternehmens. Die nachfolgende Grafik zeigt, wie drei derWissensgebiete die Bereitstellung betrieblicher Werte bzw. betrieblichen Nutzens(business value) vor, während und nach dem Lebenszyklus eines Projekts unter-stützen.

Abb. 1.1.1: Business-Analyse über Projekte hinaus

Was ist Business-Analyse?Business-Analyse ist die Tätigkeit, Change in einem Unternehmen zu ermög -lichen, indem sie Bedarfe definiert und Lösungen empfiehlt, die den StakeholdernNutzen bringen. Business-Analyse ermöglicht es einem Unternehmen, Bedarfeund Gründe für Veränderung zu artikulieren und Lösungen zu entwerfen undzu beschreiben, die für das Unternehmen wertvoll/wertschöpfend sind.

Business-Analyse wird in verschiedenen Vorhaben in einem Unternehmen aus-geübt. Die Vorhaben können strategischer, taktischer oder operativer Art sein.Business-Analyse kann innerhalb eines Projektes ausgeübt werden oder bei derWeiterentwicklung eines Unternehmens und dessen kontinuierlicher Verbesserung.Sie kann eingesetzt werden, um den Ist-Zustand zu verstehen, den Soll-Zustandzu definieren und die benötigten Aufgaben zu bestimmen, um vom Ist- zumSoll-Zustand zu kommen.

Business-Analyse kann aus verschiedenen Perspektiven durchgeführt werden.Der BABOK®-Leitfaden beschreibt mehrere dieser Perspektiven: Agil, BusinessIntelligence, IT, Geschäftsarchitektur und Business Process Management. EinePerspektive stellt eine Art Linse dar, durch die ein Business-Analyst seine Aufgabenin dem jeweiligen Kontext sieht. Eine oder mehrere der Perspektiven können

2

EinleitungWas ist Business-Analyse?

Projekt

Projekt

Erledigung

Anforderungsanalyseund Design-Definition

Projektabschluss

Nutzen

Strategische Analyse

Lösungsbewertung

Vorprojekt

Grundlage

1.2

auf ein Vorhaben zutreffen. Die im BABOK®-Leitfaden vorgestellten Perspektivenstellen weder alle Kontexte der Business-Analyse dar, noch bilden sie eine voll-ständige Zusammenstellung aller Anwendungsmöglichkeiten der Business-Ana-lyse.

Wer ist ein Business-Analyst?Ein Business-Analyst ist jeder, der die im BABOK®-Leitfaden beschriebenenBusiness Analyse-Aktivitäten durchführt, unabhängig von der Stellenbezeichnungoder der organisatorischen Rolle.

Der Business-Analyst ist dafür verantwortlich, Informationen zu ermitteln, zuordnen und zu analysieren. Diese Informationen stammen aus einer Vielzahlvon Quellen in einem Unternehmen, u.a. IT-Werkzeugen, Geschäftsprozessen,Dokumenten und Stakeholdern. Der Business-Analyst ist verantwortlich dafür,dass die tatsächlichen Bedarfe der Stakeholder erhoben werden (was häufig dieUntersuchung und Klärung der geäußerten Wünsche beinhaltet), um tieferlie-gende Anliegen und Ursachen zu bestimmen.

Der Business-Analyst ist daran beteiligt, die entworfenen und gelieferten Lösungenmit den Bedarfen der Stakeholder abzustimmen. Zu den Aktivitäten der Busi-ness-Analyse gehören:

• Probleme und Ziele des Unternehmens verstehen• Bedarfe und Lösungen analysieren• Strategien entwickeln• Veränderung voranbringen• Zusammenarbeit mit und unter den Stakeholdern moderieren.

Weitere gebräuchliche Bezeichnungen für Personen, die Business-Analyse aus-üben, sind

• Unternehmensarchitekt• Business-System-Analyst • Datenanalyst• Unternehmensanalyst• Managementberater• Prozessanalyst• Produktmanager• Produktverantwortlicher• Requirements Engineer

• Systemanalyst.

Einleitung Wer ist ein Business-Analyst?

3

1.3

Aufbau des BABOK®-LeitfadensDer Kern des BABOK®-Leitfadens sind die Aufgaben der Business-Analyse, die inWissensgebiete unterteilt sind. Wissensgebiete sind eine Sammlung logisch zusam-mengehöriger (aber nicht unbedingt zeitlich aufeinanderfolgender) Aufgaben.Diese Aufgaben beschreiben die spezifischen Aktivitäten, die notwendig undsinnvoll sind, um den Zweck des zugehörigen Wissensgebiets zu erreichen.

Kernbegriffe der Business-Analyse, Basiskompetenzen, Techniken und Perspektivensind Abschnitte des erweiterten Inhalts des BABOK®-Leitfadens. Sie helfen demBusiness-Analysten, Aufgaben der Business- Analyse besser durchzuführen.

• Kernbegriffe der Business-Analyse definieren die zentralen Begriffe, die notwendig sind, um den Inhalt, die Konzepte und Ideen des BABOK®-Leitfadens zu verstehen.

• Basiskompetenzen beschreiben Verhaltensweisen, Charaktereigen-schaften, Kenntnisse und persönliche Qualitäten, die für eine effektive Ausübung der Business-Analyse notwendig sind.

• Techniken bieten Hilfen, um Aufgaben der Business-Analyse zu erledigen. Mit den beschriebenen Techniken sollen die gebräuchlichsten und in der Community der Business-Analyse am weitesten verbreiteten Techniken abgedeckt werden.

• Perspektiven beschreiben verschiedene Sichten der Business-Analyse. Perspektiven helfen dem Business-Analysten, von verschiedenen Standpunkten Aufgaben der Business Analyse im jeweiligen Kontext eines Vorhabens besser auszuführen.

Kernbegriffe

Das Kapitel „Schlüsselkonzepte der Business-Analyse“ (business analysis keyconcepts) (Kap.2) liefert die Kernideen, die für das Verständnis des BABOK®-Leitfadens benötigt werden.

Das Kapitel enthält:• Kernkonzept-Modell der Business-Analyse • Kernbegriffe• Klassifikationsschema von Anforderungen• Stakeholder• Anforderungen und Designs.

WissensgebieteWissensgebiete sind zusammengehörige Bereiche der Expertise der Business-Analyse, die aus verschiedene Aufgaben bestehen.

EinleitungAufbau des BABOK®-Leitfadens

4

1.4

1.4.1

1.4.2

Die sechs Wissensgebiete sind: • Planung und Überwachung der Business-Analyse Beschreibt die Aufgaben des Business-Analysten zur Organisation und Koordination der Aktivitäten von Business-Analysten und Stake holdern. Diese Aufgaben liefern Ergebnisse, die als Schlüssel-Inputs und Vorlagen für andere Aufgaben des BABOK®-Leitfadens dienen.

• Erhebung und ZusammenarbeitBeschreibt die Aufgaben des Business-Analysten zur Vorbereitung und Durchführung von Erhebungen und zur Bestätigung der Ergebnisse. Das Wissensgebiet beschreibt zudem die Kommunikation mit Stakeholdern, sobald Informationen zur Business-Analyse zusammengestellt sind, wie auch die fortlaufende Zusammenarbeit mit den betroffenen Stakehol-dern während der Business-Analyse.

• Management des Anforderungs-LebenszyklusBeschreibt die Aufgaben des Business-Analysten zum Management und zur Pflege von Anforderungen und von Informationen zum Design von deren Entstehen bis zu deren Auslaufen. Dazu wird beschrieben, wie sinnvolle Beziehungen zwischen verwandten Anforderungen und Designs hergestellt werden, wie vorgeschlagene Änderungen an Anforderungen und Designs bewertet und analysiert werden und wie Einigkeit bezüglich vorgeschlagener Änderungen erreicht wird.

• Strategische AnalyseBeschreibt, was der Business-Analyst tun muss, um zusammen mit den Stakeholdern strategisch oder operativ wichtigen Bedarf zu identifizie-ren, dem Unternehmen zu helfen, diesen Bedarf zu adressieren und die sich für diese Veränderung ergebende Strategie mit Strategien auf höherem und niedrigerem Level abzustimmen.

• Anforderungsanalyse und Design-DefinitionBeschreibt die Aufgaben des Business-Analysten zur Strukturierung und Organisation von ermittelten Anforderungen, zur Spezifikation und Modellierung von Anforderungen und Designs, zur Verifizierung und Validierung von Informationen, zur Identifikation von Lösungsoptionen und zur Einschätzung des potentiellen Nutzens jeder Lösungsoption. Dieses Wissensgebiet deckt die inkrementellen und iterativen Aktivitä-ten ab, vom initialen Konzept und Erkennen des Bedarfs bis zur Umset-zung der Bedarfe in eine spezifische, empfohlene Lösung.

• LösungsbewertungBeschreibt die Aufgaben des Business-Analysten zur Bewertung der Leistungsfähigkeit und des Nutzens einer Lösung, die in dem Unter-nehmen eingesetzt wird, und zu Empfehlungen, wie Hindernisse und Beschränkungen beseitigt werden, die der Erreichung der Ziele im Wege stehen.

Einleitung Aufbau des BABOK®-Leitfadens

5

Die folgende Abbildung zeigt die generellen Zusammenhänge zwischen den Wissensgebieten.

Abb. 1.4.1: Zusammenhänge zwischen den Wissensgebieten

Aufgaben

Eine Aufgabe beschreibt einen abgrenzbaren Arbeitsabschnitt, der formal oderinformal als Teil der Business-Analyse ausgeführt werden kann. Der BABOK®-Leitfaden definiert eine Liste von Business-Analyse-Aufgaben. Die Aufgabenkönnen generell in den verschiedenen Einsatzgebieten der Business-Analyse –unabhängig von der Art des Vorhabens – durchgeführt werden. Ein Business-Analyst kann auch andere Aktivitäten durchführen, die von seinem Unternehmenvorgeschrieben werden, diese zusätzlichen Aktivitäten sind aber nicht als Teildes Berufsbildes der Business-Analyse anzusehen.

Aufgaben sind in Wissensgebiete gruppiert. Der Business-Analyst führt die Auf-gaben aller Wissensgebiete entweder nacheinander, iterativ oder gleichzeitigaus. Der BABOK®-Leitfaden schreibt keinen Prozess vor, in der die Aufgabendurchzuführen sind. Aufgaben können in jeglicher Reihenfolge durchgeführtwerden, solange die notwendigen Inputs für eine Aufgabe vorliegen. Ein Busi-ness-Analyse-Vorhaben kann mit jeder Aufgabe starten; die Ermittlung des Ist-Zustands oder die Messung der Performance einer Lösung sind allerdings typischeKandidaten für den Beginn.


6

Erhebung undZusammenarbeit

StrategischeAnalyse

Anforderungs-analyse und

Design-Definition

Management des Anforderungs-Lebenszyklus

Lösungs-bewertung

Planung undÜberwachung derBusiness-Analyse

1.4.3

Jede Aufgabe des BABOK®-Leitfadens wird in folgendem Format beschrieben:• Zweck• Beschreibung • Inputs• Elemente• Leitfäden und Werkzeuge• Techniken• Stakeholder • Outputs.

.1 ZweckDer Abschnitt zum Zweck liefert eine kurze Beschreibung dafür, weshalb ein Busi-ness-Analyst diese Aufgabe durchführt und welcher Wert dabei geschaffen wird.

.2 BeschreibungDer Abschnitt zur Beschreibung erläutert mit mehr Details, was die Aufgabeumfasst, warum sie ausgeübt wird und was sie erreichen sollte.

.3 InputsDer Abschnitt zu Inputs listet auf, was eine Aufgabe benötigt bzw. was sieauslöst. Inputs können Informationen sein, die verarbeitet oder transformiertwerden, um einen Output zu produzieren. Inputs umfassen die notwendigenAngaben und Hilfsmittel, um eine Aufgabe zu beginnen. Sie können explizitaußerhalb des Arbeitsgebietes der Business-Analyse entstanden oder durch eineAufgabe der Business-Analyse geschaffen worden sein. Inputs, die außerhalbdes Arbeitsgebietes der Business-Analyse entstanden sind, werden durch denHinweis „(extern)“ in der Inputliste gekennzeichnet.Wenn es einen Input gibt, kann daraus nicht geschlossen werden, dass daszugehörige Lieferobjekt damit schon vollständig sei. Der Input muss nur soweitfertig gestellt sein, dass Folgearbeiten beginnen können. Während des Lebens-zyklus eines Vorhabens kann es beliebig viele Versionen eines Inputs geben. DerAbschnitt zu Inputs enthält eine grafische Darstellung der Inputs und Outputs,der anderen Aufgaben, die die Outputs nutzen, sowie der Leitfäden und Werk-zeuge, die in den Aufgaben genannt werden.

.4 ElementeDer Abschnitt zu Elementen beschreibt die Kernbegriffe, die zum Verständniswichtig sind, wie eine Aufgabe erledigt wird. Die Elemente sind bei der Durch-führung nicht zwingend vorgeschrieben; ihr Einsatz hängt vom jeweiligen Vor-gehen ab.


7

.5 Leitfäden und WerkzeugeDer Abschnitt zu Leitfäden (Vorlagen/Orientierungshilfen) und Werkzeugen listetdie Ressourcen auf, die notwendig sind, um einen Input in einen Output zutransformieren. Ein Leitfaden liefert Instruktionen und Beschreibungen, warumund wie eine Aufgabe auszuführen ist. Ein Werkzeug wird genutzt, um eineAufgabe zu erledigen. Leitfäden und Werkzeuge können auch Output andererAufgaben sein.

.6 TechnikenDer Abschnitt zu Techniken listet die Techniken auf, die für diese Aufgabe derBusiness-Analyse eingesetzt werden können.

.7 StakeholderDer Abschnitt zu Stakeholdern setzt sich aus einer generischen Liste von Stake-holdern zusammen, die typischerweise an der Durchführung der Aufgabe beteiligtoder von dieser betroffen sind. Der BABOK®-Leitfaden schreibt nicht vor, dassdiese Rollen in jedem Vorhaben der Business-Analyse ausgefüllt oder gelebtwerden müssen.

.8 OutputsDer Abschnitt zu Outputs beschreibt die Ergebnisse, die bei der Durchführungder Aufgabe entstehen. Outputs werden geschaffen, verändert oder sie ändernihren Zustand, wenn eine Aufgabe erfolgreich abgeschlossen ist. Ein Outputkann ein selbstständiges Lieferobjekt sein oder Bestandteil eines übergeordnetenObjekts. Die Form des Outputs hängt vom jeweiligen Vorhaben, den verwendetenStandards eines Unternehmens und dem Urteil des Business-Analysten ab, wiedie Informationsbedürfnisse der Schlüssel-Stakeholder am besten abgedecktwerden können.

Ähnlich wie bei Inputs gilt, dass die Ausführung einer Aufgabe abgeschlossensein kann, ohne dass der Output einen endgültigen Zustand erreicht hat. Auf-gaben, die einen bestimmten Output nutzen, müssen nicht zwangsläufig aufdessen Vollständigkeit warten, um selbst zu beginnen.

Basiskompetenzen

Basiskompetenzen berücksichtigen Kenntnisse, Fähigkeiten, Verhaltensweisen,Charaktereigenschaften und persönliche Qualitäten, die dazu beitragen, dassder Business-Analyst seine Rolle erfolgreich ausfüllen kann. Diese Basiskompe-tenzen gelten nicht nur für das Berufsbild der Business-Analyse. Eine erfolgreicheAusübung von Aufgaben und Techniken hängt jedoch häufig davon ab, ob eineoder mehrere Basiskompetenzen vorhanden sind.


8

1.4.4

Basiskompetenzen haben die folgende Struktur:• Zweck • Kernbeschreibung• Erfolgsmaßstäbe.

.1 ZweckDer Abschnitt zum Zweck beschreibt, warum es für den Business-Analysten hilf-reich ist, diese Basiskompetenz zu besitzen.

.2 BeschreibungDer Abschnitt zur Beschreibunge enthält die Fähigkeiten und Expertise, die mitder Anwendung dieser Kompetenz verbunden sind.

.3 ErfolgsmaßstäbeDer Abschnitt zu den Erfolgsmaßstäben beschreibt, wie bestimmt werden kann,ob eine Person dieser Basiskompetenz befähigt ist.

Techniken

Techniken bieten zusätzliche Informationen darüber, wie eine Aufgabe durch-geführt werden kann.

Die Liste der Techniken im BABOK®-Leitfaden erhebt keinen Anspruch auf Voll-ständigkeit. Es gibt verschiedene Techniken, die alternativ oder in Verbindungmit anderen Techniken angewendet werden können, um eine Aufgabe zuerfüllen. Der Business-Analyst wird ermutigt, bestehende Techniken abzuwandelnoder neue zu entwickeln, die seiner Situation und den Zielen seiner Aufgabenam besten dienlich sind.

Techniken haben die folgende Struktur:• Zweck • Beschreibung • Elemente • Bewertung.

.1 ZweckDer Abschnitt zum Zweck beschreibt, wofür die Technik genutzt wird und zuwelchen Gegebenheiten sie typischerweise eingesetzt wird.


9

1.4.5

.2 Beschreibung Der Abschnitt zur Beschreibung erläutert die Technik und wie sie durchgeführtwird.

.3 Elemente Der Abschnitt zu Elementen beschreibt Schlüsselkonzepte, die dem Verständnisdafür dienen, wie die Technik eingesetzt wird.

.4 Bewertung Der Abschnitt zur Bewertung beschreibt Stärken und Grenzen der Technik.

Perspektiven

Perspektiven werden in der Business-Analyse genutzt, um im speziellen Kontextdes Vorhabens die Aufgaben und Techniken der Business-Analyse zu schärfen.Viele Vorhaben nutzen typischerweise eine oder mehrere Perspektiven. Die Per-spektiven im BABOK®-Leitfaden sind:

• Agil• Business Intelligence• Informationstechnologie• Geschäftsarchitektur • Business Process Management (BPM).

Diese fünf Perspektiven decken nicht alle Blickwinkel ab, die in der Business-Analyse eingenommen werden können. Sie repräsentieren lediglich einige derPerspektiven der Business-Analyse, die zum Zeitpunkt des Erstellens des BABOK®-Leitfadens weit verbreitet sind.Die Perspektiven schließen sich nicht gegenseitig aus, so dass in einem Vorhabenmehr als eine Perspektive eingenommen werden kann.

Perspektiven haben die folgende Struktur:• Scope des Change-Vorhabens • Scope der Business-Analyse • Methoden, Herangehensweisen und Techniken • Basiskompetenzen • Auswirkungen auf die Wissensgebiete.


10

1.4.6

.1 Scope des Change-VorhabensDer Abschnitt zum Scope des Change-Vorhabens beschreibt, welche Teile desUnternehmens von der Veränderung betroffen sind, falls diese Perspektive ein-genommen wird, und in welchem Umfang Ziele und operatives Geschäft desUnternehmens beeinflusst werden. Der Scope des Change-Vorhabens zeigtauch, welche Probleme gelöst werden müssen, wie dabei vorzugehen ist undwie der geschaffene Wert gemessen werden kann.

.2 Scope der Business-AnalyseDer Abschnitt zum Scope der Business-Analyse beschreibt die Schlüssel-Stake-holder inklusive eines Profils typischer Sponsoren, die betroffene Zielgruppe unddie Rolle des Business-Analysten in dem Vorhaben. Der Abschnitt erläutert auchtypische Ergebnisse der Business-Analyse, die bei dieser Perspektive erwartetwerden.

.3 Methoden, Herangehensweisen und TechnikenBei jeder Perspektive gibt es eine andere Zusammenstellung dieses Abschnitts.In jedem Fall werden die Methoden, Herangehensweisen oder Techniken beschrie-ben, die für die Anwendung der Business-Analyse in dieser Perspektive gebräuch-lich und spezifisch sind. Methoden und Herangehensweisen sind spezialisierteWege, die Arbeiten der Business-Analyse durchzuführen. Die Techniken diesesAbschnitts sind Techniken, die nicht im Kapitel 10 (Techniken) des BABOK®-Leit-fadens enthalten, sondern besonders für diese Perspektive relevant sind.

In der Perspektive „Geschäftsarchitektur“ sind Referenzmodelle anstelle vonMethoden und Herangehensweisen aufgeführt. In der Perspektive „BusinessProcess Management“ werden Frameworks (Rahmenmodelle/Bezugsrahmen)anstelle von Herangehensweisen behandelt.

.4 Basiskompetenzen Der Abschnitt zu Basiskompetenzen beschreibt die Kompetenzen, die in dieserPerspektive besonders häufig benötigt werden.

.5 Auswirkungen auf die WissensgebieteDer Abschnitt zu den Auswirkungen auf die Wissensgebiete beschreibt, wieWissens gebiete angewandt oder modifiziert werden. Er erläutert auch, wie spezi-fische Aktivitäten in einer Perspektive zu den Aufgaben des BABOK®-Leitfadenspassen.


11

13

Das Kapitel „Schlüsselkonzepte der Business-Analyse“ bietet Informationen, dieGrundlage für alle anderen Inhalte, Konzepte und Ideen des BABOK®-Leitfadensind.

Es liefert dem Business-Analysten Einsichten in die zentralen Ideen, die für dasVerständnis und die Anwendung des BABOK®-Leitfadens in seiner täglichenPraxis der Business-Analyse notwendig sind.

Dieses Kapitel enthält:• Kernkonzept-Modell der Business-Analyse (Business Analysis Core Concept Model™/BACCM™): Darin wird ein konzeptioneller Rahmen für den Beruf des Business-Analysten definiert.• Kernbegriffe: Das sind Definitionen der wesentlichen Konzepte, die wegen ihrer Bedeutung für den BABOK®-Leitfaden hervorgehoben werden.• Klassifikationsschema von Anforderungen: Es werden Anforderungs-ebenen und -typen identifiziert, die den Business-Analysten und andere Stakeholder bei der Klassifikation von Anforderungen unterstützen.• Stakeholder: Hier werden Rollen definiert und Gruppen oder Einzelpersonen charakterisiert, die an den Aktivitäten der Business-Analyse in einem Change-Prozess teilhaben oder davon betroffen sind.• Anforderungen und Designs: Es wird der Unterschied zwischen und die Wichtigkeit von Anforderungen und Designs im Zusammenhang mit der Business-Analyse beschrieben.

Schlüsselkonzepte der Business-Analyse2

Kernkonzept-Modell der Business-AnalyseDas Kernkonzept-Modell der Business-Analyse (BACCM™) stellt den Rahmenfür das Konzept der Business-Analyse dar. Es erklärt die Business-Analyse undzeigt, was es für diejenigen bedeutet, die mit der Durchführung der Aufgabender Business-Analyse betraut sind. Es ist unabhängig von der Perspektive, derBranche, der gewählten Methodik oder der Ebene in der Organisation. Es bestehtaus sechs Begriffen, die für alle Business-Analysten das gleiche bedeuten, mitderen Hilfe sie über die Business-Analyse diskutieren können und deren Bedeutungin der üblichen Terminologie sie kennen. Jeder dieser Begriffe wird als ein Kern-konzept betrachtet.

Die sechs Kernkonzepte sind: Change, Bedarf, Lösung, Stakeholder, Nutzen undKontext. Jedes Kernkonzept ist von grundlegender Bedeutung für die Praxis derBusiness-Analyse. Alle Konzepte sind gleichwertig und notwendig. Jedes Kern-konzept wird durch die anderen fünf Kernkonzepte definiert und kann nichtverstanden werden, ohne die anderen Konzepte vollständig verstanden zu haben.Kein Konzept hat eine größere Bedeutung oder Signifikanz als ein anderes Kon-zept. Diese Konzepte helfen, die Art der Informationen zu verstehen, die in derBusiness-Analyse erhoben, analysiert oder verwaltet werden.

Das BACCM™ kann verwendet werden, um• den Beruf des Business-Analysten und das Arbeitsgebiet der Business-Analyse zu beschreiben• über Business-Analyse mit umgangssprachlicher Terminologie zu kommunizieren• die Beziehungen der Kernkonzepte in der Business-Analyse zu bewerten• die Qualität der Business-Analyse durch eine ganzheitliche Beurteilung der Beziehungen zwischen diesen sechs Konzepten zu steigern • den Einfluss dieser Konzepte und Beziehungen zu jedem Zeitpunkt bei der Arbeit zu bewerten, um sowohl eine Basis zu legen als auch den weiterführenden Weg zu gestalten.

Tabelle 2.1.1: Das BACCM™

Schlüsselkonzepte der Business-Analyse

14

Schlüsselkonzepte der Business-AnalyseKernkonzept-Modell der Business-Analyse

2.1

Kernkonzept Beschreibung

Change Der Akt der Veränderung als Reaktion auf einen Bedarf.

Changes werden durchgeführt, um die Leistung eines Unternehmenszu verbessern.

Diese Verbesserungen sind bewusst und werden durch die Aktivitätender Business-Analyse kontrolliert.

Tabelle 2.1.1: Das BACCM™ (Fortsetzung)

Schlüsselkonzepte der Business-Analyse Kernkonzept-Modell der Business-Analyse

15

Kernkonzept Beschreibung

Bedarf Ein Problem, das zu lösen, oder eine Chance, die wahrzu nehmen ist.

Der Bedarf kann Changes auslösen, wenn Stakeholder zum Handelnmotiviert werden.

Changes können auch einen Bedarf auslösen, wenn durch sie derNutzen bestehender Lösungen vermindert oder erhöht wird.

Lösung Ein bestimmter Weg, um einen Bedarf (oder auch mehrere) in einembestimmten Kontext zu befriedigen.

Eine Lösung befriedigt den Bedarf des Stakeholders, indem ein aufge-zeigtes Problem beseitigt oder aus einer Chance ein Vorteil geschaffenwird.

Stakeholder Eine Einzelperson oder eine Gruppe, die mit dem Change, dem Bedarfoder der Lösung in einer Beziehung steht.

Stakeholder werden meistens den Gruppen „ist interessiert amChange“, „ist betroffen vom Change“ oder „kann den Changebeeinflussen“ zugeordnet.

Stakeholder werden gemäß deren Beziehung zum Bedarf, zumChange oder zur Lösung gruppiert.

Nutzen Der Wert, die Bedeutung oder die Zweckmäßigkeit für den Stakeholderin einem bestimmten Kontext.

Der Nutzen kann als potentielle oder realisierte Rendite, als Zugewinnoder als Verbesserung gesehen werden. Die Verringerung eines Ver-lustes, eines Risikos oder die Reduzierung von Kosten stellt einenNutzen dar.

Der Nutzen kann materiell oder immateriell sein. Materieller Nutzen istdirekt messbar und hat häufig eine signifikante monetäre Komponente.Immaterieller Nutzen kann nur indirekt gemessen werden. ImmateriellerNutzen hat häufig eine bedeutende Motivationskomponente wie dieReputation des Unternehmens oder die Moral der Mitarbeiter.

Manchmal kann der Nutzen absolut bewertet werden, in vielen Fällenaber nur als relative Größe eine Lösungsvariante ist aus der Sicht derStakeholder nützlicher als andere.

Kontext Die Umstände, die einen Change beeinflussen, die von einem Changeselbst beeinflusst werden und die den Change verständlich machen.

Changes treten in einem Kontext auf. Der Kontext ist alles, was für denChange im Rahmen des gegebenen Umfeldes relevant ist. Zum Kontextkönnen gehören: Einstellungen, Verhaltensweisen, Überzeugungen,Mitbewerber, Kultur, Demografie, Ziele, Regierung, Infrastruktur, Sprachen, Verluste, Prozesse, Produkte, Projekte, Vertrieb, Saison, Terminologie, Technik, Wetter und weitere Faktoren.

Die Kernkonzepte werden von Business-Analysten verwendet, um Qualität undVollständigkeit ihrer Arbeit zu prüfen. In der Beschreibung jedes Wissensgebietesgibt es Beispiele, wie die Kernkonzepte für die einzelnen Aufgaben eingesetztoder angewendet werden können. Während der Planung oder Durchführungeiner Aufgabe oder Technik können Business-Analysten prüfen, wie jedes Kern-konzept durch Fragen angesprochen wird, wie z.B.:• Welche Arten von Changes machen wir?• Welche Bedürfnisse versuchen wir zu befriedigen?• Welche Lösungen schaffen oder adaptieren wir?• Welche Stakeholder sind eingebunden?• Was erachten Stakeholder als nützlich?• In welchem Kontext befinden wir uns, in welchem befindet sich die Lösung?

Wenn sich eines der Kernkonzepte verändert, sollten die Kernkonzepte undderen Beitrag zum Nutzen neu bewertet werden.

Abb. 2.1.1: BACCM™

Schlüsselkonzepte der Business-AnalyseKernkonzept-Modell der Business-Analyse

16

Change

Stakeholder Kontext

Bedarf Lösung

Nutzen

Kernbegriffe

Business-AnalyseDer BABOK®-Leitfaden beschreibt und definiert die Business-Analyse als diePraxis, Anforderungen zu ermitteln und Lösungen vorzuschlagen, die in Unter-nehmen Veränderungen (Changes) bewirken und Stakeholdern Nutzen brin-gen.

Information der Business-AnalyseInformationen der Business-Analyse sind alle Arten unterschiedlichster Informa-tionen, die vom Business-Analysten analysiert, transformiert, zusammengefasstund berichtet werden. Es handelt sich um jede Art von Informationen, in jedemDetaillierungsgrad, die als Input für die Business-Analyse verwendet werdenoder bei der Business-Analyse entstehen. Beispiele für Informationen der Busi-ness-Analyse sind Erhebungsergebnisse, Anforderungen, Designs, Lösungsvari-anten, Lösungsumfang und Change-Strategien.

Es ist wichtig, den Gegenstand der Aktivitäten der Business-Analyse nicht nurauf die „Anforderungen“ zu beschränken, sondern generell auf „Informationen“zu erweitern, um sicherzustellen, dass alle Inputs und Outputs der Business-Analyse zu deren Aufgaben und Aktivitäten gehören, so wie es im BABOK®-Leitfaden beschrieben wird. So sind alle oben genannten Beispiele Elemente beider Umsetzung der Aufgabe „Informationsmanagement der Business-Analyseplanen“. Würde der BABOK®-Leitfaden nur das „Anforderungsmanagementplanen“ beschreiben, dann würden Outputs wie Erhebungsergebnisse, Lösungs-varianten und Change-Strategien nicht dazugehören.

DesignEin Design ist eine nutzbare Darstellung einer Lösung. Das Design konzentriertsich auf die Festlegung, welcher Nutzen von einer fertigen Lösung realisiertwerden kann. Dieses kann in der Form eines Dokumentes (oder einer Reihe vonDokumenten) dargestellt sein und je nach den Umständen sehr unterschiedlichaussehen.

Unternehmen Ein Unternehmen ist ein System, das aus einer oder mehreren Organisationenund deren Lösungskonzepten besteht und bestimmte (in der Regel wirtschaftliche)Ziele verfolgt.

Diese Lösungskonzepte (auch organisatorische Fähigkeiten genannt) könnenProzesse, Werkzeuge oder Informationen sein. Für die Zwecke der Business-Analyse können Unternehmensgrenzen in Bezug auf das konkrete Change-Vor-haben festgelegt werden und müssen nicht durch die Grenzen einer juristischen

Schlüsselkonzepte der Business-Analyse Kernbegriffe

17

2.2

Weitere Informati-onen im Kapitel 1.2 „Was istBusiness-Analyse?“

Weitere Informatio-nen im Kapitel 2.5„Anforder-ungen undDesigns“

Person, eines Unternehmens oder einer Organisationseinheit bestimmt sein. EinUnternehmen kann eine beliebige Anzahl von Geschäften, öffentlichen Aufgabenoder andere Organisationstypen enthalten.

OrganisationEine Organisation ist eine autonome Einheit in einem Unternehmen, die voneinem Einzelnen oder von einer Personenmehrheit geleitet wird, gemeinsamenZielen verpflichtet ist und sich von anderen Einheiten abgrenzen lässt (institutio-nelle Sicht der Organisation). Organisationen sind dauerhaft eingerichtet, imUnterschied etwa zu Projektgruppen, die sich mit der Erledigung eines Auftragswieder auflösen.

PlanEin Plan ist ein Vorschlag, wie etwas zu tun oder zu erreichen ist. Ein Plan isteine Aufstellung von beispielsweise Ereignissen, Abhängigkeiten, Abfolgen, Plan-zeiten, Outputs, benötigten Materialien und Ressourcen und Stakeholdern (Betei-ligten), die zusammenwirken, um etwas zu tun oder zu erreichen.

AnforderungEine Anforderung ist eine brauchbare Darstellung eines Bedarfs. Anforderungenkonzentrieren sich darauf, zu verstehen, welche Art von Nutzen geliefert werdenkönnte, um diese Anforderung zu erfüllen. Die Anforderung kann in der Formeines Dokumentes (oder eine Reihe von Dokumenten) dargestellt werden undje nach Umständen sehr unterschiedlich aussehen.

RisikoEin Risiko ist die Unsicherheit über den Wert eines Change oder über die Wirk-samkeit einer Lösung. Der Business-Analyst arbeitet mit anderen Stakeholdernzusammen, um Risiken zu identifizieren, zu bewerten und zu priorisieren unddamit besser steuern zu können. Risiken sind so zu steuern, dass die Eintritts-wahrscheinlichkeit für Ereignisse und deren Rahmenbedingungen besser abge-schätzt werden kann, etwa indem Folgen abgeschwächt, Gefahrenquellen besei-tigt oder Gefahren vermieden werden, etwa durch die Entscheidung, gar nichtzu starten oder eine Aktivität nicht fortzusetzen oder auch das Risiko mit anderenParteien zu teilen (Versicherung) oder das Risiko bewusst zu akzeptieren (evtl.sogar zu erhöhen), um Chancen wahrzunehmen.

Klassifikationsschema von Anforderungen Für die Zwecke des BABOK®-Leitfadens beschreibt das folgende Klassifikations-schema die Anforderungen:

Schlüsselkonzepte der Business-AnalyseKlassifikationsschema von Anforderungen

18

Weitere Infor-mationen imKapitel 2.5„Anforderun-gen undDesigns“

2.3

• Betriebliche Anforderungen: Das sind Ziele oder gewünschte Ergeb-nisse, die einen Change-Prozess auslösen. Sie können sich auf das gesamte Unternehmen (Unternehmensziele), einen Geschäftsbereich (Bereichsziele) oder auf ein bestimmtes Vorhaben beziehen.• Stakeholder-Anforderungen: Sie beschreiben die Bedürfnisse von Stakeholdern, die erfüllt sein müssen, damit die betrieblichen Anforderungen erfüllt werden können. Sie können als eine Brücke dienen zwischen betrieblichen Anforderungen und Lösungsanfor-derungen.• Lösungsanforderungen: Sie beschreiben die Fähigkeiten und Qualitä-ten einer Lösung, welche die Stakeholder-Anforderungen erfüllt. Sie sind so weit detailliert, dass die Lösung entwickelt und implementiert werden kann. Lösungsanforderungen können in zwei Unterkategorieneingeteilt werden:• Funktionale Anforderungen: Sie beschreiben die Leistungen oder Fähigkeiten, die ein Produkt, ein Service oder eine sonstige Lösung dem Kunden oder Anwender bietet.• Nicht-funktionale Anforderungen oder Anforderungen an die Servicequalität: Sie beziehen sich nicht direkt auf das funktionale Verhalten der Lösung, sondern beschreiben, unter welchen Bedingungen eine Lösung funktionsfähig bleiben muss oder welche Qualitäten die Lösung haben muss.

• Überleitungsanforderungen: Das sind Anforderungen an eine Lösung oder ein System, bzw. Bedingungen, die gegeben sein müssen, um den Wechsel von dem heutigen Zustand in einen zukünftigen Zustand (Lösung) vollziehen zu können. Sie werden nach dem Abschluss des Change-Prozesses nicht mehr benötigt. Die Anforderungen unterschei-den sich somit von anderen, indem sie nur vorübergehender Natur sind. Überleitungsanforderungen betreffen Themen wie Datenkonver-tierung, Schulungen und Sicherstellung des laufenden Geschäfts-betriebs während des Change.

StakeholderStakeholder sind Einzelpersonen oder Personengruppen, die eigene Interessenin ein Vorhaben einbringen, auf die Lösung Einfluss nehmen oder von der Lösungbetroffen sind. Jede Aufgabe enthält eine Liste von Stakeholdern, die bei derAusführung dieser Aufgabe mitarbeiten oder die von ihr betroffen sind. DerBusiness-Analyst hat direkt oder indirekt mit den Stakeholdern zu tun. DerBABOK®-Leitfaden schreibt nicht vor, dass alle Rollen für jedes einzelne Vorhabenvorhanden sein müssen. Die Stakeholder sind im Allgemeinen eine Quelle fürAnforderungen, Annahmen oder Einschränkungen.

Schlüsselkonzepte der Business-Analyse Stakeholder

19

Weitere Infor-mationen imKapitel 10.30„Analysenicht-funktio-naler Anforde-rungen“

2.4

Die folgende Liste erhebt nicht den Anspruch darauf, alle möglichen Interessen-gruppen und Klassifikationen zu enthalten. Es gibt auch andere Rollenbezeich-nungen für Personen, die zu diesen generisch gebildeten Rollen gehören. VieleStakeholder lassen sich nicht eindeutig einer Rolle zuordnen. Andererseits kanneine einzelne Person gleichzeitig oder nacheinander mehr als eine Rolle erfüllen.

Für die Zwecke des BABOK®-Leitfadens enthält die Liste der Stakeholder folgendeRollen:

Business-Analyst

Der Business-Analyst ist in seiner Natur ein Stakeholder für alle Aktivitäten derBusiness-Analyse. Der BABOK®-Leitfaden unterstellt, dass der Business-Analystfür die Ausführung dieser Tätigkeiten zuständig und verantwortlich ist. In einigenFällen kann der Business-Analyst auch für die Erledigung von Aktivitäten zuständigsein, die anderen Stakeholder-Rollen zugeordnet sind.

Kunde

Der Kunde ist ein Stakeholder, der Produkte oder Services des Unternehmensnutzt oder nutzen kann und der vertragliche oder moralische Ansprüche hat,die ein Unternehmen erfüllen muss.

Fachexperte

Der Fachexperte ist eine Person mit besonderen Kenntnissen in einem bestimmtenGebiet, das für ein Unternehmen wichtig oder für eine Lösung relevant ist.

Diese Rolle wird häufig von folgenden Personen ausgeübt: Anwender oder Per-sonen mit fundierten Kenntnissen der Lösung, Manager, Prozessverantwortliche,Juristen, Berater und andere.

Anwender

Der Anwender ist ein Stakeholder, der direkt mit der Nutzung der Lösung zutun hat. Anwender sind auch Beteiligte in einem Geschäftsprozess (sie nutzen

Schlüsselkonzepte der Business-AnalyseStakeholder

20

• Business-Analyst • Projektmanager

• Kunde • Regulierer

• Fachexperte • Sponsor/Auftraggeber

• Anwender •Lieferant

• Umsetzungsexperte • Tester

• Support

2.4.2

2.4.3

2.4.4

2.4.1

die Ergebnisse vorgelagerter Prozessstufen) oder die finalen Nutzer des Produktsoder der Lösung.

Umsetzungsexperte

Der Umsetzungsexperte ist ein Stakeholder, der hinsichtlich der Umsetzung eineroder mehrerer Lösungsbestandteile besonders qualifiziert ist. Es ist zwar nicht möglich,eine vollständige Liste aller Rollen von Umsetzungsexperten zu erstellen, die für alleVorhaben passt, die gebräuchlichsten sind jedoch: Projektbibliothekar, Change Mana-ger, Konfigurationsmanager, Lösungsarchitekt, Entwickler, Datenbankadministrator,Informationsarchitekt, Usability-Analyst, Trainer und Change-Berater.

Support (Operational Support)

Der Support ist ein Stakeholder, der für das Management und die Wartung vonSystemen oder Produkten im Tagesgeschäft zuständig ist.

Es ist zwar nicht möglich, eine vollständige Liste aller Supportrollen für alle Ini-tiativen zu erstellen, aber die gebräuchlichsten sind: Betriebs-Analyst, Produkt-Analyst, Benutzerservice und Release Manager.

Projektmanager

Der Projektmanager ist für die Steuerung eines Projekts formal verantwortlich.Er ist dafür zuständig, dass die Projektziele hinsichtlich Anforderungen, Scope,Qualität und Risiko in der vorgegebenen Zeit und mit den bewilligten Ressourcenerreicht werden.

Gebräuchliche andere Bezeichnungen für diese Rolle sind Projektleiter, technischerLeiter, Produktmanager und Teamleiter.

Regulierer

Der Regulierer ist ein Stakeholder, der für Definition und Durchsetzung vonStandards zuständig ist. Standards für eine Lösung können von Aufsichts - behörden, vom Gesetzgeber, von der Unternehmensführung, von Prüfungsricht-linien oder von betrieblichen Kompetenzzentren stammen. Mögliche Rollen sindRegierung, Regulierungsbehörden und Wirtschaftsprüfer.

Sponsor/Auftraggeber

Der Sponsor ist ein Stakeholder, der befugt ist, eine Bedarfsermittlung auszulösenund ein Vorhaben auf den Weg zu bringen, das diesen Bedarf erfüllt. Er kannden Scope festlegen und verfügt über die für das Vorhaben notwendigen Mittel.

Schlüsselkonzepte der Business-Analyse Stakeholder

21

2.4.5

2.4.8

2.4.6

2.4.7

2.4.9

Er genehmigt die durchzuführenden Arbeiten und steuert das Budget und denScope für die Aktivität. Mögliche Rollen sind Führungskraft und Projektauftrag-geber/Projektsponsor.

Lieferant

Der Lieferant ist ein Stakeholder außerhalb der Grenzen einer Organisation. Erliefert Services oder Produkte und hat moralische oder vertragliche Ansprücheoder Verpflichtungen, die zu beachten sind. Mögliche Rollen sind Anbieter, Ver-käufer und Berater.

Tester

Der Tester ist dafür zuständig, dass eine Lösung daraufhin überprüft wird, obsie die definierten Anforderungen und die erarbeiteten Spezifikationen erfüllt.Der Tester muss sicherstellen, dass die Lösung die geltenden Qualitätsstandardseinhält und dass das Risiko von Fehlern oder Störungen erkannt und minimiertwird. Eine alternative Rolle ist der Qualitätssicherer.

Anforderungen und DesignsErhebung, Analyse, Bewertung und Verwaltung von Anforderungen sind Schlüs-selaktivitäten der Business-Analyse. Der Business-Analyst ist jedoch auch für dieDefinition des Designs einer Lösung auf einer bestimmten Ebene verantwortlich.Inwieweit der Business-Analyst für das Design zuständig ist, hängt von der Wahr-nehmung seiner Rolle im Einzelfall ab.

Anforderungen fokussieren auf den Bedarf, Designs fokussieren auf die Lösung.Die Unterscheidung zwischen Anforderungen und Designs ist nicht immer ein-deutig. Für beide können die gleichen Techniken verwendet werden, es wirderhoben, modelliert und analysiert. Eine Anforderung führt zu einem Design,das umgekehrt wieder zur Erhebung und Analyse von weiteren Anforderungenführen kann. Die Verschiebung des Fokus ist oft subtil.

Die Klassifizierung, ob es um Anforderung oder um Design geht, wird immerweniger wichtig, je besser im Fortschritt des Vorhabens der Bedarf erkannt undbedient wird. Die beschriebenen Aufgaben im BABOK®-Leitfaden wie „Anfor-derungen rückverfolgen“ oder „Anforderungen spezifizieren und modellieren“mögen sich auf Anforderungen beziehen, dienen aber letztlich auch dem Design.

Business-Analyse kann komplex und rekursiv sein. Eine oder mehrere Anforde-rungen können verwendet werden, um ein Design zu entwerfen. Das Designkann dann dazu verwendet werden, zusätzliche Anforderungen zu erheben,

Schlüsselkonzepte der Business-AnalyseAnforderungen und Designs

22

2.4.10

2.4.11

2.5

mit denen die Designs weiter detailliert werden können. Der Business-Analystkann Anforderungen und Designs an andere Stakeholder weitergeben, damitdiese an den Designs weiterarbeiten. Egal ob der Business-Analyst oder eineandere Rolle die Designs vervollständigt, meistens überprüft der Business-Analystdie endgültigen Designs, um zu gewährleisten, dass sie den Anforderungenentsprechen.

Die folgende Tabelle zeigt einige einfache Beispiele für Informationen, die ent-weder als Anforderung oder als Design aufgefasst werden können.

Tabelle 2.5.1: Anforderungen und Designs

Ein Stakeholder kann einen konkreten Bedarf oder eine Lösung für einen unter-stellten Bedarf aufzeigen. Ein Business-Analyst kann mit Aktionen wie sie in„Erhebung und Zusammenarbeit“, „Strategische Analyse“‚ „Anforderungsanalyseund Design-Definition“ und „Lösungsbewertung“ beschrieben sind, einenWunsch in eine Anforderung oder in ein Design transformieren. Unabhängigvom Fokus der Stakeholder hat der Business-Analyst die Aufgabe, ständig dieFrage nach dem „Warum“ zu stellen. Zum Beispiel: „Warum trägt eine Anfor-derung oder ein Design dazu bei, für das Unternehmen Nutzen zu schaffen unddamit die Unternehmensziele zu erreichen?“

Schlüsselkonzepte der Business-Analyse Anforderungen und Designs

23

Anforderung Design

Zeige Verkaufsdaten von 6 Monatenfür mehrere Organisationseinheiten ineiner einzigen Ansicht.

Skizze eines Dashboards

Reduziere die Zeit für Kommissionie-ren und Verpacken eines Kunden -auftrags.

Prozessmodell

Lege eine Krankengeschichte an undwerte sie aus.

Bildschirm-Layout mit den spezifischen Datenfeldern

Entwickle Geschäftsstrategie und Zielefür ein neues Geschäftsfeld.

Geschäftsmodell

Stelle Informationen in Englisch undFranzösisch bereit.

Prototyp mit englischem undfranzösischem Text

Abb. 2.5.1: Anforderungen-und-Design-Kreislauf

Schlüsselkonzepte der Business-AnalyseAnforderungen und Designs

24

Design

Überleitungs-anforderungen

Was sind dieBedingungen?

Stakeholder-Anforderungen

Was sind dieBedarfe?

BetrieblicheAnforderungen

Warum willich das?

Lösungs-anforderungen

Was willich?

Zyklus wiederholt sich, bis die Anforderungen

erfüllt sind

Desig

n D

esign

Bew

ertu

ng des

Ergebniss

es

25

Die Aufgaben von „Planung und Überwachung der Business-Analyse“ organi-sieren und koordinieren die Bemühungen des Business-Analysten und der betei-ligten Stakeholder. Diese Aufgaben erzeugen Outputs, die für alle anderen Auf-gaben des BABOK®-Leitfadens eine zentrale Bedeutung haben.

Die „Planung und Überwachung der Business-Analyse“ umfasst die folgendenAufgaben:• Ansatz der Business-Analyse planen: Hier wird die Planung der Aktivi-täten der Business-Analyse von der Erarbeitung oder Auswahl einer Methodik bis zur Planung der einzelnen Aktivitäten, Aufgaben und Ergebnisse beschrieben.• Einbindung der Stakeholder planen: Sie beschreibt, welche Stakeholderfür den Change relevant sind, was der Business-Analyst von ihnen benö-tigt, was sie vom Business-Analysten benötigen und wie die Zusammen-arbeit geregelt sein soll.• Steuerung der Business-Analyse planen: Es wird festgelegt, welche Komponenten der Business-Analyse verwendet werden, um die Steue-rungsfunktion des Unternehmens zu unterstützen. Damit wird sicherge-stellt, dass Entscheidungen richtig und konsequent getroffen werden und einem Prozess folgen, der sicherstellt, dass die Entscheidungsträger die benötigten Informationen erhalten. Beispiele hierfür sind das Anfor-derungsmanagement, das Risikomanagement der Business-Analyse und die Zuweisung von Ressourcen der Business-Analyse.• Informationsmanagement der Business-Analyse planen: Es legt fest, wie Informationen vom Business-Analysten entwickelt (einschließlich Anforderungen und Designs), erfasst, gespeichert und in andere Informationen für die langfristige Nutzung integriert werden.• Leistungsverbesserungen der Business-Analyse ermitteln: Hier wird die Verwaltung und Überwachung der Arbeit der Business-Analyse beschrieben, um sicherzustellen, dass die Verpflichtungen eingehalten werden und kontinuierliches Lernen und Verbesserungsmöglichkeiten verwirklicht werden.

3 Planung und Überwachung der Business-Analyse

Das Kernkonzept-Modell in der „Planung und Überwachung der Business-Analyse“Das Kernkonzept-Modell der Business-Analyse beschreibt die Beziehungen zwischenden sechs Kernkonzepten. Die folgende Tabelle zeigt die Nutzung jedes Kernkon-zepts im Rahmen der Planung und Überwachung der Business-Analyse.,

Tabelle 3.0.1: Das Kernkonzept-Modell in der „Planung und Überwachung der Business-Analyse“

26

Planung und Überwachung der Business-Analyse

Das Kernkonzept-Modell in der „Planungund Überwachung der Business-Analyse“

Kernkonzept Bei der Planung und Überwachung der Business-Analyse: Der Business-Analyst...

Change: Der Akt der Veränderung als Reaktion auf einen Bedarf.

...ist verantwortlich für die Festlegung, wie Ent-scheidungen über Changes angefordert undgenehmigt werden.

Bedarf:Ein Problem, das zu lösen, odereine Chance, die wahrzunehmenist.

...wählt einen Ansatz der Business-Analyse, der fürdas Vorhaben eine angemessene Analyse liefert.

Lösung:Ein bestimmter Weg, um einenBedarf (oder auch mehrere) ineinem bestimmten Kontext zubefriedigen.

...beurteilt, ob die Performance/Ausführung derBusiness-Analyse ein wesentlicher Faktor für dieerfolgreiche Umsetzung einer Lösung war.

Stakeholder:Eine Einzelperson oder eineGruppe mit Bezug zum Change,dem Bedarf oder der Lösung.

...führt eine Stakeholder-Analyse durch, um sicher-zustellen, dass die Planungs- und Überwachungs-tätigkeiten die Bedürfnisse der Stakeholder reflek-tieren und ist verantwortlich für die richtige Aus-wahl der Stakeholder.

Nutzen: Der Wert, die Bedeutung oder dieZweckmäßigkeit eines Ergebnissesfür den Stakeholder in einembestimmten Kontext.

...erstellt eine Performance-Analyse, um sicherzu-stellen, dass die Aktivitäten der Business-Analysedem Stakeholder weiterhin ausreichenden Nutzenliefern.

Kontext: Die Umstände, die den Changebeeinflussen, von ihm beeinflusstwerden oder die Veränderungverständlich machen.

...sorgt für ein vollständiges Verständnis des Kon-textes der Analyse, um einen effizienten Ansatz derBusiness-Analyse zu entwickeln.

Abb. 3.0.1: Input-Output-Diagramm „Planung und Überwachung der Business-Analyse“


Das Kernkonzept-Modell in der„Planungund Überwachung der Business-Analyse“

27

Aufgaben

Output

Input

Bedarfe Leistungsziele (extern)

Ansatz der Business-Analyse

planen

3.1Einbindung

der Stakeholderplanen

3.2Steuerung der

Business-Analyseplanen

3.3

Informationsmanage-ment der Business-

Analyse planen

3.4Leistungsverbesserungen

der Business-Analyseermitteln

3.5


3.1 3.2

Ansatz derSteuerung

3.3

Ansatz desInformations-managements

3.4Leistungs-

beurteilung der Business-Analyse

3.5

Ansatz derEinbindung der

Stakeholder

Ansatz der Business-Analyse planen

Zweck

Der Zweck von „Ansatz der Business-Analyse planen“ besteht darin, eine geeigneteMethode zur Steuerung der Aktivitäten der Business-Analyse zu definieren.

Beschreibung

Ansätze der Business-Analyse beschreiben die allgemeine Methode für die Durch-führung einer Business-Analyse in einem bestimmten Vorhaben, wie und wannAufgaben durchgeführt und wie die zu erbringenden Leistungen erbracht wer-den.

Der Business-Analyst kann auch einen ersten Satz an Techniken festlegen, diegenutzt werden sollen. Diese Liste kann sich im Laufe der Arbeiten ändern,wenn die Arbeiten fortschreiten und der Business-Analyst das Change-Vorhabenund die Stakeholder besser verstanden hat.

Der Ansatz der Business-Analyse kann durch eine allgemeine Methode oderdurch betriebliche Standards definiert werden. In einigen Unternehmen werdenElemente des Ansatzes der Business-Analyse zu wiederkehrenden Prozessenstandardisiert und formalisiert, die dann für jedes weitere Vorhaben genutztwerden können. Selbst wenn ein solcher Standard vorhanden ist, ist es sinnvoll,das Vorgehen an die Bedürfnisse eines konkreten Vorhabens anzupassen. Dazukann geregelt sein, welche Ansätze erlaubt sind, welche Elemente dieser Prozesseangepasst werden dürfen und welche allgemeinen Richtlinien für die Auswahleines Prozesses gelten.

Sind keine organisatorischen Standards vorhanden, erarbeitet der Business-Analyst gemeinsam mit den entsprechenden Stakeholdern das Vorgehen, wiedie Arbeiten erledigt werden sollen. Wenn beispielsweise der Change im Rahmeneines Projekts erfolgt, können die Standards und die Vorgehensweise in derPhase der Projektplanung entwickelt werden.

Der Ansatz der Business-Analyse soll• sich an den Gesamtzielen des Change-Vorhabens ausrichten• die Aufgaben der Business-Analyse mit den Aktivitäten und Ergebnissen des gesamten Change koordinieren• Aufgaben zum Risikomanagement vorsehen, um alle Risiken zu reduzieren, die die Qualität der Ergebnisse der Business-Analyse oder die Effizienz der Arbeiten beeinträchtigen könnten• Ansätze nutzen und Techniken einsetzen, die sich früher gut bewährt haben.



28

3.1

3.1.2

3.1.1

Inputs

• Bedarfe: Der Ansatz der Business-Analyse wird von dem Problem oder den Chancen bestimmt, denen sich das Unternehmen gegenübersieht. Dazu muss alles berücksichtigt werden, was zum Zeitpunkt der Planung über den Bedarf bekannt ist, wohl wissend, dass sich dieses Verständnis erst mit den gesamten Aktivitäten der Business-Analyse vervollständigt.

Abb. 3.1.1: Input-Output-Diagramm „Ansatz der Business-Analyse planen“



29

Input


3.1

Output

Leitfäden undWerkzeuge

UnternehmenspolitischeVorgaben

Expertenurteile

Ansatz der Einbindungder Stakeholder

Leistungsbeurteilung derBusiness-Analyse

Methoden undFrameworks

3.1 Ansatz der

Business-Analyse

Bedarfe

Aufgaben, die diesen Output verwenden

Einbindungder Stakeholder

planen

3.2 Steuerung der


3.3Informationsmanage-

ment der Business-Analyse planen

3.4

Leistungsverbesserungen der Business-Analyse

ermitteln

3.5

Erhebungvorbereiten

4.1Erhebung

durchführen

4.2

Business-Analyse-Informationen

kommunizieren

4.4Zusammenarbeitmit Stakeholdern

managen

4.5

Ist-Zustandanalysieren

6.1

Risikenbewerten

6.3Change-Strategie

definieren

6.4

3.1.3

Elemente

.1 PlanungsansatzEs gibt verschiedene Planungsmethoden quer hinweg über Betrachtungsweisen,Branchen und Unternehmen. Die meisten lassen sich irgendwo zwischen voraus-schauendem (prädiktivem) und sich anpassendem/aufbauendem (adaptivem)Ansatz einordnen.

Vorausschauende Ansätze konzentrieren sich darauf, Unsicherheit im Voraus zuminimieren und sicherzustellen, dass die Lösung vor Beginn der Implementierungbereits definiert ist, um die Kontrolle zu maximieren und Risiken zu minimieren.Diese Ansätze werden oft in Situationen bevorzugt, in denen Anforderungenvor der Umsetzung effektiv definiert werden können und das Risiko einer feh-lerhaften Umsetzung unannehmbar hoch ist, oder wenn die Einbindung vonStakeholdern erhebliche Herausforderungen mit sich bringt.

Adaptive Ansätze konzentrieren sich darauf, in kurzen Iterationen schnell Nutzenzu liefern und dabei durchaus einen höheren Grad an Unsicherheit hinsichtlichder Gesamtlösung in Kauf zu nehmen. Diese Ansätze werden bevorzugt, wennman eher tastend (explorativ) nach der besten Lösung sucht oder wenn einebestehende Lösung nur inkrementell verbessert werden soll.

Unterschiedliche Ansätze können in dem gleichen Vorhaben verwendet werden.Unter anderem kann der Business-Analyst betriebliche Standards bei der Planungvon Aktivitäten der Business-Analyse, die Toleranz im Umgang mit Unsicherheitenoder frühere Erfahrungen mit unterschiedlichen Ansätzen berücksichtigen.

Unabhängig von der Vorgehensweise ist die Planung wichtig, um sicherzustellen,dass Nutzen für das Unternehmen entsteht. Die Planung wird für eine bestimmteInitiative typischerweise mehrmals durchgeführt, da Pläne geändert werden müs-sen, um veränderte Bedingungen und neu aufgeworfene Fragen angemessenzu berücksichtigen. Der Ansatz der Business-Analyse sollte auch beschreiben,wie Pläne bei Bedarf zu ändern sind.

.2 Formalität und Detaillierungsgrad der Ergebnisse der Business-Analyse Bei der Definition des Business-Analyse-Ansatzes ist der Formalisierungsgrad sozu wählen, dass er für den Planungsansatz angemessen ist.

Vorausschauende Ansätze erfordern typischerweise formale Dokumentationenund Darstellungen. Informationen der Business-Analyse können in formalenDokumenten mit standardisierten Vorlagen erfasst werden. Informationen werdenmit unterschiedlichem Detaillierungsgrad erfasst. Der spezifische Inhalt und diespezifische Form der Informationen der Business-Analyse können je nach denverwendeten organisatorischen Methoden, Prozessen und Vorlagen variieren.

Adaptive Ansätze favorisieren die Festlegung von Anforderungen und Entwürfendurch Interaktionen des Teams und durch die Berücksichtigung von Feedback zu



30

3.1.4

einer (Zwischen-)Lösung. Eine verbindliche Dokumentation von Anforderungenbeschränkt sich oft auf eine begrenzte Liste priorisierter Anforderungen. WeitereDokumentationen der Business-Analyse können nach freiem Ermessen des Teamsgeschaffen werden und bestehen im Allgemeinen aus eigens ent wickelten Model-len, um dem Team ein spezifisches Problem verständlich zu machen. Eine förmlicheDokumentation wird häufig erst erstellt, nachdem die Lösung bereits implementiertist, und dient dazu, den Wissenstransfer zu erleichtern. Andere Überlegungen,die die Vorgehensweise beeinflussen können, sind z.B.:• die Änderung ist komplex und birgt ein hohes Risiko• das Unternehmen ist Teil von oder steht in Wechselwirkung mit stark regulierten Branchen• Verträge oder Vereinbarungen erfordern hohe Formalisierung• Stakeholder sind geografisch weit verteilt• Ressourcen sind ausgelagert• die Personalfluktuation ist hoch und/oder die Teammitglieder sind unerfahren• Anforderungen müssen formell genehmigt werden • Informationen der Business-Analyse müssen langfristig erhalten und gewartet oder zur Verwendung für künftige Initiativen weitergegeben werden.

Tabelle 3.1.2: Formalität und Detaillierungsgrad der Leistungen der Business-Analyse



31

Ansatz

Vorausschauend(prädikativ)

Adaptiv

Lösungs-definition

Grad derFormalität

Aktivitäten

Timing

Vor Implementierung be-schrieben, um Kontrolle zu maximieren und Risiken zu minimieren.

Formal – die Information ist in standardisierten Formu-laren erfasst.

Die erforderliche Aktivitäten zur Erarbeitung der Ergeb-nisse werden zunächst identifiziert und dann in Aufgaben unterteilt.

Aufgaben werden in be-stimmten Phasen durchge-führt.

Iterativ beschrieben, um die beste Lösung zu erreichen oder eine bestehende Lösung zu verbessern.

Informal – die Information wird durch Interaktionen im Team und durch Feedback gesammelt.

Aktivitäten werden zuerst in Iterationen mit den ge-wünschten Ergebnissen aufgegliedert, dann werden die damit verbundenen Aufgaben festgelegt.

Aufgaben werden iterativ ausgeführt.

.3 Aktivitäten der Business-AnalyseEin Ansatz der Business-Analyse liefert eine Beschreibung der Arten von Aktivitäten,die vom Business-Analysten durchgeführt werden. Oft hängen die ausgewähltenAktivitäten von den Methoden ab, die vom Unternehmen genutzt werden.

Zur Integration von Aktivitäten in den Ansatz der Business-Analyse gehören:• Identifizieren der Aktivitäten, die erforderlich sind, um ein Ergebnis fertigstellen zu können. Dann werden die Aktivitäten in Einzelauf-gaben aufgegliedert.• Aufteilen der Arbeit in Iterationen, Festlegen der zu erbringenden Ergebnisse für jede Iteration und Identifizieren der damit verbundenen Tätigkeiten und Aufgaben. • Nutzung eines früheren, ähnlichen Vorhabens als Rahmen, der um konkrete Aufgaben und Tätigkeiten ergänzt wird, die speziell für die aktuelle Initiative relevant sind.

.4 Zeitliche Koordination der Arbeit der Business-AnalyseDer Business-Analyst legt fest, wann die Aufgaben der Business-Analyse durchge-führt werden müssen und ob sich die Höhe des Aufwands im Laufe der Zeitändert. Zu dieser Planung gehört auch die Festlegung, ob die Aufgaben der Busi-ness-Analyse, die zu anderen Wissensgebieten gehören, hauptsächlich in bestimm-ten Phasen oder iterativ im Laufe der gesamten Initiative durchgeführt werden.

Der Zeitpunkt der Aktivitäten der Business-Analyse kann beeinflusst werdendurch• die Verfügbarkeit von Ressourcen• Wichtigkeit und/oder Dringlichkeit des Vorhabens• andere gleichzeitig laufende Vorhaben • Restriktionen wie z.B. Vertragsbedingungen oder aufsichtsrechtliche Fristen.

.5 Komplexität und Risiken Die Komplexität, die Größe des Change-Vorhabens und das Gesamtrisiko fürdas Unternehmen sind bei der Festlegung des Ansatzes der Business-Analyse zuberücksichtigen. Weil sich Komplexität und Risiken erhöhen oder vermindernkönnen, kann dadurch die Art und der Umfang der Arbeit der Business-Analysebeeinflusst werden und damit auch den gewählten Ansatz verändern.

Der Ansatz kann auch von der Anzahl der Stakeholder und der Ressourcen fürdie Business-Analyse abhängen. Wenn die Zahl der Stakeholder steigt, muss dieVorgehensweise so angepasst werden, dass zusätzliche Prozessschritte aufge-nommen werden, um die Arbeit der Business-Analyse besser steuern zu können.



32

Andere Faktoren, die Einfluss auf die Komplexität haben können, sind:• Größe der Changes• Anzahl der betroffenen Geschäftsbereiche oder Systeme• geografische und kulturelle Faktoren• technologische Komplexität• andere Risiken, die die Business-Analyse behindern könnten.

Von folgenden Faktoren hängt das Risikoniveau für den Aufwand der Business-Analyse ab:• Erfahrung des Business-Analysten• Kenntnisstand des Business-Analysten über das Arbeitsgebiet/die Domäne• Erfahrung der Stakeholder, ihre Bedürfnisse zu kommunizieren• Einstellung der Stakeholder zu einem Vorhaben und zur Business- Analyse im Allgemeinen• Zeit und Aufwand, die von den Stakeholdern für die Arbeiten der Business-Analyse vorgesehen werden• alle Rahmenwerke, Methoden, Werkzeuge und/oder Techniken, die durch betriebliche Richtlinien und Praktiken vorgegeben sind• Unternehmenskultur.

.6 Akzeptanz Der Ansatz der Business-Analyse wird von den Key-Stakeholdern überprüft undgenehmigt. In einigen Unternehmen kann der Prozess der Business-Analyse stärkerstrukturiert sein, und es wird die Unterschrift von Key-Stakeholdern gefordert,um sicherzustellen, dass alle notwendigen Aktivitäten identifiziert wurden, dieSchätzungen realistisch und die vorgeschlagenen Rollen und Verantwortlichkeitenkorrekt sind. Alle Probleme und Fragen, die von den Stakeholdern bei der Über-prüfung des Ansatzes genannt wurden, werden vom Business-Analysten doku-mentiert und behandelt. Stakeholder spielen auch bei der Überprüfung undAbnahme von Änderungen des Ansatzes der Business-Analyse, die vorgenommenwerden, um veränderte Bedingungen zu berücksichtigen, eine Rolle.

Leitfäden und Werkzeuge

• Leistungsbeurteilung der Business-Analyse: Sie liefert Ergebnisse früherer Beurteilungen, die zu überprüfen und in alle Planungs ansätze einzuarbei-ten sind.• Unternehmenspolitische Vorgaben: Sie definieren die Grenzen, innerhalb derer die Entscheidungen getroffen werden müssen. Sie können durch Regelungen, Verträge, Vereinbarungen, Abmachungen, Gewährleistungen,



33

3.1.5

Zertifizierungen oder andere rechtliche Verpflichtungen beschrieben werden. Diese Vorgaben können den Ansatz der Business-Analyse beein-flussen.• Expertenurteile: Sie werden genutzt, um den Ansatz der Business-Analysezu optimieren. Das Fachwissen kann aus einer Vielzahl von Quellen stam-men, wie zum Beispiel Stakeholder der Initiative, Kompetenzzentren des Unternehmens, Berater, Vereinigungen oder Branchen. Die Erfahrungen des Business-Analysten und anderer Stakeholder sollten bei der Auswahl oder Veränderung eines Ansatzes beachtet werden.• Methoden und Frameworks: Sie prägen den Ansatz, indem sie Methoden,Techniken, Verfahren, Arbeitskonzepte und Regeln vorgeben. Unter Umständen müssen sie auf die Bedürfnisse der konkreten betrieblichen Herausforderung zugeschnitten werden.• Ansatz der Einbindung der Stakeholder: Werden die Stakeholder und deren Anliegen und Interessen richtig verstanden, beeinflusst dies den gewählten Ansatz der Business-Analyse.

Techniken

• Brainstorming: Wird verwendet, um mögliche Aktivitäten, Methoden, Risiken und andere für die Business-Analyse relevante Sachverhalte zu identifizieren und kann dazu beitragen, den Ansatz der Business-Analyse zu entwickeln.• Business Cases: Werden verwendet, um zu verstehen, ob es Elemente gibt (Probleme/Möglichkeiten), die besonders zeitkritisch oder hochwertig sind, oder ob es Unsicherheiten gibt bezüglich Bedarfs- oder Lösungselementen.• Dokumentenanalysen: Werden genutzt, um bestehende organisatorische Assets/Unternehmens-Assets zu prüfen, die für die Planung des Ansatzes nützlich sein könnten.• Schätzung: Wird verwendet, um die Dauer von Aktivitäten der Business-Analyse zu bestimmen.• Finanzanalyse: Wird verwendet, um herauszufinden, wie der Nutzen von den verschiedenen Ansätzen (und den vorgesehenen Lieferoptionen) beeinflusst wird.• Funktionale Gliederung: Wird verwendet, um komplexe Prozesse oder Ansätze der Business-Analyse in handhabbare Komponenten aufzuteilen.• Interviews: Werden genutzt, um gemeinsam mit einem Einzelnen oder einer kleinen Gruppe, Aktivitäten zu planen.• Item Tracking: Dient dazu, Probleme, die bei Planungsaktivitäten auftauchen, zu verfolgen. Es können auch die risikobehafteten Themen verfolgt werden, die während der Diskussionen bei der Erstellung des Ansatzes auftreten.



34

3.1.6

• Lessons Learned: Dienen dazu, die bisherigen Erfahrungen eines Unter-nehmens (Erfolge und Herausforderungen) bei der Planung des Ansatzes der Business-Analyse zu berücksichtigen.• Prozessmodellierung: Wird zur Definition und Dokumentation des Ansatzesder Business-Analyse verwendet.• Reviews: Werden genutzt, um den ausgewählten Ansatz der Business-Analyse mit den Stakeholdern anzustimmen.• Risikoanalyse und -management: Wird verwendet, um Risiken einzu-schätzen und bei der Auswahl des Ansatzes der Business-Analyse zu berücksichtigen.• Scope-Modellierung: Wird verwendet, um die Grenzen der Lösung als Input für Planung und Schätzung festzulegen.• Umfrage oder Fragebogen: Werden verwendet, um mögliche Aktivitäten der Business-Analyse, Techniken, Risiken und andere Elemente, die für die Erstellung des Ansatzes der Business-Analyse relevant sind, zu identifizieren.• Workshops: Werden genutzt, um die Planung in Team-Meetings zu unterstützen.

Stakeholder

• Fachexperte: Er kann dann ein Risikofaktor sein, wenn seine Mitwirkung erforderlich ist, er aber nicht zur Verfügung steht. Der gewählte Ansatz kann von der Verfügbarkeit und dem Umfang der Beteiligung der Fach-experten an dem Vorhaben abhängig sein.• Projektmanager: Er sorgt für einen realistischen Ansatz für den Gesamt-plan inkl. Zeitpläne. Der Ansatz der Business-Analyse muss mit anderen Tätigkeiten vereinbar sein.• Regulierer: Er kann benötigt werden, um Aspekte des Ansatzes der Business-Analyse oder Entscheidungen zu dem Prozess freizugeben, insbesondere in Unternehmen, in denen der Prozess der Business-Analyse auditiert ist.• Sponsor: Er kann Bedarfe und Ziele für den Ansatz vorgeben und stellt sicher, dass Unternehmenspolitiken eingehalten werden. Der gewählte Ansatz wird von seiner Verfügbarkeit und seinem Engagement bei dem Vorhaben abhängen.

Outputs

• Ansatz der Business-Analyse: In ihm wird der Ansatz der Business-Analyse mit den zugehörigen Aktivitäten für das gesamte Vorhaben festgelegt. Er



35

3.1.7

3.1.8

regelt, wer die Aktivitäten durchführt, den Zeitplan und die Abfolge der Arbeiten, die zu erbringenden Ergebnisse und die zu nutzenden Techniken. Die restlichen Ergebnisse des Wissensgebiets „Planung und Überwachung der Business-Analyse“ können in das Gesamtkonzept integriert werden oder unabhängig davon sein. Dies hängt von der gewählten Methodik, Organisa-tion und Perspektive ab.

Einbindung der Stakeholder planen

Zweck

Der Zweck von „Einbindung der Stakeholder planen“ ist es, einen Weg zufinden, wie effektive Arbeitsbeziehungen mit den Stakeholdern erreicht undaufrechterhalten werden können.

Beschreibung

Zu „Einbindung der Stakeholder planen“ gehört eine gründliche Stakeholder-Analyse, um alle beteiligten Stakeholder zu identifizieren und deren Charakte-ristiken/Eigenheiten/Eigenschaften zu analysieren. Aus den Ergebnissen der Ana-lyse werden die besten Ansätze der Zusammenarbeit und Kommunikation fürdas Vorhaben unter Berücksichtigung des Stakeholder-Risikos festgelegt.

Die Planung der Einbindung der Stakeholder kann unverhältnismäßig komplexwerden, wenn sehr viele Stakeholder in die Aktivitäten der Business-Analyseeinbezogen werden. Es können dann neue oder andere Techniken für dasManagement der Stakeholder erforderlich werden, wenn sich die Zusammenarbeitvon einigen wenigen Stakeholdern auf Dutzende, Hunderte oder sogar TausendePersonen erhöht.

Inputs

• Bedarfe: Das Verständnis über den betrieblichen Bedarf und über die betroffenen Teile des Unternehmens hilft dabei, die relevanten Stake-holder zu identifizieren. Im Laufe der Analyse der Stakeholder kann der Bedarf präzisiert werden.• Ansatz der Business-Analyse: Der gesamte Ansatz der Business-Analyse muss in die Analyse der Stakeholder und die Ansätze der Zusammenarbeitund Kommunikation einbezogen werden, um die Konsistenz zwischen den Ansätzen zu gewährleisten.



36

3.2.1

3.2.2

3.2

3.2.3

Abb. 3.2.1: Input-Output-Diagramm „Einbindung der Stakeholder planen“



37

Einbindung der Stakeholder planen3.2

Output

3.2 Ansatz der

Einbindung derStakeholder



planen

3.1 Steuerung der


3.3Informationsmanage-

ment der Business-Analyse planen

3.4

Erhebungvorbereiten

4.1Erhebung

durchführen

4.2Business-Analyse-

Informationenkommunizieren

4.4

Zusammenarbeitmit Stakeholdern

managen

4.5

Risikenbewerten

6.3

Change-Strategiedefinieren

6.4

Input

Bedarfe Ansatz derBusiness-Analyse

3.1


Leistungsbeurteilungder Business-Analyse

Change-Strategie

Beschreibung desIst-Zustands

Elemente

.1 Stakeholder-Analyse durchführen Zur Stakeholder-Analyse gehören die Identifizierung der Stakeholder (wer wirddurch den Change direkt oder indirekt beeinflusst) und deren Charakteristikasowie die Analyse der schon einmal erfassten Informationen. Die Stakeholder-Analyse wird wiederholt durchgeführt, solange die Aktivitäten der Business-Analyse andauern.

Eine vollständige und detaillierte Stakeholder-Liste stellt sicher, dass keine Betei-ligten übersehen werden. Es ist wichtig zu verstehen, wer die Stakeholder sind,welche Auswirkungen die vorgeschlagenen Veränderungen auf die Stakeholderhaben und welchen Einflusses die Stakeholder auf den Change haben können.Nur so ist es möglich, die Bedarfe, die Wünsche und die Erwartungen der Stake-holder mit der Lösung zu erfüllen. Wenn Stakeholder nicht rechtzeitig erkanntwerden, kann der Business-Analyst möglicherweise kritische Anforderungennicht berücksichtigen. Spät entdeckte Stakeholder-Bedarfe erfordern dann wahr-scheinlich eine Überarbeitung von Aufgaben der Business-Analyse, die entwederin Arbeit oder bereits abgeschlossen sind. Dies kann zu erhöhten Kosten führenund verringert die Zufriedenheit der Stakeholder.

Wie der Business-Analyst die Stakeholder-Analyse durchführt, hängt auch vonden Projekten, Methoden und Unternehmen ab. Das Organigramm und dieGeschäftsprozesse eines Unternehmens können als eine erste Quelle zur Identi-fizierung interner Stakeholder dienen. Auch kann der Sponsor Stakeholder nen-nen. Stakeholder außerhalb der Organisation lassen sich aus bestehenden Ver-trägen ableiten, auch können mögliche spätere Anbieter sowie regulatorischeGremien und gesetzgebende Stellen Stakeholder eines Change sein. Aktionäre,Kunden und Lieferanten können ebenfalls bei der Suche nach externen Stake-holdern ins Auge gefasst werden.

Rollen

Der Business-Analyst identifiziert Stakeholder-Rollen, um zu verstehen, wo undwie die Stakeholder an einem Vorhaben mitwirken. Es ist wichtig, dass demBusiness-Analysten die verschiedenen Rollen eines einzelnen Stakeholders bewusstsind, für die dieser in einem Unternehmen verantwortlich ist.

Einstellungen

Die Einstellungen der Stakeholder können sich positiv oder negativ auf die Ver-änderung auswirken. Der Business-Analyst ermittelt die Einstellungen der Sta-keholder, um zu verstehen, wodurch ihre Handlungen und Verhaltensweisenbeeinflusst sein können. Ist bekannt, wie ein Stakeholder ein Vorhaben wahr-nimmt, kann der Business-Analyst die Zusammenarbeit und die Einbindung desStakeholders gezielt planen.



38

3.2.4

Der Business-Analyst analysiert die Einstellungen der Stakeholder in Bezug auf• Unternehmensziele, Ziele der Initiative und alle Lösungsvorschläge• die Business-Analyse im Allgemeinen• das Interesse an der Veränderung• den Sponsor• die Teammitglieder und die anderen Beteiligten• die Zusammenarbeit und den Ansatz der Teamarbeit.

Stakeholder mit einer positiven Einstellung können starke Vorkämpfer/Promotorensein und wichtige Beiträge leisten. Andere Stakeholder können nicht erkennen,was das Vorhaben bringen soll, oder sie missverstehen den möglichen Nutzenoder sie machen sich Sorgen wegen der möglichen Auswirkungen des Changeauf sie. Stakeholder, die zentrale Rollen in den Vorhaben einnehmen und wichtigeBeitrage leisten sollen, zu dem Vorhaben aber eine negative Einstellung haben,erfordern konkrete Maßnahmen, um ihre Kooperationsbereitschaft zu erhöhen.

Entscheidungskompetenz

Der Business-Analyst ermittelt die Entscheidungsbefugnisse eines Stakeholdersbezüglich Aktivitäten der Business-Analyse, Ergebnissen sowie Veränderungender Aufgaben der Business-Analyse.

Sind die Entscheidungskompetenzen von Anfang an bekannt, gibt es wenigerMissverständnisse in der Arbeit der Business-Analyse. So kann sichergestellt wer-den, dass der Business-Analyst mit den richtigen Stakeholdern zusammenarbeitet,um Entscheidungen zu treffen oder Genehmigungen einzuholen.

Macht- oder Einflussverhältnisse

Das Verständnis der Art des Einflusses darüber, welche Einflussstrukturen undEinflusskanäle es innerhalb eines Unternehmens gibt, kann beim Beziehungs-aufbau und beim Entwickeln von Vertrauen von unschätzbarem Wert sein. DasWissen über den Einfluss und die Einstellung jedes einzelnen Stakeholders kannbei der Entwicklung von Strategien für das Engagement und die Zusammenarbeithelfen. Der Business-Analyst bewertet, wie viel Einfluss notwendig ist, um einenChange umzusetzen und vergleicht ihn mit dem tatsächlichen Einfluss der zen-tralen Stakeholder. Besteht eine Diskrepanz zwischen dem erforderlichen unddem vorhandenen oder vermutlichen Einfluss des Stakeholders, entwickelt derBusiness-Analyst Risikopläne oder geeignete Ersatzstrategien, um die notwendigeUnterstützung zu erhalten.

.2 Zusammenarbeit mit Stakeholdern festlegen Eine effektive Zusammenarbeit mit den Stakeholdern ist unerlässlich, um dasEngagement für die Aktivitäten der Business-Analyse aufrecht zu halten. Eine



39

Zusammenarbeit kann auch spontan erfolgen. Eine wirkungsvolle Zusammenarbeitmuss allerdings schon während der Planung der Aktivitäten bewusst durchdachtund geplant werden.Der Business-Analyst kann für interne und externe Stakeholder unterschiedlicheAnsätze der Zusammenarbeit vorsehen. Diese Ansätze können sich bei unter-schiedlichen Aktivitäten auch unterscheiden. Ziel ist es, jene Ansätze herauszu-finden, die am besten dazu geeignet sind, die Bedarfe der jeweiligen Stakeholderzu treffen und die sicherstellen, dass das Interesse und Engagement der Stake-holder über das gesamte Vorhaben erhalten bleibt. Einige Über legungen beider Planung der Zusammenarbeit sind:• Zeitpunkt und Häufigkeit der Zusammenarbeit• Ort• Verfügbare Tools wie Wikis und Online-Communities• Vorgehen bei der Einführung, persönlich oder virtuell • Präferenzen der Stakeholder.

Ergebnisse der Planung können dokumentiert werden. Ändern sich Faktoren,können oder müssen diese Pläne überdacht und angepasst werden, um dasnachhaltige Engagement der Stakeholder sicherzustellen.

.3 Kommunikationsbedarf der Stakeholder Der Business-Analyst muss folgende Aspekte beachten:• Was muss kommuniziert werden?• Welche ist die geeignete Verteilungsmethode (schriftlich oder mündlich)?• Wer gehört zur Zielgruppe?• Wann soll die Kommunikation stattfinden?• Wie häufig soll die Kommunikation stattfinden?• Wie ist die geografische Lage der Stakeholder, die die Mitteilungen erhalten sollen?• Welcher Detaillierungsgrad ist für die Kommunikation mit den Stakeholdern geeignet?• Wie formal soll die Kommunikation stattfinden?

Diese Überlegungen zur Kommunikation können als Stakeholder-Kommunikati-onsplan dokumentiert werden. Der Business-Analyst erstellt und überarbeitetdie Kommunikationspläne gemeinsam mit den Stakeholdern, um deren Anfor-derungen und Erwartungen zur Kommunikation zu erfüllen.



40


• Leistungsbeurteilung der Business-Analyse: Sie liefert Ergebnisse früherer Leistungsbeurteilungen, die überprüft und berücksichtigt werden sollten.• Change-Strategie: Sie wird für eine bessere Beurteilung des Einflusses der Stakeholder und für die Entwicklung effektiver Strategien zur Einbindung der Stakeholder eingesetzt.• Beschreibung des Ist-Zustands: Er liefert den Kontext, in dem die Arbeit erledigt werden muss. Diese Information wird zu einer effektiveren Stakeholder-Analyse und einem besseren Verständnis der Auswirkungen des gewünschten Changes führen.

Techniken

• Brainstorming: Wird verwendet, um die Stakeholder-Liste zu erstellen und Rollen und Verantwortlichkeiten der Stakeholder zu identifizieren.• Analyse der Geschäftsregeln: Identifiziert Stakeholder, die an der Erstellung der Geschäftsregeln beteiligt waren.• Dokumentenanalyse: Wird verwendet, um die bestehenden Unter-nehmens-Assets zu überprüfen, mit deren Hilfe die Einbindung der Stakeholder geplant werden kann.• Interviews: Dienen dazu, mit bestimmten Stakeholdern zusammen-zuarbeiten, um weitere Informationen über Stakeholder-Gruppen zu erhalten.• Lessons Learned: Damit werden die bisherigen Erfahrungen eines Unternehmens (Erfolge wie auch Herausforderungen) bei der Planung der Einbindung der Stakeholder ermittelt.• Mind Mapping: Wird verwendet, um potentielle Stakeholder zu identi-fizieren und die Beziehungen zwischen ihnen zu verdeutlichen.• Organisationsmodellierung: Wird verwendet, um festzustellen, ob die angeführten Organisationseinheiten oder Personen besondere Bedürf-nisse oder besondere Interessen haben, die berücksichtigt werden sollten. Organisationsmodelle beschreiben die Rollen und Funktionen im Unternehmen und die Art, in der die Stakeholder zusammenarbeiten. Organisationsmodelle können somit helfen, Stakeholder zu identifizieren, die vom Change betroffen sein werden.• Prozessmodellierung: Wird verwendet, um Stakeholder anhand der Systeme zu kategorisieren, die ihre Geschäftsprozesse unterstützen.• Risikoanalyse und -management: Dienen dazu, Risiken für das Vorhaben zu ermitteln, die aus den Einstellungen der Stakeholder oder daraus resultieren, dass sich Key-Stakeholder an dem Vorhaben nicht beteiligen.



41

3.2.5

3.2.6

• Scope-Modellierung: Wird verwendet, um mit Hilfe der Modelle zu zeigen, dass Interessen von Stakeholdern möglicherweise zwar nicht in den Lösungsumfang (Scope der Lösung) fallen, aber dennoch direkt oder indirekt mit der Lösung in irgendeiner Weise zusammenhängen.• Stakeholder-Listen, -Karten oder Personas: Werden verwendet, um die Beziehungen der Beteiligten zur Lösung und untereinander (bildlich) darzustellen.• Umfrage oder Fragebogen: Werden verwendet, um gemeinsame Merk-male einer Stakeholder-Gruppe zu identifizieren.• Workshops: Werden mit Stakeholder-Gruppen veranstaltet, um mehr Information über sie zu erhalten.

Stakeholder

• Kunden: Das können externe Stakeholder sein.• Fachexperte: Er kann helfen, Stakeholder zu identifizieren und kann selbst Stakeholder sein, der eine oder mehrere Rollen in dem Vorhaben übernimmt.• Anwender: Das können interne Stakeholder sein.• Projektmanager: Er kann Stakeholder erkennen und empfehlen. Die Verantwortung für die Identifikation und Steuerung der Stakeholder kann er mit dem Business-Analysten teilen.• Regulierer: Er kann verlangen, dass bestimmte Stakeholder-Vertreter oder -Gruppen in die Aktivitäten der Business-Analyse einbezogen werden.• Sponsor: Er kann verlangen, dass bestimmte Stakeholder in die Aktivitä-ten der Business-Analyse einbezogen werden.

Outputs

• Ansatz der Einbindung der Stakeholder: Er enthält eine Liste der Stake-holder, deren ermittelte Charakteristika und eine Auflistung der Rollen und Verantwortlichkeiten für den Change. Aus ihm sind zusätzlich die Ansätze der Zusammenarbeit und Kommunikation ersichtlich, die der Business-Analyst während der Initiative nutzen wird.



42

3.2.7

3.2.8

Steuerung der Business-Analyse planen

Zweck

Der Zweck von „Steuerung der Business-Analyse planen“ ist es, festzulegen,wie über Anforderungen und Designs, Reviews, Kontrollen, Genehmigungenund Priorisierungen entschieden wird.

Beschreibung

Der Business-Analyst gewährleistet, dass ein Steuerungsprozess implementiert istund alle Unklarheiten beseitigt sind. Dieser Prozess legt die Entscheidungsträger,die Abläufe und die für die zu treffenden Entscheidungen benötigten Informationenfest. Ein Steuerungsprozess regelt, wie Genehmigungen und Entscheidungen überdie Priorisierungen für Anforderungen und Designs getroffen werden.

Bei der Planung des Steuerungsansatzes legt der Business-Analyst fest,• wie an die Arbeit der Business-Analyse herangegangen wird und wie sie priorisiert wird• wie der Prozess abläuft, wenn Veränderungen für Informationen der Business-Analyse vorgeschlagen werden• wer die Befugnisse und die Verantwortung hat, Changes vorzuschla-gen und wer in die Change-Diskussionen einbezogen werden soll• wer für die Analyse von Change-Anforderungen verantwortlich ist• wer befugt ist, Changes zu genehmigen• wie Changes dokumentiert und kommuniziert werden.

Inputs

• Ansatz der Business-Analyse: Es ist notwendig, den übergreifenden Ansatz der Business-Analyse in den Governance-Ansatz einzubeziehen, um Konsistenz zwischen den Ansätzen zu gewährleisten.• Ansatz der Einbindung der Stakeholder: Es ist hilfreich, die Stakeholder und ihre Kommunikations- und Zusammenarbeitsbedürfnisse zu verstehen, wenn die Beteiligung der Stakeholder am Governance-Ansatz festgelegt wird. Der Ansatz der Stakeholder-Einbindung kann aktualisiert werden, wenn der Governance-Ansatz fertiggestellt ist.



43

3.3

3.3.1

3.3.2

3.3.3

Abb. 3.3.1: Input-Output-Diagramm „Steuerung der Business-Analyse planen“

Elemente

.1 Entscheidungsfindung In dem gesamten Vorhaben sind laufend Entscheidungen zu treffen. Ein Stakeholderkann im Entscheidungsprozess verschiedene Rollen einnehmen, z.B.• Teilnehmer in Entscheidungsdiskussionen



44

Input


Stakeholder

3.2

Ansatz derSteuerung

3.3

Anforderungenpriorisieren

5.3



3.3

Output


Gesetzliche Regelungen

3.1 Ansatz der

Business-Analyse

Änderungen vonAnforderungen

beurteilen

5.4

Anforderungengenehmigen

5.5


Analyse planen

3.4




3.3.4

• Fachexperte, der Erfahrung und Wissen für den Entscheidungsprozess zur Verfügung stellt• Reviewer von Informationen• Entscheider.

Der Entscheidungsprozess legt fest, was zu tun ist, falls Teams sich nicht einigenkönnen, indem Eskalationspfade und Key Stakeholder mit endgültiger Entschei-dungsbefugnis bestimmt werden.

.2 Steuerungsprozess des Change Mit einem Steuerungsprozess des Change legt der Business-Analyst fest, • wie der Prozess für die Anforderung von Changes aussieht: In ihm wird spezifiziert, welche Anforderungen und Designs der Steuerungs-prozess des Change abdecken soll und ob er für alle Changes gelten soll oder nur für Changes einer bestimmten Größe, mit bestimmten Kosten oder bestimmtem Aufwand. Dieser Prozess detailliert die not-wendigen Schritte für einen Change-Vorschlag, wann ein Change vorgeschlagen werden kann, wer den Change vorschlagen kann und wie Change-Anforderungen kommuniziert werden.• welche Elemente eine Change-Anforderung hat: Es wird festgelegt, welche Informationen ein Vorschlag für die Entscheidungsfindung undUmsetzung enthalten muss. Mögliche Komponenten, die in einem Change-Antrag zu berücksichtigen sind:• Kosten- und Zeitschätzungen: Die erwarteten Kosten des Change werden für jeden Bereich geschätzt, der vom vorgeschlagenen Change betroffen ist.

• Nutzen: Die Erläuterung des Nutzens des Change im Rahmen des gesamten Vorhabens, welche Vorteile der Change bringt und inwie-weit er mit den Unternehmenszielen vereinbar ist. Der Nutzen berück-sichtigt sowohl finanzielle Vorteile und taktische Vorteile, als auch die Auswirkungen auf Scope, Zeit, Kosten, Qualität und Ressourcen.

• Risiken: Eine Analyse der Risiken, die sich möglicherweise für das Vorhaben, die Lösung oder die Geschäftsziele ergeben können.

• Priorität: Der Stellenwert des Change bezogen auf andere Faktoren wie betriebliche Ziele, Compliance-Anforderungen und Bedarfe der Stakeholder.

• Mögliche Varianten: Es ist üblich, mehrere Varianten zu betrachten, ein-schließlich des Vorschlags des Anfordernden und anderer Stakeholder, damit die Entscheidungsträger die Variante auswählen können, die die Bedarfe des gesamten Vorhabens am besten erfüllt. Für diese Varian-ten werden die Kriterien (wie z.B. Kosten, Zeit, Vorteile, Risiken und Priorität) ermittelt und bewertet.



45

• Festlegung, wie Changes priorisiert werden: Die vorgeschlagene Veränderung wird dabei relativ zu anderen konkurrierenden Interessenin dem Vorhaben priorisiert.• Festlegung, wie Changes dokumentiert werden: Ein Konfigurations-management und Standards für Nachvollziehbarkeit liefern Produkt-Baselines und Verfahren zur Versionskontrolle, mit denen ermittelt wird, welche Termine durch den Change betroffen sind.• Festlegung, wie Changes kommuniziert werden: Es wird festgelegt, wie vorgeschlagene Changes, Changes in Überprüfung und geneh-migte, abgelehnte oder zurückgestellte Changes den Stakeholdern kommuniziert werden.• Festlegung, wer die Wirkungsanalyse durchführen wird: Die Zustän-digkeit und Verantwortung für die Durchführung einer Analyse der Auswirkungen des vorgeschlagenen Change auf das gesamte Vor-haben wird festgelegt.• Festlegung, wer Changes genehmigen wird: Ernennung einer Person, welche die Changes genehmigen darf, und Festlegung, für welche Informationen der Business-Analyse sie zuständig ist.

.3 Planen des Ansatzes der Priorisierung Zeitschienen, erwarteter Nutzen, Abhängigkeiten, Ressourcenbeschränkungen,angewandte Methoden und andere Faktoren wirken sich darauf aus, wie Anfor-derungen und Designs priorisiert werden.

Bei der Planung des Priorisierungsprozesses legt der Business-Analyst fest:• Formalität und Verbindlichkeit des Priorisierungsprozesses• Teilnehmer, die an der Priorisierung zu beteiligen sind• Vorgehen bei der Entscheidung, wie zu priorisieren ist, inkl. der verwendeten Priorisierungstechniken • Kriterien, die für die Priorisierung verwendet werden. Zum Beispiel können Anforderungen basierend auf Kosten, Risiko und Nutzen priorisiert werden.

Der Ansatz sollte auch festlegen, welche Stakeholder eine Rolle bei der Priori-sierung wahrnehmen werden.

.4 Planen der GenehmigungenEine Genehmigung formalisiert die Vereinbarung zwischen allen Stakeholdern,dass der Inhalt und die Darstellung der Anforderungen und Designs korrekt,angemessen und ausreichend detailliert sind, um die Arbeit erfolgreich fortsetzenzu können.



46

Zeitpunkt und Häufigkeit von Genehmigungen sind abhängig von der Größeund Komplexität des Change und der Risiken, eine Genehmigung zu unterlassenoder zu verzögern.

Der Business-Analyst muss die Art der zu genehmigenden Anforderungen undDesigns, den Zeitpunkt für die Genehmigung, den bei der Genehmigung einzu-haltenden Prozess und den Entscheidungsberechtigten festlegen.

Bei der Planung eines Genehmigungsprozesses muss der Business-Analyst dieOrganisationskultur und die Art der zu genehmigenden Informationen berück-sichtigen. Zum Beispiel erfordern neue Systeme oder Prozesse in stark reguliertenBranchen wie Finanzwesen, Pharmaunternehmen oder Gesundheitsleistungenwahrscheinlich häufigere und gründlichere Überprüfungen und Genehmigungenvon sehr detaillierten Spezifikationen. Für andere Typen von Vorhaben kann einweniger intensiver Genehmigungsprozess angemessen sein und schnellere Ergeb-nisse möglich machen.

Zur Planung der Genehmigungen gehören auch die Genehmigungstermine unddie Terminverfolgung. Verfügbarkeit und Einstellungen der Stakeholder sowiederen Bereitschaft zum Engagement bestimmen die Effizienz des Genehmi-gungsprozesses und können sich erheblich auf die Fertigstellungstermine aus-wirken.


• Leistungsbeurteilung der Business-Analyse: Liefert Ergebnisse früherer Be-urteilungen, die zu überprüfen und in alle Planungsansätze einzuarbeiten sind.• Unternehmenspolitische Vorgaben: Definieren die Grenzen, innerhalb dererdie Entscheidungen getroffen werden müssen. Sie können in Regelungen, Verträgen, Vereinbarungen, Abmachungen, Gewährleistungen, Zertifizie-rungen oder anderen rechtlichen Verpflichtungen beschrieben sein.• Beschreibung des Ist-Zustands: Liefert den Kontext, in dem die Arbeit erledigt werden muss. Diese Informationen können helfen, bessere Ent-scheidungen zu treffen.• Gesetzliche Regelungen: Verbindliche Regeln oder Vorschriften, die einge-halten werden müssen und die genutzt werden können, um ein Rahmen-werk zu entwickeln, innerhalb dessen solide Entscheidungen der Business-Analyse gefällt werden können.

Techniken

• Brainstorming: Wird verwendet, um eine erste Liste potentieller Stake-holder zu erstellen, die im definierten Steuerungsprozess Rollen als Entscheider übernehmen könnten.



47

3.3.5

3.3.6

• Dokumentenanalysen: Werden verwendet, um den bestehenden Steue-rungsprozess oder vorhandene Vorlagen zu beurteilen.• Interviews: Werden genutzt, um mit einzelnen Personen oder in einer kleinen Gruppe mögliche Ansätze und Beteiligte für die Entscheidungs-findung, Steuerung des Change, Genehmigungen oder Priorisierungen zu ermitteln.• Item Tracking: Wird verwendet, um jeden möglichen Sachverhalt zu verfolgen, der bei der Planung des Steuerungsansatzes auftaucht.• Lessons Learned: Wird verwendet, um aus früheren Erfahrungen Hinweise zu finden, die für Planung der Steuerung bei aktuellen oder zukünftigen Vorhaben genutzt werden können.• Organisationsmodellierung: Wird verwendet, um Rollen und Verantwort-lichkeiten innerhalb des Unternehmens zu verstehen, damit ein Steue-rungsansatz festgelegt werden kann, der die richtigen Stakeholder einbezieht.• Prozessmodellierung: Wird verwendet, um den Prozess oder die Methode für die Steuerung der Business-Analyse zu dokumentieren.• Reviews: Werden genutzt, um den vorgeschlagenen Governance-Plan mitden zentralen Stakeholdern zu überprüfen.• Umfrage oder Fragebogen: Werden verwendet, um mögliche Ansätze und Teilnehmer der Entscheidungsfindung, der Change-Kontrolle, der Genehmigung oder der Priorisierung zu identifizieren.• Workshops: Werden verwendet, um mögliche Ansätze und Teilnehmer der Entscheidungsfindung, der Change-Kontrolle, der Genehmigung oder der Priorisierung in Team-Meetings zu identifizieren.

Stakeholder

• Fachexperte: Er kann selbst einen Change anfordern oder als Teilnehmer in Change-Diskussionen benötigt werden.• Projektmanager: Er arbeitet mit dem Business-Analysten zusammen, um sicherzustellen, dass die Gesamtprojektsteuerung mit dem Ansatz der Steuerung der Business-Analyse abgestimmt ist.• Regulierer: Er kann Regeln oder Vorschriften auferlegen, die bei der Fest-legung des Steuerungsplans der Business-Analyse berücksichtigt werden müssen. Er kann selbst auch Changes anfordern.• Sponsor: Er kann eigene Anforderungen zur Verwaltung von Informatio-nen der Business-Analyse einbringen. Er beteiligt sich an Change-Diskus-sionen und genehmigt vorgeschlagene Changes.



48

3.3.7

Outputs• Ansatz der Steuerung: Er identifiziert die Stakeholder, die für Entscheidungen über die Arbeit der Business-Analyse zuständig sind, legt fest, wer für die Prioritätensetzung verantwortlich ist und wer Änderungen an Informationen der Business-Analyse genehmigt. Er definiert auch den Prozess zur Steuerung von Anforderungs- und Design-Änderungen innerhalb des gesamten Vorhabens.

Informationsmanagement der Business-Analyse planen

ZweckZweck von „Informationsmanagement der Business-Analyse planen“ ist, einenAnsatz zu entwickeln, wie Informationen der Business-Analyse gespeichert undabgerufen werden.

Beschreibung Informationen der Business-Analyse sind alle Informationen, die der Business-Analyst im Zuge einer Business-Analyse erhebt, erstellt, zusammenträgt und wei-tergibt. Modelle, Abgrenzungen, Stakeholder-Anliegen, Erhebungsergebnisse,Anforderungen, Designs und Lösungsmöglichkeiten sind nur wenige Beispiele.Dazu gehören Anforderungen und Designs, die aus einfachen User Stories, formalenAnforderungsdokumenten oder aus funktionierenden Prototypen stammen.

Zu einem Informationsmanagement gehören folgende Festlegungen:• Organisation der Informationen• Detaillierungsgrad der zu erfassenden Informationen• Beziehungen zwischen den Informationen• Sicherstellung der Wiederverwendbarkeit von Informationen für andere Vorhaben und im gesamten Unternehmen• Speicherung und Abruf von Informationen• Kriterien für zu aktualisierende Informationen.

Ein Informationsmanagement stellt sicher, dass die Informationen der Business-Analyse in funktionaler und nützlicher Art und Weise organisiert werden, fürdie zuständigen Mitarbeiter leicht zugänglich sind und für die notwendige Dauergespeichert werden.

Inputs• Ansatz der Business-Analyse: Die Einbeziehung des gesamten Ansatzes derBusiness-Analyse in den Ansatz des Informationsmanagements ist not-wendig, um die Konsistenz zwischen den Ansätzen zu gewährleisten.



49

3.3.8

3.4

3.4.1

3.4.2

3.4.3

• Ansatz der Einbindung der Stakeholder: Bei der Bestimmung der spezifi-schen Ansprüche der Stakeholder an das Informationsmanagement ist es hilfreich, die Stakeholder zu kennen und ihre Bedürfnisse hinsichtlich Kommunikation und Zusammenarbeit zu verstehen.• Ansatz der Steuerung: Legt fest, wie der Business-Analyst mit Changes zu Anforderungen und Designs umgehen muss, wie für die Leistungen der Business-Analyse Entscheidungen zu fällen, Genehmigungen zu erteilen und Prioritäten zu setzen sind.

Abb. 3.4.1: Input-Output-Diagramm „Informationsmanagement der Business-Analyse planen“



50

Input


Stakeholder

3.2


3.4


kommunizieren

4.4

Anforderungenrückverfolgen

5.1



3.4

Output



3.1

Ansatz derSteuerung

3.3

Anforderungenpflegen

5.2 Anforderungs-

architekturdefinieren

7.4

Rechts- und Regelungs-informationen



Werkzeuge desInformationsmanagements

Elemente

.1 Organisation von Informationen der Business-Analyse Der Business-Analyst ist dafür verantwortlich, die Informationen der Business-Analyse so zu organisieren, dass sie leicht zugänglich und effizient zu nutzensind. Informationen müssen gut strukturiert und leicht zu finden sein, es darfkeine Konflikte mit anderen Informationen geben und sie sollen nicht unnötigmehrfach erfasst oder gespeichert werden.

Der Business-Analyst legt zu Beginn des Vorhabens fest, wie die Informationender Business-Analyse am besten zu strukturieren und zu organisieren sind. Dabeimuss berücksichtigt werden, welche Arten und Mengen von Informationen zuerheben sind, welche Zugangs- und Nutzungsbedürfnisse die Stakeholder habenund wie groß und komplex das Vorhaben ist. Beziehungen zwischen den ver-schiedenen Arten von Informationen müssen definiert werden, um auch zukünftigmit neuen oder geänderten Informationen umgehen zu können.

.2 Abstraktionsebene Die Abstraktionsebene beschreibt die Breite und Tiefe der bereitgestellten Infor-mationen. Die Detaillierung der Informationen kann alle Abstufungen habenvon sehr konzeptionell, eher als Überblick zusammengefasst, bis zu sehr detailliert.Die Festlegung, wie viele Detailinformationen jeder Stakeholder über die weitereEntwicklung des Vorhabens verlangen kann, erfolgt mit Rücksicht auf den Bedarfder Stakeholder, die Komplexität des Inhaltes und die Bedeutung des Changes.Anstatt allen Stakeholdern dieselben Informationen zu präsentieren, sollte derBusiness-Analyst Breite und Detaillierung der Informationen auf die Rolle jedesStakeholders abstimmen. Informationen der Business-Analyse über ein sehrwichtiges Thema oder solche, die mit einem hohen Risiko verbunden sind,werden häufig sehr detailliert dargestellt.

.3 Planen des Ansatzes der Traceability Der Ansatz der Traceability hängt ab von• der Komplexität des Arbeitsgebietes• der Anzahl der Sichten auf die Anforderungen• jeglichen anforderungsbezogenen Risiken, Unternehmensstandards, relevanten behördlichen Vorschriften• dem Verständnis der Kosten und des Nutzens, die mit der Nachverfol-gung verbunden sind.

Der Business-Analyst plant den Ansatz mit dem notwendigen Detaillierungsgrad,um Mehrwert zu generieren ohne unangemessenen Aufwand zu erzeugen.



51

3.4.4

.4 Planen der Wiederverwendbarkeit von Anforderungen Eine wiederholte Verwendung von Anforderungen kann einem UnternehmenZeit, Anstrengungen und Kosten sparen, sofern die Anforderungen zugänglichund in einer Weise strukturiert sind, die ihre Wiederverwendung unterstützt.

Potentielle Kandidaten für eine langfristige Nutzung sind diejenigen Anforde-rungen, die ein Unternehmen laufend erfüllen, z.B. • behördliche Vorschriften• vertragliche Verpflichtungen• Qualitätsstandards• Service Level Agreements• Geschäftsregeln• Geschäftsprozesse• Anforderungen an Produkte, die das Unternehmen produziert.

Anforderungen können auch wiederverwendet werden, wenn sie allgemeineFunktionen oder Dienstleistungen beschreiben, die über mehrere Systeme, Pro-zesse oder Programme hinweg verwendet werden.

Um Anforderungen auch nach dem aktuellen Vorhaben zukünftig wiederver-wenden zu können, legt der Business-Analyst fest, wie sie am besten strukturiertund gespeichert werden und wie auf sie zugegriffen werden kann.

Damit Anforderungen wiederverwendbar sind, müssen sie klar benannt, genaubeschrieben und in einer anderen, dem Business-Analysten zugänglichen Daten-bank abgelegt sein.

.5 Speicherung und Zugriff Informationen der Business-Analyse können auf vielfältige Weise gespeichertwerden. Entscheidungen über die Speicherung hängen von vielen Faktoren ab,wie z.B. davon, wer auf die Informationen zugreifen muss, wie oft man daraufzugreifen muss und welche Bedingungen es für den Zugriff gibt.

Auch von Unternehmensstandards und der Verfügbarkeit von Werkzeugen hän-gen die Entscheidungen bezüglich Speicherung und Zugriff ab. Der Ansatz derBusiness-Analyse legt fest, wie die verschiedenen Werkzeuge während des aktu-ellen Vorhabens verwendet werden und wie die Informationen erfasst undgespeichert werden. Tools können die Auswahl der Analysetechniken, die Dar-stellungsform und die Organisation der Informationen beeinflussen.

Das Repository enthält möglicherweise auch andere Informationen und nichtnur Anforderungen und Designs. Es sollte den Status aller Informationen anzeigenund Änderungen im Zeitablauf zulassen.



52

.6 Attribute der Anforderungen Eigenschaften oder Attribute der Anforderungen enthalten Informationen überdie Anforderungen und helfen bei der laufenden Verwaltung der Anforderungenwährend des Change. Sie werden gemeinsam mit den Anforderungen geplantund festgelegt.

Eigenschaften oder Attribute der Anforderungen ermöglichen es dem Business-Analysten, die Informationen mit einzelnen Anforderungen oder mit verwandtenAnforderungsgruppen zu verknüpfen. Die durch Informationen dokumentiertenAttribute helfen dem Team, effizient und effektiv zwischen den Anforderungenabzuwägen, die Stakeholder zu identifizieren, die durch den potentiellen Changebetroffen sein können, und die Auswirkungen eines vorgeschlagenen Changezu verstehen.

Folgende Eigenschaften von Anforderungen werden üblicherweise verwendet:• Eindeutige Kennung: Bietet eine eindeutige Identifizierung. Der Wert wird nie verändert, auch wenn die Anforderung verschoben, geändert oder gelöscht wird, und er wird auch nicht wiederverwendet. • Autor: Name der Person, die zu konsultieren ist, falls später festgestelltwerden sollte, dass die Anforderung mehrdeutig, unklar oder wider-sprüchlich ist.• Komplexität: Gibt an, wie schwierig die Umsetzung der Anforderung sein wird.• Eigentümerschaft: Nennt die Person oder die Gruppe, die die Anforde-rung benötigt oder Eigentümer nach der Umsetzung sein wird.• Priorität: Steht für die relative Bedeutung der Anforderung. Die Priori-tät kann entweder auf den relativen Nutzen einer Anforderung oder die Implementierungs-Reihenfolge verweisen.• Risiken: Zeigen unsichere Ereignisse, von denen die Anforderungen beeinflusst werden können.• Quelle: Zeigt den Ursprung der Anforderung. Die Quelle wird häufig konsultiert, wenn sich die Anforderung ändert oder wenn zusätzliche Informationen über die Anforderung oder den Bedarf eingeholt wer-den müssen, der zur Anforderung geführt hat.• Stabilität: Steht für den Reifegrad der Anforderung.• Status: Zeigt den Status der Anforderung: vorgeschlagen, akzeptiert, überprüft, verschoben, abgesagt oder implementiert.• Dringlichkeit: Gibt an, wie schnell die Anforderung umgesetzt werden muss. Wird üblicherweise nur dann getrennt von der Priorität festge-legt, wenn es eine bestimmte Frist für die Umsetzung gibt.



53


• Leistungsbeurteilung der Business-Analyse: Sie liefert Ergebnisse früherer Beurteilungen, die zu überprüfen und in alle Planungsansätze einzuarbei-ten sind.• Unternehmenspolitische Vorgaben: Sie definieren die Grenzen, die bei den Entscheidungen beachtet werden müssen. Sie können durch Regelungen, Verträge, Vereinbarungen, Abmachungen, Gewährleistungen, Zertifizierun-gen oder andere rechtliche Verpflichtungen beschrieben werden.• Werkzeuge des Informationsmanagements: Jedes Unternehmen nutzt Werkzeuge, um Informationen der Business-Analyse zu speichern, abzurufen und gemeinsam zu verwenden. Diese können so einfach wie ein Whiteboard oder so komplex sein wie ein globales Wiki oder ein leis-tungsfähiges Werkzeug zum Management der Anforderungen.• Rechts- und Regelungsinformationen: Sie beschreiben gesetzliche Regelungen oder Vorschriften, die eingehalten werden müssen. Mit ihrer Hilfe kann geregelt werden, wie die Informationen der Business-Analyse verwaltet werden.

Techniken

• Brainstorming: Kann Stakeholdern helfen, ihren Bedarf zur Verwaltung der Informationen der Business-Analyse zu ermitteln.• Interviews: Werden genutzt, um bestimmten Stakeholdern zu helfen, ihren Bedarf zur Verwaltung der Informationen der Business-Analyse zu ermitteln.• Item Tracking: Wird verwendet, um offene Punkte im Prozess des aktuellen Informationsmanagements zu verfolgen.• Lessons Learned: Werden als Informationsquelle eingesetzt, um Ansätze für eine effiziente Verwaltung von Informationen der Business-Analyse zu analysieren.• Mind Mapping: Wird zur Identifizierung und Kategorisierung der zu verwaltenden Informationsarten verwendet.• Prozessmodellierung: Wird verwendet, um den Prozess oder die Methode der Verwaltung von Informationen der Business-Analyse zu dokumentieren.• Umfrage oder Fragebogen: Werden verwendet, um Input von Stake-holdern zum Management von Informationen der Business-Analyse einzuholen.• Workshops: Werden verwendet, um in Team-Meetings Anforderungen für die Verwaltung von Informationen der Business-Analyse zu identifi-zieren.



54

3.4.5

3.4.6

Stakeholder

• Fachexperte: Er muss möglicherweise auf Informationen der Business-Analyse zugreifen und mit ihnen arbeiten und ist an diesen Informationen eher aus seiner speziellen Fachgebietssicht interessiert.• Regulierer: Sie können Regeln und Prozesse für das Informations-Management festlegen.• Sponsor: Er bewertet, kommentiert und genehmigt Informationen der Business-Analyse.

Outputs

• Ansatz des Informationsmanagements: Zu ihm gehört der definierte Ansatz, wie Informationen der Business-Analyse gespeichert werden, wie darauf zuge-griffen wird und wie sie während des Change und nach Abschluss des Change verwendet werden.

Leistungsverbesserungen der Business-Analyse ermitteln

Zweck

Der Zweck von „Leistungsverbesserungen der Business-Analyse ermitteln“ ist,die Arbeit der Business-Analyse zu bewerten und, wenn erforderlich, Prozess-verbesserungen zu planen.

Beschreibung

Um die Leistung zu überwachen und zu verbessern, ist es notwendig, Kennzahlenfür die Performance festzulegen, die Leistungsanalyse durchzuführen, über dieErgebnisse der Analyse zu berichten und erforderliche vorbeugende oder korrigierendeMaßnahmen festzulegen. Leistungsanalysen sollten während des gesamten Vorhabensdurchgeführt werden. Sobald potentielle Leistungsverbesserungen festgestellt werden,werden sie zu Leitfäden für die nächste Durchführung einer Aufgabe.

Inputs

• Leistungsziele (extern): Sie beschreiben die gewünschten Leistungsergeb-nisse, die ein Unternehmen oder eine Organisation zu erreichen hofft.



55

3.4.7

3.4.8

3.5

3.5.1

3.5.2

3.5.3

• Ansatz der Business-Analyse: Mit ihm wird bestimmt, welche Ergebnisse durch die Arbeit der Business-Analyse bereitzustellen, welche Aktivitäten durchzuführen (einschließlich, wann sie durchgeführt werden und wer sie durchführt) und welche Techniken zu verwenden sind.

Abb. 3.5.1: Input-Output-Diagramm „Leistungsverbesserungen der Business-Analyse ermitteln“



56

Leistungsverbesserungen derBusiness-Analyse ermitteln

3.5

Output

3.5 Leistungs-

beurteilung derBusiness-Analyse



Analyse planen


managen

4.5

Input

Leistungsziele(extern)

Ansatz derBusiness-Analyse

3.1


Leistungs-Standardsdes Unternehmens


planen

3.1 Steuerung der


3.3Einbindung


3.2

Elemente

.1 Leistungsanalyse Eine effektive Business-Analyse hängt von dem Kontext ab, in dem sich ein bestimmtesUnternehmen oder ein Vorhaben befindet. Berichte über die Leistung der Business-Analyse können informell und verbal sein oder aus einer formalen Dokumentationbestehen. Berichte über die Leistung der Business-Analyse werden auf die Anforde-rungen unterschiedlicher Reviewer ausgerichtet.

.2 Maßstäbe der EvaluierungGibt es aktuelle Maßstäbe, kann der Business-Analyst sie nutzen oder neueMaßstäbe festlegen. Der Business-Analyst kann auch bei den StakeholdernMaßstäbe für die Evaluierung erheben.

Leistungsmessungen können auf den geplanten Terminen für die Fälligkeitender zu liefernden Leistungen basieren, auf Kennzahlen, wie z.B. Häufigkeit derVeränderungen von Ergebnissen der Business-Analyse, Zahl notwendiger Prüf-zyklen, Effizienz der Tätigkeiten oder auf qualitativem Feedback von Stakeholdernoder Kollegen zu den Leistungen des Business-Analysten. Geeignete Maßstäbefür die Leistung des Business-Analysten erleichtern es ihm, Probleme zu identifi-zieren, die seine eigene Leistung beeinträchtigen können, oder Chancen fürVerbesserungen zu erkennen. Die Maßstäbe können sowohl quantitative alsauch qualitative Aspekte beinhalten. Qualitative Maßstäbe sind subjektiv undhängen stark von den Einstellungen, Wahrnehmungen und anderen subjektivenKriterien der Stakeholder ab.

Einige mögliche Maßstäbe sind:• Genauigkeit und Vollständigkeit: Zeigen, ob der Business-Analyst korrekte und nützliche Ergebnisse geliefert hat, oder ob sie immer wieder überarbeitet werden mussten, um von den Stakeholdern akzeptiert zu werden.• Kenntnisse: Dienen der Einschätzung, ob der Business-Analyst die not-wendigen Fähigkeiten und Erfahrungen hat, um die zugewiesene Auf-gabe zu erfüllen.• Effektivität: Ist ein Maß dafür, ob die Ergebnisse des Business-Analysten einfach zu nutzen waren oder ob sie umfangreiche Erläuterung erforder-ten, um sie zu verstehen.• Organisatorische Unterstützung: Ist ein Maß dafür, ob passende Ressourcen verfügbar waren, um die Aktivitäten der Business-Analyse bedarfsgemäß fertigzustellen.• Signifikanz: Mit ihr wird der Nutzen bewertet, den die Ergebnisse bieten, und beurteilt, ob Kosten, Zeitbedarf und Aufwand für die Erstellung der Ergebnisse gerechtfertigt sind.



57

3.5.4

• Strategie: Mit ihr wird beurteilt, ob Unternehmensziele erreicht, Probleme gelöst und Verbesserungen erreicht wurden.• Rechtzeitigkeit: Mit ihr wird bewertet, ob die Arbeit des Business-Analysten pünktlich, gemäß den Erwartungen der Stakeholder und gemäß Zeitplan, geliefert wurde.

.3 Analyse der Ergebnisse Die Prozesse der Business-Analyse und die Leistungen werden mit den definiertenMaßstäben beurteilt. Die Analyse kann sich auf den Prozess der Business-Analyse,die beteiligten Ressourcen und die gelieferten Ergebnisse beziehen.

Die Leistung kann aus der Sicht der Empfänger der Arbeit der Business-Analysebeurteilt werden. Es kann auch ein Personalchef oder ein Kompetenzzentrumdiese Beurteilung durchführen und Einschätzungen abgeben. Alle Stakeholderkönnen sich an der Beurteilung beteiligen, das Unternehmen kann aber sehrunterschiedliche Ansichten darüber haben, wer die Befugnisse hat, die Maßstäbezu definieren, an denen die Leistung gemessen wird.

.4 Empfohlene Aktivitäten für Verbesserungen Sobald die Analyse der Leistungen abgeschlossen ist, bezieht der Business-Analyst die entsprechenden Stakeholder ein, um die folgenden Aktivitäten fest-zulegen:• Vorbeugende Aktivitäten: Sie reduzieren die Eintrittswahrscheinlichkeit eines Ereignisses, das negative Auswirkungen hat oder haben kann.• Korrigierende Aktivitäten: Durch sie werden Möglichkeiten geschaffen,negative Auswirkungen eines eingetretenen Ereignisses zu verringern.• Verbessernde Aktivitäten: Sie schaffen Möglichkeiten, die Eintritts-wahrscheinlichkeit oder die Auswirkungen von Ereignissen mit positi-ven Folgen zu erhöhen.

Diese Aktionen haben wahrscheinlich Änderungen am Ansatz der Business-Analyse, an Prozessen und an Werkzeugen zur Folge.


• Organisatorische Leistungs-Standards des Unternehmens: Sie können Leistungsmaßstäbe oder Erwartungen hinsichtlich der zu erbringenden Ergebnisse beinhalten, die vom Unternehmen gefordert werden.



58

3.5.5

Techniken

• Brainstorming: Wird verwendet, um Ideen für Verbesserungsmöglich-keiten zu generieren.• Interviews: Werden verwendet, um Beurteilungen der Performance/ Leistung der Business-Analyse zu sammeln.• Item Tracking: Wird verwendet, um Sachverhalte, die bei der Durchfüh-rung der Business-Analyse sichtbar werden, für eine spätere Bearbeitung im Auge zu behalten.• Lessons Learned: Werden verwendet, um vorgeschlagene Veränderungen der Prozesse der Business-Analyse, Leistungen, Vorlagen und andere Prozessbestandteile zu identifizieren, die im aktuellen und in künftigen Vorhaben genutzt werden können.• Kennzahlen und Key-Performance-Indikatoren (KPIs): Werden verwendet, um festzulegen, welche Kennzahlen zur Bewertung und Verfolgung der Performance der Business-Analyse geeignet sind.• Beobachtung: Wird verwendet, um die Performance der Business-Analyse zu ermitteln.• Prozessanalyse: Wird verwendet, um bestehende Prozesse der Business-Analyse zu analysieren und Verbesserungsmöglichkeiten zu ermitteln.• Prozessmodellierung: Wird verwendet, um Prozesse der Business-Analyse zu entwickeln und zu verstehen, wie diese Prozesse verbessert werden können, um Schnittstellenprobleme zu verringern, Durchlaufzeiten zu verbessern oder die Durchführung der Arbeit der Business-Analyse so zu verändern, dass nachgelagerte Prozesse verbessert werden (können).• Reviews: Werden verwendet, um veränderte Prozesse oder Ergebnisse der Business-Analyse zu ermitteln, die in die zukünftige Arbeit integriert werden können.• Risikoanalyse und -management: Wird verwendet, um potentielle Bedingungen oder Ereignisse zu identifizieren und zu bewältigen, die die Leistung der Business-Analyse negativ beeinflussen können.• Ursachenanalyse: Wird verwendet, um die tiefer liegenden Ursachen von Fehlern und Schwierigkeiten zu ermitteln.• Umfrage oder Fragebogen: Werden verwendet, um Feedback von Stake-holdern über ihre Zufriedenheit mit den Aktivitäten und Ergebnissen der Business-Analyse einzuholen.• Workshops: Werden verwendet, um Urteile über die Leistung der Business-Analyse zu sammeln und Ideen für Verbesserungsmöglichkeiten zu ent-wickeln.



59

3.5.6

Stakeholder

• Fachexperten: Sie sollten über die Aktivitäten der Business-Analyse informiert sein, um über deren Beteiligung an der Arbeit nachzudenken und deren Feedback über mögliche Verbesserungen des Ansatzes der Business-Analyse einzuholen.• Projektmanager: Er ist für den Erfolg eines Projektes verantwortlich und muss über den aktuellen Stand der Arbeit der Business-Analyse auf dem Laufenden gehalten werden. Werden potentielle Probleme oder Verbes-serungsmöglichkeiten festgestellt, ist der Projektmanager vor Durchfüh-rung von Veränderungen einzubinden, um zu beurteilen, ob diese Ände-rungen Einfluss auf das Projekt haben werden. Projektmanager können auch Berichte über die Performance der Business-Analyse an den Sponsor und andere Stakeholder liefern.• Sponsor: Der Sponsor kann Berichte über die Leistungen der Business-Analyse verlangen, wenn Probleme auftauchen, die angegangen werden müssen. Ein Manager der Business-Analysten kann auch Vorhaben spon-sern, um die Leistung der Business-Analyse zu verbessern.

Outputs

• Leistungsbeurteilung der Business-Analyse: Sie enthält einen Vergleich der geplanten mit der tatsächlichen Leistung, die Hauptursachen der Abweichungen von der erwarteten Leistung, Vorschläge zur Beseitigung der Probleme und andere Untersuchungsergebnisse, die helfen sollen, die Performance des Prozesses der Business-Analyse besser zu verstehen.



60

3.5.7

3.5.8

61

Das Wissensgebiet „Erhebung und Zusammenarbeit“ beschreibt die Aufgaben,die der Business-Analyst ausübt, um Informationen von Stakeholdern zu erhaltenund um die Ergebnisse zu bestätigen. Ebenso beschreibt es die Kommunikationmit Stakeholdern, sobald Informationen der Business-Analyse zusammengetragensind.

Erhebung ist das Ermitteln oder Empfangen von Informationen, sei es von Stake-holdern oder aus anderen Quellen. Die Erhebung ist das übliche Mittel, Anforde-rungen und Informationen zum Design zu entdecken. Sie schließt die direkte Kom-munikation mit Stakeholdern ebenso ein wie das Untersuchen von und das Experi-mentieren mit Sachverhalten sowie den Empfang von Informationen. Zusammen-arbeit ist eine Handlung, bei der zwei oder mehr Personen zusammen auf eingemeinsames Ziel hinarbeiten. Das Wissensgebiet „Erhebung und Zusammenarbeit“beschreibt, wie Business-Analysten alle Arten von Informationen der Business-Analyse identifizieren und sich auf diese Informationen einigen. „Erhebung undZusammenarbeit“ ist keine „Phase“ in der Business-Analyse; vielmehr dauert sieso lange, wie Tätigkeiten der Business-Analyse anfallen.

„Erhebung und Zusammenarbeit“ kann geplant, ungeplant oder beides sein.Geplante Aktivitäten, wie z.B. Workshops, Experimente und/oder Umfragen,können im Vorfeld strukturiert und organisiert werden. Ungeplante Aktivitätenfinden einfach statt, ohne dass dies besonders auffällt, z.B. Zusammenarbeitoder Besprechungen in „letzter Minute“ oder „just in time“. Informationen derBusiness-Analyse, die aus einer ungeplanten Aktivität stammen, müssen mögli-cherweise später noch genauer hinterfragt und weiterverfolgt werden.

Informationen der Business-Analyse zu erheben ist keine isolierte Aktivität. Infor-mationen werden bei jeder Aufgabe erhoben, die eine Interaktion mit Stakehol-dern beinhaltet und werden auch erhoben, während der Business-Analyst unab-hängig von Stakeholdern analytisch arbeitet. Eine Erhebung kann weitere, detail-lierte Erhebungen auslösen, um Lücken zu schließen oder um das Verständniszu vergrößern.

Erhebung und Zusammenarbeit4

Das Wissensgebiet „Erhebung und Zusammenarbeit“ setzt sich aus den folgendenAufgaben zusammen:

• Erhebung vorbereiten: Es ist sicherzustellen, dass die Stakeholder die benötigten Informationen bereitstellen können und dass sie verstehen,was im Rahmen der Erhebung von ihnen erwartet wird. Es sollen auch gemeinsame Erwartungen hinsichtlich der Ergebnisse dieser Aktivität aufgebaut werden. Zur Vorbereitung kann auch gehören, Recherchequellen zu identifizieren oder ein Experiment vorzubereiten, z.B. um zu prüfen, ob eine Prozessveränderung bereits zu einer Ver-besserung führt.

• Erhebung durchführen: Dazu gehören alle Tätigkeiten, um die Bedarfe der Stakeholder zu verstehen und mögliche Lösungen zu identifizieren,die diese Bedarfe decken. Dies kann mittels direkter Interaktion mit den Stakeholdern oder über Recherchen oder Experimente geschehen.

• Erhebungsergebnisse bestätigen: Mit dieser Aufgabe ist sicherzu-stellen, dass die Stakeholder die Erhebungsergebnisse alle gleich verstehen, dass Informationen der Erhebung korrekt aufgezeichnet wurden und dass der Business-Analyst die gewünschten Informationenerhalten hat. Zu dieser Aufgabe gehört zudem der Vergleich mit ande-ren Informationen, um Inkonsistenzen oder Lücken zu finden.

• Business-Analyse-Informationen kommunizieren: Die Stakeholder werden mit den benötigten Informationen dann versorgt, wenn sie erforderlich sind. Die Informationen werden dabei in einer nützlichen Form bereitgestellt, mit richtiger Terminologie und Konzepten.

• Zusammenarbeit mit Stakeholdern managen: Dazu gehören alle Aktivitäten mit den Stakeholdern, die dazu dienen, sie in den gesam-ten Prozess der Business-Analyse einzubeziehen und sicherzustellen, dass der Business-Analyst die benötigten Ergebnisse liefern kann.

Das Kernkonzept-Modell in der „Erhebung undZusammenarbeit“The Business Analysis Core Concept Model™ (BACCM™) beschreibt die Zusam-menhänge zwischen den sechs Kernkonzepten.

Die folgende Tabelle zeigt den Gebrauch und die Anwendung jedes Kernkonzeptsim Kontext von „Erhebung und Zusammenarbeit“.

Erhebung und Zusammenarbeit

62

Erhebung und ZusammenarbeitDas Kernkonzept-Modell in der „Erhebung und Zusammenarbeit“

Tabelle 4.0.1: Das Kernkonzept-Modell in der „Erhebung und Zusammenarbeit“

Erhebung und Zusammenarbeit Das Kernkonzept-Modell in der „Erhebung und Zusammenarbeit“

63

Kernkonzept Während „Erhebung und Zusammenarbeit“...


...nutzt der Business-Analyst verschiedene Erhe-bungstechniken, um die Eigenschaften einer Verän-derung, inklusive der Bedenken der Stakeholderhinsichtlich der Veränderung, vollständig zu identi-fizieren. Von der Veränderung selbst können diegeeigneten Formen und der Umfang der Erhebungund Zusammenarbeit abhängen.


...erhebt, bestätigt und kommuniziert der Business-Analyst Bedarfe und unterstützende Informationender Business-Analyse. Da Erhebungen iterativ undinkrementell erfolgen, kann sich das Verständnis fürden Bedarf unter Umständen erst im Zeitverlaufentwickeln.


...erhebt, bestätigt und kommuniziert der Business-Analyst notwendige oder gewünschteEigenschaften vorgeschlagener Lösungen.


...managt der Business-Analyst die Zusammenarbeitmit Stakeholdern, die an der Business-Analysebeteiligt sind. Alle Stakeholder können in unter-schiedlichen Rollen und zu unterschiedlichen Zeit-punkten an der Veränderung teilnehmen.

Nutzen: Der Wert, die Bedeutung oder dieZweckmäßigkeit eines Ergebnissesfür den Stakeholder in einembestimmten Kontext.

...arbeitet der Business-Analyst mit Stakeholdernzusammen, um den relativen Wert der durch dieErhebung bereitgestellten Informationen zu unter-suchen, und wendet verschiedene Techniken an,um diesen Wert zu bestätigen und zu kommuni-zieren.


...wendet der Business-Analyst verschiedene Erhebungstechniken an, um Informationen zu dem Kontext zu identifizieren, der die Veränderungbeeinflussen kann.

Abb. 4.0.1: Input-Output-Diagramm „Erhebung und Zusammenarbeit“

Erhebung und ZusammenarbeitDas Kernkonzept-Modell in der „Erhebung und Zusammenarbeit“

64

Aufgaben

Output

Input

BedarfeBusiness-Analyse-

InformationenAnsatz der

Einbindung derStakeholder

3.2

Leistungs-beurteilung der

Business-Analyse

3.5

Erhebungvorbereiten

4.1Erhebung

durchführen

4.2 Erhebungs-ergebnissebestätigen

4.3


kommunizieren


managen

4.5

Plan derErhebung

4.1 4.2 Erhebungs-ergebnisse(bestätigt)

4.3


(kommuniziert)

4.4

Stakeholder-Engagement

4.5

Erhebungs-ergebnisse

(unbestätigt)

Erhebung vorbereiten

Zweck

Der Zweck der Aufgabe „Erhebung vorbereiten“ ist es, den Umfang der Erhe-bungsaktivität zu verstehen, angemessene Techniken zu wählen und geeignetesunterstützendes Material und Ressourcen zu besorgen.

Beschreibung

Der Business-Analyst bereitet eine Erhebung vor, indem er die gewünschtenErgebnisse dieser Aktivität definiert, unter Berücksichtigung der einzubeziehendenStakeholder und der Ziele des Vorhabens. In diesem Zusammenhang

• wird festgelegt, welche Arbeitsergebnisse durch die Nutzung der Erhebungsergebnisse produziert werden sollen

• wird entschieden, welche Techniken am besten geeignet sind, diese Ergebnisse zu produzieren

• wird die Logistik für die Erhebung bereitgestellt• werden notwendige unterstützende Materialien identifiziert• wird ein Verständnis für die Umstände entwickelt, die die Zusammen-arbeit während der Erhebung fördern.

Inputs

• Bedarfe: Sie sind bei der Vorbereitung maßgeblich für den Umfang und den Zweck der Erhebungsaktivitäten. Die Erhebung kann dazu genutzt werden, um Bedarfe zu entdecken. Im Vorfeld bestehen immer schon gewisse Vorstellungen über die Art des Bedarfs, selbst wenn dieser noch nicht vollständig erhoben ist oder verstanden wird. Andernfalls würde ein Vorhaben gar nicht begonnen.

• Ansatz der Einbindung der Stakeholder: Werden die Vorstellungen der Stakeholder hinsichtlich Kommunikation und Zusammenarbeit verstan-den, ist es einfacher, geeignete und effektive Erhebungen zu planen und vorzubereiten.

Erhebung und Zusammenarbeit Erhebung vorbereiten

65

4.1

4.1.1

4.1.2

4.1.3

Abb. 4.1.1: Input-Output-Diagramm „Erhebung vorbereiten“

Elemente

.1 Den Umfang der Erhebung verstehenUm die Art der Informationen der Business-Analyse, die während der Erhebungermittelt werden sollen und die möglichen Techniken zu bestimmen, berücksichtigtder Business-Analyst

• den zu analysierenden Bereich• übergreifende kulturelle Einflüsse und Umgebungseinflüsse der Unternehmung

• den physischen Standort der Stakeholder• beteiligte Stakeholder und deren Gruppendynamik

Erhebung und ZusammenarbeitErhebung vorbereiten

66

Input

BedarfeAnsatz der

Einbindung der Stakeholder

3.2

Plan derErhebung

4.1

Erhebungdurchführen

4.2 Erhebungs-ergebnissebestätigen

4.3


Erhebung vorbereiten4.1

Output


Vorgehen in derBusiness-Analyse

Geschäftsziele

Vorhandene Business-Analyse-Informationen

Möglicher Wert

4.1.4

• erwartete Outputs, die in die Erhebungsaktivitäten einfließen• Fähigkeiten des Business-Analysten• andere Erhebungsaktivitäten, die geplant sind, um diese Aktivität zu ergänzen

• Strategie oder Lösungsansatz• Umfang der künftigen Lösung• mögliche Quellen für Informationen, die in die spezifische Erhebungs-aktivitäten einfließen können.

Versteht der Business-Analyst den Umfang der Erhebungsaktivität, kann er besserreagieren, wenn die Erhebung vom vorgesehenen Umfang abweicht. Es fälltdann auch leichter, festzustellen, ob Personen und Materialien nicht rechtzeitigzur Verfügung stehen und wann die Aktivität vollständig erledigt ist.

.2 Erhebungstechniken auswählenMeistens werden während einer Erhebung mehrere Techniken genutzt. Diebenutzten Techniken hängen von Kosten- und Zeitbeschränkungen ab, von denQuellen der Informationen und dem Zugang zu diesen, von der Kultur der Orga-nisation und von den gewünschten Ergebnissen. Der Business-Analyst kanndazu die Bedarfe der Stakeholder berücksichtigen, deren Verfügbarkeit und phy-sische Standorte (an einem Ort oder verstreut). Für eine erfolgreiche Erhebungist es sehr wichtig, die richtigen Techniken zu wählen und sicherzustellen, dassjede Technik richtig durchgeführt wird. Bei der Auswahl der Erhebungstechnikenberücksichtigt der Business-Analyst

• Techniken, die üblicherweise in ähnlichen Vorhaben genutzt werden• Techniken, die spezifisch auf die Situation passen• die benötigten Aufgaben, um jede Technik vorzubereiten, auszuführenund abzuschließen.

Da sich Situationen und (Gruppen-)Dynamiken ändern, kann es notwendig sein,dass der Business-Analyst die ursprüngliche Auswahl anpasst, indem er geeig-netere Techniken einbezieht. Ein tiefes Verständnis der verfügbaren Bandbreitean Techniken hilft, den sich verändernden Umständen zu begegnen.

.3 Organisation der Erhebung planenDie Organisation wird vor einer Erhebung geplant. Dazu gehören

• die Ziele der Aktivität• Beteiligte und deren Rollen• eingeplante Ressourcen, inklusive Personen, Räume und Werkzeuge• Standorte• Kommunikationskanäle


67

• Techniken • Sprachen, die die Stakeholder nutzen (mündlich oder schriftlich).

Zur Organisation kann auch eine Agenda gehören, wenn andere Stakeholderbeteiligt sind.

.4 Unterstützendes Material besorgenDer Business-Analyst identifiziert Informationsquellen, die benötigt werden, umeine Erhebung durchzuführen. Unter Umständen werden für die Erhebung großeMengen an Informationen benötigt, z.B. über Personen, Systeme, historische Daten,Materialien und Dokumente. Als Dokumente kommen bestehende Systembeschrei-bungen, Geschäftsregeln, organisatorische Vorgaben, Regularien und Beschrän-kungen in Frage. Unterstützende Materialien können auch Output der Analysesein, zum Beispiel Entwurfsversionen von Analysemodellen (siehe Kap. 7.1 „Anfor-derungen spezifizieren und modellieren“). Der Business-Analyst beschafft oder ent-wickelt die benötigten Materialien und Werkzeuge. Es kann auch notwendig sein,zusätzlich erst einmal experimentell Informationen zu erheben , wenn neue Werk-zeuge, Ausrüstung oder Techniken genutzt werden sollen.

.5 Stakeholder vorbereitenUnter Umständen wird es notwendig sein, dass der Business-Analyst den Stake-holdern erläutert, wie eine Erhebungstechnik funktioniert oder welche Informa-tionen benötigt werden. Es kann auch ratsam sein, die Erhebungstechnik nichtdirekt an der Erhebung beteiligten Stakeholdern zu erklären, um ihnen zu helfen,die Validität und Relevanz der erhobenen Informationen zu verstehen. Stakeholderkönnen während einer Erhebung lustlos oder herausfordernd sein, wenn sie denEindruck haben, dass diese nicht mit ihren individuellen Zielen übereinstimmt,wenn sie den Zweck nicht verstehen oder über das Vorgehen verwirrt sind. In derVorbereitung der Erhebung sollte der Business-Analyst sicherstellen, dass alle not-wendigen Stakeholder der geplanten Erhebung zustimmen.

Der Business-Analyst kann Stakeholder auch insofern vorbereiten, als er siebittet, sich unterstützendes Material vorab anzuschauen, um die Erhebung soeffektiv wie möglich zu gestalten. Wird eine Agenda im Vorfeld bereitgestellt,können die Stakeholder dabei unterstützt werden, gedanklich vorbereitet undmit den notwendigen Informationen zu der Erhebung zu kommen.

Recherchen oder Untersuchungen können vom Business-Analysten auch alleinedurchgeführt werden. Dann ist eine Vorbereitung der Stakeholder nicht notwendig.


• Vorgehen in der Business-Analyse: Damit wird die generelle Strategie fest-gelegt, wie eine Business-Analyse durchgeführt wird. Dazu gehören Aus-

Erhebung und ZusammenarbeitErhebung vorbereiten

68

4.1.5

sagen über die generelle Methode, Arten von Stakeholdern und wie diesebeteiligt werden sollten, eine Liste der Stakeholder, der zeitliche Ablauf der anfallenden Aufgaben, das erwartete Format und der Detaillierungs-grad der Erhebungsergebnisse sowie identifizierte Herausforderungen und Unsicherheiten.

• Geschäftsziele: Sie beschreiben die gewünschte Richtung, um den ange-strebten Sollzustand zu erreichen. Sie können genutzt werden, um Erhe-bungen zu planen und vorzubereiten und um unterstützende Materialien zu entwickeln.

• Vorhandene Business-Analyse-Informationen: Sie können zum besseren Verständnis der Ziele der Erhebung beitragen und die Vorbereitung der Erhebung unterstützen.

• Möglicher Wert: Er beschreibt den Wert, der durch den vorgeschlagenen Sollzustand erreicht werden soll und kann für die Gestaltung der Erhe-bung genutzt werden.

Techniken

• Brainstorming: Kann dazu genutzt werden, gemeinsam die Quellen für dieInformationen zu identifizieren und Einigkeit darüber zu erreichen, welcheQuellen konsultiert werden sollten und welche Erhebungstechniken vor-aussichtlich die effektivsten sind.

• Data Mining: Damit können Informationen oder Muster identifiziert werden, die noch näher untersucht werden müssen.

• Dokumentenanalyse: Mit Hilfe dieser Technik können mögliche Quellen für unterstützende Materialien identifiziert und untersucht werden.

• Schätzung: Wird genutzt, um die benötigte Zeit und den Aufwand für die Erhebung sowie damit verbundene Kosten zu schätzen.

• Interviews: Befragungen werden genutzt, um Bedenken hinsichtlich der geplanten Erhebung zu ermitteln und um autorisiert zu werden, einen bestimmten Weg einzuschlagen.

• Mind Mapping: Diese Technik wird genutzt, um gemeinsam und einver-nehmlich die Quellen für die Informationen der Business-Analyse heraus-zufinden und festzulegen, welche Quellen konsultiert werden sollten undwelche Erhebungstechniken voraussichtlich die effektivsten sind.

• Risikoanalyse und -management: Damit können Bedingungen oder Situationen identifiziert, untersucht und bewältigt werden, die die Erhe-bung unterbrechen oder die Qualität und Validität der Erhebungsergeb-nisse negativ beeinflussen können. Die Pläne für die Erhebung sollten angepasst werden, um die schwerwiegendsten Risiken zu vermeiden, zu transferieren oder abzuschwächen.


69

4.1.6

• Stakeholder-Listen, -Karten oder Personas: Werden genutzt, um festzu-legen, wer während der Vorbereitung der Erhebung konsultiert werden sollte, wer daran teilnehmen sollte und um die geeigneten Rollen für jeden Stakeholder festzulegen.

Stakeholder

• Fachexperte: Er liefert unterstützende Materialien und bietet Hilfe, welcheanderen Informationsquellen herangezogen werden sollten. Er kann auch bei Recherchen, Experimenten und moderierten Erhebungen helfen.

• Projektmanager: Er stellt sicher, dass die geeigneten Personen und Ressourcen zur Durchführung der Erhebung zur Verfügung stehen.

• Sponsor: Er trägt die Verantwortung und hat das Recht, eine geplante Erhebung zu genehmigen oder abzulehnen sowie spezifische Stakehol-der zu beteiligen und anzufordern.

Outputs

• Plan der Erhebung: Wird für jede Erhebungsaktivität genutzt. Er beinhal-tet die Vorgehensweise, den Umfang der Erhebung, die ausgewähltenTechniken und unterstützende Materialien.

Erhebung durchführen

Zweck

Der Zweck der Aufgabe „Erhebung durchführen“ ist, für die Veränderung rele-vante Informationen zu identifizieren, zu Tage zu fördern und auszuwerten.

Beschreibung

Es gibt drei gebräuchliche Arten von Erhebung:• Gemeinschaftlich: Es erfolgt eine direkte Interaktion mit Stakeholdern und die Erhebung beruht auf deren Erfahrungen, Expertisen und Urteilsvermögen.

• Recherche: Informationen werden aus Materialien oder Quellen systematisch gewonnen und ausgewertet, die den in der Veränderung eingebundenen Stakeholdern nicht direkt bekannt sind. Stakeholder können an der Recherche teilnehmen. Eine Recherche kann eine

Erhebung und ZusammenarbeitErhebung durchführen

70

4.1.7

4.1.8

4.2.1

4.2.2

4.2

Analyse historischer Daten beinhalten, um Trends oder vergangene Ergebnisse zu identifizieren.

• Experimente: Es werden Informationen identifiziert, die nur durch einen kontrollierten Test ermittelt werden können. Manche Informatio-nen können nicht durch Personen oder Dokumente zu Tage gefördert werden, weil sie unbekannt sind. Experimente können helfen, diese Art von Informationen zu entdecken. Zu den Experimenten gehören Beobachtungsstudien, Machbarkeitsstudien und Prototypen.

Um das gewünschte Ergebnis zu erzielen, können eine oder mehrere Erhebungs-techniken genutzt werden.

Stakeholder können in der Erhebung mitarbeiten, indem sie• an der Erhebung teilnehmen und interagieren• recherchieren, studieren und Feedback liefern zu Dokumenten, Systemen, Modellen und Schnittstellen.

Inputs

• Plan der Erhebung: Beinhaltet die geplanten Erhebungsaktivitäten und Techniken, die Vorgehensweise (z.B. Datum, Zeit, Standorte, Ressourcen, Agenda), den Umfang der Erhebung und die verfügbaren Quellen für Hintergrundinformationen.

Erhebung und Zusammenarbeit Erhebung durchführen

71

4.2.3

Abb. 4.2.1: Input-Output-Diagramm „Erhebung durchführen“

Elemente

.1 Erhebung lenkenEs ist hilfreich, die vorgeschlagene Darstellung der Informationen der Business-Analyse, die in der Planung definiert wurde, zu verstehen, so dass die Erhebungs-aktivitäten sich darauf konzentrieren, die vorgesehenen Informationen im gewünsch-ten Detaillierungsgrad zu produzieren. Dies gilt für jede Erhebungsaktivität währenddes Vorhabens und kann je Aktivität unterschiedlich sein. Um in die Richtung dergewünschten Ergebnisse zu lenken, berücksichtigt der Business-Analyst

• die Ziele und Agenda der Erhebung• den Umfang der Veränderung• welche Form des Outputs eine Aktivität erzeugen wird


72

Input

Erhebungs-ergebnissebestätigen

4.3

Aufgabe, die diesen Output verwendet

Erhebung durchführen4.2

Output




Vorgehen zur Beteiligung der Stakeholder

UnterstützendeMaterialien

Plan derErhebung

4.1

4.2 Erhebungs-ergebnisse

(unbestätigt)

4.2.4

• welche anderen Darstellungsformen diese Ergebnisse unterstützen werden

• wie sich der Output in bereits Bekanntes integriert• wer die Informationen liefert• wer die Informationen nutzen wird• wie die Informationen genutzt werden.

Während die meisten dieser Punkte bereits bei der Planung der Erhebung berück-sichtigt wurden (siehe Kap. 4.1 „Erhebung vorbereiten“), sind alle diese Punkteauch bei der Erhebung selbst wichtig, um sie voranzubringen und die Ziele zuerreichen. So können Stakeholder z.B. Sachverhalte diskutieren, die außerhalbdes Rahmens der Erhebung oder der Veränderung liegen. Dann muss der Busi-ness-Analyst dieses erkennen und entscheiden, wie es weitergehen soll. Entwedernimmt er diese Abweichung zur Kenntnis und lässt sie zu oder er lenkt dieBesprechung in eine andere Richtung.

Der Business-Analyst nutzt diese Informationen auch, um zu entscheiden, obgenügend erhoben wurde und die Erhebung beendet werden kann.

.2 Erhebungsergebnisse festhaltenErhebungen erfolgen häufig iterativ und laufen als eine ganze Serie von Durch-gängen – parallel oder nacheinander – abhängig vom Umfang der Erhebung(siehe Kap. 4.1 „Erhebung vorbereiten“). Wenn die Erhebung ungeplant ist,werden die Ergebnisse festgehalten und in die geplanten Ergebnisse integriert.

Durch die Dokumentation der Erhebungsergebnisse wird auch sichergestellt,dass die produzierten Informationen für spätere Bezugnahme und späterenGebrauch vorhanden sind.


• Vorgehen in der Business-Analyse: Von diesem Vorgehen hängt ab, wie die Erhebungsaktivitäten durchgeführt werden, da damit auch der Outputfestlegt wird.

• Vorhandene Business-Analyse-Informationen: Von den vorhandenen Informationen hängen die Fragen ab, die in der Erhebung gestellt werden, und das Vorgehen bei der Erhebung.

• Vorgehen zur Beteiligung der Stakeholder: Dieses Vorgehen liefert Ansätzezu einer effektiven Zusammenarbeit und zur Kommunikation.

• Unterstützende Materialien: Das sind alle Materialien zur Vorbereitung von Business-Analysten und Stakeholdern auf die Erhebung, wie auch jegliche Informationen, Werkzeuge oder Ausrüstung, die während der Erhebung genutzt werden.


73

4.2.5

Techniken

• Benchmarking und Marktanalysen: Benchmarking wird als Informations-quelle genutzt, indem ein spezifischer Prozess, ein System, Produkt, Service oder eine Struktur mit einem anderen externen Vergleichswert abgeglichen wird, z.B. einer vergleichbaren Organisation oder einem Wert in einer ande-ren Branche. Marktanalysen werden genutzt, um festzustellen, was Kundenwollen und was Wettbewerber liefern.

• Brainstorming und Mind Mapping: Dienen dazu, viele Ideen von einer Gruppe von Stakeholdern in einem kurzen Zeitraum zu generieren und diese Ideen zu organisieren und zu priorisieren.

• Analyse der Geschäftsregeln: Mit ihrer Hilfe werden Regeln identifiziert, die Entscheidungen in einer Organisation steuern und damit die organi-satorischen Abläufe definieren, einschränken oder ermöglichen.

• Gemeinschaftliche Spiele: Dienen dazu, ein besseres Verständnis eines Problems zu entwickeln oder kreative Lösungen zu fördern.

• Begriffsmodellierung: Mit ihrer Hilfe werden Schlüsselbegriffe und wich-tige Ideen identifiziert und die Beziehungen zwischen ihnen definiert.

• Data Mining: Wird genutzt, um relevante Informationen und Muster zu identifizieren.

• Datenmodellierung: Wird verwendet, um in der Erhebung Beziehungen zwischen Entitäten zu verstehen.

• Dokumentenanalyse: Dient zur Überprüfung bestehender Systeme, Ver-träge, Geschäftsvorgänge, Regelungen, Standards und Regularien.

• Fokusgruppe: Eignet sich, um Ideen und Einstellungen einer Gruppe zu identifizieren und zu verstehen.

• Schnittstellenanalyse: Hilft, die Interaktion und die Eigenschaften dieser Interaktion zu verstehen, die zwischen zwei Entitäten stattfindet, z.B. zwischen zwei Systemen, zwei Organisationen oder zwei Personen oder Rollen.

• Interviews: Dienen dazu, Stakeholder zu befragen, um deren Bedarfe aufzudecken, Probleme zu identifizieren oder Chancen zu entdecken.

• Beobachtung: Ist hilfreich, um zu erkennen, wie derzeit gearbeitet wird, möglicherweise auch an verschiedenen Standorten und unter unterschiedlichen Umständen.

• Prozessanalyse: Dient dazu, aktuelle Prozesse zu verstehen und Verbes-serungsmöglichkeiten in diesen Prozessen zu identifizieren.

• Prozessmodellierung: Wird genutzt, um Prozesse mit Stakeholdern zu erheben.


74

4.2.6

• Prototyping: Trägt dazu bei, die Bedarfe von Stakeholdern in einem iterativen Prozess zu ermitteln und zu validieren und ein Modell der Anforderungen oder des Designs zu entwickeln.

• Umfrage oder Fragebogen: Dienen dazu, Informationen von einer Perso-nengruppe in strukturierter Weise und in vergleichsweise kurzer Zeit zu erheben; dies schließt Informationen zu Kunden, Produkten, Arbeitsprak-tiken und Eigenschaften ein.

• Workshops: Sind nützlich, um Informationen durch eine Personengruppe, die von einem Moderator gesteuert wird, gemeinschaftlich zu erheben; dazu können Informationen zu Kunden, Produkten, Arbeitspraktiken und Eigenschaften gehören.

Stakeholder

• Kunden: Liefern wertvolle Informationen der Business-Analyse während der Erhebung.

• Fachexperten: Sind Experten auf unterschiedlichen Fachgebieten und können wichtige Informationen liefern. Häufig helfen sie dem Business-Analysten bei der Identifikation geeigneter Recherchequellen und können dazu beitragen, Recherchen, Experimente und moderierte Erhebungen zuarrangieren.

• Endanwender: Sind die Benutzer bestehender oder zukünftiger Lösungen und sollten an der Erhebung teilnehmen.

• Umsetzungsexperte: Designt und implementiert eine Lösung und liefert spezialisierte Expertise. Er kann an der Erhebung teilnehmen, indem er klärende Fragen stellt und Alternativen anbietet.

• Sponsor: Fällt die wichtigen Entscheidungen und stellt sicher, dass die benötigten Stakeholder in eine Erhebung eingebunden sind.

• Jeder Stakeholder: Kann relevantes Wissen oder Erfahrungen besit-zen, um an der Erhebung teilzunehmen.

Outputs

• Erhebungsergebnisse (unbestätigt): Sind Informationen, die in einem Format dokumentiert sind, das für die jeweilige Erhebung festgelegt wurde.


75

4.2.7

4.2.8

Erhebungsergebnisse bestätigen

Zweck

Der Zweck der Aufgabe „Erhebungsergebnisse bestätigen“ ist es, die währendder Erhebung gesammelten Informationen auf Richtigkeit und Konsistenz mitanderen Informationen zu überprüfen.

Beschreibung

Erhobene Informationen werden geprüft und bestätigt, um mögliche Problemezu erkennen und zu beseitigen, bevor Ressourcen für die Nutzung dieser Infor-mationen bereitgestellt werden. Diese Prüfung kann Fehler, Auslassungen, Kon-flikte und Mehrdeutigkeiten aufdecken.

Die Erhebungsergebnisse können mit ihrer Quelle und anderen Erhebungsergeb-nissen verglichen werden, um so die Konsistenz sicherzustellen. Es kann notwendigsein, gemeinsam mit den Stakeholdern zu überprüfen, ob deren Inputs korrekterfasst wurden und ob sie den Ergebnissen nicht-moderierter Erhebungen zustim-men. Falls eine Information nicht korrekt ist, ermittelt der Business-Analyst dierichtige Information; dies kann weitere Erhebungen nach sich ziehen. WerdenRessourcen für Aktivitäten der Business-Analyse auf der Grundlage unbestätigterErhebungsergebnisse eingesetzt, kann dies dazu führen, dass die Erwartungender Stakeholder nicht erfüllt werden. Falls die Ergebnisse inkonsistent sind, könnenweitere Erhebungen notwendig sein, um die Diskrepanzen aufzulösen.

Die Bestätigung der Erhebungsergebnisse ist eine weniger gründliche und wenigerformale Prüfung als die Prüfung während der Analyse.

Inputs

• Erhebungsergebnisse (unbestätigt): Erfasste Informationen in einem Format, das spezifisch für die jeweilige Erhebung ist.

Erhebung und ZusammenarbeitErhebungsergebnisse bestätigen

76

4.3.1

4.3

4.3.2

4.3.3

Abb. 4.3.1: Input-Output-Diagramm „Erhebungsergebnisse bestätigen“

Elemente

.1 Erhebungsergebnisse mit Informationsquellen vergleichenDie Aufgabe „Erhebung durchführen“ (Kap. 4.2) beschreibt Quellen, aus denensich Erhebungsergebnisse ableiten lassen, inklusive Dokumente und Wissen derStakeholder. Der Business-Analyst kann Folge-Meetings moderieren, in denendie Stakeholder die Erhebungsergebnisse korrigieren. Die Stakeholder könnenErhebungsergebnisse auch ohne fremde Hilfe bestätigen.

Erhebung und Zusammenarbeit Erhebungsergebnisse bestätigen

77

Input


6.1Risiken

bewerten

6.3


Erhebungsergebnisse bestätigen4.3

Output


Plan der Erhebung


Erhebungs-ergebnisse(bestätigt)

4.3


(unbestätigt)

4.3.4

.2 Erhebungsergebnisse mit anderen Erhebungsergebnissen vergleichenDer Business-Analyst vergleicht die gesammelten Ergebnisse, um zu bestätigen,dass die Informationen konsistent und präzise sind. Werden Abweichungen inden Ergebnissen festgestellt, versucht der Business-Analyst, die Ursachen inZusammenarbeit mit den Stakeholdern zu klären. Die Ergebnisse können auchmit historischen Daten verglichen werden, um aktuellere Erhebungsergebnissezu bestätigen.

Inkonsistenzen in Erhebungsergebnissen werden oft sichtbar, wenn der Busi-ness-Analyst Spezifikationen und Modelle entwickelt. Um die Zusammenarbeitzu fördern, können diese Modelle auch während einer Erhebung entwickeltwerden.


• Plan der Erhebung: Gibt Hinweise, welche alternativen Quellen und welche Erhebungsergebnisse verglichen werden sollen.

• Vorhandene Business-Analyse-Informationen: Können genutzt werden, um Erhebungsergebnisse zu bestätigen oder um zur weiteren Detaillierungzusätzliche Fragen zu entwickeln.

Techniken

• Dokumentenanalyse: Wird verwendet, um Erhebungsergebnisse gegenüberanderen Informationsquellen oder anderen Dokumenten zu bestätigen.

• Interviews: Dienen der Bestätigung der Informationen selbst und der korrekten Integration dieser Informationen.

• Reviews: Mit ihrer Hilfe kann die Zusammenstellung von Erhebungsergeb-nissen bestätigt werden. Diese Reviews können informell oder formell sein, abhängig von den Risiken, falsche, unnütze oder irrelevante Infor-mationen erhoben zu haben.

• Workshops: Sind mehr oder weniger formelle Reviews der vorläufigen Erhebungsergebnisse. Eine Agenda, Entwürfe und Testszenarien können bei der Durchsicht der Erhebungsergebnisse genutzt werden. Von den Beteiligten wird Feedback eingefordert und dokumentiert.

Stakeholder

• Fachexperten: Sind Personen mit fundiertem Wissen, Erfahrungen oder Expertise bezüglich der zu erhebenden Informationen, der angestrebten Veränderung oder der Lösung. Sie helfen bei der Bestätigung der Erhe-bungsergebnisse und können dazu beitragen, Auslassungen, Inkonsis-

Erhebung und ZusammenarbeitErhebungsergebnisse bestätigen

78

4.3.5

4.3.6

4.3.7

tenzen und Konflikte in den Erhebungsergebnissen zu identifizieren. Sie können auch bestätigen, dass relevante Informationen erhoben wurden.

• Jeder Stakeholder: Alle möglichen Stakeholder können hinzugezogen werden, um die Erhebungsergebnisse zu bestätigen.

Outputs

• Erhebungsergebnisse (bestätigt): Das integrierte und bestätigte Ergebnis der Erhebung, bei dem sich der Business-Analyst und andere Stakeholder einig sind, dass es die erfassten Informationen korrekt widergibt, dass es relevant und als Input für die weitere Arbeit nützlich ist.

Business-Analyse-Informationen kommunizieren

Zweck

Mit der Aufgabe „Business-Analyse-Informationen kommunizieren“ soll sicher-gestellt werden, dass alle Stakeholder ein gemeinsames Verständnis der erhobenenInformationen haben.

Beschreibung

Der Business-Analyst muss an die Stakeholder deren Bedürfnissen entsprechendeInformationen weitergeben, und das zur richtigen Zeit und in geeigneten For-maten. Dabei ist auch zu bedenken, dass die Informationen hinsichtlich Sprache,Tonfall und Stil zielgruppengerecht geäußert werden.

Informationen der Business-Analyse werden bidirektional und iterativ ausge-tauscht. Dabei müssen die Empfänger, der Inhalt, der Zweck, der Kontext unddie erwarteten Ergebnisse berücksichtigt werden. Mit der Aufgabe „Einbindungder Stakeholder planen“ (Kap. 3.2) werden die Kommunikationsbedürfnisseevaluiert und die zu sendenden Nachrichten geplant.

Informationen zu kommunizieren bedeutet nicht einfach, Informationen weg-zuschicken und dabei zu unterstellen, dass sie empfangen und verstandenwurden. Der Business-Analyst bindet Stakeholder mit ein, um sicherzustellen,dass diese die Informationen verstehen und ihnen auch zustimmen. Der Busi-ness-Analyst geht auf jeglichen Widerspruch ein. Die Art und Weise der Kom-munikation muss möglicherweise verändert werden, wenn die Stakeholder Infor-mationen nicht erhalten oder nicht wie beabsichtigt verstehen. Für ein und die-selbe Information können verschiedene Formen der Kommunikation notwendigsein.

Erhebung und Zusammenarbeit Business-Analyse-Informationen kommunizieren

79

4.3.8

4.4.2

4.4.1

4.4

Inputs

• Business-Analyse-Informationen: Dabei handelt es sich um jede Art von Informationen in jeglichem Detaillierungsgrad, die als Input oder Output der Business-Analyse genutzt wird. Informationen der Business-Analyse sind dann ein Input für diese Aufgabe, wenn sie an weitere Stakeholder kommuniziert werden müssen oder sollen.

• Ansatz der Einbindung der Stakeholder: In diesem Ansatz werden Grup-pen von Stakeholdern, deren Rollen und deren genereller Bedarf hinsicht-lich der Kommunikation von Informationen beschrieben.

Abb. 4.4.1: Input-Output-Diagramm „Business-Analyse-Informationen kommunizieren“

Elemente

.1 Ziele und Format der Kommunikation festlegenZusammenstellungen von Informationen der Business-Analyse können aus unter-schiedlichen Gründen vorbereitet werden, sie dienen zum Beispiel

• der Kommunikation von Anforderungen und Designs gegenüber Stakeholdern

• der frühen Einschätzung der Planung und Qualität• der Evaluation möglicher Alternativen

Erhebung und ZusammenarbeitBusiness-Analyse-Informationenkommunizieren

80

Input

Business-Analyse-Informationen kommunizieren

4.4

Output



Vorgehen desInformationsmanagements


(kommuniziert)

4.4



Stakeholder

3.2

4.4.3

4.4.4

• formalen Reviews und Genehmigungen• als Inputs zum Lösungsdesign• der Erfüllung vertraglicher und regulatorischer Verpflichtungen• der Verwaltung zur Weiterverwendung.

Die Zusammenstellung von Informationspaketen dient primär dazu, Informationenklar und in einem für die gewünschte Veränderung geeigneten Format zu über-mitteln. Der Business-Analyst stellt als Entscheidungshilfe dazu folgende Fragen:

• Welche Zielgruppe erhält die Zusammenstellung?• Was verstehen und welche Kommunikation benötigen die unter-schiedlichen Typen von Stakeholdern?

• Was ist der bevorzugte Kommunikations- oder Lernstil jedes Stakeholders?• Welche Informationen sind wichtig für die Kommunikation?• Sind die Präsentation, das Format der Zusammenstellung und die Informationen in der Zusammenstellung zielgruppengerecht?

• Wie unterstützt die Zusammenstellung andere Aktivitäten?• Sind regulatorische oder vertragliche Bedingungen einzuhalten?

Mögliche Formen der Zusammenstellung sind:• Formale Dokumentation: Basiert normalerweise auf einer internen Vorlage (Template) und kann Texte, Tabellen oder Diagramme enthal-ten. Sie bietet eine stabile, einfach zu nutzende, langfristige Aufzeich-nung der Informationen.

• Informelle Dokumentation: Dazu können jeweils situativ Texte, Dia-gramme oder Tabellen zusammengestellt werden, die aber nicht Bestandteil eines formalen Prozesses in der Organisation sind.

• Präsentationen: Liefern einen groben Überblick, der geeignet ist, die Ziele einer Veränderung, Funktionen einer Lösung oder Informationen zur Entscheidungsfindung verständlich zu machen.

Es sollte überlegt werden, welcher Weg der Beste ist, die Materialien zu kombi-nieren und zu präsentieren, um eine einheitliche und effektive Nachricht aneine oder mehrere Gruppen von Stakeholdern zu übermitteln. Zusammenstel-lungen können in verschiedenen Online- oder Offline-Verzeichnissen aufbewahrtwerden einschließlich der Dokumente oder IT-Tools.

.2 Zusammenstellung der Business-Analyse kommunizierenDie Kommunikation der Zusammenstellung einer Business-Analyse dient dazu,Stakeholder in einem geeigneten Detaillierungsgrad über die Veränderung sozu informieren, dass sie die gelieferten Inhalte auch verstehen können. Stake-holdern wird damit die Möglichkeit geboten, die Zusammenstellung zu prüfen,Fragen zu den Informationen zu stellen und etwaige Bedenken zu äußern.

Erhebung und Zusammenarbeit Business-Analyse-Informationenkommunizieren

81

Dazu ist es auch wichtig, eine geeignete Informationsplattform zu wählen.Gebräuchliche Kommunikationsplattformen sind:

• Zusammenarbeit in Gruppen: Damit kann die Zusammenstellung zeit-gleich einer Gruppe relevanter Stakeholder bekannt gegeben werden. So wird es auch möglich, die Informationen und damit verbundene Anliegen unmittelbar zu erörtern.

• Individuelle Zusammenarbeit: Auf diesem Weg wird die Zusammen-stellung einzelnen Stakeholdern vorgestellt. Sie erleichtert das indivi-duelle Verständnis der Information, wenn eine Gruppenkonstellation nicht möglich oder weniger wirkungsvoll ist und damit nicht zu den besten Ergebnissen führen dürfte.

• E-Mail oder andere Methoden: So kann die Zusammenstellung kommuniziert werden, wenn die Informationen einen derart hohen Reifegrad besitzen, so dass nur wenige oder gar keine näheren Erläu-terungen benötigt werden.


• Vorgehen in der Business-Analyse: Hier wird beschrieben, wie die verschie-denen Informationsarten verteilt werden – und weniger was verteilt wird. Dazu gehören der erforderliche Detaillierungs- und Formalisierungsgrad, die Häufigkeit der Kommunikation und die Abhängigkeit der Kommunikation von der Anzahl und der geographischen Verteilung der Stakeholder.

• Vorgehen des Informationsmanagements: Damit wird festgelegt, wie Informationen der Business-Analyse zusammengestellt und an die Stake-holder kommuniziert werden.

Techniken

• Interviews: Dienen dazu, Informationen individuell an Stakeholder zu übermitteln.

• Reviews: Bieten Stakeholdern eine Gelegenheit, Feedback zu geben, not-wendige Anpassungen zu beantragen, erforderliche Antworten und Aktio-nen zu verstehen und ihnen zuzustimmen oder sie zu genehmigen. Reviews können in der Gruppenarbeit oder bei der bilateralen Zusammenarbeit eingesetzt werden.

• Workshops: In ihnen wird Stakeholdern eine Gelegenheit geboten, Feedback zu geben und erforderliche Anpassungen, Antworten und Aktionen zu verstehen. Workshops helfen auch, Konsens zu erreichen und Genehmigungen zu erteilen. Sie werden normalerweise in der Gruppenarbeit eingesetzt.

Erhebung und ZusammenarbeitBusiness-Analyse-Informationenkommunizieren

82

4.4.5

4.4.6

Stakeholder

• Endanwender: Für sie ist eine häufige Kommunikation erforderlich, so dass sie die relevanten Informationen der Business-Analyse kennen.

• Kunden: Das eben genannte gilt auch für die Kunden.• Fachexperte: Sollte die Informationen der Business-Analyse verstehen, umsie während des Veränderungsvorhabens zu bestätigen und zu validieren.

• Umsetzungsexperte: Sollte die Informationen der Business-Analyse kennen und verstehen, insbesondere Anforderungen und Designs, um sie umsetzen zu können.

• Tester: Sollte die Informationen der Business-Analyse kennen und verste-hen, insbesondere Anforderungen und Designs, um sie testen zu können.

• Jeder Stakeholder: Nahezu alle Stakeholder haben wahrscheinlich zumin-dest einmal während eines Veränderungsvorhabens Kommunikationsbedarf.

Outputs

• Business-Analyse-Informationen (kommuniziert): Informationen der Business-Analyse können als kommuniziert betrachtet werden, wenn die angesprochenen Stakeholder ihren Inhalt und die Auswirkungen verstan-den haben.

Zusammenarbeit mit Stakeholdern managen

Zweck

Der Zweck der Aufgabe „Zusammenarbeit mit Stakeholdern managen“ ist es,Stakeholder zu ermutigen, auf ein gemeinsames Ziel hinzuarbeiten.

Beschreibung

In der Business-Analyse gibt es viele Gelegenheiten, Ergebnisse gemeinsam mitStakeholdern zu erstellen. Stakeholder haben einen unterschiedlichen Einflussund unterschiedliche Befugnisse zur Genehmigung von Arbeitsergebnissen. Siesind eine wichtige Quelle bei der Ermittlung von Bedarfen, Einschränkungenund Annahmen. Im Verlauf der Business-Analyse identifiziert der Business-Analystdie Stakeholder, bestätigt ihre Rollen und kommuniziert mit ihnen, um sicherzu-stellen, dass die richtigen Stakeholder zur richtigen Zeit und in geeigneten Rollenteilnehmen.

Erhebung und Zusammenarbeit Zusammenarbeit mit Stakeholdern managen

83

4.4.7

4.4.8

4.5.1

4.5.2

4.5

Es ist eine fortlaufende Aktivität, die Zusammenarbeit mit Stakeholdern zu mana-gen. Auch wenn das Management die Zusammenarbeit mit Stakeholdern zudem Zeitpunkt beginnt, an dem Stakeholder identifiziert und analysiert wurden,können während der Initiative jederzeit neue Stakeholder identifiziert werden.Werden neue Stakeholder identifiziert, gilt es, deren Rolle, Einfluss und Beziehungzu dem Vorhaben zu analysieren. Rolle, Verantwortlichkeit, Einfluss, Einstellungund Autorität jedes Stakeholders können sich im Zeitverlauf ändern.

Je größer der Einfluss oder die Sichtbarkeit der Veränderung in der Organisationist, desto sorgfältiger muss die Zusammenarbeit mit den Stakeholdern gemanagtwerden. Der Business-Analyst managt die Zusammenarbeit mit Stakeholdern,um von positiven Reaktionen zu profitieren und um negative Reaktionen abzu-mildern oder zu verhindern. Der Business-Analyst sollte die Einstellung jedesStakeholders fortlaufend beobachten und bewerten, um festzustellen, ob sichAuswirkungen auf ihre Beteiligung in der Business-Analyse ergeben könnten.

Schlechte Beziehungen zu Stakeholdern können viele nachteilige Effekte aufdie Business-Analyse zur Folge haben, insbesondere

• das Ausbleiben von qualitativ guten Informationen• starke negative Reaktionen auf Verzögerungen und Hindernisse• Widerstand hinsichtlich der Veränderung• mangelnde Unterstützung für die und Beteiligung an der Business-Analyse

• mangelnde Beachtung von Informationen der Business-Analyse.

Diese Effekte können durch starke, positive und vertrauensvolle Beziehungenzu Stakeholdern zumindest abgemildert werden. Der Business-Analyst managtaktiv die Beziehungen zu Stakeholdern, die

• den Business-Analyst unterstützen, z.B. durch Inputs zu Aufgaben der Business-Analyse und zu anderen unterstützenden Aktivitäten

• durch den Business-Analyst unterstützt werden, z.B. durch Outputs derAufgaben der Business-Analyse

• an der Durchführung von Aufgaben der Business-Analyse beteiligt sind.

Inputs

• Ansatz der Einbindung der Stakeholder: Das Vorgehen beschreibt die Formen der voraussichtlichen Zusammenarbeit mit den Stakeholdern und wie diese vermutlich zu managen sind.

• Leistungsbeurteilung der Business-Analyse: Sie liefert wichtige Informatio-nen zur Effektivität der durchgeführten Aufgaben der Business-Analyse, einschließlich der Aufgaben, die auf das Engagement der Stakeholder fokussieren.

Erhebung und ZusammenarbeitZusammenarbeit mit Stakeholdern managen

84

4.5.3

Abb. 4.5.1: Input-Output-Diagramm „Zusammenarbeit mit Stakeholdern managen“

Elemente

.1 Bekenntnis zu Verpflichtungen erreichenStakeholder nehmen an Aktivitäten der Business-Analyse teil. Sie gehen dazuVerpflichtungen ein, die Zeit und Ressourcen erfordern. Der Business-Analystund die Stakeholder ermitteln diese Verpflichtungen und vereinbaren sie so frühwie möglich. Die Details dieser Verpflichtungen können formell oder informellkommuniziert werden, solange auf beiden Seiten Klarheit über Erwartungenund gewünschte Ergebnisse besteht.

Möglicherweise werden die Bedingungen und Konditionen gemeinsam erörtertund ausgehandelt. Eine effektive Verhandlungsführung, ausgeprägte Fähigkeitenin der Kommunikation und Konfliktlösung sind für ein effektives Stakeholder-Management wichtig (siehe „Verhandlung und Konfliktlösung“, Kap. 9.5.4).


85

Input

Output



Geschäftsziele

Beschreibung desSoll-Zustands

Empfohlene Aktionen

Ergebnisse derRisikoanalyse


Stakeholder

3.2Leistungs-

beurteilung derBusiness-Analyse

3.5

Stakeholder-Engagement

4.5

Zusammenarbeit mitStakeholdern managen

4.5

4.5.4

.2 Stakeholder Engagement verfolgen Der Business-Analyst beobachtet laufend die Beteiligung und die Leistung derStakeholder, um sicherzustellen, dass

• die richtigen Fachexperten und andere Stakeholder effektiv teilnehmen• Einstellungen und Interessen der Stakeholder gleich bleiben oder sich verbessern

• Erhebungsergebnisse rechtzeitig bestätigt werden• Zustimmungen weiter bestehen und Verpflichtungen eingehalten werden.

Der Business-Analyst beobachtet kontinuierlich Risiken wie z.B.:• Stakeholder werden durch andere Aufgaben abgelenkt• Erhebungsaktivitäten liefern nicht die Qualität, die für die Informatio-nen der Business-Analyse notwendig sind

• Genehmigungen verzögern sich.

.3 ZusammenarbeitStakeholder werden Veränderungen eher unterstützen, wenn der Business-Analyst mit ihnen zusammenarbeitet und Informationen, Ideen und Innovationenungehindert fließen können. Echtes Stakeholder-Engagement bedeutet, dassalle beteiligten Stakeholder den Eindruck haben, dass sie gehört werden, dassihre Meinungen zählen und ihre Beiträge anerkannt werden. Zu einer Zusam-menarbeit gehört eine regelmäßige, häufige und bidirektionale Kommunikation.Beziehungen, die auf Zusammenarbeit beruhen, tragen dazu dabei, einen unge-hinderten Informationsfluss aufrechtzuerhalten, auch wenn es Hindernisse undVerzögerungen gibt, und sie unterstützen den gemeinsamen Versuch, Problemezu lösen und gewünschte Ergebnisse zu erzielen.


• Vorgehen in der Business-Analyse: Das Vorgehen beschreibt die Art und den Grad der erforderlichen Zusammenarbeit mit jeder Gruppe von Stakeholdern, die dazu beiträgt, die geplanten Aktivitäten der Business-Analyse durchzuführen.

• Geschäftsziele: Sie geben die Orientierung für den Weg zum Soll-Zustand.Sie können helfen, mehrere Stakeholder auf eine gemeinsame Vision der gewünschten Geschäftsergebnisse zu fokussieren.

• Beschreibung des Soll-Zustands: Sie definiert den gewünschten Soll-Zustand und den erwarteten Wert, den dieser liefert; dies kann dazu beitragen, dass diverse Stakeholder ein gemeinsames Ziel anpeilen.

Erhebung und ZusammenarbeitZusammenarbeit mit Stakeholdern managen

86

4.5.5

• Empfohlene Aktionen: Die Information darüber, was getan werden sollte, um den Wert einer Lösung zu verbessern, kann Personen zur Unterstüt-zung anregen und Stakeholder dazu bringen, sich auf ein gemeinsames Ziel fokussieren.

• Ergebnisse der Risikoanalyse: Auf Risiken, die von Stakeholdern ausgehen,sollte eingegangen werden, um eine erfolgreiche Zusammenarbeit mit den Stakeholdern sicherzustellen.

Techniken

• Gemeinschaftliche Spiele: Dienen dazu, die Zusammenarbeit in einer Gruppe zu stimulieren, indem die Beteiligten in sichere und lustige Situa-tionen versetzt werden, in denen sie ihr Wissen und ihre Erfahrungen zu einem bestimmten Thema teilen, versteckte Annahmen identifizieren und dieses Wissen in einer Art und Weise erforschen können, die bei norma-len Interaktionen wahrscheinlich nicht stattfindet.

• Lessons Learned: Tragen dazu bei, die Zufriedenheit oder Unzufriedenheitder Stakeholder zu verstehen, und bieten eine Chance, die Zusammen-arbeit zu verbessern.

• Risikoanalyse und -management: Diese Technik hilft, solche Risiken zu identifizieren und zu managen, die mit der Einbindung, Beteiligung und dem Engagement der Stakeholder verbunden sind.

• Stakeholder-Listen, -Karten oder Personas: In diesen Dokumenten wird festgehalten, wer in der Business-Analyse mitarbeitet, welche informellen Beziehungen zwischen den Stakeholdern bestehen und welche Stake-holder zu den benötigten Informationen der Business-Analyse befragt werden sollten.

Stakeholder

• Alle Stakeholder: Alle Arten von Stakeholdern, die möglicherweise in den Veränderungsprozess eingebunden sind.

Outputs

• Stakeholder-Engagement: Die Bereitschaft der Stakeholder, sich bei Aktivi-täten der Business-Analyse zu engagieren und mit dem Business-Analysten bei Bedarf zu interagieren.


87

4.5.6

4.5.8

4.5.7

89

Das Wissensgebiet „Management des Anforderungs-Lebenszyklus“ (RequirementsLife Cycle Management) beschreibt die Aufgaben des Business-Analysten, diedazu dienen, Anforderungen zu organisieren und zu pflegen sowie Informationenvon der Ermittlung bis zur Löschung zu gestalten. Diese Aufgaben umfassen dieVerbindung von Anforderungen und Modellen, die Einschätzung, welche Wir-kungen auf Anforderungen oder Designs zu erwarten sind, sobald Veränderungenvorgeschlagen werden, wie auch die Analyse von Veränderungen und geeigneterMaßnahmen, die dazu dienen, die Zustimmung aller Beteiligten zu gewinnen.

Mit dem Management des Anforderungs-Lebenszyklus soll sichergestellt werden,dass Unternehmens-, Stakeholder- und Lösungsanforderungen sowie Designsaufeinander abgestimmt sind und durch die gefundene Lösung auch erfüllt wer-den. Hierbei wird kontrolliert, welche Anforderungen in der eigentlichen, zuerstellenden Lösung erfüllt werden. Des Weiteren unterstützt das Managementdes Anforderungs-Lebenszyklus die zukünftige Wiederverwendung von Infor-mationen.

Der Anforderungs-Lebenszyklus• startet mit der Abbildung eines betrieblichen Bedarfs als Anforderung• begleitet die Entwicklung einer Lösung• endet, wenn eine Lösung und deren Anforderungen gelöscht werden.

Das Anforderungsmanagement endet nicht mit der Implementierung einerLösung. Wenn die Anforderungen sachgemäß gepflegt werden, liefern sie einenMehrwert über den gesamten Lebenszyklus der Lösung.

Das Wissensgebiet „Management des Anforderungs-Lebenszyklus“ ist unab-hängig von einer konkreten Methode oder einem bestimmten Prozess zur Steue-rung der Aufgaben des Business-Analysten. Der hier beschriebene Lebenszyklusbezieht sich auf verschiedene Phasen und Status, die eine Anforderung als Teiljeglicher Veränderung durchlaufen kann. Anforderungen können durchausgleichzeitig mehrere Status haben.

5 Management des Anforderungs-Lebenszyklus

Abb. 5.0.1: Management des Anforderungs-Lebenszyklus

Das Wissensgebiet „Management des Anforderungs-Lebenszyklus“ enthält diefolgenden Aufgaben:

• Anforderungen rückverfolgen: Dazu gehören die Analyse und Pflege der Verbindungen zwischen Anforderungen, Designs, Lösungskompo-nenten und anderen Arbeitsergebnissen, um Wirkung, Abdeckung und Zuordnung zu ermitteln.

• Anforderungen pflegen: Damit wird sichergestellt, dass Anforderun-gen und Designs während des gesamten Anforderungs-Lebenszyklus korrekt bleiben, aktualisiert werden und bei Bedarf wieder verwendet werden können.

• Anforderungen priorisieren: Damit werden der Nutzen, die Dring-lichkeit und mögliche Risiken bewertet, die sich bei bestimmten Anforderungen und Designs ergeben, um sicherzustellen, dass die zum jeweiligen Zeitpunkt wichtigsten Anforderungen untersucht und umgesetzt werden.

• Änderungen von Anforderungen beurteilen: Neue und sich ändernde Anforderungen der Stakeholder werden bewertet, um zu bestimmen, ob sie im Rahmen eines Änderungsvorhabens umgesetzt werden müssen.

• Anforderungen genehmigen: Mit den im Genehmigungsprozess involvierten Stakeholdern wird zusammengearbeitet, um deren Genehmigung und Einverständnis bezüglich der Anforderungen und der Designs zu erreichen.


90

JaBeurteilen

Nein

Zustimmung/Einigung

Managen

• Verknüpfen• Pflegen• Priorisieren

Ja

Nein

Weiter bearbeiten

PotentielleAnforderung

Das Kernkonzept-Modell im „Management des Anforderungs-Lebenszyklus“Das Kernkonzept-Modell der Business-Analyse (BACCMTM) beschreibt die Ver-bindungen zwischen den sechs Kernkonzepten.

Die nachfolgende Tabelle zeigt, wie jedes Kernkonzept im Zusammenhang mitdem Management des Anforderungs-Lebenszyklus genutzt und angewendetwird.

Tabelle 5.0.1: Das Kernkonzept-Modell im „Management des Anforderungs-Lebenszyklus“


Das Kernkonzept-Modell im „Manage-ment des Anforderungs-Lebenszyklus“

91

Kernkonzept Im Management des Anforderungs-Lebenszyklus ist esAufgabe des Business-Analysten,...


... zu regeln, wie vorgeschlagene Anforderungenoder Designs in einem Veränderungsvorhabenbeurteilt werden.


... die Anforderungen nachzuvollziehen, zu priorisieren und zu pflegen, mit dem Ziel, dass der Bedarf erfüllt wird.


... die Verbindung von Anforderungen und Designszu den Lösungskomponenten zu überprüfen, umsicherzustellen, dass die Lösung den eigentlichenBedarf erfüllt.


... eng mit den zentralen Stakeholdern zusammen-zuarbeiten, um sicherzustellen, dass Anforderun-gen und Designs gleich verstanden, unterstützt undgenehmigt werden.

Nutzen: Der Wert, die Bedeutung oder dieZweckmäßigkeit eines Ergebnis-ses für den Stakeholder in einembestimmten Kontext.

... die Anforderungen zur Wiederverwendung zu pflegen und deren Nutzen über die aktuelle Initiative hinaus zu erweitern..


... den Kontext zu analysieren, um die Rückverfolg-barkeit und die Priorisierung zu unterstützen.

Abb. 5.0.2: Input-Output-Diagramm „Management des Anforderungs-Lebenszyklus“


Das Kernkonzept-Modell im „Manage-ment des Anforderungs-Lebenszyklus“

92

Aufgaben

Input

Anforderungen Designs VorgeschlageneÄnderungen

Anforderungen(verifiziert)

7.2

Anforderungenrückverfolgen

5.1Anforderungen

pflegen

5.2Anforderungenpriorisieren

5.3

Änderungen von Anforderungenbeurteilen

5.4


5.5

Anforderungen(rückverfolgt)

5.1

Designs(gepflegt)

5.2

5.4 BeurteilteÄnderungenvon Designs

Output

Designs(rückverfolgt)

5.1Anforderungen

(gepflegt)

5.2

Anforderungen(priorisiert)

5.3Designs

(priorisiert)

5.3

Anforderungen(genehmigt)

5.5

Designs(genehmigt)

5.5

5.4 Beurteilte


Anforderungen rückverfolgen

Zweck

Die Aufgabe „Anforderungen rückverfolgen“ soll sicherstellen, dass Anforde-rungen und Designs auf verschiedenen Ebenen aufeinander abgestimmt sindund dass die von den Anforderungen bewirkten Veränderungen beherrscht wer-den können.

Beschreibung

Die Rückverfolgung von Anforderungen identifiziert und dokumentiert die Ein-ordnung jeder Anforderung, sowohl in ihrer Entstehung (Blick zurück) wie auchim Hinblick auf ihre Auswirkungen (Blick voraus) sowie in ihren Beziehungen zuanderen Anforderungen. Die Rückverfolgbarkeit soll sicherstellen, dass die Lösungden Anforderungen entspricht und hilft dabei, den Scope, die Veränderung selbst,Risiko, Zeit, Kosten und Kommunikation zu managen. Außerdem werden mitihrer Hilfe fehlende Funktionalitäten erkannt oder vorhandene Funktionalitätenidentifiziert, denen keine Anforderungen gegenüberstehen.

Die Rückverfolgung ermöglicht• schnellere und einfachere Auswirkungsanalysen• die Ermittlung von Inkonsistenzen oder Diskrepanzen innerhalb von Anforderungen

• tiefe Einblicke in den Umfang und die Komplexität von Change-Vorhaben

• eine zuverlässige Beurteilung, welche Anforderungen bereits umge-setzt wurden und welche nicht.

Oft ist es schwer, akkurat Bedarfe und Lösungen darzustellen, ohne deren Verbin-dungen untereinander einzubeziehen. Während die Rückverfolgung an sich wert-haltig ist, muss der Business-Analyst abwägen, wie weit es sich lohnt, die ver-schiedenen möglichen Arten der Verbindungen darzustellen. Die Rückverfolgungunterstützt sowohl die Zuordnung von Anforderungen zu Releases als auch derenPlanung, indem die direkte Verbindung zwischen Anforderung und Bedarf dar-gestellt wird.

Die nachfolgenden Abbildungen zeigen Beispiele zur visuellen Darstellung derRückverfolgbarkeit für einen Prozess und für Software-Anforderungen.



93

5.1.1

5.1.2

5.1

Weitere Infor-mationen überdie Zuordnungfinden Sie imKapitel „Anfor-derungsarchi-tektur definie-ren“, Kap. 7.4

Abb. 5.1.1: Prozess-Rückverfolgung

Abb. 5.1.2: Software-Anforderungs-Rückverfolgung

Inputs

• Anforderungen: Sie können zu anderen Anforderungen (inklusive Unter-nehmenszielen, betrieblichen Zielen, betrieblichen Anforderungen, Stakeholder-Anforderungen, Lösungsanforderungen oder Überleitungs-anforderungen), Lösungskomponenten oder anderen Arbeitsergebnissen rückverfolgt werden.

• Designs: Sie können zu anderen Anforderungen, Lösungskomponenten oder anderen Arbeitsergebnissen rückverfolgt werden.



94

Wertschöpfungskette

Geschäftsprozess

Sub-Prozess

Aktivität

Aufgabe

Betrieblicher Bedarf


Stakeholder-Anforderungen

Lösungs-anforderungen

Design

Code

Test

5.1.3

Abb. 5.1.3: Input-Output-Diagramm „Anforderungen rückverfolgen“

Elemente

.1 FormalisierungsgradWenn Anforderungen rückverfolgt werden, muss der Business-Analyst den zuerwartenden Nutzen jeder Verbindung ebenso beachten wie das Wesen unddie Verwendung dieser speziellen Verbindung.

Der Aufwand der Anforderungsrückverfolgung steigt signifikant mit der Anzahlder Anforderungen und dem Grad der Formalisierung.

.2 BeziehungstypenEs gibt eine Vielzahl von Verbindungsarten, die vom Business-Analysten bei derFestlegung des Ansatzes der Rückverfolgung in Frage kommen:



95

Input

Anforderungen Designs


5.1

Design-Optionendefinieren

7.5


Anforderungen rückverfolgen5.1

Output


Bereichswissen

Informationsmanagement-Ansatz

Rechtliche/RegulatorischeInformationen

Anforderungsmanagement-Tools/Ablagen

Designs(rückverfolgt)

5.1

5.1.4

• Ableitung: Diese Beziehung zwischen zwei Anforderungen wird benutzt, wenn eine Anforderung von einer anderen abgeleitet wird. Dieser Bezie-hungstyp eignet sich, um Anforderungen auf verschiedenen Abstraktions-ebenen miteinander zu verbinden. Beispiel: Eine Lösungsanforderung wirdvon einer betrieblichen oder einer Stakeholder-Anforderung abgeleitet.

• Abhängigkeit: Diese Beziehung zwischen zwei Anforderungen wird benutzt, wenn eine Anforderung von der anderen abhängt. Dieser Beziehungstyp enthält zwei Unterformen:• Notwendig: Das ist der Fall, wenn die Umsetzung einer Anforderung nur dann sinnvoll ist, wenn die abhängige Anforderung ebenfalls umgesetzt wird.

• Aufwand: Dieser Fall ist gegeben, wenn eine Anforderung dadurch sehr viel leichter implementiert werden kann, dass eine andere Anforderung ebenfalls umgesetzt wird.

• Erfüllung: In dieser Beziehung erfüllt ein Element der Umsetzung eine An-forderung. Beispiel: Die Beziehung zwischen einer funktionalen Anforde-rung und einer Lösungskomponente, welche diese Anforderung umsetzt.

• Validierung: Das ist die Beziehung zwischen einer Anforderung und einem Testfall oder einem anderen Element, mit dem bestimmt werden kann, ob die Lösung die Anforderung erfüllen wird.

.3 Rückverfolgungs-RepositoryDie Rückverfolgung von Anforderungen wird anhand der festgelegten Methodendokumentiert und gepflegt. Ein Anforderungsmanagement-Tool kann signifikanteVorteile bringen, wenn eine große Anzahl an Anforderungen gepflegt und rück-verfolgt werden soll, sodass eine manuelle Verwaltung nicht mehr wirtschaftlicherscheint.


• Bereichswissen: Das für die Rückverfolgung erforderliche Wissen und die Expertise innerhalb eines Fachbereichs.

• Informationsmanagement-Ansatz: Er stellt Informationen über die Planungsaktivitäten zur Rückverfolgung bereit.

• Rechtliche/regulatorische Informationen: Hier werden die einzuhaltenden rechtlichen Vorgaben oder sonstigen Regelungen beschrieben. Sie müssen unter Umständen bereits bei der Definition der Regeln der Rück-verfolgung beachtet werden.

• Anforderungsmanagement-Tools/Ablagen: Sie werden zur Speicherung und Pflege von Informationen der Business-Analyse genutzt. Tools können so simpel wie ein Textdokument sein oder ein auf die Aufgaben des Anforderungsmanagements spezialisiertes System.



96

5.1.5

Techniken

• Analyse der Geschäftsregeln: Wird zur Rückverfolgung von Geschäfts-regeln zu Anforderungen genutzt, die diese Geschäftsregeln unterstützen, oder zur Rückverfolgung von Regeln, die Anforderungen unterstützen.

• Funktionale Gliederung: Wird genutzt, um den Scope der Lösung in kleinere Komponenten aufzugliedern, um damit Ressourcen besser zu ordnen oder um Grobkonzepte zu detaillierteren Konzepten rückverfol-gen zu können.

• Prozessmodellierung: Wird sowohl zur visuellen Darstellung eines zukünf-tigen Prozesses genutzt als auch dazu, die Beziehungen von Anforde-rungen zu zukünftigen Prozessen zu ermitteln.

• Scope-Modellierung: Dient sowohl zur visuellen Darstellung des Umfangs eines Vorhabens als auch der Analyse, welcher Bereich von den Anforder-ungen unterstützt wird.

Stakeholder

• Kunden: Sie sind davon betroffen, wie und wann Anforderungen um-gesetzt werden. Sie sollten über die Beziehungen der Anforderungen befragt werden, respektive sollte deren Zustimmung eingeholt werden.

• Fachexperten: Sie können Empfehlungen im Hinblick auf die Beziehung von Anforderungsgruppen zu Lösungskomponenten oder Releases geben.

• Endbenutzer: Sie können bestimmte zeitliche Beziehungen fordern, indem die Umsetzung von Anforderungen zu einem bestimmten Zeit-punkt oder in einer bestimmte Folge gefordert wird.

• Umsetzungsexperte: Die Rückverfolgung stellt sicher, dass die entwickelte Lösung den betrieblichen Bedarf erfüllt und richtet die Aufmerksamkeit auf die Abhängigkeiten zwischen den Lösungskomponenten während derImplementierung.

• Support: Die Rückverfolgung bietet eine weitere Dokumentationsquelle und dient dem Help Desk als Referenz.

• Projektmanager: Die Rückverfolgung hilft beim Management des Projekt-Scopes und der Veränderung.

• Sponsor: Er muss die verschieden Beziehungen genehmigen.• Lieferanten: Sie sind von der Art und dem Zeitpunkt der Implementierungder Anforderung betroffen.

• Tester: Sie müssen verstehen, wie und wo Anforderungen implementiert werden, um Testpläne und -fälle zu erstellen. Sie können Testfälle zu den Anforderungen rückverfolgen.



97

5.1.6

5.1.7

Outputs

• Anforderungen (rückverfolgt): Sie haben eine klar definierte Beziehung zuanderen Anforderungen, zu Lösungskomponenten oder Releases, zu Phasen und Iterationen innerhalb des Scopes der Lösung, sodass die Abdeckung und die Auswirkungen der Veränderung eindeutig erkannt werden können.

• Designs (rückverfolgt): Sie haben eine klar definierte Beziehung zu ande-ren Anforderungen, Lösungskomponenten oder Releases, zu Phasen und Iterationen innerhalb des Scopes der Lösung, sodass die Abdeckung und die Auswirkungen der Veränderung eindeutig erkannt werden können.

Anforderungen pflegen

Zweck

Der Zweck der Aufgabe „Anforderungen pflegen“ besteht darin, die Genauigkeitund Konsistenz von Anforderungen während des gesamten Lebenszyklus zuerhalten und die Anforderungen auch in anderen Lösungen wiederverwendenzu können.

Beschreibung

Eine Anforderung, die einen laufenden Bedarf repräsentiert, muss gepflegt wer-den, um über ihren gesamten Zeitverlauf gültig zu bleiben.

Um den maximalen Nutzen aus der Pflege und der Wiederverwendbarkeit vonAnforderungen zu gewährleisten, sollte eine Anforderung

• konsistent dargestellt• durch einen standardisierten Prozess, der den Zugriff regelt und die Qualität sichert, überprüft und genehmigt

• einfach zugänglich und verständlich sein.

Inputs

• Anforderungen: Sie enthalten Unternehmensziele, betriebliche Ziele, Stakeholder-Anforderungen, Lösungsanforderungen und Überleitungs-anforderungen. Die Anforderungen sollten über ihren gesamten Lebens-zyklus gepflegt werden.

• Designs: Falls notwendig, können sie über ihren vollständigen Lebens-zyklus gepflegt werden.



98

5.1.8

5.2

5.2.2

5.2.1

5.2.3

Abb. 5.2.1: Input-Output-Diagramm „Anforderungen pflegen“

Elemente

.1 Pflege der AnforderungenAnforderungen müssen gepflegt werden, sodass sie ihre Gültigkeit auch währendund nach einer genehmigten Veränderung behalten. Für die Pflege der Anfor-derungen und die Sicherstellung einer hohen Genauigkeit ist der Business-Analyst zuständig. Nur wenn Anforderungen klar definiert sind, einen eindeutigenNamen tragen und für Stakeholder einfach zugänglich sind, können sie ord-nungsgemäß gepflegt werden.

Ein Business-Analyst ist ebenfalls dafür zuständig, die Beziehungen zwischenAnforderungen, Anforderungsgruppen und weiteren verbundenen Informationender Business-Analyse zu pflegen und sicherzustellen, dass der Kontext und dieursprüngliche Vorstellung der Anforderung erhalten bleibt. Repositories mit all-gemein akzeptierten Taxonomien unterstützen die Entwicklung und Pflege vonVerbindungen zwischen den gepflegten Anforderungen und erleichtern dieRückverfolgung von Anforderungen und Designs.



99

Input


Anforderungen(gepflegt)

5.2

Anforderungen pflegen5.2

Output


Informationsmanagement-Ansatz

Designs(gepflegt)

5.2

5.2.4

.2 Pflege der AttributeBei der Erhebung von Anforderungen erhebt der Business-Analyst auch die Attri-bute der Anforderungen. Informationen, z.B. über die Quelle der Anforderung,über ihre Priorität oder Komplexität, erleichtern die Verwaltung einer Anforderungwährend ihres gesamten Lebenszyklus. Manche Attribute ändern sich, sobaldder Business-Analyst weitere Informationen erhält oder durch eine weitereAnalyse entdeckt. Ein Attribut kann sich ändern, obwohl sich die eigentlicheAnforderung nicht ändert.

.3 Wiederverwendung von AnforderungenEs gibt verschiedene Situationen, in denen Anforderungen erneut verwendetwerden können.

Anforderungen, die für eine langfristige Verwendung in Frage kommen, sindidentifiziert, tragen einen klaren Namen und sind so gespeichert, dass sie durchdie Stakeholder einfach gefunden werden können. Abhängig vom Abstrakti-onsgrad und dem zugedachten Bedarf können Anforderungen

• innerhalb des aktuellen Vorhabens• in ähnlichen Vorhaben• in ähnlichen Abteilungen• innerhalb der gesamten Organisation

wiederverwendet werden.

Eher abstrakt beschriebene Anforderungen können weitgehend losgelöst vonLösungen formuliert sein. Anforderungen, die eher allgemein, ohne direkte Ver-bindung zu einem bestimmten Tool oder zu einer Organisationstruktur dargestelltsind, lassen sich besser wiederverwenden. Diese Anforderungen müssen auchkaum einmal während eines Vorhabens geändert werden. Je detaillierter Anfor-derungen beschrieben werden, desto enger ist ihre Verbindung mit einer bestimm-ten Lösung oder Lösungsoption. Genaue Referenzen zu Applikationen oderAbteilungen begrenzen die Wiederverwendbarkeit von Anforderungen undDesigns innerhalb der gesamten Organisation.

Anforderungen, die wiederverwendet werden sollen, spiegeln den aktuellenStand der Organisation. Stakeholder validieren die erneute Nutzung vorhandenerAnforderungen, bevor sie für ein weiteres Vorhaben akzeptiert werden.


• Informationsmanagement-Ansatz: Er gibt Hinweise, wie Anforderungen verwaltet werden sollen, um sie wieder verwenden zu können.



100

5.2.5

Techniken

• Analyse der Geschäftsregeln: Dient dazu, Geschäftsregeln zu identifizie-ren, die innerhalb der gesamten Organisation gleichartig sind, mit dem Ziel, die erneute Nutzung zu erleichtern.

• Datenflussdiagramme: Dienen der Identifizierung von Informationsflüs-sen, die innerhalb der gesamten Organisation gleichartig sind, um sie gegebenenfalls wiederverwenden zu können.

• Datenmodellierung: Wird zur Identifizierung von Datenstrukturen genutzt,die innerhalb der gesamten Organisation gleichartig sind, um sie gegebe-nenfalls wiederverwenden zu können.

• Dokumentenanalyse: Dient der Analyse bestehender Dokumentationen, kann zur Pflege und Wiederverwendung von Anforderungen beitragen.

• Funktionale Gliederung: Mit ihrer Hilfe werden Anforderungen ermittelt, die es in Lösungskomponenten bereits gibt und die möglicherweise wiederverwendet werden können.

• Prozessmodellierung: Damit können Anforderungen aus bestehenden Prozessen erkannt werden, die sich eventuell wiederverwenden lassen.

• Use Cases und Szenarien: Mit ihnen lassen sich Lösungskomponenten erkennen, die eventuell von mehr als einer Lösung genutzt werden können.

• User Stories: Aus ihnen lassen sich Anforderungen erkennen, die in Ver-bindung mit einer User Story stehen und die eventuell wiederverwendet werden können.

Stakeholder

• Fachexperte: Er sieht sich regelmäßig gepflegte Anforderungen an, um sicherzustellen, dass diese den tatsächlichen Bedarf korrekt wiedergeben.

• Implementierungs-Fachexperte: Er nutzt gepflegte Anforderungen, um Regressionstests zu entwickeln und Wirkungsanalysen für etwaige Verän-derungen auszuführen.

• Support: Er zieht gepflegte Anforderungen hinzu, um den aktuellen Stand zu bestätigen.

• Regulator: Er berücksichtigt gepflegte Anforderungen, um zu bestätigen, dass regulatorische Vorgaben eingehalten werden.

• Tester: Gepflegte Anforderungen werden von Testern als Unterstützung bei der Erstellung von Testplänen und Testfällen genutzt.

Outputs

• Anforderungen (gepflegt): Einmalig definiert stehen diese Anforderungen bereit und können langfristig durch die Organisation verwendet werden.



101

5.2.6

5.2.7

5.2.8

Sie können Bestandteile betrieblicher Prozesse werden oder in zukünfti-gen Vorhaben verwendet werden. Anforderungen, die nicht genehmigt oder nicht implementiert wurden, können unter Umständen für zukünf-tige Initiativen gepflegt werden.

• Designs (gepflegt): Solche Designs können wiederverwendet werden, nachdem sie entwickelt wurden. Zum Beispiel kann eine eigenständige Komponente für eine zukünftige Verwendung bereitstehen.

Anforderungen priorisieren

Zweck

Der Zweck der Aufgabe „Anforderungen priorisieren“ besteht darin, die Anfor-derungen entsprechend ihrer relativen Wichtigkeit in eine Rangfolge zu bringen.

Beschreibung

Eine Priorisierung ist die Einordnung und Bestimmung der Rangfolge von Anfor-derungen gemäß der relativen Bedeutung für die Stakeholder. Mit der Priorisierungwird einer Anforderung eine höhere oder niedrigere Bedeutung beigemessen.Die Priorität kann den relativen Nutzen der Anforderung bedeuten oder die Rei-henfolge bestimmen, in der die Anforderungen umgesetzt werden sollen. Prio-risierung ist ein kontinuierlicher Prozess, da sich Prioritäten verändern können,etwa wenn sich der Kontext der Anforderungen verändert.

Abhängigkeiten zwischen den Anforderungen werden ermittelt und können diePriorisierung beeinflussen. Mit der Priorisierung soll sichergestellt werden, dassder maximale Nutzen erreicht wird.

Inputs

• Anforderungen: Das sind jegliche Anforderungen in Form von Text, Matrizen oder Diagrammen, die sich priorisieren lassen.

• Designs: Jegliche Designs in Form von Text, Prototypen oder Diagram-men lassen sich priorisieren.



102

5.3.1

5.3

5.3.2

5.3.3

Abb. 5.3.1: Input-Output-Diagramm „Anforderungen priorisieren“

Elemente

.1 Grundlagen der PriorisierungDie Grundlagen der Priorisierung von Anforderungen werden einvernehmlichmit den Stakeholdern vereinbart, so wie es im Wissensbereich „Planung undÜberwachung der Business-Analyse“ bestimmt wird.



103

Input



5.3

Risikenbewerten

6. 3


Anforderungen priorisieren5.3

Output


Designs(priorisiert)

5.3

Fachwissen

Entscheidungsansatz

Anforderungs-Architektur


Scope der Lösung

Geschäftliche Restriktionen

Veränderungsstrategie

5.3.4

Typische Einflussfaktoren auf die Priorisierung sind:• Nutzen: Nutzen sind alle Vorteile, die Stakeholder durch die Umsetzung einer Anforderung gewinnen, gemessen an den Unternehmens- und Bereichszielen des jeweiligen Änderungsvorhabens. Der Nutzen kann sich auf eine bestimmte Funktionalität, eine erwünschte Qualität, ein strategisches Ziel oder einen betrieblichen Zweck beziehen. Gibt es mehrere Gruppen von Stakeholdern, kann der Nutzen unterschiedlich wahrgenommen werden. Maßnahmen zur Konfliktlösung und Ver-handlungen können herangezogen werden, um einen Konsens bezüg-lich des Gesamtnutzens herzustellen.

• Strafe: Das können mögliche Konsequenzen sein, die entstehen, wenn eine bestimmte Anforderung nicht umgesetzt wird. So kann die Priori-sierung von Anforderungen anhand von regulatorischen oder politi-schen Forderungen unter Umständen Vorrang haben vor Stakeholder-Interessen. Eine „Strafe“ kann aber auch in den negativen Konsequen-zen gesehen werden, die sich ergeben, wenn eine Anforderung nicht umgesetzt wird, deren Erfüllung die Kunden erwarten.

• Kosten: Kosten und Ressourcen, die zur Implementierung einer Anfor-derung benötigt werden, können ebenfalls ein Maßstab sein. Informa-tionen über die Kosten werden typischerweise von den Implementie-rungs-Teams oder den Anbietern bereitgestellt. Kunden können ihre Priorität verändern, wenn sie die Kosten der Umsetzung erfahren haben.Die Kosten werden oft in ein Verhältnis zu anderen Kriterien gestellt, wie z.B. bei der Kosten-Nutzen-Analyse.

• Risiko: Risiko ist ein Maß für die Wahrscheinlichkeit, dass eine Anforde-rung einen geringeren Nutzen liefert oder die Erwartungen überhaupt nicht erfüllen kann. Das können Faktoren wie Schwierigkeiten bei der Umsetzung sein oder die Gefahr, dass die Stakeholder eine bestimmte Lösung nicht akzeptieren. Besteht ein Risiko, dass eine Lösung technisch nicht umsetzbar ist, wird der Anforderung mit dem höchsten Umset-zungsschwierigkeitsgrad die oberste Priorität zugewiesen, um den Res-sourcen-Einsatz zu minimieren, ehe zu spät festgestellt wird, dass die Gesamtlösung nicht realisiert werden kann. Die Prüfung der prinzipiellen Machbarkeit kann bei der Beurteilung helfen, ob Hoch-Risiko-Lösungen machbar sind.

• Inhaltliche Abhängigkeiten: Oft gibt es Verbindungen zwischen Anfor-derungen, bei denen eine Anforderung nicht erfüllt werden kann, solangedie abhängige Anforderung nicht ebenfalls erfüllt ist. Manchmal kann es sinnvoll sein, beide abhängigen Anforderungen gemeinsam zu implemen-tieren. Es kann auch Abhängigkeiten zu anderen Vorhaben oder Sachver-halten geben, z.B. zu Entscheidungen anderer Teams, Finanzierungszusa-gen oder der Verfügbarkeit begrenzter Ressourcen. Abhängigkeiten werden in der Aufgabe „Anforderungen rückverfolgen“ identifiziert.



104

• Zeitliche Abhängigkeiten: Die nicht-fristgerechte Erfüllung einer Anfor-derung kann zu einem signifikant geringeren Nutzen führen. Ein Bei-spiel sind Time-to-Market-Szenarien, in denen der realisierte Nutzen exponentiell steigt, wenn eine Funktionalität eher als von der Konkur-renz geliefert wird. Unter „Zeitliche Abhängigkeiten“ fallen aber auch saisonale Funktionalitäten, die nur zu bestimmten Jahreszeiten einen Wert haben.

• Stabilität: Das betrifft die Wahrscheinlichkeit, dass sich eine Anforde-rung ändert, entweder weil eine weitergehende Analyse benötigt wirdoder weil zwischen den Stakeholdern noch keine Einigung erzielt wurde. Ist eine Anforderung nicht stabil, kann sie eine niedrigere Priorität erhalten, um nicht vorhersehbare Korrekturarbeit und un-nötigen Aufwand zu vermeiden.

• Regulatorische Vorgaben oder Richtlinien: Anforderungen, die zur Erfüllung von regulatorischen Anforderungen an die Organisation oder aufgrund von Richtlinien erfüllt werden müssen, haben gegebenenfalls Vorrang vor den Interessen der Stakeholder.

.2 Herausforderungen bei der Priorisierung Priorisierung ist eine Beurteilung des relativen Nutzens. Jeder Stakeholder kannauf etwas Anderes Wert legen. In diesem Falle kann es zu Konflikten zwischenden Stakeholdern kommen. Stakeholder können Schwierigkeiten damit haben,auch nur eine ihrer Anforderungen mit einer niedrigeren Priorität zu versehen,was die notwendige Kompromissfähigkeit stark einschränken kann. Zusätzlichnutzen Stakeholder die Priorisierung, um (bewusst oder unbewusst) das Ergebnisin ihrem Interesse zu beeinflussen.

Für verschiedene Arten von Anforderungen sind nicht alle Kriterien gleichermaßenrelevant – daraus können Konflikte entstehen. Dies kann bei der PriorisierungKompromisse zwischen Stakeholdern erfordern.

.3 Fortwährende PriorisierungPrioritäten können sich durch Veränderungen im Kontext oder durch die Entdeckungneuer Informationen ändern. Zu Beginn findet die Priorisierung auf einem hohenAbstraktionslevel statt. Mit der weiteren Präzisierung der Anforderungen wird diePriorisierung auf detaillierterer Ebene fortgeführt. Dabei werden neue Einflussfak-toren zur Priorisierung berücksichtigt. Die Grundlagen der Priorisierung könnensich in verschiedenen Phasen eines Change-Prozesses ebenfalls wandeln. ZumBeispiel könnten die Stakeholder am Anfang eines Wandels nach dem Nutzenpriorisieren. Das Implementierungs-Team kann dann die Anforderungen anhandvon technischen Abhängigkeiten verändern. Nachdem das Implementierungs-Team die Kosten jeder Anforderung bestimmt hat, können die Stakeholder diePriorisierung verändern.



105


• Geschäftliche Restriktionen: Regulatorische Vorgaben, vertragliche Verein-barungen und geschäftliche Richtlinien können die Prioritäten bestimmen.

• Veränderungsstrategie: Sie enthält Informationen bezüglich Kosten, zeit-licher Vorgaben und Nutzenrealisierung, die zur Bestimmung der Priorität von Anforderungen herangezogen werden können.

• Fachwissen: Wissen und Expertise des Fachgebietes werden zur Unter-stützung der Priorisierung benötigt.

• Entscheidungsansatz: Beinhaltet das Vorgehen und die Befugnisse zur Priorisierung von Anforderungen.

• Anforderungs-Architektur: Sie wird dazu genutzt, die Abhängigkeiten zu anderen Anforderungen und zu Arbeitsergebnissen zu verstehen.

• Anforderungsmanagement-Tools/Ablagen: Wird ein Attribut für die Priorität eingefügt, kann der Business-Analyst nach Prioritäten sortieren oder nach der Priorität auf die Anforderungen zugreifen.

• Scope der Lösung: Er wird bei der Priorisierung berücksichtigt, um sicher-zustellen, dass die Priorisierung mit dem Scope verträglich ist.

Techniken

• Backlog Management: Wird bei der Priorisierung zum Vergleich von Anforderungen hinzugezogen. Im Backlog kann die Priorisierung der Anforderungen gepflegt werden.

• Business Cases: Werden genutzt, um Anforderungen mit den ermittelten Unternehmens- und Geschäftszielen abzugleichen, um damit ihre Wich-tigkeit zu bestimmen.

• Entscheidungsanalyse: Wird zur Identifikation von sehr wichtigen Anforderungen genutzt.

• Schätzung: Schätzungen können als Basis der Priorisierung dienen. • Finanzanalyse: Wird zur Bestimmung des finanziellen Werts einer Gruppe von Anforderungen genutzt sowie zur Abschätzung, wie sich der Zeit-punkt der Fertigstellung auf deren Nutzen auswirken kann.

• Interviews: Werden angewandt, um ein besseres Verständnis der grund-legenden Prioritäten bzw. der Priorisierung einzelner Stakeholder oder kleiner Gruppen von Stakeholdern zu erhalten

• Item Tracking: Wird genutzt, um bei der Priorisierung den Überblick über Sachverhalte zu behalten, die von Stakeholdern vorgebracht wurden.

• Priorisierung: Wird zur Unterstützung des Priorisierungsprozesses ange-wandt.



106

5.3.5

5.3.6

• Risikoanalyse und -management: Werden zum Verständnis von Risiken genutzt, die bei der Priorisierung zu beachten sind.

• Workshops: Werden genutzt, um im Rahmen einer moderierten Gruppen-arbeit ein besseres Verständnis der grundlegenden Prioritäten bzw. der Prio-risierung von Stakeholdern zu erhalten.

Stakeholder

• Kunden: Sie verifizieren aus der Perspektive des Kunden oder Endanwen-ders, ob eine priorisierte Anforderung tatsächlich einen Mehrwert liefert. Kunden können auch über eine Änderung der Priorisierung verhandeln, wenn sie eine andere Einschätzung des Nutzens haben.

• Endanwender: Er verifiziert, dass die priorisierten Anforderungen aus der Sicht des Endanwenders einen Mehrwert bringen.

• Umsetzungsexperte: Er bringt Informationen zu technischen Abhängig-keiten ein und kann auf der Grundlage technischer Restriktionen über eine Änderung der Priorisierung verhandeln.

• Projektmanager: Er nutzt die Priorisierung für seinen Projektplan sowie bei der Zuordnung von Anforderungen zu Releases.

• Regulator: Er kann bestätigen, dass die Anforderungen mit rechtlichen und regulatorischen Vorgaben verträglich sind.

• Sponsor: Er kann bestätigen, dass die priorisierten Anforderungen aus betrieblicher Sicht einen Mehrwert erbringen.

Outputs

• Anforderungen (priorisiert): Priorisierte oder in einer Rangfolge geordnete Anforderungen stehen zur weiteren Verarbeitung bereit; dabei ist sichergestellt, dass die Anforderungen mit dem höchsten Mehrwert zuerst bearbeitet werden.

• Designs (priorisiert): Priorisierte oder in einer Rangfolge geordnete Designs stehen zur weiteren Verarbeitung bereit; dabei ist sichergestellt, dass die Designs mit dem höchsten Mehrwert zuerst bearbeitet werden.



107

5.3.7

5.3.8

Änderungen von Anforderungen beurteilen

Zweck

Der Zweck von „Änderungen von Anforderungen beurteilen“ besteht in derBewertung der Auswirkungen, die vorgeschlagene Änderungen von Anforde-rungen und Designs haben können.

Beschreibung

Die Aufgabe „Änderungen von Anforderungen beurteilen“ wird ausgeführt,wenn neue Bedarfe oder mögliche Lösungen identifiziert werden. Diese könnenmit der Change-Strategie und/oder dem Scope der Lösung in Einklang stehen,müssen es aber nicht. Die Beurteilung muss durchgeführt werden, um zu prüfen,ob die vorgeschlagene Veränderung den Mehrwert einer Lösung vergrößert,und um gegebenenfalls zu bestimmen, was dazu getan werden muss.

Der Business-Analyst beurteilt die potentiellen Auswirkungen einer Veränderungauf den Nutzen der Lösung und prüft, ob vorgeschlagene Änderungen mitanderen Anforderungen verträglich sind oder ob das allgemeine Risiko gesteigertwird. Der Business-Analyst stellt weiterhin sicher, dass eine vorgeschlagene Ände-rung einen anerkannten Bedarf erfüllt.

Wenn eine Änderung beurteilt wird, prüft der Business-Analyst, ob die vorge-schlagene Änderung

• im Einklang mit der Unternehmensstrategie steht• für das Unternehmen oder einzelne Stakeholder-Gruppen Mehrwert liefert• Auswirkungen auf den Lieferzeitpunkt der Lösung oder auf eine zur Mehrwertlieferung benötigte Ressource hat

• ob Risiken, Chancen oder Einschränkungen beeinflusst werden, die in einem Zusammenhang mit dem gesamten Vorhaben stehen.

Die Ergebnisse dieser Beurteilung müssen die Entscheidungsfindung sowie dieKontrollansätze unterstützen, die im Wissensgebiet „Planung und Überwachungder Business-Analyse“ definiert werden.

Inputs

• Vorgeschlagene Änderungen: Sie können jederzeit entdeckt werden und beeinflussen jegliche Arbeit oder bisherige Ergebnisse der Business-Analyse. Es gibt viele Auslöser für eine vorgeschlagene Veränderung, seien es Ände-rungen der Unternehmensstrategie, der Stakeholder, der rechtlichen Anfor-derungen oder des regulatorischen Rahmens.



108

5.4

5.4.1

5.4.2

5.4.3

• Anforderungen und Designs: Sie müssen gegebenenfalls überprüft werden,um mögliche Auswirkungen einer vorgeschlagenen Änderung zu ermitteln.

Abb. 5.4.1: Input-Output-Diagramm „Änderungen von Anforderungen beurteilen“

Elemente

.1 Formalisierung der BeurteilungDer Business-Analyst bestimmt das Ausmaß der Formalisierung des Beurteilungs-prozesses; dabei berücksichtigt er die verfügbaren Informationen, die unterstellteWichtigkeit einer Veränderung und die Regelungen zum Entscheidungsprozess.Viele vorgeschlagene Veränderungen werden vor der genaueren Überprüfungzurückgenommen oder abgelehnt, so dass sich eine formale Genehmigungerübrigt. In vorausplanenden Vorhaben kann die Auswirkung jeder Veränderungverheerend sein; eine Änderung an einer Stelle kann möglicherweise dazu führen,dass alle bisher ausgeführten Aufgaben und Aktivitäten überprüft und überar-beitet werden müssen. Ein adaptiver Ansatz hingegen benötigt einen niedrigerenFormalitätsgrad bei der Beurteilung von Veränderungen. Zwar kann auch hiereine Überarbeitung nötig sein, adaptive Ansätze versuchen jedoch die Auswir-kungen von Veränderungen zu minimieren, indem iterative und inkrementelleImplementierungstechniken verwendet werden. Die Idee der fortlaufenden Evo-lution erfordert weniger formale Beurteilungsverfahren.



109

Input

Anforderungen

Änderungen von Anforderungenbeurteilen

5.4

Output


Fachwissen

Steuerungsansatz

Anforderungs-Architektur

Scope der Lösung



5.4 BeurteilteÄnderungenvon Designs

5.4 Beurteilte


VorgeschlageneÄnderungen

Designs

5.4.4

.2 WirkungsanalyseEine Wirkungsanalyse wird zur Beurteilung oder Bewertung der Auswirkungeneiner Veränderung genutzt. Rückverfolgbarkeit ist an dieser Stelle ein hilfreichesWerkzeug zur Analyse der Auswirkungen. Wenn sich eine Anforderung ändert,können die Verbindungen zu anderen Anforderungen oder Lösungskomponentenüberprüft werden.

Eine Änderung kann bei jeder damit verbundenen Anforderung oder Lösungs-komponente ebenfalls eine Änderung nötig machen.

Wenn Änderungen oder Zusätze zu bestehenden Anforderungen erwogen wer-den, sollte der Business-Analyst die Auswirkungen der vorgeschlagenen Änderungbeurteilen und dabei Folgendes beachten:

• Nutzen: Welcher Nutzen ergibt sich, wenn die gewünschte Änderung umgesetzt wird?

• Kosten: Wie hoch sind die Gesamtkosten der Umsetzung der Änderung, die Kosten der damit verbundenen Nachbearbeitung und die Opportuni-tätskosten, die sich zum Beispiel ergeben, weil andere Lösungsmerkmale deswegen verschoben oder aufgegeben werden müssen?

• Auswirkung: Wie viele Kunden- oder Geschäftsprozesse sind durch dieVeränderung betroffen?

• Zeitplan: Welche Auswirkungen ergeben sich hinsichtlich bestehender Lieferversprechungen?

• Dringlichkeit: Wie wichtig, notwendig oder gar zwingend (z.B. regulato-rische Angelegenheiten oder Sicherheitsprobleme) ist die gewünschte Veränderung?

.3 Entscheidungsfindung Abhängig vom gewählten Ansatz können unterschiedliche Stakeholder befugtsein, die vorgeschlagenen Änderungen anzunehmen, abzulehnen oder zu ver-schieben. Sämtliche Auswirkungen und die aus der Auswirkungsanalyse stam-menden Entscheidungen müssen dokumentiert und an alle Stakeholder kom-muniziert werden. Wie Entscheidungen getroffen, Veränderungen durchgeführtund kommuniziert werden, wird in der Aufgabe „Planung und Überwachungder Business-Analyse“ festgelegt.


• Veränderungsstrategie: Sie beschreibt den Zweck und die Richtung von Änderungen, stellt einen Bezug zum Kontext der Änderung her und identifiziert kritische Komponenten der Änderung.

• Fachwissen: Das Wissen und die Expertise des Fachbereichs werden zur Beurteilung von vorgeschlagenen Änderungen benötigt.



110

5.4.5

• Steuerungsansatz: Der Steuerungsansatz regelt die Kontrolle der Verän-derung sowie den Entscheidungsprozess, aber auch die Rolle der Stake-holder innerhalb dieser Prozesse.

• Rechtliche/Regulatorische Informationen: Sie beschreiben die einzuhalten-den rechtlichen Vorschriften und Regelungen, die einen großen Einfluss auf Anforderungen haben können und bei etwaigen Änderungen berück-sichtigt werden müssen.

• Anforderungs-Architektur: Anforderungen können miteinander in Beziehung stehen, weshalb der Business-Analyst auch diese Verbindun-gen untersuchen und analysieren muss; so kann er bestimmen, welche Anforderungen von einer geforderten Änderung betroffen sind.

• Scope der Lösung: Er muss bei der Beurteilung von Änderungen beachtet werden, um die Auswirkungen einer vorgeschlagenen Änderung zu verstehen.

Techniken

• Business Cases: Werden zur Rechtfertigung einer vorgeschlagenen Änderung genutzt.

• Analyse der Geschäftsregeln: Wird dazu genutzt, um Änderungen im Hinblick auf Unternehmenspolitik und Geschäftsregeln zu bewerten und um die Orientierung zu erleichtern.

• Entscheidungsanalyse: Wird zur Unterstützung im Beurteilungsprozess von Änderungen genutzt.

• Dokumentenanalyse: Wird zur Analyse bestehender Dokumente genutzt, dieein besseres Verständnis der Auswirkung einer Veränderung ermöglichen.

• Schätzung: Wird zur Abschätzung der Größe einer Änderung verwendet.• Finanzanalyse: Wird zur Bewertung der finanziellen Konsequenzen einer vorgeschlagenen Änderung verwendet.

• Schnittstellenanalyse: Wird verwendet, um dem Business-Analysten bei der Identifikation von solchen Schnittstellen zu helfen, die von der Ände-rung betroffen sein können.

• Interviews: Mit ihrer Hilfe können die Auswirkungen auf die Organisation und deren Assets besser verstanden werden

• Item Tracking: Wird dazu genutzt, einen Überblick über alle Angelegen-heiten oder Konflikte zu behalten, die bei der Analyse der Auswirkungen entdeckt werden.

• Risikoanalyse und -management: Werden zur Bestimmung des Risiko-grades genutzt, der mit der Änderung verbunden ist.

• Workshops: Werden genutzt, um ein besseres Verständnis über die Aus-wirkungen zu erlangen.



111

5.4.6

Stakeholder

• Kunden: Sie geben eine Rückmeldung darüber, welche Auswirkungen eine Änderung auf den Nutzen einer Lösung haben wird.

• Fachbereichsexperte: Er ist hinsichtlich einiger Aspekte der Situation fachlich kompetent und kann daher Einblicke bieten, wie sich die Ände-rung auf die Organisation und den Nutzen einer Lösung auswirken wird.

• Endanwender: Er benutzt die Lösung oder ist Bestandteil der Lösung und kann Informationen über die Auswirkungen der Änderung auf seine Aktivitäten liefern.

• Support: Er bietet Informationen sowohl über seine Fähigkeit, das System zu managen und zu warten, als auch über seinen Informationsbedarf, um die umgesetzte Änderung später betreiben und unterstützen zu können.

• Projektmanager: Er überprüft die Beurteilung der Anforderungsänderung,um zu bestimmen, ob zusätzliche Projektarbeit für eine erfolgreiche Implementierung der Lösung notwendig ist.

• Regulator: Änderungen müssen wahrscheinlich Auditoren mitgeteilt werden, um die Einhaltung von Standards zu bestätigen.

• Sponsor: Er ist für den Scope der Lösung gesamtverantwortlich und kann Hintergrundinformationen liefern, die in die Beurteilung einer Verände-rung miteinfließen können.

• Tester: Er wird hinzugezogen, um die Auswirkung einer vorgeschlagenen Änderung zu ermitteln.

Outputs

• Beurteilte Änderungen von Anforderungen: Es wird eine Empfehlung gegeben, eine vorgeschlagene Anforderungsänderung zu genehmigen, zu modifizieren oder abzulehnen.

• Beurteilte Änderungen von Designs: Es wird eine Empfehlung abgegeben, eine vorgeschlagene Design-Änderung an einer oder mehrerer Design-Komponenten zu genehmigen, zu modifizieren oder abzulehnen.

Anforderungen genehmigen

Zweck

Der Zweck von „Anforderungen genehmigen“ besteht darin, über Anforderungenund Designs Einigung zu erreichen und Genehmigung einzuholen, damit die Busi-ness-Analyse und/oder die Konstruktion der Lösung fortgesetzt werden können.



112

5.4.7

5.4.8

5.5.1

5.5

Beschreibung

Der Business-Analyst ist für eine klare Kommunikation von Anforderungen,Designs oder anderen Informationen der Business-Analyse gegenüber Kern-Sta-keholdern, die für Genehmigungen zuständig sind, verantwortlich.

Die Genehmigung von Anforderungen und Designs kann formal oder informellgeschehen. In vorausplanenden Ansätzen werden Genehmigungen typischerweiseam Ende einer Phase oder in vorab geplanten Meetings zur Steuerung des Ände-rungsprozesses eingeholt. Bei adaptiven Ansätzen werden Genehmigungen nor-malerweise nur dann eingeholt, wenn die Konstruktion und Implementierungeiner Lösung beginnen kann. Der Business-Analyst arbeitet mit den Kern-Stake-holdern zusammen, um Zustimmung zu neuen und geänderten Anforderungeneinzuholen, um die Ergebnisse dieser Diskussionen zu kommunizieren und umdie genehmigten Anforderungen umzusetzen und nachzuverfolgen.

Inputs

• Anforderungen (bestätigt): Das ist eine Gruppe von Anforderungen, die als qualitativ zufriedenstellend bestätigt wurde und die als verlässliche Grundlage für weitere Spezifikationen und Entwicklungen dient.

• Designs: Diese Gruppe von Designs wurde als geeignet befunden zur wei-teren Spezifikationen und zur Entwicklung.

Abb. 5.5.1: Input-Output-Diagramm „Anforderungen genehmigen“



113

5.5.2

5.5.3

Input

Anforderungen(bestätigt)

Designs

Anforderungen(genehmigt)

5.5

Anforderungen genehmigen5.5

Output


Designs(genehmigt)

5.5

Steuerungsansatz


Scope der Lösung



Elemente

.1 Verstehe die Rollen der StakeholderDer Genehmigungsprozess wird durch die Aufgabe „Steuerung der Business-Ana-lyse planen“ (Kap. 3.1) definiert. Für die Planung dieses Genehmigungsprozessesmuss Klarheit herrschen über die Rollen und Kompetenzen der Stakeholder. DerBusiness-Analyst ist dafür verantwortlich, Genehmigungen von Stakeholdern ein-zuholen und muss dazu verstehen, wer entscheidungsbefugt ist und wer über diegesamte Initiative hinweg Freigaben erteilt. Der Business-Analyst muss auch aufStakeholder achten, die großen Einfluss haben und die deswegen zu Anforderungenbefragt werden oder über diese informiert sein sollten. Es sind zwar nur wenigeStakeholder befugt, Anforderungen zu genehmigen oder abzulehnen, aber esgibt viele Stakeholder, die diesen Entscheidungsprozess beeinflussen können.

.2 Management von Konflikten und ProblemenUm die Stakeholder für eine Lösung zu gewinnen, wird in der Regel versucht,einen Konsens zu finden, bevor die Anfrage zur Genehmigung von Anforde-rungen gestellt wird. Der für die gesamte Initiative gewählte Ansatz zur Ent-scheidungsfindung und Konfliktlösung wird in der Aufgabe „Steuerung derBusiness-Analyse planen“ (Kap. 3.1) festgelegt.

Stakeholder-Gruppen haben oft verschiedene Sichtweisen und Prioritäten, dienicht im Einklang mit anderen Stakeholdern stehen. Ein Konflikt zwischen denStakeholdern kann z.B. durch abweichende Interpretationen von Anforderungenoder Designs entstehen oder aufgrund unterschiedlicher Bewertungen von Anfor-derungen oder Designs. In diesen Konfliktsituationen stellt der Business-Analystdie Kommunikation zwischen Stakeholdern sicher, sodass jede Gruppe dieBedarfe anderer Gruppen besser nachvollziehen kann. Konflikt- und Problemlö-sung sind relativ oft erforderlich, wenn der Business-Analyst Anforderungen undDesigns überprüft und versucht, eine Genehmigung für diese zu erhalten.

.3 Zustimmung gewinnenDer Business-Analyst ist dafür verantwortlich, dass die Stakeholder mit Entschei-dungsbefugnissen die Anforderungen verstehen und akzeptieren. Die Genehmigungbestätigt, dass die Stakeholder davon überzeugt wurden, dass der Mehrwert,den die Umsetzung einer Anforderung bringt, eine Investition in eine Lösungrechtfertigt. Der Business-Analyst holt Genehmigungen ein, indem er Anforderungenoder Änderungen zuvor gemeinsam mit den verantwortlichen Stakeholdern über-prüft und beim Einholen der Genehmigung dann darauf hinweist, dass dieseLösungen oder Designs von den betroffenen Stakeholdern mitgetragen werden.

Der Business-Analyst präsentiert die Anforderungen den Stakeholdern, um derenZustimmung einzuholen und nutzt dabei die Methoden und Mittel aus den Auf-gaben „Steuerung der Business-Analyse planen“ (Kap. 3.1) und „Business-Ana-



114

5.5.4

lyse-Informationen kommunizieren“ (Kap. 4.4). Um den Genehmigungsprozesszu unterstützen, spricht der Business-Analyst jegliche Fragen an oder stellt imFalle von Nachfragen weitere Informationen bereit.

Für den Erfolg einer Änderung ist eine hundertprozentige Zustimmung nichtunbedingt notwendig. Sind jedoch nicht alle damit einverstanden, müssen diedamit verbundenen Risiken identifiziert und behandelt werden.

.4 Verfolge und kommuniziere GenehmigungenEin Business-Analyst zeichnet die Ergebnisse der Entscheidungen auf, wennmöglich in Tools zur Pflege und Nachverfolgung von Anforderungen. Soll derStatus von Anforderungen kommuniziert werden, sind akkurate Aufzeichnungenüber den aktuellen Genehmigungsstatus erforderlich. Stakeholder müssen inder Lage sein, die Anforderungen und Designs zu bestimmen, die zu diesemZeitpunkt genehmigt sind und zur Implementierung anstehen. Es kann hilfreichsein, eine Änderungshistorie der Anforderungen zu führen: was hat sich geändert,wer hat die Änderung durchgeführt, weshalb wurde geändert und wann wurdediese Änderung ausgeführt.


• Veränderungsstrategie: Sie bietet Informationen, wie ein Konsens zwischen den Stakeholdern erreicht werden kann.

• Steuerungsansatz: Er identifiziert die Stakeholder, die Entscheidungsbefug-nisse über Informationen der Business-Analyse besitzen, und legt fest, wann diese Genehmigungen stattfinden und wie sie auf die Unternehmenspolitik ausgerichtet werden.

• Rechtliche/Regulatorische Informationen: Sie beschreiben die einzuhaltendengesetzlichen Vorgaben und Rahmenbedingungen. Diese können einen Ein-fluss auf den Genehmigungsprozess von Anforderungen und Designs haben.

• Anforderungsmanagement-Tools/Ablagen: Tools, um Anforderungsgeneh-migungen aufzuzeichnen.

• Scope der Lösung: Der Lösungsumfang muss bei der Genehmigung von Anforderungen beachtet werden, um deren Verträglichkeit und Vollständig-keit beurteilen zu können.

Techniken

• Akzeptanz- und Bewertungskriterien: Sie werden zur Definition von Ent-scheidungskriterien genutzt.

• Entscheidungsanalyse: Sie wird zur Bewertung von Lösungen herangezo-gen und kann dazu beitragen, Zustimmung zu gewinnen.



115

5.5.5

5.5.6

• Item Tracking: Es wird dazu genutzt, Sachverhalte nachzuverfolgen, die im Einigungsprozess identifiziert werden .

• Reviews: Anforderungen werden in Reviews bewertet.• Workshops: Sie können die Einholung von Zustimmung fördern.

Stakeholder

• Kunden: Sie können bei der Überprüfung und Genehmigung von Anforde-rungen und Designs eine aktive Rolle spielen, um sicherzustellen, dass ihre Bedarfe erfüllt werden.

• Fachexperten: Sie können in die Überprüfung und Genehmigung von Anfor-derungen und Designs involviert sein, je nachdem wie die Rollen der Stakehol-der und Entscheider definiert sind.

• Endanwender: Personen, die die Lösung nutzen oder selbst eine Lösungskom-ponente darstellen, und die bei der Überprüfung, Validierung und Priorisie-rung von Anforderungen und Designs involviert sein können, je nachdem wie die Rollen der Stakeholder und Entscheider definiert sind.

• Support: Er trägt die Verantwortung, dass Anforderungen und Designs im Rahmen der technologischen Einschränkungen und der betrieblichen Potentiale unterstützt werden können. Das Support-Personal kann bei der Überprüfung und Genehmigung von Anforderungen eine Rolle spielen.

• Projektmanager: Er ist für die Identifikation von und den Umgang mit Risiken verantwortlich, die in Verbindung mit dem Lösungs-Design, der Entwicklung, der Lieferung, der Implementierung, dem Betrieb oder der Nachhaltigkeit stehen. Der Projektmanager kann Aktivitäten des Projektplans zur Überprü-fung und/oder zur Genehmigung steuern.

• Regulatoren: Das sind externe oder interne Teilnehmer, die zu der Verbindungzwischen geäußerten Anforderungen und spezifischen Regulierungen Stellungnehmen müssen, entweder formal in einer Prüfung oder informal als Input fürdie Aufgaben des Managements des Anforderungs-Lebenszyklus.

• Sponsor: Er ist dafür zuständig, den Business Case, die Lösung, den Scope der Lösung sowie Anforderungen und Designs zu überprüfen und zu genehmigen.

• Tester: Er ist dafür zuständig, dass die Qualitätsstandards mit den Informatio-nen der Business-Analyse verträglich sind.

Outputs

• Anforderungen (genehmigt): Anforderungen, denen die Stakeholder zugestimmt haben und die zur weiteren Verwendung für die Business-Analyse bereitstehen.

• Designs (genehmigt): Designs, denen die Stakeholder zugestimmt haben und die zur weiteren Verwendung für Entwicklungsarbeiten bereitstehen.



116

5.5.7

5.5.8

117

Die Strategie definiert die effektivste Art und Weise, wie die Fähigkeiten einesUnternehmens eingesetzt werden können, um die gewünschten Ziele zu errei-chen. Es kann Strategien für ein ganzes Unternehmen, einen Bereich, eine Abtei-lung, eine Region, ein Produkt, ein Projekt oder für einen Entwicklungszyklusgeben.

Das Wissensgebiet „Strategische Analyse“ beschreibt die Tätigkeiten der Busi-ness-Analyse, die erledigt werden müssen, um in Zusammenarbeit mit den Stake-holdern einen Bedarf von strategischer oder taktischer Bedeutung zu identifizieren,das Unternehmen in die Lage zu versetzen, diesen Bedarf zu erfüllen und diedaraus resultierende Strategie für die Veränderung mit über- oder untergeordnetenStrategien abzustimmen.

Die strategische Analyse konzentriert sich auf die Definition von zukünftigenZuständen und Übergängen, die notwendig sind, um diesen betrieblichen Bedarfzu erfüllen. Die dafür notwendige Arbeit wird durch den konkreten Bedarf undden jeweiligen Lösungsraum bestimmt. Dieser Lösungsraum umfasst sowohlstrategisches Denken im Zuge der Business-Analyse als auch das Entdecken oderEntwickeln von möglichen Lösungen, die es dem Unternehmen ermöglichen,einen größeren Nutzen für die Stakeholder und für sich selbst zu schaffen.

Die strategische Analyse bildet den Kontext für die Analyse der Anforderungenund für das Design einer bestimmten Veränderung. Eine strategische Analysesollte immer dann gestartet werden, wenn ein neuer betrieblicher Bedarf iden-tifiziert wird. Mit ihrer Hilfe können Stakeholder entscheiden, ob dieser konkretebetriebliche Bedarf berücksichtigt wird oder nicht. Die strategische Analyse findetlaufend statt, um Veränderungen des betrieblichen Bedarfs oder des aktuellenKontextes zu bewerten oder wenn neue Informationen auftauchen, die mögli-cherweise eine Anpassung der Change-Strategie erfordern.

Die folgende Grafik zeigt die Bandbreite der Wertschöpfung im Fortgang derAktivitäten der Business-Analyse vom potentiellen Nutzen zum tatsächlichenWert.

6 Strategische Analyse

Abb. 6.0.1: Nutzen der Business-Analyse

Im Zuge der strategischen Analyse muss der Business-Analyst den jeweiligenKontext ebenso berücksichtigen wie die Vorhersehbarkeit möglicher Ergebnisse.Hat eine Veränderung ein vorhersehbares Ergebnis, sind der zukünftige Zustandund mögliche Entwicklungsstufen leicht zu bestimmen und damit kann aucheine klare Strategie definert werden. Wenn das Ergebnis der Veränderung nichtso eindeutig abzusehen ist, wird es sinnvoller sein, sich auf Risikominimierung,die Prüfung von Annahmen und eine Strategie kleinerer Schritte zu beschränken,bis eine klare Strategie anwendbar ist oder bis das Vorhaben beendet wird. DieTätigkeiten können in beliebiger Reihenfolge durchgeführt werden, obwohl siemeistens gleichzeitig ablaufen, da die Strategie sich danach richten muss, wastatsächlich im Bereich des Möglichen liegt.

Eine Strategie wird in Form eines strategischen Plans, einer Vision, eines BusinessCases, einer Produkt-Roadmap oder einer anderen passenden Form festgehalten.

Das Wissensgebiet „Strategische Analyse“ umfasst folgende Tätigkeiten:• Ist-Zustand analysieren: Dazu muss der betriebliche Bedarf verstanden werden und dessen Zusammenhang mit der Arbeitsweise des Unter-nehmens. Damit werden die Grundlage und der Kontext für eine Veränderung geschaffen.

• Soll-Zustand definieren: Er definiert die Ziele, die zeigen können, dass der betriebliche Bedarf erfüllt wurde, und bestimmt, welche Teile des Unternehmens verändert werden müssen, um diese Ziele zu erfüllen.

• Risiken bewerten: Die Unwägbarkeiten von Veränderungen müssen verstanden werden, um abzuschätzen, welche Auswirkungen sie auf die Zielerreichung haben können und welche Maßnahmen zur Bewäl-tigung von Risiken geeignet sein können.

• Change-Strategie definieren: Es wird eine Analyse der Abweichung zwischen Ist- und Soll-Zustand durchgeführt. Die verschiedenen Optio-nen, um den Soll-Zustand zu erreichen, werden bewertet und es wird der Ansatz empfohlen, der den höchsten Nutzen bringt, einschließlich der dazu notwendigen Übergangsstadien.

118


Bedarf

Potential Umsetzung

Scope derLösung

Anforderun-gen

Design Machbarkeits-studie/

Prototyp

Pilot/Beta-

version

Betrieb

StrategischeAnalyse


Lösungsbewertung

Das Kernkonzept-Modell in der strategischen AnalyseDas „Kernkonzept-Modell der Business-Analyse“ beschreibt die Beziehungenzwischen den sechs fundamentalen Konzepten. Die folgende Tabelle beschreibtdie Verwendung und Anwendung dieser fundamentalen Konzepte in der stra-tegischen Analyse:

Tabelle 6.0.1: Das Kernkonzept-Modell in der strategischen Analyse

Strategische Analyse Das Kernkonzept-Modell in der strategischen Analyse

119

Kernkonzept In der strategischen Analyse wird mit dem jeweiligenKonzept wie folgt gearbeitet...


...der Soll-Zustand und eine Change-Strategie, diedient, den Soll-Zustand zu erreichen, werden defi-niert.


...die Bedarfe des Ist-Zustands werden identifiziertund priorisiert, um den Soll-Zustand zu bestimmen.


...der Scope einer Lösung wird als Teil der Change-Strategie definiert.


...mit den Stakeholdern wird zusammengearbeitet,um den betrieblichen Bedarf zu verstehen und umeine Strategie und einen Soll-Zustand zu entwi-ckeln, damit diese Bedarfe erfüllt werden.


...der potentielle Wert der Lösung wird geprüft, umbestimmen zu können, ob eine Veränderunggerechtfertigt ist..


...der Kontext, in dem sich das Unternehmen befin-det, wird bei der Entwicklung der Change-Strategieberücksichtigt.

Abb. 6.0.2: Input-Output-Diagramm „Strategische Analyse“


120

Aufgaben

Output

Input


6.1Soll-Zustand

definieren

6.2

Change-Strategie definieren

6.4

Beschreibungdes Ist-Zustands

6.1 6.1 Betriebliche

Ziele

6.2

Change-Strategie6.4

Scope derLösung

6.4


Bedarfe Einflüsse(intern, extern)


Stakeholder

3.2

Beschreibungdes Soll-Zustands

6.2 6.2 Ergebnisse derRisiko-Analyse

6.3 Potentieller

Nutzen

4.2 Erhebungs-ergebnisse(bestätigt)


(unbestätigt)


5.3


5.3

Risikenbewerten

6.3

Ist-Zustand analysieren

Zweck

Mit der Analyse des Ist-Zustands soll verstanden werden, warum ein Unternehmenetwas verändern muss und was davon direkt oder indirekt betroffen ist.

Beschreibung

Am Anfang eines Veränderungsvorhabens muss erst einmal verstanden werden,warum eine Veränderung überhaupt notwendig ist. Potentielle Veränderungenwerden durch bestimmte Probleme angestoßen, die nicht gelöst, oder Chancen,die nicht wahrgenommen werden können, ohne den Ist-Zustand zu verändern.Der Business-Analyst hilft Stakeholdern, indem er betriebliche Bedarfe untersuchtund zur Sprache bringt und so das Streben nach Veränderung weckt. Ohne diebetrieblichen Bedarfe vollkommen verstanden zu haben, ist es entweder unmög-lich, eine passende Strategie zu entwickeln, oder es besteht die Gefahr, dasseine Change-Strategie auf unterschiedlichen bzw. widersprüchlichen Forderungenvon Stakeholdern beruht.

Eine Veränderung geschieht immer im Kontext von bestehenden Stakeholdern,Prozessen, genutzten Technologien und Vorgehensweisen, die den aktuellenZustand des Unternehmens bilden. Der Business-Analyst untersucht den Ist-Zustand im Zusammenhang mit dem betrieblichen Bedarf, um zu verstehen,welche Faktoren geplante Veränderungen beeinflussen und was durch die Ver-änderungen wiederum beeinflusst wird. Der Ist-Zustand wird so detailliertbetrachtet, wie es nötig ist, um den Änderungsbedarf und die Change-Strategiesinnvoll zu validieren. Es ist notwendig, den Ist-Zustand zu verstehen, um iden-tifizieren zu können, was verändert werden muss, um einen Soll-Zustand zuerreichen und um anschließend das Ergebnis der Veränderung bewerten zukönnen.

Der Scope des Ist-Zustands beschreibt die wichtigsten bestehenden Einflussfak-toren aus der Umwelt des Vorhabens. Die Grenzen des Scopes des Ist-Zustandswerden durch die Bestandteile des Unternehmens und dessen Umgebungbestimmt, die für den Bedarf relevant sind. Der Ist-Zustand kann auf unter-schiedlichen Ebenen beschrieben werden, von der Sicht des Gesamtunternehmensbis hin zu kleinen Komponenten einer konkreten Lösung. Um das Modell desIst-Zustands zu erstellen, muss möglicherweise mit dem gesamten Unternehmenkooperiert werden, eventuell sogar mit Einheiten außerhalb des Unternehmens.Für kleinere Vorhaben ist manchmal auch nur ein kleiner Teil des Unternehmensbetroffen.

Strategische Analyse Ist-Zustand analysieren

121

6.1

6.1.1

6.1.2

Wenn eine Veränderung entwickelt und eingeführt wird, verändert sich oft derIst-Zustand eines Unternehmens. Interne und externe Faktoren, wie auch andereorganisatorische Veränderungen, können den Ist-Zustand so beeinflussen, dassder Soll-Zustand oder auch die Change-Strategie, Anforderungen und Designsverändert werden müssen.

Inputs

• Erhebungsergebnisse (bestätigt): Sie werden verwendet, um den Ist-Zustand zu definieren und verstehen.

• Bedarfe: Probleme oder Chancen eines Unternehmens oder einer Organisa-tion; führen oft dazu, dass Tätigkeiten der Business-Analyse ausgeführt werden, um diese Probleme oder Chancen besser zu verstehen.

Strategische AnalyseIst-Zustand analysieren

122

6.1.3

Abb. 6.1.1: Input-Output-Diagramm „Ist-Zustand analysieren“


123

Input

Bedarfe


6.1

Ist-Zustand analysieren6.1

Output



6.1

BetrieblicheBeschränkungen

Maß der Lösungs-Performance

Ergebnisse derStakeholder-Analyse

Business-Analyse-Ansatz

Performance-Zieleder Lösung

Erhebungs-ergebnisse(bestätigt)

4.3

Einschränkungen derLösung

Unternehmensstrategie


Soll-Zustanddefinieren

6.2

Aufgabe, die diesenOutput verwendet

Einbindungder Stakeholder

planen

3.2 Steuerung der


3.3


6.2Risiken

bewerten

6.3


6.4Nutzenpotentialanalysieren und

Lösung empfehlen

7.6

Einschränkungendes Unternehmens

beurteilen

8.4Maßnahmen zur Stei-gerung des Nutzensder Lösung empfehlen

8.5

Elemente

.1 Betrieblicher BedarfBetriebliche Bedarfe sind die Probleme und Chancen, die eine strategische Bedeu-tung für das Unternehmen haben. Vorgänge innerhalb eines Unternehmens, wiezum Beispiel eine Kundenbeschwerde, ein Umsatzverlust oder eine neue Markt-chance lösen normalerweise die Bewertung eines betrieblichen Bedarfs aus.

Ein betrieblicher Bedarf kann auf verschiedenen Ebenen innerhalb des Unter-nehmens identifiziert werden:

• Top-down: Ein strategisches Ziel soll erreicht werden.• Bottom-up: Es taucht ein Problem auf mit dem aktuellen Zustand einesProzesses, einer Unternehmensfunktion oder eines Systems.

• Sicht des mittleren Managements: Eine Führungskraft benötigt zusätz-liche Informationen, um eine fundierte Entscheidung zu treffen oder sie muss zusätzliche Funktionen ausführen, um Unternehmensziele zu erreichen.

• Externe Sicht: Neue Wünsche von Kunden tauchen auf, eine Konkur-renzsituation am Markt verändert sich oder es gibt Änderungen von gesetzlichen Rahmenbedingungen.

Die Definition des betrieblichen Bedarfs ist häufg der entscheidende Schritt imRahmen der Tätigkeiten der Business-Analyse. Eine Lösung muss den betrieblichenBedarf erfüllen, um als erfolgreich angesehen zu werden. Die Art und Weisewie der betriebliche Bedarf definiert wird, ist ausschlaggebend dafür, welchealternativen Lösungen in Betracht gezogen, welche Stakeholder befragt undwelche Lösungsansätze evaluiert werden. Betriebliche Bedarfe werden immeraus der Sicht des Unternehmens als Ganzes beschrieben und nicht aus der Sichteines bestimmten Stakeholders.

Betriebliche Bedarfe werden oft zusammen mit einer mutmaßlichen Lösungbeschrieben. Der Business-Analyst sollte immer die Annahmen und Bedingungen,die hinter einem betrieblichen Bedarf stecken, hinterfragen, damit das richtigeProblem gelöst wird und die größtmögliche Bandbreite an alternativen Lösungs-ansätzen berücksichtigt wird.

Die Lösung zu einem Bündel betrieblicher Bedarfe muss das Potential haben,Nutzen für das Unternehmen oder für seine Stakeholder zu schaffen oder Verlustezu vermeiden, die sonst eintreten würden. Folgende Faktoren könnte der Busi-ness-Analyst berücksichtigen:

• Nachteile, die das Problem innerhalb der Organisation verursacht, und die Quantifizierung dieser Nachteile (z.B. potentieller Einnahmen-verlust, Ineffizienzen, unzufriedene Kunden, mangelnde Mitarbeiter-zufriedenheit)


124

6.1.4

• erwartete Vorteile einer potentiellen Lösung (z.B. Steigerung der Umsätze, Kostenreduktion, größerer Marktanteil)

• Schnelligkeit, mit der ein Problem gelöst oder eine Chance ergriffen werden kann, oder was es kostet, nichts zu tun

• die eigentliche Ursache des Problems.

Betriebliche Bedarfe prägen die Analyse des Ist-Zustands. Obwohl es nicht unbe-dingt notwendig ist, alle Aspekte des Ist-Zustands detailliert zu behandeln, bevoreine Change-Strategie entwickelt wird, bringt diese Analyse dennoch meistensdie grundlegenden Ursachen zu Tage, die das Problem oder die Chance verursachthaben (die wiederum zusätzlicher betrieblicher Bedarf sein können).

.2 Organisationsstruktur und KulturDie Organisationsstruktur definiert die formalen Beziehungen zwischen Mitar-beitern in einem Unternehmen. Obwohl Kommunikationskanäle und Beziehungennicht auf die formale Beziehungsebene beschränkt sind, werden sie dennochdadurch stark beeinflusst und das bestehende Berichtswesen kann eine potentielleVeränderung unterstützen oder behindern.

Die Organisationskultur besteht aus Überzeugungen, Werten und Normen, dievon den Mitgliedern der Organisation geteilt werden. Diese Überzeugungenprägen die Maßnahmen, die von einer Organisation ergriffen werden. Der Busi-ness-Analyst bewertet die Unternehmenskultur, um

• zu identifizieren, ob Änderungen in der Unternehmenskultur notwendig sind, um Ziele besser zu erreichen

• herauszufinden, ob die Stakeholder die Gründe für den Ist-Zustand verstehen und den Wert, der daraus geschaffen wird

• um festzustellen, ob die Stakeholder den Ist-Zustand als zufriedenstel-lend beurteilen oder ob eine Veränderung notwendig ist.

.3 Fähigkeiten und ProzesseFähigkeiten und Prozesse beschrieben die Aktivitäten, die ein Unternehmen aus-führt. Sie umfassen auch das Wissen, über das ein Unternehmen verfügt, dieProdukte und Dienstleistung, die es anbietet, die Funktionen, die es unterstützt,und die Methoden, die angewandt werden, um Entscheidungen zu treffen.Kernkompetenzen oder Kernprozesse beschreiben wesentliche Funktionen desUnternehmens, die das Unternehmen von den anderen unterscheidet. Sie werdenmit Hilfe von Performance-Indikatoren gemessen, um die Vorteile einer Verän-derung zu bewerten.

Der Business-Analyst kann zwei Sichtweisen einnehmen:• Eine fähigkeitsbezogene Betrachtung des Unternehmens, wenn innovative Lösungen gesucht werden, um bestehende Fähigkeiten zu kombinieren und so ein neues Ergebnis zu produzieren. Der fähigkeits-


125

bezogene Ansatz ist in diesem Fall sinnvoll, da Fähigkeiten normaler-weise funktional verteilt sind und Beziehungen zu anderen Fähigkeitenaufweisen, was die Suche nach Lücken im System vereinfacht.

• Eine prozessbezogene Betrachtung des Unternehmens, wenn eine verbesserte Leistung bei bestehenden Tätigkeiten erreicht werden soll. Der prozessbezogene Ansatz ist nützlich, da im Normalfall die Prozesseentlang Wertschöpfungsketten quer durch das Unternehmen gezogensind, um Nutzen für den Kunden zu generieren. Daher ist es leichter sicherzustellen, dass eine Veränderung wirklich die Leistung verbessert.

.4 Technologie und InfrastrukturInformationssysteme, die vom Unternehmen genutzt werden, unterstützen dieMitarbeiter dabei, Prozesse durchzuführen, Entscheidungen zu treffen und mitLieferanten und Kunden zu interagieren. Die Infrastruktur beschreibt die physi-schen Komponenten und Fähigkeiten eines Unternehmens. Diese Infrastrukturkann unter anderem IT-Ausstattung, Fabriken, Logistik und deren Betrieb undWartung beinhalten.

.5 RichtlinienGrundsätze bilden einen Entscheidungsrahmen auf den verschiedenen Ebenendes Unternehmens. Sie sind als Richtlinien im Normalfall eher für das Alltagsgeschäftals für strategische Veränderungen gedacht. Sie stellen sicher, dass die richtigenEntscheidungen getroffen werden und geben den Mitarbeitern eine Richtschnurfür erlaubte und angemessene Verhaltensweisen und Aktionen, unterstützen dieSteuerung und bestimmen, wann und wie neue Ressourcen beschafft werdenkönnen. Die Identifikation relevanter Richtlinien beeinflusst den möglichen Umfangvon Lösungen und kann auch Restriktionen für mögliche Alternativen setzen.

.6 UnternehmensarchitekturKein Bestandteil des Ist-Zustands sollte für sich isoliert betrachtet werden. DerBusiness-Analyst muss verstehen, wie alle Elemente des Ist-Zustands zusammen-passen und zusammenwirken, um effektive Veränderungen empfehlen zu können.Die vorhandene Unternehmensarchitektur erfüllt normalerweise eine Menge vonBedarfen des Unternehmens und der Stakeholder. Wenn diese Bedarfe nichterkannt werden oder in Übergangsstadien bzw. im Soll-Zustand nicht mehr erfülltwerden, bewirken Veränderungen eher eine Verschlechterung der Situation.

.7 Interne VermögenswerteDer Business-Analyst identifiziert die Vermögenswerte des Unternehmens, dieim Ist-Zustand verwendet werden. Ressourcen können materieller oder immate-rieller Natur sein, zum Beispiel finanzielle Ressourcen, Patente, ein guter Rufoder Markennamen.


126

.8 Externe BeeinflusserEs gibt externe Einflussfaktoren für das Unternehmen, die nicht Teil einer Verän-derung, aber dennoch Bedingungen, Abhängigkeiten oder Treiber für den Ist-Zustand sind.

Quellen externer Einflussfaktoren sind:• Struktur der Branche: Unterschiedliche Branchen haben unterschied-liche Wertschöpfungsketten. Das ist dann ein besonders wichtiger Ein-flussfaktor, wenn eine mögliche Veränderung darin besteht, in einer neuen Branche tätig zu werden.

• Mitbewerber: Die Art und Intensität des Wettbewerbs in unterschied-lichen Branchen kann wichtig sein. Der Eintritt eines neuen Mitbewer-bers kann eine Branche verändern oder den Wettbewerb verschärfen.

• Kunden: Größe und Art bestehender und potentieller Kundensegmen-te können Verhandlungsmacht und Preissensitivität bestimmen. Alter-nativ können auch andere Arten der Deckung des Kundenbedarfs demUnternehmen die Chance bieten, einen größeren Wert zu liefern.

• Lieferanten: Die Vielfalt und Unterschiedlichkeit von Lieferanten kann ein Einflussfaktor sein, außerdem die Macht der Lieferanten über ihre Kunden.

• Politische und regulatorische Rahmenbedingungen: Oft haben aktuelleund geplante Gesetze und Vorgaben Einfluss auf eine Branche.

• Technologie: Produktivitätsgewinne, die durch neue oder erwartete tech-nologische Innovationen möglich sind, können den Bedarf beeinflussen.

• Makroökonomische Faktoren: Einschränkungen und Chancen, die inner-halb der makroökonomischen Umwelt herrschen, können ebenfalls den Bedarf beeinflussen. (z. B. Handelsbeschränkungen, Arbeitslosigkeit, Inflation, ...)

Einige Quellen mögen unterschiedliche Begrifflichkeiten verwenden, je nach dem,ob es ein gewinnorientiertes, ein gemeinnütziges oder ein staatliches Unternehmenist. Ein Land zum Beispiel hat keine Kunden, sondern Einwohner oder Bürger.


• Business-Analyse-Ansatz: Gesamtheit der Prozesse, Regeln, Richtlinien, Erhebungen und Aktivitäten, die angewendet werden, um Business-Analyse in einem bestimmten Zusammenhang durchzuführen.

• Betriebliche Beschränkungen: Werden verwendet, um die Herausforde-rungen zu verstehen, die in einem Unternehmen gegeben sind.

• Unternehmensstrategie: Beschreibung des Weges, den ein Unternehmen gehen will, um seine Fähigkeiten zur Erreichung der Ziele einzusetzen. Siekann implizit oder explizit gelten.


127

6.1.5

• Einschränkungen der Lösung: Werden verwendet, den gegenwärtigen Zu-stand und die Herausforderungen zu verstehen, die der Ist-Zustand bietet.

• Performance-Ziele der Lösung: Sie messen die gegenwärtige Performance einer Lösung und dienen als Basis für die Zielsetzung in der Zukunft und für die Leistungsmessung.

• Maß der Lösungs-Performance: Beschreiben die aktuelle Performance bestehender Lösungen.

• Ergebnisse der Stakeholder-Analyse: Bietet eine Auflistung der Stakeholder aus dem gesamten Unternehmen, die zu Verständnis und Analyse des Ist-Zustandes beitragen.

Techniken

• Benchmarking und Marktanalyse: Werden durchgeführt, um zu verstehen,welche Möglichkeiten zur Verbesserung des Ist-Zustandes es gibt. Dazu können spezielle Frameworks genutzt werden, z.B. Branchenstruktur-analyse, PEST, STEEP, CATWOE und andere.

• Betriebliche Fähigkeitsanalyse: Identifiziert Leistungsmängel und priorisiertsie unter Berücksichtigung von Werten und Risiken.

• Darstellung des Geschäftsmodells: Beschreibt, wie ein Unternehmen Werte für seine Kunden schafft und liefert und wie es dafür entlohnt wird.

• Business Case: Liefert die Rechtfertigung für ein Vorhaben, indem es den erwarteten Nutzen einer vorgeschlagenen Lösung sichtbar macht, unter Berücksichtigung der Kosten, des zeitlichen Aufwandes und anderer Fak-toren, die notwendig sind, um diese Lösung zu erstellen und zu nutzen.

• Begrffsmodellierung: Wird verwendet, um die zentralen Begriffe und Konzepte eines Unternehmens und deren Beziehungen untereinander zu erfassen.

• Data Mining: Dient dazu, die Entscheidungsfindung zu verbessern, indem nützliche Muster und Einsichten aus Daten gewonnen werden.

• Dokumentenanalyse: Dient der Erhebung von Informationen zur Business-Analyse durch das Studium bereits vorhandener Unterlagen über rele-vante betriebliche oder außerbetriebliche Sachverhalte.

• Finanzanalyse: Dient dem Verständnis der Profitabilität des Ist-Zustands und der finanziellen Fähigkeiten Veränderungsvorhaben umzusetzen.

• Fokusgruppe: Zweck einer Fokusgruppe ist es, Feedback von Kunden oderEndverbrauchern über den Ist-Zustand zu ermitteln.

• Funktionale Gliederung: Hilft, komplexe Systeme oder Beziehungen in kleinere Einheiten zu zerlegen.


128

6.1.6

• Interviews: Dienen dazu, im Dialog mit Stakeholdern den Ist-Zustand und die sich daraus ergebenden Bedarfe zu verstehen.

• Item Tracking: Dient der Verfolgung und dem Management von Ergebnis-sen, die über den Ist-Zustand erhoben wurden.

• Lessons Learned: Dienen dazu, Fehler und Chancen zurückliegender Vorhaben zu erfassen, die eine Verbesserung von Prozessen auslösen können.

• Kennzahlen und Key-Performance-Indikatoren (KPIs): Dienen dazu, die Leistung des Ist-Zustands zu bewerten.

• Mind Mapping: Wird verwendet, um relevante Aspekte des Ist-Zustands zu ermitteln und so die relevanten Faktoren zu verstehen, die einen Bedarf beeinflussen.

• Beobachtung: Fördert Einblicke in Bedarfe, die gegenwärtig vorhanden sind, aber zuvor noch von keinem Stakeholder erkannt wurden.

• Organisationsmodellierung: Beschreibt Rollen, Verantwortlichkeiten und Berichtswege im Ist-Zustand.

• Prozessanalyse: Identifiziert Möglichkeiten, den gegenwärtigen Zustand zu verbessern.

• Prozessmodellierung: Ist die Darstellung eines Geschäftsprozesses im Ist-Zustand.

• Risikoanalyse und -management: Identifizieren Risiken, die mit dem Ist-Zustand verbunden sind.

• Ursachenanalyse: Dient dazu, die einem Problem zugrundeliegenden Auslöser zu ermitteln und zu bewerten und daraus einen Bedarf zu ermitteln.

• Scope-Modellierung: Trägt dazu bei, die Grenzen der Beschreibung des Ist-Zustandes festzulegen.

• Umfrage oder Fragebogen: Werden verwendet, um von einer großen Anzahl unterschiedlicher Befragter Informationen zu erheben.

• SWOT-Analyse: Ist eine Technik, um Stärken und Schwächen, Chancen und Risiken einer Organisation zu ermitteln.

• Anbieter-Assessment: Dient dazu, die Fähigkeit von aktuellen Lieferanten einzuschätzen, inwieweit diese eingegangene Verpflichtungen einhalten oder ob einzelne Veränderungen notwendig sind.

• Workshops: Bringen Stakeholder zusammen, um gemeinsam den Ist-Zustandund ihre Bedarfe zu beschreiben.


129

Stakeholder

• Kunde: Er nutzt die bestehende Lösung und könnte darüber Auskunft eben.

• Fachexperte: Er besitzt Fachwissen über einige Aspekte des Ist-Zustandes.• Anwender: Setzt die bestehenden Lösungen unmittelbar ein und kann darüber Auskunft geben.

• Umsetzungsexperte: Er kennt einige Aspekte des Ist-Zustands.• Support: Er ist direkt daran beteiligt, die betrieblichen Operationen zu unterstützen, und kann Auskunft darüber geben, wie gut diese Opera-tionen in der bestehenden Lösung unterstützt werden.

• Projektmanager: Er kann Informationen über den Ist-Zustand für seine Planung verwenden.

• Regulierer: Er kann Interpretationen relevanter Regelungen liefern, die sich auf die Unternehmenspolitik, Geschäftsregeln, Verfahren oder Rollenverantwortlichkeiten in dem gegenwärtigen Zustand beziehen.

• Sponsor: Er kann relevante Informationen über die Performance beste-hender Lösungen liefern.

• Lieferant: Er kann als Externer Einfluss auf den Ist-Zustand haben.• Tester: Er kann Informationen über Probleme des Ist-Zustands liefern.

Outputs

• Beschreibung des Ist-Zustands: Die Beschreibung des Kontexts eines Unternehmens, seiner Fähigkeiten, Ressourcen, Kultur, Leistung, Abhän-gigkeiten, Infrastruktur, externen Einflussfaktoren und der wesentlichen Beziehungen zwischen diesen Elementen.

• Betriebliche Anforderungen: Probleme, Chancen oder Einschränkungen, die auf der Grundlage des Verständnisses der aktuellen Situation definiert wurden.

Soll-Zustand definieren

Zweck

Die Aufgabe „Soll-Zustand definieren“ dient dazu, die Bedingungen zu definieren,die notwendig sind, um den betrieblichen Bedarf zu erfüllen.

Strategische AnalyseSoll-Zustand definieren

130

6.1.8

6.1.7

6.2.1

6.2

Beschreibung

Jede sinnvolle Veränderung setzt auch voraus, dass klar formuliert ist, was alsErfolg anzusehen ist. Der Business-Analyst hat dafür zu sorgen, dass der Soll-Zustand des Unternehmens hinreichend definiert ist, dass die Veränderung mitden verfügbaren Ressourcen möglich ist und dass die Stakeholder eine gemein-same und übereinstimmende Sicht auf das gewünschte Ergebnis haben. Wiebei der Analyse des Ist-Zustandes geht es nicht darum, dass der Soll-Zustandbereits so definiert ist, dass sofort mit der Umsetzung begonnen werden kann.Der Soll-Zustand wird in einem solchen Detaillierungsgrad definiert, dass

• unterschiedliche Strategien zur Erreichung des Soll-Zustands identifi-ziert und bewertet werden können

• eine klare Definition der Ergebnisse, die den betrieblichen Bedarf erfüllen, vorliegt

• die Rahmenbedingungen für den Umfang möglicher Lösungen spezifiziert sind

• der Nutzen, der mit dem Ziel-Zustand erreicht wird, bewertet werden kann

• Konsens unter den zentralen Stakeholdern erreicht wird.

Die Beschreibung des Soll-Zustandes kann jeden relevanten Sachverhalt des vor-geschlagenen Soll-Zustandes enthalten. Sie enthält die neuen, die beseitigten unddie veränderten Bestandteile des Unternehmens. Dazu können auch Änderungenan den Grenzen des Unternehmens gehören, wie zum Beispiel der Eintritt in einenneuen Markt oder der Kauf eines anderen Unternehmens. Zum Soll-Zustandkönnen aber auch kleine, einfache Änderungen an bestehenden Unternehmens-teilen gehören, wie zum Beispiel die Anpassung eines Prozessschrittes oder dieEntfernung eines Elementes aus einer bestehenden Applikation. Eine Veränderungkann in jedem Unternehmensteil notwendig sein, unter anderem in:

• Geschäftsprozessen• Funktionen• Organisationsstrukturen• Kompetenzen der Mitarbeiter• Wissen und Fertigkeiten• Trainings• Fabriken/Betriebsstätten• Desktop-Werkzeugen• Standorten• Daten und Informationen• Applikationen und/oder

• der IT-Infrastruktur.

Strategische Analyse Soll-Zustand definieren

131

6.2.2

Die Beschreibung kann graphische Modelle und Text enthalten, um die Abgren-zung des Umfangs und andere Details zu beschreiben. Relevante Beziehungenzwischen Entitäten werden identifiziert und beschrieben. Der für die Beschreibungdes Soll-Zustands notwendige Aufwand ist abhängig von der Art der Veränderung.Die erwarteten Ergebnisse einer Veränderung können quantitativ definiert odergrob formuliert sein. Mit der Beschreibung des Soll-Zustandes können die Stake-holder den potentiellen Nutzen einer Lösung erkennen und verstehen; ein wich-tiges Element, um den Entscheidungsprozess zu erleichtern. Bringt eine Verän-derung vorhersehbare Ergebnisse und einen vorhersehbaren Nutzen oder gibtes eine Vielzahl von möglichen Veränderungen, die Nutzen stiften können, istdie Analyse des Soll-Zustandes wichtig, um Informationen für die Wahl der ambesten geeigneten Option zu haben. Ist es schwierig, den künftigen Nutzen zuprognostizieren, kann der Soll-Zustand durch geeignete Performance-Werte defi-niert werden (um gemeinsam vereinbarte Maßstäbe für den angestrebten betrieb-lichen Wert zu haben). Die Change-Strategie sieht dann vor, die unterschiedlichenOptionen zu untersuchen.

Inputs

• Betriebliche Anforderungen: Das sind die Probleme, Chancen oder Ein-schränkungen, die mit dem Soll-Zustand abgebaut werden sollen.


132

6.2.3

Abb. 6.2.1: Input-Output-Diagramm „Soll-Zustand definieren“


133

Input


BetrieblicheZiele

6.2

Soll-Zustand definieren6.2

Output



6.2

Beschreibung des Ist-Zustands

Unternehmensstrategie

Kennzahlen und Key-Performance-Indikatoren



6.2

Aufgaben, die diesenOutput verwenden

Planen derEinbindung der

Stakeholder

3.2

Risikenbewerten

6.3

Nutzenpotentialanalysieren und

Lösung empfehlen

7.6


beurteilen

8.4



6.4


Lösung empfehlen

7.6

Leistungskenn-zahlen analysieren

8.2

PotentiellerNutzen

6.2

Erhebungvorbereiten


managen


managen

4.5

Erhebungvorbereiten

4.1Risiken

bewerten

6.3

Risikenbewerten

6.3

Anforderungenvalidieren

7.3Anforderungen

validieren

7.3


7.3


Lösung empfehlen

7.6


7.5Lösungs-Perfor-mance messen

8.1

8.1


8.2Einschränkungen

des Unternehmensbeurteilen

8.4

Maßnahmen zur Stei-gerung des Nutzensder Lösung empfehlen

8.5

Lösungs-Perfor-mance messen

Elemente

.1 Betriebliche Ziele und LeitlinienEin Soll-Zustand kann anhand von betrieblichen Zielen beschrieben werden, umder Entwicklung der Change-Strategie eine Richtung zu geben und den poten-tiellen Nutzen zu identifizieren. Betriebliche Ziele beschreiben, was das Unter-nehmen zu erreichen versucht. Ziele können Veränderungen betreffen, die eineOrganisation erreichen möchte, oder auch bestehende Zustände, die eine Orga-nisation bewahren möchte.

Ziele sind längerfristige und qualitative Beschreibungen von Zuständen oderUmständen, die das Unternehmen erreichen oder bewahren will. Beispiele fürbetriebliche Ziele sind unter anderem:

• Schaffen einer neuen Leistung, z.B. eine neue Dienstleistung oder ein neues Produkt, Behebung eines Wettbewerbsnachteils oder schaffen eines neuen Wettbewerbsvorteils

• Gewinnerhöhung, z.B. durch Umsatzsteigerung oder Reduktion von Kosten

• Verbesserung der Kundenzufriedenheit• Verbesserung der Mitarbeiterzufriedenheit• Erfüllung neuer regulatorischer Bestimmungen• Erhöhung der Sicherheit• Verkürzung der Lieferzeit eines Produktes oder einer Dienstleistung.

Abstrakte Ziele können in konkrete Ziele untergliedert werden, die zu denerwünschten Ergebnissen führen sollen, z.B. gesteigerte Kundenzufriedenheit,operative Exzellenz und Wachstum. Ein Ziel könnte beispielsweise sein „Steigerungder Anzahl der Kunden mit hohen Umsätzen“, dieses könnte detailliert werdenzu „Erhöhung der Anzahl der Kunden mit hohen Umsätzen im Segment der30- bis 45-Jährigen um 30% in den nächsten 6 Monaten.“

Im Zuge der Analyse werden die Ziele zu verständlichen, granularen und spezifi-schen Vorgaben, die mit Kennzahlen verbunden sind, mit deren Hilfe dann derErfolg objektiv bewertet werden kann. Messbare Vorgaben helfen Teams zuerkennen, ob die Bedarfe erfüllt wurden und ob eine Veränderung den gewünsch-ten Effekt bewirkt hat. Messbare Zielgrößen sind oft sehr wichtig, um eine Ver-änderung zu begründen. Sie stellen meist auch ein wesentliches Element fürden Business Case einer Veränderung dar. Ein bewährter Test für die Eignungvon Zielgrößen ist die SMART-Formel:

• Spezifisch (Specific): Beschreibt etwas, das ein beobachtbares Ergebnis hat• Messbar (Measurable): Das Ergebnis ist messbar• Erreichbar (Achievable): Das Ergebnis muss mit den verfügbaren Ressourcen erreichbar sein


134

6.2.4

• Relevant (Relevant): Das Ergebns muss abgestimmt sein mit Vision, Mission und Zielen des Unternehmens

• Zeitraumbegrenzt (Time-bounded): Das Ergebnis muss in einem für den Bedarf angemessenen Zeitraum erreicht werden.

.2 Scope des LösungsraumesEs muss im Vorfeld abgeklärt werden, welches Spektrum an Lösungen für dieErfüllung der betrieblichen Ziele in Betracht gezogen wird. Der Umfang desLösungsraums ist ein Einflussfaktor dafür, welche Optionen als mögliche Lösungs-ansätze in Frage kommen. Zu den möglichen Lösungsansätzen gehören unteranderem Änderungen von Organisationsstruktur und -kultur, Fähigkeiten und Pro-zessen, Technologien und Infrastruktur, Unternehmenspolitik, des Portfolios (neueProdukte und Dienstleistungen) oder auch der Aufbau von Beziehungen zu anderenOrganisationen, die außerhalb des Unternehmens angesiedelt sind. Solche Lösungs-ansätze erfordern spezielle Kenntnisse des Business-Analysten wie auch des Pro-jektteams. Die Analyse kann auf unterschiedlichen Ebenen im Unternehmen erfol-gen und die Betrachtungsebene ist nicht immer abhängig von der Größe derÄnderung. So kann es sogar bei kleinen Änderungen notwendig sein, zu über-prüfen, ob sie mit den Zielen des Gesamtunternehmens verträglich sind.

Wenn unterschiedliche Lösungsansätze den betrieblichen Bedarf und die Zieleerfüllen, muss entschieden werden, welche Lösungsansätze in die nähere Auswahlgelangen. Diese Entscheidung wird normalerweise aufgrund des Nutzens fürdie Stakeholder getroffen und setzt voraus, dass die möglichen Change-Strategienverstanden werden. Die wesentlichen Entscheidungskriterien sind abhängig vondem generellen Zielsystem des Unternehmens, müssen aber zusätzlich den qua-litativen und quantitativen Nutzen jeder Option, die Zeit, die für den Übergangin den Soll-Zustand benötigt wird, und die für das Unternehmen entstehendenOpportunitätskosten berücksichtigen.

.3 RestriktionenRestriktionen beschreiben Aspekte des Ist- und des Soll-Zustands, die nicht durchdie Lösung verändert werden dürfen oder es sind verpflichtende Elemente desDesigns der Lösung.

Restriktionen sind:• Budgetäre Einschränkungen• Zeitbeschränkungen• Technologie• Infrastruktur• Unternehmenspolitik• Obergrenzen der verfügbaren Ressourcen• Qualifikation der Mitglieder im Team und der Stakeholder


135

• Vorgaben, dass gewisse Stakeholder durch die Umsetzung nicht betroffen sein dürfen

• Erfüllung regulatorischer Bestimmungen• jede andere Einschränkung.

.4 Organisationsstruktur und -kulturDie formellen und informellen Arbeitsbeziehungen, die in einem Unternehmenexistieren, müssen eventuell geändert werden, um den Soll-Zustand zu ermögli-chen. Änderungen bei den Weisungsbefugnissen können Teams dazu motivieren,enger zusammenzuarbeiten und zielgerichteter vorzugehen. Elemente der Orga-nisationsstruktur und -kultur müssen eventuell geändert werden, um den Soll-Zustand zu erreichen. Die Beschreibung des Soll-Zustands gibt schon Hinweisedarauf, welche möglichen Konflikte, Auswirkungen und Grenzen relevant werdenkönnen.

.5 Fähigkeiten und ProzesseNeue Aktivitäten oder notwendige Anpassungen von Prozessen müssen identi-fiziert werden. Neue und geänderte Fähigkeiten und Prozesse werden notwendigsein, wenn neue Produkte oder Dienstleistungen angeboten werden, wenn neuegesetzliche Vorschriften zu erfüllen sind oder wenn die Leistung des Unternehmensverbessert werden soll.

.6 Technologie und InfrastrukturWenn der aktuelle Stand der Technologie und der Infrastruktur nicht ausreichendist, um den betrieblichen Bedarf zu erfüllen, dann ermittelt der Business-Analystdie Veränderungen, die erforderlich sind, um den Soll-Zustand zu erreichen.

Die bestehende Infrastruktur kann zu technischen Einschränkungen für dasDesign einer Lösung führen. Das können zum Beispiel Programmiersprachen,Hardware- und Softwareumgebungen oder Applikations-Software sein, die ver-wendet werden müssen. Technische Einschränkungen können auch der maximaleVerbrauch an Ressourcen, Größe und Timing von Nachrichten, der Leistungs-umfang der Software, Speichergrößen, Dateigrößen oder die maximale Mengeder Datenelemente sein. Zu den technischen Einschränkungen gehören auchalle Richtlinien und Standards der IT-Architektur.

.7 Unternehmenspolitische VorgabenWenn die aktuellen Vorgaben der Erfüllung des betrieblichen Bedarfs im Wegestehen, dann identifiziert der Business-Analyst die notwendigen Veränderungen,um den Soll-Zustand erreichen zu können.

Unternehmenspolitische Vorgaben sind eine häufige Quelle von Einschränkungenfür eine Lösung oder für den verfügbaren Lösungsraum. Sie bestimmen, welche


136

Lösungen welche Zuständigkeiten berühren, wie der Prozess für die Freigabeeiner Lösung aussieht und welche Kriterien eine vorgeschlagene Lösung erfüllenmuss, um dafür ein Budget freizugeben. In manchen Fällen ermöglicht eine Ver-änderung von Vorgaben auch, dass alternative Lösungen anwendbar werden,die anderenfalls nicht berücksichtigt worden wären.

.8 UnternehmensarchitekturDie Elemente eines Soll-Zustands müssen effektiv zusammenwirken und dazubeitragen, die betrieblichen Ziele zu erreichen. Zusätzlich sollten Sie in den Soll-Zustand des gesamten Unternehmens hineinpassen.

.9 Interne RessourcenDie Analyse der Ressourcen zeigt möglicherweise auf, dass bestehende Ressourcenerweitert, Fertigkeiten entwickelt oder neue Ressourcen geschaffen werdenmüssen. Im Zuge der Analyse der Ressourcen untersucht der Business-Analyst,welche Ressourcen benötigt werden, um den Ist-Zustand aufrecht zu erhalten,welche notwendig sind, um die Change-Strategie umzusetzen, und welche Res-sourcen im Soll-Zustand notwendig sein werden. Die Analyse vorhandener undkünftig notwendiger Ressourcen findet im Rahmen von Machbarkeitsstudienfür mögliche Lösungsansätze statt.

.10 Annahmen identifizierenDie meisten Strategien beruhen auf Annahmen, die für den Erfolg einer Strategieentscheidend sind, insbesondere wenn es sich um ein ungewisses und schwerabschätzbares Umfeld handelt. Es ist oftmals schwierig bis unmöglich, zu bewei-sen, dass der gewünschte Erfolg tatsächlich eintreten wird, auch wenn einebestimmte Annahme plausibel erscheint. Die gemachten Annahmen müssenbewusst gemacht und verstanden werden, damit entsprechende Maßnahmengetroffen werden können, falls sich die Annahme als falsch herausstellen sollte.Change-Strategien in unklaren Umfeldern können so strukturiert werden, dasssolche Annahmen möglichst frühzeitig getestet werden, um gegebenenfalls einVorhaben entsprechend anzupassen oder abzubrechen.

.11 Potentieller WertDie Erfüllung betrieblicher Ziele allein rechtfertigt nicht den Übergang in einenSoll-Zustand; zusätzlich muss der potentielle Wert einer Veränderung bewertetwerden, um zu prüfen, ob dieser erwartete Wert ausreichend ist.

Im Rahmen der Definition des Soll-Zustands ermittelt der Business-Analyst denpotentiellen Wert einer Lösung. Der potentielle Wert einer Lösung ist der Netto-Zugewinn durch die Lösung, nachdem die dafür erforderlichen Kosten des Betriebsabgezogen wurden. Ein Change muss einen größeren Wert für das Unternehmenerwirtschaften als er ohne diese Maßnahmen gewesen wäre. Es kann passieren,


137

dass der Soll-Zustand für bestimmte Stakeholder oder für das Unternehmen alsGanzes zu einer Verschlechterung führt. Zum Beispiel müssen neue gesetzlicheRegelungen oder ein verschärfter Wettbewerb für den Fortbestand des Unter-nehmens berücksichtigt werden, die sich dann aber negativ auf den Wert aus-wirken.

Wenn der Business-Analyst den Soll-Zustand bestimmt, beachtet er möglicheEinflüsse hinsichtlich zunehmender oder abnehmender Werte, die sich ergebenkönnen durch

• externe Chancen, die erst durch die Analyse der externen Einflüsse aufgedeckt wurden

• zuvor unbekannte Stärken von neuen Partnern• neue Technologien oder neues Wissen• den potentiellen Wegfall eines Mitbewerbers • erzwungene Umsetzung einer Veränderungskomponente.

Der Business-Analyst ermittelt die jeweiligen Wahrscheinlichkeiten für möglicheWertveränderungen wie auch für die Steigerung dieser Werte in Bezug auf ein-zelne Lösungskomponenten. Er schätzt einen potentiellen Gesamtwert, indemer die Einzelschätzungen aggregiert.

Der potentielle Wert, inklusive der Details der erwarteten Nutzen und Kostenund die wahrscheinliche Konsequenz, wenn keine Veränderung durchgeführtwürde, sind Schlüsselkomponenten, um den Business Case für ein Vorhaben zuformulieren. Aufstellungen, aus denen der aktuell erwirtschaftete Wert im Ver-gleich mit dem künftig erzielbaren Wert sichtbar wird, ermöglichen es den Sta-keholdern, die erwarteten Wertzuwächse zu verstehen. Meistens wird der Soll-Zustand nicht alle Möglichkeiten für Verbesserung berücksichtigen. Alle nichtbehandelten Chancen bleiben aber als Kandidaten für künftige Verbesserungenbestehen und sollten entsprechend dokumentiert werden.

Zusätzlich zum potentiellen Wert sollten aus der Analyse auch Investitionsbeträgeersichtlich sein, die notwendig sind, um unterschiedliche Soll-Zustände zu errei-chen. Während die tatsächliche Investition von der Change-Strategie abhängt,können diese Informationen dazu beitragen, zwischen unterschiedlichen Stra-tegien auszuwählen.


• Beschreibung des Ist-Zustands: Beschreibt den Kontext, in dem die Aufgaben erfüllt werden müssen und ist oft der Ausgangspunkt für den Soll-Zustand.

• Kennzahlen und Key-Performance-Indikatoren (KPIs): Key-Performance-Indikatoren und Kennzahlen werden verwendet, um festzustellen, ob der gewünschte Soll-Zustand erreicht wurde.


138

6.2.5

• Unternehmensstrategie: Sie beschreibt den Weg, die Methoden oder den Ansatz, den ein Unternehmen oder eine Organisation verfolgen wird, um einen gewünschten Soll-Zustand zu erreichen. Diese Beschreibung kann explizit oder implizit sein.

Techniken

• Akzeptanz- und Bewertungskriterien: Werden verwendet, um solche Tatbestände zu ermitteln, die dafür sorgen, dass der zukünftige Zustand akzeptiert wird oder von Lösungsoptionen zu bewerten.

• Balanced Scorecard: Wird verwendet, um Ziele zu setzen, an denen die spätere Lösung gemessen werden kann.

• Benchmarking und Marktanalyse: Werden durchgeführt, um Entschei-dungen über die zukünftigen betrieblichen Ziele zu fällen.

• Brainstorming: Verfahren zur Sammlung von Ideen für die zukünftige Lösung.

• Betriebliche Fähigkeitsanalyse: Identifiziert Leistungsmängel und priorisiertsie unter Berücksichtigung von Werten und Risiken.

• Business Case: Liefert die Rechtfertigung für ein Vorhaben, indem es den erwarteten Nutzen einer vorgeschlagenen Lösung sichtbar macht.

• Begriffsmodellierung: Wird verwendet, um die Strategie eines Unter-nehmens zu planen, indem die benötigte Infrastruktur, die angestrebte Kundengruppe, die Kostenstruktur und die Erlösflüsse erfasst werden, dienotwendig sind, um das Nutzenversprechen für den Kunden im ange-strebten Soll-Zustand einhalten zu können.

• Entscheidungsanalyse: Wird verwendet, um verschiedene zukünftige Lösungsmöglichkeiten zu vergleichen, und zu verstehen, welche die beste Lösung sein dürfte.

• Finanzanalyse: Dient dazu, die finanziellen Auswirkungen einer zukünfti-gen Lösung zu verstehen.

• Funktionale Gliederung: Dient dazu, komplexe Systeme der zukünftigen Lösung in ihre kleineren Bestandteile zu zerlegen, um sie so besser zu verstehen.

• Interviews: Werden verwendet, um mit Stakeholdern zu sprechen und damit den gewünschten zukünftigen Zustand, die zu erfüllenden Bedarfe und die damit verfolgten betrieblichen Ziele zu verstehen.

• Lessons Learned: Dienen dazu, aus Erfahrungen, die in der Vergangenheitgemacht wurden, abzuleiten, welche Verbesserungsmöglichkeiten ange-gangen werden sollen und wie der gegenwärtige Zustand verbessert werden kann.


139

6.2.6

• Kennzahlen und Key-Performance-Indikatoren (KPIs): Dienen dazu, festzu-stellen, wann es gelungen ist, die betrieblichen Ziele zu erreichen.

• Mind Mapping: Wird dazu verwendet, Ideen für den Soll-Zustand zu entwickeln.

• Organisationsmodellierung: Wird dazu verwendet, Rollen, Verantwort-lichkeiten und Berichtsstrukturen für den zukünftigen Zustand zu beschreiben.

• Prozessmodellierung: Wird verwendet, um zukünftige Arbeitsabläufe darzustellen.

• Prototyping: Wird verwendet, um zukünftige Lösungen zu modellieren. Es kann auch für die Ermittlung des möglichen Wertbeitrags hilfreich sein.

• Scope-Modellierung: In Scope-Modellen werden die Grenzen für den zukünftigen Soll-Zustand definiert.

• Umfrage oder Fragebogen: Wird verwendet, um zu erheben, welchen zukünftigen Zustand die Stakeholder wünschen, welche Bedarfe damit angesprochen und welche betrieblichen Ziele damit angestrebt werden.

• SWOT-Analyse: Ist eine Technik, um Stärken und Schwächen, Chancen und Risiken der zukünftigen Lösung zu ermitteln.

• Anbieter-Assessment: Dient dazu, den Nutzen einzuschätzen, den mög-liche zukünftige Lieferanten bringen können.

• Workshops: Bringen Stakeholder zusammen, um gemeinsam den zukünf-tigen Zustand zu beschreiben.

Stakeholder

• Kunde: Er ist ein möglicher Nutzer oder Käufer der zukünftigen Lösung und könnte über seine Bereitschaft Auskunft geben, ob er willens oder in der Lage ist, die neue Lösung zu nutzen.

• Fachexperte: Er besitzt Fachwissen über einige Aspekte des Ist-Zustan-des und möglicher zukünftiger Zustände.

• Anwender: Setzt die bestehenden Lösungen unmittelbar ein oder ist Bestandteil der späteren Lösung und kann darüber Auskunft geben, ob er bereit ist, sie zu nutzen.

• Umsetzungsexperte: Er kann darüber Auskunft geben, ob mit der Lösung der gewünschte zukünftige Zustand erreicht werden kann.

• Support: Er ist direkt daran beteiligt, die betrieblichen Operationen zu unterstützen, und kann Auskunft darüber geben, wie gut diese Opera-tionen von der zukünftigen Lösung unterstützt werden.

• Projektmanager: Er kann Informationen darüber geben, wie eine vernünf-tige und beherrschbare zukünftige Lösung aussehen könnte.


140

6.2.7

• Regulierer: Er ist dafür zuständig, dass relevante Regelungen und Gesetze im zukünftigen Zustand eingehalten werden. Interpretationen relevanter Regelungen müssen in die Beschreibung einfließen und finden sich in der Unternehmenspolitik, in Geschäftsregeln, Verfahren oder Rollenverant-wortlichkeiten.

• Sponsor: Er kann festlegen, welche betrieblichen Bedarfe erfüllt werden sollen und welche Ziele für den Soll-Zustand gelten. Er bewilligt die Vor-haben und sichert die Finanzierung.

• Lieferant: Er kann an der Erarbeitung der zukünftigen Lösung mitwirken oder Teile der zukünftigen Lösung bereitstellen.

• Tester: Er ist dafür zuständig, dass der gewünschte zukünftige Zustand hinreichend auf seine Funktionsweise und Qualität getestet wird.

Outputs

• Betriebliche Ziele: Sie zeigen die gewünschte Richtung, in die das Unter-nehmen gehen will, um den Soll-Zustand zu erreichen.

• Beschreibung des Soll-Zustands: Zur Beschreibung des Soll-Zustands gehören die Grenzen der neuen, eliminierten und veränderten Kompo-nenten und der potentielle Wert, der vom Soll-Zustand erwartet wird. Die Beschreibung kann die künftig gewünschten Fähigkeiten, politischen Vorgaben, Ressourcen, Abhängigkeiten, Infrastruktur, externe Einflüsse und die Beziehungen zwischen diesen Aspekten enthalten.

• Potentieller Nutzen: Das ist der Nutzen, der durch die Implementierung des Soll-Zustandes erwirtschaftet werden soll.

Risiken bewerten

Zweck

Der Zweck der Risikobewertung liegt darin, die unerwünschten Wirkungen voninternen und externen Kräften auf das Unternehmen während eines Übergangsund im Soll-Zustand zu verstehen. Das Verständnis der potentiellen Auswirkungenkann zu Empfehlungen hinsichtlich des weiteren Vorgehens führen.

Beschreibung

Risikobewertung schließt die Analyse und das Management der Risiken ein. Risikenkönnen in Bezug auf den Ist-Zustand, den erwünschten Soll-Zustand, den Changeselbst, die Change-Strategie oder jede andere Tätigkeit im Unternehmen bestehen.

Strategische Analyse Risiken bewerten

141

6.2.8

6.3

6.3.1

6.3.2

Risiken werden analysiert im Hinblick auf • potentielle Konsequenzen, wenn das Risiko eintritt• Auswirkungen dieser Konsequenzen• die Wahrscheinlichkeit, dass ein Risiko auftritt• den potentiellen Zeitraum, in dem das Risiko eintreten kann.

Eine Sammlung von Risiken wird für die Auswahl oder Koordination der Change-Strategie genutzt. Eine Risikobewertung kann vorsehen, den Eintritt des Risikoszu akzeptieren, sofern der Aufwand zur Bewältigung höher wäre als die möglicheEinbuße. Wenn die Risiken verstanden wurden und das Vorhaben weiterverfolgtwird, können die Risiken angegangen werden, um die gesamten Auswirkungenauf den potentiellen Nutzen möglichst gering zu halten.

Einige Methoden enthalten das Konzept der „positiven Risiken“, um mit Chancenumzugehen. Obwohl die formale Definition von Risiko im BABOK® Guide dieseArt und Weise Risiko zu behandeln nicht ausschließt, werden Chancen hier alsBedarfe angesehen (und entsprechend behandelt). Risiko wird für ungewisseGegebenheiten verwendet, die negative Ergebnisse zur Folge haben können.

Inputs

• Betriebliche Ziele: Sie beschreiben die vorgesehene Richtung, die einge-schlagen wird, um den Soll-Zustand zu erreichen, und können verwendet werden, um potentielle Risiken zu identifizieren und zu bewerten.

• Erhebungsergebnisse (bestätigt): Sie bieten ein Verständnis dafür, was unterschiedliche Stakeholder als Risiken für die Erreichung des Soll-Zustands ansehen.

• Einflüsse: Faktoren innerhalb und außerhalb des Unternehmens, die die Erreichung des Soll-Zustands beeinflussen.

• Potentieller Nutzen: Der Nutzen, der durch die Implementierung des Soll-Zustands erreicht werden kann, ist eine Messgröße, die zur Bewertung von Risiken herangezogen werden kann.

• Anforderungen (priorisiert): Abhängig von der Priorität beeinflussen die Anforderungen die Risiken und werden als Teil der Lösung betrachtet.

Strategische AnalyseRisiken bewerten

142

Wichtig

6.3.3

Abb. 6.3.1: Input-Output-Diagramm „Risiken bewerten“


143

Input


Risiken bewerten

6.3

Output




Unternehmenspolitik

Change-Strategie

Einflüsse Erhebungs-ergebnisse(bestätigt)

4.3


managen

4.5


5.3Anforderungen

(priorisiert)

5.3

BetrieblicheZiele

6.2 Potientieller

Nutzen

6.2


6.3


6.4

Einschränkungender Lösungbeurteilen

8.3


Lösung empfehlen

7.6


Identifizierte Risiken

Ansatz der Einbindungder Stakeholder


8.2Einschränkungen


8.4

Elemente

.1 UngewissheitenWenn ein Risiko bewertet wird, gibt es einerseits die Unsicherheit hinsichtlichder Wahrscheinlichkeit, dass das Risiko tatsächlich eintritt und andererseits hin-sichtlich der Auswirkungen dieses Risikos. Der Business-Analyst arbeitet mit Stake-holdern zusammen, um die Risiken aufgrund ihrer aktuellen Einschätzung zubewerten. Selbst wenn nicht eindeutig vorhergesagt werden kann, was allesaufgrund einer bestimmten Change-Strategie passieren wird, ist es trotzdemmöglich, die Auswirkungen von ungewissen oder unbekannten Ereignissen oderSituationen abzuschätzen. Der Business-Analyst zieht ähnliche Situationen ausder Vergangenheit heran, um Risiken zu bewerten. Die Lessons Learned ausvergangenen Vorhaben und Fachwissen von Stakeholdern helfen dem Business-Analysten bei der Einschätzung, welche Wahrscheinlichkeiten und welche Aus-wirkungen die Risiken der Veränderung in sich tragen.

.2 Einschränkungen, Annahmen und AbhängigkeitenRestriktionen, Annahmen und Abhängigkeiten können auf Risiken hin untersuchtund unter Umständen als eigene Risiken behandelt werden. Wenn ein Risiko,eine Annahme oder eine Abhängigkeit mit einem Aspekt eines Veränderungs-vorhabens in Beziehung steht, dann kann es als Risiko formuliert werden, indem das Ereignis, die Bedingung oder die Auswirkung ermittelt wird, die durchdie Restriktion, Annahme oder Abhängigkeit verursacht werden könnte.

.3 Negative Auswirkungen auf den WertRisiken werden als Bedingungen formuliert, die die Wahrscheinlichkeit oder dieWirkung einer negativen Auswirkung auf den potentiellen Wert einer Veränderungerhöhen. Der Business-Analyst identifiziert und beschreibt jedes Risiko und schätztdie Wahrscheinlichkeit und die Auswirkungen, um ein bestimmtes Risikoniveauzu bestimmen. Er schätzt das Niveau des Gesamtrisikos auf Grund der zusam-mengesetzten Risiken. So wird eine Einschätzung der Gesamtauswirkungen derbewerteten Risiken möglich. In manchen Fällen kann das Gesamtrisiko in finanziellenGrößen, im Zeitaufwand oder in anderen Maßstäben dargestellt werden.

.4 RisikobereitschaftRisikobereitschaft ist das Ausmaß der Unsicherheit, die ein Stakeholder oder einUnternehmen zu ertragen bereit ist, um einen potentiellen Wert zu erreichen.

Generell gibt es drei grobe Einteilungen der Risikobereitschaft:• Risikovermeidung: Hier fehlt die Bereitschaft, Unsicherheiten zu akzep-tieren; es werden entweder riskante Handlungsweisen vermieden oder es wird lieber mehr investiert (und damit letztlich ein niedrigerer poten-tieller Wert erwirtschaftet), um Risiken zu minimieren.


144

6.3.4

• Neutralität: Ein bestimmtes Risikoniveau wird akzeptiert, sofern die Handlungsweise keinen Verlust bedeutet, wenn das Risiko eintritt.

• Risikofreude: Es besteht eine hohe Bereitschaft, Risiken zu akzeptieren oder sogar noch höhere Risiken einzugehen, wenn damit ein höherer potentieller Wert erreicht werden kann.

Eine Einzelperson oder eine Organisation kann zu verschiedenen Zeiten unter-schiedliche Stufen der Risikobereitschaft zeigen. Wenn die Risikobereitschaftgering ist, wird mehr Aufwand in Vermeidungs-, Verschiebungs- oder Bewälti-gungsstrategien gesteckt. Ist die Risikobereitschaft hoch, werden mehr Risikenakzeptiert. Typischerweise werden die Risiken mit der größten Wahrscheinlichkeitoder den stärksten Auswirkungen immer behandelt, unabhängig von der indivi-duellen Risikobereitschaft.

.5 EmpfehlungAufgrund der Risikobewertung gibt der Business-Analyst eine Handlungsemp-fehlung ab. Er arbeitet mit den Stakeholdern zusammen, um das Gesamtrisikound die Risikobereitschaft einschätzen zu können.

Die Empfehlung fällt normalerweise in eine der nachstehenden Kategorien:• Verfolgung der Vorteile einer Veränderung ohne Berücksichtigung der Risiken

• Verfolgung der Vorteile einer Veränderung mit zusätzlichen Investitio-nen in die Risikominimierung (Eintrittswahrscheinlichkeit und/oder Auswirkungen)

• Suche von Ansätzen, die dafür sorgen, dass die Vorteile der Verände-rung die Risiken überwiegen

• Suche von Ansätzen, um Chancen zu ergreifen und zu optimieren. • keine Veränderungen anstreben.

Wenn die Veränderung in Kauf genommen wird und dabei Risiken bewusst ein-gegangen werden, sollten Stakeholder benannt werden, die dafür zuständigsind, Risiken und deren Auswirkungen zu beobachten und überwachen. DasRisiko kann den Ist-Zustand des Unternehmens verändern und eine Überarbeitungder Change-Strategie erfordern. In diesem Fall sollte im Vorfeld ein Aktionsplanentwickelt werden, bevor das Risiko eintritt.


• Business-Analyse-Ansatz: Er zeigt auf, wie der Business-Analyst Risiken analysiert.

• Unternehmenspolitik: Sie definiert den Handlungsspielraum von Entschei -dungen und kann Aspekte des Risikomanagements erzwingen und lenken.


145

6.3.5

• Change-Strategie: Beschreibt die Vorgehensweise, wie der Übergang vomIst-Zustand zum Soll-Zustand erfolgen soll, um die erwünschten Ergeb-nisse zu erzielen. Dieser Prozess muss bewertet werden, um die damit verbundenen Risiken zu verstehen.

• Beschreibung des Ist-Zustands: Darin wird der Kontext beschrieben, in dem die Aufgaben zu erledigen sind. Kann verwendet werden, um die Risiken, die mit dem Ist-Zustand verbunden sind, zu bestimmen.

• Beschreibung des Soll-Zustands: Er ist maßgeblich für die Risiken, die mit dem Soll-Zustand verbunden sind.

• Identifizierte Risiken: Sie entstehen aus dem Ergebnis der bisherigen Risikoanalyse, aus Erhebungsaktivitäten, aus früheren Tätigkeiten der Business-Analyse oder aus Expertenwissen und können als Ausgangs-punkt für eine vertiefende Risikobewertung verwendet werden.

• Ansatz der Einbindung der Stakeholder: Das Verständnis der Stakeholder und der Stakeholder-Gruppen hilft, die möglichen Auswirkungen von internen und externen Kräften zu identifizieren und zu bewerten.

Techniken

• Brainstorming: Dient dazu, gemeinsam Risiken zu identifizieren und ein-zuschätzen.

• Business Cases: Werden verwendet, um Risiken zu entdecken, die mit alternativen Change-Strategien verbunden sind.

• Entscheidungsanalyse: Wird verwendet, um Probleme einzuschätzen.• Dokumentenanalyse: Wird eingesetzt, um bestehende Dokumente im Hinblick auf potentielle Risiken, Restriktionen, Annahmen und Abhängig-keiten zu analysieren.

• Finanzanalyse: Wird genutzt, um die möglichen Einflüsse von Risiken auf den finanziellen Wert einer Lösung abzuschätzen.

• Interviews: Mit ihrer Hilfe kann ermittelt werden, welche potentiellen Risiken und welche damit verbundenen Effekte aus der Sicht der Stake-holder auftreten können.

• Lessons Learned: Sie können Hinweise geben auf mögliche Risiken, die sich aus zurückliegenden Vorhaben ergeben.

• Mind Mapping: Wird genutzt, um mögliche Risiken zu identifizieren und zu kategorisieren und ihre Beziehungen untereinander zu verstehen.

• Risikoanalyse und -management: Werden verwendet, um Risiken zu identifizieren und mit ihnen umzugehen.

• Ursachenanalyse: Mit ihrer Hilfe können tieferliegende Probleme ermittelt werden, die zu Risiken führen.

• Umfrage oder Fragebogen: Mit ihrer Hilfe kann ermittelt werden, welche


146

6.3.6

potentiellen Risiken und welche damit verbundenen Effekte aus der Sicht der Stakeholder auftreten können.

• Workshops: Mit ihrer Hilfe kann ermittelt werden, welche potentiellen Risiken und welche damit verbundenen Effekte aus der Sicht der Stake-holder auftreten können.

Stakeholder

• Fachexperte: Er kann auf der Basis seines Expertenwissens im Fachbereich Input zur Risikoeinschätzung liefern.

• Umsetzungsexperte: Er kann auf der Basis seines Expertenwissens im Fachbereich Input zur Risikoeinschätzung liefern.

• Support: Er ist direkt daran beteiligt, die betrieblichen Operationen zu unter-stützen und kann Risiken identifizieren und ihren Einfluss abschätzen.

• Projektmanager: Er kann Risiken einschätzen und ist verantwortlich für den Umgang mit Risiken und die Abschwächung von Wirkungen.

• Regulierer: Er kann relevante Regelungen interpretieren und die Risiken benennen, die sich aus Gesetzen, Verordnungen oder Regelungen ergeben.

• Sponsor: Er muss im Rahmen seiner Entscheidungs- und Bewilligungs-befugnisse die mit dem Vorhaben verbundenen Risiken kennen und berücksichtigen.

• Lieferant: Mit der Beauftragung von Lieferanten können Risiken verbun-den sein.

• Tester: Er identifiziert aus der Sicht der Validierung oder Verifizierung die Risiken der Change-Strategie.

Outputs

• Ergebnisse der Risikoanalyse: Die mit der Erreichung des Soll-Zustands verbunde-nen Risiken sind ebenso bekannt wie die Strategien zur Risikominimierung, die verwendet werden, um Risiken zu verhindern, die Auswirkungen von Risiken zu beschränken oder die Eintrittswahrscheinlichkeit von Risiken zu verringern.


Zweck

Bei der Entwicklung einer Change-Strategie geht es darum, alternative Vorge-hensweisen für das Veränderungsvorhaben zu entwickeln, zu bewerten unddann den bestmöglichen Ansatz auszuwählen.

Strategische Analyse Change-Strategie definieren

147

6.3.7

6.3.8

6.4.1

6.4

Beschreibung

Die Entwicklung einer Change-Strategie ist einfacher, wenn der Ist-Zustand undder zukünftige Soll-Zustand bereits definiert sind, da sie in einem unmittelbarenZusammenhang mit dem Veränderungsprozess stehen.

Die Change-Strategie bringt die Eigenschaften einer Veränderung klar zum Ausdruck:• Kontext der Veränderung• identifizierte alternative Change-Strategien• eine Begründung, warum eine bestimmte Change Strategie die Beste ist• benötigte Investionen und Ressourcen zur Erreichung des Soll-Zustands• wie das Unternehmen die gewünschten Werte realisieren kann, nach-dem die Lösung umgesetzt wurde

• zentrale Stakeholder im Rahmen des Veränderungsprozesses • Übergangszustände am Weg zum Soll-Zustand.

Die angemessene Darstellung einer Change-Strategie hängt von der Perspektivedes Change-Teams und deren Stakeholdern ab. Die Change-Strategie kann alsTeil eines Business Cases, als Statement of Work (SOW), als strategischer Planeines Unternehmens oder auf andere Art und Weise dargestellt werden.

Soll eine Change-Strategie definiert werden, müssen im Normalfall mehrere Stra-tegien ermittelt werden, aus denen dann jene Strategie ausgewählt wird, die inder momentanen Situation am besten geeignet erscheint. Es kann auch vorkommen,dass Change-Strategien im ersten Schritt nur einen Teilaspekt des gewünschtenSoll-Zustands erfüllen und daher nur Komponenten der späteren kompletten Lösungbeinhalten. Für jeden Übergangszustand auf dem Weg zum Soll-Zustand sollte dieChange-Strategie bestimmen, welche Teile der Lösung abgeschlossen sind undwelche nicht, und welche Aspekte des angepeilten Wertes erreicht werden könnenund welche nicht.

Inputs

• Beschreibung des Ist-Zustands: Sie liefert die relevanten Informationen desIst-Zustands und enthält auch Bewertungen interner und externer Ein-flüsse auf das betrachtete Unternehmen.

• Beschreibung des Soll-Zustands: Sie liefert relevante Informationen über den Soll-Zustand.

• Ergebnisse der Risikoanalyse: Dort werden die identifizierten Risiken und deren mögliche Auswirkungen beschrieben.

• Ansatz der Einbindung der Stakeholder: Sind die Bedürfnisse der Stake-holder in Bezug auf Kommunikation und Zusammenarbeit bekannt, können die für den Veränderungsprozess notwendigen Aktivitäten abgeleitet wer-den, die ein Teil der Change-Strategie werden sollen.

Strategische AnalyseChange-Strategie definieren

148

6.4.2

6.4.3

Abb. 6.4.1: Input-Output-Diagramm „Change-Strategie definieren“


149

Change-Strategie

6.4

Change-Strategie definieren6.4

Output


Design-Optionen


Lösungsempfehlungen


Planen derEinbindung der

Stakeholder

3.2Aufgaben, die diesen Output verwenden

Nutzenpotential analysieren und

Lösung empfehlen

7.6

Scope derLösung

6.4


7.5


7.3


7.5

Anforderungs-architekturdefinieren

7.4

Input


6.3


6.1


6.2


Stakeholder

3.2

Risikenbewerten

6.3

Anforderungenspezifizieren und

modellieren

7.1


5.3Änderungen von Anforderungen

beurteilen

5.4


5.5

Änderungen von Anforderungen

beurteilen

5.4


5.5


5.3Einbindung


3.2

8.1Leistungskenn-

zahlen analysieren

8.2


8.3Einschränkungen


8.4


8.2

8.1


8.3Einschränkungen


8.4




Elemente

.1 Scope der LösungDie Lösung ist das Ergebnis einer Veränderung, mit deren Hilfe ein Unternehmeneinen Bedarf erfüllen kann. Bei der Planung einer Change-Strategie könnenmehrere Lösungsmöglichkeiten untersucht und bewertet werden, der besteLösungsansatz wird begründet und ausgewählt. Der Scope der Lösung definiertdie Grenzen einer Lösung und wird so ausführlich beschrieben, dass die Stake-holder nachvollziehen können, welche neuen Fähigkeiten der Veränderungs-prozess bereitstellen wird. Der Scope der Lösung beschreibt auch, wie die vor-geschlagene Lösung die Ziele des Soll-Zustands erfüllen kann. Der Scope derLösung kann sich auch während eines Vorhabens verändern, wenn zusätzlicheInformationen bekannt werden.

Der Scope der Lösung kann auf verschiedene Arten beschrieben werden, z.B.durch:

• Fähigkeiten • Technologien• Geschäftsregeln • Betriebliche Entscheidungen• Daten • Prozesse• Ressourcen • Wissen und Fertigkeiten• Modelle/Beschreibungen von • Funktionen

Märkten • Netzwerke• Standorte • Arbeitsabläufe• Organisationsstrukturen • Folgen• Ereignisse • Geschäftslogik.• Motivationen

Um Klarheit zu schaffen, kann der Scope der Lösung auch denkbare Lösungs-aspekte beschreiben, die nicht in Frage kommen (sie sind „out-of-scope“).

.2 Gap-AnalyseDie Gap-Analyse ermittelt den Unterschied zwischen den Fähigkeiten des Ist-Zustands und des Soll-Zustands. Soll eine Gap-Analyse durchgeführt werden,müssen Ist- und Soll-Zustand definiert sein. Wird die gleiche Technik verwendet,um den Ist-Zustand und den Soll-Zustand zu beschreiben, erleichtert dies denVergleich der beiden Zustände.

Mit der Gap-Analyse können die Probleme (Lücken) identifiziert werden, die dasUnternehmen daran hindern, Bedarfe zu erfüllen und Ziele zu erreichen. DieGap-Analyse kann dazu verwendet werden, herauszufinden, ob ein Unternehmenmit den gegebenen Strukturen, Ressourcen, Fähigkeiten und Technologien inder Lage ist, die Bedarfe zu erfüllen. Ist das Unternehmen in der Lage, den


150

6.4.4

Bedarf mit den Fähigkeiten des Ist-Zustands zu erreichen, dann wird die Verän-derung wahrscheinlich relativ klein sein oder sich sogar erübrigen. Ist das nichtder Fall, wird eine Change-Strategie benötigt, um die fehlenden Fähigkeiten zuschaffen oder bestehende zu erweitern. Die Fähigkeiten, die im Rahmen derGap-Analyse betrachtet werden, sind unter anderem:

• Prozesse • Funktionen• Geschäftsfelder • Organisationsstrukturen• Kompetenzen der Mitarbeiter • Wissen und Fertigkeiten• Training • Betriebsstätten• Standorte • Daten und Informationen• Applikationen • Technologische Infrastruktur.

Abweichungen müssen sowohl in den Übergangszuständen wie auch im Soll-Zustand behandelt werden.

.3 Bewertung der Bereitschaft des UnternehmensDer Business-Analyst versucht herauszufinden, ob das Unternehmen in der Lageist, den Change durchzuführen und diesen auch im Soll-Zustand zu bewahren.Die Bewertung der Bereitschaft betrachtet also nicht nur, ob das Unternehmenin der Lage ist, den Veränderungsprozess erfolgreich zu durchlaufen. Er setztsich auch mit der Frage auseinander, ob diese Lösung nachhaltig verwendetwird, um damit Wert (Nutzen) zu schaffen. Die Bewertung schließt sowohl diekulturelle Bereitschaft der Stakeholder mit ein als auch die operative Bereitschaft,den Zeitplan, bis zu dem die Veränderung umgesetzt sein soll, einzuhalten,sowie die verfügbaren Ressourcen, um die Veränderung umzusetzen.

.4 Die Change-StrategieEine Change-Strategie ist ein eher allgemein formulierter Plan, aus dem dieAktivitäten und Ereignisse hervorgehen, die dazu beitragen, dass sich ein Unter-nehmen vom Ist-Zustand zum Soll-Zustand weiterentwickelt. Change-Strategienkönnen sich auf einzelne Initiativen beziehen, in denen mehrere kleine Vorhabenals Folge von Projekten durchgeführt werden, oder auf verschiedene laufendeVerbesserungs-Vorhaben. In diesen Fällen deckt jedes einzelne Element desChange den Bedarf nicht vollständig ab, so dass mehrere Änderungsvorhabennotwendig werden.

Im Zuge der Entwicklung einer Change-Strategie werden mehrere Optionenidentifiziert, untersucht und in dem notwendigen Detaillierungsgrad beschrieben,um untersuchen zu können, welche Optionen machbar sind. Alternativen könnenüber ein Brainstorming oder mithilfe der Befragung von Fachexperten ermitteltwerden. Weitere Ideen können aus früheren Change-Vorhaben, Strategien ausanderen Märkten oder aus Ansätzen abgeleitet werden, die von Mitbewerberngewählt wurden.


151

Aus den möglichen Optionen wird eine bevorzugte Change-Strategie ausgewähltund weiter detailliert. Bei der Auswahl der bevorzugten Strategie sollten folgendeAspekte betrachtet werden:

• die Bereitschaft des Unternehmens, den Change durchzuführen• die wesentlichen Kosten und Investitionen, die zur Umsetzung notwendig sind

• der Zeitraum, in dem die Veränderung umgesetzt werden soll• der Abgleich mit den betrieblichen Zielen• der Zeitraum bis zu dem der entsprechende Wert erzeugt wird• Opportunitätskosten der Change-Strategie.

Der Business-Analyst kann als Entscheidungshilfe für jede potentielle Change-Strategie einen Business Case entwickeln. Die Opportunitätskosten jeder Change-Strategie müssen ebenfalls berücksichtigt werden. Opportunitätskosten sindVorteile bzw. Erlöse, die mit der Auswahl einer alternativen Change-Strategiehätten erwirtschaftet werden können, durch die gewählte Variante aber nichtrealisiert werden können. Die Optionen, die zwar untersucht, aber abgelehntwurden, sind ein wesentlicher Bestandteil der gewählten Strategie, sie bietenden Stakeholdern Einblicke in die Vor- und Nachteile unterschiedlicher Lösungs-ansätze.

Bei der Definition der Change-Strategie wird auch die Investition betrachtet, dienotwendig ist, um den Change zum Soll-Zustand zu bewerkstelligen. Die Erlöseeines Soll-Zustands mögen sehr hoch sein, wenn aber die Investitionen zu hochsind („sie können sich den Change nicht leisten“) wird das Unternehmen dieseChance verstreichen lassen und in Anderes investieren.

Der erhoffte Wert, einschließlich der erwarteten Nutzen und Kosten, enthältwesentliche Komponenten, um einen Business Case für die Veränderung zuerstellen. Indem die Beschreibungen des möglichen Werts mit den Messergeb-nissen des aktuell erreichten Werts verglichen werden, können Stakeholder denWert der erwarteten Veränderung verstehen. Obwohl jede Veränderung, diedurch den Business-Analysten begleitet wird, den Wert erhöhen soll, ist esmöglich, dass manche Veränderungen den Wert in Teilen der Organisation ver-ringern, während er in anderen Teilen erhöht wird.

.5 Übergangszustände und Release-PlanungIn vielen Fällen wird der Soll-Zustand erst in mehreren Schritten in der fernerenZukunft erreicht und nicht durch ein einzelnes Vorhaben. Das hat zur Folge,dass das Unternehmen auch in einem oder mehreren Übergangszuständen funk-tionieren muss. Mit der Release-Planung wird dann festgelegt, welche Anforde-rungen in welcher Phase, welchem Release oder welcher Iteration eines Verän-derungsvorhabens aufzunehmen sind. Der Business-Analyst moderiert die Mee-tings der Release-Planung, um Stakeholdern zu helfen, die richtigen Entschei-


152

dungen zu treffen. Es gibt viele Faktoren, die diese Entscheidungen beeinflussen,unter anderem das Gesamtbudget, feste Termine oder Zeitbeschränkungen,begrenzte Ressourcen, Schulungspläne und die Fähigkeit des Unternehmens,die beabsichtigten Änderungen innerhalb eines bestimmten Zeitraums umzu-setzen. Es kann auch organisatorische Einschränkungen oder Richtlinien geben,die bei jeder Umsetzung berücksichtigt werden müssen. Der Business-Analystträgt bei der Planung der Umsetzung dazu bei, dass Störungen des normalenGeschäftsablaufs möglichst gering bleiben und dass alle Beteiligten wissen,welche Auswirkungen ein Change auf das Unternehmen hat.


• Business-Analyse-Ansatz: Er beschreibt, wie ein Business-Analyst eine Change-Strategie definiert.

• Design-Optionen: Sie zeigen, welche verschiedenen Möglichkeiten es gibt, um einen betrieblichen Bedarf zu erfüllen. Jede Option birgt gewisse Herausforderungen an den Change. Die Change-Strategie wird sowohl von der gewählten Option beeinflusst als auch von dem gewähl-ten Change-Ansatz.

• Lösungsempfehlungen: Sie beinhalten die möglichen Optionen, die verfolgt werden können, um einen Soll-Zustand zu erreichen. Dazu fließen auch die Empfehlungen von verschiedenen Fachexperten ein.

Techniken

• Balanced Scorecard: Wird dazu verwendet, die Maßstäbe zu definieren, mit denen sich die Effektivität der Change-Strategie messen lässt.

• Benchmarking und Marktanalyse: Erleichtern Entscheidungen über eine angemessene Change-Strategie.

• Brainstorming: Damit können gemeinsam Ideen für die Change-Strategie erarbeitet werden.

• Betriebliche Fähigkeitsanalyse: Wird dazu verwendet, Defizite bei den betrieblichen Fähigkeiten im Hinblick auf Chancen und Risiken zu beurteilen.

• Business Cases: Werden verwendet, um Informationen über die empfoh-lene Change-Strategie zu erfassen sowie über andere mögliche Strate-gien, die bewertet, aber nicht empfohlen wurden.

• Begriffsmodellierung: Wird genutzt, um Veränderungen bei der vorhan-denen Infrastruktur, der Kundenbasis und der Finanzstruktur zu ermitteln,die notwendig sind, um den gewünschten Wert zu erreichen.


153

6.4.6

6.4.5

• Entscheidungsanalyse: Wird verwendet, um unterschiedliche Change-Strategien zu vergleichen und die passende auszuwählen.

• Schätzungen: Dienen dazu, Zeiten zu schätzen, die für Aktivitäten der Change-Strategie benötigt werden.

• Finanzanalyse: Wird dazu genutzt, die möglichen Werte zu ermitteln, die mit einer Change-Strategie verbunden sind, und um unterschiedliche Strategien im Hinblick auf ihren Return on Investment zu bewerten.

• Fokusgruppen: In ihnen werden Kunden oder Anwender zusammen-gebracht, um sie zu ihrer Meinung über die Lösungen und die Change-Strategie zu befragen.

• Funktionale Gliederung: Mit ihrer Hilfe werden bei der Entwicklung einer Change-Strategie die Komponenten einer Lösung in kleinere Bestandteile zerlegt.

• Interviews: Werden eingesetzt, um mit den Stakeholdern über den Um-fang der Lösung und des Veränderungsvorhabens zu sprechen und um deren Vorschläge für die Change-Strategie zu verstehen.

• Lessons Learned: Dienen dem Verständnis, was in den zurückliegenden Veränderungsprozessen schiefgelaufen ist, um so die Change-Strategie zu verbessern.

• Mind Mapping: Wird bei der Entwicklung und Untersuchung von Ideen für Change-Strategien genutzt.

• Organisationsmodellierung: Mit ihrer Hilfe werden Rollen, Verantwort-lichkeiten und Berichtsstrukturen beschrieben, die während der Ver-änderung benötigt werden und Teil der Lösung sind.

• Prozessmodellierung: Damit werden die Arbeitsprozesse in der späteren Lösung oder während des Change-Vorhabens beschrieben.

• Scope-Modellierung: Dient der Beschreibung des Scopes der Lösung und der Grenzen des Veränderungsvorhabens.

• SWOT-Analyse: Mit ihrer Hilfe werden Entscheidungen über eine ange-messene Change-Strategie gefunden.

• Anbieter-Assessment: Damit wird festgestellt, ob Lieferanten entweder als Träger der Veränderung oder als Lösungselement Teil der Change-Strategie sind.

• Workshops: In ihnen werden gemeinsam mit Stakeholdern Change-Strategien entwickelt.

Stakeholder

• Kunde: Kann Käufer oder Anwender der Lösung sein. Kunden können auch als Tester oder Mitglieder von Fokusgruppen eingebunden werden,


154

6.4.7

deren Beitrag bei der betrieblichen Akzeptanzeinschätzung berücksichtigtwird.

• Fachexperte: Er besitzt Fachwissen über einige Aspekte des Change.• Endanwender: Er nutzt eine Lösung, ist eine Komponente derselben oder er nutzt die Lösung nur während des Change-Prozesses. Endanwender können Kunden sein oder Personen, die während des Veränderungspro-zesses mit dem Unternehmen zusammenarbeiten. Anwender können auch als Tester oder Mitglieder von Fokusgruppen mitwirken, deren Bei-trag bei der betrieblichen Akzeptanzeinschätzung berücksichtigt wird.

• Umsetzungsexperte: Er besitzt spezialisiertes Wissen über einige Aspekte des Änderungsvorhabens.

• Support: Er ist direkt daran beteiligt, die betrieblichen Operationen zu unterstützen und kann Informationen dazu beisteuern, inwieweit er die Lösung während des Veränderungsvorhabens oder im laufenden Betrieb unterstützen kann.

• Projektmanager: Er ist verantwortlich für die Planung und Steuerung aller Aktivitäten einer Veränderung. In einem Projekt ist er für den Scope des Projektes zuständig, der alle Aufgaben für das Projektteam umfasst.

• Regulierer: Er stellt sicher, dass Gesetze, Verordnungen oder Regeln im Rahmen der Veränderung eingehalten werden. Er kann auch die Analyse der betrieblichen Akzeptanzeinschätzung unterstützen, da bei der Umset-zung eines Veränderungsvorhabens möglicherweise Gesetze und Verord-nungen beachtet werden müssen.

• Sponsor: Er bewilligt die Freigabe, stellt die Finanzierung für die Umset-zung sicher und tritt für das Vorhaben ein.

• Lieferant: Er kann an der Umsetzung der Veränderung beteiligt oder Teil der Lösung nach ihrer Einführung sein.

• Tester: Er ist dafür zuständig, sicherzustellen, dass die Veränderung funktioniert und die gewünschten Ergebnisse mit einer angemessenen Qualität bereitstehen. Er ist oft auch bei der Validierung von Lösungs-komponenten eingeschaltet, deren Ergebnisse auch in die Einschätzung der betrieblichen Akzeptanz einfließen.

Outputs

• Change-Strategie: Der Ansatz, den die Organisation verfolgen wird, um die Veränderung umzusetzen.

• Scope der Lösung: Der Lösungsumfang, der durch die Umsetzung der Change-Strategie erreicht werden kann.


155

6.4.8

157

Das Wissensgebiet „Anforderungsanalyse und Design-Definition“ beschreibt dieAufgaben, mit denen der Business-Analyst die in der Erhebung ermitteltenAnforderungen strukturiert und organisiert, Anforderungen und Designs spezi-fiziert und modelliert, Informationen überprüft und bestätigt sowie Lösungsop-tionen, die den betrieblichen Bedarf decken, identifiziert und den potentiellenNutzen jeder dieser Lösungsoptionen ermittelt. Dieses Wissensgebiet deckt dieeinzelnen Bearbeitungsschritte und die wiederkehrenden Tätigkeiten ab, vomAnfangskonzept und der Bedarfsermittlung bis zur Umsetzung dieses Bedarfsin einer empfohlenen Lösung (weitere Informationen finden Sie unter „Anfor-derungen und Designs“, Kap. 2.5).

Anforderungen und Designs sind wichtige Werkzeuge, mit denen der Business-Analyst Change definiert und lenkt. Der Hauptunterschied zwischen Anforde-rungen und Designs liegt darin, wie und durch wen sie genutzt werden. Wasfür den einen ein Design ist, kann für einen anderen eine Anforderung sein.Anforderungen und Designs können entweder sehr abstrakt oder sehr detailliertsein, je nachdem was für die Empfänger der Information zweckmäßig ist.

Die Modellierung des Bedarfs, der Anforderungen, Designs und Lösungen durchden Business-Analysten dient dazu, eine gründliche Analyse und Kommunikationmit den Stakeholdern zu unterstützen. Form, Detailierungsgrad und Inhalt sindabhängig von Kontext, Zielgruppe und Zweck.

Der Business-Analyst ermittelt den potentiellen Wert von Anforderungen undDesigns. Gemeinsam mit den Umsetzungsexperten definiert der Business-Analystzu bewertende Lösungsoptionen, um die Lösungsoption vorzuschlagen, die denBedarf am besten deckt und den höchsten Nutzen stiftet.

Die folgende Abbildung 7.0.1 zeigt, wie die Aktivitäten der Business-Analysefortschreiten, von der potentiellen Lösung bis zur konkreten Wertschöpfung.

7

Weitere Informationenin Kap. 2.5„Anforde-rungen undDesigns“

Anforderungsanalyse und Design-Definition

Abb. 7.0.1: Wertstrahl der Business-Analyse

Das Wissensgebiet „Anforderungsanalyse und Design-Definition“ umfasst fol-gende Aufgaben:

• Anforderungen spezifizieren und modellieren: Mit Hilfe von Analyse-techniken wird detailliert ein Set von Anforderungen oder Designs beschrieben.

• Anforderungen verifizieren: Damit wird sichergestellt, dass ein Set von Anforderungen entwickelt wurde, das für die Nutzung durch einen bestimmten Stakeholder ausreichend detailliert, in sich konsistent und qualitativ hochwertig ist.

• Anforderungen validieren: Damit wird sichergestellt, dass ein Set von Anforderungen oder Designs für das Unternehmen Wert schafft und die Unternehmensziele unterstützt.

• Anforderungsarchitektur definieren: Damit werden alle Anforderun-gen und Designs so strukturiert, dass sie den übergeordneten Zweck des Change-Vorhabens unterstützen und dass sie mit einander ver-träglich und effektiv sind.

• Design-Optionen definieren: Verschiedene mögliche Arten, einen Bedarf zu decken, werden identifiziert, untersucht und beschrieben.

• Nutzenpotential analysieren und Lösung empfehlen: Der Wert, den eine mögliche Lösung für ein Unternehmen schafft, wird eingeschätzt. Verschiedene Optionen inklusive ihrer Zielkonflikte werden verglichen, um so Lösungsoptionen zu ermitteln und diejenige Option zu empfeh-len, die den größten Gesamtnutzen liefert.

Das Kernkonzept-Modell in der „Anforderungsanalyseund Design-DefinitionDas Kernkonzept-Modell der Business-Analyse (BACCM™) beschreibt die Bezie-hungen der sechs Kernkonzepte. Die folgende Tabelle gibt einen Überblick zumEinsatz und zur Verwendung jedes Kernkonzeptes in der Anforderungsanalyseund Design-Definition.

158


Das Kernkonzept-Modell in „Anforderungsanalyse und Design-Definition“

Bedarf

Potential Umsetzung

Scope derLösung

Anforderun-gen


Prototyp

Pilot/Beta-

version

Betrieb

StrategischeAnalyse


Lösungsbewertung

Tabelle 7.0.1: Das Kernkonzept-Modell in der „Anforderungsanalyse und Design-Definition“



159

Kernkonzept Der Business-Analyst in der Anforderungsanalyse undDesign-Definition …


… verwandelt die Ergebnisse der Erhebung inAnforderungen und Designs, um den Changegenau zu definieren.


… analysiert den Bedarf, um eine Lösung empfehlen zu können, die diesen Bedarf abdeckt.


… definiert Lösungsoptionen und empfiehlt dieje-nige, die den Bedarf am besten abdeckt und denhöchsten Nutzen verspricht.


… formuliert die Anforderungen und Designs so,dass diese von jeder Stakeholdergruppe verstandenund genutzt werden können.


… analysiert und quantifiziert das Nutzen-potential der Lösungsoptionen.


… modelliert und beschreibt den Kontext in einerForm, die für alle Stakeholder verständlich undverwendbar ist.

Abb. 7.0.2: Input-Output-Diagramm „Anforderungsanalyse und Design-Definition“



160

Aufgaben

Output

Input

Anforderungen(alle Zustände)



(alle Zustände)

4.2, 4.3

PotentiellerNutzen

6.2

Anforderungen(spezifiziert und

modelliert)

7.1

3.4

Scope derLösung

6.4

Change-Strategie6.4


7.3

Anforderungs-architekturdefinieren

7.4


modellieren

7.1

Nutzenpotential analysieren und

Lösung empfehlen

7.6


7.5

Anforderungenverifizieren

7.2


7.2Anforderungen

(validiert)

7.3

Anforderungs-architektur

7.4Design-

Optionen

7.5Lösungs-

empfehlung

7.6

Anforderungen spezifizieren und modellieren

Zweck

„Anforderungen spezifizieren und modellieren“ dient dazu, die Ergebnisse derErhebung zu analysieren, zusammenzufassen und daraus Anforderungen undDesigns zu erarbeiten.

Beschreibung

„Anforderungen spezifizieren und modellieren“ beschreibt die Tätigkeiten, diedazu dienen, die Ergebnisse der Erhebung zu analysieren und darzustellen. Stehtdas Verstehen des Bedarfs im Vordergrund, werden die Ergebnisse als „Anfor-derungen“ bezeichnet. Liegt der Schwerpunkt auf der Lösung, dann werdendie Ergebnisse „Designs“ genannt.

In vielen IT-Umgebungen wird der Begriff „Design“ enger verwendet und bezeich-net nur technische Designs, die von Software-Entwicklern, Datenarchitektenund Umsetzungsexperten erstellt werden. Alle betrieblich relevanten, nicht-tech-nischen Ergebnisse werden als „Requirements“ bezeichnet.

Zusätzlich zu den Modellen, die der Abbildung der Anforderungen dienen,werden in dieser Aufgabe auch Informationen zu den Attributen oder Metadatenüber die Anforderungen erfasst. Das Spezifizieren und die Modellierungsaktivitätenbetreffen alle Arten/Typen von Anforderungen.

Inputs

• Erhebungsergebnisse (alle Zustände): Die Modellierung kann mit jeder Form des Ergebnisses der Erhebung starten. Sie kann auch zusätzliche Erhebungs-maßnahmen auslösen, um Anforderungen zu klären oder zu erweitern. Erhebung und Modellierung können nacheinander, iterativ oder parallel durchgeführt werden.



161

7.1

7.1.1

7.1.2

Wichtig

7.1.3

Abb. 7.1.1: Input-Output-Diagramm „Anforderungen spezifizieren und modellieren“

Elemente

.1 Anforderungen modellierenEin Modell beschreibt und visualisiert Informationen für eine bestimmte Zielgruppe,um damit die Analyse, die Kommunikation und das Verständnis zu verbessern.Modelle können auch dazu dienen, bereits vorhandenes Wissen zu bestätigen,Informationslücken des Business-Analysten aufzudecken und Redundanzen zuidentifizieren.

Der Business-Analyst verwendet eine oder mehrere der folgenden Formate zurModellierung:

• Matrizen: Eine Matrix wird eingesetzt, wenn der Business-Analyst eine Anforderung oder ein Set von Anforderungen modelliert, die eine



162

Input


Anforderungen spezifizierenund modellieren

7.1

Output


Modellierungs-Notationen/ Standards

Modellierungswerkzeuge

Anforderungsarchitektur

Werkzeuge zum Manage-ment des Anforderungs-

Lebenszyklus

Scope der Lösung


(alle Zustände)

4.2, 4.3


7.3Anforderungen

verifizieren

7.2


modelliert)

7.1

7.1.4

komplexe aber gleichartige Struktur haben, die in Elemente unterteilt werden kann, und auf jeden Eintrag in der Tabelle zutreffen. Matrizen können auch für Data Dictionaries, für die Rückverfolgbarkeit oder für die Analyse von Lücken genutzt werden. Matrizen dienen auch zur Priorisierung von Anforderungen und Aufzeichnung von Anforderungs-attributen und Metadaten.

• Diagramme: Ein Diagramm ist eine visuelle, oft bildhafte Darstellung einer Anforderung oder eines Sets von Anforderungen. Ein Diagramm ist besonders geeignet, komplexe Sachverhalte darzustellen, die mit Worten allein nur schwierig zu erklären wären. Diagramme können auch zur Beschreibung der Grenzen von Business Domains eingesetzt werden, außerdem dazu, Sachverhalte zu kategorisieren und zu hierar-chisieren oder um Objektkomponenten wie Daten und deren Bezie-hungen untereinander darzustellen.

Der Business-Analyst verwendet ein oder mehrere Modellformate und legt fest,welche Kategorien und spezifischen Modelle innerhalb einzelner Kategoriengenutzt werden. Modellkategorien können sein:

• Personen und Rollen: Modelle bilden Organisationen, Personengrup-pen, Rollen und deren Beziehungen innerhalb eines Unternehmens oder einer Lösung ab. Techniken dazu sind Organisationsmodellierung,Rollen- und Zuständigkeitsmatrix und Stakeholder-Listen, -Karten oder Personas.

• Begründung: Modelle bilden das „Warum“ einer Änderung ab. Geeig-nete Techniken dazu sind die Entscheidungsmodellierung, Scope-Modellierung, Darstellung des Geschäftsmodells, Ursachenanalyse undAnalyse der Geschäftsregeln.

• Abfolge von Aktivitäten: Modelle bilden die Handlungsfolge, Ereignisseoder geplante Handlungen ab. Techniken dazu sind Prozessmodellie-rung, Use Cases und Szenarien sowie User Stories.

• Fähigkeiten: Modelle konzentrieren sich auf Features oder Funktionen eines Unternehmens oder einer Lösung. Techniken dazu sind die Betrieb-liche Fähigkeitsanalyse, Funktionale Gliederung und Prototyping.

• Daten und Information: Modelle bilden die Eigenschaften und den Informationsaustausch in einem Unternehmen oder einer Lösung ab. Techniken zur Darstellung von Daten und Information umfassen Data Dictionary, Datenflussdiagramme, Datenmodellierung, Glossar, Statusmodellierung und Schnittstellen-Analyse.

Der Business-Analyst sollte die Kombination von Modellen auswählen, die fürden Bedarf der Stakeholder in einem Kontext am besten geeignet ist. JedeModellierungstechnik, die spezifische Einblicke in ein Fachgebiet vermittelt, hatihre eigenen Stärken und Schwächen.



163

.2 Anforderungen analysierenInformationen der Business-Analyse können zur genaueren Untersuchung inKomponenten zerlegt werden hinsichtlich

• allem, was geändert werden muss, um den Unternehmensbedarf zu decken

• allem, was gleichbleiben muss, um den Unternehmensbedarf zu decken• fehlender Komponenten• nicht notwendiger Komponenten• aller Nebenbedingungen und Annahmen, die Einfluss auf die Kompo-nenten haben.

Die Tiefe der Zerlegung und der Detaillierungsgrad sind unter anderem vomWissen und Verständnis der Stakeholder abhängig, der Gefahr von Missver-ständnissen oder Kommunikationsfehlern, Unternehmensstandards sowie ver-traglichen oder regulatorischen Verpflichtungen.

Die Analyse liefert eine Diskussionsgrundlage, um gemeinsam Lösungsoptionenzu finden.

.3 Anforderungen und Attribute darstellenDer Business-Analyst identifiziert als Teil der Erhebung Informationen überAnforderungen und deren Attribute. Anforderungen sollten explizit dargestelltwerden und ausreichend detailliert sein, um die Eigenschaften der Anforderungenund die Qualität des Designs abzubilden (siehe „Anforderungen verifizieren“,Kap. 7.2). Für jede Anforderung oder jedes Set an Anforderungen könnenbestimmte Attribute festgelegt werden. Diese Attribute werden während derPlanung des Informationsmanagements ausgewählt (siehe „Informationsma-nagement der Business-Analyse planen“, Kap. 3.4).

Während der Spezifikation der Anforderungen können diese auch beispielsweisenach dem Schema kategorisiert werden, das in Kapitel 2.3 beschrieben wird.Normalerweise beinhalten Erhebungsergebnisse verschiedene Typen von Infor-mationen, so dass zu erwarten ist, dass gleichzeitig verschiedene Arten vonAnforderungen zu spezifizieren sind. Die Kategorisierung von Anforderungenkann dazu beitragen, Anforderungen besser zu verstehen, die Vollständigkeiteiner Kategorie zu prüfen und dafür zu sorgen, dass die Beziehungen zwischenden Anforderungen nachvollzogen werden können.

.4 Einen geeigneten Abstraktionsgrad umsetzenDer Abstraktionsgrad einer Anforderung hängt von der Art und der Zielgruppeder Anforderung ab. Nicht alle Stakeholder verlangen ein vollständiges Set vonAnforderungen und Modellen oder halten sie überhaupt für notwendig. Es kannsinnvoll sein, verschiedene Sichten der Anforderungen zu schaffen, die den glei-



164

chen Bedarf jeweils passend für verschiedene Stakeholder abbilden. Der Busi-ness-Analyst achtet besonders darauf, dass der einheitliche Sinn und Zweck derAnforderungen bei allen Formen der Darstellung gewahrt bleibt.

Der Ansatz der Business-Analyse kann den Abstraktionsgrad und die Wahl derModelle bei der Definition der Anforderungen beeinflussen.


• Modellierungs-Notationen/-Standards: Sie erlauben die exakte Spezifika-tion von Anforderungen und Designs, abgestimmt auf die Zielgruppe undden Zweck der Modelle. Standardvorlagen und Syntax helfen, die richti-gen Informationen zu den Anforderungen zu liefern.

• Modellierungswerkzeuge: Software, mit der Matrizen und Diagramme zurAbbildung von Anforderungen gezeichnet und gespeichert werden. DieseFunktionalität kann ein Werkzeug zum Management des Anforderungs-Lebenszyklus enthalten, muss es aber nicht.

• Anforderungsarchitektur: Die Anforderungen und deren interne Bezie-hungen können in einer Anforderungsarchitektur überprüft werden, ob sie vollständig und konsistent sind.

• Werkzeuge zum Management des Anforderungs-Lebenszyklus: Das ist Software, die dazu dient, Anforderungen und Designs aufzuzeichnen, zu organisieren, zu speichern und zu verbreiten/teilen.

• Scope der Lösung: Die Grenzen der Lösung bestimmen auch die Gren-zen der Anforderungs- und Design-Modelle.

Techniken

• Akzeptanz- und Bewertungskriterien: Dienen der Darstellung der Akzep-tanz- und Bewertungskriterien für die Anforderungsattribute.

• Betriebliche Fähigkeitsanalyse: Bildet die Features oder Funktionen eines Unternehmens ab.

• Darstellung des Geschäftsmodells: Beschreibt die Gründe für die Anforde-rungen.

• Analyse der Geschäftsregeln: Die Geschäftsregeln können gemeinsam mitden Anforderungen analysiert, spezifiziert und modelliert werden.

• Begriffsmodellierung: Dient zur Definition der Begriffe und der Beziehun-gen, die für den Change und das Unternehmen relevant sind.

• Data Dictionary: Wird genutzt, um Details über die von der Änderung betroffenen Daten festzuhalten. Dazu gehören Definitionen, Beziehun-gen zu anderen Daten, Quellen, Formaten und Verwendung.



165

7.1.5

7.1.6

• Datenflussdiagramm: Dient der Visualisierung von Anforderungen zum Datenfluss.

• Datenmodellierung: Aus der Modellierung der Daten wird ersichtlich, wie Daten verwendet werden, um den Informationsbedarf der Stakeholder zudecken.

• Entscheidungsmodellierung: Stellt die Entscheidungen in einem Modell dar,um die notwendigen Elemente des Entscheidungsprozesses abzubilden.

• Funktionale Gliederung: Dient zur Modellierung von Anforderungen, um die wesentlichen Bestandteile einer komplexen betrieblichen Funktionzu identifizieren.

• Glossar: Es enthält die Erklärung der relevanten Begriffe, die bei der Anforderungsanalyse auftauchen.

• Schnittstellenanalyse: Dient zur Modellierung von Anforderungen, um Inputs und Outputs der modellierten Lösung zu identifizieren und zu validieren.

• Analyse nicht-funktionaler Anforderungen: Damit werden die Attribute zur Qualität des Service definiert und analysiert.

• Organisationsmodellierung: Erlaubt dem Business-Analysten, die Rollen, Verantwortlichkeiten und Kommunikationswege innerhalb einer Organi-sation zu modellieren.

• Prozessmodellierung: Damit werden die Schritte oder Aktivitäten abge-bildet, die in einem Unternehmen durchgeführt werden oder die für gewünschte Veränderungen notwendig sind.

• Prototyping: Erleichtert den Stakeholdern die Visualisierung des Erschei-nungsbilds und der Fähigkeiten einer geplanten Lösung.

• Rollen- und Zuständigkeitsmatrix: Damit werden die Anforderungen spezifiziert und modelliert, die mit der Aufteilung der Zuständigkeiten zwischen den Benutzern und den verwendeten externen Schnittstellen bei der Nutzung einer Lösung verbunden sind.

• Ursacheanalyse: Damit werden die Ursachen eines Problems als Teil der Begründung offengelegt.

• Scope-Modellierung: Damit wird die Begrenzung eines Sachverhalts visuellgezeigt.

• Sequenzdiagramm: Dient dazu, die Anforderungen zu spezifizieren und zu modellieren, so dass klar wird, wie Prozesse funktionieren und in welcher Abfolge sie miteinander interagieren.

• Stakeholder-Listen, -Karten oder Personas: Dienen der Identifikation der Stakeholder und ihrer Eigenschaften.

• Statusmodellierung: Bildet die verschiedenen Statuszustände eines Lösungselements abhängig von im Lebenszyklus auftretenden Ereignis-sen ab.



166

• Use Cases und Szenarien: Mit ihnen wird das erwünschte Verhalten einer Lösung modelliert, indem die Aktionen gezeigt werden, die Benutzer mit der Lösung vornehmen, um ein bestimmtes Ziel zu erreichen oder eine bestimmte Handlung zu vollziehen.

• User Stories: Damit werden prägnant Anforderungen darüber spezifiziert, was Personen tun oder tun müssen, wenn sie die Lösung verwenden.

Stakeholder

• Jeder Stakeholder: Der Business-Analyst kann diese Aufgabe allein durch-führen und dann die einzelnen Anforderungspakete den Stakeholdern zum Review und zur Genehmigung vorlegen, oder er lädt einige oder alle Stake-holder ein, bei dieser Aufgabe mitzuwirken.

Outputs

• Anforderungen (spezifiziert und modelliert): Alle Kombinationen von Anfor-derungen und/oder Designs in der Form von Text, Matrizen und Diagrammen.

Anforderungen verifizieren

Zweck

Der Zweck von „Anforderungen verifizieren“ ist, sicherzustellen, dass dieAnforderungen und Designs die Qualitätsstandards und den geforderten Zweckerfüllen.

Beschreibung

„Anforderungen verifizieren“ stellt sicher, dass die Anforderungen und Designskorrekt definiert wurden. Dazu werden die Anforderungen und Designs vondem Business-Analysten und Kern-Stakeholdern darauf überprüft, ob die Anfor-derungen und Designs für die Validierung bereit sind. Damit werden auch Infor-mationen bereitgestellt, die für weitere Arbeiten benötigt werden.

Eine Spezifikation von hoher Qualität ist gut lesbar und für die vorgeseheneZielgruppe leicht verständlich. Ein Modell von hoher Qualität folgt den formalenoder informellen Notationsstandards und bildet die Realität effektiv ab.



167

7.1.8

7.1.7

7.2

7.2.1

7.2.2

Die wichtigste Eigenschaft hochwertiger Anforderungen und Designs ist ihreNutzbarkeit. Sie müssen die Bedürfnisse der Stakeholder befriedigen, die diesefür einen bestimmten Zweck nutzen wollen. Die Qualität entscheidet sich inletzter Konsequenz beim Stakeholder.

Inputs

• Anforderungen (spezifiziert und modelliert): Jede Anforderung, jedes Design kann dahingehend verifiziert werden, dass deren Texte gut struk-turiert sind sowie die Matrizen und Modellierungsnotationen korrekt verwendet werden.

Abb. 7.2.1: Input-Output-Diagramm „Anforderungen verifizieren“



168

Input


Anforderungen verifizieren7.2

Output


modelliert)

7.1


7.2


5.5


Werkzeuge zum Manage-ment des Anforderungs-

Lebenszyklus

7.2.3

Elemente

.1 Eigenschaften der Anforderungs- und Design-QualitätAuch wenn die Qualität letztendlich von den Bedürfnissen der Stakeholderabhängt, welche die Anforderungen oder die Designs nutzen werden, so weisenakzeptable Qualitätsanforderungen viele der folgenden Eigenschaften auf:

• Atomar: Sie sind in sich geschlossen und auch ohne andere Anforde-rungen oder Designs verständlich.

• Vollständig: Sie sind ausreichend, um weitere Arbeiten zu lenken, und so detailliert, dass damit weitergearbeitet werden kann. Der jeweils notwendige Grad an Vollständigkeit hängt von den gewählten Per-spektiven oder der genutzten Methode ebenso ab wie von dem Moment im Lebenszyklus, zu dem die Anforderung untersucht oder dargestellt wird.

• Konsistent: Sie sind auf die ermittelten Bedürfnisse der Stakeholder ausgerichtet und stehen nicht mit anderen Anforderungen im Konflikt.

• Präzise: Sie sind relevant und beinhalten nur notwendige Inhalte.• Machbar: Sie sind vernünftig und innerhalb des akzeptierten Risikos, Zeitplans und Budgets erreichbar oder werden insofern als umsetzbar eingeschätzt, als sich weitere Untersuchungen in Form von Experimen-ten oder Prototypen lohnen.

• Unzweideutig: Die Anforderung muss so eindeutig formuliert sein, dass klar ist, ob eine Lösung den entsprechenden Bedarf erfüllt oder nicht.

• Testbar: Es muss möglich sein, die Erfüllung der Anforderung oder des Designs zu verifizieren. Das akzeptable Niveau, die Erfüllung zu verifi-zieren, hängt vom jeweiligen Abstraktionsgrad der Anforderung oder des Designs ab.

• Priorisiert: Anforderungen sind geordnet, gruppiert oder abgestimmt im Hinblick auf Wichtigkeit und Wert im Vergleich zu allen anderen Anforderungen.

• Verständlich: Anforderungen und Designs sind mit Begriffen darge-stellt, die der Zielgruppe geläufig sind.

.2 Aktivitäten zur VerifikationDie Verifikation wird normalerweise iterativ während des Prozesses der Anfor-derungsanalyse durchgeführt. Zu den Aktivitäten der Verifikation gehört es,

• die Compliance mit Leistungsstandards für die Business-Analyse zu prüfen, wie beispielsweise die Verwendung der richtigen Methoden und Werkzeuge



169

7.2.4

• die korrekte Verwendung der Modellierungsnotation, der Vorlagen oder Formate zu prüfen

• die Vollständigkeit innerhalb jedes Modells zu prüfen• jedes Modell mit anderen relevanten Modellen zu vergleichen, zu prüfen, dass in einem Modell erwähnte Elemente nicht bei einem anderen Modell fehlen, und sicherzustellen, dass die Elemente konsistent referenziert werden

• sicherzustellen, dass die verwendeten Begriffe bei der Formulierung der Anforderungen sowohl für die Stakeholder verständlich als auch konsis-tent mit der Verwendung dieser Begriffe innerhalb des Unternehmens sind

• Beispiele anzufügen, wo dies zur Klärung hilfreich ist.

.3 ChecklistenChecklisten dienen der Qualitätssicherung bei der Verifikation von Anforderungenund Designs. Checklisten können ein Standard-Set von Qualitätselementen bein-halten, das der Business-Analyst nutzt, um Anforderungen zu verifizieren, odersie können für bestimmte Vorhaben speziell entwickelt werden. Eine Checklistesoll sicherstellen, dass Sachverhalte, die für wichtig gehalten werden, in denendgültigen Anforderungen enthalten sind, oder dass die erforderlichen Schritteim Verifikationsprozess erledigt werden.


• Werkzeuge zum Management des Anforderungs-Lebenszyklus: Einige Werk-zeuge bieten Funktionalitäten, um Aspekte von Eigenschaften zu überprü-fen, beispielsweise ob sie atomar, unzweideutig und priorisiert sind.

Techniken

• Akzeptanz- und Bewertungskriterien: Mit ihnen soll sichergestellt werden,dass die Anforderungen so klar beschrieben sind, dass mit ihnen ein Set an Tests erstellt werden kann, um damit die Erfüllung der Anforderungs-kriterien zu prüfen.

• Item Tracking: Dient der Sicherstellung, dass alle während der Verifizie-rung identifizierten Probleme oder Anliegen auch gemanagt und gelöst werden.

• Kennzahlen und Key-Performance-Indikatoren: Mit ihnen soll herausgefun-den werden, wie die Qualität der Anforderungen bewertet werden kann.

• Reviews: Sie dienen der Überprüfung der Anforderungsdokumentation, um Anforderungen zu entdecken, welche den Qualitätsanspruch noch nicht erfüllen.



170

7.2.6

7.2.5

Stakeholder

• Alle Stakeholder: Der Business-Analyst ist zusammen mit dem Fach- und demUmsetzungsexperten dafür verantwortlich, dass diese Aufgabe erledigt wird. Andere Stakeholder können auch problematische Anforderungen entdecken.Daher können potentiell alle Stakeholder an dieser Aufgabe mitwirken.

Outputs

• Anforderungen (verifiziert): Ein Set von Anforderungen oder Designs mit einer ausreichend hohen Qualität, so dass weitere Arbeitsschritte darauf aufbauen können.

Anforderungen validieren

Zweck

Der Zweck von „Anforderungen validieren“ ist die Sicherstellung, dass alle Anfor-derungen und Designs auf die betrieblichen Anforderungen ausgerichtet sindund dazu beitragen, die notwendige Wertschöpfung zu schaffen.

Beschreibung

Anforderungen sind permanent zu validieren, um sicherzustellen, dass die Stake-holder-, Lösungs- und Umsetzungsanforderungen auf die betrieblichen Anforde-rungen ausgerichtet bleiben und dass die Designs die Anforderungen erfüllen.

Bei der Validierung der Anforderungen ist es für den Business-Analysten sehrwichtig, dass er den von den Stakeholdern gewünschten Soll-Zustand versteht,mit dem der Bedarf erfüllt wird. Das übergeordnete Ziel der Umsetzung der Anfor-derungen ist, einen von den Stakeholdern gewünschten Soll-Zustand zu schaffen.Oft haben Stakeholder unterschiedliche oder sogar gegensätzliche Bedürfnisseund Erwartungen, die im Validierungsprozess aufgedeckt werden können.

Inputs

• Anforderungen (spezifiziert und modelliert): Alle Arten von Anforderungen und Designs können validiert werden. Die Validierung kann noch vor der vollständigen Verifizierung der Anforderungen starten. Die Validierung kann jedoch erst dann abgeschlossen werden, wenn alle Anforderungen vollstän-dig verifiziert worden sind.



171

7.2.8

7.2.7

7.3.2

7.3.1

7.3

7.3.3

Abb. 7.3.1: Input-Output-Diagramm „Anforderungen validieren“

Elemente

.1 Annahmen identifizierenWenn ein Unternehmen ein Produkt oder eine Dienstleistung startet, für die eskeine Vorgänger gibt, kann es notwendig werden, Annahmen über die Reaktionender Kunden oder Stakeholder zu treffen, da es noch keine Erfahrungswertegibt. In anderen Fällen mag es schwierig oder unmöglich sein, zu beweisen,dass ein bestimmtes Problem auf eine vermutete Ursache zurückgeführt werdenkann. Stakeholder können erwarten, dass die Umsetzung einer Anforderungbestimmte Vorteile bringt. Diese Annahmen werden identifiziert und definiert,so dass damit verbundene Risiken bewältigt werden können.



172

Input


Output



Nutzenpotential

Scope der Lösung


7.5 8.1


modelliert)

7.1

Unternehmensziele

Anforderungen validieren7.3

Anforderungen(validiert)

7.3


7.3.4

.2 Messbare Bewertungskriterien definierenBei der Definition des Soll-Zustands kann es vorkommen, dass zwar die erwartetenVorteile definiert, aber weder spezifisch messbare Kriterien noch der Bewer-tungsprozess festgelegt wurden. Der Business-Analyst definiert die Bewertungs-kriterien, mit denen festgestellt werden kann, wie erfolgreich der Change nachder Umsetzung der Lösung ist. Ausgangswerte können anhand des Ist-Zustandsfestgestellt werden. Zielgrößen können aus der Erreichung der Unternehmenszieleoder anderer Kenngrößen für den Erfolg abgeleitet werden.

.3 Die Ausrichtung auf den Scope der Lösung bewertenEine Anforderung kann einem Stakeholder Nutzen stiften und dennoch für eineLösung nicht erwünscht sein. Eine Anforderung, die keinen Nutzen für einenStakeholder schafft, ist ein Streichkandidat. Wenn die Ausrichtung der Anforde-rungen nicht stimmt, muss entweder der Soll-Zustand neu bewertet oder derScope der Lösung geändert werden, oder die Anforderung ist aus dem Scopeder Lösung zu entfernen.

Wenn sich bei der Bewertung herausstellt, dass ein Design eine Anforderungnicht erfüllt, so kann eine Anforderung fehlen oder falsch verstanden wordensein oder das Design muss geändert werden.


• Unternehmensziele: Sie stellen sicher, dass die Anforderungen die gewünschten Vorteile für das Unternehmen erbringen.

• Beschreibung des Soll-Zustands: Damit kann sichergestellt werden, dass die im Scope der Lösung enthaltenen Anforderungen zu dem gewünsch-ten Soll-Zustand beitragen werden.

• Nutzenpotenzial: Es kann als Benchmark dienen, um den Nutzen zu über-prüfen, der von den Anforderungen erwartet wird.

• Scope der Lösung: Er stellt sicher, dass die Nutzen schaffenden Anforde-rungen innerhalb des Scopes der gewünschten Lösung liegen.

Techniken

• Akzeptanz- und Bewertungskriterien: Mit ihnen werden Qualitätskriteriendefiniert, die erfüllt sein müssen, damit sie von den Stakeholdern akzep-tiert werden.

• Dokumentenanalyse: Dient zur Erkennung eines bereits vorher dokumen-tierten betrieblichen Bedarfes , der zur Validierung von Anforderungen benutzt wird.



173

7.3.6

7.3.5

• Finanzanalyse: Damit können die finanziellen Vorteile ermittelt werden, die einer Anforderung zugeordnet werden können.

• Item Tracking: Dient der Sicherstellung, dass alle Probleme gelöst und alle Anliegen behandelt werden, die während der Validierung identifiziert werden.

• Kennzahlen und Key-Performance-Indikatoren: Dienen der Auswahl geeigneter Performance-Messgrößen für eine Lösung, Lösungskompo-nente oder Anforderung.

• Reviews: Damit kann bestätigt werden, ob ein Stakeholder der Meinung ist, dass seine Bedürfnisse erfüllt werden oder nicht.

• Risikoanalyse und -management: Damit werden mögliche Szenarien identifiziert, die einen Einfluss haben können auf die erwarteten Vorteile einer Anforderung.

Stakeholder

• Alle Stakeholder: Der Business-Analyst ist in Verbindung mit Kunden, Anwendern und Auftraggeber primär dafür verantwortlich, festzustellen, ob die Anforderungen validiert wurden oder nicht. Andere Stakeholder können im Kommunikationsprozess problematische Anforderungen ent-decken. Daher können fast alle Stakeholder im Projekt an dieser Aufgabe mitwirken.

Outputs

• Anforderungen (validiert): Bei validierten Anforderungen und Designs ist nachgewiesen, dass sie den Stakeholdern Nutzen stiften und mit den betrieblichen Zielen vereinbar sind, die mit dem Change angestrebt werden. Wenn eine Anforderung oder ein Design nicht validiert werden kann, bringt sie/es entweder dem Unternehmen keinen Nutzen oder sie/es fällt nicht in den Scope der Lösung oder beides.

Anforderungsarchitektur definieren

Zweck

Der Zweck von „Anforderungsarchitektur definieren“ ist, sicherzustellen, dassdie Anforderungen sich wechselseitig bei der Zielerreichung unterstützen.



174

7.3.8

7.3.7

7.4

7.4.1

Beschreibung

Die Anforderungsarchitektur ist die Struktur aller Anforderungen eines Change.Die Anforderungsarchitektur vereinigt die individuellen Modelle und Spezifika-tionen zu einem Ganzen, das die übergeordneten Unternehmensziele unterstütztund für die Stakeholder ein nützliches Ergebnis hervorbringt.

Der Business-Analyst verwendet eine Anforderungsarchitektur, um• zu verstehen, welche Modelle für den Bereich, den Scope der Lösung und die Zielgruppe geeignet sind

• die Anforderungen in Strukturen zu organisieren, die für die unter-schiedlichen Stakeholder relevant sind

• darzustellen, wie Anforderungen und Modelle zusammenhängen, miteinander agieren und wie die Teile zusammenpassen, um ein sinn-volles Ganzes zu bilden

• sicherzustellen, dass die Anforderungen zusammen die übergeordne-ten Ziele erreichen

• Entscheidungen bei miteinander konkurrierenden Anforderungen unter Berücksichtigung der Gesamtziele treffen zu können.

Die Anforderungsarchitektur dient nicht dem Ziel der Rückverfolgbarkeit (Trace-ability), vielmehr soll sie darstellen, wie Elemente harmonisch zusammenwirken,um die betrieblichen Anforderungen zu erfüllen und sie auf verschiedene Artund Weise so zu strukturieren, dass sie auf die unterschiedlichen Sichtweisender Stakeholder ausgerichtet sind. Die Rückverfolgbarkeit wird oft als Mecha-nismus zur Abbildung und zum Management dieser Beziehungen genutzt (siehe„Anforderungen rückverfolgen“, Kap. 5.1).

Die Rückverfolgbarkeit stellt sicher, dass jede Anforderung auf ein Ziel bezogenist, und zeigt, wie dieses Ziel zu erreichen ist. Traceability allein beweist nochnicht, dass die Lösung ein funktionierendes kompaktes Ganzes ist.

Inputs

• Ansatz des Informationsmanagements: Er definiert, wie die Informationender Business-Analyse (inklusive Anforderungen und Modellen) gespeichertund wie auf sie zugegriffen werden kann.

• Anforderungen (alle Zustände): Jede Anforderung sollte nur einmal aufge-führt und in die Anforderungsarchitektur integriert werden, so dass das gesamte Set im Hinblick auf Vollständigkeit beurteilt werden kann.

• Scope der Lösung: Er ist zu berücksichtigen, damit die Anforderungs-architektur auf die Grenzen der gewünschten Lösung abgestimmt ist.



175

7.4.2

7.4.3

Abb. 7.4.1: Input-Output-Diagramm „Anforderungsarchitektur definieren“



176

Input


Output


Software zum Architektur-management

Methoden undFrameworks

Rechtliche und regula-torische informationen


7.4

Anforderungsarchitektur definieren7.4

Anforderungen(alle Zustände)


3.4

Scope derLösung

6.4


modellieren

7.1


7.5


5.3Änderungen von Anforderungen

beurteilen

5.4

Elemente

.1 Anforderungs-Viewpoint und SichtenEin Viewpoint ist ein Satz von Vereinbarungen, in dem definiert wird, wie Anfor-derungen dargestellt und organisiert werden, wie diese Darstellungen organisiertsind und wie sie zusammenhängen. Viewpoints liefern Vorlagen, um die Anliegenbestimmter Stakeholder-Gruppen zu berücksichtigen.

Anforderungs-Viewpoints beinhalten häufig Standards und Richtlinien für• Modelltypen, die in Anforderungen verwendet werden• Attribute, die konsistent in verschiedenen Modellen eingesetzt und verwendet werden

• verwendete Modellierungsnotationen, und sie liefern• analytische Ansätze zur Identifikation und Wartung von relevanten Beziehungen zwischen Modellen.

Ein Viewpoint allein kann keine Architektur schaffen. Jeder Viewpoint ist bessergeeignet für einige Anforderungsaspekte und weniger für andere, da unter-schiedliche Gruppen von Stakeholdern auch unterschiedliche Anliegen haben.Der Versuch, zu viele Informationen in einen einzelnen Viewpoint zu pressen,macht diesen zu kompliziert und untergräbt dessen Zweck, Anliegen zu erklären.Beispiele für Viewpoints sind:

• Geschäftsprozessmodelle• Datenmodelle und Informationen• Benutzerinteraktionen, inklusive Use Cases und/oder User Experience• Audit und Sicherheit• Geschäftsmodelle.

Jeder dieser Viewpoints nutzt unterschiedliche Modellierungsnotationen und -techniken. Jeder ist wichtig, um am Schluss eine kohärente Lösung zu erreichen.Eine Lösung wäre wahrscheinlich nicht erfolgreich, wenn ein Business-Analyst bei-spielsweise nur den Viewpoint Geschäftsprozess betrachten würde.

Wird versucht, zu viele Konventionen verschiedener Sichtweisen in einen einzelnenViewpoint zu pressen, erschwert dies die Analyse und führt zu zu vielen irrele-vanten Informationen für eine bestimmte Gruppe von Stakeholdern.

Die konkreten Anforderungen und Designs, die sich aus einem bestimmtenViewpoint ergeben, nennt man eine Sicht („view“). Ein Set von Sichten ergibtdie Anforderungsarchitektur für eine bestimmte Lösung. Der Business-Analystrichtet Anforderungen aus, koordiniert und strukturiert sie in sinnvolle Sichtenfür die verschiedenen Stakeholder. Dieses Set von koordinierten, einander unter-stützenden Sichten ist die Grundlage dafür, Vollständigkeit und die Kohärenzvon Anforderungen zu beurteilen. Viewpoints sagen also dem Business-Analysten,welche Informationen er jeder Stakeholdergruppe liefern sollte, um deren jeweilige



177

7.4.4

Anliegen zu berücksichtigen, während Sichten das erarbeitete Ergebnis von Anfor-derungen und Designs für einen bestimmten Viewpoint sind.

.2 Architekturen von VorlagenEin Architektur-Rahmenmodell ist eine Sammlung von Viewpoints, die ein Stan-dard für eine Branche, einen Industriezweig oder ein Unternehmen sind. DerBusiness-Analyst kann solche Rahmenmodelle als vordefinierte Vorlagen bei derDefinition ihrer Architektur benutzen. Ähnlich kann das Rahmenmodell mitbereichsspezifischen Informationen gefüttert werden und so eine Sammlung anSichten bilden, die nützliche Vorlagen zur Konstruktion einer Architektur liefern,wenn die bereits eingepflegten Informationen sehr exakt sind.

.3 VollständigkeitEine Architektur ist hilfreich, um die Vollständigkeit eines Sets von Anforderungenzu gewährleisten. Das gesamte Set von Anforderungen sollte für die Zielgruppeso verständlich sein, dass diese Zielgruppe feststellen kann, dass das Set schlüssigist und ein vollständiges Bild bietet. Keine Anforderung sollte fehlen, inkonsistentzu anderen sein oder diesen widersprechen. Die Anforderungsarchitektur solltealle Abhängigkeiten zwischen Anforderungen berücksichtigen, die die Zielerrei-chung gefährden könnten.

Werden Anforderungen nach unterschiedlichen Viewpoints geordnet, fördertdies die Vollständigkeit. Iterationen bei der Erhebung, der Spezifikation und derAnalyseaktivitäten tragen dazu bei, Lücken aufzudecken.

.4 Beziehungen zwischen Anforderungen herstellen und verifizierenAnforderungen können bei der Definition der Anforderungsarchitektur auf ver-schiedene Weise zueinander in Beziehung gesetzt werden. Der Business-Analystuntersucht und analysiert die Anforderungen, um die Beziehungen zwischendiesen Anforderungen zu definieren. Die Darstellung dieser Beziehungen wirdin „Anforderungen rückverfolgen“ vorgegeben (siehe Kap. 5.1).

Der Business-Analyst untersucht jede Beziehung, damit diese die folgenden Qua-litätskriterien erfüllt:

• Definiert: Es gibt eine Beziehung und ihr Typ ist beschrieben.• Notwendig: Die Beziehung ist notwendig, um die Anforderungen ganzheitlich verstehen zu können.

• Korrekt: Die Elemente stehen tatsächlich in der beschriebenen Beziehung.• Unzweideutig: Es gibt keine Beziehungen, die Elemente auf zwei unterschiedliche Arten verbinden und sich dabei widersprechen.

• Konsistent: Beziehungen werden gleichartig beschrieben, es werden die gleichen Sets von Standards genutzt, wie sie in den Viewpoints beschrieben sind.



178

.5 Informationsarchitektur der Business-AnalyseDie Struktur der Informationen der Business-Analyse ist auch eine Informations-architektur. Dieser Architekturtyp ist als Teil der Aufgabe „Informationsmanage-ment der Business-Analyse planen“ (Kap. 3.4) definiert. Die Informationsarchi-tektur ist eine Komponente der Anforderungsarchitektur, weil sie beschreibt,wie alle Informationen der Business-Analyse für einen Change zusammenhängen.Sie definiert Beziehungen für Informationstypen wie Anforderungen, Designs,Modelltypen und Erhebungsergebnisse.

Wird dieser Typ einer Informationsstruktur verstanden, kann über eine Vollstän-digkeitsprüfung der Beziehungen sichergestellt werden, dass das gesamte Setan Anforderungen vollständig ist. Es empfiehlt sich, vor dem Aufbau der Infra-struktur (wie z.B. Werkzeuge zum Management des Anforderungs-Lebenszyklus,Software zum Architekturmanagement oder Dokumenten-Repositories) mit derDefinition dieser Architektur zu beginnen.


• Software zum Architekturmanagement: Modellierungssoftware ist hilf-reich, um das Ausmaß, die Komplexität und die Versionen der Beziehun-gen innerhalb der Anforderungsarchitektur zu managen.

• Rechtliche und regulatorische Informationen: Sie beschreiben rechtliche Vorschriften oder Regulierungen, die einzuhalten sind. Sie können Aus-wirkungen auf die Anforderungsarchitektur oder deren Ergebnisse haben.Zusätzlich sind Einschränkungen zu beachten, die sich aus Verträgen oderaus Standards ergeben.

• Methoden und Frameworks: Bieten ein Set an Modellen und Beziehungen zwischen den Modellen, um die unterschiedlichen Sichtweisen abzubilden.

Techniken

• Datenmodellierung: Dient zur Beschreibung der Anforderungsstruktur in Bezug auf die Daten.

• Funktionale Gliederung: Dient dazu, eine Organisationseinheit, ein Pro-dukt oder andere Elemente in ihre Einzelteile zu zerlegen.

• Interview: Damit kann gemeinsam die Anforderungsstruktur definiert werden.• Organisationsmodellierung: Dient dazu, die verschiedenen Organisations-einheiten, Stakeholder und deren Beziehungen zu verstehen, um so die relevanten Viewpoints zu bestimmen.

• Scope-Modellierung: Dient zur Identifikation der Elemente und Grenzen der Anforderungsarchitektur.

• Workshop: Damit kann gemeinsam die Anforderungsstruktur definiert werden.



179

7.4.5

7.4.6

Stakeholder

• Fachexperte, Umsetzungsexperte, Projektmanager, Auftraggeber, Tester: Sie alle können bei der Definition und Bestätigung der Anforderungs-architektur mitwirken.

• Alle Stakeholder: Sie können auch die Anforderungsarchitektur nutzen, um die Vollständigkeit der Anforderungen zu überprüfen.

Outputs

• Anforderungsarchitektur: Anforderungen und deren wechselseitige Beziehungen, sowie die Informationen zum Kontext.

Design-Optionen definieren

Zweck

Der Zweck von „Design-Optionen definieren“ ist es, den Lösungsansatz zu defi-nieren, Verbesserungsmöglichkeiten im Unternehmen zu identifizieren, die Anfor-derungen auf die Lösungskomponenten zuzuordnen und Design-Optionen dar-zustellen, welche den gewünschten Soll-Zustand erfüllen.

Beschreibung

Beim Design einer Lösung können eine oder mehrere Design-Optionen (Varianten)identifiziert werden. Jede Design-Option entspricht einem Weg, ein Set vonAnforderungen zu erfüllen. Design-Optionen sind konkreter als die Change-Strategie. Sie sind taktisch, nicht strategisch. Bei der Entwicklung einer Lösungist oft zwischen Alternativen abzuwägen, die jeweils unterschiedliche Vorteilehaben (wenn man das eine will, muss man das andere mögen). Hier wird auchvon Trade-offs gesprochen. Der Business-Analyst muss den Effekt dieser Trade-offs beurteilen. Mit dem zeitlichen und inhaltlichen Fortschritt einer Initiativeändern sich Anforderungen und auch Design-Optionen.

Inputs

• Change-Strategie: Sie beschreibt den Ansatz, wie der Übergang zum Soll-Zustand erreicht wird. Dies kann bei Design-Entscheidungen Einfluss darauf haben, was machbar oder möglich ist.

• Anforderungen (validiert, priorisiert): Nur validierte Anforderungen werdenin Design-Optionen berücksichtigt. Das Wissen über den jeweiligen Stel-



180

7.4.8

7.4.7

7.5

7.5.1

7.5.2

7.5.3

lenwert der Anforderungen erleichtert die Erarbeitung angemessener Design-Optionen. Anforderungen der höchsten Prioritätsstufe können beider Auswahl von Lösungskomponenten stärker gewichtet werden als Anforderungen geringer Priorität.

• Anforderungsarchitektur: Das gesamte Set von Anforderungen und deren Beziehungen sind wichtig bei der Definition von Design-Optionen, die das Set von Anforderungen gesamthaft (holistisch) berücksichtigen können.

Abb. 7.5.1: Input-Output-Diagramm „Design-Optionen definieren“



181

Input

Output

Design-Optionen

7.5

Design-Optionen definieren7.5


7.4

Anforderungen(priorisiert,validiert)

5.3, 7.3

Change-Strategie6.4



6.4Nutzenpotential analysieren und

Lösung empfehlen

7.6




Scope der Lösung

Ist-Lösungen

Elemente

.1 Lösungsansätze beschreibenDer Lösungsansatz beschreibt, ob Lösungskomponenten selbst produziert oderzugekauft werden, oder eine Kombination von beidem. Der Business-Analystbeurteilt die Vorteile der Lösungsansätze für jede Design-Option:

• Selbst produzieren: Lösungskomponenten werden für ein Set von Anforderungen von Experten zusammengebaut, konstruiert oder ent-wickelt. Die Anforderungen und die Design-Optionen sind detailliert genug, um zu entscheiden, welche Lösung produziert werden soll. Zu dieser Option gehört auch die Modifikation einer bestehenden Lösung.

• Zukaufen: Lösungskomponenten werden aus solchen Angeboten aus-gewählt, welche die Anforderungen erfüllen. Anforderungen und Design-Optionen sind ausreichend detailliert, um eine Empfehlung abzugeben, welche Lösung gekauft werden soll. Solche Angebote sind normalerweise Produkte oder Dienstleistungen im Eigentum von Dritten, die auch die Wartung übernehmen.

• Kombination von beidem: Nicht alle Design-Optionen fallen strikt in eine der oben genannten Kategorien. In Design-Optionen können Eigenproduktion und Zukauf von Komponenten miteinander kombi-niert werden.

Bei allen Ansätzen wird die vorgeschlagene Integration von Komponenten eben-falls in der Design-Option berücksichtigt.

.2 Verbesserungsmöglichkeiten identifizierenWenn Design-Optionen vorgeschlagen werden, ergeben sich häufig weitereChancen, die Arbeit eines Unternehmens zu verbessern, die ebenfalls zu berück-sichtigen sind.

Typische Beispiele für Chancen sind:• Effizienz steigern: Über Reengineering oder gemeinsam genutzte Prozesse, veränderte Verantwortlichkeiten oder Outsourcing kann die Arbeit von Personen automatisiert oder vereinfacht werden. Die Auto-matisierung kann auch dazu führen, dass zukünftig gleiche Funktionendurch verschiedene Stakeholder gleichartig ausgeführt werden, was imIst-Zustand oft nicht der Fall ist.

• Informationszugang verbessern: Die Mitarbeiter, die direkt oder indi-rekt mit den Kunden in Kontakt stehen, erhalten mehr und bessere Informationen, was den Bedarf an Spezialisten reduziert.

• Zusätzliche Fähigkeiten identifizieren: Es werden Fähigkeiten verdeut-licht, die das Potential besitzen, im Zusammenhang mit der Lösung zukünftig Nutzen zu schaffen. Diese Fähigkeiten mögen nicht zwin-



182

7.5.4

gend genutzt werden und auch nicht sofort für das Unternehmen wert-voll sein (beispielsweise eine Software-Applikation mit Features, welchedas Unternehmen erst in der Zukunft nutzen will), sie bieten aber eineChance.

.3 Anforderungen zuordnenDie Zuordnung der Anforderungen ist der Prozess der Zuweisung von Anforde-rungen zu Lösungskomponenten und Releases, um die Ziele bestmöglich zuerreichen. Die Zuordnung wird durch die Beurteilung der Abwägungen (Trade-offs) der Alternativen unterstützt, um so den Nutzen zu maximieren und dieKosten zu minimieren. Der Nutzen einer Lösung kann auch davon abhängen,wie Anforderungen umgesetzt werden und wann die Lösung für die Stakeholderzur Verfügung steht. Das Ziel der Zuordnung ist es, diesen Nutzen zu maximieren.

Anforderungen können Organisationseinheiten, Funktionen, Lösungskompo-nenten oder Releases einer Lösung zugeordnet werden. Die Zuordnung derAnforderung beginnt normalerweise, wenn ein Lösungsansatz bestimmt wurdeund wird fortgesetzt, bis alle gültigen Anforderungen zugeordnet sind. DieZuordnung begleitet typischerweise das Design und die Umsetzung einer Lösung.

.4 Design-Optionen beschreibenDesign-Optionen werden untersucht und entwickelt, während über den erwünsch-ten Soll-Zustand nachgedacht wird, um damit sicherzustellen, dass die Design-Option valide ist. Für jede Design-Option sind Kennzahlen der Lösungs-Performancezu definieren.

Eine Design-Option besteht normalerweise aus mehreren Komponenten, die alsDesign-Element beschrieben werden. Design-Elemente können sein:

• Unternehmenspolitik und Geschäftsregeln• Geschäftsprozesse, die ausgeführt und gesteuert werden müssen• Personen, die die Lösung umsetzen und pflegen, inklusive deren Funktionen und Verantwortlichkeiten

• zu treffende operative Entscheidungen• in der Lösung eingesetzte Software-Applikationen und Applikations-komponenten

• Organisationsstrukturen, inklusive der Interaktionen zwischen demUnternehmen, seinen Kunden und seinen Lieferanten.


• Ist-Lösungen: Bestehende Produkte oder Leistungen, die oft von Dritten erbracht und als Komponente einer Design-Option angesehen werden.



183

7.5.5

• Beschreibung des Soll-Zustands: Damit wird der gewünschte Zustand des Unternehmens ermittelt, in dem die Design-Optionen enthalten sind. Diesist eine Voraussetzung dafür, dass diese Optionen auch genutzt werden können.

• Anforderungen (rückverfolgt): Sie definieren die Design-Optionen, die am besten die bereits bekannten Anforderungen erfüllen.

• Scope der Lösung: Definiert die Grenzen für die Auswahl möglicher Design-Optionen.

Techniken

• Benchmarking und Marktanalyse: Dienen der Identifikation und Analyse bestehender Lösungen und Markttrends.

• Brainstorming: Helfen dabei, Verbesserungsmöglichkeiten und Design-Optionen zu entdecken.

• Dokumentenanalyse: Liefert die Informationen, die benötigt werden, um Verbesserungsmöglichkeiten und Design-Optionen zu beschreiben.

• Interview: Dient dazu, Verbesserungsmöglichkeiten und Design-Optionen zu entdecken.

• Lessons Learned: Hilft dabei, Verbesserungsmöglichkeiten zu entdecken.• Mind Mapping: Trägt dazu bei, mögliche Design-Optionen zu identifizie-ren und zu entdecken.

• Ursachenanalyse: Mit ihrer Hilfe können Ursachen für Probleme in einem Change verstanden und Lösungen vorgeschlagen werden.

• Umfrage oder Fragebogen: Dienen dazu, Verbesserungsmöglichkeiten und Design-Optionen zu entdecken.

• Anbieter-Assessment: Die Beurteilung einer externen (Drittpartei-) Lösung ist mit einer Lieferantenbeurteilung zu koppeln, um sicherzustellen, dass die Lösung tragfähig ist und alle Beteiligten eine gute Arbeitsbeziehung aufbauen und pflegen können.

• Workshop: Hilft, Verbesserungsmöglichkeiten und Design-Optionen zu entdecken.

Stakeholder

• Fachexperte: Er bringt sein Wissen über das Unternehmen ein, um bei derBewertung der Lösungsalternativen, insbesondere hinsichtlich des Nutzen-potentials einer Lösung, Input und Feedback zu geben.

• Umsetzungsexperte: Er nutzt seine Kenntnisse über die Design-Optionen, um Informationen zu den Restriktionen und Grenzen einer Lösung und zuderen Kosten zu liefern.



184

7.5.6

7.5.7

• Operativer Support: Er kann helfen bei der Bewertung des Schwierigkeits-grads und den Kosten der Integration der vorgeschlagenen Lösung in die bestehenden Prozesse und Systeme.

• Projektmanager: Er plant und managt den Prozess der Lösungsdefinition, inklusive des Scopes der Lösung und aller Risiken, die mit der vorgeschla-genen Lösung zusammenhängen.

• Lieferant: Er gibt Auskunft über die Funktionalität einer bestimmten Design-Option.

Outputs

• Design-Optionen: Sie beschreiben verschiedene Wege, wie ein oder mehrere Bedarfe in einem Kontext befriedigt werden können. Sie können einen Lösungsansatz sowie Verbesserungsmöglichkeiten durch die Option und deren Komponenten beinhalten.

Nutzenpotential analysieren und Lösung empfehlen

Zweck

Der Zweck von „Nutzenpotential analysieren und Lösung empfehlen“ ist es,den möglichen Wert jeder einzelnen Design-Option zu ermitteln und darzulegen,welche Option die betrieblichen Anforderungen am besten erfüllt.

Beschreibung

„Nutzenpotential analysieren und Lösung empfehlen“ beschreibt, wie das Nut-zenpotential eingeschätzt und modelliert wird, das mit einem Set von Anforde-rungen, Designs oder Design-Optionen geliefert wird. Während eines Changewird das Nutzenpotential viele Male analysiert. Diese Analyse kann geplant seinoder durch einen veränderten Kontext oder einen anderen Scope des Changeausgelöst werden. Bei der Analyse des Nutzenpotentials wird davon ausgegangen,dass Schätzungen mit Unsicherheit behaftet sind. Der Nutzen kann finanziellerArt sein, sich aber auch in der Reputation oder in der Stellung am Markt aus-drücken. Jeder Change kann aus einem Mix an Minderungen und Steigerungendes Nutzens bestehen.

Die Design-Optionen werden hinsichtlich ihres Nutzenpotentials miteinanderverglichen. Jede Option besitzt Vor- und Nachteile, die es zu beurteilen gilt.Abhängig von der Begründung für einen Change kann es sein, dass keine Optionals beste empfohlen werden kann, oder es liegt eine eindeutig beste Variante



185

7.5.8

7.6.1

7.6

7.6.2

vor. Das kann zur Folge haben, dass man an mehr als einer Design-Option mitder Arbeit beginnt, um dann, eventuell mit dem Ziel einer Machbarkeitsstudie,die Leistung jeder Option zu bestimmen. In anderen Fällen können alle vorge-schlagenen Designs verworfen und weitere Analysen notwendig werden, umein geeignetes Design zu finden. Es ist auch möglich, dass die Empfehlunglautet, den Ist-Zustand beizubehalten.

Inputs

• Potentieller Nutzen: Es kann als Benchmark für die von den einzelnen Designs geschaffenen Nutzen dienen.

• Design-Optionen: Sie sind zu bewerten und zu vergleichen, damit eine Option als Lösung empfohlen werden kann.

Abb. 7.6.1: Input-Output-Diagramm „Nutzenpotential analysieren und Lösung empfehlen“



186

Input


Nutzenpotential analysierenund Lösung empfehlen

7.6

Output


Unternehmensziele



Scope der Lösung


6.4

Lösungs-empfehlung

7.6

PotentiellerNutzen

6.2Design-

Optionen

7.5


7.6.3

Elemente

.1 Erwarteter NutzenErwartete Vorteile beschreiben den positiven Wertbeitrag, den eine Lösung denStakeholdern bringen soll. Werte können Vorteile, die Verringerung eines Risikos,Compliance mit betrieblichen Richtlinien und Vorschriften sein, wie auch einebessere Handhabung durch die Benutzer oder jedes andere positive Ergebnis.Der Nutzen wird ermittelt, indem die von den Stakeholdern erwünschten Vorteileverglichen werden mit den tatsächlich erzielbaren Vorteilen. Die erwarteten Vor-teile werden auf der Basis einer Anforderung oder eines Sets von Anforderungenermittelt. Dabei wird berücksichtigt, inwieweit die Unternehmensziele erfülltwerden. Die Summe des Nutzens sind die Nettovorteile aller Anforderungen,die ein bestimmtes Design erfüllt. Solcher Nutzen ergibt sich oft erst im Laufeder Zeit.

.2 Erwartete KostenZu den erwarteten Kosten gehören alle Wertminderungen, die mit einer Lösungverbunden sind, einschließlich der Kosten für die Beschaffung der Lösung, dernegativen Auswirkungen auf die Stakeholder und der Kosten derWartung/Instandhaltung im laufenden Betrieb.

Zu den erwarteten Kosten gehören• Zeitaufwand• Betriebskosten• Beschaffungs- und Umsetzungskosten• Instandhaltungskosten• Materialkosten• Informationskosten• Personalkosten.

Zu den erwarteten Kosten einer Design-Option gehören die gesamten Kostenaller Komponenten.

Der Business-Analyst berücksichtigt auch Opportunitätskosten, wenn er dieerwarteten Kosten eines Change einschätzt. Opportunitätskosten sind alternativeErgebnisse, die erreicht worden wären, wenn die Ressourcen, Zeit und Geldmitteleiner Design-Option in eine andere Option investiert worden wären. Die Oppor-tunitätskosten einer Design-Option entsprechen dem Wert der besten, nichtausgeführten Alternative.


Nutzenpotental analysieren und Lösung empfehlen

187

7.6.4

.3 Nutzen bestimmenDas Nutzenpotential einer Lösung für einen Stakeholder basiert auf den erzeugtenVorteilen dieser Lösung und den dadurch entstandenen Kosten. Der Gesamt-nutzen für einen Stakeholder kann positiv sein (wenn der Nutzen höher ist alsdie Kosten) oder negativ (wenn die Kosten den Nutzen übersteigen).

Der Business-Analyst berücksichtigt das Nutzenpotential aus der Perspektive derStakeholder.

Der Nutzen für das Unternehmen wird meistens stärker gewichtet als der Wertfür eine einzelne Stakeholder-Gruppe. Es kann sein, dass die Steigerung desNutzens für eine Stakeholder-Gruppe zu einer Minderung des Nutzens für eineandere Gruppe führt. Ein positiver Wertzuwachs aus der Gesamtsicht des Unter-nehmens kann den Change dennoch rechtfertigen.

Ein potentieller Nutzen ist immer unsicher. Es gibt immer Ereignisse oder Bedin-gungen, bei deren Eintritt der tatsächliche Nutzen gesteigert oder vermindertwird. Viele Changes werden aufgrund nicht messbarer oder unsicherer Vorteileausgelöst, während die Kosten zumeist messbar sind und sogar steigen können.Wenn Nutzen nicht messbar ist, die Kosten aber exakt bestimmt werden können,wird es für die Entscheidungsträger schwierig, Optionen zu vergleichen. DerBusiness-Analyst erarbeitet eine vollständige Schätzung der zweckgetriebenenund finanziellen Auswirkungen eines vorgeschlagenen Change, indem er diemessbaren und die nicht messbaren Kosten mit den messbaren und nicht mess-baren Vorteilen vergleicht. Die Kosten- und Nutzenschätzung muss dabei dasAusmaß an Unsicherheit zum Zeitpunkt der Schätzung berücksichtigen.

.4 Design-Optionen beurteilen und eine Lösung empfehlenJede Design-Option wird anhand des von ihr versprochenen Nutzenpotentialsbeurteilt. Während der Analyse der Design-Optionen kann es jederzeit notwendigwerden, die ursprüngliche Zuordnung der Design-Elemente zu den Komponentenneu zu bewerten. Das hat damit zu tun, dass mit dem Fortschritt des Vorhabensdie tatsächlichen Kosten der Umsetzung jeder Komponente klarer werden unddamit auch besser beurteilt werden kann, wo das beste Kosten-Nutzen-Verhältnisvorliegt.

Sobald Kosten und Aufwand für jede Lösungskomponente bekannt sind, beurteiltder Business-Analyst jede Design-Option und stellt so sicher, dass sie den größtenNutzen bringen. Dabei sind mehrere Faktoren zu berücksichtigen:

• Verfügbare Ressourcen: Die verfügbaren Ressourcen können die umsetzbaren Anforderungen begrenzen. In einigen Fällen ist es zweck-mäßig, einen Business Case zu erstellen, um zusätzliche Investitions-mittel zu bewilligen.

• Lösungseinschränkungen: Regulatorische Anforderungen oder Unternehmensentscheidungen können vorschreiben, dass bestimmte



188

Anforderungen manuell oder automatisch abgewickelt werden oder dass bestimmte Anforderungen gegenüber anderen priorisiert werden.

• Abhängigkeiten zwischen Anforderungen: Einige Fähigkeiten mögen für sich gesehen nur geringen Nutzen schaffen, müssen aber trotzdemaufgebaut werden, um andere hochwertige Anforderungen zu unter-stützen.

Andere Überlegungen können Beziehungen zu vorgeschlagenen Lieferanten,Abhängigkeiten zu anderen Vorhaben, zur Unternehmenskultur und zum fürdie Investition benötigten Cash-flow berücksichtigen.

Der Business-Analyst empfiehlt die Option (oder mehrere), die als die nützlichsteeingeschätzt wird und den Bedarf abdeckt. Es ist möglich, dass keine der Design-Optionen als umsetzungswürdig angesehen wird und deshalb empfohlen wird,den Status Quo beizubehalten.


• Unternehmensziele: Sie werden zur Ermittlung der erwarteten Vorteile genutzt.

• Beschreibung des Ist-Zustands: Der Ist-Zustand liefert den Kontext, in welchem die Arbeit zu erledigen ist. Die Beschreibung des Ist-Zustands ist hilfreich, um den Nutzen einer möglichen Lösung zu ermitteln und zu quantifizieren.

• Beschreibung des Soll-Zustands: Sie zeigt den erwünschten Soll-Zustand, zu dem die Lösung später gehören wird. Dies unterstützt die Formulie-rung geeigneter Design-Optionen, die dem Soll-Zustand gerecht werden.

• Ergebnisse der Risikoanalyse: Zum Nutzenpotential der Design-Optionen gehört auch eine Aussage über den Risikograd, der mit der empfohlenen Design-Option oder dem Vorhaben insgesamt verbunden ist.

• Scope der Lösung: Er beschreibt den Umfang der umzusetzenden Lösung, so dass eine Bewertung durchgeführt werden kann, die den Scope der Lösung mit einbezieht.

Techniken

• Akzeptanz- und Bewertungskriterien: Akzeptanzkriterien sind als Anfor-derungen besonders nützlich, um vorgeschlagene Lösungen zu bewerten und um zu überprüfen, ob eine Lösung den betrieblichen Bedarf deckt.

• Backlog Management: Wird genutzt, um den potentiellen Nutzen in eine Reihenfolge zu bringen.

• Brainstorming: Ist hilfreich, um gemeinsam mögliche Vorteile der Anfor-derungen zu ermitteln.



189

7.6.5

7.6.6

• Business Cases: Dienen dazu, Empfehlungen hinsichtlich der Erfüllung betrieblicher Ziele prüfen zu können.

• Darstellung des Geschäftsmodells: Bietet ein Werkzeug, um Strategien und Initiativen besser zu verstehen.

• Entscheidungsanalyse: Wird eingesetzt, um Design-Optionen zu beurtei-len und in eine Reihenfolge zu bringen.

• Schätzung: Als erster Schritt zur Einschätzung des Nutzens eines Vor-habens können die Kosten und der Aufwand vorhergesagt werden, die mit der Erfüllung der Anforderungen verbunden sind.

• Finanzanalyse: Dient der Bewertung der finanziellen Rendite verschiede-ner Optionen und der Auswahl des bestmöglichen Ertrags.

• Fokusgruppe: Damit wird Input von den Stakeholdern darüber eingeholt, welche Design-Option die Anforderungen am besten erfüllt und welchen Nutzen eine Gruppe von Stakeholdern erwartet.

• Interview: Dient dazu, Input von den Stakeholdern darüber einzuholen, welche Design-Option die Anforderungen am besten erfüllt, und dazu, die Nutzenerwartungen der Stakeholder zu bewerten.

• Kennzahlen und Key-Performance-Indikatoren (KPIs): Damit werden die Kennzahlen erzeugt und bewertet, die für die Ermittlung des Nutzens verwendet werden.

• Risikoanalyse und -management: Dienen dazu, Risiken zu identifizie-ren und zu managen, die einen Einfluss auf das Nutzenpotential der Anforderungen haben können.

• Umfrage oder Fragebogen: Mit ihnen wird Input von Stakeholdern darüber eingeholt, welche Design-Option die Anforderungen am besten erfüllt und welche Werterwartungen diese Stakeholder haben.

• SWOT-Analyse: Damit werden die Stärken und Schwächen ermittelt, die einen Einfluss auf den Wert der Lösungen haben.

• Workshop: Dient dazu, Input von den Stakeholdern darüber einzuholen, welche Design-Option die Anforderungen am besten erfüllt und welche Werterwartungen die Stakeholder haben.

Stakeholder

• Kunden: Sie repräsentieren die von den Anforderungen und Lösungen betroffenen Marktsegmente. Sie werden in die Analyse des Nutzens der Anforderungen und der Kosten und der Design-Optionen eingebunden.

• Fachexperte: Fachexperten bringen ihr Fachwissen in die Analyse des Nutzenpotentials und der Werte ein, insbesondere bei den Anforderun-gen, bei denen dies schwer zu bestimmen ist.



190

7.6.7

• Endanwender: Sie liefern Einblicke hinsichtlich des Nutzenpotentials eines Change.

• Umsetzungsexperte: Sie können helfen, die möglichen Kosten und Risikender Umsetzung der Design-Optionen zu bestimmen.

• Projektmanager: Sie managen den Auswahlprozess so, dass sie über die möglichen Auswirkungen für die Betroffenen bei der Umsetzung des Change informiert sind. Sie sind sich auch der Risiken bewusst, die mit dem Change verbunden sind.

• Regulator: Sie können bei Bewertung von Risiken beteiligt sein, die mit externen Regulatoren verbunden sind oder Restriktionen für möglichen Nutzen setzen.

• Auftraggeber: Er genehmigt die Ressourcen, die benötigt werden, um eine Lösung zu kaufen oder zu entwickeln, und entscheidet über die endgültige Empfehlung. Der Auftraggeber ist daran interessiert, über alle Veränderungen des Nutzenpotentials, der Risiken und der sich daraus ableitenden Opportunitätskosten informiert zu werden, da er sich so eventuell auch für eine andere Richtung entscheiden kann.

Outputs

• Lösungsempfehlung: Sie bietet die vorgeschlagene, am besten geeignete Lösung auf Basis einer Bewertung aller definierten Design-Optionen. Die empfohlene Lösung sollte den für das Unternehmen geschaffenen Nutzen maximieren.



191

7.6.8

193

Das Wissensgebiet „Lösungsbewertung“ beschreibt die Aufgaben, mit denender Business-Analyst beurteilt, ob die Lösungen während ihres Einsatzes imUnternehmen die versprochene Leistung und Wertschöpfung erbringen. DerBusiness-Analyst gibt auch Empfehlungen, wie Hindernisse umgangen und Eng-pässe eliminiert werden können, so dass der Gesamtnutzen für das Unternehmenbestmöglich ausgeschöpft wird.

Obwohl manche Ähnlichkeiten mit den Aufgaben in Kapitel 6 „StrategischeAnalyse“ oder Kapitel 7 „Anforderungsanalyse und Design-Definition“ bestehen,unterscheidet sich das Wissensgebiet „Lösungsbewertung“ von den anderenWissensgebieten hauptsächlich dadurch, dass nun eine konkrete Lösung zurBewertung vorliegt. Diese Lösung kann zwar noch unvollständig sein, Lösungs-komponenten sind jedoch bereits umgesetzt und in bestimmter Weise einsatz-bereit. Die Aufgaben der Lösungsbewertung zur Steigerung der Wertschöpfungkönnen vor dem Beginn eines Change, wobei der aktuelle Nutzen beurteiltwird, oder erst nach der Umsetzung einer Lösung durchgeführt werden.

Die Aufgaben der Lösungsbewertung können für Lösungskomponenten in ver-schiedenen Entwicklungsphasen durchgeführt werden:

• Prototypen oder Machbarkeitsnachweis: Dabei handelt es sich um eingeschränkte, aber verwendbare Lösungsversionen, die deren Nutzen zeigen.

• Pilot oder Beta Release: Das sind eingeschränkte Umsetzungen oder Lösungsversionen, die dazu dienen, Probleme aufzudecken und ver-stehen zu lernen, welchen Nutzen eine Lösung im Einsatz tatsächlich erzeugt, bevor die vollständige Lösung in den Echtbetrieb geht.

• Einsatz im Tagesgeschäft: Das sind Versionen einer teilweisen oder vollständigen Lösung, mit deren Einsatz Unternehmensziele erreicht, gewünschte Ergebnisse geschaffen oder Prozesse ausgeführt werden.

Die Lösungsbewertung beschreibt die Aufgaben, welche die tatsächlich erzielteWertschöpfung ermitteln, zeigt eventuell bestehende Einschränkungen bei derErreichung des angestrebten Nutzens und erarbeitet Empfehlungen, wie der Wert

8 Lösungsbewertung

der Lösung noch gesteigert werden kann. Dazu werden in verschiedenster FormPrüfungen der Performance, Tests und Experimente miteinander kombiniert.Dabei kann die Beurteilung des erreichten Nutzens sowohl objektiv nachprüfbarals auch subjektiv sein. Die Lösungsbewertung konzentriert sich üblicherweisenur auf einen Teil des Unternehmens und nicht auf das Gesamtunternehmen.

Die folgende Abbildung zeigt, wie die Aktivitäten der Business-Analyse von derpotentiellen Lösung bis zur konkreten Nutzenschöpfung fortschreiten.

Abb. 8.0.1: Wertstrahl der Business-Analyse

Das Wissensgebiet „Lösungsbewertung“ umfasst die folgenden Aufgaben:• Lösung-Performance: Es wird die am besten geeignete Vorgehens-weise festgelegt, wie die Performance einer Lösung zu ermitteln ist. Dazu gehören auch die Abstimmung mit den Unternehmenszielen und die Durchführung der Bewertung.

• Leistungskennzahlen analysieren: Es werden die notwendigen Informa-tionen gesammelt und untersucht, mit denen die Performance der Lösung gemessen und der Nutzen aufgezeigt wird, den sie für das Unternehmen und für die Stakeholder bereitstellen. Die Aufgabe klärt auch, ob die Lösung den gegenwärtigen betrieblichen Bedarf abdeckt.

• Einschränkungen der Lösung beurteilen: Es werden jene Aspekte untersucht, welche in dem gegenwärtigen Rahmen der Lösung verhindern, dass der derzeitige betriebliche Bedarf erfüllt wird.

• Einschränkungen des Unternehmens beurteilen: Es wird untersucht, welche außerhalb des Scopes der Lösung liegenden Aspekte ein Unternehmen daran hindern, die volle Nutzenschöpfung einer Lösung zu realisieren.

• Maßnahmen zur Steigerung des Nutzens der Lösung empfehlen: Es werden Maßnahmen identifiziert und definiert, die ein Unternehmen ergreifen kann, um den geschaffenen Nutzen einer Lösung zu erhöhen.

194

Lösungsbewertung

Bedarf

Potential Umsetzung

Scope derLösung

Anforderun-gen


Prototyp

Pilot/Beta-

version

Betrieb

StrategischeAnalyse


Lösungsbewertung

Das Kernkonzept-Modell in der LösungsbewertungDas Kernkonzept-Modell der Business Analyse (BACCM™) beschreibt die Bezie-hungen der sechs Kernkonzepte. Die folgende Tabelle gibt einen Überblick zuEinsatz und Verwendung jedes Kernkonzeptes in der Lösungsbewertung.

Tabelle 8.0.1: Das Kernkonzept-Modell in der Lösungsbewertung

Lösungsbewertung Das Kernkonzept-Modell in der Lösungsbewertung

195

Kernkonzept Der Business-Analyst in der Lösungsbewertung …


… empfiehlt eine Veränderung entweder derLösung oder des Unternehmens, um den ver-sprochenen Wertbeitrag einer Lösung auch zuerzielen.


… bewertet, wie eine Lösung oder Lösungs-komponente den Bedarf deckt.


… beurteilt die Performance einer Lösung,ermittelt, ob sie den versprochenen Nutzenbringt, und analysiert gegebenenfalls, weshalbdieser Wert nicht von der Lösung bzw. Lösungs-komponente erbracht wird.


… sammelt von den Stakeholdern Informatio-nen über die Performance der Lösung undderen Wertbeitrag..


… ermittelt, ob eine Lösung den versprochenenNutzen erbringt und analysiert gegebenenfalls,weshalb dieser Nutzen von der Lösung bzw.Lösungskomponente nicht erbracht wird.


… analysiert den Kontext bei der Ermittlung derLösungs-Performance und alle Einschränkungenund Nebenbedingungen, welche die Erzielungdes vollen Nutzenbeitrags einer Lösung behin-dern könnten.

Abb. 8.0.2: Input-Output-Diagramm „Lösungsbewertung“

LösungsbewertungLösungsbewertung

196

Aufgaben

Output

Input

UmgesetzteLösung (extern)


BetrieblicheZiele

6.2

PotentiellerNutzen

6.2

8.1Leistungskenn-

zahlen analysieren

8.2Einschränkungen

der Lösungbeurteilen

8.3


beurteilen

8.4 8.5

Leistungskenn-zahlen fürLösungen

8.1 8.2

Einschränkungender Lösung

8.3

EmpfohleneMaßnahmen

8.5

Analyse derLösungs-

Performance

6.1


8.4



Lösungs-Performance

Zweck

Der Zweck von „Lösungs-Performance“ ist die Definition von Leistungskennzahlen,um auf Basis der gesammelten Informationen die Effektivität und Effizienz einerLösung über ihren Nutzenbeitrag zu ermitteln.

Beschreibung

Leistungskennzahlen bestimmen den Nutzen einer neu eingesetzten oder bereitsbestehenden Lösung. Die zum Einsatz kommenden Kennzahlen sind abhängig vonder Lösung selbst, dem Kontext und davon, wie das Unternehmen Nutzen definiert.Sollte eine Lösung keine eigenen Kennzahlen liefern, erarbeitet der Business-Analystgemeinsam mit den Stakeholdern die für die Messung der Wertschöpfung ambesten geeigneten Kennzahlen und legt fest, wie die Informationen gesammeltwerden, die dazu notwendig sind. Die Leistung kann durch Kennzahlen (Key Per-formance Indicators, KPIs) ermittelt und mit den Zielen eines Unternehmens, einesProjekts, eines Prozesses oder mit Tests einer Software-Anwendung abgeglichenwerden.

Inputs

• Betriebliche Ziele: Das sind messbare Ergebnisse, welche ein Unterneh-men erreichen will. Sie dienen als Benchmark für die Lösungs-Performance.

• Umgesetzte Lösung (extern): Eine tatsächlich bestehende Lösung oder Lösungskomponente in Form eines Prototyps, eines Piloten oder einer Beta-Lösung.

Lösungsbewertung Lösungs-Performance messen

197

8.1.1

8.1

8.1.2

8.1.3

Abb 8.1.1: Input-Output-Diagramm „Lösungs-Performance messen“

Elemente

.1 Kennzahlen für die Lösungs-Performance definierenVor der Definition neuer Kennzahlen ist zu klären, ob bereits Kennzahlen existierenoder ob es Methoden gibt, wie sie gewonnen werden sollen. Der Business-Analyst überprüft und stellt sicher, dass die bestehenden Kennzahlen korrektund relevant sind. Er erhebt auch weitere von den Stakeholdern identifizierteKennzahlen.

Unternehmens- und Prozessziele sind typische Quellen für Kennzahlen. Dritte,wie Anbieter von Lösungen, staatliche Institutionen oder Regulatoren, könnenLeistungskennzahlen beeinflussen oder vorgeben. Die Art und Weise der Messung

LösungsbewertungLösungs-Performance

198

Input

Leistungskenn-zahlen fürLösungen

8.1


6.1 Leistungskenn-

zahlen analysieren

8.2


Lösungs-Performance messen8.1

Output


Change-Strategie


Anforderungen(validiert)

Scope der Lösung


BetrieblicheZiele

6.2

8.1.4

ist bei der Auswahl der Erhebungsmethode zu berücksichtigen. Die Maßstäbefür die Lösungs-Performance können quantitativ, qualitativ oder beides gemeinsamsein, je nach dem zu messenden Wert.

• Quantitative Messgrößen (Kennzahlen): Sie sind numerisch, zählbar oder endlich. Gewöhnlich handelt es sich um absolute Werte oder Relationen.

• Qualitative Messgrößen: Sie sind subjektiv und umfassen Einstellungen, Wahrnehmungen und andere subjektive Kategorien. Kunden, Anwen-der und andere Nutzer der Lösung können einschätzen, wie gut eine Lösung ihren Bedarf abdeckt.

.2 Kennzahlen der Lösungs-Performance validierenDie Validierung der Kennzahlen der Lösungs-Performance stellt sicher, dass dieBeurteilung der Lösungen auch Nutzen stiftet. Der Business-Analyst validiertgemeinsam mit den Stakeholdern die Performance-Kennzahlen und die Kriterien,welche diese beeinflussen. Einzelne Kennzahlen der Leistung sollten sich in einübergeordnetes Kennzahlengerüst im Umfeld der Lösung einfügen lassen. DieEntscheidung, welche Kennzahlen zur Bewertung einer Lösung eingesetzt werden,liegt oft beim Auftraggeber, sie kann aber auch von jedem entscheidungsbefugtenStakeholder getroffen werden.

.3 Kennzahldaten der Lösungs-Performance sammelnBei der Definition der Kennzahlen der Leistung verwendet der Business-AnalystKonzepte, die sich in Stichprobenverfahren bewährt haben. Bei der Datensamm-lung berücksichtigt er folgende Sachverhalte:

• Umfang oder Stichprobengröße: Es wird der Umfang oder die Größe einer Stichprobe festgelegt, die für das Vorhaben angemessen ist. Einezu kleine Stichprobe kann die Ergebnisse verfälschen. Große Stichpro-ben sind zwar wünschenswert, können in der Praxis aber nur schwer zu realisieren sein.

• Häufigkeit und Rhythmus: Die Häufigkeit und der Rhythmus der Datenerhebung kann sich auf das Ergebnis auswirken.

• Aktualität: Erst vor kurzem erhobene Daten spiegeln normalerweise die Tatsachen besser wider als ältere Daten.

Qualitative Messgrößen können die Diskussion über den Nutzen und die Ein-schätzung des Nutzens einer Lösung erleichtern. Stakeholder, die mit dem Einsatzund der Anwendung einer Lösung vertraut sind, können sich auf der Basis dervorliegenden Fakten und vernünftiger Annahmen leichter einigen und zu einergemeinsamen Bewertung gelangen.

Lösungsbewertung Lösungs-Performance

199


• Change-Strategie: Die einzusetzende oder eingesetzte Veränderungs-strategie, die mit der Umsetzung den versprochenen Nutzen bringt.

• Beschreibung des Soll-Zustands: Die Beschreibung legt die Grenzen vorge-schlagenen neuen, abgelösten oder modifizierten Komponenten des Unternehmens und den Nutzen dar, der vom Soll-Zustand erwartet wird.

• Anforderungen (validiert): Ein Satz von analysierten und hinsichtlich ihres Nutzenbeitrags beurteilten Anforderungen.

• Scope der Lösung: Die Grenzen des zu messenden und zu bewertenden Lösungsumfangs.

Techniken

• Akzeptanz- und Bewertungskriterien: Dienen dazu, eine akzeptable Lösungs-Performance zu definieren.

• Benchmarking und Marktanalyse: Werden eingesetzt, um Kenngrößen und Akzeptanzniveaus zu definieren.

• Business Cases: Mit ihrer Hilfe werden die betrieblichen Ziele und die Kennzahlen für die Performance der vorgeschlagenen Lösung definiert.

• Data Mining: Dient der Sammlung und Analyse von großen Daten-mengen über die Leistung/Performance der Lösung.

• Entscheidungsanalyse: Hilft den Stakeholdern bei der Auswahl geeigneterKriterien für die Performance und angemessener Leistungsniveaus.

• Fokusgruppe: Liefert subjektive Beurteilungen, Einsichten und Eindrücke der Performance der Lösung.

• Kennzahlen und Key-Performance-Indikatoren (KPIs): Dienen dazu, die Lösungs-Performance zu messen.

• Analyse nicht-funktionaler Anforderungen: Werden eingesetzt, um die erwarteten Eigenschaften einer Lösung zu definieren.

• Beobachtung: Trägt dazu bei, entweder Feedback zur Wahrnehmung der Performance zu erhalten oder widersprüchliche Ergebnisse einem Reali-täts-Check zu unterziehen.

• Prototyping: Dient der Simulation einer neuen Lösung, so dass Kennzah-len der Performance ermittelt und gesammelt werden können.

• Umfrage oder Fragebogen: Dienen dazu, Meinungen und Einstellungen über die Lösungs-Performance zu erheben. Umfragen und Fragebogen können sehr effektiv sein, wenn große oder sehr unterschiedliche Grup-pen befragt werden müssen.

LösungsbewertungLösungs-Performance

200

8.1.5

8.1.6

• Use Cases und Szenarien: Mit ihrer Hilfe kann das erwartete Ergebnis einer Lösung definiert werden.

• Anbieter-Assessment: Dient der Beurteilung, welche Performance-Kennzahlen eines Lieferanten in die Bewertung der Performance der Lösung einfließen sollen.

Stakeholder

• Kunde: Er kann um Feedback zur Performance von Lösungen gebeten werden.

• Fachexperte: Er kann dank seines Wissens über das Fachgebiet Kenn-zahlen vorschlagen.

• Endanwender: Er trägt maßgeblich zum tatsächlichen Nutzen einer Lösung bei, der durch die Kennzahlen der Performance gemessen wird. Er kann zu seiner Beurteilung und zum Feedback etwa über die Arbeits-belastung oder die Arbeitszufriedenheit befragt werden.

• Projektmanager: Er ist für die Termin- und Aufgabenplanung und für die Durchführung der Messung der Performance verantwortlich. Werden Lösungen bereits eingesetzt, kann diese Rolle entfallen.

• Sponsor: Er ist für die Genehmigung der Kennzahlen zur Bewertung der Performance verantwortlich und kann auch Erwartungen zur Performanceabgeben.

• Regulator: Eine externe oder interne Gruppe, die Einschränkungen oder Richtlinien vorgeben oder vorschreiben kann, die in die Messgrößen zur Lösungs-Performance übernommen werden müssen.

Outputs

• Leistungskennzahlen für Lösungen: Messgrößen, die Informationen darüber liefern, wie gut die Leistung der Lösung ist oder sein könnte.

Leistungskennzahlen analysieren

Zweck

Der Zweck der Aufgabe „Leistungskennzahlen analysieren“ ist es, Einblick inden Nutzen zu gewinnen, den eine Lösung bringt.

Lösungsbewertung Leistungskennzahlen analysieren

201

8.1.7

8.1.8

8.2

8.2.1

Beschreibung

Die in der Aufgabe „Lösungs-Performance“ (Kap. 8.1) gesammelten Messgrößenmüssen interpretiert und zusammengefasst werden, um ihnen Sinn zu gebenund Maßnahmen ableiten zu können. Messgrößen der Performance allein habennur selten direkt Entscheidungen über den Nutzen einer Lösung zur Folge.

Um die Kennzahlen der Performance sinnvoll analysieren zu können, muss derBusiness-Analyst sich über den potentiellen Nutzen klarwerden, den die Stake-holder mit der Lösung erreichen wollen. Dabei können folgende Größen dieAnalyse erleichtern: Unternehmensziele, Key Performance Indicators (KPIs), dasRisiko-Niveau der Lösung, die Risikoneigung sowohl der Stakeholder als auchdes Unternehmens und sonstige Ziele.

Inputs

• Potentieller Nutzen: Er beschreibt den Nutzen, der durch die Umsetzung des vorgeschlagenen Soll-Zustands erzielt werden kann. Er kann als Benchmark für die Bewertung der Performance der Lösung genutzt werden.

• Leistungskennzahlen für Lösungen: Sie messen und liefern Informationen darüber, wie gut eine Lösung funktioniert oder potentiell funktionieren könnte.

LösungsbewertungLeistungskennzahlen analysieren

202

8.2.3

8.2.2

Abb. 8.2.1: Input-Output-Diagramm „Leistungskennzahlen analysieren“

Elemente

.1 Performance von Lösungen vs. ZielwertDer Business-Analyst untersucht die bereits vorhandenen Messgrößen, ob sieden Stakeholdern dabei helfen können, den Nutzen einer Lösung zu verstehen.Eine Lösung kann durchaus eine gute Performance haben, wie beispielsweiseein effizientes Online-Transaktionssystem, aber dennoch nicht den erwarteten(oder den früher erzielten) Nutzen bringen. Andererseits kann eine nur wenigeffektive, aber potentiell wertvolle Lösung, wie etwa ein ineffizienter Kernprozess,durch Verbesserungsmaßnahmen eine Leistungssteigerung erfahren. Sind die


203

Input


Performance

8.2


Leistungskennzahlen analysieren8.2

Output


Change-Strategie



Scope der Lösung

PotentiellerNutzen

6.2Leistungskenn-

zahlen fürLösungen

8.1

8.3Einschränkungen

der Lösungbeurteilen


beurteilen

8.4

8.2.4

Kennzahlen nicht dazu geeignet, dass die Stakeholder den Nutzen der Lösungbewerten können, sollte der Business-Analyst entweder weitere Werte ermittelnoder die fehlenden Werte wie ein Risiko der Lösung behandeln.

.2 RisikenDie Messung der Performance kann neue Risiken für die Performance der Lösungoder für das Unternehmen aufdecken. Diese Risiken werden genauso identifiziertund gemanagt wie alle anderen Risiken.

.3 TrendsBei der Analyse von Performance-Informationen berücksichtigt der Business-Analyst auch die Zeitperiode, in der die Daten gesammelt wurden, um gegenAusreißer und Verzerrungen gewappnet zu sein. Eine genügend große Stichprobeüber einen längeren Zeitraum hinweg liefert ein korrekteres Bild der Performance,auf deren Basis Entscheidungen getroffen werden können. Damit wird auchdas Risiko von Fehlinformationen wegen unvollständiger Daten gesenkt. Alledeutlich erkennbaren und sich wiederholenden Trends, wie beispielsweise eineZunahme von Fehlern zu bestimmten Zeiten oder eine Veränderung der Pro-zessgeschwindigkeit bei erhöhtem Auftragsvolumen, sind zu dokumentieren.

.4 ExaktheitDie Präzision der Messung der Performance ist ausschlaggebend für die Gültigkeitder Analyse. Der Business-Analyst testet und analysiert die gesammelten Datenhinsichtlich ihrer Korrektheit. Ergebnisse sind nur dann korrekt und verlässlich,wenn die Messung der Performance reproduzierbar ist.

.5 Performance-VariationDer Unterschied zwischen der erwarteten und der tatsächlichen Performanceergibt eine Abweichung, die bei der Analyse der Performance zu berücksichtigenist. Eine Ursachenanalyse kann die zugrundeliegenden Treiber bedeutenderAbweichungen in einer Lösung aufdecken. Empfehlungen, wie die Performancegesteigert und Abweichungen reduziert werden können, finden sich in der Auf-gabe „Maßnahmen zur Steigerung des Nutzens der Lösung empfehlen“ (Kap.8.5).


• Change-Strategie: Die verwendete oder zu verwendende Veränderungs-strategie, um den potentiellen Nutzen zu erreichen.

• Beschreibung des Soll-Zustands: Die Beschreibung legt die Grenzen der vorgeschlagenen neuen, abgelösten oder modifizierten Komponenten desUnternehmens und den Nutzen dar, der vom Soll-Zustand erwartet wird.

LösungsbewertungLeistungskennzahlen analysieren

204

8.2.5

• Ergebnisse der Risikoanalyse: Das Gesamtrisiko-Niveau und das geplante Vorgehen, wie individuelle Risiken modifiziert werden.


Techniken

• Akzeptanz- und Bewertungskriterien: Dienen dazu, die akzeptable Perfor-mance der Lösung festzusetzen. Die Analyse der Performance wird auch mit Blick auf die Erfüllung der Akzeptanzkriterien vorgenommen.

• Benchmarking und Marktanalyse: Werden eingesetzt, um bei der Risiko-, Trend- und Abweichungsbeurteilung die Ergebnisse anderer Unterneh-men zu berücksichtigen, die ähnliche Lösungen nutzen.

• Data Mining: Dient dazu, Daten über die Performance, Trends, Gemein-samkeiten und Abweichungen von den erwarteten Niveaus der Perfor-mance zu ermitteln und Muster und Wirkzusammenhänge in diesen Daten erkennen zu können.

• Interview: Wird eingesetzt, um den erwarteten Nutzen einer Lösung und deren wahrgenommene Performance gemeinsam mit einzelnen Personen oder kleinen Gruppen festzustellen.

• Kennzahlen und Key-Performance-Indikatoren (KPIs): Dienen dazu, die Performance einer Lösung insbesondere im Hinblick auf den Grad der Zielerreichung zu analysieren.

• Beobachtung: Ist geeignet, um eine Lösung im Echteinsatz anzusehen, wenn die gesammelten Daten keine definitiven Aussagen zulassen.

• Risikoanalyse und -management: Dient dazu, Risiken zu identifizieren, zuanalysieren und Pläne zur Modifikation und zum Management der Risiken im Tagesgeschäft/Regelprozess zu entwickeln.

• Ursachenanalyse: Mit ihrer Hilfe können die tieferliegenden Ursachen von Schwankungen der Performance ermittelt werden.

• Umfrage oder Fragebogen: Werden genutzt, um den erwarteten Nutzen einer Lösung und deren wahrgenommene Performance festzustellen.

Stakeholder

• Fachexperte: Er kann Risiken identifizieren und Einsichten über die Daten der Performance-Analyse liefern.

• Projektmanager: Er ist innerhalb des Projekts für das gesamte Risiko-management verantwortlich und kann an der Analyse von Risiken für neue oder geänderte Lösungen mitwirken.


205

8.2.6

8.2.7

• Sponsor: Er kann Risiken identifizieren, Einblick in die Daten und Aussagen über den möglichen Nutzen einer Lösung liefern. Er entscheidet über die Bedeutung von Abweichungen im Soll-Ist-Vergleich der Leistung.

Outputs

• Analyse der Lösungs-Performance: Sie beinhaltet die Ergebnisse der Analyse aus den gesammelten Informationen und die Empfehlungen, wie Perfor-mance-Lücken geschlossen und Chancen zur Steigerung des Nutzens ergrif-fen werden können.

Einschränkungen der Lösung beurteilen

Zweck

Der Zweck von „Einschränkungen der Lösung beurteilen“ ist es, die internenFaktoren zu erkennen, welche die Entfaltung des vollen Potentials einer Lösungbe- oder verhindern.

Beschreibung

Die Beurteilung der Einschränkungen der Lösung identifiziert die Ursachen, diefür Leistungsdefizite und ineffektive Lösungen und Lösungskomponenten ver-antwortlich sind.

„Einschränkungen der Lösung beurteilen“ hängt eng zusammen mit der Aufgabe„Einschränkungen des Unternehmens beurteilen“ (Kap. 8.4). Beide Aufgabenkönnen parallel durchgeführt werden. Wenn eine Lösung ihren potentiellenNutzen nicht erzielt, soll der Business-Analyst die internen und externen Faktorenermitteln, welche die Wertschöpfung be- oder verhindern. Hier stehen dieinternen Faktoren einer Lösung im Vordergrund.

Diese Beurteilung kann jederzeit im Lebenszyklus einer Lösung erfolgen. Siekann sich auf Lösungskomponenten beziehen, die sich in der Entwicklung befin-den oder auf bereits fertige Lösungen, die kurz vor dem Echtbetrieb stehen,aber auch bei einer bereits bestehenden Lösung angewendet werden. Unabhängigvon dem jeweiligen Stand sind die einzelnen Aktivitäten der Beurteilung sehrähnlich und berücksichtigen die gleichen Aspekte.

LösungsbewertungEinschränkungen der Lösung beurteilen

206

8.2.8

8.3

8.3.1

8.3.2

Inputs

• Umgesetzte Lösung (extern): Eine existierende Lösung, die operativ im Einsatz sein kann, aber nicht sein muss. Es kann sich auch um einen Prototyp handeln. Um überhaupt bewertet werden zu können, muss die Lösung aber in irgendeiner Form genutzt werden.

• Analyse der Lösungs-Performance : Aus der Analyse der gesammelten Messungen werden Ergebnisse und Empfehlungen abgeleitet, wie Lücken in der Performance geschlossen und Chancen zur Wertsteigerung genutzt werden können.

Abb. 8.3.1: Input-Output-Diagramm „Einschränkungen der Lösung beurteilen“

Lösungsbewertung Einschränkungen der Lösung beurteilen

207

Input


8.3


Einschränkungen der Lösungbeurteilen

8.3

Output


Change-Strategie


Scope der Lösung


6.1Ist-Zustandanalysieren


Performance

8.2


8.3.3

Elemente

.1 Abhängigkeiten unter den internen Lösungskomponenten identifizierenLösungen haben oft innere Abhängigkeiten, so dass unter Umständen die Per-formance der gesamten Lösung von dem Niveau der schwächsten Komponenteabhängt. Die Beurteilung der Gesamt-Performance der Lösung oder ihrer Kom-ponenten wird in den Aufgaben „Leistung-Performance“ (Kap. 8.1) und „Leis-tungskennzahlen analysieren“ (Kap. 8.2) durchgeführt. Der Business-Analystidentifiziert Lösungskomponenten, die von anderen Lösungskomponenten abhän-gig sind, und beurteilt dann, ob wegen dieser Abhängigkeiten oder wegenanderer Komponenten die Performance der Lösung und die Schaffung vonNutzen begrenzt wird.

.2 Probleme der Lösung untersuchenWenn feststeht, dass eine Lösung beständig oder wiederholt ineffektive Ergebnisseliefert, ist eine Problemanalyse durchzuführen, um die Ursache des Problems zufinden.

Der Business-Analyst erkennt Probleme in einer Lösung oder Lösungskomponenteanhand von Fällen, in denen die Leistung unterhalb der geforderten Qualitätliegt oder wenn ein potentieller Nutzen nicht erreicht wird. Probleme ergebensich, wenn Ziele verfehlt oder Anforderungen nicht erfüllt werden. Problemekönnen sich auch aus dem Unvermögen ergeben, einen zuvor versprochenenNutzen zu realisieren, der in den Aufgaben „Change-Strategie definieren“ (Kap.6.4) oder „Maßnahmen zur Steigerung des Nutzens der Lösung empfehlen“(Kap. 8.5) vorgegeben wurde.

.3 Wirkungsanalyse durchführenDer Business-Analyst überprüft die identifizierten Probleme, um deren Auswirkungenauf das operative Geschäft aufzuzeigen oder auf die Fähigkeit der Lösung, einenpotentiellen Nutzen tatsächlich zu liefern. Dazu ist zu berücksichtigen, wie schwer-wiegend das Problem ist, wie wahrscheinlich es auftritt, welche Auswirkungen esauf den Geschäftsbetrieb hat und in wie weit das Unternehmen in der Lage ist,mit diesen Auswirkungen zurechtzukommen. Der Business-Analyst leitet darausab, welche Probleme gelöst werden müssen, welche durch andere Maßnahmenoder Ansätze entschärft und welche akzeptiert werden können.

Andere Maßnahmen und Ansätze können zusätzliche Qualitätskontrollen sein,neue oder veränderte Geschäftsprozesse oder Support für Ausnahmefälle undAbweichungen vom gewünschten Ergebnis.

Zusätzlich zu den identifizierten Problemen beurteilt der Business-Analyst auchdie Risiken der Lösung und deren potentielle Einschränkungen. Die Risikobeur-teilung ist auf die spezifische Lösung und ihre Einschränkungen zugeschnitten.


208

8.3.4


• Change-Strategie: Die verwendete oder zu verwendende Veränderungs-strategie, um den potentiellen Nutzen zu erreichen.

• Ergebnisse der Risikoanalyse: Das Gesamtrisiko-Niveau und das geplante Vorgehen, wie individuelle Risiken modifiziert werden.


Techniken

• Akzeptanz- und Bewertungskriterien: Dienen dazu, zu zeigen, in welchemAusmaß Akzeptanzkriterien durch die Lösung erfüllt bzw. voraussichtlich erfüllt werden, als auch dazu, die Kriterien zu ermitteln, die von der Lösung nicht erfüllt werden.

• Benchmarking und Marktanalyse: Wird eingesetzt, um andere Unterneh-men zu finden, die mit ähnlichen Herausforderungen bei vergleichbaren Lösungen zu kämpfen haben, und versucht, festzustellen, wie diese Orga-nisationen die Probleme angehen.

• Analyse der Geschäftsregeln: Dient zur Darstellung der bestehenden Geschäftsregeln und der Veränderungen, die notwendig sind, um den potentiellen Nutzen des Change zu erzielen.

• Data Mining: Damit werden jene Faktoren identifiziert, welche die Perfor-mance einer Lösung einschränken.

• Entscheidungsanalyse: Mit ihrer Hilfe werden sowohl die bestehenden betrieblichen Entscheidungen dargestellt als auch die Anpassungen, die notwendig sind, um den potentiellen Nutzen eines Change erreichen zu können.

• Interview: Dient zur Problemanalyse.• Item Tracking: Dient dazu, die Anliegen der Stakeholder aufzuzeigen und zu managen, wenn Ursachen aufgetaucht sind, die dazu führen, dass eine Lösung den potentiellen Nutzen nicht erreicht.

• Lessons Learned: Werden eingesetzt, um herauszufinden, was bereits beim Start und der Begründung des Vorhabens sowie bei der Konstruk-tion der Lösung dazu geführt haben kann, dass die Lösung den mög-lichen Nutzen nicht bringt.

• Risikoanalyse und -management: Dienen der Identifikation, der Analyse und dem Management von Risiken, die mit der Lösung und deren Ein-schränkungen im Zusammenhang stehen, und verhindern können, dass der gewünschte Nutzen erreicht werden kann.

Lösungsbewertung Einschränkungen der Lösung beurteilen

209

8.3.5

8.3.6

• Ursachenanalyse: Hilft, die Faktoren und die zugrundeliegenden Ursachenzu erkennen und zu verstehen, die dazu führen, dass die Lösung den möglichen Nutzen nicht erreicht.

• Umfrage oder Fragebogen: Sie unterstützten die Problemanalyse.

Stakeholder

• Kunde: Er steht am Ende der Wertschöpfungskette. Da er persönlich von einer Lösung betroffen ist, kann er den Nutzen einer Lösung besonders fundiert beurteilen und zur Bewertung und zum Feedback herangezogen werden.

• Fachexperte: Er liefert den Input, wie eine Lösung arbeiten soll, und ermittelt potentielle Einschränkungen bei der Realisierung des Nutzens.

• Endanwender: Er nutzt die Lösung oder ist Teil einer Lösungskomponente und trägt somit zur Wertschöpfung und damit auch der Performance der Lösung bei. Ein Endanwender kann beispielsweise die Arbeitsbelastung beurteilen und Feedback zur Arbeitszufriedenheit geben.

• Regulator: Eine Person, deren Organisation bezüglich des geplanten und potentiellen Nutzens einer Lösung eingeschaltet werden muss, da diese Organisation für die Lösung Grenzen setzen und damit beeinflussen kann, in welchem Ausmaß oder wann tatsächlich Nutzen geschaffen werden kann.

• Auftraggeber: Er ist für die Genehmigung des potentiellen Nutzens einer Lösung verantwortlich, für die Bereitstellung der Ressourcen, die notwen-dig sind, um die Lösung zu entwickeln, umzusetzen und zu unterstützen. Außerdem ist er für die Steuerung der Ressourcen bei der Nutzung der Lösung zuständig. Der Auftraggeber ist auch verantwortlich für die Genehmigung einer Änderung des potentiellen Nutzens.

• Tester: Er ist für die Identifikation von Problemen der Lösung in der Konstruktions- und Umsetzungsphase verantwortlich. Tester werden nur selten eingesetzt, um eine bereits bestehende Lösung zu beurteilen, die nicht von einem Änderungsverfahren betroffen ist.

Outputs

• Einschränkungen der Lösung: Beschreibung der bestehenden Einschrän-kungen der Lösung, einschließlich der Restriktionen und Defekte.


210

8.3.7

8.3.8

Einschränkungen des Unternehmens beurteilen

Zweck

Der Zweck von „Einschränkungen des Unternehmens beurteilen“ ist die Bewer-tung, wie externe Faktoren außerhalb der Lösung die Realisierung des Nutzensnegativ begrenzen können.

Beschreibung

Lösungen können über mehrere Organisationseinheiten hinweg im Unternehmeneingesetzt werden. Daher können viele Interaktionen und Abhängigkeiten beste-hen. Lösungen können auch von Umweltfaktoren außerhalb des Unternehmensabhängen. Einschränkungen für das Unternehmen können sich aus der Kultur,dem Betrieb, den technischen Komponenten, Stakeholder-Interessen oder Lei-tungsstrukturen ergeben.

Bei der Beurteilung der Einschränkungen des Unternehmens werden die tiefer-liegenden Ursachen identifiziert und es wird dargestellt, wie betriebliche Ein-flussgrößen die Realisierung von Nutzen eingrenzen.

Diese Beurteilung kann jederzeit im Lebenszyklus einer Lösung erfolgen. Siekann an einer Lösungskomponente während deren Entwicklung oder bei einerbereits fertigen Lösung kurz vor dem Echtbetrieb oder bei einer bestehendenLösung im Ist-Einsatz angewendet werden. Unabhängig vom Zeitpunkt sind dieeinzelnen Aktivitäten der Beurteilung sehr ähnlich und erfordern die gleichenFähigkeiten.

Inputs

• Beschreibung des Ist-Zustands: Es wird das bestehende interne Umfeld der Lösung beschrieben, inklusive der Umweltfaktoren, der Kultur und der internen Faktoren, welche die Lösung einschränken.

• Umgesetzte oder konstruierte Lösung (extern): Es besteht bereits eine Lösung. Die Lösung kann, muss aber nicht operativ im Einsatz sein; sie kann auch ein Prototyp sein. Die Lösung muss aber in irgendeiner Form im Einsatz sein, damit sie bewertet werden kann.

• Analyse der Leistung der Lösung: Das sind die Ergebnisse der Analyse der gesammelten Daten und die Empfehlungen, wie die Performance-Lücken geschlossen und die Chancen zur Steigerung des Nutzens genutzt werden können.

Lösungsbewertung Einschränkungen des Unternehmens beurteilen

211

8.4

8.4.1

8.4.2

8.4.3

Abb. 8.4.1: Input-Output-Diagramm „Einschränkungen des Unternehmens beurteilen“

Elemente

.1 Bewertung der UnternehmenskulturDie Unternehmenskultur umfasst die grundsätzlichen Einstellungen, Werte undfesten Regeln, die unter den Mitgliedern des Unternehmens gelten. Auch wenndiese grundsätzlichen Einstellungen und Werte möglicherweise nicht direkterkennbar sind, beeinflussen sie maßgeblich die Handlungen eines Unterneh-mens.

LösungsbewertungEinschränkungen des Unternehmens beurteilen

212


8.4


Einschränkungen desUnternehmens beurteilen

8.4

Output


Change-Strategie


Scope der Lösung

6.1Ist-Zustandanalysieren


Performance

8.2

8.5

Input

Umgesetzte oder konstruierte

Lösung (extern)


6.1


Geschäftsziele


8.4.4

Der Business-Analyst bewertet die Kultur unter folgenden Aspekten, indem er• ermittelt, ob Stakeholder die Gründe verstehen, warum es diese Lösung gibt

• feststellt, ob die Stakeholder eine Lösung als etwas Nützliches betrach-ten und die Veränderung unterstützen

• feststellt, ob und gegebenenfalls welche kulturellen Veränderungen notwendig sind, um mehr Nutzen aus der Lösung zu ziehen.

Bei der Bewertung der Unternehmenskultur wird abgeschätzt, bis zu welchemGrad die Kultur eine Lösung akzeptieren kann. Sollte es für die Lösung notwendigsein, die Unternehmenskultur anzupassen, muss die Fähigkeit und Bereitschaftdes Unternehmens eingeschätzt werden, solche Veränderungen der Unterneh-menskultur zu akzeptieren.

Der Business-Analyst bewertet interne und externe Stakeholder, indem er• das Verständnis für die und die Akzeptanz der Lösung beurteilt• einschätzt, welchen Wert und welchen Nutzen die Stakeholder der Lösung beimessen

• die Kommunikationsmaßnahmen festlegt, die erforderlich sind, damit die Lösung bekannt ist und verstanden wird.

.2 Analyse der Auswirkung auf die StakeholderEine Analyse der Auswirkungen auf die Stakeholder zeigt, welche Effekte eineLösung auf eine spezielle Gruppe von Stakeholdern hat.Für die Analyse der Auswirkung auf die Stakeholder untersucht der Business-Analyst:

• Funktionen: Prozesse, in denen der Stakeholder die Lösung nutzt, einschließlich der Inputs des Stakeholders in den Prozess, der Art der Nutzung der Lösung und der Outputs, die der Stakeholder vom Prozess erhält.

• Standorte: Geographische Lage des Stakeholders, der die Lösung nutzt. Arbeiten die Stakeholder an unterschiedlichen Standorten, kanndies die Nutzung der Lösung beeinflussen und die Möglichkeit, den wirklichen Nutzen der Lösung zu realisieren.

• Bedenken: Fragen, Risiken und allgemeine Bedenken, die Stakeholder in Bezug auf die Lösung haben. Dazu können die Nutzung der Lösung, die Wahrnehmung des Nutzens der Lösung und die Fähigkeit des Stake-holders gehören, mit der Lösung die notwendigen Funktionen zu erfüllen.

.3 Veränderungen an der OrganisationsstrukturManchmal bewertet der Business-Analyst, welche Auswirkungen eine Lösungauf die Organisationsstruktur hat.


213

Die Nutzung einer Lösung und die Bereitschaft, eine Veränderung anzunehmen,kann durch formale und informelle Verbindungen zwischen Stakeholdern geför-dert oder behindert werden. Die Strukturen des Leitungssystems können zukompliziert oder lückenhaft sein, um die Lösung effektiv zu nutzen. Eine zentraleAufgabe ist die Bewertung, ob die Aufbauorganisation (Hierarchie) für dieeffektive Nutzung der Lösung geeignet ist. Gelegentlich beeinflussen informelleBeziehungen innerhalb eines Unternehmens – seien es Allianzen, Freundschaftenoder Abhängigkeiten aus der Matrixstruktur – den potentiellen Nutzen einerLösung. Diese informellen Beziehungen werden vom Business-Analysten zusätzlichzur formalen Organisationsstruktur berücksichtigt.

.4 Bewertung der betrieblichen FähigkeitenMit der Bewertung der betrieblichen Fähigkeiten soll ermittelt werden, ob einUnternehmen in der Lage ist, sich an eine Lösung anzupassen oder die Lösungeffektiv zu nutzen. Dabei wird untersucht, welche Prozesse und Hilfsmittel inner-halb des Unternehmens von der Lösung profitieren könnten und ob ausreichendeund passende Mittel zur Unterstützung bereitstehen.

Bei einem Assessment der betrieblichen Fähigkeiten berücksichtigt der Business-Analyst

• Politiken und Prozesse• Fähigkeiten und Verfahren, die helfen, andere Fähigkeiten zu entwickeln• Qualifikations- und Fortbildungsbedarf• Abläufe im Personalbereich• Risikoeinstellung und Management-Ansätze• Werkzeuge und Technologien, die eine Lösung unterstützen.


• Geschäftsziele: Sie werden bei der Messung und Bestimmung der Perfor-mance der Lösung berücksichtigt.

• Change-Strategie: Die verwendete Veränderungsstrategie, die dazu dient,den potentiellen Nutzen mit der Umsetzung zu erzielen.

• Beschreibung des Soll-Zustands: Die Beschreibung der Grenzen der vor-geschlagenen neuen, abgelösten oder veränderten Komponenten des Unternehmens sowie des Nutzens, der von dem Soll-Zustand erwartet wird.

• Ergebnisse der Risikoanalyse: Das Gesamtrisiko-Niveau und der geplante Ansatz, wie mit den einzelnen Risiken umgegangen wird.

• Scope der Lösung: Die Grenzen der Lösung, innerhalb derer gemessen und bewertet wird.

LösungsbewertungEinschränkungen des Unternehmens beurteilen

214

8.4.5

Techniken

• Benchmarking und Marktanalyse: Dient der Identifikation bestehender Lösungen und Interaktionen im Unternehmen.

• Brainstorming: Mit seiner Hilfe können Lücken in der Organisation oder Bedenken von Stakeholdern ermittelt werden.

• Data Mining: Damit können jene Faktoren identifiziert werden, welche die Performance der Lösung begrenzen.

• Entscheidungsanalyse: Unterstützt die Entscheidungsfindung bei Unsicher-heit und kann verwendet werden, um Entscheidungen zu funktionalen, technischen oder vorgehensspezifischen Defiziten zu beurteilen.

• Dokumentenanalyse: Mit ihrer Hilfe kann ein Verständnis für die Kultur, den Betrieb und die Struktur eines Unternehmens gewonnen werden.

• Interviews: Dient dient dazu, Mängel in der Organisation zu identifizie-ren und Stakeholder-Bedenken aufzudecken.

• Item Tracking: Stellt sicher, dass keine Anliegen ignoriert oder vergessen werden, und dass bei der Bewertung aufgedeckte Sachverhalte abgehan-delt werden.

• Lessons Learned: Werden genutzt, um bisherige Vorhaben zu analysieren und zu erkennen, wie das Unternehmen mit den Lösungen zusammenwirkt.

• Beobachtung: Dient dazu, die Austauschprozesse zwischen dem Unter-nehmen und der Lösung zu beobachten und die Auswirkungen zu studieren.

• Organisationsmodellierung: Sie wird angewandt, um eventuell notwendige Veränderungen der Organisationsstruktur zu ermitteln.

• Prozessanalyse: Mit ihrer Hilfe werden Chancen zur Steigerung der Perfor-mance identifiziert.

• Prozessmodellierung: Damit werden bestehende Geschäftsprozesse und/ oder Veränderungen dargestellt, die notwendig sind, um den potentiellenNutzen der Lösung zu realisieren.

• Risikoanalyse und -management: Sie dienen der Risikobeurteilung von Technologien (ob die ausgewählte technische Ressource die notwendigen Funktionalitäten bietet), Finanzen (ob die Kosten so ausufern könen, dass es zum Abbruch des Vorhabens kommen kann) und des Betriebs (ob das Unternehmen in der Lage ist, die notwendigen Veränderungen so vorzu-nehmen, dass die Lösung den potentiellen Nutzen auch wirklich bringt).

• Rollen- und Zuständigkeitsmatrix: Wird genutzt, um die Rollen und die damit verbundenen Befugnisse der Stakeholder in eine Matrix einzutra-gen. Es wird auch vermerkt, ob es immer die gleichen Endanwender gibt.


215

8.4.6

• Ursachenanalyse: Dient der Feststellung, ob es tieferliegende Ursachen gibt, die sich aus den Einschränkungen des Unternehmens ergeben.

• Umfrage oder Fragebogen: Dienen dazu, Mängel im Unternehmen oder Bedenken der Stakeholder zu ermitteln.

• SWOT-Analyse: Zeigt auf, wie eine Veränderung einem Unternehmen hilft, Stärken zu verbessern und Schwächen zu verringern. Die SWOT-Analyse hilft auch, die Strategien zu beurteilen, mit denen identifizierte Anliegen angegangen werden sollen.

• Workshops: Dienen zur Identifikation von Mängeln im Unternehmen oder von Bedenken der Stakeholder.

Stakeholder

• Kunde: Person, welche die Lösung direkt kauft oder konsumiert und/oder mit dem Unternehmen zusammenwirkt, wenn sie die Lösung nutzt.

• Fachexperte: Er liefert Informationen darüber, wie das Unternehmen mit der Lösung interagiert, und identifiziert mögliche Einschränkungen.

• Endanwender: Person, die eine Lösung nutzt oder eine Komponente der Lösung ist. Anwender können Kunden oder Personen sein, die im Unter-nehmen arbeiten.

• Regulator: Eine oder mehrere staatliche Institutionen oder Berufsver-bände, die die Einhaltung von Gesetzen, Vorgaben und Regeln über-wachen. Regulatoren können einzigartige Quellen für die Bewertung des Unternehmens sein, da relevante Regelungen unbedingt in den Anforde-rungen zu berücksichtigen sind. Es kann sein, dass Gesetze und Regelun-gen noch vor einem geplanten Change befolgt werden müssen, oder erstdann, wenn die Lösung umgesetzt wurde.

• Sponsor: Er genehmigt das Vorhaben und stellt sicher, dass die finanziellen Mittel zur Umsetzung der Lösung vorhanden sind. Er treibt als Champion die Lösung der Probleme voran, die bei der Bewertung des Unternehmens identifiziert wurden.

Outputs

• Einschränkungen des Unternehmens: Die bestehenden Einschränkungen im Unternehmen werden ebenso beschrieben wie die Auswirkungen der Leis-tungen der Lösung auf das Unternehmen.

LösungsbewertungLösungsbewertung

216

8.4.7

8.4.8

Maßnahmen zur Steigerung des Nutzens der Lösungempfehlen

Zweck

Der Zweck von „Maßnahmen zur Steigerung des Nutzens der Lösung empfehlen“ist es, jene Faktoren zu verstehen, die es möglich machen, von einem aktuellenzu einem potentiellen Nutzen zu kommen, und eine Empfehlung zu geben, wiediese Verbesserung erzielt werden kann.

Beschreibung

Die verschiedenen Aufgaben des Wissensgebiets „Lösungsbewertung“ helfendabei, eine nicht akzeptable Leistung der Lösung zu ermitteln, zu analysierenund die Ursachen dafür festzustellen. Die Aufgabe „Maßnahmen zur Steigerungdes Nutzens der Lösung empfehlen“ konzentriert sich darauf, die Ergebnisseder durchgeführten Bewertungen zu verstehen und Alternativen und geeigneteHandlungen zu ermitteln, um die Lösungs-Performance zu erhöhen und dieWertschöpfung zu steigern.

Im Allgemeinen werden Empfehlungen gegeben, wie eine Lösung ersetzt, abge-löst oder erweitert werden soll. Die Empfehlungen können auch die langfristigenFolgen und Beiträge einer Lösung für die Stakeholder aufzeigen. Sie könnenauch Empfehlungen enthalten, wie ein Unternehmen verändert werden muss,um die maximale Leistung und den gewünschten Nutzen der Lösung zu errei-chen.

Inputs

• Einschränkungen des Unternehmens: Eine Beschreibung der bestehendenEinschränkungen, inklusive der Beschreibung, wie sich die Leistung der Lösung auf das Unternehmen auswirkt.

• Einschränkungen der Lösung: Eine Beschreibung der bestehenden Einschrän-kungen der Lösung inklusive der Restriktionen und Mängel.

Lösungsbewertung Maßnahmen zur Steigerung des Nutzensder Lösung empfehlen

217

8.5.3

8.5.2

8.5.1

8.5

Abb. 8.5.1: Input-Output-Diagramm „Maßnahmen zur Steigerung des Nutzens der Lösung empfehlen“

Elemente

.1 Anpassung der Kennzahlen zur Messung der Lösungs-PerformanceIn einigen Fällen wird zwar die Leistung der Lösung als akzeptabel erachtet,möglicherweise werden aber die Ziele nicht erreicht. Unter Umständen müssenweitere Analysen durchgeführt werden, um besser geeignete Messgrößen zufinden und zu definieren.

.2 EmpfehlungenEmpfehlungen beschreiben meistens – aber nicht immer – Möglichkeiten, diedazu dienen können, die Lösungs-Performance zu verbessern. Abhängig vom

LösungsbewertungMaßnahmen zur Steigerung des Nutzensder Lösung empfehlen

218

Input

EmpfohleneMaßnahmen

8.5


Maßnahmen zur Steigerung desNutzens der Lösung empfehlen

8.5

Output


Betriebliche Ziele


Scope der Lösung


managen

4.5


8.3 Einschränkungen

des Unternehmens

8.4

8.5.4

jeweiligen Grund für die Minderleistung einer Lösung, kann es auch sinnvollsein, keine Maßnahmen zu ergreifen, externe Bedingungen anzupassen oderdie Erwartungen an die Lösung zu korrigieren.

Einige Beispiele für Empfehlungen, die ein Business-Analyst geben kann:• Tue nichts: Das wird üblicherweise empfohlen, wenn der Nutzen eines Change im Vergleich zu dem dafür erforderlichen Aufwand eher gering ist oder wenn die Risiken der Veränderung deutlich höher sind als die Risiken, die bei der Beibehaltung des gegenwärtigen Zustands gegeben sind. Es besteht auch die Möglichkeit, dass die Umsetzung des Change mit den verfügbaren Ressourcen oder in der vorgesehe-nen Zeit nicht möglich ist.

• Führe Change im Unternehmen durch: Change ist ein Prozess, der dazu dient, Befindlichkeiten, Wahrnehmungen und die Beteiligung an einer Veränderung zu steuern. Zur Steuerung eines Change werden üblicherweise ein Prozess und eine ganze Reihe von Werkzeugen ge-nutzt, die dazu dienen, eine Veränderung im Unternehmen umzusetzen. Der Business-Analyst kann helfen, Empfehlungen für Veränderungen der Organisationsstruktur oder beim Personal zu erarbeiten, wenn sich Funk-tionen und Aufgaben etwa wegen einer Automatisierung von Prozessen deutlich verändern. Den Stakeholdern können weitere Informationen zurVerfügung gestellt werden und es können neue Qualifikationen erfor-derlich sein, um die Lösung umzusetzen. Empfehlungen im Zusammen-hang mit Change können beispielsweise sein:• Automatisierung oder Vereinfachung der Arbeit der Mitarbeiter. Ver-gleichsweise einfache Aufgaben sind für eine Automatisierung prädes-tiniert. Zusätzlich können Aktivitäten und Geschäftsregeln geprüft und analysiert werden, um Möglichkeiten für ein Reengineering, Änderun-gen in den Verantwortlichkeiten oder ein Outsourcing zu ermitteln.

• Verbesserung des Zugangs zu Informationen. Es werden den Betei-ligten und Entscheidungsberechtigten möglicherweise mehr oder bessere Informationen zur Verfügung gestellt.

• Reduziere die Komplexität von Schnittstellen: Schnittstellen sind immerdann erforderlich, wenn Aufgaben zwischen Systemen oder Personen weitergegeben werden. Die Verringerung der Komplexität kann das Verständnis für die Aufgaben erhöhen.

• Beseitige Redundanz: Unterschiedliches Gruppen von Stakeholdern haben möglicherweise gleichartige Bedürfnisse, die mit einer einzigen Lösung erfüllt werden können, um so die Kosten für die Umsetzung zuverringern.

• Vermeide Verschwendung: Werden alle Aktivitäten entfernt, die nicht zu einem Produkt oder einer Leistung beitragen, oder werden sie auf ein Minimum beschränkt, kann Verschwendung vermieden werden.


219

• Erkenne zusätzliche Fähigkeiten: Lösungsvarianten bieten möglicher-weise Fähigkeiten, die über die definierten Anforderungen hinaus-gehen. Oft bieten diese Fähigkeiten keinen direkten Nutzen für die Organisation, sie könnten aber in Zukunft nützlich sein, wenn der Bedarf auftaucht, diese Fähigkeiten schnell zu entwickeln oder zu implementieren (beispielsweise stellt eine Software-Applikation Funk-tionen zur Verfügung, die das Unternehmen voraussichtlich in Zukunftbenötigen wird).

• Setze Lösung außer Betrieb: Es kann notwendig sein, darüber nach-zudenken, eine Lösung oder einen Teil einer Lösung zu ersetzen, wennbeispielsweise eine Technologie am Ende ihres Lebenszyklus ist oder wenn Leistungen in das Unternehmen zurück verlagert oder aber ausgegliedert werden (Outsourcing) oder wenn die Lösung den Zweck nicht erfüllt, für den sie geschaffen wurde.

• Einige zusätzliche Faktoren können die Entscheidung beeinflussen, eine Lösung außer Betrieb zu setzen:• Steigende Kosten: Üblicherweise steigen die Kosten für den Betrieb einer Lösung im Laufe der Zeit, während andere Lösungen zwar eine höhere erstmalige Investition erfordern, dafür dann aber geringere laufende Kosten haben.

• Opportunitätskosten: Sie zeigen den möglichen Wert einer Alternative.• Notwendigkeit: Die meisten Lösungskomponenten haben eine begrenzte Lebensdauer (sie können überflüssig werden, die Markt-situation kann sich ändern etc.). Nach einer bestimmten Nutzungs-dauer ist es dann nicht mehr sinnvoll oder möglich, die bestehende Komponente weiter zu betreiben.

• Bereits getätigter Aufwand: Der Aufwand und die finanziellen Mittel,die bereits für ein Vorhaben ausgegeben wurden, haben oft den psychologischen Effekt, dass es Stakeholdern schwerfällt, Lösungen zu ersetzen oder zu beseitigen, weil sie dann das Gefühl haben, die eingesetzten Mittel zu „verschwenden“. Da die Investitionen der Vergangenheit aber nicht mehr rückgängig gemacht werden können, ist deren Höhe für Entscheidungen letztlich irrelevant. Entscheidungensollten ausschließlich auf zukünftigen Investitionen und deren erziel-baren Nutzen basieren.


• Betriebliche Ziele: Sie werden bei der Bewertung, Messung und Bestim-mung der Leistung einer Lösung berücksichtigt.

• Beschreibung des Ist-Zustands: Liefert die Beschreibung des Kontextes, in dem die Aufgaben erledigt werden müssen. Sie kann bei der Beurteilung


220

8.5.5

der Alternativen und zum besseren Verständnis der potentiell vorgesehe-nen Nutzensteigerung herangezogen werden. Die Beschreibung kann auch unbeabsichtigte Folgen von Alternativen aufzeigen, die sonst unentdeckt bleiben würden.

• Scope der Lösung: Die Grenzen der Lösung, innerhalb derer gemessen und bewertet wird.

Techniken

• Data Mining: Es dient dazu, Schätzungen und Vorhersagen über die Leis-tung von Lösungen abzuleiten.

• Entscheidungsanalyse: Mit ihrer Hilfe können die Auswirkung aller Aktivi-täten auf den potentiellen Nutzen und die unterschiedlichen Aspekte der Performance bestimmt werden.

• Finanzanalyse: Mit ihr können die potentiellen Kosten und der Nutzen eines Change beurteilt werden.

• Fokusgruppe: Hilft bei der Ermittlung, ob die Performance-Kennzahlen geändert werden müssen und ob es Chancen zur Steigerung der Leistunggibt.

• Organisationsmodellierung: Damit können die Auswirkungen potentieller Veränderungen auf die Organisationsstruktur sichtbar gemacht werden.

• Priorisierung: Wird eingesetzt, um den relativen Wert verschiedener Hand-lungen zur Steigerung der Leistung einer Lösung zu ermitteln.

• Prozessanalyse: Dient dazu, Chancen bei Prozessen zu erkennen, die miteinander verbunden sind.

• Risikoanalyse und -management: Dienen der Bewertung unterschiedlicherErgebnisse unter bestimmten Bedingungen.

• Umfrage oder Fragebogen: Werden verwendet, um Feedback von vielen, auch sehr unterschiedlichen Stakeholdern zu erhalten, und um festzustellen, ob der erwartete Nutzen erzielt oder übererfüllt wurde, ob die Kennzahlen im aktuellen Umfeld immer noch gültig oder relevant sind und welche Maß-nahmen zur Verbesserung der Lösung geeignet sein können.

Stakeholder

• Kunde: Person, welche die Lösung direkt kauft oder konsumiert und/oder die mit dem Unternehmen zusammenwirkt, wenn sie die Lösung nutzt.

• Fachexperte: Er liefert Informationen, wie eine Lösung und/oder die Orga-nisation verändert werden muss, um eine Nutzensteigerung zu erzielen.


221

8.5.6

8.5.7

• Endanwender: Person, die eine Lösung nutzt oder Teil einer Lösung ist. Anwender können Konsumenten oder Personen sein, die im Unterneh-men arbeiten.

• Regulator: Eine oder mehrere staatliche Institutionen oder Berufsorganisa-tionen, welche die Einhaltung von Gesetzen, Vorgaben und Regeln über-wachen. Relevante Regulierungen sind in den Anforderungen zu berück-sichtigen.

• Auftraggeber: Er genehmigt die Umsetzung der vorgeschlagenen Maßnah-men und stellt dafür die Budgets sicher.

Outputs

• Empfohlene Maßnahmen: Empfehlungen dazu, mit welchen Aktivitäten der Nutzen einer Lösung gesteigert werden kann.


222

8.5.8

223

Das Wissensgebiet „Basiskompetenzen“ beschreibt Verhaltensweisen, Eigen-schaften, Kenntnisse und persönliche Qualitäten, die für die Praxis der Business-Analyse förderlich sind.

Die hier beschriebenen Basiskompetenzen gelten nicht nur für das Gebiet derBusiness-Analyse. Sie werden hier angeführt, um dem Leser die Vielfalt wichtigerFähigkeiten bewusst zu machen, die Voraussetzung dafür sind, als Business-Analyst allen Situationen gewachsen zu sein.

Diese Basiskompetenzen verteilen sich auf sechs Kategorien:• Analytisches Denken und Problemlösung• Verhalten• Geschäftsverständnis• Kommunikationsfähigkeit• Interaktionsfähigkeit• Werkzeuge und Technologie.

Für die Bestimmung jeder Basiskompetenz werden Zweck, Beschreibung undErfolgsmaßstäbe angeführt.

Analytisches Denken und ProblemlösungDer Business-Analyst muss in der Lage sein, analytisch zu denken und Problemezu lösen, um mit Problemen und Chancen effektiv umgehen zu können, umfestzustellen, welche Changes voraussichtlich den größten Wert liefern, undum mit den Stakeholdern ein gemeinsames Verständnis der Auswirkungen vonVeränderungen zu erarbeiten.

Der Business-Analyst nutzt analytisches Denken, um unterschiedliche Arten vonInformationen (z. B. Diagramme, Bedenken von Stakeholdern, Kundenfeedback,schematische Darstellungen, Benutzerhandbücher und Tabellen) schnell zu ver-stehen und die relevanten Informationen herausfiltern zu können. Der Business-

9 Basiskompetenzen

9.1

Analyst sollte zielführende und nützliche Methoden kennen und nutzen, mitdenen er Medien, Zielgruppen, Problemarten und Umfelder ermittelt und aus-wertet.

Der Business-Analyst verwendet „Analytisches Denken und Problemlösung“, damit ihrer Hilfe Situationen besser erfasst, der Wert vorgeschlagener Veränderungenund andere komplexe Sachverhalte leichter verstanden werden können.

Mit einem guten Verständnis für die Basiskompetenzen „Analytisches Denkenund Problemlösung“ kann der Business-Analyst die am besten geeignete Formfinden, um die Ergebnisse den Stakeholdern zu präsentieren. Einige Vorschlägekönnen beispielsweise besser mit Diagrammen und Grafiken als rein verbal dar-gestellt werden. Dieses Verständnis hilft dem Business-Analysten, seinen Ansatzder Business-Analyse besser zu planen und macht es leichter, die relevantenInformationen zielgruppengerecht zu präsentieren.

Die Basiskompetenzen in „Analytisches Denken und Problemlösung“ umfassen:• Kreatives Denken• Entscheidungsfindung• Lernen• Problemlösung• Systemdenken• Konzeptionelles Denken• Visuelles Denken.

Kreatives Denken

.1 ZweckKreatives Denken und die Unterstützung anderer beim kreativen Denken hilftdem Business-Analysten, neue Ideen, Ansätze und Alternativen für Problemeund Chancen zu finden.

.2 BeschreibungKreatives Denken bedeutet, neue Ideen und Konzepte zu entwickeln oder auchbestehende Ideen und Konzepte neu zu verknüpfen und so neue Anwendungs-bereiche für sie zu entdecken. Kreatives Denken hilft, starre Ansätze der Pro-blemlösung zu vermeiden, indem die üblichen Vorgehensweisen hinterfragt wer-den und neue Ideen und der Situation angemessene neue Wege gefördert wer-den. Kreatives Denken kann auch die Kombination, Abwandlung und Wieder-verwendung bestehender Konzepte umfassen. Der Business-Analyst kann kreativesDenken bei Dritten fördern, indem er alternative Wege findet und vorschlägt,Fragen stellt und Annahmen in Frage stellt.

224

BasiskompetenzenAnalytisches Denken und Problemlösung

9.1.1

.3 ErfolgsmaßstäbeKriterien für erfolgreiches kreatives Denken sind u.a.:

• Entwicklung und erfolgreiche Berücksichtigung neuer Ideen• Untersuchung neuer Konzepte und Ideen• Untersuchung von Abwandlungen bestehender Konzepte und Ideen• Weckung von Kreativität bei sich selbst und bei anderen• Nutzung neuer Ideen zur Lösung existierender Probleme.

Entscheidungsfindung

.1 ZweckDer Business-Analyst muss die Kriterien der Entscheidungsfindung herausfindenund anderen dabei helfen, bessere Entscheidungen zu treffen.

.2 BeschreibungEine Entscheidung wird immer dann benötigt, wenn der Business-Analyst odereine Gruppe von Stakeholdern eine Alternative oder eine Vorgehensweise auszwei oder mehreren Optionen auswählen muss. Die Auswahl muss den größtenNutzen für die Stakeholder und das Unternehmen liefern. Dabei werden für dieEntscheidung relevante Informationen gesammelt und bewertet, um so die besteMöglichkeit herauszufinden. Der Business-Analyst dokumentiert die Entschei-dungen (und die zugehörigen Begründungen), um sie in Zukunft im Falleähnlicher Entscheidungen verfügbar zu haben oder um Entscheidungen zubegründen.

.3 ErfolgsmaßstäbeKriterien für eine erfolgreiche Entscheidungsfindung sind u.a.:

• in die Entscheidung wurden die richtigen Stakeholder eingebunden• Stakeholder verstehen den Entscheidungsfindungsprozess und die Begründung der Entscheidung

• Vor- und Nachteile aller verfügbaren Optionen wurden den Stake-holdern klar und deutlich vorgestellt

• Entscheidung verringert oder beseitigt Unsicherheit und die verblei-bende Unsicherheit wird akzeptiert

• getroffene Entscheidung betrifft das tatsächliche Bedürfnis oder die Chance und erfolgt im besten Interesse aller Stakeholder

• Stakeholder verstehen die Ausgangssituation, die Rahmenbedingun-gen und die daraus folgenden Maßnahmen

• Entscheidung wird tatsächlich getroffen.

Basiskompetenzen Analytisches Denken und Problemlösung

225

9.1.2

Lernen

.1 ZweckDer Business-Analyst muss in der Lage sein, sich rasch in unterschiedlichsteInformationen einzuarbeiten und sein Wissen auf die Situation anpassen. Damitkann er erfolgreich in einem sich schnell ändernden und sich weiter entwickelndenUmfeld arbeiten.

.2 BeschreibungLernen ist der Prozess der Aneignung von Wissen oder Kompetenzen. DasErlernen eines Fachgebiets durchläuft verschiedene Stadien. Es beginnt damit,sich die groben Fakten anzueignen und geht weiter über das Verständnis derjeweiligen Bedeutung bis hin zur Anwendung des Wissens im Tagesgeschäft.Schließlich erfolgen Analyse, Synthese und Evaluation des Gelernten. Ein Busi-ness-Analyst muss wissen, auf welcher Lernebene er sich gerade befindet undsituativ die bestgeeigneten Aktivitäten der Analyse auswählen. Wenn der Lern-prozess über ein Fachgebiet in eine umfassende Analyse mündet, verknüpft derBusiness-Analyst die Informationen (Synthese), um neue Lösungsmöglichkeitenzu entwickeln. Anschließend bewertet er die Lösungen im Hinblick auf derenEffektivität.

Lerntechniken sind u.a.:• Visuell: Lernen findet mittels der Präsentation von Bildern, Foto-grafien, Diagrammen, Modellen und Videos statt

• Auditiv: Lernen findet mittels gesprochener und geschriebener Sprache sowie mit Texten statt

• Kinästhetisch: Lernen findet mittels Umsetzung statt (Learning by doing).

.3 ErfolgsmaßstäbeKriterien für erfolgreiches Lernen sind u.a.:

• allen ist bewusst, dass alle Stakeholder lernen müssen• Stakeholder lernen die Konzepte kennen und zeigen anschließend, dass sie sie verstanden haben

• bestehende Konzepte werden auf neue Anwendungsgebiete und Verhältnisse angewendet

• neue Fakten, Ideen, Konzepte und Meinungen werden schnell auf-gegriffen

• neue Fakten, Ideen, Konzepte und Meinungen können wirkungsvoll anderen vorgestellt werden.


226

9.1.3

Problemlösung

.1 ZweckDer Business-Analyst beschreibt und löst Probleme, um sicherzustellen, dass dietatsächlichen Ursachen eines Problems von allen Stakeholdern verstanden werdenund die Lösungen auf die Behebung dieser Ursachen abzielen.

.2 BeschreibungDie Beschreibung eines Problems erfordert zwingend, dass die Art des Problemsund die zugrundeliegenden Sachverhalte von allen Stakeholdern klar verstandenwerden. Die Standpunkte und Blickwinkel der Stakeholder werden präzise ange-sprochen und behandelt, um mögliche Konflikte zwischen den Zielen und Absich-ten der unterschiedlichen Gruppen von Stakeholdern zu verstehen. Annahmenwerden ermittelt und auf ihre Gültigkeit überprüft. Die angestrebten Ziele, diemit der Lösung des Problems erreicht werden sollen, werden klar definiert. Alter-native Lösungen werden berücksichtigt und gegebenenfalls entwickelt. Die Alter-nativen werden anhand der Ziele bewertet, um so die beste Lösung herauszu-finden und den Nutzen für die einzelnen Lösungen wie auch eventuell erforder-liche Abstriche zu erfassen.

.3 ErfolgsmaßstäbeKriterien für effektive Problemlösung sind u.a.:

• Teilnehmer haben Vertrauen in den Problemlösungsprozess• ausgewählte Lösungen erfüllen die definierten Zielsetzungen und beheben die eigentliche Ursache des Problems

• neue Lösungsmöglichkeiten können effektiv unter Verwendung eines Frameworks zur Problemlösung bewertet werden

• im Problemlösungsprozess werden keine Entscheidungen auf Basis vonAnnahmen, die zuvor nicht auf ihre Gültigkeit überprüft wurden, von Vorurteilen oder anderen Hindernissen getroffen, die dazu führen können, dass nicht die beste Lösung ausgewählt wird.

Systemdenken

.1 ZweckDer Business-Analyst versteht ein Unternehmen aus einer ganzheitlichen Sicht,wenn er weiß, wie Menschen, Prozesse und Technologie zusammenwirken.


227

9.1.4

9.1.5

.2 BeschreibungSystemtheorie und Systemdenken gehen davon aus, dass ein System als GanzesEigenschaften, Verhaltensweisen und charakteristische Merkmale besitzt, diesich aus dem Zusammenspiel der Komponenten des Systems ergeben. DieseFaktoren können nicht vorausgesagt werden, wenn lediglich die einzelnen Kom-ponenten verstanden werden. Wenn beispielsweise der Business-Analyst weiß,dass ein Kunde möglicherweise eine gekaufte Ware wieder zurückgibt, hat erdamit noch kein ganzheitliches Bild. Der Business-Analyst muss analysieren, wel-chen Einfluss die Rückgabe auf Themen wie Warenbestand, Finanzen oder Qua-lifikation des Verkaufspersonals hat. Im Kontext der Systemtheorie umfasst derAusdruck System auch die beteiligten Personen, die Wechselbeziehung zwischenihnen, externe Einflüsse auf ihr Verhalten und alle anderen relevanten Faktoren.

.3 ErfolgsmaßstäbeKriterien für effektives Systemdenken sind u.a.:

• wie die Änderung einer Komponente das Gesamtsystem beeinflusst• wie die Änderung eines Systems seine Umgebung beeinflusst• wie Systeme auf Veränderungen und Druck von außen reagieren.

Konzeptionelles Denken

.1 ZweckDer Business-Analyst erhält üblicherweise große Mengen detaillierter und mög-licherweise nicht zusammenpassender Informationen. Mithilfe des konzeptionellenDenkens kann der Business-Analyst verstehen, wie eine Information in eingrößeres Bild hineinpasst und welche Details wichtig sind. So kann er abstrakterscheinende Informationen miteinander verknüpfen.

.2 BeschreibungBeim konzeptionellen Denken geht es um das Verständnis der Verknüpfungenzwischen Kontext, Lösung, Bedürfnissen, Veränderung, Stakeholdern und Nutzenauf abstrakter Ebene und im Rahmen des Gesamtzusammenhangs. Zum kon-zeptionellen Denken gehört das Verständnis, wie Details in einen größerenKontext passen. Bisherige Erfahrungen, Wissen, Kreativität, Intuition und abs-traktes Denken werden genutzt, um Varianten, Optionen und neue, nicht direktmit dem Thema verbundene Ideen finden zu können.

Konzeptionelles Denken in der Business-Analyse befasst sich insbesondere auchdamit, Gesichtspunkte, die nicht so einfach erkannt werden können, mit demzugrundeliegenden Problem oder der Chance, den Modellen oder den Rahmen-modellen zu verknüpfen, um so die Stakeholder dabei zu unterstützen, sich


228

9.1.6

selbst und die anderen Stakeholder besser zu verstehen und die Veränderungbesser zu bewältigen. Mit konzeptionellem Denken werden unzusammenhän-gende Informationen miteinander verbunden, die aus einer Vielzahl von Quellenstammen. Stakeholder, Ziele, Risiken, Details und andere Faktoren können solcheQuellen sein. Mit diesen Informationen stellt konzeptionelles Denken Möglich-keiten und Alternativen für Lösungen bereit und liefert diese Information anandere, um sie zu ermutigen, eigene Ideen zu entwickeln.

.3 ErfolgsmaßstäbeErfolgreiches konzeptionelles Denken lässt sich u.a. an folgenden Kriterienerkennen:

• unzusammenhängende Informationen werden miteinander verbundenund es werden Maßnahmen ergriffen, Zusammenhänge besser zu ver-stehen

• gemeinsam mit den Stakeholdern wird bestätigt, dass ein Konzept verstanden und ihm vertraut wird

• es werden abstrakte Konzepte entwickelt, unter gleichzeitiger Berück-sichtigung von Informationen und Unsicherheit

• um eine Situation zu verstehen, werden auch Erfahrungen aus der Vergangenheit berücksichtigt.

Visuelles Denken

.1 ZweckDie Fähigkeit, komplexe Konzepte und Modelle in nachvollziehbarer, visuellerForm Dritten zu verdeutlichen, erleichtert es dem Business-Analysten, Stakeholderzu gewinnen und ihnen die dargestellten Konzepte verständlich zu machen.

.2 BeschreibungDie Fähigkeit, visuell zu denken, erlaubt es dem Business-Analysten, diskutierteKonzepte oder Systeme in Form grafischer Abbildungen darzustellen. Diese gra-fischen Darstellungen zielen darauf ab, dass Stakeholder leichter die präsentiertenKonzepte verstehen und dann dazu eigene Beiträge leisten können. VisuellesDenken setzt voraus, dass der Analyst abstrahieren kann und dann angemessenegrafische Mittel findet, um die Ergebnisse darzustellen.

Visuelles Denken heißt bildlich darstellen und einfache Konzepte, Grafiken,Modelle, Diagramme oder andere Konstrukte schaffen, mit deren Hilfe auchnicht-visuelle Informationen zusammengeführt und transportiert werden. ImZusammenhang mit der Business-Analyse werden große Informationsmengenund komplexe Zusammenhänge zwischen Kontexten, Stakeholdern, Bedarf,Lösungen, Änderungen und Werten übermittelt. Bilder zeigen diese Informationen


229

9.1.7

und die damit verbundene Komplexität. Sie ermöglichen es Stakeholdern undZuhörern, schneller zu lernen, die Informationen weiter zu bearbeiten und mitihren eigenen Sachverhalten in Verbindung zu bringen.

Visuelles Denken erleichtert es den Zuhörern, die dargestellten Konzepte inihren eigenen Kontext einzubetten und andere Kontexte besser zu verstehenund zu akzeptieren.

.3 ErfolgsmaßstäbeErfolgreiches visuelles Denken ist unter anderem an folgenden Kriterien zu erken-nen:

• komplexe Informationen werden mithilfe visueller, leicht verständlicherModelle weitergegeben

• bildliche Darstellungen fördern Vergleiche, das Erkennen von Mustern und eine kooperative Darstellung von Ideen

• Produktivität wird durch verbessertes Lernen, leichtere Rekapitulation und einfachere Weiterverfolgung von Sachverhalten mithilfe geeigne-ter Abbildungen gesteigert

• Stakeholder setzen sich tiefer mit Sachverhalten auseinander als wenn nur textliche Darstellungen verwendet würden

• Stakeholder verstehen kritische Informationen, die bei einer rein text-lichen Darstellung unter Umständen übersehen worden wären.

VerhaltenMerkmale des Verhaltens sind nicht nur bei der Business-Analyse relevant. Esgilt als erwiesen, dass vom Verhalten gerade in der Business-Analyse die per-sönliche Erfolgswahrscheinlichkeit abhängt. Diese Merkmale bilden den Kernder persönlichen Kompetenzen eines Business-Analysten. Jedes der hier beschrie-benen Merkmale kann die Leistung maßgeblich bestimmen.

Die Kernkompetenzen im Verhalten fokussieren auf Merkmale und Verhaltens-weisen, die es einem Business-Analysten möglich machen, Vertrauen und Aner-kennung der Stakeholder zu gewinnen. Das kann ein Business-Analyst dadurcherreichen, dass er sich konsequent und nachhaltig ethisch korrekt verhält, Auf-gaben pünktlich und erwartungsgerecht erledigt, mit angemessenem Aufwandhochwertige Ergebnisse abliefert und flexibel auf veränderte Bedürfnisse undUmstände reagiert.

Zu den Merkmalen des Verhaltens gehören:• Ethik

• Persönliche Verantwortlichkeit

BasiskompetenzenVerhalten

230

9.2

• Vertrauenswürdigkeit• Selbstorganisation und Zeitmanagement• Anpassungsfähigkeit.

Ethik

.1 ZweckEthisches Verhalten und die Beachtung ethischer Einflüsse auf Dritte trägt dazubei, dass der Business-Analyst den Respekt der Stakeholder gewinnt. Es ist einewichtige Fähigkeit des Business-Analysten, die möglichen ethischen Schwierig-keiten für eine Unternehmung oder für die Stakeholder zu erkennen, die miteiner vorgeschlagenen Lösung verbunden sein können, und Risiken für solcheSchwierigkeiten möglichst klein zu halten.

.2 BeschreibungEthisches Verhalten erfordert das Verständnis für und die Konzentration aufFairness, Rücksichtnahme und moralisches Verhalten bei allen Aktivitäten undBeziehungen in der Business-Analyse. Weiter ist zu berücksichtigen, wie sicheine vorgeschlagene Lösung auf alle Gruppen von Stakeholdern auswirken kannund dafür zu sorgen, dass alle so fair wie möglich behandelt werden. FairesHandeln heißt nicht, dass die Ergebnisse für alle Betroffenen nützlich sein müssen,setzt aber voraus, dass alle betroffenen Stakeholder die Gründe für Entschei-dungen verstehen. Ethische Sensibilität versetzt den Business-Analysten in dieLage, ethische Dilemmata zu erkennen und Lösungsvorschläge zu unterbreiten.

.3 ErfolgsmaßstäbeZu den Merkmalen ethischen Verhaltens gehören:

• schnelles Erkennen ethischer Dilemmata und das Angebot von Lösungsvorschlägen

• Feedback der Stakeholder, dass Entscheidungen und Handlungen als transparent und fair wahrgenommen werden

• Entscheidungen werden unter Berücksichtigung der Interessen aller Stakeholder getroffen

• Begründungen für Entscheidungen werden klar genannt und ver-standen

• vollständige und zügige Offenlegung möglicher Interessenskonflikte• Aufrichtigkeit im Hinblick auf eigene Fähigkeiten und erbrachte Leistungen sowie Bereitschaft, Verantwortung für Fehler und Irrtümer zu übernehmen.

Basiskompetenzen Verhalten

231

9.2.1

Persönliche Verantwortlichkeit

.1 ZweckPersönliche Verantwortlichkeit ist für einen Business-Analysten wichtig, weil damitsichergestellt werden kann, dass die Aufgaben pünktlich und erwartungsgerechterledigt werden. Der Business-Analyst kann Glaubwürdigkeit aufbauen, indemer dafür sorgt, dass die Bedürfnisse des Unternehmens befriedigt werden.

.2 BeschreibungZu der persönlichen Verantwortlichkeit gehört es, alle Aktivitäten so effektiv zuplanen, dass die Ziele erreicht werden und der gelieferte Nutzen mit dem betrieb-lichen Bedarf übereinstimmt. Weiter gehört dazu, alle Hinweise und Sachverhalteaufzuspüren, die mit den Bedarfen der Stakeholder im Zusammenhang stehen.Eine vollständige Aufgabenerledigung der Business-Analyse bedeutet, vollständige,korrekte und relevante Lösungen zu erarbeiten, die auf einen erkannten Bedarfzurückzuführen sind. Der Business-Analyst übernimmt die Verantwortung dafür,Risiken und andere Sachverhalte zu erkennen und bei Bedarf zu eskalieren. Erstellt auch sicher, dass Entscheider so gut informiert sind, dass sie die Auswir-kungen aller Maßnahmen beurteilen können.

.3 ErfolgsmaßstäbeZu den Merkmalen persönlicher Verantwortlichkeit gehören:

• alle Aufgaben sind bekannt und effektiv geplant• Arbeit wird zeitgerecht erledigt oder rechtzeitig und unter Angabe vonGründen neu geplant

• jeweiliger Status geplanter und ungeplanter Arbeit ist bekannt• Stakeholder haben den Eindruck, dass die Arbeit gut organisiert ist• Risiken und sonstige Sachverhalte sind bekannt und werden angemes-sen behandelt

• vollständig rückführbare Anforderungen werden rechtzeitig abgelie-fert und die Bedarfe der Stakeholder werden erfüllt.

Vertrauenswürdigkeit

.1 ZweckGewinnt ein Business-Analyst das Vertrauen der Stakeholder, fällt es ihm leichter,Informationen auch über sensitive Sachverhalte zu erheben. Das Vertrauen derStakeholder wird gefördert, wenn ihre eigenen Empfehlungen korrekt und fairbewertet werden.


232

9.2.2

9.2.3

.2 BeschreibungVertrauenswürdigkeit ist die Wahrnehmung, dass eine Person es wert ist, ihrVertrauen zu schenken. Wird ein Business-Analyst als vertrauenswürdig angese-hen, kann er damit die bei vielen Stakeholdern anzutreffende Angst vor Verän-derungsprozessen abbauen.

Mehrere Faktoren können dazu beitragen, dass eine Person als vertrauenswürdigangesehen wird:

• Aufgaben und Arbeitsergebnisse werden bewusst und konsequent, zeit-gerecht und innerhalb des Budgets erledigt; dabei werden die erwarteten Ergebnisse so erreicht, dass die Kollegen und Stakeholder das Verhalten des Business-Analysten als berechenbar und vertrauenswürdig empfinden

• Kollegen und Stakeholder schätzen den Business-Analysten als stark ein, indem er Zuversicht verbreitet

• es wird konsequent und fair gehandelt, Konflikte und Anliegen werden unmittelbar aufgegriffen, so dass die Stakeholder den Business-Analystenals ehrenwert und transparent empfinden

• ein konsistenter Zeitplan wird über einen langen Zeitraum aufrecht-erhalten, so dass Kollegen und Stakeholder die Erreichbarkeit des Business-Analysten als vorhersehbar und zuverlässig ansehen.

.3 ErfolgsmaßstäbeZu den Merkmalen der Vertrauenswürdigkeit gehören:

• Stakeholder beteiligen den Business-Analysten in Diskussionen und beider Entscheidungsfindung

• Stakeholder wenden sich an den Business-Analysten, wenn sie Beden-ken haben oder andere Sachverhalte behandeln wollen

• Stakeholder sind bereit, mit dem Business-Analysten schwierige oder kontroverse Themen zu erörtern

• Stakeholder machen nicht den Business-Analysten verantwortlich, wenn Probleme auftreten

• Stakeholder respektieren Ideen und Empfehlungen des Business-Analysten• Stakeholder reagieren auf Empfehlungen des Business-Analysten mit positivem Feedback.

Selbstorganisation und Zeitmanagement

.1 ZweckOrganisiertes Arbeiten und gutes Zeitmanagement ermöglichen es dem Business-Analysten, Aufgaben effektiv zu erledigen und die verfügbare Zeit gut zu nutzen.


233

9.2.4

.2 BeschreibungZur Organisation und zum Zeitmanagement gehören auch die Fähigkeiten, Aufgabenzu priorisieren, sie effizient zu erledigen und mit der verfügbaren Zeit effektivumzugehen. Dazu werden permanent erhebliche Informationsmengen gesammelt,geordnet und so verwaltet, dass sie aktuell und auch später genutzt werden können.Der Business-Analyst muss in der Lage sein, Informationen zu erkennen, die eslohnt, aufbewahrt zu werden, und sie von weniger wichtigen zu unterscheiden.

Effektives Zeitmanagement erfordert die Fähigkeit, Aufgaben und Termine zupriorisieren.

Zu den organisatorischen Techniken gehört auch die Entwicklung von kurz- undlangfristigen Zielen, Aktionsplänen und Priorisierungslisten sowie die Nutzung vonChecklisten. Im Rahmen eines effektiven Zeitmanagements sind auch die Zeitlimitsfür nicht-kritische Aufgaben festzulegen, ist ausreichend Zeit auf sehr riskanteund priorisierte Aufgaben zu verwenden, der erforderliche Zeitaufwand ist beson-ders zu beachten und mögliche Unterbrechungen müssen gemanagt werden.

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven Organisation und eines guten Zeitmanage-ments gehören:

• Fähigkeit, Ergebnisse zeitgerecht abzuliefern• Stakeholder haben den Eindruck, dass sich der Business-Analyst zur richtigen Zeit mit den richtigen Aufgaben auseinandersetzt

• Zeitpläne und Termine werden beherrscht und sind den Stakeholdern bekannt

• Stakeholder haben den Eindruck, dass die Zeit für Meetings und die Lektüre von Unterlagen gut investiert ist

• Meetings, Interviews und Anforderungsworkshops sind gut vorbereitet• relevante Informationen zur Business-Analyse sind dokumentiert und gut geordnet

• Projektpläne und Termine werden eingehalten• es stehen korrekte, gründliche und schlüssige Informationen zur Verfügung, die von den Stakeholdern auch verstanden werden

• es gibt aktuelle Informationen über den Status jedes einzelnen Auf-gabenelements und über die noch zu erledigenden Aufgaben.

Anpassungsfähigkeit

.1 ZweckDer Business-Analyst arbeitet häufig mit vielen unterschiedlichen Stakeholdernzusammen. Die Zusammenarbeit findet in einem sich schnell verändernden


234

9.2.5

Umfeld statt. Um möglichst effektiv zu arbeiten, passt er dazu sein Verhaltenund die gewählten Arbeitsmethoden an die jeweiligen Stakeholder, Unternehmenund Situationen an.

.2 BeschreibungAnpassungsfähigkeit ist immer dann gegeben, wenn Techniken, Arbeitsstile,Methoden und Vorgehensweisen flexibel eingesetzt werden können. Wenn derBusiness-Analyst in der von den Stakeholdern bevorzugten Form mit ihnenzusammenzuarbeitet, kann die Qualität des gelieferten Service maximiert werden.Zusätzlich wird so dem Unternehmen geholfen, besser seine Ziele zu erreichen.Die Fähigkeit, sich an verschiedene Situationen und Kontexte anzupassen, setztsowohl ein Interesse daran voraus, was andere wünschen und benötigen, wieauch die Bereitschaft, unterschiedliche Verhaltensweisen auszuprobieren.

Der Business-Analyst muss manchmal die Art der Zusammenarbeit mit den Stake-holdern modifizieren, beispielsweise bei der Art, wie Interviews durchgeführtoder wie Workshops moderiert werden. Unterschiedliche Stakeholder kommenauch unterschiedlich mit den verschiedenen Instrumenten aus dem Werkzeug-kasten der Business-Analyse zurecht. Einige Menschen sind eher visuelle Typenund bevorzugen in Modellen, Diagrammen oder Bildern grafisch aufbereiteteInformationen; andere nutzen lieber verbale oder textliche Beschreibungen.Eine erfolgreiche Zusammenarbeit wird wahrscheinlicher, wenn der Business-Analyst erkennen kann, welche Ansätze funktionieren, und sich dann auchentsprechend verhält.

Wenn sich in einem Unternehmen die Ziele verändern, muss der Business-Analystdiese Veränderungen akzeptieren und berücksichtigen. Ähnliches gilt, wenn sicheine Situation ändert oder wenn unvorhergesehene Ereignisse eintreten. Dannmüssen die Pläne geändert oder weitere Optionen erarbeitet werden, um denmaximalen Nutzen zu liefern. Der Business-Analyst passt sich an, wenn sich dieAnforderungen der Stakeholder oder des Unternehmens ändern oder wenn derKontext, in dem ein Ziel verfolgt wird, sich wandelt. Ändert sich der Bedarfselbst, reagiert der Business-Analyst darauf, indem er Pläne und Vorgehensweisenso anpasst, dass ein möglichst großer Nutzen aus der vorgeschlagenen Lösungerreicht werden kann.

.3 ErfolgsmaßstäbeZu den Merkmalen der Anpassungsfähigkeit gehören:

• Mut zeigen, unkonventionell zu handeln• Anpassung an veränderte Bedingungen und Umwelten• andere Sichtweisen und Vorgehen abwägen und wertschätzen• im Fall von Veränderungen und Mehrdeutigkeiten eine positive Haltung zeigen


235

• Bereitschaft zeigen, neue Methoden, Verfahren oder Techniken zu erlernen, um bestmöglich die Ziele zu erreichen

• Verhalten auf die jeweiligen Bedingungen abstimmen• Gewinnen und Nutzen neuer Informationen und Erwerb neuer Fähig-keiten, um neuen Herausforderungen zu begegnen

• Bereitschaft, Aufgaben, Rollen und Projektzuständigkeiten zu ändern, wenn sich die betriebliche Realität verändert

• weitreichende Anpassung des persönlichen Auftretens gegenüber unterschiedlichen Individuen und Gruppen

• Bereitschaft, rückblickend zu bewerten, was funktioniert hat und was nicht, und was beim nächsten Mal anders gemacht werden könnte.

GeschäftsverständnisDer Business-Analyst muss Geschäftsverständnis besitzen, um effektiv innerhalbder Branche, des Wirtschaftszweigs, der Unternehmung, der jeweiligen Lösungund der gewählten Methodologie arbeiten zu können. Geschäftsverständnisermöglicht es dem Business-Analysten, besser die übergreifenden Konzepte zuverstehen, von denen Strukturen, Nutzen und Werte abhängen, die mit einemkonkreten Change oder einem Bedarf verbunden sind.

Zu den Fähigkeiten des Geschäftsverständnisses gehören:• Unternehmerisches Verständnis• Branchenkenntnis• Unternehmenskenntnis• Kenntnis bestehender Lösungen• Methodenkenntnis.

Unternehmerisches Verständnis

.1 ZweckBusiness-Analyse setzt das Verständnis grundlegender Geschäftsprinzipien undBest Practices voraus, wenn geeignete Lösungen erarbeitet werden sollen.

.2 BeschreibungUnternehmerisches Verständnis ist die Fähigkeit, den betrieblichen Bedarf aufder Basis von Erfahrungen und Wissen zu verstehen, die in anderen Situationenerworben worden sind. Unternehmen verwenden häufig ähnliche Praktiken inFinanzen, Logistik, Verkauf, Marketing, Supply Chain Management, Human

BasiskompetenzenGeschäftsverständnis

236

9.3

9.3.1

Resources und bei der Umsetzung gesetzlicher Vorgaben. UnternehmerischesVerständnis ist die Fähigkeit, das auf diesen Gemeinsamkeiten basierende Wissenin unterschiedlichen Situationen anzuwenden.

Wenn mögliche Lösungen erarbeitet werden, kann es sehr hilfreich sein, zuwissen, wie andere Unternehmen Herausforderungen bewältigt haben. Sich derErfahrungen und Herausforderungen aus der Vergangenheit bewusst zu sein,kann dem Business-Analysten dabei helfen, herauszufinden, welche Informationenin der gegenwärtigen Situation genutzt werden könnten.

.3 ErfolgsmaßstäbeZu den Merkmalen des unternehmerischen Verständnisses gehören:

• mögliche Restriktionen und Chancen werden frühzeitig erkannt• wenn Änderungen einer Situation Anpassungen für ein Vorhaben erfordern, wird dies frühzeitig erkannt

• mögliche Risiken werden erkannt, Maßnahmen zum Management desRisikos werden getroffen

• Möglichkeiten für Einsparungen und Gewinnsteigerungen werden erkannt

• in veränderten Situationen werden mögliche neue Optionen erkannt.

Branchenkenntnis

.1 ZweckBranchenkenntnis versetzt den Business-Analysten in die Lage, bestehende Prak-tiken und Aktivitäten innerhalb einer Branche ebenso zu verstehen wie ähnlicheProzesse, die innerhalb der Branche genutzt werden.

.2 BeschreibungZu den Branchenkenntnissen gehört das Verständnis über:

• aktuelle Trends • Marktkräfte• Einflussfaktoren auf die • KernprozesseEntwicklung von Märkten

• Services • Produkte• Definitionen • Kundensegmente• Anbieter • Praktiken und Verfahren• Regulierungen • andere Faktoren, die eine Branche

beeinflussen oder von einer Branche beeinflusst werden.

Basiskompetenzen Geschäftsverständnis

237

9.3.2

Zur Branchenkenntnis gehört auch das Verständnis dafür, wie eine Unternehmunginnerhalb einer Branche positioniert ist und welche wechselseitigen Beziehungenim Hinblick auf Markt und Human Resources bestehen.

Soll Wissen über eine bestimmte Branche, einen Mitbewerber oder ein Unter-nehmen aufgebaut werden, können die folgenden Fragen hilfreich sein:

• Wer sind die führenden Unternehmen in der Branche?• Welche Unternehmen treiben oder beeinflussen eine Branche?• Was bringt es, sich mit diesen Unternehmen auseinanderzusetzen?• Wer ist aktiv zur Förderung der Publizität, wer nimmt an Tagungen teil und wer liefert Marketing-Materialien?

• Wie sehen die Produkte und Dienstleistungen im Vergleich aus?• In welchen Punkten ist ein Unternehmen besonders erfolgreich, welche Benchmarks könnten genutzt werden?

• Welche Lieferanten, Praktiken, Ausrüstung und Werkzeuge werden von den einzelnen Unternehmen genutzt und warum werden sie genutzt?

• Was sind mögliche Einflüsse von Unwettern, politischen Unruhen oder Naturkatastrophen?

• Welches sind die Zielkunden, welche davon werden auch von den Mit-bewerbern bearbeitet?

• Welche Einflüsse haben saisonale Zyklen auf Produktion, Marketing und Verkauf? Hat dies Einfluss auf den Personalbestand oder erfordert es Änderungen der Prozesse?

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven Branchenkenntnis gehören:

• Kenntnisse über wichtige Mitbewerber und Partner• Fähigkeit, zentrale Trends der Branche zu erkennen• mit den wichtigsten Kundensegmenten vertraut sein• gemeinsame Produkte und Produkttypen kennen• Informationsquellen über die Branche kennen, einschließlich relevanterVerbände oder Zeitschriften

• für eine Branche spezifische Begriffe, Standards, Prozesse und Methodologien kennen und verstehen

• Gesamtheit der Regeln und Vorschriften kennen, die für eine Branche relevant sind.


238

Unternehmenskenntnis

.1 ZweckZur Unternehmenskenntnis gehört das Verständnis der Managementstrukturenund Geschäftsarchitekturen eines Unternehmens.

.2 BeschreibungZur Unternehmenskenntnis gehören das Wissen darüber, wie das UnternehmenGewinne erarbeitet, wie es seine Ziele erreicht, wie die Aufbauorganisation aus-sieht, welche Beziehungen zwischen Geschäftseinheiten bestehen und welchePersonen zentrale Positionen innehaben bzw. zentrale Stakeholder sind. Dazugehört auch das Verständnis über die formalen und informalen Kommunikati-onskanäle und über die internen politischen Einflüsse auf die Entscheidungsfin-dung.

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven Unternehmenskenntnis gehören:

• bestehende formale und informale Kommunikationskanäle und Ein-flussstrukturen werden berücksichtigt

• Terminologie oder Jargon im Unternehmen ist bekannt• angebotene Produkte oder Dienstleistungen werden verstanden• Fachexperten des Unternehmens sind bekannt• bestehende organisatorische Beziehungen und politische Einflüsse werden angemessen berücksichtigt.

Kenntnis bestehender Lösungen

.1 ZweckDer Business-Analyst kann seine Kenntnisse über bestehende Lösungen dazunutzen, die Wege zu identifizieren, die am besten geeignet sind, um einenChange umzusetzen.

.2 BeschreibungWenn eine Business-Analyse dazu dient, eine bestehende Lösung zu verbessern,nutzt der Business-Analyst das Wissen und die Erfahrungen aus seinen früherenTätigkeiten. Sind im Markt verfügbare Lösungen oder Anbieter bekannt, könnenmögliche Lösungsvarianten leichter gefunden werden. Der Business-Analyst kannsein bestehendes Wissen durch Erhebungen oder vertiefte Analysen aufwerten.

Basiskompetenzen Geschäftsverständnis

239

9.3.3

9.3.4

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven Kenntnis bestehender Lösungen gehören:

• geringerer Zeitverbrauch oder niedrigere Kosten bei der Einführung einer Veränderung

• weniger Zeitbedarf für die Anforderungsanalyse und/oder den Lösungsentwurf

• leichtere Einschätzung, ob ein größeres Change-Vorhaben im Hinblick auf den gelieferten Nutzen gerechtfertigt ist oder nicht

• erkennen, welche vorhandenen, aber nicht genutzten Fähigkeiten ein-gesetzt werden können, um Werte zu schaffen.

Methodenkenntnis

.1 ZweckKennt der Business-Analyst die in der Unternehmung genutzten Methoden,stehen ihm Informationen über den Kontext, Abhängigkeiten, Chancen undRestriktionen zur Verfügung, die bei der Business-Analyse genutzt werden.

.2 BeschreibungMethoden liefern Vorgaben über das Timing (große oder inkrementelle Bear-beitungsschritte), das Vorgehen, die Rollen der Beteiligten, das akzeptierte Risi-koniveau und andere Aspekte, die für ein Vorgehen und das Management einesChange-Vorhabens relevant sind. Unternehmen übernehmen Methoden oderentwickeln ihre eigenen, damit sie auf die jeweilige Kultur, den Reifegrad, diegewünschte Flexibilität, das Risiko, die Unsicherheit und die betriebliche Steuerungausgerichtet sind.

Kenntnisse über ein breiteres Spektrum von Methoden erlauben es dem Busi-ness-Analysten, sich schnell in neue Arbeitsumfelder hineinzufinden und dorterfolgreich zu arbeiten.

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven Methodenkenntnis gehören:

• Fähigkeit, mit einer veränderten Methode umzugehen• Bereitschaft, neue Methoden zu erlernen• erfolgreiche Integration der Aufgaben und Techniken der Business-Analyse in die bestehende Methode

• Vertrautheit mit Begriffen, Tools und Techniken einer Methode• Fähigkeit, mehrere Rollen bei Aufgaben zu übernehmen, die von einer Methode vorgeschrieben sind.


240

9.3.5

KommunikationsfähigkeitKommunikation ist ein Vorgang, bei dem ein Sender Informationen an einenEmpfänger so weiterleitet, dass die vom Sender beabsichtigte Bedeutung ankommt.Aktive Zuhörtechniken helfen dabei, das wechselseitige Verstehen und Vertrauenzu vertiefen. Eine effektive Kommunikation hilft allen Stakeholdern.

Kommunikation kann sich verschiedener Methoden bedienen: Verbale, nonver-bale, physische oder schriftliche Kommunikation. Die meisten Formen der Kom-munikation nutzen Worte, einige setzen auch Bewegungen oder Ausdrucksfor-men ein. Worte, Gesten und Sätze haben nicht für jedes Individuum die gleicheBedeutung. Zu einer effektiven Kommunikation gehört es, dass Sender undEmpfänger die übermittelten Sachverhalte gleich verstehen. Ein gemeinsamesGlossar und klare Ziele sind wirksame Hilfen, um Missverständnisse und die sichdaraus ergebenden Komplikationen zu vermeiden.

Zu einer effektiven Kommunikation gehört es, den Kommunikationsstil und diegenutzten Techniken auf das Wissensniveau und den Kommunikationsstil derEmpfänger abzustimmen. Gute Kommunikatoren wissen, wie der Ton, die Kör-persprache oder der jeweilige Kontext die Bedeutung von Worten verändernkann. Es kann nützlich sein, sich vorab mit der Begriffswelt der Empfänger undden dort genutzten Konzepten zu beschäftigen.

Zu einer effektiven Kommunikation gehört es auch, dass sich der Sender überden Empfänger informiert. Gibt es zwischen Sender und Empfänger deutlicheUnterschiede, z.B. in der Muttersprache, der Kultur, der Motivation, hinsichtlichder Prioritäten, der Kommunikation, des Lernens oder des Kommunikationsstils,dann müssen unter Umständen ganz spezielle Methoden genutzt werden. Jedeseinzelne Informationselement muss dann sorgfältig aufbereitet und zusammen-gestellt werden, um sicherzustellen, dass es eindeutig ist und verstanden wird.

Bei der Planung einer Kommunikation können die folgenden Überlegungen hilf-reich sein:

• beachten, was der Empfänger bereits weiß und was nicht• Informationen logisch und nachvollziehbar aufbereiten• festlegen, auf welche Weise kommuniziert werden soll, um die beabsichtigten Inhalte zu übermitteln (z.B. visuelle Hilfen, Grafiken, Diagramme oder Aufzählungen nutzen)

• sich die Erwartungen der Empfänger bewusstmachen.

Zu den Kernkompetenzen der Kommunikationsfähigkeit gehören:• Verbale Kommunikation• Nonverbale Kommunikation• Schriftliche Kommunikation

• Zuhören.

Basiskompetenzen Kommunikationsfähigkeit

241

9.4

Verbale Kommunikation

.1 ZweckDer Business-Analyst nutzt die verbale Kommunikation um Ideen, Konzepte,Fakten oder Meinungen an unterschiedlichste Stakeholder zu übermitteln.

.2 BeschreibungEine verbale Kommunikation nutzt das gesprochene Wort, um Informationenvon einem Sender an einen Empfänger zu übermitteln. Die verbale Kommuni-kation wird genutzt, um Informationen der Business-Analyse, Ideen, Konzepte,Fakten und Meinungen zu übermitteln. Auf diesem Weg kann effizient kom-muniziert werden, da auch emotionale oder nonverbale Signale übermittelt wer-den. Parallel dazu kann auch eine schriftliche Kommunikation stattfinden.

Bei der verbalen Kommunikation geht es insbesondere um die Wortwahl desSenders und um den gewählten Ton. Wenn der Empfänger den Sender sehenkann, ist auch die nonverbale Kommunikation maßgeblich dafür, wie die Nach-richten verstanden werden. Wenn der Sender den Empfänger sehen kann, gibtder Empfänger eine Antwort, womit beide in einen Dialog eintreten, selbstwenn der Empfänger sich verbal nicht äußert. Wenn der Sender die nonverbaleKommunikation des Empfängers verfolgt, kann er bei Bedarf die Nachrichtunaufgefordert noch einmal für den Adressaten aufbereiten.

Wenn der Sender sich der Wirkung des gewählten Tons bewusst ist und weiß,wie der Ton den Empfänger positiv oder negativ beeinflussen kann, steigert dasdie Qualität der verbalen Kommunikation. Zu einer effektiven Kommunikationgehört es, dass man sich verständlich ausdrücken kann. Der Sender sollte dieverbale Kommunikation immer auch mit dem aktiven Zuhören verbinden, umeine korrekte Übermittlung sicherzustellen.

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven verbalen Kommunikation gehören:

• Formulierung von Sachverhalten auf verschiedene Art und Weise, um die Verständigung zu verbessern

• Teilnahme an Unterhaltungen, um daraus Schlüsse ziehen zu können• Durchführung gut aufbereiteter Präsentationen• Übermittlung wichtiger Informationen in ruhiger und vernunftbetonterWeise und Vorstellung von Lösungsoptionen.

BasiskompetenzenKommunikationsfähigkeit

242

9.4.1

Nonverbale Kommunikation

.1 ZweckFähigkeiten der nonverbalen Kommunikation erlauben es, Nachrichten beispiels-weise durch Bewegungen, Mimik, Haltung, Gesten oder Blickkontakt zu sendenund zu empfangen.

.2 BeschreibungKommunikation fokussiert normalerweise auf gesprochene oder geschriebeneWorte. Bei einer nonverbalen Kommunikation wird jedoch mehr übermittelt alsWorte ausdrücken können. Stimmungen, Einstellungen und Gefühle äußernsich in Körperhaltung und Mimik. Eine nonverbale Kommunikation beginntunmittelbar, sobald eine Person eine andere sehen kann. Die effektive Nutzungder Fähigkeiten einer nonverbalen Kommunikation kann eine vertrauensvolleZusammenarbeit fördern. Sich der nonverbalen Kommunikation bewusst zusein, heißt aufmerksam zu beobachten und auf Gefühle einzugehen, die vonder anderen Seite nicht mit Worten ausgedrückt werden.

Gesten und Ausdrücke geben kein vollständiges Bild. Sie sind aber Indikatorender Gefühle und Absichten des Kommunizierenden. Wenn beispielsweise dienonverbale Kommunikation eines Stakeholders nicht mit der verbalen Nachrichtübereinstimmt, kann der Business-Analyst unter Umständen versuchen, imGespräch die Quelle für diese Abweichung herauszufinden.

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven nonverbalen Kommunikation gehören:

• Körpersprache wird bewusst wahrgenommen, dabei ist man sich aber immer darüber im Klaren, dass nur mit der Körpersprache allein eine vollständige Kommunikation nicht möglich ist

• Aufbau eines Vertrauensverhältnisses und Verbesserung der Informa-tionsübermittlung durch nonverbale Kommunikation

• weichen die nonverbalen Signale von den verbalen Nachrichten ab, wird dies gezielt angesprochen und zu klären versucht.

Schriftliche Kommunikation

.1 ZweckDer Business-Analyst nutzt die schriftliche Kommunikation, um Ideen, Konzepte,Fakten oder Meinungen an unterschiedlichste Stakeholder zu übermitteln.

Basiskompetenzen Kommunikationsfähigkeit

243

9.4.2

9.4.3

.2 BeschreibungBei einer schriftlichen Kommunikation werden Texte, Symbole, Modelle undSkizzen genutzt, um Informationen zu übermitteln. Dabei ist es hilfreich, wennman die Empfänger kennt. Bei der Darstellung von Informationen und Ideenmüssen die richtigen Worte gewählt werden, sodass die Empfänger die beab-sichtigte Bedeutung verstehen. Dabei besteht die zusätzliche Herausforderung,dass die Übermittlung nicht zur gleichen Zeit und nicht am gleichen Ort stattfindetwie die Erstellung der Informationen.

Eine effektive schriftliche Kommunikation setzt ein breites Vokabular, die Beherr-schung von Grammatik und Sprachstil und das Verständnis darüber voraus, wiedie verwendeten Begriffe von der Zuhörerschaft verstanden werden. Mit einerschriftlichen Kommunikation können große Informationsmengen übermitteltwerden, die dafür benötigten Fähigkeiten stehen aber nicht allen Menschen zurVerfügung und müssen entwickelt werden.

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven schriftlichen Kommunikation gehören:

• Schreibstil wird auf die Anforderungen der Empfänger angepasst• Grammatik und Sprachstil müssen korrekt sein• es werden Worte gewählt, deren Bedeutung den Empfängern bekannt ist• Leser sind in der Lage, den Inhalt der schriftlichen Kommunikation zu umschreiben und zu wiederholen.

Zuhören

.1 ZweckEffektives Zuhören erlaubt es dem Business-Analysten, verbal übermittelte Infor-mationen korrekt zu verstehen.

.2 BeschreibungZuhören bedeutet nicht nur Worte aufzunehmen, sondern auch deren Bedeutungim Zusammenhang zu verstehen. Werden die Fähigkeiten effektiven Zuhörensgenutzt, versteht der Business-Analyst nicht nur besser, was gesagt wird, er sig-nalisiert dem Gegenüber auch, dass er ihn ernst nimmt.

Aktives Zuhören bedeutet sowohl die Aufnahme als auch die Interpretation des-sen, was die andere Person zu kommunizieren versucht, welcher Sinn also hinterden genutzten Worten steht, um so die Essenz der Nachricht zu verstehen. Beieinem aktiven Zuhören werden Inhalte auch zusammengefasst und in anderenWorten wiederholt, um sicherzustellen, dass Sender und Empfänger dasselbemeinen.

BasiskompetenzenKommunikationsfähigkeit

244

9.4.4

.3 ErfolgsmaßstäbeZu den Merkmalen eines effektiven Zuhörens gehören:

• es wird aufmerksam zugehört• Sprecher wird verbal und nonverbal ermutigt• es wird Feedback gegeben, um das Verständnis zu überprüfen• beim aktiven Zuhören werden eigene Bewertungen zurückgestellt.

InteraktionsfähigkeitInteraktionsfähigkeiten zeigen sich darin, dass der Business-Analyst in der Lageist, zu unterschiedlichen Personen, Führungskräfte eingeschlossen, Beziehungenaufzubauen, mit ihnen zu kooperieren und zu kommunizieren. Kollegen, Team-mitglieder, Entwickler, Verkäufer, Fortbildungs- und Entwicklungsexperten, Anwen-der, Kunden und sonstige Fachexperten sind typische Partner für Interaktionen.

Der Business-Analyst ist in einer einzigartigen Position, um die Kommunikationder Stakeholder zu moderieren, Leadership zu zeigen, den Nutzen von Lösungenherauszustellen und dafür zu sorgen, dass Stakeholder vorgeschlagene Lösungenund Veränderungen unterstützen.

Zu den Kernkompetenzen der Interaktionsfähigkeit gehören:• Moderation• Leadership und Einflussnahme• Zusammenarbeit• Verhandlung und Konfliktlösung• Wissensvermittlung.

Moderation

.1 ZweckDer Business-Analyst moderiert Interaktionen zwischen Stakeholdern, um siebei der Entscheidungsfindung, Problemlösung, beim Austausch von Ideen undInformationen ebenso zu unterstützen wie bei der Suche nach Kompromissenhinsichtlich der Priorisierung von Anforderungen. Auch wenn es um Verhand-lungen oder Konfliktlösung geht, kann der Business-Analyst Interaktionen zwischenbeteiligten Stakeholdern moderieren.

.2 BeschreibungModeration ist die Fähigkeit, Diskussionen in einer Gruppe so zu steuern, dassalle Beteiligten ihre eigenen Gesichtspunkte einbringen können, und sicherzu-

Basiskompetenzen Interaktionsfähigkeit

245

9.5

9.5.1

stellen, dass die Beteiligten auch andere eingebrachte Sichtweisen anerkennenund willkommen heißen.

.3 ErfolgsmaßstäbeZu den Merkmalen einer effektiven Moderation gehören:

• Beteiligten wird klargemacht, dass der Moderator im Hinblick auf den Prozess neutral ist, keine Entscheidungen fällt und die Sachverhalte nicht selbst eingebracht hat

• alle Beteiligten werden zur aktiven Teilnahme ermutigt• Moderator ist neutral und überparteilich, greift aber in den Prozess ein,wenn es notwendig ist, um Vorschläge zu machen oder Hintergründe zu verdeutlichen

• es werden grundlegende Regelungen vereinbart, etwa, dass Vorschläge unvoreingenommen angehört werden, auf bereits Behandeltem aufge-baut wird, Ideen nicht gleich verworfen werden und anderen erlaubt wird, zu sprechen und ihre eigenen Vorstellungen auszudrücken

• es wird dafür gesorgt, dass die Beteiligten die vorgebrachten Gesichts-punkte korrekt verstehen

• es werden Instrumente für Meetings genutzt, um eine Diskussion fokussiert und strukturiert durchzuführen

• es wird dafür gesorgt, dass der rote Faden eingehalten wird• Interessen der Beteiligten, deren Motivation und deren Ziele werden verstanden und berücksichtigt.

Leadership und Einflussnahme

.1 ZweckDer Business-Analyst setzt Leadership ein und nutzt Fähigkeiten zur Einflussnahme,wenn es darum geht, Stakeholder bei der Auswertung von Informationen undLösungsoptionen zu unterstützen. Er versucht, in einem Change-Prozess Einigkeitherzustellen und die Unterstützung und Kooperation der Stakeholder zu erreichen.

.2 BeschreibungLeadership und Einflussnahme bedeuten, dass Menschen motiviert werden, zusam-menzuarbeiten und gemeinsame Ziele zu erreichen. Wenn die individuellen Motive,Bedürfnisse und Fähigkeiten der Stakeholder bekannt sind und kanalisiert werdenkönnen, ist der Business-Analyst in der Lage, die Ziele der Unternehmung zu errei-chen. Da der Business-Analyst dafür zuständig ist, Informationen der Business-Analyse zu definieren, zu analysieren und zu kommunizieren, kann er Leadershipzeigen und Einfluss nehmen, auch ohne formell weisungsberechtigt zu sein.

BasiskompetenzenInteraktionsfähigkeit

246

9.5.2

.3 ErfolgsmaßstäbeZu den Merkmalen eines effektiven Leaderships und einer effektiven Einfluss-nahme gehören:

• weniger Widerstand gegen notwendige Veränderungen• Artikulation einer klaren und inspirierenden Vision über den gewünschten zukünftigen Zustand

• erfolgreiche Inspiration Dritter, um eine Vision zur Aktion zu machen• Beeinflussung der Stakeholder mit dem Ziel, wechselseitige Interessen zu verstehen

• effektive Nutzung von Techniken der Zusammenarbeit, um andere zu beeinflussen

• Stakeholder werden beeinflusst, übergreifende Ziele gegenüber den eigenen Vorstellungen abzuwägen

• Sachverhalte werden in einen anderen Zusammenhang gestellt, mit dem Ziel, andere Perspektiven zu verstehen und gemeinsame Ziele zu akzeptieren.

Zusammenarbeit

.1 ZweckDie Fähigkeit zum Teamwork erlaubt es dem Business-Analysten, produktiv mitTeammitgliedern, Stakeholdern und anderen Beteiligten zusammenzuarbeiten,sodass Lösungen effektiv erarbeitet und eingeführt werden können.

.2 BeschreibungDer Business-Analyst arbeitet oft als Mitglied in einem Team zusammen mitanderen Business-Analysten, Projektmanagern, Stakeholdern und Fachexperten.Die persönlichen Beziehungen zwischen diesen Rollenträgern sind kritischeErfolgsfaktoren für jedes Projekt oder Unternehmen. Es ist für den Business-Analysten wichtig, zu verstehen, wie ein Team entwickelt wird und wie es funk-tioniert. Auch ist es sehr wichtig, die Dynamik der Teamentwicklung und derenBedeutung für den Fortschritt im Team in verschiedenen Phasen eines Projekteszu verstehen. Zu wissen, wie und wann ein Team durch den Lebenszyklus einesProjektes voranschreitet, und die eigene Rolle dementsprechend anzupassen,kann mögliche negative Einflüsse auf ein Team verringern.

Vertrauen zwischen den Teammitgliedern aufzubauen und aufrechtzuerhalten,fördert den Zusammenhalt in einem Team und hilft ihm, die größtmögliche Leis-tung zu erbringen. Wenn die Teammitglieder aktiv an den Bedingungen füreine positive und vertrauensvolle Teamentwicklung arbeiten, lassen sich schwierigeEntscheidungen und Herausforderungen leichter beherrschen.


247

9.5.3

Konflikte in Teams sind normal. Wird vernünftig damit umgegangen, kann einTeam sogar davon profitieren. Werden Konflikte gelöst, muss sich das Team aufdie Positionen, Annahmen, Beobachtungen und Erwartungen aller Teammitgliederkonzentrieren. Werden solche Probleme bearbeitet, kann das einen sehr wertvollenBeitrag dazu leisten, die Analyse zu vertiefen und die Lösung zu verbessern.

.3 ErfolgsmaßstäbeZu den Merkmalen effektiven Teamworks gehören:

• es wird eine kooperative Arbeitsumgebung gefördert• Konflikte werden effektiv gelöst• Mitglieder bauen untereinander ein Vertrauensverhältnis auf• Team setzt sich gemeinsame, hohe Leistungsziele• Identifikation der Mitglieder mit den gemeinsamen Zielen wird gefördert.

Verhandlung und Konfliktlösung

.1 ZweckDer Business-Analyst ist gelegentlich für die Mediation von Verhandlungen zwi-schen Stakeholdern zuständig, mit dem Ziel, ein gemeinsames Verständnis zuentwickeln oder eine Übereinstimmung zu finden. In diesem Prozess hilft derBusiness-Analyst Konflikte zu lösen und Meinungsunterschiede abzubauen, umdie Arbeitsbeziehungen zwischen den Stakeholdern und Teammitgliedern auf-rechtzuerhalten und zu stärken.

.2 BeschreibungZur Verhandlung und Konfliktlösung gehört die Begleitung von Diskussionenzwischen den Beteiligten, um ihnen zu helfen, unterschiedliche Sichten aufeinen Sachverhalt zu akzeptieren, Meinungsverschiedenheiten zu lösen und zuSchlussfolgerungen zu kommen, die von allen Beteiligten getragen werden. Füreine erfolgreiche Verhandlung und Konfliktlösung müssen die zugrundeliegendenInteressen der Beteiligten bekannt sein und es muss geklärt werden, wie sichdiese Interessen von den vorgetragenen Positionen unterscheiden, um den Betei-ligten bei der Suche nach befriedigenden Lösungen zu helfen. Dabei achtet derBusiness-Analyst darauf, dass die Ergebnisse mit der übergreifenden Lösungund den Zielen des Unternehmens verträglich sind.

.3 ErfolgsmaßstäbeZu den Merkmalen effektiver Verhandlung und Konfliktlösung gehören:

• es wird planvoll vorgegangen, um sicherzustellen, dass der gewählte Ton, die gezeigte Haltung und die verwendeten Methoden die Gefühleund Bedarfe aller Seiten berücksichtigen

BasiskompetenzenInteraktionsfähigkeit

248

9.5.4

• es wird erkannt, wenn scheinbar unverträgliche Bedarfe der Parteien miteinander versöhnt werden können und dass für beide Seiten eine befriedigende Lösung gefunden werden kann, ohne dass eine Seite verliert

• es wird versucht, die Sachfragen von den Personen zu trennen, sodass Themen diskutiert werden können, ohne die Arbeitsbeziehungen zu belasten

• es wird anerkannt, dass eine effektive Verhandlung und Konfliktlösungnicht immer in einer Sitzung erfolgen kann und dass gelegentlich mehrere Termine benötigt werden.

Wissensvermittlung

.1 ZweckFähigkeiten zur Wissensvermittlung helfen dem Business-Analysten dabei, Infor-mationen zur Business-Analyse, zu Konzepten, Ideen und Sachverhalten effektivzu kommunizieren. Diese Fähigkeiten tragen auch dazu bei, dass Informationenverstanden und behalten werden.

.2 BeschreibungWissensvermittlung ist ein Prozess, in dem andere beim Wissenserwerb begleitetwerden. Der Business-Analyst ist dafür verantwortlich, dass die übermitteltenInformationen von den Stakeholdern auch verstanden werden. Er klärt Sachver-halte mit den Stakeholdern, indem er diese dabei unterstützt, den Kontext unddie zugrundeliegenden Bedürfnisse zu verstehen. Dazu werden Fähigkeiten derWissensübermittlung benötigt, um die am besten geeigneten visuellen, verbalen,schriftlichen oder kinästhetischen („handgreiflichen“) Ansätze auszuwählen,abhängig von dem vermittelten Inhalt oder den genutzten Techniken. Damitwird auch versucht, das Engagement der Stakeholder zu fördern und durch dasgemeinsame Lernen mehr Klarheit zu gewinnen. Der Business-Analyst erhebtoder erlernt häufig neues Wissen, das er dann an die Stakeholder weitergibt.

.3 ErfolgsmaßstäbeZu den Merkmalen effektiver Wissensvermittlung gehören:

• es werden unterschiedliche Methoden der Wissensübermittlung genutzt• durch die intensive Beteiligung der Stakeholder entstehen neue Informationen

• es wird überprüft, ob den Zuhörern klar ist, welche Kernbotschaften sie erlernen sollen

• die Stakeholder weisen nach, dass sie neues Wissen, neue Fakten, Konzepte und Ideen besitzen.


249

9.5.5

Werkzeuge und TechnologieDer Business-Analyst nutzt eine Vielzahl von Software-Anwendungen, die dazudienen, die Kommunikation und Kooperation zu unterstützen, Anforderungs-dokumente zu schaffen und zu pflegen, Konzepte zu modellieren, Sachverhaltenachzuverfolgen und generell die Produktivität zu steigern.

Bei der Dokumentation von Anforderungen werden häufig Werkzeuge zur Text-verarbeitung verwendet, während bei der Ableitung von Anforderungen mögli-cherweise Werkzeuge zum Prototyping und zur Simulation oder auch spezialisierteWerkzeuge für die Modellierung und für die Erstellung von Grafiken genutztwerden.

Werkzeuge zum Management von Anforderungen unterstützen den Workflowvon Anforderungen, die Einholung von Genehmigungen, Baselining (zusam-mengehörige Versionen in der Software-Versionsverwaltung definieren) und dieÜberwachung von Änderungen. Diese Werkzeuge unterstützen auch die Nach-vollziehbarkeit von Anforderungen und helfen dabei, Auswirkungen geänderterAnforderungen zu ermitteln.

Die Interaktion mit den Stakeholdern und den Mitgliedern des Teams kannWerkzeuge der Kommunikation und Kooperation erfordern. Präsentationssoft-ware kann Ideen verdeutlichen und Diskussionen zwischen den Stakeholdernund den Teammitgliedern fördern.

Zu den Werkzeugen und Technologien der Basiskompetenzen der Business-Ana-lyse gehören:

• Office-Anwendungen und -Technologie• Business-Analyse-Werkzeuge und -Technologie• Kommunikationswerkzeuge und -technologie.

Office-Anwendungen und -Technologie

.1 ZweckDer Business-Analyst nutzt Office-Anwendungen und -Technologie zur Doku-mentation und Weiterverfolgung von Informationen und Artefakten.

.2 BeschreibungOffice-Anwendungen und -Technologie versetzen den Business-Analysten in dieLage, Informationen zu organisieren, aufzugliedern, zu verarbeiten, zu verstehenund zu übermitteln. Wenn diese Tools genutzt werden sollen, müssen sie ersteinmal erlernt werden. Wird ein Programm beherrscht, erleichtert das oft auchden Zugang zu anderen, ähnlichen Programmen. Einige Programme bieten auchZusatzleistungen für andere Programme oder dienen dazu, zwischen Programmen

BasiskompetenzenWerkzeuge und Technologie

250

9.6

9.6.1

Informationen auszutauschen (z.B. Programme zum Import oder Export vonDateien). Viele Unternehmen nutzen solche Tools, um Informationen auszuwerten,zu verteilen oder zu speichern.

Zu den Office-Anwendungen und -Technologien gehören:• Programme zur Textverarbeitung und Präsentation: Sie bieten die Mög-lichkeit, Informationen als Brief, Zeitung, Poster, Forschungsdokument,Bildschirmpräsentation oder Animation zu präsentieren. Textverarbei-tung wird normalerweise genutzt, um Anforderungsdokumente zu erstellen und zu pflegen. Sie bieten weitreichende Möglichkeiten der Formatierung und der Art der Präsentation. Für die Textverarbeitung gibt es vielfältige standardisierte Templates zur Dokumentation von Anforderungen. Die meisten Programme zur Textverarbeitung unter-stützen aber die Nachverfolgung von Änderungen und die Aufzeich-nung von Kommentaren so gut wie gar nicht. Auch sind sie für die gemeinsame Nutzung durch mehrere Autoren weniger geeignet. Allerdings gibt es in der Cloud Lösungen, mit denen die Zusammen-arbeit unterstützt wird.

• Präsentationssoftware: Sie dient zur Entwicklung von Schulungsunter-lagen oder zur Präsentation von Informationen, mit deren Hilfe Diskus-sionen zwischen den Stakeholdern gefördert werden. Einige bieten rudimentäre Möglichkeiten, Anforderungen zu ermitteln oder die Zusammenarbeit zu fördern.

• Tabellenkalkulation: Sie erlauben mathematische und logische Opera-tionen. Oft werden sie dazu genutzt, Listen zu pflegen (wie z.B. elemen-tare Anforderungen, Features, Aktionen, Sachverhalte oder Mängel). Siewerden auch dazu genutzt, numerische Daten zu erfassen und durch einfache Operationen zu verarbeiten. Sie können die Entscheidungs-analyse erleichtern und sind sehr mächtige Instrumente, um Szenarien zu verdichten. Die Weiterverfolgung von Sachverhalten wird nur ele-mentar unterstützt. Der Austausch von Informationen ist ähnlich wie bei der Textverarbeitung.

• Werkzeuge zur Kommunikation (E-Mail und sofortige Nachrichten-übermittlung): Mit ihnen wird die Kommunikation mit Stakeholdern unterstützt, die regional weit gestreut sind, die auf Anfragen nicht direkt antworten können oder die eine Aufzeichnung einer Diskussion benötigen, die über einen längeren Zeitraum hinweg stattgefunden hat. Die Werkzeuge stehen normalerweise allen Stakeholdern zur Verfügung und sind einfach zu nutzen. Sie sind allerdings zur länger-fristigen Aufbewahrung von Informationen eher weniger geeignet. Siewerden hauptsächlich genutzt, um bei der Kommunikation zeitliche und räumliche Grenzen zu überwinden.

Basiskompetenzen Werkzeuge und Technologie

251

• Werkzeuge der Zusammenarbeit und des Wissensmanagements: Sie unterstützen die Sammlung von Wissen, das im Unternehmen an unterschiedlichen Stellen vorhanden ist und machen es einem breiten Kreis von Nutzern zugänglich. Dokumente können von einem ganzen Team eingesehen werden und erleichtern damit die Kooperation. Mehrere Anwender können damit auch gleichzeitig an einem Doku-ment arbeiten. Kommentare und Diskussionen über den Inhalt werdengefördert. Bei diesen Tools kann es sich um Datenbanken für Doku-mente handeln, die Office-Anwendungen integrieren oder um Wikis, mit denen relativ einfach Web-Seiten gestaltet und verlinkt werden können, aber auch um Diskussionsforen, Cloud Services oder andere netzbasierte Werkzeuge.

• Hardware: Sie macht die Vervielfältigung und Verteilung von Informa-tionen möglich, um so die Kommunikation mit den Stakeholdern zu erleichtern. Werkzeuge wie Drucker und digitale Projektoren werden oft genutzt, um digitale Inhalte, die auf Rechnern entstanden sind, in leicht zu nutzende, physische Informationen umzuwandeln. Foto-kopierer und Scanner vervielfältigen physische Dokumente und erlauben es, sie elektronisch auszutauschen.

.3 ErfolgsmaßstäbeZu den Merkmalen effektiver Office-Anwendungen und -Technologie gehören:

• effizientere und reibungslosere Prozesse durch das Ausprobieren und die Nutzung von Features und Funktionen von Tools

• Bewusstsein dafür, welche Tools welche Funktionen erfolgreich unter-stützen

• Urteilsfähigkeit darüber, welche Tools am besten den Stakeholdern gerecht werden

• Fähigkeit, anderen die wesentlichen Leistungsmerkmale der verfüg-baren Tools zu verdeutlichen.

Business-Analyse-Werkzeuge und -Technologie

.1 ZweckDer Business-Analyst nutzt ein breites Spektrum von Werkzeugen und Technologie,um Ergebnisse der Business-Analyse zu modellieren, zu dokumentieren und zunutzen.


252

9.6.2

.2 BeschreibungAuf die Business-Analyse spezialisierte Werkzeuge besitzen spezielle Fähigkeiten zur

• Modellierung• Erstellung von Diagrammen• Dokumentation• Analyse und Darstellung von Anforderungen• Darstellung von Beziehungen zwischen den Anforderungen• Nachverfolgung und Aufbewahrung von Anforderungs-Artefakten • Kommunikation mit Stakeholdern.

Einige Werkzeuge der Business-Analyse fokussieren ausschließlich auf eineeinzelne Aktivität, andere integrieren viele Funktionen in einem einzigen Werk-zeug. Zu den Tools, die speziell für die Business-Analyse entwickelt wurden,können Funktionen zur Modellierung, zum Management von Anforderungen,zur Nachverfolgung von Sachverhalten, zum Prototyping und zur Simulationsowie zur computerunterstützten Entwicklung von Software gehören.

Modellierungswerkzeuge stellen Funktionalitäten bereit, die den Business-Ana-lysten bei einer Vielzahl von Aufgaben unterstützen. Dazu gehören:

• Schaffung von Modellen und bildlichen Darstellungen, um die Anforderungen der Stakeholder abzustimmen und die Beziehungen von Bedarfen, Entitäten, Anforderungen, Stakeholdern und Kontexten zu verdeutlichen

• bildliche Darstellungen zu Geschäftsregeln, schriftlichen Anforderun-gen, verbalen und grafischen Aussagen über Scope, Datenanforderun-gen, Produktbedarfe und andere Informationen und Zusammenhänge

• Schaffung eines ausführungsreifen Programms, mit dem ein Modell umgesetzt oder ein Applikations-Code erstellt wird, der dann von einem Entwickler weiter verfeinert wird.

Diese Werkzeuge überprüfen häufig die Einhaltung einer bestimmten Notation.Einige Modellierungswerkzeuge unterstützen die Entwicklung ausführungsreiferModelle. Ein Business Process Management System (BPMS) ermöglicht z.B. dieUmsetzung ausführungsreifer Prozessmodelle und Managementsysteme zur Ver-waltung von Geschäftsregeln (mit deren Hilfe die erfassten Geschäftsregelnbewertet werden können).

Werkzeuge zum Anforderungsmanagement bieten Funktionalitäten, die einenBusiness-Analysten bei einer ganzen Reihe von Aufgaben zum Managementvon Anforderungen unterstützen wie zum Beispiel:

• Workflow von Anforderungen einschließlich Baselining, Stellungnah-men und Freigaben, Steuerung von Änderungen und Status bei der Umsetzung


253

• vorwärts wie auch rückwärts gerichtete Verfolgung von Anforderun-gen, Beziehungen zwischen Anforderungen und Analyse der Auswir-kungen von Anforderungsänderungen

• Konfigurationsmanagement von Anforderungen und Artefakten von Anforderungen

• Verifizierung der Qualität von Anforderungen, indem definierte Merk-male und Beziehungen überprüft werden.

Werkzeuge zur Weiterverfolgung von Sachverhalten können den Business-Ana-lysten mit einer Reihe von Funktionen unterstützen wie zum Beispiel:

• Verfolgung von Risiken, die mit Anforderungen verbunden sind• Verfolgung von mit Anforderungen verbundenen Konflikten und sonstigen Sachverhalten

• Weiterverfolgung von Fehlern.

Werkzeuge zum Bau von Prototypen und zur Simulation können den Business-Analysten ebenfalls bei seiner Arbeit unterstützen.

.3 ErfolgsmaßstäbeZu den Merkmalen effektiver Werkzeuge und Technologien der Business-Analysegehören:

• die Fähigkeit, ein Tool und andere ähnliche Tools sinnvoll zu nutzen• die Fähigkeit, die wichtigsten, gegenwärtig verfügbaren Werkzeuge und ihre Stärken und Schwächen sowie deren Anwendungsbedingun-gen in einer konkreten Situation zu kennen

• die Fähigkeit, die wesentlichen Features eines Werkzeugs zu verstehenund zu nutzen

• die Fähigkeit, ein Werkzeug auszuwählen, das die betrieblichen Pro-zesse unterstützt

• die Fähigkeit, durch die Nutzung eines Tools die mit Anforderungen verbundenen Aufgaben schneller als sonst möglich zu erledigen

• die Fähigkeit, Änderungen an den Anforderungen zu verfolgen und deren Auswirkungen auf die Einführung, die Stakeholder und den Nutzen einzuschätzen.

Kommunikationswerkzeuge und -Technologie

.1 ZweckDer Business-Analyst nutzt Kommunikationswerkzeuge und -Technologie umeine Business-Analyse durchzuführen, Teams zu managen und mit Stakeholdernzusammenzuarbeiten.


254

9.6.3

.2 BeschreibungKommunikationswerkzeuge werden genutzt, um Aufgaben, die mit dem Aus-tausch von Informationen und mit der Zusammenarbeit verbunden sind, zuplanen und umzusetzen. So wird eine Zusammenarbeit sowohl mit virtuellenTeams als auch mit Mitarbeitern vor Ort möglich.

Ist klar, welche Optionen diese Werkzeuge bereithalten – und ist man in derLage, die verschiedenen Kommunikationswerkzeuge bei der Aufgabenerfüllungin unterschiedlichen Arbeitsumfeldern zu nutzen – werden eine effizientere undkorrektere Kommunikation und eine wirkungsvollere Entscheidungsfindung mög-lich. Der Business-Analyst wählt das geeignete Werkzeug aus, abgestimmt aufdie jeweilige Situation und die Gruppe der Stakeholder, unter Beachtung vonKosten, Risiko und Nutzen.

Beispiele für solche Werkzeuge sind Tools zur Sprachkommunikation, zur sofor-tigen Nachrichtenübermittlung, zum Online Chat, zum Bloggen, zu Micro Blog-ging und E-Mails.

Beispiele für Tools zur Zusammenarbeit sind Videokonferenzen, elektronischeWhiteboards, Wikis, elektronische Kalender, Werkzeuge zum Online Brainstor-ming, elektronische Entscheidungsfindung, elektronische Abstimmungen, gemein-same Nutzung von Dokumenten und Austausch von Ideen.

.3 ErfolgsmaßstäbeZu den Merkmalen effektiver Kommunikationswerkzeuge und -Technologiegehören:

• eine auf die Zuhörerschaft und den jeweiligen Zweck abgestimmte Auswahl effektiver Werkzeuge

• sinnvolle Entscheidungen, wann Kommunikationstechnik genutzt wirdund wann nicht

• Fähigkeit, Werkzeuge zu identifizieren, die den Kommunikations-anforderungen entsprechen

• Features eines Werkzeugs verstehen und nutzen.


255

257

Das Kapitel „Techniken“ bietet eine allgemeine Übersicht über die Instrumente,auf die in den verschiedenen Wissensgebieten des BABOK®-Leitfadens hinge-wiesen wird und die bei der Business-Analyse genutzt werden können.

Die hier aufgeführten Techniken sind nur eine Teilmenge der vom Business-Ana-lysten verwendeten Instrumente. Hier sollen die in der Community der Busi-ness-Analyse bekanntesten und am weitesten verbreiteten Techniken dargestelltwerden. Der Business-Analyst nutzt seine Erfahrung und sein Urteilsvermögen,um zu bestimmen, welche Techniken in einer bestimmten Situation besondersgeeignet sind und wie sie eingesetzt werden können. Es können durchaus auchTechniken eingesetzt werden, die sich nicht in diesem BABOK®-Leitfaden wie-derfinden. Mit der Weiterentwicklung der Business-Analyse werden in späterenAuflagen des BABOK®-Leitfadens Techniken hinzugefügt, vorhandene Technikenverändert oder auch eliminiert, falls das sinnvoll sein sollte.

In einigen Fällen wurden konzeptionell ähnliche Techniken in einem Abschnittzusammengefasst. Jedes Instrument kann einzeln oder kombiniert mit anderengenutzt werden, wenn so die Ziele besser erreicht werden können.

Akzeptanz- und Bewertungskriterien

Zweck

Akzeptanzkriterien werden dazu benutzt, um die Anforderungen, Ergebnisseoder Bedingungen zu bestimmen, die erfüllt sein müssen, damit eine Lösungfür die wichtigsten Stakeholder akzeptabel ist. Bewertungskriterien sind Maßstäbe,die dazu verwendet werden, um zwischen verschiedenen Lösungsvarianten Aus-wahlentscheidungen fällen zu können.

Techniken

10.1

10.1.1

10

Beschreibung

Akzeptanz- und Bewertungskriterien legen die Maßstäbe fest, mit deren HilfeLösungen und Design-Alternativen bewertet und verglichen werden. Messbareund nachprüfbare Kriterien ermöglichen eine objektive und konsistente Beurtei-lung von Lösungen und Designs. Akzeptanz- und Bewertungskriterien könnenauf allen Ebenen eines Projektes vom Groben zum Detail verwendet werden.Akzeptanzkriterien beschreiben Mindestanforderungen, die erfüllt sein müssen,damit es sich überhaupt lohnt, eine Lösung einzuführen. Sie können dazu ver-wendet werden, um zu bestimmen, ob eine Lösung oder eine Lösungskompo-nente eine Anforderung erfüllt. Akzeptanzkriterien werden typischerweise immerdann verwendet, wenn nur eine Lösung bewertet wird, um herauszufinden, obsie gewählt wird oder nicht.

Bewertungskriterien bilden einen Satz von Maßstäben, die es möglich machen,Lösungen oder alternative Entwürfe entsprechend ihrem Wert für die Stakeholderin eine Rangordnung zu bringen. Jedes Bewertungskriterium präsentiert einenMaßstab, mit dem spezielle Lösungseigenschaften wie Kosten, Performance,Anwenderfreundlichkeit oder die Erfüllung gewünschter Funktionalität aus derSicht des Bedarfs der Stakeholder beurteilt werden. Eigenschaften, die nichtdirekt gemessen werden können, können mithilfe von Expertenbeurteilungenoder Scoring-Techniken bewertet werden.

Bewertungs- und Akzeptanzkriterien können die gleichen Attribute nutzen.Wenn unterschiedliche Lösungsmöglichkeiten bewertet werden, dürften Ansätzemit niedrigeren Kosten und höherer Performance besser eingestuft werden.Damit eine Lösung akzeptiert werden kann, muss sie die Mindest-Leistungsan-forderungen ebenso erfüllen wie sie die Obergrenzen der Kosten einhaltenmuss, die sich aus vertraglichen Vereinbarungen oder aus einem Akzeptanztestder Anwender ergeben.

Elemente

.1 WertattributeWertattribute sind Eigenschaften einer Lösung, die maßgeblich den Nutzen fürdie Stakeholder bestimmen oder beeinflussen. Sie stellen eine bedeutsame undallgemein akzeptierte Aufgliederung des Nutzenversprechens in seine einzelnenBestandteile dar, die letztlich die Eigenschaften beinhaltet, die eine Lösung ent-weder besitzen oder vermeiden sollte.

Zu solchen Wertattributen gehören beispielsweise:• Fähigkeit, bestimmte Informationen zu liefern• Fähigkeit, bestimmte Aktivitäten zu erledigen oder zu unterstützen

• Performance und Antwortzeitverhalten

258

TechnikenAkzeptanz- und Bewertungskriterien

10.1.2

10.1.3

• Anwendbarkeit der Lösung in speziellen Situationen und Kontexten• Verfügbarkeit spezieller Features und Fähigkeiten• Nutzbarkeit, Sicherheit, Skalierbarkeit und Zuverlässigkeit.

Werden die Akzeptanz- und Bewertungskriterien aus Wertattributen abgeleitet,so kann damit sichergestellt werden, dass sie zu Recht bestehen und für denBedarf der Stakeholder relevant sind und deswegen bei der Bewertung undAkzeptanz einer Lösung beachtet werden sollten. Der Business-Analyst stelltsicher, dass die Bestimmung der Wertattribute von allen Stakeholdern mitgetragenwird. Der Business-Analyst kann Werkzeuge und Vorgaben für Bestätigung,Aufzeichnung und Weiterverarbeitung der Ergebnisse entwerfen.

Abb.10.1.1: Akzeptanz- und Bewertungskriterien

.2 BeurteilungDamit Lösungen anhand der Akzeptanz- und Bewertungskriterien beurteilt werdenkönnen, müssen die Kriterien operationalisiert (messbar gemacht) werden.

Techniken Akzeptanz- und Bewertungskriterien

259

Eine Lösung

Akzeptanz-kriterien

Festlegung derAnforderungen

Test

Wertattribute:• Kosten• Performance• Nutzbarkeit• Funktionalität

Anforderungen,die erfüllt seinmüssen, damiteine Lösung inBetracht kommt.

Durchführungdes Anwender-Akzeptanztests

Anforderungenerfüllt oder nicht

Mehrere Lösungen

Bewertungs-kriterien

Festlegung der Be-urteilungskriterien

Beurteilen

Wertattribute:• Kosten• Performance• Nutzbarkeit• Funktionalität

Kriterien, diedazu dienen, denWert zu ermitteln,den möglicheLösungen bieten.

Lösungen Rangordnungder Lösungen

Testbarkeit

Akzeptanzkriterien werden in einer testbaren Form ausgedrückt. Dazu kann esnotwendig sein, die Anforderungen in sehr kleine Elemente zu zerlegen, sodassTestfälle geschrieben werden können, um die Lösung anhand der Kriterien zuüberprüfen. Akzeptanzkriterien werden in einer Form dargestellt, die als erfülltoder nicht erfüllt beurteilt werden kann. Dazu werden oft Anwender-Akzep-tanztests durchgeführt.

Maßstäbe

Bewertungsmaßstäbe dienen dazu, zu bestimmen, ob Lösungselemente denBedarf der Stakeholder abdecken und ihnen Nutzen bieten. Diese Kriterienwerden entweder als stetige Merkmale (zum Beispiel Zeit, Kosten, Menge) oderals diskrete Merkmale (zum Beispiel „erfüllt“ oder „nicht erfüllt“) ausgestaltet.Die Festlegung dieser Kriterien macht es möglich, eine Lösung durch unter-schiedlichste Methoden wie zum Beispiel Benchmarking oder Expertenbeurteilungzu bewerten. Zur Ermittlung der Bewertungskriterien, zur Bewertung selbst undzur Weiterverarbeitung und Aufbewahrung können Entwurfswerkzeuge undRegeln genutzt werden.

Bewertung

.1 Stärken• Agile Methoden können es erforderlich machen, dass die Anforderungen in der Form testbarer Akzeptanzkriterien vorliegen.

• Akzeptanzkriterien sind notwendig, wenn die Anforderungen vertraglicheVerpflichtungen beinhalten.

• Akzeptanzkriterien bieten die Möglichkeit, Anforderungen anhand akzep-tierter Kriterien zu überprüfen.

• Bewertungskriterien bieten die Möglichkeit, verschiedene Bedarfe anhandakzeptierter Kriterien zu beurteilen, wie zum Beispiel Lösungsmerkmale, lokale oder globale Benchmarks, allgemeine Maßstäbe oder vereinbarte Kennzahlen.

• Bewertungskriterien tragen dazu bei, dass der erwartete Return on Invest-ment (RoI) oder andere spezifizierte Werte erreicht werden.

• Bewertungskriterien helfen bei der Festlegung von Prioritäten.

.2 Grenzen• Akzeptanzkriterien können vertragliche Verpflichtungen darstellen und als solche aus rechtlichen oder politischen Gründen kaum verändert werden.

TechnikenAkzeptanz- und Bewertungskriterien

260

10.1.4

• Bei der Bewertung von Kriterien für verschiedene Bedarfe unterschiedlicher Stakeholder kann es eine echte Herausforderung sein, gemeinsamen getra-gene Maßstäbe zu vereinbaren.

Backlog Management

Zweck

Der Backlog dient der Aufzeichnung, Verfolgung und Priorisierung unerledigterAufträge (Auftragsbestand).

Beschreibung

Ein Auftragsbestand entsteht immer dann, wenn der Umfang der zu erledigendenAufträge größer ist als die verfügbaren Kapazitäten.

Backlog Management beinhaltet ein planvolles Vorgehen, um festzulegen,• was formal zum Auftragsbestand gehört• wie diese Aufträge zu beschreiben sind• wie diese ausstehende Arbeit weiterverfolgt werden soll• wie die Rückstände periodisch überprüft und in Relation zu anderen Elementen des Backlog priorisiert werden

• wie einzelne Elemente ausgewählt und bearbeitet werden• wie diese Aufträge schließlich aus dem Auftragsbestand eliminiert werden.

In einem planmäßig geführten Auftragsbestand stehen diejenigen Elemente ander Spitze der Liste, die mit der höchsten Bearbeitungspriorität versehen sind.Sie werden normalerweise als nächste Aufträge ausgewählt.

Der gesamte Auftragsbestand sollte periodisch überprüft werden, da sich beiden Bedarfen der Stakeholder veränderte Prioritäten ergeben können. In vielenUnternehmen wird der Auftragsbestand in festen Intervallen überprüft.

Veränderungen des Backlogs werden regelmäßig überprüft; die wesentlichenGründe für Veränderungen werden untersucht: Ein wachsender Auftragsbestandkönnte Hinweise auf eine steigende Nachfrage oder auch auf einen Rückgang derProduktivität geben; ein rückläufiger Auftragsrückstand könnte auf einen Rückgangder Nachfrage hinweisen oder auf Fortschritte im Prozess der Umsetzung.

Es kann auch mehr als einen Backlog geben: einen beispielsweise für die umfang-reichen, langfristig beabsichtigten Vorhaben insgesamt und einen zweiten, mitdem die kurzfristig zu erledigenden Aufträge verwaltet werden.

Techniken Backlog Management

261

10.2

10.2.1

10.2.2

Elemente

.1 SachverhalteZu einem Auftragsbestand kann alles Mögliche gehören, das erledigt werdenmuss. Ein Backlog kann beispielsweise folgende Sachverhalte fassen:• Use Cases • User Stories• Funktionale Anforderungen • Nicht-funktionale Anforderungen• Designs • Kundenaufträge• Risiken • Änderungsaufträge• Störungen • Planmäßige Überarbeitung• Maintenance/Wartung • Durchführung einer Präsentation • Vervollständigung eines Dokumentes.

Ein Vorhaben wird dem Auftragsbestand hinzugefügt, wenn es einen Wert füreinen Stakeholder bieten kann. Es kann sein, dass einzelne Personen befugtsind, neue Aufträge zum Auftragsbestand hinzuzufügen oder es gibt ein Gre-mium, das gemeinsam beschließt, weitere Aufträge hinzuzufügen. In einigenFällen kann es auch sein, dass die Verantwortung an den Business-Analystendelegiert wird. Es kann Richtlinien und Regeln geben, in denen festgelegt wird,was wann aufgenommen wird, etwa wenn wichtige Produktmängel auftreten.

.2 PriorisierungDie Inhalte des Auftragsbestands werden ihrer relativen Bedeutung gemäß prio-risiert. Im Zeitablauf können sich die Prioritäten ändern, wenn es neue Einschät-zungen der Stakeholder gibt, oder wenn neue Abhängigkeiten zwischen einzelnenBestandteilen des Auftragsbestands entstehen. Prioritäten können sich auch ausden Regeln für das Management des Backlog ergeben.

Zur Priorisierung kann auch ein mehrstufiges Vorgehen gewählt werden. Wennneue Sachverhalte hinzugefügt werden, kann die Priorisierung erst eher allgemeinerNatur sein (zum Beispiel: hoch, mittel oder niedrig). Sachverhalte mit hoher Prioritätwerden normalerweise relativ häufig überprüft, da sie Kandidaten für die nächstenAufträge sein dürften. Um die hoch bewerteten Sachverhalte zu priorisieren, kannein wesentlich feineres Instrumentarium verwendet werden wie zum Beispiel einequantifizierte Rangfolge auf der Basis des erwarteten Nutzens.

.3 EinschätzungEinzelne Elemente des Auftragsrückstands können unterschiedlich detailliertbeschrieben werden. Sachverhalte, die an der Spitze des Auftragsrückstandsstehen, werden normalerweise sehr viel detaillierter beschrieben, mit einer relativgenauen Einschätzung über deren Größe und Komplexität, um so besser die

TechnikenBacklog Management

262

10.2.3

Kosten und den Aufwand für die Erledigung abzuschätzen. Neu hinzugefügteSachverhalte, die vermutlich nicht in nächster Zeit bearbeitet werden, werdeneher global beschrieben.

Auf Sachverhalte im Auftragsbestand wird normalerweise relativ wenig Arbeitverwendet, hier geht es lediglich darum, zu verstehen, wie viel Aufwand für dieErledigung voraussichtlich notwendig sein wird. Mit der Bearbeitung andererAufträge können sich die Prioritäten im Bestand verändern, was dann dazuführen kann, dass Größe und Komplexität eines einzelnen Vorhabens genauerabgeschätzt werden.

Feedback aus bereits abgewickelten Aufträgen kann helfen, Kosten und Zeit-aufwand unerledigter Aufträge präziser einzuschätzen.

.4 Veränderungen im AuftragsbestandOffene Aufträge können in der Priorisierung aufrücken, wenn sich die relativePriorität zu ihren Gunsten entwickelt. Wenn neue oder andere Anforderungenfestgestellt werden, werden sie zu dem Auftragsbestand hinzugefügt und ihrerrelativen Bedeutung entsprechend eingeordnet.

Sobald Kapazitäten frei werden, wird der Rückstand überprüft. Aufträge werdendann zum Beispiel unter Berücksichtigung des geschätzten Aufwands und dererwarteten Komplexität, unter Beachtung der verfügbaren Kapazitäten ausge-wählt.

Sachverhalte werden aus dem Auftragsrückstand entfernt, wenn sie erledigtsind oder wenn eine Entscheidung gefällt wurde, sie nicht zu bearbeiten.Entfernte Aufträge können jedoch jederzeit wieder aufgenommen werden,wenn zum Beispiel• die Stakeholder deutlich veränderte Bedarfe haben• andere hoch priorisierte Aufträge mehr Zeit brauchen als erwartet• fertiggestellte Aufträge Fehler aufweisen.

Bewertung

.1 Stärken• Backlog Management ist ein effizientes und effektives Vorgehen, um auf veränderte Anforderungen der Stakeholder und auf neue Prioritäten zu reagieren.

• Nur Sachverhalte an der Spitze des Auftragsbestands werden detailliert bearbeitet, niedriger eingeordnete Vorhaben bedeuten niedrigere Priori-täten. Für sie wird weniger Aufwand betrieben.

• Backlog Management ist ein hilfreiches Instrument für die Kommunika-tion, da die Stakeholder so besser verstehen können, an welchem Sach-

Techniken Backlog Management

263

10.2.4

verhalt zukünftig gearbeitet wird, welche nachrangig sind und welche vorläufig gar nicht bearbeitet werden.

.2 Grenzen• Es kann schwierig sein, umfangreiche Auftragsbestände zu managen. • Erfahrung ist unerlässlich, um Aufträge zu zergliedern und deren voraus-sichtlichen Zeitaufwand abzuschätzen.

• Mangelnde Detaillierung bei Elementen des Auftragsbestands kann dazu führen, dass eigentlich relevante Informationen verloren gehen.

Balanced Scorecard

Zweck

Mit Hilfe der Balanced Scorecard kann jedes beliebige Geschäftsmodell, jedeOrganisationsstruktur und jeder Geschäftsprozess ergebnisorientiert gesteuertwerden.

Beschreibung

Die Balanced Scorecard ist ein strategisches Planungs- und Steuerungsinstrument,das dazu dient, die Leistung von Unternehmen jenseits rein finanzieller Maßstäbezu messen. Es ist am Ergebnis orientiert und bietet einen abgewogenen Blickauf ein Unternehmen. Es stellt den Strategieentwurf in der Form eines aktivenRasters aus Zielen und Erfolgsmaßstäben dar. Dem liegt die Annahme zu Grunde,dass die Treiber der Wertschöpfung bekannt sind, gemessen und optimiert wer-den, mit dem Ziel, nachhaltig die Leistung zu erreichen.

Die Balanced Scorecard setzt sich aus vier Dimensionen zusammen:• Lernen und Entwicklung • Geschäftsprozess• Kunde• Finanzen.

Die Balanced Scorecard beinhaltet messbare Ziele, klare Beurteilungsmaßstäbeund Zielvorgaben, die aus der Vision und der Strategie eines Unternehmensabgeleitet werden. Balanced Scorecards können auf unterschiedlichen Ebeneneines Unternehmens eingesetzt werden. So gibt es eine unternehmensweiteScorecard ebenso wie auch Scorecards für Unternehmensbereiche oder auchfür einzelne Projekte und Vorhaben.

TechnikenBalanced Scorecard

264

10.3

10.3.1

10.3.2

Abb. 10.3.1: Balanced Scorecard

Elemente

.1 Lernen und EntwicklungDiese Dimension umfasst Maßnahmen der Aus- und Weiterbildung von Mitar-beitern, der Innovation von Produkten und Leistungen sowie der Weiterent-wicklung der Unternehmenskultur. Messgrößen können die Ausgaben für Aus-und Weiterbildung sein, der Einsatz von Mentoren, der Austausch von Wissensowie technologische Verbesserungen.

.2 GeschäftsprozessZu dieser Dimension gehören Kennzahlen, die darüber Auskunft geben, wie gut dasUnternehmen arbeitet und ob die Produkte dem Bedarf der Kunden entsprechen.

Techniken Balanced Scorecard

265

Wie sollten wir gegenüber unserenShareholdern auftreten, wenn wirfinanziell erfolgreich sein wollen?

Visionund

Strategie

Kunde

• Ziele• Kennzahlen• Initiativen

Finanzen

• Ziele• Kennzahlen• Initiativen

Lernen undEntwicklung• Ziele• Kennzahlen• Initiativen

InterneGeschäftsprozesse• Ziele• Kennzahlen• Initiativen

Bei welchen Geschäfts-prozessen müssen wirbesonders gut sein,wenn wir die Kundenund die Shareholder zu-friedenstellen wollen?

Wie können wir unsere Fähigkeit zurAnpassung und Verbesserung bewahren,

um so unsere Ziele zu erreichen?

Wie sollten wir gegen-über unseren Kundenauftreten, wenn wirunsere Vision erreichenwollen?

10.3.3

.3 KundeZu dieser Dimension gehören die Fokussierung auf die Kunden, die Zufriedenheitder Kunden mit den Produkten und Leistungen sowie auf die gelieferte Qualitätund die Erfahrungen, die die Kunden insgesamt mit dem Unternehmen gemachthaben.

.4 FinanzenDiese Dimension deckt alles ab, was finanziell notwendig ist, um die Strategieumzusetzen. Beispiele für finanzielle Kennzahlen können Rentabilität, Umsatz-wachstum oder zusätzlich geschaffene Werte sein.

.5 Messgrößen oder IndikatorenEs gibt zwei Arten von Messgrößen oder Indikatoren: Ergebniswerte (zum Beispielerzielter Umsatz oder Gewinn) oder steuernde Werte, die maßgeblich die Ergeb-nisse beeinflussen (zum Beispiel Anzahl Vertriebsmitarbeiter oder Werbeaufwand).Die Ergebniswerte zeigen lediglich auf, welche Folgen frühere Maßnahmengehabt haben, sie hinken damit immer hinter der Realität her, wohingegen steu-ernde Werte Informationen über die mögliche zukünftige Entwicklung bietenund damit einen aktuelleren Bezug haben.

Bewertung

Wenn Messgrößen ihren Sinn erfüllen sollen, sollten sie quantifizierbar sein, ausder Strategie abgeleitet werden und von allen Stakeholdern leicht zu verstehensein. Werden Maßgrößen neu entwickelt, sollten dabei bereits bestehendeGrößen berücksichtigt werden, um mögliche kontraproduktive Effekte zu ver-meiden. Alle Dimensionen einer Balanced Scorecard können sich laufend verän-dern oder angepasst werden. Jede Dimension hat Auswirkungen auf die übrigen.Eine Balanced Scorecard erlaubt es einem Unternehmen, ein System der Steuerungund Überwachung zu etablieren, um Fortschritte bei der Zielerreichung zu erken-nen und gegebenenfalls auch die Strategie anzupassen.

Da Scorecards zur Leistungsmessung verwendet werden, ist es besonders wichtig,Veränderungen der Messgrößen offen und eindeutig zu kommunizieren.

.1 Stärken• Balanced Scorecards erleichtern eine ganzheitliche und abgewogene Planung und ein ganzheitliches Denken.

• Kurz-, mittel- und langfristige Ziele können zu Programmen verschmolzenwerden, bei denen der Fortschritt inkrementeller Veränderungen gemes-sen wird.

TechnikenBalanced Scorecard

266

10.3.4

• Strategische, taktische und operative Teams können leichter aufeinander abgestimmt werden.

• Zukunftsorientiertes Denken und Wettbewerbsfähigkeit werden gefördert.

.2 Grenzen• Eine klare Strategie ist zwingende Voraussetzung für den Einsatz der Balanced Scorecard.

• Die Balanced Scorecard kann irrtümlich als das einzige Instrument für die strategische Planung angesehen werden, stellt jedoch lediglich ein Element in einer ganzen Reihe von Werkzeugen zur strategischen Planung dar.

• Die Balanced Scorecard kann irrtümlich als Ersatz für die Planung, Umsetzung und Messung der Strategie angesehen werden.

Benchmarking und Marktanalyse

Zweck

Benchmarking und Marktanalysen werden durchgeführt, um betriebliche Akti-vitäten zu verbessern sowie die Kundenzufriedenheit und auch den Wert fürStakeholder zu steigern.

Beschreibung

Benchmark-Studien werden durchgeführt, um betriebliche Praktiken mit denenzu vergleichen, die als die Besten gelten. Best Practices können bei Mitbewerbern,bei Regierungsstellen oder bei Unternehmensverbänden gefunden werden. DasBenchmarking zielt darauf ab, die Leistung des eigenen Unternehmens zu bewer-ten und sicherzustellen, dass es effizient arbeitet. Benchmarking kann auch imHinblick auf bestehende Compliance-Regeln durchgeführt werden. Die Ergebnisseeiner Benchmark-Studie lösen häufig Veränderungsprozesse aus.

Bei einer Marktanalyse wird untersucht, ob die Produkte und Leistungen demBedarf oder den Wünschen der Kunden entsprechen, welche Ursachen Kauf-entscheidungen zugrunde liegen und welche Mitbewerber im Markt tätig sind.Mit einer Marktanalyse sollen Informationen gewonnen und in den unterschied-lichsten Entscheidungsprozessen eines Unternehmens genutzt werden. Markt-analysen können auch Hinweise darauf geben, wann es besser ist, aus einemMarkt auszusteigen. Schließlich können sie genutzt werden, wenn es darumgeht, Partner zu finden oder Unternehmen zu verschmelzen.

Techniken Benchmarking und Marktanalyse

267

10.4

10.4.1

10.4.2

Elemente

.1 Benchmarking Zum Benchmarking gehören: • Abgrenzung des Untersuchungsbereichs• Identifikation der Unternehmen, die als führend angesehen werden (einschließlich Mitbewerber)

• Untersuchung der ausgewählten Unternehmen, um deren Praktiken zuverstehen

• Nutzung einer Informationsanfrage, um die Kompetenzen der Unter-nehmen mit Best Practices zu ermitteln

• Vereinbarung von Besuchen in diesen Unternehmen• Ermittlung der Differenzen zwischen den gegenwärtigen Leistungen und den Best Practices

• Entwurf eines Projektvorschlags zur Umsetzung der Best Practices.

.2 MarktanalysenMarktanalysen setzen voraus, dass der Business-Analyst • die Kunden identifiziert und deren Präferenzen versteht• Möglichkeiten herausfiltert, die Werte für die Kunden steigern• Mitbewerber ermittelt und deren Aktivitäten untersucht• Markttrends untersucht, Wachstumsraten prognostiziert und die mögliche Profitabilität einschätzt

• angemessene Unternehmensstrategien entwickelt• Marktdaten sammelt• vorhandene Ressourcen, wie z. B. betriebliche Aufzeichnungen, Forschungsergebnisse und Bücher nutzt, und diese Information für die jeweilige Fragestellung einsetzt

• diese Daten überprüft, um daraus Trends abzuleiten und Schluss-folgerungen zu ziehen.

Bewertung

.1 Stärken• Benchmarking stellt Unternehmen Informationen über neue und abwei-chende Verfahren, Ideen und Werkzeuge zur Verfügung, die helfen können, die betriebliche Performance zu steigern.

• Ein Unternehmen kann das Benchmarking nutzen, um Best Practices der Mitbewerber zu ermitteln und deren Wettbewerbsvorteile auszugleichen oder sie zu übertreffen.

TechnikenBenchmarking und Marktanalyse

268

10.4.3

10.4.4

• Benchmarking zeigt auf, warum vergleichbare Unternehmen erfolgreich sind und welche Prozesse sie nutzen, um erfolgreich zu sein.

• Mit der Marktanalyse können spezifische Zielgruppen angesprochen werden, um ausgewählte Fragen zu beantworten.

• Eine Marktanalyse kann spezifische Schwächen eines Unternehmens oder einer Branche deutlich machen.

• Marktanalysen können Wettbewerbsvorteile von Mitbewerbern deutlich machen, die sie durch bessere Angebote von Produkten oder Services erreicht haben.

.2 Grenzen• Benchmarking ist ein zeitaufwändiges Verfahren. Möglicherweise ist ein Unternehmen nicht ausreichend qualifiziert, um eine Analyse durchzu-führen und die gewonnenen Informationen zu nutzen.

• Benchmarking kann keine innovativen Lösungen hervorbringen oder Lösungen, die einen nachhaltigen Wettbewerbsvorteil bieten, da diese Lösung an anderer Stelle bereits verfügbar sind und lediglich nachgeahmt werden.

• Marktanalysen können zeitaufwändig und teuer sein und Ergebnisse erst zeitlich verzögert bereitstellen.

• Ohne eine Marktsegmentierung dürften Marktanalysen nicht die erwarteten Ergebnisse bringen oder sogar fehlerhafte Daten über die Produkte oder Services der Mitbewerber liefern.

Brainstorming

Zweck

Brainstorming ist ein geeignetes Verfahren zur Förderung des kreativen Denkensbei der Lösung von Problemen. Mit einem Brainstorming sollen möglichst vieleneue Ideen produziert werden, die anschließend vertieft untersucht werdenkönnen.

Beschreibung

Brainstorming ist eine Technik zur Gewinnung möglichst vieler unterschiedlicherLösungsoptionen.

Damit können unter anderem folgende Fragen beantwortet werden:

• Welche Optionen haben wir für eine gegebene Problemstellung?

Techniken Brainstorming

269

10.5

10.5.2

10.5.1

• Was hindert eine Gruppe daran, eine Lösung oder einen Ansatz voranzutreiben?

• Was könnte eine Verzögerung in der Aktivität „A“ verursacht haben?• Was könnte die Gruppe tun, um das Problem „B“ zu lösen?

Brainstorming ist deswegen so wirkungsvoll, weil auf eine Fragestellung oderein Problem fokussiert wird und dafür möglichst viele denkbare Lösungen erar-beitet werden. Diese Technik funktioniert am besten in einer Gruppe, da sie dieErfahrungen und die Kreativität aller Gruppenmitglieder abruft. Auch eineeinzelne Person kann diese Technik nutzen. Um die Kreativität zu fördern, werdendie Teilnehmer ermutigt, aus neuen Perspektiven auf Sachverhalte zu schauenund in jede beliebige Richtung frei zu assoziieren. Wird eine Sitzung gut moderiert,kann Brainstorming produktiv, motivierend und lustig sein.

Abb. 10.5.1: Brainstorming

TechnikenBrainstorming

270

Untersuchungs-bereich abgrenzen

1. Vorbereitung

2. Durchführung

3. Auswertung

Zeitraumfestlegen

Teilnehmerermitteln

Bewertungskriterienfestlegen

Austausch vonIdeen

Dokumentationder Ideen

Weiterführen vonIdeen

Sammlung möglichstvieler Ideen

Diskussion undBewertung

Auflistung Einstufung derIdeen

Verteilung derErgebnisliste

Elemente

.1 Vorbereitung• Entwicklung einer klaren und schlüssigen Beschreibung der anstehenden Fragestellung.

• Festlegung eines zeitlichen Rahmens für die Ideensammlung. Je größer die Gruppe, desto mehr Zeit wird benötigt.

• Bestimmung des Moderators und der Teilnehmer (empfehlenswert sind sechs bis acht Teilnehmer mit einem angemessenen Erfahrungshintergrundhinsichtlich des Themas).

• Abklärung der Erwartungen der Teilnehmer und deren Motivation für den Prozess.

• Erarbeitung von Kriterien für die Bewertung und Einstufung der Ideen.

.2 Durchführung• Sammlung neuer Ideen ohne Diskussion, Kritik oder Bewertung.• Visualisierung aller Ideen.• Ermutigung der Teilnehmer, kreativ zu sein, ausgefallene Ideen zu äußern und auf den Ideen anderer aufzubauen.

• Sammlung möglichst vieler Ideen, ohne vorher eine quantitative Grenze zu setzen.

.3 Auswertung• Nachdem das Zeitlimit erreicht ist, werden die gesammelten Ideen anhandder vorher festgelegten Kriterien diskutiert und bewertet.

• In verdichteten Listen werden die Ergebnisse festgehalten, zusammengehö-rige Ideen werden zusammengeführt und Mehrfachnennungen eliminiert.

• Die Ideen werden in eine Rangfolge gebracht und an die betroffenen Stellen weitergeleitet.

Bewertung

.1 Stärken• Im Brainstorming werden viele Ideen in kurzer Zeit gesammelt.• Eine wertneutrale Umgebung fördert das kreative Denken.• Brainstorming kann auch in Workshops genutzt werden, um Spannungen zwischen Teilnehmern abzubauen.

Techniken Brainstorming

271

10.5.3

10.5.4

.2 Grenzen• Die Beteiligung hängt ab von der individuellen Kreativität und der Bereit-schaft, sich einzubringen.

• Politische Positionen und organisatorische Gegebenheiten können die Beteiligung beeinflussen.

• Die Beteiligten müssen die Regel beachten, dass während der Sammlung keine Bewertung vorgenommen wird.

Betriebliche Fähigkeitsanalyse

Zweck

Die betriebliche Fähigkeitsanalyse bietet einen Rahmen für die Planung undAbgrenzung von Vorhaben. Sie schafft ein gemeinsames Verständnis über stra-tegiekonforme Ergebnisse und bietet einen Filter für die Priorisierung und denScope von Vorhaben.

Beschreibung

Die betriebliche Fähigkeitsanalyse beschreibt, was ein Unternehmen oder ein Teileines Unternehmens zu tun in der Lage ist. Betriebliche Fähigkeiten determinierendie Möglichkeiten eines Unternehmens zu handeln oder etwas weiterzuentwickeln,um damit betriebliche Ziele zu erreichen. Fähigkeiten können im Hinblick auf dieLeistungen und die damit verbundenen Risiken bewertet werden, um so spezifischeLücken zu ermitteln und Investitionen zu priorisieren. Viele Produktentwicklungendienen dazu, eine bestehende Fähigkeit zu verbessern oder eine neue zu schaffen.Solange ein Unternehmen einander ähnliche Funktionen wahrnimmt, bleibenauch die erforderlichen Fähigkeiten gleich – selbst wenn sich die Art der Durch-führung für diese Fähigkeiten signifikant verändert.

Elemente

.1 FähigkeitenFähigkeiten begründen die Möglichkeiten eines Unternehmens, eine Leistungzu erbringen oder etwas zu verändern, was letztlich dazu beiträgt, die Unter-nehmensziele zu erreichen. Fähigkeiten beschreiben den Zweck oder das Ergebniseiner Leistung oder Transformation, nicht jedoch wie diese Leistung oder diesesErgebnis erbracht wird. Die Fähigkeit wird nur einmal in einer Fähigkeitskartedargestellt, selbst wenn sie in mehreren Geschäftseinheiten verfügbar ist.

TechnikenBetriebliche Fähigkeitsanalyse

272

10.6

10.6.1

10.6.2

10.6.3

.2 Nutzung der FähigkeitenFähigkeiten stellen einen Wert dar, indem sie Umsätze fördern oder bewahren,Kosten reduzieren oder verhindern, einen Service verbessern, dazu beitragen,die Compliance einzuhalten, oder das Unternehmen zukunftsfest zu machen.Nicht alle Fähigkeiten haben den gleichen Wert. Es gibt verschiedene Werkzeuge,mit denen der Wert sichtbar gemacht werden kann.

3 Performance-ErwartungenFähigkeiten können bewertet werden um Performance-Erwartungen zu ermitteln.Wenn eine Fähigkeit verbessert werden soll, liegt dem normalerweise eine Per-formance-Lücke zugrunde. Die Performance-Lücke ist der Unterschied zwischender gegenwärtigen Leistung und dem strategisch gewünschten Ergebnis.

.4 RisikomodellFähigkeiten selbst besitzen kein Risiko, Risiken ergeben sich vielmehr aus derPerformance der Fähigkeit.

Diese Risiken fallen in die üblichen Kategorien:• Betriebliches Risiko• Technologisches Risiko• Unternehmerisches Risiko• Marktrisiko.

.5 Strategische PlanungGegenwärtige und zukünftige betriebliche Fähigkeiten können bei der Entschei-dung helfen, welchen Weg ein Unternehmen aus strategischer Sicht einschlagensoll. Ein Assessment der betrieblichen Fähigkeiten kann entsprechende Empfeh-lungen oder Vorschläge erleichtern. Diese Informationen können als Basis füreine Produkt-Roadmap oder als Leitfaden für eine Release-Planung dienen. Aufstrategischer Ebene sollen die Fähigkeiten helfen, dass ein Unternehmen seineWettbewerbsfähigkeit erwirbt und bewahrt und ein bestimmtes Wertversprechenabgeben kann.

.6 FähigkeitskartenFähigkeitskarten sind grafische Abbildungen der Elemente einer betrieblichenFähigkeitsanalyse. Die folgenden Beispiele zeigen ein Element einer Fähigkeits-karte, das als Bestandteil eines größeren Rasters anzusehen ist.

Bis heute gibt es keine Standardnotation für eine Fähigkeitskarte. Die folgendenAbbildungen zeigen zwei verschiedene Vorgehensweisen, um eine Fähigkeitskartezu erstellen. Die ersten beiden Abbildungen10.6.1 und 10.6.2 gehören zumersten Beispiel und die dritte Abbildung 10.6.3 zeigt ein zweites Beispiel.

Techniken Betriebliche Fähigkeitsanalyse

273

Abb. 10.6.1: Erstes Beispiel für eine Fähigkeitskarte – Zelle


274

Wert für denKunden

Risiko• wirtschaftliches Risiko• technologisches Risiko• Unternehmens-Risiko

Wert für dasUnternehmen

Mängel in der Performance

Hoher Wert

Mittlerer Wert

Niedriger Wert

Große Performance-Lücke

Mittlere Performance-Lücke

Geringe Performance-Lücke

Hohes Risiko

Mittleres Risiko

Niedriges Risiko

Schlüssel

Ein Ergebnis

Abb. 10.6.2: Erstes Beispiel für eine Fähigkeitskarte

Techniken Betriebliche Fähigkeitsanalyse

275

Unternehmenswertanalyse „Center of Excellence“

Hoher Wert

Mittlerer Wert

Niedriger Wert

Große Performance-Lücke

Mittlere Performance-Lücke

Geringe Performance-Lücke

Hohes Risiko

Mittleres Risiko

Niedriges Risiko

Schlüssel

Entwicklungdes Zeitplans

Anwender-Test

Templates undRessourcen-

pflege

Stakeholder-Analyse

Anwender-Akzeptanz-

Test

Mentoring

Prozess-analyse

Kommunikationder

Anforderungen

Training Planung derPersonal-

entwicklung

Ursachen-analyse

Anforderungs-management

Projektanalyse /Beratung

Ressourcen-verteilung

Fähigkeits-analyse

Anforderungs-erhebung

Unternehmens-analyse /Beratung

PerformanceManagement

Unternehmens-analyse

Projekt-analyse

ProfessionelleEntwicklung

Management

Abb. 10.6.3: Zweites Beispiel für eine Fähigkeitskarte


276

Entwicklung des Zeitplans

Stakeholder-Analyse

Prozessanalyse

Ursachenanalyse

Fähigkeitsanalyse

Anwender-Test

Anwender-Akzeptanz-Test

Kommunikation der Anforderungen

Anforderungsmanagement

Anforderungserhebung

Templates und Ressourcenpflege

Mentoring

Training

Projektanalyse / Beratung

Unternehmensanalyse / Beratung

Planung der Personalentwicklung

Ressourcenverteilung

Performance Management

Unternehmensanalysehoch mittel niedrig

Wert fürUnternehmen

Wert fürKunden

Performance-Lücke Risiko

ProjektanalyseWert für

UnternehmenWert fürKunden


ProfessionelleEntwicklung

Wert fürUnternehmen

Wert fürKunden


ManagementWert für

UnternehmenWert fürKunden


hoch mittel niedrig groß mittel gering hoch mittel niedrig

hoch mittel niedrig hoch mittel niedrig groß mittel gering hoch mittel niedrig



Bewertung

.1 Stärken• Die betriebliche Fähigkeitsanalyse schafft ein gemeinsames Verständnis für Ergebnisse, Strategie und Performance. Mit ihrer Hilfe können ziel-gerichtete Initiativen gestartet werden.

• Trägt dazu bei, dass betriebliche Vorhaben auf die betrieblichen Gegeben-heiten abgestimmt sind.

• Ist hilfreich bei der Klärung, ob ein Unternehmen die Fähigkeiten besitzt, neue Produkte oder Dienstleistungen anzubieten.

.2 Grenzen• Setzt die Bereitschaft eines Unternehmens voraus, mit diesem Modell zu arbeiten.

• Wenn keine allgemeine Akzeptanz dieses Modells besteht, können die erwünschten Wirkungen nicht erreicht werden.

• Erfordert eine breite, bereichsübergreifende Zusammenarbeit bei der Bestimmung der Fähigkeiten und des Werteordnungsrahmens.

Business Case

Zweck

Ein Business Case liefert die Rechtfertigung für ein Vorhaben, indem er denerwarteten Nutzen einer vorgeschlagenen Lösung sichtbar macht, unter Berück-sichtigung der Kosten, des zeitlichen Aufwandes und anderer Faktoren, die not-wendig sind, um diese Lösung zu erstellen und zu nutzen.

Beschreibung

Ein Business Case zeigt den Grund dafür auf, etwas zu unternehmen. EinBusiness Case wird normalerweise formal dokumentiert, kann aber auch eherformlos sein. Der Aufwand für einen Business Case sollte auf die Größe, dieBedeutung und den erwarteten Nutzen abgestimmt sein. Der Business Casebietet ausreichend detaillierte Informationen als Grundlage für eine Entscheidung,ohne dass er auf die konkrete Umsetzung eingeht. Er kann auch Katalysatorsein für Anstöße zu Veränderungsprozessen.

Techniken Business Case

277

10.6.4

10.7

10.7.1

10.7.2

Ein Business Case wird genutzt, um• einen Bedarf zu bestimmen• die gewünschten Ergebnisse festzulegen• Restriktionen, Annahmen und Risiken zu beschreiben• eine Lösung zu empfehlen.

Elemente

.1 BedarfsprüfungEin Business Case wird durch einen Bedarf ausgelöst. Mit ihm sollen relevanteZiele erreicht werden. Diese Ziele leiten sich aus der Strategie oder den Strategieneines Unternehmens ab. Eine Bedarfsprüfung ermittelt ein Problem oder eineChance. Bei der Entwicklung eines Business Case werden mehrere infrage kom-mende Alternativen ermittelt und überprüft.

.2 Gewünschte ErgebnisseDie gewünschten Ergebnisse beschreiben den Zustand, der sich ergibt, wennder Bedarf gedeckt ist. Sie sollten möglichst quantifizierbar sein, um den Erfolgmessen zu können. Die messbaren Ergebnisse sollten an definierten Meilensteinenund bei der Fertigstellung des Vorhabens überprüft werden. Sie sollten unab-hängig sein von der empfohlenen Lösung. Bei der Bewertung der Lösungsvari-anten lautet die entscheidende Frage, ob sie dazu beitragen, die gewünschtenErgebnisse zu erreichen.

.3 Bewertung von AlternativenEin Business Case identifiziert und bewertet verschiedene Lösungsvarianten.Varianten können beispielsweise unterschiedliche Technologien, Prozesse oderGeschäftsmodelle sein. Alternativen können auch in der Art der Beschaffungbestehen oder in unterschiedlichen zeitlichen Dimensionen (z.B. frühestmöglicheFertigstellung). Sie werden durch Restriktionen wie zum Beispiel Budget, Zeit-vorgaben oder rechtliche Erfordernisse beeinflusst. Immer sollte auch die „Null-Variante“ (alles wird beim Alten belassen) untersucht werden.

Jede Variante sollte nach den folgenden Kriterien bewertet werden:• Scope: Der Scope legt die Grenzen für Lösungsvarianten fest. Der Scope kann beispielsweise definiert werden über Organisationsgren-zen, Systemgrenzen, Geschäftsprozesse, Produktlinien oder geographi-sche Regionen. Aussagen über den Scope stellen klar, was zu dem Vorhaben gehört und was ausgeschlossen bleibt. Der Scope verschie-dener Varianten kann ähnlich sein, abhängig von der Lösung können sich aber durchaus auch andere Scopes ergeben.

278

Business Case Techniken

10.7.3

• Machbarkeit: Die betriebliche und technische Machbarkeit sollte für jede Alternative überprüft werden. Dazu gehören das verfügbare Wissen, die Fähigkeiten, die Ressourcen wie auch der technische Reifegrad und Erfahrungen bezüglich der vorgeschlagenen Technolo-gien.

• Annahmen, Risiken und Restriktionen: Annahmen sind Faktoren, die das gemeinsame Verständnis des Vorhabens beeinflussen. Restriktio-nen sind Vorgaben, die mögliche Alternativen ausschließen. Risiken sind potentielle Probleme, die einen negativen Einfluss auf eine Lösunghaben können. Solche vereinbarten und dokumentierten Faktoren erleichtern realistische Erwartungen und ein gemeinsames Verständnis zwischen den Stakeholdern.

• Finanzielle Analyse und Nutzeneinschätzung: Zur finanziellen Analyse und zur Nutzeneinschätzung gehören eine Schätzung der Kosten für die Umsetzung und den Betrieb einer Lösung sowie deren quantifizierter finanzieller Nutzen. Nicht-finanzielle Vorteile (wie zum Beispiel verbesserte Mitarbeitermotivation, höhere Flexibilität, verbesserte Kundenzufrieden-heit oder Reduzierung von Risiken) sind ebenfalls wichtig und bieten erheblichen Nutzen für das Unternehmen. Die Nutzeneinschätzungen werden daraufhin überprüft, ob sie mit den strategischen Zielen eines Unternehmens verträglich sind.

.4 Vorgeschlagene LösungDie vorgeschlagene Lösung beschreibt den wünschenswerten Weg, ein Problemzu lösen oder eine Chance zu ergreifen. Die Lösung wird in einem ausreichendenDetaillierungsgrad für die Entscheider so beschrieben, dass sie diese Lösung ver-stehen und zu einer Entscheidung kommen können. Die vorgeschlagene Lösungkann auch Kostenschätzungen und den Zeitbedarf für die Umsetzung einschlie-ßen. Der Nutzen oder die Ergebnisse werden so beschrieben, dass die Stakeholdernach der Einführung beurteilen können, ob die Erwartungen erfüllt wurden.

Bewertung

.1 Stärken• Business Cases bieten eine Verschmelzung komplexer Fakten, Sachver-halte und Analysen, die eine Entscheidung ermöglichen.

• Business Cases liefern eine detaillierte finanzielle Analyse von Kosten und Nutzen.

• Sie bieten Hilfestellungen für die laufenden Entscheidungen während des Vorhabens.

Techniken Business Case

279

10.7.4

.2 Grenzen• Es besteht die Gefahr der subjektiven Verzerrung durch die Ersteller.• Wird normalerweise nicht aktualisiert, nachdem die Entscheidung gefällt wurde.

• Es fließen Annahmen über Kosten und Nutzen ein, die sich bei weiteren Untersuchungen als nicht realistisch erweisen können.

Darstellung des Geschäftsmodells

Zweck

Die Darstellung eines Geschäftsmodells beschreibt, wie ein Unternehmen Nutzenfür seine Kunden schafft und liefert und wie es dafür entlohnt wird.

Beschreibung

Die Darstellung des Geschäftsmodells beinhaltet neun Themenblöcke, in denenbeschrieben wird wie ein Unternehmen Nutzen schaffen will:• Zentrale Partnerschaften• Kernaktivitäten• Kernressourcen• Nutzenversprechen• Beziehungen zu Kunden• Kanäle• Kundensegmente• Kostenstruktur• Erlösfluss.

Diese Themen werden in einer Grafik angeordnet, aus der die Beziehungen zwi-schen den betrieblichen Aktivitäten, den Finanzen, den Kunden und den Ange-boten hervorgehen. Diese Darstellung kann auch als Blaupause dienen, um eineStrategie einzuführen.


280

Techniken

10.8

10.8.1

10.8.2

Abb. 10.8.1: Darstellung des Geschäftsmodells

Eine Darstellung des Geschäftsmodells kann ebenso zur Diagnose wie für diePlanung der Strategie oder einzelner Vorhaben genutzt werden. Die Elementeder Darstellung dienen als Vergrößerungsglas zur Diagnose des gegenwärtigenZustands des Unternehmens, insbesondere im Hinblick auf den Umfang an Ener-gie, Zeit und Ressourcen, welche das Unternehmen gegenwärtig in verschiedeneGebiete investiert. Als ein Modell zur Planung und Überwachung kann die Dar-stellung auch ein Leitfaden und Raster zum Verständnis von Abhängigkeitenund Prioritäten zwischen Gruppen und Vorhaben sein.

Die Darstellung des Geschäftsmodells kann auch dazu genutzt werden, dieBeziehungen von Programmen, Projekten oder anderen Vorhaben (zum BeispielPersonalbeschaffung oder Mitarbeiterbindung) zur Unternehmensstrategie dar-zustellen. In diesen Fällen dient die Darstellung dazu, sichtbar zu machen, woein Unternehmen investiert oder in welchen Zusammenhang ein spezielles Vor-haben passt.


281

Techniken

ZentralePartnerschaften

Kernaktivitäten

Kernressourcen

Nutzen-versprechen

Beziehungenzu Kunden

Kanäle

Kunden-segmente

Kostenstruktur Erlösfluss

Elemente

.1 Zentrale PartnerschaftenZentrale Partnerschaften bringen es häufig mit sich, dass betriebliche Informa-tionen, z. B. über genutzte Technologien, weitergegeben müssen. In einigenFällen kann eine funktionierende Partnerschaft auch weitergehend formalisiertwerden, etwa durch eine Beteiligung oder einen Merger.

Vorteile zentraler Partnerschaften sind unter anderem:• Optimierung und ökonomische Vorteile• Verringerung von Risiken und Unsicherheiten• Gewinnung spezieller Ressourcen und Aktivitäten• Mangel an internen Fähigkeiten.

.2 KernaktivitätenKernaktivitäten sind kritisch für die Schaffung, Lieferung und Bewahrung vonWerten sowie für die Durchführung anderer Aktivitäten eines Unternehmens.

Kernaktivitäten können folgendermaßen klassifiziert werden:• Wertschöpfende Aktivitäten: Sachverhalte, für die ein Kunde bereit ist zu zahlen.

• Nicht-wertschöpfende Aktivitäten: Sachverhalte und Leistungen, für die der Kunde nicht zu zahlen bereit ist, weil sie ihm keinen zusätz-lichen Nutzen bringen.

• Betriebsbedingte, nicht-wertschöpfende Aktivitäten: Leistungen, die aus betrieblichen oder sonstigen Gründen zu erbringen sind (z.B. gesetzliche Pflichten oder interne Aufgaben), für die ein Kunden nicht zu zahlen bereit ist.

.3 KernressourcenRessourcen sind die Voraussetzungen, um überhaupt ein Geschäftsmodell umzu-setzen. Je nach Geschäftsmodell werden unterschiedliche Ressourcen benötigt.

Ressourcen können folgendermaßen klassifiziert werden:• physische Ressourcen (Gebäude, Maschinen)• finanzielle Ressourcen (flüssige Mittel und Kreditlinien, die für den Geschäftsbetrieb benötigt werden)

• intellektuelle Ressourcen (Wissen, Patente, Copyright, Kunden, Informationen, Markenrechte)

• humane Ressourcen (Menschen).


282

Techniken

10.8.3

.4 NutzenversprechenEin Nutzenversprechen beschreibt, welchen Nutzen ein Unternehmen seinenKunden durch seine Produkte oder Leistungen anbietet. Dabei kann es sich umein einzelnes Produkt oder einen Service oder um eine ganze Gruppe von Güternund Leistungen handeln, die dem Kunden dienen bzw. dessen Probleme lösen.

.5 Beziehungen zu KundenAllgemein kann zwischen der Gewinnung und Bindung von Kunden unterschie-den werden. Die dabei angewendeten Verfahren hängen unter anderem vondem gewünschten Ausmaß an Austausch und von den verwendeten Kommuni-kationswegen und -verfahren ab. So können beispielsweise Kundenbeziehungensehr stark personifiziert sein oder aber automatisch ablaufen. Diese Beziehungenkönnen eher formalisiert oder auch informal sein.

.6 KanäleKanäle sind unterschiedliche Wege, auf denen ein Unternehmen mit seinenKunden interagiert und den Kunden Werte liefert. Einige Kanäle sind kommuni-kativ (zum Beispiel Marketing-Kanäle) und einige lieferorientiert (zum BeispielLieferlogistik).

Unternehmen nutzen Kanäle, um• auf ihr Angebot aufmerksam zu machen• dem Kunden das Nutzenversprechen sichtbar zu machen• Produkte oder Leistungen zu kaufen• Support zu bieten.

Zum Verständnis der Kanäle müssen Prozesse, Verfahren, Technologien, Inputund Output ebenso identifiziert werden wie die Bedeutung verschiedener Kanälefür die Umsetzung der Strategie.

.7 KundensegmenteIn Kundensegmenten werden solche Kunden gruppiert, die vergleichbare Bedarfehaben und ähnliche Merkmale aufweisen, so dass ein Unternehmen effektiverund effizienter dieses Segment bedienen kann.

Ein Unternehmen könnte verschiedene Kundensegmente abgrenzen, wenn• jedes Segment einen anderen Bedarf hat• die Segmente sehr unterschiedlich profitabel sind• unterschiedliche Distributionskanäle genutzt werden• die Segmente sich im Aufbau und im Erhalt der Kundenbeziehungen unterscheiden.


283

Techniken

.8 KostenstrukturJede Organisationseinheit, jedes Produkt oder jede Aktivität in einem Unterneh-men verursacht Kosten. Unternehmen versuchen, soweit wie möglich Kostenzu reduzieren, zu minimieren oder zu eliminieren. Eine Kostensenkung kann dieRentabilität eines Unternehmens fördern und damit Möglichkeiten eröffnen,Werte für das Unternehmen oder für die Kunden zu schaffen. Deswegen ist eswichtig, das jeweilige Geschäftsmodell und die damit verbundenen Kosten zuverstehen, um zu erkennen, wo primär Kosten eingespart werden können.

.9 Erlösfluss

Der Erlösfluss ist der Weg oder das Verfahren, auf dem Erlöse von einem Kun-densegment im Austausch für die erbrachten Leistungen in ein Unternehmengelangen. Es gibt zwei elementare Wege, auf denen Erlöse erzielt werden: Ein-maliger Kauf eines Produktes oder einer Leistung oder wiederkehrende Erlösedurch periodische Zahlungen für Güter, Services oder Support.

Beispiele für verschiedene Erlösflüsse sind:• Lizenzen oder Subskriptionsgebühren (der Kunde zahlt für das Recht auf den einmaligen oder wiederkehrenden Zugriff auf ein bestimmtes Gut).

• Transaktions- oder Nutzungsgebühren (der Kunde zahlt jedes mal für die Nutzung eines Produktes oder eines Service).

• Verkauf (der Kunde gewinnt das Eigentumsrecht an einem spezifi-schen Produkt).

• Vermietung oder Leasing (der Kunde hat ein zeitlich befristetes Recht, bestimmte Güter zu nutzen).

Bewertung

.1 Stärken• Die Darstellung des Geschäftsmodells ist ein weit verbreiteter und wirk-samer Weg, ein Geschäftsmodell zu durchdringen und zu optimieren.

• Es ist einfach zu verstehen und leicht zu handhaben.

.2 Grenzen• Berücksichtigt nicht alternative Wertmaßstäbe wie zum Beispiel soziale Auswirkungen oder Einflüsse auf die Umwelt.

• Das Hauptaugenmerk auf das Nutzenversprechen bietet kein ganzheit-liches Bild für die Entwicklung der Unternehmensstrategie.

• Verdeutlicht nicht die strategische Position des Unternehmens.


284

Techniken

10.8.4

Analyse der Geschäftsregeln

Zweck

Die Analyse der Geschäftsregeln wird dazu verwendet, Regeln, die das Tagesge-schäft und die Entscheidungsfindung steuern, zu identifizieren, darzustellen, zuvalidieren und zu organisieren.

Beschreibung

Unternehmenspolitik und Regeln steuern das Tagesgeschäft eines Unternehmensund seiner Prozesse und prägen die betrieblichen Entscheidungen. Eine Unter-nehmenspolitik ist eine generelle Anweisung, mit der die Aktionen eines Unter-nehmens und die Menschen in Unternehmen beeinflusst, reguliert und kontrolliertwerden. Eine Geschäftsregel ist eine spezifische, nachprüfbare Vorgabe, diedazu dient, das konkrete Verhalten zu steuern, zu beurteilen oder Entscheidungenherbeizuführen. Eine Geschäftsregel muss eindeutig sein (keiner weiteren Erläu-terung bedürfen). Sie kann lediglich von autorisierten Stellen im Unternehmengesetzt werden.

Zur Analyse von Geschäftsregeln gehören deren Sammlung, Formulierung, Vali-dierung mit den Stakeholdern, die Abstimmung auf die Unternehmensziele unddie Aufbereitung der Geschäftsregeln, so dass sie wirksam genutzt werden kön-nen. Es gibt explizite Quellen für Geschäftsregeln (zum Beispiel eine dokumentierteGeschäftspolitik oder Verträge) oder verdeckte Quellen (zum Beispiel nicht-doku-mentiertes Know-how von Stakeholdern, gewohnheitsmäßige Praktiken oderkulturelle Normen). Geschäftsregeln sollten explizit, eindeutig, klar und leichtzugänglich sein und aus einer zentralen Quelle stammen. Grundlegende Prinzipienfür Geschäftsregeln sind:• Geschäftsregeln basieren auf einer standardisierten Terminologie, sodass die Fachleute im Unternehmen in der Lage sind, sie zu validieren.

• Regeln werden getrennt von dem Vorgehen, wie sie durchgesetzt werden.

• Regeln werden auf einer sehr detaillierten Ebene als eindeutige Vor-gaben formuliert.

• Sie werden getrennt von den Prozessen, die sie unterstützen oder beeinflussen.

• Die Beziehungen der Regeln zu den relevanten Entscheidungen werden dokumentiert.

• Regeln werden laufend überwacht und an relevante Veränderungen angepasst.


285

Techniken

10.9.2

10.9

10.9.1

Eine Gruppierung von Geschäftsregeln, die für die Entscheidungsfindung genutztwerden kann, wird auch als Entscheidungsmatrix oder als Entscheidungsbaumbezeichnet (siehe Kap. 10.16.2). Sie können viele Regeln beinhalten und sehrkomplex sein.

Elemente

Geschäftsregeln erfordern die konsistente Nutzung betrieblicher Begriffe, einGlossar für die im Unternehmen benutzten Begriffe und das Verständnis derstrukturellen Verbindungen zwischen diesen Begriffen. Glossare von Wirtschafts-verbänden oder anderen Unternehmen sollten erwogen werden, wenn es keineigenes Glossar gibt. Manchmal sind auch Definitionen und Strukturen von DataDictionaries oder von Datenmodellen hilfreich. Geschäftsregeln sollten unabhängigvon der jeweils installierten Technologie sein, so dass sie von allen Mitarbeiterngenutzt werden können.

Häufig gibt es Ausnahmen zu den Geschäftsregeln. Sie sollten dann als zusätzlicheRegeln behandelt werden. Vorhandene Regeln sind daraufhin zu überprüfen,ob sie mit den betrieblichen Zielen verträglich sind und ob sie immer nochgelten, wenn neue Lösungen entwickelt werden.

.1 Definitorische RegelnDefinitorische Regeln konkretisieren Begriffe oder sie schaffen Wissen oder Infor-mation. Sie stellen Informationen bereit, wie ein Begriff zu verstehen ist. Defini-torische Regeln können nicht verletzt werden, aber sie können falsch angewendetwerden. Ein Beispiel für eine definitorische Regel ist:„Ein Kunde wird als bevorzugter Kunde angesehen, wenn er mehr als zehnAufträge pro Monat erteilt.“

Definitorische Regeln schreiben häufig vor, wie Informationen abgeleitet werden,wie sie zu berechnen sind oder welche Schlussfolgerungen aus Informationenzu ziehen sind. Eine Schlussfolgerung kann sich unter Umständen aus mehrerenRegeln ergeben, von denen jede wiederum ihre eigenen Ableitungen oderBerechnungen beinhaltet. Solche Kombinationen definitorischer Regeln werdenoft für Entscheidungen in Prozessen oder zu bestimmten Ereignissen benutzt.Ein Beispiel für eine solche Regel könnte sein: „Die lokale Steuer für einen Auftrag wird ermittelt aus der Summe aller Preisefür alle Gegenstände, die der lokalen Steuer unterliegen, multipliziert mit demlokalen Steuersatz.“

.2 VerhaltensregelnVerhaltensregeln sind Regeln für Personen, die auch dann gelten, wenn das Verhaltenautomatisiert ist. Sie dienen dazu, das Tagesgeschäft zu lenken. Dies geschieht,


286

Techniken

10.9.3

indem Verpflichtungen oder Verbote erlassen werden, die das Verhalten, Aktionen,Praktiken oder Verfahren betreffen. Verhaltensregeln werden von Unternehmenerlassen und durchgesetzt, um die Unternehmenspolitik zu unterstützen, Risikenzu vermindern oder die Produktivität zu fördern. Oft werden dazu Informationengenutzt, die sich aus definitorischen Regeln ergeben. Verhaltensregeln sollen dieAktionen von Menschen steuern, die innerhalb des Unternehmens arbeiten oderdie mit dem Unternehmen zu tun haben. Sie können Menschen verpflichten, Dingeauf eine bestimmte Art und Weise zu tun, sie daran hindern etwas zu tun oder dieBedingungen beschreiben, unter denen etwas zu tun ist. Ein Beispiel für eine Ver-haltensregel ist:„Eine Bestellung wird nicht erledigt, wenn die Rechnungsadresse des Kundennicht übereinstimmt mit dessen Adresse in der Datei des Kreditkartenunter-nehmens.“

Im Unterschied zu den definitorischen Regeln können Verhaltensregeln direktverletzt werden. Schon aus der Definition geht hervor, dass es immer möglichist, Verhaltensregeln zu verletzen, selbst wenn ein Unternehmen das unbedingtvermeiden möchte und außergewöhnliche Vorkehrungen gegen solche Verlet-zungen getroffen hat. Deswegen muss genau untersucht werden, wie Regelnerzwungen werden sollen, welche Arten von Sanktionen im Falle einer Regel-verletzung und welche weiteren Maßnahmen vorbeugend und im Nachhineinergriffen werden können. Derartige Analysen führen häufig zu einer Spezifizierungweiterer Regeln.

Verschiedene Intensitäten der Durchsetzung einer Verhaltensregel können vor-gesehen werden. Zum Beispiel:• absolut keine Verletzungen erlaubt• Verletzungen werden von einer autorisierten Stelle korrigiert• keine Maßnahmen, ein Verhalten zu erzwingen.

Eine Verhaltensregel, für die es keine Maßnahmen zur Durchsetzung gibt, ist ehereine Richtschnur, mit der das bevorzugte oder beste Verhalten empfohlen wird.

Bewertung

.1 Stärken• Änderungen von Geschäftsregeln können leicht umgesetzt werden, wennsie in einem zentralen System verwaltet werden.

• Eine zentrale Datei schafft die Möglichkeit, Geschäftsregeln innerhalb des Unternehmens mehrfach zu verwenden.

• Geschäftsregeln strukturieren und steuern das betriebliche Verhalten.• Eindeutig definierte und verwaltete Geschäftsregeln erlauben Änderun-gen der Unternehmenspolitik, ohne Prozesse oder Systeme zu verändern.


287

Techniken

10.9.4

.2 Grenzen• Unternehmen können umfangreiche Listen mehrdeutiger Geschäftsregelnerstellen.

• Geschäftsregeln können einander widersprechen oder bei gleichzeitiger Verwendung unvorhergesehene Wirkungen entfalten, wenn sie nicht aufeinander abgestimmt sind.

• Wenn das verwendete Vokabular mehrdeutig, wenig geeignet oder schlecht aufbereitet ist, werden die damit erarbeiteten Geschäftsregeln fehlerhaft oder widersprüchlich sein.

Gemeinschaftliche Spiele

Zweck

Gemeinschaftliche Spiele ermutigen die Teilnehmer, zusammenzuwirken, umein gemeinsames Verständnis für ein Problem oder eine Lösung zu erreichen.

Beschreibung

Gemeinschaftliche Spiele leiten sich aus verschiedenen strukturierten Spieltech-niken ab und dienen dazu, die Zusammenarbeit zu erleichtern. Jedes Spiel folgtRegeln, die dazu dienen, dass die Teilnehmer sich auf ein bestimmtes Ziel fokus-sieren. Die Spiele werden genutzt, damit die Teilnehmer ihr Wissen und ihreErfahrungen teilen, versteckte Annahmen erkennen und aus dem Wissen Schlüsseziehen, wie es in normalen Interaktionen kaum geschehen würde. Die gemein-same Erfahrung in dem gemeinschaftlichen Spiel ermutigt Menschen, die unter-schiedliche Sichten auf einen Sachverhalt haben, besser zusammenzuarbeiten,einander besser zu verstehen, eine gemeinsame Lösung zu erarbeiten oder eingemeinsames Problemverständnis zu schaffen. Viele gemeinschaftliche Spielekönnen dazu verwendet werden, die Perspektiven unterschiedlicher Stakeholderzu verstehen.

Gemeinschaftliche Spiele sind besonders erfolgreich, wenn ein neutraler Mode-rator den Teilnehmern hilft, die Regeln zu verstehen und sie durchzusetzen. Esist Aufgabe des Moderators, das Spiel voranzubringen und sicherzustellen, dassalle Teilnehmer die ihnen zugedachten Rollen spielen. Gemeinschaftliche Spielenutzen normalerweise taktile und visuelle Elemente. Die aktive Arbeit mit Mode-rationskarten und Klebezetteln, das Schreiben auf Tafeln oder das Zeichnen vonBildern hilft Menschen, Hemmungen abzubauen, und fördert kreatives und late-rales Denken.


288

Techniken

10.10

10.10.1

10.10.2

Elemente

.1 Zweck eines SpielsJedes einzelne gemeinschaftliche Spiel verfolgt einen bestimmten Zweck. Nor-malerweise soll ein besseres Verständnis für ein Problem geschaffen oder essollen kreative Lösungen gefunden werden. Der Moderator hilft den Teilnehmern,den Zweck zu verstehen und gemeinsam erfolgreich zu arbeiten.

.2 ProzessJede Art eines gemeinschaftlichen Spiels folgt einem bestimmten Prozess oderbefolgt bestimmte Regeln, welche zur Erreichung des Ziels beitragen. Für jedeneinzelnen Schritt steht normalerweise nur eine begrenzte Zeit zur Verfügung.

Spiele laufen meistens in drei Schritten ab:Schritt 1: Einstiegsphase, in der das Engagement der Teilnehmer

geweckt werden soll, in der die Regeln bekanntgegeben werden und die Ideensammlung beginnt.

Schritt 2: Explorationsphase, in der die Teilnehmer zusammenarbeiten, Verbindungen zwischen ihren Ideen suchen, gefundene Ideen testen und mit neuen Ideen experimentieren.

Schritt 3: Abschlussphase, in der Ideen bewertet und solche Ideen herausgefiltert werden, die vermutlich am besten geeignet sind, das Ziel zu erreichen.

.3 ErgebnisAm Ende eines gemeinschaftlichen Spiels untersuchen die Teilnehmer zusammenmit dem Moderator die Ergebnisse und legen die Entscheidungen oder Aktionenfest, die aufgrund der gefundenen Ergebnisse ergriffen werden müssen.

.4 Beispiele für gemeinschaftliche SpieleEs gibt viele unterschiedliche gemeinschaftliche Spiele. Hier einige Beispiele:


289

Techniken

10.10.3

Tabelle 10.10.1: Beispiele für gemeinschaftliche Spiele

Bewertung

.1 Stärken• Spiele können verdeckte Annahmen oder Meinungsunterschiede ver-deutlichen.

• Sie ermutigen kreatives Denken, indem sie alternative mentale Prozesse anregen.

• Sie regen eher stille oder zurückhaltende Teilnehmer an, eine aktive Rolle im Team zu übernehmen.

• In einigen gemeinschaftlichen Spielen können auch betriebliche Bedarfe sichtbar gemacht werden, die bisher nicht befriedigt werden.

.2 Grenzen• Die spielerische Art kann von zurückhaltenden Menschen als albern empfunden werden oder dazu führen, dass sie sich unwohl fühlen.

• Spiele können zeitaufwändig sein und insbesondere dann als unproduktiv empfunden werden, wenn die Ziele oder die Ergebnisse unklar sind.

• Die Ergebnisse einer Gruppenarbeit können ein trügerisches Vertrauen in die „Richtigkeit“ der Ergebnisse bewirken.


290

Techniken

Spiel Beschreibung Ziel

Produkt-verpackung

Die Teilnehmer erarbeiten eineSchachtel für ein Produkt, das imEinzelhandel angeboten werdensoll.

Hilft, die Produktmerkmalezu identifizieren, die imMarkt besonderes Interessewecken könnten.

Ähnlich-keitskarte

Die Teilnehmer schreiben Merkmaleauf selbstklebende Karten, heften sieauf eine Tafel und ordnen sie dannzu Gruppen ähnlicher Merkmale.

Wird verwendet, um mit-einander verbundene Themen oder Merkmale zuidentifizieren.

Fischglas Die Teilnehmer werden in zweiGruppen eingeteilt. Eine Gruppespricht über einen Sachverhalt, wäh-rend die andere Gruppe beobachtetund ihre Beobachtungen aufschreibt.

Wird verwendet, um verdeckte Unterstellungenoder Annahmen zu erken-nen.

10.10.4

Begriffsmodellierung

Zweck

Ein Begriffsmodell dient dazu, das in einem Unternehmen genutzte Vokabular zuorganisieren, um so eine fundierte und konsistente Kommunikation zu ermöglichen.

Beschreibung

Der erste Teil eines Begriffsmodells ist ein Glossar, das typischerweise auf zentraleSubstantive fokussiert. Begriffsmodelle legen größten Wert auf hochwertige,lösungsneutrale Begriffe und sind frei von Daten oder Sachverhalten, die mitder Einführung zu tun haben. Sie legen Wert auf eine differenzierte Sprache.

Ein Begriffsmodell legt die exakte Bedeutung eines Wortes fest und schließt dieBegriffe der Business-Analyse mit ein. Ein Begriffsmodell ist dann besonders wichtig,wenn Präzision – auch bei sehr differenzierten Begriffen – erforderlich ist.

Begriffsmodelle sind immer dann besonders wertvoll, wenn• ein Unternehmen wichtiges Wissen organisieren, bewahren, weiterver-wenden, verwalten und übermitteln will

• in einem Vorhaben viele Geschäftsregeln genutzt werden• die Stakeholder sich gegen Nomenklatur und Definitionen aus Daten-modellen, Klassendiagrammen oder Datenelementen wehren, die sie als rein technologisch ansehen

• innovative Lösungen bei der Restrukturierung von Prozessen oder anderenAspekten zur betrieblichen Leistungssteigerung angestrebt werden

• ein Unternehmen hinsichtlich der Compliance oder anderer Regelun-gen besonders gefordert ist.

Ein Begriffsmodell unterscheidet sich von einem Datenmodell. Ein Begriffsmodellsoll die natürliche Sprache und deren Semantik nutzen. Begriffsmodelle sindnicht dazu da, Daten zu verbinden, zu verschlüsseln oder zu vereinfachen. Des-wegen ist das Vokabular in einem Begriffsmodell viel reicher und differenzierterund berücksichtigt die Terminologie von Geschäftseinheiten. Diese Modelle wer-den häufig grafisch aufbereitet.

Elemente

.1 Definition von SubstantivenDefinitionen von Substantiven, die typischerweise in einem Fachbereich genutztwerden, sind elementare Bestandteile von Begriffsmodellen.


291

Techniken

10.11

10.11.1

10.11.2

10.11.3

.2 Definition von VerbenDefinitionen von Verben bieten die strukturelle Verbindung zwischen Definitionenvon Substantiven. Die Definitionen von Verben nutzen standardisierte Begriffe,so dass sie eindeutig verwendet werden können. Verben müssen nicht unbedingtin ganzen Sätzen beschrieben werden, oft reicht auch ein Satzteil, der alsBaustein von Sätzen weiterverwendet werden kann (wie z.B. Aussagen inGeschäftsregeln). Manchmal werden Beschreibungen von Verben aus Definiti-onsregeln abgeleitet oder zusammengesetzt. So können neues Wissen oderneue Informationen aus grundlegenden Fakten geschaffen werden.

.3 Andere VerbindungenDa Begriffsmodelle eine differenzierte Semantik unterstützen müssen, werdenneben den Definitionen von Substantiven und Verben auch andere standardisierteVerbindungen genutzt. Dazu gehören unter anderem:• Kategorisierungen• Klassifikationen• Verbindungen zwischen Teilmengen/Untermengen • Rollen.

Bewertung

.1 Stärken• Begriffsmodelle bieten eine anwenderfreundliche Gelegenheit, mit Stake-holdern über präzise Bedeutungen und feine Unterscheidungen zu kommunizieren.

• Sie sind unabhängig von möglichen Verzerrungen aus dem Datendesign und dessen meist sehr begrenztem Wortschatz.

• Sie sind nützlich für anspruchsvolle und komplexe Geschäftsprozesse, in die viel Wissen einfließt.

• Sie tragen dazu bei, dass selbst große Mengen von Geschäftsregeln und komplexen Entscheidungstabellen eindeutig und auf einander abgestimmt sind.

.2 Grenzen• Begriffsmodelle können unrealistisch hohe Erwartungen wecken, wie schnell eine Integration über die Klärung der Semantik erreicht werden kann.

• Setzen spezialisierte Kenntnisse und die Fähigkeit zu abstraktem Denken voraus.


292

Techniken

10.11.4

• Die Fokussierung auf Wissen und Regeln kann auf Stakeholder befremd-lich wirken.

• Setzen die Unterstützung durch Tools voraus, auf die beim Formulieren von Geschäftsregeln, Anforderungen und anderen Sachverhalten direkt zurück-gegriffen werden kann.

Data Dictionary

Zweck

Ein Data Dictionary wird dazu verwendet, die Definition von Datenelementenzu standardisieren und eine gemeinsame Interpretation dieser Datenelementezu ermöglichen.

Beschreibung

Ein Data Dictionary wird verwendet, um Standarddefinitionen von Datenele-menten, deren Bedeutung und zulässige Werte zu dokumentieren. Ein DataDictionary enthält Definitionen jedes Datenelements und zeigt auf, wie dieseElemente zu zusammengesetzten Elementen verbunden werden. Data Dictionarieswerden genutzt, um den Gebrauch und die Bedeutung von Datenelementen zustandardisieren, so dass die Stakeholder erkennen, welche Datenelemente inden Lösungen verwendet werden.

Data Dictionaries werden auch als Datenbanken für Metadaten bezeichnet. Sieunterstützen die Nutzung von Daten in den Lösungen. Wenn Unternehmen dasData Mining und andere hoch entwickelte Analyseverfahren einsetzen wollen,kann ein Data Dictionary die Metadaten bereitstellen, die für diese komplexerenSzenarien benötigt werden. Ein Data Dictionary wird oft im Zusammenhang miteinem Entity-Relationship-Diagramm eingesetzt (siehe Datenmodellierung, Kap.10.15) und kann aus einem Datenmodell abgeleitet werden. Data Dictionarieskönnen manuell (zum Beispiel als eine Tabelle) oder mithilfe eines automatisiertenWerkzeugs gepflegt werden.

Data Dictionary

293

Techniken

10.12

10.12.2

10.12.1

Abb. 10.12.1: Beispiel für ein Data Dictionary

Elemente

.1 DatenelementeData Dictionaries beschreiben die charakteristischen Merkmale von Datenele-menten, auch gemäß der Definition, welche die Stakeholder verwenden. ZuData Dictionaries gehören die Standarddefinition von Datenelementen, derenBedeutung und die zulässigen Werte. Data Dictionaries enthalten Definitionenfür die elementaren Datenelemente und beschreiben, wie diese Elemente zuzusammengesetzten Datenelementen verbunden werden.

.2 Primitive DatenelementeDie folgenden Informationen müssen für jedes Datenelement in einem DataDictionary enthalten sein:• Name: Nur einmal vergebene Bezeichnung für das Datenelement, auf die von zusammengesetzten Datenelementen referenziert wird.

• Alias: Alternative Namen des Datenelements, die von Stakeholdern verwendet werden.

• Werte/Bedeutungen: Liste zulässiger Werte für dieses Datenelement. Dazu können die erlaubten Werte direkt genannt werden oder es werden lediglich die erlaubten Formate (u.U. einschließlich der Anzahl der erlaubten Zeichen) angeführt. Wenn es für Werte Abkürzungen gibt, muss deren Bedeutung ebenfalls aufgeführt werden.

Data Dictionary

294

Techniken

Primitive Datenelemente

Datenelement 1 Datenelement 2 Datenelement 3

Name Zur Referenzierung verwendeter Name

Erster Vorname Zweiter Vorname Familienname

AliasAnderer Name, der vonStakeholdern benutzt wird

VerwendeterVorname

Zweiter Vorname Beiname

Werte/BedeutungenAufzählung oder Beschrei-bung von Datenelementen

Mindestens zweiBuchstaben

Kann entfallen Mindestens zweiBuchstaben

BeschreibungDefinition

Erster Vorname Zweiter Vorname Familienname

Zusammengesetzte Datenelemente

Name des Kunden = erster Vorname + zweiter Vor-name + Familienname

10.12.3

• Beschreibung: Definition des Datenelements im Zusammenhang mit einer Lösung.

.3 Zusammengesetzte DatenelementeZusammengesetzte Datenelemente entstehen, indem primitive Datenelementezu Strukturen zusammengeführt werden. Strukturen können sein:• Folgen: Die Ordnung primitiver Datenelemente innerhalb einer zusammengesetzten Struktur. So zeigt beispielsweise ein Plus, dass einElement auf ein anderes folgt oder mit ihm verbunden wird.

• Wiederholungen: Zeigen, ob ein Datenelement mehrfach wiederholt werden kann.

• Optionale Elemente: Können, müssen aber nicht in einem zusammen-gesetzten Element enthalten sein.

Bewertung

.1 Vorteile• Data Dictionaries sorgen dafür, dass alle Stakeholder ein gemeinsames Ver-ständnis über das Format und den Inhalt einer relevanten Information haben.

• Eine einzige Datei der betrieblichen Metadaten fördert den konsistenten Gebrauch von Daten in einem Unternehmen.

.2 Grenzen• Data Dictionaries erfordern eine kontinuierliche Pflege, da andernfalls Metadaten überflüssig oder fehlerhaft werden könnten.

• Die Pflege muss zügig und konsistent erfolgen, so dass Stakeholder schnell und einfach die Informationen wiederfinden, die sie benötigen. Eine korrekte und vollständige Pflege kostet Zeit und Geld.

• Wenn verfügbare Metadaten nicht an verschiedenen Stellen in einem Unter-nehmen genutzt werden, bleibt der Nutzen für das Unternehmen begrenzt.

Datenflussdiagramme

Zweck

Datenflussdiagramme zeigen, woher Daten kommen, mit welchen Aktivitäten dieDaten verarbeitet werden und ob die Ergebnisse der Verarbeitung gespeichert odervon einer anderen Aktivität bzw. einer externen Einheit verwendet werden.

Datenflussdiagramme

295

Techniken

10.12.4

10.13

10.13.1

Beschreibung

Datenflussdiagramme bilden den Transformationsprozess von Daten ab. Sieeignen sich für die Visualisierung eines Transaktions-Systems und zeigen dieGrenzen eines physischen, logischen oder manuellen Systems auf.

Ein Datenflussdiagramm zeigt die Bewegungen und Umwandlungen von Datenzwischen externen Größen und Prozessen. Der Output einer externen Einheitoder eines Prozesses ist der Input einer anderen Einheit oder eines Prozesses.Datenflussdiagramme zeigen auch die temporären oder dauerhaften Speicher(die als Datenspeicher oder Datenbank bezeichnet werden), in denen die Datenin einem System oder in einer Organisation aufbewahrt werden. Die verwendetenDaten sollten in einem Data Dictionary definiert werden.

Datenflussdiagramme können verschiedene Abstraktionsebenen abbilden. Diehöchste Ebene betrifft das gesamte System mit den externen Agenten als Liefe-ranten und Abnehmer der Ergebnisse des Transformationsprozesses.

Abb. 10.13.1: Kontext-Diagramm in der Notation Gane-Sarson

Datenflussdiagramme

296

Techniken

Daten-Input

ExternerAgent

Substantiv

ExternerAgent

Substantiv

ExternerAgent

Substantiv

ExternerAgent

Substantiv

Verarbeitungs-prozess

Substantiv / VerbSatz zur

BeschreibungDaten-Input

Daten-Input

Daten-Input

Daten-Output

Daten-Output

Daten-Output

Daten-Output

10.13.2

Die nächste Ebene eines Datenflussdiagramms ist das Level-1-Diagramm. Level-1-Diagramme zeigen die Prozesse des Systems mit den jeweiligen Inputdaten,dem Output und den Datenspeichern.

Abb. 10.13.2: Level-1-Diagramm nach der Yourdon-Notation

Weitere Ebenen eines Datenflussdiagramms (Level 2, Level 3 usw.) zergliederndie Prozesse aus dem Diagramm der obersten Ebene. Level-1-Diagramme sindnützlich, um die Aufgliederung der Prozesse in Unter- und Teilsysteme (Partition),der Datenflüsse zwischen den Unter- und Teilsystemen sowie die gespeichertenDaten zu verstehen, die von diesen Einheiten verwendet werden. Wenn esgewünscht wird oder notwendig ist, kann jedes Unter- bzw. Teilsystem weiterzergliedert werden. Die externen Agenten bleiben unverändert, zusätzliche Flüsseund Speicher werden festgelegt.

Datenflussdiagramme

297

Techniken

Daten-InputSubstantiv

ExternerAgent

Substantiv

ExternerAgent

Substantiv

Verar-beitungs-prozess

Substantiv /Verb



Daten-OutputSubstantiv

Daten-speicher

ExternerAgent

Substantiv

ExternerAgent

Substantiv

Substantiv


Substantiv /Verb

Transfor-mierteDaten

als Output


Substantiv /Verb

Logische Datenflussdiagramme bilden den zukünftigen Zustand ab, sie zeigen,welche Transformationen unabhängig von den gegenwärtigen physikalischenBegrenzungen stattfinden müssen. Physische Datenflussdiagramme modellierenalle Speicher, Drucker, Masken, Apparate und andere Erscheinungsformen vonDaten. Das physische Diagramm kann entweder den gegenwärtigen oder denzukünftigen Zustand abbilden.

Elemente

.1 Externe (Entität, Quelle, Senke)Eine Externe (Entität, Quelle, Senke) ist eine Person, eine Organisation, ein auto-matisiertes System oder eine Vorrichtung, welche(s) in der Lage ist, Daten zuproduzieren oder zu empfangen. Eine Externe liegt außerhalb des betrachtetenSystems. Externe sind die Quellen oder die Empfänger (Senken) von Daten. JedeExterne muss zumindest eine Dateneinheit senden oder empfangen. Externewerden durch ein Substantiv in einem Rechteck beschrieben. Sie finden sich aufallen Zerlegungsstufen von Datenflussdiagrammen.

.2 DatenspeicherEin Datenspeicher ist eine Sammlung von Daten, die mehrfach genutzt und fürdie spätere Verwendung aufbewahrt werden. Es handelt sich um Daten imRuhezustand. Jeder Speicher muss zumindest einen Datenfluss aufweisen, derzu ihm hinführt oder aus ihm herauskommt. Ein Datenspeicher wird entwederdurch zwei parallellaufende Linien oder durch ein rechts offenes Rechteck miteiner Beschriftung abgebildet.

.3 ProzessEin Prozess kann eine manuelle oder eine automatisierte Aktivität sein, die ausbetrieblichen Gründen erfüllt wird. Ein Prozess transformiert Daten in einen Out-put. Prozesse sollten durch ein Substantiv und ein Verb benannt werden. JederProzess muss mindestens einen Datenfluss haben, der zu ihm hinführt, undeinen Datenfluss, der aus ihm herauskommt. Ein Prozess wird als ein Kreis oderals ein Rechteck mit abgerundeten Ecken abgebildet.

.4 DatenflussDie Bewegung von Daten zwischen einem externen Agenten, einem Prozessund einem Datenspeicher wird durch einen Datenfluss abgebildet. Der Datenflussbindet Prozesse zusammen. Jeder Datenfluss verbindet sich mit einem Prozessund zeigt den Input und Output eines Prozesses auf. Er transformiert einenInput in einen Output. Datenflüsse werden durch eine Linie mit einem Pfeilabgebildet und mit einem Substantiv beschrieben.

Datenflussdiagramme

298

Techniken

10.13.3

Abb. 10.13.3: Datenflussdiagramm in der Notation Gane-Sarson

Abb. 10.13.4: Datenflussdiagramm in der Yourdon-Notation

Bewertung

.1 Vorteile• Das Datenflussdiagramm kann sowohl als Entwurfstechnik für Prozesse und Daten als auch als Technik zur Verifizierung von Datenmodellen oder funktionalen Zerlegungen verwendet werden.

• Gut geeigneter Ansatz, um Systemgrenzen und Schnittstellen zu definie-ren. Erleichtert damit die Schätzung des erforderlichen Aufwandes.

• Für die meisten Nutzer relativ leicht zu verstehen.

Datenflussdiagramme

299

Techniken

Daten-Input

Daten-Output

Daten-Input ausübergeordnetem

Diagramm(System-Input)

Prozess 1

Bezeichnungdurch Verb /

Substantiv / Satz

1

Prozess 2

Bezeichnungdurch Verb /

Substantiv / Satz

2

Datenspeicher

Daten-Output ausübergeordnetem

Diagramm(System-Output)

Daten-Input

ExternerAgent

Verarbeitungs-prozess

Daten-Output

Daten-speicher

10.13.4

• Hilft,Redundanzen oder eine fehlerhafte Nutzung von Datenelementen zuerkennen.

• Zeigt Verbindungen zu anderen Systemen auf.• Kann als ein Element der Systemdokumentation verwendet werden.• Erleichtert das Verständnis der Logik, auf der ein Datenfluss in einem System basiert.

.2 Grenzen • Datenflussdiagramme sehr großer Systeme können sehr komplex und für die betroffenen Stakeholder schwer verständlich sein.

• Unterschiedliche Notationen mit verschiedenen Symbolen für gleiche Sachverhalte können für die Dokumentation Probleme schaffen.

• Datenflussdiagramme sagen wenig aus über die Prozesse, die Reihenfolge der Aktivitäten oder die beteiligten Stakeholder.

Data Mining

Zweck

Data Mining dient dazu, die Entscheidungsfindung zu verbessern, indem nützlicheMuster und Einsichten aus Daten gewonnen werden.

Beschreibung

Data Mining ist ein analytischer Prozess, in dem große Mengen von Daten ausunterschiedlichen Blickrichtungen untersucht und verdichtet werden, um darausnützliche Muster und Beziehungen zu erkennen.

Ergebnis des Data Minings sind normalerweise mathematische Modelle oderGleichungen, die zu grundeliegende Strukturen und Beziehungen beschreiben.Diese Modelle können für die menschliche Entscheidungsfindung mithilfe vonDashboards oder als Berichte zur Verfügung gestellt oder für die automatisierteEntscheidungsfindung durch Geschäftsregeln genutzt werden.

Data Mining kann sowohl in kontrollierten wie auch in nicht-kontrolliertenRecherchen genutzt werden. Bei einer kontrollierten Recherche können dieAnwender eine Frage stellen, um eine Antwort für ihre Entscheidungsfindungzu erhalten. In einer nicht-kontrollierten Untersuchung werden die ermitteltenMuster direkt als Entscheidungsgrundlage verwendet.

Data Mining

300

Techniken

10.14

10.14.1

10.14.2

Data Mining umfasst sowohl beschreibende als auch diagnostische und vorher-sagende Techniken:• Beschreibend: Durch die Gruppierung von Daten werden Muster sicht-bar wie beispielsweise Ähnlichkeiten zwischen bestimmten Kunden-gruppen.

• Diagnostisch: Zur Diagnose können Entscheidungsbäume ebenso bei-tragen wie Segmentierungen der Daten, beispielsweise die Ermittlung typischer Merkmale besonders profitabler Kunden.

• Vorhersagend: Regressionsanalysen oder neurale Netzwerke können zeigen, wie wahrscheinlich ein bestimmtes Ereignis in der Zukunft auf-tritt, wie z. B. die Möglichkeit der Insolvenz bei einer bestimmten Kundengruppe.

In allen Fällen ist es besonders wichtig, immer das Ziel des Data Mining im Augezu behalten und darauf vorbereitet zu sein, dass es erheblichen Aufwand verur-sachen kann, die relevanten Informationen und den benötigten Umfang zubestimmen, um die gewünschte Qualität gewährleisten zu können.

Elemente

.1 AnforderungsermittlungZiel und Umfang des Data Mining leiten sich entweder aus den Anforderungenfür eine wichtige betriebliche Entscheidung ab oder aus dem Bedarf einer funk-tionalen Einheit, die bereichsspezifische Informationen benötigt. Ein Top-Down-oder ein Bottom-Up-Ansatz des Data Mining gibt Hinweise auf die sinnvoll anzu-wendenden Techniken.

Formale Techniken zur Modellierung von Entscheidungen (siehe Entscheidungs-modellierung, Kap. 10.16) werden genutzt, um die Anforderungen für einenTop-Down-Ansatz zu ermitteln. Für Bottom-Up-Ansätze zur Mustererkennungist es hilfreich, wenn die gewünschten Ergebnisse über bereits bestehende Ent-scheidungsmodelle gewonnen werden können.

Data-Mining-Vorhaben sind in einer agilen Umgebung besonders erfolgverspre-chend. Sie unterstützen schnelle Iterationen, Bestätigungen und Nutzung vonErgebnissen in einem kontrollierten Projektablauf.

.2 Datenvorbereitung: Datenbestand zur AnalyseDie Werkzeuge zum Data Mining basieren auf einem Datenbestand, der zurAnalyse genutzt wird. Dieser Datenbestand wird normalerweise aus unterschied-lichen Quellen gespeist. Diese Daten können entweder physisch extrahiert undin eine Datei übertragen werden oder es handelt sich um virtuelle Dateien, diein einer Datenbank oder einem Data Warehouse belassen und dort direkt genutzt

Data Mining

301

Techniken

10.14.3

werden. Analytische Datenbestände gliedern sich in einen Bestand, der für dieAnalyse genutzt wird, einen davon völlig unabhängigen Bestand, der dem Beweisdient, dass das Modell auch für Daten gilt, die nicht in der Entwicklung verwendetwurden, und in einen Datenbestand für die abschließende Validierung. Da dierelevanten Datenbestände sehr groß sein können, kann es auch notwendig sein,mit Stichproben oder direkt innerhalb von Datenbanken zu arbeiten, ohne großeDatenmengen zu bewegen.

.3 DatenanalyseSobald die Daten vorliegen, werden sie analysiert. Dazu stehen eine großeAnzahl unterschiedlicher statistischer Verfahren sowie Techniken zur Visualisierungder Ergebnisse zur Verfügung, mit deren Hilfe die Verteilung der Werte sichtbarwird. Auch kann veranschaulicht werden, welche Daten fehlen und wie sichbestimmte Merkmale verhalten. Das ist der zeitaufwändigste und komplexesteSchritt des Data Mining, für den auch eine automatisierte Unterstützung ange-boten wird. Ergebnisse des Data Mining sind normalerweise dann besonderswertvoll, wenn nützliche Merkmale identifiziert werden. So kann zum Beispieldie Anzahl der Besuche eines Kunden in den letzten 80 Tagen ein besonderswichtiges Merkmal für dessen zukünftige Nachfrage sein.

.4 ModellierungstechnikenEs gibt ein breites Spektrum von Techniken zum Data Mining. Einige Beispieledafür sind:• Classification and Regression Trees (CART), C5 oder andere Entschei-dungsbaum-Techniken

• Lineare und logistische Regression• Neurale Netzwerke• Support Sector Machines• Scorecards zur Vorhersage (Predictive Scorecards).

Der Datenbestand zur Analyse und die verwendeten Merkmale werden in dieseAlgorithmen eingegeben, die entweder selbstständig (der Anwender weiß nicht,wonach die Algorithmen suchen) oder kontrolliert arbeiten (der Anwender suchtgezielt ein Ergebnis oder sagt ein Ergebnis voraus). Häufig werden mehrereTechniken eingesetzt, um herauszufinden, welche besonders wirksam ist. EinigeDaten fließen nicht in die Modellierung ein, sie werden lediglich für die Bestäti-gung benötigt, dass ein Ergebnis mit Daten, die ursprünglich nicht genutzt wur-den, wiederholt werden kann.

.5 EinsatzNachdem ein Modell entwickelt wurde, muss es eingesetzt werden, um Nutzenzu bringen. Data-Mining-Modelle können in unterschiedlichster Art und Weise

Data Mining

302

Techniken

genutzt werden. Sie unterstützen entweder eine menschliche Entscheidung oderfließen in automatisierte Entscheidungssysteme ein. Für die menschlichen Nutzerkönnen die Ergebnisse des Data Mining bildlich aufbereitet oder als reine Datenzur Verfügung gestellt werden. Viele Techniken des Data Mining leiten möglicheGeschäftsregeln ab, die in Regelsysteme integriert werden können. Solche aus-führbaren Entscheidungsregeln können bei Bedarf zusammen mit Expertenregelnin Entscheidungsmodelle eingebaut werden. Einige Techniken des Data Mining– besonders solche, die als Vorhersagetechniken bezeichnet werden – führenzu mathematischen Formeln, die als ausführungsreife Geschäftsregeln genutztoder zu SQL-Befehlen umgewandelt werden können. Eine zunehmende Anzahlvon Ansätzen, die innerhalb von Datenbanken genutzt werden können, erleichterndie Integration solcher Modelle in die Daten-Infrastruktur eines Unternehmens.

Bewertung

.1 Stärken• Data Mining macht verborgene Strukturen sichtbar und eröffnet wertvolleEinsichten durch die Analyse – so kann leichter festgelegt werden, welcheDaten gesammelt werden sollten oder wie viele Menschen von bestimm-ten Vorschlägen betroffen sein werden.

• Kann in einen Systementwurf integriert werden, um die Korrektheit der Daten zu steigern.

• Kann dabei helfen, menschliche Fehleinschätzung zu korrigieren, indem die tatsächlichen Werte berücksichtigt werden.

.2 Grenzen• Werden Techniken genutzt, ohne deren Funktionsweise verstanden zu haben, kann das zu fehlerhaften Schlüssen führen.

• Umfangreiche Datenbestände und hochentwickelte Werkzeuge können zu einer missbräuchlichen Nutzung (ver-)führen.

• Viele Techniken und Werkzeuge erfordern für ihre Nutzung Spezialisten.• Einige Techniken basieren auf hochentwickelten mathematischen Ansät-zen, so dass einige Stakeholder unter Umständen die Ergebnisse nicht nachvollziehen können. Das kann zu fehlender Akzeptanz der Ergebnisse führen.

• Es kann schwierig sein, die Ergebnisse des Data Mining zu nutzen, wenn die Entscheidungsprozesse, für die sie erarbeitet wurden, nicht verstan-den worden sind.

Data Mining

303

Techniken

10.14.4

Datenmodellierung

Zweck

Ein Datenmodell beschreibt die Entitäten, Klassen oder Datenobjekte, die fürein Fachgebiet relevant sind, dazu deren Attribute, um sie zu beschreiben, unddie Beziehungen zwischen ihnen, um damit die Bedeutung der Begriffe fürAnalyse und Umsetzung eindeutig zu machen.

Beschreibung

Ein Datenmodell wird normalerweise in der Form eines Diagramms dargestellt,das durch textliche Beschreibungen ergänzt wird. Es zeigt die Elemente, die fürdas Geschäft wichtig sind (z.B. Menschen, Orte, Dinge, Transaktionen), die zuge-hörigen Attribute und die wichtigsten Beziehungen zwischen den Elementen.Datenmodelle werden häufig in der Erhebung, zur Analyse und zum Design derAnforderungen verwendet. Sie unterstützen aber auch die Einführung und diekontinuierliche Verbesserung von Anwendungen.

Es gibt mehrere Varianten von Datenmodellen:• Konzeptionelles Datenmodell: Es ist unabhängig von einer Lösung oder einer Technologie und kann zeigen, wie ein Unternehmen seine Informationen wahrnimmt. Es kann dazu genutzt werden, eine kon-sistente Begriffswelt zu schaffen, die alle relevanten Begriffe umfasst und zueinander in Beziehung setzt.

• Logisches Datenmodell: Ist eine Abstraktion des konzeptionellen Datenmodells, indem die Regeln der Datennormalisierung umgesetzt wurden, um formal die Integrität der Daten und der Beziehungen sicherzustellen. Das logische Datenmodell wird zum Entwurf einer Lösung benötigt.

• Physisches Datenmodell: Wird von den Experten für die Einführung verwendet, um damit zu beschreiben, wie eine Datenbank physisch organisiert ist. Dabei geht es im Wesentlichen um Performance, Abstimmung und Sicherheit.

Konzeptionelles, logisches und physisches Datenmodell werden somit für unter-schiedliche Zwecksetzungen erarbeitet und können sich stark voneinander unter-scheiden, selbst wenn sie dieselbe Domain betreffen.

Auf einer konzeptionellen Ebene führen selbst sehr unterschiedliche Notationender Datenmodellierung zu ähnlichen Ergebnissen und können somit wie eineeinzige Technik (so wie sie hier dargestellt wird) angesehen werden. Logische undphysische Datenmodelle enthalten spezifische Elemente, die stärker von den Lösun-gen abhängen, die mit ihnen erarbeitet wurden, und werden meistens von Stake-

Datenmodellierung

304

Techniken

10.15.1

10.15.2

10.15

holdern erstellt, die Experten für bestimmte technische Lösungen sind. So werdenbeispielsweise logische und physische Entity-Relationship-Diagramme eingesetzt,um eine relationale Datenbank einzuführen, wohingegen logische oder physischeKlassendiagramme genutzt werden, um die objektorientierte Software-Entwicklungzu unterstützen.

Objektdiagramme können dazu verwendet werden, bestimmte Instanzen vonEntitäten aus einem Datenmodell darzustellen, u.U. einschließlich ausgewählterBeispiele für Werte von Attributen, die solche Objektdiagramme konkreter undbesser verständlich machen.

Elemente

.1 Entität oder KlasseIn ein Datenmodell fließen Daten über Entitäten (oder Klassen oder Datenobjekte)ein. Eine Entität kann etwas Physisches repräsentieren (wie z.B. ein Kaufhaus),etwas Organisatorisches (wie z.B. den Verkaufsbereich), etwas Abstraktes (wiez.B. eine Produktlinie) oder ein Ereignis (wie z.B. eine Verabredung). Eine Entitätbesitzt Attribute und hat Beziehungen zu anderen Entitäten des Modells.

In einem Klassendiagramm werden Entitäten als Klassen bezeichnet. Ebensowie eine Entität in einem Datenmodell, enthält eine Klasse Attribute und besitztBeziehungen zu anderen Klassen. Zu einer Klasse gehören auch Operationenoder Funktionen, die beschreiben, was mit der Klasse gemacht werden kann,wie z.B. eine Rechnung schreiben oder ein Konto eröffnen.

Jede Art einer Entität oder einer Klasse besitzt ein Bestimmungsmerkmal, dassie unterscheidbar macht von anderen.

.2 AttributeEin Attribut definiert eine bestimmte Information, die mit der Entität verbundenist, einschließlich der Aussage, wie viel Information sie enthalten kann, welcheWerte sie annehmen kann und um welchen Informationstyp es sich handelt.Attribute können in einem Data Dictionary beschrieben werden (siehe DataDictionary, Kap. 10.12). Die zulässigen Werte können durch Geschäftsregelnspezifiziert werden (siehe Analyse der Geschäftsregeln, Kap. 10.9).

Attribute können beispielsweise folgende Werte sein:• Name: Eine eindeutige Bezeichnung für das Attribut. Andere Bezeich-nungen, die von Stakeholdern verwendet werden, sollten als „Alias“ dokumentiert werden.

• Werte/Bedeutungen: Z.B. eine Liste der erlaubten Werte, die das Attribut einnehmen darf.

• Beschreibung: Definition des Attributs im Zusammenhang mit der Lösung.

Datenmodellierung

305

Techniken

10.15.3

.3 Beziehung oder ZuordnungDie Beziehungen zwischen den Entitäten bringen Struktur in ein Datenmodell,indem sie zeigen, welche Entitäten wie mit anderen Entitäten zusammenhängen.Zu den Spezifikationen der Beziehungen gehören auch Aussagen darüber, wieviele davon auf beiden Seiten mindestens vorkommen müssen oder maximalvorkommen dürfen (z.B. jeder Kunde gehört zu einem Verkaufsgebiet, währendein Verkaufsgebiet zu null, einem, zwei oder vielen Kunden Beziehungen habenkann). Der Begriff „Kardinalität“ wird verwendet, wenn ein Minimum und einMaximum angegeben wird für die Werte, die eine Beziehung annehmen kann.Typische Werte für die Kardinalität sind 0, 1 und viele.

Die Beziehung zwischen zwei Entitäten kann in eine Richtung gelesen werden,wie z.B.:

Jeder Fall (dieser Entität) hat (mindestens, maximal) Beziehungen (zu dieser bestimmten Entität).

In einem Klassenmodell wird der Begriff Assoziation anstelle von Beziehung ver-wendet und Multiplizität anstelle von Kardinalität.

.4 DiagrammeSowohl die Datenmodelle als auch die Klassenmodelle können in einem odermehreren Diagrammen dargestellt werden, die Entitäten, Attribute und Bezie-hungen zeigen.

Das Diagramm eines Datenmodells wird Entity-Relationship-Diagramm (ERD)genannt. In einem Klassenmodell wird das Diagramm ein Klassendiagrammgenannt.

Datenmodellierung

306

Techniken

Abb. 10.15.1: Entity-Relationship-Diagramm (Crow’s Food Notation)

Datenmodellierung

307

Techniken

Entität 1

Attribut

Entität 2

Attribut

Entität 3

Attribut 1

Attribut 2

Primärschlüssel

Entität 4

Attribut

Beziehung rechts nach links

Beziehung links nach rechts

Jede Entität wird als Rechteck mit dem Namen der Entitätdargestellt.

Der Primärschlüssel der Entität wird unterdem Entitätsnamen angezeigt.

Beziehungen werden durch eine Linie dargestellt, die zum Anzeigen der Kardinalität mit einem Symbol versehen wird.

Entität Entität Entität Entität

Die Attribute derEntität werden unter dem Primärschlüsselangeführt.

Kardinalität

Beliebige Anzahl(0:n)

0:1 1 Beliebige Anzahl(1:n)

Primärschlüssel Primärschlüssel

Primärschlüssel

Abb. 10.15.2: Klassendiagramm (UML®)

.5 Metadaten Ein Datenmodell kann zusätzlich Metadaten beinhalten, welche die Entitätenbeschreiben. Zusätzliche Angaben können sein, wann und warum die Entitätgeschaffen oder verändert wurde, wie sie genutzt werden soll, wie oft siegenutzt wird, wann und durch wen. Auch könnten Restriktionen hinsichtlichihrer Schaffung oder ihres Gebrauchs genannt werden oder auch Restriktionen,die sich aus Sicherheitsanforderungen, dem Schutz der Privatsphäre oder derAuditierung ableiten und einzelne oder ganze Gruppen von Entitäten betreffen.

Bewertung

.1 Stärken• Datenmodelle können verwendet werden, um konsistente Begriffe zu definieren und bekanntzumachen, die von den Experten des Fachbereichsund von den Fachleuten für die Einführung benutzt werden.

Datenmodellierung

308

Techniken

Klasse 1

Attribut 1: Datentyp

Klasse 2

Attribut 1Attribut 2Attribut 3Attribut 4

Hier wird der Name der Klasseaufgeführt. Er kann möglicher-weise ein Stereotyp sein, derweitere Eigenschaften beschreibt.

Beziehungen werden durcheine Linie dargestellt, dieauch die Multiplizität anzeigenkann.

<<Stereotyp>>

0 …*

Operation 1Operation 2Operation 3

1

Die Attribute einer Klassewerden in dem Feld unter demNamen aufgeführt, die Opera-tionen ein Feld darunter.

Klasse Klasse Klasse Klasse

Multiplizität


Muss exaktX sein

Beliebige Anzahlvon X bis Y


* X X ... Y 1 ...*

Attribut 2: Datentyp

10.15.4

• Überprüfung der Datenmodelle hilft, sicherzustellen, dass das logische Design der Daten den betrieblichen Bedarf auch richtig trifft.

• Bieten einen konsistenten Ansatz, um Daten und Beziehungen zu analy-sieren und zu dokumentieren

• Sind insofern flexibel, als jeder beliebige Detaillierungsgrad gewählt werdenkann, der den Anforderungen der jeweiligen Zielgruppe gerecht wird.

• Die formale Modellierung der Informationen kann zusätzliche Anforde-rungen hervorbringen, falls Inkonsistenzen festgestellt werden.

.2 Grenzen• Werden die Modellierungsstandards zu sklavisch angewendet, können dabei Modelle herauskommen, welche für Menschen ohne IT-Hintergrundwenig geeignet sind.

• Die Modelle können über mehrere funktionale Einheiten hinwegreichen und damit das Verständnis individueller Stakeholder überfordern.

Entscheidungsanalyse

Zweck

Die Entscheidungsanalyse untersucht formal ein Problem und mögliche Ent-scheidungen zur Problemlösung, um den Wert alternativer Ergebnisse unter denBedingungen von Unsicherheit zu ermitteln.

Beschreibung

Die Entscheidungsanalyse untersucht und modelliert mögliche Folgen von Ent-scheidungen zu einem bestimmten Problem. Eine Entscheidung ist die Auswahleiner bestimmten Handlungsoption aus mehreren Optionen, die mit unterschied-lichen Wahrscheinlichkeiten zu unterschiedlichen Werten führen. Der Ergebniswertkann – abhängig von dem jeweiligen Bereich und den verwendeten Bewer-tungskriterien – unterschiedlich aussehen. Häufig sind es finanzielle Werte,Punktwerte oder Rangfolgen.

Entscheidungen sind oft schwer zu fällen, insbesondere wenn• das Problem schlecht beschrieben ist• die Maßnahmen, die zu einem bestimmten Ergebnis führen sollen, nicht voll verstanden werden

• unklar ist, welche externen Faktoren die Entscheidung beeinflussen


309

Techniken

10.16

10.16.1

10.16.2

• die betroffenen Stakeholder sich über den Wert unterschiedlicher Ergebnisse nicht einig sind oder wenn die Ergebnisse nicht direkt mit-einander verglichen werden können.

Die Entscheidungsanalyse hilft dem Business-Analysten, unterschiedliche Ergeb-niswerte unter der Bedingung von Unsicherheit oder in sehr komplexen Situa-tionen zu beurteilen. Dazu stehen verschiedene Verfahren zur Verfügung. DieEignung eines Verfahrens hängt vom Grad der Unsicherheit, von Risiken, Qualitätder Informationen und der Verfügbarkeit von Bewertungskriterien ab.

Eine gute Entscheidungsanalyse setzt voraus, dass die folgenden Punkte ver-standen wurden:• die für die jeweilige Entscheidungssituation relevanten Werte und Ziele• die Art der Entscheidung, die gefällt werden muss.• Unsicherheiten, die auf diese Entscheidung Einfluss haben• Folgen jeder möglichen Entscheidung.

Zu einer Entscheidungsanalyse gehören die folgenden Aktivitäten:1. Definition des Problems: Eindeutige Beschreibung der vorliegenden Entscheidungssituation.

2. Ermittlung von Alternativen: Identifizierung von möglichen Vorschlägenoder Handlungswegen.

3. Bewertung von Alternativen: Bestimmung eines formalen Vorgehens zur Bewertung der Alternativen. Zu Beginn dieses Schrittes sollte auchEinvernehmen über die Bewertungskriterien hergestellt werden.

4. Auswahl einer Alternative: Auf der Grundlage der Ergebnisse der Bewertung entscheiden die dazu befugten Personen, welche Variantegewählt werden soll.

5. Einführung: Die ausgewählte Variante wird umgesetzt.

Dem Business-Analysten und Entscheidungsberechtigten steht eine ganze Reihevon Techniken zur Entscheidungsanalyse zur Verfügung. Einige Techniken eignensich besonders, um zwischen zwei Varianten zu unterscheiden, andere könnenauch für mehrere Varianten benutzt werden.

Beispiele für Techniken zur Entscheidungsanalyse:• Pro-und-Contra-Spiel• Kraftfeldanalyse• Entscheidungstabellen• Entscheidungsbäume• Vergleichende Analyse• Analytischer Hierarchieprozess (Analytical Hierarchy Process) (AHP)


310

Techniken

• Totally-Partially-Not (TPN)• Nutzwertanalyse (Multi-Criteria Decision Analysis)• Computerunterstützte Simulation und Algorithmen.

Elemente

.1 Komponenten der EntscheidungsanalyseZu den allgemeinen Komponenten der Entscheidungsanalyse gehören:• Zu fällende Entscheidung oder Problembeschreibung: Beschreibung der Entscheidungssituation oder des zu lösenden Problems.

• Entscheider: Person oder Personengruppe, die für die letzte Entschei-dung zuständig ist.

• Variante: Möglicher Vorschlag oder Handlungsweg.• Entscheidungskriterien: Geeignete Merkmale für die Bewertung der Varianten.

.2 Entscheidungsmatrix Die beiden folgenden Tabellen zeigen Beispiele für eine einfache Entscheidungs-matrix und für eine gewichtete Entscheidungsmatrix.

Eine einfache Entscheidungsmatrix prüft, ob eine Alternative die gewählten Kri-terien erfüllt oder nicht und zeigt dann auf, in wie vielen Fällen ein Kriteriumerfüllt wird. In diesem Beispiel wäre die Variante 1 am besten geeignet.

(n/a = nicht erfüllt)Tabelle 10.16.1: Einfache Entscheidungsmatrix

In einer gewichteten Entscheidungsmatrix beruht die Bewertung auf mehrerenKriterien, deren Bedeutung durch ihr Gewicht gekennzeichnet wird. Je größerdieses Gewicht ist, desto größer ist die Bedeutung dieses Kriteriums. In diesem


311

Techniken

Variante 1 Variante 2 Variante 3

Kriterium 1 Erfüllt n/a n/a

Kriterium 2 Erfüllt Erfüllt Erfüllt

Kriterium 3 Erfüllt Erfüllt

Kriterium 4 Erfüllt n/a n/a

Ergebnis 3 2 2

10.16.2

Beispiel werden die Gewichte im Bereich von 1-5 vergeben, wobei 5 für diehöchste Bedeutung steht. Die Varianten erhalten „Noten“ von 1-5, je nachdemwie gut sie diese Kriterien erfüllen. Dann werden die Gewichte mit den Bewer-tungspunkten multipliziert und die Summe der Werte addiert. Die Variante mitder höchsten Punktzahl dürfte dann ausgewählt werden.

Tabelle 10.16.2: Gewichtete Entscheidungsmatrix

.3 EntscheidungsbäumeEin Entscheidungsbaum dient einer Bewertung, wenn es mehrere Quellen derUnsicherheit gibt. Ein Entscheidungsbaum gibt Hilfen bei der Frage, welcheLösungsoptionen in Abhängigkeit von der gewählten Strategie geeignet sind.

Weitere Informationen über Entscheidungsbäume finden sich im Kapitel 10.17„Entscheidungsmodellierung“.

.4 AbwägungEine Abwägung wird wichtig, wenn in einer Entscheidungssituation mehrereZiele berücksichtigt werden, von denen einige unter Umständen miteinander inKonflikt stehen. Wenn sich solche Ziele gegenseitig behindern, reicht es nicht,einfach einen Wert zu ermitteln, etwa die Variante mit dem höchsten Gewinn.Mögliche Ansätze in solchen Situationen können sein:• Ausschluss unterlegener Varianten: Eine unterlegene Variante ist eine mögliche Option, die jedoch im Vergleich mit einer oder mehreren anderen Varianten deutlich abfällt. So kann eine Variante beispiels-weise unterlegen sein, weil sie wenige Vorteile, dafür aber markante Nachteile hat.

• Nutzwertanalyse: Eine Nutzwertanalyse ist ein quantitatives Bewertungs-verfahren zur Ermittlung der Vorteilhaftigkeit von Alternativen, in dem die Zielerreichung für die gewichteten Ziele (Kriterien) zu einem Wert verdichtet wird.


312

Techniken

Kriterien-gewichtung

Variante 1 WertVariante 1



Kriterium 1 1 Rang=1* 3 Rang=1* 5 Rang=1* 2




GewichtetesErgebnis

28 37 40

Bewertung

.1 Stärken• Entscheidungsanalysen bieten Vorgehensweisen, um Lösungsvarianten auch in komplexen Situationen oder unter Unsicherheit zu bewerten.

• Helfen den Stakeholdern, Entscheidungen unter bewusster Berücksichti-gung von Kriterien zu fällen und nicht nur auf der Basis von Beschreibun-gen und Emotionen.

• Zwingt die Stakeholder, die Bedeutung alternativer Ergebnisse zu bewerten.• Ermöglicht die Nutzung geeigneter quantitativer Verfahren oder relativer Rankings, um die Lösungen sowohl nach finanziellen als auch nach nicht-finanziellen Kriterien zu bewerten.

.2 Grenzen• Möglicherweise stehen die für eine Entscheidungsanalyse notwendigen Informationen nicht rechtzeitig zur Verfügung.

• Viele Entscheidungen müssen sehr schnell gefällt werden, für einen formellen Entscheidungsprozess fehlt dann u.U. die Zeit.

• Entscheider müssen die notwendigen Informationen (z.B. über Ziele und Kriterien) bereitstellen und die zugrundeliegenden Annahmen und Grenzender verwendeten Verfahren kennen. Andernfalls besteht die Gefahr, dass sie die Ergebnisse als sicherer einschätzen als sie tatsächlich sind.

• Es kann sich „Paralyse durch Analyse“ einstellen, wenn zu viel Zeit und Energie in die Entscheidungsfindung und die Bestimmung von Wahrschein-lichkeitswerten gesteckt wird.

• Einige Verfahren erfordern Spezialwissen (z.B. über Mathematik und Wahrscheinlichkeitstheorie).

Entscheidungsmodellierung

ZweckEntscheidungsmodellierung zeigt, wie wiederkehrende Entscheidungen gefälltwerden.

BeschreibungEntscheidungsmodelle machen sichtbar, wie Daten und Wissen miteinander kom-biniert werden, um zu einer bestimmten Entscheidung zu kommen. Modelle können


313

Techniken

10.16.4

10.17

10.17.2

10.17.1

sowohl für einfache als auch für komplexe Entscheidungen eingesetzt werden. Ein-fache Entscheidungsmodelle benutzen für eine Entscheidung eine einzige Entschei-dungsmatrix oder einen Entscheidungsbaum, um zu zeigen, wie eine Gruppe vonGeschäftsregeln zusammenspielt. Komplexe Entscheidungsmodelle zerlegen Ent-scheidungen in einzelne Komponenten, so dass jede Teilentscheidung getrenntbeschrieben werden kann. Das Modell zeigt dann, wie diese einzelnen Elemente zueiner Gesamtentscheidung zusammengefügt werden, sowie die für eine Entscheidungoder eine Teilentscheidung benötigten Informationen. Jede Teilentscheidung wirddurch die Geschäftsregeln beschrieben, die für diese Teilentscheidung relevant sind.

Ein umfassendes Entscheidungsmodell ist ganzheitlich und stellt Verbindungenzu Prozessen, Leistungsmaßstäben und Organisationen her. Es zeigt, woher dieGeschäftsregeln stammen, und basiert auf analytischer Klarheit.

Für eine konkrete Entscheidung können die Geschäftsregeln definitorisch seinoder das Verhalten regeln. So kann beispielsweise die Regel „Validiere Auftrag“bedeuten, dass geprüft wird, ob der Steuerbetrag richtig berechnet wurde (einedefinitorische Regel) und ob die Rechnungsadresse zu der benutzten Kreditkartepasst (eine Verhaltensregel).

Entscheidungstabellen und Entscheidungsbäume legen fest, wie eine spezifischeEntscheidung gefällt wird. Für unterschiedliche Detaillierungsebenen kann auchjeweils ein grafisches Entscheidungsmodell entwickelt werden. Auf einer über-geordneten Ebene kann beispielsweise lediglich dargestellt werden, an welchenStellen Entscheidungen zu fällen sind, wohingegen auf einer detaillierten Ebenedas Modell die Ist- oder Soll-Entscheidungsfindung so detailliert aufzeigen kann,dass sie als Struktur für alle relevanten Geschäftsregeln genutzt werden kann.

Elemente

.1 Modelltypen und NotationenEs gibt viele verschiedene Ansätze der Entscheidungsmodellierung. Entschei-dungstabellen zeigen die Regeln auf, die für eine Detailentscheidung benötigtwerden. Entscheidungsbäume werden in einigen Wirtschaftsbereichen genutzt,finden sich aber wesentlich seltener als Entscheidungstabellen. Komplexe Ent-scheidungen erfordern eine Kombination vieler einfacher Entscheidungen ineinem Netzwerk. Alle diese Ansätze beinhalten drei Schlüsselelemente: • Entscheidung• Information• Wissen.

Entscheidungstabellen

In betriebliche Entscheidungen fließt ein ganzer Satz von Eingangswerten ein.Anhand bestimmter Geschäftsregeln wird aus mehreren möglichen Ergebnissen


314

Techniken

10.17.3

ein Ergebnis ausgewählt. Eine Entscheidungstabelle ist eine kompakte tabellarischeDarstellung der betreffenden Regeln. Jede Zeile beinhaltet eine Regel und in denSpalten werden die möglichen Bedingungen dieser Regel aufgelistet. Am Ende derZeile findet sich dann die Entscheidung, die unter den vorgegebenen Bedingungengefällt wird. Entscheidungstabellen enthalten normalerweise eine oder mehrereBedingungspalten mit bestimmten Datenelementen sowie eine oder mehrereSpalten, die Aktionen oder Ergebnisse beinhalten. Jede Zeile einer Entschei-dungstabelle stellt eine Entscheidungsregel dar. Wenn alle Zellen einer Regelentweder zutreffend oder „blank“(irrelevant) sind, kommt diese Regel zumtragen, womit die Entscheidung gefällt ist.

Tabelle 10.17.1: Entscheidungstabelle

Entscheidungsbäume

Entscheidungsbäume bilden ebenfalls einen Satz von Entscheidungsregeln ab.Jeder Pfad eines Entscheidungsbaums führt zu einer Entscheidung. Jede Ebenedes Baums repräsentiert ein bestimmtes Datenelement. In Flussrichtung werdendie unterschiedlichen Bedingungen genannt, die erfüllt sein müssen, um fortzu-fahren. Entscheidungsbäume können ein sehr wirksamer Ansatz sein, umbestimmte Gruppen von Regeln darzustellen, insbesondere wenn es darumgeht, Kundensegmente zu bilden.

Ein Entscheidungsbaum bestimmt ebenso wie eine Entscheidungstabelle eineAktion oder ein Ergebnis aufgrund der vorliegenden Bedingungen.

In dem folgenden Entscheidungsbaum teilen sich die Regeln die Bedingungender vorgehenden Zerlegungsebene.


315

Techniken

Kreditbetrag

<=1000

Regeln für Berechtigung

Alter Berechtigung

>18 berechtigt

1000–2000>21 berechtigt

>2000>=25 berechtigt

<=18 nicht berechtigt

<=21 nicht berechtigt

<25 nicht berechtigt

Abb. 10.17.2: Entscheidungsbaum

Entscheidungs-Anforderungs-Diagramm

Ein Entscheidungs-Anforderungs-Diagramm ist eine grafische Darstellung derInformation, des Wissens und der Entscheidungen, die in eine komplexe betrieb-liche Entscheidung einfließen.

Entscheidungs-Anforderungs-Diagramme enthalten die folgenden Elemente:• Entscheidungen: Sie werden als Rechtecke dargestellt. In jede Entschei-dung geht ein ganzer Satz von Eingangsgrößen ein. Mit der Entschei-dung wird aus einer Anzahl möglicher Ergebnisse ein Ergebnis gemäß den Entscheidungsregeln ausgewählt.

• Eingangsdaten: Sie werden als Oval dargestellt und zeigen die Daten, die für die Entscheidung benötigt werden.

• Modell betrieblichen Wissens: Wird als Rechteck mit abgeschnittenen Ecken dargestellt und beinhaltet Gruppen von Geschäftsregeln, Ent-scheidungstabellen, Entscheidungsbäume oder auch analytische Vor-hersagemodelle, die angeben, wie eine Entscheidung zu fällen ist.

• Wissensquelle: Wird in der Form eines Dokuments dargestellt und beschreibt die Originalquelle (z.B. Dokument oder Person), aus der die benötigte Entscheidungslogik abgeleitet werden kann oder abgeleitet wurde.

Diese Elemente werden zu einem Netzwerk verbunden und zeigen die einzelnenBausteine, aus denen sich komplexe Entscheidungen zusammensetzen. Durch-


316

Techniken

Alter

Nicht berechtigt

Berechtigt

<=18

> 18

Alter

Nicht berechtigt

Berechtigt

<=21

> 21

Alter

Nicht berechtigt

Berechtigt

< 25

>=25

1000-2000

<=1000

> 2000

Betrag

gehende Linien zeigen die für eine Entscheidung benötigten Informationen. Sowerden die benötigten Informationen mit einer Entscheidung oder auch zweiEntscheidungen miteinander verbunden.

Modelle betrieblichen Wissens, mit denen beschrieben wird, wie eine spezifischeEntscheidung zu fällen ist, können durch eine gestrichelte Linie mit der Ent-scheidung verbunden werden und zeigen, welche Anforderungen die Entschei-dung in dieser Hinsicht benötigt. Wissensquellen werden ebenfalls durch einegestrichelte Linie, die in einem Kreis endet, mit der Entscheidung verbunden.Sie zeigen, dass die Quelle (zum Beispiel ein Dokument oder eine Person) fürdiese Entscheidung Befugnisse besitzt. Das wird eine Autorisierungsanforderung(authority requirement) genannt.

Abb. 10.17.3: Entscheidungs-Anforderungs-Diagramm

Bewertung

.1 Stärken • Entscheidungsmodelle sind ein gutes Kommunikationsinstrument, fördernein gemeinsames Verständnis und unterstützen die Analyse von Einflüssenauf eine Entscheidung.

• Viele Perspektiven können einfließen und miteinander kombiniert werden, insbesondere wenn ein Diagramm genutzt wird.

• Vereinfachen komplexe Entscheidungen, indem das Management der Geschäftsregeln vom Prozess getrennt wird.

• Unterstützen die Handhabung auch großer Mengen von Geschäfts-regeln in Entscheidungstabellen.


317

Techniken

Daten-Input

Entscheidung

EntscheidungModell betrieb-lichen Wissens

Wissensquelle

Daten-Input

Modell betrieb-lichen Wissens

10.17.4

• Unterstützen die Automatisierung von Regeln, das Data Mining und prognostische Analysen wie auch nicht-automatisierte Entscheidungen oder Projekte zur Business Intelligence.

.2 Grenzen• Entscheidungsmodelle bringen eine weitere Art von Diagrammen in die Modellierung von Geschäftsprozessen. Das kann zu unnötiger Komplexität führen, falls die Entscheidungen einfach und in den Prozess eingebunden sind.

• Können dazu führen, dass nur bestimmte Regeln für eine Entscheidung alsrelevant angesehen werden und andere gar nicht weitergesucht werden.

• Fördern die Annahme, dass es nur diesen einen Standard gibt, der aber unter Umständen nicht für alle Fälle passt. Das kann dazu führen, dass ein Unternehmen in einem Ist-Zustand verharrt.

• Erfordern oft die Einwilligung mehrerer betrieblicher Bereiche, was es schwierig machen kann, zu einer Lösung zu kommen.

• Decken unter Umständen Verhaltensregeln nicht ausreichend mit ab.• Erfordern eine klare und gemeinsam getragene betriebliche Terminologie, da sich andernfalls insbesondere bei der Automatisierung Qualitätspro-bleme ergeben können.

Dokumentenanalyse

Zweck

Die Dokumentenanalyse dient der Erhebung von Informationen zur Business-Analyse durch das Studium bereits vorhandener Unterlagen über relevantebetriebliche oder außerbetriebliche Sachverhalte.

Beschreibung

Die Dokumentenanalyse kann dazu verwendet werden, um Hintergrundinforma-tionen zum besseren Verständnis eines betrieblichen Bedarfs zu sammeln oder umbestehende Lösungen zu verstehen und zu bewerten. Die Dokumentenanalysekann auch dazu verwendet werden, um Interviews und Beobachtungen zu validieren.Data Mining (siehe Kap. 10.14) kann ebenfalls zur Dokumentenanalyse gezähltwerden, wenn es beispielsweise darum geht, aus bestehenden DatenbeständenStrukturen zu ermitteln oder Daten zu ordnen, um so Ansätze für Veränderungenzu finden. Zweck, Umfang und Gegenstand der Erhebung hängen von den jeweils

Dokumentenanalyse

318

Techniken

10.18

10.18.1

10.18.2

benötigten Informationen ab. Bei einer Dokumentenanalyse sichtet der Business-Analyst planmäßig die Unterlagen und entscheidet, welche Ergebnisse davon fest-gehalten werden.

Zu den Hintergrundinformationen, die durch eine Dokumentenanalyse erhobenwerden, gehören beispielsweise Marketing-Studien, Richtlinien und betrieblicheStandards sowie Protokolle und Organigramme. Durch das Studium einer Vielzahlunterschiedlicher Quellen kann der Business-Analyst sicherstellen, dass ein Bedarfim Gesamtzusammenhang richtig verstanden wird. Die Erhebung bereits beste-hender Lösungen kann Geschäftsregeln, technische Dokumentationen, Trai-ningsunterlagen, Problemberichte, vorhandene Anforderungsdokumente undVerfahrensbeschreibungen betreffen, um so herauszufinden, wie die gegenwärtigeLösung funktioniert und warum sie in dieser Form eingeführt wurde. Dokumen-tenanalyse kann auch dazu beitragen, vorhandene Informationslücken zu schlie-ßen, wenn beispielsweise die Experten nicht mehr greifbar sind, die eine Lösungentwickelt haben.

Elemente

.1 VorbereitungDas bei einer Dokumentenanalyse benutzte Material kann öffentlich zugänglichoder geschützt sein. Bei der Prüfung, welche Dokumente für die Analyse infragekommen, ist zu beachten,• ob der Inhalt der Quelle relevant, aktuell, ehrlich und glaubwürdig ist• ob die Inhalte verständlich sind und den betroffenen Stakeholdern leicht vermittelt werden können

• welche benötigten Daten erhoben und für eine Analyse aufbereitet werden sollen.

.2 Überprüfung der Dokumente und AnalyseZur Dokumentenanalyse gehören:• Gründliches Studium der Inhalte und Aufzeichnung relevanter Informa-tionen. Dazu kann auch ein Vordruck verwendet werden, in dem syste-matisch das Thema, die Art des Dokuments, die Quelle, Ergebnisse, eine Bewertung sowie weitere zu ergreifende Maßnahmen festgehal-ten werden.

• Die Feststellung, ob es widersprechende Aussagen oder Redundanzen gibt.

• Dokumentation von Sachverhalten, über die keine ausreichenden Informationen gefunden wurden. In solchen Fällen kann es nötig sein, weitere Erhebungen anzustellen oder tiefer in einen Sachverhalt einzu-steigen.

Dokumentenanalyse

319

Techniken

10.18.3

.3 Dokumentation der ErgebnisseWenn die gesammelten Informationen verwendet werden sollen, muss sich derBusiness-Analyst darüber im Klaren sein, ob• Inhalt und Detaillierungsgrad für die vorgesehene Zielgruppe ange-messen sind

• die gesammelten Informationen zu besser verständlichen, visuellen Darstellungen wie zum Beispiel Modelle, Graphen, Prozessabläufe oder Entscheidungstabellen aufbereitet werden.

Bewertung

.1 Stärken• Vorhandenes Material kann als Grundlage verwendet werden.• Es muss kein neuer Inhalt geschaffen werden.• Bestehende Quellen können als Referenz verwendet werden, um heraus-zufinden, wie der gegenwärtige Stand aussieht und was sich verändert hat.

• Die Ergebnisse können mit den Resultaten anderer Erhebungstechniken verglichen und bewertet werden.

• Die Ergebnisse können so aufbereitet werden, dass sie sich einfach nutzen und wiederverwenden lassen.

.2 Grenzen• Bestehende Dokumente können veraltet oder unbrauchbar sein (fehler-haft, lückenhaft, nicht lesbar, nicht überprüft oder nicht genehmigt).

• Die Autoren stehen u.U. für Rückfragen nicht zur Verfügung.• Die Ergebnisse sind primär dafür geeignet, den gegenwärtigen Zustand zu bewerten.

• Wenn es eine große Anzahl möglicher Quellen gibt, kann das Verfahren sehr zeitaufwändig werden, zu einer Informationsflut führen oder sogar Verwirrung stiften.

Schätzung

Zweck

Schätzungen werden durch Business-Analysten und andere Stakeholder vorge-nommen, um Kosten und andere Aufwendungen für ein Vorhaben vorherzu-sagen.

Schätzung

320

Techniken

10.18.4

10.19

10.19.1

Beschreibung

Schätzungen können die Entscheidungsfindung unterstützen, indem folgendeSachverhalte vorausgesagt werden:• Kosten und Zeitaufwand für • erwarteter Nutzen einer Lösungein bestimmtes Vorgehen

• Kosten eines Projektes • zukünftige Performance• erwarteter Wert einer Lösung • Kosten für die Bereitstellung einer

Lösung• Kosten für den laufenden • Auswirkungen potentieller RisikenBetrieb einer Lösung.

Das Ergebnis einer Schätzung wird häufig in einer einzigen Zahl ausgedrückt.Die Angabe eines Bereiches mit Minimal- und Maximalwerten und zugehörigenWahrscheinlichkeiten kann für die Stakeholder jedoch wesentlich sinnvoller sein.Ein solcher Bereich wird auch als Konfidenzintervall bezeichnet und bietet einMaß für die vorhandene Unsicherheit. Je weniger Informationen der Schätzendebesitzt, desto breiter dürfte das Intervall ausfallen.

Schätzungen erfolgen oft als ein iterativer Prozess. Die Werte werden überprüftund eventuell angepasst, sobald weitere Informationen vorliegen. Viele Schät-zungen ziehen auch historische Daten und die Ergebnisse früherer Schätzungenhinzu, um die eigenen Aussagen zu überprüfen. Jede Schätzung sollte mit ihrerjeweiligen Wahrscheinlichkeit versehen werden.

Elemente

.1 MethodenEs können unterschiedliche Techniken der Schätzung eingesetzt werden. Injedem Fall ist es für die Schätzer wichtig, sich mit den Betroffenen vorher darüberzu einigen, welche Elemente geschätzt werden sollen. Dies geschieht häufig inder Form eines Projektstrukturplans oder einer anderen Form der Zerlegung derzu schätzenden Werte. Werden Schätzwerte erarbeitet und abgeliefert, solltenimmer auch die Restriktionen und Unterstellungen klar kommuniziert werden.

Zu den üblichen Schätzungstechniken gehören:• Top-Down-Ansatz: Eine Gesamtschätzung wird stufenweise in Einzel-werte aufgegliedert.

• Bottom-Up-Ansatz: Ausgehend von der größten gewünschten Detail-lierungsebene werden Werte geschätzt und stufenweise nach oben verdichtet.

• Parametrische Schätzung: Dazu wird ein Modell der zu schätzenden Parameter entwickelt, in das historische Erfahrungen des Unterneh-

Schätzung

321

Techniken

10.19.2

10.19.3

mens einfließen, da nur so die gegebenen Fähigkeiten und Fertigkei-ten der Mitarbeiter wie auch die Qualität der jeweiligen Prozesse angemessen berücksichtigt werden können.

• Rough Order of Magnitude (ROM): Grobe Einschätzung bei niedrigem Informationsstand. Ist meistens mit einem breiten Konfidenzintervall verbunden.

• Rollierende Schätzung (Rolling Wave): Wiederkehrende Schätzungen eines Vorhabens, mit denen detaillierte Aussagen über naheliegende Ereignisse gemacht werden (zum Beispiel im Projektfortschritt), die dann bei den Werten für das restliche Vorhaben berücksichtigt werden,so dass die Präzision dieser Schätzwerte zunehmend steigt.

• Delphi-Methode: Kombiniert oft eine Expertenschätzung mit histori-schen Werten. Es gibt eine Reihe von Varianten für dieses Vorgehen, in jedem Fall werden mehrere Runden von Schätzungen durch Experten zugrundegelegt, um ein gemeinsam getragenes Ergebnis zu erreichen.

• PERT: Verfahren aus der Netzplantechnik, bei dem drei Wertegeschätzt werden: 1. Optimistischer Wert, das Best-Case-Szenario. 2. Pessimistischer Wert, das Worst-Case-Szenario. 3. Wahrscheinlicher Wert. Die Schätzung führt zu einem gewichteten Ergebnis und ergibt sich nach der folgenden Formel:

.2 Zuverlässigkeit der SchätzungDie Zuverlässigkeit einer Schätzung ist ein Maß für die Unsicherheit und bewertet,wie nahe eine Schätzung an dem später tatsächlich gemessenen Wert liegt. Siekann als ein Konfidenzintervall um einen mittleren Wert berechnet werden.Dieses Konfidenzintervall bietet einen Ausdruck für die vorhandene Unsicherheit.Liegen nur wenige Informationen vor, wie zum Beispiel ganz am Anfang einesVorhabens, wird häufig mit einer ROM-Schätzung begonnen, die wenig präziseund mit relativ hoher Unsicherheit verbunden ist.

ROM-Schätzungen bieten oft nur eine Zuverlässigkeit von plus/minus 50%.Sobald mehr Informationen zur Verfügung stehen, wird es möglich, eine definitive,genauere Schätzung vorzunehmen. Solche definitiven Schätzungen sollten maxi-mal plus/minus 10% vom tatsächlichen Wert abweichen.

Arbeitsgruppen können bei einer rollierenden Schätzung mit einer ROM-Schät-zung beginnen, um dann stufenweise zu definitiven Schätzungen zu gelangen.Für den jeweils nächsten anstehenden Arbeitsschritt werden dann definitiveSchätzungen vorgelegt, sobald ausreichende Informationen vorhanden sind. Fürspätere Ereignisse begnügt man sich mit ROM-Schätzungen, die dann mit demProjektfortschritt zunehmend verfeinert werden.

Schätzung

322

Techniken

1•optimistischer Wert + 1•pessimistischer Wert + 4•wahrscheinlicher Wert6

.3 InformationsquellenSchätzer berücksichtigen die verfügbaren Informationen, die sich aus früherenErfahrungen ergeben.

Beispiele für typische Informationsquellen:• Analoge Situationen: Es wird ein Sachverhalt (z.B. Projekt, Vorhaben, Risiko, Arbeitspaket) verwendet, das dem zu Schätzenden ähnlich ist.

• Betriebliche Historie: Es wird auf frühere Erfahrungswerte des Unterneh-mens bei vergleichbaren Aufgaben zurückgegriffen. Das ist dann beson-ders hilfreich, wenn die Aufgaben von der gleichen oder einer vergleich-baren Gruppe erledigt werden, die auch die gleichen Techniken einsetzt.

• Expertenurteil: Fachleute werden über den zu schätzenden Sachverhaltbefragt. Das sind häufig interne oder externe Personen, die solche Aufgaben in der Vergangenheit selbst erledigt oder begleitet haben. Wenn externe Personen befragt werden, muss zusätzlich die Qualifika-tion der vorgesehenen Mitarbeiter ausdrücklich berücksichtigt werden.

.4 Präzision und Vertrauenswürdigkeit der SchätzungWerden für einen bestimmten Sachverhalt mehrere Schätzungen abgegeben,steigt die Präzision der Schätzung auch mit steigender Übereinstimmung zwischenden Schätzwerten. Durch Ermittlung statistischer Werte wie Varianz oder Stan-dardabweichung, können die Schätzer das Ausmaß ihrer Übereinstimmungermitteln. Um das Ausmaß der Präzision oder Vertrauenswürdigkeit auszudrücken,wird für eine Schätzung häufig ein Wert angegeben und mit einer Aussageüber die Wahrscheinlichkeit verbunden. So könnte eine Gruppe beispielsweiseauf Grund ihrer individuellen Schätzwerte zu der Aussage kommen, dass eineAufgabe 40 Stunden benötigt mit einer Wahrscheinlichkeit von 90%. Der tat-sächliche Wert dürfte dann innerhalb eines Intervalls von 40 + 4 Stunden und40 – 4 Stunden liegen, d.h. zwischen 36 und 44 Stunden. Je höher die Genau-igkeit eingeschätzt wird, desto kleiner wird dieser Bereich.

Um die Präzision zu steigern, können Techniken eingesetzt werden, z.B. dasPERT-Verfahren. Werden Schätzungen für einzelne Teile eines Sachverhalts abge-geben und mit Wahrscheinlichkeiten versehen, dürften sich Schätzfehler teilweiseausgleichen. Die Gesamtschätzung ergibt sich dann aus der Verdichtung derTeilwerte unter Berücksichtigung der jeweiligen Wahrscheinlichkeiten.

.5 Lieferanten für SchätzwerteHäufig schätzen diejenigen, die ein bestimmtes Ergebnis auch abliefern sollen.Eine Schätzung ist in der Regel besser, wenn sie von einem Team und nicht voneinem Individuum stammt, da das Fachwissen und die Einschätzungen aller Mit-glieder berücksichtigt werden.

Manche Unternehmen haben ein Team, das auf Schätzungen spezialisiert istund viele Schätzaufgaben erledigt.

Schätzung

323

Techniken

Wenn ein Unternehmen auf eine sehr hohe Qualität der Schätzung bei einembestimmten Sachverhalt angewiesen ist, kann auch ein externer Experte hinzu-gezogen werden, der selbst schätzt oder die internen Schätzwerte kritisch hin-terfragt. Die internen und die externen Schätzwerte können dann miteinanderverglichen, Abweichungen können auf ihre Ursachen untersucht werden.

Bewertung

.1 Stärken • Schätzungen liefern die Grundlage für Budgets, Zeitvorgaben oder andereGrößen.

• Fehlen Schätzungen, können unrealistische Budgets oder Zeitvorgaben die Folge sein.

• Schätzt ein kleines Team von Fachleuten die Werte und nutzt dazu geeig-nete Techniken, sind normalerweise die Ergebnisse deutlich besser als wenn ein Individuum schätzen würde.

• Fließen die Erfahrungen während der Arbeit rollierend ein, entsteht ein immer genaueres Bild.

.2 Grenzen• Schätzungen können immer nur so gut sein wie das verfügbare Wissen über den Sachverhalt. Schätzungen ohne Erfahrungshintergrund bringen es mit sich, dass der tatsächliche Wert sehr weit von dem später erreich-ten Wert abweichen kann.

• Wird nur eine Schätzmethode genutzt, können die Stakeholder unrealis-tische Erwartungen haben.

Finanzanalyse

Zweck

Eine Finanzanalyse dient dazu, die finanziellen Auswirkungen einer Investition,einer Lösung oder eines Lösungsansatzes zu verstehen.

Beschreibung

Eine Finanzanalyse dient der Einschätzung der Rentabilität und des Nutzenseiner Lösungsvariante. Dazu werden die gesamten Kosten und der Nutzen fürdie Bereitstellung und Nutzung einer Lösung berücksichtigt.

Finanzanalyse

324

Techniken

10.19.4

10.20.1

10.20.2

10.20

Der Business-Analyst nutzt eine Finanzanalyse für die Empfehlung einer Lösungoder einer Investition, indem er die finanziellen Auswirkungen einer Lösungoder eines Lösungsansatzes mit den Auswirkungen anderer Varianten vergleicht.Dazu werden die folgenden Kosten berücksichtigt:• Investitionskosten für eine Lösung und der Zeitrahmen, in dem sie anfallen

• erwarteter finanzieller Nutzen und der Zeitrahmen, in dem er erzielt wird

• laufende Kosten für die Nutzung oder den Betrieb der Lösung und für deren Support

• finanzielle Risiken, die mit der Umstellung verbunden sind• laufende finanzielle Risiken, die sich aus dem Betrieb der Lösung ergeben.

Dazu wird typischerweise eine Kombination verschiedener Analysetechnikengenutzt, da jede Technik eine andere Perspektive einnimmt. Auf der Grundlageder Finanzanalyse wird dann entschieden, welche aus mehreren möglichen Vari-anten ausgewählt wird.

Die Finanzanalyse hat immer auch mit Unsicherheit zu tun. Je weiter man ineinem Vorhaben voranschreitet, desto besser werden die Auswirkungen derUnsicherheit erkennbar. Eine Finanzanalyse begleitet ein Vorhaben, um festzu-stellen, ob der erwartete Nutzen ausreicht, um das Vorhaben fortzusetzen. Eskann durchaus vorkommen, dass der Business-Analyst empfiehlt, ein Vorhabenzu beenden, wenn die neueren Einschätzungen es nicht mehr als lohnenderscheinen lassen.

Elemente

.1 Kosten des VeränderungsvorhabensZu den Kosten des Veränderungsvorhabens gehören alle Aufwendungen fürden Bau oder den Kauf einer Lösung und für den Prozess der Umsetzung imUnternehmen. Dazu können die Kosten für neue Gebäude und Geräte gehörensowie Kosten für Software, Personal und andere Ressourcen, für die Auflösungvon bestehenden Verträgen, für Vertragsstrafen, für die Konvertierung vonDaten, für Trainingsmaßnahmen, für die Kommunikation der Veränderung undfür das Management der Einführungsphase. Solche Kosten können auf ver-schiedene Bereiche eines Unternehmens verteilt werden.

.2 Total Cost of Ownership (TCO)Zu den Total Cost of Ownership gehören die Kosten für die Beschaffung undden Aufbau einer Lösung, die Kosten für deren Gebrauch und den notwendigen

Finanzanalyse

325

Techniken

10.20.3

Support für eine bestimmte Nutzungszeit und unter Umständen auch die Kostenfür die Entsorgung, um den wirklichen Wert einer Lösung zu verstehen. Bei derBeschaffung von Ausrüstungsgegenständen und Gebäuden gibt es normalerweiseeine Vorstellung über die Lebenserwartung. Wird in Prozesse oder Softwareinvestiert, ist die Nutzungsdauer häufig unklar. Einige Unternehmen unterstellenin diesen Fällen häufig eine standardisierte Zeitspanne wie beispielsweise dreioder fünf Jahre.

.3 Erzielung von NutzenNutzen wird aus Investitionen erst im Laufe der Zeit erzielt. Der geplante Wertkann auf Basis jährlicher Einzelwerte oder als kumulierter Wert für einen bestimm-ten Zeitraum angegeben werden.

.4 Kosten-Nutzen-AnalyseEine Kosten-Nutzen-Analyse ist die Vorhersage des erwarteten gesamten Nut-zens – ausgedrückt in finanziellen Größen – abzüglich der erwarteten Gesamt-kosten, die zu einem erwarteten Nettoergebnis führen.

Kosten und Nutzen werden häufig auf der Basis von Annahmen geschätzt. AlleAnnahmen über die Kosten- und Nutzenbestandteile sollten in den Kalkulationenoffengelegt werden, so dass sie überprüft, hinterfragt und genehmigt werdenkönnen. Die bei der Einschätzung verwendete Methode sollte beschrieben wer-den, damit sie überprüft und nötigenfalls auch angepasst werden kann.

Der Zeitraum für eine Kosten-Nutzen-Analyse sollte weit genug in die Zukunftreichen, in der die Lösung benutzt wird und in der die geplanten Werte realisiertwerden. Dadurch wird sichtbar, welche Kosten wann anfallen und wann dererwartete Nutzen erreicht sein sollte.

Einige Nutzenwerte lassen sich erst später realisieren, so wie auch einige Pro-jektkosten in späteren Jahren noch hinzukommen können. Der kumulierte Net-tonutzen kann über mehrere Jahre negativ sein, bis die Investition sich amortisierthat.

Es kann für den Business-Analysten sinnvoll sein, während eines laufendenChange-Vorhabens die Kosten-Nutzen-Analyse zu überprüfen und anzupassen,um zu schauen, ob die Lösung immer noch sinnvoll ist.

Finanzanalyse

326

Techniken

Tabelle 10.20.1: Beispiel für eine Kosten-Nutzen-Analyse

.5 Finanzielle KalkulationenUnternehmen nutzen unterschiedliche Verfahren der Finanzrechnung, um besserzu verstehen, wann und wie bestimmte Investments erfolgreich sind. Bei diesenBerechnungen werden die inhärenten Risiken von Investments ebenso berück-sichtigt wie die einmaligen Investitionskosten, die Zeitpunkte der Rückflüsse,der Vergleich mit alternativen Investitionsmöglichkeiten und der Zeitraum, derbenötigt wird, um die investierten Mittel wieder zu verdienen.

Finanzanalyse

327

Techniken

Jahr 0 Jahr 1 Jahr 2 Jahr 0

Erwarteter Nutzen

Erlöse $XXXX $XXXX $XXXX

Einsparungen laufende Kosten $XXXX $XXXX $XXXX

Zeitliche Einsparungen $XXXX $XXXX $XXXX

Verringerte Fehlerkosten $XXXX $XXXX $XXXX

Höhere Kundenzufriedenheit $XXXX $XXXX $XXXX

Verringerte Kosten für Compliance

$XXXX $XXXX $XXXX

Sonstige $XXXX $XXXX $XXXX

Summe jährlicher Nutzen $0 $XXXX $XXXX $XXXX

Kosten

Projektkosten $XXXX $XXXX $0 $0

Laufender Support $0 $XXXX $XXXX $XXXX

Baukosten $XXXX $0 $0 $XXXX

Lizenzen $0 $XXXX $XXXX $XXXX

Infrastrukturkosten $XXXX $0 $XXXX $0

Sonstige $0 $XXXX $0 $XXXX

Summe Kosten $XXXX $XXXX $XXXX $XXXX

Nettonutzen -$XXXX $XXXX $XXXX $XXXX

Kumulierter Nettonutzen -$XXXX -$XXXX -$XXXX $XXXX

Spezielle Standardsoftware einschließlich der Tabellenkalkulation bietet normaler-weise die dafür benötigten Funktionen, um diese Berechnungen durchzuführen.

Return on Investment

Der Return on Investment (ROI) ist die Verzinsung des Kapitals bzw. die Kapital-rendite als Maß für den wirtschaftlichen Nutzen eines Projekts oder einer Investition.

Sie wird wie folgt berechnet:

Return on Investment (ROI) = (Summe der Erträge –Summe der Aufwendungen)/Summe der Aufwendungen.

Je höher der ROI, desto besser ist die Investition.

Abzinsungsrate

Die Abzinsungsrate ist der Zinssatz, der internen Berechnungen zugrundegelegtwird. Normalerweise wird er in etwa dem Wert entsprechen, den ein Unternehmenerwartet, wenn es Geld anderswo investieren würde. Viele Unternehmen verwendeneinen Standardzinssatz, der üblicherweise vom Finanzbereich festgelegt wird, umhausinterne Investments zu überprüfen. Gelegentlich wird diese Rate auch höherangesetzt, wenn die anstehende Investition langfristig angelegt ist und es damitgrößere Unsicherheiten über die zukünftige Entwicklung gibt (Risikozuschlag).

Kapitalwertmethode

Der Kapitalwert ist eine betriebswirtschaftliche Kennziffer der dynamischen Inves-titionsrechnung. Bei der Kapitalwertmethode wird berücksichtigt, dass Aufwen-dungen und Erträge einer Investition zu unterschiedlichen Zeiten eintreten unddamit auch einen unterschiedlichen Wert haben. Spätere Erlöse sind schon des-wegen weniger „wertvoll“, weil sie nicht unmittelbar für die Finanzierung einerInvestition zur Verfügung stehen. Ergebnis einer Kapitalwertmethode ist dervoraussichtliche wirtschaftliche Erfolg einer Maßnahme oder eines Projektes undwird in der Regel vor der eigentlichen Investition berechnet. Er ermittelt sich ausder Summe aller Barwerte der durch eine Investition verursachten Ein- und Aus-zahlungen. Barwert bedeutet, dass die Ein- und Auszahlungen unter Berück-sichtigung eines kalkulatorischen Zinssatzes miteinander vergleichbar gemachtund auf den Zeitpunkt der Investition bezogen werden.

Interner Zinsfuß

Der Interne Zinsfuß ist ein Zinssatz, bei dem eine Investition ihren Break-Even-Punkt erreicht. Anders ausgedrückt halten sich also Kosten und Erlöse die Waage.Dazu wird für eine Investition eine mittlere, jährliche Rendite berechnet unterBerücksichtigung der Tatsache, dass die Ein- und Auszahlungen für diese Inves-titionen zu unterschiedlichen Zeitpunkten anfallen und deswegen abgezinstwerden müssen.

Finanzanalyse

328

Techniken

Bei der internen Zinsfußmethode wird der Zinssatz ermittelt, bei dem der Kapi-talwert = 0 ist. Eine Investition ist aus dieser Sicht immer dann sinnvoll, wennder interne Zinsfuß unter Berücksichtigung eines Risikozuschlags höher ist alsder Zinssatz, der durch andere vergleichbare Investments erreicht werden kann –beispielsweise durch andere Lösungsvarianten. Die Vorteilhaftigkeit einer Inves-tition wird also an der Höhe des internen Zinsfußes sichtbar.

Amortisationszeitraum

Der Amortisationszeitraum stellt die Zeitspanne dar, die benötigt wird, die Kostenfür eine Investition wieder einzuspielen. Vereinfacht können dazu alle Ein- undAuszahlungen kumuliert werden, bis sie sich decken. In der wirtschaftlichanspruchsvolleren Variante werden auch die unterschiedlichen Zeitpunkte derEin- und Auszahlungen durch eine Diskontierung berücksichtigt.

Sobald eine Investition den Amortisationszeitraum erreicht hat, kann sie zueinem positiven Ergebnis beitragen, wenn danach die Einzahlungen die Aus-zahlungen übersteigen. Unternehmen verlangen bei Investitionen häufig, dassder Amortisationszeitraum nicht mehr als x Jahre betragen darf.

Bewertung

.1 Stärken• Finanzielle Analysen erlauben es den Entscheidern, sehr unterschiedliche Investments aus verschiedenen Perspektiven zu beurteilen.

• Annahmen und Schätzungen, die in Nutzen und Kosten sowie in die finanziellen Berechnungen einfließen, werden offengelegt und können damit von den Entscheidungsberechtigten hinterfragt werden.

• Unsicherheiten über eine Veränderung oder eine Lösung werden verrin-gert, indem die relevanten Faktoren für ein Investment sichtbar gemacht werden.

• Falls sich in einem Vorhaben zum Beispiel veränderte Anforderungen oder neue Bedarfe ergeben, können die voraussichtlichen Auswirkungen ermittelt und aufgezeigt werden.

.2 Grenzen• Einige Arten von Kosten und Nutzen sind nur schwer finanziell zu quan-tifizieren.

• Da sich eine Finanzanalyse mit der Zukunft beschäftigt, bleiben immer Unsicherheiten über die erwarteten Kosten und den Nutzen bestehen.

• Positive Finanzzahlen können einen falschen Eindruck erwecken, da häufig auch nicht finanzielle Größen eine wesentliche Rolle spielen.

Finanzanalyse

329

Techniken

10.20.4

Fokusgruppen

ZweckZweck einer Fokusgruppe ist es, Ideen und Einstellungen zu bestimmten Pro-dukten, Dienstleistungen oder Sachverhalten in einem interaktiven Gruppenumfeldzu ermitteln. Die Teilnehmer werden von einem Moderator geleitet und tauschenihre Eindrücke, Präferenzen und Vorstellungen aus.

Beschreibung Eine Fokusgruppe setzt sich aus qualifizierten Personen zusammen, die ein bestimm-tes Thema erörtern und kommentieren möchten. Der Einzelne erhält hierdurchdie Möglichkeit, seine eigenen Ansichten der Gruppe mitzuteilen und sie dort zudiskutieren. Das kann dazu führen, dass die Teilnehmer ihre eigenen Ansichtenangesichts der Erfahrungen der anderen Teilnehmer neu bewerten. Ein qualifizierterModerator kümmert sich um verwaltungstechnische Vorarbeiten, unterstützt dieSitzung und erstellt den Bericht. Beobachter können die Fokusgruppe begleitenund die Ergebnisse protokollieren, dürfen jedoch nicht teilnehmen.

Eine Fokusgruppe kann während des gesamten Lebenszyklus eines Projekts eingesetztwerden. Wenn es sich um ein Produkt im Entwicklungsstadium handelt, werdendie Ideen der Gruppe im Verhältnis zu den bereits formulierten Anforderungenanalysiert. Dies kann dazu führen, dass bestehende Anforderungen aktualisiertoder neue Anforderungen entdeckt werden. Wenn es sich um ein fertiges Produkthandelt, das eingeführt werden soll, könnte die Gruppe beeinflussen, wie dasProdukt im Markt positioniert wird oder welche Anforderungen mit dem nächstenRelease erfüllt werden sollen. Mit einer Fokusgruppe kann auch die Kundenzufrie-denheit hinsichtlich eines Produkts oder einer Dienstleistung bewertet werden.

Eine Fokusgruppe ist eine Form der qualitativen Sozialforschung. Die Aktivitätensind ähnlich einem Brainstorming, allerdings ist eine Fokusgruppe stärker strukturiertund auf die Ansichten der Beteiligten zu einem bestimmten Thema fokussiert. Eshandelt sich nicht um eine Interviewsitzung, die mit einer Gruppe stattfindet, son-dern um eine Diskussion, bei der Feedback zu einem speziellen Fachgebiet eingeholtwird. Die Ergebnisse einer Sitzung werden analysiert und dann eher als Themenund Perspektiven weiterverwendet und nicht als quantitative Aussagen.

Elemente

.1 Ziel der Fokusgruppe Eine Fokusgruppe benötigt ein klares und spezifisches Ziel für ihre Arbeit. Dazuwerden Fragen formuliert. Die Diskussion wird durch einen Moderator gesteuert,um das Ziel zu erreichen.

Fokusgruppen

330

Techniken

10.21

10.21.1

10.21.2

10.21.2

.2 Planung der FokusgruppeDer Plan für die Fokusgruppe stellt sicher, dass sich alle Stakeholder über denZweck der Veranstaltung klar sind und dazu beitragen, die Ziele zu erreichen.

Zur Planung der Fokusgruppe gehören:• Zweck: Es werden Fragen entwickelt, zentrale Themenfelder erarbeitetund eine Empfehlung ausgesprochen, ob ein Diskussionsleitfaden genutzt werden soll oder nicht.

• Ort: Festlegung, ob ein Online Meeting oder ein Face-to-Face-Treffen stattfindet und wo ein solches Treffen durchgeführt werden soll.

• Logistik: Festlegung der Größe und der Ausstattung des Raums, des Termins und weiterer benötigter Hilfen wie z.B. Transportmöglichkeiten.

• Beteiligte: Bestimmung der Anforderungen an die Beteiligten, Fest-legung, ob Beobachter notwendig sind, Bestimmung von Moderator und Protokollant. Überlegungen, ob Anreize für die Teilnahme gesetzt werden sollen.

• Budget: Ermittlung der Kosten für die Sitzung und Sicherstellung, dass die geforderten Ressourcen rechtzeitig verfügbar sind.

• Zeitplan: Festlegung des Sitzungszeitraums und der Termine, zu denen Ergebnisse der Fokusgruppe bereitgestellt werden.

• Ergebnisse: Festlegung, wie die Ergebnisse analysiert und weitergelei-tet werden, sowie der Aktionen, die aufgrund der Ergebnisse ergriffen werden sollen.

.3 TeilnehmerFür den Erfolg einer Fokusgruppe ist es wichtig, dass sich die Beteiligten inhaltlichengagieren, aber auch die Meinungen der Anderen aufmerksam zur Kenntnisnehmen. Eine Fokusgruppe umfasst normalerweise sechs bis zwölf Mitglieder.Es kann notwendig sein, zum Ausgleich von Abwesenheiten weitere Personeneinzuladen. Falls es notwendig ist, sehr viele Menschen zu beteiligen, kann essinnvoll sein, mehr als eine Fokusgruppe zu bilden. Häufig werden die Teilnehmerfür die Teilnahme bezahlt.

Welche Anforderungen an die Beteiligten gestellt werden, hängt von den jewei-ligen Zielen der Fokusgruppe ab.

.4 DiskussionsleitfadenEin Diskussionsleitfaden bietet dem Moderator eine Liste spezieller Fragen undThemen, die behandelt werden müssen, um das Ziel zu erreichen. Diskussions-leitfäden bieten auch eine Struktur oder einen Rahmen, den der Moderatorbeachten soll. Beispielsweise kann dort auch geregelt werden, dass erst ein all-gemeines Feedback und Kommentare eingeholt werden, bevor Einzelheiten

Fokusgruppen

331

Techniken

behandelt werden. Leitfäden erinnern den Moderator daran, neue Mitgliederwillkommen zu heißen und vorzustellen, die Ziele der Sitzung zu beschreibenund zu zeigen, wie die Veranstaltung abläuft und was mit Feedback geschehenwird.

.5 Ernennung eines Moderators und eines ProtokollantenEin Moderator soll dafür sorgen, dass die Gruppe zielorientiert beim Thema bleibt.Dazu muss er verstanden haben, worum es bei dem Thema geht. Ein Moderatorkümmert sich darum, dass alle ausreichend beteiligt werden, geht flexibel auf diejeweilige Situation ein und sorgt für ein unverfälschtes Feedback.

Der Protokollant macht sich Notizen, um sicherzustellen, dass die behandeltenPunkte korrekt dokumentiert werden.

Der Business-Analyst kann sowohl die Rolle des Moderators als auch die einesProtokollanten ausfüllen. Moderator wie Protokollant verhalten sich neutral, siesind keine aktiven Mitglieder der Gruppe.

.6 Steuerung der FokusgruppeDer Moderator lenkt die Diskussion der Gruppe und folgt dabei einem Leitfaden,um sicherzustellen, dass die Ziele erreicht werden. Dabei sollten die Teilnehmerjedoch nicht unnötig in ihrer freien Meinungsäußerung gegängelt werden. EineSitzung dauert normalerweise zwischen einer und zwei Stunden. Die Ergebnissewerden dokumentiert.

.7 NachbereitungDie Ergebnisse einer Fokusgruppe werden zeitnah schriftlich dokumentiert. DerBusiness-Analyst überprüft die Dokumente und Bemerkungen der Teilnehmer,untersucht, ob sich aus den Ergebnissen Trends ableiten lassen und erarbeiteteine Zusammenfassung.

Bewertung

.1 Stärken• Im Vergleich zu einer Erhebung mittels Interview ist eine Fokusgruppe weniger zeit- und kostenaufwändig.

• Es können sehr wirksam Haltungen, Erfahrungen und Wunschvorstellun-gen ermittelt werden.

• Durch die aktive Diskussion und die Möglichkeit, Fragen zu stellen, wird ein Umfeld geschaffen, in dem die Beteiligten auch ihre eigene Sicht hinterfragen können.

Fokusgruppen

332

Techniken

10.21.4

• Eine Online-Fokusgruppe ist immer dann sinnvoll, wenn die Reisebudgets begrenzt und die Teilnehmer regional weit verstreut sind.

• Sitzungen von Online-Fokusgruppen können für die spätere Auswertung aufgezeichnet werden.

.2 Grenzen• Es kann sein, dass sich Menschen in einer Gruppensituation nicht frei-mütig über sensitive oder persönliche Sachverhalte äußern.

• Es kann Unterschiede geben zwischen dem, was gesagt und was wirklich getan wird.

• Wenn eine Gruppe zu homogen ist, kann es sein, dass nicht die gesamte Breite der Anforderungen ermittelt wird.

• Es wird ein qualifizierter Moderator benötigt, um Interaktionen und Diskussionen zu steuern.

• Es ist für die Beteiligten schwierig, einen gemeinsamen Termin zu finden.• Bei Online-Fokusgruppen sind die Interaktionen zwischen den Beteiligten eher begrenzt.

• Für einen Moderator ist es bei Online-Fokusgruppen schwierig, die wirklichen Meinungen zu erkennen, da die Signale der Körpersprache nicht sichtbar werden.

• Ein lautstarker Teilnehmer kann eine Gruppe dominieren.

Funktionale Gliederung

Zweck

Eine funktionale Gliederung hilft, Komplexität in den Griff zu bekommen undUnsicherheiten zu verringern, indem Prozesse, Systeme, funktionale Bereicheoder Sachverhalte in ihre kleineren Bestandteile zerlegt werden und so die Mög-lichkeit geschaffen wird, diese einzeln zu analysieren.

Beschreibung

Die funktionale Gliederung ist ein erster Schritt in der Analyse komplexer Systemeund Konzepte, die jeweils als ein ganzer Satz zusammenhängender Funktionen,Effekte oder Komponenten angesehen werden können. Durch eine Abgrenzungkleinerer Einheiten verringert sich die Komplexität der Analyse. Werden größereKomponenten in kleinere zerlegt, wird es leichter, für jede einzelne Komponente


333

Techniken

10.22

10.22.1

10.22.2

deren Umfang zu bestimmen, die Weiterentwicklung zu verfolgen und dendamit verbundenen Arbeitsaufwand zu schätzen. Es wird auch einfacher, dieLeistung einer einzelnen Komponente in Relation zu anderen zu beurteilen.

Die Tiefe der Zerlegung hängt von der Natur der Komponenten wie auch vonden verfolgten Zielen ab. Bei einer Gliederung wird davon ausgegangen, dassdie Summe der kleineren Elemente vollständig die übergeordnete Einheit abbildet.So kann in der Hierarchie einer funktionalen Zerlegung jedes Teilelement auchnur ein übergeordnetes Ausgangselement haben.

Die folgende Abbildung zeigt ein Beispiel, wie eine Funktion in kleinere beherrsch-bare und messbare Subkomponenten zerlegt werden kann.

Abb. 10.22.1: Diagramm einer funktionalen Gliederung

Elemente

.1 Ziele der Gliederung Die mit einer Gliederung verbundenen Ziele sind maßgeblich dafür, wie die Zer-legung abläuft, und sie bestimmen, was, nach welchen Kriterien und wiedetailliert gegliedert werden soll.

Beispiele für Ziele einer Zerlegung:• Messen und Beherrschen: Es werden einfacher zu handhabende Teile abgegrenzt, die einen Beitrag zu dem Gesamtergebnis liefern und für die wichtige Indikatoren oder Kennzahlen ermittelt werden können.

• Design: Der Entwurf von Lösungen kann durch weniger komplexe, abgegrenzte Sachverhalte/Elemente vereinfacht werden.


334

Techniken

Funktion

Unterfunktion 1 Unterfunktion 2

Aktivität 1.1.1

Prozess 1.3 Prozess 1.2 Prozess 2.1 Prozess 2.3 Prozess 2.2

Aktivität 2.1.1

Aktivität 1.1.2

Aktivität 1.1.3

Aktivität 1.2.1

Aktivität 1.2.2

Prozess 1.1 Prozess 2.4

Aktivität 2.1.2

10.22.3

• Analyse: Die Untersuchung wesentlicher Eigenschaften und Verhal-tensweisen eines Artefakts oder Phänomens kann erleichtert werden, indem es von seiner Umwelt abgegrenzt wird.

• Schätzung und Vorhersage: Das Maß an Unsicherheit kann verringert werden, indem Sachverhalte in ihre kleineren Elemente zerlegt werden.

• Wiederverwendung: Werden kleinere Einheiten als Bausteine konzipiert,können sie in verschiedenen Prozessen genutzt werden.

• Optimierung: Eine Zerlegung kann helfen, Flaschenhälse (Bottlenecks)zu entdecken und zu entschärfen, die Kosten einer Funktion zu redu-zieren oder die Prozessqualität zu steigern.

• Substitution: Durch die Zerlegung in kleinere Einheiten können Lösungs-komponenten einfacher ausgetauscht werden, ohne die Leistung des Gesamtsystems erheblich zu beeinflussen.

• Kapselung: Die Kombination abgrenzbarer Module erleichtert die Bildung komplexerer Einheiten.

.2 Gegenstände der ZerlegungEine funktionale Gliederung kann für eine Vielzahl unterschiedlicher Sachverhaltegenutzt werden, z.B.:• Ergebnisse betrieblicher Aktivitäten: Zum Beispiel Umsatz, Gewinn, Aufwendungen, Serviceumfang oder Produktionsvolumen.

• Zu erledigende Aufgaben: Zerlegung eines Projektes mithilfe eines Projektstrukturplans in Phasen, Meilensteine, Arbeitspakete, Auf-gaben, Aktivitäten.

• Geschäftsprozess: Beispielsweise ein Prozessstrukturplan, der dazu dient, die Bestandteile eines Prozesses zu messen, zu handhaben, zu optimieren oder wiederzuverwenden.

• Funktion: Zerlegung kann anschließend der Optimierung oder einer leichteren Einführung dienen.

• Organisationseinheit: Gliederung kann helfen, eine neue Struktur zu schaffen.

• Lösungskomponente: Kleinere Einheiten erleichtern den Entwurf, die Einführung oder Veränderungen.

• Aktivitäten: Zerlegung erleichtert Veränderungen, Optimierung, Messung, Zeitschätzung und Einführung.

• Produkte und Services: Eine Aufgliederung fördert Design, Verbesse-rung und Einführung.

• Entscheidungen: Die Zerlegung von Entscheidungen in ihre Komponen-ten kann dazu beitragen, Entscheidungen zu verbessern oder zu unter-stützen, indem die Inputs, die zugrundeliegenden Modelle, die Abhän-gigkeiten und die Ergebnisse identifiziert werden.


335

Techniken

.3 Tiefe der GliederungEine angemessene Tiefe der Zerlegung liegt dann vor, wenn sie dazu geeignetist, die verfolgten Ziele zu erreichen. Die Zerlegung wird so lange fortgeführt, bisder Business-Analyst sich über den zugrundeliegenden Sachverhalt klargewordenist und die Ergebnisse als Basis für die weitere Bearbeitung dienen können.

.4 Darstellung der GliederungsergebnisseDie Darstellung der Ergebnisse einer funktionalen Gliederung erlaubt es demBusiness-Analysten, diese Ergebnisse zu validieren, zu verifizieren und sie für dieweitere Arbeit zu nutzen. Die Ergebnisse können als rein textliche Beschreibungvorliegen, als hierarchische Gliederung, als formelle Notation (z.B. mathematischeFormeln, Business Process Execution Language, Programmiersprachen) oder alsbildhaftes Diagramm. Dazu steht ein breites Spektrum an Techniken zur Verfügungz.B.:• Baumdiagramme: Zeigen die hierarchische Aufgliederung von Arbeit, Aktivitäten, Organisationseinheiten oder Ergebnissen.

• Geschachtelte Diagramme: Verdeutlichen die hierarchischen Abhän-gigkeiten eines Teils zu allen anderen Teilen eines Ganzen.

• Use Case Diagramme: Beschreiben das beobachtbare Verhalten zwischen Akteuren und dem betrachteten System, das sich ergibt, wenn ein Aktor das System nutzt, um ein bestimmtes Ziel zu erreichen.

• Flussdiagramme: Zeigen die Ergebnisse der Zerlegung eines Prozesses oder einer Funktion.

• State-Transition-Diagramme: Verdeutlichen das Verhalten eines Objek-tes in seinem Gesamtzusammenhang.

• Ursache-Wirkungs-Diagramme: Verdeutlichen die Ereignisse, Bedin-gungen, Aktivitäten und Effekte, die daran beteiligt sind, ein komple-xes Ergebnis oder Phänomen hervorzubringen.

• Entscheidungsbäume: Zeigen die Einzelheiten der Struktur einer kom-plexen Entscheidung und ihrer möglichen Ergebnisse.

• Mind Maps: Bilden gruppierte Gedanken in Form einer Landkarte ab.

• Komponenten-Diagramme: Machen sichtbar, wie Komponenten mit-einander verbunden sind, um eine größere Einheit und/oder ein Soft-waresystem zu bilden.

• Decision Model and Notation: Analysiert die Geschäftslogik in einer standardisierten Notation und dient der Sicherstellung eines schlüssi-gen und integrierten Ergebnisses.


336

Techniken

Bewertung

.1 Stärken• Eine funktionale Gliederung erleichtert komplexe Vorhaben, indem viel-schichtige Probleme in besser beherrschbare Teile aufgegliedert werden.

• Bietet einen strukturierten Ansatz, um ein gemeinsames Verständnis kom-plexer Sachverhalte zwischen verschiedenen Stakeholdern zu entwickeln.

• Vereinfacht die Messung und Schätzung des Arbeitsumfangs der Auf-gaben, die in einem bestimmten Vorhaben anfallen, erleichtert die Abgrenzung der Arbeit und die Bestimmung geeigneter Kennzahlen und Messwerte.

.2 Grenzen• Fehlende oder falsche Informationen aus einer Gliederung können später zu Nacharbeit führen oder die Arbeit der Aufgliederung komplett infrage-stellen.

• Viele Systeme können nicht durch einfache hierarchische Beziehungen zwischen den Komponenten abgebildet werden, weil die Abhängigkeitenzwischen den Komponenten auch durch die Art der Zerlegung determi-niert sein kann.

• Jeder komplexe Sachverhalt erlaubt alternative Formen der Gliederung. Alle denkbaren Varianten zu untersuchen, kann sehr herausfordernd und zeitaufwändig sein, die Beschäftigung mit lediglich einer Variante kann demgegenüber wichtige Sachverhalte verbergen und damit mögliche bessere Lösungen verhindern.

• Die Durchführung einer funktionalen Gliederung kann unter Umständen ein tiefes Verständnis des Sachverhalts und eine intensive Zusammenarbeit mit verschiedenen Stakeholdern erfordern.

Glossar

ZweckEin Glossar definiert die zentralen Begriffe, die für ein Fachgebiet oder einenbetrieblichen Bereich relevant sind.

BeschreibungGlossare werden verwendet, um ein gemeinsames Verständnis für die Begriffezu vermitteln, die von den Stakeholdern verwendet werden. Ein Begriff kann

Glossar

337

Techniken

10.22.4

10.23

10.23.1

10.23.2

für verschiedene Menschen sehr unterschiedliche Bedeutung haben. Eine Listeder relevanten Begriffe und die im betrieblichen Umfeld gültigen Definitionenkönnen helfen, ein gemeinsames Verständnis zu schaffen und die innerbetrieblicheKommunikation zu erleichtern. Ein Glossar sollte allen Betroffen zugänglich sein.

Elemente

Ein Glossar ist eine Liste von Begriffen und zugehöriger Definitionen sowie derebenfalls verwendeten Synonyme.

Ein Begriff wird in das Glossar aufgenommen, wenn• dieser Begriff lediglich in einem Bereich verwendet wird• es unterschiedliche Begriffsverständnisse für ihn gibt• die Definition nicht mit der Alltagssprache übereinstimmt• die Wahrscheinlichkeit besteht, dass Missverständnisse auftreten.

Der Aufbau eines Glossars sollte möglichst zu Beginn eines Vorhabens odereines Projektes stattfinden, um den Wissenstransfer und das Verständnis zuerleichtern. Dazu wird ein Ansprechpartner bestimmt, der für die laufende Pflegeund die Verteilung des Glossars zuständig ist. Wenn Unternehmen derartigeGlossare entwickeln, stellt sich häufig heraus, dass sie später auch noch fürandere Vorhaben verwendet werden können.

Bei der Entwicklung eines Glossars sollte beachtet werden, dass• Definitionen klar, präzise und kurz sind• Akronyme ausgeschrieben werden, wenn sie in einer Definition ver-wendet werden,

• Stakeholder auf Glossare einfach und sicher zugreifen können• der Kreis derer begrenzt ist, die eine Berechtigung für die Pflege des Glossars besitzen.

Bewertung

.1 Stärken• Ein Glossar fördert das gemeinsame Verständnis eines Fachgebiets sowie eine bessere Kommunikation zwischen allen Stakeholdern.

• Werden die Definitionen in einer zentralen Dokumentation des Unter-nehmens aufgeführt, gibt es jeweils nur eine gültige Definition. Die Konsistenz wird dadurch zusätzlich gefördert.

• Erstellung und Pflege relevanter Informationen der Business-Analyse wie z.B. Geschäftsregeln, Anforderungen und Strategien der Veränderung, werden vereinfacht.

Glossar

338

Techniken

10.23.3

10.23.4

.2 Grenzen• Ein Glossar benötigt einen Zuständigen, der für eine zeitnahe Pflege ver-antwortlich ist. Andernfalls besteht die Gefahr, dass es veraltet und dann auch ignoriert wird.

• Für verschiedene Stakeholder kann es durchaus eine Herausforderung sein, sich auf eine einzige Definition für einen Begriff zu einigen.

Schnittstellenanalyse


Eine Schnittstellenanalyse dient der Klärung der Frage wo, warum, wann, wieund für wen welche Informationen zwischen Lösungskomponenten oder überLösungsgrenzen hinweg ausgetauscht werden.

Beschreibung

Eine Schnittstelle ist eine Verbindung zwischen zwei Komponenten oder Lösungen.Alle Lösungen erfordern eine oder mehrere Schnittstellen zum Austausch mitanderen Lösungskomponenten, Organisationseinheiten oder Geschäftsprozessen.

Beispiele für Typen von Schnittstellen:• Anwender-Schnittstellen (User Interface), an denen ein menschlicher Nutzer direkt mit einer Lösung interagiert

• Schnittstellen zu Menschen außerhalb der Lösung, z.B. Regulatoren oder Stakeholdern

• Schnittstellen zu und zwischen Geschäftsprozessen• Datenflüsse zwischen Systemen• Application Programming Interfaces (APIs)• Schnittstellen zur Hardware.

Eine Schnittstellenanalyse definiert und klärt unter anderem,• wer die Schnittstelle nutzt• welche Information wie oft ausgetauscht wird• wo der Informationsaustausch stattfindet• warum die Schnittstelle benötigt wird• wie die Schnittstelle aussieht oder wie sie eingeführt werden sollte.

Eine frühzeitige Identifikation von Schnittstellen erlaubt es dem Business-Analysten,präziser die Anforderungen der Stakeholder zu ermitteln und damit die benötigte


339

Techniken

10.24

10.24.1

10.24.2

Funktionalität der Lösung bereitzustellen. Eine solche frühzeitige Ermittlung derSchnittstellen macht sichtbar, welche Stakeholder von bestimmten Lösungskom-ponenten profitieren oder von bestimmten Komponenten abhängig sind. Sokann der Business-Analyst auch erkennen, welche Stakeholder bei anderen Erhe-bungstechniken beteiligt werden sollten.

Abb. 10.24.1: Schnittstellenanalyse

Elemente

.1 Vorbereitung der IdentifikationDer Business-Analyst kann andere Techniken wie zum Beispiel Dokumentenana-lyse, Beobachtung oder Interview nutzen, um festzustellen, welche Schnittstellenidentifiziert werden müssen. In einem Kontextdiagramm können Informationenüber Schnittstellen zwischen Personen, Organisationseinheiten, Geschäftspro-zessen oder anderen Lösungskomponenten auf einem relativ hohen Abstrakti-onsgrad sichtbar gemacht werden. Die Ergebnisse dieser Analyse können zeigen,wie häufig bestehende Schnittstellen genutzt werden und ob es Probleme gibt,die darauf hinweisen, dass Verbesserungen vorgenommen werden müssen. DieErgebnisse können außerdem zeigen, welche weiteren Sachverhalte gelöstwerden müssen, damit eine Schnittstelle geschaffen werden kann.

.2 Identifikation der SchnittstelleDer Business-Analyst ermittelt, welche Schnittstellen in Zukunft für jeden einzelnenStakeholder bzw. für jedes System geschaffen werden müssen. Die Beziehungzwischen Stakeholdern kann von „many-to-many“ bis hin zu „one-to-one“ reichen.Einige Schnittstellen können weniger offensichtlich sein und weniger häufiggenutzt werden wie zum Beispiel Schnittstellen, die für die Regulierung, für Auditsoder für die Mitarbeiterschulung benötigt werden. Dabei kann es auch Schnittstellengeben, die nicht direkt mit der operativen Lösung zu tun haben.


340

Techniken

Lösung

Schnittstelle

Validierungoder

TransformationLösung

Nachricht

Input Output

Nachricht

10.24.3

Für jede Schnittstelle wird• die Funktion beschrieben• die Häufigkeit der Nutzung eingeschätzt• die am besten geeignete Form ermittelt und es werden• weitere Details erhoben.

.3 Definition der SchnittstellenDie Anforderungen an eine Schnittstelle ergeben sich hauptsächlich aus der Beschrei-bung von Input und Output dieser Schnittstelle, aus den geltenden Regeln zurValidierung von Input und Output sowie aus den Ereignissen, die Interaktionenauslösen. Dabei kann es eine große Anzahl unterschiedlicher Interaktionstypengeben, die alle spezifiziert werden müssen. Interaktionen können durch typischeoder alternative Flüsse von Input oder Output einer Lösung verursacht werden,aber auch durch außergewöhnliche Ereignisse wie zum Beispiel durch Fehler.

Der Business-Analyst berücksichtigt, wer die Schnittstelle nutzt, welche Informationfließt und wann und wo der Austausch stattfindet. Die Schnittstelle legt denWorkflow zwischen Systemen fest, die Rollen und Rechte von Anwendern sowiebestehende Zielvorgaben für die Schnittstellen. Die Festlegung einer Schnittstellehängt auch von Richtlinien zur Nutzung ab, wie zum Beispiel Anforderungen andie Erreichbarkeit oder Anforderungen, die sich aus Workflows ergeben.

Damit wichtige Elemente für das Design sichtbar werden, müssen Schnittstellenzwischen Komponenten einer Lösung oder eines Prozesses und Menschen vorabsehr gründlich analysiert werden. Zu einer Definition einer Schnittstelle gehören• Name• Umfang• Art des Austauschs• Format der Nachricht

• Häufigkeit des Austauschs.

Bewertung

.1 Stärken• Durch eine frühzeitige Analyse der Schnittstellen können die funktionalenVoraussetzungen besser ermittelt werden.

• Durch eine klare Spezifikation der Schnittstelle können planmäßig die Anforderungen, die Geschäftsregeln und die Restriktionen einer Lösung ermittelt werden.

• Da es primär um die Abhängigkeiten zwischen Komponenten geht, wird eine zu detaillierte Analyse vermieden.


341

Techniken

10.24.4

.2 Grenzen• Schnittstellenanalyse bietet keine Einsichten in andere Lösungsbestand-teile, da die Analyse sich nicht mit den Interna einer Lösung beschäftigt.

Interview

Zweck

Ein Interview ist ein systematisches Vorgehen, um mit Menschen zu sprechenund Informationen von einer Person oder einer Gruppe von Personen einzuholen,indem relevante Fragen gestellt und die Antworten dokumentiert werden. EinInterview kann auch verwendet werden, um eine vertrauensvolle Beziehungzwischen dem Business-Analysten und Stakeholdern aufzubauen und damitderen Bereitschaft zu fördern, sich für ein Vorhaben zu engagieren oder einegeplante Lösung zu unterstützen.

Beschreibung

Ein Interview ist eine weit verbreitete Technik zur Erhebung von Anforderungen.Mit ihm wird eine persönliche Beziehung zu Menschen aufgebaut, die voneinem Vorhaben betroffen sind.

In einem Interview stellt der Interviewer Fragen, um Antworten zu erhalten. Diehäufigste Form sind Einzelgespräche. In einem Gruppengespräch muss der Inter-viewer dafür sorgen, dass sich alle Teilnehmer einbringen.

Zur Ermittlung von Anforderungen stehen zwei Arten von Interviews zur Verfügung: • Strukturiertes Interview: Hier arbeitet der Interviewer eine vorher fest-gelegte Anzahl von Fragen in einer festen Reihenfolge ab.

• Unstrukturiertes Interview: Hier besprechen Interviewer und Befragte ohne vorher festgelegte Fragen alle relevanten Interessensgebiete, die sich oft erst im Interview ergeben.

Ein erfolgreiches Interview hängt von verschiedenen Faktoren ab, dazu gehören u.a.:• Wissen des Interviewers über das betrachtete Fachgebiet • Erfahrung des Interviewers in der Gesprächsführung • Fähigkeit des Interviewers zur Dokumentation der Ergebnisse• Bereitschaft der befragten Personen, die relevanten Informationen zur Verfügung zu stellen

• Wissen des Interviewers über die vom Unternehmen verfolgten Ziele und über die erwartete zukünftige Lösung

• Verhältnis des Interviewers zu der befragten Person.

Interview

342

Techniken

10.25

10.25.1

10.25.2

Elemente

.1 Ziel des InterviewsBei der Planung von Interviews muss der Business-Analyst im Auge behalten,• was der grundlegende Zweck dieser Befragung ist, in Abhängigkeit von dem betrieblichen Bedarf

• welche Ziele in dem einzelnen Interview verfolgt werden – das hängt auch davon ab, was der Befragte dazu beitragen kann.

Diese Ziele müssen dem Befragten auch verdeutlicht werden.

.2 Auswahl der BefragtenPotentielle Befragte werden mit Unterstützung durch Projektleiter, Sponsorenoder andere Stakeholder – abhängig vom Ziel des Interviews – ausgewählt.

.3 InterviewfragenAbhängig von dem verfolgten Ziel werden die Fragen entworfen. Ziele könnensein:• Daten sammeln• die Sichtweise und Einstellung des Stakeholders zu einem Vorhaben zuerfragen

• eine Lösung entwickeln• über eine Lösung informieren oder dafür werben.

Zwei Fragetypen werden unterschieden:• Offene Fragen: Fragen, die zu einem Dialog ermutigen und die nicht einfach durch „Ja“ oder „Nein“ beantwortet werden können, sonderneiner Erklärung bedürfen.

• Geschlossene Fragen: Fragen, die verwendet werden, um eine einzige Antwort zu erhalten wie: „Ja“, „Nein“ oder eine bestimmte Zahl.

Interviewfragen werden meistens nach ihrer Bedeutung oder ihrer Priorität geord-net. Beispiele für die Reihenfolge sind die Regeln „Vom Allgemeinen zum Spe-ziellen“ oder „Vom Detail zur Zusammenfassung“. Auch kann die Reihenfolgevom Wissensstand des Befragten und vom Gegenstand des Interviews abhängiggemacht werden.

Der Schwerpunkt kann in einem Interview auf frei formulierte Fragen gelegtwerden, um so besser auf die individuelle Sicht eines Gesprächspartners eingehenzu können. Wenn die Vergleichbarkeit der Ergebnisse im Vordergrund steht,kann es auch sinnvoll sein, allen Beteiligten standardisierte Fragen zu stellen,die dann in einer Checkliste vorbereitet werden.

Interview

343

Techniken

10.25.3

Interviewfragen können Bestandteil eines Leitfadens sein, in dem neben denFragen selbst auch die dafür vorgesehene Zeit und eventuelle Nachfassfragenaufgelistet werden. Zusätzlich können solche Fragen gekennzeichnet werden,die bei zeitlichen Engpässen unter Umständen ausgelassen werden können. Alldas hängt von der Art des Interviews, den verfolgten Zielen, der Art der Kom-munikation und dem zeitlichen Rahmen ab. In einem solchen Leitfaden könnenauch die Ergebnisse festgehalten werden.

.4 Logistik der InterviewsFür ein erfolgreiches Interview muss die notwendige Logistik bereitgestelltwerden. Zu den Entscheidungen über die Logistik gehören:• Ort des Interviews: Der hängt ab von der zeitlichen Verfügbarkeit und der Art der Kommunikation (persönliche Befragung, Telefon oder Online-Konferenz).

• Aufzeichnung des Interviews: Soll detailliert dokumentiert werden, kann es notwendig sein, einen Protokollanten einzusetzen.

• Vorherige Zustellung der Fragen: Das kann in den Fällen sinnvoll sein, in denen der Befragte selbst erst Informationen zusammentragen muss, um die Fragen beantworten zu können.

• Verwendung der Fragen: Es ist zu klären, ob die Ergebnisse vertraulich behandelt werden sollen und wie sie in diesem Fall verdichtet werden, um die Quelle unsichtbar zu machen.

.5 Ablauf des Interviews

Interviewbeginn: Der Interviewer• nennt den Zweck des Interviews und den Grund, warum gerade der Befragte einen Beitrag leisten soll

• geht auf eventuell von der befragten Person geäußerte Bedenken ein• erläutert, was nach dem Interview mit den erhobenen Informationen gemacht wird.

Während des Interviews: Der Interviewer• stellt sicher, dass der Schwerpunkt des Interviews auf den festgesetz-ten Zielen und den vorher festgelegten Fragen liegt

• spricht alle von der befragten Person während des Interviews geäußer-ten Bedenken an und hält sie fest, damit sie später weiterverfolgt werden können

• hört aktiv zu und macht dem Befragten bewusst, wie er ihn verstan-den hat

• macht sich schriftliche Notizen oder zeichnet die Ergebnisse auf.

Interview

344

Techniken

Interviewende: Der Interviewer• fragt nach Sachverhalten, die während der Sitzung möglicherweise nicht behandelt worden sind

• fasst die Sitzung zusammen und bittet um Ergänzung oder Korrekturen

• erläutert, wie die Ergebnisse verwendet werden• dankt dem Befragten.

.6 Interview-NachbereitungEs ist wichtig für den Interviewer, die Informationen nachzubereiten und dieErgebnisse mit den Befragten möglichst kurze Zeit nach dem Interview zu verifi-zieren. So können die Befragten auch feststellen, was der Interviewer aus demGespräch mitgenommen hat, und auf möglicherweise fehlende oder inkorrekteSachverhalte hinweisen.

Bewertung

.1 Stärken • Ein Interview fördert die Beteiligung und den Aufbau einer Beziehung zu den Stakeholdern.

• Einfache, schnell anwendbare Technik, die in unterschiedlichen Situationeneingesetzt werden kann.

• Möglichkeit für den Interviewer und die Teilnehmer, ausführliche Diskus-sionen zu führen und Erläuterungen zu den Fragen und Antworten zu geben.

• Nonverbales Verhalten kann beobachtet werden. • Der Interviewer kann weiterführende Fragen stellen und klären, ob er alles richtig verstanden hat.

• Gezielte Erhebung ist möglich, wenn sie auf Vereinbarungen beruht, die vorher getroffen wurden. Ergebnisse lassen sich so eher in der vorgese-henen Zeit erreichen.

• Die befragten Personen erhalten die Möglichkeit, im persönlichen Gespräch ihre Meinung zu äußern, was sie eventuell in einem öffent-lichen Rahmen nicht tun würden.

.2 Grenzen• Relativ zeitaufwändiges Verfahren.• Erfordert Engagement und beträchtlichen Zeitaufwand der Teilnehmer. • Interviewer müssen für diese Arbeit ausgebildet sein. Insbesondere für

Interview

345

Techniken

10.25.4

unstrukturierte Interviews werden besondere Kenntnisse benötigt, ein-schließlich Aktivierungstechniken und aktivem Zuhören.

• Abhängig davon, wie eindeutig die Themen während des Interviews geklärt wurden, können die Ergebnisse vom Interviewer subjektiv inter-pretiert werden.

• Es besteht das Risiko, den befragten Personen unbeabsichtigt Suggestiv-fragen zu stellen.

Item Tracking

Zweck

Item Tracking dient der Erfassung und der Zuordnung von Zuständigkeiten fürSachverhalte und Interessen der Stakeholder, die Einfluss auf die Lösung habenoder eine Lösung erfordern.

BeschreibungItem Tracking ist ein planmäßiger Ansatz des Business-Analysten, sich mit Anliegenvon Stakeholdern zu beschäftigen. Stakeholder können solche Anliegen als Akti-vität, Annahme, Restriktion, Abhängigkeit, Mangel, Verbesserung oder Sachverhaltbezeichnen.

Wenn ein solches Anliegen erstmals von einem Stakeholder geäußert wird, prüftder Business-Analyst, welchen Einfluss es auf das Unternehmen haben könnteund ob es berechtigt ist. Falls das der Fall sein sollte, wird das Anliegen als Itemklassifiziert und dokumentiert, um es so auf dem Weg bis zur Erledigung verfolgenzu können. Im Lebenszyklus des Item wird es dann einem oder mehreren Zustän-digen für die Bearbeitung zugeordnet.

Beim Item Tracking wird der Weg von der ersten Aufzeichnung des Anliegensbis zur Erledigung verfolgt. Die Dokumentation kann den betroffenen Stakehol-dern zugänglich gemacht werden, um Transparenz zu gewährleisten und Fort-schritte sichtbar zu machen.

Elemente

.1 Verzeichnis der ItemsDie Items können mithilfe verschiedener Software-Anwendungen oder manuellverwaltet und bestimmten Stakeholdern zugänglich gemacht werden. Jedesaufgezeichnete Item kann alle oder eine größere Anzahl von Attributen aufweisen,z.B.:

Item Tracking

346

Techniken

10.26

10.26.1

10.26.2

10.26.3

• Bezeichnung des Item: Eindeutiger Name, der es unterscheidbar macht von allen anderen.

• Zusammenfassung: Kurze Beschreibung des Item.• Kategorie: Einordnung in Gruppen von Items mit vergleichbaren Eigenschaften.

• Typ: Art des Item.• Erhebungsdatum: Datum, an dem das Item zum ersten Mal erfasst wurde.• Identifiziert durch: Person, die dieses Anliegen erstmals eingebracht hat. • Auswirkungen: Die möglichen Folgen, falls dieses Anliegen nicht bis zum Fertigstellungstermin abgearbeitet ist. Die Folgen können zu dem erforderlichen Zeitaufwand, den Kosten, dem Umfang oder der Quali-tät in Beziehung gesetzt werden.

• Priorität: Bedeutung des für die betroffenen Stakeholder.• Erledigungsdatum: Datum, an dem der Sachverhalt erledigt oder beendet sein soll.

• Verantwortlicher: Mitarbeiter, der für die abschließende Erledigung verantwortlich ist.

• Bearbeiter: Mitarbeiter, der das Anliegen selbst bearbeitet.• Vereinbarte Strategie: Die für das Anliegen einvernehmlich vereinbarte Strategie, die beispielsweise Akzeptieren, Verfolgen, Ignorieren, Folgenmildern oder Vermeiden lauten könnte.

• Status: Der gegenwärtige Bearbeitungsstand des Anliegens. Beispiele können sein: eröffnet, zugeordnet, bearbeitet oder aufgegeben .

• Bearbeitungsprotokoll: Logbuch, in dem die Details der Bearbeitung dokumentiert werden bis hin zur Abnahme des Ergebnisses.

• Eskalationsmatrix: Zeigt die Zuständigkeiten für den Fall, dass das Anliegen nicht bis zu dem vorgegebenen Termin erledigt ist.

.2 Item ManagementDie operative Bearbeitung jedes Item wird durch den Bedarf der Stakeholderund durch betriebliche Prozessstandards geregelt. In einigen Fällen kann einItem selbst wiederum ein anderes oder mehrere andere Items auslösen, dieebenfalls dokumentiert und fortgeschrieben werden müssen. Dabei ist daraufzu achten, dass Doppelarbeiten vermieden und die Arbeiten koordiniert werden.Jedes Item muss bis zum Abschluss erfasst und dokumentiert werden.

.3 KennzahlenAlle Stakeholder profitieren von der detaillierten Information über die Items undderen Bearbeitungsstand. Diese Items können individuell abgearbeitet werdenoder es werden Key-Performance-Indikatoren für den Abwicklungsprozess erar-beitet.

Item Tracking

347

Techniken

Abhängig vom Ergebnis können die Stakeholder bestimmen, wie gut• das Anliegen mit den geplanten Ressourcen gelöst wurde• das Anliegen voranschreitet• der Bearbeitungsprozess dokumentiert und verfolgt wird.

Bewertung

.1 Stärken• Item Tracking stellt sicher, dass berechtigte Anliegen der Stakeholder erfasst, verfolgt und zur Zufriedenheit der Beteiligten gelöst werden.

• Gibt Stakeholdern die Gelegenheit, ein Ranking für ausstehende Vorhaben zu erstellen.

.2 Grenzen• Kann dazu führen, dass der Aufwand für die Administration den Nutzen des ganzen Vorhabens übersteigt.

• Kann Zeit kosten, die besser in andere Anliegen investiert worden wäre, und die Stakeholder könnten sich zu lange mit Details und Auswertun-gen beschäftigen.

Lessons Learned

Zweck

Lessons Learned dienen dazu, Erfolge, Chancen, Fehler und Verbesserungsvorschlägezu erfassen und zu dokumentieren, um daraus für spätere Vorhaben zu lernen.

Beschreibung

Eine Lessons-Learned-Sitzung kann helfen, notwendige Veränderungen im Prozessder Business-Analyse zu ermitteln oder Erfolge bewusst zu machen, die bei derzukünftigen Arbeit genutzt werden können. Dieser Ansatz kann auch schon amEnde eines Meilensteins sinnvoll genutzt werden.

Lessons-Learned-Sitzungen können unterschiedlich konzipiert werden. Sie solltenein für die beteiligten Stakeholder geeignetes Format haben, entweder als for-melle, moderierte Meetings mit eindeutiger Agenda oder als informelle Arbeits-sitzungen. Lassen sich nennenswerte Erfolge feiern, dann sollte das auch ange-messen zelebriert werden.

Lessons Learned

348

Techniken

10.27

10.26.4

10.27.1

10.27.2

Elemente

Lessons-Learned-Sitzungen können sich beschäftigen mit dem Review von• Aktivitäten der Business-Analyse oder deren Ergebnissen• der erarbeiteten Lösung, dem Produkt oder dem Service• eingeführten oder aussortierten technischen Anwendungen• Einflüssen auf organisatorische Prozesse• Performance-Erwartungen und Ergebnissen• Kernursachen für die Performance• Empfehlungen für das zukünftige Verhalten.

Bewertung

.1 Stärken• Lessons Learned sind nützlich, um Chancen für Verbesserungen zu ermitteln.• Fördern die Arbeitszufriedenheit von Teams, besonders nach schwierigen Phasen.

• Verstärken positive Erfahrungen und Erfolge.• Verringern Risiken für zukünftige Aktionen.• Liefern greifbare Werte oder Kennzahlen zu einem abgeschlossenen Vorhaben.

• Erkennen Stärken und Versäumnisse hinsichtlich Projektstruktur, Methodologie oder eingesetzter Werkzeuge.

.2 Grenzen• Ehrliche Diskussionen können verhindert werden, wenn Einzelne ver-suchen, Schuldige für Versäumnisse oder Fehler zu finden.

• Teilnehmer mögen sich nicht bereit erklären, Probleme zu dokumentieren und zu diskutieren.

• Eine proaktive Moderation ist u.U. erforderlich, damit die Sitzung auf Lösungen und Verbesserungsmöglichkeiten fokussiert bleibt.


Zweck Kennzahlen und Key-Performance-Indikatoren dienen dazu, die Leistung von Lösun-gen, Lösungskomponenten und anderen wichtigen Sachverhalten zu messen.


349

Techniken

10.27.3

10.27.4

10.28

10.28.1

Beschreibung

Eine Kennzahl ist ganz allgemein eine Maßzahl, die zur Quantifizierung dientund von einem Unternehmen zur Erfolgsmessung verwendet wird. Ein Indikatorkennzeichnet eine bestimmte numerische Messung, die den Grad des Fortschrittsbei der Zielerreichung, einem Arbeitsergebnis, einer Aktivität oder bei den Inputsfür andere Prozesse anzeigt. Ein Key-Performance-Indikator misst den Fortschrittim Hinblick auf die Erreichung eines strategischen Ziels. Als Reporting wird derVorgang bezeichnet, bei dem Stakeholder in einem bestimmten Format und inbestimmten Abständen Informationen über die Kennzahlen erhalten.

Kennzahlen und Reporting sind wichtige Bestandteile des Monitoring und derValidierung. Monitoring ist ein kontinuierlicher Prozess der Erfassung von Daten,um zu ermitteln, wie gut eine Lösung im Vergleich zu den erwarteten Ergebnissenumgesetzt wurde. Validierung ist die systematische und objektive Bewertungeiner Lösung, um ihren Status und ihren Beitrag zur Zielerreichung zu ermittelnund um festzustellen, wie Lösungen verbessert werden können, um die Zielebestmöglich zu erreichen. Der Fokus eines Monitoring- oder Validierungssystemsliegt auf den geplanten Zielen und Beiträgen einer Lösung, wie auch auf dendamit verbundenen Inputs, Aktivitäten und Outputs.

Elemente

.1 IndikatorenEin Indikator stellt eine bestimmte Messgröße dar für ein Ziel, einen Bedarf,eine Auswirkung, einen Output, eine Aktivität oder einen Input in Form einerTabelle oder einer Grafik. Für jeden interessierenden Sachverhalt gibt es mindestenseinen Indikator, mit dessen Hilfe er ordnungsgemäß gemessen werden kann,bei einigen Sachverhalten kann es auch sein, dass mehrere Indikatoren benötigtwerden. Ein guter Indikator hat sechs Merkmale: • Eindeutig: genau und unmissverständlich• Relevant: dem Faktor angemessen• Wirtschaftlich: zu angemessenen Kosten verfügbar• Angemessen: erlaubt die Leistungsbewertung• Quantifizierbar: kann unabhängig validiert werden• Glaubwürdig und nachvollziehbar: basiert auf Tatsachen und gründ-licher Recherche.

Zusätzlich zu diesen Merkmalen sind die Interessen der Stakeholder wichtig.Bestimmte Indikatoren sind besser geeignet als andere, wenn es um die Leis-tungssteigerung oder -verbesserung durch die Stakeholder geht. Im Laufe derZeit können Schwächen bei einzelnen Indikatoren ermittelt und ausgemerztwerden.


350

Techniken

10.28.2

10.28.3

Nicht alle Faktoren sind direkt messbar. Wenn Daten für direkte Indikatorennicht verfügbar sind oder sich nicht in regelmäßigen Abständen erfassen lassen,können stellvertretende Variable verwendet werden. Wenn beispielsweise keineUmfrage zur Kundenzufriedenheit vorhanden ist, kann ein Unternehmen dieEntwicklung des Anteils von Altkunden am Umsatz als Indikator benutzen.

Bei der Festlegung eines Indikators sind die Datenquelle, die Art der Erfassung,die erfassende Person sowie Kosten, Häufigkeit und Schwierigkeiten bei derErfassung zu berücksichtigen. Sekundäre Datenquellen mögen besonders wirt-schaftlich sein, sollen aber die weiteren Merkmale für einen guten Indikatorerfüllt werden, können auch vorhergehende Untersuchungen wie Umfragen,Interviews oder direkte Beobachtungen notwendig sein. Von der Art der Daten-erfassung hängen ganz entscheidend die Kosten eines Monitoring-, Validie-rungs- und Berichtssystems ab.

.2 Kennzahlen Eine Kennzahl ist ein quantifizierbares Maß für einen Indikator, das zu bestimmtenZeitpunkten ermittelt wird. Eine Zielkennzahl ist ein Wert, der in einem festge-legten Zeitraum erreicht werden soll. Bei der Festlegung einer Kennzahl füreinen Indikator ist es wichtig, den Ausgangspunkt der Planung, die verfügbarenRessourcen zur Verbesserung der betrachteten Größe und die politische Situationzu beachten.

Eine Kennzahl kann ein bestimmter Punkt, ein Grenzwert oder eine Spannesein. Eine Spanne kann nützlich sein, wenn es sich um eine neue Kennzahl han-delt. Die Zeitvorgabe dafür, eine Zielkennzahl zu erreichen, kann mehrere Jahreumfassen, sie kann aber auch auf ein Jahr oder ein Quartal bezogen sein. Es istnicht ungewöhnlich, die Vorgaben auch kurzfristig anzupassen.

.3 Struktur Zum Aufbau eines Monitoring- und Validierungssystems sind Verfahren zurDatenerfassung, zur Datenanalyse und zum Berichtswesen notwendig, außerdemmüssen die Basisdaten ermittelt werden. Bei der Datenerfassung ist zu regeln,wo die Daten erfasst werden, welche Erhebungstechniken und Verfahren zurDatenerfassung zu nutzen sind, wie häufig erfasst werden soll und wer dafürzuständig ist. Die Analysemethode spezifiziert die Verfahren zur Durchführungder Analyse und zur Ermittlung der Nutzer, die großes Interesse daran haben,wie die Analyse durchgeführt wird. Das Berichtsverfahren beinhaltet die Berichts-vorlagen, die Empfänger, die Berichtshäufigkeit und die zu nutzenden Kommu-nikationsmittel. Basisinformationen sind die Daten, die direkt vor oder zu Beginneines Messzeitraums geliefert werden. Ausgangsdaten werden verwendet, umInformationen über die aktuelle Leistung zu erhalten und den Fortschritt abdiesem Punkt zu messen. Sie sind für jeden Indikator zu erfassen, zu analysierenund festzuhalten.


351

Techniken

Drei Schlüsselfaktoren – Reliabilität, Validität und Aktualität – können heran-gezogen werden, um die Qualität der Indikatoren und ihrer Kennzahlen zuermitteln. Reliabilität ist das Ausmaß, zu welchem der Datenerfassungsansatzräumlich und zeitlich stabil und konsistent ist. Validität ist das Ausmaß, zu demDaten die vom Unternehmen beabsichtigte Leistung eindeutig und direkt messen.Aktualität misst, inwieweit die Anforderungen des Managements erfüllt werdenhinsichtlich Berichtsfrequenz und unveränderter Gültigkeit der Kennzahlen.

.4 BerichterstattungÜblicherweise werden in Berichten die Basisdaten, die aktuellen Kennzahlenund Zielkennzahlen miteinander verglichen und geben den Wert der ermitteltenAbweichungen sowohl in absoluten als auch in relativen Werten an. In denmeisten Fällen sind Trends glaubwürdiger und wichtiger als absolute Kennzahlen.Visuelle Präsentationen sind meistens wirkungsvoller als Tabellen, insbesonderewenn Text zur Erläuterung der Daten verwendet wird.

Bewertung

.1 Stärken• Der Aufbau eines Monitoring- und Validierungssystems erlaubt es den Stakeholdern, zu begreifen, wie nahe eine Lösung einem Ziel kommt und welchen Effekt die eingesetzten Ressourcen auf das Ergebnis haben.

• Indikatoren, Kennzahlen und Berichterstattung erleichtern auch die Aus-richtung eines Unternehmens, indem Ziele und Zielvorgaben, geeignete Lösungen und zugehörige Aufgaben und Ressourcen miteinander ver-knüpft werden.

.2 Grenzen • Werden mehr Daten als nötig erfasst, entstehen unnötige Kosten für die Erfassung, Analyse und Berichterstattung. Projektmitglieder können dadurch auch von anderen Aufgaben abgelenkt werden. Bei agilen Projekten ist dies besonders relevant.

• In bürokratischen Systemen werden viele Daten erfasst, die keine nützlichen und zeitnahen Berichte hervorbringen, die für schnelle Reaktionen notwendigwären. Die mit der Erfassung von Kennzahlendaten beauftragten Personen müssen Feedback erhalten, damit sie verstehen, welche Auswirkungen ihre Handlungen auf die Qualität der Projektergebnisse haben.

• Werden Kennzahlen zur Leistungsbewertung verwendet, bemühen sich die von der Messung betroffenen Personen vermutlich, ihre Leistungen in Bezug auf diese Kennzahlen zu verbessern, selbst wenn dies zu sub-optimalen Leistungen bei anderen Aktivitäten führt.


352

Techniken

10.28.4

Mind Mapping

Zweck

Mind Mapping wird dazu verwendet, Gedanken, Ideen und Informationen zuartikulieren und geordnet zu dokumentieren.

Beschreibung

Mind Mapping ist eine strukturierte, nicht-lineare Technik zur Dokumentationvon Gedanken, Ideen und Informationen. Ausgehend von einem zentralen Punkt(Idee, Problem, Lösung etc.) werden weitere Punkte auf der nächsten Ebeneabgeleitet, die den übergeordneten Begriff erklären. Dieser Zerlegungsprozesskann über mehrere Stufen so weit fortgeführt werden, bis eine Idee, ein Problem,eine Lösung etc. vollständig beschrieben ist. Die Punkte werden durch Linien somiteinander verbunden, dass ein Schlüsselbegriff die zugehörigen Begriffe zusam-menfasst.

Mind Maps können von Individuen oder von Teams gemeinsam erstellt werden.Sie können auf einer Tafel oder einem Papier entwickelt werden oder mit Hilfespezialisierter Software.

Der Business-Analyst nutzt Mind Maps, um• Ideen für komplexe Konzepte oder Probleme zu sammeln oder solche Konzepte oder Probleme zu verstehen

• Beziehungen zwischen verschiedenen Facetten eines Problems zu ermitteln und dabei Kreativität und kritisches Denkvermögen zu nutzen

• einen zusammenfassenden Überblick über komplexe Probleme oder Konzepte zu geben.

Es gibt kein standardisiertes Format für eine Mind Map. Dem Mind Mappingliegt im Kern die Idee zugrunde, Informationen auf eine Art und Weise zuerfassen, wie das menschliche Gehirn Informationen verarbeitet. Die folgendeAbbildung soll die generelle Struktur und die Nutzung einer Mind Map verdeut-lichen.

Mind Mapping

353

Techniken

10.29

10.29.1

10.29.2

Abb. 10.29.1: Beispiel einer Mind Map

Elemente

.1 AusgangsthemaDas Ausgangsthema einer Mind Map ist ein Gedanke oder das Konzept, umdas es hier geht. Dieser Begriff wird im Zentrum positioniert, so dass vieleThemen und Sachverhalte damit verbunden werden können. Für das Ausgangs-thema wird oft auch ein Bild verwendet, da Bilder implizit viele Informationen insich bergen, was die Ideensammlung fördern kann.

.2 ThemenThemen sind Gedanken oder Konzepte, die das Ausgangsthema erklären odergenauer definieren. Die Verbindung zum Ausgangsthema wird durch eine Linieverdeutlicht. Sie wird oft mit einem Schlüsselbegriff versehen. Die Anzahl derThemen hängt davon ab, was alles benötigt wird, um das Ausgangsthema mög-lichst vollständig zu beschreiben.

Mind Mapping

354

Techniken

Ausgangsthema

Teilthema 1.1

Teilthema 1.2

Teilthema 2.1

Teilthema 2.2

Thema 1

Thema 2

Teilthema 2.2.1

Teilthema 2.2.2

Teilthema 3.1

Teilthema 3.2

Teilthema 4.1

Teilthema 4.2

Thema 3

Thema 4

Teilthema 4.3

Teilthema 4.3.1

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüssel-begriff

Schlüsselbegriff

Schlüsselbegriff

Schlüssel-begriff

Schlüssel-begriffÄste

Äste

10.29.3

.3 Teilthemen Teilthemen sind Gedanken oder Konzepte, die das Thema erklären oder genauerdefinieren und deswegen mit ihm unmittelbar verbunden sind. Die Beziehungzum Thema wird ebenfalls durch eine Linie verdeutlicht. Auch hier hängt dieAnzahl der Teilthemen davon ab, was alles benötigt wird, um das Themamöglichst vollständig zu beschreiben.

.4 ÄsteÄste sind die Verbindungslinien zwischen Ausgangsthema, Themen und Teil-themen. Sie können mit einem Schlüsselbegriff versehen werden, der die Artder Beziehung kenntlich macht.

.5 SchlüsselbegriffeEin Schlüsselbegriff ist ein einzelnes Wort, mit dem die Art der Beziehungbenannt wird. Solche Schlüsselbegriffe helfen bei der Gruppierung und regenAssoziationen an, fördern also die Vollständigkeit bei einem Thema oder Teilthema.

.6 FarbeFarben können zusätzlich verwendet werden, um Themen und Teilthemen undihre Beziehungen zu kategorisieren, zu priorisieren oder zu analysieren. Es gibtdazu keine Standards. Jeder Anwender nutzt die Farben, die ihm am bestengeeignet erscheinen.

.7 BilderBilder können dazu genutzt werden, umfangreiche Informationen auszudrücken,die sich kaum in einen Begriff pressen lassen. Sie fördern die Kreativität und dieInnovation, indem sie zusätzliche Ideen, Gedanken und Assoziationen erleichtern.

Bewertung

.1 Stärken• Mind Maps können als eine wirksame Technik zur Zusammenarbeit und Kommunikation genutzt werden.

• Komplexe Gedanken, Ideen und Informationen werden zusammen-gefasst, dabei werden die Gesamtzusammenhänge sichtbar.

• Verbindungen und Teilthemen fördern das Verständnis und die Fähigkeit zur Entscheidungsfindung.

• Mind Maps fördern Assoziationen, indem sie Beziehungen sichtbar machen und so eine kreative Problemlösung unterstützen.

• Können bei der Vorbereitung und Durchführung von Präsentationen helfen.

Mind Mapping

355

Techniken

10.29.4

.2 Grenzen• Können als Werkzeug des Brainstormings in der Ideensammlung missbrauchtwerden, da die Strukturen einen ungehinderten Ideenfluss eventuell behindern.

• Es kann schwierig sein, ein gemeinsames Verständnis über die Struktur einer Mind Map zu kommunizieren.

Analyse nicht-funktionaler Anforderungen

Zweck

Eine Analyse nicht-funktionaler Anforderungen setzt sich mit Anforderungenauseinander, die bestimmen, wie gut die funktionalen Anforderungen bewältigtwerden sollen. Mit ihnen werden Kriterien spezifiziert, die darüber Auskunftgeben, wie gut ein System funktioniert – nicht aber, was es alles tut. Letzteresbeschreiben die funktionalen Anforderungen.

Beschreibung

Nicht-funktionale Anforderungen werden auch als Qualitätsmerkmale bezeichnet.Sie sind oft direkt mit den Lösungen selbst verbunden, beziehen sich abermeistens gleichzeitig auch auf die Prozesse und die beteiligten Menschen. Sieergänzen die funktionalen Anforderungen an eine Lösung, identifizieren Res-triktionen für diese Anforderungen und beschreiben Qualitätsmerkmale, dieeine Lösung bieten muss, wenn die funktionalen Anforderungen erfüllt werden.

Nicht-funktionale Anforderungen werden meistens in Aussagesätzen beschriebenoder in Matrizen angeführt. Aussagesätze zu nicht-funktionalen Anforderungenbedeuten in der Regel eine Begrenzung. Beispielsweise dürfen Fehler nicht häu-figer als x % vorkommen, Transaktionen dürfen nicht länger als y Sekundendauern oder das System muss mindestens eine Verfügbarkeit von z % haben.

Elemente

.1 Arten nicht-funktionaler AnforderungenBeispiele für nicht-funktionale Anforderungen:• Verfügbarkeit: In welchem Ausmaß ist eine Lösung betriebsfähig und zugänglich? Wird häufig mit einer Prozentzahl angegeben, zu der die Lösung genutzt werden kann.

• Kompatibilität: Wie effektiv kann eine Lösung mit anderen Komponen-ten zusammenarbeiten, zum Beispiel, wie gut arbeitet ein Prozess mit einem anderen zusammen?


356

Techniken

10.30

10.30.1

10.30.2

10.30.3

• Funktionalität: In welchem Ausmaß erfüllt eine Lösung die Anforde-rungen der Anwender einschließlich Eignung, Korrektheit und Inter-operabilität?

• Wartbarkeit: Wie einfach ist es, eine Lösung oder eine Komponente zumodifizieren, etwa um Fehler zu beseitigen, die Leistung zu verbessernoder die Lösung an eine veränderte Umwelt anzupassen?

• Performance-Effizienz: In welchem Ausmaß erfüllt eine Lösung die geforderten Funktionen bei einem möglichst geringen Ressourcen-verbrauch? Kann auch für eine bestimmte Zeitperiode ermittelt werden oder bei Belastungsspitzen oder bei geringer Auslastung.

• Portabilität: Wie einfach kann eine Lösung oder eine Komponente voneiner Umwelt in eine andere übertragen werden?

• Zuverlässigkeit: In welchem Ausmaß funktioniert eine Lösung fehlerfreiund störungsfrei? Kann beispielsweise in der durchschnittlichen Zeit-spanne ausgedrückt werden, die zwischen zwei Fehlerereignissen liegt.

• Skalierbarkeit: In welchem Ausmaß kann eine Lösung ausgebaut werden oder wachsende Volumina bewältigen?

• Sicherheit: In welchem Ausmaß verhindert eine Lösung, dass Ergeb-nisse oder Komponenten der Lösung missbräuchlich genutzt, modifi-ziert, zerstört oder Unberechtigten offengelegt werden?

• Benutzerfreundlichkeit: Wie einfach kann ein Nutzer die Anwendung erlernen?

• Zertifizierung: Inwieweit erfüllt eine Lösung bestimmte Standards oder Vereinbarungen eines Wirtschaftszweiges?

• Compliance: Inwieweit werden gültige Regelungen, finanzielle oder gesetzliche Vorgaben eingehalten?

• Lokalisierung: Inwieweit sind lokale Sprachen, Gesetze, Währungen, Kulturen, Rechtschreibung in den Lösungen oder Lösungskomponen-ten berücksichtigt?

• Service Level Agreements: Inwieweit erfüllt eine Lösung Vorgaben, die zwischen dem Lieferanten und dem Nutzer vereinbart wurden?

• Ausbaubarkeit: Inwieweit ist eine Lösung in der Lage, neue Funktiona-litäten zusätzlich zu erfüllen?

.2 Messung nicht-funktionaler AnforderungenNicht-funktionale Anforderungen beschreiben qualitative Merkmale häufig inallgemeinen Begriffen wie zum Beispiel „der Prozess muss leicht zu erlernensein“ oder „das System soll schnell antworten“. Nicht-funktionale Anforderungensollten soweit möglich quantifiziert werden. Nur dann sind sie für die Entwicklernützlich und am Ende auch überprüfbar.


357

Techniken

Beispiel:• Die Anforderung „Der Prozess muss leicht zu erlernen sein“ kann beispielsweise durch die Vorgabe „90% der Nutzer müssen in der Lage sein, den Prozess nach 6 Stunden Einweisung zu nutzen“ quan-tifiziert werden.

• „Das System muss schnell antworten“ kann messbar gemacht werden durch die Vorgabe „das System muss in 90% der Fälle in maximal 2 Sekunden antworten“.

Einige Kategorien nicht-funktionaler Anforderungen werden durch die Urheberdieser Anforderungen definiert.

Zum Beispiel:• Anforderungen an eine Zertifizierung werden im Allgemeinen in einemquantifizierbaren Detaillierungsgrad von den Organisationen definiert, die diese Standards gesetzt haben – zum Beispiel ISO-Zertifizierungs-standards.

• Ähnliches gilt für Anforderungen an die Compliance oder an die Lokalisierung.

• Service Level Agreements beinhalten fast immer quantifizierbare und messbare Kriterien für die Einhaltung.

• Aus der Unternehmensarchitektur leiten sich normalerweise die Anforderungen der Lösungsumgebung ab und spezifizieren, welche Plattform oder welche anderen Attribute der Umwelt berücksichtigt sein müssen.

.3 Kontextabhängigkeit nicht-funktionaler AnforderungenNicht-funktionale Anforderungen sind oft von dem jeweiligen Kontext abhängig.So kann beispielsweise eine Autorität bestimmte Compliance- oder Sicherheits-anforderungen festlegen. Wenn ein Unternehmen in ein anderes Land expandiert,müssen die dort gültigen Vorgaben eingehalten werden. Nur wenn diese nicht-funktionalen Anforderungen rechtzeitig erkannt werden, sind die Lösungen fürdie Stakeholder von Nutzen.

Die Berücksichtigung nicht-funktionaler Anforderungen kann unter UmständenAuswirkungen auf andere Anforderungen haben. So können beispielsweiseRegelungen oder Ressourcen in einer Region die Wartbarkeit einer Lösung beein-flussen, was dazu führen kann, dass in dieser Region eine niedrigere Perfor-mance-Effizienz oder Zuverlässigkeit hingenommen werden muss.

Da ein Kontext seiner Natur nach sehr dynamisch ist, müssen nicht-funktionaleAnforderungen häufig angepasst oder ersetzt werden. Der Business-Analystsollte die jeweilige Stabilität des Kontextes berücksichtigen, wenn er nicht-funk-tionale Anforderungen untersucht.


358

Techniken

Bewertung

.1 Stärken• Nicht-funktionale Anforderungen verdeutlichen Restriktionen, die für bestimmte funktionale Anforderungen berücksichtigt werden müssen.

• Bieten quantifizierbare Aussagen darüber, was die funktionalen Anforderun-gen leisten müssen und entscheiden ganz maßgeblich darüber, ob eine Lösung von den Anwendern akzeptiert wird.

.2 Grenzen• Klarheit und Nutzen nicht-funktionaler Anforderungen hängen davon ab, wie gut die Stakeholder den wirklichen Bedarf beurteilen können.

• Erwartungen unterschiedlicher Anwender können sehr unterschiedlich sein, was es oft schwierig macht, diese unter einen Hut zu bringen, da siesehr stark von subjektiven Einschätzungen abhängen, was als erforder-liche Qualität anzusehen ist.

• Verschiedene nicht-funktionale Anforderungen können miteinander in Konkurrenz stehen, zum Beispiel können Anforderungen an die Perfor-mance mit den Anforderungen an die Sicherheit konkurrieren.

• Sehr rigorose Anforderungen oder Restriktionen führen häufig zu teuren Lösungen und zu zusätzlichem zeitlichem Aufwand, was auch die Akzep-tanz beeinträchtigen kann.

• Viele nicht-funktionale Anforderungen sind qualitativer Natur, damit nur schwer quantifizier- und messbar und bieten einen Spielraum bei der Beurtei-lung, wie gut sie erfüllt werden.

Beobachtung

Zweck

Eine Beobachtung wird verwendet, um Informationen zu erheben, indem Akti-vitäten in ihrem jeweiligen Kontext beobachtet und interpretiert werden. Sie bieteteine Grundlage dafür, Anforderungen und Chancen zu identifizieren, Geschäfts-prozesse zu verstehen, Leistungsstandards zu setzen, die Performance einer Lösungzu bewerten oder Training und Weiterentwicklung zu unterstützen.

Beschreibung

Die Beobachtung von Aktivitäten, die auch als Job Shadowing bezeichnet wird,macht es möglich, eine Aktivität aus erster Hand zu überprüfen und in dem

Beobachtung

359

Techniken

10.30.4

10.31

10.31.1

10.31.2

Augenblick, in dem sie erbracht wird. Sie kann entweder in der natürlichenArbeitsumgebung oder in eigens dafür eingerichteten Laboratorien vorgenommenwerden. Die Ziele der Beobachtung sind für die Planung und die methodischeDurchführung maßgeblich.

Es gibt zwei grundlegende Ansätze für die Beobachtung:• Aktiv/Sichtbar: Während der Beobachtung einer Aktivität stellt der Beobachter bei Bedarf Fragen. Obwohl er dadurch den Arbeitsfluss unterbricht, kann der Beobachter schneller verstehen, warum was getan wird oder warum bestimmte Entscheidungen gefällt werden. Beieiner Variante dieser Methode wird noch stärker in die laufende Arbeiteingegriffen, indem der Beobachtete gebeten wird, bestimmte Auf-gaben zu erfüllen. Diese Art einer moderierten Beobachtung erleich-tert es dem Beobachter, seine angestrebten Ziele zu erreichen, die Beob-achtungszeit zu verkürzen oder spezifische Informationen zu erheben.

• Passiv/Unsichtbar: Bei diesem Vorgehen beobachtet der Erheber den Betroffenen, ohne dessen Arbeit zu unterbrechen. Irgendwelche offe-nen Punkte werden nach der Beobachtung geklärt. So kann eher ein natürlicher Arbeitsablauf beobachtet werden. Dabei werden auch die benötigte Zeit und die Qualität der Arbeit sichtbar. Als Variante dieser Methode wird eine Aktivität per Video aufgezeichnet und anschlie-ßend mit der beobachteten Person gemeinsam überprüft, um weitere Informationen zu erhalten.

Da bei dieser Erhebungstechnik gleichzeitig auch die Arbeitsumwelt eines Mit-arbeiters beobachtet wird, können auch die verwendeten Tools und die ver-wendeten Informationsobjekte erkannt werden. Das erleichtert das Verständnisder Aktivitäten und hilft, den Bedarf und mögliche Verbesserungen herauszu-finden. Diese Technik wird auch als Kontextuelles Interview bezeichnet.

Elemente

.1 Ziele der BeobachtungEin klares und eindeutiges Ziel lässt erkennen, was mit der Beobachtung erreichtwerden soll.

Mögliche Ziele einer Beobachtung können sein:• Verstehen der Aktivität und ihrer Elemente, z.B.Aufgaben, Tools, Ereignisse und Interaktionen

• Ermittlung von Verbesserungsmöglichkeiten• Entwicklung von Leistungsmaßstäben• Bewertung von Lösungen und eine Validierung gemachter Annahmen.

Beobachtung

360

Techniken

10.31.3

.2 Vorbereitung der BeobachtungZur Vorbereitung einer Beobachtung gehören die Festlegung des Vorgehens, dasvon den verfolgten Zielen abhängt, und die Entscheidung, wer bei welchen Aktivi-täten zu welchen Zeiten beobachtet werden soll. Der Business-Analyst berücksichtigtdabei die Fähigkeiten und die vorhandenen Erfahrungen der Beteiligten, die Wie-derholungshäufigkeit der zu beobachtenden Aktivitäten sowie alle relevanten Doku-mentationen und Analysen. Außerdem wird ein Zeitplan aufgestellt.

Dieser Beobachtungsplan stellt sicher, dass sich alle Stakeholder des Zwecks derBeobachtung bewusst sind, die Ergebnisse mittragen und ihre Erwartungen andie Erhebung auch erfüllt werden.

.3 Durchführung der BeobachtungZu Beginn der Beobachtung fallen folgende Aufgaben an:• Erklärung, warum die Beobachtung durchgeführt wird• Zusicherung gegenüber dem Beteiligten, dass seine persönliche Leis-tung nicht bewertet wird und dass die Ergebnisse dieser Beobachtung zusammen mit anderen als Ganzes bewertet werden

• Information des Beteiligten, dass er die Beobachtung jederzeit unter-brechen kann

• Empfehlung an den Beobachteten, jegliche Bedenken oder Sorgen schonwährend der Beobachtung oder direkt danach offen anzusprechen.

Während der Beobachtung• wird die Erfüllung der Aktivitäten beobachtet; dabei wird auf typische und untypische Arbeitsschritte ebenso geachtet wie auf die genutzten Werkzeuge und die Informationsinhalte

• wird alles Beobachtete aufgezeichnet, wie etwa die Zeit, die für die Erledi-gung benötigt wird, die erreichte Qualität, jegliche Anomalität in dem Prozess sowie die Bedenken und Fragen, die beim Beobachter auftauchen

• werden schon während der Erhebung oder unmittelbar danach Fragengestellt, um sicherzugehen, dass die aus den Beobachtungen gezoge-nen Schlussfolgerungen richtig sind.

.4 Bestätigung und Abstimmung der BeobachtungsergebnisseNach der Beobachtung überprüft der Business-Analyst seine Aufzeichnungen,um sie dann gemeinsam mit den Beteiligten zu besprechen und noch offenePunkte zu klären. Werden die Dokumente den Beobachteten zugänglich gemacht,lassen sich leichter eventuell bestehende Bedenken zerstreuen.

Die so validierten Ergebnisse werden mit anderen Beobachtungsergebnissen zusam-mengeführt, um Ähnlichkeiten, Unterschiede und Trends zu erkennen. Die Ergebnissewerden verdichtet und mit den Zielen der Erhebung abgeglichen. Bedarfe undentdeckte Verbesserungsmöglichkeiten werden den Stakeholdern mitgeteilt.

Beobachtung

361

Techniken

Bewertung

.1 Stärken• Beobachter gewinnen eine realistische und praxisnahe Einsicht in die Aktivitäten innerhalb eines Prozesses.

• Informell erledigte Aufgaben und Umgehungen von Regelungen können erkannt werden.

• Die erreichte Produktivität kann aus erster Hand und unter realitätsnahen Bedingungen erkannt und mit bestehenden Leistungsmaßstäben vergli-chen werden.

• Verbesserungsvorschläge werden durch objektive und quantitative Aussagen abgesichert.

.2 Grenzen• Beobachtungen können die Arbeit stören und damit auch die erbrachte Leistung beeinträchtigen.

• Können von den Beobachteten als aufdringlich und bedrohlich empfun-den werden.

• Der Beobachtete kann sein Arbeitsverhalten während der Beobachtung ändern.

• Verfahren ist zeitaufwändig.• Für geistige Arbeiten, die nicht direkt beobachtet werden können, ist die Technik wenig geeignet.

Organisationsmodellierung

Zweck

Die Organisationsmodellierung wird dazu verwendet, Rollen, Verantwortlichkeitenund Berichtsstrukturen innerhalb eines Unternehmens zu beschreiben und dieseStrukturen auf die betrieblichen Ziele abzustimmen.

Beschreibung

Ein Organisationsmodell zeigt, wie eine Organisation oder eine Organisations-einheit strukturiert ist. Zweck jeder Organisationseinheit ist es, Menschen zusam-menzuführen, um gemeinsam Leistungen zu erbringen. Vergleichbare Qualifi-kation oder die gemeinsame Bearbeitung eines bestimmten Marktes könnenGründe für die Bildung einer Organisationseinheit sein.


362

Techniken

10.31.4

10.32.1

10.32.2

10.32

Ein Organisationsmodell ist eine grafische Darstellung der Organisationseinheit,aus der sichtbar werden:• Grenzen der Gruppe (wer gehört alles dazu)• formale Beziehungen zwischen den Mitgliedern (wer ist wem unter-stellt)

• funktionale Rolle jeder Person• Schnittstellen (Interaktionen und Abhängigkeiten) zwischen dieser Einheit und anderen Einheiten oder Stakeholdern.

Elemente

.1 Typen organisatorischer ModelleEs gibt drei typische Organisationsmodelle:• Funktionale Orientierung: Die Zusammensetzung der Gruppe basiert auf vergleichbaren Fähigkeiten oder Erfahrungen. Diese Organisations-form fördert normalerweise die Standardisierung der Arbeit oder der Prozesse. Funktionale Organisationseinheiten können dazu beitragen, Kosten zu senken. Sie verhindern, dass mehrfach an verschiedenen Stellen die gleiche Arbeit erledigt wird. Auf der anderen Seite können Koordinations- und Kommunikationsprobleme die Folge sein (dieses Modell fördert das sogenannte Silo-Denken).

Abb. 10.32.1: Funktionale Gliederung eines Organisationsmodells


363

Techniken

10.32.3

Oberste LeitungsebeneName Stelleninhaber

ManagementfunktionName Stelleninhaber


UnbesetzteStelle

Leiter Geschäftsbereich(keine Mitarbeiter)

MitarbeiterName Stellen-inhaber




• Marktorientierung (Objektorientierung): Hier steht das Ziel im Vorder-grund, Leistungen für bestimmte Kundengruppen, Regionen, Projekte oder Prozesse zu erbringen. Derartige objektorientierte Strukturen machen es einem Unternehmen leichter, die Anforderungen ihrer Kunden (bzw. der Objekte) zu erfüllen. Das kann die Nachteile mit sichbringen, dass bei der Erledigung der Arbeit in verschiedenen Märkten unterschiedlich vorgegangen wird und dass Doppelarbeiten auftreten.

Abb. 10.32.2: Marktorientiertes Organisationsmodell

• Matrixmodell: Hier gibt es jeweils einen Manager für jede Funktion und einen anderen für ein Objekt (Produkt, Region, Dienstleistung oder Kunde). Die Mitarbeiter berichten an einen Linienvorgesetzten, der für die Performance bestimmter Aufgaben und damit auch für eine Effizienzsteigerung zuständig ist, sowie an einen Vorgesetzten, der für einen Markt (oder Produkt, Dienstleistung oder Projekt) zustän-dig ist und dafür Verantwortung trägt, dass das Produkt oder die Dienstleistung über mehrere funktionale Zuständigkeiten hinweg koordiniert wird. Die wesentliche Herausforderung des Matrixmodells liegt darin, dass jeder Mitarbeiter zwei Vorgesetzte hat, die sich auf unterschiedliche Ziele konzentrieren, was zu Konflikten führen kann.


364

Techniken

OberstesLeitungsorgan

Stabsstelle

Rechnungswesen

Marketing undVertrieb

Forschung undEntwicklung

Markt 1

Rechnungswesen



Rechnungswesen



Planung

Produktion

Finanzen(Shared Services)

Markt 2 Markt 3

Abb. 10.32.3: Matrixmodell

.2 RollenZu einer Organisationseinheit gehört immer eine Anzahl definierter Rollen. JederMitarbeiter bringt bestimmte Fähigkeiten und spezielles Wissen ein, hat spezifischeVerantwortlichkeiten, übernimmt bestimmte Aufgaben und hat definierte Bezie-hungen zu anderen Rollen in dem Unternehmen.

.3 SchnittstellenJede Organisationseinheit hat Schnittstellen zu anderen Organisationseinheiten.Schnittstellen (Interaktionen) können aus Kommunikationsbeziehungen oderArbeitsflüssen resultieren, wenn eine Organisationseinheit Ergebnisse ihrer Arbeitan eine andere Einheit weitergibt.

.4 OrganigrammeDie gängigste Form zur Dokumentation des Organisationsmodells ist ein Orga-nigramm.

Es gibt keinen Dokumentationsstandard für Organigramme, allerdings sind einigeKonventionen relativ weit verbreitet.• Rechteck: • Symbolisiert eine Organisationseinheit wie zum Beispiel Mitarbeiter, Gruppen, Abteilungen oder Divisionen

• Symbolisiert eine Rolle innerhalb eines Unternehmens und dazu die Menschen, die diese Rolle tragen.


365

Techniken

Projektmanager Mitarbeiter

Region 1

Linienvorgesetzter

Mitarbeiter

Mitarbeiter

Mitarbeiter

Region 2

Linienvorgesetzter

Mitarbeiter

Mitarbeiter

Mitarbeiter

Region 3

Linienvorgesetzter

Mitarbeiter

Mitarbeiter

Prozessmanager

Produktmanager

• Linie:• Symbolisiert die Berichtswege zwischen Organisationseinheiten. Eine durchgezogene Linie zeigt typischerweise direkte Weisungsbefug-nisse, wohingegen eine gepunktete Linie entweder eine Kommuni-kationsbeziehung oder eine situative Weisungsbefugnis darstellt.

.5 EinflüsseOrganigramme sind das wichtigste Werkzeug für die Ordinationsmodellierung.Sie zeigen die formale Struktur eines Unternehmens. Der Business-Analystversucht darüber hinaus, informale Strukturen und Kommunikationsbeziehungenwie auch informale Einflüsse zu erkennen, die sich nicht direkt aus einem Schau-bild ablesen lassen.

Gerade für die Planung der Kommunikationsbeziehungen und für die Akzeptanzvon Lösungen ist es wichtig, auch diese informalen Strukturen zu kennen. Sollensie ermittelt werden, kann dies etwa über die Frage „wen kann ich dazu fragen“geschehen. Häufig werden solche Einflüsse auch sichtbar, wenn ein Mitarbeiterin Gruppensitzungen immer wieder für die anderen spricht.

Bewertung

.1 Stärken• Organisationsmodelle sind sehr weit verbreitet.• Ein Organisationsmodell kann als Bestandteil der Dokumentation der Business-Analyse hilfreich sein. Für zukünftige Projekte kann es nützlich sein, zu wissen, wer in einem Vorhaben in welcher Rolle betroffen war.

.2 Grenzen• Organisationsmodelle sind häufig veraltet.• Informelle Beziehungen, Einflüsse und Kommunikationskanäle werden nicht abgebildet und sind schwer zu ermitteln. Häufig widersprechen sie dem formellen Organisationsmodell.

Priorisierung

Zweck

Eine Priorisierung bietet einen Rahmen dafür, Entscheidungen von Stakeholdernzu erleichtern und die relative Bedeutung von Sachverhalten der Business-Analysezu verstehen.

Priorisierung

366

Techniken

10.32.4

10.33

10.33.1

Beschreibung

Priorisierung ist ein Vorgehen, das verwendet wird, um die relative Bedeutungvon Vorhaben zur Business-Analyse zu bestimmen. Diese Bedeutung kann abhän-gig sein von Wert, Risiko, Schwierigkeit der Einführung oder anderen Kriterien.Diese Prioritäten werden benutzt, um zu bestimmen, welche Sachverhaltegenauer untersucht werden sollten, welche Anforderungen zuerst eingeführtwerden sollten oder wie viel Zeit oder sonstige Ressourcen in die Anforderungeninvestiert werden soll.

Es gibt verschiedene Vorgehensweisen zur Priorisierung. Vier Ansätze könnenunterschieden werden:• Gruppierung• Rangfolge• Time Boxing/Budgetierung und• Verhandlung.

Abb. 10.33.1: Ansätze der Priorisierung

Priorisierung

367

Techniken

10.33.2

Ermittle die Bedeutung von Vorhaben der Business-Analyse auf der Grundlagevon Wert, Risiko, Durchführungsschwierigkeit und anderen Kriterien

Berücksichtigung der Zielgruppe und deren Meinungen

Ansätze der Priorisierung

Auswahl eines Verfahrens

Gruppierung

Klassifizierunghohe, mittlere,niedrige Priorität

Rangfolge

Absteigende Folgevom Wichtigstenzum am wenigstenWichtigen

Time Boxing /Budgetierung

Zuordnung festvorgegebener Res-sourcen (Zeit oderGeld)

Verhandlung

Findung einer ein-vernehmlichenPriorisierung allerBeteiligten

Bei der Auswahl eines Verfahrens berücksichtigt der Business-Analyst die Zielgruppe,um deren Bedürfnisse es geht, und ermittelt deren Meinung über den Wert, deneine Anforderung oder ein Vorhaben den jeweiligen Stakeholdern bringt.

Der Business-Analyst überprüft Prioritäten und nutzt die verschiedenen Vorge-hensweisen, sobald es Änderungen im betrieblichen Umfeld, bei den Stakeholdernoder bei den verfügbaren Informationen gibt.

Elemente

.1 GruppierungGruppierung bedeutet, relevante Sachverhalte in vorgegebene Kategorien, z.B.hohe, mittlere oder niedrige Priorität, einzuordnen. Viele Werkzeuge der Busi-ness-Analyse unterstützen dies, indem dort ein derartiges Attribut einer Anfor-derung verwendet wird.

.2 RangfolgeBei einem Rangfolgeverfahren werden die Vorhaben, beginnend mit dem wich-tigsten in absteigender Rangfolge geordnet. Zu manchen modifizierten Ansätzengehört die explizite Rangfolge der Anforderungen in einer strukturierten Liste(etwa im Produkt-Backlog).

.3 Time Boxing/BudgetierungTime Boxing oder Budgetierung priorisieren, indem den verschiedenen VorhabenRessourcen fest zugeordnet werden. Das geschieht häufig, wenn der Lösungswegbereits feststeht. Time Boxing wird oft zur Priorisierung von Anforderungenangewendet, wenn die verfügbaren Ressourcen einer Projektgruppe für einenbestimmten Zeitraum feststehen und auf die bestehenden Anforderungen verteiltwerden. Das Budgetierungsverfahren wird eingesetzt, wenn die Gruppe übereinen festen Geldbetrag verfügen kann. Dieser Ansatz wird oft dann benutzt,wenn es klare Vorgaben über den spätesten Fertigstellungstermin eines Ergeb-nisses gibt, oder auch bei wiederkehrenden Vorhaben.

.4 VerhandlungBei einem Verhandlungsansatz wird versucht, gemeinsam mit den Betroffeneneine Einigung über die Priorisierung der Anforderungen herzustellen.

Bewertung

.1 Stärken• Priorisierung erleichtert die Findung gemeinsam getragener Ergebnisse und trägt dazu bei, wertschöpfende Ergebnisse zu produzieren und Zeit-vorgaben einzuhalten.

Priorisierung

368

Techniken

10.33.3

10.33.4

.2 Schwächen• Stakeholder drücken sich vor schwierigen Entscheidungen und wollen nicht wahrhaben, dass nicht alles gleichzeitig erreicht werden kann.

• Eine Arbeitsgruppe beeinflusst absichtlich oder unabsichtlich das Ergebnisder Priorisierung, indem die Schwierigkeit oder die Komplexität bei der Umsetzung bestimmter Anforderungen unter- oder überschätzt wird.

• Es stehen keine Kennzahlen und Key-Performance-Indikatoren zur Priorisie-rung zur Verfügung; deswegen kann die Wahrnehmung einzelner Stake-holder subjektiv verzerrt sein.

Prozessanalyse

Zweck

In einer Prozessanalyse wird ein Geschäftsprozess hinsichtlich seiner Effektivitätund Effizienz untersucht sowie hinsichtlich seiner Fähigkeit, Verbesserungsmög-lichkeiten sichtbar zu machen.

Beschreibung

Die Prozessanalyse verfolgt unter anderem die folgenden Zielsetzungen:• Vorschläge für effektivere und effizientere Prozesse erarbeiten• Differenzen zwischen dem gegenwärtigen und einem gewünschten zukünftigen Zustand bestimmen

• Faktoren erkennen, die bei einer vertraglichen Verhandlung berück-sichtigt werden sollten

• Verstehen, wie Daten und Technologien in einem Prozess genutzt werden

• Auswirkungen einer laufenden Prozessveränderung erkennen.

Für die Prozessanalyse und die Suche nach Verbesserungen gibt es eine ganzeReihe von Modellen und Methoden, wie zum Beispiel Six Sigma und Lean.Ansätze zur Verbesserung von Prozessen sind beispielsweise Wertstromanalyse,statistische Analysen, Prozesssimulation, Benchmarking und Prozess-Frameworks.

Beispiele für Verbesserungsansätze von Prozessen sind:• Verkürzung von Bearbeitungs- und Durchlaufzeiten• Modifikation von Schnittstellen oder Übergaben zwischen Rollen und Organisationseinheiten, um Fehler und Flaschenhälse zu verringern

Prozessanalyse

369

Techniken

10.34

10.34.1

10.34.2

• Automatisierung von Bearbeitungsschritten• Automatisierte Entscheidungen in Geschäftsprozessen.

Bei der Analyse von Prozessen untersucht der Business-Analyst,• welche Wertschöpfung durch einen Prozess erreicht wird• inwieweit ein Prozess zur Erreichung der Unternehmensziele beiträgt• in welchem Umfang ein Prozess heute effektiv, effizient, wiederholbar, gemessen, kontrolliert und transparent ist bzw. zukünftig sein sollte

• inwieweit die Anforderungen an eine Lösung dazu beitragen können, den zukünftigen Prozess aus der Sicht der Stakeholder – einschließlich der Kunden – zu verbessern.

Elemente

.1 Ermittlung von Abweichungen und möglichen VerbesserungenDie Ermittlung von Abweichungen von einem Soll und von Ansätzen für möglicheVerbesserungen kann helfen, die Grenzen für die Analyse zu bestimmen. Indus-triespezifische Modelle und Prozess-Frameworks können dabei hilfreich sein. ZurErmittlung von Abweichungen und Verbesserungsbereichen versucht der Busi-ness-Analyst,• Abweichungen zwischen dem heutigen und einem gewünschten zukünftigen Zustand zu ermitteln

• festzustellen, welche Abweichungen und Bereiche zur Wertschöpfung beitragen und welche nicht

• Schwächen und Herausforderungen des Prozesses aus unterschied-lichsten Blickwinkeln zu verstehen

• Abweichungen und Verbesserungsmöglichkeiten auf die Strategie des Unternehmens auszurichten

• Beziehungen der Abweichungen und Verbesserungsbereiche zu anderen Veränderungsprozessen im Unternehmen zu verstehen.

.2 UrsachenanalyseDie Identifikation der Ursachen für Abweichungen und für Verbesserungen stelltsicher, dass die Lösung nicht nur an Symptomen operiert.

Durch die Identifikation der eigentlichen Ursachen für Abweichungen und Ver-besserungen versteht der Business-Analyst,• dass es mehrere Ursachen geben kann• welche Inputs zu Abweichungen oder zu Verbesserungsmöglichkeiten führen

Prozessanalyse

370

Techniken

10.34.3

• welche Personen kompetente Aussagen über Ursachen machen können• welche Kennzahlen und Anreizsysteme es für diejenigen gibt, die für den Prozess verantwortlich sind oder ihn ausführen.

.3 Erarbeiten und Bewerten von LösungsvariantenDie Erarbeitung von Optionen und Lösungsvarianten hilft, aus verschiedenen Blick-winkeln auf die Prozessverbesserung zu schauen und sie zu bewerten. Es ist wichtig,dass die Stakeholder bei der Beurteilung der Auswirkungen, der Fragen der Mach-barkeit und bei der Bewertung alternativer Lösungen beteiligt werden.

.4 Verbreitete Methoden

SIPOC

SIPOC (Supplier, Input, Process, Output, Customer) ist eine Methode zur Pro-zessanalyse, die aus der Six-Sigma-Methodik stammt und für die Zwecke derProzessanalyse verallgemeinert wurde.

SIPOC wird für die Untersuchung von Prozessen verwendet um zu verstehen,welche Lieferanten (Supplier) welchen Input liefern, wie der Prozess abläuft,welcher Output an welche Kunden (Customer) geliefert wird.

Abb. 10.34.1: SIPOC-Modell

SIPOC bietet einen einfachen Überblick über einen Prozess. Es zeigt auch dieKomplexität und wer und was daran beteiligt ist, Input zu schaffen, beziehungs-weise wer welche Ergebnisse aus dem Prozess erhält. SIPOC ist ein wirkungsvollesWerkzeug, um einen Dialog über Probleme, Chancen, Abweichungen, Ursachen,Optionen und Lösungsalternativen im Rahmen einer Prozessanalyse zu führen.

Prozessanalyse

371

Techniken

Lieferanten Input Output Kunden

• Kunde (Käufer)• Kreditkarten- organisation• PayPal

• Kauf

Prozess

Einkauf-material

festlegen

Schritt 2

Zahlungsin-formationenbestätigen

Schritt 3

Lieferterminbestätigen

Schritt 4

Eingangprüfen

Schritt 5

Profilerstellen

Schritt 1

• Kunden- informationen• Bestands- informationen• Zahlungs- methode und Details

• Auftragsdetails• Zahlungs- bestätigung• Gekaufte Produkte

• Kunde (Käufer)• Lagerauftrag• Kreditbüro• PayPal• Auslieferung

Wertstrom-Darstellung (Value Stream Mapping VSM)

Zur Wertstrom-Darstellung gehören die Dokumentation und Verfolgung vonInput und Bearbeitungsstellen, an denen dieser Input verarbeitet wird. Es wirdganz am Anfang der Supply Chain begonnen. An jeder Station wird ermittelt,welche Wartezeiten es für den Input gibt und wie lang die Bearbeitungszeitensind. Am Ende der Wertschöpfungskette wird der Logistikprozess zum Kundendargestellt.

Die Wertstrom-Darstellung zeigt auf einen Blick alle Schritte eines Prozessesvom Beginn bis zum Ende, sowohl die wertschöpfenden als auch die nicht-wertschöpfenden Elemente.

Abb. 10.34.2: Wertstrom-Darstellung

Bewertung

.1 Stärken• Prozessanalyse stellt sicher, dass die Lösung sich auf die richtigen Sach-verhalte bezieht und verhindert Fehlentwicklungen.

• Viele unterschiedliche Techniken und Methoden können genutzt werden und bieten dem Team ein flexibles Instrumentarium.

Prozessanalyse

372

Techniken

Prozess

Aktivität /Aufgaben

Daten

Prozess


Daten

Prozess


Daten

Dokumente(schriftliche

Informationen)

Zeit ZeitZeit

Zeit Zeit

Zeit

Zeit

Gesamtverarbeitungszeit

Wartezeit

Bearbeitungs-zeit

Nicht-wert-schöpfende Zeit

wertschöpfendeZeit

Kunde

ElektronischerInformations-fluss

Lieferant

Versand

Versand

Prozess


Daten

10.34.4

.2 Grenzen• Kann sehr zeitaufwändig sein.• Da es sehr viele Techniken und Methoden gibt, kann es schwierig sein, dierichtigen herauszufinden und zu entscheiden, wie konsequent sie in diesem konkreten Fall angewendet werden sollen.

• Bei einer Verbesserung von geistigen Prozessen oder Prozessen mit vielen Entscheidungen eher wenig effektiv.

Prozessmodellierung

Zweck

Eine Prozessmodellierung ist die Darstellung eines Geschäftsprozesses mithilfeeiner standardisierten Notation. Sie zeigt, wie die Aufgaben erledigt werden,und bietet eine Grundlage für die Prozessanalyse.

Beschreibung

Prozessmodelle beschreiben einen Arbeitsfluss. Das Modell eines Geschäftspro-zesses beschreibt die Reihenfolge einzelner definierter Arbeitsschritte innerhalbeines Unternehmens oder eines Unternehmensbereiches. Ein System-Prozess-modell beschreibt die Bearbeitungsfolge von Programmen und Einheiten ineinem Computersystem. Ein Programm-Prozessmodell zeigt die Folge der Bear-beitungsbefehle in einer Software-Anwendung. Ein Prozessmodell kann auchdazu verwendet werden, operative Verfahren zu dokumentieren.

Ein Prozessmodell kann auf unterschiedlichen Ebenen entwickelt werden, indenen jeweils die Blickrichtung bestimmter Stakeholder eingenommen wird.Diese Ebenen dienen dazu, stufenweise einen komplexen Prozess in einzelneKomponenten zu zerlegen und auf jeder Stufe immer detaillierter und präziserzu werden. Auf einer allgemeinen Ebene (Unternehmen oder Gesamtzusam-menhang) verdeutlicht das Modell einen Prozess im Ganzen und in seinenZusammenhängen zu anderen Prozessen. Auf niedrigeren (operativen) Ebenenkönnen die Aktivitäten und die Ergebnisse sehr viel detaillierter dargestelltwerden und alternative Wege aufzeigen. Auf der feinsten Zerlegungsstufe kanndas Modell für eine Simulation oder für die konkrete Ausführung genutzt werden.

Prozessmodelle können dazu verwendet werden, um• eine Lösung oder einen Teil einer Lösung im Zusammenhang zu zeigen• zu beschreiben, was tatsächlich in einem Prozess geschieht oder was passieren sollte

Prozessmodellierung

373

Techniken

10.35.1

10.35.2

10.35

• eine verständliche Beschreibung einer Reihe von Aktivitäten für einen Dritten zu liefern

• eine textliche Darstellung bildlich zu ergänzen• als Grundlage für die Prozessanalyse zu dienen.

Der Business-Analyst kann einen Prozess zur Darstellung des Ist-Zustandes odereines zukünftigen Zustandes (Soll-Modell) nutzen. Ein Ist-Modell unterstützt dasVerständnis und eine gemeinsame Übereinkunft darüber, was gegenwärtiggeschieht. Ein Soll-Modell kann zu einer gemeinsamen Übereinkunft darüberführen, wie die gewünschte zukünftige Lösung aussehen soll.

Folgende Sachverhalte gehören normalerweise in ein Prozessmodell:• am Prozessbeteiligte• Auslöser des Prozesses• Schritte oder Aktivitäten des Prozesses (sowohl manuell als auch automatisiert)

• Arbeitsflüsse und Entscheidungspunkte, durch die die Aktivitäten miteinander verbunden werden

• Ergebnisse des Prozesses.

Ein elementares Prozessmodell beinhaltet einen Auslöser, eine Folge von Aktivi-täten und ein Ergebnis.

Ein ausführlicheres Prozessmodell kann auch noch andere Elemente enthalten,z.B. Daten, Material, Input und Output und ausführliche Beschreibungen, welchedie grafische Darstellung ergänzen.

Elemente

.1 Arten von Prozessmodellen und Notationen Für die Prozessmodellierung werden die unterschiedlichsten Notationen verwendet.Die gebräuchlichsten sind:• Ablaufpläne und Wertstromanalyse (Value Stream Mapping) werden im Fachbereich genutzt.

• Datenflussdiagramme und Unified Modeling LanguageTM (UML®) sind eher für IT-Spezialisten nützlich.

• Business Process Model and Notation (BPMN) wird zunehmend als Standard angesehen und kann sowohl im Fachbereich als auch von IT-Spezialisten genutzt werden.

• Integrated DEFinition (IDEF) Notation und Input-Guide-Output- Enabler (IGOE)-Diagramme, die vor allem dazu dienen, den Umfang eines Vorhabens abzustimmen.

• SIPOC und Wertstromanalyse für die Modellierung von Prozessen.

Prozessmodellierung

374

Techniken

10.35.3

Prozessmodelle enthalten typischerweise einige oder alle der folgenden Ele-mente:• Aktivität: Ein abgrenzbarer Schritt oder eine Aufgabe in einem Geschäftsprozess. Dabei kann es sich um ein einzelnes Aufgaben-element handeln oder weiter zergliedert werden in Unterprozesse, die jeweils wieder eigene Aktivitäten, Flüsse und andere Prozesselemente aufweisen.

• Ereignis: Ein Vorfall, der keine eigene Zeit beansprucht, aber eine Aktivität oder einen Prozess auslöst, unterbricht oder beendet. Dabei kann es sich um eine eingegangene Nachricht, den Ablauf einer bestimmten Zeitspanne oder um den Eintritt einer bestimmten Bedin-gung handeln, wie sie in einer Geschäftsregel definiert wird.

• Ablaufrichtung: Ein Pfad, der die Folgebeziehungen eines Prozesses darstellt. Normalerweise werden sie so gezeichnet, dass sie den Zeit-ablauf konsistent abbilden (typischerweise in der Richtung, wie der Text auch gelesen würde).

• Entscheidung: Eine Station in einem Prozess, in der ein Ablauf in zwei oder mehr Pfade aufgegliedert wird, die entweder wechselseitige exklusive Alternativen sind oder aber parallel laufen. Eine Entschei-dung kann auch dazu dienen, separate Ablaufteile wieder miteinanderzu verbinden.

• Link: Eine Verbindung zu anderen Prozessdarstellungen.• Rolle: Ein bestimmter Personentyp oder eine bestimmte Gruppe, die an dem Prozess beteiligt ist. Die verwendeten Bezeichnungen ent-sprechen normalerweise denen, die in den Organisationsmodellen benutzt werden.

Ablaufplan

Ablaufpläne werden normalerweise für Mitarbeiter der Fachbereiche genutztund eignen sich sowohl zur Darstellung der bestehenden Lösungen, wie auchfür die Dokumentation einer zukünftigen Lösung. Ein Ablaufplan kann sehr ein-fach sein und lediglich eine Folge von Aktivitäten abbilden oder vollständigersein und – etwa in der Form einer Swimlane – gleichzeitig die beteiligten Rollendokumentieren.

Prozessmodellierung

375

Techniken

Abb. 10.35.1: Ablaufplan

Business Process Model and Notation (BPMN)

Business Process Model and Notation (BPMN) ist eine weit verbreitete Form zurModellierung von Geschäftsprozessen, die sowohl für Mitarbeiter des Fachbereichsals auch für die Entwickler von Anwendungen verständlich ist. BPMN ist fürviele Arten der Modellierung geeignet und kann als Input für die Umsetzung ininformationstechnologische Anwendungen genutzt werden.

Prozessmodellierung

376

Techniken

Aufgabe 2A

Swimlane für Rolle 1

Arbeitsflüsseverschmelzen.

Swimlanes gehören nicht zum Standard,werden aber häufig als Erweiterung einesAblaufplans genutzt.

Der Arbeitsfluss teiltsich, die Aufgaben wer-den parallel nebenein-ander erledigt.

Swimlane für Rolle 2

Aufgabe 1

Input/Output

Start

Stop

Ent-schei-dung

Teilprozess

Aufgabe 3

Ein Teilprozess be-inhaltet selbst wiederein Prozessmodell.

Aufgabe 2B

Falsch

Richtig

Die Möglichkeit, die Zuordnung von Aktivitäten auf unterschiedliche Aufgaben-träger sichtbar zu machen, ist ein zentrales Merkmal der BPMN. Wenn derArbeitsfluss die Grenze einer Swimlane durchbricht, werden andere Rolleninhaberzuständig. Swimlanes sind Teil eines Pools. Ein Pool ist eine selbstständige Einheit,typischerweise eines Unternehmens, oder ein System. Ein Pool kann mehrereSwimlanes enthalten, jede davon enthält eine Rolle. Häufig wird ein Pool fürdas betreffende Unternehmen gebildet und ein weiterer für den Kunden. Eskönnen aber auch noch weitere Pools gebildet werden.

Abb. 10.35.2: Business Process Model and Notation

Prozessmodellierung

377

Techniken

Swimlane 1

Exklusives Gateway.Die Entscheidungwird nicht im Gate-way gefällt, sondernist Bestandteil dervorausgehenden Aufgabe.

Aufspaltung desArbeitsflusses inzwei parallele Äste.

Swimlane 2

Startereignis

X

Ein Teilprozess trägtein Prozessmodellin sich.

paralleleVerzweigung

Aufgabe 1

Endereignis

Aufgabe 3

Aufgabe 2A

Input/OutputAufgabe

Teilprozess

Aufgabe 2B

parallele Zusam-menführung

Teilprozesserfolgreich?

Der Arbeitsfluss wirdzusammengeführt.

Daten-speicher

Aktivitätsdiagramm

Ein Aktivitätsdiagramm gehört zu den Use-Case-Diagrammen der Unified Mode-ling LanguageTM (UML®). Es wurde ursprünglich entwickelt, um einen einzelnenUse Case auszuarbeiten. Heute wird es auch für die allgemeine Modellierungvon Prozessen einschließlich der Modellierung von Geschäftsprozessen verwendet.Es sieht ähnlich aus wie ein Ablaufplan, nutzt aber normalerweise Swimlaneszur Abbildung der Zuständigkeiten, Symbole für die Parallelverarbeitung undmehrere Entscheidungspunkte für die Beendigung eines Prozesses.

Abb. 10.35.3: Aktivitätsdiagramm

Prozessmodellierung

378

Techniken

Ein Teilprozess trägtein Prozessmodellin sich.

[Falsch]

Arbeitsfluss zu-sammengeführt.

Spalte für Rolle 1 Spalte für Rolle 2

Aufgabe 1

Aufgabe 2A Aufgabe 2B

Aufgabe (I/O)

Aufgabe 3

Teilprozess

Arbeitsfluss ver-zweigt in parallellaufende Äste.

Entscheidung

[Richtig]

Bewertung

.1 Stärken• Prozessmodellierung kommt dem allgemeinen Verständnis zur Darstellungvon Folgen entgegen.

• Die meisten Stakeholder haben keine Probleme mit den Konzepten und elementaren Bestandteilen eines Prozessmodells.

• Die Nutzung unterschiedlicher Detaillierungsgrade kommt unterschied-lichen Perspektiven von Stakeholdergruppen entgegen.

• Eine große Anzahl von Szenarien und parallel verlaufender Zweige kann einfach abgebildet werden.

• Hilft dabei, Stakeholder zu entdecken, die andernfalls möglicherweise übersehen worden wären.

• Erleichtert die Ermittlung möglicher Verbesserungen, indem Schwächen ineiner Prozessstruktur hervorgehoben werden.

• Birgt einen Nutzen in sich selbst, da auf diesem Wege Dokumente für Zwecke der Compliance entstehen, die auch für Trainingsaktivitäten und die Koordination verwendet werden können.

• Können als Ausgangspunkt für eine kontinuierliche Verbesserung genutztwerden.

• Fördern Einheitlichkeit der Dokumentation unterschiedlichster Ergebnisse.• Bieten Prozesseigentümern und Beteiligten Transparenz und fördern das Verständnis hinsichtlich Zuständigkeiten, Folgebeziehungen und Schnitt-stellen.

.2 Grenzen• Für Mitarbeiter der IT repräsentieren Prozessmodelle überkommene Ansätze der Software-Entwicklung. Deswegen wird kaum Zeit dafür auf-gewendet, insbesondere nicht für die Dokumentation des Ist-Zustandes.

• Werden sie nicht sorgfältig strukturiert, können sie sehr komplex und unübersichtlich werden. Das trifft besonders dann zu, wenn die Geschäftsregeln nicht vom Prozess getrennt werden.

• Komplexe Prozesse beinhalten viele Aktivitäten und Rollen, sodass es für einen Einzelnen fast unmöglich ist, sie zu verstehen und freizugeben.

• Probleme in Prozessen werden häufig nicht auf den oberen Ebenen der Modelldarstellung sichtbar. Dazu werden detailliertere Modelle mit Bezug zu Metadaten (zum Beispiel Häufigkeiten, Kosten, Zeitverbrauch) benötigt. Häufig müssen die betroffenen Mitarbeiter selbst eingeschaltet werden, umdie Probleme im betrieblichen Alltag zu erkennen.

Techniken Prozessmodellierung

379

10.35.4

TechnikenPrototyping

380

• In einer sehr dynamischen Umwelt können Prozessmodelle schnell über-holt sein.

• Wenn die Prozessmodelle lediglich zur Dokumentation verwendet werden, kann es schwierig sein, sie laufend zu pflegen, da die Stakeholder Änderun-gen vornehmen können, ohne das Modell entsprechend zu aktualisieren.

Prototyping

Zweck

Prototyping dient dazu, Anforderungen von Stakeholdern in einem iterativenProzess zu ermitteln und zu revidieren, indem ein Modell oder ein Design derAnforderungen entworfen wird. Es wird auch dazu verwendet, Anwender-erfahrungen zu optimieren und Design-Optionen zu bewerten, oder es dient alsGrundlage für die endgültige Lösung.

Beschreibung

Prototyping ist ein bewährtes Verfahren für das Design von Produkten. Dazuwird ein Modell der späteren Lösung erarbeitet, das als Prototyp bezeichnetwird. Prototyping wird dazu verwendet, sowohl fehlende als auch falsch definierteAnforderungen zu erkennen und unberechtigte Annahmen zu widerlegen, indemschon in einer frühen Entwurfsphase gezeigt wird, wie das Produkt aussiehtund funktioniert.

Prototypen können lediglich operativ nicht nutzbare Modelle, aber auch arbeitsfähigeErgebnisse sein. Schließlich gibt es noch rein digitale Darstellungen einer Lösungoder eines vorgeschlagenen Produktes. Diese können für Werbezwecke verwendetwerden, die Funktionsweise des späteren Produktes demonstrieren oder Prozessein der Form von Diagrammen (z.B.Workflows) abbilden. Prototypen mit Geschäfts-regeln und Beispieldaten können dazu genutzt werden, einen gewünschten Pro-zessfluss und die Wirkung der Geschäftsregeln zu untersuchen. Ein Daten-Prototypingkann zur Bereinigung von Datenbeständen verwendet werden.

Elemente

.1 Ansätze des PrototypingEs gibt zwei mögliche Ansätze des Prototyping:• Wegwerf-Prototyp: Prototypen werden mit einfachen Werkzeugen (z.B. Papier und Bleistift, Whiteboard oder Software)

10.36

10.36.1

10.36.2

10.36.3

entworfen, um Anforderungen zu ermitteln und zu präzisieren. Der Prototyp kann im Laufe des Vorhabens weiterentwickelt werden, ohne jemals zu einer funktionierenden Lösung zu führen. Dieser Ansatz ist besonders hilfreich, um die Funktionalität zu überprüfen oder Prozessezu ermitteln, die nur schwer auf anderen Wegen zu erfassen sind oderzu denen es sehr unterschiedliche Auffassungen gibt. Diese Prototypensind in der Regel relativ kostengünstig, wenn es darum geht, Anforde-rungen zu bestätigen, die sich nicht nur aus der Benutzerschnittstelle ergeben, sondern eher aus den zugrundeliegenden Prozessen, Daten und Geschäftsregeln.

• Evolutionärer oder funktionaler Prototyp: Diese Prototypen dienen dazu, anhand der Nutzung die Anforderungen der Stakeholder immer besser zu erkennen, um daraus schließlich funktionsfähige Lösungen zu entwickeln. Hier wird also eine arbeitsfähige Lösung erstellt, was aller-dings spezielle Werkzeuge oder Entwurfssprachen des Prototyping voraussetzt. Wenn eine spezialisierte Software genutzt wird, lassen sich Prozesse, Geschäftsregeln und Daten simulieren, um den Einfluss von Änderungen zu ermitteln und die gewünschten Ergebnisse zu bewerten.

.2 Beispiele für PrototypingHeute wird ein breites Spektrum des Prototyping genutzt.

Dazu einige Beispiele:• Machbarkeitsstudie (Proof of Principle oder Proof of Concept): Es wird ein Modell entwickelt, mit dem das Design eines Systems validiert werden soll, ohne das konkrete Aussehen, die zur Leistungserbringungverwendeten Ressourcen oder die Prozesse der finalen Lösung zu modellieren.

• Form Study Prototype: Dieser Prototyp wird dazu verwendet, um die Größe oder das „Look and Feel“ eines zu entwickelnden Produktes zu ermitteln, ohne dessen Funktionalität zu besitzen. Dabei sollen vorallem ergonomische und visuelle Faktoren berücksichtigt werden, die leichter mithilfe eines „greifbaren“ Ergebnisses erfasst und mit ein-fachen Mitteln kostengünstig hergestellt werden können. Dieser Prototyp kann auch zur Modellierung eines Workflow oder einer Navigation auf einer hohen Abstraktionsebene dienen, um Lücken oder Inkonsistenzen einer möglichen Lösung rechtzeitig zu erkennen.

• Usability Prototype (Gebrauchsfähigkeits-Prototyp): Dieser Prototyp dient dem Test, wie der Anwender mit dem System arbeiten kann. Die eigentlichen Funktionen werden nicht bereitgestellt.

• Visueller Prototyp: Es wird ein Produktmodell hergestellt, um das Erscheinungsbild zu verdeutlichen. Auch hier wird die Funktionalität nicht mit entwickelt.

Techniken Prototyping

381

• Funktionaler Prototyp: Es wird ein Modell einer Lösung erarbeitet, das dazu dient, die Funktionalität, die Gebrauchsfähigkeit und den Work-flow eines Systems zu testen. Es wird auch als Arbeitsmodell bezeich-net und sowohl für die Simulation von Prozessen und Geschäftsregeln als auch für den Aufruf einzelner Funktionen genutzt.

.3 Methoden des PrototypingFolgende Methoden des Prototyping sind weit verbreitet:• Storyboarding: Eine bildlich und textlich detaillierte Darstellung der Prozessfolge, in der die verschiedenen Interaktionen der Anwender miteiner Lösung sichtbar werden.

• Papier-Prototyping: Verwendung von Papier und Schreibstift, um Schnittstellen oder einen Prozess zu entwerfen.

• Workflow-Modellierung: Darstellung einer Folge von Operationen primär aus der Sicht der beteiligten Personen.

• Simulationen: Lösungen oder Komponenten einer Lösung werden bei unterschiedlichen Prozessen, Szenarien, Geschäftsregeln, Daten und Input getestet.

Bewertung

.1 Stärken• Prototypen bieten eine visuelle Darstellung der zukünftigen Lösung.• Geben Stakeholdern die Gelegenheit, schon bei dem Design Input und Feedback zu liefern.

• Werden Wegwerf-Prototypen oder Papier-Prototypen entwickelt, ist es fürdie Anwender leichter, Kritik und Verbesserungsvorschläge zu äußern, als wenn gebrauchsfertige Lösungen vorliegen würden.

• Ein begrenzter, aber sehr detaillierter Prototyp kann dazu verwendet werden,die technische Machbarkeit und das Lösungskonzept zu bestätigen sowie technologische oder Prozessmängel zu ermitteln.

.2 Grenzen• Bei sehr komplexen Systemen oder Prozessen kann es leicht passieren, dass bei der Entwicklung eines Prototyps langwierige Diskussionen geführt werden, in denen es eher um das „Wie“ als um das „Was“ geht. Das kann sehr zeitaufwändig sein und Ressourcen binden.

• Die zugrundeliegende Technologie muss u.U. erst verstanden oder ange-nommen werden, ehe mit dem Prototyping begonnen wird.

TechnikenPrototyping

382

10.36.4

• Ist der Prototyp im Detail ausgearbeitet, entwickeln die Stakeholder unter Umständen unrealistische Erwartungen hinsichtlich der eigentlichen Lösung. Das kann sich auf den Fertigstellungstermin ebenso beziehen wieauf die erwartete Performance, Zuverlässigkeit und Nutzerfreundlichkeit.

• Stakeholder können sich mehr auf die Entwurfsspezifikationen einer Lösung konzentrieren als auf die Anforderungen, die eine Lösung erfüllen muss. Das kann das Design der Lösung beeinträchtigen. Entwickler kommen unter Umständen zu der Auffassung, dass sie eine Nutzerschnittstelle schaffen müssen, die exakt dem Prototyp entspricht, selbst wenn es andere und bessere Möglichkeiten dafür gibt.

Reviews

Zweck

Reviews werden verwendet, um Arbeitsergebnisse zu bewerten.

Beschreibung

Für Arbeitsergebnisse der Business-Analyse gibt es verschiedene Typen vonReviews.

Jeder Typ wird für die Bedürfnisse des Unternehmens und des Business-Analystenkonkretisiert und berücksichtigt die folgenden Dimensionen:• Ziele – Was soll mit dem Review erreicht werden?• Techniken – Soll ein formeller oder informeller Weg für das Review gewählt werden?

• Beteiligte – Wer soll an dem Review mitwirken?

Jedes Review sollte auf das Arbeitsergebnis und nicht auf die Fähigkeiten oderHandlungen der Beteiligten fokussieren. Das Arbeitsergebnis kann aus mehrerenLösungen bestehen, ein einzelnes Produkt oder das Ergebnis eines bestimmtenEntwicklungsstandes sein. Ist ein Vorhaben komplett abgeschlossen, dient dasReview normalerweise dazu, Fehler zu erkennen und zu beseitigen oder diebeteiligten Personen über das Ergebnis zu informieren. In einem laufenden Vor-haben kann ein Review dabei helfen, ein Problem zu lösen oder eine Frage zubeantworten.

Bei jedem Review sollte der Business-Analyst beteiligt sein. Reviewer könnenArbeitskollegen sein oder Stakeholder, die prüfen, ob das Ergebnis komplett istund korrekt funktioniert. Die Schritte eines Reviews hängen von der jeweils ver-wendeten Technik ab.

Techniken Reviews

383

10.37

10.37.1

10.37.2

Zu einem Review können gehören:• Überblick über das Arbeitsergebnis und die Ziele des Reviews• Checklisten und Referenzmaterial zur Unterstützung der Reviewer• Prüfung des Arbeitsergebnisses und Dokumentation der Bemerkungen• Verifizierung von Nacharbeiten.

Auf der Grundlage des Feedbacks wird das Arbeitsergebnis angepasst.

Elemente

.1 Ziele Die Ziele werden allen am Review Beteiligten verdeutlicht.

Ziele können zum Beispiel sein:• Fehler entdecken• Prüfen, ob Spezifikationen oder Standards eingehalten sind• Sicherstellen, dass das Arbeitsergebnis vollständig und richtig ist• Einvernehmen hinsichtlich des Vorgehens oder der Lösung herstellen• Fragen beantworten, Sachverhalte lösen oder Alternativen erforschen• Reviewer mit dem Arbeitsergebnis vertraut machen• Aussagen über die Qualität eines Arbeitsergebnisses machen.

.2 TechnikenReviews können formal oder informal ablaufen. Die für ein Review genutztenTechniken hängen davon ab, welche Ziele verfolgt werden.

Folgende Techniken sind weit verbreitet:• Inspektion: Eine formale Technik, zu der ein Überblick über das Arbeits-, ergebnis insgesamt, individuelle Reviews, die Dokumentation von Mängeln, die Konsolidierung von Mängeln im Team und die Nach-verfolgung gehören, um sicherzustellen, dass die notwendigen Ver-änderungen auch vorgenommen werden. Zentrales Anliegen sind die Beseitigung von Fehlern und die Sicherstellung einer hohen Qualität des Arbeitsergebnisses. Eine Inspektion wird normalerweise von Kolle-gen durchgeführt, es können aber auch die Stakeholder hinzugezogenwerden.

• Formales Walkthrough (wird auch als Team Review bezeichnet): Dabei handelt es sich um eine formale Technik, bei der sowohl individuelle Reviews als auch eine Konsolidierung im Team stattfinden. Sie wird sowohl von Kollegen als auch von betroffenen Stakeholdern genutzt.

TechnikenReviews

384

10.37.3

• Single Issue Review (wird auch als technisches Review bezeichnet): Formale Technik, bei der sich die Reviewer einzeln primär auf einen speziellen Sachverhalt eines Arbeitsergebnisses oder einen Standard konzentrieren, bevor es in einer Gruppensitzung dann darum geht, dieanstehende Fragestellung gemeinsam zu lösen.

• Informales Walkthrough: Informale Technik, bei der der Business-Analyst ein Arbeitsergebnis im Entwurfsstadium anschaut und dazu Feedback gibt.

• Pass Around: Eine informale Technik, bei der mehrere Reviewer münd-liches oder schriftliches Feedback geben. Das Arbeitsergebnis kann als Ganzes zwischen den Reviewern weitergereicht werden oder jeder erhält eine Kopie.

• Ad hoc: Eine informale Technik, bei der der Business-Analyst eine Bewertung oder Hilfe von einem Kollegen erbittet.

.3 BeteiligteDie Ziele des Reviews, die ausgewählten Techniken und betrieblichen Standardsentscheiden darüber, welche Rollen aufgrund ihrer Expertise beteiligt werden.

In einigen Fällen kann auch ein Vorgesetzter oder Manager wegen seiner Quali-fikation hinzugezogen werden. In diesen Fällen muss der Moderator sorgfältigdarauf achten, dass alle Beteiligten offen und aufrichtig miteinander umgehen.

Tabelle 10.37.1: Rollen in Reviews

Techniken Reviews

385

Rolle Beschreibung Zuständigkeit Mögliche Techniken

Ersteller Urheber desArbeits-ergebnisses

Beantwortet Fragen zu dem Arbeits-ergebnis und nimmt Vorschläge undKommentare entgegen. Setztgewünschte Änderungen um.

Alle

Reviewer Kollege oderStakeholder

Prüft das Arbeitsergebnis gemäßden vorgegebenen Zielen. Wenn esdarum geht, Fehler zu finden, prüftder Reviewer vor der gemeinsamenReview-Sitzung das Arbeitsergebnisund hält Mängel wie auch Verbesse-rungsvorschläge fest.

Alle

Tabelle 10.37.1: Rollen in Reviews (Fortsetzung)

Bewertung

.1 Stärken• Reviews können dazu beitragen, schon in einer frühen Phase einer Produkt-entwicklung, Mängel zu erkennen, deren Beseitigung unter Umständen sehr aufwändig wäre, wenn sie erst in einem späteren Entwicklungs-stadium entdeckt worden wären.

• Alle an einem Review Beteiligten sind an dem Ergebnis und damit an der Qualität der Lösung interessiert.

• Die Prüfung von Arbeitsergebnissen am Schreibtisch und Pass Around Reviews erlauben es den Reviewern, die Prüfung zu Zeiten vorzunehmen, die für sie günstig sind.

.2 Grenzen• Konsequente Team Reviews kosten Zeit und Mühe. Deswegen sollten formale Verfahren des Reviews nur für die wichtigsten Arbeitsergebnisse eingesetzt werden.

• Informale Reviews durch eine oder zwei Personen verringern zwar den Aufwand, sind aber im Vergleich zu einem Team und einem formalen Ansatz weniger zuverlässig, wenn es darum geht, alle signifikanten Mängel zu erkennen.

TechnikenReviews

386

Rolle Beschreibung Zuständigkeit Mögliche Techniken

Moderator Neutrale Person(sollte nicht der Urheberdes Arbeits-ergebnissessein)

Moderiert die Review-Sitzung, sorgtdafür, dass die Ziele erreicht unddass alle relevanten Teile desArbeitsergebnisses auch berücksich-tigt werden. Würdigt die Vorarbeitder Reviewer und sorgt dafür, dasssich alle Anwesenden beteiligen.

Inspektion

FormalesWalkthrough

Protokollant Neutraler Teil-nehmer, dersich gut aus-drücken kann.

Dokumentiert alle Mängel, Vor-schläge, Kommentare, Sachverhalte,Bedenken und offenen Fragen, diewährend der Sitzung auftauchen.Die Arbeit wird erleichtert, wenn derProtokollant mit dem jeweiligenSachverhalt vertraut ist.

Inspektion

Formales oderinformalesWalkthrough

10.37.4

• Bei einer Prüfung von Arbeitsergebnissen am Schreibtisch und Pass Around Reviews kann nicht ohne weiteres festgestellt werden, ob sich alleBeteiligten engagiert haben.

• Wenn die Kommentare zu Reviews per E-Mail weitergeleitet werden, müssenunter Umständen sehr viele Informationen verarbeitet werden. Zudem ist es für den Ersteller des Arbeitsergebnisses schwierig, mit Ablehnungen und Meinungsunterschieden umzugehen.

Risikoanalyse und -management

Zweck

Risikoanalyse und -management dienen der Ermittlung, was ein Unternehmenoder eine Lösung bedroht, der Analyse und Bewertung der Eintrittswahrschein-lichkeit und der Auswirkungen sowie der Erarbeitung von Ansätzen zum Umgangmit Risiken.

Beschreibung

Werden mögliche Risiken nicht rechtzeitig erkannt und keine Maßnahmen dagegenergriffen, kann das den Wert einer Lösung erheblich beeinträchtigen. Zu Risiko-analyse und -management gehören die Ermittlung, die Analyse und die Bewertungvon Risiken. Wenn es dazu noch keine ausreichenden Kontrollverfahren gibt, ent-wickelt der Business-Analyst Pläne, um Risiken zu vermeiden, die Auswirkungenzu verringern oder zu modifizieren. Falls notwendig, setzt er diese Pläne um.

Risikomanagement ist eine laufende Aktivität. Ständiger Kontakt mit den Stake-holdern kann sowohl helfen, Risiken zu ermitteln, als auch identifizierte Risikenzu überwachen.

Elemente

.1 RisikoidentifikationRisiken können durch eine Kombination von Expertenurteil, Input von Stakehol-dern, Experimenten, Erfahrungen aus der Vergangenheit und Analysen bei frü-heren, ähnlichen Vorhaben und Situationen ermittelt werden. Dabei wird dasZiel verfolgt, die relevanten Risiken möglichst vollständig zu erfassen und Wis-sensdefizite so weit wie möglich zu minimieren. Risikoidentifikation ist eine fort-laufende Tätigkeit.

Ein eingetretenes Risiko können ein einzelnes Ereignis, mehrere Ereignisse oderauch das Ausbleiben eines Ereignisses sein. Eine einzelne Bedingung oder auch

Techniken Risikoanalyse und -management

387

10.38

10.38.1

10.38.2

10.38.3

mehrere Bedingungen gemeinsam können zu einem Risiko führen. Ein Ereignisoder eine Bedingung kann unterschiedliche Folgen haben, und eine Folge kanndurch mehrere unterschiedliche Ereignisse oder Bedingungen verursacht werden.

Jedes Risiko kann in einem Risikoregister beschrieben werden, wodurch die Ana-lyse von Risiken und die Planung von Maßnahmen unterstützt wird.

Abb. 10.38.1: Beispiel für ein Risikoregister

TechnikenRisikoanalyse und -management

388

# Risiko-ereignisoderBedingung

Folgen Wahr-schein-lich-keit

Aus-wir-kung

GrößedesRisikos

Plan zumUmgangmit Risiken

Zustän-diger(Risiko-eigen-tümer)

Restrisiko

Wahr-schein-lichkeit

Auswir-kung

Risiko-niveau

1 Gewerkschaftstimmt Ände-rungen in denAufgabenbe-schreibungennicht zu

PersonelleÄnderungenkönnen nichtvorgenom-men werden

mittel mittel mittel SpätestensEnde nächstenMonats Beginnder Verhand-lungen mitder Gewerk-schaft

Marta niedrig niedrig niedrig

2 QualitativschlechtereErgebnisse,Verzögerungder Fertig-stellung

mittel hoch hoch Erarbeitungeines Plans,wann welcheExperten not-wendig sind,Workshops vorOrt,Unterstützungdurch einenSponsor

Deepak niedrig mittel niedrig

3 Zu wenigeKundenbeteiligensich an derUmfrage

Unvollstän-dige Ermitt-lung derKundenan-forderungen

mittel hoch hoch Vertrag miteinem speziali-sierten Markt-forschungs-unternehmen

François niedrig mittel niedrig

4 Aufbauorga-nisation wirdnicht auf dieneuen Pro-zesse ausge-richtet

Unternehmenist nicht in derLage, die ge-plante Effi-zienz zu errei-chen und be-triebliche An-forderungenwerden nichterfüllt

hoch hoch hoch Sponsor aus derbetrieblichenEbene muss vorder Einführungden organisa-torischen Ver-änderungen zu-stimmen. Ver-änderungenmüssen vor derEinführung ge-schehen

Jiahui mittel

niedrig

mittel

Fachbereichs-experten ste-hen nicht fürdie Erhebungvon Anforde-rungen zurVerfügung

.2 AnalyseZur Risikoanalyse gehört es, sich über das Risiko selbst und den Grad der Bedro-hung klar zu werden. Gelegentlich gibt es bereits Kontrollen für bestimmteRisiken, sie sollten dann bei der Risikoanalyse berücksichtigt werden.

Die Wahrscheinlichkeit des Eintretens kann entweder quantifiziert oder verbalausgedrückt werden (zum Beispiel niedrig, mittel, hoch).

Die Auswirkungen eines Risikos werden durch die mögliche Beeinträchtigungdes Nutzens beschrieben. Der Einfluss von Risiken kann in Kosten, Zeitdauer,Reichweite oder Qualität einer Lösung oder durch irgendeine andere, von denStakeholdern als relevant erachtete Größe ausgedrückt werden, z.B. durch Repu-tation, Compliance oder soziale Verantwortlichkeit.

Tabelle 10.38.1: Beispiele für Maßstäbe von Risikoauswirkungen

Techniken Risikoanalyse und -management

389

Umfang Qualität Kosten Aufwand Zeitdauer Reputa-tion

SozialeVerantwort-lichkeit

GeringeAuswir-kung

Nur kleinereBereichesindbetroffen

Gering-fügigeQualitäts-probleme

Wenigerals 1%höhereKosten

Wenigerals 2%zusätz-licherZeitauf-wand

Bis zu 3%zeitlicheVerzöge-rung

SehrgeringeAuswir-kung auf dieReputa-tion

Gering-fügigeBehinde-rung

MittlereAuswir-kung

Wesent-liche Bereichesindbetroffen,es gibtaber dieMöglich-keit vonUmgehun-gen

ErheblicheQualitäts-einbußen,das Pro-dukt istaber nochnutzbar

Mehr als1%, aberwenigerals 3%höhereKosten

2-10%höhererZeit-bedarf

Verspä-tungzwischen3% und10%

MäßigerEinflussauf dieReputa-tion

ErheblicheBehinde-rung

HoheAuswir-kung

Das Produkterfülltnicht dengeforder-ten Bedarf

Das Produkt istnichtbrauchbar

Mehr als3%höhereKosten

Mehr als10%höhererZeit-bedarf

Verspä-tungmehr als10%

Gravie-renderEinflussauf dieReputa-tion

Schwer-wiegendeBehinde-rung

Auch wenn ein Unternehmen bereits standardisierte Kriterien für Risikoauswirkungenhat, kann es sinnvoll sein, Kategorien wie Kosten, Zeitaufwand und Reputationzusätzlich aufzunehmen, um das akzeptierbare Risikoniveau zu ermitteln. Typi-scherweise gibt es 3-5 Ausprägungen, um die möglichen Wirkungen zu bewerten.

Das Risikoniveau kann auch über einen zusammenfassenden Wert ausgedrücktwerden, in den Wahrscheinlichkeit des Eintretens und Auswirkung eingehen.Meistens wird dazu einfach die Wirkung mit der Wahrscheinlichkeit multipliziert.Die Risiken werden dann nach ihrem absteigenden Risikoniveau sortiert. Risiken,die kurzfristig eintreten können, können eine höhere Priorität erhalten als solche,die erst später erwartet werden. Risiken aus Kategorien wie Reputation oderCompliance können ebenfalls eine höhere Priorität erhalten als andere.

.3 Bewertung von RisikenDie Ergebnisse der Risikoanalyse werden mit dem potentiellen Nutzen einesChange oder einer Lösung verglichen, um zu ermitteln, ob dieses Maß an Risikoakzeptiert werden kann oder nicht. Ein Ausdruck für ein Gesamtrisiko kannermittelt werden. Dazu werden die individuellen Risikoniveaus addiert.

.4 Umgang mit RisikenEinige Risiken können akzeptabel sein, bei anderen ist es unerlässlich, Maßnahmenzu ergreifen, um das Risiko zu verringern.

Es kann sinnvoll sein, einen oder mehrere Ansätze zu erwägen, wie mit dem Risikoumgegangen werden soll. Oft empfiehlt es sich, mehrere Ansätze zu kombinieren: • Vermeiden: Entweder wird die Ursache für das Risiko beseitigt oder es werden Maßnahmen ergriffen, die das Risiko beseitigen.

• Übertragen: Die Verantwortung für den Umgang mit dem Risiko wird weitergereicht oder mit einer dritten Partei gemeinsam getragen.

• Abschwächen: Entweder wird die Wahrscheinlichkeit für das Eintreten des Risikos reduziert oder die möglichen Auswirkungen für den Fall, dass das Risiko eintritt.

• Akzeptieren: Es wird bewusst entschieden, nichts zu unternehmen. Tritt das Risiko ein, werden situativ Maßnahmen ergriffen.

• Steigern: Es wird ein höheres Risiko akzeptiert und damit die Chancen für ein besseres Ergebnis zu steigern.

Nachdem die Entscheidung für den Umgang mit einem Risiko gefällt wurde,wird ein Plan für den Fall erarbeitet, dass es eintritt und einem Verantwortlichen(Risiko-Eigentümer) übertragen. Soll ein Risiko vermieden werden, ergreift derZuständige geeignete Maßnahmen, um sicherzustellen, dass es nicht eintrittoder die Auswirkungen beherrschbar sind. Können Risiken nicht vermieden wer-den, ist der Risiko-Eigentümer dafür zuständig, das Risiko laufend zu verfolgenund einen Plan zur Abschwächung des Risikos vorzulegen.

TechnikenRisikoanalyse und -management

390

Das Risiko wird dann erneut analysiert, um die restliche Bedrohung, die Wahr-scheinlichkeit des Eintretens und die möglichen Auswirkungen einzuschätzen,nachdem vorbeugende Maßnahmen ergriffen wurden. Eine Kosten-Nutzen-Ana-lyse kann verwendet werden, um festzustellen, ob der Nutzen der Risikominde-rung die notwendigen Kosten rechtfertigt. Schließlich sind die Folgen eines Rest-risikos neu zu bewerten.

Die Stakeholder sollten über die Pläne zum Umgang mit Risiken informiert werden.

Bewertung

.1 Stärken• Risikoanalyse und -management können genutzt werden für strategische Risiken, die den langfristigen Wert eines Unternehmens beeinflussen, für taktische Risiken, die den Wert einer einzelnen Maßnahme beeinträchti-gen, oder für operative Risiken, die den Wert einer Lösung bedrohen können, nachdem diese Lösung bereits eingeführt wurde.

• Bei verschiedenen Vorhaben tauchen immer wieder ähnliche Risiken auf. Der erfolgreiche Umgang mit den Risiken zurückliegender Vorhaben kannzu wertvollen „Lessons Learned“ führen, die für spätere Maßnahmen genutzt werden können.

• Das Risikoniveau einer Veränderung kann sich im Laufe der Zeit verändern. Ein kontinuierliches Risikomanagement trägt dazu bei, Änderungen zu erkennen, Risiken neu zu bewerten und die Eignung von Maßnahmen zu überprüfen.

.2 Grenzen• Die Anzahl möglicher Risiken für ein konkretes Vorhaben kann derartig groß sein, dass sie kaum zu handhaben ist und eventuell in einzelne Bedrohungsfelder aufgespalten werden muss.

• Es kann immer wieder vorkommen, dass erhebliche Risiken nicht rechtzeitig entdeckt werden.

Rollen- und Zuständigkeitsmatrix

Zweck

Eine Rollen- und Zuständigkeitsmatrix wird dazu verwendet, um sicherzustellen,dass alle Aktivitäten Verantwortlichen übertragen, Rollen identifiziert, fehlendeRollen entdeckt und die Ergebnisse einer geplanten Veränderung bekanntgemachtwerden.

Techniken Rollen- und Zuständigkeitsmatrix

391

10.38.4

10.39

10.39.1

Beschreibung

Die Zuweisung von Befugnissen auf Rollen setzt voraus, dass diese Rollenbestimmt sind und dass den Rollen Zuständigkeiten übertragen werden, diesich aus der Lösung ergeben. Eine Rolle ist ein Sammelbegriff für eine Gruppevon Individuen, die gleiche Funktionen wahrzunehmen hat. Jede Funktion umfassteine oder mehrere Aktivitäten, die erledigt werden müssen. Eine einzelne Aktivitätkann einer oder mehreren Rollen übertragen werden. Jede Person mit dieserBefugnis kann die zugehörigen Aktivitäten erfüllen.

Hier ein Beispiel für eine Rollen- und Zuständigkeitsmatrix für ein Softwaresystem.

Abb. 10.39.1: Rollen- und Zuständigkeitsmatrix

Elemente

.1 Identifikation von RollenSollen Rollen für interne oder externe Stakeholder identifiziert werden, mussder Business-Analyst• Organisationsmodelle, Stellen- und Verfahrensbeschreibungen sowie Benutzerhandbücher überprüfen

• sich mit Stakeholdern treffen, um weitere Rollen zu ermitteln.

TechnikenRollen- und Zuständigkeitsmatrix

392

10.39.2

Rollen- und Zuständig- keits-Matrix

Ro

lle

Gru

pp

e 1

Ad

min

istr

ato

r

Man

ager

Ro

lle G

rup

pe

2

Ver

kau

f

Ku

nd

e

Aktivität

Neues Konto anlegen X X

X

Konto verändern X X X

Auftrag erteilen X X X X

Berichte zur Kenntnis nehmen X X X

Berichte erstellen X X X

10.39.3

Durch diese Überprüfung und Diskussion kann sich zeigen, dass Personen mitunterschiedlichen Titeln die gleiche Rolle besetzen oder aber Stelleninhaber glei-cher Stellenbezeichnung unterschiedliche Rollen wahrnehmen.

Bei der Identifikation von Rollen sollte der Business-Analyst darauf achten, welchePersonen die gleichen Funktionen erledigen, die einen vergleichbaren Bedarfdecken.

.2 Identifikation von AktivitätenDer Business-Analyst nutzt häufig eine Aufgliederung von Funktionen, um jedeFunktion in ihre Elemente zu zerlegen, die Prozessmodellierung, um den Arbeits-ablauf und die Arbeitsteilung zwischen den Beteiligten besser zu verstehen,sowie Use Cases, um die Aufgaben abzubilden. Mithilfe dieser Techniken kannder Business-Analyst sicherstellen, dass alle zu erledigenden Funktionen verteiltwerden und die jeweiligen Aktivitäten in verschiedenen Szenarien von Use Casesidentifiziert werden.

Es kann verschiedene Abstraktionsgrade für die Rollen- und die Zuständigkeits-matrizen geben, die von der jeweiligen Blickrichtung der Business-Analyse abhän-gen. Auf einer allgemeinen Ebene können Rollen und Verantwortlichkeiten ineiner RSCI-Matrix (Responsible, Accountable, Consulted, Informed) dargestelltwerden. Spezifische Matrizen für Rollen und Verantwortlichkeiten in Informati-onssystemen lassen sich in einer CRUD-Matrix (Create, Read, Update, Delete)erkennen.

.3 Identifikation von RechtenRechte sind Aktionen, die bestimmte Rolleninhaber ausführen dürfen. Für jedeeinzelne Aktivität ermittelt der Business-Analyst die Rechte der jeweiligen Rolle.Dazu müssen die Sicherheitsanforderungen und der Arbeitsfluss beachtet werden.Um die Rechte zu validieren, arbeitet der Business-Analyst mit Stakeholdernzusammen.

.4 Erweiterungen

Delegation

Der Business-Analyst kann auch versuchen festzustellen, welche Rechte befristetoder langfristig von einem Individuum auf ein anderes übertragen werden können.

Vererbung

Stakeholder können fordern, dass bei der Zuordnung von Rechten auf einerbestimmten Hierarchieebene, dieses Recht ausschließlich auf dieser Ebene oderauf den direkt nachgeordneten Ebenen angesiedelt sein darf.

Techniken Rollen- und Zuständigkeitsmatrix

393

Bewertung

.1 Stärken• Eine Rollen- und Zuständigkeitsmatrix sorgt für „Checks and Balances“ und für den Datenschutz, wenn bestimmte Stelleninhaber nur begrenzte Rechte haben.

• Erleichtert Vergleiche im Zeitablauf, wenn dokumentiert wird, welche Rechte in bestimmten Zeiträumen wem übertragen worden sind.

• Bietet eine Dokumentation von Rollen und Zuständigkeiten für bestimmte Aktivitäten.

.2 Grenzen• Der notwendige Detaillierungsgrad muss sorgfältig beachtet werden, da andernfalls entweder zu viel Zeit für nicht notwendige Details aufgewendet wird oder aber ein zu niedriger Detaillierungsgrad bestimmte Rollen und Verantwortlichkeiten gar nicht erst sichtbar macht.

Ursachenanalyse

Zweck

Eine Ursachenanalyse dient dazu, die einem Problem zugrundeliegenden Auslöserzu ermitteln und zu bewerten.

Beschreibung

Ursachenanalyse ist ein systematisches Vorgehen mit dem Ziel, die eigentlichenGründe für ein Problem oder eine Situation zu ermitteln und sich nicht primär mitden Auswirkungen zu beschäftigen. Es wird ein schrittweiser Ansatz genutzt, daes fast immer mehr als eine Ursache für ein Problem oder für bestimmte Wirkungengibt. Ursachenanalyse konzentriert sich auf die Hauptgründe für unerwünschteAbweichungen, dazu gehören Menschen (Irrtümer, fehlende Ausbildung), physischeObjekte (fehlerhafte Sachmittel, schlechte Räumlichkeiten) oder organisatorischeLösungen (mangelhaftes Prozessdesign, schlechte Organisationsstrukturen).

Die Ursachenanalyse bereitet Informationen in einem Raster auf, der bei Bedarfeine tiefergehende Analyse ermöglicht. Ursachenanalyse kann verwendet werdenfür:• Reaktive Analyse: Für ein bereits aufgetretenes Problem werden die Ursachen analysiert, um geeignete Maßnahmen zu ergreifen.

TechnikenUrsachenanalyse

394

10.39.4

10.40.1

10.40.2

10.40

• Proaktive Analyse: Es werden mögliche zukünftige Problemgebiete ermittelt, um präventive Maßnahmen einzusetzen.

Zur Ursachenanalyse gehören vier Hauptaktivitäten:• Problembeschreibung: Hier wird der zu behandelnde Sachverhalt aufgeführt.

• Datensammlung: Erhebung von Informationen über die Art, den Umfang, den Ort und die zeitliche Dimension (wann, wie lange) des Problems.

• Ermittlung der Ursachen: Muster von Auswirkungen werden unter-sucht, um so die konkreten Aktionen zu entdecken, die zu dem Problem führen oder dazu beitragen.

• Ermittlung von Maßnahmen: Suche nach korrigierenden Aktionen, die zukünftig Probleme verhindern oder die Wiederholungsmöglichkeit verringern.

Elemente

.1 Ursache-Wirkungs-Diagramm (Fishbone Diagram)Ein Ursache-Wirkungs-Diagramm wird dazu verwendet, mögliche Ursachen fürein Problem zu erkennen und zu strukturieren. Die Technik hilft dabei, auf dasProblem (statt auf die Lösung) fokussiert zu bleiben und Ideen für die weitereAnalyse zu ordnen. Es dient als eine Karte, in der mögliche Ursache-Wirkungs-Beziehungen dargestellt werden.

In folgenden Schritten wird ein Ursache-Wirkungs-Diagramm entwickelt:Schritt 1: Das zu lösende Problem wird in einem Kasten am rechten

Bildrand mittig verdeutlicht (Effekt).Schritt 2: Zu diesem Kasten läuft eine waagerechte Linie (das Rückgrat

der Fischgräte).Schritt 3: Zu dieser waagerechten Linie laufen diagonale Linien, auf

denen mögliche Ursachenbündel (Kategorien) für das Problem genannt werden (typische Beispiele sind Menschen, Sachmittel, Prozesse, Werkzeuge, politische Vorgaben).

Schritt 4: Auf diese Linien führen waagerechte Pfeile, auf denen tieferliegende Ursachen genannt werden.

Schritt 5: Mithilfe eines Brainstorming können solche Kategorien und diemöglichen Ursachen für das Problem (eventuell auch über mehrere Stufen) gesammelt werden.

Schritt 6: Analyse der Ergebnisse. Da bisher nur mögliche Ursachen genannt wurden, ist eine weitergehende Analyse notwendig,

Techniken Ursachenanalyse

395

10.40.3

um diesen Zusammenhang zu bestätigen oder zu verwerfen, am besten anhand harter Daten.

Schritt 7: Nachdem die Ursache(n) gefunden wurde(n), kann ein Brain-storming zur Suche möglicher Lösungen beitragen.

Abb. 10.40.1: Ursache-Wirkungs-Diagramm

.2 Die „Fünf Warum-Fragen“Die „Fünf Warum-Fragen“ sind eine Fragetechnik, die dazu dient, das Wesenund die Ursache eines Problems zu erkennen. In diesem Vorgehen werden wie-derholt Fragen gestellt, um zu der eigentlichen Ursache eines Problems vorzu-dringen. Das ist eine der einfachsten Moderationstechniken, die hauptsächlichangewendet wird, wenn auch Menschen zu dem Problem beigetragen haben.

Nutzung dieser Technik:Schritt 1: Das Problem wird schriftlich für alle sichtbar dokumentiert.Schritt 2: Als nächstes wird die Frage gestellt: „Warum tritt dieses Problem

auf?“ Die Antwort wird unter dem Problem festgehalten.Schritt 3: Zu der genannten Ursache wird erneut „warum“ gefragt.

Auch diese Antwort wird dokumentiert.

Schritt 3 wird so oft wiederholt, bis sicher zu sein scheint, dass die Kernursacheidentifiziert wurde. Dazu können weniger als fünf Fragen reichen, gelegentlichsind aber auch mehr als fünf notwendig.

TechnikenUrsachenanalyse

396

Primäre Ursache Tertiäre

Ursache

Problem/Wirkung

Kategorie 1 Kategorie 2

Kategorie 3 Kategorie N

SekundäreUrsache

Die „Fünf Warum-Fragen“ können als eigener Ansatz genutzt oder aber auchals Teil des Ursache-Wirkungs-Diagramms eingesetzt werden. Nachdem Ursa-chenideen im Diagramm eingetragen wurden, können die „Fünf Warum-Fragen“dazu beitragen, noch tiefer zur Kernursache vorzudringen.

Bewertung

.1 Stärken• Ursachenanalyse fördert die Objektivität bei der Ursache-Wirkungs-Analyse.• Erlaubt es, den Stakeholdern gezielt an den Punkten anzusetzen, die bisher die Qualität der Lösung beeinträchtigt haben.

.2 Grenzen• Die besten Ergebnisse werden dann erzielt, wenn der Business-Analyst speziell darauf vorbereitet wurde, nicht nur Symptome, sondern die wirk-lichen Ursachen zu identifizieren.

• Es kann bei komplexen Problemen schwierig sein, zu der Kernursache vorzu-dringen, falsche Schlussfolgerung zu vermeiden oder sich nicht in Sack-gassen zu verlaufen.

Scope-Modellierung (Modellierung der Systemgrenzen)

Zweck

In Scope-Modellen wird festgelegt, durch welche Grenzen ein Vorhaben oderein Objekt (System) definiert wird, und benannt, welche Elemente innerhalboder außerhalb dieser Grenzen liegen.

Beschreibung

Scope-Modelle werden ganz allgemein verwendet, um die Grenzen der Ein-flussnahme, der Änderung, der Lösung oder eines Bedarfs zu bestimmen. Siekönnen dazu beitragen, dass anstelle einer diffusen Beschreibung eine Grenzeeindeutig abgesteckt wird.

Die Modelle gehen von unterschiedlichen Blickwinkeln aus:• In-Scope: Die Grenze wird über die darin enthaltenen Elemente defi-niert. Das kann zum Beispiel durch eine funktionale Zerlegung gesche-hen.

Techniken Scope-Modellierung

397

10.41

10.40.4

10.41.2

10.41.1

• Out-of-Scope: Das Modell wird über die Sicht von außen abgegrenzt, dazu werden die nicht enthaltenen Elemente genannt (z.B. Kontext-Diagramm).

• Beide Sichten: Das Modell identifiziert eine Grenze aus beiden Blick-richtungen und nennt dazu Elemente, die innerhalb wie auch außer-halb der Grenzen liegen (z.B. Use-Case-Diagramm).

Scope-Modelle unterstützen das Verständnis von Grenzen aus unterschiedlichenBlickwinkeln:• Grenzen der Einflussnahme: Was wird analysiert, welche Rollen und Verantwortlichkeiten gehören dazu, was liegt innerhalb der Organisa-tion und was außerhalb?

• Bedarfsgrenzen: Bedarf von welchen Stakeholdern, welche zu liefern-den Werte, welche funktionalen Bereiche und Organisationseinheiten sind zu berücksichtigen?

• Lösungsgrenzen: Wie weit darf oder muss eine Lösung gehen, in welchem Umfang sind Veränderungen zulässig (z.B. Erweiterung einer bestehenden Anwendung oder komplette Neuentwicklung)?

• Umfang von Veränderungen: Welche Maßnahmen sind zu ergreifen, welche Stakeholder sind betroffen oder involviert, welche Ereignisse sind auszulösen oder zu verhindern?.

Scope-Modelle werden typischerweise in der Form von Diagrammen, Matrizenund verbalen Erläuterungen dargestellt. Wenn die Abgrenzung schrittweiseerfolgt, sollte das jeweilige Modell für jede Iteration dokumentiert werden.

Elemente

.1 ZieleScope-Modelle werden typischerweise verwendet, um klarzustellen, • worauf Einfluss genommen werden darf• welche Elemente relevant sind• wo die Aktivitäten angesetzt werden.

Der Business-Analyst wählt, abhängig von der jeweiligen Aktion oder dem Bedarfder Stakeholder, ein geeignetes Modell aus.

.2 Grenzen der Veränderung und KontextDer Business-Analyst hat typischerweise mit Elementen zu tun, die im Rahmeneines Vorhabens verändert werden, und mit Elementen, die außerhalb liegen,aber Einfluss auf den zu verändernden Bereich haben. Für alle Elemente innerhalb

TechnikenScope-Modellierung

398

10.41.3

des Bereichs sucht der Business-Analyst geeignete Lösungen. Für alle nicht bein-flussbaren Elemente muss er deren Beziehungen zu dem gegenwärtigen Zustandkennen und bei den geplanten Änderungen entsprechend berücksichtigen.

Dazu legt der Business-Analyst beispielsweise fest: • Geschäftsprozesse, die definiert oder modifiziert werden sollen• betriebliche Funktionen, die hinzugefügt, verändert, optimiert oder neu verteilt werden sollen

• Fähigkeiten, die entwickelt werden sollen oder verändert werden müssen• Reaktionen auf externe oder interne Auslöser• Use Cases und Situationen, die unterstützt werden sollen• Technologien, die verändert oder ersetzt werden sollen• Informationen, die gewonnen, produziert oder verarbeitet werden müssen

• Stakeholder und organisatorische Rollen, die von Veränderungen beeinflusst werden

• interne und externe Agenten und Einheiten, die von der Maßnahme betroffen sind

• Unternehmen und Organisationseinheiten (Abteilungen, Teams, Gruppen), für die sich Änderungen ergeben

• Systeme, Komponenten, Werkzeuge und physische Gegenstände, die für die Veränderung benötigt oder durch sie beeinflusst werden.

.3 DetaillierungsgradDer Detaillierungsgrad, mit dem die Grenzen beschrieben werden, hängt vomZweck der jeweiligen Analyse ab. Dabei ist darauf zu achten, dass mit derBeschreibung mögliche Unklarheiten vermieden werden, ohne einen zu großenAufwand zu betreiben. Die Elemente des fertigen Scope-Modells können einfachaufgelistet oder zu zusammenhängenden Gruppen geordnet werden. So kannbeispielsweise ein zu verändernder Sachverhalt über sämtliche betroffeneGeschäftsprozesse, über einen Geschäftsprozess, der die einzelnen Prozesse insich birgt, oder als eine generische Geschäftsfunktion beschrieben werden. Ganzähnlich können die betroffenen Stakeholder über die einzelnen Stellenbezeich-nungen oder aber über ihre gemeinsame Rolle definiert werden.

.4 BeziehungenDie Untersuchung der Beziehungen zwischen möglichen Elementen des Scopesorgt für Vollständigkeit und Ganzheitlichkeit des Scope-Modells, indem diewechselseitigen Abhängigkeiten oder die Elemente sichtbar werden, die auf dieLösung Einfluss haben oder von ihr selbst beeinflusst werden.

Techniken Scope-Modellierung

399

Sollen spezielle Arten von Beziehungen untersucht werden, können dazu ver-schiedene Darstellungsmethoden genutzt werden:• Eltern-Kind-Beziehung: Leitet Elemente durch eine hierarchische Auf-gliederung aus einem übergeordneten Element ab. Derartige Bezie-hung finden sich beispielsweise in einem Organigramm, in einem Entity-Relationship-Diagramm, bei der Ableitung von Teilprozessen ausübergeordneten Prozessen oder in einem Verbundzustandsmodell.

• Funktionale Zuständigkeit: Stellt eine Beziehung zwischen einem Agenten (Stakeholder, Organisationseinheit oder Lösungskomponente)und einer Funktion dar. Derartige Beziehungen finden sich in Geschäftsprozessmodellen und in Diagrammen zur Darstellung der Zusammenarbeit wie auch in Use-Case-Diagrammen.

• Lieferant/Kunde: Bildet Beziehungen ab, die durch die Übergabe von Informationen oder Materialien entstehen. Elemente können Prozesse,Systeme, Lösungskomponenten oder Organisationseinheiten sowohl von internen als auch von externen Entitäten sein. Beziehungen die-ser Art zeigen sich in Datenflussdiagrammen, Geschäftsprozessmodel-len, Kollaborationsdiagrammen und Robustheitsdiagrammen.

• Ursache/Wirkung: Bildet die Beziehungen zwischen Elementen ab, die andere beeinflussen und/oder von diesen beeinflusst werden. Beziehun-gen dieser Art finden sich beispielsweise im Ursache-Wirkungs-Diagramm.

• Emergent: In sehr komplexen Systemen spielen sehr viele Elemente zusammen, die gemeinsam zu Ergebnissen führen, die nicht nur aus den einzelnen Elementen erklärt werden können.

.5 AnnahmenZum Zeitpunkt der Scope-Modellierung basiert das Modell auf Annahmen, z. B.über den Bedarf, über Voraussetzungen für bestimmte Ergebnisse, Auswirkungenvon Veränderungen oder die Anwendbarkeit und Nutzbarkeit einer Lösung. Diewesentlichen Annahmen und ihre Auswirkungen sollten in einem Scope-Modellexplizit erwähnt werden.

.6 Ergebnis des Scope-ModellierungDie Ergebnisse der Scope-Modellierung können in folgenden Formen dokumen-tiert werden:• verbale Beschreibung der Elemente und der Kriterien, denen zufolge etwas innerhalb oder außerhalb des Scope liegt

• Diagramme, in denen die Beziehungen zwischen den Elementen abge-bildet werden

• Matrizen zur Abbildung der Abhängigkeiten zwischen allen betroffe-nen Elementen.

TechnikenScope-Modellierung

400

Bewertung

.1 Stärken• Ein Scope-Modell erleichtert das Einvernehmen der Beteiligten und bildet die Grundlage für • vertragliche Verpflichtungen• die Schätzung des Projektaufwands• die Rechtfertigung von Entscheidungen darüber, welche Anforderun-gen dazu gehören und welche außerhalb liegen

• die Einschätzung der Vollständigkeit und der Auswirkungen der Lösungen.

.2 Grenzen• Ein Ausgangsmodell, das wenig detailliert ist, wird insbesondere hinsicht-lich der Grenzelemente nicht ausreichend aussagefähig sein.

• Ist erst einmal eine Grenze festgelegt, kann es aus politischen und vertrag-lichen Gründen sehr schwierig sein, sie zu verändern. Auf der anderen Seitekönnen sehr viele Faktoren auftauchen, die diese Grenze infrage stellen, wenn die Ziele erreicht werden sollen. Dazu gehören beispielsweise irrtüm-liche Annahmen, Veränderungen der Situation, Weiterentwicklung der An-forderungen oder technologische Innovationen. Sie alle können dazu führen, dass der ursprüngliche Scope teilweise oder ganz angepasst werden muss.

• Traditionelle Scope-Modelle können nicht mit komplexen Grenzen umge-hen, z.B. mit einem Horizont (eine Grenze, die völlig von der Position des jeweiligen Stakeholders abhängt).

Sequenz-Diagramme

Zweck

Sequenz-Diagramme werden verwendet, um die Logik von Use Cases zu model-lieren, indem sie zeigen, wie Informationen zwischen den Beteiligten bei derDurchführung eines Szenarios ausgetauscht werden.

Beschreibung

Ein Sequenz-Diagramm zeigt, wie Prozesse oder Objekte in einem Szenariozusammenspielen. In einem Diagramm wird dargestellt, welche Klassen für dieDurchführung eines Szenarios benötigt werden und welche Nachrichten (ausgelöst

Techniken Sequenz-Diagramme

401

10.42

10.41.4

10.42.1

10.42.2

durch die Schritte in einem Use Case) sie miteinander austauschen. Das Sequenz-Diagramm zeigt, wie die Objekte in dem Szenario zusammenspielen, aber nicht,wie sie zueinander in Beziehung stehen. Sequenz-Diagramme werden oft auchverwendet, um zu zeigen, wie Komponenten von Benutzerschnittstellen oderSoftware-Komponenten zusammenwirken.

Das Diagramm zeigt die Informationen in einer horizontalen oder vertikalenDarstellung. Die Objekte, die Nachrichten senden, werden im oberen Bereicheiner Seite als Kästen dargestellt und von links nach rechts angeordnet. JedesObjekt nimmt eine eigene Spalte ein, die durch eine durchgehende Linie abge-grenzt wird. Nachrichten, die von einem Objekt zum nächsten weitergeleitetwerden, sind als horizontale Pfeile dargestellt. Die Reihenfolge der Nachrichtenwird in einer Top-Down- und Von-links-nach-rechts-Folge dokumentiert. Dabeiwird mit der ersten Nachricht oben links begonnen und weitere Nachrichtenfolgen nach rechts und nach unten.

Die Standardnotation für ein Sequenz-Diagramm ist Teil der Spezifikation derUnified Modeling LanguageTM (UML®).

Elemente

.1 LifelineBei der Modellierung eines Szenarios in einem Sequenz-Diagramm repräsentierteine Lifeline den Weg eines Objektes. Das folgende Beispiel zeigt als Objekteinen Auftrag. Eine Lifeline wird als eine vertikale gestrichelte Linie dargestellt,die von jedem Symbol für ein Objekt bis zum Fuß der Seite geht.

Abb. 10.42.1: Lifeline

.2 Aktivierungs-BoxEine Aktivierungs-Box repräsentiert den Zeitraum, in dem eine Operation durch-geführt wird. Der Aufruf zur Aktivierung wird durch einen Pfeil mit solider Spitzegezeigt, der zu dem zu aktivierenden Objekt weist. Die Lifeline kann mit einemX beendet werden.

TechnikenSequenz-Diagramme

402

10.42.3

Auftrag

Abb. 10.42.2: Aktivierungs-Box

.3 NachrichtEine Nachricht ist eine Interaktion zwischen zwei Objekten. Eine Nachricht wirdals ein Pfeil dargestellt, der aus der Aktivierungs-Box des Objektes kommt, dasdie Nachricht an die Aktivierungs-Box des Objektes sendet, das diese Nachrichterhält.

Der Name der Nachricht wird oberhalb der Verbindungslinie eingesetzt. Es gibtverschiedene Arten von Nachrichten:• Synchroner Call: Übergibt die Zuständigkeit an das empfangende Objekt. Der Sender kann nicht agieren, bevor er eine Nachricht zurückerhält.

• Asynchroner Call (auch als Signal bezeichnet): Hier kann das Objekt seine eigene Verarbeitung fortsetzen, nachdem das Signal gesendet wurde. Das Objekt kann auch viele Signale gleichzeitig senden, dage-gen nur ein Signal pro Zeiteinheit akzeptieren.

Techniken Sequenz-Diagramme

403

Auftrag

X

Abb. 10.42.3: Nachricht

Bewertung

.1 Stärken• Sequenz-Diagramme zeigen die Interaktionen zwischen den Objekten eines Systems in der zeitlichen Folge, in der Interaktionen stattfinden.

• Zeigen die Interaktionen zwischen Objekten bildlich, so dass die dahinter-stehende Logik relativ einfach mit den Stakeholdern validiert werden kann.

• Use Cases können in ein oder mehrere Sequenz-Diagramme verfeinert werden, um so mehr Details sichtbar zu machen und ein tieferes Verständnis eines Geschäftsprozesses zu ermöglichen.

.2 Grenzen• Es kann viel Zeit darauf verschwendet werden, einen ganzen Satz von Sequenz-Diagrammen für jeden Use Case eines Systems zu entwickeln, die in Wirklichkeit gar nicht benötigt werden.

• Wurden ursprünglich für die Modellierung von Systemabläufen entwickeltund können unter Umständen als zu technisch empfunden werden.

TechnikenSequenz-Diagramme

404

Objekt 1Objekt 3Objekt 2

X

Call

Synchroner Call

Asynchroner CallAntwort

Lifeline

Spezifikationder Ausführung

Beendigung

10.42.4

Stakeholder-Listen, -Karten oder Personas

ZweckStakeholder-Listen, -Karten oder Personas helfen dem Business-Analysten beider Analyse von Stakeholdern und deren Merkmalen. Diese Analyse ist wichtig,um sicherzustellen, dass der Business-Analyst alle möglichen Quellen von Anfor-derungen erkennt und der Stakeholder ganzheitlich verstanden wird. Nur sokönnen bestmögliche Entscheidungen im Sinne der Stakeholder und des Vorha-bens gefällt werden, um Engagement, Zusammenarbeit und Kommunikationgelingen zu lassen.

BeschreibungZur Stakeholder-Analyse gehört die Ermittlung derjenigen, die durch eine vor-gesehene Maßnahme betroffen sind oder die einen gemeinsamen betrieblichenBedarf haben. In einer Stakeholder-Analyse werden die verschiedenen Merkmaleder identifizierten Stakeholder dokumentiert, bewertet und analysiert.

Zu den Merkmalen von Stakeholdern, für die sich ein solcher Aufwand lohnt,gehören:• Anerkennung und Status in dem betroffenen Bereich• Interesse an dem geplanten Änderungsvorhaben und die Einstellung dazu• Einstellung gegenüber der Arbeit und der Rolle der Business-Analyse• hierarchische Position.

Zu den Aufgaben, die mit einer Stakeholder-Analyse verbunden sind, siehe „Ein-bindung der Stakeholder planen“, Kap.3.2.

Für eine Stakeholder-Analyse kann der Business-Analyst eine oder mehrere Tech-niken anwenden. Stakeholder-Listen, -Karten oder Personas sind drei möglicheInstrumente, die dafür infrage kommen.

Elemente

.1 Stakeholder-ListenUm eine Stakeholder-Liste zu erstellen, kann der Business-Analyst verschiedeneTechniken nutzen. Brainstorming und Interviews sind gebräuchlich. Die Listesollte sehr sorgfältig erstellt werden, da sie sowohl für die Stakeholder-Analyseals auch für die Planung der Erhebung, Zusammenarbeit und Kommunikationäußerst wichtig ist.

Stakeholder-Listen können ziemlich umfangreich werden. In der Analyse empfiehltes sich, Kategorien zu bilden und die Liste zu strukturieren. Vollständigkeit ist

Techniken Stakeholder-Listen, -Karten oder Personas

405

10.43.1

10.43.2

10.43.3

10.43

wichtig, damit sichergestellt werden kann, dass keine wichtige Stakeholder-Gruppe übersehen wird, andernfalls könnten Anforderungen nicht oder zu späterkannt werden.

.2 Stakeholder-KartenStakeholder-Karten sind Diagramme, in denen die Beziehungen einzelner Stake-holder sowohl untereinander als auch zu der Lösung dargestellt werden.

Es gibt eine ganze Reihe solcher Stakeholder-Karten. Zu den am weitesten ver-breiteten gehören:• Stakeholder-Matrix: Hier wird der Einfluss eines Stakeholders im Ver-gleich zu seinem Interesse an dem Vorhaben abgebildet.

• Zwiebeldiagramm: Dient zur Abbildung der Nähe eines Stakeholders zu einer Lösung. Einige Stakeholder arbeiten direkt mit einer Lösung oder sind an einem Geschäftsprozess beteiligt, andere sind innerhalb des Unternehmens indirekt betroffen und wieder andere stehen außer-halb des Unternehmens.

Der Business-Analyst beginnt normalerweise die Stakeholder-Analyse mit derÜberprüfung des vorgeschlagenen Scope des Vorhabens und leitet daraus diebetroffenen Personen oder Gruppen ab. Dazu kann erst einmal eine Stakehol-der-Matrix erstellt werden, um die Stakeholder und deren Rollen bei der Ermittlungder Anforderungen zu erkennen. Im Laufe eines Projektes kann sich dann diePosition eines Stakeholders verändern, ausgelöst durch organisatorische Verän-derungen, neue Rahmenbedingungen oder Anpassungen des Scope. Wegendieser möglichen Veränderungen erfolgt eine Stakeholder-Analyse iterativ undmuss immer wieder überprüft werden.

Abb. 10.43.1: Stakeholder-Matrix

TechnikenStakeholder-Listen, -Karten oder Personas

406

Sicherstellung, dass derStakeholder zufrieden bleibt.

Niedrig

Niedrig

Hoch

HochEinfluss auf denStakeholder

Einfluss desStakeholders

Überprüfung, ob sich Interessen oder Einfluss des Stakeholders verändern.

Stakeholder sollte ständig informiert werden, da er wahrscheinlich sehr besorgt ist und befürchtet, Einfluss zu verlieren.

Enge Zusammenarbeit mit dem Stakeholder, um sicherzustellen, dass er mit dem Ergebnis einverstanden ist und es unterstützt.

• Starker Einfluss/Erhebliche Auswirkungen: Diese Stakeholder sind für das Veränderungsvorhaben von zentraler Bedeutung. Der Business-Analyst sollte seine Bestrebungen auf diese Gruppe ausrichten und sie regelmäßig beteiligen.

• Starker Einfluss/Geringe Auswirkungen: Der Bedarf dieser Stakeholder sollte erfüllt werden. Der Business-Analyst sollte sich engagieren und sich mit ihnen abstimmen und darüber hinaus versuchen, sie einzubin-den und ihr Interesse an dem Vorhaben zu wecken.

• Geringer Einfluss/Erhebliche Auswirkungen: Diese Stakeholder unter-stützen das Vorhaben und sind dessen potentielle Botschafter. Der Business-Analyst sollte diese Gruppe aktiv beteiligen und Interesse an deren Bedarf zeigen.

• Geringer Einfluss/Geringe Auswirkungen: Die Stakeholder können auf den üblichen Kommunikationskanälen informiert werden. Besonders Engagement kann sie auch zu Botschaftern machen, um damit weitereUnterstützung für das Vorhaben zu gewinnen.

Abb. 10.43.2 Stakeholder-Zwiebeldiagramm

.3 RACI-MatrixEin anderes gebräuchliches Werkzeug ist die Verantwortlichkeits-Matrix (RACI-Matrix). RACI steht für die vier Arten von Verantwortlichkeit, die ein Stakeholderim Rahmen einer Initiative übernehmen kann: Zuständig (Responsible), Verant-wortlich (Accountable), Beteiligt (Consulted) und Informiert (Informed). Wenneine RACI-Matrix erstellt wird, müssen vorher alle Stakeholder oder -gruppen

Techniken Stakeholder-Listen, -Karten oder Personas

407

Sponsoren, Führungs-kräfte, Experten aus demFachbereich und anderemit der betroffenen Grup-pe Zusammenarbeitende.

Kunden, Lieferanten,Regulierungsstellen u. a.

BetroffeneOrganisationseinheit

Unternehmen

Betroffeneexterne Stakeholder

Ersteller derLösung

Anwender, Benutzerser-vice u. a., deren Arbeitsich ändert, wenn dieLösung eingeführt wird.

Projektteam u. a., die un-mittelbar mit der Erstel-lung der Lösung zu tunhaben.

bekannt sein. Die weitere Analyse dient dann dazu, die jeweilige Position derStakeholder oder -gruppen in der RACI-Matrix zu identifizieren. Dabei ist esüblich, die betreffenden Begriffe vorher zu definieren, um für jeden Nutzerdieser Matrix ein gemeinsames, konsistentes Verständnis über die Zuordnungund die jeweiligen Rollen sicherzustellen.• Zuständig (Responsible): Diese Personen erledigen aktiv die Aufgaben.• Verantwortlich (Accountable): Diese Person ist letztendlich verantwort-lich für den Erfolg der Maßnahme und hat deswegen auch Entschei-dungsbefugnisse. In diese Kategorie kann nur ein Stakeholder fallen.

• Beteiligt (Consulted): Stakeholder oder -gruppen, die um ihre Meinunggefragt werden oder Informationen über die Aufgaben erteilen. Dazu gehören meistens die Experten des Fachbereichs.

• Informiert (Informed): Stakeholder oder -gruppen, die über den Fort-gang des Vorhabens und über die Ergebnisse informiert werden. Hier gibt es eine Einweg-Kommunikation im Unterschied zu einer Zweiweg-Kommunikation bei der Beteiligung.

Abb. 10.43.3: RACI-Matrix

.4 PersonasEine Persona wird definiert als ein fiktionales Wesen oder Archetyp, der veran-schaulicht, wie ein typischer Anwender mit einer Lösung interagiert. Personassind immer dann hilfreich, wenn man den Bedarf einer Gruppe oder einer

TechnikenStakeholder-Listen, -Karten oder Personas

408

Änderungsvorhaben RACI

Entscheider/Sponsor

Business-Analyst

Projektmanager

Entwickler

Tester

Trainer

Applikations-Architekt

Datenmodellierer

Datenbank-Analyst

Infrastruktur-Analyst

Business-Architekt

Informations-Architekt

Anwender

Fachexperte

Andere Stakeholder R C I

C

C

C

R

C

C

C

C

C

C

R

I

I

A

(variiert)

bestimmten Anwenderklasse verstehen möchte. Zwar sind diese Anwender-gruppen fiktional, sie sollen aber tatsächliche Anwender repräsentieren. DurchRecherchen wird versucht, die Anwendergruppe zu verstehen. Die so geschaffenenPersonas basieren dann auf Wissen und nicht auf Meinungen. Für die Untersu-chungen gibt es verschiedene Erhebungstechniken, z.B. Interviews und Frage-bogen. Die Persona wird als Erzählung beschrieben und konzentriert sich vorallem darauf, Einblicke in die Ziele der Gruppe zu erwerben. So kann der Leserdie Perspektive der Stakeholder erkennen. Personas bringen den Anwender zumLeben, so werden seine Bedürfnisse auch für diejenigen nachvollziehbar, die dieLösung entwerfen und bauen.

Bewertung

.1 Stärken• Stakeholder-Listen, -Karten oder Personas verdeutlichen die konkreten Personen, die bei der Anforderungsermittlung beteiligt werden müssen.

• Erleichtern dem Business-Analysten die Planung von Zusammenarbeit, Kommunikation und Moderation zur Beteiligung aller Gruppen von Stake-holdern.

• Sind hilfreich, um im Zeitablauf auftretende Veränderungen bei den Betroffe-nen zu verstehen.

.2 Grenzen• Der Business-Analyst, der kontinuierlich in den gleichen Teams zusammen-arbeitet, könnte diese Technik nicht anwenden, weil sich aus seiner Sicht in seinen Gruppen nur geringfügige Änderungen ergeben.

• Es kann schwierig und auch politisch riskant sein, Annahmen über ein spezi-fisches Merkmal eines Stakeholders zu formulieren.

Statusmodellierung

Zweck

Statusmodellierung wird verwendet, um die verschiedenen Zustände einer Entitätinnerhalb eines Systems, den Übergang von einem Zustand zu einem anderenund die jeweils möglichen Folgen für die Entität zu beschreiben und zu analy-sieren.

Techniken Statusmodellierung

409

10.43.4

10.44

10.44.1

Beschreibung

Eine Entität ist ein Objekt oder ein Konzept innerhalb eines Systems. Eine Entitätkann in unterschiedlichen Prozessen genutzt werden. Der Lebenszyklus jederEntität hat einen Anfang und ein Ende.

In einem Statusmodell (wird gelegentlich auch als Statusübergangsmodell bezeich-net) ist ein Status eine formelle Darstellung eines Zustands. Es wird verwendet,wenn es erforderlich ist, ein präzises und konsistentes Verständnis einer Entitätzu gewinnen, die ein komplexes Verhalten aufweist mit komplexen Regeln, diedas Verhalten steuern.

Ein Statusmodell beschreibt• einen Satz möglicher Zustände für eine Entität• eine Folge von Zuständen, in der sich eine Entität befinden kann• den Übergang von einem Status zu einem anderen• Ereignisse und Bedingungen, die die Entität dazu bringen, den Status zu verändern

• Aktionen, die in der Entität in jedem Zustand erfüllt werden können oder müssen, wenn sich die Entität durch ihren Lebenszyklus bewegt.

Während ein Prozessmodell alle Entitäten zeigt, die von einem Prozess genutztoder beeinflusst werden, zeigt ein Statusmodell die komplementäre Sicht. Hierwird sichtbar, welchen Einfluss alle Prozesse haben, die eine Entität berühren.

Elemente

.1 StatusEine Entität hat eine begrenzte Anzahl möglicher Status während ihres Lebens-zyklus, sie kann aber zur gleichen Zeit mehrere Status einnehmen. Jeder Statuswird mit einem Namen und den Aktivitäten beschrieben, die in diesem Zustanderledigt werden können. Dabei kann es Regeln dafür geben, welche Aktivitätenerledigt werden können oder müssen, und auf welche Ereignisse die Entitätreagiert oder welche Ereignisse sie selbst auslöst.

Ein komplexer Status kann in Sub-Status untergliedert werden.

.2 StatusübergangWie eine Entität sich von einem Zustand in einen anderen verändert, kann überdie Schritte in einem Prozess, über Geschäftsregeln oder über den Inhalt vonInformationen bestimmt werden. Die Folge der Zustände ist nicht immer linear;die Entität kann mehrere Status überspringen oder zu einem früheren Statuszurückkehren, und das unter Umständen mehr als einmal.

TechnikenStatusmodellierung

410

10.44.2

10.44.3

Ein Übergang kann konditional sein (ausgelöst durch ein bestimmtes Ereignisoder das Eintreten einer Bedingung) oder automatisch erfolgen (ausgelöst durchdie Fertigstellung der erforderlichen vorherigen Aktivitäten oder auch durchZeitablauf). Er kann auch rekursiv sein, indem die Entität einen Zustand verlässtund zu diesem wieder zurückkehrt. Ein Statusübergang wird über das Ereignisbeschrieben, welches den Übergang auslöst, oder über die Bedingungen, vondenen es abhängt, ob eine Entität auf ein Ereignis antworten muss oder auchüber die Aktionen, die im Zusammenhang mit dem Ereignis passieren.

.3 Statusdiagramm Ein Statusdiagramm zeigt den Lebenszyklus einer Entität von der Entstehungüber die verschiedenen Status, die diese Entität einnehmen kann, bevor sie aus-gemustert wird.

Ein Status in einem Statusdiagramm wird als Rechteck mit abgerundeten Eckendargestellt. Es kann eine beliebige Anzahl von Status geben. Ein Status kann inSub-Status aufgegliedert werden.

Der Übergang von einem Status in einen anderen wird durch einen Pfeil vomAusgangsstatus dargestellt, dessen Pfeilspitze zum nächsten Status weist. Optionalkann auch der Name des Ereignisses genannt werden, das ursächlich dafür ist,dass die Entität von einem Status zu einem anderen wechselt oder es könnendie Bedingungen oder Aktionen genannt werden.

Anfang und Ende des Lebenszyklus einer Entität werden mit jeweils speziellenSymbolen dargestellt.

Abb. 10.44.1: Statusübergangsdiagramm

Techniken Statusmodellierung

411

ÜbergangStatus 1

Status 2

Ausgangs-status

Endstatus

Status 3

.4 StatustabelleEine Statustabelle ist eine zweidimensionale Matrix, in der die Status und dieÜbergänge zwischen den Status dargestellt werden. Sie kann zur Erhebung undAnalyse als Alternative, als Vorgänger oder als Ergänzung zu einem Statusdia-gramm verwendet werden. Eine Statustabelle kann als einfacher Einstieg in einStatusmodell dienen, um die Namen der Status und der Ereignisse mit den Fach-experten des Bereichs zu erheben.

Jede Zeile zeigt einen Ausgangszustand, den Übergang und den Endstatus.Wenn ein Status mehrere Übergänge haben kann, gibt es für jeden Übergangeine eigene Zeile.

Ein Status, der am Ende einer Zeile steht, kann der Start in einer anderen Zeilesein.

Bewertung

.1 Stärken• Ein Statusmodell identifiziert Geschäftsregeln und Informationsattribute, die zu der modellierten Entität gehören.

• Identifiziert und beschreibt die Aktivitäten der Entität in verschiedenen Status.

• Ist ein effektiveres Dokumentations- und Kommunikationswerkzeug als eine Textdarstellung, insbesondere wenn die zu beschreibende Entität mehr als einige wenige Status, Übergänge und Bedingungen hat, die diese Über-gänge auslösen.

.2 Grenzen• Wird normalerweise nur genutzt, um Informations-Entitäten, die als kom-plex gelten, zu verstehen und zu kommunizieren. Einfache Entitäten können auch verstanden werden, ohne den Aufwand zu betreiben, der für den Bau eines Statusmodells erforderlich ist.

• Der Aufbau eines Statusmodells erscheint am Anfang einfach; es kann aber auch schwierig und zeitaufwändig sein, sich mit den beteiligten Experten des Fachbereichs über die erforderlichen Details zu einigen.

• Wenn ein Statusdiagramm erstellt wird, ist hohe Präzision hinsichtlich der Status und Übergänge erforderlich.

TechnikenStatusmodellierung

412

10.44.4

Umfrage oder Fragebogen

Zweck

Eine Umfrage oder ein Fragebogen wird verwendet, um von einer großen AnzahlBefragter in strukturierter Form und in relativ kurzer Zeit Informationen für dieBusiness-Analyse zu erheben, einschließlich Informationen über Kunden, Produkte,Arbeitsverfahren und Verhaltensweisen.

Beschreibung

Ein Fragebogen oder eine Umfrage beinhaltet einen Katalog von Fragen, diesich an Stakeholder und Experten der Fachbereiche wenden. Die Antwortenwerden dann gesammelt und analysiert, um Wissen über das jeweilige Fachgebietzu gewinnen. Die Fragen können in schriftlicher Form, aber auch mündlich,zum Beispiel per Telefon, unterbreitet und eventuell auch durch eine Aufzeich-nungstechnik dokumentiert werden.

Zwei Fragetypen können in einer Studie oder einer Befragung eingesetzt werden:• Geschlossene Fragen: Der Befragte wird gebeten, aus vorformulierten Antwortmöglichkeiten auszuwählen. Dabei kann es sich um Ja/Nein-Antworten, Multiple-Choice-Antworten, Rangfolgen oder um Fragen handeln, in denen es um den Grad der Zustimmung geht. Solche Fragen sind immer dann hilfreich, wenn die möglichen Antworten relativ klar erkennbar und begrenzt sind. Antworten auf geschlossene Fragen sind einfach zu analysieren und können in quantifizierte Ergeb-nisse verdichtet werden.

• Offene Fragen: Der Befragte antwortet in freier Form. Er hat nicht die Möglichkeit, aus vorgegebenen Antworten zu wählen. Offene Fragen bieten sich an, wenn der betreffende Sachverhalt bekannt, die mög-lichen Antworten aber nicht klar sind. Offene Fragen können zu aus-sagefähigeren Ergebnissen und zu einem breiteren Spektrum von Antworten führen als geschlossene Fragen. Es ist allerdings schwierig und zeitaufwändig, Antworten auf offene Fragen zu gruppieren, zu qualifizieren und zu verdichten, da sie unstrukturiert, oft sehr subjektivformuliert, redundant oder auch unvollständig sein können.

Fragen sollten so formuliert werden, dass sie die Antworten nicht beeinflussen,sie sollten eine neutrale Sprache verwenden und nicht so strukturiert oder alsFragefolgen aufgebaut sein, dass der Befragte die erwartete Antwort darausableiten könnte.

Techniken Umfrage oder Fragebogen

413

10.45

10.45.1

10.45.2

Elemente

.1 VorbereitungEin Fragebogen oder eine Umfrage ist nur dann nützlich, wenn er/sie detailliertvorbereitet wurde, um sicherzustellen, dass die benötigten Informationen mög-lichst effizient erhoben werden.

Zur Vorbereitung gehört:• Festlegung des Ziels: Ein klares und präzises Ziel zeigt, was mit der Erhebung erreicht werden soll. Alle Fragen folgen diesem Ziel.

• Festlegung der Zielgruppe: Es muss bestimmt werden, welche und wieviele Personen in welcher Zusammensetzung (z.B. nach den Kriterien Sprache, Standort, Kultur, Fachbereich) zum Untersuchungsbereich gehören. Daraus lassen sich Hinweise auf das Design der Erhebung ableiten.

• Auswahl des geeigneten Fragetyps: Vom Ziel einer Erhebung hängt dieangemessene Kombination offener und geschlossener Fragen ab.

• Auswahl der Befragten: Abhängig von der Umfrage bzw. der Art des Fragebogens und der Anzahl von Personen in der Zielgruppe ist zu entscheiden, ob es notwendig und machbar ist, die gesamte Gruppe zu befragen. Das kann notwendig sein, selbst wenn die Gruppe sehr groß ist, beispielsweise wenn die Zusammensetzung der Gruppe etwa hinsichtlich der räumlichen Verteilung, regulatorischer Unterschiede, fehlender Standardisierung der Arbeit oder unterschiedlicher Geschäftsprozesse sehr heterogen ist. Wenn die betroffene Zielgruppe sehr groß ist und eher offene Fragen gestellt werden sollen, kann es notwendig sein, eine spezielle Voruntersuchung für die Entwicklung des Fragebogens durchzuführen. Wird ein statistisch abgesichertes Auswahlverfahren gewählt, lässt sich sicherstellen, dass die Zielgruppe in der Stichprobe repräsentiert ist und die Ergebnisse verallgemeinert werden können.

• Festlegung der Verteilung und Rücksendung der Ergebnisse: Für jede einzelne Zielgruppe muss die Kommunikation geplant werden.

• Festlegung der Antwortquote und des Abgabetermins: Es muss fest-gelegt werden, welche Antwortquote mindestens erreicht werden muss und ab wann die Umfrage als abgeschlossen gelten kann. Falls die Mindestanzahl der Antworten nicht erreicht wird, kann die Aus-sagekraft der Ergebnisse begrenzt sein.

• Festlegung, ob die Umfrage oder der Fragebogen durch individuelle Interviews ergänzt werden soll: Können durch die Umfrage oder den Fragebogen nicht alle relevanten Sachverhalte geklärt werden, bieten sich weitergehende Interviews, entweder vor oder nach der schrift-lichen Befragung, an.

TechnikenUmfrage oder Fragebogen

414

10.45.3

• Formulierung der Fragen: Es ist sicherzustellen, dass alle Fragen auf dieZiele der Studie ausgerichtet sind.

• Test der Umfrage/des Fragebogens: Ein Test zeigt mögliche Fehler und Verbesserungsmöglichkeiten auf.

.2 Verteilung des FragebogensWenn die Umfrage/der Fragebogen verteilt wird, sollten die Ziele der Erhebungebenso bekannt-gegeben werden wie die weitere Verwendung der Ergebnisseund Regelungen hinsichtlich Vertraulichkeit und Anonymität.

Bei der Auswahl der geeigneten Distributionsmethode (z.B. persönlich, E-Mail,Postweg oder Erhebungswerkzeug) sollten unter anderem folgende Kriterienbeachtet werden:• Dringlichkeit der Ergebnisse• geforderte Sicherheit• geographische Verteilung der Befragten.

.3 Dokumentation der ErgebnisseBei der Dokumentation der Ergebnisse fallen folgende Aufgaben an:• Zusammenstellung der Antworten• Verdichtung der Ergebnisse• Bewertung der Ergebnisse und Identifikation weiterführender Themen• Entwicklung von Kategorien zur Kodierung der Daten• Aufgliederung der Daten in messbare Bestandteile.

Bewertung

.1 Stärken• Umfragen und Fragebogen bringen schnelle Ergebnisse und sind relativ wenig aufwändig.

• Erleichtern die Sammlung von Informationen bei einer großen Zielgruppe.• Stellen keine zu hohen zeitlichen Anforderungen an die Antwortenden.• Sind effektiv und effizient, wenn die Befragten regional weit verstreut sind.

• Werden vorwiegend geschlossene Fragen verwendet, können sehr gut qualifizierte Informationen für statistische Analysen gewonnen werden.

• Beim Einsatz offener Fragen kann die Erhebung Ergebnisse hervorbringen,die durch andere Erhebungstechniken nur schwer zu ermitteln sind.

Techniken Umfrage oder Fragebogen

415

10.45.4

.2 Grenzen• Sollen unverfälschte Ergebnisse erhoben werden, ist Spezialwissen hin-sichtlich statistischer Stichproben erforderlich, soweit keine Vollerhebung durchgeführt werden kann.

• Die Antwortquoten können für eine Auswertung mit statistischen Wahr-scheinlichkeiten zu klein sein.

• Werden offene Fragen genutzt, ist die Analyse der Ergebnisse aufwändig.• Mehrdeutige Fragen können falsch oder gar nicht beantwortet werden.• Nachfassaktionen können erforderlich werden.

SWOT-Analyse

Zweck

SWOT-Analyse ist eine einfache und dennoch effektive Technik, um Stärkenund Schwächen, Chancen und Risiken eines Unternehmens zu ermitteln.

Beschreibung

Die SWOT-Analyse wird dazu verwendet, den Zustand eines Unternehmens unterBerücksichtigung interner und externer Faktoren zu bewerten.

Dazu wird eine kurze, präzise, realistische Sprache verwendet, die sich weitgehendauf Fakten bezieht. Die SWOT-Analyse dient als Bewertung vor dem Hintergrundbekannter Erfolgsfaktoren. Sie kann auf jeder Ebene, dem gesamten Unterneh-men, einzelnen Divisionen oder Geschäftseinheiten bis hin zu einem Projektoder einem Individuum genutzt werden. Mithilfe dieser Analyse können die Sta-keholder auf systematischem Weg die Auswirkungen gegebener Bedingungenauf zukünftige Zustände oder Ereignisse besser verstehen.

Eine SWOT-Analyse kann verwendet werden, um• die gegenwärtige Umwelt eines Unternehmens zu bewerten• vorhandene Informationen mit Stakeholdern auszutauschen• die bestmöglichen Optionen zur Erreichung der betrieblichen Ziele zu erkennen

• wesentliche Erfolgsbarrieren zu erkennen und Maßnahmen zu planen, wie diese Barrieren überwunden werden können

• Projektpläne anzupassen und neu zu definieren, soweit sich dazu die Notwendigkeit ergibt

TechnikenSWOT-Analyse

416

10.46

10.46.2

10.46.1

• Stärken zu identifizieren, die es einem Unternehmen ermöglichen,neue Strategien einzuführen

• auf Basis gegebener Anforderungen Kriterien für den Projekterfolg zu entwickeln

• Schwachstellen zu identifizieren, die Projektziele bedrohen• Strategien zu entwickeln, um mögliche Bedrohungsszenarien abzu-wehren.

Elemente

Die SWOT-Analyse ist ein Akronym für Strengths-Weaknesses-Opportunities-and Threats-Analyse.• Strengths (Stärken): Dazu gehört alles, was ein Unternehmen oder eine Einheit gut beherrscht. Das können beispielsweise erfahrene Mitarbeiter, effektive Prozesse, leistungsfähige IT-Systeme, gute Kun-denbeziehungen oder andere interne Erfolgsfaktoren sein.

• Weaknesses (Schwächen): Aktionen und Funktionen, die von der jeweiligen Einheit schlecht oder gar nicht beherrscht werden.

• Opportunities (Chancen): Externe Faktoren, aus denen die jeweilige Einheit für sich Vorteile ziehen kann. Dazu können neue Märkte, neue Technologien, Veränderungen bei den Mitbewerbern oder andere Faktoren gehören.

• Threats (Risiken): Externe Faktoren, die die betrachtete Einheit negativ beeinflussen können. Das können beispielsweise neue Mitbewerber, konjunkturelle Abschwünge oder andere Kräfte sein.

Beginnt eine SWOT-Analyse mit Risiken und Chancen, wird damit gleichzeitigdie Grundlage geschaffen, um Stärken und Schwächen zu analysieren.

Techniken SWOT-Analyse

417

10.46.3

Abb. 10.46.1: SWOT-Matrix

Bewertung

.1 Stärken• Die SWOT-Analyse ist ein wertvolles Werkzeug, um Unternehmen, Produkte, Prozesse oder Stakeholder besser zu verstehen.

• Unterstützt den Business-Analysten dabei, den Fokus der Stakeholder auf wichtige Erfolgsfaktoren des Unternehmens zu lenken.

.2 Grenzen• Die Ergebnisse einer SWOT-Analyse bieten lediglich einen Überblick, weitere detaillierte Analysen sind in der Regel notwendig.

• Wenn eine SWOT-Analyse nicht in einem eindeutigen Kontext durch-geführt wird, können die Ergebnisse wenig zielgerichtet sein und Sach-verhalte betreffen, die in der gegenwärtigen Situation irrelevant sind.

TechnikenSWOT-Analyse

418

Stärken

• Stärke• Stärke• Stärke

Schwächen

• Schwäche• Schwäche• Schwäche

Chancen

• Chance• Chance• Chance

Risiken

• Risiko• Risiko• Risiko

SO-Strategien ST-Strategien

WO-Strategien WT-Strategien

Wie können die Stärken der Einheit genutzt werden, um Chancen wahrzunehmen?SO-Strategien lassen sich relativ direkt umsetzen.

Wie kann die Einheit ihre Stärken nutzen, um potenti-elle Risiken abzuwehren?Können Risiken in Chancen umgewandelt werden?

Kann die Einheit eine Chance nutzen, um eine Schwäche zu beseitigenoder abzuschwächen?Gewährleistet die Chance die Entwicklung neuer Fähigkeiten?

Kann sich die Einheit neu aufstellen, um das Risiko zu beseitigen?Sollte die Einheit den Markt verlassen?Zu WT-Strategien gehören auch Worst-Case-Szenarien.

10.46.4

Use Cases und Szenarien

Zweck

Use Cases und Szenarien beschreiben, wie eine Person oder ein System mit dermodellierten Lösung interagiert, um ein Ziel zu erreichen.

Beschreibung

Use Cases beschreiben die Interaktionen zwischen einem primären Aktor, derLösung und allen sekundären Aktoren, die benötigt werden, um die Ziele desprimären Aktors zu erreichen. Use Cases werden normalerweise durch den pri-mären Aktor ausgelöst, können aber auch durch ein anderes System oder einexternes Ereignis angestoßen werden.

Ein Use Case beschreibt die möglichen Ergebnisse von Versuchen, mit einerLösung ein Ziel zu erreichen. Es zeigt im Detail die verschiedenen möglichenWege auf, indem primäre und alternative Abläufe definiert werden. Der Primär-oder Basisablauf zeigt den direktesten Weg, um das Ziel des Use Case zuerreichen. Besondere Umstände und Ausnahmen, die verhindern, dass das Zielauf diesem direkten Weg erreicht wird, werden in Alternativ- oder Ausnahme-Abläufen dokumentiert. Use Cases werden aus der Sicht des Aktors beschriebenund bilden nicht die internen Prozesse einer Lösung ab.

Use-Case-Diagramme sind graphische Abbildungen der Beziehungen zwischenAktoren und einem oder mehreren Use Cases, die von der Lösung unterstütztwerden.

In einigen Ansätzen wird zwischen Business-Use Cases und System-Use Casesunterschieden. Dabei zeigt der Business-Use Case die Interaktionen des Aktorsmit einem Prozess oder einer Funktion, während der System-Use Case die Inter-aktionen des Aktors und einer Software-Applikation darstellt.

Ein Szenario beschreibt einen einzigen Fall, mit dem der Aktor ein bestimmtesZiel erreichen kann. Szenarien werden als eine Folge von Schritten dargestellt,die ein Aktor oder eine Lösung durchläuft, um ein Ziel zu erreichen. Ein UseCase beschreibt mehrere Szenarien.

Elemente

Es gibt kein fest vorgegebenes, universal gültiges Format für Use Cases. Die fol-genden Elemente werden häufig bei der Beschreibung eines Use Case doku-mentiert.

Techniken Use Cases und Szenarien

419

10.47

10.47.1

10.47.2

10.47.3

.1 Use-Case-DiagrammEin Use-Case-Diagramm visualisiert den Scope einer Lösung, indem es die betroffenenBeteiligten und deren Interaktionen mit bestimmten Use Cases ebenso dokumentiertwie die Beziehungen, die zwischen den Use Cases bestehen. Die Unified ModelingLanguage™ (UML®) ist die Standardnotation für ein Use-Case-Diagramm.

Beziehungen

Beziehungen zwischen Aktoren werden als Assoziationen bezeichnet. Eine Ver-bindungslinie als Symbol einer Assoziation bedeutet, dass ein Aktor zu der Funk-tionalität eines Use Case Zugang hat. Assoziationen stellen keinen Input oderOutput, keine Abhängigkeiten oder zeitlichen Größen dar.

Es gibt zwei weit verbreitete Beziehungen zwischen Use Cases:• Erweitern (extend): Damit kann ein zusätzliches Verhalten in den Use Case eingefügt werden. Ein erweiterter Use Case muss auch ohne die Erweiterung bereits voll funktionsfähig und somit nicht von der Erwei-terung abhängig sein, um zu funktionieren. Diese Beziehung kann dazu verwendet werden, um anzuzeigen, dass ein alternativer Ablauf zu einem bestehenden Use Case hinzugefügt wurde, damit neue Anforderungen erfüllt werden können.

• Einschließen (include): Erlaubt es einem Use Case, die Funktionalität eines anderen Use Case zu nutzen. Der eingeschlossene Use Case muss dafür in sich selbst kein vollständiger Use Case sein. Er wird nur in dem Fall aktiv, wenn er von einem Aktor aufgerufen wird. Diese Beziehung wird meistens dann genutzt, wenn mehrere Use Cases eine bestimmte Funktionalität gemeinsam nutzen oder wenn eine kom-plexe Logik zusammengefasst werden soll.

Abb. 10.47.1: Use-Case-Diagramm

TechnikenUse Cases und Szenarien

420

Use Case 4

Use Case 2Erweiterungspunkt:

Rufe Use Case 3auf

Use Case 3

Use Case 1

System

<<erweitern>> <<einschließen>>

Aktor 1 Aktor 2

.2 Beschreibung eines Use Case

Name

Jeder Use Case hat einen eigenständigen Namen. Der Name besteht normaler-weise aus einem Verb, mit dem eine Tätigkeit des Aktors beschrieben wird, undeinem Substantiv, das entweder beschreibt, woran etwas getan wird oder welchesZiel mit der Aktivität verfolgt wird.

Ziel

Das Ziel ist eine kurze Beschreibung des gewünschten Ergebnisses des Use Caseaus der Sicht des jeweiligen Aktors. Es stellt die Zusammenfassung des UseCase dar.

Aktoren

Ein Aktor ist eine Person oder ein System außerhalb der Lösung, die/das mit derLösung zusammenwirkt. Jeder Aktor hat einen spezifischen Namen, mit demdie Rolle bezeichnet wird, die er im Zusammenspiel mit der Lösung erfüllt. Ineinigen Ansätzen des Use Case wird empfohlen, keine Systeme oder Ereignisseals Aktoren zu behandeln.

Ein Use Case wird durch einen Aktor ausgelöst. Er wird als der primäre Aktorfür diesen Use Case bezeichnet. Andere Aktoren, die den Use Case unterstützen,werden als sekundäre Aktoren bezeichnet.

Bedingungen

Eine Bedingung ist ein Sachverhalt, der erfüllt sein muss, damit der Use Caseausgelöst werden kann. Die Bedingung wird in dem Use Case nicht geprüft. Siestellt eine Voraussetzung für die Durchführung dar.

Auslöser

Ein Auslöser ist ein Ereignis, das den Fluss in einem Use Case startet. Der häufigsteAuslöser ist eine Aktion, die von dem primären Aktor vorgenommen wird.

Auch kann ein zeitliches Ereignis (z.B. eine bestimmte Zeit) einen Use Case aus-lösen. Das ist immer dann der Fall, wenn ein Use Case zu bestimmten Tageszeitenoder Kalenderdaten aufgerufen wird, z.B. die Routine am Ende eines Tages odereines Monats.

Arbeitsfluss (Flow of Events)

Ein Arbeitsfluss ist die Folge von Schritten, die von einem Aktor und der Lösungbei der Durchführung eines Use Case erledigt wird. Die meisten Beschreibungenvon Use Cases heben einen Primär- oder Hauptablauf hervor. Das ist in derRegel der kürzeste oder schnellste Weg, um das Ziel des Aktors zu erreichen.

Techniken Use Cases und Szenarien

421

Use Cases können auch alternative oder Ausnahmefälle beinhalten. AlternativeFlüsse beschreiben andere Wege, die ein Aktor bei Bedarf gehen kann, um dasZiel des Use Case zu erreichen. Ausnahmeflüsse beschreiben die gewünschteAntwort der Lösung für den Fall, dass das angestrebte Ziel nicht auf direktemWeg erreicht werden kann.

Nachbedingungen oder Garantien

Eine Nachbedingung ist ein Sachverhalt, der nach Abschluss des Use Case erfülltsein muss. Die Nachbedingungen müssen für alle möglichen Wege durch denUse Case erfüllt sein, sowohl für die primären als auch für die sekundären Wege.Im Use Case können auch Nachbedingungen für den erfolgreichen und füreinen nicht erfolgreichen Durchlauf genannt werden. Diese werden als Garantienbezeichnet; Erfolgsgarantien beschreiben die Nachbedingungen für einen erfolg-reichen Ablauf. Minimal-Garantien beschreiben Bedingungen, die erfüllt seinmüssen, selbst wenn das eigentliche Ziel nicht erreicht wird. Sie können sich aufSicherheitsanforderungen oder auf die Integrität von Daten beziehen.

Bewertung

.1 Stärken• Use-Case-Diagramme können den Scope eines Vorhabens verdeutlichen und erleichtern das Verständnis der Anforderungen.

• Use-Case-Beschreibungen können wegen ihrer einfachen Darstellung gut von den Stakeholdern nachvollzogen werden.

• Die Berücksichtigung eines angestrebten Ziels oder eines gewünschten Ergebnisses stellt sicher, dass der Wert des Use Case für das Unterneh -men ausdrücklich formuliert wird.

• Use-Case-Beschreibungen stellen das funktionale Verhalten eines Systems dar.

.2 Grenzen• Die hohe Flexibilität bei der Beschreibung von Use Cases kann dazu füh-ren, dass Informationen aufgenommen werden, die besser mithilfe ande-rer Techniken, z.B. nicht-funktionaler Anforderungen oder Geschäfts-regeln, dokumentiert würden.

• Entscheidungen und die ihnen zugrundeliegenden Geschäftsregeln soll-ten nicht direkt in einem Use Case aufgezeichnet, sondern getrennt ver-waltet und von dort verlinkt werden.

• Das flexible Format von Use Cases kann dazu führen, dass nicht angemes-sene oder nicht notwendige Details dokumentiert werden.

• Use Cases bilden ganz bewusst nicht das Design einer Lösung ab. Es kannerheblicher Aufwand entstehen, um die Schritte aus den Use Cases zu einer Software-Architektur umzuwandeln.

TechnikenUse Cases und Szenarien

422

10.47.4

User Stories

Zweck

Eine User Story ist eine kurzgefasste, präzise Beschreibung der Funktionalitätoder Qualität, die benötigt wird, um einem spezifischen Stakeholder von Nutzenzu sein.

Beschreibung

User Stories beschreiben den Bedarf eines spezifischen Stakeholders und ermög-lichen es Teams, in einer einfachen Form Lösungsmerkmale zu beschreiben, diefür einen Stakeholder von Bedeutung sind. Sie dienen als Grundlage, um denBedarf zu ermitteln und ermöglichen Priorisierung, Aufwandsschätzung undPlanung von Lösungen. Eine User Story besteht typischerweise aus einem oderzwei Sätzen, in denen beschrieben wird, wer den Bedarf hat und welches Ziel erverfolgt sowie weitere Informationen, die helfen können, den Scope der UserStory zu verstehen. User Stories fokussieren auf den für den Stakeholder zuschaffenden Nutzen und erleichtern die Ermittlung von Anforderungen, indemsie weitere Gespräche mit den Stakeholdern fördern, die auch helfen können,funktionale Anforderungen zu gruppieren.

User Stories lassen sich nutzen, um• den Bedarf der Stakeholder zu ermitteln und die Entwicklung von Lösungen zu priorisieren

• einen Fertigstellungstermin abzuschätzen und zu planen• die Basis für Akzeptanztests zu legen• den geschaffenen Wert zu quantifizieren und zu messen• weitere, abgeleitete Anforderungen zu verfolgen• zusätzliche Analysen durchzuführen• das Projektmanagement und das Berichtswesen zu unterstützen.

Elemente

.1 Titel (optional)Der Titel einer User Story beschreibt die Aktivität, die ein Stakeholder mit einemSystem ausführen will. Typischerweise geschieht dies durch einen Satz, mit demein Ziel ausgedrückt wird, so wie es auch in Use Cases der Fall ist.

Techniken User Stories

423

10.48.3

10.48.1

10.48.2

10.48

.2 Statement of ValueEs gibt keine verbindliche Struktur für User Stories.

Das am weitesten verbreitete Muster enthält drei Komponenten:• Wer: Rolle des Anwenders oder konkrete Person.• Was: Erforderliche Aktion, gefordertes Feature oder Verhalten oder diegewünschte Qualität.

• Weshalb: Nutzen oder Wert, der nach der Fertigstellung geliefert werden muss.

Beispiel: „Als (wer) muss ich (was) machen, damit (weshalb) erreicht werden kann.“

.3 VertiefungUser Stories helfen den Bearbeitungsteams, das beschriebene Lösungsmerkmalund den gewünschten Nutzen genauer zu untersuchen und zu verstehen. Dadie User Story nicht alles enthält, was über den Bedarf des Stakeholders bekanntsein sollte, wird diese Story weiter ausgeformt und vertieft.

.4 AkzeptanzkriterienEine User Story kann durch die Entwicklung detaillierter Akzeptanzkriterien abgestütztwerden (siehe dazu „Akzeptanz- und Bewertungskriterien“, Kap. 10.1). Akzep-tanzkriterien definieren die Grenzen einer User Story und können dem Team helfen,zu erkennen, was eine Lösung leisten muss, um den Stakeholdern nützlich zu sein.Akzeptanzkriterien können bei Bedarf um andere Modelle ergänzt werden.

Bewertung

.1 Stärken• User Stories sind für Stakeholder leicht zu verstehen.• Können unterschiedlichste Erhebungstechniken nutzen.• Konzentrieren sich auf den Wert für die Stakeholder.• Schaffen ein gemeinsames Verständnis über den jeweiligen Bereich, wennbei der Entstehung und Vertiefung mit den Betroffenen kooperiert wird.

• Betreffen kleine, umsetzbare Einheiten der Funktionalität, die auch getes-tet werden können. So wird es möglich, schnell Ergebnisse zu schaffen und dabei auf das Feedback der Kunden einzugehen.

.2 GrenzenGanz allgemein sind User Stories ein Werkzeug, um schnell Anforderungen zuermitteln und zu priorisieren. Sie dienen weniger dazu, eine langfristig nutzbare

TechnikenUser Stories

424

10.48.4

Grundlage zu schaffen oder detaillierte Analysen zu ermöglichen. Wenn dieserGrundsatz missachtet wird, können sich die folgenden Probleme ergeben:

• Das schrittweise Vorgehen kann für ein Team eine echte Herausforderungsein, da am Anfang normalerweise noch nicht alle notwendigen Informa-tionen und detaillierten Spezifikationen vorliegen.

• Immer wieder müssen die Ergebnisse in einen größeren Rahmen einge-passt werden. Ein Team kann den Gesamtüberblick verlieren, wenn die User Stories nicht immer wieder rückblickend validiert oder durch grund-sätzlichere Analysen unterlegt werden.

• Notwendige Informationen können fehlen, die für die Governance, für die Planung der weiteren Aufgaben oder für die Erwartungen der Stake-holder benötigt werden. Oft werden weitere Unterlagen benötigt.

Anbieter-Assessment

Zweck

Ein Anbieter-Assessment dient dazu, die Fähigkeit eines Anbieters einzuschätzen,inwieweit er eingegangene Verpflichtungen hinsichtlich der Lieferung oder Bereit-stellung eines Produktes oder einer Leistung gewährleisten kann.

Beschreibung

Wenn Lösungsbestandteile von externen Lieferanten oder Anbietern bereitgestelltwerden (sie können am Design, an der Konstruktion oder Einführung bzw. derlaufenden Pflege einer Lösung oder von Lösungskomponenten beteiligt sein)oder wenn die Lösung insgesamt Dritten übertragen wird (Outsourcing), könnensich ganz spezielle Anforderungen an diese dritte Seite ergeben. Es kann not-wendig sein, zu prüfen, ob der Lieferant finanziell stabil ist, bestimmte Mengenund/oder Qualitäten an Personal bereitstellen oder Compliance gewährleistenkann. Nicht-funktionale Anforderungen können genutzt werden, um den Service-Level dieses Lieferanten festzulegen. Dazu kann eine sorgfältige Risikoprüfung(Due Diligence) durchgeführt werden oder es wird eine Zertifizierung durch eineunabhängige Stelle verlangt.

Eine Lieferantenprüfung wird durchgeführt, um sicherzustellen, dass der Lieferantzuverlässig ist, dass das Produkt die geforderte Leistung bringt und die Erwar-tungen und Anforderungen des Unternehmens erfüllt. Diese Einschätzung kannformalisiert werden durch die Ausschreibung einer Informationsanfrage (RFI –Request for Information), einer Anfrage (RFQ – Request for Quote), einer offenenAusschreibung (RFT – Request for Tender) oder einer Ausschreibung (RFP –

Techniken Anbieter-Assessment

425

10.49

10.49.1

10.49.2

Request for Proposal). Das kann aber auch auf informellem Weg geschehen,etwa indem Empfehlungen oder Mund-zu-Mund-Propaganda berücksichtigtwerden. Die betrieblichen Standards, die Komplexität eines Vorhabens und dieBedeutung einer Lösung können das Ausmaß der Formalität bestimmen, nachder Anbieter beurteilt werden.

Elemente

.1 Wissen und ErfahrungEiner der wesentlichen Gründe dafür, Anbieter einzuschalten, liegt darin, dassdiese Anbieter Wissen und Erfahrungen besitzen, die innerhalb des Unternehmensnicht vorhanden sind. Dazu werden beispielsweise Anbieter angesprochen, diebesondere Erfahrungen in bestimmten Methoden oder Technologien besitzen,um interne Mitarbeiter an dieser Expertise teilhaben zu lassen.

.2 Lizenzierung und PreismodelleWird eine Lösung oder Lösungskomponente extern eingekauft oder wird dieEntwicklung Dritten übertragen, sind die Lizenzbedingungen oder Preismodellezu berücksichtigen. Häufig unterscheiden sich funktional ähnliche Lösungenmarkant hinsichtlich der Lizenzmodelle, die sorgfältig analysiert und vor demHintergrund unterschiedlicher Szenarien bewertet werden müssen, um festzu-stellen, welche Option die beste Kosten-Nutzen-Relation hinsichtlich der möglichenSzenarien bietet.

.3 Stellung des Anbieters im MarktJeder Anbieter sollte mit dessen Mitbewerbern im Hinblick auf die jeweiligePosition im Markt verglichen werden, um zu entscheiden, mit welchen Lieferantenzusammengearbeitet werden soll. Dabei kann beispielsweise überprüft werden,wie weit das Profil des eigenen Unternehmens mit den übrigen Kunden desAnbieters übereinstimmt. Auch ist zu beachten, wie sich die Position des Liefe-ranten im Markt entwickelt, insbesondere wenn eine langfristige Partnerschaftangestrebt wird.

.4 VertragsbedingungenVertragsbedingungen sind insbesondere hinsichtlich der Kontinuität und Integritätder gelieferten Produkte und Leistungen zu berücksichtigen. Dazu muss dasUnternehmen prüfen, ob die Lizenzbedingungen, der Vorbehalt geistigen Eigen-tums und die technologische Infrastruktur möglicherweise später zu Problemenführen könnte, falls das Unternehmen sich entscheiden sollte, zu einem anderenAnbieter zu wechseln. Auch kann es wichtig sein, zu prüfen, inwieweit ein Lie-ferant den Schutz vertraulicher Daten des Unternehmens gewährleisten kann.Außerdem wird berücksichtigt, unter welchen Bedingungen spezielle Anpas-

TechnikenAnbieter-Assessment

426

10.49.3

sungen des Produkts auf die Anforderung des Kunden geboten werden, inwieweites regelmäßige Updates gibt und in welchen Etappen geforderte Features voraus-sichtlich bereitgestellt werden.

.5 Erfahrungen, Reputation und Stabilität des AnbietersDie Erfahrungen anderer Kunden können wertvolle Informationen darüber bieten,inwieweit der Lieferant in der Lage sein wird, vertragliche und nicht-vertraglicheVerpflichtungen zu erfüllen. Lieferanten können auch hinsichtlich der Erfüllungrelevanter externer Standards zu Qualität, Sicherheit und Professionalität bewertetwerden. Es kann unter Umständen notwendig werden, vom Lieferantenbestimmte Maßnahmen für den Fall zu verlangen, dass der Anbieter in finanzielleSchwierigkeiten gerät, um so sicherzustellen, dass die Lösung auch dann wei-tergeführt und weiterentwickelt werden kann, wenn sich die Situation desAnbieters grundlegend verändert.

Bewertung

.1 Stärken• Anbieter-Assessment steigert die Wahrscheinlichkeit, dass das Unternehmen eine produktive und faire Beziehung mit einem passenden und verlässlichen Anbieter entwickelt, die zur nachhaltigen Zufriedenheit mit dem Anbieter führt.

.2 Grenzen• Kann zeitaufwändig sein und viele Ressourcen binden.• Kann das Risiko des Scheiterns im weiteren Verlauf der Partnerschaft nichtverhindern.

• Subjektive Einschätzungen können das Ergebnis verfälschen.

Workshops

Zweck

Workshops bringen Stakeholder zusammen, um ein gemeinsames Ziel zu errei-chen.

Beschreibung

Ein Workshop ist ein Ereignis, zu dem wichtige Stakeholder oder Fachbereichs-experten für eine begrenzte Zeit fokussiert zusammenarbeiten. Ein Workshop

Techniken Workshops

427

10.49.4

10.50

10.50.1

10.50.2

kann unterschiedlichen Zwecken dienen, z.B. Planung, Analyse, Design, Abgren-zung, Anforderungsermittlung, Modellierung oder eine beliebige Kombinationdieser Vorhaben. Der Workshop kann dazu beitragen, Ideen für neue Featuresoder Produkte zu entwickeln, Konsens hinsichtlich eines Sachverhalts herzustellenoder Anforderungen und Entwürfe zu überprüfen.

Zu Workshops gehören normalerweise• eine repräsentative Gruppe von Stakeholdern• ein definiertes Ziel• eine interaktive und kooperative Zusammenarbeit• ein definiertes Arbeitsergebnis• ein Moderator.

Workshops können helfen, Vertrauen, gegenseitiges Verstehen und eine funktio-nierende Kommunikation zwischen den Stakeholdern zu entwickeln und Arbeits-ergebnisse hervorzubringen, die zukünftige Aufgaben strukturieren und lenken.

Idealerweise wird ein Workshop von einem erfahrenen, neutralen Moderatorgesteuert; diese Rolle kann aber auch ein Gruppenmitglied übernehmen. EinProtokollant hält die Ergebnisse und die offenen Punkte fest. Der Business-Analyst kann als Moderator oder Protokollant tätig werden. Ist der Business-Analyst selbst Fachexperte, kann er in dem Workshop auch als normaler Teil-nehmer mitwirken. Das kann allerdings zu Irritationen hinsichtlich der Rolle desBusiness-Analysten führen und sollte nur mit Bedacht geschehen.

Elemente

.1 Vorbereitung des WorkshopsBei der Vorbereitung eines Workshops sorgt der Business-Analyst dafür, dass• der Zweck und die gewünschten Ergebnisse feststehen• die für die Teilnahme vorgesehenen Stakeholder bestimmt sind• Moderator und Protokollführer benannt sind• eine Agenda vorhanden ist• klar ist, wie die Ergebnisse festgehalten werden• die Sitzung geplant ist und die Teilnehmer eingeladen werden• geeignete Räume und Sachmittel bereitstehen• die Agenda und andere Materialien vorab an die Beteiligten versendet werden

• bei Bedarf vorab Interviews mit den Beteiligten durchgeführt werden.

TechnikenWorkshops

428

10.50.3

.2 Rollen im WorkshopZu einem erfolgreichen Workshop gehören normalerweise verschiedene Rollen:• Sponsor: Ist letztendlich für das Ergebnis verantwortlich, obwohl er normalerweise an dem Workshop selbst nicht teilnimmt.

• Moderator: Stellt sicher, dass in dem Workshop professionell und objektiv kooperiert wird, stellt die Ziele und die Agenda für den Work-shop vor, gewährleistet die Struktur und die Einhaltung elementarer Regeln, sorgt dafür, dass alle beim Thema bleiben und auf die gewünschten Ergebnisse hinarbeiten. Er moderiert die Entscheidungs-findung und die Auflösung von Konflikten und stellt sicher, dass alle Beteiligten Gelegenheit haben, sich aktiv einzubringen.

• Protokollant: Hält die Entscheidungen in einem vorher festgelegten Format fest und behält die Punkte im Auge, die für die spätere Behandlung zurückgestellt wurden.

• Timekeeper: Eine mögliche Rolle, die dafür sorgt, dass nicht mehr Zeit als vorgesehen für die einzelnen Bestandteile der Agenda aufgewen-det wird.

• Teilnehmer: Dazu gehören die zentralen Stakeholder und die Fach-experten. Sie sollen ihr Wissen und ihre Sichtweise einbringen, einan-der zuhören und die behandelten Themen möglichst objektiv erörtern.

.3 Durchführung des WorkshopsDamit alle Beteiligten wissen worum es eigentlich geht, schildert der Moderatorzu Beginn normalerweise den Zweck und die gewünschten Ergebnisse des Work-shops. Workshops können auch mit einem spielerischen Einstieg beginnen, umdas Eis zu brechen.

Die Vereinbarung gemeinsamer Regeln kann wesentlich dazu beitragen, einekonstruktive und produktive Arbeitssituation zu schaffen. Zu den elementarenRegeln gehören beispielsweise:• Meinungen anderer respektieren• jeder beteiligt sich• Diskussionen, die nicht unmittelbar zum Thema gehören, sind nur zu bestimmten Zeiträumen erlaubt

• die Sache steht im Vordergrund und nicht die Person• ein bestimmtes Abstimmverfahren für Entscheidungen ist vereinbart.

Während des Workshops konzentriert sich der Moderator darauf, dass alle Akti-vitäten auf den Zweck und die gewünschten Ergebnisse ausgerichtet sind.

Techniken Workshops

429

.4 Nachbereitung des WorkshopsNach dem Workshop sorgt der Moderator dafür, dass die offenen Punkte ausdem Workshop weiterverfolgt werden, er vervollständigt die Dokumentationund verteilt sie an die Beteiligten und an alle diejenigen, die über das Arbeitser-gebnis informiert sein sollten.

Bewertung

.1 Stärken• In Workshops können in relativ kurzer Zeit gemeinsam getragene Ergeb-nisse gefunden werden.

• Es können Stakeholder mitarbeiten, Entscheidungen fällen und mehr Verständnis für die Gesamtzusammenhänge gewinnen.

• Workshops sind meistens weniger zeit- und kostenaufwändig als eine Serie von Interviews.

• Die Beteiligten erhalten unmittelbares Feedback auf ihre Sicht.

.2 Grenzen• Es kann für einzelne Stakeholder schwierig sein, an einem bestimmten Termin teilzunehmen. Das erschwert die Terminfindung.

• Der Erfolg eines Workshops hängt maßgeblich vom Wissen der Beteilig-ten und von der Qualität des Moderators ab.

• Werden viele Personen beteiligt, kann der Zeitbedarf sehr groß werden. Umgekehrt können wesentliche Gesichtspunkte übersehen werden, wenn zu wenige Personen beteiligt werden. In diesem Fall kann es auch passieren, dass Entscheidungen gefällt werden, die nicht die Mehrheit derStakeholder widerspiegeln.

TechnikenWorkshops

430

10.50.4

431

In der Arbeit der Business-Analyse werden Perspektiven genutzt, um auf Aufgabenund Techniken zu fokussieren, die spezifisch für dieses Vorhaben sind. Diemeisten Vorhaben verwenden eine oder mehrere Perspektiven. In diesem BABOK®-Leitfaden werden die folgenden Perspektiven behandelt:

• Agil• Business Intelligence• Informationstechnologie• Geschäftsarchitektur• Business Process Management (BPM).

Damit wird nicht unterstellt, dass es für die Business-Analyse keine weiterenrelevanten Perspektiven gibt. Die hier erörterten Perspektiven sind jedoch einigeder Stoßrichtungen, die besonders weit verbreitet waren, als diese Version desWerkes entstand.

In jedem Vorhaben kann/können eine, mehrere oder alle diese Perspektiven ver-folgt werden. So kann zum Beispiel ein Vorhaben eine technologische Kompo-nente haben, die dazu führen kann, dass Änderungen an der Prozessorganisationvorgenommen werden, und es kann beschlossen worden sein, für das Vorhabenteilweise oder komplett einen agilen Ansatz zu verfolgen. In einem anderenVorhaben kann es darum gehen, zwei Unternehmen zu fusionieren, was eserforderlich macht, auf die betrieblichen Fähigkeiten zu schauen und einzu-schätzen, wie sich die Transformation auf diese Fähigkeiten auswirkt (Geschäfts-architektur-Perspektive). Zusätzlich benötigt das obere Management aktuellereInformationen für die Entscheidungsfindung und Analyse (Business-Intelligence-Perspektive). Große oder komplexe Vorhaben werden sich wahrscheinlich mitallen Perspektiven auseinandersetzen.

Während die hier im einzelnen beschriebenen Aufgaben auf allen Gebieten derBusiness-Analyse angewendet werden sollen, sind sie auch für jede spezifischePerspektive der Business-Analyse relevant. Perspektiven bieten Wege an, aufdenen die Arbeit der Business-Analyse in dem jeweiligen Kontext fokussiertangegangen werden kann. Die Perspektiven helfen dabei, die Wissensgebiete

Perspektiven11

und Aufgaben aus dem BABOK® zu interpretieren und zu verstehen, indem sieden Blick darauf richten in welcher Perspektive man gerade unterwegs ist.

Jede Perspektive folgt der gleichen Struktur:• Scope des Change-Vorhabens• Scope der Business-Analyse• Ansätze, Frameworks, Referenzmodelle und/oder Techniken• Basiskompetenzen• Auswirkungen auf die Wissensgebiete.

Die agile PerspektiveIn der agilen Perspektive werden die Besonderheiten der Business-Analyse her-vorgehoben, wenn sie in einem agilen Umfeld stattfindet.

Agil bedeutet, Flexibilität in den Vordergrund zu stellen, die sich in einem Satzan Werten und Prinzipien sowie einer Anzahl sich ergänzender Praktiken äußert.Agile Vorhaben bedeuten ständige Veränderungen. Der Business-Analyst, der inagilen Vorhaben tätig ist, wägt ständig neu ab, passt seine Bemühungen undTaktiken immer wieder an und justiert sie neu. Der Business-Analyst leistet seineArbeit und liefert sie erst zum spätesten noch zu vertretenen Zeitpunkt ab, umso lange wie möglich flexibel auf Veränderungen reagieren zu können. Er steigtnicht eher in Details ein als dieser Detaillierungsgrad für das agile Team vonNutzen ist.

Eine agile Business-Analyse stellt sicher, dass die benötigten Informationen ineinem angemessenen Detaillierungsgrad zur rechten Zeit bereitstehen. Der Busi-ness-Analyst hilft agilen Teams, die folgenden Fragen zu beantworten:

• Welchen Bedarf wollen wir befriedigen?• Lohnt es sich, diesen Bedarf zu befriedigen?• Sollten wir etwas abliefern, um den Bedarf zu befriedigen?• Was ist der richtige Weg, diesen Bedarf zu befriedigen?

Business-Analyse findet in einem agilen Vorhaben kontinuierlich statt und stütztsich hauptsächlich auf zwischenmenschliche Fähigkeiten wie Kommunikation,Moderation, Coaching und Verhandlungen. Der Business-Analyst ist aktives Mit-glied eines agilen Teams und unterstützt häufig Planung, Analyse, Tests und Prä-sentationen. In einem agilen Team kann die Business-Analyse durch einen Pro-duktmanager, Auftraggeber, Business-Analysten oder durch eine andere bestimmteRolle im Team übernommen werden. Der Business-Analyst hilft dem Team dabei,veränderte Annahmen und andere sich ergebende Veränderungen zu erkennen.

Die IIBA-Broschüre „Agile Extension to the BABOK®“ Guide liefert einen erwei-terten Überblick der Rollen, Einstellungen und Praktiken der Business-Analyse in

432

11.1

PerspektivenDie agile Perspektive

Mehr Infor-mationen imKapitel 1.4.6

einem agilen Ansatz, sowie auch weitere Details zu den Werten und Prinzipiendes „Agile Manifesto“ (www.agilemanifesto.org).

Scope des Change-Vorhabens

Der Business-Analyst, der in agilen Vorhaben mitwirkt, arbeitet mit dem Auf-traggeber auf einem strategischen Niveau zusammen und hilft dabei zu definieren,wie das vorgeschlagene Produkt oder Feature mit den betrieblichen Zielen ver-einbar ist. Er arbeitet mit verschiedenen Stakeholdern und dem gesamten Teamzusammen, um die Produktvision auf eine priorisierte Liste der zu erledigendenAufgaben herunter zu brechen. Die Priorisierung von Sachverhalten (oder diepriorisierte Liste unerledigter Aufträge) orientiert sich normalerweise an denRessourcen und Fähigkeiten, die benötigt werden, um das gewünschte Produktherzustellen. Dabei wird darauf Wert gelegt, dass die Ergebnisse mit demhöchsten Nutzen zuerst bearbeitet werden.

Der Business-Analyst kann stellvertretend für einen Stakeholder tätig werdenoder direkt mit dem Sponsor oder Auftraggeber zusammenarbeiten.

In einem agilen Umfeld werden Veränderungen und schnelle Reaktionen aufdiese Veränderungen gefordert. Agile Teams liefern kleine, inkrementelle Ver-änderungen und setzen sich mit priorisierten Sachverhalten immer nur währendeiner Iteration auseinander. So kann das agile Team sich ergebende Veränderungenbei der nachfolgenden Iteration relativ einfach umsetzen. Eine Iteration ist dabeiein vereinbarter Zeitraum für eine bestimmte Arbeit.

Anforderungen werden auf dem Wege laufender Untersuchung und Analyseder betrieblichen Bedarfe entwickelt. Dabei ist zu beachten, dass zwar fast alleagilen Ansätze iterativ, nicht aber alle iterativen Vorgehensweisen zwingend agilsind. Es gibt auch eine Reihe agiler Ansätze, die nicht iterativ arbeiten, wie zumBeispiel die Kanban-Methode.

Bei agilen Vorhaben entwickelt sich der Scope ständig weiter. Das wird mithilfeder Backlog-Liste gemanagt, die kontinuierlich überprüft und neu priorisiertwird. In diesem Prozess wird auch der Scope präzisiert und neu definiert, umden sich weiter entwickelnden betrieblichen Bedürfnissen gerecht zu werden.

Wenn sich wesentliche Veränderungen ergeben, die erheblichen Einfluss aufden Gesamtwert und die Ziele des Projekts haben, kann es sein, dass das Projektvertagt und neu bewertet wird.

.1 Breite des ChangeAgile Ansätze werden zur Erfüllung einer breiten Palette an Bedarfen in einemUnternehmen eingesetzt. Die häufigste Anwendung agiler Praktiken findet sichin der Software-Entwicklung. Viele Unternehmen haben aber auch begonnen,agile Prinzipien in nicht-softwarespezifischen Veränderungen wie Prozessopti-

Perspektiven Die agile Perspektive

433

11.1.1

mierungen und Verbesserungsprojekten einzusetzen. Vorhaben mit agilem Ansatzkönnen innerhalb einer einzelnen Abteilung abgewickelt werden oder sich übermehrere Teams, Abteilungen, Divisionen eines Unternehmens erstrecken.

Unternehmen, die mit der agilen Philosophie noch nicht sehr vertraut sind, fälltes leichter, sich mit den agilen Denkweisen vertraut zu machen, wenn sie sichauf kontinuierliche Verbesserungsvorhaben, permanenten Change und sichtbareFortschritte konzentrieren. Die agilen Denkweisen zu übernehmen bedeutet,agile Prinzipien kulturell einzuverleiben und nicht anzunehmen, dass es sichhierbei lediglich um eine einzuführende Methode oder Praxis handelt.

.2 Tiefe des ChangeVorhaben, in denen ein agiler Ansatz genutzt wird, sind häufig Teil eines größerenProgramms, wozu beispielsweise ein umfassendes Change-Vorhaben in einemUnternehmen oder das Reengineering von Prozessen gehören können. Der agileArbeitsfluss konzentriert sich häufig – aber nicht immer – auf die Entwicklungvon Software. Die anderen Elemente des Programms können agil oder nacheiner anderen Methode bearbeitet werden. Agile Prinzipien und Praktiken sindhäufig unter folgenden Voraussetzungen erfolgsversprechend:

• Es gibt ein klares Commitment des Kunden und hohe Bereitschaft bei den bevollmächtigten Fachexperten.

• Der betriebliche Bedarf oder die vorgeschlagene Lösung sind komplex oder kompliziert.

• Betriebliche Bedarfe verändern sich oder sind noch nicht voll bekannt.

Agile Ansätze können bei Vorhaben verwendet werden, in denen es um die Ent-wicklung einer neuen Lösung oder um die Beibehaltung und Verbesserung bereitsbestehender Lösungen geht. So können beispielsweise bei kritischen Verände-rungsvorhaben Prozesse hinzugefügt werden, um behördlichen Anforderungengerecht zu werden und mit diesen kritischen Aspekten umzugehen.

.3 Nutzen und umgesetzte LösungenDer Nutzen und die umgesetzten Lösungen sind in einem agilen Vorhabenähnlich wie bei jedem anderen. Der wesentliche Unterschied liegt darin, dass ineinem agilen Ansatz möglichst schnell und auf eine äußerst kooperative WeiseNutzen geschaffen wird, indem bei der Planung darauf geachtet wird, dass kon-tinuierlich Verbesserungen erreicht werden.

Ein agiles Vorgehen erzeugt den Nutzen vor allem durch den Ansatz des agilenTeams, die bereits erledigte Arbeit laufend zu überprüfen und Feedback zugeben. Stakeholder haben Gelegenheit, immer wieder das Produkt zu überprüfen.So können sie fehlende Anforderungen schon sehr früh erkennen. Die Lösungentwickelt sich im Zeitablauf. Dabei wird davon ausgegangen, dass schnell undflexibel auf Veränderungen eingegangen wird. Klare und transparente Kommu-


434

nikation ist äußerst wichtig, damit die Bestrebungen des agilen Teams auf diebetrieblichen Bedarfe und Erwartungen abgestimmt werden.

In einem neuen Team spielt der Business-Analyst häufig eine zentrale Rolle dabei,enge Beziehungen und Vertrauen der Teammitglieder untereinander und mitexternen Stakeholdern aufzubauen, um so kooperative Diskussionen und dieEinsatzbereitschaft zu fördern. Diese Interaktion ermöglicht es dem agilen Team,genau den Nutzen zu liefern, der den sich weiter entwickelnden Erwartungender Stakeholder entspricht.

.4 Umsetzungsansatz Agile Ansätze konzentrieren sich auf die Interaktion von Menschen, transparenteKommunikation und kontinuierliche Lieferung von werthaltigen Veränderungen.

Jeder agile Ansatz hat seine eigenen speziellen Merkmale, die es dem Teamerlauben, einen Weg zu wählen, der für das anstehende Vorhaben am bestengeeignet ist. Einige Teams haben festgestellt, dass eine hybride Lösung odereine Kombination von Ansätzen erforderlich ist, um im Rahmen der gegebenenRestriktionen erfolgreich zu sein.

Die Ergänzungsbroschüre „Agile Extension to the BABOK®“ Guide liefert weitereInformationen zu anderen Umsetzungsansätzen.

.5 Zentrale AnnahmenDie folgenden Annahmen sind in einer agilen Umgebung weit verbreitet:

• Geänderte Anforderungen werden begrüßt, auch wenn sie spät im Entwicklungsprozess auftauchen.

• Das betriebliche Problem lässt sich in ein Set an Bedürfnissen herunter-brechen, die mit einer Kombination von Technologie- und Geschäfts-prozessveränderungen erfüllt werden können.

• Die Kunden agiler Vorhaben sind sehr engagiert und die Fachexperten stehen voll hinter dem agilen Ansatz und sind mit ausreichenden Kompetenzen ausgestattet.

• Im Idealfall bleibt die Teammitgliedschaft konstant und die Teammit-glieder wechseln nicht andauernd zu anderen Teams.

• Interdisziplinäre Teams, die am gleichen Standort angesiedelt sind, werden bevorzugt, um so effizientere und effektivere Face-to-Face-Kontakte zu fördern. Agile Ansätze können bei räumlich getrennten Teams trotzdem gut funktionieren, sofern geeigneter Support vorhan-den ist und die Kommunikationswege gut ausgebaut sind.

• Teammitglieder können mehr als eine Rolle innerhalb eines Teams übernehmen, sofern dies notwendig ist und das Team die notwen-digen Fähigkeiten hat (beispielsweise fachübergreifende Teams).


435

• Teammitglieder sind gegenüber kontinuierlichen Verbesserungsprozes-sen und einer regelmäßigen Überprüfung/Inspektion des Wertschöp-fungsbeitrags ihrer Leistungen positiv eingestellt.

• Agile Teams besitzen ausreichende Befugnisse und organisieren ihre Arbeit selbst.

Scope der Business-Analyse

.1 Auftraggeber des ChangeEs ist wichtig, dass der Auftraggeber eines agilen Vorhabens mit der agilen Phi-losophie, der Denkweise und dem Vorgehen vertraut ist. Er sollte offen sein fürkonstantes Feedback und wissen, dass von Stakeholdern Abwägungen bei Ziel-konflikten gefordert sind. Ein agiler Auftraggeber versteht und akzeptiert, dass

• situativ flexibel geplant wird anstelle einer langfristigen und inflexiblen (deterministischen) Planung

• ein fixer Zeitabschnitt für einen Arbeitszyklus festgelegt wird und dies auch als sinnvoll angesehen wird

• die Beteiligung des Auftraggebers notwendig und wertvoll ist.

Die aktive Mitwirkung des Auftraggebers (oder der befugten Fachexperten) indem agilen Team ist wichtig für den Erfolg, damit der Auftraggeber in der Lageist, das Produkt vorab zu begutachten und zu verstehen, während es noch ent-wickelt wird. Damit hat der Auftraggeber die Möglichkeit, dem Team kontinu-ierlich Feedback zu geben und das Produkt noch zu verändern, wenn der Bedarfsich ändert.

.2 Ziele und Akteure des ChangeAgile Ansätze sind immer dann am erfolgreichsten, wenn die Unternehmenskulturund die Arbeitsumgebung eine intensive Zusammenarbeit fördern, wenn häufigmiteinander kommuniziert wird und wenn inkrementelle Verbesserungen gegen-über einem „großen Wurf“ bevorzugt werden.

Agile Teams sind oft entweder klein oder bestehen selbst aus mehreren kleinenTeams. Die einfache und flache Struktur ändert nichts an der Tatsache, dass dieErgebnisse eine große Gruppe von Stakeholdern betreffen können. Der für denChange Zuständige, der zu den Stakeholdern gezählt wird, ist auch bei einemagilen Ansatz der gleiche. Von den folgenden Rollen/Personen gehen die wesent-lichen Impulse bei einem Change mit agilem Vorgehen aus:

• Leiter eines agilen Teams: Er ist der Moderator der Teamarbeit. Ein agiler Teamleiter hat oft ähnlich ausgeprägte Soft Skills wie ein Projekt-manager, delegiert aber die Aufgaben der Planung, Terminierung und Priorisierung vollständig an das Team. Anstelle eines traditionellen


436

11.1.2

Befehls- und Kontrollansatzes wird das Management in allen agilen Ansätzen als dienende und unterstützende Kraft gesehen. Je nach Ansatz wird diese Rolle Scrum Master, Iteration Manager, Team Leader oder Coach genannt.

• Kundenvertreter oder Produkteigner: Er ist ein aktives Teammitglied, das dafür verantwortlich ist, dass die entstehenden Lösungen oder Vorschläge den Anforderungen gerecht werden, die dem Team zur Bearbeitung übertragen wurden. In Scrum nennt man diese Rolle Produkteigner (product owner). Die Dynamic Systems Development Method (DSDM) spricht von einem Visionär (visionary) und Extreme Programming (XP) von einem Kundenvertreter (customer represen-tative).

• Teammitglieder: Die Spezialisten oder Fachexperten decken die tech-nische Seite ab und nehmen die Interessen der Kunden wahr. Je nach Umfang und Kontext des Vorhabens übernehmen Teammit-glieder unterschiedliche, spezialisierte Rollen im Team. Experten für Benutzerfreundlichkeit, technische Architekten und Datenbank-Administratoren sind nur einige der Spezialistenrollen, die das Team nach Bedarf unterstützen.

• Externe Stakeholder: Alle weiteren Stakeholder, die keine Teammitglie-der sind, aber ein starkes Interesse am Ergebnis des Projektes haben oder für die Fertigstellung benötigt werden, unterstützen die Arbeit des Teams.

.3 Die Rolle des Business-AnalystenIn einem agilen Team können ein oder mehrere Mitglieder Fähigkeiten der Busi-ness-Analyse einbringen, dabei ist es unerheblich, ob sie den Titel „Business-Analyst“ führen oder nicht. Die Anerkennung von Teammitgliedern, die fach-übergreifend qualifiziert sind, führt dazu, dass die Praktiken der Business-Analysenicht nur bei einem einzelnen Experten gesehen werden.

In agilen Teams können die Aktivitäten der Business-Analyse durch einen odermehrere der folgenden Akteure durchgeführt werden:

• im Team mitarbeitender Business-Analyst• Kundenvertreter oder Auftraggeber• Aktivitäten werden im gesamten Team aufgeteilt.

Die Ergänzungsbroschüre „Agile Extension to the BABOK®“ Guide liefert dazuweitere Informationen.


437

.4 Ergebnisse der Business-AnalyseIn einer agilen Umgebung bringt Business-Analyse die Menschen zusammen undstellt sicher, dass das agile Team die richtigen Stakeholder zum richtigen Zeitpunkteinbezieht. Offene Kommunikation und gute Zusammenarbeit sind wesentlicheErgebnisse einer erfolgreichen Business-Analyse in einem agilen Projekt.

Der Business-Analyst stellt sicher, dass die Projektvision und -richtung permanentauf die Unternehmensziele und den betrieblichen Bedarf ausgerichtet sind. DerBusiness-Analyst ist mitverantwortlich für die Definition strategischer Kriterienzum Projektabschluss. Während des Projekts hilft er bei der Festlegung derAkzeptanzkriterien. Er hilft auch mit bei der Formulierung der Produktvision.Eine solche Produktvision steht bei agilen Projekten oft am Anfang.

Eine konsequente Dokumentation und deren Form hängen weitgehend vomjeweiligen Zweck und Kontext ab. Agile Ansätze ziehen es vor, nicht mehr alsunbedingt notwendig und just-in-time zu dokumentieren anstatt starren Doku-mentationsmodellen zu folgen. Dieser Ansatz erlaubt es, erforderlichen Changekurzfristig zu realisieren und gleichzeitig den Änderungsaufwand gering zuhalten. Zwingende Dokumentation, wie sie für Prüfung/Audit und Compliance-Berichte vorgeschrieben ist, sind jedoch in jedem Lieferzyklus zu erstellen. Es istwichtig, dass die Dokumente einen identifizierten Bedarf abdecken und mehrWert schaffen als für ihre Produktion und Wartung aufgewendet wird.

Ansätze und Techniken

.1 AnsätzeAgil ist ein Oberbegriff für eine Vielzahl von Ansätzen. In allen agilen Ansätzewird Business-Analyse praktiziert, doch nur einige wenige definieren die Rolle derBusiness-Analyse explizit. Die Kerneigenschaft eines agilen Ansatzes ist ihre Aus-richtung auf die Werte und Prinzipien des „Agile Manifesto“. Ein agiles Teamkann auch verschiedene Ansätze miteinander kombinieren, entweder von Anfangan oder im Projektfortschritt, wenn so besser gewährleistet werden kann, dass imjeweiligen Projekt und in der Arbeitsumgebung effektiv Nutzen geschaffen wird.


438

11.1.3

Tabelle 11.1.1: Agile Ansätze


439

Ansatz Kurzbeschreibung

Crystal Clear Teil der Familie der Crystal-Methodologie, die sich über Härteund Farbe definiert. Die Härte bezieht sich darauf, wie unterneh-menskritisch oder schadensintensiv Aktivitäten sind, so dass mitsteigendem Risikograd ein rigoroses Vorgehen und eine eherdeterministische Planung notwendig werden. Die Farbe beziehtsich auf das Gewicht des Projekts in Bezug auf verschiedeneDimensionen wie die Anzahl involvierter Personen oder riskanterElemente im Projekt.

DisciplinedAgile Delivery (DAD)

Ein Rahmenmodell für Entscheidungsprozesse, das Ideen auseiner Vielzahl agiler Ansätze integriert. Es soll ein Projekt vomStart bis zur Lieferung des Ergebnisses unterstützen. DAD gibtkeine fixe Vorgehensweise vor und erlaubt Teams, ihre eigenenLebenszyklen und Ansätze anzupassen.

Dynamic Systems Development Method (DSDM)

Ein Rahmenmodell zur Projektarbeit, das sich darauf konzen-triert, dass Kosten, Qualität und Termine zu Projektbeginn fest-gelegt werden, wobei Unvorhergesehenes durch eine Verände-rung der zu entwickelnden Features aufgefangen wird. MoS-CoW-Priorisierungstechniken helfen beim Scope-Management.Time Boxing oder kurze fokussierte Arbeitseinheiten mit eindeu-tig festgelegten Ergebnissen werden zur Steuerung eingesetzt.

EvolutionaryProjectManagement(Evo)

Eine Methode des Projektmanagements zur schrittweisen Entwick-lung und Umsetzung eines Systems. Der Schwerpunkt liegt aufeiner Quantifizierung des Nutzens für mehrere Stakeholder. DiePlanung der einzelnen Entwicklungsschritte erfolgt auf der Grund-lage der messbaren Wertschöpfung. Die Methode nutzt Tabellenzur Schätzung von Wirkungen als formelle Technik, um zu beurtei-len, inwieweit die Lösungen geeignet sind, Nutzen für die unter-schiedlichen Stakeholder bei gegebenen Kosten zu erzeugen.

Extreme Programming (XP)

Es ist nach dem Konzept benannt, bei dem gute Techniken derSoftware-Entwicklung ins Extreme gesteigert werden. DiesesKonzept setzt auf den technischen Entwicklungsprozess undumfasst Programmierung zu zweit (Pair Programming), test-getriebene Entwicklung und andere handwerkliche Ansätze dertechnischen Praxis. Die technischen XP-Praktiken werden oft miteinem Rahmenmodell des agilen Managements kombiniert.

Feature DrivenDevelopment (FDD)

Es stellt den Nutzen einzelner Funktionalitäten für den Kundenbei der Softwareentwicklung in den Mittelpunkt. Beispielsweisewird nach einer eher groben Abstimmung des Scopes eine Fea-ture-Liste aufgestellt. Alle Planungs-, Design- und Entwicklungs-aktivitäten werden auf Basis von Feature Sets durchgeführt.

Tabelle 11.1.1: Agile Ansätze (Fortsetzung)

.2 TechnikenDie folgende Tabelle listet Techniken auf, die in agilen Ansätzen weit verbreitetsind. Die Ergänzungsbroschüre „Agile Extension to the BABOK® Guide“ beschreibtdiese Techniken im Detail.


440

Ansatz Kurzbeschreibung

Kanban Kanban funktioniert auch ohne fixe Iterationen. Die Arbeit wirdals kontinuierlicher Strom von Aktivitäten im Entwicklungspro-zess erledigt. Ein wesentliches Element ist die Begrenzung desArbeitsumfangs, der gleichzeitig geleistet werden darf (soge-nannte „work in progress“-Limite oder WIP). Das Team bearbei-tet nur eine beschränkte Anzahl von Vorhaben gleichzeitig. DieArbeit an einem neuen Vorhaben kann erst beginnen, wenn dasvorherige abgeschlossen ist und der nachfolgende Aktivitäten-strom dies erfordert.

Scaled AgileFramework®

(SAFe™)

Ein Bezugsrahmen zur Umsetzung agiler Praktiken auf Unterneh-mensebene. Er betont einzelne Rollen, Teams, Aktivitäten undArtefakte, die notwendig sind, um ein agiles Vorgehen von derTeam- auf die Unternehmensebene skalieren zu können.

Scrum Ein schlankes Rahmenmodell des Prozessmanagements, das aufempirischer Prozesssteuerung aufsetzt. Die Arbeit wird in einerFolge von Iterationen einer fixierten Länge (von etwa einemMonat) ausgeführt, die Sprints genannt werden. Am Ende jedesSprints muss das Team eine arbeitsfähige Software erzeugen, die qualitativ solchen Ansprüchen genügt, dass sie potentiell veröffentlicht oder den Kunden zugänglich gemacht werdenkönnte.

Tabelle 11.1.2: In agilen Ansätzen genutzte Techniken


441

Technik Kurzbeschreibung

BehaviourDriven Development(BDD)

Ein Ansatz zur Verbesserung der Kommunikation zwischenStakeholdern und Teammitgliedern, indem der Produktbedarfanhand konkreter Beispiele erläutert wird

Kano-Analyse Eine Technik zum Verständnis, von welchen Produkt-Features dieZufriedenheit der Kunden abhängt.

Schlanke Dokumentation

Dieses Prinzip betrifft jede Art von Dokumentation in einemagilen Projekt. Damit soll sichergestellt werden, dass jede Formder Dokumentation einen bestehenden Bedarf abdeckt, eineneindeutigen Nutzen für Stakeholder liefert und keinen unnötigenMehraufwand erzeugt. So kann beispielsweise eine Beschrei-bung der Systemzusammenhänge erst gegen Ende des Projektserstellt werden, nachdem stabile Inhalte und erfolgreiche Akzep-tanztests als Teil des Produkttests vorliegen.

MoSCoW-Priorisierung

Eine Methode zur Priorisierung von Stories (oder anderer Ele-mente) in inkrementellen und iterativen Ansätzen. MoSCoW(must have, should have, could have, won’t have) bietet einenWeg, um ein gemeinsames Verständnis der relativen Wichtigkeitder Lieferung einer Story oder einer anderen Wertkategorie ineinem Produkt zu erzeugen.

Personas Fiktive Charaktere/Archetypen, die verdeutlichen, wie typischeBenutzer mit einem Produkt umgehen.

Planungs-Workshop

Ein gemeinsamer Workshop, in dem das agile Team den Nutzenbestimmt, den es in einer bestimmten Zeitspanne, z.B. einRelease, liefern kann.

PurposeAlignmentModel

Ein Modell, das dazu dient, Ideen im Kontext von Kunden undWertschöpfung zu beurteilen.

Realoptionen Ein Ansatz, der dazu dient, den bestmöglichen Zeitpunkt fürEntscheidungen zu finden (und weniger, wie die Entscheidunggetroffen wird).

Relative Schätzung

Ist eine Team-Schätztechnik, bei der Story-Punkte genutzt wer-den, die von der relativen Komplexität einer zu entwickelndenUser Story abhängen, oder Idealtage unterstellen – das ist derGesamtaufwand, der für die Entwicklung einer Story entsteht.

Tabelle 11.1.2: In agilen Ansätzen genutzte Techniken (Fortsetzung)

Basiskompetenzen

Agil ist ein spezieller Denkansatz, eine eigene „Philosophie“. Der agil arbeitendeBusiness-Analyst verkörpert die Werte und Prinzipien des „Agile Manifesto“,das auf einer humanistischen Grundhaltung, auf Kommunikation und auf Zusam-menarbeit im Prozess der Produktentwicklung setzt. Weitere Informationen zuden agilen Prinzipien für den Business-Analysten finden sich in der Ergänzungs-broschüre „Agile Extension to the BABOK® Guide“. Mit der Übernahme deragilen Philosophie entwickelt der Business-Analyst folgende Kompetenzen:

• Kommunikation und Zusammenarbeit: Die Fähigkeit, die Vision und den Bedarf des Auftraggebers an Dritte zu vermitteln, und zu helfen, dass andere Personen gewonnen werden, um die Vision zu unterstüt-zen, an der Verhandlung über die Setzung von Prioritäten teilzuneh-men und sie zu moderieren, und so dazu beizutragen, dass die gefun-denen Ergebnisse gemeinsam getragen werden.

• Geduld und Toleranz: Die Fähigkeit, auch unter Druck in der Inter-aktion mit anderen die Selbstbeherrschung zu bewahren und offen fürArgumente zu sein.

• Flexibilität und Anpassungsfähigkeit: Fachgebietsüberschreitende Fähig-keiten erlauben es dem Business-Analysten, über die Grenzen seines Spe-zialgebiets hinauszusehen und andere Teammitglieder zu unterstützen.


442

11.1.4


Retrospektiven Das ist ein ähnlicher Begriff wie die Technik der Lessons Learned.Retrospektiven setzen ihren Schwerpunkt auf die kontinuierlicheVerbesserung der Arbeitsprozesse im Team und finden in agilenProjekten nach jeder Iteration statt.

Story Decomposition

Sie stellt sicher, dass die Anforderungen für ein Produkt in einemangemessenen Detailgrad dargestellt und aus einem Unterneh-mensziel abgeleitet werden.

Story Mapping Es liefert eine grafische und physische Sicht der Folge von Aktivitäten, die eine Lösung unterstützen soll.

Storyboarding Es zeigt grafisch und mit Text den detaillierten Ablauf der Aktivitäten der Benutzer beim Einsatz eines Systems innerhalbeines Unternehmens.

Wertstrom-analyse

Sie liefert eine vollständige, faktenbasierte Darstellung der Aktivitäten, die im Zeitablauf erforderlich sind, um ein Produktoder eine Dienstleistung für den Kunden erbringen zu können.

• Fähigkeit, mit Veränderungen umzugehen: Die Fähigkeit, schnell die Auswirkungen eines Change zu überblicken, und zu ermitteln, was beisich oft ändernden Anforderungen betrieblichen Nutzen bringt und bei der Neu-Priorisierung der To-Do-Liste oder bei der Pflege dieser Liste mitzuhelfen.

• Fähigkeit, Wertschöpfung für das Unternehmen zu erkennen: Die Fähigkeit, zu erkennen, wie Änderungen und neue Features betrieb-lichen Nutzen schaffen und die Vision unterstützen.

• Kontinuierliche Verbesserung: Regelmäßige Reviews mit dem agilen Team, um so die eigene Effektivität zu steigern.

Auswirkungen auf die Wissensgebiete

Dieser Abschnitt erklärt, in welcher Beziehung bestimmte Praktiken der Busi-ness-Analyse bei einem agilen Vorgehen zu den im BABOK®-Leitfaden definiertenAufgaben einer Business-Analyse stehen. Er beschreibt auch, wie jedes Wis-sensgebiet in agilen Vorgehen genutzt oder angepasst wird.

Bei jedem Wissensgebiet werden auch die Techniken aus dem BABOK®-Leitfadenaufgelistet, die für die agile Perspektive relevant sind. Die Techniken der „AgileExtension“ werden in der Erweiterungsbroschüre „Agile Extension to the BABOK®

Guide“ detailliert diskutiert. Diese Liste ist nicht als vollständiger Überblick überalle Techniken gedacht, vielmehr werden die vom Business-Analysten üblicherweisegenutzten Techniken aufgelistet, die in den zu erledigenden Aufgaben genutztwerden können.

.1 Planung und Überwachung der Business-Analyse In agilen Ansätzen wird die detaillierte Planung der Business-Analyse so langezurückgestellt, bis die Aktivität eines Arbeitspakets unmittelbar bevorsteht. Diessteht im Gegensatz zu klassischen Projekten, wo zum größten Teil bereits beiProjektbeginn geplant wird.

Zu Beginn eines Projekts wird ein erster grober Plan der Aktivitäten der Busi-ness-Analyse entwickelt. Dieser Plan wird dann zu Beginn jedes Zyklus aktualisiert,um Veränderungen zu berücksichtigen und die Aktualität des Plans sicherzustellen.Die Beteiligung der Stakeholder und deren Engagement sind der Schlüssel zuerfolgreichen agilen Projekten. Der Business-Analyst plant proaktiv, wie er Stake-holder einbezieht, sie aktiviert und mit ihnen zusammenarbeitet.

In agilen Projekten wird normalerweise eher informell kommuniziert, die Ergeb-nisse der Business-Analyse entstehen oft im Austausch und bei der Zusammen-arbeit. Es wird weniger Wert auf schriftliche Dokumentation gelegt.


443

11.1.5

Techniken des BABOK®-Leitfadens

• Backlog-Management (Kap.10.2) • Schätzung (Kap.10.19)• Gemeinschaftliche Spiele (Kap.10.10) • Scope-Modellierung (Kap.10.41)• Kennzahlen und Key- • Stakeholder-Listen, -Karten oderPerformance-Indikatoren (Kap.10.28) Personas (Kap.10.43)

• Mind Mapping (Kap. 10.29) • User Stories (Kap.10.48)• Priorisierung (Kap.10.33) • Workshops (Kap.10.50)

Techniken aus „Agile Extension to the BABOK® Guide“

• MoSCoW-Priorisierung • Personas• Relative Schätzung • Rückblick• Schlanke Dokumentation

.2 Erhebung und ZusammenarbeitEine stufenweise Erhebung und Bearbeitung findet bei einem agilen Vorhabenimmer wieder statt. Am weitesten verbreitet ist eine Erhebung zu Beginn, diedazu dient, die Vision und den Scope auf einem relativ hohen Abstraktionsniveaufestzulegen, und Meilensteine für die Fertigstellung des Produktes zu planen. Injedem Zyklus werden dann Informationen für die Sachverhalte, die in diesemZyklus entwickelt werden sollen, detaillierter erhoben. Dazu werden gerade soviele Details ermittelt, dass die vorliegenden Arbeiten korrekt und zielorientiertausgeführt werden können. Agile Ansätze versuchen, die Zeit zwischen derErarbeitung des Bedarfs und der Umsetzung der Lösung zu minimieren. Aufgemeinsame Ansätze zur Erhebung, wie z.B. Workshops mit Stakeholdern, wirdbesonderer Wert gelegt.


• Akzeptanz- und • Analyse nicht-funktionaler Bewertungskriterien (Kap.10.1) Anforderungen (Kap.10.30)

• Backlog- Management (Kap.10.2) • Brainstorming (Kap.10.5)• Begriffsmodellierung (Kap.10.11) • Gemeinschaftliche Spiele

(Kap.10.10)• Mind Mapping (Kap.10.29) • Prozessmodellierung (Kap.10.35)• Prototyping (Kap.10.36) • Reviews (Kap.10.37)• Schnittstellenanalyse (Kap.10.24) • Scope-Modellierung (Kap.10.41)• Stakeholder-Listen, -Karten • Use Cases und Szenarienoder Personas (Kap.10.43) (Kap.10.47)

• User Stories (Kap.10.48) • Workshops (Kap.10.50)


444


• Behaviour Driven Development • Schlanke Dokumentation• Personas • Storyboarding• Story Mapping

.3 Management des Anforderungs-LebenszyklusDer Scope wird bei einem agilen Vorgehen zunehmend präziser festgelegt. Eswird davon ausgegangen, dass sich der Bedarf wandelt und das Design im Pro-jektverlauf verändert wird. Die Priorisierung der Features erfolgt auf Basis desNutzens und der Entwicklungsprioritäten, die für die Arbeiten in jedem Zyklusmaßgeblich sind. Die Validierung der sich wandelnden Lösung geschieht gemein-sam mit den Stakeholdern am Ende jeder Iteration, statt einen formellen Anfor-derungs-Abnahmeprozess zu durchlaufen.


• Akzeptanz- und • Backlog Management (Kap.10.2)Bewertungskriterien (Kap.10.1)

• Gemeinschaftliche Spiele • Priorisierung (Kap.10.33)(Kap.10.10)

• Reviews (Kap.10.37) • Workshops (Kap.10.50)


• Kano-Analyse • MoSCoW-Priorisierung• Story Decomposition • Story Mapping

.4 Strategische AnalyseAgile Ansätze werden oft eingesetzt, wenn der Bedarf, die Lösung oder derScope des Change unklar ist. Die Strategieanalyse ist fester Bestandteil einesagilen Vorhabens. Sie soll sicherstellen, dass die gelieferte Lösung den Stakehol-dern dauerhaft Nutzen bringt. Mitglieder agiler Teams setzen die Strategieanalyseein, um die Produktvision zu verstehen und zu definieren und um die Roadmapder Entwicklung zu erarbeiten und anzupassen. Außerdem werden kontinuierlichdie zugehörigen Risiken überwacht. In jeder Iteration wird die vorgeschlageneLösung wieder dahingehend überprüft, ob sie im aktuellen Kontext die Zieledes Unternehmens effektiv erfüllt. Der adaptive Charakter agiler Projekte führtdazu, dass Veränderungen im Projekt, die sich aus geänderten Unternehmens-zielen ergeben, das Projekt nicht massiv stören, diese Veränderungen sindvielmehr zu erwartende Bestandteile des Prozesses.


445


• Backlog Management (Kap.10.2) • Brainstorming (Kap.10.5)• Betriebliche Fähigkeitsanalyse • Gemeinschaftliche Spiele(Kap.10.6) (Kap.10.10)

• Begriffsmodellierung (Kap.10.11) • Kennzahlen und Key-Performance- Indikatoren (Kap.10.28)

• Scope-Modellierung (Kap.10.41) • Workshops (Kap.10.50)


• Kano-Analyse • Personas• Purpose Alignment Model • Real Options (Realoptionen)• Wertstromanalyse

.5 Anforderungsanalyse und Design-DefinitionDer Bedarf wird in agilen Projekten Schritt für Schritt erarbeitet. Analyse undDesign werden zeitgerecht auf Just-in-time-Basis durchgeführt, entweder kurz voroder während einer Iteration, in der die Lösungskomponente entwickelt wird.

Die kurz vor einer Iteration durchgeführte Analyse liefert dem Team die not-wendigen Informationen, um die geplanten Arbeiten einzuschätzen. Die währendeiner Iteration durchgeführten Analysen dienen dazu, dem Team die Informationenzu liefen, die notwendig sind, um die geplanten Arbeiten zu liefern bzw. dieErgebnisse zu erstellen.

Modelle und andere Analyse- und Design-Techniken werden üblicherweise infor-mell eingesetzt und werden meistens nach ihrem Gebrauch auch nicht gewartet.Der gewählte Analyse- und Design-Ansatz sollte eine schrittweise Ausarbeitungerlauben, auf neuen Erkenntnissen basierende Veränderungen zulassen undnicht dazu führen, dass das Team sich zu früh auf eine bestimmte Lösungfestlegt. Agile Teams nutzen User Stories im größten Detaillierungsgrad, die nor-malerweise mit Akzeptanzkriterien versehen sind, welche die Details der Analyseund des Designs beinhalten und aus denen hervorgeht, wie sich die Storiesnach der Einführung verhalten sollten. Die entstehende Lösung wird gemeinsammit den Stakeholdern am Ende jeder Iteration validiert.



• Analyse der Geschäftsregeln • Begriffsmodellierung (Kap.10.11)(Kap.10.9)

• Betriebliche Fähigkeitsanalyse • Gemeinschaftliche Spiele (Kap.10.6) (Kap.10.10)


446

• Priorisierung (Kap.10.33) • Prozessanalyse (Kap.10.34)• Prozessmodellierung (Kap.10.35) • Schnittstellenanalyse (Kap.10.24)• Scope-Modellierung (Kap.10.41) • Use Cases und Szenarien

(Kap.10.47)• User Stories (Kap.10.48) • Workshops (Kap.10.50)


• Behaviour Driven Development • Kano-Analyse• Schlanke Dokumentation • MoSCoW-Priorisierung• Purpose Alignment Model • Real Options • Story Decomposition • Story Elaboration• Story Mapping • Storyboarding• Wertstromanalyse

.6 LösungsbewertungWährend des gesamten agilen Projekts beurteilen und evaluieren die Stakeholderund das agile Team kontinuierlich die entstehende Lösung, die schrittweise auf-und ausgebaut wird.

Die Evaluierung der wachsenden Lösung findet zusammen mit den Stakeholdernam Ende eines Entwicklungszyklus statt. So wird sichergestellt, dass die Ergeb-nisse/Lieferobjekte den Bedarf decken und die Erwartungen erfüllt werden. DerBusiness-Analyst stellt vor der Freigabe eines Produktes sicher, dass es die Erwar-tungen erfüllt und identifiziert neue Chancen, die Wertschöpfung des Unter-nehmens zu steigern.


• Akzeptanz- und • Kennzahlen und Key-Bewertungskriterien (Kap.10.1) Performance-Indikatoren (Kap.10.28)

• Analyse nicht-funktionaler • Betriebliche FähigkeitsanalyseAnforderungen (Kap.10.30) (Kap.10.6)

• Prototyping (Kap.10.36) • Prozessanalyse (Kap.10.34)• Reviews (Kap.10.37) • Stakeholder-Listen, -Karten

oder Personas (Kap.10.43)• Use Cases und Szenarien • User Stories (Kap.10.48)(Kap.10.47)

• Workshops (Kap.10.50)


• Personas • Wertstromanalyse


447

11.2 Die Business-Intelligence-PerspektiveDie Business-Intelligence-Perspektive betont die Besonderheiten der Business-Analyse bei der Transformation, Integration und Verbesserung der Datenqua-lität.

Der Schwerpunkt der Business Intelligence (BI) ist die Transformation von Datenzu wertschöpfenden Informationen. Es geht darum, wo Daten zu beschaffensind, wie sie zu integrieren sind und wie sie aufgewertet werden können, umals analytische Erkenntnisse den Entscheidungsprozess in Unternehmen zu unter-stützen.

Vorhaben der Business Intelligence nutzen datenzentrierte Systemarchitekturen,Technologien und Werkzeuge, um verlässliche, konsistente und qualitativ hoch-wertige Informationen zu liefern, so dass Stakeholder strategische, taktischeund operative Vorhaben besser managen können.


.1 Breite des ChangeEin Kernziel eines Business-Intelligence-Systems ist die konsistente Definitionund Verwendung von Informationen in einem Unternehmen, indem ein soge-nannter „single point of truth“ (SPOT, einzige Quelle der Wahrheit) für diebetrieblichen Daten eingerichtet wird. Eine Lösungsarchitektur, die verschiedeneinterne und möglicherweise auch externe Datenquellen integriert, bildet dasFundament einer Business-Intelligence-Lösung.

Business Intelligence fördert eine unternehmensweite Sichtweise des Informati-onsmanagements. Ein Vorhaben zur Business Intelligence kann auch bedeuten,dass Infrastruktur-Services (wie Daten-Governance und Metadaten-Management)entwickelt werden, um damit ein konzeptionelles Rahmenmodell der BI zu unter-stützen.

PerspektivenDie Business-Intelligence-Perspektive

448

11.2.1

Abb. 11.2.1: Business-Intelligence-Lösung – Bezugsrahmen (Conceptual Framework)

.2 Tiefe des ChangeVorhaben der Business Intelligence fokussieren auf Informationen, die Entschei-dungen auf bestimmten betrieblichen Ebenen oder übergreifend unterstützen:

• Topmanagement: Unterstützung strategischer Entscheidungen.• Mittleres Management: Unterstützung taktischer Entscheidungen.• Ausführungsebene: Unterstützung operativer Entscheidungen.

Wenn ein Informationsbedarf auf einer bestimmten Ebene genannt oder identi-fiziert wird, untersucht der Business-Analyst die betrieblichen Auswirkungen aufdas Unternehmen und auf die anderen Ebenen, um den Gesamteinfluss desChange auf das Unternehmen beurteilen zu können.

Auf jeder Ebene kann der betriebliche Bedarf auf eine oder mehrere der folgendenGründe zurückzuführen sein:

• Kommunikationsanforderungen zur Entwicklung neuer Berichte oder dem Ersatz bestehender Berichte

• Informationsanforderungen für die Ergänzung und Erweiterung analy-tischer Funktionalitäten

Perspektiven Die Business-Intelligence-Perspektive

449

• Partner• Branche• Öffentlichkeit

Daten-integration

Unternehmens-datensicht

Entscheidungs-unterstützung

Entscheidungs-punkte

Daten-quellen

Daten-transformation

Datenqualitäts-management

Daten-analyse

Informations-lieferung

ExterneSysteme

• Zentrale• Geschäftsbereich• Ad-hoc, isoliert

InterneSysteme

• Maschinendaten• Internetdaten• Audiovisuelle Daten• Dokumente & Text

AndereQuellen

DataWarehouse

Unstrukturierte Daten

AnalytischeSandboxes

OperativeDatenspeicher

DataMarts

PeriodischeBerichte

Ad-hoc-Abfragen

InteraktiveDashboards

Von BedingungenabhängigeMeldungen

AutomatisierteEntscheidungs-

daten

• Anforderungen zur Integration von Daten für den Aufbau oder die Ver-änderung der Sichten der Unternehmensdaten im Hinblick auf Daten-quellen, Definitionen, Transformationsregeln und Qualitätsaspekten.

.3 Nutzen und umgesetzte LösungenDer Wert eines Vorhabens der Business Intelligence liegt darin, zeitgerecht genaue,wertvolle und handlungsrelevante Informationen denjenigen Personen und Systemenzu liefern, die diese effektiv für Entscheidungen im Unternehmen nutzen können.

Entscheidungen auf der Grundlage besserer Informationen kann die betrieblichePerformance auf folgenden Gebieten steigern:

• strategische Prozesse wie Marktanalyse, Kundenbindung und Produkt-entwicklung

• taktische Prozesse wie Bestandssteuerung und Finanzplanung• operative Prozesse wie Gläubigerbeurteilung, Fehlererkennung und Überwachung der Verbindlichkeiten.

Diese Verbesserungen der aktuellen oder zukünftigen Leistung eines Unterneh-mens können zu einer Umsatzsteigerung und/oder Kostensenkung führen.

.4 UmsetzungsansatzEine Business-Intelligence-Lösung kann auf verschiedenen Wegen umgesetztwerden, um den entstehenden Informationsbedarf der Stakeholder zu deckenund den Unternehmensprioritäten gerecht zu werden.

Die Erweiterbarkeit und Skalierbarkeit der Lösungsarchitektur ermöglichen dieschrittweise Einführung und eine immer breitere und bessere Unterstützungbetrieblicher Entscheidungen:

• auf verschiedenen Ebenen im Unternehmen – vom strategischen (Topmanagement) über das taktische (mittleres Management) bis zum operativen Management (Personal und Systeme)

• in den vorgesehenen Funktionsbereichen des Unternehmens von einem bestimmten Bereich bis zu einer unternehmensweiten Umsetzung.

Infrastrukturdienste, welche das Datenmanagement, die Analyse und Präsenta-tionsfähigkeiten bereitstellen, vereinfachen eine phasen- oder stufenweise Ent-wicklungsstrategie im Hinblick auf

• den Einbezug, die Koordination und Steuerung verschiedener Daten-quellen

• die Analyse und Entwicklung der betrieblichen Information und Erkenntnisse.

Kommerzielle Standardpakete stellen oft Infrastruktur-Komponenten einer Busi-ness-Intelligence-Lösung bereit, die dann für die individuelle Unternehmensum-gebung und deren Bedarf konfiguriert werden.


450

.5 Zentrale AnnahmenNachfolgend eine Liste wichtiger Annahmen zu einem Vorhaben der BusinessIntelligence:

• Bestehende Geschäftsprozesse und Transaktionssysteme liefern definierbare und vorhersehbare Quelldaten.

• Die zur Unterstützung der Business-Intelligence-Lösung notwendige funktionsübergreifende Daten-Infrastruktur wird nicht aus technischen, finanziellen, politisch/kulturellen oder anderen Gründen verhindert.

• Dem Unternehmen ist bewusst, dass Geschäftsprozess-Reengineering und Change Management notwendig sein können, um mit einer Business-Intelligence-Lösung effektiv Werte schöpfen zu können.


.1 Auftraggeber des ChangeDer Auftraggeber eines Vorhabens der Business Intelligence ist idealerweise aufder höchsten Ebene der Einheit angesiedelt, die von dem Change betroffen ist.So kann ein konsistentes, zusammenhängendes Vorgehen für die gemeinsameVerwendung der Datenbestände innerhalb der funktionsübergreifenden Archi-tektur einer Business-Intelligence-Lösung sichergestellt werden.

.2 Ziele des ChangeDie Ziele eines Vorhabens der Business Intelligence leiten sich aus betrieblichenEntscheidungen ab, die auf verschiedenen Ebenen von solchen Personen oderSystemen getroffen wurden, die von besseren Berichten, besserem Monitoringoder Prognosemodellen für leistungsorientierte Daten profitieren.

.3 Die Rolle des Business-AnalystenWie bei anderen Vorhaben ist der Business-Analyst die zentrale Verbindung zwi-schen den Stakeholdern der Business Intelligence und den Lösungslieferantenbei der Erhebung, Analyse und Spezifikation des Unternehmensbedarfs.

Zusätzlich zu dieser Rolle kann der Business-Analyst auch an technischen, spezi-fischen Aktivitäten der Business Intelligence teilnehmen, wie beispielsweise

• Modellierung von Unternehmensdaten• Entscheidungsmodellierung• spezialisierte Präsentations-Designs (z.B. Dashboards)• Design von Ad hoc-Abfragen.

Ein Business-Analyst, der in einem Vorhaben der Business Intelligence mitarbeitet,übernimmt eine oder mehrere der folgenden Rollen:


451

11.2.2

• als Business-Analyst, der mit der Definition betrieblicher Anforderun-gen und der Bewertung von möglichen Lösungen vertraut ist

• als Analytiker im Bereich der Business Intelligence, der Data-Mining- und Prognose-Techniken anwenden und Visualisierungen entwickeln kann

• als Datenanalyst, der in der Definition von Quellsystemdaten erfahren ist, die für Analysen benötigt werden

• als Datenmodellierer/-architekt, der mit der Definition von Quell- und Zieldatenstrukturen in logischen Datenmodellen vertraut ist.

.4 Ergebnisse der Business-Analyse Innerhalb der Business Intelligence fokussiert die Business-Analyse auf die Haupt-bestandteile der Lösungsarchitektur. Dazu gehören

• die Spezifikation von betrieblichen Entscheidungen, die beeinflusst oder geändert werden sollen

• die Sammlung von Daten aus Quellsystemen• die Integration nicht-kompatibler Quellen zu einem einheitlichen betrieblichen Rahmenmodell

• die Bereitstellung gezielter Informationen und analytischer Erkenntnisse für Stakeholder des Unternehmens.

Der Business-Analyst ist verantwortlich für die Analyse und Spezifikation derbetrieblichen Anforderungen für alle diese Komponenten und arbeitet bei derBeurteilung von Lösungsartefakten mit technischen Experten zusammen.

Die zentralen Ergebnisse der Business-Analyse sind:• Abdeckung der Geschäftsprozesse: Sie definiert den Umfang des Change mit einer sehr allgemeinen Darstellung der betrieblichen Entscheidungen, die durch die Lösung unterstützt werden sollen. Sie zeigt, wie der Informations-Output verwendet und welchen Wert dieser schaffen wird.

• Entscheidungsmodelle: Sie identifizieren die Informationsanforderun-gen jeder zu unterstützenden betrieblichen Entscheidung und spezifi-zieren die Logik der Geschäftsregeln, wie individuelle Informations-komponenten zu den Entscheidungsergebnissen beitragen.

• Logisches Quelldatenmodell und Data Dictionary: Das logische Quell-datenmodell liefert eine Standarddefinition der benötigten Daten, wie diese im Quellsystem gespeichert sind. Das Quelldaten-Data-Dictionaryliefert eine Definition jedes Elements und der Geschäftsregeln, die dabei angewendet werden: Beschreibung, Typ, Format und Länge, gesetzliche Werte und jegliche interne Abhängigkeiten.


452

• Qualitätsbeurteilung von Quelldaten: Sie evaluiert Vollständigkeit, Gültigkeit und Zuverlässigkeit der Daten aus den Quellsystemen. Sie identifiziert, wo weitere Verifikationen und Verbesserungen der Quell-daten notwendig sind, um konsistente betriebliche Definitionen zu garantieren, und um sicherzustellen, dass Regeln für die Daten-bestände unternehmensweit gelten

• Logisches Zieldatenmodell und Data Dictionary: Das logische Zieldaten-modell ist eine integrierte, normalisierte Sicht auf die notwendigen Datenstrukturen zur Unterstützung der betrieblichen Bereiche. Das Zieldaten-Dictionary liefert standardisierte, unternehmensweite Defini-tionen der Datenelemente und Integritätsregeln.

• Transformationsregeln: Ordnet Quell- und Zieldatenelemente zu, um Anforderungen hinsichtlich der Dekodierung/Kodierung von Werten und Datenkorrekturen (bei fehlerhaften Werten) und Ergänzungen (beifehlenden Werten) im Transformationsprozess zu spezifizieren.

• Anforderungen der betrieblichen Analysen: Sie definieren die Informa-tions- und Kommunikationsanforderungen für Ergebnisse zur Unter-stützung von Entscheidungen. Dazu gehören • vordefinierte Berichte• Dashboards• Balanced Scorecards• Ad hoc-Berichte• Online-Analytical-Processing (OLAP)-Abfragen• Data Mining• Prescriptive Analytics• von Bedingungen abhängige Meldungen• Verarbeitung komplexer Ereignisketten• Vorhersagemodelle.

• Zu den Spezifikationen für jeden Output können gehören: (1) Datenauswahl/-dimensionen, Detailierungsgrad, eingesetzte Filter-kriterien, Möglichkeiten für Drill down, Slice and Dice, und Benutzer-zugang und -rechte(2) Präsentationsregeln, die das Format von Datenelementen, Überset-zungen/Referenzen (labels, look-ups), Berechnungen und Aggregatio-nen von Daten definieren.

• Lösungsarchitektur: Sie liefert eine sehr abstrakte Sicht darauf, wie die Anforderungen zur Unterstützung von Entscheidungen jedes Funktions-bereichs vom Bezugsrahmen der Business Intelligence abgedeckt werden. Dies wird normalerweise in Form eines Prozess- oder Daten-flussmodels dargestellt, das festlegt,


453

• wo die Quelldaten herkommen• wie (pull/push) und wann (Häufigkeit, Latenz) die Daten extrahiert werden

• wo die Transformation stattfinden wird (Bereinigung, Kodierung, Anreicherung)

• wo die Daten physisch gespeichert werden (Data Warehouse, Data Marts)

• wie die Daten in den Präsentations-Output einfließen werden (Berichts- und Abfragewerkzeuge).

Methoden und Ansätze

.1 MethodenEs gibt keine formellen Methoden der Business Intelligence, die einen direktenEinfluss auf die Verantwortlichkeiten und Tätigkeiten des Business-Analystenhaben. Ein Vorhaben der Business Intelligence kann aber Methoden einsetzen,die auch auf anderen Gebieten oder Perspektiven angewendet werden, die wie-derum einen Einfluss auf die Rolle der Business-Analyse haben können.

.2 AnsätzeInnerhalb des Rahmenmodells der Business Intelligence gibt es einige wenigerformale und potentiell überlappende Ansätze, die sich auf bestimmte Unter-nehmens- und technische Kontexte beziehen.

Analysearten

Es gibt drei Arten von Datenanalysen, die schrittweise mit zunehmender System-komplexität, höheren Kosten und verbessertem Nutzen verbunden sein können:

• Deskriptive Analyse: Sie nutzt historische Daten, um die zurückliegendePerformance des Unternehmens zu verstehen und zu analysieren. Geschäftsinformationen können kategorisiert und konsolidiert werden,um so die Stakeholder-Sicht am besten abzudecken. Darunter fallen Dashboards für das Topmanagement, Key Performance Indicators (KPI), Scorecards für das mittlere Management und Charts für das operative Management. Es werden keine Annahmen darüber getrof-fen, welche Situationen die Stakeholder interessieren könnten, welche Entscheidungen getroffen werden müssen oder welche Handlungen ausgeführt werden könnten. Die Business-Analyse fokussiert auf die Informations- und Kommunikationsanforderungen für das Standard-berichtswesen und die Dashboards, Ad hoc-Berichte und Abfragemög-lichkeiten.


454

11.2.3

• Prognose: Sie nutzt statistische Methoden, um Muster in den histori-schen Daten zu erkennen und dann diese Erkenntnisse hinsichtlich Beziehungen und Trends für Voraussagen zukünftiger Ereignisse einzu-setzen. Die einzelnen, für die Stakeholder interessanten Situationen werden spezifiziert und deren Geschäftsregeln definiert. Die Business-Analyse fokussiert auf die Informationsanforderungen, um mittels Data Mining Muster erkennen zu können und Predictive Modelling, Prognosen und von Bedingungen abhängige Meldungen einzusetzen.

• Programmierte Entscheidungen (prescriptive analytics): Sie erweitern die Prognosen, um zu fällende Entscheidungen zu erkennen und geeignete Handlungen zur Steigerung der Unternehmensleistung einzuleiten. Statistische Optimierungs- und Simulationstechniken können dazu verwendet werden, die beste Lösung oder das beste Ergebnis unter verschiedenen möglichen Optionen zu bestimmen. Für Situationen, die für Stakeholder interessant sind, werden vollständige Spezifikationen der zugehörigen Entscheidungen und möglicher Hand-lungen benötigt. Die Business-Analyse fokussiert auf die betriebliche Ziele, Restriktionen und die Geschäftsregeln, die den Entscheidungs-prozess steuern.

Angebots- und nachfragegetrieben

Die Ziele und Prioritäten eines Vorhabens der Business Intelligence können aufden technischen Zielen eines bestehenden Informationsbeschaffungssystems(angebotsgetrieben) aufsetzen oder auf den betrieblichen Zielen, geeigneteInformationen zur Verbesserung des Entscheidungsprozesses zu liefern (nach-fragegetrieben):

• Angebotsgetrieben: Hier steht die Frage im Vordergrund:„Welcher Wert kann zu bestimmten Kosten erzeugt werden?“ Dieser Ansatz untersucht bestehende Systemdaten, um herauszufinden, welche Daten vorhanden sind. Eine häufige Umsetzungsstrategie ist:1. Einbeziehung bestehender Datenbanken in die Business-

Intelligence-Lösungsarchitektur.2. schrittweiser Ersatz oder schrittweise Reparatur bestehender

Outputs 3. Ermittlung neuer Erkenntnisse aus den konsolidierten Daten.

• Nachfragegetrieben: Hier steht die Frage im Vordergrund:„Welche Kosten müssen aufgewendet werden, um einen bestimmten Nutzen zu erreichen?" Dieser Ansatz beginnt mit der Identifikation der Infor-mationen, die für betriebliche Entscheidungen benötigt werden, und ermittelt die notwendigen Datenquellen, um Machbarkeit und Kosten herauszufinden. Der Ansatz sieht inkrementelle Umsetzungsstrategien vor, die nicht durch bestehende Datenbankstrukturen im Voraus fest-


455

gelegt sind, und erlaubt es, die Business Intelligence aktiv für die früh-zeitige Untersuchung zu nutzen, welche Berichte über die bestehen-den hinaus nützlich sein könnten.

Strukturierte und unstrukturierte Daten

Zwei Datentypen sind beim Vorgehen der Business Intelligence zu berücksich-tigen:

• Strukturierte Daten: Traditionelle Data-Warehouse-Lösungen setzten darauf, die strukturierten Daten (numerisch und kategorisch) der operativen Systeme zu konsolidieren, wo die Sets betrieblicher Infor-mationen anhand vordefinierter Strukturen (bekannt als „schema on write“) identifiziert werden, und eine Vorlage, die auf Regeln basiert, die Datenintegrität sichert. Der Fokus der Business-Analyse liegt auf Datenmodellen, Data Dictionaries und Geschäftsregeln, um die Infor-mationsanforderungen und -fähigkeiten zu definieren.

• Unstrukturierte Daten: Lösungen der Business Intelligence können auch halb- oder unstrukturierte Daten beinhalten. Dazu gehören auch Text-, Bild-, Audio- und Video-Dateien. Diese Daten werden oft von externen Quellen angeliefert. Für diese Datenarten sind die Struktur und die Beziehungen nicht vordefiniert und es werden keine speziellenRegeln für die Sicherung der Datenintegrität angewendet. Sets an Informationen werden aus Rohdaten abgeleitet (bekannt als „schema on read“). Die Business-Analyse fokussiert sich auf die Definitionen von Metadaten und auf die Algorithmen zum Datenabgleich, um Informationsanforderungen und -fähigkeiten zu definieren.

Basiskompetenzen

Wie bei jeder Business-Analyse benötigt der Business-Analyst grundlegendeFähigkeiten der Kommunikation und der Analyse, um effektiv sowohl mit denbetrieblichen Stakeholdern als auch mit den Anbietern technischer Lösungenumzugehen.

Die Koordination der betrieblichen Informationsanforderungen kann mit denErgebnissen der Systeme der Business Intelligence weiter verbessert werden,wenn der Business-Analyst auf folgenden Gebieten kompetent ist:

• Unternehmensdaten und deren funktionale Verwendung, inklusive derTerminologie und Regeln

• Analyse komplexer Datenstrukturen und deren Übersetzung in ein standardisiertes Format

• Geschäftsprozesse mit Einfluss auf KPIs und Kennzahlen• Entscheidungsmodellierung


456

11.2.4

• Techniken der Datenanalyse inklusive Statistik, Datenprofilanalyse und Pivot-Tabellen

• Data Warehouse und Konzepte und Architektur der Business Intelligence

• logische und physische Datenmodelle• ETL (Extract, Transform, Load) Best Practices inklusive dem Manage-ment historischer Daten und Referenzdaten

• Berichtswerkzeuge der Business Intelligence.


Dieser Abschnitt erklärt, in welcher Beziehung spezifische Praktiken der Busi-ness-Analyse innerhalb der Business Intelligence mit den Aufgaben der Busi-ness-Analyse und den Praktiken stehen, die im BABOK®-Leitfaden definiert wur-den. Dieser Abschnitt beschreibt, wie jedes Wissensgebiet in der Business Intel-ligence angewendet oder verändert wird.

Jedes Wissensgebiet listet die für die Business Intelligence relevanten Technikenauf. Die in der Business Intelligence genutzten Techniken weichen nicht starkvon den im BABOK®-Leitfaden beschriebenen Techniken ab. Die Techniken desBABOK®-Leitfadens finden sich im Kapitel 10. Diese Liste ist nicht als allumfassendeListe aller Techniken gedacht, sondern soll vielmehr die Technikarten hervorheben,die von dem Business-Analysten bei der Bewältigung der Aufgaben des jeweiligenWissensgebiets angewandt werden können.

.1 Planung und Überwachung der Business-Analyse Ein Vorhaben der Business Intelligence kann es notwendig machen, eine Basis-Dateninfrastruktur aufzubauen, um eine Lösung zu unterstützen, oder es kanneine Erweiterung der Infrastruktur einer bestehenden Lösung erforderlich sein.Scope-Modellierung wird häufig dazu verwendet, diese Alternativen zu unter-suchen und die relevanten Tätigkeiten der Business-Analyse entsprechend zuplanen.

Das Paradigma der Informationsversorgung mithilfe der Business Intelligencekann ein neuer und wenig vertrauter Ansatz für die Stakeholder des Unterneh-mens als auch für den Business-Analysten selbst sein. Bei der Planung eines sol-chen Vorhabens berücksichtigt der Business-Analyst:

• Wie erfahren sind die Stakeholder bei der Äußerung ihrer Informations- und Kommunikationsanforderungen im Kontext der Business Intelli-gence?

• Wie geübt ist der Business-Analyst in der Interpretation dieser Anfor-derungen und Überführung in detaillierte Spezifikationen für die tech-nischen Spezialisten der Business Intelligence?


457

11.2.5

Lösungen der Business Intelligence stellen normalerweise Rahmenmodelle, Werk-zeuge und Techniken bereit, welche die Anforderungsdefinition und die Lösungs-modellierung unterstützen. Die Kompetenz der Stakeholder und des Business-Analysten bei der Anwendung dieser Werkzeuge kann sich auf den Planungs-ansatz auswirken.

Bei der Beurteilung der Einstellung der Stakeholder zum Vorhaben der BusinessIntelligence sollte der Business-Analyst sich der Tatsache bewusst sein, dass eineunternehmensweite Business-Intelligence-Lösung für einige operative Stakeholdernicht unmittelbar Nutzen bringen wird. Sie wird jedoch Nutzen an anderer Stelleim Unternehmen schaffen. Die Flexibilität und Ausbaubarkeit der Infrastrukturder Business Intelligence schafft einen langfristigen strategischen Wert, der weitüber kurzfristige operative Erträge hinausgeht.

Eine Lösung der Business Intelligence, in der mehrere Datenquellen integriertwerden, ist für viele Stakeholder mit überlappenden Informationsanforderungenvon Bedeutung. Der Business-Analyst bereitet die Analyse und Synthese der ein-zelnen Anforderungen in ein Set an Anforderungen vor, das vollständig, zusam-menhängend, konflikt- und überschneidungsfrei ist.


• Akzeptanz- und • Analyse nicht-funktionalerBewertungskriterien (Kap.10.1) Anforderungen (Kap.10.30)

• Balanced Scorecard (Kap.10.3) • Brainstorming (Kap.10.15)• Entscheidungsanalyse (Kap.10.16) • Funktionale Gliederung (Kap.10.22)• Interviews (Kap.10.25) • Item Tracking (Kap.10.26)• Kennzahlen und Key • Organisationsmodellierung (Kap.10.32)Performance-Indikatoren (Kap.10.28)

• Priorisierung (Kap.10.33) • Prozessmodellierung (Kap.10.35)• Reviews (Kap.10.37) • Risikoanalyse und

-management (Kap.10.38)• Rollen und Zuständigkeits- • Schätzung (Kap.10.19)matrix (Kap.10.39)

• Ursachenanalyse (Kap.10.40) • Scope-Modellierung (Kap.10.41)• Stakeholder-Listen, -Karten • Umfrage oder Fragebogen (Kap.10.45)oder Personas (Kap.10.43)

• Use Cases und Szenarien (Kap.10.47) • User Stories (Kap.10.48)• Workshops (Kap.10.50)

.2 Erhebung und Zusammenarbeit Da die Business Intelligence ihrem Wesen nach übergreifend tätig wird, mussder Business-Analyst normalerweise spezialisierte Dokumentationswerkzeuge


458

und -techniken einsetzen, um die betrieblichen und technischen Anforderungenbei den Stakeholdern erheben zu können. Einzelne Stakeholder haben häufignur ein begrenztes Wissen und eingeschränkte Kompetenzen, etwa hinsichtlich

• der zu unterstützenden betrieblichen Entscheidungen• der Datenelemente, die diese Entscheidungen unterstützen• der Datenquellen, der Transformation und der Integrationsregel• der Präsentation der benötigten Informationen.

Interviews mit einzelnen Stakeholdern identifizieren die Informationen. Analyti-scher Spürsinn ist gefragt, um deren Entscheidungsprozesse zu unterstützen.Workshops mit Stakeholdern aus unterschiedlichen Funktionsbereichen desUnternehmens können gemeinsame, überlappende Informationsanforderungenaufdecken, die besser durch eine integrierte Lösung abgedeckt werden.

Datenmodelle und Data Dictionaries liefern Definitionen der Strukturen undGeschäftsregeln der bestehenden Systemdaten. Der Business-Analyst beurteiltdie vorhandene Dokumentation, um Unvollständigkeiten in einem Modell oderInkonsistenzen zwischen Modellen aufzudecken.

Um Daten-Artefakte erweiterte Prozessmodelle können dazu beitragen, die anEntscheidungspunkten notwendigen Datenquellen zu identifizieren. Entschei-dungsmodelle legen Datenanalyse-Anforderungen und Geschäftsregeln für Ent-scheidungen fest.

Kommerzielle Standardpakete mit Business-Intelligence-Funktionalitäten könnendem Business-Analysten ein Set an sehr effektiven Prototyping-Werkzeugen zurErhebung und Klärung der Stakeholder-Informations- und Kommunikationsan-forderungen bereitstellen.


• Beobachtung (Kap.10.31) • Brainstorming (Kap.10.5)• Dokumentenanalyse (Kap.10.18) • Fokusgruppen (Kap.10.21)• Funktionale Gliederung (Kap.10.22) •Glossar (Kap.10.23)• Interviews (Kap.10.25) • Item Tracking (Kap.10.26)• Prototyping (Kap.10.36) • Schnittstellenanalyse (Kap.10.24)• Stakeholder-Listen, -Karten •Workshops (Kap.10.50)oder Personas (Kap.10.43)

• Umfrage oder Fragebogen (Kap.10.45)

.3 Management des Anforderungs-LebenszyklusDer Architektur-Aspekt der Business Intelligence erfordert den Aufbau von Infra-struktur-Fähigkeiten in der Lösung. Dies kann zu strukturellen Abhängigkeiteninnerhalb der Lösung führen, besonders dort, wo die Lieferung zeitlich gestaffelt


459

ist, so dass die Priorisierung des einzelnen Bedarfs betroffen ist. Oftmals könnendurch die gleichzeitige Umsetzung verwandter Anforderungen Einsparungspo-tentiale genutzt werden.


• Item Tracking (Kap.10.26) •Organisationsmodellierung (Kap.10.32)• Priorisierung (Kap.10.33) • Reviews (Kap.10.37)• Rollen- und Zuständig- • Stakeholder-Listen, -Karten keitsmatrix (Kap.10.39) oder Personas (Kap.10.43)


.4 Strategische Analyse Der Business-Analyst kann abstrakte konzeptionelle Datenmodelle nutzen, umden Ist-Zustand der Unternehmensinformation abzubilden, Informations-Siloszu identifizieren und damit verbundene Probleme und Chancen zu beurteilen.Organisationsmodellierung kann zur Evaluierung der bestehenden Infrastrukturdes Datenmanagements dienen, wie z.B. Metadaten-Management und Daten-Governance.

Bei der Definition der zukünftigen Strategie kann der Business-Analyst sehr ab-strakte Modelle nutzen, um die Architektur für die Datenspeicherung, -über-führung und -transformation abzubilden:

• Logische Datenmodelle: Sie liefern eine statische Sicht der Lösungs-architektur, indem sie das Informationsportal abbilden, das die Inputs der operativen Datenquellen mit der Lieferung des Unternehmens-informations-Outputs verbindet.

• Datenfluss-Diagramme: Sie dienen häufig dazu, die dynamischen Aspekte der Lösung (Bewegungsdaten) abzubilden und andere Archi-tekturkonstrukte wie Latenz und Erreichbarkeit zu identifizieren.

• Entscheidungsmodelle: Sie sind bei der Definition nützlich, wie rele-vante betriebliche Entscheidungen getroffen werden, sowie wo und wie eine Datenanalyse diesen Bedarf am effektivsten abdecken kann.

• Physische Datenmodelle: Sie zeigen die Umsetzungsumgebung inklu-sive dem Data Warehouse und Data Marts.

Die erweiterbare Architektur der Lösungen der Business Intelligence kann eineinkrementelle Umsetzung in verschiedenen Funktionsbereichen des Unternehmensunterstützen. Der Business-Analyst kann Optionen von Veränderungsstrategienauf der Grundlage des betrieblichen Bedarfs und der Prioritäten, der Auswir-kungen auf die Unternehmensaktivitäten und der Benutzerfreundlichkeit derbestehenden Infrastrukturkomponenten definieren.


460


• Analyse der Geschäftsregeln • Backlog Management (Kap.10.2)(Kap.10.9)

• Benchmarking und • Brainstorming (Kap.10.5)Marktanalyse (Kap.10.4)

• Datenflussdiagramme (Kap.10.13) • Datenmodellierung (Kap.10.15)• Entscheidungsanalyse (Kap.10.16) • Dokumentenanalyse (Kap.10.18)• Schätzung (Kap.10.19) • Fokusgruppen (Kap.10.21)• Funktionale Gliederung (Kap.10.22) • Glossar (Kap.10.23)• Organisationsmodellierung • Risikoanalyse und (Kap.10.32) -management (Kap.10.38)

• Ursachenanalyse (Kap.10.40) • Stakeholder-Listen, -Karten oder Personas (Kap.10.43)

• SWOT-Analyse (Kap.10.46)

.5 Anforderungsanalyse und Design-Definition Bei der Modellierung und Spezifikation der Anforderungen der Back Office-Datenerfassung und -speicherung nutzt der Business-Analyst spezifische daten-orientierte Modellierungstechniken wie Datenmodellierung, Data Dictionary,Entscheidungsmodellierung und Analyse der Geschäftsregeln.

Datenmodelle der bestehenden Systeme helfen bei der Definition der Datenver-fügbarkeit und identifizieren Doppelgleisigkeiten, Inkonsistenzen und Qualitäts-mängel von Daten. Wo es keine Systemdokumentation gibt oder diese veraltetist, kann Reverse-Engineered-Modellierung eine wichtige Rolle spielen und ofteine Zusammenarbeit mit technischen Experten wie Datenbank-Administratorenund Applikations-Programmierern erfordern.

Ein Soll-Zustands-Datenmodell zeigt auf, wie die Quellinformationen in der vor-geschlagenen Lösung generisch strukturiert sind. Der Transformationsprozesswird normalerweise mithilfe von Datenflussdiagrammen modelliert, um dasLatenzmanagement und die Erreichbarkeits-Anforderungen der Lösung zu illus-trieren. Der Business-Analyst definiert spezifische Geschäftsregeln für die Prüfungder Datenintegrität und für die Datentransformation.

Zur Modellierung und Spezifikation des Informations-Outputs für den Kontaktmit Kunden gehören

• die Analyse bestehender Berichte, um festzustellen ob diese ersetzt oder mit Ergebnissen der Business Intelligence verbessert werden sollten

• die Nutzung von Fähigkeiten der Business Intelligence wie Ad hoc-Abfragen, Data Mining und komplexe Ereignisabwicklung, um den Inhalt und das Format der neuen Ergebnisse der Business Intelligence zu identifizieren und zu spezifizieren.


461

Der Business-Analyst ist an der Beurteilung der Fähigkeiten einer vorgeschlagenenLösung im Hinblick auf die spezifizierten Anforderungen beteiligt (normalerweiseist dies ein kommerzielles Standard-Software-Paket). Zum Kontext der BusinessIntelligence gehören funktionale Anforderungen wie Selbstbedienungsangebote,Datenanalyse-Werkzeuge, Datenpräsentations-Werkzeuge, Drill-down-Fähigkeitenund nicht-funktionale Anforderungen in Bezug auf Datenqualität, Datenlatenzund Abfrageleistungsqualität.


• Akzeptanz- und Bewertungs- • Analyse der Geschäftsregelnkriterien (Kap.10.1) (Kap.10.9)

• Analyse nicht-funktionaler • Anbieter-Assessment (Kap.10.49)Anforderungen (Kap.10.30)

• Balanced Scorecard (Kap.10.3) • Beobachtung (Kap.10.31)• Data Dictionary (Kap.10.12) • Datenflussdiagramme (Kap.10.13)• Datenmodellierung (Kap.10.15) • Dokumentenanalyse (Kap.10.18)• Entscheidungsmodellierung • Funktionale Gliederung (Kap.10.22)(Kap.10.17)

• Glossar (Kap.10.23) • Interviews (Kap.10.25)• Kennzahlen und Key- Performance-Indikatoren •Organisationsmodellierung(Kap.10.28) (Kap.10.32)

• Priorisierung (Kap.10.33) • Prototyping (Kap.10.36)• Prozessmodellierung (Kap.10.35) • Reviews (Kap.10.37)• Scope-Modellierung (Kap.10.41) • Stakeholder-Listen, -Karten

oder Personas (Kap.10.43)• Statusmodellierung (Kap.10.44) • Schnittstellenanalyse (Kap.10.24)• Use Cases und Szenarien (Kap.10.47)

.6 Lösungsbewertung Bei der Einführung einer Lösung der Business Intelligence tritt häufig der Mangelauf, dass die Informations- und Analyse-Funktionalitäten, welche die Lösunganbietet, nicht genutzt werden.

Stakeholder, die nicht mit den Fähigkeiten der Business Intelligence vertrautsind, können ihren Fokus zu sehr auf den Ersatz oder die Wiederherstellung desbestehenden Informations-Outputs richten. Der Business-Analyst sollte Chancenfür zusätzliche Wertschöpfung durch eine Lösung der Business Intelligence auf-decken und bewerten.


462

Techniken des BABOK® -Leitfadens

• Akzeptanz- und • Analyse der Geschäftsregeln Bewertungskriterien (Kap.10.1) (Kap.10.9)

• Anbieter-Assessment ((Kap.10.49) • Balanced Scorecard (Kap.10.3)• Beobachtung (Kap.10.31) • Data Dictionary (Kap.10.12)• Datenflussdiagramme (Kap.10.13) • Datenmodellierung (Kap.10.15)• Dokumentenanalyse (Kap.10.18) • Entscheidungsmodellierung (Kap.10.17)• Fokusgruppen (Kap.10.21) • Funktionale Gliederung (Kap.10.22)• Glossar (Kap.10.23) • Interviews (Kap.10.25)• Item Tracking (Kap.10.26) • Kennzahlen und Key-

Performance-Indikatoren (Kap.10.28)• Organisationsmodellierung (Kap.10.32) • Priorisierung (Kap.10.33)• Prozessmodellierung (Kap.10.35) • Risikoanalyse und

-management (Kap.10.38)• Schätzung (Kap.10.19) • Stakeholder-Listen, -Karten

oder Personas (Kap.10.43)• SWOT-Analyse (Kap.10.46) • Umfrage oder Fragebogen (Kap.10.45)• Use Cases und Szenarien (Kap.10.47) • User Stories (Kap.10.48)

Die Informationstechnologie-PerspektiveDie Informationstechnologie (IT)-Perspektive zeigt die Besonderheiten der Busi-ness-Analyse aus dem Blickwinkel ihrer Auswirkungen auf die Systeme der Infor-mationstechnologie auf.

Wenn der Business-Analyst mit Informationstechnologie zu tun hat, muss er miteiner großen Komplexität und einem breiten Spektrum von Aktivitäten umgehenkönnen. Vorhaben können so klein sein wie partielle Verbesserungen oder kleineFehlerkorrekturen oder so groß wie ein Reengineering-Projekt der gesamteninformationstechnologischen Infrastruktur eines Großunternehmens. Der Busi-ness-Analyst steht vor der Herausforderung, dass die Stakeholder sehr unter-schiedliche Niveaus an Fachwissen und Fähigkeiten haben. Dennoch muss erunter diesen Umständen wertschöpfende Lösungen für die IT-Bedürfnisse derStakeholder entwickeln.

Der Erfolg des Business-Analysten im IT-Umfeld hängt im Kern davon ab, dasses ihm gelingt, den technischen Stakeholdern die Vision und die Bedürfnissedes Unternehmens effektiv zu erklären. Der Business-Analyst ist aufgefordert,proaktiv auf die Stakeholder des Unternehmens und die Entwicklungsteamszuzugehen und so sicherzustellen, dass der Bedarf verstanden und auf die Unter-nehmensstrategie ausgerichtet wird. Der Business-Analyst nimmt dabei häufig

Perspektiven Die Informationstechnologie-Perspektive

463

11.3

Diese Perspek-tive konzen-triert sich aufnicht-agileAnsätze bei IT-Vorhaben.

die Rolle eines Übersetzers ein, der den Stakeholdern des Unternehmens undden IT-Stakeholdern Bedürfnisse, Restriktionen und Kontext der anderen Stake-holder verständlich macht. Vom Begriff „Lösungs-Design“ zu sprechen, ist ineinem Technologie-Kontext und aus der Perspektive der Business-Analyse durchaussinnvoll. In einem IT-Umfeld ist der Begriff „Design“ jedoch anders besetzt undbedeutet im Allgemeinen „technisches Design“ oder den Technologieeinsatzzur Lösung betrieblicher Probleme. Der im IT-Umfeld tätige Business-Analystdefiniert und erarbeitet die Lösungsanforderungen oder nimmt zusammen mitden betrieblichen Stakeholdern am Lösungs-Design teil, während er sich ausdem technischen Design heraushält.

Im IT-Kontext wird der Begriff „Design“ traditionell für das Lösungs- oder technischeDesign reserviert, das Entwickler, IT- oder Lösungsarchitekten erstellen. Die gesamteArbeit des IT-Business-Analysten fällt unter den Begriff „Anforderungen“, inklusivebeispielsweise der Definition und dem Design von Geschäftsprozessen, Benut-zerschnittstellen, Berichten oder anderen, für die Lösung relevanten Elementen,die nicht vom Umsetzungs-Team abgedeckt werden. Der Business-Analyst ineinem IT-Kontext kann daher den Begriff „Design“ durch „Lösungsanforderungen“ersetzen, um die Verantwortlichkeiten klar zu trennen.

Der Business-Analyst, der in einem IT-Umfeld arbeitet, prüft seine Aufgaben hin-sichtlich der folgenden drei Faktoren:

• Auswirkungen auf die Lösung: Nutzen und Risiko der Lösung für das Unternehmen.

• Reifegrad des Unternehmens: Formalisierungsgrad und Flexibilität der Change-Prozesse eines Unternehmens.

• Umfang der Änderung: Breite, Tiefe, Komplexität und Kontext des vorgeschlagenen Change.


Veränderungen an IT-Systemen werden aus verschiedenen Gründen eingeleitet.Jeder der folgenden Treiber kann eine Veränderung der IT auslösen:

• Entwickeln einer neuen betrieblichen Fähigkeit: Damit kann ein Unter-nehmen grundlegend verändert werden. Derartige IT-Vorhaben kön-nen größere Programme außerhalb der IT auslösen, die sich dabei aberauf diese – die Unternehmensumwelt verändernden – Technologien ausrichten müssen.

• Erreichen eines betrieblichen Ziels durch Verbesserung einer bestehen-den Fähigkeit: Mit einem solchen Change soll ein definierter Bedarf gedeckt werden. Dazu gehören beispielsweise auch regulatorische An-forderungen oder die Umsetzung von spezifischen betrieblichen Zielen. Solche Vorhaben verändern oft ein bereits bestehendes System, könnenaber auch die Umsetzung und Integration neuer Systeme erfordern.

PerspektivenDie Informationstechnologie-Perspektive

464

Wichtig

11.3.1

Mehr Informa-tionen zu agilenAnsätzen inInformations-technologie-Vorhaben finden Sie inKapitel 11.1„Die agile Per-spektive“.

• Erleichterung einer operativen Verbesserung: Sie wird angestrebt, um die Effizienz eines Unternehmens zu erhöhen oder das betriebliche Risiko zu senken. Der Umfang der Änderung, der Reifegrad des Unter-nehmens und die Auswirkungen der Lösung bestimmen, ob diese Änderungen als Projekt, als kontinuierlicher Verbesserungsprozess oder als einfaches Verbesserungsvorhaben gemanagt werden.

• Wartung eines bestehenden IT-Systems: Sie wird durchgeführt, um ein bestehendes IT-System problemlos betreiben zu können. Abhängig vom Umfang der Änderung kann die Wartung als Projekt oder im Rahmen eines festgelegten Wartungszyklus durchgeführt werden. Dazu können von der Technologie getriebene Änderungen zählen, wiedie Einstellung des Supports einer Technologie durch einen Lieferantenoder auch terminierte Releases beziehungsweise Upgrades eines gekauften Software-Pakets oder technische Veränderungen, die not-wendig werden, damit die strategisch gewählte Architektur aufrecht-erhalten werden kann.

• Reparatur eines defekten IT-Systems: Wenn ein IT-System nicht wie vorgesehen funktioniert, wird es repariert, um die normale Funktions-weise wieder herzustellen. Die Dringlichkeit der Reparatur hängt im Allgemeinen vom Ausmaß der Störung ab. In einigen Fällen kann der Reparaturumfang sehr groß sein, so dass die Reparatur als eigenstän-diges Projekt durchgeführt wird.

.1 Breite des ChangeInformationstechnologische Vorhaben können sich auf ein Einzelsystem oderauf viele interagierende Systeme beziehen. Einige Systeme werden intern ent-wickelt und gewartet, während andere Anwendungen, die von einer externenOrganisation entwickelt wurden, zugekauft und implementiert werden. Es istauch möglich, dass externe Unternehmen maßgeschneiderte Lösungen speziellentwickeln, wenn etwa Entwicklungsaufgaben ausgegliedert (Outsourcing) odervertraglich vereinbart werden.

Der Scope eines IT-Vorhabens beschränkt sich oft auf eine bestimmte Softwareund Hardware mit einer kleinen Anzahl von Systemen, Applikationen oder Stake-holdern. Größere Vorhaben können Auswirkungen auf viele Benutzergruppenund Systeme haben und erfordern oft die Mitwirkung des ganzen Unternehmens.Der Einsatz von Standard-Software (COTS) kann anfangs einen geringen oderbegrenzten Umfang haben, nach Vollendung der Analyse jedoch einen breiterenUmfang annehmen als zuerst erwartet. Der Ansatz der Business-Analyse für dieAuswahl und den Einsatz von Standard-Software ist anders als bei einer hausin-ternen Entwicklung. Diese IT-Systeme benötigen meistens Anpassung, Integration,Verwaltung und Training. Manchmal werden die Vorhaben auf die Erstinstallationund Umsetzung oder auf die Verbesserung einer bestehenden Applikationbeschränkt. IT-Vorhaben können sich auch auf eine sehr spezifische technische


465

Lösung beschränken und die Frage beantworten, welche Daten benötigt werden,wie diese Daten gesammelt und gespeichert werden und wie auf sie zugegriffenwird, um die betrieblichen Transaktionen zu unterstützen, oder wie Informationenverteilt und den Unternehmenseinheiten zur Verfügung gestellt werden.

Der im IT-Bereich tätige Business-Analyst ist angehalten, den Kontext jeder IT-Änderung zu berücksichtigen. Er überlegt, ob eine Änderung als Projekt, alskontinuierlicher Veränderungsprozess oder als Wartungsaktivität gemanagt wird.Der Business-Analyst hat also das Change Management des Unternehmens undalle Auswirkungen inkl. Training, Kommunikation und Akzeptanz der Änderungin seine Überlegungen einzubeziehen.

Die Art der Tätigkeiten der Business-Analyse in einem IT-Umfeld hängt von einerVielzahl von Faktoren ab, die von der Lösung beeinflusst werden:

• Welche Auswirkungen hat ein Ausfall des Systems auf das Unternehmen?• Was geschieht bei verminderter Leistung?• Welche betrieblichen Fähigkeiten und Prozesse hängen vom IT-System ab?

• Wer trägt zu diesen Fähigkeiten und Prozessen bei?• Wer nutzt diese Fähigkeiten und Prozesse?

Bei der Berücksichtigung dieser Faktoren achtet der Business-Analyst nicht nurdarauf, dass der Formalisierungsgrad der Analyseaktivitäten auf die von derUnternehmenung definierten Prozesse der Business-Analyse abgestimmt wird,sondern er berücksichtigt auch die Wichtigkeit des IT-Systems. Die Bedeutungdes analysierten Systems kann einen Hinweis darauf geben, ob weitere Analysennotwendig sind, um die Anforderungen für den Change zu unterstützen undzu definieren.

.2 Tiefe des ChangeHäufig muss sich der Business-Analyst bei Veränderungen in einer IT-Umgebungmit Details auseinandersetzen. Dazu gehören auch technische Details wie dieDefinition individueller Datenelemente, die durch den Change verändert werdenoder betroffen sind. Integrationsmaßnahmen können Analysen von und Entwürfefür Schnittstellen zwischen IT-Systemen auf sehr detaillierter Ebene auslösen.Wegen des notwendigerweise hohen Detailierungsgrads in Vorhaben dieser Arterhebt und analysiert der Business-Analyst, wie das Unternehmen als Ganzesfunktioniert und wie die IT-Systeme diese Aktivitäten unterstützen. Damit gewinntder Business-Analyst das notwendige Verständnis dafür, ob die entdeckten unddokumentierten Details für die Wertschöpfung relevant sind. Dies kann eineganz besondere Herausforderung sein, wenn eine IT-Systemänderung aus tech-nischen Gründen gestartet wird, ohne vorher den Bezug zum beziehungsweisedie Ausrichtung auf den Unternehmenszweck geklärt zu haben.


466

.3 Nutzen und umgesetzte LösungenSysteme der Informationstechnologie werden zur Steigerung des Nutzens in einemUnternehmen eingesetzt. Dazu gehören auch alle unterstützenden Fähigkeitenund Prozesse, die dieses System verwenden. Der Business-Analyst bemüht sich,die IT-Funktionalitäten auf diese Prozesse und Fähigkeiten auszurichten und zuermitteln, welchen Effekt das IT-System auf diese Prozesse und Fähigkeiten hat.

Änderungen eines IT-Systems können auf vielfältige Art Nutzen schaffen wiebeispielsweise:

• Betriebskosten senken• Leerarbeit reduzieren• die strategische Ausrichtung verbessern• die Verlässlichkeit und Stabilität erhöhen• fehleranfällige oder manuelle Prozesse automatisieren• Probleme beseitigen• Skalierungen ermöglichen• Fähigkeiten verbessern oder leichter nutzbar machen• neue Funktionalitäten und neue Fähigkeiten umsetzen.

.4 Umsetzungsansatz Es gibt große Unterschiede bei der Umsetzung von Tätigkeiten der Business-Analyse in einer IT-Organisation. Die Spanne reicht von kleinen Verbesserungen,die innerhalb eines einzelnen, kurzen Zeitraums ausgeliefert werden, bis zuzeitlich gestaffelten Multi-Release-Umsetzungen.

Kurzfristige Vorhaben können einen einzelnen Business-Analysten während einerkurzen Zeitspanne beschäftigen. Größere Vorhaben setzen in der Regel mehrereBusiness-Analysten ein, die ihre Aktivitäten in verschiedener Art miteinanderkoordinieren. Business-Analysten können ihre Arbeit nach den betroffenen Unter-nehmenseinheiten oder nach spezifischen Aktivitäten aufteilen.

.5 Zentrale AnnahmenDie folgende Liste enthält die zentralen Annahmen der IT-Disziplin:

• Betriebliche Fähigkeiten und Prozesse, die ein IT-System nutzen, bringen dem Unternehmen Nutzen.

• Der Business-Analyst, der sich mit anderen Perspektiven auseinander-setzt, kann seine Beiträge in die Arbeit der IT-Business-Analysten einbringen.

• IT-Systemänderungen werden normalerweise von einem betrieblichen Bedarf getrieben, allerdings gibt es auch Vorhaben, die von technolo-gischen Entwicklungen ausgelöst werden.


467


.1 Auftraggeber des ChangeChange-Vorhaben der Informationstechnologie können entweder vom Manage-ment gesponsert, von IT-Abteilungen beantragt oder von beiden gemeinsamausgelöst werden. Diese Change-Vorhaben sollten auf die Unternehmensstrategieund auf die Unternehmensziele ausgerichtet sein. Eine IT-Abteilung kann Vorhabenallein auf die technische Strategie ausrichten oder technische Ziele anstreben,für den Erfolg eines Change ist jedoch eine Ausrichtung auf die übergreifendeUnternehmensstrategie maßgeblich.

Mögliche Auftraggeber/Sponsoren eines Change sind• Technik-Team• Technik-Vorstand• Verantwortlicher für eine Software-Applikation• Prozessverantwortlicher • Bereichsverantwortlicher (Business Owner),• interner Produktmanager • mit regulatorischen Aktivitäten Beauftragte (wie die Rechtsabteilung).

Unternehmen können auf vielen verschiedenen Wegen IT-Changes in Gangbringen. Häufig bilden Großunternehmen ein Programm- oder Projektmanage-ment-Office innerhalb der IT-Abteilung, das Änderungswünsche entgegennimmtund den Einsatz für die Abteilung priorisiert.

.2 Ziele des ChangeDer Business-Analyst identifiziert alle relevanten Abteilungen, Prozesse, Appli-kationen und Funktionen, die von dem vorgeschlagenen Change betroffen seinkönnten. Der Business-Analyst schaut nicht nur auf die Details des Vorhabens,sondern achtet auch auf die Gesamtzusammenhänge und den möglichen Einflussdes Change (sowohl betriebswirtschaftlich als auch technisch) auf das Unter-nehmen. Dies beinhaltet eine Prozess- und Funktionenanalyse mit einem Schwer-punkt auf die technischen und organisatorischen Schnittstellen.

.3 Die Rolle des Business-AnalystenIn einem IT-Vorhaben können Aktivitäten der Business-Analyse durch unterschiedlichqualifizierte Personen ausgeführt werden und unterschiedliche Titel tragen. DieZuteilung kann abhängig sein von der Art des Change, der Erfahrung, dem not-wendigen Wissen, aber auch von den verfügbaren personellen Ressourcen. DasPersonal kann den Aufgaben der Business-Analyse gemäß den unten beschriebenenErfahrungen zugeteilt werden. Es kann bei einem bestimmten Change alle odernur einen Teil der Zuständigkeiten der Business-Analyse übernehmen.


468

11.3.2

Es ist möglich, dass alle Aufgaben der Business-Analyse in einem IT-Projekt voneiner Person durchgeführt werden, die nur einen der folgenden Hintergründebesitzt:

• Business-Analyst, der eng mit den Anwendern eines IT-Systems zusam-menarbeitet

• IT-Business-Analyst, der als Bindeglied zwischen dem technischen Teamund der Unternehmenseinheit agiert, die die Applikation nutzt

• Fachexperte, der mit der eingesetzten Software vertraut ist• Software-Anwender, der die Software im Tagesgeschäft nutzt und daraus Empfehlungen für die Benutzerfreundlichkeit ableiten kann

• System-Analyst mit Fachwissen aus dem Geschäftsbereich, aber ohne Erfahrungen mit der spezifischen Applikation

• Geschäftsprozess-Verantwortlicher mit fundiertem Verständnis der betrieblichen Fähigkeiten oder Prozesse, aber ohne technische oder IT-Erfahrung

• Techniker mit fundiertem technischem Erfahrungshintergrund• Vertreter des Herstellers (von Standard-Software), der das notwendige Customizing einer Standardlösung vornehmen kann und dazu sein Fachwissen über die Hersteller-Software und frühere Installationserfah-rungen nutzt.

.4 Ergebnisse der Business-AnalyseInnerhalb eines IT-Vorhabens kann der Business-Analyst die von der Änderungbetroffenen Geschäftsprozesse sowie die vom System gesammelten Daten undInformationen der Business Intelligence ermitteln. Der am Vorhaben beteiligteBusiness-Analyst plant sorgfältig den Einsatz der Business-Analyse und die Lie-ferobjekte, die das Change-Vorhaben unterstützen sollen.

Der gewählte Ansatz wirkt sich direkt auf die Lieferobjekte und Ergebnisse derBusiness-Analyse aus. Viele Unternehmen haben eine eigene Methode der Ent-wicklung von Systemen oder Lösungen, die bis zu einem bestimmten Grad dieLieferobjekte für jeden Projektmeilenstein vorgibt. Über diese Vorgaben hinauskann der Business-Analyst zusätzliche Lieferobjekte erstellen, die über diejenigenhinausgehen, die vom gewählten Change-Ansatz oder dem spezifischen betrieb-lichen Vorgehen vorgesehen sind, und dabei Techniken anwenden, die ein ganz-heitliches Verständnis des Change unterstützen.

Der im IT-Bereich tätige Business-Analyst ist verantwortlich für die Erstellung fol-gender Lieferobjekte:

• definierte, vollständige, testfähige, priorisierte und verifizierte Anforderungen

• Analyse der Alternativen/Optionen


469

• Geschäftsregeln• Gap-Analyse• Funktionale Zerlegung• Use Cases und Szenarien, und/oder, falls geeignet, User Stories• Schnittstellenanalyse• Prototypen• Prozessanalyse• Prozessmodelle• Zustandsmodelle• Entscheidungsmodelle• Kontextmodelle oder Scope-Modelle • Datenmodelle.

In dieser Liste nicht aufgeführte Lieferobjekte, die mit den Ergebnissen von Busi-ness-Analyse-Techniken in Beziehung stehen, können ebenfalls als Lieferobjekteangesehen werden.

Methoden

Die von IT-Organisationen eingesetzten Methoden sind sehr vielfältig. Im Allge-meinen lassen sich zwei generische Methoden der Entwicklung von Lösungenunterscheiden:

• Determiniert (Predictive): Strukturierte Prozesse, in denen besonderer Wert auf die Planung und formale Dokumentation der Prozesse zur Umsetzung des Change gelegt wird. Jede Phase des Prozesses oder der Sequenz wird abgeschlossen, bevor die nächste Phase startet.

• Adaptiv: Adaptive Prozesse erlauben die erneute Durchführung eines oder mehrerer Zyklen des strukturierten Gesamtprozesses. Die meistenadaptiven Modelle sind sowohl iterativ als auch inkrementell und fokussieren auf die Weiterentwicklung des Produktes sowohl in der Breite als auch in der Tiefe.

Es kann auch eine hybride Methode genutzt werden. Hybrid kann beispielsweiseeine Gesamtvision für das Vorhaben beinhalten (wie im determinierten Ansatz),und gleichzeitig die Definition der Details in vielen individuellen Zyklen oder Ite-rationen erledigen (wie im adaptiven Ansatz).

Die folgende Tabelle identifiziert verschiedene etablierte Methoden oder Ansätze,die der im IT-Bereich tätige Business-Analyst antreffen kann.


470

11.3.3

Tabelle 11.3.1: Methoden der Informationstechnologie

Basiskompetenzen

Der im IT-Bereich tätige Business-Analyst besitzt möglicherweise für die IT-Ent-wicklung relevante Fähigkeiten wie Programmierung, Datenbankmanagement,Erstellung einer System- oder Lösungsarchitektur, Software-Test oder anderetechnische Qualifikationen. Für die Entwicklung relevante Fähigkeiten oder tech-nische Kenntnisse sind aber für den im IT-Umfeld erfolgreichen Business-Analystennicht zwingend erforderlich. Es ist für den Business-Analysten wichtig, die Details,die zu einem Anforderungspaket gehören, sehr gut zu verstehen, um die tech-nische Lösung unterstützen zu können. Er sollte auch wissen, was unter denRahmenbedingungen der technischen Architektur eines Unternehmens machbarist. Diese Fähigkeiten ermöglichen es ihm, mit den Stakeholdern zusammen einFramework für die betriebliche Lösung zu entwickeln, das dem technischenTeam die Flexibilität zum Design der technischen Lösung gibt.

Der Business-Analyst nutzt bei der Arbeit mit den Stakeholdern seine Fähigkeitender Beeinflussung und Moderation. Verhandlungskompetenz ist bei der Zusam-menarbeit mit betrieblichen und technischen Mitarbeitern besonders wichtig,um zu Entscheidungen zu kommen und Einvernehmen zu erreichen, wenn dieKosten der Lösung (in Bezug auf Zeit, Budget oder Auswirkungen auf die Archi-tektur) mit dem gewünschten betrieblichen Ergebnis in Konflikt stehen.


471

Methode Kurzbeschreibung

Selbstentwickeltoder unterneh-mensspezifisch

Eine Methode zur Steuerung von IT-Vorhaben kann aus Kompo-nenten bereits bestehender Methoden und Ansätze zusammen-gestellt werden.

RequirementsEngineering(RE)

Damit wird ein strukturierter Ansatz zur Entwicklung und zumManagement von Anforderungen festgelegt, der in deterministi-schen, adaptiven und agilen Umfeldern angewendet werdenkann.

StructuredSystems Analysis andDesign Method(SSADM)

Eine deterministische Entwicklungsmethode, die sich auf dielogische Modellierung konzentriert und die Trennung der Anfor-derungen von den Lösungen als Kernaspekt der Systemanalyseund Spezifikation ansieht.

Unified Process(UP)

Ein adaptiver Entwicklungsansatz. Die Start- und Verfeinerungs-phasen sind besonders wichtig für den Business-Analysten. UPzählt nicht zu den agilen, sondern zu den adaptiven Methoden.

11.3.4

Systemdenken ist eine sehr wichtige Kompetenz für den Business-Analysten imIT-Umfeld. Systemdenken unterstützt die Fähigkeit des Business-Analysten, eineübergeordnete Sicht einzunehmen, und so andere betroffene Applikationenoder technische Aspekte, Details eines bestimmten Bedarfs und mögliche tech-nische Lösungen im Blick zu behalten. Systemdenken unterstützt auch die Fähig-keit, Auswirkungen auf Personen, Prozesse und Software zu identifizieren, dienicht notwendigerweise direkt von der IT-Entwicklung betroffen sind, und dieRisiken und möglichen Ergebnisse dieser Auswirkungen zu analysieren.


Dieser Abschnitt erklärt, in welchem Bezug spezifische Praktiken der Business-Analyse in der Informationstechnologie zu den im BABOK®-Leitfaden definiertenAufgaben und Praktiken der Business-Analyse stehen. Er beschreibt auch, wiejedes Wissensgebiet in einem IT-Umfeld angewandt oder verändert wird.

Jedes Wissensgebiet listet die für die IT-Perspektive relevanten Techniken auf. Inder IT verwendete Techniken weichen im Großen und Ganzen nicht wesentlichvon den Techniken des BABOK®-Leitfadens ab. Die Techniken des BABOK®-Leit-fadens finden sich im Technik-Kapitel des Leitfadens. Die Liste ist nicht als all-umfassend anzusehen, sondern hebt nur verschiedene Techniken hervor, dievon dem Business-Analysten zur Erfüllung der Aufgaben dieses Wissensgebietseingesetzt werden.

.1 Planung und Überwachung der Business-AnalyseEin Ansatz der Business-Analyse ist ein Kerninstrument der Kommunikation, dasdazu verwendet werden kann, die für die Business-Analyse notwendigen Res-sourcen zu identifizieren und genügend Zeit für die Analyse-Arbeit vorzusehen.Ein wohldefinierter Plan der Business-Analyse fügt sich in den Gesamtprojektplanein und bietet dem Business-Analysten die Möglichkeit, die Aktivitäten der Busi-ness-Analyse für das Projekt zu definieren und zeitlich zu planen.

Viele Unternehmen haben Standards und Prozesse eingeführt, die bestimmteAufgaben und Ergebnisse der Analyse definieren. Wenn es die nicht gibt, ermitteltder Business-Analyst diese Aufgaben und Ergebnisse selbst auf Basis des Bedarfsin dem jeweiligen Vorhaben.

Es ist wichtig, den Kontext der Analyse-Arbeiten zu verstehen. Dazu gehörtauch das Verständnis des Zusammenspiels der Software-Systeme, Geschäftspro-zesse und Daten, die zwischen den Systemen ausgetauscht werden. Änderungenan einem einzelnen System oder Prozess können eine Welle an Folgeänderungenauslösen, die dazu führen, dass zusätzliche Systeme, Prozesse oder Stakeholder-Gruppen in den Scope des Vorhabens hineinkommen.

Der IT-Business-Analyst kann Mitglied eines Software-Teams sein. So kann derBusiness-Analyst sehr viel Fachwissen über eine bestimmte Software oder von


472

11.3.5

der Software unterstützte Prozesse erwerben. Die Einstellungen und Bedarfeder Stakeholder können sich ändern, je nachdem wie ein Change abläuft. Rollen,Zusammenarbeit und Kommunikation werden für jeden Change eingeplant.

Standard-Software-Lösungen können größere Maßnahmen zur Systemintegrationund -anpassung auslösen. Immer wieder gibt es unerwartete Aufgaben, die sichaus der Einführung externer Software ergeben. Bei der Berücksichtigung unbe-kannter Auswirkungen und schwer einschätzbarer Anpassungen (Customizing)zieht der Business-Analyst sowohl die internen Stakeholder hinzu, da sie dieBedarfe im Rahmen des Change kennen, als auch externe Stakeholder, dieErfahrungen mit der Einführung bestimmter Standard-Software-Lösungen ein-bringen können.


• Backlog Management (Kap.10.2) • Dokumentenanalyse (Kap.10.18)• Funktionale Gliederung (Kap.10.22) • Item Tracking Kap.10.26)• Kennzahlen und Key- • Organisationsmodellierung Performance-Indikatoren (Kap.10.32)(Kap.10.28)

• Rollen- und Zuständigkeits- • Schätzung (Kap.10.19)matrix (Kap.10.39)

• Scope-Modellierung (Kap.10.41) • Stakeholder-Listen, -Karten oder Personas (Kap.10.43)

.2 Erhebung und ZusammenarbeitÄnderungen der Informationstechnologie betreffen häufig viele Stakeholder,die, jeder für sich, sehr spezifische Beziehungen zur Lösung oder zum Changehaben. Wenn eine Änderung eine IT-Applikation oder ein IT-System betrifft,kann das technische Personal Fachwissen, Sichtweisen und Erfahrungen ein-bringen, mit deren Hilfe Auswirkungen auf weitere Systeme oder Prozesse iden-tifiziert werden können, wenn Anforderungen und Lösungen definiert werden.Darum empfiehlt es sich, zumindest eine Erhebungsrunde durchzuführen, inwelcher sich gleichzeitig Mitarbeiter aus der Entwicklung oder dem technischenDesign und Experten der Fachbereiche im gleichen Raum befinden. Dieser Ansatzzur Erhebung bietet eine Plattform zur Zusammenarbeit von technischen undbetriebswirtschaftlichen Teams, wobei der IT-Business-Analyst als Moderator undVerbindungsglied im Prozess agiert.

Der im IT-Bereich tätige Business-Analyst kann alle Techniken einsetzen, die imWissensgebiet „Erhebung und Zusammenarbeit“ identifiziert wurden. Zusätzlichsind im IT-Bereich die folgenden Methoden von großem Nutzen:

• Recherche: Sie nutzt Ergebnisse betrieblicher Prozesse, Markt-forschung, Wettbewerbsanalyse, funktionale Spezifikationen und Beobachtung.


473

• Simulation: Sie nutzt statistische Modellierung und erstellte Modelle.• Experimente: Sie nutzen Machbarkeitsnachweise, Prototypen, Alpha- und Beta-Releases, und A/B-Tests.

Informationstechnologische Change-Vorhaben können von betrieblichen Stake-holdern als Störung oder als Kosten angesehen werden, wenn die Änderungfür die Stakeholder nicht erfolgskritisch ist oder wenn sie negative Auswirkungendurch die Änderung erwarten. Dies kann die Mitwirkung bei der Erhebungerschweren. Die Erhebung über Bereichsgrenzen hinweg kann behindert werden,mit der möglichen Folge, dass die Zusammenarbeit unterbrochen wird undNachbesserungen notwendig werden. Der IT-Business-Analyst kann das Risikovon Nachbesserungen verringern, indem er dafür sorgt, dass Ressourcen der ITund des Betriebs zusammenarbeiten.


• Beobachtung (Kap.10.31) • Brainstorming (Kap.10.5)• Dokumentenanalyse (Kap.10.18) • Fokusgruppen (Kap.10.21)• Gemeinschaftliche Spiele (Kap.10.10) • Interviews (Kap.10.25)• Prozessmodellierung (Kap.10.35) • Prototyping (Kap.10.36)• Schnittstellenanalyse (Kap.10.24) • Scope-Modellierung (Kap.10.41)• Sequenzdiagramme (Kap.10.42) • Stakeholder-Listen, -Karten

oder Personas (Kap.10.43)• Statusmodellierung (Kap.10.44) • Umfrage oder Fragebogen (Kap.10.45)• Use Cases und Szenarien (Kap.10.47) •Workshops (Kap.10.50)

.3 Management des Anforderungs-LebenszyklusIn IT-Vorhaben treten häufig Sachverhalte auf, an die zuvor niemand gedacht hat.Erst durch gründliche Untersuchungen lernt der Business-Analyst die Auswirkungender neuen, von der Lösung bereitgestellten Funktionalitäten kennen. Das Bewusst-sein, dass es in IT-Umgebungen viele Unwägbarkeiten gibt, hat dazu geführt, dasszunehmend in kurzen Zyklen geplant und umgesetzt wird (agiles Vorgehen undkontinuierlicher Verbesserungsprozess), Change rigoros kontrolliert wird (CapabilityMaturity Model Integration, CMMI) und bei Diensten der Informationstechnologiezunehmend Outsourcing betrieben wird (Software as a Service und Cloud-Services).

Der im IT-Bereich tätige Business-Analyst legt deswegen besonderes Augenmerkauf die Harmonisierung, Abnahmeverfahren,Änderungskontrollen, Nachvollzieh-barkeit (Traceability) und die Management-Tools zur Steuerung des Anforde-rungslebenszyklus. Es gehört zur Rolle des Business-Analysten, mit den Stake-holdern zusammen eine konsistente Methode zur Überprüfung sich ändernderAnforderungen zu entwickeln, um die Ausrichtung des Vorhabens auf die Unter-nehmensziele sicherzustellen.


474

In vielen Fällen werden Änderungen an bereits genehmigten Anforderungen vor-genommen, die durch Änderungen höherrangiger Anforderungen (z.B. Unterneh-menszielen) ausgelöst werden. Der Business-Analyst arbeitet mit Stakeholdernzusammen, um sicherzustellen, dass diese Anforderungen tragfähig sind, bevor zuLösungs- oder technischen Anforderungen übergegangen wird. Wenn Änderungender Anforderungen präsentiert werden, analysiert der Business-Analyst die Auswir-kungen und plant, wie die vorgeschlagenen Änderungen zu managen sind.

Mit der steigenden Komplexität der IT-Umgebungen wird es immer wichtiger,jede Änderung sowohl an einer Anforderung als auch zwischen Anforderungenund anderen Informationen rückverfolgen zu können. Die Nachvollziehbarkeitauch von Abhängigkeiten und Beziehungen unter den Anforderungen erleichtertes den Stakeholdern, Änderungen im IT-System zu verstehen und die Auswir-kungen zusätzlicher Änderungen vorherzusehen.

Da sich technische Systeme im Zeitablauf ändern, ist es hilfreich, wenn jedeVersion einer Anforderung in bestimmter Weise gespeichert und Rechenschaftdarüber abgelegt wird. Die Nachvollziehbarkeit ermöglicht es, die Quelle undden Besitzer jeder angeforderten Funktion und jedes Features festzustellen, undAntworten auf die Fragen zu finden nach dem „Warum“, „Wann“ und „Wie“des Change im Zeitablauf. Diese Historie ist wichtig, um zu gewährleisten, dassdie Anforderungen vollständig sind und dass die Genehmigung der Anforde-rungen eine bewusste Entscheidung ist. Falls die Change-Vorhaben und das IT-System von Wirtschaftsprüfern und Regulierungsbehörden unter die Lupe genom-men werden, können sie und andere Beteiligte verstehen, was, wann und warumetwas geschah. Dies kann bei Prüfungen immer dann besonders wichtig sein,wenn eine Applikation Daten oder Prozesse systematisch und ohne menschlichesZutun bei einer Transaktion oder Prozessinstanz managt. Diese Verfolgbarkeithilft dem Unternehmen auch zu verstehen, warum bestimmte Funktionalitätenvom IT-System nicht erbracht oder umgesetzt wurden, und warum sie aus demScope einer Implementierung entfernt wurden.


• Akzeptanz- und • Entscheidungsanalyse (Kap.10.16)Bewertungskriterien (Kap.10.1)

• Item Tracking (Kap.10.26) • Kennzahlen und Key- Performance-Indikatoren (Kap.10.28)

• Priorisierung (Kap.10.33)

.4 Strategische AnalyseIn einer IT-Organisation konzentriert sich die Strategieanalyse auf die Technologienund Systeme, Geschäftseinheiten, Geschäftsprozesse und Geschäftsstrategien,die von einem vorgeschlagenen Change betroffen sind. Es ist möglich, dass die


475

Auswirkungen einer Änderung eine ganze Reihe weiterer Änderungen in anderenSystemen zur Folge haben. Um die Bedarfe und die vorgeschlagenen Changesanalysieren zu können, muss der Business-Analyst versuchen, die verschiedenenvon einer Änderung betroffenen Aspekte zu verstehen.

Zur Ist-Analyse in einem IT-Vorhaben gehören die Analyse manueller Prozesse,das Verständnis darüber, was das System oder die Technologie derzeit tut, welcheDaten für die Ausführung benötigt werden und welche anderen Systeme undProzesse mit dem System vernetzt sind. Der Business-Analyst plant von vornhereinein, dass zuerst der Ist-Zustand und der größere Kontext des Unternehmensgründlich verstanden sein muss, in dem Bewusstsein, dass der Scope deutlichenger wird, sobald der Soll-Zustand identifiziert ist.

Wenn der Ist-Zustand verstanden wurde, wird der gewünschte Soll-Zustandbeschrieben. Er kann auf Prozessen oder auf Fähigkeiten basieren und schließtnormalerweise mit ein, wie sich bestehende Systemfunktionalitäten ändern müs-sen, um die zukünftige Vision zu unterstützen und die Ziele sowohl der indivi-duellen Stakeholder als auch des Unternehmens zu erfüllen. Aus dem Verständnisdes Ist- und Soll-Zustands kann die Differenz zwischen beiden identifiziert undso die Richtung der Änderung bestimmt werden. Erst dann gilt es, die Lösungs-optionen zu untersuchen.

Sobald die Aspekte des Scope der Änderung und der erwünschte Soll-Zustandverstanden wurden, beurteilt der Business-Analyst damit verbundene Unsicher-heiten und Risiken. Unsicherheit wird verdeutlicht durch:

• Identifikation und Definition der Risiken• Identifikation und Definition möglicher Vorteile• Festlegung von Parametern für Abweichungen bei bekannten Prozessen und Operationen

• Aufklärung des Unbekannten.

Der Business-Analyst untersucht auch andere mögliche Risiken, inklusive:• Herstellerrisiken, wie z.B. die Stabilität ihres Geschäftes und ihrer Produkte• Auswirkungen auf die technische Umgebung des Systems• Skalierbarkeit der Lösung, falls das Transaktionsvolumen oder die Anwenderanzahl im Zeitablauf steigen sollte

• weitere Prozesse oder Systemänderungen, die wegen der unter-nommenen Änderung notwendig werden.


• Anbieter-Assessment (Kap.10.49) • Beobachtungen (Kap.10.31)• Betriebliche Fähigkeitsanalyse • Fokusgruppen (Kap.10.21)(Kap.10.6)


476

• Funktionale Gliederung (Kap.10.22) • Interviews (Kap.10.25)• Item Tracking (Kap.10.26) • Prozessanalyse (Kap.10.34)• Prozessmodellierung (Kap.10.35) • Scope-Modellierung (Kap.10.41)• SWOT-Analyse (Kap.10.46) • Umfrage oder Fragebogen (Kap.10.49)• Workshops (Kap.10.50)

.5 Anforderungsanalyse und Design-DefinitionFür den im IT-Bereich tätigen Business-Analysten ist es wichtig, zu verstehenund zu klären, was der Begriff „Design“ bedeutet. Viele IT-Organisationen ver-stehen unter „Design“ nur das Design oder die Blaupause/Blueprint einerSoftware oder einer technischen Veränderung. Das Wissensgebiet „Anforde-rungsanalyse und Design-Definition“ fasst den Begriff „Design“ weiter und siehtihn aus dem Blickwinkel des Business-Analysten. Designs sind nutzbare Abbil-dungen, die sich auf die Lösung beziehen und aufzeigen, wie durch eine LösungNutzen geschaffen werden kann, wenn sie tatsächlich umgesetzt wird. Bei-spielsweise können Modelle möglicher Prozessverbesserungen (mit oder ohneAuswirkung auf ein IT-System), Layouts von Benutzerschnittstellen oder Spezifi-kationen von Berichten auch als „Designs“ angesehen werden.

Der Business-Analyst erarbeitet die betrieblichen und technischen Anforderungen,gliedert und definiert die Bedürfnisse der Stakeholder und ermittelt den Nutzenfür die Stakeholder, wenn eine technische Lösung oder Änderung umgesetztwird. Er erhebt, definiert und analysiert betriebliche Anforderungen und Anfor-derungen der Stakeholder und definiert, analysiert und modelliert auch Lösungs-Designs. Er definiert die Anforderungen in dem Detaillierungsgrad, der für dasLösungs-Design erforderlich ist und als Input für die technischen Designs dient.Diese Ausarbeitung umfasst sowohl funktionale Anforderungen als auch nicht-funktionale Anforderungen. Es gibt Change-Vorhaben, in denen die nicht-funk-tionalen Anforderungen alle Unternehmensziele beinhalten, die mit dem Changeverfolgt werden.

Der Business-Analyst vertraut das technische Design für Software-Lösungenhäufig anderen am Change beteiligten Akteuren an. Oft ist ein Systemarchitekt,Programmierer, Datenbankmanager, oder anderer technischer Experte erforderlich,um zu bestimmen, welche Technologie einzusetzen ist, um ein Set an Anforde-rungen zu erfüllen. Der IT-Business-Analysten definiert Prozessschritte, Geschäfts-regeln, Bildschirmabfolgen und Berichts-Layouts. Die Definition von Anforde-rungen einschließlich der detaillierten Funktionalität eines Systems, eines Unter-nehmens und die Definition der Prozesse im System ist ein Kernbestandteil desLösungs-Designs und trennt nicht in Analyse und Design.

In einer Anforderungsanalyse kann der IT-Business-Analyst gemeinsam mit einemanderen, auf andere Gebiete spezialisierten Business-Analysten zusammenarbeiten,beispielsweise mit einem Business-Analysten mit betriebswirtschaftlichem Schwer-


477

punkt oder einem Unternehmensarchitekten. So kann sichergestellt werden, dassdie IT-Anforderungen auf die Unternehmensstrategie ausgerichtet werden.

Zu einer Anforderungsanalyse und Design-Definition gehört häufig auch dieDokumentation der Anforderungen in Wort und Bild. In einigen Fällen könnenAnforderungen auch anders dargestellt werden, z.B. als Machbarkeitsnachweis,als einsatzbereiter Software-Prototyp oder als Simulation. In allen Fällen hat derBusiness-Analyst die Aufgabe, eine ausreichend detaillierte Dokumentation vor-zulegen, so dass

• der Betrieb die Anforderungen verifizieren und validieren kann• die Entwickler daraus das Design erstellen können• die Tester die Lösung beurteilen können, bevor sie produktiv eingesetzt wird.


• Analyse der Geschäftsregeln • Analyse nicht-funktionaler (Kap.10.9) Anforderungen (Kap.10.30)

• Data Dictionary (Kap.10.12) • Datenflussdiagramme (Kap.10.13)• Datenmodellierung (Kap.10.15) • Dokumentenanalyse (Kap.10.18)• Entscheidungsanalyse (Kap.10.16) • Entscheidungsmodellierung (Kap.10.17)• Funktionale Gliederung (Kap.10.22) •Glossar (Kap.10.23)• Organisationsmodellierung (Kap.10.32) • Prozessmodellierung (Kap.10.35)• Prototyping (Kap.10.36) • Reviews (Kap.10.37)• Rollen- und • Schnittstellenanalyse (Kap.10.24)Zuständigkeitsmatrix (Kap.10.39)

• Scope-Modellierung (Kap.10.41) • Sequenzdiagramme (Kap.10.42)• Umfrage oder Fragebogen (Kap.10.45) • Use Cases und Szenarien (Kap.10.47)• User Stories (Kap.10.48)

.6 LösungsbewertungDie Lösungsbewertung konzentriert sich auf die Lösungskomponenten undderen Nutzen. In einem IT-Kontext schließt dieses den Fokus auf die Interaktionenzwischen verschiedenen Systemen sowohl innerhalb des Change als auch desUmfelds mit ein. Es ist für den im IT-Bereich tätigen Business-Analysten wichtig,den Kontext einer Lösung zu verstehen und zu erkennen, wie ein System oderProzess andere Systeme innerhalb des Umfelds beeinflusst. Diese Auswirkungenkönnen den Nutzen anderer System positiv oder negativ beeinflussen und soAuswirkungen auf den Gesamtnutzen einer Änderung haben.

Ein Aspekt der Lösungsbewertung in einem IT-Kontext ist der Software-Test oderder Lösungstest. Tests oder Qualitätssicherung stellen sicher, dass die Lösung


478

dem Entwurf oder der Vorhersage entsprechend funktioniert und dass sie denbetrieblichen Bedarf oder den Bedarf der Stakeholder abdeckt, die die Änderungeingefordert haben. Der Business-Analyst arbeitet mit Experten für Qualitäts-management und Tests zusammen, damit die technischen Lösungen den alsAnforderungen definierten betrieblichen Bedarf erfüllen und die anderen erfor-derlichen Lieferobjekte bereitgestellt werden. Tester nutzen Testmethoden, umTests zu planen, zu entwickeln und durchzuführen. Ein Lösungstest fokussiertim Allgemeinen auf den Test des Gesamtprozesses, inklusive systemübergreifenderTests, um sicherzustellen, dass die Qualität der Lösung umfassend gewährleistetist. Der Business-Analyst arbeitet mit den Stakeholdern bei der Planung, Ent-wicklung und Umsetzung der Tests zusammen, um sicherzustellen, dass dieLösung die Bedürfnisse der Benutzer erfüllt.

Der Business-Analyst schafft die Voraussetzung dafür, dass er selbst die Gründefür die Umsetzung einer IT-Lösung kennt und weiß, wie die Lösung Nutzenschafft. Die Nutzensteigerung wird üblicherweise aus der besseren Unterstützungder Geschäftsprozesse abgeleitet.

Geschäftliche und technische Ziele sind mit Nutzen und Wertschöpfung verknüpft.Nutzen und Wertschöpfung werden anhand vorher festgelegter Kennzahlenermittelt. Anforderungen sollten sich auf ihre Ziele rückführen lassen. DieseRückverfolgbarkeit bietet eine Basis für die Bewertung der Lösung. Die Analyseder Leistung einer Lösung stellt die technischen Systeme in den Mittelpunktund zeigt auf, wie diese potentiellen oder tatsächlichen Mehrwert für die Stake-holder erzeugen.

Wenn zu einem umfassenden Change ein IT-Element gehört, kann eine Bewertungder IT-Lösung dazu beitragen, einen umfassenderen Nutzen oder Mehrwert ausdem gesamten Vorhaben zu realisieren.

Bei der Evaluierung einer Lösung kann der Business-Analyst mit einem TeamAufgaben übernehmen, zum Beispiel die Einschätzung der Nachteile/Grenzeneiner Lösung und die Beurteilung der Auswirkungen dieser Nachteile. Der Busi-ness-Analyst kann entweder für einen Teil oder für die gesamte entwickelteLösung die technischen Tests unterstützen und bewerten.


• Akzeptanz- und • Anbieter-Assessment (Kap.10.49)Bewertungskriterien (Kap.10.1)

• Item Tracking (Kap.10.26) • Entscheidungsanalyse (Kap.10.16)• Kennzahlen und Key • Organisationsmodellierung Performance-Indikatoren (Kap.10.28) (Kap.10.32)

• Prozessmodellierung (Kap.10.35) • Risikoanalyse und -management (Kap.10.38)

• Schätzungen (Kap.10.19) • SWOT-Analyse (Kap.10.46)


479

Die Geschäftsarchitektur-PerspektiveDie Geschäftsarchitektur-Perspektive zeigt die Besonderheiten für die Business-Analyse im Zusammenhang mit der Geschäftsarchitektur. Die Geschäftsarchitekturmodelliert ein Unternehmen, um zu zeigen, wie die strategischen Anliegen derwichtigsten Stakeholder erfüllt werden, und um die Aktivitäten der Weiterent-wicklung von Unternehmen zu unterstützen.

Die Geschäftsarchitektur liefert Beschreibungen der Architektur und als „Blue-prints“ bezeichnete Sichten, die ein einheitliches Unternehmensverständnisschaffen sollen, um die strategischen Ziele mit den taktischen Notwendigkeitenin Einklang zu bringen. Die Geschäftsarchitektur als Disziplin nutzt analytischesDenken und Architekturprinzipen auf der Ebene des Gesamtunternehmens. DieLösungen betreffen Änderungen im Geschäftsmodell, im Betriebsmodell oder inder Organisationsstruktur und können wiederum andere Vorhaben anstoßen.

Die Geschäftsarchitektur folgt einigen grundlegenden Prinzipien:• Scope: Die Geschäftsarchitektur bezieht sich auf das Gesamtunter-nehmen. Es geht nicht um ein einzelnes Projekt, ein einzelnes Vor-haben, einen einzelnen Prozess oder einzelne Informationen. Die Geschäftsarchitektur stellt Projekte, Prozesse und Information in einen größeren betrieblichen Zusammenhang, um Interaktionen, Integrati-onschancen, Doppelgleisigkeiten und Inkonsistenzen zu erkennen.

• Trennung von Sachverhalten: Die Geschäftsarchitektur betrachtet Sachverhalte isoliert, die eigentlich zusammenhängen. Besonders wird nach den folgenden Merkmalen unterschieden: • die vom Unternehmen genutzte Information• wie das Unternehmen handelt• wer handelt und wo im Unternehmen gehandelt wird• wann etwas getan wird• warum etwas getan wird• wie gut es getan wird.

Sobald die voneinander unabhängigen Sachverhalte identifiziert sind, können sie in bestimmten Kombinationen oder Mappings zusam-mengefasst werden, um die beabsichtigten betrieblichen Vorhaben zu analysieren.

• Szenario-getrieben: Für ein Unternehmen stellen sich viele unterschied-liche Fragen, wenn eine Vorlage oder ein Entwurf für eine Anpassung benötigt wird. Für jede dieser unterschiedlichen Fragen oder Unterneh-mensszenarien wird jeweils ein anderes Set an Vorlagen oder Entwür-fen benötigt, mit spezifischen Informationen und Beziehungen, mit unterschiedlichen Arten von Ergebnissen und Kennzahlen für den Erfolg.

PerspektivenDie Geschäftsarchitektur-Perspektive

480

11.4

• Wissensbasiert: Während die Beantwortung dieser Fragen das Hauptziel der Geschäftsarchitektur ist, besteht ein weiteres, nicht unwichtiges Ziel darin, die verschiedenen Architekturkomponenten zu sammeln (was, wie, wer, warum etc.) und deren Beziehungen in einem Wissensspeicher zu katalogisieren, so dass sie schnell und einfach zur Beantwortung der nächsten offenen Fragen genutzt werden können. Der Wissensspeicher ist oft ein formales Architektur-Repository.


.1 Breite des ChangeAktivitäten der Geschäftsarchitektur können

• unternehmensweit• in einer einzelnen Geschäftseinheit des Unternehmens (Definition der Architektur eines der Geschäftsmodelle des Unternehmens)

• für eine einzige funktionale Einheit

durchgeführt werden.

Bei der Geschäftsarchitektur wird normalerweise das Gesamtunternehmenbetrachtet, es kann sich aber auch auf eine autonome Geschäftseinheit innerhalbeines Unternehmens beziehen. Ein weiter Scope ist auf jeden Fall notwendig,damit Konsistenz auf der Ebene des Gesamtunternehmens gewährleistet unddie Integration gesteuert werden kann. Beispielsweise kann mithilfe der Geschäfts-architektur eine Situation verdeutlicht werden, in der die gleiche Fähigkeit inverschiedenen Prozessen und Organisationseinheiten eines Unternehmens vor-handen ist, und wenn verschiedene Prozesse und Unternehmenseinheiten unter-schiedliche Informationsmodelle nutzen. Die Betrachtung des gesamten Unter-nehmens schafft einen guten Überblick. Damit kann beurteilt werden, ob diestrategischen Ziele mit der bestehenden Organisationstruktur am besten erreichtwerden können.

.2 Tiefe des ChangeAktivitäten der Geschäftsarchitektur können sich auf die Topmanagement-Ebenekonzentrieren, um strategische Entscheidungen zu erleichtern, oder auf die Ebenedes mittleren Managements, um die Umsetzung von Vorhaben zu unterstützen.

Obwohl die Geschäftsarchitektur wichtige Informationen zum Kontext liefert,wird sie normalerweise nicht auf der operativen Ebene oder bei Entscheidungenzu Prozessen genutzt. Bei operativen Prozessen wird sie erst ab der Ebene einesWertstroms genutzt, um den Prozess zu bewerten.

Perspektiven Die Geschäftsarchitektur-Perspektive

481

11.4.1

.3 Nutzen und umgesetzte LösungenDie Geschäftsarchitektur wendet das Prinzip der Trennung von Sichten an, umjeweils spezielle Modelle zu entwickeln, in denen das Geschäftsmodell, eineLösung oder das Unternehmen in einzelne Sachverhalte mit spezifischen Funk-tionen aufgeteilt wird. Sie zeigt auch die Interaktionen zwischen den isoliertenModellen.

Zu den Elementen der Modelle der Geschäftsarchitektur gehören• Fähigkeiten • Nutzen• Prozesse• Informationen und Daten• Organisation• Berichtswesen und Management• Stakeholder• Sicherheitsstrategien• Ergebnisse.

Architekturmodelle ermöglichen es Unternehmen, einen Überblick über den zuanalysierenden Gegenstand zu gewinnen. Sie liefern Einsichten in die wichtigenTeile eines Unternehmens oder eines Software-Systems, zeigen auf, wie diesezusammenpassen und arbeiten die für den Erfolg wichtigsten Komponentenoder Fähigkeiten heraus.

Die Einsichten der Geschäftsarchitektur können helfen, Systeme und Operationenin einer kohärenten und nützlichen Weise am Laufen zu halten. BetrieblicheEntscheidungen werden besser nachvollziehbar. Wenn eine Änderung angedachtwird, liefert die Architektur Details über die wichtigsten von der Änderungbetroffenen Elemente, was die Priorisierung und Ressourcenzuordnung erleichtert.Da ein Architekturmodell auch aufzeigt, wie die Teile zusammenpassen, kannes auch zur Wirkungsanalyse verwendet werden, um deutlich zu machen, welcheanderen Elemente des Systems oder Geschäfts von einem Change betroffensein werden.

Die Architektur selbst kann als Hilfsmittel dazu dienen, notwendige Änderungenaufzudecken. Die Leistungskennzahlen jedes Architekturelements können über-wacht und bewertet werden, um Leistungsdefizite festzustellen. Die Bedeutungjedes Elements kann mit der Leistung des Unternehmens oder des Gesamtsystemsverglichen werden. Dies unterstützt die Entscheider bei der Festlegung, woInvestitionen notwendig sind und welche Prioritäten diesen Entscheidungenzugewiesen werden.

Die Geschäftsarchitektur dient dazu, koordinierte und synchronisierte Handlungenin einem Unternehmen zu erleichtern, indem die Handlungen mit der Unter-


482

nehmensvision, den Unternehmenszielen und der Strategie abgestimmt werden.Die in diesem Prozess geschaffenen Architekturmodelle dienen als Werkzeuge,um die hinter der Vision stehende Absicht, die Ziele und die Strategie zu klären,zu vereinheitlichen und zu verstehen. Sie stellen auch sicher, dass die Ressourcenfokussiert dort eingesetzt werden, wo sie dem Unternehmen den größten Nutzenbringen.

Die Geschäftsarchitektur liefert eine Vorlage, die das Management nutzen kann,um Strategien sowohl für Informationstechnologie- (IT) und Nicht-IT-Perspektivenzu planen und umzusetzen. Die Geschäftsarchitektur wird von Unternehmenzur Steuerung folgender Anliegen eingesetzt:

• Strategische Planung• Neugestaltung des Geschäftsmodells • Reorganisation des Unternehmens • Leistungsmessung und andere Vorhaben zur Verbesserung der Kundenbindung

• Verbesserung der Produktion• Kostensenkung• Formalisierung des Wissens im Unternehmen • Schaffung eines Mediums zur Kommunikation der betrieblichen Vision.

.4 UmsetzungsansatzDie Geschäftsarchitektur schafft ein Framework für die Planung, die Klarheitund Einblick in das Unternehmen bietet und die Entscheider unterstützt, not-wendige Änderungen zu finden. Die Blueprints der Geschäftsarchitektur förderndie Erkenntnis, dafür, wie gut ein Unternehmen seine Organisation auf die Stra-tegie abgestimmt hat. Daraus lassen sich Änderungsvorhaben und andere Pla-nungsaktivitäten ableiten.

Die Teilpläne der Geschäftsarchitektur können definieren • den Ist-Zustand• den Soll-Zustand• einen oder mehrere Übergangszustände zum Soll-Zustand.

Geschäftsarchitekten müssen das Gesamtunternehmen ganzheitlich betrachten.Im Allgemeinen berichten sie direkt an ein Mitglied des Topmanagements.Geschäftsarchitekten benötigen ein breites Wissen über die Funktionsweise einesUnternehmens, insbesondere über

• Umwelt- und Branchentrends• Struktur und Berichtslinien

• Wertschöpfungsströme


483

• Fähigkeiten• Prozesse • Informations- und Datenquellen und -speicher• das Zusammenspiel dieser Elemente, um die Strategie eines Unternehmens zu unterstützen.

Geschäftsarchitekten spielen eine wichtige Rolle bei der Kommunikation undErneuerung einer Strategie eines Unternehmens. Sie nutzen Blueprints, Modelleund Einsichten der Geschäftsarchitektur, um für die Strategie eines Unternehmenszu werben und die individuellen Stakeholder-Bedürfnisse auf die Ziele des Unter-nehmens auszurichten.

Mehrere Faktoren sind für eine erfolgreiche Geschäftsarchitektur zentral wichtig:• Unterstützung durch das Topmanagement• Integration in klare und effektive Governance-Prozesse, einschließlich der Verbindungen zu den betrieblichen Entscheidungsträgern (die beispielsweise für Investitionen, Projekte und Infrastrukturentscheidun-gen zuständig sind)

• Integration in laufende Vorhaben (das kann die Mitwirkung in Len-kungsausschüssen oder anderen beratenden Gremien bedeuten)

• Zugang zu leitenden Führungskräften, Abteilungsleitern, Produkteig-nern/Produktverantwortlichen, Lösungsarchitekten, Business-Analystenund Projektmanagern.

.5 Zentrale AnnahmenUm die Geschäftsarchitektur für ein Unternehmen nutzbar zu machen, benötigtder Business-Analyst

• eine Sicht auf das gesamte zu analysierende Unternehmen• volle Unterstützung durch das Topmanagement• Mitwirkung der Bereichsleiter und der Fachexperten• eine gelebte Unternehmensstrategie• ein geschäftliches Anliegen, das bearbeitet werden muss.


.1 Auftraggeber des Change Idealerweise ist ein Mitglied des Topmanagements oder der Geschäftsleitungder Auftraggeber eines Geschäftsarchitektur-Vorhabens. Jedoch kann auch derChef einer Sparte Auftraggeber sein.


484

11.4.2

.2 Zielobjekte des Change Die folgende Liste zeigt wesentliche Änderungsvorhaben, die sich aus einerAnalyse der Geschäftsarchitektur ergeben können:

• betriebliche Fähigkeiten• betriebliche Wertströme• Investitionsentscheidungen• Portfolio-Entscheidungen.

Die folgenden Personengruppen nutzen Ergebnisse der Geschäftsarchitektur zurSteuerung von Change-Vorhaben:

• Management auf allen Hierarchiestufen• Produkt- oder Service-Verantwortliche• Operative Einheiten• Lösungsarchitekten• Projektmanager • Business-Analysten, die in anderen Kontexten arbeiten (beispielsweise auf Projektebene).

.3 Die Rolle des Business-AnalystenZiel des im Bereich Geschäftsarchitektur tätigen Business-Analysten ist es,

• den gesamten Kontext des Unternehmens zu verstehen und ausgewo-gene Einsichten zu allen Elementen und ihren Beziehungen innerhalb des Unternehmens zu liefern

• eine gesamtheitliche, verständliche Übersicht über alle Sonderheiten des Unternehmens zu liefern.

Die Geschäftsarchitektur bietet eine Vielzahl von Unternehmensmodellen. DieseModelle oder Blueprints liefern ganzheitliche Einsichten in das Unternehmen,die dem Management des Unternehmens als Grundlage für strategische Ent-scheidungen dienen. Um eine Geschäftsarchitektur zu entwickeln, muss derBusiness-Analyst eine breite Palette an strategisch bedeutsamen Sachverhaltenverstehen, aufnehmen und zueinander in Bezug setzen. Dabei benötigt derBusiness-Analyst Einblicke, Fähigkeiten und Wissen zu folgenden Gebieten:

• Unternehmensstrategie und -ziele• wesentliche Informationen über das Unternehmen • IT-Architektur des Unternehmens• Prozessarchitektur • Betriebliche Performance und Struktur der Business Intelligence.

Geschäftsarchitektur unterstützt die strategischen Beratungs- und Planungsgre-mien bei der Steuerung und Entscheidungsfindung in Change-Vorhaben. Die


485

Geschäftsarchitektur zeigt auf, wie gut Entscheidungen auf die strategischenZiele des Unternehmens ausgerichtet sind und hilft bei der Steuerung. DieGeschäftsarchitektur sichert diese Ausrichtung auch während der verschiedenenÜbergangsphasen einer Änderung zu ihrem Soll-Zustand.

.4 Ergebnisse der Business-Analyse Die Geschäftsarchitektur liefert für die Business-Analyse ein umfassendes Bildund eine gesamtheitliche Sicht. Zu den Ergebnissen der Geschäftsarchitekturgehören:

• die Ausrichtung des Unternehmens auf seine Strategie• die Planung des Change als Folge der Strategie• die Gewährleistung, dass bei der Umsetzung des Change die Aus-richtung auf die Strategie beibehalten wird.

Diese Ergebnisse der Geschäftsarchitektur bilden den Kontext für die Anforde-rungsanalyse, für Planung und Priorisierung, für Bewertung und Systemdesignauf einem hohem Aggregationsgrad. Sie fördern das Verständnis und die Aus-richtung auf die Strategie, auf die Bedürfnisse der Stakeholder und auf diebetrieblichen Fähigkeiten. Architektonische Sichten und Blueprints liefern präzi-sierte Informationen, die sonst Annahmen geblieben wären. Sie minimieren dasRisiko von Doppelarbeiten, wenn Fähigkeiten, Systeme und Informationssamm-lungen aufgebaut werden sollen, die bereits an anderer Stelle im Unternehmenvorhanden sind.

Die von der Geschäftsarchitektur entwickelten Modelle und Blueprints sind diewesentlichen Ergebnisse. Dazu gehören unter anderem:

• Landkarten der betrieblichen Fähigkeiten• Abbildungen der Wertstromanalyse• Unternehmenslandkarten • Konzepte des betrieblichen Informationssystems • Prozessarchitektur auf hohem Aggregationsgrad • Modelle zur Entwicklung, zur Kommunikation und zum Management von Geschäftsplänen.

Referenzmodelle und Techniken

.1 ReferenzmodelleReferenzmodelle sind vordefinierte Architekturvorlagen, die für eine bestimmteBranche oder für Funktionen, die es üblicherweise in verschiedenen Branchengibt (wie beispielsweise IT oder Finanzen), eine oder mehrere Sichten bereitstellen.


486

11.4.3

Referenzmodelle werden oft als eine Standard-Architektur für eine Branche oderFunktion angesehen. Sie liefern eine Basisarchitektur als Startpunkt, die derBusiness-Architekt an den Bedarf des eigenen Unternehmens anpassen kann.

Die folgende Tabelle listet einige der bekanntesten Referenzmodelle auf.

Tabelle 11.4.1: Referenzmodelle der Geschäftsarchitektur

.2 TechnikenDie folgende Tabelle zeigt Techniken, die in der Geschäftsarchitektur häufig ein-gesetzt werden und die nicht bereits im Technikkapitel des BABOK®-Leitfadensbeschrieben wurden.


487

Referenzmodell Domäne

Association for Cooperative Opera-tions Research and Development(ACORD)

Versicherungen und Finanzunternehmen

Business Motivation Model (BMM) Generisches Modell

Control Objectives for IT (COBIT) IT-Governance und IT-Management

eTOM und FRAMEWORX Telekommunikation

Federal Enterprise ArchitectureService Reference Model (FEASRM)

Öffentliche Verwaltung (entwickelt für die US-Regierung)

Information TechnologyInfrastructure Library (ITIL®)

IT-Servicemanagement

Process Classification Framework(PCF)

Verschiedene Branchen wie Luftfahrtindustrie,Verteidigungsindustrie, Automobilindustrie,Bildungsindustrie, Energieerzeugung, Erdölin-dustrie, Pharma und Telekommunikation

Supply Chain Operations Reference(SCOR)

Supply Chain Management

Value Reference Model (VRM) Management von Wertschöpfungsketten

Tabelle 11.4.2: Techniken der Geschäftsarchitektur


488

Technik Beschreibung

Archimate® Offene Standard-Modellierungssprache

Business Motivation Model (BMM) Formalisierung der Unternehmensmotivationunter den Begriffen Mission, Vision, Strate-gien, Taktiken, Ziele, Richtlinien, Regeln undAkteure

Architektur der Geschäftsprozesse Prozessmodellierung inklusive der Schnittstel-len als ein Mittel, um eine ganzheitliche Sichtvon Prozessen innerhalb eines Unternehmenszu schaffen

Capability Map Hierarchischer Katalog der Fähigkeiten oderder Aktivitäten eines Unternehmens. Fähigkei-ten werden in strategische, Kern- und unter-stützende Fähigkeiten eingeteilt.

Customer Journey Map Customer Journey („Die Reise des Kunden“)ist ein Modell zur Darstellung des Wegs, denein Kunde von den verschiedenen Berüh-rungspunkten und den verschiedenen Stake-holdern im Rahmen einer Dienstleistung oderinnerhalb Unternehmens nimmt. CustomerJourney Maps werden oft zur Analyse undzum Design des Kundenerlebnisses eingesetzt.

Enterprise Core Diagram Modelliert die Integration und Standardisie-rung eines Unternehmens.

Information Map Katalog der wichtigen Geschäftskonzepte(fundamentale betriebliche Entitäten) in Ver-bindung mit den betrieblichen Fähigkeitenund der Wertschöpfung. Dies wird normaler-weise gemeinsam mit dem Fähigkeitsmodellentwickelt und stellt das gemeinsame betrieb-liche Vokabular des Unternehmens dar. Er istkein Datenmodell, sondern vielmehr eineTaxonomie des Geschäfts.

Organizational Map Modell, das die Beziehungen der Geschäfts-einheiten untereinander, zu externen Partnernund zu Fähigkeiten und Informationen dar-stellt. Im Gegensatz zu einem klassischenOrganigramm ist das Modell auf die Bezie-hungen zwischen den Einheiten fokussiert,nicht auf die Hierarchie.

Tabelle 11.4.2: Techniken der Geschäftsarchitektur (Fortsetzung)


489

Technik Beschreibung

Analyse des Projektportfolios Wird eingesetzt, um Programme, Projekte undPortfolios zu modellieren, mit dem Ziel, eineganzheitliche Sicht der Vorhaben eines Unter-nehmens zu bekommen.

Roadmap Modelliert die notwendigen Handlungen,Abhängigkeiten und Verantwortlichkeiten, umvom Ist-Zustand über Übergangsstadien zumSoll-Zustand zu gelangen.

Service-orientierte Analyse Wird eingesetzt, um die Analyse, das Designund die Architektur von Systemen und Soft-ware zu modellieren, mit dem Ziel, eine ganz-heitliche Sicht der IT-Infrastruktur eines Unter-nehmens zu schaffen.

The Open Group ArchitectureFramework (TOGAF®)

Liefert eine Methode, um eine Unternehmens-architektur zu entwickeln. Die Phase B derTOGAF® Architecture Development Method(ADM) fokussiert auf die Entwicklung derGeschäftsarchitektur. Unternehmen, dieTOGAF® einsetzen, können die Phase B indivi-duell gestalten, indem sie die im BABOK®-Leit-faden beschriebenen Geschäftsarchitektur Blue-prints, Techniken und Referenzen verwenden.

Value Mapping (Wertstromanalyse) Die Wertstromanalyse liefert ein ganzheitli-ches Bild der notwendigen wertschöpfendenAktivitäten. Mit ihr werden Verbesserungspo-tenziale in einem End-to-End-Prozess erkannt.Es gibt verschiedene Arten der Wertstromana-lyse. Ein Wertstrom ist ein häufig eingesetztesKonzept in der Geschäftsarchitektur.

Zachman Framework Liefert eine Ontologie der Grundbegriffe einesUnternehmens, die aus einer Matrix von sechsFragewörtern abgeleitet wird (was, wie, wo,wer, wann, warum), und sechs Abstraktions-ebenen (executive, business management,architect, engineer, technician, enterprise). FürGeschäftsarchitekten kann es sinnvoll sein, dieTopmanagement- oder Geschäftsmanage-ment-Perspektiven hinsichtlich der verschiede-nen Fragewörter abzuklären, um so Klarheitund ein tieferes Verständnis zu gewinnen.

Basiskompetenzen

Zusätzlich zu den anderen Basiskompetenzen benötigt der im Bereich Geschäfts-architektur tätige Business-Analyst folgende Kompetenzen:

• hohe Toleranz für Mehrdeutigkeiten und Unsicherheit• Fähigkeit, Dinge in einen weiteren Kontext zu stellen• Fähigkeit, Anforderungen und Kontext in ein Konzept oder das Designeiner Lösung zu überführen

• Fähigkeit, unnötige Details wegzulassen, um höher aggregierte Sich-ten darstellen zu können

• Fähigkeit, in langfristigen Zeiträumen von mehreren Jahren denken zu können

• Fähigkeit, taktische Ergebnisse zu liefern (kurzfristig), die sofort Nutzen stiften und gleichzeitig die (langfristige) Geschäftsstrategie unterstützen

• gepflegte Umgangsformen bei der Zusammenarbeit mit Top-managern

• Fähigkeit, verschiedene Szenarien und Ergebnisse in Betracht zu ziehen

• Fähigkeit, zu führen und Veränderungen in Unternehmen umzusetzen• Gespür für die politische Situation im Unternehmen.


Dieser Abschnitt erklärt, in welcher Beziehung spezifische Praktiken der Busi-ness-Analyse, die in der Geschäftsarchitektur wahrgenommen werden, zu denim BABOK®-Leitfaden definierten Aufgaben und Praktiken der Business-Analysestehen. Es wird gezeigt, wie jedes Wissensgebiet der Business-Analyse im Rahmender Geschäftsarchitektur angewandt oder durch die Geschäftsarchitektur ver-ändert wird.

Zu jedem Wissensgebiet werden die relevanten Techniken für die Geschäfts-archi-tektur-Perspektive aufgelistet. Techniken des BABOK®-Leitfadens sind im Technik-kapitel aufgeführt. Die weiteren hier genannten Techniken der Business-Analyse,die in diesem Leitfaden nicht in Kapitel 10 behandelt werden, gelten als besonderswertvoll für den Business-Analysten, der im Bereich Geschäftsarchitektur tätig ist.Diese Liste an Techniken erhebt keinen Anspruch auf Vollständigkeit.

.1 Planung und Überwachung der Business-Analyse Für die Planung und Überwachung der Business-Analyse ist es aus Sicht derGeschäftsarchitektur notwendig, dass der Business-Analyst folgende Elementeeines Unternehmens versteht:


490

11.4.4

11.4.5

• Strategie und Ausrichtung• Geschäftsmodell und Leistungsversprechen• Aktuelle betriebliche und operative Fähigkeiten• Stakeholder und deren Berührungspunkte• Wachstumspläne, Governance und Planungsprozesse• Kultur und Umfeld• Bereitschaft und Fähigkeit zum Change.

Sobald dem Business-Analysten diese Elemente bekannt sind, kann er das not-wendige Verständnis dafür entwickeln, welche Architektursichten für eine Analyserelevant sind.

Die Planung der Governance und die Überwachung fokussieren vor allem auf• die Auswahl, welche Projekte oder Vorhaben den größten Nutzen für die Unternehmensstrategie und die Ergebnisse haben werden

• die Ermittlung, welche Bezugsrahmen/Frameworks oder Modelle bestehen oder innerhalb des Unternehmens eingesetzt werden.



• Brainstorming (Kap.10.5) • Betriebliche Fähigkeitsanalyse (Kap.10.6)• Entscheidungsanalyse (Kap.10.16) • Funktionale Gliederung (Kap.10.22)• Interviews (Kap.10.25) • Item Tracking (Kap.10.26)• Kennzahlen und Key- •Organisationsmodellierung Performance-Indikatoren (Kap.10.32)(Kap.10.28)

• Prozessmodellierung (Kap.10.35) • Reviews (Kap.10.37)• Risikoanalyse und • Rollen- und Zuständig--management (Kap.10.38) keitsmatrix (Kap.10.39)

• Schätzung (Kap.10.19) • Scope-Modellierung (Kap.10.41)• Stakeholder-Listen, -Karten • Umfrage oder Fragebogenoder Personas (Kap.10.43) (Kap.10.45)

• Ursachenanalyse (Kap.10.40) • Use Cases und Szenarien (Kap.10.47)

Weitere Techniken der Business-Analyse

• Capability Map •Geschäftsprozessarchitektur

• Projektportfolio-Analyse • Service-orientierte Analyse


491

.2 Erhebung und Zusammenarbeit Der im Bereich Geschäftsarchitektur tätige Business-Analyst ist üblicherweisevielen Mehrdeutigkeiten und großer Unsicherheit ausgesetzt. Bei Aufgaben derErhebung und Zusammenarbeit berücksichtigt der Business-Analyst betrieblicheKursänderungen, die durch interne und externe Kräfte und Veränderungen imMarkt angetrieben werden. Die Art der Änderung kann häufig vorhergesagtwerden, der externe Marktdruck macht jedoch die Änderungsgeschwindigkeitoft unvorhersehbar.

Da die Geschäftsarchitektur viel Input aus dem ganzen Unternehmen benötigt,sind der Zugang zu den Stakeholdern und deren Verfügbarkeit erfolgskritisch.Der Business-Analyst erhebt Informationen, z.B. über die Strategie, Werte, beste-hende Architekturen und Leistungskennzahlen.

Die Anwaltschaft für die Unternehmensstrategie steht im Zentrum der Kommu-nikationsstrategie der Geschäftsarchitekten. Als Teilnehmer in verschiedenenSteuerungs- und Beratungsgremien nutzen Geschäftsarchitekten formale Kom-munikationskanäle in Projekten, Vorhaben und operativen Einheiten, um dieUnternehmensstrategie zu kommunizieren, den Unternehmenskontext zu erklärenund sich für die Ausrichtung auf die Unternehmensstrategie einzusetzen.

Es ist eine unerlässliche Funktion der Geschäftsarchitektur, dafür zu sorgen, dassdie Stakeholder die Unternehmensstrategie verstehen und mittragen. Um sicher-zustellen, dass alle Handlungen auf die Unternehmensstrategie ausgerichtetsind, können Geschäftsarchitekten den Scope eines Projekts oder eines Vorhabensbestimmen und Restriktionen formulieren. Dies kann negativ aufgenommenwerden. Der Geschäftsarchitekt muss dann die Brücke schlagen zwischen denBedürfnissen und Wünschen der einzelnen Stakeholder, Projekten und Funkti-onseinheiten und dem Verständnis des Kontextes sowie der Unternehmenszieleund Strategie. Das Ziel des Geschäftsarchitekten ist es, die Unternehmenszieleund -strategie zu optimieren und Maßnahmen zu verhindern, die dem Gesamt-unternehmen nur suboptimale Ergebnisse bringen. Dies stellt hohe Anforderungensowohl an die Erhebungsaktivitäten als auch an die Zusammenarbeit.

Der Geschäftsarchitekt gewinnt tiefe Einblicke in die Strategie, die Treiber, dieMotivation und Bestrebungen des Unternehmens und der Stakeholder. Auf derGrundlage dieses Verständnisses arbeitet der Geschäftsarchitekt mit allen Hierar-chieebenen des Unternehmens zusammen, vom Topmanagement über das mittlereManagement, das Projektmanagement-Office (PMO), Produkteigner, Projektma-nager, diverse Business-Analysten, Lösungsarchitekten bis hin zu IT-Mitarbeitern,um die Lücken im Verständnis der Strategie zu schließen und alle Maßnahmenauf die Unternehmensstrategie auszurichten. Soll eine effektive Zusammenarbeiterreicht werden, müssen Geschäftsarchitekten viele unterschiedliche Perspektivenund Kontexte, in denen die Stakeholder aktiv sind, verstehen und berücksichtigen.Der Geschäftsarchitekt muss auch mit jedem dieser Stakeholder in einer Sprachekommunizieren können, die von beiden verstanden wird.


492


• Beobachtung (Kap.10.31) • Brainstorming (Kap.10.5)• Dokumentenanalyse (Kap.10.18) • Fokusgruppen (Kap.10.21)• Funktionale Gliederung (Kap.10.22) •Glossar (Kap.10.23)• Interviews (Kap.10.25) • Item Tracking (Kap.10.26)• Prototyping (Kap.10.36) • Schnittstellenanalyse (Kap.10.24)• Stakeholder-Listen, -Karten • Umfrage oder Fragebogen oder Personas (Kap.10.43) (Kap.10.45)



• keine

.3 Management des Anforderungs-LebenszyklusDer mit Geschäftsarchitektur befasste Business-Analyst muss vom Topmanagementunterstützt werden und das Recht haben, die zu bewältigenden Arbeiten zuerledigen. Ein Architektur-Review-Board, das sich aus entscheidungsbefugtenTopmanagern zusammensetzt, kann Änderungen der Geschäftsarchitektur über-prüfen und beurteilen. Dieses Gremium setzt sich häufig auch mit dem Portfo-liomanagement auseinander und entscheidet auf Basis der Auswirkungen aufdas Geschäft und die Strategie über Investitionen und die Priorisierung vonÄnderungsvorhaben.

Der mit Geschäftsarchitektur befasste Business-Analyst versteht den Einfluss derProjekte auf die Geschäftsarchitektur; er erweitert, korrigiert und verbessertkontinuierlich die Geschäftsarchitektur. Er identifiziert auch möglicherweise auf-tauchende Veränderungen interner wie auch externer Faktoren (einschließlichder Veränderungen im Markt) und entscheidet darüber, wie er diese Verände-rungen in der Geschäftsarchitektur des Unternehmens berücksichtigt.


• Balanced Scorecard (Kap.10.3) • Benchmarking und Marktanalyse (Kap.10.4)

• Betriebliche Fähigkeitsanalyse • Datenmodellierung (Kap.10.15)(Kap.10.6)

• Entscheidungsanalyse (Kap.10.16) •Gemeinschaftliche Spiele (Kap.10.10)• Item Tracking (Kap.10.26) • Kennzahlen und Key-

Performance-Indikatoren (Kap.10.28)• Lessons Learned (Kap.10.27) •Organisationsmodellierung (Kap.10.32)• Prozessanalyse (Kap.10.34) • Prozessmodellierung (Kap.10.35)


493

• Reviews (Kap.10.37) • Risikoanalyse und -management (Kap.10.38)

• Rollen- und Zuständigkeits- • Schätzung (Kap.10.19)matrix (Kap.10.39)

• Schnittstellenanalyse (Kap.10.24) • Stakeholder-Listen, -Karten oder Personas (Kap.10.43)

• SWOT-Analyse (Kap.10.46) • Ursachenanalyse (Kap.10.40)


• Archimate® •Geschäftsprozessarchitektur• Unternehmenswert-Modellierung •Capability Map• Enterprise Core Diagram • Projektportfolio-Analyse• Roadmap • Service-orientierte Analyse• Wertstromanalyse

.4 Strategische AnalyseDie Geschäftsarchitektur kann eine bedeutende Rolle in der Strategieanalysespielen. Sie liefert Architektursichten des Ist-Zustands des Unternehmens undhilft bei der Definition sowohl des Soll-Zustands als auch der Übergangszustände,um diesen Soll-Zustand zu erreichen.

Die Geschäftsarchitekten entwickeln Roadmaps, die auf der Change-Strategiedes Unternehmens basieren. Klar definierte Übergangszustände helfen demUnternehmen, kontinuierlich Wert zu schaffen und während aller Phasen desWandels wettbewerbsfähig zu bleiben. Dazu muss ein Unternehmen folgendeFaktoren analysieren:

• Marktbedingungen• Märkte, in denen das Unternehmen aktiv sein soll• Sicherstellung der Wettbewerbsfähigkeit des Unternehmens in der Übergangsphase

• bestmögliche Ausrichtung der Markenpositionierung des Unternehmens.

Die Geschäftsarchitektur liefert Informationen zum Kontext, in dem das Unter-nehmen steht, und Architektursichten, die es leichter machen, das Unternehmenzu verstehen, so dass die relevanten Fragen hinsichtlich Kosten, Chancen undAufwand analysiert werden können.


• Analyse der Geschäftsregeln (Kap.10.9) • Balanced Scorecard (Kap.10.3)• Benchmarking und Marktanalyse • Betriebliche Fähigkeitsanalyse(Kap.10.4) (Kap.10.6)


494

• Brainstorming (Kap.10.5) • Darstellung des Geschäftsmodells(Kap.10.8)

• Datenmodellierung (Kap.10.15) • Dokumentenanalyse (Kap.10.18)• Fokusgruppen (Kap.10.21) •Gemeinschaftliche Spiele (Kap.10.10)• Glossar (Kap.10.23) • Kennzahlen und Key-

Performance-Indikatoren (Kap.10.28)• Organisationsmodellierung (Kap.10.32) • Reviews (Kap.10.37)• Risikoanalyse und • Schätzung (Kap.10.19)-management (Kap.10.38)

• Stakeholder-Listen, -Karten • SWOT-Analyse (Kap.10.46)oder Personas (Kap.10.43)

• Umfrage oder Fragebogen (Kap.10.40) •Workshops (Kap.10.50)


• Archimate® •Geschäftsprozessarchitektur• Capability Map •Customer Journey Map• Enterprise Core Diagram • Projektportfolio-Analyse• Roadmap • Service-orientierte Analyse• Strategie-Landkarte •Wertstromanalyse

.5 Anforderungsanalyse und Design-DefinitionGeschäftsarchitektur liefert mit unterschiedlichen Modellen individuelle Archi-tektursichten eines Unternehmens, die jeweils auf den Bedarf der Stakeholderausgerichtet werden. Diese Architektursichten können Fähigkeiten- und Wert-Landkarten, Organisationslandkarten und Informations- und Geschäftsprozess-modelle sein. Der im Bereich Geschäftsarchitektur tätige Business-Analyst nutztseine Expertise, sein Urteilsvermögen und seine Erfahrung bei der Entscheidung,was bei einem Modell wichtig ist (und was nicht). Modelle sollen den Kontextliefern und solche Informationen, die bessere Ergebnisse der Anforderungsanalyseund des Designs möglich machen.

Der architektonische Kontext und die Möglichkeit, vorhandene Architektursichtenrasch nachzuschlagen, bieten wichtige Informationen. Gäbe es sie nicht, müssteder Analyst mit Annahmen arbeiten. Werden diese Informationen von derGeschäftsarchitektur geliefert, wird das Risiko von Doppelarbeiten beim Aufbauvon Fähigkeiten, Systemen oder Informationen, die bereits anderswo im Unter-nehmen existieren, minimiert.

Das Design entsteht aus dem Verständnis des Bedarfs und der Anforderungen.Die Geschäftsarchitektur liefert relevante Informationen, um die strategischeAusrichtung der vorgeschlagenen Änderungen ebenso zu analysieren wie die


495

wechselseitigen Effekte der Änderungen. Geschäftsarchitekten fassen das Wissenund die Einsichten aus verschiedeneren Architektureinsichten zusammen, umso festzustellen, ob vorgeschlagene Änderungen die Ziele des Unternehmensverfolgen oder zu den Zielen in Konflikt stehen.

Geschäftsarchitektur versucht sicherzustellen, dass das Unternehmen als Ganzesfür die Stakeholder kontinuierlich Wert schafft, sowohl im normalen Geschäfts-gang wie auch während eines Change. Der im Bereich Geschäftsarchitekturtätige Business-Analyst konzentriert sich auf die ganzheitliche Wertschöpfungdes Unternehmens. Er versucht, lokale Optimierungen zu vermeiden, bei denenfür einen Einzelprozess oder für eine einzelne Systemverbesserung Aufwandbetrieben wird und Ressourcen verbraucht werden, die nicht auf die Strategieausgerichtet sind und keinen sinnvollen Beitrag zum Unternehmen als Ganzesleisten- oder sogar suboptimale Lösungen schaffen.


• Akzeptanz- und • Analyse der Geschäftsregeln (Kap.10.9)Bewertungskriterien (Kap.10.1)

• Anbieter-Assessment (Kap.10.49) • Backlog Management (Kap.10.2)• Balanced Scorecard (Kap.10.3) • Beobachtung (Kap.10.31)• Benchmarking und • Betriebliche Fähigkeitsanalyse Marktanalyse (Kap.10.4) (Kap.10.6)

• Brainstorming (Kap.10.5) • Darstellung des Geschäftsmodells (Kap.10.8)

• Data Dictionary (Kap.10.12) • Datenflussdiagramme (Kap.10.13)• Datenmodellierung (Kap.10.15) • Dokumentenanalyse (Kap.10.18)• Entscheidungsanalyse (Kap.10.16) • Fokusgruppen (Kap.10.21)• Funktionale Gliederung (Kap.10.22) •Gemeinschaftliche Spiele (Kap.10.10)• Glossar (Kap.10.23) • Item Tracking (Kap.10.26)• Lessons Learned (Kap.10.27) • Kennzahlen und Key-

Performance-Indikatoren (Kap.10.28)• Analyse nicht-funktionaler • Organisationsmodellierung Anforderungen (Kap.10.30) (Kap.10.32)

• Prozessanalyse (Kap.10.34) • Prozessmodellierung (Kap.10.35)• Prototyping (Kap.10.36) • Reviews (Kap.10.37)• Risikoanalyse und • Rollen und Zuständigkeitsmatrix -management (Kap.10.38) (Kap.10.39)

• Schätzung (Kap.10.19) • Schnittstellenanalyse (Kap.10.24)• Scope-Modellierung (Kap.10.41) • Sequenzdiagramme (Kap.10.42 )• Stakeholder-Listen, -Karten oder Personas (Kap.10.43)


496

• Statusmodellierung (Kap.10.44) • Umfrage oder Fragebogen (Kap.10.45)• SWOT-Analyse (Kap.10.46) • Ursachenanalyse (Kap.10.40)• Use Cases und Szenarien (Kap.10.47) • User Stories (Kap.10.48)• Workshops (Kap.10.50)


• Archimate® •Geschäftsprozessarchitektur• Capability Map •Customer Journey Map• Enterprise Core Diagram • Projektportfolio-Analyse• Roadmap • Service-orientierte Analyse• Wertstromanalyse

.6 LösungsbewertungDie Geschäftsarchitektur stellt grundlegende Fragen zum Geschäft, einschließlichder Frage nach der Performance.

Um diese Frage beantworten zu können, müssen zuerst andere Fragen geklärtwerden:

• Welche Ergebnisse will das Unternehmen, wille es ein bestimmtes Vorhaben oder eine Komponente erreichen?

• Wie können diese Ergebnisse mit dem SMART-Zielkonzept (Specific, Measurable, Achievable, Relevant, Time-bounded) gemessen werden?

• Welche Informationen sind notwendig, um die Zielerreichung zu messen?

• Wie müssen Prozesse, Dienstleistungen, Vorhaben etc. ausgestaltet werden, damit diese Informationen geliefert werden können?

• Wie werden die Informationen über die Leistung am besten präsentiert– als Bericht, Ad hoc-Abfragen, Dashboards etc.?

• Wie werden diese Informationen bei zukünftigen Investitionsentschei-dungen berücksichtigt?

Wenn die Fähigkeiten ermittelt und die Prozessarchitektur festgelegt werdensollen, ist es auf einer detaillierteren Ebene sehr wichtig, die spezifischen Leis-tungsmerkmale und -ergebnisse zu identifizieren, anhand derer die Fähigkeitenoder Prozesse bewertet werden. Die tatsächliche Messung wird selten vom Busi-ness-Analysten selbst durchgeführt. Normalerweise übernehmen dies die Pro-duktverantwortlichen, die operativen Manager oder die IT-Manager.

Der im Bereich Geschäftsarchitektur tätige Business-Analyst analysiert die Ergeb-nisse der Messungen und berücksichtigt diese bei seinen weiteren Planungen.


497



• Beobachtungen (Kap.10.31) • Brainstorming (Kap.10.5)• Betriebliche • Fokusgruppen (Kap.10.21)Fähigkeitsanalyse (Kap.10.6)

• Item Tracking (Kap.10.3126) •Gemeinschaftliche Spiele (Kap.10.10)• Kennzahlen und Key-Performance • Lessons Learned (Kap.10.27)-Indikatoren (Kap.10.28)

• Organisationsmodellierung (Kap.10.32)• Prozessanalyse (Kap.10.34)• Prozessmodellierung (Kap.10.35) • Risikoanalyse und

-management (Kap.10.38)• Rollen- und • Stakeholder-Listen, -Karten oder Zuständigkeitsmatrix (Kap.10.39) Personas (Kap.10.43)

• SWOT-Analyse (Kap.10.46) • Umfrage oder Fragebogen (Kap.10.45)

Weitere Techniken der Business-Analyse-

• Business Motivation Modelling •Geschäftsprozessarchitektur• Capability Map •Customer Journey Map• Service-orientierte Analyse •Wertstromanalyse

Die Business-Process-Management-PerspektiveDie Business-Process-Management-Perspektive unterstreicht die besonderenMerkmale der Business-Analyse im Zusammenhang mit der Entwicklung oderOptimierung von Geschäftsprozessen.

Business Process Management (BPM) ist eine Managementdisziplin, in der aucheine Reihe von Technologien genutzt wird, die

• sich darauf konzentrieren, wie das Unternehmen seine Aufgaben erledigt, um über alle beteiligten Funktionsbereiche hinweg Nutzen fürKunden und Stakeholder zu liefern

• dabei das Unternehmen ganzheitlich betrachtet• das Unternehmen aus prozessorientierter Sicht betrachtet.

Eine BPM-Initiative liefert Nutzen, indem die Art und Weise der Aufgabenerfüllungin einem Unternehmen verbessert wird.

BPM legt fest, wie manuelle und automatisierte Prozesse erstellt, geändert,gelöscht und gesteuert werden. Unternehmen, die auf eine prozessorientierte

PerspektivenDie Business-Process-Management-Perspektive

498

11.5

Sicht bauen, betrachten BPM als dauerhafte Herausforderung und integralenBestandteil des Managements und des laufenden Betriebs des Unternehmens.

11.5.1 Scope des Change-Vorhabens

Der Business-Analyst der BPM-Disziplin kann einen einzelnen abgegrenztenProzess bearbeiten, er kann aber auch alle Prozesse in einem Unternehmenbetrachten. Der Business-Analyst konzentriert sich häufig darauf, wie die Prozesseeines Unternehmens verbessert werden können, um die Ziele zu erreichen.

BPM-Lebenszyklen umfassen im Allgemeinen folgende Aktivitäten:• Gestaltung: Die Identifikation von Prozessen und die Beschreibung des Ist-Zustands und die Festlegung, wie der Prozess in Zukunft aussehen soll. Der Unterschied zwischen diesen Zuständen kann dazu benutzt werden, die Erwartungen der Stakeholder dahingehend zu spezifizie-ren, wie das Unternehmen zukünftig arbeiten sollte.

• Modellierung: Das ist die grafische Prozessdarstellung, in welcher der Prozess im aktuellen Zustand dokumentiert und mit dem zukünfti-gen Zustand verglichen wird. Diese Phase des BPM-Lebenszyklus liefertden Input für die Spezifikation der Anforderungen und für das Lösungs-Design sowie für die Ermittlung des potentiellen Nutzens. In Simulationen kann auch mithilfe quantitativer Daten das Nutzenpoten-tial von Prozessvarianten analysiert und verglichen werden.

• Durchführung und Überwachung: Liefert denselben Input wie die Modellierung, die Daten sind dann allerdings das Ergebnis der tatsäch-lichen Ausführung von Prozessen. Die Daten, die aus den aktuellen Durchläufen von Geschäftsprozessen stammen, sind sehr zuverlässig und objektiv und bieten daher eine sehr gute Grundlage für die Ana-lyse des Nutzens, um damit Alternativen für die Verbesserung empfeh-len zu können.

• Optimierung: Hier werden die eben beschriebenen Schritte laufend wiederholt. Die Ergebnisse der Durchführung und Überwachung der Geschäftsprozesse werden genutzt, um Modelle und Designs zu ändern, damit Ineffizienzen beseitigt werden und der Nutzen gestei-gert wird. Die Optimierung kann eine Quelle von Anforderungen und Lösungsentwürfen sein, die direkt von den Stakeholdern und der User-Community kommen. Die Optimierung von Prozessen ist auch ein guter Weg, um den Wert einer vorgeschlagenen Lösungsmodifikation zu verdeutlichen und Initiativen zur Verbesserung von Prozessen und Produkten zu begründen.

Perspektiven Die Business-Process-Management-Perspektive

499

11.5.1

.1 Breite des ChangeMit einem BPM soll sichergestellt werden, dass der optimierte Nutzen überganzheitliche (End-to-End-)Prozesse erreicht wird. Ein umfassendes BPM-Vorhabenkann sich auf das gesamte Unternehmen erstrecken. Durch ein einzelnes BPM-Vorhaben kann die Prozessorientierung eines Unternehmens erhöht werden,indem sie Einblicke in ihre Prozesse liefert. Die Prozesse eines Unternehmensbeschreiben, was es tut und wie es das tut. Ein umfassendes Verständnis derProzesse macht es den Stakeholdern möglich, diese Prozesse an die sich konti-nuierlich entwickelnden Bedürfnisse des Unternehmens und seiner Kunden anzu-passen. Einzelne Vorhaben können spezifische Prozesse und Unterprozesse ver-bessern. Die Aufteilung größerer, komplexer Prozesse in kleinere Pakete (Teil-prozesse) ermöglicht es dem Business-Analysten, besser zu verstehen, was injedem Prozess geschieht und wie er optimiert werden kann.

.2 Tiefe des ChangeDer Business-Analyst verwendet BPM Frameworks, um die Tätigkeiten der Analysezu unterstützen und die Prozesse des Unternehmens besser zu verstehen. BPMFrameworks sind vorgefertigte Basisprozesse oder Beschreibungen von Prozessenfür eine generische Organisation, eine bestimmte Branche, Fachbereiche oderTypen von Wertströmen. BPM Frameworks definieren spezielle Prozessebenenin der Prozessarchitektur der Organisation.

So führt der Business-Analyst beispielsweise eine Analyse der Supply Chaindurch, um einzelne Prozesse eines Unternehmens zu bewerten. Bei der Analyseder Lieferkette wird häufig zunächst der Gesamtprozess aus Sicht eines Konzernsoder einer Gruppe in einzelne Teilkomponenten zerlegt. Diese werden danachweiter detailliert bis hin zu einzelnen personenbezogenen Aufgaben.

Der Business-Analyst, der am BPM beteiligt ist, ist häufig auch mit der kontinu-ierlichen Verbesserung betraut, denn er ist oft derjenige, der am besten mitdem BPM vertraut sind.

.3 Nutzen und umgesetzte LösungenMit dem BPM sollen die operative Leistung (Effektivität, Effizienz, Anpassbarkeitund Qualität) verbessert und Kosten und Risiken reduziert werden. Der Busi-ness-Analyst sieht häufig die Transparenz der Prozesse und der betrieblichenTätigkeiten als einen wesentlichen Nutzen von BPM-Vorhaben an. Die Transparenzder Prozesse und Tätigkeiten bietet Entscheidungsträgern einen klaren Überblicküber die operativen Folgen von Entscheidungen, durch die bisherige Prozesseverändert werden. Vorhaben der Business-Analyse beginnen häufig mit der Iden-tifizierung des Bedarfs der Kunden. Solche Bedarfe werden im Allgemeinen alsBPM-Treiber bezeichnet.


500

BPM-Treiber sind:• Kostenreduktion• Erhöhung der Qualität• Erhöhung der Produktivität• Aufkommende Konkurrenz• Risikomanagement• Compliance-Initiativen• Nächste Generation der Prozessautomation• Implementierung eines Kernsystems• Innovation und Wachstum• Rationalisierung nach Merger oder Akquisition• Standardisierungsinitiativen• Grundlegende Veränderungen• Einrichtung eines BPM-Kompetenzzentrums• Vermehrte Nutzung agiler Ansätze • Schnellere Prozesse.

.4 Umsetzungsansatz Die Umsetzung für BPM-Vorhaben in Unternehmen reicht von eher taktischenAnsätzen, die sich auf Verbesserungen einzelner Prozesse konzentrieren, bis hinzu einer Management-Disziplin, die alle Prozesse in einem Unternehmen umfasst.Der eigentliche Zweck der Prozesstransformation ist es, den Unternehmen zuhelfen, ihre Geschäftsprozesse zu identifizieren, zu priorisieren und zu optimieren,um damit den Stakeholdern Nutzen zu liefern.

Unternehmen bewerten regelmäßig ihre Kernprozesse und beschäftigen sichmit einer kontinuierlichen Verbesserung, um exzellente Prozessqualität zu erreichenund zu erhalten. Der Erfolg von BPM kann daran gemessen werden, wie gutsich das BPM-Vorhaben an den festgelegten Zielen für das BPM in dem Unter-nehmen ausrichtet.

Es gibt mehrere Ansätze, die für die Einführung des BPM verwendet werdenkönnen:

• Business Process Reengineering: Diese Methoden zielen auf das Redesign der wichtigsten Prozesse des gesamten Unternehmens ab.

• Evolutionäre Formen der Veränderung: Hier gibt es festgelegte Ziele für die übergreifenden Prozesse. Einzelne Änderungen an den Teilpro-zessen werden so ausgerichtet, dass sie mit den Gesamtzielen im Einklang stehen.

• Substantielle Ermittlung: Dieser Ansatz wird genutzt, wenn organisato-rische Prozesse nicht definiert sind oder wenn die dokumentierte


501

Version des Prozesses wesentlich vom tatsächlich gelebten Prozess abweicht. Die Substantielle Ermittlung zeigt die tatsächlichen Prozesse auf und ist eine Methode zur Organisationsanalyse.

• Prozess-Benchmarking: Hier werden die Geschäftsprozesse des Unter-nehmens und deren Performance mit „Best Practices“ der Branche verglichen. Typischerweise werden Qualität, Zeit und Kosten gemessen.

• Spezielle BPMS-Anwendungen: Mit ihrer Hilfe werden BPM-Vorhaben unterstützt. Prozessmodelle können direkt in lauffähige Anwendungenumgesetzt werden. Mit diesen Werkzeugen können die BPM-Aktivitä-ten automatisiert werden.

Ansätze zur Prozessverbesserung können nach ihrem Ausgangspunkt kategorisiertwerden. Sie gehen vom Groben ins Detail oder vom Detail zum Groben bzw.basieren ihre Lösungen in erster Linie auf der Organisation (personenbezogen)oder auf den technologischen Möglichkeiten (IT-basiert).

• Top-down: Vorhaben werden üblicherweise zentral unter Kontrolle desTopmanagements modelliert und haben damit organisationsweite Auswirkungen. Sie sind auf End-to-End-Prozesse oder wesentliche Teiledes (Kern-)Geschäftes ausgerichtet.

• Bottom-up: Es handelt sich üblicherweise um taktische Ansätze zur Verbesserung einzelner Prozesse und Abteilungs-Workflows oder kleinere Teilprozesse des Unternehmens.

• Personenzentriert: Bei diesen Initiativen betreffen die wesentlichen Änderungen die Tätigkeiten und Abläufe der Organisation.

• IT-zentriert: Solche Vorhaben sind häufig auf die Prozessautomation und die Möglichkeiten der IT fokussiert.

.5 Zentrale AnnahmenDie wichtigsten Annahmen aus der BPM-Disziplin sind hier angeführt:

• Die Prozesse werden im Allgemeinen von IT-Systemen unterstützt, die Entwicklung dieser Systeme wird aber von den meisten BPM-Metho-den nicht abgedeckt. Der Business-Analyst kann zusätzliche Anforde-rungen vorschlagen, die auf bestehenden IT-Systemen basieren.

• BPM-Vorhaben werden vom Topmanagement unterstützt. Der Business-Analyst kann hinzugezogen werden, um zusätzliche Anforde-rungen vorzuschlagen, die auf der betrieblichen Strategie basieren.

• BPM-Systeme erfordern ein enges Zusammenspiel mit der Unterneh-mensstrategie, aber die meisten Methoden unterstützen nicht die Strategieentwicklung, sie liegt außerhalb des Horizonts.

• BPM-Vorhaben sind funktionsübergreifend und betrachten End-to-End-Prozesse der Organisation.


502


.1 Auftraggeber des ChangeDie unternehmensweiten BPM-Vorhaben werden in der Regel von Führungs-kräften gestartet und fokussieren auf Nutzen und Ergebnisse aus strategischerSicht. Die so entstandenen strategischen Ziele werden dann den Geschäftspro-zessen zugeordnet, mit denen diese Ziele am ehesten erreicht werden können.

BPM-Vorhaben werden häufig durch eine externe Situation ausgelöst, die einenneuen oder veränderten Bedarf erzeugt. Es werden dann Praktiken der Busi-ness-Analyse angewendet, um einen Business Case für ein solches Vorhaben zuentwickeln.

Prozessverbesserungen werden üblicherweise von einem Prozessmanager initiiertoder zumindest geleitet. Dies gilt für alle Ebenen der Organisation. Der Umfangdes Prozesses oder Teilprozesses hängt üblicherweise von der Befugnis des Pro-zessmanagers ab.

.2 Ziele und Akteure des ChangeDie möglichen primären Veränderungsziele bei einem BPM-Vorhaben sind:

• Kunde: Er ist der zentrale Stakeholder in jedem BPM-Vorhaben. Das Hauptaugenmerk liegt auf dem externen Kunden. Interne Kunden werden ebenfalls berücksichtigt. Da BPM sich von Natur aus auf Kun-den konzentriert, spielt der Kunde immer eine Rolle, um die Effektivi-tät der Prozessänderung zu validieren. Die Einbeziehung der Kunden zu einem frühen Zeitpunkt minimiert das Risiko des Scheiterns. Mit seiner Beteiligung wird sichergestellt, dass die Ziele der Prozessleistungauf die Erwartungen des Kunden ausgerichtet sind.

• Regulierer: In fast jedem BPM-Vorhaben ist der Regulierer ein Stake-holder, da sich für viele Unternehmen immer mehr Anforderungen ausder Compliance und dem Risikomanagement ergeben. Der Regulierer kann beispielsweise ein BPM-Vorhaben auslösen, indem er Gesetze oder andere Vorgaben etwa zu Themen der Sicherheit, Transparenz, Chancengleichheit oder Nichtdiskriminierung erlässt.

• Prozess-Owner: Er ist ein zentraler Stakeholder in jedem BPM-Vor-haben. Er hat die Verantwortung und die Kompetenz, die endgültige Entscheidung zu allen Änderungen zu treffen. Der Prozess-Owner ist auch für die Messung der Prozessleistung verantwortlich.

• Prozessbeteiligte: Das sind Stakeholder, die direkt oder indirekt an demProzess mitwirken oder von ihm betroffen sind. Sie definieren die Aktivitäten des Prozesses. Um sicherzustellen, dass deren Interessen erfüllt werden, werden sie am Prozess-Design beteiligt.


503

11.5.2

• Projektmanager: Er managt das BPM-Vorhaben und ist für die Herbei-führung von Entscheidungen und für das Ergebnis verantwortlich. Der Projektmanager arbeitet mit einem Team zusammen, zu dem auch Prozessanalysten, Prozess-Owner und Prozess-Designer gehören. Der Projektmanager ist für die Planung und Steuerung, das Kommunikati-onsmanagement, das Change Management und für das Risikomana-gement verantwortlich.

• Umsetzungs-Team: Dieses Team setzt das geplante BPM-Vorhaben in funktionierende Geschäftsprozesse um. Für den Erfolg eines BPM-Vor-habens ist es wichtig, dass alle erforderlichen Funktionen eingebundenwerden, die Bedürfnisse der Kunden erfüllen.

.3 Die Rolle des Business-AnalystenDer Business-Analyst, der im Business Process Management arbeitet, kann eineVielzahl von Rollen übernehmen:

• Prozessarchitekt: Er ist verantwortlich für die Modellierung, Analyse, Implementierung, Überwachung und kontinuierliche Verbesserung derGeschäftsprozesse. Der Prozessarchitekt weiß, wie Geschäftsprozesse zu gestalten sind und wie diese Prozesse entweder manuell oder durcheine automatisierte Prozessabwicklung auf einer BPM-Plattform ver-bessert werden können. Prozessarchitekten kümmern sich um das Wissen über den Prozess, die geeignete Methodik und Technologie und holen dazu die benötigten Entscheidungen ein, um die Ziele des Unternehmens zu erreichen. Prozessarchitekten verbessern und trans-formieren Geschäftsprozesse in technisch verbesserte und ausführbare Prozessvorlagen. Abhängig vom jeweiligen Vorhaben können sich Prozessarchitekten auf die organisatorische Prozessverbesserung oder auf den Einsatz der Technologie konzentrieren. Prozessarchitekten sindverantwortlich für die Entwicklung und Pflege von Standards und für die Sammlung und Bereitstellung von Referenzmodellen für Produkte und Dienstleistungen, Geschäftsprozessen, Key-Performance-Indikato-ren (KPIs) und kritischen Erfolgsfaktoren. Prozessarchitekten werden bei der Prozessanalyse und bei der Umsetzung eingesetzt.

• Prozessanalyst/-Designer: Sie besitzen detaillierte Kenntnisse über Prozesse und verfügen dazu über besondere Fähigkeiten. Sie sind Experten für die Dokumentation und für das Prozessdesign in Verbin-dung mit Performance-Trends. Ihnen ist besonders daran gelegen, Geschäftsprozesse zu optimieren, um so die Leistung des Unterneh-mens zu steigern. Dieses Ziel erfordert ein detailliertes Prozessverständ-nis und die notwendigen Analysen für die Prozessoptimierung. Sie analysieren und bewerten den Ist-Zustand der Prozesse, bewerten alternative Optionen des Prozess-Designs und empfehlen Änderungen.


504

• Prozessmodellierer: Er erfasst und dokumentiert Geschäftsprozesse (sowohl im Ist- als auch im Soll-Zustand). Der Prozessmodellierer ist häufig ein Prozessanalyst, der einen Prozess für die Implementierung oder die Unterstützung durch ein IT-System dokumentiert.

Die Rollen des Prozessanalysten/-Designers und des Prozessmodellierers werdenhäufig von derselben Person wahrgenommen.

Abb. 11.5.1: Die Rollen des Business-Analysten in einer BPM-Initiative

.4 Ergebnisse der Business-AnalyseZu den Ergebnissen der Arbeit des Business-Analysten im BPM gehören:

• Modelle von Geschäftsprozessen• Geschäftsregeln• Kennzahlen der Prozessleistung• Betriebliche Entscheidungen• Beurteilung der Prozessleistung.

Modelle von Geschäftsprozessen

Modelle von Geschäftsprozessen beginnen auf der obersten Ebene als End-to-End-Modell des gesamten Prozesses und können im Detail bis zu spezifischenWorkflows modelliert werden. Modelle von Geschäftsprozessen sind sowohl dasErgebnis von Analysen als auch Ausgangspunkt für die Prozessanalyse. Sie werdenunterschieden in Ist-Modelle (aktueller Zustand) und Soll-Modelle (zukünftiger


505

FunktionalerLeiter

Prozess-manager

Belegschaft

Mitarbeiterim Prozess

Business-Analyst

Projekt-manager

Prozess-Projekt-manager

Prozessarchitekt

Prozess-analyst &-designer

Prozess-modellierer

Vorhaben einer Prozessveränderung Laufender Betrieb

Implementierung

ZentralerStakeholder

Prozess-Owner

Zustand). Ein Ist-Modell zeichnet den Prozess, wie er derzeit ohne Verbesserungenfunktioniert. Ein Soll-Modell zeigt, wie der Prozess mit allen Verbesserungsmög-lichkeiten aussehen würde. Die Darstellung des Ist-Zustands bietet die Möglichkeit,eine Investition in den Prozess zu rechtfertigen, da damit die Wirkung der Pro-zessverbesserungen gemessen und Änderungen priorisiert werden können. Trans-itions-Modelle beschreiben, welche Schritte und Zwischenzustände nötig sind,um vom aktuellen Zustand des Prozesses zum zukünftigen Zustand zu kommen.

Geschäftsregeln

Geschäftsregeln steuern Geschäftsprozesse. Sie dienen dazu, betriebliche Struk-turen zu festigen und das Handeln des Unternehmens zu regeln. Geschäftsregelnwerden während der Erhebung von Anforderungen und der Analyse von Pro-zessen ermittelt und konzentrieren sich häufig auf die betriebliche Rechnungs-legung, auf Zutrittskontrollen und die Unternehmenspolitik. Die Klassifizierungvon Geschäftsregeln kann helfen, die richtigen Entscheidungen für die best-mögliche Umsetzung zu treffen. Die Analyse von Geschäftsregeln gibt Einblick,wie die betrieblichen Funktionen und Prozesse dazu beitragen, die Unterneh-mensziele zu erfüllen. Vor einer Verbesserung oder Neugestaltung analysiert derBusiness-Analyst die Gründe für die Existenz einer Geschäftsregel und untersuchtihre Auswirkungen auf den Geschäftsprozess. Geschäftsregeln beeinflussen Ent-scheidungen und können daher, wenn es sinnvoll ist, über die von ihnen beein-flussten Entscheidungen einzelnen Prozessen zugeordnet werden, außer wennsie ausschließlich der Messung der Leistung eines Prozesses dienen.

Kriterien der Prozessleistung

Kriterien der Prozessleistung sind Parameter, die verwendet werden, um Mög-lichkeiten zur Verbesserung von Prozessen zu identifizieren. Sie werden definiertund implementiert, um sicherzustellen, dass die Prozesse auf die betrieblichenAnforderungen und auf die strategischen Ziele des Unternehmens ausgerichtetsind. Kriterien der Prozessleistung können viele Aspekte eines Prozesses sein, ein-schließlich Qualität, Zeit, Kosten, Agilität, Effektivität, Effizienz, Reaktionsfähigkeit,Anpassungsfähigkeit, Flexibilität, Kundenzufriedenheit, Geschwindigkeit, Varia-bilität, Sichtbarkeit, Vielfalt, Aufwand für und Umfang von Nachbearbeitungen.Viele der Kriterien sollen die Effektivität und Effizienz des Prozesses sowie denZielerreichungsgrad messen. Sind solche Kriterien im ganzen Unternehmen etab-liert, ist das auch ein Merkmal für den Reifegrad der Prozesskultur in einemUnternehmen. Damit wird auch ein gemeinsames Verständnis der Prozessleistunggefördert. Diese Kriterien sind der Schlüssel für die Definition von Service LevelAgreements, wenn ein Unternehmen Services für Kunden zur Verfügung stellt.

Betriebliche Entscheidungen

Betriebliche Entscheidungen sind eine spezielle Art von Aufgaben oder Tätigkeitenin einem Geschäftsprozess, die im Prozess bestimmen, welche von mehreren


506

möglichen Optionen auszuwählen ist. Entscheidungen müssen im Rahmen einerAufgabe oder Tätigkeit getroffen und dann umgesetzt werden. Die Umsetzungerfolgt oft nach einer Verzweigung im Prozess. Die manuellen oder automati-sierten Entscheidungen werden unabhängig vom Prozess entwickelt und durchGeschäftsregeln beschrieben. Entscheidungsregeln, die oft durch eine „BusinessRules Engine“ umgesetzt werden, ermöglichen die Automatisierung dieser Ent-scheidungen.

Beurteilung der Prozessleistung

Der Erfolg eines BPM-Vorhabens beruht darauf, die Leistung der betrachtetenGeschäftsprozesse kontinuierlich zu messen und zu überwachen. Die Beurteilungkann statisch sein und wird in Berichten und Scorecards dokumentiert, oder siekann dynamisch sein und wird in Dashboards angezeigt. Sie stellt alle erforderli-chen Informationen für die Entscheidungsträger in einer Organisation zur Ver-fügung, um Ressourcen umzuschichten oder anzupassen, damit die geplantenProzessziele erreicht werden können.

Frameworks, Methoden und Techniken

.1 FrameworksDie folgende Tabelle 11.5.1 „BPM Frameworks“ listet Frameworks auf, die inder Disziplin des Business Process Management häufig verwendet werden.


507

11.5.3

Tabelle 11.5.1: BPM Frameworks

.2 MethodenDie folgende Tabelle 11.5.2 „BPM-Methoden“ listet Methoden auf, die in derDisziplin des Business Process Management häufig verwendet werden.


508

Framework Kurzbeschreibung

ACCORD Ein methodisches Framework, das aktuelle Standardmodelle wieauch unstrukturierte Daten mit konzeptuellen Modellenvergleicht.

EnhancedTelecommunica-tions Operati-ons Map (eTOM)

Ein hierarchisches Framework, das ursprünglich für die Telekom-munikationsindustrie entwickelt wurde und dann von anderenserviceorientierten Branchen übernommen wurde.

GovernmentsStrategic Refe-rence Model (GSRM)

Ein Lebenszyklus-Framework, das generische Verwaltungspro-zesse und Muster für jede Stufe des organisatorischen Reifegradszur Verfügung stellt.

Model basedand IntegratedProcess Impro-vement (MIPI)

Ein zyklisches Framework mit folgenden Schritten: Bereitschafts-beurteilung, Markierung von Prozess in Überprüfung, detaillierteDatenerfassung, Prozessmodellierung, Prozessbeurteilung undProzess-Redesign, Einsatz der verbesserten Prozesse und Prozess-überprüfung.

Process Classifi-cation Frame-work(PCF)

Ein Klassifizierungs-Framework, das Prozesse detailliert und fürBenchmarking und Performance-Messung verwendet wird.

Table 11.5.2: BPM-Methoden


509

Methode Kurzbeschreibung

Adaptive CaseManagement (ACM)

Ein Verfahren, das verwendet wird, wenn Vorgänge von Naturaus nicht statisch oder unveränderlich sind und Menschen invielfältiger Weise eingreifen. Ein ACM-Prozess kann bei jederDurchführung anders aussehen.

Business Pro-cess Reenginee-ring (BPR)

Die grundlegende Neuausrichtung von Geschäftsprozessen, umVerbesserungen bei kritischen Performance-Kennzahlen wieKosten, Qualität, Service und Geschwindigkeit zu erhalten.

ContinuousImprovement(CI)

Die laufende Überwachung und Anpassung bestehender Pro-zesse, damit sie die Ziele besser erreichen. Das Unternehmenmuss permanente Veränderungen vornehmen und dazu auchkulturell bereit sein.

Lean Eine Methodik zur kontinuierlichen Verbesserung, die auf dieBeseitigung von Verschwendung in einem Prozess konzentriertist. Als Verschwendung ist hier Arbeit gemeint, für die der Kundedes Prozesses nicht zu zahlen bereit ist.

Six Sigma Eine Methodik zur kontinuierlichen Verbesserung, die sich aufdie Beseitigung von Abweichungen bei den Ergebnissen vonProzessen konzentriert. Six Sigma ist statistisch orientiert undkonzentriert sich auf die Leistungsdaten.

Theory OfConstraints(TOC)

Eine Methodik, die davon ausgeht, dass mit drei Variablen dieLeistungsfähigkeit eines Unternehmens optimiert werden kann:dem Prozessdurchsatz, den Betriebskosten der Produktion unddem Lagerbestand. Die Leistung eines Prozesses wird durch einebeherrschende Restriktion zu jedem gegebenen Zeitpunkt domi-niert und der Vorgang kann nur optimiert werden, wenn dieseGröße verbessert wird.

Total QualityManagement (TQM)

Ein Management-Philosophie, der das Prinzip zugrunde liegt,dass die Prozesse eines Unternehmens internen wie auch exter-nen Kunden und Stakeholdern die hochwertigsten Produkte undDienstleistungen liefern, welche die Erwartungen der Kundenund Stakeholder erfüllen oder sogar übertreffen.

.3 TechnikenIn der folgenden Tabelle 11.5.3 „BPM-Techniken“ werden Techniken aufgelistet,die im Techniken-Kapitel des BABOK® Leitfadens nicht enthalten sind, aber inner-halb der BPM-Disziplin verwendet werden.rTabelle 11.5.3: BPM-Techniken

Tabelle 11.5.3: BPM-Techniken (Fortsetzung)


510


Cost Analysis Eine Liste aller Kosten pro Aktivität, die dazu dient, die detaillier-ten Kosten des Prozesses zu zeigen. Sie wird häufig verwendet,um die Kosten, die mit einem Produkt oder einer Dienstleistungim Zusammenhang stehen, zu verstehen und zu würdigen. CostAnalysis ist auch als Prozesskostenrechnung bekannt.

Critical toQuality (CTQ)

Eine Reihe von Baum-Diagrammen, die dabei helfen können, dieMaßnahmen bei Prozessverbesserungen auf die Anforderungender Kunden auszurichten. CTQ ist eine Technik, die bei Six Sigma– aber nicht nur dort – verwendet wird.

Cycle-timeAnalysis

Eine Analyse des Zeitbedarfs jeder Aktivität innerhalb des Prozes-ses. Die Analyse der Zykluszeit ist auch als Analyse der Durch-laufzeit bekannt.

Define MeasureAnalyze DesignVerify (DMADV)

Ein datengesteuerter strukturierter Fahrplan, der verwendetwird, um neue Prozesse zu entwickeln oder bestehende Prozessezu verbessern. DMADV ist eine Technik, die bei Six Sigma – abernicht nur dort – verwendet wird.

Define MeasureAnalyzeImprove Control(DMAIC)

Ein datengesteuerter strukturierter Fahrplan zur Verbesserungvon Prozessen. DMAIC ist eine Technik, die bei Six Sigma – abernicht nur dort – verwendet wird.

Drum-Buffer-Rope (DBR)

Mit dieser Methode soll sichergestellt werden, dass die System-Schwachstelle stets die maximal mögliche Leistung erbringt,indem gerade vor dieser Schwachstelle ein ausreichender Puffervon Materialien vorhanden ist, um eine kontinuierliche Auslas-tung zu gewährleisten.

Failure Modeand EffectAnalysis (FMEA)

Eine systematische Methode zur Untersuchung von Prozessstö-rungen und Defekten und zur Identifizierung möglicher Ursa-chen. FMEA ist eine Technik, die bei der Lokalisierung von Pro-blemen im Ist-Prozess und bei der Korrektur im Rahmen derEntwicklung von Soll-Prozessen hilft.

House of Qua-lity/Voice ofCustomer

Eine Matrix, in der Kundenwünsche und Produkteigenschaftenzu den Fähigkeiten eines Unternehmens in Relation gesetztwerden. Diese Technik kann bei der Entwicklung der Soll-Pro-zesse verwendet werden.


511


Inputs, Guide,Outputs, Enab-lers (IGOE)

Ein Diagramm, in dem der Kontext eines Prozesses beschriebenwird, indem Ein- und Ausgänge des Prozesses ebenso aufgelistetwerden wie die Handbücher, die bei der Ausführung der Pro-zesse genutzt werden, und die unterstützenden Werkzeuge undInformationen, die für den Prozess erforderlich sind.

Kaizen Event Eine gezielte, schnelle Anstrengung, um den Nutzen einerbestimmten Aktivität oder eines bestimmten Teilprozesses zuverbessern.

Process Simula-tion

Ein Modell des Prozesses und eine Reihe zufällig ausgewählterVariablen, um viele Variationen eines Prozesses zu ermitteln undzu bewerten und damit die Leistung unter realen Bedingungeneinschätzen zu können.

Suppliers InputsProcess OutputsCustomers(SIPOC)

Eine Tabelle, die Ein- und Ausgänge von mehreren Prozessenzusammenfasst. Auch bekannt als COPIS, das ist SIPOC einfachrückwärts gelesen.

Theory ofConstraints (TOC) ThinkingProcesses

Eine Reihe von logischen Ursache-Wirkungs-Modellen, die ver-wendet wird, um Konflikte zu diagnostizieren, Ursachen vonProblemen zu identifizieren und zukünftige Zustände einesSystems zu definieren, damit diese Probleme erfolgreich gelöstwerden können. TOC-Prozessdenken ist eine Technik bei derEntwicklung von Soll-Prozessen, die bei der Bestimmung vonProblemen im Ist-Prozess und bei deren Korrektur hilft.

Value AddedAnalysis

Analysiert den Nutzen für den Kunden, der bei jedem Schritterzielt wird, um so Möglichkeiten zur Prozessverbesserung zuermitteln.

Value StreamAnalysis

Damit wird in jedem Funktionsbereich, der Teil eines End-to-End-Prozesses ist, ermittelt, was er zur Steigerung des Nutzens fürden Kunden beigetragen hat.

Who WhatWhen WhereWhy (5Ws)

Eine Reihe von Fragen, die die Grundlage für die Sammlung vonBasisinformationen bilden. Den 5Ws kann auch ein Wie (How)hinzugefügt werden, um „5Ws und H“ zu werden.

Basiskompetenzen

Der Business-Analyst, der im Business Process Management arbeitet, ist gefordert,• den Status quo in Frage zu stellen• so tief zu graben, bis die Ursachen eines Problems klar sind• zu bewerten, warum die Dinge in einer bestimmten Art und Weise getan werden

• die Fachexperten zu ermutigen, über neue Ideen und Ansätze nachzu-denken, um ihre Prozesse effektiver und effizienter zu machen.

Er ist auch gefordert, die Situationen zu verstehen, alle Themen deutlich anzu-sprechen und sowohl die interne als auch die externe Sicht auf die zu analysie-renden Prozesse zu beachten.

Da Änderungen von Prozessen häufig die gewohnte Arbeitsumgebung vonMenschen erheblich verändern, ist die Fähigkeit zur Zusammenarbeit in einemBPM-Vorhaben sehr wichtig. Bei der Zusammenarbeit mit Personen und Gruppenmit unterschiedlichen Meinungen muss der Business-Analyst häufig verhandelnund vermitteln, Konflikte zwischen verschiedenen Gruppen innerhalb des Unter-nehmens aufdecken und lösen. Der Business-Analyst ist ein neutraler und unab-hängiger Moderator eines Change.

Bei BPM-Vorhaben sind häufig alle Ebenen des Unternehmens zu beteiligen undder Business-Analyst ist gefordert, sowohl über interne Grenzen hinweg wieauch mit Personen außerhalb des Unternehmens zu kommunizieren.


In diesem Abschnitt wird erläutert, wie bestimmte Praktiken der Business-Analyseim Rahmen des Business Process Management (BPM) mit den Aufgaben und Prak-tiken der Business-Analyse – wie sie in diesem BABOK® Leitfaden dargestellt sind –zusammenhängen. Dieser Abschnitt beschreibt auch, wie die einzelnen Wissens-gebiete innerhalb der BPM-Disziplin angewendet oder modifiziert werden.

Zu jedem Wissensbereich werden die Techniken des BABOK® Leitfadens aufgelistet,die für die BPM-Perspektive relevant sind. Andere Techniken der Business-Analysesind in diesem Kapitel nicht enthalten, können aber dennoch für den Business-Analysten, der in der BPM-Disziplin arbeitet, nützlich sein. Die Aufzählung derTechniken erhebt nicht den Anspruch, vollständig zu sein, vielmehr sollen dieTechniken genannt werden, die der Business-Analyst nutzen kann, wenn er Auf-gaben in dem jeweiligen Wissensgebiet durchführt.

.1 Planung und Überwachung der Business-AnalyseBei der Planung von BPM-Vorhaben wird rollierend geplant, weil in der Anfangs-phase nur begrenzte Informationen für die Planung vorhanden sind. Zu BPM-


512

11.5.4

11.5.5

Vorhaben gehört es, dass Aktivitäten fortlaufend verbessert werden. BPM-Vor-haben scheitern häufig, wenn es versäumt wird, die Auswirkungen von Verän-derungen der Prozesse laufend zu überwachen. Bei BPM-Vorhaben ist der primäreFokus auf die Analyse und Verbesserung der Geschäftsprozesse gerichtet, bevorgeeignete Technologien für die Prozessunterstützung oder irgendwelche Ände-rungen, die an Software-Anwendungen oder Arbeitsverfahren erforderlichwerden könnten, untersucht werden.


• Item Tracking (Kap.10.26) • Prozessmodellierung (Kap.10.35)• Reviews (Kap.10.37) • Schätzung (Kap.10.19)• Stakeholder-Listen, -Karten •Workshops (Kap.10.50)oder Personas (Kap.10.43)

Andere Techniken der Business-Analyse

• Inputs, Guide, Outputs, Enablers (IGOE)

.2 Erhebung und ZusammenarbeitUm im Rahmen eines BPM-Vorhabens erfolgreich zu sein, muss der Umfang desVorhabens und des betroffenen Prozesses definiert und verstanden werden.

Prozessmodellierung und Stakeholder-Analyse werden generell während derErhebungsphase eines BPM-Vorhabens angewendet. Dabei konzentriert sich derBusiness-Analyst auf Ursache-Wirkungs-Zusammenhänge sowohl veränderterProzesse wie auch des Ist-Zustands. Wenn ein bestehender Prozess geändertwird, werden die Auswirkungen von Verbesserungen auf die Organisation, dieMenschen und die Technologie untersucht. Prozesslandkarten sind ein wichtigesInstrument in der Erhebung in BPM-Vorhaben. Während ihrer Entwicklungwerden die betroffenen Stakeholder intensiv eingebunden. Effektive Erhebungund Zusammenarbeit sind entscheidende Erfolgsfaktoren bei Prozessanalyse,Prozessmodellierung und Design.

Prozessänderungen können erhebliche Auswirkungen iim gesamten Unternehmenhaben, die Zusammenarbeit mit den Stakeholdern und die Berücksichtigungihrer Erwartungen sind deswegen besonders kritische Faktoren. Ohne eine effek-tive Zusammenarbeit mit den Stakeholdern können Prozessänderungen nichterfolgreich umgesetzt werden oder die Ziele des Unternehmens werden nichterreicht.


513


• Beobachtungen (Kap.10.31) • Brainstorming (Kap.10.5)• Dokumentenanalyse (Kap.10.18) • Fokusgruppen (Kap.10.21)• Interviews (Kap.10.25) • Kennzahlen und Key-

Performance-Indikatoren (Kap.10.28)• Prozessmodellierung (Kap.10.35) • Prototyping (Kap.10.36)• Reviews (Kap.10.37) • Schnittstellenanalyse (Kap.10.24)• Scope-Modellierung (Kap.10.41) • Stakeholder-Listen, -Karten oder

Personas (Kap.10.43)• Umfrage oder Fragebogen (Kap.10.45)• Ursachenanalyse (Kap.10.40)• Use Cases und Szenarien (Kap.10.47) • User Stories (Kap.10.48)• Workshops (Kap.10.50)

Andere Techniken der Business-Analyse

• House of Quality/Voice of Customer

.3 Management des Anforderungs-LebenszyklusZum BPM gehört eine Reihe von prozessorientierten Ansätzen, die sich daraufkonzentrieren, die Wertschöpfung zu erhöhen und dabei viele Funktionsbereicheeinbeziehen. Ein höherer Nutzen kann oft nur mit einem gezielten Change-Vor-haben erreicht werden, er kann sich aber auch aus einer Ad-hoc-Anfrage odereinem Überprüfungsprozess ergeben. BPM-Aktivitäten haben erhebliche Aus-wirkungen auf das Management des Anforderungs-Lebenszyklus, da dabei neuebetriebliche Anforderungen entstehen können, die zu einem neuen Design,Änderungen von Programmen, Umsetzungsmaßnahmen und weiteren Ände-rungen nach der Umsetzung führen. Der Business-Analyst ist dafür zuständig,die Verbindung zu dem Management des Anforderungs-Lebenszyklus aufrechtzu erhalten und eine effektive Kommunikation mit den Stakeholdern und Pro-zessverantwortlichen sicherzustellen. Sie sind schließlich die ultimativen Ent-scheidungsträger, wenn es um Prozesse, Changes und unterstützende Lösungengeht.

Da die Dokumentation von Geschäftsprozessen im täglichen Betrieb des Unter-nehmens verwendet werden soll, ist sie für alle Stakeholder verfügbar. Wennder Prozess durch ein BPMS automatisiert wird, kann der dokumentierte Prozessunter Umständen direkt ausgeführt werden.


• Akzeptanz- und • Analyse der GeschäftsregelnBewertungskriterien (Kap.10.1) (Kap.10.9)


514

• Analyse nicht-funktionaler • Backlogmanagement (Kap.10.2)Anforderungen (Kap.10.30)

• Brainstorming (Kap.10.5) • Priorisierung (Kap.10.33)• Prozessanalyse (Kap.10.34) • Prozessmodellierung (Kap.10.35)• Prototyping (Kap.10.36) • Scope-Modellierung (Kap.10.41)• Workshops (Kap.10.50)


• Keine

.4 Strategische AnalyseIm Zusammenhang mit dem BPM muss für die Strategieanalyse klar sein, welcheRolle die Prozesse für die Wertschöpfungskette spielen. Zumindest müssen alleProzesse berücksichtigt werden, die von dem Vorhaben betroffen sind.

Der aktuelle Zustand wird wahrscheinlich durch die Ist-Wertschöpfungsketteund die aktuellen Performance-Kennzahlen für den Geschäftsprozess beschrieben.Der zukünftige Zustand wird als Soll-Wertschöpfungskette und mit den ent-sprechenden Kennzahlen für die Soll-Performance beschrieben. Ansätze zurkontinuierlichen Prozessverbesserung konzentrieren sich auf die Performance-Kennzahlen, um daraus die Strategie abzuleiten. Zur Change-Strategie gehörtdann auch die Identifikation möglicher Änderungen von Prozessen.


• Dokumentenanalyse (Kap.10.18) • Funktionale Gliederung (Kap.10.22)• Interviews (Kap.10.25) • Lessons Learned (Kap.10.27)• Prozessanalyse (Kap.10.34) • Prozessmodellierung (Kap.10.35)


• Drum-Buffer-Rope •House of Quality/Voice of Customer

• Inputs, Guide, Outputs, • TOC Thinking ProcessesEnablers (IGOE)

.5 Anforderungsanalyse und Design-DefinitionAnforderungsanalyse und Design-Definition konzentrieren sich auf die Definitiondes Soll-Prozessmodells. Zur Anforderungsarchitektur gehören üblicherweise dasProzessmodell, die damit verbundenen Geschäftsregeln und Entscheidungen, Infor-mationsanforderungen und die Organisationsstruktur. Lösungsoptionen enthaltenüblicherweise die zur Unterstützung des Prozesses benötigten IT-Anpassungensowie das Outsourcing von Teilen des Prozesses und ähnliche Veränderungen.


515


• Analyse der Geschäftsregeln • Benchmarking und (Kap.10.9) Marktanalyse (Kap.10.4)

• Entscheidungsmodellierung • Funktionale Gliederung (Kap.10.17) (Kap.10.22)

• Kennzahlen und Key- • Priorisierung (Kap.10.33)Performance-Indikatoren (Kap.10.28)

• Prototyping (Kap.10.36) • Schätzung (Kap.10.19)• Scope-Modellierung (Kap.10.41) • Stakeholder-Listen, -Karten oder

Personas (Kap.10.43)• Workshops (Kap.10.50)


• Kaizen Event • Process Simulation

.6 LösungsbewertungLösungen werden typischerweise während eines BPM-Vorhabens fortlaufendbewertet, um die Performance des Geschäftsprozesses zu beurteilen. Wenn Pro-zesse für verschiedene Szenarien bewertet werden, können sie weiterentwickeltund laufend überwacht werden. Mit den Aufgaben der Lösungsbewertung wer-den die Auswirkungen von Prozessverbesserungen und deren Nutzen sichtbargemacht. Zur Lösung kann auch ein Prozess-Mining gehören, bei dem Technikenwie Audit-Trails oder Transaktionsprotokolle eingesetzt werden, um weitereDetails der Prozesse zu erkennen.

Die Aufgabe „Lösungsperformance messen“, (Kap.8.1) wird durchgeführt, ummögliche Unterschiede zwischen dem potentiellen Nutzen und dem tatsächlichenNutzen zu verstehen. Mit dieser Analyse soll herausgefunden werden, warumes eine Abweichung zwischen möglichem und tatsächlichem Nutzen gibt. Eswird untersucht, ob eine bestimmte Lösung besser funktionieren oder mehrNutzen bringen könnte. Die Bewertung untersucht Chancen oder Restriktionender umgesetzten Lösung, was sie zur Erfüllung des Bedarfs beiträgt oder wie sieverbessert werden könnte. Die Ergebnisse können weitere Prozessverbesserungenauslösen. Dazu wird der BPM-Lebenszyklus unter Umständen mehrfach wieder-holt.


516


• Akzeptanz- und • Analyse der Geschäftsregeln Bewertungskriterien (Kap.10.1) (Kap.10.9)


• Beobachtungen (Kap.10.31) • Brainstorming (Kap.10.5)• Betriebliche • Dokumentenanalyse (Kap.10.18)Fähigkeitsanalyse (Kap.10.6)

• Entscheidungsanalyse (Kap.10.16) • Interviews (Kap.10.25)• Kennzahlen und Key- •Organisationsmodellierung Performance-Indikatoren (Kap.10.32)(Kap.10.28)

• Prozessmodellierung (Kap.10.35) • Reviews (Kap.10.37)• Risikoanalyse und • Schätzung (Kap.10.19)-management (Kap.10.38)

• Stakeholder-Listen, -Karten • SWOT-Analyse (Kap.10.46)oder Personas (Kap.10.43)

• Umfrage oder Fragebogen • Ursachenanalyse (Kap.10.40)(Kap.10.45)


• Kaizen Event • Failure Mode and Effect Analysis (FMEA)

• Process Simulation • Value Stream Analysis


517

519

a Abgrenzungsmodell (scope model): Modell, mit dem die Grenzen eines Geschäfts-bereichs oder einer Lösung bestimmt werden.

Ablaufdiagramm (sequence diagram): Grafische Darstellung eines Prozesses undder Zusammenhänge zwischen den Prozesselementen durch Symbole.

Adaptiver Ansatz (adaptive approach): Vorgehensweise, bei der die Lösung auseinem wiederkehrenden Prozess des Entdeckens und Lernens entsteht, mit Rückkopplungsschleifen, die dazu ermutigen, Entscheidungen so spät wie möglich zu fällen.

Akteur BA (actor): Person, Vorrichtung oder System mit einer spezifischen Rollein einer Lösung.

Akzeptanzkriterien (acceptance criteria): Kriterien, die sich aus den Anforderungen,den Lösungen oder der Bereitstellung ableiten lassen und die erfüllt sein müssen, um die Akzeptanz der Stakeholder zu erreichen.

Akzeptanztest (user acceptance test): Untersuchung, ob die erarbeitete Lösungden Bedarf der Anwendergruppe erfüllt, die diese Lösung nutzt. Dazu werden die Akzeptanzkriterien verwendet.

Anforderung (requirement): Gebrauchsfähige Darstellung eines Bedarfs.

Anforderungsabbildung (requirements artifact): Hilfsmittel der Business Analyse mit Informationen über Anforderungen, etwa in der Form einer Matrix, eines Dokumentes oder eines Modells.

Anforderungsarchitektur (requirements architecture): Anforderungen für ein bestimmtes Vorhaben und deren wechselseitige Abhängigkeiten.

Anforderungsdokument (requirements document): siehe Anforderungspaket

Anforderungs-Lebenszyklus (requirements life cycle): Phasen, die eine Anforderungdurchläuft von der Ermittlung bis zur Löschung.

Anforderungsmanagement (requirements management): Planung, Durchführung,Monitoring und Kontrolle jeglicher Aufgaben, die mit der Erhebung, der Analyse und dem Design von Anforderungen verbunden sind, sowie dasManagement des Anforderungs-Lebenszkyklus.

Anforderungsmanagementplan (requirements management plan): Teilgebiet der Business-Analyse-Planung für ein konkretes Vorhaben, in dem die Werkzeuge,Aktivitäten, Rollen und Verantwortlichkeiten beschrieben werden, die in dem Vorhaben eingesetzt werden, um die Anforderungen zu managen.

Anhang A: Glossar

Anforderungsmanagement-Tool (requirements management tool): Spezialsoft-ware, die folgende Fähigkeiten unterstützt: Erhebung und Zusammenarbeit,Modellierung und Spezifizierung, Pflege und Nutzung von Anforderun-gen, Versionierung, Definition von Attributen, zum Nachverfolgen und zum Monitoring von Anforderungen, zur Erstellung von Dokumenten undzur Steuerung der Änderung von Anforderungen.

Anforderungsmangel (requirements defect): Problem oder Fehler in einer Anforderung. Mängel können sich ergeben, weil Anforderungen qualitativschlecht sind (siehe Anforderungsverifizierung) oder weil sie einen Bedarfbeschreiben, der, wenn er erfüllt würde, für Stakeholer keinen Wert schafft (siehe Anforderungsvalidierung).

Anforderungsmerkmal (requirements attribute): Metadaten (beschreibende Eigen-schaften) zu einer Anforderung, die für die Entwicklung und Verwaltungvon Anforderungen genutzt werden.

Anforderungsmodell (requirements model): Abstrakte, normalerweise grafische Darstellung bestimmter Aspekte aktueller oder zukünftiger Anforderungen.

Anforderungspaket (requirements package): Spezielle Form eines Pakets der Business-Analyse, das hauptsächlich Anforderungen betrifft. Ein Anforde-rungspaket kann die Ausgangsgrößen einer Sammlung von Anforderun-gen darstellen.

Anforderungsvalidierung (requirements validation): Überprüfung der Anforde-rungen hinsichtlich ihrer Verträglichkeit mit den Zielen oder Vorgaben (Richtwerten) einer Organisation (Unternehmung).

Anforderungsverifizierung (requirements verification): Überprüfung von Anfor-derungen hinsichtlich ihrer Richtigkeit, Präzision und Aussagefähigkeit, um sie als ausreichende Vorgaben für das Design und die Umsetzung ver-wenden zu können.

Anforderungs-Workshop (requirements workshop): Strukturiertes und mode-riertes Treffen einer Gruppe von Stakeholdern zur Ermittlung oder Über-arbeitung von Anforderungen.

Anforderungszuordnung (requirements allocation): Prozess der Zuweisung von Anforderungen an Systeme oder Lösungsbestandteile wie zum Beispiel Mitarbeiter, Hardware, Software.

Anfrage (request for quotation RFQ): Beschaffungsmethode, um Preise und Lösungsmöglichkeiten von Anbietern zu ermitteln.

Annahme (assumption): Größe, die als gegenwärtiger oder zukünftiger Einfluss-faktor unterstellt wird, die aber nicht als sicher gelten kann.

Anwender (end user): Stakeholder, der direkt mit der Anwendung der Lösung zu tun hat.

520

Glossar

Arbeitsergebnis BA (work product): Dokument oder Sammlung von Notizen undDiagrammen, die der Business-Analyst im Prozess der Anforderungs-ermittlung nutzt.

Architektur (architecture): Design, die Ordnung und das Verhalten einer gegen-wärtigen oder zukünftigen Struktur, abgeleitet aus den Komponenten und der Interaktion der Komponenten (siehe auch Unternehmensarchi-tektur, Anforderungsarchitektur).

Artefakt BA (artifact): Lösungsrelevantes Objekt, das als ein Ergebnis der Business-Analyse entstanden ist.

Aufgabe BA (task): Abgrenzbarer, zu erledigender Vorgang, der formal oder informal im Rahmen einer Business Analyse erledigt wird.

Aufgabenstrukturplan oder Projektstrukturplan (work breakdown structure): Hierarchisch aufgegliederte Darstellung der Aufgaben, die bei einem Vor-haben zu erledigen sind, um die Ziele eines Vorhabens zu erreichen und die geforderten Ergebnisse zu erarbeiten. Damit werden die Struktur undder Umfang eines Projektes dargestellt.

Auftragsbeschreibung (statement of work): Schriftliche Dokumentation der Services oder Aufgaben, die erledigt werden müssen.

Auslöser BA (event): Vorfall oder Ereignis, auf das eine Organisationseinheit, einSystem oder ein Prozess reagieren muss.

Ausschreibung (request for proposal RFP): Anforderungsdokument im Zusam-menhang mit einer formalen Anfrage an Lieferanten, ein Angebot abzu-geben.

Ausschreibung, offen (request for tender RFT): Nicht-standardisierte Aufforde-rung an Anbieter, Vorschläge für Produkte oder Services zu unterbreiten.

Bedarf (need): Problem, das gelöst, oder eine Chance, die wahrgenommen werden sollte.

Benchmarking: Vergleich mit führenden Unternehmen hinsichtlich Prozess, Leis-tung, Kosten, Zeit, Qualität oder anderer Kriterien zur Bestimmung der relativen eigenen Position, um damit Möglichkeiten für die eigene Ver-besserung zu ermitteln.

Beobachtung (observation): Erhebungstechnik, bei der Informationen über Anfor-derungen durch die direkte Anschauung von Stakeholdern und ihrer Arbeitsumwelt ermittelt werden.

Betriebliche Anforderung (business requirement): Darstellung der Unterneh-mensziele, betrieblichen Zielsetzungen und Ergebnisse, die beschrei-ben, weshalb ein Veränderungsprozess begonnen wurde und wie der Erfolg gemessen werden kann.

Glossar

521

b

Betriebliche Leistungsfähigkeit (organizational capability): Möglichkeit eines Unternehmens, seine Ziele z.B. mit Hilfe von Prozessen, Technik und Informationen zu erreichen.

Betriebliche Zielsetzung (business objective): Objektive, messbare Größe, die geeignet ist, zu zeigen, ob ein erwartetes Ergebnis erreicht wurde.

Betrieblicher Bedarf (business need): Zu lösendes Problem oder eine wahrzu-nehmende Chance von strategischer oder taktischer Bedeutung.

Bewertung (evaluation): Beurteilung der Vorteilhaftigkeit von Lösungen durch Abgleich mit den angestrebten Zielen.

Body of Knowledge: Aggregiertes Wissen und allgemein akzeptierte Vorgehens-weisen zu einem Fachgebiet.

BPM: siehe Business Process Management.

Brainstorming: Verfahren zur kritikfreien Ermittlung von Ergebnissen durch einemöglichst breite Sammlung von Ideen in einer Gruppe, die in der Regel moderiert wird.

Business: siehe Unternehmen

Business-Analyse (business analysis): Praxis, Anforderungen zu ermitteln und Lösungen vorzuschlagen, die in Unternehmen Änderungen bewirken undfür Stakeholder wertvoll sind.

Business-Analyse-Ansatz (business analysis approach): Gesamtheit der Prozesse,Regeln, Richtlinien, Erhebungen und Aktivitäten, die angewendet werden,um Business-Analyse in einem bestimmten Zusammenhang auszuüben.

Business-Analyse-Kommunikationsplan (business analysis communication plan):Beschreibung der Formen der Kommunikation, die ein Business-Analyst im Zusammenhang mit einer Business-Analyse nutzt, sowie die Empfän-ger der Kommunikation und die zeitlichen Regelungen dazu.

Business-Analyse-Plan (business analysis plan): Beschreibung der geplanten Akti-vitäten, die ein Business-Analyst ergreifen wird, um alles Notwendige im Zusammenhang mit einem bestimmten BA-Vorhaben zu tun (zeitlich, methodisch und inhaltlich).

Business-Analyst: Jede Person, die Business-Analyse betreibt, gleich welche Posi-tion sie einnimmt oder welche Stellenbezeichnung sie trägt (Näheres siehe„Was ist ein Business-Analyst?“)

Business-Case: Darstellung eines Geschäftsszenarios, in dem Kosten und Nutzeneiner beabsichtigten Lösung ebenso abgewogen werden wie die nicht-finanziellen Auswirkungen.

Business-Process Management: Managementdisziplin, mit deren Hilfe bestimmtwird, wie manuelle oder automatisierte Prozesse gestaltet, modifiziert, beendet und gesteuert werden.

Glossar

522

Change: Maßnahmen, die ergriffen werden, um von einem erkannten Bedarf zu einem Ergebnis zu gelangen.

Change Agent: Für Änderungen zuständige Person.

Change Management: Alle geplanten Aktivitäten, Werkzeuge und Vorgehens-weisen, die dazu dienen, die Bedürfnisse der von einem Veränderungs-prozess betroffenen Menschen zu erkennen und zu berücksichtigen.

Change-Strategie (change strategy): Plan, um von dem heutigen Zustand zu einem zukünftigen Zustand zu gelangen und dabei die angestrebten Zielezu erreichen.

Change Team: Funktionsübergreifende Gruppe von Personen, die damit beauftragtist, eine Veränderung herbeizuführen, und dafür die notwendige Qualifi-kation und Kompetenz besitzt.

Checkliste BA: Standardisierter Satz von Qualitätskriterien, den Reviewer für dieVerifizierung von Anforderungen nutzen.

Core Concept BA: Einer von sechs fundamentalen Bestandteilen der Business-Analyse: Change, Bedarf, Lösung, Kontext, Stakeholder und Wert.

COTS commercial off-the-shelf: siehe Standardprodukt.

CRUD-Matrix (create, read, update, and delete matrix): Zweidimensionale Matrix,in der abgebildet wird, welche Rollen bestimmte Informationen ergänzen(create), lesen (read), aktualisieren (update) oder löschen (delete) können.In einer vergleichbaren Matrix kann auch abgebildet werden, welche Pro-zesse (nicht Rollen) ergänzen, lesen, aktualisieren oder löschen dürfen.

Design: Nutzbare Darstellung einer Lösung.

Dokumentenanalyse (document analysis): Erhebungstechnik, um in einer beste-henden Organisation auf der Grundlage vorhandener Unterlagen, Anfor-derungen zu ermitteln.

DSDM (dynamic systems development method): Ordnungsrahmen (framework)für Projekte, in denen Kosten, Zeiten und Qualität von Beginn an vorge-geben sind, wohingegen die zu liefernden Ergebnisse variabel gehalten werden.

Einführungsexperte (implementation subject matter expert): Stakeholder, der hinsichtlich der Umsetzung einer oder mehrerer Lösungsbestandteile besonderes qualifiziert ist.

Entity-Relationship-Diagramm (entity relationship diagram): Grafische Darstel-lung der für ein Problem relevanten Größen (Entitäten) und deren Bezie-hungen untereinander.

Glossar

523

d

c

e

Entscheidungsanalyse (decision analysis): Verfahren zur Entscheidungsvorberei-tung, mit dessen Hilfe mögliche Folgen einer Entscheidung modelliert und analysiert werden und das dazu beiträgt, eine gute Entscheidung unter Unsicherheit zu fällen.

Entscheidungsprozess (governance process): Prozess, in dem relevante Entschei-der Informationen nutzen, um Entscheidungen über Veränderungen oderLösungen zu fällen und dabei Prioritäten und Genehmigungen einholen.

Erhebung (elicitation): Iterative Ableitung und Ermittlung von Informationen vonStakeholdern oder anderen Quellen.

Evolutionärer Prototyp (evolutionary prototype): Vorläufige Version einer späterenLösung, die zur Erprobung von Eigenschaften dient, kontinuierlich modi-fiziert und an die Anforderungen der Anwender angepasst wird.

Experiment: Kontrollierte Erhebung, um etwas zu entdecken, eine Hypothese zu überprüfen oder eine bekannte Tatsache zu demonstrieren.

Externe Schnittstelle (external interface): Schnittstelle zu Systemen oder Objekten außerhalb des Untersuchungs- oder Gestaltungsbereichs. Dabeikann es sich um eine andere Hardware, eine Software, eine Person handeln,die mit dem betrachteten System in Beziehung steht.

Externer Akteur (external actor): Akteur außerhalb des zu entwickelnden Systems,der die Ausführung des Use Case unterstützt.

Fachexperte (domain subject matter expert): Person mit besonderer Fach-kenntnis in einem bestimmten Gebiet, das für ein Unternehmen wichtig ist bzw. das für eine Lösung relevant ist.

Fachgebiet (business domain): Wissensgebiet, das sich aus gemeinsamen Anfor-derungen, gemeinsamer Terminologie und gemeinsamer Funktionalität ergibt und zur Lösung eines Problems herangezogen wird.

Fishbone-Diagramm (cause-and-effect-diagram): Darstellungsform, die in der Ursachenanalyse dazu verwendet wird, die zugrundeliegenden Auslöser für Probleme und die Abhängigkeiten zwischen diesen Auslösern zu ermit-teln. Wird auch als Ishikawa-Diagramm oder Ursache-Wirkungs-Diagrammbezeichnet.

Fokusgruppe (focus group): Methodischer Ansatz, um mit Hilfe einer Gruppe Vor-schläge und Einstellungen zu ermitteln zu einem Produkt, einem Service oder einer Lösungsmöglichkeit. Die Beteiligten werden durch einen Mode-rator gesteuert und tauschen ihre Eindrücke, Präferenzen und Bedürf-nisse untereinander aus.

Fragebogen (questionaire): Schriftliche Zusammenstellung von Fragen für Stakeholder, um mit ihrer Hilfe Auskünfte zu erheben und qualitativ oderquantitativ (statistisch) auszuwerten.

Glossar

524

f

Funktionale Anforderung (functional requirement): Leistungen oder Fähigkeiten,die ein Produkt, ein Service oder eine sonstige Lösung dem Kunden oderAnwender bietet.

Gap-Analyse (gap analysis): Vergleich eines gegenwärtigen Zustands oder einergegenwärtigen Leistung mit einem gewünschten zukünftigen Zustand oder einer zukünftigen Leistung, um so Ansatzpunkte zu erkennen, wie die ermittelte Differenz überwunden werden kann.

Geschäftsprozess (business process): Reihe definierter Aktivitäten oder Bearbei-tungsschritte, die arbeitsteilig und in gleicher Form wiederkehrend in einerUnternehmung bearbeitet werden. Geschäftsprozesse werden durch aus-lösende Ereignisse angestoßen und können unterschiedliche Ergebnisse zur Folge haben. Ein erfolgreicher Geschäftsprozess schafft Wert(e) für einen oder mehrere Stakeholder. Er kann innerhalb eines Unternehmens oder unternehmensübergreifend ablaufen .

Geschäftsregel (business rule): Spezifische, praktikable und nachvollziehbare Vorgabe, die innerhalb eines Unternehmens umgesetzt werden kann unddie dazu dient, das Verhalten zu steuern, zu urteilen und Entscheidungenzu fällen.

Horizontaler Prototyp (horizontal prototype): Wenig detaillierter Prototyp, der aber möglichst die ganze Breite der Funktionalität eines Systems oder einer Anwendung abbildet, um dem Kunden oder einer anderen Organi-sation die Erfüllung von Anforderungen zu demonstrieren.

Indikator (indicator): Zahl als quantitativer Ausdruck zur Messung eines bestimm-ten Ergebnisses und zur Ermittlung von Veränderungen aufgrund bestimm-ter Eingriffe oder Maßnahmen.

Informationsanfrage (request for information RFI): Formale Erhebungstechnik, mit der Informationen über die Leistungsfähigkeit von Lieferanten oder andere Informationen im Zusammenhang mit einer zukünftigen Beschaf-fungsmaßnahme gesammelt werden.

Input BA: Information, die benötigt oder bearbeitet wird, um ein Ergebnis zu produzieren. Am Anfang jeder Aufgabenerfüllung steht eine Information.

Interfunktionsfähigkeit (interoperability): Fähigkeit von Systemen, durch Informati-onsaustausch oder Austausch von Services miteinander zu kommunizieren.

Interview: Erhebungstechnik, bei der einzelne Personen oder Personengruppenmündlich zu bestimmten Sachverhalten befragt werden. Diese Befragung kann sowohl in einem formellen Rahmen als auch informell geschehen.

Glossar

525

g

h

i

Ishikawa-Diagramm: siehe Fishbone-Diagramm

Iteration: Zyklus aus Analyse, Entwicklung, Test und Umsetzung als Bestandteil einer größeren Anzahl solcher Zyklen.

Kernursache (root cause): Letztendliche Ursache für ein Problem, weitere Ursachenkönnen ausgeschlossen werden.

Kompetenz (capability): Gesamtheit der Aktivitäten, die ein Unternehmen aus-führt, das dort verfügbare Wissen, die Produkte und Services, die es bereit-stellt, die Funktionen, die es erfüllt, und die Methoden, die es einsetzt, um Entscheidungen zu fällen.

Komponente (component): Abgrenzbares Element eines größeren Ganzen, daseine eindeutige Funktion erfüllt.

Kontext (context): Sachverhalte, die eine Veränderung beeinflussen, die Ein-flüsse auf Dritte haben und die das Verständnis für die Veränderung fördern.

Kontrolliertes Vorgehen (predictive approach): Methodischer Ansatz, bei dem schon zu Beginn eines Vorhabens die Ausgangssituation bestimmt und gründlich geplant wird, um eine größtmögliche Beherrschbarkeit zu gewährleisten und Risiken zu minimieren.

Konzeptmodell (concept model): Analysemodell, mit dem zentrale Konzepte füreinen Problembereich erarbeitet werden, deren gemeinsame Struktur ermittelt wird und für die eine gemeinsame Sprache geschaffen wird, mitderen Hilfe störungsfrei kommuniziert werden kann.

Kosten-Nutzen-Analyse (cost-benefit analysis): Analyse zur Ermittlung der Wirt-schaftlichkeit einer Lösung. Den quantifizierbaren monetären und nicht-monetären Kosten einer Lösung wird der Nutzen gegenübergestellt.

Kraftfeldanalyse (force field analysis): Methodischer Ansatz zur Ermittlung aller Kräfte, die einer Veränderung positiv oder negativ gegenüberstehen, ein-schließlich der Einschätzung der Stärke dieser Kräfte.

Kunde (customer): Stakeholder, der Produkte oder Services des Unternehmens nutzt oder nutzen kann und der vertragliche oder moralische Ansprüchehat, die ein Unternehmen erfüllen muss.

Lebenszyklus (life-cycle): Reihe von Veränderungen an einem Gegenstand oder Objekt vom Beginn bis zum Ende.

Leistung (deliverable): Spezifiziertes Produkt oder ein spezifizierter Service, dessen Lieferung zugesagt wurde.

Glossar

526

k

l

Lessons-learned-Prozess (lessons learned process): Technik zur Verbesserung vonProzessen, die angewendet wird, um aus einem Prozess oder Projekt zu lernen. Dazu wird ein spezielles Treffen einberufen, in dem die Gruppe herausfindet, was gut gelaufen ist, was nicht geklappt hat und was somitfür die Zukunft daraus gelernt werden kann.

Lieferant (supplier): Ein Stakeholder außerhalb der Grenzen einer Organisation,der Services oder Produkte liefert und der moralische oder vertragliche Ansprüche besitzen kann, die bei einer Lösung zu beachten sind.

Lösung (solution): Spezifischer Ansatz, um einen oder mehrere Bedarfe in einemKontext zu befriedigen.

Lösungsanforderung (solution requirement): Fähigkeit oder Qualität einer Lösung,die funktionale und/oder nicht-funktionale Anforderungen eines Stake-holders abdeckt.

Lösungsbereich (product scope): Gesamtheit der Fähigkeiten, die eine Lösung bieten muss, um die betrieblichen Anforderungen zu erfüllen.

Lösungskomponente (solution component): Teil einer Lösung, wie z.B. Menschen,Infrastruktur, Hardware, Software, Betriebsmittel, Räume, Teilprozesse oder eine beliebige Kombination dieser Objekte.

Lösungs-Lebenszyklus (solution life cycle): Phasen, die eine Lösung von der Ent-wicklung bis zur Abschaffung durchläuft .

Lösungsmerkmal (feature): Abgrenzbarer Bestandteil einer Lösung, in dem eineReihe von Anforderungen umgesetzt wird und der Wert für Stakeholder liefert.

Lösungsoption (solution option): Ein möglicher Weg, einen oder mehrere Bedarfein einem bestimmten Kontext zu befriedigen.

Machbarkeitsstudie (feasibility study): Prüfung möglicher Varianten darauf, ob sie technisch, organisatorisch und wirtschaftlich im Rahmen gegebener Restriktionen umgesetzt werden können und ob sie geeignet sind, wesent-liche Ziele zu erreichen.

Mangel (defect): Unzulänglichkeit in einem Produkt oder in einer Leistung, die deren Qualität beeinträchtigt oder von einem gewünschten Zustand odereiner gewünschten Funktionalität abweicht.

Matrix: Schriftliche Form der Modellierung, die dazu genutzt wird, Informationendarzustellen, die dargestellt, kategorisiert und miteinander in Beziehung gesetzt werden können.

Metadaten (metadata): Daten, die Informationen über andere Daten enthalten (z.B. Struktur, Semantik, Wertebereiche und Verwendung von Daten). Beiden beschriebenen Daten handelt es sich oft um Datenbanken oder

Glossar

527

m

Dateien. Sie werden genutzt, um den Kontext und die Aussagefähigkeit von gespeicherten Informationen zu verstehen.

Methodik (methodology): Gesamtheit von Prozessen, Regeln, Vorlagen und Arbeitstechniken, aus denen hervorgeht, wie (im Rahmen einer Business-Analyse) Lösungen erarbeitet, umgesetzt und eingeführt werden.

Metrik (metric): Quantitative Ausprägung einer Kennziffer, die eine Unternehmungzu einem bestimmten Zeitpunkt erhebt.

Mission Statement: Formelle Erklärung der Werte und Ziele, die den eigentlichenZweck des Unternehmens ausdrücken.

Modell (model): Vereinfachte Darstellung eines realen Sachverhalts, die dazu dient, für eine bestimmte Zielgruppe die Kommunikation, die Analyse oder das Verständnis zu fördern.

Moderation (facilitation): Menschen mit Hilfe systematischer Bemühungen auf eine Weise zu gemeinsamen Zielen führen und dabei die Beteiligung, die Kooperation, die Produktivität und die Synergie fördern.

Monitoring: Kontinuierlicher Prozess der Datensammlung und -auswertung, umfestzustellen, inwieweit eine eingeführte Lösung die erwarteten Ergebnissebringt, und um bei Bedarf einzugreifen, wenn nicht die gewünschte Ent-wicklung eintritt oder wenn bestimmte Werte über- oder unterschritten werden.

Nachvollziehbarkeit (traceability): siehe Nachvollziehbarkeit von Anforderungen

Nachvollziehbarkeit von Anforderungen (traceability of requirements): Fähigkeit,die Beziehungen zwischen Gruppen von Anforderungen vom ursprüng-lichen Bedarf des Stakeholders bis zur aktuell eingeführten Lösung zurück-zuverfolgen. Die Nachvollziehbarkeit unterstützt die Überwachung von Änderungen, indem die Quelle einer Anforderung oder eines Designs identifiziert werden kann und andere verbundene Anforderungen und Designs, die von einer Änderung ebenfalls betroffen sein können, ersichtlichsind.

Nicht-funktionale Anforderung (non-functional requirement): Anforderungen, die nicht eine konkrete Funktion einer Lösung betreffen, sondern eher „begleitender“ Natur sind z.BQualitätsmerkmale oder zwingende Vorgabenfür das Design der Lösung insgesamt.

OLAP: siehe Online Analytical Processing

Online Analytical Processing: IT-gestützter Zugriff auf Informationen, mit dem große Mengen vorhandenen Wissens nach unterschiedlichsten Kriterien analysiert und aufbereitet werden können.

Glossar

528

n

o

Organisation (organization): Unternehmen oder eine autonome Einheit in einemUnternehmen, das (die) von einem Einzelnen oder von einer Personen-mehrheit geleitet wird, gemeinsamen Zielen verpflichtet ist und sich von anderen Einheiten abgrenzen lässt (institutionelle Sicht der Organisation).Organisationen sind dauerhaft eingerichtet, im Unterschied etwa zu Pro-jektgruppen, die sich mit der Erledigung eines Auftrags wieder auflösen.Der Begriff Unternehmen wird hier häufig synonym für Organisation ver-wendet. Der Begriff wird auch in der sogenannten funktionellen Sicht für die Tätigkeit des „Organisierens“ verwendet.

Organisationseinheit (organizational unit): Abgrenzbare Einheit von Personen ineiner Organisation oder einem Unternehmen (z.B. Gruppe, Abteilung, Kollegium).

Organisationsmodellierung (organization modeling): Analysetechnik, die dazu dient, Rollen, Verantwortlichkeiten und Leitungsstrukturen zu beschrei-ben.

Peer Review: Technik der Qualitätssicherung. Eine kleine Gruppe von Stakehol-dern begutachtet und bewertet Ergebnisse der Projektarbeit, um Fehler oder Verbesserungsmöglichkeiten zu ermitteln.

Plan: Detaillierte Aufstellung, z.B. von Ereignissen, Abhängigkeiten, Abfolgen, Zeiten, Output, benötigten Ressourcen, Beteiligten, die zusammenwir-

ken, um etwas zu erreichen oder um etwas zu tun.

Priorisierung (prioritization): Vorgehen zur Bestimmung der relativen Bedeutungeiner Reihe von Vorhaben, um zu bestimmen, in welcher Reihenfolge siebearbeitet werden.

Produkt BA (product): Lösung oder ein Teil einer Lösung als Ergebnis eines Vor-habens.

Produkt Backlog (product backlog): Satz von User Stories, Anforderungen oder Lösungsmerkmalen, die als Kandidaten für eine mögliche Einführung prio-risiert und bewertet wurden.

Produktvision (product vision statement): Kurzgefasste Aussage über die Ziele, die mit einer Lösung erreicht werden sollen, und darüber, wie die Lösungdie Strategie der Unternehmung unterstützen soll.

Projekt (project): Zeitlich befristetes, in dieser konkreten Form einmaliges Vorhaben,mit dem ein Produkt, ein Service oder ein Ergebnis erreicht werden soll.

Projektmanager (project manager): Der für die Bearbeitung eines Projekts formalverantwortliche Leiter, der dafür zuständig ist, dass die Projektziele im vorgegebenen Rahmen, in der vorgegebenen Zeit und mit dem bewillig-ten Mitteleinsatz erreicht werden.

Glossar

529

p

Projektumfang (project scope): Aufgaben in einem Projekt, die erledigt werdenmüssen, um ein Produkt, einen Service oder ein Ergebnis mit spezifizier-ten Lösungsmerkmalen und Funktionen zu liefern.

Prototyp (prototype): Vorläufige (simulierte) Version einer späteren Lösung, die dazu dient, Anforderungen zu ermitteln oder die Erfüllung von Anforde-rungen zu demonstrieren.

Prozess (process): Reihe definierter Aktivitäten oder Bearbeitungsschritte, die arbeitsteilig und in gleicher Form wiederkehrend in einer Unternehmungbearbeitet werden. Geschäftsprozesse werden durch auslösende Ereig-nisse angestoßen und können unterschiedliche Ergebnisse zur Folge haben.Ein erfolgreicher Geschäftsprozess schafft Wert(e) für einen oder mehrereStakeholder.

Prozessmodell (process model): Grafische Darstellung des Flusses und der Steue-rung eines Prozesses mit den zu durchlaufenden Prozessschritten sowie der Faktoren, die den Prozess beeinflussen können. Einige Modelle werdenauch dazu verwendet, die Performance eines Prozesses zu simulieren.

Prozessverbesserung (process re-engineering): Neugestaltung von Geschäfts-prozessen, um die Performance zu steigern.

Qualität (quality): Eigenschaft einer Lösung oder eines Ergebnisses, die daran gemessen wird, inwieweit gegebene Ziele erreicht oder Anforderungen erfüllt werden.

Qualitätskriterien (quality attributes): Maßstäbe für die Messung der Qualität. Inder Software-Entwicklung: Maßstäbe zur Messung aller funktionalen wieauch nicht-funktionalen Anforderungen an eine Anwendung.

Qualitätssicherung (quality assurance): Maßnahmen und Vorkehrungen, die ergriffen werden, um sicherzustellen, dass ein Projekt, Service oder Produktdie erwarteten Qualitätskriterien erreicht.

RACI-Matrix (RACI = resposible, accountable, consulted and informed matrix): Technik zur Darstellung der Verantwortlichkeiten von Rollen oder Team-mitgliedern – dazu gehören die Aktivitäten, für die sie zuständig (reponsible)oder verantwortlich (accountable) sind, für die sie Informationen liefern (consulted) oder über die sie informiert (informed) werden müssen.

Regulierer (regulator): Stakeholder, der nicht zum Unternehmen gehört und fürdie Bestimmung und Durchsetzung von Standards zuständig ist.

Repository: Physische oder virtuelle Einrichtung, in der alle relevanten Informa-tionen zu einem bestimmten Sachverhalt aufbewahrt werden oder aus dem sie abgerufen werden können.

Glossar

530

q

r

Restriktion (constraint): Zwingende allgemeine Vorgaben, welche die Anzahl möglicher Lösungsvarianten einengen. Das können innerbetrieblich ver-ursachte Vorgaben sein (z.B. Budgetgrenzen) oder außerbetriebliche Vor-gaben (z.B. gesetzliche Vorschriften).

Restrisiko (residual risk): Risiko, das bleibt, nachdem Maßnahmen ergriffen oderPläne entwickelt wurden, wie mit dem ursprünglichen Risiko umgegangenwerden soll.

Retroperspektive (retroperspective): siehe Lessons-learned-Prozess.

Return on Investment (ROI): Kapitalverzinsung oder Kapitalrendite als Maß für den wirtschaftlichen Nutzen eines Projekts oder einer Investition.

Review (inspection): Formales, standardisiertes Verfahren der Qualitätssicherungdurch Experten mit festen Rollen und eindeutigen Dokumentationsregeln,bei dem mögliche Mängel, Schwachstellen oder Fehler sowie Kennzahlenermittelt werden.

RFI: siehe Informationsanfrage

RFP: siehe Ausschreibung

RFQ: siehe Anfrage

RFT: siehe Ausschreibung, offen

Richtlinie BA (guideline): Anweisung oder Beschreibung dazu, warum oder wieeine Aufgabe zu erledigen ist.

Risiko BA (risk): Unsicherheit hinsichtlich des Wertes einer Änderung oder der Wirksamkeit einer Lösung.

Risikoeinschätzung (risk assessment): Identifizieren, analysieren und bewerten von Risiken.

ROI: siehe Return on Investment

Schätzung (estimate): Quantitative Annahme über ein geplantes Ergebnis, benö-tigte Ressourcen und benötigte Zeiten bei vorhandener Unsicherheit.

Schnittstelle (interface): Gemeinsame Grenze zwischen Personen und/oder Systemen, auf der Informationen oder physische Objekte ausgetauscht werden.

Service BA: Erfüllung jeglicher Aufgaben oder Pflichten für einen Stakeholder, gesehen aus der Perspektive des Stakeholders.

SIPOC: siehe Suppliers, inputs, process, outputs and customers

SME: siehe Fachexperte

Software Engineer: siehe Entwickler

Glossar

531

s

SOW: siehe Statement of WorkSponsor: Stakeholder, der befugt ist, einen Bedarf zu bestimmen und ein

Vorhaben auszulösen, den Umfang festzulegen und der über die dafür notwendigen Mittel verfügen kann.

Stakeholder: Person oder Personengruppe, die eigene Interessen in ein Vor-haben einbringt oder auf die Lösung Einfluss nimmt.

Stakeholder-Analyse (stakeholder analysis): Identifikation und Analyse der Stake-holder, die von einer geplanten Änderung betroffen sind und Einschätzungvon deren Einfluss, Beteiligung und Bedarf im Rahmen einer Business-Analyse.

Stakeholder-Anforderung (stakeholder requirement): Beschreibung der Bedarfeeines Stakeholders oder einer Kategorie von Stakeholdern, die erfüllt seinmüssen, damit die Unternehmensanforderungen erfüllt werden können. Sie können als eine Brücke dienen zwischen den Unternehmensanforde-rungen und verschiedenen Kategorien von Lösungsanforderungen.

Stakeholder-Liste (stakeholder list): Aufstellung aller Stakeholder, die durch eineVeränderung, einen Bedarf oder eine vorgeschlagene Lösung betroffen sind, und eine Beschreibung deren Attribute und Merkmale in Bezug aufihre Beteiligung in dem Vorhaben.

Stakeholder-Stellvertreter BA (stakeholder proxy): Rolle, die ein Business-Analysteinnimmt, wenn er die Interessen eines Stakeholders oder einer Gruppe von Stakeholdern vertritt.

Standardprodukt (commercial off-the-shelf): Am Markt verfügbare fertige Lösung, die alle oder die meisten Anforderungen einer größeren Anzahl von Kunden abdeckt. Möglicherweise ist für die Nutzung in einem Unter-nehmen noch eine individuelle Konfigurierung notwendig.

Strategie (strategy): Beschreibung des Weges, den ein Unternehmen gehen will,um seine Fähigkeiten zur Erreichung der Ziele einzusetzen.

Strengths, weaknesses, opportunities and threats analysis: siehe SWOT

Strukturelle Geschäftsregel (definitional business rule): Regel, die aussagt, dass etwas nur richtig oder falsch sein kann. Die Regel erfordert oder verbietetKonzepte, Wissen oder Information.

Suppliers, Inputs, Process, Outputs and Customers (SIPOC): Technik um hoch-rangige Elemente eines Prozesses zu beschreiben. Kann im Zusammen-hang mit Prozessdokumentationen sowie mit „in/out of scope“-Werk-zeugen verwendet werden, die mehr Detail liefern.

Support (operational support): Stakeholder, die für das Management und die Wartung von Systemen oder Produkten im Tagesgeschäft zuständig sind.

Swimlane: Horizontale Zeilen oder vertikale Spalten, in die Symbole eines

Glossar

532

Ablaufdiagramms eingetragen werden, die jeweils durch einen spezifi-schen Aktor oder eine Rolle übernommen werden.

SWOT: Analysemodell, das verwendet wird, um die Einflussfaktoren (Stärken, Schwächen, Chancen und Risiken) eines Vorhabens und deren Wirkung zu verstehen.

System: Zusammenhang von wechselseitig abhängigen Komponenten, die auf verschiedenste Art und Weise interagieren, um gewünschte Ergebnisse hervorzubringen.

Technik (technique): Vorgehensweise, Methode oder eine Form, eine Aufgabe der Business-Analyse zu erledigen oder das Ergebnis zu gestalten.

Tester: Person, die dafür zuständig ist, dass eine Lösung daraufhin überprüft wird, ob die durch einen Business-Analysten definierten Anforderungen erfüllt sind, und die den Prozess der Verifizierung umsetzt.

UAT: siehe Anwendertest

Überleitungsanforderungen (transition requirements): Anforderungen an eine Lösung oder ein System, bzw. Bedingungen, die gegeben sein müssen, um den Wechsel von dem heutigen Zustand (Lösung) in einen zukünftigenZustand vollziehen zu können. Diese Anforderungen erledigen sich in dem Augenblick, wenn der Übergang vollzogen ist, sie sind damit nur temporärer Natur.

Umfang (scope): Grenzen einer Lösung, einer Veränderung, eines Bedarfs oder der Beeinflussbarkeit.

Umfrage (survey): Sammlung und Bewertung von Meinungen oder Erfahrungeneiner Gruppe von Personen durch eine Reihe von Fragen.

UML®: siehe Unified modeling language™

Ungeprüfte Anforderung (stated requirement): Anforderung eines Stakeholders,die noch nicht analysiert, verifiziert oder validiert ist. Sie reflektiert norma-lerweise eher die Wünsche eines Stakeholders als einen wirklichen Bedarf.

Unified modeling language™: Frei verfügbare, nicht-geschützte Sprache (Notation)zur Modellierung, Visualisierung, Spezifizierung und Dokumentation vonFunktionen und Arbeitsergebnissen von Software-Produkten, die objekt-orientiert entwickelt werden. Die in der Business-Analyse gebräuchlichstenUML®-Diagramme sind Use-Case-Diagramme, Activity-Diagramme, Zustandsdiagramme und Class-Diagramme.

Unternehmen (enterprise): Organisation, die bestimmte (in der Regel wirtschaft-liche) Ziele verfolgt und Produkte oder Leistungen für Kunden erbringt.

Glossar

533

t

u

Unternehmensarchitektur (business architecture): Design, Struktur und Verhaltendes gegenwärtigen oder zukünftigen Zustandes eines Unternehmens. Siesoll helfen, ein gemeinsames Verständnis über das Unternehmen zu schaf-fen, und dient auch dazu, die strategischen Ziele und die taktischen Anfor-derungen aufeinander abzustimmen.

Unternehmensentscheidung (business decision): Situative oder geplante Ent-scheidung, die auf Basis der Strategie, der Meinung des Managements, eines allgemeinen Konsens oder auf der Grundlage von Geschäftsregeln gefällt wird.

Unternehmenspolitik (business policy): Nicht-operative Vorgabe, welche die Akti-vitäten in einem Unternehmen beeinflusst und steuert.

Unternehmensziel (business goal): Zustand oder Ergebnis, das ein Unterneh-men nachhaltig anstrebt und eher qualitativ als quantitativ beschrieben wird.

Ursachenanalyse (root cause analysis): Strukturierte Untersuchung, welche Aus-löser letztlich einem bekannten Problem zugrundeliegen.

Use Case: Beschreibung des beobachtbaren Verhaltens zwischen Akteuren unddem betrachteten System, das sich ergibt, wenn ein Aktor das System nutzt, um ein bestimmtes Ziel zu erreichen.

Use-Case-Diagramm (use case diagram): Grafische Darstellung aus der UML®

(Unified Modeling Language) zur Abbildung aller Akteure und Use Caseseines bestimmten Systems oder Produkts.

User Story: Grobe, kurze und formlose Beschreibung solcher Leistungsmerk-male einer Lösung, die für einen Anwender wertvoll sind. Eine User Storybesteht normalerweise aus zwei oder drei Sätzen. Sie bietet die Mindest-information für einen Entwickler, um den notwendigen Entwicklungsauf-wand abzuschätzen.

Validierte Anforderung (validated requirement): Eine bereits darauf überprüfte Anforderung, dass sie dazu beiträgt, einen bestimmten Nutzen zu brin-gen und innerhalb des vorgegebenen Rahmens (scope) liegt.

Validierung (validation): Prozess der Überprüfung, ob ein Ergebnis für die beab-sichtigte Verwendung geeignet ist.

Validierungsmodell (proof of concept): Modell, das dazu dient, das Design einerLösung zu überprüfen, ohne die äußere Form, die notwendigen Ressour-cen oder die fertigen Prozesse zu zeigen, die von den Anwendern genutztwerden.

Veränderungsbereitschaft eines Unternehmens (enterprise readiness assessment):Bewertung, die beschreibt, inwieweit ein Unternehmen bereit ist, neue Lösungen zu akzeptieren und effektiv zu nutzen.

Glossar

534

v

Verhaltensregel (behavioral business rule): Geschäftsregel, die ein Verhalten, eine Aktion, eine Praxis oder ein Verfahren einfordert oder aber verbietet.Sie dient dazu, das Tagesgeschäft zu lenken. Wird auch operative Regel genannt.

Verifizierte Anforderung (verified requirement): Überprüfte Anforderung, bei derfestgestellt wurde, dass sie korrekt definiert ist, Standards oder Richt-linien genügt und in einem angemessenen Detaillierungsgrad dargestelltwird.

Verifizierung BA (verification): Prozess der Überprüfung von Arbeitsergebnissen imHinblick darauf, ob sie einen angemessenen Qualitätsstandard erreichen.

Vertikaler Prototyp (vertical prototype): Prototyp, der dazu dient, in die Details einer Lösung einzudringen, um Anforderungen und Design über mehrereDetaillierungsstufen hinweg zu ermitteln, die nicht einfach auf der Ober-fläche zu erkennen oder zu verstehen sind. Dazu kann auch die Inter-aktion zwischen mehreren Lösungsbestandteilen gehören.

Vorhaben (initiative): Jede(s) Projekt, Programm oder Aktion, das (die) ergriffen wird, ein Problem zu lösen oder bestimmte Ziele zu erreichen.

VSM: siehe Wertstromanalyse

Walkthrough: Systematisches Verfahren der Qualitätssicherung, bei dem die Beteiligten Schritt für Schritt ein Produkt oder eine Leistung überprüfen, um Anforderungen oder Designs zu validieren und dabei Fehler, unge-löste Sachverhalte, Inkonsistenzen oder Konflikte zu ermitteln.

WBS: siehe Aufgabenstrukturplan

Wegwerfprototyp (throw away prototype): Einfach herzustellender Prototyp, derlediglich dazu dient, Anforderungen der Anwender an die Benutzerstellezu definieren. Dazu werden sehr einfache Werkzeuge verwendet, unter Umständen sogar nur Papier und Bleistift. Dieser Prototyp wird später normalerweise nicht weiter genutzt.

Wert BA (value): Nutzen, die Bedeutung oder die Brauchbarkeit einer Sache füreinen Stakeholder in einem bestimmten Kontext.

Wertstromanalyse (value stream analysis): Vollständige, tatsachenbasierte Zeit-reihen-Darstellung des Flusses der Aktivitäten, die notwendig sind, um ein Produkt oder einen Service zu liefern.

Wettbewerbsfähigkeitsanalyse (competitive analysis): Strukturiertes Vorgehen zur Ermittlung der wesentlichen Merkmale eines Unternehmens mit demZiel, die langfristigen Rentabilitätschancen zu ermitteln und mit den Prak-tiken der wichtigsten Mitbewerber zu vergleichen.

Glossar

535

w

Wirkungsanalyse (change control): Überprüfung der Auswirkungen von neuen Anforderungen und Lösungen, um vor der Entscheidung und Umsetzungdie möglichen Konsequenzen zu verstehen.

Wirkungsanalyse (impact analysis): Prognosetechnik, die versucht, die Effekte verschiedener zukünftig möglicher Entscheidungen, Ereignisse oder Tat-bestände darzustellen und zu analysieren. Hier werden primär die Wir-kungen untersucht, die eine vorgeschlagene Veränderung auf einen Stakeholder, ein Projekt oder ein System haben.

Wissensgebiet BA (knowledge area): Fachgebiet, das mehrere spezifische Auf-gaben der Business-Analyse umfasst.

Workshop: Moderierte und zielorientierte Veranstaltung, bei der zentrale Stake-holder dazu beitragen, ein definiertes Ziel zu erreichen.

Zeitfenster (time box): Vorgegebener Zeitabschnitt, in dem eine bestimmte Auf-gabe erledigt oder ein Ereignis abgeschlossen sein muss.

Zeitlicher Auslöser (temporal event): Zeitbasiertes Ereignis, das den Beginn einesProzesses, die Bewertung von Geschäftsregeln oder eine andere Reaktionauslösen kann.

Zerlegung (decomposition): Verfahren, mit dessen Hilfe ein Problem in seine Bestandteile zergliedert wird, um so die Analyse zu erleichtern und die Komponenten besser zu verstehen.

Ziel (goal): siehe Unternehmensziel

Ziel (objective): siehe Betriebliche Zielsetzung

Zuordnung (allocation): siehe Zuordnung von Anforderungen

Zustandsdiagramm (state diagram): Analysemodell, das den Lebenszyklus einer Datenentität oder Klasse zeigt.

Glossar

536

z

537

Die folgende Übersicht zeigt alle Aufgaben aus dem BABOK®-Leitfaden, zudenen es im Kapitel 10 behandelte Techniken gibt.

Diese Zuordnung soll lediglich als Verweis dienen und keinesfalls bedeuten, dassdiese Techniken bei anderen Aufgaben nicht nutzbringend eingesetzt werdenkönnen, auch wenn sie dort nicht aufgeführt werden.

Anhang B: Techniken mit Aufgabenzuordnung

538

Techniken mit Aufgabenzuordnung

8. Lösun

gs-

bewertung

8.1 Lösung

s-Performan

cemessen

8.2 Leistung

s-kenn

zahlen

analysieren

8.3 Einschrän-

kung

en der

Lösung

beu

rtei-

len

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.2 Anforde

run-

gen verifizieren

7.3 Anforde

run-

gen validieren

7.6 Nutzenp

oten

-tia

l ana

lysieren

und Lösung

empfeh

len

7.6 Nutzenp

oten

-tia

l ana

lysieren

und Lösung

empfeh

len

6. Stra

tegische

Analyse

6.2 So

ll-Zu

stan

dde

finieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie

defin

ieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.5 Anforde

r-un

gen ge

neh-

migen

5.3 Anforde

run-

gen priorisieren

4. Erheb

ung un

dZu

sammen

arbe

it3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

10. Techn

iken

10.1 Akzep

tanz-

und Be

wer-

tung

skriterien

10.2 Backlog

Man

agem

ent

10.3 Balan

ced

Scorecard


539

8. Lösun

gs-

bewertung

8.1 Lösung

s-Performan

cemessen

8.2 Leistung

s-kenn

zahlen

analysieren

8.3 Einschrän-

kung

en der

Lösung

beu

rteilen

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.5 Design-

Optione

n de

finieren

7.5 Design-

Optione

n de

finieren

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie de

fi-nieren

6.2 So

ll-Zu

stan

dde

finieren

6.3 Risiken

bewerten

6.4 Cha

nge-

Strategie

defin

ieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

4. Erheb

ung un

dZu

sammen

arbe

it

4.2 Erhe

bung

durchfüh

ren

4.1 Erhe

bung

vorbereiten

4.2 Erhe

bung

durchfüh

ren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-Ana

-lyse (B

A) p

lane

n

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r BA

plane

n

3.4 Inform

ati-

onsm

anag

emen

tde

r BA

plane

n

3.5 Leistung

sver-

besserun

gen de

rBA

erm

itteln

10. Techn

iken

10.4 Ben

ch-

marking

und

Marktan

alyse

10.5 Brain-

storming


540

8. Lösun

gs-

bewertung

8.1 Lösung

s-Performan

cemessen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anfor-

derung

en

spezifizieren

un

d mod

ellieren

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.6 Nutzenp

oten

-tia

l ana

lysieren

und Lösung

empfeh

len

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie

defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.3 Risiken

bewerten

6.4 Cha

nge-

Strategie

defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie

defin

ieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.3 Anfor-

derung

en

priorisieren

5.4 Änd

erun

gen

von Anfor-

derung

en

beurteilen

4. Erheb

ung un

dZu

sammen

arbe

it3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

10. Techn

iken

10.6 Betrie

b-liche

Fäh

igkeits-

analyse

10.7 Business

Case

10.8 Darstellung

des Geschäfts-

mod

ells


541

8. Lösun

gs-

bewertung

8.3 Einschrän-

kung

en der

Lösung

beu

rtei-

len

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anfor-

derung

en

spezifizieren

un

d mod

ellieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.2 Anforde

run-

gen pflege

n

5.4 Änd

erun

gen

von Anforde

run-

gen be

urteilen

5.2 Anfor-

derung

en

pflege

n

4. Erheb

ung un

dZu

sammen

arbe

it

4.2 Erhe

bung

durchfüh

ren

4.2 Erhe

bung

durchfüh

ren

4.5 Zu

sammen

-arbe

it mit

Stakeh

olde

rn

man

agen

4.2 Erhe

bung

durchfüh

ren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

10. Techn

iken

10.9 Ana

lyse

der Geschäfts-

rege

ln

10.10 Gem

ein-

scha

ftliche

Spiele

10.11 Be

griffs-

mod

ellierung

10.12 Data

Dictio

nary

10.13 Daten

-flu

ssdiag

ramme


542

8. Lösun

gs-

bewertung

8.1 Lösung

s-Performan

cemessen

8.2 Leistung

s-kenn

zahlen

analysieren

8.3 Einschrän-

kung

en der

Lösung

beu

rteilen

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

8.5 Maß

nahm

enzur S

teigerun

g de

sNutzens der

Lösung

empfehlen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.4 Anforde

-rung

sarchitektur

defin

ieren

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.2 Anfor-

derung

en

pflege

n

4. Erheb

ung un

dZu

sammen

arbe

it

4.1 Erhe

bung

vorbereiten

4.2 Erhe

bung

durchfüh

ren

4.2 Erhe

bung

durchfüh

ren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

10. Techn

iken

10.14 Data

Mining

10.15 Daten

-mod

ellierung


543

8. Lösun

gs-

bewertung

8.1 Lösung

s-Performan

cemessen

8.3 Einschrän-

kung

en der

Lösung

beu

rtei-

len

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

8.5 Maß

nahm

enzur Wertsteige-

rung

der Lösun

gem

pfeh

len

8.4 Ein-

schrän

kung

ende

s Unter-

nehm

ens

beurteilen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.3 Anfor-

derung

en

validieren

7.5 Design-

Optione

n de

finieren

6. Stra

tegische

Analyse

6.2 So

ll-Zu

stan

dde

finieren

6.3 Risiken

bewerten

6.4 Cha

nge-

Strategie

defin

ieren

6.2 So

ll-Zu

stan

dde

finieren

6.1 Ist-Zu

stan

dan

alysieren

6.3 Risiken

bewerten

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.3 Anfor-

derung

en

priorisieren

5.4 Änd

erun

gen

von Anfor-

derung

en

beurteilen

5.5 Anfor-

derung

enge

nehm

igen

5.2 Anfor-

derung

en

pflege

n

5.4 Änd

erun

gen

von Anfor-

derung

en

beurteilen

4. Erheb

ung un

dZu

sammen

arbe

it

4.1 Erhe

bung

vorbereiten

4.2 Erhe

bung

durchfüh

ren

4.3 Erhe

bung

s-erge

bnisse

bestätigen

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

10. Techn

iken

10.16 En

t-sche

idun

gs-

analyse

10.17 En

tschei-

dung

s-mod

ellierung

10.18 Dok

u-men

tena

nalyse


544

8. Lösun

gs-

bewertung

8.5 Maß

nahm

enzur Wertsteige-

rung

der Lösun

gem

pfeh

len

8.1 Lösung

s-Performan

cemessen

8.5 Maß

nahm

enzur Steige

rung

des N

utzens der

Lösung

empfeh

-len

77. A

nforde

rung

s-an

alyse un

dDe

sign-De

finition

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

7.3 Anforde

run-

gen validieren

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.4 Anforde

-rung

sarchitektur

defin

ieren

6. Stra

tegische

Analyse

6.4 Cha

nge-

Strategie

defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.3 Risiken

bewerten

6.4 Cha

nge-Stra-

tegie defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

6.4 Cha

nge-

Strategie

defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-Stra-

tegie defin

ieren

5. M

anag

emen

t des

Anforderun

gs-

Lebe

nszyklus

5.3 Anforde

run-

gen priorisieren

5.4 Änd

erun

gen

von Anforde

run-

gen be

urteilen

5.3 Anfor-

derung

en

priorisieren

5.4 Änd

erun

gen

von Anfor-

derung

en

beurteilen

5.1 Anforde

run-

gen rückverfolge

n

5.2 Anforde

run-

gen pflege

n

4. Erheb

ung un

dZu

sammen

arbe

it

4.1 Erhe

bung

vorbereiten

4.2 Erhe

bung

durchfüh

ren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

10 .Techn

iken

10.19

Schä

tzun

g

10.20 Fina

nz-

analyse

10.21 Foku

s-grup

pen

10.22 Funk

-tio

nale

Gliede

rung


545

8. Lösun

gs-

bewertung

8.2 Leistung

s-kenn

zahlen

analysieren

8.3 Ein-

schrän

kung

ende

r Lösung

beurteilen

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

77. A

nforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.4 Anforde

-rung

sarchitektur

defin

ieren

7.5 Design-

Optione

n de

finieren

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

d de

finieren

6.3 Risiken

bewerten

6.4 Cha

nge-

Strategie

defin

ieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.4 Änd

erun

gen

von Anforde

run-

gen be

urteilen

5.3 Anfor-

derung

en

priorisieren

5.4 Änd

erun

gen

von Anfor-

derung

en

beurteilen

4. Erheb

ung un

dZu

sammen

arbe

it

4.2 Erhe

bung

durchfüh

ren

4.1 Erhe

bung

vorbereiten

4.2 Erhe

bung

durchfüh

ren

4.3 Erhe

bung

s-erge

bnisse

bestätigen

4.4 Bu

sine

ss-

Ana

lyse-

Inform

atione

nko

mmun

izieren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

3.4 Inform

ati-

onsm

anag

e-men

t de

r Bu

si-

ness-Ana

lyse

plan

en

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.23 Glossar

10.24 Schn

itt-

stellena

nalyse

10.25 Interviews


546

8. Lösun

gs-

bewertung

8.3 Ein-

schrän

kung

ende

r Lösung

beurteilen

8.4 Ein-

schrän

kung

ende

s Unter-

nehm

ens

beurteilen

77. A

nforde

rung

s-an

alyse un

dDe

sign-De

finition

7.2 Anfor-

derung

en

verifizieren

7.3 Anfor-

derung

en

validieren

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.3 Anfor-

derung

en

priorisieren

5.4 Änd

erun

gen

von Anfor-

derung

en

beurteilen

5.5 Anfor-

derung

enge

nehm

igen

4. Erheb

ung un

dZu

sammen

arbe

it3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

3.4 Inform

ati-

onsm

anag

e-men

t de

r Bu

si-

ness-Ana

lyse

plan

en

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.26 Ite

mTracking


547

8. Lösun

gs-

bewertung

8.3 Ein-

schrän

kung

ende

r Lösung

beurteilen

8.4 Ein-

schrän

kung

ende

s Unter-

nehm

ens

beurteilen

8.1 Lösung

s-Performan

cemessen

8.2 Leistung

s-kenn

zahlen

analysieren

77. A

nforde

rung

s-an

alyse un

dDe

sign-De

finition

7.5 Design-

Optione

n de

finie-

ren

7.2 Anforde

run-

gen verifizieren

7.3 Anforde

run-

gen validieren

7.6 Nutzenp

oten

-tia

l ana

lysieren

und Lösung

empfeh

len

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.3 Risiken

bewerten

6.4 Cha

nge-

Strategie

defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

4. Erheb

ung un

dZu

sammen

arbe

it

4.5 Zu

sammen

-arbe

it mit

Stakeh

olde

rnman

agen

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

3.4 Inform

ati-

onsm

anag

e-men

t de

r Bu

sine

ss-

Ana

lyse plane

n

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Analyse erm

itteln

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.27 Lesson

sLearne

d

10.28 Ken

n-zahlen

und

Key-

Performan

ce-

Indikatoren


548

8. Lösun

gs-

bewertung

8.1 Lösung

s-Performan

cemessen

8.1 Lösung

s-Performan

cemessen

8.2 Leistung

s-kenn

zahlen

analysieren

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.5 Design-

Optione

n de

finieren

7.1 Anfor-

derung

en

spezifizieren

un

d mod

ellieren

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.3 Risiken

bewerten

6.4 Cha

nge-

Strategie

defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

4. Erheb

ung un

dZu

sammen

arbe

it

4.1 Erhe

bung

vorbereiten

4.2 Erhe

bung

durchfüh

ren

4.2 Erhe

bung

durchfüh

ren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.4 Inform

ati-

onsm

anag

e-men

t de

r Bu

si-

ness-Ana

lyse

plan

en

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.29 Mind

Map

ping

10.30 Ana

lyse

nicht-funk

tiona

-ler Anforde

run-

gen

10.31 Be

obach-

tung


549

8. Lösun

gs-

bewertung

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

8.5 Maß

nahm

enzur Steige

rung

des Nutzens der

Lösung

empfeh

-len

8.5 Maß

nahm

enzur Steige

rung

des Nutzens der

Lösung

empfeh

-len

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

8.5 Maß

nahm

enzur Steige

rung

des Nutzens der

Lösung

empfeh

-len

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anfor-

derung

en

spezifizieren

un

d mod

ellieren

7.4 Anforde

-rung

sarchitektur

defin

ieren

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie

defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.3 Anfor-

derung

en

priorisieren

4. Erheb

ung un

dZu

sammen

arbe

it

4.2 Erhe

bung

durchfüh

ren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.32 Orga-

nisatio

ns-

mod

ellierung

10.33 Priorisie-

rung

10.34 Prozess-

analyse


550

8. Lösun

gs-

bewertung

8.4 Ein-

schrän

kung

ende

s Unter-

nehm

ens

beurteilen

8.1 Lösung

s-Performan

cemessen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anfor-

derung

en

spezifizieren

un

d mod

ellieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

6. Stra

tegische

Analyse

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie

defin

ieren

6.2 So

ll-Zu

stan

dde

finieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.2 Anfor-

derung

en

pflege

n

4. Erheb

ung un

dZu

sammen

arbe

it

4.2 Erhe

bung

durchfüh

ren

4.2 Erhe

bung

durchfüh

ren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-Ana

-lyse plane

n

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

3.4 Inform

ati-

onsm

anag

e-men

t de

r Bu

si-

ness-Ana

lyse

plan

en

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.35 Prozess-

mod

ellierung

10.36 Proto-

typing


551

8. Lösun

gs-

bewertung

8.2 Leistung

s-kenn

zahlen

analysieren

8.3 Einschrän-

kung

en der

Lösung

be

urteilen

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

8.5 Maß

nahm

enzur Steige

rung

des Nutzens der

Lösung

em

pfeh

len

77. A

nforde

rung

s-an

alyse un

dDe

sign-De

finition

7.2 Anforde

run-

gen verifizieren

7.3 Anforde

run-

gen validieren

7.3 Anforde

run-

gen validieren

7.6 Nutzenp

oten

-tia

l ana

lysieren

und Lösung

empfeh

len

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.3 Risiken

bewerten

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.5 Anfor-

derung

enge

nehm

igen

5.3 Anfor-

derung

en

priorisieren

5.4 Änd

erun

gen

von Anfor-

derung

en

beurteilen

4. Erheb

ung un

dZu

sammen

arbe

it

4.3 Erhe

bung

s-erge

bnisse

bestätigen

4.4 Bu

sine

ss-

Ana

lyse-In

for-

matione

n ko

mmun

izieren

4.1 Erhe

bung

vorbereiten

4.5 Zu

sammen

-arbe

it mit

Stakeh

olde

rnman

agen

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.37 Re

view

s

10.38 Risiko

-an

alyse un

d -m

anag

emen

t


552

8. Lösun

gs-

bewertung

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

8.2 Leistung

s-kenn

zahlen

analysieren

8.3 Einschrän-

kung

en der

Lösung

beu

rtei-

len

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.5 Design-Optio-

nen de

finieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.4 Anforde

-rung

sarchitektur

defin

ieren

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.3 Risiken

bewerten

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie de

fi-nieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

4. Erheb

ung un

dZu

sammen

arbe

it3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse erm

it-teln

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

10. Techn

iken

10.39 Ro

llen-

und Zu

stän

dig-

keitsmatrix

10.40 Ursache

n-an

alyse

10.41 Scop

e-Mod

ellierung

(Mod

ellierung

der System

-gren

zen)


553

8. Lösun

gs-

bewertung

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

6. Stra

tegische

Analyse

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

4. Erheb

ung un

dZu

sammen

arbe

it

4.1 Erhe

bung

vorbereiten

4.5 Zu

sammen

-arbe

it mit Stake-

holdern man

a-ge

n

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

10. Techn

iken

10.42 Sequ

enz-

diag

ramme

10.43 Stake-

holder-Listen,

-Karten od

erPerson

as

10.44 Status-

mod

ellierung


554

8. Lösun

gs-

bewertung

8.1 Lösung

s-Performan

cemessen

8.2 Leistung

s-kenn

zahlen

analysieren

8.3 Ein-

schrän

kung

ende

r Lösung

beurteilen

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

8.5 Maß

nahm

enzur Steige

rung

des Nutzens

der Lösung

empfeh

len

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.5 Design-

Optione

n de

finieren

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.3 Risiken

bewerten

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

4. Erheb

ung un

dZu

sammen

arbe

it

4.2 Erhe

bung

durchfüh

ren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

3.4 Inform

ati-

onsm

anag

e-men

t de

r Bu

si-

ness-Ana

lyse

plan

en

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.45 Umfrag

eod

er Frage

-bo

gen


555

8. Lösun

gs-

bewertung

8.4 Ein-

schrän

kung

ende

s Unter-

nehm

ens

beurteilen

8.1 Lösung

s-Performan

cemessen

8.1 Lösung

s-Performan

cemessen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.1 Anforde

run-

gen spezifizieren

und mod

ellieren

7.5 Design-

Optione

n de

finieren

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie

defin

ieren

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.4 Cha

nge-

Strategie

defin

ieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.2 Anfor-

derung

en

pflege

n

5.2 Anfor-

derung

en

pflege

n

4. Erheb

ung un

dZu

sammen

arbe

it3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

10. Techn

iken

10.46 SW

OT-

Ana

lyse

10.47 Use Cases

und Szen

arien

10.48 User

Stories

10.49 Anb

ieter-

Assessm

ent


556

8. Lösun

gs-

bewertung

8.4 Einschrän-

kung

en des

Unterne

hmen

sbe

urteilen

7. Anforde

rung

s-an

alyse un

dDe

sign-De

finition

7.4 Anforde

-rung

sarchitektur

defin

ieren

7.5 Design-

Optione

n de

finieren

7.6 Nutzen-

potential

analysieren

und Lösung

empfeh

len

6. Stra

tegische

Analyse

6.1 Ist-Zu

stan

dan

alysieren

6.2 So

ll-Zu

stan

dde

finieren

6.3 Risiken

bewerten

6.4 Cha

nge-

Strategie

defin

ieren

5. M

anag

emen

tde

s Anforde

rung

s-Lebe

nszyklus

5.3 Anforde

run-

gen priorisieren

5.4 Änd

erun

gen

von Anforde

run-

gen be

urteilen

5.5 Anforde

run-

gen ge

nehm

i-ge

n

4. Erheb

ung un

dZu

sammen

arbe

it

4.2 Erhe

bung

durchfüh

ren

4.3 Erhe

bung

s-erge

bnisse

bestätigen

4.4 Bu

sine

ss-

Ana

lyse-In

for-

matione

n ko

m-

mun

izieren

3. Planu

ng und

Überwachu

ng der

Busin

ess-An

alyse

3.1 Ansatz de

rBu

sine

ss-

Ana

lyse plane

n

3.2 Einb

indu

ngde

r Stakeh

olde

rplan

en

3.3 Steu

erun

gde

r Bu

sine

ss-

Ana

lyse plane

n

3.4 Inform

ati-

onsm

anag

e-men

t de

r Bu

si-

ness-Ana

lyse

plan

en

3.5 Leistung

s-verbesserung

ende

r Bu

sine

ss-

Ana

lyse

ermitteln

10. Techn

iken

10.50 Work-

shop

s

557

Die folgenden Inhalte wurden unverändert aus der englischen Originalausgabedes IIBA® übernommen.

Body of Knowledge CommitteeContent for this release was primarily developed by the Body of KnowledgeCommittee:• Angela M. Wick, CBAP, PMP, PBA

• Emily Iem, CBAP, PMP: Chairperson

• John M. A. Burns, MSc, BSc, CEng

• Joy Beatty, CBAP, PMI-PBA

• Masahiko Soh

• Matthew W. Leach, CBAP

• Peter Lefterov, CBAP

• Phil Vincent, CBAP, M. Comp. Sci., PMP

• Shane Hastie, CBAP, MIM, ICE-VM

• Julian Sammy

• Laura Paton, CBAP, MBA, PMP: Past Chairperson

• Tom Burke, CBAP, MS, CSPO

Body of Knowledge Operations TeamThe following individuals partnered with and supported all stakeholders toprovide the framework for content development and delivery:• Kevin Brennan, CBAP, OCEB, PMP, Executive Vice President, Product Management and Development, IIBA: Sponsor

• Paul Stapleton, Standards and Publications Manager, IIBA: Editor

• Sandi Campbell, Project Manager, IIBA: Project Manager

Anhang C: Contributors

Content ContributorsThe following individuals contributed additional content used in this revision:

Contributors

• Alberto Vasquez

• Ales Stempihar

• Ali Mazer, CBAP, MBA

• Andrew Guitarte, CBAP, DBA, PMP

• Angie Perris, CBAP, MBA, PMP

• Anne Fomim, CBAP

• Beth Faris, CBAP

• Brian T. Hunt, CBAP, I.Eng., FInstLM

• Cari J. Faanes-Blakey, CBAP, PMI - PBA

• Charles Bozonier, CBAP

• Christina D. Harris, ITIL, BA

• Colleen S. Berish, AIT

• Dean J. Larson, CBAP

• Dena Loadwick, CBAP

• Edwina Simons, CBAP, MBA, SSGB

• Ellan Kay Young

• Gagan Saxena

• Georgy Saveliev, CBAP

• Greg Geracie

• Heather Mylan-Mains, CBAP

• Inger Dickson, CBAP

• James (Jim) Baird, CMC

• James Taylor

• Janet Wood, CBAP

• Jason Andrew Oliver, CBAP, MBA, CISSP

• Jason Frink, CBAP

• Jason Questor

• Jennifer Battan, CBAP

• Jennifer Swearingen

• Josh Jones, CBAP

• Dr. Joyce Statz

• Judith A. Haughton, CBAP, MBA

• Jules Prevost, CBAP

• Kelly Morrison Smith, MBA, MS

• Manish S. Nachnani, CBAP, PMP, CSM

• Marcelo Neves, CBAP

• Maria Amuchastegui, CBAP, CTFL, CSM

• Marsha B. Hughes, CBAP, PMP, CSM

• Martin Schedlbauer, CBAP, PhD

• Maureen McVey, CBAP

• McNaughton Lebohang, CBAP, BSc (Hons) CS, PMP

• Mike Crawford

• Mike Rosen

• Milena Komitska, PhD

• Muhammad Saad Rahman, CBAP, M.Sc., PMP

• Neale Croutear-Foy, BA (Hons.),FBCS, FInstLM

• Norman A. Thuswaldner, CBAP

• Paul Mulvey, CBAP

• Poonam Dhanwani

• Ricardo Pereira, CBAP

558

Expert Advisory and Review GroupThe following industry experts generously provided IIBA® with advice and guidanceon the scope and content of version 3.0 of the BABOK® Guide during its planningand development, and helped to shape the content and direction of this release:

Contributors

559

• Richard Larson, CBAP, PMP, PMI-PBA

• Ronald G. Ross

• Sean P. Boylan, CBAP, MAppLing

• Sergio Conte

• Sherri L. Nowak, CBAP, MSM

• Silke Goodwin, CBAP

• Steven Blais, PMP, PBA

• Suneet K. Garg, CBAP, TOGAF 9, CBPP

• Suzanne R. Burgess, CBAP

• Tharshan Sreetharan, CBAP, PMP, MBA

• Thea Rasins

• Thomas (Tom) Barker, CBAP, PhD, PMP

• Tina M. Underhill

• Victoria Cupet, CBAP, PMP, PMI- PBA

• Barbara A. Carkenord, CBAP, PMI-PBA, PMP

• Bill Bigler, PhD

• Brian Cameron

• Chuck Walrad

• Elizabeth Larson, CBAP, PMP, CSM

• Ellen Gottesdiener, SM, CPS

• Gladys S. W. Lam

• Greg Geracie

• James Robertson

• James Taylor

• Jason Questor

•Jeff Scott

• Kent J. McDonald

• Kitty Hass

• Linda R. Finley

• Mary Gorman, CBAP, CSM, PMI- PBA

• Mike Rosen

• Peter H.M. Brooks, B.Sc., FSM

• Roger T. Burlton, P. Eng, CMC

• Ronald G. Ross

• Suzanne Robertson

• Whynde Kuehn

Practitioner ReviewersThe following individuals participated in the practitioner review of version 3.0,and provided feedback used to help to shape the content and direction of thePublic Review Draft:

The following individuals also served as review team leads:

• Billie Johnson, CBAP, PBA, CSM

• Camille L. Spruill, CBAP, PMP, CSM

• Chaithanya Atthanti, CBAP

• Jeanette Moore-Loggins, CBAP, BA, MBA,

• Kimberley Byron, CBAP

• Peter Johnson, CBAP

• Tom Karasmanis

Contributors

560

• Aljaž Prusnik, CBAP

• Angela Musa, CBAP

• Annette Brice, CBAP

• Ashok Kaushal

• Barbara J Monaco, CBAP

• Beth Gomolka, CBAP, PMP, CSP

• Carol R. Drew, CBAP

• Cei Sanderson, CSPO

• Charles Raj, CBAP, B. Com., FCA

• Chen-Kuang Yu

• Cherie Wagner

• Devendra Shrikant Upadhye, CBAP

• Diana Cagle, CBAP, MBA

• Fabrício Laguna, CBAP, PMP, MBA

• Geoffrey Griffin, CBAP

• Iavi Rotberg

• Jayesh Jain, CBAP, B.Sc., CSPO

• Joe Goss

• Joseph F. Ruffolo

• Karen Gras, CBAP

• Kathleen C. McGoey

• Laith Obeidat, CBAP

• Laura R. Walker, LSS

• Lenche Pandovska, CBAP

• Lily V. Dang, CBAP

• Lynn Parkin, CCBA

• Michael D. Western, CBAP

• Nicolae Crudu, CCBA

• Partha Pratim Das, PMP, CSM

• Richard Freeley, CBAP

• Robert Dyason

• Steven J. Gara, CBAP, MS

• Teri A. McIntyre, CBAP, CAPM, MA

• Theodora Tonkovska

• Tolani J Hassan, ISEB

• Tricia K. Dreixler, CBAP

• Wayne Li

• Yoshinori Tanaka, CBAP

• Zoya Roytblat, CBAP

Agile ExtensionContent for this version includes content from the Agile Extension to the BABOK®

Guide. IIBA® would like to thank the following contributors to the Agile Extensionto the BABOK® Guide:

Enterprise Business Analysis Extension DraftContent for this version includes content from the Enterprise Business AnalysisExtension to the BABOK® Guide Draft. IIBA® would like to thank the followingcontributors to the Enterprise Business Analysis Extension to the BABOK® GuideDraft:

Version 3.0 also includes content developed for previous versions of the BABOK®

Guide.

Contributors

561

• Ali Mazer

• Brian Hemker

• Carol Scalice

• Chris Matts

• David C. Cook

• David Morris

• Dennis Stevens

• Ellen Gottesdiener

• Kevin Brennan

• Luiz Claudio Parzianello

• Marsha Hughes

• Pascal Van Cauwenberghe

• Paul Stapleton, Editor

• Peter Gordon

• Shane Hastie

• Steve Erlank

• Susan Block

• Charlie Huai-Ling Ch'ng

• Dean Larson

• Jason Questor

• Joanne Dong

• Kevin Brennan

• Matt Northrup

• Neil Burton

• Nitza Dovenspike

• Phillip Quinn

• Ron Babin

Other Significant Contributors• Aminah Nailor, CBAP

• Annie Thomas, CPAP

• Rose Ha, CBAP

• Bernard Aschwanden, Publishing Smarter: Layout and Design

• Irena Duniskvaric, Publishing Smarter: Illustrations

• Lynda Sydney, Ignite Writing Services: Copy Editing

• SOS Design Inc.: Cover

• Vic Bhai, Technical Writer/Editor, IIBA: Technical Writing

Additional ThanksIIBA® and the Body of Knowledge Committee would like to thank all thosepractitioners of business analysis who have provided us with comments andfeedback over the years, as well as those who have provided us with feedbackon the Public Review Draft.

Version 2.0

Body of Knowledge Committee

Content for this release was primarily developed by the Body of KnowledgeCommittee:• Kevin Brennan, CBAP, OCEB, PMP, Vice President, Professional Development

• Barbara A. Carkenord, MBA, CBAP

• Mary Gorman, CBAP

• Kathleen B. Hass, PMP

• Brenda Kerton, MA

• Elizabeth Larson, CBAP, PMP

• Richard Larson, CBAP, PMP

• Jason Questor

• Laura Paton, MBA, CBAP, PMP (Project Manager)

Contributors

562

Content Contributors

The following individuals contributed additional content used in this revision:

The Graphics Team developed graphics and graphics standards:

Version 2.0 also includes content developed for previous versions of the BABOK®

Guide.

Expert Advisory and Review Group

The following industry experts generously provided IIBA® with advice and guidanceon the scope and content of version 2.0 of the BABOK® Guide during its planningand development, and helped to shape the content and direction of this release:

Contributors

• Tony Alderson

• James Baird

• Jake Calabrese, CBAP

• Bruce C. Chadbourne, PgMP, PMP

• Karen Chandler

• Carrolynn Chang

• Richard Fox, CBAP

• Rosemary Hossenlopp

• Peter Gordon, CBAP


• Monica Jain

• Cherifa Mansoura Liamani, PhD

• Karen Little

• Laura Markey

• Richard Martin

• Gillian McCleary

• William B. Murray

• Angie Perris, CBAP

• David Wright

• Carl Gosselin

• Perry McLeod, CBAP, PMP

• Alexandre Romanov

• Patricia Sandino

• Maggie Yang

• Scott Ambler

• James Baird

• Kurt Bittner

• Rafael Dorantes

• Robin F. Goldsmith, JD


• Paul Harmon

• Dean Leffingwell

563

Practitioner Reviewers

The following individuals participated in the practitioner review of version 2.0,and provided feedback used in the revision of the Public Review Draft:

Contributors

• Gladys S.W. Lam

• Kent J. McDonald

• Mark McGregor

• Meilir Page-Jones

• James Robertson

• Suzanne Robertson

• Ronald G. Ross

• David Ruble

• Steve Tockey

• Sharon M. Aker

• Betty H. Baker, CBAP

• B. D. Barnes PhD, PE, PMP, CSSBB

• Jennifer S. Battan, CBAP

• Subrahmanya Gupta Boda

• Craig W. Brown, MPM, CSM

• Cathy Brunsting

• Peter Burg, PMP

• Greg Busby, CBAP

• Diana Cagle, MBA, CBAP

• Duncan Cairns

• Bruce Chadbourne, PgMP, PMP

• Carrollynn Chang

• Patricia Chappell, CBAP, MBA

• Mark Cheek, PMP

• Huai-Ling Ch'ng, CBAP

• Desirée Purvis (née Chu), CBAP

• Pauline Chung

• Joseph Da Silva

• Nitza Dovenspike

• James Downey, PhD, PMP

• Tamer El-Tonsy, CISA, PRINCE2, ITIL

• Steve Erlank, BSc, BCom (Hons)

• Margaret Gaino Ewing, MBA,CBAP

• Stephanie Garwood, CBAP

• Joe Goss

• Karen Gras, CBAP

• Kwabby Gyasi

• Bob Hillier, PMP

• Billie Johnson, CBAP

• Peter Johnson, CBAP

• Hans Jonasson, CBAP, PMP

• Barbara Koenig

• Steven R. Koss, MBA

• Douglas Kowalczyk

• Robert Lam, MBA, ISP


• Karen Little, CBAP

• Joy Matthews

• Perry McLeod, CBAP, PMP

564

The following individuals also served as review team leads:

• Cathy Brunsting



• Robert Lam, MBA, ISP

Version 1.6

Body of Knowledge Committee

• Kathleen Barret (President)

• Kevin Brennan, CBAP, PMP (Vice-President)

• Barbara Carkenord, MBA, CBAP

• Mary Gorman, CBAP

• Kathleen B. Hass, PMP

• Brenda Kerton

• Elizabeth Larson, CBAP, PMP


• Dulce Oliveira

• Cleve Pillifant

Contributors

565

• Holly M. Meyer

• Michael Mohammed

• Brian Monson, PMP

• Nancy A. Murphy, PMP, CBAP

• Richard L. Neighbarger, CSQA, CSQE

• Tony Newport, CBAP

• Samia Osman

• Cecilia Rathwell

• Suzanna Etheridge Rawlins, PMP

• Helen Ronnenbergh

• Zoya Roytblat

• Christopher Ryba

• Julian Sammy

• Keith Sarre, CBAP

• Laura Schleicher

• Fred Seip

• Thomas Slahetka, CBAP

• Warren Steger

• Leah Sturm, CBAP

• James M. Szuch

• Robin Tucker

• Krishna Vishwanath

• A. S. Umashankar

Contributors to Version 1.6

Reviewers of Version 1.6

Contributors

566

• Tony Alderson

• Finny Barker

• Neil Burton

• Karen Chandler

• Richard Fox, CBAP

• Rosemary Hossenlopp

• Peter Gordon, CBAP

• Monica Jain

• Peter Kovaks

• Chris Matts

• Laura Markey

• Patricia Martin

• Richard Martin

• Rosina Mete

• William Murray

• Harish Pathria

• Kathleen Person

• Tony Rice

• John Slater

• Mark Tracy

• Jacqueline Young

• Sharon Aker

• Betty H. Baker, CBAP

• Jo Bennett

• Cathy Brunsting

• Carrollynn Chang, CBAP


• Pauline Chung

• Joseph R. Czarnecki


• May Jim, CBAP

• Day Knez

• Barb Koenig

• Robert Lam

• Cherifa Mansoura Liamani, PhD

• Gillian McCleary

• Kelly Piechota

• Howard Podeswa

• Leslie Ponder

• Cecilia Rathwell

• Jennifer Rojek

• Keith Sarre, CBAP

• Jessica Gonzalez Solis

• Jim Subach

• Diane Talbot

• Krishna Vishwanath

• Marilyn Vogt

• Scott Witt

569

Die folgenden Inhalte wurden unverändert aus der englischen Originalausgabedes IIBA® übernommen.

OverviewVersion 3 of the BABOK® Guide has extensively revised, restructured, andrewritten BABOK® Guide version 2.0. This summary of changes provides anoverview of where topics covered in version 2.0 may be found in version 3. Thissummary is not a complete description of the changes, and in some cases thescope of a task or technique has changed significantly at a lower level.

Introduction

Business Analysis

The definition of this primary concept has been updated to align with otherchanges in the BABOK® Guide, specifically the Business Analysis Core ConceptModel™ (BACCM™).

Business Analysis Key Concepts

Business Analysis Core Concept Model™ (BACCM™) (NEW)

A model comprised of six terms that have a common meaning to all businessanalysis practitioners and helps them discuss business analysis and its relationshipsin common terminology.

Requirements and Design (NEW)

This section describes the distinction between and overlap of two key businessanalysis concepts: requirements and design.

Anhang D: Summary of Changes fromBABOK® Guide v 2.0

Knowledge Areas

Business Analysis Planning and Monitoring

The focus and name of this knowledge area remains the same for version 3.

Some tasks were renamed, one new task was added and some elements weremoved around. Version 3 continues to address the business analyst's role indefining the business analysis work and defining the approach for the initiative.

Elicitation (Version 2.0 name) is now

Elicitation and Collaboration (Version 3 name)

The focus of this knowledge area remains similar but has expanded to includecommunication topics from version 2.0 and the new topic of collaboration.

In addition, the simpler content from version 2.0 was expanded to provide moreguidance for practitioners. Also, an explicit reference to unplanned elicitation is

570

Summary of Changes from BABOK® Guide v 2.0

2.0 Task: Business Analysis Planningand Monitoring

3.0 Task: Business Analysis Planning andMonitoring

2.1 Plan Business Analysis Approach

Prioritization and Change Managementcontent shifted to 3.3 Plan BusinessAnalysis Governance

3.1 Plan Business Analysis Approach

2.2 Conduct Stakeholder Analysis 3.2 Plan Stakeholder Engagement

2.3 Plan Business Analysis Activities 3.1 Plan Business Analysis Approach

2.4 Plan Business Analysis Communication

3.2 Plan Stakeholder Engagement

2.5 Plan Requirements ManagementProcess

Prioritization and Change Managementcontent shifted to 3.3 Plan BusinessAnalysis Governance

3.4 Plan Business Analysis InformationManagement

2.6 Manage Business Analysis Performance

3.5 Identify Business Analysis Performance Improvements

made to acknowledge the informal elicitation that can occur during conversation.Business analysis information is also referenced throughout rather than justrequirements as the object of elicitation.

Requirements Management and Communication (Version 2.0 name)

is now Requirements Life Cycle Management (Version 3 name)

Requirements Life Cycle Management was determined to be a more appropriatename for this knowledge area in order to emphasize that requirements havetheir own life cycle and that requirements management is an ongoing activity.

Communication activities were shifted from this knowledge area to the Elicitationand Collaboration knowledge area.


571

2.0 Task: Elicitation 3.0 Task: Elicitation and Collaboration

3.1 Prepare for Elicitation 4.1 Prepare for Elicitation

3.2 Conduct Elicitation Activity 4.2 Conduct Elicitation

3.4 Confirm Elicitation Results 4.3 Confirm Elicitation Results

3.3 Document Elicitation Results 4.4 Communicate Business AnalysisInformation

n/a 4.5 Manage Stakeholder Collaboration

2.0 Task: Requirements Managementand Communication

3.0 Task: Requirements Life CycleManagement

4.1 Manage Solution Scope and Requirements

Solution Scope Management is addres-sed within 5.1 Trace Requirements.Conflict and Issue Management andPresenting Requirements for Review are addressed in 5.5 Approve Require-ments.

5.1 Trace Requirements

5.5 Approve Requirements

Enterprise Analysis (Version 2.0 name) is now

Strategy Analysis (Version 3 name)

This knowledge area has taken on a new name and expanded purpose.

Enterprise Analysis focused on the upfront work the business analyst conductedat the start of a project. Strategy Analysis is broader and includes the work thebusiness analyst conducts to understand the current state of the business, todefine the desired future state, to develop a change strategy to achieve thedesired business outcomes and to assess the risks inherent in the change stra-tegy.


572

4.2 Manage Requirements Traceability

Relationships and ConfigurationManagement are addressed in 5.1Trace Requirements. Impact Analysis isaddressed in 5.4 Assess RequirementsChanges.

5.1 Trace Requirements

5.4 Assess Requirements Changes

4.3 Maintain Requirements for Reuse 5.2 Maintain Requirements

4.4 Prepare Requirements Package 4.4 Communicate Business AnalysisInformation

4.5 Communicate Requirements 4.4 Communicate Business AnalysisInformation

5.3 Prioritize Requirements

Moved from 6.1 Prioritize Requirements(v2.0)

N/A 5.5 Approve Requirements

New task which includes the conceptsfrom the v2 Elements Conflict and IssueManagement , Presenting Require-ments for Review and Approval fromthe v2 Task Manage

Requirements Analysis (Version 2.0 name) is now

Requirements Analysis and Design Definition (Version 3 name)

This knowledge area was renamed to accommodate expanded content.

Version 3 now addresses the topic of design and explains where business analystshave involvement with design activities. Requirements Analysis and Design Defi-nition also incorporates some of the tasks from the version 2.0 Solution Assess-


573

2.0 Task: Enterprise Analysis 3.0 Task: Strategy Analysis

5.1 Define Business Need

Business Problem or Opportunity isaddressed in 6.1 Analyze Current State.Business Goals and Objectives andDesired Outcome are addressed in 6.2Define Future State.

6.1 Analyze Current State, 6.2 DefineFuture State

5.2 Assess Capability Gaps

Current Capability Analysis is addressedin 6.1 Analyze Current State. Assess-ment of New Capability Requirementsand Assumptions are addressed in 6.2Define Future State.

6.1 Analyze Current State, 6.2 DefineFuture State, 6.4 Define Change Strategy

Define Change Strategy includes a GapAnalysis which was not explicitly identi-fied in 5.2 Assess Capability Gaps butwas the intent of the task.

5.3 Determine Solution ApproachAlternative Generation and

Assumptions and Constraints areaddressed in 6.2 Define Future State.Ranking and Selection of Approaches isaddressed in 7.5 Define Design Optionsand 7.6 Analyze Potential Value andRecommend Solution.

6.2 Define Future State, 7.5 DefineDesign Options (v3 RequirementsAnalysis and Design Definitionknowledge area), 7.6 Analyze PotentialValue and Recommend Solution (v3Requirements Analysis and DesignDefinition knowledge area)

5.4 Define Solution Scope 6.4 Define Change Strategy

5.5 Define Business Case 7.6 Analyze Potential Value andRecommend Solution (RequirementsAnalysis and Design Definitionknowledge area), 10.7 Business Cases(Technique)

574

ment and Validation. Activities involved with the proposed solution assessment– before any construction of a solution; whether in part or in whole – are nowpart of this Requirements Analysis and Design Definition.


2.0 Task: Requirements AnalysisN/A 3.0 Task: Requirements Analysis andDesign Definition

6.1 Prioritize Requirements 5.3 Prioritize Requirements (v3 Requirements Life Cycle Manage-ment knowledge area)

6.2 Organize Requirements 7.4 Define Requirements Architecture

6.3 Specify and Model Requirements 7.1 Specify and Model Requirements

6.4 Define Assumptions andConstraints

Assumptions and Business Constraintsare addressed in 6.2 Define FutureState. Technical Constraints are addres-sed in 7.6 Analyze Potential Value andRecommend Solution

6.2 Define Future State (v3 StrategyAnalysis knowledge area) and 7.6Analyze Potential Value and Recom-mend Solution

6.5 Verify Requirements 7.2 Verify Requirements

6.6 Validate Requirements 7.3 Validate Requirements

N/A 7.5 Define Design Options

New task in Requirements Analysis andDesign Definition which incorporates5.3 Determine Solution Approach (v2.0Enterprise Analysis knowledge area),7.1 Assess Proposed Solution (v2.0Solution Assessment and Validationknowledge area), and 7.2 AllocateRequirements (v2.0

Solution Assessment and Validationknowledge area)

Solution Assessment and Validation (Version 2.0 name) is now

Solution Evaluation (Version 3 name)

The version 3 knowledge area provides less focus on implementing a solutionand more focus on evaluating solutions.

The knowledge area includes content on evaluating whether value is being deli-vered by a solution and discusses the business analyst's role in assessing what ishindering an organization from receiving full value from a solution.


575

N/A 7.6 Analyze Potential Value and Recom-mend Solution

New task in Requirements Analysis andDesign Definition which incorporates5.5 Define Business Case (v2.0 Enter-prise Analysis knowledge area) and 7.1Assess Proposed Solution (v2.0 SolutionAssessment and Validation knowledgearea)

2.0 Task: Solution Assessment andValidation

3.1 Task: Solution Evaluation

7.1 Assess Proposed Solution 7.5 Define Design Options and 7.6Analyze Potential Value and Recom-mend Solution (v3 Requirements Analy-sis and Design Definition knowledgearea)

7.2 Allocate Requirements 7.5 Define Design Options (v3 Require-ments Analysis and Design Definitionknowledge area)

7.3 Assess Organizational Readiness 6.4 Define Change Strategy (v3 Stra-tegy Analysis knowledge area)

576

Underlying Competencies

Analytical Thinking and Problem Solving

• NEW – Conceptual Thinking• NEW – Visual Thinking

Behavioural Characteristics

• Ethics – removed• Personal Organization – renamed and expanded Organization and Time Management

• NEW – Personal Accountability• NEW – Adaptability


7.4 Define Transition Requirements 6.4 Define Change Strategy (v3 StrategyAnalysis knowledge area),

2.3 Requirements Classification Schema

7.5 Validate Solution 8.3 Assess Solution Limitations

7.6 Evaluate Solution Performance 8.5 Recommend Actions to IncreaseSolution Value

N/A 8.1 Measure Solution Performance

New task that incorporates definingsolution performance measures andmeasuring the actual performance

N/A 8.2 Analyze Performance Measures

New task that focuses on comparingthe actual value (solution performance)against the expected value

N/A 8.4 Assess Enterprise Limitations

New task that identifies what, externalto the solution, may be preventing itfrom delivering its expected value

Business Knowledge• Business Principles and Practices – renamed Business Acumen• NEW – Methodology Knowledge

Communication Skills• Oral Communications – renamed Verbal Communication• Teaching – moved to Interaction Skills• NEW – Non-verbal Communication• NEW – Listening

Interaction Skills• Facilitation and Negotiation – split competencies and renamed Facilitation

• NEW – Negotiation and Conflict Resolution

Software Applications (Version 2.0 name) is nowTools and Technology (Version 3 name)

• General-Purpose Applications – renamed Office Productivity Tools and Technology

• Specialized Applications – renamed Business Analysis Tools and Technology

• NEW – Communication Tools and Technology

Techniques

Name or Focus Change

• Benchmarking and Market Analysis (v2.0 Benchmarking)• Data Dictionary (v2.0 Data Dictionary and Glossary)• Glossary (v2.0 Data Dictionary and Glossary)• Reviews (v2.0 Structured Walkthrough)• Risk Analysis and Management (v2.0 Risk Analysis)• Use Cases and Scenarios (v2.0 Scenarios and Use Cases)• User Stories• Workshops (v2.0 Requirements Workshop)


577


578

New Techniques

• Backlog Management• Balanced Scorecard• Business Capability Analysis• Business Case• Business Model Canvas• Collaborative Games• Concept Modelling• Data Mining• Decision Modelling• Financial Analysis• Mind Mapping• Prioritization• Process Analysis• Roles and Permissions Matrix• Stakeholder List, Map, or Personas

Perspectives (NEW)

Perspectives are used within business analysis work to provide focus to tasksand techniques specific to the context of the initiative.

Most initiatives are likely to engage one or more perspectives. The perspectivesincluded in the BABOK® Guide are:

• Agile• Business Intelligence• Information Technology• Business Architecture• Business Process Management.

These perspectives do not presume to represent all the possible perspectivesfrom which business analysis is practiced. The perspectives discussed in theBABOK® Guide represent some of the more common views of business analysisat the time of writing.

Perspectives are not mutually exclusive, in that a given initiative might employmore than one perspective.

Stichwortverzeichnis

A

B

ACCORD 508

Adaptive Case Management 509

Akzeptanz 33

Akzeptanz- und Bewertungskriterien 257

Analyse der Geschäftsregeln 285

des Projektportfolios 489

nicht-funktionaler Anforderungen 356

Strategische 5, 117

Analytisches Denken 223

Anbieter-Assessment 425

Anforderungen 18, 22

analysieren 164

beurteilen 108

genehmigen 112

modellieren 162

pflegen 98

priorisieren 102

Anforderungen

Attribute der 53

Betriebliche 19

Eigenschaften der 169

Funktionale 19

Nicht-funktionale 19

rückverfolgen 93

spezifizieren 161

validieren 171

verifizieren 167

Wiederverwendbarkeit von 52

Anforderungsanalyse 5, 157

Anforderungsarchitektur definieren 174

Anforderungs-Lebenszyklus, agiler 5, 89

Anpassungsfähigkeit 234

Anwender 20

Aufgaben 6

BACCM™ 14

Backlog Management 261

Basiskompetenzen 8, 223

Basiskompetenzen der Business-Analyse 4

Begriffsmodellierung 291

Behaviour Driven Development 441

Benchmarking 267

Beobachtung 359

579


Brainstorming 269

Branchenkenntnis 237

Business-Analyse 2, 17

Business-Analyse

Ansatz der 28

Informationen 79

Informationsmanagement der 25

Kernkonzept der 13

Steuerung der 25, 43

Business-Analyse

Werkzeuge der 252

Business-Analyst 3, 20

Business Case 277

Business-Intelligence-Perspektive 448

Business Motivation Model 488

Business-Process-Management-Perspektive 498

Business Process Reengineering 509

D

C Capability Map 488

Change-Strategie 147, 151

Continuous Improvement 509

Cost Analysis 510

Critical to Quality 510

Crystal Clear 439

Customer Journey Map 488

Cycle-time Analysis 510

Darstellung des Geschäftsmodells 280

Data Dictionary 293

Data Mining 300

Datenflussdiagramme 295

Datenmodellierung 304

Define Measure Analyze Design Verify 510

Denken, Konzeptionelles 228

Kreatives 224

Visuelles 229

Design 17, 22

-Definition 5, 157

-Optionen 180, 188

-Qualität 169

Deskriptive Analyse 454

Detaillierungsgrad 30

Disciplined Agile Delivery 439

Dokumentenanalyse 318

Drum-Buffer-Rope 510

Dynamic Systems Development 439

Effect Analysis 510

Entscheidungsfindung 225

Entscheidungsmodellierung 313

Erhebung 5, 61

durchführen 70

vorbereiten 65

Erhebungstechniken 67

Ethik 231

Evaluierung 57

Evolutionary Project Management 439

Extreme Programming 439

E

580


581

H

I

G

Fachexperte 20

Fähigkeiten, betriebliche 214

Fähigkeitsanalyse, betriebliche 272

Failure Mode 510

Feature Driven Development 439

Finanzanalyse 324

Fokusgruppen 330

Formalisierungsgrad 30

Fragebogen 413

Frameworks 507

Funktionale Gliederung 333

F

House of Quality 510

Gap-Analyse 150

Gemeinschaftliche Spiele 288

Geschäftsarchitektur-Perspektive 480

Geschäftsverständnis 236

Glossar 337

Governments Strategic Reference Model 508

Information Map 488

Informationsmanagement 49

Informationstechnologie-Perspektive 463

Infrastruktur 136

Inputs, Guide, Outputs, Enablers 511

Interaktionsfähigkeit 245

Interview 342

Ist-Zustand analysieren 121

Item Tracking 346

Kaizen Event 511

Kanban 440

Kenntnis 239

Kennzahlen 349

Kernkonzept 14

Kernkonzept-Modell 26, 62, 91, 119, 158, 195

Key-Performance-Indikatoren 349

Kommunikation,

Nonverbale 243

Schriftliche 243

Verbale 242

Kommunikationsfähigkeit 241

Kommunikationswerkzeuge 254

Konfliktlösung 248

Kultur 136

Kunde 20

K


582

N

M

L Leadership 246

Lean 509

Leistungskennzahlen 197

analysieren 201

Leistungsverbesserungen der Business-Analyse 25, 55

Lernen 226

Lessons Learned 348

Lieferant 22

Lösung 239

empfehlen 185

Lösungsanforderungen 19

Lösungsbewertung 5, 193

Lösungs-Performance 197

Lösungsraum 135

Nutzen 188 Nutzenpotential analysieren 185

Marktanalyse 267

Maßnahmen zur Steigerung des Nutzens 217

Methodenkenntnis 240

Mind Mapping 353

Model based and Integrated Process Improvement 508

Moderation 245

MoSCoW-Priorisierung 441

P

O Office-Anwendungen 250

Organisation 18

Organisationsmodellierung 362

Organisationsstruktur 136, 213

Organizational Map 488

Personas 408, 441

Perspektive 10, 431, 432

der Business-Analyse 4

Pilot 193

Plan 18

Planung und Überwachung 25


Planungsansatz 30

Priorisierung 46, 366

Problemlösung 223, 227

Process Classification Framework 508

Process Simulation 511

Prognose 455

Programmierte Entscheidung 455

Projektmanager 21, 504

Prototypen 193

Prototyping 380

Prozessanalyse 369

Prozessanalyst/-designer 504

Prozessarchitekt 504

Prozessmodellierer 505

Prozessmodellierung 373


583

R

Scaled Agile Framework 440

Schätzung 320

Schnittstellenanalyse 339

Scope 135, 173


der Lösung 150

des Change-Vorhabens 11

Scope-Modellierung 397

Scrum 440

Selbstorganisation 233

Sequenzdiagramme 401

Service-orientierte Analyse 489

Six Sigma 509

Soll-Zustand definieren 130

Sponsor 21

Stakeholder 8, 19

Einbindung der 25

Statusmodellierung 409

Steuerungsprozess des Change 45

Story Decomposition 442

Story Mapping 442

Storyboarding 442

Support 21

SWOT-Analyse 416

Systemdenken 227

Szenarien 419

Referenzmodelle 486

Regulierer 21

Release 193

Release-Planung 152

Ressourcen 137

Retrospektiven 442

Reviews 383

Risiken bewerten 141

Risiko 18

Risikoanalyse 387

Risikomanagement 387

Roadmap 489

Rollen 38

Rollenmatrix 391

S

Techniken 257


Technologie 136, 250

Tester 22

The Open Group Architecture Framework 489

Theory of Constraints 509, 511

Total Quality Management 509

Traceability 51

T


584

Value Added Analysis 511

Value Mapping 489

Value Stream Analysis 511

Verantwortlichkeit, Persönliche 232

Verhalten 230

Verhandlung 248

Vertrauenswürdigkeit 232

Zachman Framework 489

Zeitmanagement 233

Ziele, betriebliche 134

Zuhören 244

Zusammenarbeit 5, 61, 247

mit Stakeholdern 83

Zuständigkeitsmatrix 391

Überleitungsanforderungen 19

Umfrage 413

Umsetzungsexperte 21

Umsetzungsteam 504

Unternehmen 17

Unternehmenskenntnis 239

Unternehmenskultur 212

Unternehmenspolitische Vorgaben 136

Unternehmerisches Verständnis 236

Ursachenanalyse 394

Use Cases 419

Use-Case-Diagramm 420

User Stories 423

Werkzeuge 250

Wertstromanalyse 442

Wirkungsanalyse 110

Wissensvermittlung 249

Workshop 427

U

V

W

Z

IIBA®

Das International Institute of BusinessAnalysis™ (IIBA®) ist eine unabhängige,nicht gewinnorientierte Organisation,die 2003 mit dem Ziel gegründetwurde, dem aufstrebenden Fachgebiet„Business-Analyse“ zu dienen.

Als die Stimme der Community derBusiness-Analyse unterstützt IIBA® dieAnerkennung des Berufes und arbeitetdaran, Standards für die Anwendungund für die Zertifizierung zu erarbeiten.IIBA® verbindet durch ein globales Netz-werk Mitglieder, Chapter, Unternehmenund Partner in der ganzen Welt, umden Beruf der Business-Analyse zu för-dern. So wird eine Community vonFachexperten gebildet, die dazu bei-trägt, bessere betriebliche Ergebnissezu erzielen.

Für Individuen, die in einem breitenSpektrum an Rollen – Business-Analyse,Systemanalyse, Anforderungsanalyse,Projektmanagement, Beratung, Prozess-verbesserung usw. – tätig sind, bietetIIBA® Ressourcen, die dazu beitragen,die eigene Karriere zu fördern.

Als IIBA®-Mitglied erhalten Expertender Business-Analyse einen breitenZugang zu Erfahrungen, Wissen undSupport. IIBA® unterstützt die Entwick-lung einer professionellen Karriere undbietet ihren Mitgliedern unter anderem:

• Zugang zu wichtigen Werk-zeugen und Erfahrungen, ein-schließlich Webinars, Tipps, Best Practices, Online-Bibliothek und Newsletter

• Einbindung in ein globales Netz-werk zum Lernen und zur Kooperation

• Möglichkeit, zusammen mit Berufskollegen ein eigenes Chapter zu bilden

• Unterstützung, um erfolgreich zu arbeiten, Anerkennung zu finden und Berufschancen wahrzunehmen

• Kostenloser Zugang zu PDF- und eBook-Versionen des BABOK® Guide

• Ermäßigte Gebühren bei IIBA®-Zertifizierungen.

585

IIBA®-ZertifizierungenIIBA®-Zertifizierungen sind heute derglobal anerkannte Standard für dieBusiness-Analyse.

Viele heutige Zertifizierungen auf demGebiet der Business-Analyse deckenzwar zentrale Fähigkeiten, wie zum Bei-spiel das Anforderungsmanagement,ab. Die IIBA®-Zertifizierung geht jedochüber diese Grundlagen hinaus und lie-fert einen einzigartigen Wert.

IIBA® fordert die Experten auf, mit derBusiness-Analyse die Strategie mit derUmsetzung zu verbinden, die lang-fristigen Chancen zu realisieren, die miteinem Change-Vorhaben verbundensind, sowie Innovation und Prozessver-besserung mit technologischen Verän-derungen zu verbinden. Dies bedeutet,dass IIBA®-zertifizierte Experten in derLage sind, zu dem gesamten Erfolgeines Unternehmens beizutragen undnicht nur daran beteiligt sind, ein abge-grenztes Projekt zeitgerecht und imRahmen der vorgegebenen Kostenabzuliefern.

Die IIBA®-Zertifizierung liefert viele Vor-teile, wie zum Beispiel:

• Einführung und Nutzung von Best-Practices der Business-Analyse durch Individuen, die als kompetent anerkannt sind

• qualitativ hochwertige, kon-sistente Lösungen werden effizient und effektiv erarbeitet

• Anerkennung als kompetenter und erfahrener Business-Analyst durch Kollegen, Kunden und andere Stakeholder

• professionelle Weiterentwicklungfür erfahrene Experten der Business-Analyse

• sichtbarer Einsatz für das Gebiet der Business-Analyse, die zuneh-mend für alle Bereiche eines Unternehmens als bedeutend anerkannt wird.

586

sgo-verein.ch › wp-content › uploads › sites › 2 › ...business analysis body of knowledge...

Documents