Realisierung eines Management Cockpits mit Microsoft Business Intelligence

Inhaltsverzeichnis

Abstract / verwendete Technologien

1 Einleitung
1.1 Vorgehensweise bei der Erstellung
1.2 Einführung in das Thema
1.3 Definition „Management Cockpit“

2 Grundlagen Management und Controlling
2.1 Controlling
2.1.1 Systembildende und systemkoppelnde Koordinationsaufgaben
2.1.2 Planungsaufgaben
2.1.3 Steuerungsaufgaben
2.1.4 Informations- und Dienstleistungsaufgaben
2.2 Verhältnis Controlling-Management

3 Analyse des Unternehmens
3.1 Firmenleitbild
3.2 Firmenziel
3.3 Firmenkennzahlen
3.4 Einsatz der Balanced Scorecard

4 Grundlagen Business Intelligence
4.1 Ziele von Business Intelligence
4.1.1 Optimierung der Entscheidungsgrundlagen
4.1.2 Erhöhung der Transparenz
4.1.3 Kontextbildung zwischen isolierten Informationen
4.2 Voraussetzungen für Business Intelligence
4.2.1 Bereitschaft Dinge in Frage zu stellen
4.2.2 Bereitschaft unkonventionell zu denken
4.2.3 Management Attention
4.2.4 Datenqualität
4.2.5 Datenmenge
4.2.6 Datenstruktur
4.3 Data Warehouse
4.3.1 Indirekter Zugriff auf die OLTP Daten des ERP Systems
4.3.2 Integration verteilter Datenbestände
4.3.3 Datenkonsolidierung- und aggregierung
4.4 OLAP
4.4.1 Dimensionen
4.4.2 Hierarchien
4.4.3 Measures
4.4.4 Cubes
4.4.5 Dimensions- und Faktentabellen
4.4.6 Speicherkonzepte
4.5 Data Mining
4.5.1 Assoziationen
4.5.2 Progressionsverfahren
4.6 Data Mining Methoden von Microsoft BI

5 Grundlagen SQL Server 2005 mit BI - Komponenten
5.1 Analysis Services
5.2 Integration Services
5.3 Reporting Services
5.4 Unified Dimension Model
5.5 SQL Server Management Studio
5.6 Business Intelligence Development Studio

6 Analyse Datenmodell

7 Datenmodellierung und Datenintegration

7.1 Importieren der AdventureWorksDW Datenbank
7.2 Modellierung der Daten für SSAS
7.2.1 Anlegen des Projekts
7.2.2 Anlegen der Datenquelle
7.2.3 Anlegen der Datenquellansicht
7.2.4 Anlegen der Cubes
7.3 Modellierung der Daten für SSIS
7.3.1 Anlegen des Projekts
7.3.2 SSIS Paket anlegen
7.3.3 SSIS Paket mit SQL Server Agent ausführen

8 Realisierung Management Cockpit
8.1 Einleitung
8.2 Installierte Komponenten
8.3 Anforderungen an das Management Cockpit
8.4 Installation der einzelnen Komponenten
8.4.1 VMWare Client
8.4.2 Microsoft Windows Server 2003 R2
8.4.3 Microsoft SQL Server 2005 / Serverkomponenten
8.4.4 Microsoft SQL Server 2005 / Clientkomponenten
8.4.5 Installation des Microsoft .NET Framework 3.0
8.4.6 Installation von Microsoft SharePoint Server Enterprise
8.4.7 Konfiguration der Internet Infomation Services
8.4.8 Installation des Reporting Server Add-In für SharePoint
8.4.9 Installation SharePoint Designer
8.4.10 Installation des Business Scorecard Servers
8.4.11 Installation des Business Scorecard Builders
8.4.12 Installation des MS Excel Add - In für SharePoint
8.4.13 Installation Plugin Excel Data Mining
8.5 Abschluss der Installation
8.6 Realisierung des Cockpits
8.6.1 Vorbereitungen in SharePoint
8.6.2 Erstellen der statischen Reports in MS Excel
8.7 Erstellen der dynamischen Reports in Excel
8.8 Erstellen der Balanced Scorecard und des Dashboards
8.8.1 Innovationssicht der Balanced Scorecard
8.8.2 Prozesssicht der Balanced Scorecard
8.8.3 Kundensicht der Balanced Scorecard
8.8.4 Finanzsicht der Balanced Scorecard
8.8.5 Dashboard
8.9 Erstellen und Bearbeiten einzelner SharePoint Seiten
8.10 Einbinden einzelner SharePoint Seiten

9 Benutzerhandbuch für das Management Cockpit
9.1 Benutzung der beiden Anwendungsrechner
9.2 Benutzung des Beamers
9.3 Benutzung der Monitore
9.4 Benutzung des Smartboards

10 Showcase
10.1 Intention des Showcase
10.2 Aufbau des Showcase
10.3 Die Belegung der statischen Monitore
10.4 Die Belegung der dynamischen Monitore
10.5 Die Management Sitzung
10.5.1 Eröffnung
10.5.2 Die Finanzsicht der BSC
10.5.3 Die Prozesssicht der BSC
10.5.4 Marketingstudie Internet
10.5.5 Data Mining
10.5.6 Die Innovationssicht der BSC
10.5.7 Die Kundensicht der BSC
10.5.8 Das dynamische Reporting
10.5.9 Das Telefonat mit Mr. Jiang
10.5.10 Das Ergebnis der Sitzung

11 Resümee

12 Anhang
12.1 Skript der SSIS Skriptkomponente
12.2 Projektplan

Quellenverzeichnis

Abbildungsverzeichnis

Abstract / verwendete Technologien

Inhalt dieser Bachelor - Thesis ist die technische Realisierung eines Management Cockpits mit Microsoft Business Intelligence Komponenten zur Steuerung eines fiktiven Unternehmens. Einer kurzen Einführung in die Problematik des „Informationsnotstandes im Management“, folgt die schrittweise Realisierung einer Entscheidungsplattform für Führungskräfte. Diese bietet unter Zuhilfenahme von Kennzahlen, auf Basis der Balanced Scorecard, eine breit gefächerte Palette von Werkzeugen für das Management. Dokumentiert wurden die informationstechnischen sowie betriebswirtschaftlichen Komponenten und Vorgehensweisen. Besondere Aufmerksamkeit wurde dem dynamischen Arbeiten mit Cubes und Data Mining geschenkt.

Abstract in English

Subject of our bachelor thesis was to realize a management cockpit using the components of Microsoft Business Intelligence. The cockpit had to be capable of leading a virtual company. Prior to realising the decision support platform for executive managers, we will give a short introduction into the key problem of modern management. The “Lack of Information”. Our platform uses Measures and Indicators based on a Balanced Scorecard, further it offers numerous tools for leading a company. We both documented the deployed components and our approach. Special attention was payed to dynamic work with OLAP Cubes and Data Mining.

Verwendete bzw. beschriebe Technologien

Das Dokument wurde mit folgenden Werkzeugen erstellt:

- Microsoft Windows XP SP3 (Betriebssystem)
- Microsoft Office Word 2003 (Texterfassung)
- Microsoft Office Excel 2003 (Tabellenkalkulation / Diagramme)
- Microsoft Office Access 2003 (Datenbanken)
- Microsoft Office Project 2007 (Projektplanung)
- Snapshot Tool (BlueShot)

Bei der Umsetzung des Management Cockpits wurde folgenden Software eingesetzt:

