Analyse-Prozess-Designer - business . intelligence . institutebusiness-intelligence-institute.org/download/Halboth Analyse... · Kurzfassung - 3 - Kurzfassung Die vorliegende Arbeit

1 Einleitung

- 1 -

Projektarbeit

Thema:

„Analyse-Prozess-Designer“

Funktionen und Einsatzgebiete im SAP

® Business Warehouse

An der Fachhochschule Dortmund

im Fachbereich Informatik

erstellte Projekt-/Diplomarbeit

im Studiengang Wirtschaftsinformatik

in Zusammenarbeit mit der evu.it GmbH, Dortmund

Dennis Halboth

geboren am 13.12.1981

(Matr.-Nr.: 7064539)

Betreuer: Prof. Dr. Engels

Dortmund, 15.03.2009

Markenrechtlicher Hinweis

- 2 -

Markenrechtlicher Hinweis

Die in dieser Arbeit wiedergegebenen Gebrauchsnamen, Handelsnamen,

Warenzeichen usw. können auch ohne besondere Kennzeichnung geschützte Marken

sein und als solche den gesetzlichen Bestimmungen unterliegen. Sämtliche in dieser

Arbeit abgedruckten Bildschirmabzüge unterliegen dem Urheberrecht © des

jeweiligen Herstellers.

SAP, R/3, mySAP ERP, ABAP, BAPI, SAP Business Warehouse (BW), SAP

Customer Relationship Management (CRM), SAP Netweaver und ABAP sind

Marken oder eingetragene Marken der SAP AG, Deutschland.

Microsoft, Microsoft Windows, Microsoft Office, Visio, Word, Excel sind Marken

oder eingetragene Marken der Microsoft Corp., USA.

Kurzfassung

- 3 -

Kurzfassung

Die vorliegende Arbeit befasst sich mit den Funktionen und Einsatzgebieten des

Analyse-Prozess-Designers (APD) im SAP Business Warehouse (SAP BW). Der

APD ist ein vollständig in das SAP BW integriertes Tool, das es ermöglicht, Daten

aus verschiedenen internen und externen Quellen zu verknüpfen und zu

transformieren. So können aus den vorhandenen Daten neue Informationen

gewonnen werden, die von besonderer Bedeutung für ein wirtschaftlich handelndes

Unternehmen sein können.

Der Analyse-Prozess-Designer stellt die konsequente Weiterentwicklung des

Business Warehouse dar, um komplexe Modellierungs- und Analyseprozesse

einfach, übersichtlich und transparent erstellen zu können. Darüber hinaus

ermöglicht er es, Analysen spezifischer und individueller auszuführen, um bei den

stetig steigenden Datenmengen eines Energieversorgungsunternehmens das

Reporting, trotz erhöhter Anforderungen, performant zu gestalten.

Um die Daten dem Analyseprozess zur Verfügung zu stellen, wird zunächst der

ETL-Prozess (Extraktion, Transformation, Laden) der Datenbeschaffung, mit Fokus

auf die Stammdaten, näher betrachtet. Dazu wird das Objektkonzept sowie der

gesamte Datenfluss vom Quellsystem zum Business Warehouse erläutert.

Anschließend erfolgt eine Beschreibung, wie die Funktionen und Möglichkeiten des

Analyse-Prozess-Designers genutzt werden können. Dabei wird deutlich, welchen

Einfluss der APD auf den eigentlichen ETL-Prozess des BW haben kann.

Durch die Abgrenzung der Möglichkeiten des APD von denen des Business

Warehouse wird herausgearbeitet, wie der ETL-Prozess durch die Kombination der

Funktionen optimiert und erweitert werden kann. Es wird dargestellt, wie der

Analyse-Prozess-Designer das Business Warehouse sinnvoll ergänzt und um

Funktionalitäten erweitert, die die Datenmodellierung im BW vereinfachen und

komplexe Prozesse ermöglichen. Zusätzlich werden die wesentlichen Änderungen in

der Entwicklung des APD dargestellt.

Mit Hilfe eines Fallbeispiels erfolgt die exemplarische Umsetzung eines

Analyseprozesses mit definierten Zielsetzungen anhand realer Daten. Dabei wird

offensichtlich, welche Prozesse und Transformationen mit den Möglichkeiten des

Business Warehouse und welche mit den Funktionalitäten des Analyse-Prozess-

Designers vollzogen werden sollten. In diesem Zusammenhang werden weitere

Einsatzgebiete genannt, in denen der APD sinnvoll verwendet werden kann.

Abstract

- 4 -

Abstract

The present work deals with the functions and applications of the Analysis Process

Designer in SAP Business Warehouse. The APD is a full-fledged SAP BW

integrated tool that enables to link-up as well as transform the data between different

internal and external data sources. In this way from the existent data, new

information can be gained and used for all decision and application processes and

thus can be decisive in many respects (strategically, tactically and operatively).

The APD represents the consistent further development of Business Warehouse,

where complex modelling and analyze processes are made simple, clear and

transparent. Moreover, it allows analysis to be specific and individual in order to

tackle the steadily increasing data of an energy supplying company despite

increasing demands to generate reports.

For the availability of the data of the analysis process, initially the ETL process of

the data acquisition, having the focus on the master data, is closely observed. In

addition to that, the object concept and the complete dataflow from the source system

to the Business Warehouse are elucidated.

This is followed by a description of how the features and the capabilities of Analysis

Process Designer can be used. It makes clear what impact the APD can have on the

ETL process of the BW.

The separation of the possibilities of the APD with those of Business Warehouse are

identified and developed. It describes how the ETL process, by means of the

combination of the functions in APD and BW, can be optimized and extended. It is

hence made clear how the APD is sensibly supplemented with the Business

Warehouse and the functionalities are therefore complimented. This helps the data

modelling in BW to be simple and allows complex processes. In addition, the

significant changes in the development of the APD are demonstrated.

With the help of an example, an analysis process with defined objectives can be

successfully implemented for actual data. It would therefore be clear which processes

and transformations should be completed with the BW, and which with the

functionalities of APD. In this context, further areas are mentioned where the APD

can be implemented.

Inhaltsverzeichnis

- 5 -

Inhaltsverzeichnis

1 Einleitung .................................................................... 7

1.1 Beschreibung der Thematik .......................................... 7

1.1.1 evu.it GmbH ..................................................................................... 7

1.2 Zielsetzung der Arbeit ................................................... 8

1.3 Abgrenzung .................................................................. 9

1.4 Eingesetzte Software .................................................... 9

2 ETL-Prozess der Stammdatenbeschaffung ............ 11

2.1 ETL-Prozess ............................................................... 11

2.2 Stammdaten im SAP BW ............................................ 14

2.3 Objektkonzept im SAP BW 3.x ................................... 15

2.4 Business Content ........................................................ 21

2.5 ETL-Prozess für Stammdaten im SAP BW 3.x ........... 22

2.5.1 Übertragungsregeln ....................................................................... 23

2.5.2 Fortschreibungsregeln ................................................................... 24

2.5.3 Direkte Fortschreibung .................................................................. 25

2.5.4 Flexible Fortschreibung ................................................................. 26

2.5.5 Verbuchungsarten ......................................................................... 27

2.5.6 Delta-Verfahren ............................................................................. 28

2.6 Änderungen im BW 7.0 ............................................... 30

3 Analyse-Prozess-Designer ....................................... 33

3.1 Integration des APD in das SAP BW .......................... 34

3.2 Prozessphasen ........................................................... 34

3.2.1 Phase 1 - Datenquellen ................................................................. 35

3.2.2 Phase 2 - Transformationen .......................................................... 37

3.2.3 Phase 3 - Datenziele ..................................................................... 44

3.3 Anwendungen ............................................................. 46

3.4 Funktionsweise ........................................................... 47

3.5 Versteckte Funktionen ................................................ 49

3.6 Abgrenzung zu den Möglichkeiten im BW .................. 50

3.7 Auswirkungen des APD auf den ETL-Prozess ............ 51

3.8 Unterschiede zwischen den Versionen des APD ........ 52

4 Fallbeispiel „Anlagen-Analyse“ ............................... 53

4.1 Einführung in die Thematik ......................................... 53

4.1.1 SAP for Utilities .............................................................................. 53

4.1.2 IS-U Haus ...................................................................................... 55

4.1.3 Ablauf der Vertragsabrechnung .................................................... 57

Inhaltsverzeichnis

- 6 -

4.2 Zielsetzung ................................................................. 59

4.3 Konzept ....................................................................... 60

4.4 Datenauswahl ............................................................. 61

4.5 Datenbeschaffung ....................................................... 64

4.6 Analyseprozess .......................................................... 66

4.6.1 Grundlegender Ablauf ................................................................... 67

4.6.2 Detaillierte Modellbeschreibung .................................................... 67

4.7 Datenspeicherung ....................................................... 81

4.8 Datenauswertung ........................................................ 82

4.9 Optimierungen ............................................................ 84

5 Abschluss .................................................................. 86

5.1 Zusammenfassung ..................................................... 86

5.2 Fazit ............................................................................ 86

5.3 Ausblick ...................................................................... 87

6 Anhang ...................................................................... 90

6.1 Anlagen-Analyse-Prozess ........................................... 90

6.2 A selection of useful ISU-Tables ................................. 91

6.3 ABAP-Routine des Analyseprozesses ........................ 92

7 Abkürzungsverzeichnis ............................................ 94

8 Abbildungsverzeichnis ............................................. 95

9 Tabellenverzeichnis .................................................. 98

10 Listingverzeichnis .................................................... 99

11 Quellenverzeichnis ................................................. 100

12 Glossar .................................................................... 103

13 Eidesstattliche Erklärung ....................................... 107

14 Stichwortverzeichnis .............................................. 108

1 Einleitung

- 7 -

1 Einleitung

1.1 Beschreibung der Thematik

Mit der Neuregelung des Energiewirtschaftsgesetzes (EnWG) im Jahre 1998 und

dem „Zweiten Gesetz zur Neuregelung des Energiewirtschaftsrechtes“ 2005 kam es

zu einer Liberalisierung und Öffnung des Energiemarktes. Dies führte zu

tiefgreifenden Veränderungen in der Energiebranche, insbesondere in der IT der

Versorgungsunternehmen. Die neue Konkurrenzsituation und der daraus

resultierende Zwang zum wirtschaftlichen Handeln führten zu einer verstärkten

Nutzung der operativen ERP-Systeme und damit auch zu einem enormen Anstieg der

vorhandenen Datenmengen. Um diese Datenmengen verarbeiten, vor allem aber

auswerten zu können, wurden zunehmend Data Warehouse Lösungen eingesetzt.

Der Grundstein zu einer optimierten Analyse der vorhandenen Massendaten ist also

gelegt. Nun sollen im nächsten Schritt, durch Verbindung verschiedenster Daten,

Auswertungen ermöglicht werden, die es erlauben, die vorhandenen Bestands- und

Vorgangsstatistiken abzulösen und zu entlasten, einzelne Statistiken zu erweitern und

miteinander zu verknüpfen. Dadurch sollen neue, nicht triviale Zusammenhänge

sichtbar gemacht werden, die die Produktivität und Wirtschaftlichkeit von

Versorgungsunternehmen weiter erhöhen können.

Mit Hilfe des Analyse-Prozess-Designers wurde im SAP Business Warehouse die

Basis geschaffen um solche Verknüpfungen und komplexen Transformationen der

Daten durchführen zu können. So können verschiedenste interne und externe

Datenquellen miteinander kombiniert, transformiert und anschließend analysiert

werden.

1.1.1 evu.it GmbH1

Die evu.it GmbH ist ein international tätiges Beratungsunternehmen für die Ver- und

Entsorgungswirtschaft, die öffentliche Verwaltung sowie dem öffentlichen

Personennahverkehr. Mit ihrem Hauptsitz in Dortmund, sowie weiteren Standorten

in Kiel, Mannheim, Nürtingen und Rostock, bietet die evu.it GmbH ein breites

Angebot an Beratungs- und Entwicklungsleistungen mit Schwerpunkt auf die

Produkte SAP sowie Microsoft Dynamics NAV.

1 Vgl. [EVU-IT, 2008]

1 Einleitung

- 8 -

Die Geschäftsbereiche der evu.it GmbH untergliedern sich wie folgt:

■ Enterprise Solution Consulting

■ Billing

■ Business Intelligence

■ Customer Relationship Management

■ Energy Data Management

■ Enterprise Resource Planning

■ Public Sector

■ Development

Die evu.it GmbH ist eine 100%ige Tochter der rku.it GmbH in Herne. Das

Leistungsangebot der rku.it GmbH umfasst neben der Bereitstellung von

Anwendungssystemen und deren individueller Anpassung auch das Hosting von

Systemen im rku.it-Rechenzentrum. Umfangreiche Schulungsprogramme und

umfassender Support runden das Leistungsspektrum ab.

1.2 Zielsetzung der Arbeit

Ziel dieser Arbeit ist es, anhand eines Fallbeispiels die Möglichkeiten,

Funktionsweisen und Einsatzgebiete des Analyse-Prozess-Designers zu erörtern.

Dazu ist es zunächst erforderlich, Daten aus den verschiedenen Datenbanktabellen

eines SAP R/3 Quellsystems in das SAP BW zu transferieren, um die Daten dem

APD zur Verfügung stellen zu können. Dort werden sie, entsprechend der

Zielsetzung der Fallstudie, mit Hilfe der Funktionalitäten des APD verknüpft,

aggregiert, eingeschränkt, erweitert, transformiert und zur späteren Auswertung in

ein geeignetes Datenziel gespeichert.

Darüber hinaus soll deutlich werden, wie der APD in das SAP BW eingebunden ist,

welche Auswirkungen der Einsatz des Tools auf den eigentlichen ETL-Prozess

(Extraktion, Transformation, Laden) des BW haben kann und wie der Einsatz des

APD sinnvoll mit den Funktionalitäten des Business Warehouse kombiniert wird.

Zusätzlich gilt es die Entwicklung des APD in Bezug auf dessen Funktionalität

zwischen den SAP BW Versionen 3.x und 7.0 festzuhalten.

1 Einleitung

- 9 -

1.3 Abgrenzung

Der Analyse-Prozess-Designer stellt im eigentlichen Sinne die Arbeitsumgebung der

SAP Data Mining Lösung dar, in der die Daten für die spezifischen Verfahren des

Data Mining vorbereitet werden. Insbesondere ab der BW Version 3.5 ist eine enge

Verknüpfung zwischen dem APD und dem Data Mining festzustellen.

Die Möglichkeiten des Data Mining sollen jedoch nicht Bestandteil dieser

Projektarbeit sein, sondern werden in der darauf aufbauenden Diplomarbeit

detailliert betrachtet.

Darüber hinaus werden die Grundlagen bezüglich des Data Warehouse Konzeptes,

der Ebenen des Data Warehouses sowie der Modellierung multidimensionaler

Datenräume (einfaches Star-Schema, Snowflake-Schema usw.) in dieser Arbeit nicht

näher erläutert.1

1.4 Eingesetzte Software

Die offiziellen Produktbezeichnungen der SAP sind recht unübersichtlich. Bis zu der

Version 3.3 wird das System als „SAP Business Information Warehouse“ bezeichnet.

Die Bezeichnung des Nachfolgers lautet „SAP Netweaver 2004“. Das aktuellste in

dieser Arbeit verwendete System trägt die offizielle Bezeichnung „SAP Netweaver

7.0“ bzw. „SAP Neatweaver 2004s“. Das neueste derzeit verfügbare System ist

„SAP Netweaver 7.1“.

Obwohl SAP den Begriff BW nicht mehr verwenden möchte, haben sich in der

Praxis, sowie in einem Großteil der Literatur die inoffiziellen Bezeichnungen BW

3.x bzw. BW 7.0 durchgesetzt. Deshalb werden auch in dieser Arbeit die Begriffe

SAP BW 3.x (für die Versionen 3.1.und 3.5) sowie BW 7.0 verwendet.

Folgende SAP-Systeme kommen zum Einsatz:

■ SAP Business Warehouse 3.1 Testsystem der evu.it

(interne Bezeichnung TB1)

■ SAP BI 7.0 Testsystem der rku.it und evu.it

(interne Bezeichnung T7B)

■ SAP R/3 4.6c mit IS-U (Industry Solution for Utilities)-Modul2

(interne Bezeichnung EE1)

■ SAP GUI 640 mit Business Explorer (BEx Analyzer, BEx Query Designer)

Die Umsetzung der Fallstudie erfolgt im Testsystem TB1 (BW 3.1), da dieses an das

R/3 Quellsystem (EE1) angeschlossen ist und eine performante Durchführung der

1 Weiterführende Informationen siehe [Kemper et al., 2006] S.17ff, [Egger et al., 2005] S.21ff,

[Gómez et al., 2006] S.3ff, [BW310, 2005] S.2ff, [Mehrwald, 2007] S.47ff

2 Siehe auch Abschnitt 4.1.1, SAP for Utilities, auf Seite 54

1 Einleitung

- 10 -

Beispielanwendung ermöglicht. Obwohl das System nicht die neueste Version des

SAP BW darstellt, haben sich die wesentlichen Konzepte nicht verändert. Die

bedeutenden Änderungen im Bereich des Objektkonzepts und des Datenflusses

werden jedoch kurz erläutert.

Das System EE1 ist eine Kopie eines älteren Kundensystems und stellt daher die

ideale Basis für die Datenbeschaffung und Analyse mit realen Daten dar.

Das System T7B (BW 7.0) wird genutzt, um die wesentlichen Unterschiede in der

Funktionalität des APD im Vergleich zum SAP BW 3.x zu erläutern.

2 ETL-Prozess der Stammdatenbeschaffung

- 11 -


Dieses Kapitel beschreibt den ETL-Prozess für Stammdaten sowie dessen

Umsetzung im SAP Business Warehouse. Im weiteren Verlauf wird nicht nur der

Prozess der Datenbeschaffung, sondern auch das zugrunde liegende Objektkonzept

im BW 3.x detailliert erläutert. Abschließend werden die grundlegenden Änderungen

und Neuerungen des Datenflusses im SAP BW 7.0 angesprochen.

2.1 ETL-Prozess

»Ein Ziel des ETL-Prozesses […] ist es, die Daten der Quellsysteme, die an den

operativen Abläufen ausgerichtet sind, in eine für die Entscheidungsunterstützung

optimierte Verwendungssicht zu transformieren und schließlich in den [Datenzielen]

dauerhaft zu speichern, ein anderes Ziel ist die Konsolidierung von Daten

unterschiedlicher Quellsysteme.«1

Der ETL-Prozess ist der wichtigste und zugleich aufwändigste Schritt im Data

Warehousing.

»Die Vielzahl unterschiedlicher Datenquellen, das unter Umständen beträchtliche

Datenvolumen sowie die komplexen Konsolidierungsvorgänge zur kontinuierlichen

Datenversorgung des Data Warehouse stellen eine große Herausforderung an die

IT-Abteilung, die beteiligten Systeme und die Werkzeuge dar.«2

Der ETL-Prozess wird in die folgenden Phasen unterteilt3:

■ Extraktion

Auswahl und Replikation der relevanten Daten im Quellsystem

■ Transformation

Konsolidierung und Transformation der Daten

■ Laden

Übernahme der Daten in das Data Warehouse

Der Prozess ist von entscheidender Bedeutung für den weiteren Verlauf des Data

Warehousing Prozesses, da nur auf Basis einer hohen Datenqualität aussagekräftige

Analysen und Auswertungen durchgeführt werden können. Man spricht in diesem

1 Vgl. [Seemann et al., 2001] S.142

2 Vgl. [Gómez et al., 2006] S.33

3 Siehe [Egger et al., 2005] S. 44 ff


- 12 -

Zusammenhang auch vom sogenannten „Garbage in, Garbage out“-Syndrom. Wenn

fehlerhafte, doppelte, inkonsistente oder anderweitig qualitativ minderwertige Daten

vorliegen, werden alle nachfolgenden Prozesse der Analyse beeinflusst. Dies führt zu

fehlerhaften Aussagen und damit zu falschen operativen oder strategischen

Entscheidungen.

Abbildung 1: Der ETL-Prozess

Der ETL-Prozess wird unterstützt durch das Metadata Repository, das alle Objekte

des BW sowie deren Beziehungen zueinander enthält. Metadaten werden oft als

„Daten über Daten“ bezeichnet. Das Metadaten Repository verwaltet diese Daten

und erlaubt ein konsistentes und homogenes Datenmodell über alle Ebenen des Data

Warehouse- und ETL-Prozesses hinweg.

Die einzelnen Phasen des ETL-Prozesses werden im Folgenden näher betrachtet.


- 13 -

Extraktion

Die Phase der Extraktion dient der Auswahl und Replikation von Daten aus

verschiedenen heterogenen und operativen Quellsystemen. Zu diesem Zweck werden

Regeln für die Verbindung des Quellsystems mit dem Data Warehouse sowie für die

Übertragung der Daten erzeugt.

Bei der erstmaligen Ausführung des Datenimports müssen alle Daten geladen

werden. Dies hat eine erhöhte Belastung der Quellsysteme zur Folge, weshalb dieser

Prozess in einem Zeitraum gestartet werden sollte, in dem die notwendigen

Ressourcen zur Verfügung stehen, z.B. nachts oder am Wochenende.

Bei Änderungen im Quellsystem, nach dem initialen Extraktionsvorgang, ist es

möglich ein Delta-Verfahren (siehe Abschnitt 2.5.6) zu verwenden, um so nur noch

die Daten nachladen zu müssen, die seit dem letzten Extraktionsvorgang neu

hinzugekommen sind, sich verändert haben oder gelöscht wurden.

Um die Datenmenge weiter zu reduzieren ist es möglich, schon vor dem eigentlichen

ETL-Transformationsvorgang Abfragen und Transformationen direkt auf den Daten

im operativen Quellsystem durchzuführen. So kann die Anzahl der zu übertragenden

Datensätze, z.B. mittels View oder durch Änderungen an den Extraktionsstrukturen,

auf das Nötigste beschränkt werden, um damit auch die nachgelagerten ETL-

Prozesse schon im Vorfeld zu optimieren.

Transformation

Die Heterogenität der verschiedenen Quellsysteme führt in der Regel zu Problemen

bei der Überführung in das Data Warehouse.

Dies können beispielsweise folgende sein:

■ fehlende Werte

■ unterschiedliche Datentypen

■ unterschiedliche Formatierungen

■ verschiedene Attribute mit gleichem Attributnamen

■ unterschiedliche Werte für gleiche Attribute

■ Dubletten

■ redundante Datensätze

■ …

Diese Inkonsistenzen und fehlerhaften Daten gilt es zu beseitigen, um eine möglichst

hohe Datenqualität als Basis der nachfolgenden Prozesse zu erreichen. Denn nur

durch Datenkonsistenz und -qualität lässt sich das Vertrauen in die Daten steigern.

Zudem wird die Möglichkeit der Rückkopplung zu den operativen Systemen

geschaffen.


- 14 -

»Der Schlüssel zum Erfolg in der Implementierung und dem Betrieb von Business-

Intelligence-Applikationen liegt nicht in der erfolgreichen Implementierung

irgendwelcher Datenqualitätswerkzeuge, sondern im Management des Daten-

qualitätsprozesses, was eine kontinuierliche Aufgabe ist.«1

Laden

Die abschließende Phase des ETL-Prozesses befasst sich, nach der Extraktion,

Transformation und Bereinigung, mit dem Laden der ausgewählten Daten in das

Data Warehouse und den darin spezifizierten Datenzielen. Um Inkonsistenzen zu

vermeiden, werden während des Ladevorganges die zu übertragenden Tabellen

gesperrt. Das Laden der Daten belastet lediglich das Data Warehouse und nicht, wie

beim Extraktionsvorgang, das Quellsystem.

2.2 Stammdaten im SAP BW

Als Stammdaten werden im Allgemeinen jene Daten bezeichnet, die über einen

