Inhaltsverzeichnis

Abbildungsverzeichnis   IV

Tabellenverzeichnis   V

Abk  ürzungsverzeichnis  VI

1  Einleitung  1

1.1  Problemstellung  1

1.2  Zielsetzung  2

2  Begriffserklärungen und Grundlagen  2

2.1  Entwicklung der Management Support Systeme  3

2.1.1  Management Information System  3

2.1.2  Decision Support System  4

2.1.3  Executive Information System  4

2.2  Data Warehouse System Konzeption und Architektur  4

2.2.1  Datenquellen  6

2.2.2  Extraktion, Transformation und Laden  7

2.2.3  On-line Analytical Processing  9

2.2.4  Multidimensionale Datenmodellierung  10

2.2.5  Data Mining  12

2.2.6  Data Marts  12

2.2.7  Metadaten  13

2.2.8  Business Intelligence  14

3  SAP NetWeaver 2004s BI  16

3.1  Funktionsumfang SAP NetWeaver 2004s BI  17

3.2  SAP BW 7.1.1 als Bestandteil von SAP NetWeaver 2004s BI  17

3.2.1  Architektur des SAP BW  18

3.2.2  Datenbeschaffung im SAP BW  19

3.2.3  Datenbereitstellung und Integration im SAP BW  20

3.2.4  Datenhaltung im SAP BW  21

4  Vorgehensmodelle zur Einführung eines Datawarehouse  23

4.1  Definition eines Vorgehensmodells.  23

4.2  Sequentielle Vorgehensmodelle  24

4.3  Iterative Vorgehensmodelle  26

4.4  Kritische Modellbetrachtung für ein Datawarehouse-Projekt  29

5  Vorgehensmodell zur Einführung einer SAP BI-Lösung  30

5.1  Werkzeuge zur Unterstützung  31

5.2  Projektsteuerung  32

5.3  Aufgabenblöcke innerhalb eines BI-Projekts  33

5.3.1  Projektumfeld.  35

5.3.2  Anforderungsanalyse  39

5.3.3  Projektrealisierung  43

5.3.4  Vorbereitung der Produktivsetzung  50

5.3.5  Going-live und Support  54

6  Problemfelder innerhalb BI-Projekten  58

7  Schlussbetrachtung und Ausblick  59

Literaturverzeichnis   VII

Anhang   VIII

III

Abbildungsverzeichnis   

Abbildung  1 Betriebswirtschaftliche Informationssysteme  

Abbildung  2 Data Warehouse Konzept  

Abbildung  3 Data Warehouse Architektur  

Abbildung  4 ETL-Prozess  

Abbildung  5 Multidimensionaler Datenwürfel mit Klassifikation und Hierarchien  

Abbildung  6 Data Marts Architektur  

Abbildung  7 Unterschiedliche Ansichten zum Begriff Business Intelligence  

Abbildung  8 SAP NetWeaver BI als Teil von SAP NetWeaver  

Abbildung  9 3 Schichten Architektur des SAP BW  

Abbildung  10 Datenbereitstellungsprozess  

Abbildung  11 Beispiel eines Datenmodells für den InfoCube Angebote/Aufträge  

Abbildung  12 Das klassische Wasserfallmodell  

Abbildung  13 Spiralmodell nach Böhm  

Abbildung  14 ASAP-Roadmap  

Abbildung  15 BI-Projektprozessmodell  

Abbildung  16 Beispiel Datenflussdiagramm für den InfoCube Angebote/Aufträge  

IV

Tabellenverzeichnis   

Tabelle 1  Eigenschaften eines Data Warehouse  6

Tabelle 2  Anspruch an die Daten  7

Tabelle 3  Vergleich OLTP zu OLAP  10

Tabelle 4  Vorgehensmodelle und deren Eignung für DWH-Projekte  30

Tabelle 5  Aufgaben der IT-Abteilung und des Fachbereichs  35

Tabelle 6  Frontend-Tools  37

Tabelle 7  Schritte innerhalb der Anforderungsanalyse  VIII

V

Abkürzungsverzeichnis

VI

1 Einleitung

