Einsatz eines Data Warehouse-basierten Informationssystems für die Unternehmenskonsolidierung

Inhaltsverzeichnis

Abkürzungsverzeichnis

Abbildungsverzeichnis

Tabellenverzeichnis

1 Zielstellung und Abgrenzung
1.1 Rahmenbedingungen
1.2 Aufbau der Arbeit

2 Grundlagen
2.1 Betriebliche Informationssysteme und Business Consolidation-Information System (BCS-IS)
2.1.1 Administrations- und Dispositionssysteme
2.1.2 Planungs- und Kontrollsysteme
2.1.3 Einordnung von BCS-IS
2.2 Data Warehouse-Konzept
2.2.1 Begriffsbestimmung
2.2.2 Data Warehouse Komponenten
2.2.3 Data Warehouse Architektur
2.3 Moderne Auswertungs- und Analysetechniken
2.3.1 On-Line Analytical Processing
2.3.2 Data Mining
2.3.2.1 Begriffsdefinition
2.3.2.2 Funktionen, Methoden und Techniken des Data Minings
2.3.2.3 Data Mining Prozess
2.4 Unternehmenskonsolidierung
2.4.1 Begriffsbestimmung
2.4.2 Konsolidierungsfunktionen
2.4.3 Systemlandschaft der Unternehmenskonsolidierung bei
Leica Geosystems

3 SAP Business Information Warehouse (SAP BW)
3.1 Produktpositionierung
3.2 Architektur des SAP BW
3.2.1 Datenbereitstellung
3.2.2 Datenhaltung
3.2.3 Informationsanalyse und -präsentation
3.3 Datenfluss in das SAP BW
3.4 BW-Schema
3.4.1 STAR-Schema
3.4.2 Erweitertes STAR-Schema (BW-Schema)
3.4.2.1 Verbindung von Stammdaten und InfoCubes
3.4.2.2 Attribute und ihre Eigenschaften
3.4.2.3 Externe Hierarchien und ihre Eigenschaften
3.4.2.4 Line Item-Dimension
3.4.2.5 Technische Limite eines InfoCubes
3.4.3 SAP BW Terminologie

4 Reportinganforderungen der Konsolidierung
4.1 Vorgehensmodell für die Entwicklung Data Warehouse basierter Informationssysteme
4.2 Vorgehensweise für die Entwicklung von BCS-IS
4.3 Anforderungsanalyse
4.3.1 Berichte
4.3.2 Berichtsübergreifende Anforderungen
4.3.3 Allgemeine Anforderungen

5 Modellierung
5.1 Modellierungsbegriff
5.2 Semantisches Modell
5.2.1 Kennzahlen
5.2.2 Dimensionen und Dimensionstypen
5.2.3 Dimensionen von BCS-IS im Einzelnen
5.3 Logisches Modell
5.3.1 Slowly changing dimensions
5.3.1.1 Szenario A: „Historische Wahrheit“
5.3.1.2 Szenario B: „Heute ist die Wahrheit“
5.3.1.3 Szenario C: „Gestern ist die Wahrheit“
5.3.1.4 Szenario D: „Die vergleichbare Wahrheit“
5.3.1.5 History Tracking für BCS-IS
5.3.2 Modellierungsentscheidungen
5.3.2.1 Abhängige Attribute im BW-Schema
5.3.2.2 m:n-Beziehungen
5.3.2.3 Modellierung der Währung
5.3.3 Hierarchien

6 Datenbeschaffung
6.1 Extraktion
6.2 Transformation
6.3 Laden

7 Datenanalyse
7.1 SAPBW-Analysewerkzeuge
7.2 Queryelemente

8 Fazit

Anhang

Quellenverzeichnis

Eidesstattliche Erklärung.

ABKÜRZUNGSVERZEICHNIS

Abbildung in dieser Leseprobe nicht enthalten

Abbildungsverzeichnis

Abbildung 1: Informationssystempyramide

Abbildung 2: Informationssystempyramide und BCS-IS

Abbildung 3: Betriebliche Informationssystempyramide

Abbildung 4: Berichtssysteme

Abbildung 5: Data Warehouse Komponenten

Abbildung 6: KDD-Prozess

Abbildung 7: Verdichtungsstufen und Konsolidierungspfade

Abbildung 8:. Systemlandschaft Unternehmenskonsolidierung bei Leica Geosystems

Abbildung 9: Datensammlungsmethoden für SEM-BCS

Abbildung 10: BW und das Business Framework

Abbildung 11: Architektur des SAP BW

Abbildung 12: Data Slicing und Data Dicing

Abbildung 13: Datenfluss in das SAP BW

Abbildung 14: Datenfluss mit ODS-Objekten

Abbildung 15: 3-dimensionale Matrix

Abbildung 16: STAR-Schema

Abbildung 17: BW-Schema

Abbildung 18: Unbalancierte Hierarchie

Abbildung 19: "blätterlose" Hierarchie

