Agile Business Intelligence

Name: Agile Business Intelligence | Theorie und Praxis
Brand: dpunkt
Price: 59.9 EUR
Availability: OnlineOnly

Theorie und Praxis

Stephan Trahasch Michael Zimmer(Autor*in)

dpunkt (Verlag)

1. Auflage

Erschienen am 12. Januar 2016

300 Seiten

E-Book

ePUB mit Wasserzeichen-DRM

Systemvoraussetzungen

E-Book

PDF mit Wasserzeichen-DRM

Systemvoraussetzungen

978-3-86491-874-2 (ISBN)

59,90 €inkl. 7% MwSt.

Systemvoraussetzungen

für ePUB mit Wasserzeichen-DRM und PDF mit Wasserzeichen-DRM

(Hinweis: Die Auswahl des von Ihnen gewünschten Dateiformats und des Kopierschutzes erfolgt erst im System des E-Book Anbieters)

E-Book Einzellizenz

Als Download verfügbar

Beschreibung

Weitere Details

Weitere Ausgaben

Personen

Inhalt

1 - Geleitwort [Seite 5]
2 - Vorwort [Seite 7]
3 - Inhaltsverzeichnis [Seite 9]
4 - 1 Agile Business Intelligence [Seite 17]
4.1 - 1.1 Einleitung [Seite 17]
4.2 - 1.2 BI-Agilität und Agile Business Intelligence [Seite 19]
4.3 - 1.3 Werte und Prinzipien für Agile Business Intelligence [Seite 21]
4.3.1 - 1.3.1 Werte [Seite 22]
4.3.2 - 1.3.2 Prinzipien [Seite 23]
4.4 - 1.4 Maßnahmen zur Steigerung der BI-Agilität [Seite 27]
4.4.1 - 1.4.1 Agile Methoden und klassische Vorgehensmodelle [Seite 28]
4.4.2 - 1.4.2 Organisatorische Maßnahmen [Seite 29]
4.4.3 - 1.4.3 Wechselwirkungen zwischen Maßnahmen und Unternehmen [Seite 30]
4.5 - 1.5 Struktur des Buches [Seite 31]
4.6 - 1.6 Ausblick [Seite 34]
5 - 2 Einsatz von Scrum in der Business Intelligence [Seite 37]
5.1 - 2.1 Einordnung von Scrum [Seite 37]
5.1.1 - 2.1.1 Das 3x3 in Scrum [Seite 38]
5.1.2 - 2.1.2 Ablauf eines Sprints [Seite 42]
5.1.3 - 2.1.3 Selbstorganisation des Teams [Seite 43]
5.1.4 - 2.1.4 Pro Scrum [Seite 43]
5.2 - 2.2 Besonderheiten von Business Intelligence und deren Auswirkungen auf Scrum [Seite 44]
5.3 - 2.3 Anpassung von Scrum [Seite 46]
5.3.1 - 2.3.1 Maßnahmen in der Gesamtorganisation [Seite 47]
5.3.2 - 2.3.2 Allgemeine organisatorische Maßnahmen [Seite 48]
5.3.3 - 2.3.3 Maßnahmen im BI-Team [Seite 51]
5.4 - 2.4 Folgen der Umsetzung von Scrum [Seite 52]
5.4.1 - 2.4.1 Projektleitung [Seite 52]
5.4.2 - 2.4.2 Planungsaspekte in der IT-Gesamtorganisation [Seite 53]
5.4.3 - 2.4.3 Planung und Priorisierung in Querschnittteams [Seite 54]
5.4.4 - 2.4.4 Architekturgremium [Seite 55]
5.4.5 - 2.4.5 Communitys [Seite 56]
5.4.6 - 2.4.6 Weiterbildung der Mitarbeiter [Seite 56]
5.4.7 - 2.4.7 Technologieaspekte [Seite 57]
5.5 - 2.5 Erfolgsfaktoren und Auswirkungen [Seite 57]
5.6 - 2.6 Herausforderungen [Seite 59]
6 - 3 Anforderungsmanagement durch User Stories [Seite 61]
6.1 - 3.1 Anforderungsmanagement in agilen BI-Projekten [Seite 61]
6.2 - 3.2 Business-Intelligence-Anforderungen als User Stories [Seite 62]
6.2.1 - 3.2.1 Was sind User Stories? [Seite 63]
6.2.2 - 3.2.2 Gute User Stories erstellen [Seite 68]
6.2.3 - 3.2.3 Planen und Schätzen [Seite 71]
6.2.4 - 3.2.4 Akzeptanzkriterien und Tests [Seite 74]
6.3 - 3.3 Fazit [Seite 76]
7 - 4 Modellierung agiler BI-Systeme [Seite 77]
7.1 - 4.1 Business-Intelligence-Architektur [Seite 77]
7.1.1 - 4.1.1 Schichtenmodell der BI-Architektur [Seite 78]
7.1.2 - 4.1.2 Modellierung des Core Data Warehouse [Seite 81]
7.2 - 4.2 Star-Schema-Modellierung im Core Data Warehouse [Seite 82]
7.2.1 - 4.2.1 Granulare Star-Schemata im Core Data Warehouse [Seite 82]
7.2.2 - 4.2.2 Bewertung dimensionaler Modelle im Core Data Warehouse [Seite 83]
7.3 - 4.3 3NF-Modelle im Core Data Warehouse [Seite 84]
7.3.1 - 4.3.1 Core-Data-Warehouse-Modellierung in 3NF [Seite 84]
7.3.2 - 4.3.2 Historisierungsaspekte von 3NF-Modellen [Seite 85]
7.3.3 - 4.3.3 Domänenkonzepte im 3NF-Modell [Seite 87]
7.3.4 - 4.3.4 Bewertung der 3NF-Modellierung im Core Data Warehouse [Seite 89]
7.4 - 4.4 Data-Vault-Ansatz [Seite 90]
7.4.1 - 4.4.1 Tabellentypen im Data-Vault-Modell [Seite 90]
7.4.2 - 4.4.2 Zeitstempel und Formen der Historisierung [Seite 94]
7.4.3 - 4.4.3 Harmonisierung von fachlichen Schlüsseln [Seite 95]
7.4.4 - 4.4.4 Bewertung der Data-Vault-Methode [Seite 96]
7.5 - 4.5 Fazit [Seite 97]
8 - 5 Data Vault für agile Data-Warehouse- Architekturen [Seite 99]
8.1 - 5.1 3. Normalform, Dimensional und Data Vault [Seite 99]
8.2 - 5.2 Automatisierung [Seite 104]
8.3 - 5.3 Geschäftsregeln [Seite 104]
8.4 - 5.4 Agile Business Intelligence [Seite 106]
8.5 - 5.5 Data Vault in der Praxis - eine exemplarische Darstellung [Seite 107]
8.6 - 5.6 Fazit [Seite 114]
9 - 6 Agile BI-Architekturen [Seite 115]
9.1 - 6.1 Einleitung [Seite 115]
9.2 - 6.2 Klassische BI-Architekturkomponenten und BI-Agilität [Seite 116]
9.3 - 6.3 Neue Architekturkomponenten und BI-Agilität [Seite 117]
9.3.1 - 6.3.1 Sandboxes [Seite 117]
9.3.2 - 6.3.2 Engines [Seite 119]
9.3.3 - 6.3.3 Bypässe [Seite 119]
9.4 - 6.4 Architekturansätze zum Umgang mit BI-Agilität [Seite 120]
9.4.1 - 6.4.1 Dezentralisierter Ansatz mit hohen Freiheitsgraden [Seite 121]
9.4.2 - 6.4.2 Autoritärer Ansatz [Seite 121]
9.4.3 - 6.4.3 Unüberwachter Sandbox-Ansatz [Seite 122]
9.4.4 - 6.4.4 Serviceorientierter Ansatz [Seite 122]
9.4.5 - 6.4.5 Serviceorientierter Ansatz mit werkzeuggestützten Sandboxes [Seite 123]
9.4.6 - 6.4.6 Einordnung der Architekturansätze [Seite 123]
9.5 - 6.5 Fazit [Seite 125]
10 - 7 Automatisiertes Testen [Seite 127]
10.1 - 7.1 Die Notwendigkeit von BI Testing [Seite 127]
10.2 - 7.2 Ziel von BI Testing [Seite 130]
10.2.1 - 7.2.1 Der fundamentale Testprozess [Seite 130]
10.2.2 - 7.2.2 Die Teststufen [Seite 133]
10.2.3 - 7.2.3 Die Testarten und die Softwarequalitätsmerkmale [Seite 134]
10.2.4 - 7.2.4 Die Testobjekte in BI-Systemen [Seite 137]
10.2.5 - 7.2.5 Der BI Testing Cube [Seite 138]
10.3 - 7.3 Das Problem der Testautomatisierung von BI Testing [Seite 139]
10.3.1 - 7.3.1 Was lässt sich beim Testen automatisieren? [Seite 140]
10.3.2 - 7.3.2 Übersicht über Werkzeuge zur automatisierten Testdurchführung [Seite 140]
10.4 - 7.4 Fazit [Seite 145]
11 - 8 Technologien, Architekturen und Prozesse [Seite 147]
11.1 - 8.1 Problemstellung [Seite 147]
11.2 - 8.2 Lösungsansatz [Seite 149]
11.2.1 - 8.2.1 Agile Methodik in Business-Intelligence-Projekten [Seite 149]
11.2.2 - 8.2.2 Grundsätze für Agile BI [Seite 150]
11.2.3 - 8.2.3 Anforderungen an eine Agile-BI-Architektur [Seite 152]
11.2.4 - 8.2.4 Architekturansatz [Seite 154]
11.2.5 - 8.2.5 Agile Datenbereitstellung [Seite 156]
11.3 - 8.3 Fazit [Seite 157]
11.3.1 - 8.3.1 Datenverständnis [Seite 157]
11.3.2 - 8.3.2 Architekturerweiterung [Seite 158]
12 - 9 BI-Agilität: Relevanz, Anforderungen und Maßnahmen [Seite 159]
12.1 - 9.1 BI-Agilität als vielschichtige Herausforderung [Seite 159]
12.2 - 9.2 BI-Agilität: Kontext und Relevanz [Seite 160]
12.3 - 9.3 Die Natur von BI-Agilitätsanforderungen [Seite 161]
12.4 - 9.4 Ansatz zur Identifikation und Selektion von BI-Agilitätsmaßnahmen [Seite 164]
12.4.1 - 9.4.1 Identifikation, Klassifikation und Priorisierung von BI-Agilitätsanforderungen [Seite 164]
12.4.2 - 9.4.2 Ableitung von Maßnahmen zur Steigerung der BI-Agilität [Seite 165]
12.4.3 - 9.4.3 Evaluation und Selektion von Maßnahmenbündeln [Seite 167]
12.5 - 9.5 Aktuelle Trends und ihre Agilitätsrelevanz [Seite 169]
12.5.1 - 9.5.1 In-Memory-BI [Seite 169]
12.5.2 - 9.5.2 Big Data [Seite 170]
12.5.3 - 9.5.3 Cloud-BI [Seite 171]
12.6 - 9.6 Fazit [Seite 172]
13 - 10 Agil und dezentral zum Enterprise Data Warehouse [Seite 173]
13.1 - 10.1 Die Landesbank Hessen-Thüringen - Helaba [Seite 173]
13.2 - 10.2 Auslöser und Ziele des BI-Projekts [Seite 174]
13.2.1 - 10.2.1 Ziele, Lösungsansatz und erwarteter Nutzen [Seite 174]
13.2.2 - 10.2.2 Projektpartner und zukünftige Nutzer [Seite 175]
13.2.3 - 10.2.3 Architektur des Enterprise Data Warehouse [Seite 176]
13.2.4 - 10.2.4 Projektmanagement und Change Management [Seite 178]
13.2.5 - 10.2.5 Beschreibung der BI-Organisation [Seite 181]
13.3 - 10.3 Maßnahmen zur Erhöhung der BI-Agilität [Seite 182]
13.3.1 - 10.3.1 Verzahnung von Kanban und Sprints [Seite 183]
13.3.2 - 10.3.2 Prinzipien [Seite 185]
13.4 - 10.4 Erfahrungen und Erfolgsfaktoren [Seite 187]
13.4.1 - 10.4.1 Realisierter Nutzen und bewirkte Veränderungen [Seite 187]
13.4.2 - 10.4.2 Reflexion der Barrieren und Erfolgsfaktoren [Seite 187]
13.5 - 10.5 Fazit [Seite 189]
14 - 11 Agile BI bei congstar [Seite 191]
14.1 - 11.1 congstar [Seite 191]
14.2 - 11.2 Ausgangssituation und Ziele des Projekts [Seite 192]
14.2.1 - 11.2.1 Ausgangssituation [Seite 192]
14.2.2 - 11.2.2 Gründe für das Scheitern einer klassischen Projektmethode [Seite 193]
14.2.3 - 11.2.3 Ziele des Data-Warehouse-Projekts bei congstar [Seite 194]
14.3 - 11.3 Projektablauf und Betrieb [Seite 195]
14.3.1 - 11.3.1 Das Data-Warehouse-Team [Seite 195]
14.3.2 - 11.3.2 Anwender des congstar Data Warehouse [Seite 197]
14.3.3 - 11.3.3 Architektur des congstar Data Warehouse [Seite 197]
14.4 - 11.4 Projektvorgehen [Seite 198]
14.4.1 - 11.4.1 Ablauf eines Sprints bei congstar [Seite 198]
14.4.2 - 11.4.2 Schnitt einer User Story [Seite 201]
14.4.3 - 11.4.3 Technologie [Seite 202]
14.4.4 - 11.4.4 Besonderheiten im congstar Data Warehouse [Seite 203]
14.5 - 11.5 Fazit [Seite 207]
14.5.1 - 11.5.1 Warum das DWH-Projekt bei congstar erfolgreich ist [Seite 207]
14.5.2 - 11.5.2 Lessons Learned [Seite 208]
15 - 12 Einführung von agilen Methoden im Coaching [Seite 211]
15.1 - 12.1 Unternehmen [Seite 211]
15.2 - 12.2 Ausgangssituation und Ziele des BI-Projekts [Seite 212]
15.3 - 12.3 Vom klassischen Projektvorgehen zur Kombination von agiler und klassischer Methodik [Seite 213]
15.3.1 - 12.3.1 Erste Projektphase: Klassische Projektmethodik und -architektur [Seite 213]
15.3.2 - 12.3.2 Zweite Projektphase: Kombination von agiler und klassischer Methodik [Seite 215]
15.4 - 12.4 Fazit [Seite 227]
16 - 13 In-Memory-Technologie als Enabler für Agile BI [Seite 229]
16.1 - 13.1 In-Memory-Technologien und Agile BI [Seite 229]
16.2 - 13.2 SAP Business Warehouse [Seite 231]
16.2.1 - 13.2.1 Allgemein [Seite 231]
16.2.2 - 13.2.2 SAP BW und In-Memory [Seite 231]
16.2.3 - 13.2.3 BW Workspaces [Seite 232]
16.3 - 13.3 Anwendungsfälle für BW Workspaces [Seite 234]
16.3.1 - 13.3.1 Lokale Erweiterung von Stamm- und Bewegungsdaten für das Flottenmanagement [Seite 234]
16.3.2 - 13.3.2 Rapid Prototyping als Interimslösung und zur Validierung [Seite 236]
16.3.3 - 13.3.3 Spezielle Projektberichte [Seite 237]
16.3.4 - 13.3.4 Nutzung als Self-Service-BI-Plattform [Seite 237]
16.4 - 13.4 Maßnahmen zur Erhöhung der BI-Agilität [Seite 238]
16.4.1 - 13.4.1 Technische Maßnahmen [Seite 238]
16.4.2 - 13.4.2 Delivery und Lebenszyklus [Seite 239]
16.4.3 - 13.4.3 Weitere Funktionen in SAP BW zur Erhöhung der BI-Agilität [Seite 239]
16.5 - 13.5 Erfahrungen und Erfolgsfaktoren [Seite 240]
16.5.1 - 13.5.1 Realisierter Nutzen und bewirkte Veränderungen [Seite 240]
16.5.2 - 13.5.2 Reflexion der Barrieren und Erfolgsfaktoren [Seite 240]
16.6 - 13.6 Fazit [Seite 241]
17 - 14 DevOps für Business Intelligence [Seite 243]
17.1 - 14.1 Warum ist das DWH für congstar so wichtig? [Seite 243]
17.2 - 14.2 Die DWH-Architektur bei congstar [Seite 244]
17.3 - 14.3 Einführung in DevOps für Business Intelligence [Seite 246]
17.4 - 14.4 Werte des Entwicklungsteams weitertragen [Seite 248]
17.5 - 14.5 Testmethodiken und Deployments [Seite 251]
17.6 - 14.6 Gemeinsame Deployments [Seite 251]
17.6.1 - 14.6.1 Automatisierte Datenbank-Deployments [Seite 252]
17.6.2 - 14.6.2 Automatisierte ETL-Deployments [Seite 253]
17.6.3 - 14.6.3 Testinfrastruktur [Seite 254]
17.7 - 14.7 Wenn es darauf ankommt: Troubleshooting [Seite 255]
17.7.1 - 14.7.1 Migration auf Tablespace mit Uniform Extent Size [Seite 255]
17.7.2 - 14.7.2 Konfigurative Eingriffe im Produktionssystem [Seite 256]
17.7.3 - 14.7.3 Datenbankanonymisierungen [Seite 257]
17.7.4 - 14.7.4 Monitoring-Berichte [Seite 258]
17.7.5 - 14.7.5 Restartmechanismen [Seite 258]
17.7.6 - 14.7.6 Backup und Recovery der Oracle-Datenbank [Seite 259]
17.7.7 - 14.7.7 Kapazitätsplanung [Seite 259]
17.8 - 14.8 Fazit [Seite 260]
18 - 15 Big Data und BI-Agilität im Marketing [Seite 261]
18.1 - 15.1 Auslöser und Ziele des Big-Data-Projekts [Seite 261]
18.2 - 15.2 Aufbau und Betrieb der Big-Data-Plattform [Seite 263]
18.2.1 - 15.2.1 Projektmanagement mit Scrum [Seite 263]
18.2.2 - 15.2.2 Architektur der Big-Data-Plattform [Seite 266]
18.2.3 - 15.2.3 Continuous Delivery [Seite 271]
18.3 - 15.3 Ein Beispiel für agile Datenanalyse [Seite 272]
18.3.1 - 15.3.1 Zusammenspiel der Big-Data-Plattform mit dem BI-Tool [Seite 272]
18.3.2 - 15.3.2 Exploratives Vorgehen [Seite 273]
18.4 - 15.4 Fazit [Seite 274]
19 - Autoren [Seite 277]
20 - Abkürzungsverzeichnis [Seite 283]
21 - Literaturverzeichnis [Seite 285]
22 - Index [Seite 297]
23 - www.dpunkt.de [Seite 0]