In vielen Branchen werden Unternehmen mit einer großen und ständig wachsenden Datenflut konfrontiert. Zur gleichen Zeit machen diese Unternehmen die Erfahrung, dass die richtige und aussagekräftige Interpretation dieser Daten von sehr großer Bedeutung ist, um beispielsweise die Effizienz zu erhöhen, Kunden näher an sich zu binden und das Geschäftsvolumen weiter zu steigern. Daten bilden daher, im wahrsten Sinne des Wortes, das Rückgrat des Geschäfts. Sie sind Voraussetzung für die Schaffung eines Wettbe-werbsvorteils um Fähigkeiten der Unternehmensleitung präzise messen und Entscheidungen frühzeitig erkennen zu können. Daten dienen aber auch der Planung strategischer Geschäftsinitiativen. So sind nicht wenige Anwendungen und Geschäftsprozesse - z.B. im Customer Relationship Management (CRM), Supply Chain Management (SCM) und in der Unterstützung der Mitarbeiter im Kundenkontakt - im Wesentlichen von der Fähigkeit abhängig, große Datenmengen aus einer Vielzahl von Quellen auswerten zu können. Um diese Datenflut effizient und aussagekräftig zu analysieren, setzten Unternehmen oft auf die Möglichkeit eines Data Warehouse (DWH). Ein DWH ermöglicht es einem Mitarbeiterob Datenerfasser, Manager oder Analytiker - seine Entscheidungen qualitativ gut und schnelOWUHIIHQ]XN|QQHQÄVon solch einem System wird erwartet, dass die richtigen In-formationen zum richtigen Zeitpunkt in der richtigen Menge am richtigen Ort in der erforderlichen Qualität vorliegen, damit die richtigen Entscheidungen getroffen werden kön- QHQ³ 1

1.1 Problemstellung

Doch aussagekräftige Ergebnisse zu erzeugen, ist alles andere als einfach. Dies beginnt bereits in der Heterogenität der Anwendungslandschaft, wie man sie häufig in Unternehmen vorfindet. Hier fallen vor allem hohe Kosten für die Erstellung und Pflege für Schnittstellenprogramme an, was mitunter zur Bildung von sogenannten Insellösungen führt. Unternehmen stellen dann fest, dass sie nicht in der Lage sind, die Vielfalt an Daten aus unterschiedlichen Systemen zu integrieren. Das Potential, welches ein DWH entfaltet, bleibt somit ungenutzt. Viele DWH-Projekte kommen aber erst gar nicht soweit, sondern scheitern bereits in der Startphase. Zu Projektbeginn sind die Ziele und Anforderungen meist unklar, notwendige Ressourcen fehlen und die Projektplanung ist unzureichend.

¹ Krcmar H. 2005, S.54.

1

1.2 Zielsetzung

Um dieses Problem im Vorfeld zu umgehen bzw. zu minimieren und um hohe Kosten auf-grund einer möglichen Restrukturierung zu vermeiden, müssen die spezifischen Gegebenheiten, die an ein DWH-Projekt bzw. im weiteren Sinne an ein Business Intelligence (BI)-Projekt gestellt werden, DXFK %HUFNVLFKWLJXQJ ILQGHQ Ä'LH *estaltung von BI-Anwendungssystemen verlangt den Einsatz eines Vorgehensmodells, das weit über die Funktionalität der traditionellen Modelle der Systementwicklung hinausgeht. Dies ist insbesondere deshalb erforderlich, da das Ziel der DWH-Systementwicklung sich nicht auf die Erstellung eines Anwendungssystem bezieht, sondern den Aufbau einer abgestimmten DWH-Systemlandschaft für den gesamten dispositiven Bereich eines Unternehmens fokusVLHUW³ 2

Die vorliegende Arbeit soll einen Einblick in die methodische Einführung einer BI-Lösung auf Basis von SAP Business Information Warehouse ³ in Unternehmen geben. Da es für das Verständnis unerlässlich ist, werden die Begrifflichkeiten die mit DWH und BI im unmittelbaren Zusammenhang stehen beschrieben. Ein weiteres Kapitel beschäftigt sich mit möglichen Vorgehensmodellen, die für die Einführung von DWH/BI-Projekten in Frage kommen. Anschließend wird ein Vorgehen auf Basis von SAP BW, der Firma SAP ⁴ vorgestellt. Hierbei steht der betriebswirtschaftliche Gesichtspunkt im Vordergrund, der sich bei der Projektplanung und -einführung ergibt. Auf die technischen Gegebenheiten soll nur am Rande eingegangen werden, da zu diesem Thema bereits eine Vielzahl an Literatur erschienen ist. Den Problemen, die sich mit der Einführung und dem Betrieb eines SAP BW ergeben, ist ein eigenes Kapitel gewidmet, wie auch der abschließenden Betrachtung bzw. Zusammenfassung der Arbeit.

2 Begriffserklärungen und Grundlagen

