BI-Governance: Wer darf was in Entwicklungs

Transcription

M2P
7. Europäische TDWI Konferenz
2. – 4. Juni 2008
Forum am Deutschen Museum, München
BI-Governance: Wer darf was in
Entwicklungs- und Betriebsphasen ?
Prof. Dr. Hans-Georg Kemper
Dr. Ralf Finger
BI-Governance: Wer darf was in
Entwicklungs- und Betriebsphasen ?
–
Erprobte Konzepte, Modelle und Methoden
Prof. Dr. Hans-Georg Kemper
Dr. Ralf Finger
Universität Stuttgart
Betriebswirtschaftliches Institut
Lehrstuhl für ABWL und Wirtschaftsinformatik I
INFORMATION WORKS
Hans-Georg Kemper: BI-Governance
Corporate Governance
Governance meint allgemein das Steuerungs- und Regelungssystem im Sinn von Aufbauund Ablaufstrukturen politisch-gesellschaftlicher Einheiten, privater oder öffentlicher
Organisationen.
... zielt auf die unternehmensspezifische Gestaltung und
Implementierung von Leitungs- und Kontrollstrukturen:
Leistungsfähige Geschäftsführung
Interessenswahrung der Stakeholder
Leistungsfähige Kooperation zwischen
Geschäftsführung und Kontrollinstanzen
Transparente interne und externe Kommunikation
Management Risikomanagement
Internationale Werte, Grundsätze nachhaltiger
Unternehmensführung
1
IT Governance
IT Governance
… structure of relationships and processes to direct and control the
enterprise in order to achieve the enterprise´s goals by adding value
while balancing risk versus return over IT and its processes.
Source: IT Governance Insitute
Wirkungszusammenhänge des Einsatzes von IT und
Unternehmenserfolg
IT
IT
Wert
Wert
beeinflusst
GeschäftsGeschäftsmodel
model
bestimmt
ermöglicht
liefert
GeschäftsGeschäftsprozesse
prozesse
bedingt
UnterUnternehmensnehmensstrategie
strategie
Quelle: Krcmar, Helmut: Informationsmanagement, Berlin, S.399 (angelehnt an Wiegand, Picot, Reichwald)
2
BI-Governance – Ist sie überhaupt erforderlich?
Typische Aussagen:
BI ist historisch gewachsen und bisher hat es immer geklappt
Wir haben bereits viele BI-Anwender. Wie soll ich denen eine
Reglementierung „schmackhaft“ machen?
Man kann Dinge auch „über-administrieren“ und sie damit abwürgen
Wo sollen wir denn anfangen, wie sollen wir das zuschneidern?
Das ist Projekt, für das im Unternehmen kein Erfahrungswissen existiert
BI-Governance – Wir haben ja noch nicht einmal eine IT-Governance
„The main reason why today's organizations refuse to implement BI Governance is
that doing so is costly and complex restricting BI Governance does not produce
value, and that management takes the roles of deciding which projects to undertake.“
US-Army Enterprise Solutions Competency Center, http://escc.army.mil/BI/PolicyGovernance.htm
Zurück in die 80er Jahre:
Management Support Systems –
MSS als Sammelbegriff
(Management-Unterstützungs-Systeme – MUS)
„Rapid changes in technology make it necessary to define the ´systems´ in Management
Support Systems to include several forms of information technology that go beyond and are
quite different from the computer used in traditional data processing. For example,
teleconferencing, electronic data bases, and graphic workstations are all information
technologies that are potentially useful for MSS.“
Michael S. Scott Morton: State of the Art of Research in Management Support Systems, Paper presented at the
Colloquium on Information Systems, MIT July 10-12, 1983, S. 2.
„Management Support Systems (MSS) is the use of computers
and related information technologies to support managers.“
Michael S. Scott Morton: State of the Art of Research in Management Support Systems, Paper presented at the
Colloquium on Information Systems, MIT July 10-12, 1983, S. 5.
3
Management Support Systems
Traditionelle Sichtweise der
Informationssysteme
Dispositive
Systeme
TopManagement
Executive
Information
Systems (EIS)
MiddleManagement
Decision
Support
Systems
(DSS)
LowerManagement
einfache, berichtsorientierte Systeme
(hochverdichtete interne und externe Daten)
Modellgestützte Analysen
(algorithmische Ausrichtung)
berichtsorientierte
Systeme
Management Information
Systems (MIS)
(schwach-verdichtete,
interne Daten)
Transaktionsorientierte
Administrations-, Dispositions- und
Abrechnungssysteme
Operative
Systeme
(OLTP – Online Transaction Processing)
Datenversorgung direkt auf operativen/externen Quellen?
Berichtsorientierte
Systeme
(hochverdichtet)
z.B.
EIS 1
EIS 2
...
Berichtsorientierte
Systeme
(schwach verdichtet)
z.B.
Modellorientierte
Systeme
z.B.
EIS n
DSS 1
DSS 2
...
MIS 1
DSS n
MIS 2
...
MIS n
Restriktionen (früher) BI-Werkzeuge
Technische/semantische Heterogenität operativer Datenhaltung
Belastung der OLTP-Systeme
Antwortzeitverhalten nicht kalkulierbar
Operative Daten meist nicht „manager-orientiert“
Produktion
z.B. OnlineDienste
Externe
Daten
Vertrieb
Technik
Personal
Beschaffung
F&E
......
Operative Datenbestände
4
Operative und dispositive Daten –
Abgrenzungen
Charakteristika
operativer Daten
Charakteristika
dispositiver Daten
Ziel
Abwicklung
der Geschäftsprozesse
Informationen für das Management,
Entscheidungsunterstützung
Ausrichtung
Detaillierte, granulare
Geschäftsvorfalldaten
Verdichtete, transformierte Daten,
umfassendes Metadatenangebot
Zeitbezug
Aktuell; zeitpunktbezogen; auf
die Transaktion ausgerichtet
Unterschiedliche, aufgabenabhängige
Aktualität; Historienbetrachtung
Modellierung
Altbestände oft nicht modelliert
(funktionsorientiert)
Sachgebiets- o. themenbezogen,
standardisiert u. endbenutzertauglich
Zustand
Häufig redundant; inkonsistent;
unnormalisiert
Konsistent modelliert; kontrollierte
Redundanz
Update
Laufend und konkurrierend
Ergänzend; Fortschreibung abgeleiteter,
aggregierter Daten
Queries
Strukturiert; meist statisch im
Programmcode
Ad-hoc für komplexe, ständig wechselnde
Fragestellungen und vorgefertigte
Standardauswertungen
Angelehnt an: Kemper H-G., Architektur u. Gestaltung von
Management-Unterstützungssystemen, 1999, Stuttgart, S.187
Operatives Datenchaos!?
Das Jahrhundertproblem der Informatik besteht in
der Bewältigung des Datenchaos, das infolge
unkontrolliert gewachsener Datenbestände fast
überall entstanden ist.
Max Vetter, 1988
Operative/
externe Daten
SCM
E-Proc.
ERP
Wertschöpfungskette
CRM
Externe
Daten
5
Historisch gewachsene dispositive Datenhaltung
Berichtsorientierte
Systeme
(hochverdichtet)
z.B.
EIS 1
EIS 2
Data
Data
...
Modellorientierte
Systeme
z.B.
EIS n
Data
DSS 1
DSS 2
Data
Data
...
DSS n
Data
Berichtsorientierte
Systeme
(schwach verdichtet)
z.B.
Extrakte/Verdichtungen
Betriebswirt. Harmonisierung
MIS 1
MIS 2
Data
Data
...
MIS n
Data
Produktion
z.B. OnlineDienste
Vertrieb
Externe
Daten
Technik
Beschaffung
Personal
......
F&E
Vorgängerkonzept des Data Warehouse
Berichtsorientierte Systeme
(hoch-verdichtet)
Modellorientierte
Systeme
EIS 1
EIS 2 ...
EIS n
DSS 1
DSS 2
Data
Data
Data
Data
Data
...
Verdichtungen
Berichtsorientierte Systeme
(schwach-verdichtet)
MIS 1
Data
DSS n
Data
MIS 2
Data
...
MIS n
Data
Verdichtungen
Info-Pool
Extrakte/Kopien
Produktion
z.B. OnlineDienste
Externe
Daten
Vertrieb
Technik
Personal
Beschaffung
F&E
......
6
Harmonisierung der Semantik
Abstimmung der zusammenzuführenden Daten bzgl.
ihrer
betriebswirtschaftlichen Bedeutung
(Deckungsbeitrag ist nicht gleich Deckungsbeitrag)
gebietsspezifischen Abgrenzung
(Europa ist nicht gleich Europa)
Währung
(Euro-$-Umrechnung ist nicht gleich Euro-$-Umrechnung)
Periodizität
(Arbeitswoche ist nicht gleich Arbeitswoche)
.....
Ein begrifflicher Freundeskreis reicht leider nicht aus!!
Data Warehouse - Die Abgrenzung eines Protagonisten
"Data Warehouse ist ein Datenbanksystem mit subjektorientierten,
integrierten, zeitbezogenen und zugleich dauerhaften Informationen"
Quelle: William H. Inmon: Building the Data-Warehouse. 1. Auflage, New York u.a. 1992
subjektorientiert
⇒ auf die Belange der Manager ausgerichtet (nach Kunden, Regionen, Produkten ...)
integriert
⇒ aus verschiedensten internen und externen Quellen zusammengeführt
zeitbezogen
⇒ Daten repräsentieren meist definierte Zeiträume (Tage, Wochen, Quartale ....)
dauerhaft
⇒ neue Daten komplettieren den Datenbestand und überschreiben nicht bestehende Daten
7
Subjektorientiert und Integriert
Integriert
Subjektorientiert
DWH
Kunden
Buchhaltung
Account-Manager
Buchhalter
Produkte
Produktion
Produktionssteuerer
Produktmanager
Lieferanten
Materialwirtschaft
Disponent
Logistik-Management
Angelehnt an: Finger, Ralf: Arbeitsunterlagen zum Data Warehouse-Seminar, Köln 1996
Zeitbezogen und Dauerhaft
Operative Daten geben stets
den aktuell gültigen
Zustand wieder
(permanente Veränderung)
Zeitbezogen
Dauerhaft
Dispositive Daten
repräsentieren
einen Zeitraum
Dispositive Daten
werden nicht
überschrieben
DWH
Buchhaltung
Kunden
2002
2003
2004
Produktion
Materialwirtschaft
Produkte
Lieferanten
Angelehnt an: Finger, Ralf: Arbeitsunterlagen zum Data Warehouse-Seminar, Köln 1996
8
Architektur erster Data Warehouses
BI-Anwendungen
MetaDaten
Data Warehouse
Zentraler Datenpool
Extraktion,
Transformation,
Laden (ETL)
Produktion
z.B. Online
-Dienste
Vertrieb
Technik
Personal
Externe
Daten
Beschaffung
......
F&E
Data Marts
Dezentrale, häufig abteilungsbezogene „kleine Data Warehouses“ (Data Marts)
Charakteristika
Performanceoptimierte, abteilungsbezogene Datenhaltung
Hohe Zweckorientierung („anwendungsklassen-orientierte Datenhaltung“)
Häufig werkzeugabhängige Datenbanken
Nicht selten im Verantwortungsbereich der Fachabteilungen („in eigener Regie“)
Data
Marts
BI-Anwendungen
BI-Anwendungen
BI-Anwendungen
iel
ht v
c
i
N
z.B. Online
-Dienste
Externe
Daten
h
risc
isto
h
“
als
ser
s
e
b
ene
chs
a
gew
en
ung
Lös
”
Data
Marts
Data
Marts
Extraktion,
Transformation,
Laden (ETL)
Produktion
Vertrieb
Technik
Personal
Beschaffung
F&E
......
9
Architektur moderner Data Warehouses
Data Warehouse
Data
Marts
Data
Marts
Meta-Daten
Data
Marts
BI-Anwendungen
Transformation
n
ge
ini n t!
e
e
l
In äl haff
F c
s
ge
ab
Zentraler Datenpool
Extraktion,
Transformation,
Laden (ETL)
z.B. Online
-Dienste
Externe
Daten
Produktion
Vertrieb
Technik
Personal
Beschaffung
F&E
......
Operational Data Store
–
Transformierte Daten auf
Transaktionsebene
Neue Applikationstypen im E-Business, z.B.
Selbstbedienungsautomaten (Automatic Teller Machines – ATM)
Call-Center-Anwendungen
CRM-Anwendungen zur gezielten Kundenansprache/-segmentierung
Multi-Channel-Management
Bedingt abgestimmte operative Anwendungsdaten auf granularer
Ebene über die betriebliche Wertschöpfungskette
Operational Data Store – ODS
Subjektorientiert, integriert (wie im Data Warehouse)
Aber nicht zeitbezogen und nicht dauerhaft (anders als im Data Warehouse)
Hoher Detaillierungsgrad der Daten (meist transaktionsorientiert)
Syntaktische/semantische Datentransformation aus „Legacy-“Vorsystemen
Zeitnahes Updating (z.B. transaktionssynchron, stündlich, täglich)
Inmon, W. H.: Building the Operational Data Store, Second Edition, New York u.a. 1999.
10
Eigenschaftsprofile von
operativen,
im ODS- und DWH-Systemen
Von Maur et al. Integrierte Informationslogistik Stand und Entwicklungstendenzen. In: von Maur, Winter: Data
Warehouse Management, Berlin, Heidelberg et a l. 2003, S. 3-23
Architektur ODS-erweiterter Data Warehouses
Data Warehouse
Data
Marts
Data
Marts
Data
Marts
Meta-Daten
BI-Anwendungen
Transformation
n
ige
ein llen fft!
n
I
Fä cha
s
ge
ab
Zentraler Datenpool
MetaDaten
Extraktion, Transformation, Laden (ETL)
(ODS)
ETL
z.B. Online
-Dienste
Externe
Daten
Produktion
Vertrieb
Personal
Technik
Beschaffung
F&E
......
11
Datenhaltungssysteme
Architektur
Datenhaltungssysteme
(Datenbanken – DB)
Data Warehouse
Data
Marts
Data
Marts
Data
Marts
In
Transformati
on
n
ig e
ein len f
a
l
Fä sch
ge
ab ft!
Relationale DB (z.B. Oracle) oder
proprietäre, multidimensionale DB
(z.B. MIS-Alea, TM1 …)
Meta-Daten
BI-Anwendungen
Zentraler Datenpool
Meist relationale DB (z.B. Oracle)
MetaDaten
Extraktion, Transformation, Laden
(ETL)
(ODS)
Produktion
z.B. Online
-Dienste
Vertrieb
Externe
Daten
Personal
Technik
Meist relationale DB (z.B. Oracle)
ERP (Enterprise Resource Planning);
meist jedoch historisch gewachsene
IT-Landschaft („Legacy-Systeme“)
Hierarchische DB (z.B. IBM / IMS)
Relationale DB (z.B. Oracle)
„Flache Dateien“
Proprietäre Strukturen
...
Beschaffung
......
F&E
Architektur ODS-erweiterter Data Warehouses
M e tad ate n
D a ta
M a rt
ODS
D a ta
M a rt
D a ta
M a rt
C o re D ata W areh o u s e
A d m in istratio n ssc h n ittstellen
E TL
O pe ra tiv e
S ys te m e
SCM
ERP
CRM
W e rts c hö pfung sk e tte
E -P ro c .
12
Business Intelligence
–
IT-basierte Managementunterstützung
in „modernen“ Zeiten
E-Business
(Veränderte Produkte, drastische Zunahme des Datenvolumens, Abnahme der
Datengranularität, Intensivierung von Kunden-/Lieferantenbeziehungen, Aufweichung
von Unternehmensgrenzen, ...)
Globalisierung
(Weltweite Marktöffnung, zunehmende Konkurrenz, verändertes Kundenverhalten,
erhöhte Dynamik und Komplexität, neue kritische Erfolgsfaktoren)
Stakeholder
(Basel 2, Corporate Governance, Risk Management, ...)
Unter
UnterBusiness
BusinessIntelligence
Intelligence(BI)
(BI)wird
wirdein
einintegrierter,
integrierter,IT-basierter
IT-basierter
Gesamtansatz
zur
betrieblichen
Entscheidungsunterstützung
Gesamtansatz zur betrieblichen Entscheidungsunterstützungverstanden.
verstanden.
BI-Werkzeuge dienen der Realisierung von BI-Anwendungen
BI-Anwendungen bilden Teilaspekte des Gesamtansatzes ab
BI-Governance – Ist sie überhaupt erforderlich?
Business
BusinessIntelligence
Intelligence(BI)
(BI)
Ziel des Ansatzes ist nicht die Entwicklung isolierter Systeme
zur Optimierung von Einzelfunktionen, sondern die Schaffung
einer zeitbeständigen BI-Infrastruktur, in deren Kontext
Einzelsysteme hoch-integriert interagieren.
Endgültige zeitstabile Lösungen können nicht erarbeitet werden,
Aufgabenbündel besitzen existentielle Bedeutung für das
Gesamtunternehmen,
Aufgabenlösungen verlangen ausgeprägte Koordination und
Mitarbeiter verfügen über interdisziplinäre Kompetenzen.
13
Business-Intelligence-Ordnungsrahmen
Business Intelligence (BI)
Access
Layer
Meta Data
BI Portal
Logic
Layer
Knowledge
Distribution
Systems for
Data Analysis
Content
& Document
Mgmt.
Data Mart
Core Data Warehouse
Data
Layer
SCM
Operational Systems
E-Proc.
ERP
Value Chain
CRM
External
Data
Business-Intelligence-Ordnungsrahmen
Logic
Layer
Data
Layer
Operational Systems
Meta Data
z.B. Data-Mart-basierte
BI-Anwendung imBusiness Intelligence (BI)
Access Controlling
Layer
BI Portal
Systems for
Data Analysis
Data Mart
Core Data Warehouse
z.B.
• Data Warehousebasierte BI-Anwendung
im CRM
Knowledge
• Datenhaltung auf
Distribution
Transaktionsebene
• Speicherung ermittelter
Kundensegmentierung
für andere Anwendungen
Content
Portal-Zugriff
&•Document
z.B.SCM
Data-Warehouse-basierte
E-Proc.
ERP
CRM
BI-Anwendung im
Rechnungswesen
Value
Chain
Mgmt.
External
Data
14
Anbindung an harmonisierte, prozessorientierte,
transaktionsnahe Daten vereinfachen ...
Betriebswirtschaftliche Analyen (Umsatz, DB, Lieferbereitschaft, Kundenzufriedenheit,...)
2
1.1.Ursachenanalyse
Ursachenanalyse
(„wird
(„wirdverursacht
verursachtdurch
durch...“)
...“)
2.2.Auswirkungsanalyse
Auswirkungsanalyse
(„was
wäre,
wenn
...“)
(„was wäre, wenn ...“)
3.3.Mustererkennung
Mustererkennung
(„steht
(„stehtim
imZusammenhang
Zusammenhangmit
mit...“)
...“)
Real-time Analytics
Closed Loop
Active Data Warehousing
3
Geschäftsprozesse
Hans-Georg
Kemper: BI-Governance
Embedded BI
Business Intelligence – Regelungsbedarf
BI-Framework
BI-Potenzialplanung
Planung der dispositiven Datenarchitektur
Planung des BI-Portfolios
Controlling
Organisatorische Implementierung
1
Business
BusinessProcess
ProcessManagement
Management
Planung der Entwicklungsrahmenbedingungen
Planung der technischen Infrastrukturen
15
BI-Governance
IT Governance
BI Governance
…ist ein Teil der IT-Governance und meint den Bereich
der organisatorischen Einbindung, der prozessualen
Gestaltung und Steuerung des gesamten BI-Kontextes
eines Unternehmens, um eine konsequente Ausrichtung
des BI-Konzeptes an der Gesamtstrategie des
Unternehmens sicherzustellen.
BI-Governance – 3 Perspektiven
BI Governance
Request
Prioritization
Guidelines /
Rules /
Recommendation
Business
Intelligence
Roles &
Responsibilities
Quelle: Noe Gutierrez: Business Intelligence (BI) Governance, ITNetwork 365, 2008
16
Empirische Studie
Onlinefragebogen (ca. 8.000 Unternehmen)
Durchführung 2006
Auswertbare Rückläufe: 499
TDWI-unterstützt
Aufbauorganisatorische BI-Einordnung
BI-Governance
Auslösende
Bedingung
Spezialisierte BIOrganisationseinheit
Phänomen
Aufgaben im Lebenszyklus von BI-Systemen
BI-Entwicklung
BI-Systemlandschaft
Fachlicher
BI-Betrieb
Technischer
BI-Betrieb
BI-Anwender
BI-Support
Unternehmenskontext
Merkmale
Kontextbedingungen
17
Die wichtigsten Erkenntnisse
BI ist kein neues Phänomen
75 % (N=326) starteten < 2003
87 % (N=330) befinden sich Wachstums- bzw. Konsolidierungsphasen
65 % haben institutionalisierte Unterstützungseinheiten (11 % planen
konkret ihre Einführung)
80 % (N=404) besitzen Varianten mit einem oder mehreren Core DWHs
(Hub-and-Spoke als dominierende Variante)
Erkenntnis
Erkenntnis1:
1:
Die
DieMehrzahl
Mehrzahlder
derUnternehmen
Unternehmenverfügt
verfügtüber
überBI-Lösungen
BI-LösungenininWachstumsWachstumsund
undKonsolidierungsphasen
Konsolidierungsphasenund
undist
istsich
sichbewusst,
bewusst,dass
dassdie
dieEntwicklung
Entwicklung
und
undder
derBetrieb
Betriebvon
vonBI-Anwendungssystemen
BI-Anwendungssystemenals
alszeitstabile
zeitstabileAufgabe
Aufgabe
adäquate
organisatorisch
verankerte
Unterstützungseinheiten
adäquate organisatorisch verankerte Unterstützungseinheitenerforderlich
erforderlich
machen.
machen.
Die wichtigsten Erkenntnisse
Assistenz-Center
moderierende Funktion an der Schnittstelle zwischen IT-Bereich und Fachabteilungen
Volldienstleister
übernehmen durchgehend sehr hohen Anteil der BI-Unterstützungsleistungen. Sie
fungieren als zentrale Erbringer von BI-Leistungen in einem Unternehmen
Betriebs-Center
zeichnet sich durch einen hohen Anteil am fachlichen BI-Betrieb und am BI-Support aus
Hosting-Center
höchsten Anteil am Betrieb der technischen BI-Infrastrukturen
Entwicklungs-Center
übernehmen die Erstellung und Pflege von BI-Systemen
Erkenntnis
Erkenntnis2:
2:
Die
DieMehrzahl
Mehrzahlder
derBI-Einrichtungen
BI-Einrichtungenbesitzt
besitztbis
biszu
zu20
20Mitarbeiter,
Mitarbeiter,betreut
betreutbis
biszu
zu
1.000
1.000Endbenutzer
Endbenutzerund
undist
istfür
fürDatenvolumina
Datenvoluminabis
bisininden
denTerabyte-Bereich
Terabyte-Bereich
verantwortlich.
verantwortlich.Aussagefähige
AussagefähigeKausalzusammenhänge
Kausalzusammenhängezwischen
zwischen
Endbenutzerzahl,
Datenvolumen
Endbenutzerzahl, Datenvolumenund
undPersonalausstattung
Personalausstattungder
derBI-Einheiten
BI-Einheiten
sind
aufgrund
der
Heterogenität
des
Aufgabenumfelds
nicht
sind aufgrund der Heterogenität des Aufgabenumfelds nichtfeststellbar.
feststellbar.
18
BI-Governance – Projektproiritäten
BI Governance
Request
Prioritization
Guidelines /
Rules /
Recommendation
Business
Intelligence
Roles &
Responsibilities
Angelehnt an: Noe Gutierrez: Business Intelligence (BI) Governance, ITNetwork 365, 2008
Request Prioritization
Ziel
Abgrenzung und Priorisierung einzelner BI-Anwendungen aufgrund CSF und SWOT-Analyse,
Mission
Managementaufgabe
3
2
Business
objectives
1
E
C
Critical
success
factors
BI-Governance-Aufgabe
A
D
B
A
Balanced
Scorecard
E
C
D
B
A
CSFs
IT-Aufgabe
Technischer Integrationsgrad
Betriebliches Know-how
Aufwand
Betriebliche Reihenfolge
Information
to measure
performance
C
Options
for evaluation
B
SWOT
CSF
A
Source (adapted): Ward, J.; Peppard, J.(2003), Strategic Planning for Information Systems, New York 2003, S. 211
19
BI-Governance – Arbeitsteilung
BI Governance
Request
Prioritization
Guidelines /
Rules /
Recommendation
Business
Intelligence
Roles &
Responsibilities
Arbeitsteilung
BI
Consumer
Information
Presentation
Selective BI
Cooperation
BI
Professional
Business Unit
Information
Analysis
Data
Storage
Data
Extraction
IT Department
e.g. Sales
Department
e.g. Supply Chain
Management
e.g. Risk
Management
20
BI-Governance –
Vorgaben und Ratschläge
BI Governance
Request
Prioritization
Guidelines /
Rules /
Recommendation
Business
Intelligence
Roles &
Responsibilities
Gesamtüberblick ITIL Version 3
Quelle: itSMF (2007), ITIL Version 3 - Was ändert sich für die Unternehmen?, Frankfurt am Main 2007.
21
BI-Governance –
Zunächst ist das BI-Wirrwarr zu beseitigen
BI Governance
Request
Prioritization
Guidelines /
Rules /
Recommendation
BI
Chaos
Roles &
Responsibilities
BI-Solutions, BI-Services und Verantwortlichkeiten
BI-Solution
BI-Solution
BI-Solution
…
Transparent Service Usage
BI-Services
BI-Services
100%
BI-Services
Business
IT
0%
Central
Providing
0%
100%
Selecive
Providing
Decentral
Providing
22
1. Dimension
BI-Services: Entwicklung und Betrieb
Definition
BI-Services
BI-Services
BI-Services
BI-Funktionen
BI-Funktionen(Hardware
(Hardware
und
undSoftware,
Software,DienstDienstleistungskomponenten)
leistungskomponenten)
Geschlossene
Geschlossene
anwendungsorientierte
anwendungsorientierte
Einheiten
Einheiten(Benutzer(Benutzer-bzw.
bzw.
Kundensicht)
Kundensicht)
Entwicklung von
BI-Services
Betrieb von
BI-Services
Projekte
Prozesse
Entwicklung
Entwicklungvon
vonBI-Services
BI-Services
Iterative,
Iterative,inkrementelle
inkrementelle
Vorgehensmodelle
Vorgehensmodelle
Prototypische
PrototypischeEntwicklung
Entwicklung
(exploratives
(explorativesPT)
PT)
Starke
StarkeEndbenutzerEndbenutzerbeteiligung
beteiligung
Versioning
Versioning
Betrieb
Betriebvon
vonBI-Services
BI-Services
Planung,
Planung,Überwachung
Überwachungund
und
Steuerung
Steuerungdes
desLieferLieferprozesses
der
BI-Solutions
prozesses der BI-Solutions
Rahmenbedingungen:
Rahmenbedingungen:
- -Geschäftsprozessorient.
Geschäftsprozessorient.
- -Kundenorientierung
Kundenorientierung
- -Kostenoptimierung
Kostenoptimierung
2. Dimension
Access, Logic, Data
Business Intelligence (BI)
BI-Solution
Access
Layer
Layer
Meta Data
Logic
Systems for
Data Analysis
Knowledge
Distribution
Content
& Document
Mgmt.
Data Mart
Core Data Warehouse
Data
Layer
Operational Systems
Services
BI Portal
SCM
E-Proc.
ERP
Value Chain
CRM
Services
Services
External
Data
23
3. Dimension
„Geschäftsnähe“
Hardware-Services
Bereitstellung, Integration, Konfiguration und den Betrieb der erforderlichen Rechen-,
Speicher- und Datenübertragungseinrichtungen.
Software-Services
Entwicklung, Konfiguration und der Betrieb von BI-Software, vom ETL-Werkzeug bis hin zu
spezialisierter Software für das Reporting oder für die Datenvisualisierung.
Template-Services
„Standardanwendungs-Schablonen“, die auf individuelle Anforderungen ausgerichtet
werden können. Ein Template kann bereits lauffähige Datenstrukturen, vorbereitete
Benutzerschnittstellen, Geschäftslogik sowie vorkonfigurierte Systemkonnektoren zur
Verknüpfung mit anderen BI-Komponenten mitbringen.
Content-Services
korrekte Definition, Sammlung, Strukturierung, Transformation und/oder Aufbereitung von
Daten (von eng abgegrenzten Teilaufgaben wie Cleansing von Adressstammdaten bis zur
Durchführung statistisch anspruchsvoller Warenkorbanalyse.
Providing
Tools
Operating
Tools
Hardware
Providing
Operating
Hardware
Reporting/OLAP/Data Mining
Operating
BI-Templates
Portal/Front end/GUI
BI-TemplateDevelopment
po
ne
nt
Operating
BI-Content
ETL/DWH/ODS
BI-ContentDevelopment
C
om
Business Specificity
BI Services Framework
Life Cycle Phase
24
Content
z.B. Harmonisierung
von Stammdaten
z.B. Durchführung von
Data-Mining-Analysen
z.B. Verantwortung von
Portalseiten
Template
z.B. Vordefinition von
Workflows für
Extraktionsprozesse
z.B. Entwicklung von
Standard-Cubes
für OLAP-basierte
Kostenanalysen
z.B. Bereitstellung von
Standardbenutzerprofilen
Software
z.B. Betrieb einer
Data-WarehouseUmgebung
z.B. Betrieb einer
Data-Mining-Suite
z.B. Entwicklung und
Betrieb von
Portalsoftware
Hardware
z.B. Aufbau und
Betrieb eines StorageSystems inkl. Storage
Area Networks
z.B. Bereitstellung
einer performanten
Rechnerinfrastruktur für
Data-Mining-Analysen
z.B. Vorhaltung einer
redundanten
Netzanbindung für den
stabilen Portalzugang
Datenhaltung
Analyse
Präsentation
BI-Komponente
3 Szenarios
Datenhaltung
Art der Leistung:
Erstellung maßgeschneiderter
OLAP-Würfel für Marktanalysen
Komponente: OLAP
(Analysekomponente)
Service-Ebene: Content
(Verantwortung der Korrektheit
und Integrität der Daten)
Content
Geschäftsnähe
Geschäftsnähe
Service Spezifikationen
Template
Art der Leistung:
Application Service Providing
für eine Portalumgebung
Komponente: Portal
(Präsentationskomponente)
Service-Ebene: Software
(Verantwortung des Betriebs
der Software inkl. Benutzersupport als Betriebs-Service)
Software
Hardware
Art der Leistung:
Hosting von Data Warehouses
auf Rechenzentrums-Hardware
Datenhaltung
Analyse
Präsentation
Komponente:
Core Data Warehouse BI-Komponente
Service-Ebene: Hardware
(Verantwortung von Stabilität,
Verfügbarkeit und Skalierbarkeit
der Hardware)
25
Providing
Tools
Operating
Tools
Hardware
Providing
Operating
Hardware
Reporting/OLAP/Data Mining
Operating
BI-Templates
Portal/Front end/GUI
BI-TemplateDevelopment
ETL/DWH/ODS
Operating
BI-Content
po
ne
nt
BI-ContentDevelopment
C
om
Business Specificity
Konkretisierung der
Life Cycle Phase
Problem Management
Deployment
Construction
Entwicklung
&
Betrieb
Incident Management
Design
IT Management
Sub-Services
Business Analysis
Life Cycle Phase
Release Management
Change Management
Configuration Management
Infrastructure Management
Service Dokumentation über den gesamte
Lebenszyklus
Role-based
Service Templates
External
Vendors
Service
Details
Customer
Services
Change
Requests
Service
Details
Service
Lifecycle
Internal
Systems
Basic
Service
Library
Internal
Organization
Service
Details
Change
Requests
Customer
Services
Customer
Service
Details
Customer
Services
Change
Requests
Change
Requests
Customer
Services
Initiation &
Preparation
Development &
Configuration
Operating &
Reengineering
26
27
BI Governance: Wer darf was in
Entwicklungs- und Betriebsprozessen?
2. Teil
Dr. Ralf Finger
© 2008 INFORMATION WORKS
alle genannten Marken sind Eigentum ihrer jeweiligen Urheber
BI Governance, 2.Teil
Agenda
BI Governance und Unternehmensstrategie
FIT-Modell: Szenarien der Arbeitsteilung
zwischen Fachbereich und IT
Anforderungen an BI Services
Spreadmarts: Warum der Fachbereich sich
immer wieder selbst helfen muss.
Agile Business Intelligence als Lösung
Dr. Ralf Finger
29
BI Governance und
Unternehmensstrategie
Effizienzsteht
stehtim
imVordergrund.
Vordergrund.
Effizienz
BIZiele:
Ziele:Standardisierung,
Standardisierung,wenig
wenig
BI
Freiheitsgradefür
fürBenutzer
Benutzer
Freiheitsgrade
Zentralisierungder
derITIT
Zentralisierung
PassgenaueBedienung
Bedienungder
derKunden
Kundensteht
steht
Passgenaue
imVordergrund
imVordergrund
BIZiele:
Ziele:Geschwindigkeit,
Geschwindigkeit,
BI
eherFachbereichsautonomie
Fachbereichsautonomie
eher
Konzentrationauf
aufabgrenzbares
abgrenzbares
Konzentration
Kundensegment,hier
hierSpezialisierung
Spezialisierungund
und
Kundensegment,
Kostenvorteile
Kostenvorteile
BIZiele:
Ziele:Mischmodell
Mischmodellaus
ausZentralisierung
Zentralisierung
BI
undDezentralisierung
Dezentralisierung
und
Quelle: Michael Porter, 1980
Dr. Ralf Finger
Das FIT-ReferenzmodellTM
Verteiltes
Datenmanagement
Dezentrale
Informationsgewinnung
Verteilte
Dezentraler
Informationszugriff
Verteilter
Informationszugriff
Informationszugriff
Informationszugriff
Fachabteilungen
Informationszugriff
Informationszugriff
Informationszugriff
Datenmanagement
Informationszugriff
Datenmanagement
Datenmanagement
Datenmanagement
Datenmanagement
Datenmanagement
IT-Abteilung
Dr. Ralf Finger
30
Aufbau BI Services
SLR
SLR
SLR
Kunden
Service
Level
Agreement
(SLA)
Business
Intelligence
Competence
Center
Service
Level
Agreement
(SLA)
Service 1
Service
Level
Agreement
(SLA)
Service 2
Service
Level Management
Service 3
IT Mittel
Operational
Level
Agreements
(OLA)
Underpinning
Contracts
(UC)
Andere interne
Einheiten
Externe
Einheiten
Dr. Ralf Finger
Anforderung an den BI Service:
Interaktionssequenz
Standardreporting
Abruf der
Standardberichte
Data Warehouse
Load
Informationszugriff
Data Mart Load
Datenmanagement
Dr. Ralf Finger
31
Typischer BI Service: Standardberichte
SLR
SLR
SLR
Kunden
Service
Level
Agreement
(SLA)
Business
Intelligence
Competence
Center
Report 1
Operational
Level
Agreements
(OLA)
Service
Level
Agreement
(SLA)
Report 2
Service
Level
Agreement
(SLA)
Service
Level Management
Report 3
IT Mittel
Underpinning
Contracts
(UC)
Andere interne
Einheiten
Externe
Einheiten
Dr. Ralf Finger
Anforderung an den BI Service:
Interaktionssequenz
Architected Data Mart
Mehrwert:
Automatisierung
auf definierten
Strukturen
Data Warehouse
Load
Abrufe
von Sichten
Mehrwert:
Interaktionsdichte
Informationszugriff
Data Mart Load
Datenmanagement
Dr. Ralf Finger
32
Typischer BI Service: Architected Data Mart
SLR
SLR
SLR
Kunden
Service
Level
Agreement
(SLA)
Business
Intelligence
Competence
Center
Data Mart 1
Service
Level
Agreement
(SLA)
Data Mart 2
Service
Level
Agreement
(SLA)
Service
Level Management
Data Mart 3
IT Mittel
Operational
Level
Agreements
(OLA)
Underpinning
Contracts
(UC)
Andere interne
Einheiten
Externe
Einheiten
Dr. Ralf Finger
Interaktionssequenz
„Fachbereichsanwendung“
Daten manuell
anreichern,
Kennzahlenberechnung
DWH Daten
Auslesen und in
Insel laden
Abrufe
von berechneten
Sichten
Mehrwert:
Interaktionsdichte
& Autarkie über alle drei Ebenen
Heute typisches Anwendungsfeld
sogenannter „Spreadmarts“
Informationszugriff
Datenmanagement
Dr. Ralf Finger
33
Spreadmarts im Fachbereich: BI Service
oft nicht hinreichend dokumentiert
SLR
SLR
SLR
Kunden
Business
Intelligence
Competence
Center
Service
Level
Agreement
(SLA)
DWH
Interface
Service
Level Management
IT Mittel
Operational
Level
Agreements
(OLA)
Andere interne
Einheiten
Underpinning
Contracts
(UC)
Externe
Einheiten
Dr. Ralf Finger
Was ist ein „Spreadmart“?
„A spreadmart is a reporting or analysis system running on a
desktop database (e.g.,spreadsheet, Access database, or
dashboard) that is created and maintained by an individual or
group that performs all the tasks normally done by a data mart
or data warehouse, such as extracting, transforming, and
formatting data as well as defining metrics, submitting queries,
and formatting and publishing reports to others. Also known as
data shadow systems, human data warehouses, or IT shadow
systems.“
Quelle: TDWI Research Report: Strategies for Managing Spreadmarts, First Quarter 2008, Eckerson, Sherman
Dr. Ralf Finger
34
Nicht alle lieben Spreadmarts.
Quelle: TDWI Research Report: Strategies for Managing Spreadmarts, First Quarter 2008, Eckerson, Sherman
Dr. Ralf Finger
Warum gibt es Spreadmarts?
Quelle: TDWI Research
Report: Strategies for
Managing Spreadmarts,
First Quarter 2008,
Eckerson, Sherman
Dr. Ralf Finger
35
Nutzen von Spreadmarts…
Quelle: TDWI Research
Report: Strategies for
Managing Spreadmarts,
First Quarter 2008,
Eckerson, Sherman
Dr. Ralf Finger
Interaktionssequenz
„Fachbereichsanwendung“
Daten manuell
anreichern,
Kennzahlenberechnung
Non DWH Daten
Auslesen und in
Insel laden
Abrufe
von berechneten
Sichten
Mehrwert:
Interaktionsdichte
& Autarkie über alle drei Ebenen
Heute typisches Anwendungsfeld
sogenannter „Spreadmarts“
Informationszugriff
Datenmanagement
Dr. Ralf Finger
36
Verarbeitung non DWH Daten im Fachbereich
Sonderanfragen
Standardberichte
∑
∑
Unlimitierte
Ad Hoc
Analyse
Geführte
Ad Hoc
Analyse
Geführte
Abfragen
∑
∑
∑
Und wieder:
„Spaghetti statt
Lasagne“
Finanzdaten
Dr. Ralf Finger
Vertrieb/
Marketing
Andere
Systeme
Ein Lösungsansatz:
BI Service DWH fremde Felder
Wie erfolgt die
Leistungsabnahme?
Informationskonsument
Prozessablauf Bereitstellung DWH fremder Felder
Welche Informationen
muss die Datenanfrage
enthalten?
Informationsbedarf
Daten
erhalten
Nicht
plausibel
IT
Weiterer
Datenbedarf
Rückfrage
erhalten
Datenanfrage
formulieren
Anfrage
erhalten
Plausibilitätsprüfung
Daten im
DWH nicht
verfügbar
Rückfrage
Prüfung
XO
R
Erwartetes
Ergebnis,
kein weiterer
Bedarf
Extraktbereitstellung
XO
R
Plausibel
Wie schnell kann eine
erste Rückmeldung
zugesagt werden?
Prüfung DWH
Verfügbarkeit
XO
R
Daten
verfügbar
Daten
bereitstellen
Wie wird entstehender
Aufwand abgestimmt?
Erweiterung des DWH nach regelmäßigem Service
Review.
Quelle: metaWORKS BI Reference Library
Dr. Ralf Finger
37
… aber was passiert wenn dies der
Regelfall ist.
Informationskonsument
Prozessablauf Bereitstellung DWH fremder Felder
Informationsbedarf
Daten
erhalten
Nicht
plausibel
IT
Weiterer
Datenbedarf
Rückfrage
erhalten
Datenanfrage
formulieren
Anfrage
erhalten
Plausibilitätsprüfung
Daten im
DWH nicht
verfügbar
Rückfrage
Prüfung
XO
R
Erwartetes
Ergebnis,
kein weiterer
Bedarf
Extraktbereitstellung
XO
R
Plausibel
Prüfung DWH
Verfügbarkeit
XO
R
Daten
verfügbar
Daten
bereitstellen
Die Schnittstelle zwischen Fachbereich und IT wird kritisch.
Dr. Ralf Finger
Data Warehouses als Shared Services
sind etabliert, und nun?
Zielsetzung DWH als
Shared Service
Zielsetzung der Synergie:
Bereitstellung von
Anaysedaten für viele
Fachbereiche
Kostengünstiger Betrieb
durch Automatisierung
Konsistenz im Core DWH
Datenmodell
Zielsetzung des
Fachbereiches
Zielsetzung der Erfüllung
einer spezifischen
Fachbereichsanforderung
Geschwindigkeit in der
Umsetzung von
Auswertungserfordernissen
Konsistenz nur im
fachbereichsspezifischen
Datenmodell
Der existierende DWH Service ist unzureichend.
Dr. Ralf Finger
38
Wann entstehen Spreadmarts?
SLR
SLR
SLR widerspricht
bisherigem DWH
als Shared
Service
SLR
Kunden
Service
Level
Agreement
(SLA)
Business
Intelligence
Competence
Center
Service
Level Management
Geforderter
BI Service
DWH als
Service
IT Mittel
Operational
Level
Agreements
(OLA)
Underpinning
Contracts
(UC)
Andere interne
Einheiten
Externe
Einheiten
Dr. Ralf Finger
Eine erste Gegenüberstellung…
Architected
Data Marts
Standardreporting

Hohe Automatisierung:
Standardisierte Prozesse
Vorhersehbare
Benutzerinteraktionen,
extensives Performance
Tuning möglich
Defintion von Services und
SLAs ist gut umsetzbar

Eher unflexibel, kaum ad
hoc Recherche

Spreadmarts
Hohe Automatisierung: Stark
standardisierte Prozesse
In definierten Grenzen
vorhesehbare
Benutzerinteraktionen
Defintion von Services und
SLAs ist naheliegend und gut
umsetzbar

Ad hoc Recherche nur in
definierten Grenzen
Fachbereichsautonomie:
Sehr hohe Flexibilität für
Fachbereiche auch
kurzfristig auf
Anforderungen zu reagieren
Hohe Interaktionsdichte &
Autarkie für
Fachbereichsanwender
Beitrag der IT schwierig zu
definieren.
Unbekannte Anwendungen
(„Hidden Applications“)
bergen operatives
Betriebsrisiko
Kaum erkennbares
Standardisierungspotential
Wann entsteht die Tendenz zu Spreadmarts?
Dr. Ralf Finger
39
Der Fachbereich wägt ab…
Aufwand der fachlichen Spezifikation (Gespräche,
Abstimmungsgespräche und Workshops, Dokumente, …)
Änderungshäufigkeiten der Anforderung
Komplexität der Anforderung aus fachlicher Sicht
(Wieviel Vorwissen ist erforderlich, um die Anforderung zu
verstehen?)
Wahrgenommenes Vorwissen der IT-Kollegen, die für
die Umsetzung benannt sind.
Kontrollaufwand für die Abnahme der Leistung
(Erstellung Testfälle mit Testdaten, Testtätigkeiten, …)
…
Dr. Ralf Finger
Te
nd
en
Ein Erklärungsversuch.
Erwartete
Kosten des
Fachbereiches
Kosten bei
Erstellung durch IT
za
us
sa
ge
Kosten bei
Erstellung durch
Fachbereich
Fachliche Dynamik und
Komplexität
Dr. Ralf Finger
40
Das Entscheidungskriterium des Fachbereiches
Erwartete Kosten
des Fachbereiches
Kosten bei
Erstellung durch
IT
Kosten bei
Erstellung durch
Fachbereich
Fachliche Dynamik und
Komplexität
Mehraufwand
aus
Beauftragung
der IT
Empfundener
Entscheidungspunkt des Fachbereiches:
„Da fragen wir niemanden, das bauen wir
uns schnell selbst.“
Dr. Ralf Finger
Durch Fachbereich empfundene Mehrkosten bei
Beauftragung der IT, warum ist das so ?
Das Kalkül des Fachbereichs
Kosten bei
Erstellung
durch IT
Kosten bei
Erstellung
durch
Fachbereich
Fachliche Dynamik
und Komplexität
Mehrkosten bei
Beauftragung
der IT
Aufwandstreiber aus Fachbereichssicht
Komplexe Rechenlogiken müssen sehr ausführlich
spezifiziert werden, um sicherzustrellen, dass sie vom
technisch orientierten Implementierer verstanden werden.
Ausführliche Testaktivitäten sind nach Fertigstellung
notwendig, um die Richtigkeit zu gewährleisten
(Kontrollkosten).
Bei häufigen Änderungen der Anforderungen multiplizieren
sich Spezifikations- und Testaufwendungen.
Kurzfristige Anforderungen sind kaum umsetzbar. IT
Vorgaben an systematisches Projektvorgehen werden zu
starr und undifferenziert angewendet. Diese
Mehraufwendungen werden durch die Fachbereiche als
unnötige Overheads empfunden.
IT Bereiche neigen dazu die IT Optimierung zu suchen. So
besteht die Gefahr, dass fachbereichsspezifische
Notwendigkeiten als „nachrangig“ empfunden werden und
zugunsten der Standardisierung zurückgestellt werden.
Fachbereiche haben das Gefühl hier ständig wachsam sein
zu müssen.
….
Dr. Ralf Finger
41
Einige typische Entwicklungen im BI Markt.
Kosten bei
Erstellung
durch IT
Erwartete Kosten des Fachbereiches
Kosten bei
Erstellung
durch IT
Kosten bei
Erstellung
durch
Fachbereich
Kosten bei
Erstellung
durch
Fachbereich
Fachliche Dynamik
und Komplexität
Fachliche Dynamik
und Komplexität
Intuitive Werkzeuge
IT Outsourcing
Kosten bei
Erstellung
durch IT
Kosten bei
Erstellung
durch IT
Kosten bei
Erstellung
durch
Fachbereich
Kosten bei
Erstellung
durch
Fachbereich
Fachliche Dynamik
und Komplexität
BI Plattformen
Fachliche Dynamik
und Komplexität
Steigende Dynamik der Anforderungen
Das Problem wird sich nicht verringern…eher wird es schlimmer.
Dr. Ralf Finger
Wie kann man das Kalkül des
Fachbereiches verstehen ?
Ein Beispiel für ein Ursache-Wirkungsdiagramm
Modellgröße
Proportionale Beziehung
zwischen Modellgrößen
(je höher desto höher
Je niedriger, desto niedriger)
Umgekehrt proportionale
Beziehung zwischen
Modellgrößen
(je höher desto niedriger
Je niedriger, desto höher)
Dr. Ralf Finger
42
Eine BI Scorecard ?
Transaktionskostenmodell
Kostenvorteil bei
Eigenleistung durch den
Fachbereich
-
+
Erwartete Kosten
bei Eigenerstellung
durch den Fachbereich
Erwartete Kosten
bei der Umsetzung
durch IT
+
+
Anteil des
IT-spezifischen Wissens
an der Gesamtaufgabe
+
Overhead durch IT
Vorgaben
Kontrollkosten
Anteil des
Wissens an der
Gesamtaufgabe
+
Spielen Sie Maßnahmen durch:
Was wird passieren, wenn …?
Dr. Ralf Finger
… was man nicht tun sollte.
Dr. Ralf Finger
43
Merkmale Agiler Verfahren
Kostenvorteil bei
Eigenleistung durch den
Fachbereich
-
+
Beispiel:
Erwartete Kosten
bei Eigenerstellung
durch den Fachbereich
Erwartete Kosten
bei der Umsetzung
durch IT
+
+
Anteil des
IT-spezifischen Wissens
an der Gesamtaufgabe
+
Overhead durch IT
Vorgaben
-
Anteil des
Wissens an der
Gesamtaufgabe
+
Kontrollkosten
-
-
Power Programmer
Konzept stärken
Vereinfachte BI
Entwicklungsprinzipien
für FB etablieren
Dr. Ralf Finger
BICC
etablieren
„Agile BI“… und tatsächlich: Es funktioniert!
Dr. Ralf Finger
44
Was heisst hier „Agile“?
Agil ist Synonym für lebhaft, flink, beweglich,
gelenkig, rege, wendig, behände
Agile Entwicklung ist ein Wertesystem.
Agile ist ein Oberbegriff für konkrete Methodiken
Agile Development ist eine Philosophie, ein
Metamodell.
…
Dr. Ralf Finger
Agile Alliance
www.agilealliance.org
Dr. Ralf Finger
45
Das agile Manifest.
http://agilemanifesto.org
Dr. Ralf Finger
Beispiele Agile Entwicklungsmethoden
Verfahren
Schwerpunkt
Projektmanagement
Inkrementelle Entwicklung

Implementierung
Sammlung von Best Practices
und Methodik

Scrum
Extreme
Programming
Feature Driven
Development
(FDD)
Vorgehen

Projektmanagement
Inkrementelle Entwicklung
Aufträge in Product-Backlog
Aufteilung des Vorhabens in 30 Zeittage
umfassende Einheiten („Sprints“)
Priorisierung durch Kunden und Planung in
Sprint Planning Meeting (1 Tag)
Sprint Backlog mit Tasks mit max 16h
Abstimmung in Daily Scrums

Aufteilung des Vorhabens in Releases,
Iterationen und
User Stories bewertet mit Story Points
Entwicklungsschritte sind time-boxed

Big Design Upfront (BDUF)
Erstellung Feature Liste
Features planen und nach Prioritäten
ordnen
Abarbeitung
Weitere: XP@Scrum, Lean Development, Adaptive Software Development
(ASD), Dynamic System Development Method (DSDM), Pramatic
Programming, etc.
Dr. Ralf Finger
46
R
Festlegung der Leistung = Services
Umfassende Definition der Services und
Verantwortlichkeiten
Festlegung für jeden Service
a
st
Ju
Wie vereinbaren wir dies mit den
Anforderungen an BI Services?
r
de
in
em
– Identifikation Service Geber (IT, Wer genau?) und Service
Nehmer (Fachbereich, Wer genau?)
– Zugesicherte Betriebszeiten
– Zugesicherte Reaktionszeiten nach Betriebszeiten
– Zugesicherte Sicherungszyklen und Aufbewahrungsfristen
Ggf. weitere service-spezifische Vereinbarungen
Dr. Ralf Finger
BI Application Stack…
Layer
Aufgabe

Reports
∑
∑
∑
∑
Defintion und Umsetzung von
Reportaufbau und Layout
Berechnete Kennzahlen
Data Marts

Core DWH

Aufbau der Datenmodellle
Implementierung der
Berechnungen und Ableitungen
∑
Implementierung der
Datenintegrationsregeln

Interface
Definition und Umsetzung
Datenanlieferungswege und
Schnittstellen
Operations

Job Scheduling & Monitoring
Backup, Archiving
Operating &
Software System

PC, Server, Netzwerk
Patches, Low-Level Tuning
Tools

Hardware
Physische Bereitstellung PC,
Server, Netzwerk
Wartung, Ausfallsicherheit
Dr. Ralf Finger
47
Das klassische Data Warehouse
Fachbereichsanwendung n
Fachbereichsanwendung 1
Layer
Layer
Aufgabe
Reports

Core DWH
Implementierung der

Interface

Operations
Operating &
Software System

Hardware

Reports

Fachbereich.
Implementierung der

Implementierung der
Data Marts
Aufgabe

Data Marts

…

Core DWH
Implementierung der

Schnittstellen
Interface
Backup, Archiving
Operations
Tools
Operating &
Software System
Server, Netzwerk
Hardware

Schnittstellen
IT
Backup, Archiving
Tools
Server, Netzwerk
Ergebnis: Die IT reguliert nur noch in den Bereichen in denen die Fachbereiche einen
Mehrwert durch die Vorgaben erhalten. Regelungen durch BI Service Vereinbarungen.
Dr. Ralf Finger
Agile BI: Eine neue Sichtweise
Fachbereichsanwendung n
Fachbereichsanwendung 1
Layer
Layer
Aufgabe

Reports

Implementierung der

Data Marts

Core DWH

Interface

Operations
Operating &
Software System

Hardware

Implementierung der
Aufgabe

Implementierung der

…
Core DWH

Schnittstellen
Interface
Backup, Archiving
Operations
Tools
Operating &
Software System
Server, Netzwerk
Hardware

Implementierung der
Alle
Themen bleiben in
Fachbereichshoheit.
Schnittstellen
Backup, Archiving
Tools
Server, Netzwerk
Ziehen Sie alle fachbereichsübergreifend einheitlichen
Themen „vor die Klammer“
(Synergie)
Alle einheitlich zu behandelnden
Themen werden mit strateg.
Technologieentscheidungen
unterlegt
Ergebnis: Die IT reguliert nur noch in den Bereichen in denen die Fachbereiche einen
Mehrwert durch die Vorgaben erhalten. Regelungen durch BI Service Vereinbarungen.
Dr. Ralf Finger
48
Agile BI: Die Herausforderung
Layer
Aufgabe

Reports
Data Marts

Implementierung der

Core DWH

Interface

Operations
Operating &
Software System

Hardware

Implementierung der
Wie kann der Fachbereich
diese Aufgaben
übernehmen und
gleichzeitig wesentliche IT
Anforderungen erfüllen?

Schnittstellen
Backup, Archiving
Tools
Dokumentation
Revisionssicherheit
Regulatorische Vorgaben
Geordneter Release Prozess
Backup
…
Agile BI muss hinsichtlich der
Betriebsorganisation ausdefiniert
sein.
Server, Netzwerk
Dr. Ralf Finger
Betriebsorganisation von Agile BI
Layer
Reports
Data Marts
Core DWH
Aufgabe
Verantwortung
Beispielprozesse

Fachbereich
BI-Team im Fachbereich

Bericht erstellen
Implementierung der Berechnungen
und Ableitungen

Freigabe Fachbereich

Data Mart anpassen
Data Mart erstellen
Ad hoc Data Mart Load

Core DWH erweitern
Schnittstellen

IT Operations

Betriebsüberwachung
Environment Reset
Tool Update
bereitstellen

Interface
Implementierung der
Neue Datenquelle
anbinden

Backup, Archiving

Operations
Operating & Software
System

Tools

IT Operations

Physische Bereitstellung PC, Server,
Netzwerk

IT Operations

Hardware

Month End Sicherung
Dr. Ralf Finger
49
IT
FB Support
FB
Beispielprozess:
Entwicklung neuer Logik
Dr. Ralf Finger
Beispiel:
Deployment of Minor and Major
Changes
Quellsystem Betrieb
Extrakt Programmierer
Power User
Prozessablauf Extraktbereitstellung
V
V
V
Quelle: metaWORKS BI Reference LibraryTM
Dr. Ralf Finger
50
Beispiel:
Reset Changes & Environment
Extrakt Programmierer
Power User
Prozessablauf Extraktbereitstellung
V
V
Quellsystem Betrieb
V
Quelle: metaWORKS BI Reference LibraryTM
Dr. Ralf Finger
Interaktionssequenz Agile BI
ähnlich Spreadmart, aber anders.
Transformationslogiken
Daten laden
Abrufe
von berechneten
Sichten
Fachbereiche übernehmen die gesamte
Entwicklungsarbeit
Die IT baut die Bühne und sichert Services
auf technischer Ebene des BI Application
Stack.
Informationszugriff
Datenmanagement
Dr. Ralf Finger
51
Ihr Ansprechpartner:
Dr. Ralf Finger
INFORMATION WORKS
Tel.: 0221/87075-0
Fax: 0221/87075-11
Email: [email protected]
Dr. Ralf Finger
52