Realisierung eines Management Cockpits auf Basis von SAP NetWeaver zur Unterstützung des Performance Measurement

Inhaltsverzeichnis

Abkürzungsverzeichnis... 4

1 Einleitung... 6

2 SAP NetWeaver 2004... 6
2.1 SAP Business Information Warehouse 3.5... 8
2.1.2 Administrator Workbench... 8
2.1.3 Business Explorer... 9
2.1.4 Web Application Designer... 9
2.2 SAP Web Application Server Release 6.40... 9

3 Datenmodellierung... 10
3.1 Definition der InfoObjects... 10
3.2 Definition des ODS‑Objekts... 12
3.3 Definition der InfoCubes... 13
3.4 Definition des MultiCube... 15

4 Datenakquisition... 15
4.1 Definition des Extraktions-, Transformations- und Lade‑Prozess... 15
4.1.1 Definition des Extraktors... 16
4.1.2 Definition der DataSource... 17
4.1.3 Definition der InfoSource... 18
4.1.4 Definition der Fortschreibungsregeln... 18
4.1.5 Definition des InfoPackage... 19
4.2 Datenfortschreibung... 20
4.2.1 Definition der DataSource... 20
4.2.2 Definition der InfoSource... 21
4.2.3 Definition der Fortschreibungsregeln. ..22
4.2.4 Definition des InfoPackages... 24
4.3 Datenfortschreibung des MultiCubes... 24

5 Datenanalyse... 25
5.1 Anlegen der Indikator‑Hierarchie des Human Capital... 26
5.2 Auswertungen auf Basis der InfoCubes auf Data Mart‑Ebene... 27
5.3 Auswertungen auf Basis des MultiCubes... 29
5.4 Weitere Auswertungen auf der Datenbasis... 30

6 Datenkommunikation... 31
6.1 Gestalterische Realisierung... 31
6.1.1 Anwenderzentriertes Design... 32
6.1.2 Zielgruppen-Definition... 32
6.1.3 Zielgruppenorientierte Visualisierung der Informationen... 33
6.1.3.1 Dimensionen visueller Darstellungsformen... 33
6.1.3.2 Anwendung der Gestaltgesetze... 34
6.1.4 Zielgruppenorientierter Aufbau und Navigation... 38
6.1.4.1 Grundstruktur des Management Cockpits... 38
6.1.4.2 Einstieg in den Management Cockpit‑Raum... 40
6.1.4.3 Einstieg in das Management Cockpit... 41
6.1.4.4 Navigation im Management Cockpit... 42
6.2 Technische Realisierung... 42
6.2.1 Business Server Pages... 43
6.2.2 Implementierung der Grundstruktur des Management Cockpits... 43
6.2.3 Implementierung des Einstiegs in den Management Cockpit‑Raum... 44
6.2.3.1 Implementierung des Firmenzeichens... 45
6.2.3.2 Implementierung der Navigationsbereiche... 45
6.2.3.3 Implementierung der Informationsbereiche... 45
6.2.3.4 Implementierung des Tickers... 45
6.2.4 Implementierung des Einstiegs in das Management Cockpit... 45
6.2.4.1 Implementierung des Navigationsbereichs... 45
6.2.4.2 Implementierung des sekundären Informationsbereichs... 46
6.2.4.3 Implementierung des primären Informationsbereichs... 46
6.2.4.4 Implementierung des Web‑Templates für die Darstellung der Indikator‑Hierarchie... 46
6.2.4.5 Implementierung des Tabellen-Interface für die Berechnung der HC‑Performance... 46
6.2.4.6 Implementierung der Darstellung der Indikator‑Hierarchie... 48

7 Zusammenfassung... 49

6 Literaturverzeichnis (inkl. weiterführender Literatur)... 50
Internet-Quellen... 50
Literatur-Quellen... 51

1 Einleitung

Gegenstand dieser Arbeit ist die Realisierung des MC zur Unterstützung des PM des HC auf Basis der im vorangegangenen Kapitel dargelegten Überlegungen zur Konzeption.

Die Umsetzung erfolgt analog zum Entwurf der informationstechnischen Konzeption mit den Phasen zur Implementierung des Datenmodells, der Datenakquisition, Datenanalyse und Datenkommunikation. Im Vorfeld soll jedoch die technische Basis erläutert werden, auf der die Realisierung des MC zur Unterstützung des PM des HC aufsetzten soll.

