Lade Inhalt...

Strategien und Vorgehensmodelle zur Einführung eines SAP BW in Unternehmen

Bachelorarbeit 2007 68 Seiten

Informatik - Wirtschaftsinformatik

Leseprobe

Inhaltsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einleitung
1.1 Problemstellung
1.2 Zielsetzung

2 Begriffserklärungen und Grundlagen
2.1 Entwicklung der Management Support Systeme
2.1.1 Management Information System
2.1.2 Decision Support System
2.1.3 Executive Information System
2.2 Data Warehouse System ± Konzeption und Architektur
2.2.1 Datenquellen
2.2.2 Extraktion, Transformation und Laden
2.2.3 On-line Analytical Processing
2.2.4 Multidimensionale Datenmodellierung
2.2.5 Data Mining
2.2.6 Data Marts
2.2.7 Metadaten
2.2.8 Business Intelligence

3 SAP NetWeaver® 2004s
3.1 Funktionsumfang SAP NetWeaver 2004s
3.2 SAP BW® 7.1.1 als Bestandteil von SAP NetWeaver 2004s
3.2.1 Architektur des SAP
3.2.2 Datenbeschaffung im SAP
3.2.3 Datenbereitstellung und Integration im SAP
3.2.4 Datenhaltung im SAP

4 Vorgehensmodelle zur Einführung eines Datawarehouse
4.1 Definition eines Vorgehensmodells
4.2 Sequentielle Vorgehensmodelle
4.3 Iterative Vorgehensmodelle
4.4 Kritische Modellbetrachtung für ein Datawarehouse-Projekt

5 Vorgehensmodell zur Einführung einer SAP BI-Lösung
5.1 Werkzeuge zur Unterstützung
5.2 Projektsteuerung
5.3 Aufgabenblöcke innerhalb eines BI-Projekts
5.3.1 Projektumfeld
5.3.2 Anforderungsanalyse
5.3.3 Projektrealisierung
5.3.4 Vorbereitung der Produktivsetzung
5.3.5 Going-live und Support

6 Problemfelder innerhalb BI-Projekten

7 Schlussbetrachtung und Ausblick

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

Abbildung 1 Betriebswirtschaftliche Informationssysteme

Abbildung 2 Data Warehouse Konzept

Abbildung 3 Data Warehouse Architektur

Abbildung 4 ETL-Prozess

Abbildung 5 Multidimensionaler Datenwürfel mit Klassifikation und Hierarchien

Abbildung 6 Data Marts Architektur

Abbildung 7 Unterschiedliche Ansichten zum Begriff Business Intelligence

Abbildung 8 SAP NetWeaver BI als Teil von SAP NetWeaver

Abbildung 9 3 Schichten Architektur des SAP BW

Abbildung 10 Datenbereitstellungsprozess

Abbildung 11 Beispiel eines Datenmodells für den InfoCube Angebote/Aufträge

Abbildung 12 Das klassische Wasserfallmodell

Abbildung 13 Spiralmodell nach Böhm

Abbildung 14 ASAP-Roadmap

Abbildung 15 BI-Projektprozessmodell

Abbildung 16 Beispiel Datenflussdiagramm für den InfoCube Angebote/Aufträge

Tabellenverzeichnis

Tabelle 1 Eigenschaften eines Data Warehouse

Tabelle 2 Anspruch an die Daten

Tabelle 3 Vergleich OLTP zu OLAP

Tabelle 4 Vorgehensmodelle und deren Eignung für DWH-Projekte

Tabelle 5 Aufgaben der IT-Abteilung und des Fachbereichs

Tabelle 6 Frontend-Tools

Tabelle 7 Schritte innerhalb der Anforderungsanalyse

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

