Inhaltsverzeichnis
Werbung
BI-Architektur_?_Konzepte_und_praktische_Umsetzung Hochschule: Standort: Studiengang: Veranstaltung: Betreuer: Typ: Themengebiet: Autor(en): Studienzeitmodell: Semesterbezeichnung: Studiensemester: Bearbeitungsstatus: Prüfungstermin: Abgabetermin: Fallstudienarbeit Hochschule für Oekonomie & Management Bonn Bachelor Wirtschaftsinformatik Fallstudie / Wissenschaftliches Arbeiten Prof._Dr._Uwe_Kern Fallstudienarbeit Business Intelligence Tobias Wäschle, Bernd Dabrock Abendstudium SS11 2 vergeben 23.01.12 15.01.12 Inhaltsverzeichnis • 1 Einleitung ♦ 1.1 Zielsetzung und Abgrenzung ♦ 1.2 Vorgehensweise • 2 Business Intelligence ♦ 2.1 Begriffsklärung ♦ 2.2 Geschichte ♦ 2.3 Anwendungsgebiete für BI • 3 Architekturkonzepte ♦ 3.1 Fachliche Architektur ◊ 3.1.1 Auswertungen ◊ 3.1.2 Measures ◊ 3.1.3 Facts ◊ 3.1.4 Dimensionen ◊ 3.1.5 Fachliche Sterne ◊ 3.1.6 Fachliche Modellierung ♦ 3.2 Referenzarchitektur ◊ 3.2.1 Data Sources ◊ 3.2.2 Data Integration ⋅ 3.2.2.1 Extract ⋅ 3.2.2.2 Transform ⋅ 3.2.2.3 Load ◊ 3.2.3 Data Management ⋅ 3.2.3.1 Core Data Warehouse ⋅ 3.2.3.2 Data Marts ⋅ 3.2.3.3 Operational Data Store ◊ 3.2.4 Information Delivery Inhaltsverzeichnis 1 BI-Architektur_?_Konzepte_und_praktische_Umsetzung ⋅ 3.2.4.1 Free Data Research ⋅ 3.2.4.2 Online Analytical Processing ⋅ 3.2.4.3 Data Mining ◊ 3.2.5 Visualization ⋅ 3.2.5.1 Front-Ends ⋅ 3.2.5.2 Dashboards ⋅ 3.2.5.3 Portale ♦ 3.3 Architekturvarianten ◊ 3.3.1 Zentrales Data Warehouse ◊ 3.3.2 Distributed Data Warehouse ◊ 3.3.3 Hub&Spoke-Architektur • 4 Praktische Umsetzung ♦ 4.1 Grundphilosophien ◊ 4.1.1 DWH Umsetzungsvarianten ⋅ 4.1.1.1 Klassisches Data Warehousing ⋅ 4.1.1.2 Closed-Loop Data Warehousing ⋅ 4.1.1.3 Real-Time Data Warehousing ⋅ 4.1.1.4 Active Data Warehousing ◊ 4.1.2 DWH Archetypen ⋅ 4.1.2.1 Archetyp Transaktionsorientiert ⋅ 4.1.2.2 Archetyp Workfloworientiert ⋅ 4.1.2.3 Archetyp Stammdatenorientiert ⋅ 4.1.2.4 Archetyp Anwendungsspezifisch ♦ 4.2 Hersteller und Produkte ◊ 4.2.1 Marktübersicht ◊ 4.2.2 Marktrelevanteste BI Lösungen Inhaltsverzeichnis 2 BI-Architektur_?_Konzepte_und_praktische_Umsetzung ◊ 4.2.3 Open Source im BI Umfeld ⋅ 4.2.3.1 Entwicklung ⋅ 4.2.3.2 Vor- und Nachteile ⋅ 4.2.3.3 Zukunft von Open Source im BI Umfeld ♦ 4.3 Szenario: "Schoko GmbH" ◊ 4.3.1 Ausgangssituation ◊ 4.3.2 Motivation und Zielsetzung ◊ 4.3.3 Lösungskonzept ◊ 4.3.4 Entwicklung und Betrieb ◊ 4.3.5 Abschließende Bemerkungen • 5 Fazit • 6 Abbildungsverzeichnis • 7 Tabellenverzeichnis • 8 Fußnoten • 9 Literatur- und Quellenverzeichnis 1 Einleitung 1.1 Zielsetzung und Abgrenzung Ziel der Fallstudie ist es in einem ersten Schwerpunkt, die Konzepte, die sich hinter dem Begriff "Business Intelligence" verbergen, zu beleuchten und ein Grundverständnis zunächst einmal des Begriffes selbst und anschließend der Architektur moderner BI-Systeme im Allgemeinen zu schaffen. Dabei liegt der Fokus auf den allgemeingültigen theoretischen Architekturkonzepten der Business Intelligence und es werden keine konkreten herstellerspezifischen Konzepte betrachtet. In einem zweiten Schwerpunkt werden Konzepte der praktischen Umsetzung vorgestellt, d.h. unter welchen Voraussetzungen sind gewisse Architekturkonzepte gut geeignet oder weniger gut geeignet. Der Abschnitt ist keine Anleitung, wie z.B. BI in einem Unternehmen richtig eingeführt wird sondern versteht sich eher als richtungsweisend und ratgebend zur Schärfung des Praxisverständnisses von BI und als Einstieg zur weiteren Vertiefung. 1.2 Vorgehensweise Die Fallstudie hat zwei Themenschwerpunkte: "Konzepte" und "praktische Umsetzung". Daher liegt der Fokus, nach einem Anfangskapitel zur Begriffsklärung und Herkunft von Business Intelligence, auf den Kapiteln "Architekturkonzepte" und "Praktische Umsetzung". Im Kapitel "Architekturkonzepte" werden die fachliche Architektur, die Referenzarchitektur und weitere 1 Einleitung 3 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Architekturvarianten erläutert. Teilweise unterscheiden sich BI-Systeme sowohl in Konzept als auch in der Umsetzung erheblich. In dieser Fallstudie werden daher nur Architekturkonzepte betrachtet die sich in den meisten aktuellen BI-Systemen wiedererkennen lassen und denen sich somit die höchste Allgemeingültigkeit unterstellen lässt. Im Kapitel "praktische Umsetzung" werden Umsetzungsvarianten vorgestellt. Je nachdem in welcher Branche das jeweilige Unternehmen tätig ist oder in welchem Bereich die BI-Software zum Einsatz kommt ergeben sich unterschiedliche Anforderungen an z.B. Verfügbarkeit, Latenzzeit und Datenhaltung oder andere individuellere Bedürfnisse. Um diesem Sachverhalt gerecht zu werden existieren verschiedene Möglichkeiten der praktischen Umsetzung die in diesem Kapitel nicht in höchstem Detailgrad aber möglichst verständlich dargestellt werden. Auch hier gilt: Es werden die typischsten und somit allgemeingültigsten Varianten vorgestellt. Aufgrund der Breite des BI-Umfelds kann nicht auf jede Nische im Besonderen eingegangen werden. Anschließend folgt das Fazit der Fallstudie. 2 Business Intelligence 2.1 Begriffsklärung Business Intelligence (Abkz. BI) ist in der Informationstechnik ein Oberbegriff für Techniken und Vorgehensweisen zur Datenerhebung, Informationsgewinnung und zur Darstellung von Informationen. Ziel ist es, anhand der gesammelten Informationen einen größtmöglichen Erkenntnisgewinn zu erzielen und das Unternehmensmanagement dadurch bei der Entscheidungsfindung in Planung, Steuerung und Kontrolle zu unterstützen. Dies wird heutzutage mithilfe von IT-Systemen erreicht, die speziell für dieses Ziel der Datenerhebung, Aufbereitung und Darstellung programmiert sind. 2.2 Geschichte Die Geburtsstunde des Begriffes "Business Intelligence" war vermutlich 1958, als der Informatiker Hans Peter Luhn im IBM-Journal seinen Beitrag ?A Business Intelligence System? veröffentlichte[1]. Populär wurde der Begriff allerdings erst in den 90er Jahren, als sich ein Analyst der Gartner Group vertiefend mit dem Thema befasste. Er bezeichnete "Business Intelligence" als einen Oberbegriff für Konzepte und Methoden zur Entscheidungsfindung auf Grundlage von Daten- und faktenbasierten Unterstützungssystemen[2]. 2.3 Anwendungsgebiete für BI 1.2 Vorgehensweise 4 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Abb. 1: BI-Framework Die Grundvorgehensweise aus unternehmerischen Prozessen Rückschlüsse auf das Geschäft zu ziehen und daraus weitere Handlungsschritte abzuleiten ist betriebswirtschaftlich nichts Neues. Ein handschriftlicher Report mit den aktuellen Produktionsdaten kann demnach bereits als "Business Intelligence" bezeichnet werden. Immer komplexer werdende Prozesse und stetig steigende Datenmengen erschweren allerdings die Durchschaubarkeit von Unternehmensabläufen wodurch es zusehends schwerer wird, ohne einen strukturierten Ansatz, eine transparente und nachvollziehbare Faktenlage darzulegen auf der vernünftige Entscheidungen getroffen werden können. Aus dieser Erkenntnis heraus wurde IT-Software entwickelt um auch in Zeiten von stetig steigenden Datenmengen eine transparente und nachvollziehbare Faktenlage darzulegen. Auch wenn sich die Software der jeweiligen Hersteller in Funktion und Umfang unterscheidet, so ist das Rahmenkonzept im Grunde genommen identisch. Zunächst werden die Geschäftsdaten und -zahlen eines Unternehmens aus den vielen verschiedenen Datenbeständen der einzelnen IT-Systeme und Unternehmensbereiche gesammelt. Diese Daten werden in einem typischerweise als "Data Warehouse" bezeichneten Datenlager gespeichert. Ein Data Warehouse ist ein umfassendes Datenlager in dem die Daten aus den verschiedenen Quellsystemen bereinigt und thematisch sortiert abgelegt werden. Dieses Data Warehouse ist anschließend selbst Datenquelle für Auswertungs- und Analysesysteme. Der Zugriff auf die Daten ist für die verschiedenen Unternehmensteile in der Regel selektiv geregelt. Produktion, Vertrieb, Beschaffung als auch die Unternehmensleitung können sich die Daten individuell nach dem benötigten Informationsbedarf und in gewünschter Präsentationsform abrufen. Die Daten stehen auch sofort für eine Auswertung zur Verfügung, indem sie automatisch strukturiert, grafisch aufbereitet und somit vergleichbar gemacht werden [3]. 3 Architekturkonzepte Die Datenquellen der IT-basierten Managementunterstützung "Business Intelligence" sind oft als transaktionale Systeme oder OnLine Transaction Processing Systems (OLTP) bezeichnet. Oft sind es ERP- oder CRM-Systeme welche zur Auftragserfassung, Rechnungsstellung, Rechnungslegung, Logistiksteuerung, Einkauf, Personalverwaltung oder dem Management von Kundenbeziehungen dienen. Ihre Ausrichtung auf einzelne Transaktionen (Auftragspositionen, Buchungssätze, Materialstämme, usw.) schränkt den Umfang der 2.3 Anwendungsgebiete für BI 5 BI-Architektur_?_Konzepte_und_praktische_Umsetzung prozessübergreifenden betriebswirtschaftlichen Entscheidungsfundierungen gravierend ein: - schlechte Performance - eingeschränkte betriebswirtschaftliche Analysemöglichkeiten[4] Die schlechte Performance transaktionaler Strukturen ist dadurch bedingt, dass analytische Anwendungen in der Regel keinen Nutzen aus einzelnen Transaktionen gewinnen können, sondern eine übergreifende Information zu mehreren Transaktionen benötigen. In einem transaktionalen Datenmodell würde eine Abfrage, welchen Umsatz ein Unternehmen in den letzten 2 Jahren erwirtschaftet hat, das Lesen aller Transaktionen der letzten zwei Jahre bedeuten, obwohl diese genaue Detaillierungsstufe gar nicht benötigt wird. Darüber hinaus würden diese OLTP-Systeme mit Analysen belastet, für die sie ursprünglich nicht gebaut worden sind. Deshalb werden die Daten der OLTP-Systeme in Verbindung mit modernen Data-Warehouse-Systemen (DWH) genutzt, um Informationen einmalig auszulesen und zum Zwecke der Business Intelligence Analysen in spezielle Datenmodelle zu transformieren.[5] Auf dieser Basis stellen die, meist für BI zum Einsatz kommenden entscheidungsunterstützenden Systeme (Decision Support Systems, DSS), den Gegenpart dar und umfassen das klassische Berichtswesen, die interaktive Datenanalyse (Online Analytical Processing, OLAP) sowie Systeme zur Suche nach komplexen Zusammenhängen und unbekannten Datenmustern (Data Mining).[6] Die Architektur beschreibt die konzeptionelle Planung der Funktionen, des Aufbaus und des Zusammenwirkens der unterschiedlichen Komponenten eines BI-Systems. 3.1 Fachliche Architektur Den Output und fachlichen Nutzen der Business Intelligence bilden die Auswertungen (Reports). Reports sind Listen, bestehend aus Spalten- und Zeilenbeschriftungen, Filtern, Gruppierungs-Ebenen und Kennzahlen. Die Reports sind die Informationsanforderungen der Anwender (Fachvertreter). Diese Informationen werden in technischen Datenmodellen in der Datenbank abgelegt. Ziel der Datenmodellierung ist immer, ein Abbild der Realität in einer datentechnisch darstellbaren Form zu schaffen.[7] Bereits in der frühen Entwurfsphase ist es wichtig, dass auch die Fachvertreter ein Verständnis der technichen Datenmodelle entwickeln und bei deren Spezifikationen mitwirken. Ein grundsätzlich falsch gewähltes Datenmodell kann nachträglich nur mit sehr großem Aufwand korrigiert werden. Auf Grund der Komplexität wählt man von allen Parteien leicht verständliche Sprachen und Techniken, um die Anforderungen und Sachverhalte darzustellen. Eine weit verbreitete Sprache zwischen Fachvertretern, Management und IT-Experten ist die Unified Modeling Language (UML). UML ist die meist genutzte Beschreibungtechnik der Object Management Group (OMG) und der Weg der Welt nicht nur Anwendungsstrukturen, Betriebseigenschaften und Architekturen, sondern auch Geschäftsprozesse und Datenstrukturen zu modellieren[8]. Neben UML existieren noch einige weitere Ansätze aber im Business Intelligence Umfeld hat sich noch kein Standard durchgesetzt[9]. Auch wenn sich keine standardisierte Sprache zur Beschreibung von Business Intelligence Systemen durchgesetzt hat, bedarf es dennoch einiger Begriffe welche der fachlichen Beschreibung dienen. 3 Architekturkonzepte 6 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 3.1.1 Auswertungen In Anlehnung an: Humm (2005), Seite 6 Abb. 2: Auswertung Der Informationsbedarf betriebswirtschaftlicher Unternehmungen ist unterschiedlich. Die Ausgestaltung und das Design der benötigten Auswertungen (Reports) ist von verschiedensten Faktoren abhängig. So fordern unterschiedliche Branchen, Produkte und Prozesse auch inhomogene Informationen zur Entscheidungsfundierung. Selbst Standardreports wie z.B. Finanzkennzahlen aus dem Reporting oder Kampagnenanalysen aus dem Marketing- und Vertriebsbereich erfordern meist aufwendige Anpassungen am Customizing bis hin zur Modellierung der Datenmodelle. Die Vertreter der Fachseiten und das Management werden über Ziele der Unternehmensstrategie gesteuert. Die Ziele bilden die Grundlage für den Informationsbedarf einer Unternehmung. So sind die Informationssysteme sowohl technisch, fachlich und organisatorisch so aufzubauen, dass sie mit diesen Anforderungen harmonisieren. Diese Kennzahlen, welche die Grundlage für die Messung der Zielerreichungen bilden, müssen in geeigneter Form bereitgestellt werden. 3.1.2 Measures Measure, auch Maßzahl oder Kennzahl genannt, ist die kleinste Informationseinheit und bildet die Basis für alle Reports. Measures sind stets numerisch und können in der Regel aggregiert werden (Summe, Mittelwert etc.). Komplexe Measures können aus anderen Measures oder (evtl. nicht aggregierbaren) Basisinformationen abgeleitet sein[10]. Measures sind folglich für mathematische Operationen geeignet. Ohne zusätzliche beschreibende Daten bringen Measures keinen Informationsgewinn. Aus diesem Grund werden sie immer mit bzw. in Facts verwendet. 3.1.3 Facts 3.1.1 Auswertungen 7 BI-Architektur_?_Konzepte_und_praktische_Umsetzung In Anlehnung an: Humm (2005), Seite 5 Abb. 3: Fact Facts sind Größen mit betriebswirtschaftlichem Bezug. Zum Beispiel Daten zum Kunden, zur Kostenstelle oder zu einem Auftrag. Ein Fact ist eine Sammlung von fachlich verbundenen Measures und Dimensionen. Fact-Beschreibungen speichern Zusatzinformationen zu den verwendeten Measures und müssen keine numerischen Werte enthalten. So lassen sie allerdings auch keine mathematischen Operationen oder Aggregationen zu. Wobei in dieses Beispiel (Abb. 3) bereits eine Analyse für einen bestimmtes Jahr, eine bestimmte Region und einen bestimmten Debitor (Kunden) darstellt (Dimensionen). 3.1.4 Dimensionen In Anlehnung an: Humm (2005), Seite 6 Abb. 4: Fachlicher Stern Dimensionen, oder auch Navigationsattribute genannt, beschreiben die aggregierbaren Daten eines Facts, indem sie Relationen zu anderen Facts herstellen. So ist im Beispiel der Abb. 4 die Region vom Kunden (Debitor) des Auftrags abhängig. Dimensionen stellen also die Informationen über die Daten eines Facts bereit. Dimensionen stellen auch die Abhängigkeit im zeitlichen Verlauf dar. So können sich beispielsweise die Measures Straße und Hausnummer innerhalb der Adresse (Fact) eines Kunden (Fact) geändert haben. Setzt man dann verschiedene Filter auf zeitliche Dimensionen, finden sich zu einem Kunden unterschiedliche Adressen. Dimensionen sind hierarchisch aufgebaut und führen so zu Gebilden wie die fachlichen Sterne. 3.1.3 Facts 8 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Wenn das Ergebnis einer Analyse "42" (Measure) ergibt, ist dieses Datum an sich wertlos. Mit der Überschrift (Fact) "Anzahl Verkäufe", einer zeitlichen Dimension "Januar 2011" und der örtlichen Dimension "Bonn", wird dieses Datum zu der Information "42 Verkäufe im Januar 2011 in Bonn". Auf transaktionale Systeme (OLTP) basierende BI kennen diese historisierende Form der Filter- und Auswertungsinstrumente für Measures in Facts nicht und lassen nur Analysen auf aktuelle Daten zu. 3.1.5 Fachliche Sterne Ein fachlicher Stern ist die fachliche Definition der Facts mit ihren Measures und den zugehörigen Dimensionen. Der Stern "Aufträge" (Abb. 4) umfasst die Measures "Umsatz" und "Anzahl Verkäufe", die Fact-Beschreibung "AuftragsNr" und die Dimensionen "Zeit" und "Region". 3.1.6 Fachliche Modellierung Abb. 5: Fachlicher Cube Die zentralen Objekte, auf denen Berichte und Analysen in einem Data Warehouse (DWH) basieren, heißen fachliche Würfel (Cubes). Ein Cube wird mit Hilfe der Modellvorstellungen fachlicher Sterne aus den geforderten Auswertungen spezifiziert und in die technischen Datenmodellstrukturen übersetzt. Der Cube beschreibt einen (aus Reportingsicht) in sich geschlossenen Datenbestand z.B. eines betriebswirtschaftlichen Bereichs. Aus Reportingsicht bezieht sich ein Report immer auf einen Cube, der die Measures, Facts und Dimensionen so anordnet, dass sie dem intuitiven Verständnis der Endanwender entsprechen. 3.1.4 Dimensionen 9 BI-Architektur_?_Konzepte_und_praktische_Umsetzung In Anlehnung an: Humm (2005), Seite 6 Abb. 6: Fachliche Modellierung 3.2 Referenzarchitektur Abb. 7: BI Referenz Architektur Je nach Anwendung, Hersteller der BI und vorhandener IT-Architektur gibt es unterschiedliche Ausprägungen einer BI-Architektur. Abb. 7 zeigt eine Architektur mit Elementen, wie sie in der Praxis häufig vorgefunden wird: Das Kernstück einer BI-Architektur ist das Data-Warehouse (DWH oder C-DWH). Thomas Zeh schreibt hierzu: »Ein DataWarehouse ist ein physischer Datenbestand, der eine integrierte Sicht auf die zugrunde liegenden Datenquellen ermöglicht.«[11] Die Sammlung der verschiedenen Komponenten um das DWH, welche erst brauchbare Auswertungen aus den Datenbeständen des DWH ermöglichen, werden in ihrer Gesamtheit als "Business Intelligence" bezeichnet. Hierzu gehören die Quellsysteme (in Abb. 7 "Data Sources"), der ETL Process innerhalb der Data Integration, der Information Delivery und schließlich die Benutzerschnittstellen zur Datenbereitstellung und Visualisierung. 3.1.6 Fachliche Modellierung 10 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 3.2.1 Data Sources Die Data Sources (im Bild beschrieben) bilden die operativen Quellsysteme (OLTP) des Unternehmens. Als Beispiel werden in Abb. 7 verschiedene Module eines Customer Relationship Management Systems (CRM-Systems) und eines Enterprise Recource Planing Systems (ERP-Systems) dargestellt. Natürlich können noch weitere Systeme über unterschiedliche Schnittstellen angebunden werden. Die Data Sources können dabei aus unterschiedlichen Technologien und Herstellern bestehen. Um die Daten für Auswertungen in einem BI-Umfeld zur Verfügung zu stellen, müssen in den Data Sources die relevanten Daten zu Extraktion bereitgestellt werden. Im Idealfall befinden sich die Daten in einer integrierten Umgebung eines Herstellers und die Datenfelder lassen sich in den Tabellen der Quellsysteme zur Extraktion kennzeichnen. Diese Kennzeichnung sorgt für ausreichende Zugriffsberechtigungen für das BI-System und erlaubt dem ETL-Process das Lesen in den transaktionalen Tabellen. In einem heterogenen Systemumfeld werden die Daten mit unterschiedlichen Lösungen zur Extraktion bereitgestellt. Eine übliche Variante ist das Schreiben einer Textdatei im CSV- oder XML-Format, mit anschließender Bereitstellung über einem sftp-Zugang. 3.2.2 Data Integration Der Bereich Data Integration (deutsch: Datenintegration) bildet die Schnittstelle zwischen den operativen Quellsystemen und dem Data Management im Data Warehouse (DWH). In dieser Schicht werden die Daten aus den Quellsystemen extrahiert, transformiert, die Qualität gesichert und in das DWH geladen. Dieser Prozess wird deshalb auch in den ETL Prozess für Extraction, Transformation and Loading zusammengefasst. Der temporäre Speicher- oder Arbeitsbereich der Data Integration wird als Staging Area bezeichnet. 3.2.2.1 Extract Die Extraktion der Daten beschreibt die eigentliche Schnittstelle. Hierbei werden die Rohdaten von den physikalischen Maschinen der Quellsysteme (Data Source) auf die BI-Server mit dem Data Warehouse (DWH) geladen. Für die Extraktion stehen dem BI-System meist vielseitige Import-Tools zur Verfügung, da nur im Idealfall direkt aus einer relationalen Quelldatenbank gelesen werden kann. Diese Import-Tools sind beispielsweise in der Lage, sich mit einen sftp-Server zu verbinden und die bereit gestellten Daten in CSV- oder XML-Dateiformaten einzulesen. Die Spezifikationen dieser Schnittstellen und Formate werden in Schnittstellenvereinbarungen mit beiden Seiten (BI <-> Data Source) abgesprochen. Diese Dokumente enthalten neben den Details zu den Datenfeldern auch Absprachen zur Art und zum Zeitpunkt der geplanten Extraktionen. Wegen der Lastzeiten der Data Sources werden die großen Datenbeladungen meist für die lastarme Nachtzeit eingeplant. In Beladungsketten werden die Extraktionen der unterschiedlichen Data Sources in Zeitfenstern eingeplant und abgearbeitet. Neben dieser Art der synchronen Extraktion können die Daten auch asynchron oder abfragegesteuert beladen werden. Die Extraktion findet dann zu einem vereinbarten Ereignis statt. Z.B. stellt die Data Source einen Extrakt der aktuellen Daten bereit, wenn eine definierte Anzahl bestimmter Vorgänge erreicht wurde. 3.2.2.2 Transform »Der Transformationsprozess umfasst alle Aktivitäten zur Umwandlung der operativen Daten in betriebswirtschaftlich interpretierbare Daten. Er setzt sich aus den Teilprozessen der Filterung, der Harmonisierung, der Aggregation sowie der Anreicherung zusammen.«[12] 3.2.1 Data Sources 11 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Der Teilprozess Filterung ist bereits ein wichtiger Teil der Qualitätssicherung der Daten. Da die Inhalte der Datenfelder oft aus manuellen Eingaben der Mitarbeiter resultieren, ist auf die syntaktische und semantische Qualität der Daten kein Verlass. Es wird in unterschiedlichen Qualtitäsebenen der Filterung unterschieden: Service Level 1: Ein falscher Datentyp eines einzelnen Datums kann bereits zu Abbrüchen einzelner Data-Source-Beladungen oder ganzer Beladungsketten führen. Im Service Level 1 werden die Daten auf ihren Typ und ihr Format (Syntax) automatisch überprüft und an bekannte Formen angepasst. Aus einem 13.01.80 wird beispielsweise der 13.01.1980. Ein semantischer Fehler, wie beispielsweise das Fehlen von Pflichtfeldern, kann durch vordefinierte Regeln mit Defaultwerten automatisiert behoben werden. Service Level 2: Die Regeldefinition des Service Level 1 wird nur die wenigsten Unstimmigkeiten aufstöbern und beseitigen können. So findet der Service Level 2 zwar noch selbständig die syntaktischen Herausforderungen aber keine passende Regel für die automatische Korrektur. Fehler dieser Stufe erfordern das manuelle Eingreifen von Spezialisten. Mit einer nachträglichen Spezifikation einer passenden Korrekturroutine werden zukünftige Fehler dieser Art bereits im Service Level 1 abgefangen. Die semantischen Prüfungen erkennen mit Hilfe von Plausibilitätskontrollen, einfachen Wertebereichsüberprüfungen oder Data-Mining-basierenden Musterkennungsverfahren fehlerhafte Datenwerte. Fehler dieser Art sich häufig fachlicher Natur und lassen sich nicht kurzfristig durch IT-Spezialisten in den Data Sources bereinigen. Service Level 3: Syntaktische Fehler können vollständig beschrieben und automatisch erkannt werden. Deshalb verbleiben nur unerkannte semantische Fehler im Service Level 3, welche nur noch manuell durch betriebswirtschaftliche Spezialisten gefunden und korrigiert werden können[13]. In Anlehnung an: Kemper (2006), Seite 29 Abb. 8: Harmonisierung Die Harmonisierung der Daten ist notwendig, weil die meist heterogenen externen Quelldaten aus den unterschiedlichen Data Sources nach unterschiedlichen Schlüsselfeldern indiziert sind. Daher liegt die 3.2.2.2 Transform 12 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Hauptaufgabe in der Zusammenführung der gefilterten Daten und im Mapping synonymer oder homonymer Werte[14]. Der Teilprozess Aggregation beginnt bereits mit der Realisierung der Dimensionen und stellt die Datenstrukturen in Anlehnung an die fachliche Konzeption her[15]. Relationale Datenstrukturen In Anlehung an: Humm (2005), Seite 7 Abb. 9: Datenstruktur nach Star-Schema • Flache Strukturen Flache Strukturen bilden eine bewusst denormalisierte und höhere Aggregationsebene ab. So können die Analysen mit einer stark verkleinerten Datenbasis arbeiten. Jeder Fact muss einen eigenen Tabellenschlüssel erhalten und so kommt es durch die so entstehenden langen Schlüssel zu Performanceeinbußen. Auch sind sie nicht für OLAP-Anwendungen geeignet. Die flachen Strukturen kommen heute meist im Austausch zwischen den Systemen und somit in der Staging Area zum Einsatz[16]. • Star-Schema Das Star-Schema ist speziell auf die Leistungsmerkmale relationaler Datenbanken abgestimmt und so kommt es nicht zu den Performanceeinbußen wie bei den flachen Strukturen. Die Faktentabelle (in Abb. 9 "Auftrag") nimmt nur die Measures und die Schlüssel der Dimensionen auf. So wird der Einsatz von besonders kurzen Schlüsseln möglich. Das Star-Schema wird beim Einsatz von R-OLAP-Systemen verwendet[17][18]. • Snowflake-Schema 3.2.2.2 Transform 13 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Das Snowflake-Schema ist eine Erweiterung des Star-Schemas. Es erweitert das Star-Schema um Stammdatentabellen, die es möglich machen, Measures nicht nur historisiert, sondern auch aktuell darzustellen. Die Administration wird allerdings aufwändiger und so wird es schwieriger, das Modell performant zu lesen. Das Snowflake-Schema wird beim Einsatz von R-OLAP-Systemen verwendet[19][20]. Multidimensionale Datenstruktur für OLAP-Systeme (M-OLAP) Hier werden herstellerabhängige, proprietäre Datenstrukturen und Datenbanksysteme verwendet, die speziell auf eine hohe Performance in multidimensionalen Datenstrukturen ausgerichtet sind, verwendet[21]" Sie werden meist in Data Marts für den Einsatz von M-OLAP benötigt. Mit dem 4. Teilprozess Anreicherung werden die betriebswirtschaftlichen Kennzahlen errechnet und in den neuen Datenstrukturen abgelegt[22]. 3.2.2.3 Load Im letzten Schritt des Data Integration ETL-Process "Load" werden die vorbereiteten Daten aus der Staging Area in das Data Management (Data Warehouse) geladen und die darauf aufbauenden Analysen aktualisiert. Hier ergeben sich weitere Möglichkeiten Ressourcen zu sparen und die Performance der Systeme nicht unnötig zu belasten. So ist es nicht nötig, immerzu alle Daten aus der Staging Area in die Datenbanken des Data Warehouse erneut zur überführen. Meist reicht es aus, nur die Änderungen am Datenbestand zu betrachten. Der Load-Process versieht geänderte Daten mit einem Zeitstempel und historisiert frühere Versionen der Datensätze, sodass auf Daten zugegriffen werden kann, die zu einem früheren Zeitpunkt gültig waren. Während des Loadings sind die Datenbanken des Data Warehouse für den Zugriff der Analyse Tools blockiert. So bietet sich auch für diesen Prozess das Zeitfenster der geringsten Last an. 3.2.3 Data Management Das Data Management umfasst die Bereiche der Datenhaltung einer BI-Architektur. Neben dem Core Data Warehouse stehen je nach Architekturkonzept noch Data Marts und der Operational Data Store (ODS) zur Verfügung. 3.2.3.1 Core Data Warehouse Das Core Data Warehouse (C-DWH) ist die zentrale Komponente und stellt sämtliche Daten nach der ersten Transformation für unterschiedlichste Auswertungszwecke bereit. Die Daten werden in einer relationalen Datenstruktur von der Extraktion abgelegt. Siehe auch R-OLAP-Technologie Das C-DWH erfüllt somit die folgenden Funktionen: 3.2.2.3 Load 14 BI-Architektur_?_Konzepte_und_praktische_Umsetzung • Sammel- und Integrationsfunktion Aufnahme aller für die Analyse wichtigen Daten im Sinne eines logisch zentralen Datenlagers. • Distributionsfunktion Versorgung aller nachgeschalteten Data Marts mit Daten. • Auswertungsfunktion Direkte Verwendung als Datenbasis für Analysen unter Umgehung der Data Marts[23]. Die Daten sind hier in meist geringerer Detaillierung abgelegt und sind so auch für zukünftige Analyseanforderungen leichter nutzbar. Auswertungen direkt im C-DWH durchzuführen, erfordert jedoch fortgeschrittene Kenntnisse im Umgang mit Datenbanken und deren Abfragen. Gerade vor dem Hintergrund der ständig steigenden Datenvolumina können die Abfragen zu Performanceeinbrüchen der Datenbank führen. Aus diesem Grund setzt man auf die, unternehmensweit ausgerichtete, Datenhaltung des C-DWHs kleinere Datenpools, mit bereichs- oder themenorientierten Datensammlungen (Data Marts), auf. Analysen, welche auf Grundlage unternehmensweiter Daten basieren, werden in Standard Reports allen Entscheidern eines Unternehmens für ihre strategischen, taktischen und operativen Entscheidungen zur Verfügung gestellt. In der Regel wird der Datenbestand des C-DWH aus den genannten Gründen dem IT-Bereich vorbehalten[24]. 3.2.3.2 Data Marts Data Marts sind bereichs- oder themenorientierte Datenpools mit wesentlich geringeren Datenvolumina als die zentralen Core Data Warehouses. Sie erlauben spezifische Benutzerberechtigungen nach Aufgaben im Unternehmen und sind für die analytischen Abfragen durch die Fachseiten gebaut. Je nach Anwendung kommen hier auch M-OLAP und H-OLAP Technologien zum Einsatz. Data Marts sind auf die Entscheidungsfundierung des Managements kleinerer Unternehmenseinheiten wie Bereiche oder Abteilungen ausgelegt. Beispielsweise werden die Datenbestände des Vertriebs mit den Instrumenten der Vertriebssteuerung, die sensiblen personenbezogenen Daten des Personalbereichs und Kennzahlen des Controllings in getrennten Data Marts aufgeteilt. Die Leseberechtigungen der Nutzer können so voneinander getrennt werden. Die Granularität der Daten ist hier erheblich höher als in einem C-DWH und auf vorab modellierte Analyseanforderungen der Fachbereiche festgelegt. Deshalb sind auch die Freiheitsgrade der Analysen eingeschränkt und neue Analyseanforderungen müssen meist durch die IT auf Basis des C-DWH neu modelliert werden[25]. Kennzahlen, welche bereichsübergreifend generiert und eingesehen werden sollen, können auf Basis der C-DWH oder ODS als Standard Reports von der IT bereitgestellt werden. 3.2.3.3 Operational Data Store 3.2.3.1 Core Data Warehouse 15 BI-Architektur_?_Konzepte_und_praktische_Umsetzung In Anlehnung an: von Maur et al. 2003, Seite 15 Abb. 10: Eigenschaftsprofile von operativen, Operational-Data-Store- und Data-Warehouse-Systemen Der Operational Data Store (ODS) ist eine dem C-DWH ähnliche, jedoch parallel betriebene und je nach Architekturkonzept optionale Datenbank. Der ODS bietet eine integrierte, konsolidierte, datenzentrierte Sicht auf die Quelldaten, beschränkt sich jedoch auf den jeweils aktuellen Stand und ist typischerweise sowohl fachlich wie auch technisch relational modelliert[26]. Ein ODS lehnt sich mit seinem Datenbestand nah an die transaktionalen Quellsysteme an ist aber doch für die unterschiedlichsten Anwendungen in den Transformationsprozessen eine Art Zwischenablage. Dennoch lassen sich Reports, wenn die dort vorliegenden Strukturen für das gewünschte Ergebnis ausreichend sind, auch auf den Bestand des ODS aufbauen. Der Transformationsprozess zur Befüllung des ODS ist daher dem Transformationsprozess zum Beladen eines Data Warehouses sehr ähnlich, beinhaltet jedoch primär nur die Stufen der Filterung und Harmonisierung. Die Daten werden oft nur über eine Zeitspanne von mehreren Tagen vorgehalten (z.B. wochenweise) und so sind zeitraumbezogene Auswertungen nicht möglich. Jede Änderung in den Quellsystemen überschreibt den im ODS vorhandenen Datensatz. Dies kann, je nach Aktualisierungshäufigkeit, zu einer vorteilhaften Aktualität der Daten im ODS führen[27]. Da die Daten im ODS hauptsächlich für Analysen auf der Basis des operativen Kontextes herangezogen werden, werden sie sehr detailliert festgehalten. Häufig erfolgt die Detaillierung auf Transaktionsebene, d. h. einzelne Geschäftsvorfälle werden gespeichert [28]. Abb. 10 zeigt die unterschiedlichen Eigenschaften der Data Sources im Vergleich mit einem ODS und einem DWH. 3.2.4 Information Delivery Der Bereich Information Delivery beschäftigt sich mit der spezifischen Aufbereitung, Nutzung und Verteilung der Daten. Hierbei kommen unterschiedliche Analysesysteme zum Einsatz, welche die Daten in ihre endgültige Darstellungsform überführen. Mit Hilfe von Analysesystemen werden demnach Daten in einen anwendungsorientierten Kontext überführt, spezifisch aufbereitet und präsentiert. Aufgrund dieser Maßnahmen werden die Daten semantisch angereichert und erlangen verwendungs-spezifische Bedeutungen, die ihre Interpretation als Informationen ermöglichen[29]. 3.2.4.1 Free Data Research Die Free Data Research (freie Datenrecherche) erlaubt den direkten Zugriff auf die Datenhaltung. Im Gegensatz zu anderen Systemen der Information Delivery bedient sich der Benutzer somit einer eher techniknahen Sprache. Im relationalen Kontext hat sich die Structured Query Language (SQL) als anerkannter Standard durchgesetzt aber es existieren weitere Datenmanipulationssprachen verschiedener Hersteller, die einen umfangreichen, aber proprietären Leistungsumfang besitzen[30]. 3.2.3.3 Operational Data Store 16 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Anforderungen an die Datenmanipulationssprachen: • Datenauswahl & Navigation Unterstützt die Navigation über unterschiedliche Dimensionen oder Hierarchieebenen. Eine Hierarchie ist die Granularitätsstufe einer Dimension. z.B. Dimension "Zeit", mit den Hierarchistufen "Tage, Woche, Monat und Jahr". • Verdichtungen Verdichtungen bilden Summen, Durchschnittswerte oder die Nennung von Extrema-Werten. • Belegungsfunktionen Gestatten das Kopieren von Werten über Dimensions- bzw. Hierarchiebenen hinaus. • Faktengenerierung Die Faktengenerierung erlaubt das Berechnen eigener Kennzahlen. • Zusammenfassung von Dimensionselementen Erlaubt das Zusammenfassen von Datensätzen zu einer alternativen Dimension, welche durch ein bestimmtes Merkmal kategorisiert werden können. Z.B.: Die alternative Dimension "Dieselfahrzeuge", welche sich anhand des Treibstoffs von anderen Fahrzeugen abgrenzen lassen[31]. Freie Datenrecherchen fordern ein Höchstmaß an IT-Verständnis von den Benutzern. Dafür wird man in der Regel mit hochperformanten Abfragen belohnt. Dennoch können falsch erstellte Abfragen, welche sich über ein großes Datenvolumen strecken, den gesamten Betrieb des Systems nachhaltig stören. Die freien Recherchen werden deshalb meist nur von Administratoren und Power-Usern eingesetzt[32]. 3.2.4.2 Online Analytical Processing 3.2.4.1 Free Data Research 17 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Abb. 11: Cube im multidimensionalem Datenraum Das Online Analytical Processing (OLAP) ist eine nach Edgar F. Codd und Mitautoren im Jahre 1993 definiertes Ad-hoc-Analysesystem in multidimensionalen Datenräumen.[33] Der veröffentlichte Artikel sorgte für heftige Diskussionen, aus denen rund 300 Regeln für das OLAP-Umfeld hervor gingen. Eine Konsolidierung dieser Eigenschaften wurde 1995 von Pendse und Creeth mit der Reduzierung auf fünf Kerninhalte vorgenommen[34]: • Fast (Geschwindigkeit): Das System soll reguläre Abfragen innerhalb von 5 Sekunden, komplexe Abfragen in maximal 20 Sekunden beantworten. • Analysis (Analyse): Das System soll eine intuitive Analyse mit der Möglichkeit von beliebigen Berechnungen anbieten. • Shared (Geteilte Nutzung): Es existiert eine effektive Zugangssteuerung und die Möglichkeit eines Mehrbenutzerbetriebs. • Multidimensional: Unabhängig von der zugrunde liegenden Datenbankstruktur ist eine konzeptionelle multidimensionale Sicht umzusetzen. • Information (Datenumfang): Die Skalierbarkeit der Anwendung ist auch bei großen Datenmengen gegeben, so dass die Antwortzeiten von Auswertungen stabil bleiben[35]. Das Akronym FASMI steht für ?Fast Analysis of Shared Multidimensional Information?. Unabhängig von der Anzahl der Dimensionen wird stets der Würfel (engl. Cube) als Metapher für multidimensionale Datenräume gewählt. Die gebräuchliche Bezeichnung Hypercube deutet die unbeschränkte Anzahl möglicher Dimensionen an. In der Praxis verwendet man auf Grund der betriebswirtschaftlichen Anforderungen und sonst resultierenden Komplexität meist Dimensionen im einstelligen Bereich. Wie im Kapitel der fachlichen Architektur bereits beschrieben, besteht ein Cube aus Measures, Facts und Dimensionen. Darüber hinaus werden die Cubes in Hierarchisierungen geordnet (z.B. Dimension "Zeit", mit den Hierarchistufen "Tage, Woche, Monat und Jahr"). Abb. 11 verdeutlicht einen Cube mit seinen Dimensionen Zeit (in der Hierarchie "Monat"), Artikel (weitere Hierarchiestufe z.B. "Produktgruppe") und Geographie (in der Hierarchie "Region")[36]. 3.2.4.2 Online Analytical Processing 18 BI-Architektur_?_Konzepte_und_praktische_Umsetzung In Anlehnung an: Kemper (2006), Seite 96 Abb. 12: Cube-Rotation im multidimensionalem Datenraum Operationen: Üblicherweise werden verschiedene Klassen von Operationen differenziert, mit deren Hilfe spezifische Auswertungen in multi-dimensionalen Datenräumen durchgeführt werden können. Auch hier wird zur Erläuterung der grundsätzlichen Funktionsweise stets der dreidimensionale Datenraum gewählt, damit die Operationen möglichst plastisch beschrieben werden können[37]. • Pivotierung/Rotation Die Rotation erlaubt das Umschalten zweier Dimensionen: • Roll-up & Drill-down Roll-up erlaubt das Umschalten der o.g. Dimensionshierarchien. Die Dimension der Zeit lässt sich somit von der Stufe "Monat" auf die Stufe "Quartal" umschalten. Die aggregierten Summen der Verkaufszahlen errechnen sich dann auf den Zeitraum ganzer Quartale. Die Operation Drill-down schaltet von einer höheren Hiercharchieebene herunter. Also z.B. von den Quartalszahlen zu den Monatssummen[38]. 3.2.4.2 Online Analytical Processing 19 BI-Architektur_?_Konzepte_und_praktische_Umsetzung In Anlehung an: Kemper (2006), Seite 100 Abb. 13: R-OLAP, M-OLAP und H-OLAP OLAP Technologien: Die OLAP Technologien werden in 3 Kategorien anhand der verwendeten serverseitigen Datenhaltung unterschieden[39]: • R-OLAP (Relational OLAP) Greift auf relationale Datenhaltung mit Star- oder Snowflake-Schemen zu, wie sie meist im Core Data Warehouse wiederzufinden sind und bereitet die angefragten Ergebnisdaten multidimensional auf. • M-OLAP (Multidimensional OLAP) Greift auf physisch multidimensional gespeicherte Daten zu, wie sie oft in Data Marts wiederzufinden sind. • H-OLAP (Hybrid OLAP) Nutzt die Vorteile der relationalen Datenhaltung im C-DWH und die Vorteile der physischen multidimensionalen Speicherungen der Data Marts zu. Wenn der Benutzer durch Drill-Down-Navigation in detailliertere Datenbereiche vorstößt, wechselt er in die relationale Datenhaltung[40]. 3.2.4.3 Data Mining »Das Data-Mining stellt allgemein verwendbare, effiziente Methoden zur Verfügung, die autonom aus großen Rohdatenmengen die bedeutsamsten und aussagekräftigsten Muster identifizieren und sie dem Anwender als interessantes Wissen präsentieren.«[41] Üblicherweise wird der Begriff Data Mining domänenunabhängig für die Mustererkennung in strukturierten Datenbeständen verwendet. Die Theorie beschreibt den Unterschied zu herkömmlichen Analysen, mit den Fehlern einer initialen Hypothese. D.h. es werden Analysetechniken und -methoden auf eine Datenbasis angewandt, ohne bereits vorab das Ziel der Analyse zu kennen. Erst nach der Analyse und Interpretation gefundener Muster im Datenbestand wird klar, welche Information gewonnen wurde. 3.2.4.3 Data Mining 20 BI-Architektur_?_Konzepte_und_praktische_Umsetzung In der Praxis beschränken sich Data-Mining-Systeme allerdings auf die automatisierte Auswahl der Analysemethode, die Datenanalyse und die Präsentation der Analyseergebnisse. Die Generierung von Hypothesen und die Festlegung der zu analysierenden Datenbestände werden weiterhin den Systembenutzern zugeordnet[42]. Data-Mining nutzt folgende Methoden: • Deskription Das Ziel der Deskription ist die Beschreibung interessanter, aber noch nicht unmittelbar handlungsrelevanter Strukturen auf Basis deskriptiver statistischer Methoden oder Visualisierungsmethoden. Sie kommt vor allem im Rahmen der explorativen Datenanalyse zum Einsatz. • Abweichungsanalyse Die Abweichungsanalyse untersucht die Datenbestände auf auffällige abweichende oder atypische Werte, welche z.B. ungewöhnlich hoch oder niedrig sind. • Assoziation Die Assoziation findet Abhängigkeiten, indem häufig gemeinsam auftretende Ereignisse analysiert werden. • Gruppenbildung Die Gruppenbildung (oder auch Segmentierung) dient der Identifizierung von Clustern gleichartiger Objekte auf Basis von Ähnlichkeitsmerkmalen. Die Objekte innerhalb eines Clusters sollten möglichst ähnlich und die Objekte unterschiedlicher Cluster möglichst unterschiedlich sein. Die Eigenschaften eines Clusters und die Merkmale, über die sich die Ähnlichkeit abgrenzen lässt, stehen im Vorfeld nicht fest. • Klassifikation Die Klassifikation bestimmter Datensätze wird erreicht, indem anhand von bestimmten Eigenschaften im Rahmen gewisser Schwellwerte, Gemeinsamkeiten gefunden werden. Beispielsweise können Kundensegmente anhand bestimmter Jahresumsätze gebildet werden. Die Klassen werden im Vorfeld gebildet und stehen somit fest. • Wirkungsprognose Diese Methode versucht auf Basis existierender Daten auf ein unbekanntes Merkmal zu schließen. Sie dient zur Planung bestimmter Forecasts. Z.B. Verkaufserwartungen bestimmter Produkte[43]. 3.2.5 Visualization 3.2.5.1 Front-Ends Die Bereitstellung der Reports und Analysen, welche auf Basis der relationalen Datenmodelle oder der multidimensionalen OLAP-Cubes basieren, erfolgt meist über Frontends. Frontends sind Client-Anwendungen, die als eigenständige Software oder Plug-Ins in Tabellenkalkulationsanwendugen die Datenbankabfragen oder OLAP-Operationen in den C-DWH oder den Data Marts durchführen. Die Bedienung erfolgt intuitiv und komfortabel auf einer grafischen Benutzeroberfläche und ermöglicht eine Aufbereitungen und Verteilung der 3.2.5 Visualization 21 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Daten[44]. Wesentliche Funktionen der Front-End-Anwendungen: • Bereitstellung fertiger Reports (Abfragen) • Erstellen, Speichern, Aufrufen und Verwalten individueller Benutzerreports • Grafische Aufbereitung der Ergebnisse durch umfangreiche Formatierungsmöglichkeiten • Grafische Aufbereitung der Ergebnisse in verschiedenen Grafiktypen und Diagrammen • Export der Ergebnisse in Office Standardsoftware Formaten • Integration der Reports in Portale • Automatische Generierung und Verteilung von Reports [45] 3.2.5.2 Dashboards Ein Dashboard (deutsch: Steuerpult) stellt den Anwendern eine Sammlung fertiger Reports auf Knopfdruck zur Verfügung. Dashboards eignen sich hervorragend, um aggregierte Informationen auf Ebene des Topmanagements auf einfache Weise übersichtlich darzustellen[46]. Die Manager sollen: • jederzeit über die wichtigsten Kennzahlen informiert sein, • Entwicklungen von operativen Geschäftsprozessen nachvollziehen, • Abhängigkeiten (Wenn-Dann) erstellen können, • über wichtige Ereignisse über Schwellwerte automatisch informiert werden, • direkte Kontaktmöglichkeiten zu den Anbietern (Fachbereiche) der Informationen angeboten bekommen, • spezielle Informationen einfach, schnell und aktuell selbst ermitteln können, um schnell auf plötzlich auftretende Situationen zu reagieren[47]. 3.2.5.3 Portale Über Portlets lassen sich vordefinierte Reports in firmeneigenen Intranets ohne lokale Clientinstallationen bereitstellen. So können operative Berichte in browserbasierenden Anwendungen direkt und plattformübergreifend (OS) integriert werden [48]. Diese können so auch auf modern Tabletcomputern oder Smartphones angezeigt werden. 3.3 Architekturvarianten Je nach Anwendung, Performanceanforderungen, geografischer Standorte, zeitlichen Gegebenheiten oder Datenvolumina kommen unterschiedliche Architekturvarianten zum Einsatz. Sie setzen sich meist mit den bereits erklärten Komponenten zusammen. Aus Sich der reinen Datenhaltung ergeben sich folgende Konzepte: • Das zentrale Data Warehouse • Das Distributed Data Warehouse • Die Hub&Spoke Architekturen oder auch Large-Scale-Architektur 3.2.5.1 Front-Ends 22 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 3.3.1 Zentrales Data Warehouse In Anlehnung an: Bachmann (2011), Seite 94 Abb. 14: Zentrales DWH Das zentrale Data Warehouse ist die einfachste Architektur. Das Data Management besteht aus einer einzigen zentralen relationalen Datenbank, welche von den Data Sources gleichermaßen genutzt wird. Die Abb. 14 zeigt die schematische Architekturdarstellung. Es wurde auf die Darstellung der Data Integration, Information Delivery und Visualization verzichtet[49]. Eigenschaften: • Zentrale Verwaltung aller Daten in einer physischen Datenbank • Historisierte und konsolidierte Datenbasis für das gesamte Unternehmen • Je nach Unternehmensgröße sehr große Datenbanken und sehr aufwendige Modellierung • Komplexe Administration und komplexes Performance Tuning • Hoher Zeitaufwand [50] 3.3.2 Distributed Data Warehouse In Anlehnung an: Bachmann (2011), Seite 95 Abb. 15: Distributed DWH Die in Abb. 15 dargestellte Distributed Data Warehouse Architektur zeigt mehrere relationalen Datenbanken. Auch hier wurde auf die Darstellung der Komponenten aus Data Integration, Information Delivery und Visualization verzichtet[51]. Eigenschaften: 3.3.1 Zentrales Data Warehouse 23 BI-Architektur_?_Konzepte_und_praktische_Umsetzung • Aufspaltung einer logischen Datenbank in mehrere Teile, gemäß geeigneter Kriterien • Verteilung auf physisch getrennte Server • Historisierte und konsolidierte Datenbasis für das gesamte Unternehmen • Problemstellung und Komplexität entspricht der zentralen Data Warehouse-Architektur • Distributions-, Synchronisations- und Abfragemechanismen notwendig[52] 3.3.3 Hub&Spoke-Architektur In Anlehnung an: Mehrwald (2007), Seite 604 Abb. 16: Replizierende Hub&Spoke Architektur Hub&Spoke bedeutet, ein BI-System nicht nur logisch sondern auch physisch auf mehrere Data-Warehouse-Systeme (z.T auch redundant) zu verteilen und dennoch nicht den Anspruch an die Zentralität des entstehenden Gesamtsystems aufzugeben[53]. Eigenschaften: • Generierung abteilungsbezogener Data Marts (Spokes) aus dem konsistenten Datenbestand (Hub) • Beschränkung der Data Marts auf Unternehmensteile, z.B. auf Abteilungen, Bereiche, Produktsparten. • Historisierte und konsolidierte Datenbasis für das gesamte Unternehmen • Modularer Charakter durch Data Marts • Vergleichsweise kurze Implementierungszeit für BI-Lösungen anhand einer ausgewählten Datenbasis • Verwaltung großer Datenmengen oder umfangreicher Ladevorgänge • Globale Verteilung der Anwender • Globale Verteilung der Data Sources • Aufbau der Architektur kann sowohl mit dem Data Warehouse als auch mit den Data Marts beginnen [54] Je nach technischen bzw. organisatorischen Anforderungen gibt es zwei grundlegende Ausprägungen der Hub&Spoke-Architektur: • die replizierende Architektur • die aggregierende Architektur 3.3.2 Distributed Data Warehouse 24 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Die replizierenden Architektur: Die replizierenden Architekturen zielen darauf ab, Ressourcenengpässe bei der Datenanalyse zu beseitigen, die entstehen können, weil zum Beispiel: • das Information Delivery das System durch große Datenmengen oder viele Anwender besonders stark belastet. • aufgrund von Anbindungsproblemen • Information Delivery und Data Integration zeitlich nicht voneinander getrennt werden können und sich merklich behindern • die Information Delivery durch spezifische Tools unterstützt werden soll, die jeweils ein eigenes BI-System erfordern Aus diesem Grund führt man die Daten in einem zentralen DWH (Hub) zusammen, bereitet sie auf und verteilt sie an die umliegenden Systeme (Spokes). Die Abb. 16 verdeutlich diese Architektur. Es wurde wieder auf die Darstellung der Komponenten aus Data Integration, Information Delivery und Visualization verzichtet. Im Gegensatz zur Referenzarchitektur dienen die Spokes jedoch nicht ausschließlich dem Zweck, die Daten des Hubs anwendungsspezifisch aufzubereiten. Wenn z.B. die gleiche Anwendung auf mehrere Spokes verteilt wurde, können diese Spokes Daten auch identisch aufbereiten. Dieses Szenario ist in der Praxis vor allem dann anzutreffen, wenn die Spokes zur Lastverteilung eingesetzt werden[55]. Die aggregierende Architektur: In Anlehnung an: Mehrwald (2007), Seite 606 Abb. 17: Aggregierende Hub&Spoke Architektur Bei den aggregierenden Hub&Spoke-Architekturen wird im Gegensatz zu replizierenden Architekturen die Data Integration als Ressourcenengpass gesehen. Dies kann der Fall sein, weil • die datenliefernden Quellsysteme geografisch getrennt sind (Anbindungsproblem). • die Datenvolumina der liefernden Data Sources zu groß sind, um von einem System verarbeitet zu werden • Information Delivery und Data Integration zeitlich nicht voneinander getrennt werden können und sich merklich behindern. 3.3.3 Hub&Spoke-Architektur 25 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Aus diesem Grund sammeln in den aggregierenden Hub&Spoke-Architekturen mehrere Spokes die Daten ein, verarbeiten sie in der Data Integration und liefern dann an ein zentrales Data Warehouse (Hub). Die Abb. 17 verdeutlich diese Architektur. Es wurde wieder auf die Darstellung der Komponenten aus Data Integration, Information Delivery und Visualization verzichtet. Insbesondere, wenn derartige Architekturen aufgrund der geografischen Verteilung der Data Sources entstehen, ist es üblich, dass auch auf den Spokes Information Delivery betrieben und an den Hub lediglich aggregierte Daten geliefert werden (weil regionales Reporting detailliertere Informationen benötigt als globales Reporting) [56]. 4 Praktische Umsetzung 4.1 Grundphilosophien In der Praxis werden BI-Systeme speziell an die Bedürfnisse des Unternehmens angepasst. Für das Data Warehouse gibt es verschiedene Umsetzungsvarianten. Dabei spielen vor allem Zugriffszeit, die Aktualität des Datenbestands und die Art der Daten eine gewichtige Rolle bei der Entscheidungsfindung. 4.1.1 DWH Umsetzungsvarianten Die Umsetzungsvarianten haben maßgeblichen Einfluss auf Aktualität der Daten und Zugriffszeit. 4.1.1.1 Klassisches Data Warehousing Bei der Umsetzung nach klassischem Data Warehousing werden die Daten in zeitlich wiederkehrenden Abständen und gebündelt transformiert. Dies kann zum Beispiel täglich, wöchentlich oder monatlich sein. Die Datenanalysesysteme nur lesend auf die Daten zugreifen ist eine hohe Datenkonsistenz gewährleistet. Typische Anwendungsbeispiele für den Einsatz des klassischen Data Warehousing sind Planungs- und Kontrollinstrumente mit kurz- bis mittelfristigem Entscheidungshorizont. Es sind bei dieser Umsetzungsvariante noch keine speziellen Optimierungen bezüglich der Aktionszeit berücksichtigt und sie kann daher als Referenz für eine Latenzzeitoptimierung genutzt werden[57]. 4.1.1.2 Closed-Loop Data Warehousing Beim Closed-Loop Data Warehousing werden die Ergebnisse der Analysesysteme direkt in die operativen und/oder dispositiven Systeme zurückgeschrieben. Dadurch wird eine inhaltliche Ergänzung der Datenbestände des Quellsystems erreicht, welche die weiteren Analysen beeinflussen können. Anwendungsgebiet für die Closed-Loop Variante ist vor allem das Customer Relationship Management. Hier werden operative und analytische CRM miteinander verbunden. Es wird z.B. möglich, Cross- oder Up-Selling Potenziale bei einem Kundenkontakt direkt aufzuzeigen indem die Ergebnisse eines Kundensegments nach Interessengebiet in das 4 Praktische Umsetzung 26 BI-Architektur_?_Konzepte_und_praktische_Umsetzung operative Customer Relationship Management System eingespeist wird. Vorteile dieses Ansatzes ist die Verringerung der Umsetzungslatenz durch bereits strukturierte Ergebnisse, die, wenn benötigt, direkt in die Zielsysteme zurück geschrieben werden können. Es entfällt eine manuelle Anpassung der Datenbankstrukturen[58]. 4.1.1.3 Real-Time Data Warehousing Beim Real-Time Data Warehousing wird der ETL-Prozess, der klassisch periodisch und batchorientiert ist, ganz oder teilweise in Echtzeit durchgeführt. Die Definition dieser Echtzeit ist eine vernachlässigbar geringe Latenzzeit (im Bereich zw. Millisekunden und Sekunden) zwischen dem erstmaligen Auftreten der Daten im operativen System und der anschließenden Verfügbarkeit im Data Warehouse. Ein einfaches Kopieren ist zur Erreichung dieses Ziels meist nicht ausreichend. Zumeist sind Transformationsprozesse und spezielle Optimierungen erforderlich. Ein typisches Beispiel für den Einsatz von Real-Time Data Warehousing ist der Wertpapierhandel. Hier ist es sehr wichtig, dass entscheidungsrelevante Informationen so schnell wie möglich zur Verfügung stehen[59]. 4.1.1.4 Active Data Warehousing »Die Grundidee des Active Data Warehousing ist eine weitere Operationalisierung des Data Warehouse und somit eine stärkere Unterstützung des Lower-Managements.« [60] In den meisten Fällen sind operative Entscheidungssituationen besser strukturiert als ihre strategischen Gegenparts. Dadurch können in bestimmten Anwendungsfällen bestimmte Aktionen teilweilse oder sogar vollständig automatisiert durchgeführt werden. Entscheidungen die ständig erneut getroffen werden müssen, können somit automatisiert gelöst werden. [61] »Zur Beschreibung dieses Sachverhalts dient das Event-Condition-Action-Modell (ECA model), das bereits seit längerem in aktiven Datenbanken in Form von Auslösern (trigger) umgesetzt wird.« [62] Eine Regel besteht aus drei Komponenten: 1. Am Anfang der Prozesse stehen Ereignisse (sog. events). Z.B. das Über- oder Unterschreiten von Schwellenwerten oder Verfügbarkeiten. 2. Darauf folgend optionale Prüfungen, ob bestimmte Zustände bestehen. Sind diese Zustände nicht erreicht, oder treffen nicht zu, so wird die Ausführung der Regel abgebrochen 3. Treffen die Zustände zu, so werden bestimmte Aktionen in die Wege geleitet. Darunter fällt z.B. die Durchführung von Transaktionen oder der Aufruf von externen Programmen[63]. Um diese klassischen ECA-Regeln für multidimensionale Analyseregeln konkret umsetzen zu können, ist es notwendig weitere Details zu bestimmen: • Was ist die primäre Ebene der Dimsensionshierarchie auf die sich die Regel bezieht? • Was sind die multidimensionalen Datenräume (Hypercubes), die für die Analyse verwendet werden? • Welche Entscheidungsschritte, in Form von Wenn-dann-Regeln, beschreiben den Entscheidungsprozess? • Welche weiteren Bedingungen müssen für die OLTP-Systeme erfüllt sein, damit automatisch Änderungen an ihnen vorgenommen werden können? [64] Active Data Warehousing unterstützt die Lösung komplexer Optimierungsprobleme. »Ein klassisches Logistikproblem ist beispielsweise die verspätete Lieferung einer Fracht, die für einen Anschlusstransport bestimmt ist. Es gilt nun abzuwägen, ob der Transport ohne diese Fracht startet oder auf sie wartet. In letzterem Fall kann sich eine andere Frachtlieferung verspäten. Die ideale Entscheidung berücksichtigt die einzelnen 4.1.1.2 Closed-Loop Data Warehousing 27 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Liefertermine, sowie die vereinbarten Service Levels und den Wert der Kunden für das Unternehmen. Darüber hinaus können noch alternative Routen, das aktuelle Wetter und weitere Faktoren eine Rolle spielen.«[65] Das Active Data Warehousing beinhaltet das Closed-Loop Verfahren. Es ist jedoch erweitert um eine aktive Entscheidungsgrundlage auf Basis von Analyseregeln[66]. 4.1.2 DWH Archetypen Archetypen sind Modellierungs- und Designansätze. Je nach Art der Daten und zugrundeliegender Implementierung können mehrere dieser Archetypen in Kombination auftreten[67]. 4.1.2.1 Archetyp Transaktionsorientiert Der Archetyp "Transaktionsorientiert" ist eine starke Anlehnung an das Star-Schema Modell. Die Daten aus den Quellsystemen (z.B. aus Buchungssystemen) sind in vordefinierte Fakten wie Mengen oder Umsätze eingeteilt. Die Dimensionen sind z.B. Produkte, Zeitperioden oder Stammdaten zu Kostenstellen und -arten und so weiter. Die Fakten werden zumeist mittels Addition über die Dimensionen aggregiert[68]. 4.1.2.2 Archetyp Workfloworientiert Beim Archetyp "Workfloworientiert" sind die Quellsysteme zumeist Workflow oder andere prozessunterstützende Systeme. »Diese liefern Status-/ Ereignis-Records und deren Zeitstempel, die sich auf bestimmte Vorgänge beziehen, z.B. die Abwicklung eines Auftrags. Aus den Statusübergängen werden Measures abgeleitet, zum Beispiel die Anzahl offener Aufträge.«[69] 4.1.2.3 Archetyp Stammdatenorientiert Beim Archetyp "Stammdatenorientiert" wird ganz oder teilweise auf Measures verzichtet. »DW-Lösungen können auch (fast) ganz ohne Measures auskommen. Sollen nur Stammdaten (Kunden,Verträge,Produkte etc.) verwaltet und für DW-Auswertungen bereitgestellt werden, ist es sinnvoll,die Daten von der normalisierten Repräsentation im operativen System zu einer denormalisierten Darstellung für das DW zu transformieren.«[70] Die Faktentabellen sind dann als sog. "factless fact tables" bezeichnet und definieren lediglich die Verknüpfung zwischen den Dimensionen[71]. 4.1.2.4 Archetyp Anwendungsspezifisch Beim Archetyp "Anwendungsspezifisch" implementiert das DWH die gleichen Aggregationen wie auch in den operativen Quellsystemen. Ein Anwendungsfall ist z.B. wenn die Quellsysteme der Deckungsbeitragsrechnung oder der Bilanzierung dienen. Dass sind Spezialregeln wie z.B. die Soll-Haben-Steuerung auch im DWH zwingend zu implementieren. »Kennzahldimensionen bilden Beziehungen zwischen diesen Measures ab. Abgesehen von derartigen Anwendungsspezifika gibt es viele Parallelen zum klassischen transaktionsorientierten DW.«[72] 4.1.1.4 Active Data Warehousing 28 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 4.2 Hersteller und Produkte Neben den großen IT-Softwareherstellern IBM, Oracle und SAP bieten auch viele kleine und mittelständische Unternehmen BI-Lösungen an. Dieses Kapitel bietet einen groben Überblick über die am Markt vorhandenen Lösungen und deren Relevanz. Ebenfalls wird kurz auf das Thema Open Source im BI-Umfeld eingegangen. 4.2.1 Marktübersicht Hersteller von BI-Lösungen Actuate GmbH¹ Antares Informations-Systeme GmbH¹ Arcplan Information Services GmbH¹ Bissantz & Company GmbH¹ Board Deutschland GmbH¹ CP Corporate Planning AG¹ Cubeware GmbH¹ Evidanza GmbH¹ IBM Corporation IDL Beratung für integrierte DV-Lösungen GmbH¹ Informatica GmbH¹ Information Builders Deutschland GmbH¹ Jaspersoft Corporation¹ Jedox AG¹ LucaNet AG¹ Microsoft MicroStrategy Deutschland GmbH¹ MIK GmbH¹ Oracle Corporation PmOne AG¹ Prevero AG¹ Prudsys AG¹ QlikTech GmbH¹ Rapid-I GmbH¹ SAP AG SAS Institute GmbH¹ STAS GmbH¹ Talend GmbH¹ Teradata GmbH¹ Thinking Networks AG¹ Tonbeller AG¹ Winterheller Software GmbH¹ ZetVisions AG¹ 4.2 Hersteller und Produkte Internetadresse www.actuate.com www.antares-is.de www.arcplan.de www.bissantz.de www.board.com www.cp.ag www.cubeware.de www.evidanza.de www.ibm.com www.idl.eu www.informatica.com www.informationbuilders.de www.jaspersoft.com www.jedox.com www.lucanet.com www.microsoft.com www.microstrategy.com www.mik.de www.oracle.com www.pmone.de www.prevero.com www.prudsys.de www.qlikview.de www.rapid-i.com www.sap.com www.sas.de www.stas.de www.talend.com www.teradata.com www.thinking-networks.de www.tonbeller.com www.winterheller.com www.zetvisions.de 29 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Tabelle 1 (Alle Angaben ohne Gewähr und Anspruch auf Vollständigkeit) Der Großteil der aufgelisteten Anbieter von BI-Lösungen wurde aus der Lünendonk®-Marktstichprobe 2011[73] übernommen (gekennzeichnet mit einer hochstehenden 1). In dieser Marktstichprobe wurden Anbieter von BI-Lösungen ausgewählt, deren Umsatz größtenteils durch das Anbieten und den Support/Weiterentwicklung von BI-Lösungen erzielt wird. ¹)[74] 4.2.2 Marktrelevanteste BI Lösungen Das von Gartner jährlich veröffentlichte Magic Quadrant (Abb. 18) zeigt, dass besonders die großen Anbieter am BI-Markt das größte Innovationspotential besitzen und die oberen Marktpositionen einnehmen. Dies bedeutet aber nicht zwangsläufig, dass kleinere Anbieter keine vernünftigen Lösungen anbieten[75]. Vor allem Anbieter von Open Source BI wie z.B Jaspersoft etablieren sich zunehmends am weltweiten BI Markt und bieten gute Alternativen zur großen Konkurrenz. In Anlehnung an: Sallam (2011) Abb. 18: Magic Quadrant 4.2.3 Open Source im BI Umfeld 4.2.3.1 Entwicklung Neben den großen Closed-Source Anbietern wie IBM, SAP und Oracle haben sich mittlerweile auch Anbieter von Open-Source BI-Lösungen am Markt etabliert. Besonders zu erwähnen, vor allem aufgrund der hohen Qualität ihrer Produkte, sind die Unternehmen Jedox, Jaspersoft und Pentaho. Dabei handelt es sich um die spezielle Form des Commercial Open Source. Das heißt, der Anbieter bietet eine kostenfreie und beliebig nutzbare "Community Version" als auch eine kostenpflichtige "Enterprise Version" an, die um diverse Features und Herstellersupport erweitert ist[76]. Die ersten Sichtbaren Anfänge nahm das Thema Open Source Software für Business Intelligence Anfang der 2000er Jahre. So wurde der Vorgänger des Produkts "RapidMiner" 2001 an der Technischen Universität entwickelt. Die Firma Jedox wurde 2002 gegründet und 2008 trat die Firma Jaspersoft in den deutschen Markt ein[77] Während Anbieter von Closed-Source BI-Software zumeist vollständig integrierte und umfassende BI-Suiten anbieten sind die Open-Source Anbieter auf einzelne Teilbereiche spezialisiert, wobei sich auch hier der Trend in Richtung des Angebots vollständiger Suiten entwickelt[78]. 4.2.1 Marktübersicht 30 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 4.2.3.2 Vor- und Nachteile Neben den klassischen Vor- und Nachteilen von Open Source Software gegenüber Closed-Source Software im Allgemeinen (darauf wird in dieser Fallstudie nicht näher eingegangen) lassen sich speziell im BI-Umfeld, insbesondere bei der Gegenüberstellung von Closed-Source BI gegenüber "commercial open source" BI, folgende Vor- und Nachteile identifizieren: Vorteile: • Freie Verfügbarkeit der BI-Software ♦ Die Software ist frei Verfügbar und kann z.B. über das Internet als Download bezogen und anschließend genutzt werden[79]. • Preisliche Attraktivität ♦ Die kommerzielle Version der Open-Source BI Software ist zumeist immer noch günstiger als die Angebote von Anbietern rein proprietärer BI-Lösungen[80]. • Bessere Anpass- und Integrierbarkeit ♦ Die Software kann vom Unternehmen selbstbestimmt angepasst bzw. erweitert werden und bietet, bedingt durch das mangelnde Komplettangebot, eine gute Integrierbarkeit in eine möglicherweise bereits bestehende BI-Umgebung[81]. Nachteile: • fehlendes Komplettangebot ♦ Im Open-Source Bereich gibt es noch keine vollständigen Suiten wie es im proprietären Bereich bereits seit längerem der Fall ist. Ein Unternehmen kann daher nicht vollständig auf Open Source aufbauen[82]. • unterschiedliche Aktivität der Open Source Community ♦ Open Source Software ist meist sehr erfolgreich wenn es eine große Community gibt, die die Software unterstützt. Im Bereich BI ist die Aktivität der Communities recht unterschiedlich. Dafür sind die Unternehmen sehr aktiv bei der Verbesserung ihrer Produkte. Dann ist es jedoch erforderlich den kommerziellen Support und die kommerzielle Version zu nutzen. Bei zu starker Eigenmodifikation der frei Verfügbaren Software sind Herstellerupdates eventuell nicht mehr auf die eigene Version anwendbar[83]. • Know-How Bedarf im eigenen Unternehmen ♦ Bei der Verwendung von Open Source BI liegt, wenn keine kommerziellen Zusatzservices in Anspruch genommen werden, die Verantwortung für Planung/Betrieb und Wartung beim Unternehmen selbst. Dieser Kostenfaktor muss ebenfalls einkalkuliert werden[84]. 4.2.3.3 Zukunft von Open Source im BI Umfeld Open Source BI-Lösungen haben sich als ernsthafte Alternative im weltweiten BI-Markt entwickelt. Von der Entwicklung von Lösungen in sehr speziellen Teilgebieten der BI lässt sich ein Trend in Richtung kompletter BI-Suiten erkennen[85]. Zwar gibt es am Markt noch immer keine Open Source BI-Suite aus einer Hand, sehr wohl ist es aber möglich unter Zusammenschaltung und Integration von Open Source BI-Lösungen mehrerer Anbieter eine sehr leistungs- und umfangsreiche BI-Umgebung aufzubauen. Es bietet sich für das DWH z.B. eine optimierte MySQL-Variante des Herstellers Greenplum an. Als ETL kann das Tool Octopus des Herstellers Enhydra verwendet werden und als Analysetools eignet sich z.B. die Datenbank Palo des Herstellers Jedox[86]. Open Source Lösungen sind vor allem für mittelständische Unternehmen und die öffentliche Hand interessant. Hohe Kosten für proprietäre Lösungen und der Bedarf nach hoher Individualisierbarkeit sind bei diesen Bedarfsträgern oft Gründe gegen eine toolgestützte BI[87]. Neueste Analysen wie die in Kap. 4.2.2 vorgestellte 4.2.3.2 Vor- und Nachteile 31 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Analyse von Gartner zeigen, dass sich Anbieter frei Verfügbarer BI-Lösungen bereits am Markt etablieren konnten und das Konzept aufgeht. Der Trend wird sich zukünftig fortsetzen. 4.3 Szenario: "Schoko GmbH" Um nachvollziehen zu können, wie die in dieser Fallstudie vorgestellten BI-Architekturkonzepte in der Praxis ineinander greifen und BI somit "erlebbar" machen, soll im Folgenden eine typische Systemimplementierung in einer fiktiven Firma dargestellt werden. 4.3.1 Ausgangssituation Die Schoko GmbH ist ein auf die Herstellung und Vermarktung von Schokoladenprodukten spezialisiertes mittelständisches und ausschließlich in Deutschland tätiges Unternehmen. Hauptabnehmer sind Discounter und Supermarktketten in ganz Deutschland, die die Produkte der Schoko GmbH in den Süßwarenbereichen weiterverkaufen. 4.3.2 Motivation und Zielsetzung Hinweisen der Vertriebsbelegschaft folgend, nach denen es starke regionale Unterschiede im Absatz der verschiedenen von der Schoko GmbH feilgebotenen Produkte gibt, möchte das Management regional aggregierte Auswertungen des Absatzes der letzten Jahre vorgelegt bekommen und beauftragt das Marketing mit dieser Aufgabe. Die Verfügbarkeit der Daten innerhalb des Unternehmens stellt sich allerdings als völlig unzureichend heraus, und so entscheidet man sich nach intensiver Diskussion mit dem Management für die Einführung eines BI-Systems um diese und künftige Anfragen des Managements beantworten zu können. 4.3.3 Lösungskonzept Nach einer intensiven Marktanalyse unter Zuhilfenahme externer IT-Berater wurde sich aus Kostengründen für eine kommerzielle open source BI-Lösung entschieden. Die Anforderungen des Managements sind nicht spezieller branchenspezifischer Natur und so ist auch der Funktionsumfang der open-source Lösung ausreichend. Aufgrund fehlenden internen Know-How's wurde eine externe Firma mit der Einführung sowie dem anschließenden Support der Software beauftragt. Da die Software in dem Unternehmen neu eingeführt wird, prüft die externe Firma zunächst die vorhandenen operativen Systeme und schafft die notwendigen Schnittstellen für die Befüllung des zentralen Datenspeichers, des DWH. Auf diese Weise konnten die operativen Systeme der Bereiche Produktion, Marketing und Vertrieb erfolgreich an das DWH angebunden werden. Bei der Speicherung der Daten entschied sich die externe Firma für eine R-OLAP Datenhaltung und zum Zwecke der periodischen Beladung wurden die entsprechenden ETL-Programme implementiert und in den Einsatz übergeben. Erstmalig sind die Kenndaten der einzelnen Bereiche der Schoko GmbH an einer zentralen Stelle gespeichert. Anschließend implementiert und konfiguriert die externe Firma die Analysetools mit denen, auf den Daten des DWH aufbauend, für den Endanwender grafisch Aussagekräftige Reports erstellt werden können und baut ein Rechtekonzept auf, um den verschiedenen Bereichen und dem Management differenzierten Zugriff auf die Analysetools zu gewähren und führt Schulungen durch. 4.2.3.3 Zukunft von Open Source im BI Umfeld 32 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 4.3.4 Entwicklung und Betrieb Die Schoko GmbH ist mit dem Standardumfang und der Konfigurierbarkeit der ausgewählten BI-Lösung zufrieden und hat keinen Bedarf an eigener Weiterentwicklung der Software. Es wurde ein Wartungsvertrag mit einer externen Firma abgeschlossen und durch den Verzicht auf eigene Entwicklung bleibt die open-source Lösung standard-upgrade fähig. Es wurde eine separierte Abteilung gegründet, die in Absprache mit den weiteren Bereichen und der externen Firma die Entwicklung und Erweiterung der Analysen und Reports steuert und vornimmt. 4.3.5 Abschließende Bemerkungen Durch die Einführung der BI-Lösung konnte das Management herausfinden, dass weiße Schokolade im Westen Deutschlands besonders beliebt ist. Die Einführung wird vom Management und der Belegschaft als ein Erfolg wahrgenommen. Die Mitarbeiter, die vormals ohne BI-Unterstützung die Anfragen des Managements erfüllen mussten bestätigen, dass sie wesentlich entlastet werden und in kürzerer Zeit qualitativ anspruchsvollere Ergebnisse präsentieren können. 5 Fazit Ziel der Business Intelligence ist es, durch integrierte IT Systeme die Menschen in den betriebswirtschaftlichen Prozessen optimal bei ihren Entscheidungen zu unterstützen. Damit dieses Ziel effektiv erreicht werden kann, bedarf es nicht nur einer individuellen Abstimmung auf das Unternehmen in allen Bereichen, sondern auch einer Anpassung an die Unternehmen Strategien auf höchster Ebene. Im Bereich der modernen Business Intelligence gibt es eine Vielzahl von individuell anpassbaren Konzepten, die sich gut wie nie zuvor an die Anforderungen betriebswirtschaftlicher Gegebenheiten anpassen lassen. Dennoch scheitern viele BI-Projekte, da es keinen Königsweg gibt, durch den sich die Potenziale mit dem bloßen Glauben an die Technik entfalten. Die unterschiedlichen Vertreter der Fachseiten platzieren nach einer Art ?Botton Up? Prinzip Anforderungen der für ihren Bereich relevanten Ziele. Dies kann zu einer falschen Richtung in der grundsätzlichen Konzeption der BI-Systeme führen, welche die zukünftigen Anforderungen nahezu unbezahlbar machen können. Die grundsätzlichen Anforderungen an die Business Intelligence müssen in Anlehnung an die langfristigen unternehmerischen Strategien, durch das Topmanagement geplant, platziert und durch entsprechende Zielvorgaben autorisiert werden. Für die erfolgreiche Umsetzung bedarf es einer Bündelung aller BI-relevanten Themen und einer permanenten Kooperation zwischen IT und den Fachbereichen. In dieser Fallstudie wurden zum einen die theoretischen Konzepte der modernen Business Intelligence beleuchtet und zum andern eine Überführung dieser Konzepte in praktisches Anwenden unternommen. Es hat sich herausgestellt, dass Business Intelligence ein sehr großes Thema ist was zu einer gewissen Unschärfe der Begriffsdefinition führt. Der Begriff ist sehr weit gefasst und viele Konzepte und Begrifflichkeiten der BI sind angepasst an die jeweilige Branche bzw. Nische, sodass hier ebenfalls eine Herausforderung bestand, herauszuarbeiten welche Konzepte "BI-typisch" und welche "Nischen-speziell" waren. Es wurden die typischsten Begrifflichkeiten und Funktionalitäten moderner BI-Systeme vorgestellt und in einem Kapitel zur praktischen Anwendung demonstriert. 4.3.4 Entwicklung und Betrieb 33 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 6 Abbildungsverzeichnis Abb. 1 Abb. 2 Abb. 3 Abb. 4 Abb. 5 Abb. 6 Abb. 7 Abb. 8 Abb. 9 Abb. 10 Abb. 11 Abb. 12 Abb. 13 Abb. 14 Abb. 15 Abb. 16 Abb. 17 Abb. 18 BI Framework Auswertung Fact Fachlicher Stern Fachlicher Cube Fachliche Modellierung BI Referenz Architektur Harmonisierung Datenstruktur nach Star-Schema Eigenschaftsprofile von operativen, Operational-Data-Store- und Data-Warehouse-Systemen Cube im multidimensionalem Datenraum Cube-Rotation im multidimensionalem Datenraum R-OLAP, M-OLAP und H-OLAP Zentrales DWH Distributed DWH Replizierende Hub&Spoke Architektur Aggregierende Hub&Spoke Architektur Magic Quadrant 7 Tabellenverzeichnis 1 Marktübersicht - Tabelle 8 Fußnoten 1. ? Vgl. Luhn (1958), Passim 2. ? Vgl. Power (2007), Passim 3. ? Vgl. Zimmermann (2008), Passim 4. ? Vgl. Mehrwald (2007), Seite 50 5. ? Vgl. Mehrwald (2007), Seite 50 f. 6. ? Vgl. Mehrwald (2007), Seite 2 7. ? Vgl. Mehrwald (2007), Seite 47 8. ? "The Unified Modeling Language? - UML - is OMG's most-used specification, and the way the world models not only application structure, behavior, and architecture, but also business process and data structure." übersetzt von Tobias Wäschle, nach Object Management Group (OMG) http://www.uml.org 9. ? Vgl. Humm (2005), Seite 5 10. ? Vgl. Humm (2005), Seite 5 11. ? Zeh (2003), Seite 36 12. ? Kemper (2006), Seite 24 13. ? Vgl. Kemper (2006), Seite 26 f. 14. ? Vgl. Kemper (2006), Seite 27 f. 15. ? Vgl. Kemper (2006), Seite 31 f. 16. ? Vgl. Mehrwald (2007), Seite 51 6 Abbildungsverzeichnis 34 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 17. ? Vgl. Kemper (2006), Seite 61 ff. 18. ? Vgl. Mehrwald (2007), Seite 53 f. 19. ? Vgl. Kemper (2006), Seite 64 f. 20. ? Vgl. Mehrwald (2007), Seite 55 f. 21. ? Vgl. Kemper (2006), Seite 100 22. ? Vgl. Kemper (2006), Seite 32 f. 23. ? Vgl. Herden 2004, Seite 52 f. 24. ? Vgl. Kurz 1999, Seite 110 f. 25. ? Vgl. Kurz 1999, Seite 110 f. 26. ? Vgl. Humm (2005), Seite 9 27. ? Vgl. Kemper 2006, Seite 38 f. 28. ? Vgl. Inmon 1999, Seite 12 ff. 29. ? Vgl. Kemper (2006), Seite 79 30. ? Vgl. Kemper (2006), Seite 91-93 31. ? Vgl. Kemper (2006), Seite 91-93 32. ? Vgl. Kemper (2006), Seite 91-93 33. ? Vgl. Codd et al. 1993, S.87 ff. 34. ? Vgl. Kemper (2006), Seite 93-101 35. ? Vgl. Kemper (2006), Seite 93-101 36. ? Vgl. Kemper (2006), Seite 93-101 37. ? Vgl. Kemper (2006), Seite 93-101 38. ? Vgl. Kemper (2006), Seite 93-101 39. ? Vgl. Kemper (2006), Seite 93-101 40. ? Vgl. Kemper (2006), Seite 93-101 41. ? Bissantz (2000), Seite 380 42. ? Vgl. Kemper (2006), Seite 106-109 43. ? Vgl. Kemper (2006), 106-109 44. ? Vgl. Bachmann (2011), Seite 107 ff. 45. ? Vgl. Bachmann (2011), Seite 107 ff. 46. ? Vgl. Bachmann (2011), Seite 109 f. 47. ? Vgl. Bachmann (2011), Seite 109 f. 48. ? Vgl. Bachmann (2011), Seite 110 49. ? Vgl. Bachmann (2011), Seite 94 50. ? Vgl. Bachmann (2011), Seite 94 51. ? Vgl. Bachmann (2011), Seite 95 52. ? Vgl. Bachmann (2011), Seite 95 53. ? Vgl. Bachmann (2011), Seite 95 f. 54. ? Vgl. Bachmann (2011), Seite 95 f. 55. ? Vgl. Mehrwald (2007), Seite 601-605 56. ? Vgl. Mehrwald (2007), Seite 601-605 57. ? Vgl. Kemper (2006), Seite 86 f. 58. ? Vgl. Kemper (2006), Seite 87 59. ? Vgl. Kemper (2006), Seite 87 f. 60. ? Brobst (2001), Seite 41 61. ? Vgl. Kemper (2006), Seite 88 f. 62. ? Elmasri (2007), Seite 825 63. ? Vgl. Kemper (2006), Seite 88 f. 64. ? Vgl. Thalhammer (2001), Seite 248 65. ? Brobst (2001), Seite 41 66. ? Vgl. Kemper (2006), Seite 88 f. 67. ? Vgl. Humm (2005), Seite 11 f. 8 Fußnoten 35 BI-Architektur_?_Konzepte_und_praktische_Umsetzung 68. ? Humm (2005), Seite 11 69. ? Humm (2005), Seite 11 f. 70. ? Humm (2005), Seite 12 71. ? Vgl. Humm (2005), Seite 12 72. ? Humm (2005), Seite 12 73. ? Vgl. Zillmann (2011) S.6 74. ? Vgl. Zillmann (2011) S.6 75. ? Vgl. Sallam (2011) S.1 76. ? Vgl. Güclü (2010), Passim 77. ? Vgl. Bange(2010), Passim 78. ? Vgl. Kleijn (2006), Passim 79. ? Vgl. Bange(2010), Passim 80. ? Vgl. Bange(2010), Passim 81. ? Vgl. Bange(2010), Passim 82. ? Vgl. Bange(2010), Passim 83. ? Vgl. Bange(2010), Passim 84. ? Vgl. Bange(2010), Passim 85. ? Vgl. Kleijn (2006), Passim 86. ? Vgl. Kleijn (2006), Passim 87. ? Vgl. Güclü (2010), Passim 9 Literatur- und Quellenverzeichnis Bachmann (2011) Bachmann, R, Kemper, G: Raus aus der BI-Falle - Wie Business Intelligence zum Erfolg wird, mitp, Heide Bange(2010) Carsten Bange, Patrick Keller, 'Marktphänomen Open-Source-BI ? ernst zu nehmende Alternative zu traditi http://www.beyenetwork.de/view/14758 (01.01.2012 18:16) Bissantz (2000) Brobst (2001) Codd (1993) Elmasri (2007) Güclü (2010) Herden (2004) Humm (2005) Inmon (1999) Kemper (2006) Kleijn (2006) Kurz (1999) Luhn (1958) Bissantz, N., Hagedorn, J. und Mertens, P.: Data Mining, in: Mucksch, H. und Behme, W. Hrsg.,Das Data W Brobst, S. and J. Rarey, P., "Active data warehouses: complementing OLAP with analysis rules", in: Data & Codd, E.F., Codd, S.B. und Salley, C.T.: Beyond Decision Support, in: Computerworld, Vol. 27, 1993, Issu Elmasri, R. und Navathe, S., Fundamentals of Database Systems, 5. Auflage, Boston, San Francisco et al. 2 Ilkem Güclü, Stefan Müller, 'Business Intelligence mit Open Source: Vergleich der BI-Lösungen Jaspersoft http://t3n.de/magazin/vergleich-bi-losungen-jaspersoft-jedox-palo-pentaho-224644/ (01.01.2012 18:03) Herden, O.: 'Basisdatenbank' in: Bauer, A. und Günzel, H. (Hrsg.), Data-Warehouse-Systeme: Architektur, Humm, Bernhard & Wietek, Frank: 'Architektur von Data Warehouses und Business Intelligence Systemen Inmon, W.H., Building the Operational Data Store, 2. Auflage, New York, Chichester et al. 1999 Kemper, H, Unger, C & Mehanna, W, Business intelligence - Grundlagen und praktische Anwendungen. Ei Alexandra Kleijn, 'Business Intelligence mit Open Source', www.heise.de, World Wide Web http://www.heise.de/open/artikel/Business-Intelligence-mit-Open-Source-221947.html (01.01.2012 18:17) Kurz, A., Data Warehousing Enabling Technology, Bonn, 1999 Luhn, H.P.: 'A Business Intelligence System'. in: "Journal of Research and Development", 1958, von IBM ( Mehrwald, C, Datawarehousing mit SAP BW 7. BI in SAP NetWeaver 2004s ; Architektur, Konzeption, Im 9 Literatur- und Quellenverzeichnis 36 BI-Architektur_?_Konzepte_und_praktische_Umsetzung Mehrwald (2007) Power, D.J. A Brief History of Decision Support Systems. DSSResources.COM, World Wide Web http://DSSResources.COM/history/dsshistory.html, version 4.0, March 10, 2007. (01.01.2012 16:43) Sallam, Richardson, Hagerty, Hostmann, 'Magic Quadrant for Business Intelligence Platforms', Gartner RA Sallam (2011) http://www.board.com/download/press/EN/Gartner_BI_MagicQuadrant_2011.pdf (01.01.2012 17:02) Thalhammer Thalhammer, T., Schrefl, M. und Mohania, M.: "Active data warehouses: complementing OLAP with analy (2001) von Maur von Maur, E., Schelp, J. und Winter, R.: "Integrierte Infor-mationslogistik ? Stand und Entwicklungstenden (2003) Zeh (2003) Zeh, Thomas: "Data Warehousing als Organisationskonzept des Datenmanagements", in: Informatik - Forsc Zimmermann Zimmermann, M.: "Grundlagenserie Business Intelligence Business Intelligence (Teil 1)": Erster Einstieg. w (2008) http://www.tecchannel.de/server/sql/1738998/business_intelligence_teil_1_erster_einstieg/index.html (01.0 Zillmann, M., Lünendonk®-Marktstichprobe 2011, Lünendonk GmbH, www.luenendonk.de Zillmann http://luenendonk-shop.de/Luenendonk-Studien/Luenendonk-Marktsegment-und-Trendstudien/2011/Luene (2011) (14.01.2012 20:53) Power (2007) 9 Literatur- und Quellenverzeichnis 37
