II  Christian Struck  

Bachelor  Thesis  

Inhaltsverzeichnis   

Sperrvermerk   I

Inhaltsverzeichnis   II

Abk  ürzungsverzeichnis  III

Abbildungsverzeichnis   IV

Abstract.   V

1  Einleitung.  1

1.1  Problemdefinition.  1

1.2  Motivation und Zielsetzung  2

1.3  Vorgehensweise und Themenabgrenzung.  3

2  Hintergründe zur Notwendigkeit einer Dokumentation im SAP BW.  4

2.1  Dokumentation  4

2.1.1  Begriff und Einordnung.  4

2.1.2  Bedeutung einer Dokumentation  5

2.1.3  Anforderungen einer Dokumentation.  5

2.1.4  Begriff Metadaten.  6

2.2  Vorstellung SAP BW  7

2.2.1  Die 3-Ebenen-Architektur  8

2.2.2  Datenfluss  10

2.2.3  Metadata Repository.  11

3  Methodik zur Evaluierung von Software  13

3.1  Vorgehensmodelle zur Softwareauswahl  13

3.1.1  Typische Phasenmodelle  14

3.1.2  FinanzIT Prozess „Tool einführen“  15

3.1.3  Vorgehensweise in der Praxis.  17

3.2  Prozessschritte in der Praxis  18

3.2.1  Analyse der Ist-Situation  18

3.2.2  Anforderungsanalyse.  20

3.2.3  Kriterienkatalog.  21

3.2.4  Marktanalyse  24

3.2.5  Entscheidung  26

3.3  Vorstellung der Alternativen  27

3.3.1  Bisheriges Vorgehen.  27

3.3.2  Eigenentwicklung  27

3.3.3  CubeServ BW Documentation Tool.  29

3.3.4  MARCO  31

3.4  Entscheidungsmethodik.  32

3.4.1  Bewertung der Alternativen.  32

3.4.2  Durchführung des Analytic Hierarchy Process  34

3.4.3  Nutzen/Kosten-Verhältnis  37

4  Fazit und Empfehlung.  41

Anhangverzeichnis.   VI

Anhang. VII   

Quellenverzeichnis   XXVII

Abkürzungsverzeichnis

ABAP Advanced Business Application Programming AHP Analytic Hierarchy Process BAPI Business Application Programming Interface BEx Business Explorer BSP Business Server Pages BW Business Information Warehouse CeBIT Centrum der Büro- und Informationstechnik CSV Character Separated Value DB Datenbank DIN Deutsches Institut für Normung e.V. DV Datenverarbeitung GmbH Gesellschaft mit beschränkter Haftung HTML Hypertext Markup Language IEEE Institute of Electrical and Electronical Engineers MARCO Management Report Compliance Analyzer ODS Operational Data Store OE Organisationseinheit OLAP Online Analytical Processing PDA Personal Digital Assistant PDF Portable Document Format PSA Persistent Staging Area PT Personentag VB Visual Basic VDI Verein Deutscher Ingenieure W3C World Wide Web Consortiums WAP Wireless Application Protocol

IV  Christian Struck  

Bachelor  Thesis  

Abbildungsverzeichnis   

Abbildung  1: Entscheidungsprozess nach Heinen.  

Abbildung  2: 3-Ebenen Architektur des SAP BW.  

Abbildung  3: Datenfluss vom Quellsystem bis zum Reporting.  

Abbildung  4: Beispiel aus dem Metadata Repository.  

Abbildung  5: Phasenmodell nach Schinzer.  

Abbildung  6: Phasenmodell nach Kremer.  

Abbildung  7: Phasenmodell nach Lang.  

Abbildung  8: Phasenmodell nach Brenner.  

Abbildung  9: Phasenmodell nach Stahlknecht/Hasenkamp.  

Abbildung  10: Prozess „Tool einführen“  

Abbildung  11: Phasenmodell für die vorliegende Arbeit.  

Abbildung  12: Teilschritte der Marktanalyse.  

Abbildung  13: Anbieterliste nach Marktübersicht.  

Abbildung  14: Vorgehen zur Eigenentwicklung.  

Abbildung  15: Vergleich der Querydokumentation.  

Abbildung  16: Vorgehen von MARCO.  