1 Agile Business Intelligence

Stephan Trahasch, Michael Zimmer, Robert Krawatzeck

Auch in der Business Intelligence (BI) werden zunehmend erfolgreich agile Methoden und Frameworks eingesetzt. Grundlegend für alle agilen Vorgehensweisen sind agile Werte und Prinzipien. Wurden die Werte und Prinzipien des agilen Manifests [Agiles Manifest 2001] und die daraus abgeleiteten Methoden zu Beginn meist eins zu eins auf die BI übertragen, so hat sich das Verständnis von BI-Agilität als ganzheitliche Eigenschaft der BI im deutschsprachigen Raum etabliert, und agile Methoden wurden auch auf die Besonderheiten der BI adaptiert. In diesem Kapitel werden BI-Agilität und Agile BI erläutert, ein Ordnungsrahmen für Maßnahmen zur Steigerung der BI-Agilität eingeführt sowie Werte und Prinzipien für eine Agile BI definiert. Einige Prinzipien und agile Methoden werden exemplarisch erläutert und auf die jeweiligen Kapitel in diesem Buch verwiesen.

1.1 Einleitung

Business Intelligence (BI) als unternehmensspezifischer Ansatz zur Entscheidungsunterstützung ist mit den zugehörigen Technologien und Anwendungen eine Voraussetzung für die faktenbasierte Entscheidungsfindung und letztlich für eine erfolgreiche Unternehmenssteuerung. BI stellt einen Kernbestandteil der IT-Infrastruktur von Unternehmen dar, und die Weiterentwicklung der analytischen Möglichkeiten von BI-Anwendungen zählt nach wie vor zu den wichtigsten Themen für Unternehmen [Gartner 2014]. Zeitnahe Analysen aufgrund einer hohen Marktdynamik und ein besseres Verständnis für Produktion, Lieferanten, Kunden und Märkte sind Basis für die Unternehmenssteuerung und notwendig, um die Wettbewerbsfähigkeit zu erhalten und auszubauen. Dies erfordert eine sehr hohe Flexibilität und Adaptionsfähigkeit der dispositiven Systeme zur Entscheidungsunterstützung. Demgegenüber steigt durch die Dynamik und zusätzliche Datenquellen die Komplexität der zu verarbeitenden Daten für die Analyse, was beispielsweise an Form (strukturiert vs. unstrukturiert), Abhängigkeit (Data Governance, Data Ownership, Historie) und Menge der Daten deutlich wird. Hohe Anpassungsfähigkeit und steigende Komplexität sind eine große Herausforderung für Business-Intelligence-Lösungen (vgl. [Kemper et al. 2010]) und für die Weiterentwicklung von Unternehmen.