Abbildung 20: Stammdaten und InfoCubes

Abbildung 21: Attributtabelle mit zeitabhängigem Attribut

Abbildung 22: Phasengliederung nach Krallmann

Abbildung 23: Vorgehensmodell für die Erstellung von DWH

Abbildung 24: Ebenen der Modellierung

Abbildung 25: Ebenen und Sichten eines Modells

Abbildung 26: Kontorahmen- bzw. Kennzahlendimension

Abbildung 27: Konsolidierungseinheiten-Hierarchie

Abbildung 28: Geschäftsbereiche-Hierarchie

Abbildung 29: Länder-Hierarchie

Abbildung 30: Zeit-Hierarchie

Abbildung 31: Szenario A: "Historische Wahrheit"

Abbildung 32: Szenario B: "Heute ist die Wahrheit"

Abbildung 33: Material-Hierarchie für Musterbeispiel Szenario B

Abbildung 34: Szenario C: "Gestern ist die Wahrheit"

Abbildung 35: Szenario D: "Die vergleichbare Wahrheit"

Abbildung 36: Logisches Datenmodell von BCS-IS

Abbildung 37: abhängige Attribute im BW-Schema

Abbildung 38: m:n-Beziehung innerhalb einer Dimensionstabelle

Abbildung 39: Positionen-Hierarchie

Abbildung 40: Konsolidierungseinheiten-Hierarchie

Abbildung 41: Datenbereitstellungsprozess

Abbildung 42: Anwendertypen

Abbildung 43: Layout Gewinn- und Verlustbericht

Abbildung 44: Layout Finanzierungsbericht

Tabellenverzeichnis

Tabelle 1: Vor- und Nachteile der einzelnen DWH-Organisationsformen

Tabelle 2: SAP BW-Terminologie

Tabelle 3: Aggregationsverhalten der Kennzahl Lagerbestand

Tabelle 4: Schema für die Beschreibung von Kennzahlen

Tabelle 5: Kategorischer Dimensionstyp

Tabelle 6: Dimensionen einer legalen Konsolidierung

Tabelle 7: Verdichtungskriterien für Konsolidierungseinheiten-Hierarchie

Tabelle 8: History Tracking für BCS-IS

Tabelle 9: Spaltendefinitionen der Struktur Time row P&L

Tabelle 10: Spaltendefinitionen der Struktur Time row Balance Sheet

1 Zielstellung und Abgrenzung

Mit dieser Arbeit soll sowohl in der Theorie als auch anhand eines konkreten Beispiels untersucht werden, welche Nutzenpotenziale bzw. Risiken zu erwarten sind, wenn ein Data Warehouse (im Folgenden kurz: DWH) für die Analyse von Unternehmens­konsolidierungsdaten eingesetzt wird. Das Ziel der Arbeit ist es, die Eignung von multidimensionalen Informationssystemen für den Bereich Analysen und Reporting im Umfeld der Unter­nehmenskonsolidierung aufzuzeigen. Der Schwerpunkt der Arbeit liegt auf der Modellierung von multidimensionalen Strukturen unter Berücksichtigung der Besonderheiten im Anwendungs­bereich der Unternehmenskonsolidierung.

Die Zielgruppe für das DWH-basierte Informationssystem für die Unternehmenskonsolidierung (im nachfolgenden BCS-IS für Business Consolidation-Information System genannt) ist vor allem das mittlere Management innerhalb des Controllings. Dazu zählen insbesondere Unit Controller (für das Controlling verant­wortliche Mitarbeiter einer rechtlich selbständigen Niederlas­sung), Divisional Controller (Controlling-Verantwortung für eine Division), Regional Controller (Controlling-Verantwortung für eine Geschäftsregion) und natürlich die Corporate Controller (Mitarbeiter der Controllingabteilung in der Konzernzentrale). Gleichzeitig soll das BCS-IS die Basis für ein später zu ent­wickelndes MIS für das Top-Management sein. Das MIS selbst ist jedoch nicht Bestandteil dieser Arbeit. Ebenso werden die Vor­systeme von BCS-IS nur im Rahmen der Informationslogistik für das DWH betrachtet.

1.1 Rahmenbedingungen

Die konkrete Implementierung von BCS-IS erfolgt mit der DWH-Lösung der SAP, SAPBusiness Information Warehouse (SAPBW). Auf die Spezifika von SAPBW wird in Kapitel 3 einge­gangen. Auf der entsprechenden Modellierungsebene werden die Besonderheiten bei der Modellierung mit SAPBW berücksichtigt.

1.2 Aufbau der Arbeit