In vielen Branchen werden Unternehmen mit einer großen und ständig wachsenden Da- tenflut konfrontiert. Zur gleichen Zeit machen diese Unternehmen die Erfahrung, dass die richtige und aussagekräftige Interpretation dieser Daten von sehr großer Bedeutung ist, um beispielsweise die Effizienz zu erhöhen, Kunden näher an sich zu binden und das Geschäftsvolumen weiter zu steigern. Daten bilden daher, im wahrsten Sinne des Wortes, das Rückgrat des Geschäfts. Sie sind Voraussetzung für die Schaffung eines Wettbe- werbsvorteils um Fähigkeiten der Unternehmensleitung präzise messen und Entschei- dungen frühzeitig erkennen zu können. Daten dienen aber auch der Planung strategischer Geschäftsinitiativen. So sind nicht wenige Anwendungen und Geschäftsprozesse - z.B. im Customer Relationship Management (CRM), Supply Chain Management (SCM) und in der Unterstützung der Mitarbeiter im Kundenkontakt - im Wesentlichen von der Fähigkeit abhängig, große Datenmengen aus einer Vielzahl von Quellen auswerten zu können. Um diese Datenflut effizient und aussagekräftig zu analysieren, setzten Unternehmen oft auf die Möglichkeit eines Data Warehouse (DWH). Ein DWH ermöglicht es einem Mitarbeiter - ob Datenerfasser, Manager oder Analytiker - seine Entscheidungen qualitativ gut und schnelO WUHIIHQ ]X N|QQHQ ÄVon solch einem System wird erwartet, dass die richtigen In- formationen zum richtigen Zeitpunkt in der richtigen Menge am richtigen Ort in der erfor- derlichen Qualität vorliegen, damit die richtigen Entscheidungen getroffen werden kön- QHQ ³1

1.1 Problemstellung

Doch aussagekräftige Ergebnisse zu erzeugen, ist alles andere als einfach. Dies beginnt bereits in der Heterogenität der Anwendungslandschaft, wie man sie häufig in Unterneh- men vorfindet. Hier fallen vor allem hohe Kosten für die Erstellung und Pflege für Schnitt- stellenprogramme an, was mitunter zur Bildung von sogenannten Insellösungen führt. Unternehmen stellen dann fest, dass sie nicht in der Lage sind, die Vielfalt an Daten aus unterschiedlichen Systemen zu integrieren. Das Potential, welches ein DWH entfaltet, bleibt somit ungenutzt. Viele DWH-Projekte kommen aber erst gar nicht soweit, sondern scheitern bereits in der Startphase. Zu Projektbeginn sind die Ziele und Anforderungen meist unklar, notwendige Ressourcen fehlen und die Projektplanung ist unzureichend.

1.2 Zielsetzung

Um dieses Problem im Vorfeld zu umgehen bzw. zu minimieren und um hohe Kosten auf- grund einer möglichen Restrukturierung zu vermeiden, müssen die spezifischen Gege- benheiten, die an ein DWH-Projekt bzw. im weiteren Sinne an ein Business Intelligence (BI)-Projekt gestellt werden, DXFK %HU FNVLFKWLJXQJ ILQGHQ Ä'LH *estaltung von BI- Anwendungssystemen verlangt den Einsatz eines Vorgehensmodells, das weit über die Funktionalität der traditionellen Modelle der Systementwicklung hinausgeht. Dies ist in- sbesondere deshalb erforderlich, da das Ziel der DWH-Systementwicklung sich nicht auf die Erstellung eines Anwendungssystem bezieht, sondern den Aufbau einer abgestimm- ten DWH-Systemlandschaft für den gesamten dispositiven Bereich eines Unternehmens fokusVLHUW ³2

Die vorliegende Arbeit soll einen Einblick in die methodische Einführung einer BI-Lösung auf Basis von SAP Business Information Warehouse3 in Unternehmen geben. Da es für das Verständnis unerlässlich ist, werden die Begrifflichkeiten die mit DWH und BI im un- mittelbaren Zusammenhang stehen beschrieben. Ein weiteres Kapitel beschäftigt sich mit möglichen Vorgehensmodellen, die für die Einführung von DWH/BI-Projekten in Frage kommen. Anschließend wird ein Vorgehen auf Basis von SAP BW, der Firma SAP4 vor- gestellt. Hierbei steht der betriebswirtschaftliche Gesichtspunkt im Vordergrund, der sich bei der Projektplanung und -einführung ergibt. Auf die technischen Gegebenheiten soll nur am Rande eingegangen werden, da zu diesem Thema bereits eine Vielzahl an Litera- tur erschienen ist. Den Problemen, die sich mit der Einführung und dem Betrieb eines SAP BW ergeben, ist ein eigenes Kapitel gewidmet, wie auch der abschließenden Be- trachtung bzw. Zusammenfassung der Arbeit.

