Heute zweifelt wohl niemand mehr ernsthaft am Sinn und Zweck eines Data-Warehouse-Ansatzes. Anwender analytischer Informationssysteme erzeugen Informationen aus den bereitgestellten Datenbeständen, die im Unternehmensalltag längst unverzichtbar geworden sind. Dabei sind die Bedürfnisse der einzelnen Anwendergruppen recht vielfältig. Dementsprechend bunt ist auch der Reigen an Business-Intelligence-(BI-)Tools in den Firmen. So führte eine Umfrage, die das Kompetenzzentrum "Data Warehousing 2" (CC DW2) der Universität St. Gallen unter den Partnerunternehmen zum Thema Vielfalt der BI-Werkzeuge durchgeführt hat, zu folgender Aussage: "Irgendwo kann man bei uns wohl fast jedes BI-Tool finden!"

Die hohe Komplexität auf der Seite der Quelldatensysteme wird häufig durch die Heterogenität der Systeme erzeugt und durch die Schwerfälligkeit bei der Ablösung der Altsysteme noch verstärkt. Zu den neueren Anforderungen an die Data-Warehouse-Systeme gehören zudem die Anbindung beziehungsweise Nutzung des Data Warehouse auch im Zusammenspiel mit operativen ("horizontalen") Applikationen wie Customer-Relationship-Management (CRM), Call-Center oder E-Business-Anwendungen. Dabei wird zudem auch ein "Closed-Loop-Konzept" diskutiert, das eine klare Trennung von operativen Systemen und Data Warehouse in Frage stellt. Eine weitere Herausforderung ist die unternehmensübergreifende Data-Warehouse-Kopplung.

Diese Anforderungen zu erfüllen, bedeutet einen erheblichen Aufwand bei der Entwicklung und dem Betrieb einer entsprechenden Informationslogistik, verbunden mit immensen Kosten und einer Komplexität, die auf lange Sicht nur schwer zu handhaben ist.

StandardlösungenDen finanziellen und zeitlichen Aufwand vor Augen, setzt man zunehmend auf Alternativen. Probate Mittel scheinen hier vor allem Standards wie der Metadatenstandard CWM der OMG und XML als Standardformat für den Datenaustausch sowie leistungsfähige Entwicklungswerkzeuge, etwa ETL-Tools (Extraktion, Transformation, Loading). Mittlerweile gibt es eine Vielzahl von Werkzeugen, die zumindest große Teile der Entwicklung und des Betriebs einer Data-Warehouse-Lösung übernehmen können.

Einen Schritt weiter geht der Versuch, eine Art Data-Warehouse-Standardsoftware anzubieten - in der Hoffnung, den hohen Aufwand mit Hilfe einer zumindest weit gehend fertigen Lösung zu reduzieren und nicht zuletzt auch das Risiko eines gescheiterten Projekts einzudämmen. Das SAP Business Information Warehouse (SAP BW) ist ein solcher Ansatz. Für wen dieser in Frage kommt und welcher Aufwand damit tatsächlich verbunden ist, soll im Folgenden aufgezeigt werden.

Die Data-Warehouse-Architektur lässt sich grob in die drei Hauptbestandteile unterteilen: die Datenquellsysteme, das Data Warehouse und die Analytischen Informationssysteme beziehungsweise BI-Tools.

Zunächst stellt sich die Frage, welche Daten überhaupt in das Data Warehouse integriert werden sollten. Grundsätzlich kommen hierfür Daten aus unternehmensinternen und -externen Systemen in Frage. Letztere lassen sich in operative und nicht-operative unterteilen. Dabei liegen die Daten in strukturierter, semistrukturierter oder unstrukturierter Form vor. Den Kern bilden in der Regel die strukturierten Daten aus den internen operativen Systemen. Beispiele hierfür sind etwa Kundendaten, die durch unzählige Attribute beschrieben werden können - also genau die Daten, die hauptsächlich im R/3-System vorliegen.

