Netweaver BI

Ohne einen systematischen Bewertungsprozess läuft die Tool-Auswahl schnell in die Irre, wie der Consulter Jörg Huss erläutert: „Bestehende Applikationen und vertraute BI-Werkzeuge suggerieren Anforderungen, die vielleicht so gar nicht existieren. Oder aber einzelne Features und Funktionen werden überbewertet und überlagern die Wahrnehmung anderer wichtiger Anforderungen." Schließlich würden Hersteller in diesem Verwirrspiel die vermeintlichen Anforderungen gerne zu ihrem eigenen Nutzen manipulieren.

Als häufigen Fehler registriert Frontend-Spezialist Huss die Überforderung der Endanwender beziehungsweise Fachbereiche mit der Anforderungsspezifikation. Der Anspruch an die technische Tiefe und Konkretheit eines Lastenheftes ist in vielen Unternehmen hoch. Den Erwartungen entsprechend werden Fachvokabeln aus dem Umfeld Business Intelligence und Begrifflichkeiten spezifischer Technologien verwendet. „Viele Fachkonzepte gleichen vorweggenommenen IT-Konzepten", erläutert Huss. „Da verwundert es nicht, dass die Anforderungen oft gleich von IT-nahen Personen im Auftrag des Fachbereichs spezifiziert werden. Damit kommt die technische Brille viel zu früh ins Spiel."

Nur sehr selten starten Unternehmen ihre Betrachtung mit der Frage, welche Aufgaben die Anwender mit Hilfe der Reports bewältigen sollen. Dabei wird bei einer eingehenden Aufgabenanalyse klar, welche Forderungen der Anwender an sein zukünftiges BI-Werkzeug stellt, welche Empfänger welche Daten mit welcher Frequenz erhalten sollen, wer überhaupt welche Daten sehen darf und welche Kommunikationsmedien (Mobile, Mail oder Portal) sich dafür am besten eignen.

Auf Basis einer Grobanalyse lassen sich die jeweiligen Anwendungsszenarien einzelnen Aufgabenkategorien zuordnen (etwa Listenreporting, Management Reporting, Ad-hoc-Analyse), die wiederum eine Vorauswahl geeigneter Werkzeuge ermöglichen. Eine tiefer gehende Detailanalyse erlaubt dann, die Relevanz verschiedener Einzelaktivitäten für die betrachteten Anwendungsszenarien einzuschätzen und damit ein funktionales Anforderungsprofil für das BI-Werkzeug beziehungsweise die individuelle Reporting-Applikation zu erstellen.

Neben den funktionalen Anforderungen, die im Rahmen der fachlichen Aufgaben- und Prozessanalyse ermittelt werden, muss ein Anforderungsprofil auch technologische und strategische Aspekte beinhalten. Die zentrale Frage lautet, wie das jeweilige Werkzeug auf SAP BW zugreift. Die Mehrzahl der verfügbaren Thirdparty-Werkzeuge nutzt die OLAP-Schicht (Online Analytical Processing) über eine der Schnittstellen ODBO, XML-A oder OLAP BAPI. Sie unterstützen dabei sowohl die reichhaltige OLAP-Funktionalität von SAP BW als auch feingranulare Berechtigungsprüfungen sowie den Zugriff auf den Business Warehouse Accelerator (BWA), mit dem für ultraschnelle Zugriffe große Datenmengen im Arbeitsspeicher bereitgehalten werden.

Ohne Business Warehouse Accelerator kann allerdings die Nutzung der OLAP-Schichten des SAP BW zu einem Performanceproblem werden. Selbst mit dem Accelerator sind die drei OLAP-Schnittstellen eher nicht für das Auslesen von Massendaten aus SAP BW konstruiert. Hinzu kommen funktionale Einschränkungen, die sich im Einzelfall zum Showstopper auswachsen können.

„Unternehmen sollten sich vom Tool-Anbieter auf alle Fälle aufzeigen lassen, wie das jeweilige Frontend alternativ zu den OLAP-Schnittstellen auf BW-Daten zugreifen kann", erläutert Mayato-Geschäftsführer Marcus Dill. „Viele Anbieter räumen dann ein, dass die Zertifizierung auf OLAP-Ebene ihnen zwar vertrieblich hilft, sie aber in der Praxis andere Wege beschreiten, wie etwa die Datenreplikation in eigene Data Marts." Eine solche Datenreplikation werfe allerdings in Bereichen wie Deltaversorgung, Konsistenz von Berechtigungen und Information Lifecycle Management eine Vielzahl von neuen Fragen auf.

Einige Anbieter gehen von vorne herein den Weg über andere SAP-Schnittstellen oder liefern sogar eigene Add-Ons für SAP BW aus. Die praktische Qualität dieser Lösungen variiert stark, wie Dill erläutert: „Darüber sollte man sich auch durch eine etwaige SAP-Zertifizierung nicht hinwegtäuschen lassen, da diese je nach Art der Schnittstelle beziehungsweise Zertifizierung gegebenenfalls nur die technische Konsistenz nachweist, nicht aber die Funktion selbst."

Manch eine Lösung genüge modernen Security-Anforderungen nicht und könne sich als Sicherheitslücke entpuppen. „SAP-Zugriffe, die nicht über eine der OLAP-Varianten gehen, müssen daher eingehend geprüft werden."