2 Begriffserklärungen und Grundlagen

Das nachfolgende Kapitel beschäftigt sich mit den Begrifflichkeiten, die sich mit dem Thema DWH und BI befassen und für die Planung und Einführung eines auf SAP BW basierenden BI-Projekts in Unternehmen als wichtiges Fundament dienen.

2.1 Entwicklung der Management Support Systeme

Durch die Eigenheit große Datenmengen schnell und effizient verarbeiten zu können, wurde die Informationstechnologie schon in früher Zeit fester Bestandteil von Informati- onssystemen. Technologisch gestützte Informationssysteme, die der Versorgung des Führungssystems mit Informationen zur Planung, Steuerung und Kontrolle dienen, wer- den im Allgemeinen als Führungsinformationssysteme (FIS) oder Managementsupport- systeme (MSS) bezeichnet. Im Laufe der 1960er Jahre wuchs mit dem technischen Fort- schritt in der Computertechnik das Bedürfnis, die neuen Möglichkeiten der Datenverarbei- tung zur Aufbereitung von Informationen für die Unternehmensführung zu nutzen. Seit dieser Zeit wurden verschiedene Ansätze, Konzepte und Systeme entwickelt, deren Ziel es war, den Managementprozess in seinen Phasen ebenenübergreifend durch geeignete Mittel zu unterstützen (vgl. Abbildung 1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1 Betriebswirtschaftliche Informationssysteme5

2.1.1 Management Information System

Aus der Historie betrachtet stellen die MIS den ersten Beitrag einer gezielten EDV- Unterstützung des Managements dar. Das Konzept des MIS war ein sehr zentraler An- satz, der versuchte alle entscheidungsrelevanten Informationen aus den operativen Sys- temen in einem Datenmodell zusammenzuführen und in Echtzeit für die Analyse zu ver- dichten. Die unflexiblen Datenstrukturen orientierten sich mehr an den operativen Syste- men als an den betriebswirtschaftlich notwendigen Erfordernissen der Fach- und Füh- rungskräfte.

2.1.2 Decision Support System

Das Ziel einer Verbesserung fachorientierter strukturierter Entscheidungsprozesse verfolgte der nachfolgende Ansatzpunkt der Decision Support-6\VWHPH '66 Ä'LHVH LQWHraktiven Systeme griffen auf abgeleitete, entscheidungsrelevante Daten und eine Vielzahl von Methoden und entscheidungsspezifischen Wissen zurück, das durch modellgestützte Analyse-, Prognose- und Simulationsmethoden ermittelt wurde.³6

2.1.3 Executive Information System

Während sich MIS und DSS kaum im oberen Management durchsetzen konnten, hatten die auf Präsentation ausgelegten Executive Information-Systeme (EIS) genau diesen PerVRQHQNUHLV XQG GHVVHQ ,QIRUPDWLRQVEHGDUI DOV =LHOJUXSSH Ä$XVO|VHU I U HLQH weitere Novellierung des MIS-Ansatzes waren die aufkommenden personalisierten Benutzeroberflächen und die zunehmende Dezentralisierung sowie Vernetzung der DV-Systeme. Über die reine Versorgung mit relevanten internen und externen Informationen hinaus wurden diese dialog- und datenorientierte Informationssysteme mit umfangreichen Analyse-, Navigations- und Kommunikationswerkzeugen ausgestattet.³7

2.2 Data Warehouse System ± Konzeption und Architektur

Das Konzept des DWH (vgl. Abbildung 2) fand in den 1990er als neuere Entwicklung im Bereich der entscheidungsunterstützenden Systeme seinen Ursprung. Auch dieser Entwurf orientiert sich an den Zielen des MIS, entscheidungsrelevante Informationen aus allen Unternehmensbereichen verfügbar zu machen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2 Data Warehouse Konzept8

Der Begriff wurde erstmals von W.H. Inmon geprägt:

ÄA Data Warehouse is a subject-oriented, integrated, time-variant, and nonvolatile collection of Data in support of managements Decision support process´9

'LHVH 'HILQLWLRQ VFKOLH‰W LQGLUHNW PHKUH $QQDKPHQ HLQ Ä(UVWHQV HLQ 'DWD :DUehouse wird immer auch physikalisch von den operativen Quelldatensystemen getrennt. Zweitens enthält ein Data Warehouse sowohl aktuelle als auch historische Detaildaten [«] Drittens wird die Struktur des Data Warehouse und der Daten in ein zentrales Metadaten5HSRVLWRU\ KLQWHUOHJW ³10 Die Informationen über die Daten bilden das Rückgrat jedes Data Warehouse. In Tabelle 1 werden die Charakteristika der klassischen Data Warehouse Definition nach W.H. Inmon beschrieben:

Tabelle 1 Eigenschaften eines Data Warehouse

Abbildung in dieser Leseprobe nicht enthalten

2.2.1 Datenquellen

Der erste Schritt ist der Vorgang der Datenbeschaffung (vgl. Abbildung 3). Dabei werden kontrolliert Daten aus externen und operativen Quellsystemen extrahiert und transformiert. Die Datenquellen werden meist nicht als Teil des DWH-Systems betrachtet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3 Data Warehouse Architektur

Um den anschließenden Extraktions-, Transformations- und Ladeprozess (ETL-Prozess) aber spezifizieren zu können, ist es unabdingbar ebenfalls die Struktur und den Aufbau der Quelldateien mit einzubeziehen. Bei der Datenbeschaffung ist darauf zu achten, dass diese fehlerfrei vorliegen:

Tabelle 2 Anspruch an die Daten

Abbildung in dieser Leseprobe nicht enthalten

2.2.2 Extraktion, Transformation und Laden

Die Aufgabe des Extraktions-, Transformations- und Ladeprozesses besteht in der Zusammenführung aller relevanten Daten in einer unternehmensweiten DatenEDQN Ä1HEHQ den technischen Anforderungen einer Extraktion aus verschiedenen Quellsystemen und der Ablage in eine Zieldatenbank von u.U. erheblicher Größe ist hierbei die Notwendigkeit der Umsetzung von nicht harmonisierten Daten als nicht zu unterschätzendes Problem zu EHDFKWHQ ³11 Dieser Prozess wird auch als ETL-Prozess bezeichnet und setzt sich aus folgenden Komponenten zusammen:

Die Extraktionskomponente ist für die Übertragung von Daten aus einer Datenquelle in den Arbeitsbereich verantwortlich. Ein Monitoringprogramm unterstützt diesen Vorgang, je nach Strategie des Monitoringprogramm fällt die Extraktion unterschiedlich aus: ÄBei der triggerbasierten Variante sind die geänderten Datensätze aus den entsprechenden Datei- en auszulesen >«@ die zeitstempelbasierte Variante erfordert lediglich die Selektion von Datensätzen anhand ihres Zeitstempels. Bei der Log- bzw. Snapshot-Variante hängt das Vorgehen von der gewählten Umsetzung der Log-Analyse bzw. des Snapshot-Vergleichs ab. Werden die als geändert identifizierten Tupel beispielsweise in eine Datei eingetragen, so ist diese Datei zu importieUHQ ³12

Bei der Transformation werden die Daten vereinheitlicht, verdichtet und angereichert. Dies umfasst die folgenden Phasen: Anpassung von Datentypen, Konvertierung von Kodierun- gen, Vereinheitlichung von Zeichenketten, Vereinheitlichung von Datumsangaben, Um- rechnung von Maßeinheiten sowie der Kombination bzw. Separierung von Attributwerten. Desweiteren sind Quelldaten häufig durch fehlerhafte, redundante, veraltete oder fehlen- de Werte verunreinigt. Mit Hilfe einer Plausibilitätsprüfung können diese aufgespürt und korrigiert werden.

Abbildung 4 ETL-Prozess13

Abbildung in dieser Leseprobe nicht enthalten

Nachdem die Transformation vollzogen wurde, befinden sich die bereinigten und angemessen aufbereiteten Daten in einem Arbeitsbereich, die für die Speicherung und spätere Auswertung geeignet sind. Um die Daten weiterleiten zu können, sind derer zwei Ladekomponenten verantwortlich:

- Äeine Komponente zur Übertragung von analyseunabhängigen Detaildaten aus dem Arbeitsbereich in die Basisdatenbank und
- eine Komponente zur Übertragung von analysespezifischen Daten (zum Beispiel Agg- UHJDWH DXV GHU %DVLVGDWHQEDQN³14

Die Ladekomponenten nehmen üblicherweise das Ladewerkzeug des jeweils zugrunde liegenden Datenbankmanagementsystems (DBMS) zu Hilfe. Die Übernahme der Daten in das DWH erfolgt auf Basis von benutzerdefinierten Aktualitäts- und Konsistenzanforderungen. Um inkonsistente Anfrageergebnisse zu vermeiden, ist während der Aktualisierung der Zugriff auf die Daten im DWH unterbunden. Oft werden DWH auch deshalb nur zu einem bestimmten Zeitpunkt aktualisiert, an dem kein Zugriff auf die Daten erfolgt (außerhalb der Arbeitszeit). Um die Störung der Endanwender zu vermeiden, muss der Aktualisierungsvorgang so kurz wie möglich sein. Daher werden Werkzeuge benötigt, die mittels Parallelität den Ladevorgang entsprechend verkürzen.

2.2.3 On-line Analytical Processing

OLAP steht eng im Zusammenhang mit dem DWH-Konzept (vgl. Abbildung 2). Während sich das DWH eher auf die Speicherung und Verwaltung der Daten im Backend-Bereich NRQ]HQWULHUW VWHKW 2/$3 DOV =XJULIIVP|JOLFKNHLW LP )URQWHQG ]XU 9HUI JXQJ Ä2/$3 Hr- laubt Entscheidern im Unternehmen, Unternehmensdaten in Echtzeit auf höherer Ebene >«@ zu analysieren:

- Mehrdimensionale Daten können entlang von bestimmten Dimensionen betrachtet und zusammengefasst werden,
- Analysefunktionen können durch den Entscheider selbst eingesetzt werden, ohne Fachpersonal mit speziellen Programmierkenntnissen,
- Anfragen und ErgebQLVVH ODXIHQ LQ (FKW]HLW DE ³15

Das OLAP-Konzept wurde von Codd aufgestellt, aber aufgrund seiner umstrittenen Re- JHOQ GXUFK GLH Ä)DVW $QDO\VLV RQ 6KDUHG 0XOWLGLPHQVLRQDO ,QIRUPDWLRQ³ )$60, -

Definitionen erweitert und vertieft. Die inhaltliche Bedeutung lässt sich wie folgt umschrei- ben:

- Fast: Es werden schnelle Antwortzeiten durch das System gefordert.
- Analysis: Einfache und vielfältige Analysemöglichkeiten werden ermöglicht.
- Share: Analyse und Eingabe durch unterschiedliche Anwendergruppen mit unter- schiedlichen Rechten und Zugriffen.
- Multidimensional: Mehrdimensionale Strukturierung der Daten mit voller Unterstüt-
zung der Dimensionshierarchien.
- Information: Bei der Analyse sollen einem Anwender alle benötigten Daten trans- parent zur Verfügung stehen.