Werden Softwareprodukte und insbesondere analytische Anwendungen klassisch, z. B. nach dem Wasserfall- oder V-Modell, entwickelt, besteht ein sehr hohes Risiko, dass nicht zeitnah auf Änderungen in einem dynamischen Umfeld reagiert werden kann und Geschäftsziele letztlich nicht erreicht werden. Die Lösung entspricht bei der Fertigstellung und der Auslieferung nicht mehr den veränderten Gegebenheiten und den Anforderungen der Stakeholder.

Agile Softwareentwicklung hingegen stellt einen leichtgewichtigen und flexiblen Ansatz dar, um mithilfe kontinuierlicher Rückkopplungen und kurzer Iterationszyklen einen schnellen Einsatz der entwickelten Systeme zu erreichen und so durch Transparenz Risiken im Entwicklungsprozess zu minimieren und auf Änderungen frühzeitig reagieren zu können. Agile Softwareentwicklung ist jedoch nicht nur die Anwendung von agilen Methoden und Frameworks, sondern stellt eine grundlegende Haltung und Denkweise der Mitarbeiter und der Organisation zur Realisierung von Softwareprojekten dar. Im Manifest für Agile Softwareentwicklung [Agiles Manifest 2001] wurden Werte und Prinzipien definiert, die den Bezugsrahmen für agile Softwareentwicklung festlegen. Die zu schätzenden Werte sind:

»Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung [und]
Reagieren auf Veränderung mehr als das Befolgen eines Plans«.

Aus diesen agilen Werten wurden zwölf Prinzipien für agile Softwareentwicklung, wie beispielsweise: »Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen« und »Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten« [Zwölf Prinzipien 2001] abgeleitet.

Da sich BI-Projekte in einigen Aspekten von Softwareentwicklungsprojekten unterscheiden, sind diese Werte und Prinzipien sowie die agilen Methoden und Vorgehensmodelle nicht direkt auf die Entwicklung dispositiver Systeme übertragbar (vgl. auch Kap. 2 oder 6). Unterschiede sind dabei beispielsweise eine erschwerte Anforderungsanalyse, abteilungsabhängige fachliche Begriffsdefinitionen sowie eine hohe Vernetzung der abteilungsübergreifenden beteiligten Systeme [König 2009]. Zusätzlich werden BI-Lösungen mithilfe von heterogenen und nicht integrierten BI-Werkzeugen (Datenintegration, Datenhaltung, Analyse, Informationsbereitstellung) entwickelt, deren Funktionsumfang die BI-Anwendungen reglementieren [Krawatzeck et al. 2013]. Des Weiteren ist die genaue Spezifikation von Key Performance Indicators (KPIs) und zu realisierenden Reports häufig nur möglich, wenn die Daten aus den Quellsystemen durch den Fachbereich gemeinsam mit dem BI-Entwicklungsteam in dem zur Verfügung stehenden BI-Tool vor der eigentlichen Realisierung analysiert werden können. Die Anforderungsanalyse setzt somit eine sehr enge Zusammenarbeit mit den Fachabteilungen voraus, damit die Fachanwender sinnvoll die Anforderungen definieren können und diese für das Entwicklungsteam nachvollziehbar sind. Erschwerend kommt bei BI-Projekten hinzu, dass oftmals langjährig bestehende BI-Lösungen erweitert und angepasst werden müssen, um neue analytische Fragestellungen beantworten zu können. Wobei die ursprünglichen Systeme hierfür z. T. nicht konzipiert wurden. Herausforderungen sind dabei u. a. die Beibehaltung der Historie von Daten und das erschwerte Refactoring aufgrund fehlender Funktionskapselung mit standardisierten Programmierschnittstellen. Bei der Entwicklung von BI-Anwendungen handelt es sich um einen kontinuierlichen Prozess zur Erfüllung eines Informationsbedarfs mit permanenten Anpassungen auch während des Betriebs.

