3 SAP Business Information Warehouse

Transkript

1 3 SAP Business Information Warehouse»Die Grundlage ist das Fundament der Basis.«Le Corbusier Das Business Information Warehouse (BW) ist die von SAP entwickelte Applikation eines Data Warehouses. Das BW ist inzwischen die Grundlage für verschiedene Anwendungen der SAP geworden, insbesondere der so genannten»new-dimension-produkte«. Zu diesen Anwendungen gehört auch das Strategic Enterprise Management (SEM) und damit auch das Business Planning and Simulation (BPS), das eine Komponente des SEM ist. Wenn das SEM-BPS im Unternehmen eingesetzt werden soll, kann dies nicht ohne das BW erfolgen, weshalb das BW hier nun vorgestellt werden soll. Sind keine Vorkenntnisse in diesem Bereich vorhanden, so ist die Lektüre des vorliegenden Kapitels für das weitere Verständnis zwingend erforderlich. Die eigentlichen Integrationsbereiche zwischen dem SEM-BPS und dem BW ergeben sich in der Modellierung der Daten (siehe Abschnitt 3.1.2). Erst wenn im BW die Objekte des Datenmodells eingestellt worden sind, kann mit dem Aufbau der SEM-BPS-Architektur begonnen werden. Darüber hinaus ist das BW die Datenquelle für die Planung, wenn es sich um Istdaten und Plandaten (aktuelle, vergangene) als Vergleichsdaten bzw. um Plandaten (zukünftige) aus anderen Systemen (z. B. R/3-System) handelt. Die Datenbeschaffung wird in Abschnitt näher beschrieben. Wenn im SEM-BPS über Planungsfunktionen veränderte oder generierte Daten gespeichert werden sollen, sind diese wiederum in das BW zurückzuschreiben (siehe Abschnitt 3.1.2). Möchte man die geplanten Daten in Berichten verwenden, so bietet sich wiederum das BW als ideales Werkzeug an. Über so genannte Queries können Berichte flexibel erstellt werden, die in Abhängigkeit des eingestellten Datenmodells auf alle im BW gespeicherten Daten zugreifen können (siehe Abschnitt 3.1.3). Das BW ist als eigenständige Applikation zu komplex, um es im Kontext eines Buches zur integrierten Unternehmensplanung detailliert beschreiben zu können. Für eine Vertiefung des Themas BW ist zunächst die im SAPNet verfügbare Dokumentation der SAP (z. B. der Titel»SAP Business Information Warehouse Functions in Detail«) zu empfehlen. 1 Die soeben beschriebenen Integrationspunkte insbesondere die der Modellie- Aufbau dieses Kapitels SAP Business Information Warehouse 91

2 rung haben jedoch auch gezeigt, dass gewisse Bestandteile des BW fundamental sind, sodass eine detaillierte Beschreibung dieser Bereiche angebracht ist. Dieses Kapitel ist daher folgendermaßen gegliedert: 1. Darstellung des Dreischichten-Modells, das alle Bereiche des BW abdeckt und diese daher nur auf aggregiertem Niveau beschreibt 2. Detaillierte Beschreibung der für das SEM-BPS relevanten Datenmodellierung mit Hinweisen zur Einstellung der Objekte im System 3. Fokus auf Bereiche des BW, die für das SEM-BPS besonders wichtig sind (teilweise betreffen sie die Modellierung und sollten daher sehr früh im Rahmen eines Projektes berücksichtigt werden) Viele BW/SEM-Projekte beginnen mit der Einführung des BW. Erst später entscheidet man sich für die Einführung von SEM-BPS, um die im BW vorhandenen Istdaten um Plandaten zu erweitern. Je nachdem, wie die Datenmodelle im BW eingestellt worden sind, können sich später für das SEM-BPS bedeutsame Einschränkungen ergeben. Im Einzelfall wird dann zu prüfen sein, ob das bestehende Datenmodell neu definiert oder um SEM-spezifische Einstellungen erweitert wird. Aus diesem Grund sollte man möglichst frühzeitig SEM-BPS-bedingte Restriktionen berücksichtigen. 3.1 Das Dreischichten-Modell des BW Aufgabe des Business Information Warehouse (wie auch generell bei Data- Warehouse-Systemen) ist die Bereitstellung von Daten für Auswertungen jeglicher Art. Letztere sind Bestandteil der Präsentationsebene, die eine der drei Schichten im Dreischichten-Modell repräsentiert. Bevor jedoch Daten in einem Bericht dargestellt werden können, müssen sie zunächst in das Business Information Warehouse»gelangen«. Dies kann entweder durch die Extraktion (Übernahme) von Daten aus anderen Systemen (SAP-eigene oder auch SAP-fremde Systeme) erfolgen oder über das Laden von Daten aus so genannten»flatfiles«(z.b. Excel- oder Textdateien). Die beschriebene Datenbeschaffung oder auch Datenbereitstellung ist der Extraktionsebene, als eine weitere Schicht des Dreischichten-Modells, zuzuordnen. Nachdem die Daten extrahiert oder auf anderem Weg in das BW geladen worden sind, müssen sie über vordefinierte Regeln so aufbereitet werden, dass sie anschließend konsistent und persistent im Warehouse vorgehalten werden können. Dieser Schritt erfolgt in der Administrationsebene, die somit die letzte Schicht des Dreischichten-Modells darstellt. Von hier aus 1 Siehe auch das SAP PRESS-Buch von Egger, 2003 sowie Mehrwald, SAP Business Information Warehouse

3 können die Daten in strukturierter Form der eingangs angeführten Präsentationsebene zur Verfügung gestellt werden. Der gesamte Prozess vom Laden bis hin zum Präsentieren der Daten ist somit Bestandteil des Business Information Warehouse. Abbildung 3.1 hält diesen Prozess in Anlehnung an das Dreischichten-Modell fest Extraktionsebene Administrationsebene 2 (Datenhaltung und - modellierung) 3 Präsentationsebene Abbildung 3.1 Dreischichten-Architektur des SAP BW (Quelle: SAP AG) Die drei Ebenen der Architektur werden in den folgenden Abschnitten detailliert beschrieben Extraktionsebene (Datenbereitstellung) Die Extraktionsebene umfasst alle technischen Aspekte, die den Transfer (die Extraktion) der Daten (sowohl der Stamm- als auch der Bewegungsdaten) aus dem Quellsystem in das BW ermöglichen. Geht man von der Extraktion der Daten aus einem SAP R/3-System aus, wird dieser Prozess durch so genannte Extraktoren unterstützt, die als Plug-Ins zuvor im R/3- System zu installieren sind. Extraktions- und Transferstrukturen auf dem R/3-System stellen sicher, dass in einer DataSource eine Anzahl von Feldern in einer flachen Struktur definiert ist, die zur Datenübertragung in das BW angeboten werden. Dieser sich noch im Quellsystem befindliche Bereich wird auch als Extraction Layer bezeichnet. Durch das Replizieren der DataSource ins BW wird erreicht, dass eine identische Feldstruktur zur späteren Übertragung der Daten aus dem Extraction Layer Inflow Layer Das Dreischichten-Modell des BW 93