Abbildung  17: Klassische Methoden zur Nutzenanalyse und Einordnung AHP.  

Abbildung  18: Ergebnis des AHP.  

Abbildung  19: Nutzenwerte der Alternativen  

Abstract

In order to draw conclusions from bugs in production or further development, a complete high quality documentation is necessary. The manual creation of technical documentation in SAP Business Information Warehouse (BW) needs a lot of time in the wheel of deployment and the result does not meet the main requirements at FinanzIT. This is the reason why the staff of the SAP BW group is interested in a new solution, which can automatically create a technical documentation for the SAP BW environment. The following paper aims to describe the procedure of selecting the best software-solution to achieve the objectives und solve the current problems. To make the reader familiar with the problem we are faced with, the first part explains the background of general documentation and the SAP module BW, an information system for management. The presentation of theoretical process models describes the different phases of evaluating software. These findings are then applied to the actual implementation. After analysing possible solutions, only four alternatives come into consideration. In addition to two external software providers, the options are to either make a proprietary development or to do nothing, maintain the current method and accept the situation.

With the aid of the “Analytic Hierarchy Process” (AHP), it is possible to select the best option and to calculate the individual benefits. Its application demonstrates that the proprietary development alternative is the most beneficial. In the next step, the individual costs have to be considered.

Although the preferred alternative to create an own solution is, in the face of investitions, not the cheapest option, it would have the best cost-benefit ratio. This finding results in a recommendation to continue with the implementation of the own solution.

1 Einleitung

In diesem Kapitel findet eine Einführung in das komplexe Thema „Auswahl einer Softwarelösung zur Erstellung einer automatisierten technischen Dokumentation für das SAP Business Information Warehouse in der FinanzIT GmbH“ statt. Dabei soll dem Leser zunächst die grundlegende Problematik aufzeigt werden, aus der die vorliegende Arbeit resultiert. Anschließend werden die Ziele des Unternehmens und die persönliche Motivation des Autors erläutert, sowie die Vorgehensweise und der Aufbau der Arbeit erklärt, damit der rote Faden beim Lesen erkennbar ist.

1.1 Problemdefinition

Die FinanzIT GmbH ist mit rund 2.700 Mitarbeitern und Umsatzerlösen von über 700 Mio. Euro das IT-Systemhaus für Sparkassen, Landesbanken und Landesbausparkassen in elf Bundesländern. Ein IT-Unternehmen dieser Größenordnung stellt von Haus aus hohe Anforderungen an Dokumentationen. Bei der täglichen Arbeit in der OE 4140 (Entwicklung und Integration Rechnungswesen) hat sich herausgestellt, dass auch im SAP Business Information Warehouse (im Folgenden SAP BW genannt) Umfeld der FinanzIT die technische Dokumentation eine große Bedeutung hat. Um Rückschlüsse auf Produktionsfehler oder Weiterentwicklungen zu bekommen, kann eine lückenlose und qualitativ hochwertige Dokumentation sehr wertvoll sein. In der Praxis wird die Dokumentation zurzeit teilweise auf Basis des Metadata Repositories (siehe Kapitel 2.2.3) manuell in einem Word-Dokument erstellt. Dieses Verfahren bringt einige zum Teil gravierende Probleme mit sich. Die manuelle Erstellung erfordert einen unnötig hohen Zeitaufwand, der im Entwicklungszyklus einen Anteil von ca. 20 % ¹ einnimmt. Dabei ist die eigentliche Arbeit nicht schwierig, da lediglich die getätigten Einstellungen in ein zentrales Dokument übertragen werden müssen. In der Praxis werden also die Systemeinstellungen detailliert recherchiert und anschließend in ein aufwendiges Word-Dokument möglichst übersichtlich eingefügt. Bei diesem Vorgehen besteht daher immer die Gefahr von menschlichen Fehlern (eine Einstellung wird übersehen oder falsch übertragen), die nicht gänzlich ausgeschlossen werden können. Da mehrere Mitarbeiter das Dokument pflegen und es noch keine bindenden Richtlinien zur Formatierung und Strukturierung gibt, ist dieses Dokument mit der Zeit immer unübersichtlicher geworden. Da der technischen Dokumentation im SAP BW jedoch eine große Bedeutung zukommt und einige Anforderungen erfüllt sein müssen, wurde der Gedanke nach einer neuen maschinellen Lösung zu suchen immer deutlicher. Dabei