- VMWare 2.5.0
- Windows Server 2003 R2
- Microsoft Internet Information Services
- SQL Server 2005 SP2
- SQL Server Client Components
- Visual Studio 2005 SP2
- SQL Server Management Studio
- .NET Framework 3.0
- SQL Server Analysis Services
- SQL Server Reporting Services
- Business Scorecard Server
- Business Scorecard Builder
- SharePoint Portal Server 2007
- SharePoint Designer 2007
- Office 2007
- Diverse Updates und PlugIns

Einleitung

1.1 Vorgehensweise bei der Erstellung

Im Folgenden wird die Vorgehensweise zur Erstellung der Thesis:

„Realisierung eines Management Cockpits mit Microsoft Business Intelligence“ beschrieben:

Das fiktive Microsoft Beispielunternehmen „AdventureWorks“ soll mit Hilfe des Microsoft SQL Server 2005, Microsoft Visual Studio 2005 und den dazugehörigen Business Intelligence Komponenten in einem Management Cockpit abgebildet werden. Das Management Cockpit wurde an der Reutlingen University als Labor aufgebaut und steht Studenten im Rahmen von Projekten und Abschlussarbeiten zur Verfügung.

Ziel ist es einen „Showcase“ zu erstellen, der mit Hilfe der oben genannten Komponenten, die Unternehmensdaten sammelt, aufbereitet, aggregiert und zur Entscheidungsfindung zur Verfügung stellt.

Vorgegangen wird in folgenden Schritten:

- Theoretische Einarbeitung
- Einarbeitung in die Laborumgebung
- Erstellung der Datenbasis
- Aufbau und Realisierung des Management Cockpits

Im ersten Schritt werden wir uns mit der theoretischen Einarbeitung befassen, insbesondere den betriebswirtschaftlichen Hintergrund beleuchten und uns generell mit der Problematik des „Informationsnotstands des Managements“ befassen. Auch das fiktive Unternehmen „Adventure Works“ wird von uns eingehend betrachtet und analysiert. Im zweiten Schritt machen wir uns mit der Laborumgebung vertraut. Hier sind bereits Anleitungen und Dokumentationen aus vorangegangenen Thesen verfügbar und erleichtern die Einarbeitung.

Anschließend erstellen wir unsere Datengrundlage. Als Basis dient ein bereits bestehendes Datenmodell inklusive Stammdaten. Dabei handelt es sich um das Datenmodell eines fiktiven von Microsoft entwickelten Unternehmens. Es wird an unsere Bedürfnisse und Wünsche angepasst um die gewünschte Funktionalität zur Verfügung stellen zu können.

Als letzter Schritt folgt die Realisierung des Management Cockpits. Der Server mit all seinen Komponenten wird auf einer virtuellen Maschine realisiert und eingerichtet.

Datencubes werden erstellt und eine Oberfläche für die Anwendung geschaffen. Ein Vorführszenario wird erdacht und ein Drehbuch dafür geschrieben.

Parallel zu allen Schritten ist es uns wichtig, die betriebswirtschaftlichen Prozesse dahinter zu verstehen, zu analysieren und in unserem Projekt wiederzugeben.

Sehr wichtig ist für uns bei dem Projekt, die vollständige Umsetzung aller einzelnen Teilprozesse und deren Abhängigkeiten, um mit dem erworbenen Wissen Anwendungen wie diese, auch in realen Unternehmen umsetzen zu können.

1.2 Einführung in das Thema

Bevor das Zeitalter des Internet angebrochen war, hatten Märkte und die dazugehörigen Unternehmen viel Zeit um auf Veränderungen zu reagieren. Kommunikationswege waren lang und detaillierte Informationen waren schwierig und aufwändig zu beschaffen. Eines der wichtigsten Instrumente für Unternehmen war lange Zeit die Meinungsumfrage. Kunden, beziehungsweise potenzielle Kunden wurden zu den Unternehmen und den einzelnen Produkten befragt. Diese Befragungen wurden ausgewertet, Rückschlüsse gezogen und Veränderungen vorgenommen.

Mit der Einführung der elektronischen Kommunikation, speziell des Internets, wurden diese Verfahren nach und nach abgelöst. Die Märkte wuchsen schneller zusammen. Das vom Internet bereitgestellte Wissen und die Möglichkeit, international nahezu in Echtzeit zu kommunizieren hatten zur Folge, dass die Märkte immer globaler wurden. Um weiterhin unter diesen Bedingungen am Markt bestehen zu können, mussten viele Unternehmen umdenken. Der Einsatz von Computern im Unternehmen, deren Vernetzung untereinander und deren Anschluss ans Internet verschafften vielen Unternehmen einen Wettbewerbsvorteil. Das Softwareangebot für die einzelnen Unternehmensbereiche wuchs parallel mit. Immer größere Anwendungen, mit immer mehr Funktionen lösten nach und nach kleinere „Insellösungen“ ab. Grundsätzlich werden heute fast alle Unternehmensprozesse digital abgebildet. Die Kehrseite dieser Entwicklung ist ein wachsendes Datenaufkommen, welches die Informationsverarbeitung immer aufwändiger gestaltet.

Um in heutigen Märkten auch langfristig erfolgreich zu sein, ist die Verfolgung einer gezielten Strategie genauso Pflicht wie deren praktische Umsetzung im Unternehmensalltag.

Während IT-Systeme den Alltag von operativen Einheiten schon vereinfachen, bleibt diese Hilfe bei strategierelevanten Fragen meist aus. Zwar steht dem Management schon heute eine große Anzahl an Daten zur Verfügung, doch sind diese oft unaufbereitet und wenig aussagekräftig. An dieser Stelle wird von „Informationsknappheit im Management“ gesprochen. Erst eine mehrfache Selektion und Aggregation der Daten kann die verdichtete Information transportieren, die benötigt wird um strategierelevante Entscheidungen treffen zu können.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Informationsfokussierung

1.3 Definition „Management Cockpit“

Ein Management Cockpit (auch IT-Dashboard oder Cockpit-Chart) ist eine Visualisierungsform großer Mengen meist verteilter Informationen in verdichteter Form, z. B. als Kennzahlen, Messpunkte oder Key Performance Indikatoren (KPI). Der Grad sowie die Visualisierungsform der Verdichtung ist ziel- und adressatenabhängig. Die Verdichtung beinhaltet eine Quantifizierung und darauf aufbauend eine Qualifizierung von Informationen, um dem Adressaten große Mengen von Informationen übersichtlicher darzustellen. Häufig zu finden ist die Darstellung von Kennzahlen als Ampel, Tachometer- oder Thermometer-Darstellung.

Ein Management Cockpit ist somit die technische Umsetzung eines Kennzahlensystems. Management Cockpits können als eigenständiges Informationssystem oder als Bestandteil eines Management- Informationssystems bzw. eines Data Warehouses realisiert werden.

Eine besondere Form des Management Cockpits stellt die Realisierung einer Balanced-Scorecard zur Unternehmenssteuerung dar.¹

Technisch umgesetzt wurde das Cockpit, wie bereits eingangs erwähnt, in Laborform an der Reutlingen University.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Management Cockpit Labor der Hochschule Reutlingen

Technischer Aufbau:

- Modularer Aufbau nach dem Baukastenprinzip
- Realisiert als leicht ab- und aufbaubarer Messestand

Visualisierung:

- Beamer für Smartboard SHARP PG-320X
- Smartboard 94 ¼ Zoll Diagonale, Touchscreenfunktion, digital ink Funktion
- 12 Monitore Phillips BDL 4231C, WXGA Breitbild 1366x768, hdmi

Computer:

- 2 PCs mit Core2Duo Prozessor Computer
- 2 x Matrox QID 128MB PCI-E LowProfil -> 8 x DVI Grafikkarten

