Konzeption und prototypische Realisierung von ISE Sales Auswertungen über SAP BW

Kiemes, Tobias

Konzeption und prototypische Realisierung von ISE Sales Auswertungen über SAP BW

Zusammenfassung

Inhaltsangabe:Einleitung:
ISE blickt auf eine Geschichte bis in das Jahr 1930 zurück, als das Unternehmen unter der Firmierung Dr. Herrmann E. Müller gegründet wurde und ist seit 1957 Lieferant der europäischen Automobilindustrie. Erst 1997 ist die heutige Firma entstanden, als sich das Bergneustädter Werk von der Teves- Gruppe ausgegliedert hat und zur ISE Innomotive Systems Europe GmbH wurde. Seitdem ist das Unternehmen gewachsen. 2001 wurde die Gesamtunternehmensgruppe Lunke Ventra Automotive (heute ISE Industries GmbH) übernommen, weiterhin wurden weltweit mehrere Werke gebaut.
Die letzte große Erweiterung des Konzerns fand 2004 statt, als die Firma IBS Brocke (heute ISE Intex GmbH) übernommen wurde. ISE ist international ausgerichtet und trägt, wo immer dies wirtschaftlich und strategisch sinnvoll ist, den Globalisierungstrategien der Kunden (die Automobilhersteller) Rechnung, indem das Unternehmen Kapazitäten vor Ort schafft. In Unternehmen dieser Größe kommt eine riesige Datenmenge zustande, die ohne eine zeitgerechte IT nicht mehr zu handhaben wäre. Aus den Daten müssen Informationen gewonnen werden und auf Basis dieser Informationen werden Entscheidungen getroffen, welche die Zukunft des Unternehmens maßgebend beeinflussen.
Diese Diplomarbeit erforscht die Grundlage für eine bessere Entscheidungsfindung. In den von dieser Diplomarbeit behandelten Auswertungen geht es um Ist- und Planumsätze. Dabei ist es für jedes Unternehmen äußerst wichtig, akkurate Kennzahlen zu erhalten, da von diesen zukunftsweisende Entscheidungen abhängen. Derzeit werden die Umsatzauswertungen mit Hilfe eines ABAP-Programms durchgeführt. Dieses Programm ist eine Eigenentwicklung, die im Laufe der Zeit immer wieder verändert bzw. erweitert wurde, dadurch sehr schlecht wartbar ist und das operative System (R/3) von ISE stark belastet.
Warum der Report mit diesen Nachteilen behaftet ist, wird in Kapitel 3.1.4 ausführlich erläutert. Die Zielsetzung dieser Diplomarbeit besteht in der Entwicklung und Bewertung eines Konzeptes für die Umsatzplanung, die auf einem Data Warehouse basiert und zu hoher Flexibilität und Performanz führt. Weiterhin soll das Data Warehousing technische und menschliche Ressourcen der IT entlasten. Der Einsatz der Data Warehouse Lösung erfolgt im Rahmen dieser Arbeit prototypisch. Mittelfristig soll ein DWH SAPs Business Information Warehouse bei ISE eingeführt werden.

Gang der Untersuchung:
Die vorliegende Arbeit schafft zunächst […]

Leseprobe

Inhaltsverzeichnis

ID 9119

Kiemes, Tobias:

Konzeption und prototypische Realisierung von ISE Sales Auswertungen über SAP BW

Hamburg: Diplomica GmbH, 2005

Zugl.: Fachhochschule Köln, Abt. Gummersbach, Diplomarbeit, 2005

Dieses Werk ist urheberrechtlich geschützt. Die dadurch begründeten Rechte,

insbesondere die der Übersetzung, des Nachdrucks, des Vortrags, der Entnahme von

Abbildungen und Tabellen, der Funksendung, der Mikroverfilmung oder der

Vervielfältigung auf anderen Wegen und der Speicherung in Datenverarbeitungsanlagen,

bleiben, auch bei nur auszugsweiser Verwertung, vorbehalten. Eine Vervielfältigung

dieses Werkes oder von Teilen dieses Werkes ist auch im Einzelfall nur in den Grenzen

der gesetzlichen Bestimmungen des Urheberrechtsgesetzes der Bundesrepublik

Deutschland in der jeweils geltenden Fassung zulässig. Sie ist grundsätzlich

vergütungspflichtig. Zuwiderhandlungen unterliegen den Strafbestimmungen des

Urheberrechtes.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in

diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme,

dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei

zu betrachten wären und daher von jedermann benutzt werden dürften.

Die Informationen in diesem Werk wurden mit Sorgfalt erarbeitet. Dennoch können

Fehler nicht vollständig ausgeschlossen werden, und die Diplomarbeiten Agentur, die

Autoren oder Übersetzer übernehmen keine juristische Verantwortung oder irgendeine

Haftung für evtl. verbliebene fehlerhafte Angaben und deren Folgen.

Diplomica GmbH

http://www.diplom.de, Hamburg 2005

Printed in Germany

Inhaltsverzeichnis

Vorwort und Danksagung

Beginnen möchte ich dieses Dokument mit einer Metapher zum Testen der

Softwarequalität. Da gibt es einen Haufen Heu, mit dem man sein Pferd füttern

muss. Doch in dem Heu verbirgt sich eine unbestimmte Anzahl von Nadeln.

Nun begibt man sich auf die Suche nach den Nadeln (Fehlern) im Heuhaufen,

man möchte ja nicht, dass das Pferd auf diese Nadeln beißt. Aber solange man

sucht, bekommt das Pferd nichts zu fressen. Schließlich wird man sich dazu

entscheiden, das Pferd zu füttern, obwohl man nur vermutet, dass keine Nadel

mehr im Heu ist.

An dieses Bild musste ich denken, während ich dem vorliegenden Dokument

den letzten Schliff verpasste; die letzten Tippfehler suchte. Jetzt ist die

Entscheidung gefällt und Sie lesen die finale Version.

Ich danke den Personen, die direkt und indirekt an der Diplomarbeit beteiligt

waren.