Agile Vorgehensmodelle und Methoden aus dem Software Engineering sind daher nicht eins zu eins auf Business Intelligence übertragbar. Die agilen Werte und Prinzipien, wie zum Beispiel die Wertschätzung von »Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung« und »Reagieren auf Veränderung mehr als das Befolgen eines Plans«, sind ein guter Ausgangspunkt, um eine anpassungsfähige BI-Entwicklung unter Berücksichtigung steigender Dynamik und Komplexität zu ermöglichen [Zimmer et al. 2012].

1.2 BI-Agilität und Agile Business Intelligence

Unter BI subsumierte Gesamtansätze zur Entscheidungsunterstützung stehen heute vor der Aufgabe, sowohl übergreifende Anforderungen nach Standardisierung als auch bereichsspezifische Agilitätsanforderungen abzubilden. Unter BI-Agilität wird in diesem Zusammenhang die Eigenschaft der BI einer Organisation verstanden, vorhersehbare und unvorhersehbare Anforderungen in Bezug auf Funktionalität oder den Inhalt einer BI-Lösung unternehmenseffizient in einem vorgegebenen Zeitrahmen in angemessener Qualität abzubilden. BI-Agilität beinhaltet einerseits eine Reaktion auf vorhersehbare Anforderungen und andererseits das proaktive Unterstützen von unvorhersehbaren Anforderungen vor dem Hintergrund einer für das Unternehmen effizienten Lösung. In diesem Zusammenhang werden unter Agile BI alle Maßnahmen zur Erhöhung [Zimmer 2015, S. 67] oder Verbesserung der BI-Agilität verstanden [Krawatzeck et al. 2013]. Dabei beschränkt sich Agile BI nicht allein auf die Auswahl und Anwendung eines agilen Vorgehensmodells zur Produktentwicklung, sondern schließt zudem Maßnahmen aus den Bereichen Prinzipien (z. B. Modularisierung, vgl. Kap. 6), Methoden (z. B. Testautomatisierung, vgl. Kap. 7) und Technologie (Data Lakes, vgl. Kap. 8 und 15) ein (vgl. Kap. 8 und 14). Grundlage für alle Methoden und Frameworks sind immer die agilen Werte und Prinzipien.

