Leseprobe
Inhaltsverzeichnis
Inhaltsverzeichnis
Abkürzungsverzeichnis
Tabellenverzeichnis
1. Einleitung
1.1. Beschreibung der Akteure
1.2. Ausgangssituation
1.3. Fallbeschreibung und Aufgabenstellung
2. IT-Projekte und Vorgehensmodelle
2.1. Begriffsdefinition: (IT-)Projekt und Vorgehensmodell
2.2. Sequenzielles Vorgehensmodell: Wasserfallmodell
2.3. Iteratives Vorgehensmodell: Rational Unified Process
2.4. Agiles Vorgehensmodell: Scrum
3. BI-Projekte: Besonderheiten und vorhandene Modelle
3.1. Definition und Konzept von Business Intelligence
3.2. Besonderheiten von BI-Projekten
3.3. Etablierte Vorgehensmodelle in BI-Projekten
4. Analyse der Eignung von Vorgehensmodellen für BI-Projekte
4.1. Phasenorientierte Vorgehensmodelle
4.2. Iterative und iterativ-inkrementell Vorgehensmodelle
4.3. Agile Vorgehensmodelle
5. Entwicklung von Auswahlkriterien für BI-Vorgehensmodelle
5.1. Identifikation allgemeingültiger Auswahlkriterien in IT-Projekten
5.2. Berücksichtigen der Besonderheiten von BI-Projekten
5.3. Zusammenfassen und Gewichten der Kriterien
Literaturverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Tabellenverzeichnis
Tabelle 1: Abschließender Kriterienkatalog
1. Einleitung
Die folgende Einleitung gibt allgemeine Informationen zu den Akteuren dieser Fallstudie. Außerdem beschreibt sie die Ausgangssituation beim betroffenen Unternehmen und gibt einen kurzen Überblick über die bearbeiteten Aufgaben.
1.1. Beschreibung der Akteure
Wir sind eine Unternehmensberatung mit dem Spezialgebiet der Beratung von Handelsunternehmen im Bereich von Business Intelligence (BI). Unser Kunde, der mittelständische Handelsbetrieb „BioFood“, spürt einen anhaltenden und intensiveren Konzentrations- und Konsolidierungsdruck, welcher zu einer Verschärfung der Wettbewerbsintensität führt.
1.2. Ausgangssituation
Das Unternehmen „BioFood“ möchte daher ein zukunftsfähiges BI-System einführen. Dieses System soll dazu dienen, Wettbewerbsvorteile durch Informationsvorsprünge zu erlangen.
Die Sortimentsgestaltung soll beispielsweise mit Data Mining optimiert werden. Eine weitere Vision ist es, Kunden mit personalisierter Werbung anzusprechen.
1.3. Fallbeschreibung und Aufgabenstellung
BI-Systeme lassen sich grundsätzlich der Kategorie „Informations- und Anwendungssysteme“ zuordnen. In diesem Bereich gibt es bereits eine Vielzahl etablierter Vorgehensmodelle. Doch nicht alle dieser Vorgehensmodelle sind aufgrund der Besonderheit von BI-Systemen für deren Einführung geeignet.
Die Aufgabe ist nun, geeignete Vorgehensmodelle für die Einführung eines BI-Systems zu finden. Dementsprechend ist die folgende Fallstudie in mehrere Teilaufgaben gegliedert:
- Zu Beginn sollen in Kapitel 2 allgemeine Vorgehensmodelle bei IT-Projekten identifiziert und beschrieben werden
- Im Anschluss soll in Kapitel 3 der Begriff „Business Intelligence“ definiert sowie die Besonderheiten bei BI-Projekten definiert werden. Außerdem werden bekannte Vorgehensmodelle für BI-Projekte identifiziert
- Im vierten Kapitel der Arbeit sollen die in Kapitel 2 identifizierten Vorgehensmodelle auf ihre Eignung in Bezug auf BI-Projekte untersucht werden
- In Kapitel 5 werden schließlich Auswahlkriterien entwickelt, die eine nachvollziehbare Auswahl von Vorgehensmodellen bei BI-Projekten ermöglichen
2. IT-Projekte und Vorgehensmodelle
In diesem Kapitel erfolgt eine kurze Einführung in die Begrifflichkeiten „IT-Projekt“ und „Vorgehensmodell“. Im Anschluss werden drei Kategorien von Vorgehensmodellen anhand der bekannten Beispiele Wasserfallmodell, Spiralmodell und Scrum beschrieben.
2.1. Begriffsdefinition: (IT-)Projekt und Vorgehensmodell
Trivial definiert ist ein Projekt eine „zeitlich befristete […] Aufgabe von erheblicher Komplexität, die […] ein gesondertes Projektmanagement erfordert“ (Voigt, K. / Schewe, G. 2018). Es zeichnet sich weiterhin u. a. durch Kriterien wie Einmaligkeit, Ressourcenknappheit, Terminierung und hohem Risiko aus.1
Aufgrund der Komplexität und des Risikos sollten Projekte gemanagt werden. Dazu dienen sog. Vorgehensmodelle. Ein Vorgehensmodell beschreibt Aktivitäten und Phasen, die ein Projekt typischerweise durchlaufen sollte und stellt somit Hilfen und Empfehlungen zur Bearbeitung des Projekts zur Verfügung. Es ermöglicht die Zerteilung in planbare und kontrollierbare Einheiten und kann deshalb dabei helfen, die Komplexität etwas zu reduzieren.2
2.2. Sequenzielles Vorgehensmodell: Wasserfallmodell
Beim Wasserfallmodell handelt es sich um ein sequenzielles Modell, welches häufig in der Softwareentwicklung zum Einsatz kommt. Dabei werden die Phasen der Softwareentwicklung nacheinander durchlaufen. Jede nachfolgende Phase ist jedoch auf die Ergebnisse der vorherigen Phase angewiesen, weshalb Phasenübergänge nur nach dem vollständigen Abschluss der vorherigen Phase möglich sind.
Ein Rückgang in eine Phase ist durch eine Optimierung des Modelles zwar mittlerweile auch möglich, jedoch muss bei der Verwendung des Wasserfallmodells bereits zu Beginn feststehen, welche Technik am Ende verwendet werden soll. Bei der Ungewissheit in IT-Projekten ist dies nachteilig. Außerdem wird der Kunde häufig erst sehr spät in die Entwicklung eingebunden, weshalb sich Probleme häufig erst zu einem sehr späten Zeitpunkt zeigen.3
2.3. Iteratives Vorgehensmodell: Rational Unified Process
Als Weiterentwicklung von sequenziellen Vorgehensmodellen können iterative Modelle gesehen werden. Dort werden die einzelnen Entwicklungsphasen in mehreren Iterationen durchlaufen. Sie entwickeln außerdem die prototypische Entwicklung weiter, bei der bereits vor dem Beginn der Entwicklung ein Prototyp erstellt wird, anhand dessen der Kunde vorab mögliche Probleme erkennen und Wünsche äußern kann.
Beim iterativen Vorgehensmodell wird das Produkt in jeder Iteration optimiert oder Fehler korrigiert. Dabei unterscheidet sich häufig die Intensität der einzelnen Entwicklungsphasen je Iteration.4
Ein Beispiel für ein iteratives (und zusätzlich inkrementelles) Vorgehensmodell ist der Rational Unified Process (RUP). Es definiert verschiedene Kernprozesse und Disziplinen, die je fortschreitender Iteration unterschiedlich stark in ihrer Ausprägung bearbeitet werden. Für Außenstehende jedoch erscheint RUP sehr komplex und umfangreich.5
2.4. Agiles Vorgehensmodell: Scrum
Im Jahr 2001 haben sich mehrere Personen zusammengeschlossen und im Agilen Manifest vier Werte für die Softwareentwicklung niedergeschrieben. In der Kernaussage sollen Softwareprojekte mehr Wert auf die Zusammenarbeit, ein funktionierendes Produkt und die Reaktion auf Veränderung legen als bisher.6 In der Folge gewann der sog. a gile Ansatz immer mehr an Bedeutung. Dabei wird auf eine umfangreiche Planung zu Beginn und festgeschriebene Prozesse verzichtet und der Fokus auf die Entwicklung gelegt, die regelmäßig mit dem Kunden begutachtet und verfeinert wird. Das Ziel von agilen Vorgehensweisen ist das Schaffen eines echten Nutzens.7
Das Beispiel Scrum ist ein Rahmenwerk, innerhalb dessen verschiedene Prozesse und Techniken eingesetzt werden können.8 Es besteht aus Rollen wie dem Product Owner, Ereignissen wie dem Sprint, in welchem die Ergebnisse erstellt werden und Artefakten wie dem Product Backlog, in den alle Anforderungen an das Produkt aufgenommen werden. Durch die Verwendung von Scrum und dessen Empfehlungen sind die Teams anpassungsfähig und flexibel und der Kunde wird in kurzen Abständen mit neuen Funktionen beliefert. Daher entspricht das Rahmenwerk dem agilen Ansatz.
3. BI-Projekte: Besonderheiten und vorhandene Modelle
Projekte im Umfeld Business Intelligence (BI) zeichnen sich im Vergleich zu anderen IT-Projekten mit gewissen Besonderheiten aus. Diese sollen in diesem Kapitel – nach einer kurzen Einführung in Business Intelligence – beschrieben werden. Außerdem werden bereits etablierte Vorgehensmodelle bei BI-Projekten erläutert.
3.1. Definition und Konzept von Business Intelligence
Die Definition von Business Intelligence (BI) erscheint aufgrund der Vielzahl an Erklärungsansätzen schwierig. Generell dient BI der Entscheidungsunterstützung durch das Sammeln, Aufbereiten und Darstellen relevanter Informationen, die aus einer Vielzahl von Daten verschiedenster Quellsysteme gewonnen werden.
Das Konzept von BI ist dabei die Unterstützung von Entscheidungsträgern mithilfe von Informationen. Diese Informationen werden aus Daten verschiedenster Quellsysteme gewonnen. Mithilfe von BI-Systemen werden diese geladen, zusammengefasst, ggf. konsolidiert und in einem entscheidungsorientierten Charakter dargestellt.9
3.2. Besonderheiten von BI-Projekten
BI-Projekte unterscheiden sich durch einige Spezifika von anderen IT-Projekten. Diese Unterschiede sollen im Folgenden kurz beschrieben werden.10
Zunächst scheint der Begriff Projekt im BI-Umfeld unpassend zu sein. So sind Vorhaben in diesem Umfeld eher als fortlaufende Entwicklung zu sehen, da ständig neue Anforderungen umgesetzt werden können und sich Fragestellungen, die durch BI adressiert werden, häufig ändern. Des Weiteren sind BI-Systeme stark mit einer Vielzahl an operativen Systemen verknüpft bzw. von diesen abhängig. In diesen Systemen wiederum arbeitet eine Vielzahl von Mitarbeitern aus verschiedensten Fachbereichen. Diese Heterogenität von Systemen und Anwendern führt zu einer gesteigerten Komplexität.
Eine weitere Herausforderung bei BI-Projekten sind Risiko und Restriktionen. Da die Quellsysteme bereits existieren kann keine Planung von Grund auf erfolgen, da bereits Restriktionen durch die heterogene und vorhandene Systemlandschaft vorhanden sind. Wird mit produktiven Daten gearbeitet steigt das Risiko von ungewollten Datenverlusten.
In BI-Projekten müssen häufig Endanwender bereits von Beginn an einbezogen werden. Diese haben jedoch häufig Probleme ihre Anforderungen bereits ex ante klar auszudrücken bzw. es droht die Gefahr von Missverständnissen. Da BI-Projekte häufig bereichsübergreifend durchgeführt werden müssen, muss die Notwendigkeit außerdem an sehr hoher Stelle im Unternehmen (z. B. in der Geschäftsleitung) gefördert werden.
3.3. Etablierte Vorgehensmodelle in BI-Projekten
BI-Projekte können auf verschiedenste Weisen realisiert werden. Aufgrund der Marktentwicklung hat sich in den letzten Jahren jedoch immer mehr der agile Ansatz etabliert. Entscheider erhoffen sich dadurch eine hohe Anpassungsfähigkeit.11 Außerdem gut geeignet für BI-Projekte sind Modelle, die Prototypen verwenden. Dies sind neben den agilen Ansätzen auch iterativ-inkrementelle Vorgehensweisen. Mit Prototypen können die Benutzer früh in den Entwicklungsprozess eingebunden werden und somit Fehler und Änderungswünsche schnell erkannt werden.12
4. Analyse der Eignung von Vorgehensmodellen für BI-Projekte
In Hinblick auf die Eignung von Vorgehensmodellen für BI-Projekte gibt es auch für die in Kapitel 2 identifizierten Methoden Unterschiede. Diese sollen im Folgenden analysiert werden. Hierzu wird für jeden in Kapitel 2 identifizierten Modelltyp beleuchtet, inwiefern dieser sich in der Theorie für BI-Projekte eignet. Wichtig ist zu erwähnen, dass je nach Projekt spezifisch entschieden werden muss, inwiefern sich einzelne Vorgehensmodelle dafür eignen. Dies kann anhand von Auswahlkriterien erfolgen, die in Kapitel 5 detaillierter beschrieben werden.
4.1. Phasenorientierte Vorgehensmodelle
Phasenorientierte Vorgehensmodelle sind häufig mit dem Vorurteil behaftet, schwerfällig zu sein und nachträgliche Änderungen während der Entwicklung auszuschließen. Außerdem wird der Anwender in phasenorientierten Vorgehensmodellen wie dem Wasserfallmodell erst sehr spät im Projekt erstmalig mit eingebunden. Zu diesem Zeitpunkt sind Änderungen häufig nur mit sehr hohem Aufwand und zu sehr hohen Kosten möglich. Da der Anwender bei BI-Projekten im Fokus steht und die Akzeptanz für das neue System essenziell ist, scheint es, als wären phasenorientierte Modelle, die viel Wert auf eine ausführliche Planung legen, für BI-Projekte nicht geeignet. Dennoch sollte berücksichtigt werden, dass eine ausführliche Planung vor allem bei riskanten und teuren Projekten wichtig sein kann.
4.2. Iterative und iterativ-inkrementell Vorgehensmodelle
Iterative und iterativ-inkrementelle Vorgehensmodelle bieten im Vergleich zu phasenorientierten Modellen den Vorteil, dass sie aus mehreren Entwicklungszyklen bestehen. Dementsprechend können Änderungen in späteren Iterationen berücksichtigt werden und das System kann kontinuierlich ausgebaut und verbessert werden. Nutzen die Vorgehensmodelle zusätzlich Prototypen, sind diese durchaus auch im BI-Umfeld vorstellbar. Dadurch erkennen Anwender die Ergebnisse schneller als bei phasenorientierten Modellen und können Änderungen früher mitteilen. Das bringt den weiteren Vorteil, dass die Anwender bereits früh mit dem System in Kontakt kommen und so frühe Lerneffekte erzielen können. Dies wiederum steigert die Akzeptanz des Systems.13
4.3. Agile Vorgehensmodelle
Agile Methoden scheinen vor allem aufgrund der Unterstützung der Anpassungs- und Reaktionsfähigkeit gut für BI-Projekte geeignet. Dennoch sind agile Methoden nicht immer vollständig in das BI-Umfeld zu übertragen und es sind einige Anpassungen erforderlich. Ein Beispiel für die gute Anwendungsmöglichkeit von Agilität ist im Bereich der Entwicklung von Data Warehouse-Lösungen zu beobachten: Dort können Methoden wie Pair Programming, Test Driven Development oder auch ein kontinuierliches Weiterentwickeln von Systemen die Agilität unterstützen.14
Bei der Verwendung agiler Vorgehensmodelle darf jedoch ein Mindestmaß an Vorausplanung nicht außer Acht gelassen werden. Außerdem sollte Wert auf ausreichende Dokumentation, Qualitätssicherung und Anwenderschulung gelegt werden, da Projekte ansonsten nicht agil, sondern eher chaotisch verlaufen können.
5. Entwicklung von Auswahlkriterien für BI-Vorgehensmodelle
Im folgenden Kapitel wird ein Kriterienkatalog entwickelt, der es ermöglichen soll, eine nachvollziehbare Entscheidung bei der Auswahl von BI-Projekten in Hinblick auf das verwendete Vorgehensmodell zu treffen.
5.1. Identifikation allgemeingültiger Auswahlkriterien in IT-Projekten
Bei der Auswahl von Vorgehensmodellen bei IT-Projekten gibt es einige allgemeingültige Kriterien, die berücksichtigt werden sollten. Im Folgenden werden sechs dieser Kriterien kurz beschrieben.15
Projektgröße
Ein entscheidendes Auswahlkriterium für ein Vorgehensmodell ist sicherlich die Größe bzw. der Umfang des Projekts. Kleinere Projekte können anders bearbeitet werden als große Projekte. Die Größe kann dabei in verschiedenen Ausprägungen bestimmt werden (z. B. Kosten, Personentage, Anzahl der Beteiligten, etc.). So eignet sich Scrum beispielsweise eher für Projekte mit kleineren Teams (zwischen drei und neun Mitgliedern plus Product Owner und Scrum Master16 ).
Detailierungsgrad
Mit dem Auswahlkriterium Detailierungsgrad wird Bezug auf die Planungs-, Spezifikations-, Dokumentations- und Kontrollphase genommen. Je nach Projekt kann eine ausführlichere Planung und Spezifikation notwendig sein. Bei verteilten Teams (z. B. weltweit) scheint es notwendig, dass das Vorgehensmodell Wert auf eine ausführliche und für alle klar verständliche Spezifikation legt, anhand der die Zielerreichung später gemessen werden kann.
Vertragsgestaltung und Vertrauen
Vor allem bei der Zusammenarbeit mit externen Dienstleistern spielt die Gestaltung der Verträge eine Rolle. Die Gestaltung der Verträge nimmt z. B. Einfluss auf den Zeit- und Kostenrahmen sowie die Haftung bei etwaigen Fehlern. Ein weiterer Faktor ist das Vertrauen der beiden Vertragsparteien. Da je nach Vorgehensmodell mehr oder weniger Planung und Dokumentation vorgesehen ist, ist es wichtig, dass die Auswahl des Modelles nach Vertragsgestaltung und gegenseitigem Vertrauen erfolgt.
[...]
1 Vgl. o. A. (2019)
2 Vgl. Breitner, M. (2012)
3 Vgl. Kleuker, S. (2018, S. 28f.), Lang, R. / Schü, J. (2013, S. 65)
4 Vgl. Kleuker, S. (2018 S. 31f.)
5 Vgl. Kleuker, S. (2018, S. 39ff.)
6 Vgl. Beck, K. et. al. (2001)
7 Vgl. Michl, T. (S. 4f.)
8 Vgl. Schwaber, K. / Sutherland, J. (2017, S. 3)
9 Vgl. Litzel, N. (2016), Hummeltenberg, W. (2019), Consulting.de (2018)
10 Vgl. Becker, J. et. al. (2006); König, S. (2009); Konzelmann, R. (2008); Trahasch, S. et. al. (2016)
11 Vgl. Trahasch, S. et. al. (2016, S. 187)
12 Vgl. Schön, D. (2018, S. 264f.)
13 Vgl. Schön, D. (ebenda)
14 Vgl. Trahasch, S. et. al. (2016, S. 191)
15 Vgl. Bauer, A. / Günzel, H. (2013, S. 341f.)
16 Vgl. Schwaber, K. / Sutherland, J. (2017, S. 7)