TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING

Agile Business Intelligence
T2A – 07.06.2011 10:00-13:15

Arno Tigges
OPITZ CONSULTING GmbH

Tom Gansor

Dr. Erik Lenhard
Kabel Deutschland
Vertrieb und Service GmbH & Co. KG

München, 07.06.2011 10:00-13:15

TDWI Konferenz 2011 – T2A Agile Business Intelligence – München 7.6.2011 © OPITZ CONSULTING GmbH 2011 Seite 1

Zur Orientierung
„Erfolgreich durch Best-Practices“
Produkte Strategie & Organisation

 Produktauswahl  IT-Strategie  BI-Strategie
 Anbieter  IT-Governance  BI-Governance
 One-Vendor vs. Best-Of-Breed  IT-Organisation  BICC
 BI-Plattform  BI-Roadmap

Technologie & Architektur Projekte
 Enterprise DWH  Fachliche Exzellenz
 Durchgängiges Informationsmodell (EPM, Planung, Prognose …)
 Vermeidung von Insellösungen  Projektvorgehen
 Technologische Innovationen  Projektmanagement
(Mobile, Appliances, In-Memory…)


Agenda T2A
1. Einführung Tom Gansor

2. Agile Vorgehensmodelle
im BI Kontext Arno Tigges

3. Etablierung Agiler Vorgehensmodelle Tom Gansor
für BI im Unternehmen

11:30 Pause

4. Werkzeuge Arno Tigges

5. Praxisbeispiel von Kabel Deutschland Dr. Erik Lenhard


1 Einführung


Sie sind jetzt gefragt (1/3)

Wer setzt Agile BI bereits ein?



Wie zufrieden sind Sie mit dem
Vorgehen in aktuellen BI-Projekten?

Eher unzufrieden mal mehr/mal weniger ziemlich zufrieden



Was würden Sie gern bzgl. Des
Vorgehens anders machen?


Business Intelligence – eine kurze Historie (1/2)
hoch

Vergangenheit
„M*S“ „DWH“ „OLAP“ „BI“ „EPM“ „?“

Zeitliche Orientierung
Vergangenheit  Jetzt  Zukunft

Jetzt
Komplexität
Datenvolumen, -vielfalt, -quellen
Analysen, Abfragen

Zukunft
gering

<1985 1990 1995 2000 2005 2010


Business Intelligence – eine kurze Historie (2/2)
hoch

Vergangenheit
„M*S“ „DWH“ „OLAP“ „BI“ „EPM“ „?“

Dynamik

Jetzt
Reaktionszeit

Zukunft
gering

<1985 1990 1995 2000 2005 2010


Wert einer Information und Reaktionszeit
Wert

Ereignis

Daten-
speicherung
Informations-
bereitstellung Entscheidung,
Maßnahme

Zeit
Reaktionszeit
Quelle: Totok/Gansor, „Von der BI Strategie zum BI Competency Center“, TDWI Konferenz 2009 T1A


BI Buzzwords

Closed Loop BI Budgeting Planning Forecasting
Open Source BI Enterprise Performance Management
Master Data Management In Memory Analytics
SAAS BI Real Time Decisioning BI Search
Business Activity Monitoring Simulation Data Mining
Real Time Data Integration Process Performance Management
Integrated Planning Web Analytics Mobile BI
Analytic CRM Process Performance Management


Typische Fragestellungen für BI
und Lösungskonzepte
 Was war (im letzten Jahr, Quartal)?
 Reporting
 DWH (Historisierung)

 Was ist (aktuell der Stand der Dinge)?
 OLAP
 Business Activity Monitoring
 Process Performance Management

 Was kommt (morgen, nächstes Jahr)?
 Planung
 Forecasting
 Simulation


Wo ist die Lücke? Management
Cockpit
OLAP-
Planung und Hochrechnung Auswertungen Frontend

Berichts- und Analysesysteme

Bereichs- Aggre-
daten gationen
Output

Metadatenmanagement
OLAP-Würfel Layer
Planung
Business

Hochrechnung Auswertungsdatenbank

nach Abschluss

Data
Basisdatenbank Storage
Retraktion

Closed ODS Layer
(Core Data Warehouse)
Loop
Laden
Staging Area Transformation Integration Layer
Extraktion

ERP-
ERP- PPS- Quell-
System
System System … systeme
Externe Daten,
Administrations- und Dispositionssysteme Internet
In Anlehnung: Totok/Gansor, „Ein BICC praktisch einführen und steuern“, TDWI Konferenz 2010 T2A


