(CFLBA) Lehrplan Versin 1.1 Deutschsprachige Ausgabe 10. Dezember 2013
Internatinal Qualificatins Bard fr Business Analyse
Cpyright-Hinweis Das vrliegende Dkument darf als Ganzes der in Auszügen vervielfältigt werden, unter der Vraussetzung, dass die Quelle angegeben wird. Cpyright-Hinweis Internatinal Qualificatins Bard fr Business Analyse (im Flgenden IQBBA genannt) IQBBA ist ein eingetragenes Warenzeichen der gasq Service GmbH. Urheberrecht 2011 der Autren an Versin vm 9 April 2014 (Karlina Zmitrwicz (Vrsitzende), Alexey Alexandrv, Alan Calder, Eric Riu du Csquer, Maureen Denning, Michał Figarski, Werner Henschelchen, Alexey Lemeshev, Beata Karpińska, Judy McKay, Ingvar Nrdström, Alain Ribault, Dariusz Paczewski, Dmitry Parilv, Yves Suvenir, Rbert Treffny) Alle Rechte vrbehalten. Die Autren übertragen hiermit das Urheberrecht an das Internatinal Qualificatins Bard fr Business Analyse (IQBBA). Die Autren (als derzeitige Urheberrechtsinhaber) und das IQBBA (als zukünftiger Urheberrechtsinhaber) haben flgenden Nutzungsbedingungen zugestimmt: 1) Jede Einzelpersn und Seminaranbieter darf diesen Lehrplan als Grundlage für Seminare verwenden, sfern die Autren und das IQBBA als Quelle und Inhaber des Urheberrechts an diesem Lehrplan angegeben werden. Des Weiteren darf der Lehrplan zu Werbungszwecken für Schulungen erst erwähnt werden, nachdem die Kursunterlagen zur ffiziellen Akkreditierung durch ein vm IQBBA anerkanntes natinales Bard eingereicht wurden. 2) Jede Einzelpersn der Gruppe vn Einzelpersnen darf den Lehrplan als Grundlage für Artikel, Bücher der andere abgeleitete Veröffentlichungen verwenden, sfern die Autren und das IQBBA als Quelle und Urheberrechtsinhaber des Lehrplans genannt werden. 3) Jedes vm IQBBA anerkanntes natinale Bard darf den Lehrplan übersetzen und den Lehrplan (bzw. die Übersetzung) an andere Parteien lizensieren. Versin 2013 Page 3 f 114 9. April 2014
Änderungsübersicht Versin Datum Bemerkungen 1.0 07.06.2011 Erste Versin des Certified Fundatin Level Business Analyst Lehrplan 1.1 14.02.2013 Aktualisierte erste Versin des Certified Fundatin Level Business Analyst Lehrplan Versin 2013 Page 4 f 114
Inhaltsverzeichnis Dank... 7 Einführung in den Lehrplan... 7 Zweck des Dkuments... 7 Die Prüfung... 7 Akkreditierung... 7 Internatinalität... 8 Kgnitive Ebenen des Wissens... 8 Detaillierungsgrad... 8 Aufbau des Lehrplans... 8 1. Grundlagen der Business Analyse (K2)... 9 2. Unternehmensanalyse (K3)...20 3. Planung des Business Analyse-Przesses (K3)...33 4. Anfrderungserhebung (K3)...44 5. Anfrderungsanalyse (K3)...55 6. Lösungsvalidierung (K3)...67 7. Werkzeuge und Techniken (K3)...71 8. Kmpetenzen (K2)...78 9. Przessverbesserung (K2)...84 10. Innvatin, Design und der Kunde (K2)...89 11. Referenzen...105 Standards...105 Bücher und snstige Publikatinen...105 12. Anhang A Lernziele/Kgnitive Ebenen des Wissens...108 Level 1: Kennen (K1)...108 Level 2: Verstehen (K2)...108 Level 3: Anwenden (K3)...108 13. Anhang B Verwendete Regeln bei der Erstellung des IQBBA Lehrplans...109 Fundatin Level-Lehrplan...109 Allgemeine Regeln...109 Aktualität...109 Lernziele...109 Gesamtstruktur...109 14. Referenzen...111 Infrmatinsquellen...111 Versin 2013 Page 5 f 114
15. Anhang C Hinweise für Ausbildungsanbieter...112 Index...113 Versin 2013 Page 6 f 114
Dank Internatinal Qualificatins Bard fr Business Analysis, Wrking Party Fundatin Level (Ausgabe 2011): Karlina Zmitrwicz (Vrsitzende), Alexey Alexandrv, Alan Calder, Eric Riu du Csquer, Maureen Denning, Michał Figarski, Werner Henschelchen, Alexey Lemeshev, Beata Karpińska, Judy McKay, Ingvar Nrdström, Alain Ribault, Dariusz Paczewski, Dmitry Parilv, Yves Suvenir, Rbert Treffny), swie alle natinalen Bards für Vrschläge zur vrliegenden Versin des Lehrplans. Einführung in den Lehrplan Zweck des Dkuments Dieser Lehrplan definiert die Basisstufe (Fundatin Level) des Ausbildungsprgramms zum IQBBA Certified Fundatin Level Business Analyst (CFLBA). Das IQBBA hat diesen Lehrplan in Zusammenarbeit mit der Glbal Assciatin fr Sftware Quality (kurz GASQ) entwickelt. Dieser Lehrplan dient als Grundlage für Seminaranbieter, die ihre Kurse akkreditieren lassen möchten. Sämtliche Inhalte dieses Lehrplans müssen in den Kursunterlagen enthalten sein. Der Lehrplan sllte außerdem als Richtlinie zur Vrbereitung auf die Zertifizierungsprüfung dienen. Alle darin aufgeführten Bereiche sind prüfungsrelevant. Die Prüfung Die Prüfung Certified Fundatin Level Business Analyst basiert auf diesem Lehrplan. Alle Abschnitte dieses Lehrplans können geprüft werden. Die Prüfungsfragen beschränken sich dabei nicht auf ein einziges Kapitel, sndern können kapitelübergreifend Inhalte aus mehreren Kapiteln abfragen. Das Frmat der Prüfung ist Single Chice (eine Antwrt vn vier Antwrtptinen ist richtig). Prüfungen können unmittelbar im Anschluss an einen akkreditierten Kurs abgelegt werden, der auch unabhängig davn in einer ffenen Prüfung (hne vrherige Kursteilnahme). Detaillierte Infrmatinen zu den Prüfungsterminen finden Sie auf der jeweiligen Website vn GASQ (www.gasq.rg) und vm IQBBA (www.iqbba.rg). Akkreditierung Die Schulungsanbieter vn IQBBA Certified Fundatin Level Business Analyst Kursen müssen akkreditiert sein. Die Akkreditierung durch das IQBBA erflgt, nachdem ein Expertenausschuss die Kursunterlagen des Schulungsanbieters geprüft hat. Ein akkreditierter Kurs ist ein Kurs, der als zu diesem Lehrplan knfrm anerkannt wurde. Als slcher darf der Kurs als Bestandteil eine ffizielle Certified Fundatin Level Business Analyst-Prüfung (kurz CFLBA-Prüfung) enthalten. Prüfungen können darüber hinaus auch vn unabhängigen Zertifizierungsstellen abgehalten werden (gemäß den Regelungen vn ISO 17024). Versin 2013 Page 7 f 114
Internatinalität Der Lehrplan wurde vn einer Gruppe internatinaler Experten entwickelt. Der Lehrplaninhalte können daher als internatinaler Standard gelten. Durch diesen Lehrplan wird es möglich, dass Ausbildungen und Prüfungen internatinal auf gleichem Niveau durchgeführt werden. Kgnitive Ebenen des Wissens Der Lehrplaninhalt wurde in drei verschiedene kgnitive Ebenen des Wissens eingestuft. Anhand dieser Einteilung erkennt der Lernende die kgnitive Stufe, die für das jeweilige Thema gefrdert wird. Im vrliegenden Lehrplan gelten die drei kgnitiven Stufen K1, K2 und K3 wie flgt: K1 - sich erinnern, erkennen, wiedergeben/kennen K2 - verstehen, erklären, begründen, vergleichen, klassifizieren, zusammenfassen K3 - in einem bestimmten Kntext anwenden Detaillierungsgrad Der Detaillierungsgrad dieses Lehrplans erlaubt internatinal knsistentes Lehren und Prüfen. Um dieses Ziel zu erreichen, enthält dieser Lehrplan Flgendes: Allgemeine Lernziele, welche die Intentin der Fundatin Level-Zertifizierung beschreiben. Eine Liste mit den Inhalten, die zu lehren sind, einschließlich einer Beschreibung und, w ntwendig, Referenzen auf weiterführende Infrmatinsquellen. Lernziele für jedes Wissensgebiet, welche das kgnitive Ergebnis der Schulung und die zu erzielende Einstellung des Teilnehmers beschreiben. Eine Liste vn Begriffen, welche der Teilnehmer verstehen und wiedergeben können sll. Eine Beschreibung der wichtigen zu lehrenden Knzepte, einschließlich Quellen wie anerkannte Fachliteratur, Nrmen und Standards. Der Lehrplan ist keine vllständige Beschreibung des Wissensgebiets Business Analyse. Er reflektiert lediglich den nötigen Umfang und Detaillierungsgrad, welcher in den Fundatin Level- Schulungen behandelt werden sll. Aufbau des Lehrplans Der Lehrplan ist in zehn Hauptkapitel gegliedert. Jeder Haupttitel eines Kapitels zeigt die anspruchsvllste Lernzielkategrie/höchste kgnitive Stufe, welche mit dem jeweiligen Kapitel abgedeckt werden sll und legt die Unterrichtszeit fest, welche in einem Kurs mindestens für dieses Kapitel aufgewendet werden muss. Versin 2013 Page 8 f 114
1. Grundlagen der Business Analyse (K2) 100 Minuten Begriffe: Anfrderung, Anfrderungsarten, Artefakt, Business Analyse, Business Analyst, Klassifikatin vn Anfrderungen, Standard, Verflgbarkeit Lernziele für die Grundlagen der Business Analyse Die Lernziele legen fest, was Sie nach Beenden des jeweiligen Mduls gelernt haben sllten. 1.1 Warum ist Business Analyse ntwendig (K2) LO-1.1.1 LO-1.1.2 Anhand vn Beispielen beschreiben können, wie eine nicht vrhandene der unvllständige Business Analyse zum Scheitern eines Prjekt führen kann. (K2) Erklären können, weshalb Business Analyse ntwendig ist und Beispiele dafür anführen können. (K2) 1.2 Was ist Business Analyse (K2) LO-1.2.1 LO-1.2.2 LO-1.2.3 LO-1.2.4 Die Begriffe Business Analyse und Business Analyst definieren können. (K1) Die allgemeinen Ziele der Business Analyse kennen. (K1) Beispiele für die Ziele der Business Analyse in verschiedenen Phasen des Sftwarelebenszyklus nennen können. (K2) Die Beziehung zum Lösungslebenszyklus kennen. (K1) 1.3 Kernknzepte der Business Analyse (K2) LO-1.3.1 Die Kernknzepte der Business Analyse erklären können. (K2) 1.4 Wissensgebiete (K1) LO-1.4.1 Die Wissensgebiete der Business Analyse kennen. (K1) 1.5 Aufgaben und Verantwrtlichkeiten (K2) LO-1.5.1 LO-1.5.2 Die Hauptaufgaben vn Business Analysten kennen. (K1) Die Rlle und Verantwrtlichkeiten eines Business Analyst in unterschiedlichen Prjektphasen erklären können. (K2) Versin 2013 Page 9 f 114
1.1. Warum ist Business Analyse ntwendig? (K2) 20 Minuten Lernziele des Abschnitts Prbleme mit den Anfrderungen können die Ursache für das Scheitern vn Prjekten sein. In den meisten Fällen werden diese Prbleme durch eine Business Analyse verursacht, die schlecht der falsch durchgeführt wurde (insbesndere im Requirements Engineering, eines der Wissensgebiete der Business Analyse). Zu den häufigen Prblemstellungen in der Business Analyse gehören (K2): Mehrdeutige, unterspezifizierte, unklare, unmögliche, widersprüchliche Geschäftsanfrderungen Instabilität der Anfrderungen (häufige und unkntrllierte Änderung der Anfrderungen) Schlechte Übertragung des Unternehmensbedarfs in Anfrderungen (unvllständige, inknsistente der nicht messbare Anfrderungen) Unklare Ziele der Initiative Kmmunikatinsprbleme Sprachbarrieren Wissensbarrieren Vage Frmulierungen Übermäßig frmale Ausdrucksweise Redundanz Verglden der Lösung (durch Hinzufügen vn unnötigem Umfang) Unzureichende Einbindung der Anwender Übersehene Anwenderklassen Minimale Spezifikatin Die erwähnten Themen können später zu Prblemen führen, z.b. bei Festlegung des Lösungsumfangs, Planung, Umsetzung und beim Testen. Unklare Anfrderungen der ein qualitativ schlechter Entwurf der Geschäftslösung können zu Verwirrung und Fragen hinsichtlich des geplanten Sftwareprdukts der der Geschäftsprzesslösung führen. Wenn keine Maßnahmen ergriffen werden, um diesen Missstand zu beseitigen, erhöht sich das Risik für ein Scheitern des Prjekts. Die Auswirkungen vn nicht fachgerechten Geschäftsanalysen auf Prjekte sind längst bekannt, werden aber trtzdem häufig vernachlässigt. Die Hauptgründe für die Vernachlässigung der Business Analyse sind (K2): Zeitdruck Ausschließliche Fkussierung auf die Erzielung schneller Ergebnisse Ausschließliche Fixierung auf die Ksten Versin 2013 Page 10 f 114
Die Wahrnehmung vn Dkumentatin, Analyse und Verstehen der Geschäftsprzesse eines Unternehmens als Ksten, und nicht als Mehrwert Mögliche Flgen einer Vernachlässigung der Business Analyse (K2) sind: Einige Geschäftsprzesse des Unternehmens sind nicht bekannt der werden nicht richtig verstanden; dies kann sich wie flgt auswirken: Anfrderungen sind ungenau Anfrderungen sind mehrdeutig (können unterschiedlich interpretiert werden) Anfrderungen sind widersprüchlich Anfrderungen erfüllen die vereinbarten Kriterien nicht (z.b. Qualitätskriterien) Anfrderungen fehlen Geschäftsprzesse und Artefakte werden vn den Anfrderungen nicht abgedeckt der nicht vllständig beschrieben. Es werden nicht alle Stakehlder identifiziert. Es werden Geschäftsziele der Bedürfnisse nicht identifiziert, was bewirkt, dass die erarbeitete Lösung den Unternehmensbedarf nicht deckt und die Unternehmensziele nicht erfüllt. Versin 2013 Page 11 f 114
1.2. Was ist Business Analyse? (K2) 20 Minuten Lernziele des Abschnitts 1.2.1. Business Analyse (K1) Business Analyse ist die Summe der Aufgaben, Kenntnisse und Methden (Werkzeuge und Techniken), die eingesetzt werden, um den Unternehmensbedarf zu ermitteln und zielführende Lösungen für die identifizierten Prbleme des Unternehmens zu entwickeln [BABOK]. Zu diesen Lösungen gehören: Entwicklung vn Sftwaresystemen Entwicklung vn Sftwarekmpnenten Erweiterungen vn vrhandener Sftware Verbesserungen des Geschäftsprzesses Änderungen der Organisatin im Unternehmen 1.2.2. Der Business Analyst (K1) Der Business Analyst (BA) ist verantwrtlich dafür, dass der Unternehmensbedarf vn (externen der internen) Kunden und anderen Stakehldern ermittelt wird und zielführende Lösungen für die Prbleme des Unternehmens entwickelt werden [BABOK]. Zu den spezifischen Aktivitäten vn Business Analysten gehören die Ermittlung, Analyse, Entwicklung und Management vn Anfrderungen. Es ist jedch zu beachten, dass der Business Analyst nicht dafür verantwrtlich ist, die Umsetzung der Lösung festzulegen (d.h. das Prduktdesign zu entwickeln). Die Umsetzung der Lösung ist das Ergebnis der Infrmatinen, die aus der Arbeit des Business Analyst resultieren, und es ist nicht die Rlle eines BA, die Umsetzung der Lösung festzulegen. Zur Lösungsimplementierung gehört häufig die Entwicklung vn Sftware, es können jedch auch Przessverbesserungen der Änderungen im Unternehmen betrffen sein. Der Business Analyst fungiert als Verbindungsglied zwischen dem Kunden und den anderen Stakehldern (z.b. dem Prjektteam) und identifiziert, verhandelt und führt einen Knsensus zwischen den Bedürfnissen der verschiedenen Repräsentanten und Gruppen herbei. 1.2.3. Die allgemeinen Ziele der Business Analyse (K1) Die allgemeinen Ziele der Business Analyse sind: Anfrderungen sammeln und dkumentieren (geschäftliche Ebene) Geschäftslösungen knzipieren, um Prbleme zu lösen Eine termingerechte Prjektdurchführung durch die genaue Ermittlung und Analyse der Anfrderungen unterstützen Die Effizienz steigern, indem die Qualität der Anfrderungsermittlung und -analyse erhöht wird, damit in späteren Prjektphasen weniger Nachbesserungen und Krrekturen erfrderlich sind. Versin 2013 Page 12 f 114
1.2.4. Business Analyse in verschiedenen Phasen des Sftwarelebenszyklus (K2) Auf Kundenseite (d.h. beim Empfänger der Lösung) beginnt die Business Analyse, sbald sich ein Bedarf für eine neue Lösung zeigt. Auf Lieferantenseite (d.h. beim Gestalter der Lösung) wird die Business Analyse nrmalerweise durch die Bereitstellung eines Budgets, durch eine Vereinbarung, einen Auftrag der ein Prjekt initiiert. Wenn ein Unternehmen beispielsweise eine neue der geänderte Funktinalität zur Verbesserung eines Geschäftsprzesses benötigt, dann sllte in einem ersten Schritt zunächst die Analyse des Bedarfs und der Anfrderungen erflgen. In traditinellen Ansätzen wird die Anfangsphase des Prjekts als Analysephase bezeichnet. In dieser Prjektphase kann der Zweck des Business Analyse-Przesses wie flgt sein: Identifizierung und Bewertung der aktuell im Unternehmen vrhandenen Geschäftsprzesse (Ist-Analyse) Sammeln erster Anfrderungen für die benötigte Geschäftslösung (Sll-Analyse) Erstellung and Analyse des Business Case Durchführung einer Machbarkeitssstudie Erarbeitung vn Ideen für die Geschäftslösung Während der nächsten Phase, der Spezifikatinsphase, ist der Business Analyst verantwrtlich für: Identifikatin und Dkumentatin vn Geschäftsanfrderungen mit einem höheren Detaillierungsgrad Unterstützung des System Analyst bei der Erstellung detaillierter Systemspezifikatinen (in denen z.b. Themen wie Daten, Mapping, Integratinsaspekte, Benutzerschnittstellen abgedeckt werden) Validierung des vrgeschlagenen Sftwaredesigns zusammen mit dem Kunden und anderen Stakehldern Ggf. Management vn Anfrderungsänderungen Während der nächsten Phase, der Entwicklungsphase, gehört zum Aufgabenbereich des Business Analyst: Unterstützung des Entwicklungsteams während der Implementierung (z.b. Klärung vn Sachverhalten in Zusammenhang mit den Anfrderungen, Validierung vn Geschäftsregeln, die im Cde angewendet werden sllen) Validierung der sukzessiven Entwicklung der Lösung gemäß den beabsichtigten Anfrderungen und Bedürfnissen (wenn möglich) Unterstützung der Tester beim Entwurf der Testfälle und Testskripte auf der geschäftlichen Ebene und Validierung der prduzierten Arbeitsergebnisse Management jeglicher Änderungen der Anfrderungen, die aufgrund vn gefundenen Defekten, regulatrischen der gesetzlichen Änderungen, benötigter neuer der erweiterter Funktinalität erfrderlich werden Während der Testphase kann die Rlle der Business Analyse variieren. Während des Systemtests kann die Rlle des BA beispielsweise auf die Verifizierung der Testergebnisse und Klärung vn Fragen in Zusammenhang mit Defekten der Lücken in den Anfrderungen beschränkt sein. Während Testphasen, in denen der Kunde invlviert ist, sllte auch der Einsatz des BA erhöht werden. Hierzu gehören flgende Aufgaben: Versin 2013 Page 13 f 114
Mitwirkung bei der Erstellung vn Testfällen für den Benutzerabnahmetest (bzw. Anwendertest lt. BABOK) Unterstützung der Abnahmetester durch die Beantwrtung vn Fragen während der Testausführung 1.2.5. Beziehung zum Lösungslebenszyklus (K1) Für verschiedene Prjekte der Ansätze (Managementansätze der Prduktentwicklungsansätze) kann es erfrderlich sein, die Anfrderungen in einem bestimmten Frmat und mit unterschiedlichem Detaillierungsgrad zu erstellen. Detaillierungsgrad und Anfrderungsfrmat können auch vm jeweiligen Geschäftsfeld und vn externen regulatrischen Anfrderungen bestimmt werden. Der Business Analyst muss in Zusammenarbeit mit dem Prjektteam und den anderen Stakehldern festlegen, welche der in der allgemeinen Geschäftsanalyse definierten Aufgaben und Techniken für das Unternehmen und für ein bestimmtes Prjekt geeignet sind. S wird beispielsweise nicht in jedem Fall eine Unternehmensanalyse durchgeführt; in manchen Prjekten sind die anfänglichen Anfrderungen und Geschäftsprzesse innerhalb des Unternehmens genau bekannt. Versin 2013 Page 14 f 114
1.3. Kernknzepte der Business Analyse (K2) 30 Minuten Lernziele des Abschnitts 1.3.1. Die Rlle des Business Analyst (K1) Der Business Analyst ist das Verbindungsglied zwischen den Stakehldern und als slches verantwrtlich für die Identifikatin, Analyse, Kmmunikatin und Validierung vn Anfrderungen für die Änderung vn Geschäftsprzessen, Unternehmensrichtlinien und/der Infrmatinssystemen [BABOK]. 1.3.2. Business Analyst und System Analyst (K2) Der Business Analyst ist verantwrtlich für das Dkumentieren und Erfassen der Geschäftsanfrderungen. Diese Infrmatinen werden dann an den System Analyst geliefert, der aus diesen Geschäftsanfrderungen technische Anfrderungen erstellt. Die Rlle des System Analyst bildet die Brücke zwischen den Geschäftsanfrderungen und der technischen Definitin der IT-Lösung. Dabei kann es erfrderlich sein, dass der System Analyst mit Prgrammiertechniken vertraut ist und die aktuell bestehende IT-Infrastruktur kennt, um s die geplante Lösung an den vrhandenen Kntext anzupassen. Die beiden Rllen ergänzen sich, und beide sind für ein erflgreiches IT-Prjekt erfrderlich. 1.3.3. Die Anfrderung (K1) Eine Anfrderung ist in [IEEE Std 610.12-1990] definiert als: 1. eine vn einem Stakehlder benötigte Beschaffenheit der eine Fähigkeit, um ein Prblem zu lösen der ein Ziel zu erreichen. 2. eine gefrderte Beschaffenheit der Fähigkeit einer Lösung der einer Lösungskmpnente (bzw. System der Systemkmpnente), die ntwendig ist, um Vrgaben vn Verträgen, Standards, Spezifikatinen der anderen frmal auferlegten Dkumenten einzuhalten. 3. Eine Dkumentatin einer unter Punkt 1 der Punkt 2 angeführten Beschaffenheit der Fähigkeit. Anfrderungen sind die Grundlage vn Systemen der Systemkmpnenten. Sie können bligatrisch sein (benötigte Anfrderungen, Restriktinen usw.) der unbedingt ntwendig, damit die Sftware funktinieren kann und die Erwartungen und Bedürfnisse der beabsichtigten Stakehlder erfüllt. Aus Gründen der Klarheit sllten Anfrderungen in die flgenden Kategrien eingeteilt werden: Geschäftsanfrderungen Benutzeranfrderungen Funktinale Anfrderungen Nichtfunktinale Anfrderungen Der Sinn und Zweck vn Anfrderungen ist wie flgt definiert (K2): Versin 2013 Page 15 f 114
Sie bilden die Grundlage für die Bewertung, Planung, Durchführung und Überwachung der Prjektaktivitäten Sie definieren die Kundenerwartungen (ausgedrückt als tatsächliche Anfrderungen und dem Wert dieser Anfrderungen für die Stakehlder) Sie sind Bestandteil vn Vereinbarungen, Aufträgen, Prjektplänen Sie legen Systemgrenzen, Lieferumfang und die Serviceklassifikatin der Anfrderungen fest [Ebert05] 1.3.4. Klassifikatin der Anfrderungen (K2) Anfrderungen setzen sich zusammen aus Przessanfrderungen und Prduktanfrderungen [Ebert05]: Przessrientierte Anfrderungen beschreiben Bedürfnisse und Einschränkungen in den Geschäftsprzessen (z.b. Management- der Prduktinsprzesse), einschließlich vn Ksten, Marketing, Durchlaufzeit, Vertrieb und Verteilung, Organisatin und Dkumentatin. Prduktanfrderungen bestehen aus funktinalen und nichtfunktinalen Anfrderungen an ein Prdukt. Beide können swhl aus Sicht des Kunden (externe Sichtweise) und aus Sicht des Lieferantenteams (interne Sichtweise) betrachtet werden. 1.3.5. Anfrderungsarten (K1) Die Anfrderungsarten werden wie flgt kategrisiert: Kundenanfrderungen (Geschäftsanfrderungen) Lösungs- der Systemanfrderungen Prdukt- der Kmpnentenanfrderungen 1.3.6. Anfrderungserhebung (K1) Die Angebtserhebung besteht aus sämtlichen Aktivitäten, Methden, Werkzeugen und Techniken, die eingesetzt werden, um die Anfrderungen an ein geplantes Sftwaresystem (der eine Geschäftslösung) vn den Stakehldern zu ermitteln [BABOK]. 1.3.7. Verflgbarkeit (K2) Die Verflgbarkeit ist die Verbindung, die jeweils zwischen unterschiedlichen Anfrderungsarten und flgenden Objekten besteht: Zwischen Anfrderungen (Zurdnung der grben Anfrderungen, in denen Bedürfnisse und Merkmale definiert sind, zu den detaillierten Anfrderungen) Zwischen detaillierten Anfrderungen und Designmdellen Zwischen detaillierten Anfrderungen und Testfällen (z.b. für den Systemtest) Zwischen abstrakten Anfrderungen und Testfällen (z.b. für den Abnahmetest) Zwischen Anfrderungen und Release/Cdeinkrement/Versin Wenn es um die Einhaltung medizinischer Vrschriften (z.b. vn FDA, MDD) geht, wird die Rückverflgbarkeit auch zur Risikbestimmung genutzt. Versin 2013 Page 16 f 114
Mit Hilfe der Verflgbarkeit zwischen Anfrderungen und anderen Prjektartefakten kann der Business Analyst sicherstellen, dass alle Geschäftsanfrderungen erfüllt wurden. Für Tester und Entwickler stellt die Verflgbarkeit sicher, dass die Anfrderungsüberdeckung erzielt wurde. Auch aus Sicht des Änderungsmanagements ist die Verflgbarkeit wichtig, um die Auswirkungen einer Änderung auf das System der den Przess zu bestimmen. 1.3.8. Artefakt (K1) Artefakte sind Arbeitsprdukte (End- der Zwischenprdukte), die während eines Prjektes erstellt und verwendet werden. Manche Artefakte beschreiben die Funktin, Architektur und Entwurf der Sftware (z.b. Anwendungsfälle bzw. Use Cases und snstige UML-Diagramme, Anfrderungsund Entwurfsdkumente). Andere Artefakte befassen sich mit dem Entwicklungsprzess selbst, wie z.b. Prjektpläne, Business Cases und Risikeinschätzungen [RUP]. Es ist erfrderlich, dass alle im Prjekt wichtigen Artefakte der Versinskntrlle unterliegen und dass ihre Herkunft krrekt verflgt werden kann. Versin 2013 Page 17 f 114
1.4. Wissensgebiete (K1) 10 Minuten Lernziele des Abschnitts Die Business Analyse umfasst die flgenden Wissensgebiete [BABOK]: Unternehmensanalyse Anfrderungsplanung und management Erhebung (Identifikatin) vn Anfrderungen Anfrderungskmmunikatin Anfrderungsanalyse und -dkumentatin Lösungsbewertung und validierung Die Business Analyse kann andere Prjektbereiche beeinflussen. Sie hat nicht nur wesentliche Auswirkungen auf das Prjektmanagement (insbesndere auf Umfangs- und Zeitmanagement), sndern auch auf die flgenden Bereiche: Design Die Business Analyse bestimmt die benötigte Geschäftsarchitektur und legt den Lösungsumfang fest. Entwicklung Der System Analyst (der die detaillierte Anfrderungsspezifikatin erstellt) verwendet die Vrgaben der Business Analyse, um festzulegen, was implementiert werden muss. Sftwaretest und andere Qualitätssicherungsaktivitäten Die Arbeitsergebnisse der Geschäfts- und der Systemanalyse bilden die Basis für das Testen (d.h. die Anfrderungsspezifikatin ist Grundlage für Testfallerstellung und ausführung). Es müssen auch die Arbeitsergebnisse selbst getestet werden (d.h. die Anfrderungsspezifikatin muss auf Knsistenz, Vllständigkeit und Einhaltung vn Standards getestet werden). Versin 2013 Page 18 f 114
1.5. Aufgaben und Verantwrtlichkeiten (K2) 20 Minuten Lernziele des Abschnitts 1.5.1. Hauptaufgaben (K1) Die Hauptaufgaben des Business Analyst sind wie flgt [BABOK]: Erhebung (Identifikatin) vn Anfrderungen Anfrderungsanalyse und mdellierung Planung der Anfrderungsrealisierung Anfrderungskmmunikatin Anfrderungsdkumentatin Anfrderungsvalidierung Knfiguratinsmanagement der Anfrderungen Vrschlag vn Geschäftslösungen 1.5.2. Die Rlle des Business Analyst in verschiedenen Prjektphasen (K2) Die Tätigkeit des Business Analysten ist mit Abschluss der ersten Analyse- und Designphasen des Prjekts nicht beendet. Ein Business Analyst unterstützt auch andere Aktivitäten, die im Laufe der nachflgenden Prjektphasen durchgeführt werden. Der BA sllte eigentlich während des gesamten Sftwarelebenszyklus, einschließlich der Wartungsphase, invlviert sein. Die Gründe für die Einbindung des BA sind wie flgt: Unterstützung der Implementierungsaufgaben, um sicherzustellen, dass die Entwickler die Anfrderungen richtig verstehen und umsetzen Unterstützung des Testens, z.b. durch die Validierung vn Testfällen, um sicherzustellen, dass der Test sämtliche Anfrderungen angemessen abdecken wird Analyse und Dkumentatin vn Änderungsanträgen (engl. Change Requests) zu den Anfrderungen Bearbeitung neuer Anfrderungen (neue Regelungen, Standards usw.) Bearbeitung vn Wünschen seitens der Kunden der Anwender, dass neue Bedürfnisse erfüllt werden sllen Alle erwähnten Punkte erfrdern die Invlvierung des Business Analysten, in vielen Fällen auch die des System Analyst. Daher unterstützt der Business Analyst das Prjekt vn Beginn an und während der gesamten Systembereitstellung (und manchmal sgar bis zur Außerbetriebnahme). Versin 2013 Page 19 f 114
2. Unternehmensanalyse (K3) 150 Minuten Begriffe: Business Case, Geschäftsprzess, Geschäftsziel, Lösungsumfang, Mehrwert für den/die Stakehlder, S.M.A.R.T., Stakehlder, Unternehmensanalyse, Unternehmensbedarf Lernziele für die Unternehmensanalyse Die Lernziele legen fest, was Sie nach Beenden des jeweiligen Mduls gelernt haben sllten. 2.1 Identifikatin der Stakehlder und Stakehlder-Analyse (K2) LO-2.1.1 LO-2.1.2 LO-2.1.3 Erklären können, wer Stakehlder in einem Prjekt sein kann. (K2) Anhand vn Beispielen erklären, wie Stakehlder identifiziert werden können. (K2) Beschreiben können, wie sich die Bedürfnisse verschiedener Stakehlder auf das Prdukt auswirken können. (K2) 2.2 Unternehmensanalyse Identifikatin vn Geschäftsprzessen (K2) LO-2.2.1 LO-2.2.2 LO-2.2.3 LO-2.2.4 Wiedergeben können, was Unternehmensanalyse ist und warum sie ntwendig ist. (K1) Die Definitin eines Geschäftsprzesses kennen. (K1) Anhand vn Beispielen die Gründe erklären können, weshalb die Identifikatin vn Geschäftsprzessen ntwendig ist. (K2) Die Techniken für die Identifikatin vn Geschäftsprzessen erklären können. (K2) 2.3 Festlegung vn Unternehmensbedarf und Unternehmenszielen (K3) LO-2.3.1 LO-2.3.2 Wiedergeben können, was Unternehmensbedarf und Unternehmensziele sind. (K1) Die Grundprinzipien der Erstellung geeigneter Unternehmensziele erklären können. (K2) LO-2.3.3 Unternehmensbedarf und -ziele für ein vrgegebenes Geschäftsszenari identifizieren können. (K3) 2.4 Festlegung des Business Case (K3) LO-2.4.1 LO-2.4.2 LO-2.4.3 Wiedergeben können, was ein Business Case ist. (K1) Die Grundprinzipien für die Erstellung eines geeigneten Business Case erklären können. (K2) Erklären können, wann die Erstellung eines Business Case ntwendig ist. (K2) Versin 2013 Page 20 f 114
LO-2.4.4 Den Business Case für ein vrgegebenes Geschäftsszenari festlegen können. (K3) 2.5 Festlegung vn Lösungsumfang und Lösungsansatz (K3) LO-2.5.1 LO-2.5.2 Erklären können, warum die Festlegung des Lösungsumfangs ntwendig ist. (K2) Den Lösungsumfang für ein vrgegebenes Geschäftsszenari bestimmen können. (K3) Versin 2013 Page 21 f 114
2.1. Identifikatin der Stakehlder und Stakehlder-Analyse (K2) 20 Minuten Lernziele des Abschnitts Eine der Schlüsselaktivitäten, die zu Beginn der Arbeiten an einem neuen System durchgeführt werden muss, ist die Identifikatin der Stakehlder und die Stakehlder-Analyse. Es ist wichtig, dass die Systemanfrderungen analysiert und verstanden werden, und dass ein Designvrschlag für die Geschäftslösung geliefert werden kann. Der Business Analyst sllte daher alle Persnen und Organisatinen kennen, die vn der geplanten Lösung betrffen sind, und umgekehrt auch all jene Persnen, die Einfluss auf die Lösung nehmen werden. 2.1.1. Stakehlder (K1) Ein Stakehlder ist eine Persn, die eigene Interessen an einem Prjekt hat der an einem Prjekt beteiligt ist. Es kann sich um Einzelpersnen und/der Organisatinen handeln, die sich aktiv in einem Prjekt engagieren, der deren Interessen inflge eines Prjekts während dessen Durchführung der nach dessen Abschluss betrffen sein können. Stakehlder können auch Einfluss auf die Prjektziele und Prjektergebnisse nehmen. Stakehlder kmmen aus der Organisatin des Lieferanten, aus dem Kundenunternehmen und vn externen Stellen. Stakehlder auf der Lieferantenseite (d.h. aus der Organisatin, die die Lösung erarbeiten wird) können sein: Prjektmanager Business Analysten und System Analysten Entwickler und Systemarchitekten Datenbank-Designer GUI Designer Technische Redakteure Tester und Mitarbeiter der Qualitätssicherung Installatins- und Betriebspersnal Stakehlder auf der Kundenseite (d.h. aus der Organisatin, die die Lösung erhalten wird) können sein: Kundenvertreter (d.h. Vertreter des Geschäftsbereichs) Spnsren Endanwender (aus dem Kundenunternehmen) Installatins- und Betriebspersnal Externe Stakehlder können sein: Endanwender, die nicht zum Kundenunternehmen gehören (z.b. Kunden des Kunden) Snstige Organisatinen (z.b. Regulierungsstellen) Versin 2013 Page 22 f 114
2.1.2. Identifikatin der Stakehlder (K2) Stakehlder können mit Hilfe der flgenden Techniken identifiziert werden: Untersuchung der Geschäftsdmäne Identifikatin der Geschäftsprzesseigner (bzw. Przessverantwrtlichen) Analyse der Organisatinsstruktur des Kundenunternehmens Sndierung des Zielmarkts des Kundenunternehmens Analyse des Beziehungsgeflechts zwischen externen Unternehmen (Lieferanten usw.) 2.1.3. Bedürfnisse und Erwartungen der Stakehlder (K2) Die unterschiedlichen Stakehlder haben unterschiedliche Bedürfnisse und Erwartungen hinsichtlich der geplanten Lösung. Es ist sehr wichtig, dass alle Stakehlder und deren Bedürfnisse identifiziert werden, und dass hinsichtlich des Zwecks einer vrgesehenen Lösung ein gemeinsames Verständnis gefunden wird. Damit sll vermieden werden, dass das Endprdukt nur die Anfrderungen einer Gruppe vn Stakehldern erfüllt. Es ist außerdem wichtig, dass die Features und Funktinen, die implementiert werden sllen, nicht im Widerspruch zu den Anfrderungen anderer Stakehlder stehen. Beispiel: Ein Sftwareprdukt, das für einen sachkundigen Kundenvertreter entwrfen wird, ist für die Endanwender eventuell nicht zufriedenstellend, da diese Gruppe ganz andere Bedürfnisse hinsichtlich der Sftware hat (z.b. eine benutzerfreundliche GUI, intuitive Navigatin und ein erweitertes Hilfesystem). Zum Verantwrtungsbereich des Business Analyst gehört es, alle Stakehlder zu identifizieren und deren Anfrderungen und Erwartungen festzustellen. Dieser Przess ist eine der Schlüsselaktivitäten in der Unternehmensanalyse, da dadurch zu Beginn der Umfang und die Anfrderungen an das System bestimmt werden. Allerdings wird diese Aktivität ft weggelassen der nur teilweise durchgeführt, was dann meist im Verlauf des Prjekts zu Prblemen führt. 2.1.4. Prbleme bei der Identifikatin der Stakehlder (K2) Zu den Hauptprblemen in Zusammenhang mit der Identifikatin der Stakehlder gehören: Ein mangelndes Verständnis für die echten Operateure der Geschäftsprzesse in einem Unternehmen Unklare Definitin der Zuständigkeiten innerhalb der Kundenrganisatin Nichtberücksichtigung vn Stakehldern, die nicht ffensichtlich und direkt vm Przess betrffen sind (z.b. die Endkunden) Eine unvllständige Analyse, was dazu führt, dass Przesse und Aktivitäten swie deren entsprechende Stakehlder übersehen werden Versin 2013 Page 23 f 114
2.2. Unternehmensanalyse Identifikatin der Geschäftsprzesse (K2) 30 Minuten Lernziele des Abschnitts 2.2.1. Unternehmensanalyse (K1) Unternehmensanalyse ist definiert als der strategische Teil des Prjektlebenszyklus und eine Anfangsphase der Business Analyse [BABOK]. Eine Unternehmensanalyse besteht aus flgenden Aktivitäten [BABOK]: Feststellung vn Geschäftschancen Entwicklung strategischer Ziele, die vm Unternehmen erreicht werden sllen, swie einer strategischen Vrgehensweise für die Planung und Durchführung der Ziele Verstehen und Entwickeln der Geschäftsarchitektur Bestimmung des ptimalen Prjektinvestitinsknzepts für das Unternehmen, einschließlich der Implementierung neuer Geschäftslösungen und technischer Systemlösungen, swie Przessveränderungen und/der rganisatrischer Änderungen Auswahl der geeignetsten Lösungsansätze für Prjekte und die Festlegung des Business Case für die jeweiligen Lösungen Initiierung vn Prjekten, und dabei sicherstellen, dass diese den vrgesehenen Mehrwert für die Stakehlder erbringen Man kann es auch s umschreiben: Die Unternehmensanalyse besteht aus den gesamten Aktivitäten, die vr Prjektbeginn durchgeführt werden, die die zukünftige Visin des Geschäfts erfassen, um den Kntext für die Identifikatin der Prjektanfrderungen und Lösungsentwurf zu einem bestimmten Vrhaben der für die langfristige Planung der Unternehmensstrategie zu liefern. In grßen, kmplexen Unternehmen kann die Unternehmensanalyse als ein eigenständiges Prjekt durchgeführt werden. In kleineren Unternehmen erflgt die Unternehmensanalyse durch das Kundenunternehmen selbst, nch bevr der Lieferant invlviert wird, als Teil der anfänglichen Anfrderungen. In manchen Fällen wird die Unternehmensanalyse auch überhaupt nicht durchgeführt, zum Beispiel dann, wenn das Ziel des Prjekts klar und messbar definiert ist. Das Ziel der Unternehmensanalyse ist die Identifikatin und Beschreibung der Geschäftsanfrderungen für zukünftige Investitinen. Diese Anfrderungen werden auf einer höheren Abstraktinsstufe als Geschäftsziele, Bedürfnisse und Erwartungen des Unternehmens definiert. Es ist wichtig, dass der Business Analyst eine umfassende Kenntnis der strategischen Ziele des Kundenunternehmens hat, damit er sicherstellen kann, dass neue Initiativen zur langfristigen Unternehmensstrategie bzw. Unternehmensmissin passen. Auch wenn der Business Analyst nicht selbst an den Aktivitäten zur Durchführung der Unternehmensanalyse beteiligt ist (da diese evtl. vm Kunden selbst durchgeführt wird), s sllte er die Unternehmensziele dennch kennen. 2.2.2. Aktivitäten der Unternehmensanalyse (K1) Zu den Aktivitäten bei der Unternehmensanalyse gehören [BABOK]: Versin 2013 Page 24 f 114
Identifikatin der im Unternehmen verwendeten Geschäftsprzesse Erstellung und Aufrechterhaltung der Geschäftsarchitektur Durchführung vn Machbarkeitsstudien, um die ptimale Geschäftslösung zu bestimmen Festlegung des Umfangs der neuen Geschäftschance Festlegung des Business Case Durchführung der ersten Risikbewertung Erstellung der Entscheidungsvrlage 2.2.3. Geschäftsprzesse (K1) Ein Geschäftsprzess ist eine Reihe vn Aktivitäten mit dem Ziel, einen spezifischen Output für einen bestimmten Kunden der Markt zu erzeugen. Geschäftsprzesse sind darauf fkussiert, wie die Arbeit in einem Unternehmen durchgeführt wird, wie die Aufgaben und Aktivitäten rganisiert sind, welche Beziehungen und welche Abhängigkeiten bestehen. Ein Przess kann als die Beauftragung vn Tätigkeiten über einen Zeitraum an einem Ort angesehen werden, der einen Beginn, ein Ende und klar definierte Inputs und Outputs hat [Sparx]. Ein Geschäftsprzess muss flgende Eigenschaften haben [Sparx]: Er hat ein Ziel Er hat bestimmte Inputs Er hat bestimmte Outputs Er nutzt Ressurcen Er besteht aus einer Reihe vn Aktivitäten, die in einer gewissen Reihenflge durchgeführt werden Er betrifft mindestens eine Organisatinseinheit Er erzeugt Mehrwert für den Kunden (swhl externe als auch interne Kunden) Auf Grundlage der Identifikatin der aktuellen Geschäftsprzesse innerhalb eines Unternehmens kann der Business Analyst die Ziele des Unternehmens verstehen und smit auch die Aktivitäten und die erfrderlichen Abläufe bestimmen, um die für die Zukunft angestrebten Geschäftsziele und strategischen Ziele zu erreichen. Diese Identifikatin dient dazu, sämtliche Aktivitäten und Rllen zu ermitteln, die für die Durchführung der Aktivitäten zur Erzeugung der gewünschten Ergebnisse (Outputs) verantwrtlich sind. Die Identifikatin vn Geschäftsprzessen hilft außerdem bei der Aufdeckung vn möglichen Lücken und ineffektiven Teilen des Przesses, die dann durch eine Przessptimierung verbessert werden können. Wenn die Geschäftsprzesse nicht ermittelt und verstanden werden, dann kann dies daran liegen, dass das Unternehmen einen niedrigen Reifegrad hat, was das Messen und Steuern vn Przessen sehr schwierig macht. Außerdem ist es wahrscheinlich, dass es bei der Definitin der Geschäftsziele und des Bedarfs erhebliche Prbleme geben wird. Versin 2013 Page 25 f 114
2.3. Festlegung vn Unternehmensbedarf und Unternehmenszielen (K3) 30 Minuten Lernziele des Abschnitts 2.3.1. Unternehmensziel (K1) Ein Unternehmensziel ist ein kurzfristiges der ein langfristiges Ziel des Unternehmens. Unternehmensziele zeichnen sich durch flgende Qualitätsmerkmale aus [Entrepreneur]: Spezifität Optimismus Realismus Swhl kurzfirstiger als auch langfristiger Umfang 2.3.2. Der Sinn vn Unternehmenszielen (K2) Die Festlegung vn Unternehmenszielen ist aus den flgenden vier Gründen wichtig: 1. Das Unternehmen muss eine Visin haben und wissen, was erreicht werden sll. Dies wird ermöglicht durch die Definitin klar festgelegter Ziele, und der entsprechenden Zeitvrgaben, in denen diese Ziele erreicht werden müssen. 2. Sie vermittelt ein klares Bild davn, was das Unternehmen mit dem Geschäft anstrebt, und es hilft dabei, die Mtivatin zu fkussieren. 3. Sie ermöglicht dem Unternehmen, die wichtigsten Geschäftsziele zu verstehen und das Engagement für diese Ziele aufrechtzuerhalten. 4. Sie liefert eine Metrik, um den Frtschritt des Unternehmens zu messen. 2.3.3. SMART (K2) SMART ist ein System und ein Werkzeug, das verwendet wird, um Ziele zu bestimmen und deren Qualitätsziele zu definieren. Gemäß diesem Ansatz müssen alle Ziele die flgenden Eigenschaften haben (SMART ist ein Akrnym der englischen Begriffe) [G. T. Dran]: S Spezifisch (specific) M Messbar (measurable) A Akzeptiert und erreichbar (attainable) R Relevant/realistisch (relevant) T Terminiert (timely) 2.3.4. Unternehmensbedarf (K1) Ein Unternehmensbedarf beschreibt das Geschäftsprblem der die Geschäftschance, die der Business Analyst verstehen und analysieren muss, um geeignete Lösungen zu empfehlen. Versin 2013 Page 26 f 114
Dabei ist zu beachten, dass der Unternehmensbedarf (der als ein Prblem der eine Chance zu verstehen ist) und der Business Case (der als das Verhältnis zwischen Ksten und Nutzen zu verstehen ist) vr Prjektbeginn definiert werden; diese Festlegung kann frmell der infrmell erflgen. Diese Definitinen sind wichtig, um die richtige Prjektauswahl sicherzustellen und um jene Prjekte richtig zu pririsieren, die dem Unternehmen dabei helfen, seine Visin, swie seine strategischen Ziele und Geschäftsziele zu erreichen. Der Unternehmensbedarf sllte vn der Persn bzw. vn der Gruppe definiert werden, die das Prjekt verlangt. Bei dieser Persn bzw. Gruppe kann es sich handeln um: Spnsr Lenkungsausschuss Regulatr der Cmpliance-Beauftragter Hchrangiger Fachexperte [Pyzdek, Thmas und Paul A. Keller] Bei der Definitin des Unternehmensbedarfs werden Business Analysten häufig vn Prjektmanagern und Prduktmanagern unterstützt. Die Arbeitsergebnisse der Business Analysten sind jedch dann am effektivsten, wenn sie als neutrale Mderatren agieren und nicht als Eigner. Prjekt- bzw. Prduktmanager und Business Analysten müssen Empfehlungen machen bezüglich der vn einem Unternehmen verlangten Prjekte, d.h. welche Prjekte durchgeführt werden sllten, um bestimmte Geschäftsziele zu erreichen. Dabei sllten Sie jedch nicht die einzigen Entscheidungsträger sein; es ist ntwendig, Kunden in die Entscheidung zu invlvieren. Flglich ist eine der Verantwrtlichkeiten des Business Analyst, mit der Persn bzw. der Gruppe zu kperieren, die das Prjekt verlangt, einschließlich der Anwender (bzw. deren Stellvertreter), und diesen zu helfen, den tatsächlichen Bedarf zu frmulieren. 2.3.5. Mehrwert für den/die Stakehlder (K1) Einer der Schlüsselfaktren eines erflgreichen Prjekts ist, dass der für die Stakehlder geschaffene Wert genau bestimmt wird. Hauptziel eines Prjekts muss immer sein, realisierten Mehrwert (bzw. Nutzen) für die Stakehlder zu erzielen. Ein Wert kann verstanden werden als der Nutzen, den wir glauben, durch eine Sache zu bekmmen [Gilb, Cmpetitive Engineering]. Versin 2013 Page 27 f 114
2.4. Festlegung des Business Case (K3) 30 Minuten Lernziele des Abschnitts Der Business Case liefert die Gründe für ein beabsichtigtes Prjekt (Initiative, Vrhaben). Dabei liefert der Business Case die Rechtfertigung für die Durchführung eines Prjekts in Bezug auf den Mehrwert, den die Prjektergebnisse für das Geschäft schaffen, verglichen mit den Ksten, die für die Entwicklung der neuen Lösung entstehen [BABOK] (K1). Nrmalerweise wird der Business Case als strukturiertes Dkument vrgelegt, kann jedch auch als eine kurze Erörterung der Präsentatin vrgebracht werden. Beispiel: Betrachten Sie einen Fall, bei dem die Benutzbarkeit durch eine Sftwareaktualisierung verbessert werden sll; hierbei würde durch eine bessere Benutzbarkeit die Kundenzufriedenheit erhöht, die Bearbeitungszeiten würden reduziert der Schulungsksten gesenkt. Im Business Case können flgende Themen abgedeckt werden: Infrmatinen über die Geschäftschance (Markttendenzen, Wettbewerber) Qualitative und quantitative Nutzwerte Schätzung der Ksten und der Zeit bis zum Erreichen der Gewinnschwelle (Break-even- Analyse) Gewinnerwartungen Flgechancen für die Zukunft Knsequenzen der Maßnahme für den Cash-Flw (im Zeitablauf), und die Methden, die für die Quantifizierung vn Nutzen und Ksten verwendet wurden Auswirkungen des beabsichtigten Prjekts/Vrhabens auf Geschäftsbetrieb der Geschäftsprzesse Auswirkungen des beabsichtigten Prjekts/Vrhabens auf die technische Infrastruktur Restriktinen in Zusammenhang mit dem beabsichtigten Prjekt/Vrhaben Einschätzung des erfrderlichen Budgets Ausrichtung an festgesetzten Priritäten des Geschäfts 2.4.1. Grundprinzipien für die Erstellung eines krrekten Business Case (K2) Die Erstellung des Business Case sllte mit Srgfalt erflgen. Ein Business Case muss nachweisen, dass die vrgeschlagene Lösung gründlich analysiert wurde, dass der Nutzen im Laufe der Zeit vllständig realisiert werden wird, und dass alle technischen Aspekte genau evaluiert wurden. Je nach Umfang und Verfügbarkeit der Infrmatinen sllte der Business Case einige der alle der flgenden Themen abdecken [Wikipedia]: Referenz Kntext Prjektbezeichnung/-referenz Hintergrund Versin 2013 Page 28 f 114
Geschäftsziele und chancen Prirität für das Geschäft Wertbeitrag Erwünschte Geschäftsergebnisse Geschäftlicher Nutzen (pr Ergebnis) Quantifizierter Mehrwert des Nutzens Ksten Prgnstizierte Rentabilität (ROI), finanzielle Szenarien Risiken und Ksten einer Nichtdurchführung Prjektrisiken (für Prjekt, Nutzen und Geschäft) Fkus Prblem/Lösungsumfang Annahmen Restriktinen Identifizierte und bewertete Optinen Bewertung vn Größe und Umfang Bewertung der Kmplexität Arbeitsergebnisse Geplante Prdukte und Nutzen Betrffene Unternehmensbereiche (intern und extern) Wichtigste Stakehlder Abhängigkeiten Arbeitsaufwand Ansatz Definitin der Phasen Prjektaktivitäten Technische Lieferaktivitäten Schätzung des Arbeitsaufwands Prjektplan Terminplan Benötigte Ressurcen Prjektleitung Prjekt-Gvernance Teamressurcen Finanzausstattung Verpflichtungen Versin 2013 Page 29 f 114
Prjektsteuerung Berichtsprzesse Terminplan für Arbeitsergebnisse Finanzierungsplan 2.4.2. Qualitätsmerkmale eines Business Case (K1) Der Przess zur Erstellung eines Business Case sllte durch flgende Qualitätsmerkmale geprägt sein [Wikipedia]: Anpassbar Angepasst an Größe und Risik der vrgeschlagenen Lösung. Knsistent Jedes Prjekt befasst sich mit denselben Grundsatzfragen des Geschäfts. Geschäftsrientiert Fkussiert auf Fähigkeiten und Auswirkungen. Umfassend Es werden alle Faktren berücksichtigt, die für eine vllständige Bewertung relevant sind. Verständlich Der Inhalt ist klar und lgisch. Messbar Die wichtigsten Aspekte lassen sich quantifizieren. Transparent Die wichtigsten Elemente lassen sich unmittelbar rechtfertigen. Verantwrtlich Die Verpflichtung zur Lieferung des Nutzens und das Kstenmanagement sind klar. 2.4.3. Vrgehensweise zur Erstellung eines Business Case (K1) Die Erstellung des Business Case erflgt in vier Schritten: Identifikatin und quantitative Bestimmung des Nutzens Identifikatin und Quantifizierung der Ksten Erstellung des Business Case Festlegung der Verfahren, die zur Messung vn Ksten und Nutzen eingesetzt werden 2.4.4. Sinn und Zweck für die Erstellung eines Business Case (K2) Anhand eines krrekt erstellten Business Case kann das Unternehmen [Wikipedia] eine Denkweise verstehen und anwenden, die es den Entscheidungsträgern im Unternehmen ermöglicht, Wert, Risik und Prirität eines beabsichtigten Prjekts zu analysieren. den Wert der vrgeschlagenen Lösung für das Unternehmen rechtfertigen und Lösungsvrschläge ablehnen, die keinen nachgewiesenen der messbaren Wert haben. entscheiden, b die vrgeschlagene Lösung einen Mehrwert für das Geschäft hat, und b sie im Vergleich mit den vrgeschlagenen Alternativen erreichbar ist. den Frtschritt und Erflg des Business Case verflgen und messen (hilfreich für das Prjektmanagement). sicherstellen, dass Prjekte mit wechselseitigen Abhängigkeiten in der ptimalen Reihenflge durchgeführt werden. Versin 2013 Page 30 f 114
Das Muster eines Business Case beinhaltet die flgenden Elemente [BABOK]: 1. Kurzzusammenfassung 2. Einführung und Zusammenfassung 3. Ansatz Begründung für die bevrzugte Prjektptin Aktueller Geschäftsprzess Prblembeschreibung Chance Prjektziele Prjektumfang Geschäftlicher Nutzen Prjektksten Annahmen Wirkungsanalyse ptenzieller Auswirkungen auf Geschäft und Mitarbeiter Wirkungsanalyse der ptenziellen technischen Auswirkungen Snstige Themen Implementierungsplan Finanzielle Metriken Bewertung der Auswirkungen auf den Datenschutz (swie auf Bestimmungen, gesetzliche Regelungen usw.) Alternative Bewertungskriterien 4. Wichtigstes Auswahlkriterium Gewichtung Restriktinen und Begrenzungen 5. Bevrzugte Alternative Geschäftlicher Nutzen Alternative Ksten Annahmen Wirkungsanalyse ptenzieller Auswirkungen auf Geschäft und Mitarbeiter Snstige Aspekte 6. Risikmanagementplan Risikbewertung Risikbeherrschung Realisierung des Nutzens 7. Schlussflgerung und Empfehlungen Versin 2013 Page 31 f 114
2.5. Festlegung vn Lösungsumfang und Lösungsansatz (K3) 40 Minuten Lernziele des Abschnitts Die Festlegung des Lösungsumfangs bildet die Grundlage für die Bestimmung des Prjektumfangs (Prjektplanung), und für die Entwicklung weiterer detaillierter Anfrderungen. Ksten und Zeitaufwand werden nrmalerweise vm Prjektmanager bestimmt. Die Schätzung basiert auf dem Prjektumfang der auf dem Lösungsumfang für das Prblem (z.b. kann für die geplante Lösung eine funktinale Zerlegung durchgeführt werden, um den gesamten erfrderlichen Arbeitsaufwand des Prjekts zu bestimmen). Wird der Umfang des Prjekts auf eine andere Art und Weise geplant, dann erhöht sich dabei das Risik für ein Scheitern des Prjekts aufgrund flgender Ursachen: Verzögerungen Budgetüberschreitungen Unvllständige Lieferung Die Festlegung des Prjektumfangs gehört zu den Aufgaben des Business Analyst. Der Prjektumfang wird zunächst durch die Geschäftsanfrderungen definiert, wird dann aber im Laufe der Anfrderungsentwicklungphase detaillierter spezifiziert. Dabei handelt es sich um eine Phase des typischen Prjektlebenszyklus. Der Lösungsumfang lässt sich mit Hilfe der flgenden Techniken bestimmen (K2): Prjektstrukturplan eine Zerlegung des Arbeitsaufwands in Arbeitspakete, die benötigt werden, um ein Prjekt abzuschließen und die Geschäftsziele zu erreichen. Prduktstrukturplan - eine Zerlegung des Prdukts in Kmpnenten Schnittstellenanalyse - eine Definitin des ntwendigen Arbeitsumfangs, um die neue Lösung in das bestehende Unternehmen und die vrhandene technische Infrastruktur zu integrieren. Versin 2013 Page 32 f 114
3. Planung des Business Analyse- Przesses (K3) 180 Minuten Begriffe: Änderungslebenszyklus, CCB (Change Cntrl Bard), Change Management, Change Request (Änderungsantrag), Kmmunikatin, Knfiguratinseinheit, Knfiguratinsmanagement, Requirements Engineering-Przess Lernziele für Planung des Business Analyse-Przesses Die Lernziele legen fest, was Sie nach Beenden des jeweiligen Mduls gelernt haben sllten. 3.1 Planung der Business Analyse-Kmmunikatin (K2) LO-3.1.1 LO-3.1.2 LO-3.1.3 Die Prjektrllen und Aktivitäten wiedergeben können, die vn den Ergebnissen der Business Analyse betrffen sind. (K1) Die typischen Arbeitsergebnisse der Business Analyse wiedergeben können. (K1) Erklären können, weshalb Kmmunikatin ein wichtiger Bestandteil der Tätigkeit eines Business Analyst ist, und definieren können, welche Faktren beim Erstellen eines Business Analyse-Kmmunikatinsplans berücksichtigt werden müssen. (K2) LO-3.1.4 Anhand vn Beispielen beschreiben können, wie die Aktivitäten und Arbeitsergebnisse der Business Analyse kmmuniziert werden können. (K2) 3.2 Planung des Anfrderungsmanagement-Przesses (K2) LO-3.2.1 LO-3.2.2 LO-3.2.3 Den Anfrderungsmanagement-Przess beschreiben können. (K2) Beschreiben können, welche zusätzlichen Elemente in die Planung des Anfrderungsmanagement-Przesses miteinbezgen werden sllen. (K2) Die Faktren beschreiben können, die in der Planung enthalten sein sllen. (K2) 3.3 Knfiguratins- und Change Management-Przess (K3) LO-3.3.1 LO-3.3.2 Das Knzept des Change Management und des Knfiguratinsmanagements erklären können. (K2) Den Unterschied zwischen Change Management und Knfiguratinsmanagement erklären können. (K2) LO-3.3.3 Für ein vrgegebenes Szenari einen Change Management-Przess implementieren können. (K3) LO-3.3.4 Die Rlle des CCB (Change Cntrl Bard) erklären können. (K2) 3.4 Auswahl vn Werkzeugen und Techniken (K1) Versin 2013 Page 33 f 114