Business Intelligence Gastvortrag von Dr. Stefan Paul an der FH

Business Intelligence
Gastvortrag von Dr. Stefan Paul an der FH Koblenz
6. Mai 2013, 14:00 – 18:00 Uhr
zur Person:
 Jahrgang 1965
 1995 - 1999: Berater bei IDS Scheer
 2000 - heute: Selbständiger IT- und Unternehmensberater
Geschäftsführer der Citi GmbH, Zweibrücken
http://www.citi-gmbh.de/
 SAP Business Warehouse Berater „der ersten Stunde“
 IT-Projektleiter in BI-Projekten bei einem DAX-Unternehmen der chem. Industrie
 Mitglied der IT Governance für BI Projekte
„Dolmetscher zwischen Business und IT“
Seite 1
Inhalt
 Einführung: Big data!
 Business Intelligence
 Data Mining
Ziel ist es, das, was Sie in der „IT Architekturen“-Vorlesung über BI gelernt haben,
- zu vertiefen und zu ergänzen und
- anschaulich zu machen, wo die Herausforderungen in der Praxis liegen
Seite 2
Big Data
Seite 3
Was ist Big data?
 Volume
− das Datenvolumen nimmt immer
mehr zu
 Variety
− semi- und unstrukturierte Daten
gewinnen an Bedeutung
 Velocity
− Realtime bzw. near Realtime
Reporting ist gefordert
 Variability*
− Komplexität von Daten bzw.
Interpretationsoptionen nehmen zu
IBM characterizes Big data
by its volume, variety and velocity – or simply V3
(from “Understanding Big data” IBM eBook)
* Gartner und Forrester haben zu den 3 von IBM eingeführten „V“ eine 4.te Dimension hinzugefügt
Seite 4
Big data: Volume
Chart from Dr. Thomas Keil, SAS;
Original source: I D C - M U L T I M E
DIAWHITEPAPER
As the Economy Contracts, the Digital
Universe Expands, May 2009
 Das Datenvolumen nimmt exponentiell zu
 … was primär an der Zunahme der unstrukturierten Daten liegt
 90% der weltweiten Daten wurden in den letzten beiden Jahren erzeugt*
* Quelle: http://www-01.ibm.com/software/data/bigdata/
Seite 5
Big data: Variety
 Alle Arten von verfügbaren Daten sind relevant zur Entscheidungsfindung
strukturiert
Unternehmensintern
Unternehmensextern
Tabellenkalkulation
Web log-files
(click-stream)
Datenbanken
Smart devices
ERP
Sensordaten
CRM
BI
unstrukturiert*
…
RFID
…
Web Sites
Textdokumente
Intranet
Soziale Netzwerke
Folien/Präsentationen
Marktanalysen/
Meinungen
Emails
…
…
* genauer: un- bzw. semistrukturierte Daten, denn z. B. Emails sind semistrukturiert, da sie eine Absender/Adressat-Struktur besitzen
Seite 6
Strukturierte vs. unstrukturierte Daten
Unternehmensinterne vs. –externe Daten
?
 Neben strukturierten und unternehmensinternen Daten gewinnen in
Unternehmen immer mehr an Bedeutung:
− semi- bzw. unstrukturierte Daten
− unternehmensexterne Daten
Beispiele: bitte zuordnen!
Strukturiert vs.
Unternehmens-
unstrukturiert
intern vs. -extern
Report zum Umsatz pro Produkt, Kunde, Monat
Zusammenfassungen von Kundengesprächen
Geschäftsklima-Index
Markt-Analysen unabhängiger Institute
Kritik bzw. Zustimmung zu Produkten in sozialen Netzwerken
Seite 7
Strukturierte vs. unstrukturierte Daten
Unternehmensinterne vs. –externe Daten
 Neben strukturierten und unternehmensinternen Daten gewinnen in
Unternehmen immer mehr an Bedeutung:
− semi- bzw. unstrukturierte Daten
− unternehmensexterne Daten
Beispiele:
Strukturiert vs.
Unternehmens-
unstrukturiert
intern vs. -extern
Report zum Umsatz pro Produkt, Kunde, Monat
Strukturiert
Intern
Zusammenfassungen von Kundengesprächen
Unstrukturiert
Intern
Strukturiert
Extern
Markt-Analysen unabhängiger Institute
Unstrukturiert
Extern
Kritik bzw. Zustimmung zu Produkten in sozialen Netzwerken
Unstrukturiert
Extern
Geschäftsklima-Index
Seite 8
Big data: Velocity
 Immer mehr Realtime Reporting ist gefordert:
“Decision window small, compared with data and data requirement change rate” *
 “Velocity” steht für folgende Herausforderungen:
− Handling der immer schnelleren Produktion und Änderung von Daten
− Entscheidern benötigen Daten zeitnah (veraltete Daten bringen keinen
Wettbewerbsvorteil)
− Die Anforderungen, welche Daten benötigt werden und in welcher Art und
Weise sie präsentiert werden müssen, ändern sich schnell
* Quelle: Forrester “Expand your digital horizon with big data”
Seite 9
Big data für Unternehmen
 Wenn Unternehmen von Big data profitieren wollen, müssen sie sich z. B. mit
den folgenden Konzepten und den dazugehörigen Technologien beschäftigen:
− Business Intelligence
− Data Mining
− …
 Es ist gut, etwas über Business Intelligence und Data Mining zu lernen
Seite 10
Business Intelligence
1.
2.
3.
4.
5.
6.
7.
8.
Data Warehouse und BI
BI Architektur
OLAP
Close the loop
Typische BI Fragestellungen
Herausforderungen in BI Projekten
IT Trends und BI
Standardisierte vs. agile BI
Seite 11
1. Data Warehouse und BI
Seite 12
Business Intelligence stellt Entscheidungen
auf die Basis von Fakten
„Unter Business Intelligence (BI) versteht man alle Strategien, Prozesse und
Technologien, bei denen aus Daten Informationen und aus Informationen
erfolgskritisches Wissen gewonnen wird, so dass Entscheidungen auf Basis von
Fakten getroffen werden, die Aktionen zur Unternehmens- und Prozesssteuerung
auslösen“
Dr. Wolfgang Martin, 2009
Seite 13
Business Intelligence erhöht den Informationsgrad
Informationsgrad
mit Informationssystem
ohne
Zeit
Quelle: Marcus Reiser, Jan Holthuis
Seite 14
Business Intelligence sorgt dafür, dass Entscheidungen
besser getroffen werden
mit Informationssystem
Informationsgrad
ohne
Gewinn an
Sicherheit
Zeitpunkt der
Entscheidung
Quelle: Marcus Reiser, Jan Holthuis
Zeit
Seite 15
Business Intelligence sorgt dafür, dass Entscheidungen
schneller getroffen werden
mit Informationssystem
Informationsgrad
ohne
Für Entscheidung
notwendiger
Informationsgrad
Gewinn an Zeit
Zeit
Quelle: Marcus Reiser, Jan Holthuis
Seite 16
Unter Business Intelligence versteht man die Analyse von
Daten mit dem Ziel, die Entscheidungsfindung zu unterstützen
Präsentation zur Entscheidungsunterstützung
„Business Intelligence* (Geschäftsanalytik)
… bezeichnet Verfahren und Prozesse zur
systematischen Analyse (Sammlung,
Auswertung und Darstellung) von Daten in
elektronischer Form.
Datenbank
Ziel ist die Gewinnung von Erkenntnissen,
die in Hinsicht auf die Unternehmensziele
bessere operative oder strategische
Entscheidungen ermöglichen.“
Wikipedia
Daten aus
(operativen)
Vorsystemen
* Der englische Ausdruck „intelligence“ bedeutet in diesem
Kontext nicht „Intelligenz“, sondern die aus dem Sammeln und
Aufbereiten erworbener Informationen gewonnenen Erkenntnisse.
Seite 17
Quellsysteme
Analysetools
Data Warehouse
Business Intelligence
BI Architektur – Übersicht
Präsentation zur Entscheidungsunterstützung
DW
Datenbank
 In der Data-Warehouse-Datenbank
werden die Daten aus den (operativen)
Quellsystemen
− gesammelt
− aufbereitet bzw. verwaltet
− nachgelagerten Analysetools zur
Verfügung gestellt
Verwaltung
ETL: Extract,
Transform
& Load
 Entscheider im Unternehmen greifen über
Spreadsheets, Dashboards oder andere
Analysetools auf die Daten zu
Daten aus
(operativen)
Vorsystemen
 … und finden damit Hilfestellungen für
ihre Entscheidungsfindung
Wichtig: Eine BI Lösung ist kein Produkt
sondern ein Konzept, das unternehmensindividuell umgesetzt werden muss.
Seite 18
Data Warehouse Definition gemäß Bill Inmon
„A Data Warehouse is a subject oriented, integrated, non volatile and time variant
collection of data in support of management decisions.“
 Collection of data in support of management decisions
Datensammlung mit der Zielrichtung Entscheidungsunterstützung
 Subject oriented
Die im DW gespeicherten Daten orientieren sich an den Inhalten bzw. Themen
der Informationsbedarfe der Entscheider
 Integrated
Im DW werden Daten aus heterogenen unternehmensinternen und -externen
Vorsystemen in einer einheitlichen Datenbasis zusammenzuführt (wobei z. B.
unterschiedliche Formatierungen vereinheitlicht werden)
 Non volatile (nicht flüchtig)
Während in den operativen Systemen die Daten sehr häufig aktualisiert werden,
bleiben die einmal im DW gespeicherten Daten unverändert bzw. „eingefroren“
 Time variant
Um zeitliche Trends analysieren zu können, ist es wichtig, dass die Daten einen
Zeitraumbezug haben, also aus ihnen jeweils ersichtlich ist, auf welchen Zeitraum
Seite 19
in der Vergangenheit sie sich beziehen.
OLAP vs. OLTP
?
 Während die operativen, transaktionsorientierten Anwendungen
(Online Transaction Processing, OLTP) Prozesse wie die Auftragsbearbeitung,
das Bestellwesen oder die Finanzbuchhaltung unterstützen
 … besteht das Ziel von analytischen bzw. Data-Warehouse-basierten
Anwendungen (Online Analytical Processing, OLAP) darin, die Entscheider im
Unternehmen mit Informationen zu versorgen
Ziel
Anwender
OLTP
(operativ)
Leistungserbringung
OLAP
(analytisch)
Entscheidungsunterstützung
Sachbearbeiter
Entscheider
Detaillierung
Zeitbezug
Aktualisierung
Seite 20
OLAP vs. OLTP
 Während die operativen, transaktionsorientierten Anwendungen
(Online Transaction Processing, OLTP) Prozesse wie die Auftragsbearbeitung,
das Bestellwesen oder die Finanzbuchhaltung unterstützen
 … besteht das Ziel von analytischen bzw. Data-Warehouse-basierten
Anwendungen (Online Analytical Processing, OLAP) darin, die Entscheider im
Unternehmen mit Informationen zu versorgen
Ziel
Anwender
Detaillierung
Zeitbezug
Aktualisierung
OLTP
(operativ)
Leistungserbringung
OLAP
(analytisch)
Entscheidungsunterstützung
Sachbearbeiter
Entscheider
sehr granular
(Einzelbelege)
aktuell
(zeitpunktbezogen)
kontinuierlich, in Echtzeit
verdichtete Daten
historisch
(zeitraumbezogen)
turnusmäßige Fortschreibung
(oft vortagesaktuelle Daten)
Seite 21
2. BI Architektur
Seite 22
Quellsysteme
Analysetools
Data Warehouse
Business Intelligence
BI und Data Warehouse Architektur
Präsentation zur Entscheidungsunterstützung
Eine BI Architektur besitzt im Wesentlichen
die folgenden Komponenten:
 Analysetools
DW
Datenbank
Verwaltung
ETL: Extract,
Transform
& Load
 Data Warehouse mit
− den Extract, Transform & LoadFunktionalitäten (ETL)
− der Data-Warehouse-Datenbank
− den Verwaltungsfunktionalitäten
 Vor- bzw. Quellsysteme
Daten aus
(operativen)
Vorsystemen
(gehören im weiteren Sinne auch zur BI Architektur,
da sie die Basis für die BI Anwendungen sind)
Abgrenzung (vereinfacht): BI = DW + Analysetools
Seite 23
Quellsysteme
Vorsysteme (bzw. Quellsysteme)
Daten aus
(operativen)
Vorsystemen
 Den Schwerpunkt bilden operative,
unternehmensinterne OLTP-Anwendungen
 Immer mehr Relevanz bekommen aber
z. B. auch:
− externe Daten zu z. B. Währungskursen, Ölpreisentwicklung usw.
− externe Stammdaten wie z. B. die über
Wirtschaftsdienste verfügbare
Zuordnung von Kunden zu
Kundensegmenten (die den
Entscheidern helfen, ein Gesamtbild
der Marktsituation zu bekommen)
Seite 24
Quellsysteme
Data Warehouse
Extract, Transform & Load
DW
Datenbank
ETL: Extract,
Transform
& Load
Daten aus
(operativen)
Vorsystemen
Verwaltung
 Ziel von ETL ist es,
