Inhaltsverzeichnis

Einleitung

Die Einsatzmöglichkeiten von Business Intelligence nehmen von Jahr zu Jahr zu. Nicht umsonst wird von einem Multi-Milliardenmarkt gesprochen. Doch wo soll man als Neuling in diesem Gebiet einsteigen? Zahlreiche Bücher gibt es inzwischen auf dem Markt, und jeden Monat erscheinen neue. Da fällt die Auswahl schwer.

Ich möchte Ihnen daher zunächst beschreiben, was Sie in diesem Buch erwarten dürfen, und für welche Fragestellungen Sie eher zu anderen Werken greifen sollten. Dieses Buch richtet sich an Neueinsteiger in oder Umsteiger von einer anderen Plattform auf SAP Business Warehouse (BW). Sie sollten allerdings mit der aktuellen Version der SAP GUI for Windows vertraut sein und wissen, wie Sie sich am SAP BW-System in Ihrer SAP-Systemlandschaft anmelden müssen. Hilfreich wäre, wenn Sie hier bereits über erste Erfahrungen sowie über ausreichend Berechtigungen verfügen, um eigene Objekte in der Data Warehousing Workbench anlegen zu dürfen. Ihre SAP-Basis beziehungsweise zahlreiche Bücher zu diesem Thema können Ihnen hier weiterhelfen.

Was genau erwartet Sie hier? Zu jedem Fachbuch gehört ein bisschen Theorie. So steigen wir auch hier zunächst mit einem Theorieteil ein, in dem ich die beiden Begriffe Business Intelligence und Data Warehouse erkläre. Ferner stelle ich die wichtigsten allgemeinen Data-Warehouse-Konzepte vor, wie die Corporate Information Factory von Bill Inmon und die Layered Scalable Architecture der SAP. Außerdem erhalten Sie einen kurzen Überblick über die Geschichte des SAP Business Warehouse. Mit dem Zukauf von Business Objects 2008 tritt eine weitere Facette auf. Diesem Thema sowie der Unterscheidung zwischen SAP Business Warehouse und SAP BusinessObjects Business Intelligence ist jeweils ein kurzer Abschnitt gewidmet. Abschließend gebe ich einen Ausblick auf die aktuellen Herausforderungen im Bereich Business Intelligence und Data Warehouses und darauf, wo die Reise in Zukunft möglicherweise hingehen kann.

Im zweiten Kapitel erwartet den Leser ein Fallbeispiel aus der Pharmabranche. In diesem Industriezweig werden meist IMS Health-Daten benutzt, die über Verkaufszahlen der einzelnen Pharma-Produkte während der letzten 18 Monate informieren. Die Daten sind in Tabellenform verpackt und wirken auf den ersten Blick eher abschreckend. Die Aufgabenstellung wird lauten, aus diesen Informationen einen Bericht mit den Top 3-Produkten »unseres« Unternehmens zu erstellen sowie den Anteil der eigenen Produkte am Gesamtmarkt zu bestimmen. Um die Datenmenge klein zu halten, wird auf einer reduzierten Datenbasis gearbeitet und mit Pseudo-Umsätzen und Beispielmaterialien gearbeitet. Nach der Lektüre sollten Sie dennoch in der Lage sein, die echten IMS Health-Daten in Ihr SAP BW-System zu laden.

In Kapitel 3 erfahren Sie, was genau die Data Warehousing Workbench ist und wozu Sie sie benötigen. Ferner gehe ich auf Datenflussdiagramme ein, die als Modellierungselement mit BW 7.3 neu hinzugekommen sind. Ich erläutere Ihnen, wie Sie Datenflussdiagramme nutzen, um iterativ ein Datenmodell zur Lösung des Fallbeispiels entwerfen zu können.

Im Kapitel 4 erläutere ich, wie Sie InfoObjects, Data Store Objekte, InfoCubes und MultiProvider zur Lösung des Fallbeispiels anlegen müssen. Da es sich hier um ein Tutorial handelt, stelle ich nicht die gesamten Details und alle zusätzlichen Optionen der einzelnen Objekte dar, sondern verweise an diesen Stellen auf die entsprechende Standardliteratur.

Nachdem das Datenmodell aufgestellt ist, muss es mit Daten gefüllt werden. Hierzu zeige ich Ihnen im Kapitel 5 die nötigen Schritte, wie Sie die Daten in Ihr BW laden können. Dabei beschränke ich mich auf die beiden Möglichkeiten der Transformationen und Datentransferprozesse. Ältere Methoden wie Fortschreibungsregeln oder Übertragungsregeln behandele ich nicht.