An erster Stelle bedanke ich mich bei Herrn Prof. Dr. Westenberger, der schon

in seiner Vorlesung zu betrieblichen Anwendungssystemen mein Interesse am

Data Warehousing weckte und mich im Verlauf der Diplomarbeit engagiert

leitete.

Dank gilt auch dem Unternehmen ISE und den Mitarbeitern der IT,

insbesondere Herrn Ralph Steuck, der die Diplomarbeit organisierte, sowie dem

Zweitprüfer, Herrn Sieghard Bickenbach.

Schließlich bedanke ich mich bei meiner Familie für die Unterstützung nicht

fachlicher Art während meines Studiums.

Tobias Kiemes

Inhaltsverzeichnis

Inhaltsverzeichnis

Inhaltsverzeichnis ... I

Abbildungsverzeichnis ...IV

Tabellenverzeichnis ...VI

Abkürzungsverzeichnis ...VII

1 Einleitung und Aufgabenstellung ... 1

1.1 Motivation... 1

1.2 Zielsetzung... 1

1.3 Vorgehen ... 2

2 Data Warehousing ... 3

2.1 Definition ... 3

2.2 Chancen und Risiken des Data Warehousings... 4

2.3 Referenzarchitektur... 6

2.4 Business Information Warehouse ... 11

2.4.1 Architektur des SAP BW... 11

2.4.2 BW vs. Referenzmodell ... 11

2.4.3 Das Datenmodell des BW ... 19

2.4.4 Kritische Betrachtung des BW ... 20

3 Problemanalyse und Anforderungsdefinition... 23

3.1 Verlauf von Sales-Analysen bei ISE ... 23

3.1.1 Bedeutung der Sales-Auswertung... 23

3.1.2 Grundsätzliche Anforderungen an die Umsatzauswertung. 23

3.1.3 Der Report ZV189002 ... 24

3.1.3.1 Anwendersicht ... 24

3.1.3.2 Technische Sicht... 27

3.1.4 Probleme der derzeitigen Umsatzauswertung... 28

Inhaltsverzeichnis

3.2 Mögliche Lösungen durch ein DWH... 31

3.2.1 Kennzahlen und Merkmale... 31

3.2.2 Vorbereitungen zum Datenmodell ... 32

3.3 Einsparungspotential ... 38

4 Konzeption ... 39

4.1 Rahmenbedingungen zur Lösung ... 39

4.2 Konzeptionelle Ansätze & Prototyp... 40

4.2.1 ETL für die Teilanalysen... 41

4.2.1.1 Extraktion ... 41

4.2.1.2 Transformation... 50

4.2.1.3 Laden... 52

4.2.1.4 Master Data ... 56

4.2.2 Gesamtlösung ... 59

4.2.3 Automatisierung des ETL-Prozesses ... 63

4.3 Bewertung... 65

4.3.1 Gegenüberstellung der alten und neuen Lösung... 65

4.3.1.1 Anwendersicht ... 65

4.3.1.2 IT-Sicht... 66

4.3.2 Testszenario: ZV189002 vs. BW ... 69

4.3.3 Rentabiltitätsanalyse ... 72

5 Fazit und Ausblick... 76

6 Literaturverzeichnis ... 79

7 Anhang ... 81

Anhang A: Glossar... 81

Anhang B: das EBW ... 86

Anhang C: KC1, das Konsolidierungssystem... 89

Anhang D: Report ZV189002... 91

Anhang E: Anforderungen & Lösung ... 97

Anhang F: Testszenario: Report vs. BW ... 101

Anhang G: Extraktion durch Funktionsbausteine ... 106

Anhang H: Demonstration anhand von Auswertungen ... 120

Abbildungsverzeichnis

III

Anhang I: Prozessketten... 123

Anhang J: Kosten-Nutzen-Analyse ... 126

Ehrenwörtliche Erklärung ... 128

Abbildungsverzeichnis

Abbildungsverzeichnis

Abbildung 1 - Business Improvement Opportunities (nach [NCR04])... 4

Abbildung 2 Referenzarchitektur (aus [BaGü04]) ... 10

Abbildung 3 - Quellsystemtypen des SAP BW ... 12

Abbildung 4 - InfoProvider ... 14

Abbildung 5 Fortschreibungsregeln ... 15

Abbildung 6 - Query Designer ... 15

Abbildung 7 - BW vs. Referenzmodell ... 18

Abbildung 8 - Star Schema... 19

Abbildung 9 - erweitertes Star-Schema ... 20

Abbildung 10 - ZV189002, Selektionskriterien... 25

Abbildung 11 - ZV189002, Ist- und/oder Planumsatz ... 26

Abbildung 12 - ZV189002, Sortierkriteren ... 27

Abbildung 13 - Ausgabe des Reports... 30

Abbildung 14 Kennzahlenschema ... 32

Abbildung 15 - multidimensionales Datenmodell... 37

Abbildung 16 - Daimler Chrysler Kundenhierarchie... 37

Abbildung 17 - Tabellen zu Analyse "Umsatz"... 42

Abbildung 18 - Definition des Delta ... 46

Abbildung 19 - Tabellen zur Analyse "Lieferungen"... 48

Abbildung 20 - Tabellen zur Analyse "lieferrelv. Einteilungen" ... 49

Abbildung 21 - Tabellen zur Analyse "Bedarfe" ... 50

Abbildung 22 - Detaildaten zur Datenanforderung... 52

Abbildung 23 - Formel zur Fortschreibung ... 53

Abbildung 24 - Star-Schema zu Datenwürfel "Umsatz" ... 54

Abbildung 25 - Abweichung zum Star Schema (Master Data)... 55

Abbildung 26 - Implementierung der Produkthierarchie... 58

Abbildung 27 - Gesamtsicht der Auswertung ... 59

Abbildung 28 - berechnete Kennzahlen... 62

Abbildung 29 - Formel für Kennzahl ... 62

Abbildung 30 - Hierarchie der Auswertungsbereiche... 63

Abbildung 31 - ETL-Prozesskette ... 64