Die Umsetzung des MC‑Prototyps erfolgt mit Hilfe von SAP NetWeaver 2004. Deshalb wird zuerst ein kurzer Überblick über die Implementierungskomponenten des technischen Frameworks von SAP NetWeaver 2004 gegeben. In diesem Bezugsrahmen werden dann auch die für die Realisierung des MC‑Protoypen wichtigsten Bestandteile von SAP NetWeaver 2004, die zentrale Anwendungskomponente des SAP Web Application Servers Release 6.40 und das SAP‑eigene DWH‑Projekt SAP Business Information Warehouse 3.5 detailliert beschrieben.

2 SAP NetWeaver 2004

SAP NetWeaver 2004 (SAP NW ’04) wird von der SAP AG als Informations‑ und Integrationsplattform vermarktet, die als Teil der mySAP.com‑Produktpalette Menschen, Informationen, Geschäftsprozesse sowie verschiedenen Technologien vereinigen soll. Dies verdeutlicht das folgende Schaubild zur Architektur von SAP NW ’04:

Abbildung 1 – SAP NetWeaver 2004 Architektur[1]

[Abbildungen werden in dieser Leseprobe nicht angezeigt]

Neue und alte Informationssysteme sollen mit Hilfe von SAP NW ’04 konsolidiert und harmonisiert werden, um eine unternehmensübergreifende Datenbasis für alle Unternehmenspartner zu schaffen. Dies geschieht unter der Zielsetzung, einen verkürzten und effizienteren Daten- und Informationszugriff sowie ‑austausch zu gewährleisten und infolgedessen die gesamte Informationsverarbeitung zu optimieren.

Dazu werden die Komponenten des Composite Application Frameworks und des Life Cycle Managements eingesetzt. Sie stellen eine standardisierte und übergreifende Entwicklungs‑ und Laufzeitumgebung zur Verfügung, mit der unter minimalem Programmieraufwand funktionsübergreifend integrierbare Applikationen erstellt und über den gesamten Software‑Lebenszyklus überwacht und gewartet werden können. [2]

2.1 SAP Business Information Warehouse 3.5

Ein Bestandteil der SAP Business Intelligence (SAP BI) Suite der Integrationsplattform SAP NW ’04 ist das SAP‑eigene DWH-Projekt:
Das SAP Business Information Warehouse 3.5 (SAP BW 3.5).

Das SAP BW 3.5 ist ein vollständiges DWS, welches neben der eigentlichen DWH‑Datenbank und den Werkzeugen zu deren Befüllung auch umfangreiche Reporting‑Funktionalitäten besitzt.

Abbildung 2 – SAP Business Information Warehouse 3.5[3]

[Abbildungen werden in dieser Leseprobe nicht angezeigt]

Ein Überblick über das SAP BW 3.5 gibt die Abbildung , anhand derer die wichtigsten Funktionalitäten und Werkzeuge des SAP BW 3.5 erläutert werden sollen.

2.1.1 Administrator Workbench

Die Administrator Workbench (AWB) ist das zentrale Bedienungselement des SAP BW 3.5 im Rahmen der Steuerung, Überwachung und Pflege aller Datenbeschaffungsprozesse. [4]

Hier werden im Folgenden alle notwendigen Schritte zur Datenmodellierung vorgenommen. Dazu sollen anhand des entwickelten Datenmodells die äquivalenten Datenelemente definiert und der gesamte Datenfluss mit seinen entsprechenden Extraktions- und Transformationskomponenten nachgebildet werden, um schließlich die Daten der HC‑Performance in dem DWH vorzuhalten.

2.1.2 Business Explorer

Der Business Explorer (BEx) stellt das Reporting- und Analysewerkzeug des SAP BW 3.5 dar. Mit seiner Hilfe können Auswertungen auf OLAP‑Basis definiert und für die Entscheidungsunterstützung verwendet werden.

Hier sollen die für die verschiedenen Sichten des MC‑Prototypen benötigten Daten ausgewählt werden. Dies geschieht über sog. Queries, die mit Hilfe des Query Designers angelegt werden und eine Selektion über die Attribute und Fakten des jeweiligen Reporting-Datenelements repräsentieren.

Die bei der Query‑Ausführung produzierten Analyseergebnisse können später auf verschiedenste Weise dem Anwender angezeigt werden.

2.1.3 Web Application Designer

Für die Zwecke des MC‑Prototyps ist vor allem die Web‑Integration des Reportings von Relevanz. Der Zugriff auf Auswertungen über das Internet wird mit Hilfe des Web Application Designers (WAD) ermöglicht. Der WAD baut dabei auf den BEx-Funktionalitäten auf und übernimmt die internetgerechte Präsentation der Daten.