DatenquellsystemeDie wichtigste Datenquelle des SAP BW bildet das SAP-R/3-System. Wie in den meisten Data Warehouses bilden auch hier die internen operativen Systeme, die OLTP-Systeme (Online Transaction Processing), das Grundgerüst der Data-Warehouse-Datenbasis, denn die OLTP-Daten sind von besonderem Interesse für das Unternehmen, "relativ" leicht verfügbar und in der Regel deutlich strukturiert. Enterprise-Resource-Planning-(ERP-)Systeme zeichnen sich insbesondere im Datenbereich durch gute Integrationsfähigkeiten aus. Genau hier liegen bekanntermaßen die Stärken von SAP R/3. Der Integrationsaufwand steigt jedoch mit den Anpassungen am SAP-System. Und Abweichungen vom Standard gibt es laut SAP in großen Unternehmen, für die das SAP BW konzipiert wurde, immer: "Das BW ist kein ''Ready-to-go-Warehouse'', es ist eine IT-Strategie", wirbt ein Firmensprecher.

Bei der Extraktion der Quelldaten von R/3 in das BW gibt es zwei Vorteile. Zum einen können die Metadaten, also auch sämtliche Strukturen, ausgelesen und somit sowohl für die Extraktion als auch für deren Basis verwendet werden. Zum anderen lassen sich dadurch notwendige Anpassungen bei einem Versionswechsel deutlich reduzieren.

Data WarehouseDas Data Warehouse besteht in der Regel aus verschiedenen Schichten. Das Kern-Data-Warehouse bildet die Schicht, in der die Daten in einem gemeinsamen Datenmodell vorliegen. Dabei ist es von Vorteil, wenn dieses Datenmodell noch unabhängig von bestimmten Analyseformen oder -Tools ist und einen möglichst hohen Grad an Semantik abbildet. Auf dieser Ebene sollten die Historisierung und Versionierung sowie die Anbindung derjenigen Daten erfolgen, die sich etwa bei einer multidimensionalen Analyse nicht sinnvoll verwenden lassen. Diese Schicht wird von Barry Devlin (siehe Kasten "Literatur") treffend als Reconciled Data Layer (RDL) bezeichnet. Hier steht vor allem der Integrationsgedanke des Data Warehouse im Vordergrund.

Der Kernschicht können eine Staging Area und/oder ein Operational Data Store (ODS) vorgelagert sein. In der Staging Area werden die Quelldaten häufig in einem ersten Schritt geladen, um dann auf einfachere Weise transformiert oder für den Reconciled Data Layer aufbereitet zu werden. Außerdem lassen sich die Daten dort - im Sinne einer besseren Ladeverteilung - in kurzen Zyklen ablegen. Der Ladeprozess in den RDL findet dann zeitverzögert statt - etwa sobald alle zu integrierenden Daten vollständig in der Staging Area vorhanden sind.

Der ODS kann als eine Art operatives Data Warehouse aufgefasst werden. Indem er die operativen Daten integriert, lassen sich diese für andere operative Anwendungen, etwa CRM- oder Online-Banking-Applikationen, gemeinsam nutzen. Zudem wird ein ODS meist aktuellere Daten als das Data Warehouse beinhalten und ist daher eine Quelle für kurzfristige, hoch aktuelle Auswertungen.

Beim SAP BW sind diese Schichten prinzipiell auch vorhanden. Die unterste Schicht bildet die Persistant Staging Area (PSA). In die PSA werden die Daten aus R/3 unverändert geladen und in relationalen Tabellen abgelegt. Die Daten durchlaufen beim Ladevorgang keinerlei Übertragungsregeln. Eine Lastenverteilung mit Hilfe der PSA ist möglich.

Bei der Integration von Nicht-R/3-Daten können Flat Files entweder direkt importiert werden, oder die Daten werden mit Hilfe eines ETL-Tools überführt - eine bei herkömmlichen Data Warehouses häufig angewandte Methode.

Im ODS des BW werden die Daten bereinigt, vereinheitlicht und integriert. Abhängig vom Grad der Integration unterschiedlicher Datenquellen steigt hierbei der Aufwand. An dieser Stelle sollte der Einsatz eines Data-Cleansing-Tools möglich sein. Erfahrungsgemäß ist Data Cleansing nicht nur bei der Integration von R/3- mit anderen Daten notwendig. Auch innerhalb des R/3-Datenbestands können - etwa durch Falscheingaben der Benutzer - erhebliche Mängel auftreten.