SAP BW basiert, wie jedes SAP-System, auf der Programmiersprache ABAP bzw. der objekt-orientierten Erweiterung ABAP/OO. An einzelnen Stellen wird hier ABAP eingesetzt, ist jedoch keinerlei Voraussetzung. Alle wichtigen Codes bietet Espresso Tutorials für Sie im folgenden Downloadbereich: http://BW.espresso-tutorials.com.

Nachdem die Daten im InfoCube geladen sind, können sie per Query ausgewertet werden. In Kapitel 6 erläutere ich Ihnen, wie Sie den BEx Query Designer zur Erstellung der Abfragen nutzen. Auf seine vielfältigen Möglichkeiten kann nicht detailliert eingegangen werden. Nur insoweit es für die Musterlösung nötig ist, werde ich die wichtigsten Funktionen anhand von Screenshots zeigen. Als Ausgabemedium der Abfragen beschränke ich mich in diesem Buch ausschließlich auf den Business Explorer Analyzer zur Dokumentation der Ergebnisse in Excel. Auf eine Darstellung der Abfrageergebnisse in den Business Objects Tools wird im Rahmen dieser konzentrierten Abhandlung verzichtet.

Für Aspekte der generellen Administration des SAP BW empfehle ich das Buch »SAP Netweaver BW – Administration« von Olaf Klostermann und Mirco Österholm (Galileo Press). Zum Thema Performance Ihres SAP BW verweise ich auf das Buch »Performance-Optimierung für SAP^© BW« von Helmut Tack (Espresso Tutorials).

Jetzt wünsche ich allen Lesern eine spannende Reise durch das SAP Business Warehouse!

Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, der diesen genauer klassifiziert:

Zum Abschluss der Einleitung noch ein Hinweis zum Copyright: Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP AG. Alle Rechte an den Screenshots liegen bei der SAP AG. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, darauf unter jedem Screenshot gesondert hinzuweisen.

1   Business Intelligence

In diesem Kapitel erläutere ich zunächst die Begriffe Business Intelligence und Data Warehouse. Dabei steht die grundlegende Idee der Corporate Information Factory von Bill Inmon im Fokus, die als Vorlage für die Umsetzung in SAP Business Warehouse (BW) diente.

1.1   Die Bedeutung von Business Intelligence

Amazon hat es erfolgreich in seinem Geschäftsmodell eingesetzt: das sogenannte Cross- und Upselling aus Sicht des Marketings und Vertriebs. Gemeint ist mit Cross-Selling Folgendes: Registrieren Sie sich auf der Internetseite von Amazon als Benutzer und stöbern Sie nach interessanten Büchern, so speichert Amazon die Treffer Ihrer Suche. Sobald Sie das nächste Mal auf die Seite gehen, schlägt Ihnen Amazon weitere Titel vor, die zu Ihren Interessen passen. Unter Upselling ist dagegen zu verstehen, dass Ihnen während Ihrer Suche ein teurerer Artikel oder ein Set, das den gewünschten Artikel enthält, vorgeschlagen werden.

Die Frage ist: Wie bringe ich als Unternehmen meine Kunden dazu, beim nächsten Besuch nicht nur den gewünschten, sondern eventuell weitere Artikel zu kaufen? Amazon hatte hier die entscheidende Idee: Wenn es gelingt, die Suchanfrage der Benutzer zu speichern, über einen Algorithmus verwandte Ergebnisse zu finden und sie dem Interessenten vorzuschlagen, kauft der Kunde eventuell mehr als nur einen Artikel. Die Umsetzung erfolgt mittels einer sogenannten Recommendation Engine (vergleiche Abschnitt »Literaturhinweise«, Punkt 1) bzw. eines Empfehlungsdienstes. Im Hintergrund werden dabei Methoden des Data-Minings aufgerufen, die verwandte oder ergänzende Produkte ermitteln. Data-Mining und Recommendation Engines sind die bekanntesten Beispiele für den Einsatz von Business Intelligence.

Das Gabler Wirtschaftslexikon definiert Business Intelligence als »Sammelbegriff für den IT-gestützten Zugriff auf Informationen, sowie die IT-gestützte Analyse und Aufbereitung dieser Informationen. Ziel dieses Prozesses ist es, aus dem im Unternehmen vorhandenen Wissen, neues Wissen zu generieren. Bei diesem neu gewonnenen Wissen soll es sich um relevantes, handlungsorientiertes Wissen handeln, welches Managemententscheidungen zur Steuerung des Unternehmens unterstützt.« (vergleiche Abschnitt »Literaturhinweise«, Punkt 2)