längeren Zeitraum unverändert bleiben. Oftmals sind es Informationen, die an

verschiedenen Stellen immer wieder benötigt werden.

Im SAP BW gibt es verschiedene Arten von Stammdaten2:

■ Texte

Mit bis zu drei Textbeschreibungen (Kurz-, Mittel- und Langtext) kann ein

Stammdatum näher beschrieben werden, wenn dessen Werte alleine nicht

ausreichend verständlich sind, z.B. bei Abkürzungen eines Länderschlüssels. Die

unterschiedlichen Längen der Texte sind deshalb sinnvoll, da auf der einen Seite

kürzere Texte u.a. bei Auswertungen übersichtlicher sind, wohingegen in anderen

Situationen längere Texte zum besseren Verständnis beitragen. Sie können

sprach- und zeitabhängig gespeichert werden, da auch in Bezug auf Stammdaten

Änderungen in einem Unternehmen auftreten können, z.B. beim Materialnamen

zu einer Materialnummer. Die Zeitabhängigkeit geht jedoch zu Lasten der

Performance und sollte daher nur sinnvoll angewendet werden.

■ Attribute

Attribute sind Felder, die Stammdaten mit Hilfe zusätzlicher Informationen näher

beschreiben. Beispiel für ein solches Attribut ist die Materialgruppe zu einer

Materialnummer. Attribute sind Objekte, die beliebig viele weitere Objekte (und

damit Attribute) besitzen können. So beinhaltet das Objekt Kunde als Attribute

beispielsweise den Kundennamen und die Kundenadresse. Attribute können,

ähnlich wie die Texte, zeitabhängig sein, d.h. sie besitzen einen definierten

Gültigkeitszeitraum.

1 Vgl. [Egger et al., 2005] S. 49

2 Siehe [Gómez et al., 2006] S.58 ff


- 15 -

■ Hierarchien

»Eine Hierarchie bildet eine Zusammenfassung und Gliederung eines Merkmals

nach individuellen Ordnungskriterien«1, z.B. die Kostenstellenhierarchie. In Form

einer Baumstruktur werden einzelne Knoten in die Hierarchie eingegliedert. Die

Bezeichnung und die Hierarchie selbst können zeit- und versionsabhängig

abgelegt werden, um so z.B. organisatorischen Änderungen Rechnung zu tragen.

2.3 Objektkonzept im SAP BW 3.x

In den folgenden Abschnitten wird das Objektkonzept des SAP Business Warehouse

3.x. näher beschrieben.2 Dabei werden alle wichtigen Objekte, die für die

Übertragung, Fortschreibung und Analyse der Daten notwendig sind, erläutert. Das

gesamte Datenmodell des Business Warehouse basiert auf diesen Objekten.

Der Datenfluss, also die Verknüpfung der einzelnen Objekte im Datenmodell, wird

in Abschnitt 2.5 erläutert.

Im Vergleich zum BW 3.x, gibt es im SAP BW 7.0 einige Änderungen bezüglich des

Datenflusses und der dafür benötigten Objekte. Auf die wesentlichen Unterschiede

wird im Abschnitt 2.6 kurz eingegangen.

InfoObject

InfoObjects sind die kleinsten Einheiten im SAP Business Warehouse. Sie werden

oft auch als betriebswirtschaftliche Auswertungsobjekte bezeichnet und bilden die

Basis aller größeren BW-Objekte.

Abbildung 2: Verwendung von InfoObjects im SAP BW

3

1 Vgl. [SAPBib3x, 2008]

2 Siehe [SAPBib3x, 2008], [BW310, 2005] S. 45ff, [Gómez et al., 2006] S.63 ff

3 In Anlehnung an [BW310, 2005] S.46


- 16 -

Es gibt unterschiedliche Typen von InfoObjects:

■ Kennzahl

■ Merkmal

■ Zeit

■ Einheit

■ Stammdatentragende Merkmale

Kennzahl

InfoObjects vom Typ „Kennzahl“ enthalten die Werte, die im späteren Verlauf

ausgewertet werden sollen, z.B. Menge, Betrag, Umsatz. Diese quantitativen Zahlen

müssen immer mit Merkmalen in Verbindung gebracht werden, da sonst ein Bezug

der Zahlen zu bestimmten Geschäftsvorfällen nicht möglich ist.

Kennzahlen werden in der Analyse mittels arithmetischer Operationen

zusammengefasst und ausgewertet. Sie können auch aus anderen Kennzahlen

abgeleitet werden, z.B. Bestandskennzahlen mit Hilfe der Bestandsveränderungen.

Merkmal

Merkmal-InfoObjects dienen dazu, die Kennzahlen zu beschreiben. Beispiele sind

Material, Kundengruppe, Produkt oder Lieferant. Ohne einen betriebs-

wirtschaftlichen Bezug der Kennzahlen zu bestimmen Merkmalen kann somit kein

sinnvolles Reporting durchgeführt werden.

Merkmale werden in den Dimensionen abgelegt und bestimmen damit die

Granularität (Feinheitsgrad) der Kennzahlen innerhalb eines multidimensionalen

Datenziels.

Stammdatentragendes Merkmal

Von stammdatentragenden Merkmalen spricht man, wenn Merkmale Attribute, Texte

oder Hierarchien besitzen. So ist es möglich, dass Merkmale beliebig viele Attribute

(in Form von InfoObjects) enthalten. Beispielsweise kann das Merkmal Kunde ein

InfoObject Kundenadresse (Merkmal) und ein InfoObject letzter Umsatz (Kennzahl)

enthalten.

Stammdatentragende Merkmale können darüber hinaus einerseits Datenziele für die

Speicherung von Daten im BW sein, andererseits als Datenquellen für Analysen

genutzt werden.


- 17 -

Zeit

Zeitmerkmale ermöglichen die Berücksichtigung eines zeitlichen Bezugs bei der

Analyse von Daten. Sie haben direkten Einfluss auf die Granularität. Beispiele für

zeitliche Merkmale sind Kalendertag, Kalenderjahr, Geschäftsjahr oder

Kalenderwoche.

Zeitmerkmale können zwar nicht neu definiert, jedoch modifiziert werden und bieten

darüber hinaus die Möglichkeit der automatischen Berechnung von Zeiten. So kann

z.B. auf Basis der Kalenderwoche, der Kalendermonat berechnet werden.

Einheit

Einheiten-InfoObjects werden dazu verwendet, Kennzahlen mit Einheiten zu

versehen, z.B. Währung oder Mengeneinheit.

DataSource

DataSources stellen das zentrale Element zur Datenbeschaffung dar.

»Eine DataSource beschreibt jeweils eine betriebwirtschaftliche Einheit von Stamm-

oder Bewegungsdaten (z.B. Kostenstellenrechnung), die aus einem Quellsystem

extrahiert werden kann.«1

In Abhängigkeit von den zu extrahierenden Daten unterscheidet man zwischen

DataSources für Bewegungsdaten, Attribute, Texte und Hierarchien.

Sie stellen zwei Feldstrukturen für die Extraktion und die Übertragung der Daten aus

dem Quellsystem zur Verfügung:

■ Extraktstruktur

Durch die sogenannten Extraktoren werden im Quellsystem die Daten in Form

einer Tabelle gesammelt. Die Felder dieser Tabelle bilden eine flache Struktur, die

sogenannte Extraktstruktur. Alle Daten in der Extraktstruktur sind lediglich

temporär gespeichert und werden unverändert an die Transferstruktur

weitergereicht.

■ Transferstruktur

Die Transferstruktur bildet den Übergang vom Quellsystem zum BW. Sie enthält

wahlweise alle oder nur einen ausgewählten Teil der Felder der Extraktstruktur.

InfoSource

Eine InfoSource beinhaltet alle Daten, die zu einem Geschäftsvorfall oder einer

bestimmten Art von betriebswirtschaftlichen Vorgängen gehören. Sie besteht aus

einer Vielzahl an InfoObjects, die zusammengefasst die sogenannte

Kommunikationsstruktur bilden. Dabei werden einer InfoSource eine oder mehrere

DataSources zugewiesen. Entsprechend der Kommunikationsstruktur der InfoSource,

können die Daten dann von der DataSource übernommen werden.

1 Vgl. [BW350, 2005] S.17


- 18 -

Die InfoSource stellt demnach eine Art Sammelstelle dar, an der die Daten

zusammengeführt, strukturiert, gefiltert und ggf. auch schon transformiert werden

können.

Persistent Staging Area

Die Persistent Staging Area (PSA) ist ein temporärer Zwischenspeicher. Beim

Übertragungsvorgang der Daten aus dem Quellsystem, werden die Daten

unverändert (bis auf technische Konvertierungen) in transparenten Tabellen abgelegt.

Auf diese Weise können die Quelldaten, die denen aus der Transferstruktur

entsprechen, bezüglich ihrer Qualität überprüft und bei Bedarf modifiziert werden.

Obwohl die Daten aus den PSA-Tabellen auch in einem späteren Prozess weiter

fortgeschrieben werden können, wird die PSA nicht zur dauerhaften Speicherung

verwendet, sondern als Zwischenspeicher verstanden.

Die Verwendung der PSA ist eine von zwei möglichen Transfermethoden im SAP

BW. Eine Alternative ist die IDOC Interface Technology (Intermediate Document).

Hierbei werden die Daten in IDOC-Container verpackt und anschließend verschickt.

Auch die PSA verwendet die IDOC-Schnittstelle, jedoch nur um Informationen

bezüglich des Quellsystems zu versenden, z.B. die Anzahl der Datensätze oder

Monitorinformationen.1

InfoCube

Der InfoCube dient der physischen Speicherung sowie der Bereitstellung der Daten

für die Analysen. Er ist das zentrale multidimensionale Objekt der Datenhaltung im

SAP BW und besteht aus InfoObjects (Kennzahlen und Merkmale), die nach dem

sogenannten „erweiterten Sternschema“2 miteinander verknüpft sind (siehe

Abbildung 3).

Dieses Schema, das auch als SAP BW Sternschema bezeichnet wird, besteht aus der

Faktentabelle, den Dimensionstabellen sowie den SID-Tabellen (Surrogat-ID). Die

Faktentabelle enthält die Fakten, also die Kennzahlen, die zu einer bestimmten

Merkmalkombination gehören. Die Dimensionstabellen werden über eine

Schlüsselbeziehung mit der Faktentabelle verknüpft.

1 Weiterführende Informationen siehe [SAPBib3x, 2008]

2 Siehe [BW310, 2005] S.25 ff


- 19 -

Abbildung 3: erweitertes Sternschema im SAP BW

1

Im Vergleich zum klassischen Sternschema ist das SAP BW Sternschema um die

SID-Tabellen erweitert worden, was bedeutet, dass die Dimensionstabellen nicht

länger die Stammdaten (Attribute, Texte, Hierarchien) enthalten. Diese befinden sich

in den sogenannten Stammdatentabellen und werden über die SID-Tabelle mit den

Dimensionstabellen verknüpft. So generiert das System zu jedem Merkmal einen

Schlüssel, der anstelle der eigentlichen Ausprägung in die Dimensionstabelle

eingefügt wird.

Diese Technik erlaubt es die Stammdaten aus dem Cube auszulagern. So sind sie

cube-unabhängig und können von verschiedenen InfoCubes gemeinsam verwendet

werden.

Der normale InfoCube wird oftmals auch als Basis-InfoCube bezeichnet. Daneben

existiert der transaktionale InfoCube. Dieser ist für (parallele) Schreibzugriffe

optimiert, wohingegen der Basis-InfoCube seine Stärken im Lesen der Daten, also im

Bereich der Auswertungen und Analysen, hat.

Die beiden genannten InfoCubes stellen eine physische Datenspeicherung im SAP

BW dar. Zusätzlich gibt es virtuelle InfoCubes. Diese besitzen selbst keine Daten,

sondern greifen direkt auf das Quellsystem zu und bilden damit eine logische Sicht

auf das vorhandene Datenmaterial.

1 In Anlehung an [BW310, 2005] S.34


- 20 -

Operational Data Store

»Ein ODS-Objekt dient der Ablage von konsolidierten und bereinigten Daten (z.B.

Bewegungsdaten oder Stammdaten) auf Belegebene (atomarer Ebene).«1

Im Vergleich zu InfoCubes (mit ihren Fakten- und Dimensionstabellen) ist ein ODS-

Objekt lediglich durch (eine) flache Tabelle(n) repräsentiert. Es gibt Schlüssel- und

Datenfelder, deren Anordnung, je nach Datenumfang, eine beträchtliche Satzlänge

zur Folge haben kann.

ODS-Objekte erlauben im Gegensatz zu den InfoCubes eine Veränderung der

vorhandenen Daten. In InfoCubes ist prinzipiell nur das Einfügen und das Löschen

auf Basis von Requests vorgesehen, während in ODS-Objekten die Daten auch

während des Durchladevorganges geändert werden können.

Standard-ODS-Objekte können ebenfalls mittels Abfragen ausgewertet werden.

Alternativ bilden sie die Grundlage für die Weiterverarbeitung im SAP BW, indem

die Daten z.B. in weitere ODS-Objekte oder InfoCubes fortgeschrieben werden.

Darüber hinaus gibt es transaktionale ODS-Objekte. Diese unterscheiden sich von

den Standard-ODS-Objekten in der Form, dass sie die Daten in nur einer Version zur

Verfügung stellen. Standard-ODS-Objekte besitzen mehrere Tabellen mit aktiven

und modifizierten Daten, sowie dem Delta zu den schon vorhandenen Einträgen.

InfoSet

Ein InfoSet ist ein weiteres Objekt im SAP BW, mit dessen Hilfe Abfragen

durchgeführt werden können. InfoSets speichern jedoch keine Daten, sondern greifen

mittels Join-Operationen auf vorhandene InfoCubes, ODS-Objekte oder Merkmale

zu.

Sinnvoll eingesetzt werden InfoSets vor allem in Bereichen, in denen Analysen sehr

spezifisch sind und so selten eingesetzt werden, dass eine separate physische

Speicherung der Daten unnötig ist. InfoSets beschränken sich jedoch auf die reine

Präsentation der Ergebnisse. Navigationen, die Verwendung von Hierarchien sowie

die Währungsumrechnung sind nicht möglich. In Kombination mit der sehr

schlechten Performance gilt es im Einzelfall abzuwägen, ob der Einsatz eines

InfoProviders2, z.B. InfoCube oder ODS-Objekt, bei häufiger Verwendung nicht

sinnvoller wäre.3

MultiProvider

MultiProvider sind InfoProvider, die aus mehreren anderen InfoProvidern

zusammengesetzt werden. So kann ein MultiProvider aus mehreren Objekten, wie


2 InfoProvider ist ein Oberbegriff für alle Objekte auf die Anfragen durchgeführt werden können.

3 Siehe [Gómez et al., 2006] S.66


- 21 -

InfoCubes, ODS-Objekte oder InfoObjects bestehen. Die einzelnen Objekte werden

dabei, anders als die InfoSets, mit Hilfe der Union-Operation miteinander verknüpft.

Sinnvoll eingesetzt werden Multiprovider dort, wo aus technischen oder

designtechnischen Gründen der Datenbestand auf mehrere InfoProvider aufgeteilt

werden muss, z.B. aufgrund der Leistungsfähigkeit des Systems. So können, zum

Zweck des Reportings, alle beteiligten Objekte wieder zusammengefügt und

anschließend analysiert werden.

Somit stellen Multiprovider, wie auch die InfoSets, lediglich eine logische Sicht über

die Objekte dar, beeinflussen deren Funktion jedoch nicht und beinhalten selbst

keine Daten.

InfoPackage

Mit Hilfe eines InfoPackages wird definiert, welche Daten wann und wie vom

Quellsystem über eine DataSource ins BW angefordert werden sollen. Dabei kann

man mit Hilfe von Selektionsbedingungen die Menge der Daten einschränken und

über Hintergrundjobs den zeitlichen Ablauf des Durchladevorganges bestimmen.

Zusätzlich kann über die Durchführung eines Delta-Verfahrens sowie die

Verwendung einer PSA entschieden werden.

Details werden in Abschnitt 2.5 näher erläutert.

2.4 Business Content

»Der Business Content des SAP BW bietet vorkonfigurierte, auf konsistente

Metadaten basierende rollen- und aufgabenbezogene Informationsmodelle. Er stellt

den Benutzern in einem Unternehmen das Angebot an Informationen [und Objekten]

zur Verfügung, das sie zur Erfüllung ihrer Aufgaben benötigen.«1

Der Business Content enhält:

■ InfoCubes

■ Kennzahlen

■ Merkmale

■ Fortschreibungsregeln

■ Queries

■ Benutzerrollen

■ Arbeitsmappen

■ Extraktoren

■ …

1 Vgl. [Seemann et al., 2001] S.197


- 22 -

Durch die Verwendung des Business Content können der administrative Aufwand

und die damit verursachten Kosten deutlich gesenkt werden. So ist es nicht nötig, bei

der Modellierung im SAP BW alles von Grund auf neu zu entwerfen, da viele

branchenspezifische Objekte und Modelle bereits vorhanden sind und genutzt

werden können.

Obwohl der Business Content von SAP, in ständigem Kontakt mit den Kunden,

weiterentwickelt und aktualisiert wird, ist eine kundenabhängige Anpassung oftmals

notwendig. Dabei gilt es abzuwägen, ob es sinnvoller ist, bestimmte Modelle selbst

anzulegen oder ein Customizing des vorhandenen Business Content durchzuführen.

2.5 ETL-Prozess für Stammdaten im SAP BW 3.x

Neben den bereits erläuterten BW-Objekten sind weitere Komponenten für den ETL-

Prozess von Bedeutung. So z.B. die Übertragungs- und Fortschreibungsregeln, aber

auch die Auswahl bestimmter Verfahren, wie das Delta-Verfahren, die Entscheidung

zwischen direkter und flexibler Fortschreibung oder die verschiedenen

Verbuchungsarten.

Abbildung 4: Beispiel – Datenfluss im SAP BW

Zur besseren Einordnung der Komponenten in den ETL-Prozess wird ein möglicher

Zusammenhang zwischen den verschiedenen BW-Objekten sowie deren Verbindung

mittels Übertragungs- und Fortschreibungsregeln vereinfacht in Abbildung 4

dargestellt.

Aus dem Quellsystem werden die Daten mit Hilfe des Extraktors in die Struktur

einer DataSource übertragen. Über die Logik der Übertragungsregeln erfolgt die

Transformation in eine InfoSource, um dann alle Daten in ein Datenziel, z.B. ein

ODS-Objekt, abzulegen. Abschließend erfolgt eine erneute Fortschreibung in einen

InfoProvider (InfoCube), so dass die Daten mit Hilfe von Analysewerkzeugen

ausgewertet werden können.

Die Funktionsweise von Übertragungs- und Fortschreibungsregeln wird in den

folgenden Abschnitten erläutert.


- 23 -

2.5.1 Übertragungsregeln

Die Logik, wie die Daten von einer DataSource (Transferstruktur) zu einer

InfoSource (Kommunikationsstruktur) übertragen werden, ist in den

Übertragungsregeln definiert.

Zunächst wird das sogenannte Mapping vorgenommen, in dem festgelegt wird,

welche Felder der Transferstruktur in welche Felder der Kommunikationsstruktur

übertragen werden (spaltenweise Zuordnung). Anschließend kann für jede

Zuordnung ein Übertragungsverfahren ausgewählt werden.

Folgende Übertragungsverfahren sind möglich:1

■ Direkte Übernahme (1:1-Regel)

■ Zuweisung eines konstanten Wertes

■ Transformation mittels ABAP-Routine

■ Berechnungen mit Hilfe von Formeln

In Abbildung 5 werden die Übertragungsregeln in einem größeren Zusammenhang

dargestellt. Der Ablauf von der Quelle bis zur InfoSource ist demnach wie folgt

aufgebaut:

Abbildung 5: Übertragungsregeln

2

1 Siehe [Egger et al., 2005] S.56



- 24 -

Werden die Daten aus einem SAP-Quellsystem bereitgestellt, so geschieht dies über

eine DataSource, die schon vorhanden ist oder angelegt werden muss. Diese

DataSource enthält die Extrakt- sowie die daraus abgeleitete Transferstruktur. Durch

den Vorgang der Replikation wird die DataSource im SAP BW bekannt gemacht und

steht dort mit der identischen Transferstruktur zur Verfügung. Mit Hilfe der

Übertragungsregeln wird die Transferstruktur mit der Kommunikationsstruktur

„gemapped“ sowie die Art der Übertragung festgelegt.

Handelt es sich bei der Datenquelle alternativ um eine flache Datei, so wird eine

DataSource im SAP BW erzeugt, die der Struktur der Datei entspricht. Anschließend

wird erneut mit Hilfe der Übertragungsregeln festgelegt, wie die Daten in die

InfoSource übertragen werden sollen.

Eine InfoSource kann mehrere Quellen besitzen. Es ist jedoch wichtig zu beachten,

dass eine DataSource immer nur einer InfoSource zugeordnet sein darf.

2.5.2 Fortschreibungsregeln

Die Fortschreibungsregeln dienen der Definition, wie Daten von einer InfoSource in

ein Datenziel oder einen InfoProvider fortgeschrieben werden sollen. Dabei ist die

Art und der Aufbau des InfoProviders von Bedeutung.

Für Kennzahlen (bei InfoCubes), Datenfelder (bei ODS-Objekten) und Attribute (bei

InfoObjects) gibt es folgende grundlegende Fortschreibungsarten:1

■ Keine Fortschreibung

■ Addition

■ Minimum

■ Maximum

■ Überschreiben (bei ODS-Objekten)

Je Kennzahl können anschließend die folgenden Regeln für die Fortschreibung der

Merkmale (bei InfoCubes) bzw. Schlüsselfelder (bei ODS-Objekten und

InfoObjects) angelegt werden:

■ Direkte Übernahme (1:1-Regel)

■ Zuweisung eines konstanten Wertes

■ Transformation mittels ABAP-Routine

■ Berechnungen mit Hilfe von Formeln

1 Siehe [Egger et al., 2005] S.56


- 25 -

Das folgende Beispiel soll den Vorgang der Fortschreibungsregeln veranschaulichen:

Abbildung 6: Fortschreibungsregeln

Im Beispiel liefert die DataSource einen Datensatz 1 und einen Datensatz 2. Beide

Datensätze besitzen dieselben Merkmalwerte. Aus diesem Grund werden die

Kennzahlen, bei einer Fortschreibungsregel Addition, während der Übertragung in

den InfoCube miteinander verrechnet.

Die Merkmale PLZ und Typ in der DataSource weisen eine andere Bezeichnung als

die korrespondierenden Merkmale im InfoCube auf. Mit Hilfe des Mappings und der

1:1-Zuordung der entsprechenden Felder, ist die korrekte Zuweisung der Daten

jedoch kein Problem.

»Im Allgemeinen kann empfohlen werden, die Übertragungsregeln zur Herstellung

einer hinreichenden Datenhygiene und die Fortschreibungsregeln für logische

Umsetzungen zu verwenden. Dieser (nicht durch SAP vorgegebene) Ansatz hat den

Vorteil, dass die Daten sofort „am Eingang“ zum SAP BW bereinigt werden. Somit

entfallen ggf. erforderliche redundante Bereinigungsfunktionen und die Gefahr,

Bereinigungen nicht an allen erforderlichen Stellen vorzunehmen und damit

inkonsistente und fehlerhafte Daten für das Reporting bereitzustellen«1

2.5.3 Direkte Fortschreibung

Eine direkte Fortschreibung ermöglicht es, Daten direkt, ohne Verwendung von

Fortschreibungsregeln, in die Stammdatentabellen eines gewählten Merkmals zu

speichern (siehe Abbildung 7). In dieser Situation repräsentiert das Merkmal selbst

die InfoSource, wodurch die Daten sofort in das Datenziel gespeichert werden.

1 Vgl. [Egger et al., 2005] S.57