OLTP in Abgrenzung zu Neben OLAP unterscheidet man noch eine weitere Form, On-line Transaction Processing (OLTP). Operative Systeme wie Administrations- und Dispositionssysteme unterliegen dem Verarbeitungskonzept des OLTP. Während OLAP Daten auf hoher Ebene analysiert, ist OLTP durch viele Nutzer charakterisiert, die gleichzeitig Daten hinzufügen, ändern oder abfragen und damit auf einzelne Transaktionen aufgeteilt werden. Dies können z.B. Aufgaben wie Bestellungen, Rechnungen oder Kundenaufträge sein. Eine genaue Über- sicht zu den Unterschieden zwischen OLTP und OLAP zeigt nachfolgende Tabelle:

Tabelle 3 Vergleich OLTP zu

Abbildung in dieser Leseprobe nicht enthalten

Ziel Getrennte Transaktion Zusammengefasst für Analyse

Die eindeutige Zuordnung von transaktionsorientierten (OLTP) und analytischen (OLAP) Aufgaben zu getrennten Systemfamilien weicht allmählich auf. So erweitert sich einerseits das Lösungsspektrum von SAP-Anwendungen zunehmend in Richtung flexibler Instrumente und auch viele OLAP-Lösungen entwickeln sich funktional weiter.