Abbildung 32 - Break-Even Analyse ... 73

Abbildung 33 - Projektportfolio ... 74

Abbildung 34 - Rentabilitätsanalyse und Kostenstruktur ... 76

Tabellenverzeichnis

Tabellenverzeichnis

Tabelle 1 Teilbereiche der Sales-Auswertung ... 26

Tabelle 2 manuelle Arbeit an der Umsatzauswertung ... 31

Tabelle 3 Attribute der Umsatzauswertung (minimal) ... 33

Tabelle 4 Beispiel für kennzahlenorientiertes Datenmodell ... 35

Tabelle 5 Beispiel für kontenorientiertes Datenmodell... 35

Tabelle 6 Hierarchie in den Merkmalen ... 59

Abkürzungsverzeichnis

VII

Abkürzungsverzeichnis

ABAP

Advanced Business Application Programming

ALE

Application Link Enabling

API

Application Programming Interface

BAPI

Business Application Programming Interface

BEx

Business Explorer

Business Information Warehouse

CRM

Customer Relationship Management

DBMS

Database Management System

DSS

Decision Support System

DWH

Data Warehouse

DWS

Data-Warehouse-System

ERP

Enterprise Resource Planning

ETL

Extraktion, Transformation, Laden

ISE

Innomotive Systems Europe

Informationstechnologie

KPI

Key Performance Indicator

MOLAP

Multidimensional On-Line Analytical Processing

ODS

Operational Data Store

OLAP

On-Line Analytical Processing

OLTP

On-Line Transaction Processing

PSA

Persistant Staging Area

R/3

R: Realtime processing

3: 3-Tier-Architektur

RFC

Remote Function Call

ROI

Return-on-Investment

SAP

Systeme, Anwendungen und Produkte in der Datenverar-

beitung

SEM

Strategic Enterprise Management

XOR

Exklusives Oder

1 Einleitung und Aufgabenstellung

1 Einleitung und Aufgabenstellung

1.1 Motivation

ISE blickt auf eine Geschichte bis in das Jahr 1930 zurück, als das Unter-

nehmen unter der Firmierung Dr. Herrmann E. Müller gegründet wurde und

ist seit 1957 Lieferant der europäischen Automobilindustrie. Erst 1997 ist die

heutige Firma entstanden, als sich das Bergneustädter Werk von der Teves-

Gruppe ausgegliedert hat und zur ISE Innomotive Systems Europe GmbH

wurde. Seitdem ist das Unternehmen gewachsen. 2001 wurde die Gesamt-

unternehmensgruppe Lunke Ventra Automotive (heute ISE Industries GmbH)

übernommen, weiterhin wurden weltweit mehrere Werke gebaut. Die letzte

große Erweiterung des Konzerns fand 2004 statt, als die Firma IBS Brocke

(heute ISE Intex GmbH) übernommen wurde.

,,ISE ist international ausgerichtet und trägt, wo immer dies wirtschaftlich und

strategisch sinnvoll ist, den Globalisierungstrategien der Kunden (die Auto-

mobilhersteller) Rechnung, indem das Unternehmen Kapazitäten vor Ort

schafft."[Inno05]

In Unternehmen dieser Größe kommt eine riesige Datenmenge zustande, die

ohne eine zeitgerechte IT nicht mehr zu handhaben wäre. Aus den Daten

müssen Informationen gewonnen werden und auf Basis dieser Informationen

werden Entscheidungen getroffen, welche die Zukunft des Unternehmens

maßgebend beeinflussen. Diese Diplomarbeit erforscht die Grundlage für

eine bessere Entscheidungsfindung.

1.2 Zielsetzung

In den von dieser Diplomarbeit behandelten Auswertungen geht es um Ist-

und Planumsätze. Dabei ist es für jedes Unternehmen äußerst wichtig, akku-

rate Kennzahlen zu erhalten, da von diesen zukunftsweisende Entscheidun-

gen abhängen.

1 Einleitung und Aufgabenstellung

Derzeit werden die Umsatzauswertungen mit Hilfe eines ABAP-Programms

durchgeführt. Dieses Programm ist eine Eigenentwicklung, die im Laufe der

Zeit immer wieder verändert bzw. erweitert wurde, dadurch sehr schlecht

wartbar ist und das operative System (R/3) von ISE stark belastet. Warum

der Report mit diesen Nachteilen behaftet ist, wird in Kapitel 3.1.4 ausführlich

erläutert.

Die Zielsetzung dieser Diplomarbeit besteht in der Entwicklung und Bewer-

tung eines Konzeptes für die Umsatzplanung, die auf einem Data Warehouse

basiert und zu hoher Flexibilität und Performanz führt. Weiterhin soll das Da-

ta Warehousing technische und menschliche Ressourcen der IT entlasten.

Der Einsatz der Data Warehouse Lösung erfolgt im Rahmen dieser Arbeit

prototypisch. Mittelfristig soll ein DWH SAP's Business Information Ware-

house bei ISE eingeführt werden.

1.3 Vorgehen

Die vorliegende Arbeit schafft zunächst einige Grundlagen, indem sie in Ka-

pitel zwei das Data Warehousing erläutert. Hier wird eine Definition gegeben,

auf die so genannte Referenzarchitektur eingegangen und schließlich das

Business Warehouse 3.5 mit der Referenzarchitektur verglichen.

Den Hauptteil liefern die Kapitel drei und vier. Das dritte Kapitel befasst sich

ausführlich mit der Ist-Aufnahme bezüglich der Sales-Auswertungen bei ISE

und der Problemanalyse, während das vierte Kapitel die prototypische Lö-

sung vorstellt.

Die Zusammenfassung der gewonnenen Arbeitsergebnisse, die Bewertung

der Lösung, ein Fazit und Ausblick erfolgen im letzten Kapitel der Diplomar-

beit.

Im Anhang finden sich neben einem Glossar Informationen über die verwen-

dete Installation des Business Warehouse, das Quellsystem und die bisheri-

ge Reportlösung. Weiterhin sind Quelltexte und die Ergebnisse des ab-