2.2 SAP Web Application Server Release 6.40

Im Zusammenspiel mit SAP NW ’04 stellt der SAP Web Application Server 6.40 (SAP WAS 6.40) die gemeinsame technische Basis für eine Vielzahl von Anwendungskomponenten dar; so auch für das SAP BW 3.5 und den MC‑Prototypen. [5]

Im Rahmen von SAP NW ’04 ist er die Entwicklungs- und Laufzeitumgebung für ABAP‑ und Java‑Applikationen und dient als Web‑Server zur Implementierung von client‑ als auch serverseitigen Web‑Anwendungen. In der Drei‑Schichten-Architektur moderner Client‑Server‑Konzepte arbeitet der SAP WAS 6.40 auf der Applikationsschicht [6] . Dort dient er in Form eines Applikationsservers als Plattform für die Ausführung von Programmen und als Konnektor zwischen Front End und Datenbankschicht. Des Weiteren fungiert der SAP WAS 6.40 als Web‑Server zur bi‑direktionalen Kommunikation mit dem Internet sowie Entwicklung und Verteilung von Webservices. [7] Da seine Funktionen durch die „ … enge Verzahnung bzw. Kombination eines solchen Systems aus Web‑ und Applikationsserver“ [8] nur schwer getrennt werden können, wurden die beiden Aufgabenbereiche im SAP WAS 6.40 zusammengeführt. Dies verdeutlicht auch das Anwendungsbeispiel des MC.

Für die Realisierung des MC‑Prototyps werden über den SAP WAS 6.40 die für die Darstellung des MC benötigten Webseiten generiert und für Anfragen aus dem Internet verfügbar gemacht. Außerdem übernimmt der Web-Server die Abwicklung der eingehenden Service‑Requests, indem er diese entgegennimmt und bearbeitet. Dazu wird eine Verbindung mit dem SAP BW 3.5 aufgebaut und die entsprechenden Daten ausgelesen, aufbereitet und durch den SAP WAS 6.40 ein neu generiertes Webdokument an den Service‑Consumer zurückgesendet.

3 Datenmodellierung

Für die Realisierung des MC zur Unterstützung des PM des HC ist es zuerst notwendig, den anhand der Anforderungen des Unternehmensszenarios entwickelten Datenfluss und das darauf aufbauende Datenmodell im SAP BW 3.5 abzubilden.

Dazu müssen die benötigten Datenobjekte und Metadaten angelegt und definiert werden, was im Folgenden in der Reihenfolge des Datenflusses skizziert wird.

3.1 Definition der InfoObjects

Die Umsetzung eines Datenmodells beginnt stets mit der Definition der Datentypen und Festlegung ihrer Datenlänge. Dazu werden in der AWB die sog. InfoObjects angelegt, die als kleinste Informationseinheiten des SAP BW 3.5 die Grundlage für alle weiteren Datenziele bilden.

InfoObjects werden dabei ebenfalls fachlich in Attribute und Fakten unterschieden, wobei die Bezeichnungen im SAP BW 3.5‑Umfeld abweichen. [9] Hier wird zwischen Kennzahlen (Fakten) und Merkmalen (Attributen) unterschieden, die analog zu der Definition von Fakten- bzw. Attributsdaten Bewegungs- oder Stammdaten aufnehmen.

Bei der Definition eines InfoObject weist man diesem neben einem systemweit eindeutigen technischen Namen und einer Textbeschreibung auch einen primitiven Datentyp und die Länge des Datenfeldes zu. [10] In Abhängigkeit von der Ausprägung des InfoObject können entweder nur numerische (für die Kennzahl‑InfoObjects) oder auch zeichentragende Datentypen zugewiesen werden.

Abbildung 3 – Anlegen von InfoObjects im SAP Business Information Warehouse 3.5[11]

[Abbildungen werden in dieser Leseprobe nicht angezeigt]