2.2.4 Multidimensionale Datenmodellierung

Die Grundlage einer multidimensionalen Datenhaltung zum Abbilden relevanter Informa- tionen und ihrer Beziehungen untereinander ist das Datenmodell. Basis eines mehrdi- mensionalen Datenmodells bilden die Beschreibungselemente, welche die charakterisie- renden Eigenschaften der Datenstruktur darstellen. Solche Elemente (z.B. Produkt A, Produkt B etc.) bilden die Erfassungsgrundlage von betriebswirtschaftlichen Kennzahlen, die zur Steuerung und Kontrolle des Unternehmens herangezogen werden können. Jede Dimension wird durch eine bestimmte Anzahl von Attributen umschrieben. Die Dimension Zeit enthält z.B. die Attribute Jahr, Quartal, Monat, Tag. In Abbildung 5 ist ein Beispiel eines Data Cube, bei dem die Zeit auf der X-Achse, das Produkt auf der Y-Achse und die Geografie auf der Z-Achse zu finden ist. Durch OLAP-Operatoren kann der Anwender durch die multidimensionale Datenstruktur navigieren und Übersichten anfordern. Bei der Navigation wird unterschieden:

Abbildung 5 Multidimensionaler Datenwürfel mit Klassifikation und Hierarchien16 Pivotierung/Rotation:

Abbildung in dieser Leseprobe nicht enthalten

³'LHVH 2SHUDWLRQ GUHKW GHQ : UIHO GXUFK 9HUWDXVFKHQ GHU 'LPHQVLRQHQ XP VHLQH $FKVHQ und ermöglicht es dem Anwender die Daten aus beliebigen Perspektiven zu analysie- UHQ ³17

Roll-up, Drill-down, Drill-across:

Mit Hilfe der Funktionen Roll-up und Drill-down kann der Benutzer entlang der Bezie- hungsebene navigieren. Beim Roll-Up erhöht sich der Detaillierungsgrad der Daten, d.h. der Benutzer hat die Möglichkeit, die Anzahl der verkauften Produkte in den einzelnen Verkaufsstellen statt im Jahres - auch im Monatsvergleich zu betrachten. Das Drill-Down ist die entgegengesetzte Funktion zum Roll-Up, was wiederum bedeutet, dass der Detail- lierungsgrad verringert wird, so dass statt eines Monatsvergleichs der Anzahl der Produktverkäufe, ein Jahresvergleich durchgeführt werden kann. Beim Drill-across wird zwischen den verschiedenen Würfeln gewechselt.

Slicing, Dicing:

Durch Slicing und Dicing können unterschiedliche Sichten auf das Datenmodell erfolgen. Beim Dicing können einzelne Attribute ausgeblendet werden, das verkleinert den Cube und macht Analysen schneller. Das Slicing bezeichnet eine eingeschränkte Betrachtung auf einen Teil bzw. die Scheibe eines Cubes.

2.2.5 Data Mining