Das nachfolgende Kapitel beschäftigt sich mit den Begrifflichkeiten, die sich mit dem Thema DWH und BI befassen und für die Planung und Einführung eines auf SAP BW basierenden BI-Projekts in Unternehmen als wichtiges Fundament dienen.

² Kemper H.-G., Mehanna W., Unger C. 2004, S. 172.

³ SAP Netweaver 2004s BI

http://www.sap.com/germany/plattform/netweaver/components/businessintelligence, (Stand:09.12.06).

⁴ SAP Deutschland, http://www.sap.com/germany/index.epx, (Stand:09.12.06).

2

2.1 Entwicklung der Management Support Systeme

Durch die Eigenheit große Datenmengen schnell und effizient verarbeiten zu können, wurde die Informationstechnologie schon in früher Zeit fester Bestandteil von Informationssystemen. Technologisch gestützte Informationssysteme, die der Versorgung des Führungssystems mit Informationen zur Planung, Steuerung und Kontrolle dienen, werden im Allgemeinen als Führungsinformationssysteme (FIS) oder Managementsupportsysteme (MSS) bezeichnet. Im Laufe der 1960er Jahre wuchs mit dem technischen Fortschritt in der Computertechnik das Bedürfnis, die neuen Möglichkeiten der Datenverarbeitung zur Aufbereitung von Informationen für die Unternehmensführung zu nutzen. Seit dieser Zeit wurden verschiedene Ansätze, Konzepte und Systeme entwickelt, deren Ziel es war, den Managementprozess in seinen Phasen ebenenübergreifend durch geeignete Mittel zu unterstützen (vgl. Abbildung 1).

2.1.1 Management Information System

Aus der Historie betrachtet stellen die MIS den ersten Beitrag einer gezielten EDV-Unterstützung des Managements dar. Das Konzept des MIS war ein sehr zentraler Ansatz, der versuchte alle entscheidungsrelevanten Informationen aus den operativen Systemen in einem Datenmodell zusammenzuführen und in Echtzeit für die Analyse zu verdichten. Die unflexiblen Datenstrukturen orientierten sich mehr an den operativen Systemen als an den betriebswirtschaftlich notwendigen Erfordernissen der Fach- und Führungskräfte.

⁵ Knöll H.-D. Schulz-Sacharow C., Zimpel M. 2006, S. 40.

3

2.1.2 Decision Support System

Das Ziel einer Verbesserung fachorientierter strukturierter Entscheidungsprozesse verfolgte der nachfolgende Ansatzpunkt der Decision Support-6\VWHPH'66Ä'LHVHLQWHraktiven Systeme griffen auf abgeleitete, entscheidungsrelevante Daten und eine Vielzahl von Methoden und entscheidungsspezifischen Wissen zurück, das durch modellgestützte Analyse-, Prognose- und Simulationsmethoden ermittelt wurde.³ 6

2.1.3 Executive Information System

Während sich MIS und DSS kaum im oberen Management durchsetzen konnten, hatten die auf Präsentation ausgelegten Executive Information-Systeme (EIS) genau diesen Per- VRQHQNUHLVXQGGHVVHQ,QIRUPDWLRQVEHGDUIDOV=LHOJUXSSHÄ$XVO|VHUIUHLQHweitere Novellierung des MIS-Ansatzes waren die aufkommenden personalisierten Benutzeroberflächen und die zunehmende Dezentralisierung sowie Vernetzung der DV-Systeme. Über die reine Versorgung mit relevanten internen und externen Informationen hinaus wurden diese dialog- und datenorientierte Informationssysteme mit umfangreichen Analyse-, Navigations- und Kommunikationswerkzeugen ausgestattet.³ 7

2.2 Data Warehouse System ± Konzeption und Architektur

Das Konzept des DWH (vgl. Abbildung 2) fand in den 1990er als neuere Entwicklung im Bereich der entscheidungsunterstützenden Systeme seinen Ursprung. Auch dieser Entwurf orientiert sich an den Zielen des MIS, entscheidungsrelevante Informationen aus allen Unternehmensbereichen verfügbar zu machen.

⁶ Knöll H.-D., Schulz-Sacharow C., Zimpel M. 2006, S. 41.

⁷ Ebd. S.41.

4

Der Begriff wurde erstmals von W.H. Inmon geprägt:

ÄA Data Warehouse is a subject-oriented, integrated, time-variant, and nonvolatile collection of Data in support of managements Decision support process´ 9