Für die Definition von Kennzahlen ist zudem ggf. die Zuordnung einer Maßeinheit und das Aggregationsverhalten bei Rechenoperationen von Belang. Dazu kann einerseits das normale Aggregationsverhalten festgelegt werden. Dies bestimmt das Vorgehen bei Datensätzen mit Schlüsselgleichheit. Hier kann entweder der aufsummierte, maximale oder minimale Aggregationswert über die Datensätze gebildet werden. Andererseits kann eine sog. Ausnahmeaggregation definiert werden, die in Abhängigkeit von einem Bezugsmerkmal eine Berechnung durchführt. [12] Für die Abbildung des Datenmodells des MC‑Prototypen ist Letzteres für die Aggregation der täglich gemeldeten Indikator-Werte von Bedeutung, über die für die wöchentliche Berichterstattung ein gleitender Durchschnitt auf Basis einer Kalenderwoche gebildet werden soll.

InfoObjects des Typs Merkmal besitzen die Eigenschaft, dass ihnen Stammdatentexte zur Beschreibung betriebswirtschaftlicher Sachverhalte zugewiesen und diese sprach‑ und zeitabhängig vorgehalten werden können. [13] Diese Erläuterungstexte werden den Stammdatenschlüsseln eines Merkmals zugewiesen und können später im Reporting angezeigt werden. Des Weiteren können Ihnen sog. Navigationsattribute zugewiesen werden, die eine Verknüpfung mit anderen Merkmalen definieren. So besitzt z. B. das Merkmal „Indikator“ die Navigationsattribute Indikator‑Name, Indikator-Messansatz und Erhebungsperiodizität, die diesem Merkmal eindeutig zuzuordnen sind und es in seiner Ausprägung spezifizieren.

Die folgende Übersicht zeigt die InfoObjects, die für die Abbildung des Datenmodells des MC‑Prototyps im SAP BW 3.5 mit Hilfe der AWB modelliert wurden:

Abbildung 4 – InfoObjects des Prototyps für das Management Cockpit zur Unterstützung des Performance Measurements des Human Capital[14]

[Abbildungen werden in dieser Leseprobe nicht angezeigt]

3.2 Definition des ODS‑Objekts

Das erste Datenelement im Datenfluss innerhalb des DWS ist das zentrale ODS‑Objekt, welches die Daten aller anzubindenden Quellsysteme aufnehmen soll.

Die Fehler! Verweisquelle konnte nicht gefunden werden. erfolgt so:

Abbildung 5 – Zentrales ODS-Objekt des Prototyps für das Management Cockpit zur Unterstützung des Performance Measurements des Human Capital[15]

[Abbildungen werden in dieser Leseprobe nicht angezeigt]

In der obigen Abbildung sind die benötigten InfoObjects zur Definition der ODS‑Datenbanktabelle in ihrer Gliederung nach Schlüssel‑ und Datenfeldern sowie Navigationsattributen aufgeführt. Letztere müssen bei der Datenakquisition nicht befüllt werden und dienen in diesem Fall nur zur Veranschaulichung der verknüpften InfoObjects mit den Merkmalen der Schlüsselfelder.

3.3 Definition der InfoCubes

Als nächstes folgt im Datenfluss des Unternehmensszenarios die Data Mart‑Ebene mit den drei Data Cubes für jede einzelne Niederlassung.

Multidimensionale Data Cubes werden von der SAP AG als InfoCubes oder BasisCubes bezeichnet. Sie stellen innerhalb des SAP BW 3.5 das Standard‑Reportingobjekt und unterscheiden sich nur hinsichtlich der Interpretation des Star-Schema. Das erweiterte Star‑Schema sieht aus Performance‑Gründen noch eine zusätzliche Ebene zwischen der Fakten‑ und der Dimensionstabelle vor, die Schlüsselkombinationen aus den einzelnen Dimensionsmerkmalen eine sog. S‑ID (Surrogat‑Identifikationsdatum) zuordnet. Da die Tabellen für die S‑IDs sowie die Fakten‑ und Dimensionen automatisch vom SAP BW 3.5 angelegt werden, soll dies nicht weiter erläutert und lediglich die Definition des InfoCubes beschrieben werden. Diese erfolgt ebenfalls mit Hilfe der AWB und soll am Beispiel des Data‑Marts für den Standort Deutschland dargestellt werden.

Der folgende ScreenShot [16] zeigt zum einen die InfoCube-Pflege der AWB mit den verfügbaren und dem InfoCube zugeordneten Merkmalen. Hier werden über die verschiedenen Reiter auch die in den InfoCube aufzunehmenden Zeitmerkmale und Kennzahl-InfoObjects definiert. Des Weiteren erfolgt über diese Transaktion die Zuordnung der Merkmale zu den verschiedenen Auswertungsdimensionen. Dies ist in der nebenstehenden Grafik dargestellt, die in vereinfachter Form das SAP BW 3.5 Star‑Schema widerspiegelt und die Aufteilung der Merkmale in Dimensionstabellen erläutert. [17]

