Inhaltsverzeichnis I

Inhaltsverzeichnis   

INHALTSVERZEICHNIS.   I

ABBILDUNGSVERZEICHNIS   IV

TABELLENVERZEICHNIS   V

ABK  ÜRZUNGSVERZEICHNIS.  VI

1  EINLEITUNG  1

1.1  ABGRENZUNG DES THEMAS UND GANG DER UNTERSUCHUNG.  2

2  GRUNDLAGEN  3

2.1  DATA WAREHOUSE  3

2.2  MANAGEMENT-INFORMATIONSSYSTEME  3

2.2.1  Anforderungen an ein MIS  3

2.3  BALANCED SCORECARD.  3

2.4  DATA MARTS  3

2.5  ONLINE ANALYTICAL PROCESSING  3

2.6  DATA MINING  3

3  AUFBAU EINES DATA WAREHOUSE.  3

3.1  DATENBASIS.  3

3.2  DATENMIGRATION.  3

3.2.1  Extraktionskomponente  3

3.2.2  Transformationskomponente.  3

3.2.3  Transport und Laden der Daten.  3

3.2.4  Integrationskomponente.  3

3.3  META-DATENBANK.  3

3.4  ARCHIVIERUNG  3

3.5  ANALYSEVERFAHREN.  3

4  REALISIERUNG DES DATA WAREHOUSE-KONZEPTES UNTER SAP R/3  3

4.1  DAS BUSINESS INFORMATION WAREHOUSE VON SAP  3

4.2  AUFBAU DES „EXECUTIVE INFORMATION SYSTEM“ VON SAP  3

4.2.1  Datenbasis im „Executive Information System“  3

4.2.1.1  Aspekte.  3

4.2.1.2  View-Aspekte  3

4.2.2  Datenmigration im „Executive Information System“  3

4.2.2.1  Senderstruktur  3

4.2.2.2  Empfängerstruktur  3

4.2.2.3  Übertragungsregeln  3

Inhaltsverzeichnis II

4.2.3  Meta-Daten im „Executive Information System“  3

4.2.4  Archivierung im EIS.  3

4.2.5  Analysewerkzeuge im EIS  3

4.2.5.1  Berichtsheft  3

4.2.5.2  Recherche  3

5  VORGEHENSWEISE ZUR EINFÜHRUNG EINES DATA WAREHOUSE.  3

5.1  VORÜBERLEGUNGEN ZUR PROJEKTDURCHFÜHRUNG.  3

5.1.1  Umfang des Projektes  3

5.1.2  Business Process Reengineering  3

5.1.3  Anforderungen an den Projektablauf.  3

5.1.3.1  Sponsoren  3

5.1.3.2  Projektgruppe  3

5.1.3.3  Projektleiter  3

5.1.3.4  Auswahl des Vorgehensmodells.  3

5.2  ANALYSE DES INFORMATIONSBEDARFS.  3

5.2.1  Definition der Anforderungen  3

5.2.1.1  Ist-Analyse.  3

5.2.1.2  Soll-Konzept.  3

5.2.2  Beschreibung der Anforderungen  3

5.2.3  Analyse der Anforderungen.  3

5.2.4  Besonderheiten der Analyse des Informationsbedarfs  bei

Data  Warehouse-Projekten  3

5.3  DESIGN.  3

5.3.1  Semantische Datenmodellierung.  3

5.3.1.1  Kennzahlen.  3

5.3.1.2  Dimensionen.  3

5.3.1.3  Datenmodell  3

5.3.1.3.1  Das modifizierte Entity-Relationship-Model  3

5.3.1.3.2  Eignung des ERM zur Darstellung multidimensionaler Datenstrukturen  3

5.3.2  Logische Datenmodellierung  3

5.3.2.1  Star Schema  3

5.3.2.2  Galaxy Schema.  3

5.3.2.3  Snow Flake Schema.  3

5.3.3  Physische Datenmodellierung.  3

5.4  IMPLEMENTIERUNG  3

5.5  EINSATZ  3

6  PROBLEMFELDER DES DATA WAREHOUSE-EINSATZES.  3

6.1  SICHERHEIT EINES DATA WAREHOUSE.  3

6.2  DATENQUALITÄT IM DATA WAREHOUSE  3

7  ZUSAMMENFASSUNG / FAZIT  3

Inhaltsverzeichnis III

LITERATURVERZEICHNIS   III

ANHANG. III   

A  ERLÄUTERUNGEN ZUR SAP AG.  III

B  ERLÄUTERUNGEN ZUR DEUTSCHER FACHVERLAG GMBH.  III

C  UMWANDLUNG VON KOMPLEXITÄTEN IM ERM  III

D  DIMENSIONSTABELLE „OBJEKTE“  III

E  ZEITAUFWAND EINES DATA WAREHOUSE-PROJEKTES  III

Abbildungsverzeichnis   

Abbildungsverzeichnis   

Abbildung  1: Aufbau eines Data Warehouse unter Verwendung von  

Data  Marts.  

Abbildung  2: Mehrdimensionaler Datenwürfel.  

Abbildung  3: Aufbau eines Data Warehouse.  

Abbildung  4: Komponenten zur Datenmigration.  