Zu Beginn der Arbeit wird das BCS-IS im Rahmen der analyti­schen Informationssysteme entsprechend positioniert. Das DWH-Konzept und aktuelle Technologien wie OLAP und Data Mining werden für das zu entwickelnde BCS-IS eingeordnet. Ausgehend von der Systemlandschaft des BCS-IS wird in Kapitel3 das DWH-Produkt der SAP, SAP BW näher vorgestellt. Kapitel 4 behan­delt die Anforderungen, die an das BCS-IS gestellt werden, die dann in Kapitel 5 in multidimensionale Strukturen übersetzt werden. Ein wesentlicher Teil der Informationslogistik eines DWH ist die Datenbeschaffung, auf die in Kapitel 6 näher eingegangen wird. Das Kapitel 7 mit dem Thema Datenanalyse vervollständigt das Thema Informationslogistik. Den Abschluss der Arbeit bildet das Fazit in Kapitel 8.

Für das bessere Verständnis des Lesers wird an dieser Stelle auf Unterschiede zwischen der allgemeinen DWH-Terminologie und SAP-spezifischen Begriffen hingewiesen. Tabelle 2 zeigt eine Gegenüberstellung dieser beiden Begriffswelten. Generell wird in dieser Arbeit die allgemein gültige Terminologie verwendet. Geht es jedoch konkret um das Produkt SAPBW (Beispiel: Kapitel 3.4 BW-Schema) bzw. um die Umsetzung mit SAPBW (Beispiel: Ka­pitel 5.3 Logisches Modell), gilt die SAP-Terminologie.

2 Grundlagen

2.1 Betriebliche Informationssysteme und Business Consolidation-Information System (BCS-IS)

Ziel dieses Kapitels ist die Einordnung bzw. Positionierung des BCS-IS in die Informationssystemlandschaft eines Unter­nehmens. Informations- und Kommunikationssysteme bzw. betriebliche Informationssysteme können in Form der Informa­tionssystempyramide voneinander abgegrenzt werden.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Informationssystempyramide^[1]

2.1.1 Administrations- und Dispositionssysteme

Mit Hilfe von Administrationssystemen können Massendaten rationell und kostengünstig verarbeitet werden, wodurch eine Entlastung des Personals von Routineaufgaben gewährleistet ist. Beispiele für Administrationssysteme sind die Finanzbuchhaltung, die Lohn- und Gehaltsabrechnung oder die Lagerbuchführung.^[2] Administrationssysteme können in Systeme zur Abbildung men­genorientierter Prozesse (z.B. Beschaffung) und in Systeme zur Abbildung wertorientierter Prozesse (z.B. Anlagenbuchhaltung) unterteilt werden. Erfolgt eine Integration der beteiligten Systeme einer Informationssystempyramide auf der vertikalen Achse spricht man von vertikaler Integration von Informations­systemen, während eine Integration der Systeme auf der hori­zontalen Achse analog als horizontale Integration von Informa­tionssystemen bezeichnet wird.

- Beispiel für vertikale Integration von Informationssystemen: Der Wareneingang eines Produktes löst automatisch eine Aus­zahlung aus, die durch ein Buchhaltungssystem durchgeführt wird (Integration mengenorientierter operativer Systeme mit wertorientierten Abrechnungssystemen).
- Beispiel für horizontale Integration von Informations­systemen: Auf der Basis von Fertigungsplänen (Fertigungs­system) wird automatisch der Materialbedarf generiert und entsprechende Beschaffungsprozesse werden ausgelöst.

Dispositionssysteme unterstützen den Anwender in der Vorbe­reitung von periodischen, kurzfristig dispositiven Entscheidungen bzw. sie treffen diese Entscheidungen automatisch.^[3] Zielsetzung ist einerseits ein Optimierungsnutzen, wenn die maschinelle Ent­scheidung besser als die menschliche ist, oder ein Rationalisie­rungsnutzen, wenn der menschliche Entscheidungsträger von Routineentscheidungen entlastet wird.^[4] Beispiele für Disposi­tionssysteme sind Systeme für die Unterstützung des Mahn­wesens oder der Bestelldisposition.

2.1.2 Planungs- und Kontrollsysteme

Während Planungssysteme auf der Grundlage von Administra­tions- und Dispositionssystemen für die Unterstützung der Planung herangezogen werden, unterstützen Kontrollsysteme die Überwachung dieser Pläne. Die von Planungs- und Kontroll­systemen unterstützten Entscheidungen lassen sich wie folgt charakterisieren:^[5]

- schlecht strukturierte Entscheidungsprobleme
- Entscheidungen fallen unregelmässig und in grösseren Zeit­abständen an.
- Entscheidungen haben eine längere Gültigkeitsdauer (im Ver­gleich zu dispositiven Entscheidungen).
- Entscheidungsträger sind meist in der Unternehmensführung angesiedelt.

Die unterbrochene Trennlinie in Abbildung 1 trennt somit Admini­strations- und Dispositionssysteme von Planungs- und Kontroll­systemen. Systeme unterhalb der Trennlinie werden auch als operative Informationssysteme bzw. oberhalb der Trennlinie als analytische Informationssysteme bezeichnet.