Operational Data StoreDie Daten im BW-ODS können als ODS-Objekte vorgehalten werden. Ein ODS-Objekt besteht aus jeweils drei relationalen Tabellen - einer für die beim Reporting notwendigen aktuellen und aktiven Daten, einer für die aus Änderungen entstehenden Daten sowie einer dritten Tabelle für das Change Log zur Unterstützung des Delta-Verfahrens.

Auf einer zweiten ODS-Ebene werden diese Daten über Fortschreibungsregeln in einen Zusammenhang gebracht, der die Beantwortung betriebswirtschaftlicher Fragen ermöglicht. Der ODS im BW realisiert somit sowohl die Konzepte des ODS als auch des RDL. Dabei besteht im Standard eine Tendenz zur Ausrichtung auf das Olap-Konzept. Hierfür werden die Daten in eine weitere Schicht - die Info Cubes - geladen, also mehrdimensional strukturierte, nach einer Art Star-Schema angelegte, relationale Tabellen (siehe Kasten "Info Cubes").

Analytische InformationssystemeIm Bereich der BI-Tools zur Realisierung analytischer Informationssysteme bietet das SAP BW als Standard den Business Explorer (BEx) an. Mit diesem lassen sich die BW-Daten unter Zuhilfenahme des BW-Olap-Prozessors, einer Rolap Engine, verarbeiten und in MS-Excel darstellen. Hierbei erzeugt jeder Verarbeitungsschritt ein SQL-Statement, das gegen die relationale BW-Datenbank läuft. Mit dem Business Explorer Analyzer werden die Abfragen erzeugt. Excel bildet das zentrale Frontend des BEx, Ergänzungen über Visual Basic sind möglich. Über den Business Explorer Browser lassen sich die Berichte abrufen.

Da sich Excel bei den Endanwendern noch immer hoher Beliebtheit erfreut, dürfte die BEx-Lösung, die einen beträchtlichen Anteil des Informationsgrundbedarfs abdeckt, Akzeptanz finden. Allerdings ergab die eingangs erwähnte Umfrage, dass BI-Anwender durchaus auch die Potenziale komplexer Werkzeuge nutzen, sobald sie damit - entsprechend geschult - einen echten Mehrwert produzieren können. Demnach sollte man in vielen Fällen auf die Anbindung weiterer Tools für die Entscheidungsunterstützung, Planung oder das Data Mining nicht verzichten. Die Anbindung entsprechender BI-Werkzeuge anderer Anbieter erlaubt das BW über die Microsoft-Schnittstelle ODBO. Diese erlaubt jedoch nicht den direkten Zugriff auf die Info Cubes. So lassen sich lediglich die im Business Explorer Analyzer vordefinierten Abfragen über ODBO nutzen. Zwar erlaubt die direkte Ankoppelung der BI-Tools über spezielle BAPIs einen effizienteren Zugriff, dies erfordert allerdings spezifische Kenntnisse und kann bei der Umsetzung einen höheren Aufwand verursachen.

Darüber hinaus besteht die Möglichkeit, über ein im Rahmen der mySAP.com-Initiative entstandenes Web-Reporting auf die BW-Daten zuzugreifen.

Ist das SAP BW eine Alternative?Bodo Rieger (siehe Kasten "Literatur") kommt in seiner Untersuchung der BI-Tools von Baan und SAP zu dem Schluss, dass es zwei Vorgehensweisen geben sollte. Demnach sind die von Baan beziehungsweise SAP gelieferten Werkzeuge dazu geeignet, das grundlegende Informationsbedürfnis zu erfüllen. Für den darüber hinaus gehenden Bedarf an Informations- und Entscheidungsunterstützung hält er jedoch ein eigenständiges Data Warehouse, auf dem beliebige, spezialisierte BI-Tools aufsetzen können, für sinnvoll. Nach Einschätzung von Rieger entsprach dies bislang auch der Strategie von SAP. Die Konzeption des BW zeugt allerdings von dem Versuch, eine umfassendere Lösung anzubieten.

