Die Meinungen über das Business Warehouse (BW) von SAP sind geteilt. Während manche Anwender auf das Werkzeug nicht mehr verzichten möchten, kritisieren andere das Analyse-Tool als zu komplex, zu langsam und zu teuer. Das wirft die Frage nach den Gründen für die unterschiedlichen Einschätzungen auf. Was führt zu einem erfolgreichen Einsatz des SAP BW und wo liegen die Stolperfallen im Betrieb? Die im Folgenden angeführten zehn Punkte zeigen, dass der Weg zu einem positiven BW-Erlebnis weder kompliziert noch weit ist.
Lesen Sie mehr zum Thema Data Warehouse:
-
Datenanalyse: Data Warehouse Appliances - Trends und neue Techniken
-
SAP-BW zu langsam: Verlag macht dem Konzern-Controlling Beine
1. Klären, was gebraucht wird
Es ist im Grunde eine Selbstverständlichkeit: Wie bei jeder Software-Einführung sollte im Unternehmen zuvor Transparenz darüber herrschen, was überhaupt in Sachen Analyse benötigt wird. Die Strategie der SAP an dieser Stelle ist eindeutig. Immer mehr Auswertungs- und Reporting-Funktionalität wandert aus den Enterprise-Resource-Planning-Systemen (ERP) in das SAP BW. Ungeachtet dessen sollten insbesondere kleinere Unternehmen mit einfachen Berichtsanforderungen abwägen, ob der BW-Einsatz tatsächlich erforderlich ist oder ob die Verwendung einfacher und kostengünstiger Systeme oder sogar die im Standard unterstützte Überführung der ERP-Daten in eine Excel/Sharepoint-Umgebung oder nach Qlikview für die eigenen Zwecke nicht vollkommen ausreicht. Umgekehrt gilt: Müssen Anwender in ihrer Tätigkeit Informationen aus verschiedenen Quellsystemen zusammenführen und diese Daten in komplexen Berichten aufbereiten, dann ist SAPs Data Warehouse-Lösung in der Regel das System der Wahl.
2. BW-Plattform richtig dimensionieren
Eine beliebte Fingerübung vieler Anwender ist es, im Falle von Leistungsproblemen oder wachsenden Nutzerzahlen einfach größere Server-Ressourcen zu implementieren. Doch in den seltensten Fällen liegt die Wurzel des Übels in einer zu schwachen Hardwareausstattung oder mangelnder Rechenleistung. Denn die Anforderungen des SAP BW sind zumindest in den Tagesstunden in aller Regel durchaus genügsam. Ein kleineres BW-System mit vier OLAP-Würfeln und 25 Auswertungsabfragen benötigt im Normalfall einen dedizierten Intel-Server mit einer Doppel-CPU (2 mal 2- oder 2 mal 4 Kerne). Alternativ lässt sich ein BW auch in einer virtualisierten Umgebung betreiben, beispielsweise auf einem IBM Power-basierenden Server. In diesem Fall beansprucht das System noch nicht einmal eine ganze CPU, sondern begnügt sich mit einem Anteil von etwa einem bis vier Zehntel.
Foto: VMS
Diese "Genügsamkeit" was die Rechenkapazitäten anbelangt mag auf den ersten Blick erstaunen. Wer sich aber einmal die prinzipielle Arbeitsweise eines Data Warehouse vor Augen führt, wird sie schnell nachvollziehen. Im Idealfall liegen die Daten im BW in genau der Form vor, die der Benutzer auch benötigt. Berechnungen werden nicht ausgeführt. Daher liegt der Anteil der CPU-Zeit an der Antwortzeit einer Query unter zehn Prozent. Der Benutzer eines BW führt im Wesentlichen lesende Datenbankzugriffe aus.
3. Mehr Leistung für die Nacht
Die "Genügsamkeit" des SAP BW beschränkt sich allerdings ausschließlich auf das Tagesgeschäft. In der Nacht ist aufgrund der zeitaufwendigen, mehrstufigen ETL(Extract, Transform, Load)-Prozesse deutlich mehr Leistung bei den Systemressourcen gefragt. Das BW muss sich zunächst gedulden, bis die vorgeschalteten Quellsysteme die Batch-Jobs der jeweiligen Nachtschicht erledigt haben und alle für das BW benötigten Daten vorliegen. Erst im Anschluss darf es die eigenen Ladeanforderungen anmelden. Die Kunst des Sizings besteht nun darin, die Systemressourcen so zu dimensionieren, dass die Arbeit des Ladens und der Aufbereitung von Daten rechtzeitig vor Beginn der Kernarbeitszeit beendet ist. Dazu sollte das BW auf möglichst viele Ressourcen nahezu exklusiv zugreifen können, da das ERP-System seine Aufgaben bereits erledigt hat.
4. Den Datenspeicher richtig konfigurieren
CPU-Power bereitet aus den genannten Gründen in der Praxis heute also kaum mehr Probleme. Eine potenzielle Gefährdung des BW-Betriebs geht dagegen von den Speichersystemen aus. Denn diese stellen den eigentlichen Flaschenhals für die im Dialogbetrieb initiierten Datenbankoperationen dar. Werden die auf einer bestimmten Platte abgelegten Daten angefordert und ist diese Platte aktuell noch mit einem anderen Ladevorgang befasst, muss erst einmal gewartet werden. Deshalb hat es sich in der Praxis als günstiger erwiesen, statt weniger große, viele kleine Festplatten einzusetzen. Auch verhindert der Einsatz einer größeren Anzahl überschaubar dimensionierter Platten, dass die aktuellen Daten nahezu ausschließlich auf einer einzelnen Festplatte liegen. Darüber hinaus können auch die in Speichersystemen fest implementierten intelligenten Verteil-Algorithmen helfen. Sie entfalten ihre Wirkung aber erfahrungsgemäß nur sehr langsam und zählen - je nach Leistungsfähigkeit - zu den eher kostspieligen Tuning-Varianten.
5. BI Accelerator als Turbo für das BW
Der Einsatz vieler kleiner Platten in einem Speichersystem ist als ausschließliche Maßnahme insbesondere für kleinere Installationen des SAP BW empfehlenswert. Der Ansatz lässt sich allerdings nicht ins Unendliche fortsetzen. In großen, zentralen BW-Umgebungen, deren Nutzerzahlen in die Tausende gehen und deren Datenmenge mehrere Terabyte umfassen, sind dagegen andere Konzepte vonnöten. Wer seinen Anwendern Performance bieten will, muss zwangsläufig auf den BI Accelerator als zusätzliche Zusatzkomponente für das BW zurückgreifen. Nach dem Prinzip der In-Memory-Technik indiziert dieser Beschleuniger die festgelegten InfoCubes/MultiCubes. Abfragen werden dann mit Hilfe leistungsfähiger Verdichtungstechniken vollständig im Speicher verarbeitet. Der BI Accelerator hat zweifellos seinen Preis, er bewirkt allerdings in sehr großen BW-Umgebungen bei Dialogprozessen auch beeindruckende Leistungssprünge.
Moderne Flash-Plattensysteme (Solid State Drive) oder Netzspeicher mit Caches auf Flashspeicher-Basis können an dieser Stelle nur bedingt als Alternative dienen. Die Geräte sind gleichfalls teuer, und da sie aus diesem Grund kaum als alleiniges Speichermedium taugen, werfen sie neue Probleme hinsichtlich der Verteil-Algorithmen zwischen Flash und herkömmlichen Platten auf.
6. Ein wenig genutztes BW wird träge
Unternehmen starten meist mit einem kleinen, sauber entworfenen BW für ein überschaubares Anwendungsfeld - beispielsweise in der Vertriebs- und Verkaufssteuerung. Die Anwender sind zufrieden, weil sie mit Hilfe des BW genau die Informationen erhalten, die ihre Arbeit effizienter macht. In aller Regel funktioniert das mit einem BW besser als mit dem traditionellen Reporting im ERP. Die Nutzer kommen auf den Geschmack, wollen zusätzliche Auswertungen und können weitere Kollegen für das BW begeistern. Entgegen der allgemeinen Erwartung führt die vermehrte Nutzung nicht zu Performance-Engpässen. Im Gegenteil: So manche Auswertungsanfrage wird sogar schneller beantwortet. Denn mit der wachsenden Nutzerzahl steigt die Chance, dass sich die geforderten Daten bereits im Cache oder Hauptspeicher befinden und nicht erst noch von der Speicherplatte der Backend-Datenbank geladen werden müssen.
Es scheint paradox: Aber ein performantes BW gewinnt Akzeptanz und ein akzeptiertes BW gewinnt Performance. Leider gilt der Umkehrschluss ebenso. Wird ein BW aus vermeintlichen Leistungsdefiziten nur sporadisch genutzt, verliert es mitunter weiter an Geschwindigkeit, da die Daten immer neu nachgeladen werden müssen.
7. Ordnung in den Reports halten
Der Leistungsgewinn durch Mehrnutzung gilt jedoch weder für jeden Anwendungsfall noch für jede Betriebssituation. So sind für das Management die positiven Erfahrungen meist Anlass, BW-Leistungen für alle Fachabteilungen im Unternehmen zu öffnen. Die IT freut sich über das gute Image und erfüllt als freundlicher Dienstleister alle Wünsche. In der Folge wachsen mit der Zeit jedoch die Aufgaben und damit Komplexität des BW. So manche Reportanforderung wird realisiert, selbst wenn schon seit einem Jahr ein ähnlich gelagerter Bericht verfügbar ist. Nur weiß niemand davon, da er in Vergessenheit geraten ist.
Andere Reporting-Wünsche weisen wiederum einen solchen Detaillierungsgrad auf, dass sie die ERP-Daten 1:1 im BW abbilden. Die unbeabsichtigte Folge der strategischen Vorgabe, sämtliche Reportings in das BW zu verlagern, mündet oft in doppelte Datenhaltung und Arbeit. Das ist nicht nur kontraproduktiv. Es gefährdet auch langfristig den Erfolg, da die Befüllung des BW in den Nachtstunden angesichts der Menge und des hohen Detaillierungsgrades nicht mehr abgeschlossen werden kann. Zur Bewältigung der Nachtspitzen müssen zusätzliche Speicher und Server beschafft werden. Die Kosten steigen.
8. Gesundheitscheck für das BW
SAP BW-Systeme neigen im Produktiveinsatz zu wachsen, Anfragen verändern sich, Antwortzeiten verschlechtern sich und Betriebskosten laufen aus dem Ruder. Aus diesem Grund ist es ratsam, das BW Gesundheitschecks zu unterziehen. Die Daten eines Echtzeit-Monitorings mit Tools wie "SAP CCMS" sind an dieser Stelle allerdings wenig hilfreich, da die Belastung des BW zu sprunghaft ist. Die Einzelfallbetrachtung erlaubt keine Aussage über den Zustand des Gesamtsystems.
Vergleichbar mit einem Langzeit-EKG vermittelt der Einsatz von statistischen und forensischen Methoden dagegen ein umfassendes Bild des BW. Daraus lassen sich beispielsweise Aussagen ableiten, unter welchen Bedingungen Probleme entstehen können. Eine Vermessung durch den "VMS DataCollector" zeichnet den kompletten Weg der Daten durch das System einschließlich Ladeprozesskette und Nutzung durch den Anwender detailliert nach. Die IT gewinnt damit ein transparentes Bild vom Ist-Zustand des Systems und erkennt, wo die Zeit vertrödelt wird. So lässt sich beispielsweise überprüfen, ob bei den Ladevorgängen die Reinigungsfunktionen in der Staging-Area noch ausreichend sind. Oder es zeigt sich, dass ein Anwender neue, leicht veränderte (Daten-)Aggregate nutzt und nicht mehr die gewohnten Abfragen stellt. Das Ergebnis des Checks sind konkrete Handlungsempfehlungen in allen Bereichen des BW, von der Vorbereitung der Daten im ERP über das Laden und Aufbereiten bis hin zur Performance im Dialogbetrieb. Die Analyse erkennt nicht nur globale Performanceprobleme, sondern erlaubt auch detaillierte Aussagen zu einzelnen Queries. So lässt sich das BW wieder auf das frühere "Gesundheitsniveau" bringen.
9. Benchmarks als Tuning-Maßstab
Der volle Nutzen eines Gesundheitschecks ergibt sich allerdings erst im Vergleich mit anderen Unternehmen. Die Frage, die sich Anwenderunternehmen stellen müssen, lautet: Was geben andere Unternehmen aus, wenn sie einen mit der eigenen Firma vergleichbaren BW-Leistungsmix erbringen? Der Unterschied ist zum Teil gewaltig. Für den eingangs skizzierten Fall einer kleineren BW-Installation weist die VMS Benchmark-Base, die Informationen zu mehr als 2000 vermessenen SAP-Systemen umfasst, für den Best-Practice-Fall monatliche Betriebskosten einschließlich Personal in Höhe von 13.000 Euro aus. Im Durchschnitt über alle kleinen BW-Installationen dieser Art betragen die Kosten 30.000 Euro. Große BW-Systeme sind schnell 30 Mal so teuer. Mit anderen Worten: Es existieren vielerorts erhebliche Einsparpotentiale.
10. Alternativen mit BW
Mit der Frage, ob ein SAP BW in jedem Fall und für jeden Anwender die geeignete Wahl darstellt, sollte sich jedes Unternehmen regelmäßig auseinandersetzen - nicht nur zu Beginn. Selbst wenn ein BW im Einsatz ist, muss das System nicht für jeden Report bereitstehen. Wenn Daten aus dem ERP nahezu 1:1 übernommen werden müssten, ist es fraglos kostengünstiger, für Auswertungen Links direkt ins ERP zur Verfügung zu stellen. Zeigt der Gesundheitscheck, dass bestimmte Nutzerkreise jeden Tag festgelegte Auswertungen ohne zusätzliche Fragestellungen abrufen, müssen diese Berichte nicht zwangsläufig im dem BW bevorratet werden. Es genügt, diese Berichte über Nacht zu erstellen und direkt per Broadcasting-Funktion in die Posteingangsbox zu übermitteln. Das entlastet das System im Tagesbetrieb und stiftet Akzeptanz auf User-Seite.
Sollten sich die Anwender intensiv und immer wieder anders mit den Datenaggregaten auseinandersetzen, sollte das BW eher als eine Zwischenstation für Analysedaten genutzt werden. Die IT sollte in einem solchen Szenario der Fachabteilung die Wahl alternativer Auswertungsumgebungen beziehungsweise -tools freistellen statt auf BW-konforme Pflichtenhefte zu pochen. Ein solcher Schritt ist der Akzeptanz sicherlich förderlich - auch wenn das BW zurücktreten muss. Aber - und das sollte an dieser Stelle ebenso Erwähnung finden - das BW ist in manchen Fällen selbst eine reale Alternative. Insbesondere aufwendige Analysen im Rahmen von Controlling/Profitabilitätsberechnung reizen die Leistungsgrenzen einer ERP-Software schnell aus und lassen sich bei sauberer Abbildung in einem BW weitaus preiswerter und kostengünstiger durchführen.