Die Bezeichnung „Analytische Informationssysteme“ impliziert bereits, dass diese zur Unterstützung analytischer Tätigkeiten eingesetzt werden. Peter Chamoni und Peter Gluchowski sub­sumieren unter dem Begriff „Analytische Informationssysteme“ Systeme und Konzepte wie DWH, On-Line Analytical Processing und Data Mining.^[6] Dabei handelt es sich um Konzepte, die sich in den letzten Jahren im Bereich der entscheidungsorientierten In­formationssysteme etabliert haben. Analytische Informations­systeme sind somit das logische Komplement zu den Operativen Informationssystemen.^[7]

2.1.3Einordnung von BCS-IS

Unter Berücksichtigung einer tätigkeitsorientierten Unterteilung der betrieblichen Informationssysteme, wie sie in den voran­gegangenen Kapiteln vorgenommen wurde, ist das Ziel von BCS-IS die Unterstützung von analytischen Aufgaben. Daher ist das BCS-IS sicherlich den Analytischen Informationssystemen zuzuordnen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Informationssystempyramide und BCS-IS^[8]

Chamoni und Gluchowski stellen die Informationssystempyramide wie folgt dar:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Betriebliche Informationssystempyramide^[9]

Die funktionale Trennung der Informationssysteme - wie sie u.a. auch von A.-W. Scheer verfolgt wird^[10] – wird auf der Ebene der Analytischen Informationssysteme aufgehoben. Diesem Konzept folgt auch das BCS-IS, da hier durch den DWH-basierten Ansatz Informationen aus verschiedenen operativen Anwendungen inte­griert werden und dem Management^[11] zur Verfügung gestellt werden. Neben dem Integrationsaspekt werden Adhoc-Abfragen und Berichte mit hoher Flexibilität durch den Einsatz multidimen­sionaler Strukturen (sind die Basis von DWH) erst ermöglicht.^[12]

Wie aus Abbildung 2 ersichtlich deckt das BCS-IS sowohl die Ebene der Berichts- und Kontrollsysteme als auch die Ebene der Analyse-Informationssysteme ab.

Zweck der Berichtssysteme ist die Sicherstellung der Informa­tionskongruenz. Informationskongruenz wird erreicht, wenn die richtigen Informationen zum richtigen Zeitpunkt in der richtigen Menge am richtigen Ort in der erforderlichen Qualität zur Ver­fügung gestellt werden.^[13]

Berichtssysteme werden wie folgt eingeteilt:

Reine Berichtssysteme: Periodische Versorgung der Nutzer mit Informatio­nen

Berichtssysteme mit Ausnahme­meldung : Abweichungen von Ver­gleichswerten werden besonders angezeigt (Exception Reporting).

Expertisesysteme: Datenmaterial wird mit zusätzlichen Informationen ange­reichert (Text, Diagnosen, Therapievor­schläge).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Berichtssysteme^[14]

Berichtssysteme können auch nach ihrer Art unterschieden werden:^[15]

- Standardberichte

Gestaltungsparameter dieser Berichte sind genau vorgegeben. Sowohl die Adressaten als auch die Berichtsinhalte sind ein­deutig festgelegt (vgl. Reine Berichtssysteme).

- Abweichungsberichte

Abweichungsberichte werden nur bei Eintritt einer Abwei­chung von vorher festgelegten Schwellwerten bzw. Toleranz­grenzen generiert bzw. Abweichungen werden innerhalb der Berichte besonders angezeigt (vgl. Berichtssysteme mit Aus­nahmemeldung).

- Bedarfsberichte

Mit Bedarfsberichten werden sogenannte Ad hoc-Analysen durchgeführt, die spontan auftretende Fragestellungen beantworten. Diese Art von Berichten sind den Analyse-Informationssystemen aus Abbildung 2 zuzuordnen.

Das BCS-IS umfasst alle 3 oben angeführten Berichtsarten. Zusammenfassend lässt sich das BCS-IS wie folgt charakteri­sieren:

- BCS-IS ist den Analytischen Informationssystemen zuzuord­nen.
- BCS-IS deckt sowohl die Ebene der Berichts- und Kontroll­systeme als auch die Ebene der Analyse-Informationssysteme ab und integriert Daten aus verschiedenen operativen Anwen­dungen (keine funktionale Trennung von BCS-IS).
- Das BCS-IS basiert auf einem DWH.
- Innerhalb der Berichtssysteme werden Standard-, Abwei­chungs- und Bedarfsberichte zur Verfügung gestellt.

2.2 Data Warehouse-Konzept

2.2.1 Begriffsbestimmung

Der Begriff DWH im engeren Sinne bezeichnet eine von den operativen DV-Systemen isolierte, unternehmensweite Daten­basis, die anhand einer kon­sequenten Themenausrichtung unter­nehmensrelevanter Sachverhalte speziell für Endbenutzer aufge­baut ist.^[16] Aus dieser Definition wird ersichtlich, dass mit einem DWH durch Integration verschiedener operativer Datenbestände ein single point of truth ^[17] im Unternehmen erreicht werden soll. Aus der Begriffsbestimmung lassen sich 4 wesentliche Charakteristika eines DWH ableiten:^[18]