- 26 -

Abbildung 7: Direkte Fortschreibung

1

Die Methode arbeitet zwar performanter als die flexible Fortschreibung, jedoch ist es

so nicht möglich, Daten aus mehreren Datenquellen zu konsolidieren und sie

anschließend in verschiedene Datenziele zu speichern.

2.5.4 Flexible Fortschreibung

Wie aus Abbildung 8 deutlich wird, ermöglicht die flexible Fortschreibung das

Ablegen der Daten in alle verfügbaren BW-Objekte, die als Datenziel geeignet sind.

Darüber hinaus können verschiedene Quellen (z.B. auch Bewegungsdaten) auf Ebene

der InfoSource zusammengeführt werden. So hat man die Möglichkeit nicht nur

innerhalb der Übertragungsregeln auf die Daten zuzugreifen, sondern auch mit Hilfe

der Fortschreibungsregeln, um so den Datenbestand an die individuellen

Erfordernisse des Datenziels anzupassen.2


2 Siehe [BW310, 2005] S.178


- 27 -

Abbildung 8: Flexible Fortschreibung

1

2.5.5 Verbuchungsarten

Wird in den Übertragungsregeln die Transfermethode PSA ausgewählt, stehen, im

Gegensatz zur IDOC-Methode, verschiedene Verbuchungsarten zur Verfügung. Die

Art der Verbuchung wird über das InfoPackage konfiguriert. Bei der Wahl der

Datenverbuchung gilt es, wie so oft im Umfeld des SAP BW, einen Kompromiss

zwischen Datensicherheit und Performanz beim Ladeprozess zu finden.2


2 Siehe [SAPBib3x, 2008]


- 28 -

Verarbeitungsoption Erläuterung

PSA und Datenziele parallel

Die Verbuchung der Daten erfolgt bei dieser Verarbeitungs-option paketweise parallel. Dabei werden die Daten nach erfolgreichem Verbuchen in die PSA, mit Hilfe eines zweiten Prozesses, parallel in die Datenziele geschrieben.

Diese Methode wird verwendet, um Daten performant in die Datenziele zu schreiben.

PSA und anschließend Datenziele

Diese Option arbeitet mit nur einem Prozess pro Datenpaket. Nachdem die Daten erfolgreich in die PSA verbucht wurden, schreibt derselbe Prozess die Daten anschließend in die Datenziele. Die Verarbeitung erfolgt somit paketweise seriell.

Vorteil dieser Methode ist die bessere Kontrolle über den gesamten Datenfluss, da nur ein Prozess pro Datenpaket verwendet wird.

Nur PSA Bei dieser Verarbeitungsoption werden die Daten nur in die PSA geschrieben, aber nicht weiter verbucht. Man kann jedoch automatisch oder manuell die Daten in die Datenziele verbuchen. Dafür wird jedoch nur ein Prozess pro Request gestartet, der nacheinander die Daten in die Datenziele schreibt. Die Verarbeitung erfolgt demnach requestweise seriell.

Vorteil dieser Methode ist die sichere Ablage der Daten im BW, ohne dass sich die Einstellungen im Quellsystem, bezüglich der Anzahl an maximalen Prozessen, auf die Anzahl der Prozesse im BW auswirken.

Tabelle 1: Verbuchungsarten1

2.5.6 Delta-Verfahren

Werden sehr große Datenmengen aus den Quellsystemen geladen, führt dies nicht

nur zu einer hohen Belastung der Hardware und Systemressourcen, sondern ist auch

mit teilweise langen Wartezeiten verbunden. Um nicht bei jeder Aktualisierung der

Datenbestände alle Daten erneut laden zu müssen ist es möglich, das sogenannte

Delta-Verfahren anzuwenden. Dabei werden nur die Datensätze übertragen, die sich

seit der letzten Aktualisierung verändert haben oder neu hinzugekommen sind. Diese

werden in eine Tabelle, die als Delta-Queue bezeichnet wird, übertragen, sobald es

zu einer Änderung an den betroffenen Daten im Quellsystem kommt.2

Durch das Delta-Verfahren wird die Menge an zu übertragenden Daten und somit

auch die Systembelastung massiv gesenkt. Bei den derzeitigen Größenordungen der

Massendaten, ist der Betrieb eines Data Warehouses in der Praxis, ohne die

Verwendung des Delta-Verfahrens, nur noch selten denkbar.

1 Siehe [SAPBib3x, 2008]

2 Je nach Quelle arbeitet das Deltaverfahren auch ohne eine Delta-Queue


- 29 -

Aufgrund der Komplexität der Thematik wird an dieser Stelle lediglich das Delta-

Verfahren in Bezug auf ein SAP Quellsystem beschrieben.1

Ob ein Delta-Verfahren angewendet werden kann oder nicht, hängt von der jeweils

verwendeten DataSource ab. Diese ist entweder „von Haus aus“ deltafähig, kann um

eine Delta-Fähigkeit erweitert werden oder ist generell nicht deltafähig.

Handelt es sich bei der DataSource um eine Datenquelle aus dem SAP BW, ist ein

Delta-Verfahren immer möglich. Bei DataSources eines SAP Quellsystems verhält

es sich wie folgt: Ist die DataSource Bestandteil des Business Content, so kann oft

ein Delta-Verfahren angewandt werden. Jedoch sind nicht alle Business Content

DataSources deltafähig. Erzeugt man, in Form von generischen Extraktoren, eigene

DataSources im Quellsystem, so ist ein Delta möglich, jedoch nicht automatisch

integriert.

Bei nicht deltafähigen DataSources kann es dennoch möglich sein, in Abhängigkeit

von den angeforderten Daten und unter Verwendung spezifischer Selektions-

bedingungen, nur neue oder geänderte Daten in das SAP BW zu übertragen. Dieses

Verfahren als solches wird jedoch nicht den Delta-Verfahren zugeordnet.2

Im Bezug auf Stammdaten erzeugen manche DataSources das Delta anhand von

ALE-Änderungszeigern (Applikation Link Enabling). Diese Technik arbeitet

unabhängig von einer Delta-Queue, indem Änderungen an definierten Tabellen

protokolliert werden.

Die Verwendung des Delta-Verfahrens wird in den InfoPackages gesteuert und

initialisiert. Folgende Fortschreibungsmodi (Updatemodi) können ausgewählt

werden:

■ Full-Update

Bei einem Full-Update werden alle Daten entsprechend der Selektionskriterien im

InfoPackage übertragen.

■ Initialisierung des Delta-Verfahrens

Die Initialisierung des Delta-Verfahrens ist die Voraussetzung für die Durchführung

von Delta-Updates. Wenn sich die Selektionsbedingungen und damit die Datensätze

nicht überlappen, kann auch mehrmals ein Delta-Verfahren initialisiert werden. So

ist es z.B. möglich, aufgrund großer Datenmengen, die Initialisierung des Delta-

Verfahrens schrittweise umzusetzen.

■ Delta-Update

Wie bereits erwähnt, ist für das Delta-Update die Initialisierung zwingend

notwendig. Ist dies geschehen, werden mit diesem Updatemodus nur die Daten

übertragen, die sich seit der letzten Aktualisierung verändert haben oder neu

hinzugekommen sind.

1 Weiterführende Informationen siehe [BW350, 2005] S.153ff

2 Siehe [BW350, 2005] S.153


- 30 -

■ Wiederholung eines Delta-Updates

Mit dieser Funktion kann das Delta-Update wiederholt werden, sollte es beim

vorherigen Ladevorgang zu einem Fehler gekommen sein.

■ Early-Delta-Initialisierung

Die Early-Delta-Initialisierung ermöglicht es, ein Delta-Init durchzuführen und

gleichzeitig die aktuellen Änderungen im Quellsystem mit Hilfe der Delta-Queue

aufzuzeichnen. So kann im Quellsystem weitergearbeitet werden, ohne das

Änderungen verloren gehen. Bei der Ausführung der „normalen“ Delta-

Initialisierung muss die Belegbearbeitung in vielen Anwendungen ruhen. Die

Möglichkeit der Early-Delta-Initialisierung ist nicht obligatorisch, sondern muss von

der DataSource unterstützt werden.

DataSources verwenden, je nach Struktur der Daten, unterschiedliche Delta-

Verfahren. Welches Verfahren verwendet wird kann über die Tabellen

ROOSOURCE (im Quellsystem) oder RSOLTPSOURCE (im BW) festgestellt

werden. Welche Eigenschaften ein Delta-Verfahren besitzt, ist in der Tabelle

RODELTAM (sowohl im BW als auch im Quellsystem) definiert. Die Eigenschaften

entscheiden z.B. darüber,

■ welche Datensätze in der Delta-Queue stehen,

■ wie neue oder geänderte Datensätze in die Delta-Queue gelangen,

■ ob Änderungen in ihrer ursprünglichen Reihenfolge bereitgestellt werden,

■ ob der Extraktor oder die Anwendung das Delta zur Verfügung stellt und

■ wie Änderungen in Datensätzen aufgezeichnet werden (z.B. bei Mengen-

änderungen in einem Auftrag)

Aufgrund der Vielzahl an Ausprägungen können die verschiedenen Delta-Verfahren

an dieser Stelle nicht im Detail erläutert werden.1

2.6 Änderungen im BW 7.0

Wie der Sprung von 3.x auf 7.0 verdeutlicht, kam es mit der neuen Version des SAP

BW zu einer Vielzahl an Neuerungen und Änderungen. Auf alle diese Änderungen

kann jedoch an dieser Stelle nicht eingegangen werden.2 Trotz aller Neuerungen

haben sich die grundlegenden Konzepte jedoch nur wenig verändert.

Dieser Abschnitt soll daher lediglich einen kurzen Überblick über die wesentlichen

Änderungen im SAP BW 7.0 bezüglich des neuen Objektkonzeptes und Datenflusses

bieten.3

1 Weiterführende Informationen siehe [BW350, 2005] S.173ff

2 Weiterführende Informationen siehe [SAPBib3xDelta7, 2008]

3 Siehe [SAPBib7, 2008], [Mehrwald, 2007]


- 31 -

Zu beachten ist, dass die aus der Version 3.x bekannten Konzepte und Technologien

bezüglich des Datenflusses weiterhin unterstützt werden. Die Vorteile in der neuen

Konzeption im SAP BW 7.0 sind jedoch groß genug, so dass sie durch eine

Migration der vorhandenen Datenmodelle genutzt werden sollten.

DataSource

Bisher war die Übertragung von Daten erst nach der Zuordnung einer InfoSource zu

einer DataSource und dem Anlegen und Aktivieren von Übertragungsregeln

möglich. Nur so wurde eine PSA-Tabelle erzeugt, in die Daten geladen werden

konnten.

Im SAP BW 7.0 hat sich das Konzept der DataSources (im Zusammenhang mit den

anderen Änderungen im Datenfluss) geändert. Mit Aktivierung einer DataSource

wird automatisch eine PSA-Tabelle in der Eingangsschicht des SAP BW erzeugt,

wodurch sofort Daten geladen werden können. In welche Datenziele die Daten später

gespeichert werden sollen, wird in dem neuen Konzept der Transformation

festgelegt.

Bei der Replikation von BI Content DataSources entscheidet zumeist das System, ob

als Ergebnis eine „neue“ DataSource oder eine DataSource vom Typ 3.x erstellt

wird. Bei generischen, selbst erstellten DataSources entscheidet der Benutzer

darüber. Vorhandene DataSources können bei Bedarf auf das neue Konzept migriert

werden.

Persistent Staging Area

Wie aus den Ausführungen zu den DataSources deutlich wird, sind PSA und

DataSource nun enger miteinander verknüpft. Die PSA ist im BW 7.0 nicht länger

optional, sondern zwingend erforderlich und wird automatisch mit der Aktivierung

der DataSource erzeugt. Auch die Verwaltung der PSA erfolgt über die DataSource.

Transformation

In SAP BW 3.x wurde der Datenfluss bisher über die Übertragungs- und

Fortschreibungsregeln in Kombination mit einer InfoSource definiert. Diese Aufgabe

wird im SAP BW 7.0 von dem neuen Konzept der Transformationen übernommen.

Dabei werden Quelle, InfoSource (beliebig viele) und Ziel mit je einer

Transformation verbunden.

Im Zusammenhang mit den Transformationen und Routinen sollte nicht unerwähnt

bleiben, dass die Verwendung der Programmiersprache ABAP Objects im SAP BW

7.0 empfohlen wird. Zwar kann auch weiterhin mit dem klassischen ABAP

programmiert werden, jedoch kann dies ggf. zu einem deutlichen Mehraufwand

führen.

InfoSource

InfoSources vom Typ 3.x können nicht von einer Transformation verwendet werden.

Durch Migration der InfoSource auf die „neue“ InfoSource, kann jedoch auch auf


- 32 -

Grundlage der Übertragungs- und Fortschreibungsregeln automatisch eine

Transformation erzeugt werden.

Datentransferprozess & InfoPackage

Der Datentransferprozess (DTP) löst das aus dem SAP BW 3.x bekannte

InfoPackage teilweise ab. Während das InfoPackage ab sofort ausschließlich für den

Datenfluss bis zur PSA zuständig ist, übernimmt der DTP die Übertragung der Daten

innerhalb des BW zwischen den Objekten (siehe Abbildung 9).

Datenfluss

Die Änderungen im Datenfluss sowie die Einführung der neuen Konzepte sind in der

folgenden Abbildung noch einmal dargestellt:

Abbildung 9: Datenfluss im SAP BW 7.0

1

Die Daten werden aus den verschiedenen Quellsystemen mit Hilfe der InfoPackages

in die PSA-Tabellen der DataSource geladen. Ab der Ebene der DataSources

übernehmen die Datentransferprozesse die Ausführung und Steuerung der

Ladevorgänge. Die Transformationen ersetzen die Übertragungs- und

Fortschreibungsregeln. Werden mehrere InfoSources hintereinander geschaltet,

geschieht dies ebenfalls über eine Transformation. Auch zwischen verschiedenen

InfoProvidern ist der Einsatz einer Transformation notwendig.

1 In Anlehnung an [SAPBib7, 2008]

3 Analyse-Prozess-Designer

- 33 -


Im SAP BW werden Daten aus verschiedenen Quellen (Datenbanktabellen, externe

Systeme, flache Dateien) gesammelt, konsolidiert, verwaltet und für spätere

Analysen und Auswertungen zur Verfügung gestellt.

In den bereits im BW vorliegenden Daten steckt jedoch noch ein weitaus höheres,

unentdecktes und ggf. für das Unternehmen wertvolles Potential.

»Dabei handelt es sich um vollkommen neue Informationen, die sich in Form von

sinnvollen Zusammenhängen zwischen den Daten darstellen, jedoch zu verborgen

oder komplex sind, um durch reines Betrachten oder Intuition aufgedeckt zu

werden.«1

Abbildung 10: Zentrale Funktionen des APD

2

Der Analyse-Prozess-Designer stellt einen strukturierten Werkzeugkasten zur

Verfügung, um diese versteckten und komplexen Zusammenhänge und Beziehungen




- 34 -

zwischen den Daten sichtbar zu machen und um damit vollkommen neue

Informationen zu gewinnen.

»Über Analyseprozesse ist es möglich, die Informationsplattform […] für strate-

gische, taktische und operative Entscheidungen zu ergänzen.«1

Mit Hilfe der APD Workbench können selbst komplexe analytische Prozesse einfach

mittels „Drag&Drop“ modelliert, gesteuert und überwacht werden.

Durch gezielte Transformationstechniken und die Anbindung an verschiedene Data-

Mining-Verfahren steht dem Anwender eine Vielzahl an Möglichkeiten offen, neue

Informationen zu schaffen und zu entdecken, die für Unternehmen von enormer

Bedeutung sein können.

3.1 Integration des APD in das SAP BW

Der APD ist vollständig in die Administrator Workbench des Business Warehouse

integriert. Dieser Umstand ermöglicht es im APD eine Vielzahl an BW-Objekten

ohne Umwege als Datenquelle und Datenziele zu verwenden. Somit sind die

Analyseprozesse auch in das Konzept der Versionierung (aktive, inaktive Version,

Contentversion, Auslieferungsversion) und des Transportanschlusses2 eingebunden.

Da der APD nur auf eine Datenbank und nicht auf mehrere verschiedene

Quellsysteme zugreift, werden mögliche Probleme bezüglich der Datenintegrität,

Datenqualität und Systemperformance deutlich vermindert.

3.2 Prozessphasen

Die Aufgaben des APD sowie der Modellierung von analytischen Prozessen

veranschaulicht Abbildung 11.

Zunächst gilt es, eine geeignete Auswahl an Daten und Datenquellen zu treffen, um

diese im anschließenden Prozess, je nach Zielsetzung, miteinander zu verknüpfen, zu

aggregieren, einzuschränken, zu erweitern oder anderweitig zu transformieren. Diese

vorbereitenden Maßnahmen haben eine sehr hohe Bedeutung für die Ergebnisse des

Analyseprozesses. Denn nur qualitativ hochwertige Eingangsdaten, als Basis des

Modells, können zu guten Auswertungen und Endergebnissen führen.

Da viele verschiedene Transformationsschritte aufeinander folgen können, machen

diese auch einen Großteil des späteren Prozessmodells aus.

Bevor die neu gewonnenen Ergebnisse und Daten verwendet werden können (z.B.

durch Queries), müssen diese in geeigneten Datenzielen abgelegt werden.

1 Vgl. [BW380, 2005] S.27

2 Siehe auch Abschnitt 12, Glossar, auf Seite 104


- 35 -

Abbildung 11: Schritte im Analyse-Prozess-Designer

1

Auf einer höheren Abstraktionsebene lassen sich die o.g. Schritte grob in 3

Prozessphasen einteilen:2

■ Datenquelle

Festlegen der Quellen, aus denen die Daten zur weiteren Verwendung extrahiert

werden sollen.

■ Transformation

Auf- und vorbereiten der extrahierten Daten durch verschiedene Transformations-

schritte.

■ Datenziel

Speichern der Ergebnisse in geeigneten Datenzielen für die spätere Analyse und

Präsentation.

3.2.1 Phase 1 - Datenquellen

In der ersten Phase des Analyseprozesses werden die Datenquellen definiert.

Entsprechend der Anforderungen an den Analyseprozess wird festgelegt, welche

Daten woher zur Verfügung gestellt werden. Dabei werden die Daten jedoch nicht

„eingelesen“, sondern es wird, wie im gesamten Modellierungsprozess, lediglich die

Struktur des Analyseprozesses festgelegt. Das Einlesen und Laden der Daten findet

erst beim Starten des fertig modellierten Analyse-Prozesses statt. Zwischendurch

besteht die Möglichkeit, die Daten und damit den bisher erstellten Analyseprozess zu

überprüfen. Hierbei werden jedoch nur die ersten ca. 2000 Datensätze ausgegeben,

anhand derer bei Bedarf der richtige Ablauf festgestellt werden kann.

1 In Anlehnung an [SAPBib3x, 2008]

2 Vgl. [KiVA, 2007] S.40


- 36 -

In Abhängigkeit von der Anwendung und dem eingesetzten BW-System1, stehen

folgende Möglichkeiten zur Verfügung:

■ Attribute eines Merkmals lesen

■ Daten aus InfoProvider lesen

■ Daten über Query lesen

■ Daten aus Datei lesen

■ Daten aus Datenbanktabelle lesen

Die genannten Datenquellen werden in den folgenden Abschnitten näher erläutert.

Attribute eines Merkmals lesen 2

Mit Hilfe dieses Datenquellentyps können aus einem ausgewählten Merkmal

(InfoObject) alle aktiven Stammdaten sowie die zugehörigen zeitabhängigen und

zeitunabhängigen Attribute ausgelesen werden.

Daten aus InfoProvider lesen

Dieser Datenquellentyp ermöglicht die Datenbereitstellung durch InfoProvider. Nach

geltender SAP-Festlegung können dies

■ InfoCubes

■ DataStore-Objekte (DSO bzw. ODS3)

■ InfoObjects als InfoProvider

■ Multiprovider oder

■ InfoSets

sein. In Abhängigkeit vom gewählten InfoProvider können diejenigen Merkmale und

Kennzahlen ausgewählt werden, die für den weiteren Analyseprozess verwendet

werden sollen.

Zu beachten ist, dass die Daten in einfacher Tabellenform zur Verfügung gestellt

werden, d.h., es werden keine Abhängigkeiten von Merkmalen und Kennzahlen

berücksichtigt.

Auch bezüglich des Aggregationsverhaltens gilt es einige Besonderheiten zu

beachten. So werden Kennzahlen ausschließlich per Standardaggregation verdichtet.

Eine Ausnahmeaggregation4 kann nur über nachfolgende Prozessschritte

durchgeführt werden.

1 Siehe auch Abschnitt 3.8, Unterschiede zwischen den Versionen des APD, auf Seite 53

2 Die Darstellung der Symbole entspricht der SAP BW Version 7.0

3 Bezeichnung im SAP BW 3.x



- 37 -

Daten über Query lesen

Mit diesem Datenquellentyp ist es möglich, Daten aus einer BW Query zu erhalten.

Alle Felder der Query werden dabei ausgelesen und zur weiteren Verwendung zur

Verfügung gestellt. Die Query muss jedoch zwingend ODBO-fähig (OLE DB for

OLAP) sein, d.h. der externe Zugriff auf die Query wird zugelassen1.

Daten aus Datei lesen

Mit diesem Knoten können Daten aus flachen Dateien im ASCII- (American

Standard Code for Information Interchange) oder CSV-Format (Comma Separated

Value) gelesen werden. Die einzulesende Datei kann sich dabei entweder auf dem

Applikationsserver oder dem lokalen Rechner befinden. Von letzterem ist jedoch

außerhalb der Testphase abzuraten, da der Verweis auf eine lokale Datei

rechnerabhängig ist. Dadurch ist die Durchführung des gesamten Analyseprozesses

nur auf dem lokalen Rechner und nicht mittels Hintergrundverarbeitung möglich.

Daten aus Datenbanktabelle lesen

Diese letzte Möglichkeit der Datenbeschaffung erlaubt es, Daten aus einer

transparenten und aktivierten Datenbanktabelle oder einem Datenbankview zu laden.

Alle in der Tabelle bzw. dem View vorhandenen Felder, stehen so zur weiteren

Verarbeitung zur Verfügung.

3.2.2 Phase 2 - Transformationen

Die zweite Phase im Modellierungsprozess umfasst den bedeutenden Teil der

Transformationen.

Folgende Transformationstypen stehen zur Auswahl:

■ Datenmenge einschränken

■ Daten aggregieren

■ Daten aus zwei Quellen miteinander verknüpfen (Join)

■ Daten aus zwei Quellen vereinigen (Union)

■ Spalten ausblenden oder umbenennen (Projektion)

■ Daten sortieren

■ Formel

■ Liste in einen Datensatz transformieren

■ Datensatz in eine Liste transformieren

■ ABAP Routine

Zu den Transformationen gehören auch diejenigen, die dem Data Mining zugeordnet

werden. Diese werden jedoch in dieser Arbeit nicht weiter erläutert.

1 Vgl. [KiVA, 2007] S.51


- 38 -

In den folgenden Abschnitten werden die genannten Transformationen näher

betrachtet.

Datenmenge einschränken

Mit Hilfe dieses Knotens können Datenmengen zeilenweise eingeschränkt und

gefiltert werden. Die Spalten der Datenstruktur bleiben dabei erhalten. Somit

entspricht die Funktionsweise einer oder mehrerer Selektionsbedingungen. Als

Ergebnis wird eine Teilmenge der Eingangsdaten erzeugt.

Abbildung 12: Beispiel – Datenmenge einschränken

1

In Abbildung 12 ist zu erkennen, wie die Kunden selektiert werden, wenn als

Filterbedingung für das Feld Kunde das Intervall 1000 bis 2000 angegeben wird.