Peripherie:

- Für Videokonferenzen: Logitech Quick Cam Ultra Vision
- Polycom Communicator C100S Tischmikrofon

Backbone:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Backbone²

Grundlagen Management und Controlling

2.1 Controlling

Unter dem Begriff Controlling fasst man alle Maßnahmen zusammen, die der Koordination der Führungssysteme, Planung, Kontrolle, Organisation, Personalwirtschaft und Informationswirtschaft dienen. Koordination bezeichnet dabei das Abstimmen einzelner Entscheidungen auf das Unternehmensziel hin.³

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Controlling

Die Hauptaufgaben des Controllings sind:

2.1.1 Systembildende und systemkoppelnde Koordinationsaufgaben

Systembildende Koordination bedeutet, ein funktionsfähiges Planungs- und Kontrollsystem bzw. Informationssystem bereitzustellen sowie laufende Gestaltungs-, Anpassungs- und Abstimmungsaufgaben innerhalb dieser Teilbereiche vorzunehmen und anzupassen. Mit systemkoppelnder Koordination ist die Abstimmung zwischen den Teilsystemen gemeint. Das heißt insbesondere die Deckung des Informationsbedarfs von Planungs- und Steuerungsprozessen durch das Rechnungswesen und durch das Berichtswesen.

2.1.2 Planungsaufgaben

Gemeinsam mit der Führungsebene ist der Controller am Zielbildungsprozess beteiligt. Er führt die Teilziele der Bereiche zu einem ganzheitlichen und abgestimmten Zielsystem zusammen.

2.1.3 Steuerungsaufgaben

Die Überwachung des systematischen Geschäftsverlaufs obliegt dem Controller. Anhand definierter Sollgrößen vergleicht er die Istgrößen und greift mit definierten Maßnahmen vorbeugend oder nachwirkend ein.

2.1.4 Informations- und Dienstleistungsaufgaben

Eine weitere Aufgabe des Controlling ist es, Daten und Informationen zu sammeln und in aufbereiteter Form dem Management zur Verfügung zu stellen. Das Berichtswesen kann bis hin zu einem Führungs- informationssystem (FIS) ausgebaut werden.

2.2 Verhältnis Controlling-Management

Während der Controller Transparenzverantwortlicher als „Lotse zum Gewinn“ ist und verschiedene Services anbieten muss, ist der Manager ergebnisverantwortlich. Das heißt, er muss eine Strategie für das Unternehmen erarbeiten und darauf achten, dass diese auch umgesetzt wird. Die Ausrichtung eines Unternehmens ist mit Entscheidungen verbunden. Jede dieser Entscheidungen beruht auf einer ungesicherten Prognose. Hauptgrund hierfür ist die Zukunftsorientierung einer Entscheidung. Je weiter der betrachtete Zeitraum in der Zukunft liegt, desto größer ist die Gefahr einer Fehlentscheidung. Aufgabe des Controllers ist es nun eine geeignete Entscheidungsbasis zu schaffen um Unsicherheit abzubauen.

Im Hinblick auf diese Strategieentwicklung stellt der Controller eine Vielzahl an Werkzeugen zur Verfügung.

Analyse des Unternehmens

An dieser Stelle betrachten wir die Ausgangssituation für die nachfolgenden Arbeiten. Das fiktive Unternehmen wird zunächst beschrieben, anschließend analysiert und zuletzt werden strategische Ziele abgeleitet.

„Adventure Works Cycles, das fiktive Unternehmen, auf dem die AdventureWorks-Beispieldatenbanken basieren, ist ein großes, multinationales Produktionsunternehmen. Das Unternehmen fertigt und verkauft Fahrräder aus Metall und Verbundwerkstoffen auf dem nordamerikanischen, europäischen und asiatischen Markt. Der Hauptsitz befindet sich mit 290 Mitarbeitern in Bothell, Washington, während mehrere regionale Vertriebsteams über die Zielmärkte hinweg verteilt sind.

Im Jahr 2000 erwarb Adventure Works Cycles eine kleine Produktionsstätte namens „Importadores Neptuno“ in Mexiko. „Importadores Neptuno“ stellt wichtige Bauteile für die Produktpalette von Adventure Works Cycles her. Diese Bauteile werden zur Endmontage an den Standort Bothell geliefert. Seit 2001 ist „Importadores Neptuno“ der alleinige Hersteller und Distributor der Produktgruppe Tourenräder.

Nach Abschluss eines erfolgreichen Geschäftsjahres ist Adventure Works Cycles daran interessiert, seinen Marktanteil durch intensivierten Verkauf an gute Kunden, durch Erweiterung der Produktverfügbarkeit über eine externe Website und durch Senkung der Preise durch reduzierte Produktionskosten zu vergrößern.“⁴

Das Unternehmen verspricht sich vom Einsatz des Management Cockpits folgende Verbesserungen in Hinblick auf die

Gesamtunternehmenssteuerung:

- Optimierung der Entscheidungsgrundlagen
- Erhöhung der Transparenz
- Kontextbildung zwischen isolierten Informationen⁵

Die strategischen Ziele und Unterziele gestalten sich wie folgt:

3.1 Firmenleitbild

Wir produzieren moderne und qualitativ hochwertige Fahrräder, um den umweltfreundlichen Mobilitätsbedarf der Menschen zu decken.

3.2 Firmenziel

Wir wollen in den nächsten 7 Jahren Mengen führender Hersteller von Fahrrädern werden.

3.3 Firmenkennzahlen

Um strategische Erfolge messen zu können, wurden für das Unternehmen Kennzahlen definiert:

- Umsatzrendite
- Eigenkapitalrendite
- Gewinnerreichung
- Marktanteil
- Liquidität
- Kundenzufriedenheit
- Liefertreue
- Effizienz der MA
- Servicezeiten
- Bildungsstand der MA
- Motivation der MA
- Patentanmeldungen
- Auszubildendenquote
- Interne Durchlaufzeiten
- Lagerbestand
- Interne Prozesszeiten

3.4 Einsatz der Balanced Scorecard

Als Strategietool und Steuerungsinstrument setzt die Adventure Works die Balanced Scorecard ein.

Die 1992 von Robert S. Kaplan und David P. Norton eingeführte Balanced Scorecard (BSC) ist ein Konzept zur Dokumentation der Ergebnisse aus Messungen der Aktivitäten eines Unternehmens im Hinblick auf seine Vision und Strategien, um den Führungskräften einen umfassenden Überblick über die Leistungsfähigkeit und Effektivität der Organisation zu bieten. Das neue Element bestand darin, dass die BSC nicht nur auf die Finanzperspektive beschränkte, sondern auch weitere Sichten auf das Unternehmen ermöglichte. Im Mittelpunkt der Sichten standen die Vision und die Strategie des Unternehmens. Aufgrund ihrer flexiblen und damit umfassenden Gestaltungsmöglichkeit ist die Balanced Scorecard ein Instrument zur Einrichtung eines integrierten Managementsystems.⁶

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Die vier Sichten der BSC⁷

Die Umsetzung der BSC für Adventure Works wird mit Hilfe von Microsoft Excel realisiert. Eine ausführliche Anleitung hierzu ist im Kapitel 8.8 zu finden. Zur besseren Übersicht wird noch ein Dashboard entworfen. Hier sind alle Kennzahlen und ihre Stati abgebildet. Der Betrachter kann sich nun einen kompletten Überblick über den aktuellen Unternehmensstatus verschaffen. Die operative Zielerreichung wird mittels Ampelsymbolen bewertet.⁸

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Das Dashboard