- Themenorientierung: Das DWH hat zum Ziel, aus operativen Daten entscheidungsrelevante Informationen zu gewinnen. Gemäss dem Informa­tionsbedürfnis der Entscheidungsträger sind diese Daten themenorientiert abzulegen. Operative Systeme sind meist nach prozessorientierten Gesichtspunkten gestaltet, im DWH ist jedoch ent­scheidend, welche Informa­tionen für die Analyse benötigt werden bzw. welche Informa­tionen für eine fundierte Ent­scheidung notwendig sind.
- Integration: Darunter versteht man die Vereinheitlichung der Daten aus den operativen Systemen im DWH. Die Vereinheit­lichung erfolgt hinsichtlich Bezeichnung, Identifikationsschlüs­sel, Typ, Format, Syntax und Semantik.^[19]
- Beständigkeit: Im Gegensatz zu operativen Daten werden Daten im DWH um aktuelle Daten aus den operativen bzw. externen Systemen ergänzt und niemals überschrieben. Ein Überschreiben der Daten würde die Darstellung von Zeit­reihen unmöglich machen. Alle Zugriffe auf das DWH erfolgen ausschliesslich lesend.
- Zeitraumbezug: In den operativen, transaktionsorientierten Systemen ist meist nur der aktuelle Stand der Geschäfts­daten interessant, während im DWH auch die Veränderung der Geschäftsdaten auf der zeitlichen Achse von Interesse ist, um Entwicklungen und Trends beurteilen zu können. Um ein Überschreiben der Daten zu verhindern, werden Geschäfts­daten bei der Übernahme in das DWH mit einem Zeitstempel versehen.

Die Begriffsdefinition von DWH im engeren Sinne umfasst ledig­lich die zentrale Datenbasis. Die Datenbasis alleine erfüllt jedoch nicht den Anspruch an eine DWH-Lösung. Neben der zentralen Speicherung der Daten in der Datenbasis sind für die Informa­tionsbereitstellung der Daten für Analysesysteme bzw. –werk­zeuge folgende Anforderungen zu berücksichtigen:^[20]

- Überführung von Transaktionsdaten in eine separate Speiche­rung mit indizierten Metadaten für analytische Zwecke
- Zusammenfassung von Transaktionsdaten zu Zeitreihen für Zwecke der Visualisierung und Analyse
- unternehmensweite Versorgung von Analysesystemen bzw. -werkzeugen (MSS)

Analysewerkzeuge sind jedoch logisch-funktional von der DWH-Lösung zu trennen. Es gibt keine einheitliche Definition der Begriffe DWH-Konzept bzw. DWH-Lösung.

Unbestritten ist jedoch, dass eine DWH-Lösung zwei wesentliche Funktionen zu erfüllen hat:^[21]

- Integration von Daten aus verschiedenen Quellsystemen (Input)
- Aufbereitung und Bereitstellung der Daten für Zielsysteme (Output)
Im Rahmen dieser Arbeit wird für das BCS-IS der gesamte DWH-Prozess von der Datenextraktion bis zur Analyse der Daten betrachtet.

2.2.2Data Warehouse Komponenten

Das Grundkonzept des Data Warehousings ist das Zusammen­führen von Daten aus verschiedenen Quellen und das (optimier­te) Bereitstellen von Daten für die Datenanalyse.

Dieses Grundkonzept gilt für jedes DWH, trotzdem gibt es in der Literatur keine einheitliche Bezeichnung für die einzelnen DWH-Komponenten. Einheitlich sind jedoch die von den Komponenten übernommenen Funktionen. Diese stehen im Mittelpunkt der nachfolgenden Beschreibungen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Data Warehouse Komponenten^[22]

Operative und externe Quellsysteme

Interne (meist operative DV-Systeme) und externe Quellsysteme sind Datenlieferanten für das Data Warehouse und kein direkter Bestandteil des DWH-Systems.

Inputkomponente

Die Inputkomponente umfasst folgende Funktionalität:^[23]

- Extraktion der Daten aus den unterschiedlichsten Quellen
- Transformation der Daten – die Transformation der Daten umfasst die Daten­integration (z.B. Daten formatieren oder bereinigen), die Datenfilterung und das Weiterverarbeiten von Daten (z.B. Daten verdichten oder kombinieren).
- Transport und Ladevorgang in die Datenbasis (= Speiche­rungskomponente) des Data Warehouses

Speicherung/Verwaltungskomponente

Die Speicherungskomponente bildet die Datenbasis, die sowohl aktuelle als auch historische Daten aus allen eingebundenen Unternehmensbereichen enthält.^[24] Sie ist die zentrale Kom­ponente des Data Warehouses.