Abbildung  5: Aufbauschema SAP - EIS.  

Abbildung  6: Grafische Darstellung eines Aspekts.  

Abbildung  7: Ablauf einer Recherche im EIS.  

Abbildung  8: Grafische Darstellung des verwendeten Vorgehensmodells.  

Abbildung  9: Exemplarischer Ablauf einer Anforderungsanalyse.  

Abbildung  10: Du-Pont-Kennzahlensystem.  

Abbildung  11: Hierarchische Darstellung der Dimension Zeit.  

Abbildung  12: Grafische Darstellung der klassischen ER-MKomponenten.  

Abbildung  13: Beziehungstypen der semantische Datenmodellierung  

im  ERM.  

Abbildung  14: Modellierung der Dimension Zeit im ERM.  

Abbildung  15: Verdichtung von Daten im ERM.  

Abbildung  16: Alternative Darstellungsformen von Kennzahlen und  

Dimensionen   

Abbildung  17: Beispiel eines Star Schemas.  

Abbildung  18: Beispiel eines Galaxy Schemas.  

Abbildung  19: Normalisierung der Dimensionstabelle Zeit.  

Abbildung  20: Beispiel eines Snow Flake Schemas  

Tabellenverzeichnis V   

Tabellenverzeichnis   

Tabelle 1:  Beispielhafte Bewegungsdaten aus der Kostenrechnung.  30

Tabelle 2:  Phaseninhalte des Phasenmodells.  45

Tabelle 3:  Vor- und Nachteile des Star Schema-Einsatzes.  70

Tabelle 4:  Dimensionstabelle Zeit mit enthaltenen Verdichtungsstufen  71

Abkürzungsverzeichnis VI

Abkürzungsverzeichnis

BPR = Business Process Reengineering bzgl. = bezüglich d.h. = das heißt DV = Datenverarbeitung EIS = Executive Information System ERM = Entitiy-Relationship-Model etc. = et cetera i.d.R. = in der Regel IT = Informationstechnologie IV = Informationsverarbeitung MIS = Management-Informationssystem OLAP = Online Analytical Processing usw. = und so weiter z.B. = zum Beispiel

1 Einleitung 1

1 Einleitung

Kaum ein Thema wurde in den letzten Jahren in der IT-Branche so intensiv und so kontrovers diskutiert wie das Data Warehouse. Die Bedeutung des Data Warehouse für die Informationstechnologie wird nachhaltig durch die Tatsache bekräftigt, daß ein Unternehmen wie die SAP AG in ihrer Branchensoftware SAP R/3 ein Data Warehouse in Form des Moduls „Executive Information System“ als Standardkomponente integriert. Daraus läßt sich erahnen, welcher Stellenwert dem Data Warehouse seitens der Softwareentwickler beigemessen wird. Die Grundidee des Data Warehouse ist relativ simpel: Um den Entscheidungsprozeß auf Unternehmensebene zu verbessern (z.B. durch Risikoreduktion mittels „genauerer“ Informationen) wird eine zentrale, unternehmensweite Informationsbasis angestrebt, aus welcher man mit Hilfe von geeigneten Werkzeugen eigenständig zeitnahe, problemspezifische Informationen gewinnen kann. 1)

Hieraus folgt, daß es zwei unterschiedliche Sichtweisen auf das Konzept des Data Warehouse gibt: 2)

ƒ Die technische Sichtweise: Im Vordergrund steht die Realisierung der Informationsbasis anhand eines entsprechenden Datenmodells und seine Implementierung in einer neuen oder bereits existierenden Systemumgebung. ƒ Die entscheidungsorientierte Sichtweise: Welche Informationen sind bereitzustellen, um eine bestmögliche Entscheidungssituation herbeizuführen. Zu klären ist somit, welche Vorgehensweise sinnvoll ist, damit ein für das Unternehmen möglichst optimaler Aufbau des Data Warehouse bewerkstelligt werden kann.

¹⁾ Vgl. Lehmann, P., Ellerau, P.: Definierte Fachbegriffe als kritischer Erfolgsfaktor eines Data

Warehouses, in: Reiterer, H., Mann, T.: Informationssysteme als Schlüssel zur Unternehmens-

führung - Anspruch und Wirklichkeit, Konstanz, 1997, S. 170.

²⁾ Vgl. Exner, A.: Erfahrungen beim Aufbau eines Data Warehouses im Controlling, in:

Mucksch, H., Behme, W.: Das Data Warehouse-Konzept, Wiesbaden, 1998, S. 556-559.

1 Einleitung 2

1.1 Abgrenzung des Themas und Gang der Untersuchung

Ziel dieser Ausarbeitung ist die Darstellung eines Data Warehouse in Bezug auf seine Verwendung, seinen Aufbau und seine Realisierung. Grundlage der Betrachtung ist das Data Warehouse in seiner Funktion als System zur Unterstützung der Entscheidungsfindung oder auch Management-Informationssystem. Um Mißverständnissen vorzubeugen wird darauf hingewiesen, daß damit nicht die Unterstützung von Geschäftsprozessen als zentrale Aufgabe des Data Warehouse zu verstehen ist. 3)