− Daten aus den Vorsystemen zu
extrahieren
− in eine einheitliche Datenbasis zu
transformiert
− Harmonisierung von Feldern aus
heterogenen Quellen (Struktur- und
Formatvereinheitlichungen)
− Daten-Qualitätskontrollen
− in die Data Warehouse-Datenbank
abzuspeichern, typischerweise in
täglichen Ladeprozeduren
 Je nach Anzahl und Heterogenität der
Vorsysteme kann ETL sehr komplex sein
Seite 25
ETL: Beispiele für Plausibilitätsprüfungen
 Datensätze werden als fehlerhaft markiert, wenn sie z. B.:
− keinen Eintrag bei Kunde und Material (Artikel) besitzen
− unlogische Datumsfelder besitzen
(z. B. kann ein Liefertermin nicht vor dem Termin liegen, an dem der dazugehörige Auftrag angelegt wurde)
− einen unrealistische hohen Warenwert besitzen
Auftrag 4711
angelegt am 1.1.2012
Artikel 0815
Kunde 1234
Liefertermin 10.1.2012
Warenwert 20 €

Auftrag 4712
angelegt am 1.1.2012
Artikel 0816
Kunde 3456
Liefertermin 10.1.2012
Warenwert 50 €

Auftrag 4713
angelegt am 1.1.2012
Artikel 0817
-
Liefertermin 10.1.2012
Warenwert 10 €

Auftrag 4714
angelegt am 1.1.2012
Artikel 0818
Kunde 5566
Liefertermin 1.12.2011
Warenwert 20 €

Auftrag 4715
angelegt am 1.1.2012
Artikel 0819
Kunde 3344
Liefertermin 10.1.2012
Warenwert 1.000.000 €

Auftrag 4711
angelegt am 1.1.2012
Artikel 0815
Kunde 1234
Liefertermin 10.1.2012
Warenwert 20 €
Auftrag 4712
angelegt am 1.1.2012
Artikel 0815
Kunde 3456
Liefertermin 10.1.2012
Warenwert 50 €
Auftrag 4713
angelegt am 1.1.2012
Artikel 0815
-
Liefertermin 10.1.2012
Warenwert 10 €
Auftrag 4714
angelegt am 1.1.2012
Artikel 0815
Kunde 5566
Liefertermin 1.12.2011
Warenwert 20 €
Auftrag 4715
angelegt am 1.1.2012
Artikel 0815
Kunde 3344
Liefertermin 10.1.2012
Warenwert 1.000.000 €
Seite 26
Quellsysteme
Data Warehouse
Data Warehouse Datenbank
DW
Datenbank
ETL: Extract,
Transform
& Load
Daten aus
(operativen)
Vorsystemen
Verwaltung
Vorteile einer separaten DWH Datenbank
(gegenüber Auswertungen direkt im OLTP):
 Entlastung der operativen Systeme von
umfangreichen Abfragen: Reports können
sehr aufwendig sein und massiv Systemressourcen binden  es besteht die Gefahr,
dass ein OLTP dadurch gebremst würde
 Für Abfragen optimierte Datenhaltung:
Einsatz spezieller, für Auswertungen
optimierte Datenbankmodelle (bewusst
redundante Datenhaltung, Aggregationen)
 Zusammenführung von Daten aus mehreren
Quellen: Oft müssen für aussagekräftige
Reports die Daten aus mehreren
Quellsystemen (aus verschiedenen
Regionen, Unternehmensbereichen,
Aufgabengebieten) kombiniert werden
Seite 27
Quellsysteme
Data Warehouse
Datenverwaltung im DWH
DW
Datenbank
ETL: Extract,
Transform
& Load
Daten aus
(operativen)
Vorsystemen
Verwaltung
 In der Data Warehouse Verwaltung werden
− Datenflüsse aus den Vorsystemen ins
DWH initiiert, gesteuert und überwacht
− historische Daten, die den relevanten
Betrachtungsbereich der Vergangenheit
überschritten haben, archiviert oder
gelöscht
− Zugriffsrechte verwaltet
− usw.
Seite 28
Quellsysteme
Analysetools
Data Warehouse
Business Intelligence
Analysetools
Präsentation zur Entscheidungsunterstützung
Dashboard
Spreadsheet
DW
Datenbank
ETL: Extract,
Transform
& Load
Daten aus
(operativen)
Vorsystemen
OLAP
Data Mining
Verwaltung
Zur Präsentation und Analyse der Daten
kommen unterschiedlichste Tools zum Einsatz:
 Dashboards: analog zu einer Instrumententafel werden Informationen kombiniert und
graphisch aufbereitet; Ziel ist es, möglichst
viel auf einen Blick zu überschauen
 Spreadsheets bzw. TabellenkalkulationsProgramme: am bekanntesten ist MS Excel
 OLAP Tools: hier stehen OLAP Navigationsmöglichkeiten im Vordergrund (oft als WEBoder Excel-basiertes Tool implementiert)
 Data Mining Tools: für die Suche nach
bisher unentdeckte und betriebswirtschaftlich relevante Muster in großen
Datenbeständen
Außerdem: Erzeugung elektronischer Listen
zur Datenverteilung an nachgelagerten
Anwendungen
Seite 29
3. OLAP
Seite 30
OLAP
 Typische BI Fragestellungen sind einfach strukturiert; sie sind „subject oriented“,
also auf die Subjekte bzw. Kategorien, in denen Entscheider denken, ausgerichtet
− Merkmale (= Dimensionen): Themen, nach denen man etwas analysiert
− Kennzahlen: quantitativen Informationen, die man auswerten möchte
 Typische Fragestellungen sind: Wie entwickeln sich bestimmte Kennzahlen
(Absatz, Umsatz, Preise usw.*) in Bezug auf bestimmte Merkmale
(Kunden, Produkte, Zeit usw.)?
 Visualisiert wird dieser Sachverhalt oft
mit einem Würfel (Cube):
− Merkmale sind die Kanten
(Dimensionen) des Würfels
− Kennzahlen stehen in Würfelzellen
Produkt
Umsatz
Umsatz:
x Mio €
A380
x Mio €
A350
Air France
Lufthansa
A320
* neben Kennzahlen wir Mengen, Werte und Preise sind auch
die Anzahl von Kundenbeschwerden oder die Anzahl an Tagen,
die eine Lieferung verspätet ist, typische BI-Kennzahlen
Qantas
2008
2009
2010
Zeit
Seite 31
OLAP-Navigation: Slice & Dice
Navigieren in den Daten entspricht dem Drehen, Wenden und Durchschneiden des
OLAP-Würfels: Slice bezeichnet dabei das Herausschneiden von Würfelscheiben
 … was bedeutet, dass man z. B. nur den Kunden Lufthansa herausschneidet:
Produkt
Produkt
Umsatz
x Mio €
A380
A350
Air France
Lufthansa
A320
Qantas
2008
2009
2009
46
A350
2010
47
Summe
120
Air France
Lufthansa
A320
2010
Zeit
Zeit
2008
Absatz
27
Umsatz
x Mio €
A380
Qantas
2008
Filter auf
Kunde = Lufthansa
2009
Zeit
2008
Absatz
10
2010
2009
17
Zeit
2010
16
Summe
43
Seite 32
OLAP-Navigation: Slice & Dice
Navigieren in den Daten entspricht dem Drehen, Wenden und Durchschneiden des
OLAP-Würfels: Dice bezeichnet dabei das Drehen des Blickwinkels
 … was bedeutet, dass man z. B. statt dem zeitlichen Verlauf die Produkte zeigt:
Produkt
Zeit
Umsatz
x Mio €
A380
A350
Air France
Lufthansa
A320
Qantas
2008
Zeit
Absatz
2009
2008
10
2010
2009
17
2010
16
Umsatz
x Mio €
2010
Zeit
Summe
43
Zeitlicher Trend 
Produktaufteilung
2009
Air France
Lufthansa
2008
Qantas
A320
A350
A380
Produkt
Absatz
A320
20
A350 A380 Summe
13
10
43
Produkt
Seite 33
OLAP-Navigation: Drill-down & Roll-up
Drill-down bedeutet, dass man die Daten detaillierter untersucht, also z. B.:
 statt dem Jahresverlauf die Absatzzahlen pro Quartal oder Monat anzeigt
 statt Lufthansa komplett zu sehen, die Standorte einzeln aufzuführen
Roll-up ist die Gegenbewegung zu drill-down (zurück auf höhere Aggregationsebenen)
Produkt
Produkt
Umsatz
x Mio €
A380
A380
A350
Air France
Lufthansa
A320
Qantas
2008
Zeit
Absatz
2009
2008
10
2010
2009
17
2010
16
Zeit
Summe
43
Jahresverlauf 
Quartalsverlauf
Umsatz
x Mio €
A350
Air France
Lufthansa
A320
Qantas
2010
2008
2009
Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4
Zeit
2008
2009
2010
Zeit (Jahr,
Summe
Quartal) 1 2 3 4 1 2 3 4 1 2 3 4
Absatz 2 2 4 2 5 4 3 5 4 4 4 4
43
Seite 34
Beispiel für Drill-Down, Slice & Dice
Beispiel-Werte sind
frei erfunden
Seite 35
Beispiel für Drill-Down, Slice & Dice
Beispiel-Werte sind
frei erfunden
Seite 36
Beispiel für Drill-Down, Slice & Dice
Beispiel-Werte sind
frei erfunden
Seite 37
Beispiel für Drill-Down, Slice & Dice
Beispiel-Werte sind
frei erfunden
Seite 38
Beispiel für Drill-Down, Slice & Dice
Beispiel-Werte sind
frei erfunden
Seite 39
OLAP Beispiel
?
 Wie sieht OLAP in einer realen Anwendung aus?
Seite 40
4. ”Close the loop“
Seite 41
Stammdaten
Quellsysteme
Analysetools
Data Warehouse
Business Intelligence
Stammdaten  Bewegungsdaten  Informationen
Präsentation zur Entscheidungsunterstützung
Informationen helfen dabei,
strategische und operative
Entscheidungen zu treffen …
DW
Datenbank
Verwaltung
Extract,
Transform
& Load
Daten aus
Vorsystemen
Material
Kunde,
Lieferant
etc.
Seite 42
Stammdaten
Quellsysteme
Analysetools
Data Warehouse
Business Intelligence
Stammdaten  Bewegungsdaten  Informationen
„Close the loop”
Präsentation zur Entscheidungsunterstützung
Informationen helfen dabei,
strategische und operative
Entscheidungen zu treffen …
DW
Datenbank
Verwaltung
Extract,
Transform
& Load
… und sie helfen bei der
Optimierung der Prozesse …
Daten aus
Vorsystemen
… und bei der Harmonisierung
der Stammdaten
Material
Kunde,
Lieferant
etc.
Seite 43
Close the loop
 Unter dem „closed loop“-Ansatz versteht man, dass die aus dem BI-Reporting
gewonnenen Erkenntnisse nicht nur dazu dienen, gute Entscheidungen im Blick
auf den Markt und den Verkauf der Produkte zu treffen
− sondern auch dazu, die Unternehmensprozesse kontinuierlich zu optimieren
− und Probleme im Bereich der Stammdaten zu analysieren und zu beheben
Beispiele:
 Prozessoptimierung: Wird z. B. festgestellt, dass Kunden regelmäßig zu spät
beliefert werden, können die Supply-Chain-Prozesse untersucht werden, um
festzustellen, wie man diese Prozesse optimieren muss, um die Lieferzuverlässigkeit zu verbessern
 Stammdatenharmonisierung: Stellt man im BI-Reporting fest, dass Produkte zu
zwei verschiedenen Kunden mit identischer Adresse geliefert werden, sollte man
hinterfragen, ob ein Stammdaten-Fehler vorliegt und es sich eigentlich um nur
einen Kunden handelt, der aber eventuell zu unterschiedlichen Zeiten von
unterschiedlichen Mitarbeitern zweimal angelegt wurde
Seite 44
5. Typische
BI Fragestellungen
Seite 45
Typische BI Fragestellungen
… und ihr möglicher Nutzen – Teil 1
Typische Fragen
 Wie haben sich Absatzmenge und Umsatzwert bezogen auf die verschiedenen
Produktbereiche in den letzten Monaten in den verschiedenen Regionen
entwickelt?
 Mit welchen Kunden mache ich den meisten Umsatz?
 Über welche Produkte erwirtschafte ich den höchsten Deckungsbeitrag?
Möglicher Nutzen
 Die für das Unternehmen besonders wichtigen Kunden werden identifiziert
(Kunden mit hohem Umsatz in lukrativen Geschäftsfeldern)
 diese Kunden können bei Produktionsengpässen bevorzugt bedient werden
 Bei einem Absatzrückgang in einer bestimmten Region oder in einem bestimmten