Eine Exclude-Selektionsbedingung wird standardmäßig nicht unterstützt. Es existiert

jedoch die Möglichkeit eine Selektionserweiterung vorzunehmen, wonach alle

Selektionsoperationen zur Verfügung stehen2.

Daten aggregieren

Der Knoten „Daten aggregieren“ bietet die Möglichkeit ausgewählte Daten zu

verdichten. So können Daten bestimmter Felder anhand ihrer Werte gruppiert

werden, um anschließend ausgewählte Felder zu aggregieren.

Folgende Aggregationsverhalten werden angeboten:

■ SUM

Die Werte der Aggregationsfelder, deren Gruppierungsfelder identisch sind,

werden summiert.

■ MIN

Nur das Minimum im Aggregationsfeld wird weitergeben.

■ MAX

Nur das Maximum im Aggregationsfeld wird weitergeben.

■ AVG

Der Durchschnitt aller Werte im Aggregationsfeld wird berechnet und

weitergegeben.


2 Weiterführende Information siehe [KiVA, 2007] S.61


- 39 -

■ AV0

Der Durchschnitt aller Werte im Aggregationsfeld wird berechnet, jedoch ohne

Berücksichtigung der Nullwerte.

■ NOP

Es wird keine Aggregation durchgeführt.

Die beiden folgenden Verhalten stellen Sonderaggregationen dar, die für die

Auswertung der Anzahl der aggregierten Datensätze von Bedeutung sein können:

■ CNT

Gibt die Anzahl der aggregierten Datensätze weiter.

■ CN0

Gibt die Anzahl der aggregierten Datensätze weiter, ohne jedoch die Nullwerte zu

berücksichtigen.

Es ist zu beachten, dass die Auswahl an Aggregationsverhalten vom Typ des

Aggregationsfeldes abhängig ist. So kann beim Typ „Character“ nur MIN oder MAX

für die Aggregation ausgewählt werden, da andere Verhaltensweisen nicht sinnvoll

sind.

Das Aggregieren von Daten soll anhand von zwei Beispielen verdeutlicht werden:

Abbildung 13: Beispiel 1 – Daten aggregieren

1

Die Abbildung 13 zeigt die Merkmale (Attribute) Kunde, Material und

Warengruppe sowie die Kennzahlen Erlös und Kosten. Durch die Angabe von Kunde

und Warengruppe als Gruppierungsfelder sowie Erlös und Kosten als

Aggregationsfelder, findet eine Verdichtung auf der Ebene Kunde/Warengruppe

statt. Die beiden Kennzahlen werden aufgrund ihres Aggregationsverhaltens (SUM)

addiert.



- 40 -

Abbildung 14: Beispiel 2 – Daten aggregieren

1

Abbildung 14 zeigt die Aggregation auf Kundenebene, wobei die Erlöse summiert

(SUM) und für die Kosten der Durchschnitt (AVG) berechnet wird.

Daten aus zwei Quellen miteinander verknüpfen (Join)

Der Knoten vom Typ „Join“ ermöglicht es, zwei Datenquellen miteinander zu

verknüpfen. Dabei ist es wichtig, alle Felder anzugeben, die weitergegeben werden

sollen.

Abbildung 15: Beispiel – Daten zweier Quellen miteinander verknüpfen

2

Abbildung 15 veranschaulicht, wie über das gemeinsame Merkmal Kunde eine

Verknüpfung der beiden Datenquellen realisiert werden kann.

Standardmäßig wird zur Verknüpfung der „Inner Join“ verwendet. Es besteht jedoch

auch die Möglichkeit einen „Left Outer Join3“ zu verwenden, wobei die zuerst

angebundene Tabelle die „linke“ Tabelle darstellt. Unterschiede im Ergebnis

zwischen beiden Verknüpfungsarten ergeben sich dann, wenn gemeinsame

Merkmale unterschiedliche Ausprägungen besitzen.


2 In Anlehnung an [SAPBibBI, 2008]



- 41 -

Daten aus zwei Quellen vereinigen (Union)

Mit Hilfe dieser Transformation können zwei Datenquellen vereinigt werden. Da im

Gegensatz zum „Join“ ggf. nur eine Schnittmenge weitergegeben wird, werden bei

der Vereinigung alle Felder der Quellstruktur im Ergebnis verwendet.

Als einzige Einschränkung gilt: Gleichnamige Felder müssen von demselben

Datentyp sein.

Abbildung 16: Beispiel – Daten aus zwei Datenquellen vereinigen

1

Abbildung 16 zeigt, wie zwei Datenquellen vereinigt werden und wie dabei, im

Gegensatz zum Join, auch leere Attributwerte im Merkmal Land entstehen können

Spalten ausblenden oder umbenennen (Projektion)

Besitzt eine Datenquelle zu viele oder unnötige Felder, können mit Hilfe dieser

Transformation einzelne Spalten ausgeblendet werden. Darüber hinaus hat man die

Möglichkeit, unpassende Feldnamen umzubenennen, um so die Verständlichkeit des

Analyseprozesses zu optimieren.

Daten sortieren

Dieser Knoten ermöglicht es, die Daten nach ausgewählten Feldern zu sortieren.

Diese Transformation wird jedoch ausschließlich zur Überprüfung von

Zwischenschritten verwendet.

Fast immer führen die Transformationen selbst eine Sortierung anhand der

Gruppierungsfelder durch, wodurch eine vorangestellte, separate Sortierung nur zu

einer verschlechterten Performance führt.



- 42 -

Abbildung 17 zeigt beispielhaft die Sortierung einer Kundenliste nach Umsatz.

Abbildung 17: Beispiel – Daten sortieren

1

Formel

Mit Hilfe der Formel-Transformation kann die Datenstruktur um weitere Felder

ergänzt werden, die anschließend mit den Ergebnissen der Formel-Berechnungen

gefüllt werden. Dabei stehen nicht nur die mathematischen Grundfunktionen und

logischen Vergleichsoperatoren sondern auch Transformationen im Hinblick auf

Datum und Zeichenketten zur Verfügung. So können auf Basis der Eingangsdaten

Berechnungen durchgeführt werden.

Die Transformationsbibliothek stellt bereits eine Vielzahl an vorgefertigten

Funktionen zur Verfügung. In Kombination mit dem Formeleditor lassen sich

weitere Funktionen einfach und ohne ABAP2 Code (Advanced Business Application

Programming) anfertigen.

Liste in Datensatz transformieren

Der Knoten „Liste in Datensatz transformieren“ erlaubt es, die interne Datenstruktur

der Eingangsdaten dahingehend zu verändern, dass gewählte Spalten in Zeilen

transponiert werden. Dementsprechend wird, bei Angabe der Transformier- und der

Transponierfelder, aus einer Liste von Datensätzen ein einzeiliger Datensatz

generiert.

Abbildung 18: Beispiel – Liste in Datensatz transformieren

3





- 43 -

Abbildung 18 veranschaulicht den Vorgang anhand eines einfachen Beispiels. Die

Fragebogen-Nr wird einfach übernommen, wohingegen die Frage-Nr als

Transformationsfeld und die Antwort als Transponierfeld angeben wird.

Anschließend lässt sich die Antwort jeder Frage in einem eigenen Feld wiederfinden.

Datensatz in Liste transformieren

Die Funktion „Datensatz in Liste transformieren“ bildet den Gegensatz zur o.g.

Transformation „Liste in Datensatz transformieren“. Auch hier wird die interne

Datenstruktur geändert, jedoch so, dass aus einem Datensatz mehrere Sätze in Form

einer Liste erzeugt werden.

Abbildung 19: Beispiel – Datensatz in Liste transformieren

1

Die Funktionsweise wird in Abbildung 19 dargestellt und entspricht dem

gegenteiligen Ablauf zu der Funktion „Liste in Datensatz transformieren“.

ABAP Routine

Die ABAP Routine ist die flexibelste Möglichkeit der Transformation. Hier können

individuelle Transformationen, die nicht durch die bereits genannten Knoten

durchgeführt werden können, mittels ABAP Code programmiert werden.

Die Eingangsdaten können in Gruppierungsfelder und Quellfelder unterteilt werden.

Gruppierungsfelder werden unverändert weitergegeben, wohingegen Quellfelder in

der ABAP Routine zur Verfügung stehen. Zusätzlich muss die Definition der

Zielfelder erfolgen, in der die Routine ihre Ergebnisse ablegen kann. Sie werden an

die Datenstruktur angehängt und erweitern somit die Eingangsdatentabelle. Sollen

die Quellfelder zusätzlich unverändert weitergegeben werden, müssen diese als

gleichnamige Zielfelder definiert werden.



- 44 -

Innerhalb der Routine ist es möglich, auf folgende Strukturen zuzugreifen1:

■ IS_GROUP

enthält die Struktur der Gruppierungsfelder (kann nicht verändert werden)

■ IT_SOURCE

enthält die Eingangstabelle ohne die Gruppierungsfelder

■ ET_TARGET

entspricht der Ausgangstabelle, die durch die Routine gefüllt wird. Wenn die

Routine beendet ist, wird die Tabelle wieder um die Elemente der

Gruppierungsfelder ergänzt.

Innerhalb eines Loop-Statements, das die gesamte interne Tabelle mit den

Quellfeldern durchläuft, kann nun die Transformationslogik implementiert werden.

...

*---------------------- Begin of transformation code --------------

DATA: ls_source TYPE y_source_fields,

ls_target TYPE y_target_fields.

LOOP AT it_source INTO ls_source.

ls_target-UMSATZ = ls_source-MENGE * ls_source-PREIS

MOVE-CORRESPONDING ls_source TO ls_target.

APPEND ls_target TO et_target.

ENDLOOP.

*----------------------- End of transformation code ----------------

...

Listing 1: Beispiel – ABAP-Routine

In dem Beispiel wird für jeden Datensatz, mit Hilfe der Quellfelder ls_source-

MENGE und ls_source-PREIS, der Umsatz berechnet und in das Zielfeld ls_target-

UMSATZ gespeichert.

3.2.3 Phase 3 - Datenziele

Nachdem die Quelldaten in der zweiten Phase entsprechend der Zielsetzungen und

Anforderungen transformiert und aufbereitet wurden, müssen die Ergebnisse in

geeigneten Datenzielen abgelegt werden.

Zu den möglichen Datenzielen gehören auch solche, die dem Bereich des Data

Mining zugeordnet werden. Diese werden, aus den bereits bekannten Gründen, an

dieser Stelle nicht näher betrachtet.

»Innerhalb eines Analyseprozesses darf nur ein Datenziel verwendet werden. Dies

bedeutet, dass alle Datenquellen […] konsolidiert werden müssen.«2

1 Vgl. [KiVA, 2007] S.71

2 Vgl. [KiVA, 2007] S.72


- 45 -

Aktuell sind folgende Datenziele verfügbar:

■ Attribute eines Merkmals ändern

■ ODS/DSO-Objekt schreiben

■ CRM-Attribute aktualisieren

Die genannten Datenziele werden nun näher betrachtet:

Attribute eines Merkmals ändern

Dieser Datenziel-Knoten ermöglicht es, die Attributwerte eines Merkmals zu ändern,

d.h. die aufbereiteten Daten werden in die Attribute eines bereits aktiven Merkmals

gespeichert. Dabei gilt es zu beachten, dass es nicht möglich ist die Struktur des

Merkmals hinsichtlich zusätzlicher Attribute zu verändern. Die Attribute aus dem

Ergebnis des Analyseprozesses müssen entweder durch die Struktur des Merkmals

abgebildet sein oder können nicht fortgeschrieben werden.

ODS/DSO-Objekt schreiben

In Abhängigkeit der verwendeten Version des Business Warehouse können die

Analyseergebnisse entweder in ein transaktionales ODS- oder DataStore-Objekt

gespeichert werden.1 Von dort ist eine Fortschreibung in einen InfoCube möglich.

Bei ODS-Objekten kann mittels InfoSet auch ein direktes Query auf die Daten

erstellt werden. Bei DataStore-Objekten ist dies auch ohne InfoSet möglich.

CRM-Attribute aktualisieren

Mit Hilfe dieses Knotens können Ergebnisse des Analyseprozesses direkt in das SAP

CRM (Customer Relationship Management) übertragen werden. Dort müssen die

Datenziele jedoch zuvor definiert werden. Dadurch wird deutlich, dass die Auswahl

an Datenzielen sowie deren Eigenschaften von dem Releasestand des eingesetzten

SAP CRM abhängig sind. In erster Linie können mit diesem Knoten Daten zum

Geschäftspartner gespeichert werden.

Daten in Datei schreiben

Dieses Datenziel erlaubt das Speichern der Analyseergebnisse in einer flache Datei,

die entweder auf dem Applikationsserver oder auf dem lokalen Rechner abgelegt

sein kann.

1 d.h. bei jedem Lauf des Analyseprozesses werden die Daten vor dem Speichern gelöscht.


- 46 -

3.3 Anwendungen

Eine Besonderheit des APD liegt in der Tatsache, dass Analyseprozesse nur

innerhalb der von SAP vorgegebenen Anwendungen angelegt werden können.

Abhängig von der gewählten Anwendung werden ausschließlich die Funktionen1

(Datenquellen, Transformationen und Datenziele) für die Modellierung des Prozesses

angeboten, die für die jeweilige Anwendung relevant sind. Bei Bedarf gibt es die

Möglichkeit die Anwendungen zu verändern bzw. neue, eigene Anwendungen zu

erzeugen, um so den Analyseprozess individuell gestalten zu können.2

Folgende Anwendungen werden standardmäßig von SAP ausgeliefert:

■ CRM-Attribute füllen (CRM_ATTRIBUTES)

■ Zielgruppe für BW-Umfragen anlegen (SATISFACTION_TGT)

■ Berechnung der Wichtigkeit (SATISFACTION_SVY)

■ Prognose Modelltraining (RT_MDL_TRAIN)

■ Allgemein (GENERIC)

Abbildung 20: Standardanwendungen von SAP

Wie in Abbildung 20 zu erkennen ist, stellt der Anwendungstyp „Allgemein“

(GENERIC) die Obermenge aller zur Verfügung stehenden Knoten dar. Um alle

Funktionen nutzen zu können, empfiehlt es sich daher, den Analyseprozess in der

Anwendung „Allgemein“ zu erzeugen.

1 Die Elemente des Modells werden auch Knoten genannt

2 Weiterführende Information siehe [KiVA, 2007] S.114


- 47 -

3.4 Funktionsweise

Die Benutzeroberfläche des APD ist klar strukturiert und stellt alle Funktionen und

Informationen und damit den gesamten analytischen Prozess übersichtlich dar (siehe

Abbildung 21). Dies ist ein entscheidender Faktor bei der Verwendung des APD im

Zusammenhang mit komplexen analytischen Modellierungsvorgängen.1

Abbildung 21: APD-GUI

2

Die Modellierung des Analyseprozesses im Arbeitsbereich erfolgt mit Hilfe von

Knoten und Datenflusspfeilen.

Knoten

Die Knoten werden durch die bereits beschriebenen Datenquellen, Transformationen

und Datenziele repräsentiert. Sie werden anhand von Symbolen per Drag&Drop auf

den Arbeitsbereich gezogen, dort miteinander verbunden und mittels Doppelklick in

ihren Eigenschaften verwaltet.

Anhand der sogenannten Dekorationen werden die unterschiedlichen Knoten

deutlicher gekennzeichnet. Die Dekorationen befinden sich in der rechten oberen

Ecke des Knotens und zeigen an, ob es sich bei dem Knoten um eine Datenquelle

(kleiner Würfel), eine Transformation (kleines Dreieck) oder ein Datenziel (kleiner

Kreis) handelt. Hierdurch lassen sich gleichartige Symbole aus den verschiedenen

Funktionsbereichen deutlicher unterscheiden.

1 Siehe auch Abschnitt 3.6, Abgrenzung zu den Möglichkeiten im BW, auf Seite 51

2 Vgl. [BW380, 2005] S.25


- 48 -

Darüber hinaus besitzt jeder Knoten einen oder mehrere Konnektoren (kleine rote

Dreiecke). Diese symbolisieren die Eingänge (links am Knoten) bzw. die Ausgänge

(rechts am Knoten). Über diese Konnektoren können die Knoten mit Hilfe von

Datenflusspfeilen miteinander verbunden werden.

Abbildung 22: Dekoration, Konnektor, Datenflusspfeil

Datenflusspfeile

Über die Datenflusspfeile werden die verschiedenen Knoten eines Analyseprozesses

miteinander verknüpft. Dies geschieht ebenfalls mittels Drag&Drop an den

Konnektoren der Knoten. Nur für Datenflusspfeile mit einem Symbol ist es

notwendig, durch Doppelklick eine Feldzuordnung zwischen den Knoten

durchzuführen. Bei Datenflusspfeilen ohne Symbol findet das Mapping automatisch

statt.

Daten anzeigen lassen

Ein weiterer wesentlicher Aspekt bei der Modellierung von komplexen

Analyseprozessen ist es, jeden einzelnen Verarbeitungsschritt auf seine Richtigkeit

überprüfen zu können. Ohne diese Möglichkeit wäre eine Fehlersuche enorm

aufwändig und schwierig. Mit Hilfe der Funktion „Daten anzeigen“ kann die

Datenqualität, anhand einer Auswahl von ca. 2000 Datensätzen, nach jedem Schritt

im Analyseprozess überprüft werden.

Genutzt werden kann diese Funktion entweder über das Kontextmenü eines Knotens

oder den Aufruf über die Funktionsauswahl (je nach Version).

Elementare Statistik anzeigen

Eine weiterführende Analyse in den einzelnen Schritten des Analyseprozesses ist

über die Funktion „Elementare Statistik anzeigen“ möglich. In Abhängigkeit von den

gewählten Feldern werden grundlegende, statistische Informationen bezüglich des


- 49 -

aktuellen Datenbestandes des Knotens angezeigt. Neben Histogrammen, Verteilungs-

und Häufigkeitsberechnungen werden, je nach Werttyp des Feldes, auch weitere

einfache Statistikkennzahlen, wie z.B. arithmetisches Mittel, Standardabweichung

oder Korrelation ausgegeben.

Die Statistiken sind vor allem im Bereich des Data Mining von Bedeutung und

können dort ein hilfreiches Mittel zur Überprüfung und Analyse des aktuellen

Datenbestandes sein.

Zwischenergebnis berechnen

Mit Hilfe der Funktion „Zwischenergebnis berechnen“ kann die teilweise

Durchführung des Analyseprozesses bis zu einem definierten Knoten gestartet

werden. Die Durchführung erfolgt wahlweise direkt oder als eingeplanter Job im

Hintergrund. Die berechneten Daten werden dann in einer temporären Tabelle

gespeichert. Sie wird jedoch ungültig, sobald der Knoten verändert wird.

Im Arbeitsbereich wird ein Zwischenergebnis optisch durch das Icon in der

rechten unteren Ecke des Knotens dargestellt.

Das Erzeugen eines Zwischenergebnisses »ist zum einen hilfreich, wenn Sie bei der

Modellierung des Analyseprozesses verschiedene Möglichkeiten ab diesem Knoten

ausprobieren möchten. Zum anderen dienen die Zwischenergebnisse der

Performanceoptimierung beim Ausführen des Analyseprozesses bei großen

Datenmengen.«1

3.5 Versteckte Funktionen

Es gibt noch eine Vielzahl weiterer Funktionen, die jedoch ausschließlich über den

Anwendungstyp2 DEVELOPMENT verfügbar sind. Dieser Anwendungstyp ist

jedoch nicht im SAP-Standard enthalten, sondern in erster Linie für die

Weiterentwicklung des APD und dessen Funktionalitäten gedacht. Obwohl einige

Funktionen sicherlich nützlich sein können, muss eine Verwendung gut überlegt

sein, da jede dieser Funktionen mit einem gewissen Risiko verbunden ist.

Manche Funktionen, wie „Quantilbildung“, „Top-Down-Verteilung“ oder „Daten in

Datenbank schreiben“ können bei Bedarf ohne erhöhtes Risiko eingesetzt werden, da

ihre Funktionsweise nicht sehr komplex und damit nachvollziehbar ist. Andere

Funktionen wie „Normalisierung“ weisen jedoch Fehler auf und sollten daher nicht

eingesetzt werden. 3

Es gilt also festzuhalten, dass aufgrund des Entwicklungsstadiums und der

ausschließlichen internen Verwendung einiger Funktionen durch SAP, ohne


2 Siehe auch Abschnitt 3.3, Anwendungen, auf Seite 47

3 Weiterführende Information siehe [KiVA, 2007] ab S.117


- 50 -

detaillierte Kenntnisse über die Arbeitsweise, der Einsatz dieser versteckten

Funktionen genau geprüft werden sollte. Darüber hinaus werden sinnvolle

Weiterentwicklungen in naher Zukunft sicherlich, in Form von Standardfunktionen,

in den APD eingebunden.

3.6 Abgrenzung zu den Möglichkeiten im BW

Trotz der vielen Möglichkeiten und Funktionen des Analyse-Prozess-Designers

lassen sich viele der Verknüpfungen und Transformationen auch mit den Mitteln des

Business Warehouse sowie den Übertragungs- und Fortschreibungsregeln

durchführen. Dabei ist die Verarbeitung in der Regel effizienter und performanter.

Dennoch besitzt der APD seine Daseinsberechtigung. Ein Einsatzgebiet in dem der

Analyse-Prozess-Designer besondere Bedeutung hat, ist das Data Mining. Nur mit

ihm können Daten, die bereits im BW vorliegen, für das Data Mining Verfahren

zusammengeführt und aufbereitet werden.

Aber auch ohne Data Mining Methoden hilft der APD bei komplexen

Problemstellungen eine übersichtliche Struktur zu schaffen. Es können beliebige

Datenobjekte, die auch schon in anderen Prozessen und Datenflüssen verwendet

werden, aus dem SAP BW genutzt und weiter aufbereitet werden. Dies geht über den

normalen ETL-Prozess des Business Warehouse weit hinaus. Der APD ermöglicht

es, eine beliebig lange Folge von Transformationen durchzuführen (siehe Abbildung

23), während dem BW dort deutliche Grenzen gesetzt sind. Die übersichtliche

Darstellung sowie die Möglichkeit der Zwischenprüfungen erlauben es, den

Analyseprozess deutlich transparenter zu gestalten. Letztlich verwendet der APD

Daten, die schon im BW vorliegen oder durch vorangestellte Analyseprozesse

erzeugt wurden. Dies können auch Teilmengen vorhandener Datenbestände sein

(Queries als Datenquelle). Somit werden das produktive Quellsystem und auch das

Business Warehouse durch den Analyseprozess des APD weniger belastet.

Idealerweise ergänzen sich die Vorteile des SAP BW sowie des APD, indem ein

Kompromiss aus Funktionalität, Flexibilität und Transparenz auf der einen Seite, und

Effizienz und Performanz auf der anderen Seite geschaffen wird. So empfiehlt z.B.

SAP »InfoSets zu benutzen, um große ODS-Objekte und Stammdatentabellen zu

verknüpfen, da die Verarbeitung effizienter [als im Analyse-Prozess-Designer] ist.«1

Inwieweit solche Kompromisse ohne Einschränkungen zu schließen sind, hängt

maßgeblich von den Anforderungen an den Analyseprozess ab.

Eine detaillierte Übersicht der Vorteile und Einsatzgebiete des APD ist im Abschnitt

5.2 zu finden.

1 Vgl. [BW380, 2005] S.252


- 51 -

Abbildung 23: Beispiel eines Analyseprozesses

1

3.7 Auswirkungen des APD auf den ETL-Prozess

Im Grunde entspricht die Verwendung des APD, vor allem ohne den Einsatz von

Data Mining Techniken, einem weiteren, flexibleren ETL-Prozess im Anschluss an

den eigentlichen ETL-Prozess des BW. Genau wie im BW werden die Daten im

APD zunächst extrahiert (wenn auch aus dem gleichen System), transformiert und