Grundlagen Business Intelligence

Obgleich sich der Begriff Business Intelligence schon seit geraumer Zeit am Markt etabliert hat herrscht doch erstaunlicherweise eine Vielzahl an Meinungen und Auffassungen darüber, was unter ihm zu verstehen ist. In diesem Kapitel soll geklärt werden, was Business Intelligence ist, bzw. nicht ist, was es zu leisten vermag und welche Voraussetzungen dafür geschaffen werden müssen.

Aufgrund der Entwicklungsgeschichte von Business Intelligence und ihrem Ursprung im Technischen, assozieren viele den Begriff Business Intelligence mit technischen Fragestellungen wie ETL, Datenbankmanagementsystemen oder Data Warehouses. Dies alles ist Business Intelligence nicht.

Business Intelligence ist kein technischer Lösungansatz für irgendwelche Fragestellungen, keine physisch vorhandene Datenbank oder gar ein fertiges System das es nur noch zu installieren gilt.

Business Intelligence ist vielmehr ein Prozess, eine Idee und all die vorher genannten technischen Entitäten dienen lediglich als Vehikel, als Mittel zur Zielerreichung. Sind diese Vehikel in die Jahre gekommen und entsprechen sie nicht mehr dem Stand der Technik, so werden sie aussortiert und es wird neue Vehikel geben. Business Intelligence als Idee wird nach wie vor fortbestehen. Um eine einheitliche Grundlage der nachfolgenden Arbeiten zu schaffen, hier eine Begriffsdefinition von Business Intelligence.

„Business Intelligence ist die entscheidungsorientierte Sammlung, Aufbereitung und Darstellung geschäftsrelevanter Informationen.“⁹

Nachfolgend werden die einzelnen Teilaspekte der Aussage ausgewertet.

Entscheidungsorientierung:

BI dient dem Zweck die Entscheidungsgrundlagen für den Entscheider zu verbessern. Dementsprechend ist es ausreichend sich auf entscheidungsrelevante Informationen zu konzentrieren.

Datensammlung:

Die Daten für Business Intelligence Anwendungen stammen häufig aus einer Vielzahl von verschiedenen Datenquellen. Diese müssen in einer Art und Weise erschlossen werden, die auch den hohen Anforderungen der Sicherheit und Benutzerberechtigungen gerecht wird. Insbesondere muss sichergestellt werden, dass Anwender nicht plötzlich Daten aus aggregierter Sicht einsehen können, obwohl ihnen dies aus isolierter Sicht nicht möglich gewesen wäre.

Datenaufbereitung:

Business Intelligence beruht auf der Weiterverarbeitung der als wertvoll erachteten Daten zu entscheidungsrelevanter Information. Vormals isolierte Informationen werden zueinander in Beziehung gesetzt und können nun im Gesamkontext neue Aussagen enthalten.

Informationsdarstellung:

Information allein kann keinen Mehrwert erbringen, wenn sie nicht in geeigneter Form kommuniziert wird. Damit muss ein System, das das erklärte Ziel hat, den Entscheider bestmöglich zu unterstützen, dieses Wissen in einer Art und Weise zur Verfügung stellen, die diesem Anspruch auch gerecht wird.

Geschäftsrelevante Informationen:

Durch die Beschränkung auf geschäftsrelevante Information wird ungemein viel Aufwand eingespart. Ausgehend von der Erkenntnis, dass die Datenaufbereitung den zeitintensivsten Teil des Projektes darstellt, ist es nur nahe liegend irrelevante Informationen gar nicht erst in Betracht zu ziehen.

Unter Berücksichtigung dieser Prämissen rückt der Anwender in den Vordergrund und die konkrete technische Realisation wird zunächst außen vor gelassen. Eingangs wurde bei Business Intelligence von einem Prozess gesprochen. Ein Prozess wird nicht nur ein einziges Mal durchlaufen und generiert auch keine Aussagen, die nie wieder in Frage gestellt werden müssen. Ändern sich die Rahmenbedingungen, so muss auch der Prozess erneut durchlaufen werden um entscheidungsrelevante Information zu gewinnen. In der Wirtschaft ändern sich die Rahmenbedingungen laufend. Business Intelligence begleitet diese Veränderung und passt sich an. Da der Business Intelligence Prozess jedes Mal auf unterster Ebene von neuem beginnt, entsteht ein logischer Kreis, der Business Intelligence Zyklus. Neu gewonnene Erkenntnis dient dem nächsten Schritt als Eingabe um das Modell noch weiter zu verbessern. Damit ist der Zyklus im weitesten Sinne ein Regelsystem, das heißt ein kybernetisches System.

Der Business Intelligence Zyklus wird im Allgemeinen in drei oder fünf Phasen unterteilt. Nachfolgend ein Zyklus mit fünf Phasen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Defintion Business Intelligence¹⁰

4.1 Ziele von Business Intelligence

In Kapitel 1 Einführung in das Thema wurden bereits die Gründe für den „Informationsnotstand“ in Unternehmen aufgezeigt. Viele Entscheidungsträger verspüren einen Mangel an Informationsmenge sowie an Informationsqualität.¹¹

Viel schwerer jedoch wiegt die häufige Widersprüchlichkeit der Informationen, da diese aus unterschiedlichen Quellen stammen.

Solche Informationen sind als Entscheidungsgrundlage ungeeignet. Die Ziele, die mit dem Einsatz von Business Intelligence verfolgt werden, sind daher im Wesentlichen diese drei:

4.1.1 Optimierung der Entscheidungsgrundlagen

Sowohl strategische als auch operative Entscheidungen werden ausgehend von einer Informationsbasis gefällt. Je klarer die Sachlage, desto qualitativ besser die Entscheidung die getroffen werden kann. Business Intelligence steuert die Verdichtung von Information zu Strategie- oder Entscheidungsrelevanter Information und hilft Inkonsistenzen im Informationsgehalt zu vermeiden.¹²

4.1.2 Erhöhung der Transparenz

Umfragen zeichnen ein beunruhigendes Bild wie es um das Strategiebewusstsein von Mitarbeitern bestellt ist¹³. Häufig wissen nicht einmal die Führungskräfte was sich hinter den Entscheidungen des Top Managements verbirgt. Führt man sich die Tatsache vor Augen, dass ein Unternehmen ein soziotechnischer Zusammenschluss von vielen Individuen zu einer gemeinsamen Zielerreichung ist, so fällt diese Tatsache noch viel drastischer ins Gewicht. Es gilt die alte Weisheit: „Wenn man das Ziel nicht kennt, ist kein Weg der Richtige“. Ein Fischwarm kann nur deshalb wie eine Einheit reagieren, weil die Kommunikation zwischen den Individuen nahezu perfekt ist und jeder einzelne Fisch weiß was zu tun ist.

Business Intelligence gibt dem einzelnen Mitarbeiter die Möglichkeit, seinen eigenen Verantwortungsbereich besser zu überblicken und zeigt ihm seine Aufgaben im Gesamtkontext der Unternehmensstrategie auf. Spiegelt sich die Unternehmensstrategie in harten Fakten wider, so kann diese in Kennzahlen bis auf Mitarbeiterebene heruntergebrochen werden und dem Mitarbeiter kann aufgezeigt werden wie sein Engagement zum Gesamterfolg beiträgt. Dies wirkt motivierend und nicht zu vernachlässigen auch inspirierend und führt damit nicht zuletzt, zu einer Innovationsbereitschaft die von unten kommt und die nicht von oben herab diktiert werden muss.