Business Intelligence ist somit weit mehr als die Abfrage von Tabellen und das Anzeigen der Ergebnisse in einer geeigneten Benutzeroberfläche. Vielmehr ist eines der Ziele, durch den Einsatz von Business Intelligence-Tools und -Methoden neue Zusammenhänge zwischen Daten zu entdecken. Dies können die Erschließung neuer Kundenfelder oder die Nutzung alternativer Vertriebswege sein. Für ein Unternehmen bedeutet dies, schneller und besser Entscheidungen treffen zu können, da verschiedene Facetten der Fragestellung analysiert werden können. Für Unternehmen wird die Geschwindigkeit, die richtigen Entscheidungen zu treffen, im Angesicht der Globalisierung zum entscheidenden Wettbewerbsfaktor.

Ein weiteres Beispiel für den Einsatz von Business Intelligence im Unternehmen ist die Erstellung der Jahresbilanz sowie der Gewinn- und Verlustrechnung (GuV). Für globale Unternehmen besteht die Herausforderung darin, die Einzelabschlüsse der Tochtergesellschaften zu einer Konzernbilanz zusammenzuführen. Dies kann nur gelingen, wenn das Unternehmen in der Lage ist, die Einzelabschlüsse aus den informatorischen Vorsystemen in einem Konzernsystem in geeigneter Art und Weise zu aggregieren. Die Plausibilitätsprüfung der Daten, das Laden der Bilanzen und GuV aus den verschiedensten Vorsystemen sowie die anschließende Konsolidierung zu einer einheitlichen Bilanz und GuV erfolgen meistens in sogenannten Data Warehouses.

Ein Data Warehouse ist in der Lage, große Datenmengen in einer Datenbank zu speichern und in möglichst kurzer Zeit Rechenoperationen oder Abfragen sehr großer Datenmengen performant auszuführen. 1988 stellte IBM als erstes Unternehmen ein Data Warehouse vor.

1.2   Data Warehouse

Das Gabler Wirtschaftslexikon definiert Data Warehouse als »eine von den operativen Datenverarbeitungssystemen separierte Datenbank, auf die nur Lesezugriff besteht. In regelmäßigen Abständen werden aus den operativen DV-Systemen unternehmensspezifische, historische und daher unveränderliche Daten zusammengetragen, vereinheitlicht, nach Nutzungszusammenhängen geordnet, verdichtet und dauerhaft in der Datenbasis des Data Warehouse archiviert. Ziel ist die Verbesserung der unternehmensinternen Informationsversorgung (Wissensmanagement) und damit der Unterstützung strategischer Entscheidungen. Als analytisches System liefert es Informationen zur Problemanalyse – Online Analytical Processing (OLAP) –, die durch die Anwendung von Methoden (z.B. des Data Mining) generiert werden.« (vergleiche Abschnitt »Literaturhinweise«, Punkt 3)

Die Daten aus den operativen Systemen werden in mehreren Schritten verdichtet, vereinheitlicht und geordnet, bis sie für das Berichtswesen im Management den geforderten Aggregierungsgrad haben. Viele Unternehmen betreiben daher in der Praxis ein mehrschichtiges Data Warehouse, wie in Abbildung 1.1 dargestellt.

Abbildung 1.1: Schichtenarchitektur eines Data Warehouses

Die unterste Ebene enthält sehr detailliert operative Daten aus den angeschlossenen Vorsystemen. Meist finden sich hier die einzelnen Belege wie Bestellungen, Kundenaufträge oder auch Buchungsbelege aus der Finanzbuchhaltung. In der Ebene »Business Transformation« werden die operativen Daten interpretiert, harmonisiert und auf eine höhere Stufe aggregiert. So könnte das etwa bedeuten, dass nicht mehr der einzelne Buchhaltungsbeleg betrachtet, sondern z.B. ein Kontensaldo ermittelt wird. Auf dieser Ebene sind zusätzliche Ableitungs- oder Zuordnungsregeln gepflegt, nach denen die Daten gegliedert werden. Hier kann hinterlegt werden, welche Konten einer Tochtergesellschaft welchen Konten des Konzerns zugeordnet sind. Nach der Business Transformation werden die Daten an die Reporting-Ebene weitergeleitet. Dort stehen sie für das Berichtswesen zur Verfügung. Meist werden die Daten auf der obersten Ebene weiter verdichtet, um ein leistungsstarkes Berichtswesen zu ermöglichen. Hier können letztlich die konsolidierte Bilanz des Konzerns sowie, bei Bedarf, die Bilanzen der Tochtergesellschaft abgerufen werden.

Aus dieser Übersicht wird deutlich, dass die Daten in einem Data Warehouse oft redundant gespeichert werden, was einen hohen zusätzlichen Speicherbedarf erfordert. Andererseits bietet sich durch den Einsatz eines Data Warehouses die Möglichkeit, auf vereinheitlichten und hoch aggregierten Daten zu berichten. Dies entlastet die operativen Systeme.

Mit ihrem zunehmenden Praxiseinsatz wuchs die Erkenntnis, dass Data Warehouses eine spezielle Architektur erfordern, um Insellösungen und Datensilos zu vermeiden.