Zu Beginn werden im 2. Kapitel dieser Arbeit grundlegende Begriffe erläutert, um das Verständnis für das Konzept des Data Warehouse zu erleichtern. Anschließend folgt im 3. Kapitel die Beschreibung des klassischen Aufbaus eines „Daten-Warenhauses“. ⁴⁾ Aufbau ist in diesem Zusammenhang als Architektur aufzufassen und nicht als die mit ihr verbundenen Aktivitäten. Diese Aktivitäten sind wiederum Grundlage des 5. Kapitels, welches sich mit der Vorgehensweise bei der Data Warehouse-Einführung beschäftigt. Da diese Untersuchung am Beispiel des „Executive Information System“ von SAP erfolgt, besteht die Notwendigkeit, den Aufbau des EIS mit dem klassischen Aufbau eines Data Warehouse zu vergleichen. Dieser Vergleich erfolgt in Kapitel 4 dieser Ausarbeitung.

In den unterschiedlichsten Phasen der Einführung eines Data Warehouse können die unterschiedlichsten Probleme auftreten. Daher ist es sinnvoll, diesem überaus wichtigen Aspekt ein eigenes Kapitel zu widmen (Kapitel 6). Abschließend erfolgt eine Zusammenfassung des behandelten Themas und es wird ein entsprechendes Fazit in Verbindung mit einem Ausblick auf zukünftige Entwicklungen (Kapitel 7) gegeben.

³⁾ Siehe hierzu Kapitel 2 (Begriffsdefinition Data Warehouse)

⁴⁾ Synonym für Data Warehouse, trotz der eigentlich falschen Übersetzung (Warehouse

entspricht dem deutschen Wort Lagerhaus) ein treffender Begriff, da hier die Beziehung

Informations(Daten)-bereitsteller bzw. -anbieter und Informationskonsument in Form eines

Warenhauses adäquat dargestellt werden kann, vgl. hierzu Mucksch, H., Behme, W.: Das

Data Warehouse-Konzept als Basis einer unternehmensweiten Informationslogistik, in:

Mucksch, H., Behme, W.: Das Data Warehouse-Konzept, Wiesbaden, 1998, S. 36-38.

1 Einleitung 3

2 Grundlagen 3

2 Grundlagen

Um die in dieser Arbeit verwendeten Begriffe und Terminologien richtig zu verstehen und zu interpretieren ist es notwendig, einleitend einige Ausdrücke zu erörtern.

2.1 Data Warehouse

Das Data Warehouse hat seinen Ursprung in den 80er Jahren. Zu dieser Zeit entwickelte die Firma IBM eine Software unter dem Namen „European Business Information System“ (später auch „Information Warehouse Strategy“ genannt), welche das Problem der Informationsflut in Unternehmen und der damit verbundenen Heterogenität der Daten beheben sollte. Ziel hierbei war die Bereitstellung von integeren, zeitnahen Informationen aus den unterschiedlichsten Bereichen eines Unternehmens zum Zwecke der Entscheidungsunterstützung. ⁵⁾ Somit läßt sich das Data Warehouse als ein Prozeß bezeichnen, der Daten verschiedenster Art und Herkunft in einer einzigen Entscheidungsdatenbank zusammenfaßt, aus welcher die Endbenutzer mittels zweckmäßiger Suchmechanismen ihre Informationen gewinnen können. ⁶⁾ Betrachtet man das Data Warehouse mehr von der technischen Seite, so gibt die Definition von Rautenstrauch einen guten Einblick in die zugrundeliegende Thematik: „Als Data Warehouse wird eine Sekundärdatenbank bezeichnet, die mit Hilfe geeigneter Extraktionsmechanismen aus einer oder mehreren operativen Datenbanken erzeugt wird. Die Daten der Sekundärdatenbank sind dabei so aufzubereiten und zu aggregieren, daß sie hinsichtlich zu erwartenden Auswertungen in möglichst geeigneter Weise zusammengestellt werden.“ ⁷⁾ Die obigen Ausführungen beschreiben das Data Warehouse in seinem herkömmlichen Sinn, d.h. in seiner Funktion als Management-Informationssystem. Neuere Definitionen erweitern diese Sichtweise. Diesen Definitionen zur Folge dient ein Data Warehouse nicht nur zur Lieferung von Informationen, sondern darüber hinaus auch zur Entwicklung von Wissen aus

⁵⁾ Vgl. Mucksch, H., Behme, W.: Das Data Warehouse-Konzept als Basis einer unternehmens-weiten Informationslogistik, in: Mucksch, H., Behme, W.: Das Data Warehouse-Konzept,

Wiesbaden, 1998, S. 35.

⁶⁾ Vgl. Eckerson, W.: Red Brick Systems enhances its data warehouse product, in: Network

World, Vol. 10, Iss. 25, 1993, S. 35.

⁷⁾ Rautenstrauch, C.: Effiziente Gestaltung von Arbeitsplatzsystemen, Bonn, 1997, S. 104.

2 Grundlagen 4

diesen Informationen und anschließender Ableitung von Aktionen aus dem gewonnenen Wissen. Somit fungiert ein Data Warehouse als

Unterstützungskomponente von Geschäftsprozessen und übernimmt folglich deren Steuerung und Kontrolle. 8)

