Das "SAP Business Information Warehouse" (SAP BW) gehört zum Business-Intelligence-Portfolio der SAP und ist mittlerweile weit verbreitet. Viele Unternehmen berichten indes von hohen Projektkosten, langen Einführungszeiten und unzufriedenen Anwendern. Schuld daran ist nicht allein die Software, sondern oft liegen die Ursachen in der IT-Strategie, der Projektorganisation sowie in der Art der Implementierung und Nutzung von SAP BW. Im Einzelnen lassen sich elf grundsätzliche Probleme in der Praxis ausmachen, die zum Teil auch in anderen Data-Warehouse-Projekten auftreten können:
1. Falsche Positionierung
Das SAP BW dient vor allem der Datenlogistik und als Basis eines Standardberichtswesen im Customer-Relationship-Management, Supply-Chain-Management und Business Intelligence (BI). Für überschaubare und abgeschlossene Aufgaben in Fachabteilungen, die beispielsweise nur ein Controlling-Werkzeug für Datenanalyse, Simulation und Planung suchen, kann die Software zu groß und zu teuer sein. Unternehmen sollten dies in ihrer IT-Strategie berücksichtigen und Werkzeuge je nach Komplexität, Funktionen und Anwendergruppen einführen, statt von vornherein auf eine zentrale Einheitslösung eines Herstellers zu setzen.
2. Unklare Strategie
SAP BW muss als relativ neues Produkt oft in eine bestehende BI-Landschaft eingebunden werden, in der Data-Warehouse-Lösungen mit anderen Techniken vorherrschen. Das Zusammenspiel zwischen den verschiedenen Systemen sollte daher klar definiert sein, um zu einer integrierten, einheitlichen Sicht auf die Unternehmenskennzahlen zu gelangen. Wo dies aus politischen oder organisatorischen Gründen nicht geschieht, wird es eine ständige Diskussion über die Richtigkeit von Zahlen geben und der administrative Aufwand zu hoch sein. Fehlt es an Fachwissen zur Umsetzung einer konsistenten Strategie, sollten Anwender externe Hilfe in Anspruch nehmen, zumal bei den unternehmensintern Beteiligten in der Regel Macht, Karrieren und Eitelkeiten auf dem Spiel stehen, die eine neutrale und für das Gesamtunternehmen optimale Strategiefindung behindern.
3. IT-getriebener Ansatz
Für jedes Data-Warehouse-Projekt ist die Zusammenarbeit zwischen den Systemanwendern in Fachabteilungen und den Systembetreuern in der IT der Schlüssel zum Erfolg. Beim SAP BW ist aber meist die IT der Treiber. Dies führt zu Systemen, die technisch gut aufgebaut sind, vom Anwender aber oft bemängelt werden. So beschweren sie sich vor allem über die mangelnde Flexibilität der Lösungen, wenn Änderungen erforderlich sind, sowie über lange Abfragezeiten oder unzureichende Funktionen. Unternehmen sollten deshalb Kompetenz- und Entscheidungszentren zu Data-Warehouse- und BI-Themen mit Mitarbeitern aus IT- und Fachabteilungen aufbauen.
Das Barc-Institut hat seine Studie "Frontends für SAP BW" aktualisiert. Sie vergleicht und bewertet sowohl die SAP-eigenen als auch 17 zertifizierte Drittanbieterwerkzeuge für Reporting und Analyse auf SAP BW. Informationen unter Barc.de. |
4. Datenmodelle
Das Datenmodell eines Data Warehouse unterscheidet sich signifikant von denen in operativen Systemen. Es ist der bestimmende Faktor für viele weitere Parameter wie die Abfrage-Performance, Ladezeiten, Anwenderfreundlichkeit und Berechnungsmöglichkeiten. Eine besondere Gefahr in SAP-BW-Projekten ist diesbezüglich die Anlage zu vieler "Cubes", die weder für Anwender noch für Administratoren überschaubar bleiben. Unternehmen sollten daher darauf achten, dass eventuelle Implementierungspartner Erfahrung mit der Modellierung von Data Warehouses haben - grundsätzliche Kenntnisse mit SAP R/3 oder anderen operativen Systemen sind hier weitgehend nutzlos. Andererseits kann die Erfahrung altgedienter Projektmitarbeiter mit dem Aufbau "freier" Data Warehouses hilfreich sein.
5. Business Content
Unternehmen setzen manchmal zu hohe Hoffnungen in den Business Content für SAP BW. Dieser bietet vordefinierte Informationsmodelle für Prozesse in R/3 und anderer SAP-Anwendungen. Dieser ist jedoch lediglich als Vorlage zu verstehen. Seine Anpassung kann in der Praxis durchaus aufwändiger sein als eine Neuentwicklung. Beispielsweise müssen Berichte so gut wie immer mit den individuellen Wünschen der Anwender abgestimmt werden. Auch funktioniert die Datenversorgung über den Business Content nur dann ohne Anpassung, wenn das zugrunde liegende R/3-System nicht verändert wurde. Auf Seiten des Datenmodells beziehungsweise der Datenbank besteht für den Administrator zudem die Gefahr, die Übersicht und das Verständnis für die Zusammenhänge zu verlieren, wenn er zu viele Objekte des Business Content aktiviert. Es ist daher ratsam, Letzteren in einem Testsystem vorab genau auf seine Eignung für die konkreten Unternehmensanforderungen zu prüfen. Unter Umständen kann es besser sein, das Data Warehouse "auf der grünen Wiese" neu aufzubauen, als den vordefinierten Content anzupassen.
6. Datenqualität
Die Datenqualität ist in jedem Data Warehouse ein Problem, unter anderem deshalb, weil sich die Anforderungen an Datenqualität in entscheidungsorientierten Systemen stark von operativen Systemen unterscheiden können. Anwender sollten daher genug Zeit und Manpower für die Validierung und Bereinigung von Daten und überhaupt für Datenqualitätsthemen einplanen. Idealer wäre ein ganzheitlicher Ansatz von der Entstehung bis zur Nutzung der Daten, doch das dauert Zeit und ist häufig nicht als Teil des Projekts umzusetzen.
7. Individualentwicklung
Auf allen Ebenen des SAP-BW-Systems können Anwender individuelle Anpassungen durch das Hinzufügen von Programmen vornehmen. Häufig wird die Datenintegration mit Abap programmiert statt spezielle Integrationswerkzeuge zu verwenden. Ebenso setzen Unternehmen statt des Standard-Web-Frontends von BW auf individuelle Web-Entwicklungen. Die schnelle und günstige Entwicklung von Individualprogrammen rächt sich aber häufig später in der Wartung eines Programmdickichts, das kein Administrator mehr durchschauen kann. Es sollte daher immer geprüft werden, ob unter langfristigen Kostenaspekten nicht Standardwerkzeuge die bessere Wahl sind.
8. Abfragezeiten
Wie schnell Systeme für Online Analytical Processing (Olap) arbeiten, hängt von den Anwendungsfällen und den Anwendergruppen ab. In einem relationalen Olap-System wie dem SAP BW müssen diesbezüglich vor allem Aggregattabellen gepflegt werden, und die Datenmodellierung muss schon nach Auswertungsgesichtspunkten erfolgen. Auch wenn das SAP BW eigentlich alle Interaktionen mit der Datenbank steuert, ist auf dieser Ebene ein Tuning häufig notwendig. Anwender sollten dafür die in der Software gebotenen Möglichkeiten zur Optimierung ausgiebig nutzen.
9. Schlechte Berater
Häufig klagen SAP- BW-Anwender über schlechte Implementierungsberater, die mit zu wenig Know-how im Data Warehousing ausgestattet sind und die noch größere Unwissenheit der Kunden ausnutzen. Ein gutes Systemhaus für die SAP-R/3-Implementierung muss noch lange keine guten Leute für SAP-BW-Implementierungen haben. Unternehmen sollten deshalb immer mehrere Angebote einholen und nicht blind auf ihren bisherigen Partner für das operative SAP-System vertrauen. Auch sollten kleine, spezialisierte Beratungshäuser nicht außer Acht gelassen werden. Das Motto heißt hier: "Wählen Sie Berater aus und nicht Beratungsfirmen."
10. Anwenderwerkzeuge
Für das Berichtswesen und die schnelle Olap-Analyse mehrdimensionaler Daten evaluieren Unternehmen häufig als Ergänzung zu den SAP-Tools Werkzeuge von Drittanbietern. Diese sind oft der Schlüssel zur Anwenderakzeptanz und damit zu Projekterfolg und Projektausweitung. Das Angebot entsprechender Tools mit zertifizierten BW-Schnittstellen ist allerdings groß und sehr heterogen. Unternehmen sollten deshalb zunächst versuchen, ob nicht auch die Möglichkeiten der SAP-Werkzeuge den Anforderungen der Anwender gerecht werden. Die Schnittstellen mancher Drittanbieterwerkzeuge sind zudem noch nicht ausgereift, so dass die Tools nicht die volle Funktionsvielfalt des SAP BW unterstützen.
11. Falsches Projekt- Management
Data Warehousing ist kein normales Projekt, da das System aufgrund sich schnell ändernder Anforderungen laufend weiterentwickelt werden muss. Dies muss bei der Projektorganisation berücksichtigt sein. Es ist ratsam, die Einführung in kleinen Schritten vorzunehmen, die möglichst innerhalb von drei Monaten sichtbare Ergebnisse zeigen. Diese dienen dann als Basis für Veränderungen und Erweiterungen. So entsteht nach und nach das Gesamtsystem, das aber flexibel für Anpassungen bleibt. Die personellen Verantwortlichkeiten für Einführungsprojekt und Betrieb sollten dabei nicht voneinander getrennt werden.