4.1.3 Kontextbildung zwischen isolierten Informationen

Hier liegt die größte Stärke von Business Intelligence. Die vorausgegangenen Punkte bringen einen hohen Zeit- und Arbeitsaufwand mit sich. Im Gegensatz dazu sind an dieser Stelle die Informationen bereits vorhanden und müssen „nur“ noch zusammengeführt und interpretiert werden. Data Mining ist eine Sammlung von Werkzeugen und Verfahren um dieses Teilziel zu erreichen.

Bisher waren dafür teure Spezialisten notwendig. Im Rahmen unserer Thesis wollen wir aufzeigen, wie dies jeder Anwender mit nur wenigen Mausklicks in vertrauter Arbeitsumgebung leisteten kann. Siehe hierzu Kapitel 10: Data Mining im Showcase.

4.2 Voraussetzungen für Business Intelligence

Es gibt nur wenige Unternehmen die nicht vom Einsatz von Business Intelligence profitieren würden. Allerdings müssen vor dem Einsatz einige wichtige Fragestellungen beantwortet werden. So genügt es nicht, dass die Daten in geeigneter Form vorhanden sind, sondern vielmehr muss auch das Unternehmen selbst bereit sein diesen Wandel nicht nur mitzutragen, sondern auch mitzugestalten. Business Intelligence muss also kompatibel mit der Unternehmenskultur des betreffenden Unternehmens sein.¹⁴

4.2.1 Bereitschaft Dinge in Frage zu stellen

Business Intelligence liefert bis dato unbekannte neue Information und Entscheidungshilfen. Diese Ergebnisse könnten unter Umständen Dinge in Frage stellen die seit geraumer Zeit im Unternehmen Bestand haben. Je nach Unternehmenskultur kann dies ein großer Vorteil, aber auch ein Nachteil sein.

4.2.2 Bereitschaft unkonventionell zu denken

Business Intelligence schafft völlig neue Erkenntnisse. Diese müssen explizit zugelassen werden. Nichts darf außen vor gelassen werden nur weil es auf den ersten Blick unsinnig oder in keiner Beziehung zueinander zu stehen scheint.

4.2.3 Management Attention

Die Einführung von Business Intelligence ist kein klar gezeichneter Weg, sondern vielmehr ein Pfad mit vielen Seitenwegen und auch Sackgassen. Dieser Sachverhalt muss vom betreffenden Management akzeptiert werden.

Sind diese drei Voraussetzungen gegeben, so stellen sich einige Anforderungen an den Datenbestand des Unternehmens.

4.2.4 Datenqualität

Bevor die technische Realisierung des Projektes angegangen werden kann, muss sichergestellt werden dass die Daten in vollständiger und konsistenter Form vorliegen. Häufig ist dies nicht in vollem Umfang der Fall und es sind intensive Vorarbeiten notwendig. Insbesondere müssen einige der Datensammlungsprozesse des Unternehmens angepasst werden um sicherzustellen, dass die Datenqualität ihr Level auch in Zukunft halten kann.

4.2.5 Datenmenge

Soll das Business Intelligence Projekt einen echten Mehrwert für das

Unternehmen schaffen, so ist eine Mindestdatenmenge erforderlich. Es

macht wenig Sinn eine Stammkundendatenbank mit lediglich 5 Datensätzen einem Data Mining Prozess zu unterwerfen, also sprichwörtlich „Mit Kanonen auf Spatzen zu schießen“. Vorsicht ist jedoch auch bei zu großen Datenmengen geboten, hier wird häufig Quantität zulasten von Qualität „erkauft“.

4.2.6 Datenstruktur

Wie jede Methode besitzen auch Data Mining Methoden Eingabeparameter die einer bestimmten Form genügen müssen. Obgleich die Algorithmen mit einer Fülle verschiedenster Inputs zurechtkommen, gilt im Allgemeinen, dass die Eingaben eine strukturierte Form aufweisen müssen. Bei Tabellendaten aus Datenbanken ist dies ohnehin der Fall. Was aber wenn Faxe, Emails etc. ausgewertet werden sollen? Um diese unstrukturierten Informationen maschinenlesbar und noch viel wichtiger auswertbar zu machen, sind erhebliche Anstrengungen notwendig, insbesondere wenn man berücksichtigt wie kontextabhängig natürliche Sprachen sind.

4.3 Data Warehouse

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Data Warehouse¹⁵

Grundsätzlich ist Business Intelligence völlig unabhängig von einem Data Warehouse oder dem Einsatz von OLAP (Siehe hierzu Kapitel 4.4). Ein Data Warehouse ist lediglich ein Vehikel um die Ziele von Business Intelligence zu erreichen. Es ist ein zentraler Speicherort der zwei Schnittstellen bereitstellt. Zum einen die Schnittstelle zu den Quellsystemen der Daten. Zum anderen eine Schnittstelle für Reporting- und Analysekomponenten. Folgende Überlegungen lagen zugrunde als die ersten Data Warehouses Anfang der 1980er Jahre entstanden.

4.3.1 Indirekter Zugriff auf die OLTP Daten des ERP Systems

Hintergrund dieser Anforderung sind zunächst Sicherheitsaspekte. Würde mit den physischen Daten des OLTP Systems gearbeitet werden, so wären im Unglücksfall alle Transaktionsdaten eines nicht gesicherten Zeitabschnitts verloren. Ein zweiter Punkt sind Performanceüberlegungen. Die Abfragen der Analysetools sind sehr rechenintensiv was in unnötiger Weise die Echtzeitperformance des Transaktionssystems beeinträchtigen würde. Ohnehin spielen für BI Anwendungen tagesaktuelle Daten nur eine untergeordnete Rolle. So genügt häufig eine wöchentliche Extraktion der Daten aus den transaktionalen Datenbeständen des Unternehmens.

4.3.2 Integration verteilter Datenbestände

Aus historischen Gründen sind die Unternehmensdaten häufig physisch dezentral verteilt. Durch die Assoziation dieser verteilten Datenbestände lassen sich neue Informationen generieren, die dem Unternehmen einen Wettbewerbsvorteil verschaffen können.

4.3.3 Datenkonsolidierung- und aggregierung

Bei der Zusammenführung der Daten werden diese zunächst in eine konsistente Form überführt. Anschließend kann diese Information verdichtet werden. Dies geschieht häufig durch einfache Summenbildung, jedoch kommen auch weitaus aufwendigere statistische Verfahren zum Einsatz. Ein OLTP System muss beispielsweise über jeden einzelnen Geschäftsvorfall „Buch führen“. Die OLAP Analyse hingegen begnügt sich mit der Aussage wie viele dieser speziellen Geschäftsvorfälle an einem Tag anfielen und benötigt von daher nicht die genaue Uhrzeit. Somit können und sollten die Daten verdichtet werden.

4.4 OLAP

Vom technologischen Standpunkt aus, ist das „On-Line Analytic Processing“ die zentrale Komponente von Business Intelligence. OLAP hat sich als sehr geeignet erwiesen die entscheidungsrelevante Darstellung von Informationen zu realisieren. An dieser Stelle eine kurze Definition von OLAP:

„OLAP ist eine Kategorie von Applikationen und Technologien zum Sammeln, Verwalten, Bearbeiten und Darstellen von multidimensionalen Daten für Analyse- und Verwaltungszwecke.“¹⁶

4.4.1 Dimensionen

Zieht man die analytische Geometrie als Vergleich heran, so entsprechen die Dimensionen dem Vektorraum. Die Dimensionen dienen dem Beschreiben von Datenmengen. Sie definieren Merkmale nach denen Abfragen formuliert werden können und für welche Daten im System hinterlegt sind.