'LHVH 'HILQLWLRQ VFKOLH‰W LQGLUHNW PHKUH $QQDKPHQ HLQ Ä(UVWHQV HLQ 'DWD :DUehouse wird immer auch physikalisch von den operativen Quelldatensystemen getrennt. Zweitens enthält ein Data Warehouse sowohl aktuelle als auch historische Detaildaten [«] Drittens wird die Struktur des Data Warehouse und der Daten in ein zentrales Metadaten- 5HSRVLWRU\KLQWHUOHJW³ ¹⁰ DieInformationen über die Daten bilden das Rückgrat jedes Data Warehouse. In Tabelle 1 werden die Charakteristika der klassischen Data Warehouse Definition nach W.H. Inmon beschrieben:

⁸ Peyer M. (ohne Datum).

⁹ Inmon W.H. 1992.

¹⁰ Kurz A. 1999, S.49.

5

Tabelle 1 Eigenschaften eines Data Warehouse

2.2.1 Datenquellen

Der erste Schritt ist der Vorgang der Datenbeschaffung (vgl. Abbildung 3). Dabei werden kontrolliert Daten aus externen und operativen Quellsystemen extrahiert und transformiert. Die Datenquellen werden meist nicht als Teil des DWH-Systems betrachtet.

Um den anschließenden Extraktions-, Transformations- und Ladeprozess (ETL-Prozess) aber spezifizieren zu können, ist es unabdingbar ebenfalls die Struktur und den Aufbau

6

der Quelldateien mit einzubeziehen. Bei der Datenbeschaffung ist darauf zu achten, dass diese fehlerfrei vorliegen:

2.2.2 Extraktion, Transformation und Laden

Die Aufgabe des Extraktions-, Transformations- und Ladeprozesses besteht in der Zusammenführung aller relevanten Daten in einer unternehmensweiten DatenEDQNÄ1HEHQ den technischen Anforderungen einer Extraktion aus verschiedenen Quellsystemen und der Ablage in eine Zieldatenbank von u.U. erheblicher Größe ist hierbei die Notwendigkeit der Umsetzung von nicht harmonisierten Daten als nicht zu unterschätzendes Problem zu EHDFKWHQ³ ¹¹ Dieser Prozess wird auch als ETL-Prozess bezeichnet und setzt sich aus folgenden Komponenten zusammen:

Die Extraktionskomponente ist für die Übertragung von Daten aus einer Datenquelle in den Arbeitsbereich verantwortlich. Ein Monitoringprogramm unterstützt diesen Vorgang, je nach Strategie des Monitoringprogramm fällt die Extraktion unterschiedlich aus: ÄBei der triggerbasierten Variante sind die geänderten Datensätze aus den entsprechenden Dateien auszulesen >«@ die zeitstempelbasierte Variante erfordert lediglich die Selektion von Datensätzen anhand ihres Zeitstempels. Bei der Log- bzw. Snapshot-Variante hängt das Vorgehen von der gewählten Umsetzung der Log-Analyse bzw. des Snapshot-Vergleichs

¹¹ Egger N. 2004, S.30-31.

7

ab. Werden die als geändert identifizierten Tupel beispielsweise in eine Datei eingetragen, so ist diese Datei zu importieUHQ³ 12

Bei der Transformation werden die Daten vereinheitlicht, verdichtet und angereichert. Dies umfasst die folgenden Phasen: Anpassung von Datentypen, Konvertierung von Kodierungen, Vereinheitlichung von Zeichenketten, Vereinheitlichung von Datumsangaben, Umrechnung von Maßeinheiten sowie der Kombination bzw. Separierung von Attributwerten. Desweiteren sind Quelldaten häufig durch fehlerhafte, redundante, veraltete oder fehlende Werte verunreinigt. Mit Hilfe einer Plausibilitätsprüfung können diese aufgespürt und korrigiert werden.

Nachdem die Transformation vollzogen wurde, befinden sich die bereinigten und angemessen aufbereiteten Daten in einem Arbeitsbereich, die für die Speicherung und spätere Auswertung geeignet sind. Um die Daten weiterleiten zu können, sind derer zwei Ladekomponenten verantwortlich:

- Äeine Komponente zur Übertragung von analyseunabhängigen Detaildaten aus dem Arbeitsbereich in die Basisdatenbank und

- eine Komponente zur Übertragung von analysespezifischen Daten (zum Beispiel Agg- UHJDWHDXVGHU%DVLVGDWHQEDQN³ 14

¹² Bauer A. 2004, S.49-50.

¹³ Eigene Abbildung.

¹⁴ Bauer A. 2004, S.51.

8