In der Realität läßt sich diese Entwicklung analog beobachten. Der Software-Konzern SAP AG trägt dieser Entwicklung Rechnung, indem zwei Komponenten in Bezug auf den Data Warehouse-Einsatz zur Verfügung gestellt werden. Das „Executive Information System“ auf der einen Seite stellt die konservative Betrachtungsweise dar und dient der „reinen“ Beschaffung von Informationen. Auf der anderen Seite ist das „Business Information Warehouse“ zu erwähnen, welches die Funktionen der Geschäftsprozeßunterstützung (Lagerverwaltung, Logistik, Produktionsplanung etc.) bereitstellt. 9)

2.2 Management-Informationssysteme

Aufgrund der Tatsache, daß ein Data Warehouse in seiner klassischen Konzeption als Management-Informationssystem dient, ist es angebracht, diesen Begriff näher zu erläutern.

Ein Management-Informationssystem ist ein Unternehmensmodell, welches die Interdependenzen zwischen den betrieblichen Funktionsbereichen erfaßt und somit zur Unterstützung des Managements dient. ¹⁰⁾ Die Ziele eines Management-Informationssystems sind: ƒ Zeitgewinn bei der Entscheidungsfindung aufgrund einer optimierten MIS-Datenbasis.

ƒ Gewinn an Sicherheit bei der Entscheidungsfindung durch eine verbesserte Informationsversorgung.

In der Fachliteratur werden synonym Begriffe wie Führungsinformationssystem, Decision-Support-System, Chef-Informationssystem, Management-Unterstützungssystem oder Executive Information System verwendet, die sich aber allesamt grundsätzlich auf den gleichen Sachverhalt beziehen. Eventuelle inhaltliche Abweichungen der Begriffe sind in der fachlichen Diskussion zu

⁸⁾ Vgl. Martin, W.: Data Warehousing, Data Mining - OLAP, Bonn, 1998, S. 11-13.

⁹⁾ Vgl. SAP AG: System R/3 - Rechnungswesen, Walldorf, 1998, S. 1-25.

¹⁰⁾ Vgl. Serfling, K.: Controlling, Stuttgart, 1992, S. 230.

2 Grundlagen 5

beobachten, können aber wegen mangelnder Bedeutung für das dieser Untersuchung zugrundeliegende Thema vernachlässigt werden.

2.2.1 Anforderungen an ein MIS

Man unterscheidet zwischen konzeptionellen und funktionalen Anforderungen an ein Management-Informationssystem. Die konzeptionellen Anforderungen lassen sich wie folgt beschreiben: 11)

ƒ Ein MIS sollte einen möglichst hohen Deckungsgrad zwischen Informationsangebot und tatsächlichem Informationsbedarf erreichen. ƒ Reduktion der wachsenden Datenflut, um durch die Konzentration auf die „wesentlichen“ Daten Entscheidungsprozesse zu beschleunigen. ƒ Periodengerechte Aufbereitung der Informationen und deren Bereitstellung.

Die funktionalen Anforderungen wiederum berücksichtigen folgende Aspekte: ¹²⁾ ƒ Inhalt: Ein MIS benötigt sowohl interne Informationen (Finanzdaten, Marketing- und Umsatzdaten, Personaldaten, Produktionsdaten etc.) als auch externe Informationen (Marktanalysen, Börsenanalysen, die finanzielle Situation von Konkurrenten etc.).

ƒ Berichtsfunktion: Es müssen Möglichkeiten zur benutzerspezifischen Informationsaufarbeitung sowie der Erstellung von Sonderberichten durch Berichtsfunktionen auf der Basis von Prognose- und Simulationsrechnungen sowie die individuelle Darstellung der Inhalte der Datenbasis bereitstehen. Dadurch ist der Benutzer in der Lage, eigene Schwerpunkte bei der Berichtserstellung zu setzen. Ein MIS soll somit die Papierflut in Unternehmen reduzieren.

ƒ Informationsversorgung: Die Informationsversorgung muß aktuell und zyklisch aufgebaut sein. Hieraus ergibt sich der Vorteil, daß die einzelnen Benutzer immer auf dem gleichen Informationsstand sind und keine Mißverständnisse bei der Kommunikation zwischen den Benutzern auftreten können. Desweiteren können „neue“ Informationen aufgrund der bestehenden Datenbasis generiert werden, so daß bisher nicht berücksichtigte Aspekte untersucht werden können.

¹¹⁾ Vgl. Bullinger, H., Koll, P.: Chefinformationssysteme, in: Krallmann, H., Papke, J.,

Rieger, B.: Rechnergestützte Werkzeuge für das Management, Berlin, 1992, S. 62.

¹²⁾ Vgl. Kadir, T.: Nutzengewinnpotentiale von Führungsinformationssystemen, in: DV-

Management, Nr. 3, 1993, S. 146f, sowie Horváth, P.: Controlling, München, 1991, S. 353ff.

2 Grundlagen 6