Die Abfrageoperationen mittels Dimensionen entsprechen der Ebenenbildung der analytischen Geometrie.

Klassische Beispiele für Dimensionen sind die Merkmale Region, Verkäufer, Produkt. Jede Dimension kann weitere Unterelemente besitzen, so genannte Ausprägungen oder Elemente. Dies wären bei der Dimension „Region“ beispielsweise: Staat, Bundesland, Landkreis.¹⁷

4.4.2 Hierarchien

Elemente von Dimensionen können einen hierarchischen Aufbau besitzen. Die in 4.4.1 genannten Elemente könnten beispielsweise wie folgt angeordnet werden: Region - Staat - Bundesland - Landkreis. Diese Anordnung ermöglicht es, Kennzahlen zu aggregieren oder herunterzubrechen. Im Business Intelligence Umfeld spricht man dabei von „Roll up“ bzw, „Drill down“.

4.4.3 Measures

Die Werte, auf die mittels Dimensionen zugegriffen wird, werden als Measures bezeichnet. Measures sind „harte Fakten“, also Größen wie Umsatz, Kosten, Durchlaufzeiten, Mengen. Sie entsprechen den betriebswirtschaftlichen Fragestellungen der einzelnen Funktionsbereiche eines Unternehmens. Beispielsweise möchte der Vertrieb wissen mit welchem Produkt der meiste Umsatz erzielt wurde. Das Measure wäre in diesem Fall der Umsatz.

Dimensionen dienen anschließend der Aufgabe, diese Frage zu beantworten. In welcher Region wurde der Umsatz gemacht, welcher Mitarbeiter war beteiligt und zu welchem Zeitpunkt erfolgte der Umsatz. Da die Dimensionen nur über einen bestimmten Detaillierungsgrad verfügen, werden die Daten in den Measures aggregiert. Numerische Werte werden dabei einer Summenbildung unterworfen, nominal skalierte Werte werden ausgezählt.

4.4.4 Cubes

„Dimensionen und Measurs zusammen definieren die Struktur und den Inhalt einer multidimensionalen Datenmenge.“¹⁸

Cube bedeutet ins Deutsche übersetzt nichts weiter als „Würfel“ und so kann man ihn sich auch am besten vorstellen.

Auf dem Cube lassen sich die Operationen „Slicing“ und „Dicing“ ausführen. „Slicing“ bedeutet in „Scheiben schneiden“. Geometrisch kann man davon sprechen, dass Ebenen eingezogen werden, die die Auswahl der Daten eingrenzen.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Slicing¹⁹

Werden mehrere Ebenen eingezogen und entstehen Untermengen des Cubes, so spricht man von „Dicing“. Die wörtliche Übersetzung „Würfeln“ ist hier völlig irreführend.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Dicing²⁰

4.4.5 Dimensions- und Faktentabellen

Prinzipiell ist es möglich die Dimensionen und Measures direkt in ein Cube Modell hineinzuschreiben. Diese Möglichkeit ist in der Praxis jedoch weniger gebräuchlich. Vielmehr werden hier die Daten aus einem relationalen Datenbanksystem bezogen. Dabei werden alle Measures in so genannten Faktentabellen gespeichert. Die Elemente jeder einzelnen Dimension werden in Dimensionstabellen gespeichert. Der Primärschlüssel einer jeden Dimensionstabelle wird als Fremdschlüssel in der entsprechenden Faktentabelle eingetragen. Folgende Schemata können bei der Modellierung eines Cube Designs als Vorlage dienen:

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 11: Star-Schema²¹

„Wenn für jede Dimension nur eine Tabelle vorgesehen ist, die jeweils alle Hierarchieebenen berücksichtigt, und jede Dimensionstabelle direkt mit der Faktentabelle verbunden ist, wird dies als Star-Schema bezeichnet.“²²

Snowflake-Schema

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 12: Snowflake Schema²³

„Wenn die verschiedenen Hierarchieebenen einer Dimension nicht in einer denormalisierten Tabelle angegeben werden, sondern auf normalisierte Tabellen verteilt sind, erfolgt die Modellierung der Cubetabellen nach dem Snowflake-Schema.“²⁴

Galaxy-Schema

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 13: Galaxy Schema²⁵

Enthält ein Cube mehr als eine Faktentabelle die jeweils nicht mit allen anderen Dimensionstabellen assoziiert ist, so spricht man von einem Galaxy-Schema.

4.4.6 Speicherkonzepte

Bei der Definition des Terminus Cube in Kapitel 4.4.4 wurde nur von der Definition von Struktur und Inhalt gesprochen. Dies bedeutet im Umkehrschluss, dass mindestens diese im Cube Model gespeichert werden müssen. Wo aber geschieht die eigentliche Datenhaltung?

MOLAP

Bei MOLAP werden alle möglichen Kombinationen der Dimensionselemente ermittelt und in aggregierter From in das Cube Modell selbst geschrieben.²⁶ Diese Lösung ist sicherlich die performanteste da die Datenaggregation lediglich einmal durchgeführt werden muss, bedauerlicherweise ist der Speicherverbrauch sehr groß. MOLAP wird aus diesem Grund nur für kleinere Cubes eingesetzt, wie sie häufig in Hochverfügbarkeits- anwendungen vorkommen.

ROLAP

Bei Rolap werden nur die multidimensionalen Definitionen im Cube gespeichert. Die gesamte Datenhaltung jedoch, erfolgt in einer relationalen Datenbank. Damit bleiben die Detaildaten an Ort und Stelle, wohingegen die aggregierten Daten in gesonderten Tabellen vorgehalten werden. Somit ergibt sich kein zusätzlicher Speicherbedarf für die Detaildaten. Als Nachteil müssen längere Antwortzeiten bei multidimensionalen Abfragen in Kauf genommen werden. ROLAP empfiehlt sich daher für große Cubes auf die eher selten zugegriffen wird.²⁷

HOLAP

Der Buchstabe „H“ in HOLAP steht für Hybrid. Damit stellt diese Lösung einen Kompromiss zu den vorher genannten Lösungen dar. Aggregierte Daten werden im Voraus berechnet und in das Cube Model geschrieben, die Detaildaten verbleiben auf der relationalen Datenbank. Damit empfiehlt sich HOLAP für folgendes Szenario: Kurze Antwortzeiten bei Zugriff auf aggregierte Daten, die eine große Menge an Detaildaten benötigen.²⁸

4.5 Data Mining

„Der Begriff ‚Data Mining’ bezeichnet Techniken und Methoden, die aus bestehenden Datenbeständen neue, bis dahin unbekannte Informationen erzeugen.“²⁹

Bei Data Mining handelt es sich damit gewisser Weise um die Generierung neuen Wissens.

Bis in die jüngste Vergangenheit waren hierfür Experten notwendig, die mit statistischen Verfahren, isolierte Informationen so in Beziehung setzten, dass diese eine neue Aussage erhielten. Mittlerweile werden diese Experten von einer Vielzahl rechnergestützter Werkzeuge unterstützt. Einen noch weitergehenden Schritt in Richtung „Automatisierung von Data Mining“, ging Microsoft mit der Integration von Standard Data Mining Algorithmen in Excel 2007. Selbst Normalanwender können hier mit wenigen Mausklicks komplexe Auswertungen durchführen und neue Erkenntnis aus den vorhandenen Informationen „generieren“.

