Dieser Abschnitt beschreibt den Prozess von der Gewinnung der Daten bis hin zu einem effizienten Reporting. Daneben erhalten Sie in diesem Abschnitt eine Einführung in die wichtigsten Begriffe und Konzepte in diesem Bereich.

Data Acquisition und Data Warehousing

Am Anfang jeder Art von Analyse in SAP BI steht ein Datenbestand in einem Datenspeicher, der zunächst aus unterschiedlichen Quellsystemen erzeugt werden muss. Dazu müssen im Quellsystem Tabellenfelder ausgelesen werden – beispielsweise die Summensatztabellen aus dem neuen Hauptbuch in SAP ERP: Bewegungsdaten sind in diesem Zusammenhang etwa die Beträge in lokaler Währung. Die Kontierung auf Sachkonten und CO-Objekte (Kostenstellen/Innenaufträge usw.) dagegen repräsentiert Stammdateninformationen. Die benötigten Stammdaten- und Bewegungsdaten- Informationen müssen nun in geeignete Datenziele in SAP BI übergeben und gespeichert werden. Dann können Datenbankabfragen darauf zugreifen und die Daten am Bildschirm ausgegeben werden.

Das klingt eigentlich simpel, allerdings müssen, damit die Datenlogistik zwischen Quellsystem und SAP BI gewährleistet ist, systemseitig sowohl im Quellsystem als auch in SAP BI noch einige Zwischenschritte definiert werden und Voraussetzungen erfüllt sein.

Erstens müssen in SAP BI die benötigten Datenziele vorhanden sein. Datenziele sind Tabellen, in denen Stammdaten und Bewegungsdaten im BI physisch abgelegt werden. Sie bestehen grundsätzlich aus kleinen Bausteinen, den so genannten InfoObjects. Hier gilt es zwei Typen zu unterschieden:

* Merkmale (z.B. Kunde, Konto, Kostenart, Kostenstelle)

* Kennzahlen (beispielsweise Liefermenge, Betrag in Hauswährung, Betrag in Transaktionswährung)


InfoObjects werden unabhängig von einzelnen Informationsmodellen angelegt und können in beliebig vielen Tabellen verwendet werden. Der Hintergrund dieses Verfahrens ist klar: Damit können Merkmale – z.B. Konten – unabhängig von ihrer Verwendung in einzelnen Datenspeichern gepflegt oder geladen werden; das Ergebnis steht dann in jedem Kontext, in dem das Merkmal verwendet wird, zur Verfügung.Folgende BI-Objekte repräsentieren Datenziele:

* InfoCubes für die mehrdimensionale Speicherung von voraggregierten Daten
* ODS-Objekte (ODS = Operational Data Storage) bzw. DSO-Objekte (DSO = Data Storage Object) für die Speicherung von Daten auf Belegebene; seit NetWeaver 2004s werden ODS-Objekte als DSOs bezeichnet
* Merkmalstabellen für die Speicherung der Stammdateninformationen und der beschreibenden Attribute


Zweitens muss im Quellsystem sowohl für die Stammdaten als auch die Bewegungsdaten festgelegt sein, welche Tabellen und Tabellenfelder überhaupt ausgelesen werden sollen und um welche Datentypen es sich dabei handelt. Diese Informationen sind Bestandteil einer Tabellenstruktur, der so genannten DataSource, die dann in SAP BI repliziert wird – man spricht hier auch von einem Metadaten-Transfer. Die DataSource dient dazu, beim eigentlichen Ladevorgang die ankommenden Daten in der Struktur des Quellsystems zu identifizieren.


Drittens müssen Regeln mit Abbildungsvorschriften für den Transfer der Daten in die Tabellenstrukturen im Zielsystem definiert werden, denn typischerweise sind die Tabellenfelder im Quellsystem als Herkunftsobjekte ganz anders bezeichnet als die InfoOjects in SAP BI als Empfänger- Objekte. Während beispielsweise in der SAP ERP-Kostenstellenrechnung CO-OM der Feldname für die Kostenstelle KOSTL lautet, wird in SAP BI häufig das Merkmal 0COSTCENTER zur Abbildung der Kostenstellen genutzt.


Die Definition dieser Abbildungsvorschriften erfolgt in SAP BI, basierend zum einen auf der DataSource, die ja die Datenstruktur aus dem Quellsystem repräsentiert, zum anderen basierend auf den Tabellenstrukturen in SAP BI.


Harmonisierung

Auf die ankommenden Daten werden vor allem dann noch zusätzliche Transformationsschritte angewendet, wenn sie aus unterschiedlichen Quellsystemen stammen. Da SAP BI als »Single Point of Truth« fungieren soll, müssen Sie die unterschiedlichen Merkmalsausprägungen vereinheitlichen. Sinnvollerweise erfolgt dies, bevor die Daten abschließend in den Datenzielen verbucht sind – daher werden solche Transformationen oft als Routinen im Zusammenhang mit den Transferregeln hinterlegt und angewendet. Zunehmend mehr Kunden wenden auch so genannte Enterprise- Data-Warehouse-Konzepte an. Im Kontext von SAP BI bedeutet das, dass Daten aus unterschiedlichen Quellen zunächst mit möglichst hoher Granularität in ODS-Objekte gespeichert und dort harmonisiert werden. Danach können Sie die harmonisierten Daten für das Reporting aggregiert nach unterschiedlichen Sichten in InfoCubes übernehmen und darauf Ihre Analysen aufbauen.


Extraktoren

Erst wenn alle Voraussetzungen erfüllt sind, können die Daten in das SAP BI-System geladen werden. Dazu werden aus SAP BI so genannte Extraktoren in den Quellsystemen angestoßen und die Extraktion gestartet. Extraktoren sind Programmbausteine, die in den Quellsystemen die benötigten Daten entsprechend den in der DataSource enthaltenen Strukturinformationen auslesen und an SAP BI übergeben. Die ankommenden Daten werden gemäß der gepflegten Abbildungsvorschriften auf die InfoObjects abgebildet und in den Datenzielen verbucht und gegebenenfalls partitioniert, aggregiert und verdichtet.

Damit ist die eine Seite der Medaille – die Bereitstellung eines Datenbestands für die Analyse – knapp, aber für die Zwecke dieses Buches hinlänglich und beschränkt auf einen einfachen Standardprozess, beschrieben. Die andere Seite der Medaille ist die Analyse selbst: Wie kommen die Daten in einer bestimmten Weise auf den Bildschirm? Dabei müssen Sie zwei Aspekte unterscheiden: Die rein berichtsorientierte Darstellung von Daten in einer Analyseumgebung wird in SAP BI durch ein breites Spektrum von Werkzeugen aus der BI Suite abgedeckt.

Daneben enthält die BI Platform Zusatzfunktionalitäten für die besonders pointierte Hervorhebung von Sachverhalten durch Alerts, für die methodisch- statistische Gewinnung von versteckten Informationen aus einem Datenbestand oder für die planerische Gestaltung von Daten.

Martin Strohmeier und Jörg Siebert  I  Quelle: SAP PRESS Buch mySAP ERP Financials"