¹ persönliche Mitteilung von Frau Sabine Grenz am 14.05.2007

stellte sich nach einigen Diskussionen innerhalb der Fachgruppe SAP BW, sowie bei fachlichen Gesprächen mit externen Beratern heraus, dass eine softwaregestützte Lösung angestrebt werden sollte, da es bereits einige spezialisierte Anbieter auf diesem Gebiet gibt. Die damit verbundenen Zielsetzungen und die Motivation, die sich in der vorliegenden Bachelor Thesis ergaben, sollen im nächsten Abschnitt genauer erläutert werden.

1.2 Motivation und Zielsetzung

Wie soeben beschrieben, steht im Mittelpunkt der vorliegenden Bachelor Thesis die Vorarbeit, die bei der Durchführung eines Entscheidungsprozesses zur Auswahl eines Dokumentationstools unterstützen soll. Das entsprechende Ziel dieser Arbeit ist es, eine Empfehlung zur Auswahl einer geeigneten Softwarelösung geben zu können. Für die FinanzIT GmbH als Unternehmen ergibt sich durch diese Arbeit die Möglichkeit, nach der Analyse die empfohlene Lösung produktiv einzusetzen und die damit verbundenen Vorteile und Möglichkeiten zu nutzen. Die Zielsetzungen der FinanzIT sind dabei differenziert zu betrachten, da minimale und optionale Anforderungen definiert worden sind, um die auszuwählende Softwarelösung zu evaluieren. Oberste Priorität und damit das minimale Ziel bei der Auswahl einer geeigneten Softwarelösung ist die schlichte automatisierte Dokumentation der Berichtseinstellungen. Besonders in diesem Bereich unterstützt das SAP BW Metadata Repository (siehe Kapitel 2.2.3) nur ungenügend. Ebenfalls ein minimales Ziel ist die Versionisierung der erstellten Dokumentation, um eine lückenlose Änderungshistorie zu erreichen, die einen Nachweis für den Fachbereich darstellt. Die Überlegungen im Vorfeld gehen aber noch ein paar Schritte weiter und verdichten sich in eine Art Vision. So verfolgt das maximale Ziel, neben der Dokumentation aller Objekte des Datenmodells, zusätzlich die Möglichkeit, Freitexte und Kommentare für verschiedene Objekte zu hinterlegen, um auf besondere Sachverhalte hinweisen zu können oder auf besondere Einstellungen des Datenmodells oder der Datenübernahme aufmerksam zu machen. Auch die Möglichkeit einer Impactanalyse, die voneinander abhängige Objekte transparent darstellen kann, wäre wünschenswert. Generell sind also die Intentionen, die bei der Auswahl eines Dokumentationstool verfolgt werden, vielfältig. Sowohl quantitative Faktoren, wie die Verkürzung der Entwicklungszeit, als auch qualitative Faktoren, die die Fehlersuche erleichtern sollen, spielen eine Rolle.

Bei der Auswahl einer neuen Softwarelösung einen Beitrag zu leisten, ist aus Sicht des Autors herausfordernd und motivierend zugleich, da theoretische Erkenntnisse aus den Bereichen Dokumentation, SAP BW, Auswahlprozess und Entscheidung praktisch

angewendet werden können. Darüber hinaus verknüpft das Thema sowohl DVtechnische als auch wirtschaftliche Aspekte und repräsentiert so wesentliche Inhalte eines Wirtschaftsinformatikstudiums.

1.3 Vorgehensweise und Themenabgrenzung