Generell muss vor Einsatz von Data Mining geklärt werden ob die Daten diskret oder stetig, sowie voneinander unabhängig sind. Diskret sind Werte die keine Zwischenschritte besitzen, wie beispielsweise die Anzahl von Personen in einem Raum. Stetig wäre hingegen die Skala eines Thermometers. „Unabhängig“ bedeutet, dass die Merkmale in keiner Abhängigkeit zueinander stehen. In unserem Projekt wäre dies beispielsweise die Beziehung der Merkmale „Fahrradkäufer“ und „Nachname“. Eine Abhängigkeit ist hier eher unwahrscheinlich.

Die Gesamtmenge der Data Mining Verfahren lässt sich in zwei Grundkategorien unterteilen.³⁰

4.5.1 Assoziationen

Assoziationen ermitteln Zusammenhänge zwischen Datenbeständen und klassifizieren diese. In den Bereich der Assoziationsanalyse fallen Verfahren wie:

Clusteranalyse

Objekte werden aufgrund von Ähnlichkeiten gruppiert.

Hauptkomponentenanalyse

Die Hauptkomponentenanalyse ermittelt welche Faktoren bestimmend für ein Objekt sind.

Faktoranalyse

Die Faktoranalyse basiert auf der Bildung von Merkmalsgruppen

Diskriminanzanalyse

Die Diskriminanzanalyse ermöglicht die Zuordnung von Objekten zu den entsprechenden Klassen.³¹

Entscheidungsbäume

Sie entsprechen in etwa einem Wahrscheinlichkeitsbaum aus dem Bereich der Stochastik. Mit ihnen lassen sich die Wahrscheinlichkeiten bestimmter Pfade, respektive Zusammenhänge zwischen den Aussagen ermitteln.

Attributsgewichtung

Die Attributsgewichtung ermittelt welche Faktoren für das Endergebnis relevant waren.

4.5.2 Progressionsverfahren

Will man aus bestehenden Daten auf zukünftige Entwicklungen schließen, so benötigt man geeignete Forecast Verfahren. Im Allgemeinen werden die nachfolgenden Techniken eingesetzt:

Regressionsanalyse

Die Regressionsanalyse zeigt Ursache-Wirkungsbeziehungen auf.

Künstliche neuronale Netze

Künstliche neuronale Netze sind in ihrer Funktionsweise den biologischen Neuronen sehr ähnlich. Aufgrund von Trainingsdaten werden die Eingangsgewichte der unterschiedlichen „Datenleitungen“ solange angepasst bis der gewünschte Output zustande kommt. Als Lernverfahren kommen sowohl deterministische wie auch stochastische Verfahren zum Einsatz.

4.6 Data Mining Methoden von Microsoft BI

Die Analysis Services von Microsoft bringen von Haus aus eine ganze Fülle von Data Mining Methoden mit. Sollten für Spezialfälle eigene Implementierrungen der Algorithmen notwendig sein, so können auch diese im SQL Server 2005 eingebunden werden.

Folgende Data Mining Methoden stehen zur Verfügung:

- Microsoft Assoziationen
- Microsoft Cluster
- Microsoft Entscheidungsstrukturen
- Microsoft Lineare Regression
- Microsoft Logistische Regression
- Microsoft Naive Bayes
- Microsoft Neuronale Netzwerke
- Microsoft Sequenzcluster
- Microsoft Zeitreihen³²

Grundlagen SQL Server 2005 mit BI - Komponenten

Bereits im Jahre 2000 betrat Microsoft mit seinem Serverprodukt SQL Server 2000 den Business Intelligence Markt. Die damalige Lösung scheiterte aber aus zwei Gründen. Zum einen war der Funktionsumfang zu gering, um im Wettbewerb gegen die etablierte Konkurrenz wie Oracle oder SAP bestehen zu können, zum anderen wusste kaum ein Lizenznehmer um die Zusatzfunktionalitäten die im Verborgenen mitinstalliert wurden. Fast mochte man glauben, Microsoft habe diese vor der Öffentlichkeit verschwiegen. Doch mit dem Erscheinen der Version 2005 wurde die strategische Absicht Microsofts deutlich, fuhr man doch eine evolutionäre Strategie wie bei den meisten Businessprodukten des Softwarehauses.

Der im Jahre 2005 vollzogene Releasewechsel, brachte eine ganze Fülle an neuen Funktionalitäten und veränderte das Produkt grundlegend, sowohl hinsichtlich der Benutzerfreundlichkeit, als auch in Hinblick auf die technologischen Grundlagen. Auf der Userseite wurden beispielsweise alle Entwicklungstätigkeiten im Business Intelligence Development Studio zusammengeführt. Dieses entsprach weitestgehend dem Visual Studio 2005 und bot damit dem Anwender eine vertraute Arbeitsumgebung. Ferner ersetzte das neue Management Studio den alten Enterprise Manager und konzentrierte die administrativen Tätigkeiten die zum Betrieb des Serverproduktes nötig waren.

Auf der technologischen Seite wurde unter anderem die schwach ausgebildete Data Mining Komponente der Vorgängerversion auf Wettbewerbsniveau gehoben. Auch im Bereich ETL (Extract, Transform, Load) wurde eine Vielzahl von Neuerungen eingebracht.³³

Der SQL Server 2005 bildet dabei als Infrastrukturserver die Applikationsund Integrationsplattform, auf die die BI Produkte des Hauses Microsoft aufsetzen. Die nachfolgenden Seiten sollen einen kurzen Überblick über diese Lösungen verschaffen. Auf deren konkretes Zusammenspiel soll später im Realisierungsteil eingegangen werden.

5.1 Analysis Services

Die Microsoft SQL Server 2005 Analysis Services bauen auf der Plattform des relationalen Datenbankservers SQL Server 2005 auf.

Sie nutzen die bestehende Infrastruktur und erweitern dieses üblicherweise als OLTP eingesetztes Produkt, um OLAP und Data Mining Funktionalität. Die Analysis Services sind dabei wiederum selbst eine Serverkomponente und dienen hauptsächlich der Verwaltung der Metadaten, beispielsweise der Strukturinformation der Cubes. Die eigentlichen Daten mit denen der Cube bei der Verarbeitung befüllt wird, befinden sich dabei stets in einer klassischen relationalen Datenbank, die auf dem SQL Server 2005 realisiert wurde. Dies kann, muss aber keinesfalls zwinged ein Datawarehouse sein.

Da es sich bei den Analysis Services um ein Serverprodukt handelt, benötigt man in logischer Konsequenz auch eine Clientkomponente um die Visualisierung der Daten vornehmen zu können. Auf die Informationen des Analysis Servers kann auf unterschiedliche Art und Weise zugegriffen werden:

- Reporting Services
- Microsoft Excel
- Microsoft Office SharePoint Server 2007
- Microsoft Business Scorecard Manager 2005

Dabei können die verschiedenen Lösungen miteinander kombiniert oder ineinander integriert werden.

5.2 Integration Services

Aus infrastruktureller IT-Sicht kann man bei den meisten Unternehmen von einem gewachsenen Gebilde sprechen. Die Datenhaltung erfolgt dabei häufig dezentral, redundant, inkonsistent und schließlich auch in verschiedenen Dateiformaten. Im Gegensatz dazu liegt die Stärke von Business Intelligence in der Verknüpfung bisher isolierter Informationen. Folglich musste eine Lösung zur Datenkonsolidierung geschaffen werden. Dies leisten die SQL Server 2005 Integration Services. Sie lösten die aus dem Vorgänger SQL Server 2000 bekannten Data Transformation Services (DTS) ab. Sie sind dazu geeignet dezentrale Datenbestände zu extrahieren, aufzubereiten und zentral zu konsolidieren.³⁴