Typische Fragestellungen für BI
und Lösungskonzepte – „Lückensuche“
 Was war (im letzten Jahr, Quartal)?
 Reporting  (evtl. keine Lücke)
 DWH (Historisierung)  Vergangenheitsbetrachtung
unter akt. Vorzeichen (What-If)

 Was ist (aktuell der Stand der Dinge)?
 OLAP  Granularität/Analysemodell passend?
 Business Activity Monitoring  Ereignisse, Messstellen vorhanden?
 Process Performance Management  Prozessmodell passend?

 Was kommt (morgen, nächstes Jahr)?
 Planung  Neues Planszenario, Planungszyklus
 Forecasting  Forecasting bei unklaren Infostand
 Simulation  Simulation einer vollkommen neuen
Situation


Herausforderung: Umsetzungszeit
 kurze Umsetzungszeit für
 Flexibilität
 Dynamik
 Reaktionsfähigkeit
 Veränderungsgeschwindigkeit

kürzer Umsetzungszeit länger

 lange Umsetzungszeit durch
 Komplexe Architekturen
 Starre Vorgehensmodelle
 Heterogene IT-Landschaften
 Umständlichen Rollout


Problem: Die IT ist der klassische Bottleneck!
 Annahme:
BI-Lösungen sind „normale“
Anforderung

Anforderung
Softwarelösungen
 Rollenaufteilung
Anforderung
Fachbereich = Kunde
IT = Lieferant
 Selbst eine hocheffektive
Kapazität und skalierbare IT hat
Projektroadmap
begrenzte Ressourcen

Jetzt Zeit


Klassische (BI/DWH-)Entwicklung
BI/DWH-Projekt VGM (sequentiell / „Wasserfall“)

Fachbereich  Annahme:
Initialisierung  FB = Kunde
Analyse  IT = Lieferant
für BI falsch!
Analyse
 IT bildet immer einen
Design
Bottleneck
 egal wie effektiv/effizient
Umsetzung
aufgestellt
6M.
Test
 Sichtbarer Effekte
Rollout  endlose Projekte
 Lange Wartezeiten auch für
Betrieb kl. Änderungen
IT


Lösungsansatz
Beteiligung des Fachbereichs an der Lösungsentwicklung

Fachbereich  Möglichst viele
Projektergebnisse
Initialisierung
durch Beteiligung der
Analyse Bedarfsträger
 Frühe Ergebnisse
Design  Frühes Feedback
 Frühe Akzeptanz
Umsetzung

Test
 Erforderlich:
Rollout Passende
Vorgehensmodelle
Betrieb
IT


Agile Modelle – Grundidee
Zeit
 Vorgehensmodell Agil:
 Sukzessive Systementwicklung
 Zyklisch
 Oft inkrementell/iterativ
 zahlreiche Spielarten

 Akzeptieren… Iteration 3
 …unvollst. Spezifikation
 …veränderliche Rahmenbedigungen und
Anforderungen

 Vorteile:
 Time-To-Market Iteration 2
 Feedback/Korrekturoption
 Frühe QS

Iteration 1

BI-Projekte im Unternehmen vs. Agile VGM 1/2
 BI-Strategieprojekt
 Entwicklung einer BI-Strategie, strategischer Rahmen für Fachlichkeit, Architektur / Technologie
und Organisation, entweder gemeinsam oder auch nur Teile (damit übergeordnetes Projekt zur
Erstellung des Portfolios);

 BI-Organisationsprojekt
 Konzeption / Einführung BICC, ggf. nur organisatorische Teil-Verbesserungen, Entwicklung
Vorgehensmodelle / Templates;

 (Reines) Fachprojekt
 Hausaufgaben des Fachbereichs, z. B. Kennzahlendefinition, Stammdatenvereinheitlichung;

 (Reines) IT-Projekt
 z. B. Modernisierung Hardware, Softwareupdate, Wartung, Performanceoptimierung;

 (Klassisches) BI-Projekt
 z. B. Einführung Vertriebsreporting, Schließung Informationsdeltas, Verbesserung Datenqualität.

Quelle: Gansor/Totok/Stock: „Von der Strategie zum Business Intelligence Competency Center“, Seite 112


BI-Projekte im Unternehmen vs. Agile VGM 2/2

 BI-Strategieprojekt
 BI-Organisationsprojekt
 (Reines) Fachprojekt
 (Reines) IT-Projekt
 (Klassisches) BI-Projekt


Fachbereich:
Vom Budget-Geber zum Projektmitgestalter (1/2)
 Vielfach erfolgt die Budgetierung des BI-Projektes in