Outputkomponente

Diese Komponente übernimmt die Aufbereitung und die Bereit­stellung der Daten für die Analysewerkzeuge (Transformations- und Verteilungsfunktion).

Administrationskomponente (Metadatenbanksystem)

In einer Metadatenbank werden sowohl datenverarbeitungs­technische (z.B. Feld­länge eines InfoObjects) als auch betriebs­wirtschaftliche Informationen (z.B. betriebswirtschaftliche Defini­tion von Umsatz) über den Datenbestand eines Data Warehouses gespeichert.

Anfrage- und Analysewerkzeuge

Über diese Komponente wird der Zugang zu den Daten im Data Warehouse gewährleistet. Durch diese Werkzeuge werden Ana­lysefunktionen (z.B. Drill-Down, Data Dicing oder Data Slicing) zur Verfügung gestellt.

2.2.3Data Warehouse Architektur

Mit dem Begriff DWH-Architektur wird in der Literatur einerseits der Schichtenaufbau der DWH-Lösung bezeichnet, andererseits geht es bei der DWH-Architektur um Organisationsformen des DWH. Die Organisationsform wird beeinflusst von der Organi­sation des Unternehmens, der IT-Infrastruktur sowie der IT-Ver­antwortlichkeit.^[25]

Der Schichtenaufbau ergibt sich aus der Anordnung der einzel­nen DWH-Komponenten bzw. der Verteilung der Funk­tionalität auf die DWH-Komponenten. Der Schichtenaufbau des DWH wird aus Abbildung 5 ersichtlich. Zwischen operativen und externen Quellsystemen und der Datenbasis befindet sich die Inputschicht und zwischen Datenbasis und Anfrage- und Analysewerkzeuge befindet sich die Outputschicht.

Aus Performancegründen und zur besseren Überschaubarkeit kann die Datenbasis des DWH in kleinere Einheiten, in soge­nannten Data Marts^[26] aufgeteilt sein, wodurch sich eine zusätz­liche Schicht ergibt. In diesem Zusammenhang ist auch der Operational Data Store (ODS) zu nennen. Der ODS ist ein Kon­strukt, das zwischen operativen und externen Quell­systemen und dem eigentlichen DWH liegt und aktuelle Daten auf detaillierter Ebene enthält. Der ODS dient zur Überbrückung der Zeitspanne zwischen zwei Datenübernahmen in das DWH.

Nachfolgend stehen jedoch die Organisationsformen des DWH im Mittelpunkt der Betrachtung. Hier gibt es vor allem 3 Ausprä­gungsvarianten:

Zentrales Data Warehouse

In der Unternehmensorganisation existiert nur ein zentrales Data Warehouse, das sowohl die Unternehmenszentrale als auch dezentrale Unternehmensbereiche bedient. Dabei ist unerheblich, ob die dezentralen Unternehmensbereiche über eigene, lokale operative DV-Systeme verfügen oder ob die operativen DV-Systeme ebenfalls zentral organisiert sind. Nachdem dezentrale operative DV-Systeme in der Regel auf unterschiedlichen Datenmodellen basieren (physisch als auch logisch), müssen entsprechende Transformationsprogramme zum Einsatz kommen.^[27]

Verteiltes Data Warehouse

Bei dieser Organisationsform verfügen die einzelnen Unter­nehmensbereiche über ein lokales DWH. Das heisst, das DWH ist als verteilte Datenbasis implementiert, wodurch die ausge­gliederten Unternehmensbereiche einen hoch verfügbaren Zugang zu den lokalen Daten haben.

Virtuelles Data Warehouse

Während die beiden ersten Varianten über ein oder mehrere DWHs mit eigener Datenbasis verfügen, besteht ein virtuelles DWH lediglich aus einer Meta-Datenebene, welche den Be­nutzer eines DWH einen begrenzten Zugriff auf detaillierte, operative Daten ermöglicht. Eine eigene DWH-Datenbasis besteht nur virtuell, physisch existieren jedoch nur die Meta­daten.^[28]

Dieses Konzept widerspricht der eigentlichen DWH-Philosophie, bei der die separate Datenhaltung (d.h. eigene Datenbasis) ein wesentlicher, zentraler Bestandteil ist. Aus­serdem würde ein rein virtuelles Konzept die Performance der operativen Systeme sehr beeinträchtigen. Deshalb ist diese Organisationsform nur in Ausnahmefällen bzw. als Ergänzung zu einem klassischen DWH zu finden, um z. B. den direkten Zugriff auf eine begrenzte Menge von operativen, hoch­aktuellen Daten zur Verfügung zu stellen.

In nachfolgender Tabelle werden die Vor- und Nachteile der oben angeführten Organisationsformen einander gegenübergestellt:

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 1: Vor- und Nachteile der einzelnen DWH-Organisations­formen

2.3 Moderne Auswertungs- und Analysetechniken