Das häufigste Einsatzszenario der Integration Services ist die Bildung eines Data Warehouses. Hierzu sollen Daten aus unterschiedlichen Quellen zusammengeführt werden.

Beispielsweise aus einem OLTP System (SAP ERP), einer Microsoft Access

Datenbank und zu guter letzt Flatfiles (Excel etc.).

Um diese komplexen Prozesse zu steuern, müssen verschiedene Pakete mit Steuer- und Datenlogik im Business Intelligence Development Studio entwickelt werden. Diese lassen sich später im SQL Server Agent einbinden und werden dadurch in regelmäßigen Abständen geladen.

Technologische Neuerung im Vergleich zu den DTS ist die Trennung von Steuer und -Datenflusslogik. Die Steuerlogik basiert dabei auf der WWF (Windows Workflow Foundation) und diese wiederum auf diversen Interfaces des .NET Frameworks. Es lassen sich komplexe Workflows konstruieren die Schrittsynchronisation und Zustimmungseinbeziehung berücksichtigen.

Die Datenflusslogik nutzt die Konnektivität von „OLE DB“. Dieser Standard ist ferner geeignet ODBC (Open Database Connectivity) Verbindungen zu realisieren. Mithilfe letztgenannter Datenbankabstraktionsschnittstelle lässt sich nahezu jede Datenquelle ansprechen und nutzbar machen. Ferner ist es möglich die Programmiersprache Visual Basic .NET (in diesem Fall als Skriptsprache) in einen solchen Datenfluss zu integrieren. Hierdurch lassen sich komplexe Datenaufbereitungen durchführen, wie beispielsweise unser mitlaufendes Absatzeinbruchszenario (Siehe hierzu Kapitel 7.3.2).

5.3 Reporting Services

Die bisher beschriebenen Komponenten arbeiten allesamt im Hintergrund und der Anwender wird sie im Idealfall nie zu Gesicht bekommen. Denn genau dies ist ihre Aufgabe. Sie sollen unsichtbar, unmerklich, zuverlässig und gekapselt arbeiten. Eine Möglichkeit den Entscheidungsträger zu unterstützen, ist die Zugänglichmachung der gewonnen Erkenntnisse aus Data Mining und Online Analytical Processing durch die Reporting Services. Bis zur Einführung von Excel 12 im Officepaket 2007 spielten sie die zentrale Rolle im Bereich Reporting.

Aus technischer Sicht handelt es sich bei ihnen um eine clientserverbasierte Berichtsplattform, die im Sinne von SOA ihre Dienste als Webservice zur Verfügung stellt. Es können sowohl relationale, als auch multidimensionale Datenquellen als Quelle dienen. Der Reiz besteht dabei aber selbstverständlich im Einsatz von OLAP Cubes, denn nur diese ermöglichen „Drillthrough“ Funktionalität. Die Weiterverarbeitung der Daten wird unkompliziert über die integrierte Excel oder PDF Exportfunktionalität gewährleistet.

Als Vision sah Microsoft bis 2007 die Einrichtung einer zentralen unternehmensweiten Berichtsplattform mittels der SSRS an. Jedoch hat sich der technologische Schwerpunkt dieser Vision seit dem Erscheinen von Office 2007 in Richtung SharePoint Server 2007 verschoben.³⁵

5.4 Unified Dimension Model

Das Unified Dimension Model dient einem ähnlichen Zweck wie ein Data Warehouse. Es sollen unterschiedliche Datenquellen erschlossen werden. Doch allein schon die unterschiedlichen SQL Dialekte erschwerten in der Vergangenheit diese Bemühungen. Sollten neben Datenbanken auch noch Flatfiles oder Webservices eingebunden werden, waren Datenqualität und Datenquantität oft nicht mehr gewährleistet. Ferner blieb häufig unklar was sich hinter den Daten verbarg, da Kontext stiftende Metadaten fehlten. Ein weiterer Punkt war die performancintensive Datenaggregation der OLTP Einzeltransaktionen zur Generierung von OLAP Daten, die bei jeder Anfrage erneut durchgeführt werden musste.

Das UDM schlägt nun eine Brücke zwischen der Anwendungsschicht und den physikalischen Datenbeständen. Anfragen werden in MDX oder T-SQL abgesetzt. Das UDM übersetzt diese in die Sprache der jeweiligen Datenquelle. Damit bildet das UDM lediglich eine Metadatenschicht, womit auch das Hauptunterscheidungsmerkmal in Bezug auf ein Data Warehouse genannt ist. Im UDM selbst sind keine Daten gespeichert. Ein Data Warehouse hingegen enthält aufbereitete Kopien der Datenquellen.

Eingebettet ist das Unified Dimension Model in die Analysis Services des SQL Server 2005.

5.5 SQL Server Management Studio

Das SQL Server Management Studio dient als zentraler Einstiegspunkt für Wartung und Administration der eingesetzten Server. Es ist verantwortlich für den Zugang zu den Daten auf unterster Ebene. Datenbanken können mit den Werkzeugen des SQL Server Management Studios unter anderem gesichert und wiederhergestellt werden. Ferner können Hintergrundprozesse eingeplant werden, wie sie insbesondere für den ETL Vorgang bei der Herstellung des Data Warehouses benötigt werden.

[...]

---

¹ Vergleiche [Schu08]

² Siehe [Vothe08] Seite 18

³ Siehe [Woeh05], S.218

⁴ Zitat von Microsoft http://technet.microsoft.com/de-de/library/ms124825.aspx 10.12.2008

⁵ Vergleiche [Walt06]

⁶ Vergleiche [Herw07]

⁷ Vergleiche [Frie08]

⁸ Siehe hierzu auch [Herw07]

⁹ Siehe [Schr06], Seite 12

¹⁰ Siehe auch [Schr06] Seite 13

¹¹ Siehe auch [Schr06] Seite 12

¹² Siehe hierzu auch [Umba07]

¹³ Siehe hierzu [Pflä6]

¹⁴ Siehe auch [Schr06] Seite 19

¹⁵ Quelle: http://www.bi-web.de/images/datawarehouse_consulting_b1.gif, Stand 25.12.2008

¹⁶ Zitat von http://www.olapreport.com/glossary.htm, Stand 25.12.2008

¹⁷ Siehe [Schr06], Seite 26

¹⁸ Siehe [Azev06], Seite 43

¹⁹ http://training.inet.com/OLAP/Images/kube0004.gif

²⁰ Quelle: http://training.inet.com/OLAP/dicing.htm, Stand 26.12.2008 Star-Schema

²¹ Quelle: http://www.learnbi.com/images/bi_dim.gif, Stand 26.12.2008

²² Siehe [Azev06], Seite 45

²³ Quelle: http://publib.boulder.ibm.com/infocenter/db2luw/v8/topic, Stand 27.12.2008

²⁴ Zitat [Azev06] Seite 46 über das Snowflake-Schema

²⁵ Quelle: http://www.pafis.shh.fi/~peizho03/sfis/ws1/galaxy.jpg, Stand 27.12.2008

²⁶ Siehe [Azev06], Seite 51

²⁷ Siehe [Azev06], Seite 52

²⁸ Siehe [Azev06], Seite 52

²⁹ Siehe [Schr06], Seite 26

³⁰ Siehe auch [Schr06], Seite 26

³¹ Siehe auch [Schr06], Seite 30

³² Siehe auch [Azev06], Seite 265

³³ Vergleiche [Urba07]

³⁴ Siehe auch [Urba07]

³⁵ Siehe hierzu auch [Schu06]