In order to draw conclusions from bugs in production or further development, a complete high quality documentation is necessary. The manual creation of technical documentation in SAP Business Information Warehouse (BW) needs a lot of time in the wheel of deployment and the result does not meet the main requirements at FinanzIT. This is the reason why the staff of the SAP BW group is interested in a new solution, which can automatically create a technical documentation for the SAP BW environment. The following paper aims to describe the procedure of selecting the best software-solution to achieve the objectives und solve the current problems.
To make the reader familiar with the problem we are faced with, the first part explains the background of general documentation and the SAP module BW, an information system for management. The presentation of theoretical process models describes the different phases of evaluating software. These findings are then applied to the actual implementation. After analysing possible solutions, only four alternatives come into consideration. In addition to two external software providers, the options are to either make a proprietary development or to do nothing, maintain the current method and accept the situation.
With the aid of the “Analytic Hierarchy Process” (AHP), it is possible to select the best option and to calculate the individual benefits. Its application demonstrates that the proprietary development alternative is the most beneficial. In the next step, the
individual costs have to be considered.
Although the preferred alternative to create an own solution is, in the face of investitions, not the cheapest option, it would have the best cost-benefit ratio. This finding results in a recommendation to continue with the implementation of the own solution.
Inhaltsverzeichnis
Sperrvermerk
Inhaltsverzeichnis
Abkürzungsverzeichnis
Abbildungsverzeichnis
Abstract
1 Einleitung
1.1 Problemdefinition
1.2 Motivation und Zielsetzung
1.3 Vorgehensweise und Themenabgrenzung
2 Hintergründe zur Notwendigkeit einer Dokumentation im SAP BW
2.1 Dokumentation
2.1.1 Begriff und Einordnung
2.1.2 Bedeutung einer Dokumentation
2.1.3 Anforderungen einer Dokumentation
2.1.4 Begriff Metadaten
2.2 Vorstellung SAP BW
2.2.1 Die 3-Ebenen-Architektur
2.2.2 Datenfluss
2.2.3 Metadata Repository
3 Methodik zur Evaluierung von Software
3.1 Vorgehensmodelle zur Softwareauswahl
3.1.1 Typische Phasenmodelle
3.1.2 FinanzIT Prozess „Tool einführen“
3.1.3 Vorgehensweise in der Praxis
3.2 Prozessschritte in der Praxis
3.2.1 Analyse der Ist-Situation
3.2.2 Anforderungsanalyse
3.2.3 Kriterienkatalog
3.2.4 Marktanalyse
3.2.5 Entscheidung
3.3 Vorstellung der Alternativen
3.3.1 Bisheriges Vorgehen
3.3.2 Eigenentwicklung
3.3.3 CubeServ BW Documentation Tool
3.3.4 MARCO
3.4 Entscheidungsmethodik
3.4.1 Bewertung der Alternativen
3.4.2 Durchführung des Analytic Hierarchy Process
3.4.3 Nutzen/Kosten-Verhältnis
4 Fazit und Empfehlung
Anhangverzeichnis
Anhang
Quellenverzeichnis
Abkürzungsverzeichnis
Abbildung in dieser Leseprobe nicht enthalten
Abbildungsverzeichnis
Abbildung 1: Entscheidungsprozess nach Heinen
Abbildung 2: 3-Ebenen Architektur des SAP BW
Abbildung 3: Datenfluss vom Quellsystem bis zum Reporting
Abbildung 4: Beispiel aus dem Metadata Repository
Abbildung 5: Phasenmodell nach Schinzer
Abbildung 6: Phasenmodell nach Kremer
Abbildung 7: Phasenmodell nach Lang
Abbildung 8: Phasenmodell nach Brenner
Abbildung 9: Phasenmodell nach Stahlknecht/Hasenkamp
Abbildung 10: Prozess „Tool einführen“
Abbildung 11: Phasenmodell für die vorliegende Arbeit
Abbildung 12: Teilschritte der Marktanalyse
Abbildung 13: Anbieterliste nach Marktübersicht
Abbildung 14: Vorgehen zur Eigenentwicklung
Abbildung 15: Vergleich der Querydokumentation
Abbildung 16: Vorgehen von MARCO
Abbildung 17: Klassische Methoden zur Nutzenanalyse und Einordnung AHP
Abbildung 18: Ergebnis des AHP
Abbildung 19: Nutzenwerte der Alternativen
Abstract
In order to draw conclusions from bugs in production or further development, a complete high quality documentation is necessary. The manual creation of technical documentation in SAP Business Information Warehouse (BW) needs a lot of time in the wheel of deployment and the result does not meet the main requirements at FinanzIT. This is the reason why the staff of the SAP BW group is interested in a new solution, which can automatically create a technical documentation for the SAP BW environment. The following paper aims to describe the procedure of selecting the best software-solution to achieve the objectives und solve the current problems.
To make the reader familiar with the problem we are faced with, the first part explains the background of general documentation and the SAP module BW, an information system for management. The presentation of theoretical process models describes the different phases of evaluating software. These findings are then applied to the actual implementation. After analysing possible solutions, only four alternatives come into consideration. In addition to two external software providers, the options are to either make a proprietary development or to do nothing, maintain the current method and accept the situation.
With the aid of the “Analytic Hierarchy Process” (AHP), it is possible to select the best option and to calculate the individual benefits. Its application demonstrates that the proprietary development alternative is the most beneficial. In the next step, the individual costs have to be considered.
Although the preferred alternative to create an own solution is, in the face of investitions, not the cheapest option, it would have the best cost-benefit ratio. This finding results in a recommendation to continue with the implementation of the own solution.
1 Einleitung
In diesem Kapitel findet eine Einführung in das komplexe Thema „Auswahl einer Softwarelösung zur Erstellung einer automatisierten technischen Dokumentation für das SAP Business Information Warehouse in der FinanzIT GmbH“ statt. Dabei soll dem Leser zunächst die grundlegende Problematik aufzeigt werden, aus der die vorliegende Arbeit resultiert. Anschließend werden die Ziele des Unternehmens und die persönliche Motivation des Autors erläutert, sowie die Vorgehensweise und der Aufbau der Arbeit erklärt, damit der rote Faden beim Lesen erkennbar ist.
1.1 Problemdefinition
Die FinanzIT GmbH ist mit rund 2.700 Mitarbeitern und Umsatzerlösen von über 700 Mio. Euro das IT-Systemhaus für Sparkassen, Landesbanken und Landesbausparkassen in elf Bundesländern. Ein IT-Unternehmen dieser Größenordnung stellt von Haus aus hohe Anforderungen an Dokumentationen. Bei der täglichen Arbeit in der OE 4140 (Entwicklung und Integration Rechnungswesen) hat sich herausgestellt, dass auch im SAP Business Information Warehouse (im Folgenden SAP BW genannt) Umfeld der FinanzIT die technische Dokumentation eine große Bedeutung hat. Um Rückschlüsse auf Produktionsfehler oder Weiterentwicklungen zu bekommen, kann eine lückenlose und qualitativ hochwertige Dokumentation sehr wertvoll sein. In der Praxis wird die Dokumentation zurzeit teilweise auf Basis des Metadata Repositories (siehe Kapitel 2.2.3) manuell in einem Word-Dokument erstellt. Dieses Verfahren bringt einige zum Teil gravierende Probleme mit sich. Die manuelle Erstellung erfordert einen unnötig hohen Zeitaufwand, der im Entwicklungszyklus einen Anteil von ca. 20 %1 einnimmt. Dabei ist die eigentliche Arbeit nicht schwierig, da lediglich die getätigten Einstellungen in ein zentrales Dokument übertragen werden müssen. In der Praxis werden also die Systemeinstellungen detailliert recherchiert und anschließend in ein aufwendiges Word-Dokument möglichst übersichtlich eingefügt. Bei diesem Vorgehen besteht daher immer die Gefahr von menschlichen Fehlern (eine Einstellung wird übersehen oder falsch übertragen), die nicht gänzlich ausgeschlossen werden können. Da mehrere Mitarbeiter das Dokument pflegen und es noch keine bindenden Richtlinien zur Formatierung und Strukturierung gibt, ist dieses Dokument mit der Zeit immer unübersichtlicher geworden. Da der technischen Dokumentation im SAP BW jedoch eine große Bedeutung zukommt und einige Anforderungen erfüllt sein müssen, wurde der Gedanke nach einer neuen maschinellen Lösung zu suchen immer deutlicher. Dabei stellte sich nach einigen Diskussionen innerhalb der Fachgruppe SAP BW, sowie bei fachlichen Gesprächen mit externen Beratern heraus, dass eine softwaregestützte Lösung angestrebt werden sollte, da es bereits einige spezialisierte Anbieter auf diesem Gebiet gibt. Die damit verbundenen Zielsetzungen und die Motivation, die sich in der vorliegenden Bachelor Thesis ergaben, sollen im nächsten Abschnitt genauer erläutert werden.
1.2 Motivation und Zielsetzung
Wie soeben beschrieben, steht im Mittelpunkt der vorliegenden Bachelor Thesis die Vorarbeit, die bei der Durchführung eines Entscheidungsprozesses zur Auswahl eines Dokumentationstools unterstützen soll. Das entsprechende Ziel dieser Arbeit ist es, eine Empfehlung zur Auswahl einer geeigneten Softwarelösung geben zu können. Für die FinanzIT GmbH als Unternehmen ergibt sich durch diese Arbeit die Möglichkeit, nach der Analyse die empfohlene Lösung produktiv einzusetzen und die damit verbundenen Vorteile und Möglichkeiten zu nutzen. Die Zielsetzungen der FinanzIT sind dabei differenziert zu betrachten, da minimale und optionale Anforderungen definiert worden sind, um die auszuwählende Softwarelösung zu evaluieren. Oberste Priorität und damit das minimale Ziel bei der Auswahl einer geeigneten Softwarelösung ist die schlichte automatisierte Dokumentation der Berichtseinstellungen. Besonders in diesem Bereich unterstützt das SAP BW Metadata Repository (siehe Kapitel 2.2.3) nur ungenügend. Ebenfalls ein minimales Ziel ist die Versionisierung der erstellten Dokumentation, um eine lückenlose Änderungshistorie zu erreichen, die einen Nachweis für den Fachbereich darstellt. Die Überlegungen im Vorfeld gehen aber noch ein paar Schritte weiter und verdichten sich in eine Art Vision. So verfolgt das maximale Ziel, neben der Dokumentation aller Objekte des Daten]modells, zusätzlich die Möglichkeit, Freitexte und Kommentare für verschiedene Objekte zu hinterlegen, um auf besondere Sachverhalte hinweisen zu können oder auf besondere Einstellungen des Datenmodells oder der Datenübernahme aufmerksam zu machen. Auch die Möglichkeit einer Impactanalyse, die voneinander abhängige Objekte transparent darstellen kann, wäre wünschenswert. Generell sind also die Intentionen, die bei der Auswahl eines Dokumentationstool verfolgt werden, vielfältig. Sowohl quantitative Faktoren, wie die Verkürzung der Entwicklungszeit, als auch qualitative Faktoren, die die Fehlersuche erleichtern sollen, spielen eine Rolle.
Bei der Auswahl einer neuen Softwarelösung einen Beitrag zu leisten, ist aus Sicht des Autors herausfordernd und motivierend zugleich, da theoretische Erkenntnisse aus den Bereichen Dokumentation, SAP BW, Auswahlprozess und Entscheidung praktisch angewendet werden können. Darüber hinaus verknüpft das Thema sowohl DVtechnische als auch wirtschaftliche Aspekte und repräsentiert so wesentliche Inhalte eines Wirtschaftsinformatikstudiums.
1.3 Vorgehensweise und Themenabgrenzung
Wie der Lösungsweg in der vorliegenden Arbeit strukturiert ist, um die Motive der FinanzIT GmbH zu berücksichtigen, soll nun die Vorgehensweise vorgestellt werden. Um dem Leser ein Verständnis zur Notwendigkeit einer automatisierten Dokumentation zu liefern, werden in Kapitel 2 theoretische Grundlagen gelegt, die in zwei Bereiche unterteilt sind. Der erste Bereich gibt Hintergrundinformationen zur Dokumentation und stellt typische Anforderungen vor. Im Fokus des zweiten Bereiches steht eine kompakte Beschreibung des SAP BW-Moduls, in dem alle Objekte, die dokumentiert werden sollen, beschrieben und in einen theoretischen Zusammenhang gebracht werden. Im Kontext der gewünschten technischen Dokumentation der Metadaten von SAP BW wird so die grundlegende Problematik einer Dokumentation herausgestellt. Im Anschluss werden im Kapitel 3.1 unterschiedliche Vorgehensmodelle zur Auswahl von Software vorgestellt. Nach Analyse diverser theoretischer Modelle und dem betrieblichen Prozess der FinanzIT, werden die Erkenntnisse in ein individuelles Phasenmodell transformiert, welches den speziellen Anforderungen dieser Toolauswahl gerecht werden soll. Die praktische Durchführung der zuvor definierten Prozessschritte wird anschließend sukzessive erläutert und die jeweiligen Ergebnisse in angemessener Art und Weise in zusammengefasster Form präsentiert.
Nach dem in der Betriebswirtschaft bekannten Entscheidungsprozess nach Heinen2 gibt es zwei Hauptphasen, die in der Abbildung 1 skizziert sind. Die vorliegende Arbeit beleuchtet dabei lediglich die Phase der Willensbildung mit der Intention eine Empfehlung für eine optimale Alternative zu geben. Die anschließende zweite Hauptphase, die Willensdurchsetzung, ist nicht Bestandteil dieser Arbeit und findet daher im Folgenden keine Berücksichtigung.
Abbildung in dieser Leseprobe nicht enthalten
2 Hintergründe zur Notwendigkeit einer Dokumentation im SAP BW
Der Fokus in diesem Kapitel liegt auf allgemeine Hinweise zu einer Dokumentation. Im Zusammenhang mit den speziellen SAP BW Anforderungen soll dem Leser klar werden, warum eine Dokumentation im BW gebraucht wird und in welcher Hinsicht ein Dokumentations-Tool ein Mehrwert für das BW Umfeld erbringen könnte.
2.1 Dokumentation
Die Dokumentation gilt als ewiges Sorgendkind der Software-Entwicklung, da es eine lästige Daueraufgabe ist, die oft vernachlässigt wird.3 Doch damit das Wissen über das komplexe SAP BW Umfeld nicht verloren geht, müssen die Einstellungen dokumentiert werden. Dieses Kapitel gibt einen Überblick aller wichtigen Aspekte einer Dokumentation. Zunächst wird der Begriff definiert und in einen thematischen Zusammenhang zum SAP BW gestellt. Anschließend soll die Bedeutung von Dokumentationen im Allgemeinen, sowie der Nutzen für SAP BW im Speziellen, verdeutlicht werden. Da Dokumentationen ein vorgegebenes Schema folgen sollten, werden die grundsätzlichen Bestandteile und Anforderungen diskutiert und Hinweise zu einer qualitativ hochwertigen Dokumentation gegeben. Im letzten Schritt wird der Fokus auf die Metadaten (siehe Kapitel 2.1.4) gesetzt. Dieser Abschnitt ist auch gleichzeitig ausschlaggebend, um die Notwendigkeit einer Dokumentation im BW Umfeld zu unterstreichen. Am Ende sollte deutlich geworden sein, worauf man bei einer Dokumentation, speziell im SAP BW, achten sollte und welche Möglichkeiten ein Softwaretool zur automatischen technischen Dokumentation bieten könnte.
2.1.1 Begriff und Einordnung
Der Begriff Dokumentation wurde Anfang des 20. Jahrhunderts von Paul Otlet als „Sammlung, Ordnung und Nutzbarmachung von Dokumenten aller Art“4 definiert. Diese allgemeine Definition reicht für die spezielle Art der Dokumentation, mit der sich die vorliegende Arbeit beschäftigt, nicht aus. Um die in Kapitel 2.2 vorgestellten BW- Objekte mit allen Eigenschaften dokumentieren zu können, wird eine so genannte technische Dokumentation verwendet. Merkmal dieser Sonderform der Dokumentation ist die strukturierte Aufbereitung der Informationsinhalte, in der für einen bestimmten Zweck geforderten Art und Vollständigkeit.5 In der Praxis bedeutet dies, dass alle Einstellungen vollständig und lesbar niedergeschrieben sind, sowie Hinweise und Kommentare auf bestimmte Sachverhalte aufmerksam machen. Die technische Dokumentation dient somit als Nachschlagewerk, welches eine Vielzahl an technischen aber auch fachlichen Informationen beinhalten kann. Ziel sollte eine transparente und dauerhafte Archivierung aller notwendigen Informationen sein.
2.1.2 Bedeutung einer Dokumentation
Damit das Wissen über das SAP BW nicht verloren geht, ist eine technische Dokumentation notwendig. Eine gute Dokumentation ist dabei in mehrfacher Hinsicht von Bedeutung. Zum einen dient sie natürlich als Nachschlagewerk und erleichtert dem Leser die Recherche bei Fehlern oder Problemen. Zum anderen ist die Dokumentation auch bei Weiterentwicklungen von BW-Berichten hilfreich, um die bisherigen Lösungswege im Detail verfolgen zu können. Vor dem Hintergrund, dass Mitarbeiter krankheits- oder urlaubsbedingt nicht immer zu erreichen sind und die Informationen aus dem SAP BW Umfeld dennoch zur Verfügung stehen müssen, bekommt dieser Aspekt einen besonders hohen Stellenwert.
Darüber hinaus ist die Dokumentation ein hervorragendes Kommunikationsinstrument. Die Praxis zeigt, dass es oft zu Missverständnissen zwischen dem Auftraggeber eines BW-Berichtes (dem Fachbereich) und dem Entwickler kommen kann. „Die Dokumentation soll die Kommunikation - ein Schlüsselelement aller großen und erfolgreichen Projekte - zwischen allen Beteiligten unterstützen.“6 Eine gute technische Dokumentation kann dafür sorgen, dass alle Beteiligten das gleiche Verständnis haben, vor allem dient sie aber auch als Sicherstellung eines aktuellen oder historischen Zustandes.
2.1.3 Anforderungen einer Dokumentation
Alle Arten von Dokumentationen müssen eine Reihe von allgemeinen Grundätzen beachten. Normen wie die DIN EN 620797, Standards wie die IEEE 10638 oder Richtlinien zur unternehmensinternen technischen Dokumentation wie die VDI 4500 (Blatt 2)9 geben dem Autor dabei einen Leitfaden zum Erstellen von Dokumentationen. Dieses Kapitel soll einen Überblick auf gewisse Prinzipien geben, die auch in einer technischen Dokumentation für das SAP BW Umfeld berücksichtigt werden sollten. Es ist wichtig, die Dokumentation zweck- und zielgruppenorientiert zu gestalten. Da die technische Dokumentation für das SAP BW primär die Erstellung aller Berichte und Objekte dokumentiert, sollten alle relevanten Informationen für die Entwickler dokumentiert werden. An dieser Stelle ist nicht zu vernachlässigen, dass alle getroffenen Entscheidungen in angemessener Art und Weise beschrieben sind. Dabei reicht es häufig nicht aus, den eingeschlagenen Weg zu beschreiben. Es können auch die Alternativen und die Gründe für deren Ablehnung für spätere Änderungen oder Diskussionen wichtig sein. Das wichtigste Kriterium für eine gute technische Dokumentation ist jedoch die Aktualität. Ein veralteter Stand führt zu Missverständnissen, sodass die manuelle Pflege der Dokumentation oft einen hohen Zeitfaktor in Anspruch nimmt. „Wenn es möglich ist, Änderungen automatisch zu dokumentieren, dann sollte es auch getan werden.“10 Diese Erkenntnis ist Grundlage für die Evaluierung einer geeigneten Softwarelösung, die die vorhandenen Metadaten des SAP BW automatisiert dokumentieren kann.
2.1.4 Begriff Metadaten
In der Datenverarbeitung hat sich im Zusammenhang von Dokumentation zunehmend der Begriff Metadaten herausgebildet. Da Metadaten bei der technischen Dokumentation im SAP BW eine große Rolle spielen, soll im Folgenden untersucht werden, wofür der Begriff steht.
Tim Berners-Lee, der Erfinder des World Wide Web und Direktor des W3C (World Wide Web Consortiums), definiert den Begriff Metadaten als „machine understandable information about web resources or other things.“11
Metadaten („Daten über Daten“) liefern also Grundinformationen über ein elektronisches Dokument, wie z.B. Angaben über Titel, Autor oder Erstellungsdatum in einem maschinenlesbaren Format. Die in einer größeren Data Warehouse-Lösung (wie SAP BW) zu verwaltenden Informationsobjekte erweisen sich als sehr zahlreich und heterogen und umfassen DV-technische und betriebswirtschaftliche Informationen, die für den Anwender sehr wertvoll sind.
Grundsätzlich beinhaltet eine umfassende Metadatenverwaltung hauptsächlich technische Angaben zu den Datenquellen, zum Transformations- und Ladeprozess, zu den Speicherstrukturen und schließlich zur Nutzung in Form von Abfragen und Auswertungen. Diese Objektsektoren finden sich in der 3-Ebenen-Architektur in BW wieder (siehe Kapitel 2.2.1).
Daneben stößt man häufig auf betriebswirtschaftliche Begriffsdefinitionen, sowie Zuordnungen zu den beteiligten Personen, wie Anwendern oder Administratoren. Eine Ablage aller Metadateninformationen erfolgt üblicherweise in einer speziellen Repository-Komponente des Data Warehouse.12 In welchem Umfang das Business Information Warehouse aus dem Hause SAP diese Komponente, das sogenannte Metadata Repository, einsetzt, ist zentraler Untersuchungsgegenstand von Kapitel 2.2.3. Zunächst soll aber eine allgemeine Einführung des BW-Moduls und einige Hintergrundinformationen vorgestellt werden.
2.2 Vorstellung SAP BW
Das SAP Business Information Warehouse (BW) wird von SAP als ein „Data Warehouse zur Unterstützung von strategischen und operativen Unternehmensentscheidungen“13 gesehen.
Die zunehmende Bedeutung der Informationsverarbeitung für den Erfolg eines Unternehmens wird häufig unterschätzt. Führungskräfte und Entscheidungsträger (Management) in Unternehmen sehen sich einer Vielzahl von Informationen gegenüber, die Grundlage für Entscheidungen bieten sollten. Die Versorgung des Managements mit validen und aktuellen Informationen zur Wahrnehmung der Führungs-, Steuerungs- und Kontrollaufgaben ist eine hohe und zugleich wichtige Herausforderung.
Angemessene Hilfsmittel sind daher notwendig, um aus der „Datenflut“ entscheidungsrelevante Informationen zu gewinnen. Das SAP BW als Data Warehouse Lösung ermöglicht eine zeitnahe Versorgung betrieblicher Entscheidungsträger mit relevanten Informationen zu Analysezwecken. Das SAP Modul befindet sich momentan in der Version 7.0 und ist Teil des weit verbreiteten SAP NetWeaver 2004s. Die FinanzIT GmbH hat Anfang 2004 das BW-Modul eingeführt, welches nach einigen Konsolidierungen mittlerweile ein festes und anerkanntes Controllingwerkzeug ist.
Vor diesem Hintergrund soll der Abschnitt das Modul SAP BW als zeitgemäßes Informationssystem für das Management einordnen und die Lösung anhand der zugrundeliegenden Architektur und eines beispielhaften Datenflusses beschreiben. Als Bindeglied zwischen SAP BW und Dokumentation kann das Metadata Repository gesehen werden. Aus diesem Grund soll diese Komponente des BW das Kapitel abrunden und die Notwendigkeit einer neuen Softwarelösung zur Dokumentation unterstreichen.
2.2.1 Die 3-Ebenen-Architektur
Die folgende Beschreibung der Systemarchitektur von BW gibt einen Überblick auf die komplexen Zusammenhänge und verdeutlicht die Notwendigkeit einer Dokumentation. Die einzelnen Objekte, die nachvollziehbar dokumentiert werden müssen, werden in diesem Kapitel bereits kurz aufgegriffen. Das in diesem Kapitel vermittelte Wissen kann als Grundlage für den anschließenden Abschnitt verstanden werden, indem ein beispielhafter Datenfluss skizziert wird.
Prinzipiell entspricht der Aufbau des Business Information Warehouse, mit den unterschiedlichen Komponenten, der Referenzarchitektur für ein Data Warehouse (siehe Anhang 1). Ein Data Warehouse-System lässt sich in drei Ebenen untergliedern:
- Datenerfassungsebene mit der Schnittstelle zu den operativen Systemen,
- Datenhaltungsebene mit dem eigentlichen Data Warehouse sowie die
- Datenbereitstellungs- und Präsentationsebene
In der Kombination aller Tools und Funktionsbereiche des BW, sowie der verbundenen Systeme, stellt sich auch das SAP BW als Architektur mit drei Ebenen dar, die nun nachfolgend anhand einer vereinfachten Darstellung in Abbildung 214 beschrieben werden. Einen Überblick über die detaillierte Gesamtarchitektur des SAP BW liefert Anhang 2.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2: 3-Ebenen Architektur des SAP BW
Quellsysteme
Die Extraktionsschicht beschreibt die unterschiedlichen operativen Systeme, aus denen das SAP BW Daten bezieht. Die Quellsysteme, die die Daten liefern, können dabei von SAP Komponenten (R/3, BW), Flat-Files (Excel-Sheets im CSV-Format) oder externen relationalen Datenbanken stammen. Der Zugriff auf die Quellsysteme erfolgt mit Hilfe von Kommunikationsschnittstellen des BW, die vom jeweiligen Quellsystemtyp abhängen. Für die Extraktion von Daten aus SAP R/3-Systemen dienen beispielsweise vorgefertigte Extraktoren. Um Daten aus Fremdsystemen in das BW zu übertragen, werden BAPI (Business Application Programming Interface) Schnittstellen eingesetzt. Die Bereitstellung der Daten erfolgt durch sogenannte DataSources, die auf Anforderungen die Übernahme der Daten starten und ins BW-System replizieren.
SAP BW Server
Die extrahierten Daten aus den Quellsystemen werden in der Ebene des BW Server abgelegt und verwaltet. Grundsätzlich lassen sich dabei Bewegungs-, Stamm- und Metadaten voneinander abgrenzen. Für die Datenablage werden im SAP BW die Speicherbereiche Persistent Staging Area (PSA), Operational Data Store (ODS) sowie InfoCubes genutzt, die unter dem Begriff InfoProvider zusammengefasst werden. Für die Organisation des SAP BW, die Steuerung, Überwachung und Pflege aller Datenbeschaffungsprozesse sorgt die Funktionalität der Administrator Workbench (Transaktion RSA1). Mit Hilfe dieser zentralen Transaktion können alle relevanten Objekte und Prozesse verwaltet und gesteuert werden. Neben der Definition aller relevanten Informationsobjekte im InfoProvider werden über die Administrator Workbench die Ladevorgänge mit Hilfe eines Schedulers geplant und über ein Monitor- Tool überwacht.
Wie die Daten aus den Quellsystemen in die BW Server Schicht und von dort in die BW OLAP Schicht gelangen, zeigt ein repräsentativer Datenfluss in Kapitel 2.2.2.
SAP BW OLAP
Um die in der Speicherkomponente des SAP BW abgelegten Inhalte zweckorientiert analysieren zu können, müssen geeignete Werkzeuge zur Formulierung von Datenbankabfragen und zur freien Navigation im Datenbestand zur Verfügung stehen. Zur Anzeige und Auswertung der gespeicherten Daten kann man den OLAP-Bereich grundsätzlich in drei Komponenten gliedern15, die jeweils auf spezifische Anwendungsfälle ausgerichtet sind:
Der Business Explorer (BEx) Analyzer ist ein Microsoft Excel basiertes Tool, welches flexible Reporting- und Analysewerkzeuge zur strategischen Analyse und Entscheidungsunterstützung im Unternehmen zur Verfügung stellt. Durch die Auswahl und Kombinationen von Merkmalen und Kennzahlen kann bestimmt werden, auf welche Art und Weise die Daten ausgewertet werden sollen. Die Datenanalysen werden im BEx durch Queries ausgeführt und ermöglichen die gleichzeitige Analyse mehrerer Dimensionen, wie z.B. Zeit, Ort und Produkt. Um dem Anwender optisch und funktional komfortablere Analysen zu bieten, können so genannte Arbeitsmappen definiert werden, in denen Excel-Funktionen mit Queries kombiniert werden.
Zusätzlich besteht in dieser Ebene die Möglichkeit, mittels Webbrowsers, die zuvor definierten Queries bei Bedarf über das Internet oder Intranet zu veröffentlichen. Als dritte Komponente können durch das Mobile Intelligence jederzeit die Web Applications unterwegs über PDAs oder WAP-fähige Mobiltelefone abgerufen werden. Diese Möglichkeit wird jedoch bei der FinanzIT GmbH nicht genutzt.
2.2.2 Datenfluss
Um die 3-Ebenen-Architektur des SAP BW zu konkretisieren, soll die BW Server Schicht anhand eines allgemeinen Datenflusses genauer beschrieben werden. Dabei stellt die Abbildung 3 zwei beispielhafte Wege dar, wie ein MultiCube mit Daten befüllt werden kann.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3: Datenfluss vom Quellsystem bis zum Reporting
Den Ausgangspunkt des gesamten Datenflusses bilden die operativen Vorsysteme, die als primäre Datenlieferanten fungieren. Zudem können auch Daten aus externen Informationssystemen übernommen oder manuell eingepflegt werden. Eine DataSource bündelt die Extraktions- und Transferstrukturen eines Quellsystems, sowie die dazugehörige Transferstruktur im BW und bildet dadurch eine betriebswirtschaftlich sinnvolle Einheit zur Repräsentation einer abgegrenzten Datenquelle. Als Eingangsablage dient die PSA zur unveränderten Zwischenspeicherung der Daten aus den Vorsystemen vor deren Weiterverarbeitung. In den Übertragungsregeln legt man fest, wie die Felder der DataSource in die InfoSource zu überführen sind. Hierbei ergeben sich erstmalig im BW Ansatzpunkte für eine Datentransformation (z.B. Datentyp-Konvertierung). Eine InfoSource ist eine Zusammenfassung von logisch zusammengehörigen InfoObjects (betriebswirtschaftliche Auswertungsobjekte). Fortschreibungsregeln spezifizieren anschließend, wie die Daten aus der Kommunikationsstruktur einer InfoSource in den InfoProvider (InfoCube oder ODS) fortgeschrieben werden. Die Fortschreibungsregeln stellen also die zweite Möglichkeit dar, die Daten durch eine definierte Logik zu verändern. In einem ODS-Objekt befinden sich konsolidierte Daten auf detaillierter Ebene in einer flachen Tabelle. Ein InfoCube repräsentiert einen in sich geschlossenen, mehrdimensionalen Datenbestand. Auf die abgelegten InfoCubes und ODS-Objekte kann mit den verfügbaren Auswertungswerkzeugen direkt zugegriffen werden. Allerdings werden in der Regel im letzten Prozessschritt die Daten aus mehreren InfoCubes und ODS-Objekten in einem MultiCube zusammengeführt. Ein MultiCube ist nur eine Sicht und enthält selbst keine Daten. Die Berichte greifen auf die Sicht des entsprechenden MultiCubes zu.
Wie man anhand des Datenflusses und der Beschreibung erkennt, gibt es viele BWObjekte, die an einem Datenfluss beteiligt sind. Eine Beschreibung aller wichtigen BWObjekte ist im Anhang 3 in Form eines Glossars zu finden.
2.2.3 Metadata Repository
Insbesondere Data Warehouse-Systeme haben häufig das Problem, das die verwendeten Datenstrukturen und Datenflüsse nicht transparent gestaltet sind und die Daten in nicht nachvollziehbarer Weise weiterverarbeitet und gespeichert werden.16 Im SAP BW werden alle Metadaten und deren Verknüpfungen zueinander zentral mit dem HTML-basierten Metadata Repository verwaltet und in grafischer Form visualisiert. Um zu diesem Funktionsbereich zu gelangen, kann der entsprechende
Reiter in der Administrator Workbench (Transaktion RSA1) gewählt werden oder direkt die Transaktion RSOR genutzt werden. Allgemein werden zwei Arten von Metadaten im BW unterschieden:
- Technische Metadaten: technische Informationen
- Business-Metadaten: Begriffsdefinition in Form von Glossaren
Im Metadata Repository werden neben der Netzwerkdarstellung des Datenflusses auch der Aufbau der Datenstrukturen im BW beschrieben. So erhält der Anwender Informationen über technische Eigenschaften wie Feldlänge oder Datentyp (siehe Abbildung 4). Außerdem beschreiben Metadaten die Herkunft und Zusammensetzung der Daten und geben Auskunft über Transformationsprozesse.
Technisch werden die Informationen, die das Metadata Repository aufbereitet, in einfachen Tabellen gespeichert. Wenn diese gespeicherten Metadaten also entsprechend aufbereitet werden, können die vorhandenen Information sehr gut zu Dokumentationszwecken genutzt werden. Eine Liste mit allen BW-Objekten, die grundsätzlich vom Metadata Repository beschrieben werden, befindet sich im Anhang 4.
Wie die Praxis gezeigt hat, unterstützen die Funktionalitäten des Metadata Repositories für eine technische Dokumentation nur unvollständig. Das bisherige Vorgehen zur Erstellung einer technischen Dokumentation benutzt die Aufbereitung im Metadata Repository als Grundlage. Dabei haben sich im alltäglichen Einsatz einige Schwachpunkte herauskristallisiert, die eine neue Dokumentationslösung erforderlich machen. Die bisherige Dokumentationsweise sowie die daraus resultierenden Schwächen werden im Rahmen der Ist-Analyse in Kapitel 3.2.1 aufgezeigt.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4: Beispiel aus dem Metadata Repository
3 Methodik zur Evaluierung von Software
Aufgrund der bereits kurz erwähnten Schwächen des Metadata Repositories und der bisherigen Dokumentation soll eine softwaregestützte Softwarelösung angestrebt und evaluiert werden. Dabei hat die Auswahlentscheidung für eine Software einen langfristigen Charakter, da der Einsatz einer Anwendungssoftware meist mehrere Jahre dauert. Aus diesem Grund sollte die Entscheidung für eine Softwarelösung strukturiert und überlegt sein. Dabei ist das Ziel der Softwareauswahl, mit ausreichender Sicherheit und möglichst geringem Ressourceneinsatz die individuell passende Softwarelösung für eine gegebene Problemstellung zu identifizieren.
In diesem Kapitel werden zunächst verschiedene Vorgehensmodelle vorgestellt, die schließlich in eine praktische Vorgehensweise münden. Die praktische Durchführung der einzelnen Prozessschritte steht hier im Vordergrund und die Ergebnisse der einzelnen Phasen werden angemessen dokumentiert. Zwei Kernpunkte der Softwareauswahl werden zudem noch einmal, innerhalb separater Kapitel, herausgestellt. Dies ist zum einen die Vorstellung aller Alternativen, die beurteilt wurden und bei der Entscheidung zur Auswahl standen. Zum anderen soll die praktische Bewertung dieser Alternativen beschrieben werden und damit eine begründete Empfehlung ausgesprochen werden. Als Methodik zur Ermittlung der Nutzenwerte wird dabei der Ansatz „Analytic Hierarchy Process“ verwendet. Anschließend werden die Nutzenwerte in Kapitel 3.4.3 den Kosten gegenübergestellt, um die beste Alternative zu ermitteln.
3.1 Vorgehensmodelle zur Softwareauswahl
Eine strukturierte Methodik bei der Softwareauswahl ist unerlässlich, um eine fundierte Entscheidung für die bestmöglichste Lösung zu erhalten. Eine Fehlentscheidung kann zu verheerenden Folgen führen. Dies liegt zum einen an den hohen Kosten, die ein neues Werkzeug mit sich bringt, und zum anderen an dem großen Aufwand der Mitarbeiter, die eine Vielzahl von Tagen für die Auswahl und Einführung investiert haben. Um falsche Entscheidungen zu vermeiden, ist ein systematisches Vorgehen zwingend notwendig. In diesem Kapitel sollen daher typische Phasenmodelle aus der Literatur und der FinanzIT interne Teilprozess „Tool einführen“ vorgestellt werden. Die Erkenntnisse daraus sind Grundlage für das praktische Vorgehen, dessen Schritte im nächsten Kapitel ausführlicher betrachtet werden.
3.1.1 Typische Phasenmodelle
Dieser Abschnitt skizziert ausgewählte Ansätze, die exemplarisch für eine ganze Reihe von theoretischen Vorgehensmodellen stehen und bei der Auswahl von Software helfen. Typisches Kennzeichen aller in der Literatur vorgestellten Vorgehensmodelle ist der geringe Detaillierungsgrad und eine allgemein gehaltene Vorgehensweise, die eine Einteilung in Phasen vorsieht. Die bekanntesten und bedeutendsten Phasenmodelle sollen im Folgenden in knapper Form vorgestellt werden. Beim Vergleich der verschiedenen Ansätze fällt auf, dass im Kern keine gravierenden Unterschiede vorhanden sind. Einige Besonderheiten sollen dennoch kurz hervorgehoben werden.
Schinzer17 teilt den Software-Auswahlprozess in vier Phasen auf. Im ersten Schritt ist eine Anforderungsanalyse durchzuführen, die alle Ziele und gewünschten Funktionen berücksichtigt. Auf dieser Basis wird im zweiten Schritt ein Kriterienkatalog abgeleitet, dessen Kriterien, je nach Wichtigkeit, unterschiedlich stark bewertet werden. In der Marktanalyse werden geeignete Software-Hersteller gesucht und die Produkte mit den zuvor definierten Kriterien abgeglichen. Eine grobe Auswahl reduziert die Software- Anbieter auf relativ wenige, die anschließend detailliert zu untersuchen sind.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5: Phasenmodell nach Schinzer
Das Phasenmodell von Kremer18 beginnt mit den Zielsetzungen, die die künftige Softwarelösung erfüllen soll. Nachdem die grundlegenden Rahmenbedingungen geklärt sind, erfolgt das Erstellen eines Grobkonzeptes. Im Gegensatz zu Schinzer, erkennt man an dieser Stelle den höheren Detailgrad der ersten drei Phasen. Ähnlich wie bei Schinzer erfolgt auf Basis des Grobkonzeptes, welches auch als Anforderungsanalyse zu verstehen ist, eine Vorauswahl der Anbieter. Anschließend sind Ausschreibungsunterlagen an die in Frage kommenden Software-Hersteller zu versenden und die Ergebnisse zu bewerten.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6: Phasenmodell nach Kremer
[...]
1 persönliche Mitteilung von Frau Sabine Grenz am 14.05.2007
2 Vgl. Heinen (1992), S. 35 ff.
3 Vgl. Ludewig/Lichter (2007), S. 241.
4 Otlet (1907), S. 7 ff.
5 Vgl. Deutscher Fachverband für Techn. Kommunikation und Informationsentwicklung (2007).
6 Posch/Birken/Gordon (2004), S. 122.
7 Vgl. Deutsches Institut für Normung e.V. (2007).
8 Vgl. Institute of Electrical and Electronical Engineers (2007).
9 Vgl. Verein Deutscher Ingenieure (2007).
10 Posch/Birken/Gordon (2004), S. 125.
11 Berners-Lee (1997).
12 Vgl. Hufford (1996).
13 SAP Info (2007).
14 Vgl. SAP AG (2004), S. 11.
15 Vgl. SAP AG (2004), S. 13.
16 Vgl. Mehrwald (2004), S. 29.
17 Vgl. Schinzer (1996).
18 Vgl. Kremer (1995).
- Quote paper
- Christian Struck (Author), 2007, Auswahl einer Softwarelösung zur Erstellung einer automatisierten technischen Dokumentation für das SAP Business Information Warehouse in der FinanzIT GmbH, Munich, GRIN Verlag, https://www.hausarbeiten.de/document/187488