Fachbereichen, diese fordern:
 Optimale Nutzung des Budget
 Passgenaue Projekteergebnisse (anforderungsgerecht)
 Einflussnahme im Projektverlauf (insbes. Bei großen Projekten)
 Transparenz über den Projektfortschritt

 Dennoch wird ein Auftraggeber/Auftragnehmermodell zu
häufig akzepiert. Gründe:
 Planbarkeit des Aufwands im FB (en bloc Fachkonzept)
 Fatalismus, „Faulheit“
 Tagesgeschäft (anderer Fokus)
 Unkommunikative IT / Hohe Mauern
 AUFBAU und ABLAUFORGANISATION im Konzern!


Fachbereich:
Vom Budget-Geber zum Projektmitgestalter (2/2)
 Ziel:
Der FB als Geldgeber wird optimal ins Projekt eingebunden
 Entsprechend der Kenntnisse und Fähigkeiten
 Kontinuierlich
 Offen und kommunikativ
 Zeitlich verteilt aber geplant (weniger Dauerbelastung!)

FB + IT Agile BI

TDWI Konferenz 2011 – T2A Agile Business Intelligence – München 7.6.2011
€
© OPITZ CONSULTING GmbH 2011 Seite 24

Agile Vorgehensmodelle
2 im BI Kontext


Agile Modelle

Manifest der agilen Software-Entwicklung

Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
Funktionierende Software ist wichtiger als umfassende Dokumentation.
Kundenzusammenarbeit ist wichtiger als Vertragsverhandlungen.
Auf Änderungen reagieren ist wichtiger als einem Plan zu folgen.

Wir schätzen die Punkte auf der rechten Seite, aber wir bewerten
die Punkte auf der linken Seite höher.

http://agilemanifesto.org

Agile Modelle - Prinzipien

Kunden- Technische
Kooperation zufriedenheit Exzellenz Vertrauen

Motivation
 Agile Softwareentwicklung
Einfachheit
basiert auf einem System
von Werten und Prinzipien.

Reflexion  Agile Softwareentwicklung
ist weniger eine Methodik
Persönliche
Kommunikation
als ein Selbstverständnis.
Funktionierende
Software

Nachhaltigkeit
Selbst-
Kontinuierliche Veränderung organisation
Anpassung als Chance


Agile Modelle – Übersicht

Weit mehr als ein modernes
Verfahren der Softwareentwicklung XP Development
– Einfluss auf Entwicklung von
Managementmethodik FDD

SCRUM

Requirements

Management
Und viele mehr…


Agile Modelle - Projekterfolg
 So teuer wie nötig…
 Einfach und lösungsorientiert
 Iterationen als „Realoptionen“

 So früh wie möglich…
 Frühe und kontinuierliche
Auslieferung
 Prototypen

 …und genau das Richtige
 Kundenkooperation
 Flexibilität
 Benutzerfeedback


Agile Modelle - SCRUM

 Management-Framework zur kollaborativen Abwicklung von
Projekten in komplexen Entwicklungsprojekten
 Eigenschaften:
 Empirische Prozess-Steuerung  Time-Boxed (feste Zeit)
 Einfach (3 Rollen, 3 Meetings, 3 Artefakte)  Skalierbar
 Transparent (Aufgabenzerlegung,
Arbeitsfortschritt)


Agile Modelle- Scrum Workflow Überblick
Product Backlog

Sprint
Daily Scrum (1-4 Wochen)
PO
Burndown Chart

TM
Sprint Ziel Sprint Backlog

PO
TM TM
SM

SM
Sprint Planning Meeting PO
TM
TM ?
PO - Product Owner
TM – Team Auslieferbares Inkrement SM SM
SM –Scrum Master
Sprint Review Meeting Sprint Retrospective


Rollen / Besonderheiten
 nur drei Rollen: PO, SM und TM
 Anzahl Personen im Team begrenzt (7 ± 2)
 das Team ist insgesamt eigenverantwortlich und
selbstorganisiert
 Eigenverantwortung fördert Motivation
 Generalisten im Team, keine Spezialisten
 das Team ist für die Tasks verantwortlich, nie ein Einzelner
 das Team "verbrennt" (Burn-Down), nicht der Einzelne


Agile Modelle - Vor- und Nachteile
 Vorteile:
 Gut einsetzbar bei unklaren Zielen und sich ändernden