Abbildung 6 – InfoCube des Prototyps für das Management Cockpit zur Unterstützung des Performance Measurements des Human Capital[18]

[Abbildugen werden in dieser Leseprobe nicht angzeigt]

Die Definition des InfoCubes auf Data‑Mart‑Ebene für die deutsche Niederlassung des Unternehmensszenarios erfolgt analog für die InfoCubes der anderen beiden Standorte.

3.4 Definition des MultiCube

Das letzte Element im Datenfluss stellt der virtuelle Cube dar, der eine vereinheitlichte Sicht über die Data‑Mart‑Ebene bieten soll.

Im Sprachgebrauch des SAP BW 3.5 werden diese Datenobjekte mit dem Fachterminus MultiProvider bzw. MultiCube [19] bezeichnet, in denen sämtliche InfoProvider des Systems für das Reporting zusammengefasst werden können. InfoProvider sind alle Datenziele, wie ODS‑Objekte oder InfoCubes, die für das Reporting zur Verfügung stehen. [20]

Die Modellierung und Definition eines MultiCubes entspricht im Wesentlichen den Anforderungen von InfoCubes. Zur Einrichtung eines MultiProviders müssen jedoch zuerst die abzubildenden InfoProvider, hier die drei Standort‑InfoCubes, ausgewählt und anschließend aus der Gesamtmenge der InfoObjects aller InfoCubes die benötigten Kennzahlen und Merkmale in Abhängigkeit vom InfoProvider selektiert werden. Dabei ist zu beachten, dass ein gemeinsames InfoObject in allen InfoProvidern besteht, „ … das als Schlüssel zum „Verbinden“ der InfoCubes dient.“ [21] Für den vorliegenden MultiProvider werden dazu alle InfoObjects aus jedem der drei BasisCubes übernommen, mit Ausnahme des quantitativen Kennzahl‑InfoObject.

4 Datenakquisition

Der Vorgang zur Befüllung des DWH mit den Daten aus den SAP HR‑Systemen und der Einrichtung des Datenflusses gliedert sich innerhalb des DWS in zwei Teilbereiche: Den ETL‑Prozess und die Datenfortschreibung.

4.1 Definition des Extraktions-, Transformations- und Lade‑Prozess

Zuerst müssen die die HC‑Performance repräsentierenden Informationen innerhalb der SAP HR‑Systeme gesammelt und in einer passenden Struktur dem SAP BW 3.5 zur Verfügung gestellt werden, um sie dann später in das zentrale ODS‑Objekt im SAP BW 3.5 zu laden.

4.1.1 Definition des Extraktors

Für jeden PI des HC existiert in dem jeweiligen SAP HR‑Modul ein sog. Infotyp, der über einen Gültigkeitszeitraum, einen Schlüssel, eine (Wert‑)Ausprägung sowie eine Beschreibung definiert und der jeweiligen Person zugeordnet ist. Die folgende Abbildung zeigt die drei Infotyp‑Ausprägungen der Indikator‑Dimension des Kompetenz‑Potentials der HC‑Indikator‑Hierarchie, die in der Tabelle des Infotyps „Qualifikation“ der SAP HR‑Komponente Personaladministration [22] abgelegt sind.

Abbildung 7 – Infotyp des SAP Human Ressource Moduls[23]

[Abbildungen werden in dieser Leseprobe nicht angzeigt]

Das Sammeln und Extrahieren der Infotyp-Daten erfolgt über den sog. Extraktor. [24] Der Extraktor ist in dem hier vorliegenden Fall eine Anwendung bzw. ein Funktionsbaustein auf dem SAP HR‑Quellsystem, [25] der die personenbezogenen Daten aus den korrespondierenden Datenbanktabellen der Infotypen ausliest und in Abhängigkeit von ihrer Zuordnung zu Planstellen des Organisationsmanagements auf Abteilungsebene aggregiert.

Die so anonymisierten Daten werden in eine adäquate Datenstruktur für die Extraktion in das SAP BW 3.5 transformiert. Diese Datenstruktur wird als Extraktstruktur bezeichnet und stellt die Schnittstelle zwischen dem Quellsystem und dem DWH dar. Die folgende Abbildung zeigt den Aufbau der Extraktstruktur, die über den Extraktor gefüllt wird:

Abbildung 8 – Extraktstruktur des SAP Human Ressource Quellsystems [26]