geladen.

Diese Tatsache hat auch Auswirkungen auf den ETL-Prozess der Datenbeschaffung

im BW. So ist es von Bedeutung, wie und welche Daten extrahiert und transformiert

werden und ob dies Auswirkungen auf die Verwendung der Daten in einem oder

mehreren möglichen Analyseprozessen hat. So können z.B. im Rahmen eines

Datenflusses bestimmte Daten so verändert (oder gar nicht erst übertragen) werden,

dass sie in einem anderen späteren Analyseprozess keine Verwendung mehr finden.

Andererseits ist es jedoch nicht sinnvoll, provisorisch „alle“ Daten in das BW zu

laden, nur weil ein Teil davon eventuell in einem Analyseprozess verwendet werden

könnte.

Es gilt also auch hier wieder, einen Kompromiss zwischen Flexibilität und Effizienz

zu finden.

1 In Anlehnung an [KiVa, 2007] S.78


- 52 -

3.8 Unterschiede zwischen den Versionen des APD

Mit der SAP BW Version 3.0 wurde der Analyse-Prozess-Designer eingeführt.

Vergleichsweise klein ist dementsprechend der Funktionsumfang zu den aktuellen

Releaseständen. Sowohl die Anbindung an die Methoden des Data Mining als auch

deren Reifegrad sind nicht sehr ausgeprägt.

Mit der Einführung des SAP BW 3.5 und der Weiterentwicklung im SAP BI 7.0

haben das »Spektrum an Verfahren, die Möglichkeit zum modulübergreifenden

Einsatz und die Integration in grafische Entwicklungswerkzeuge […] einen vorläuf-

igen Höhepunkt erreicht.«1

Die folgende Tabelle stellt die wesentlichen Änderungen und Erweiterungen bei den

Funktionen des Analyse-Prozess-Designers dar:

Unterscheidungsmerkmal SAP BW 3.1 SAP BW 3.5 SAP BI 7.0

Transformation „Spalten ausblenden oder umbenennen“ (Projektion)

nein ja ja

Transformation „Daten aus zwei Quellen vereinigen“ (Union)

nein nein ja

Transformation „Formel“ nein nein ja

Datenziel „Daten in Datei schreiben“ nein versteckt ja

Sonderaggregationsverhalten nein ja ja

Programmiersprache in der Funktion „ABAP Routine“

ABAP ABAP ABAP Objects

Zugriff auf Funktion „Daten anzeigen“ Funktionsauswahl Kontextmenü Kontextmenü

Funktion „Elementare Statistik anzeigen“ nein ja ja

Funktion „Zwischenergebnis“ nein ja ja

Anzahl integrierter Data Mining Methoden 1 5+2 5+

Dekorationen nein ja ja

Tabelle 2: Unterschiede zwischen den Versionen des APD

Zusätzlich gibt es noch eine Vielzahl an Änderungen an der grafischen Oberfläche.

(z.B. bei Symbolen für die jeweiligen Funktionen) sowie im Funktions- und

Informationsangebot in den verschiedenen Leisten der APD-Workbench. Da diese

Änderungen jedoch für den Benutzer offensichtlich sind, bedürfen sie keiner

weiteren Erläuterung.

1 Vgl. [KiVa, 2007] S.12

2 Erweiterungen über Drittanbieter möglich

4 Fallbeispiel „Anlagen-Analyse“

- 53 -


Anhand eines Fallbeispiels soll die Umsetzung eines Analyseprozesses mit Hilfe des

Analyse-Prozess-Designers durchgeführt werden. Durch Verknüpfungen und

Transformationen von realen Daten1 eines Energieversorgungsunternehmens sollen

neue, nützliche Informationen geschaffen werden.

Um einen Einblick in die branchenspezifischen Gegebenheiten eines

Energieversorgungsunternehmens zu bekommen, die für das Fallbeispiel relevant

sind, werden die wichtigen Begrifflichkeiten und Zusammenhänge zunächst in einer

kurzen Einführung erläutert. Anschließend werden die Zielsetzungen des

Fallsbeispiels definiert und daraus ein Konzept für die Umsetzung abgeleitet. In den

darauf folgenden Abschnitten folgen die Prozesse der Datenbeschaffung,

Transformation, Datenspeicherung und Datenauswertung. Zuletzt werden mögliche

Optimierungsvorschläge genannt, um die Systembelastung zu minimieren.

4.1 Einführung in die Thematik

Um die Zielsetzung sowie die nachfolgenden Schritte der Umsetzung nachvollziehen

zu können, gilt es zunächst die wichtigen Begriffe und Prinzipien eines

Energieversorgungsunternehmens, in Bezug auf das Fallbeispiel der Anlagen-

Analyse, zu erläutern.

4.1.1 SAP for Utilities

» SAP Utilities ist ein geschäftsprozessorientiertes Vertriebs- und Informations-

system für alle Versorgungsarten und Serviceleistungen eines Versorgungs- und

Dienstleistungsunternehmens. Die Branchenkomponente Versorgungsindustrie(IS-U)

dient gleichermaßen zur Verwaltung und Abrechnung von Tarifkunden,

Sonderkunden, Dienstleistungskunden und Interessenten.«2

1 Als Quelle dient das System EE1 (siehe auch Abschnitt 1.4, Eingesetzte Software, auf Seite 10)

2 Vgl. [SAPBibUtil, 2008]


- 54 -

SAP for Utilities besteht aus folgenden Komponenten:1

■ IS-U/CSS (Industry Solution Utilities / Customer Care Service)

□ Grundfunktionen

Verwalten von Adressen und Erzeugen von Terminen für Ablesungen,

Abschläge und Abrechnungen.

□ Stammdatenverwaltung

Verwalten der Stammdaten wie Geschäftspartner, Verträge, Anschlussobjekte,

Anlagen.

□ Geräteverwaltung

Verwaltung der Installation und Beglaubigung von Geräten.

□ Abrechnung

Abrechnung der Dienste Strom, Gas, Wasser, Abwasser, Fernwärme, Abfall,

Multimedia-Dienste.

□ Fakturierung

Zusammenführung von Leistungen auf einer Rechnung sowie deren

gemeinsame Fakturierung. Darüber hinaus können Steuern, Gebühren und

Abgaben ermittelt und erhoben werden.

□ Kundenservice

Über den Kundenservice können die wichtigen Geschäftsprozesse gestartet

sowie alle dafür benötigten Daten angezeigt werden. Bestandteile des

Kundenservice sind das Customer-Interaction-Center (CIC) bzw. das Front-

Office (für die Mitarbeiter) sowie die Internet-Self-Services (für die Kunden).

■ EDM (Energy Data Management)

In diesem Bereich erfolgen alle Funktionen bezüglich Lastgangmessung,

Energiemengenbilanzierung, Fahrplan-Management sowie Abrechnung von

Zeitreihen mit Hilfe der Real-Time-Pricing-Abrechnung. Das EDM besitzt dafür eine

zentrale Datenbank mit allen Energiedaten.

■ Work Management

Kombiniert verschiedene SAP-Komponenten und ergänzt sie um verschiedene

branchenabhängige Funktionen.

■ IS-U-WA (Waste and Recycling)

Deckt die betriebswirtschaftlichen Abläufe von Entsorgungsunternehmen ab.

■ IDE

IDE ist der unternehmensübergreifende Datenaustausch zwischen z.B. Lieferant,

Netzbetreiber und Kunden, der aufgrund der Deregulierung der Energiemärkte

notwendig ist.

1 Siehe auch [SAPBibUtil, 2008]


- 55 -

Die Komponente IS-U ist für dieses Fallbeispiel von zentraler Bedeutung, da alle

Daten, die der Analyse-Prozess-Designer im weiteren Verlauf verarbeitet, aus dieser

Branchenlösung extrahiert werden.

SAP Utilities, und damit auch IS-U, integriert verschiedene Standardkomponenten

des SAP-Systems oder anderer externer Systeme. Die folgende Abbildung soll diesen

Zusammenhang kurz darstellen:

Abbildung 24: Integrationsmodell des ISU

1

4.1.2 IS-U Haus

Das IS-U Haus ist eine grafische Darstellung der branchenspezifischen Stammdaten

eines Versorgungsunternehmens. Sie verdeutlicht die Eigenschaften sowie den

Zusammenhang der einzelnen Stammdaten untereinander.

1 In Anlehnung an [IUT110, 2005] S.24


- 56 -

Abbildung 25: IS-U Haus

1

Die Stammdaten werden unterteilt in kaufmännische und technische Stammdaten.

Die wichtigsten Stammdaten werden in der folgenden Übersicht erläutert:

Kaufmännische Stammdaten

■ Geschäftspartner

Der Geschäftspartner ist eine natürliche Person, eine Organisation oder Gruppe

von natürlichen Personen und besitzt ein oder mehrere Vertragskonten. Der

Geschäftspartner ist identisch mit dem Vertragspartner.

■ Vertragskonto

Das Vertragskonto sammelt alle Verträge zu einem Geschäftspartner und enthält

z.B. Daten über die Zahlungskonditionen oder die Bankverbindung.

■ Vertrag

Ein Vertrag bezieht sich immer auf eine Sparte, z.B. Strom oder Wasser und ist

u.a. für die Abrechnung sowie die Abschlagsplanerstellung von Bedeutung.

Technische Stammdaten

■ Anschlussobjekt

Bei dem Anschlussobjekt handelt es sich zumeist um ein Gebäude oder ein

Grundstück. Es beinhaltet eine oder mehrere Verbrauchsstellen.

■ Verbrauchsstelle

Die Verbrauchsstelle ist eine räumlich abgetrennte Einheit, z.B. eine Wohnung.

Einer Verbrauchsstelle können eine oder mehrere Anlagen zugeordnet haben.



- 57 -

■ Anlage

Die Anlage umfasst alle Geräte und Zählwerke einer Sparte, die gemeinsam

abgerechnet werden.

■ Geräteplatz

Der Geräteplatz bezeichnet den Ort im Anschlussobjekt, an dem sich Geräte

befinden, z.B. Korridor oder Keller.

■ Zählpunkt

Der Zählpunkt ist eine Stelle, an der eine Leistung erbracht wird. Er besitzt eine

Zählpunktbezeichnung, die aus einem 33-stelligen Schlüssel zusammengesetzt

und innerhalb von Deutschland eindeutig ist. Der Zählpunkt wird für die

Kommunikation zu externen Systemen verwendet.

4.1.3 Ablauf der Vertragsabrechnung

Auf einer hohen Abstraktionsebene lässt sich der Vorgang der Vertragsabrechnung

in die Teilschritte Ablesung, Abrechnung und Fakturierung unterteilen.

Abbildung 26: Ablauf der Vertragsabrechnung (vereinfacht)

Abbildung 26 zeigt den Vorgang in einer stark vereinfachten Form. In der Praxis

verbirgt sich hinter den Teilschritten eine Vielzahl weiterer Prozesse, Komponenten

und Zusammenhänge. Nachfolgend werden nur die Aspekte näher betrachtet, die für

die Fallstudie von besonderer Bedeutung sind.1

Ablesung

Bei dem Vorgang der Ablesung wird der aktuelle Zählerstand der Geräte zum Zweck

der Abrechnung abgelesen. Dieser Vorgang kann auf verschiedene Arten

durchgeführt werden (manuell, maschinell, Kundenselbstablesung). Gemeinsam

haben diese Verfahren, dass zunächst Ableseaufträge erstellt werden, sobald der

Termin der Ablesung erreicht ist. Die Ablesung wird durchgeführt und die

Ergebnisse werden in einem Ablesebeleg erfasst. Nachdem sie übermittelt wurden,

folgt eine Plausibilitätsprüfung und ggf. eine Korrektur der Ableseergebnisse.

Zusammen mit dem Ableseauftrag wird ein Abrechnungsauftrag erzeugt. Der

Abrechnungsauftrag benötigt den Ablesebeleg mit plausiblen Zählerständen, um das

Kennzeichen „abrechenbar“ zu erhalten.

Mehrere Ablesungen werden in der Regel in sogenannten Ableseeinheiten

zusammengefasst. Diese beinhalten verschiedene Stadtteile, Straßen, Anschluss-

1 Weiterführende Informationen siehe [IUT110, 2005] S.215ff


- 58 -

objekte, Geräteplätze bis zu den einzelnen Geräten und werden über eine

Ablesereihenfolge effektiv abgearbeitet.

Jede Ablesung hat einen spezifischen Ablesegrund. Im IS-U sind 31 verschiedene

Gründe definiert, wie z.B. Turnusablesung (z.B. jährlich), Zwischenablesung,

Einzugsablesung oder Kontrollablesung.

Abrechnung

In der Abrechnung werden die bereits erzeugten Abrechnungsaufträge verarbeitet.

Die aus der Ablesung bekannten Verbräuche sowie andere Leistungen des

Unternehmens werden mit Preisen bewertet. Das Ergebnis der Abrechnung ist der

Abrechnungsbeleg. Dieser wird für die Fakturierung benötigt. Der

Abrechnungsauftrag wird nach erfolgreicher Abrechnung gelöscht.

Fakturierung

Die Fakturierung stellt die Verbindung zum Vertragskontokorrent1 her. In der

Fakturierung werden die angefallenen Forderungen gesammelt und mit den bisher

geleisteten Abschlagszahlungen des Kunden verrechnet. Auch die Verwaltung und

Erzeugung von Abschlagsplänen erfolgt in der Fakturierung. Darüber hinaus sind das

Mahnwesen und das Sperren Aufgabengebiete der Fakturierung. Abschließend

werden die Rechnungen erstellt und gedruckt. Dieser Vorgang erzeugt einen

Druckbeleg.

Der gesamte Abrechungsvorgang mit den beteiligten Komponenten ist noch einmal

in der folgenden Abbildung dargestellt:

Abbildung 27: Ablauf der Vertragsabrechnung

2




- 59 -

Stornierung

Bei der Stornierung werden einzelne Belege mit einem Stornierungskennzeichen

versehen und dadurch als fehlerhaft gekennzeichnet. Die Datensätze befinden sich

dabei weiter im System, werden jedoch in den anschließenden Prozessen nicht weiter

betrachtet. Wird z.B. ein Abrechnungsbeleg storniert, erhält dieser ein Storno-

Kennzeichen, wonach ein neuer, korrekter Abrechnungsbeleg erzeugt wird.

Man unterscheidet zwischen Einzelstorno und Gesamtstorno. Bei der

Einzelstornierung wird nur ein Abrechnungsbeleg oder ein Fakturierungsbeleg

storniert. Beim Gesamtstorno werden alle zusammenhängenden Belege gleichzeitig

storniert.

Simulation

Mit Hilfe der Simulation können Abrechnungen und Fakturierungen simuliert

werden. Mit diesem Verfahren ist es z.B. möglich Prognosen zu erstellen, Aspekte

der bilanziellen Abgrenzung zu berücksichtigen oder Abschlagspläne zu generieren.

Bei der Simulation der Abrechnung werden Simulationsbelege erstellt. Sie werden

ausschließlich in der Fakturierungssimulation verwendet.1

4.2 Zielsetzung

Das Ziel der Fallstudie ist es, einen Überblick zu erhalten, welche Anlagen eines

Energieversorgungsunternehmens abgelesen, abgerechnet und fakturiert wurden.

Folgende Fragestellungen sollen mit den Ergebnissen beantwortet werden:

■ Welche Anlagen wurden abgelesen?

■ Welche Anlagen wurden nicht abgelesen?

■ Welche Anlagen wurden abgerechnet?

■ Welche Anlagen wurden nicht abgerechnet?

■ Welche Anlagen wurden fakturiert?

■ Welche Anlagen wurden nicht fakturiert?

■ Welche Anlagen wurden abgelesen, jedoch nicht abgerechnet?

■ Welche Anlagen wurden abgelesen und abgerechnet, jedoch nicht fakturiert?

Zudem soll eine weitere Aufschlüsselung der Ergebnisse anhand folgender Kriterien

möglich sein:

■ Sparte

■ Ableseeinheit

■ Anlage

■ Abrechnungsrelevantes Datum

1 Weiterführende Informationen siehe [IUT110, 2005] S.303ff


- 60 -

■ Abrechnungsrelevantes Jahr

■ Ablesegrund

Mögliche Beispielfragen in diesem Zusammenhang können sein:

■ Wie viele und welche Anlagen wurden in der Sparte Strom nicht abgelesen?

■ Wie viele Ablesungen mit dem Ablesegrund „Turnusablesung“ wurden zum

abrechnungsrelevanten Datum „17.08.2007“ zwar abgerechnet, jedoch nicht

fakturiert?

■ Zu welchen Ableseeinheiten gehören die Ablesungen, die vermehrt nicht

abgerechnet werden?

■ …

Die Kombination der verschiedenen Kriterien erlaubt dabei eine Vielzahl an

möglichen Sichten auf die Ergebnisse.

4.3 Konzept

Abbildung 28: Grobkonzept der Umsetzung der Fallstudie

Der erste Schritt der Umsetzung ist, zunächst die Ziele und die dahinter stehenden

Geschäftsprozesse zu analysieren und zu verstehen. Nur so ist es möglich, die Daten

zu identifizieren, die für den Analyseprozess und damit für das Erreichen der

definierten Ziele notwendig sind.


- 61 -

Es ist wichtig festzulegen, welche Daten von Bedeutung sind, aus welcher Tabelle

sie extrahiert werden können und ob möglicherweise Verknüpfungen verschiedener

Tabellen vor dem eigentlichen Prozess der Datenbeschaffung sinnvoll sind.

Anschließend müssen die Daten für die Weiterverarbeitung im Analyse-Prozess-

Designer in das Business Warehouse übertragen werden. Dazu sollte der Business

Content zunächst näher betrachtet werden, um den Prozess der Datenbeschaffung zu

standardisieren und zu vereinfachen. Ist es nicht möglich, alle benötigten Daten über

den vorhanden Business Content zu extrahieren, müssen die DataSources selbst

erzeugt oder der Business Content angepasst werden. Sowohl im Prozess der

Datenbeschaffung als auch im späteren Verlauf des Analyseprozesses sollte die

Datenqualität optimiert werden.

Anschließend werden die Daten im Analyse-Prozess-Designer verknüpft und

transformiert. Eine regelmäßige Prüfung der Zwischenergebnisse vereinfacht das

Auffinden von Fehlern sowie deren Beseitigung direkt an der Stelle an der sie

auftreten. Nach der Durchführung des Analyseprozesses werden die Endergebnisse

geprüft sowie Queries für die verschiedenen Abfragen erzeugt.

Die Optimierung und ggf. Erweiterung sind ein begleitender Prozess, da die

einzelnen Phasen immer wieder zu Erkenntnissen führen, die das gesamte Konzept

und damit auch die Ergebnisse verbessern können.

4.4 Datenauswahl

Dieser Abschnitt beschreibt, welche Daten für die Zielsetzungen der Fallstudie

benötigt werden und aus welchen Datenbanktabellen des IS-U diese zu beschaffen

sind.

Anlagen

Um Aussagen darüber machen zu können, ob eine Anlage abgelesen, abgerechnet

und fakturiert worden ist, werden zunächst alle aktiven Anlagen benötigt. Diese

werden über ihre Anlagennummer eindeutig identifiziert. Um die aktiven von den

inaktiven Anlagen trennen zu können, werden darüber hinaus die zeitabhängigen

Daten (gültig ab, gültig bis) zu den Anlagen benötigt.

Die zeitunabhängigen Daten befinden sich im IS-U in der Tabelle EANL. Dabei

werden nur folgende Daten benötigt:

■ Anlagennummer

■ Sparte

Die Sparte ist laut Zielsetzung für die Differenzierung in der späteren Auswertung

von Bedeutung. Da in der Tabelle EANL jeder Anlage eine Sparte zugeordnet ist,

werden diese Informationen an dieser Stelle direkt mit extrahiert.


- 62 -

Die zeitabhängigen Daten befinden sich in der Tabelle EANLH. Es werden folgende

Daten benötigt:

■ Anlagennummer

■ gültig bis

Über das Feld gültig bis werden im späteren Verlauf die inaktiven Anlagen

ausgefiltert.

Obwohl in beiden Tabellen jeweils alle Anlagen mit ihrer Anlagennummer vertreten

sind, ist es dennoch nötig, beide Tabellen auszulesen, da die Informationen bezüglich

der Sparte nicht in der Anlagen-Tabelle mit den zeitabhängigen Daten vorhanden

sind. Darüber hinaus ist es nur an dieser Stelle möglich, die Daten auszulesen, wenn

einer Anlage die weder abgelesen, noch abgerechnet, noch fakturiert wurde, eine

Sparte zugeordnet werden soll.

Ablesebeleg

Um eine Aussage darüber machen zu können, ob eine Anlage abgelesen wurde,

werden die Ablesebelege benötigt.

Die Daten über die Ablesebelege befinden sich in der Tabelle EABL. Es werden

folgende Daten benötigt:

■ Ablesebelegnummer

■ abrechnungsrelevantes Datum

■ Ablesestatus

In dieser Tabelle gibt es u.a. noch die Felder geplantes Ablesedatum und

tatsächliches Ablesedatum. Letzteres ist nur dann mit Daten gefüllt, wenn das

geplante Ablesedatum nicht eingehalten wurde. Das abrechnungsrelevante Datum

entspricht jedoch immer dem späteren der beiden Daten und ist damit immer das

Datum, am dem die Ablesung stattgefunden hat. Somit können komplizierte

Verfahren zum Abgleich zwischen geplantem und tatsächlichem Ablesedatum

vermieden werden.

Das abrechnungsrelevante Datum wird für die Auswertung verwendet, um zeitliche

Bezüge zwischen den Ablesungen, Abrechungen und Fakturierungen herzustellen.

Der Ablesestatus gibt u.a. Auskunft darüber, ob bisher lediglich ein Ableseauftrag

erstellt wurde oder ob eine Ablesung tatsächlich schon stattgefunden hat.

Ablesegrund

Die Datenbanktabelle mit den Ablesegründen wird in zweifacher Hinsicht benötigt.

Zum Einen um eine Differenzierung in der späteren Auswertung bezüglich der

Gründe der Ablesung machen zu können, zum Anderen um den Anlagen einen

Ablesebeleg zuzuordnen.


- 63 -

Die Daten bezüglich des Ablesegrundes befinden sich in der Tabelle EABLG. Es

werden folgende Daten benötigt:


■ Anlagennummer

■ Ablesegrund

So kann mit dieser Tabelle aufgrund der Felder Ablesebelegnummer und

Anlagennummer die Verbindung zwischen den Anlagen und den Ablesebelegen

geschaffen werden.

Abrechnungsbeleg

Der Abrechnungsbeleg ist das Ergebnis der Abrechnung und dient als Beweis, dass

eine Anlage abgelesen wurde.

Die Daten des Abrechnungsbelegs befinden sich in der Tabelle ERCH. Folgende

Daten werden benötigt:

■ Abrechnungsbelegnummer

■ Stornodatum

■ Simulation

Existiert ein Stornodatum zu einem Abrechnungsbeleg, wurde die Abrechnung

storniert. Somit ist dieser Eintrag für die Auswertung nicht mehr relevant und wird

im späteren Verlauf ausgefiltert.

Wurde der Abrechnungsbeleg nur zum Zweck der Simulation erzeugt, so wird dies

über das Feld Simulation deutlich. Auch diese Abrechnungsbelege werden im

Analyseprozess aussortiert.

Abrechnungsbelegzeilen

Im IS-U werden die einzelnen Positionen des Abrechnungsbelegs in der Tabelle

DBERCHZ gespeichert. Mit Hilfe dieser Tabelle kann die Verbindung zwischen

einem Ablesebeleg und einem Abrechnungsbeleg hergestellt werden. Dies ist

entscheidend, um eine Aussage darüber treffen zu können, ob eine Anlage zwar

abgelesen aber ggf. nicht abgerechnet wurde.

Folgende Daten werden benötigt:



Aufgrund der o.g. Felder wird deutlich, dass mit Hilfe der Abrechnungsbelegnummer

und der Ablesebelegnummer die Verknüpfung der beiden Belege ermöglicht wird.

Fakturierungsbelege/Druckbelege

Mit Hilfe der Fakturierungsbelege bzw. der Druckbelege, die das Ergebnis der

Fakturierung darstellen, kann festgestellt werden, ob eine Anlage fakturiert wurde.


- 64 -

Diese Daten befinden sich in der Tabelle ERCHC. Folgende Daten werden benötigt:


■ Druckbelegnummer

■ Datum Fakturastornierung

■ Beleg gebucht

Eine Zuordnung der Druckbelege zu den Abrechnungsbelegen erfolgt über die Felder

Abrechnungsbelegnummer und Druckbelegnummer. Ist ein Beleg gebucht, befindet

sich ein Eintrag im Feld Beleg gebucht. Simulierte Belege besitzen dort keinen

Eintrag. Das Datum der Fakturastornierung wird benötigt, um im Analyse-Prozess-

Designer die stornierten Fakturierungen aussortieren zu können.

Die o.g. Daten bilden die Grundlage für den späteren Analyseprozess. Zusätzlich zu

diesen Daten können aus den bereits ausgewählten Tabellen eine Vielzahl weiterer

Informationen extrahiert werden, um die spätere Auswertung noch detaillierter

gestalten zu können. In diesem Fallbeispiel beschränken sich die benötigten Daten

jedoch auf die Anforderungen, die aus den Zielsetzungen hervorgehen. Eine

Erweiterung des gesamten Konzepts um weitere Daten ist jedoch ohne großen

Aufwand möglich.

4.5 Datenbeschaffung

Nachdem die benötigten Daten und Tabellen identifiziert sind, gilt es nun die Daten

für den Analyseprozess im SAP BW zur Verfügung zu stellen. Dafür wird zunächst

geprüft, ob und in welcher Form der vorhandene Business Content für diesen

Datenbeschaffungsprozess verwendet werden kann. Ist dies nicht möglich, werden

generische DataSources, welche die Daten aus dem Quellsystem extrahieren, neu

erzeugt.

Analyse des vorhandenen Business Content

Da der Analyseprozess, wie bereits beschrieben, in einem SAP BW 3.1 Testsystem

durchgeführt wird, der eine ältere Version des Business Content verwendet, ist es

vielfach nicht möglich mit Hilfe der vorgefertigten Objekte die benötigten Daten aus

dem Quellsystem in das SAP BW zu übertragen. Lediglich die zeitabhängigen und

zeitunabhängigen Daten der Anlagen werden mit Hilfe der vorhandenen DataSources

extrahiert.

Bei näherer Betrachtung des BW 7.0 Testsystems wird deutlich, dass der Business

Content im Laufe der Jahre erheblich erweitert wurde. So wäre es hier durchaus

möglich, fast alle Daten mit Hilfe des Content zu extrahieren und in das BW zu

laden.

In der Praxis wird versucht, möglichst den vorhandenen Business Content zu

verwenden. Aus diesem Grund und der Tatsache, dass das verwendete Testsystem


- 65 -

sich nicht auf dem neuesten Stand befindet, wird im weiteren Verlauf dieses

Abschnittes nur kurz auf die Datenbeschaffung mit Hilfe von generischen

DataSources eingegangen.

Generische DataSources

Mit den generischen DataSources ist es möglich, eigene Strukturen für die Extraktion

von Daten zu erzeugen, wenn der vorhandene Business Content nicht ausreichend ist.

So kann z.B. eine Datenbanktabelle oder ein View als Quelle dienen. Dabei können

beliebige Felder ausgewählt werden, die extrahiert werden sollen. Zusätzlich kann

über ein Deltaverfahren und die Möglichkeit der Datenselektion innerhalb der

InfoPackages entschieden werden.

Wie bereits erwähnt, ist es möglich, im Quellsystem Views als Basis der

DataSources zu verwenden, um so mit Hilfe nur weniger DataSources alle benötigten

Daten extrahieren zu können. Um eine größere Transparenz und Flexibilität des

Analyseprozesses zu ermöglichen, wird jedoch in diesem Fallbeispiel zu jeder

Tabelle aus der Daten extrahiert werden sollen, eine eigene generische DataSource

erzeugt. Im weiteren Verlauf werden die Daten in separaten ODS-Objekten

gespeichert.

Datenfluss

Aufgrund der Verwendung von jeweils einer DataSource für jede auszulesende

Datenbanktabelle ist der Datenfluss zum SAP BW für alle Daten nahezu identisch.

Aus diesem Grund wird in der folgenden Abbildung lediglich ein Datenfluss

beispielhaft dargestellt.

Abbildung 29: Beispiel Datenfluss der Umsetzung


- 66 -

Aus dem Quellsystem werden die Daten mit Hilfe der replizierten DataSources über

die PSA und die InfoSource in das ODS-Objekt gespeichert. Die Übertragungs- und

Fortschreibungsregeln werden zunächst nicht für die Transformationen der Daten

verwendet, um die Flexibilität des Analyseprozesses nicht zu beeinflussen und alle

Transformationen transparent und übersichtlich im APD darzustellen.1

Datenübertragung

Zu Testzwecken wird zunächst nur ein Teil der Datenmenge aus dem Quellsystem in

das Business Warehouse übertragen und im Analyseprozess verwendet. So ist eine

schnelle Durchführung des Prozesses sowie die Überprüfung der Zwischen- und

Endergebnisse möglich. Deshalb werden in den InfoPackages die Selektionskriterien

so gewählt, dass nur 500-1000 Datensätze aus den Tabellen übertragen werden.

Erst nachdem das Modell mit den Teildaten vollständig getestet und überprüft ist,

werden alle zur Verfügung stehenden Daten in das Modell übertragen.

Die Daten werden bei der vollständigen Extraktion nicht gefiltert, d.h. es findet keine

zeilenweise Selektion statt. Stattdessen findet die Filterung im Analyseprozess statt

(z.B. alle inaktiven Anlagen entfernen), um alle durchgeführten Transformationen

übersichtlich mit Hilfe des APD durchzuführen und darzustellen.

Lediglich die Extraktion der Abrechnungsbelegzeilen aus der Tabelle DBERCHZ

bildet hierbei eine Ausnahme. Die Tabelle ist so umfangreich, dass es sinnvoll ist

schon beim Ladevorgang die Daten zu filtern, um so nur die Datensätze zu

transferieren in denen sich die Beziehungen zwischen Abrechnungsbelegnummern

und Ablesebelegnummern widerspiegeln. Alle weiteren unnötigen Datensätze

werden an dieser Stelle bereits aussortiert.

4.6 Analyseprozess

Nachdem die Daten im SAP BW zur Verfügung stehen, kann der Analyseprozess mit

Hilfe des APD modelliert werden.

Um das Gesamtkonzept des Analyseprozesses besser zu veranschaulichen, wird

zunächst der grundsätzliche Gedankengang auf einem höheren Abstraktionsniveau

beschrieben. Anschließend wird das vollständige Modell dargestellt und schrittweise

erläutert.

1 Siehe auch Abschnitt 3.6, Abgrenzung zu den Möglichkeiten im BW, auf Seite 51


- 67 -

4.6.1 Grundlegender Ablauf

Abbildung 30: Ablauf des Analyseprozesses

Zunächst werden alle Anlagen ermittelt, die sich aktiv im System befinden und gültig

sind (also vom Kunden verwendet werden).

Anschließend werden den Anlagen die Ablesebelege zugeordnet. Ist ein Ablesebeleg

zu einer Anlage vorhanden, wurde diese zum entsprechenden Datum abgelesen.

Dann werden die Abrechnungsbelege den Ablesebelegen zugeordnet. Existiert ein

Abrechnungsbeleg zu einem Ablesebeleg, so wurde die Anlage nicht nur abgelesen,

sondern auch abgerechnet. Existiert kein Abrechnungsbeleg zu einem Ablesebeleg,

wurde die Anlage zwar abgelesen, jedoch nicht abgerechnet.

Im letzten Schritt werden die Fakturierungs- bzw. Druckbelege den Abrechnungs-

belegen zugeordnet. Gibt es einen Druckbeleg zu einem Abrechnungsbeleg, wurde

die Anlage fakturiert. Andernfalls wurde sie zwar abgelesen und abgerechnet, jedoch

nicht fakturiert.

Dieser grundlegende Ablauf abstrahiert viele Gegebenheiten und Einschränkungen.

Er bildet jedoch das Grundgerüst für den vollständigen Analyseprozess.

4.6.2 Detaillierte Modellbeschreibung

In Abbildung 31 ist das vollständige Modell des Analyseprozesses für das

Fallbeispiel der Anlagen-Analyse dargestellt.

Um die einzelnen Transformationen und Verknüpfungen verständlich beschreiben zu

können, wurde jeder Teilschritt mit einer Nummer versehen.1 Jeder dieser Schritte

wird in den folgenden Abschnitten detailliert erläutert. Die Bezeichnungen der

Schritte können von denen aus der Abbildung abweichen, da für das Modell eine

möglichst kurze Bezeichnung aus Gründen der Übersichtlichkeit sinnvoll ist.

1 Eine vergrößerte, nicht nummerierte Darstellung befindet sich in Abschnitt 6.1, Anhang, auf Seite 91


- 68 -

Abbildung 31: Anlagen-Analyse-Prozess

Schritt 1 – Anlage (zeitunabhängige Daten)1

Der erste Schritt stellt lediglich die zeitunabhängigen Daten der Anlage dem APD-

Prozess zur Verfügung. Dafür wird das ODS-Objekt, in das die Anlage-Daten bei der

Extraktion geladen wurden, als Datenquelle ausgewählt.


- 69 -

Ein Ausschnitt der Daten wird in der folgenden Abbildung dargestellt:

Abbildung 32: Zwischenergebnis Schritt 1

Somit stehen alle vorhandenen Anlagen, identifiziert über ihre Anlagennummer,

sowie die dazugehörigen Sparten zur Verfügung.

Schritt 2 – Anlage (zeitabhängige Daten) 2

Im zweiten Schritt werden die zeitabhängigen Daten der Anlagen als Quelle

definiert.


Zu jeder Anlagennummer existiert damit ein Eintrag bis zu welchem Datum eine

Anlage gültig ist. In Abbildung 33 gibt es zu der Anlagennummer 1230000003 zwei

Einträge. Aus dem ersten Datensatz wird deutlich, dass die Anlage bis zum

30.09.2001 gültig war. Anschließend wurde sie erneut aktiviert und ist bis zu dem

aktuellen Datum gültig (dies ist am Datum 31.12.9999 ersichtlich).

Schritt 3 – Inaktive Anlagen entfernen3

In Schritt 3 werden alle inaktiven Anlagen aus Schritt 2 entfernt. Diese Selektion

erfolgt anhand des Feldes gültig bis. Alle Einträge die nicht 31.12.9999 als Wert

besitzen, werden aussortiert. Durch dieses Vorgehen werden zusätzlich diejenigen

Anlagen weitergereicht, die zwischenzeitlich nicht aktiv waren, aktuell aber wieder

gültig sind.


- 70 -


Wie die Abbildung zeigt, wurden alle Einträge mit einem anderen Datum als dem

31.12.9999 entfernt.

Schritt 4 – Aktive Anlagen mit Sparte4

Mit Hilfe dieser Verknüpfung werden die Anlagennummern aus Schritt 1 mit denen

aus Schritt 3 verknüpft. Zusätzlich wird die Sparte übernommen. Der eigentliche

Sinn liegt jedoch darin, dass aus der Tabelle der Anlagen mit den Sparten alle

inaktiven Anlagen gelöscht werden.

Abbildung 35: Verknüpfung in Schritt 3

Dies geschieht durch die Verknüpfung der Tabellen mittels Inner Join über die

Felder der Anlagennummer. Somit werden nur die Anlagen in die Ergebnismenge

übernommen, die sich in beiden Tabellen befinden.


Das Ergebnis sind demnach alle aktiven Anlagen mit ihren Sparten. Das Feld gültig

bis hat seinen Zweck erfüllt und wird im weiteren Verlauf nicht weiter benötigt und

somit auch nicht übernommen.

Der Umweg der Filterung der Daten über die genannten Schritte ist deshalb

notwendig, weil auf der einen Seite nur in den zeitabhängigen Daten das Feld gültig

bis vorhanden ist und sich auf der anderen Seite die Angabe zu den Sparten nur in

der Tabelle mit den zeitunabhängigen Daten befindet.

Alternativ wäre es auch möglich, zunächst die Verknüpfung der beiden Tabellen

durchzuführen und anschließend die inaktiven Daten auszusortieren. Das Ergebnis ist


- 71 -

in beiden Fällen dasselbe. Die Performance erhöht sich jedoch, wenn die zu

verknüpfende Datenmenge möglichst gering ist.

Schritt 5 – Ablesebelege5

In diesem Schritt werden alle Ablesebelege mit ihren eindeutigen Nummern, dem

Ablesestatus sowie dem abrechnungsrelevanten Datum zur Verfügung gestellt.


Schritt 6 – Bisher nicht durchgeführte Ablesungen entfernen6

Es existieren Ablesebelege, zu denen noch keine Ablesung durchgeführt wurde.

Diese sind durch den Ablesestatus 0 gekennzeichnet und werden in diesem Schritt

ausgefiltert.

Schritt 7 – Ablesegrund7

Schritt 7 versorgt den APD-Prozess mit den Daten der Ablesegründe.


Wie aus der Abbildung deutlich wird, kann es zu einem Ablesebeleg mehrere

Ablesegründe geben. So gehören beispielsweise die Ablesegründe 08, 06 und 21

zusammen (sie stehen für die Vorgänge Einzugsablesung, Ablesung zum technischen

Einbau und Ablesung zum abrechnungstechnischen Einbau).

Zusätzlich werden neben den Ableseeinheiten auch die Anlagennummern, die zu

einem Ablesebeleg gehören, zur Verfügung gestellt.


- 72 -

Schritt 8 – Ablesegründe ohne Abrechnung entfernen8

Wie aus den Ausführungen zu den Ablesegründen deutlich wird, folgt nicht

zwangsläufig auf einen Ablesebeleg mit einem bestimmten Ablesegrund auch eine

Abrechnung (z.B. Ablesung zum technischen Einbau). Ablesebelege die keine

Abrechnung zur Folge haben, sind für die Auswertung nicht relevant und verfälschen

das Ergebnis. Aus diesem Grund werden nur folgende Ablesegründe berücksichtigt:

■ 01 – Turnusablesung

■ 02 – Zwischenablesung mit Abrechnung

■ 03 – Schlussablesung mit Umzug

■ 04 – Gebietsablesung mit Abrechnung

Die Ablesebelege mit anderen Gründen werden in diesem Schritt aussortiert. Sollen

dennoch andere Ablesegründe weiter berücksichtigt werden, ist dies durch einfache

Modifikation dieses einzelnen Transformationsschrittes möglich.


Im Vergleich zu Abbildung 38 wird in dieser Grafik deutlich, dass nur die

Ablesebelege mit den genannten Ablesegründen weitergegeben werden.

Schritt 9 – Zuordnung Ablesegründe zu den Ablesebelegen9

An dieser Stelle werden die Ergebnisse der Schritte 6 und 8 miteinander verknüpft.

Somit werden nicht nur den Ablesebelegen die Ablesegründe zugeordnet, sondern

auch alle Ablesebelege entfernt, deren Ablesegründe nicht betrachtet werden sollen.

Abbildung 40: Verknüpfung Schritt 9


- 73 -

Die Verbindung erfolgt mittels Inner Join über die Felder Ablesebelegnummer.

Alternativ hätten erst die Verknüpfungen der Ablesebelege mit den Gründen und

anschließend die beiden Filteraktionen durchgeführt werden können. Jedoch ist es,

wie bereits in Schritt 4 erläutert, aus Performancegründen sinnvoll, die zu

verknüpfenden Datenmengen möglichst zu minimieren.


Das Ergebnis dieses Schrittes sind die Ablesebelege mit ihren Ableseeinheiten,

Ablesegründen und den abrechungsrelevanten Daten.

Schritt 10 – Zuordnung Ablesebelege zu Anlagen10

In diesem Schritt erfolgt die Zuordnung der Anlagen zu den Ablesungen, d.h. bereits

nach diesem Schritt kann eine Aussage darüber getroffen werden, ob eine Anlage

abgelesen wurde.


Über die Anlagennummer, die sich sowohl in der Tabelle der Ablesebelege als auch

in der Anlagen-Tabelle befindet, werden alle Daten miteinander kombiniert. In

diesem Fall erfolgt die Verknüpfung über einen Left Outer Join, wobei die aktiven

Anlagen die „linke Tabelle“ darstellen. Dadurch werden zum Einen die Ablesebelege

den richtigen Anlagen zugeordnet, andererseits bleibt das Feld der

Ablesebelegnummer in der Ergebnistabelle leer, wenn es keinen Ablesebeleg zu

einer Anlage gibt. Nur so ist es möglich festzustellen, dass eine Anlage nicht

abgelesen wurde.


- 74 -


Aus der Ergebnismenge wird deutlich, dass eine Anlage mehrere Ablesebelege

besitzen kann. Dieser Umstand ergibt sich daraus, dass Ablesungen immer wieder

durchgeführt werden, z.B. jährlich.

Schritt 11 – Abrechnungsbeleg11

Schritt 11 liefert lediglich die Daten zu den Abrechnungsbelegen und beinhaltet

neben der Abrechnungsbelegnummer auch ein mögliches Stornodatum sowie ein

Kennzeichen, ob der Beleg ausschließlich zur Simulation erzeugt wurde.


Schritt 12 – Stornierte u. simulierte Abrechnungsbelege entfernen12

In diesem Schritt werden die Abrechnungsbelege gefiltert. Nur solche Belege, die

weder storniert, noch ausschließlich zum Zweck der Simulation erzeugt wurden,

werden weitergegeben.


Somit befindet sich in der Ergebnismenge zu keinem Datensatz ein Stornodatum

oder ein Simulationskennzeichen.


- 75 -

Schritt 13 – Abrechnungsbelegzeilen13

Schritt 13 stellt die Abrechnungsbelegzeilen zur Verfügung. Diese ermöglichen die

Zuordnung von Abrechnungsbeleg zu Ablesebeleg. Dabei können zu einem

Abrechnungsbeleg mehrere Ablesebelege existieren.


Schritt 14 – Stornierte Belegzeilen entfernen14

Durch die Verknüpfung der Schritte 12 und 13 ist es möglich, all jene Zuordnungen

von Abrechnungs- und Ablesebelegen zu löschen, die durch stornierte oder

simulierte Belege entstanden sind.


Technisch erfolgt diese Umsetzung erneut mit Hilfe des Inner Join. Dieser sorgt

dafür, dass alle Abrechnungsbelegzeilen entfernt werden, die zu den stornierten oder

simulierten Abrechnungsbelegen gehören.

Das Stornodatum sowie das Kennzeichen für die Simulation werden nicht weiter

benötigt und daher nicht übernommen.



- 76 -

Schritt 15 – Zuordnung Abrechnungsbelege zu Ablesebelegen15

Schritt 15 ordnet den Anlagen mit den Ablesebelegen die Abrechnungsbelege zu.

Somit kann ab dieser Stelle eine Aussage darüber getroffen werden, ob eine Anlage

abgerechnet wurde.


Die Verknüpfung erfolgt erneut mittels Left Outer Join über das Feld der

Ablesebelegnummer. Die Felder der Anlagen mit Ablesebelegen, die keinen

Abrechnungsbeleg haben, bleiben leer. Nur so ist eine Aussage möglich, welche

Anlagen zwar abgelesen, aber nicht abgerechnet wurden.


Schritt 16 – Sortierung nach Anlagen16

In diesem Schritt werden die Daten aufsteigend nach den Anlagennummern sortiert.

Mit Hilfe der Sortierung können die Zwischenergebnisse besser kontrolliert und

dargestellt werden. Auf den weiteren Verlauf des Prozesses hat die Sortierung keinen

Einfluss, da die Daten bei den meisten Transformationen schon im Vorfeld intern

sortiert werden, so dass eine separate Sortierung lediglich zu Performanceeinbußen

führt. Aus diesem Grund sollten die Sortierungen bei umfangreichen

Analyseprozessen nach erfolgreichem Testen der Zwischen- und Endergebnisse

entfernt werden.


- 77 -

Schritt 17 – Nicht simulierte Fakturierungsbelege (Druckbelege) 17

Schritt 17 stellt dem Prozess die Druckbelege zur Verfügung. Dabei wurden die

simulierten Belege bereits bei der Extraktion der Daten ausgefiltert.


Neben der Zuordnung von Abrechnungsbeleg und Fakturierungsbeleg befinden sich

in den gegebenen Daten das Buchungsdatum der Fakturastornierung sowie das

Kennzeichen, ob der Abrechnungsbeleg fakturiert wurde.

Schritt 18 – Stornierte Fakturierungen entfernen18

In diesem Schritt werden alle stornierten oder nicht gebuchten Druckbelege entfernt,

da sie zu falschen Ergebnissen in der Auswertung führen würden. Somit werden nur

solche Datensätze weitergegeben, die einen Eintrag im Feld Beleg gebucht und

keinen Eintrag im Feld Buchungsdatum Fakturastornierung besitzen.


Schritt 19 – Zuordnung Druckbelege zu Abrechnungsbelege19

Nun erfolgt die Zuordnung der Druckbelege zu den Abrechnungsbelegen. Somit

kann eine Aussage darüber getroffen werden, ob eine Anlage fakturiert wurde.

Befindet sich kein Eintrag im Feld für den Druckbeleg, wurde die Anlage mit dem

jeweiligen Ablesebeleg und dem entsprechenden Abrechnungsbeleg nicht fakturiert.


- 78 -


Technisch wird die Verknüpfung erneut mit Hilfe des Left Outer Joins realisiert. Die

Felder Buchungsdatum der Fakturastornierung sowie Belege gebucht haben ihren

Zweck erfüllt und werden nicht weiter benötigt.

Das sortierte Ergebnis von Schritt 19 sieht wie folgt aus:


An dieser Stelle wird deutlich, dass eine Anlage an einem bestimmten Datum zwar

abgelesen (es existiert eine Ablesebelegnummer) und auch abgerechnet (es existiert

eine Abrechnungsbelegnummer), jedoch ggf. nicht fakturiert wurde (es existiert

keine Druckbelegnummer).

Schritt 20 – Sortieren nach Anlagen20

Wie bereits in Schritt 16 erläutert, wird die Sortierung der Anlagen nur zum Zweck

der übersichtlicheren Darstellung verwendet.

Schritt 21 – Routine zur Ermittlung von Kennzahlen und Jahr21

Die ABAP-Routine in Schritt 21 verfolgt zwei Ziele. Zum Einen soll aus dem

abrechnungsrelevanten Datum die Jahreszahl in ein separates Feld geschrieben

werden. Zum Anderen sollen die Felder Anlage abgelesen, Anlage nicht abgelesen,

Anlage abgerechnet, Anlage nicht abgerechnet, Anlage fakturiert, Anlage nicht

fakturiert erzeugt und mit 0 oder 1 gefüllt werden (siehe Abbildung 55). Diese

generierten Kennzahlen erlauben in der späteren Auswertung die Aggregation der

Anlagen.


- 79 -

Aus Gründen der Performance werden beide Aufgaben innerhalb von nur einer

Routine abgearbeitet. Andernfalls müssten alle Datensätze zweimal durchlaufen

werden, was den gesamten Prozess deutlich verlangsamen würde.

Das Ergebnis wird aus Abbildung 55 deutlich.


1

In der Routine werden die Felder Ableseeinheit, Ablesegrund, Sparte und Anlage als

Gruppierungsfelder definiert. Sie stehen der Routine somit nicht zur Verfügung und

werden einfach weitergereicht.