Produktsegment kann frühzeitig gegengesteuert werden (zum Beispiel durch
gezielte Werbemaßnahmen oder durch Preisreduktionen).
Seite 46
Typische BI Fragestellungen
… und ihr möglicher Nutzen – Teil 2
Typische Fragen
 Welche Rohstoffe bestellen wir monatlich in welchen Mengen bei unseren
wichtigsten Lieferanten?
Möglicher Nutzen
 Abhängigkeiten von Lieferanten können erkannt bzw. verhindert werden, so dass
man beim Ausfall eines Lieferanten ober bei Änderungen in dessen Preispolitik
zeitnah auf Alternativen zugreifen kann
Seite 47
Typische BI Fragestellungen
… und ihr möglicher Nutzen – Teil 3
Typische Fragen
 Wie zuverlässig ist meine Supply Chain in Bezug auf die pünktliche Ablieferung
der Waren beim Kunden?
 Wie viele Beschwerden von Kunden gehen pro Monat ein und worüber
beschweren sich die Kunden?
Möglicher Nutzen
 Verspätete Lieferungen, die zu Unzufriedenheit auf Kundenseite führen, sind
frühzeitig bekannt und es können Maßnahmen ergriffen werden, die
Lieferzuverlässigkeit zu verbessern – idealerweise bevor es zu
Kundenbeschwerden kommt.
Seite 48
Einige Aussagen zu Kennzahlen
 „Roughly right is better than precisely wrong“ Carveth Read
− Nicht über betriebswirtschaftlich irrelevante „Nachkommastellen“ diskutieren,
weil man dabei ev. die wichtigen Dinge (die großen Trends) übersieht!
− Gilt nicht für Auswertungen in der Finanzbuchhaltung (dort muss es exakt sein)
 Kennzahlen beeinflussen sich gegenseitig
− Wenn die Lagerreichweite sinkt ( reduzierte Lagerhaltungskosten,
weniger gebundenes Kapital)
− sinkt typischerweise auch die Lieferfähigkeit und Lieferzuverlässigkeit
(und damit auch die Kundenzufriedenheit)
 Welche Kennzahlen sind eigentlich wichtig? Beispiel:
− Absatz steigt  sehr gut, ich verkaufe mehr!
− Umsatz steigt  noch besser, denn ich verkaufe mehr teure Produkte!
− Deckungsbeitrag und Profit steigen  erst jetzt bin ich sicher, dass es gut läuft!
− Es bleibt die Frage, ob ich auch in den richtigen Märkten* wachse?
* bei zukunftsträchtigen Produkte und Kunden
Seite 49
6. Herausforderungen in BI Projekten
i.
ii.
iii.
iv.
v.
Das Team (Facheinheit und IT)
Fachliche Anforderungen
Tools
Prototyp
Go Live und was dann?
Seite 50
BI scheint eine einfache Thematik zu sein
… trotzdem laufen viele BI Projekte schief
 BI scheint eine relativ
einfache Thematik zu sein:
Daten sammeln, verwalten
und präsentieren  That‘s it!
Präsentieren
Verwalten
Sammeln
 Trotzdem laufen viele BI Projekte schief:
“Gartner says more than 50 percent of Data Warehouse projects will have
limited acceptance or will be failures”
Gartner Press release 2005
 Wo liegt das Problem?
Seite 51
Wo liegen die Probleme bzw. Herausforderungen?
Phasen eines typischen BI Projektes
Projektstart
- Ziele*
- Sponsoren
- Team
Analyse der
fachlichen
Anforderungen
Toolauswahl
Prototyp
Entwicklung
Post
Go-Live
* welche "Entscheider" sollen bei der Verrichtung
welcher betriebswirtschaftlichen Aufgaben unterstützt werden
und welche Informationen benötigt man dazu?
 Einige Herausforderungen in BI Projekten werden näher betrachtet
Seite 52
6. Herausforderungen in BI Projekten
i.
ii.
iii.
iv.
v.
Das Team (Facheinheit und IT)
− Rollenabgrenzung
− gemeinsame Sprache
− Kommunikation
Fachliche Anforderungen
Tools
Prototyp
Go Live und was dann?
Seite 53
Die Rollen/Aufgaben müssen
zwischen Facheinheit und IT klar abgegrenzt sein
 Wenn die Facheinheit Aufgaben der IT übernimmt und z.B. selbst programmiert
oder über Tabellen-Logiken entscheidet
- ... werden die Anwendungen oft nicht in das Support-Konzept eingebunden
 wer kümmert sich um die Pflege, Korrektur und Erweiterung der
Anwendung, um die Rückmeldung zu User-Anfragen, etc. ?
- ... sind die Anwendungen oft auf einzelne Einheiten
beschränkt, folgen also keinem zentralen Ansatz
 Synergien gehen verloren
 Wenn die IT Fach-Aufgaben übernimmt (z.B. Fachkonzept-Details festlegt) ...
- ... verstehen die Facheinheiten ev. die Details der Anwendung nicht
 die Anwendung findet keine Akzeptanz
Seite 54
Die Rollen/Aufgaben müssen
zwischen Facheinheit und IT klar abgegrenzt sein
 Konflikte in der Aufgabenverteilung zwischen Facheinheit und IT basieren oft
auf betrieblichen Rahmenbedingungen wie z.B.:
- Mitarbeiter sind überlastet
 jeder versucht Arbeit abzuschieben
- Mitarbeiter sorgen sich um ihre Aufgaben
 und verbitten sich Eingriffe in ihren
Kompetenz-Bereich
Seite 55
Gemeinsame Sprache: Mitarbeiter der Facheinheit
benötigen ein Grundverständnis zu IT-Themen
 Zum Beispiel sollten Facheinheiten Mitarbeiter einige Grundbegriffe der
Datenmodellierung verstehen, wie z.B.:
- Bewegungsdaten
Beleg 4711
bestellt am 1.1.2010
Artikel 0815
Warenempfänger 1234
10 KG
20 €
Seite 56
Gemeinsame Sprache: Mitarbeiter der Facheinheit
benötigen ein Grundverständnis zu IT-Themen
 Zum Beispiel sollten Facheinheiten Mitarbeiter einige Grundbegriffe der
Datenmodellierung verstehen, wie z.B.:
- Bewegungsdaten vs. Stammdaten
Beleg 4711
bestellt am 1.1.2010
Artikel 0815
Warenempfänger 1234
10 KG
20 €
Name: Müller GmbH
Ort: Bielefeld
Land: Deutschland
Branche: Automobile
werden regelmäßig
aktualisiert
(täglich, wöchentlich)
Seite 57
Gemeinsame Sprache: Mitarbeiter der Facheinheit
benötigen ein Grundverständnis zu IT-Themen
 Zum Beispiel sollten Facheinheiten Mitarbeiter einige Grundbegriffe der
Datenmodellierung verstehen, wie z.B.:
- Nummern-Ergänzungen (Compounding) zur Vermeidung von Kollisionen
Beleg 4711
bestellt am 1.1.2010
Artikel 0815
Warenempfänger 01/1234
10 KG
20 €
Name: Müller GmbH
Ort: Bielefeld
Beleg 4713
bestellt am 1.2.2010
Artikel 1111
Warenempfänger 02/1234
10 KG
20 €
Name: Smith Inc.
bei einer hinzugekauften Firma
aus GB werden die identischen
Kundennummern verwendet
 aber für andere Kunden
Ort: London
Seite 58
Gemeinsame Sprache: Mitarbeiter der Facheinheit
benötigen ein Grundverständnis zu IT-Themen
 Zum Beispiel sollten Facheinheiten Mitarbeiter verstehen,
- … dass es Performance-Restriktionen gibt
 man kann nicht beliebig viele Daten beliebig schnell bereitstellen!
viel
schnell
- … dass es in der IT Arbeit „Aufwandstreiber“ gibt
 Dinge, die relativ einfach klingen, können technisch sehr aufwändig sein!
Seite 59
Gemeinsame Sprache: Mitarbeiter der IT benötigen ein
Grundverständnis der Arbeit der Facheinheit
 Zum Beispiel sollten IT-Mitarbeiter ein Grundverständnis der Arbeit der
Facheinheit haben zu Themen wie:
- Prozess-Know-how: Wie sind Prozesse konzipiert bzw. implementiert, aus
denen das BI Tool die Daten bezieht?
- Was sind die wesentlichen Kennzahlen, die bereitgestellt werden sollen
- und wofür werden sie verwendet?
Seite 60
Gemeinsame Sprache: es geht um einen groben
Überblick und nicht um die Details
 Es kommt zu Frustration und Missverständnissen
- wenn die IT die Facheinheit mit IT-Ausdrücken überfordert
- wenn die Facheinheit die IT Kollegen nicht zumindest in die Grundzüge der
fachlichen Hintergründe der Anforderung einweiht
 Wo es nötig ist, muss jemand (Projektleitung, Berater, etc.) übersetzen!
Business – IT
IT – Business
Seite 61
Gemeinsame Sprache: es geht um einen groben
Überblick und nicht um die Details
 Facheinheit und IT müssen „ihre“ Themen so weit veranschaulichen und
vereinfachen, dass ein gemeinsames Gespräch und gemeinsame
Entscheidungen möglich werden
„Wahrheit und Klarheit sind komplementär!“
100% Klar
„das Programm ist fehlerhaft“
 ziemlich klar!
100% Wahr
„im Function Module XY führt
eine fehlende If-Anweisung dazu,
dass in ca. 10% aller Fälle ein falscher
Datums-Wert an das übergeordnete
Programm übergeben wird...“
 näher an der „Wahrheit“
Seite 62
Offene Kommunikation & gegenseitiges Vertrauen sind
essentiell für den Projekterfolg
 Es muss möglich sein, die Aussagen der jeweils anderen Einheit zu hinterfragen
 die Aussage „das versteht Du eh nicht“ hilft hier nicht weiter!
 Gleichzeitig muss es in der Zusammenarbeit eine Vertrauensbasis geben (nicht
jede Aussage, die unangenehm ist, sollte hinterfragt werden)
Zwei Beispiele:
Wenn die IT zur Umsetzung einer Anforderung
nur 2 technische Optionen sieht (mit Vor.- und
Nachteilen), ist es nicht hilfreich, wenn die
Facheinheit darauf drängt, dass nach einer
Option 3 (ohne Nachteile) gesucht wird
-
Wenn die Facheinheit eine technisch schwierig
zu ermittelnde Information zwingend für ihr
Reporting benötigt, ist es nicht hilfreich,
wenn die IT den betriebswirtschaftlichen
Mehrwert dieser Information in Frage stellt
Seite 63
Das Team: Zusammenfassung
 Die Rollen/Aufgaben müssen zwischen Facheinheit und IT klar abgegrenzt sein
 Facheinheit-Mitarbeiter benötigen ein Grundverständnis zu IT-Themen …
… und umgekehrt
 Die Kommunikation lebt davon, dass jeder einen groben Einblick in die Arbeit
der anderen Einheit hat  es geht nicht um die Details!
 Offene Kommunikation und gegenseitiges Vertrauen sind essentiell
 Man kann nur erfolgreich sein, wenn alle das gleiche Ziel verfolgen
Seite 64
6. Herausforderungen in BI Projekten
i. Das Team (Facheinheit und IT)
ii. Fachliche Anforderungen
− Unterschiedliche Sichten
− Implizite Logik
− Abgeleitete Merkmale
− Beschränkung auf das Wesentliche
− Datenqualität
iii. Tools
iv. Prototyp
v. Go Live und was dann?
Seite 65
Anforderungen – unterschiedliche Sichten
Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht:
Absatzzahlen – pro Warengruppe – pro Land – pro Monat
Seite 66
Anforderungen – unterschiedliche Sichten
Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht:
Absatzzahlen – pro Warengruppe – pro Land – pro Monat
 Hier müssen z.B. folgende Details geklärt werden:
- Absatzzahlen: Alle Absätze oder nur die Absätze mit „echten“ Kunden?
- pro Warengruppe: welche Artikel gehören zu dieser Warengruppe und:
ist die Gruppierung gemäß aktueller Sicht zu erstellen?
- pro Land: Land der Vertriebseinheit oder Land des Kunden?
- pro Monat: basierend auf welchem Datum?
Seite 67
Anforderungen – unterschiedliche Sichten
Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht:
Absatzzahlen – pro Warengruppe – pro Land – pro Monat
 Dazu sagt der Vertriebschef
- alle Absätze – auch die Verkäufe an Händler, die zum Konzern gehören
- auch historische Daten sollen so gezeigt werden, als wäre die aktuelle
Waren-Gruppierung schon immer gültig gewesen
- bezogen auf das Land des Kunden, der die Ware geliefert bekommt
- basierend auf Auftragsanlagedatum
Seite 68
Anforderungen – unterschiedliche Sichten
Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht:
Absatzzahlen – pro Warengruppe – pro Land – pro Monat
 Dazu sagt der Finanzchef