Während OLAP gewünschte Antworten auf die Fragen der Benutzer liefert, zielt das Ver- fahren des Data Mining nach bisher verborgenen Zusammenhängen innerhalb der Unter- nehmensdaten und gibt damit keine Antwort auf gezielte Fragen. Vielmehr erlaubt Data Mining durch automatisierte Analysen aus großen Datenmengen durch das Aufspüren von Mustern neues Wissen zu generieren. Die Erkenntnis des Prozesses hilft dem An- wender anschließend seine Arbeit efIHNWLYHU XQG VFKQHOOHU GXUFK]XI KUHQ Ä=XP (Lnsatz kommen hierbei hauptsächlich Techniken aus den Bereichen der Statistik, z.B. Neuronale Netze, Clusteranalyse- und Entscheidungsbaumverfahren, sowie Algorithmen zum Finden von Assoziationsregeln und Sequenzmustern. Diese Techniken unterstützen die drei Ver- fahren der Segmentierung, Klassifizierung und Assoziierung von abhängigen DaWHQ ³18 Die Datenmustererkennung ist vor allem dann hilfreich, wenn Zusammenhänge und Ent- scheidungen analysiert und strukturiert werden bzw. Entscheidungen bewertet oder Alter- nativen ausgewählt werden müssen. Wichtig hierbei ist, dass nur der Nutzer selbst die Datenmuster interpretieren und damit auf die Gesamtzusammenhänge des Unterneh- mens schlussfolgern kann.

2.2.6 Data Marts

Bei einem DHW handelt es sich in aller Regel um ein zentral positioniertes System, wel- ches zu Analysezwecken übergreifend alle Daten aus den operativen Systemen eines Unternehmens bezieht und extrahiert. Aus organisatorischen Gründen ist es allerdings in

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6 Data Marts Architektur19

Großunternehmen schwierig ein zentrales DWH aufzubauen, was auf die Komplexität und Realisierung zurückzuführen ist. Dies hatte zur Folge, dass viele DWH-Projekte aufgrund der großen Vorlaufzeiten gescheitert sind, bevor ein erster Nutzen eingetreten ist. Aus diesem Grund sind vor allem in größeren Organisationen viele Insellösungen vorzufinden, in denen voneinander unabhängige DWH-6\VWHPH HLQJHVHW]W ZHUGHQ Ä'HUDUWLJH DXWo- nome Datenbestände, die voneinander unabhängig aufgebaut werden, werden als Data Marts (vgl. Abbildung 6) bezeichnet. Data Marts werden in der Regel bereichsbezogen oder regional aufgebaut. Der Nachteil an Data Marts liegt unter anderem darin, dass sie keine bereichsübergreifende Datenanalyse erlauben und das ihre Datendefinitionen in YLHOHQ )lOOHQ LQNRQVLVWHQW VLQG ³20 Nichtsdestotrotz bieten sie eine Möglichkeit die Komple- xität, die an ein zentrales DWH gestellt wird zu verringern und um erst einmal Erfahrun- gen mit dem Thema DWH zu sammeln. Data Marts sollten aber nicht als letzte Ausbau- stufe angesehen werden, sondern langsam auf ein einheitliches Gesamtsystem hingeführt werden, wie z.B. ein zentrales DWH.

2.2.7 Metadaten

Ä8QWHU GHP %HJULII 0HWDGDWHQ YHUVWHKW PDQ JHPHLQKLQ MHGH $UW von Informationen, die für den Entwurf, die Konstruktion und die Benutzung eines Informationssystems benötigt ZHUGHQ ³ 'LH 0HWDGDWHQ EHVFKUHLEHQ DOVR GLH 6WUXNWXU GHU JHVSHLFKHUWHQ 'DWHQ LP ':+ 6LH N|QQHQ GDKHU DXFK DOV Ä'DWHQ EHU 'DWHQ³ DQJHVehen werden und erlauben somit eine gezielte und strukturierte Auswertung von Informationen über die Zusammenhänge eines komplexen Systems.

2.2.8 Business Intelligence

In den letzten Jahren hat sich neben DWH noch eine weitere Begrifflichkeit entwickelt. Im Allgemeinen versteht man unter BI Modelle, Werkzeuge und Methoden zur Entwicklung von Reports durch Endanwender und IT-Spezialisten sowie Plattformen zur Entwicklung komplexer analytischer Systeme.

Der Begriff BI wurde erstmals 1996 aus Überlegungen der Gartner Group erwähnt und ins Leben gerufen:

Ä%\ ,QIRUPDWLRQ 'HPRFUDF\ ZLOO HPHUJH LQ IRUZDUG WKLQNLQJ HQWHUSULVHV ZLWK %XVi- ness Intelligence information and applications available broadly to employees, consul- tants, customers, suppliers, and the public. >«@ Data analysis, reporting and query tools can help business users wade through a sea of data to synthesize valuable information from it ± WRGD\ WKHVH WRROV FROOHFWLYHO\ IDOO LQWR D FDWHJRU\ FDOOHG µ%XVLQHVV ,QWHOOLJHQFH¶ ´21

Nach vielfältigen Untersuchungen stellte man aber fest, dass sich für den Begriff BI als solcher keine richtige Einordnung finden ließ, sondern dieser oftmals aus Marketinggrün- den für die Bezeichnung von verschiedenen Frontend-Tools herhalten musste. Aus die- sem Grund wurde der Begriff BI von Mertens unter verschiedenen Sichtweisen neu be- trachtet und umschrieben. Dabei identifizierte er bei seiner Untersuchung 7 unterschiedli- che Variationen:

Ä %, DOV )RUWVHW]XQJ GHU 'DWHQ- und Informationsverarbeitung: IV für die Unternehmensleitung

2. BI als Filter in der Informationsflut: Informationslogistik

3. BI = MIS, aber besonders schnelle/flexible Auswertungen %, DOV )U KZDUQV\VWHP Ä$OHUWLQJ³

5. BI = Data Warehouse

6. BI als Informations- und Wissensspeicherung

7. BI als Prozess: Symptomerhebung Æ Diagnose ÆTherapie Æ Prognose Æ 7KHUDSLHNRQWUROOH ³22

Auch Gluchowski hat sich Gedanken gemacht und eine Strukturierung mittels zweidimensionalen Ordnungsrahmens vorgenommen (vgl. Abbildung 7).

Abbildung 7 Unterschiedliche Ansichten zum Begriff Business Intelligence23

Abbildung in dieser Leseprobe nicht enthalten

Das Enge BI-Verständnis fasst in der Abbildung all die Applikationen zusammen, die der direkten Entscheidungsfindung dienen. Darunter fallen vor allem OLAP wie auch MIS und

Das Analyseorientierte BI-Verständnis geht darüber noch einen Schritt hinaus und bezieht auch die Benutzer ein, die unmittelbar mit dem System arbeiten. Neben OLAP, MIS und EIS sind dies Text- und Data Mining-Anwendungen, das ad Hoc-Reporting, sowie die Balance Scorecard und das analytische CRM.

Das Weite BI-Verständnis stellt als einzige Voraussetzung an BI Werkzeuge den ent- scheidungsunterstützenden Charakter. Durch die Instrumente soll eine bessere Einsicht in das Unternehmen gegeben werden. Somit sind alle Werkzeuge, die operative Daten zur Informations- und daraus resultierenden Wissensgenerierung aufbereiten und speichern, BI-Instrumente.

Anzumerken ist, dass sich aus langfristiger Sicht BI nur durchsetzen kann, wenn es als eigenständiges Konzept behandelt wird und dabei der Managementunterstützung dient sowie neue Ideen hineinbringt, die sich von bereits bestehenden Konzepten abheben.

[...]


1 Krcmar H. 2005, S.54.

2 Kemper H.-G., Mehanna W., Unger C. 2004, S. 172.

3 SAP Netweaver 2004s http://www.sap.com/germany/plattform/netweaver/components/businessintelligence, (Stand:09.12.06).

4 SAP Deutschland, http://www.sap.com/germany/index.epx, (Stand:09.12.06).

5 Knöll H.-D. Schulz-Sacharow C., Zimpel M. 2006, S. 40.

6 Knöll H.-D., Schulz-Sacharow C., Zimpel M. 2006, S. 41.

7 Ebd. S.41.

8 Peyer M. (ohne Datum).

9 Inmon W.H. 1992.

10 Kurz A. 1999, S.49.

11 Egger N. 2004, S.30-31.

12 Bauer A. 2004, S.49-50.

13 Eigene Abbildung.

14 Bauer A. 2004, S.51.

15 Krcmar H. 2005, S.85-86.

16 Bauer A. 2004, S.103.

17 Ebd., S.106.

18 Knöll Heinz-D., Schulz-Sacharow C., Zimpel M. 2006, S. 60-61.

19 Eigene Abbildung.

20 Mehrwald C. 2003, S.37-39.

21 Anandarajan M., Anandarajan A . 2004, S.18.

22 Mertens, P. 2/2002, S.4.

23 Kemper H.-G., Mehanna W., Unger C. 2004, S.4

Details

Seiten
68
Jahr
2007
ISBN (eBook)
9783638615105
ISBN (Buch)
9783638680738
Dateigröße
1.6 MB
Sprache
Deutsch
Katalognummer
v70197
Institution / Hochschule
Hochschule für Technik und Wirtschaft Berlin
Note
1,7
Schlagworte
Strategien Vorgehensmodelle Einführung Unternehmen

Autor

Teilen

Zurück

Titel: Strategien und Vorgehensmodelle zur Einführung eines SAP BW in Unternehmen