Anforderungen/Umgebung
 Verspricht besseres Kosten/Nutzen-Verhältnis
 Ergebnisse entsprechen genauer den Anforderungen

 Nachteile:
 Ergebnis ist nicht vorhersagbar
 Qualitätseigenschaften können nicht garantiert werden
 Oft nicht nachvollziehbar, wie eine Funktion zustande kommt
 Festpreisangebot nicht möglich / schwer kalkulierbar


Agile mit BI? Gedränge im Datawarehouse?


Besonderheiten im BI/DWH Projekt
 Komplexe Architekturen
 Komplexe
multidimensionale Modelle
 Kennzahlen basieren auf
großer Menge an
Quelldaten
 nicht einfach, frühzeitig schon
Ergebnisse zu erhalten

 Hoher Auswirkungsgrad
bei Anpassungen nötig
 z.B. Einbau einer fehlenden
Dimension ist schnell mit hohem
Aufwand verbunden


Typische „Probleme“ im BI/DWH Projektumfeld
BI/DWH Projekte
 … werden erst langwierig geplant
 … dauern dann zu lange
 … verursachen im Verhältnis sehr hohe Kosten
 … liefern am Ende doch nicht den nötigen Mehrwert
 … sind am Ende zu starr und zu unflexibel
 … werden nur von wenigen Personen genutzt
 … und diverses Weiteres…


Problemfelder
Personen und Skills Fehlende Prototypen
 Personen mit entsprechenden  es werden keine Prototypen
Skills fehlen gebaut
 Anforderungen werden schlecht  zu wenige Iterationen (Versionen)
aufgenommen des Prototyps
 Kommunikation zwischen IT und  zu wenige Prototyp-Anwender
Fachbereich ist unzureichend

Unpassende Werkzeuge Größe/Kosten
 Umständliche Bedienung  es gibt keine ersten „kleinen“
 Ungeeignetes oder fehlendes DWH/BI Lösungen
Metadatenmanagement  Die Lizenzkosten für BI-Suiten
 keine geeigente Visualisierung der sind gleich sehr hoch
(Zwischen-)Ergebnisse  Ein DWH benötigt hohen Bedarf
 Komplexe Infrastruktur und an (teurer) Hardware/Storage
Hardware nötig


Abgrenzung Agile BI / Agile DWH
 Agile BI ist nicht gleich Agile Data Warehousing
 BI -> Reports, Dashboards, Queries
 DWH -> Data Management

 Programmierung von Software einfacher in Sprints
aufzuteilen als Beladung eines (E)DWH
 Erstellung von Reports/Dashboards ähnlich wie
Softwareentwicklung -> gleicher agiler Ansatz

 Herausforderung Agiles Data
Management

Stephen Swoyer http://tdwi.org/articles/2010/09/15/agile-dw-keep-users-happy.aspx


Agiles BI mit SCRUM (1/2)
 Product Backlog (Beispiele)
 Reports
 Dashboards
 Verteilungskanäle
 Scorecards Herausforderung:
..... zuzüglich technischer Abhängigkeiten Agiles Data
Management
 Selected Backlog
 Ausgewählte Einträge des Product Backlogs für einen Sprint

 Sprint Backlog (Beispiele)
 Aufgaben um das Sprintziel zu erreichen: Herausforderung:
 Datenquellen im Datamart bereitstellen Agiles Data
 Report a fertigstellen Management
 Report a,b,c auf Dashboard x
 E-Mail Alerts für Kennzahlen y und z aktivieren


Agiles BI mit SCRUM (2/2)
 Sprint durchführen
„Klassischen“ SCRUM Sprint durchführen mit
 Daily Scrum
 Burndown Chart

 Ausführbares Inkrement ausliefern
 Review (Abnahme) des Sprintergebnisses
 Sprintergebnis (Objekte des Selected Backlog) werden ausgerollt

 Retrospektive
 Wertfreier Rückblick auf Sprint
 Was war gut?
 Was könnte verbessert werden?


Agiles Data Management / Probleme
Probleme:
 technische Abhängigkeiten im Selected Log
 Priorisierter Report hat komplexe Datenquelle
 Dauer für Bereitstellung im Data Mart überschreitet
Sprintlänge


Agiles Data Management / Lösungsansätze (1/2)
Lösungsansätze:
 Agile Architekturen
 geeignete DWH Architektur etablieren
 Verwendung eines Business Layers mit Durchgriff auf alle Schichten

 Data To Dashboards in Minutes
 Erstes Inkrement liefert funktionalen Report im „Zieldesign“
 Features sind erfüllt
 Datenmenge und/oder Ladeintervall eingeschränkt
 „Alternative“ Quellen – z.B. Einbindung von Excel-Sheets
 Weitere Ausbaustufen (z.B. „echte“ Datenquellen, höhere Ladeintervalle)
