Abbildungsverzeichnis
Tabellenverzeichnis
Abkürzungsverzeichnis
1 Einleitung
1.1 Kurzüberblick
1.2 Aufbau der Arbeit
2 Business Intelligence
2.1 Ein kurzer Überblick
2.1.1 Semantische Sichtweise
2.1.2 Pragmatische Sichtweise
2.1.3 Verständnis der Business Intelligence
2.1.4 Entwicklung der Business Intelligence
2.2 Komponenten der Business Intelligence
2.2.1 Ein aktuelles BI Umfeld im Überblick
2.2.2 Datenherkunft
2.2.3 Datenbereitstellung
2.2.4 Informationsgenerierung
2.2.5 Informationszugriff
2.2.6 Metadatenmanagement
2.3 Bedeutung der BI für die betriebswirtschaftliche Praxis
3 Das Data Warehouse
3.1 Konzept des Data Warehouse
3.2 Referenzarchitektur eines Data Warehouse
3.2.1 Aufbau der Architektur
3.2.2 Datenquellen
3.2.3 Metadatenmanager und Repositorium
3.2.4 Arbeitsbereich
3.2.5 Basisdatenbank
3.2.6 Data Warehouse
3.2.7 Data Warehouse Manager
3.3 OLAP im Data Warehousing
3.3.1 OLAP Definition
3.3.2 Multidimensionale Datenmodelle
3.3.3 Fallbeispiel: Cube-Erstellung
3.3.4 Fallbeispiel: Arbeitsprozesse mit Cubes
3.3.4.1 Die Standardprozeduren
3.3.4.2 Pivoting
3.3.4.3 Slicing
3.3.4.4 Dicing eines Cubes
3.3.4.5 Drill-Down & Roll-Up
3.4 OLAP im relationalen Umfeld
3.4.1 Datenmodelle von OLAP Systemen
4 Reportingerfordernisse im Unternehmen
4.1 Bedeutung des Reporting
4.2 Anforderungen an das Reporting
4.3 Umsetzungsstrategien
4.3.1 Vorüberlegungen
4.4 Excellence im Reporting
4.4.1 Grundlegende Problemstellung
4.4.2 Das „magische Viereck“ der Management-Reporting Excellence
4.4.3 Die zwölf Erfolgsfaktoren
4.4.3.1 Strategie und Steuerungsverständnis fest im Blick halten
4.4.3.2 Nutzen für das Management schaffen
4.4.3.3 Effizienz im Reporting
4.4.3.4 Interaktion zwischen Controlling und Management stärken
5 Open Source BI mit der Pentaho BI Suite
5.1 Open Source Business Intelligence
5.2 Aufbau der Pentaho BI Suite
5.3 Installation des Pentaho Testsystems
5.4 Funktionen im BI Portal
5.5 Datenbereitstellung / ETL Prozess
5.6 Mondrian
6 Schlussbetrachtung
6.1 BI und DW im Unternehmen
6.2 Kapitelbezogenes Resümee
6.3 Schwierigkeiten bei der Umsetzung des Fallbeispiels
6.4 Ausblick
GLOSSAR
Anhang A
Anhang B
Literaturverzeichnis
Abbildung 1: Unterschiedliche Verständnisse der BI
Abbildung 2: Verständnisse der Business Intelligence
Abbildung 3: Entwicklungsumfeld der Business Intelligence
Abbildung 4: Komponenten der Business Intelligence
Abbildung 5: Phasen der Transformation
Abbildung 6: Referenzarchitektur eines Data Warehouse
Abbildung 7: Multidimensionaler Cube
Abbildung 8: Aufbereitete Beispieltabellen
Abbildung 9: Cube-Entwurf mit 3 Dimensionen
Abbildung 10: Aufbereiteter Cube
Abbildung 11: Pivoting eines Cubes
Abbildung 12: Slicing eines Cubes
Abbildung 13: Dicing eines Cubes
Abbildung 14: Transaktionales Datenmodell
Abbildung 15: Datenmodell "Flache Struktur"
Abbildung 16: Datenmodell "Star Schema"
Abbildung 17: Datenmodell "Snowflake Schema"
Abbildung 18: Objektiver und subjektiver Informationsbedarf
Abbildung 19: Entstehungsmöglichkeiten von Störungen im Berichtswesen
Abbildung 20: Arten von Berichten
Abbildung 21: Berichtsarten in der Praxis
Abbildung 22: Erstellungsart der Managementreporte nach Bereichen
Abbildung 23: Perspektiven der Transparenz
Abbildung 24: Das "magische Viereck" der Management-Reporting Excellence
Abbildung 25: System der Reporting Pyramiden
Abbildung 26: Aufbau der Pentaho BI Suite
Abbildung 27: Einbindung des mySQL JDBC Treibers
Abbildung 28: XAMPP Control Panel
Abbildung 29: Startseite der Pentaho-Plattform
Abbildung 30: Portalseite der Pentaho BI-Suite
Abbildung 31: Pentaho Data Integration
Abbildung 32: OLAP-Beispiel Grundansicht
Abbildung 33: OLAP-Beispiel Pivoting
Abbildung 34: OLAP-Beispiel: Slicing
Abbildung 35: OLAP-Beispiel Dicing
Abbildung 36: OLAP-Beispiel Drill-Down und Roll-Up
Abbildung 37: OLAP-Beispiel Zusatzwerkzeuge
Tabelle 1: Vergleich der Eigenschaften von OLTP und OLAP
Tabelle 2: Vor- und Nachteile des Standardberichts
Tabelle 3: Vor- und Nachteile des Abweichungsberichts
Tabelle 4: Vor- und Nachteile des Bedarfsberichts
Abbildung in dieser Leseprobe nicht enthalten
Im Zeitalter der Informationstechnik hat sich die Masse an Daten und Informationen, denen wir tagtäglich begegnen oder die uns verfügbar gemacht werden, immense Ausmaße angenommen. Die Quantität dieser Daten – insbesondere im Business Umfeld – kennt kaum Grenzen und immer wieder eröffnen sich neue Datenquellen aus denen wichtige Informationen gewonnen werden können. Doch wie sieht es mit der Qualität dieser Daten aus?
Betrachtet man das Controlling eines multinationalen Unternehmens, erkennt man schnell, dass hier Datenströme aus den unterschiedlichsten Quellen mit den unterschiedlichsten Strukturen, Volumina und Qualitäten auflaufen. Diese Daten manuell zu strukturieren, zu vereinheitlichen, zu transformieren, zu analysieren, zu speichern und schließlich zu kommunizieren, ist eine Aufgabe, die einfach nicht mehr realisierbar ist. Selbst moderne Tabellenkalkulationen oder operative Datenbanksysteme stoßen so schnell an ihre Grenzen.
Es wird ein Umfeld bzw. System benötigt, welches diesen Ansprüchen gerecht wird. Ein Business Intelligence Umfeld mit einem zentralen Data Warehouse kann vielen dieser Anforderungen mehr als gerecht werden. Die neu aufgestellte Datenbasis steht dem gesamten Unternehmen zur Verfügung und führt so zu einer Vereinheitlichung der Datenstrukturen sowie deren Semantik. Eine funktionierende Business Intelligence erlaubt dem Unternehmen in kürzester Zeit, hochaktuelle Informationen und dynamische Berichte zu generieren, um flexibel am Markt agieren zu können. Komplexe Data Mining Anwendungen finden Muster in den Daten, um Geschäftsprozesse zu optimieren, die verborgenen Wünsche des Kunden aufzudecken oder völlig neue Geschäftsmodelle zu entwickeln.
Ziel dieser Arbeit ist es, einen fundierten Überblick über die Bedeutung der Business Intelligence, des Data Warehouse sowie dem Reporting in diesem Umfeld zu geben und am Ende mögliche Umsetzungsmöglichkeiten zu demonstrieren.
Im zweiten Kapitel wird der Frage nachgegangen, was man überhaupt unter dem Begriff „Business Intelligence“ versteht und ob es eine Möglichkeit gibt, diesen genau zu definieren. Hierfür wird ein kurzer Überblick über die geschichtliche Entwicklung der Informationssysteme innerhalb der Unternehmen eingeschoben, der schließlich in einem Referenzmodell mündet. Dieses Modell zeigt, wie aktuelle BI-Landschaften aussehen könnten. Hier wird versucht zu erklären, wie ein Business Intelligence System funktioniert und welche Möglichkeiten man hat, dieses effektiv zu nutzen.
Das Konzept und die Funktionsweise eines Data Warehouse hat, aufbauend auf dem zweiten Kapitel, das dritte Kapitel zum Inhalt. Es versucht das allgemein anerkannte Data Warehouse Konzept und die darauf aufbauende Referenzarchitektur darzustellen und die Prozesse innerhalb des Data Warehouse entsprechend zu erläutern. Hierfür wird aufgeführt, welche Anforderungen an die Systeme zu stellen sind um dem analytischen Gedanken zu folgen. Das Kapitel wird mit einer Einführung in die multidimensionalen Datenmodelle und deren Abbildung im relationalen Umfeld abgeschlossen.
Kapitel 4 stellt die Erfordernisse eines Reportings dar und versucht die Thematiken Business Intelligence und Data Warehouse in dieses Thema zu integrieren. Es soll aufzeigen, wie sich die gewonnenen Erkenntnisse der vorherigen Kapitel schließlich auch im Bereich des Unternehmensreportings widerspiegeln. Hierzu orientiert sich das Kapitel an der Management Reporting Excellence, der Idealform des Management Reportings.
Abschließend soll das fünfte Kapitel aufzeigen, wie man mit Open Source Produkten ein Business Intelligence Umfeld aufbauen und administrieren kann. Es stellte sich heraus, dass es hier zu einigen Problemen kommen kann, die ebenfalls im Kapitel erläutert werden.
Die Arbeit endet mit einer Schlussbetrachtung, die abschließend aufzeigen soll, ob die Problemstellungen der einzelnen Kapitel gelöst worden sind und welche Fragen eventuell nicht beantwortet werden konnten.
In vielen Lehrbüchern, Internetinhalten und Aufsätzen wird der Begriff „Business Intelligence“ differenziert dargestellt. Es ist daher sinnvoll, zunächst einen kurzen Ausflug in die Geschichte und Entwicklung der BI zu unternehmen, um die Verständlichkeit der nachfolgenden Kapitel zu verbessern. Interessanterweise wird das Wort „Intelligence“ häufig nur rein wortwörtlich – also als Intelligenz – interpretiert. Innerhalb der BI spielt diese sicherlich auch eine wichtige Rolle, aber die weiteren Übersetzungen des Begriffs wie z.B. Aufklärung, Einsicht oder Information beschreiben die Aufgaben und Wirkungsweisen der BI wesentlich passender.[1] Dies wird unter anderem auch in den drei Prozessphasen Bereitstellung (von Information), Entdeckung (Aufklärung) und Kommunikation deutlich, in die man die BI grob einteilen kann.[2] Würde man den Begriff BI nun also rein nach dessen semantischer Sichtweise definieren, so käme man zu dem Ergebnis, dass es sich bei der BI um einen Prozess oder eine Institution handelt, die im wirtschaftlichen Umfeld aufklärt, informiert und neue Einsichten vermittelt.
Betrachtet man nun – neben der sehr breit gespannten semantischen Sichtweise – die stark differenzierten Definitionen des Begriffs, die sich im Laufe der Zeit sowohl in der Forschung als auch in der Praxis entwickelten, so wird deutlich, warum auch das Verständnis von BI in der Praxis einen sehr großen Umfang aufweist. Ein Grund hierfür ist sicherlich die recht lange und dynamische Entwicklung der Vorläufersysteme, welche bereits seit den 60er Jahren existierten und schließlich in die BI mündeten. Doch auch das Unternehmensumfeld trug entschieden dazu bei, das Verständnis der Allgemeinheit hinsichtlich der BI weiter aufquellen zu lassen. Je nach Produktspektrum wurde der Begriff der BI von jedem Unternehmen anders ausgelegt. Infolge dessen ergaben sich viele differenzierte Auffassungen, was nun unter BI zu verstehen ist. Abbildung 1 stellt in diesem Zusammenhang die unterschiedlichen Assoziationen auf, die sich daraus ergaben und von Mertens in einem Arbeitspapier zum Thema BI publiziert worden sind.[3]
Abbildung 1 : Unterschiedliche Verständnisse der BI
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Darstellung
Es fällt auf, dass sich die Sichtweisen an unterschiedlichen Objekten orientieren. Zum einen sind dies die Systeme und Anwendungen, die mit der BI zusammenhängen und zum anderen die Prozesse, die notwendig sind um ein BI-Umfeld zu betreiben.
In der Literatur werden, unter anderem wegen der im Kapitel 2.1.2 besprochenen Thematik, verschiedene Abgrenzungen vorgenommen, welche die BI in einem Verständnisrahmen aufgliedern. Gluchowski stellt die Zusammenhänge sehr anschaulich in einer Matrix dar, deren Abszisse angibt, ob das Objekt der BI eher technik- oder anwendungsorientiert ist, sowie deren Ordinate, welche differenziert, ob es sich um eine Datenbereitstellung oder eine Datenauswertung handelt. In diesem aufgespannten Raum ordnet er nun die einzelnen Objekte der BI ein und definiert mit den entstandenen Feldern die unterschiedlichen Verständnisse der BI.[4] Im Bereich des „Engen BI-Verständnisses“ sieht er nur die Hauptmodule, die ein BI-Umfeld ausmachen wie die OLAP-Funktionalität und die Informationssysteme MIS / EIS. Darauf aufbauend folgen die analyseorientierten Verständnisse, die sich eher im datenbereitstellenden Bereich der Matrix aufhalten, aber sowohl technikorientiert sind – wie z.B. die Mustererkennung innerhalb der Daten – wie auch die Komponenten, die eher auf die Anwendungsebene fokussiert sind. Dazu zählen einerseits die Kennzahlensysteme wie z.B. die Balanced Scorecard und andererseits auch Planungs- und Konsolidierungssysteme. Der Domäne des „Weiten BI-Verständnisses“ werden überwiegend Objekte zugeordnet, die für die Datenbereitstellung zuständig sind. Ein klarer Vertreter dieses Bereichs, dem auch in dieser Arbeit ein größeres Augenmerk gewidmet wird, ist das Data Warehouse. In Anlehnung an Gluchowski stellt Abbildung 2 das aufgespannte Ordnungsfeld der einzelnen Verständnisse der BI dar.
Abbildung 2 : Verständnisse der Business Intelligence
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Darstellung in Anlehnung an Gluchowski (2001), S. 7.
Die einzelnen Komponenten werden an späterer Stelle dieser Arbeit noch näher erläutert. Abschließend zu erwähnen ist, dass die breite Auslegung des Begriffs und die vielen differenzierten Definitionen die BI zwar allumfassend beschreiben, jedoch die Gefahr besteht, dass der Begriff weiter verwässert wird und nur noch als ein Schlagwort zu gebrauchen ist.[5]
Der Bedarf nach einer adressatengerechten Lieferung von Informationen besteht nicht erst seit dem Aufkommen von BI-Produkten. Schon in den 60er Jahren versuchte man die Ansätze der Organisationslehre, der Informatik und der Führungslehre miteinander zu kombinieren.[6] Daraus entwickelte sich schließlich das Management Information System (MIS) – sozusagen der Vorläufer der heutigen BI. Schon damals sollte aus den Daten, welche die proprietären Systeme lieferten, Informationen gewonnen werden, um das Management bei deren Entscheidungsfindung zu unterstützen.
Kennzeichnend war damals jedoch, dass man auf die objektiven und subjektiven Informationsbedürfnisse der Manager kaum eingehen konnte. Die zu der Zeit vorherrschenden sehr starren Systeme ließen derartige Individualisierungen einfach nicht zu. Ebenfalls festzuhalten ist, dass die Datenextraktion direkt auf die operativen Systemen aufsetzte, was aber aufgrund fehlender Alternativen und den geringeren Datenmengen vorerst nicht weiter berücksichtigt wurde.[7] Eine ebenfalls zu erwähnende Komponente waren die damaligen Kosten für derartige Großrechnerarchitekturen. Informationssysteme dieser Art blieben daher nur den großen Unternehmen vorbehalten. In den nachfolgenden Jahren wurden weitere Anstrengungen unternommen, das MIS um einen modellorientierten Ansatz zu erweitern.
Diese Entwicklung mündete Ende der 60er / Anfang der 70er Jahre schließlich in die ersten Decision Support Systems (DSS) bzw. Management Decision Systems (MDS), welche vor allem durch Peter Keen und Charles Stabell vorangetrieben wurden. Die Unterschiede zum MIS waren unverkennbar, da es die Architektur der DSS erlaubte, auf die vielfältigen Methoden und Modelle Rückgriff zu nehmen, die in dem System implementiert waren. Vom Prinzip her waren es zwar immer noch Management Information Systems, doch weil der Begriff durch die schlechten Erfahrungen mit vielen negativen Assoziationen behaftet war, entschied man sich für einen Namenswechsel und damit zu den DSS.[8] Erstmals wurden Erfahrungswerte in Rechnern abgelegt, die anschließend in die Informationsgenerierung zur Analyse, Prognose oder Simulation mit einfließen konnten. Man wandte sich von den datengetriebenen Systemen ab und eröffnete sich neue Sichtweisen durch die methodengetriebene Herangehensweise.[9]
Doch im Laufe der 70er Jahre stellte sich heraus, dass die bisherigen Herangehensweisen, ein Informationssystem für das obere Management zu schaffen, erhebliche Akzeptanz- und Verständnisprobleme zur Folge hatten.[10] Dafür steht stellvertretend eine Aussage von einem Mitarbeiter im Vorstandsbüro eines großen Chemiekonzerns dieser Zeit: „The President bought a home computer six months ago. He's been happily working on his own investment portfolio with it and told us last week that he was sure that he ought to be able to use computers directly in the management of the corporation. We need a plan to make this happen." Die verschiedenen Umstände führten schließlich dazu, dass sich Rockart und Treacy näher mit diesen Problemtiken auseinandersetzten und schließlich eine weitere Form der Informationssysteme entwickelten, welche speziell für die obere Führungsebene ausgelegt war und durch niedrigere Akzeptanzbarrieren auch schnell in die Unternehmensumfelder Einzug halten sollte. Dieses sogenannte Executive Information System (EIS) sollte interessanterweise eine von vielen Forderungen des Managements befriedigen, die jedoch auch heute noch aktuell ist.
Rockart und Treacy fanden heraus, dass das Management trotz der implementierten MIS bzw. DSS jener Zeit sehr darüber klagte, dass es noch immer keine ausreichende Transparenz über die ablaufenden Prozesse der Unternehmung habe. Sie forderten einen bedarfsgerechten, breiteren Zugriff auf die Datengrundlagen sowie eine Ausweitung des Detaillierungsgrades. Außerdem bestand eine Nachfrage nach einer einfachen Möglichkeit, die Analyse auch selber durchführen und dynamisieren zu können.[11]
Es bleibt festzuhalten, dass die bisher angesprochenen Systeme nicht parallel existierten – vielmehr gingen sie nach und nach ineinander über und die Entwicklungen innerhalb des Bereichs eines Systems wurden auch zu Treibern der nachfolgenden Systeme. So finden sich Modelle der Optimierung, Simulation, Statistik und auch der künstlichen Intelligenz heutzutage nicht nur in einzelnen Bereichen der BI, sondern verstehen sich vielmehr als Werkzeuge der gesamten BI-Umgebung.
In den 90er Jahren wurden die Problematiken des Online Transaction Processing (OLTP) auf der einen Seite und jene des Online Analytical Processing (OLAP) bei simultaner Nutzung immer offenbarer. Einige markante Unterschiede zwischen den beiden Systemen veranschaulicht Tabelle 1. Für kleinere Analysen innerhalb eines kurzen Zeitraums waren die operativen Systeme mit ihrer normalisierten relationalen Datenbankstruktur ausreichend. Die Datenmengen waren noch nicht zu groß und für längere Extraktionsprozesse nutzte man Leerzeiten der Systemarchitektur, um die Performance im operativen Bereich nicht zu belasten. Doch je größer die Datenmengen wurden und je stärker die Fragmentierung – durch das relationale Datenmodell bedingt – zunahm, desto länger wurde auch die Laufzeit der Abfragen und desto rasanter stieg die Auslastung der operativen Systeme an. Dieses grundlegende Problem des Zugriffs auf die operativen Datenbestände wurde mit der Entwicklung des Data Warehouse schließlich gelöst. In den frühen 90er Jahren stellten W. Inmon und E.F. Codd fest, dass OLTP und OLAP in ein und demselben Datenbankumfeld nicht gleichzeitig existieren können.[12] Es wurde schließlich der Weg für die Entwicklung und Einführung vom Data Warehouse geebnet.
Tabelle 1 : Vergleich der Eigenschaften von OLTP und OLAP
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Darstellung
Einige Jahre vor den Veröffentlichungen von Inmon und Codd beschäftigte sich auch Howard Dresner – Marktforscher bei der Gartner Group – mit den Problematiken der Informationsversorgung und prägte dabei den Begriff „Business Intelligence“ nachhaltig. Erstmalig im Jahre 1989 verwendet, stand der Begriff einige Jahre später nicht mehr für ein Nischengeschäft, sondern für einen allgemein gültigen Bereich der Unternehmenssteuerung und Forschung.[13]
In etwa zur gleichen Zeit, zu der sich die BI in der Unternehmenslandschaft durchsetzte, fanden auch immer mehr analytische Anwendungen Einzug in die einzelnen Bereiche der Informationssysteme. Gerade die vorgelagerten Datenbestände der Data Warehouse Architekturen ließen es zu, nach Mustern innerhalb der Datenbestände zu suchen. Der Begriff „Data Mining“ gewann ebenfalls zunehmend an Popularität und fügte sich nach und nach in die Landschaft der BI ein. Aktuell begegnen einem die Begriffe Corporate Performance Management, Process Performance Management sowie Business Activity Monitoring immer häufiger und hier bleibt abzuwarten, wie sich diese Felder auf das Verständnis der BI auswirken werden. Betrachtet man nun die historische Entwicklung rund um das Thema Business Intelligence, ist ersichtlich, dass auf der einen Seite die Weiterentwicklung eher datengetrieben fortgeführt wurde. Die Struktur, die Herkunft, die Haltung, die Speicherung, die Verfügbarkeit der Daten, etc. waren Inhalte der Problemstellungen, welche die Weiterentwicklung deutlich vorantrieben. Auf der anderen Seite standen eher die methodengetriebenen Entwicklungen, deren Inhalte eher Fragestellungen waren, wie mit den Daten verfahren werden soll. Abbildung 3 stellt die nun fast 50jährige Entwicklungsgeschichte der Business Intelligence noch einmal an einem Zeitstrahl und differenziert nach dem jeweiligen Entwicklungshintergrund dar.
Abbildung 3 : Entwicklungsumfeld der Business Intelligence
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Darstellung
Definiert man nun den Begriff der BI hinsichtlich dessen semantischer wie auch pragmatischer Bedeutung, so zeichnet sich ein erstes grobes Bild des Begriffs ab. Dieses Bild wird aussagekräftiger, wenn man nun noch die einzelnen Komponenten hinzufügt, welche die Struktur der BI ausmachen. In Abbildung 4 sind die häufig vorkommenden Komponenten eines BI Umfelds schematisch dargestellt.
Abbildung 4 : Komponenten der Business Intelligence
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Darstellung
Die roten Rechtecke bezeichnen die einzelnen Bereiche einer BI-Referenzumgebung in Bezug auf die Daten und den daraus gewonnenen Informationen. Nachfolgend werden diese Bereiche wie auch die enthaltenen Objekte charakterisiert sowie deren Funktionen kurz erläutert, da diese für den Reportingprozess ebenfalls eine nicht zu vernachlässigende Bedeutung haben.
In einem idealen Umfeld für ein BI System stehen für die Generierung der Daten unterschiedliche Vorsysteme zur Verfügung.[14] Auf der einen Seite ein klarer Vorteil, denn je mehr Daten zusammengetragen können, desto weitreichender bzw. detaillierter könnten die Zusammenhänge sein, die aus dem entwickelten Informationsstamm generiert werden. Betrachtet man zunächst die operativen Vorsysteme, welche meist die aktuellen internen Daten für das Data Warehouse bereitstellen, wird klar, dass es schon dort zu Problemen kommen kann. Wenn Daten z.B. aus dem ERP-System des Unternehmens extrahiert werden sollen, um für weitere Transformations- und Speicherprozesse zur Verfügung zu stehen, muss ein Prozess in Gang gesetzt werden, welcher die Daten dieser Systeme über Schnittstellen oder die zu Grunde liegenden Datenbanken auslesen kann.
Dies muss nun nicht nur vom ERP System aus möglich sein, sondern sämtliche Subsysteme umfassen, die wirtschaftlich relevante Daten vorhalten. Teilweise werden im Bereich SCM oder CRM andere Module eingesetzt oder gar mit dem ERP System nicht kompatible Anwendungen. Diese Daten sollen natürlich auch in einem Data Warehouse – zusammen mit den Daten des ERP Systems – allen Benutzern zur Verfügung stehen. Es wird deutlich, dass es hier zu erheblichen Problemen kommen kann, wenn die Datendefinitionen und Datenstrukturen zwischen den Systemen nicht übereinstimmen.[15]
Noch prägnanter kommt diese Problematik zum Ausdruck, wenn man bedenkt, dass im Idealfall alle Informationsquellen für eine Datengenerierung zur Verfügung stehen sollten und auch genutzt werden. Hierzu zählen die Altsysteme (Legacy Systems) der Unternehmung, die noch Daten über bestimmte Produktentwicklungen, Kundenbeziehungen oder andere substanzielle Informationen enthalten. Hierbei ist festzustellen, dass die Datenbestände von älteren bzw. gewachsenen Systemen kaum bis gar nicht dokumentiert sind und so den Prozess der Extraktion merklich erschweren.[16] Festzuhalten bleiben auch die Massen an Flat Files – also einzelnen Dateien – die auf den diversen Rechnern der Mitarbeiter oder Abteilungen liegen und ein wesentlicher Bestandteil des gebündelten Unternehmenswissens sind. Ein Beispiel sind Auswertungen als Excel Dateien, statistische Daten als csv-Dateien, Listen als txt- oder Word Dateien, usw. Durch strategische Partnerschaften, Joint-Ventures oder Beteiligungen hat man eventuell Zugriff auf die Datenbestände der Partner, dessen Informationsbasis auch eine wichtige Rolle bei Entscheidungen spielen kann und somit auch mit in das Data Warehouse aufgenommen werden sollte. Nicht zuletzt sei an dieser Stelle auf die Angebotsvielfalt an Informationen verwiesen, die das Web 2.0 zur Verfügung stellt und keinesfalls missachtet oder unzureichend behandelt werden sollte.
Abschließend kann man sagen, dass für die Beschaffung der Daten unterschiedlichste Quellen zur Verfügung stehen. Wie bereits oben genannt, ist dies ein großer Vorteil, den das Unternehmen für sich nutzen sollte. Doch stehen die Daten meist unstrukturiert, redundant, inkonsistent und in verschiedenen Formaten zur Verfügung und eine 1:1 Übernahme dieser Daten in das Data Warehouse würde fatale Folgen haben. Die Bereitstellung dieser Daten stellt daher eine Kernfunktion des BI Umfeldes dar und legt die Grundsteine für das Qualitätsniveau der Informationen und Auswertungen.
Damit die Daten im Core Data Warehouse bzw. im Operational Data Store abgelegt werden können, bedarf es eines Prozesses, der die Daten aus den Vorsystemen extrahiert, aufbereitet, kontrolliert, evtl. anreichert und schließlich in das Warehouse schreibt. Dieser Transformationsprozess wird in der Praxis ETL-Prozess (Extraction, Transformation, Loading) genannt.[17] Hauptaufgabe ist es, die unterschiedlichen operativen Informationen so umzuwandeln und bereitzustellen, dass sie den betriebswirtschaftlichen Anforderungen genügen. Dieser Prozess lässt sich in die vier Unterprozesse Filterung, Harmonisierung, Aggregation und Anreicherung unterteilen.
Die Filterung ist nicht nur der reine Extraktionsprozess, sondern auch die erste Stufe für die Transformation der Daten. Im Data Warehouse werden bestimmte Bereiche für die Rohextraktion reserviert (staging areas), in denen der Filterungsprozess die operativen Daten aus den Vorsystemen durchführt.[18] Gleichzeitig werden diese Daten auf syntaktische und semantische Fehler hin überprüft. Dieser Prozess läuft zum größten Teil automatisiert ab, da es sich um eindeutige oder sich immer wiederholende Fehler handelt, die man später in den Extraktionsprozessen berücksichtigt. Nur bei gravierenden oder unbekannten Fehlern muss manuell in den Prozess eingegriffen werden. Nach diesem Prozess sind die Daten jedoch immer noch nicht für die verschiedenen betriebswirtschaftlichen Einsatzgebiete geeignet.
Erst der Harmonisierungsprozess macht aus den Daten brauchbare Objekte, mit denen die einzelnen Systeme arbeiten können. Da der Prozess ebenfalls aktiv in die Daten eingreift und – falls notwendig – abändert oder umstrukturiert, wird er auch als zweite Transformationsschicht bezeichnet. Harmonisierungen werden dann notwendig, wenn die internen Daten schon untereinander nicht verträglich sind und wenn die externen Daten an die internen angepasst werden. Hierbei treten Disharmonien vor allem im datenbanktechnischen Bereich auf z.B. bei unterschiedlichen Primärschlüsseln, differenzierten Datenkodierungen, Synonymen oder Homonymen. Meist kann dieser Teil der Harmonisierung (auch syntaktische Harmonisierung genannt) ohne betriebswirtschaftliches Know-How durchgeführt und automatisiert werden.[19]
Ganz im Gegensatz zu der betriebswirtschaftlichen Harmonisierung. Hierbei wird während des Transformationsprozesses sichergestellt, dass die einzelnen Daten auch tatsächlich genau das meinen, was diese darstellen sollen.[20] Beispielhaft sei hier der Cashflow zu nennen, der womöglich in den verschiedenen Unternehmensbereichen anders berechnet und ausgewiesen wird. Erst die betriebswirtschaftliche Harmonisierung macht diese Kennziffer somit vergleichbar und sorgt dafür, dass diese von den Informationsbedarfsanmeldern richtig interpretiert werden kann. Weiterhin wird bei der betriebswirtschaftlichen Harmonisierung festgelegt, in welcher Granularität die Daten weiterverarbeitet werden sollen und ob somit eine Erfordernis besteht, sämtliche Einzelbelege zu erfassen oder schon eine gewisse Voraggregation vorzunehmen. Erst nach diesen ersten beiden Transformationsstufen würden die Daten den Anforderungen genügen, welche die betriebswirtschaftliche Praxis an sie stellt. Dieser Datenbestand bildet auch die höchste Detailstufe oder die geringste Granularität, wenn in den weiterführenden Anwendungen z.B. die Drill-down Funktionalität genutzt werden sollte.
In der dritten Transformationsschicht können die bereinigten Daten nun nach speziellen Dimensionen aggregiert, z.B. nach Kunde, Produkt o.ä., um so nach und nach zu einer anwendungsorientierten Datenhaltung zu gelangen. Die letzte Transformationsschicht ist schließlich die Anreicherungsschicht. Hier werden die Datenbestände aus der zweiten und dritten Ebene dazu genutzt, um betriebswirtschaftliche Kennzahlen oder andere Größen zu ermitteln und diese in die Daten zu integrieren.[21] Dies hat zum Vorteil, dass z.B. der Cashflow einmalig pro Monat mit den konsistenten Daten der zweiten Ebene berechnet wird und so über Jahre hinweg vergleichbar ist, wenn nichts an den Transformationsregeln verändert wird. Gerade im Bereich des Berichtswesens und der Reporting Excellence ist dies ein Faktor, dem man eine hohe Beachtung zukommen lassen sollte.
Abbildung 5 : Phasen der Transformation
Abbildung in dieser Leseprobe nicht enthalten
Quelle: Eigene Darstellung in Anlehnung an Kemper / Mehanna / Unger (2006), S.33.
Die einzelnen Phasen sowie der mögliche Verlauf werden in Abbildung 5 noch einmal grafisch dargestellt. Nachdem der Transformationsprozess durchgeführt wurde, werden die Daten schließlich in die entsprechenden Bereiche des CDW übertragen. Aus diesem Hauptdatenbestand können nun auch differenzierte Abbilder generiert werden, die z.B. nur die Daten für eine bestimmte Abteilung oder einen bestimmten Unternehmensteil vorhalten. Diese Abbilder des CDW werden auch als Data Marts bezeichnet.[22] Dies sind im Prinzip vollständige Data Warehouses, nur mit einem geringeren Datenbestand. Abbildung 4 stellt das Prinzip einer abhängigen Data Mart Schicht dar, da die Data Marts vom CDW gespeist werden. Doch ist auch der umgekehrte Fall möglich, in dem mehrere Data Marts zu einem CDW zusammengefasst werden und somit eine unabhängige Data Mart Schicht repräsentieren.[23]
Der gesamte Transformationsprozess ist ein wesentliches Qualitätskriterium für die Güte des gesamten Datenbestandes im Data Warehouse, den Data Marts wie auch in allen auf dem CDW aufsetzenden Applikationen. Daher scheint es angebracht, diesen Prozess in der Praxis sowohl von professionellen Mitarbeitern der IT-Abteilungen wie auch betriebswirtschaftlich versierten Spezialisten begleiten zu lassen.
In diesem Bereich des BI-Umfeldes werden die aufbereiteten und bereinigten Daten ab der zweiten Transformationsschicht benutzt, um die ersten Informationssysteme mit ihnen zu versorgen. Das OLAP-FrontEnd greift über den OLAP-Server auf die Daten des CDW zu, um komplexe Abfragen in mehreren Dimensionen durchzuführen und neue Cubes zu generieren, sich in den Cubes zu bewegen oder die OLAP Funktionalitäten zu nutzen.[24] DataMining Applikationen suchen in den verschiedenen Transformationsschichten nach Mustern, die sich für weitere betriebswirtschaftliche Vorgehensweisen nutzen lassen oder helfen die Prozesse zu optimieren.[25] Auch die Reportingfunktionalität setzt eben auf diese Datenstrukturen auf, da sie teilweise automatisiert ausgeführt wird und eventuell berechnete Kennzahlen aus der Anreicherungsschicht als auslösende Momente benötigt. Hier sei beispielsweise auf die Abweichungsberichte im späteren Kapitel verwiesen, die feste Warnpunkte benötigen, um wirksam zu funktionieren.
An dieser Stelle sei ebenfalls das Wissensmanagement angesprochen, welches die qualitativ hochwertigen und vereinheitlichten Daten, die bisher erstellt worden sind, nutzen kann, um die eigenen Datenbestände zu vervollständigen oder aufzubauen. Über das Metadatenmanagement ist es zudem in der Lage auch seinerseits Daten für das Data Warehouse zu liefern.
In diesem Bereich finden sich die Systeme, die man grob unter dem Namen „FrontEnd“ zusammenfassen könnte, da sie primär von Endanwendern (wie z.B. der Geschäftsführung oder spezialisierten Fachkräften einzelner Abteilungen) bedient, genutzt und weiterentwickelt werden. Idealerweise werden die kompletten Applikationen in einem Portal dargestellt, welches benutzergruppenspezifisch aufgebaut werden kann.
Das Metadatenmanagement ist im CDW sowie im ODS bzw. den Data Marts implementiert und führt in einem Repository eine detaillierte Beschreibung der Daten, Strukturen und Prozesse, die das DW-System kennt.[26] An der Breite des Balkens in Abbildung 4 erkennt man, dass das MDM nicht nur für den ETL-Prozess wichtig ist, sondern auch für die folgenden zwei Schichten. Auf der einen Seite nutzen DataMining Applikationen oder die Reportingautomatismen das MDM, um unlogische Suchabfragen zu vermeiden und auf der anderen Seite wird das MDM von den Endanwendern genutzt, um zu verstehen, wie welche Daten dargestellt sind und woher sie genau kommen; somit sind sie in der Lage auch komplexere Sachverhalte zu verstehen.
Im Zeitalter der Informationstechnik und auch der Informationsüberflutung wird eine adäquate Vorgehensweise bei dem Umgang mit diesen Datenmengen immer wichtiger. Je schneller man aus diesen Daten auch betriebswirtschaftlich sinnvolle Informationen entwickeln und diese in strategische Handlungen fortführen kann, desto größer wird auch der Wettbewerbsvorteil sein, den man sozusagen als Informationsvorsprung gegenüber der Konkurrenz hat. Beachtet man die Qualitätsfaktoren bei der Implementierung des ETL-Prozesses und des Metadatenmanagements, so profitieren auch alle anderen Applikationen davon und liefern werthaltige Ergebnisse.
Gerade im Bereich des Reportings kommt es auf Flexibilität, Geschwindigkeit, Qualität und Verfügbarkeit an. Manuell erstellte Excel Dateien – dessen Datengrundlage erst noch aus den diversen Systemen generiert werden muss – können diese Anforderungen nur in sehr geringem Umfang befriedigen. Wichtig ist daher, die Planung eines BI-Umfelds mit dazugehörigem Data Warehouse Konzept von Anfang an von Spezialisten der verschiedensten Abteilungen begleiten zu lassen und auf die Anforderungen des Unternehmens abzustimmen.
Das folgende Kapitel beschäftigt sich überwiegend mit dem Aufbau eines Data Warehouse und den zu Grunde liegenden Architekturen, um den Zusammenhang von Business Intelligence, Data Warehouse und Reporting besser darstellen zu können.
[...]
[1] Vgl. Gluchowski / Gabriel / Dittmar (2008), S. 89.
[2] Vgl. Grothe / Gentsch (2000), S. 20.
[3] Vgl. Mertens (2002), S. 4.
[4] Vgl. Gluchowski (2001), S. 7.
[5] Vgl. Gluchowski (2001), S. 2.
[6] Vgl. Weill / Olson (1987), S. 5.
[7] Vgl. Knöll / Schulz-Sacharow / Zimpel (2006), S. 41.
[8] Vgl. Grothe / Gentsch (2000), S. 65.
[9] Vgl. Alter (2002), S. 151.
[10] Vgl. Rockart / Treacy (1980), S. 4.
[11] Vgl. Rockart / Treacy (1980), S. 6f.
[12] Vgl. Jarke / Lenzerini / Vassiliou / Vassiliadis (2000), S. 1.
[13] Vgl. [URL1] Gartner Group.
[14] Vgl. Chamoni / Gluchowski / Hahne (2005), S. 40.
[15] Vgl. Bodendorf (2006), S. 38.
[16] Vgl. Gluchowski / Gabriel / Dittmar (2008), S. 135f.
[17] Vgl. Kemper / Mehanna / Unger (2006), S. 23.
[18] Vgl. Mehrwald (2005), S. 184f.
[19] Vgl. Kemper / Mehanna / Unger (2006), S. 28ff.
[20] Vgl. Kemper / Mehanna / Unger (2006), S. 30f.
[21] Vgl. Müller (2000), S. 196f.
[22] Vgl. Grothe / Gentsch (2000), S. 53f.
[23] Vgl. Gluchowski / Gabriel / Dittmar (2008), S. 130.
[24] Vgl. Muksch / Behme (2000), S. 349.
[25] Vgl. Nölken (2002), S. 261.
[26] Vgl. Jarke / Lenzerini / Vassiliou / Vassiliadis (2000), S. 124.