- nur Absätze mit „echten“ Kunden
- historische Daten sollen so gezeigt werden bzw. in Warengruppen
eingeordnet sein, wie sie zum Zeitpunkt der Belegerstellung gruppiert waren
- bezogen auf das Land des Kunden, der die Ware bezahlt
- basierend auf Rechnungsdatum
Seite 69
Anforderungen – unterschiedliche Sichten
Beispiel 1: Die Facheinheit einer Brauerei möchte folgenden Bericht:
Absatzzahlen – pro Warengruppe – pro Land – pro Monat
 jede Menge Klärungs- bzw. Detaillierungsbedarf
 unterschiedliche Antworten aus unterschiedlichen Abteilungen
Seite 70
Anforderungen – implizite Logik
Beispiel 2: Die Facheinheit eines Industriebetriebes möchte folgenden Bericht:
Lieferzuverlässigkeit – pro Transportart – pro Land – pro Monat
 Auch hier müssen die Merkmale Transportart, Land, Monat detailliert werden
 Zusätzlich muss hier geklärt werden:
- Basierend auf der Definition der Lieferzuverlässigkeit =
Anzahl pünktliche Lieferungen / Anzahl alle Lieferungen
 was ist „pünktlich“, welche Verspätung ist noch OK?
Im Verständnis der Facheinheit ist die Interpretation, ob eine Lieferung
pünktlich ist oder nicht, abhängig von der Transportart:
See: +/- 3 Tage Toleranz
LKW: 0 Tage Toleranz
Seite 71
Anforderungen – implizite Logik
„pünktlich“ ist abhängig von der Transportart
80
30
See: +/- 3 Tage Toleranz
15
15
10
10
1
4
5
5
- 3 Tage
LKW: 0 Tage Toleranz
Zugesagter
Eintreff-Termin
4
+ 3 Tage
Lieferzuverlässigkeit im See-Verkehr:
90 pünktliche Lieferungen
100 Lieferungen insgesamt
= 90 %
1
1
1
2
- 3 Tage
3
3
3
3
Zugesagter
Eintreff-Termin
2
1
1
+ 3 Tage
Lieferzuverlässigkeit im LKW-Verkehr:
80 pünktliche Lieferungen
100 Lieferungen insgesamt
= 80 %
Seite 72
Anforderungen – implizite Logik:
3 Implementierungs-Optionen
Abhängigkeit der Pünktlichkeit von der Transportart ist in Anwendung implementiert
80
30
See: +/- 3 Tage Toleranz
15
15
10
10
1
4
5
5
- 3 Tage
LKW: 0 Tage Toleranz
Zugesagter
Eintreff-Termin
+ 3 Tage
4
1
1
1
2
- 3 Tage
3
3
3
Zugesagter
Eintreff-Termin
3
2
1
1
+ 3 Tage
 Option 1: Die Anwendung berücksichtigt bei Berechnung der Lieferzuverlässigkeit
automatisch die unterschiedlichen Toleranzen  implizite Logik
 Zum Verständnis der Daten muss der User bedenken, dass diese Logik in die
Berechnung eingebaut ist
Seite 73
Anforderungen – implizite Logik:
3 Implementierungs-Optionen
Implementiert ist eine 0 Tage Toleranz für alle Transportarten
80
30
15
15
10
10
1
4
5
5
- 3 Tage
Zugesagter
Eintreff-Termin
+ 3 Tage
4
1
1
1
2
- 3 Tage
3
3
3
Zugesagter
Eintreff-Termin
3
2
1
1
+ 3 Tage
 Option 2: Toleranz wird für alle Transportarten auf „0 Tage“ gesetzt
 Zum Verständnis der Daten muss der User berücksichtigen, dass im SeeVerkehr eine geringere Pünktlichkeit zu erwarten ist
Seite 74
Anforderungen – implizite Logik:
3 Implementierungs-Optionen
Die Toleranz ist variabel (kann vom User individuell festgelegt werden)
80
30
15
15
10
10
1
4
5
5
- 3 Tage
Zugesagter
Eintreff-Termin
+ 3 Tage
4
1
1
1
2
- 3 Tage
3
3
3
Zugesagter
Eintreff-Termin
3
2
1
1
+ 3 Tage
 Option 3: der User kann die Toleranz selbst einstellen
 damit besteht z.B. die Möglichkeit, See-Transporte mit +/- 3 oder mit +/- 0
Tagen auszuwerten
Seite 75
Anforderungen – implizite Logik
 Implizite Logik (Option 1) hat Vorteile:
- Einheitliche, standardisierte und vergleichbare Interpretation der Daten
- User müssen sich um nichts kümmern
 Nachteile:
- Verlust an Flexibilität
- Mögliche Missverständnisse, wenn Regeln nicht bekannt sind
 Wieso wird ein 2 Tage verspäteter Transport manchmal als „pünktlich“ bewertet
und manchmal als „unpünktlich“?
 Implizite Logik kann sehr hilfreich sein …
 … funktionieren aber nur, wenn sie global anerkannt und verstanden ist
 Flexibilität darf nicht verloren gehen
 daher z.B. in globalen Standard-Berichten Logik einbauen, aber für Experten
die Option erhalten, diese Regeln auch auszuschalten bzw. selbst festzulegen
Seite 76
Anforderungen – abgeleitete Merkmale
Beispiel 3: Absatzmenge aller über eCommerce angelegten Aufträge
 Die Info „Auftrag wurde über eCommerce-Vertriebskanal angelegt“ ist nicht
global einheitlich über ein Feld erkennbar
 Abgeleitetes Merkmale „eCommerce-Kennzeichen“ mit Definition
- Quelle 1: Verkaufsbelegart = x1, x3 oder x7
- Quelle 2: Vorgängerbelegart des Auftrages = y1
 Aufgabe von abgeleiteten Merkmalen
1. Verdichten bzw. vereinfachen:
x1, x3, x7 = eCommerce
2. Harmonisieren:
eCommerce ist in Quelle 1
anders definiert als in Quelle 2
eCommerce ja / nein
Verkaufsbelegarten:
x1, x2, x3, x4, x5
x6, x7, x8, x9, x10
Vorgängerbelegart:
y1, y2,, y3, y4
Seite 77
Anforderungen – abgeleitete Merkmale
 Problemfelder bei abgeleiteten Merkmalen
- Neue Begrifflichkeiten müssen geschult und etabliert werden
- Information lässt sich nicht 1:1 im ERP-Quellsystem überprüfen
- Qualität der Information steht und fällt damit, dass Mapping-Tabellen aktuell
gehalten werden
- Wenn Zuordnungen geändert werden (z.B. weil alte Einträge fehlerhaft oder
unvollständig waren)  Umstellung der Historie-Daten notwendig
 Abgeleitete Merkmale können sehr hilfreich sein …
 … funktionieren aber nur, wenn sie global anerkannt und verstanden sind
(man sollte die Anwender nicht mit unnötig vielen Objekten überfordern)
 Flexibilität darf nicht verloren gehen  Experten unter den Usern sollten auch
die Basis-Merkmale sehen können
Seite 78
Anforderungen – Beschränkung auf das Wesentliche
Ich will ALLES
haben !!!
 Wenn man Kollegen aus der Facheinheit die Frage stellt, welche Merkmale z.B.
aus einem Auftragsdokument für das Reporting relevant sein könnten, bekommt
man oft die Antwort „ALLES könnte irgendwie irgendwann relevant sein“
 Was sind die wesentlichen Informationen (Merkmale und Kennzahlen)?
 Besser 80% der Anforderungen mit einer „Easy-to-use“ Anwendung abdecken
… als 99% der Anforderungen in einem Tool bereitstellen, das keiner nutzt,
weil es zu komplex bzw. unübersichtlich ist
Seite 79
Anforderungen – Beschränkung auf das Wesentliche
Seite 80
Anforderungen – Datenqualität
 Beim Laden von Daten werden oft Fehlerprüfungen bzw. Plausibilitätschecks
durchgeführt  Belege im Reporting werden nicht angezeigt weil z.B.:
- Kundennummern falsch ist
- Datumsfelder unlogisch ist (Lieferungsdatum zeitlich vor Auftragsanlage)
+ Das BI-System findet Fehler und hilft, diese zukünftig im ERP zu vermeiden
 Die fehlerhaften Belege werden z. B. in einem Monats-Umsatz-Report vermisst
(wo es z.B. dem Vertriebschefs völlig gleichgültig ist, ob es in den ERPBelegen Datumsfelder gibt, die nicht plausibel sind)
-
 Es muss abgewogen werden, was wichtiger ist: Fehler aufzudecken oder
Daten vollständig (und analog zum ERP) anzuzeigen
Seite 81
Anforderungen – Datenqualität
 Der korrekte Trend ist z.B. in Supply Chain Anwendungen oft wichtiger als die
korrekten Absolut-Werte
- Anwender ziehen ihre Schlüsse sehr oft über die Analyse des Trends
- … aber bei Finance & Controlling Anwendungen sieht man das anders
 Beim Beheben von Fehlern sollte man an die eventuell zu diesen Daten
getroffene Zielvereinbarungen denken und Korrekturen kommunizieren und
dann nur jeweils zum Monats-, Quartal- oder Jahreswechsel einbauen
 Hilfreich zur Verifizierung der Datenqualität einer Anwendung ist die Option,
im Reporting-Umfeld auch die Einzelbelege anzeigen zu können
Seite 82
Anforderungen – Datenqualität
Exkurs/Beispiel: Fabrikkalender vs. 7 Tage-Kalender
Überwachung der Pünktlichkeit basierend auf einer 7 Tage Woche
4 Tage zu spät
Di Mi Do Fr Sa So Mo Di Mi
Versprochener
Liefertermin
t
Tatsächlicher
Liefertermin
Alternativ: basierend auf 2 Fabrikkalendern (Ermittlung der Arbeitstage)
1 Arbeitstag zu spät
2 Arbeitstage zu spät
Tu We Th Fr Sa So Mo Tu We
Versprochener
Liefertermin
Tatsächlicher
Liefertermin
t
Tu We Th Fr Sa So Mo Tu We
Feiertag
Versprochener
Liefertermin
t
Tatsächlicher
Liefertermin
 gibt es einen analytischen Mehrwert durch die Fabrikkalender-Information?
Seite 83
Zusammenfassung:
Bei der Definition der fachlichen Anforderungen muss man …




Details diskutieren und bei Interessenskonflikten Kompromisse finden
Entscheidung treffen über den Einbau impliziter Logik & abgeleiteter Merkmale
Die für das Reporting wesentlichen Informationen finden
Eine Strategie zum Umgang mit Fehler bzw. Ungenauigkeiten finden
 Oft gibt es nicht die „eine“ richtige Lösung, die für alle passt
 Was kann man tun?  Optionen sind:
- Kompromisse finden
- Separate Anwendungen pro Anforderer bzw. Facheinheit bauen
- Anwendungen bzw. Datenmodelle so flexible wie möglich bauen
 Wichtig ist dabei aber immer auch „Keep it simple !!!“
Seite 84
6. Herausforderungen in BI Projekten
i.
ii.
iii.
iv.
v.
Das Team (Facheinheit und IT)
Fachliche Anforderungen
Tools
Prototyp
Go Live und was dann?
Seite 85
Wichtiger als „schicke“ Frontend-Tools
sind z.B. eine klare Anforderungs-Definition und
ein schlüssiges IT Konzept
 Beim Start von BI Projekten wird oft über Frontend-Tools diskutiert
- Facheinheit-Mitarbeiter haben sich z.B. auf Messen oder im Internet
informiert und betrachten nun Tool und Anwendungs-Idee als Einheit
- Solche Diskussionen sind viel interessanter und „spaßiger“ als z.B. die
Anforderungs-Detailanalyse
Quelle: http://www.projectmanager.com/
images/showcase/dashboard.jpg
„Organizations tend to throw technology at BI
problems. You could have the right tool but it
could be doomed to failure because of …
(e.g.) an absence of executive support …”
Ian Bertram, Gartner global BI manager, 2009
 Lenkt bisweilen von den eigentlichen Problemen ab
 Oft gibt es Rahmenbedingungen (IT-Strategie, Know-how im Unternehmen, etc.)
und nur geringe Anzahl von Tools kommt überhaupt in Frage
Seite 86
Frontend Tool Beispiel: QlikView
Beispiel-Werte sind
frei erfunden
Seite 87
Frontend Tool Beispiel: QlikView
Beispiel-Werte sind
frei erfunden
Seite 88
6. Herausforderungen in BI Projekten
i.
ii.
iii.
iv.
v.
Das Team (Facheinheit und IT)
Fachliche Anforderungen
Tools
Prototyp
Go Live und was dann?
Seite 89
Die zügige Erstellung eines ersten
Prototypen erleichtert die Projektarbeit
 Sobald die Anforderungen und Konzepte grob geklärt sind, hilft die Erstellung
