E-Interview "Business Intelligence: To SAP or Not To SAP? (Integrationskonzepte für SAP und Applix)" mit Prof. Dr. Martin Grothe

NetSkill AG E-Interview: Business Intelligence: To SAP or Not To SAP? (Integrationskonzepte für SAP und Applix) Name: Prof. Dr. Martin Grothe Organisation: Institute of Electronic Business, Berlin Funktion: Professor / Buch-Autor Kurzeinführung in das Titel-Thema: Der attraktive Business Intelligence-Markt wird nicht nur von den Business Intelligen- ce-Spezialisten, sondern zunehmend auch von den Generalisten Microsoft und SAP geprägt. Insbesondere bei SAP fragen sich Unternehmen, ob und in welchem Um- fang sie ihre Business Intelligence-Anforderung durch SAP abdecken können, ob überhaupt der Einsatz von weiteren Plattformen sinnvoll bzw. notwendig ist und wie – wenn ja – gegebenenfalls integrative Lösungen gestaltet werden können. Professor Martin Grothe, langjähriger Business Intelligence-Spezialist, nicht nur im Rahmen der Competence Site, hat nun insbesondere für Applix-Anwender unter- sucht, wie dort die Business Intelligence-Lösungen in Kombination mit SAP gestaltet wurden. Darüber hinaus hat er aber auch grundsätzlich mögliche Rollen von SAP einerseits und von Speziallösungen anderseits in Gesamtszenarien beleuchtet. So kann er in diesem E-Interview auch umfassend die Frage beantworten, ob und in welcher Form es in the long run Business Intelligence jenseits von SAP geben wird. NetSkill AG Sehr geehrter Herr Professor Grothe, Competence Site: SAP und Spezial-Lösungen in der Business Intelligence-Welt To SAP or Not To SAP? Welche Bedeutung hat Ihrer Baucheinschätzung nach heute schon SAP in der Business Intelligence Welt? Welche Rolle ordnen Unternehmen SAP, den SAP-Lösungen und Lösungen von Business Intelligence-Spezialisten zu? Was spricht für (und gegen) eine Arbeitsteilung in integrierten Gesamtlösungen? Professor Grothe: Ein Entweder/oder stellt sich nur von Ferne. Wir erleben das Vordringen der OLTP- Systeme in den analytischen Aufgabenbereich: In der klassischen Arbeitsteilung zwi- schen OLTP- und OLAP-Systemen, die auf der einen Seite für Transaktionen essen- tielle operative Stabilität, auf der anderen Seite für Analyserfordernisse unabdingbare hohe Flexibilität gewährleistete, zeichnet sich nun ein langsamer, aber nachhaltiger Wandel ab. Vor dem Hintergrund dieser Entwicklungstendenz und aktueller Fallstudien wird deut- lich, dass die eindeutige Zuordnung von transaktionsorientierten und analytische Aufgaben zu getrennten Systemfamilien aufweicht. So erweitert sich einerseits das Lösungsspektrum von SAP-Anwendungen zunehmend in Richtung flexibler Instru- mente, wenngleich so mancher Philosophiebruch diesen Weg erschwert. Aber nicht nur die Transaktionssysteme bewegen sich. Auch viele OLAP-Lösungen entwickeln sich funktional weiter. Diese Bewegung bietet die Chance, die jeweiligen Effizienzdomänen noch klarer herauszustellen. Aus der Sichtweise von OLAP-Gestaltern bieten folgende Bereiche weiten Raum, in dem diese Lösungen ihre Stärken nutzbringend einsetzen können: ! Weitgehende Unterstützung von Work Flows, stärkere Nutzung von interaktiven Komponenten und dezentraler Zusammenarbeit im Prozess (Collaboration), ! Breitere Unterstützung von qualitativen / textuellen Informationen (bis hin zu denkbaren Verbindungen zum Wissensmanagement), ! Simulation und War-Gaming als möglicherweise kommende Einsatzbereiche. NetSkill AG Insbesondere die Aufgabe der Prozessunterstützung durch Work Flows wird bei- spielsweise von der Integra-Lösung von Applix bereits sehr gut aufgenommen. Damit wird deutlich, dass „Spezialisten“ eben genau dann eine Berechtigung haben, wenn sie spezielle Vorteile bieten, mit denen über den um sich greifenden Standard hin- ausgegangen werden kann. Mein Hauptanliegen ist es aber, in dieser tektonischen Weiterentwicklung einen wich- tigen Punkt nicht untergehen zu lassen: So erobert sich die IT-Abteilung mit den aus- greifenden Schritten von SAP BW die faktische Gestaltungsmacht über zentrale Con- trolling-Werkzeuge zurück. So waren es ja gerade wichtige Freiheitsgrade, die die einfach und komfortabel zu modellierenden OLAP-Systeme den Fachabteilungen erschlossen haben. Hier sehe ich auch die eigentlich entscheidenden Fragestellungen: Es entsteht ein Lösungsraum, der geeigneter Strukturierung bedarf. Die konkrete Herausforderung liegt nun darin, für jede Aufgabe das geeignete Werkzeug einzusetzen und den Ein- satz von SAP BW und/oder TM1 als Vertreter verschiedener Systemklassen aus dem Bereich Business Intelligence entsprechend zu gestalten. Von entscheidender Bedeutung für diese Fragen der Werkzeugauswahl und -gestal- tung ist die Einbindung der Controlling-Bereiche: so wird doch über deren analytische Wertschöpfungsmöglichkeiten bestimmt. Hierbei ist ein vorausschauender Blick es- sentiell, denn es kann nur zu gut prognostiziert werden, dass sich die Einsatzpoten- ziale von Warehouse- und OLAP-Lösungen künftig noch sehr viel stärker fortentwi- ckeln werden. So muss hier gefordert werden, dass Controlling weiterhin treibende Kraft seiner Werkzeugentwicklung und Weiterentwicklung bleiben muss. Als oberste Maxime muss gefordert werden, dass kein Fall eintreten darf, in dem Controlling plötzlich nicht mehr über ein eigenes Instrumentarium verfügen kann, dass hohe Flexibilität gewährleisten kann. So werden Controller etwas die Flexibilität und Leistungsfähig- keit von TM1 nicht mehr missen wollen. Zur Fragestellung „To SAP or Not to SAP“ gilt allerdings: sine qua non. NetSkill AG Competence Site: Integrationskonzepte für die Business Intelligence Welt Wenn SAP und Spezialisten heute noch jeweils spezifische Stärken aufweisen, wie sehen dann die integrativen Lösungen aus? Welche Aufgaben übernehmen die Teil- komponenten jeweils im Gesamtszenario? Wie sehen dabei die Schnittstellen aus? Professor Grothe: In den aufgenommenen Fallstudien wurden drei Basiskonstellationen erkannt, in de- nen Unternehmen TM1 und SAP / SAP BW einsetzen: 1. In vielen Fällen wird eine sehr dichte Integration beider Systemwelten realisiert, zumeist mit SAP als führendem System. 2. In anderen Konstellationen wird ein OLAP-System als flexibles "Produktionssys- tem" für Planungs- und Berichtszwecke genutzt. 3. In wieder anderen Fällen werden lediglich kleinere, singuläre Randthemen mit multidimensionalen Werkzeugen realisiert. Wesentlicher Unterschied in diesen Clustern sind die Schnittstellen zwischen den Systemen. 1. Die häufigste Konstellation nutzt die Integrationsmöglichkeiten zwischen OLTP und OLAP, zwischen SAP und TM1. In der grundsätzlichen Aufteilung findet die um- fassende Datenhaltung in SAP, die Analyse und Berichtserstellung in TM1 statt. E- benso wird die Erfassung neuer Daten im Rahmen der Planung zumeist in TM1 rea- lisiert. So werden die Ist-Daten aus SAP regelmäßig in das OLAP-System exportiert. Dieser Exportprozess ist durch besondere Tools gut unterstützt (Turbo-Integrator, csv- Dateien). Hierbei sind nicht nur die eigentlichen Daten, sondern auch die Strukturdi- mensionen (etwa Kostenstellenhierarchien, Kostenarten, Produkte) übertragbar. Damit kann das multidimensionale Modell quasi „on the fly“ aktualisiert werden und SAP als das führende System in allen Strukturfragen positioniert werden. Die Erhebung der Plandaten im Planungs-, Hochrechnungs- und Budgetierungspro- zess wird dagegen sehr effizient direkt in entsprechend aufbereiteten Eingabemas- ken des OLAP-Systems abgebildet. Eine durchaus übliche „Knetphase“ im Budget- prozess, das Spiel mit quantitativen oder sogar strukturellen Szenarien kann auf die- NetSkill AG se Weise transparent und strukturiert begleitet werden. Erst der abgestimmte Plan wird in das SAP-System überführt. Am Beispiel der Berliner Wasserbetriebe wird deutlich, dass auch sehr detaillierte Planungsmodelle auf diese Weise abgebildet werden können. Ebenso ist die Einbin- dung von ausführlichen, Excel-basierten Modellen in diesen Prozessen umsetzbar. Damit bietet diese Integrationskonstellation die sehr wertvolle Verbindung eines leis- tungsfähigen Planungs- und Analysesystems mit der aktuellen und vollständigen Da- tenbasis. Gleichzeit kann basierend auf dieser Architektur ein spezifisches Berichts- wesen aufgesetzt werden. 2. Die zweite Konstellation setzt OLAP-Systeme als zentrale Verdichtung von zu- meist dezentral bereitgestellter Information ein. Etwa ein Konzernberichtswesen kann so organisiert werden: ! Gesellschaften in der Berichtspflicht stellen ihre Daten in standardisierten Tabel- len (in aller Regel Microsoft Excel) zur Verfügung, die dann in die zentrale Wür- felstruktur eingelesen werden. ! Die zuliefernden Einzelgesellschaften setzen in der Regel unterschiedliche opera- tive Systeme ein, auch SAP ist nicht überall durchgängiger Standard. Aus diesen Vorsystemen werden die Daten lokal in die Tabellenwerke exportiert. ! Das zentrale Modell ist Basis für das Berichtswesen an die Unternehmensführung und die Gesellschaften. Auf Basis einer solchen Architektur konnte etwa die Aufnahme von Chrysler Finance in den Berichtsraum der neu fusionierten DaimlerChrysler Services AG innerhalb von nur zwei Wochen realisiert werden. Eine sehr interessante Entwicklungsperspektive dieser Grundkonstellation betreibt ein deutscher Großkonzern aus dem Zulieferbereich: Hier wird die Durchdringung mit durchgängigen OLAP-Systemen aus der Zentrale in die elf Unternehmensbereiche fortgeschrieben, so dass auch auf der zweiten Ebene mit dieser Flexibilität gearbeitet werden kann. Lediglich die ca. 150 Unternehmen innerhalb der Bereiche liefern dann noch Tabellenwerke zu. 3. In der dritten Konstellation bestehen im Großen und Ganzen keine Schnittstellen zu Umsystemen. Beispielhafte Anwendungsfälle können etwa das Umweltberichts- wesen oder das Risikomanagement sein.