4 Quellsystem ins BW vorliegt. Auf der Grundlage der replizierten Data- Source wird die Transferstruktur angelegt. Möchte man an dieser Stelle die auf der Basis der bis hierhin bestehenden Struktur extrahierten Daten überprüfen können, lässt sich mit Bezug zur DataSource eine Persistent Staging Area (PSA) als physische Eingangsablage anlegen (die PSA wird hauptsächlich aus Gründen der Performance als Zwischenspeicher beim Datenladen genutzt). Beim Laden von Daten werden dann die Datensätze an die Transferstruktur weitergegeben und im PSA gespeichert. Der zuvor beschriebene BW-basierte Bereich der Extraktionsebene wird insgesamt auch als Inflow Layer bezeichnet. Die Beschreibung des Extraction Layers und des Inflow Layers ist in Abbildung 3.2 dargestellt. Zusammen bilden beide Layer die Extraktionsebene. Ab hier erfolgt der Übergang zur nächsten Ebene, der Administrationsebene, als zweite Schicht im Dreischichten-Modell. PSA BW OLAP- System Inflow Layer Transferstruktur Replikation DataSource Systemübergang Transferstruktur Extraktionsstruktur Extraktionsdaten User Exit Extraction Layer SAP R/3-Module R/3 OLTP- System Abbildung 3.2 Architektur der Extraktionsebene Administrationsebene (Datenhaltung und -modellierung) Transformation Layer An den im vorhergehenden Abschnitt beschriebenen Inflow Layer schließt sich direkt der Transformation Layer an. Er umfasst im Wesentlichen drei Bestandteile: die InfoSource, die Kommunikationsstruktur und die Übertragungsregeln. Die InfoSource kann als eine Zusammenfassung 94 SAP Business Information Warehouse

5 inhaltlich logisch (betriebswirtschaftlich) zusammengehörender InfoObjekte verstanden werden, deren Ziel es ist, Informationen (Stamm- oder Bewegungsdaten) in strukturierter Form abzubilden und somit den noch zu beschreibenden Datenzielen zur Verfügung zu stellen. InfoObjekte sind als Merkmale oder Kennzahlen die Basiselemente des BW. Sie werden im Verlauf dieses Abschnitts noch aufgegriffen und detailliert beschrieben. Zu jeder InfoSource gehört eine Kommunikationsstruktur, die die Verknüpfung der Felder der DataSource mit den InfoObjekten der InfoSource sicherstellt. Darüber hinaus kann durch die Verwendung von Übertragungsregeln (Transfer Rules) festgelegt werden, wie die Felder der Transferstruktur in die InfoObjekte der InfoSource übernommen werden sollen. SAP liefert hierzu bereits eine Reihe von Regeln, die üblichen Geschäftslogiken entsprechen. In einem zweiten und damit letzten Schritt der Administrationsebene werden die Daten in das finale Datenziel fortgeschrieben. Diese auch als Integration Layer bezeichnete Ebene umfasst neben den Datenzielen die Fortschreibungsregeln. Als Datenziele werden alle Objekte des BW bezeichnet, in die letztendlich extrahierte oder auf andere Weise ins BW geladene Daten geschrieben werden. Solche Datenziele können Info Cubes, ODS-Objekte oder InfoObjekte sein (siehe Abschnitt 3.2). In diesem Fall sind es nur Merkmale mit Attributen, Texten oder Hierarchien Kennzahlen sind als Datenziele ausgeschlossen. Die Verwendung der Fortschreibungsregeln (Update Rules) stellt die Verbindung zwischen den InfoObjekten der InfoSource und den InfoObjekten des Datenziels her. Über Fortschreibungsarten (z.b. Addition von Kennzahlenwerten) und Fortschreibungsmethoden (z.b. Umformatierung von Merkmalen) kann die Fortschreibungsregel weiter spezifiziert werden. In Abbildung 3.3 ist die Administrationsebene bestehend aus Transformation- und Integration Layer nochmals zusammenhängend dargestellt. Mit der Darstellung des Extraction-, Inflow-, Transformation- und Integration Layers sind alle logischen Ebenen beschrieben worden, die an dem Prozess des Datenladens beteiligt sind, der auch als Staging bezeichnet wird. Die verschiedenen steuernden Objekte der jeweiligen Layer werden wiederum in ihrer Gesamtheit als Staging Engine bezeichnet. Neben der zuvor beschriebenen Datenhaltung ist die Datenmodellierung ein weiterer wesentlicher Bereich der Administrationsebene. Sie ist für die in SEM-BPS vorzunehmenden Einstellungen besonders relevant und wird daher in Abschnitt 3.2 beschrieben. Integration Layer Staging und Staging Engine Datenmodellierung Das Dreischichten-Modell des BW 95

6 Abbildung 3.3 Architektur der Administrationsebene (Quelle: SAP AG) Präsentationsebene (Datenauswertung und Reporting) Nachdem die Daten in den Datenzielen vorhanden sind, können sie von hier aus in Berichten analysiert werden. Das von der SAP dazu entwickelte Werkzeug ist der Business Explorer (BEx). Berichte des Business Explorers werden als Queries im Sinne klassischer Datenbankabfragen bezeichnet. Diese sind jedoch in Bezug auf Präsentationsfähigkeit nicht mit den ehemals verwendeten»select-abfragen«zu verwechseln. Der Business Explorer setzt sich aus drei Bereichen zusammen (siehe Abbildung 3.4): Business Explorer Funktionalitäten des BEx Business Explorer Analyzer (BEx Analyzer) Business Explorer Map (BEx Map) Web Application Designer Während die BEx Map Daten mit geographischem Bezug anhand von Landkarten auswertet, wird über den BEx Analyzer der Datenbestand über einen Excel-Bericht angezeigt. Mit dem Web Application Designer hat man die Option, die Berichte auch ins Web zu publizieren. Sowohl der BEx Analyzer als auch der Web Application Designer basieren auf einer stark vereinfachten Technik (Drag & Drop, Hilfsassistent), die dem Anwender die Erstellung gewünschter Berichte mit geringem Aufwand erlauben. Berichte können vordefiniert, zusätzliche Kennzahlen (Werte) über den Datenbestand des Datenziels hinausgehend errechnet und in Grafiken (neben der BEx Map) dargestellt werden. Drilldown- und Aufrissfunktionen erlauben die Auswertung der Daten bis auf die im Datenziel vorhandene Datengranularität. 96 SAP Business Information Warehouse