eines ersten Prototypen in den Projektarbeit
- Man sieht, worüber man spricht  Missverständnisse werden ausgeräumt
- Man kann – falls nötig – jetzt noch gegensteuern
(ohne ganz viel Geld verloren zu haben)
- Man ist weg von der „grünen Wiese“
(für viele Kollegen ist es einfacher, etwas „Bestehendes“ anzupassen)
- Man bekommt ein Gefühl dafür, was technisch möglich ist
- Man erreicht einen ersten Projekterfolg
 Motivation für Projektmitarbeiter, Anforderer und Sponsoren
Deshalb gilt immer noch der Spruch: „Think big, start small!“
Seite 90
6. Herausforderungen in BI Projekten
i.
ii.
iii.
iv.
v.
Das Team (Facheinheit und IT)
Fachliche Anforderungen
Tools
Prototyp
Go Live und was dann?
Seite 91
Nicht selten wird die Arbeit, die nach
dem Go Live ansteht, unterschätzt
 Nach dem Go Live
- …stellt man vielleicht fest, dass die „Welt“ nicht auf dieses Tool gewartet hat
 es wird weniger genutzt als erwartet
(ein „Geschenk“, das sich niemand gewünscht hat)
- ... bekommt man erstmals Feedback von
den „echten“ Anwendern und stellt dann fest,
dass man einiges überarbeiten muss
 Nach dem Go Live
- … braucht man einen „starken“ Application Owner, der
 das Change Management organisiert
 Marketing für die neue Anwendung betreibt
(Training organisiert, Vorträge hält, die Anwender informiert und überzeugt)
- … braucht man weiterhin zumindest einen Teil des Projektteams
 um eventuell erst jetzt erkennbare Fehler zu korrigieren
 dringende Änderungswünsche umzusetzen
Seite 92
6. Herausforderungen in BI Projekten
i.
ii.
iii.
iv.
v.
Das Team (Facheinheit und IT)
Fachliche Anforderungen
Tools
Prototyp
Go Live und was dann?
 Zusammenfassung
Seite 93
Business Intelligence Projekte in der Praxis:
Herausforderungen an Business und IT
 Business Intelligence … klingt einfach, ist es aber nicht!
 Herausforderungen in BI Projekten
- Team … muss sich „multikulturell“ (Business und IT) zusammen finden
und am gleichen Strick ziehen
- Fachliche Anforderungen … müssen im Detail diskutiert und verstanden
werden – und es müssen oft fachlich und IT-technisch Kompromisse
gefunden werden
- Tools … alleine lösen noch keine Probleme
- Prototyp … ist immer noch der beste Start
- Go Live und was dann? … beginnt manchmal die Arbeit erst so richtig
Seite 94
Business Intelligence Projekte in der Praxis:
Herausforderungen an Business und IT
Mögliche Gründe für das Scheitern von BI-Projekten sind z. B.:
 Mangelnde Datenqualität im DWH  Prüfungen im ETL-Prozess sehr wichtig!
 Die Datenqualität ist sehr gut, aber die Anwender verstehen das Tool nicht
(wg. unterschiedlichen Sichten auf die Daten, komplexen Ableitungs- und
Berechnungsregeln, etc.)
 Komplexität, wo immer möglich, vermeiden!
 Anwendungen so einfach und bedienerfreundlich wie möglich gestalten!
 Umfangreiche Trainings und schlüssige Dokumentationsunterlagen anbieten!
 Neben der Datenqualität ist wichtig für die Akzeptanz von BI-Anwendungen:
− Einheitliches Verständnis darüber etablieren, wie die Daten zu interpretieren
sind und welche Ableitungs- und Berechnungsregeln Verwendung finden
− Usability und Simplicity
Seite 95
7. IT Trends und BI
Seite 96
Wie geht’s weiter mit BI?
 Aktuell stellen 3 große IT-Trends einige der klassischen BI Konzepte in Frage:
Cloud
InMemory
Mobile
Seite 97
Wie geht’s weiter mit BI: InMemory
?
InMemory
 Braucht man im inMemory-Zeitalter noch eine separate DHW Datenbank?
Rückblick: Was waren noch einmal die Gründe für eine separate DWH Datenbank?
Seite 98
Wie geht’s weiter mit BI: InMemory
InMemory
 Braucht man im inMemory-Zeitalter noch eine separate DHW Datenbank?
 Gründe für eine separate DWH Datenbank:
1. Entlastung der operativen Systeme von umfangreichen Abfragen
2. Umsetzung einer für Abfragen optimierte Datenhaltung
3. Zusammenführung von Daten aus mehreren Quellen
 1. und 2. verlieren z. T. an Bedeutung, aber man wird nach wie vor BI
Architekturen benötigen*, um z. B.
− Daten aus verteilten Quellsystemen zusammenzuführen
− Impliziter Logiken, abgeleitete Merkmale usw. umzusetzen
* auch wenn diese zukünftig zum Teil anders aussehen werden
Seite 99
Wie geht’s weiter mit BI: Cloud, SaaS
Cloud
Software as a Service
 Wozu noch komplizierte BI Projekte durchführen, wenn man doch einfach die
Daten in eine Reporting-Cloud-Anwendung laden kann?
 Die Problematik der Diskussion fachlicher Anforderungen, bzw. der
Kommunikation zwischen Facheinheit und IT bleiben bestehen
 Viele große Unternehmen sind aktuell noch skeptisch gegenüber der Cloud
(z. B. wegen Bedenken bzgl. Datensicherheit)
 … aber für das Prototyping in BI Projekten ergeben sich hier ganz neue
Möglichkeiten
Seite 100
Wie geht’s weiter mit BI: Mobile
Mobile
 Sind Smartphones, Tabletts usw. nur eine wenig hilfreiche „Spielerei“?
 Braucht man nun nicht mehr denn je „einfache“ Anwendungen?
 Smartphones und Tabletts sind aus dem privaten Alltag nicht mehr
wegzudenken und werden auch in den Unternehmen immer wichtiger
 BI Tools müssen sich damit auseinandersetzen!
Seite 101
8. Standardisierte
versus agile BI
Seite 102
Herausforderung an IT-Architektur & Tools:
Gleichzeitig standardisiert und agil zu sein
„Wie handeln erfolgreiche Unternehmen?“
Auf diese Frage antwortet der BI Analyst Dr. Wolfgang Martin (2009):
Sie legen ihr Augenmerk auf den Kunden
Sie trennen sich von niedrigwertigen Aufgaben
Sie dezentralisieren Entscheidungsprozesse
Sie sind compliant
Sie denken und handeln durchgängig („end-to-end) und ermöglichen so die
Kollaboration mit Zulieferern, Partnern und Kunden
 Sie industrialisieren (standardisieren und automatisieren) Geschäftsprozesse
 Sie sind agil und damit in der Lage, jederzeit Strategie-Änderungen flexibel
und schnell umzusetzen
 Und schließlich entscheiden sie sich für Performance Management, getreu
dem Leitspruch „Man kann nur managen, was man auch messen kann“





Seite 103
Standardisierung und Agilität
 „Operational excellence“ also Industrialisierung (Automation und
Standardisierung) von Geschäftsprozessen bleibt wichtig
- beschleunigt und optimiert Geschäftsprozesse
- erhöht den Durchsatz
- verbessert die Qualität
 In Zeiten der Krise und des Wandels wird der Lebenszyklus von Strategien und
Prozessen immer kürzer  Agilität wird zusätzlich immer wichtiger
- Fähigkeit zur kontinuierlichen und schnellen Innovation und zur Anpassung
der eigenen Geschäftsmodelle und Prozesse an die Markt- und
Kundendynamik
Wolfgang Martin, 2009
 Standardisierung und Agilität erfordern zum Teil widersprüchliche Ansätze
 IT Architekturen und -Konzepte müssen beiden Ansprüchen gerecht zu werden
Seite 104
Standardisierung ist die Basis
 Unternehmensweit abgestimmte Regeln sorgen dafür, dass die ReportingLandschaft standardisiert/harmonisiert ist und bleibt, insb.:
1. „Single Point of Truth“ über ein Enterprise Data Warehouse (EDW)
für alle Reporting-relevanten Stamm- und Bewegungsdaten
2. „Extract once, deploy many“ zur Vermeidung redundanter Datenextraktionen
Reporting Anwendungen
...
Vertrieb &
Marketing
2b. … deploy many
Supply
Chain
Einkauf
EDW
...
1. Single Point of truth
Quellsysteme
2a. Extract once
Seite 105
… aber auch Flexibilität/Agilität ist notwendig
 Eine unternehmensweit standardisierte und EDW-basierte Architektur bringt viele
Vorteile, ist aber nicht sehr flexibel!
 Rahmen schaffen zur Umsetzung flexibler Anforderungen
- Separates Umfeld mit reduzierte Entwicklungsregeln (geringere Kosten,
kürzere Entwicklungszeiten, etc.)
 aber zu standardisierten Merkmalen und Kennzahlen abgrenzen
- Möglichkeit, Daten zu ergänzen (incl. Join mit den zentralen Daten),
ohne die IT-Abteilung involvieren zu müssen
 aber Know-how gefragt, damit Datenanbindung konsistent erfolgt
- Zusatz-Tools, z. B. zur Verwendung
innovativer Visualisierungskonzepte
 aber „Tool-Zoo“ vermeiden
Quelle: http://hammacher-datentechnik.com/Beispiellsungen.html#Zweig8
Seite 106
Kompromiss zwischen Standardisierung und Flexibilität
 Die Standards sind die Basis!  Unternehmensweit abgestimmte Regeln sorgen
dafür, dass die Reporting-Landschaft standardisiert ist und bleibt
- Enterprise Data Warehouse als „Single Point of Truth“
- „Extract once, deploy many“ zur Vermeidung redundanter Datenextraktionen
- Entwicklungsrichtlinien/Namenskonventionen zur Strukturierung der Arbeit
- Liste der im Unternehmen „erlaubten“ Tools zur Vermeidung eines „Tool-Zoos“
 Rahmen zur Umsetzung flexibler Anforderungen
- Stark reduzierte Entwicklungsregeln
- Option für Datenergänzungen ohne Involvement der IT-Abteilung
- Separate Tools für spezielle Zusatzfunktionen
 Beide „Welten“ müssen durch ein Regelwerk klar abgegrenzt werden
 Hierfür ist eine IT Governance notwendig!
Seite 107
Data Mining
1.
2.
3.
4.
5.
Was ist Data Mining?
Der Knowledge Discovery in Databases (KDD) Prozess
Clusterverfahren
Entscheidungsbaumverfahren
Assoziationsanalyseverfahren
Seite 108
1. Was ist Data Mining?
Seite 109
Data Mining
 “Data Mining is a problem-solving methodology that finds a logical or
mathematical description, eventually of a complex nature, of patterns and
regularities in a set of data.” Decker und Focardi
 Ziel von Data Mining:
− Muster entdecken in großen Datenbeständen
− und mit logischen oder mathematischen Modellen zu beschreiben
Seite 110
Data Mining
„… Das Rennen ums Weiße Haus
könnte im digitalen Raum entschieden
werden …“
Seite 111
Data Mining: Beispiele für Muster
 Regionale Zusammenhänge, z. B. wenn
in großen Städten Produkte stark verkauft
werden, während diese in ländlichen
Regionen keinen Absatz finden
 Wiederkehrende zeitliche Trends, z. B.
wenn die Verkaufszahlen bestimmter
Produkte immer am Monatsende absinken
 Cross-Selling, z. B.: Wer Babywindeln kauft,
kauf auch Bier
Seite 112
Data Mining
 Data Mining sucht Muster,
− die bisher nicht bekannt waren
− die betriebswirtschaftlich relevante Zusammenhänge beschreiben
 Damit kann man Vorhersagen über zukünftige Entwicklungen treffen
und sich Wettbewerbsvorteile erarbeiten
 diese Muster-Erkennung kann für ein Unternehmen sehr wertvoll sein;
daher der Begriff „Mining“ (Bergbau, Abbau, Gewinnung) und
die Assoziation mit dem Schürfen von Gold in Datenbergen
Seite 113
Data Mining versus OLAP
 OLAP-Analysetools geben Antworten 
auf Fragen, die vom Anwender gestellt
werden (wobei der Anwender durch die
Datenwürfeln navigiert)
Data Mining Tools suchen selbständig
nach Zusammenhängen und
entwickeln automatisiert Hypothesen,
die hilfreich sein könnten
1. Frage
2. Antwort
Muster
Seite 114
Data Mining versus OLAP
 OLAP-Analysetools blicken in die
Vergangenheit  man möchte zum
Beispiel verstehen, wie sich die
Absatzzahlen der verschiedenen
Produkte in den belieferten
Regionen entwickelt haben
Vergangenheit
• Was ist passiert?
 Reporting
• Warum ist es passiert?
 Analysen
HEUTE
 Data Mining Tools blicken auch nach
vorne  man versucht Datenmuster
zu entdecken, die für Vergangenheit
und Zukunft Gültigkeit haben
Zukunft
• Was wird passieren?
 Vorhersagen
• Welche Optionen haben wir?
 Simulationen