ƒ Einfache Bedienung: Dieser Aspekt ist einer der wichtigsten, denn eine schnelle, flexible, unabhängige und einfache Handhabung muß aus ergonomischen Gründen gewährleistet sein. Dieser Forderung wird durch entsprechende MIS-Entwicklungswerkzeuge Rechnung getragen. ƒ Graphische Oberfläche: Sinnvoll ist eine graphische Oberfläche, die es ermöglicht, gleichzeitig Tabellen, die dazugehörigen Business-Graphiken sowie Graphiken anderer Formate generieren zu können. Insbesondere vermitteln „What-If“-Fragestellungen einen höheren Informationswert als nackte Zahlenkolonnen, d.h. bei Planungs- und Analyseaufgaben kann die graphische Darstellung einen wesentlich höheren Informationswert beinhalten. ƒ Ausnahmeberichtswesen (Exception Reporting): Hierbei werden

Abweichungen zwischen Soll- und Ist-Daten graphisch und/oder farbig dargestellt, so daß auf einen Blick komplexe Zustandsbeschreibungen dargestellt werden können. Dies kann unter Umständen automatisiert werden, um sofort prägnante Abweichungen feststellen und Ursachen ermitteln zu können (siehe auch Frühwarnsystem).

ƒ Frühwarnsystem: Unterstützt werden soll das frühzeitige Erkennen von Entwicklungstendenzen im Sinne eines Frühwarnsystems durch Zeitreihenbetrachtungen und -analysen. Nicht der Absolutwert des Indikators, sondern die ersichtliche Entwicklung und der Vergleich mit z.B. Branchen-und Konkurrenzzahlen ist wichtig. „Frühwarnsysteme haben die Aufgabe, mit zeitlichem Vorsprung auf Ereignisse hinzuweisen, die mit hoher Wahrscheinlichkeit die Unternehmensentwicklung nachhaltig beeinflussen werden. Dadurch soll dem Unternehmen ein ausreichender

Handlungsspielraum eröffnet werden, um sich mit entsprechenden Maßnahmen und Strategien auf diese Ereignisse vorzubereiten. Frühwarnsysteme ermöglichen zum Einen das Erkennen von Risiken und zum Anderen das Aufspüren von Chancen. Werden Risiken zu spät erkannt, werden unter dem Zeitdruck oft unzureichende oder falsche Abwehrmaßnahmen getroffen. Werden Chancen zu spät erkannt, besteht die Gefahr, daß die getroffenen Maßnahmen eher in Richtung Imitation statt Innovation gehen.“ 13)

¹³⁾ Hesslinger, H.: Die wachsende Bedeutung von Frühwarnsystemen, in: Management

Zeitschrift, Nr. 11, 1993, S. 32.

2 Grundlagen 7

ƒ Detaillierungsgrad (Drill-Down-Analysen): Bei dieser Funktion dienen die dargestellten Informationen als eine Art Auslöser, über den weitere Details und Hintergrundinformationen abgerufen werden können. Hierbei kann sich der Benutzer durch die verschiedenen Aggregationsstufen einer Dimension „entlangbewegen“. Unter einer Dimension versteht man in diesem Zusammenhang eine Informationsart (z.B. Produkte, Regionen, Zeit etc.) mit ihren Ausprägungen, die aggregiert (summiert) werden können. Die Gesamtheit der Dimensionen ergibt das im MIS betrachtete Unternehmensmodell.

ƒ Breites Anwendungs- und Unterstützungsspektrum: Es sollten mathematischstatistische Funktionen, Prognosen und Simulationen, Analyse- und Graphikfähigkeit, Kommunikation und Datenaustausch zur Verfügung stehen. ƒ Flexibilität des Systems: Fernerhin muß die Fähigkeit vorhanden sein, betriebsindividuelle Strukturen und Abläufe sowie deren Änderungen berücksichtigen zu können.

ƒ Nutzung in den verschiedenen Phasen des Managementprozesses: Das System muß in allen Phasen von Managementprozessen wie Planung, Entscheidung, Durchsetzung und Kontrolle nutzbar sein.

Im Verlaufe dieser Untersuchung wird sich zeigen, daß sich die vorstehend beschriebenen Anforderungen an ein Management-Informationssystem weitestgehend mit den an ein Data Warehouse gestellten und realisierten Forderungen decken.

2.3 Balanced Scorecard

Die Balanced Scorecard entwickelte sich aus der Tatsache heraus, daß im Zeitalter der stetig wachsenden Konkurrenz auf fast allen Märkten die Orientierung von Geschäftszielen an rein finanziellen Kennzahlen (Umsatzvolumen,

Deckungsbeiträge, Gewinn etc.), welche durch die operativen Systeme zur Verfügung gestellt werden, nicht mehr ausreichte. Folglich müssen diese Geschäftsziele um Kennzahlen erweitert werden, die zu einer Kontinuität oder, im noch günstigeren Fall, zu einer Verbesserung der Leistungserbringung führen. Denkbar sind hierbei Kennzahlen über Aktivitäten wie der Ausbildungsstand der Mitarbeiter, die Kundenzufriedenheit oder etwa die Optimierung der Workflows. Die Balanced Scorecard dient als Informationssystem auf den verschiedensten

2 Grundlagen 8