7 BEx Analyzer Web Report BEx Map ODBO Meta Data Repository OLAP Processor Operative Daten InfoProvider BW Server R/3 Abbildung 3.4 Präsentationsebene Darstellungsalternativen 3.2 BW-Einstellungen Datenmodellierung In Kapitel 2 wurde mehrfach betont, dass zum einen SEM-BPS-Funktionen nur auf der Basis eines im BW bestehenden Datenmodells angelegt werden können und dass zum anderen aufgrund dieser engen Verknüpfung die Datenmodellierung dementsprechend wichtig ist. Ohne dabei zu sehr ins Detail gehen zu wollen (flache Tabellen, Snowflake-Schema usw.), werden die für die Modellierung relevanten Objekte und das von der SAP verwendete erweiterte Star-Schema beschrieben. An geeigneter Stelle erfolgt der direkte Absprung in das System, sodass die Erstellung der einzelnen Objekte auch praktisch nachvollzogen werden kann BW-Datenmodell: erweitertes Star-Schema Ausgehend von den betriebswirtschaftlichen Anforderungen eines Unternehmens d.h. mit Bezug zur integrierten Unternehmensplanung die im System abzubildenden Planungsteilgebiete kann festgehalten werden, welche Objekte (im BW-Jargon als InfoObjekte bezeichnet) für die einzelnen Gebiete miteinander verknüpft werden sollen, um die gewünschten Daten im BW zu speichern. Es geht also um die Verknüpfung von Merkmalen (Kunde, Produkt usw.) mit Kennzahlen (Verkaufsmenge, Erlöse, BW-Einstellungen Datenmodellierung 97

8 Kosten des Umsatzes usw.), die für die einzelnen Planungsteilgebiete (hier z.b. die Ergebnisplanung) so im System zu hinterlegen sind, dass die Plandaten in der notwendigen Kombination im BW vorhanden sind. Datenmodelle: von der transaktionalen Struktur zum Star-Schema Star-Schema: Faktentabelle und Dimensionstabelle Die Modellierung der Daten verfolgt somit das Ziel, die Realität (z. B. die Ergebnisplanung) datentechnisch im System abzubilden. Bei diesem gedanklichen Transformationsprozess gibt es verschiedene Lösungsansätze die in der einschlägigen Literatur diskutierten Datenmodelle. Eine der Lösungen wird die in den ERP-(Enterprise-Resource-Planning-)Systemen wie dem SAP R/3 verwendete transaktionale Struktur sein. Wendet man sich hingegen den OLAP-spezifischen (Online Analytical Processing) Datenmodellen zu (OLAP-spezifische Datenmodelle sind für das Reporting besonders geeignet, da optimiert), gelangt man über flache Strukturen schließlich zu dem Star-Schema, das in seiner erweiterten Form von der SAP im BW eingesetzt wird. Die Wahl des Datenmodells ist letztlich abhängig von der abzubildenden Realität sowie von verschiedenen Faktoren wie Performance (insbesondere bei der Abfrage der Daten) und Betrachtung der Daten in der zeitlichen Dimension (historisch, aktuell, stichtagsbezogen). Für die Bearbeitung täglich anfallender Istdaten eignet sich eine normalisierte Form (transaktionale Struktur), während für analytische Anwendungen wie z.b. der jährlich anfallenden Unternehmensplanung Datenbankmodelle wie das Star-Schema geeignet sind. Das Star-Schema (siehe Abbildung 3.5) umfasst eine im Zentrum befindliche so genannte Faktentabelle und in relationaler Beziehung zu ihr stehende Dimensionstabellen. Ordnet man die Dimensionstabellen sternförmig um die zentrale Faktentabelle ergibt sich ein Stern, der dem Modell diesen Namen gab. Künstliche Schlüssel (oder auch abstrakte Nummern) stellen die Verbindung zwischen der Faktentabelle und den Dimensionstabellen her. In Anlehnung an die Dimensionen werden sie als DIM-ID (Dimensions- Identitätsnummer) bezeichnet. Die Faktentabelle ist der physische Ort, an dem die Datensätze (d.h. die Bewegungsdaten wie z.b. Plandaten) hinterlegt werden. Jeder Datensatz besteht dabei aus den Kennzahlenwerten (Erlöse, Verwaltungskosten usw.) sowie den künstlichen Schlüsseln, die die Kennzahlen weiter identifizieren. Dabei repräsentiert jeder Schlüssel einen Merkmalswert (auch als Merkmalsausprägung bezeichnet). In dem angeführten Beispiel könnte dies für das Merkmal»Kunde«der Einzelhandelsmarkt»Süd«sein. Die Information, um welches Merkmal und um welche Ausprägung des Merkmals es sich handelt, ist folglich in der Dimensionstabelle beschrieben. 98 SAP Business Information Warehouse

9 Durch die Verwendung der DIM-ID statt der Merkmalsausprägungen in der Faktentabelle können die Felder der Datensätze in ihrer Länge reduziert und damit performanter werden. In einer Dimensionstabelle sind somit 1 bis n Merkmale mit den entsprechenden Ausprägungen und weiteren beschreibenden Attributen (Kennzeichen, Texte, Kategorisierungen usw.) hinterlegt. Zumeist werden einer Dimension thematisch ähnliche Merkmale (z.b. Produkt und Produktgruppe) zugeordnet. Aufgrund der flachen Struktur der Dimensionstabelle ist aus Gründen der Performance darauf zu achten, dass nicht zu viele Merkmale in eine Dimension aufgenommen werden. Stammdatentabellen Hierarchien Dimension»Produkt«Dimension»Kunde«Attribute Größe Typ Verp DIM-ID I Merkmal: Produkt Merkmal: Produktgruppe DIM-ID II Merkmal: Kunde Merkmal: Kundengruppe Texte Produkt Pumpe Produkt Bike Produkt Stuhl DIM-ID I DIM-ID II DIM-ID III Kennzahl: Menge Kennzahl: KdU Kennzahl: Erlöse Dimension»Zeit«DIM-ID III Merkmal: Jahr Merkmal: Periode Abbildung 3.5 Star-Schema Ausgehend von dem Star-Schema hat SAP für das BW eine erweiterte Form entwickelt (siehe Abbildung 3.6). In Anlehnung an den künstlichen Schlüssel DIM-ID, werden die Merkmale nicht in den Dimensionstabellen direkt hinterlegt, sondern in eigenen Tabelle, die wiederum mit den Dimensionstabellen über einen weiteren künstlichen Schlüssel, dem SID (Stammdaten-Identitätsnummer) verknüpft sind. Dieses erweiterte Star- Schema hat den Vorteil, dass die in den SID-Tabellen hinterlegten Merkmale (mit den entsprechenden Ausprägungen) von den BW-Objekten»Faktentabelle«und»Dimensionstabelle«vollständig losgelöst sind und somit im gesamten BW frei referenziert werden können. Die Beschrei- SAP BW-Modell: erweitertes Star- Schema BW-Einstellungen Datenmodellierung 99

10 bung des InfoCubes wird später noch zeigen, dass die Faktentabelle und die Dimensionen jeweils Cube-spezifisch, während die Merkmale Cubeübergreifend sind. Attribute Größe Typ Verp Hierarchien MatGrup. MatGroupSID-Tabelle SIDtable (Name: /BIC/SMATGROUP) MatGroup Stammdatentabellen SIDtable (Name: /BIC/SMATGROUP) Texte Produkt Pumpe Produkt Bike Produkt Stuhl MatGrup. SID -MatGrup. X Y Z SID-Material Material SID-MatGrup AAA CCC DDD Dim-ID Erlöse Faktentabelle Dim-ID SID-Material Dimensionstabelle Material MatGroupSID-Tabelle SIDtable (Name: /BIC/SMATGROUP) Abbildung 3.6 Erweitertes Star-Schema des SAP BW (Quelle: SAP AG) InfoObjekte Die bereits mehrfach erwähnten InfoObjekte (insbesondere im Zusammenhang mit der Faktentabelle) bilden im Kontext des BW die kleinste Einheit. Grundsätzlich lassen sich zwei Typen unterscheiden: die Merkmale und die Kennzahlen. Mit Bezug zu den Merkmalen existieren neben den eher betriebswirtschaftlich orientierten die spezialisierten Merkmale für Zeiten und Einheiten Merkmale Merkmale repräsentieren betriebswirtschaftliche Auswertungsobjekte wie z. B. Kostenstelle oder auch Produkt. Darüber hinaus werden Merkmale durch Ausprägungen bzw. Merkmalswerte charakterisiert. Im Kontext der Kostenstelle wären dies beispielsweise die Produktions- und die Servicekostenstelle bzw. für die Region die Ausprägungen»Nord«und»Süd«. 100 SAP Business Information Warehouse