[Abbildungen werden i dieser Leseprobe nicht angezeigt]

4.1.2 Definition der DataSource

Zur Übernahme der Daten in das SAP BW 3.5 muss die Definition der Extraktstruktur und das zugehörige Quellsystems dem DWH bekannt gemacht werden. Dies geschieht über die DataSource, die quellsystemspezifisch angelegt werden muss.

Durch das Einrichten der SAP HR‑Systeme als Quellsysteme des SAP BW 3.5 wird die Verbindung hergestellt. Da es sich in dem diskutierten Unternehmensszenario bei den Quellsystemen um SAP‑Module handelt, bietet das SAP BW 3.5 die Möglichkeit an, die DataSources zu replizieren [27] ; d. h., dass die Definition der Extraktstruktur des Quellsystems automatisch in die DataSource auf DWH‑Seite übernommen wird und kein manuelles Anlegen notwenig ist. [28]

DDie so generierte DataSource beinhaltet nun die Metadatenbeschreibung des Quellsystems. Diese wird dann mit den passenden InfoObjects im SAP BW 3.5 gemappt und der Zugriff auf die in der Extraktstruktur gelieferten Daten ermöglicht. [29]

[...]

---

[1] Eigene Darstellung in Anlehnung an SAP AG (2003), http://www11.sap.com, S. 6.

[2] Heinemann; Rau (2005), S. 27f.

[3] SAP AG (2003a), http://help.sap.com, o. S.

[4] Vgl. SAP AG (2003b), http://help.sap.com, o. S.

[5] Vgl. Heinemann; Rau (2005), S. 21.

[6] Die Three-Tier-Architektur beinhaltet folgende Schichten in aufsteigender Reihenfolge: Client‑Schicht, Applikationsschicht und Datenbankschicht. Vgl. Heinemann; Rau (2005), S. 33.

[7] Vgl. SAP AG (2005), http://help.sap.com, o. S.

[8] Heinemann; Rau (2005), S. 24.

[9] Vgl. Seemann et al. (2001), S. 118 und 120.

[10] Vgl. Hahne (2005), S. 43.

[11] ScreenShot aus dem SAP BW 3.5.

[12] Vgl. Fischer (2003), S. 107.

[13] Vgl. Seemann et al. (2001), S. 122.

[14] ScreenShot aus dem SAP BW 3.5.

[15] ScreenShot aus dem SAP BW 3.5.

[16] Der linke Teil des ScreenShots stammt aus der InfoCube-Pflege der AWB, wohingegen die rechte Grafik eine aus dem Metadata Repository generierte Grafik ist, die mit Hilfe eines Bildbearbeitungsprogramms zusammengeführt wurde.

[17] Die Darstellung des SAP Star‑Schemas ist nicht zuletzt aufgrund der fehlenden S‑ID‑Tabellen unvollständig. Es werden auch zwei der drei vom SAP BW 3.5 vorgegebenen Standarddimensionen (Datenpaket und Einheiten) unterschlagen. Die dritte nicht explizit zu definierende Dimension beinhaltet die Zeit‑Merkmale des Datenmodells eines InfoCubes. Vgl. Mehrwald (2003), S. 92.

[18] ScreenShot aus dem SAP BW 3.5.

[19] Dies ist die alte Bezeichnung der SAP AG für einen virtuellen Cube, der im Zeitverlauf durch den Begriff des Multiproviders zur Begriffsvereinheitlichung mit den untergeordneten InfoProvidern eingeführt wurde.

[20] Vgl. Mehrwald (2003), S. 6.

[21] Seemann et al. (2001), S. 130. Anführungszeichen im Zitat wurden geändert.

[22] Neben den HC‑Performance‑Daten aus dem Bereich der Personalentwicklung werden auch Infotyp‑Daten aus den SAP HR‑Komponenten Organisationsmanagement und Zeitwirtschaft ausgelesen.

[23] ScreenShot aus dem SAP HR.

[24] Vgl. Fischer (2003), S. 93.

[25] Ein Extraktor kann auch generischer Natur sein, der lediglich eine ihm zugewiesene Datenbank‑View ausliest und in einer passenden Extraktstruktur zur Verfügung stellt.

[26] ScreenShot aus dem SAP HR.

[27] Zum Fachterminus des „Replizierens“ vgl. Mehrwald (2003), S. 194.

[28] Vgl. Seemann et al. (2001), S. 159f.

[29] Vgl. Fischer (2003), S. 93f.