Die Kombination aus R/3 und BW stellt einen alternativen Ansatz zum unabhängigen Data Warehouse mit vollständig offenen Schnittstellen dar. Gute Integration und Standardisierung bedingen jedoch Vorteile ebenso wie Nachteile. So ist die R/3-BW-Gesamtlösung hoch komplex, was auch den Schwierigkeitsgrad bei grundlegenden Änderungen ausmacht. Deutlich wird dies bei den Business Contents, die schon jetzt eine nur schwer überschaubare Anzahl erreicht haben - einen entsprechend hohen Aufwand erfordern notwendige Veränderungen. Zudem gestaltet sich die Integration von R/3-fremden Quelldaten äußerst schwierig. Je größer also das Bedürfnis, Nicht-R/3-Daten zu integrieren und das Datenmodell umzustrukturieren (RDL-Konzept), desto bedeutsamer der Anpassungsaufwand.

Mit zunehmender Analysekomplexität werden Ergänzungen des Business Explorer um spezialisierte BI-Tools erforderlich werden, wodurch die Schnittstelle über ODBO zum Engpass geraten kann. Ferner wäre auch ein verbesserter Zugriff auf das BW wünschenswert. Die Vorteile des SAP-BW-Ansatzes sind allerdings nicht zu unterschätzen. Die Integration von R/3 und BW ist gelungen und erleichtert vieles. Bei einem hohen Anteil von R/3-Daten und der Nutzung des Standards kann die Implementierung des BW vergleichsweise einfach sein. Gerade die vorgegebenen Business Contents und das durchgängige Konzept werden für viele Unternehmen ein Erfolgspotenzial darstellen. Eine integrierte Informationslogistik, etwa die Anbindung von SAPs CRM zu einem Closed-Loop-Konzept, wird erleichtert. Auch die Integration der vorhandenen Metadaten ist vergleichsweise einfach und Teil der BW-Konzeption - ein insbesondere vor dem Hintergrund der zunehmenden Bedeutung von Data-Warehouse-Metadaten wichtiger Aspekt. Wer seine IT-Strategie schon bei der umfassenden Einführung von R/3 zugunsten von SAP ausgerichtet hat, wird sich eventuell allein deshalb für das BW entscheiden. So verspricht SAP gewisse Sicherheiten, ferner werden mit dem Release BW 3.0 weitere aufgelistete Mängel entfallen. Für viele Hersteller ist SAP BW außerdem ein interessantes Marktsegment, sodass eine breite Unterstützung durch Drittanbieter von Werkzeugen und Schnittstellen weiterhin sehr wahrscheinlich ist.

*Dr. Eitel von Maur ist Dozent und Projektleiter am Institut für Wirtschaftsinformatik an der Universität St.Gallen.

Info CubesEin Info Cube gliedert sich in Merkmale und Kennzahlen (Info Objects). Dabei lassen sich die Stammdaten separat von den Dimensionstabellen halten, um diese möglichst klein zu halten. Die Info Cubes werden mit Hilfe der Administrator-Workbench verwaltet. Grundsätzlich wird zwischen Basis Cubes, Multi Cubes und Remote Cubes unterschieden. Basis Cubes werden von mehreren Informationsquellen über Fortschreibungsregeln mit Daten versorgt. Multi Cubes basieren auf Basis Cubes und/oder Remote Cubes, mit dem Ziel, die Kombination von Daten zu ermöglichen. Der Multi Cube ist eine rein logische Struktur und wird nicht physikalisch abgelegt. Remote Cubes realisieren Durchgriffe auf die operativen Daten, gehen also nicht über das BW.

LiteraturDevlin, B.: Data Warehouse: From Architecture to Implementation; Addison-Wesley, 1997

Jung, R.; Winter, R.: Data Warehouse Strategie: Erfahrungen, Methoden, Visionen; Springer, 2000

Rieger, B.: Führungsinformationssysteme in Standardsoftware-Paketen; Industrie Management 3/1997

Abb: Die Architektur des SAP BW

Die Schichten des SAP BW entsprechen prinzipiell denen anderer Data-Warehouse-Lösungen. R/3-Daten werden allerdings unverändert geladen, während Fremddaten als Flat Files umplatziert oder über ETL-Tools überführt werden. Quelle: SAP SI/Peter Lehmann