11 Im Unterschied zu den betriebswirtschaftlich orientierten Auswertungsobjekten, die individuell im BW definiert werden können, werden von der SAP Zeitmerkmale fest vorgegeben. Die Zeitmerkmale reichen von dem Merkmal 0WEEKDAY1 (Wochentag) bis hin zum Merkmal 0CALYEAR (Kalenderjahr). Dazwischen liegen eine weitere Reihe von Zeitmerkmalen, die alle üblichen Zeiteinteilungen wie Woche, Monat und Quartal berücksichtigen. Es können zwar weitere Zeitmerkmale definiert werden, doch fehlen dann die Vorteile der von der SAP ausgelieferten»echten«zeitmerkmale, wie z.b. die Partitionierung oder Typkonvertierung im Staging. Wie das Zeitmerkmal stellt auch der Merkmalstyp Einheit eine spezielle Ausführung des Merkmals dar. Solche Merkmale werden als Zusatzinformation zu den Kennzahlen verwendet, die entweder Beträge oder Mengen darstellen können. Daher ist auch beim Anlegen eines Merkmals vom Typ Einheiten zwischen der Ausprägung»Mengen- oder Währungseinheit«zu unterscheiden. Werden für Merkmale Texte, Attribute oder Hierarchien angelegt, handelt es sich um ein stammdatentragendes Merkmal. Wie bereits aus dem SAP R/3 bekannt, sind mit Stammdaten die Daten gemeint, die im Unterschied zu den Bewegungsdaten über einen längeren Zeitraum hinweg konstant bleiben. Als Stammdaten dienen Attribute der weiteren Beschreibung bzw. Strukturierung eines Merkmals oder genauer gesagt einer Merkmalsausprägung. Am Beispiel der Kostenstelle sind der Kostenstellenverantwortliche und der Kostenstellentyp jeweils ein Attribut. Im BW werden verschiedene Typen von Attributen unterschieden, wie zeitabhängige bzw. zeitunabhängige Attribute und Navigationsattribute. Zusätzlich lässt sich ein Merkmal an ein anderes klammern, wobei das geklammerte Merkmal wiederum als Attribut bezeichnet wird. Attribute müssen, bevor sie als solche einem Merkmal zugeordnet werden können, selbst als Merkmal im BW angelegt werden. Wie die Attribute sind auch Hierarchien Stammdaten. Eine Hierarchie kann nur mit Bezug zu einem Merkmal, das dann als Basismerkmal bezeichnet wird, angelegt werden. Werden in der Hierarchie für die unterschiedlichen Ebenen (oder auch Knoten) Merkmale bzw. deren Ausprägungen verwendet, spricht man von bebuchbaren Knoten. Liegen hingegen Textknoten (technischer Name 0HIERNODE) vor, können diese nicht bebucht werden. Abbildung 3.7 zeigt eine Hierarchie mit bebuchbaren Knoten: Das Basismerkmal 0ACCOUNT für Konto befindet sich auf Zeitmerkmal Einheitenmerkmal Stammdatentragendes Merkmal Attribut Hierarchie BW-Einstellungen Datenmodellierung 101

12 der untersten Ebene (Blätter). Je Ebene wird ein anderes Merkmal verwendet. Hierarchien müssen nicht immer mit einer einzigen Hierarchiewurzel (dem obersten Knoten) beginnen, sondern können über eine»schwesterbeziehung«mehrere»wurzelansätze«haben. Diese Funktion ist in BW-Release 3.1 verfügbar. Abbildung 3.7 Merkmalshierarchie am Beispiel der Bilanz Hierarchie anlegen Hierarchien werden mit Bezug zu einem Merkmal angelegt. Dazu ist zunächst das Merkmal über die Transaktion RSA14 bzw. über den Menüpfad SAP Menü Business Information Warehouse BW-Administration Administrator Workbench InfoObjects zu selektieren (das Merkmal ist am einfachsten über die Suchfunktion zu finden). Im Kon- 102 SAP Business Information Warehouse

13 textmenü eines selektierten (Basis-)Merkmals kann über die Option Hierarchie anlegen die Hierarchie angelegt werden. Diese Option ist nur dann für ein Merkmal vorhanden, wenn sie in den Einstellungen des Merkmals zugelassen worden ist. Abschließend sollen anhand des in Abbildung 3.8 dargestellten Merkmals 0COSTCENTER (Kostenstelle) die wesentlichen Einstellungen im System erläutert werden. Abbildung 3.8 Anlegen eines Merkmals im BW Ein Merkmal wird über den Menüpfad SAP Menü Business Information Warehouse BW-Administration Administrator Workbench InfoObjects angelegt (Transaktion RSA14). Es besteht aus den Kopfdaten sowie aus den Registerkarten Allgemeines, Business Explorer, Stammdaten/ Texte, Hierarchie und Klammerung. Nachfolgend werden in Abhängigkeit dieser Registerkarte die jeweiligen Einstellungen beschrieben: Allgemeines Auf dieser Registerkarte wird zunächst der Datentyp des Merkmals (Charakter, Numerisch, Datum oder Zeit) bestimmt. Des Weiteren ist die Datenlänge (für den internen Speicherplatz) vorzugeben. Anschließend sind zwei bedeutsame Kennzeichen zu bestimmen. Wird das BW-Einstellungen Datenmodellierung 103

14 Merkmal ausschließlich als Attribut eingesetzt, folgen daraus weitere Systemrestriktionen für das Merkmal. Es können also z.b. keine Hierarchien mit Bezug zum Attribut angelegt werden. Über das Kennzeichen Merkmal ist Dokumenteigenschaft wird gesteuert, ob z.b später auch im SEM-BPS Dokumente mit Bezug zum Merkmal angelegt werden können. Im SEM-BPS gibt es eine eigene Planungsfunktion zum Anlegen der Dokumente. Darüber hinaus können Dokumente in Planungslayouts mit Bezug zur Zelle angelegt werden. Diese Option besteht auch für das Anlegen von Dokumenten in BW-Queries. Business Explorer Hier können verschiedene Einstellungen mit Bezug zur Darstellung des Merkmals in einer Query vorgenommen werden. So kann vorbelegt werden, ob nur der Text des Merkmals oder auch der Schlüssel angezeigt werden soll. Darüber hinaus ist über ein Kennzeichen zu entscheiden, ob das Merkmal auch als»geo-merkmal«im BEx Map verwendet werden kann. Des Weiteren können die Merkmalswerte mit dem Kennzeichen Berechtigungsrelevant zum Anzeigen in Queries berechtigungsabhängig gestaltet werden. Stammdaten/Texte In diesem Bereich wird festgelegt, ob für das Merkmal Stammdaten, d.h. Merkmalswerte, angelegt werden sollen und ob darüber hinaus eine Textabelle für das Merkmal erstellt werden soll. Es besteht dann weiterhin die Möglichkeit, die Texte sprach- bzw. zeitabhängig für die Merkmalsausprägungen zu hinterlegen, sodass beispielswiese eine historische Entwicklung der Stammdaten nachvollzogen werden kann. Diese Option kann sich auch auf Attribute beziehen. Hierarchie Wenn man für das Merkmal Hierarchien anlegen möchte, ist hier das entsprechende Kennzeichen zu setzen. Soll die Hierarchie darüber hinaus aus verschiedenen Merkmalen bestehen, sind diese Merkmale als»fremde Merkmale in Hierarchien«aufzunehmen. Weitere Hierarchie- Eigenschaften, die für alle Hierarchien zu diesem Merkmal gültig sein sollen wie z.b. die Vorzeichenumkehr oder die Zeitabhängigkeit sind ebenso an dieser Stelle pflegbar. Attribute Hier werden alle Merkmale aufgenommen, die Attribut des vorliegenden Merkmals sein sollen. So könnte z.b. das Merkmal Konto als Attribut zum Merkmal Kostenart aufgenommen werden. 104 SAP Business Information Warehouse