Abbildung 1-1 stellt die beiden Begriffe BI-Agilität als Eigenschaft der BI und Agile BI als konkrete Maßnahmen schematisch zueinander in Bezug.

Abb. 1-1 Definition der Begriffe BI-Agilität und Agile BI

Eine hohe BI-Agilität hat keinen Alleinvertretungsanspruch und ist immer unternehmensindividuell auszugestalten. Nicht jeder Unternehmensbereich unterliegt einer hohen Dynamik, sodass hierfür eine hohe BI-Agilität nicht zwingend notwendig ist und traditionelle Ansätze besser geeignet sein können. Die Notwendigkeit einer hohen BI-Agilität muss sich sowohl von der Unternehmensstrategie ableiten als auch durch die Anforderungen des Fachbereichs begründen lassen. Die Variationsmöglichkeiten von Agile-BI-Maßnahmen werden unmittelbar durch die BI-Architektur, die BI-Aufbauorganisation, die BI-Prozesse und letztlich die BI-Governance reglementiert [Zimmer 2015].

Innerhalb des durch die BI-Governance vorgegebenen...

Inhalt (EPUB)

Systemvoraussetzungen

Dateiformat: ePUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat ePUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader – beide kostenlos (siehe E-Book Hilfe).
Tablet/Smartphone (Android; iOS): Installieren Sie die App Adobe Digital Editions oder eine andere Leseapp für E-Books, z.B. PocketBook (siehe E-Book Hilfe).
E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m.

Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an.
Mit Wasserzeichen-DRM wird hier ein „weicher” Kopierschutz verwendet. Daher ist technisch zwar alles möglich – sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.

Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).
Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions oder die App PocketBook (siehe E-Book Hilfe).
E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m.

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein „weicher” Kopierschutz verwendet. Daher ist technisch zwar alles möglich – sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.

Als PDF speichern Als Link merken