Die Felder abrechnungsrelevantes Datum, Ablesebelegnummer, Abrechnungs-

belegnummer sowie Druckbelegnummer werden als Quellfelder definiert und werden

benötigt, um die neuen Felder mit Inhalt zu füllen.

Als Zielfelder werden alle Quellfelder sowie die neu erzeugten Felder festgelegt. Nur

Quellfelder die auch als Zielfelder definiert sind, werden am Ende der Routine neben

den Gruppierungsfeldern weitergegeben.

Die Routine durchläuft jeden Datensatz der Quellfelder. Wenn sich ein Datum im

Feld abrechungsrelevantes Datum befindet, werden in das Zielfeld Jahr die ersten 4

Zeichen des Quellfeldes geschrieben. Diese entsprechen aufgrund der Art der

Speicherung von Datumsfeldern dem jeweiligen Jahr.2

Die anderen Zielfelder werden in Abhängigkeit davon ob die Quellfelder

Ablesebelegnummer, Abrechnungsbelegnummer und Druckbelegnummer Daten

1 Aufgrund der Anzahl der Spalten wurde die Abbildung aufgeteilt

2 Beispielsweise 20080406 für den 06.04.2008


- 80 -

beinhalten, mit 0 oder 1 gefüllt. Gibt es beispielsweise zu einer Anlage einen

Ablesebeleg, erfolgt im Feld Anlage abgelesen der Eintrag 1. Analog verhält es sich

bei den restliche Zielfeldern.

...

*-------------------- Begin of transformation code -------------------------




IF ls_source-ADAT NE SPACE.

ls_target-ZJAHR = ls_source-ADAT(4).

ENDIF.

IF ls_source-ABLBELNR NE SPACE.

ls_target-ANLABG = '1'.

ls_target-ANLNABG = '0'.

ELSE.



ENDIF.

IF ls_source-ZBELENR NE SPACE.

ls_target-ANLABGR = '1'.

ls_target-ANLNABGR = '0'.

ELSE.



ENDIF.

IF ls_source-OPBEL NE SPACE.

ls_target-ANLFAK = '1'.

ls_target-ANLNFAK = '0'.

ELSE.



ENDIF.



ENDLOOP.

*---------------------- End of transformation code -------------------------

...

Listing 2: ABAP Routine Schritt 211

1 Der vollständige Code befindet sich in Abschnitt 6.3, Anhang, auf Seite 93


- 81 -

Schritt 21 – Sortieren nach Anlagen22

Wie in Schritt 16 und 20 findet an dieser Stelle eine Sortierung aufsteigend nach den

Anlagennummern statt.

Schritt 22 – Duplikate entfernen23

An dieser Stelle werden mit Hilfe der Aggregationsfunktion doppelte Einträge, die

durch die verschiedenen Verknüpfungen entstanden sind, entfernt. Dabei werden alle

Felder als Gruppierungsfelder angegeben. So findet keine Aggregation von

Kennzahlen statt, sondern es werden lediglich alle Duplikate aussortiert.

Schritt 23 – Feldzuordnung zum ODS-Objekt24

Letztlich muss noch eine Feldzuordnung vorgenommen werden, die definiert, welche

Felder der Ergebnistabelle des letzten Schrittes auf welche Felder des ODS-Objektes

zugeordnet werden sollen.

Schritt 24 – ODS-Objekt25

Das ODS-Objekt beinhaltet alle Felder der Ergebnismenge aus Schritt 23 in Form

von InfoObjects und nimmt damit alle Ergebnisdaten des Analyseprozesses auf.

4.7 Datenspeicherung

Für die Speicherung der Ergebnisse des Analyseprozesses wird für dieses

Fallbeispiel ein transaktionales ODS-Objekt gewählt. Dieses kann die Daten nicht

nur sehr performant abspeichern, sondern bei Bedarf auch in nachfolgenden

Datenzielen weiter fortschreiben. So wäre es, je nach Fragestellung und Zielsetzung,

auch sinnvoll, die Daten nachträglich in einen InfoCube abzulegen, um so eine

bessere Analyse und Auswertung großer Datenbestände zu ermöglichen.

Im Fallbeispiel wird dieses Vorgehen jedoch nicht weiter betrachtet. Stattdessen wird

ein InfoSet erzeugt, das als einzige Quelle das transaktionale ODS-Objekt

zugewiesen bekommt. Durch dieses Vorgehen ist es möglich, indirekt ein

transaktionales ODS-Objekt als Quelle von Queries zu verwenden.


- 82 -

Abbildung 56: Eigenschaften des transaktionalen ODS-Objekts

4.8 Datenauswertung

Das zugrunde liegende Datenmaterial der Ergebnismenge des APD-Prozesses erlaubt

eine Vielzahl an möglichen Auswertungen und Abfragen. Im Folgenden sollen die

wichtigsten Aspekte anhand zweier Queries beispielhaft erläutert werden.

Abbildung 57: Beispiel-Query 1

In der ersten Query werden alle Kennzahlen (als Spalten) sowie die Merkmale Jahr,

Sparte und Ablesegrund (als Zeilen) definiert. Zusätzlich wird das Jahr auf den Wert

2000 beschränkt.


- 83 -

Das Ergebnis dieser Query ist in der folgenden Abbildung dargestellt:

Abbildung 58: Ergebnis Beispiel-Query 1

Bereits diese sehr spezifische Auswertung erlaubt es, eine Vielzahl an Fragen zu

beantworten, z.B.:

■ Wie viele Ablesebelege wurden im Jahr 2000 abgelesen, abgerechnet, fakturiert?

■ Wie viele Ablesebelege wurden im Jahr 2000 abgelesen, aber nicht abgerechnet?

■ Wie viele Ablesebelege wurden im Jahr 2000 abgelesen, abgerechnet aber nicht

fakturiert?

■ Zu welcher Sparte gehören die Anlagen der Ablesebelege?

■ Welche Ablesegründe gab es für die Ablesebelege?

■ Sind fehlende Abrechnungen für bestimmte Sparten oder bei bestimmten

Ablesegründen besonders auffällig?

■ …

In der folgenden Query sollen alle Anlagen angezeigt werden, die zwar abgerechnet

aber nicht fakturiert worden sind. Eine mögliche Umsetzung dieser Fragestellung ist,

mit Hilfe einer Query, in der folgenden Abbildung dargestellt:

Abbildung 59: Beispiel-Query 2


- 84 -

Einen Ausschnitt der Ergebnisse der Query zeigt die folgende Abbildung:

Abbildung 60: Ergebnis Beispiel-Query 2

Obwohl die Auswertungen bei Bedarf sehr stark auf eine bestimmte Fragestellung

eingeschränkt werden können, ist es oft hilfreich den Gesamtzusammenhang zu

betrachten, um so die Ergebnisse richtig interpretieren zu können. So ist es z.B. nicht

ungewöhnlich, dass eine Anlage, die vor einem Tag abgelesen wurde, nicht schon am

Folgetag fakturiert ist.

In diesem Zusammenhang ist es auch von Bedeutung, wann und zu welchem

Zeitpunkt die Statistik erstellt und aktualisiert wird. Diesen Aspekt gilt es in

Absprache mit den Fachabteilungen zu berücksichtigen und entsprechend

umzusetzen.

4.9 Optimierungen

Bereits im aktuellen Zustand des Analysemodells lassen sich die beteiligten Prozesse

sehr performant durchführen. Dennoch gibt es viele Möglichkeiten einen

Analyseprozess, vor allem mit größeren Datenmengen, weiter zu optimieren. Einen

kurzen Überblick über die Optimierungspotentiale gibt Tabelle 3.

Neben den in der Tabelle genannten technischen Optimierungen gibt es auch

verschiedene fachliche Erweiterungen, die sinnvoll durchgeführt werden könnten. Da

dieses Fallbeispiel jedoch in erster Linie zur Darstellung der Möglichkeiten und

Einsatzgebiete des APD dient, wird auf eine detaillierte Betrachtung an dieser Stelle

verzichtet.


- 85 -

Optimierung Beschreibung

InfoSets für Verknüpfungen verwenden

Verknüpfungen von verschiedenen Objekten können innerhalb des BW mit Hilfe von InfoSets schneller durchgeführt werden als dies im APD möglich ist. So könnten in der Fallstudie z.B. die zeitabhängigen Daten mit den zeitunabhängigen Daten der Anlage schon im Vorfeld durch ein Infoset verknüpft werden. Das InfoSet wird anschließend als eine Quelle des APD-Prozesses verwendet.

Für Verknüpfungen, die im späteren Verlauf des Analyseprozesses vollzogen werden sollen, können jedoch keine InfoSets verwendet werden.

Spalten umbennen

Ab der Version 3.5 des Business Warehouse gibt es die Möglichkeit mit Hilfe einer Transformation die Spalten der Ergebnismenge umzubennen. Diese Funktion kann sinnvoll genutzt werden, um ähnlich klingende oder schlecht bezeichnete Felder verständlicher zu machen.

Nur benötigte Daten aus dem Quellsystem laden

Indem zuvor klare Anforderungen definiert werden, können die zu extrahierenden Daten auf das benötigte Minimum beschränkt werden. Dies führt zu einer deutlichen Verbesserung des Ladevorganges, erschwert auf der anderen Seite jedoch die Erweiterbarkeit des Modells.

Filtern der Daten auf Quellsystem-ebene

Viele der in der Fallstudie verwendeten Filtertransformationen können schon auf Ebene des Quellsystems beim Extraktionsvorgang durchgeführt werden. Dies optimiert nicht nur den Ladevorgang der Daten in das BW, sondern auch den APD-Prozess selbst, indem die Filtertransformationen nicht mehr benötigt werden. Jedoch wird der gesamte APD-Prozess dadurch weniger transparent.

Sortierungen löschen

Wie bereits erwähnt, werden die Sortierungen lediglich für die Auswertung von Zwischenergebnissen verwendet. Für den eigentlichen Prozess sind sie irrelevant und sollten, nach der Validierung der Ergebnisse, entfernt werden.

Duplikate entfernen

Das Entfernen von Duplikaten sollte im Idealfall an der Stelle geschehen, an der sie entstehen. So werden die Duplikate nicht unnötigerweise durch alle weiteren Transformationen getragen.

Prozessketten verwenden

Mit Hilfe der Prozessketten können die gesamten Abläufe für einen Analyseprozess automatisiert werden. Sie sind von besonderer Bedeutung, wenn Aktualisierungen regelmäßig stattfinden sollen.

Probleme bei zeitlichen Übergängen

Werden Anlagen beispielsweise am 31.12.2007 abgelesen, jedoch erst am 01.01.2008 abgerechnet, sind die Ergebnisse bei einer Aggregation auf Jahresebene fehlerhaft, da für das Jahr 2007 die Anlage als nicht abgerechnet angezeigt wird. Dieses Problem lässt sich nur über eine Umstellung des gesamten Analyseprozesses oder mittels einer weiteren ABAP-Routine beheben.

Felder in Query berechnen

Die Felder Anlage nicht abgelesen, Anlage nicht abgerechnet, Anlage nicht fakturiert können auch mittels selbst definierter Kennzahlen in der Query mit Daten gefüllt werden. Dadurch wird der Analyseprozess und insbesondere die ressourcenintensive ABAP-Routine innerhalb des Prozesses weiter entlastet.

Texte hinterlegen

Um Merkmale nicht über Nummern interpretieren zu müssen, können zum Zweck der Auswertung Texte zu den jeweiligen Ausprägungen hinzugefügt werden (z.B. Sparte: 10 - „Strom“)

InfoCube für die Auswertung verwenden

Um Auswertungen, insbesondere bei großen Datenmengen schneller durchführen zu können, empfiehlt sich das Fortschreiben der Daten aus den transaktionalen ODS-Objekt in einen InfoCube. Dieser ist für das Lesen der Daten optimiert und erlaubt so eine performante Durchführung der Queries.

Aggregationen der Zeit-einheiten im InfoCube

Zusätzlich bietet der InfoCube bessere Möglichkeiten über Zeiteinheiten zu aggregieren. So werden innerhalb eines InfoCubes lediglich mit Hilfe einer einzelnen Zeitangabe (z.B. 13.12.2007) alle anderen Zeitmerkmale wie Kalenderwoche, Jahr, Geschäftsjahr etc. berechnet. Dadurch könnte in dem Fallbeispiel die Berechnung des Jahres mit Hilfe der ABAP-Routine entfallen.

Tabelle 3: Optimierungen des Analyseprozesses

5 Abschluss

- 86 -

5 Abschluss

5.1 Zusammenfassung

Einleitend in diese Projektarbeit wurde der ETL-Prozess der Datenbeschaffung im

SAP Business Warehouse beschrieben. Dazu war es notwendig, zunächst die Objekte

des BW, deren Zusammenspiel und Verbindung sowie den gesamten Datenfluss von

einem SAP Quellsystem in das Business Warehouse zu betrachten. Neben der

Beschreibung des Business Content wurde der gesamte ETL-Prozess für Stammdaten

im SAP BW 3.x mit all seinen Fortschreibungs- und Verbuchungsarten sowie dem

Delta-Verfahren erläutert. Zusätzlich wurden die wesentlichen Änderungen im

Objektkonzept und Datenfluss im SAP BW 7.0 kurz dargestellt.

Anschließend wurde die Funktionsweise des Analyse-Prozess-Designers

beschrieben, wie dieser in das SAP BW eingebunden ist, welche Phasen ein

Analyseprozess umfasst und welche wesentlichen Unterschiede in den verschiedenen

Versionen des APD zu finden sind. Zusätzlich wurden die Möglichkeiten des APD

von denen des BW abgegrenzt und die möglichen Auswirkungen auf den ETL-

Prozess dargestellt.

Im Fallbeispiel wurden zunächst die wichtigen branchenspezifischen

Begrifflichkeiten erläutert, die zum Verständnis des Beispiel-Analyseprozesses

notwendig sind. Anschließend wurden die benötigten Daten identifiziert, ausgewählt

und beschafft. Die detaillierte Beschreibung des gesamten Analyseprozesses in all

seinen Schritten war Bestandteil des nachfolgenden Abschnittes. Nach der

beispielhaften Auswertung und Analyse wurden abschließend noch mögliche

Optimierungspotentiale aufgezeigt, die zu einer verbesserten Performance des

gesamten Prozesses führen sollen.

Insgesamt konnte so ein Überblick über die Funktionen und Einsatzgebiete des

Analyse-Prozess-Designers geschaffen werden, der als Grundlage weiterer Arbeiten

sowie der anschließenden Diplomarbeit dienen kann.

5.2 Fazit

Der Analyse-Prozess-Designer ist die konsequente Weiterentwicklung des Business

Warehouse, um komplexe Modellierungs- und Analyseprozesse einfach,

übersichtlich, transparent und modular entwerfen zu können. Er ermöglicht die

Filterung, Verknüpfung und Transformation von Daten, die ggf. bereits im Business

5 Abschluss

- 87 -

Warehouse konsolidiert wurden, um so neue Informationen zu schaffen, die für ein

Unternehmen von besonderer Bedeutung sein können.

Vor allem im Hinblick auf das Data Mining ist der APD das entscheidende Tool, um

die Daten für die verschiedenen Verfahren und Techniken der statistisch-

mathematischen Berechnungen vorzubereiten. Aber auch ohne die Verwendung der

Data Mining Techniken erlaubt es der Analyse-Prozess-Designer komplexe

Datenmodellierungen durchzuführen, die im SAP BW gar nicht oder nur mit einem

deutlichen Mehraufwand möglich sind.

Dennoch gestattet das BW eine deutlich performantere Durchführung, zumindest der

grundlegenden Transformationen, so dass immer ein Kompromiss zwischen

Flexibilität und Transparenz auf der einen Seite, und Effizienz und Performanz auf

der anderen Seite geschaffen werden muss.

Mit Hilfe des APD kann der eigentliche ETL-Prozess des Business Warehouses

erweitert werden. Haben die Daten im BW bereits einen ETL-Prozess durchlaufen,

schließt sich durch das Extrahieren, Transformieren und Laden der Daten im APD

ein weiterer ETL-Prozess an. Oftmals sind die Daten die im APD verwendet werden

jedoch nicht von ausreichender Qualität, so dass sie, insbesondere in Bezug auf das

Data Mining, zunächst konsolidiert und bereinigt werden müssen.

Im Gegensatz zum BW erlaubt der APD eine nahezu unendliche Kette von

Transformationen, deren Umsetzung im SAP BW kaum möglich ist. Auch die

Auswahl von Daten, die sich bereits im BW befinden sowie deren Verwendung in

verschiedenen Prozessen als Quelle (z.B. mittels Queries) ist im Business Warehouse

so nicht möglich.

Sicherlich hätte das Fallbeispiel auch komplett mit Mitteln des Business Warehouse

umgesetzt werden können, jedoch ist der Mehraufwand bei derart komplexen

Prozessen um ein Vielfaches höher und deutlich schwieriger umzusetzen. Mit der

deutlich übersichtlicheren Darstellung lassen sich zudem die Analyseprozesse

wesentlich einfacher erweitern, ohne dass der gesamte Datenfluss geändert werden

muss. Komplizierte Transformationen lassen sich darüber hinaus im BW nur mittels

ABAP-Code realisieren, während im APD diese Funktionen einfach durch

Drag&Drop verwendet werden können. Dieses Vorgehen führt selbst bei einfacheren

Umwandlungen zu einer deutlichen Zeit- und damit Kostenersparnis.

5.3 Ausblick

Die vorliegende Projektarbeit kann in vielfacher Weise als Basis anderer Arbeiten

betrachtet oder in weiteren Projekten erweitert werden.

So wäre es beispielsweise möglich, die Ergebnisse der Fallstudie mit der

Verkaufsstatistik zu verknüpfen. Über die Angabe der Anlagen die ggf. nicht

abgelesen, nicht abgerechnet oder nicht fakturiert wurden, könnten in Kombination

mit den Verbräuchen der Vorjahre sowie den Daten aus der Verkaufsstatistik,

Aussagen darüber getroffen werden, wie viel Umsatz dem Unternehmen entgangen

5 Abschluss

- 88 -

ist. Neben diesen komplexen Verknüpfungen und Transformationen von Daten für

spezifische Auswertungen, gibt es eine Reihe weiterer Einsatzgebiete für den APD.

In der Praxis werden durch fortlaufende Erweiterungen der Analysemöglichkeiten

die Extraktstrukturen im Quellsystem immer umfangreicher und die InfoCubes im

Business Warehouse immer unperformanter. Mittelfristig ist dies ein grundlegendes

Problem, welches durch die Umstellung auf den APD behoben werden kann. So

können Analyseprozesse helfen, die Performanz der Datenbeschaffung sowie der

Auswertung zu erhöhen. Beispielsweise können zusätzliche Stammdaten, die nicht

regelmäßig aktualisiert werden müssen, erst in einem APD-Prozess den jeweiligen

Merkmalen zugeordnet werden. Bisher ist dies nur über eine Erweiterung des

Extraktors im Quellsystem möglich. Um jedoch die Stammdaten nicht bei jedem

Extraktionsvorgang redundant mit übertragen zu müssen, werden diese individuell in

einem Analyseprozess zu einer Abfrage hinzugefügt. Zusätzlich sind durch diese

Vorgehensweise die Faktentabellen der InfoCubes weniger umfangreich, was zu

deutlichen Performancesteigerungen bei der Auswertung führt. Darüber hinaus

können die InfoCubes weiter entlastet werden, indem Queries als Quelle eines

Analyseprozesses verwendet werden. Diese können mit anderen Daten (z.B.

Stammdaten) verknüpft und anschließend in separate Datenziele gespeichert werden.

Somit erfolgt die Auswertung auf diese Datenziele und nicht wie zuvor auf die

ausgelasteten InfoCubes. Dadurch werden die Informationen, die sich in den

InfoCubes befinden, auf Teilfragen und spezifische, rollenabhängige Auswertungen

beschränkt, indem jeder nur auf die Daten zugreift, die er für seine Analysen und

sein Reporting benötigt.

Viele weitere Kombinationen von Daten aus verschiedenen Systemen sind mit Hilfe

dieser Projektarbeit sowie den darin enthaltenen Erläuterungen zu den Funktionen

des APD möglich.

Einer der wesentlichen Gründe für die Entwicklung des Analyse-Prozess-Designers

ist jedoch das Data Mining, welches in dieser Arbeit nicht weiter betrachtet wurde,

jedoch Bestandteil der nachfolgenden Diplomarbeit sein soll. Der APD ist, vor allem

in seiner aktuellen Version, sehr eng mit den Techniken des Data Mining verbunden

und erlaubt es, verschiedene Data Mining Verfahren innerhalb eines

Analyseprozesses zu verwenden, um so weitere, nicht triviale Informationen zu

entdecken, die durch einfaches Betrachten von Daten nicht ersichtlich sind, jedoch

für ein Unternehmen von besonders hoher Bedeutung sein können.

So kann das Data Mining z.B. auf Analysen der Verkaufsstatistik in Kombination

mit weiteren Stammdaten durchgeführt werden. Dadurch können beispielsweise die

wichtigen Kunden eines Unternehmens herausgefunden oder Kundengruppen auf

verschiedene Weisen identifiziert und analysiert werden. Es kann auch berechnet

werden, wie wahrscheinlich es ist, dass ein Kunde mittelfristig kündigt und zu einem

Mitbewerber wechselt. Solche Aussagen sind im Rahmen der Öffnung des

Energiemarktes von immer größerer Bedeutung und ermöglichen beispielsweise

gezielte Marketingaktionen. Die genannten Beispiele sind jedoch nur ein kleiner Teil

möglicher Auswertungen, die mit Hilfe des Data Mining realisiert werden können.

5 Abschluss

- 89 -

Mit dieser Projektarbeit wurde ein grundlegendes Verständnis für die Funktionsweise

und Verwendung des Analyse-Prozess-Designers geschaffen. Darauf aufbauend

sollen in der nachfolgenden Diplomarbeit die Möglichkeiten erläutert werden, die

das SAP Business Warehouse in Bezug auf das Data Mining zur Verfügung stellt.

Dabei steht neben der Erläuterung der verschiedenen Verfahren vor allem die praxis-

und branchenbezogene Umsetzung von Analyse-Prozessen mit den Techniken des

Data Mining im Vordergrund. Getreu dem Motto:

»We are drowning in information, but starving for knowledge«1

1 Vgl. [Naisbitt, 1984]

6 Anhang

- 90 -

6 Anhang

6.1 Anlagen-Analyse-Prozess

6 Anhang

- 91 -

6.2 A selection of useful ISU-Tables

Vgl. [Lapa, 2008]

6 Anhang

- 92 -

6.3 ABAP-Routine des Analyseprozesses

REPORT RSAN_WB_ROUTINE_TEMP_REPORT .

TYPES: BEGIN OF y_group_fields ,

ABLEINH TYPE /BIC/OIABLEINH ,

ABLESGR TYPE /BIC/OIABLESGR ,

SPARTE TYPE /BIC/OISPARTE ,

ANLAGE TYPE /BIC/OIANLAGE ,

END OF y_group_fields .

TYPES: BEGIN OF y_source_fields ,

ZBELENR TYPE /BIC/OIZBELENR ,

ABLBELNR TYPE /BIC/OIABLBELNR ,

OPBEL TYPE /BIC/OIOPBEL ,

ADAT TYPE /BIC/OIADAT ,

END OF y_source_fields .

TYPES: yt_source_fields TYPE STANDARD TABLE OF y_source_fields .

TYPES: BEGIN OF y_target_fields ,

ADAT TYPE /BIC/OIADAT ,

ZJAHR TYPE /BIC/OIZJAHR ,

ABLBELNR TYPE /BIC/OIABLBELNR ,

ZBELENR TYPE /BIC/OIZBELENR ,

OPBEL TYPE /BIC/OIOPBEL ,

ANLABG TYPE /BIC/OIANLABG ,