kommen ins Backlog


Agiles Data Management / Lösungsansätze (2/2)
Lösungsansätze:
 Geeignete ("agilable") ETL Tools
 Schnelle Datenintegration durch Einsatz von fortgeschrittenen Tools
 Frühzeitige Visualisierung der Ergebnisse
 Wiederverwendbarkeit Sicherstellen durch „Mapping Templates“
 Fehlerfreie Datenintegration durch automatisierte Regressionstest

 Auswahl des Selected Backlogs
 Wenige Reports in frühen Sprints
 DWH wird je Sprint immer umfangreicher
 Späte Sprints können mehr neue Reports/Kennzahlen beinhalten


Agile DWH Architektur
Security

Quellen Performance

BI Abstraction and Query Generation
Management
Staging Layer Apps
Foundation Layer
Unstrukturierte
Daten Access + Perfor-
mance Layer Web Services
Temporäre eingebettete
Operative Prozess- Data Marts
Daten Daten neutrales MVs, AWs,
Daten- CTAS Alerts,
model Dashboards,
in 3NF Analyse Reports,
Master Daten zurück-
Sandkasten Queries
gewiesene
Daten
Standard BI BI App Daten Advanced
Applikationen Analysis
Tools
ETL, Messaging und Metadaten

In Anlehnung an „Enabling Pervasive BI through a Practical Data Warehouse Reference Architecture“
An Oracle Whitepaper, February 2010

DWH Implementierung in Sprints
Sources Business
Layer

Sprint 1


Sources Staging Layer Business
Layer

Sprint 2


Sources Staging Layer Foundation Business
Layer Layer

Sprint 3


Sources Staging Layer Foundation Access Layer Business
Layer Layer

Sprint 4
Agile BI benötigt
 agile Architekturen
 agile Hardware (Clouds, …)
 agiles Deployment
 agile Beteiligte


Risiken bei agilen Data Management
 Nicht ausreichend sorgfältige Modellierung kann komplette
Sprints aushebeln
 Unnötige Komplexität entsteht im DWH
 Komplexität verursacht Performanceeinbußen
 Aufwändiges Refactoring des DWH kann nötig werden
 Data Management erfolgt in anderen, nicht agilen Projekten
und behindert Erfüllung technischer Abhängigkeiten eines
Sprints


Best Practices agiler DWH Modellierung
1. Zu Anfang (Sprint "0") grundlegende Gedanken zur DWH
Architektur und Datenmodellierung machen
2. Details Just-In-Time modellieren
3. So früh wie möglich, und wenn möglich automatisiert auf
Funktion überprüfen
4. Grundlegende nutzungsorientierte DWH Modellierung
befolgen (Star-Schema, etc.)
5. Nicht am "Single-Point-Of-Truth" verbeißen
6. Auschließlich die nötigen Daten des aktuellen Sprints
berücksichtigen


SWOT Analyse Agile BI
(S)trengths (W)eaknesses

• schnelle Lieferung • Ergebnisse im voraus schwer planbar
• richtige Umsetzung der Anforderung • Qualitätsmerkmale schwer im voraus
• schnelle Reaktion auf veränderte identifizierbar
Anforderungen • keine Festpreise/Werkverträge
• SLA kompliziert

(O)pportunities (T)hreats
• Kundenzufriedenheit steigern • das Team „spielt nicht mit“
• den schlechten Ruf der unflexiblen • der Auftraggeber/Fachbereich lässt
DWH-Lösungen abbauen sich nicht ausreichend involvieren
• Spaß im Projektteam durch neues • DWH/Datenmodell wird unnötig
Vorgehen komplex


SWOT Analyse Maßnahmen
(S)trengths (W)eaknesses
(O)pportunities erfolgreiche BI Projekte durch Ergebnisse sind zwar nicht im
schnelle Lieferung der genau voraus Planbar, decken
benötigten, richtigen Lösung dafür aber genau sogar
erzeugt hohe kurzfristig angepasste
Kundenzufriedenheit Anforderungen ab
(T)hreats Kundeneinbindung fördern frühzeitige Reaktion und
durch schnelle Reaktion auf Gegensteuerung auf
angepasste Anforderungen Fehlentwicklungen
und schnelle Lieferung


Erfolgsfaktoren für Agile BI
 Schnell erste, aber korrekte Ergebnisse liefern, auch wenn
Daten/ETL noch nicht vollständig sind
 Anwender/Auftraggeber intensiv und kontinuierlich