schließenden Testszenarios beigefügt. Verschiedene Screenshots zeigen

2 Data Warehousing

Beispiele für Auswertungen auf Grundlage des Prototyps. Den Schluss bil-

den eEPKs zu den Prozessen der Report- und BW-Lösung.

2 Data Warehousing

2.1 Definition

W. H. Immon definierte den Begriff Data Warehouse in den 90er Jahren wie

folgt: ,,The data warehouse is ... the foundation of all DSS processing ... A

data warehouse is a subject-oriented, integrated, non-volatile, and time-

variant collection of data in support of management's decisions. The data

warehouse contains granular corporate data."

Das Data Warehouse versteht sich also als Basis für entscheidungsunter-

stützende Prozesse (decision support). Es sammelt Daten und stellt diese in

Form von für die Zielgruppe nutzbarer Informationen bereit. Dabei gelten die

Attribute der

Subjektorientiertheit

das DWH fokussiert auf bestimmte Kernbereiche eines Unternehmens,

z. B. Produkte oder Kunden.

Integration

Daten von verschiedenen Quellen werden im DWH zusammengeführt.

Dabei müssen diese vereinheitlicht werden (Namensgebung, Bezugs-

größen, etc).

Nicht-Volatilität, Beständigkeit

Die Daten können im DWH nicht mehr verändert werden.

Granularität der Daten

Die Daten weisen eine bestimmte Verdichtung auf. Daten mit grober

Granularität benötigen weniger Speicherplatz, der Detaillierungsgrad ist

geringer.

(vgl. [Egger04], S. 30 f.]

2 Data Warehousing

Im Allgemeinen versteht man unter dem Data Warehousing nur das Bereit-

stellen der Daten. Andere Definitionen zählen die Analyse (z. B. OLAP) dazu.

Eine weitere, etwas kürzere Definition lautet:

,,Datenlager für Analysezwecke" [BaGü05]

2.2 Chancen und Risiken des Data Warehousings

,,Organizations discovered that getting information out of ERP was difficult."

[Inmon99]

Das Data Warehouse hilft, das Geschäft eines Unternehmens zu verbessern,

indem es Informationen liefert, auf deren Basis Entscheidungen getroffen

werden. Den Entscheidungen folgen Handlungen, die dann zu bestimmten

Ergebnissen führen. Die Ergebnisse müssen nun mit den Zielen des Unter-

nehmens abgeglichen und die Ziele ggf. neu definiert werden.

Abbildung 1 - Business Improvement Opportunities (nach [NCR04])

Das Business Warehouse soll mittelfristig bei ISE eingeführt werden. Diese

Diplomarbeit ist zeitlich vor der Einführung einzuordnen. Es handelt sich um

einen Prototyp, noch nicht um ein produktives System. Trotzdem ist dieser

Prototyp eine Grundlage für die Einführung.

Schon an dieser Stelle sollte man sich weit reichende Gedanken über die

Chancen und Risiken eines Data Warehouses machen. Es kann nur von Vor-

2 Data Warehousing

teil sein, wenn man diese Gedanken bei der weiteren Durchführung des Pro-

jektes im Hinterkopf behält.

Chancen gibt es genug und sie sind vermutlich auch jedem Leser dieses

Dokumentes klar, es sind die Chancen von Informationssystemen im Allge-

meinen und die der Data-Warehouse-Systeme im Speziellen. Dabei handelt

es sich um ganz offensichtliche Eigenschaften des Data Warehousings, wie:

Gezielte Informationssuche

Zugriff auf die Informationen nach verschiedenen (multidimensiona-

len) Kriterien

Optimierte Darstellung

die aber alle dem Hauptzweck und der eigentlich zu nennenden Chance die-

nen:

die Analyse der Unternehmensdaten zur frühzeitigen Erkennung

von Chancen & Risiken für das Unternehmen!

Die Risiken des Data Warehousings sind vielleicht nicht so klar, auf sie soll

deshalb ausführlicher eingegangen werden. Auch hier gibt es natürlich die

allgemeinen Risiken, die mit der Einführung neuer Systeme verbunden sind,

z. B.:

Desinteresse der Nutzer: Bei Einführung neuer Systeme besteht im-

mer die Gefahr, dass die Benutzer sich gar nicht an das neue System

gewöhnen wollen. Daher muss man ihnen unbedingt die Vorteile

deutlich machen und für eine ausreichende Schulung sorgen. Das

Projekt scheitert, wenn es nicht gelingt, die Benutzer zu motivieren.

Es ist auch vorteilhaft, wenn dieser Prototyp von Erfolg gekrönt ist.

Wenn die nutznießende Abteilung VE5 begeistert ist, werden andere

Abteilungen eine DWH-Lösung für sich anstreben.

Fehlende Qualifikation der Personen, die das DWH entwickeln, war-

ten und schließlich nutzen. Auch hier sorgen Schulungen für Abhilfe.

2 Data Warehousing

Etc

Diese Risiken stellen eine Gefahr für das Projekt ,,Data Warehouse" dar. Es

gibt aber auch Gefahren, die sich direkt auf das Unternehmen auswirken

können. Wie in Abbildung 1 ersichtlich ist, werden die Informationen des

DWH analysiert und auf Grundlage dieser Analyse folgen Aktionen. Die Ana-

lyse untersucht vor allem die Key Performance Indicators

