200604-BI-Applix
|
|
|
»manage
it«
als
|
Fallstudien und Entwicklungstendenzen im Bereich Business Intelligence OLTP goes OLAP Die eindeutige Zuordnung von transaktionsorientierten und analytischen Aufgaben zu getrennten Systemfamilien weicht allmählich auf. So erweitert sich einerseits das Lösungsspektrum von SAP-Anwendungen zunehmend in Richtung flexibler Instrumente. Aber nicht nur die Transaktionssysteme bewegen sich. Auch viele OLAP-Lösungen entwickeln sich funktional weiter.
1. Einordnung der Studie Diese Studie dient dazu, Entwicklungen in der systemgestützten Controllingunterstützung erkennen und Entscheidungen in ihren Auswirkungen besser abschätzen zu können. Hierbei steht das Zusammenspiel von OLTP- und Data-Warehouse-Lösungen mit multidimensionalen OLAP-Systemen im Mittelpunkt. Insbesondere wirft die fortschreitende Entwicklung und Einführung von SAP BW mitsamt dem Business Explorer Fragen nach der Integration von bestehenden OLAP-Systemen auf. Als Bezugssystem wurde Applix TM1 herangezogen. Die Studie gründet sich auf die Diskussion konkreter Anwendungserfahrung und Einblicke in bestehende betriebliche Anwendungen von SAP BW und Applix TM1 bei den Berliner Wasserbetrieben, der Daimler Chrysler Services AG, Deutsche Lufthansa AG und der ZF Friedrichshaften AG. Dieser Beitrag fasst die Studie zusammen, die komplett, inklusive der Beschreibungen der Unternehmenslösungen unter http://www.applix.com einsehbar ist.
1.1 Aktuelle Fragestellung und Zielsetzung Diese Studie soll eine gute Grundlage bieten, um · Entwicklungen im Bereich systemgestützter Controllingunterstützung besser erkennen und beurteilen zu können und · Entscheidungen in diesem Bereich in ihren Auswirkungen besser abschätzen zu können. Hierbei steht aus Gründen stetig zunehmender Entscheidungsreife das Zusammenspiel von klassischen OLTP- und Data-Warehouse-Lösungen mit multidimensionalen OLAP-Systemen im Mittelpunkt des Interesses. Insbesondere wirft die fortschreitende Entwicklung und Einführung von SAP BW mitsamt dem Business Explorer Fragen nach der Integration von zum Teil bereits seit langem bestehenden OLAP-Systemen auf. Als Bezugssystem wird im folgenden Applix TM1 herangezogen. Somit gilt es zunächst, die vorherrschenden Entwicklungstendenzen mit ihren wahrscheinlichen Auswirkungen transparent zu machen. Es zeigt sich, dass weit mehr Implikationen zu beachten sind, als der erste flüchtige Blick vermuten lässt. Ebenso wird in der Folge deutlich, dass es das »typische« OLAP-Anwendungssystem nicht gibt. Die Flexibilität dieser Werkzeuge erlaubt es den Fachabteilungen (!) in Unternehmen, auch für sehr spezifische Strukturen und Prozesse jeweils ohne prohibitiven Aufwand spezifisch geeignete Systeme aufzubauen. Aus einer ganzen Reihe von Fallstudien konnten drei große Einsatzkonstellationen destilliert werden. In diesen Clustern ergeben sich jeweils andere Aufgabenverteilungen, betrachtet man OLTP und OLAP im Zusammenhang. Ebenso sind die Fragen der Integration und der Schnittstellengestaltung jeweils unterschiedlich zu beurteilen und auszurichten. Insgesamt wird als Ergebnis deutlich, dass das Controlling OLAP-Systeme als ein eigenes und flexibles Werkzeug außerordentlich gut angenommen hat. Schnelle und insbesondere fallweise Anforderungen werden so effizient umsetzbar. Als betriebswirtschaftliches Basisaxiom gilt hier, dass fallweise und generelle Regelungen unterschiedlich behandelt werden müssen. Das Substitutionsgesetz folgert weiter, dass ab einem bestimmten Grad an Unveränderlichkeit und Konstanz eine generelle Regelung gefunden werden sollte. In der Entsprechung finden hier OLTP und Data Warehouse ihren Platz.
1.2 Entwicklungstendenzen der Controlling-Unterstützung Mit der Einführung von OLAP-Systemen bekam das Controlling ein Gestaltungswerkzeug in die Hand, das bisher unerreichte Flexibilität und, wichtiger noch, weitgehende Autarkie von Systementwicklern und Abfrageprogrammierern erschloss. Die Reichweite dieser zugewachsenen Gestaltungskraft wird durch Dauerdiskussionen mit den IT-Administrationen nur zu deutlich unterstrichen; so drängen diese – zu Recht! – auf eine zentrale Aufstellung und Einhaltung von Standards der betrieblichen IT-Systeme und -Organisationen. Interessanterweise beruhte gerade der Siegeszug von OLAP-Anwendungen in der überwiegenden Mehrzahl der Fälle auf dem Rückgriff auf einen eingeführten Standard. So sind Anwendungen in verteilten Umgebungen ohne die Vorprägung durch Microsoft Excel kaum denkbar. Auf dieser Grundlage konnte sich eine klare Trennung zwischen primär transaktionsbasierten und analytischen Systemwelten aufbauen: · Online Transaction Processing (OLTP) und · Online Analytical Processing (OLAP), beide Anwendungsklassen mit jeweils eigenen Optimierungszielrichtungen. TREND: In dieser Arbeitsteilung zwischen OLTP- und OLAP-Systemen, die auf der einen Seite für Transaktionen essentielle 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: Das Vordringen der OLTP-Systeme in den analytischen Aufgabenbereich. Diese Tendenz kommt nicht von ungefähr, sondern ist eine in der Architektur langfristig angelegte Entwicklung, die auf die Verdichtung und weitere Aufbereitung der originären Daten hinausläuft. So setzt das SAP Business Warehouse (BW) idealtypisch auf einem R/3-Basissystem auf (was jedoch nicht zwingend ist). Es erschließen sich Vorteile bei überwiegendem oder ausschließlichem Einsatz von SAP R/3 durch die sehr homogenen EDV-Landschaft. Dahinter verbirgt sich jedoch mehr als eine Erfüllung der grundsätzlich nicht unberechtigten Forderung nach möglichst einheitlichen Systemlandschaften. Wird dieser Wandel durch das Controlling nicht proaktiv erkannt und mitgestaltet, dann kann hier Stagnation oder sogar ein Rückschritt in der analytischen Leistungskraft entstehen. · Hierbei stehen gar nicht die Aspekte Bedienbarkeit und Nutzerunterstützung (zum Beispiel im Kontext der Verwaltung der Arbeitsmappen) im Vordergrund: in mittlerer Frist werden die OLTP-Extensionen mit Sicherheit aufholen und (hoffentlich) auch auf die ursprünglichen Transaktionssysteme zurückwirken. · Viel gewichtiger ist der sich in der Projektion im Controlling abzeichnende Verlust der Gestaltungsmacht über eigene Unterstützungswerkzeuge: So können mit OLAP-Systemen schnell und effizient auch begrenzte Aufgaben gelöst werden, OLTP-basierte Warehouse-Lösungen haben immer eine ganzheitliche Reichweite und müssen damit durch die zentrale IT-Administration geführt werden. · Von diesen Punkten unberührt und weitgehend unbemerkt besteht noch ein weiterer Unterschied, der gravierende Auswirkungen haben wird: In der Datenmodellierung folgen OLTP und OLAP andersartigen Philosophien. o OLTP-Systeme, in denen letztlich die Verwaltung sehr großer Beleganzahlen im Mittelpunkt steht, folgen aufgrund dieser Listenbasis relationalen Datenmodellen. Folglich sind aufbauende analytische Module auch in der Regel als ROLAP (relationales OLAP) zu bezeichnen. So hat auch das SAP Business Information Warehouse eine multidimensionale Datenhaltung mit erweitertem Star-Schema in einem relationalem Datenbanksystem (für die Definition und Administration in der Administrators Workbench ist darüber hinaus ein Datenbankadministrator oder Entwickler erforderlich). o OLAP-Systeme, in denen die schrittweise multidimensionale Analyse und Veredelung der Information angestrebt wird, greifen in der Regel auf einen zellwertorientierten Ansatz zurück. Hier ist von MOLAP (multidimensionales OLAP) zu sprechen. · Der Unterschied wird genau dann plastisch, wenn ein jeweils angefertigter Analyse-Schnitt aktualisiert werden soll: Ein MOLAP-System zieht die neuen Daten aus dem entsprechenden Würfel und füllt die definierte Struktur. Ein ROLAP-System baut die Tabellenstruktur wieder zeilenweise auf und überschreibt dabei etwaige Zwischenzeilen oder andere bereichsspezifische Änderungen am Zeilenaufbau. · Weiterhin sind Schreibzugriffe sowohl in einem operativen System oder Data Warehouse eher unüblich. Dies mag für Prozesse des Berichtswesens hinnehmbar, für Aufgaben im Bereich von Planung und Budgetierung jedoch schlichtweg nicht akzeptabel sein. Damit sind in ganz unterschiedlichen Bereichen (Gestaltbarkeit, Berichtsaufbau, dezentrale Prozesse, Bedienbarkeit) teilweise gravierende Einschränkungen prognostizierbar. Auch einige in den jeweils bestehenden Anwendungsmodellen bereits gelöste Aufgaben werden wieder zu offenen Baustellen werden. So muss in vielen Fällen sicherlich für eine längere Zeitspanne der Erhalt der bestehenden Abbildungs- und Erklärungskraft als oberstes Ziel definiert werden. Hierbei gilt gleichwohl, dass die Auswirkungen dieses Wandels nicht für alle aufgebauten Systeme in gleichem Maße zutreffen werden. So scheint es ratsam, zunächst verschiedene Konstellationen darzustellen, um dann zu Aussagen zur sich abzeichnenden Aufgabenverteilung zu gelangen.
1.3 Hintergrund: SAP Business Warehouse Diese Studie nimmt nicht Bezug auf ein konkretes Release der diskutierten Softwareprodukte. Zum einen ist der eingesetzte Stand in den zugrunde liegenden Fallstudien naturgemäß unterschiedlich, zum anderen gilt es hier vielmehr, Entwicklungslinien aufzuzeigen und nicht release-bezogene Verbesserungsschritte nachzuzeichnen. Als große Linie ist das Business Warehouse in der SAP-Landschaft als zentrale Reporting-Engine vorgesehen, um die Berichtsprobleme im OLTP zu überwinden; die Analyseteile entstehen im Nachgang. Das Business Warehouse hat damit das Ziel, alle jene Daten, welche im OLTP (bzw. ERP Enterprise Resource Planning)-System »versteckt« sind, für Analysen zugänglich zu machen und gleichzeitig das Warehouse vom SAP R/3-System (mit seiner OLTP Charakteristik) zu entkoppeln.
Die folgende Abbildung zeigt diese Architektur in der Übersicht.
Abbildung 1: Architektur mySAP BI / Offene Plattform. [Quelle: SAP AG 2002] Die Abbildung zeigt, dass · zum einen als Datenquellen nicht nur SAP R/3-Applikationen, · zum anderen als Analysewerkzeuge nicht nur der SAP BW Explorer, sondern auch Applikationen anderer Hersteller (»3rd party«) zum Einsatz kommen können. Weiterhin ist als Reaktion auf eine oftmals als langsam wahrgenommene Entwicklung der SAP SEM-Lösungen (Strategic Enterprise Management) nunmehr der Planungsteil aus dem SAP SEM-BPS-Modul (Business Planning and Simulation XE "Business Planning and Simulation" ) im BW als analytische Komponente verfügbar. Damit werden auch Schreibzugriffe auf das Data Warehouse möglich. Die Philosophie von SAP spiegelt sich in der technischen Realisierung des Business Warehouses wider: · Die Cubes (Datenwürfel) existieren unabhängig voneinander und werden durch SAP-Tabellen mit Daten versorgt. Änderungen in diesen Tabellen führen zu nachgelagerten Anpassungen im Business Warehouse, da betroffene Cubes mitunter neu aufgebaut werden müssen. · Diese Eigenständigkeit der Cubes erfordert separate Interfaces und erhöht damit die Komplexität beim Anlegen und im laufenden Betrieb des Business Warehouses. · Die Redundanz der Daten in den Cubes ist hoch, da für jede Sicht auf die Daten ein separater Cube erstellt werden muss. · Die Verwendung von historischen Daten in Cubes hat direkte Konsequenzen auf die SAP Applikationen, da die Größe des Systems wächst und Transaktionen dadurch verlangsamt werden können. Da jeder Cube auf viele Tabellen zugreifen können muss, wurde eine Zwischenschicht (Staging Area) eingeführt, die für das Laden der Daten zuständig ist und ein Recovery ermöglicht: · Die Synchronisierung der Cubes ist schwierig, da jede Transaktion Veränderungen durchführt, die in der Staging Area berücksichtigt werden. Werden diese Updates nicht sofort an die davon abhängigen Cubes weitergeleitet, dann werden in den Analysen teilweise veraltete Ergebnisse verwendet. · Die Granularität der Daten innerhalb der SAP Staging Area ist nicht konsistent, da die einzelnen Tabellen Daten von unterschiedlicher Granularität enthalten. Einerseits werden Transaktionsdetails, andererseits auch voraggregierte Daten verarbeitet. · Auf die Daten der Staging Area kann nur mit Hilfe des SAP OLAP-Tools unmittelbar zugegriffen werden. OLAP Tools von anderen Herstellern können auf die SAP OLAP Engine mittels eines Interfaces zugreifen. Diese Tools unterliegen somit den Beschränkungen der SAP OLAP Engine, wodurch die Funktionalität im Vergleich zum teilweise höheren Niveau bestehender OLAP-Tools verringert wird. Das häufige Performance-Problem von BW-Anwendungen hängt auch stark von der verwendeten Datenbank ab. So wird das originäre Datenmodell mitunter im Einführungsprojekt weitgehend neu modelliert. Vielfach wird auch von der Verwendung der Rollen, Queries und Arbeitsmappen abgeraten. Insgesamt ergeben sich durch diese Datenmodell-Thematik und der Ansatz der BW-Zentralität mitunter auch unerwartete Probleme der Datenkonsistenz und des propagierten »Single Point of Truth«. So muss als ein Nachteil des BW herausgestellt werden, dass die Komplexität beträchtlich ist und das System eine schwere Zugänglichkeit für den Nutzer aufweist. Dies jedoch soll nicht über bestehende Vorteile hinwegtäuschen, sondern vielmehr dazu dienen, die Zusammenstellung und das Zusammenspiel mit anderen Anwendungen zu optimieren.
2. Basiskonstellationen In den aufgenommenen Fallstudien wurden drei Basiskonstellationen erkannt, in denen Unternehmen Applix 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 »Produktionssystem« 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.
2.1 Integration beider Systemwelten Die häufigste Konstellation nutzt die Integrationsmöglichkeiten zwischen OLTP und OLAP, zwischen SAP und Applix TM1. In der grundsätzlichen Aufteilung findet die umfassende Datenhaltung in SAP, die Analyse und Berichtserstellung in Applix TM1 statt. Ebenso wird die Erfassung neuer Daten im Rahmen der Planung zumeist in Applix TM1 realisiert. 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 Strukturdimensionen (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 Budgetierungsprozess wird dagegen sehr effizient direkt in entsprechend aufbereiteten Eingabemasken des OLAP-Systems abgebildet. Eine durchaus übliche »Knetphase«, das Spiel mit quantitativen oder sogar strukturellen Szenarien kann auf diese 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 Einbindung von ausführlichen, Excel-basierten Modellen in diesen Prozessen umsetzbar. Damit bietet diese Integrationskonstellation die sehr wertvolle Verbindung eines leistungsfähigen Planungs- und Analysesystems mit der aktuellen und vollständigen Datenbasis. Gleichzeit kann basierend auf dieser Architektur ein spezifisches Berichtswesen aufgesetzt werden.
2.2 OLAP als flexibles Produktionssystem für Planung und Reporting Die zweite Konstellation setzt OLAP-Systeme als zentrale Verdichtung von zumeist dezentral bereitgestellter Information ein. Ein Konzernberichtswesen kann etwa so organisiert werden:
Auf Basis einer solchen Architektur konnte etwa die Aufnahme von Chrysler Finance in den Berichtsraum der neu fusionierten Daimler Chrysler Services AG innerhalb von nur zwei Wochen realisiert werden. Eine sehr interessante Entwicklungsperspektive dieser Grundkonstellation betreibt ein deutscher Großkonzern aus dem Automobilzulieferbereich: 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.
2.3 Randthemen mit multidimensionalen Werkzeugen In der dritten Konstellation bestehen im Großen und Ganzen keine Schnittstellen zu Umsystemen. Beispielhafte Anwendungsfälle können etwa das Umweltberichtswesen oder das Risikomanagement sein. Hier treten drei Merkmale hervor:
Im Bereich dieser Konstellation liegen auch Einsatzbereiche, die erst allmählich aufgenommen werden: So kann zum Beispiel auch ein einfaches Scoringmodell sehr schnell aufgebaut und in Entscheidungsprozessen eingesetzt werden.
3. Effizienzdomänen und Aufgabenverteilung Der Praxisblick zeigt sehr deutlich, dass beide Notwendigkeiten ihren Platz haben:
Damit verlagert sich die Frage von einem mitunter geäußerten »entweder/oder« zu der Suche nach hilfreichen Kriterien für die Entscheidung, welche anstehende Aufgabe mit welchem Werkzeug am Besten unterstützt werden kann. Hierzu liefern die Fallstudien gutes Anschauungsmaterial; es gilt, die Lessons Learned in Bezug auf die unterschiedenen Aufgaben- und Einsatzbereiche aufzunehmen.
3.1 Einordnung in der Business Intelligence-Matrix Die häufig relativ unklar geführte Diskussion zur Aufgabenverteilung von SAP BW und Applix TM1 kann in einer übersichtlichen Struktur grundsätzlich dargestellt werden. Die Business Intelligence-Matrix gliedert Methoden und Werkzeuge zunächst auf Basis ihrer Datengrundlage und der Ausrichtung der entsprechenden Entdeckungsprozesse. Diese Prozesse werden dann in die Phasen Datenbereitstellung, Entdeckung und Kommunikation differenziert.
Abbildung 2: Business Intelligence-Matrix (Grothe/Gentsch 2000) Hierbei wird sehr deutlich, dass der Bereich SAP im der Bereitstellungsstufe zu verorten ist, während die OLAP-Anwendungen primär auf die Entdeckung von Mustern und Zusammenhänge zielen. Es ist wichtig herauszustellen, dass beispielsweise SAP BW auf das Vorhandensein einer Bereitstellungsstufe in Form einer SAP R/3-Anwendung ausgelegt ist, wenngleich auch andere Datenquellen aufgenommen werden können. Dahingegen umfassen gängige OLAP-Lösungen wie Applix TM1 eine eigenständige Datenhaltung.
3.2 Herausforderung »Beyond Budgeting« Die Standardisierung von Abläufen durch umfassende SAP-Applikationen mag für bestimmte Prozesse ein großer Vorteil sein. Gerade im Controlling verstärkt sich jedoch eine Auffassung, die das starre Gerüst der etablierten Budgetierungs- und Planungsprozesse wieder sehr drastisch zurückführen will. Unter dem Label »Beyond Budgeting« wird dagegen quasi permanente Planung und Hochrechnung (Forecasting) als Vorgehensmodell propagiert, um intern mit der notwendigen Flexibilität auf Veränderungen zumindest reagieren, idealerweise aber auch proaktiv agieren zu können. Hierzu werden Werkzeuge benötigt, die auch losgelöst von bestehenden Strukturen mit parallelen Szenarien umgehen können. Anpassungen müssen schnell und hochflexibel umsetzbar sein. Warnfunktionen und Workflows müssen ebenso unterstützt werden wie dezentrale Zusammenarbeit. Applix verfolgt diese Philosophie mit Integra, dessen Kernelement Applix TM1 ist. In dieser Domäne »Beyond Budgeting« können sich OLTP-Systeme nicht behaupten. Für OLAP-Systeme entsteht jedoch ein Einsatzbereich, in dem ihre immanenten Vorteile im Bereich der Geschwindigkeit und Flexibilität massiv zum Tragen kommen.
4. Ausblick Vor dem Hintergrund der Entwicklungstendenzen und Fallstudien wird deutlich, dass die eindeutige Zuordnung von transaktionsorientierten und analytischen Aufgaben zu getrennten Systemfamilien aufweicht. So erweitert sich einerseits das Lösungsspektrum von SAP-Anwendungen zunehmend in Richtung flexibler Instrumente, 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:
Ein langjähriger Applix TM1-Gestalter wies in seinem »Beste-aller-Welten-Szenario« noch auf einen weiteren Bereich hin, der mit dem Cube Viewer und seiner Flexibilität erschlossen werden könnte: das SAP Business Warehouse. Prof. Dr. Martin Grothe ___________________________________________________________ Prof. Dr. Martin Grothe, Geschäftsführer der Complexium GmbH und Gastprofessor am Institute of Electronic Business, einem An-Institut der Universität der Künste Berlin
|
Folgen Sie »manage it« auf Google+
| |||||||||||||||||||||||