einbinden
 Schnelles, zuverlässiges und müheloses Deployment
 Projektteam mit großem Interesse und Spaß am (neuen)
agilen Vorgehen
 Sehr gute Kommunikation zwischen ALLEN


Etablierung Agiler Vorgehensmodelle
3 für BI im Unternehmen


Einbindung der bestehenden BI-Organisation
 In der Regel besteht im Unternehmen eine ausgeprägte
Organisation für (BI-)Projekte
 Traditionelle Vorgehensmodelle
und Rollenverteilungen sind etabliert
 Phasenorientiertes Vorgehen
 Klare Rollenverteilung zwischen Fachbereichen und IT-Bereichen
 Auftraggeber vs. Auftragnehmer
 U.u. sind VGM als Konzernstandard sogar vorgeschrieben
 Ggf. prägen externe Dienstleister oder outgesourcte IT-Bereiche das
Vorgehen
 Teilaspekte der BI-Projekte sind via SLAs „abgesichert“

 Konsequenz:
Agile BI erfordert eine Anpassung der BI-Organisation für
BI-Projekte!

BICC als Motor des Fortschritts für Agile BI (1/5)
BI Competency Center
BI-Management BI-Architektur BI-Unterstützung BI-Umsetzung
BI-Management Fachliche Architektur BI-Personalentwicklung BI-Entwicklung
BI-Standardisierung Technische Architektur BI-Support BI-Betrieb

Agile BI !


 BI-Management
 Governance, d.h. die BI-Projekte müssen zur BI-Strategie passen
 Akzeptanz der Lösungen ist oft ein wichtiges Ziel innerhalb einer BI-Strategie
 Profitiert von Transparenz bzgl. Projektfortschritt

 BI-Standardisierung
 Etablierung von passenden BI-Vorgehensmodellen
 Erkennen von Best Practices, so auch Agilität
 Grundlagen schaffen für agiles Vorgehen (Projektmgmt. Methodike etc.)


Exkurs BI-Standardisierung
„BI Strategie“ (Makroebene)
 Ausrichtung an Unternehmenstrategie  Entwicklungsrahmen
 Informationssystem-Architektur  Informationssystem-Infrastruktur
 Lösungsportfolio  Personal, Partner, Verbündete

Steuerung und Organisation

Vorgaben, Projektinitialisierung Feedback für Revision / Adaption

Entwicklungsprojekt Reengineering
BI/DWH Lösung 1 BI/DWH Lösung 1

VGM VGM

Entwicklungsprojekt Reengineering
BI/DWH Lösung n BI/DWH Lösung 1

VGM VGM
„BI Operationalisierung“ (Mikroebene)



 BI-Architektur
 Eine gute fachliche Basis (Informationsmodell) erleichtert frühe Ergebnisse
in den 1. Iterationen
 Die technische Architektur muss es ermöglichen, schnell sichtbare
Ergebnisse (ggf. unter Umgehung v. Schichten) zu erzielen
 Dass BICC schafft die architektonische Basis für agile Entwicklung



 BI-Personalentwicklung
 Einfluss auf die Teamzusammensetzung (Sourcing, Akquise)
 Einfluss auf die Teamentwicklung (Weiterbildung bzgl. Der nötigen Skills)

 BI-Support
 Herausforderung: Gestaltung eines Support, der agile Projektteams
unterstützen kann



 BI-Entwicklung
 Kernbereich für BI-Projekte, daher unmittelbar beteiligt und betroffen
 Profitiert selbst von agilen Ansätze
 Fördert den Erfolg des BICC (z.B. durch kürzere Time2Market, bessere
Akzeptanz)

 BI-Betrieb
 Herausforderung: Unterstützung des Betriebs (Betriebsübergangs…) für
agile Projekte


Rahmenbedindungen für die Einführung Agile BI
mit Scrum – Projektteam
Hürden Voraussetzungen

 Unerwünschte Transparenz  Hohe Sozial- und
(Individuelle Leistung, Methodenkompetenz
Teamleistung)
 Kritikfähigkeit
 Starke Fokussierung o.
 Konfliktfähigkeit
Spezialisierung
 Autonomie
 Dominierende Teammitglieder
 Fachliche Flexibilität und Breite
 Fehlender Führungsanspruch
(kein echter Projektleiter)  Passendes Motivationsprofil bei
den Scrumrollen
 Mangelndes Vertrauen des Top-
Managements  Vertrauensvorschuss durch das
Management