15 Klammerung Auf dieser Registerkarte lassen sich wiederum wie bei der Registerkarte Attribute Merkmale selektieren. Im Unterschied zu einem Attribut ist dieses Merkmal jedoch an das vorliegende geklammert, d.h., die Selektion des vorliegenden Merkmals kann später nur im Zusammenhang mit dem geklammerten Merkmal erfolgen. Dies ist insbesondere dann wichtig, wenn ein Merkmal in verschiedenen organisatorischen Einheiten vorkommen kann, d.h. systemweit nicht eindeutig ist. Dieselbe Kostenstelle kann z.b. im R/3-System mit Bezug zu zwei unterschiedlichen Kostenrechnungskreisen angelegt werden. Im BW wäre es an dieser Stelle sinnvoll, die Kostenstelle an das Merkmal Kostenrechnungskreis zu klammern. Mit diesem doppelten Schlüssel ist eine Kostenstelle somit immer eindeutig im System identifizierbar. Nach Einstellung der einzelnen Registerkarten ist das Merkmal zu aktivieren. Wenn man zum angelegten Merkmal die Ausprägungen manuell anlegen möchte, kann man die dafür vorgesehene Pflegemaske über den Menüpfad Zusätze Stammdaten Pflegen bzw. direkt aus dem Kontextmenü zum Merkmal über Stammdaten pflegen erreichen Kennzahlen Im Unterschied zu den Merkmalen handelt es sich bei dem InfoObjekt»Kennzahl«nicht um eine Ordnungsgröße, sondern um einen Wert, der entweder eine Fluss- oder eine Bestandsgröße darstellt. Die Kennzahl wird damit zum Träger der in der Faktentabelle gebuchten Werte, wie z.b. die Produktionsmenge oder die Vertriebsgemeinkosten. Neben dem Betrag oder der Menge als geläufigste Einstellung können auch andere Kennzahlentypen wie Datum, Zeit, Zähler oder Integerzahl definiert werden. Mit der Unterscheidung zwischen Fluss- oder Bestandsgröße kann das Systemverhalten für den Kennzahlenwert beeinflusst werden. Während eine Flussgröße (z.b. Aufwendungen und Erträge der GuV) zeitunabhängige Werte abbildet und damit kumuliert werden kann, ist bei der Bestandsgröße darauf zu achten, dass sie grundsätzlich zeitbezogen und damit nur eingeschränkt kumulierbar ist. Dies ist am Beispiel der Positionen einer Bilanz nachvollziehbar. So kann z.b. ein Anlagenendbestand nicht mit dem Anfangsbestand kumuliert werden, sondern die Beziehung ergibt sich aus den Veränderungen (Flussgrößen), die sich zwischen den jeweiligen Betrachtungszeitpunkten ergeben haben: Bestands- und Flussgrößen Endbestand = Anfangsbestand +/ Bestandsveränderungen BW-Einstellungen Datenmodellierung 105

16 An dieser Stelle ist darauf hinzuweisen, dass die im SEM-BPS ausgelieferte Funktion zur Bestandsrechnung nur auf Flussgrößen basiert. Kennzahlen sollten aus SEM-BPS-Sicht möglichst nicht als Bestandsgrößen definiert werden. Einheiten Ein weiterer wesentlicher Bestandteil der Kennzahlendefinition ist im Fall des Kennzahlentyps Betrag oder Menge die Währung bzw. die Mengeneinheit. Es besteht die Möglichkeit, entweder eine Einheit fix vorzugeben oder auf ein Merkmal vom Typ Einheit zu referenzieren. Abschließend werden analog zu den Merkmalen anhand der Kennzahl 0AMOUNT (Betrag) die wesentlichen Einstellungen beschrieben. Abbildung 3.9 Anlegen einer Kennzahl im BW Eine Kennzahl kann ausgehend von der Transaktion RSA14 bzw. über den Menüpfad SAP Menü Business Information Warehouse BW-Administration Administrator Workbench InfoObjects angelegt werden (analog zum Merkmal). Abbildung 3.9 zeigt, dass neben den Kopfinformationen die drei Registerkarten Typ/Einheit, Aggregation und Weitere Eigenschaften zu pflegen sind: 106 SAP Business Information Warehouse

17 Typ/Einheit Diese Registerkarte ist grundlegend für die Definition der Kennzahl. An dieser Stelle wird bestimmt, wie die Zahlenwerte später vom System zu interpretieren sind. Wählt man den Typ Betrag oder Menge, ist zusätzlich eine Währungseinheit bzw. eine Mengeneinheit zu hinterlegen. Diese kann als fester Wert bestimmt werden oder variabel, indem auf ein entsprechendes Merkmal referenziert wird. Je nach Kennzahlentyp sind verschiedene Datentypen selektierbar. Aggregation Hier wird bestimmt, ob es sich bei der Kennzahl um eine Flussgröße oder eine Bestandsgröße handeln soll. Wird die Kennzahl als Bestandsgröße definiert, sind zusätzlich Kennzahlen für die Bestandsveränderung anzugeben. An dieser Stelle kann vorweggenommen werden, dass es für das SEM-BPS besser (flexibler) ist, alle Kennzahlen als Flussgrößen zu definieren. Des Weiteren wird über die Aggregation gesteuert, wie Kennzahlenwerte verdichtet werden sollen. Neben den Standardaggregationen Summe oder Minimal- bzw. Maximalwert können auch Ausnahmeaggregationen definiert werden. Mit Bezug zu einem Merkmal (z. B. Kunde) ist es dann beispielsweise denkbar, für die Kennzahl Umsatz direkt die Durchschnittsaggregation Umsatz pro Kunde zu ermitteln. Weitere Eigenschaften Analog zu den Merkmalen können hier auch Einstellungen für die Darstellung der Kennzahlen im Business Explorer bestimmt werden. Beispiele sind die Anzahl der Dezimalstellen oder die Skalierung (Zehner, Tausender usw). Abschließend ist die Kennzahl zu aktivieren InfoProvider Der InfoProvider umfasst alle Objekte des BW, auf denen Berichte, d.h. BEx Queries, angelegt und ausgeführt werden können. Das Objekt ist damit Datenlieferant (Provider) einer Query. Mit Bezug zur physischen Datenhaltung können die InfoProvider unterschieden werden in solche, die eine physische Datenhaltung zulassen, und solche, die nur eine logische Sicht darstellen. Objekte, in denen Daten physisch hinterlegt werden, tragen auch die Bezeichnung Datenziele. Dieser bereits in Abschnitt 3.1 mehrfach verwendete Ausdruck umfasst die nachstehenden Objekte: InfoProvider mit physischer Datenhaltung BW-Einstellungen Datenmodellierung 107