Wie der Lösungsweg in der vorliegenden Arbeit strukturiert ist, um die Motive der FinanzIT GmbH zu berücksichtigen, soll nun die Vorgehensweise vorgestellt werden. Um dem Leser ein Verständnis zur Notwendigkeit einer automatisierten Dokumentation zu liefern, werden in Kapitel 2 theoretische Grundlagen gelegt, die in zwei Bereiche unterteilt sind. Der erste Bereich gibt Hintergrundinformationen zur Dokumentation und stellt typische Anforderungen vor. Im Fokus des zweiten Bereiches steht eine kompakte Beschreibung des SAP BW-Moduls, in dem alle Objekte, die dokumentiert werden sollen, beschrieben und in einen theoretischen Zusammenhang gebracht werden. Im Kontext der gewünschten technischen Dokumentation der Metadaten von SAP BW wird so die grundlegende Problematik einer Dokumentation herausgestellt. Im Anschluss werden im Kapitel 3.1 unterschiedliche Vorgehensmodelle zur Auswahl von Software vorgestellt. Nach Analyse diverser theoretischer Modelle und dem betrieblichen Prozess der FinanzIT, werden die Erkenntnisse in ein individuelles Phasenmodell transformiert, welches den speziellen Anforderungen dieser Toolauswahl gerecht werden soll. Die praktische Durchführung der zuvor definierten Prozessschritte wird anschließend sukzessive erläutert und die jeweiligen Ergebnisse in angemessener Art und Weise in zusammengefasster Form präsentiert.

Nach dem in der Betriebswirtschaft bekannten Entscheidungsprozess nach Heinen ² gibt es zwei Hauptphasen, die in der Abbildung 1 skizziert sind. Die vorliegende Arbeit beleuchtet dabei lediglich die Phase der Willensbildung mit der Intention eine Empfehlung für eine optimale Alternative zu geben. Die anschließende zweite Hauptphase, die Willensdurchsetzung, ist nicht Bestandteil dieser Arbeit und findet daher im Folgenden keine Berücksichtigung.

Abbildung 1: Entscheidungsprozess nach Heinen

² Vgl. Heinen (1992), S. 35 ff.

2 Hintergründe zur Notwendigkeit einer Dokumentation im SAP BW

Der Fokus in diesem Kapitel liegt auf allgemeine Hinweise zu einer Dokumentation. Im Zusammenhang mit den speziellen SAP BW Anforderungen soll dem Leser klar werden, warum eine Dokumentation im BW gebraucht wird und in welcher Hinsicht ein Dokumentations-Tool ein Mehrwert für das BW Umfeld erbringen könnte.

2.1 Dokumentation

Die Dokumentation gilt als ewiges Sorgendkind der Software-Entwicklung, da es eine lästige Daueraufgabe ist, die oft vernachlässigt wird. ³ Doch damit das Wissen über das komplexe SAP BW Umfeld nicht verloren geht, müssen die Einstellungen dokumentiert werden. Dieses Kapitel gibt einen Überblick aller wichtigen Aspekte einer Dokumentation. Zunächst wird der Begriff definiert und in einen thematischen Zusammenhang zum SAP BW gestellt. Anschließend soll die Bedeutung von Dokumentationen im Allgemeinen, sowie der Nutzen für SAP BW im Speziellen, verdeutlicht werden. Da Dokumentationen ein vorgegebenes Schema folgen sollten, werden die grundsätzlichen Bestandteile und Anforderungen diskutiert und Hinweise zu einer qualitativ hochwertigen Dokumentation gegeben. Im letzten Schritt wird der Fokus auf die Metadaten (siehe Kapitel 2.1.4) gesetzt. Dieser Abschnitt ist auch gleichzeitig ausschlaggebend, um die Notwendigkeit einer Dokumentation im BW Umfeld zu unterstreichen. Am Ende sollte deutlich geworden sein, worauf man bei einer Dokumentation, speziell im SAP BW, achten sollte und welche Möglichkeiten ein Softwaretool zur automatischen technischen Dokumentation bieten könnte.

2.1.1 Begriff und Einordnung

Der Begriff Dokumentation wurde Anfang des 20. Jahrhunderts von Paul Otlet als „Sammlung, Ordnung und Nutzbarmachung von Dokumenten aller Art“ ⁴ definiert. Diese allgemeine Definition reicht für die spezielle Art der Dokumentation, mit der sich die vorliegende Arbeit beschäftigt, nicht aus. Um die in Kapitel 2.2 vorgestellten BW-Objekte mit allen Eigenschaften dokumentieren zu können, wird eine so genannte technische Dokumentation verwendet. Merkmal dieser Sonderform der Dokumentation ist die strukturierte Aufbereitung der Informationsinhalte, in der für einen bestimmten Zweck geforderten Art und Vollständigkeit. ⁵ In der Praxis bedeutet dies, dass alle

³ Vgl. Ludewig/Lichter (2007), S. 241.

⁴ Otlet (1907), S. 7 ff.