Zeit
Seite 115
2. Der KDD Prozess
Seite 116
Data Mining und Knowledge Discovery in Databases
 “Knowledge discovery in databases is the non-trivial process of identifying valid,
novel, potentially useful, and ultimately understandable patterns in data”
Fayyad, 1996
 Diese KDD Definition besagt,
− dass es um neue (novel), bisher nicht aufgefallene Muster geht
− dass diese Muster potentiell nützlich (potentially useful)
− und verständlich (understandable) sein sollten
 Vor allem aber weist sie darauf hin, dass KDD ein Prozess ist  Betrachtet man
diesen Prozess im Detail, sieht man dass er Data Mining als Analyseschritt enthält
Seite 117
KDD-Prozess
Startpunkt: Einsatzbereich und Zielsetzung
 Selektion
 Vorverarbeitung
 Transformation
 Anwendung der Data Mining Methoden
 Interpretation und Evaluierung der
Ergebnisse
!
Wissen
Interpretation /
Evaluierung
Muster
Date Mining
(Methodenanwendung)
Transformierte
Daten
Transformation
 Data Mining ist Teil des KDD-Prozesses
(beide Begriffe werden aber oft auch
synonym verwendet)
 KDD bzw. Data Mining ist mehr als die
Anwendung von Data-Mining-Methoden
auf den DWH-Datenbestand
Vorverarbeitete
Daten
Vorverarbeitung
Zieldaten
Auswahl / Selektion
Daten
Darstellung basiert auf Fayyad
Seite 118
KDD-Prozess: Selektion
Zieldaten
Auswahl / Selektion
Daten
 Die für die zu untersuchende Thematik relevanten Daten werden in Datenquellen
selektiert und in einen Zieldatenbestand (ev. DWH) übernommen
 Mögliche Datenquellen:
− OLTP Systeme
− DWH
− Unternehmensexterne Anwendungen oder Datenbanken
 Unterscheidung: Vertikale vs. horizontale Selektion (siehe nächste Folie)
Seite 119
KDD-Prozess: Vertikale vs. horizontale Selektion
 Vertikale Selektion: Auswahl einer Teilmenge der vorhandenen Datensätze; z. B.:
Nur die Absatzzahlen der letzten 3 Jahre, auch wenn im DWH 10 Jahre vorliegen
 Horizontale Selektion: Auswahl nur solcher Merkmale bzw. Attribute, die für die
Analysen von Interesse sind; z. B.: Name der Stadt ist nicht wichtig, wenn die PLZ
vorliegt (worüber man regionale Muster erkennen kann)
Zeitraum
Monat
Dez 12
Dez 12
Dez 12
Dez 12
Nov 12
Nov 12
Nov 12
Nov 12
Nov 12
Okt 12
...
Dez 09
Dez 09
Dez 09
Dez 09
Verkaufsort- Verkaufsort- KassenPLZ
Stadt
Nummer
67433
67433
67433
67433
67433
67433
67433
67433
67433
67433
...
67433
67433
67433
67433
Neustadt
Neustadt
Neustadt
Neustadt
Neustadt
Neustadt
Neustadt
Neustadt
Neustadt
Neustadt
...
Neustadt
Neustadt
Neustadt
Neustadt
1
1
1
1
2
2
2
2
2
3
...
1
1
1
1
ArtikelNummer
Menge
4711
4712
4713
4715
4711
4712
4713
4714
4715
4711
...
4711
4712
4713
4714
200
100
20
55
300
200
30
250
55
200
...
200
100
20
500
Wert
100,00 €
150,00 €
10,00 €
60,00 €
150,00 €
300,00 €
15,00 €
150,00 €
60,00 €
100,00 €
...
100,00 €
150,00 €
10,00 €
300,00 €
Seite 120
KDD-Prozess: Vorverarbeitung
Vorverarbeitete
Daten
Vorverarbeitung
Zieldaten
 Analyse und falls nötig Verbesserung der Datenqualität der selektierten Daten
 Probleme bereiten fehlende oder fehlerhafte Daten (letztere können über Plausibilitätsprüfungen entdeckt werden)  Optionen zur Korrektur bzw. Ergänzung:
− Löschen der Datensätze
Probleme: Wichtige Informationen gehen eventuell verloren und der Abgleich
zwischen KDD-Datenbestand und Quellsystemen ist nicht mehr möglich
− Manuelle Pflege der fehlenden Informationen
Problem: Hoher Aufwand, daher Kosten-Nutzen-Abwägung notwendig
− Automatisierte Herleitung der Informationen (Mittelwert-Bildung, Ermittlung des
wahrscheinlichsten Wertes, etc.)
Problem: Gibt es einen guten Algorithmus zur Ergänzung bzw. Korrektur?Seite 121
KDD-Prozess: Vorverarbeitung
 Beim Umgang mit fehlenden und fehlerhaften Daten sollte die Frage im
Mittelpunkt stehen, was man mit den Daten erreichen will?
Beispiel:
VerkaufsortPLZ
67433
67433
67433
67433
67433
KundenAlter
17
12
77
999
83
ArtikelNummer
4711
4712
4713
4715
4711
Wert
100,00 €
150,00 €
10,00 €
300,00 €
60,00 €
 Ist vor allem wichtig, den Gesamtumsatz korrekt auszuweisen,
− müssen Datensätze mit fehlenden und fehlerhaften Daten akzeptiert werden
− und falls möglich der fehlende Umsatz-Wert ermittelt werden*
 Geht es primär um die regionale Zuordnung,
− sollte man bei fehlender PLZ versuchen, diese nachträglich zu ermitteln
(manuell oder über einen Algorithmus)
− und falls dies nicht gelingt, den Datensatz löschen
* z. B. aus dem Verkaufspreis des gleichen Artikels an einen anderen Kunden
Seite 122
KDD-Prozess: Transformation
Transformierte
Daten
Transformation
Vorverarbeitete
Daten
 Die Transformation bringt die Daten in eine als Input für das Data-Mining-System
geeignete Form; z. B.:
− Datumsangaben sowie Mengen- und Wertfelder werden in eine Form
gebracht, die a.) einheitlich für alle Quellen ist und b.) von der Data-MiningAnwendung interpretiert werden kann
− Je nach Problemstellung wird die Komplexität der Daten reduziert, indem die
Daten z. B. klassifiziert oder aggregiert werden
Beispiel:
Verkaufsort- Kunden- ArtikelPLZ
Alter Nummer
67433
17
4711
67433
12
4712
67433
14
4713
Wert
100,00 €
150,00 €
10,00 €
VerkaufsortKundenArtikelPLZ (3-stellig) Alter (Cluster) Nummer
674
Jung
4711
674
Jung
4712
674
Jung
4713
Wert
100,00 €
150,00 €
10,00 €Seite
123
KDD-Prozess: Anwendung der Data Mining Methoden
Muster
Date Mining
(Methodenanwendung)
Transformierte
Daten
 Mit Data-Mining-Methoden versucht man, bisher nicht erkannte Datenmuster
aufzudecken und zu beschreiben
 Besonders wichtig bzw. weit verbreitet:
 Clusterverfahren: Objekte werden anhand ihrer Eigenschaften in Cluster mit
identischen Eigenschaften eingeteilt
 Entscheidungsbaumverfahren: Zu vorliegenden Clustern werden neue
Objekte zugeordnet und damit klassifiziert
 Verfahren der Assoziationsanalyse: Analyse von Abhängigkeitsmustern bzw.
von Wenn-dann-Regeln , z. B.: „Wer ein Fahrrad kauft, kauft er in 30% aller
Fälle innerhalb der folgenden 4 Wochen auch noch Fahrradtaschen“
Seite 124
KDD-Prozess: Interpretation und Evaluierung der Ergebnisse
!
Wissen
Interpretation /
Evaluierung
Muster
 Die mit KDD und Data Mining ermittelten Datenmuster sind nutzlos, wenn es nicht
gelingt, sie so zu interpretieren, dass das Unternehmen davon einen Nutzen hat
 Beispiele für KDD-Nutzen bzw. Erkenntnisse:
− Zeitliche Zusammenhang zwischen einem Ereignis (z. B.: Olympische Spiele)
und dem Anstieg der Absatzzahlen gewisser Produkte (z. B.: Laufschuhe)
 Wenn das Ereignis zum nächsten Mal ansteht, kann die Produktion im
Vorfeld erhöht und die steigende Nachfrage ohne Engpässe bedient werden
− Korrelation zwischen dem Absatz zweier Produkte (z. B.: Windeln und Bier)
 durch räumliche Nähe der Produkte (im Supermarktregal) wird dieses
Kundenverhalten unterstützt und der Absatz beider Produkte erhöht
Seite 125
KDD-Prozess
 Führt der KDD-Prozess nicht zum
Erfolg, kann auf jeden Teilschritt
zurückgesprungen werden, um
− z. B. durch Anpassung von
selektierten Daten oder DataMining-Verfahren einen neuen
Versuch zu unternehmen,
Muster mit betriebswirtschaftlichem Mehrwert zu finden
 Auch wenn oft primär über die Data
Mining Methoden gesprochen wird:
Der größte Aufwand im KDDProzess entfällt auf Selektion,
Vorverarbeitung und Transformation
!
Wissen
Interpretation /
Evaluierung
Muster
Date Mining
(Methodenanwendung)
Transformierte
Daten
Transformation
Vorverarbeitete
Daten
Vorverarbeitung
Zieldaten
Auswahl / Selektion
Daten
Darstellung basiert auf Fayyad
Seite 126
Data Warehouse versus KDD
 Ein DWH, in dem schon Plausibilitätsprüfungen und Formatvereinheitlichungen
durchgeführt sind, ist eine sehr gute Datenbasis für KDD
 KDD ist aber mehr als die Anwendung von Data-Mining-Methoden auf ein DWH:
− Für KDD wird z. T. der direkter Realtime-Zugriff auf operative Daten benötigt
− Im KDD-Prozess werden Daten z. T. maßgeschneidert so transformiert, dass
sie als Input für Data-Mining-Verfahren passen (diese Transformationen
wären in einem reinen OLAP-Reporting eventuell unsinnig)
Seite 127
3. Clusterverfahren
Seite 128
Clusterverfahren
 Clusterverfahren: Objekte werden (automatisiert) in Cluster mit identischen/
ähnlichen Eigenschaften eingeteilt
 Ziel ist, dass Objekte innerhalb einer gefundenen Gruppe (Cluster, Segment)
möglichst homogen sind, also möglichst ähnliche Eigenschaften besitzen
 … während Objekte aus unterschiedlichen Clustern möglichst unähnlich sein sollen
 Clusterverfahren werden z. B. eingesetzt, um Kunden bzw. Märkte zu segmentieren
 Diese Kundensegmente können dann maßgeschneidert auf ihre Eigenschaften
(ihre Interessen, ihr Kaufverhalten) hin angesprochen und beworben werden.
Haben Sie schon einmal darüber nachgedacht, warum sie im Baumarkt nach ihrer Postleitzahl gefragt werden
… und vielleicht notiert die freundliche Verkäuferin ja auch noch ihr Geschlecht und schätzt ihr Alter …
Seite 129
Vorgehen beim Clusterverfahren
 Zur Clusterung muss man 3 Festlegungen treffen:
1. Proximitätsmaß definieren: Quantifizierung der Ähnlichkeit zwischen zwei
Objekten
2. Fusionierungsalgorithmus auswählen: Objekte basierend auf ihrer Ähnlichkeit
in Cluster einteilen
3. Clusteranzahl wählen: Festlegen, bei welcher Clusteranzahl der Algorithmen
stoppen soll
Seite 130
Proximitätsmaß: nominale Objekteigenschaften
 Summe der Anzahl der übereinstimmenden Objekteigenschaften
zur Berechnung der Ähnlichkeit
 Summe der Anzahl der nicht übereinstimmenden Objekteigenschaften
zur Ermittlung der Distanz
 Pro Merkmal gibt es nur 0 oder 1 bzw. identisch oder nicht identisch.
Beispiel:
Geschlecht Geburtsland Alter (Kategorie) PLZ
Kunde 1 männlich
Deutschland
Alt
66482
weiblich
Deutschland
Mittel
22587
Kunde 2
0
1
0
0
Ähnlichkeit Summe: 1
1
0
1
1
Distanz Summe: 3
Seite 131
Proximitätsmaß: numerische Objekteigenschaften
 Zur Distanzbestimmung werden geometrische Formeln verwendet wie z. B.
− Euklidische Distanz
𝑑 𝑋𝑖 , 𝑋𝑗 =
x (2, 2)
𝑛
� 𝑋𝑖𝑖 − 𝑋𝑗𝑗
𝑘=1
2
x
(1, 1)
x (2, 2)
− Manhattan-Distanz
𝑛
𝑑 𝑋𝑖 , 𝑋𝑗 = � 𝑋𝑖𝑖 − 𝑋𝑗𝑗
𝑘=1
Beispiel:
Anzahl Artikel
Kunde 1
5
Kunde 2
10
25
5
Distanz = 2
Umsatz [€]
300
250
2500
50
Alter
70
35
1225
35
x
(1, 1)
Euklidische Distanz: √3750 = 61,2
Manhattan Distanz: 90
Seite 132
Proximitätsmaß
 Oft müssen sowohl nominale als auch numerische Objekteigenschaften