18 InfoObjekt (nur Merkmale) InfoCube ODS-Objekt Das InfoObjekt»Merkmal«(Kennzahl ist hier ausgeschlossen) ist nur dann als Datenziel zu bezeichnen, wenn es ausdrücklich als solches im System deklariert wird. InfoProvider ohne physische Datenhaltung InfoProvider, die keine physische Datenablage haben, sondern lediglich eine logische Sicht auf die Daten ermöglichen, setzen sich aus folgenden Objekten zusammen: InfoSets RemoteCubes SAP RemoteCubes Virtueller InfoCube mit Services MultiProvider Die Beschreibung der InfoProvider soll sich an dieser Stelle auf die für das Verständnis dieses Buches wesentlichen Objekte beschränken. Dies sind der InfoCube und der MultiProvider InfoCube Das zentrale Element, das im BW die meisten analytischen Funktionen bei der Auswertung und Speicherung der Bewegungsdaten bietet und auch aus Aspekten der Performance bevorzugt werden sollte, ist der Info- Cube. Aus der Sicht des Staging-Prozesses (siehe Abschnitte und 3.1.2) ist der InfoCube ein Datenziel. Aus der Sicht des BEx Analyzers ein InfoProvider. Als wesentliches BW-Objekt der Administrationsebene dient der InfoCube als zentraler Datenspeicher für Berichte und Auswertungen. Aufbau eines InfoCubes Ein InfoCube besteht aus InfoObjekten (Kennzahlen und Merkmale), die in Anlehnung an das in Abschnitt vorgestellte erweiterte Star- Schema angeordnet werden. Aus der Sicht der Modellierung setzt sich der InfoCube somit aus einer Faktentabelle mit den Kennzahlen und den Feldern für die Dimensions-Identifikationsnummern (DIM-ID) sowie aus den Dimensionstabellen mit den Merkmalen zusammen. Letztere verweisen wiederum auf SID-Tabellen, die sich außerhalb des Definitionsbereiches eines InfoCubes befinden. 108 SAP Business Information Warehouse

19 Das von der SAP vorgegebene technische Limit umfasst eine Faktentabelle mit bis zu 16 Dimensionstabellen je InfoCube. 3 der 16 Dimensionen sind bereits für die Dimensionen Zeit, Einheit und InfoPackage vorbelegt. Mit Bezug zum SEM-BPS sind zwei Arten von InfoCubes zu unterscheiden: der Basic InfoCube und der transaktionale InfoCube. Während der Basic InfoCube den einzigen für das BW entwickelten InfoCube darstellt, ist der transaktionale InfoCube erst später speziell für die Anforderungen des SEM-BPS entstanden. Der Unterschied zwischen beiden besteht darin, dass in einen Basic InfoCube Daten geladen werden können, während der transaktionale InfoCube dies nicht zulässt, dafür aber einen direkten Schreibzugriff aus dem SEM-BPS ermöglicht. Der Basic InfoCube ist demnach für das Laden von Massendaten im Rahmen des Staging-Prozesses ausgelegt, während der transaktionale InfoCube für die Belange des SEM-BPS optimiert ist. Während in älteren BW-Releaseständen InfoCubes entweder nur als BasicCube oder als transaktionaler Cube angelegt werden konnten, kann heute über ein Kennzeichen zwischen diesen beiden Definitionen gewechselt werden (zu allgemeinen Fragen zu den Auswirkungen, die eine Umstellung von Basic auf transaktionale InfoCubes mit sich bringt, siehe auch OSS-Hinweis ). Dies bedeutet, dass zu einem Zeitpunkt t Daten in den InfoCube geladen und zu einem anderen Zeitpunkt t+1 Planwerte über SEM-BPS-Funktionen in denselben InfoCube geschrieben werden können. Zwischen dem Zeitpunkt t und t+1 ist der Statuswechsel von»basic«zu»transaktional«vorzunehmen. Diese Einstellung erfolgt im Kontextmenü zum InfoCube, der wiederum über die Transaktion RSA11 selektiert werden kann. Im BW wird ein InfoCube immer mit Bezug zu einer InfoArea angelegt. Diese dient nur der Gruppierung inhaltlich zusammengehörender Info- Cubes. Der Begriff»inhaltlich zusammengehörend«ist sehr individuell auslegbar. Normalerweise werden InfoCubes nach betriebswirtschaftlichen Teilgebieten gruppiert. Basic InfoCube und transaktionaler InfoCube Statuswechsel»Basic«vs.»Transaktional«InfoCube im System anlegen Erst wenn alle für den InfoCube benötigten Merkmale und Kennzahlen im System angelegt worden sind, kann der InfoCube gepflegt werden. Abbildung 3.10 zeigt, wie Merkmale aus dem im BW vorhandenen Vorrat (rechte Bildhälfte) in den InfoCube übernommen werden können (linke Bildhälfte). BW-Einstellungen Datenmodellierung 109

20 Abbildung 3.10 Aufbau eines InfoCubes Einstellungen des InfoCubes im Detail Der InfoCube wird ausgehend von der Transaktion RSA11 bzw. ausgehend von dem Menüpfad SAP Menü Business Information Warehouse BW-Administration Administrator Workbench InfoProvider angelegt. Im Einzelnen sind die nachstehenden Registerkarten zu pflegen: Merkmale Aus dem Merkmalsvorrat (systemweit) lassen sich die Merkmale für den InfoProvider einzeln auswählen und übernehmen. Liegen Merkmalsklammerungen vor, werden die geklammerten Merkmale automatisch mit übernommen. Nach erfolgter Selektion der Merkmale sind diese in Anlehnung an die in Abschnitt beschriebene Logik des Star-Schemas Dimensionen zuzuordnen. Dazu sind über die Drucktaste Dimensionen die gewünschten Dimensionen zunächst anzulegen, um in einem zweiten Schritt die ausgewählten Merkmale mit den Dimensionen zu verknüpfen. Zeitmerkmale Die Einstellungen erfolgen analog zu der Auswahl der Merkmale. Auch sie sind Dimensionen (zumeist der Dimension»Zeit«) zuzuordnen. 110 SAP Business Information Warehouse