⁵ Vgl. Deutscher Fachverband für Techn. Kommunikation und Informationsentwicklung (2007).

Einstellungen vollständig und lesbar niedergeschrieben sind, sowie Hinweise und Kommentare auf bestimmte Sachverhalte aufmerksam machen. Die technische Dokumentation dient somit als Nachschlagewerk, welches eine Vielzahl an technischen aber auch fachlichen Informationen beinhalten kann. Ziel sollte eine transparente und dauerhafte Archivierung aller notwendigen Informationen sein.

2.1.2 Bedeutung einer Dokumentation

Damit das Wissen über das SAP BW nicht verloren geht, ist eine technische Dokumentation notwendig. Eine gute Dokumentation ist dabei in mehrfacher Hinsicht von Bedeutung. Zum einen dient sie natürlich als Nachschlagewerk und erleichtert dem Leser die Recherche bei Fehlern oder Problemen. Zum anderen ist die Dokumentation auch bei Weiterentwicklungen von BW-Berichten hilfreich, um die bisherigen Lösungswege im Detail verfolgen zu können. Vor dem Hintergrund, dass Mitarbeiter krankheits- oder urlaubsbedingt nicht immer zu erreichen sind und die Informationen aus dem SAP BW Umfeld dennoch zur Verfügung stehen müssen, bekommt dieser Aspekt einen besonders hohen Stellenwert.

Darüber hinaus ist die Dokumentation ein hervorragendes Kommunikationsinstrument. Die Praxis zeigt, dass es oft zu Missverständnissen zwischen dem Auftraggeber eines BW-Berichtes (dem Fachbereich) und dem Entwickler kommen kann. „Die Dokumentation soll die Kommunikation - ein Schlüsselelement aller großen und erfolgreichen Projekte - zwischen allen Beteiligten unterstützen.“ ⁶ Eine gute technische Dokumentation kann dafür sorgen, dass alle Beteiligten das gleiche Verständnis haben, vor allem dient sie aber auch als Sicherstellung eines aktuellen oder historischen Zustandes.

2.1.3 Anforderungen einer Dokumentation

Alle Arten von Dokumentationen müssen eine Reihe von allgemeinen Grundätzen beachten. Normen wie die DIN EN 62079 ⁷ , Standards wie die IEEE 1063 ⁸ oder Richtlinien zur unternehmensinternen technischen Dokumentation wie die VDI 4500 (Blatt 2) ⁹ geben dem Autor dabei einen Leitfaden zum Erstellen von Dokumentationen. Dieses Kapitel soll einen Überblick auf gewisse Prinzipien geben, die auch in einer technischen Dokumentation für das SAP BW Umfeld berücksichtigt werden sollten.

⁶ Posch/Birken/Gordon (2004), S. 122.

⁷ Vgl. Deutsches Institut für Normung e.V. (2007).

⁸ Vgl. Institute of Electrical and Electronical Engineers (2007).

⁹ Vgl. Verein Deutscher Ingenieure (2007).

Es ist wichtig, die Dokumentation zweck- und zielgruppenorientiert zu gestalten. Da die technische Dokumentation für das SAP BW primär die Erstellung aller Berichte und Objekte dokumentiert, sollten alle relevanten Informationen für die Entwickler dokumentiert werden. An dieser Stelle ist nicht zu vernachlässigen, dass alle getroffenen Entscheidungen in angemessener Art und Weise beschrieben sind. Dabei reicht es häufig nicht aus, den eingeschlagenen Weg zu beschreiben. Es können auch die Alternativen und die Gründe für deren Ablehnung für spätere Änderungen oder Diskussionen wichtig sein. Das wichtigste Kriterium für eine gute technische Dokumentation ist jedoch die Aktualität. Ein veralteter Stand führt zu Missverständnissen, sodass die manuelle Pflege der Dokumentation oft einen hohen Zeitfaktor in Anspruch nimmt. „Wenn es möglich ist, Änderungen automatisch zu dokumentieren, dann sollte es auch getan werden.“ ¹⁰ Diese Erkenntnis ist Grundlage für die Evaluierung einer geeigneten Softwarelösung, die die vorhandenen Metadaten des SAP BW automatisiert dokumentieren kann.

2.1.4 Begriff Metadaten