(KPI's). Dabei be-

steht die Gefahr, dass der Datenwürfel nicht vollständig oder falsch gefüllt ist

und vereinzelte KPI's dadurch falsch sind.

Am deutlichsten wird die Problematik an einem kleinen Rechenbeispiel: Man

stelle sich einen fehlerhaften Bruch vor, bei dem der Nenner 0 ist. Hier hat

der Anwender Glück gehabt, denn er bekommt einen Fehler - Division durch

Null ist nicht möglich. Wenn der Nenner aber eine andere falsche Zahl ist,

dann ist das Ergebnis keine Fehlermeldung, sondern lediglich eine falsche

Zahl. Unter Umständen merkt der Anwender dies nicht und rechnet mit der

falschen Zahl weiter. Dadurch entstehen Folgefehler und im Unternehmen

könnten solche unerkannten Fehler zu fatalen Fehlentscheidungen führen

(vgl. Abbildung 1).

Deshalb ist dringend davon auszugehen, dass eine Kennzahl falsch ist, so-

lange nicht alle nötigen Daten übertragen wurden.

2.3 Referenzarchitektur

Zunächst soll eine Referenzarchitektur zur Architektur des DWH-Systems

betrachtet werden. Ziel dieses Modells ist die Beschreibung des grundlegen-

den Aufbaus eines solchen Systems, also die Komponenten und deren Zu-

sammenhang. Eine Referenzarchitektur ermöglicht Vergleiche zwischen

KPI: Schlüssel-Einflussfaktoren, die zeigen, wie gut ein Unternehmen seine gesetzten Ziele

erreicht hat [West05]

2 Data Warehousing

Werkzeugen für das Data Warehousing oder kann als Grundlage für eine

konkrete Implementierung genutzt werden. Durch die Zerlegung der Kompo-

nenten wird die Komplexität einer konkreten Implementierung verringert. Sie

ist ein Mittel zur Beschreibung und dient zum gemeinsamen und eindeutigen

Verständnis (vgl. [BaGü04]). In der Praxis können DWH-Systeme von der

Referenzarchitektur abweichen. Abbildung 2 zeigt die auf den folgenden

Seiten beschriebene Referenzarchitektur.

Der Datenbeschaffungsprozess beginnt bei der Datenquelle, welche in der

Referenzarchitektur Stellvertreter für mehrere reale Datenquellen ist. Diese

Komponente ist kein Bestandteil des DWS selbst., sondern Ausgangspunkt

des Datenflusses beim Data Warehousing. Datenquellen können beliebige

Datenbestände sein nicht notwendigerweise Datenbanken. Die Menge der

Daten ist in der Praxis so groß, dass Aktualisierungen inkrementell propagiert

werden müssen. Ein Löschen der alten Daten und anschließendes erneutes

Laden aller Daten ist nicht praktikabel.

Der Monitor ist die Komponente, die das inkrementelle Laden ermöglicht. Er

ist für die Entdeckung von Veränderungen der Daten einer Quelle zuständig.

Weil die Funktionsweise des Monitors von der Art der Datenquelle abhängt,

existiert im Allgemeinen ein Monitor pro Datenquelle. Es gibt unterschiedliche

Monitoring-Strategien, z. B. Trigger, Replikationen, Zeitstempel, Logging o-

der Snapshots.

Als zentrale Komponente des Datenbeschaffungsbereichs führt das Refe-

renzmodell den Arbeitsbereich auf. Dieser dient der Integration von Daten

aus heterogenen Quellen. Hier werden Daten auf ihrem Weg von den Daten-

quellen in die Basisdatenbank temporär zwischengespeichert. Notwendige

Datentransformationen können direkt auf diesem Zwischenspeicher ausge-

führt werden, ohne dass die Datenquellen oder die Basisdatenbank in ihrem

laufenden Betrieb beeinträchtigt werden.

Zur Übertragung von Daten aus der Datenquelle in den Arbeitsbereich ist die

Extraktionskomponente verantwortlich. Sie steuert auch die Auswahl von

2 Data Warehousing

Quellen, die in das Data Warehouse transportiert werden sollen. Für die Ex-

traktion kommen verschiedene Strategien in Frage: periodische Extraktion,

Extraktion auf Anfrage, ereignisgesteuerte Extraktion oder die sofortige Ex-

traktion bei Änderungen.

Vor dem Laden der extrahierten Daten in die Basisdatenbank müssen diese

in einen geeigneten Zustand gebracht werden. Die Transformationskompo-

nente berücksichtigt sowohl strukturelle als auch inhaltliche Aspekte. Daten

aus verschiedenen Datenquellen müssen zunächst in ein einheitliches inter-

nes Format überführt werden, um vergleichbar zu sein. Die Transformation

dient also der Datenmigration, aber auch der Datenbereinigung, da Quellda-

ten häufig durch fehlerhafte, redundante, veraltete oder fehlende Werte ver-

unreinigt sind.

Die Weiterleitung der Daten aus dem Arbeitsbereich in die Basisdatenbank

übernehmen Ladekomponenten, und zwar jeweils eine für die Übertragung

von analyseunabhängigen Detaildaten und analysespezifischen Daten. Übli-

cherweise nehmen die Ladekomponenten dabei das Ladewerkzeug des

zugrunde liegenden DBMS zu Hilfe.

Die Basisdatenbank ist als integrierte Datenbasis für verschiedene Analysen

vorgesehen. Sie ermöglicht die Mehrfachverwendung und Flexibilität in der

Verwendung der Daten und kann als Basis für andere operative Anwendun-

gen dienen. Dabei sammelt sie alle für die Analyse erforderlichen Daten in

der niedrigst erforderlichen Granularität, ohne dabei auf eine spezifische

Analyse zu fokussieren. Mit diesen Daten versorgt sie alle Data Warehouses,

kann aber auch direkt als Datenbasis für die Analyse verwendet werden.

Um die Qualität der Daten sicherstellen zu können, muss nachvollziehbar

sein, wie die Daten in die Basisdatenbank gekommen sind, welchen Weg

und vor allem welche Transformationen sie durchlaufen haben.

Das Data Warehouse ist als Komponente des Data Warehouse Systems zu

betrachten. Es ist die zugrunde liegende Datenbank, die für Analysezwecke

2 Data Warehousing

aufgebaut wird. Die Strukturierung der Daten ist dabei ausschließlich an den

Analysebedürfnissen des Anwenders ausgerichtet. Neben Funktionen zur

Bereitstellung bietet das Data Warehouse auch Funktionen zur Verarbeitung

der Daten.

Das Data Warehouse ermöglicht die Analyse. Analyse ist im Referenzmodell

als Oberbegriff für alle Operationen zu sehen, die mit den Daten des Data

Warehouse durchgeführt werden können. Dazu zählen neben Abfrage und

Darstellung vor allem die Anwendung von Analysefunktionen auf ausgewähl-

te Daten zur Generierung neuer Informationen. Ergebnisse der Analyse (z. B.

Plandaten) werden wieder in die Basisdatenbank bzw. das Data Warehouse

zurückgeführt. Dadurch wird eine Rückkopplung erzeugt, die wertvolle Resul-

tate festhält, die Qualität der Datenbasis erhöht und zukünftige Analysen

verbessert. Zur Präsentation von Daten und Analyseergebnissen werden die

typischen Mittel der Informationsdarstellung genutzt, in erster Linie Tabellen,

Grafiken (z. B. Graphen oder geografische Informationen in Landkarten),

Texte, aber auch multimediale Elemente.

Die Referenzarchitektur nach Bauer und Günzel betrachtet den Data-

Warehouse-Manager als zentrale Komponente für Initiierung, Steuerung und

Überwachung der einzelnen Prozesse von der Extraktion der Daten bis hin

zur Analyse der Daten im Data Warehouse. Er übernimmt die Steuerung von

Monitoren, Extraktoren, Transformatoren, Ladekomponenten und Analyse-

komponenten. Eine der wichtigsten Aufgaben des DW-Managers ist die Initi-

ierung des Datenbeschaffungsprozesses.

Metadaten sind alle Informationen, die den Aufbau, die Wartung und die Ad-

ministration des DWS vereinfachen und darüber hinaus die Informationsge-

winnung aus dem Data Warehouse ermöglichen [BaGü04]. Man unterschei-

det Metadaten zur Generierung des DWH (z. B. Datenquellen, Speicherme-

dium, Speicherort, Datenstruktur, Generierungszeitpunkt, Datenverantwortli-

cher), Kontrolldaten (z. B. letzter Aktualisierungszeitpunkt, Gültigkeitsdauer,

Zugriffsrechte) und Anwenderinformationen (z. B. Datenstruktur im DWH,

2 Data Warehousing

Semantik der Daten, Integritätsbedingungen) (vgl. [West05]). Im Repositori-

um werden diese Metadaten abgelegt.

Der Metadatenmanager steuert die Metadatenverwaltung des DWS. Er bietet

ein API, damit andere Komponenten lesend und schreibend auf das Reposi-

torium zugreifen können.

Abbildung 2 Referenzarchitektur (aus [BaGü04])

2 Data Warehousing

2.4 Business Information Warehouse

In diesem Kapitel soll SAP's Business Information Warehouse genauer un-

tersucht werden. Das Ziel des Kapitels besteht darin, das BW mit dem Refe-

renzmodell zu vergleichen und seine Besonderheiten herauszustellen.

2.4.1 Architektur des SAP BW

Das SAP BW arbeitet auf einer eigenen Installation. Dabei ist es technisch

mit dem R/3 System zu vergleichen (3-schichtige Architektur). Es kommuni-

ziert mit Hilfe verschiedener Technologien mit den Quellsystemen, z. B. ALE

(Application Link Enabling, SAP-eigene Technologie), RFC (Remote Funkti-

on Call), flache Dateien, BAPI (Business Application Programming Inter-

faces, SAP eigene Technologie) oder Third-Party-Extraktions-Tools. [Eg-

ger04]

2.4.2 BW vs. Referenzmodell

,,Das SAP Business Information Warehouse versteht sich als umfassende

Data-Warehouse-Lösung. Alle für den Data-Warehouse-Prozess erforderli-

chen Komponenten sind enthalten. Im Kern sind dies Funktionen für den

ETL-Prozess, Komponenten für die Datenablage, Werkzeuge für Analysen

und Berichte." [Egger04]

Nachdem das Referenzmodell eingeführt und dessen Komponenten erläutert

wurden, soll es mit dem Business Warehouse verglichen werden und dabei

auf die Besonderheiten der SAP Lösung eingegangen werden. Eggers Aus-

sage das BW sei eine umfassende Data Warehouse Lösung wird kritisch

betrachtet.

Obwohl die Datenquelle keine direkte Komponente des Referenzmodells ist,

soll auch diese genannt werden, denn hier beginnt der Datenfluss. SAP BW

2 Data Warehousing

benutzt hier den Begriff Quellsystem. Ein Quellsystem kann ein SAP-System

sein, ein anderes SAP BW, ein Dateisystem (also flache Dateien), ein Da-

tenbanksystem oder ein beliebiges Fremdsystem, das BAPI

implementiert

(s. Abbildung 3 - Quellsystemtypen des SAP BW). Die SAP ist in diesem

Punkt im eigenen Interesse sehr flexibel, denn die Anbindung an Datenquel-

len ist ein wesentlicher Entscheidungsfaktor bei der Wahl eines Data-

Warehouse-Systems. Natürlich ist das BW im Hinblick auf die Anbindung an

SAP R/3 optimiert.

Abbildung 3 - Quellsystemtypen des SAP BW

Pro Quellsystem existieren n DataSources. Die DataSource definiert, welche

Daten extrahiert werden. Diese Regeln (z. B. welche Spalten einer Tabelle

übertragen werden) nennt SAP die Transferstruktur. Die Transferstruktur

entspricht der Transformationskomponente im Referenzmodell. Weiterhin

kann auch in Abhängigkeit vom jeweiligen Quellsystem ein Delta-Verfahren

festgelegt werden, also Regeln, die das inkrementelle Laden ermöglichen.

Auch die Extraktion erfolgt abhängig vom Quellsystem. In SAP-R/3-

Systemen werden Extraktoren als Plug-ins installiert, das BW bringt ebenfalls

Extraktoren mit (falls es als Quellsystem für ein anderes BW dienen soll

Business Application Programming Interfaces, standardisierte Programmschnittstellen, die

externen Zugriff auf die Geschäftsprozesse und Daten des SAP-Systems bieten

In den Naturwissenschaften und in der Technik wird das große Delta als Symbol für die

Differenz ... verwendet. [Wiki05]

2 Data Warehousing

Data Mart), bei Fremdsystemen ist man allerdings auf Tools von Drittherstel-

lern angewiesen.

Zu den DataSources werden InfoPackages erzeugt. In ihnen können zusätz-

liche Selektionskriterien zu den Daten definiert (z. B. alle Belege aus Mai

2005) werden, und es wird festgelegt, ob die PSA genutzt wird oder direkt in

die Datenziele fortgeschrieben wird. Schließlich wird das Laden eingeplant

oder sofort gestartet. Mit Bezug auf das Referenzmodell kann man hier von

der Ladekomponente für die analyseunabhängigen Detaildaten sprechen.

Üblicherweise werden die Daten im BW zunächst in die Persistant Staging

Area (PSA) geschrieben und anschließend von dort in die eigentlichen Da-

tenziele. Bei der PSA handelt es sich um Tabellen, die der DataSource, bzw.

ihrer Transferstruktur entsprechen. Die Daten werden in der gleichen Granu-

larität abgelegt, wie sie von der DataSource geliefert werden.

Die PSA entspricht dem Arbeitsbereich des Referenzmodells. In der PSA

können die Daten technisch geprüft werden (z. B. auf Vollständigkeit der Da-

tenanforderung). Fehlerhafte Daten können korrigiert werden. Die PSA (der

Arbeitsbereich) steigert auch die Performance der Ladevorgänge, da die Da-

tenextraktion von der zeitaufwändigen Weiterverarbeitung der Daten entkop-

pelt wird.

Von der PSA aus lässt sich die Fortschreibung einplanen oder unmittelbar

starten. Dabei werden die Daten in all jene Datenziele geschrieben, für die

Fortschreibungsregeln existieren. Bei den Datenzielen handelt es sich in ers-

ter Linie um verschiedene Varianten von InfoCubes (Datenwürfel), aber auch

ODS-Objekten. SAP prägt hier den Oberbegriff InfoProvider (s. Abb.

Abbildung 4 - InfoProvider). Mit Hilfe der Fortschreibungsregeln werden die

Daten für die spezielle Sicht der jeweiligen InfoProvider aufbereitet. Kenn-

zahlen, bzw. Merkmale können mit einfachen Formeln oder komplexeren

Routinen bearbeitet werden.

2 Data Warehousing

Abbildung 4 - InfoProvider

Die InfoProvider (mit Ausnahme der ODS-Objekte) bilden im BW die Kompo-

nente des Data Warehouse analog zum Referenzmodell. In ihnen liegen die

Daten ausgerichtet an den Analysebedürfnissen des Anwenders vor. In den

InfoCubes werden auch Aggregate gebildet. Aggregate sind über beliebige

Merkmale aggregierte und persistente Spiegelbilder der InfoCubes. Sie be-

sitzen das gleiche Datenmodell wie der zugrunde liegende InfoCube und

werden erzeugt, um ganz bestimmte Analysen zu optimieren.

SAP selber sieht seine InfoProvider als Basis für das Data Warehouse und

spricht dabei von ,,Data Warehouse Layer" (vgl [Yanko05]). Insbesondere die

ODS-Objekte sollen zum Aufbau dieser Data Warehouse Schicht genutzt

werden. Bezogen auf das Referenzmodell lassen sich die ODS-Objekte des

BW aber sehr gut mit der Definition (nach [BaGü04]) einer Basisdatenbank

vereinbaren. Daten werden dort in niedrigster Granularität in Tabellenform

gesammelt, bereinigt und anschließend in InfoCubes fortgeschrieben.

Daneben lassen sich auch Abfragen direkt auf ODS-Objekten vollziehen.

2 Data Warehousing

Die Fortschreibungsregeln bilden die Ladekomponente für analysespezifi-

sche Daten (s. Abb. Abbildung 5 Fortschreibungsregeln).

Abbildung 5 Fortschreibungsregeln

Auf den InfoProvidern basierend werden die Analysen erstellt. SAP BW bie-

tet hierfür verschiedene Tools an, das wichtigste ist der Query Designer. Er

zeigt die Dimensionen mit ihren Merkmalen sowie die Kennzahlen des ent-

sprechenden InfoProviders (i. d. R. ein Datenwürfel) an, mit denen der Be-

nutzer dann per Drag & Drop eine Abfrage erstellen kann. (s. Abb. Abbildung

6 - Query Designer)

Abbildung 6 - Query Designer

2 Data Warehousing

Zur Präsentation dient ein durch Plug-ins erweitertes MS Excel oder ein mit-

gelieferter Webserver, der HTML-Seiten generiert. Bei beiden Präsentati-

onsmitteln lassen sich die Abfragen bearbeiten, z. B. durch die nachträgliche

Auswahl von Merkmalen oder Filterkriterien. Auch verschiedene Charts las-

sen sich erzeugen. In der Praxis werden oft Analysetools von Drittherstellern

eingesetzt.

Zusammenfassend lässt sich sagen, dass die Komponenten entlang des Da-

tenflusses analog zum Referenzmodell vorhanden sind. Schwieriger gestaltet

sich der Vergleich bei den Komponenten, die eine steuernde Funktion haben.

Dem Data-Warehoue-Manager lässt sich die Administrator-Workbench des

BW zuordnen, da der Benutzer von hier aus alle Aktionen des Staging-

Prozesses steuert. Allerdings fehlt hier die Darstellung der Analysekompo-

nenten. Diese ist in externe Tools (Query Designer, etc) ausgelagert.

Verwirrung bei dem Referenzmodell-BW-Vergleich stiftet der Monitor. Der

Monitor des Referenzmodells überwacht Änderungen in den Datenquellen,

um das inkrementelle Laden zu ermöglichen. Im Business Warehouse exis-

tiert ebenfalls ein ,,Monitor", allerdings mit abweichender Funktionalität. Die-

ser Monitor ist dafür zuständig, den Fortschritt der Ladeprozesse im BW zu

überwachen. Nichtsdestotrotz muss es im System eine Komponente mit der

Funktionalität eines echten Monitors geben sonst wäre das inkrementelle

Laden nicht möglich. Diese Komponente ist aber im Quellsystem integriert,

nicht im BW selber.

Als Stellvertreter für das Repositorium ist im BW das Metadata Repository

vorhanden, welches einen zentralen Einstiegspunkt für die Ansicht und Pfle-

ge der Metadaten bietet. Teil der Metadaten ist z. B. die Kategorisierung

sämtlicher BW-Objekte und die Information darüber, welche ABAP-

Dictionary-Elemente und Programme aufgrund dieser Objekte angelegt wur-

den, wie die BW-Objekte mit Daten versorgt werden, etc. Über die Metadaten

werden das Datenmanagement und die Verarbeitungsschritte des Stagings

2 Data Warehousing

systemweit einheitlich definiert. Ohne diese Informationen kann ein Data-

Warehouse-System schnell zu einer Black Box

werden.

Der Repository-Manager ist die BW-Entsprechung für den Metadaten-

Manager und ermöglicht den Zugriff auf die Metadaten.

Abbildung 7 stellt den Vergleich zusammenfassend dar. Inspiriert von SAP's

Ampelkonzept wurden die Komponenten mit grünen, gelben oder roten Am-

peln versehen, abhängig von der Konformität des BW mit dem Referenzmo-

dell. Abschließend lässt sich feststellen, dass das BW bis auf einige gering

zu gewichtende Abweichungen dem Referenzmodell entspricht.

Black Box: System, das in nicht nachvollziehbarer Weise Daten verarbeitet und speichert

[Mehrwald03]

2 Data Warehousing

Abbildung 7 - BW vs. Referenzmodell

2 Data Warehousing

2.4.3 Das Datenmodell des BW

Das typischerweise in DWH-Systemen verwendete Star-Schema (s.

Abbildung 8 - Star Schema) sieht vor, dass Dimensionen durch einen Di-

mensionsschlüssel identifiziert werden und in der Dimension die Merkmals-

werte abgelegt werden. Merkmale benötigen damit keine weitere Identifikati-

on, sondern stellen sich lediglich durch ihren Wert dar. [Mehrwald03]

Abbildung 8 - Star Schema

Dieses Konzept wurde nicht ins BW übernommen. Auch bei SAP's erweiter-

tem Starschema gibt es eine Faktentabelle, die von Dimensionen umgeben

ist. Doch bestehen die Dimensionen hier aus Dimensionstabelle und Stamm-

datentabellen. Die eigentlichen Dimensionswerte und deren beschreibenden

Attribute sind in den Stammdatentabellen abgelegt und die eigentliche Di-

mensionstabelle bildet nur noch die Verknüpfung zwischen Faktentabelle und

den Stammdatentabellen. (s. Abbildung 9 - erweitertes Star-Schema).

Durch dieses Prinzip lassen sich die Informationen aus den Dimensionen für

mehrere Info-Cubes (Datenwürfel) gemeinsam nutzen, die Stammdaten sind

also übergreifend gültig (vgl. [Hahne03]).

Die Tatsache, dass der Schlüssel der Stammdatentabellen, die SID, immer

vom Typ Integer (4 Byte Länge) ist, kann unter Umständen trotz des aufwän-

digeren Datenmodells positiv für die Performance sein. (vgl. [Mehrwald03])

2 Data Warehousing

Abbildung 9 - erweitertes Star-Schema

Das erweiterte Star-Schema sollte nicht mit dem Snowflake-Schema gleich

gesetzt werden. Beide ähneln sich, beide besitzen verglichen mit dem Stan-

dard Star-Schema weniger redundante Daten. Doch während das Snowfla-

ke-Schema die geringe Redundanz als Ziel verfolgt, wurde das erweiterte

Star-Schema eher im Hinblick auf die gemeinsame Verwendung von

Stammdaten entwickelt.

2.4.4 Kritische Betrachtung des BW

SAP's BW wird von der Fachwelt durchaus kritisch betrachtet. Einer der

Gründer der Data-Warehouse-Idee, Bill Inmon, moniert in seinem White Pa-

per über das BW die geschlossene und proprietäre Architektur. Er bezweifelt

sogar, dass es sich beim BW um ein Data Warehouse handelt (vgl. [In-

mon99]). Allerdings stammt dieser Aufsatz aus dem Jahr 1999 und beschrieb

die Version 2.0a des BW. Inzwischen ist die Version 3.5 aktuell und das BW

hat nur noch wenig mit den ersten Versionen gemein. Im Vergleich mit dem

Referenzmodell wurde bewiesen, dass es sich beim Business Warehouse

um ein ,,echtes" Data Warehouse handelt.

James Goodnight, Gründer und CEO des Analysespezialisten SAS Institute,

behauptet, das SAP BW biete kein Business Intelligence, sondern lediglich

statistische Berichte (vgl. [Alex05]). Die Aussage des Konkurrenten ist offen-

sichtlich stark marketinggetrieben. James Goodnight beschränkt Business

Intelligence auf die Stärken des eigenen Produktes, wobei es sich in erster

Details

Seiten
Erscheinungsform: Originalausgabe
Erscheinungsjahr: 2005
ISBN (eBook): 9783832491192
ISBN (Paperback): 9783838691190
DOI: 10.3239/9783832491192
Dateigröße: 3 MB
Sprache: Deutsch
Institution / Hochschule: Technische Hochschule Köln, ehem. Fachhochschule Köln – Informatik und Ingenieurwissenschaften
Erscheinungsdatum: 2005 (November)
Note: 1,0
Schlagworte: referenzmodell data warehouse business information einführung kosten-nutzen
Produktsicherheit: Diplom.de

Autor

Tobias Kiemes (Autor:in)

Konzeption und prototypische Realisierung von ISE Sales Auswertungen über SAP BW

Zusammenfassung

Leseprobe

Inhaltsverzeichnis

Details

Autor

Tobias Kiemes (Autor:in)