21 Kennzahlen Abschließend sind die gewünschten Kennzahlen auszuwählen. Im Unterschied zu den Merkmalen werden sie nicht Dimensionen zugeordnet. Gemäß des Star-Schemas sind sie direkt Bestandteil der Faktentabelle. Wie für die InfoObjekte»Merkmale«und»Kennzahlen«gilt auch für die InfoCubes, dass sie nach Fertigstellung zu aktivieren sind MultiProvider Der MultiProvider ist zwar für das SEM-BPS nicht weiter relevant, er ist jedoch an dieser Stelle zu definieren, da er in Kapitel 5 wieder aufgegriffen wird. Aufgabe des MultiProviders ist es, Daten aus verschiedenen Datenquellen, d.h. von verschiedenen Datenzielen, zu bündeln, um sie Berichten im BW zur Verfügung zu stellen. Neben den Datenzielen InfoObjekt (nur Merkmal), ODS-Objekt und InfoCube, die direkt Daten vorhalten, können auch über die logische Sicht des InfoSets Daten aus der Sicht des MultiProviders bezogen werden. Beim»Weiterreichen«der Daten von der Quelle bis in die Query werden diese nicht physisch in einem Multi- Provider zwischengespeichert. Das Konzept des BEx Analyzers sieht vor, dass eine Query grundsätzlich nur mit Bezug zu einem InfoProvider angelegt werden kann. Das Objekt MultiProvider ermöglicht somit, die systemseitige Einschränkung zu umgehen, indem Daten aus verschieden InfoProvidern gelesen werden können. Anwendung des MultiProviders Technische Einschränkung des BEx Wie sich in Kapitel 5 zeigen wird, ist der MultiProvider zwingend erforderlich, um die normalerweise in getrennten InfoCubes gehaltenen Istund Plandaten zusammen in einem Bericht auswerten zu können. 3.3 SEM-BPS-relevante Einstellungen im BW Da im Kontext dieses Buches nicht alle Bereiche des BW detailliert beschrieben werden können, sollen in diesem Kapitel nur solche Themen angesprochen werden, die im BW für das SEM-BPS zu beachten sind. Zum Teil handelt es sich um grundlegende Konzepte der Datenmodellierung, zum Teil auch»nur«um scheinbar unbedeutende Kennzeichen, die gerne übersehen werden, für ausgewählte Funktionen des SEM-BPS jedoch wesentlich sind. SEM-BPS-relevante Einstellungen im BW 111

22 Zunächst werden verschiedene Einstellungen im Bereich der Modellierung aufgezeigt. Es folgen zwei Einstellungen, die für Queries zu berücksichtigen sind. Abschließend wird auf den BW Business Content und seine Relevanz für das SEM-BPS eingegangen Modellierung: Kennzahlenmodell versus Kontenmodell In Abschnitt ist das Star-Schema mit der Faktentabelle vorgestellt worden. Es wurde in diesem Zusammenhang darauf hingewiesen, dass die zwei wesentlichen Objekte die InfoObjekte»Merkmal«und»Kennzahl«sind. Bisher ist jedoch nicht beschrieben worden, ob das Datenmodell mit möglichst vielen oder mit möglichst wenigen Kennzahlen aufgebaut werden soll. Es ist denkbar, dass man z.b. für die Ergebnisplanung für jede Kosten- und Erlösposition eine Kennzahl anlegt (d.h. eine Kennzahl für die Erlöse, eine weitere für die Kosten des Umsatzes, wiederum eine für die Vertriebsgemeinkosten usw.) und nur das Produkt und den Kunden (und eventuell weitere Auswertungsobjekte) als Merkmale führt. Es ist aber auch möglich, dass nur eine Kennzahl als»betrag«angelegt wird und über ein weiteres Merkmal in Verbindung mit dessen Ausprägungen bestimmt wird, welche Bedeutung dem Kennzahlenwert zukommt. Dies bedeutet: Legt man ein Merkmal als»ergebnisplanposition«mit den Ausprägungen»Erlöse«,»Kosten des Umsatzes«,»Vertriebsgemeinkosten«usw. an, wird durch die Kombination dieses Merkmalwertes und der Kennzahl»Betrag«der in der Faktentabelle gebuchte Wert immer eindeutig zuzuordnen sein. Kennzahlen- und Kontenmodell In dem zuerst beschriebenen Fall, d. h. viele Kennzahlen, spricht man vom Kennzahlenmodell. Derjenige Leser, der das CO-PA im SAP R/3 kennt, wird an dieser Stelle die Parallele zwischen den Kennzahlen und den Wertfeldern hergestellt haben. In diesem Sinne ist das CO-PA ein Kennzahlenmodell. Im zweiten Fall, in dem die Kennzahlen durch Merkmalsausprägungen eines Merkmals ersetzt werden, spricht man vom Kontenmodell. Das Kennzahlenmodell lässt die Faktentabelle»breit«werden, das Kontenmodell führt zu einer Ausdehnung der Faktentabelle in der Länge, d.h., die Anzahl der Datensätze in der Faktentabelle steigt. Das nun folgende Beispiel verdeutlicht den Zusammenhang (siehe Abbildung 3.11). Beispiel Ein Produkt 4711 soll mit folgenden drei Beträgen in Verbindung gebracht werden: ein Betrag von in Verbindung mit dem Konto 6000 für Bruttoerlöse, ein Betrag von in Verbindung mit 112 SAP Business Information Warehouse

23 dem Konto 6100 für Erlösschmälerungen und ein Betrag von für Kosten des Umsatzes (Konto 4000). Im Kennzahlenmodell ergibt sich daraufhin ein Datensatz in der Faktentabelle für die Kombination Produkt/Bruttoerlös/Erlösschmälerung/KdU mit 4711/ / / , d.h. bestehend aus einem Merkmal und drei Kennzahlen. Im Kontenmodell werden zwei Merkmale verwendet, Produkt und Konto, sowie eine Kennzahl Betrag. Es ergeben sich drei Datensätze in der Faktentabelle, jeweils bestehend aus der Kombination Produkt/ Konto/Betrag: 4711/6000/ , 4711/6100/ und 4711/ 4000/ Kennzahlenmodell Produkt Bruttoerlös Erlösschmälerung Kosten des Umsatzes Kontenmodell Produkt Konto Betrag Abbildung 3.11 Kennzahlen versus Kontenmodell Aus der Sicht des BW hat das Modell Auswirkungen auf die Performance. Tendenziell wird ein Kennzahlenmodell performanter sein als ein Kontenmodell. Diese allgemeine Aussage ist jedoch im Einzelfall zu überprüfen. In Abschnitt wird dieser Aspekt im Rahmen der Optimierung ausführlicher behandelt. Gleichzeitig wird auf den OSS-Hinweis verwiesen, der die Unterschiede an Zahlenbeispielen herausarbeitet. Aus der Sicht des SEM-BPS sind folgende Vor- und Nachteile aus der Perspektive des Kontenmodells zu berücksichtigen. Auch die einzelnen Begriffe des SEM-BPS erst in Kapitel 4 erläutert werden, sollen der Übersichtlichkeit halber die wesentlichen Punkte hier bereits aufgegriffen werden. Vor- und Nachteile aus der Sicht des BW Vor- und Nachteile SEM-BPS-relevante Einstellungen im BW 113

24 Vorteile Das Hinzufügen einer neuen Kennzahl, hier in Form einer Merkmalsausprägung, ist einfacher und schneller als das Anlegen einer neuen Kennzahl. Das Hinzufügen einer neuen Merkmalsausprägung ist einfacher im Hinblick auf die Planungsarchitektur. In der Planungsebene ist jede neue Kennzahl also explizit mit aufzunehmen, während dies für eine neue Merkmalsausprägung nicht der Fall ist. Das Hinzufügen einer neuen Merkmalsausprägung ist einfacher im Hinblick auf die Planungsfunktionen. Für Funktionen gilt generell, dass eine Kennzahl immer explizit auszuwählen ist. Bei»geschicktem«Design können solche Änderungen im Vorfeld dadurch verhindert werden, dass man im Rahmen der Merkmalseinschränkung keine Einzelwerte, sondern Intervalle oder Hierarchieknoten aus einer BW-Hierarchie angibt. Wenn die neue Merkmalsausprägung Teil des Intervalles ist, wird sie automatisch mit berücksichtigt. Dies ist bei Kennzahlen nicht möglich. Die»automatische«Berücksichtigung neuer Merkmalsausprägungen über Intervalle ist nur dann problemlos einsetzbar, wenn die Intervalle zuvor genau definiert worden sind und die entsprechende Definition auch eingehalten wird. Anderenfalls wird der hier angesprochene Vorteil schnell zum Nachteil. Der Pflegeaufwand für Formel-Fox-Funktionen (die in der Regel sehr häufig eingesetzt werden) ist beim Kontenmodell erheblich geringer. Im Fall des Planungslayouts ist je nach Design des Layouts die neue Kennzahl explizit als Spalte oder Zeile mit aufzunehmen, während eine Merkmalsausprägung in den meisten Fällen höchstens in der Planungsebene bzw. im Planungspaket anzugeben ist, falls die Selektion des Merkmals eingeschränkt war. Eine Reihe von Funktionen (insbesondere die betriebswirtschaftlichen Funktionen), die SAP im Standard zur Verfügung stellt, sind nur auf der Basis des Kontenmodells anwendbar. Für Merkmale können Variablen verwendet werden, für Kennzahlen nicht. 114 SAP Business Information Warehouse