In der Datenverarbeitung hat sich im Zusammenhang von Dokumentation zunehmend der Begriff Metadaten herausgebildet. Da Metadaten bei der technischen Dokumentation im SAP BW eine große Rolle spielen, soll im Folgenden untersucht werden, wofür der Begriff steht.

Tim Berners-Lee, der Erfinder des World Wide Web und Direktor des W3C (World Wide Web Consortiums), definiert den Begriff Metadaten als „machine understandable information about web resources or other things.“ ¹¹ Metadaten („Daten über Daten“) liefern also Grundinformationen über ein elektronisches Dokument, wie z.B. Angaben über Titel, Autor oder Erstellungsdatum in einem maschinenlesbaren Format. Die in einer größeren Data Warehouse-Lösung (wie SAP BW) zu verwaltenden Informationsobjekte erweisen sich als sehr zahlreich und heterogen und umfassen DV-technische und betriebswirtschaftliche Informationen, die für den Anwender sehr wertvoll sind.

Grundsätzlich beinhaltet eine umfassende Metadatenverwaltung hauptsächlich technische Angaben zu den Datenquellen, zum Transformations- und Ladeprozess, zu den Speicherstrukturen und schließlich zur Nutzung in Form von Abfragen und Auswertungen. Diese Objektsektoren finden sich in der 3-Ebenen-Architektur in BW wieder (siehe Kapitel 2.2.1).

¹⁰ Posch/Birken/Gordon (2004), S. 125.

¹¹ Berners-Lee (1997).

Daneben stößt man häufig auf betriebswirtschaftliche Begriffsdefinitionen, sowie Zuordnungen zu den beteiligten Personen, wie Anwendern oder Administratoren. Eine Ablage aller Metadateninformationen erfolgt üblicherweise in einer speziellen Repository-Komponente des Data Warehouse. ¹² In welchem Umfang das Business Information Warehouse aus dem Hause SAP diese Komponente, das sogenannte Metadata Repository, einsetzt, ist zentraler Untersuchungsgegenstand von Kapitel 2.2.3. Zunächst soll aber eine allgemeine Einführung des BW-Moduls und einige Hintergrundinformationen vorgestellt werden.

2.2 Vorstellung SAP BW

Das SAP Business Information Warehouse (BW) wird von SAP als ein „Data Warehouse zur Unterstützung von strategischen und operativen

Unternehmensentscheidungen“ ¹³ gesehen.

Die zunehmende Bedeutung der Informationsverarbeitung für den Erfolg eines Unternehmens wird häufig unterschätzt. Führungskräfte und Entscheidungsträger (Management) in Unternehmen sehen sich einer Vielzahl von Informationen gegenüber, die Grundlage für Entscheidungen bieten sollten. Die Versorgung des Managements mit validen und aktuellen Informationen zur Wahrnehmung der Führungs-, Steuerungs- und Kontrollaufgaben ist eine hohe und zugleich wichtige Herausforderung. Angemessene Hilfsmittel sind daher notwendig, um aus der „Datenflut“ entscheidungsrelevante Informationen zu gewinnen. Das SAP BW als Data Warehouse Lösung ermöglicht eine zeitnahe Versorgung betrieblicher Entscheidungsträger mit relevanten Informationen zu Analysezwecken. Das SAP Modul befindet sich momentan in der Version 7.0 und ist Teil des weit verbreiteten SAP NetWeaver 2004s. Die FinanzIT GmbH hat Anfang 2004 das BW-Modul eingeführt, welches nach einigen Konsolidierungen mittlerweile ein festes und anerkanntes Controllingwerkzeug ist.

Vor diesem Hintergrund soll der Abschnitt das Modul SAP BW als zeitgemäßes Informationssystem für das Management einordnen und die Lösung anhand der zugrundeliegenden Architektur und eines beispielhaften Datenflusses beschreiben. Als Bindeglied zwischen SAP BW und Dokumentation kann das Metadata Repository gesehen werden. Aus diesem Grund soll diese Komponente des BW das Kapitel abrunden und die Notwendigkeit einer neuen Softwarelösung zur Dokumentation unterstreichen.

¹² Vgl. Hufford (1996).

¹³ SAP Info (2007).

2.2.1 Die 3-Ebenen-Architektur