berücksichtigt werden
 Sind einzelne Eigenschaften besonders wichtig, können bei der Ermittlung der
Gesamt-Distanz Gewichtungsfaktoren verwendet werden
 Während in den hier vorgestellten Beispielen Distanzwerte für 2 Objekte
berechnet wurden, müssen zur Clusterbildung die Abstandswerte aller Objekte
des Datenbestands ermittelt werden
Seite 133
Agglomerative versus divisive Methoden
1
1, 2
2
3
1, 2, 3, 4, 5
3, 4
4
3, 4, 5
5
Agglomerative
Methode
Divisive
Methoden


0
1
2
3
4
4
3
2
1
0
Agglomerativ (Bottom-up): Jedes Objekt wird als Cluster interpretiert; dann werden die Abstände der
Cluster berechnet und jeweils die beiden Cluster mit dem geringsten Abstand zusammengeführt
Divisiv (Top-down): Alle Objekte befinden sich in einem einzigen Cluster; dann werden schrittweise
kleinere, möglichst homogene Cluster gebildet
Seite 134
Quelle: Chamoni, P.; Gluchowski, P.: Analytische Informationssysteme, Data Warehouse, On-Line Analytical Processing, Data Mining. Springer Verlag, 1999
3 Optionen zur Distanz-Ermittlung bei Clustern
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Complete Linkage:
größte Abstand zwischen zwei Objekten
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Single Linkage:
geringste Abstand zwischen zwei Objekten
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Average Linkage:
Abstand zwischen den Cluster-Schwerpunkten
x
Schwerpunkt des Clusters
x Einzelne Objekte
Zur Ermittlung der Distanz zwischen den beiden Punkten bzw. Schwerpunkten können dann wieder
geometrischen Formeln wie der Euklidischen Distanz oder der Manhattan Distanz verwendet werden
Seite 135
Clusteranzahl
 Festlegung bei wie vielen Clustern der Fusionierungsalgorithmus stoppen soll?
 Einerseits: Je größer die Anzahl der Cluster ist, desto höher kann man die
Anforderungen an die Homogenität eines einzelnen Clusters stellen
 Andererseits: Eine möglichst geringe Anzahl von Clustern fördert die
Handhabbarkeit und Aussagefähigkeit der Analyseergebnisse
Beispiel: Werden 3 Kundensegmente identifiziert, kann man diese individuell
anzusprechen/bewerben; je mehr Clustern es werden, desto aufwendiger wird es
Seite 136
Beispiel: Cluster für Objekte mit 2 Eigenschaften x, y
Agglomeratives Clusterverfahren / Euklidische Distanz / Average-Linkage / Stopp: 3 Cluster
?
y
1) Ausgangspunkt:
5 Objekte/Cluster
x
Seite 137
Beispiel: Cluster für Objekte mit 2 Eigenschaften x, y
Agglomeratives Clusterverfahren / Euklidische Distanz / Average-Linkage / Stopp: 3 Cluster
y
?
y
1) Ausgangspunkt:
5 Objekte/Cluster
x
2) Neues Cluster
x
Seite 138
Beispiel: Cluster für Objekte mit 2 Eigenschaften x, y
Agglomeratives Clusterverfahren / Euklidische Distanz / Average-Linkage / Stopp: 3 Cluster
y
y
1) Ausgangspunkt:
5 Objekte/Cluster
2) Neues Cluster
3) Neue Abstände
zum Schwerpunkt
x
x
y
y
y
y
5) Neue Abstände zum
Schwerpunkt
4) Neues Cluster
x
x
x
6) Stopp bei 3 Cluster
x
Seite 139
?
Beispiel für Kundensegmentierungs-Cluster
 Kunden mit zwei Objekteigenschaften: Anzahl (gekaufter) Artikel, Umsatz in €
 Einsatz des agglomerativen Clusterverfahrens
 Einsatz der Abstandsermittlung mittels Manhattan-Distanz und Single-Linkage
Kunden:
Kunde Anzahl Artikel Umsatzwert in €
K1
5
20
K2
10
15
K3
15
25
K4
10
30
K5
15
5
K6
15
35
K7
10
10
K8
25
30
K9
35
35
K10
30
30
mit Abstandsmatrix:
Kunde
K1
K2
K3
K4
K5
K6
K7
K8
K9
K10
K1
-
K2
K3
K4
K5
K6
K7
K8
K9
K10
-
-
-
-
-
-
-
-
-
Seite 140
Beispiel für Kundensegmentierungs-Cluster
 Kunden mit zwei Objekteigenschaften: Anzahl (gekaufter) Artikel, Umsatz in €
 Einsatz des agglomerativen Clusterverfahrens
 Einsatz der Abstandsermittlung mittels Manhattan-Distanz und Single-Linkage
Diagramm:
mit Abstandsmatrix:
Kunde
K1
K2
K3
K4
K5
K6
K7
K8
K9
K10
K1
-
K2 K3 K4
10 15 15
- 15 15
- 10
-
K5
25
15
20
30
-
K6
25
25
10
10
30
-
K7
15
5
20
20
10
30
-
K8
30
30
15
15
35
15
35
-
K9
45
45
30
30
50
20
50
15
-
K10
35
35
20
20
40
20
40
5
10
-
Seite 141
Beispiel für Kundensegmentierungs-Cluster
 Ausgangspunkt: 10 Objekte ( also 10 Cluster)
 Schritt 1: Kleinster Abstand zwischen Kunde 2 und 7 und Kunde 8 und 10
 noch 8 Cluster verbleiben
Diagramm:
mit Abstandsmatrix:
Kunde
K1
K2
K3
K4
K5
K6
K7
K8
K9
K10
K1
-
K2 K3 K4
10 15 15
- 15 15
- 10
-
K5
25
15
20
30
-
K6
25
25
10
10
30
-
K7
15
5
20
20
10
30
-
K8
30
30
15
15
35
15
35
-
K9
45
45
30
30
50
20
50
15
-
K10
35
35
20
20
40
20
40
5
10
-
Seite 142
Beispiel für Kundensegmentierungs-Cluster
 Ausgangspunkt: 8 Cluster
 Schritt 2: Kleinster Abstand (single linkage) zwischen einerseits Kunde 1 und
andererseits Kunde 2 vom Cluster aus K2 und K7, etc.
 Stopp bei 3 Clustern
Diagramm:
mit Abstandsmatrix:
Kunde
K1
K2
K3
K4
K5
K6
K7
K8
K9
K10
K1
-
K2 K3 K4
10 15 15
- 15 15
- 10
-
K5
25
15
20
30
-
K6
25
25
10
10
30
-
K7
15
5
20
20
10
30
-
K8
30
30
15
15
35
15
35
-
K9
45
45
30
30
50
20
50
15
-
K10
35
35
20
20
40
20
40
5
10
-
Seite 143
Anwendungsgebiete für Clusterverfahren
 Segmentierung von Kunden oder Märkten:
Kunden können dann maßgeschneidert auf ihre Interessen
und ihr Kaufverhalten hin angesprochen und beworben werden
 Gesundheitswesen:
Patienten können basierend auf Eigenschaften wie Alter,
Geschlecht, Cholesterinwerte, Blutdruck usw. in Risikogruppen
für bestimmte Krankheitsbilder eingeordnet werden
 Patienten aus unterschiedlichen Clustern können dann
spezifische Vorschläge zur Krankheitsprävention unterbreitet
werden
Seite 144
4. Entscheidungsbaumverfahren
Seite 145
Entscheidungsbaumverfahren
 Entscheidungsbaumverfahren werden eingesetzt, um neue Objekte in schon
vorhandene Cluster bzw. Segmente einzuordnen
 Für diese Zuordnung werden Klassifizierungsregeln generiert, die in einer
Baumstruktur dargestellt werden können:
Beispiel:
Einordnung neuer Kunden
in die Segmente „kreditwürdig“
bzw. „nicht kreditwürdig“
Schulden
> 20.000 €
ja
nein
Einkommen
> 50.000 €
ja
Kredit kann
erteilt werden!
Kredit kann
erteilt werden!
nein
Kredit sollte
nicht erteilt werden!
 Der Verwendung eines Entscheidungsbaumes ist meist einfach und intuitiv,
komplizierter ist dagegen die Entscheidungsbaumerstellung
Seite 146
Entscheidungsbaumerstellung – Ausgangspunkt
Ausgangspunkt sind die vorhandenen
Datenbestände mit:
 unabhängigen Attributen: Eigenschaften,
die man zur Entscheidungsbaumerstellung
heranziehen kann wie z. B.
− Schulden
− Einkommen
− Alter
− Arbeitslos oder nicht
− Selbständig oder angestellt
− …
 abhängigem Attribut: die Eigenschaft,
die man später für neue Daten (neue
Kunden) vorhersagen möchte, z. B.:
− „kreditwürdig“ vs. „nicht kreditwürdig“
Kunde
Schulden Einkommen Alter . . .
Meier
25.000 €
100.000 € 60
Neumeier
80.000 €
20.000 € 55
Altmeier
10.000 €
55.000 € 70
Müller
35.000 €
40.000 € 35
Neumüller 50.000 €
150.000 € 25
Altmüller
40.000 €
30.000 € 65
Mann
50.000 €
100.000 € 40
Neumann
10.000 €
20.000 € 20
Altmann
25.000 €
45.000 € 55
Schneider
50.000 €
55.000 € 60
Gärtner
100.000 €
55.000 € 55
Schmidt
50.000 €
25.000 € 45
Fritz
50.000 €
55.000 € 35
Friedrich
30.000 €
40.000 € 19
...
kreditwürdig
ja
nein
ja
ja
ja
nein
ja
ja
ja
ja
nein
ja
ja
ja
Kundeneigenschaften
(unabhängige Attribute)
Information, ob sich die Kunden
als kreditwürdig erwiesen haben
(abhängiges Attribut)
Seite 147
Entscheidungsbaumerstellung – Vorgehensweise
 Aufteilung des Datenbestandes:
− Trainingsmenge
zur Erstellung des
EntscheidungsbaumModells
− Validierungsmenge
zum Test des Modells
Beispiel für Entscheidungsbaum
Kunde
Schulden Einkommen Alter . . .
Meier
25.000 €
100.000 € 60
Neumeier
80.000 €
20.000 € 55
Altmeier
10.000 €
55.000 € 70
Müller
35.000 €
40.000 € 35
Neumüller 50.000 €
150.000 € 25
Altmüller
40.000 €
30.000 € 65
Mann
50.000 €
100.000 € 40
Neumann
10.000 €
20.000 € 20
Altmann
25.000 €
45.000 € 55
...
Schneider
Gärtner
Schmidt
Fritz
Friedrich
...
50.000 €
100.000 €
50.000 €
50.000 €
30.000 €
55.000 €
55.000 €
25.000 €
55.000 €
40.000 €
60
55
45
35
19
Vorhersage
Korrekt
kreditwürdig Entsch.baum oder nicht?
ja
ja
korrekt
nein
nein
korrekt
ja
ja
korrekt
ja
ja
korrekt
ja
ja
korrekt
nein
nein
korrekt
ja
ja
korrekt
ja
ja
korrekt
ja
nein
falsch
ja
nein
ja
ja
ja
ja
ja
ja
ja
ja
korrekt
falsch
korrekt
korrekt
korrekt
Information aus den Bestandsdaten
Vorhersage des Entscheidungsbaum-Modells
Prüfung ob Vorhersage korrekt ist?
Seite 148
Entscheidungsbaumerstellung – Vorgehensweise
 Gelingt es mit der Trainingsmenge
ein Entscheidungsbaum-Modell zu
erstellen,
Kunde
Schulden Einkommen Alter . . .
Meier
25.000 €
100.000 € 60
Neumeier
80.000 €
20.000 € 55
Altmeier
10.000 €
55.000 € 70
Müller
35.000 €
40.000 € 35
Neumüller 50.000 €
150.000 € 25
Altmüller
40.000 €
30.000 € 65
Mann
50.000 €
100.000 € 40
Neumann
10.000 €
20.000 € 20
Altmann
25.000 €
45.000 € 55
...
 … das auch bei den Validierungsdaten möglichst oft das korrekte
Clustern ermittelt
Schneider
Gärtner
Schmidt
Fritz
Friedrich
...
 … kann davon ausgegangen