Es macht relativ wenig Sinn, im Rahmen eines DWH-Projektes eine integrierte, konsistente und analyse-optimierte Datenbasis zur Verfügung zu stellen, ohne sich über Zugriffsmöglichkeiten Gedanken zu machen. Im Bereich der multidimensionalen Analyse sind hier vor allem zwei Konzepte zu nennen: On-Line Analytical Processing und Data Mining. Diese werden in den folgenden Kapiteln näher betrachtet.

2.3.1 On-Line Analytical Processing

On-Line Analytical Processing (OLAP) ist eine Softwaretechnolo­gie, die Managern wie auch qualifizierten Mitarbeitern aus den Fachabteilungen schnelle, interaktive und vielfältige Zugriffe auf relevante und konsistente Informationen ermög­lichen soll.^[29] Zentrale Forderung von OLAP ist, dass der Endanwender eine Anfrage an das DWH in der Terminologie der realen Geschäfts­welt definieren kann und diese vom OLAP-Tool in strukturierte Anfragesprachen (z.B. SQL) übersetzt wird. OLAP ist eng mit dem DWH-Konzept verbunden, ist jedoch nur eine Art von Aus­wertetechnik und berücksichtigt nicht die zu Grunde liegende Datenlogistik.^[30]

Die funktionalen Forderungen an OLAP wurden von E.F. Codd definiert und lauten wie folgt:^[31]

1 Mehrdimensionale konzeptionelle Perspektive

Entsprechend der multidimensionalen Sicht eines Analytikers auf die Kennzahlen eines Unternehmens, soll auch die kon­zeptionelle Sicht eines OLAP-Modells multidimensional sein.

2 Transparenz

OLAP-Werkzeuge müssen sich nahtlos in das vorhandene Informationssystem einfügen. Als Schnittstelle zum Anwender muss eine bedienerfreundliche Benutzeroberfläche mit mög­lichst intuitiver Erlernbarkeit zur Verfügung stehen. Der Nutzer darf sich auf keinen Fall mit technischen Details aus­einandersetzen müssen. Der Datenursprung muss verborgen werden bzw. darf höchstens als Zusatzinformation mitge­lie­fert werden.

3 Zugriffsmöglichkeit

Durch eine offene Systemarchitektur soll der Zugriff auf unter­nehmensinterne und -externe Daten unterstützt werden.

4 Stabile Antwortzeiten bei der Berichtserstattung

Antwortzeiten der Datenanfragen sollen annähernd stabil bleiben, selbst wenn das Datenvolumen bzw. die Anzahl Dimensionen überproportional zunehmen.

5.Client-/Server-Architektur

Der Einsatz in Client-/Server-Architekturen sollte unterstützt werden.

6. Grundprinzipien der gleichgestellten Dimensionen

Die einzelnen Dimensionen müssen gleichgestellt und gleich­behandelt werden, d. h. alle Operationen müssen auf allen Dimensionen durchführbar sein. Spezialfunktionen in einzel­nen Dimensionen sind weitgehend zu vermeiden.

7. Dynamische Verwaltung „dünnbesetzter“ Matrizen

Durch Anwachsen des Datenbestands und durch hohe Detaillierung kommt es zu sogenannten dünnbesetzten Matri­zen^[32]. Diese dünnbesetzten Matrizen müssen dynamisch ver­waltet werden, um das Datenvolumen nicht unnötig auf­zu­blähen. Allerdings darf die multidimensionale Daten­manipula­tion nicht beeinflusst werden.

8.Mehrbenutzerfähigkeit

Das System muss mehrbenutzerfähig sein. Damit verbunden ist ein Sicherheitskonzept, das dem Datenbankadministrator die Möglichkeit gibt, den Datenzugriff und die Datenverfüg­barkeit zu begrenzen.

Unbeschränkte kreuzdimensionale Operationen über Dimensionen hinweg

Es müssen verschiedene Operationen über mehrere Dimen­sionen hinweg möglich sein. Benötigt werden diese Opera­tionen zur ausgereiften Datenanalyse und zur Kennzahlen­berechnung. Die Berechnungsvorschriften für Kennzahlen müssen im System abgelegt und als Metadaten verwaltet werden können.

Intuitive Datenmanipulation

Eine einfache Benutzerführung und -oberfläche soll den Zugriff und die Arbeit mit den Daten mit wenig Lernaufwand ermöglichen. Die multidimensionalen Operationen wie Drill-down oder Roll-up sollen einfach und intuitiv durchführbar sein.

Flexibles Berichtswesen

Ein flexibles Berichtswesen soll neben vorgefertigten Standardberichten auch dynamisch erzeugte Auswertungs­protokolle (als Grafik und/oder in Schriftform) unterstützen.

Unbegrenzte Dimensions- und Aggregationsstufen

Diese Regel verlangt vom OLAP-System eine unbegrenzte Anzahl an Dimensionen sowie keine Einschränkung bezüglich der Anzahl und Art der Konsolidierungsebenen innerhalb von Dimensionen.