Die folgende Beschreibung der Systemarchitektur von BW gibt einen Überblick auf die komplexen Zusammenhänge und verdeutlicht die Notwendigkeit einer Dokumentation. Die einzelnen Objekte, die nachvollziehbar dokumentiert werden müssen, werden in diesem Kapitel bereits kurz aufgegriffen. Das in diesem Kapitel vermittelte Wissen kann als Grundlage für den anschließenden Abschnitt verstanden werden, indem ein beispielhafter Datenfluss skizziert wird.

Prinzipiell entspricht der Aufbau des Business Information Warehouse, mit den unterschiedlichen Komponenten, der Referenzarchitektur für ein Data Warehouse (siehe Anhang 1). Ein Data Warehouse-System lässt sich in drei Ebenen untergliedern:

• Datenerfassungsebene mit der Schnittstelle zu den operativen Systemen,

• Datenhaltungsebene mit dem eigentlichen Data Warehouse sowie die

• Datenbereitstellungs- und Präsentationsebene

In der Kombination aller Tools und Funktionsbereiche des BW, sowie der verbundenen Systeme, stellt sich auch das SAP BW als Architektur mit drei Ebenen dar, die nun nachfolgend anhand einer vereinfachten Darstellung in Abbildung 2 ¹⁴ beschrieben werden. Einen Überblick über die detaillierte Gesamtarchitektur des SAP BW liefert Anhang 2.

Abbildung 2: 3-Ebenen Architektur des SAP BW

¹⁴ Vgl. SAP AG (2004), S. 11.

Quellsysteme

Die Extraktionsschicht beschreibt die unterschiedlichen operativen Systeme, aus denen das SAP BW Daten bezieht. Die Quellsysteme, die die Daten liefern, können dabei von SAP Komponenten (R/3, BW), Flat-Files (Excel-Sheets im CSV-Format) oder externen relationalen Datenbanken stammen. Der Zugriff auf die Quellsysteme erfolgt mit Hilfe von Kommunikationsschnittstellen des BW, die vom jeweiligen Quellsystemtyp abhängen. Für die Extraktion von Daten aus SAP R/3-Systemen dienen beispielsweise vorgefertigte Extraktoren. Um Daten aus Fremdsystemen in das BW zu übertragen, werden BAPI (Business Application Programming Interface) Schnittstellen eingesetzt. Die Bereitstellung der Daten erfolgt durch sogenannte DataSources, die auf Anforderungen die Übernahme der Daten starten und ins BW-System replizieren.

SAP BW Server

Die extrahierten Daten aus den Quellsystemen werden in der Ebene des BW Server abgelegt und verwaltet. Grundsätzlich lassen sich dabei Bewegungs-, Stamm- und Metadaten voneinander abgrenzen. Für die Datenablage werden im SAP BW die Speicherbereiche Persistent Staging Area (PSA), Operational Data Store (ODS) sowie InfoCubes genutzt, die unter dem Begriff InfoProvider zusammengefasst werden. Für die Organisation des SAP BW, die Steuerung, Überwachung und Pflege aller Datenbeschaffungsprozesse sorgt die Funktionalität der Administrator Workbench (Transaktion RSA1). Mit Hilfe dieser zentralen Transaktion können alle relevanten Objekte und Prozesse verwaltet und gesteuert werden. Neben der Definition aller relevanten Informationsobjekte im InfoProvider werden über die Administrator Workbench die Ladevorgänge mit Hilfe eines Schedulers geplant und über ein Monitor-Tool überwacht.

Wie die Daten aus den Quellsystemen in die BW Server Schicht und von dort in die BW OLAP Schicht gelangen, zeigt ein repräsentativer Datenfluss in Kapitel 2.2.2.

SAP BW OLAP

Um die in der Speicherkomponente des SAP BW abgelegten Inhalte zweckorientiert analysieren zu können, müssen geeignete Werkzeuge zur Formulierung von Datenbankabfragen und zur freien Navigation im Datenbestand zur Verfügung stehen. Zur Anzeige und Auswertung der gespeicherten Daten kann man den OLAP-Bereich grundsätzlich in drei Komponenten gliedern ¹⁵ , die jeweils auf spezifische Anwendungsfälle ausgerichtet sind:

¹⁵ Vgl. SAP AG (2004), S. 13.