1.3   Die Corporate Information Factory

Im Jahr 1996 war es Bill Inmon vorbehalten, die Idee einer Corporate Information Factory (CIF) zu veröffentlichen. Sie ist in Abbildung 1.2 dargestellt:

Abbildung 1.2: Corporate Information Factory

Kernidee der Corporate Information Factory ist, dass Daten in einem Enterprise Data Warehouse (EDW) abgelegt werden können und dort nachgelagerten Systemen für Auswertungen zur Verfügung stehen. Im ersten Schritt werden die Daten aus verschiedensten Vorsystemen oder Applikationen extrahiert und in einer Staging Area gespeichert. Aus dieser Staging Area können die Daten im nächsten Schritt per Extraktion, Transformation und Laden (ETL) weiter homogenisiert und verdichtet werden, oder es lassen sich weitere Zusammenhänge zwischen den Daten ableiten. Im Anschluss an das ETL werden die Daten meist in verschiedenen Data Marts des Enterprise Data Warehouses gespeichert. Ein Data Mart kann dabei einerseits eine persistente, anwendungsspezifische Sicht, andererseits eine persistente Sicht auf die Daten sein, die für einen bestimmten Organisationsbereich erstellt wird.

Im Zentrum der CIF steht das Enterprise Data Warehouse, das die Daten an nachgelagerte Systeme weiterliefert. Dies können Decision Support Systeme oder sogenannte Departmental Data Marts, also abteilungs- oder fachspezifische Data Marts, sein. Die Daten im EDW erfüllen folgende Eigenschaften:

• granular,
• integriert,
• historisch.

Nach diesem Ausflug in die allgemeinen Grundlagen des Data Warehouses möchte ich im nächsten Abschnitt das SAP Business Warehouse vorstellen.

1.4   SAP Business Warehouse

Parallel zur Entwicklung der ersten Data Warehouses stiegen, bedingt durch den Siegeszug von SAP R/3 zur unternehmensweiten Ressourcenplanung, die Anforderungen im unternehmensinternen Berichtswesen. Mithilfe des herkömmlichen ERP-Systems waren diese Anforderungen nur schwer zu erfüllen.

In der ersten Hälfte des Jahres 1997 ging das SAP Business Information Warehouse 1.2A für wenige ausgewählte Kunden an den Start. Bill Inmon hatte mit seiner CIF dazu architektonisch die Vorarbeit geleistet. SAP griff seine Idee auf und nutzte sie für die generelle Strukturierung und Modellierung des eigenen Business Warehouse. Die Prozessierung der Daten über Extraktion aus den angeschlossenen Quellsystemen bis hin zum Bereitstellen in Data Marts heißt Staging. In Anlehnung an das CIF läuft das Staging im SAP Business Warehouse nach dem in Abbildung 1.3 gezeigten Schema ab:

Abbildung 1.3: Staging im SAP Business Warehouse

Die Eingangsebene der Daten bildet die Persistent Staging Area (PSA). Dies sind flache Tabellen, in denen die Daten aus dem Vorsystem unverändert abgelegt und im nächsten Schritt aus der PSA über Methoden der Extraktion, Transformation und des Ladens (ETL) an das Enterprise Data Warehouse übertragen werden.

Die Begriffsbildung des Enterprise Data Warehouses im Zusammenhang mit SAP BW hat sich allerdings erst in den letzten Jahren etabliert und meint eine mehrstufige Schichtenarchitektur zur Modellierung und Speicherung der Daten. Kleinstes Element der Modellierung stellt das sogenannte InfoObject dar. InfoObjects können wiederum in Merkmale und Kennzahlen unterschieden werden.

Als Methoden der Datenverarbeitung stehen im SAP Business Warehouse Übertragungs- und Fortschreibungsregeln oder Transformationen zur Verfügung. Als Lademethoden dienen das sogenannte Infopackage sowie der Datentransferprozess. Datenziele einer Transformation heißen im SAP Business Warehouse allgemein InfoProvider. Die beiden wichtigsten Typen der InfoProvider sind die Data Store Objects und sogenannte InfoCubes. Data Store Objects sind im Wesentlichen flache Tabellen. InfoCubes sind in einer für die mehrdimensionale Analyse optimierten Datenstruktur auf der Datenbank gespeichert. Für die mehrdimensionale Analyse hat sich das »Snowflake-« oder Sternschema durchgesetzt.

Im Zentrum des Sternschemas steht die Faktentabelle. Sie enthält alle Kennzahlen, wie beispielsweise Brutto-Umsatz, Netto-Umsatz oder Verkaufsmenge in Stückzahl. Um die Faktentabelle sind Dimensionstabellen gereiht