Rahmenbedindungen für die Einführung Agile BI
mit Scrum – Organisation
Hürden Voraussetzungen

 Klares Verhältnis Auftraggeber  Hinreichend flexible Verträge o.
vs. Auftragnehmer Verrechnungsmodelle
 SLAs, Werkverträge, Zahlung  Keine organisatorischen
via vorabdefinierter Meilensteine Mauern zw. Fachbereich u.
bspw. IT
 Räumliche Trennung
 Unterstützende Organisation
 Vorgegebene Prozesse,
(BICC, Experten,
Dienstwege
Projektmanagement, …)
 Etablierte
 Management Buy-In
Pflichtvorgehensmodelle
 Ablehnung im Top Mgmt.


Change Management

„Nichts bedarf so sehr der Änderung wie
die Gewohnheiten anderer Leute.“
(Mark Twain)


Angst vor Veränderungen

Den Drang verspüren, die Alte …und in eine neue … um schließlich in dieser
Welt hinter sich zu lassen … Welt einzutauchen … selbstverständlich zu agieren.

Alte Welt Alte Welt
Neue
Neue Welt Neue Welt
Welt

Weg von der alten Welt in die neue Welt

Hürden und Hindernisse

Gedacht ist nicht Gesagt ist nicht Verstanden ist nicht Einverstanden ist Durchgeführt ist
gesagt verstanden einverstanden nicht durchgeführt nicht beibehalten

„Wie, wir planen eine „Wohin fahren wir „Können wir nicht „Ich hab meinen „Wann fahren wir
Reise!?“ noch mal?“ lieber woanders Koffer noch gar nicht denn endlich wieder
hinfahren?“ gepackt! zurück!“


Ängsten gezielt begegnen
Hürden und Hindernisse

Gedacht ist nicht Gesagt ist nicht Verstanden ist nicht Einverstanden ist Durchgeführt ist
gesagt verstanden einverstanden nicht durchgeführt nicht beibehalten

Zielgruppenorientierte Training
Stabilisierung
Kommunikation und -coaching

Ergebnisorientierte
Optimierung der Kommunikation Erarbeitung und Umsetzung der
Methoden und
Bereitstellung von Informationen geeigneten Maßnahmen
Maßnahmen
Basis für einen flexiblen und interaktiven Mitarbeiter zu Multiplikatoren
Periodischer
Informationsaustausch schaffen entwickeln
Erfahrungsaustausch

z.B. Projektteam vorbereiten,
z.B. BICC
Bspw. Ankündigung des neuen coachen;
Roundtable zu
VGM, Binnenmarketing Neue Teams durch erfahrene
Agile BI
Agile BI Experten begleiten


Change Management:
Handlungsempfehlungen aus der Praxis

Auswahl und Aktiver Umgang
Einbindung von mit Konflikten
Schlüsselfiguren • Achtung Frontenbildung
• Personen tragen Prozesse (IT vs. Fachbereich)
• Verbündete • Nicht par ordre du mufti
• Informelle Meinungsführer • Nicht ignorieren
• Alpha-Personen (Aura, • Neutrale Vermittlung (nicht
Charakterköpfe, Vorbilder) aus dem Projekt)


Beispiel – Projektorganisation, Agile BI 1/2
 Konzern
Projekt A B C
 Dynamisches Business
Anforderungen  Neue Geschäftsmodelle
 Zahlreiche umfassende
parallele BI Projekte
Frontend
 Hauptherausforderungen
 Time2Market (Projektlaufzeiten)
Datenbewirtsch.  Konkurrenz der Projekte um
die Ressourcen
Betrieb /  Erste Ergebnisse erst ab
Datenbanken 80% Fertigstellungsgrad
 Volatile Anforderungen
 Z.T. geringe Akzeptanz der
Fachabteilungen


Beispiel – Projektorganisation, Agile BI 2/2
 BICC
Projekt A B C
 Interne Beratung
Anforderungen  Fokus
 Methoden
 Architektur
Frontend
 Einführung agile BI
 Gemischte Projektteams
Datenbewirtsch. End2End

 Experten im BICC
Betrieb /
Datenbanken  Spezifische Skills
 Architektur u.
Methodenberatung


4 Werkzeuge


Werkzeuge - Einleitung
 PM Tools für agile Projekte
 generell geht agiles Vorgehen auch ohne spezielle Tools
 Agiles Prinzip der „Einfachheit“ gilt auch für die Werkzeuge
 spezielle „agile“ Features von PM Tools können hilfreich sein

 Funktionalitäten von "BI Suiten" für agiles Vorgehen
 Was für spezifische Anforderungen müssen BI Suiten erfüllen?
 Welche Komponenten sind wichtig?
 Welche Nutzung ist wichtig?