25 Nachteile Das bereits angesprochene Performance-Problem wirkt sich nachteilig aus, da die Faktentabelle eventuell»aufgebläht«wird. Der Einsatz des Powersim zur Abbildung dynamischer Simulationsmodelle setzt das Kennzahlenmodell voraus. Dieser Nachteil kann jedoch durch ein»kippen«des Modells (d.h. vom Kennzahlen ins Kontenmodell) umgangen werden (siehe die Anmerkungen in Abschnitt zur Formel-Fox-Funktion). Darüber hinaus ist festzustellen, dass das Kennzahlenmodell auf 233 Kennzahlen je InfoCube systemseitig im BW begrenzt ist. Als Fazit kann man aus der Sicht des SEM festhalten, dass generell ein Kontenmodell zu bevorzugen ist. Im Einzelfall wie z. B. der Abbildung der Ergebnisplanung kann es sinnvoll sein, ein Kennzahlenmodell zu bevorzugen, insbesondere dann, wenn die Daten aus dem CO-PA des R/3-Systems in das BW extrahiert werden sollen. In dem Fall könnte die im SAP-System bestehende Datenstruktur im BW beibehalten werden. Die hier beschriebenen Aspekte werden an verschiedenen Stellen in Kapitel 4 wieder aufgenommen und zum Teil detailliert behandelt. Fazit: Kennzahlen- versus Kontenmodell Modellierung: weitere Aspekte Zwei weitere Aspekte sind in Bezug auf die Modellierung im BW und die SEM-BPS-Funktionen zu betrachten: Transaktionaler InfoCube Open Request Der transaktionale InfoCube wird an dieser Stelle der Vollständigkeit halber erneut erwähnt. Die Funktionsweise wurde bereits in Abschnitt beschrieben. Ein transaktionaler InfoCube ist die Voraussetzung dafür, dass SEM-BPS zum Einsatz kommen kann. Dies betrifft das Zurückschreiben von Daten in das BW, die über SEM-BPS-Funktionen entweder neu generiert oder verändert worden sind. Es betrifft nicht das Lesen von Daten im Sinne von Referenzdaten. Diese können auch aus einem Basic InfoCube gelesen und für SEM-BPS-Funktionen zur weiteren Verarbeitung bereitgestellt werden. Im Zusammenhang mit dem Zurückschreiben der Daten aus dem SEM-BPS in den transaktionalen InfoCube ist die BW-Funktion des Open Requests zu betrachten. Generell wird im BW mit jedem Ladeprozess (Staging) von Daten in einem InfoCube ein (»Lade«-)Request angelegt. Nach dem Ladeprozess wird dieser Request automatisch geschlossen und ist damit been- Transaktionaler InfoCube Open Request SEM-BPS-relevante Einstellungen im BW 115

26 det. Ein Ampelstatus zeigt den erfolgreichen Ladevorgang grün an. Werden Daten aus dem SEM-BPS in den transaktionalen InfoCube zurückgeschrieben, wird systemseitig automatisch ein Request analog zum Ladeprozess angelegt. Im Unterschied zu dem»lade-request«bleibt dieser jedoch so lange geöffnet, bis über das SEM-BPS Datensätze erzeugt worden sind. Danach wird der Request automatisch geschlossen und ein neuer geöffnet. Die Ampel steht solange der Request geöffnet ist auf Gelb. Da der Request eine Zeit lang geöffnet bleibt, wird von einem Open Request gesprochen. Abbildung 3.12 zeigt einen offenen Request. Die Übersicht der Requests zu einem InfoCube ist erreichbar über die Transaktion RSA11, indem der entsprechende InfoCube selektiert und über das Kontextmenü die Option Administrieren ausgewählt wird. Abbildung 3.12 Open Request im transaktionalen InfoCube Daten im ListCube überprüfen Es ist üblich, dass im Rahmen des Testens von SEM-BPS-Funktionen die Testergebnisse anhand des veränderten Datenbestands im transaktionalen InfoCube überprüft werden. Dazu ist die gleiche Transaktion RSA1 wie bei der Selektion der Request-Übersicht auszuführen. Von hier aus sind folgende Schritte durchzuführen: 116 SAP Business Information Warehouse

27 Schritt 1 Die Registerkarte Inhalt wird ausgewählt und anschließend die Drucktaste InfoCube-Inhalt auswählen. Schritt 2 Dieser Schritt ist nur dann auszuführen, wenn zu viele Felder zur Selektion vorhanden sind. In diesem Fall ist die Markierung der SID-Felder zu entfernen (dafür steht eine entsprechende Drucktaste zur Verfügung). Nach erfolgter Auswahl wird das Fenster Datenziel Browser, Selektionsbild angezeigt. Schritt 3 Über die Drucktaste Feldauswahl zur Ausgabe sind die Felder und Kennzahlen zu markieren, die später auch in der Ausgabe angezeigt werden sollen. Über den Zurück-Pfeil gelangt man wieder auf das vorhergehende Fenster. Schritt 4 In dem Fenser Datenziel Browser, Selektionsbild können die Merkmale unabhängig von der zuvor vorgenommenen Selektion eingeschränkt werden. Die Einschränkung sollte auf jeden Fall genutzt werden, wenn viele Daten in der Faktentabelle des InfoCubes sind. Als Ergebnis werden die aufgrund der vorgenommenen Selektion ermittelten Werte im ListCube dargestellt. Die Auswertungen der Daten über den ListCube werden zum einen an dieser Stelle erwähnt, weil jeder Anwender des SEM-BPS diese Funktion zum Nachvollziehen von Testergebnissen kennen sollte, zum anderen ist darauf hinzuweisen, dass in Verbindung mit dem Open Request die aktuellsten Daten in Queries nicht immer angezeigt werden. Sollte man deshalb im Rahmen eines Tests den Eindruck gewinnen, dass Daten nicht im ListCube angezeigt werden, obwohl sie im offenen Request sein sollten, wird die Schließung des Requests empfohlen. Dazu ist über die Transaktion SE37 der Report RSAPO_CLOSE_TRANS_REQUEST zu starten Präsentationsebene: Kennzeichen ODBO und Variable 0S_RQMRC Auf der Präsentationsebene gibt es aus der Sicht des SEM-BPS zwei Details, die berücksichtigt werden müssen: Die Variable 0S_RQMRC Das Kennzeichen»Freigegeben für OBDO«SEM-BPS-relevante Einstellungen im BW 117