ANLNABG TYPE /BIC/OIANLNABG ,

ANLABGR TYPE /BIC/OIANLABGR ,

ANLNABGR TYPE /BIC/OIANLNABGR ,

ANLFAK TYPE /BIC/OIANLFAK ,

ANLNFAK TYPE /BIC/OIANLNFAK ,

END OF y_target_fields .

TYPES: yt_target_fields TYPE STANDARD TABLE OF y_target_fields .

*---------- Begin of type definitions -------------------------------

*TYPES: ...

*----------- End of type definitions --------------------------------

FORM compute_data_transformation

USING is_group TYPE y_group_fields

it_source TYPE yt_source_fields

EXPORTING et_target TYPE yt_target_fields .

*--------- Begin of transformation code -----------------------------



6 Anhang

- 93 -


IF ls_source-ADAT NE SPACE.

ls_target-ZJAHR = ls_source-ADAT(4).

ENDIF.

IF ls_source-ABLBELNR NE SPACE.



ELSE.



ENDIF.

IF ls_source-ZBELENR NE SPACE.



ELSE.



ENDIF.

IF ls_source-OPBEL NE SPACE.



ELSE.



ENDIF.



ENDLOOP.

*---------- End of transformation code ------------------------------

ENDFORM.

7 Abkürzungsverzeichnis

- 94 -

7 Abkürzungsverzeichnis

ABAP Advanced Business Application Programming

ALE Application Link Enabling

APD Analyse-Prozess-Designer

ASCII American Standard Code for Information Interchange

DTP Datentranfserprozess

BW Business Warehouse

CCS Customer Care Service

CIC Customer Interaction Center

CRM Customer Relationship Management

CSV Comma Seperated Value

DSO Data Store Objekt

EDM Energy Data Management

EnWG Energiewirtschaftsgesetz

ERP Enterprise Ressource Planning

ETL Extraktion, Transformation und Laden

GUI Graphical User Interface

IDOC Intermediate Document

IS-U Industry Solution for Utilities

ODBO OLE DB for OLAP

ODS Operational Data Store

SAP Software Anwendungen und Programme

8 Abbildungsverzeichnis

- 95 -


Abbildung 1: Der ETL-Prozess .................................................................. 12

Abbildung 2: Verwendung von InfoObjects im SAP BW .......................... 15

Abbildung 3: erweitertes Sternschema im SAP BW .................................. 19

Abbildung 4: Beispiel – Datenfluss im SAP BW ....................................... 22

Abbildung 5: Übertragungsregeln .............................................................. 23

Abbildung 6: Fortschreibungsregeln .......................................................... 25

Abbildung 7: Direkte Fortschreibung ......................................................... 26

Abbildung 8: Flexible Fortschreibung ........................................................ 27

Abbildung 9: Datenfluss im SAP BW 7.0 .................................................. 32

Abbildung 10: Zentrale Funktionen des APD ............................................ 33

Abbildung 11: Schritte im Analyse-Prozess-Designer ............................... 35

Abbildung 12: Beispiel – Datenmenge einschränken ................................. 38

Abbildung 13: Beispiel 1 – Daten aggregieren ........................................... 39

Abbildung 14: Beispiel 2 – Daten aggregieren ........................................... 40

Abbildung 15: Beispiel – Daten zweier Quellen miteinander verknüpfen . 40

Abbildung 16: Beispiel – Daten aus zwei Datenquellen vereinigen .......... 41

Abbildung 17: Beispiel – Daten sortieren .................................................. 42

Abbildung 18: Beispiel – Liste in Datensatz transformieren ...................... 42

Abbildung 19: Beispiel – Datensatz in Liste transformieren ...................... 43

Abbildung 20: Standardanwendungen von SAP ........................................ 46

Abbildung 21: APD-GUI ............................................................................ 47

Abbildung 22: Dekoration, Konnektor, Datenflusspfeil ............................. 48

Abbildung 23: Beispiel eines Analyseprozesses ........................................ 51

Abbildung 24: Integrationsmodell des ISU ................................................ 55

Abbildung 25: IS-U Haus ........................................................................... 56

Abbildung 26: Ablauf der Vertragsabrechnung (vereinfacht) .................... 57


- 96 -

Abbildung 27: Ablauf der Vertragsabrechnung ......................................... 58

Abbildung 28: Grobkonzept der Umsetzung der Fallstudie ....................... 60

Abbildung 29: Beispiel Datenfluss der Umsetzung .................................... 65

Abbildung 30: Ablauf des Analyseprozesses ............................................. 67

Abbildung 31: Anlagen-Analyse-Prozess ................................................... 68

Abbildung 32: Zwischenergebnis Schritt 1 ................................................ 69



Abbildung 35: Verknüpfung in Schritt 3 .................................................... 70





Abbildung 40: Verknüpfung Schritt 9 ........................................................ 72


Abbildung 42: Verknüpfung Schritt 10 ...................................................... 73

Abbildung 43: Zwischenergebnis Schritt 10 .............................................. 74


Abbildung 45: Zwischenergebnis Schritt 12 ............................................... 74











Abbildung 56: Eigenschaften des transaktionalen ODS-Objekts ............... 82

Abbildung 57: Beispiel-Query 1 ................................................................. 82

Abbildung 58: Ergebnis Beispiel-Query 1 ................................................. 83


- 97 -

Abbildung 59: Beispiel-Query 2 ................................................................. 83

Abbildung 60: Ergebnis Beispiel-Query 2 ................................................. 84

9 Tabellenverzeichnis

- 98 -

9 Tabellenverzeichnis

Tabelle 1: Verbuchungsarten ...................................................................... 28

Tabelle 2: Unterschiede zwischen den Versionen des APD ....................... 52

Tabelle 3: Optimierungen des Analyseprozesses ........................................ 85

10 Listingverzeichnis

- 99 -

10 Listingverzeichnis

Listing 1: Beispiel – ABAP-Routine ........................................................... 44

Listing 2: ABAP Routine Schritt 21 ........................................................... 80

11 Quellenverzeichnis

- 100 -


Literatur

[Egger et al., 2005]

N. Egger, J.R. Fiechter, R. Salzmann, R.P. Sawicki, T. Thielen;

SAP BW Datenbeschaffung;

Galileo Press; Bonn 2005; 1. Auflage; ISBN 3-89842-536-3

[FuFu; 2003]

B. Fu, H. Fu;

SAP BW – A Step-by-Step Guide;

Addinson-Wesley; 2003; ISBN 0-201-70366-1

[Gómez et al., 2006]

J.M. Gómez, C. Rautenstrauch, P. Cissek, B. Grahlher;

Einführung in SAP Business Information Warehouse;

Springer Verlag; Heidelberg 2006, ISBN 978-3-540-31124-9

[KeJa, 2002]

H. Keller, J. Jacobitz;

ABAP Objects Referenz;

Galileo Press; Bonn 2002; 1 .Auflage; ISBN 3-934358-61-6

[KeKr, 2001]

H. Keller, S. Krüger;

ABAP Objects – Einführung in die SAP-Programmierung;


[Kemper et al.,2006]

H. Kemper, W. Mehanna, C. Unger;

Business Intelligence – Grundlagen und praktische Anwendungen;

Friedr. Vieweg & Sohn Verlag / GWV Fachverlage GmbH; Wiesbaden 2006; 2. Auflage;

ISBN 978-3-8348-0275-0

[KiVa, 2007]

M. Kießwetter, D. Vahlkamp;

Data Mining in SAP Netweaver BI;

Galileo Press; 1. Auflage; Bonn 2007; ISBN 978-3-89842-850-7

[Mehrwald, 2007]

C. Mehrwald;

Datawarehousing mit SPA BW 7 – BI in SAP Netweaver 2004s;

dpunkt.verlag GmbH; Heidelberg 2007; 4. Auflage; ISBN 978-3-89864-460-0

[Naisbitt, 1984]

J. Naisbitt;

Megatrends - Ten New Directions Transforming Our Lives

Warner Books, 1984; ISBN 978-0-44690-991-4


- 101 -

[Seemann et al., 2001]

A. Seemann, B. Schmalzridt, P. Lehmann;

SAP Business Information Warehouse;


SAP-Unterlagen

[BW310, 2005]

BW310; Data Warehousing; SAP Schulungsunterlagen Teilnehmerhandbuch

Version 2005/Q1; Materialnummer: 50071081; SAP AG

[BW330, 2005]

BW330; Business Information Warehouse – Modellierung


[BW350, 2005]

BW350; SAP BW – Datenxtraktion; SAP Schulungsunterlagen Teilnehmerhandbuch


[BW380, 2005]

BW380; SAP Business Intelligence - Analyseprozesse und Data Mining;

SAP Schulungsunterlagen Teilnehmerhandbuch Version 2005/Q1;

Materialnummer: 50072606; SAP AG

[BWFunctions, 2003]

SAP Business Information Warehouse – Functions in Detail

Version 2.0; SAP AG 2003

[IUT110, 2005]

IUT100; EInführung in das System ISU/CCS

SAP IS-Utilities/Customer Care Service 471; Version 2005/Q1;

Materialnummer: 50071399

Online-Quellen

[EVU-IT, 2008]

evu.it Website: Unternehmen

http://www.evu-it.de/front_content.php?idcat=31 (30.03.2008, 07:55)

[Lapa, 2008]

Marcin Lapa; Utility and SAP Consultant; http://marcinlapa.com (11.04.2008, 15:17)

[SAPBib3x, 2008]

SAP-Bibliothek: SAP Business Information Warehouse

http://help.sap.com/saphelp_nw04/helpdata/de/49/7e960481916448b20134d471d36a6b/fr

ameset.htm (31.03.2008, 11:52)

[SAPBib3xDelta7]

SAP-Bibliothek: Enterprise Data Warehousing (Neuerungen im SAP BW 7)

http://help.sap.com/saphelp_nw2004s/helpdata/de/31/ec1342eb11de2ce10000000a1550

b0/frameset.htm (09.04.2008, 10:30)

[SAPBib7, 2008]

SAP-Bibliothek: SAP Netweaver 7.0 (2004s)

http://help.sap.com/saphelp_nw70/helpdata/DE/45/dc799c25c15592e10000000a1553f7/fr

ameset.htm (09.04.2008, 10:25)


- 102 -

[SAPBibBI, 2008]

SAP-Bibliohtek: BI Plattform

http://help.sap.com/saphelp_nw70/helpdata/DE/49/7e960481916448b20134d471d36a6b/f

rameset.htm (01.04.2008, 12:55)

[SAPBibUtil, 2008]

Sap-Bibliothek: SAP Utilities

http://help.sap.com/saphelp_utilities472/helpdata/de/c6/4dce68eafc11d18a030000e829fb

bd/frameset.htm (10.04.2008, 10:00)

12 Glossar

- 103 -

12 Glossar

Hier finden Sie kurze Erläuterungen zu den wichtigsten Fachbegriffen. Die Begriffe

sind alphabetisch aufsteigend geordnet. Das Zeichen weist auf einen ebenfalls im

Glossar aufgeführten Begriff hin.

ABAP

Die Advanced Business Application Programming (ABAP) ist eine von SAP

entwickelte Programmiersprache für die Entwicklung im SAP Umfeld.

ABAP Objects

ABAP Objects ist eine Erweiterung von ABAP um die Elemente der

objektorientierten Programmierung (außer Mehrfachvererbung und Überladen von

Methoden).

Administrator Workbench

Die Administrator Workbench ist das zentrale Element innerhalb des SAP

Business Warehouse zur Modellierung von Data-Warehousing-Prozessen. Mit

ihr können alle Prozesse der Datenbeschaffung, -haltung und –verarbeitung

gesteuert, überwacht und gepflegt werden.

ALE

Application Link Enabling erlaubt die Kommunikation mittels kontrolliertem

Nachrichtenaustausch zwischen verteilten (SAP-)Anwendungssystemen.

APD Workbench

Die APD Workbench ist die grafische Benutzeroberfläche des Analyse-Prozess-

Designers und stellt dem Anwender die Funktionalitäten zur Modellierung und

Durchführung analytischer Prozesse zur Verfügung.

Ausnahmeaggregation

Mit Hilfe eines weiteren Bezugsmerkmals wird bei einer Aggregation der zu

verwendende Wert festgelegt. Beispielsweise kann die Bestandsgröße „Anlagen“

über das Merkmal „Sparte“ aggregiert werden. Falsch wäre dagegen eine

Aggregation über verschiedene Zeiträume, denn dann würden mehr Anlagen

ermittelt als vorhanden sind. So kann z.B. die Angabe „letzter Wert“ bezogen auf

die Größe „Kalendermonat“ bewirken, dass immer der letzte Wert verwendet

wird. Weitere Ausnahmeaggregationen sind u.a. „Min“, „Max“ oder

„Durchschnitt“.

12 Glossar

- 104 -

Customizing

Beim Customizing werden die vorgegebenen oder bereits definierten Objekte des

Business Warehouse an die spezifischen Bedürfnisse und Anforderungen des

Kunden angepasst.

DataMart

Data Marts werden als Datenziele definiert, die in weitere Datenziele

fortgeschrieben werden können. Sie sind somit kleine Einheiten des Data

Warehouse, die den Austausch zwischen einem oder mehreren BW-Systemen

ermöglichen.

Data Mining

Mit Hilfe des Data Mining sollen neue, nicht triviale Informationen mit Hilfe von

mathematisch-statistischen Verfahren ermittelt werden. D.h., es wird automatisiert

nach Mustern in den vorhandenen Daten gesucht, um so die operativen, taktischen

oder strategischen Entscheidungen in einem Unternehmen unterstützen zu

können.

Data Warehouse

Ein Data Warehouse ist das konsolidierte Datenlager eines Unternehmens, das

sich aus vielen verschiedenen Quellen zusammensetzen kann. Die Daten im Data

Warehouse werden in erster Linie für analytische Auswertungen genutzt.

Drag&Drop

Durch Betätigen der linken Maustaste lassen sich grafische Objekte „Ziehen und

Fallenlassen“. Das Drag&Drop-Verfahren stellt somit eine Art der Bedienung von

grafischen Benutzeroberflächen dar.

ERP-System

Enterprise Resource Planing Systeme unterstützen das Unternehmen mit Hilfe

komplexer Anwendungssoftware bei der Ressourcenplanung und –verteilung.

Exclude-Selektionsbedingung

Die Exclude-Selektionsbedingung stellt das Gegenstück zur normalen

Selektionsbedingung dar. Dabei werden alle Daten selektiert, die nicht der

Bedingung entsprechen.

Granularität

Die Granularität beschreibt den Feinheitsgrad von Daten im Data Warehouse.

Eine hohe Granularität führt zu einer großen Datenmenge, da auch Details

beschrieben werden. Eine niedrige Granularität abstrahiert dagegen gewisse

Eigenschaften der Daten.

IDOC

Das Intermediate Document stellt eine Art Container dar, der für den

Datenaustausch zwischen den verschiedenen SAP-Systemen oder einem

Fremdsystem genutzt wird.

12 Glossar

- 105 -

InfoProvider

Ein InfoProvider ist ein Sammelbegriff für diejenigen Datenziele, auf deren

Datenbestand Analysen und Queries durchgeführt werden können und die als

Quelle für weitere Prozesse zur Verfügung stehen.

Inner Join

Diese Art von Join fügt nur die Datensätze aus zwei Tabellen zusammen, die den

angegebenen Kriterien entsprechen. Alle anderen Datensätze erzeugen keinen

Eintrag in der Ergebnismenge.

IS-U

Die Branchenkomponente Versorgungsindustrie dient innerhalb von SAP Utilities

der Verwaltung und Abrechnung von Kunden.

Left Outer Join

Der Left-Outer-Join unterscheidet zwischen linker und rechter Tabelle. Alle

Datensätze der linken Tabelle werden mit Ergänzung der Daten aus der rechten

Tabelle in die Ergebnismenge eingefügt. Existiert zu einem Datensatz der linken

Tabelle kein passender Eintrag in der rechten Tabelle, bleiben die Felder der

Ergebnismenge in Bezug auf die rechte Tabelle leer.

Metadata Repository

Das Metadata Repository verwaltet und bietet den zentralen Zugriff auf alle

Metadaten (Eigenschaften und Verknüpfungen von Objekten) im SAP

Business Warehouse.

Metadaten

Als Metadaten werden Daten bezeichnet, die Informationen über Daten beinhalten

und so z.B. die Eigenschaften von Daten beschreiben.

Prozessketten

Mit Hilfe von Prozessketten können Abläufe automatisiert werden. So wird die

Prozesskette nach Eintreten eines definierten Ergebnisses gestartet und löst

verschiedene aufeinander folgende Prozesse aus, die im Business Warehouse

durchgeführt werden sollen.

Query

Als Query bezeichnet man eine Abfrage, die auf einem InfoProvider

durchgeführt wird, um Analysen durchzuführen oder Berichte zu erzeugen.

Replikation

Mit Hilfe der Replikation werden DataSources aus einem Quellsystem im

Business Warehouse bekannt gemacht. Durch diesen Vorgang ist es möglich,

Daten aus einem Quellsystem in das BW zu übertragen.

SAP

Die SAP AG ist einer der weltweit größten Softwarehersteller der Welt. Ihre

Produkte richten sich in erste Linie an mittelständische oder große Kunden und

decken alle Geschäftsprozesse eines Unternehmens ab.

12 Glossar

- 106 -

Transportanschluss

Mit Hilfe des Transportanschlusses können komplette Strukturen von einem

System in ein anderes übertragen werden (z.B. von einem Test- und in

Produktivsystem).

Versionierung

Das Versionierungssystem von SAP erlaubt die Unterscheidung u.a. zwischen

aktiven, modifizierten und inaktiven Versionen von Objekten und Bestandteilen

des SAP-Systems. Dadurch ist es zum Beispiel möglich, Objekte zu verändern

und zu speichern, ohne dass das System durch die Änderungen beeinflusst wird.

Vertragskontokorrent

Das Vertragskontokorrent stellt eine Art Nebenbuchaltung dar, um die Vielzahl an

Buchungen eines Energieversorgungsunternehmens zu sammeln und gemeinsam

fakturieren zu können.

13 Eidesstattliche Erklärung

- 107 -

13 Eidesstattliche Erklärung

Gemäß § 26 (1) der DPO erkläre ich an Eides statt, dass ich die vorliegende Arbeit

selbständig angefertigt habe. Ich habe mich keiner fremden Hilfe bedient und keine

anderen, als die angegebenen Quellen und Hilfsmittel benutzt. Alle Stellen, die

wörtlich oder sinngemäß veröffentlichten oder nicht veröffentlichten Schriften und

anderen Quellen entnommen sind, habe ich als solche kenntlich gemacht. Diese

Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.

Dortmund, den 15.03.2009 ______________________________

(Dennis Halboth)

14 Stichwortverzeichnis

- 108 -


- A -

ABAP Routine 47

Abbildungsverzeichnis 103

Abgrenzung 9

Abkürzungsverzeichnis 102

Ablesebeleg 67, 77

Ablesegrund 68, 77

Ablesung 62

Abrechnung 59, 63

Abrechnungsbeleg 68, 80

Abrechnungsbelegzeilen 69, 81

Abschluss 94

Abstract 5

Aggregationsfelder 43

ALE-Änderungszeiger 31

Analyseprozess 72 Grundlegender Ablauf 72

Analyse-Prozess-Designer 36

Änderungen im BW 7.0 32

Anlage 62

Anlagen-Analyse 58

Anschlussobjekt 61

Anwendungen 50

Anwendungstyp 53

APD Abgrenzung zum BW 54 Auswirkungen auf den ETL-Prozess 55 Funktionsweise 51 Unterschiede der Versionen 56 Versteckte Funktionen 53

ASCII 40

Attribute 15

Attribute eines Merkmals ändern 49

Attribute eines Merkmals lesen 39

Ausblick 95

- B -

Business Content 22

- C -

CRM-Attribute aktualisieren 49

CSV 40

- D -

DataSource 18, 33

Daten aggregieren 42

Daten anzeigen lassen 52

Daten aus Datei lesen 40

Daten aus Datenbanktabelle lesen 40

Daten aus InfoProvider lesen 39

Daten aus zwei Quellen miteinander verknüpfen 43

Daten aus zwei Quellen vereinigen 44

Daten in Datei schreiben 49

Daten sortieren 45

Daten über Query lesen 40

Datenauswahl 67

Datenflusspfeile 52

Datenmenge einschränken 41

Datenquellen 38

Datensatz in Liste transformieren 46

Datentransferprozess 34

Datenziele 48

Delta-Update 31

Delta-Verfahren 30

Direkte Fortschreibung 27

Druckbelege 69

- E -

Early-Delta-Initialisierung 32

EE1 11

Eingesetzte Software 10

Einheit 18

Einleitung 8

Elementare Statistik anzeigen 53

Energiewirtschaftsgesetz 8

Energy Data Management 59

ETL-Prozess 12, 55 Phasen 12

ETL-Prozess im SAP BW 3.x 23

evu.it GmbH Geschäftsbereiche 9


- 109 -

evu.it GmbH 8

Exclude-Selektionsbedingung 41

Extraktion 13

Extraktstruktur 19

- F -

Fakturierung 59, 63

Fakturierungsbeleg 69

Fallbeispiel 58 Datenauswertung 89 Datenbeschaffung 70 Datenspeicherung 88 Konzept 66 Optimierungen 91 Zielsetzung 65

Fazit 94

Flexible Fortschreibung 28

Formel 45

Formeleditor 45

Fortschreibungsregeln 26

Full-Update 31

- G -

Generische DataSource 70

Geräteplatz 62

Geräteverwaltung 59

Geschäftspartner 61

Glossar 111

Grundfunktionen 59

- H -

Hierarchien 16

Histogramme 53

- I -

IDE 59

IDOC 19

InfoCube 20

InfoObject 16

InfoPackage 22, 34

InfoSet 21

InfoSource 19, 34

Inhaltsverzeichnis 6

Initialisierung des Delta-Verfahrens 31

Integration des APD in das SAP BW 37

IS-U Haus 60

- K -

Kennzahl 17

Knoten 51

Konnektoren 52

Kundenservice 59

Kurzfassung 4

- L -

Laden 15

Liste in Datensatz transformieren 46

- M -

Markenrechtlicher Hinweis 3

Merkmal 17

Metadata Repository 13

Metadaten 13

Modellbeschreibung 73

MultiProvider 22

- O -

Objektkonzept im SAP BW 3.x 16

ODBO 40

ODS/DSO-Objekt schreiben 49

Operational Data Store 21

- P -

Persistent Staging Area 19, 33

Prozessphasen 37

- Q -

Quellenverzeichnis 108

Query 90

- R -

rku.it 9

Routine 84

- S -

SAP for Utilities 58

SID-Tabellen 20

Simulation 64

Sortieren 82, 84, 87

Spalten ausblenden oder umbenennen 45

Sperrvermerk 2

Stammdaten kaufmännisch 61 technisch 61

Stammdaten im SAP BW 15

Stammdatentragendes Merkmal 18

Stammdatenverwaltung 59

Standardaggregation 39

Sternschema 20

Stornierung 64


- 110 -

- T -

T7B 11

TB1 11

Texte 15

Thematik 8

Transferstruktur 19

Transformation 14, 33, 40

- U -

Übertragungsregeln 24

Übertragungsverfahren 24

- V -

Verbrauchsstelle 62

Verbuchungsarten 29

Vertrag 61

Vertragsabrechnung 62

Vertragskonto 61

- W -

Waste and Recycling 59

Wiederholung eines Delta-Updates 32

Work Management 59

- Z -

Zählpunkt 62

Zeit 18

Zielsetzung der Arbeit 9

Zusammenfassung 94

Zwischenergebnis berechnen 53

Documents

Analyse-Prozess-Designer - business . intelligence . institutebusiness-intelligence-institute.org/download/Halboth Analyse... · Kurzfassung - 3 - Kurzfassung Die vorliegende Arbeit