Neben dem Zugriff auf das SAP-System müssen alternative BW-Frontends oft zusätzliche Nicht-SAP-Quellen verarbeiten. Das gilt zum Beispiel, wenn die entsprechenden Daten noch nicht im SAP BW verfügbar sind oder wenn SAP BW nicht das einzige Data Warehouse im Unternehmen ist. „Unterstützt das Frontend keine semantische Schicht über verschiedene Quellen, werden Ergebnislisten aus BW-Reports abgezogen und in lokalen MS-Excel- und MS-Access-Anwendungen mit anderen Daten integriert", warnt Dill. „Solche lokalen Lösungsinseln bringen immer zusätzliche Risiken und Kosten mit sich. Ein Frontend sollte diese Integrationsanforderungen abdecken und kanalisieren."

Weitere typische technologische Fragestellungen betreffen die Frontend-Plattform (zum Beispiel in MS Excel mittels Add-In oder in Browsern über Webtechnologien wie Adobe Flash), die Authentifizierung (Single Sign On) und Autorisierung, die Verschlüsselung, die Integration ins SAP Portal oder in andere Portalplattformen, Optionen für Versand, Druck und PDF-Export, die Integration in MS Office, die Installation sowie Rahmenbedingungen hinsichtlich Hardware oder Software (zum Beispiel Betriebssystem, MS-Office-Release).

Die zugrundeliegenden Anforderungen leiten sich einerseits aus fachlichen Erfordernissen ab und ergeben sich andererseits aus der bestehenden Infrastruktur sowie den Vorgaben des Unternehmens.

Auch harte finanzielle Kriterien spielen bei der Tool-Auswahl eine zentrale Rolle. Der Nutzen, den die neue BI-Applikation stiftet, soll schließlich trotz der Kosten für Anschaffung und Betrieb erhalten bleiben.

Trotz komplexer Preismodelle und einer Unzahl an Rabatten und Lockangeboten lassen sich die absehbaren Lizenzkosten durch Einholen eines schlichten Kostenvoranschlages relativ einfach ermitteln. Gleiches gilt für die jährlich anfallenden Supportgebühren.

Die Bedeutung von Lizenzkosten wird von den meisten Unternehmen überbewertet, obwohl andere Faktoren auf Dauer höhere Kosten verursachen können, erläutert Dill: „Den größten Kostenblock machen erfahrungsgemäß das Customizing der Werkzeuge und die Entwicklung von Anwendungen auf der gewählten Plattform aus." Aufwands- und Kostentreiber sind zunächst oft die Werkzeuge selbst, etwa durch hohe Komplexität, schlechte Bedienbarkeit, unzureichende Dokumentation und arbeitsintensive Erweiterungstechniken.

Hinzu kommen Marktfaktoren wie hohe Beratersätze sowie teure Ergänzungspakete, die fehlende Funktionen nachrüsten. Außerdem spielt es eine Rolle, ob für eine Technologie im Haus bereits Erfahrungen und Infrastruktur vorliegen, beispielsweise in Nachbarabteilungen oder anderen Tochterunternehmen eines Konzerns.

Für den Endanwender ist vor allem die einfache Bedienung wichtig. Diese ist allerdings nicht immer gegeben. Viele Anbieter werben zwar mit „intuitiven Drag&Drop-Oberflächen", allerdings sind bei komplexeren Querys oft Programmierkenntnisse erforderlich. Wenn die Bedienung des Tools die ständige Unterstützung durch Berater erfordert, treibt dies die laufenden Kosten immens nach oben.

Hat ein Unternehmen das Profil seiner fachlichen und technologischen Anforderungen erstellt, steht der Vergleich mit dem Leistungsprofil der in Frage kommenden Werkzeuge an. „Diese Hürde können viele Unternehmen nicht ohne fremde Hilfe überwinden, da oftmals hausintern die erforderliche Detailkenntnis fehlt", berichtet Dill. „Die Software-Anbieter helfen an dieser Stelle nur eingeschränkt, da sie meist kein realistisches Bild ihrer Werkzeuge vermitteln und über Schwächen ihrer Lösung nicht gerne reden." In der Regel empfehle es sich, einen spezialisierten Berater einzubeziehen. Dieser sollte keinesfalls Provisionen von Herstellern kassieren, da sonst die Gefahr besteht, dass er seine eigenen wirtschaftlichen Interessen in die Bewertung der jeweiligen Software mit einfließen lässt. Sind Anforderungs- und Leistungsprofile erstellt, dann können diese qualitativ und quantitativ miteinander verglichen werden, so dass sich bei den Werkzeugen die Spreu vom Weizen trennt. Ist ein Unternehmen auch nach diesem Schritt noch unsicher, für welches der Werkzeuge es sich entscheiden soll, oder bestehen Zweifel, ob selbst das Tool mit dem besten Score die Anforderungen ausreichend abdeckt, dann empfiehlt sich die Erstellung eines Prototyps als Proof of Concept.

„Ab einer gewissen Investitionshöhe sollten Anwender auf einem aussagefähigen Prototypen bestehen", rät Dill. „Viele Hersteller unterstützen solche Pläne bereitwillig mit viel Spezialwissen und Ressourcen – in der Regel zu sehr günstigen Konditionen und manchmal sogar kostenlos." jf