PM Tools für agile Projekte
 Web "2.0" Technologien
 Projekt Wikis
 Issue Tracking Tools
 Agile: insbesondere für Verwaltung und Priorisierung der Backlogs
 JIRA mit GreenHopper Plugin
 trac mit Agilo Plugin

 Unterstützt bei
Zusammenarbeit des Teams
Unterstützt bei Priorisierung der Backlogs
Bindet den Fachbereich ein


JIRA mit GreenHopper Plugin


trac mit Agilo Plugin


Automatisiertes Testen
 Automatisiertes Testen / Test-Driven Development
 Unit Tests
 früh abgestimmte Ergebnisse ermöglichen Test-Driven Development
 Unit-Test zu Beginn erstellen
 Tools: Unit-Test Frameworks (z.B. JUnit, oder spezielle Query Tools)
 Regressions Tests
 automatische Testdurchführung aller BI Komponenten/Berichte des DWH
 nicht geänderte Module testen, um Seiteneffekte frühzeitig zu erkennen
 um Datenqualität zu gewährleisten
 um Vertrauen in die DWH Architektur bzw. das agile BI-Projekt zu erzeugen
 Tools: Unit-Test Frameworks (s.o.)

Fast Delivery Process
Datenqualitätsanforderungen


Anforderungen an BI Suiten (1/3)
 Data to Dashboards in Minutes
 Vom Fachbereich bereitgestellte Daten werden direkt in ein Dashboard
eingebaut
 Das „Dashboard“ wird gemeinsam direkt im Werkzeug erstellt
 Fast Prototyping
 Ergebnisse fließen in finale Lösung ein

Fast Delivery
Datenqualitätsanforderungen
Schnell und direkt anfangen
Features First, not Data First


Screenshot Pentaho Data Integrator


 Rapid Deployment
 Einfaches Übertragen von Objekten zwischen den vorhandenen
Umgebungen (z.B. DEV, TEST, INT, PROD)
 Versions- und Revisionssicher
 Keine „Schwellenangst“ für kleine Veränderungen

Kontinuierliches Einbinden der Stakeholder
Schnelles/müheloses Deployment


 Business/Presentation Layer
 BI Applikationen greifen nur auf diesen Layer zu
 Der Layer kann auf alle Schichten zugreifen (Access-, Foundation Layer,
Stage Layer, Sources)
 Umstellung bei Änderung der Quellschicht einfach durchführbar
 Umstellung bei Änderung der Quellschicht ist transparent für BI
Applikationen

Kontinuierliches Refactoring des DWH
Schnell und direkt anfangen


Projektberichte mit BI Suite
 Eigenes BI-Tool zur Visualisierung verwenden
 Realer Showcase für die Verwendung der BI Suite
 Projektberichte (z.B. Burn-Down Diagramme) in einem Dashboard der
verwendeten BI Suite darstellen
 Visualisierung von Prozessinformationen (z.B. Zeitpunkte und Laufzeiten der
Ladeläufe, Verfügbarkeits-Statistiken etc.)

Kontinuierliches Einbinden der Stakeholder
Eigenwerbung für die BI Application
Vetrauen schaffen in Deliverables


Zusammenfassung Werkzeuge
 Für agiles PM sind zahlreiche unterstützende Tools auf dem
Markt
 Tools für agiles PM sind nicht zwingend
 Prinzip der „Einfachheit“ auch bei Werkzeuge einhalten
 z.B. das Planning Board kann durchaus sinnvoll auch „mechanisch“
funktionieren (Pinnwand)

 Die eingesetzte BI Suite muss Mindestanforderungen
erfüllen, damit agiles BI prinzipiell funktioniert
 Verwendung eines Business Layers
 Geeignetes Metadatenmanagement
 Einfaches Deployment


Ansprechpartner
Tom Gansor
Director Strategie und Innovation

Kirchstraße 6  51647 Gummersbach
Tel. +49 2261 6001-0
tom.gansor@opitz-consulting.com

Arno Tigges
Project Manager

OPITZ CONSULTING München GmbH
Weltenburger Straße 4  81677 München
Tel. +49 89 680098-0
arno.tigges@opitz-consulting.com


TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING

Similar a TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING (20)

Más de OPITZ CONSULTING Deutschland

Más de OPITZ CONSULTING Deutschland (20)

TDWI - Agile Business Intelligence - Tom Gansor - Arno Tigges - OPITZ CONSULTING