Ebenen eines Unternehmens. Sowohl das Management eines Unternehmens wird angesprochen, als auch der ausführende Mitarbeiter in der Leistungserstellung. Dem Management werden Kennzahlen bereitgestellt, die präzise Aussagen über den Erfolg des Unternehmens, Teile des Unternehmens oder künftiger Projekte möglich machen. Der ausführende Mitarbeiter hingegen erhält z.B. Informationen über die finanziellen Konsequenzen seiner Handlungen. Mit der Verfügbarkeit von unterschiedlichsten Kennzahlen (sowohl extern orientierte wie z.B. die Kundenzufriedenheit, als auch intern orientierte wie z.B. die Mitarbeiterzufriedenheit) versucht die Balanced Scorecard eine Art „Balance“ in der Informationsversorgung zu erreichen. 14)

Somit stellt die Balanced Scorecard eine neue Form von Informationssystem dar. Ihre Konzeption erinnert jedoch stark an den Grundgedanken eines Data Warehouse, nämlich die Bereitstellung unterschiedlichster Informationen.

2.4 Data Marts

Unter einem Data Mart versteht man eine bewußt redundante Haltung von Daten, die einen Ausschnitt aus dem Data Warehouse eines Gesamtunternehmens widerspiegeln. Somit handelt es sich eigentlich um ein „kleines“, vereinfachtes Data Warehouse. 15)

Der gewählte Ausschnitt entspricht einem sogenannten Subjektbereich, der gemeinhin Ausprägungen wie z.B. Abteilungen, Regionen, Produktgruppen usw. annimmt. Desweiteren ist der betrachtete Zeitraum in der Regel begrenzt, d.h. historische Analysen sind in Data Marts nur bedingt möglich. ¹⁶⁾ Die Gründe für die Entwicklung solcher Data Marts sind unterschiedlich. Auf der einen Seite besteht die Forderung nach verbesserter Performance bei der Durchführung von Abfragen, da infolge der einheitlichen Datenbasis in einem Data Warehouse schnell immense Datenmengen auftreten. Diese Datenmengen verlangsamen wiederum den Abfrageprozeß. 17)

¹⁴⁾ Vgl. Kaplan, R., Norton, D.: Balanced Scorecard, Stuttgart, 1997, S. 1-38.

¹⁵⁾ Vgl. Mucksch, H., Behme, W.: Das Data Warehouse-Konzept als Basis einer

unternehmensweiten Informationslogistik, in: Mucksch, H., Behme, W.: Das Data

Warehouse-Konzept, Wiesbaden, 1998, S. 45-46.

¹⁶⁾ Vgl. Schneppel, U.: Analyse multidimensionaler Datenstrukturen, in: Martin, W.: Data

Warehousing, Data Mining - OLAP, Bonn, 1998, S. 195-196.

¹⁷⁾ Vgl. Schinzer, H., Bange, C.: Werkzeuge zum Aufbau analytischer Informationssysteme, in:

Chamoni, P., Gluchowski, P.: Analytische Informationssysteme, Berlin, 1998, S. 45.

2 Grundlagen 9

Auf der anderen Seite steht die Kostenfrage. Mit der Einführung eines Data Warehouse sind natürlich nicht unerhebliche Kosten verbunden. Aufgrund der wirtschaftlichen Lage der meisten Unternehmen ist eine Investition dieser Größenordnung meist nicht möglich. Daher empfiehlt sich die schrittweise Einführung eines Data Warehouse durch die Erstellung einzelner Data Marts. ¹⁸⁾ Eine solche Vorgehensweise setzt selbstverständlich voraus, daß eine einheitliche Rahmenarchitektur für alle Data Marts verwendet wird. Die Abbildung 1 zeigt, wie ein solcher Aufbau realisiert werden könnte. 19)

Abbildung 1: Aufbau eines Data Warehouse unter Verwendung von Data Marts 20)

2.5 Online Analytical Processing

In den vergangenen Jahren wird immer öfter im Zusammenhang mit dem Data Warehouse auch der Begriff „Online Analytical Processing“ (kurz OLAP) genannt. Der Grund hierfür ist sehr einfach auszumachen. Um ein Data Warehouse sinnvoll einsetzen zu können, benötigt man zweckgerechte Analyseprozesse, die aus den großen Datenmengen Informationen extrahieren. Einen solchen Analyseprozeß stellt das OLAP dar. 21)

¹⁸⁾ Vgl. Wird die Suche nach den Schätzen zu teuer?, in: Computerwoche, Nr. 14, 1998,

S. 47-48.

¹⁹⁾ Vgl. Stotz, W., Müller, H.: Das skalierbare Data Warehouse, in: Chamoni, P., Gluchowski, P.:

Analytische Informationssysteme, Berlin, 1998, S. 206.

²⁰⁾ In Anlehnung an Stotz, W., Müller, H.: Das skalierbare Data Warehouse, in: Chamoni, P.,

Gluchowski, P.: Analytische Informationssysteme, Berlin, 1998, S. 207.

²¹⁾ Vgl. Hönig, T.: Desktop OLAP in Theorie und Praxis, in: Martin, W.: Data Warehousing,

Data Mining - OLAP, Bonn, 1998, S. 169.

2 Grundlagen 10