2.3.2 Data Mining

2.3.2.1 Begriffsdefinition

Im Gegensatz zu OLAP ist Data Mining eine Analysetechnik, bei der in der Regel vom Benutzer keine spezifizierten, detaillierten Eingrenzungen der Datenrecherche vorgegeben werden. Mit Data Mining-Methoden können versteckte Informationen in grossen Datenbeständen entdeckt werden bzw. zuverlässige Prognosen von unbekannten oder zukünftigen Werten und Entwicklungen getroffen werden.^[33]

Data Mining ist ein Oberbegriff für Methoden und Techniken, die bislang unbe­kannte Zusammenhänge in den Datenbeständen eines Unternehmens aufdecken helfen.^[34] Data Mining kann mit dem deutschen Begriff Datenmustererkennung übersetzt

werden. Unbestätigte Hypothesen oder empirische Beobach­tungen kön­nen gezielt durch Data Mining verifiziert, erweitert oder auch widerlegt werden. Durch effizient maschinell analy­sierte und aufbereitete Daten entstehen Wett­bewerbsvorteile. Speziell in den Bereichen Marketing, strategische Planung und Controlling erhöhen Data Mining-Methoden und -Techniken die Qualität des Entscheidungsfindungsprozesses. In der Literatur werden zwei Data Mining-Begriffe unterschieden:

Data Mining im engeren Sinn

Unter Data Mining im engeren Sinn versteht man das Analy­sieren von Datenbeständen nach Mustern ohne vorheriges Aufstellen einer Hypothese durch den Anwender.

Data Mining im weiteren Sinn

Darunter versteht man das Analysieren von Datenbeständen nach Mustern nach einem fest vorgegebenen hypothetischen Tatbestand.

Data Mining ist schon seit über 30 Jahren bekannt, auch wenn es vielleicht damals nicht als Data Mining bezeichnet wurde. Statis­tische Analysen bestehend aus den klassischen statistischen Methoden wie Korrelation, Regression oder die Qui-Quadrat-Methode waren die ersten Data Mining-Anwendungen. Die Pioniere auf diesem Gebiet waren SAS, SPSS und IBM. In den späten 80ern wurden die statistischen Analysen durch neue Techniken und Methoden wie Fuzzy logic oder neuronale Netze ergänzt.

[...]

^[1] Quelle: (IWI Uni Leipzig 2001)

^[2] vgl. (IWI Uni Leipzig 2001)

^[3] vgl. (IWI Uni Leipzig 2001)

^[4] vgl. (Totok 2000), S. 39

^[5] vgl. (IWI Uni Leipzig 2001)

^[6] vgl. (Chamoni; Gluchowski 1999), S. 5

^[7] vgl. (Gabriel 1999), S. 420

^[8] Quelle: eigene Darstellung in Anlehnung an (IWI Uni Leipzig 2001)

^[9] Quelle: eigene Darstellung in Anlehnung an (Chamoni; Gluchowski 1999), S. 11

^[10] vgl. (Scheer 1995), S. 5

^[11] unter dem Begriff „Management“ wird die in Kapitel 1 definierte Zielgruppe des BCS-IS verstanden

^[12] vgl. (Holthuis 2001), S. 42 f.

^[13] vgl. (Totok 2000), S. 25

^[14] Quelle: eigene Darstellung in Anlehnung an (IWI Uni Leipzig 2001)

^[15] vgl. (Totok 2000), S. 26

^[16] vgl. (Mucksch; Behme 2000), S. 14

^[17] vgl. (Kruczynski 2000), S. 5

^[18] vgl. (Inmon 1996), S. 33 ff.

^[19] vgl. (Totok 2000), S. 43

^[20] vgl. (Heine 1999), S. 113 f.

^[21] vgl. (Heine 1999), S. 111

^[22] Quelle: (Heine 1999), S. 120

^[23] vgl. (Holthuis 2001), S. 88

^[24] vgl. (Holthuis 2001), S. 80

^[25] vgl. (Totok 2000), S. 103

^[26] Ein Data Mart beinhaltet einen bewusst redundant gehaltenen Ausschnitt der DWH-Datenbasis und ist meist für eine spezielle Gruppe von Analysten (z.B. Marketing-Fachleute) konzipiert.

^[27] vgl. (Mucksch; Behme 2000), S. 51

^[28] vgl. (Mucksch; Behme 2000), S. 55 f.

^[29] vgl. (Chamoni; Gluchowski 2000), S. 334

^[30] vgl. (IWI Uni Leipzig 2001)

^[31] vgl. (IWI Uni Leipzig 2001)

^[32] Eine dünnbesetzte Matrix enthält eine grosse Anzahl Zellen mit dem Wert NA (not available)

^[33] vgl. (Holthuis 2001), S. 57

^[34] vgl. (Mucksch; Behme 2000), S. 31