Agiles Projektmanagement für analytische Informationssysteme ...
Agiles Projektmanagement für analytische Informationssysteme ...
Agiles Projektmanagement für analytische Informationssysteme ...
Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
<strong>Agiles</strong> <strong>Projektmanagement</strong> für <strong>analytische</strong> <strong>Informationssysteme</strong>:<br />
Konstruktion und Evaluation einer situativen Methode<br />
D I S S E R T A T I O N<br />
der Universität St. Gallen,<br />
Hochschule für Wirtschafts-,<br />
Rechts- und Sozialwissenschaften<br />
sowie Internationale Beziehungen (HSG)<br />
zur Erlangung der Würde eines<br />
Doktors der Wirtschaftswissenschaften<br />
vorgelegt von<br />
Philipp Gubler<br />
von<br />
Aadorf (Thurgau)<br />
Genehmigt auf Antrag der Herren<br />
Prof. Dr. Robert Winter<br />
und<br />
PD Dr. Joachim Schelp<br />
Dissertation Nr. 4081<br />
Sierke Verlag, Göttingen 2012
Die Universität St. Gallen, Hochschule für Wirtschafts-, Rechts- und Sozialwissenschaften<br />
sowie Internationale Beziehungen (HSG), gestattet hiermit die Drucklegung<br />
der vorliegenden Dissertation, ohne damit zu den darin ausgesprochenen Anschauungen<br />
Stellung zu nehmen.<br />
St. Gallen, den 29. Oktober 2012<br />
Der Rektor:<br />
Prof. Dr. Thomas Bieger
Vorwort<br />
iii<br />
Vorwort<br />
Die vorliegende Arbeit entstand im Rahmen meiner Tätigkeit als wissenschaftlicher<br />
Mitarbeiter in den Kompetenzzentren Enterprise Information Warehousing (CC EIW)<br />
und Informationslogistik-Management (CC ILM) am Institut für Wirtschaftsinformatik<br />
der Universität St. Gallen (IWI-HSG). Mit der Fertigstellung dieser Dissertation blicke<br />
ich auf rund vier Jahre Studium und intensive Forschungsarbeit zurück. Es war für<br />
mich ein wichtiger, sehr interessanter und prägender Lebensabschnitt. Auch wenn im<br />
Rahmen einer monographischen Dissertation am Ende nur ein Autor aufgeführt ist,<br />
kann ein solch grosses Projekt nie ohne die teils direkte, teils weniger direkte wissenschaftliche<br />
und persönliche Unterstützung einer Vielzahl von Personen erfolgreich<br />
abgeschlossen werden. In den folgenden Zeilen möchte ich diesen Personen meinen<br />
Dank zum Ausdruck bringen.<br />
An erster Stelle ist mein Doktorvater, Herr Prof. Dr. Robert Winter, zu nennen. Ihm<br />
danke ich herzlich für das Schaffen ausgezeichneter Rahmenbedingungen für die praxisorientierte<br />
Forschung im Bereich Wirtschaftsinformatik. Er ist mir mit Rat und Tat<br />
während des gesamten Entstehungsprozesses der Dissertation zur Seite gestanden.<br />
Ebenfalls danke ich PD Dr. Joachim Schelp für die Übernahme des Korreferats und<br />
die wertvollen Hinweise insbesondere in der frühen Phase des Dissertationsprojekts.<br />
Darüber hinaus sei meinen Projektleitern Prof. Dr. Stephan Aier, Ulrich Wlk und ganz<br />
besonders Prof. Dr. Felix Wortmann ein Dank auszusprechen. Er hat es mit seiner unverkennbaren<br />
Art verstanden, die Rolle eines Vorgesetzten mit der eines Freundes und<br />
Mentors zu verbinden. In unzähligen Diskussionen hat er mit seiner fachlichen Kompetenz<br />
und der Fähigkeit, Dinge unkonventionell zu betrachten, massgeblich zum Erfolg<br />
meines Dissertationsprojekts beigetragen.<br />
Ausserdem möchte ich mich bei Dr. Tobias Bucher bedanken. Ohne seine Unterstützung<br />
hätte ich eine Promotion wohl nie in Betracht gezogen.<br />
Praxisnahe Forschung, wie sie am IWI-HSG praktiziert wird, kann nur mittels engen<br />
Austauschs von Universität und Wirtschaft gelingen. Daher möchte ich mich herzlich<br />
bei meinen Fallstudien- und Evaluationspartnern bedanken. Mein Dank gebührt Eike<br />
Straehler-Pohl (BLUEFORTE GmbH), Alexander Scholz (BMW AG), den Interviewpartnern<br />
des Bundesamts für Informatik und Telekommunikation und dessen<br />
Kunden, Philippe Weder (Infoman Schweiz AG), Dr. Carsten Dittmar, Heiko Gronwald,<br />
Uwe Hoos und Sascha Oliver Werner (alle Steria Mummert Consulting AG)
iv<br />
Vorwort<br />
sowie der Interviewpartnerin der Schweizerischen Grossbank. Auch die statistischen<br />
Erhebungen wären ohne die Mitarbeit einer Vielzahl von Praxisvertretenden nicht<br />
möglich gewesen – danke an dieser Stelle allen Umfrageteilnehmenden.<br />
Meine Zeit am IWI-HSG durfte ich in einem ausserordentlich kollegialen und freundschaftlichen<br />
Arbeitsumfeld verbringen. Zu dieser exzellenten Atmosphäre haben wesentlich<br />
meine Kolleginnen und Kollegen beigetragen, sei es durch intensive und interessante<br />
wissenschaftliche Diskussionen oder gelegentliche Aktivitäten ausserhalb des<br />
Institutes. Neben den oben erwähnten Personen gilt mein Dank Ralf Abraham, Dr. Antonia<br />
Albani, Dr. Lars Baacke, Stefan Bischoff, André Blondiau, Rudolf Brühwiler,<br />
Dr. Barbara Dinter, Dr. Anne Cleven, Yannic Domigall, Marion Fässler, Dr. Christian<br />
Fischer, Dr. Ronny Fischer, Dr. René Fitterer, Dr. Wojciech Ganczarski, Dr. Anke<br />
Gericke, Andreas Györy, Dr. Stephan Kurpjuweit, Nils Labusch (auch für seine inhaltlichen<br />
Anregungen zur vorliegenden Arbeit), Dr. Gerrit Lahrmann, Linda Lower, Dr.<br />
Frederik Marx, Bernadette Mayer-Schawalder, Dr. Jörg Mayer, Dr. Tobias Mettler,<br />
Dr. Jochen Müller, David Raber, Dr. Felix Reinshagen, Dr. Christian Riege, Dr. Peter<br />
Rohner, Dr. Jan Saat, Dr. Moritz Schmaltz, Dr. Daniel Stock, Dr. Florian Stroh, Dr.<br />
Matthias Stutz, Simon Weiss, Dr. Christian Wilhelmi und vielen weiteren. Besonders<br />
hervorheben möchte ich in diesem Zusammenhang Dr. Bettina Gleichauf, bei der ich<br />
mich für eine tolle gemeinsame Zeit im Büro bedanken möchte.<br />
Mein grösster persönlicher Dank gilt schliesslich den Menschen, die mir während<br />
meines Promotionsprozesses, aber auch in den vielen Jahren davor, ihren uneingeschränkten<br />
Rückhalt gegeben haben. So danke ich meinen Eltern Marianna und Ueli<br />
Gubler, meinen Schwestern Sarah Gubler und Eva Gubler, sowie meiner Freundin<br />
Martina Küng. Sie haben mich in jeder Situation liebevoll und verständnisvoll unterstützt<br />
und mein bisweilen ungemütliches Verhalten mit viel Geduld ertragen. Martina<br />
und Marianna haben ausserdem mit ihrem akribischen Lektorat auch noch so kleine<br />
Fehler in der Arbeit entdeckt.<br />
Dafür, dass ich in jeder Situation voll auf meine Familie zählen kann und dass wir<br />
auch in schwierigen Zeiten, wie wir sie während meiner Zeit am IWI-HSG mehrfach<br />
erleben mussten, immer zusammenhalten, ist für mich ganz besonders wichtig. Hierfür<br />
möchte ich mich bei euch herzlichst bedanken. Euch sei diese Arbeit von ganzem Herzen<br />
gewidmet.<br />
St. Gallen, im November 2012<br />
Philipp Gubler
Inhaltsübersicht<br />
v<br />
Inhaltsübersicht<br />
Vorwort ......................................................................................................................... iii<br />
Inhaltsübersicht ............................................................................................................. v<br />
Inhaltsverzeichnis ....................................................................................................... vii<br />
Abkürzungsverzeichnis ............................................................................................... xv<br />
Abbildungsverzeichnis ............................................................................................. xvii<br />
Tabellenverzeichnis ................................................................................................... xxi<br />
Kurzfassung ............................................................................................................ xxvii<br />
Abstract .................................................................................................................. xxviii<br />
1 Einleitung ...................................................................................................... 1<br />
1.1 Ausgangslage und Problemstellung ............................................................... 1<br />
1.2 Forschungsfragen und Zielsetzungen ............................................................. 4<br />
1.3 Forschungsmethodik und -prozess ................................................................. 7<br />
1.4 Adressaten und Nutzenpotenziale ................................................................ 15<br />
1.5 Vorgehen und Struktur der Forschungsarbeit .............................................. 17<br />
2 Konzeptionelle Grundlagen ....................................................................... 20<br />
2.1 St. Galler Ansatz des Business Engineerings ............................................... 20<br />
2.2 Analytische <strong>Informationssysteme</strong> ................................................................ 28<br />
2.3 Projekte und deren Abwicklung ................................................................... 36<br />
2.4 Agile Entwicklung ........................................................................................ 55<br />
3 Stand der Forschung und verwandte Arbeiten ....................................... 75<br />
3.1 Auswahl und Bewertungskriterien für verwandte Arbeiten ......................... 75<br />
3.2 Vorstellung ausgewählter Publikationen ...................................................... 80<br />
3.3 Zusammenfassende Bewertung der untersuchten Publikationen ................. 83<br />
4 Grundlagen für die Methodenentwicklung .............................................. 89<br />
4.1 Gestaltungsfaktoren für agiles AIS-<strong>Projektmanagement</strong> ............................. 89<br />
4.2 Realisierungsformen für agiles AIS-<strong>Projektmanagement</strong> ............................ 95
vi<br />
Inhaltsübersicht<br />
4.3 Ableitung von Projekttypen und Kontexttypen ......................................... 100<br />
4.4 Entwicklungssituationen für einen methodischen Ansatz ......................... 105<br />
5 Fallstudien zur Methodenentwicklung ................................................... 108<br />
5.1 Auswahl der Fallstudien ............................................................................. 109<br />
5.2 Fallstudie A: BLUEFORTE GmbH ........................................................... 109<br />
5.3 Fallstudie B: BMW AG ............................................................................. 125<br />
5.4 Fallstudie C: Steria Mummert Consulting AG .......................................... 148<br />
5.5 Fallstudie D: Schweizerische Grossbank ................................................... 161<br />
5.6 Zusammenfassende Betrachtung der untersuchten Fallstudien ................. 173<br />
6 Entwicklung des methodischen Ansatzes ............................................... 183<br />
6.1 Anforderungen an den methodischen Ansatz ............................................ 183<br />
6.2 Ableitung des methodischen Ansatzes ....................................................... 190<br />
6.3 Spezifikation der Methodenfragmente für die situative Methode ............. 201<br />
6.4 Resultierende Beschreibungsmodelle der situativen Methode .................. 311<br />
7 Evaluation der situativen Methode ........................................................ 319<br />
7.1 Evaluation in der gestaltungsorientierten Wirtschaftsinformatik .............. 319<br />
7.2 Analytische Evaluation .............................................................................. 321<br />
7.3 Empirische Evaluation ............................................................................... 330<br />
8 Zusammenfassung und Ausblick ............................................................ 341<br />
8.1 Zusammenfassung der Forschungsarbeit ................................................... 341<br />
8.2 Kritische Würdigung .................................................................................. 344<br />
8.3 Ausblick und weiterer Forschungsbedarf .................................................. 347<br />
Anhang A: Fragebogen der Umfrage ...................................................................... 351<br />
Anhang B: Interviewleitfaden für die Fallstudien ................................................. 353<br />
Anhang C: Interviewleitfaden für die Evaluation .................................................. 355<br />
Anhang D: Ansprechpersonen zu den Fallstudien ................................................. 358<br />
Literaturverzeichnis .................................................................................................. 361
Inhaltsverzeichnis<br />
vii<br />
Inhaltsverzeichnis<br />
1 Einleitung ...................................................................................................... 1<br />
1.1 Ausgangslage und Problemstellung ............................................................... 1<br />
1.2 Forschungsfragen und Zielsetzungen ............................................................. 4<br />
1.3 Forschungsmethodik und -prozess ................................................................. 7<br />
1.3.1 Forschungsströmungen in der Wirtschaftsinformatik ................................ 7<br />
1.3.2 Artefakttypen in der gestaltungsorientierten<br />
Wirtschaftsinformatik ................................................................................. 9<br />
1.3.3 Forschungsprozess der Dissertation ......................................................... 13<br />
1.4 Adressaten und Nutzenpotenziale ................................................................ 15<br />
1.5 Vorgehen und Struktur der Forschungsarbeit .............................................. 17<br />
2 Konzeptionelle Grundlagen ....................................................................... 20<br />
2.1 St. Galler Ansatz des Business Engineerings ............................................... 20<br />
2.1.1 Run the Business vs. Change the Business .............................................. 21<br />
2.1.2 „Ingenieurmässige“ Unterstützung projektgetriebener<br />
Veränderung ............................................................................................. 23<br />
2.1.3 Situatives Methoden-Engineering ............................................................ 25<br />
2.2 Analytische <strong>Informationssysteme</strong> ................................................................ 28<br />
2.3 Projekte und deren Abwicklung ................................................................... 36<br />
2.3.1 HERMES .................................................................................................. 42<br />
2.3.2 PRINCE2 .................................................................................................. 43<br />
2.3.3 Guide to the Project Management Body of Knowledge<br />
(PMBoK Guide) ....................................................................................... 45<br />
2.3.4 Rational Unified Process (RUP) .............................................................. 48<br />
2.3.5 V-Modell .................................................................................................. 52<br />
2.3.6 Zusammenfassende Betrachtung .............................................................. 54<br />
2.4 Agile Entwicklung ........................................................................................ 55<br />
2.4.1 Dynamic System Development Method (DSDM) ................................... 60
viii<br />
Inhaltsverzeichnis<br />
2.4.2 Extreme Programming (XP) .................................................................... 61<br />
2.4.3 Feature-Driven Development (FDD) ....................................................... 63<br />
2.4.4 Kanban ..................................................................................................... 64<br />
2.4.5 Scrum ....................................................................................................... 66<br />
2.4.6 Zusammenfassende Betrachtung .............................................................. 70<br />
3 Stand der Forschung und verwandte Arbeiten ....................................... 75<br />
3.1 Auswahl und Bewertungskriterien für verwandte Arbeiten ........................ 75<br />
3.1.1 Auswahlkriterien und -prozess................................................................. 75<br />
3.1.2 Bewertungskriterien ................................................................................. 77<br />
3.2 Vorstellung ausgewählter Publikationen ..................................................... 80<br />
3.2.1 HUGHES: Agile Data Warehousing .......................................................... 80<br />
3.2.2 KIMBALL ET AL.: The Data Warehouse Lifecycle Toolkit ....................... 81<br />
3.2.3 MOSS UND ATRE: Business Intelligence Roadmap .................................. 82<br />
3.3 Zusammenfassende Bewertung der untersuchten Publikationen ................. 83<br />
4 Grundlagen für die Methodenentwicklung ............................................. 89<br />
4.1 Gestaltungsfaktoren für agiles AIS-<strong>Projektmanagement</strong> ............................. 89<br />
4.2 Realisierungsformen für agiles AIS-<strong>Projektmanagement</strong>............................ 95<br />
4.3 Ableitung von Projekttypen und Kontexttypen ......................................... 100<br />
4.3.1 Projekttypen ........................................................................................... 100<br />
4.3.2 Kontexttypen .......................................................................................... 103<br />
4.4 Entwicklungssituationen für einen methodischen Ansatz ......................... 105<br />
5 Fallstudien zur Methodenentwicklung ................................................... 108<br />
5.1 Auswahl der Fallstudien ............................................................................. 109<br />
5.2 Fallstudie A: BLUEFORTE GmbH ........................................................... 109<br />
5.2.1 Unternehmensprofil................................................................................ 110<br />
5.2.2 Ausgangslage und Problemstellung ....................................................... 111<br />
5.2.2.1 Ursprüngliche Data Warehouse-Landschaft und Projektauslöser .. 111<br />
5.2.2.2 Herausforderungen im Projektaufbau und Lösungsansätze ........... 112
Inhaltsverzeichnis<br />
ix<br />
5.2.3 Details zum betrachteten Projekt ............................................................ 113<br />
5.2.3.1 Projektvorgehen .............................................................................. 114<br />
5.2.3.2 Beteiligte Rollen.............................................................................. 119<br />
5.2.4 Wesentliche Erkenntnisse und Ausblick ................................................ 121<br />
5.3 Fallstudie B: BMW AG .............................................................................. 125<br />
5.3.1 Unternehmensprofil ................................................................................ 125<br />
5.3.2 Ausgangslage und Problemstellung im Unternehmen ........................... 126<br />
5.3.2.1 Ursprüngliche Methode und Auslöser der Veränderung ................ 126<br />
5.3.2.2 Herausforderungen der Veränderung und Lösungsansätze ............ 130<br />
5.3.3 Details zur neuen Vorgehensweise ........................................................ 133<br />
5.3.3.1 Projektvorgehen und Ergebnisse ..................................................... 133<br />
5.3.3.2 Beteiligte Rollen.............................................................................. 140<br />
5.3.4 Wesentliche Erkenntnisse und Herausforderungen ............................... 143<br />
5.4 Fallstudie C: Steria Mummert Consulting AG ........................................... 148<br />
5.4.1 Unternehmensprofil ................................................................................ 148<br />
5.4.2 Ausgangslage und Problemstellung im Unternehmen ........................... 149<br />
5.4.2.1 Ursprüngliche Data Warehouse-Landschaft und Projektauslöser .. 149<br />
5.4.2.2 Herausforderungen im Projektaufbau und Lösungsansätze ............ 150<br />
5.4.3 Details zum betrachteten Projekt ............................................................ 152<br />
5.4.3.1 Projektvorgehen .............................................................................. 152<br />
5.4.3.2 Beteiligte Rollen.............................................................................. 158<br />
5.4.4 Wesentliche Erkenntnisse und Ausblick ................................................ 160<br />
5.5 Fallstudie D: Schweizerische Grossbank ................................................... 161<br />
5.5.1 Unternehmensprofil ................................................................................ 162<br />
5.5.2 Ausgangslage und Problemstellung im Unternehmen ........................... 162<br />
5.5.2.1 Auslöser der Veränderung .............................................................. 162<br />
5.5.2.2 Herausforderungen der Veränderung und Lösungsansätze ............ 163<br />
5.5.3 Details zur betrachteten Veränderung .................................................... 164
x<br />
Inhaltsverzeichnis<br />
5.5.3.1 Projektvorgehen .............................................................................. 165<br />
5.5.3.2 Beteiligte Rollen ............................................................................. 167<br />
5.5.3.3 Werkzeuge ...................................................................................... 168<br />
5.5.4 Wesentliche Erkenntnisse und Herausforderungen ............................... 171<br />
5.6 Zusammenfassende Betrachtung der untersuchten Fallstudien ................. 173<br />
5.6.1 Zusammenfassende Darstellung der Vorgehen...................................... 173<br />
5.6.2 Situationsbezogene Einordnung der Fallstudien .................................... 180<br />
6 Entwicklung des methodischen Ansatzes ............................................... 183<br />
6.1 Anforderungen an den methodischen Ansatz ............................................ 183<br />
6.1.1 Inhaltlich deduktive Anforderungen ...................................................... 183<br />
6.1.2 Inhaltlich induktive Anforderungen ....................................................... 185<br />
6.1.3 Methodische Anforderungen .................................................................. 188<br />
6.2 Ableitung des methodischen Ansatzes ....................................................... 190<br />
6.2.1 Modularisierung und situationsspezifische Adaption des<br />
methodischen Ansatzes .......................................................................... 190<br />
6.2.2 Vorgehensweise bei der Ableitung des methodischen Ansatzes ........... 194<br />
6.2.3 Ableitung des Vorgehensmodells und der Methodenfragmente<br />
der situativen Methode ........................................................................... 195<br />
6.3 Spezifikation der Methodenfragmente für die situative Methode ............. 201<br />
6.3.1 Methodenfragment 01 – Grobe Start-/Ziel-Bestimmung ....................... 205<br />
6.3.1.1 Aussensicht ..................................................................................... 205<br />
6.3.1.2 Innensicht ........................................................................................ 206<br />
6.3.2 Methodenfragment A – Initialisierung der Strategie ............................. 210<br />
6.3.2.1 Aussensicht ..................................................................................... 210<br />
6.3.2.2 Innensicht ........................................................................................ 211<br />
6.3.3 Methodenfragment B – Strategieformulierung ...................................... 214<br />
6.3.3.1 Aussensicht ..................................................................................... 214<br />
6.3.3.2 Innensicht ........................................................................................ 215
Inhaltsverzeichnis<br />
xi<br />
6.3.4 Methodenfragment C – Strategieumsetzung .......................................... 217<br />
6.3.4.1 Aussensicht ..................................................................................... 217<br />
6.3.4.2 Innensicht ........................................................................................ 218<br />
6.3.5 Methodenfragment D – Strategiekontrolle ............................................. 220<br />
6.3.5.1 Aussensicht ..................................................................................... 221<br />
6.3.5.2 Innensicht ........................................................................................ 222<br />
6.3.6 Methodenfragment 02 – Projektinitialisierung ...................................... 223<br />
6.3.6.1 Aussensicht ..................................................................................... 224<br />
6.3.6.2 Innensicht ........................................................................................ 225<br />
6.3.7 Methodenfragment 03 – Projektvision ................................................... 229<br />
6.3.7.1 Aussensicht ..................................................................................... 229<br />
6.3.7.2 Innensicht ........................................................................................ 230<br />
6.3.8 Methodenfragment 04 – Definition Projektteam ................................... 234<br />
6.3.8.1 Aussensicht ..................................................................................... 235<br />
6.3.8.2 Innensicht ........................................................................................ 236<br />
6.3.9 Methodenfragment 05 – Release- und Sprintplanung ............................ 242<br />
6.3.9.1 Aussensicht ..................................................................................... 242<br />
6.3.9.2 Innensicht ........................................................................................ 243<br />
6.3.10 Methodenfragment 06 – Planung Release .............................................. 247<br />
6.3.10.1 Aussensicht ..................................................................................... 247<br />
6.3.10.2 Innensicht ........................................................................................ 248<br />
6.3.11 Methodenfragment 07 – Umsetzung Release......................................... 254<br />
6.3.11.1 Aussensicht ..................................................................................... 254<br />
6.3.11.2 Innensicht ........................................................................................ 255<br />
6.3.12 Methodenfragment 08 – Review und Deploy Release ........................... 259<br />
6.3.12.1 Aussensicht ..................................................................................... 259<br />
6.3.12.2 Innensicht ........................................................................................ 260<br />
6.3.13 Methodenfragment 09 – Retrospektive Release..................................... 263
xii<br />
Inhaltsverzeichnis<br />
6.3.13.1 Aussensicht ..................................................................................... 263<br />
6.3.13.2 Innensicht ........................................................................................ 264<br />
6.3.14 Methodenfragment 10 – Sprintplanung Frontend .................................. 266<br />
6.3.14.1 Aussensicht ..................................................................................... 266<br />
6.3.14.2 Innensicht ........................................................................................ 268<br />
6.3.15 Methodenfragment 11 – Konzept und Realisierung Frontend ............... 273<br />
6.3.15.1 Aussensicht ..................................................................................... 273<br />
6.3.15.2 Innensicht ........................................................................................ 274<br />
6.3.16 Methodenfragment 12 – Review und Deploy Frontend ........................ 278<br />
6.3.16.1 Aussensicht ..................................................................................... 278<br />
6.3.16.2 Innensicht ........................................................................................ 280<br />
6.3.17 Methodenfragment 13 – Retrospektive Frontend-Sprint ....................... 282<br />
6.3.17.1 Aussensicht ..................................................................................... 282<br />
6.3.17.2 Innensicht ........................................................................................ 283<br />
6.3.18 Methodenfragment 14 – Planung und Analyse Backend ....................... 285<br />
6.3.18.1 Aussensicht ..................................................................................... 285<br />
6.3.18.2 Innensicht ........................................................................................ 286<br />
6.3.19 Methodenfragment 15 – Design Backend .............................................. 291<br />
6.3.19.1 Aussensicht ..................................................................................... 291<br />
6.3.19.2 Innensicht ........................................................................................ 292<br />
6.3.20 Methodenfragment 16 – Realisierung Backend ..................................... 296<br />
6.3.20.1 Aussensicht ..................................................................................... 296<br />
6.3.20.2 Innensicht ........................................................................................ 297<br />
6.3.21 Methodenfragment 17 – Review und Deploy Backend ......................... 301<br />
6.3.21.1 Aussensicht ..................................................................................... 301<br />
6.3.21.2 Innensicht ........................................................................................ 302<br />
6.3.22 Methodenfragment 18 – Retrospektive Backend ................................... 304<br />
6.3.22.1 Aussensicht ..................................................................................... 304
Inhaltsverzeichnis<br />
xiii<br />
6.3.22.2 Innensicht ........................................................................................ 305<br />
6.3.23 Methodenfragment 19 – Projektabschluss ............................................. 307<br />
6.3.23.1 Aussensicht ..................................................................................... 307<br />
6.3.23.2 Innensicht ........................................................................................ 308<br />
6.4 Resultierende Beschreibungsmodelle der situativen Methode .................. 311<br />
6.4.1 Dokumentationsmodell .......................................................................... 311<br />
6.4.2 Rollenmodell .......................................................................................... 313<br />
6.4.3 Informationsmodell ................................................................................ 314<br />
7 Evaluation der situativen Methode ......................................................... 319<br />
7.1 Evaluation in der gestaltungsorientierten Wirtschaftsinformatik .............. 319<br />
7.2 Analytische Evaluation ............................................................................... 321<br />
7.2.1 Evaluation bezüglich inhaltlicher Anforderungen ................................. 321<br />
7.2.2 Evaluation bezüglich methodischer Anforderungen .............................. 328<br />
7.3 Empirische Evaluation ............................................................................... 330<br />
7.3.1 Diskussion der Phasen der situativen Methode ...................................... 331<br />
7.3.2 Diskussion des Methodenentwurfs als Ganzes ...................................... 337<br />
8 Zusammenfassung und Ausblick ............................................................ 341<br />
8.1 Zusammenfassung der Forschungsarbeit ................................................... 341<br />
8.2 Kritische Würdigung .................................................................................. 344<br />
8.3 Ausblick und weiterer Forschungsbedarf ................................................... 347<br />
Anhang A: Fragebogen der Umfrage ...................................................................... 351<br />
Anhang B: Interviewleitfaden für die Fallstudien .................................................. 353<br />
Anhang C: Interviewleitfaden für die Evaluation .................................................. 355<br />
Anhang D: Ansprechpersonen zu den Fallstudien ................................................. 358<br />
Literaturverzeichnis .................................................................................................. 361
Abkürzungsverzeichnis<br />
xv<br />
Abkürzungsverzeichnis<br />
AIS<br />
ANSI<br />
AP<br />
APU<br />
BE<br />
BFS<br />
BI<br />
BICC<br />
BIT<br />
CC<br />
COCOMO<br />
DIN<br />
DL<br />
DM<br />
DMS<br />
DR<br />
DS<br />
DSDM<br />
DSR<br />
DSS<br />
DWH<br />
EIS<br />
ESS<br />
ETL<br />
EZV<br />
FDD<br />
GUI<br />
HTML<br />
IBA<br />
IEEE<br />
IIL<br />
IKT<br />
INVEST<br />
IP<br />
IS<br />
ISB<br />
ISR<br />
Analytische <strong>Informationssysteme</strong><br />
American National Standards Institute<br />
Arbeitspaket<br />
Analytische Prozessunterstützung<br />
(St. Galler Ansatz des) Business Engineering<br />
Bundesamt für Statistik<br />
Business Intelligence<br />
Business Intelligence Competence Center<br />
Bundesamt für Informatik und Telekommunikation<br />
Competence Center<br />
Constructive Cost Model<br />
Deutsches Institut für Normung e.V.<br />
Dienstleister<br />
Data Mart<br />
Data Mining System<br />
Design Research<br />
Design Science<br />
Dynamic System Development Method<br />
Design Science Research<br />
Decision Support System<br />
Data Warehouse<br />
Executive Information System<br />
Executive Support System<br />
Extract, Transform, Load<br />
Eidgenössische Zollverwaltung<br />
Feature Driven Development<br />
Graphical User Interface<br />
Hypertext Markup Language<br />
Informationsbedarfsanalyse<br />
Institute of Electrical and Electronics Engineers<br />
Integrierte Informationslogistik<br />
Informations- und Kommunikationstechnologie<br />
independent, negotiable, valuable, estimatable, small, testable<br />
Informationsportal<br />
Informationssystem<br />
Informatikstrategieorgan Bund<br />
Information Systems Research
xvi<br />
Abkürzungsverzeichnis<br />
IT<br />
Informationstechnologie<br />
ITIL<br />
IT Infrastructure Library<br />
ITPM<br />
IT Process Quality Management Methode<br />
IWI-HSG Institut für Wirtschaftsinformatik der Universität St. Gallen<br />
KMO-Kriterium Kaiser-Mayer-Olkin-Kriterium<br />
MA<br />
Mitarbeitende<br />
ME<br />
Methoden-Engineering<br />
MIS<br />
Management Information System<br />
MSA<br />
Measure of Sampling Adequacy<br />
MSS<br />
Management Support System<br />
NSGMM Neues St. Galler Managementmodell<br />
OGC<br />
Office of Government Commerce<br />
OLAP<br />
Online Analytical Processing<br />
PMBoK Project Management Body of Knowledge<br />
PMI<br />
Project Management Institute<br />
PRINCE2 Projects in Controlled Environments 2<br />
PROMET BECS Projektmethode Business Engineering Case Studies<br />
PROMPT Project Resource Organisation Management Planning Technique<br />
PT<br />
Projekttyp<br />
QSP<br />
Quality Sparring Partner<br />
RACI<br />
responsable, accountable, consulted, informed<br />
ROI<br />
Return on Investment<br />
RUP<br />
Rational Unified Process<br />
SECO<br />
Staatssekretariat für Wirtschaft<br />
SLA<br />
Service Level Agreement<br />
SME<br />
Situatives Methoden-Engineering<br />
SOA<br />
Service Orientierte Architekturen<br />
SQL<br />
Structured Query Language<br />
STROIS Strategic Orientation of the Portfolio of Information Systems<br />
SWOT<br />
Strengths, Weaknesses, Opportunities, Threats<br />
TIS<br />
Transaktionale <strong>Informationssysteme</strong><br />
TP<br />
Teilprojekt<br />
UML<br />
Unified Modeling Language<br />
WI<br />
Wirtschaftsinformatik<br />
WIP<br />
Work in Progress<br />
WKWI Wissenschaftliche Kommission für Wirtschaftsinformatik<br />
WWW<br />
World Wide Web<br />
XP<br />
Extreme Programming
Abbildungsverzeichnis<br />
xvii<br />
Abbildungsverzeichnis<br />
Abbildung 1: Design Science Research Cycle nach Hevner ........................................ 9<br />
Abbildung 2:<br />
Abbildung 3:<br />
Bezugsrahmen zur Einordnung gestaltungsorientierter<br />
Forschung ............................................................................................. 10<br />
Zuordnung der DSR-Artefakttypen zur Forschungskonzeption<br />
nach CHMIELEWICZ. ............................................................................. 12<br />
Abbildung 4: Forschungsprozess der Dissertation ..................................................... 15<br />
Abbildung 5: Struktur und Aufbau der Forschungsarbeit .......................................... 18<br />
Abbildung 6: Projektgetriebene vs. kontinuierliche Veränderung ............................. 22<br />
Abbildung 7:<br />
Gestaltungsebenen des St. Galler Ansatz des<br />
Business Engineering ........................................................................... 24<br />
Abbildung 8: Erweitertes Metamodell des Methoden-Engineerings ......................... 27<br />
Abbildung 9:<br />
Historische Entwicklung der Rechnerunterstützung des<br />
Managements ....................................................................................... 29<br />
Abbildung 10: Positionierung der zentralen Konzeptionen von AIS ........................... 35<br />
Abbildung 11: Entwicklung des <strong>Projektmanagement</strong>s am Beispiel<br />
ausgewählter Forschungs- und Entwicklungsprojekte ......................... 37<br />
Abbildung 12: Aufgabenabgrenzung bei Projekten ..................................................... 39<br />
Abbildung 13: Phasenmodell von HERMES ............................................................... 42<br />
Abbildung 14: Vorgehensmodell des Rational Unified Process (RUP) ...................... 50<br />
Abbildung 15: Stark abstrahierte Darstellung des V-Modells ..................................... 53<br />
Abbildung 16: Vorgehensweise in Scrum .................................................................... 67<br />
Abbildung 17: Einordnung der vorgestellten agilen Ansätze nach Grad der<br />
Agilität und Entwicklungsperspektive ................................................. 74<br />
Abbildung 18: Suchstrategie für agile AIS-Entwicklung ............................................ 76<br />
Abbildung 19: Inhaltlicher Untersuchungsrahmen für die Literaturanalyse ................ 78<br />
Abbildung 20: Scree-Plot für die Faktorenanalyse ...................................................... 92<br />
Abbildung 21: Dendrogramm der Clusteranalyse ........................................................ 96<br />
Abbildung 22: Elbow-Kriterium zu Bestimmung der Clusterzahl ............................... 97
xviii<br />
Abbildungsverzeichnis<br />
Abbildung 23: Ergebnisse der Clusteranalyse (Gestaltungsfaktoren 1 und 4) ............ 98<br />
Abbildung 24: Ergebnisse der Clusteranalyse (Gestaltungsfaktoren 2 und 3) ............ 99<br />
Abbildung 25: Abgeleitete Projekttypen .................................................................... 101<br />
Abbildung 26: Projektfokus der Projekttypen A und B ............................................. 102<br />
Abbildung 27: Erwartungshaltung vs. Agile und Wasserfall-Ansatz ........................ 113<br />
Abbildung 28: Anforderungstausch und Change-Request bei BLUEFORTE .......... 115<br />
Abbildung 29: Ablauf eines vier-Wochen Sprints bei BLUEFORTE ....................... 116<br />
Abbildung 30: Abnahmeprozess für Entwicklungspakete bei BLUEFORTE ........... 125<br />
Abbildung 31: Phasen der IT Process Management-Methode ................................... 127<br />
Abbildung 32: Agile Vorgehensweise bei der BMW Group ..................................... 134<br />
Abbildung 33: Grundlegendes Vorgehen im Projekt bei SMC ................................. 157<br />
Abbildung 34: Elemente eines Methodenfragments .................................................. 191<br />
Abbildung 35: Spektrum situativer Methoden ........................................................... 193<br />
Abbildung 36: Kombination aus quantitativen und qualitativen<br />
Forschungsmethoden ......................................................................... 194<br />
Abbildung 37: Vorgehensmodell der situativen Methode ......................................... 199<br />
Abbildung 38: Verwendete Elemente der BPMN ...................................................... 204<br />
Abbildung 39: Entscheidungsbaum für teamspezifische Voraussetzungen<br />
(Projekttyp 1) ..................................................................................... 207<br />
Abbildung 40: Entscheidungsbaum für Agilität der Entwicklung<br />
(Projekttyp 2) ..................................................................................... 207<br />
Abbildung 41: Entscheidungsbaum für organisatorischen Reifegrad der<br />
AIS-Landschaft .................................................................................. 208<br />
Abbildung 42: Entscheidungsbaum für technischen Reifegrad der<br />
AIS-Landschaft .................................................................................. 209<br />
Abbildung 43: Funktionsweise zwischen Product Backlog und<br />
Release Backlog ................................................................................. 244<br />
Abbildung 44: Wirkungsweise des Pipelinings ......................................................... 253<br />
Abbildung 45: Ablauf eines Frontend-Sprints ........................................................... 269<br />
Abbildung 46: Beispiel für ein Burn Down Chart ..................................................... 272
Abbildungsverzeichnis<br />
xix<br />
Abbildung 47: Zusammenspiel von Scrum und Wasserfall-Ansatz innerhalb<br />
eines Backend-Sprints ........................................................................ 288<br />
Abbildung 48: Informationsmodell der situativen Methode ...................................... 315<br />
Abbildung 49: Systematisierung der Evaluationstypen ............................................. 320
Tabellenverzeichnis<br />
xxi<br />
Tabellenverzeichnis<br />
Tabelle 1: Charakteristika von Wasserfall-Ansatz und Agilität ........................... 72<br />
Tabelle 2:<br />
Adressierung agiler Prinzipien durch die betrachteten<br />
agilen Methoden ................................................................................... 73<br />
Tabelle 3: Beschreibung der Konzepte ................................................................. 79<br />
Tabelle 4: Übersicht und Bewertung der untersuchten Ansätze ........................... 87<br />
Tabelle 5:<br />
Zusammensetzung der Rückläufer nach Branche und<br />
Unternehmensgrösse ............................................................................ 90<br />
Tabelle 6: Eigenwerte ............................................................................................ 92<br />
Tabelle 7: Variablen und deren Ladungen auf die extrahierten Faktoren ............. 94<br />
Tabelle 8: Entwicklung der Fehlerquadratsummen .............................................. 97<br />
Tabelle 9: Faktorwerte der jeweiligen Cluster ...................................................... 97<br />
Tabelle 10: Induktiv und deduktiv ermittelte Kontexttypen ................................. 104<br />
Tabelle 11: Situationsmatrix mit Kontext- und Projekttypen ............................... 105<br />
Tabelle 12: Konsolidierte Situationsmatrix mit Kontext- und Projekttypen ........ 106<br />
Tabelle 13: Positionierung der untersuchten Fallstudien ...................................... 109<br />
Tabelle 14: Unternehmensprofil BLUEFORTE GmbH ....................................... 110<br />
Tabelle 15: Unternehmensprofil BMW Group ..................................................... 126<br />
Tabelle 16: Hauptaspekte der agilen Vorgehensweise bei der BMW Group ....... 133<br />
Tabelle 17: Unternehmensprofil Steria Mummert Consulting .............................. 149<br />
Tabelle 18: Gegenüberstellung der Ergebnisse in Scrum und RUP ..................... 167<br />
Tabelle 19:<br />
Abgeleitetes und generalisiertes Vorgehen bei<br />
BLUEFORTE GmbH ......................................................................... 175<br />
Tabelle 20: Abgeleitetes und generalisiertes Vorgehen bei BMW AG ................ 176<br />
Tabelle 21:<br />
Tabelle 22:<br />
Abgeleitetes und generalisiertes Vorgehen bei<br />
Steria Mummert Consulting AG ........................................................ 177<br />
Abgeleitetes und generalisiertes Vorgehen bei einer<br />
Schweizerischen Grossbank (grössere Projekte) ............................... 179
xxii<br />
Tabelle 23:<br />
Abgeleitetes und generalisiertes Vorgehen bei einer<br />
Tabellenverzeichnis<br />
Schweizerischen Grossbank (kleinere Projekte) ................................ 179<br />
Tabelle 24: Situationsspezifische Einordnung der Fallstudien ............................. 182<br />
Tabelle 25: Anforderungen aus der Praxis ............................................................ 187<br />
Tabelle 26:<br />
Kernbereiche und deren durchschnittliche Umsetzungsgrade<br />
bzw. Abweichungen ........................................................................... 188<br />
Tabelle 27: Methodenfragmente für die situative Methode .................................. 197<br />
Tabelle 28: Beschreibung der Aussensicht eines Methodenfragments................. 203<br />
Tabelle 29: Beschreibung der Innensicht eines Methodenfragments ................... 204<br />
Tabelle 30:<br />
Tabelle 31:<br />
Methodenfragment 01 – Grobe Start-/Ziel-Bestimmung<br />
(Aussensicht)...................................................................................... 205<br />
Methodenfragment 01 – Grobe Start-/Ziel-Bestimmung<br />
(Innensicht) ........................................................................................ 206<br />
Tabelle 32: Beteiligte Rollen Methodenfragment 01 ............................................ 210<br />
Tabelle 33:<br />
Tabelle 34:<br />
Methodenfragment A – Initialisierung der Strategie<br />
(Aussensicht)...................................................................................... 211<br />
Methodenfragment A – Initialisierung der Strategie<br />
(Innensicht) ........................................................................................ 212<br />
Tabelle 35: Beteiligte Rollen Methodenfragment A ............................................. 213<br />
Tabelle 36: Methodenfragment B – Strategieformulierung (Aussensicht)........... 214<br />
Tabelle 37: Methodenfragment B – Strategieformulierung (Innensicht) ............. 215<br />
Tabelle 38: Beteiligte Rollen Methodenfragment B ............................................. 217<br />
Tabelle 39: Methodenfragment C – Strategieumsetzung (Aussensicht)............... 218<br />
Tabelle 40: Methodenfragment C – Strategieumsetzung (Innensicht) ................. 219<br />
Tabelle 41: Beteiligte Rollen Methodenfragment C ............................................. 220<br />
Tabelle 42: Methodenfragment D – Strategiekontrolle (Aussensicht) ................. 221<br />
Tabelle 43: Methodenfragment D – Strategiekontrolle (Innensicht).................... 222<br />
Tabelle 44: Beteiligte Rollen Methodenfragment D ............................................. 223<br />
Tabelle 45: Methodenfragment 02 – Projektinitialisierung (Aussensicht)........... 224<br />
Tabelle 46: Methodenfragment 02 – Projektinitialisierung (Innensicht).............. 225
Tabellenverzeichnis<br />
xxiii<br />
Tabelle 47: Beteiligte Rollen Methodenfragment 02 ............................................ 228<br />
Tabelle 48: Methodenfragment 03 – Projektvision (Aussensicht)........................ 230<br />
Tabelle 49: Methodenfragment 03 – Projektvision (Innensicht) .......................... 231<br />
Tabelle 50: Detaillierungsstufen der Anforderungserhebung ............................... 232<br />
Tabelle 51: Beteiligte Rollen Methodenfragment 03 ............................................ 234<br />
Tabelle 52: Methodenfragment 04 – Definition Projektteam (Aussensicht) ........ 235<br />
Tabelle 53: Methodenfragment 04 – Definition Projektteam (Innensicht)........... 236<br />
Tabelle 54: Rollen im Projekt ............................................................................... 238<br />
Tabelle 55: Beteiligte Rollen Methodenfragment 04 ............................................ 241<br />
Tabelle 56:<br />
Tabelle 57:<br />
Methodenfragment 05 – Release- und Sprintplanung<br />
(Aussensicht)...................................................................................... 242<br />
Methodenfragment 05 – Release- und Sprintplanung<br />
(Innensicht)......................................................................................... 243<br />
Tabelle 58: Tabellarische Darstellung eines Product Backlogs ............................ 246<br />
Tabelle 59: Beteiligte Rollen Methodenfragment 05 ............................................ 247<br />
Tabelle 60: Methodenfragment 06 – Planung Release (Aussensicht) .................. 248<br />
Tabelle 61: Methodenfragment 06 – Planung Release (Innensicht) ..................... 249<br />
Tabelle 62: Fibonacci-Reihe zur relativen Schätzung von Aufwänden ................ 250<br />
Tabelle 63: Mögliche Ausgestaltung eines Releaseplans ..................................... 252<br />
Tabelle 64: Beteiligte Rollen Methodenfragment 06 ............................................ 253<br />
Tabelle 65: Methodenfragment 07 – Umsetzung Release (Aussensicht) ............. 255<br />
Tabelle 66: Methodenfragment 07 – Umsetzung Release (Innensicht) ................ 256<br />
Tabelle 67: Beteiligte Rollen Methodenfragment 07 ............................................ 258<br />
Tabelle 68:<br />
Tabelle 69:<br />
Methodenfragment 08 – Review und Deploy Release<br />
(Aussensicht)...................................................................................... 260<br />
Methodenfragment 08 – Review und Deploy Release<br />
(Innensicht)......................................................................................... 261<br />
Tabelle 70: Beteiligte Rollen Methodenfragment 08 ............................................ 263<br />
Tabelle 71: Methodenfragment 09 – Retrospektive Release (Aussensicht) ......... 264<br />
Tabelle 72: Methodenfragment 09 – Retrospektive Release (Innensicht) ............ 265
xxiv<br />
Tabellenverzeichnis<br />
Tabelle 73: Beteiligte Rollen Methodenfragment 09 ............................................ 266<br />
Tabelle 74: Methodenfragment 10 – Sprintplanung Frontend (Aussensicht)....... 267<br />
Tabelle 75: Methodenfragment 10 – Sprintplanung Frontend (Innensicht) ......... 268<br />
Tabelle 76: Beispielhafte Darstellung eines Sprint Backlogs ............................... 271<br />
Tabelle 77: Beteiligte Rollen Methodenfragment 10 ............................................ 272<br />
Tabelle 78:<br />
Tabelle 79:<br />
Methodenfragment 11 – Konzept und Realisierung Frontend<br />
(Aussensicht)...................................................................................... 274<br />
Methodenfragment 11 – Konzept und Realisierung Frontend<br />
(Innensicht) ........................................................................................ 275<br />
Tabelle 80: Beteiligte Rollen Methodenfragment 11 ............................................ 277<br />
Tabelle 81:<br />
Tabelle 82:<br />
Methodenfragment 12 – Review und Deploy Frontend<br />
(Aussensicht)...................................................................................... 279<br />
Methodenfragment 12 – Review und Deploy Frontend<br />
(Innensicht) ........................................................................................ 280<br />
Tabelle 83: Beteiligte Rollen Methodenfragment 12 ............................................ 282<br />
Tabelle 84:<br />
Tabelle 85:<br />
Methodenfragment 13 – Retrospektive Frontend-Sprint<br />
(Aussensicht)...................................................................................... 283<br />
Methodenfragment 13 – Retrospektive Frontend-Sprint<br />
(Innensicht) ........................................................................................ 284<br />
Tabelle 86: Beteiligte Rollen Methodenfragment 13 ............................................ 284<br />
Tabelle 87:<br />
Tabelle 88:<br />
Methodenfragment 14 – Planung und Analyse Backend<br />
(Aussensicht)...................................................................................... 286<br />
Methodenfragment 14 – Planung und Analyse Backend<br />
(Innensicht) ........................................................................................ 287<br />
Tabelle 89: Beteiligte Rollen Methodenfragment 14 ............................................ 290<br />
Tabelle 90: Methodenfragment 15 – Design Backend (Aussensicht) .................. 292<br />
Tabelle 91: Methodenfragment 15 – Design Backend (Innensicht) ..................... 294<br />
Tabelle 92: Beteiligte Rollen Methodenfragment 15 ............................................ 295<br />
Tabelle 93: Methodenfragment 16 – Realisierung Backend (Aussensicht) ......... 297<br />
Tabelle 94: Methodenfragment 16 – Realisierung Backend (Innensicht) ............ 298
Tabellenverzeichnis<br />
xxv<br />
Tabelle 95: Beteiligte Rollen Methodenfragment 16 ............................................ 300<br />
Tabelle 96:<br />
Tabelle 97:<br />
Methodenfragment 17 – Review und Deploy Backend<br />
(Aussensicht)...................................................................................... 301<br />
Methodenfragment 17 – Review und Deploy Backend<br />
(Innensicht)......................................................................................... 302<br />
Tabelle 98: Beteiligte Rollen Methodenfragment 17 ............................................ 304<br />
Tabelle 99: Methodenfragment 18 – Retrospektive Backend (Aussensicht)........ 305<br />
Tabelle 100: Methodenfragment 18 – Retrospektive Backend (Innensicht) .......... 306<br />
Tabelle 101: Beteiligte Rollen Methodenfragment 18 ............................................ 307<br />
Tabelle 102: Methodenfragment 19 – Projektabschluss (Aussensicht) .................. 308<br />
Tabelle 103: Methodenfragment 19 – Projektabschluss (Innensicht)..................... 309<br />
Tabelle 104: Beteiligte Rollen Methodenfragment 19 ............................................ 310<br />
Tabelle 105: Dokumentationsmodell der situativen Methode ................................ 312<br />
Tabelle 106: Rollenmodell der situativen Methode ................................................ 314<br />
Tabelle 107:<br />
Beschreibung der Entitäten um die das Core Business<br />
Metamodell erweitert wurde .............................................................. 318<br />
Tabelle 108: Adressierung der Anforderungen aus dem PMBoK Guide ............... 323<br />
Tabelle 109: Adressierung der Anforderungen aus der Praxis (Teil I) ................... 325<br />
Tabelle 110: Adressierung der Anforderungen aus der Praxis (Teil II).................. 326<br />
Tabelle 111:<br />
Anforderungsadressierung wichtigster Ansätze vs.<br />
eigener Ansatz .................................................................................... 327<br />
Tabelle 112: Übersicht Evaluation: Agile Strategie ................................................ 332<br />
Tabelle 113: Übersicht Evaluation: Initialisierungs- und Definitionsphase ........... 333<br />
Tabelle 114: Übersicht Evaluation: Release-Cycle ................................................. 334<br />
Tabelle 115: Übersicht Evaluation: Frontend-Sprint .............................................. 335<br />
Tabelle 116: Übersicht Evaluation: Backend-Sprint ............................................... 336<br />
Tabelle 117: Übersicht Evaluation: Projektabschluss ............................................. 337<br />
Tabelle 118: Übersicht Evaluation: Gesamtbeurteilung ......................................... 337<br />
Tabelle 119: Adressierung der Ziele der Forschungsarbeit .................................... 345
Kurzfassung<br />
xxvii<br />
Kurzfassung<br />
Ausgangspunkt dieser Arbeit ist die Feststellung in der Praxis, dass ein grosser Teil<br />
von IT-Projekten im Allgemeinen und Projekten zur Entwicklung <strong>analytische</strong>r <strong>Informationssysteme</strong><br />
im Speziellen nach wie vor oft scheitern, bzw. zeitlich oder finanziell<br />
überzogen werden oder hinter den Erwartungen zurückbleiben. Analytische <strong>Informationssysteme</strong><br />
unterscheiden sich ausserdem aufgrund ihrer spezifischen Charakteristika<br />
erheblich von Systemen im transaktionalen Umfeld. Insbesondere volatile Anforderungen,<br />
heterogene Nutzungsgruppen, sowie bereichs- bzw. unternehmensübergreifende<br />
Datenintegration und -nutzung sind Aspekte, die für Projekte im Umfeld <strong>analytische</strong>r<br />
<strong>Informationssysteme</strong> eine besondere Vorgehensweise notwendig machen. In der<br />
Softwareentwicklung haben sich in der Vergangenheit agile Ansätze etabliert, die vor<br />
allem den volatilen Anforderungen Rechnung tragen.<br />
Zielsetzung der Arbeit ist die Konstruktion eines methodischen Ansatzes zur effektiven<br />
und effizienten Abwicklung von Projekten im Umfeld <strong>analytische</strong>r <strong>Informationssysteme</strong>.<br />
Hierzu wird Scrum, eine weit verbreitete agile Entwicklungsmethode, auf<br />
deren Spezifika adaptiert und mit traditionellen Ansätzen für solche Projekte kombiniert.<br />
Gleichzeitig fliessen Erkenntnisse aus der Literatur sowie aus erfolgreichen agilen<br />
Projekten in der Praxis, mit ein. Die komponentenorientierte Gestaltung der Methode<br />
ermöglicht ausserdem eine Anwendung in unterschiedlichen Entwicklungssituationen.<br />
Diese sind begründet durch verschiedene Projektschwerpunkte oder Rahmenbedingungen<br />
wie bspw. der Erfahrung mit agiler Entwicklung oder der vielfältigen<br />
Ausprägungen <strong>analytische</strong>r <strong>Informationssysteme</strong>.<br />
Der Nachweis der Praxistauglichkeit und Nützlichkeit aber auch der korrekten Herleitung<br />
und Konstruktion der situativen Methode wird im Rahmen der Evaluation erbracht.<br />
Diese erfolgt einerseits analytisch auf Basis zuvor aufgestellter inhaltlicher und<br />
methodischer Anforderungen und andererseits mittels einer Expertenbefragung. Mit<br />
der Verwendung adäquater Forschungsmethoden für die Konstruktion und der anschliessenden<br />
Evaluation der situativen Methode deckt vorliegende Arbeit die wesentlichen<br />
Forschungsaktivitäten der gestaltungsorientierten Wirtschaftsinformatik ab.<br />
Schlüsselwörter: Agile Entwicklung, Analytische <strong>Informationssysteme</strong>, Business Engineering,<br />
Business Intelligence, Data Warehouse, Design Research, Gestaltungsorientierte<br />
Wirtschaftsinformatik, Informationslogistik, <strong>Projektmanagement</strong>, Scrum, Situatives<br />
Methoden Engineering, Strategie
xxviii<br />
Abstract<br />
Abstract<br />
The motivation for this work is founded in the observation that many development<br />
projects for analytical information systems either fall short of expectations or are not<br />
completed in time or on budget. A major reason for this issue lies in the very specific<br />
characteristics of analytical information systems, which vary significantly from those<br />
of transaction-oriented systems. Particularities like volatile requirements, heterogeneous<br />
user groups and the need for area- or company-wide data integration and usage<br />
require very specific method support. For handling volatile requirements traditional<br />
software development has yielded agile approaches.<br />
The work at hand aims at developing a methodological approach to carry out development<br />
projects in the field of analytical information systems both more effectively and<br />
efficiently. In order to thoroughly address and rigorously solve the above named challenges<br />
Scrum, a widespread agile development method, is adapted to the specifics of<br />
the considered projects. Findings from a literature analyses, as well as from successful<br />
agile projects are used as inputs. The resulting component-oriented approach allows an<br />
adaptation for various development situations. The situations are characterized by means<br />
of project types and general conditions such as experience with agile development<br />
or use of different types of analytical information systems.<br />
Evidence for the method’s practicality and usefulness as well as its rigorous derivation<br />
and construction is realized by means of a comprehensive method evaluation. The evaluation<br />
is completed both analytically based on previously defined content-related and<br />
methodological criteria and empirically through an expert survey. Beginning with<br />
problem identification in practice, the subsequent development and application of appropriate<br />
methods for project development and the final evaluation of the situational<br />
method, this work covers the complete cycle of design research.<br />
Keywords: Agile Development, Analytical Information Systems, Business Engineering,<br />
Data Warehouse, Design Research, Information Logistics, Project Management,<br />
Scrum, Situational Method Engineering, Strategy
Hinweis zur Verwendung geschlechtsneutraler Formulierungen<br />
xxix<br />
Hinweis zur Verwendung geschlechtsneutraler<br />
Formulierungen<br />
Die vorliegende Arbeit berücksichtigt, soweit möglich, konform der Zielsetzung der<br />
Konferenz der Gleichstellungs- und Frauenbeauftragten an Schweizer Universitäten<br />
und Hochschulen 1 die Empfehlungen der Dudenredaktion 2 zur sprachlichen Gleichstellung<br />
von Frauen und Männern.<br />
Im Sinne der adäquaten Lesbarkeit wird jedoch der Praxis der Dudenredaktion 3 folgend<br />
auf die Verwendung von Doppelnennungen und Kurzformen verzichtet. Durch<br />
die Verwendung von Partizipien oder Sachbezeichnungen an Stelle von Personenbezeichnungen<br />
wird – wo immer möglich – die sprachliche Gleichbehandlung von Frauen<br />
und Männern gewährleistet. Erscheint dies aus sachlogischen oder sprachästhetischen<br />
Gründen nicht sinnvoll, wird in Ausnahmefällen stellvertretend für beide Geschlechter<br />
und ohne Einschränkung der sprachlichen Gleichstellung von Frauen und<br />
Männern die männliche Form verwendet.<br />
Dadurch werden in der vorliegenden Arbeit Frauen und Männer gleichermassen berücksichtigt.<br />
1 Kofrah 2005.<br />
2 Eickhoff 1999.<br />
3 Eickhoff 1999, S. 3.
Einleitung 1<br />
1 Einleitung<br />
1.1 Ausgangslage und Problemstellung<br />
Gerade in wirtschaftlich schwierigen Zeiten sehen sich Unternehmen zunehmend mit<br />
neuen Herausforderungen konfrontiert. Durch Internationalisierung und Globalisierung<br />
4 , durch steigende regulatorische Anforderungen 5 , aber auch durch Kosteneinsparungsdruck<br />
6 , sind Organisationen im Informationszeitalter gezwungen, sich schnell<br />
und kontinuierlich zu verändern. Strategische, organisatorische oder technische Innovationen<br />
helfen, dieser Herausforderung entgegenzutreten und schaffen die Voraussetzung<br />
für Unternehmen, längerfristig ihre Wettbewerbsfähigkeit zu erhalten 7 . Informationstechnologie<br />
(IT) fungiert hier als befähigendes und unterstützendes Werkzeug 8 .<br />
Die Versorgung von Führungs- und Fachkräften mit adäquater Information ist in diesem<br />
Zusammenhang als hochrelevant einzustufen 9 . Durch die adäquate Nutzung historisierter,<br />
nicht volatiler Daten mittels <strong>analytische</strong>r <strong>Informationssysteme</strong> (AIS) und der<br />
dadurch erzielten Transparenz, kann schnell auf Veränderung reagiert werden. Innerhalb<br />
der <strong>Informationssysteme</strong> (IS) bilden AIS eine wichtige Gruppe 10 . Sie unterstützen<br />
Entscheidungen basierend auf der Integration und Anreicherung transaktionaler Daten.<br />
Aufgrund der weitreichenden Charakteristika der durch AIS unterstützten Entscheidungen,<br />
können diese als sehr heterogene IS-Gruppe dargestellt werden 11 .<br />
Die Vielschichtigkeit von AIS ist dabei die Herausforderung bei der Gestaltung methodischer<br />
Vorgehensweisen für entsprechende AIS-Projekte. Einer der Hauptfaktoren<br />
für diese Problematik sind die volatilen Anforderungen, die sich in Projekten im Umfeld<br />
von AIS ergeben 12 . Diese resultieren insbesondere daraus, dass Entscheidungsprozesse,<br />
die durch AIS unterstützt werden, im Gegensatz zu den Prozessen in transaktionalen<br />
Systemen wenig wiederholend, wenig standardisiert und weniger strukturiert<br />
sind 13 . Die Nutzungsgruppen von AIS bewegen sich darüber hinaus auf allen Unternehmensebenen<br />
bis hin zum Top-Management. Aufgrund der Heterogenität dieser<br />
4<br />
5<br />
6<br />
7<br />
8<br />
9<br />
10<br />
11<br />
12<br />
13<br />
Vgl. WTO 2007.<br />
Vgl. Caldwell 2009, S. 2ff.; Hostmann 2009, S. 1; Klesse et al. 2004.<br />
Vgl. Hostmann 2009, S. 1; Wolff 2010.<br />
Vgl. Kagermann, Österle 2006, S. 277ff.<br />
Vgl. Earl, Feeny 2000; Henderson, Venkatraman 1999; Ives, Learmonth 1984, S. 1193.<br />
Vgl. Sprague Jr 1980, S. 4.<br />
Vgl. Arnott et al. 2007, S. 2078; Arnott, Pervan 2005, S. 25; Elbashir et al. 2008, S. 136.<br />
Vgl. Stroh et al. 2011, S. 37.<br />
Vgl. Rajlich 2006, S. 68.<br />
Vgl. Brobst et al. 2008; Hughes 2008; Shin 2002.
2 Einleitung<br />
Gruppen und damit auch der Entscheidungen, die getroffen werden, ist es in den meisten<br />
Fällen nicht möglich, Anforderungen an ein Projekt im AIS-Umfeld vor der eigentlichen<br />
Entwicklung angemessen zu definieren 14 . Schlussendlich trägt die bereichsübergreifende<br />
Integration unterschiedlichster Datenquellen zu einer Komplexität bei,<br />
die die Entwicklung transaktionaler Anwendungen in der Regel deutlich übersteigt 15 .<br />
Anforderungen an AIS unterliegen, wie dies auch für andere IS gilt, einem kontinuierlichen,<br />
immer schnelllebigeren Wandel 16 . Es gilt also, diesen externen wie auch internen<br />
Anforderungen gerecht zu werden. Schnell auf verändernde Rahmenbedingungen<br />
zu reagieren, bedeutet, dass diese IT-seitig sowie organisatorisch effizient und effektiv<br />
umgesetzt werden müssen. Aus diesem Grund muss das Management von AIS-<br />
Projekten entsprechend agil und flexibel gestaltet werden. Dies gilt gleichermassen für<br />
Erst-, als auch für Weiterentwicklungsprojekte im AIS-Umfeld. Gleichzeitig zeigen<br />
Untersuchungen, dass ein grosser Teil von IT-Projekten entweder ganz scheitert oder<br />
finanziell bzw. zeitlich überzogen wird – und dies, obwohl mittlerweile langjährige<br />
Erfahrungen mit dieser Art von Projekten bestehen 17 . Die Tragweite gescheiterter AIS-<br />
Projekte untermauert eine Studie aus dem Jahre 2009, im Rahmen derer Entscheidungsträger<br />
in Unternehmen befragt wurden. Dabei gaben 59% von ihnen an, dass sie<br />
Informationen vermissen, die für ihre Tätigkeit wertvoll wären. Die Hälfte der bereits<br />
verfügbaren Information sei allerdings für ihre Arbeit nicht relevant 18 . Einer der Gründe<br />
für dieses Scheitern von AIS-Projekten liegt darin, in diesem Bereich oftmals traditionelle,<br />
schwergewichtige Wasserfall-Ansätze im Einsatz sind, die es nicht erlauben,<br />
auf sich ändernde Rahmenbedingungen und Anforderungen einzugehen.<br />
Im Rahmen einer explorativen Untersuchung mittels vier Interviews bei den Schweizerischen<br />
Bundesbehörden konnte diese Problematik empirisch belegt werden 19 . Dabei<br />
wurde ausserdem untersucht, welche Herausforderungen und Problembereiche sich im<br />
Einsatz einer klassischen, wasserfallorientierten <strong>Projektmanagement</strong>-Methode<br />
14<br />
15<br />
16<br />
17<br />
18<br />
19<br />
Vgl. March, Hevner 2007, S. 1034f.<br />
Vgl. Brobst et al. 2008; Clark et al. 2007; Finger 2011.<br />
Vgl. Chamoni, Gluchowski 2006; Hughes 2008.<br />
Vgl. Feldmüller et al. 2005, S. 7; Ramamurthy et al. 2008; Watson 2005; Wixom, Watson 2001 – Gerne<br />
wird in diesem Zusammenhang auch der Chaos Report der Standish Group zitiert (Standish 2009).<br />
Vgl. IBM 2009.<br />
Es fand je ein Interview mit Projektleitungen und Mitarbeitenden des Bundesamts für Informatik und Telekommunikation<br />
(BIT), des Bundesamts für Statistik (BFS), der Eidgenössischen Zollverwaltung (EZV) und<br />
dem Staatssekretariat für Wirtschaft (SECO) statt. Im Rahmen der jeweils ca. einstündigen Interviews wurde<br />
die Ausgangslage, die Probleme mit der bestehenden Methode und allfällige Lösungsansätze diskutiert. Die<br />
Details zu den Ansprechpersonen der Interviews sind in Anhang D verzeichnet.
Einleitung 3<br />
(HERMES 20 ) in AIS-Projekten ergeben. Dabei konnte festgestellt werden, dass diese<br />
Methode im Einsatz für AIS-Projekte deutlich angepasst wurde, damit sie erfolgreich<br />
eingesetzt werden konnte. Insbesondere in vier Bereichen wurde HERMES verändert.<br />
1. Die untersuchten Fälle vereinfachen die Methode sehr. Dabei werden deutlich weniger<br />
Phasen, Aktivitäten, Rollen und Ergebnisse verwendet, bzw. erstellt, als von der<br />
Methode vorgesehen. 2. Die betrachteten Projekte ergänzen die Methode um AISspezifische<br />
Aspekte. 3. Es wird zwischen einer fachlichen und einer technischen Organisation<br />
unterschieden. Insbesondere die Rollen werden dabei deutlich getrennt. 4.<br />
Alle untersuchten Projekte gehen iterativ vor. Es wird weniger sequentiell, als vielmehr<br />
in Zyklen gearbeitet, um sich langsam der Lösung zu nähern.<br />
Die beschriebene Diskrepanz zwischen der gegenwärtigen und der gewünschten Situation<br />
zeigt, dass Handlungsbedarf im Bereich des Managements von AIS-Projekten besteht.<br />
Wissenschaft und Praxis haben unterschiedliche Ansätze hervorgebracht, die das<br />
Management solcher Erst- und Weiterentwicklungsprojekte für AIS unterstützen.<br />
Oftmals bieten diese jedoch nur punktuell Unterstützung und lassen in ihrer Gesamthaftigkeit<br />
Verbesserungs- und Ausbaupotential erkennen. Andere Ansätze behandeln<br />
eine Vielzahl an Details und Eventualitäten in einem AIS-Projekt und sind damit durch<br />
deren Umfang und Aufbau in der Praxis kaum zu handhaben 21 .<br />
Neben dem aus der Praxis abgeleiteten Handlungsbedarf zeigt sich auch in der Literatur,<br />
dass schwergewichtige Methoden für AIS-Projekte nicht immer zielführend sind 22 .<br />
Vor diesem Hintergrund widmet sich vorliegende Arbeit der Frage, wie Projekte im<br />
Umfeld von AIS effektiv und effizient abgewickelt werden können, um den beschriebenen<br />
Problemfeldern zu begegnen. In der klassischen Softwareentwicklung haben<br />
sich in den letzten Jahren agile Vorgehensweisen etabliert 23 . Diese erlauben es, Anforderungen<br />
zeitnah zu adressieren und durch kleinere Arbeitspakete kontinuierlich fertige<br />
Produktinkremente zu liefern. Dieses Konzept wird im Rahmen dieser Arbeit auf<br />
AIS-Projekte adaptiert und in einen methodischen Ansatz zum Management von Erstund<br />
Weiterentwicklungsprojekten im Kontext von AIS mit einbezogen. Die angestrebte<br />
Lösung sieht ausserdem vor, situative Aspekte zu berücksichtigen. Dies erlaubt eine<br />
20<br />
21<br />
22<br />
23<br />
HERMES ist eine offene <strong>Projektmanagement</strong>methode zum Führen und Abwickeln von IT-Projekten (vgl.<br />
auch Abschnitt 2.3.1). Sie zeichnet sich durch einen hohen Detaillierungsgrad aus und orientiert sich am<br />
Wasserfall-Ansatz. Sie ist seit 1975 in der Bundesverwaltung der Schweiz im Einsatz. Für IT-Projekte des<br />
Bundes ist HERMES verbindlich (Informatikstrategieorgan Bund 2010a).<br />
Vgl. hierzu Kapitel 3.<br />
Der Handlungsbedarf in diesem Bereich wurde auch vom Informatikstrategieorgan Bund (ISB) erkannt.<br />
Dieses hat im September 2010 eine Studie zu HERMES in Verbindung mit Agilität am Beispiel von Scrum<br />
herausgegeben (Informatikstrategieorgan Bund 2010b).<br />
Vgl. bspw. Conboy 2009; Dyba, Dingsøyr 2008; Reifer 2002.
4 Einleitung<br />
Anwendung in unterschiedlichen Situationen, die sowohl Projekttypen als auch nicht<br />
projektspezifische Rahmenbedingungen berücksichtigt. Die Problemstellung für das<br />
Forschungsvorhaben dieser Arbeit kann somit folgendermassen formuliert werden:<br />
Problemstellung<br />
Wie können Erst- und Weiterentwicklungsprojekte für <strong>analytische</strong> <strong>Informationssysteme</strong><br />
effizienter und effektiver durchgeführt werden? Welchen methodischen Beitrag<br />
kann hierbei das Konzept der agilen Entwicklung leisten?<br />
Aufbauend auf der beschriebenen Ausgangslage und der Definition der Problemstellung<br />
für diese Arbeit, werden im Folgenden die zugrundeliegenden Forschungsfragen<br />
und Zielsetzungen abgeleitet. Im Rahmen der Erläuterung der Forschungsmethodik<br />
wird insbesondere auf die gestaltungsorientierte Wirtschaftsinformatik (WI) eingegangen<br />
und der Forschungsprozess beschrieben. Nach einer Skizzierung der Adressaten<br />
und Nutzenpotenziale schliesst das Kapitel mit einem Überblick über den Aufbau der<br />
Arbeit.<br />
1.2 Forschungsfragen und Zielsetzungen<br />
Auf der Grundlage der in Abschnitt 1.1 skizzierten Problemstellung, lässt sich für das<br />
Forschungsvorhaben eine zentrale Forschungsfrage formulieren. Allerdings ist die Voraussetzung<br />
für die Definition konkreter Ziele eine möglichst umfassende Kenntnis<br />
über die aktuelle Situation (Ist) und die anzustrebende Lösung (Soll). Hierzu gehören<br />
neben Kenntnissen über die konzeptionellen Grundlagen 24 , der Identifikation bestehender<br />
Lösungsansätze und deren Ausbaupotenzial 25 , auch die Analyse der existierenden<br />
endogenen und exogenen Einflussfaktoren 26 auf ein AIS-Projekt, sowie der inhaltlichen<br />
und methodischen Restriktionen. Vor diesem Hintergrund basiert die Formulierung<br />
der Ziele und Forschungsfragen auf den in den genannten Kapiteln untersuchten<br />
Aspekten.<br />
24<br />
25<br />
26<br />
Vgl. Kapitel 2.<br />
Vgl. Kapitel 3.<br />
Vgl. Kapitel 4.
Einleitung 5<br />
Forschungsfrage<br />
Wie muss eine adäquate methodische Unterstützung für das Management von Erst-<br />
und Weiterentwicklungsprojekten 27 für <strong>analytische</strong> <strong>Informationssysteme</strong>, unter Berücksichtigung<br />
derer spezifischen Eigenschaften und Charakteristika, mithilfe agiler<br />
Konzepte und anpassbar auf unternehmens- und projektspezifische Aspekte gestaltet<br />
werden, damit solche Projekte effizienter und effektiver abgewickelt werden können?<br />
Mit der Beantwortung der Forschungsfrage wird insbesondere ein Gestaltungsziel verfolgt.<br />
Neben Gestaltungszielen, also der Veränderung bestehender und Schaffung neuer<br />
Sachverhalte 28 , beschäftigt sich die WI 29 auch mit Erkenntniszielen, also dem Verständnis<br />
von Sachverhalten 30 . Erkenntnisziele bilden in der vorliegenden Arbeit die<br />
Basis für die Erreichung der Gestaltungsziele. Entsprechend werden drei Erkenntnisziele<br />
und vier Gestaltungsziele auf Grundlage der Problemstellung identifiziert.<br />
Erkenntnisziel: Welche endogenen und exogenen Gestaltungsfaktoren beeinflussen<br />
Projekte im Umfeld <strong>analytische</strong>r <strong>Informationssysteme</strong>?<br />
E 1 : Welche durch ein AIS-Projekt unveränderbaren Gestaltungsfaktoren (Kontexttypen)<br />
existieren in der Praxis und müssen von einem methodischen Ansatz berücksichtigt<br />
werden?<br />
E 2 : Welche durch ein AIS-Projekt veränderbaren Gestaltungsfaktoren (in Form von<br />
Realisierungsgraden bzw. darauf basierenden Projekttypen) existieren in der<br />
Praxis und müssen von einem methodischen Ansatz berücksichtigt werden?<br />
E 3 : Welche Kombinationen aus unveränderbaren (E 1 ) und veränderbaren Gestaltungsfaktoren<br />
(E 2 ) sind in der Praxis relevant und müssen von einem methodischen<br />
Ansatz berücksichtigt werden?<br />
Im Rahmen der Erkenntnisziele wird die in Abschnitt 1.1 beschriebene situative Gestaltung<br />
des methodischen Ansatzes aufgegriffen. Hierbei ist es in einem ersten Schritt<br />
notwendig, die relevanten, situationsspezifischen Konstellationen der Gestaltungsfaktoren<br />
zu identifizieren. Dies widerspiegelt das Haupterkenntnisziel. Diese Konstellationen<br />
ergeben sich aus der Identifikation unveränderbarer Rahmenbedingungen, die auf<br />
ein AIS-Projekt wirken (Kontexttypen) und veränderbaren Gestaltungsfaktoren (in<br />
27<br />
28<br />
29<br />
30<br />
Im Folgenden sind mit der Bezeichnung AIS-Projekt bzw. <strong>Projektmanagement</strong> für AIS jeweils sowohl Erst-,<br />
als auch Weiterentwicklungsprojekte gemeint.<br />
Vgl. Becker et al. 2003b, S. 315; Frank 1997, S. 31ff.; Laudon et al. 2010, S. 45ff.<br />
Vgl. Abschnitt 1.3.1.<br />
Vgl. Laudon et al. 2010, S. 45ff.
6 Einleitung<br />
Form von Realisierungsgraden bzw. der zugrunde liegenden Projekttypen) 31 . Diese<br />
Gestaltungsfaktoren widerspiegeln sich in den Unterzielen E 1 und E 2 . Die Identifikation<br />
der relevanten Kombinationen der Faktoren aus E 1 und E 2 ergibt E 3 . Für diese relevanten<br />
Kombinationen werden im Rahmen der Arbeit Adaptionsmechanismen im Sinne<br />
des situativen Methoden-Engineerings (SME) entwickelt 32 .<br />
Den Ausführungen in Abschnitt 1.1, sowie der Problemstellung und der Forschungsfrage<br />
folgend, können Gestaltungsziele für vorliegende Arbeit abgeleitet werden. Ziel<br />
dabei ist es, einen methodischen Ansatz für das Management von AIS-Projekten zu<br />
entwickeln. Dabei soll das Konzept der Agilität mit einbezogen und die spezifischen<br />
Charakteristika von AIS berücksichtigt werden (G 1 ). Ausgehend von den Erkenntniszielen<br />
E 1 -E 3 , sollen die identifizierten Gestaltungsfaktoren und die daraus resultierenden<br />
Situationen im Ansatz Berücksichtigung finden und entsprechende Adaptionsmechanismen<br />
für die Adaption des Ansatzes auf, die sich aus E 3 ergebenden relevanten<br />
Situationen, konstruiert werden (G 2 ). Schlussendlich soll mittels einer empirischen und<br />
<strong>analytische</strong>n Evaluation die Vorteilhaftigkeit und Nutzbarkeit des Ansatzes gezeigt<br />
werden. Ebenso sollen dabei auch mögliche Erweiterungspotenziale für den Ansatz<br />
identifiziert werden (G 3 ).<br />
Gestaltungsziel: Wie kann das Management von Projekten für <strong>analytische</strong> <strong>Informationssysteme</strong><br />
im Unternehmen methodisch adäquat unterstützt<br />
werden?<br />
G 1 : Es soll ein methodischer Ansatz entwickelt werden, der das Konzept der agilen<br />
Entwicklung auf die Domäne von AIS überträgt und dabei deren spezifische<br />
Charakteristika berücksichtigt.<br />
G 2 : Der methodische Ansatz soll so konstruiert sein, dass situative Aspekte, die<br />
durch die Gestaltungsfaktoren (E 1 -E 3 ) zum Ausdruck kommen, berücksichtigt<br />
werden. Dabei sollen Mechanismen mit einbezogen werden, die die Adaption<br />
der Methode auf spezifische Situationen erlauben.<br />
G 3 : Zur Ermittlung des Nutzenbeitrags des methodischen Ansatzes ist dieser einer<br />
empirischen und methodischen Evaluation zu unterziehen.<br />
31<br />
32<br />
Aus der Kombination aus Kontexttyp und Projekttyp ergeben sich nach dem Verständnis des situativen<br />
Methoden-Engineering nach BUCHER ET AL. (2007) Entwicklungssituationen (vgl. auch Abschnitt 2.1.3).<br />
Vgl. Gestaltungsziel 2 (G 2 ).
Einleitung 7<br />
1.3 Forschungsmethodik und -prozess<br />
Die vorliegende Arbeit begründet sich vor dem Hintergrund der praxisorientierten,<br />
angewandten Forschung, wie sie am Institut für Wirtschaftsinformatik der Universität<br />
St. Gallen (IWI-HSG) betrieben wird. Sie lässt sich deshalb zu weiten Teilen der gestaltungsorientierten<br />
WI zuordnen. Dieser Abschnitt erläutert die forschungsmethodischen<br />
Grundlagen der WI 33 . Anschliessend wird basierend darauf der Forschungsprozess<br />
der Dissertation detailliert vorgestellt 34 .<br />
1.3.1 Forschungsströmungen in der Wirtschaftsinformatik<br />
Die WI ist eine vergleichsweise junge Forschungsdisziplin 35 . Ihr interdisziplinärer<br />
Charakter zeigt sich in der Integration der Wissensgebiete der Wirtschaftswissenschaften<br />
und der Informatik 36 . Die Beantwortung von Forschungsfragen beinhaltet in einem<br />
ersten Schritt die Wahl der richtigen Forschungsmethodik.<br />
Gegenwärtig werden in der Forschung zu IS zwei grundsätzliche Forschungsparadigmen<br />
37 diskutiert. Einerseits existiert ein vor allem auf verhaltenswissenschaftliche Aspekte<br />
fokussierter, behavioristischer Ansatz (behavioral IS research). Dieser ist insbesondere<br />
im angelsächsischen Raum verbreitet und beschäftigt sich mit dem Verständnis<br />
von Phänomenen im Kontext von IS und deren Umwelt. Dabei steht im Vordergrund,<br />
diese zu erklären und zu prognostizieren 38 . Die Entwicklung von Theorien 39 ,<br />
deren Validierung, sowie die Erklärung und Prognose von Phänomenen in soziotechnischen<br />
Systemen, steht im Zentrum dieses Ansatzes 40 . Die dabei genutzten Forschungsmethoden<br />
stammen vor allem aus der empirischen Sozialforschung 41 und dominieren<br />
insbesondere die internationale Fachliteratur 42 .<br />
33<br />
Vgl. Abschnitt 1.3.1 und 1.3.2.<br />
34<br />
Vgl. Abschnitt 1.3.3.<br />
35<br />
Vgl. Rolf 1998; WKWI 2007.<br />
36<br />
Vgl. WKWI 2007.<br />
37<br />
Ein Paradigma umfasst „[…] Standards der Wissenschaftlichkeit, die innerhalb einer Wissenschaftsgemeinde<br />
anerkannt, ausserhalb dieser aber bezweifelt werden“ (Steinmann, Scherer 1994, S. 265). Sie bieten demnach<br />
einen Rahmen, wie in einer Forschungsdisziplin vorgegangen wird. Mittlerweile hat sich die Pluralität<br />
von Forschungsparadigmen durchgesetzt (Kuhn 1976; Lakatos 1980).<br />
38 Vgl. Zmud 1997, S. XXI.<br />
39<br />
Bezogen auf Wissenschaften wird als Theorie oft ein „Lehrgebäude [bezeichnet], ohne Rücksicht auf die<br />
Methode(n), mit denen es gewonnen wurde, oder auf seinen Gegenstand“ (Seiffert 1992, S. 386f.)<br />
40 Vgl. Gregor 2006, S. 612ff.; Hevner et al. 2004, S. 76.<br />
41 Vgl. Chen, Hirschheim 2004, S. 207f.; Schauer, Frank 2007, S. 134ff.<br />
42 Vgl. Niehaves 2006, S. 3; Schauer, Frank 2007, S. 121.
8 Einleitung<br />
Vor allem im europäischen bzw. deutschsprachigen Raum der WI dominiert das gestaltungsorientierte<br />
Paradigma (IS design (science 43 ) research) 44 . Dieses beschäftigt<br />
sich mit der Konstruktion von Artefakten. Mit Hilfe innovativer Ideen, Praktiken,<br />
technischer Fähigkeiten und Produkten sollen relevante Lösungen für praktische Probleme<br />
erarbeitet und bspw. der Nutzung und Implementierung von IS zur Verfügung<br />
gestellt werden 45 . Die vorherrschende Methodik der gestaltungsorientierten WI ist an<br />
die des ingenieurwissenschaftlichen Bereichs angelehnt 46 .<br />
Die beiden Strömungen grenzen sich initial deutlich voneinander ab. Das Ziel von behavioral<br />
IS research ist in erster Linie die Erkenntnis, also das Finden der „Wahrheit“.<br />
Dabei wird auf methodische Fundiertheit (rigor) priorisiert. Dem entgegen steht im IS<br />
design (science) research Nützlichkeit als Ziel (Gestaltungsziel) und Relevanz für die<br />
Praxis im Vordergrund (relevance) 47 . Zugunsten eines integrativen und sich ergänzenden<br />
Ansatzes im Sinne eines „Methodenpluralismus“ 48 , bzw. eines „konsolidierten<br />
Methodenspektrums“ 49 , postulieren neuere Quellen, dass sich die beiden Forschungsströmungen<br />
(rigor und relevance) nicht ausschliessen 50 . Im Gegenteil, die beiden<br />
Strömungen sind durch starke Interdependenzen gekennzeichnet 51 .<br />
Dies widerspiegelt sich in den Grundsätzen auch im DSR-Framework von Hevner 52 ,<br />
welcher die drei Zyklen Relevance-, Design- und Rigor Cycle unterscheidet (vgl. Abbildung<br />
1). Im Relevance Cycle werden die Anforderungen für eine Problemdomäne<br />
definiert. Er ist Startpunkt für den Design-Prozess. Gleichzeitig wird hier die Nützlichkeit<br />
der konstruierten Lösung im Rahmen der Evaluation demonstriert. Der Rigor<br />
Cycle bietet hierbei die Grundlagen in Form von wissenschaftlichen Theorien, bestehenden<br />
Artefakten und beinhaltet auch die Erfahrung und Expertisen für die bearbeitete<br />
Domäne. Neue, generalisierbare Lösungen aus dem Design Cycle fliessen anschliessend<br />
für die Wiederverwendung in die Knowledge Base. Schlussendlich dient der De-<br />
43 Vorliegende Arbeit unterscheidet zwischen Design Science (DS), Design Research (DR) und Design Science<br />
Research (DSR). Für eine Erläuterung vgl. Abschnitt 1.3.2.<br />
44 Vgl. Becker et al. 2008; Lange 2006; Wilde, Hess 2007; Winter 2008b.<br />
45 Vgl. Hevner et al. 2004, S. 76; Winter 2008b, S. 471ff.<br />
46 Vgl. Goldkuhl 2004, S. 61f.; Kuechler et al. 2007, S. 6; Simon 1996.<br />
47 Vgl. Becker et al. 2003a; Frank 1997; Heinzl et al. 2001; König et al. 1996.<br />
48 Vgl. Frank 2006.<br />
49 Vgl. Wilde, Hess 2006.<br />
50 Vgl. Becker, Pfeiffer 2006, S. 5ff.; Cao et al. 2006; Frank 2006, S. 40ff.; Hevner et al. 2004, S. 78ff.;<br />
Kuechler et al. 2007, S. 12f.; Niehaves 2006, S. 68ff.; Nunamaker Jr et al. 1991; Schelp, Winter 2008, S.<br />
80ff.; Winter 2007.<br />
51 Vgl. Becker, Pfeiffer 2006, S. 5ff.; Cao et al. 2006; Frank 2006, S. 40ff.; Hevner et al. 2004, S. 78ff.;<br />
Kuechler et al. 2007, S. 12f.; March, Smith 1995; Niehaves 2006, S. 68ff.; Nunamaker Jr et al. 1991; Schelp,<br />
Winter 2008, S. 80ff.; Winter 2007.<br />
52<br />
Vgl. Hevner 2007a; Hevner 2007b.
Einleitung 9<br />
sign Cycle als Lösungsprozess und iteriert zwischen den Kernaktivitäten der Artefaktkonstruktion<br />
und deren Evaluation 53 .<br />
Environment Design Science Knowledge Base<br />
Application Domain<br />
• People<br />
• Organizational<br />
Systems<br />
Relevance Cycle<br />
• Technical<br />
Systems<br />
• Problems &<br />
Opportunities<br />
• Requirements<br />
• Field Testing<br />
Build Design<br />
Artifacts &<br />
Processes<br />
Design<br />
Cycle<br />
Evaluate<br />
Abbildung 1: Design Science Research Cycle nach Hevner 54<br />
Vorliegende Arbeit verfolgt sowohl Erkenntnisziele, als auch Gestaltungsziele. Dabei<br />
sind die Erkenntnisziele (E 1 -E 3 ) der behavioristischen Forschung zuzuordnen, während<br />
die Gestaltungsziele (G 1 -G 4 ) durch ihren Gestaltungscharakter in der konstruktionsorientierten<br />
Forschung anzusiedeln sind. So gesehen müssen für die Beantwortung der<br />
Forschungsfragen Methoden aus beiden Strömungen verwendet werden. Dieser Methodenpluralismus<br />
veranschaulicht die zunehmende Integrativität der von behavioral<br />
IS research und IS design (science) research im Sinne von HEVNER UND MARCH: „IS<br />
research should combine the creativity and precision of design science with the empiricism<br />
and discipline of behavioral science“ 55 .<br />
Rigor Cycle<br />
• Grounding<br />
• Additions to KB<br />
Foundations<br />
• Scientific Theories &<br />
Methods<br />
• Experience<br />
& Expertise<br />
• Meta-Artifacts<br />
(Design Products &<br />
Design Processes)<br />
1.3.2 Artefakttypen in der gestaltungsorientierten Wirtschaftsinformatik<br />
Im Rahmen des Design Science Research (DSR) werden in der gestaltungsorientierten<br />
WI nach GERICKE UND WINTER 56 zwei Teildisziplinen unterschieden: Die Konstruktionsforschung<br />
(Design Science (DS)), die sich mit der Forschung an der Methodik zur<br />
Artefaktkonstruktion und -evaluation beschäftigt bzw. die grundsätzlichen Methoden<br />
und Modelle für die wissenschaftlich-stringente Entwicklung von Artefakten erforscht<br />
und die Artefaktkonstruktion (Design Research (DR)), die sich der Konstruktion, Evaluation<br />
und problemspezifischen Adaption von Artefakten widmet 57 . In Abbildung 2<br />
53<br />
54<br />
55<br />
56<br />
57<br />
Vgl. Winter 2012, S. 2.<br />
Vgl. Hevner 2007a; Hevner 2007b.<br />
Vgl. Hevner, March 2003, S. 111.<br />
Vgl. Gericke, Winter 2009a, S. 202; Winter 2008b, S. 472.<br />
Vgl. Winter 2008b, S. 472.
Design Science Research<br />
10 Einleitung<br />
wird diese Unterscheidung der Teildisziplinen verdeutlicht. Gleichzeitig wird das in<br />
vorliegender Arbeit angestrebte Artefakt entsprechend eingeordnet und hervorgehoben.<br />
Forschungsbereich Problemstellung Problemlösung<br />
Design Science<br />
Design Research<br />
Überlegungen zur<br />
Artefaktkonstruktion<br />
Überlegungen zur<br />
Artefaktevaluation<br />
Entwicklung neuer<br />
Artefakte<br />
Adaption bestehender<br />
Artefakte<br />
Konstrukt<br />
Methode<br />
Konstrukt<br />
Methode<br />
Konstrukt<br />
Methode<br />
Konstrukt<br />
Methode<br />
Modell<br />
Instanz<br />
Modell<br />
Instanz<br />
Modell<br />
(Instanz)<br />
Modell<br />
Instanz<br />
Abbildung 2: Bezugsrahmen zur Einordnung gestaltungsorientierter Forschung 58<br />
Im Rahmen der gestaltungsorientierten WI haben sich seit Jahren fünf Klassen von<br />
Artefakttypen nach MARCH UND SMITH bzw. HEVNER ET AL. 59 durchgesetzt. Sie unterscheiden<br />
Artefakte im Sinne von Forschungsergebnissen in Konstrukte, Modelle, Methoden<br />
und Instanziierungen.<br />
Konstrukte konzeptualisieren und formalisieren das gemeinsame Vokabular einer Domäne.<br />
Sie bilden die grundlegenden Bausteine der Fachsprache, damit Probleme und<br />
Lösungen innerhalb der Domäne kommuniziert und beschrieben werden können.<br />
Modelle setzten Konstrukte in Beziehung zueinander. Durch die damit verbundene<br />
Komplexitätsreduktion lässt sich ein Abbild der Realität oder eines Ausschnitts davon<br />
darstellen 60 . Modelle abstrahieren die Realität und stellen den zweckspezifischen Ausschnitt<br />
dar. Die Auswahl des Bereichs hängt in erster Linie von diesem Zweck und<br />
dem zu betrachtenden Objekt ab 61 . Somit lassen sich Sachverhalte mittels Ausblenden<br />
nicht kontextrelevanter Aspekte einfacher und anschaulicher darstellen.<br />
Methoden 62 dienen dazu, Problemlösungsprozesse zu systematisieren. Sie sind eine<br />
Abfolge von Einzelschritten zur Erreichung einer Problemlösung 63 . Sie haben nach<br />
58<br />
59<br />
60<br />
61<br />
62<br />
63<br />
Adaptiert von Mettler 2010, S. 10 auf Basis von Gericke, Winter 2009a, S. 202; Winter 2008b, S. 472.<br />
Vgl. Hevner et al. 2004, S. 78; March, Smith 1995, S. 256ff.<br />
Vgl. March, Smith 1995, S. 256.<br />
Vgl. Schmincke 1997, S. 97; Stachowiak 1973, S. 113ff.; Wand et al. 1995, S. 285.<br />
Eine detaillierte Diskussion über Methoden und deren Konstruktionsprozess, sowie situative Erweiterungen<br />
findet sich in Abschnitt 2.1.3.<br />
Vgl. March, Smith 1995, S. 257.
Einleitung 11<br />
GREIFFENBERG 64 einen anleitenden Charakter. Nach BRAUN ET AL. 65 sind konstituierende<br />
Charakteristika von Methoden deren Zielorientierung, Systematik, Prinzipienorientierung<br />
und Wiederholbarkeit. Eine Methode besteht nach GUTZWILLER bzw.<br />
WINTER 66 aus fünf Elementen: Den Aktivitäten, welche die einzelnen Aufgaben zur<br />
Erzeugung definierter Ergebnisse beschreiben und durch ein Vorgehensmodell in Reihenfolge<br />
gebracht werden; den Ergebnissen, welche die Produkte der Aktivitäten darstellen;<br />
den Techniken, mit Hilfe derer Entwurfsergebnisse erzeugt werden, den Rollen,<br />
welche für die Ausführung eines Bündels von Aktivitäten verantwortlich sind und<br />
dem Informationsmodell, welches das konzeptionelle Datenmodell der Ergebnisse beschreibt.<br />
Je nach Verständnis einer Methode sind dabei allerdings nicht alle Elemente<br />
zwingend notwendig 67 . Deren Konstruktionsprozess wird in Abschnitt 2.1.3 genauer<br />
beleuchtet.<br />
Instanziierungen sind Realisierungsformen der beschriebenen Artefakttypen in ihrer<br />
Umwelt. Sie zeigen den Nutzenbeitrag eines Artefakts sowie dessen Anwendbarkeit<br />
bezüglich ihres Problemlösungsanspruchs in der Praxis 68 bspw. durch eine prototypische<br />
Implementierung.<br />
Neben den vier beschriebenen Artefakttypen wird seit einigen Jahren immer wieder<br />
die Rolle der Theorie in der gestaltungsorientierten WI diskutiert. In den Sozialwissenschaften<br />
können verschiedene Arten von Theorien unterschieden werden. Ihnen allen<br />
gemeinsam ist, dass sie sich der Verallgemeinerung und Abstraktion von Phänomenen,<br />
Interaktionen und Kausalbeziehungen widmen 69 . FISCHER ET AL. 70 unterteilen,<br />
CHMIELEWICZ 71 folgend, theoretische Aussagen in drei Gruppen: Theoretische Aussagen<br />
als Ursache-Wirkungs-Relationen, Technologische Aussagen als Ziel-Mittel-<br />
Relationen und normative Aussagen, die sich mit dem Werte- und Zielsystem auseinandersetzen<br />
und Aussagen darüber treffen, inwieweit die Umsetzung einer technologischen<br />
Aussage zu wünschenswerten Effekten führt.<br />
Hierauf aufbauend können Theorien in der gestaltungsorientierten WI in zwei Kategorien<br />
unterteilt werden. Auf der einen Seite existieren vor allem aus der behavioristischen<br />
Forschung stammende, erklärende und voraussagende Kerntheorien (kernel the-<br />
64<br />
65<br />
66<br />
67<br />
68<br />
69<br />
70<br />
71<br />
Vgl. Greiffenberg 2003, S. 11.<br />
Vgl. Braun et al. 2005, S. 1297.<br />
Vgl. Gutzwiller 1994, S. 12ff.; Winter 2003, S. 88f.<br />
Vgl. Braun et al. 2005, S. 1297.<br />
Vgl. March, Smith 1995, S. 258.<br />
Vgl. Gregor 2006, S. 614ff.<br />
Vgl. Fischer et al. 2010, S. 384.<br />
Vgl. Chmielewicz 1994, S. 10.
12 Einleitung<br />
ories) 72 . Sie zeigen eher Ursache-Wirkungs-Relationen und bilden damit vorwiegend<br />
die Grundlage für die Konstruktion von Artefakten 73 . Zielorientierung und Ziel-Mittel-<br />
Beziehungen sind Teil der Gestaltungstheorien (design theories) auf der anderen Seite.<br />
Die Grundlage dafür bilden eher technologische und normative Aussagen 74 . Eine eindeutige<br />
Zuordnung von kernel theories auf die Ursache-Wirkungs- bzw. der design<br />
theories auf die Ziel-Mittel-Relationen lässt sich aufgrund der teilweisen Überschneidungen<br />
allerdings nicht vornehmen.<br />
Abbildung 3 zeigt nach GERICKE UND WINTER 75 die Interrelation der Artefakttypen<br />
nach HEVNER ET AL. bzw. MARCH UND SMITH 76 mit der Konzeptualisierung nach<br />
CHMIELEWICZ 77 .<br />
Generische und spezielle (singuläre)<br />
normative Aussagen<br />
(normative Aussagen)<br />
Instanziierung<br />
Ziel-Mittel-Relationen<br />
(Technologische Aussagen)<br />
Modell<br />
Methode<br />
Ursache-Wirkungs-Relationen<br />
(Theoretische Aussagen)<br />
Theorie<br />
(Wissensbasis)<br />
Zugrunde liegende Konzepte<br />
(Ontologische Grundlagen)<br />
Konstrukt/<br />
Konzept<br />
Abbildung 3: Zuordnung der DSR-Artefakttypen zur Forschungskonzeption<br />
nach CHMIELEWICZ 78 .<br />
Wie bereits erwähnt, berücksichtigen MARCH UND SMITH Theorien nicht als Artefakttypen<br />
der gestaltungsorientierten WI. Sie argumentieren, dass die Theoriekonstruktion<br />
charakteristisch für Naturwissenschaften und weniger für Gestaltungswissenschaften<br />
sei 79 . Somit verbleibt in der Gegenüberstellung eine Lücke hinsichtlich der zu Grunde<br />
liegenden Ursache-Wirkungs-Relationen, welche für eine fundierte Spezifikation von<br />
Modellen und Methoden notwendig ist. Zur Schliessung der Lücke bestehen zwei Optionen.<br />
Es kann auf bestehenden Theorien aufgebaut oder fundiertes Wissen mittels<br />
72<br />
73<br />
74<br />
75<br />
76<br />
77<br />
78<br />
79<br />
Vgl. Gregor 2006, S. 620; Walls et al. 1992, S. 42.<br />
Vgl. Walls et al. 1992, S. 42.<br />
Vgl. Walls et al. 1992, S. 42.<br />
Vgl. Gericke, Winter 2009b; Winter 2008b, S. 205.<br />
Vgl. Hevner et al. 2004; March, Smith 1995.<br />
Vgl. Chmielewicz 1994.<br />
In Anlehnung an Chmielewicz 1994; Gericke, Winter 2009b, S. 200; Winter 2008b, S. 205.<br />
Vgl. Fischer et al. 2010, S. 387.
Einleitung 13<br />
geeigneter (quantitativer) Forschungsmethoden generiert werden. Vorliegende Arbeit<br />
bedient sich beider Möglichkeiten, indem auf bestehende theoretische Konzepte aufgebaut<br />
und im Rahmen der Definition der Anforderungen und der Spezifikation von<br />
Situationen auf eine empirische Untersuchung mittels einer Umfrage zurückgegriffen<br />
wird.<br />
1.3.3 Forschungsprozess der Dissertation<br />
Im Rahmen der Konstruktion von Methoden spielt Nützlichkeit in der gestaltungsorientierten<br />
WI eine zentrale Rolle. Neben der Methoden-Konstruktion ist dabei auch die<br />
Evaluation elementar 80 . Zur besseren Strukturierung und Bewertung methodischer Aspekte<br />
schlagen PEFFERS ET AL. 81 vor, einen Forschungsprozess zur Gliederung des Ablaufs<br />
zu definieren. Hierzu existiert eine Vielzahl von Vorgehen, die jedoch alle die<br />
beiden Hauptphasen der Konstruktion und Evaluation von Artefakten in der gestaltungsorientierten<br />
WI berücksichtigen 82 . Ein bekanntes Beispiel ist der Ansatz nach<br />
MARCH UND SMITH 83 . Dieser findet zunehmende Verbreitung 84 . Gleichzeitig sind parallel<br />
dazu die oben genannten Ansätze entstanden, die die impliziten Annahmen des<br />
Ansatzes weiter detaillieren. So schlagen ROSSI UND SEIN 85 einen Forschungsprozess<br />
vor, der sich in die vier Phasen „Identify a Need“, „Build“, „Evaluate“ und „Learn &<br />
Theorize“ gliedert. Die erste Phase, „Identify a Need“, also die Identifikation der Forschungslücke<br />
und deren Begründung, besteht immer aus Geschäftsanforderungen, also<br />
Problemen im Spannungsfeld zwischen Mensch, Organisation und Technologie und<br />
stellt somit die Relevanz der Forschung für die Praxis sicher 86 . Die Phasen „Build“ und<br />
„Evaluate“ decken sich mit den entsprechenden des Ansatzes nach MARCH UND<br />
SMITH. „Learn & Theorize“, die letzte Phase im Forschungsprozess, beinhaltet die kritische<br />
Reflexion der Ergebnisse und die Ableitung von Erkenntnissen. Im Sinne einer<br />
Konsolidierung der bestehenden Forschungsprozesse schlagen PEFFERS ET AL. 87 folgende<br />
Phasen vor: „Identify Problem & Motivate“, „Define Objectives of a Solution“,<br />
„Design & Development“, „Demonstration“, „Evaluation“, „Communication“. Dieser<br />
wird aufgrund seiner Verbreitung und der Tatsache, dass es sich um einen auf den vo-<br />
80<br />
81<br />
82<br />
83<br />
84<br />
85<br />
86<br />
87<br />
Vgl. Abbildung 1, sowie Hevner et al. 2004; March, Smith 1995.<br />
Vgl. Peffers et al. 2006, S. 93; Peffers et al. 2007, S. 54.<br />
Bspw. von Hevner et al. 2004; March, Smith 1995; Peffers et al. 2007; Rossi, Sein 2003; Venable 2006.<br />
Vgl. March, Smith 1995.<br />
Vgl. Gericke 2009.<br />
Vgl. Rossi, Sein 2003.<br />
Vgl. Benbasat, Zmud 1999, S. 7ff.; Hevner et al. 2004, S. 84f.<br />
Vgl. Peffers et al. 2006, S. 86ff.
14 Einleitung<br />
rangehenden aufbauenden Prozess handelt, für diese Arbeit verwendet 88 . Allerdings<br />
werden die vorgeschlagenen Phasen teilweise zusammengefasst bzw. erweitert. Die<br />
einzelnen Phasen und deren Bezug zur vorliegenden Arbeit werden im Folgenden kurz<br />
beschrieben:<br />
Identify Problem & Motivate (1): Im Rahmen der Problemanalyse und der Motivation<br />
der Arbeit werden einerseits basierend auf einer Literaturanalyse (vgl. Kapitel 3) die<br />
Schwächen bestehender Ansätze analysiert. Auf der anderen Seite wird mittels vier<br />
Kurzfallstudien (vgl. Abschnitt 1.1) die Problematik aus Sicht der Praxis motiviert.<br />
Ausserdem werden Praxisanforderungen durch eine empirische Erhebung definiert<br />
(vgl. Abschnitt 6.1.2). So wird in der vorliegenden Arbeit das zu lösende Problem aus<br />
zwei verschiedenen Perspektiven (Literatur und Praxis) beleuchtet.<br />
Define Objectives of a Solution (2): Basierend auf den Erkenntnissen aus dem ersten<br />
Schritt (1) können so Ziele für das zu konstruierende Artefakt hergeleitet werden. Hier<br />
fliessen die Ausbaupotenziale aus der Literaturanalyse, sowie die Anforderungen aus<br />
der Praxis implizit in die Zieldefinition ein (vgl. Abschnitt 1.2).<br />
Design & Development (3): In der Entwicklungsphase (vgl. Kapitel 6) wird aufgrund<br />
der definierten Ziele und spezifizierten Anforderungen das Artefakt gebaut, welches<br />
zur Problemlösung dient. Diese Phase umfasst die Ableitung von Gestaltungsfaktoren<br />
und Projekttypen, um entsprechende Situationen für den Aufbau der situativen Methode<br />
zu erhalten. Dies geschieht in der vorliegenden Arbeit durch eine empirische Umfrage.<br />
Es fliessen dabei allerdings auch Erkenntnisse aus der Literatur und aus den<br />
Fallstudien für die Motivation ein (vgl. Kapitel 4). Schliesslich wird in dieser Phase<br />
die situative Methode an sich, basierend auf Fallstudien (vgl. Kapitel 5), den Erkenntnissen<br />
aus der Literatur (vgl. Kapitel 3) und der empirischen Umfrage (vgl. Abschnitt<br />
3.1.2), konstruiert.<br />
Demonstration & Evaluation (4): Die Phasen der Demonstration und Evaluation werden<br />
in vorliegender Arbeit zusammengefasst. Die Demonstration umfasst den Nachweis<br />
der Nützlichkeit hinsichtlich der Praxis. Dies wird durch die Einschätzung entsprechender<br />
Experten gemacht und fällt damit mit der Evaluation zusammen. Diese<br />
Phase beinhaltet methodische und inhaltliche Reflexion und den Nachweis der Nützlichkeit<br />
des situativen Artefakts (vgl. Kapitel 7).<br />
88<br />
Gegenwärtig hat sich noch kein allgemein akzeptierter Standard-Forschungsprozess für IS-Forschung herausgebildet<br />
(vgl. Peffers et al. 2006).
Application<br />
Addition<br />
Environment<br />
Relevance<br />
Rigor<br />
Einleitung 15<br />
Communication (5): Die Kommunikation der Forschungsergebnisse gegenüber der<br />
Praxis erfolgt in erster Linie im Rahmen der Problemanalyse, der Konstruktion und<br />
der Evaluation. Gegenüber der Wissenschaft wird die Kommunikation anhand der<br />
Publikation in Form dieser Arbeit sichergestellt. Hierbei wird natürlich auch das Ziel<br />
verfolgt, eine für die Praxis nützliche Publikation der Forschungsergebnisse zu erarbeiten.<br />
Reflecion (6): Im verwendeten Forschungsprozess nach PEFFERS ET AL. 89 , der sich als<br />
konsolidierter Ansatz versteht, wird auf die nicht unwesentliche Phase „Learn & Theorize“,<br />
wie bspw. durch ROSSI UND SEIN 90 vorgeschlagen, nicht eingegangen. Obwohl<br />
Theoriebildung in vorliegender Forschungsarbeit nicht im Zentrum steht und sich die<br />
verwendeten Forschungsmethoden nicht uneingeschränkt zur Theoriebildung eignen,<br />
ist eine kritische Reflexion der Forschungsergebnisse und der Erfahrungen im Forschungsprozess,<br />
sowie die Ableitung zukünftigen Forschungsbedarfs hinsichtlich der<br />
Arbeit zwingend notwendig (vgl. Kapitel 8). Aus diesem Grund wird der Forschungsprozess,<br />
BAACKE 91 folgend, um die Phase „Reflection“ erweitert. So ergibt sich aus<br />
den vorgestellten Phasen im Prozess folgende zusammenfassende Darstellung:<br />
Design Science<br />
(1) Identify Problem & Motivate<br />
(2) Define Objectives of a Solution<br />
(3) Design & Development<br />
(4) Demonstration & Evaluation<br />
Knowledge Base<br />
(5) Communication<br />
(6) Reflecion<br />
Informationsfluss logische Abhängigkeit inhaltliche Rückkopplung<br />
Abbildung 4: Forschungsprozess der Dissertation 92<br />
1.4 Adressaten und Nutzenpotenziale<br />
Das Wirken der gestaltungsorientierten WI richtet sich gleichermassen an die Wissenschaft<br />
und an die Praxis. Die Forschungsergebnisse liefern dabei einen Beitrag für bei-<br />
89<br />
90<br />
91<br />
92<br />
Vgl. Peffers et al. 2006, S. 86ff.<br />
Vgl. Rossi, Sein 2003.<br />
Vgl. Baacke 2010, S. 11.<br />
Adaptiert von Baacke 2010, S. 11, basierend auf Peffers et al. 2007, S. 86ff. und erweitert durch Rossi, Sein<br />
2003.
16 Einleitung<br />
de Gruppen 93 . Ziel der vorliegenden Forschungsarbeit ist es, beide Anspruchsgruppen,<br />
die sich mit dem Management von Projekten für AIS beschäftigen, zu adressieren. Für<br />
diese Gruppen ergeben sich, individuelle Nutzenpotenziale.<br />
Für Forschende im behandelten Themengebiet sind dies konkret folgende Aspekte:<br />
Durch die Konstruktion und Evaluation der situativen Methode zum agilen Management<br />
von Projekten für AIS, verspricht die vorliegende Forschungsarbeit<br />
einen Beitrag zur Wissensbasis („Knowledge Base“ 94 ) zu leisten und damit den<br />
wissenschaftlichen Diskurs weiter zu treiben. Dies erfolgt insbesondere durch<br />
die methodische Erfassung der Agilität in Methoden.<br />
Mit der empirischen Ermittlung von Gestaltungs- und Einflussfaktoren auf agile<br />
Projekte im Umfeld von AIS und die entsprechende Identifikation relevanter Situationen<br />
für die situative Methodengestaltung, können für die weitere Entwicklung<br />
von methodischen Unterstützungen im Management von Projekten verwendet<br />
werden.<br />
Für Vertreter aus der Praxis, die sich mit dem behandelten Themengebiet befassen,<br />
ergeben sich folgende konkrete Nutzenpotenziale:<br />
Durch die Adaption bestehender Ansätze aus Wissenschaft und Praxis und deren<br />
Ausbau zu einem methodisch fundierten Artefakt können Anwendungsunternehmen<br />
auf ein Werkzeug zurückgreifen, um ihre Projekte für AIS effizienter<br />
und effektiver zu gestalten.<br />
Der auf unterschiedliche Entwicklungssituationen adaptierbare Ansatz hilft<br />
aufgrund seiner komponentenartigen Konstruktion anstehende Projekte auf die<br />
spezifischen Begebenheiten im Unternehmen und im entsprechenden Projekt<br />
anzupassen.<br />
Die identifizierten Gestaltungsfaktoren helfen Unternehmen bei der Anwendung<br />
des methodischen Ansatzes durch eine Ausgangs- und Zielbestimmung<br />
und damit bei der situationsspezifischen Adaption.<br />
Die im Rahmen der Dissertation durchgeführten Fallstudien geben Anwendern<br />
ausserdem die Möglichkeit, einen Vergleich der eigenen Vorgehensweise mit<br />
bestehenden Ansätzen aus der Praxis durchzuführen.<br />
93<br />
94<br />
Vgl. March, Smith 1995; Straub et al. 1994, S. 23; WKWI 1994, S. 81.<br />
Vgl. March, Smith 1995 sowie Abschnitt 1.3.1.
Einleitung 17<br />
1.5 Vorgehen und Struktur der Forschungsarbeit<br />
Vorliegende Forschungsarbeit ist in acht Kapitel gegliedert, die zur Erhöhung der<br />
Übersichtlichkeit thematisch in fünf Teile zusammengefasst werden. Deren Inhalt wird<br />
im Folgenden kurz umrissen und in Abbildung 5 grafisch dargestellt.<br />
Diesem einführenden Kapitel (Kapitel 1), das unter anderem die Problemstellung, die<br />
Forschungsfrage und die daraus abgeleiteten Erkenntnis- und Gestaltungsziele sowie<br />
die verwendete Forschungsmethodik und den Forschungsprozess erläutert, folgen im<br />
zweiten Teil die Ausgangsbedingungen für die Methodenkonstruktion. Dabei werden<br />
insbesondere die konzeptionellen Grundlagen (Kapitel 2), auf denen die Arbeit aufbaut,<br />
sowie eine Analyse des State-of-the-Art in Form eines Vergleichs bestehender<br />
Ansätze und Forschungsarbeiten (Kapitel 3) vorgestellt.<br />
Der dritte Teil der Arbeit umfasst die Konstruktion der situativen Methode zum agilen<br />
<strong>Projektmanagement</strong> für AIS. Hierzu werden in Kapitel 4 die Grundlagen für die Methodenentwicklung<br />
in Form der empirischen Ableitung von Gestaltungsfaktoren und<br />
Realisierungsformen agiler AIS-<strong>Projektmanagement</strong>-Ansätze in der Praxis abgeleitet.<br />
Hiermit wird dem situativen Charakter des Ansatzes Rechnung getragen. Im Anschluss<br />
daran werden ergänzend zu den quantitativ-empirisch ermittelten Ergebnissen<br />
vier Fallstudien vorgestellt (Kapitel 5). Mithilfe dieser können in qualitativempirischer<br />
Form zusätzliche Erkenntnisse für die Methodenkonstruktion gewonnen<br />
werden. Kapitel 6 widmet sich der eigentlichen Konstruktion der situativen Methode<br />
zum agilen <strong>Projektmanagement</strong> für AIS. Dazu wird in einem ersten Schritt der Ausgangspunkt<br />
in Form von Annahmen zur zugrundeliegenden Architektur und Organisationsform<br />
festgelegt. Anschliessend werden die inhaltlichen und methodischen Anforderungen<br />
an den Ansatz definiert. Im Rahmen der Konstruktion des methodischen Ansatzes<br />
wird zuerst dessen Modularisierungskonzept zur situationsspezifischen Adaption<br />
vorgestellt und basierend auf den Fallstudien die einzelnen Methodenfragmente,<br />
sowie das sich daraus ergebende Vorgehensmodell, abgeleitet. Für jedes Methodenfragment<br />
wird anschliessend zunächst dessen Aussensicht im Sinne eines Blackbox-<br />
Ansatzes grob skizziert und danach in der Innensicht detaillierter und weiterführender<br />
spezifiziert. Das Kapitel schliesst mit der Darstellung der im Sinne des situativen Methoden-Engineerings<br />
neben dem Vorgehensmodell noch fehlenden Beschreibungsmodelle,<br />
namentlich dem Dokumentations-, Rollen- und Informationsmodell.
Kapitel 8<br />
Zusammenfassung<br />
und<br />
Ausblick<br />
Kapitel 7<br />
Evaluation<br />
der<br />
situativen<br />
Methode<br />
Kapitel 6<br />
Entwicklung des<br />
methodischen<br />
Ansatzes<br />
Kapitel 5<br />
Fallstudien zur<br />
Methodenentwicklung<br />
Kapitel 4<br />
Grundlagen für<br />
die Methodenentwicklung<br />
Kapitel 3<br />
Stand der<br />
Forschung<br />
und<br />
verwandte<br />
Arbeiten<br />
Kapitel 2<br />
Konzeptionelle<br />
Grundlagen<br />
Kapitel 1<br />
Einleitung<br />
18 Einleitung<br />
TEIL I: EINFÜHRUNG<br />
Ausgangslage und<br />
Problemstellung<br />
Forschungsfragen und<br />
Zielsetzungen<br />
Forschungsmethodik und<br />
-prozess<br />
Adressaten und<br />
Nutzenpotenziale<br />
Vorgehen und Struktur der<br />
Forschungsarbeit<br />
TEIL II: AUSGANGSBEDINGUNGEN<br />
St. Galler Ansatz des Business Engineerings<br />
Analytische <strong>Informationssysteme</strong><br />
Projekte und deren Abwicklung<br />
Agile Entwicklung<br />
Auswahl und<br />
Bewertungskriterien für<br />
verwandte Arbeiten<br />
Vorstellung ausgewählter<br />
Publikationen<br />
Zusammenfassende<br />
Bewertung der untersuchten<br />
Publikationen<br />
TEIL III: METHODENENTWICKLUNG<br />
Gestaltungsfaktoren für agiles AIS-<br />
<strong>Projektmanagement</strong><br />
Realisierungsformen für agiles AIS-<br />
<strong>Projektmanagement</strong><br />
Ableitung von Projekttypen und Kontexttypen<br />
Entwicklungssituationen für einen methodischen<br />
Ansatz<br />
Auswahl der Fallstudien<br />
Fallstudie A: BLUEFORTE GmbH<br />
Fallstudie B: BMW AG<br />
Fallstudie C: Steria Mummert Consulting AG<br />
Fallstudie D: Schweizerische Grossbank<br />
Zusammenfassende Betrachtung der<br />
untersuchten Fallstudien<br />
Anforderungen an den methodischen Ansatz<br />
Ableitung eines methodischen Ansatzes<br />
Spezifikation der Methodenfragmente für die<br />
situative Methode<br />
Resultierende Beschreibungsmodelle der<br />
situativen Methode<br />
TEIL IV: EVALUATION<br />
Evaluation in der<br />
gestaltungsorientierten WI<br />
Analytische Evaluation<br />
Empirische Evaluation<br />
TEIL V: SCHLUSS<br />
Zusammenfassung der<br />
Forschungsarbeit<br />
Kritische Würdigung<br />
Ausblick und Ansatzpunkte für<br />
weiteren Forschungsbedarf<br />
Abbildung 5: Struktur und Aufbau der Forschungsarbeit
Einleitung 19<br />
Der vierte Teil der Arbeit widmet sich der Evaluation des situativen Methodenentwurfs<br />
(Kapitel 7) 95 . Diese dient dem Nachweis der korrekten Herleitung und Entwicklung<br />
der situativen Methode auf Basis zuvor aufgestellter Anforderungen (<strong>analytische</strong><br />
Evaluation), sowie dem Nachweis der Praxistauglichkeit und Nützlichkeit des Ansatzes<br />
im Rahmen einer Fallstudie (empirische Evaluation).<br />
Die Forschungsarbeit schliesst im fünften Teil mit einer Zusammenfassung und kritischer<br />
Würdigung der Ergebnisse, sowie einem Ausblick auf potenziellen zukünftigen<br />
Forschungs- und Ausbaubedarf.<br />
95<br />
Die Begriffe „Methodenentwurf“ und „Methodenvorschlag“ werden in vorliegender Arbeit synonym verwendet.<br />
Beide beziehen sich auf die in der Arbeit entwickelte situative Methode.
20 Konzeptionelle Grundlagen<br />
2 Konzeptionelle Grundlagen<br />
In den folgenden Abschnitten werden die begrifflichen und konzeptionellen Grundlagen<br />
für die Forschungsarbeit gelegt. Sie bilden die Basis für das Verständnis und bieten<br />
zugleich das Rahmenwerk, in dem die Arbeit eingebettet ist. Abschnitt 2.1 beleuchtet<br />
den St. Galler Ansatz des Business Engineering und dabei insbesondere das<br />
(situative) Methoden-Engineering, welches den methodischen Kern für die Konstruktion<br />
einer situativen Methode bietet. Abschnitt 2.2 führt die Konzepte der AIS und der<br />
integrierten Informationslogistik (IIL) nach dem Verständnis am IWI-HSG ein. In Abschnitt<br />
2.3 wird auf Projekte und deren Abwicklung eingegangen. Dabei werden insbesondere<br />
unterschiedliche Herangehensweisen bei Projekten im Allgemeinen und IT-<br />
Projekten im Speziellen beleuchtet. Abschliessend wird in Abschnitt 2.4 die Grundidee<br />
der agilen Entwicklung eingeführt. Der Fokus des Abschnitts liegt auf der Beleuchtung<br />
der grundlegenden Wirkungsweise agiler Methoden im ersten Teil und der Vorstellung<br />
ausgewählter Ansätze im zweiten Teil. Der dritte Teil des Abschnitts widmet sich einer<br />
zusammenfassenden Betrachtung der agilen Entwicklung und den Konsequenzen<br />
für die vorliegende Arbeit.<br />
2.1 St. Galler Ansatz des Business Engineerings<br />
Der St. Galler Ansatz des Business Engineerings (BE) bildet den grundlegenden Forschungsrahmen<br />
der Dissertation. Das BE bezeichnet die „methoden- und modellbasierte<br />
Konstruktionslehre für Unternehmen des Informationszeitalters“ 96 . Es bietet einen<br />
ganzheitlichen Ansatz für das Veränderungsmanagement und integriert, im Gegensatz<br />
zu anderen Ansätzen zur Veränderung von Organisationen, die nur einzelne Aspekte<br />
behandeln, verschiedene Modellsichten und Architekturbereiche 97 . Der Einsatz eines<br />
solchen ganzheitlichen Ansatzes ist im komplexen Umfeld des Managements von Projekten<br />
für AIS notwendig. Veränderungen können dabei radikal oder inkrementell<br />
sein 98 . Als Element des BE sind das Methoden-Engineering (ME) und dessen Weiterentwicklung<br />
zum SME von besonderer Relevanz für die Arbeit. Es sichert das ingenieurmässige<br />
Vorgehen in Veränderungsprojekten, wie sie die vorliegende Arbeit behandelt.<br />
96<br />
97<br />
98<br />
Vgl. Österle, Winter 2003, S. 7.<br />
Vgl. Österle, Winter 2003, S. 3.<br />
Vgl. Rüegg-Stürm 2003; Staehle 1999, S. 901.
Konzeptionelle Grundlagen 21<br />
2.1.1 Run the Business vs. Change the Business<br />
Der St. Galler Ansatz des BE ordnet sich in das Neue St. Galler Managementmodell<br />
(NSGMM) 99 ein. Dieses versteht Organisationen als komplexe soziale Systeme, die<br />
aus verschiedenen Blickwinkeln verstanden und betrachtet werden müssen 100 . Das<br />
NSGMM unterscheidet dabei zwischen zwei Blickwinkeln. Der eine betrifft die Unternehmensumwelt<br />
wie bspw. Anspruchsgruppen oder unterschiedliche Umwelteinflüsse<br />
wie bspw. die technologische Umwelt oder gesellschaftliche Aspekte. Der andere<br />
Blickwinkel betrifft die Unternehmung an sich mit ihrer Kultur, unterschiedlichen<br />
Arten von Prozessen, Ressourcen, der Strategie oder aber wie sich die Unternehmung<br />
weiterentwickelt. Für das BE sind diese Entwicklungsmodi von zentraler Bedeutung.<br />
Dabei wird zwischen „Erneuerung“ und „Optimierung“ unterschieden 101 . Das bedeutet,<br />
dass die Gestaltung von Unternehmen oder deren Teile radikal (mit eher revolutionärem<br />
Charakter) oder inkrementell (mit eher evolutionärem Charakter) weitergetrieben<br />
werden kann 102 .<br />
Radikale Veränderungen streben eine umfassende Neugestaltung an und berücksichtigen<br />
dabei aktuelle Strukturen bewusst nicht 103 . Der Weg vom Ist-Zustand zum Soll-<br />
Zustand wird in einem Schritt vollzogen. Diese Art der Veränderung ist entsprechend<br />
flexibel, jedoch mit relativ hohem Risiko verbunden. Im Rahmen grosser Schritte können<br />
unvorhergesehene Änderungen der Rahmenbedingungen gravierende Folgen haben.<br />
Gleichzeitig tendieren Menschen dazu, kleinere Veränderungen besser aufzunehmen.<br />
Radikale Veränderungen haben typischerweise Projektcharakter und werden ausserhalb<br />
des laufenden Betriebs in Unternehmen mit fixiertem Anfang und Ende durchgeführt.<br />
Sie sind unter dem Begriff „Change the Business“ subsumierbar.<br />
Im Rahmen inkrementeller Veränderungen auf der anderen Seite, wird diese in kleineren<br />
Schritten vollzogen und dabei der Ist-Zustand im Unternehmen berücksichtigt 104 .<br />
Das damit verbundene Risiko eines Scheiterns ist somit deutlich geringer und die Veränderung<br />
wird durch die Mitarbeitenden tendenziell besser aufgenommen. Allerdings<br />
können so weniger grosse Vorhaben umgesetzt werden. Inkrementelle Veränderungen<br />
99<br />
Für Details zum neuen St. Galler Managementmodell und dessen Blickwinkeln wird auf Dubs et al. 2004<br />
verwiesen.<br />
100 Vgl. Winter 2010b, S. 1.<br />
101 Vgl. Rüegg-Stürm 2003.<br />
102 Vgl. Winter 2010b, S. 1.<br />
103 Vgl. Hammer, Champy 1993.<br />
104 Vgl. Davenport, Short 1990, S. 14.
lokal<br />
Reichweite der Veränderung<br />
übergreifend<br />
22 Konzeptionelle Grundlagen<br />
werden häufig innerhalb des laufenden Betriebs in Unternehmen vorgenommen und<br />
sind eher kontinuierlich. Sie sind deshalb dem „Run the Business“ zuzuordnen.<br />
Eine Abgrenzung zwischen radikaler und inkrementeller Veränderung ist nicht immer<br />
klar vorzunehmen. Je nach Reichweite und Detailniveau einer Veränderung, kann diese<br />
von einigen Beteiligten bzw. Betroffenen als inkrementell wahrgenommen werden<br />
während andere diese als radikal auffassen. Ein übergreifendes Veränderungsprojekt<br />
hat bspw. für die einen Stakeholder gravierende Auswirkungen, während auf lokaler<br />
Ebene andere nur wenig betroffen sind. Aus diesem Grund muss eine methodische<br />
Unterstützung von Veränderung auch Mischformen abdecken. Abbildung 6 fasst die<br />
Arten von Veränderung und deren Reichweite zusammen. Die projektgetriebenen Veränderungen,<br />
die dem „Change the Business“ zuzuordnen sind, liegen im Fokus des<br />
BE 105 .<br />
Projektgetriebene<br />
Umsetzung<br />
Projektgetriebene<br />
Umsetzung<br />
Kontinuierliche<br />
Umsetzung<br />
Projektgetriebene<br />
Umsetzung<br />
„Change the<br />
Business“<br />
„Run the<br />
Business“<br />
inkrementell<br />
Art der Veränderung<br />
radikal<br />
Abbildung 6: Projektgetriebene vs. kontinuierliche Veränderung 106<br />
Auslöser für radikale Veränderungen sind vielfältig. Neben bspw. regulatorischen Anpassungen<br />
oder aus marktlichen Gründen wie z.B. veränderte Konkurrenzsituation,<br />
sich neu erschliessende Märkte oder die Optimierung von Geschäftsabläufen werden<br />
Technologieinnovationen insbesondere im Bereich der Informations- und Kommunikationstechnologie<br />
(IKT) 107 als die hauptsächlichen Enabler für radikale Veränderungen<br />
genannt 108 . Die nach wie vor rasante Entwicklung im IT-Bereich und die damit<br />
verbundenen Möglichkeiten bspw. durch Automatisierung von Abläufen, Analysemöglichkeiten<br />
durch aggregierte, historische Daten oder Geschwindigkeitszuwachs<br />
durch höhere Leistungsfähigkeit der Systeme, veranschaulichen die zentrale Rolle der<br />
105 Vgl. Österle, Winter 2003, S. 13.<br />
106 In Anlehnung an Baacke 2010, S. 22.<br />
107 IKT und IT wird in der vorliegenden Arbeit synonym verwendet.<br />
108 Vgl. Österle, Winter 2003, S. 11; Winter 2010b, S. 2.
Konzeptionelle Grundlagen 23<br />
IT für das Auslösen von Veränderungen in Unternehmen. Veränderungen, bspw. durch<br />
IT-Innovation, sind immer mehrdimensional, d.h. betreffen nicht nur die auslösende<br />
Dimension. Sie sind verknüpft mit anderen technologischen oder sozioökonomischen<br />
Dimensionen. Es handelt sich also um „komplexe Mensch-Maschine-Systeme“ 109 und<br />
betrifft sowohl technische, fachliche als auch menschliche bzw. weiche Faktoren, sog.<br />
„Work Systems“ 110 . In der deutschsprachigen WI hat sich der Begriff „Informationssystem“<br />
für die Bezeichnung von Systemen aus Menschen und Maschinen, die Informationen<br />
erzeugen, verarbeiten und/oder nutzen und zueinander in Kommunikationsbeziehungen<br />
stehen, etabliert 111 . Vorliegende Arbeit orientiert sich an diesem breiten,<br />
soziotechnischen Verständnis des IS-Begriffs 112 .<br />
2.1.2 „Ingenieurmässige“ Unterstützung projektgetriebener Veränderung<br />
Um Veränderungen umsetzen zu können, die dem „Change the Business“ zuzuordnen<br />
sind, d.h. projektgetriebene Umsetzungen, die entweder radikal oder übergreifend inkrementell<br />
sind (vgl. Abbildung 6), muss das entsprechende Vorgehen methodisch<br />
adäquat unterstützt werden. Eine systematische Gestaltung des Prozesses durch „ingenieurmässige“<br />
Vorgehensweisen mittels Modellen und Methoden hilft, die Komplexität<br />
einer solchen Veränderung in seinen verschiedenen Dimensionen beherrschbar zu<br />
machen 113 . Hierdurch kann Transparenz geschaffen werden und durch die erleichterte<br />
Kommunikation wird Arbeitsteilung ermöglicht. Der Veränderungsprozess wird so<br />
nachvollzieh- und wiederholbar 114 . Der St. Galler Ansatz des BE nimmt diese Aspekte<br />
auf und stellt Konzepte sowie Modelle und Methoden aus der Betriebswirtschaft, dem<br />
Change Management, Systems Engineering und Innovationsmanagement zur Verfügung,<br />
die diesen Prozess unterstützen. Es bezeichnet sich als die „methoden- und modellbasierte<br />
Konstruktionslehre für Unternehmen im Informationszeitalter“ 115 und ist<br />
dabei von stark interdisziplinärem Charakter. Nur so kann eine ganzheitliche und integrierte<br />
Betrachtung sichergestellt werden. Es ist bspw. wenig sinnvoll, eine IT-<br />
Innovation auf Software- und Infrastrukturebene zu implementieren ohne entsprechende<br />
Berücksichtigung organisatorischer, kultureller und strategischer Aspekte.<br />
109 Vgl. Österle, Winter 2003, S. 10.<br />
110 Vgl. Alter 2003, S. 367f.<br />
111 Vgl. Balzert 2000, S. 25; Bucher 2009, S. 14.<br />
112 Für Details zur Unterscheidung der IS-Begriffe in der deutschsprachigen WI wird auf Wall 1996 verwiesen.<br />
113 Vgl. Österle, Winter 2003, S. 7.<br />
114 Vgl. Winter 2003, S. 88; Winter 2007, S. 403.<br />
115 Vgl. Österle, Winter 2003, S. 7; Winter 2010b, S. 3.
Womit?<br />
Wie?<br />
Was?<br />
24 Konzeptionelle Grundlagen<br />
Im BE werden zwei wesentliche Aspekte von Veränderungsprozessen, in der fachlichem<br />
und der politisch-kulturellen Dimension, unterschieden:<br />
Die politisch-kulturelle Dimension steht als Ergänzung zu den fachlichen Modellierungsebenen<br />
und berücksichtigt „weiche“ Faktoren wie bspw. die Unternehmenskultur,<br />
politische Strukturen in der Unternehmung, Führungsverhalten und Machtstrukturen<br />
116 .<br />
Hinsichtlich der fachlichen Dimension werden zum Zweck der Komplexitätsreduktion<br />
mehrere, hierarchisch gegliederte Modellierungsebenen unterschieden. Durch die Abhängigkeiten<br />
der Ebenen untereinander und der damit verbundenen Verknüpfung, wird<br />
eine gewisse Konsistenz für das Gesamtmodell sicher gestellt 117 .<br />
Strategie<br />
Beschreibung der grundlegenden strategischen<br />
Ausrichtung und Rolle in einer vernetzten<br />
Geschäftsarchitektur.<br />
Politischekultureller<br />
Rahmen<br />
Organisation<br />
Alignment<br />
Software<br />
Definition der Aufbauorganisation und Prozesse zur<br />
Umsetzung der Strategie; Spezifikation von<br />
Informationsobjekten und -flüssen<br />
Abstraktes Bindeglied zwischen Organisations- und<br />
Softwareebene; Dient der Entkopplung fachlicher und<br />
organisatorischer Aspekte<br />
Beschreibung wieder verwendbarer Softwarekomponenten<br />
und Datenstrukturen die den fachlichen<br />
Funktionalitäten zur Verfügung gestellt werden.<br />
Beschreibung<br />
“weicher”<br />
Faktoren, die<br />
berücksichtigt<br />
werden müssen<br />
(bspw.<br />
Führung,<br />
Verhalten,<br />
Macht,<br />
Anreizsysteme)<br />
Infrastruktur<br />
Beschreibung der technischen Komponenten, die<br />
zum Betrieb der Softwarekomponenten erforderlich<br />
sind.<br />
Abbildung 7: Gestaltungsebenen des St. Galler Ansatz des Business Engineering 118<br />
Auf jeder der in Abbildung 7 dargestellten Ebenen werden Methoden, Modelle und<br />
Werkzeuge eingesetzt, die bei der Erreichung des Soll-Zustands (Gestaltungsziel) Unterstützung<br />
bieten. Dabei sind die Modelle sowohl innerhalb der Ebenen, als auch ebenenübergreifend<br />
über ihre Entitätstypen integriert.<br />
Neben dieser Modellsicht des BE beschäftigt sich die Methodensicht mit der Frage,<br />
wie eine Veränderung im Rahmen des „Change the Business“ gestaltet werden soll.<br />
Auch hier steht das strukturierte, nachvollziehbare und wiederholbare ingenieurmässige<br />
Vorgehen im Zentrum. Das Gestaltungsziel der Konstruktion einer situativen Methode<br />
in der vorliegenden Arbeit bedarf einer genaueren Betrachtung der systematischen<br />
Entwicklung derselben.<br />
116 Vgl. Österle, Winter 2003, S. 11.<br />
117 Vgl. Winter 2003, S. 91f.<br />
118 In Anlehnung an Baacke 2010, S. 23; Winter 2003.
Konzeptionelle Grundlagen 25<br />
2.1.3 Situatives Methoden-Engineering<br />
Im Rahmen der vorliegenden Arbeit wird eine situative Methode zum agilen Management<br />
von AIS-Projekten entwickelt. Aus diesem Grund ist nicht nur die Methode an<br />
sich zu betrachten, sondern auch deren systematische, ingenieurmässige Entwicklung.<br />
Das ME beschäftigt sich nach HEYM 119 mit der „[…] Entwicklung, Modifikation und<br />
Anpassung von Methoden durch die Beschreibung der Methodenkomponenten und<br />
ihrer Beziehungen“. Das SME erweitert den klassischen Ansatz um situative (an spezifische<br />
Situationen anpassbare) Aspekte 120 . Die Grundlage für vorliegende Forschungsarbeit<br />
bildet demnach das SME. Die einzelnen Konzepte werden im Folgenden detailliert<br />
erläutert.<br />
Der Ursprung der Methodenkonstruktion, wie sie das BE vorschlägt, liegt in der „Entwicklung,<br />
Anpassung und Modifikation von Software-Entwicklungsmethoden“ 121 .<br />
Nach und nach wurde das Begriffsverständnis jedoch von einem rein technischen zu<br />
einem integrierten erweitert. Diese Erweiterung gründet darauf, dass Unternehmen<br />
sozio-technische Systeme darstellen und dass eine Entwicklung eines IS nicht ausschliesslich<br />
technische Aspekte behandeln kann 122 . Die Weiterentwicklung des ME<br />
ging sogar so weit, dass auch Veränderungsprojekte, die nicht das Ziel verfolgen<br />
Software zu entwickeln, durch diesen Ansatz abgedeckt wurden 123 .<br />
Für die vorliegende Arbeit wird die Definition des Begriffs „Methoden-Engineering“<br />
nach BUCHER 124 adaptiert und erweitert. Diese schliesst durch ihren generischen Charakter<br />
auch das im späteren Verlauf des Abschnitts erweiterte SME mit ein:<br />
Methoden-Engineering<br />
Methoden-Engineering bezeichnet als Sammelbegriff diejenigen konstruktionsorientierten<br />
Ansätze, die sich mit der Entwicklung und Anpassung von Methoden beschäftigen.<br />
Ziel des Methoden-Engineerings ist die Bereitstellung detailliert beschriebener<br />
und evaluierter, d.h. funktionsfähiger und nützlicher Vorgehens- und<br />
Handlungsanweisungen, die Unternehmen beim systematischen, strukturierten und<br />
ergebnisgeleiteten Entwurf von <strong>Informationssysteme</strong>n, sowie damit verbundener<br />
Komponenten wie bspw. entsprechende Managementansätze, anleiten und unterstützen.<br />
119 Vgl. Heym 1993, S. 61, sowie auch Brinkkemper 1996; Gutzwiller 1994.<br />
120 Vgl. Bucher et al. 2007.<br />
121 Vgl. Heym 1993, S. 5.<br />
122 Vgl. Truex, Avison 2003, S. 509.<br />
123 Vgl. bspw. Baumöl 2005.<br />
124 Vgl. Bucher 2009, S. 17.
26 Konzeptionelle Grundlagen<br />
Nach BUCHER 125 bestehen in der wissenschaftlichen Literatur zwei unterschiedliche<br />
Sichten auf den Begriff „Methode“ – eine inhaltliche und eine formale. Inhaltlich gesehen<br />
stellen Methoden Anleitungen bzw. Handlungsempfehlungen dar, um ein bestimmtes<br />
Ziel oder Ergebnis zu erreichen bzw. zu gestalten. Hierzu konstituiert sich<br />
eine Methode aus Entwurfsaktivitäten und Techniken zur Erstellung von Entwurfsergebnissen,<br />
einem Informationsmodell, welches das Entwurfsergebnis näher beschreibt,<br />
und Rollen, die für die Ausführung der Aktivitäten verantwortlich sind 126 . Eine Methode<br />
beinhaltet demnach eine Produkt- und eine Prozesssicht 127 . Die andere Sichtweise<br />
auf Methoden ist die formale. Hierbei werden diese als Aggregat derer Bestandteile<br />
betrachtet 128 . Deren Bestandteile werden in der Literatur uneinheitlich beschrieben. Sie<br />
werden als „Method Components“, „Method Fragments“ oder „Method Chunks“ bezeichnet.<br />
In der vorliegenden Arbeit wird auf BUCHER 129 Bezug genommen, der den<br />
Begriff „Methodenfragment“ als formalen Bestandteil einer Methode geprägt hat. Darunter<br />
ist die „Kombination eines Entwurfsergebnisses und einer oder mehrerer Entwurfsaktivitäten,<br />
einer oder mehrerer Techniken sowie einer oder mehrere Rollen“ 130<br />
zu verstehen 131 .<br />
Die Anwendung von Methoden in der Praxis hat in der Vergangenheit deutlich gemacht,<br />
dass diese aufgrund ihres stark generischen Charakters oftmals an die besonderen<br />
Ausprägungen eines Projektes angepasst werden müssen 132 . Diese Anpassbarkeit<br />
an Situationen führte zu einer Weiterentwicklung des ME zum SME 133 . Die Identifikation<br />
situativer Einflussfaktoren, die auf die Konstruktion der Methode und deren Anwendung<br />
wirken, ist hierbei von besonderer Bedeutung 134 . Diese werden in der Literatur<br />
gegenwärtig nicht einheitlich behandelt. Bereits in den 1990er Jahren, kurz nach-<br />
125 Vgl. Bucher 2009, S. 17.<br />
126 Vgl. Braun et al. 2005, S. 1297; Gutzwiller 1994, S. 12ff.; Heym 1993, S. 111ff.<br />
127 Vgl. bspw. Avison, Fitzgerald 1988, S. 8; Brinkkemper 1996, S. 275f.; Goldkuhl et al. 1997, S. 4;<br />
Greiffenberg 2003, S. 956; Harmsen 1997, S. 11; Heym 1993, S. 132f.; Karlsson, Ågerfalk 2004, S. 621;<br />
Karlsson, Wistrand 2006, S. 82; Kronlöf et al. 1993, S. 7f.; Nuseibeh 1994, S. 20; Odell 1996, S. 1; Olle et<br />
al. 1988, S. 1f.<br />
128 Vgl. bspw. Goldkuhl et al. 1997, S. 4f.; Greiffenberg 2003, S. 957; Harmsen 1997, S. 52f.; Karlsson,<br />
Ågerfalk 2004, S. 619; Karlsson, Ågerfalk 2005, S. 35; Karlsson, Wistrand 2006, S. 85; Kumar, Welke<br />
1992, S. 263f.; Marttiin et al. 1996, S. 68; Nuseibeh et al. 1996, S. 269; Punter, Lemmen 1996, S. 295;<br />
Ralyté, Rolland 2001a, S. 20; Saeki 2003, S. 8; Wistrand, Karlsson 2004, S. 192.<br />
129 Vgl. Bucher 2009, S. 49ff.<br />
130 Vgl. Bucher 2009, S. 52.<br />
131 Vgl. hierzu auch die detaillierteren Ausführungen in Abschnitt 6.2.1.<br />
132 Vgl. Winter, Schelp 2006, S. 1562.<br />
133 Vgl. Brinkkemper 1996, S. 277ff.; Bucher, Winter 2009, S. 18ff.; Harmsen et al. 1994, S. 175ff.; Kumar,<br />
Welke 1992, S. 258ff.; van Slooten, Hodes 1996, S. 32ff.<br />
134 Vgl. Winter, Schelp 2006, S. 1562.
Situative Erweiterung des Metamodells<br />
Methoden-Engineering Metamodell<br />
Konzeptionelle Grundlagen 27<br />
dem GUTZWILLER 135 die fünf grundlegenden Elemente einer Methode in einem Metamodell<br />
festgehalten hat, entbrannte die Diskussion nach situativ anpassbaren Methoden.<br />
Diese Ansätze des „situativen Methoden-Engineering“ 136 fand jedoch keine Berücksichtigung<br />
im Metamodell nach GUTZWILLER. Dem Umstand, dass Methoden an<br />
die situationsspezifischen Charakteristika des jeweiligen Veränderungsprojekts angepasst<br />
werden müssen und dies entsprechenden Eingang in das Methoden-Engineering<br />
Metamodell finden muss, haben BUCHER ET AL. Rechnung getragen 137 .<br />
ist Teil von<br />
Informationsmodell<br />
stellt problemorientierte<br />
Sicht dar<br />
erzeugt/<br />
verwendet<br />
ist Teil von<br />
Entwurfsergebnis<br />
Vorgänger/<br />
Nachfolger<br />
unterstützt<br />
Erstellung<br />
Rolle<br />
ist beteiligt an<br />
Entwurfsaktivität<br />
Technik<br />
ist Teil von<br />
Projekttyp<br />
ist Teil von<br />
ist Teil von<br />
Methodenfragment<br />
Entwicklungssituation<br />
beeinflusst Anwendbarkeit<br />
Kontexttyp<br />
Adaptionsmechanismus<br />
Abbildung 8: Erweitertes Metamodell des Methoden-Engineerings 138<br />
Abbildung 8 zeigt im oberen Teil das klassische Metamodell nach GUTZWILLER 139 .<br />
Hierbei steht das Entwurfsergebnis im Zentrum, mit dessen Hilfe eine problemorientierte<br />
Partialsicht auf das Informationsmodell erreicht werden kann. Die Gesamtheit<br />
aller Entwurfsergebnisse einer Methode wird als Dokumentationsmodell bezeichnet.<br />
Das Informationsmodell beschreibt die Gestaltungsobjekte einer Methode und deren<br />
Beziehungen. Es repräsentiert den Lösungs- und Gestaltungsraum, in dem eine Methode<br />
angewandt wird. Die Entwurfsergebnisse sind das Resultat, aber auch die<br />
Grundlage für die Entwurfsaktivitäten. Diese können hierarchisch strukturiert und in<br />
eine Ablauffolge gebracht werden. Das Vorgehensmodell ist die Gesamtheit aller<br />
Entwurfsaktivitäten in ihrer entsprechenden Reihenfolge. Jeder Entwurfsaktivität ist<br />
135 Vgl. Gutzwiller 1994, S. 13.<br />
136 Vgl. bspw. Harmsen et al. 1994, S. 172; Kumar, Welke 1992, S. 262; Rolland, Prakash 1996, S. 191; ter<br />
Hofstede, Verhoef 1997, S. 402.<br />
137 Vgl. Bucher et al. 2007, S. 40f.<br />
138 In Anlehnung an Bucher 2009, S. 18; Bucher et al. 2007, S. 41.<br />
139 Vgl. Gutzwiller 1994, S. 12ff.
28 Konzeptionelle Grundlagen<br />
dabei mindestens eine Rolle zugeordnet, die einen Träger und eine Partizipationsform<br />
repräsentieren. Die Erstellung von Entwurfsergebnissen ist unterstützt durch Techniken,<br />
wie bspw. Anleitungen oder Handlungsanweisungen.<br />
Der untere Teil in Abbildung 8 beschreibt die situative Erweiterung des ME-<br />
Metamodells. Bislang wurde der situative Aspekt in der wissenschaftlichen Literatur<br />
nicht einheitlich definiert. Im Folgenden wird daher auf den Ansatz nach BUCHER ET<br />
AL. Bezug genommen 140 . Eine Entwicklungssituation besteht diesem Ansatz entsprechend<br />
aus Kontext- und Projekttyp. Während der Kontexttyp diejenigen Elemente des<br />
IS und seiner Umwelt enthält, die im Rahmen des Projekts nicht veränderbar sind, dieses<br />
aber dennoch beeinflussen können, umfasst der Projekttyp die Teile, die im Rahmen<br />
des Projekts geändert werden können und Einfluss darauf ausüben. Sowohl Kontext-<br />
als auch Projekttyp sind hierarchisch strukturiert und lassen sich in einzelne Beschreibungsfaktoren<br />
verfeinern. Sie beeinflussen die Anwendbarkeit von Methodenfragmenten.<br />
Mittels geeigneter Adaptionsmechanismen wie Aggregation oder Konfiguration<br />
werden Methodenfragmente unter Berücksichtigung der entsprechenden Situation<br />
zu einer situativen Methode zusammengesetzt.<br />
2.2 Analytische <strong>Informationssysteme</strong><br />
<strong>Informationssysteme</strong> als sozio-technische Systeme mit menschlichen und maschinellen<br />
Komponenten werden sowohl in der deutschsprachigen WI als auch in der angelsächsischen<br />
Information Systems Research (ISR) in zwei Klassen unterteilt 141 .<br />
Operative, bzw. transaktionale IS (TIS) unterstützen die Ausführung von Aktivitäten<br />
innerhalb eines Geschäftsprozesses. Hierzu gehört bspw. die Erfassung eines Auftrags<br />
und dessen Abwicklung. AIS auf der anderen Seite fokussieren auf die Unterstützung<br />
dispositiver Tätigkeiten im Unternehmen 142 . Die Basis dafür bilden die Integration und<br />
adäquate Aufbereitung der Daten aus verschiedenen operativen Quellen.<br />
Das Nutzenspektrum <strong>analytische</strong>r IS ist sehr breit. Es werden auf der einen Seite Tätigkeiten<br />
unterstützt, die über die Unternehmenssteuerung mittels aggregierter und historisierter<br />
Daten oder weniger repetitiven Entscheidungen wie bspw. der Planung von<br />
Kampagnen bis hin zu Entscheidungen mit strategischem Charakter wie Expansionsplanung<br />
oder Standortentscheidungen, reichen 143 . Auf der anderen Seite unterstützen<br />
140 Vgl. Bucher et al. 2007.<br />
141 Vgl. Ferstl, Sinz 2008, S. 2ff.<br />
142 Vgl. Bauer, Günzel 2004, S. 9; Laudon et al. 2006, S. 85.<br />
143 Vgl. Laudon et al. 2006, S. 84.
Konzeptionelle Grundlagen 29<br />
AIS auch mit Geschäftsprozessen verbundene Tätigkeiten wie bspw. die Terminierung<br />
einer Lieferung aufgrund historischer Daten oder die systemische Unterstützung der<br />
Preissetzung bei Last-Minute-Angeboten in der Tourismus-Branche 144 . Es stehen somit<br />
die „Informationsversorgung und funktionale Unterstützung betrieblicher Fach- und<br />
Führungskräfte zu Analysezwecken“ im Vordergrund 145 . So gesehen sind AIS als eine<br />
sehr heterogene IS-Klasse zu sehen 146 . Dies zeigt auch die nachfolgende Skizze (vgl.<br />
Abbildung 9) der historischen Entwicklung der Computerunterstützung des Managements<br />
und insbesondere von AIS mit ihren vielfältigen Ausprägungen und Charakteristika.<br />
Dabei werden die jeweiligen Konzepte im Zeitverlauf den typischen Nutzungsgruppen<br />
(Top-Management, Fachbereichsmanagement und operative Ebene)<br />
zugeordnet.<br />
Top-<br />
Manage-<br />
ment-<br />
Ebene<br />
EIS<br />
ESS<br />
DWH<br />
EIS<br />
OLAP<br />
WWW<br />
Mobile<br />
Fachbereichsmanagementebenen<br />
MIS<br />
Idee<br />
MIS<br />
DSS<br />
MIS<br />
DSS<br />
DSS<br />
DMS<br />
IP<br />
Big Data<br />
Social Media<br />
Sentiment<br />
operative<br />
Ebene<br />
TIS<br />
TIS<br />
TIS TIS TIS<br />
1950er<br />
1960er 1970er 1980er 1990er<br />
2000er und Zukunft<br />
Legende:<br />
Anwendungssystemtypen für die<br />
Managementunterstützung<br />
Nicht realisierte<br />
Anwendungssystemkonzepte<br />
Sonstige, die Entwicklung beeinflussende<br />
Anwendungssystemtypen<br />
Abbildung 9: Historische Entwicklung der Rechnerunterstützung des Managements 147<br />
Ausgehend von Softwaresystemen, die bereits in den 1950er Jahren die operativen<br />
Prozesse in den Unternehmen, insbesondere die elektronische Verarbeitung administrativer<br />
und dispositiver Massendaten, unterstützten 148 , wurden in den 1960er Jahren<br />
die ersten <strong>Informationssysteme</strong>, die Management Information Systems (MIS), entwickelt.<br />
Diese erlaubten es, Führungskräfte mit Informationen zu versorgen, die zur<br />
Steuerung des Unternehmens dienten. Das Konzept wurde allerdings nur teilweise<br />
144 Vgl. Bucher, Dinter 2008, S. 174ff.<br />
145 Vgl. Chamoni, Gluchowski 2006, S. 11.<br />
146 Vgl. Winter et al. 2008, S. 5ff.<br />
147 In Anlehnung an Knackstedt 2004, S. 75ff. und Stroh 2010, S. 15.<br />
148 Vgl. Oppelt 1995, S. 9ff.
30 Konzeptionelle Grundlagen<br />
umgesetzt (vgl. MIS Idee in Abbildung 9), da zu jener Zeit die technischen Voraussetzungen<br />
noch nicht gegeben waren 149 .<br />
Die Ursprünge von AIS reichen demnach bis in die 1960er Jahre zurück. Seit den<br />
1970er Jahren bauen AIS auf der Speicherung von integrierten und historisierten Daten<br />
auf und erlauben es, auf Grundlage der daraus generierten Berichte Planung, Steuerung<br />
und Kontrolle auf allen Hierarchiestufen eines Unternehmens zu betreiben 150 .<br />
Unter dem Begriff Management Support Systems (MSS) werden die drei verschiedenen<br />
Systemklassen MIS, Decision Support Systems (DSS) und Executive Information<br />
Systems (EIS) zusammengefasst 151 . Zusätzlich wurde in den 1980er Jahren die Executive<br />
Support Systems (ESS) eingeführt, welche EIS um typische DSS-Funktionen wie<br />
bspw. Sensitivitätsanalysen erweiterten 152 .<br />
MIS sind Systeme zur Versorgung des mittleren Managements mit <strong>analytische</strong>n Daten.<br />
In der zweiten Generation, ab 1980, waren flexible Abfragen möglich, die von den<br />
Endanwendenden selbst durchgeführt wurden, während in der ersten Generation die<br />
Berichte in manueller Arbeit von speziell qualifizierten IT-Mitarbeitenden aufbereitet<br />
werden mussten. MIS greift vorwiegend auf operative Daten zurück, welche jedoch<br />
teilweise historisiert sein können und in der Regel engen Subjektbezug haben 153 . MIS<br />
wird heute als synonymer Begriff für die Gesamtheit der MSS verstanden 154 . Auch<br />
DSS versorgen in erster Linie das mittlere Management mit Daten zur Entscheidungsunterstützung.<br />
Sie dienen jedoch dazu, dieses interaktiv bei ihren Entscheidungen zu<br />
unterstützen. Sie zeichnen sich durch ihre hohe Flexibilität aus und dienen zu Prognose-,<br />
Planungs-, Simulations- und Optimierungszwecken 155 . Im Unterschied zu MIS und<br />
DSS richtet sich das EIS in erster Linie an das Top-Management. Es aggregiert und<br />
integriert Daten aus MIS, DSS und externen Quellen und stellt diese in visualisierter<br />
Form dar.<br />
Zunehmend wird allerdings eine Typisierung der oben genannten Systemklassen kritisch<br />
beurteilt, da eine solch feingranulare Abgrenzung eher zu Verwirrung als zu Klä-<br />
149 Vgl. Knackstedt 2004, S. 76.<br />
150 Vgl. Clark et al. 2007, S. 580ff.<br />
151 Vgl. Holten 1999, S. 29.<br />
152 Vgl. Knackstedt 2004, S. 81.<br />
153 Vgl. Laudon et al. 2006, S. 86f.; Winter et al. 2008, S. 7.<br />
154 Vgl. Winter et al. 2008, S. 7.<br />
155 Vgl. Holten 1999, S. 36ff.
Konzeptionelle Grundlagen 31<br />
rung führt 156 und aus heutiger Perspektive eher Spezialkonzepte beschreibt, die kaum<br />
noch in dezidierter Form zu finden sind 157 .<br />
Ende der 1980er Jahre wurde von INMON das Konzept des Data Warehouse (DWH)<br />
vorgestellt. Es ermöglichte, durch die Integration mehrerer Datenquellen und die<br />
Schaffung eines aufbereiteten, unternehmensweiten Datenbestands die Weiterentwicklung<br />
der bestehenden Ansätze. Dadurch wurde ein umfassendes Berichtswesen ermöglicht,<br />
was die Systemtypen bis dahin nicht zu leisten vermochten. INMON legte mit folgender<br />
Definition die grundlegenden Eigenschaften eines DWH fest: „A data warehouse<br />
is a subject-oriented, integrated, nonvolatile, time-variant collection of data in<br />
support of management's decisions.“ 158 – „subject-oriented“ bedeutet dabei, dass die<br />
Daten in einem DWH so strukturiert werden, dass sie einem bestimmten Anwendungszweck<br />
dienen, „integrated“ heisst, dass die analyserelevanten Daten aus den verschiedenen<br />
operativen Systemen im DWH physisch zusammengeführt, bereinigt und<br />
vereinheitlicht werden, aufgrund der Eigenschaft „nonvolatile“ werden einmal eingelesene<br />
Daten nicht mehr überschrieben oder geändert und „time-variant“ ist eine langfristige<br />
Haltung der Daten im DWH, um Analysen mit Zeitbezug zu ermöglichen. Diese<br />
Eigenschaften ermöglichten EIS und DSS auf einer integrierten Datenbasis. INMON<br />
sieht bezüglich DWH-Architektur eine zentrale Integrationsschicht, basierend auf einem<br />
relationalen Unternehmens-Datenmodell, vor. In der Praxis hat sich allerdings die<br />
Sichtweise von KIMBALL durchgesetzt 159 . Dieser sieht statt einer zentralen Datenbasis<br />
unterschiedliche multidimensionale Sichten von Datenbeständen in Form von Data<br />
Marts zu speziellen fachlichen Themen vor 160 . Somit kann einerseits gewährleistet<br />
werden, dass die Informationen für die Nutzenden einfacher zugänglich sind und dass<br />
andererseits ein höherer Schutz vor unbefugtem Zugriff auf die Daten besteht 161 .<br />
Aufgrund der neuen Möglichkeiten haben sich in den 1990er Jahren weitere Ansätze<br />
etabliert, welche die Präsentations- und Auswertungssicht bereichert haben. Die wichtigsten<br />
Konzepte hierbei sind Data Mining Systeme (DMS) und Online Analytical<br />
Processing (OLAP) 162 . DMS zielen auf die Auswertung von grossen Datenmengen ab.<br />
Es werden Methoden zur Verfügung gestellt, die es erlauben, grosse, strukturierte Datenmengen<br />
auf interessante aber schwer zu identifizierende Zusammenhänge zu analy-<br />
156 Vgl. Bauer, Günzel 2004, S. 11.<br />
157 Vgl. Winter et al. 2008, S. 7.<br />
158 Vgl. Inmon 1996, S. 33.<br />
159 Vgl. Breslin 2004, S. 7; Sen, Sinha 2005, S. 80.<br />
160 Vgl. Kimball, Ross 2002, S. 78ff.<br />
161 Vgl. Breslin 2004, S. 13.<br />
162 Vgl. Knackstedt 2004, S. 87.
32 Konzeptionelle Grundlagen<br />
sieren 163 . Dabei werden statistische Verfahren wie bspw. Klassifikation, Regression,<br />
Prognose, etc. verwendet. Typischerweise werden diese Verfahren basierend auf den<br />
Datenbeständen eines DWH durchgeführt. Erste Produkte für Data Mining kamen in<br />
den 1990er Jahren auf den Markt 164 . Daneben etablierten sich zunehmend auch OLAP-<br />
Systeme. Die eher an das Top-Management gerichteten Analysewerkzeuge zeichnen<br />
sich dadurch aus, dass sie über eine Navigationsfunktion durch die im Datenbestand<br />
abgebildeten Dimensionen und Hierarchien verfügen 165 . Die eigentliche Datenbankabfrage<br />
bleibt den Nutzenden verborgen, so dass diese nicht beherrscht werden müssen.<br />
So ermöglichen OLAP-Systeme eine multidimensionale Betrachtung der Daten 166<br />
(bspw. eine Analyse der Verkaufszahlen über einen gewissen Zeitraum, Verkaufsgebiet<br />
und für ein gewisses Produkt). OLAP-Systeme greifen in der Regel auf die strukturierten<br />
Daten in einem DWH zu.<br />
Die Mitte der 1990er Jahre einsetzende zunehmende Verbreitung des World-Wide-<br />
Webs (WWW) ermöglichte die weitere Integration der verschiedenen Ansätze von<br />
AIS und dabei insbesondere die Bereitstellung qualitativer und unternehmensexterner<br />
Daten 167 . Das Konzept von Informationsportalen (IP), welches Unternehmen ermöglicht<br />
„to unlock internally and externally stored information and provide users a single<br />
gateway to personalized information needed to make informed business decisions“ 168 ,<br />
zeigt diese zunehmende Vernetzung.<br />
Mit der Etablierung mobiler Endgeräte wie bspw. Smartphones oder Tablets wurde es<br />
in den 2000er Jahren möglich, dass insbesondere das Top-Management jederzeit über<br />
das WWW auf die AIS der Unternehmung zugreifen kann 169 . Ein weiterer Trend, der<br />
gegenwärtig immer mehr an Bedeutung gewinnt, ist die Analyse qualitativer Daten aus<br />
sozialen Netzwerken wie bspw. Twitter, Facebook oder Internetforen (Social Media<br />
Sentiment). Ziel dabei ist es, Stimmungen zu gewissen Produkten oder Unternehmungen<br />
zu ermitteln, auszuwerten und, wo notwendig, darauf zu reagieren. Aufgrund der<br />
Geschwindigkeit, mit der in sozialen Netzwerken kommuniziert wird, kann so schnell<br />
ein Stimmungsbild ermittelt werden, was bei adäquater Reaktion zu einem Wettbewerbsvorteil<br />
führen kann 170 . Eine Analyse dieser Daten erfolgt demnach auf einer sehr<br />
163 Vgl. Bissantz et al. 2000, S. 380.<br />
164 Vgl. Schinzer 2000, S. 432.<br />
165 Vgl. Lehner 2002, S. 83ff.<br />
166 Vgl. Codd et al. 1993.<br />
167 Prognostiziert bereits durch Oppelt 1995, S. 151ff. und bestätigt durch die heutigen Trends.<br />
168 Vgl. Shilakes, Tylman 1998, S. 3.<br />
169 Vgl. Mayer, Weitzel 2012, S. 1677ff.<br />
170 Vgl. bspw. Stodder 2011.
Konzeptionelle Grundlagen 33<br />
grossen Datenmenge. Die global entstehenden Daten explodieren seit Jahren. Seit<br />
2005 ist die Datenmenge von ca. 100 Exabyte auf ca. 1750 Exabyte gestiegen 171 . Konventionelle<br />
Methoden der Speicherung, Erfassung und Analyse dieser Daten reichen<br />
nicht mehr aus. Es bedarf demnach innovativer technischer Konzepte, um dieser Herausforderung<br />
zu begegnen 172 . STODDER ET AL. nennt eine Vielzahl Techniken zur Analyse<br />
und Speicherung solch grosser Datenmengen 173 .<br />
Das technische Konzept des DWH als zentraler integrierender Speicher für Daten,<br />
bleibt seit dessen Etablierung in den 1990er Jahren als Basis für die Entwicklung weiterführender<br />
Konzepte erhalten. Neben der Auffassung des DWH als rein technische<br />
Komponente, findet sich auch der Begriff des Data Warehousing. Darunter subsumieren<br />
sich alle Prozesse, die für den Betrieb relevant sind, d.h. sämtliche Aktivitäten,<br />
welche die Extraktion der Daten aus den Quellsystemen, die Transformation und das<br />
Laden in das DWH, sowie die Analyse der Daten im DWH betreffen 174 . Beide Begriffe,<br />
das DWH als „Umsetzungsarchitektur“ 175 und Data Warehousing als Konzept für<br />
den Betrieb eines DWHs sind eher technische Komponenten von AIS.<br />
Eine stärker fachliche Ausrichtung stellt dagegen das Konzept der Business Intelligence<br />
(BI) dar. Der erstmals 1958 von LUHN 176 eingeführte Begriff verstand darunter<br />
die Analyse, das Berichtswesen und die Datenabfrage für die Endnutzenden 177 . In der<br />
Vergangenheit entwickelten sich verschiedenartige Definitionen von BI, die von einer<br />
weiten Sicht als Sammelbegriff für fachliche Anwendungen wie auch technische<br />
Komponenten bzw. die zugrundeliegende Integrationsinfrastruktur 178 bis hin zur ursprünglichen,<br />
engen Sicht von BI im Sinne von LUHN als zur Verfügung stellendes<br />
Konzept von Analysefunktionen zur Umsetzung betrieblicher Prozesse durch die Versorgung<br />
mit handlungs- und entscheidungsrelevanten Informationen reichen 179 .<br />
Alle beschriebenen Konzepte und Technologien und insbesondere die grundlegenden<br />
Ansätze DWH und BI sind auch heute noch von einer stark technologischen Sicht geprägt,<br />
ohne organisatorische und strategische Aspekte adäquat miteinzubeziehen 180 .<br />
171 Vgl. The Economist 2010.<br />
172 Vgl. bspw. Manyika et al. 2011; Stodder 2011.<br />
173 Vgl. Stodder 2011, S. 27ff.<br />
174 Vgl. Bauer, Günzel 2004, S. 75ff.<br />
175 Vgl. Winter 2010a, S. 5.<br />
176 Vgl. Luhn 1958, S. 315ff.<br />
177 Vgl. Anandarajan et al. 2004, S. 18.<br />
178 Vgl. Kemper et al. 2010, S. 4.<br />
179 Vgl. Gluchowski 2001, S. 6f.; Kemper et al. 2010, S. 2ff.; Klesse 2007, S. 27f.; Winter 2010a, S. 5.<br />
180 Vgl. Winter et al. 2008, S. 8.
34 Konzeptionelle Grundlagen<br />
Um dieser Gegebenheit Rechnung zu tragen, wurde das St. Galler Konzept der IIL<br />
entwickelt. Dieses orientiert sich am BE (vgl. Abschnitt 2.1) und setzt sich mit der<br />
fachlichen Sicht von AIS auseinander 181 . IIL versteht sich als „Planung, Steuerung,<br />
Durchführung und Kontrolle der Gesamtheit der Datenflüsse […] die über eine Betrachtungseinheit<br />
hinausgehen, sowie die Speicherung und Aufbereitung dieser Daten.<br />
Dabei werden nur solche Datenflüsse zur Informationslogistik gezählt, die der Unterstützung<br />
von Entscheidungen dienen“ 182 . Zu den Gestaltungsaufgaben der IIL gehören,<br />
analog dem BE, strategische und organisatorische Rahmenbedingungen der <strong>analytische</strong>n<br />
Informationsversorgung, finanzielle Aspekte, sowie das IT/Business-<br />
Alignment 183 .<br />
Zusammenfassend lassen sich drei zentrale Unterschiede zwischen BI/DWH und IIL<br />
festhalten 184 : Die IIL hat einen umfassenderen Fokus, welcher alle Ebenen des St. Galler<br />
BE-Modells umfasst (vgl. Abschnitt 2.1), während sich BI/DWH vorwiegend mit<br />
den Ebenen „Software“ und „Infrastruktur“ befasst. BI/DWH fokussiert vorwiegend<br />
auf die Schaffung einer integrierten Datenbasis, während die IIL das Ziel verfolgt, Informationsflüsse<br />
zu realisieren, die der Befriedigung von Informationsbedarfen aus<br />
den Fachabteilungen dienen. Der dritte Unterschied ergibt sich aus der Berücksichtigung<br />
von organisationsübergreifenden Informationsflüssen, wie bei der IIL vorhanden<br />
– während BI/DWH einen expliziten Fokus auf organisationsübergreifende Informationsflüsse<br />
vermissen lässt.<br />
Während sich IIL auf die Gesamtheit der für Entscheidungen relevanten Datenflüsse<br />
konzentriert und dabei vor allem auf die Generierung von Synergien fokussiert, zielt<br />
die <strong>analytische</strong> Prozessunterstützung (APU) auf die Versorgung einzelner Prozesse,<br />
insbesondere im operativen Bereich, mit <strong>analytische</strong>n Informationen, ab. Dabei werden<br />
die Daten, die in den verschiedenen Geschäfts- und Unterstützungsprozessen anfallen,<br />
als direkter Input für die Auswertungen und Analyseergebnisse verwendet 185 .<br />
Die enge Verzahnung von Analytik und Prozessausführung 186 zeigen beispielhaft zwei<br />
Anwendungsmöglichkeiten wie von BUCHER UND DINTER genannt: Die Generierung<br />
von Last-Minute-Angeboten eines Reiseveranstalters und die Überprüfung von Zah-<br />
181 Vgl. Winter 2008a, S. 24ff.<br />
182 Vgl. Winter 2010a, S. 6; Winter et al. 2008, S. 2.<br />
183 Vgl. Winter 2010a, S. 9ff.<br />
184 Vgl. im Folgenden Winter et al. 2008, S. 6ff.<br />
185 Vgl. Bucher, Dinter 2008, S. 169.<br />
186 Vgl. Winter 2010a, S. 20.
Perspektive<br />
Konzeptionelle Grundlagen 35<br />
lungsverkehrstransaktionen hinsichtlich Geldwäschereiverdachts 187 . In beiden Fällen<br />
handelt es sich um stark strukturierte Prozesse, die jedoch aus verschiedenen Gründen<br />
nicht vollständig automatisiert werden können. Dennoch haben beide eine grosse Bedeutung<br />
für das jeweilige Unternehmen 188 . Hier setzt der Ansatz der APU an und stellt<br />
den Prozessausführenden <strong>analytische</strong> Informationen zur Verfügung, die Entscheidungen<br />
unterstützen.<br />
Die in diesem Abschnitt beschriebenen Konzepte und Ansätze lassen sich hinsichtlich<br />
der Dimensionen Perspektive bzw. Reichweite mit den Ausprägungen „übergreifend &<br />
langfristig“ sowie „lokal & kurzfristig“ und der Dimension Fokus mit den Ausprägungen<br />
„fachlich“ und „technisch“ positionieren (vgl. Abbildung 10).<br />
übergreifend<br />
&<br />
langfristig<br />
Integrierte<br />
Informationslogistik<br />
Data Warehousing<br />
Analytische<br />
Prozessunterstützung<br />
Business Intelligence<br />
lokal &<br />
kurstfristig<br />
fachlich<br />
Fokus<br />
technisch<br />
Abbildung 10: Positionierung der zentralen Konzeptionen von AIS 189<br />
Zusammenfassend kann festgehalten werden, dass AIS eine besondere Klasse von IS<br />
bilden. Sie integrieren Daten aus unterschiedlichsten operativen Systemen und werden<br />
ausserdem lokal, wie auch bereichs- bzw. organisationseinheitsübergreifend, genutzt.<br />
Ausserdem subsumieren sie sowohl technische Aspekte, die sich mit der Datenstrukturierung<br />
und Integration beschäftigen, als auch eher fachlich geprägte, die sich mit der<br />
Datenpräsentation und -auswertung auseinandersetzen. Dies erklärt die hohe Heterogenität<br />
und Komplexität von Projekten im Umfeld von AIS. AIS bilden gemäss CHA-<br />
MONI UND GLUCHOWSKI die logische Klammer um alle beschriebenen Konzepte, sowohl<br />
fachlicher, als auch technischer Natur 190 . Aus diesem Grund müssen für eine situative<br />
Methode für das Management von AIS-Projekten sämtliche Perspektiven berücksichtigt<br />
werden. Insbesondere die Trennung zwischen Datenstrukturierung und<br />
187 Vgl. Bucher, Dinter 2008, S. 173ff.<br />
188 Vgl. Winter 2010a, S. 22.<br />
189 In Anlehnung an Winter 2010a, S. 6.<br />
190 Vgl. Chamoni, Gluchowski 2006, S. 3.
36 Konzeptionelle Grundlagen<br />
-präsentation, also die Bereiche Backend und Frontend, bedürfen einer besonderen<br />
Betrachtung. Neben der in diesem Kapitel beschriebenen historisch bedingten Trennung,<br />
zeigen dies sowohl die Beobachtungen in den Fallstudien (vgl. Kapitel 5), als<br />
auch die Analyse der Literatur (vgl. Kapitel 3).<br />
Die angesprochene Trennung widerspiegelt sich auch in den vielfältigen Ausprägungen<br />
von Systemarchitekturen der AIS. Sie unterscheiden verschiedene Arten der Integration,<br />
Speicherung und Präsentation der Daten 191 . Die in der Praxis am häufigsten<br />
eingesetzte Architektur 192 ist die auf INMON zurückgehende Hub-and-Spoke-<br />
Architektur 193 . Dabei werden die Daten, ausgehend von den Quellsystemen, mittels<br />
eines ETL-Prozesses in ein zentrales DWH transformiert, gespeichert und historisiert.<br />
Daraus werden Data Marts gespeist, die jeweils eine Partialsicht auf die Gesamtdaten<br />
beinhalten. Der zu entwickelnde Ansatz verfolgt hinsichtlich Systemaspekten das Ziel,<br />
möglichst generisch einsetzbar zu sein. Implizit wird der situativen Methode die angesprochene<br />
Hub-and-Spoke-Architektur zugrunde gelegt. Der Einsatz unter anderen<br />
Architekturformen ist allerdings auch denkbar.<br />
Neben der Architekturform existieren auch bezüglich der Organisation von AIS unterschiedliche<br />
Ausgestaltungen. Für die vorliegende Arbeit wird implizit davon ausgegangen,<br />
dass die AIS-Organisationseinheit der IT-Abteilung untergliedert ist und aufgrund<br />
der Häufigkeit dieser Organisationsform als eine Art Competence Center (CC)<br />
fungiert. Auch für den Fall der Anwendung der Methode durch einen externen Dienstleister<br />
wird der CC-Charakter angenommen. Aufgrund der zunehmenden Industrialisierung<br />
bei der Erstellung von IT-Dienstleistungen und durch den verstärkten Einsatz<br />
von Standardsoftware sowohl im Frontend- als auch im Backendbereich, nimmt die<br />
Fertigungstiefe sowohl im Betrieb, als auch in der Entwicklung von AIS ab 194 . Dennoch<br />
müssen entsprechende Kompetenzen sowohl technischer, als auch fachlicher Natur<br />
gebündelt und in einer Organisationseinheit untergebracht werden.<br />
2.3 Projekte und deren Abwicklung<br />
Seit grössere Vorhaben umgesetzt werden, wurden diese mittels mehr oder weniger<br />
expliziter Planung durchgeführt. Anders wäre es nicht möglich gewesen, Projekte wie<br />
die Chinesische Mauer oder die Pyramiden zu realisieren 195 . Moderne Ansätze des<br />
191 Für eine Übersicht vgl. Lahrmann, Stroh 2008.<br />
192 Vgl. Eckerson 2006, S. 15; Inmon 2002, S. 35ff.<br />
193 Vgl. Inmon 2002.<br />
194 Vgl. Eckerson 2005, S. 10ff.; Richardson 2008; von Jouanne-Diedrich et al. 2005, S. 18.<br />
195 Vgl. Casutt 2005, S. 6f.; Pfeiffer 2004, S. 3.
Konzeptionelle Grundlagen 37<br />
<strong>Projektmanagement</strong>s stammen aus den 40er Jahren des 20. Jahrhunderts aus der<br />
Raumfahrt, vor allem aber aus grossen Militärprojekten 196 . Nach dem Zweiten Weltkrieg<br />
fand das <strong>Projektmanagement</strong> mehr und mehr Verbreitung in der Industrie. Im<br />
Jahr 1983 veröffentlichte das Project Management Institute (PMI), der USamerikanische<br />
Fachverband für <strong>Projektmanagement</strong>, mit dem „Project Management<br />
Body of Knowledge Guide“ (PMBoK Guide), die erste umfangreiche Ausbildungsunterlage<br />
für Projektpersonal 197 . Bis heute wurden unzählige Vorgehensweisen für das<br />
Management von Projekten veröffentlicht. Diese reichen von allgemeinen Projektmethoden<br />
bis hin zu spezifischen Branchen- oder Fachlösungen.<br />
Abbildung 11 zeigt anhand einiger ausgewählter Forschungs- und Entwicklungsprojekte<br />
die zeitliche Entwicklung formalisierten <strong>Projektmanagement</strong>s.<br />
2004<br />
2009<br />
Verspäteter Erstflug des Airbus A-380<br />
EU-Erweiterung<br />
1996<br />
2002<br />
Einführung des Euro<br />
Java von Sun<br />
1982<br />
1993<br />
Intel Pentium Processor<br />
Compact Disc (CD) von Philips<br />
1981 IBM Personal Computer<br />
1977 Entwicklung der Software für die Space-Shuttle<br />
1977 IBM Betriebssystem MVS/SE<br />
Erstes Grossprojekt, welches<br />
konsequent iterativ-inkrementell<br />
entwickelt wurde<br />
1940<br />
1960<br />
Apollo-Programm der NASA<br />
Manhatten Engineering District Project (Nuklearbombe)<br />
Erstmaliger Einsatz von<br />
<strong>Projektmanagement</strong>-Techniken<br />
Abbildung 11: Entwicklung des <strong>Projektmanagement</strong>s<br />
am Beispiel ausgewählter Forschungs- und Entwicklungsprojekte 198<br />
Das <strong>Projektmanagement</strong> strukturiert Vorhaben und stellt Möglichkeiten zur Verfügung,<br />
arbeitsteilige Aufgaben besser zu koordinieren und zu kontrollieren. Damit können<br />
Projekte schneller, kostengünstiger und mit besseren Resultaten abgewickelt werden<br />
199 . Eine entsprechende Notwendigkeit wird durch verschiedene externe Faktoren<br />
196 Als Anfang des modernen <strong>Projektmanagement</strong>s gelten das Manhatten Engineering District Projekt von<br />
1941, dessen Ziel es war, die erste Nuklearbombe zu entwickeln, sowie das Apollo Projekt der NASA Anfang<br />
der 1960er Jahre (Litke 2007, S. 21f.; Pfeiffer 2004).<br />
197 Vgl. Casutt 2005, S. 7.<br />
198 In Anlehnung an Wieczorrek, Mertens 2011, S. 17.<br />
199 Vgl. Casutt 2005, S. 6.
38 Konzeptionelle Grundlagen<br />
begründet, so z.B. durch dynamische Märkte mit verkürzten Produktlebens-, Produktentwicklungs-<br />
und Innovationszyklen, durch steigende technologische Innovationen<br />
und Entwicklungen, durch eine Dezentralisierung von Verantwortung, durch hohe<br />
Kundenorientierung und gewachsene Nachfrage nach spezialisierten Dienstleistungen<br />
und Systemlösungen, durch ergebnisorientierte und zielgeleitete Arbeitsformen, durch<br />
fortschreitende Globalisierung und sich rasant entwickelnde Informationsbereitstellung<br />
und vereinfachte Kommunikationsmedien 200 .<br />
Der Projektbegriff ist schon länger in die Alltagssprache übergegangen. So wird in<br />
vielfältiger Form von einem Projekt gesprochen, bspw. wenn ein Unternehmen eine<br />
Investition plant oder eine Musikgruppe einen neuen Tonträger aufnimmt 201 . Werden<br />
Projekte nach deren Gemeinsamkeiten untersucht, so können gemäss KUSTER ET AL. 202<br />
einige Charakteristika identifiziert werden:<br />
Projekte bringen Veränderungen mit sich. Sie sind abgegrenzte Vorhaben, sowohl inhaltlich<br />
als auch zeitlich, sind Innovationen, d.h. sie erschaffen Neues und sind komplex,<br />
überschreiten die gewöhnliche Organisationsstruktur und tangieren verschiedene<br />
Disziplinen und Verantwortungsbereiche. Ausserdem ändert sich der Projektcharakter<br />
von Phase zu Phase und erfordert je nach Situation andere Managementfähigkeiten.<br />
Projekte sind schwierig zu planen und zu steuern und erfordern somit besondere organisatorische<br />
Massnahmen. Sie brauchen ausserordentliche Ressourcen hinsichtlich<br />
Wissen, Personal und Finanzen, weisen je nach Grösse und Komplexität verschiedene<br />
Risiken auf und verlangen für deren Abwicklung eigene Organisationen (Projektorganisationen).<br />
Projekte mit hoher Komplexität sind nach PFETZING UND ROHDE 203 neuartig, bereichsübergreifend,<br />
interdisziplinär, risikoreich, aufwändig, strategisch bedeutend, dringlich<br />
und aussergewöhnlich.<br />
Obschon KUSTER ET AL. postulieren, dass sich gegenwärtig noch keine einheitliche<br />
Definition von Projekt herausgebildet hat, beschreibt die Definition nach DIN 69901 204<br />
den Projektbegriff entsprechend der oben genannten Charakteristika und wird der vorliegenden<br />
Arbeit zugrunde gelegt:<br />
200 Vgl. Lent 2003, S. E-1; Wieczorrek, Mertens 2011, S. 10.<br />
201 Vgl. Wieczorrek, Mertens 2011, S. 9.<br />
202 Vgl. Kuster et al. 2008, S. 4.<br />
203 Vgl. Pfetzing, Rohde 2001, S. 14.<br />
204 Deutsches Institut für Normung.
Konzeptionelle Grundlagen 39<br />
Projekt<br />
„Ein Projekt ist ein Vorhaben, das im Wesentlichen durch Einmaligkeit der Bedingungen<br />
und ihrer Gesamtheit gekennzeichnet ist wie z.B. Zielvorgabe, zeitliche, finanzielle,<br />
personelle oder andere Begrenzungen, Abgrenzung gegenüber anderen<br />
Vorhaben und projektspezifische Organisation.“ 205<br />
Entsprechend dieser Definition grenzen WIECZORREK UND MERTENS Projekte, wie in<br />
Abbildung 12 dargestellt, ab. Dabei wird eine Regeltätigkeit dadurch gekennzeichnet,<br />
dass sie keinen einmaligen Charakter besitzt und keine definierten Start- und Endpunkte<br />
hat. Hierzu gehören bspw. Prozesse, die im Rahmen von Linienfunktionen abgewickelt<br />
werden (bspw. Auftragsannahme und -abwicklung). Vorhaben sind durch<br />
Einmaligkeit gekennzeichnet. Wenn diese innerhalb der bestehenden Organisationsstruktur<br />
abgewickelt werden, werden sie als Linienaktivitäten bezeichnet. Sofern für<br />
Vorhaben eine temporäre Organisation geschaffen wird, die nur für die Laufzeit des<br />
Projekts besteht, so wird von einem Projekt gesprochen.<br />
Prozessen bzw. Problemlösungen erforderlich sind.“ 207 . DIN 69901 definierte Pro-<br />
Aufgabe<br />
Regeltätigkeit<br />
(permanent durchgeführte<br />
Prozesse)<br />
jektmanagement folgendermassen:<br />
207 Vgl. Kuster et al. 2008, S. 8.<br />
Abbildung 12: Aufgabenabgrenzung bei Projekten 206<br />
Um solche einmaligen und durch eine spezielle, temporäre Organisation charakterisierten<br />
Projekte abwickeln zu können, bedarf es einer adäquaten Planung und Führung<br />
mittels geeigneter Organisations- und Steuerungsmittel. <strong>Projektmanagement</strong> ist dabei<br />
der „[…] Oberbegriff für alle planenden, überwachenden, koordinierenden und steuernden<br />
Massnahmen […], die für die Um- oder Neugestaltung von Systemen oder<br />
205 Vgl. DIN 2009.<br />
206 In Anlehnung an Wieczorrek, Mertens 2011.<br />
Projekte<br />
(Einmaligkeit und<br />
spezielle Org.)<br />
Vorhaben<br />
Linienaktivität<br />
(Einmaligkeit aber keine<br />
spezielle Org.)
40 Konzeptionelle Grundlagen<br />
<strong>Projektmanagement</strong><br />
„<strong>Projektmanagement</strong> ist die Gesamtheit von Führungsaufgaben, -organisationen,<br />
-techniken und -mittel für die Abwicklung eines Projekts.“ 208<br />
Nach JENNY 209 gehören zu den wichtigen Aufgaben eines <strong>Projektmanagement</strong>s die<br />
Planung und Koordination, das Schaffen und Berücksichtigen von Rahmenbedingungen<br />
innerhalb des Projekts, das Anleiten, Motivieren und Kontrollieren der Mitarbeitenden,<br />
der Schutz des Projekts vor der Einwirkung der Umsysteme, das Erkennen und<br />
Beheben unerwarteter Schwierigkeiten sowie die Vertretung des Projekts nach aussen.<br />
Das <strong>Projektmanagement</strong> ist demnach in einem permanenten Entscheidungsprozess mit<br />
dem Ziel, in möglichst kurzer Zeit möglichst viel Qualität und Quantität zu möglichst<br />
geringen Kosten zu liefern 210 . Jedes Projekt befindet sich in diesem „magischen Dreieck“<br />
zwischen Kosten, Qualität/Quantität und Zeit 211 . Diese Vielschichtigkeit des <strong>Projektmanagement</strong>s<br />
widerspiegelt sich auch in den unterschiedlichen Dimensionen, wie<br />
sie KUSTER ET AL. 212 sehen:<br />
Die funktionale Dimension, die sich der Frage widmet, was zu tun ist und dabei die<br />
entsprechenden Arbeitsschritte und Phasen im Projekt betrachtet. Dabei geht es um die<br />
Initialisierung von Projekten, d.h. das Projekt in Gang setzen, die Projektbearbeitung,<br />
also das Projekt in Gang halten, sowie der Abschluss des Projekts.<br />
Die institutionelle Dimension beschäftigt sich mit Fragen der Projektorganisation und<br />
der Verknüpfung des Projekts zu seinem Umfeld. Dabei geht es um die Bestimmung<br />
des Projektgremiums, das Festlegen von Rollen und Funktionen, sowie die Regelung<br />
von Kompetenzen und Verantwortungen.<br />
Die personelle, psychologische und soziale Dimension befasst sich mit Führungsfunktionen.<br />
Dazu gehört der Einsatz und die Qualifikation der Projektmitglieder, das Leiten<br />
der Teams, das Regeln der Zusammenarbeit, das Bewältigen von Konflikten oder das<br />
Gestalten von sozialen Prozessen.<br />
Die instrumentelle Dimension beinhaltet unterstützende Instrumente und Techniken<br />
wie bspw. die IT-Unterstützung im Projekt, die Unterstützung durch etablierte Projektmethoden<br />
oder Templates, Formulare und andere Hilfsmittel.<br />
208 Vgl. DIN 2009.<br />
209 Vgl. Jenny 2001, S. 62.<br />
210 Vgl. Amberg et al. 2011, S. 3.<br />
211 Vgl. Amberg et al. 2011, S. 3; Wieczorrek, Mertens 2011, S. 13.<br />
212 Vgl. Kuster et al. 2008, S. 9f.
Konzeptionelle Grundlagen 41<br />
Eine besondere Klasse von Projekten bilden IT-Projekte. Diese beschäftigen sich mit<br />
der Entwicklung von IKT-Systemen und bilden den Gegenstand der weiteren Ausführungen.<br />
Heute zeigt eine Vielzahl von Untersuchungen, dass ein grosser Teil von IT-<br />
Projekten entweder ganz scheitert oder finanziell bzw. zeitlich überzogen wird 213 . Die<br />
Gründe dafür liegen im Fehlen einer klaren Vision, und der klaren Formulierung von<br />
Anforderungen, unrealistischen Erwartungen seitens des Kunden, schlechte Aufteilung<br />
des Projekts in Teilprojekte und Aufgabenbündel, unpassende Zusammensetzung des<br />
Projektteams, schlechte Involvierung der Stakeholder, schlechte strategische Verankerung<br />
sowie fehlende Top-Management-Unterstützung 214 . Im Umkehrschluss bedeutet<br />
dies auch, dass dies Erfolgsfaktoren für IT-Projekte sein können, sofern sie adäquat<br />
berücksichtigt werden.<br />
Unterschiede zwischen IT-<strong>Projektmanagement</strong> und allgemeinem <strong>Projektmanagement</strong><br />
sind dabei insbesondere die Interdisziplinarität, die durch den Einbezug von Fachkräften<br />
und IT-Mitarbeitenden entsteht, sowie in vielen Fällen die Neuartigkeit und das<br />
Risiko, welches sich bspw. durch die Migration einer geschäftskritischen Applikation<br />
ergibt. Für das Management von AIS-Projekten verschärft sich die bereichsübergreifende<br />
und interdisziplinäre Komponente zusätzlich dadurch, dass Daten aus verschiedenen<br />
Fachbereichen integriert und von anderen Fachbereichen genutzt werden. Deshalb<br />
kann IT-Projekten allgemein eine hohe Komplexität unterstellt werden. Dabei<br />
lassen sich solche Projekte in „[…] immer wiederkehrende gleichförmige Abschnitte<br />
bzw. Phasen unterteilen, die eine standardisierte Abwicklung dieser Projekte ermöglichen“<br />
215 . Aus diesem Grund bietet sich hier der Einsatz standardisierter Verfahren wie<br />
bspw. Vorgehensmodellen an. In der Vergangenheit hat sich eine Vielzahl von Methoden<br />
für IT-Projekte etabliert. Dabei lässt sich beobachten, dass unabhängig davon in<br />
welche und wie viele Arbeitspakete ein Projekt aufgeteilt wird, immer die Phasen „Initialisierung“,<br />
„Analyse“, „Konzept/Design“, „Realisierung“, „Einführung“ und „Abschluss“<br />
verwendet werden 216 .<br />
Dies wiederspiegelt sich in den sich etablierten Methoden für das <strong>Projektmanagement</strong>.<br />
Dazu gehören allgemeine Methoden, die auf IT-Projekte adaptiert werden wie bspw.<br />
der PMBoK Guide oder PRINCE2, aber auch spezifisch für IT-Projekte entwickelte<br />
213 Vgl. Feldmüller et al. 2005; Ramamurthy et al. 2008; Watson 2005; Wixom, Watson 2001.<br />
214 Vgl. Humphrey 2002; Schwalbe 2011; Wieczorrek, Mertens 2011; Yetton et al. 2000.<br />
215 Vgl. Wieczorrek, Mertens 2011, S. 11.<br />
216 Vgl. Informatikstrategieorgan Bund 2003; Informatikstrategieorgan Bund 2010a; Kuster et al. 2008; Lent<br />
2003.
42 Konzeptionelle Grundlagen<br />
Ansätze wie das V-Modell XT, Rational Unified Process (RUP) oder HERMES. Im<br />
Folgenden werden diese Ansätze kurz beschrieben 217 .<br />
2.3.1 HERMES<br />
HERMES ist eine generische Vorgehensweise für das Management von IT-Projekten<br />
im Allgemeinen. Dies begünstigt auf der einen Seite den breiten Einsatz im Schweizerischen<br />
Bundesumfeld, für welches die Methode entwickelt wurde, bereitet jedoch auf<br />
der anderen Seite gewisse Schwierigkeiten im spezifischen Facheinsatz, wie bspw. der<br />
Einsatz für AIS-Projekte. HERMES wurde 1975 für den Einsatz in IT-Projekten in der<br />
Schweizerischen Bundesverwaltung eingeführt. Nach umfassenden Revisionen in den<br />
Jahren 1986 und 1995 ist die Methode auch in Kantonen, Lehrinstituten und Unternehmen<br />
im Einsatz 218 . Der Ansatz wird ständig weiterentwickelt und durch das Informatikstrategieorgan<br />
Bund (ISB) herausgegeben.<br />
Projekttyp<br />
Systementwicklung<br />
Konzept<br />
Realisierung<br />
Initialisierung<br />
Voranalyse<br />
Einführung<br />
Abschluss<br />
Projekttyp<br />
Systemadaption<br />
Evaluation<br />
Implementierung<br />
Abbildung 13: Phasenmodell von HERMES 219<br />
Dieser Ansatz orientiert sich am St. Galler Ansatz des ME (vgl. auch Abschnitt 2.1.3).<br />
Die Methode beinhaltet ein Vorgehensmodell mit entsprechenden Aktivitäten, ein Ergebnismodell<br />
und Rollen. Das Vorgehensmodell ist sequentiell, orientiert sich also am<br />
Wasserfall-Ansatz 220 und gibt in hohem Detaillierungsgrad die einzelnen zu bearbeitenden<br />
Aktivitäten wider. HERMES unterscheidet zwei Arten von Projekten, für die<br />
jeweils eine eigene Ausgabe der Methode erschienen ist, die Systementwicklung und<br />
217 Die Auswahl der Ansätze erfolgte nach deren Verbreitung. Hierzu wurde in der in Abschnitt 4.1 durchgeführten<br />
Umfrage auch die eingesetzte <strong>Projektmanagement</strong>-Methode im AIS-Umfeld abgefragt. Dabei gaben<br />
31% an, eine eigene Methode zu verwenden, 21% verwenden Scrum, 9.7% V-Modell XT, jeweils 8.3%<br />
RUP, PMBoK Guide und PRINCE2, 7% Sonstige und 6.4% Kanban. Scrum und Kanban werden in den Abschnitten<br />
2.4.4 und 2.4.5 vorgestellt.<br />
218 Vgl. Informatikstrategieorgan Bund 2003, S. III; Informatikstrategieorgan Bund 2010a, S. III.<br />
219 In Anlehnung an Informatikstrategieorgan Bund 2009.<br />
220 Für eine kurze Charakterisierung des Wasserfall-Ansatzes vgl. Abschnitt 2.4.6.
Konzeptionelle Grundlagen 43<br />
die Systemadaption. Im Rahmen des Projekts Systementwicklung wird dabei ein neues<br />
System entwickelt, bei Systemadaption wird ein System angeschafft und entsprechend<br />
adaptiert. Für die Systementwicklung werden im Vorgehensmodell die Phasen „Initialisierung“,<br />
„Voranalyse“, „Konzept“, „Realisierung“, „Einführung“ und „Abschluss“<br />
verwendet, für die Systemadaption werden „Konzept“ und „Realisierung“ durch „Evaluation“<br />
und „Implementierung“ ersetzt (vgl. Abbildung 13). In jeder Phase existieren<br />
Entscheidungspunkte, welche überprüfen ob die in der Phase definierten Vorgaben<br />
erfüllt sind und somit in die nächste Phase übergegangen werden kann.<br />
Bezüglich Rollen und Ergebnissen werden diese sehr detailliert beschrieben. Die Rollen<br />
sind aufgeteilt nach „Projektleitung und -steuerung“, „Projektsachbearbeitung“ und<br />
„Querschnittsaufgaben“. Mittels Tailoring können in HERMES nicht benötigte Rollen<br />
weggestrichen werden. Dasselbe gilt für die Kernergebnisse, die aufgeteilt werden in<br />
„Projektergebnisse“ und „Querschnittsergebnisse“. HERMES geht ausserdem stark auf<br />
die Querschnittsaufgaben (in Hermes Submodelle genannt) wie <strong>Projektmanagement</strong><br />
(Projektsteuerung), Qualitätssicherung, Risikomanagement, Konfigurationsmanagement<br />
und Projektmarketing (Projektkommunikation) ein.<br />
Insgesamt betrachtet handelt sich es bei HERMES um einen sehr mächtigen und detaillierten<br />
Ansatz. Durch seinen generischen Charakter lässt er sich vielfältig einsetzen,<br />
allerdings ist für den konkreten Einsatz ein relativ hoher Aufwand für das Tailoring<br />
notwendig.<br />
2.3.2 PRINCE2<br />
PRINCE2 ist ein Ansatz, der Management, Steuerung und Organisation eines Projekts<br />
behandelt. Er wird vom Office of Government Commerce (OGC) herausgegeben. Die<br />
neueste Überarbeitung stammt aus dem Jahr 2009. Deren Ursprung geht allerdings bis<br />
ins Jahr 1975 zurück, wo der erste Vorläufer von PRINCE2 unter dem Namen<br />
PROMPT veröffentlicht wurde. Das Akronym PRINCE steht für „Projects IN Controlled<br />
Environments“.<br />
Das Fundament von PRINCE2 bilden sieben Grundprinzipien 221 , die erfüllt sein müssen,<br />
damit ein Projekt nach diesem Ansatz abgewickelt werden kann: Fortlaufende<br />
geschäftliche Rechtfertigung, Lernen aus Erfahrung, Definierte Rollen und Verantwortlichkeiten,<br />
Steuern über Managementphasen, Steuern nach dem Ausnahmeprinzip,<br />
Produktorientierung, und Anpassung an die Projektumgebung.<br />
221 Vgl. im Folgenden Profeo Ltd. 2010a.
44 Konzeptionelle Grundlagen<br />
Neben den Grundprinzipien werden von PRINCE2 sieben Themen definiert. Diese<br />
beschreiben Kompetenzen und Verfahren, die in den verschiedenen Prozessen im Projekt<br />
immer wieder zur Anwendung kommen 222 : Business Case, Organisation, Qualität,<br />
Pläne, Risiken, Änderungen und Fortschritt.<br />
Das Prozessmodell von PRINCE2 besteht aus sieben Hauptprozessen, die jeweils aus<br />
Subprozessen bestehen und aus zwei Blickwinkeln, dem zeitlichen Aspekt und der<br />
Managementebene, betrachtet werden 223 . Ursprünglich waren acht Prozesse vorgesehen,<br />
in der neusten Version von PRINCE2 aus dem Jahr 2009 wurde jedoch der Prozess<br />
„Planung“ gestrichen. Somit werden folgende Prozesse behandelt 224 :<br />
Vorbereiten des Projekts: Ziel dieses Prozesses ist es zu identifizieren, ob sich ein Projekt<br />
für vorliegenden Fall lohnt bzw. ob es machbar ist. Der Prozess ist also schon vor<br />
dem eigentlichen Projektbeginn zu durchlaufen.<br />
Lenken des Projekts: Das Lenken des Projekts ist durch die Funktion des Lenkungsausschusses<br />
definiert. Dieser ist für das gesamte Projekt verantwortlich und wird regelmässig<br />
durch die Projektleitung mit Statusberichten versorgt. Typischerweise ist<br />
der Lenkungsausschuss nur an den Phasenübergängen involviert und ergibt die Freigabe<br />
für die nächste Phase. Wenn jedoch aufgrund des Grundprinzips „Ausnahmeprinzip“<br />
eine Toleranzüberschreitung vorliegt, wird der Lenkungsausschuss eingebunden.<br />
Initiieren des Projekts: Mit der Initiierung des Projekts wird dessen Grundlage geschaffen.<br />
Es wird den Stakeholdern ein klares Bild darüber vermittelt, was das Ziel des<br />
Projekts ist und welche Arbeiten im Projekt geplant sind. Ziel ist es, die finanziellen<br />
Mittel für das Projekt zu generieren. Dafür werden verschiedene Dokumente wie<br />
bspw. die Risikomanagementstrategie, die Qualitätsmanagementstrategie, die Kommunikationsmanagementstrategie,<br />
der Business Case oder der Projektplan erstellt.<br />
Steuern einer Projektphase: Dieser Prozess beschreibt die tägliche Arbeit des <strong>Projektmanagement</strong>s,<br />
d.h. es werden Arbeiten zugewiesen, Fortschrittsberichte erstellt oder<br />
Korrekturmassnahmen eingeleitet.<br />
Managen der Produktlieferung: Getreu dem Prinzip der „Produktorientierung“ wird in<br />
diesem Prozess die eigentliche Produkterstellung geregelt. Dabei geht es darum, Arbeitspakete<br />
anzunehmen, auszuführen und abzuliefern. Ein Produkt bei PRINCE2 sind<br />
sämtliche Projektergebnisse, also sowohl materielle als auch immaterielle.<br />
222 Vgl. im Folgenden Profeo Ltd. 2010c.<br />
223 Vgl. im Folgenden Profeo Ltd. 2010b.<br />
224 Vgl. im Folgenden Köhler 2006, S. 127ff.
Konzeptionelle Grundlagen 45<br />
Managen von Projektphasenübergängen: Basierend auf dem Grundprinzip „Steuern<br />
über Managementphasen“ wird jeweils am Ende jeder Phase die neue vorbereitet.<br />
Hierzu werden Informationen zusammengestellt, die für die Freigabe der aktuellen<br />
Phase benötigt werden.<br />
Abschliessen eines Projekts: Im Rahmen des Projektabschluss werden sämtliche Aktivitäten,<br />
die für den Abschluss des Projekts notwendig sind, durchgeführt. Hierzu gehören<br />
bspw. die Übergabe des fertigen Produkts, die Bewertung des Projekts und die<br />
Empfehlung an den Lenkungsausschuss, das Projekt abzuschliessen.<br />
Die Rollen in PRINCE2 sind vor allem auf der Ebene des <strong>Projektmanagement</strong>s geregelt.<br />
Es werden Rollen in den Bereichen Kunde, wie bspw. die Kundenvertretung, die<br />
den Vorsitz des Lenkungsausschusses innehat, Hauptnutzende und Hauptlieferanten 225<br />
definiert. Die Projektleitung wird vom Lenkungsausschuss ernannt und führt das Projekt<br />
operativ. Bezüglich des Teams werden keine Vorgaben gemacht.<br />
PRINCE2 sieht eine Vielzahl von Ergebnissen vor, die entlang der Prozesse definiert<br />
sind 226 . Diese sind relativ grobgranular und gehen wenig auf konkrete Projektinhalte<br />
ein.<br />
Insgesamt betrachtet ist PRINCE2 ein sehr mächtiger und detaillierter Ansatz. Durch<br />
seinen generischen Charakter und die grobgranulare Strukturierung lässt er sich vielfältig<br />
einsetzen, allerdings ist für den konkreten Einsatz ein relativ hoher Aufwand für<br />
das Tailoring notwendig. Er bietet aber eine prozessorientierte Schritt-für-Schritt-<br />
Anleitung, wie in Projekten vorgegangen werden muss, damit keine wichtigen Aspekte<br />
vergessen werden. Dies ist auch der Grund, warum sich der Ansatz in Grossbritannien<br />
zum De-facto-Standard entwickelt hat und derzeit in mehr als 50 Ländern angewendet<br />
wird 227 .<br />
2.3.3 Guide to the Project Management Body of Knowledge (PMBoK Guide)<br />
Unter dem Namen „Guide to the Project Management Body of Knowledge“ wird der<br />
PMBoK Guide vom PMI mittlerweile in der vierten Auflage publiziert. Erstmals wurde<br />
der Ansatz 1987 veröffentlicht. International ist er der am häufigsten verwendete<br />
Standard 228 . Es handelt sich dabei allerdings weniger um eine <strong>Projektmanagement</strong>-<br />
225 Vgl. im Folgenden ILX Group 2012; Köhler 2006, S. 116ff.<br />
226 Vgl. Köhler 2006, S. 121ff.<br />
227 Vgl. Bergmann, Garrecht 2008, S. 210.<br />
228 Vgl. Bergmann, Garrecht 2008, S. 210.
46 Konzeptionelle Grundlagen<br />
Methode im klassischen Sinne. Vielmehr bietet der PMBoK Guide einen Standard mit<br />
gesammelten Best-Practices des <strong>Projektmanagement</strong> 229 .<br />
Der Ansatz ist prozessorientiert aufgebaut, d.h. es werden in fünf Prozessgruppen insgesamt<br />
42 Prozesse definiert, die in einem Projekt durchlaufen werden 230 :<br />
Initiierung 231 : Diese Gruppe beinhaltet Prozesse, die der formalen Autorisierung des<br />
Projekts dienen wie bspw. die Erstellung des Projektauftrags.<br />
Planung 232 : Die Planung beinhaltet die Festlegung des Projektumfangs, den <strong>Projektmanagement</strong>plan<br />
im Rahmen dessen die Planung der Wissensgebiete behandelt wird,<br />
sowie die Planung der Durchführung des Projekts mit sämtlichen Aspekten wie Projektstrukturplan,<br />
Kostenplan, Terminplan, Risikoplan, etc.<br />
Ausführung 233 : Diese Gruppe ist die eigentliche Erstellung des Ergebnisses des Projekts.<br />
Hier wird sichergestellt, dass das Projekt wie geplant durchgeführt wird.<br />
Steuerung und Monitoring 234 : In dieser Gruppe werden Prozesse vereinigt, die sich mit<br />
der Steuerung des Projekts und dessen Monitoring auseinandersetzen. Dabei wird auf<br />
dem in der Planung erstellten <strong>Projektmanagement</strong>plan aufgebaut. Zu den Prozessen<br />
dieser Gruppe gehören, sofern erforderlich, auch die Planung und Einleitung von Korrekturmassnahmen.<br />
Abschluss 235 : Die beiden Prozesse, die sich mit dem Projektabschluss beschäftigen<br />
sind die Vertragsbeendigung insbesondere mit Lieferanten und Kunden sowie der eigentliche<br />
formale Projektabschluss.<br />
Den eigentlichen Schwerpunkt des PMBoK Guide bilden die Wissensgebiete. Die insgesamt<br />
neun Wissensgebiete decken sämtliche <strong>Projektmanagement</strong>aktivitäten in einem<br />
Projekt ab. Sie basieren auf der Erfahrung aus den Projekten der Mitglieder des<br />
PMI 236 . Die 42 Prozesse des PMBoK Guides werden, gruppiert in die fünf Prozessgruppen,<br />
den jeweiligen Wissensgebieten zugeordnet, so dass aufgrund der Zuordnung<br />
für jeden der Prozesse ein Blickwinkel nach dessen Prozessgruppe und den Wissens-<br />
229 Vgl. Ó Conchúir 2011, S. 13f.; Project Management Institute 2008, S. 3.<br />
230 Vgl. Project Management Institute 2008, S. 37ff.<br />
231 Vgl. Project Management Institute 2008, S. 44ff.<br />
232 Vgl. Project Management Institute 2008, S. 46ff.<br />
233 Vgl. Project Management Institute 2008, S. 55ff.<br />
234 Vgl. Project Management Institute 2008, S. 59ff.<br />
235 Vgl. Project Management Institute 2008, S. 64ff.<br />
236 Vgl. Ó Conchúir 2011, S. 29.
Konzeptionelle Grundlagen 47<br />
gebieten erreicht wird 237 . Die neun Wissensgebiete des PMBoK Guides werden im<br />
Folgenden kurz beschrieben:<br />
Integrationsmanagement 238 : Das Integrationsmanagement umfasst Aktivitäten und<br />
Aufgaben, die der Integration der einzelnen Phasen im Projekt dienen. Es geht dabei<br />
insbesondere um die Sicherstellung des Zusammenspiels der einzelnen Phasen und um<br />
den Blick für das Gesamtprojekt.<br />
Scopemanagement 239 : Das Scopemanagement beinhaltet die Sicherstellung der Einhaltung<br />
des für das Projekt definierten Umfangs. Dabei geht es in erster Linie darum zu<br />
definieren und steuern, was in das Projekt mit aufgenommen wird und was ausgeschlossen<br />
wird.<br />
Zeitmanagement 240 : Im Rahmen des Zeitmanagements wird sichergestellt, dass die<br />
Projektgesamtlaufzeit aber auch die Laufzeit der einzelnen Teilprojekte bzw. im vorliegenden<br />
Fall Sprints, eingehalten werden.<br />
Kostenmanagement 241 : Zu den Aufgaben des Kostenmanagements gehören insbesondere<br />
die Budgetkontrolle und -anpassung. Bei Bedarf müssen Gegenmassnahmen eingeleitet<br />
werden.<br />
Qualitätsmanagement 242 : Das Qualitätsmanagement zielt auf die Einhaltung der vom<br />
Kunden geforderten Qualität der Teilergebnisse und des Endergebnisses ab. Soweit<br />
notwendig, wird im Rahmen des Qualitätsmanagements auch die erforderliche Dokumentation<br />
sichergestellt.<br />
Personalmanagement 243 : Um die notwendigen personellen Ressourcen zur Verfügung<br />
stellen zu können, braucht es Prozesse und Aufgaben, die sich dem Personalmanagement<br />
annehmen. Hierzu gehören auch die adäquate Zusammenstellung des Projektteams<br />
und die Besetzung der Rollen und die Verteilung der Verantwortlichkeiten innerhalb<br />
des Projekts.<br />
Kommunikationsmanagement 244 : Im Rahmen des Kommunikationsmanagements werden<br />
die Projektergebnisse und das Projekt an sich adäquat gegenüber sämtlichen rele-<br />
237 Vgl. Project Management Institute 2008, S. 43.<br />
238 Vgl. Project Management Institute 2008, S. 71ff.<br />
239 Vgl. Project Management Institute 2008, S. 103ff.<br />
240 Vgl. Project Management Institute 2008, S. 129ff.<br />
241 Vgl. Project Management Institute 2008, S. 165ff.<br />
242 Vgl. Project Management Institute 2008, S. 189ff.<br />
243 Vgl. Project Management Institute 2008, S. 215ff.<br />
244 Vgl. Project Management Institute 2008, S. 243ff.
48 Konzeptionelle Grundlagen<br />
vanten Stakeholdern und insbesondere gegenüber den Kunden und Auftraggebern<br />
kommuniziert. Das Kommunikationsmanagement zielt darauf ab, das Projekt und dessen<br />
Ziel sichtbar zu machen.<br />
Risikomanagement 245 : Im Rahmen des Risikomanagements werden über die gesamte<br />
Laufzeit des Projekts Risiken identifiziert, überwacht und entsprechende Eintrittswahrscheinlichkeiten<br />
definiert. Ausserdem werden geeignete Massnahmen im Falle<br />
des Eintreffens eines Risikos definiert.<br />
Beschaffungsmanagement 246 : Sämtliche im Rahmen des Projekts benötigten Ressourcen<br />
von IT-Infrastruktur über Softwarebeschaffungen bis hin zu Büromaterial werden<br />
durch das Beschaffungsmanagement gesteuert und beschafft. Zum Beschaffungsmanagement<br />
gehört auch die Verwaltung sämtlicher Verträge gegenüber Dritten während<br />
der Projektlaufzeit.<br />
Bezüglich der Rollen, die im Wissensgebiet „Personalmanagement“ abgehandelt werden,<br />
gibt der PMBoK Guide keine konkreten Vorgaben. Es werden eher generelle Angaben<br />
zum Akquisitionsprozess des Projektteams, der Planung, der Pflege und Entwicklung<br />
gemacht 247 .<br />
Der PMBoK Guide definiert für jeden der 42 Prozesse jeweils Inputs, Werkzeuge und<br />
Techniken für die Ausführung, sowie Outputs. Diese Outputs sind jeweils die Ergebnisse<br />
aus dem Prozess.<br />
Insgesamt betrachtet bietet der PMBoK Guide ein Rahmenwerk mit Best-Practices für<br />
die Projektabwicklung. Aufgrund seiner Verbreitung und seiner laufenden Weiterentwicklung<br />
basierend auf den praktischen Erfahrungen vieler Projektmanager, deckt er<br />
die wesentlichen Aspekte des <strong>Projektmanagement</strong>s ab. In vielen Bereichen ist er jedoch<br />
eher generisch gehalten und lässt sich so zwar vielfältig einsetzen, allerdings ist<br />
für den konkreten Einsatz ein relativ hoher Aufwand für die Anpassung an den Unternehmenskontext<br />
erforderlich. Der PMBoK Guide kann gut als Ergänzung zu anderen<br />
Vorgehen eingesetzt werden.<br />
2.3.4 Rational Unified Process (RUP)<br />
Der Rational Unified Process (RUP) ist ein phasenorientierter, inkrementeller und iterativer<br />
Ansatz für Softwareentwicklungsprojekte. Er ist also ein speziell auf IT-<br />
245 Vgl. Project Management Institute 2008, S. 273ff.<br />
246 Vgl. Project Management Institute 2008, S. 313ff.<br />
247 Vgl. Project Management Institute 2008, S. 215ff.
Konzeptionelle Grundlagen 49<br />
Projekte ausgerichteter Ansatz. Der RUP ist ein kommerzielles Produkt der Firma Rational<br />
Software, die zum IBM-Konzern gehört 248 .<br />
Der RUP basiert auf sechs grundlegenden Prinzipien für die effektive Entwicklung<br />
von Software. Diese nennen sich Best-Practices, da sie sich als erfolgreich erwiesen<br />
haben 249 :<br />
Iterative Softwareentwicklung: Durch iterative Softwareentwicklung können im Gegensatz<br />
zu sequentiellen Vorgehen wie bspw. dem Wasserfall-Ansatz, auch zu einem<br />
späteren Zeitpunkt Änderungen berücksichtigt werden.<br />
Anforderungsmanagement: Anforderungen sind die Essenz der Entwicklung einer<br />
Software. Sie müssen systematisch erkannt, organisiert und implementiert werden.<br />
Somit kann die Qualität verbessert und die Kundenzufriedenheit erhöht werden.<br />
Komponentenbasierte Architektur: Einerseits können durch eine komponentenbasierte<br />
Architektur einer Software die einzelnen Module besser wiederverwendet werden.<br />
Andererseits ermöglicht dieses Vorgehen auch, dass Module parallel entwickelt und<br />
getestet werden können.<br />
Visuelle Modellierung der Software: Um die Struktur und das Verhalten von Architekturen<br />
und Softwarekomponenten zu verstehen, wird eine visuelle Modellierung vorgeschlagen.<br />
Diese ermöglicht ein besseres Problemverständnis und durch standardisierte<br />
Modellierungssprachen einen besseren Austausch zwischen den Projektbeteiligten.<br />
Häufig wird hierzu die Unified Modeling Language (UML) 250 verwendet. Diese Modellierungssprache<br />
wurde auch von Rational Software entwickelt und bildete damals<br />
die Grundlage für die Entwicklung des RUP.<br />
Projektbegleitendes Qualitätsmanagement: Institutionalisiertes <strong>Projektmanagement</strong><br />
während der gesamten Projektlaufzeit erhöht die Qualität des Produkts und hilft mögliche<br />
Probleme frühzeitig zu erkennen.<br />
Kontrolliertes Änderungsmanagement: Um Anforderungen zu verwalten und eine Versionierung<br />
der Entwicklungsstände zu realisieren, wird dem Projekt ein kontrolliertes<br />
Anforderungsmanagement zugrunde gelegt. Dies erhöht die Nachvollziehbarkeit und<br />
damit die Transparenz.<br />
248 Vgl. Rational Software Inc. 1998.<br />
249 Vgl. auch im Folgenden Rational Software Inc. 1998, S. 1f.<br />
250 Vgl. Oestereich 2005.
Inhaltliche Organisation<br />
50 Konzeptionelle Grundlagen<br />
Zeitliche Organisation<br />
Engineering Workflows<br />
Phasen<br />
Inception Elaboration Constrution Transition<br />
Business Modeling<br />
Requirements<br />
Analysis & Design<br />
Implementation<br />
Test<br />
Deployment<br />
Supporting Workflows<br />
Configuration & Change Management<br />
Project Management<br />
Environment<br />
Initial Elab1 Elab2 Const1 Const2 Const3 Tran1 Tran2<br />
Iterationen<br />
Abbildung 14: Vorgehensmodell des Rational Unified Process (RUP) 251<br />
Das Vorgehensmodell des RUP gliedert sich in vier grundlegende Phasen (vgl. Abbildung<br />
14) die jeweils mehrere Iterationen durchlaufen können. Diese Phasen widerspiegeln<br />
die zeitliche Komponente des Projekts und werden als „Dynamische Aspekte“<br />
bezeichnet 252 :<br />
Inception (Beginn): Zu Beginn des Projekts werden die wichtigsten Rahmenbedingungen<br />
festgelegt. Der Schwerpunkt liegt dabei auf dem Business Modeling sowie den<br />
grundlegenden Anforderungen und Rahmenbedingungen des Projekts.<br />
Elaboration (Entwurf und Design): In dieser Phase werden die Anforderungen spezifiziert,<br />
die Architektur festgelegt sowie die geplante Softwarelösung entworfen. Es werden<br />
ausserdem die jeweiligen Iterationen für die Implementierungsphase festgelegt.<br />
Construction (Implementierung): Die Konstruktion dient der eigentlichen Implementierung<br />
der Lösung. Basierend auf der definierten Architektur und den Anforderungen<br />
werden die jeweiligen Komponenten sowohl umgesetzt als auch getestet.<br />
Transition (Auslieferung): Diese Phase dient der Auslieferung und Installation des im<br />
Projekt erstellten Produkts. Der Schwerpunkt dieser Phase liegt dabei auf der Auslieferung<br />
an den Kunden.<br />
251 In Anlehnung an Rational Software Inc. 1998, S. 3.<br />
252 Vgl. im Folgenden Rational Software Inc. 1998, S. 3ff.; Schatten et al. 2010, S. 58ff.
Konzeptionelle Grundlagen 51<br />
Neben den zeitlichen Aspekten gibt es in RUP die inhaltliche Dimension. Diese wird<br />
als „Statische Dimension“ bezeichnet. Sie beinhaltet eine Reihe von Vorgaben und<br />
Richtlinien, die als Disziplinen und Workflows bezeichnet werden. Sie verteilen sich<br />
jeweils in unterschiedlicher Intensität auf die einzelnen Phasen der zeitlichen Dimension<br />
(vgl. Abbildung 14). Es existieren sechs „Engineering Workflows“ und drei<br />
„Supporting Workflows“ 253 :<br />
Engineering Workflows:<br />
Business Modeling: Das Business Modeling ermöglicht das einheitliche Verständnis<br />
aller beteiligten Stakeholder hinsichtlich der zu erstellenden Lösung. Durch UML wird<br />
dieser Workflow unterstützt.<br />
Requirements: In diesem Workflow werden die Anforderungen detailliert erhoben. Sie<br />
stellen die Grundlage für das zu erstellende Produkt dar.<br />
Analysis & Design: Basierend auf den erhobenen Anforderungen und dem Business<br />
Modeling werden in diesem Workflow sowohl die zugrunde liegende Architektur, wie<br />
auch die zentralen Software-Module entworfen.<br />
Implementation: Dieser Workflow dient der eigentlichen Implementierung, dem Testen<br />
und der Integration der Module in das Gesamtsystem.<br />
Test: Zur Qualitätssicherung werden in diesem Workflow die entwickelten Module<br />
getestet. Aufgrund der zentralen Rolle des Testens ist in RUP dieser Workflow eigenständig<br />
und wird nicht in die Implementierung integriert. Die Erstellung von Testfällen<br />
geschieht bereits in einem frühen Stadium der Entwicklung.<br />
Deployment: Dieser Workflow regelt den Ablauf der Fertigstellung und Auslieferung<br />
des Produkts an den Kunden.<br />
Supporting Workflows:<br />
Configuration & Change Management: Im Rahmen der Configuration und des Change<br />
Managements wird die Organisation des Versions- und Konfigurationsmanagements<br />
definiert. Es wird ausserdem geregelt, wie mit Änderungsanträgen umzugehen ist.<br />
Project Management: Das <strong>Projektmanagement</strong> ist eine übergreifende Aktivität, die<br />
sich mit der Planung und Koordination des Projekts befasst. Dabei werden Aufgaben<br />
der Ressourcenplanung und der Qualitätssicherung ausgeführt. Das <strong>Projektmanagement</strong><br />
ist ausserdem zuständig für die Planung zusätzlicher Iterationen.<br />
253 Vgl. im Folgenden Rational Software Inc. 1998, S. 10ff.; Schatten et al. 2010, S. 60ff.
52 Konzeptionelle Grundlagen<br />
Environment: Dieser Workflow dient der Regelung der Ressourcen, die dem Entwicklungsteam<br />
zur Verfügung stehen.<br />
Der RUP definiert eine Vielzahl von Rollen, die nach den einzelnen Disziplinen geordnet<br />
sind. Die Rollen sind dabei vorwiegend technischer und implementierungsnaher<br />
Natur 254 . Die Ergebnisse des RUP werden entlang der zeitlichen Dimension definiert.<br />
Es werden für jede Phase Ergebnisse definiert, die mithilfe der Workflows und den<br />
entsprechenden Rollen erstellt werden.<br />
Der RUP ist ein spezifisch auf IT-Projekte ausgelegter Ansatz, der sich durch umfassende<br />
Prozessdefinitionen kennzeichnet. Er bietet sich aufgrund seiner Mächtigkeit vor<br />
allem für Grossprojekte an. Die enge Verzahnung mit UML unterstützt die Abwicklung<br />
von Projekten.<br />
2.3.5 V-Modell<br />
Wie auch der RUP ist das V-Modell ein speziell auf die IT zugeschnittenes Vorgehensmodell<br />
für die Planung und Durchführung von Projekten. Der Ansatz bietet konkrete<br />
Vorgaben, standardisierte Vorgehensweisen und dazugehörige Ergebnisse und<br />
Rollen. Das V-Modell ist in der neusten Version (V-Modell XT) aus dem Jahr 2006<br />
eine Weiterentwicklung des 1997 erstmals veröffentlichten V-Modells 97 255 . Heute ist<br />
das V-Modell der Standardentwicklungsansatz für IT-Projekte der öffentlichen Hand<br />
in Deutschland 256 .<br />
Das Vorgehensmodell des V-Modells orientiert sich am Wasserfall-Ansatz und basiert<br />
auf dem Software-Lebenszyklus. Es umfasst die wesentlichen Schritte von der Konzeptphase<br />
über Planung, Entwurf, Design und Implementierung bis zu Test, Wartung<br />
und Weiterentwicklung. Dabei wird zwischen „konstruktiven“ und „integrativen“ Phasen<br />
unterschieden. Jeder Konstruktionsphase wird eine Integrations- und Testphase<br />
gegenübergestellt. Dadurch ergeben sich unterschiedlich detaillierte Sichten auf das<br />
IT-Projekt 257 (vgl. Abbildung 15).<br />
Wie in Abbildung 15 dargestellt, zeigt sich durch die Anordnung der konstruktiven<br />
und integrativen Phasen das charakteristische „V“. Die Phasen der Konstruktion gehen<br />
von einer Idee bzw. einem Konzept aus und spezifizieren diese mit immer höherem<br />
Detaillierungsgrad bis auf Komponentenebene (linke Seite). Nach der Umsetzung der<br />
254 Vgl. Crain 2005.<br />
255 Vgl. IABG mbH 2006a.<br />
256 Vgl. IABG mbH 2011.<br />
257 Vgl. Schatten et al. 2010, S. 49ff.
Detaillierungsgrad<br />
Konzeptionelle Grundlagen 53<br />
Komponenten wird das Gesamtsystem schrittweise zusammengebaut, bis das Produkt<br />
vollständig umgesetzt ist. Dabei wird das System implementiert, integriert und getestet<br />
(rechte Seite).<br />
Zeit<br />
Konzept und<br />
Idee<br />
Betrieb und<br />
Wartung<br />
System-, Akzeptanz- und Abnahmetest<br />
Anwendersicht<br />
Installiertes<br />
System<br />
Systemdesign<br />
Integrationstest<br />
Architekturtest<br />
Getestetes<br />
System<br />
Systemspezifikation<br />
Komponentenspezifikation<br />
Komponententest<br />
Implementierungssicht<br />
Getestete<br />
Komponenten<br />
Konstruktive Phasen<br />
Integrative Phasen<br />
Abbildung 15: Stark abstrahierte Darstellung des V-Modells 258<br />
Die horizontale Gliederung des V-Modells ermöglicht die Projektbetrachtung aus unterschiedlichen<br />
Sichten und stellt ausserdem den Zusammenhang zwischen den konstruktiven<br />
und integrativen Phasen her. Die horizontalen Sichten teilen sich in die<br />
„Anwendersicht“, die „Architektursicht“ und die „Implementierungssicht“ 259 auf:<br />
Anwendersicht: Die Anwendersicht betrachtet das Gesamtsystem aus Sicht des Kunden<br />
und der Geschäftsprozesse. Ziel ist es, die Anforderungen an das Gesamtsystem zu<br />
definieren und dessen Realisierung zu planen. Gleichzeitig werden für die rechte Seite<br />
Akzeptanzanforderungen definiert, die in Akzeptanz- und Abnahmetests nach der Umsetzung<br />
durchgeführt werden.<br />
Architektursicht: Der Fokus dieser Sicht liegt auf der Frage, wie die spezifizierten Anforderungen<br />
umgesetzt werden. Dabei wird die grundlegende Architektur, das Design,<br />
die Modularisierung des Gesamtsystems, aber auch das Zusammenspiel der einzelnen<br />
Komponenten definiert. Auf der rechten Seite des Modells stehen dem gegenüber konkret<br />
getestete und integrierte Softwaremodule. Es werden Integrationstests definiert,<br />
die auf die Architektur und das Design abzielen.<br />
258 In Anlehnung an Schatten et al. 2010, S. 50; Scholz 2005, S. 203.<br />
259 Vgl. im Folgenden Schatten et al. 2010, S. 50f.
54 Konzeptionelle Grundlagen<br />
Implementierungssicht: Die Implementierungssicht hat den höchsten Detaillierungsgrad<br />
und wird durch eine weitere Verfeinerung der Entwurfs- und Designdokumente<br />
erreicht. Sie zeigt die konkret spezifizierten Komponenten und stellt die Ausgangsbasis<br />
für die Umsetzung dar. Die rechte Seite widmet sich dem Testen der implementierten<br />
Komponenten.<br />
Das V-Modell bietet Vorgehensweisen, Methoden und Werkzeuganforderungen für<br />
die vier Submodelle „System Erstellung“ (SE), „Qualitätssicherung“ (QS), „<strong>Projektmanagement</strong>“<br />
(PM) und „Konfigurationsmanagement“ (KM). Auf allen Ebenen des in<br />
Abbildung 15 dargestellten Vorgehensmodells werden die entsprechenden Submodelle<br />
und konkret dazugehörige Aktivitäten definiert 260 .<br />
Das V-Modell definiert eine Vielzahl von Rollen, die jeweils den entsprechenden<br />
Submodellen zugeordnet sind. Dabei zwischen „Manager“, „verantwortlich“ und<br />
„durchführend“ unterschieden 261 .<br />
Hinsichtlich der Ergebnisse (im V-Modell Produkte genannt) sind diese hierarchisch<br />
strukturiert. Dabei werden verschiedene Disziplinen jeweils für das Projekt an sich, für<br />
die Entwicklung und für die Organisation definiert, denen die zu erstellenden Ergebnisse<br />
untergliedert sind 262 .<br />
Das V-Modell zeichnet sich durch seine klare Struktur aus und ist auf IT-Projekte ausgelegt.<br />
Es eignet sich vor allem für klar definierte Projekte mit stabilen und vollständigen<br />
Anforderungen. Der Ansatz ist sehr mächtig und eignet sich vor allem für grössere<br />
Vorhaben. In der neusten Ausgabe des V-Modells (V-Modell XT) wird der Anpassung<br />
auf das spezifische Projekt mehr Bedeutung zugemessen. Das XT steht demnach auch<br />
für „extreme tailoring“.<br />
2.3.6 Zusammenfassende Betrachtung<br />
Allen diesen Ansätzen gemeinsam ist deren sequentielle Orientierung nach Phasen.<br />
Der RUP bietet zwar einen gewissen Grad an Iterativität, dennoch orientiert er sich an<br />
den oben genannten Phasen. Insbesondere um den genannten Gründen für das Scheitern<br />
von IT-Projekten entgegen zu wirken, aber auch aufgrund des volatileren Umfelds,<br />
in dem sich Projekte heute befinden, haben sich in jüngerer Zeit Ansätze etabliert,<br />
die dieser schlechteren Planbarkeit von Projekten begegnen. Diese sind gekenn-<br />
260 Vgl. IABG mbH 2006d; Scholz 2005, S. 203f.<br />
261 Vgl. IABG mbH 2006b.<br />
262 Vgl. IABG mbH 2006c.
Konzeptionelle Grundlagen 55<br />
zeichnet durch mehr Flexibilität, Anpassbarkeit und Dynamik 263 . Zwei der heute am<br />
weitesten verbreiteten Ansätze sind Scrum und Kanban. Diese Ansätze gehören zur<br />
Familie der agilen Ansätze. Sie werden im Rahmen von Abschnitt 2.4 detaillierter beschrieben.<br />
2.4 Agile Entwicklung<br />
Der Begriff “Software Engineering” wurde 1968 im Rahmen der NATO-Konferenz in<br />
Garmisch-Partenkirchen geprägt. Ziel war es, als Reaktion auf die in die Krise gekommene<br />
Softwareentwicklung (Softwarekrise) ein ingenieurmässiges Vorgehen bei<br />
der Entwicklung von Software und Systemen zu etablieren. Daraus entwickelten sich<br />
immer aufwändigere, umfangreichere und mächtigere Handlungsanweisungen. wie<br />
Software entwickelt werden sollte 264 . Durch das ingenieurmässige Vorgehen wurden<br />
die Entwicklungsprozesse zwar strukturierter, blieben aufgrund ihrer sequentiellen<br />
Orientierung aber starr und wenig flexibel. Hinzu kam, dass Softwareprojekte zunehmend<br />
umfangreicher, komplexer und übergreifender wurden.<br />
Ein grundsätzliches Problem bei der Softwareentwicklung beschreiben BLEEK UND<br />
WOLF 265 : Das Ziel eines Softwareentwicklungsprojekts ist es, ein einsetzbares Softwaresystem<br />
zu entwickeln, welches bestimmten, projektspezifischen Anforderungen<br />
genügt. Die Anforderungen dafür resultieren aus Geschäftszielen. Die Transformation<br />
von Geschäftszielen über Anforderungen zum einsetzbaren Softwaresystem ist demnach<br />
der Prozess eines Softwareentwicklungsprojekts. Natürlich muss auch überprüft<br />
werden, ob das System die Anforderungen erfüllt. Typischerweise liegt die Kompetenz<br />
der Beurteilung bei den Fachbereichsvertretungen bzw. beim Kunden. Diese Beurteilung<br />
sollte allerdings nicht erst am fertigen Softwaresystem zu Projektende erfolgen,<br />
da dann Änderungen und Anpassungen nur noch mit viel Aufwand realisiert werden<br />
können.<br />
Neben dieser beschriebenen Herausforderung existieren aber noch weitere Problembereiche<br />
klassischer Softwareentwicklungen, die im Rahmen von AIS-Entwicklung noch<br />
verstärkt auftreten 266 . So unterliegen IS einem kontinuierlichen, immer schnelllebigeren<br />
Wandel 267 . Ausserdem ändern sich Anforderungen stetig in IS-, vor allem aber in<br />
AIS-Projekten, aufgrund sich ändernder Rahmenbedingungen wie bspw. regulatori-<br />
263 Vgl. Kuster et al. 2008, S. 32f.<br />
264 Vgl. Hruschka et al. 2009, S. 1.<br />
265 Vgl. Bleek, Wolf 2008, S. 8ff.<br />
266 Vgl. Abschnitt 1.1.<br />
267 Vgl. Chamoni, Gluchowski 2006; Hughes 2008.
56 Konzeptionelle Grundlagen<br />
schen Vorschriften. Hinzu kommt, dass zu Beginn eines Softwareentwicklungsprojekts,<br />
insb. im AIS-Bereich, der Kunde nicht in der Lage ist, seine Anforderungen<br />
adäquat zu spezifizieren bzw. sich nicht über die Möglichkeiten, die sich durch IS ergeben,<br />
bewusst ist. Schlussendlich zeigt sich, dass der Kunde heute nicht mehr zufrieden<br />
ist, wenn er erst am Schluss des Projekts brauchbare und nutzbare Ergebnisse bekommt.<br />
Vielmehr muss er regelmässig nutzbare Produktinkremente geliefert bekommen<br />
268 .<br />
Solche sequentielle, mächtige und detaillierte Methoden, wie oben beschrieben, haben<br />
jedoch durchaus noch ihre Daseinsberechtigung, nämlich in Projekten mit stabilen und<br />
vorab spezifizierbaren Anforderungen mit entsprechenden Rahmenbedingungen. Zunehmend<br />
werden diese Projekte allerdings aufgrund der genannten Voraussetzungen<br />
seltener 269 .<br />
Aus diesem Grund entstanden Anfang der 1990er Jahre erste grundlegende Ideen und<br />
erste Ansätze, wie Softwareentwicklungsprozesse effizienter und effektiver, vor allem<br />
aber den genannten Begebenheiten entsprechend gestaltet werden konnten 270 . Zu Beginn<br />
des Jahres 2001 trafen sich 17 führende Softwareentwickler und Methodenforscher<br />
in Utah, um die neuen Ideen zu konzeptualisieren und in einem Manifest festzuhalten.<br />
Daraus resultierte nach heftigen Diskussionen das Agile Manifest der Softwareentwicklung:<br />
Das Agile Manifest der Softwareentwicklung 271<br />
We are uncovering better ways of developing software by doing it and helping others<br />
do it. Through this work we have come to value:<br />
Individuals and interactions over processes and tools<br />
Working software over comprehensive documentation<br />
Customer collaboration over contract negotiation<br />
Responding to change over following a plan<br />
That is, while there is value in the items on the right, we value the items on the left<br />
more.<br />
268 Diese Aussage untermauern die Aussagen aus sämtlichen Fallstudien in Kapitel 5.<br />
269 Vgl. Hotle 2010.<br />
270 Vgl. Scrum (Sutherland 1995) oder extreme Programming nach einem Projekt bei Daimler Chrysler von<br />
1995-2000 (Beck 1999).<br />
271 Vgl. Beck et al. 2001a.
Konzeptionelle Grundlagen 57<br />
Dieses Manifest wurde zusätzlich durch zwölf dahinterliegende Prinzipien weiter detailliert:<br />
Die Prinzipien hinter dem Agilen Manifest 272<br />
(a) Our highest priority is to satisfy the customer through early and continuous delivery<br />
of valuable software.<br />
(b) Welcome changing requirements, even late in development. Agile processes harness<br />
change for the customer's competitive advantage.<br />
(c) Deliver working software frequently, from a couple of weeks to a couple of months,<br />
with a preference to the shorter timescale.<br />
(d) Business people and developers must work together daily throughout the project.<br />
(e) Build projects around motivated individuals. Give them the environment and<br />
support they need, and trust them to get the job done.<br />
(f) The most efficient and effective method of conveying information to and within a<br />
development team is face-to-face conversation.<br />
(g) Working software is the primary measure of progress.<br />
(h) Agile processes promote sustainable development. The sponsors, developers, and<br />
users should be able to maintain a constant pace indefinitely.<br />
(i) Continuous attention to technical excellence and good design enhances agility.<br />
(j) Simplicity – the art of maximizing the amount of work not done – is essential.<br />
(k) The best architectures, requirements, and designs emerge from self-organizing<br />
teams.<br />
(l) At regular intervals, the team reflects on how to become more effective, then tunes<br />
and adjusts its behavior accordingly.<br />
Diese Grundsätze und Prinzipien spiegeln sich auch in den zahlreichen agilen Softwareentwicklungsmethoden<br />
wider 273 . Bekannte Ansätze für diese agile Entwicklung<br />
sind bspw. die Dynamic System Development Method (DSDM) 274 , Extreme Programming<br />
(XP) 275 , Feature-Driven Development (FDD) 276 , Kanban 277 oder Scrum 278<br />
und sind zentraler Gegenstand vorliegender Arbeit. Eine Beschreibung dieser Ansätze<br />
finden sich in den Abschnitten 2.4.1 bis 2.4.5.<br />
272 Vgl. Beck et al. 2001b.<br />
273 Vgl. Dyba, Dingsøyr 2008, S. 3.<br />
274 Vgl. Norton 2007a; Voigt 2004.<br />
275 Vgl. Beck 1999; Bleek, Wolf 2008, S. 137ff.; Norton, Murphy 2007; Wolf, Rook 2009, S. 9ff.; Wolf, Rook<br />
2011, S. 9ff.<br />
276 Vgl. Bleek, Wolf 2008, S. 152ff.; Norton 2007b; Wolf, Rook 2009, S. 17ff.; Wolf, Rook 2011, S. 17ff.<br />
277 Vgl. Anderson 2011; Wolf, Rook 2011, S. 14ff.<br />
278 Vgl. Beedle, Schwaber 2001; Bleek, Wolf 2008, S. 149ff.; Norton 2007d; Pichler 2008; Wolf, Rook 2009, S.<br />
6ff.; Wolf, Rook 2011, S. 6ff.
58 Konzeptionelle Grundlagen<br />
Neben diesen grundlegenden Prämissen und Prinzipien hat BECK in seinem frühen<br />
Werk die Grundwerte agiler Entwicklung festgehalten 279 :<br />
Kommunikation: Die schlank gehaltene Vorgehensweise bedarf einer intensiven direkten<br />
Kommunikation zwischen den Projektbeteiligten. Aber auch die Kommunikation<br />
mit den Kunden muss entsprechend intensiv erfolgen.<br />
Einfachheit: Entwicklungsprojekte, insbesondere für Software, sind im Allgemeinen<br />
komplex. Ziel agiler Entwicklungsmethoden ist es, diese Komplexität, wo immer es<br />
geht, zu reduzieren. Dies bedeutet, dass technisch nur das gebaut werden soll, was<br />
wirklich benötigt wird, organisatorisch so wenig Überbau wie möglich zu generieren<br />
und methodisch so einfach vorzugehen, dass es für alle verständlich und nachvollziehbar<br />
bleibt.<br />
Rückkoppelung: Direkt mit der Kommunikation als Wert zusammenhängend ist die<br />
Rückkoppelung. Durch intensive, unmittelbare Kommunikation entstehen Rückkoppelungen<br />
im Vorgehen, welche eine kontinuierliche Bewertung und Anpassung der Ergebnisse<br />
zur Folge hat.<br />
Mut: Mut bedarf es insbesondere bei der Kommunikation, welche ehrlich, offen und<br />
direkt zwischen den Projektbeteiligten geschehen soll. Gleichzeitig ist es notwendig,<br />
den Mut zu haben, sich aus bestehenden, klassischen Strukturen zu lösen und neue<br />
Wege zu gehen.<br />
Respekt: Respekt zwischen den meist interdisziplinären Projektbeteiligten in der Zusammenarbeit<br />
fördert wiederum die offene Kommunikationskultur und setzt somit die<br />
Basis für erfolgreiche agile Entwicklung.<br />
Mit diesen Werten, Grundsätzen und Prinzipien ist die Grundlage für die fortwährende<br />
Neu- und Weiterentwicklung agiler Methoden geschaffen worden. Der Begriff der<br />
Agilität gibt allerdings immer wieder Anlass zu Diskussionen, sei es bezüglich seiner<br />
Bedeutung aber auch der Abgrenzung gegenüber anderen Konzepten wie bspw. Lean.<br />
Der Begriff „agil“ stammt aus dem Lateinischen „agilis“ leitet sich von „agere“ (tun,<br />
machen, handeln) ab. Agilis bedeutet „von grosser Beweglichkeit zeugend; regsam<br />
und wendig“, bzw. „flink, wendig, beweglich“ 280 . Als agil wird im Allgemeinen jemand<br />
bezeichnet, der körperlich oder geistig wendig oder flink ist. Die agile Entwicklung<br />
greift diese Punkte auf und vertritt das Ziel, angepasst (wendig) vorzugehen und<br />
279 Vgl. Beck 1999; Bleek, Wolf 2008, S. 10ff.<br />
280 Vgl. Duden 1999, S. 99.
Konzeptionelle Grundlagen 59<br />
schnell (flink) vorzeigbare Ergebnisse zu erzielen 281 . Neben der etymologischen Bedeutung<br />
des Begriffs muss dieser auch von anderen Konstrukten wie bspw. Flexibilität<br />
oder dem Lean-Gedanken abgegrenzt werden.<br />
Ausgehend vom Agilitätsbegriff in der Produktionswirtschaft im Rahmen der Betrachtung<br />
von Agilität und Service Orientierten Architekturen (SOA), welche SCHELP UND<br />
WINTER diskutieren, wird Flexibilität als „[…] die Fähigkeit eines Systems verstanden,<br />
sich an erwartete Änderungen anzupassen. Agilität schliesst dagegen auch die<br />
Anpassungsfähigkeit an unerwartete Änderungen mit ein“ 282 . Auf agile Entwicklung<br />
übertragen bedeutet dies, dass auf unvorhergesehene Änderungen der Rahmenbedingungen<br />
oder Anforderungen während der gesamten Projektlaufzeit reagiert werden<br />
kann.<br />
Eine weitere Abgrenzung des Agilitätsbergriffs muss gegenüber dem Lean-Gedanken<br />
vorgenommen werden. Dieser hat seinen Ursprung anfangs der 1990er Jahre im Produktionssystem<br />
von Toyota 283 . Er wird als leichtgewichtig und damit als Gegenteil zu<br />
reguliert und bürokratisch bezeichnet 284 . Die Grundsätze der Lean Production wurden<br />
auf die Softwareentwicklung übertragen und es wurden dafür sieben Richtlinien definiert:<br />
„Verschwendung vermeiden“, „Lernen unterstützen“, „so spät entscheiden wie<br />
möglich“, „so früh ausliefern wie möglich“, „Verantwortung an das Team geben“, „Integrität<br />
einbauen“ und „das Ganze sehen“ 285 . Diese Richtlinien erinnern an die<br />
Grundsätze und Prinzipien der agilen Entwicklung. Der Lean-Gedanke ist jedoch mehr<br />
eine Management-Philosophie als ein Framework für Softwareentwicklung, wie es die<br />
Agilität bietet. Trotzdem sind die Gemeinsamkeiten gross. Das sich bereits früher<br />
etablierte Lean hat die Entwicklung der Agilität stark beeinflusst 286 . Der Hauptunterschied<br />
ist aber deren Herkunft und damit deren Sicht der Welt. Während Lean aus der<br />
Produktion kommt und eine entsprechende Weltanschauung vertritt, kommt Agilität<br />
aus der Theoriebildung 287 . CONBOY identifiziert zudem zwei weitere Unterschiede<br />
zwischen lean und agil. Der erste ist „[…] to be lean is to be good at things you can<br />
control while to be agile is to be good at things you cannot.“ 288 . Der zweite Unter-<br />
281 Vgl. Bleek, Wolf 2008, S. 7.<br />
282 Vgl. Becker 2001, S. 28; Vokurka, Fliedner 1998, S. 166f. zit. in Schelp, Winter 2007, S. 1.<br />
283 Vgl. Taiichi 2005.<br />
284 Vgl. Stober, Hansmann 2010, S. 36.<br />
285 Vgl. Norton 2007c; Poppendieck, Poppendieck 2003; Stober, Hansmann 2010.<br />
286 Vgl. Fowler 2008.<br />
287 Vgl. West 2009.<br />
288 Vgl. Maskell 1996 zit. in Conboy 2009, S. 340.
60 Konzeptionelle Grundlagen<br />
schied ist „[…] a lean [organization] is cost efficient and productive, while an agile<br />
one learns fast, if not initially cost efficient and productive“ 289 .<br />
Zusammenfassend definiert CONBOY Agilität folgendermassen:<br />
Definition von Agilität 290<br />
Agility is „[…] the continual readiness of an ISD 291 method to rapidly or inherently<br />
create change, proactively or reactively embrace change, and learn from change while<br />
contributing to perceived customer value (economy, quality, and simplicity),<br />
through its collective components and relationships with its environment.“<br />
Folgende Abschnitte dienen dazu, eine Übersicht über die meist verbreiteten und wichtigsten<br />
Entwicklungsansätze vorzunehmen. Obschon die beschriebenen Methoden unterschiedlichen<br />
Fokus haben, sind alle aus der Grundidee der Agilität entstanden und<br />
setzen die agilen Werte und Prinzipien in unterschiedlicher Intensität um. Neben einer<br />
Beschreibung der Ansätze wird demnach im Folgenden einerseits der Fokus der Methode<br />
(Entwicklungsperspektive eher auf Mikro- oder Makroebene) und andererseits<br />
der Grad der Umsetzung agiler Werte und Prinzipien herausgestellt. Dies ermöglicht<br />
im Anschluss eine vergleichende Übersicht, aus der sich für die weitere Arbeit entsprechende<br />
Konsequenzen ergeben (vgl. Tabelle 2 und Abbildung 17).<br />
2.4.1 Dynamic System Development Method (DSDM)<br />
DSDM ist ein agiler Ansatz, der sich, ähnlich Scrum, auf das Management von Projekten<br />
fokussiert, jedoch noch stärker auf die Softwareentwicklung eingeht 292 . Er wird<br />
durch das DSDM Konsortium kontrolliert und bietet ein Framework mit den drei<br />
Hauptphasen „Pre-Project“ (Projektinitialisierung und Finanzierung), „Project Life<br />
Cycle“ und „Post-Project“ (Projektabschluss). Die Hauptphase „Project Life Cycle“<br />
wird dabei in folgende Subphasen unterteilt: „Feasibility Study“, „Business Study“,<br />
„Functional Model Iteration“, „Design & Build Iteration“ und „Implementation“. Dabei<br />
werden verschiedene Prinzipien wie „aktiver Einbezug des Kunden“, „Kompetenzübertragung<br />
an das Team“, „regelmässige Lieferung von Produkten“, „kontinuierliche<br />
Überprüfung des gelieferten Produkts auf die Bedürfnisse des Kunden“, „iterative<br />
und inkrementelle Entwicklung“, „Reaktion auf sich ändernde Anforderungen“,<br />
„Anforderungen auf hohem Niveau fixieren“, „Testen während des gesamten Lebens-<br />
289 Vgl. Booth, Harmer 1995, zit. in Conboy 2009, S. 340.<br />
290 Vgl. Conboy 2009, S. 340.<br />
291 ISD steht für Information System Development.<br />
292 Vgl. Norton 2007a.
Konzeptionelle Grundlagen 61<br />
zyklus“ und „Kommunikation und Kooperation mit allen beteiligten Stakeholder“ zugrunde<br />
gelegt. Timeboxing und Prototyping sind die Kerntechniken dieses Ansatzes.<br />
Die DSDM ist allerdings keine Methode im eigentlichen Sinne, da nicht detailliert<br />
wird, wie Aktivitäten ausgeführt werden müssen. Es kann also eher als grobgranulares<br />
agiles Framework gesehen werden 293 .<br />
DSDM kann demnach als Ansatz eher auf Makroebene gesehen werden. Er adressiert<br />
die agilen Prinzipien zu einem grösseren Teil (vgl. Tabelle 2).<br />
2.4.2 Extreme Programming (XP)<br />
XP wird als ein leichtgewichtiger, agiler Softwareentwicklungsansatz bezeichnet. Er<br />
basiert auf einem Set an Werten, Prinzipien und Praktiken. Dabei gilt er als einer der<br />
reifsten und meistverbreiteten agilen Softwareentwicklungsansätze, aber auch als der<br />
radikalste Ansatz. XP ist als iterative Vorgehensweise konzipiert, die das kontinuierliche<br />
und qualitativ hochwertige Ausliefern von Software fördert. Dabei gibt XP sehr<br />
genaue Vorgaben über die Programmierung, sowie die Zusammenarbeit sowohl im<br />
Entwicklungsteam als auch mit den Kunden. Der Ansatz wurde im Jahr 1999 erstmals<br />
durch BECK 294 beschrieben.<br />
Kern der Methode sind ineinander verzahnte Rückkopplungszyklen, die einerseits von<br />
unterschiedlicher Dauer und andererseits von unterschiedlicher Reichweite sind. Diese<br />
Rückkopplung ist ausserdem einer der fünf Werte von XP. Auf höchster Ebene werden<br />
regelmässige, idealerweise monatliche Releases produktiv gesetzt (Monatstakt). Kurze<br />
Release-Zyklen mit lauffähigen Systemversionen, die von Kundenseite getestet werden<br />
und deren fachliche Anforderungen ggf. angepasst werden, werden in Wochentakt<br />
ausgeliefert (Wochentakt). In täglichen Meetings wird der aktuelle Stand der Arbeit<br />
abgeglichen (Tagestakt). Für frühe Fehlerfindung wird regelmässig eine Codeintegration<br />
durchgeführt (Stundentakt). Es wird testgetrieben entwickelt, d.h. die Tests werden<br />
vor der Programmierung spezifiziert (Minutentakt). Schlussendlich ist das wohl<br />
bekannteste Element von XP das Pair Programming (Sekundentakt) 295 .<br />
XP basiert auf den fünf zentralen Werten „Kommunikation“, „Rückkopplung“, “Einfachheit“,<br />
„Mut“ und „Respekt“, die bereits oben beschrieben wurden. Darüber hinaus<br />
werden 14 Prinzipien und 13 Primärpraktiken definiert. Die 14 Prinzipien detaillieren<br />
diese Werte. Diese sind „Menschlichkeit“, „Wirtschaftlichkeit“, „gegenseitiger Vor-<br />
293 Vgl. Voigt 2004.<br />
294 Vgl. Beck 1999.<br />
295 Vgl. Wolf, Rook 2009, S. 9; Wolf, Rook 2011, S. 9.
62 Konzeptionelle Grundlagen<br />
teil“, „Verbesserung“, „Mannigfaltigkeit“, „Reflexion“, „Fluss“, „Gelegenheit“, „Redundanz“,<br />
„Fehlschlag“, „Qualität“, „Babyschritte“ und „akzeptierte Verantwortlichkeit“<br />
296 . Im Sinne von „Best Practices“ werden für XP 13 so genannte Praktiken definiert,<br />
die elementare Erfolgskriterien für den Einsatz dieses Ansatzes widerspiegeln.<br />
Dazu gehört „räumlich zusammensitzen“, „komplettes Team“, „informative Arbeitsumgebung“,<br />
„energiegeladene Arbeit“, „Pair Programming“, „Geschichten“,<br />
„Wochenzyklus“, „Quartalszyklus“, „Freiraum“, „Zehn-Minuten-Build“, „kontinuierliche<br />
Integration“, „testgetriebene Entwicklung“ und „inkrementeller Entwurf“. Nicht<br />
selbsterklärend ist das „komplette Team“, was bedeutet, dass das Team mit den notwendigen<br />
fachlichen und technischen Kompetenzen ausgestattet werden muss, damit<br />
das Projekt erfolgreich sein kann. Die „energiegeladene Arbeit“ bedeutet, dass alle<br />
Teammitglieder engagiert mitarbeiten und sich für das Projekt einsetzen. Mit „Geschichten“<br />
sind Stories gemeint, im Rahmen derer die Fachabteilungen aber auch die<br />
Entwickler ihre Anforderungen aufschreiben und diese dann durch das Entwicklungsteam<br />
in umsetzbare Anforderungen dekomponiert werden. Mit „Wochenzyklus“ sind<br />
wöchige Iterationen gemeint, die den Entwicklungsteams fixe Zeitfenster für die Entwicklung<br />
bieten. Ein Release dauert typischerweise ein Quartal (Quartalszyklus) und<br />
beinhaltet mehrere Iterationen 297 .<br />
Quasi als Reifestufe werden elf Folgepraktiken in XP festgehalten, die ein Team zusätzlich<br />
einsetzen kann, wenn es die Primärpraktiken beherrscht. Diese dienen dazu,<br />
den XP-Prozess weiter zu optimieren.<br />
XP ist sehr entwicklungsorientiert und wird deshalb oft in Zusammenhang mit einem<br />
passenden <strong>Projektmanagement</strong>-Framework wie bspw. Scrum verwendet 298 . Die Kernaktivitäten<br />
in XP sind „Coding“, „Testing“, „Listening“ und „Designing“ 299 . Diese<br />
Aktivitäten untermauern den starken Fokus auf die Entwicklung an sich. Dabei wird<br />
ein grosser Wert auf die Qualitätssicherung durch testgetriebene Entwicklung und Pair<br />
Programming gelegt. XP macht klare Vorgaben über das Management, die Teamzusammensetzung<br />
und -zusammenarbeit und vor allem auch bezüglich der konkreten<br />
Programmierung. Es handelt sich bei XP um eine sehr radikale, mächtige und damit<br />
anspruchsvolle Methode für den praktischen Einsatz 300 .<br />
296 Vgl. Norton, Murphy 2007, S. 5; Wolf, Rook 2009, S. 9; Wolf, Rook 2011, S. 9.<br />
297 Vgl. Wolf, Rook 2009, S. 11ff.; Wolf, Rook 2011, S. 11ff.<br />
298 Vgl. Norton, Murphy 2007, S. 2.<br />
299 Vgl. Norton, Murphy 2007, S. 4.<br />
300 Vgl. Wolf, Rook 2009, S. 13; Wolf, Rook 2011, S. 13.
Konzeptionelle Grundlagen 63<br />
XP setzt den Fokus demnach eher auf der Mikroebene, obschon auch Elemente der<br />
Makroebene zu finden sind. Es adressiert die agilen Prinzipien zu grossen Teilen explizit<br />
(vgl. Tabelle 2).<br />
2.4.3 Feature-Driven Development (FDD)<br />
Wie der Name sagt, orientiert sich das FDD in erster Linie an der Implementierung<br />
von Anforderungen. Diese werden sehr kundennah definiert 301 . Voraussetzung für den<br />
Erfolg von FDD sind kleine, hoch kollaborative Entwicklungsteams. Der Ansatz<br />
zeichnet sich durch seine Einfachheit aus. FDD wird in fünf Teilprozesse aufgeteilt.<br />
Diese sind „Erstelle das Gesamtmodell“, „Erstelle die Feature-Liste“, „Plane je Feature“,<br />
Entwirf je Feature“ und „Entwickle je Feature“ 302 :<br />
Erstelle das Gesamtmodell: In diesem Schritt wird in Zusammenarbeit zwischen Fachbereichen<br />
und IT der Umfang und Inhalt des Gesamtsystems definiert. Dieses wird<br />
anschliessend in Module geschnitten und jeweils Fachmodelle für die einzelnen Bereiche<br />
erstellt. Diese werden überprüft und in das Gesamtsystem integriert. Ziel dieser<br />
Phase ist der Konsens über Umfang und Inhalt des zu erstellenden Systems, sowie ein<br />
fachliches Kernmodell.<br />
Erstelle die Feature-Liste: Im zweiten Schritt wird das Gesamtsystem zerlegt und in<br />
einzelne Features aufgeteilt. Das Ergebnis dieser Phase ist eine Liste mit kategorisierten<br />
Features nach fachlichen Gesichtspunkten.<br />
Plane je Feature: Der dritte Schritt widmet sich der Planung der Features. Die Projektleitung<br />
plant dabei mit den Entwicklungsleitern die Reihenfolge, in der die Features<br />
realisiert werden sollen. Dabei werden auch auf Abhängigkeiten zwischen den Features<br />
und die Auslastung des Entwicklungsteams Rücksicht genommen.<br />
Entwirf je Feature: Im vierten Schritt werden die zu entwickelnden Features in einer<br />
ersten Version entworfen. Dabei werden Sequenzdiagramme und darauf aufbauend<br />
verfeinerte Klassenmodelle geschrieben und erste Entwürfe für die Klassen- und Methodenrümpfe<br />
erarbeitet. Vor dem Übergang in die Entwicklungsphase werden diese<br />
Ergebnisse nochmals überprüft.<br />
Entwickle je Feature: Der fünfte Schritt ist die eigentliche Programmierung der geplanten<br />
Features. Dabei wird ein grosses Gewicht auf Integrationstests und Quelltextinspektionen<br />
zur Qualitätssicherung gelegt.<br />
301 Vgl. Bleek, Wolf 2008, S. 152ff.; Wolf, Rook 2009, S. 17ff.; Wolf, Rook 2011, S. 17ff.<br />
302 Vgl. im Folgenden Bleek, Wolf 2008, S. 152ff.; Norton 2007b, S. 4ff.; Wolf, Rook 2009, S. 17ff.; Wolf,<br />
Rook 2011, S. 17ff.
64 Konzeptionelle Grundlagen<br />
Ob FDD wirklich als agile Methode bezeichnet werden kann ist umstritten, da davon<br />
ausgegangen wird, dass der Kunde nach der Erstellung des Gesamtmodells, also zu<br />
Beginn des Projekts, bereits alle Anforderungen definiert hat. Dies widerspricht eigentlich<br />
der Agilität 303 . Die Diskussion von BLEEK UND WOLF kommt zum Schluss,<br />
dass FDD durchaus als agile Methode bezeichnet werden kann, jedoch nicht mit dem<br />
Fokus der Änderungsflexibilität.<br />
FDD macht zwar Vorgaben zur eigentlichen Entwicklung, der Fokus ist allerdings<br />
eher auf der Makroebene zu sehen. Die agilen Prinzipien werden bei FDD nur zu einem<br />
Teil explizit adressiert (vgl. Tabelle 2).<br />
2.4.4 Kanban<br />
Kanban ist eine der jüngsten agilen Methoden. Es handelt sich hierbei allerdings weder<br />
um eine Entwicklungsmethode wie bspw. XP, noch um eine Management-Methode<br />
wie Scrum. Vielmehr ist Kanban eine Methode für das Change Management. Ursprünglich<br />
stammt sie aus der Produktion, wo das Ziel verfolgt wurde, Lagerbestände<br />
zu reduzieren und einen gleichmässigen Fluss in der Fertigung zu erreichen. Kanban in<br />
der IT orientiert sich an Lean Development 304 .<br />
Ziel von Kanban ist es, bestehende Prozesse kontinuierlich und methodisch unterstützt<br />
zu verbessern. Dadurch, dass es auf Bestehendem aufsetzt, lässt es sich problemlos mit<br />
anderen agilen Methoden oder klassischen, wasserfallorientierten Methoden kombinieren<br />
305 .<br />
ANDERSON 306 , der eigentliche Begründer von Kanban in der IT, hat drei Grundprinzipien<br />
und fünf Kerneigenschaften von Kanban definiert:<br />
Die Grundprinzipien sind „Beginne dort, wo du dich im Moment befindest“, „Komme<br />
mit den anderen überein, dass inkrementelle, evolutionäre Veränderungen angestrebt<br />
werden“ und „Respektiere den bestehenden Prozess sowie die existierenden Rollen,<br />
Verantwortlichkeiten und Berufsbezeichnungen“.<br />
Kerneigenschaften:<br />
Visualisiere den Fluss der Arbeit (Workflow): Hier werden typischerweise sogenannte<br />
Kanban-Boards verwendet. Diese lassen sich einfach an Whiteboards oder elektro-<br />
303 Vgl. Bleek, Wolf 2008, S. 155f.<br />
304 Vgl. Wolf, Rook 2011, S. 14ff.<br />
305 Vgl. Wolf, Rook 2011, S. 14ff.<br />
306 Vgl. Anderson 2011.
Konzeptionelle Grundlagen 65<br />
nisch erstellen. Ziel dabei ist es, die einzelnen Aufgaben in ihren Entwicklungsschritten<br />
im Auge zu behalten. Gute Kanban-Boards ermöglichen es, auf einen Blick zu<br />
überprüfen, wo sich die einzelnen Aufgaben befinden und wo sich Probleme bzw.<br />
Engpässe ergeben könnten.<br />
Begrenze den Work in Progress (WIP): Hier wird die Anzahl der Aufgaben im jeweiligen<br />
Status limitiert, d.h. es kann nur eine zuvor definierte Anzahl Aufgaben in der<br />
Spalte „Test“ sein. Ziel hierbei ist es, durch eine Verhinderung von Überlast die Qualität<br />
zu erhöhen und die Durchlaufzeit pro Aufgabe zu verkleinern. Gleichzeitig hilft<br />
dieses Limit, auf einen Blick zu sehen, wie und wo Probleme und Engpässe auftreten<br />
könnten.<br />
Führe Messungen zum Fluss durch und kontrolliere ihn (Flow): Bei Kanban wird<br />
grossen Wert auf quantitatives Management gelegt. Es werden Messungen durchgeführt,<br />
welche anschliessend als Ausgangspunkt für Anpassungen fungieren. Insbesondere<br />
die Durchlaufzeit der Aufgaben bildet dabei eine zentrale Steuerungsgrösse. Ziel<br />
ist es, diese Durchlaufzeit kontinuierlich zu verkürzen. Dabei hat sich gezeigt, dass<br />
dadurch auch die Qualität merklich gesteigert werden kann. Weitere Messgrössen sind<br />
bspw. Termintreue oder Fehlerquote.<br />
Mache die Regeln für den Prozess explizit: Selbstorganisation des Projektteams ist eine<br />
Grundlage für Kanban. Die Teammitglieder sollen selbstständig neue Aufgaben für<br />
die Bearbeitung an sich nehmen, Probleme erkennen, diskutieren und lösen können.<br />
Hierfür ist es notwendig, dass die impliziten Prozessregeln expliziert werden. Die damit<br />
erreichte Transparenz ermöglicht so, mit einer gewissen Fluktuation innerhalb des<br />
Projektteams umzugehen.<br />
Verwende Modelle, um Chancen für Verbesserung zu erkennen: Kontinuierliche Verbesserung<br />
in kleinen Schritten (Kaizen 307 ) ist elementarer Bestandteil von Kanban. Um<br />
Chancen hierfür erkennen und diskutieren zu können, werden Modelle zusammen mit<br />
Kanban eingesetzt wie bspw. Systems Thinking oder das Toyota Produktion Systems<br />
308 . Sie helfen dabei, Prozesse besser zu verstehen und daraus Potenzial für Verbesserung<br />
abzuleiten.<br />
307 Kaizen bezeichnet eine japanische Lebens- und Arbeitsphilosophie, in deren Zentrum das Streben nach<br />
ständiger Verbesserung steht (vgl. Imai 1992).<br />
308 Elemente des Toyota Production Systems (TPS) wie bspw. das „Thinking People System“, sind Schlüsselaspekte<br />
für die Erkennung von Chancen zur Verbesserung. Im Rahmen dessen wird den Mitarbeitenden<br />
Verantwortung für den Prozesserfolg übertragen und diese somit zum Mitdenken und Einbringen von Verbesserungspotenzialen<br />
animiert.
66 Konzeptionelle Grundlagen<br />
Insbesondere bei den Grundprinzipien wird die Denkweise von Kanban deutlich, nämlich<br />
das Ziel, möglichst ohne grössere Widerstände der Beteiligten Verbesserungen zu<br />
erlangen.<br />
Kanban als Change Management-Ansatz ist aufgrund seiner Charakteristika als Management-Methode<br />
auf der Makroebene zu positionieren. Er adressiert einen Teil der<br />
agilen Prinzipien explizit und einige implizit (vgl. Tabelle 2).<br />
2.4.5 Scrum<br />
Scrum ist ein agiles Framework zum Management von Projekten und ist heute einer<br />
der bekanntesten Vertreter agiler Methoden, da es durch seine einfache Struktur und<br />
die klar definierten Rollen, sowie wenige, klare Regeln schnell, verständlich ist 309 .<br />
Grundannahme bei Scrum ist, dass Projekte so komplex sind, dass die Anforderungen<br />
nicht vorgängig vollständig ausspezifiziert werden können. Deshalb wird in kurzen,<br />
intensiven Iterationszyklen entwickelt, an deren Ende ein lauffähiges, inkrementell<br />
verbessertes Produkt steht und nach jeder Iteration die spezifizierten Anforderungen<br />
überprüft und angepasst werden können. Die ersten Ideen für diesen Ansatz stammen<br />
aus dem Jahr 1993. Vorgestellt wurde der Ansatz 1995 durch SUTHERLAND 310 , formalisiert<br />
und in Buchform publiziert wurde Scrum 2001 311 . Der Begriff „Scrum“ stammt<br />
aus dem Rugby und wird als „Gedränge“ übersetzt. Es handelt sich dabei um einen<br />
Spielzug, bei dem jeweils acht Spieler beider Mannschaften vorne übergebeugt ein<br />
Gedränge bilden. Anschliessend wird der Ball von der Seite in das Gedränge geworfen<br />
und die Spieler müssen mit den Füssen versuchen den Ball nach hinten auf ihre Seite<br />
zu bringen. Erst nachdem der Ball hinten das Gedränge verlassen hat, darf ein Angriff<br />
lanciert werden. Dieser Spielzug ist sehr kompliziert und muss intensiv geübt werden.<br />
Dabei geht es insbesondere darum, dass die einzelnen Rollen klar sind und diese ideal<br />
zusammenspielen. Nur so kann der Spielzug erfolgreich abgeschlossen werden. Er<br />
verlangt also disziplinierte Teamarbeit 312 . Diese Charakteristika widerspiegeln sich in<br />
Scrum als agile Managementmethode. Es handelt sich bei diesem Ansatz nicht um eine<br />
spezifisch agile Methode für die Entwicklung von Software. Vielmehr bietet Scrum<br />
einen Ansatz, mit dessen Hilfe jegliche Projekte agil gestaltet werden können. Aus<br />
309 Vgl. Pichler 2008, S. 1.<br />
310 Vgl. Sutherland 1995.<br />
311 Vgl. Schwaber, Beedle 2001.<br />
312 Vgl. Pichler 2008, S. 2.
Konzeptionelle Grundlagen 67<br />
diesem Grund bleibt die Methode entsprechend grobgranular und macht keine Angaben<br />
dazu, wie entwickelt werden soll 313 .<br />
Scrum basiert auf drei zentralen Prinzipien, „Transparenz“, „Überprüfung“ und „Anpassung“.<br />
Transparenz wird erreicht indem der Fortschritt und mögliche Hindernisse<br />
regelmässig, d.h. täglich für alle sichtbar festgehalten werden. Überprüfung wird<br />
dadurch erwirkt, dass am Ende jeden Sprints die Ergebnisse präsentiert, kritisch überprüft<br />
und beurteilt werden. Die Anpassung ist ein zentrales Element von Scrum zur<br />
Behandlung sich ändernder Anforderungen während des Projekts. Es wird durch diesen<br />
Ansatz ermöglich, dass während der Laufzeit jeweils Änderungen in das Projekt<br />
einfliessen können 314 .<br />
Product-Backlog Sprint-Backlog Sprint Lauffähige, inkrementell<br />
verbesserte Software<br />
Daily<br />
Scrum<br />
Sprint<br />
max.<br />
30 Tage<br />
Abbildung 16: Vorgehensweise in Scrum 315<br />
Das Vorgehen 316 , wie in Abbildung 16 dargestellt, gestaltet sich so, dass im Product<br />
Backlog sämtliche Anforderungen und deren technische Abhängigkeiten gesammelt<br />
werden. Nach jedem Sprint werden diese neu bewertet, priorisiert, ergänzt oder gestrichen.<br />
Im Product Backlog befinden sich sowohl bereits nach deren Aufwand geschätzte,<br />
als auch noch nicht geschätzte Anforderungen. Immer wenn eine neue Anforderung<br />
auftaucht, sei dies im Rahmen des aktuellen Sprints oder ausserhalb dessen, wird diese<br />
in das Product Backlog eingetragen und in das Projekt mit aufgenommen.<br />
Im Sprint Backlog werden die für den geplanten Sprint ausgewählten Anforderungen<br />
gesammelt. Aus der grossen Menge an Anforderungen im Product Backlog werden<br />
313 Vgl. Bleek, Wolf 2008, S. 149.<br />
314 Vgl. Sutherland, Schwaber 2011, S. 3.<br />
315 In Anlehnung an Bleek, Wolf 2008, S. 152; Pichler 2008, S. 7<br />
316 Vgl. im Folgenden Bleek, Wolf 2008, S. 150f.
68 Konzeptionelle Grundlagen<br />
durch den Product Owner 317 diese ausgewählt, die im folgenden Sprint implementiert<br />
werden sollen.<br />
Bevor ein Entwicklungs-Sprint gestartet wird, wird eine Sprint-Planung durchgeführt.<br />
Hierbei geht es darum, die konkret im nächsten zeitlich fixierten Sprint abzuarbeitenden<br />
Anforderungen zu definieren. Der Product Owner ist zwar für die Auswahl der zu<br />
implementierenden Anforderungen zuständig, ist dabei aber auf die Zusammenarbeit<br />
mit dem Entwicklungsteam angewiesen. Dieses ist in der Lage die ausgewählten Anforderungen<br />
nach deren Aufwand zu schätzen und nur so viel für die Umsetzung zu<br />
planen wie auch möglich ist. Somit stellt das Entwicklungsteam in Zusammenarbeit<br />
mit dem Product Owner sicher, dass nur erfüllbare Erwartungen an den Sprint entstehen.<br />
Im Rahmen des Sprint-Planungs-Meetings werden also einerseits die Anforderungen<br />
für den nächsten Sprint ausgewählt und diese andererseits, wo notwendig, geschätzt.<br />
Es existieren unterschiedliche Schätzmethoden. Eine verbreitete ist der Planungspoker,<br />
welcher nach einem Punktesystem auf abstrakter Ebene jeder Anforderung<br />
einen Wert zuordnet. Jedes Mitglied des Entwicklungsteams vergibt dabei Punkte<br />
pro Anforderung, die anschliessend diskutiert werden, bis ein Konsens über die Höhe<br />
des Aufwands gefunden wird 318 .<br />
Anschliessend folgt der maximal 30 Tage dauernde Entwicklungssprint, im Rahmen<br />
dessen das Sprint Backlog abgearbeitet wird. In dieser Zeit ist das Entwicklungsteam<br />
ungestört von externen Einflüssen und es werden keine neuen oder sich ändernden<br />
Anforderungen im Sprint behandelt. Das Entwicklungsteam organisiert sich in dieser<br />
Zeit selbst und ist dafür verantwortlich, dass am Ende des Sprints die geplanten Anforderungen<br />
implementiert werden. Zur Steigerung der Transparenz werden die geplanten<br />
und die bereits implementierten Aufgaben in einem Burn Down Chart visualisiert.<br />
So ist für jedes Projektmitglied sichtbar, ob der Sprint im Plan ist und es gibt<br />
dem Product Owner und dem Scrum Master Möglichkeiten für Gegenmassnahmen im<br />
nächsten Sprint 319 .<br />
Während des Sprints findet täglich ein sog. Daily Scrum statt, ein Kurzmeeting, im<br />
Rahmen dessen alle Beteiligten auf den aktuellen Stand gebracht werden und weitere<br />
Schritte geplant werden. Das Meeting dauert typischerweise maximal 15 Minuten und<br />
es werden die drei zentralen Fragen „Was habe ich seit dem letzten Daily Scrum ge-<br />
317 Die Beschreibung der Rollen findet sich am Ende des Abschnitts.<br />
318 Vgl. Pichler 2008, S. 60f.<br />
319 Vgl. Sutherland, Schwaber 2011, S. 13f.
Konzeptionelle Grundlagen 69<br />
tan?“, „Was plane ich bis zum nächsten Daily Scrum?“ und „Wo liegen Hindernisse,<br />
die mich in der Ausführung einer Aufgabe behindern?“ geklärt.<br />
Am Ende eines Sprints wird das Resultat, ein lauffähiges, inkrementell verbessertes<br />
Produkt, in einer Sprint-Review dem Product Owner präsentiert und durch diesen bewertet,<br />
bevor ein neuer Sprint initialisiert wird. Daraus ergeben sich ggf. neue oder<br />
geänderte Anforderungen, die wiederum in das Product Backlog einfliessen. Wenn<br />
Anforderungen nicht im geplanten Sprint implementiert werden konnten, so gehen<br />
auch diese zurück in das Product Backlog. Daraus lernt das Entwicklungsteam diese<br />
besser zu schätzen oder eine bessere Einschätzung der eigenen Leistungsfähigkeit im<br />
Sprint.<br />
In einer Sprint-Retrospektive reflektiert sich das Team selbst und betrachtet den Prozess<br />
des abgelaufenen Sprints kritisch. Hieraus werden Lehren gezogen und Massnahmen<br />
für die weiteren Sprints definiert.<br />
So schlank das Vorgehen in Scrum ist, so schlank ist auch das Rollenmodell. Der Ansatz<br />
sieht die Kernrollen „Product Owner“, „Scrum Master“ und „Team“ vor, die getreu<br />
dem Agilen Manifest „Individuals and interactions over processes and tools“, sehr<br />
eng zusammenarbeiten 320 .<br />
Der Product Owner ist für die Repräsentation der Kundenbedürfnisse verantwortlich.<br />
Dabei nimmt er eine zentrale Rolle im Projekt ein, steuert dieses und arbeitet eng mit<br />
den Entwicklungsteams zusammen. Die Arbeit des Product Owners ist typischerweise<br />
eine Vollzeitaufgabe, insbesondere dann, wenn es sich um grössere Vorhaben handelt.<br />
Der Projekterfolg ist direkt abhängig von der Qualifikation und dem Engagement des<br />
Product Owners. Aus diesem Grund muss dieser sorgfältig ausgewählt werden. Der<br />
Product Owner ist für die Anforderungsbeschreibung und das -management zuständig,<br />
steuert die Releases und ist Bindeglied zwischen dem Projektteam und den relevanten<br />
Stakeholdern.<br />
Das Team ist für sämtliche Arbeiten verantwortlich, die für das Erreichen der fertigen<br />
Produktinkremente notwendig sind. Ein zentraler Aspekt von Scrum ist die Selbststeuerung<br />
der Entwicklungsteams. Damit ein Entwicklungsteam in Scrum funktionieren<br />
kann, muss es über eine Reihe von Eigenschaften verfügen. Es muss „bevollmächtigt“<br />
sein, d.h. Entscheidungskompetenz besitzen, es muss „autonom“ sein, d.h. nicht wesentlich<br />
von externen Einflüssen abhängig sein und „interdisziplinär besetzt“ sein, d.h.<br />
alle Rollen beinhalten, die für das Erreichen des Ziels notwendig sind. Weiter ist, wie<br />
320 Vgl. im Folgenden Pichler 2008, S. 9ff.
70 Konzeptionelle Grundlagen<br />
erwähnt die „Selbstorganisation“ ein zentraler Aspekt, die Team müssen „klein“ sein,<br />
d.h. zwischen fünf und neun Mitglieder haben, alle sollten „Vollzeitteammitglieder“<br />
sein, damit keine externen Abhängigkeiten entstehen und schliesslich sollen die „Arbeitsplätze<br />
in unmittelbarer Nähe“ sein, damit intensive Kommunikation ermöglicht<br />
wird.<br />
Der Scrum Master agiert als Coach und Change Agent. Seine Hauptaufgabe ist die<br />
korrekte Durchsetzung der Methode und er dient der Etablierung des Prozesses und<br />
der Denkweise im Unternehmen. Zu den Aufgaben des Scrum Masters gehören, wie<br />
erwähnt, die Etablierung der Methode, die Sicherstellung der direkten Zusammenarbeit<br />
zwischen Product Owner und Team, das Beseitigen jeglicher Hindernisse, egal ob<br />
diese organisatorischer oder technischer Natur sind und schliesslich das ständige Verbessern<br />
der Methodenumsetzung im Projekt.<br />
Scrum sieht keine Rolle der Projektleitung vor. Dessen Aufgaben werden vor allem<br />
durch den Product Owner, teilweise aber auch durch das Team abgedeckt 321 . Die Erfahrung<br />
der Unternehmen aus den Fallstudien (vgl. Kapitel 5) haben jedoch gezeigt,<br />
dass in allen Fällen eine Art Projektleitung eingesetzt wird. Dies hat mit der Einschränkung<br />
der Macht des Product Owners zu tun. Insbesondere bei Projekten mit Beteiligung<br />
externer Dienstleister kann die vollständige Kontrolle des Projektteams nicht<br />
dem internen Product Owner überlassen werden. Hier sind Mechanismen notwendig,<br />
die eine Verteilung der Macht auf Kunde und externem Dienstleister erlauben.<br />
Zusammengefasst ist Scrum eine gut dokumentierte und mittlerweile gereifte Methode<br />
mit globaler Anwendung. Es gibt verschiedene Werkzeuge, die die Einführung und<br />
Abwicklung von Scrum unterstützen. Es lässt sich durch seine Einfachheit verhältnismässig<br />
schnell einsetzen. Scrum wird in erster Linie als <strong>Projektmanagement</strong>methode<br />
ohne tieferen Bezug auf die Softwareentwicklung verstanden. Aus diesem Grund wird<br />
der Ansatz häufig mit konkreten agilen Entwicklungsmethoden wie bspw. XP kombiniert<br />
322 . Somit ist der Ansatz auf der Makroebene zu positionieren. Durch Scrum werden<br />
die meisten der agilen Prinzipien explizit adressiert (vgl. Tabelle 2).<br />
2.4.6 Zusammenfassende Betrachtung<br />
Nach den Grundlagen über agile Entwicklung und der Vorstellung ausgewählter Ansätze<br />
in den vorangegangenen Abschnitten, wird das Kapitel zusammenfassend betrachtet.<br />
Dabei soll einerseits detaillierter auf die grundlegenden Vorgehen bei Projek-<br />
321 Vgl. bspw. Pichler 2008, S. 23f.<br />
322 Vgl. Norton 2007d, S. 6; Wolf, Rook 2009, S. 8; Wolf, Rook 2011, S. 8.
Konzeptionelle Grundlagen 71<br />
ten eingegangen werden, die vorgestellten Ansätze zusammenfassend charakterisiert,<br />
sowie abschliessend die geeignete agile Methode für das Management von AIS-<br />
Projekten identifiziert werden. Diese bildet die Grundlage für die in Kapitel 6 aufzubauende<br />
situative Methode.<br />
Grundsätzlich lassen sich drei verschiedene <strong>Projektmanagement</strong>ansätze unterscheiden.<br />
Der klassische Wasserfall-Ansatz 323 wird durch eine stark sequentielle Vorgehensweise<br />
mit selektiver Zusammenarbeit zwischen den Projektbeteiligten charakterisiert. Iterationszyklen<br />
und Rückkoppelungen finden zwar statt, sind jedoch wenig ausgeprägt<br />
324 .<br />
Der Spiral-Ansatz 325 sieht grosse und häufige Iterationszyklen vor und orientiert sich<br />
dennoch stark am Wasserfall-Ansatz 326 . Der agile Ansatz zeichnet sich dadurch aus,<br />
dass das Gesamtprojekt in zahlreiche kleine und relativ unabhängige Arbeitspakete<br />
aufgeteilt wird. Jedes der Arbeitspakete hat zum Ziel, ein fertiges Produktinkrement zu<br />
generieren 327 . Die dadurch entstehenden Iterationszyklen sind sehr zahlreich und verlangen,<br />
wie bereits erwähnt, eine ausgeprägte Kommunikation zwischen den Projektbeteiligten.<br />
Eine nicht abschliessende Gegenüberstellung der beiden extremen Ansätze, des Wasserfall-Ansatzes<br />
und der Agilität, zeigt deren fundamental unterschiedliche Herangehensweise<br />
bei IT-Projekten. Es zeigt sich aber auch, dass sich die beiden Ansätze nicht<br />
zwingend ausschliessen. Für einige Projekte sind Wasserfall-Ansätze durchaus geeigneter<br />
(vgl. Tabelle 1).<br />
Nach HOTLE 328 sollte ein Wasserfall-Ansatz dann verwendet werden, wenn die Anforderungen<br />
klar, stabil und abschliessend zu definieren sind sowie das Projektumfeld<br />
stabil ist. Für die Erarbeitung ganzheitlicher, nicht teilbarer Konzepte wie bspw. Architekturen<br />
eignet sich der Wasserfall-Ansatz. Iterative Methoden sollen bei volatilen<br />
Anforderungen angewendet werden, wenn die sequentielle Bearbeitung der Aufgaben<br />
für den Projekterfolg massgeblich ist. Agile Methoden eignen sich bei stark volatilen,<br />
schwer fassbaren und nicht abschliessenden Anforderungen und wenn sich Geschäftsanforderungen<br />
schnell und kontinuierlich verändern. Ein unbekanntes oder instabiles<br />
323 Der Wasserfall-Ansatz geht auf ROYCE zurück, der dieses 1970 vorstellte. Das Modell beinhaltet sieben<br />
streng sequentielle Schritte zur Entwicklung von Software (Royce 1970).<br />
324 Vgl. Hotle 2010, S. 2.<br />
325 Der Spiralansatz ist eine Weiterentwicklung des Wasserfall-Ansatzes und geht auf BOEHM zurück (Boehm<br />
1986).<br />
326 Vgl. Hotle 2010, S. 3.<br />
327 Vgl. Hotle 2010, S. 4.<br />
328 Vgl. Hotle 2010.
72 Konzeptionelle Grundlagen<br />
Projektumfeld begünstigt den Einsatz agiler Methoden, da während des Projekts noch<br />
„Kurskorrekturen“ vorgenommen werden können.<br />
Charakteristika<br />
Wasserfall-Ansatz<br />
- Lineares Vorgehensmodell<br />
- Klare Phasenabgrenzung<br />
- Eindeutig definierte Ergebnisse<br />
- „Dokumentationsgetrieben“<br />
- Frühes Festlegen der Anforderungen<br />
Agiler Ansatz<br />
- Funktionierende Produktinkremente sind wichtiger<br />
als Dokumentation<br />
- Individuen und Interaktionen sind wichtiger als<br />
Prozesse und Werkzeuge<br />
- Offenheit für Änderungen ist wichtiger als ein<br />
festgelegter Plan.<br />
- Kommunikation mit Kunden ist wichtiger als<br />
Vertragsverhandlungen<br />
Fokus 329<br />
Anford.<br />
gesetzt<br />
Ressourcen<br />
gesetzt<br />
Zeit<br />
gesetzt<br />
Ress.<br />
gesetzt<br />
Qualität<br />
gesetzt<br />
Qualität<br />
variabel<br />
Zeit<br />
variabel<br />
Funktionalität (Umfang)<br />
variabel<br />
Vorteile<br />
Herausforderungen<br />
- Akzeptierter Ansatz insbesondere in konservativem<br />
Projektumfeld<br />
- Breites Erfahrungswissen in Unternehmen<br />
vorhanden.<br />
- Anforderungen können während des Projekts<br />
nur noch mit viel Aufwand geändert werden.<br />
- Viel Aufwand fliesst in die Dokumentation<br />
- Späte Lieferung von Ergebnissen heisst späte<br />
Erfolgskontrolle<br />
- Lieferung funktionsfähiger Ergebnisse (schneller<br />
Return on Investment (ROI).<br />
- Sich ändernde Anforderungen sind der Normalfall<br />
und können während der gesamten Projektlaufzeit<br />
berücksichtigt werden.<br />
- Akzeptanz in traditionellen Projektumgebungen<br />
- Sich ändernde Anforderungen können den<br />
Projektabschluss verzögern.<br />
Tabelle 1: Charakteristika von Wasserfall-Ansatz und Agilität 330<br />
Projekte für AIS bewegen sich vorwiegend in letzterem Umfeld 331 . Daher ist der Einsatz<br />
agiler Methoden für deren Management eine Möglichkeit, der Komplexität in solchen<br />
Projekten zu begegnen. Im AIS-Umfeld konnten sich agile Methoden gegenwärtig<br />
noch nicht etablieren. Nach wie vor werden klassische Wasserfall-Ansätze verwendet.<br />
Der Grund dafür liegt zu einem wesentlichen Teil in der Risikolage, in der sich<br />
AIS-Projekte typischerweise befinden. Hieraus ergeben sich eine Aversion gegenüber<br />
neuen Ansätzen und ein Festhalten an Vorgehen, die sich in der Vergangenheit bewährt<br />
haben. Es muss demnach ein Weg gefunden werden, wie die etablierte Agilität<br />
in der Applikationsentwicklung (Frontend) mit traditionellem Vorgehen in der Datenstrukturierung<br />
(Backend) vereinbart werden kann.<br />
329 In Anlehnung an Norton 2007a, S. 2.<br />
330 Die Charakteristika der agilen Ansätze werden je nach betrachteter Methode unterschiedlich stark fokussiert,<br />
bspw. gilt die „Offenheit für Änderungen ist wichtiger als ein festgelegter Plan“ nicht für FDD.<br />
331 Vgl. Clark et al. 2007; Hughes 2008; Kimball et al. 2008; Moss, Atre 2003; Strauch 2002; Winter, Strauch<br />
2003; Wixom, Watson 2001.
Regelmässige Lieferung<br />
von Ergebnissen<br />
Ändernde<br />
Anforderungen<br />
Aufteilung in Sprints<br />
Zusammenarbeit zwischen<br />
Fachbereich/IT<br />
Motivierte Individuen<br />
Face-to-Face-<br />
Kommunikation<br />
Beurteilung der<br />
Ergebnisse<br />
Nachhaltige<br />
Entwicklung<br />
Technische Exzellenz<br />
Einfachheit<br />
Selbstorganisierte<br />
Teams<br />
Selbstreflexion<br />
Konzeptionelle Grundlagen 73<br />
Im Gartner Hype Cycle fort Application Development von 2009 befinden sich agile<br />
Entwicklungsmethoden zu Beginn der „Talsohle der Desillusion“ 332 . Nichtsdestotrotz<br />
zeigt die Menge an neueren Veröffentlichungen zu diesem Thema, dass die Agilität an<br />
Bedeutung gewinnt 333 . Aber auch die einschlägigen Konferenzen sowohl praxisorientierte,<br />
als auch wissenschaftliche, beschäftigen sich zunehmend mit agilen Methoden<br />
für Projekte unterschiedlichster Bereiche.<br />
Um eine geeignete Methode für die Adaption auf AIS-Projekte zu identifizieren, müssen<br />
deren Charakteristika gegenübergestellt werden. Hierbei bietet sich die Einordnung<br />
auf zwei Achsen an, nämlich der Grad der Agilität im Sinne des Agilen Manifests<br />
und die Perspektive des Ansatzes an (vgl. Abbildung 17).<br />
Der Grad der Agilität gibt dabei an, inwiefern der Ansatz die Prinzipien und Praktiken<br />
aus dem Agilen Manifest berücksichtigt. Die Perspektive zeigt, ob der Fokus des Ansatzes<br />
eher auf der Mikroebene, also auf der eigentlichen Programmierung liegt, oder<br />
eher auf der Makroebene, d.h. eher ein Managementansatz für Projekte bietet. Diese<br />
Charakterisierung erfolgte jeweils zusammenfassend für jeden beschriebenen Ansatz.<br />
Hinsichtlich der Adressierung der agilen Prinzipien im Sinne des Agilen Manifests<br />
gibt Tabelle 2 einen Überblick über die betrachteten Ansätze 334 .<br />
(a) (b) (c) (d) (e) (f) (g) (h) (i) (j) (k) (l)<br />
DSDM + + + + 0 0 + - 0 0 + 0<br />
XP + 0 + + + + 0 - - + + +<br />
FDD + - 0 + 0 0 0 - 0 - - -<br />
Kanban + 0 - 0 0 0 0 - - + - -<br />
Scrum + + + + + + + 0 0 + + +<br />
Legende: [+] = vollständig adressiert; [0] = teilweise oder implizit adressiert; [-] = nicht adressiert<br />
Tabelle 2: Adressierung agiler Prinzipien durch die betrachteten agilen Methoden<br />
Abbildung 17 zeigt die Einordnung der betrachteten agilen Ansätze basierend auf der<br />
Charakterisierung in den jeweiligen Abschnitten (vgl. Abschnitt 2.4.1 bis 2.4.5) und<br />
332 Vgl. Norton et al. 2009, S. 5.<br />
333 vgl. bspw. Beyer, Richardson 2010; Bleek, Wolf 2008; Eckstein 2009; Hotle 2010; Hotle, Norton 2010;<br />
Hughes 2008; Pichler 2008.<br />
334 Die erste Zeile in Tabelle 2 zeigt, welches agile Prinzip aus dem Agilen Manifest abgedeckt ist (vgl. Abschnitt<br />
2.4).
mikro<br />
Entwicklungsperspektive<br />
makro<br />
74 Konzeptionelle Grundlagen<br />
der in Tabelle 2 vorgenommenen Gegenüberstellung. Ziel der vorliegenden Arbeit ist<br />
es, eine Management-Methode zu entwickeln. Der Fokus soll dabei weniger auf der<br />
Mikroebene, als vielmehr die Makrosicht beinhalten und Hilfestellungen bei der Organisation<br />
und Führung agiler AIS-Projekte bieten. Kanban ist ein Ansatz, der sich vor<br />
allem für wiederkehrende, regelmässige Aufgaben eignet. AIS-Projekte sind aber eher<br />
neu, unregelmässig und einmalig. Bei FDD wird vorausgesetzt, dass die Anforderungen<br />
bereits im Vorfeld klar sind. Somit bleibt auf der Makroebene Scrum als möglicher<br />
zu adaptierender Ansatz.<br />
Kanban<br />
Scrum<br />
FDD<br />
DSDM<br />
XP<br />
gering<br />
hoch<br />
Agilität im Sinne des agilen Manifests<br />
335 Vgl. Bleek, Wolf 2008, S. 149; Hughes 2008, S. 23; Norton 2007d, S. 2.<br />
336 Vgl. bspw. Hughes 2008.<br />
Abbildung 17: Einordnung der vorgestellten agilen Ansätze<br />
nach Grad der Agilität und Entwicklungsperspektive<br />
Aufgrund seiner mittlerweile hohen Verbreitung und Popularität als Ansatz für das<br />
Management von Projekten 335 , aber auch seiner bereits punktuellen Adaption auf den<br />
AIS-Kontext 336 wird an dieser Stelle Scrum als Grundlage für die Konstruktion einer<br />
agilen situativen Methode für das Management von AIS-Projekten verwendet. Dabei<br />
soll, wie oben erwähnt, agile Entwicklung mit traditionellen, verbreiteten Ansätzen in<br />
der AIS-Entwicklung kombiniert werden.
Stand der Forschung und verwandte Arbeiten 75<br />
3 Stand der Forschung und verwandte Arbeiten<br />
Folgende Abschnitte zeigen den aktuellen Stand der Forschung mittels einer Literaturanalyse<br />
auf. Diese bewegt sich insbesondere in den Domänen AIS-Entwicklung und<br />
agile Entwicklung, sowie der Schnittmenge agiler AIS-Entwicklung. Ziel dabei ist es,<br />
für die Konstruktion der situativen Methode relevante Ansätze zu identifizieren und zu<br />
analysieren. Hierfür werden in Abschnitt 3.1 der Auswahlprozess der Literaturrecherche<br />
dargelegt und die Bewertungskriterien für die zu identifizierenden Ansätze erläutert.<br />
Abschnitt 3.2 fasst die Kernaussagen und Vorgehen dreier für die Arbeit relevanter<br />
Ansätze zusammen. Abschnitt 3.3 stellt sämtliche identifizierten Publikationen den<br />
definierten Bewertungskriterien gegenüber und leitet daraus Erweiterungsmöglichkeiten<br />
ab, die durch die zu entwickelnde situative Methode adressiert werden.<br />
3.1 Auswahl und Bewertungskriterien für verwandte Arbeiten<br />
Folgender Abschnitt definiert die Auswahlkriterien und skizziert den Auswahlprozess<br />
für die Literaturrecherche. In Abschnitt 3.1.2 wird der Bezugsrahmen für die Bewertung<br />
der identifizierten Ansätze hergeleitet.<br />
3.1.1 Auswahlkriterien und -prozess<br />
Ausgangspunkt für die Auswahl der relevanten Ansätze aus der wissenschaftlichen<br />
Literatur ist eine Schlüsselwort-basierte Suche in allen von der wissenschaftlichen<br />
Kommission für Wirtschaftsinformatik (WKWI) mit „A“ klassifizierten Journals und<br />
Konferenzen 337 . Hierbei wurden keine zeitlichen Beschränkungen vorgenommen und<br />
jeweils die Abstracts analysiert. Bei der Suche wurde ein vierstufiges Verfahren zur<br />
Fokussierung auf relevante Suchergebnisse verwendet. Ausgehend vom <strong>Projektmanagement</strong><br />
(englischsprachige Schlüsselwörter „project management“, „development“,<br />
„program“) wurde die Suche schrittweise über die Einschränkung auf Agilität („agile“,<br />
„iterative“, „lean“), Methode/Prozess („method“, „process“,) und schliesslich<br />
AIS („analytical information system“, „business intelligence“, „data warehouse“,<br />
„analytics“, „decision support system“) verfeinert. Für den Einbezug deutschsprachiger<br />
Quellen wurden die entsprechenden deutschen Übersetzungen der Begriffe verwendet.<br />
Die Schlüsselwort-basierte Suche selbst wurde mithilfe der Literaturdatenbanken<br />
ProQuest, EbscoHost, ScienceDirect, Springerlink, ACM digital Library, AIS<br />
electronic Library (welche über einen Zugriff auf die entsprechenden Quellen verfü-<br />
337 Vgl. WKWI 2008, S. 160ff.
76 Stand der Forschung und verwandte Arbeiten<br />
gen), sowie auf den Webseiten der Fachzeitschriften durchgeführt. Letztlich ergab sich<br />
eine Treffermenge von insgesamt 62 Artikeln. Die Abstracts und Titel der Artikel<br />
wurden im Anschluss auf ihre Relevanz im Hinblick auf das vorliegende Thema (agile<br />
Methodenunterstützung für das Management von Projekten im Umfeld von AIS) analysiert.<br />
Auch bei grosszügiger Bewertung der identifizierten Beiträge konnte kein relevanter<br />
Artikel identifiziert werden. Einen wesentlichen Erklärungsgrund für dieses<br />
Ergebnis liefert CONBOY 338 . Er kommt nach ähnlicher Analyse zum Schluss, dass die<br />
Neuartigkeit des Themas Ursache für die nicht existierende Verbreitung in Top-<br />
Journals und -Konferenzen ist.<br />
Abbildung 18: Suchstrategie für agile AIS-Entwicklung<br />
Basierend auf diesen Ergebnissen musste das Suchfeld entsprechend erweitert werden.<br />
Die agile Entwicklung von AIS bewegt sich im Spannungsfeld zweier etablierter Domänen:<br />
Agile Entwicklung und (klassische) AIS-Entwicklung. Beide Domänen werden<br />
sowohl in der Wissenschaft als auch in der Praxis adressiert (vgl. Abbildung 18).<br />
Ziel war es somit, die Suche auf agile Entwicklung und (klassische) AIS-Entwicklung<br />
zu erweitern und dabei auch Praxisbeiträge einzubeziehen. Um die wissenschaftlichen<br />
Quellen aus dem Umfeld agile Entwicklung und (klassische) AIS-Entwicklung zu<br />
identifizieren, wurde analog zur initialen Analyse eine Schlüsselwort-basierte Suche in<br />
A-klassifizierten Journals und Konferenzen durchgeführt. Dabei wurden dieselben<br />
Schlüsselwörter verwendet, wie zu Beginn des Abschnitts beschrieben, allerdings ohne<br />
die Einschränkung auf AIS bzw. Agilität. Um entsprechende Quellen aus der Praxis zu<br />
338 Vgl. Conboy 2009, S. 330.
Stand der Forschung und verwandte Arbeiten 77<br />
ermitteln, wurde eine Schlüsselwort-basierte Suche auf Google Scholar angewendet.<br />
Dabei standen zunächst Quellen im Mittelpunkt, die unmittelbar in Bezug zur agilen<br />
AIS-Entwicklung stehen (Schlüsselwörter analog der initialen Suche oben). Innerhalb<br />
dieser Ergebnisse wurde anschliessend eine von WEBSTER UND WATSON 339 vorgeschlagene<br />
Quellenanalyse („Backward Search“) durchgeführt. Mit dieser Vorgehensweise<br />
konnten zwei Aspekte sichergestellt werden: Einerseits schliesst diese Datenbank<br />
auch Fachliteratur, die in Buchform publiziert wurde, mit ein und andererseits<br />
werden auch Praxisbeiträge berücksichtigt. Somit konnten klassische Ansätze für die<br />
Entwicklung von AIS (bspw. DEVLIN, INMON, KIMBALL ET AL. 340 ) mit einbezogen<br />
werden. Aber auch Standardwerke, die sich mit agilen Entwicklungsmethoden auseinandersetzen<br />
(bspw. SCHWABER UND BEEDLER, COCKBURN 341 ) konnten so in die Analyse<br />
aufgenommen werden.<br />
Total ergaben sich bei der Suche insgesamt 58 Artikel, wobei 27 davon wissenschaftlicher<br />
Herkunft sind und 31 der Praxis zugerechnet werden können (vgl. Abbildung<br />
18). Alle Beiträge wurden in einem letzten Schritt durch eine detailliertere Textanalyse<br />
nochmals auf ihre Relevanz überprüft. Dabei wurden Beiträge ausgeschlossen, die<br />
zwar die entsprechenden Schlagworte beinhalten, sich jedoch nicht mit dem eigentlichen<br />
Thema dieses Beitrages auseinandersetzen (bspw. setzten sich GROSSMANN ET<br />
AL. 342 mit dem Thema Data Mining auseinander). So können für die detaillierte Literaturanalyse<br />
insgesamt 29 Artikel identifiziert werden. Drei davon werden aufgrund ihrer<br />
Ähnlichkeit bzw. der gleichen Herkunft gruppiert. Damit können 26 Ansätze in die<br />
weitere Betrachtung mit aufgenommen werden 343 .<br />
3.1.2 Bewertungskriterien<br />
Um eine fundierte und stringente inhaltliche Analyse der zuvor identifizierten Literatur<br />
gewährleisten zu können, soll in diesem Abschnitt ein Untersuchungsrahmen abgeleitet<br />
werden. Der natürliche Ausgangspunkt für die Definition eines solchen Rahmens<br />
liegt in der agilen Softwareentwicklung. Allgemein akzeptierte Untersuchungsrahmen<br />
oder entsprechende Theorien existieren in dieser Domäne jedoch nicht. „Agile development<br />
lacks theoretical underpinnings and scientific evidence that support its claimed<br />
339 Vgl. Webster, Watson 2002, S. xv ff.<br />
340 Vgl. Devlin 1997; Inmon 2002; Kimball, Ross 2002; Kimball et al. 2008.<br />
341 Vgl. Cockburn 2002; Schwaber, Beedle 2001.<br />
342 Vgl. Grossmann et al. 2002.<br />
343 Vgl. Tabelle 4.
78 Stand der Forschung und verwandte Arbeiten<br />
benefits and key principles“ 344 . „To fill this gap, researchers have called for structured,<br />
rigorous empirical studies on agile development with a common research agenda” 345 .<br />
Daher soll im Folgenden auf der Arbeit von LEE UND XIA 346 aufgebaut werden, die<br />
sich basierend auf einer umfangreichen Literaturanalyse mit den fundamentalen Konzepten<br />
der agilen Softwareentwicklung auseinandersetzen. Komplementär dazu werden<br />
etablierte Theorien aus dem IS-Umfeld zur Ableitung des Untersuchungsrahmens<br />
herangezogen.<br />
LEE UND XIA 347 identifizieren drei fundamentale Konzepte zur Analyse der (agilen)<br />
Entwicklung. Die Charakteristik des Entwicklungsteams beeinflusst massgeblich den<br />
eigentlichen Entwicklungsprozess. Dieser ist gekennzeichnet durch die Art und Weise<br />
der Entwicklungspraktiken bzw. den allgemeinen Ablauf der Entwicklung. Der Entwicklungsprozess<br />
beeinflusst wiederum das Ergebnis der Entwicklung. Dieses wird<br />
durch die Erfüllung der (funktionalen und nicht-funktionalen) Anforderungen sowie<br />
die Einhaltung von Budget und Zeitplan bestimmt.<br />
Ausgangspunkt:<br />
Lee & Xia (2010)<br />
Organizational<br />
Culture Theory<br />
PMBoK Guide<br />
Strukturierungsrahmen<br />
Team<br />
Team<br />
Design<br />
Design<br />
Prozess<br />
Teilprozesse<br />
Umsetzung<br />
Umsetzung<br />
Management<br />
Management<br />
Explizite Prinzipien<br />
& Implizite Normen<br />
Kultur<br />
Ergebnis<br />
Output<br />
Abbildung 19: Inhaltlicher Untersuchungsrahmen für die Literaturanalyse<br />
Um die eigentliche Entwicklung genauer analysieren zu können, soll der Entwicklungsprozess<br />
auf Basis der Organisational Culture Theory 348 weiter konzeptualisiert<br />
werden. Diese unterscheidet zwischen Artefakten, d.h. sichtbaren Strukturen und Pro-<br />
344 Vgl. Erickson et al. 2005 zit. in Lee, Xia 2010, S. 89.<br />
345 Vgl. Dyba, Dingsøyr 2008 zit. in Lee, Xia 2010, S. 89.<br />
346 Vgl. Lee, Xia 2010.<br />
347 Vgl. Lee, Xia 2010.<br />
348 Vgl. Schein 1997.
Stand der Forschung und verwandte Arbeiten 79<br />
zessen, expliziten Prinzipien sowie impliziten Normen und Werten. Artefakte sind im<br />
Kontext der agilen Entwicklung insbesondere die Teilprozesse bzw. Phasen des agilen<br />
Entwicklungsprozesses. Die expliziten Prinzipien sowie impliziten Normen und Werte<br />
bestimmen die Kultur, die den Entwicklungsprozess prägt.<br />
Um wiederum die Teilprozesse der (agilen) Entwicklung differenziert untersuchen zu<br />
können, soll auf dem <strong>Projektmanagement</strong>-Standard PMBoK Guide 349 aufgebaut werden.<br />
Dieser Standard wird durch das American National Standards Institute (ANSI)<br />
und das Institute of Electrical and Electronics Engineers (IEEE) anerkannt. Der Standard<br />
gliedert den Entwicklungsprozess in vier grundlegende Phasen. Um den Untersuchungsrahmen<br />
nicht zu komplex zu gestalten, werden diese im Folgenden zu zwei<br />
Konzepten zusammengefasst: Design („Identify“ und „Design“) und Umsetzung<br />
(„Construct“ und „Evaluate“). Zusätzlich zu den grundlegenden Phasen beschäftigt<br />
sich der Standard mit dem Management des Entwicklungsprozesses, d.h. der Planung,<br />
Steuerung und Kontrolle der eigentlichen Entwicklungsaktivitäten.<br />
Konzept Beschreibung Referenzen<br />
Team<br />
Design<br />
Umsetzung<br />
Managenagement<br />
Kultur<br />
Output<br />
Team repräsentiert die Charakteristika des Entwicklungsteams.<br />
Dies beinhaltet u.a. dessen Zusammensetzung, Erfahrung und<br />
Organisation.<br />
Das Design umfasst die Aktivitäten und Prinzipien, die sich auf die<br />
Spezifikation der Anforderung beziehen und fundamentale Grundlage<br />
einer Entwicklungsvorgehensweise bilden.<br />
Die Umsetzung umfasst die Aktivitäten und Prinzipien, die sich auf<br />
die Implementierung der Anforderung beziehen und die fundamentale<br />
Grundlage einer Entwicklungsvorgehensweise bilden.<br />
Das Management umfasst die Aktivitäten und Prinzipien, die sich<br />
auf die Planung, Steuerung und Kontrolle des Entwicklungsprozesses<br />
beziehen und die fundamentale Grundlage einer Entwicklungsvorgehensweise<br />
bilden.<br />
Die Kultur umfasst explizite Prinzipien und implizite Normen und<br />
Werte, die fundamentale Grundlage einer Entwicklungsvorgehensweise<br />
bilden.<br />
Output repräsentiert das Ergebnis der Entwicklung, d.h. die Erfüllung<br />
der (funktionalen und nicht-funktionalen) Anforderungen<br />
sowie die Einhaltung von Budget und Zeitplan.<br />
Tabelle 3: Beschreibung der Konzepte<br />
Beck et al. 2001a; Cockburn,<br />
Highsmith 2001; Highsmith<br />
2004; Lee, Xia 2010<br />
Beck et al. 2001a; Lee, Xia<br />
2010; Project Management<br />
Institute 2008<br />
Beck et al. 2001a; Henderson-Sellers,<br />
Serour 2005;<br />
Lee, Xia 2010; Project Management<br />
Institute 2008<br />
Beck et al. 2001a; Erickson<br />
et al. 2005; Lee, Xia 2010;<br />
Project Management Institute<br />
2008<br />
Beck et al. 2001a; Lee, Xia<br />
2010; Schein 1997<br />
Highsmith 2004; Kerzner<br />
2009; Lee, Xia 2010; Mitchell<br />
2006<br />
Der Untersuchungsrahmen umfasst damit sechs zentrale Konzepte: Team, Design,<br />
Umsetzung, Management, Kultur und Output (vgl. Abbildung 19). Diese Konzepte<br />
349 Vgl. Project Management Institute 2008 und Abschnitt 2.3.3.
80 Stand der Forschung und verwandte Arbeiten<br />
bilden das Fundament der Literaturbewertung sowie die Basis für die Definition des<br />
Fragebogens in Kapitel 4. Um die Konzepte weiter zu konkretisieren, werden diese um<br />
konkrete Fragen bzw. Aspekte angereichert. Tabelle 3 beschreibt die abgeleiteten<br />
Konzepte und führt jeweils zentrale Quellen an.<br />
Neben den erarbeiteten inhaltlichen Aspekten wird als zweite Komponente der Fokus<br />
des Ansatzes aufgeführt („AIS“ und/oder „Agilität“). Diese Kriterien werden zur Steigerung<br />
der Übersichtlichkeit aufgrund der unterschiedlichen Herkunft der Ansätze<br />
herangezogen 350 .<br />
Neben den inhaltlichen Bewertungskriterien wurden die Ansätze zusätzlich hinsichtlich<br />
ihres konkreten Unterstützungsgrads untersucht. Dabei wurde die Frage gestellt, in<br />
welchem Umfang der Ansatz eine entsprechende Methode (Kriterium „Methode“)<br />
bzw. ein entwickeltes (Referenz-)Modell (Kriterium „Modell“) als Gestaltungshilfe<br />
bietet 351 . Ausserdem wurde überprüft, ob der jeweilige Ansatz situationsspezifische<br />
Faktoren berücksichtigt (Kriterium „Situativität“) 352 .<br />
3.2 Vorstellung ausgewählter Publikationen<br />
Im Folgenden werden drei ausgewählte Ansätze für die klassische und agile Entwicklung<br />
im Umfeld AIS beschrieben. Es handelt sich hier einerseits um den verbreitetsten<br />
in der klassischen Domäne (KIMBALL ET AL.) sowie um die Arbeit von MOSS UND AT-<br />
RE und andererseits um den grossen und bekannten Ansatz zur agilen Entwicklung von<br />
AIS (HUGHES). Sämtliche Ansätze sind in der Bewertung in Tabelle 4 relativ hoch<br />
eingestuft. Dies ist der Grund, weshalb die Ansätze genauer vorgestellt werden.<br />
3.2.1 HUGHES: Agile Data Warehousing<br />
Der Ansatz nach HUGHES 353 adaptiert Scrum auf die Domäne von AIS. Ausgehend<br />
vom generischen Scrum 354 werden eine Reihe von Techniken vorgeschlagen, wie das<br />
agile Prinzip auf die AIS-Entwicklung übertragen werden kann, wie z.B. Schätzverfahren<br />
für die Aufgabenplanung oder Pipelining von Arbeitspaketen zur parallelen<br />
Entwicklung verschiedener, grösserer Aufgaben in unterschiedlichen Teams unter Berücksichtigung<br />
der fixen Sprintlängen. Der Ansatz schlägt ausserdem Reifestufen für<br />
die Etablierung einer agilen Entwicklung für AIS vor. Somit können einzelne Elemen-<br />
350 Vgl. Abschnitt 3.1.1.<br />
351 Vgl. auch Abschnitt 1.3.2.<br />
352 Für das SME vgl. Abschnitt 2.1.3.<br />
353 Vgl. Hughes 2008.<br />
354 Vgl. Abschnitt 2.4.
Stand der Forschung und verwandte Arbeiten 81<br />
te agiler Entwicklung wie bspw. in der ersten Stufe die Dekomposition von User Stories<br />
und Epics 355 und die agile Schätzung geübt werden, bevor die nächste Stufe erreicht<br />
wird. So lassen sich kontinuierlich Fortschritte erzielen und bestehende Praktiken<br />
festigen, ohne Gefahr zu laufen, in alte Wasserfall-Muster zurück zu fallen. Der<br />
Ansatz geht auch auf die geographische Aufteilung der Teams, wenn nicht alle Mitglieder<br />
am selben Ort arbeiten können, ein. HUGHES schlägt in diesem Fall die geographische<br />
Trennung nach Frontend- und Backend-Team vor. Neben der vom klassischen<br />
Scrum vorgeschlagenen Kernrollen „Product Owner“, „Scrum Master“ und „Team“<br />
schlägt HUGHES zusätzlich zwei Rollen vor, die AIS-spezifisch sind. Diese sind ein<br />
„Solution Architect 356 “ der den Product Owner bei technischen Fragen entlastet und<br />
bspw. Anforderungen verwaltet und User Stories in Entwickler Stories übersetzt, und<br />
der „Data Architect 357 “, der für die Definition der Schnittstellen verantwortlich ist.<br />
Insgesamt betrachtet bietet der Ansatz nach HUGHES eine Sammlung von Techniken,<br />
wie Scrum auf AIS-Projekte adaptiert werden können. Der Fokus liegt dabei allerdings<br />
in erster Linie auf der Entwicklung von Data Marts und Frontends und weniger auf der<br />
Strukturierung und Integration von Daten. Der Ansatz sieht keine situationsspezifischen<br />
Anpassungen vor.<br />
3.2.2 KIMBALL ET AL.: The Data Warehouse Lifecycle Toolkit<br />
Der Ansatz nach KIMBALL ET AL. 358 kann als einer der klassischen Ansätze für die<br />
Entwicklung von DWH-Systemen bezeichnet werden. Es handelt sich dabei um ein<br />
Vorgehensmodell, welches sich am Wasserfall-Ansatz orientiert. Dabei ist der Ansatz<br />
zugeschnitten auf die AIS-Domäne und sehr implementierungsorientiert. Er besitzt die<br />
Eigenschaften eines Lebenszyklus-Modells („The Data Warehouse Lifecyle Toolkit“)<br />
und ist partiell iterativ gestaltet. Der Ansatz spezifiziert eine Vielzahl von Entwurfsaktivitäten,<br />
die in einem aggregierten Vorgehensmodell zusammengefasst sind. Grundsätzlich<br />
ist das Vorgehen in die sechs Phasen „Programm-/Projektplanung“, „Anforderungsdefinition“,<br />
„Design und Realisierung“, „Einführung“, „Wachstum und Betrieb“<br />
sowie über den gesamten Lebenszyklus hinweg das „Programm-/<strong>Projektmanagement</strong>“.<br />
Die Phase „Design und Realisierung“ verläuft dabei in drei Tracks, dem Technologie-<br />
355 Epics und User Stories sind Bezeichnungen für Anforderungen unterschiedlichen Detaillierungsgrads (vgl.<br />
hierzu Abschnitt 2.4.5).<br />
356 Die Rolle des Solution Architect wird in der zu konstruierenden Methode durch die technische Projektleitung<br />
abgedeckt (vgl. Abschnitt 6.3.8.2).<br />
357 Die Rolle des Data Architect wird in der zu konstruierenden Methode durch die Zusammenarbeit zwischen<br />
Product Owner und technischer Projektleitung abgedeckt (vgl. Abschnitt 6.3.8.2).<br />
358 Vgl. Kimball et al. 2008.
82 Stand der Forschung und verwandte Arbeiten<br />
Track im Rahmen dessen die Infrastruktur, sowie Hard- und Softwareaspekte behandelt<br />
werden, dem Daten-Track mit der dimensionalen Modellierung, dem physischen<br />
Design und den ETL-Schnittstellen und dem BI-Applikations-Track, der die <strong>analytische</strong>n<br />
Applikationen entwickelt. Den Entwurfsaktivitäten werden Rollen zugewiesen,<br />
die nach „Core Team“, „Coaches“, „Specialists“, „Front Office“ und „Free Agents“<br />
gruppiert werden. Auch wenn keine Techniken explizit aufgeführt werden, sind diese<br />
implizit durch die detaillierte Beschreibung der Aktivitäten implizit ableitbar. Die Vorlagen<br />
für die Entwurfsergebnisse sind sehr detailliert entlang dem Vorgehensmodell<br />
spezifiziert. Es ist keine situative Anpassung vorgesehen. Aufgrund des iterativen Charakters,<br />
kann das Vorgehensmodell für Erstentwicklungsprojekte einmal und bei Weiterentwicklungsprojekten<br />
jeweils ein weiteres Mal durchlaufen werden.<br />
Der Ansatz nach KIMBALL ET AL. gilt als Bottom-Up-Ansatz, d.h. es werden ausgehend<br />
von den Data Marts, deren Anforderungen durch die Endnutzenden definiert<br />
werden, die Schnittstellen zu den Quellsystemen und ggf. des DWH entwickelt. So<br />
gesehen eignet sich das Vorgehen, wenn das System zukünftig ausgebaut werden soll,<br />
d.h. es wird heutigen Agilitäts-Anforderungen zumindest teilweise gerecht.<br />
3.2.3 MOSS UND ATRE: Business Intelligence Roadmap<br />
Beim Ansatz nach MOSS UND ATRE 359 handelt es sich um einen sehr detaillierten Projektstrukturplan-Ansatz<br />
für AIS-Projekte, der stark wasserfallorientiert ist. Der Ansatz<br />
ist sehr implementierungsorientiert und bietet eine praxisorientierte Schritt-für-Schritt-<br />
Anleitung für die Entwicklung eines AIS. Es wird eine Vielzahl AIS-spezifischer Entwurfsaktivitäten<br />
spezifiziert. Diese sind in sechs Phasen unterteilt, „Rechtfertigung“,<br />
„Planung“, „Analyse“, „Design“, „Entwicklung“ und „Einführung“. In den Realisierungsphasen<br />
(„Planung“, „Analyse“, „Entwicklung“) werden drei unterschiedliche<br />
Perspektiven parallel abgehandelt. Diese sind „Backend“, „Frontend“ und „Metadata“.<br />
Innerhalb der Phasen werden 16 Schritte vorgeschlagen, entlang derer auch die Vorlagen<br />
für die Entwurfsergebnisse definiert werden. Neben dem Schritt „Business Case“<br />
in Phase „Rechtfertigung“ und den Schritten „Projektplanung“ und „Infrastruktur Evaluation“<br />
in der Phase „Planung“ sind insbesondere die Teilschritte in den Realisierungsphasen<br />
spezifisch für AIS. Die Phase „Analyse“ beinhaltet die Schritte „Projektanforderungsdefinition“,<br />
„Datenanalyse“, „Prototyping“ und „Metadaten-Repository<br />
Analyse“, die Phase „Design“ beschäftigt sich mit „Datenbank Design“, „ETL 360 De-<br />
359 Vgl. Moss, Atre 2003.<br />
360 Extract, Transform, Load, der Prozess, der die relevanten Daten aus den verschiedenen Quellen extrahiert,<br />
sie in das Schema und Format der Zieldatenbank transformiert und schliesslich in die Zieldatenbank lädt.
Stand der Forschung und verwandte Arbeiten 83<br />
sign“ und „Metadaten-Repository Design“ und die Phase „Entwicklung“ beinhaltet die<br />
Schritte „ETL-Entwicklung“, „Applikationsentwicklung“, „Data Mining“ und „Metadata-Repository<br />
Entwicklung“. In der Phase „Einführung“ werden die „Implementierung<br />
und Übergabe“ und die „Release Evaluation“ behandelt.<br />
MOSS UND ATRE definieren eine Vielzahl AIS-spezifischer Rollen, die in die drei Rollengruppen<br />
„Core Team“, „Extended Team“ und „Additional Roles“ aufgeteilt werden.<br />
Es findet sich jedoch keine konsistente Beschreibung der Rollen an einer einzelnen<br />
Stelle, was die Übersicht erschwert. Gleichzeitig wird auch hier kein Fokus auf<br />
Querschnittsaufgaben gelegt. Der aktive Einbezug der Fachbereiche findet in diesem<br />
Ansatz keine besondere Beachtung.<br />
Insgesamt ist der Ansatz von MOSS UND ATRE sehr detailliert und umfangreich. Er<br />
deckt sämtliche Aspekte der Entwicklung und Weiterentwicklung eines AIS feingranular<br />
ab, was diesen Ansatz sehr mächtig macht. Es sind keine situationsspezifischen<br />
Anpassungen möglich, so dass die Adaption der Methode auf kleine Projekte herausfordernd<br />
ist.<br />
3.3 Zusammenfassende Bewertung der untersuchten Publikationen<br />
Folgender Abschnitt stellt, basierend auf dem in Abschnitt 3.1.2 entwickelten Rahmenwerk,<br />
eine zusammenfassende Gegenüberstellung aller identifizierten Publikationen<br />
dar. Dieses Rahmenwerk sowie die Angaben zum Fokus der Ansätze und die forschungsmethodischen<br />
Aspekte (vgl. Abschnitt 3.1.2) erlauben dabei eine direkte Vergleichbarkeit<br />
der einzelnen Ansätze.<br />
In Tabelle 4 werden die Bewertungsergebnisse zusammenfassend dargestellt. Dabei<br />
reicht das Spektrum der Adressierung der einzelnen Kernbereiche von vollständig<br />
adressiert (ausgefüllte Kreisfläche) bis hin zu nicht adressiert (leere Kreisfläche). Zu<br />
beachten ist, dass eine herausragende Bewertung nur dann erzielt werden kann, wenn<br />
sowohl die AIS-Besonderheiten als auch die Agilität durch den Ansatz entsprechend<br />
adressiert werden. Wesentliche Ergebnisse der Analyse sind insbesondere folgende:<br />
Es gibt zahlreiche Ansätze, die sehr detailliert auf den Aspekt Team eingehen 361 . Andere<br />
Ansätze wie z.B. INMON 362 adressieren diesen Aspekt hingegen kaum. Im Allgemeinen<br />
kann jedoch festgehalten werden, dass dieser Aspekt im Vergleich zu den anderen<br />
Kernaspekten relativ gut abgedeckt ist.<br />
361 Bspw. Hughes 2008; Moss, Atre 2003; Vidgen, Wang 2009.<br />
362 Vgl. Inmon 2002.
84 Stand der Forschung und verwandte Arbeiten<br />
Ähnlich viele Arbeiten adressieren den Bereich Design in agilen AIS-Projekten. Auffällig<br />
ist jedoch, dass eine entsprechende Tiefe lediglich bei HUGHES und MOSS UND<br />
ATRE 363 vorhanden ist. Zahlreiche Arbeiten sind eher genereller Natur und beschränken<br />
sich auf Grundsätze und Techniken, die hinter der Designphase stehen. So geht<br />
bspw. COCKBURN 364 in erster Linie auf Prinzipien und oft auftretende Fehler in der<br />
Design-Phase (bzw. wie diese vermieden werden können) ein. Dies geschieht allerdings<br />
auf einem sehr generischen Niveau für alle agilen Methoden und ohne AIS-<br />
Fokus.<br />
Alle Arbeiten adressieren die Umsetzung. Allerdings zeigt die detaillierte Analyse,<br />
dass es sich hierbei selten um konkrete Vorgehensweisen handelt. Vielmehr werden<br />
grundsätzliche Praktiken vermittelt oder aber sehr spezifische Aspekte beleuchtet.<br />
AMBLER oder auch CORR UND STAGNITTO 365 behandeln bspw. die agile Datenbankentwicklung<br />
sehr fokussiert. Die Entwicklung von Benutzendenschnittstellen bzw.<br />
Berichten wird dabei jedoch völlig ausser Acht gelassen. GREY bzw. GOEDE UND<br />
HUISMAN 366 wiederum testen für jede der bekannten agilen Methoden, ob diese für den<br />
AIS-Kontext adaptierbar sind, jedoch ohne konkrete Vorgehensweisen vorzuschlagen.<br />
HUGHES sowie MOSS UND ATRE 367 decken den Bereich Umsetzung relativ gut ab. Bei<br />
HUGHES allerdings ist festzustellen, dass dieser Ansatz vor allem auf die Umsetzung<br />
von Data Marts eingeht und somit das Thema DWH nur partiell abdeckt. MOSS UND<br />
ATRE beschreiben zwar detailliert die AIS-Umsetzung, jedoch wird relativ schwach<br />
auf den Aspekt der Agilität eingegangen.<br />
Der Bereich Management wird sehr unterschiedlich adressiert. Während einige Ansätze<br />
klare und AIS-spezifische Vorgehen und Prinzipien vorschlagen 368 , beschränken<br />
sich andere Ansätze eher auf Generelles 369 . Diese Aspekte können als Input verwendet,<br />
müssen jedoch an den AIS-Kontext angepasst werden.<br />
Wie das Agile Manifest 370 zeigt, ist die Kultur ein zentrales Element in der agilen<br />
Softwareentwicklung. Im Allgemeinen wird dieser Aspekt, zumindest im AIS-<br />
Kontext, jedoch eher vernachlässigt. Zwar wird Kultur von vielen Standardansätzen<br />
363 Vgl. Hughes 2008; Moss, Atre 2003.<br />
364 Vgl. Cockburn 2002.<br />
365 Vgl. Ambler 2003; Corr, Stagnitto 2011.<br />
366 Vgl. Goede, Huisman 2010; Grey 2006.<br />
367 Vgl. Hughes 2008; Moss, Atre 2003.<br />
368 Vgl. bspw. Hughes 2008; Moss, Atre 2003.<br />
369 Vgl. bspw. Cao et al. 2009; Maruping et al. 2009; Schwaber, Beedle 2001.<br />
370 Vgl. Beck et al. 2001a.
Stand der Forschung und verwandte Arbeiten 85<br />
für Agilität adressiert 371 , allerdings beschränkt sich diese Adressierung oftmals auf<br />
grundlegende Prinzipien und Praktiken bzw. kulturelle Voraussetzungen, die für den<br />
Erfolg agiler Methoden in Unternehmen notwendig sind. Die AIS-spezifischen Ansätze,<br />
die sich nicht mit dem Konzept der Agilität befassen, gehen gar nicht oder nur ganz<br />
wenig auf die Kultur ein 372 . Bei den AIS-Ansätzen, die Agilität mit einbeziehen, wird<br />
Kultur zwar in Ansätzen adressiert 373 , jedoch nur HUGHES setzt sich fundiert mit der<br />
Rolle der Kultur in AIS-Projekten auseinander. Aufgrund der hohen Tragweite des<br />
Kulturaspekts in agilen Projekten besteht hier grosses Erweiterungspotenzial.<br />
Im Allgemeinen kann festgestellt werden, dass die Literatur dem Bereich Output eher<br />
weniger Beachtung schenkt. Es existieren zwar im Agilen Manifest gewisse Aspekte,<br />
die den Output betreffen (bspw. durch „working software over comprehensive documentation“<br />
oder in den Prinzipien des Agilen Manifests). Allerdings handelt es sich<br />
hier eher um Prinzipien und Guidelines als um konkrete Vorgehen zur Steigerung des<br />
Outputs. Entsprechend wird in den betrachteten Ansätzen vor allem auf diese Prinzipien<br />
referenziert. Lediglich Ansätze wie KIMBALL ET AL. oder MOSS UND ATRE 374 gehen<br />
detaillierter darauf ein, wie der Output in AIS-Projekten konkret verbessert werden<br />
kann.<br />
Bei der Auswertung der forschungsmethodischen Aspekte fällt auf, dass einige der Ansätze<br />
ein methodenähnliches Vorgehen vorschlagen. Allerdings ist die Bandbreite des<br />
Detaillierungsgrads sehr weit. Er reicht von fast vollständigen Methoden mit Rollenmodellen<br />
und Dokumentationsmodellen 375 bis hin zu hochgenerischen Vorgehensmodellen.<br />
Ausserdem fällt auf, dass nur wenige der Ansätze auf situationsspezifische Aspekte<br />
in AIS-Projekten eingehen 376 .<br />
371 Vgl. bspw. Beck et al. 2001a; Cockburn 2002; Dingsøyr et al. 2010; Schwaber, Beedle 2001.<br />
372 Vgl. bspw. Inmon 2002; Kimball et al. 2008; Shin 2002.<br />
373 Vgl. bspw. Goede, Huisman 2010; Graziano 2010; Grey 2006; Hughes 2008; Mulder 2010.<br />
374 Vgl. Kimball et al. 2008; Moss, Atre 2003.<br />
375 Vgl. bspw. Kimball et al. 2008; Moss 2001; Moss, Atre 2003; Shin 2002.<br />
376 Vgl. bspw. Cao et al. 2009; Fitzgerald et al. 2006; Maruping et al. 2009.
AIS<br />
Agilität<br />
Team<br />
Design<br />
Umsetzung<br />
Management<br />
Kultur<br />
Output<br />
Methode<br />
Modell<br />
Sit. Aspekte<br />
86 Stand der Forschung und verwandte Arbeiten<br />
Fokus<br />
Inhaltliche Aspekte bzgl.<br />
AIS Agilität<br />
Forsch.<br />
meth.<br />
Aspekte<br />
4 vollumfänglich<br />
adressiert<br />
3 grösstenteils<br />
adressiert<br />
Untersuchter Ansatz<br />
Ambler 2003<br />
Augustine et al. 2005<br />
Beck et al. 2001a<br />
Beck et al. 2001b<br />
Brobst et al. 2008<br />
Cao et al. 2009<br />
Cao et al. 2010<br />
Cockburn 2002<br />
Collier und Highsmith<br />
2004<br />
Conboy 2009<br />
Corr, Stagnitto 2011<br />
Dingsoyr et al. 2010<br />
Finger 2011<br />
Fitzgerald et al. 2006<br />
Goede und Huisman<br />
2010<br />
Grey 2006<br />
2 teilweise<br />
adressiert<br />
1 in Ansätzen<br />
adressiert<br />
0 nicht adressiert<br />
Inhaltliche Beschreibung des Ansatzes<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Sammlung von Techniken, die agile Datenbankentwicklung<br />
unterstützen.<br />
Sehr detailliert und praxisorientiert.<br />
Das Paper identifiziert Prinzipien und Grundwerte,<br />
die für ein erfolgreiches agiles <strong>Projektmanagement</strong><br />
notwendig sind.<br />
Es geht insbesondere auf mögliche Schwierigkeiten<br />
für Projektmanager bei der Umstellung<br />
auf agiles <strong>Projektmanagement</strong> ein.<br />
Grundlegendes Manifest mit den Werten der<br />
Agilität.<br />
Auf dem Manifest aufbauende, detailliertere<br />
Aufstellung der Grundprinzipien, denen agile<br />
Entwicklung/Projekte folgen sollten.<br />
Ein Praktikerbeitrag, der das Sandboxing als<br />
Element für agile DWH-Entwicklung behandelt<br />
und vorstellt.<br />
Das Paper beschäftigt sich mit der Adaption<br />
agiler Methoden für verschiedene Projekte.<br />
Es geht ausserdem auch auf Herausforderungen<br />
ein, die sich in verschiedenen Bereichen<br />
der agilen Entwicklung ergeben.<br />
Das Paper baut ein System Dynamics Modell<br />
377 , welches die Abhängigkeiten und Einflüsse<br />
der Praktiken agiler Methoden widerspiegelt.<br />
Das Modell basiert auf einer Literaturanalyse<br />
und neun Fallstudien.<br />
Das Buch behandelt agile Softwareentwicklung<br />
im Allgemeinen und geht dabei insbesondere<br />
auf die Prinzipien und auf den Faktor Team und<br />
Individuen ein.<br />
Es gibt einen guten Überblick über das Agile<br />
Manifest.<br />
Der Artikel motiviert, warum agile Prinzipien auf<br />
DWH übertragen werden müssen und gibt neun<br />
Praktiken für die Adaption.<br />
Der Artikel entwickelt eine Definition für agile<br />
IS-Entwicklung, basierend auf einer Literaturanalyse<br />
Der Fokus des Artikels liegt auf Beiträgen aus<br />
der Praxis.<br />
Das Buch fokussiert auf agile Modellierung von<br />
DWH.<br />
Dabei wird eine Methode (BEAM) vorgestellt,<br />
die es erlaubt mittels agiler Techniken Anforderungen<br />
für das Datenmodell des DWH zu ermitteln.<br />
Literaturanalyse zu agiler Entwicklung und<br />
Übersicht über agile Methoden.<br />
Es untersucht die Abdeckung der Methoden<br />
bezüglich Projektlebenszyklus.<br />
Buchkapitel zur Definition und Motivation von<br />
agiler BI.<br />
Abgrenzung agile Entwicklung und agiler<br />
Betrieb.<br />
Die Arbeit befasst sich mit dem „Tailoring“<br />
agiler Methoden am Beispiel von Scrum und<br />
XP.<br />
Es werden verschiedene Fallstudien vorgestellt,<br />
in dessen Rahmen eine solche Anpassung<br />
durchgeführt wurde.<br />
Arbeit, die die Ansätze von KIMBALL ET AL. und<br />
INMON auf ihre Kombinierbarkeit mit den sieben<br />
bekanntesten agilen Methoden untersucht.<br />
Mittels eines Experiments wird auf Basis von<br />
KIMBALL ET AL. in Kombination mit jeweils einer<br />
der sieben agilen Methoden die Sinnhaftigkeit<br />
der Kombination untersucht.<br />
x x 2 2 2 1 1 1 0 1 0<br />
x 2 1 0 1 1 0 0 0 0<br />
x 1 1 1 1 2 1 0 0 0<br />
x x 1 0 2 0 0 2 0 1 0<br />
x 2 1 2 2 1 1 0 0 2<br />
x 2 2 1 1 0 2 0 0 1<br />
x 3 2 2 2 2 1 1 0 0<br />
x x 2 2 2 0 0 1 0 0 0<br />
x 1 1 1 1 1 0 0 0 0<br />
x x 1 3 3 1 1 2 0 0 0<br />
x 2 0 0 0 2 0 0 0 0<br />
x x 1 1 1 1 0 1 0 2 0<br />
x 1 1 1 1 1 1 2 0 3<br />
x x 2 2 2 2 2 2 2 0 0<br />
377 Vgl. Forrester 1961.
AIS<br />
Agilität<br />
Team<br />
Design<br />
Umsetzung<br />
Management<br />
Kultur<br />
Output<br />
Methode<br />
Modell<br />
Sit. Aspekte<br />
Stand der Forschung und verwandte Arbeiten 87<br />
Fokus<br />
Inhaltliche Aspekte bzgl.<br />
AIS Agilität<br />
Forsch.<br />
meth.<br />
Aspekte<br />
4 vollumfänglich<br />
adressiert<br />
3 grösstenteils<br />
adressiert<br />
Untersuchter Ansatz<br />
Graziano 2010<br />
Hughes 2008<br />
Inmon 2002<br />
Kimball et al. 2008<br />
Maruping et al. 2009<br />
Moss 2001<br />
Moss & Atre 2003<br />
Mulder 2010<br />
Murphy 2004<br />
Schatz und Abdelshafi<br />
2005<br />
Schwaber und Beedle<br />
2001<br />
Shin 2002<br />
Vidgen, Wang 2009<br />
2 teilweise<br />
adressiert<br />
1 in Ansätzen<br />
adressiert<br />
0 nicht adressiert<br />
Inhaltliche Beschreibung des Ansatzes<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
Die Arbeit motiviert zuerst den Bedarf nach<br />
agilen Methoden im AIS-Kontext.<br />
Anschliessend werden die zwölf Prinzipien des<br />
Agilen Manifests aufgenommen und auf den<br />
AIS-Kontext übertragen.<br />
Ansatz, der spezifisch auf den Einsatz agiler<br />
Methoden im Kontext BI eingeht.<br />
Ein relativ umfassender Ansatz, der viele<br />
Elemente der Agilität mit der Entwicklung von<br />
BI vereint.<br />
Der Ansatz fokussiert vor allem auf die Entwicklung<br />
von Reports und Data Marts, wenig auf die<br />
Entwicklung von DWH.<br />
Dieser Ansatz ist sehr stark wasserfallgeprägt<br />
und beschreibt die sequentielle Entwicklung<br />
von AIS-Lösungen.<br />
Das DWH wird als zentrales integrierendes<br />
Element verstanden, das als „Single Version of<br />
Truth“ fungiert.<br />
Dieser Ansatz deckt den gesamten DWH-<br />
Lebenszyklus ab.<br />
Er geht davon aus, dass ein DWH evolutionär<br />
entwickelt wird.<br />
Das Paper entwickelt die Hypothese, dass agile<br />
Methoden zu besseren Projektergebnissen führen.<br />
Moderierende Faktoren sind dabei hohe Benutzeranforderungsvolatilität<br />
und Output-, bzw.<br />
Selbstkontrolle.<br />
Work-breakdown Structure Ansatz, der wenig<br />
auf Agilität eingeht und den gesamten AIS-<br />
Lebenszyklus abdeckt.<br />
Der Ansatz ist sehr umfangreich.<br />
In der Arbeit wird mittels Action Research<br />
untersucht, ob der Einsatz von Scrum in der<br />
DWH-Entwicklung sinnvoll ist.<br />
Die Resultate sind nicht sehr DWH spezifisch,<br />
bestätigen aber den Sinn des Einsatzes von<br />
Scrum im AIS-Umfeld.<br />
Das Paper gibt einen Überblick über den<br />
Nutzen von Scrum als <strong>Projektmanagement</strong>-<br />
Methode.<br />
Das Paper geht insbesondere auf die Werkzeuge,<br />
die in Scrum verwendet werden (Burn<br />
Down Charts, Daily Scrums, etc.), ein.<br />
Mittels einer Case Study zeigt dieses Paper,<br />
wie erfolgreich auf agile Entwicklungsmethoden<br />
umgestellt werden kann.<br />
Das Paper gibt auf allen Ebenen Tipps für den<br />
Umstieg. Es zeigt Erfolgsfaktoren, die den Umstieg<br />
auf Scrum vereinfachen.<br />
Ein Grundlagenwerk zu Scrum, welches den<br />
Ansatz sehr detailliert erläutert.<br />
Der Ansatz zeigt auch, wie Scrum für das<br />
<strong>Projektmanagement</strong> und Extreme Programming<br />
für die konkrete Umsetzung kombiniert werden<br />
können.<br />
Vorgehen für DWH-<strong>Projektmanagement</strong> mit<br />
den Phasen "initialize", "execution" und "closing".<br />
Die Methode geht explizit auch auf iteratives<br />
Vorgehen ein.<br />
Entwickelt ein Framework, das Enabler und<br />
organisatorische Elemente für den Einsatz agiler<br />
Methoden identifiziert.<br />
Gleichzeitig werden Anforderungen an agile<br />
Teams definiert. Es wird dabei ein Vergleich<br />
zwischen einem agilen Team und einem Team,<br />
was dem traditionellen Wasserfall-Ansatz folgt,<br />
in Form einer Fallstudie, herangezogen.<br />
x x 1 1 1 1 2 1 0 1 0<br />
x x 4 4 2 4 4 2 1 1 0<br />
x 0 3 3 2 0 2 2 1 0<br />
x x 2 3 3 2 1 2 3 0 0<br />
x 2 1 2 2 1 2 0 2 2<br />
x x 4 4 4 3 2 3 3 0 1<br />
x x 2 2 2 2 2 2 0 0 0<br />
x 1 1 1 1 1 1 1 0 0<br />
x 1 1 1 1 1 1 0 0 0<br />
x 2 2 2 2 2 1 2 0 1<br />
x 1 1 1 0 0 1 3 0 0<br />
x 3 0 1 0 0 1 0 1 0<br />
Tabelle 4: Übersicht und Bewertung der untersuchten Ansätze
88 Stand der Forschung und verwandte Arbeiten<br />
Zusammenfassend kann festgehalten werden, dass die untersuchte Literatur die, anhand<br />
der Bewertungskriterien formulierten, inhaltlichen und methodischen Anforderungen<br />
nur teilweise erfüllt. Zwar gibt es einige wenige Arbeiten, die punktuell eine<br />
hohe Abdeckung aufweisen, jedoch bietet kein Ansatz eine umfassende Betrachtung.<br />
Bezüglich forschungsmethodischer Aspekte ist die Abdeckung der identifizierten Kriterien<br />
noch geringer. Tabelle 4 stellt die Ergebnisse zusammenfassend dar.
Grundlagen für die Methodenentwicklung 89<br />
4 Grundlagen für die Methodenentwicklung<br />
Aus den Ausführungen in den vorangehenden Kapiteln und insbesondere aufgrund der<br />
in Abschnitt 1.2 formulierten Erkenntnisziele (E 1 und E 2 ) sowie der Analyse des<br />
Stands der Forschung (vgl. Kapitel 3), ergeben sich wesentliche Voraussetzungen für<br />
die Entwicklung einer situativen Methode für agiles <strong>Projektmanagement</strong> im Umfeld<br />
von AIS. Die zu konstruierende Methode muss anpassbar sein, um eine Vielzahl unterschiedlicher<br />
relevanter Situationen in der Praxis abdecken zu können. Gemäss des in<br />
Abschnitt 2.1.3 eingeführten SME, bildet die Ableitung von Projekttypen und Kontexttypen<br />
die Grundlage für die Identifikation relevanter Situationen. Diese können<br />
entweder aufgrund generischer Kataloge vordefinierter Situationsfaktoren gebildet<br />
werden 378 und/oder, wenn nicht ausreichend, mittels empirischer Befunde 379 ergänzt<br />
werden oder auf ebendiesen basieren. Im Folgenden werden Gestaltungsfaktoren bzw.<br />
Realisierungsformen für agiles <strong>Projektmanagement</strong> im Umfeld von AIS quantitativempirisch<br />
erhoben (Abschnitte 4.1 und 4.2) und daraus in Abschnitt 4.3 Projekttypen<br />
und Kontexttypen abgeleitet. Abschnitt 4.4 kombiniert beide zu Entwicklungssituationen.<br />
4.1 Gestaltungsfaktoren für agiles AIS-<strong>Projektmanagement</strong><br />
Gestaltungsfaktoren haben wesentlichen Einfluss auf die Methodenkonstruktion. Diese<br />
fassen einzelne Variablen zusammen, die die Ausgestaltung eines agilen <strong>Projektmanagement</strong>-Ansatzes<br />
für AIS beschreiben. Stark verdichtet lässt sich so der Entwicklungsstand<br />
eines Unternehmens im betrachteten Themenfeld charakterisieren.<br />
Für die Extraktion von Gestaltungsfaktoren wurde eine Faktorenanalyse, bzw. in diesem<br />
Fall Hauptkomponentenanalyse 380 gewählt. Es handelt sich hierbei um eine explorative<br />
Technik, da im Vorfeld der Untersuchung keine oder nur unzureichende Erwartungen<br />
bezüglich der Faktoren existierten 381 .<br />
Als Datenbasis für die Erhebung der Gestaltungsfaktoren und Realisierungsgrade diente<br />
eine Umfrage im Rahmen einer Praxiskonferenz Ende Mai 2011 mit dem Themenfokus<br />
„Business Intelligence & Data Warehousing: Geschäftsnutzen nachhaltig reali-<br />
378 Vgl. van Slooten, Hodes 1996, S. 32f.<br />
379 Vgl. Aier et al. 2008, S. 16ff.; Bucher, Winter 2009, S. o.S.<br />
380 Vgl. Backhaus et al. 2006, S. 293.<br />
381 Vgl. Backhaus et al. 2006, S. 330.
90 Grundlagen für die Methodenentwicklung<br />
sieren“ 382 . Diese wurde an ca. 120 Teilnehmende dieser Konferenz im deutschsprachigen<br />
Raum ausgehändigt. Von den 71 retournierten Umfragebogen wurden acht aufgrund<br />
unvollständiger oder widersprüchlicher Angaben aus der Auswertung ausgeschlossen.<br />
Daraus resultierte eine Anzahl von 63 Datensätzen, die verwendet werden<br />
konnten. Somit ergibt sich eine Antwortquote von ca. 52.5 %. Der Grossteil der Teilnehmenden<br />
verfügt über ein fundiertes Erfahrungswissen im Bereich AIS. So gaben<br />
76% der Befragten an, sich mehr als sechs Jahre Erfahrung im Umfeld von AIS zu<br />
bewegen. Tabelle 5 gibt einen Überblick über die Branchen und Unternehmensgrössen,<br />
aus denen die Umfrageteilnehmenden stammen. Auffallend ist, dass vor allem<br />
Grossunternehmen im Datensatz vertreten sind. So arbeiten 62.3% der Befragten in<br />
Unternehmen mit mehr als 1000 Mitarbeitenden (MA). Der Dienstleistungssektor ist<br />
mit knapp 47% die am häufigsten vertretene Branche.<br />
< 49 MA 50 bis 199 MA 200 - 999 MA 1000 - 5000 MA > 5000 MA<br />
Gesamt<br />
Finanzdienstleistungen 0 (0.0%) 0 (0.0%) 4 (6.6%) 5 (8.2%) 6 (9.8%) 15 (24.6%)<br />
Dienstleistungen 2 (3.3%) 4 (6.6%) 2 (3.3%) 1 (1.6%) 4 (6.6%) 13 (21.3%)<br />
Automobil 0 (0.0%) 1 (1.6%) 0 (0.0%) 1 (1.6%) 5 (8.2%) 7 (11.5%)<br />
Technologie, Medien, Telco 0 (0.0%) 2 (3.3%) 2 (3.3%) 1 (1.6%) 1 (1.6%) 6 (9.8%)<br />
Industrielle Produktion 0 (0.0%) 0 (0.0%) 1 (1.6%) 1 (1.6%) 3 (4.9%) 5 (8.2%)<br />
Sonstige 0 (0.0%) 2 (3.3%) 0 (0.0%) 2 (3.3%) 1 (1.6%) 5 (8.2%)<br />
Chemie/Pharma 1 (1.6%) 0 (0.0%) 1 (1.6%) 0 (0.0%) 1 (1.6%) 3 (4.9%)<br />
Gesundheitswesen 0 (0.0%) 0 (0.0%) 0 (0.0%) 2 (3.3%) 0 (0.0%) 2 (3.3%)<br />
Handel & Konsumgüter 0 (0.0%) 0 (0.0%) 0 (0.0%) 1 (1.6%) 1 (1.6%) 2 (3.3%)<br />
Energie-/Wasser-Versorgung 0 (0.0%) 0 (0.0%) 0 (0.0%) 1 (1.6%) 0 (0.0%) 1 (1.6%)<br />
Öffentliche Verwaltung 0 (0.0%) 0 (0.0%) 1 (1.6%) 0 (0.0%) 0 (0.0%) 1 (1.6%)<br />
Transport & Logistik 0 (0.0%) 0 (0.0%) 0 (0.0%) 0 (0.0%) 1 (1.6%) 1 (1.6%)<br />
Gesamt 3 (4.9%) 9 (14.8%) 11 (18.0%) 15 (24.6%) 23 (37.7%) 61 (100.0%)<br />
Tabelle 5: Zusammensetzung der Rückläufer nach Branche und Unternehmensgrösse 383<br />
Als Basis für den verwendeten Fragebogen wurde der in Kapitel 3.1.2 im Rahmen der<br />
Analyse des Stands der Forschung entwickelte Strukturierungsrahmen mit den sechs<br />
Kernelementen verwendet. Für die Entwicklung der Detailfragen wurden zunächst die<br />
zwölf Prinzipien des Agilen Manifests 384 herangezogen, da diese die Essenz der agilen<br />
Softwareentwicklung repräsentieren. Anschliessend wurden diese durch die über das<br />
Agile Manifest hinausgehenden Charakteristika von Scrum ergänzt. Scrum hat sich als<br />
der zentrale agile Ansatz in der Praxis etabliert und bietet sich daher auch im Kontext<br />
AIS als fundamentaler Ausgangspunkt an 385 . Schliesslich wurde zur Messung des Out-<br />
382 Die Veranstaltungsreihe wird an der Universität St. Gallen ausgetragen und dient in erster Linie dem Erfahrungs-<br />
und Wissensaustausch zwischen Praktikern, Experten und Wissenschaftlern. Es handelt sich dabei<br />
um eine eintägige Veranstaltung im Rahmen derer erfolgreiche Unternehmensvertreter ihre Erfahrungen zu<br />
den jeweiligen Themenbereichen teilen.<br />
383 Zwei Befragte machten keine Angaben zur Unternehmung, weshalb ein Total von 61 resultiert.<br />
384 Vgl. Beck et al. 2001b.<br />
385 Vgl. Hughes 2008 sowie Abschnitt 2.4.5.
Grundlagen für die Methodenentwicklung 91<br />
puts auf eine Forschungsarbeit von LEE UND XIA 386 zurückgegriffen. Diese beschreiben<br />
entsprechende Aspekte und Fragen. Gleichzeitig wurden, zusätzlich zu spezifischen<br />
Variablen zur agilen Entwicklung, allgemeine Rahmenbedingungen zum Unternehmen<br />
und der Struktur der <strong>analytische</strong>n Informationslandschaft hinzugenommen.<br />
Die Bewertung der einzelnen Items des Fragebogens erfolgte mithilfe einer fünfstufigen<br />
Likert-Skala von 0 („trifft gar nicht zu“) bis 4 („trifft vollständig zu“) zur Erfassung<br />
des Ist (derzeitiger Umsetzungsgrad) und Soll (angestrebte Umsetzungsabsicht).<br />
Der verwendete Fragebogen ist in Anhang A zu finden.<br />
Zur Prüfung, inwieweit sich der Datensatz für eine Faktorenanalyse eignet, wurde vor<br />
der Analyse entsprechend der zwei von DZIUBAN UND SHIRKEY vorgeschlagenen Kriterien<br />
vorgegangen. Diese definieren einerseits die Vorgabe, dass der Anteil der nichtdiagonalen<br />
Elemente der sogenannten Anti-Image-Kovarianzmatrix mit einem Wert<br />
ungleich null (bzw. > 0.09), weniger als 25% der gesamten Elemente ausmacht 387 . Andererseits<br />
wird als weiteres Gütemass das „Measure of Sampling Adequacy“ (MSA)<br />
genannt. Dieses ist auch als Kaiser-Mayer-Olkin-Kriterium (KMO-Kriterium) bekannt<br />
388 . Das KMO-Kriterium wird in der Literatur gemeinhin als das beste Gütemass<br />
für die Überprüfung einer Korrelationsmatrix für eine Faktorenanalyse angesehen 389 .<br />
Im vorliegenden Fall ist der Anteil der nicht-diagonalen Elemente der Anti-Image-<br />
Kovarianzmatrix (> 0.09) bei 5.11%. Das KMO-Kriterium weist einen Wert von 0.816<br />
auf, was als „verdienstvoll“ einzustufen ist 390 . Aufgrund beider Gütekriterien ist der<br />
Datensatz als für eine Faktorenanalyse geeignet einzustufen 391 .<br />
Zwei Gründe führten dazu, dass zur Extraktion der Faktoren die Hauptkomponentenanalyse<br />
gewählt wurde. Einerseits wird das Ziel verfolgt, die Frage nach einem<br />
Sammelbegriff (Komponente) für „auf einen Faktor hoch ladende Variablen“ zu beantworten.<br />
Damit wird eine Reduktion der Vielzahl einzelner Variablen in zusammengehörige<br />
Faktoren erreicht 392 . Andererseits liegen der Hauptkomponentenmethode keine<br />
speziellen Annahmen über die statistische Verteilung der Daten zugrunde 393 .<br />
386 Vgl. Lee, Xia 2010, S. 92.<br />
387 Vgl. Dziuban, Shirkey 1974, S. 358ff.<br />
388 Vgl. Kaiser 1970, S. 401ff.<br />
389 Vgl. Dziuban, Shirkey 1974, S. 361.<br />
390 Vgl. Backhaus et al. 2006, S. 276ff.; Kaiser, Rice 1974.<br />
391 Vgl. Backhaus et al. 2006, S. 276ff.<br />
392 Vgl. Backhaus et al. 2006, S. 293.<br />
393 Vgl. Kirchhoff et al. 2003, S. 83.
Eigenwerte<br />
92 Grundlagen für die Methodenentwicklung<br />
Zur Bestimmung der Anzahl Faktoren wurden zwei etablierte Testverfahren verwendet.<br />
Diese sind das Kaiser-Guttmann-Kriterium, wonach die Anzahl zu extrahierenden<br />
Faktoren der Zahl der Faktoren entspricht deren Eigenwerte grösser als eins sind 394<br />
und der Scree-Test, bzw. das Elbow-Kriterium 395 . Dabei wird davon ausgegangen,<br />
dass nur diejenigen Faktoren extrahiert werden sollen, die einen hohen Eigenwert haben<br />
und entsprechend einen hohen Anteil der Varianz erklären können. Wie in Abbildung<br />
20 dargestellt, fallen die Eigenwerte der korrelierenden Variablen zunächst steil<br />
ab. Ab einer gewissen Stelle zeichnet sich eine Knickstelle (sog. Elbow) ab. Die rechts<br />
dieser Knickstelle liegenden Eigenwerte stagnieren auf niedrigem Niveau. Die links<br />
von der Knickstelle liegenden Eigenwerte können einen bedeutenden Teil der Varianz<br />
erklären und definieren daher die Anzahl zu extrahierende Faktoren.<br />
12<br />
10<br />
8<br />
6<br />
4<br />
2<br />
0<br />
Scree-Test<br />
Eigenwert = 1<br />
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30<br />
Faktoren<br />
Faktor<br />
Erklärter<br />
Eigenwert Varianzanteil<br />
(in %)<br />
1 10.459 34.863<br />
2 3.014 44.911<br />
3 1.883 51.188<br />
4 1.438 55.982<br />
5 1.297 60.303<br />
6 1.185 64.254<br />
7 1.104 67.933<br />
8 1.048 71.424<br />
9 .947 74.580<br />
… … …<br />
30 .071 100.000<br />
Abbildung 20: Scree-Plot für die Faktorenanalyse<br />
Tabelle 6: Eigenwerte<br />
Ziel der Faktorenanalyse ist die Gewinnung aussagekräftiger und interpretierbarer<br />
Faktoren. Aus diesem Grund wird den Resultaten des Scree-Tests gefolgt um vier Faktoren<br />
auszuwählen (vgl. Abbildung 20). Die Extraktion von acht Faktoren, wie es<br />
durch das Kaiser-Guttmann-Kriterium vorgeschlagen wird (vgl. Tabelle 6), würde zu<br />
einer nicht mehr gleich gut interpretierbaren Anzahl Faktoren führen, was die Aussagekraft<br />
der Faktorenanalyse schmälern würde. Durch die vier extrahierten Faktoren<br />
kann ein Varianzanteil von 55.9% erklärt werden.<br />
394 Vgl. Kaiser, Dickman 1959, S. 426.<br />
395 Vgl. Cattell 1966, S. 245ff.
Agilität der Entwicklung<br />
Grundlagen für die Methodenentwicklung 93<br />
Im vorliegenden Fall resultierten aus 30 Variablen vier unterschiedliche Faktoren. Zur<br />
Verbesserung der Interpretierbarkeit wurde die Faktorladungsmatrix mit Hilfe der so<br />
genannten Varimax-Methode mit Kaiser-Normalisierung rotiert 396 . Die Zuweisung der<br />
Variablen zu einem Faktor erfolgte in Abhängigkeit der jeweiligen Faktorladung (≥<br />
0.5) 397 . In zwei Ausnahmefällen wurden Variablen einem Faktor zugeordnet, obwohl<br />
sie eine Faktorladung < 0.5 aufwiesen. Eine Variable wurde aus sachlogischen Überlegungen<br />
einem Faktor zugeordnet, obwohl die Ladung entsprechend tief ist. Tabelle 7<br />
veranschaulicht die Variablen und deren Ladungen auf die extrahierten Faktoren.<br />
ID<br />
Variablenname<br />
Faktor<br />
1<br />
Faktor<br />
2<br />
Faktor<br />
3<br />
Faktor<br />
4<br />
A1<br />
Für jeden Entwicklungszyklus bzw. Release werden in einem Planungstreffen<br />
zwischen Fachbereich und IT die zu bearbeitenden Aufgaben<br />
definiert.<br />
.750 .260 -.033 .209<br />
A2 Ergebnisse werden in regelmässigen, kurzen Abständen geliefert 398 . .693 .170 .189 .395<br />
A3<br />
A4<br />
Das Projekt wird in kurze, gleich lange Entwicklungszyklen (Sprints)<br />
aufgeteilt.<br />
Die Beurteilung des Projektstatus erfolgt im Wesentlichen durch die<br />
Bewertung der Projektergebnisse.<br />
.676 .234 .004 -.068<br />
.668 -.127 .353 -.042<br />
A5 Der Projektfortschritt wird regelmässig präsentiert und bewertet. .648 .075 .017 -.142<br />
A6<br />
Einfachheit ist ein wesentliches Prinzip - sowohl im Rahmen der Softwareentwicklung<br />
(Prozess) als auch im Kontext der zu entwickelnden<br />
Software (Ergebnis).<br />
.631 .178 .309 .239<br />
A7<br />
Während des Projekts werden kontinuierlich lauffähige Ergebnisse<br />
geliefert.<br />
.628 .256 .125 .479<br />
A8<br />
In regelmässigen Projektreviews reflektiert sich das Projektteam kritisch.<br />
.621 .215 .202 .018<br />
A9<br />
Der Projektfortschritt wird täglich, auf der Basis etablierter Konzepte<br />
wie Burn Down Charts, analysiert.<br />
.618 .258 -.048 -.143<br />
A10<br />
Die Entwicklung erfolgt für die Projektmitglieder nachhaltig durch<br />
Vermeidung von Überlast-/Unterlast-Phasen.<br />
.600 .231 -.060 -.045<br />
A11<br />
Im Projekt wird auf der Basis eines priorisierten Anforderungskatalogs<br />
(Backlog) gearbeitet.<br />
.570 .220 .066 .255<br />
A12 Im Projekt wird intensiv und idealerweise face-to-face kommuniziert. .570 -.162 .402 .022<br />
A13<br />
Sich ändernde Anforderungen während des Projekts werden berücksichtigt.<br />
.549 -.261 .203 .215<br />
A14 Fachbereich und IT arbeiten im Projekt auf täglicher Basis zusammen. .535 .236 .256 .342<br />
A15<br />
Starker Fokus wird auf technische Exzellenz und gutes Design in<br />
Projektdurchführung und Produkt gelegt.<br />
.493 .283 .056 .091<br />
A16 Es werden kurze, tägliche Abstimmungsmeetings durchgeführt. .491 .331 .068 .003<br />
396 Vgl. bspw. Backhaus et al. 2006, S. 259ff.; Kaiser, Rice 1974.<br />
397 Vgl. Backhaus et al. 2006, S. 299; Härdle, Simar 2003, S. 259.<br />
398 Während bei A2 der Fokus auf der Regelmässigkeit liegt, stehen bei A7 die lauffähigen Ergebnisse im Vordergrund.
Teamcharakter<br />
Tech. Reifegrad der anal.<br />
Informationslandschaft<br />
Org. Reifegrad der anal.<br />
Informationslandschaft<br />
94 Grundlagen für die Methodenentwicklung<br />
ID<br />
Variablenname<br />
Faktor<br />
1<br />
Faktor<br />
2<br />
Faktor<br />
3<br />
Faktor<br />
4<br />
F1<br />
BI/DWH 399 zeichnet sich aus Sicht des Gesamtunternehmens aus<br />
durch eine systematische Weiterentwicklung z.B. via wohldefinierte BI-<br />
Strategie.<br />
.202 .789 .263 .053<br />
F2<br />
BI/DWH zeichnet sich aus Sicht des Gesamtunternehmens aus durch<br />
ein klar definiertes Leistungsspektrum.<br />
.175 .780 .269 -.047<br />
F3<br />
Charakteristika für die BI/DWH-Organisation in meinem Unternehmen<br />
sind strikte Governance.<br />
.251 .695 .443 -.064<br />
F4<br />
BI/DWH zeichnet sich aus Sicht des Gesamtunternehmens aus durch<br />
hohe Verbreitung im Unternehmen.<br />
.191 .680 -.025 .332<br />
F5<br />
BI/DWH zeichnet sich aus Sicht des Gesamtunternehmens aus durch<br />
hohe Anzahl abgedeckter Fachgebiete.<br />
.128 .669 -.008 .169<br />
F6<br />
Charakteristika für die BI/DWH-Organisation in meinem Unternehmen<br />
sind standardisierte BI/DWH-Entwicklungsprozesse.<br />
.292 .655 .444 -.088<br />
F7<br />
Charakteristika für die BI/DWH-Organisation in meinem Unternehmen<br />
sind hohe fachliche Kompetenz der (internen) BI/DWH.<br />
.196 .587 .388 .190<br />
T1<br />
In meinem Unternehmen zeichnet sich BI/DWH technisch aus durch<br />
hohe Datenqualität.<br />
.031 .184 .786 .071<br />
T2<br />
In meinem Unternehmen zeichnet sich BI/DWH technisch aus durch<br />
homogene Gesamtarchitektur (Quellsysteme, Infrastruktur).<br />
-.026 .132 .754 .046<br />
T3<br />
In meinem Unternehmen zeichnet sich BI/DWH technisch aus durch<br />
standardisierte und homogene <strong>analytische</strong> <strong>Informationssysteme</strong>.<br />
.221 .261 .752 .061<br />
T4<br />
Charakteristika für die BI/DWH-Organisation in meinem Unternehmen<br />
sind hohe technische Kompetenz der (internen) BI/DWH.<br />
.207 .486 .584 .045<br />
C1<br />
Die Entwicklungsteams bestehen aus einer kleinen Anzahl Teammitglieder<br />
(5-10 Personen).<br />
.161 .298 .115 .655<br />
C2<br />
Mein Unternehmen hat im Allgemeinen eine etablierte Kultur für<br />
Teamwork.<br />
.441 .269 .081 .518<br />
C3<br />
Die Entwicklungsteams bestehen aus Mitgliedern unterschiedlicher<br />
fachlicher Herkunft/Kompetenz (interdisziplinäre Teams).<br />
.449 .256 .157 .238<br />
Tabelle 7: Variablen und deren Ladungen auf die extrahierten Faktoren<br />
Aufgrund der individuellen Variablenbezeichnungen in Tabelle 7 lassen sich für das<br />
agile <strong>Projektmanagement</strong> für AIS auf stark verdichtetem Niveau folgende vier Gestaltungsfaktoren<br />
ableiten:<br />
Gestaltungsfaktor 1 – „Agilität der Entwicklung“: Dieser Faktor subsumiert Variablen,<br />
die den Grad der Agilität der Entwicklung betreffen. Dabei wird Bezug auf Fragen<br />
nach typischen Aspekten genommen, die agile Entwicklung charakterisieren, wie<br />
bspw. kurze Entwicklungszyklen, regelmässige Lieferung nutzbarer Ergebnisse, regelmässige<br />
Projektreviews, das Arbeiten mit Burn Down Charts, einem priorisierten<br />
Anforderungskatalog oder das Berücksichtigen sich ändernder Anforderungen während<br />
des Projekts. Ferner wird auf kulturelle Charakteristika agiler Entwicklung eingegangen<br />
wie bspw. die enge Zusammenarbeit zwischen Fachbereich und IT oder die<br />
intensive face-to-face-Kommunikation.<br />
399 Zur einfacheren Verständlichkeit für die Umfrageteilnehmenden wurde im Fragebogen BI/DWH als Synonym<br />
für AIS verwendet.
Grundlagen für die Methodenentwicklung 95<br />
Gestaltungsfaktor 2 – „Organisatorischer Reifegrad der <strong>analytische</strong>n Informationslandschaft“:<br />
Variablen die den organisatorischen bzw. sozio-technischen Reifegrad<br />
der <strong>analytische</strong>n Informationslandschaft in den befragten Unternehmen betreffen, werden<br />
in Faktor 2 zusammengefasst. Hierbei handelt es sich bspw. um die Systematik in<br />
der Weiterentwicklung, Governance-Strukturen, Verbreitung im Unternehmen bzw.<br />
Anzahl der abgedeckten Fachgebiete oder die fachliche Kompetenz der internen AIS-<br />
Landschaft.<br />
Gestaltungsfaktor 3 – „Technischer Reifegrad der <strong>analytische</strong>n Informationslandschaft“:<br />
Fragen zur technischen Reife der <strong>analytische</strong>n Informationslandschaft fasst<br />
Faktor 3 zusammen. Insbesondere Aspekte zu Datenqualität, homogenen Architekturen<br />
der Quellsysteme und der Infrastruktur, Standardisiertheit und Homogenität der<br />
<strong>analytische</strong>n Informationslandschaft oder die technische Kompetenz der internen Mitarbeitenden<br />
im Bereich AIS wurden abgefragt.<br />
Gestaltungsfaktor 4 – „Teamcharakter“: Faktor 4 subsumiert Variablen, die den Charakter<br />
des Entwicklungsteams betreffen. Aus sachlogischen Gesichtspunkten wurde<br />
hier zusätzlich noch die Variable C3 zur interdisziplinären Struktur des Entwicklungsteams<br />
mit aufgenommen.<br />
4.2 Realisierungsformen für agiles AIS-<strong>Projektmanagement</strong><br />
Basierend auf den in Abschnitt 4.1 identifizierten Gestaltungsfaktoren lassen sich im<br />
nachfolgenden Analyseschritt verschiedenartige Realisierungsformen von AIS-<br />
Projekten in der Praxis ermitteln. Zu diesem Zweck wurde ein hierarchischagglomeratives<br />
Verfahren auf Grundlage der zuvor abgeleiteten Gestaltungsfaktoren<br />
verwendet. Solche Verfahren fassen anfänglich jeden einzelnen Gestaltungsfaktor als<br />
eigenes Cluster 400 auf und fusionieren diese dann bis zum Erreichen eines Abbruchkriteriums.<br />
Aufgrund seiner weiten Verbreitung in der Praxis 401 und der Eigenschaft, in<br />
den meisten Fällen sehr gute Partitionen finden zu können 402 , wurde der Ward-<br />
Algorithmus zur Fusionierung der Cluster verwendet. Als Distanzmass kam die quadrierte<br />
Euklidische Distanz zum Einsatz 403 .<br />
Zur Bestimmung der sinnvollen Anzahl Cluster gibt es grundsätzlich zwei Möglichkeiten,<br />
mithilfe einer visualisierten Form des Fusionierungsprozesses mittels eines<br />
400 Cluster und Realisierungsformen werden in vorliegendem Kontext synonym verwendet.<br />
401 Vgl. Hair Jr et al. 2006, S. 486; Han, Kamber 2006, S. 408; Härdle, Simar 2003, S. 308ff.<br />
402 Vgl. Bergs 1981, S. 96f.<br />
403 Vgl. Ward Jr 1963, S. 236.
96 Grundlagen für die Methodenentwicklung<br />
Dendrogramms 404 oder durch statistische Kriterien mittels des sogenannten Elbow-<br />
Kriteriums 405 . Grundsätzlich ist das Ziel, eine handhabbare und interpretierbare Anzahl<br />
von Clustern l-<br />
406 .<br />
Abbildung 21 zeigt das Dendrogramm für die vorliegende Clusteranalyse. Zur Bestimmung<br />
der geeigneten Anzahl Cluster werden die grössten Abstände zwischen den<br />
Teilungen ermittelt. Im vorliegenden Fall ergibt sich daher eine Clusteranzahl von<br />
zwei bis vier. Aufgrund dieser nicht eindeutigen Interpretierbarkeit soll zusätzlich<br />
noch das Verfahren des Elbow-Kriteriums angewandt werden.<br />
2 Cluster<br />
3 Cluster<br />
4 Cluster<br />
5 Cluster<br />
6 Cluster<br />
Cluster<br />
1<br />
Cluster<br />
2<br />
Cluster<br />
3<br />
Cluster<br />
4<br />
Abbildung 21: Dendrogramm der Clusteranalyse<br />
Zu Bestimmung des Elbow-Kriteriums für die Clusteranzahl wird die Heterogenitätsentwicklung<br />
betrachtet. Zu diesem Zweck wird die Anzahl vorgeschlagener Cluster<br />
gegen die Fehlerquadratsumme in einem Koordinatensystem abgetragen (vgl. Abbildung<br />
22). Dabei zeigt sich im Diagramm bei einer Clusteranzahl von vier ein <br />
(Elbow) in der Entwicklung des Heterogenitätsmasses, d.h. die Fehlerquadratsumme<br />
steigt zwischen Clusteranzahl vier und fünf überproportional. Dies verdeutlicht auch<br />
die absolute Entwicklung der Fehlerquadratsumme wie in Tabelle 8 ersichtlich. Diese<br />
404 Vgl. Backhaus et al. 2006, S. 534; Gordon 1996, S. 65ff.<br />
405 Vgl. Backhaus et al. 2006, S. 534.<br />
406 Vgl. Backhaus et al. 2006, S. 534.
Cluster 4<br />
Cluster 3<br />
Cluster 2<br />
Cluster 1<br />
Fehlerquadratsumme<br />
Grundlagen für die Methodenentwicklung 97<br />
Lösung ergibt eine handhabbare und hinreichend detaillierte Anzahl Cluster, so dass<br />
im Folgenden mit einer Clusteranzahl von vier weiterverfahren wird.<br />
225<br />
200<br />
175<br />
150<br />
125<br />
100<br />
75<br />
50<br />
25<br />
0<br />
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 63<br />
Anzahl der Cluster<br />
Anzahl<br />
Cluster<br />
1<br />
2<br />
3<br />
4<br />
5<br />
6<br />
7<br />
8<br />
9<br />
…<br />
62<br />
63<br />
Entwicklung<br />
der Fehlerquadratsumme<br />
37.591<br />
29.835<br />
25.725<br />
24.324<br />
14.684<br />
12.780<br />
11.311<br />
10.356<br />
…<br />
37.591<br />
Abbildung 22: Elbow-Kriterium zu Bestimmung der Clusterzahl<br />
Tabelle 8: Entwicklung<br />
der Fehlerquadratsummen<br />
Anzahl<br />
Instanzen<br />
im Datensatz<br />
Mittelwert<br />
Faktorwert<br />
Standardfehler<br />
95%-Konfidenzintervall<br />
Untere<br />
Grenze<br />
Obere Grenze<br />
Agilität der Entwicklung<br />
0.50 0.69 0.16 0.84<br />
Org. Reife der AIS 0.17 0.49 -0.07 0.41<br />
16<br />
Tech. Reife der AIS 0.93 0.69 0.60 1.27<br />
Teamcharakter 0.43 0.59 0.14 0.72<br />
Agilität der Entwicklung<br />
0.58 0.47 0.05 1.12<br />
Org. Reife der AIS -1.92 0.21 -2.17 -1.68<br />
3<br />
Tech. Reife der AIS -0.19 1.50 -1.88 1.50<br />
Teamcharakter -2.26 0.65 -2.99 -1.52<br />
Agilität der Entwicklung<br />
0.13 1.19 -0.42 0.68<br />
Org. Reife der AIS -0.75 0.74 -1.09 -0.41<br />
18<br />
Tech. Reife der AIS -0.51 0.90 -0.93 -0.10<br />
Teamcharakter 0.63 0.72 0.29 0.96<br />
Agilität der Entwicklung<br />
-0.46 0.81 -0.78 -0.15<br />
Org. Reife der AIS -0.20 0.79 -0.50 0.11<br />
26<br />
Tech. Reife der AIS -0.20 0.71 -0.47 0.08<br />
Teamcharakter -0.44 0.77 -0.74 -0.15<br />
Tabelle 9: Faktorwerte der jeweiligen Cluster
98 Grundlagen für die Methodenentwicklung<br />
Jedes der identifizierten Cluster repräsentiert eine spezifische Realisierungsform agilen<br />
<strong>Projektmanagement</strong>s für AIS. Dabei handelt es sich um wiederkehrende Muster, die in<br />
der Praxis der befragten Unternehmen zu beobachten sind.<br />
Tabelle 9 zeigt die sich aus der Analyse ergebenden Cluster, deren Mittelwerte der<br />
einzelnen Gestaltungsfaktoren, sowie das jeweilige 95%-Konfidenzintervall, also der<br />
Wertebereich, in dem sich die einzelnen Variablen mit einer 95%-Wahrscheinlichkeit<br />
befinden.<br />
2.0<br />
Grad der Agilität<br />
der Entwicklung<br />
1.0 Cluster 3<br />
Cluster<br />
1<br />
Teamcharakter<br />
0.0<br />
-3.0 -2.0 -1.0 0.0 1.0 2.0 3.0<br />
Cluster 4<br />
-1.0<br />
-2.0<br />
Cluster 2<br />
-3.0<br />
-4.0<br />
Abbildung 23: Ergebnisse der Clusteranalyse (Gestaltungsfaktoren 1 und 4)<br />
Mittels der Mittelwerte und der oberen und unteren Grenze der dazugehörigen 95%-<br />
Konfidenzintervalle, lassen sich die einzelnen Cluster visualisieren. Dabei werden die<br />
Gestaltungsfaktoren 1 („Grad der Agilität der Entwicklung“) und 4 („Teamcharakter“),<br />
sowie die Gestaltungsfaktoren 2 („Organisatorischer Reifegrad der <strong>analytische</strong>n Informationslandschaft“)<br />
und 3 („Technischer Reifegrad der <strong>analytische</strong>n Informationslandschaft“)<br />
aus sachlogischen Gründen jeweils in Koordinatensystemen grafisch dargestellt.<br />
Aufgrund des semantischen Bezugs der Gestaltungsfaktoren 2 und 3 und aufgrund<br />
der Tatsache, dass diese durch die Agilität des <strong>Projektmanagement</strong>s für AIS<br />
nicht primär verändert werden, wird auf die Gestaltungsfaktoren 1 und 4 fokussiert.
Grundlagen für die Methodenentwicklung 99<br />
Dabei fällt auf, dass es bei Cluster 1 und Cluster 3 relativ grosse Überschneidungen<br />
gibt. Trotzdem können die vier Cluster jeweils einem Quadranten des Koordinatensystems<br />
zugeordnet werden (vgl. Abbildung 23).<br />
Technischer Reifegrad der<br />
<strong>analytische</strong>n Informationslandschaft<br />
2.0<br />
1.0<br />
Cluster<br />
1<br />
Organisatorischer Reifegrad<br />
der <strong>analytische</strong>n<br />
Informationslandschaft<br />
Cluster 0.0<br />
-3.0 -2.0 -1.0 0.0 1.0 2.0 3.0<br />
4<br />
Cluster 3<br />
-1.0<br />
Cluster 2<br />
-2.0<br />
-3.0<br />
-4.0<br />
Abbildung 24: Ergebnisse der Clusteranalyse (Gestaltungsfaktoren 2 und 3)<br />
Bezüglich der Gestaltungsfaktoren 2 und 3 ist zwischen Cluster 2 und 3 eine fast vollständige<br />
Überschneidung zu beobachten. Die Cluster 2, 3 und 4 bewegen sich im<br />
Quadranten „tiefer technischer Reifegrad der <strong>analytische</strong>n Informationslandschaft bei<br />
tiefem organisatorischen Reifegrad der <strong>analytische</strong>n Informationslandschaft“, wobei<br />
Cluster 4 tendenziell den höchsten technischen Reifegrad der <strong>analytische</strong>n Informationslandschaft<br />
aufweist (vgl. Abbildung 24). Cluster 1 zeichnet sich durch einen hohen<br />
organisatorischen und relativ hohen technischen Reifegrad der <strong>analytische</strong>n Informationslandschaft<br />
aus.<br />
Aufgrund der visualisierten Betrachtung der Ergebnisse der Clusteranalyse lassen sich<br />
die vier identifizierten Cluster wie folgt beschreiben:<br />
Cluster 1 – „Grösstenteils agile Entwicklung bei fördernden Teamcharakteristika“:<br />
Unternehmen, die diesem Cluster zugeordnet werden, verwenden bereits grösstenteils
100 Grundlagen für die Methodenentwicklung<br />
agile Prinzipien und Techniken in ihren Projekten im AIS-Umfeld und zeichnen sich<br />
durch gute Voraussetzungen bezüglich der Charakteristika der Entwicklungsteams aus.<br />
Cluster 2 – „Keine agile Entwicklung mit guten teamspezifischen Voraussetzungen“:<br />
Dieses Cluster subsumiert Unternehmen, die heute noch keine agile Entwicklung im<br />
AIS-Umfeld betreiben, jedoch aufgrund ihrer Teamstrukturen und -charakteristika gute<br />
Voraussetzungen haben, um agile Entwicklung einzuführen.<br />
Cluster 3 – „Etablierte agile Entwicklung bei förderndem Teamcharakter“: In diesem<br />
Cluster befinden sich Unternehmen, bei denen sich agile Entwicklung im AIS-Umfeld<br />
bereits etabliert hat. Die guten teamspezifischen Voraussetzungen unterstützen den<br />
erfolgreichen Einsatz agiler Methoden im Unternehmen.<br />
Cluster 4 – „Keine agile Entwicklung mit schlechten teamspezifischen Voraussetzungen“:<br />
Unternehmen, die diesem Cluster angehören, haben keine agile Entwicklung im<br />
AIS-Umfeld. Die Teamspezifika sind nicht fördernd für agile Entwicklung.<br />
4.3 Ableitung von Projekttypen und Kontexttypen<br />
Auf Basis der in den vorangegangenen Abschnitten quantitativ-empirisch identifizierten<br />
Gestaltungsfaktoren und Realisierungsformen, werden in den nachfolgenden Abschnitten<br />
relevante Projekt- und Kontexttypen für die situative Methodenkonstruktion<br />
in Kapitel 6 abgeleitet.<br />
4.3.1 Projekttypen<br />
Aus den Ergebnissen der explorativen Untersuchungen in den vorangegangenen Kapiteln<br />
und insbesondere aus der Clusteranalyse lassen sich potentielle Projekttypen (PT)<br />
für die Konstruktion der situativen Methode ableiten. Es handelt sich hierbei um die<br />
Übergänge zwischen den in Abschnitt 4.2 bzw. Abbildung 23 identifizierten Realisierungsformen.<br />
Es werden dabei jedoch lediglich Massnahmen betrachtet werden, die<br />
eine Verbesserung der initialen Realisierungsform betreffen. Die Cluster 1 und 3 überschneiden<br />
sich fast vollständig bezüglich der betrachteten Faktoren „Agilität der Entwicklung“<br />
und „Teamspezifische Voraussetzungen“ (vgl. Abbildung 23). Deshalb<br />
wird zwischen diesen beiden Clustern keine signifikante Verbesserung der Realisierungsform<br />
erwartet, so dass die beiden Cluster zusammengefasst werden. Es ergeben<br />
sich daraus, wie in Abbildung 25 ersichtlich, drei relevante Realisierungsformen. Daraus<br />
leiten sich zwei direkte und eine kombinierte Transformationsmöglichkeit ab<br />
(PT1, PT2 und PT3, wobei sich dieser aus einer Kombination aus PT1 und PT2 definiert).<br />
Die so identifizierten Projekttypen werden im Folgenden beschrieben.
Teamspezifische Voraussetzungen<br />
PT1<br />
Grundlagen für die Methodenentwicklung 101<br />
gut<br />
Mittlere Reife der<br />
Agilität in der<br />
Entwicklung<br />
Keine agile Entwicklung mit<br />
guten teamspezifischen<br />
Voraussetzungen<br />
(Cluster 2)<br />
PT2<br />
Hohe Reife der Agilität<br />
in der Entwicklung<br />
Etablierte agile Entwicklung bei<br />
guten teamspezifischen<br />
Voraussetzungen<br />
(Cluster 1 und 3)<br />
schlecht<br />
Tiefe Reife der Agilität<br />
in der Entwicklung<br />
Keine agile Entwicklung mit<br />
schlechten teamspezifischen<br />
Voraussetzungen<br />
(Cluster 4)<br />
isolierter PT<br />
kombinierter PT<br />
tief<br />
Agilität der Entwicklung<br />
hoch<br />
Abbildung 25: Abgeleitete Projekttypen<br />
Projekttyp 1 – „Schaffung teamspezifischer Voraussetzungen für agile Entwicklung für<br />
AIS“: Dieser Projekttyp dient dazu, die teamspezifischen Voraussetzungen im Unternehmen<br />
zu schaffen, damit eine agile Entwicklung für AIS etabliert werden kann. Dabei<br />
werden insbesondere Rahmenbedingungen wie bspw. die Etablierung einer Kultur<br />
für Teamarbeit im Unternehmen geschaffen, die Teamgrösse entsprechend klein oder<br />
die Zusammensetzung der Entwicklungsteams interdisziplinär gestaltet. Im Ausgangspunkt<br />
für diesen Übergang ist weder eine agile Entwicklung formalisiert vorhanden,<br />
noch die Charakteristika der Entwicklungsteams fördernd für agile Entwicklung für<br />
AIS.<br />
Projekttyp 2 – „Etablierung einer agilen Entwicklung für AIS“: Basierend auf guten<br />
Voraussetzungen bezüglich der Charakteristika der Entwicklungsteams ist das Ziel<br />
von Projekttyp 2 die Etablierung einer agilen Entwicklung für AIS. Aufgrund der Tatsache,<br />
dass agile Entwicklung auf verschiedenen Praktiken, Techniken und Prinzipien<br />
basiert (vgl. Abschnitt 2.4), kann dieser Projekttyp mit unterschiedlichen Schwerpunkten<br />
durchgeführt werden. Die in Tabelle 8 dargestellten Variablen A1 bis A16 wiederspiegeln<br />
diese unterschiedlichen Aspekte der agilen Entwicklung und können flexibel<br />
zur Verbesserung eingesetzt werden.<br />
Wie in Abbildung 25 dargestellt, ist auch eine Verbesserung von „Tiefer Reifegrad der<br />
Agilität der Entwicklung“ zu „Hoher Reifegrad der Agilität der Entwicklung“ denkbar<br />
(Projekttyp 3). Es handelt sich hierbei um eine Kombination aus den isolierten Projekttypen<br />
1 und 2. Eine direkte Etablierung einer agilen Entwicklung für AIS von Grund
Operative Systeme<br />
Datenerfassungsebene<br />
(ETL-Schicht)<br />
Datenhaltung (DWH)<br />
Datenbereitstellung<br />
(Data Marts)<br />
Datenpräsentation<br />
Operative Systeme<br />
Datenerfassungsebene<br />
(ETL-Schicht)<br />
Datenhaltung (DWH)<br />
Datenbereitstellung<br />
(Data Marts)<br />
Datenpräsentation<br />
102 Grundlagen für die Methodenentwicklung<br />
auf ist allerdings mit erhöhten Aufwänden sowie einer erhöhten Komplexität verbunden<br />
und deshalb eher schwierig umzusetzen.<br />
Neben dem Ziel, in der situativen Methode die beiden quantitativ-empirisch, induktiv<br />
identifizierten Entwicklungsszenarien abzubilden, soll die Methode ausserdem so konstruiert<br />
werden, dass unterschiedliche grundlegende Projektfokusse mit einbezogen<br />
werden können. Sowohl in der Praxis 407 , als auch in der Literatur 408 , werden zwei Arten<br />
von Projekten unterschieden, Frontend- und Backend-Entwicklung. Während sich<br />
Projekte im Bereich Frontend vorwiegend damit beschäftigen, auf einer bestehenden<br />
Datenbasis wie bspw. einem DWH <strong>analytische</strong> Applikationen zu bauen oder Berichte<br />
zu erstellen, fokussieren Projekte im Backend-Bereich darauf, Daten zu integrieren<br />
und zu strukturieren oder neue Datenquellen anzubinden.<br />
Diese unterschiedlichen Projekttypen müssen in der situativen Methode für das agile<br />
<strong>Projektmanagement</strong> von AIS-Projekten zusätzlich berücksichtigt werden. Konkret<br />
wird deshalb deduktiv zusätzlich noch der Projekttyp „Frontend Entwicklungsprojekt“<br />
(Projekttyp A), sowie „Backend Entwicklungsprojekt“ (Projekttyp B) mit aufgenommen.<br />
In der Praxis verbreitet ist die Kombination beider Projekttypen, bspw. hat der<br />
Aufbau eines neuen DHW auch grosse Auswirkungen auf den Frontend-Bereich.<br />
Projektfokus<br />
Frontend<br />
Projektfokus Backend<br />
Abbildung 26: Projektfokus der Projekttypen A und B 409<br />
407 Sämtliche der untersuchten Fallstudien differenzieren zwischen Frontend- und Backend-Entwicklung (vgl.<br />
Kapitel 5).<br />
408 Vgl. bspw. Hughes 2008; Jung, Winter 2000; Kimball et al. 2008; Moss, Atre 2003, sowie sämtliche Fallstudien<br />
in Kapitel 5.<br />
409 Bezüglich der zugrundeliegenden AIS-Architektur vgl. Abschnitt 2.2.
Grundlagen für die Methodenentwicklung 103<br />
Abbildung 26 zeigt, wo der Fokus der beiden Projekttypen A und B liegt. Aus der<br />
Kombination der beiden isolierten Projekttypen A und B ergeben sich Projekte, die<br />
beide Bereiche abdecken.<br />
4.3.2 Kontexttypen<br />
Die in Abschnitt 4.1 identifizierten Gestaltungsfaktoren 2 („Organisatorischer Reifegrad<br />
der <strong>analytische</strong>n Informationslandschaft“) und 3 („Technischer Reifegrad der<br />
<strong>analytische</strong>n Informationslandschaft“) stellen einflussnehmende Faktoren dar, die sich<br />
auf die Methodenkonstruktion und deren Anwendung auswirken. Durch die Methodenanwendung<br />
bzw. durch die Projektdurchführung werden diese allerdings nicht primär<br />
beeinflusst. So gesehen entsprechen sie den in Abschnitt 2.1.3 charakterisierten<br />
Kontexttypen 410 . Zur Sicherstellung der Handhabbarkeit der situationsdeterminierenden<br />
Faktoren, wird pro Gestaltungsfaktor jeweils von einer geringen und einer hohen<br />
Ausprägung ausgegangen.<br />
Für Gestaltungsfaktor 2 wird demnach von einem „tiefen organisatorischen Reifegrad<br />
der <strong>analytische</strong>n Informationslandschaft“ und einem „hohen organisatorischen Reifegrad<br />
der <strong>analytische</strong>n Informationslandschaft“ ausgegangen. Variablen, aus welchen<br />
sich eine hohe Ausprägung dieses Gestaltungsfaktors ergibt, sind die systematische<br />
Weiterentwicklung von AIS, ein klar definiertes Leistungsspektrum, eine strikte<br />
Governance, eine hohe Verbreitung von AIS im Unternehmen, eine hohe Anzahl abgedeckter<br />
Fachgebiete durch AIS, standardisierte Entwicklungsprozesse für AIS oder<br />
eine hohe fachliche Kompetenz der AIS-Mitarbeitenden (vgl. Tabelle 7). Eine tiefe<br />
Ausprägung des Gestaltungsfaktors ergibt sich durch die entsprechende Inverse. Für<br />
Gestaltungsfaktor 3 wird „tiefer technischer Reifegrad der <strong>analytische</strong>n Informationslandschaft“<br />
und „hoher technischer Reifegrad der <strong>analytische</strong>n Informationslandschaft“<br />
verwendet. Variablen aus denen sich eine hohe Ausprägung dieses Gestaltungsfaktors<br />
ergibt, sind hohe Datenqualität der AIS, eine homogene Gesamtarchitektur<br />
der AIS, technisch homogene und standardisierte AIS und eine hohe technische<br />
Kompetenz der AIS-Mitarbeitenden (vgl. Tabelle 7). Eine tiefe Ausprägung des Gestaltungsfaktors<br />
ergibt sich auch hier durch die entsprechende Inverse.<br />
Zur genaueren Differenzierung der Situationen in der Methodenanwendung nennt<br />
STROH 411 neben diesen induktiv ermittelten Kontexttypen als weitere Dimension den<br />
Projektumfang. Dieser wird gestützt auf allgemeinen Theorien des Projektmanage-<br />
410 Vgl. Bucher et al. 2007, S. 37ff.<br />
411 Vgl. Stroh 2010, S. 53.
104 Grundlagen für die Methodenentwicklung<br />
ments zur Typisierung von Projekten deduktiv abgeleitet. Der PMBoK Guide schlägt<br />
dabei den Projektumfang vor, wobei dieser neben der Projektgrösse auch dessen Komplexität<br />
beinhaltet 412 . Die typisierende Eigenschaft von Projekten nach deren Umfang<br />
wird durch eine Vielzahl von Untersuchungen bezüglich dessen Einflusses auf das generelle<br />
Vorgehen und Management untermauert 413 .<br />
Analog der oben induktiv ermittelten Kontextfaktoren werden auch für den Projektumfang<br />
jeweils zwei Ausprägungen definiert. Im vorliegenden Fall kann aufgrund der<br />
Reichweite eines Projekts zwischen einer lokalen und einer globalen Ausprägung unterschieden<br />
werden. Ein lokales AIS-Projekt zeichnet sich dabei durch eine geringe<br />
Reichweite und damit durch eine kleinere Anzahl Abhängigkeitsfaktoren aus. Die Erstellung<br />
eines neuen Berichts kann bspw. basierend auf einer stabilen und bestehenden<br />
Datenbasis als lokal bezeichnet werden, während der initiale Aufbau eines DWH mit<br />
seinen vielfältigen Abhängigkeiten von Quellsystemen und dem bereichs- oder gar<br />
unternehmensübergreifenden Charakter als global bezeichnet wird. Entsprechend ist<br />
auch der Projektumfang in ersterem Fall gering und in zweitem gross. Als Kontextfak-<br />
t-<br />
.<br />
Eine Kombination der induktiv aus den Gestaltungsfaktoren 2 und 3 der Faktoranalyse<br />
und deduktiv aus der Theorie hergeleiteten Kontextfaktoren ergibt, wie in Tabelle 10<br />
dargestellt, 8 theoretisch mögliche Kombinationen von Kontextfaktoren.<br />
Kontexttyp<br />
1<br />
Kontexttyp<br />
2<br />
Kontexttyp<br />
3<br />
Kontexttyp<br />
4<br />
Kontexttyp<br />
5<br />
Kontexttyp<br />
6<br />
Kontexttyp<br />
7<br />
Kontexttyp<br />
8<br />
Geringer Projektumfang (lokal)<br />
Hoher Projektumfang (global)<br />
Gestaltungsfaktor 2<br />
Tiefer fachlicher<br />
Reifegrad der<br />
AIS-Landschaft<br />
Hoher fachlicher<br />
Reifegrad der<br />
AIS-Landschaft<br />
Tiefer fachlicher<br />
Reifegrad der<br />
AIS-Landschaft<br />
Hoher fachlicher<br />
Reifegrad der<br />
AIS-Landschaft<br />
Gestaltungsfaktor 3<br />
Tiefer techn.<br />
Reifegrad<br />
der AIS-<br />
Landschaft<br />
Hoher techn.<br />
Reifegrad<br />
der AIS-<br />
Landschaft<br />
Tiefer techn.<br />
Reifegrad<br />
der AIS-<br />
Landschaft<br />
Hoher techn.<br />
Reifegrad<br />
der AIS-<br />
Landschaft<br />
Tiefer techn.<br />
Reifegrad<br />
der AIS-<br />
Landschaft<br />
Hoher techn.<br />
Reifegrad<br />
der AIS-<br />
Landschaft<br />
Tiefer techn.<br />
Reifegrad<br />
der AIS-<br />
Landschaft<br />
Hoher techn.<br />
Reifegrad<br />
der AIS-<br />
Landschaft<br />
Tabelle 10: Induktiv und deduktiv ermittelte Kontexttypen<br />
412 Vgl. Project Management Institute 2008, S. 87.<br />
413 Vgl. bspw. Dvir et al. 1998, S. 921f.; Loch et al. 2006, S. 153; Shenhar 2001, S. 399ff.; Shenhar, Dvir 1996,<br />
S. 611f.; Turner, Cochrane 1993, S. 95.
Grundlagen für die Methodenentwicklung 105<br />
4.4 Entwicklungssituationen für einen methodischen Ansatz<br />
Für die situative Ausgestaltung des methodischen Ansatzes in Kapitel 6 sind die Entwicklungssituationen<br />
im Sinne von BUCHER ET AL. 414 zu identifizieren. Diese bestehen<br />
aus Einflussgrössen, die auf die Anwendung einer Methode einwirken, jedoch durch<br />
diese nicht verändert werden (Kontexttypen), und Faktoren, die durch die Methodenanwendung<br />
beeinflusst werden und den Start- sowie den angestrebten Zielzustand eines<br />
Projekts festlegen bzw. das Projekt an sich charakterisieren (Projekttypen).<br />
Die Menge der Situationen definiert sich durch die Kombination von Kontexttypen<br />
und Projekttypen. Die Reihenfolge der Elemente innerhalb der Menge der Kontexttypen<br />
und Projekttypen ist irrelevant. Somit kann eine Situation als ein kartesisches Produkt<br />
aus den beiden Faktoren angesehen werden. Tabelle 11 zeigt die theoretisch möglichen<br />
Kombinationen der acht Kontexttypen und der vier Projekttypen in Form einer<br />
Situationsmatrix.<br />
Kontexttyp<br />
1<br />
Kontexttyp<br />
2<br />
Kontexttyp<br />
3<br />
Kontexttyp<br />
4<br />
Kontexttyp<br />
5<br />
Kontexttyp<br />
6<br />
Kontexttyp<br />
7<br />
Kontexttyp<br />
8<br />
Geringer Projektumfang (lokal) Hoher Projektumfang (global)<br />
Tiefer org. Reifegrad der Hoher org. Reifegrad der Tiefer org. Reifegrad der Hoher org. Reifegrad der<br />
anal. Informationslandschaflandschaflandschaflandschaft<br />
anal. Informations-<br />
anal. Informations-<br />
anal. Informations-<br />
Tiefer techn. Hoher techn. Tiefer techn. Hoher techn. Tiefer techn. Hoher techn. Tiefer techn. Hoher techn.<br />
Reifegrad Reifegrad Reifegrad Reifegrad Reifegrad Reifegrad Reifegrad Reifegrad<br />
der anal. der anal. der anal. der anal. der anal. der anal. der anal. der anal.<br />
Inform.- Inform.- Inform.- Inform.- Inform.- Inform.- Inform.- Inform.-<br />
landschaft landschaft landschaft landschaft landschaft landschaft landschaft landschaft<br />
Schaffung<br />
Projekttyp<br />
Situation Situation Situation Situation Situation Situation Situation Situation<br />
teamspezifischer<br />
1<br />
Voraussetzungen<br />
1<br />
2<br />
3<br />
4<br />
5<br />
6<br />
7<br />
8<br />
Etablierung einer<br />
Projekttyp<br />
Situation Situation Situation Situation Situation Situation Situation Situation<br />
agilen Entwicklung<br />
2<br />
für AIS<br />
9 10 11 12 13 14 15 16<br />
Projekttyp Frontend- Situation Situation Situation Situation Situation Situation Situation Situation<br />
A Entwicklungsprojekt 17 18 19 20 21 22 23 24<br />
Projekttyp Backend- Situation Situation Situation Situation Situation Situation Situation Situation<br />
B Entwicklungsprojekt 25 26 27 28 29 30 31 32<br />
Tabelle 11: Situationsmatrix mit Kontext- und Projekttypen<br />
Aufgrund der in Abschnitt 4.3.1 abgeleiteten Projekttypen A und B, sowie deren<br />
Kombination kann sich ein Unternehmen in mehreren Situationen befinden. Wird<br />
bspw. ein komplettes neues DWH in einem Unternehmen mit hoher organisatorischer<br />
414 Vgl. Bucher et al. 2007, S. 37.
106 Grundlagen für die Methodenentwicklung<br />
und hoher technischer Reife aufgebaut und ist das Unternehmen noch im Aufbau der<br />
agilen Entwicklung, so kann es den Situationen 16, 24 und 32 zugeordnet werden. Es<br />
wird dabei also agile Entwicklung etabliert und gleichzeitig im Bereich Frontend und<br />
Backend entwickelt.<br />
Die gestaltungsorientierte WI fordert die Praktikabilität von Artefakten. Aus diesem<br />
Grund soll die oben konstruierte theoretische Situationsmatrix vereinfacht werden. Im<br />
vorliegenden Fall wird diese hinsichtlich zweier Aspekte modifiziert.<br />
Einerseits lässt die Analyse der Verteilung der betrachteten Fälle bezüglich organisatorischem<br />
und technischem Reifegrad der <strong>analytische</strong>n Informationslandschaft (vgl. Abbildung<br />
24) darauf schliessen, dass es keine typischen Fälle gibt, die bei einem eher<br />
hohen organisatorischen Reifegrad einen tiefen technischen Reifegrad aufweisen. Dies<br />
ist so zu interpretieren, dass eine hohe organisatorische Reife auch eine eher hohe<br />
technische Reife der <strong>analytische</strong>n Informationslandschaft nach sich zieht. Aus diesem<br />
Grund werden die in der Praxis nicht beobachtbaren Situationen 3, 7, 11, 15, 19, 23,<br />
27 und 31 für die vorliegende Arbeit nicht betrachtet (in Tabelle 12 durchgestrichen).<br />
Kontexttyp<br />
1<br />
Kontexttyp<br />
2<br />
Kontexttyp<br />
3<br />
Kontexttyp<br />
4<br />
Kontexttyp<br />
5<br />
Kontexttyp<br />
6<br />
Kontexttyp<br />
7<br />
Kontexttyp<br />
8<br />
Geringer Projektumfang (lokal)<br />
Hoher Projektumfang (global)<br />
Tiefer org. Reifegrad der<br />
anal. Informationslandschaft<br />
Hoher org. Reifegrad der<br />
anal. Informationslandschaft<br />
Tiefer org. Reifegrad der<br />
anal. Informationslandschaft<br />
Hoher org. Reifegrad der<br />
anal. Informationslandschaft<br />
Tiefer techn.<br />
Reifegrad<br />
der anal.<br />
Inform.-<br />
landschaft<br />
Hoher techn.<br />
Reifegrad<br />
der anal.<br />
Inform.-<br />
landschaft<br />
Tiefer techn.<br />
Reifegrad<br />
der anal.<br />
Inform.-<br />
landschaft<br />
Hoher techn.<br />
Reifegrad<br />
der anal.<br />
Inform.-<br />
landschaft<br />
Tiefer techn.<br />
Reifegrad<br />
der anal.<br />
Inform.-<br />
landschaft<br />
Hoher techn.<br />
Reifegrad<br />
der anal.<br />
Inform.-<br />
landschaft<br />
Tiefer techn.<br />
Reifegrad<br />
der anal.<br />
Inform.-<br />
landschaft<br />
Hoher techn.<br />
Reifegrad<br />
der anal.<br />
Inform.-<br />
landschaft<br />
Projekttyp<br />
1<br />
Schaffung<br />
teamspezifischer<br />
Voraussetzungen<br />
Situation<br />
1<br />
Situation<br />
2<br />
Situation<br />
3<br />
Situation<br />
4<br />
Situation<br />
5<br />
Situation<br />
6<br />
Situation<br />
7<br />
Situation<br />
8<br />
Projekttyp<br />
2<br />
Etablierung einer<br />
agilen Entwicklung<br />
für AIS<br />
Situation<br />
9<br />
Situation<br />
10<br />
Situation<br />
11<br />
Situation<br />
12<br />
Situation<br />
13<br />
Situation<br />
14<br />
Situation<br />
15<br />
Situation<br />
16<br />
Projekttyp<br />
A<br />
Frontend-<br />
Entwicklungsprojekt<br />
Situation<br />
17<br />
Situation<br />
18<br />
Situation<br />
19<br />
Situation<br />
20<br />
Situation<br />
21<br />
Situation<br />
22<br />
Situation<br />
23<br />
Situation<br />
24<br />
Projekttyp<br />
B<br />
Backend-<br />
Entwicklungsprojekt<br />
Situation<br />
25<br />
Situation<br />
26<br />
Situation<br />
27<br />
Situation<br />
28<br />
Situation<br />
29<br />
Situation<br />
30<br />
Situation<br />
31<br />
Situation<br />
32<br />
Tabelle 12: Konsolidierte Situationsmatrix mit Kontext- und Projekttypen<br />
Andererseits zeigt sich sowohl in der Literatur, als auch in den betrachteten Fällen,<br />
dass bei Projekten grösseren Umfangs, d.h. bei globalen Projekten, nie ausschliesslich<br />
Frontend- oder Backend-Entwicklung durchgeführt wird. Vielmehr sind diese Projekte
Grundlagen für die Methodenentwicklung 107<br />
eine Kombination aus beiden. Aus diesem Grund werden für die vorliegende Arbeit<br />
die Situationen 21 und 29, 22 und 30, sowie 24 und 32 zusammengefasst (in Tabelle<br />
12 dunkel schattiert).<br />
Somit ergibt sich aus der Vereinfachung und Konsolidierung eine Situationsmatrix mit<br />
21 relevanten Situationen (vgl. Tabelle 12). Im weiteren Verlauf der Arbeit und dabei<br />
insbesondere in der Konstruktion des methodischen Ansatzes in Kapitel 6, wird auf die<br />
Inhalte dieser konsolidierten Situationsmatrix zurückgegriffen. Gleichzeitig dient die<br />
Matrix auch dazu, die Fallstudien in Kapitel 5 zu positionieren.
108 Fallstudien zur Methodenentwicklung<br />
5 Fallstudien zur Methodenentwicklung<br />
Als Grundlage für die induktive Herleitung der situativen Methode dienen qualitativempirisch<br />
erhobene Fallstudien erfolgreich durchgeführter agiler Projekte im Umfeld<br />
von AIS. In der Forschung werden Fallstudien für die Detailanalyse eines abgegrenzten<br />
Phänomens in seinem natürlichen Kontext verwendet 415 . Dabei können unterschiedliche<br />
Ziele verfolgt werden. Diese reichen von einer reinen Beschreibung eines<br />
Phänomens, über die Bildung von Hypothesen, bis hin zur Entwicklung und dem Testen<br />
von Theorien 416 . In der vorliegenden Arbeit werden die Projektvorgehen in den<br />
Fallstudien beschrieben und zur Bildung von Hypothesen (Methodenfragmenten) verwendet.<br />
Sie dienen ergänzend zu den in Kapitel 3 untersuchten Ansätzen aus der Literatur<br />
dazu, eine situative Methode konstruieren zu können.<br />
Folgender Abschnitt stellt vier Projekte aus der Praxis vor. Die Dokumentation der<br />
Fallstudien orientiert sich an der Methode „PROMET Business Engineering Case Studies“<br />
(BECS) 417 , die im Rahmen des BE 418 entwickelt wurde. Um die Vergleichbarkeit<br />
der Fallstudien sicherstellen zu können, wird in der Dokumentation den Vorgaben von<br />
BECS gefolgt. Entsprechend wird für jedes Praxisbeispiel, neben Angaben zum Unternehmen,<br />
die Ausgangssituation und Problemstellung erläutert. Anschliessend wird<br />
die neue Lösung und Details zum betrachteten Projekt bzw. der betrachteten Veränderung<br />
skizziert. Daneben werden für jede betrachtete Fallstudie die wesentlichen Erkenntnisse<br />
und Herausforderungen dargelegt. Die betrachteten Praxisprojekte bilden<br />
zusammen mit den Erkenntnissen aus den bestehenden Ansätzen die Grundlage für die<br />
Ableitung eines situativen methodischen Ansatzes in Kapitel 6.<br />
Abschnitt 5.1 erläutert die Auswahl der Fallstudien im Kontext des Forschungsvorhabens,<br />
in den Abschnitten 5.2 bis 5.5 werden die genannten Fallstudien beschrieben und<br />
Abschnitt 5.6 dient einer zusammenfassenden Betrachtung der untersuchten Fallstudien,<br />
sowie der Einordnung in den Gesamtkontext der Arbeit. Der für die Fallstudien<br />
eingesetzte Interviewleitfaden findet sich in Anhang B, die Ansprechpartnerinnen und<br />
Ansprechpartner, sofern diese genannt werden wollen, sind in Anhang D verzeichnet.<br />
415 Vgl. bspw. Cavaye 1996, S. 229; Stake 1995, S. VI; Yin 2009, S. 1.<br />
416 Vgl. Benbasat et al. 1987, S. 370; Darke et al. 1998, S. 275; Eisenhardt 1989, S. 548.<br />
417 Vgl. Senger, Österle 2004, S. 15ff.<br />
418 Vgl. Abschnitt 2.1.
Fallstudien zur Methodenentwicklung 109<br />
5.1 Auswahl der Fallstudien<br />
In der Fallstudienforschung dienen einzelne Betrachtungen (Single-Case-Study) in der<br />
Regel dazu, ungewöhnliche oder besonders typische Phänomene zu beschreiben.<br />
Mehrfach-Betrachtungen (Multi-Case-Studies) dienen der Analyse eines Phänomens<br />
in unterschiedlichen Kontexten 419 .<br />
In vorliegender Arbeit wurden verschiedene Fälle untersucht mit dem Ziel, einen möglichst<br />
breiten Überblick über verschiedene Lösungsansätze für das agile Management<br />
von Projekten im Umfeld von AIS zu erhalten. Zur Sicherstellung der Repräsentativität<br />
der betrachteten Fälle wurden diese mittels der in Abschnitt 4.1 beschriebenen Umfrage<br />
akquiriert. Im letzten Teil des Fragebogens wurden die Unternehmensvertretenden<br />
gefragt, ob sie für eine Fallstudie zur Verfügung stehen würden. Aus den 41% positiven<br />
Rückmeldungen wurden aufgrund der individuellen Betrachtung der Antworten<br />
im Fragebogen diejenigen ausgewählt, welche nach eigenen Angaben erfolgreich agile<br />
Entwicklungsmethoden im AIS-Umfeld einsetzen. Aus den so identifizierten „good<br />
Practice“-Ansätzen wurden Fälle nach den Differenzierungsmerkmalen Typologie,<br />
Branche, Unternehmensgrösse, Projektfinanzierung und der Art der bestehenden<br />
Governance-Strukturen im Unternehmen (vgl. Tabelle 13) ausgewählt. Beratungsunternehmen<br />
wurden ausserdem aufgrund der Argumentation von CONBOY dass „[…]<br />
agile method practice has led research, with the creation, promotion, and dissemination<br />
of these methods almost completely due to the efforts of practitioners and consultants“<br />
420 hinzugezogen.<br />
Merkmal Fallstudie A Fallstudie B Fallstudie C Fallstudie D<br />
Typologie<br />
Anwender<br />
Beratungsunternehmen<br />
Beratungsunternehmen<br />
Anwender<br />
Branche AIS-Beratung Automobilhersteller AIS-Beratung Finanzinstitut<br />
Unternehmensgrösse Klein Gross Mittel Gross<br />
Projektfinanzierung Festpreis Flexibel Festpreis Flexibel<br />
Bestehende Governancestrukturen<br />
Flexible Governancestrukturen<br />
Flexible Governancestrukturen<br />
Fixe Governancestrukturen<br />
Tabelle 13: Positionierung der untersuchten Fallstudien<br />
5.2 Fallstudie A: BLUEFORTE GmbH<br />
Fixe Governancestrukturen<br />
Vorliegende Fallstudie beschreibt und analysiert, wie BLUEFORTE GmbH (BLUE-<br />
FORTE) in einem grossen AIS-Projekt bei einem Kunden zuerst mit einem klassi-<br />
419 Vgl. Stake 2006, S. 23; Yin 2009, S. 40.<br />
420 Vgl. Conboy 2009.
110 Fallstudien zur Methodenentwicklung<br />
schen Wasserfall-Ansatz gestartet ist und nach einiger Zeit aus verschiedenen Gründen<br />
gemerkt hat, dass mit dieser Vorgehensweise das Projekt nicht erfolgreich abgewickelt<br />
werden kann. Daraus hat sich in Zusammenarbeit mit dem Kunden eine neue, agile<br />
Lösung ergeben, die im Rahmen der Fallstudie genauer analysiert wird. Im Zentrum<br />
der Analyse liegt die Besonderheit des Projekts, dass es sich hierbei um eine Fixpreiskonstellation<br />
mit Werkvertrag handelt. Die Betrachtungen fokussieren insbesondere<br />
auf die Auslöser und Herausforderungen für die veränderte Methode, die neue Vorgehensweise<br />
und die dabei beteiligten Rollen.<br />
5.2.1 Unternehmensprofil<br />
Die BLUEFORTE ist eine auf BI und Performance Management spezialisierte Management-<br />
und IT-Beratung. Sie ist zu 100% inhabergeführt und berät branchenübergreifend<br />
und herstellerunabhängig. Dabei fokussiert sie auf den wachstumsstarken<br />
Mittelstand sowie Grossunternehmen. Das Leistungsangebot von BLUEFORTE deckt<br />
den gesamten Lebenszyklus von BI und Performance Management ab. Insbesondere<br />
werden organisatorische Kompetenzen, Strategie und Architektur, Technologie und<br />
Infrastruktur sowie Performance Kompetenzen abgedeckt. Tabelle 14 fasst die wichtigsten<br />
Kennzahlen und Unternehmensmerkmale zusammen.<br />
Unternehmensprofil BLUEFORTE GmbH<br />
Gründung<br />
Firmensitz<br />
Branche<br />
Geschäftsfelder<br />
Organisationsstruktur<br />
Umsatz<br />
Mitarbeitende<br />
Kunden<br />
Internetportal/Kontakt<br />
2008 gegründet durch Dirk U. Proff, Dr. Gunar Schröer und Christian Neumann in Hamburg<br />
(Deutschland)<br />
Hamburg (Deutschland)<br />
Management- und IT-Beratung für Business Intelligence und Performance Management<br />
BI Strategy, Risk Management & Compliance, BI Auditing, BI Governance, BI Competency<br />
Center (BICC), BI Sourcing, Enterprise Reporting, Performance Measurement, Process<br />
Intelligence, Large Data Warehousing, BI Life Cycle Management, Data Quality Management<br />
BLUEFORTE GmbH ist zu 100% inhabergeführt und unterhält Standorte in Hamburg,<br />
Düsseldorf und München<br />
4 Mio. EUR<br />
35 Mitarbeitende<br />
Die BLUEFORTE GmbH berät wachstumsorientierten Mittelstand und Grossunternehmen<br />
in den Branchen Retail, Financial Services, Telco & Media.<br />
http://www.blueforte.com<br />
Tabelle 14: Unternehmensprofil BLUEFORTE GmbH 421<br />
421 Vgl. BLUEFORTE GmbH 2011, sowie Erläuterungen aus dem Fallstudieninterview.
Fallstudien zur Methodenentwicklung 111<br />
5.2.2 Ausgangslage und Problemstellung<br />
Bei dem betrachteten Projekt handelt es sich um ein Grossprojekt, im Rahmen dessen<br />
ein komplettes DWH mit den entsprechenden <strong>analytische</strong>n Applikationen entwickelt<br />
wurde. Im Folgenden werden die Auslöser für das Projekt sowie die Gründe für die<br />
dabei vorgenommenen Änderungen in der Methode dokumentiert. Insbesondere fokussieren<br />
die Betrachtungen darauf, wie agile Methoden mit der Fixpreiskonstellation<br />
und Werkvertragscharakter von Projekten verein- und handhabbar ist.<br />
5.2.2.1 Ursprüngliche Data Warehouse-Landschaft und Projektauslöser<br />
Das betrachtete Projekt ist ein Grossprojekt über ca. 2000 Personentage. Dieses wird<br />
dabei von Grund auf konzipiert und wenig auf der bestehenden <strong>analytische</strong>n Informatik-Landschaft<br />
aufgebaut. Somit ist das Projekt als strategisch bedeutend und für das<br />
Kundenunternehmen als komplex und entsprechend risikobehaftet einzustufen. Aus<br />
diesem Grund hat sich für das vorliegende Projekt ein Werkvertrag mit Festpreiskonstellation<br />
ergeben. Festpreisprojekte sind typischerweise Projekte, die von Anfang an<br />
durchgeplant werden können und deren Anforderungen und Projektstruktur klar und<br />
nicht volatil sind – also Projekte, bei denen sich der Wasserfall-Ansatz anbietet.<br />
Aufgrund dessen, dass der Kunde über wenig Know-how im Bereich AIS verfügte und<br />
auch wenig <strong>Projektmanagement</strong>-Erfahrung mitbrachte, wurde BLUEFORTE mit der<br />
operativen und strategischen Projektleitung beauftragt. Das Ziel des Kundenunternehmens<br />
war es demnach, mit dem Beratungsmandat auch fundiertes <strong>Projektmanagement</strong><br />
einzukaufen. Das hohe Risiko, mit dem das Projekt verbunden war, führte dazu, dass<br />
die Unternehmensführung des Kunden darauf bestand, ein Festpreisprojekt mit entsprechendem<br />
Werkvertrag zu verhandeln.<br />
Aufgrund der Festpreiskonstellation und des daraus resultierenden Wasserfall-<br />
Ansatzes war das Projektsetup entsprechend klassisch. Seitens des Kunden wurden<br />
zwei Projektleitungen, eine IT-Projektleitung, die für die Bereitstellung von Soft- und<br />
Hardware zuständig war, und eine fachliche Projektleitung, die gleichzeitig Sponsor<br />
des Projekts war, eingesetzt. Diese hatte die fachliche Verantwortung über das Projekt<br />
und verantwortete die Sicherstellung der adäquaten Anforderungs-Implementierung.<br />
Von BLUEFORTE wurde eine Projektleitung eingesetzt, die die operative Verantwortung<br />
über die Projektabwicklung innehatte.<br />
Nach den ersten zwei Monaten der Implementierungsphase deckte sich die Erwartungshaltung<br />
nicht mehr mit der vor dem Projekt definierten, was zu einer Krise im<br />
Projekt geführt hatte. Ein Grund dafür war allerdings auch, dass während der längeren
112 Fallstudien zur Methodenentwicklung<br />
Konzeptionsphase keine greifbaren Ergebnisse sichtbar wurden. Dies steigerte die Erwartungshaltung<br />
für die Implementierung, welche in den ersten zwei Monaten nicht<br />
erfüllt werden konnte.<br />
5.2.2.2 Herausforderungen im Projektaufbau und Lösungsansätze<br />
Insbesondere zwei Problembereiche im Projekt führten aufgrund oben genannter Ausgangslage<br />
zu dieser Krise im Projekt. Diese Herausforderungen mussten für die Lösungsansätze<br />
adäquat berücksichtigt werden, um den Projekterfolg nicht zu gefährden.<br />
Keine sichtbaren Ergebnisse in der Konzeptionsphase: In der ersten Phase des Projekts<br />
wurde viel Zeit mit Konzeption und Vorarbeit verbraucht. Es wurde ein Framework<br />
aufgebaut, welches wiederverwendbare, generische Komponenten enthielt und als<br />
Grundlage für das Projekt diente. Dies führte dazu, dass in dieser Phase noch keine für<br />
den Fachbereich verwendbaren Ergebnisse erstellt wurden, was die Geschäftsleitung<br />
des projektunerfahrenen Kundenunternehmens irritierte und deren Erwartungen nicht<br />
erfüllte.<br />
Anforderungen ändern sich: Gleichzeitig hat das Kundenunternehmen aber auch gesehen,<br />
dass sich die Anforderungen im Laufe der Zeit geändert haben. Die zu Beginn der<br />
Konzeptionsphase spezifizierten Berichtsvorschläge wurden aufgrund sich ändernder<br />
Rahmenbedingungen nicht mehr gebraucht. Aufgrund dieser Begebenheit kam der<br />
Wunsch auf, mit Anforderungen flexibler umzugehen.<br />
Mit der Erkenntnis, dass basierend auf diesen Problembereichen das gegenwärtige<br />
Vorgehen nicht mehr weitergeführt werden konnte, haben sich die Beteiligten getroffen<br />
und nach einer Lösung gesucht. Insbesondere der stellvertretende Fachbereichsprojektleiter<br />
auf Kundenseite hat dabei einen wesentlichen Beitrag geleistet. Dieser hatte<br />
bereits Erfahrung mit agilen Methoden. Zusammen mit ihm konnten Punkte herausgearbeitet<br />
werden, wie vorgegangen werden musste, um den Kundennutzen des Projekts<br />
mehr in den Vordergrund rücken zu können.<br />
Aufgrund der genannten Gründe haben sich die Projektbeteiligten dazu entschlossen,<br />
das Projekt mit agilen Methoden weiterzuführen. Dabei wurde Scrum als Basis für<br />
diese agile Methode gewählt. Dieses Vorgehen bietet einen agilen Rahmen für das<br />
Abwickeln von Projekten, ohne sich dabei in Details zu verlieren. In der Praxis hat<br />
sich Scrum als Methode für das agile Management von Projekten etabliert 422 . So wurde<br />
der Geschäftsleitung vorgeschlagen, Scrum einzusetzen und hierzu externe Unterstüt-<br />
422 Vgl. Hughes 2008.
ROI<br />
Fallstudien zur Methodenentwicklung 113<br />
zung in Form eines Scrum-Trainings zu akquirieren. Aufgrund der Risikolage des Projekts<br />
wollte diese jedoch nicht auf den Festpreis- und Werkvertrags-Charakter des Projekts<br />
verzichten. Aus diesem Grund wurde der Vorschlag abgelehnt. Grundsätzlich<br />
war jedoch das Projektleitungsteam in der Ausgestaltung der Methode frei.<br />
Wie in Abbildung 27 dargestellt, ist nach Erfahrung von BLUEFORTE insbesondere<br />
die Diskrepanz zwischen der Erwartungshaltung des Kunden und dem Projektfortschritt<br />
beim Wasserfall-Ansatz ein grosses Problem. Die Darstellung zeigt, wie dieser<br />
Diskrepanz mit agilen Methoden erfolgreich begegnet werden kann.<br />
Vereinbarung<br />
Zeit<br />
Abbildung 27: Erwartungshaltung vs. Agile und Wasserfall-Ansatz 423<br />
In der Konsequenz haben sich die Projektbeteiligten auf eine Methode geeinigt, welche<br />
einerseits trotzdem die Fixpreisaspekte und den Werkvertrag berücksichtigte, jedoch<br />
stark geprägt war von agilen Elementen. In den folgenden Abschnitten wird diese<br />
Methode genauer beleuchtet und dabei werden auch Herausforderungen und Stolpersteine<br />
analysiert. Um erfolgreich zu bleiben, musste die auf Scrum basierende Methode<br />
an einigen Stellen stark angepasst werden.<br />
5.2.3 Details zum betrachteten Projekt<br />
Im Folgenden wird das Vorgehen im beschriebenen Projekt detaillierter analysiert.<br />
Dabei wird insbesondere auf den Projektablauf und die beteiligten Rollen eingegangen.<br />
423 Die Darstellung wurde im Vergleich zu der von BLUEFORTE zur Verfügung gestellten leicht modifiziert,<br />
ohne deren Aussage zu verändern. Die Aussagen, wie sich die Erwartungshaltung für den Return on Investment<br />
(ROI) mit verschiedenen Entwicklungs-Methoden im Zeitverlauf ändert, bleibt erhalten.
114 Fallstudien zur Methodenentwicklung<br />
5.2.3.1 Projektvorgehen<br />
Aufgrund der bestehenden Rahmenbedingungen haben sich insbesondere zwei Punkte<br />
für den erfolgreichen Einsatz von Scrum im Projekt herauskristallisiert. Auf der einen<br />
Seite mussten die agilen Aspekte identifiziert werden, die durch die Festpreiskonstellation<br />
nicht tangiert werden. Auf der anderen Seite mussten Wege gefunden werden, wie<br />
mit Aspekten umgegangen wird, die durch diese Festpreiskonstellation beeinflusst<br />
werden.<br />
Unabhängig der Vertragskonstellation können kürzere Iterationszyklen, kleinere Arbeitspakete<br />
und schnellere Produktivschaltung von kleinen Ergebnisinkrementen realisiert<br />
werden. Ausserdem können agile Prinzipien im Rahmen der Kommunikation und<br />
Transparenz, die die Zusammenarbeit zwischen Fachbereich, IT und Entwicklern verbessern,<br />
gelebt werden. Dazu gehören Daily Scrums und Weekly Scrums oder der Einsatz<br />
von Kanban-Boards 424 zur Erhöhung der Transparenz in der Projektsteuerung.<br />
Der Hauptaspekt, der durch die Festpreiskonstellation im vorliegenden Projekt beeinflusst<br />
wird, ist das Anforderungsmanagement. Das bedeutet, dass der Projektscope<br />
aufgrund des fixierten Umfangs nicht mehr ohne weiteres erweitert werden kann.<br />
Trotzdem haben die Projektbeteiligten festgestellt, dass sich insbesondere im AIS-<br />
Bereich Anforderungen schnell und oft ändern. Somit war die Herausforderung im<br />
betrachteten Fall, Anforderungsänderungen zu berücksichtigen, ohne dabei den Gesamtscope<br />
des Projekts zu verändern. Der Lösungsansatz lag im Konzept des Anforderungstausches.<br />
Dabei war es so, dass jedes der zu Beginn des Projekts definierten Arbeitspakete<br />
mit einem gewissen Wert in Personentagen beurteilt worden ist. Wenn der<br />
Kunde festgestellt hatte, dass ein Paket nicht mehr gebraucht wurde, so konnte dieses<br />
aufwandsneutral durch neue Anforderungen ausgetauscht werden (vgl. Abbildung 28).<br />
Natürlich bestanden im Projekt gewisse Arbeitspakete, die die Basis bildeten und somit<br />
als obligatorisch eingestuft wurden.<br />
Dieses Vorgehen bedingte, dass zu Beginn das Gesamtprojekt in Teilprojekte und<br />
kleine Arbeitspakete aufgeteilt wurde und diese anschliessend nach deren Aufwand<br />
geschätzt wurden. Das Vorgehen dabei war so, dass zuerst aus dem Gesamtprojekt<br />
kleinere Teilprojekte geschnitten wurden. Dies geschah im Backend nach den betroffenen<br />
Quellsystemen und deren wichtigen Schnittstellen. Im Frontend wurden die<br />
Fachbereichsanforderungen nach Berichten als Grundlage für die Teilprojekte genommen.<br />
Daraus entstanden unterschiedlich grosse Pakete, die geschätzt werden<br />
424 Vgl. Wolf, Rook 2011.
Priorität<br />
Fallstudien zur Methodenentwicklung 115<br />
konnten. Diese lagen zwischen 10 und 50 Personentagen. Insbesondere im Backend<br />
waren die Pakete eher grösser. Gleichzeitig ergaben sich auch grössere Abhängigkeiten,<br />
bspw. konnte aufgrund fehlender Verfügbarkeit des Backend-Entwicklungsteams<br />
eine Datenquelle nicht angebunden werden. Dieses Paket wurde daher dann zu Gunsten<br />
anderer vorläufig nicht abgearbeitet und später entsprechend der Verfügbarkeit<br />
nachentwickelt. Die jeweiligen Arbeitspakete wurden ihrerseits mithilfe einer Work-<br />
Breakdown-Structure weiter heruntergebrochen, so dass sich im Endeffekt Aufgaben<br />
im Rahmen von 1-3 Personentagen ergaben.<br />
Anforderungsänderung Backlog Timeline<br />
Change<br />
Request<br />
Anforderungstausch<br />
Prioritätentausch<br />
TP 1<br />
TP 2<br />
JAN FEB MRZ …<br />
Abbildung 28: Anforderungstausch und Change-Request bei BLUEFORTE<br />
Neben dem Anforderungstausch kamen für zusätzliche Anforderungen, die nicht im<br />
Scope des Projekts waren, klassische Change-Request-Methoden zur Anwendung (vgl.<br />
Abbildung 28). Damit konnte trotz Festpreisstruktur eine gewisse Flexibilität erreicht<br />
werden.<br />
Aufgrund der Vorarbeiten im Rahmen der Erstellung des Frameworks haben die Beteiligten<br />
herausgefunden, dass innerhalb verschiedener Arbeitspakete viele Aufgaben<br />
relativ gleichförmig waren. Es wurden bspw. ca. 400 Quellsystemtabellen identifiziert,<br />
die in das DWH integriert werden mussten. Die jeweilige Integration war mit jeweils<br />
ähnlichem Aufwand verbunden, so dass man ca. 20 Tabellen pro Monat abarbeiten<br />
konnte. Um die Flexibilität gegenüber dem Kunden noch weiter zu erhöhen, haben<br />
sich die Projektleitungen entschlossen, den Fachbereichen jeweils zu Beginn des Monats<br />
die Wahl zu lassen, welche Tabellen für kommenden Monat geplant werden sollten<br />
425 .<br />
425 Analog der Aufgabe des Product Owners im klassischen Scrum.
116 Fallstudien zur Methodenentwicklung<br />
Diese Definition eines Monats, d.h. vier Wochen als fixer Release-Cycles 426 , hatte sich<br />
schnell etabliert und bewährt. Der jeweilige Release-Cycles war eigentlich ein Sprint<br />
über vier Wochen, an dessen Ende ein produktiv nutzbares Ergebnis ausgeliefert wurde.<br />
Die unbedingte Einhaltung dieser gleichbleibenden Zeitspanne hatte sich als erfolgreich<br />
erwiesen, d.h. wichtigstes Kriterium waren die vier Wochen, flexibel waren<br />
die Ergebnisse, die in dieser Zeit geliefert wurden. Richtgrössen waren im Beispiel<br />
„Integration von Quellsystemtabellen in das DWH“ die definierten 20 Stück, ob im<br />
Endeffekt jedoch 15 oder 25 integriert wurden, war weniger wichtig. Als viel wichtiger<br />
wurde erachtet, dass in regelmässigen Abständen nutzbare Ergebnisse geliefert<br />
wurden. Dies gab der Kundenseite Transparenz, Sicherheit und Planbarkeit.<br />
Releasestart<br />
Redaktionsschluss<br />
Deployment-Ende<br />
Codefreeze<br />
Deployment-Start<br />
Woche 1<br />
Woche 3<br />
Woche 4<br />
Product Backlog<br />
Entwicklungsphase<br />
Abschlussphase<br />
Deployment<br />
Nutzenpaket 1<br />
Test<br />
Spezifikation<br />
Entwicklung<br />
Entwickler<br />
Test<br />
Modul<br />
Test<br />
Abnahme<br />
Test<br />
Nutzenpaket 2<br />
Test<br />
Spezifikation<br />
Entwicklung<br />
Entwickler<br />
Test<br />
Modul<br />
Test<br />
Abnahme<br />
Test<br />
Nutzenpaket 3<br />
Test<br />
Spezifikation<br />
Entwicklung<br />
Entwickler<br />
Test<br />
Modul<br />
Test<br />
Abnahme<br />
Test<br />
Nutzenpaket 4<br />
Test<br />
Spezifikation<br />
Entwicklung<br />
Entwickler<br />
Test<br />
Modul<br />
Test<br />
Abnahme<br />
Test<br />
Übernahme<br />
in nächstes Release<br />
Abbildung 29: Ablauf eines vier-Wochen Sprints bei BLUEFORTE<br />
Der Ablauf eines solchen Vier-Wochen-Sprints war dabei typischerweise so, dass in<br />
der ersten Woche die Planung stattfand. Hier wurde definiert, was in diesem Sprint<br />
abgearbeitet wird. In der zweiten Woche wurde entwickelt und am Ende die Planung<br />
neu betrachtet, um realistische Ziele sicherstellen zu können. Nach der dritten Woche,<br />
in der wiederum entwickelt wurde, wurde der Code eingefroren (Codefreeze), so dass<br />
in der vierten Woche Zeit für das Testen und Einführen blieb. Typischerweise kam<br />
man dabei mit ein bis zwei Tagen für die Einführung aus, nachdem sich das Vorgehen<br />
eingespielt hatte. Abbildung 29 visualisiert den beschriebenen Ablauf eines Sprints.<br />
426 Die Verwendung der Terminologien Release und Sprint wurde im betrachteten Projekt synonym verwendet.
Fallstudien zur Methodenentwicklung 117<br />
Hier wird auch deutlich, dass verschiedene Entwicklungspakete parallel realisiert wurden,<br />
so dass die Produktivität deutlich gesteigert werden konnte. Die Parallelisierung<br />
ermöglichte ausserdem, dass personelle Ressourcen, wo notwendig, zwischen den einzelnen<br />
Entwicklungspaketen verschoben werden konnten.<br />
Für das Testen war ein Testteam zuständig, welches auch bereits parallel zur Entwicklung<br />
fertige Pakete getestet hatte, d.h. die Entwicklung und das Testen liefen leicht<br />
zeitlich versetzt, aber parallel. Diese kleinen Pakete waren Aufgaben, die, wie oben<br />
beschrieben, zwischen ein und drei Entwicklungstage benötigten. Nach ein paar<br />
Sprints waren das Testteam und das Entwicklungsteam so eingespielt, dass der Entwicklungs-<br />
und Testfortschritt nahezu gleichlaufend war. Ein wichtiges Prinzip bei der<br />
Einführung am Ende des Sprints war, dass nur wirklich getestete Pakete ausgeliefert<br />
werden durften. Wenn bspw. eine Tabelle im Backend noch nicht vollständig getestet<br />
war am Ende des Sprints, wurde diese auf den nächsten Sprint verlegt. Gleich verfuhren<br />
die Projektteams auch im Frontend. Microstrategy 427 , das verwendete Frontend-<br />
Werkzeug, ermöglichte es, kleine Arbeitspakete zu definieren. Auch diese wurden nur<br />
vollständig getestet ausgeliefert. Teilweise hatte dies zur Folge, dass nach einem<br />
Sprint nur ein neuer Bericht ausgeliefert wurde, jedoch konnte ein Durchschnitt von<br />
zwei bis drei Berichten pro Monat eingehalten werden.<br />
Das grundsätzliche Vorgehen bei der Entwicklung des Back- und Frontend war so,<br />
dass in einem ersten Schritt die Anforderungen für das Frontend soweit spezifiziert<br />
wurden, bis diese stabil waren. Konkret arbeiteten die Projektbeteiligten hierbei eng<br />
mit den Anwendenden aus dem Fachbereich zusammen. Diese wurden auch in die<br />
Testphase mit einbezogen. Dabei wurde basierend auf verbal formulierten Anforderungen<br />
oder rudimentären Excel-Modellen, ein erster Prototyp des Frontends erstellt.<br />
Dieser wurde anschliessend iterativ mit dem Fachbereich soweit ausgereift, bis der<br />
fertige Bericht, ohne Dateninhalt und die dazugehörigen Schnittstellen, stabil war.<br />
Hierbei wurde aufgrund der Arbeit mit Prototypen auf genaue Dokumentation von Berichtspezifikationen<br />
verzichtet und die Zeit für intensivere Arbeit mit den Endanwendenden<br />
verwendet.<br />
Auf den im Frontend spezifizierten Anforderungen und Schnittstellen basierend konnte,<br />
jeweils im Anschluss und später auch parallel, die entsprechende Anbindung der<br />
Datenquellen an das DWH realisiert werden. Bezüglich der Abhängigkeiten zwischen<br />
Frontend und Backend hatten die Projektteams insofern Glück, als das von den 400 zu<br />
integrierenden Tabellen lediglich 80-120 direkt für das Frontend relevant waren. Die<br />
427 Details vgl. MicroStrategy Inc. 2012.
118 Fallstudien zur Methodenentwicklung<br />
restlichen Tabellen waren für andere Anforderungen wie bspw. Data Mining relevant.<br />
So gab es zu Beginn relativ hohe Abhängigkeiten zwischen Frontend und Backend,<br />
was einen entsprechend hohen Abstimmungsbedarf zur Folge hatte. Allerdings war es<br />
für das Backend-Team nicht relevant, welche Tabelle als nächstes integriert wurde, so<br />
dass die Frontend-Teams in Zusammenarbeit mit den Fachbereichen die notwendigen<br />
Tabellen eruieren konnten. Dies wurde als Arbeitspaket an das Backend-Team weitergeleitet,<br />
welches die Tabellen entsprechend integrierten. Nach einer gewissen Zeit,<br />
bzw. nach einer gewissen Anzahl Sprints, konnte so ein Grundstock an integrierten<br />
Tabellen aufgebaut werden. Dies ermöglichte es, dass sich Frontend- und Backend-<br />
Teams etwas voneinander lösen und unabhängiger entwickeln konnten. Eine weitere<br />
Vereinfachung für das Frontend-Team war es, dass das Datenmodell für das DWH<br />
schon lange fertig war, bevor die Tabellen für die Berichte gebraucht wurden. So<br />
konnte schon früh auf leere Tabellen zugegriffen werden und diese wo notwendig mit<br />
Dummy-Daten gefüllt werden.<br />
Mit dem Ziel, die Methode möglichst den agilen Prinzipien folgend zu gestalten, wurde<br />
auch die Dokumentation entsprechend schlank gehalten. Im Backend wurde mit Ab<br />
Initio 428 entwickelt. Hierbei handelt es sich um ein grafisches Entwicklungswerkzeug.<br />
Sämtliche Dokumentationen, die das Backend betroffen haben, wurden direkt in diesem<br />
Werkzeug erstellt. Ähnlich wurde auch im Frontend verfahren. Auch hier wurde<br />
direkt im Tool dokumentiert. Im vorliegenden Fall war diese Art von Dokumentation<br />
in einem ersten Schritt etwas problematisch, da das Projekt nach dessen Abschluss für<br />
den Betrieb an eine neue Person übergeben wurde. Diese Person hatte zu Beginn Probleme<br />
damit, dass nur das Nötigste dokumentiert wurde. Im Nachhinein muss dies für<br />
solche Projekte als Risiko eingestuft werden. Die betroffenen Mitarbeitenden müssen<br />
bereits während der Projektlaufzeit instruiert werden, wie die Dokumentation stattfindet<br />
und dass das Wissen durch die enge Zusammenarbeit aller Beteiligten sowohl bei<br />
den Entwicklungsteams, als auch bei den Fachanwendenden liegt.<br />
Scrum sieht vor, dass nach jedem Sprint eine Retrospektive durchgeführt wird, bei der<br />
sich das Projektteam kritisch reflektiert und aufgrund der Ergebnisse Massnahmen<br />
ableitet. Damit wird das Ziel verfolgt, eine ständige Verbesserung der Leistung zu erreichen.<br />
Im vorliegenden Fall wurden solche Retrospektiven häufiger durchgeführt,<br />
jedoch nicht institutionalisiert. Die Projektleitung hatte situativ eine solche einberufen,<br />
wenn ein Sprint nicht zur vollsten Zufriedenheit verlaufen war.<br />
428 Details vgl. Ab Initio Software LLC 2012.
Fallstudien zur Methodenentwicklung 119<br />
5.2.3.2 Beteiligte Rollen<br />
Das Projektteam im untersuchten Fall bestand nach der Neuorientierung aus insgesamt<br />
ca. 15 Personen. Diese waren aufgeteilt in Projektmitglieder seitens des Kundenunternehmens<br />
und BLUEFORTE.<br />
Seitens des Kundenunternehmens gab es eine flexible Anzahl Fachbereichsmitarbeitende,<br />
die jedoch nicht zu 100% für das Projekt freigestellt waren und nur bei Bedarf<br />
mit einbezogen wurden. Hinzu kamen zwei Projektleitungen, eine von der fachlichen<br />
Seite und eine von der IT. Diese waren für das Projekt zu 100% freigestellt. Ausserdem<br />
konnte vom Kundenunternehmen aus auf zwei bis drei Entwickelnde zugegriffen<br />
werden. Diese hatten allerdings keine Erfahrung im AIS-Bereich und nutzen das Projekt<br />
als Lernfeld. BLUEFORTE hatte entsprechend zusätzlich einen Ausbildungsauftrag.<br />
BLUEFORTE stellte ihrerseits insbesondere das Entwicklungsteam, welches aus drei<br />
Frontend- und vier Backendentwickelnden bestand. Hinzu kamen durchschnittlich<br />
zwei Business Analysten sowie eine Projektleitung, die durch den Interviewpartner<br />
eingenommen wurde. Dieser übernahm diese Rolle allerdings erst nach der Krise und<br />
der erforderlichen Neubetrachtung des Projekts.<br />
Bezüglich des Rollenverständnisses gab es in der Anfangsphase der Einführung der<br />
agilen Methode Diskussionen. Nachdem die Geschäftsleitung davon überzeugt werden<br />
konnte, agile Methoden einzusetzen, war insbesondere die fachliche Projektleitung<br />
seitens des Kunden der Meinung, die Rollen sollten entsprechend direkt aus Scrum<br />
übernommen werden. Dies hätte bedeutet, dass der Product Owner aus dem Kundenunternehmen<br />
die Verantwortung für die Funktion des Endergebnisses trägt, dass es<br />
keine Projektleitungen gibt und dass der Scrum Master durch BLUEFORTE übernommen<br />
wird. Dieser wäre dann ausschliesslich für die Einhaltung der Methode und<br />
Schaffung geeigneter Rahmenbedingungen verantwortlich gewesen. Schnell wurde<br />
allerdings klar, dass dies nicht praktikabel ist. Aufgrund der Festpreiskonstellation trug<br />
BLUEFORTE auch das finanzielle Risiko des Projekts und musste somit über entsprechende<br />
Kompetenzen verfügen, das Projekt zu steuern. Gleichzeitig hätte der Product<br />
Owner auf Kundenseite die Möglichkeit gehabt, das Projekt zu Lasten von BLUE-<br />
FORTE anzupassen und den Scope nach Belieben zu kontrollieren. Aus diesem Grund<br />
ist man bei der bestehenden Rollenverteilung geblieben.
120 Fallstudien zur Methodenentwicklung<br />
Um einen Überblick über die Anpassungen der Rollen im vorliegenden Projekt gegenüber<br />
dem klassischen Scrum zu erhalten, werden diese den entsprechenden Rollen gegenübergestellt:<br />
Product Owner: Die Rolle des Product Owners wurde in vorliegendem Fall, wie durch<br />
Scrum angedacht, teilweise durch den Fachbereich, d.h. durch die fachliche Projektleitung<br />
auf Kundenseite, übernommen. Gewisse Aufgaben, wie bspw. das Anforderungsmanagement,<br />
verantwortete allerdings die Projektleitung seitens BLUEFORTE.<br />
Zu deren Aufgaben gehörte unter anderem auch das Lösen zwischenmenschlicher<br />
Probleme im Projektablauf. Die Rolle des Product Owners wurde somit aufgeteilt auf<br />
die Projektleitung des Kunden und von BLUEFORTE.<br />
Daneben wurde im betrachteten Projekt die Rolle des technischen Projektleiters auf<br />
Kundenseite verwendet. Diese ist im klassischen Scrum nicht vorgesehen. Die Aufgabe<br />
der technischen Projektleitung war es, aufkommende technische Hürden frühzeitig<br />
zu lösen, sei es durch die entsprechende Bereitstellung von Hard- und Software oder<br />
das Lösen technischer Probleme. Diese Rolle hat sich im Projekt als sehr hilfreich erwiesen.<br />
Scrum Master: Die Rolle des Scrum Masters wurde im betrachteten Projekt durch die<br />
Projektleitung von BLUEFORTE übernommen. Neben Aufgaben wie bspw. Budgetund<br />
Ressourcenkontrolle, war diese auch zuständig dafür, dass die Methode eingehalten<br />
wurde und schuf die notwendigen Rahmenbedingungen für effizientes Arbeiten.<br />
Team: Das Entwicklungsteam, welches in erster Linie durch BLUEFORTE gestellt<br />
wurde, teilte sich in die Bereiche Frontend und Backend auf. Dabei wurden drei Frontend-Entwickelnde<br />
mit Fokus auf Mircostrategy sowie vier Backend-Entwickler mit Ab<br />
Initio-Fokus eingesetzt. Zusätzlich wurden bis zu zwei Business Analysten beschäftigt<br />
und von Kundenseite unterstützten zwei bis drei wenig AIS-erfahrene Entwickler das<br />
Team. Das Entwicklungsteam entsprach somit dem, was Scrum vorsieht, jedoch mit<br />
entsprechender Spezialisierung auf Frontend bzw. Backend sowie Business Analyse.<br />
Outsourcing und die damit verbundene Problematik mit agilen Methoden 429 war in<br />
diesem Projekt kein Thema, da das Betriebsteam, welches jetzt im Einsatz ist, vor Ort<br />
arbeitet und zu weiten Teilen durch BLUEFORTE ausgebildet wurde.<br />
429 Durch die intensive Interaktion innerhalb des Projektteams sehen viele agile Methoden die Voraussetzung,<br />
dass die Teammitglieder in unmittelbarer geographischer Nähe arbeiten.
Fallstudien zur Methodenentwicklung 121<br />
5.2.4 Wesentliche Erkenntnisse und Ausblick<br />
Auf Basis der Analyse des vorliegenden Projekts lassen sich eine Reihe von Erkenntnissen<br />
und Herausforderungen ableiten. Erkenntnisse sind dabei grundsätzliche Wirkungsweisen<br />
agiler Entwicklungsmethoden, während die Herausforderungen potenzielle<br />
Schwierigkeiten in der Umsetzung agiler Methoden beschreiben.<br />
Das Projekt wurde zur Zufriedenheit aller erfolgreich abgeschlossen. Nach der krisenbedingten<br />
Neubetrachtung, Neuplanung und -budgetierung für die Restlaufzeit konnte<br />
das agile Vorgehen erfolgreich abgebildet und umgesetzt werden. Insgesamt konnte<br />
der Projektabschluss so sowohl zeitlich, als auch finanziell sehr genau getroffen werden.<br />
Aufgrund des Erfolgs des Projekts plant BLUEFORTE, die Erkenntnisse aus dem Projekt<br />
zu formalisieren und für weitere Projekte wieder zu verwenden. Insbesondere für<br />
grosse AIS-Projekte, die auf wenig Bestehendem aufbauen, eignet sich diese Methode<br />
sehr gut.<br />
Erkenntnisse:<br />
Vorbereitung des Kundenunternehmens: Einer der Hauptunterschiede, ob ein Projekt<br />
von einem externen Unternehmen oder der internen AIS-Abteilung durchgeführt wird,<br />
ist, dass die externen Dienstleister immer wieder mit neuen Kunden zusammenarbeiten<br />
und damit mit neuen Unternehmensstrukturen konfrontiert sind. Wenn agile Methoden<br />
eingesetzt werden, muss vorgängig geprüft werden, inwiefern das Kundenunternehmen<br />
für solches Vorgehen bereit ist. Insbesondere in traditionsreichen Unternehmen<br />
mit starren Strukturen bedarf es einer umfassenden Betrachtung und entsprechenden<br />
Vorbereitungsmassnahmen, damit agile Methoden nicht an Vorbehalten und ablehnender<br />
Haltung scheitern.<br />
Entwicklung eines Frameworks für das Projekt: Die Erfahrung von BLUEFORTE hat<br />
gezeigt, dass es sinnvoll ist, in einem ersten Schritt im Projekt ein Framework zu entwickeln,<br />
welches einen Gesamtüberblick über den Scope des Projekts gibt und wiederverwendbare<br />
Module identifiziert. Aufgrund der Ganzheitlichkeit dieses Frameworks<br />
ist es allerdings nur schwer möglich, dies in kleine Pakete zu schneiden, so dass<br />
diese in einzelnen Sprints abgewickelt werden können. Somit muss dieses Framework<br />
gezwungenermassen als Ganzes entwickelt werden. Gleichzeitig fungiert es aber auch<br />
als Vorbereitung für das Gesamtprojekt. Aus diesem Grund wird durch BLUEFORTE<br />
die These vertreten, dass zu Beginn eines grossen Projekts eine Phase eingelegt werden<br />
muss, in der dieses Framework und ein Big Picture mit einer groben Release- und
122 Fallstudien zur Methodenentwicklung<br />
Sprintplanung für das Projekt entwickelt werden muss. Ausserdem werden in dieser<br />
Phase grundsätzliche Vorbereitungen wie bspw. Ressourcenplanung, strategische Entscheidungen<br />
oder Hard- und Softwareentscheidungen getroffen. Diese These deckt<br />
sich mit dem Vorgehen von HUGHES 430 , der einen sog. Sprint 0 vor das eigentliche<br />
Projekt stellt, wo ebendiese Aspekte geklärt werden. Die Durchführung einer solchen<br />
längeren Phase zu Beginn muss, so BLUEFORTE, mittels klassischen Wasserfall-<br />
Ansatzes erfolgen. Eine transparente Kommunikation ist gegenüber dem Kunden elementar,<br />
damit die eingangs beschriebene Krise nicht eintritt und die Erwartungshaltungen<br />
klar sind.<br />
Anforderungstausch: Als elementar hat sich im vorliegenden Projekt mit Festpreisstruktur<br />
und Werkvertrag auch das Konzept des Anforderungstausches erwiesen.<br />
Durch die initiale Schätzung der zuvor definierten Arbeitspakete können, bei sich ändernden<br />
Anforderungen, diese aufwandsneutral durch andere Pakete ausgetauscht<br />
werden. Der Gesamtscope bleibt dabei bestehen und trotzdem kann auf die Volatilität<br />
im Projektumfeld reagiert werden. Für BLUEFORTE war dies einer der Haupterfolgsfaktoren<br />
für die Abwicklung des beschriebenen Projekts.<br />
Einbezug der Kunden: Ein weiterer Erfolgsfaktor im betrachteten Projekt sieht BLUE-<br />
FORTE im engen Einbezug der Endanwendenden in die Entwicklung. Dies konnte<br />
einerseits sicherstellen, dass das Ergebnis den Erwartungen der Fachbereiche entsprach<br />
und andererseits auch das Verhältnis zwischen IT, Fachbereich und BLUE-<br />
FORTE erheblich verbesserte. Dies ging sogar soweit, dass einzelne Fachbereichsvertreter<br />
im Laufe der Zeit auf freiwilliger Basis an den Daily Scrums teilgenommen haben,<br />
um den Überblick über das Projekt zu behalten und die Entwicklung des Projekts<br />
in zehn Minuten beobachten zu können.<br />
Aufwandschätzung: Scrum sieht zur Aufwandschätzung einzelner Arbeitspakete Story<br />
Points und Estimation Poker 431 vor. Aufgrund ihrer Erfahrung haben sich die Entwicklungsteams<br />
jedoch schwer getan mit dieser abstrakten Methode, die Aufwände zu<br />
schätzen. Vielmehr konnten sie sich mit den ihnen bekannten Personentagen identifizieren.<br />
Diese Vorgehensweise hat gut funktioniert und zu genauen Resultaten geführt.<br />
Die Aufwandschätzung wurde zu Beginn des Projekts einmal durchgeführt und anschliessend<br />
immer dann angepasst, wenn es Anforderungstausche gegeben hat. Die<br />
initiale Schätzung wurde dabei jeweils basierend auf festgelegten Kriterien durchgeführt,<br />
ohne die genauen Inhalte der Pakete kennen zu müssen. Für die jeweiligen Teil-<br />
430 Vgl. Hughes 2008, S. 44f.<br />
431 Vgl. Hughes 2008, S. 106ff., bzw. Abschnitt 6.3.10.2.
Fallstudien zur Methodenentwicklung 123<br />
bereiche bspw. einer Berichtserstellung wurden hierzu Wertebereiche definiert und mit<br />
Annahmen hierzu hinterlegt. Für jeden Teilbereich wurde dann ein Wertebereich entsprechend<br />
des geschätzten Aufwands ausgewählt, was in der Summe eine Schätzung<br />
für den Gesamtaufwand dieser Reporterstellung ergab. Es wurden jeweils für die drei<br />
Klassen „einfacher Bericht“, „schwieriger Bericht“ und „komplexer Bericht“ eigene<br />
Templates mit eigenen Wertebereichen und Annahmen auf Excel-Basis verwendet.<br />
Für das Management dieser Aufwände wurde Jira 432 als Anforderungsdatenbank verwendet.<br />
Mithilfe dieses Werkzeugs konnte die Planung durchgeführt werden und<br />
bspw. Burn up- und Burn down-Charts generiert werden 433 .<br />
Zentrale Herausforderungen:<br />
Initialer Aufwand vor der Neuorientierung: Ein Punkt, den BLUEFORTE aus den Erfahrungen<br />
des Projekts als verbesserungswürdig mitnimmt, ist die Tatsache, dass sie<br />
den Aufwand, der vor der Krise und der darauffolgenden Neuorientierung angefallen<br />
ist, bis zum Ende mittragen mussten. Sie mussten diesen Aufwand als Lehrgeld bezahlen,<br />
auch aufgrund dessen, dass sie zu wenig kundenorientiert in das Projekt gestartet<br />
sind. Natürlich konnte auch aus dieser Phase ein gewisser Output realisiert werden,<br />
wie bspw. das Framework, welches auch im weiteren Verlauf verwendet werden konnte.<br />
Ein wesentlicher Teil der bis dahin erarbeiteten Ergebnisse musste jedoch verworfen<br />
werden. Das Learning, welches daraus gezogen wurde, war, dass in der Planung<br />
das Entwicklungsteam enger mit einbezogen werden muss und so die Aufwände genauer<br />
abgeschätzt werden können. Gleichzeitig muss zukünftig die Kommunikation<br />
mit dem Kunden in der Anfangsphase transparenter gestaltet werden, so dass dessen<br />
Erwartungshaltung realistischer ist.<br />
Agile Denkweise im Unternehmen etablieren: Was insbesondere nach der Neuorientierung<br />
des Projekts von Seiten BLUEFORTES unterschätzt wurde, ist, dass agile Entwicklung<br />
im Entwicklungsteam alleine nicht ausreicht. Vielmehr muss eine solche<br />
agile Methode und die agile Denkweise in der ganzen Organisation etabliert werden.<br />
Im Nachhinein sind sich alle Beteiligten einig, dass eine Art Schulung für diese<br />
Denkweise für alle Beteiligten, also auch für die Fachbereiche, sinnvoll gewesen wäre.<br />
Nur so kann die Flexibilität, die eine solche Vorgehensweise von allen, insbesondere<br />
von den Fachbereichen erwartet, erreicht werden. Auch von der IT her war es nicht<br />
immer einfach, diese Flexibilität zu gewährleisten. Hier wurde die IT-Projektleitung<br />
mit eingespannt, die dann rechtzeitig versucht hat, diese Hürden aus dem Weg zu räu-<br />
432 Details vgl. Atlassian 2012.<br />
433 Vgl. hierzu die Ausführungen in Abschnitt 6.3.13.2.
124 Fallstudien zur Methodenentwicklung<br />
men. Die gesamte Organisation muss also ein agiles Vorgehen zuerst lernen, bevor es<br />
produktiv eingesetzt werden kann. Insbesondere von der Geschäftsleitung her hat es<br />
lange gedauert, bis diese gemerkt hat, dass das Projekt nach wie vor im Plan ist und<br />
dass dieses Vorgehen durchaus positiven Effekt auf den Projektoutput hat. Auch im<br />
Reporting gegenüber der Geschäftsleitung war es so, dass diese vor allem die klassischen<br />
<strong>Projektmanagement</strong>-Instrumente wie bspw. die Earned Value Methode 434 , interessiert<br />
hat. Dies kann durchaus in einem solchen Projekt, insbesondere bei einer Fixpreiskonstellation,<br />
genutzt werden, aber am Anfang haben sich alle Beteiligten schwer<br />
getan. Es musste deshalb dieses neue Vorgehen mit klassischem <strong>Projektmanagement</strong><br />
kombiniert werden. Aufgrund der Aufteilung des Gesamtprojekts in möglichst kleine<br />
Pakete, konnten diese nach der Earned Value Methode bewertet werden. Konkret wurden<br />
Pakete, die noch nicht in der Entwicklung waren, mit 0%, solche in der Entwicklung<br />
mit 10%, fertig entwickelte mit 90% und fertig getestete mit 100% bewertet. Auf<br />
Basis dieser Bewertung und der entsprechenden Aggregation konnte jederzeit ein genauer<br />
Statusbericht über das Gesamtprojekt geliefert werden. Bei Anforderungstausch<br />
wurden die Pakte neu bewertet und in den Gesamtstatus integriert.<br />
Diskussionen über initial definierte Anforderungen: Aus BLUEFORTES Erfahrung<br />
gibt es im Rahmen von Festpreiskonstellationen im Laufe des Projekts immer wieder<br />
Diskussionen darüber, was initial als zu erarbeitende Anforderung definiert wurde und<br />
was als Change Request gehandhabt werden muss. Im vorliegenden Projekt konnte<br />
diese Diskussion zugunsten einer pragmatischen Lösung verhindert werden. Es wurden<br />
bereits in frühen Phasen Puffertage gesammelt, die dafür eingesetzt wurden, um<br />
dem Kunden entgegen zu kommen und Anforderungen umzusetzen, die aus Sicht von<br />
BLUEFORTE nicht initial definiert wurden. Diese Puffertage kamen bspw. dadurch<br />
zustande, dass ein Paket zu einem gewissen Zeitpunkt nicht implementiert werden<br />
konnte, da auf Kundenseite die notwendigen Ressourcen nicht vorhanden waren. Natürlich<br />
wurde diese Ansammlung der Puffertage transparent kommuniziert und in Absprache<br />
mit dem Kunden definiert. Sie stellten so eine besondere Art des Anforderungstausches<br />
dar, der für Unvorhergesehenes eingesetzt werden konnte. So haben<br />
sich 50-60 Tage aufgebaut, die als Reserve genutzt werden konnten, um Anforderungen<br />
umzusetzen, ohne sich auf Diskussionen einlassen zu müssen. Dies hat Unmut<br />
verhindert und damit zu einer deutlich besseren Zusammenarbeit geführt.<br />
Gateways und bestehende Strukturen: Zur Steuerung von Projekten müssen Projekte in<br />
vielen Unternehmen regelmässig Gateways durchlaufen, die durch Steuerungsgremien<br />
434 Vgl. bspw. Kuster et al. 2008, S. 316f.
Fallstudien zur Methodenentwicklung 125<br />
abgenommen werden. Auch im vorliegenden Kundenunternehmen gab es einen Abnahmeprozess<br />
(vgl. Abbildung 30).<br />
Fachbereich Entwicklung Testteam Testteam Entwicklung<br />
FEEDBACK<br />
LOOP<br />
QUALITY<br />
GATE<br />
1<br />
QUALITY<br />
GATE<br />
2<br />
QUALITY<br />
GATE<br />
3<br />
Anforderung<br />
Entwicklung<br />
Entwicklertest<br />
Modultest<br />
Abnahmetest<br />
Deployment<br />
10% 35% 15% 35% 5%<br />
Abbildung 30: Abnahmeprozess für Entwicklungspakete bei BLUEFORTE<br />
Dieser ist zwar sehr formell, jedoch flexibel gestaltet. So haben die Projektleitungen<br />
das Gesamtprojekt im Rahmen der Projektinitialisierung in Kleinstpakete aufgeteilt,<br />
die ihrerseits durch den Abnahmeprozess gelaufen sind. Dies konnte bereits in einer<br />
frühen Phase des Projekts geschehen und somit wurde die weitere agile Arbeit im Projekt<br />
nicht behindert. Gleichzeitig wurde die Abnahme auch während der Entwicklung<br />
innerhalb der Entwicklungs-Sprints durchgeführt, so dass nur vollständig abgenommene<br />
Pakete am Ende des Sprints ausgeliefert wurden (vgl. Abbildung 30).<br />
5.3 Fallstudie B: BMW AG<br />
Die folgende Fallstudie beschreibt die agile Methode, die in der BMW Group, insbesondere<br />
im Bereich Einkauf, eingesetzt wird. Dabei wird die Ausgangslage und die<br />
Problemstellung im Unternehmen vor der Veränderung erläutert und anschliessend<br />
detaillierter auf die agile Methode eingegangen. Die Betrachtungen fokussieren dabei<br />
auf ein Veränderungsprogramm im Einkauf, wo einerseits der Ursprung und der Druck<br />
für eine Veränderung liegen und andererseits die neue Methode erfolgreich eingesetzt<br />
wird.<br />
5.3.1 Unternehmensprofil<br />
Die BMW Group ist weltweit einer der erfolgreichsten Hersteller von Automobilen<br />
und Motorrädern. In Deutschland zählt sie zu den grössten Industrieunternehmen. Die<br />
BMW Group positioniert sich im Premium-Segment und verfügt mit den Marken
126 Fallstudien zur Methodenentwicklung<br />
BMW, MINI und Rolls Royce über eine starke Präsenz in der Automobilbranche. Tabelle<br />
15 fasst die wichtigsten Kennzahlen und Unternehmensmerkmale zusammen.<br />
Unternehmensprofil BMW Group<br />
Gründung<br />
Firmensitz<br />
Branche<br />
Geschäftsfelder<br />
Organisationsstruktur<br />
1916 als Bayrische Flugzeugwerke AG (BFW),<br />
1917 Umwandlung zu Bayrische Motorenwerke G.m.b.H,<br />
1918 Umwandlung zu Bayrische Motorenwerke Aktiengesellschaft (BMW AG)<br />
München (Deutschland)<br />
Automobil- und Motorradhersteller<br />
Automobile, Motorräder, Finanzdienstleistungen<br />
Die BMW Group unterhält neben der Zentrale in München Standorte für Forschung und<br />
Entwicklung, Produktion, Montage und Vertrieb auf allen Kontinenten.<br />
Umsatz Weltweit 60‘477 Mio. EUR (Geschäftsjahr 2010)<br />
Operatives Ergebnis (EBIT) Weltweit 4‘836 Mio. EUR (Geschäftsjahr 2010)<br />
Mitarbeitende 95‘453 Mitarbeitende weltweit (Geschäftsjahr 2010)<br />
Internetportal/Kontakt<br />
http://www.bmwgroup.com<br />
Tabelle 15: Unternehmensprofil BMW Group 435<br />
5.3.2 Ausgangslage und Problemstellung im Unternehmen<br />
Im Zuge der immer schnelllebiger werdenden Gesellschaft und der damit verbundenen<br />
Konsequenzen für Unternehmen ist der Wasserfall-Ansatz für Projekte im Umfeld der<br />
IT nicht mehr zeitgemäss. Zu dieser Auffassung ist man vor allem im Einkauf der<br />
BMW Group gekommen. Die Fachvertretenden verfügen nicht über die Fähigkeit, aus<br />
einem Konzept so zu abstrahieren, dass für sie die angestrebte Lösung konkret fassbar<br />
wird. Gleichzeitig verändern sich die Fachanforderungen während eines Projekts so,<br />
dass ein vorgängig erstelltes Konzept in kurzer Zeit nicht mehr verwendet werden<br />
kann. Vor diesem Hintergrund entstand das Bestreben bei der BMW Group, die vorherrschende<br />
Projektmethode auf die neuen Bedürfnisse anzupassen.<br />
5.3.2.1 Ursprüngliche Methode und Auslöser der Veränderung<br />
Seit vielen Jahren werden bei der BMW Group grosse IT-Projekte durchgeführt. Diese<br />
wurden immer mit der bei der BMW Group verwendeten Methode, der IT Process<br />
Quality Management Methode (ITPM), durchgeführt. Diese Methode ist stark wasserfallorientiert<br />
und angelehnt an ITIL. Die Methode ist ein BMW spezifisches Qualitätsmanagement-System<br />
für IT-Prozesse, welches die Bereiche „Programm Management“,<br />
„Projektdurchführung“, „Systemwartung“, „Systembetrieb“ und deren Schnitt-<br />
435 Vgl. BMW Group 2010a; BMW Group 2010b.
Fallstudien zur Methodenentwicklung 127<br />
stellen zueinander behandelt. Für die Projektdurchführung werden fünf Phasen unterschieden,<br />
die in Abbildung 31 dargestellt sind.<br />
1 2 3 4 5<br />
Implementierung<br />
Projektauftrag<br />
Grobkonzept<br />
Fachkonzept<br />
Abnahme<br />
Quality<br />
Gate<br />
Quality<br />
Gate<br />
Quality<br />
Gate<br />
Quality<br />
Gate<br />
Abbildung 31: Phasen der IT Process Management-Methode<br />
Phase 1: Projektauftrag: Der Projektauftrag beinhaltet sämtliche Aspekte bezüglich<br />
der Planung von Ressourcen und dem Vorgehen. Mithilfe von Templates wird detailliert<br />
beschrieben, was das Vorhaben ist und wie vorgegangen wird, um dieses zu erreichen.<br />
Der so erstellte Projektauftrag muss anschliessend einen Gateway passieren, wobei<br />
dieser durch ein Gremium genehmigt oder abgelehnt wird. Bis ein genehmigter<br />
Projektantrag vorliegt, kann es 6-10 Wochen dauern.<br />
Phase 2: Grobkonzept: Im Grobkonzept werden nach der Freigabe des Projektauftrags<br />
mögliche Alternativen, die Ist-Prozesse, die Soll-Prozesse, Lösungsalternativen,<br />
die IT-Architektur, die fachlichen Anforderungen, etc. beschrieben. Auch das Grobkonzept<br />
wird in einem Gateway vom Abnahmegremium verabschiedet.<br />
Phase 3: Fachkonzept: Das Fachkonzept detailliert das Grobkonzept weiter und der<br />
Projektablauf wird geplant. Es wird wiederum in einem Gateway verabschiedet.<br />
Phase 4: Implementierung: Die eigentliche Projektdurchführung geschieht in der<br />
Implementierungsphase. Hier werden neben der Konfiguration und Programmierung<br />
der Anforderungen auch Integrationstests durchgeführt. Auch diese Phase wird durch<br />
einen Gateway abgeschlossen.<br />
Phase 5: Abnahme: Die letzte Phase nach ITPM bildet die Abnahme. In dieser Phase<br />
wird das fertige und getestete IT-System final abgenommen und in die Linienorganisation<br />
übergeben, wo es produktiv geschaltet wird. Diese Phase ist ein letzter Gateway,<br />
bevor das Projekt abgeschlossen ist.<br />
Das Vorgehen nach ITPM ist charakterisiert durch eine streng sequentielle Abfolge<br />
von Aktivitäten, an deren Ende jeweils ein Ergebnis erstellt wird und nach Durchlauf<br />
aller Phasen das fertige, getestete und abgenommene Endergebnis resultiert. Innerhalb<br />
des Vorgehens kann dabei auf eine jahrelange Erfahrung zurückgegriffen werden.
128 Fallstudien zur Methodenentwicklung<br />
Aufgrund der Mächtigkeit des Ansatzes und den zahlreichen Werkzeugen und Templates,<br />
die zur Verfügung stehen, ist dieses Vorgehen hocheffizient.<br />
Neben der Effizienz ergeben sich aus der Erfahrung der BMW Group aber auch negative<br />
Effekte im Rahmen des Einsatzes dieser Methode. So gibt es im Projekt nur wenige<br />
Möglichkeiten, Veränderungen zu berücksichtigen. Wenn bspw. sich in der Implementierungsphase<br />
grundlegende Benutzeranforderungen ändern oder neue Rahmenbedingungen<br />
entstehen, ist das Projektteam gezwungen, das Projekt neu zu starten und<br />
die bereits erstellten Ergebnisse zu verwerfen. Gleichzeitig sind nur wenige Fachvertretende<br />
in der Lage, ihre Anforderungen vorab zu spezifizieren bzw. dies so zu abstrahieren,<br />
dass sie konzeptionell erfasst werden können. Dies führt entsprechend dazu,<br />
dass erst im Laufe des Projekts klar wird, was die Fachabteilungen brauchen.<br />
Genau diese Aspekte zeigten im Jahre 2009, dass die bis dahin verwendete ITPM-<br />
Methode nicht immer zielführend ist und dass viele Projekte nicht kundenorientiert<br />
durchgeführt werden können, wenn Anforderungen volatil sind. Damals musste ein<br />
Projekt durchgeführt werden, bei welchem die Vorgabe war, in 6 Monaten fertige Ergebnisse<br />
zu liefern. Das Projekt bewegte sich genau in einem solch volatilen Umfeld,<br />
so dass die breite Meinung war, dass dieses unmöglich in 6 Monaten durchgeführt<br />
werden konnte. Die einzige Möglichkeit für eine erfolgreiche Abwicklung war es, die<br />
Methode so anzupassen, dass die Projektergebnisse in kleinen Stücken erstellt und<br />
ausgeliefert wurden. Gleichzeitig war das Ziel, sich iterativ immer weiter der Lösung<br />
zu nähern und jeweils einen Prototypen zu erstellen, diesen mit dem Kunden zu besprechen<br />
und in einer nächsten Iteration Änderungen und neuen Anforderungen umzusetzen.<br />
Agilität war zu dieser Zeit noch kein Thema bei der BMW Group.<br />
Der Projektinhalt war dabei die Abbildung eines Einkaufsprozesses in einem neu aufzubauenden<br />
IT-System. Im Rahmen dessen sollten keine Änderungen der zugrunde<br />
liegenden Datenstruktur gemacht werden. Es wurde ausschliesslich die Frontend-Seite<br />
angepasst. Dabei wurde so vorgegangen, dass noch bevor Konzepte geschrieben wurden,<br />
die entsprechenden Benutzerschnittstellen basierend auf Dummy-Daten entworfen<br />
wurden. Diese wurden anschliessend mit den Fachanwendenden abgestimmt und<br />
weiter verfeinert, bis neben dem Inhalt und Aufbau dieser Schnittstellen auch die Logik<br />
und der Datenfluss zwischen den einzelnen Ebenen klar war. Basierend auf diesen<br />
Erkenntnissen waren die benötigten Schnittstellen zu den Datenquellen definierbar.<br />
Diese dienten anschliessend als Programmiervorlagen für die Implementierung.<br />
Eine Einschränkung gab es allerdings für dieses Vorgehen. Dadurch, dass nicht wie<br />
üblich in den ersten Phasen des Projekts Konzepte geschrieben wurden, die alle ge-
Fallstudien zur Methodenentwicklung 129<br />
genwärtigen und zukünftigen Anforderungen enthalten und direkt mit der Implementierung<br />
begonnen wurde, konnte seitens der IT nur 80% der Lösung erbracht werden.<br />
Diese konnten aber die meisten der gegenwärtigen und zukünftigen Anforderungen<br />
abdecken, jedoch ohne Garantie, dass diese vollständig waren. Die Alternative wäre<br />
das ITPM-Vorgehen gewesen, welches alles abdeckte, jedoch nicht in der vorgegebenen<br />
Zeit durchführbar gewesen wäre. Konfrontiert mit dieser Einschränkung war für<br />
die Fachvertretenden klar, erstere zu bevorzugen. Das Projekt wurde ein voller Erfolg<br />
und ein erster Meilenstein in Richtung Agilität bei der BMW Group war gesetzt.<br />
Gleichzeitig konnte durch diese iterative und sehr eng mit dem Kunden verbundene<br />
Arbeitsweise in Form regelmässiger Workshops eine Nähe geschaffen werden, die<br />
Vertrauen schaffte und sich positiv auf das Verhältnis zwischen IT und Business auswirkte.<br />
Durch dieses Projekt, welches zwar in seiner Struktur und Umgebung nicht sehr komplex<br />
war, konnte somit ein erstes Mal ein Vorläufer der heutigen Methode prototypisch<br />
umgesetzt werden.<br />
Ein weiteres Projekt, welches dazu führte, dass sich die BMW Group weiter in Richtung<br />
Agilität entwickelt hat, war die Entwicklung eines Management-Cockpits für den<br />
Bereich Karosserie und Karosseriefertigung. Bis anhin waren ein Referent und zwei<br />
Assistierende alle 14 Tage damit beschäftigt, eine grosse Menge Powerpoint-Folien<br />
mit den neusten Kennzahlen zu aktualisieren. Das Vorgehen war, in einem ersten<br />
Schritt sämtliche von diesen drei Personen aktualisierten Powerpoint-Folien in einem<br />
Raum aufzuhängen. Damit konnte einerseits die Menge der Kennzahlen und andererseits<br />
der damit verbundene Aufwand für die Aktualisierung visualisiert werden. In einem<br />
zweiten Schritt wurde der Inhalt dieser Folien in einem Workshop mit diesen drei<br />
Personen in einer Cockpit-Logik abgebildet. Daraus konnte anschliessend in einfachem<br />
HTML ein erster Prototyp gebaut werden, welcher als Gesprächsgrundlage für<br />
die Verfeinerung der Anforderungen an ein Cockpit diente. Das Resultat wurde in<br />
pragmatischer Form, im Sinne eines Protokolls des Workshops, dokumentiert und der<br />
abgeleitete und verfeinerte Prototyp in die Produktivumgebung implementiert. Mit<br />
diesen Ergebnissen wurden die entsprechenden Führungskräfte, die bis anhin die<br />
Powerpoint-Folien konsumiert hatten, konfrontiert um sicher zu stellen, dass die relevanten<br />
Kennzahlen und Informationen mit aufgenommen wurden.<br />
Die Reaktionen auf das gewählte Vorgehen waren sehr positiv. Gleichzeitig war ein<br />
weiteres Ziel des Projekts, herauszufinden, wie grundsätzlich eine Benutzerschnittstelle<br />
bei der BMW Group aufgebaut werden sollte. Die Erfahrung hat gezeigt, dass über
130 Fallstudien zur Methodenentwicklung<br />
solche Workshops sehr genau ermittelt werden kann, was der Bedarf ist. Dies kann<br />
nicht durch die IT geleistet werden, da es eine Grundvoraussetzung ist, dass nicht nur<br />
Kenntnis der operativen Prozesse vorhanden ist, sondern dass diese auch gelebt werden<br />
müssen.<br />
Aufgrund des Erfolgs der beiden Projekte war die Unterstützung durch die Fachabteilungen<br />
gross. So wurde zusammen mit der Abteilung, die für die methodische Unterstützung<br />
des Unternehmens verantwortlich ist, eine neue agile Vorgehensweise entwickelt,<br />
die sich in das bestehende Framework um das ITPM integrieren lässt. Ziel des<br />
neuen, agilen Vorgehens war es, dass Projekte in kleineren Schritten abgewickelt werden<br />
können, bzw. kleine Iterationszyklen verwendet werden, mit Visualisierung gearbeitet<br />
wird, dass sich ändernde Anforderungen adäquat berücksichtigen lassen und<br />
dass nur die notwendigen Aspekte vorab beschrieben werden und nicht das detaillierte<br />
Fachkonzept, wie es ITPM vorsieht.<br />
Dadurch, dass Führungskräfte aus dem Fachbereich tendenziell über wenig freie zeitliche<br />
Ressourcen verfügen, werden sich diese nicht mit Aufgaben auseinandersetzen,<br />
die durch eine auf Projektdurchführung spezialisierte Abteilung wie die IT übernommen<br />
werden können. Somit muss die methodische Unterstützung zur Aufnahme von<br />
Anforderungen so gestaltet werden, dass der Prozess einfach zu verstehen ist und Führungskräfte<br />
in einfacher Art Bedürfnisse platzieren können. Entsprechende Visualisierungsmöglichkeiten<br />
wie bspw. einfache Prototypen oder Mockups zeigen die Möglichkeiten<br />
und Grenzen. Fachvertretende können darauf basierend einfacher ihre Anforderungen<br />
ausdrücken als mit abstrakten Methoden. Auch dieser Aspekt musste<br />
durch die neue Methode abgedeckt werden.<br />
5.3.2.2 Herausforderungen der Veränderung und Lösungsansätze<br />
Aufgrund der Ausgangslage ergibt sich eine Vielzahl von spezifischen Herausforderungen<br />
und Anforderungen an eine neue Methode, die adäquat berücksichtigt werden<br />
müssen:<br />
Vorgehen in kleinen Schritten: Beide beschriebenen initialen Projekte und die aus der<br />
Problemstellung hervorgehenden Probleme ergeben die Anforderung, dass die Methode<br />
in kleinen Schritten vorgeht. Die Herausforderungen dabei sind insbesondere die<br />
Akzeptanz der Vorgehensweise durch die Fachbereiche und die Vereinbarkeit mit der<br />
bestehenden Governance-Struktur innerhalb des Unternehmens. Im vorliegenden Fall<br />
wurden beide Herausforderungen durch die beiden erfolgreichen initialen Projekte gelöst.<br />
Dabei wurde gezeigt, dass die Ergebnisse der Projekte eine Verbesserung der ge-
Fallstudien zur Methodenentwicklung 131<br />
genwärtigen Vorgehensweise hinsichtlich Qualität und Zeit bedeuten. Die engere Zusammenarbeit<br />
der IT mit den Fachbereichen ermöglichte eine höhere Effizienz und<br />
Effektivität bezüglich der Projektanforderungen.<br />
Anforderungsformulierung: Wie beschrieben sind die Fachvertretenden nicht in der<br />
Lage, die Anforderungen an ein Projekt adäquat zu beschreiben. Dies hat zwei Gründe,<br />
einerseits die fehlende Fähigkeit, die Anforderungen so abstrahiert zu beschreiben,<br />
dass die Entwicklung diese entsprechend umsetzen kann und andererseits deren Volatilität,<br />
die dazu führt, dass die Anforderungen entweder im Vorfeld noch nicht bekannt<br />
sind oder sich im Laufe des Projekts sehr stark verändern. Gleichzeitig sehen sich heute<br />
Führungskräfte mit einer Informationsflut konfrontiert, die nur durch strukturierende<br />
Werkzeuge beherrschbar gemacht werden können. Es braucht also entscheidungsorientierte<br />
Lösungen, die diese Informationsflut auf die wesentlichen und relevanten Informationen<br />
reduzieren. Die Lösung für die genannten Herausforderungen und Anforderungen<br />
liegt darin, dass sehr früh im Projekt Prototypen erstellt werden. Diese dienen<br />
den Fachanwendenden als eine Art „Knetmasse“. Sie sehen eine erste Vorstellung<br />
der IT, wie die Lösung aussehen könnte. Mithilfe dieser Prototypen wird es einfacher<br />
für die Fachbereiche, ihre Vorstellungen und Anforderungen zu formulieren. Eine iterative<br />
Annährung an die finale Lösung mittels Einsatz immer weiterentwickelter Prototypen<br />
unterstützt die Zusammenarbeit zwischen Fachbereich und IT.<br />
Never Ending Stories: Aufgrund der Tatsache, dass während des Projekts immer wieder<br />
Anforderungen angepasst, umpriorisiert, erweitert oder gestrichen werden können,<br />
kann der Eindruck entstehen, dass für die Fachanwendenden in jeder Iteration neue<br />
Bedürfnisse und damit Anforderungen entstehen. So besteht die Gefahr, dass das Projekt<br />
nie zu einem Abschluss kommt und sich zu einer Never Ending Story entwickelt.<br />
Die Erfahrung der BMW Group hat jedoch gezeigt, dass bei einer abschliessenden<br />
Vorabspezifikation der Anforderungen viele Funktionalitäten implementiert werden,<br />
die von den Fachabteilungen nicht benötigt werden. Es werden alle möglichen Anwendungsfälle<br />
abgedeckt, die jedoch nicht zwingend gebraucht werden. Durch das<br />
iterative Anforderungsmanagement werden so im Endeffekt eher weniger Funktionalitäten<br />
implementiert als bei der klassischen Vorgehensweise.<br />
80/20-Ansatz: Eng verbunden mit der Anforderungsspezifikation und der Gefahr von<br />
Never Ending Stories ist der 80/20-Ansatz. Dieser wird von der BMW Group als elementar<br />
angesehen. Dabei geht es darum, dass bislang die vorab entwickelten Konzepte<br />
oftmals überladen wurden, da 100% aller möglichen gegenwärtigen und zukünftigen<br />
Anforderungen abgedeckt werden wollten. Dabei wurde vor allem auf die Funktion
132 Fallstudien zur Methodenentwicklung<br />
fokussiert und der zeitliche Aspekt war etwas in den Hintergrund gerückt. Typischerweise<br />
kann aber durch 80% der Ergebnisse in sehr viel kürzerer Zeit den Fachabteilungen<br />
schon sehr viel Nutzen gestiftet werden. In einem zweiten Schritt, bzw. in den<br />
weiteren Iterationen kann anschliessend der Ausbau und weitere wichtige Anforderungen,<br />
die sich ergeben, angegangen werden. Eine neue Methode muss demnach diesen<br />
80/20-Ansatz unterstützen.<br />
Dokumentation: Im Rahmen des klassischen Wasserfall-Ansatzes werden mächtige,<br />
detaillierte und weitreichende Dokumente produziert. Diese umfassen bei der BMW<br />
Group oft mehr als 500 Seiten und aufgrund der Grösse lesen diese nur wenige Beteiligte.<br />
In diesem Zusammenhang muss die Frage gestellt werden, wofür ein Projekt<br />
durchgeführt wird und welchen Nutzen der Kunde von einer solchen Konzeption hat.<br />
Aus diesem Grund wird bei der BMW Group versucht, nur das Notwendige zu dokumentieren<br />
und Ergebnisse und Protokolle aus Workshops als Dokumentation und<br />
Konzeption zu verwenden.<br />
Internationalisierung: Zunehmend werden Projekte noch internationaler und insbesondere<br />
in einem globalen Unternehmen, wie die BMW Group, nehmen solche Projekte<br />
einen immer wichtigeren Stellenwert ein. Neben geographischen Herausforderungen<br />
sehen sich die Projektbeteiligten auch mit kulturellen und sprachlichen Herausforderungen<br />
konfrontiert. Die internationalen Projektpartner verwenden andere Fachbegriffe,<br />
haben andere Begriffsverständnisse oder setzen verschiedene Schwerpunkte in den<br />
Projekten. Das macht die konzeptionelle Kommunikation schwierig. Diesem Unterschied<br />
im Level of Language lässt sich durch die Verwendung von Mockups und Prototypen<br />
begegnen. Dadurch sehen alle Beteiligten, wie das Endergebnis aussehen<br />
könnte und man kann sich iterativ an die Lösung herantasten. Basierend auf einem<br />
ausdefinierten Prototypen sind die Anforderungen in der Datenstruktur klar und im<br />
Sinne eines Reverse Engineerings kann das Backend nachentwickelt werden.<br />
Eine Möglichkeit, den genannten Herausforderungen und Anforderungen zu begegnen,<br />
ist der Einsatz agiler Methoden für die Projektabwicklung 436 .<br />
Im betrachteten Fall wurde von der BMW Group Scrum als agile Methode adaptiert.<br />
Diese bietet einen agilen Rahmen für das Abwickeln von Projekten ohne sich dabei in<br />
Details zu verlieren. In der Praxis hat sich Scrum als Methode für das agile Management<br />
von Projekten etabliert 437 .<br />
436 Für Grundlagen und Charakteristika agiler Methode vgl. Abschnitt 2.4.<br />
437 Vgl. Hughes 2008.
Fallstudien zur Methodenentwicklung 133<br />
Zusammenfassend charakterisiert die BMW Group die für sie wichtigsten Aspekte für<br />
eine agile Vorgehensweise in ihrem Unternehmenskontext wie in Tabelle 16 dargestellt.<br />
Dabei wird zwischen den Bereichen „Team“, „Sprint“, „Anforderungsmanagement“,<br />
„Projektsteuerung“, „Qualität“ und „Dokumentation“ unterschieden.<br />
Team<br />
Sprint<br />
Anforderungsmanagement<br />
Projektsteuerung<br />
Qualität<br />
Dokumentation<br />
Selbstorganisation, Einbindung des Kunden/Fachbereichs, definierte Rollen<br />
Termintreue, Timeboxing, Retrospektive, Lernen, Releaseplanung<br />
Permanente Änderungen, Product Backlog, Sprint Backlog, Wertschöpfung, User Stories,<br />
Priorisierung<br />
Planung, Aufwandschätzung, Entwicklungsgeschwindigkeit, Story Points, Backlogs, Burn<br />
Down Charts<br />
Motivation, Wertschöpfung, Reviews, Retrospektive, Refactoring, Continous Integration,<br />
Testautomatisierung<br />
Direktes Gespräch, Entscheidungslog, Architektur, Designentscheidung, Wartung<br />
Tabelle 16: Hauptaspekte der agilen Vorgehensweise bei der BMW Group<br />
5.3.3 Details zur neuen Vorgehensweise<br />
Im Folgenden wird das Vorgehen im betrachteten Fall detaillierter beschrieben. Dabei<br />
wird insbesondere auf den Projektablauf, Ergebnisse und die beteiligten Rollen eingegangen.<br />
5.3.3.1 Projektvorgehen und Ergebnisse<br />
Das Projektvorgehen im vorliegenden Fall ist stark geprägt durch die Agilität. Sowohl<br />
für die Entwicklung des Frontends, als auch für das Backend wird ein agiler Ansatz<br />
verwendet. Dabei wird die gleiche Vorgehensweise verwendet. Obwohl in der Wissenschafts-<br />
und Praxisliteratur vor einer agilen Vorgehensweise im Backend-Bereich gewarnt<br />
wird 438 , hat die Erfahrung bei der BMW Group gezeigt, dass eine solche Vorgehensweise<br />
auch für Anpassungen und Entwicklungen von Datenstrukturen sinnvoll ist.<br />
Als Basis für die neue Vorgehensweise wurden vier Ziele definiert, die von Seiten der<br />
BMW Group als elementar eingestuft wurden:<br />
Kundenzufriedenheit und Wertschöpfung: Die neue Methode soll nicht wertschöpfende<br />
bzw. nicht genutzte Funktionalitäten vermeiden. Dies soll durch eine enge Einbeziehung<br />
des Kunden während der gesamten Projektlaufzeit sichergestellt werden. Gleichzeitig<br />
sollen Anforderungsänderungen und neue Anforderungen im Laufe des Projekts<br />
bewusst eingeplant werden.<br />
Schnelligkeit, hohe Produktivität und früher Nutzen für den Fachbereich: Die neue<br />
Methode soll eine schnelle Reaktion auf sich ändernde Rahmenbedingungen zulassen.<br />
438 Vgl. bspw. Moss 2009.
134 Fallstudien zur Methodenentwicklung<br />
Dabei sollen leichtgewichtige Prozesse etabliert werden, die alle Tätigkeiten vermeiden,<br />
die nicht direkt zur Wertsteigerung des Produkts beitragen. Ausserdem soll mit<br />
der agilen Vorgehensweise eine Produktivsetzung von Teillieferungen vor Projektende<br />
ermöglicht werden.<br />
Qualität: Trotz der Berücksichtigung sich ändernder Anforderungen soll eine hohe<br />
Qualität forciert werden. Dies wird durch automatisierte Testverfahren und kontinuierliche<br />
Integration von Ergebnissen in das Gesamtprodukt sichergestellt. Durch häufiges<br />
Feedback von Kundenseite und regelmässige Retrospektive durch das Projektteam soll<br />
eine ständige Verbesserung erreicht werden.<br />
Termintreue: Als Basis für „Timeboxing“, d.h. fix definierte Entwicklungszeiträume,<br />
wird eine sinnvolle Priorisierung von Anforderungen in enger Zusammenarbeit mit<br />
dem Fachbereich angestrebt. Dabei soll durch die Verlagerung kritischer und hoch<br />
priorisierter Projektteile in frühe Iterationsphasen das Risiko eines Überschreitens des<br />
Lieferzeitpunkts für das ganze Projekt sichergestellt werden.<br />
Aufgrund dieser Ziele und Voraussetzungen wurde basierend auf der ITPM-Methode<br />
eine agile Vorgehensweise entwickelt. Dabei wurde Scrum adaptiert und auf den Kontext<br />
der BMW Group angepasst. Das Vorgehen definiert vier Phasen, wobei die eigentliche<br />
Entwicklungsphase jeweils mehrfach durchlaufen wird. Abbildung 32 zeigt<br />
das Vorgehen schematisch.<br />
Abbildung 32: Agile Vorgehensweise bei der BMW Group<br />
Phase 0 – Project Setup:<br />
Diese Phase dient der Initialisierung des Projekts. Sie dient der Voraussetzung für die<br />
anschliessende Explorationsphase. Es wird in einem ersten Schritt entschieden, welche<br />
der beiden vorgegebenen Methoden, die durch die BMW Group angeboten werden,<br />
verwendet werden soll. Als Entscheidungskriterien dient ein Katalog mit Charakteristika<br />
des Projekts. Anschliessend wird, falls die agile Methode gewählt wird – und diese<br />
liegt im Fokus der vorliegenden Betrachtungen – eine erste grobe Skizze der Anforderungen<br />
basierend auf User Stories gemacht. Zusätzlich werden die Rollen für das
Fallstudien zur Methodenentwicklung 135<br />
Projekt aufgrund der Methode definiert 439 und das Zusammenarbeitsmodell vereinbart.<br />
Im Rahmen des Projekt Setups werden ausserdem die Schnittstellenpartner auf fachlicher<br />
und technischer Seite definiert und eine erste grobe Planung der Releases und die<br />
dafür notwendigen Sprints durchgeführt.<br />
Am Ende der Phase 0 steht als Ergebnis der Projektauftrag. Dieser beinhaltet den Projekthintergrund<br />
mit den Gründen für das Projekt, der Historie, sowie Stärken und<br />
Schwächen für das Projekt. Die Ziele des Projekts und die initiale Anforderungserfassung<br />
mit User Stories und einem Product Backlog sind weitere Bestandteile des Projektauftrags.<br />
Es werden Abgrenzungen gemacht, wie bspw. Umfänge fachlicher und<br />
technischer Natur eingeschränkt. Die Schnittstellen werden geklärt, sowohl auf technischer<br />
wie auch auf fachlicher Seite und neben der Begründung der Auswahl des Vorgehensmodells,<br />
Rahmenbedingungen und Voraussetzungen für das Projekt geklärt.<br />
Falls das Projekt Schutzbedarf hat oder spezielle Risiken berücksichtigt werden müssen,<br />
werden diese auch im Projektauftrag definiert. Falls bereits bekannt, werden Lösungsalternativen<br />
definiert, im Rahmen der agilen Methode sind diese jedoch eher zu<br />
vernachlässigen, da die Vorgehensweise von der Anpassung der Lösungsalternativen<br />
während des Projekts lebt. Natürlich muss eine Wirtschaftlichkeitsrechnung erstellt<br />
werden, die eine grobe Kosten/Nutzen-Abschätzung beinhaltet. Abschliessend wird<br />
die Projektorganisation mit den beteiligten externen und internen Partnern definiert<br />
und für die Explorationsphase ein <strong>Projektmanagement</strong> und eine Planung definiert. Hier<br />
wird auch schon eine erste grobe Release- und Sprintplanung erstellt. Grundsätzlich<br />
sind die Projektteams frei in der Definition der Sprintlängen. Diese variieren zwischen<br />
2 Wochen und 2 Monaten. In den meisten Fällen werden verschiedene Sprints (Frontend<br />
und Backend) durch verschiedene Teams parallel durchgeführt.<br />
Jede Phase in der Methode wird durch einen Gateway abgeschlossen. Gemäss offizieller<br />
Methode muss hier der Projektauftrag abgenommen und freigegeben werden. In der<br />
Praxis werden bei der BMW Group diese Gateways nicht so streng durchgeführt.<br />
Vielmehr wird durch Ergebnisse und Protokolle aus Workshops die Abnahme sichergestellt.<br />
Phase 1 – Exploration Phase:<br />
Die Explorationsphase dient der „Erkundung“ des Projektumfelds in fachlicher und<br />
technischer Hinsicht. Dabei wird die angestrebte Lösung in einer ersten Form skizziert<br />
um sicherzustellen, dass sich die gesetzten Ziele realistisch erreichen lassen. Dafür<br />
439 Vgl. hierzu Abschnitt 5.3.3.2.
136 Fallstudien zur Methodenentwicklung<br />
wird die Basisarchitektur und Infrastruktur festgelegt, sowie geprüft ob bereits sinnvoll<br />
verwendbare Musterlösungen vorhanden sind. Bereits in dieser Phase wird der spätere<br />
IT-Betrieb eingebunden und geplant.<br />
Es werden in dieser Phase Aktivitäten durchgeführt und Ergebnisse erstellt, die grundlegende<br />
Bedeutung für das Projekt haben. Dazu gehört eine Ist-Analyse der Geschäftsprozesse,<br />
der Aufbauorganisation, der Schnittstellen, der Altsysteme, des Grobdatenmodells<br />
und des Schutzbedarfs, das fachliche Sollkonzept für die Architektur mit den<br />
Geschäftsprozessen, Schnittstellen, dem Funktionsmodell und dem Benutzermodell<br />
und eine weitere Erfassung der Anforderungen mittels User Stories. Die technische<br />
Architektur mit entsprechenden, architekturrelevanten Anforderungen bzw. Randbedingungen,<br />
einem Datenmodell/-entwurf und einem Entwurf für die Modularisierung<br />
wird erstellt und wichtige Design Entscheidungen getroffen. Darüber hinaus werden<br />
übergreifende Konzepte und Anforderungen wie das Sicherheitskonzept, die Planung<br />
der Dokumentation und ein Einführungs-, Migrations- und Notfallplan erstellt und<br />
wenn möglich ein erster Prototyp gebaut. Die Projektplanung und das Management<br />
aus Phase 0 werden fortgeschrieben und an die neuen Erkenntnisse angepasst.<br />
Auch hier ist für den Übergang in die Phase X wieder ein Gateway vorgesehen. Wie<br />
bereits in der vorhergehenden Phase wird dieses in der Praxis nicht in der Form bedient,<br />
wie es von der Methode her vorgesehen ist.<br />
Phase X – Sprint Phases:<br />
Die Sprintphasen dienen dazu, die Realisierung des Projektergebnisses in kleine, beherrschbare<br />
Teile und Entwicklungssprints aufzuteilen. Diese Phasen sind der eigentliche<br />
Kern des Projekts. Dabei werden eine oder mehrere User Stories komplett entwickelt,<br />
getestet und in das Gesamtsystem integriert. In einem ersten Schritt (Sprintplanung)<br />
werden aus dem Product Backlog die Anforderungen priorisiert und deren Aufwand<br />
geschätzt. Hieraus wird das Sprint Backlog erstellt, also die Anforderungen für<br />
den aktuellen Sprint ausspezifiziert und geplant. Anschliessend werden diese Anforderungen<br />
inkrementell und iterativ umgesetzt und am Schluss getestet, so dass das Ergebnis<br />
des Sprints ein qualitätsgesicherter Teil des Gesamtergebnisses darstellt.<br />
Die Aktivitäten in dieser Phase sind in die sechs Bereiche „Sprintplanung“, „Softwareerstellung“,<br />
„Softwarehärtung“, „sprintübergreifende Ergebnisse/Dokumentation“,<br />
„<strong>Projektmanagement</strong>/-planung“ und „Test Gateway“ bzw. Integrationstest eingeteilt.<br />
Die Sprintplanung besteht aus methodischer Sicht aus den User Stories für den Sprint<br />
und damit aus den entsprechend priorisierten Anforderungen aus dem Product Back-
Fallstudien zur Methodenentwicklung 137<br />
log, die im Sprint Backlog festgehalten werden. Für die priorisierten User Stories wird<br />
anschliessend eine Aufwandschätzung gemacht. Als Methode wird hierfür das Planning<br />
Poker verwendet 440 . Die jeweilig geschätzten User Stories werden anschliessend<br />
mit der Sprintlänge und der entsprechenden Teamkapazität verglichen und die User<br />
Stories, die im nächsten Sprint abgearbeitet werden, definiert. Grundsätzlich ist es<br />
möglich bzw. üblich, dass verschiedene Entwicklungsteams parallel verschiedene<br />
Sprints durchführen (bspw. im Frontendbereich und im Backendbereich).<br />
Bezüglich des Requirement Engineering gibt es zwei Möglichkeiten, wie dieses in das<br />
Projekt mit einbezogen werden kann. Zum einen kann, wie durch die Methode vorgesehen,<br />
in der Explorationsphase ein initiales Product Backlog erstellt werden, der<br />
durch die Sprints abgearbeitet wird und in den Integrationstests, Reviews und Retrospektiven<br />
ergänzt, verändert oder verkleinert wird. Die zweite Möglichkeit, die im<br />
Einkauf der BMW Group vorherrschend ist, ist die Integration des Requirements Engineerings<br />
in die Sprints, d.h. im Rahmen von Workshops mit den Fachabteilungen,<br />
die innerhalb der Sprints durchgeführt werden. Dabei werden die User Stories aufgenommen<br />
und in fachlicher Sprache dokumentiert.<br />
Die Softwareerstellung bildet den eigentlichen Kern des Sprints. In diesem Bereich<br />
werden Prototypen erstellt, Refactoring betrieben d.h. wo notwendig Architektur und<br />
Design angepasst, die Testspezifikationen definiert, kontinuierlich integriert, Module<br />
und Subsysteme systematisch abgearbeitet, Aspekte der Datenhaltung geklärt und ein<br />
Qualitäts-Check durchgeführt.<br />
Basierend auf den in der Sprintplanung definierten Aufgaben und aufgrund des Sprint<br />
Backlogs werden anschliessend die User Stories und die daraus abgeleiteten Anforderungen<br />
entwickelt. Aus der Erfahrung der BMW Group sind für die ersten Sprints 80%<br />
der Anforderungen bereits klar. Diese werden abgearbeitet und währenddessen und im<br />
Laufe der weiteren Sprints werden die restlichen 20% definiert. Es geht also bei dem<br />
agilen Ansatz nicht darum, Dinge wegzulassen sondern darum, Dinge pragmatischer<br />
zu betrachten, indem sie auf das Wesentliche reduziert werden und indem Sprints klein<br />
geschnitten und parallelisiert werden.<br />
Die Entwicklung im Backend-Bereich wird bei der BMW Group gleich gemacht wie<br />
auch im Frontend. Die klein geschnittenen Teile, die in einem Sprint entwickelt werden,<br />
sind eigentlich kleine Wasserfälle, die hintereinander durchgeführt werden. Aus<br />
diesem Grund kann durch die Modularisierung der Arbeitspakete in beiden Bereichen<br />
440 Vgl. Abschnitt 6.3.10.2.
138 Fallstudien zur Methodenentwicklung<br />
gleich vorgegangen werden. Die Erfahrung hat gezeigt, dass neben der Grösse dieser<br />
Entwicklungspakete, der Hauptunterschied in der eigentlichen Entwicklung bei agilen<br />
Vorgehensweisen, die Mächtigkeit und die Formalisierung der Methode ist. So gesehen<br />
muss beim klassischen Wasserfall-Ansatz durch die Projektleitung weniger Risiko<br />
eingegangen werden, da es diese fixen Gateways gibt, wo sich das Projektteam jeweils<br />
absichern kann. Wasserfall ist demnach administrativ korrekt aber es ist niemals innovativ<br />
forschend. Für die Entwicklung im Backend-Bereich ist es wichtig, dass einige<br />
Themen sauber beschrieben sind, um die Zusammenarbeit mit dem Frontend sicher zu<br />
stellen. Dazu gehören Schnittstellenverträge bei Datenlieferungen, Transformationslogiken,<br />
wenn notwendig die ETL-Schicht und die Datenhaltung bzw. die Cube-<br />
Struktur. Diese Beschreibung wird jedoch nie alles abdecken, so dass auf der Backend-<br />
Seite Entwickelnde notwendig sind, die über breites Wissen über die Architektur verfügen<br />
und die das zugrundeliegende Datenmodell sehr gut kennen.<br />
Unter der Auffassung, dass Software einen gewissen Lebenszyklus hat und nach einer<br />
bestimmten Zeit abgelöst wird, wird bei der BMW Group so entwickelt, dass nicht alle<br />
möglichen zukünftigen Anforderungen abgedeckt werden wollen. Vielmehr wird die<br />
Auffassung vertreten, dass bei einer grösseren Änderung, bspw. in der Datenstruktur,<br />
die bestehende Lösung neu gebaut wird. So können schneller Resultate geliefert werden,<br />
was nach der Erfahrung bei der BMW Group deutliche Kostenvorteile mit sich<br />
bringt. Aus diesem Grund ist die Entwicklung im Backend-Bereich mittels Sprints<br />
kein Widerspruch. Es existieren zwei Teams, eines für Frontend und eines für Backend.<br />
Für das Backend wird basierend auf dem Frontend Anforderungen definiert und<br />
ein Product Backlog erstellt, der entsprechend abgearbeitet wird. Der Synchronisationspunkt<br />
ist dann, wenn definiert wird, wann die Daten aus dem Backend ins Frontend<br />
gelangen.<br />
Die Softwarehärtung dient dem Abschluss der Softwareerstellung. Dabei wird innerhalb<br />
der Sprintteams eine Retrospektive gemacht und dabei der Entwicklungssprint<br />
selbstkritisch betrachtet. Daraus werden teamintern Verbessungsmassnahmen definiert,<br />
bspw. für die Organisation des Sprints oder die Kommunikation untereinander.<br />
Die Ergebnisse der Retrospektive fliessen als Learnings in die folgenden Sprints ein.<br />
Zur Härtung der Software gehört auch der Abschluss des Sprints, die Frozen Zone, wo<br />
keine neuen Aufgaben mehr abgearbeitet werden. Ab diesem Zeitpunkt ist der Sprint<br />
beendet und es werden nur noch Tests durchgeführt und keine neuen Funktionalitäten<br />
mehr implementiert. Den Abschluss der Softwarehärtung bilden automatisierte Tests<br />
des Produktinkrements und die Abnahme an sich.
Fallstudien zur Methodenentwicklung 139<br />
Der Bereich Sprintübergreifende Ergebnisse/Dokumentation deckt einerseits Themen<br />
ab, die sich durch die Teilung des Gesamtprojekts in viele kleine Stücke ergeben und<br />
andererseits die Dokumentation des Projekts. Im Rahmen agiler Vorgehensweisen<br />
wird versucht, schneller zu sein und somit nicht zwingend notwendige Schleifen zu<br />
eliminieren, d.h. es wird nur das dokumentiert, was für die Umsetzung gebraucht wird.<br />
Die Konzeptionsarbeit wird damit auf das Wesentliche reduziert.<br />
Zu diesem Bereich gehört die Umsetzung übergreifender Konzepte und Anforderungen,<br />
die Fortschreibung der Architektur, sofern notwendig, die Aktualisierung der U-<br />
ser Stories und des Product Backlogs, die Prozess-, Betriebs- und Benutzungsdokumentation,<br />
die Implementierung der Service Level Messung und die Erstellung der<br />
Trainingsunterlagen.<br />
Die letzten beiden Bereiche beinhalten die Fortschreibung des <strong>Projektmanagement</strong>s<br />
und der Projektplanung sowie einem Integrationstest als Vorbereitung für die anschliessende<br />
Abnahme des getesteten Systems vor dem Go-live, wenn es sich um den<br />
letzten Sprint gehandelt hat.<br />
Phase 5 – Install, Commission & Deploy System:<br />
Die letzte Phase ist der Einsatz der Lösung und der Übergang in den Betrieb, die Wartung<br />
und in die Prozesse. Sie wird immer dann durchlaufen, wenn die Gesamtlösung<br />
oder ein Teil davon (Releases) produktiv geschaltet wird. Somit kann diese Phase im<br />
Laufe des Projekts mehrfach durchgeführt werden. Das Projektteam bleibt hierbei so<br />
lange verantwortlich, bis ein geregelter Übergang in Betrieb und Wartung stattgefunden<br />
hat. Wenn weitere Releases nachfolgen, werden bisherige Ergebnisse überarbeitet<br />
und konsolidiert. Im Falle des Durchlaufs der Phase am Ende des Gesamtprojekts, also<br />
wenn die Gesamtlösung fertig entwickelt wird, schliesst diese Phase mit dem abgenommenen<br />
Projektabschlussbericht ab.<br />
Die Aktivitäten und Ergebnisse aus Phase 5 lassen sich in drei Bereiche unterteilen,<br />
der Produktivanlauf, der Übergang des Releases in die Linie und der Projektabschlussbericht.<br />
Zum Produktivanlauf gehören Aktivitäten und Ergebnisse wie die Installation und<br />
Übergabe des IT-Systems mit der entsprechenden IT-Infrastruktur, Anwendungssoftware<br />
und den technischen Ausrüstungen für die Geschäftsprozesse, die über die IT<br />
hinaus gehen, die Einstellung des Systems und die Integration in die Zielumgebung<br />
(bspw. Erstellung von Benutzern) und der Import, bzw. das manuelle Einfügen der<br />
Stammdaten, ein Probelauf, die Verifizierung der Service Level Parameter, die Ein-
140 Fallstudien zur Methodenentwicklung<br />
richtung der geänderten Organisation bezüglich Ablauf- und Aufbauorganisation,<br />
Schulungen der Benutzenden und der Administration und der Aktualisierung des <strong>Projektmanagement</strong>s<br />
(falls das Projekt weitere Releases beinhaltet). Der Produktivanlauf<br />
wird methodisch gesehen durch einen Gateway abgeschlossen, in der Praxis wird es<br />
jedoch so gehandhabt wie bei den vorherigen Gateways auch.<br />
Die Ergebnisse und Aktivtäten des Übergangs des Releases in die Linie beinhaltet die<br />
Stabilisierung des Systems, die Deaktivierung und Entsorgung des Altsystems, die<br />
Organisation der Wartung mit Rollen und Verantwortlichkeiten, dem Ablauf, des Ressourcenplans<br />
und den SLAs, den Betrieb mit der fertigen Betriebsdokumentation, die<br />
Klärung der Verantwortungen und den unterschriebenen SLAs, der Prozessübergabe<br />
an die Linie, sofern weitere Releases geplant sind, die weitere Releaseplanung und<br />
eine Zusammenstellung der zu wartenden Ergebnisse. Auch der Übergang in die Linie<br />
wird methodisch gesehen durch einen Gateway abgeschlossen, in der Praxis wird es<br />
jedoch so gehandhabt wie bei den vorherigen Gateways auch.<br />
Der Projektabschlussbericht als dritter Bereich beinhaltet eine Beschreibung des Projektverlaufs,<br />
ein Soll/Ist-Vergleich des Projektablaufs mit dem Projektauftrag bezüglich<br />
Zielerreichung, Leistungsumfang, Wirtschaftlichkeit, Terminabweichungen und<br />
verbleibende Risiken, eine Systembeurteilung und Lessons Learned.<br />
Die beschriebene Methode basierend auf Scrum hat sich bei der BMW Group etabliert,<br />
bzw. ist dabei, sich zu etablieren. Im Intranet der BMW Group ist diese Methode in<br />
einem Wiki dokumentiert. Gleichzeitig wird da auch ein Tool-Kit zu Verfügung gestellt,<br />
welches Templates etc. enthält. Die Methode ist anerkannter Standard im Unternehmen<br />
und vor Beginn eines Projekts kann entschieden werden, ob ein Wasserfall-<br />
Ansatz oder die agile Methode gewählt wird. Mittlerweile sind viele Projekte sehr<br />
Frontend-lastig und deshalb verbreitet sich der Einsatz der agilen Methode immer weiter.<br />
5.3.3.2 Beteiligte Rollen<br />
Durch die Adaption von Scrum ergeben sich klassisch die drei Rollen „Product Owner“,<br />
„Scrum Master“ und „Team“. Diese Aufteilung hat sich aber erfahrungsgemäss<br />
als zu wenig praxistauglich erwiesen. Aus diesem Grund wurden diese Rollen so angepasst,<br />
dass sie auf den Kontext der BMW Group passen. Die einzelnen Rollen, deren<br />
Funktionen und die Abweichung zum klassischen Scrum werden im Folgenden beschrieben:
Fallstudien zur Methodenentwicklung 141<br />
Product Owner: Diese Rolle ist durch den Fachbereich abgedeckt. Sie verantwortet die<br />
Funktionalität des Teil-, bzw. Endprodukts und ist insbesondere für das Anforderungsmanagement<br />
zuständig. Gleichzeitig vertritt der Product Owner die Auftraggeberseite<br />
des Projekts und sorgt für das gemeinsame Verständnis mit dem Auftraggeber.<br />
Zu den Aufgaben gehören insbesondere die Priorisierung der einzelnen User Stories<br />
im Product Backlog, die Festlegung der Funktionalitäten der einzelnen Sprints, d.h. die<br />
Priorisierung der Anforderungen für das Sprint Backlog und das Scope Management.<br />
Je nach Grösse des Projekts wird die Rolle durch Fachbereichsvertreter verschiedener<br />
Hierarchiestufen besetzt. In kleineren Projekten kann das Scope Management auch<br />
durch die Projektleitung wahrgenommen werden.<br />
Projektleitung: Die Rolle der Projektleitung ist in Scrum in der Form nicht vorgesehen.<br />
Dennoch wird diese bei der BMW Group eingesetzt. Dies hat verschiedene Gründe.<br />
Auf der einen Seite braucht es nach wie vor eine Ansprechperson seitens des Auftragnehmers<br />
und diese ist bei Scrum so nicht klar abgedeckt. Gleichzeitig ist die Projektleitung<br />
eine hybride Rolle. Sie hat insbesondere die Gesamtverantwortung für das<br />
Projekt und ist im Handwerk des <strong>Projektmanagement</strong>s ausgebildet. Von dieser klassischen,<br />
wasserfallorientierten Ausbildung kommend, braucht eine Projektleitung bei<br />
der BMW Group die Fähigkeit, die agile Vorgehensweise zu adaptieren und umzusetzen.<br />
Deshalb wird diese, je nach Projektorganisation, auch als agiler Coach/Scrum<br />
Master eingesetzt (siehe unten). Zu den Aufgaben der Projektleitung gehören unter<br />
anderem die Strukturierung von Anforderungen und das „Kleinschneiden“ ebendieser.<br />
Dafür wird ein hohes Abstraktionsvermögen vorausgesetzt. Die Projektleitung pflegt<br />
ausserdem Listen mit offenen Punkten, moderiert Meetings und erstellt und aktualisiert<br />
die Projektpläne.<br />
<strong>Agiles</strong> Team: Das agile Team wird unterteilt in interne Projektmitarbeitende und externe<br />
Dienstleister. Bei der BMW Group wird relativ wenig Programmierleistung intern<br />
erbracht. Deshalb sind diese Mitarbeitenden für die eigentliche Umsetzung verantwortlich.<br />
Das agile Team agiert eigenverantwortlich und muss deshalb über das<br />
entsprechende Know-how und die Kompetenzen verfügen. Zu den Aufgaben des agilen<br />
Teams gehört die Planung der Aufwände und Termine, das Erstellen der Projektergebnisse,<br />
das Durchführen der laufenden Qualitätssicherung, das Einsteuern von Änderungen,<br />
die Unterstützung bei der Priorisierung der Anforderungen und die Vorbereitung<br />
der fachlichen Abnahme durch das Definieren von Abnahmekriterien und Testfällen.<br />
Es verantwortet ausserdem die entsprechenden Tests. Im agilen Team sind verschiedene<br />
Subrollen integriert. Dazu gehören Fachbereichsverantwortliche, Chefarchi-
142 Fallstudien zur Methodenentwicklung<br />
tekten, Testverantwortliche, Projektmitarbeitende, Konfigurationsmanagende und Inbetriebnahmemanagende.<br />
Agiler Coach: Der agile Coach ist für die ordnungsgemässe Durchführung des Projektes<br />
und für die Implementierung der agilen Methoden verantwortlich. Er übernimmt<br />
die Rolle, die bei Scrum der Scrum Master innehat. Zu den Aufgaben des agilen Coaches<br />
gehört die Aufrechterhaltung der Transparenz während der gesamten Entwicklung<br />
des Projekts, das Erkennen von Verbesserungspotenzialen, die Sicherstellung der<br />
Entwicklungs- und Planungsprozesse, das Überwachen der Aufteilung der Rollen und<br />
Rechte sowie die Implementierung der agilen Methoden. Er sorgt ausserdem mit allen<br />
Mitteln für die Produktivität des Teams, indem er gute Arbeitsbedingungen schafft und<br />
die Arbeitszufriedenheit hoch hält. Wenn mehrere Scrum-Teams parallel an einem<br />
Projekt arbeiten, so wird ein „Scrum of Scrums“ als Skalierungsmodell gefahren. Dabei<br />
sendet jedes Team ein Mitglied in das „Scrum of Scrums Meeting“, um dort die<br />
Ergebnisse der Teams zu repräsentieren und übergreifende Themen zu klären.<br />
Im Einkauf, dem betrachteten Bereich der BMW Group, wird die Rolle des agilen<br />
Coachs allerdings nicht so gelebt. Für die Einführung und Entwicklung der agilen Methode<br />
wurde ein agiler Coach eingesetzt. Dieser hat die Scrum Trainings für die Beteiligten<br />
durchgeführt, die Methoden vorbereitet und Repräsentationsmaterial erstellt.<br />
Ziel dabei war es sicherzustellen, dass nach der Einführung der agilen Methode nicht<br />
in die alten Strukturen zurück verfallen wurde. In den laufenden Projekten, die jetzt<br />
nach der Etablierung der Methode durchgeführt werden, wird die Rolle des agilen<br />
Coaches, bzw. des Scrum Masters, der die ordnungsgemässe Durchführung der Methode<br />
sicherstellt, durch die Projektleitung übernommen. Damit kann eine schlankere<br />
Organisationsstruktur erreicht werden.<br />
QSP (Quality Sparring Partner): Rolle des QSP, also der Qualitätssicherer, der Dokumente<br />
prüft und die Qualität der Ergebnisse sicherstellt, gibt es im klassischen<br />
Scrum nicht und wird auch vom Einkauf der BMW Group nicht gelebt. Die relevanten<br />
Reviews und Gateways werden trotzdem gemacht, wenn bspw. das Projektergebnis an<br />
Betrieb und Wartung übergeben wird. Bei kritischen Projekten in der BMW Group<br />
wird von der Methode vorgeschrieben, dass ein QSP eingesetzt wird. Der agile Coach<br />
kann im Idealfall die Rolle des QSP einnehmen. Die Aufgabe des QSP sind insbesondere<br />
die Definition und Sicherstellung von Qualitätsmanagements-Massnahmen wie<br />
bspw. Abnahmen, Qualitäts-Checks, Testplanungen und Überprüfung der Dokumentation.
Fallstudien zur Methodenentwicklung 143<br />
Multiplikator: Die Rolle des Multiplikators ist in Scrum nicht vorgesehen. Er wird bei<br />
der BMW Group optional eingesetzt und dient der Absicherung der Kommunikation.<br />
Ein Multiplikator trägt die Ergebnisse als erweiterter Arm des Projektteams in die<br />
Fachbereiche und gibt Feedback aus den Fachbereichen zurück. Zu den Aufgaben des<br />
Multiplikators gehört die Sicherstellung der Kommunikation zwischen den Fachbereichen<br />
und dem Projektteam, das Feedback-Geben an das Projektteam, sowie regelmässige<br />
Erfahrungsberichte im Rahmen der Projektstatusberichte z.B. an den Lenkungsausschuss.<br />
Im betrachteten Bereich des Einkaufs wird diese Rolle nicht verwendet.<br />
5.3.4 Wesentliche Erkenntnisse und Herausforderungen<br />
Auf Basis der Analyse der vorliegenden Fallstudie lassen sich eine Reihe von Erkenntnissen<br />
und Herausforderungen ableiten.<br />
Erkenntnisse:<br />
Pragmatismus: Die eigentliche Kernerkenntnis ist, dass bei Entwicklungsprojekten nur<br />
ein hoher Grad an Pragmatismus zielführend sein kann. Im vorliegenden Fall ist dies<br />
in der Unternehmenskultur der BMW Group integriert, bzw. ein Hauptaspekt in der<br />
Automobilbranche. Ein Werk darf nie stehen bleiben und so sind alle Mitarbeitenden<br />
ständig gezwungen, zu improvisieren. Somit ist diese Branche per se pragmatisch. In<br />
diesem Fall ist es nicht möglich, dass die Zentrale, bzw. die darin verortete IT nach<br />
einem Vollständigkeitsansatz verfährt.<br />
Innovative Menschen: Eine wichtige Voraussetzung für den Erfolg agiler Vorgehen ist<br />
die menschliche Komponente. Einerseits müssen von Seiten der Fachbereiche Mitarbeitende<br />
involviert werden, die innovativ und offen für Neues sind. Dies war einer der<br />
Erfolgsfaktoren im Einkauf bei der BMW Group im Rahmen der Einführung der neuen<br />
Methode. Dabei wurden gezielt Mitarbeitende identifiziert und kontaktiert, die über<br />
ein entsprechendes Profil verfügten. Andererseits muss das Projektteam aus innovativen<br />
Mitgliedern bestehen. Dabei ist wichtig, dass diese motiviert sind, Dinge zu verändern<br />
und dafür auch sich und ihre eigene Arbeit zu überdenken. Grundsätzlich ist<br />
das Ziel wichtiger als die Methode und somit ist ein gemeinsames Ziel innerhalb des<br />
Projektteams relevant. Ob ein agiles Projektteam geformt werden kann, liegt zu grossen<br />
Teilen an der Projektleitung, da diese die Rahmenbedingung setzt und die Verantwortung<br />
trägt.<br />
Kleinteiligkeit: Kern der Methode ist das Schneiden des Projekts in kleine, voneinander<br />
möglichst unabhängige und abgeschlossene Teile, so dass diese in kurzer Zeit<br />
(Sprints) entwickelt werden können und regelmässig nutzenstiftend an die Fachabtei-
144 Fallstudien zur Methodenentwicklung<br />
lungen geliefert werden können. Wenn diese Kleinteiligkeit erreicht werden kann,<br />
kann in der Summe sehr viel günstiger entwickelt werden, da auf sich ändernde Anforderungen<br />
im Projekt eingegangen werden kann. In der Konsequenz werden dann<br />
jedoch wesentlich mehr Projekte bzw. Aktivitäten durchgeführt, d.h. es gibt viele<br />
Puzzlesteine, die abgearbeitet werden müssen. Die Aufgabe der Projektleitung ist dabei,<br />
diese Puzzlesteine zusammenzuhalten. Dies macht deren Arbeit aber auch interessanter,<br />
da sie sich mehr mit der fachlichen Seite des Projekts auseinandersetzen kann.<br />
Es ist ausserdem ein Steuerungssystem gegenüber den Projektleitungen. Wenn ein<br />
grosses Projekt geführt werden muss, dann kann sich diese eher zurückziehen, viele<br />
Dinge delegieren und sich auf das Steuern beschränken. So muss sie sich intensiver<br />
mit den Themen auseinandersetzen und ist damit näher am Projekt.<br />
Frühe Pilotierung: Auch im V-Modell, welches von der BMW Group eingesetzt wird,<br />
also einem klassischen Wasserfall-Ansatz gibt es Pilotierungen. Wenn diese aber an<br />
den Anfang des Projekts gestellt werden, auch wenn noch nicht 100% aller Anforderungen<br />
klar sind und der Prototyp nur als Gesprächsgrundlage dient, so kann sehr viel<br />
mehr Nähe zum Kunden erreicht werden.<br />
Pipelining der Sprints: Durch die Kleinteiligkeit und die Modularisierung des Projekts<br />
ist es möglich, die Sprints im Frontend- und Backendbereich unabhängig voneinander<br />
zu gestalten, d.h. die zu entwickelnden Module werden so geschnitten, dass nie gleichzeitig<br />
am gleichen Modul in beiden Bereichen gearbeitet wird. So kann sichergestellt<br />
werden, dass wenn im Frontend ein Modul fertiggestellt ist, die Anforderungen an das<br />
Backend weitergereicht werden und nicht im nächsten Sprint wieder dasselbe Modul<br />
bearbeitet wird, wobei sich die Anforderungen dann wieder ändern. Die Aufteilung<br />
des Projekts in einzelne Teile ist eine anspruchsvolle Aufgabe der Projektleitung und<br />
kritisch für den Erfolg des Projekts.<br />
Software-Lebenszyklus: Die Erfahrung der BMW Group hat gezeigt, dass es nicht zielführend<br />
ist, mit der Auffassung ein Projekt durchzuführen, dass Datenmodelle und<br />
Entwicklungen für die Ewigkeit gebaut sind. So gesehen müssen sich Projektbeteiligte<br />
von der Vorstellung lösen, dass alle gegenwärtigen und möglichst alle zukünftigen<br />
Anforderungen durch das Projekt abgedeckt werden müssen. Durch die Schnelllebigkeit,<br />
in der sich ein Unternehmen bewegt, lassen sich die zukünftigen Anforderungen<br />
nicht definieren und so ist die Wahrscheinlichkeit, dass nicht die richtigen Anforderungen<br />
umgesetzt werden, sehr gross. Entsprechend ist es wertvoller, wenn dem Kunden<br />
schnell eine Lösung geliefert werden kann, mit der er produktiv arbeiten kann, die<br />
jedoch vielleicht in ein paar Jahren komplett erneuert werden muss, als wenn alle
Fallstudien zur Methodenentwicklung 145<br />
Eventualitäten abgedeckt sind, die Lösung aber erst in bspw. zwei Jahren produktiv<br />
nutzbar wird.<br />
Tägliche Abstimmungsmeetings als Führungsinstrument: Die in Scrum vorgesehenen<br />
und bei der BMW Group durchgeführten täglichen Abstimmungsmeetings (Daily<br />
Scrums) haben zwei wichtige Funktionen. Einerseits dienen sie dazu, dass alle Projektmitglieder<br />
auf dem aktuellen Stand sind bezüglich des Projekts und der gerade abgeschlossenen<br />
und geplanten Arbeiten. Andererseits sind sie aber auch ein wichtiges<br />
Führungsinstrument. Die Erfahrung der BMW Group hiermit hat gezeigt, dass durch<br />
regelmässige Abstimmungsmeetings kein Projektmitglied unvorbereitet erscheint.<br />
Keiner will sich die Blösse geben, sagen zu müssen, dass gerade keine Aktivitäten in<br />
Arbeit bzw. abgeschlossen sind. So gesehen sind diese Daily Scrums ein positives<br />
Führungsinstrument.<br />
Schulung und Training: Die Aufteilung des Projekts in kleine, in sich abgeschlossene<br />
Teile hat den Vorteil, dass jeweils nach einem Sprint, wenn das Produktinkrement an<br />
den Fachbereich übergeben wird, dieser sich mit dem System auseinandersetzt. In der<br />
Konsequenz wird jedes Mal eine kleine Schulung durchgeführt, um die neuen Funktionalitäten<br />
zu demonstrieren. So gesehen werden mehr, dafür kürzere Schulungstermine<br />
pro Jahr angeboten, was einerseits besser konsumierbar ist für die Fachbereiche und<br />
andererseits wiederum mehr Nähe zwischen Business und IT schafft.<br />
Interaktion zwischen Fachbereich und IT: Durch die regelmässige und engere Zusammenarbeit<br />
zwischen Fachbereich und IT, sowie durch die regelmässige Lieferung produktiv<br />
einsetzbarer Projektergebnisse, verbessert sich die Wahrnehmung der IT gegenüber<br />
dem Business. Dies fördert die Zusammenarbeit.<br />
Transparenz: Einer der Haupterfolgsfaktoren in Projekten für <strong>analytische</strong> <strong>Informationssysteme</strong><br />
ist nach der Erfahrung der BMW Group die Nachvollziehbarkeit der Daten.<br />
Im betrachteten Bereich des Einkaufs wird ein grosses zentrales DWH als Single<br />
Point of Truth verwendet. Dieses besteht aus mehreren Millionen Datensätzen und<br />
charakterisiert sich durch Nachteile, wie eine tabellarische, unübersichtliche Darstellung<br />
mit vielen Details, sowie schlechte Performanz. Es werden alle einkaufsrelevanten<br />
Daten weltweit erfasst, was für die sporadische Nutzung zu komplex ist. Aus diesem<br />
Grund wurde eine aggregierte Ebene auf das DWH aufgesetzt, welche als Cockpits<br />
dargestellt wird. Diese sind multidimensional und können verschieden ausgewertet<br />
werden. Die Daten aus dem Kern-DWH werden dabei verdichtet und aggregiert. Dies<br />
führt zu weniger Komplexität und gleichzeitig können die Daten personalisiert dargestellt<br />
werden. Zwischen dem DWH und den Cockpits wird eine weitere Datenbank
146 Fallstudien zur Methodenentwicklung<br />
zwischengeschaltet, um die Performanz sicherzustellen. Dabei haben die dargestellten<br />
Daten immer eine Referenz auf das Kern-DWH, um bei Unklarheiten direkt nachvollziehen<br />
zu können, woher die Daten kommen. Um diese Transparenz zu erreichen wird<br />
möglichst wenig Transformation der Daten durchgeführt, d.h. es werden bei der Aggregation<br />
nur Summen gebildet und keine weiteren Operationen. So kann die Durchgängigkeit<br />
der Daten sichergestellt und damit diese Transparenz erreicht werden.<br />
Zentrale Herausforderungen:<br />
Ablehnende Haltung gegenüber Agilität: Zu Beginn der Initiative für eine neue agile<br />
Methode für die Abwicklung von Projekten war Skepsis insbesondere bei den Fachbereichen<br />
zu spüren. Dieser Herausforderung konnte durch frühe, schnelle und qualitativ<br />
hochwertige Projektergebnisse entgegengewirkt werden. Die anfängliche Skepsis wich<br />
schnell der Überzeugung, dass es nur noch wenige Rahmenbedingungen für Projekte<br />
gibt, wo ein Wasserfall-Ansatz zielführend ist.<br />
Bestehende Strukturen: Eine der Herausforderungen bei der Einführung einer neuen<br />
Methode für die Abwicklung von Projekten ist deren Einbettung in bestehende Unternehmens-<br />
und Governance-Strukturen. Insbesondere im vorliegenden Fall einer agilen<br />
Methode können bestehende Abnahmeprozesse für zu erstellende Dokumente wie<br />
bspw. Konzepte oder Dokumentationen nicht mehr in der gewohnten Form durchgeführt<br />
werden. Wenn nach jeder Phase im Projekt ein formalisiertes Abnahme-Gate<br />
vorgesehen ist, passt dies nicht in die schnellen und informellen Entwicklungssprints<br />
der betrachteten agilen Methode. Im vorliegenden Fall sieht die BMW Group diese<br />
Abnahme-Gates vorwiegend als Absicherung für die Projektleitungen bezüglich deren<br />
Verantwortung oder als politische Stellhebel. Es handelt sich hierbei um vorwiegend<br />
administrative Themen und keine inhaltliche Diskussionen. Im vorliegenden Fall des<br />
Einkaufs konnte erreicht werden, dass diese Abnahmen in Form von Workshops mit<br />
den Fachanwendenden durchgeführt werden. Dabei werden sie nicht mehr Gateways<br />
genannt sondern Prozessworkshops. Die von der BMW Group eingesetzte Methode<br />
wurde dahingehend modifiziert, dass formelle Abnahmen nicht mehr notwendig sind.<br />
Dieses Vorgehen hat sich mittlerweile etabliert und stösst auf breite Akzeptanz.<br />
Angst, Bestehendes zu verwerfen: Eine weitere Herausforderung ist, dass die Enwicklungsteams<br />
Angst davor haben, bestehende Software neu zu entwickeln und dabei das<br />
Alte zu verwerfen. Es wird traditionell so lange an einer Lösung entwickelt, bis diese<br />
alle möglichen gegenwärtigen und zukünftigen Fälle abdeckt. Die Erfahrung der<br />
BMW Group zeigt allerdings, dass es sehr viel günstiger ist, die heutigen Anforderungen<br />
nach einem 80/20-Ansatz zu entwickeln und dabei das Risiko einzugehen, dass die
Fallstudien zur Methodenentwicklung 147<br />
Lösung nach einer gewissen Zeit vollständig neu gebaut werden muss. Dabei ist<br />
durchaus realistisch, dass heutige Skalierbarkeiten morgen nicht mehr notwendig sind,<br />
da sich entweder keine neuen Anforderungen mehr ergeben oder aber diese sich so<br />
signifikant ändern, dass die bestehende Lösung neu gebaut werden muss. Es ist also<br />
wichtiger, heutige Anforderungen schnell und hochwertig umzusetzen damit die Fachbereiche<br />
schnell mit guten Lösungen arbeiten können, als dass zukünftige Anforderungen<br />
zu erfassen und zu implementieren versucht werden.<br />
Schneller Wechsel der Führungskräfte: Gleichzeitig und an obiger Herausforderung<br />
anknüpfend ist zu beobachten, dass Führungskräfte selten länger als 2-3 Jahre in einer<br />
Position sind. Vielmehr wird nach dieser Zeit eine neue Herausforderung angenommen,<br />
sei es in der gleichen Abteilung, in der gleichen Unternehmung oder an einem<br />
anderen Ort. Die Konsequenz für Entwicklungsprojekte ist, dass nicht über eine längere<br />
Zeit an einer Lösung gearbeitet werden kann. Vielmehr müssen schnell Ergebnisse<br />
geliefert werden, da es in einem längerfristigen Projekt durchaus vorkommen kann,<br />
dass während des Projekts oder kurz vor dessen Abschluss der Kunde nicht mehr diese<br />
Aufgabe innehat. So gesehen passt die agile Vorgehensweise sehr gut zur heutigen<br />
Schnelllebigkeit und je grösser ein Unternehmen ist, desto fragmentierter und instabiler<br />
ist ihre Struktur. Dies führt dazu, dass Projekte noch kleinteiliger durchgeführt<br />
werden müssen. Heutige IT-Architekturen geben diesen Spielraum und diese Flexibilität<br />
durch Toolbaukästen etc.<br />
Akzeptanzprobleme durch fehlende Transparenz: Damals, im Rahmen des ersten grossen<br />
Release des AIS im Einkauf, welches per Wasserfall entwickelt wurde, musste die<br />
Entwicklung lange mit Akzeptanzproblemen seitens der Fachbereiche kämpfen. Dies<br />
aufgrund dessen, dass gerade bei AIS-Projekten, die sich mit dem Messen und Aufbereiten<br />
von Zahlen beschäftigen, Transparenz einen grossen Stellenwert hat. Daraus<br />
ergibt sich natürlich die Möglichkeit für die einzelnen Mitarbeitenden gemessen zu<br />
werden. Durch die kleinen Schritte im Projekt bzw. durch die Kleinteiligkeit des Projekts<br />
und die kontinuierliche Schulung konnte für die Anwendenden Transparenz geschaffen<br />
und damit weniger Zweifel an den Zahlen gegeben werden.<br />
Wasserfall-Ansatz in grossen Infrastrukturprojekten: Die Erfahrung der BMW Group<br />
hat gezeigt, dass nicht immer eine agile Vorgehensweise zielführend ist. Vielmehr gibt<br />
es einzelne Projekttypen, für die es wichtig ist, eine Methode zu wählen, wo Stabilität<br />
vorherrscht und viel Erfahrung vorhanden ist. Insbesondere bei grossen Infrastrukturprojekten<br />
wie bspw. dem Ersetzen eines Märktesystems, der Einführung eines neuen<br />
Buchhaltungssystems oder einem grossen SAP-Projekt muss präzise gearbeitet werden
148 Fallstudien zur Methodenentwicklung<br />
und die Projektumgebung bzw. die Anforderungen sind entsprechend stabil. Hier bietet<br />
sich an, dass ein Wasserfall-Ansatz gewählt wird. Aus diesem Grund werden bei<br />
der BMW Group nach wie vor ein klassischer und der agile Ansatz für Projekte angeboten.<br />
Grundsätzlich kann festgehalten werden, dass bei benutzerintensiven oder anwendungsorientierten<br />
Projekten die agile Vorgehensweise vorzuziehen ist. Je stabiler<br />
das Umfeld ist, desto eher bietet sich der Wasserfall-Ansatz an. Hier ändern sich die<br />
Prozesse wenig und es wird nur etwas Altes durch etwas Neues ersetzt, bspw. ein neues<br />
Release einer Software. Allerdings sind in der heutigen Zeit nur noch sehr wenige<br />
Projekte so stabil. Es kann die These aufgestellt werden, dass wenn User-Stories vorhanden<br />
sind, ein agiler Ansatz gewählt werden sollte. Die Herausforderung liegt insbesondere<br />
darin, abschätzen zu können, wie stabil das Projektumfeld ist und zu entscheiden,<br />
wann ein agiler und wann ein klassischer Ansatz besser funktioniert.<br />
5.4 Fallstudie C: Steria Mummert Consulting AG<br />
Das betrachtete Projekt ist ein Grossprojekt, im Rahmen dessen ein komplettes DWH<br />
aufgebaut wird. Dabei wird dieses von Grund auf neu konzeptioniert und wenig auf<br />
der bestehenden <strong>analytische</strong>n IT-Landschaft aufgebaut. Es ist entsprechend hoch komplex<br />
und strategisch sehr bedeutend für das Kundenunternehmen einzustufen. Entsprechend<br />
hoch ist auch das Risiko. Das Projekt ist in der Telekommunikationsbranche<br />
anzusiedeln. Einer der grössten deutschen Telekommunikationsanbieter beauftragte<br />
die Steria Mummert Consulting AG (SMC) damit, dieses Projekt operativ und strategisch<br />
zu führen. Zum Zeitpunkt der Fallstudienaufnahme war das Projekt noch in einer<br />
späten Planungsphase. Mit der Erfahrung der beteiligten Projektleitungen konnten jedoch<br />
typische Stolpersteine in solchen Projekten bereits in der Planungsphase beseitigt<br />
werden. Der Interviewpartner und technische Projektleiter 441 auf Seiten SMC ist sowohl<br />
im Bereich DWH, als auch in der Telekommunikationsbranche sehr erfahren.<br />
5.4.1 Unternehmensprofil<br />
SMC ist eine der zehn grössten Anbieter für Management- und IT-Beratungen und<br />
bietet Business-Services, die unter Einsatz moderner Informationstechnologie Unternehmen<br />
wie Behörden ein effizienteres und profitableres Arbeiten ermöglichen. SMC<br />
ist Teil der Steria Gruppe und verbindet tiefgehende Kenntnisse der Geschäftsmodelle<br />
seiner Kunden mit umfassender internationaler Expertise in IT und Business Process<br />
Outsourcing. Als international tätiges Unternehmen betreut SMC eine Vielzahl von<br />
441 Für die Aufteilung der Rollen im Projekt und die detaillierte Beschreibung wird auf Abschnitt 5.4.3.2 verwiesen.
Fallstudien zur Methodenentwicklung 149<br />
Kunden im deutschsprachigen Raum. Tabelle 17 fasst die wichtigsten Kennzahlen und<br />
Unternehmensmerkmale zusammen.<br />
Unternehmensprofil Steria Mummert Consulting<br />
Gründung<br />
Firmensitz<br />
Branche<br />
Geschäftsfelder<br />
Organisationsstruktur<br />
1969, Gründung der Steria GmbH; 2005 Fusion von Mummert Consulting und Steria<br />
GmbH; ab 2008 unter dem Namen Steria Mummert Consulting AG im Markt.<br />
Hamburg (Deutschland)<br />
Management- und IT-Beratung<br />
Business Intelligence Lösungen, Enterprise Information Management, Human Capital<br />
Management, SAP Lösungen, IT-Management Lösungen, Software Lösungen<br />
Steria Mummert Consulting ist eine Tochterfirma der Steria Gruppe. Diese unterhält<br />
Standorte in 16 Ländern, in Europa, Asien, Indien und Afrika<br />
Umsatz Weltweit 1.693 Mia. EUR (Geschäftsjahr 2010)<br />
Operatives Ergebnis (EBIT) 70.9 Mio. EUR (Geschäftsjahr 2010)<br />
Mitarbeitende 18‘674 Weltweit, ca. 1‘700 in Deutschland (Geschäftsjahr 2010)<br />
Kunden<br />
Internetportal/Kontakt<br />
Steria Mummert Consulting berät Kunden in den Branchen Banking, Versicherungen,<br />
Utilities, Public Services, Telekommunikation, Transport und Health Care<br />
http://www.steria-mummert.de<br />
Tabelle 17: Unternehmensprofil Steria Mummert Consulting 442<br />
In der vorliegenden Fallstudie wird ein Projekt bei einem der grössten deutschen Telekommunikationsanbieter<br />
untersucht. Das Beratungsmandat der SMC beinhaltet die<br />
operative und strategische Projektleitung, sowie die operative Umsetzung des Projekts<br />
in Zusammenarbeit mit den betroffenen Fachbereichen des Kunden und der IT.<br />
5.4.2 Ausgangslage und Problemstellung im Unternehmen<br />
Folgende Abschnitte skizzieren die Ausgangslage im Unternehmen und die Auslöser,<br />
die zur Veränderung der Methode hin zu einer agilen Vorgehensweise geführt haben.<br />
Es wird ausserdem auf die Herausforderungen und deren Lösungsansätze eingegangen,<br />
die sich im Rahmen der Einführung agiler Methoden ergeben haben.<br />
5.4.2.1 Ursprüngliche Data Warehouse-Landschaft und Projektauslöser<br />
Die Ausgangslage im Kundenunternehmen ist so, dass dieses gegenwärtig mittels historischer<br />
Daten schwer zu steuern ist. Wichtige Kennzahlen, die für ein Telekommunikationsunternehmen<br />
für die Steuerung braucht, lassen sich aufgrund der Datenstruktur<br />
in der bestehenden Lösung nicht ableiten (bspw. „Earned Revenue per User“ als<br />
typische Kennzahl für die Branche). Gleichzeitig kann auf der Datenbasis nicht ermittelt<br />
werden, welche Kunden sich positiv bzw. negativ auf den Deckungsbeitrag des<br />
442 Vgl. Steria Group 2011a; Steria Group 2011b; Steria Group 2011c; Steria Mummert Consulting AG 2011.
150 Fallstudien zur Methodenentwicklung<br />
Unternehmens auswirken. Die Kostenstruktur des Unternehmens ist dementsprechend<br />
nicht transparent. Es besteht also ein gravierender Information Gap. In erster Linie<br />
resultiert diese Begebenheit aus der schlechten Datenstruktur und -basis. Der Grund<br />
dafür sind zwei historische Fehlschläge von Projekten, die zum Ziel hatten, ein DWH<br />
zu entwickeln. Die gegenwärtige Lösung ist daher eher als Interimslösung zu verstehen<br />
und verfügt nicht über die gewünschte Granularität und Qualität der Daten.<br />
Das betrachtete Projekt setzt demnach technologisch nicht auf der bestehenden DWH-<br />
Infrastruktur auf, da diese nicht mehr nutzbar ist. Es werden daher die bestehenden<br />
Quellsysteme als Basis genommen und darauf das DWH aufgebaut.<br />
Das Ziel des Projekts ist es somit, einerseits eine Datenbasis zu schaffen, auf der entsprechende<br />
Steuerungswerkzeuge aufgebaut werden könnten und andererseits die bedarfsgerechte<br />
Entwicklung der entsprechenden Werkzeuge im Unternehmen. Da das<br />
Hauptproblem die schlechte Steuerbarkeit des Unternehmens ist, ist die Management<br />
Attention für das Projekt entsprechend hoch.<br />
5.4.2.2 Herausforderungen im Projektaufbau und Lösungsansätze<br />
Aufgrund der genannten Ausgangslage ergibt sich eine Reihe von projektspezifischen<br />
Herausforderungen, die adäquat berücksichtigt werden müssen:<br />
Information Gap: Es besteht keine adäquate Datenbasis auf der das Projekt aufbauen<br />
kann. Der Information Gap besteht hierbei darin, dass die Informationen aus den<br />
Quellsystemen nicht bis in die Steuerungsebene des Unternehmens gelangen können.<br />
Entsprechend muss im Projekt von den Quellsystemen ausgegangen werden und alles<br />
bis hin zu <strong>analytische</strong>n Applikationen neu aufgebaut werden. Somit ergibt sich eine<br />
hohe Projektkomplexität, der es zu begegnen gilt. Dieser Komplexität kann mittels<br />
einer entsprechenden Modularisierung des Projekts entgegengewirkt werden. So wird<br />
das Projekt in handhabbare Stücke geschnitten.<br />
Hohe Management Attention: Aufgrund der Tragweite des Projekts nimmt dieses einen<br />
hohen Stellenwert im Unternehmen ein. Der entsprechenden Management Attention<br />
muss im Projekt Rechnung getragen werden, sei es durch regelmässige Statusberichte<br />
oder aber durch Quick-Wins, d.h. schnelle, verwendbare Ergebnisse.<br />
Verknüpfung aller Abteilungen: Im Rahmen des Projekts werden alle Quellsysteme an<br />
das neue DWH angebunden. Daraus ergibt sich die Herausforderung, dass sämtliche<br />
Abteilungen, seien sie datenliefernd oder spätere Nutzende der Daten, in das Projekt<br />
involviert sind. Hieraus ergibt sich ein grosser Abstimmungsbedarf und daraus eine<br />
entsprechende Projektkomplexität. Ein modular gestalteter Projektaufbau im Rahmen
Fallstudien zur Methodenentwicklung 151<br />
dessen jeweils eine begrenzte Anzahl Stakeholder involviert sind, kann dieser Komplexität<br />
entgegen wirken.<br />
Volatile Anforderungen: Unter anderem aufgrund der Tatsache, dass im Unternehmen<br />
bislang nur wenige <strong>analytische</strong> Applikationen auf schlechter Datenbasis im Einsatz<br />
waren, ist es für die Fachbereiche sehr schwierig, die Anforderungen vorab zu spezifizieren.<br />
Sie wissen nicht, welche Möglichkeiten es gibt und welche Daten zur Verfügung<br />
stehen. Die Anforderungen in Projekten für BI allgemein sind volatil. Wenn die<br />
Infrastruktur von Grund auf neu gebaut wird, wird diese Volatilität noch verstärkt. Es<br />
ist somit elementar, dass die Fachbereiche mit den Daten und Möglichkeiten <strong>analytische</strong>r<br />
Applikationen spielen können, um diese besser kennen zu lernen und so ihre Anforderungen<br />
an das System besser spezifizieren können. Somit bietet sich an, dass<br />
kleine Iterationszyklen gewählt werden und am Ende jeweils inkrementell verbesserte,<br />
lauffähige Ergebnisse entstehen. Diese können von den Fachbereichen benutzt werden<br />
um weitere Anforderungen zu spezifizieren oder diese zu detaillieren.<br />
Neben den Herausforderungen, die sich für das Kundenunternehmen im Projekt ergeben,<br />
sieht sich ein Beratungsunternehmen mit einer weiteren beratungsspezifischen<br />
Herausforderung konfrontiert.<br />
Wirtschaftlichkeit: Ein Beratungsunternehmen muss technisch hoch qualitative Projekte<br />
abwickeln. Daneben nimmt es aber auch die Rolle eines externen, gewinnorientierten<br />
Dienstleisters ein und muss sich entsprechend wirtschaftlich orientieren. Es muss<br />
also anders vorgegangen werden, wenn Gewinne maximiert werden müssen, als bei<br />
einer internen Abteilung, die in erster Linie die Kosten minimieren muss. Hierzu hat<br />
SMC eine Kalkulationsmethode für agile Projekte entwickelt, die im vorliegenden<br />
Projekt ausgetestet wird.<br />
Eine Möglichkeit, den genannten Herausforderungen zu begegnen ist der Einsatz agiler<br />
Methoden für die Projektabwicklung. Im betrachteten Projekt wurde von SMC und<br />
seinem Kundenunternehmen Scrum als agile Methode gewählt. Diese bietet einen agilen<br />
Rahmen für das Abwickeln von Projekten ohne sich dabei in Details zu verlieren.<br />
In der Praxis hat sich Scrum als Methode für das agile Management von Projekten<br />
etabliert 443 .<br />
SMC hat bis anhin vor allem traditionell mit dem V-Modell 444 entwickelt. Einzelne<br />
Projekte im AIS-Bereich, die nicht das Kern-DWH betreffen wurden jedoch schon mit<br />
443 Vgl. Hughes 2008.<br />
444 Vgl. IABG mbH 2011, bzw. Abschnitt 2.3.5.
152 Fallstudien zur Methodenentwicklung<br />
agilen Methoden abgewickelt. Erfahrungen mit grösseren Projekten und agilen Methoden<br />
bestehen jedoch noch nicht.<br />
Im betrachteten Kundenunternehmen aus der Telekommunikationsbranche unterhält<br />
SMC schon längere Zeit Beratungsmandate im AIS-Bereich. Dieses Unternehmen benutzte<br />
länger schon den Wasserfall-Ansatz für die Entwicklung im AIS-Bereich. Diese<br />
Methode wurde IT-seitig immer weiter formalisiert, jedoch bestand zunehmend das<br />
Problem, dass die Anwendenden ihre Anforderungen fachseitig nicht konzeptionell<br />
erfassen konnten und diese nicht detailliert spezifizieren konnten. Der Standardprozess<br />
des Unternehmens war nicht mehr in der Lage, diesen Herausforderungen zu begegnen.<br />
Mit Hilfe von SMC konnte eine Art extreme Prototyping versuchsweise eingeführt<br />
werden. Dies war noch keine agile Methode im engeren Sinne, enthielt aber<br />
Komponenten wie bspw. Backlogs, die an Scrum angelehnt waren. Dieses Projekt<br />
wurde mit diesem Vorgehen ein Erfolg, da durch die zahlreichen Iterationszyklen die<br />
Anforderungen besser erfasst und spezifiziert werden konnten. Insbesondere die durch<br />
dieses Vorgehen initiierte enge Zusammenarbeit zwischen IT und Fachseite konnten<br />
das Kundenunternehmen vollständig überzeugen, agile Methoden zu verwenden.<br />
Dieser Erfolg war dann ausschlaggebend für den Test, ob grössere Projekte, wie das<br />
vorliegende, in einem ähnlichen Rahmen durchgeführt werden konnten.<br />
Hierfür wurde eine hybride Vorgehensweise gewählt, d.h. eine Mischung aus einem<br />
V-Modell-Vorgehen und agiler Entwicklung. SMC ist der Meinung, dass im Frontend-<br />
Bereich, d.h. bezüglich Applikationen, die auf dem Kern-DWH aufsetzen, agile Methoden<br />
sehr gut eingesetzt werden können. Für das Kern-DWH, d.h. für die Strukturierung<br />
der Daten und die entsprechenden Bereinigungs- und Aufbereitungsprozesse aus<br />
den Quellsystemen seien agile Methoden eher ungeeignet und deshalb der Wasserfall-<br />
Ansatz, bzw. im vorliegenden Fall das V-Modell, vorzuziehen.<br />
5.4.3 Details zum betrachteten Projekt<br />
Im Folgenden wird das Vorgehen im beschriebenen Projekt detaillierter beschrieben.<br />
Dabei wird insbesondere auf den Projektablauf und die beteiligten Rollen eingegangen.<br />
5.4.3.1 Projektvorgehen<br />
Das grundsätzliche Vorgehen im betrachteten Projekt orientiert sich auf der einen Seite<br />
am klassischen Wasserfall-Ansatz und wird für die Entwicklung des Kern-DWH<br />
verwendet. Hier wird das V-Modell eingesetzt. Die Fachkonzeption, sowie die Front-
Fallstudien zur Methodenentwicklung 153<br />
end-Entwicklung (bzw. die Entwicklung der <strong>analytische</strong>n Applikationen, die auf dem<br />
DWH aufbauen) wird mittels eines adaptierten Scrum abgewickelt. Der Fokus der Betrachtungen<br />
liegt weniger auf dem Bereich des V-Modells als vielmehr auf der Adaption<br />
von Scrum für das Projekt. Ein Grund für diese gemischte Variante liegt in den<br />
Erfahrungen aus der Wissenschafts- und Praxisliteratur. Diese warnt davor, agile Methoden<br />
für die Entwicklung von Hub-and-Spoke-Architekturen zu verwenden 445 .<br />
Gründe dafür sind bspw. das stabile Umfeld in dem sich solche Vorhaben positionieren<br />
oder aber die Schwierigkeit, einzelne Bereiche in einem DWH zu entwickeln und<br />
anschliessend neue hinzuzufügen. Es ist bspw. nur schwer möglich, basierend auf einem<br />