Im Gegensatz zu dem herkömmlichen Analyseprozeß von operativen Systemen, dem sogenannten Online Transaction Processing (kurz OLTP), ermöglicht das OLAP Analysen auf mehrdimensionaler Basis. Mit mehrdimensionalen Analysen sind dabei Abfragen auf Basis von historischen, konsolidierten Datenbeständen gemeint. Diese müssen nicht zwingenderweise aus dem Data Warehouse entnommen werden. Die operativen Systeme können ebenfalls als Datenlieferanten dienen. Dabei wird auf eine Anordnung betriebswirtschaftlicher Kennzahlen, entlang unterschiedlicher Dimensionen (wie z.B. Zeit, Region, Land, Kunde, Währung) abgezielt, wie sie vom Management benötigt werden. Versinnbildlicht ergeben diese quantitativen Größen eine Sammlung von Würfeln, wobei die einzelnen Dimensionen durch entsprechende Würfelkanten verkörpert werden (Abbildung 2 zeigt beispielhaft den Aufbau eines solchen Datenwürfels). Die Anzahl der Dimensionen, die für eine angemessene Beschreibung notwendig sind, variiert von Fall zu Fall. 22)

²²⁾ Vgl. Finkelstein, R.: Understanding the Need for On-Line Analytical Servers, Arbor Software,

White Paper, 1997, S. 9.

²³⁾ In Anlehnung an Gärtner, M.: Die Eignung relationaler und erweiterter relationaler

Datenmodelle für das Data Warehouse, in: Mucksch, H., Behme, W.: Das Data Warehouse-

Konzept, Wiesbaden, 1998, S. 202.

2 Grundlagen 11

Die Aufgabe des OLAP ist es somit, dem Benutzer geeignete Werkzeuge zur Verfügung zu stellen, um gezielte Schnitte (auch „Slicing and Dicing“ genannt) durch einen mehrdimensionalen Datenwürfel vornehmen zu können. Dadurch lassen sich die unterschiedlichsten Kombinationen der einzelnen Dimensionen und ihrer Kennzahlen realisieren, was wiederum zu maßgeschneiderten Informationen für die anwendende Person führt. ²⁴⁾ Um dieses Ziel zu verwirklichen formulierte Codd im Jahre 1993 zwölf Regeln zur Entwicklung von OLAP-Systemen: 25)

1. Mehrdimensionale konzeptionelle Sichten: Da betriebswirtschaftliche Kennzahlen wie Umsatz oder Gewinn nur im Zusammenhang mit ihren Bezugsgrößen (Kunde, Region, Produkt etc.) aussagekräftig sind, sind mehrdimensionale konzeptionelle Sichten für unternehmerische Analysen unabdinglich.

2. Transparenz: Gefordert wird eine homogene Benutzeroberfläche mit allen erforderlichen Funktionen für einen einfachen Analyseprozeß. Die zur Analyse verwendeten Datenquellen müssen immer nachvollziehbar sein. 3. Zugriffsmöglichkeit: Das OLAP-System sollte die Möglichkeit des Zugriffes auf die unterschiedlichsten Daten in den unterschiedlichsten Systemen haben. Hierfür müssen entsprechende Konvertierungsmöglichkeiten geschaffen werden.

4. Gleichbleibende Berichtsleistung: Bei zunehmendem Datenvolumen darf das System nicht an Performance in Bezug auf die Abfragen verlieren. 5. Client-Server-Architektur: OLAP-Systeme müssen in der Lage sein, in Client-Server-Architekturen agieren zu können.

6. Grundprinzipien der gleichgestellten Dimensionen: Die strukturelle Ausprägung der Dimensionen ist möglichst einheitlich zu gestalten. 7. Dynamische Speicherverwaltung dünn besetzter Matrizen: Um eine bestmögliche physikalische Speicherung der Daten zu erzielen ist es erforderlich, dünn besetzte Matrizen (verursacht durch schwache Überschneidungen der Dimensionen) durch das System effektiv zu verwalten.

²⁴⁾ Vgl. Chamoni, P., Gluchowski, P.: On-Line Analytical Processing (OLAP), in: Mucksch, H.,

Behme, W.: Das Data Warehouse-Konzept, Wiesbaden, 1998, S. 438-441.

²⁵⁾ Vgl. Codd, E., Codd, S., Salley, C.: Providing OLAP (On-Line Analytical Processing) to

User-Analysts: An IT Mandate. E. F. Codd & Associates, 1993.

2 Grundlagen 12

8. Mehrbenutzerfähigkeit: Analog zu den grundsätzlichen Anforderungen an klassische Datenbank-Management-Systeme ist es auch bei den OLAP-Systemen notwendig, mehreren Benutzern den Zugriff auf die gleiche Datenquelle zu ermöglichen. Damit einhergehend ist die Vergabe von Zugriffsrechten zu realisieren.

9. Unbeschränkte kreuzdimensionale Operationen: Für die Durchführung von Analysen über mehrere Dimensionen hinweg, ist die Verwaltung von dimensionsübergreifenden Operationen erforderlich.

10. Intuitive Datenmanipulation: Die Unterstützung des intuitiven Arbeitens durch ergonomisch gestaltete Benutzeroberflächen soll den Aufwand für Anwenderschulungen möglichst gering halten.

11. Flexibles Berichtswesen: Der Benutzer muß in der Lage sein, seine Berichte möglichst flexibel gestalten zu können. Dementsprechend benötigt er geeignete Tools, um die Daten anforderungsgerecht zusammenstellen zu können.