werden, dass auch die Zuordnung
neuer Datensätze weitgehend*
korrekte Vorhersagen liefert
Theobald
Willibald
Sommer
Winter
Herbst
* eine 100% korrekte Vorhersage wird meist nicht erreicht
50.000 €
100.000 €
50.000 €
50.000 €
30.000 €
Vorhersage
Korrekt
kreditwürdig Entsch.baum oder nicht?
ja
ja
korrekt
nein
nein
korrekt
ja
ja
korrekt
ja
ja
korrekt
ja
ja
korrekt
nein
nein
korrekt
ja
ja
korrekt
ja
ja
korrekt
ja
nein
falsch
55.000 €
55.000 €
25.000 €
55.000 €
40.000 €
60
55
45
35
19
ja
nein
ja
ja
ja
ja
ja
ja
ja
ja
korrekt
falsch
korrekt
korrekt
korrekt
40.000 €
45.000 €
25.000 €
55.000 €
40.000 €
60
45
55
35
19
???
???
???
???
???
nein
ja
nein
ja
ja
???
???
???
???
???
Neue Kunden:
70.000 €
60.000 €
50.000 €
30.000 €
10.000 €
Da das Modell vor der Anwendung auf neue Daten mit Validierungsdaten überprüft wird, spricht man von überwachtem Lernen
Seite 149
Entscheidungsbaumerstellung – Vorgehensweise
Wie kommt man zu einem guten Modell?
 Man sucht die Objekteigenschaften, die am besten geeignet sind, die Daten in
Teilmengen zu splitten, die möglichst homogen sind in Bezug auf das abhängige
Attribut (z. B.: möglichst ausschließlich kreditwürdig bzw. nicht kreditwürdig)
 Zur Ermittlung der geeigneten Unterscheidungswerte werden mathematische
Algorithmen eingesetzt:
− im Beispiel könnte statt 20.000 € ja auch 10.000 € oder 30.000 € als
Schuldengrenze festgelegt werden
− oder es könnte zunächst nach dem Einkommen und erst dann nach den
Schulden gesplittet werden (auch die Reihenfolge der Splitts ist wichtig)
 Weiterhin muss man festlegen, mit welchem Grad an Homogenität man
zufrieden ist
− Reicht z. B. eine Verteilung von 80:20, bedeutet dies, dass mindestens
80% der Daten jeder Teilmenge einer Ausprägung des abhängigen
Attributes (kreditwürdig oder nicht kreditwürdig) entsprechen müssen
Seite 150
Entscheidungsbaumerstellung – Vorgehensweise
Wie kommt man zu einem guten Modell?
 Beispiel: Ziel ist eine Homogenität von mindestens 80:20
Datensätze gesamt:
Kreditwürdig:
Nicht kreditwürdig
Schulden
> 20.000 €
ja
Datensätze gesamt:
Kreditwürdig:
Nicht kreditwürdig
Einkommen
> 50.000 €
ja
Datensätze gesamt:
Kreditwürdig:
Nicht kreditwürdig
300
275
25
92%
8%
Mindestwert für
Homogenität erreicht
1000
700
300
600
325
275
54%
46%
nein
Datensätze gesamt:
Kreditwürdig:
Nicht kreditwürdig
400
375
25
94%
6%
Mindestwert für
Homogenität erreicht
Mindestwert für
Homogenität nicht erreicht
nein
Datensätze gesamt:
Kreditwürdig:
Nicht kreditwürdig
300
50
250
17%
83%
Mindestwert für
Homogenität erreicht
Seite 151
Anwendungsgebiete für Entscheidungsbaumverfahren
 Bonitätsprüfung von Neukunden einer Bank (siehe vorne)
 Betrugserkennung bzw. -vorbeugung
bei Versicherungen
Seite 152
Übung 1 zum Entscheidungsbaum-Verfahren
?
 Nehmen wir an, dass der gesamte Datenbestand nur aus 14 Datensätzen besteht
 Was wäre dann das bessere Start-Splitt-Kriterium:
− Schulden < 20.000 € oder
− Einkommen > 50.000 €
Kunde
Schulden
Meier
25.000 €
Neumeier
80.000 €
Altmeier
10.000 €
Müller
35.000 €
Neumüller 50.000 €
Altmüller
40.000 €
Mann
50.000 €
Neumann
10.000 €
Altmann
25.000 €
Schneider
50.000 €
Gärtner
100.000 €
Schmidt
50.000 €
Fritz
50.000 €
Friedrich
30.000 €
Schulden
Einkommen
< 20.000 € Einkommen
> 50.000
nein
100.000 €
ja
nein
20.000 €
nein
ja
55.000 €
ja
nein
40.000 €
nein
nein
150.000 €
ja
nein
30.000 €
nein
nein
100.000 €
ja
ja
20.000 €
nein
nein
45.000 €
nein
nein
55.000 €
ja
nein
55.000 €
ja
nein
25.000 €
nein
nein
55.000 €
ja
nein
40.000 €
nein
kreditwürdig
ja
nein
ja
ja
ja
nein
ja
ja
ja
ja
nein
ja
ja
ja
Seite 153
Übung 1 zum Entscheidungsbaum-Verfahren
 Nehmen wir an, dass der gesamte Datenbestand nur aus 14 Datensätzen besteht
 Was wäre dann das bessere Start-Splitt-Kriterium:
− Schulden < 20.000 € oder
− Einkommen > 50.000 €
 besser, da mehr Übereinstimmungen
Kunde
Schulden
Meier
25.000 €
Neumeier
80.000 €
Altmeier
10.000 €
Müller
35.000 €
Neumüller 50.000 €
Altmüller
40.000 €
Mann
50.000 €
Neumann
10.000 €
Altmann
25.000 €
Schneider
50.000 €
Gärtner
100.000 €
Schmidt
50.000 €
Fritz
50.000 €
Friedrich
30.000 €
Schulden
Einkommen
< 20.000 € Einkommen
> 50.000
nein
100.000 €
ja
nein
20.000 €
nein
ja
55.000 €
ja
nein
40.000 €
nein
nein
150.000 €
ja
nein
30.000 €
nein
nein
100.000 €
ja
ja
20.000 €
nein
nein
45.000 €
nein
nein
55.000 €
ja
nein
55.000 €
ja
nein
25.000 €
nein
nein
55.000 €
ja
nein
40.000 €
nein
Anzahl der Übereinstimmungen: 5
kreditwürdig
ja
nein
ja
ja
ja
nein
ja
ja
ja
ja
nein
ja
ja
ja
8
Seite 154
Übung 2 zum Entscheidungsbaum-Verfahren
?
 Nehmen wir an, dass der gesamte Datenbestand nur aus 14 Datensätzen besteht
 Was wäre dann das bessere Start-Splitt-Kriterium:
− Schulden < 20.000 € oder
− Schulden < 30.000 €
Kunde
Schulden
Meier
25.000 €
Neumeier
80.000 €
Altmeier
10.000 €
Müller
35.000 €
Neumüller 50.000 €
Altmüller
40.000 €
Mann
50.000 €
Neumann
10.000 €
Altmann
25.000 €
Schneider
50.000 €
Gärtner
100.000 €
Schmidt
50.000 €
Fritz
50.000 €
Friedrich
30.000 €
Schulden
< 20.000 €
nein
nein
ja
nein
nein
nein
nein
ja
nein
nein
nein
nein
nein
nein
Schulden
< 30.000 €
ja
nein
ja
nein
nein
nein
nein
ja
ja
nein
nein
nein
nein
ja
kreditwürdig
ja
nein
ja
ja
ja
nein
ja
ja
ja
ja
nein
ja
ja
ja
Seite 155
Übung 2 zum Entscheidungsbaum-Verfahren
 Nehmen wir an, dass der gesamte Datenbestand nur aus 14 Datensätzen besteht
 Was wäre dann das bessere Start-Splitt-Kriterium:
− Schulden < 20.000 € oder
− Schulden < 30.000 €
 besser, da mehr Übereinstimmungen
Kunde
Schulden
Meier
25.000 €
Neumeier
80.000 €
Altmeier
10.000 €
Müller
35.000 €
Neumüller 50.000 €
Altmüller
40.000 €
Mann
50.000 €
Neumann
10.000 €
Altmann
25.000 €
Schneider
50.000 €
Gärtner
100.000 €
Schmidt
50.000 €
Fritz
50.000 €
Friedrich
30.000 €
Schulden
< 20.000 €
nein
nein
ja
nein
nein
nein
nein
ja
nein
nein
nein
nein
nein
nein
Anzahl der Übereinstimmungen: 5
Schulden
< 30.000 €
ja
nein
ja
nein
nein
nein
nein
ja
ja
nein
nein
nein
nein
ja
kreditwürdig
ja
nein
ja
ja
ja
nein
ja
ja
ja
ja
nein
ja
ja
ja
8
Seite 156
5. Assoziationsanalyseverfahren
Seite 157
Verfahren der Assoziationsanalyse
 Ziel ist die Identifikation von Zusammenhängen, die sich als Wenn-DannAussagen beschreiben lassen, z. B.:
− Wer die DVDs Fluch der Karibik 1 und
Fluch der Karibik 2 gekauft hat,
kauft oft auch Fluch der Karibik 3
− Wer Johannisbeerlikör kauft,
kauft oft auch Sekt dazu
− Wer Windeln kauft, kauf oft auch Bier
 Diese Beispiele sind Warenkorbanalysen: Durch die Auswertung von Kassenbondaten will man herausfinden, welche Waren zusammen gekauft werden Seite 158
Verfahren der Assoziationsanalyse –
Kennzahlen zur „Stärke“ von Assoziationsregeln
 Ausgangspunkt ist eine Wenn-Dann-Aussage, z. B.
„Wenn jemand Nudeln kauft, dann kauft er auch Wein“
mit Nudeln
mit Wein
mit Wein
alle Kassenbons
alle Kassenbons
entnommen aus Gabriel,
Data Warehouse &
Data Mining, 2011
mit Nudeln
Support
Support =
Anzahl der Datensätze, die die Regel unterstützen
Anzahl aller Datensätze
Konfidenz
Konfidenz =
Anzahl der Datensätze, die diese Regel unterstützen
Anzahl aller Datensätze, die den Prämissenteil* erfüllen
* im obigen Beispiel: die Anzahl der Geschäftsvorfälle,
bei denen Nudeln gekauft werden
Seite 159
Suche nach Assoziationen
 Wegen der großen Datenbestände (z. B. Kassenbons), verwendet man bei der
Suche nach relevanten Assoziationen Algorithmen, die die Liste der möglichen
Assoziationen eingrenzen, z. B. den A-priori-Algorithmus, der 2 Phasen hat:
1. Ermittlung aller gemeinsam auftretenden Ereignisse,
deren Support-Wert über einem Minimalwert liegt
 Eliminierung von Assoziationen, die nur selten vorkommen
2. Selektion derjenigen Assoziationen aus Phase 1,
deren Konfidenz-Wert über einem Minimalwert liegt
 Eliminierung von Assoziationen, die nur selten korrekt sind, d.h. wo nur in
wenigen Fällen aus der Wenn-Aussage (Prämisse) die Dann-Aussage folgt
---------------------------------------------------------------------------------------------------------------Bei der Wahl der Minimalwerte von Support und Konfidenz ist zu beachten:
 einerseits soll die Ergebnismenge nicht zu groß und damit unübersichtlich werden
 andererseits will man keine wichtigen Assoziationen übersehen
Seite 160
Anwendungsgebiete für Assoziationsanalyseverfahren
 Warenkorbanalyse: Wenn bestimmte Artikel häufig zusammen gekauft werden,
kann man sie gezielt zusammen anbieten und damit eventuell den Umsatz
beider Artikel steigern (Crossmarketing), z. B. durch:
− Gezielte Anordnung von Waren in benachbarten Supermarktregalen
− Webshop-Werbung: „Wer dies kauft, kauft oft auch jenes …“
− Oft werden dabei auch zeitliche Zusammenhänge entdeckt, z. B.:
Personen, die eine Kamera gekauft haben, haben oft in den folgenden 6
Monaten Interesse an Zusatzobjektiven oder größere Speicherkarten
 Ursachenforschung bei Plan-Ist-Abweichungen, z. B.:
− Absatz von Streusalz korreliert mit den Winter-Außentemperaturen und der
Niederschlagsmenge (Glatteisgefahr)
− Absatz von Bier korreliert mit Sport-Großereignissen wie einer Fußball-WM
 Gesundheitsweisen, z. B. Ermittlung von sich gut ergänzender
Behandlungsmethoden
 Systematische technische Fehler, z. B. Telekommunikation-Fehlroutings
 Kreditkartenmissbrauch (fraud detection)
Aus bestimmten zeitlichen Verhaltensmustern (z. B. kleine Testabbuchungen vor
Seite 161
größeren Abbuchen) kann man einen Kreditkartenmissbrauch vorhersagen
Das war‘s für heute!
Haben Sie noch Fragen zu diesen Themen?
Business Intelligence
1. Data Warehouse und BI
2. BI Architektur
3. OLAP
4. Close the loop
5. Typische BI Fragestellungen
6. Herausforderungen in BI Projekten
7. IT Trends und BI
8. Standardisierte vs. agile BI
Data Mining
1. Was ist Data Mining?
2. Der Knowledge Discovery in
Databases (KDD) Prozess
3. Clusterverfahren
4. Entscheidungsbaumverfahren
5. Assoziationsanalyseverfahren
Seite 162