12. Unbegrenzte Dimensions- und Aggregationsstufen: Die Anzahl der Dimensionen und der möglichen Aggregationsstufen darf keiner Beschränkung unterliegen.

Diese OLAP-Regeln von Codd waren Ausgangspunkt für eine kontroverse Diskussion bezüglich ihrer Genauigkeit und ihrer technischen Anwendbarkeit. Aufbauend auf dieser Diskussion entwickelten Pendse und Creeth den Begriff der „Fast Analysis of Shared Multidimensional Information“ (kurz FASMI), um eine genauere Beschreibung von OLAP-Systemen zu geben. Ihre Forderungen lassen sich wie folgt beschreiben: 26)

1. Fast: Der Zugriff auf die Daten sollte mittels OLAP-Werkzeugen innerhalb von durchschnittlich 5 Sekunden möglich sein. Bei einfachen Abfragen sollte der Zugriff binnen einer Sekunde und selbst bei aufwendigen Abfragen innerhalb von 20 Sekunden ermöglicht werden.

2. Analysis: Das OLAP-System muß in der Lage sein, mit Geschäftslogistik und statistischen Analysen umgehen zu können, die für den Endbenutzer im Rahmen seiner Datenanalysen relevant sind (z.B. Zeitreihenanalysen, What-If-Szenarien).

²⁶⁾ Vgl. Pendse, N., Chreeth, R.: What is OLAP? An Analysis of what the increasingly misused

OLAP termis supposed to mean, URL: http://www.olapreport.com/fasmi.htm.

2 Grundlagen 13

3. Shared: Die OLAP-Datenbasis muß gleichzeitige Zugriffe von mehreren Benutzern zulassen. Dies kann bei Schreibvorgängen zu erheblichen Problemen führen, da durch die hoch verdichteten Daten Neuberechnungen eines Großteils von Datenbeständen notwendig werden können. Desweiteren müssen verschiedene Zugriffsrechte für einzelne Benutzer realisierbar sein. 4. Multidimensional: Mittels OLAP soll eine effiziente Speicherung der multidimensionalen Kennzahlen möglich sein und den Anwendern bei Bedarf direkt für die Analysen zur Verfügung stehen.

5. Information: Die gesamte Information, unabhängig von Herkunft oder Menge, soll jederzeit für Analysen bereitstehen.

Infolge der Heterogenität der auf dem Markt angebotenen OLAP-Produkte sind solche Beschreibungen jedoch zum Scheitern verurteilt. Jeder Anbieter wartet mit neuen Funktionalitäten und verbesserten Leistungsmerkmalen durch veränderte Technologien auf, wodurch wiederum eine einheitliche Darstellung des OLAP-Gedankens verhindert wird. Somit können die beschriebenen Anforderungen an ein OLAP-System nur als Anhaltspunkte dienen, sie besitzen keine Allgemeingültigkeit.

2.6 Data Mining

Grundsätzlich versteht man unter dem Begriff Data Mining (in der Fachliteratur auch unter der Bezeichnung „Knowledge Discovery Tools“ bekannt) das selbständige bzw. automatische Durchsuchen von großen Datenbeständen. Es gibt dabei zwei Ansätze zur Beschreibung des Data Mining-Prozesses. Der erste Ansatz geht davon aus, daß dem Data Mining-Werkzeug Hypothesen über den vermuteten Sachverhalt durch den Benutzer vorgegeben werden. Dieses versucht dann die Hypothesen anhand der vorhandenen Daten zu bestätigen oder bei negativem Ergebnis zu falsifizieren. Dieser Ansatz ist mittlerweile überholt, da in diesem Fall ein fundiertes Fachwissen des Benutzers von Nöten wäre, um von vornherein sinnvolle Hypothesen formulieren zu können. ²⁷⁾ Der zweite Ansatz unterstreicht die Forderung nach selbständiger Arbeitsweise des Data Mining-Systems. Hierbei werden die zugrundeliegenden Hypothesen durch das System automatisch generiert und ebenfalls durch dieses überprüft. Die Generierung erfolgt durch entsprechende Algorithmen, die sich der Struktur-,

²⁷⁾ Vgl. Boehrer, D.: Data Warehouse und Data Mining, Bern, 1997, S. 17-19.

2 Grundlagen 14

Muster- oder Trenderkennung bedienen. Angewandt werden hierbei bekannte Verfahren wie z.B. Neuronale Netze, Genetische Algorithmen oder Clusteranalysen. Die Überprüfung der erstellten Hypothesen erfolgt wiederum analog zum ersten Ansatz, nämlich durch empirische Prüfung unter der Verwendung von gegebenen Daten. 28)

Somit handelt es sich beim Data Mining, wie auch beim OLAP-System, um ein Analysewerkzeug, welches die Gewinnung von Informationen aus den Datenbeständen eines Data Warehouse unterstützen und vereinfachen soll.

²⁸⁾ Vgl. Kurz, A.: Neue Wege der Datenanalyse mittels neuartigen Knowledge Discovery- und

Data Mining Methoden, in: Martin, W.: Data Warehousing, Data Mining - OLAP, Bonn,

1998, S. 255-258.