Business Intelligence - Grundlagen und praktische Anwendungen: Eine Einfuhrung in die IT-basierte Managementunterstutzung. Mit Online-Service. 3. Auflage (Studium)

Hans-Georg Kemper | Henning Baars | Walid Mehanna Business Intelligence – Grundlagen und praktische Anwendungen

Hans-Georg Kemper | Henning Baars | Walid Mehanna

Business Intelligence – Grundlagen und praktische Anwendungen Eine Einführung in die IT-basierte Managementunterstützung 3., überarbeitete und erweiterte Auflage Mit 113 Abbildungen STUDIUM

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

Das in diesem Werk enthaltene Programm-Material ist mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht. Höchste inhaltliche und technische Qualität unserer Produkte ist unser Ziel. Bei der Produktion und Auslieferung unserer Bücher wollen wir die Umwelt schonen: Dieses Buch ist auf säurefreiem und chlorfrei gebleichtem Papier gedruckt. Die Einschweißfolie besteht aus Polyäthylen und damit aus organischen Grundstoffen, die weder bei der Herstellung noch bei der Verbrennung Schadstoffe freisetzen.

1. Auflage 2004 2. Auflage 2006 3., überarbeitete und erweiterte Auflage 2010 Alle Rechte vorbehalten © Vieweg +Teubner Verlag | Springer Fachmedien Wiesbaden GmbH 2010 Lektorat: Christel Roß | Maren Mithöfer Vieweg+Teubner Verlag ist eine Marke von Springer Fachmedien. Springer Fachmedien ist Teil der Fachverlagsgruppe Springer Science+Business Media.. www.viewegteubner.de Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften. Umschlaggestaltung: KünkelLopka Medienentwicklung, Heidelberg Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-0719-9

Vorwort zur 3. Auflage Business Intelligence (BI) hat sich in Wissenschaft und Praxis als Begriff für IT-Lösungen der Managementunterstützung etabliert. Das vorliegende Buch beschäftigt sich detailliert mit diesem Themenkomplex und liefert auf der Basis eines Ordnungsrahmens einen fundierten Einblick in den Themenbereich. Die folgende Darstellung verdeutlicht die Struktur des Buches:

Kapitel 1: Business Intelligence — Begriffsabgrenzung und Ordnungsrahmen Kapitel 2: Datenbereitstellung und -modellierung Kapitel 3: Informationsgenerierung, -speicherung, -distribution und -zugriff Kapitel 4: Entwicklung und Betrieb integrierter BI-Lösungen Kapitel 5: Praktische Anwendungen Kapitel 6: Ausblick

Das Buch wurde in der 3. Auflage aktualisiert und ergänzt. So sind die integrierte BI-Architektur um Komponenten zur Integration unstrukturierter Informationen angereichert, die Abschnitte zur Informationsdistribution und zum Informationszugriff neu gestaltet sowie der Entwicklungs-/Betriebsbereich neu strukturiert und um strategisch orientierte BI-Governance-Ansätze sowie um BI-Service-Konzepte erweitert worden. Ferner wurden neue Praxisbeispiele im Kapitel 5 eingebunden, die den veränderten BI-Rahmenbedingungen der letzten Jahre Rechnung tragen. Das Buch endet mit einem Kapitel, in dem zukünftige Entwicklungen in technischen, organisatorischen und anwendungsorientierten Feldern vorgestellt und kritisch diskutiert werden.

V

Das Werk ist anwendungsorientiert ausgerichtet und richtet sich bewusst sowohl an Praktiker als auch an Lehrende sowie Studierende der Wirtschaftsinformatik. Die Abbildungen des Buches sind zum Download unter der URL http://www.wi.uni-stuttgart.de/bi-buch verfügbar. Es sei an dieser Stelle allen gedankt, die durch ihre engagierte Mitarbeit die Erstellung des Werkes aktiv unterstützt haben. Insbesondere gilt unser Dank Frau Viola Koppetzki, Frau Stefanie Wenk, Herrn Jens Lachenmaier und Herrn Christian Bauer für die redaktionelle Unterstützung sowie den Vertretern der Anwenderunternehmen, die als Interviewpartner wertvolle Anregungen für die Darstellung der Fallstudien geliefert haben. Hans-Georg Kemper Henning Baars Walid Mehanna

VI

Stuttgart, im April 2010

Inhaltsverzeichnis 1

Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen .......... 1 1.1 Business Intelligence ......................................................................................... 1 1.2 Definitionsvielfalt ............................................................................................... 2 1.3 Veränderungen im Unternehmensumfeld ........................................................ 5 1.4 Business Intelligence als integrierter Gesamtansatz ........................................ 8 1.5 Business Intelligence – Ordnungsrahmen...................................................... 10

2

Datenbereitstellung und -modellierung ..................................................... 15 2.1 Historisch gewachsene Formen der dispositiven Datenhaltung................... 15 2.2 Data-Warehouse-Konzept ............................................................................... 19 2.2.1

Begriff Data Warehouse ...................................................................... 19

2.2.2

Gängige Architekturvarianten von DWH-/Data-Mart-Lösungen ....... 21

2.2.3

Architektur ODS-erweiterter Data Warehouses ................................. 24

2.3 Detaillierung ODS-erweiterter Data Warehouses .......................................... 26 2.3.1

Transformationsprozess – ETL ............................................................ 26

2.3.2

Core Data Warehouse und Data Marts............................................... 39

2.3.3

Operational Data Store ........................................................................ 43

2.3.4

Metadaten ............................................................................................. 47

2.3.5

Berechtigungsstrukturen...................................................................... 54

2.3.6

Administrationsschnittstellen ............................................................... 56

2.4 Modellierung multidimensionaler Datenräume ............................................. 58 2.4.1

Grundlagen der Datenmodellierung .................................................. 58

2.4.2

Star-Schema und Varianten ................................................................. 66

2.4.3

Snowflake-Schema ............................................................................... 70

2.4.4

Konzepte der Historisierung ............................................................... 71

2.4.5

Fallbeispiel ........................................................................................... 77

2.5 Zusammenfassung ........................................................................................... 82 3

Informationsgenerierung, -speicherung, -distribution und -zugriff ........ 85 3.1 Informationsgenerierung: Analysesysteme ..................................................... 85 3.1.1

Konventionelle Klassifizierungen ....................................................... 85

3.1.2

BI-Analysesysteme – Ordnungsschema ............................................. 87 VII

Inhaltsverzeichnis 3.1.3

DWH-Implementierungsansätze ......................................................... 90

3.1.4

Freie Datenrecherche .......................................................................... 96

3.1.5

OLAP..................................................................................................... 99

3.1.6

Modellgestützte Analysesysteme ........................................................110

3.1.7

Berichtssysteme...................................................................................124

3.1.8

Konzeptorientierte Systeme ...............................................................131

3.2 Informationsdistribution: Content und Document Management .................141 3.2.1

Werkzeuge für das betriebliche Wissensmanagement .....................142

3.2.2

Content- und Document-Management-Systeme im BI-Kontext ......145

3.2.3

Distribution von BI-Ergebnissen und BI-(Teil)-Systemen ................148

3.3 Informationszugriff: Portale ............................................................................152 3.3.1

Einordnung des Portalbegriffs ...........................................................154

3.3.2

Portal-Personalisierung .......................................................................156

3.3.3

Integration von Inhalten.....................................................................157

3.4 Zusammenfassung ..........................................................................................160 4

Entwicklung und Betrieb integrierter BI-Lösungen ................................ 163 4.1 Vorbemerkungen ............................................................................................163 4.2 Konzept integrierter BI-Ansätze .....................................................................165 4.3 Makro-Ebene ...................................................................................................167 4.3.1

Potenzialplanung ................................................................................170

4.3.2

Portfoliomanagement .........................................................................174

4.3.3

Technologie- und Infrastrukturmanagement ....................................176

4.3.4

BI Service und Sourcing Policies .......................................................178

4.3.5

Dispositive Datenarchitektur ..............................................................182

4.3.6

Entwicklungs- und Betriebs-Rahmenbedingungen ..........................184

4.3.7

Controlling...........................................................................................187

4.3.8

Organisatorische Gestaltung ..............................................................189

4.4 Mikro-Ebene ....................................................................................................196 4.4.1

Entwicklungs-Modell ..........................................................................198

4.4.2

Betriebs-Modell ...................................................................................202

4.4.3

Reengineering-Modell.........................................................................205

4.4.4

Organisatorische Gestaltung ..............................................................206

4.5 Zusammenfassung ..........................................................................................207 VIII

5

Praktische Anwendungen ......................................................................... 209 5.1 Data-Mart-basierte BI-Anwendung eines Finanzdienstleisters .....................209 5.2 ODS-erweiterter BI-Ansatz eines Telekommunikationsanbieters ................213 5.3 Data-Mart-basierte CRM-Anwendung im Einzelhandel ................................219 5.4 Real-time Data Warehousing einer Börsenorganisation ...............................224 5.5 Agil entwickeltes BI-System einer Bankgesellschaft.....................................229 5.6 Unternehmensübergreifende BI eines Bundesverbandes ............................232 5.7 Data Warehousing in einer RFID-basierten Retail Supply Chain ................235 5.8 Operational BI in der Nutzfahrzeugproduktion ...........................................239 5.9 Template-basierte BI-Koordination im Konzernverbund .............................243

6

Ausblick ...................................................................................................... 249 6.1 Entwicklungen im Bereich der Hard- und Software-Infrastruktur ..............249 6.2 Entwicklungen im Bereich der BI-Organisation ...........................................254 6.3 Ausbau von BI-Anwendungsdomänen .........................................................257 6.4 Abschließende Bemerkungen ........................................................................262

Abkürzungsverzeichnis .................................................................................... 263 Abbildungsverzeichnis ..................................................................................... 267 Literaturverzeichnis ......................................................................................... 271 Sachwortverzeichnis ........................................................................................ 293

IX

1

Business Intelligence — Begriffsabgrenzung und Ordnungsrahmen Im Mittelpunkt des ersten Kapitels stehen die Abgrenzung des Begriffes Business Intelligence (BI) und die Entwicklung eines BI-Rahmenkonzeptes, das den grundlegenden Ordnungsrahmen für das vorliegende Werk bildet.

1.1

Management Support Systems

Business Intelligence Die IT-basierte Managementunterstützung besitzt eine lange Historie. Bereits mit dem Beginn der kommerziellen Nutzung der elektronischen Datenverarbeitung in den 60er Jahren des letzten Jahrhunderts begannen erste Versuche, die Führungskräfte mit Hilfe von Informationssystemen zu unterstützen. Vor dem Hintergrund enthusiastischer Technikgläubigkeit und eines eher mechanistisch ausgerichteten Organisationsverständnisses entstanden umfassende Ansätze, die jedoch allesamt scheiterten. Erst im Laufe der Jahre gelang es, benutzergruppenspezifische und aufgabenorientierte Einzelsysteme zu entwickeln, die erfolgreich im Management eingesetzt werden konnten. In den 80er Jahren etablierte sich für dieses Konglomerat von Informationsund Kommunikationssystemen der Sammelbegriff „Management Support Systems“ (MSS) – im Deutschen als „Managementunterstützungssysteme“ (MUS) bezeichnet. Scott Morton, einer der Protagonisten dieses Ansatzes, definierte den Begriff Management Support Systems als „the use of computers and related information technologies to support managers“ (Scott Morton 1983, S. 5). Somit wurde bereits vor Jahrzehnten verdeutlicht, dass die Unterstützung des Managements sich nicht auf den isolierten Einsatz von Computern beschränken kann, sondern das gesamte Umfeld der Informations- und Kommunikationstechnologie umfasst. Scott Morton konstatierte zu dieser Zeit bereits treffend: „For example, teleconferencing, electronic data bases, and graphic workstations are all information technologies that are potentially useful for MSS.” (Scott Morton 1983, S. 5). Obwohl sich gerade im letzten Jahrzehnt aufgrund umfangreicher technologischer Entwicklungen grundlegende Veränderungen im Bereich der IT-basierten Managementunterstützung erge1

1 Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen ben haben, ist der Sammelbegriff „Management Support Systems“ auch heute noch gebräuchlich und findet insbesondere in der Wissenschaft weiterhin Verwendung. In der betrieblichen Praxis hat sich jedoch seit Mitte der 90er Jahre eine neue Bezeichnung entwickelt und dort auch bereits umfassend etabliert. „Business Intelligence“ (BI) heißt der vielschichtige Begriff. Er lässt sich primär auf Überlegungen der Gartner Group aus dem Jahre 1996 zurückführen (Hervorhebungen und Formate durch die Autoren, Inhalte übernommen aus Anandarajan et al. 2004, S. 18 f.): • „By 2000, Information Democracy will emerge in forwardthinking enterprises, with Business Intelligence information and applications available broadly to employees, consultants, customers, suppliers, and the public. BI-Begriff in der Praxis

• The key to thriving in a competitive marketplace is staying ahead of the competition. • Making sound business decisions based on accurate and current information takes more than intuition. • Data analysis, reporting, and query tools can help business users wade through a sea of data to synthesize valuable information from it – today these tools collectively fall into a category called ´Business Intelligence´.” Bei genauerer Untersuchung dieser Begriffsherleitung kann festgehalten werden, dass aus wissenschaftlicher Sicht kaum stichhaltige Argumente für die Notwendigkeit einer derartigen Begrifflichkeit existieren. BI wird in der frühen, marketingorientierten Abgrenzung vielmehr als Sammelbezeichnung für FrontendWerkzeuge verstanden und ist als begriffliche Klammer für diese Systemkategorie überflüssig. Trotzdem haben diese ersten Überlegungen zunächst in der Praxis und zeitversetzt auch in der Wissenschaft zu intensiven Diskussionen um eine Neuorientierung der IT-basierten Managementunterstützung geführt.

1.2

Definitionsvielfalt Die anfängliche Unsicherheit im Umgang mit dem Begriff Business Intelligence wird von Mertens prägnant dargestellt. Bei seiner Untersuchung gängiger BI-Abgrenzungen identifiziert er sieben unterschiedliche Varianten (Mertens 2002, S. 4):

2

1.2 Definitionsvielfalt „1. BI als Fortsetzung der Daten- und Informationsverarbeitung: IV für die Unternehmensleitung 2. BI als Filter in der Informationsflut: Informationslogistik 3. BI = MIS, aber besonders schnelle/flexible Auswertungen 4. BI als Frühwarnsystem („Alerting“) 5. BI = Data Warehouse 6. BI als Informations- und Wissensspeicherung 7. BI als Prozess: Symptomerhebung Prognose Æ Therapiekontrolle.“

Æ

Diagnose

Æ

Therapie

Æ

Eine genauere Betrachtung der verfügbaren Begriffsbestimmungen macht deutlich, dass das Gros der Definitionen Business Intelligence über die verwendeten Systeme abgrenzt. Eine typische Definition bieten beispielsweise Chamoni und Gluchowski. Sie sehen in BI einen Sammelbegriff „zur Kennzeichnung von Systemen […], die auf der Basis interner Leistungs- und Abrechnungsdaten sowie externer Marktdaten in der Lage sind, das Management in seiner planenden, steuernden und koordinierenden Tätigkeit zu unterstützen“ (Chamoni/Gluchowski 2004, S. 119).

Einordnung von BI-Systemen

Eine treffende Strukturierung der möglichen Sichtweisen liefert Gluchowski mit Hilfe eines zweidimensionalen Ordnungsrahmens (vgl. Abb. 1.1). Auf der vertikalen Achse werden die jeweiligen Phasen des analytischen Datenverarbeitungsprozesses aufgetragen (von der Bereitstellung bis zur Auswertung), während die horizontale Achse den Schwerpunkt zwischen Technik- und Anwendungsorientierung definiert. Aufgrund der Positionierung von Anwendungsklassen lassen sich hierbei drei gängige Typen von Definitionsansätzen abgrenzen: • Enges BI-Verständnis Unter Business Intelligence i. e. S. werden lediglich wenige Kernapplikationen verstanden, die eine Entscheidungsfindung unmittelbar unterstützen. Hierbei sind vor allem das Online Analytical Processing (OLAP) und die Management Information Systems (MIS) bzw. Executive Information Systems (EIS) zu nennen.1

1 Eine detaillierte Erläuterung der Konzepte und Technologien erfolgt in

den Kapiteln 2 und 3.

3

1 Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen • Analyseorientiertes BI-Verständnis Business Intelligence im analyseorientierten Sinne umfasst sämtliche Anwendungen, bei denen der Entscheider (oder auch der Entscheidungsvorbereiter) direkt mit dem System arbeitet, d. h. einen unmittelbaren Zugriff auf eine Benutzungsoberfläche mit interaktiven Funktionen besitzt. Hierzu gehören neben OLAP und MIS/EIS auch Systeme des Text Mining und des Data Mining, das Ad-hoc-Reporting sowie Balanced Scorecards, der Bereich des analytischen Customer Relationship Management und Systeme zur Unterstützung der Planung und Konsolidierung. • Weites BI-Verständnis Unter Business Intelligence i. w. S. werden alle direkt und indirekt für die Entscheidungsunterstützung eingesetzten Anwendungen verstanden. Dieses beinhaltet neben der Auswertungsund Präsentationsfunktionalität auch die Datenaufbereitung und -speicherung. Prozessphase Datenbereitstellung

Weites BIVerständnis

Extraktion, Transformation Data Warehouse Standard

Enges BIVerständnis

Reporting Ad-hoc Text Mining Data Mining

Datenauswertung Technik

Abb. 1.1:

OLAP

MIS/ EIS

Kennzahlen-/ BSC-Systeme Analytisches CRM Planung/ Konsolidierung

Anwendung

Analyseorientiertes BIVerständnis

Schwerpunkt

Unterschiedliche Facetten von Business Intelligence (modifiziert übernommen aus Gluchowski 2001, S. 7)

Die Einordnung der verschiedenen Definitionsansätze zum Themenbereich Business Intelligence ist nicht frei von Kritik geblieben. So wirken viele Ansätze nicht trennscharf, weisen zum Teil

4

1.3 Veränderungen im Unternehmensumfeld einen hohen Grad an Beliebigkeit auf oder lassen Abgrenzungen zu bestehenden Ansätzen vermissen. Langfristig kann Business Intelligence nur überzeugen, wenn es als eigenständiges Konzept der Managementunterstützung innovative Lösungen offeriert und sich qualitativ von althergebrachten Ansätzen unterscheidet. Im Folgenden wird dieser Bereich thematisiert, wobei zunächst auf die Veränderungen in der Unternehmensumwelt eingegangen wird, denen sich sämtliche Organisationen seit mehreren Jahren zu stellen haben.

1.3

Veränderungen im Unternehmensumfeld Globalisierung

Konsequenzen

Intensive Diskussionen über Veränderungen der Wettbewerbsbedingungen aufgrund einer weltweiten Öffnung von Güter-, Arbeits- und Informationsmärkten begannen bereits in den 80er Jahren (Porter 1986, S. 19 f.). Seit einiger Zeit steigen jedoch die Dynamik und die Tragweite dieser Entwicklungen erheblich. Längst vorbei sind die Zeiten, in denen Globalisierungsstrategien ausschließlich als Option ambitionierter Unternehmen galten, um neue Märkte zu erschließen und zusätzliches Wachstum zu generieren. In der Realität sind heute nahezu sämtliche Unternehmen mit den Konsequenzen der veränderten Rahmenbedingungen konfrontiert. So beschäftigen sich Institutionen wie die Welthandelsorganisation WTO (World Trade Organization) und der Internationale Währungsfond (IWF) mit der Regelung und Intensivierung von globalen Handels- und Wirtschaftsbeziehungen. Darüber hinaus senken regionale Freihandelsabkommen und Staatenverbunde wie die Europäische Union die Markteintrittsbarrieren für viele Unternehmen. Die weltweite Marktöffnung ist somit Realität und birgt Chancen und Risiken für große und mittelständische Unternehmen (Abel et al. (Hrsg.), 2006), die sich in neuen Handels- und Diversifizierungsmöglichkeiten und einem erhöhten Konkurrenzdruck manifestieren.

Stakeholder Neben den Vertretern von Beschaffungs- und Absatzmärkten haben weitere Akteure ein berechtigtes Interesse und direkten oder indirekten Einfluss auf Unternehmen. Bei börsennotierten Unternehmen sind hierbei vor allem Investoren zu nennen, aber auch Umweltschutzorganisationen und behördliche Institutionen 5

1 Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen (Finanz- und Steuerbehörden) fallen in die Kategorie der Anspruchsgruppen Stakeholder. Daraus resultieren teilweise konkrete und umfangreiche Anforderungen an das Management. Verbindlich für alle Unternehmen ist die Rechnungslegung nach festen Standards: Die Dokumentation der betrieblichen Vorgänge in Form von Bilanz, Gewinnund Verlustrechnung und erläuterndem Anhang ist vorgegeben durch internationale Vorschriften wie den „International Financial Reporting Standards“ (IFRS) oder nationalen Regularien wie dem Handelsgesetzbuch (HGB) (z. B. Ruhnke 2008). Weiterhin schreibt das „Gesetz zur Kontrolle und Transparenz im Unternehmensbereich“ (KonTraG) für Aktiengesellschaften den Einsatz eines Risikomanagementsystems vor (z. B. Wolf/Runzheimer 2009). Ergänzt werden diese rechtsformspezifischen Anforderungen durch branchenspezifische Richtlinien und Vorgaben. Exemplarisch ist das EU-Projekt „Solvency II“ zu nennen, das für Versicherungen u. a. die Offenlegung der Ausstattung mit Eigenmitteln (Solvabilität) regelt (z. B. Romeike/Müller-Reichart 2008, S. 115 ff.). Ein gewichtiges Thema für Banken sind die Eigenkapitalvereinbarungen „Basel II“, welche u. a. die Kreditvergabe an Unternehmen über ein Ratingsystem beschreibt (z. B. Buchmüller 2008). Die genannten externen Anforderungen werden kontinuierlich weiterentwickelt und angepasst. Sie erfordern daher von Seiten der Unternehmen eine hohe Flexibilität und Reaktionsfähigkeit.

E-Business

Digitale Evolution

6

Ohne Frage ist die Internettechnologie eine der treibenden Kräfte für die gravierenden Veränderungen in nahezu sämtlichen gesellschaftspolitischen, volkswirtschaftlichen und betriebswirtschaftlichen Bereichen. Wenngleich auch die „Digitale Revolution“ ausgeblieben und die Entwicklung eher als „Digitale Evolution“ zu bezeichnen ist, stellt das Internet heute eine Herausforderung für die gesamte Ökonomie dar. Die Verfügbarkeit einer gemeinsamen Kommunikationsplattform ermöglicht E-Business im Sinne der „teilweise[n] [...] [bzw.] vollständige[n] Unterstützung, Abwicklung und Aufrechterhaltung von Leistungsaustauschprozessen mittels elektronischer Netze“ (Wirtz 2001, S. 29). Der Begriff der Leistungsaustauschprozesse beschreibt dabei den Transfer von materiellen und immateriellen Gütern sowie von Dienstleistungen.

1.3 Veränderungen im Unternehmensumfeld Aufgrund der neuen Möglichkeiten hat sich das wirtschaftliche Umfeld drastisch verändert. Die Beziehungen auf der Lieferanten- und Kundenseite wurden intensiviert und in vielen Bereichen teilweise oder vollständig digitalisiert. Vor allem auf der Ebene der operativen Informations- und Kommunikationssysteme sind hierdurch große Entwicklungssprünge initiiert worden (z. B. Kemper/Lee 2002, S. 13 ff.). Das E-Business hat sich in der Zwischenzeit etabliert und ist, wenn auch mit unterschiedlicher Intensität, branchenübergreifend realisiert (European Commission, The Sectoral e-Business Watch (Hrsg.) 2008). E-Business ermöglicht Integration

Zulieferer

Unternehmen

Kunde

Beschaffung Produktion

Vertrieb

E-Procurement

CRM

Multi Channel

SCM ERP

Wert-

schöpfungs-

kette

Güter & Information Information Legende ERP Enterprise Resource Planning CRM Customer Relationship Management

Abb. 1.2:

SCM Supply Chain Management

E-Business und Wertschöpfung (Kemper/Lee 2002, S. 14)

Die Abb. 1.2 zeigt die typischen operativen Anwendungssysteme im Bereich des E-Business in ihren Ausprägungen als IntraBusiness-, Business-to-Business- und Business-to-ConsumerAnwendungen. Wie deutlich wird, unterstützen diese Systeme des E-Business primär die Wertschöpfungskette einer Unterneh7

1 Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen mung. Während ERP-Systeme (Enterprise Resource Planning) hierbei vor allem die integrierte Abwicklung operativer Prozesse innerhalb des Unternehmens fokussieren, umfassen die anderen Systeme die Aktivitäten zur Unterstützung des gesamten Leistungsaustauschprozesses vom Lieferanten bis zum Kunden. So dienen SCM-Systeme (Supply Chain Management) zur Optimierung der gesamten Lieferkette vom Rohmaterialproduzenten bis zu dem Verkauf der fertiggestellten Produkte (Staberhofer/Rohrhofer 2007, S. 38). Internetbasierte E-Procurement-Systeme unterstützen die elektronische Beschaffung. CRM-Systeme (Customer Relationship Management) ermöglichen die Koordination aller genutzten Vertriebskanäle (Multi Channel) und liefern Hilfen für die Pflege und Auswertung von Kundenbeziehungen (Hippner et al. 2006, S. 45 ff.).

1.4

Business Intelligence als integrierter Gesamtansatz Die stetige Ausweitung der Datenbasis, die massive Veränderung des Marktumfelds und immer höhere interne und externe Anforderungen an Transparenz und Fundierung der Entscheidungen sind zwingend in die Kalküle einer erfolgreichen Unternehmenssteuerung einzubeziehen. Althergebrachte Einzelsysteme zur Managementunterstützung können diesen Anforderungen nicht mehr genügen. Wie die beschriebenen Kontextfaktoren darstellen, sind isolierte oder punktuelle Lösungsansätze nicht ausreichend, da sie nur einzelne Aspekte behandeln und häufig auf isolierten Datenbasen aufbauen.

Intelligence als Information

Integrierte Lösungsansätze sind somit erforderlich und es erscheint durchaus gerechtfertigt, bei grundlegenden Umorientierungen im Bereich der IT-basierten Managementunterstützung neue Begrifflichkeiten zu verwenden. In diesem Sinne wird im Weiteren Business Intelligence interpretiert, wobei der bedeutungsreiche englische Begriff Intelligence in diesem Zusammenhang als Information zu verstehen ist, die es zu generieren, speichern, recherchieren, analysieren, interpretieren und zu verteilen gilt. Business Intelligence beschreibt in diesem Werk einen integrierten, unternehmensspezifischen Gesamtansatz. In Abgrenzung zu vielen anderen Definitionen dienen erwerbbare BI-Werkzeuge daher ausschließlich als Entwicklungshilfen spezieller BIAnwendungen. Das bedeutet, dass z. B. Tools zum Aufbau von Data Warehouses, OLAP-Frontends oder Portalsoftware lediglich mittelbaren Charakter besitzen.

8

1.4 Business Intelligence als integrierter Gesamtansatz Auch einzelne, mit den o. a. Werkzeugen entwickelte BI-Anwendungssysteme konkretisieren nach diesem Definitionsansatz jeweils nur einen Teilaspekt eines unternehmensspezifischen BIAnsatzes. So reflektieren z. B. Data-Mart-basierte Controllinganwendungen oder CRM-Lösungen für den Vertrieb nur einzelne Bereiche des BI-Ansatzes eines Unternehmens. Definition Business Intelligence

!

Business Intelligence (BI) bezeichnet einen integrierten, unternehmensspezifischen, IT-basierten Gesamtansatz zur betrieblichen Entscheidungsunterstützung. • BI-Werkzeuge dienen ausschließlich der Entwicklung von BI-Anwendungen. • BI-Anwendungssysteme bilden Teilaspekte des BIGesamtansatzes ab.

Die Abb. 1.3 verdeutlicht den Einsatzbereich umfassender BIAnwendungssysteme in Unternehmen. Führungssystem

Management

Koordination & Unterstützung

Top Externe

Business

Daten

Middle

Intelligence Lower

Planen Steuern

Interne

Überwachen

Daten

Ausführungssystem Operative Informations- und Kommunikationssysteme

Abb. 1.3:

Wertschöpfende Prozesse

Einsatzfeld von BI-Anwendungssystemen

9

1 Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen Wie ersichtlich, liegt der Einsatzbereich von BI-Anwendungssystemen im gesamten Führungssystem einer Organisation. Adressaten für BI-Lösungen sind demnach Mitarbeiter aller Managementebenen. Top Management

Das Top Management umfasst den Kreis der obersten Führungskräfte. Hierunter fallen Vorstände, Geschäftsführer sowie leitende Angestellte, die nicht-delegierbare Entscheidungen von strategischer Bedeutung treffen.

Middle Management

Das Middle Management besteht aus Mitarbeitern, die Entscheidungen vorbereiten und gefällte Entscheidungen der obersten Managementebene in konkrete Programme und Pläne umsetzen, wobei sie ebenfalls für die Erfüllung dieser Vorgaben verantwortlich sind.

Lower Management

Das Lower Management bildet die Schnittstelle zu den operativen Einheiten des Ausführungssystems. Ihr Verantwortungsbereich ist meist die Planung, Steuerung und Kontrolle von überschaubaren ausführenden Organisationseinheiten.

Koordination & Unterstützung

Aufgrund der Komplexität des Führungssystems sind neben dem eigentlichen Management auch unterstützende Organisationseinheiten in vielen Entscheidungsprozessen als Entscheidungsvorbereiter involviert. Das Controlling beispielsweise sieht die Koordination der Planung und Kontrolle sowie der Informationsversorgung als seine Kernaufgabe.

1.5

Business Intelligence — Ordnungsrahmen Business Intelligence als integrierter, IT-basierter Gesamtansatz kann gemäß der Definition lediglich unternehmensspezifisch konkretisiert werden. Selbstverständlich kann diese individuelle Ausgestaltung ausschließlich auf der Basis eines generischen Konzeptes erfolgen, das in Form eines Frameworks den Raum für die unternehmensindividuelle Gestaltung des jeweiligen BIAnsatzes determiniert. Dieses Konstrukt wird im Folgenden als BI-Ordnungsrahmen bezeichnet und dient in weiten Teilen dieses Buches als Strukturierungsgrundlage des Inhaltes. Die Abb. 1.4 verdeutlicht den Aufbau des dreischichtigen BIOrdnungsrahmens (modifiziert übernommen aus Kemper/Baars 2006, S. 10 f.).

10

1.5 Business Intelligence – Ordnungsrahmen

Business Intelligence (BI) Informationszugriff

Informationsgenerierung/ -distribution

Data Mart Core Data Warehouse Operational Data Store

Datenbereitstellung

Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Abb. 1.4: Externe/operative Vorsysteme

Produktionsorientierte Vorsysteme

Informationsdistribution

Analysesysteme

Systemintegration

Metadaten

BI-Portal

Content & Document Mgmt.

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

Externe Daten

BI-Ordnungsrahmen

Dem BI-Ordnungsrahmen vorgelagert sind die externen/operativen Quellsysteme. In innovativen BI-Ansätzen der industriellen Unternehmen erfahren hierbei in jüngerer Zeit neben den bereits beschriebenen SCM-, E-Procurement-, ERP- und CRM-Systemen zusätzlich vermehrt operative Quellsysteme größerer Bedeutung, die in den Bereichen der Produktentwicklung und Produktion eingesetzt werden. Hierzu zählen CAx-, PPS-, PDM/PLM-Systeme und MES. Unter CAx werden die sog. „Computer Aided“ Technologien wie Computer Aided Design (CAD), Computer Aided Manufacturing (CAM) oder Computer Aided Engineering (CAE) verstanden. PPS-Systeme unterstützen die Produktionsplanung und -steuerung. MES dienen als Manufacturing Execution Systems der effizienten Fertigungsprozessdurchführung auf der Shop Floor-Ebene und PDM/PLM-Systeme stellen integrierte Lösungen des Produktdaten- und des Produktlebenszyklusmanagements dar. (z. B. Vajna et al. 2009, S. 12 ff. und Mertens 2005, S. 28 ff.). In der ersten Schicht des BI-Ordnungsrahmens sind aus all diesen Quellsystemen konsistente, stimmige Daten zu generieren und adäquat abzulegen. Hierbei lassen sich strukturierte (numerische) und unstrukturierte Daten unterscheiden.

11

1 Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen Die Bereitstellung strukturierter Daten erfolgt in aller Regel mit Hilfe von sog. Data-Warehouse-Konzepten, die aus Core Data Warehouses und Data Marts bestehen. Sie definieren sich als themenbezogene, integrierte Datenhaltungen, bei denen das aus Managementsicht gewünschte, meist voraggregierte Datenmaterial dauerhaft – also historienbildend – abgelegt wird.

Datenvolumina

Die Anfang der 90er Jahre eingeführten Data Warehouses wiesen meist ein überschaubares Datenvolumen auf. In Zeiten des E-Business verändern sich jedoch die Ausrichtung und das Datenvolumen von Data-Warehouse-Lösungen gravierend. So können beispielsweise kundenzentrierte Data Warehouses umsatzstarker Handelshäuser Größen bis zum zwei- oder dreistelligen Terabyte-Bereich – teilweise sogar bis in den Petabyte-Bereich – aufweisen. Sie sollen die Daten aller Kunden über deren gesamten Lebenszyklus möglichst detailliert vorhalten und kanalübergreifend integrieren. Häufig ist in neueren Architekturdarstellungen zusätzlich ein spezieller Datenpool – ein sog. Operational Data Store (ODS) – integriert, der als Vorstufe eines analytischen Data Warehouse aktuelle transaktionsorientierte Daten aus verschiedenen Quellsystemen beinhaltet und für spezielle Anwendungs- und Auswertungszwecke bereitstellt (Inmon et al. 2000, S. 218 f.). Unstrukturierte Daten werden in aller Regel in sog. Content- und Document Management Systems vorgehalten. Hierbei können in Content Management Systems (CMS) Informationsobjekte mit beliebiger elektronischer Darstellungsform (Daten, Texte, Graphiken, Bilder, Audio-/Videosequenzen) eingebunden werden, wobei aus Gründen der Mehrfachverwendbarkeit eine strikte Trennung von Inhalt, Layout und Struktur erfolgt. Unter Document Management Systems (DMS) werden hingegen meist Systeme verstanden, die unstrukturierte, digitalisierte (eingescannte) Dokumente bereitstellen und über Funktionen zu deren Archivierung, Verschlagwortung, Versionierung und Visualisierung verfügen.

Informationsgenerierung

Systeme zur Informationsgenerierung gehören zur mittleren Schicht des Ordnungsrahmens. In diesem Kontext lassen sich unterschiedliche Systeme abgrenzen, die sich im Grad ihrer Anwendungsausrichtung, der Nutzungsfrequenz, der erforderlichen IT-Kompetenz der Benutzer und der Form der Nutzungsinitiierung unterscheiden.

Informationsdistribution

In jüngeren BI-Ansätzen erfolgt bewusst eine Ergänzung des Konzepts um Systeme zur Informationsdistribution. Sie stellen

12

1.5 Business Intelligence – Ordnungsrahmen die Schnittstelle zwischen Business Intelligence und Ansätzen des betrieblichen Wissensmanagements dar. So soll durch diese Verbindung zum einen sichergestellt werden, dass das im BIKontext erzeugte kodifizierbare – also digital speicherungsfähige – Wissen archiviert und bei Bedarf anderen Entscheidungsträgern des Unternehmens zur Verfügung gestellt werden kann. Zum anderen können mit Hilfe dieser Systeme existierende unstrukturierte, qualitative Inhalte in BI-Analysen einbezogen werden und sie somit inhaltlich anreichern. Informationszugriff

Komfortable Benutzerschnittstellen sind erforderlich, um die vielfältigen steuerungsrelevanten Informationen abrufen zu können. Dieser Zugriff erfolgt in der Regel mit Hilfe sog. Portale, die dem Benutzer über das Firmen-Intranet einen zentralen Einstiegspunkt für verschiedene Analysesysteme bieten. Durch Verwendung des Single-Sign-On-Prinzips können mehrere Anmeldeprozeduren an verschiedenen Systemen durch ein komfortables, einmaliges Anmelden ersetzt werden. Des Weiteren werden mit Hilfe von Personalisierungstechniken benutzerspezifische und rollenorientierte Benutzungsoberflächen zur Verfügung gestellt.

13

2

Datenbereitstellung und -modellierung Die Aufbereitung und Speicherung konsistenter, betriebswirtschaftlich auf die Belange der Manager ausgerichteter Daten ist die Grundvoraussetzung für den Einsatz leistungsfähiger BIAnwendungssysteme. Das folgende Kapitel beschäftigt sich mit diesem Themenkomplex, wobei zunächst die historisch gewachsenen Formen der Datenhaltung erläutert werden. Es folgen eine detaillierte Beschreibung neuerer Data-Warehouse-Konzepte und Ansätze sog. Operational Data Stores. Das Kapitel schließt mit grundlegenden Designfragen der Modellierung dispositiver Daten.

2.1

Dispositive Arbeitsleistung nach Gutenberg

Operative Daten

Historisch gewachsene Formen der dispositiven Datenhaltung Der Begriff der dispositiven Arbeitsleistung geht ursprünglich auf Erich Gutenberg zurück: „Unter objektbezogenen Arbeitsleistungen werden alle diejenigen Tätigkeiten verstanden, die unmittelbar mit der Leistungserstellung, der Leistungsverwertung und mit finanziellen Aufgaben in Zusammenhang stehen, ohne dispositivanordnender Natur zu sein. [...] Dispositive Arbeitsleistungen liegen dagegen vor, wenn es sich um Arbeiten handelt, die mit der Leitung und Lenkung der betrieblichen Vorgänge in Zusammenhang stehen.“ (Gutenberg 1983, S. 3). In Anlehnung an diese klassische Definition dispositiver Arbeitsleistung können Informationssysteme nach der Art der unterstützten Arbeitsinhalte in operative und dispositive Systeme unterschieden werden, wobei die zugehörigen Daten dieser Systeme in operative2 und dispositive3 Daten unterteilt werden können. Operative Daten werden von Administrations-, Dispositions- und Abrechnungssystemen generiert und/oder verarbeitet. Große

2

„operativ [lat.-nlat.]: [...] (besonders Wirtschaft) konkrete Maßnahmen betreffend, die unmittelbar wirksam werden (Dudenredaktion (Hrsg.) 2006, S. 732).

3

„dispositiv [lat.-nlat.]: anordnend, verfügend […]“ Dudenredaktion (Hrsg.) 2006, S. 240).

15

2 Datenbereitstellung und -modellierung Teile der operativen Daten werden hierbei von sog. OnlineTransaction-Processing-Systemen (OLTP-Systemen) erzeugt, bei denen mehrere Benutzer im Teilhaberbetrieb sich derselben Systeme und Datenbestände bedienen, wie beispielsweise bei Auskunfts-, Buchungs- und Bestellsystemen.

Dispositive Daten

In Abgrenzung zu den operativen Daten werden die für managementunterstützende Systeme erforderlichen Daten als dispositive Daten bezeichnet. Wie die Abb. 2.1 verdeutlicht, unterscheiden sich diese Daten erheblich von dem operativen Datenmaterial, so dass ein direkter Durchgriff von managementunterstützenden Systemen auf operative Daten häufig nicht zielführend ist.

Charakteristika operativer Daten

Charakteristika dispositiver Daten

Ziel

Abwicklung der Geschäftsprozesse

Informationen für das Management; Entscheidungsunterstützung

Ausrichtung

Detaillierte, granulare Geschäftsvorfalldaten

Meist verdichtete, transformierte Daten; umfassendes Metadatenangebot

Zeitbezug

Aktuell; zeitpunktbezogen; auf die Transaktion ausgerichtet

Unterschiedliche, aufgabenabhängige Aktualität; Historienbetrachtung

Modellierung

Altbestände oft nicht modelliert (funktionsorientiert)

Sachgebiets- o. themenbezogen, standardisiert u. endbenutzertauglich

Zustand

Häufig redundant; inkonsistent

Konsistent modelliert; kontrollierte Redundanz

Update

Laufend und konkurrierend

Ergänzend; Fortschreibung abgeleiteter, aggregierter Daten

Queries

Strukturiert; meist statisch im Programmcode

Ad-hoc für komplexe, ständig wechselnde Fragestellungen und vorgefertigte Standardauswertungen

Abb. 2.1:

Charakteristika operativer und dispositiver Daten (modifiziert übernommen aus Christmann 1996, S. C822.07)

Bis weit in die 90er Jahre hinein konnten daher managementunterstützende Systeme meist ausschließlich auf eigene, herstellerspezifische (proprietäre) und daher isolierte Datenbestände zugreifen. Wie Abb. 2.2 zeigt, wurden zur Befüllung dieser Daten-

16

2.1 Historisch gewachsene Formen der dispositiven Datenhaltung bereiche Kopien und Extrakte aus den verschiedenen operativen internen und externen Datenquellen gezogen.4

Berichtsorientierte Systeme (hoch verdichtet) z.B. Modellorientierte Systeme z.B. EIS 1

EIS 2

Daten Data

Daten Data

EIS n

…

DSS 1

DSS 2

DSS n

…

Daten Data Daten Data

Daten Data

Daten Data

Extrakte/Verdichtungen Betriebswirt. Harmonisierung

Berichtsorientierte Systeme (schwach verdichtet) z.B. Extrakte/Verdichtungen Betriebswirt. Harmonisierung

MIS 1

MIS 2

MIS n

… Daten Data

Daten Data

Daten Data

Extrakte/Verdichtungen Betriebswirt. Harmonisierung

z.B. Online-Dienste, Marktforschungsinstitute Externe Daten

Technik Vertrieb

Beschaffung

Personal

Produktion

F&E

……..

Operative Datenbestände

Abb. 2.2:

Historisch gewachsene Datenversorgung managementunterstützender Systeme

Diese Vorgehensweise weist jedoch erhebliche Nachteile auf: • Beeinträchtigung der Performance der operativen Systeme durch mehrfaches Kopieren und Extrahieren. • Inkonsistenz des dispositiven Datenmaterials, da die zu unterschiedlichen Zeitpunkten durchgeführten Kopier- und Extraktionsprozesse aufgrund des fortlaufenden Betriebs der operati-

4

Eine detaillierte Beschreibung der in der Abbildung dargestellten Executive Information Systems (EIS), Decision Support Systems (DSS) und Management Information Systems (MIS) erfolgt im 3. Kapitel.

17

2 Datenbereitstellung und -modellierung ven Transaktionssysteme nicht die gleichen Datenwerte liefern. • Erhöhung des Aufwands und der Fehleranfälligkeit, da die betriebswirtschaftliche Harmonisierung des Datenmaterials für jedes einzelne Subsystem individuell durchgeführt werden muss. • Unerwünschte Nebenwirkungen durch das Löschen und Ändern von Daten in vorgelagerten dispositiven Systemen, die nicht selten als zusätzliche Datenquelle herangezogen werden. Daten-PoolAnsatz

Einen Fortschritt stellt der Daten-Pool-Ansatz dar, der als direkter Vorgänger des Data-Warehouse-Konzepts angesehen werden kann (vgl. Abb. 2.3).

Berichtsorientierte Systeme (hoch verdichtet)

Modellorientierte Systeme

Berichtsorientierte Systeme (schwach verdichtet)

EIS 1

EIS 2

… EIS n

DSS 1

DSS 2 … DSS n

MIS 1

MIS 2 … MIS n

Daten Data

Daten Data

Daten Data

Daten Data

Daten Data

Daten Data

Daten Data

Daten Data

Extrakte/Verdichtungen Betriebswirt. Harmonisierung

Daten Data

Extrakte/Verdichtungen Betriebswirt. Harmonisierung

Daten-Pool Extrakte/Kopien

z.B. Online-Dienste, Marktforschungsinstitute Externe Daten Abb. 2.3:

Technik Vertrieb

Beschaffung

Personal

Produktion

F&E

……..

Operative Datenbestände Daten-Pool-Ansatz

Hierbei werden die operativen Daten durch reine Kopier- und Extraktionsvorgänge in physisch von den Quellsystemen getrennten Datenbanken gespiegelt, so dass die unterschiedlichen managementunterstützenden Systeme eines Unternehmens auf 18

2.2 Data-Warehouse-Konzept einen dedizierten Datenpool zugreifen können. Auf diese Weise wird zumindest die zeitliche Konsistenz der dispositiven Daten, die sich identischer operativer Quellen bedienen, gesichert und die Beeinträchtigung der Performance der operativen Systeme aufgrund des einmaligen Kopier- und Extraktionsvorgangs reduziert. Die erforderlichen Harmonisierungen und Verdichtungen haben jedoch noch immer für jedes managementunterstützende ITSystem separat im Rahmen weiterer Kopier- und Extraktionsvorgänge zu erfolgen. Daher kann auch der Daten-Pool-Ansatz keine einheitliche Sicht auf die Daten eines Unternehmens garantieren und birgt weiterhin die Gefahr semantischer Inkonsistenzen.

2.2

Data-Warehouse-Konzept Das Data-Warehouse-Konzept stellt eine wesentliche Neuerung gegenüber traditionellen Ansätzen dar. Während bei früheren Lösungen die Modellierung des erforderlichen Datenmaterials als Teil des Entwicklungsprozesses einzelner IT-Systeme gesehen wurde, steht nun die Bereitstellung einer dispositiven Datenbasis für den gesamten Komplex der Managementunterstützung eines Unternehmens im Vordergrund.

2.2.1

Begriff Data Warehouse

Definition Data Warehouse

Data Warehouses (DWHs) sind von den operativen Datenbeständen getrennte, logisch zentralisierte, dispositive Datenhaltungssysteme. Idealtypisch dienen sie als unternehmensweit einheitliche und konsistente Datenbasis für alle Arten von Managementunterstützungssystemen (Mucksch/Behme 2000, S. 6; Gabriel et. al. 2000, S. 76). Der Begriff Data Warehouse wurde wesentlich von William H. Inmon geprägt. Danach ist ein Data-Warehouse-System durch die Merkmale der Themenorientierung, der Integration, des Zeitraumbezugs und der Nicht-Volatilität charakterisiert (Inmon 2005, S. 29 ff.). • Themenorientierung Die Datenhaltung von operativen Systemen eines Unternehmens orientiert sich gewöhnlich an der unmittelbaren Durchführung der Wertschöpfungsprozesse. Im Gegensatz hierzu sind die dispositiven Daten des Data Warehouse an den Informationsbedarfen des Managements ausgerichtet. Die Entscheidungsträger sollen in die Lage versetzt werden, direkt Informationen zu den sie 19

2 Datenbereitstellung und -modellierung interessierenden Kerngebieten (subjects) zu recherchieren. Typische Interessengebiete sind somit • die Unternehmensstruktur, z. B. Geschäftsbereiche, Organisationsbereiche, rechtliche Einheiten, • die Produktstruktur, z. B. Produktgruppen, Produkte, • die Regionalstruktur, z. B. Länder, Gebiete, Bezirke, Filialen, • die Kundenstruktur, z. B. Kundensegmente, Kunden, • die Zeitstruktur, z. B. Jahre, Quartale, Monate, zu denen meist Informationen (Fakten) wie • betriebswirtschaftliche Kennzahlen, z. B. Umsätze, Deckungsbeiträge, Gewinn und • deren Ausprägungen, z. B. Plan-, Ist-Werte, Abweichungen zugeordnet werden (Mucksch/Behme 2000, S. 10). • Integration Eine wesentliche Aufgabe bei der Erstellung eines Data Warehouse stellt die Integration der entscheidungsrelevanten Daten aus den unterschiedlichen operativen und externen Quellen zu einer inhaltlich widerspruchsfreien Datensammlung dar. Diese Aufgabe erweist sich in der Realität meist als äußerst komplex, weil die historisch gewachsenen operativen Systeme mit den ihnen zugrunde liegenden Datenhaltungssystemen häufig Datenredundanzen, Inkonsistenzen und semantische Widersprüche aufweisen. • Zeitraumbezug Während Daten in operativen Systemen typischerweise transaktionsorientiert und somit zeitpunktbezogen erzeugt und abgelegt werden, repräsentieren Daten im Data Warehouse häufig einen Zeitraum, z. B. einen Tag, eine Woche oder einen Monat.

Granularität

20

Mit zunehmender Durchdringung des E-Business und den daraus resultierenden Analysemöglichkeiten relativiert sich jedoch das von Inmon bereits Anfang der 90er Jahre propagierte Merkmal des Zeitraumbezugs immer mehr. So ist ein deutlicher Trend erkennbar, die sog. Granularität – also die unterste Stufe betriebswirtschaftlich relevanter Detaildaten des DWH – zu verfeinern und die sie repräsentierenden Zeiträume enger zu fassen. In neueren Konzepten – etwa bei kundenzentrierten Data Ware-

2.2 Data-Warehouse-Konzept houses – ist es heute sogar üblich, die Daten auf der Ebene der Transaktionen abzulegen. • Nicht-Volatilität Daten in operativen Systemen zeichnen sich durch kontinuierliche Veränderungen aus und repräsentieren daher den jeweils aktuellen Zustand innerhalb eines Geschäftsprozesses. Die Historie dieser Daten wird in aller Regel nicht gespeichert. Lediglich aus Recovery-Gründen (z. B. für das Wiederaufsetzen der Datenbank nach technischen Defekten) erfolgt meist eine Datensicherung und -speicherung über einen begrenzten Zeitraum. Dauerhafte Datenablage

2.2.2

Historisch gewachsen vs. bewusste Gestaltung

Das Data Warehouse weist hingegen die Besonderheit auf, dass die integrierten Daten dauerhaft abgelegt werden und somit für künftige betriebswirtschaftliche Analysen weiterhin zur Verfügung stehen. Um das Datenwachstum zu begrenzen, müssen selbstverständlich auch in diesem Falle sinnvolle Historisierungskonzepte entwickelt und implementiert werden. So sind z. B. Überlegungen anzustellen, ob Daten eines bestimmten Alters nicht in verdichteter Form abzulegen bzw. zu archivieren sind.

Gängige Architekturvarianten von DWH-/Data-Mart-Lösungen Die Architektur (der Bauplan) eines Informationssystems dient der Beschreibung der einzelnen Systembausteine hinsichtlich ihrer Art, ihrer funktionalen Eigenschaften und ihres Zusammenwirkens. Es liegt auf der Hand, dass in der Praxis eine Vielzahl von DWH-/Data-Mart-Architekturvarianten existiert. Meist sind diese aus historisch gewachsenen BI-Landschaften entstanden. Jedoch ist ein Teil dieser Architekturvarianten auch auf bewusste Gestaltungsaktivitäten zurückzuführen, die eine auf das individuelle Unternehmen ausgerichtete wirksame Managementunterstützung sicherstellen sollen. Häufig vorzufindende Ansätze sind hierbei5 (vgl. Abb. 2.4):

5

Auf das Konzept des Embedded BI, bei dem BI-Funktionalitäten direkt in den operativen Systemen integriert werden, wird in diesem Lehrbuch bewusst nicht eingegangen. Sicherlich sind auch bei dieser BI-Variante sinnvolle Anwendungsfelder denkbar. Da die Systeme jedoch primär in eng abgegrenzten Datenausschnitten der operativen Kontexte eingesetzt werden (Klawans 2008) und meist ein integraler Bestandteil der operativen Systeme sind, entsprechen sie nicht dem in diesem Werk zugrundeliegenden BI-Verständnis und passen daher auch nicht zu dem dargestellten BI-Bezugsrahmen.

21

2 Datenbereitstellung und -modellierung •

Unabhängige Data Marts

•

Data Marts mit abgestimmten Datenmodellen

•

Zentrales C-DWH (Verzicht auf Data Marts)

•

Mehrere C-DWHs

•

C-DHW und abhängige Data Marts

•

DWH-Architektur-Mix

Unabhängige Data Marts

Data Mart

Data Mart

Data Mart

Operative Quellsysteme

Mehrere C-DWHs

Core Data Warehouse

Core Data Warehouse

Operative Quellsysteme

C-DWH und abhängige Data Marts Abgestimmte Datenmodelle

Data Mart

Data Mart

Data Mart

Data Mart

Data Mart

Data Mart

Core Data Warehouse

Operative Quellsysteme Operative Quellsysteme

DWH-Architekturmix Zentrales C-DWH

Core Data Warehouse

Data Mart

Data Mart

Virtuelles DWH

Data Mart

Core Data Warehouse

Data Mart

Data Mart

Operative Quellsysteme

Operative Quellsysteme

Abb. 2.4:

Unabhängige Data Marts

22

Architekturvarianten von DWH-/Data-Mart-Lösungen

Eine dezentrale Architektur mit unabhängigen Data Marts (kleineren, applikationsklassen-orientierten Datenpools) macht lediglich dann einen Sinn, wenn keine übergreifenden Datenauswertungen im Unternehmen erforderlich sind. Das ist jedoch eher selten der Fall und daher ist diese Lösung meist das Resultat einer historisch „gewachsene Struktur“. Sie kann sich insbesondere bei dem Fehlen koordinierender BI-Instanzen oder BIStrategien in den Organisationen ausbreiten. Die Nachteile sich inhaltlich überlappender Data Marts liegen vor allem in den Be-

2.2 Data-Warehouse-Konzept reichen der mehrfachen Aufbereitung (Transformation) operativer Daten und der mangelnden Möglichkeit zur Durchführung bereichsübergreifender Auswertungen. Zur Charakterisierung dieser Probleme wird häufig die Metapher einer Stove Pipe („Ofenrohr“) genutzt, da die Daten für jeden Anwendungsbereich isoliert aus den Quellsystemen bezogen und aufbereitet werden und danach als sog. Datensilos für andere Kontexte nur noch eingeschränkt einsetzbar sind. Die Unterlegenheit historisch gewachsener Data-Mart-Architekturen gegenüber Ansätzen mit einer logischen Integration ist mittlerweile auch empirisch dokumentiert (Ariyachandra/Watson 2006). Die Konsolidierung solcher Ansätze stellt für viele Unternehmen eine erhebliche Herausforderung dar, für die zurzeit noch keine überzeugenden Migrationskonzepte existieren.

Data Marts mit abgestimmten Datenmodellen

Betrieb eines C-DWH bei Verzicht auf Data Marts

Betrieb mehrerer C-DWH

Eine Alternative stellt der Einsatz von Data Marts mit konzeptionell abgestimmten Datenmodellen dar, mit deren Hilfe die Konsistenz und Integrität des dispositiven Datenmaterials sichergestellt werden soll. Bei diesem Ansatz ist – wie beim Konzept unabhängigre Data Marts – ebenfalls das mehrfache Aufbereiten identischer Quelldaten für unterschiedliche Datenhaltungssysteme erforderlich. Weiterhin stößt das Konzept häufig auch aufgrund der Data-Mart-typischen applikationsnahen Datenspeicherung an Grenzen. So werden Daten in Data Marts bewusst in anwendungsklassenspezifischen Formen (insbesondere in unterschiedlicher Granularität, Aggregation und Anreicherung) vorgehalten und ermöglichen daher meist lediglich eine Zusammenführung unter Informationsverlusten. Ein Verzicht auf Data Marts kann eine Alternative für kleinere Lösungen sein, bei denen Applikationen aus einer Anwendungsdomäne unterstützt werden, eine überschaubare Anzahl von Endbenutzern existiert und nur geringe Datenvolumina auftreten. Ein solch monolithischer Ansatz, der die Auswertungsfunktion des C-DWH in den Mittelpunkt stellt, kann jedoch bei komplexeren Lösungen aus Performance- und Administrationsgründen mit erheblichen Nachteilen verbunden sein. Existieren im geschäftlichen Unternehmensumfeld mehrere, unterschiedliche Produkt-/Marktstrukturen (strategische Geschäftseinheiten), so können zur Unterstützung der divergierenden Geschäftsprozesse durchaus mehrere C-DWHs aufgebaut werden. Diese Rahmenbedingungen sind insbesondere bei spartenorientierten Unternehmen, Konzernen und Großunternehmen mit diversifiziertem Angebotsspektrum vorzufinden. 23

2 Datenbereitstellung und -modellierung C-DWH und abhängige Data Marts

DWHArchitekturmix

2.2.3 Referenzarchitektur des Buches

Hub-and-Spoke

24

Die Erweiterung eines C-DWH um Data Marts, die sich über Transformationsprozesse der Daten des C-DWH bedienen, ist eine der in (Lehr-)Büchern häufig dargestellten Architekturvarianten. Sie liegt (in einer erweiterten Form) auch diesem Werk zu Grunde und wird im folgenden Kapitel 2.2.3 ausführlich behandelt. Eine für die Praxis nicht selten vorzufindende Struktur ist der DWH-Architekturmix bestehend aus C-DWHs, abhängigen und unabhängigen Data Marts sowie direkten Datendurchgriffen (sog. Virtuelle DHWs mit eigener Datentransformation). Diese Ansätze können sowohl das Resultat einer historisch gewachsenen BILandschaft als auch das Ergebnis eines bewussten Gestaltungsprozesses zur optimalen Unterstützung wertschöpfender Primärgeschäftsprozesse und flankierender Querschnittsprozesse sein. Das 4. Kapitel widmet sich ausführlich diesem Themenbereich.

Architektur ODS-erweiterter Data Warehouses Die in diesem Werk Verwendung findende Architektur (Referenzarchitektur des Buches) ist in der Abb. 2.5 verdeutlicht und stellt einen sog. ODS-erweiterten DWH-Ansatz dar. In diesen Fällen ist das Data Warehouse um eine transaktionsorientierte, nicht historienbildende, integrierte Datenhaltung – den Operational Data Store (ODS) – erweitert. Da für ODS-Systeme andere, von der originären DWH-Definition abweichende Kriterien gelten, wird ihre Einordnung in der Praxis und Wissenschaft kontrovers diskutiert. Im vorliegenden Buch wird der ODS – wie die senkrechte Linie in der Abbildung verdeutlicht – nicht direkt dem DWH zugerechnet. Da jedoch der Einsatzbereich und die enge Verwandtschaft des ODS mit dem DWH unstrittig ist, werden diese Datenhaltungssysteme ebenfalls hier in diesem Kapitel behandelt, wobei die ODS-Besonderheiten explizit thematisiert werden. Deutlich wird, dass das hier dargestellte Data Warehouse aus einem Konglomerat verschiedener dispositiver Datenhaltungssysteme besteht. Diese unterscheiden sich primär durch die Verdichtungsgrade der Daten und den Grad ihrer Applikationsorientierung, sind jedoch miteinander verbunden und über Mechanismen der Redundanzbeherrschung in ihrer Konsistenz gesichert. Aus diesem Grunde wird diese Architekturvariante auch häufig als Hub-and-Spoke-Architektur (Nabe-Speiche-Architektur) bezeichnet, wobei das Core Data Warehouse die Nabe

2.2 Data-Warehouse-Konzept repräsentiert und die abhängigen Data Marts die Speichen darstellen.

Data Mart

Metadaten

Data Mart

Transformation

Data Mart

Transformation

ODS Transformation Core Data Warehouse

Administrationsschnittstellen

ETL Operative Systeme

Abb. 2.5:

ETL-Prozess

Core Data Warehouse

SCM

ERP CRM Wertschöpfungskette

E-Proc.

ODS-erweiterte Data-Warehouse-Architektur

Dem Transformationsprozess zwischen operativen und dispositiven Datenhaltungen kommt eine wesentliche Bedeutung zu. Er hat die Aufgabe, die an speziellen operativen Anwendungsfeldern orientierten Daten in themenorientierte Daten zu überführen, die dem Informationsbedarf des Managements entsprechen. Aus den englischen Bezeichnungen der Teilschritte “Extraction“, „Transformation“ und “Loading“ leitet sich der häufig gebrauchte Begriff ETL-Prozess ab.6 Die Kernkomponente der Architektur stellt die zentrale DataWarehouse-Datenbank dar, die auch als Core Data Warehouse bezeichnet wird. Ihre Befüllung erfolgt direkt aus den operativen internen und externen Quellsystemen oder vorgelagerten Operational Data Stores. Das Core Data Warehouse basiert meist auf einer relationalen Datenbank und kann durchaus Größen im

6

Neben den ETL-Prozessen, die direkt auf die operativen Datenquellen aufsetzen, sind im DWH auch Extraktions-, Transformationsund Ladevorgänge zwischen den diversen dispositiven Datenhaltungen erforderlich. In der Abb. 2.5. werden diese verkürzt als „Transformation“ bezeichnet.

25

2 Datenbereitstellung und -modellierung Terabyte-Bereich erreichen (Unger/Kemper 2008, S. 146 f.). Noch höhere Datenvolumina weisen häufig kundenzentrierte DWHs von Unternehmen aus den Bereichen Finanzdienstleistung, Telekommunikation oder Handel auf, in denen teilweise bereits mehrere Petabyte (1 Petabyte = 1.024 Terabyte) hinterlegt sind. So umfasste das Data Warehouse einer bekannten Internethandelsplattform im Jahr 2008 bereits ca. 5 Petabyte (Lai 2008). Data Marts

Data Marts sind kleinere Datenpools für eine Klasse von Applikationen, die üblicherweise für einen eingeschränkten Benutzerkreis aufgebaut werden. Ihre Daten werden in aller Regel mit Hilfe weiterer Transformationsprozesse aus dem Core Data Warehouse extrahiert.

Operational Data Store

Ein Operational Data Store beinhaltet aktuelle transaktionsorientierte Daten aus verschiedenen operativen Quellsystemen und stellt sie für Anwendungs- und Auswertungszwecke bereit. Die Daten werden hierbei jedoch nicht längerfristig historisiert, sondern – in Analogie zur operativen Datenhaltung – im Bedarfsfalle durch neue Transaktionen überschrieben (Inmon et. al. 2000, S. 218 f.; Mucksch 2006, S. 136).

Metadaten

Die Metadaten beschreiben die Datenstruktur der gespeicherten DWH- und ODS-Daten. Sie können daher als „Daten über Daten“ bezeichnet werden und erlauben eine gezielte und strukturierte Auswertung von Informationen über Zusammenhänge der gesamten dispositiven Datenhaltung (Wieken 1999, S. 205).

Administrationsschnittstellen

Unter den Administrationsschnittstellen werden systemgestützte Zugänge für technische und betriebswirtschaftliche Fachspezialisten verstanden. Mit ihrer Hilfe können Modifikationen, Einschränkungen und Erweiterungen im Data Warehouse und im ODS umgesetzt werden.

2.3

Detaillierung ODS-erweiterter Data Warehouses Im Weiteren werden alle oben angeführten Komponenten ODSerweiterter Data Warehouses ausführlich beschrieben und diskutiert.

2.3.1 Enterprise Information Integration

26

Transformationsprozess — ETL Zurzeit wird der direkte Zugriff auf heterogene Quelldaten und deren unmittelbare Harmonisierung unter dem Schlagwort Enterprise Information Integration (EII) intensiv diskutiert. (White 2005, S. 15 ff.). Im Bereich der managementunterstützenden Systeme hat sich jedoch allgemein die Auffassung durchgesetzt,

2.3 Detaillierung ODS-erweiterter Data Warehouses dass dispositive Anwendungen nur in Ausnahmefällen direkt auf die operativen Daten aufsetzen sollten. Umfassende Virtuelle Data Warehouses ohne dedizierte dispositive Datenhaltung haben sich nicht etablieren können, da • die Heterogenität gewachsener Infrastrukturen (LegacySysteme) den Zugriff auf das relevante Datenmaterial erschwert, • die Ressourcenbelastung durch schlecht antizipierbare Managementabfragen für operative Systeme kaum kalkulierbar ist, • eine für Managementabfragen wichtige Historienbetrachtung aufgrund mangelnder Historienführung im operativen Kontext nicht möglich ist und • operative Daten lediglich mit Hilfe umfangreicher Transformationsregeln in relevante Managementinformationen überführt werden können. Gerade der letzte Punkt gilt als schwierig, da er die syntaktische und semantische Integration der Quelldaten und deren weitere Aufbereitung zu inhaltlich widerspruchsfreien dispositiven Datensammlungen leisten muss. Aufgrund seiner Komplexität wird er nicht selten auch als Engpass im Rahmen der Erstellung und Nutzung einer Data-Warehouse-Lösung angesehen. In vielen Fällen wird der Transformationsprozess ausschließlich auf die direkte Schnittstelle zwischen den operativen Daten und der dispositiven Datenhaltung begrenzt. Transformationsprozesse innerhalb des Operational Data Store bzw. des Data Warehouse werden dagegen häufig nicht explizit thematisiert. Um zu einem konsistenten Ansatz zu gelangen, wird daher im Folgenden eine differenzierte Darstellung des Transformationsprozesses aus einer betriebswirtschaftlich-konzeptionellen Perspektive entwickelt (weitere Ausführungen angelehnt an Kemper/Finger 2010, S. 157 ff.). Transformation

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 (vgl. Abb. 2.6).

27

2 Datenbereitstellung und -modellierung

Filterung

Unter der Filterung werden die Extraktion aus den operativen Daten und die Bereinigung syntaktischer oder inhaltlicher Defekte in den zu übernehmenden Daten verstanden.

Harmonisierung

Die Harmonisierung bezeichnet den Prozess der betriebswirtschaftlichen Abstimmung gefilterter Daten.

Aggregation

Die Aggregation ist die Verdichtung gefilterter und harmonisierter Daten.

Anreicherung

Die Bildung und Speicherung betriebswirtschaftlicher Kennzahlen aus gefilterten und harmonisierten Daten wird als Anreicherung bezeichnet.

Abb. 2.6:

Teilprozesse der Transformation

Filterung Die erste Schicht der Transformation stellt die Filterung dar. Mit ihrer Hilfe werden die für das Data Warehouse benötigten Daten, die meist aus heterogenen unternehmensinternen und -externen Quellen stammen, selektiert, zwischengespeichert und von Mängeln befreit. Filterung Bereinigte Extrakte

Bereinigte Extrakte

Extrakte

Extrakte

...

Bereinigte Extrakte

Extrakte

Produktion

...

Technik

z.B. Online-Dienste Vertrieb

Externe Daten

Personal

F&E

Beschaffung

Operative Datenbestände

Abb. 2.7:

Erste Transformationsschicht – Filterung

Die Filterung unterteilt sich aus diesem Grunde in die beiden Phasen Extraktion und Bereinigung (vgl. Abb. 2.7). Extraktion und Bereinigung

Im Rahmen der Extraktion werden die unternehmensexternen und insbesondere die operativen unternehmensinternen Daten in speziell hierfür vorgesehene Extraktionsbereiche (staging areas) des Data Warehouse eingestellt. Die Bereinigung dient der Befreiung der extrahierten Daten sowohl von syntaktischen als auch von semantischen Mängeln.

28

2.3 Detaillierung ODS-erweiterter Data Warehouses Unter syntaktischen Mängeln sind hierbei formelle Mängel der code-technischen Darstellung zu verstehen. Semantische Mängel betreffen dagegen Mängel in den betriebswirtschaftlichen Inhalten der Daten. In diesem Zusammenhang können mehrere Klassen von Mängeln identifiziert werden: • 1. Klasse: Automatisierbare Defekterkennung mit automatisierbarer Korrektur während des Extraktionsvorganges. • 2. Klasse: Automatisierbare Defekterkennung mit manueller Korrektur nach dem Extraktionsvorgang. • 3. Klasse: Manuelle Defekterkennung mit manueller Korrektur nach dem Extraktionsvorgang.

Bereinigung

1. Klasse Automatisierbare Erkennung und automatisierbare Korrektur

2. Klasse Automatisierbare Erkennung und manuelle Korrektur

3. Klasse Manuelle Erkennung und manuelle Korrektur

Syntaktische Mängel Bekannte Formatanpassungen

Erkennbare Formatinkompatibilitäten

—

Semantische Mängel Fehlende Datenwerte

Ausreißerwerte / unstimmige Wertekonstellationen

Unerkannte semantische Fehler in operativen Quellen

bedingen kurz- oder mittelfristig eine Fehlerbereinigung in den operativen Quellsystemen

Abb. 2.8:

Mängelklassifikation im Rahmen der Bereinigung (Kemper/Finger 2010, S. 166)

Jede dieser Klassen erfordert eine besondere Vorgehensweise der Bereinigung. • Mängel der 1. Klasse Syntax und Semantik

Die syntaktischen und semantischen Mängel der 1. Klasse können durch implementierte Transformationsregeln automatisiert behoben werden, da sie bereits vor der Erstellung der Extraktionsroutinen bekannt sind bzw. ihr Auftreten antizipiert werden kann. So gehören zu dieser Klasse syntaktische Mängel, die durch interne Format-, Steuer- oder Sonderzeichen bewirkt und in opera29

2 Datenbereitstellung und -modellierung tiven Systemen – z. B. zur Dokumentation von Stornobuchungen – herangezogen werden. Diese Mängel lassen sich während des Extraktionsvorgangs identifizieren und über Zuordnungstabellen (mapping tables) in den Extraktdaten bearbeiten. Ein Beispiel für die automatisierte Bereinigung eines semantischen Mangels sind fehlende Ist-Werte in den operativen Daten, z. B. aufgrund nicht durchgeführter Übertragungen von Umsatzdaten einzelner Niederlassungen. Solche fehlenden Inhalte können während des Extraktionsvorganges erkannt und gemäß vorab definierter und im Unternehmen abgestimmter Regeln durch äquivalente Werte ersetzt werden (wie etwa Plan-Werte des Monats, Ist-Werte des Vormonats oder Ist-Werte des Vorjahresmonats). Um die Datenqualität zu sichern und sinnvolle Verdichtungen auf Basis dieses Datenmaterials erstellen zu können, ist die Verfahrensweise zu dokumentieren und zu kommentieren. • Mängel der 2. Klasse Diejenigen Mängel, die automatisiert bereinigt werden können, stellen jedoch nur den kleineren Teil dar. So lassen sich Mängel der 2. Klasse mit Hilfe implementierter Routinen lediglich identifizieren. Sie sind somit anschließend von technischen und betriebswirtschaftlichen Spezialisten manuell zu bereinigen. Bei den syntaktischen Mängeln können beispielsweise bisher nicht berücksichtigte Syntaxvarianten erstmalig entdeckt und durch technische Spezialisten manuell in den Extrakten berichtigt werden. Für zukünftige Extraktionsvorgänge sind solche Syntaxvarianten zu berücksichtigen und automatisiert zu behandeln, so dass sie ab diesem Zeitpunkt zu den Mängeln der 1. Klasse gehören. Für einen Teil der semantischen Mängel der 2. Klasse ist ebenfalls eine automatische Erkennung möglich. Mit Hilfe von Plausibilitätskontrollen (z. B. durch Vergleiche von Bilanz- oder Kontrollsummen), einfachen Wertebereichsüberprüfungen oder DataMining-basierten Musterkennungsverfahren (z. B. zur Erkennung von Ausreißerwerten oder nicht erlaubten Attributausprägungen) können fehlerhafte Datenwerte erkannt werden. Da diese Mängel meist auf Fehlern in den operativen Datenquellen beruhen, sind je nach Schwere des Fehlers, seinen Auswirkungen im operativen Systemumfeld und dem Aufwand der Fehlerbehebung Korrekturmaßnahmen in den betroffenen operativen Quellsystemen einzuleiten. Ist eine Bereinigung an der Quelle nicht möglich, sind von Spezialisten Bereinigungsmaß30

2.3 Detaillierung ODS-erweiterter Data Warehouses nahmen in der Filterungsschicht des Data Warehouse umzusetzen, damit die Fehler der operativen Quellsystemumgebung nicht die Datenqualität im dispositiven Bereich verschlechtern und dadurch die Akzeptanz der Endbenutzer negativ beeinflussen können.

Competitive Intelligence

Ein direktes Ansetzen an der Quelle wird speziell bei einer Nutzung externer Datenlieferanten erschwert. Solche Quellen gewinnen mit neuen, stärker auf die Analyse externer Informationen ausgerichteten Anwendungssystemen – etwa im Kontext der Wettbewerbsanalyse (Competitive Intelligence) sowie dem Aufkommen von unternehmensübergreifenden Data Warehouses (z. B. für Franchise-Betriebe, Marktplätze, Supply-Chain-Kooperationen u. ä.) – zunehmend an Bedeutung. • Mängel der 3. Klasse Da die Datensyntax stets vollständig beschrieben werden kann, sind syntaktische Mängel immer automatisiert erkennbar. Die manuelle Identifikation von Mängeln ist deshalb nur für semantische Mängel erforderlich (vgl. Abb. 2.8). Beispiele sind unkorrekte Datenwerte in den extrahierten Daten, die nicht durch Plausibilitätsprüfungen, einfache Wertebereichsprüfungen oder Verfahren der Mustererkennung identifiziert, sondern lediglich von betriebswirtschaftlichen Fachexperten erkannt werden können. Bei diesen semantischen Mängeln handelt es sich ebenfalls stets um Fehler in den operativen Datenquellen. Diese sind wie oben beschrieben zu behandeln. Kann also aufgrund individueller Rahmenbedingen eine Berichtigung der operativen Quellsysteme nicht (sofort) erfolgen, ist eine Bereinigung der semantischen Fehler in der Filterungsschicht des Data Warehouse vorzunehmen. Mängel der 2. wie auch der 3. Klasse erschweren insbesondere die Realisierung von Lösungen, die auf eine zeitnahe Datenbereitstellung ausgelegt sind (Real-time Data Warehousing, vgl. Abschnitt 3.1.3). Ein Ansatz, trotz manueller Aktivitäten noch eine angemessene Datenbefüllung sicherzustellen, ist der Einsatz von Workflow-Management-Systemen, mit denen die notwendigen Korrekturprozesse strukturiert, verfolgt und analysiert werden können (Bartel et al. 2000).

Cleansing & Scrubbing

Weiterhin können die beschriebenen Datentransformationen werkzeugseitig durch sog. Cleansing-and-Scrubbing-Komponenten unterstützt werden, die üblicherweise ein Bündel von Algorithmen zur Datenbereinigung bereitstellen. Im Mittelpunkt

31

2 Datenbereitstellung und -modellierung stehen Verfahren zur Fehlererkennung, Fehlerkorrektur, Syntaxabgleichung sowie zur Dublettenerkennung und -eliminierung.

Harmonisierung Die Harmonisierung stellt die zweite Schicht der Transformation dar. Im Gegensatz zur Filterung liefert sie bereits dispositiv verwendbare Daten, die sich auf der detailliertesten Stufe betriebswirtschaftlich sinnvoller Interpretation – der Granularität – befinden. Abb. 2.9 veranschaulicht die Harmonisierungsschicht und die Verknüpfung zur Filterungsschicht. Die Hauptaufgabe der Harmonisierungsschicht liegt in der Zusammenführung der gefilterten Daten, wobei die physische Integration der Daten aufgrund leistungsfähiger Werkzeugunterstützung in der Regel keine größeren Probleme bereitet. Eine größere Herausforderung bedeutet dagegen die syntaktische und betriebswirtschaftliche Abgleichung der gefilterten Datenbestände als Vorbereitung der physischen Integration. Harmonisierung Gefilterte / harmonisierte Daten der gewünschten Granularität

Betriebswirtschaftliche Harmonisierung Syntaktische Harmonisierung Filterung Bereinigte Extrakte

Bereinigte Extrakte

Extrakte

Extrakte

...

Bereinigte Extrakte

Extrakte

Produktion

...

Technik

z.B. Online-Dienste Vertrieb

Externe Daten

Personal

F&E

Beschaffung

Operative Datenbestände

Abb. 2.9:

Zweite Transformationsschicht – Harmonisierung

• Syntaktische Harmonisierung Die operativen und externen Datenbestände weisen meist eine hohe Heterogenität auf. Insbesondere die operativen Daten müssen mit Hilfe von umfangreichen Transformationsregeln vereinheitlicht, d. h. syntaktisch harmonisiert werden. Mit Hilfe dieser Transformationsregeln werden Schlüsseldisharmonien in den Extrakten bereinigt und die Probleme unterschiedlich kodierter Daten sowie die Schwierigkeiten bei der Verwendung von Synonymen und Homonymen gelöst. 32

2.3 Detaillierung ODS-erweiterter Data Warehouses • Schlüsseldisharmonien basieren auf Unverträglichkeiten der Primärschlüssel in den extrahierten und bereinigten Daten und entstehen durch die Verwendung unterschiedlicher Zugriffsschlüssel in der operativen Datenhaltung. In Abb. 2.10 wird der Sachverhalt anhand eines Beispiels veranschaulicht. In diesem Anwendungsfall sollen übergreifende, kundenzentrierte Analysen durchgeführt werden. Eine Untersuchung der Quellsysteme macht jedoch deutlich, dass die relevanten operativen Anwendungssysteme – hier im Beispiel ein Außendienstsystem, eine Call-Center-Anwendung und eine Abrechnungsapplikation – über unterschiedliche Primärschlüssel für die Kunden verfügen. Um die gewünschte Auswertung durchführen zu können, sind somit die Schlüsseldisharmonien zu eliminieren. Daher wird in diesem Beispiel im Rahmen der Harmonisierung eine Zuordnungstabelle (mapping table) erarbeitet, die für jeden Kunden einen neuen künstlichen Primärschlüssel generiert und die Primärschlüssel der operativen Systeme als Fremdschlüssel mitführt, so dass übergreifende Auswertungen ermöglicht werden. AD_SYS AD-FX8257 AD-FH2454 AD-FX7059 AD-FT2567 ...

... Kunde_Text Müller Meier Schulz Schmitz ... ...

CC_SYS 59235395 08485356 08555698 85385386 ...

Kunde_ID 0001 0002 0003 0004 ...

Kunde_Text Müller Meier Schulz Schmitz ...

...

...

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 ...

Kunde_Grp Handel Industrie Industrie Handel ...

AD_SYS AD-FX8257 AD-FH2454 AD-FX7059 AD-FT2567 ...

Kunde_Text Müller Meier Schulz Schmitz ...

CC_SYS 59235395 08485356 08555698 85385386 ...

AC_SYS 3857_ACC 3525_ACC 3635_ACC 3566_ACC ...

Kunde_Text Müller Meier Schulz Schmitz ...

Kunde_Status A A A B ...

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 ...

AC_SYS 3857_ACC 3525_ACC 3635_ACC 3566_ACC ...

...

...

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 ...

Legende: AD — Außendienstsystem, CC — Call-Center-Anwendung, AC — Abrechnungs-/Accounting-System

Abb. 2.10: Zuordnungstabellen zur Eliminierung von Schlüsseldisharmonien (modifiziert übernommen von Finger 2002)

33

2 Datenbereitstellung und -modellierung • Unter unterschiedlich kodierten Daten werden Daten verstanden, die über identische Attributnamen und eine identische Bedeutung verfügen, jedoch unterschiedliche Domänen bzw. Wertebereiche aufweisen. Das Attribut „Geschlecht“ kann in einem Quellsystem z. B. mit der Domäne „0“ und „1“ und in einem anderen Quellsystem mit der Domäne „M“ und „W“ kodiert sein. Die Lösung dieses Problems liegt in der eindeutigen Wahl einer Domäne und der Verwendung entsprechender Zuordnungs- bzw. Mapping-Tabellen (vgl. Abb. 2.11). • Bei Synonymen handelt es sich um Attribute, die zwar unterschiedliche Namen besitzen, jedoch dieselbe Bedeutung und dieselbe Domäne aufweisen (vgl. Abb. 2.11). Die Differenzen können durch eine Festlegung der Attributbezeichnung und eine Überführung der anderen Attributbezeichnungen bereinigt werden. Informationen über Mitarbeiter können in einem Quellsystem beispielsweise unter der Attributbezeichnung „Mitarbeiter“ und in einem anderen System unter der Bezeichnung „Personal“ geführt werden. Charakteristika Beispiele Datenquelle 1

Datenquelle 2

Aktivität

Unterschiedliche Gleiche AttributKodierung namen; gleiche Bedeutung; unterschiedliche Domänen

Attribut: GESCHLECHT Domäne: (0, 1)

Attribut: GESCHLECHT Domäne: (M, W)

Wahl einer Domäne

Synonyme

Unterschiedliche Attributnamen; gleiche Bedeutung; gleiche Domänen

Attribut: PERSONAL Inhalt: Name der Betriebsangehörigen

Attribut: MITARBEITER Inhalt: Name der Betriebsangehörigen

Wahl eines Attributnamens

Homonyme

Gleiche Attributnamen; unterschiedliche Bedeutung oder ungleiche Domänen

Attribut: PARTNER Inhalt: Name der Kunden

Attribut: PARTNER Inhalt: Name der Lieferanten

Wahl unterschiedlicher Attributnamen

Abb. 2.11: Unterschiedliche Kodierung, Synonyme und Homonyme (Kemper/Finger 2010, S. 168) • Homonyme weisen zwar denselben Attributnamen auf, besitzen jedoch unterschiedliche Bedeutungen. Daher können sie 34

2.3 Detaillierung ODS-erweiterter Data Warehouses über neu zu vergebende Attributnamen unterschieden werden (vgl. Abb. 2.11). Attribute aus zwei unterschiedlichen Quellsystemen können z. B. mit der Bezeichnung „Partner“ versehen sein. In der einen Quelle ist damit der Kunde gemeint, in der anderen Quelle jedoch der Lieferant. • Betriebswirtschaftliche Harmonisierung Neben der syntaktischen Abgleichung bilden die Aktivitäten der betriebswirtschaftlichen Harmonisierung einen weiteren wichtigen Teilschritt, um das Ziel der Überführung der operativen Daten in managementorientierte Daten zu erreichen. Hierzu gehören die Teilaufgaben der Abgleichung der betriebswirtschaftlichen Kennziffern sowie die Festlegung der gewünschten Granularität der dispositiven Daten. •

Die Abgleichung betriebswirtschaftlicher Kennziffern stellt sicher, dass für das gesamte Unternehmen ein fachlich konsistenter, dispositiver Datenzugriff gewährleistet wird. Für diese Zwecke sind Transformationsregeln zu implementieren, die das operative Datenmaterial in Bezug auf die betriebswirtschaftliche Bedeutung, die gebiets- und ressortspezifische Gültigkeit, die Währung oder die Periodenzuordnung in einheitliche Werte überführen. Ohne Frage gehören diese Aufgaben zu den anspruchsvollsten Tätigkeiten beim Aufbau integrierter BI-Ansätze und bedürfen hoher betriebswirtschaftlicher Kompetenz und Durchsetzungskraft im Unternehmen.

• Um die operativen Daten in die gewünschte Granularität zu überführen, sind weitere Transformationsregeln erforderlich. Sollen beispielsweise tagesaktuelle Werte auf Basis von Produkt- und Kundengruppen die detailliertesten Daten des Data Warehouse bilden, sind sämtliche Einzelbelege über Aggregationsmechanismen zu tagesaktuellen, produktgruppen- und kundengruppenspezifischen Werten zusammenzufassen. Nach Abschluss der Transformationen der Filterungs- und der Harmonisierungsschicht liegt im Data Warehouse ein bereinigter und konsistenter Datenbestand auf der Granularitätsebene vor. Dieser kann für analytische Informationssysteme direkt nutzbar gemacht werden (Kemper/Finger 2010, S. 169).

Aggregation Die dritte Transformationsschicht dient der Aggregation (vgl. Abb. 2.12). In dieser Phase werden die gefilterten und harmoni35

2 Datenbereitstellung und -modellierung sierten Daten um Verdichtungsstrukturen erweitert, wobei eine zentrale Definition mehrfach verwendbarer Dimensionshierarchien die anwendungsübergreifende Konsistenz der DWHAnalysen unterstützen kann.

Parallele Hierarchien

Zur Abbildung von Verdichtungsstrukturen wird in der Regel eine Reihe von Dimensionshierarchietabellen entwickelt, welche die antizipierbaren Auswertungsvarianten ermöglichen. „Kunde“, „Kundengruppe“ und „Gesamt“ kann als Beispiel einer einfachen Hierarchie dienen. Parallele Hierarchien entstehen, wenn die Granularwerte einer Dimension nach verschiedenen Kriterien hierarchisiert werden, z. B. „Produkte“ über „Produkthauptgruppen“ oder alternativ über „Profit-Center-Zugehörigkeit“ zu „Gesamt“ (vgl. auch Kapitel 2.4.2). Dimensionshierarchien können im Zeitverlauf modifiziert, gelöscht oder neu angelegt werden. Meist ist dieses auf sich ändernde Rahmenbedingungen im Unternehmen zurückzuführen, wie z. B. Veränderungen der personellen Zuständigkeiten, Zusammenfassungen bzw. Entflechtungen von Teilmärkten oder Sortimentsumstrukturierungen. Um in diesen Fällen konsistente Analysen auch über die Historie der Daten zu gewährleisten, sind die Veränderungen in den Tabellen mit Gültigkeitsstempeln (Zeitstempeln) zu versehen. Eine ausführliche Diskussion dieses Themenbereiches erfolgt in Kapitel 2.4.4. Die Erstellung und Pflege von Dimensionshierarchisierungstabellen und die aus Performancegründen häufig durchgeführte physische Speicherung von aggregierten Tabellen hat eine erste Orientierung auf eine anwendungsorientierte Datenhaltung zur Folge. Die Ausrichtung der Datenhaltung auf bestimmte Applikationsklassen durchbricht das Paradigma einer applikationsneutralen Datenmodellierung. Es wird ein Teil der Funktionalität, der vormals in den auf den Daten operierenden Anwendungssystemen implementiert war, in die Datenhaltung verlagert.

36

2.3 Detaillierung ODS-erweiterter Data Warehouses Gefilterte / harmonisierte Daten der gewünschten Granularität und Aggregate Aggregation DimensionsHierarchisierung Harmonisierung Gefilterte / harmonisierte Daten der gewünschten Granularität

Betriebswirtschaftliche Harmonisierung Syntaktische Harmonisierung Filterung Bereinigte Extrakte

Bereinigte Extrakte

Extrakte

Extrakte

...

Bereinigte Extrakte

Extrakte

Produktion

...

Technik

z.B. Online-Dienste Vertrieb

Externe Daten

Personal

F&E

Beschaffung

Operative Datenbestände

Abb. 2.12: Dritte Transformationsschicht – Aggregation

Anreicherung Applikationsbezogene Datenhaltung

Während in der Aggregationsschicht bereits eine erste Ablösung vom Paradigma der strikten Trennung von Daten und Programmlogik sichtbar wird, erfolgt in der Anreicherungsschicht eine fast völlige Abkehr von diesem Denkmuster. Mit Hilfe der Anreicherung werden betriebswirtschaftliche Kennzahlen berechnet und in die Datenbasis integriert. Hier können sowohl Werte auf Basis der zweiten Schicht (harmonisierte Daten der gewünschten Granularität) als auch auf Basis der dritten Schicht (bereits aggregierte Zusammenfassungstabellen) berechnet und selbst als Attribute gespeichert werden. Beispielsweise ist eine Berechnung wöchentlicher Deckungsbeiträge auf Produktebene (zweite Schicht) und jährlicher Deckungsbeiträge auf Filialebene (dritte Schicht) denkbar.

37

2 Datenbereitstellung und -modellierung Gefilterte / harmonisierte Daten der gewünschten Granularität, Aggregate und Anreicherungen

Gefilterte / harmonisierte Daten der gewünschten Granularität und Aggregate

Anreicherung

Aggregation Berechnung betriebswirtschaftlicher Kenngrößen

DimensionsHierarchisierung

Harmonisierung Gefilterte / harmonisierte Daten der gewünschten Granularität

Betriebswirtschaftliche Harmonisierung Syntaktische Harmonisierung Filterung Bereinigte Extrakte

Bereinigte Extrakte

Extrakte

Extrakte

...

Bereinigte Extrakte

Extrakte

Produktion

...

Technik

z.B. Online-Dienste Vertrieb

Externe Daten

Personal

F&E

Beschaffung

Operative Datenbestände

Abb. 2.13: Vierte Transformationsschicht – Anreicherung Eine solche Vorgehensweise bietet folgende Vorteile: • Kalkulierbares Antwortzeitverhalten bei späteren Abfragen aufgrund der Vorausberechnung. • Garantierte Konsistenz der kalkulierten Werte, da sie anwendungsübergreifend nur einmal gebildet werden. • Etablierung eines abgestimmten betriebswirtschaftlichen Instrumentariums. Abb. 2.13 zeigt den vollständigen Prozess der Transformation mit den vier Schichten der Filterung, Harmonisierung, Aggregation und Anreicherung. Die erste Schicht der Filterung regelt als technisch orientierte Schicht die Rohdatenbereitstellung. Die oberen drei anwendungsorientierten Schichten erzeugen betriebswirtschaftlich verwendbare dispositive Daten, die von Informationssystemen für das Management genutzt werden können.

38

2.3 Detaillierung ODS-erweiterter Data Warehouses

2.3.2

Core Data Warehouse

Core Data Warehouse und Data Marts Das Core Data Warehouse (C-DWH) ist die zentrale Datenhaltungskomponente im DWH-Konzept. Hier werden sämtliche Daten nach einem ersten Transformationsprozess für unterschiedlichste Auswertungszwecke und zur Weitergabe an eine Vielzahl von Benutzern bereitgestellt. Das C-DWH erfüllt somit die folgenden Funktionen (Herden 2009, S. 54 f.): • 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. • Qualitätssicherungsfunktion Transformierte Daten sichern die syntaktische und semantische Stimmigkeit der dispositiven Datenbasis.

Auswertungsfunktion

Applikationsklassenneutralität des C-DWH

Kontrovers wird in jüngerer Zeit die direkte Nutzung des C-DWH für endbenutzerbezogene Analysen – also eine Auswertungsfunktion des C-DWH – diskutiert. Erlaubten viele Unternehmen anfangs sog. Power-Usern – also Mitarbeitern mit exzellenten ITKenntnissen – die direkte Nutzung des C-DWH für Spezialanwendungen, so ist die Praxis in diesen Bereichen meist zurückhaltender geworden. Zurückzuführen ist dieser Meinungswandel häufig auf die negativen Erfahrungen, die im Laufe der Zeit mit dieser Lösung gemacht worden sind. So ist es nicht selten vorgekommen, dass C-DWH-Benutzer mit ungeschickten oder fehlerbehafteten Abfragen (meist SQL-Abfragen) die Performance des C-DWH stark belasteten und für Störungen im gesamten DWHBetrieb sorgten. Hinzu kommt, dass die Datenvolumina der DWHs in den letzten Jahren gravierend gestiegen sind und eine professionelle Bewirtschaftung erfordern. Vor diesem Hintergrund verfestigt sich mehrheitlich die Auffassung, dass die Befüllung, die Pflege und die Nutzung des C-DWH ausschließlich durch die IT-Abteilung zu erfolgen haben und analytische Auswertungen demnach nur in den Data Marts ermöglicht werden sollen. Damit das C-DWH als Lieferant dispositiver Daten sämtliche Data Marts bedienen kann, sind eine starke Detaillierung und ein hoher Grad an Mehrfachverwendbarkeit der Daten erforderlich. Eine Ausrichtung der Datenhaltung erfolgt daher primär an Kriterien einer technischen Optimierung der zugrunde liegenden Datenstrukturen, so dass Beladevorgänge, Modifikationen, Lösch39

2 Datenbereitstellung und -modellierung operationen und Datenweitergaben an die Data Marts sicher und performant durchgeführt werden können. Aggregate oder Anreicherungen – also funktionale Erweiterungen der dritten und vierten Transformationsschicht – stehen im C-DWH im Unterschied zu den Data Marts nicht im Mittelpunkt und werden demnach auch nur dann berücksichtigt, wenn ihre mehrfache Verwendung in verschiedenen Data Marts gegeben ist. Bei der Weitergabe der Daten des C-DWH in die Data Marts werden daher in aller Regel weitere Transformationsprozesse erforderlich, bei denen die Daten auf höhere Aggregationsniveaus verdichtet und um applikationsklassenorientierte Summenwerte sowie Anreicherungen ergänzt werden. Aktualisierungszyklen des C-DWH

Eine Aktualisierung des C-DWH erfolgt bedarfsabhängig, wobei üblicherweise drei Aktualisierungsvarianten unterschieden werden (Herden 2009, S. 57 f.): • Aktualisierung in Abhängigkeit der Änderungsquantität Die aufgelaufenen Änderungen in den Quellsystemen werden gesammelt. Sobald eine vorher festgelegte Anzahl von Änderungen erreicht ist, werden die Daten in das C-DWH übertragen. • Aktualisierung in periodischen Zeitabständen Die Übertragung der Daten in das C-DWH erfolgt nach vorher festgelegten Zeitabständen, z. B. stündlich, täglich, wöchentlich oder monatlich, in Abhängigkeit von den Aktualitätserfordernissen des jeweiligen Anwendungsbereichs. Bei mehreren Beladungen pro Tag sind jedoch hierbei häufig Belastungen der operativen Systeme im laufenden Tagesgeschäft nicht zu vermeiden, die zu Performance- und Durchsatzproblemen der operativen Infrastruktur führen können. • Echtzeit-Aktualisierung Die Daten der operativen Quellsysteme werden transaktionssynchron in das C-DWH geladen, d. h. im gleichen Moment, in dem Geschäftsvorfälle zu Änderungen der operativen Daten führen. Diese Variante weist eine hohe Komplexität auf und stellt eine große Herausforderung dar, da Mechanismen zum Anstoß der Datenübertragung und eine permanente Anbindung von Quellsystemen und C-DWH gewährleistet sein müssen. In aller Regel kommen hierfür spezielle Beladungssysteme zum Einsatz, die – im Gegensatz zu batch-orientierten Übertragungen – einer ereignisgesteuerten Logik folgen und die Daten im sog. Push-Betrieb in das C-DWH einspeisen. Weiterhin sind über geeignete Mechanismen dynamische Agg-

40

2.3 Detaillierung ODS-erweiterter Data Warehouses regationsbildungen und zeitnahe Datenübergaben an angeschlossenen Data Marts sicherzustellen (White 2005, S. 11 ff.). Die Auswahlentscheidung über die Aktualisierungsvariante kann nach technischen, inhaltlichen und organisatorischen Kriterien gefällt werden (vgl. auch Kapitel 3.1.3).

Data Marts

Data Marts besitzen einen hohen Grad an Anwendungsorientierung, haben ein wesentlich geringeres Datenvolumen als C-DWHs und sind meist auf einen spezifizierten Benutzerkreis bzw. auf eine Aufgabe ausgerichtet. Da sie häufig bereits vordefinierte Hierarchien, berechnete Aggregate und betriebswirtschaftliche Kennziffern in Form von Anreicherungen beinhalten, stellen sie nach Meinung vieler Kritiker keine Datenhaltung dar, sondern können bereits als Teil der Applikation aufgefasst werden. In der Tat ist der Übergang zwischen Datenhaltung und Anwendung bei dieser Form nahezu fließend, so dass in der Praxis häufig bei realen Systemen die Datenhaltung, die Funktionalität und die Benutzeroberflächen verschmelzen. Eine Gegenüberstellung der Charakteristika von Data Marts und Core Data Warehouses verdeutlicht die Abb. 2.14 (eine ausführliche Diskussion der OLAP-Technologien erfolgt in Kapitel 3.1.5). In kommerziellen DWH-Ansätzen werden zurzeit meist relationale Datenbanksysteme und werkzeugabhängige (proprietäre) Datenhaltungssysteme eingesetzt.

Physische Datenhaltung in C-DWHs und Data Marts

Relationale Systeme begannen seit den frühen 80er Jahren sich flächendeckend in den Unternehmen für operative und dispositive Anwendungsfelder zu etablieren. Sie gelten als sicher und stabil, besitzen leistungsfähige Berechtigungsverwaltungen, sind auf nahezu allen Hardwareplattformen verfügbar und haben sich auch bei großem Datenvolumen und hohen Benutzerzahlen bewährt. Die Datenhaltung in diesen Systemen beruht auf dem relationalen Datenmodell, das auf der Basis zweidimensionaler, flacher Tabellen die Darstellung von Objekten und Beziehungen ermöglicht. Zur Vermeidung von Redundanz und Anomalien wurde von dem Protagonisten des relationalen Datenmodells Edgar F. Codd in den 70er Jahren ein mathematisches Regelwerk entwickelt. Dieses Regelwerk, das als Normalformenlehre bekannt ist, stellt verschiedene Prinzipien der Relationenbildung dar, wobei ein Datenmodell als voll normalisiert gilt, wenn es die dritte Codd´sche Normalform erfüllt (eine Detaillierung der Normalformenlehre erfolgt in Æ Kapitel 2.4.1).

41

2 Datenbereitstellung und -modellierung

Charakteristika

Data Mart

Core Data Warehouse

Betriebswirtschaftliches Ziel

Effiziente Unterstützung der Entscheider einer Abteilung, ausgerichtet alleinig auf deren Analyseanforderungen

Effiziente Managementunterstützung durch strategische, taktische und operative Informationsobjekte für alle Entscheider in einem Unternehmen

Ausrichtung

Abteilungsbezogen

Zentral, unternehmensweit

Granularität der Daten

Zumeist höher aggregierte Daten

Kleinster Grad der Detaillierung

Semantisches Datenmodell

Semantisches Modell ist auf vorab modellierte Analyseanforderungen festgelegt

Semantisches Modell ist auch für zukünftige Analyseanforderungen offen

Modellierungskonventionen Heterogen (proprietäre Data Marts, jede Abteilung hat ihre eigenen Konventionen); Einheitlich (abgeleitete Data Marts, Konventionen des Core Data Warehouse werden übernommen)

Einheitlich

Verwendete OLAPTechnologie (hauptsächlich)

M-OLAP (proprietäre Data Marts) R-OLAP bzw. H-OLAP (abgeleitete Data Marts)

R-OLAP

Direkter Zugriff durch Endanwender

In der Regel möglich

Häufig nicht erlaubt; zentraler Betrieb des C-DWH durch IT-Abteilung; dient als Quelldatensystem für Data Marts

Freiheitsgrade der Analysen

Eher gering (Anwender kann über die Abteilungsgrenzen nicht hinaus sehen)

Flexibel; sämtliche zugänglichen (Sicherheit) Informationen können in Analysen einfließen

Einfluss von externen Datenquellen

Zumeist nicht gegeben, wenn ja, dann nur spezifischer Ausschnitt

Hoch; sämtliche verfügbaren externen Datenquellen werden integriert, um die Qualität der Analysen verbessern zu können

Datenvolumen

Gering bis moderat

Von moderat bis sehr umfangreich (bis in den Petabyte-Bereich)

Abb. 2.14: Data Marts und Core Data Warehouse (modifiziert übernommen aus Kurz 1999, S. 110 f.) Normalformenlehre

42

Die Eignung relationaler Datenhaltungssysteme für den Anwendungsbereich der Managementunterstützung kam Anfang der 90er Jahre in die Diskussion. Initiiert wurde die Auseinandersetzung durch die eher provokante These von Codd, die von ihm maßgeblich entwickelten relationalen Ansätze seien nicht geeignet, das Management adäquat zu unterstützen. Codd schlug vor, für diesen Anwendungsbereich physisch mehrdimensionale Datenhaltungssysteme einzusetzen, die u. a. eine höhere Performance und Flexibilität für das Anwendungsfeld böten.

2.3 Detaillierung ODS-erweiterter Data Warehouses

Proprietäre Systeme

2.3.3

Im Gegensatz zu relationalen Systemen sind diese Systeme bislang jedoch nicht standardisiert, häufig auch nicht auf große Benutzerzahlen ausgerichtet und erschweren aufgrund ihrer proprietären Strukturen zukünftige Migrationen. Obwohl sie auch größere Datenvolumina verwalten können (Eicker 2001, S. 70), werden sie aus den oben genannten Gründen meist nicht als Infrastruktursysteme im Core Data Warehouse eingesetzt. Trotzdem haben werkzeugspezifische, performanceoptimierte Datenhaltungssysteme heute einen festen Platz innerhalb der Managementunterstützung, wobei sie jedoch meist in Data Marts zum Einsatz kommen.

Operational Data Store Der Operational Data Store weist als harmonisierter Datenpool eine enge Verwandtschaft zum Data Warehouse auf, unterscheidet sich jedoch in wesentlichen Punkten von traditionellen DWHs. So verbindet ein Operational Data Store den Bereich der operativen Transaktionssysteme mit der dispositiven Systemlandschaft, um im Tagesgeschäft operative und taktische Entscheidungen zu unterstützen bzw. neue, transaktionsorientierte Dienstleistungen anbieten zu können. Als Integrator besitzt er Eigenständigkeit und gehört neben dem traditionellen DataWarehouse-Ansatz – bestehend aus C-DWH und Data Marts – zu den essenziellen Komponenten aktueller Datenhaltungskonzepte.

Definition Operational Data Store

Der Operational Data Store (ODS) kann definiert werden als eine Datenhaltung mit themenorientierten, integrierten, zeitpunktbezogenen, volatilen und detaillierten Daten (Inmon 1999, S. 12 ff.). Die einzelnen Charakteristika des ODS werden im Folgenden erläutert: • Themenorientierung Die Konzeption eines ODS erfolgt – genau wie beim Data Warehouse – anhand entscheidungsorientierter Perspektiven. Häufig verwendete Dimensionen betreffen z. B. die Produkte, Regionen oder Kunden (vgl. Abschnitt 2.2.1). • Integration Die im ODS enthaltenen Daten stammen aus den operativen Quellsystemen des Unternehmens. Bei der Überführung der Daten in den ODS erfolgt eine Transformation zu einer unternehmensweit einheitlichen und inhaltlich widerspruchsfreien Datensammlung. Der Transformationsprozess zur Befüllung des ODS ist daher dem Transformationsprozess zum Beladen eines 43

2 Datenbereitstellung und -modellierung Data Warehouse sehr ähnlich, beinhaltet jedoch primär nur die Stufen der Filterung und Harmonisierung. • Zeitpunktbezug Im ODS findet keine explizite Historisierung der übernommenen Daten statt. In der Regel werden die Daten lediglich über eine Zeitspanne von mehreren Tagen oder Wochen – primär aus Recovery-Gründen – vorgehalten. Daher sind auch keine zeitraumbezogenen Auswertungen möglich. • Volatilität Die Daten im ODS werden regelmäßig aktualisiert. Jede Änderung der Daten in den operativen Quellsystemen führt zu einem Überschreiben der Daten im ODS. Es existieren jedoch Unterschiede in der Aktualisierungshäufigkeit. Die Datenfortschreibung kann transaktionssynchron, d. h. zeitlich parallel zu den Änderungen in den Quellsystemen, stündlich oder auch täglich durchgeführt werden. Um die hohe Aktualität der Daten sinnvoll nutzen zu können, sollte ein ODS eine hohe Performance aufweisen. • Hoher Detaillierungsgrad 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 (Inmon 1999, S. 12 ff.). Die drei letztgenannten Charakteristika zeigen die wesentlichen Unterschiede zwischen einem ODS und einem Data Warehouse auf. Einen abschließenden Vergleich der Eigenschaftsprofile von operativen, Operational-Data-Store- sowie Data-Warehouse-Systemen verdeutlicht die Abb. 2.15. Die Erweiterung traditioneller DWH-Architekuren um ODSKonzepte hat gerade in den letzten Jahren enorm an Popularität gewonnen, da ODS zum einen für die Durchführung von Aktivitäten im Rahmen der Geschäftsprozessabwicklung von Relevanz sein können. Zum anderen bilden ODS die Basis für neue, prozessorientierte BI-Ansätze, die häufig unter dem (schillernden) Begriff Operational BI (s. u.) zusammengefasst werden.

44

2.3 Detaillierung ODS-erweiterter Data Warehouses Basisorientierung: Transaktion

Informationsobjekt

Zeitbezüge: Aktuell

Aktuell + historisch

Zugriffsart: Read-write

Read-only

Aggregationsgrad: Detailliert

Aggregiert

Integrationsgrad: Isoliert

Integriert

Zugänglichkeit: Real-time

Zeitverzögert Legende: Datenhaltung in operativen Systemen Datenhaltung in Operational Data Stores Datenhaltung im Data-Warehouse-System

Abb. 2.15: Eigenschaftsprofile von operativen, Operational-DataStore- und Data-Warehouse-Systemen (von Maur et al. 2003, S. 15)

Geschäftsprozessabwicklung Im Zuge des E-Business sind eine Reihe anwendungs- und funktionsbereichsübergreifende Applikationen entstanden. Beispiele sind Service- und Call-Center-Lösungen für das Customer Relationship Management, vernetzte Selbstbedienungsautomaten (Automatic Teller Machines – ATM) oder die Lieferungsverfolgung im Supply Chain Management. Hierbei müssen oftmals kurzfristig (quasi in Real-time) Daten aus den verschiedenen operativen Quellsystemen zur Verfügung gestellt werden, um eine zeitgerechte Prozessbearbeitung gewährleisten zu können. ODS können in diesen Fällen als harmonisierte Datenhaltungssysteme den Mitarbeitern einen ganzheitlichen Blick auf die Geschäftsprozesse ermöglichen und bieten somit einen Lösungsansatz zum Themenbereich Enterprise Application Integration (EAI) (von Maur et al. 2003, S. 13 f.). Operational BI Definition Operational BI

Wie so häufig, ist auch Operational BI zurzeit noch nicht eindeutig definiert, teilweise beliebig abgegrenzt und nicht selten werblich gefärbt. In diesem Lehrbuch bezeichnet Operational BI „…integrierte geschäftsprozessorientierte Systeme, die mit Hilfe klassischer Business Intelligence Methoden auf der Basis zeitna45

2 Datenbereitstellung und -modellierung her, prozessualer Ablaufdaten und in aller Regel auch historischer, gespeicherter Daten eine Real-time- (Near-real-time-) Unterstützung für zeitkritische Entscheidungen während des Prozessablaufes bieten.“ (Gluchowski et al. 2009). Einsatzgebiete für dieses Konzept finden sich beispielsweise in Versicherungs- und Banksystemen zur unmittelbaren Vermeidung von Betrugsfällen (Online Fraud Detection), bei denen das aktuelle Benutzerverhalten mit den ermittelten Standardprofilen aus Data-Mining-Anwendungen direkt verglichen werden kann. Aber auch im Bereich der Logistik ergeben sich vielfältige Einsatzmöglichkeiten. So bietet die BI-Infrastruktur eines großen deutschen Flughafenbetriebs bereits im Jahre 2009 neben den klassischen BI-Funktionalitäten vielfältige Analysen über die aktuellen Flugbewegungen, die momentane Flugplatzauslastung, den Stand der Gepäcklogistik oder der Wetterprognosen. Diese Analysen werden „near Real-time“ durchgeführt und aufbereitet, so dass sie sowohl zur direkten Steuerung der Prozesse herangezogen werden können als auch wertvollen Input für die längerfristige, strategische Gesamtplanung des Flughafens liefern (Weber 2009, S. 26 f.). Ein weiteres eindrucksvolles Beispiel einer leistungsfähigen Systeminfrastruktur im Operational BI-Kontext liefert ein global agierendes US-amerikanisches Unternehmen im Bereich des Casino-Entertainments, das weltweit namhafte Casino-, Hotelund Restaurantketten betreibt. Um die Kundenbindung zu erhöhen und Cross-Selling-Potentiale auszuschöpfen, implementierte die Unternehmung ein „Real-time CRM“. Für diese Zwecke erfolgte in den letzten Jahren die Entwicklung von ITInfrastrukturen und Kartensystemen, mit deren Hilfe sich das individuelle Verhalten sämtlicher Kunden zum Zeitpunkt der Servicenutzung erfassen lässt. So sind beispielweise in den Casinos Spieltische und Slot-Machines mit Kartenlesern ausgestattet, die der Kunde – wenn er zu den Millionen Kartenprogrammteilnehmern des Hauses gehört – zu seiner persönlichen Identifikation und zum Sammeln von Bonuspunkten benutzen kann. Die Karte wird während der Spielnutzung elektronisch ausgelesen und mit den in Data Warehouses abgelegten individuellen Benutzerinformationen zusammengeführt. Auf diese Weise lassen sich den Casino-Mitarbeitern bereits während der Spielnutzung die Identitäten der Kunden übermitteln. Spezifische Informationen, wie Spielgewohnheiten, Kundenwert, Loyalität, Getränkeund Essensvorlieben, Übernachtungs- und Unterhaltungsgepflogenheiten für den häufig angeschlossenen Entertainbereich sind 46

2.3 Detaillierung ODS-erweiterter Data Warehouses somit in Echtzeit verfügbar und sofort situativ nutzbar. Besondere Leistungen, wie Spielgutscheine, Lieblingsgetränke, Snacks, Übernachtungsofferten im konzerneigenen Hotels oder Angebote für Musicals präferierter Genres, können also guten Kunden zeitnah bereits beim Spielverlauf offeriert werden und erlauben die individuelle Ansprache (Turban et al. 2004).

2.3.4

Metadaten Metadaten werden zur Beschreibung der Bedeutung und der Eigenschaften von Objekten eingesetzt, um diese besser interpretieren, einordnen, verwalten und nutzen zu können. So werden beispielsweise Bücher in Bibliotheken mit Signaturen versehen, nach Schlagworten registriert und auf der Basis von Titeln, Autoren, Einsatzgebieten u. ä. klassifiziert. Diese Informationen werden in Form von Metadaten in spezielle Systeme eingestellt, gepflegt und den Benutzern zugänglich gemacht, um die Buchbestände sinnvoll verwenden zu können. Die Begrifflichkeit „meta“ lässt sich aus dem Griechischen ableiten und wird hier in der Bedeutung „auf einer höheren Stufe bzw. Ebene befindlich“ verwendet.

Definition Metadaten

In der Datenverarbeitung werden unter Metadaten allgemein alle Arten von Informationen verstanden, die für die Analyse, den Entwurf, die Konstruktion und die Nutzung eines Informationssystems erforderlich sind (Vaduva/Vetterli 2001, S. 273; Staudt et al. 1999, S. 7). Somit beschränken sich Metadaten im hier fokussierten BI-Bereich nicht allein auf die Entwicklung, sondern werden in allen Phasen des BI-Lebenszyklus generiert, verwaltet und genutzt. In DWH-/ODS-Konzepten kommt dem Metadatenmanagement ein besonderer Stellenwert zu, da aufgrund der Symbiose von Logik und Datenhaltung (vgl. z. B. Kapitel 2.3.1 und Kapitel 2.3.2) weitaus mehr Informationen vorgehalten werden müssen als in klassischen Datenhaltungssystemen der operativen Systeme.7

7

Als erste und einfachste Variante von Metadatenverwaltungssystemen wurden Systemkataloge in relationalen Datenbanksystemen eingesetzt. Diese als Data Dictionaries bezeichneten Systeme enthalten Informationen über angelegte Relationen und ihre Attributstruktur (Schreier 2001, S. 129).

47

2 Datenbereitstellung und -modellierung Metadaten über generierte betriebswirtschaftliche Kennzahlen, Verantwortlichkeiten, ...

Metadaten über rollenspezifische BenutzerProfile, Verantwortlichkeiten, ...

Metadaten über Dimensionshierarchisierungen, Änderungshistorien, Verantwortlichkeiten, ...

Metadaten über syntaktische und semantische Harmonisierungsregeln, Granularitäten, Verantwortlichkeiten, ...

Datenzugriffe Aggregation DimensionsHierarchisierung

Berechnung betriebswirtschaftlicher Kenngrößen Harmonisierung Betriebswirtschaftliche Harmonisierung Syntaktische Harmonisierung

Datenzugriffe

Datenzugriffe

Anreicherung

Metadaten über Extraktionswerkzeuge, MappingTabellen, Bereinigungsregeln, Verantwortlichkeiten, ...

Filterung Bereinigte Extrakte

Bereinigte Extrakte

Extrakte

Extrakte

Produktion Vertrieb

Extrakte

Metadaten über Hardware, Netze, Datenstruktur, Änderungsfrequenz, Alternativquellen, Verantwortlichkeiten,...

...

Technik Personal

Bereinigte Extrakte

...

F&E

Beschaffung

Operative Datenbestände

Abb. 2.16: Metadaten der dispositiven Datenbereitstellung Wie aus der Abb. 2.16 ersichtlich wird, stellt die Metadatenverwaltung hier ein zentrales Dokumentations- und Steuerungswerkzeug von BI-Anwendungssystemen dar. Sie erleichtert die Navigation und stellt detaillierte Informationen über Systemkomponenten sowie Prozesse zur Verfügung. Insbesondere schafft sie für den Anwender Klarheit darüber, aus welchen Quellen Daten zusammengesetzt werden, welche betriebswirtschaftlichen Kennzahlen verwendet werden und wie diese Kennzahlen aus betriebswirtschaftlicher Perspektive zu interpretieren sind (Kemper/Finger 2010, S. 173). Metadaten können nach den folgenden Nutzungskategorien unterschieden werden (Staudt et al. 2004, S. 328 f.; Kemper 1999, S. 223):

Passive und (semi-)aktive Metadaten

• Passive Metadaten ermöglichen eine konsistente Dokumentation der Struktur, des Entwicklungsprozesses und der Datenverwendung in einem BI-Anwendungssystem. Potenzielle Nutzer sind alle Akteure im BI-Umfeld, wie z. B. Endbenutzer, Systemadministratoren oder Systementwickler. • (Semi-)aktive Metadaten enthalten Strukturinformationen und Transformationsregeln und werden als integrale Bestandteile

48

2.3 Detaillierung ODS-erweiterter Data Warehouses der dispositiven Datenhaltungssysteme abgelegt. Diese Informationen können zu einer direkten (auch softwaregestützten) Überprüfung von Strukturen herangezogen (semi-aktive Metadaten) bzw. von Werkzeugen zur Laufzeit interpretiert und zur unmittelbaren Ausführung von Transformations- oder Analyseprozessen genutzt werden (aktive Metadaten).

Technische und betriebswirtschaftliche Metadaten

Des Weiteren lassen sich technische und betriebswirtschaftliche Metadaten differenzieren. Technische Metadaten konzentrieren sich auf IT-orientierte Aspekte der Transformationsschicht 1 (Filterungsschicht), während betriebswirtschaftliche Metadaten die Schichten 2 bis 4 (Harmonisierung, Aggregation, Anreicherung) und die Berechtigungsverwaltung fokussieren (Kemper 1999, S. 224). Die Erzeugung und das Management der Metadaten dienen

Metadatennutzung

• der Effizienzsteigerung der Entwicklung und des Betriebs von BI-Anwendungssystemen sowie • der Effektivitätssteigerung der Nutzung von BI-Anwendungssystemen. Für die Entwicklung und den Betrieb ergeben sich Vorteile in den folgenden Bereichen: • Anpassung an Quellsysteme Die Übernahme operativer und externer Datenquellen erfolgt in der Filterungsschicht (Transformationsschicht 1). Die hier durchzuführenden Extraktions- und Bereinigungsprozesse können mit Hilfe von Metadaten dokumentiert werden und sind auf diese Weise leicht modifizier- und erweiterbar. • Harmonisierung der Daten aus heterogenen Quellsystemen In der Harmonisierungsschicht (Transformationsschicht 2) sind die operativen Quellen syntaktisch und semantisch zu integrieren. Informationen über Struktur und Bedeutung der Quellsysteme erleichtern diese Transformationsaktivitäten und unterstützen somit effiziente Neuentwicklungen und Erweiterungen von BI-Anwendungssystemen. • Wartung und Wiederverwendung Die Speicherung von Metadaten außerhalb der Anwendungsprogramme vereinfacht sowohl die Wartung als auch die Anpassung und Erweiterung erheblich. Aufgrund der konsistenten, zentralen Ablage der Metadaten lassen sich betriebswirtschaftliche und technische Änderungen in den analytischen Systemen schnell und widerspruchsfrei durchführen, wobei 49

2 Datenbereitstellung und -modellierung die Mehrfachverwendung von Daten-Teilmodellen oder von Transformationsprozessen wirkungsvoll unterstützt wird. • Berechtigungsverwaltung Die Berechtigungsverwaltung ist in integrierten BI-Konzepten nicht länger Bestandteil eines jeden Einzelsystems, sondern stellt eine zentrale Komponente der dispositiven Datenbereitstellung dar (Kemper 1999, S. 221). Benutzerrollen werden mit Hilfe von Metadaten beschrieben und erlauben eine konsistente Zugriffsadministration, wobei eine einfache Pflege und die effiziente Kontrolle der Beziehungen zwischen BI-Nutzern, BIAnwendungen und den jeweiligen Datenberechtigungen ermöglicht wird. Aus Benutzersicht sind vor allem Qualitäts- und Terminologieaspekte relevant: • Datenqualität Informationen über den gesamten Transformationsprozess (vgl. Abb. 2.16) dienen der Transparenz der Datenherleitung von der Datenquelle bis zur Datenverwendung. Informationen über Verantwortlichkeiten, Qualitäten der Quellsysteme, Harmonisierungsroutinen, Anreicherungen u. ä. dokumentieren den Prozess der Informationsgenerierung und sichern somit die Datenqualität bzgl. der Konsistenz, Aktualität, Genauigkeit und Vollständigkeit. • Begriffsverständnis Die Metadaten dokumentieren die betriebswirtschaftlichen Kennzahlen bzgl. ihrer Bezeichnung, Abgrenzung, Herkunft und Verwendung. Die dispositive Datenhaltung stellt somit einen single point of truth dar, der über die Metadaten organisationsweit nutzbar gemacht wird und zu einer abgestimmten Terminologie im Unternehmen führt.

Architekturvarianten des Metadatenmanagements Unternehmensindividuelle BI-Ansätze sind komplex und bestehen aus einer Vielzahl von spezifischen Komponenten. Für diese Einzelkomponenten existieren am Markt Werkzeuge, mit deren Hilfe sie entwickelt und in den Unternehmenskontext integriert werden können. Grundsätzlich können in der Praxis hierbei zwei Entwicklungslinien festgestellt werden, sog. End-to-End- und Best-Of-Breed-Ansätze. End-to-End

50

Kommerzielle Anbieter von End-to-End-Lösungen bieten eine Vielzahl abgestimmter Werkzeuge zum Aufbau unternehmens-

2.3 Detaillierung ODS-erweiterter Data Warehouses spezifischer BI-Konzepte an. Ihre Werkzeuge unterstützen somit sämtliche Entwicklungs- und Betreiberprozesse vom ETL-Design bis zur Portalintegration der BI-Anwendungen. Best-of-Breed

Softwarehersteller von Best-of-Breed-Lösungen bieten hingegen spezialisierte Werkzeuge zur Entwicklung leistungsfähiger Einzelkomponenten eines unternehmensspezifischen BI-Konzeptes. In der Praxis werden diese unterschiedlichen Ansätze kontrovers diskutiert. Auch ohne an dieser Stelle eine kritische Bewertung dieser Diskussion vorzunehmen, wird deutlich, dass eine konsistente Metadaten-Verwaltung aller Komponenten eines integrierten BI-Ansatzes äußerst komplex ist. Im Folgenden werden drei gängige Architekturvarianten vorgestellt, wobei neben einer zentralisierten Lösung zwei Ansätze des verteilten Metadatenmanagements in heterogenen Systemumgebungen diskutiert werden (Do/Rahm 2000, S. 8). • Zentrales Metadatenmanagement Ein zentralisierter Ansatz des Metadatenmanagements (vgl. Abb. 2.17) basiert auf einem zentralen physischen Repository, wobei hier unter einem Repository eine Datenbank verstanden wird, die zur Verwaltung von Metadaten eingesetzt wird.

Metadaten

REP

Data Mart

ODS

Data Mart

Data Mart

Core Data Warehouse

ETL Operative Systeme

SCM

ERP CRM Wertschöpfungskette

E-Proc.

Abb. 2.17: Zentrales Metadaten-Repository Bei einer zentralistischen Lösung werden sowohl die gemeinsam genutzten als auch die spezifischen Metadaten aller beteiligten 51

2 Datenbereitstellung und -modellierung Komponenten der dispositiven Datenhaltung und der Berechtigungsstrukturen gespeichert. Verständlicherweise ist eine solche monolithische Lösung vor allem bei End-to-End-Ansätzen denkbar, während bei Best-of-Breed-Lösungen die Entwicklung eines zentralisierten Ansatzes aufgrund der Schnittstellenproblematik sich erheblich komplexer darstellt. Als Vorteile ergeben sich ein redundanzfreies und konsistentes Metadatenmanagement, ein globaler Zugriff auf alle Metadaten sowie der Verzicht auf Austauschmechanismen für die Metadaten. Nachteilig können sich die Abhängigkeiten von der zentralen Datenhaltungskomponente, eine komplexe zentrale Wartung komponentenspezifischer Metadaten sowie die teilweise nicht zufrieden stellende Performance großer zentraler Lösungen auswirken. In der Praxis haben sich aufgrund der Komplexität bislang keine satisfizierenden zentralen Lösungsansätze etablieren können.

REP

REP

Schnittstellen REP

Data Mart

Metadaten

REP

Data Mart

Data Mart

REP

ODS

Core Data Warehouse

ETL Operative Systeme

SCM

ERP CRM Wertschöpfungskette

E-Proc.

Abb. 2.18: Dezentrale Metadaten-Repositories

• Dezentrales Metadatenmanagement Den gegenteiligen Ansatz stellt das dezentrale Metadatenmanagement dar (vgl Abb. 2.18). Alle Komponenten eines BIAnwendungssystems verfügen über ein eigenes, lokales Metadaten-Repository und kommunizieren miteinander, um Metadaten 52

2.3 Detaillierung ODS-erweiterter Data Warehouses auszutauschen. Diese Situation ist typisch für den derzeitigen Stand der Implementierungen von BI-Anwendungssystemen. Vorteilhaft sind die große Autonomie der Anwendungen sowie der schnelle lokale Zugriff auf die Metadaten. Als Nachteile ergeben sich die zahlreichen Schnittstellen zwischen den verschiedenen Repositories und die redundante Haltung der Metadaten, die nur schwer zu synchronisieren sind. • Föderiertes Metadatenmanagement

REP

REP REP

REP

Data Mart

Metadaten

REP

Metadaten-Manager

Eine Kombination der beiden vorgenannten Ansätze stellt das föderierte Metadatenmanagement dar (vgl. Abb. 2.19). Jede Komponente eines BI-Anwendungssystems verwaltet ihre eigenen Metadaten in einem lokalen Repository. Darüber hinaus existiert ein zentrales Metadaten-Repository, in dem gemeinsam genutzte Metadaten verwaltet werden. Der Austausch der Metadaten zwischen den einzelnen BI-Komponenten und dem zentralen Repository verläuft über eine definierte Schnittstelle, die auf einem standardisierten Metadaten-Modell wie z. B. dem unten beschriebenen Common Warehouse Metamodel (CWM) basiert. Die Vorteile dieser Architekturvariante liegen in einer einheitlichen Repräsentation der gemeinsam genutzten Metadaten, in der Autonomie der lokalen Repositories, in der stark reduzierten Zahl der Schnittstellen zwischen den Repositories sowie in der kontrollierten Redundanz der Metadatenhaltung (Do/Rahm 2000, S. 8 f.).

ODS

Data Mart

Data Mart

Core Data Warehouse

ETL Operative Systeme

SCM

ERP CRM Wertschöpfungskette

E-Proc.

Abb. 2.19: Föderative Metadaten-Repositories 53

2 Datenbereitstellung und -modellierung

Austauschstandard für Metadaten

2.3.5

Ein Austauschstandard im Umfeld des Metadatenmanagements hat die Aufgabe, als flexibles, herstellerunabhängiges und formal definiertes Rahmenwerk den Austausch von Metadaten zwischen BI-Werkzeugen und Metadaten-Repositories in einer verteilten heterogenen Systemumgebung zu ermöglichen. In diesem Kontext findet der seit 2001 gültige Standard Common Warehouse Metamodel8 (CWM) eine zunehmende Verbreitung. Er wurde unter dem Dach der Object Management Group9 (OMG) entwickelt (Lehner 2003, S. 48 f.) und ermöglicht eine vollständige Spezifikation der für den Austausch von Metadaten erforderlichen Syntax und Semantik.

Berechtigungsstrukturen In den traditionellen, historisch gewachsenen Systemen der Managementunterstützung erfolgt die Regelung der Zugriffsrechte meist in den einzelnen Systemen. BI-Konzepte mit integrierter Datenhaltung erlauben im Gegensatz dazu eine zentrale Berechtigungsverwaltung, die einen essentiellen Bestandteil des Datenhaltungssystems darstellt. Somit können Zugriffsrechte für sämtliche Analysesysteme konsistent abgelegt werden, wodurch die ansonsten unvermeidbare Redundanz in den getrennten Berechtigungsverwaltungen mehrerer Analysesysteme entfällt.

Rollenbasierte Zugriffskontrolle

54

Aufgrund ihrer hohen Flexibilität etablieren sich zunehmend sog. rollenbasierte Zugriffskontrollen (Role-based access control, RBAC). In diesem Konzept werden Benutzern bzw. Benutzergruppen aufgrund ihrer Aufgaben und Verantwortlichkeiten die Mitgliedschaften an benötigten Rollen zugewiesen. Rollen stellen somit eine Weiterentwicklung des traditionellen Konzeptes dar, in dem der Fokus auf die einzelnen Personen bzw. auf eine Gruppe von Personen gerichtet ist. In Rollen dagegen werden Rechte zusammengefasst, die zur Erfüllung definierter Aufgaben und Funktionen nach dem Need-to-know-Prinzip erforderlich sind. Diese Ausrichtung ermöglicht eine zeitstabilere und wesentlich vereinfachte Pflege. Zugriffsrechte, wie z. B. das Lesen, Schreiben und Modifizieren von Daten oder das Ausführen von Funktionen bzw. Anwendungssystemen auf der Basis abgegrenzter Datensichten werden somit sachlich begründet und erleichtern die Berechtigungspflege bei Veränderungen im Verantwor-

8

http://www.cwmforum.org/spec.htm

9

http://www.omg.org/technology/cwm

2.3 Detaillierung ODS-erweiterter Data Warehouses tungsprofil einzelner Mitarbeiter bzw. bei Personalneueinstellungen (Rupprecht 2003, S. 126). Die Abb. 2.20 zeigt ein rollenbasiertes Zugriffskonzept am Beispiel von Führungsaufgaben verschiedener Hierarchieebenen – hier der ersten, zweiten und dritten Führungsebene. Durch die Zuweisung von Datensichten zu diesen Rollen wird sichergestellt, dass alle Anspruchsgruppen durch eine Beschränkung des dispositiven Datenzugriffs auf bestimmte Tabellenfelder von Basis- oder Zusammenfassungstabellen nur mit ihrem aufgabenspezifischen Datenmaterial arbeiten können. So wird verhindert, dass Mitarbeiter auf die Daten anderer Verantwortungsbereiche zugreifen. Transferschichten

Realisiert wird diese Einschränkung der Datensicht mit Hilfe der Festlegung einer Einsprungadresse in die Daten sowie der gezielten Begrenzung der vertikalen Recherchetiefe und der horizontalen Recherchebreite. Des Weiteren werden horizontale und vertikale Transferschichten definiert. Diese gemeinsamen Datenräume stellen sicher, dass sowohl zwischen vorgesetzten und nachgelagerten als auch zwischen horizontal kooperierenden Organisationseinheiten Datensichten existieren, die teilweise identisch sind und die managementspezifische Kommunikationsund Kooperationsprozesse unterstützen können.

Relevanz der Berechtigungsadministration

Die konsequente Beachtung des Need-to-Know-Prinzips kann in stark arbeitsteiligen Organisationen zu einer komplexen, detailreichen Berechtigungsverwaltung führen. So sollte die Möglichkeit existieren, die Zugriffe auf alle Stufen der Auswertungsdimensionen einzuschränken und im Bedarfsfall Berechtigungen für einzelne Analyseobjekte und Kennzahlen zu vergeben. Da gleichzeitig kontinuierlich organisatorische Veränderungen nachgehalten werden müssen, kann die Berechtigungsverwaltung einen erheblichen Administrationsaufwand nach sich ziehen. Im Rahmen des Betriebs des Data Warehouse sind deshalb in größeren BI-Umgebungen Lösungen zu entwickeln, die eine effiziente, schnelle und toolgestützte Abwicklung der entsprechenden Prozesse erlauben.

55

2 Datenbereitstellung und -modellierung Verantwortungsbereich: Beispiel A Rechercheraum der 1. Führungsebene

Gemeinsamer Datenraum von A und B

A

Verantwortungsbereich: Beispiel B

B

Rechercheraum der 2. Führungsebene

C

Horizontale und vertikale Transferschichten Rechercheraum der 3. Führungsebene

D

E

F

G

H

I

Prozesse der Wertschöpfung Legende: A bis I = Verantwortungsträger

Abb. 2.20: Einschränkung der Recherchemöglichkeit durch eine hierarchieorientierte rollenbasierte Zugriffskontrolle (Kemper 1999, S. 222)

2.3.6

Administrationsschnittstellen Es herrscht allgemein Konsens darüber, dass Berechtigungsverwaltungen einfache und intuitive Benutzungsoberflächen erfordern. Hingegen ist nicht selten in der Praxis die Meinung anzutreffen, dass komfortable Administrationsschnittstellen für die Pflege der dispositiven Datenbestände irrelevant seien, da Transformationsprozesse vollständig beschrieben werden könnten und relativ zeitstabile Strukturen aufwiesen. Diese Annahme ist nicht korrekt. Vielmehr sind bei vielen ETL-Prozessen manuelle Datenkorrekturen bzw. -manipulationen durchzuführen, und auch die Transformationsprozesse selbst unterliegen zeitlichen Veränderungsprozessen (vgl. Kapitel 2.3.1). Neben einem komfortablen Zugang zur Berechtigungsverwaltung sind daher bereits im DWH-/ODS-Konzept entsprechende Administrationsschnittstellen einzuplanen.

Definition Administrationsschnittstellen

56

Administrationsschnittstellen sind systemgestützte Zugänge, mit deren Hilfe technische und betriebswirtschaftliche Spezialisten sämtliche Bereiche der dispositiven Datenhaltung pflegen und somit

2.3 Detaillierung ODS-erweiterter Data Warehouses • Transformationsregeln, • dispositive Daten oder Datengruppen und • rollenbasierte Zugriffsberechtigungen generieren, modifizieren und löschen können. Generell wird zwischen einer technisch orientierten Schnittstelle (technische Administrationsschnittstelle) und einer betriebswirtschaftlichen Schnittstelle (fachliche Administrationsschnittstelle) unterschieden (vgl. Abb. 2.21). • Technische Administrationsschnittstelle Über die technische Administrationsschnittstelle können Spezialisten interaktiv sämtliche Daten und Transformationsregeln der Filterungsschicht pflegen. Hierzu gehören neben der direkten Datenmanipulation die Einrichtung, Modifikation, Einschränkung oder Erweiterung aller Strukturen zur Extraktion und Bereinigung, wobei den technischen Metadaten Dokumentations- und Steuerungsfunktionen zukommen (vgl. Abb. 2.21). • Fachliche Administrationsschnittstelle Die fachliche Administrationsschnittstelle dient der Pflege der Daten und Strukturen der oberen drei Transformationsschichten (Harmonisierung, Aggregation, Anreicherung) sowie der Verwaltung des Berechtigungskonzeptes. Die betriebswirtschaftlichen Spezialisten verwenden die fachliche Administrationsschnittstelle beispielsweise, um syntaktische und semantische Harmonisierungsprozesse, Hierarchiebäume, notwendige Zusammenfassungstabellen oder betriebswirtschaftliche Kennzahlen interaktiv zu bilden, zu bearbeiten und zu pflegen. Des Weiteren wird diese Komponente genutzt, um die zu den transformierten Ist-Werten korrespondierenden Vergleichswerte – meist Plan- bzw. Budgetwerte – manuell oder (halb-)automatisch in das Data Warehouse zu integrieren. Im Kontext der Berechtigungsverwaltung dient die fachliche Administrationsschnittstelle der intuitiven Zuordnung von rollenkonformen Datenberechtigungen und korrespondierenden Analysesystemen zu Mitarbeitern oder Mitarbeitergruppen (Rollenträger). Auch hier dienen die betriebswirtschaftlichen Metadaten – in Analogie zu der technischen Administrationsschnittstelle – primär der Dokumentation und Steuerung sämtlicher Abläufe.

57

2 Datenbereitstellung und -modellierung

Berechtigungs-Verwaltung

betriebswirtschaftliche

Metadaten-Verwaltung Anreicherung

Fachliche Administrationsschnittstelle

Aggregation Harmonisierung

Dispositve Datenhaltung

semantische Harm. syntaktische Harm.

Filterung

Bereinigung Extraktion

Technische Administrationsschnittstelle

technische Metadaten-Verw. operative Datenschnittstelle

operative / externe Daten

Abb. 2.21: Technische und fachliche Administrationsschnittstellen (Kemper 1999, S. 229)

2.4

Modellierung multidimensionaler Datenräume Dieses Kapitel beschäftigt sich mit dem Bereich der Datenmodellierung in multidimensionalen Datenräumen, der vor allem für die Modellierung in applikationsklassenorientierten Data Marts von Relevanz ist. Die Ausführungen starten mit den Grundlagen der Datenmodellierung. Aktuelle Ansätze multidimensionaler Schemata und wichtige Fragen der Historisierung folgen. Das Kapitel schließt mit einer umfassenden Darstellung einer Fallstudie.

2.4.1

Grundlagen der Datenmodellierung Grundsätzlich beschreiben Datenmodelle die Bedeutung und Repräsentation von Daten, wobei sie als abstrakte Abbildungen von Realitätsausschnitten aufgefasst werden können. Je nach Ausrichtung können semantische, logische und physische Modelle unterschieden werden. Während physische Modelle techniknah ausgerichtet sind und auf die Belange der Speicherung abzielen, sind logische und semantische Modelle enger an der Realwelt orientiert.

58

2.4 Modellierung multidimensionaler Datenräume Semantische Modelle haben hierbei die größte Nähe zur Realwelt und bilden einen (betriebswirtschaftlichen) Zusammenhang auf einer vollständig technologieneutralen Ebene ab. Einer der bekanntesten Vertreter semantischer Modellierungsansätze ist der Entity-Relationship-Ansatz. Semantische Modelle bilden die Brücke zu logischen Modellen, die zwar noch losgelöst von der technischen Implementierung auf den Speichermedien sind, jedoch bereits den Einsatz spezieller Datenhaltungssysteme determinieren. Bekanntester Vertreter dieser Modellierung ist das relationale Datenmodell (Hahne 2002, S. 9).

A

1:n-Beziehungen

n

AB

1

A

Ein Element von A kommt in n Ausprägungen AB vor (Schlageter/Stucky-Notation)

B A

Generalisierung / Spezialisierung

B und C sind Teilmengen von A

B

C

B

disjunkt

A

ABC

nicht disjunkt

B

Aggregation

C

Uminterpretation von Beziehungsin Entitytypen

A

AB ABC

C

ABC wird aus den Objekten A, B und C gebildet

B AB geht mit C die Beziehung ABC ein

C Abb. 2.22: Erweiterte ERM-Notation (modifiziert übernommen aus Scheer 1998, S. 45)

EntityRelationshipModell

Das Entity-Relationship-Modell (ERM) ist bereits in den 70er Jahren von Peter Chen entwickelt und im Lauf der Jahrzehnte modifiziert und erweitert worden. Es besteht im Kern aus Entitätstypen, die sich als Sammlung gleich strukturierter Entitäten (Objekte) verstehen und aus Beziehungstypen, welche die gleich strukturierten Beziehungen zwischen den Entitäten der beteiligten Entitätstypen darstellen. 59

2 Datenbereitstellung und -modellierung Die Abb. 2.22 verdeutlicht die hier im Buch verwendete, erweiterte Notation, die sich auch im Gebrauch der Kardinalitäten von der ursprünglichen Chen-Darstellung unterscheidet. Aus Gründen der Eindeutigkeit bei Involvierung mehrerer Entitätstypen wird die Chen-Notation „gedreht“, so dass die Kardinalität eines Entitätstyps jeweils das Vorkommen einer Entitätsausprägung in den Beziehungen des Beziehungstyps meint (Schlageter/Stucky 1983, S. 51). Ein Anwendungsbeispiel eines ERMs findet sich in Abb. 2.23. ZEIT

KT1 m KT2

TYP

KUNDE

1

n

Auftrag

1

n

AUFTRAGSPOS.

m

PRODUKT

m

n

KT3 GEHÖRT ZU

. . .

ZUSTÄNDIG

n KONDITIONEN

STRUKTUR

n VERKÄUFER

Abb. 2.23: ERM-Beispiel Das ERM stellt einen Ausschnitt aus dem Geschäftsumfeld eines PC-Handelhauses dar. Es wird deutlich, dass Kunden eindeutig bestimmten Kundenkategorien (KT) sowie einer definierten Konditionengruppe zugeordnet werden. Ein Auftrag wird aus der Kundennummer und einem Zeitstempel gebildet. Dieser Beziehungstyp wird in einen Entitätstyp umgewandelt, um mit diesem neu gebildeten Konstrukt weitere Modellierungsaktionen durchführen zu können. So wird ersichtlich, dass ein Auftrag exakt einem Verkäufer zugeordnet wird. Weiterhin kann ein Auftrag eine nicht beschränkte Anzahl von Produkten aufweisen, wobei die Produkte (als Gattungsprodukte) auch in verschiedenen Aufträgen vorkommen können. Die Entitäten des Entitätstyps PRODUKT können weiterhin reflexive Beziehungen aufweisen, also mit anderen Entitäten des Entitätstyps im Zusammenhang

60

2.4 Modellierung multidimensionaler Datenräume stehen. Dieses Konstrukt stellt somit eine Stückliste dar, welche die Struktur zusammengesetzter Produkte beschreibt. Da semantische Modellierungen in Form von Entity-RelationshipModellen sehr einfach in logische Relationenmodelle überführt werden können, werden diese beiden Modellierungsvarianten häufig gemeinsam verwendet. Relationenmodelle basieren auf Relationen, die sowohl Entitätstypen als auch Beziehungstypen darstellen können. Relationen besitzen einen eindeutigen Namen und zugehörige Attribute, von denen eines oder eine Kombination von mehreren einen Primärschlüssel bilden. Dieser wird jeweils durch Unterstreichen kenntlich gemacht. Relationen werden in Form zweidimensionaler Tabellen abgebildet, die einen eindeutigen Namen besitzen. Die Spalten der Tabelle beinhalten Attributswerte. Die Zeilen (Tupel) sind eindeutig über Primärschlüsselausprägungen identifizierbar und repräsentieren zusammengehörige Werte für eine Entität oder Beziehung. Die Abb. 2.24 verdeutlicht den Zusammenhang.

Relationale Datenmodelle

Name der Relation Primärschlüssel Mitarbeiter

Tupel

Attribute

MA#

NAME

WOHNORT

GEBURTSORT

GEBURTSDATUM

ANSTELLUNGSDATUM

1001

Müller

Köln

Berlin

16.01.1973

08.08.2001

1002

Ott

Kiel

Berlin

20.04.1957

24.11.1999

1003

Meier

Essen

München

09.04.1978

17.05.2003

… Attributausprägungen

Abb. 2.24: Beispiel einer Relation Die Überführung eines ERMs in ein relationales Datenmodell wird wie folgt durchgeführt: • Jeder Entitätstyp wird im Relationenmodell zu einer eigenständigen Relation. • Jeder komplexe Beziehungstyp (n:m-Beziehung) wird ebenfalls eine eigenständige Relation, wobei die Tabelle einen aus

61

2 Datenbereitstellung und -modellierung allen involvierten Entitätstypen zusammengesetzten Primärschlüssel erhält. • Die Abbildung einfacher Beziehungstypen (1:n-Beziehung) erfordert keine eigenständige Relation. Bei der hier verwendeten Kardinalitätsnotation wird der Primärschlüssel des Entitätstypen mit der „n-Beziehung“ als Attribut in den Entitätstypen mit der „1-Beziehung“ eingebunden. Die Abb. 2.25 zeigt die Umwandlung auf der Basis eines einfachen Beispiels, in dem Kunden individuelle Einzelprodukte kaufen, zu deren Erstellung mehrere Mitarbeiter mit einer bestimmten Anzahl von Arbeitsstunden erforderlich sind.

wird über den Fremdschlüssel KD# in der Produkt-Relation dokumentiert n KUNDE

KAUFT

1

n PRODUKT

FERTIGT

m

MITARBEITER

werden Tabellen Relationen: KUNDE(KD#, Name, ...) PRODUKT(PR#, Preis, ..., KD# ) MITARBEITER(MA#, Name, ...) FERTIGT(PR#, MA#, Arbeitstunden, ...)

Abb. 2.25: Umwandlung eines ERMs in ein Relationenmodell Die Ableitung eines Relationenmodells aus einem ERM stellt als Top-Down-Ansatz lediglich eine Variante der Modellbildung dar. Häufig ist jedoch auch der Bottom-Up-Ansatz oder eine Symbiose von beidem erforderlich, um ein geeignetes Modell zu entwickeln. So ist es in der Praxis nicht selten, dass Teile der erforderlichen Datenmodelle auf der Basis bestehender Berichtsstrukturen oder anderer Dokumente zu entwickeln sind. In diesen Fällen ist die Normalformenlehre von besonderer Relevanz. Sie geht zurück auf Edgar F. Codd, der als Protagonist der relationalen Modellierung bereits in den 70er Jahren ein mathematisches 62

2.4 Modellierung multidimensionaler Datenräume Regelwerk entwickelte, um existierende Relationen in redundanzärmere Datenstrukturen zu überführen.

Redundanz

Redundanz meint in diesem Zusammenhang das mehrfache Speichern identischer Attributswerte ein und derselben Objektausprägung. So stellt das mehrfache Speichern des Namens „Meier“ innerhalb einer Tabelle beispielsweise keine Redundanz dar, so lange diese Attributsausprägungen jeweils für unterschiedliche Entitäten abgelegt werden. Es ist leicht einsehbar, dass Redundanz innerhalb einer Datenhaltung zu sog. Anomalien führen kann, also zu konsistenzgefährdenden Komplikationen bei Einschub-, Modifikations- und Löschoperationen.

Normalisierungsprozess

Im Zeitverlauf sind eine Vielzahl von Vorschriften und Prinzipien entwickelt worden, um Datenbestände in redundanzarme bzw. redundanzfreie Strukturen zu überführen. Allgemein gilt jedoch ein Relationenmodell bereits als voll normalisiert, wenn es der dritten Codd´schen Normalform entspricht.

Erste Normalform (1NF)

Eine Relation befindet sich in der ersten Normalform, wenn alle Nicht-Schlüsselattribute funktional von einem Schlüssel der Tabelle abhängen. Attributsausprägungen dürfen dabei nur aus einfachen (also nicht mengenmäßigen) Werten bestehen.

Zweite Normalform (2NF)

Relationen der zweiten Normalform müssen so konstruiert sein, dass sie den Anforderungen der 1NF genügen und alle NichtSchlüsselattribute funktional vom gesamten Schlüssel abhängen. Somit muss ausgeschlossen werden, dass bereits Schlüsselteile (z. B. bereits ein Attribut eines zusammengesetzten Schlüssels) bestimmte Attribute der Relation identifizieren können.

Dritte Normalform (3NF)

Eine Relation entspricht der dritten Normalform, wenn sie den Anforderungen der 2NF genügt und zusätzlich keine funktionalen Abhängigkeiten zwischen Nicht-Schlüsselattributen existieren. In der dritten Normalform gilt demnach, dass lediglich der Primärschlüssel der Relation Attribute identifizieren darf. So stellt z. B. das Speichern von „Mitarbeiternummer“ und „Mitarbeitername“ als Nichtschlüsselattribute eine Verletzung der 3NF dar, weil die „Mitarbeiternummer“ den Namen der Mitarbeiter eindeutig identifiziert. Im Folgenden soll dieser Sachverhalt anhand eines Beispiels verdeutlicht werden (modifiziert übernommen aus Vetter 1998). Die Abb. 2.26 zeigt eine unnormalisierte Tabelle, deren fachlicher Inhalt von Menschen leicht interpretierbar ist, jedoch im relationalen Kontext aufgrund des Fehlens von Primärschlüsseln, 63

2 Datenbereitstellung und -modellierung der Mehrfachbelegung von Feldern und der Existenz von Redundanzen zu erheblichen Problemen bei Einschub-, Modifikations- oder Löschoperationen führen kann. Die Tabelle repräsentiert den folgenden Zusammenhang: • Personen besitzen jeweils eine Personalnummer (PE#), die jeden Mitarbeiter eindeutig identifiziert. • Personen besitzen jeweils einen Namen, wohnen an genau einem Wohnort und sind exakt einer Abteilung (A-NAME) zugeordnet, die sich über eine Abteilungsnummer (A#) identifizieren lässt. • Die Personen sind am Erstellungsprozess von beliebig vielen Produkten (PR-NAME) beteiligt, die sich eindeutig über die Produktnummer (PR#) identifizieren lassen. Für die Erstellung von Produkten benötigen die Personen – je nach Können und Erfahrung – verschiedene Zeiten, so dass die Bearbeitungszeit (ZEIT) für ein Produkt von dem Produkt selbst und dem Mitarbeiter determiniert wird. Person-UN UPDATE

PE# 101 102 103 104

NAME Hans Rolf Urs Paul

WOHNORT Zürich Basel Genf Zürich

A# 1 2 2 1

A-NAME Physik Chemie Chemie Physik

PR# 11,12 13 11,12,13

PR-NAME A, B C A, B, C A, C

ZEIT 60, 40 100 20, 50, 30 80, 20

EINSCHUB

105

Max

Bern

1

EDV

12, 13

X, Y

25, 78

nicht existierender Schlüsselwert (Einschub wird akzeptiert)

Realitätswidrige Aussagen

Abb. 2.26: Unnormalisierte Tabelle (modifiziert übernommen aus Vetter 1998) Um aus der unnormalisierten Tabelle eine Datenstruktur zu entwickeln, die der dritten Normalform entspricht, müssten zunächst zur Wahrung der ersten Normalform die Mehrfachbelegungen der Felder eliminiert werden und ein Primärschlüssel zur eindeutigen Identifikation der Nicht-Schlüsselattribute definiert werden. Das könnte in diesem Falle ein zusammengesetzter Schlüssel aus Personennummer und Produktnummer (PE#,PR#) sein. Zur Umsetzung der zweiten Normalform müsste darauf geachtet werden, dass nicht bereits Schlüsselteile des zusammengesetzten Primärschlüssels einzelne Attribute bestimmen. Im vorliegenden Beispiel wäre ein zusammengesetzter Primärschlüssel aus Personennummer und Produktnummer (PE#,PR#) lediglich für die Identifikation des Attributes ZEIT erforderlich, während die ande64

2.4 Modellierung multidimensionaler Datenräume ren Attribute bereits aufgrund der Schlüsselteile identifiziert werden können. So identifiziert der Teilschlüssel PE# eindeutig die Attribute NAME, WOHNORT, A#, A-NAME, während der andere Schüsselteil PR# eindeutig das Attribut PR-NAME bestimmt. Somit müsste die Tabelle in drei Einzeltabellen zerlegt werden. Um der dritten Normalform zu entsprechen, dürfen keine funktionalen Abhängigkeiten zwischen Nicht-Schlüsselattributen existieren. Da aber bereits die Abteilungsnummer (A#) das Attribut A-NAME determiniert, ist auch hier eine neue Tabelle zu definieren. Die Abb. 2.27 zeigt das Ergebnis des gesamten Normalisierungsprozesses. Eine vollständige Ausrichtung der Datenhaltung an den Normalisierungsvorschriften bewirkt, dass Datenbestände völlig applikationsneutral und redundanzfrei abgelegt werden können. In der Praxis wird dieser Forderung verständlicherweise nicht immer zur Gänze nachgekommen, da die geforderte Aufteilung in zu viele separierte Tabellen zu Wartungs- und Performanceproblemen führen würde. So ist es in den Unternehmen üblich, bewusst kleinere Verletzungen – meist im Bereich der 3NF – hinzunehmen, um leistungsstarke Datenhaltungssysteme anbieten zu können.

PRODUKT

Person

PR# 11 12 13

PE# 101 102 103 104

PR-NAME A B C

NAME Hans Rolf Urs Paul

WOHNORT Zürich Basel Genf Zürich

A# 1 2 2 1

PE-PR

PE# 101 101 102 103 103 103 104 104

Abteilung

A# 1 2

PR# 11 12 13 11 12 13 11 13

ZEIT 60 40 100 20 50 30 80 20

A-NAME Physik Chemie

Abb. 2.27: Voll normalisierte Datenstruktur (modifiziert übernommen aus Vetter 1998) Diese Datenhaltungssysteme sind trotzdem weitestgehend applikationsneutral und werden daher häufig auch als „nahe der 3NF“ bezeichnet. Auch der Aufbau eines Core Data Warehouse erfolgt in aller Regel auf der Basis dieser Kriterien, da das Datenvolu65

2 Datenbereitstellung und -modellierung men und die Einsatzcharakteristika des C-DWH eine zu starke Applikationsausrichtung verbieten. Data Marts sind hingegen als applikationsklassenorientierte Datenhaltungen anzusehen, für die performanceoptimierte Modellierungen heranzuziehen sind. Im Folgenden werden diese Modellierungsvarianten ausführlich vorgestellt und diskutiert.

2.4.2

Star-Schema und Varianten In Data Marts werden häufig multidimensionale Datenräume definiert, die bereits eine enge Analyseausrichtung aufweisen. Eine typische Fragestellung im Rahmen von Analysen ist z. B.:

Multidimensionale Datenräume

Fakten

„Welcher Umsatz wurde im Juni 2010 in der Region Ost mit dem Produkt C220 bei dem Kundentyp Privatkunden erzielt?“ Wie die Analyseanforderung bereits deutlich macht, können verschiedene Aspekte mehrdimensionaler Datenräume differenziert werden. Sie werden im Weiteren als Fakten, Dimensionen und Hierarchisierungen bezeichnet. Fakten – auch Measures genannt – sind numerische Werte, die den Mittelpunkt der Datenanalyse bilden. Aus semantischer Sicht stellen Fakten betriebswirtschaftliche Kennzahlen dar. Diese haben generell die Aufgabe, relevante Zusammenhänge in verdichteter, quantitativ messbarer Form wiederzugeben (Horváth 2009, S. 504). Faktdaten repräsentieren in der Regel monetäre Werte oder Mengen wie etwa Umsatzerlöse, Umsatzmengen, Einzelkosten oder den Personalbestand.

Dimensionen

Dimensionen dagegen sind deskriptiver Natur. Sie ermöglichen unterschiedliche Sichten auf die Fakten. Nach ihnen können Faktdaten zur Auswertung gruppiert und analysiert werden. Gängige Dimensionsausprägungen auf der granularen Ebene sind beispielsweise Tage, Produkte oder Kunden.

Hierarchisierungen

Innerhalb einer Dimension können vertikale, hierarchische Beziehungen bestehen. Diese ermöglichen die Betrachtung unterschiedlicher Verdichtungsstufen der Faktdaten entlang eines Konsolidierungspfades. Beispielsweise kann die Dimensionsausprägung „Mitarbeiter“ hierarchisiert werden in „Filiale“, „Region“, „Land“ und „Gesamt“. Werden Elemente auf niedriger Verdichtungsstufe nach unterschiedlichen Konsolidierungspfaden aggregiert, entstehen parallele Hierarchien. Jeder Pfad stellt dann eine andere Sicht auf die Faktdaten dar. Die Abb. 2.28 zeigt anhand der Modellpalette

66

2.4 Modellierung multidimensionaler Datenräume eines Automobilherstellers innerhalb der Dimension Modelle zwei unterschiedliche Verdichtungswege über die Ebenen „Motoren“ sowie „Modellgruppen“.

Dimension Modelle Alle Modelle

1.6l

1.8l

2.0l

2.8l

3.0l

3er

316i

318i

Total

3.5l

4.0l

5.0l

Motoren

5er

320i

328i

520i

528i

530i

535i

540i

740i

7er

Modellgruppen

750i

Modelle

Abb. 2.28: Parallele Dimensionshierarchien (Hahne 1999, S. 150)

Star-Schemata

Zur Umsetzung des multidimensionalen Datenmodells finden proprietäre (herstellerspezifische) und relationale Datenhaltungssysteme Anwendung. In dem hier fokussierten relationalen Kontext werden unter dem Begriff Star-Schemata diverse logische Datenmodellierungsvarianten auf der Basis des Relationenmodells verstanden. Das einfache Star-Schema setzt sich aus einer Faktentabelle und mehreren Dimensionstabellen zusammen. Der Name leitet sich aus der sternförmigen Anordnung der Dimensionstabellen um die im Mittelpunkt stehende Faktentabelle ab.

Einfaches Star-Schema

Die Faktentabelle besitzt die informationstragenden Attribute – z. B. Umsätze, variable Kosten – und als Primärschlüssel einen zusammengesetzten Schlüssel aus den Primärschlüsseln der involvierten Dimensionstabellen. Auf einer semantischen Ebene repräsentieren die Dimensionstabellen demnach die Entitätstypen, während die Fakttabelle den komplexen Beziehungstyp der involvierten Entitätstypen darstellt. Abb. 2.29 zeigt ein entsprechendes ERM.

67

2 Datenbereitstellung und -modellierung m PRODUKT

n

UMSATZANALYSE

VERKÄUFER

p

o ZEIT

KUNDENTYP

Abb. 2.29: ERM einer Star-Modellierung Das entsprechende Star-Schema zeigt Abb. 2.30. Deutlich wird, dass die Dimensionstabellen die Hierarchieabbildung beinhalten. So verfügt die Dimensionstabelle „DT Verkäufer“ über Attribute zur Kennzeichnung des Navigationspfades über „Region“ und „Land“. DT Zeit

DT Produkt

KZeit

KProdukt

Monat Jahr

Produkt KProduktgruppe Produktgruppe FT Umsatzanalyse

DT Verkäufer KVerkäufer Name KRegion Region KLand Land

KZeit KVerkäufer KProdukt KKundentyp Umsatz Var.-Kosten

KKundentyp Kundentyp FT DT K

= Faktentabelle = Dimensionstabelle = Key

Abb. 2.30: Beispiel eines Star-Schemas

68

DT Kundentyp

2.4 Modellierung multidimensionaler Datenräume Aufgrund der Existenz funktionaler Abhängigkeiten zwischen Nicht-Schlüsselattributen wird in dieser Tabelle bewusst die 3NF verletzt. Um der 3NF zu genügen, müsste die Tabelle in drei einzelne Tabellen zerlegt werden, nämlich in die Tabellen „Verkäufer“, „Region“ und „Land“. Aus Gründen der Performance sieht man bei der Star-Modellierung jedoch von einer Normalisierung der Dimensionstabellen ab und akzeptiert die hierdurch auftretende Redundanz. Abfragen auf Granularitätsebene lassen sich mit Hilfe des StarSchemas komfortabel abbilden. Für Ad-hoc-Abfragen über Aggregate stehen verschiedene Möglichkeiten zur Verfügung. Im Rahmen der Abfrage des einleitenden Beispiels „Welcher Umsatz wurde im Juni 2010 in der Region Ost mit dem Produkt C220 bei dem Kundentyp Privatkunden erzielt?“ müsste für die „Region“ ein entsprechendes Aggregat über die Dimension „Verkäufer“ gebildet werden. FactConstellationSchema

Galaxien

Dieses Aggregat könnte während der Laufzeit (on the fly) berechnet werden oder aber bereits im Vorfeld ermittelt und abgelegt werden. Sind hierfür gesonderte Summationstabellen vorgesehen, so wird dieses Konzept mehrerer abhängiger, aggregierter Faktentabellen als Fact-Constellation-Schema bezeichnet. Normalerweise stehen in Data Marts mehrere Star-Schemata für unterschiedliche Analysezwecke zur Verfügung. Da sie teilweise auf strukturidentischen Dimensionstabellen basieren, ist die mehrfache Verwendung einzelner Dimensionstabellen aus Gründen der Konsistenz empfehlenswert. Diese Konzepte integrieren demnach mehrere Stars und werden aus diesen Gründen auch häufig als Galaxien bezeichnet. Das Star-Schema und seine Varianten zeichnen sich durch folgende Vorteile aus: • Einfache und daher intuitive Datenmodelle. • Geringe Anzahl von Join-Operationen. • Geringe Anzahl physischer Data-Warehouse-Tabellen. • Geringer Aufwand im Rahmen der Data-Warehouse-Wartung. Dem stehen auch Nachteile gegenüber: • Verschlechtertes Antwortzeitverhalten bei sehr großen Dimensionstabellen. • Redundanz innerhalb der Dimensionstabellen durch das mehrfache Festhalten identischer Fakten (Kurz 1999, S. 159 f.). 69

2 Datenbereitstellung und -modellierung

2.4.3

Keine konsequente Normalisierung

Snowflake-Schema Der Übergang von der Star-Modellierung zur SnowflakeModellierung ist fließend und die Diskussion hierüber ist unübersichtlich und kontrovers. Einigkeit besteht lediglich darüber, dass das Entwurfsmuster bei entsprechender Tabellenteilung optisch an eine Schneeflocke erinnern kann. Ob diese Tabellenteilung jedoch zu einer voll normalisierten Datenstruktur führen sollte, ist umstritten. In diesem Buch wird davon ausgegangen, dass das Ziel einer Snowflake-Modellierung nicht in der konsequenten Entwicklung voll normalisierter Dimensionstabellen bestehen kann. Vielmehr gilt es, ein performanceoptimiertes Datenmodell zu erzeugen, das vor dem Hintergrund eines realen Anwendungsfalles zu satisfizierenden Ergebnissen führt. Diese Zielsetzung ist demnach weit gefasst und lässt Raum für verschiedene Optimierungsansätze. • Hier sind zunächst einmal die bereits erwähnten Summationstabellen des Fact-Constellation-Schemas zu nennen. Diese sollten lediglich dann für häufig abgerufene Aggregationen gebildet werden, wenn sie sich aus vielen Detaildaten ermitteln und eine Berechnung on the fly aus Performancegründen nicht sinnvoll erscheint. • Eine vollständige Normalisierung von Dimensionstabellen zur Optimierung des Datenmodells ist lediglich dann zweckmäßig, wenn für jede Hierarchieebene entsprechende Summationstabellen auf der Faktenseite existieren. Andernfalls wäre die zur Laufzeit durchzuführende Aggregation lediglich mit Hilfe zeitintensiver Join-Operationen über die voll normalisierten Dimensionstabellen möglich. Da die Bildung von Summationstabellen – wie oben beschrieben – jedoch nur in bestimmten Fällen anzuraten ist, erscheint eine konsequente Normalisierung der Dimensionstabellen unangebracht. Vielmehr sollten sie bedarfsgerecht angepasst werden, so dass sie lediglich diejenigen Teile der Hierarchie beinhalten, für die keine Summationstabellen existieren. Da bei diesem Verfahren funktionale Abhängigkeiten zwischen Nicht-Schlüsselattributen der Dimensionstabellen weiterhin existieren können, werden die auf diese Weise entstehenden Dimensionstabellen im angelsächsischen Sprachraum auch als „slightly normalized dimensions“ bezeichnet. • Häufig verwendete Informationen – wie z. B. die Namen verantwortlicher Mitarbeiter der Filiale, der Region, des Landes – sollten in performanceoptimierten Datenmodellen bewusst re-

70

2.4 Modellierung multidimensionaler Datenräume dundant in der Dimensionstabelle geführt werden, um zeitaufwändige Join-Operationen zu den originären Tabellen – wie z. B. der Mitarbeitertabelle – zu umgehen. Neben diesen grundlegenden Prinzipien existieren noch andere Vorgehensweisen, um die Performance von Snowflake-Schemata zu erhöhen. Sie konzentrieren sich insbesondere auf weitere Teilungen der Dimensionstabellen aufgrund von Attributscharakteristika und der Partitionierung großer Fakttabellen auf der Basis typischer Abfragestrukturen.10 Ein Beispiel eines Snowflake-Schemas zeigt die Abb. 2.38 im Kapitel 2.4.5.

2.4.4

Konzepte der Historisierung Im Kontext der Datenhaltung werden verschiedene Ansätze der Sicherung zeitorientierter Datenausprägungen unterschieden, die Archivierung, das Backup und die Historisierung.

Archivierung

Zielsetzung der Archivierung ist es, Datenbereiche mit Hilfe von Sicherungskopien bei fachlichem Bedarf wiederherstellen zu können, z. B. bei Prüfungen, bei Rechtsstreitigkeiten oder anderen selten benötigten fachlichen Anwendungen.

Backup

Ein Backup bezeichnet die Sicherung von Datenbeständen auf speziellen Sicherungsmedien (i. d. R. Magnetbändern), um bei technischem Systemfehlverhalten Datenbereiche wiederherstellen zu können.

Historisierung

Unter Historisierung werden Konzepte verstanden, mit deren Hilfe Änderungen von Attributsausprägungen, Beziehungen und Entitäten im Zeitablauf dokumentiert werden können, um unterschiedliche fachliche Zustände auswertbar zu machen. Selbstverständlich kommen alle der o. a. Sicherungskonzepte im Bereich der dispositiven Datenhaltung zum Einsatz. So werden Altbestände, die nicht länger für Analysezwecke benötigt werden, archiviert und ausgelagert. Backup-Mechanismen werden eingesetzt, um im ODS, im Core Data Warehouse oder in den Data Marts Datenbestände bei technischen Fehlern – z. B. Magnetplattenfehlern – rekonstruieren zu können. Da Archivierung und Backup-Verfahren allgemeiner Natur sind und in allen betrieblichen Anwendungsbereichen eingesetzt werden, sollen sie hier nicht weiter thematisiert werden. Aus

10

Zur Vertiefung sei auf die einschlägige Fachliteratur verwiesen, z. B. Bauer/Günzel (Hrsg.) 2009 und Lehner 2003.

71

2 Datenbereitstellung und -modellierung analytischer Sicht kommt jedoch der Historisierung eine elementare Bedeutung zu, da sie – im Gegensatz zur Archivierung und zum Backup – den Möglichkeitsraum der Informationsrecherche determiniert. Die gängigsten Ansätze werden daher im Weiteren erläutert und diskutiert. Die Frage, ob in dispositiven Datenbeständen eine Nutzung komplexer Verfahren zur Historisierung überhaupt erforderlich ist, hat bei oberflächlicher Betrachtung durchaus Berechtigung. So stellen die meisten Datenbestände lediglich harmonisierte Datenreservoirs dar, die (periodisch) aus operativen/externen Quellen gefüllt werden und primär nur lesenden Zugriff erlauben. Laut Definition wird das bereits abgelegte Datenmaterial im C-DWH oder in Data Marts bei jeder Befüllung um die neuen Werte ergänzt, so dass die bereits integrierten Datenwerte im System verfügbar bleiben. Die Notwendigkeit der Anwendung weiter reichender Verfahren zur Historisierung ist somit nicht sofort erkennbar. Historisierung von Attributsausprägu ngen und Hierarchiestrukturen

Eine detaillierte Betrachtung der einzelnen Tabellenstrukturen verdeutlicht jedoch, dass die o. a. Aussagen lediglich für die Faktentabellen gelten. Dimensionstabellen können hingegen im Verlaufe der Zeit erheblichen Veränderungen unterliegen. Typische Änderungen treten auf im Bereich von Attributsausprägungen (z. B. die Adressenänderungen von Kunden) oder bei der Hierarchisierung von Dimensionen (z. B. Neugliederungen von Regionen oder Durchspielen von Plan-Szenarien). Da die Änderungsfrequenz von Dimensionstabellen im Gegensatz zu transaktionsorientierten Systemen jedoch gering ist, wird in diesem Zusammenhang im angelsächsischen Sprachgebrauch auch häufig treffend der Begriff „slowly changing dimensions“ verwendet. Gängige Vorgehensweisen zur Behandlung von Dimensionsänderungen sind das einfache Update-Verfahren sowie die Snapshot- und die Delta-Historisierung.

Update-Verfahren

72

Das Update-Verfahren stellt keine Historisierung dar. Die bestehenden Daten werden im Falle von Änderungen einfach überschrieben. Aus diesem Grunde ist das Verfahren lediglich für Attribute geeignet, bei denen ausschließlich die aktuelle Ausprägung für die Analysezwecke von Relevanz ist, z. B. interne Telefonnummern oder aktuelle Mitarbeiternamen. Vorteilhaft ist, dass das Verfahren einfach durchzuführen ist und nicht zu Datenwachstum in den Dimensionstabellen führt. Ein einfaches Update verdeutlicht beispielhaft die Abb. 2.31, aus der ersichtlich wird,

2.4 Modellierung multidimensionaler Datenräume dass sämtliche Analysen ausschließlich auf der aktuellen Attributsausprägung der Dimensionstabelle basieren. So ist in dem Beispiel erkennbar, dass die Abfrage nach dem Gesamtumsatz der Kundin „Schulz-Maier“ auch die Umsätze vor ihrer Adress- und Namensänderung einbezieht. Dimensionstabelle

1.

2.

3.

Kunde_ID 1 2 3 4

Kunde_Text Müller Meier Schulz Schmitz

Kunde_Strasse Parkstrasse Schlossallee Schillerstrasse Berliner

Kunde_Ort Köln München Berlin Hamburg

Geschl M W W M

Kunde_Tel 1234 4321 5678 8765

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08

Kunde_ID 1 2 3 3 4

Kunde_Text Müller Meier Schulz Schulz-Maier Schmitz

Kunde_Strasse Parkstrasse Schlossallee Schillerstrasse Schillerstrasse Berliner

Kunde_Ort Köln München Berlin Berlin Hamburg

Geschl M W W W M

Kunde_Tel 1234 4321 5678 5678 8765

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31JAN2010:23:05:04 31DEC2009:23:03:08

Kunde_ID 1 2 3 3 3 4

Kunde_Text Müller Meier Schulz Schulz-Maier Schulz-Maier Schmitz

Kunde_Strasse Parkstrasse Schlossallee Schillerstrasse Schillerstrasse Goethestrasse Berliner

Kunde_Ort Köln München Berlin Berlin München Hamburg

Geschl M W W W W M

Kunde_Tel 1234 4321 5678 5678 3333 8765

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31JAN2010:23:05:04 28FEB2010:23:01:03 31DEC2009:23:03:08

Abb. 2.31: Update-Verfahren Finger 2002) SnapshotHistorisierung

(modifiziert

übernommen

von

Das Snapshot-Verfahren ermöglicht eine vollständige Historisierung der Dimensionstabellen. Es führt jedoch zu einem großen Datenwachstum in den Dimensionstabellen, da bei jeder Aktualisierung der Dimensionstabellen nochmals sämtliche Datensätze – also die geänderten und die unverändert gebliebenen – an die existierende Tabelle angehängt werden. Zur eindeutigen Identifikation der einzelnen Tabellenzeilen erhält jeder Snapshot einen Zeitstempel, aus dem der Extraktionszeitpunkt deutlich wird. Abb. 2.32 verdeutlicht das Snapshot-Verfahren. Wie ersichtlich, erlaubt das Verfahren sowohl kumulierte Faktenabfragen über aktuelle Dimensionsausprägungen als auch zeitpunktbezogene Auswertungen des Datenbestandes, wobei in diesen Fällen über die identischen Ausprägungen der Zeitstempel in der Fakttabelle und in der Dimensionstabelle die Zuordnung realisiert wird.

73

2 Datenbereitstellung und -modellierung Dimensionstabelle

Welche Bestellmenge entfällt auf Schulz zu einem bestimmten Zeitpunkt ? Z. B. Dezember 2009

Kunde_ID 1 2 3 4 1 2 3 4 1 2 3 4

Welche Bestellmenge entfällt auf Schulz-Maier ?

Kunde_Text Müller Meier Schulz Schmitz Müller Meier Schulz-Maier Schmitz Müller Meier Schulz-Maier Schmitz

Kunde_ID 1 2 3 3 3 4

...

Bestell_ID 1111111 2222222 3333333 4444444 5555555 6666666

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31JAN2010:23:05:04 31JAN2010:23:05:04 31JAN2010:23:05:04 31JAN2010:23:05:04 28FEB2010:23:01:03 28FEB2010:23:01:03 28FEB2010:23:01:03 28FEB2010:23:01:03 ...

Bestellmenge 1 3 4 2 4 2

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31JAN2010:23:05:04 28FEB2010:23:01:03 31DEC2009:23:03:08

Fakten-Tabelle

Abb. 2.32: Snapshot-Verfahren (modifiziert übernommen von Finger 2002) Resümierend lässt sich festhalten, dass dieses Verfahren einfach und intuitiv zu handhaben ist, jedoch neben dem bereits o. a. Datenwachstum auch Performanceprobleme hervorrufen kann. Das ist vor allem darauf zurückzuführen, dass der Zeitstempel als Teil des zusammengesetzten Primärschlüssels bei allen Operationen eingebunden werden muss und bei Join-Operationen rechenintensive Aktionen zur Folge hat. Die Anwendung des Snapshot-Verfahrens ist daher lediglich dann zu empfehlen, wenn eine vollständige Historisierung aus Analysegründen erforderlich ist, Informationen über Veränderungen aus den operativen Datenbeständen jedoch nicht gewonnen werden können. DeltaHistorisierung

Können Änderungen in den operativen Daten gekennzeichnet werden, sind mit Hilfe dieser Informationen sog. DeltaHistorisierungsverfahren einsetzbar. Der Vorteil dieser Methoden liegt in der zeilengenauen Historisierung der Dimensionstabellen, die das Wachstum der Tabellen auf die geänderten Daten beschränkt. Im Weiteren sollen einige gängige Varianten dieser Historisierungsmethode vorgestellt werden, die Delta-Historisierung mit

74

2.4 Modellierung multidimensionaler Datenräume künstlicher Schlüsselerweiterung, eine sog. Current-Flag-Variante und die Historisierung mit Gültigkeitsfeldern.11 Dimensionstabelle Kunde_ID 1.01 2.01 3.01 3.02 3.03 4.01

Kunde_Text Müller Meier Schulz Schulz-Maier Schulz-Maier Schmitz

Welche Bestellmenge entfällt auf Schulz-Maier im Februar 2010?

Kunde_Strasse Parkstrasse Schlossallee Schillerstrasse Schillerstrasse Goethestrasse Berliner

Kunde_Ort Köln München Berlin Berlin München Hamburg

Geschl M W W W W M

Kunde_Tel 1234 4321 5678 5678 3333 8765

Curr 1 1 0 0 1 1

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31JAN2010:23:05:04 28FEB2010:23:01:03 31DEC2009:23:03:08

Fakten-Tabelle Kunde_ID 1.01 2.01 3.01 3.02 3.03 4.01

Bestell_ID 1111111 2222222 3333333 4444444 5555555 6666666

...

Bestellmenge 1 3 4 2 4 2

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31JAN2010:23:05:04 28FEB2010:23:01:03 31DEC2009:23:03:08

Abb. 2.33: Delta-Historisierung mit Schlüsselerweiterung und Current-Flag-Attribut (modifiziert übernommen von Finger 2002) Künstliche Schlüsselerweiterung

Bei Delta-Historisierungen mit künstlicher Schlüsselerweiterung erhält jeder Datensatz einer Dimensionstabelle einen zusätzlichen künstlichen Teilschlüssel, der auch in den Zeilen der Fakttabelle mitgeführt wird. Sobald eine Aktualisierung erforderlich ist, wird der künstliche Teilschlüssel um einen Zählerschritt inkrementiert und der neue Datensatz in der Dimensionstabelle eingefügt, wobei die Schlüsselerweiterung ab diesem Zeitpunkt auch für neue korrespondierende Zeilen in der Fakttabelle verwendet wird. Aufgrund der Schlüsselerweiterungen sind zeitgenaue historische Auswertungen möglich, da zeitlich zusammengehörige Daten in Fakt- und Dimensionstabellen dieselbe Schlüsselerweiterung besitzen.

Current-FlagVariante

Meist bedienen sich Analysen des aktuellsten Datenmaterials, so dass eine Optimierung für diese Kategorie von Abfragen sinnvoll erscheint. Die Integration eines Current Flags – z. B. mit der Ausprägung „1“ für „aktuell“ – erleichtert diese Art von Abfragen

11

Selbstverständlich sind diese Varianten auch als Erweiterung der Snapshot-Methode denkbar. Aufgrund der hohen Praxisrelevanz der Delta-Methode werden sie hier an diesem Verfahren verdeutlicht.

75

2 Datenbereitstellung und -modellierung erheblich, da die jeweils aktuellen Datensätze nicht länger über die Datumsfelder errechnet werden müssen. Die Abb. 2.33 verdeutlicht ein Beispiel der Delta-Historisierung mit künstlicher Schlüsselerweiterung und einem Current-Flag-Attribut. Die bisherigen Varianten der Historisierungen nutzen den Zeitstempel der Extraktion zur Bestimmung des Änderungszeitpunktes. In einigen Analysen kann diese Zeitbestimmung zu ungenau sein. So kann es beispielsweise erforderlich werden, die Änderungen in einer Dimension mit Kundendaten exakt – z. B. tagesgenau – zu erfassen. In diesen Fällen können ausschließlich Gültigkeitsfelder zu korrekten Ergebnissen führen. In Abb. 2.34 wird das bisher beschriebene Delta-Verfahren um diese ZeitAttribute erweitert. Dimensionstabelle

1.

2.

3.

Kunde_ID 1.01 2.01 3.01 4.01

Kunde_Text Müller Meier Schulz Schmitz

...

Kunde_Ort Köln München Berlin Hamburg

gueltig_von 31DEC2009 31DEC2009 31DEC2009 31DEC2009

gueltig_bis 31DEC9999 31DEC9999 31DEC9999 31DEC9999

Curr 1 1 1 1

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08

Kunde_ID 1.01 2.01 3.01 3.02 4.01

Kunde_Text Müller Meier Schulz Schulz-Maier Schmitz

...

Kunde_Ort Köln München Berlin Berlin Hamburg

gueltig_von 31DEC2009 31DEC2009 31DEC2009 15JAN2010 31DEC2009

gueltig_bis 31DEC9999 31DEC9999 14JAN2000 31DEC9999 31DEC9999

Curr 1 1 0 1 1

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31JAN2010:23:05:04 31DEC2009:23:03:08

Kunde_ID 1.01 2.01 3.01 3.02 3.03 4.01

Kunde_Text Müller Meier Schulz Schulz-Maier Schulz-Maier Schmitz

...

Kunde_Ort Köln München Berlin Berlin München Hamburg

gueltig_von 31DEC2009 31DEC2009 31DEC2009 15JAN2010 20FEB2010 31DEC2009

gueltig_bis 31DEC9999 31DEC9999 14JAN2010 19FEB2010 31DEC9999 31DEC9999

Curr 1 1 0 0 1 1

LOADTIME 31DEC2009:23:03:08 31DEC2009:23:03:08 31DEC2009:23:03:08 31JAN2010:23:05:04 28FEB2010:23:01:03 31DEC2009:23:03:08

Abb. 2.34: Delta-Historisierung mit Gültigkeitsfeldern (modifiziert übernommen von Finger 2002) Wie ersichtlich, werden zwei spezielle Zeitfelder mit Gültigkeitsangaben integriert, wobei sie nach jeder Aktualisierung der entsprechenden Zeile angepasst werden müssen. Änderungen in Dimensionsstrukturen

76

Neben der Historisierung von Attributsausprägungen, sind auch Veränderungen in den Dimensionsstrukturen zu dokumentieren und zu historisieren. Auch hier kommen Varianten der o. a. Verfahren zu Einsatz, wobei im Weiteren lediglich die DeltaHistorisierung mit Gültigkeitsfeldern kurz erläutert wird. Die Abb. 2.35 verdeutlicht die Thematik.

2.4 Modellierung multidimensionaler Datenräume Wie erkennbar wird, lassen sich hierarchische Zuordnungen durch Tabellenstrukturen abbilden. So wird hier am Beispiel einer Hierarchie-Tabelle mit unterschiedlichen Recherchetiefen – einer sog. unbalancierten Hierarchie – aufgezeigt, wie die Änderung über Gültigkeitsfelder dokumentiert und für die Zwecke alternativer Auswertungen verfügbar gemacht werden können.

Alt

1

1

2

O E_ID 1 2 3 4 5 6 7

OE _PAR 0 1 1 2 2 3 3

2

3 5

4

7

6

GUE LT_VON 01J AN1900 01J AN1900 01J AN1900 01J AN1900 01J AN1900 01J AN1900 01J AN1900

Neu

GUELT _BIS 31DEC 9999 31DEC 9999 31DEC 9999 31DEC 9999 31DEC 9999 31DEC 9999 31DEC 9999

5 OE_ID 1 2 3 4 5 6 7 4

6 OE_PAR 0 1 1 2 2 3 3 1

4

3

GUELT_VON 01JAN1900 01JAN1900 01JAN1900 01JAN1900 01JAN1900 01JAN1900 01JAN1900 01JAN2010

7 GUELT_BIS 31DEC9999 31DEC9999 31DEC9999 31DEC2009 31DEC9999 31DEC9999 31DEC9999 31DEC9999

Abb. 2.35: Historisierung unbalancierter Hierarchien (modifiziert übernommen von Finger 2002)

2.4.5

Fallbeispiel Auf der Basis einer Fallstudie sollen im Folgenden die Grundlagen der multidimensionalen Modellierung dispositiver Datenbestände noch einmal verdeutlicht werden.

Ausgangssituation Die WI-Computerhandelsgesellschaft mbH ist ein bundesweit agierendes PC-Handelshaus mit Hauptsitz in Köln, das sowohl Komplettangebote als auch einzelne Komponenten – wie Drucker, Monitore, Basiseinheiten und Zubehör – an gewerbliche Kunden verkauft. Der Leiter der Abteilung Marketing und Vertrieb ist mit der bisherigen IT-Unterstützung unzufrieden. Hauptsächlich bemängelt er • schlechte Performance der interaktiven Berichtssysteme,

77

2 Datenbereitstellung und -modellierung • unterschiedliche Kennzahlen und

Definitionen

bei

betriebswirtschaftlichen

• mangelnde Flexibilität bzgl. der Auswertungsdimensionen und Verdichtungsstufen bei Ad-hoc-Analysen. Anforderungen

Nach den Vorstellungen des Abteilungsleiters sollte das neue System diese Mängel beseitigen und primär aus zwei Modulen bestehen. • Modul Verkaufsanalyse: In diesem Teilsystem sind als unterste Detaillierungsebene die monatlichen Plan- und Ist-Werte für die Verkaufsmengen und Umsätze der einzelnen Produkte pro Filiale und Kundengruppe heranzuziehen. Aus Benutzersicht sind Aggregationsmöglichkeiten auf Jahreswerte, Produktgruppen, Verkaufsgebiete u. ä. vorzusehen. • Modul Deckungsbeitragsrechnung (DB): Bei der Deckungsbeitragsrechnung sollten die DB1 und DB2 als monatliche Deckungsbeiträge der Filialen analysiert werden können, wobei Aggregationen auf Regionenebene vorzusehen sind. In beiden Modulen sind Informationen über die jeweiligen organisatorischen Zuständigkeiten in die Analysen zu integrieren.

Rahmenbedingungen

Zur Erarbeitung einer Lösung wird ein Entity-Relationship-Modell der Vorsysteme zur Verfügung gestellt. Die Abb. 2.36 zeigt das ERM. Im Folgenden sind die Relationen mit beispielhafter Attributierung dargestellt, wobei sich die Relationen selbstverständlich auch leicht aus dem ERM ableiten lassen (vgl. Kapitel 2.4.1): KUNDE (KD#, Name, Adresse, ..., KGR#) KUNDENGRUPPE (KGR#, Bezeichnung, ..., PERS#) PERSONAL (PERS#, Name, Adresse, ...) ORGEINHEIT (ORG#, Bezeichnung, ..., REG#, PERS#) REGION (REG#, Bezeichnung, ..., PERS#) PRODUKT (PROD#, Bezeichnung, ..., PRODGR#) PRODGRUPPE (PRODGR#, Bezeichnung, ...) STRUKTUR (O.PROD#, U.PROD#, Menge) AUFTRAG (AUFTR#, +(KD#, TAGESDATUM), ORG#) AUFTRAGSPOS (AUFTR#, PROD#, Menge) FIXKOSTEN (ORG#, MON_DAT, Fix_Plan, Fix_Ist) VK-PLANUNG (PROD#, MON_DAT, KGR#, ORG#, PlanMenge) EK_VK (PROD#, MON_DAT, EK_Plan, EK_Ist, VK_Plan, VK_Ist)

78

2.4 Modellierung multidimensionaler Datenräume Eine erste Analyse des ERMs und des voll normalisierten Relationenmodells der Vorsysteme verdeutlicht, dass die VKPlanung (Verkaufsplanung) auf der Ebene der Kundengruppe, der Org.-Einheit (Filiale), des Produktes und der Zeit basiert, wobei die Zeit hier als Monat zu interpretieren ist. Sämtliche korrespondierenden IST-Werte werden – wie das ERM verdeutlicht – auf der Ebene der einzelnen Kundenaufträge gespeichert (Transaktionsebene) und müssen demnach für die Berichtszwecke jeweils on the fly auf das entsprechende Niveau des PlanWertes aggregiert werden. Es ist naheliegend, dass diese Lösung nicht zu einem satisfizierenden Antwortzeitverhalten führen kann.

Erste Bestandsaufnahme

EK_VK IST_PLAN

AUFTRAGSPOS.

KUNDE

n

AUFTRAG

1

n

n

PERSONAL

n

1

1

BETREUT VON

GEHÖRT ZU

n

n

BETREUT VON

m

VKPLANUNG

m

p

ORG. EINHEIT

BETREUT VON

PRODUKTGRUPPE

n

m

1

n

STRUKTUR

o

n

KUNDENGRUPPE

GEHÖRT ZU

FIX-K. IST_PLAN

ZUSTÄNDIG

n

ZEIT

1

PRODUKT

n

m

1

GEHÖRT ZU

m

n

n

m

1

REGION

Abb. 2.36: ERM der bisherigen Lösung

79

2 Datenbereitstellung und -modellierung Information Packages

Um eine Bestandsaufnahme der Anforderungen von Benutzerseite zu erleichtern, werden im Weiteren mit Hilfe von sog. Information Packages (Hammergren 1996) Informationen über Fakten, Dimensionen und Hierarchisierungen erhoben. Die Abb. 2.37 zeigt das entsprechende Information Package für das Modul Verkaufsanalyse. Ein Information Package ist ein (elektronisches) Formular, auf dem in der unteren Zeile die informationstragenden Fakten (Measures) eingetragen werden. In diesem Beispiel sind die Fakten um nützliche Informationen zu ihrer Berechnung ergänzt. So bedeutet (1), dass die entsprechenden Werte direkt – also ohne Aggregationen – aus den Vorsystemen übernommen werden können. Die (2) signalisiert, dass die Daten aus den Quellsystemen zunächst auf die erforderliche Granularität des Data Marts zu verdichten und teilweise weitere Berechnungen aus Daten der Quellsysteme durchzuführen sind. Die mit (3) gekennzeichneten Fakten werden ausschließlich durch einfache Berechnungen innerhalb der Fakttabelle selbst erzeugt, wie z. B. Abweichungen und ähnliche Kennzahlen. Dimensionen Hierarchisierungen

Alle Monate

Alle Produkte

Alle Kd.Gruppen

Alle Org.Einheiten

Jahr (3)

Pr.-Gruppe (5)

Kd.-Gruppe (6)

Region (4)

Quartal (12)

Produkt (25000)

Org.-Einheiten (25)

Monat (36)

Fakten:

PlanMenge (1), IstMenge (2), PlanUmsatz (2), IstUmsatz (2), Abw. abs. (3), ...

1 = übernehmen in FT 2 = Granularitätsanpassung und evtl. Berechnung für FT 3 = berechnet nur in der FT aus Feldern der FT

Abb. 2.37: Information Package für die Verkaufsanalyse Die Spalten des Formulars definieren die Dimensionen des multidimensionalen Datenraumes. Aus Gründen der Übersichtlichkeit empfiehlt es sich, die Dimensionsnamen aus den Attributsbezeichnungen der jeweils geringsten Granularitätsstufe der entsprechenden Dimension abzuleiten. Die Hierarchien werden anschließend spezifiziert, wobei durch Angaben zu möglichen Ausprägungen wertvolle Hinweise zur 80

2.4 Modellierung multidimensionaler Datenräume Optimierung der physischen Umsetzung des multidimensionalen Datenraumes gemacht werden können. So ergibt z. B. die Multiplikation der Ausprägungen auf der Granularitätsebene die maximal mögliche Anzahl von Zeilen in der Fakttabelle und erlaubt so eine Einschätzung, ob Tabellenteilungen (Partitionierungen) erforderlich sind. Auch geben die Mengenangaben erste Hinweise darauf, ob bei relationaler Umsetzung des Datenraumes Summationstabellen integriert werden sollten. In dem hier dargestellten Beispiel könnte eine solche Tabelle für die Produktdimension erforderlich werden, da in diesem Fall 25.000 Produkte zu 5 Produktgruppen zusammengefasst werden und somit bei ProduktgruppenAnalysen jeweils mehrere Tausend Datensätze aggregiert werden müssten. Snowflake Schema

Abb. 2.38 zeigt das aus diesen Vorüberlegungen entwickelte Snowflake-Schema. FT-Verk.-An.(Main) Monat# Monat/Jahr

O.Produkt# U.Produkt#

Produkt#

Menge

Produkt Produktgruppe# Produktgruppe

Monat# Produkt# Kundengruppe# Org.-Einh.# PlanMenge IstMenge PlanUmsatz IstUmsatz Abw abs. = ...

(1) (2) (2) (2) (3)

FT-DB Monat# Org.-Einh.# Fix_Plan Fix_Ist PlanUmsatz IstUmsatz VarPlanKosten VarIstKosten DB1_Plan = DB1_Ist = DB2_Plan= DB2_Ist =

Org.-Einh# (1) (1) (2) (2) (2) (2) (3) (3) (3) (3)

Org.-Bezeichnung Pers#.Org Nachname Region# Reg.-Bezeichnung (Pers#.Reg) (Nachname)

FT-Verk.-An. (Agg.) Produktgruppe# Produktgruppe

Kundengruppe# Kundengruppe Pers# Nachname

1 = übernehmen in FT 2 = Granularitätsanpassung und evtl. Berechnung für FT 3 = berechnet nur in der FT aus Feldern der FT

Monat# Produktgruppe# Kundengruppe# Org.-Einh.# PlanMenge IstMenge PlanUmsatz IstUmsatz Abw abs. = ...

(2) (2) (2) (2) (3)

Pers# Titel Vorname Nachname Position E-Mail Telefon

Abb. 2.38: Snowflake-Schema für Verkaufsanalyse und DB-Rechnung

81

2 Datenbereitstellung und -modellierung Modul Verkaufsanalyse

Wie deutlich wird, existieren für das Modul Verkaufanalyse eine originäre Faktentabelle (FT-Verk.-An. (Main)) mit den Granularwerten und eine weitere abgeleitete Faktentabelle (FTVerk.-An. (Agg.)) mit aggregierten Werten, die bereits auf der Ebene der Produktgruppe vorgehalten werden.

Modul Deckungsbeitragsrechnung

Das Modul Deckungsbeitragrechnung besitzt aufgrund des geringen Datenvolumens keine Summationstabellen und basiert somit lediglich auf einer Faktentabelle.

Dimensionstabellen

Die Mehrzahl der Dimensionstabellen beinhalten funktionale Abhängigkeiten zwischen Nicht-Schlüsselattributen und sind somit nicht normalisiert. Lediglich die Dimensionstabelle Monat und die optionale (in der Abbildung geklammert darstellte) Dimensionstabelle der Produktgruppe entspricht der 3NF. Alle weiteren Tabellen besitzen funktional abhängige Hierarchieinformationen oder Attribute mit redundanten Ausprägungen zur performanten Einbindung der Namen aus der Personentabelle. Sicherlich stellt die Lösung dieser Fallstudie lediglich eine einfache Variante dar, um die Performance der hier skizzierten analytischen Informationssysteme zu erhöhen. Jedoch wird bereits auf der Basis dieses kleinen Beispiels deutlich, dass eine Vielzahl von Möglichkeiten existiert, um dispositive multidimensionale Datenräume im relationalen Kontext zu optimieren.

2.5

Zusammenfassung Die dispositive Datenhaltung in integrierten BI-Ansätzen besteht aus Operational Data Stores und Data Warehouses. Operational Data Stores sind transaktionsorientierte Datenpools, die sich durch Themenorientierung, Integration, Zeitpunktbezug, Volatilität und einen hohen Detaillierungsgrad auszeichnen. Data Warehouses bestehen im Allgemeinen aus einem Core Data Warehouse und darauf aufsetzenden Data Marts. Sie lassen sich durch Themenorientierung, Integration, Zeitraumbezug und dauerhafte Speicherung charakterisieren. Um aus operativen Daten betriebswirtschaftlich sinnvoll interpretierbare Informationen ableiten zu können, ist ein Transformationsprozess erforderlich. In diesem Zusammenhang werden Filterungs-, Harmonisierungs-, Aggregations- und Anreicherungsprozesse unterschieden. Die Zugriffsberechtigungen sind ein integraler Bestandteil der dispositiven Datenhaltung, wobei mit Hilfe rollenbasierter Zu-

82

2.5 Zusammenfassung griffskontrollen adäquate Berechtigungskonzepte umgesetzt werden. Zur Dokumentation sämtlicher Prozesse in der dispositiven Datenhaltung und zur Steuerung der Benutzerzugriffe werden technische und betriebswirtschaftliche Metadaten erzeugt. Sie lassen sich in passive oder (semi-)aktive Metadaten differenzieren, wobei zwischen zentralen, dezentralen und föderierten Metadatenverwaltungen unterschieden werden kann. Zur Pflege der Prozesse sind für die dispositive Datenhaltung technische und fachliche Administrationsschnittstellen vorgesehen, mit deren Hilfe Mitarbeiter den gesamten Transformationsprozess und die Berechtigungsstrukturen anlegen, verändern oder löschen können. Die Modellierung dispositiver Daten erfolgt im relationalen Kontext mittels Star- und Snowflake-Modellierungsvarianten, die eine performanceoptimierte Modellierung multidimensionaler Datenräume erlauben. Um Auswertungen über längere Zeiträume zu gewährleisten, ist in vielen Fällen die Dokumentation von strukturellen und inhaltlichen Veränderungen in der Datenhaltung erforderlich. Für diese Zwecke existieren Historisierungskonzepte, wie das Snapshotund das Delta-Verfahren.

83

3

Informationsgenerierung, -speicherung, -distribution und -zugriff Während bei der Datenbereitstellung die Transformation und Speicherung der Daten im Vordergrund stehen, beschäftigt sich das folgende Kapitel mit ihrer anschließenden spezifischen Aufbereitung, Nutzung und Verteilung. Hierbei werden zunächst Analysesysteme erläutert, mit denen die Daten in ihre endgültige Darstellungsform überführt werden. Im Anschluss werden Konzepte und Werkzeuge diskutiert, die eine systematische Speicherung und Distribution von BI-Inhalten unterstützen, um so deren Wiederverwendung zu fördern. Das Kapitel schließt mit der Vorstellung von Portalen, die eine Zusammenführung der Inhalte auf der Zugriffsebene ermöglichen.

3.1

Informationsgenerierung: Analysesysteme Unter Analyse, aus dem Griechischen „analysis“ für „Auflösung“, wird die systematische „Untersuchung eines Sachverhalts unter Berücksichtigung seiner Teilaspekte“ verstanden (Zwahr 2006, S. 238 f.). 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 verwendungsspezifische Bedeutungen, die ihre Interpretation als Informationen ermöglichen.

3.1.1

Konventionelle Klassifizierungen In konventionellen Klassifizierungen werden Informationssysteme des Managements aus historischen Gründen oft direkt den Benutzerklassen des Top, Middle und Lower Management zugeordnet und auf hoher Abstraktionsebene in modellorientierte und berichtsorientierte Analysesysteme unterschieden.

Modellorientierte Analysesysteme

Modellorientierte Analysesysteme basieren auf algorithmischen Strukturen (Ottmann/Widmayer 2002, S. 1). Ihnen liegt somit ein Formelwerk zugrunde, das eine anwendungsspezifische Weiterverarbeitung und Präsentation der Daten ermöglicht. Verwendung finden häufig Modelle und Methoden der Forschungsberei85

3 Informationsgenerierung, -speicherung, -distribution und -zugriff che des Operations Research und der Künstlichen Intelligenz, wobei in betriebswirtschaftlichen Anwendungsgebieten insbesondere auch Verfahren der deskriptiven Statistik und der Finanzmathematik zum Einsatz kommen (z. B. Domschke/Drexl 2007). Es ist in der Praxis nicht selten, dass erfahrene Mitarbeiter in den Fachabteilungen modellorientierte Systeme selbstverantwortlich entwickeln und einsetzen. Daher gehört dieser Bereich häufig zum Komplex des End User Computing (Personal Computing, Individuelle Datenverarbeitung – IDV), bei dem der Endbenutzer fundierte IT-Kenntnisse sowie Wissen über die methodischen und die fachlich-inhaltlichen Dimensionen der zu erstellenden Lösung besitzen muss. Berichtsorientierte Berichtsorientierte Systeme unterstützen hingegen primär die Informationsrecherche und -darstellung in Form aufbereiteter Systeme Datensichten. Sie stellen somit ein Komplement zu den modellorientierten Systemen dar. In ihrer einfachsten Form als starres Berichtswesen erfordern sie vom Benutzer primär die Fähigkeit, die Systeme bedienen und die dargestellten Inhalte sachgerecht interpretieren zu können. Mittlerweile wurde diese Kategorie von Analysesystemen funktional erweitert. So erlauben berichtsorientierte Systeme heute häufig die benutzerseitige Einbindung von einfachen mathematischen Formeln (z. B. Spalten-/Zeilensummierungen), ermöglichen individuelle Berichtsextraktionen bzw. -erweiterungen und bieten interaktive Navigationsmechanismen für Ad-hoc-Berichte. Ein Mindestmaß an IT-Fähigkeiten ist daher heute auch bei der Benutzung dieser Kategorie von Analysesystemen erforderlich. Pyramidendarstellung

In der älteren Literatur findet sich oft eine Pyramidendarstellung der Systeme mit einer entsprechenden Zuordnung der Benutzergruppen (vgl. Abb. 3.1). Ohne Frage stellt diese didaktische Vereinfachung des Sachverhaltes eine erste Möglichkeit dar, sich mit der Thematik der Analysesysteme auseinanderzusetzen. So verdeutlicht sie die Einsatzschwerpunkte und den Charakter der einzelnen Systemklassen und spiegelt – wenn auch stark vereinfacht – durchaus die Realität der IT-basierten Managementunterstützung bis weit in die 90er Jahre wider. Für eine Einordnung moderner BI-Konzepte eignet sich eine einfache pyramidale Darstellung jedoch nicht mehr. Sie ist eher irreführend und birgt die Gefahr von Fehlinterpretationen.

86

3.1 Informationsgenerierung: Analysesysteme

Top Management

Executive Information Systems

Berichtsorientierung

OLAP Middle Management

Lower Management

Abb. 3.1:

Decision Support Systems Expert Systems Data Mining Management Information Systems

Modellorientierung

Berichtsorientierung

Traditionelle Abgrenzung der dispositiven Systeme (Kemper 1999, S. 233)

Kritikpunkte sind insbesondere: • Die Aufteilung der Anwendungssysteme deutet eine Differenzierung in abgrenzbare Systemklassen an, die sich in der Praxis in dieser Form nicht wiederfindet. • Es wird angenommen, dass die einzelnen Systemklassen sich eindeutig den Managementebenen zuordnen lassen. Auch dieses Phänomen ist überholt und gilt für moderne Analysesysteme nicht länger. • Die Abbildung suggeriert eine hierarchische Abhängigkeit der Systeme, die datenseitig in früheren Lösungen durchaus bestand (vgl. Kapitel 2.1). In modernen BI-Konzepten existieren jedoch eigenständige harmonisierte Datenhaltungssysteme für den gesamten dispositiven Bereich, so dass datenseitige Abhängigkeiten nicht mehr gegeben sind.

3.1.2

BI-Analysesysteme — Ordnungsschema Da die traditionelle pyramidale Darstellung als Rahmenkonzept für moderne BI-Anwendungen nicht mehr genügen kann, existieren in der Wissenschaft und vor allem in der Praxis Unsicherheiten, wie der gesamte Bereich adäquat zu strukturieren ist. Abb. 3.2 gibt einen Eindruck über gebräuchliche Einordnungen.

87

3 Informationsgenerierung, -speicherung, -distribution und -zugriff

Anwendungsgebiete

BI-Anwendungssysteme

ƒ Customer Relationship Management ƒ Supply Chain Management ƒ Risiko-Management ƒ Competitive Intelligence ƒ Stakeholder-Einbindung ƒ…

ƒ Churn-Analyse ƒ Kundensegmentierung ƒ Kundenwertanalysen ƒ Web-Controlling ƒ Benchmarking ƒ Lieferantenbewertungssystem ƒ…

Î

Organisatorische Einheiten

BI-Anwendungssysteme

ƒ Unternehmensführung ƒ Controlling ƒ Marketing ƒ Vertrieb ƒ Personal ƒ…

ƒ ISTM (IS Top Management) ƒ MIS (Marketing IS) ƒ VIS (Vertriebs IS) ƒ EIS (Einkäufer IS) ƒ…

Abb. 3.2:

Î

Beispiele für BI-Analysesysteme

Deutlich wird, dass BI-Analysesysteme sowohl über Anwendungsgebiete als auch über die BI-Lösungen einsetzenden organisatorischen Einheiten charakterisiert werden. Anwendungsgebiete und die entsprechenden BI-Systeme

So wird beispielsweise Customer Relationship Management nicht selten als ein Einsatzgebiet für BI-Lösungen identifiziert. In der Tat lassen sich viele BI-Anwendungen in diesem Kontext finden, wie z. B. die • Churn-Analyse (Change and Turn) Die Ermittlung von (guten) Kunden, bei denen aufgrund von Datenkonstellationen – z. B. bei der Produktnutzung, Anrufverhalten bei Call-Center-Kontakten u. ä. – mit einer hohen Wahrscheinlichkeit von einer bevorstehenden Kündigung auszugehen ist. Auf der Basis der BI-Analyse können dann nachfolgend operative Maßnahmen eingeleitet werden, um die Kundenzufriedenheit dieser kritischen Gruppe zu erhöhen und eine Abwanderung zu verhindern. • Kundensegmentierung Die Einteilung von Kunden nach speziellen Kriterien, z. B. die Durchführung einer Clusteranalyse auf der Basis von Umsatzzahlen, um eine nachgelagerte Werbeaktion zielorientiert auf die profitablen Kunden auszurichten. Die Liste mit Beispielen könnte ohne weiteres fortgeführt und auch für andere Anwendungsbereiche wie Supply Chain Mana-

88

3.1 Informationsgenerierung: Analysesysteme gement, Risiko-Management u. ä. erweitert werden. Jedoch muss bemängelt werden, dass diese Einordnung nicht schlüssig ist und lediglich auf einer deskriptiven Ebene die im praktischen Umfeld vorkommenden Systeme einer Anwendungsdomäne aufzählt. Irritationen sind somit unausweichlich, zumal alle Anwendungsdomänen auch andere Anwendungssysteme umfassen. So gehören zum Customer Relationship Management (CRM) neben dem analytischen CRM auch das weite Feld des operativen CRM (Hippner et al. 2006, S. 48 ff.), das jedoch nicht dem BusinessIntelligence-Kontext zuzurechnen ist. Das operative CRM befasst sich z. B. mit der Durchführung/Optimierung von Kampagnen und der Koordination der verschiedenen Vertriebskanäle und Kundenkontaktpunkte. Organisatorische Einheiten und die entsprechenden BI-Systeme

Auch das gerade in der Praxis dominierende Prinzip, Systeme aufgrund organisatorischer Zuständigkeit zu differenzieren, ist wenig hilfreich. Zwar ist das Vorgehen sehr verständlich, da die organisatorische Einheit in aller Regel Auftraggeber des jeweiligen Systems ist und somit in exponierter Rolle als späterer Anwender im Mittelpunkt der Systementwicklung steht. Allerdings sind die Bezeichnungen lediglich innerhalb des Unternehmens sinnvoll interpretierbar und führen außerhalb der Organisationsgrenzen nicht selten zu Irritationen. Informationssysteme im Marketing als MIS zu bezeichnen oder EinkäuferInformationssysteme mit dem Akronym EIS zu betiteln, ist daher unglücklich und führt außerhalb der Organisation zu Fehlinterpretationen der Systemcharakteristika. Für die weitere Detaillierung der Informationsgenerierung wird daher bewusst auf eine Kategorisierung nach Anwendungsgebieten und organisatorischen Einheiten verzichtet. Die Analysesysteme werden vielmehr aufgrund ihrer funktionalen Ausrichtung in generische Basissysteme und konzeptorientierte Systeme unterteilt. Als Grundlage der Umsetzung dienen die möglichen Ausprägungen, die als verschiedene Implementierungsansätze diskutiert werden. Die Abb. 3.3 zeigt die entsprechende Aufteilung.

Generische Basissysteme

Unter den generischen Basissystemen werden BI-Systeme zusammengefasst, die als eigenständige Komponenten in einem umfassenden BI-Anwendungssystem integriert werden können. Unterschieden werden hierbei freie Datenrecherchen, OLAPSysteme, Berichtssysteme und modellgestützte Analysesysteme.

Konzeptorientierte In Abgrenzung hierzu beziehen sich konzeptorientierte Systeme auf konkrete Managementprozesse, indem sie bestimmte beSysteme triebswirtschaftliche Konzepte abbilden. Hierunter fallen bei89

3 Informationsgenerierung, -speicherung, -distribution und -zugriff spielsweise die Balanced Scorecard, die Planung, die Konsolidierung oder das Wertorientierte Management. Implementierungsansätze

Die Anbindung der generischen Basissysteme und der konzeptorientierten Systeme an die Datenbereitstellung kann in verschiedenen Ausprägungen realisiert werden. Als entsprechende Implementierungsansätze werden hierbei das klassische Data Warehousing, Closed-loop Data Warehousing, Active Data Warehousing und Real-time Data Warehousing unterschieden. Implementierungsansätze y Klassisches Data Warehousing y Closed-loop Data Warehousing

y Real-time Data Warehousing y Active Data Warehousing

Konzeptorientierte Systeme y Balanced Scorecard y Planung und Budgetierung

y Konsolidierung y Wertorientiertes Management

Generische Basissysteme Berichtssysteme

Modellgestützte Analysesysteme

y Interaktive Reporting-Plattformen y Generierte Berichte (MIS, EIS)

y Decision Support Systems y Expert Systems y Data/Text/Web/Process Mining

Freie Datenrecherchen

OLAP-Systeme

y SQL:2003 y MDX

y Freie OLAP-Analysen y Geführte OLAP-Analysen

Abb. 3.3:

Analysesysteme für das Management

3.1.3

DWH-Implementierungsansätze

Frühe DWHs

Die frühen Data Warehouses der 90er Jahre waren nahezu ausschließlich Systeme, die in planerischen Bereichen – häufig im Controlling – eingesetzt wurden. Ein Data Warehouse sollte daher nach den Definitionsansätzen des Protagonisten William H. Inmon ausschließlich zeitraumbezogene Daten beinhalten, wobei die Mehrzahl der DWHs in Anlehnung an das Standardberichtswesen monatsaktuelle Daten umfassten (vgl. ausführlich in Kapitel 2.2.1).

Neuere Ansätze

Daneben werden DWHs jedoch im Rahmen der geschäftsprozessorientierten „operational BI“ (vgl. Kapitel 2.3.3) heute auch zur Unterstützung von Entscheidungen in taktisch und operativ ausgerichteten Anwendungsfeldern eingesetzt. Häufig werden in diesen Gebieten andere Anforderungen an die Datenhaltung gestellt, da bereits einzelne Transaktionen Auswirkungen auf

90

3.1 Informationsgenerierung: Analysesysteme Entscheidungen ausüben können. Die Zeitspanne von der Datengenerierung bis zur Maßnahmenumsetzung kann in diesen Fällen durchaus als kritische Größe betrachtet werden, deren Verkürzung einen positiven Effekt auf die Zielerreichung des Unternehmens besitzen kann. Wertverlust einer Information

Der Kurvenverlauf in Abb. 3.4 zeigt beispielhaft den Wertverlust einer Information über eine Abfolge von Verarbeitungsschritten in BI-Anwendungssystemen. Die Darstellung setzt eine Situation voraus, bei der es betriebswirtschaftlich sinnvoll ist, möglichst unmittelbar im Anschluss an die operative Transaktion zu handeln, beispielsweise bei der Entgegennahme einer Kundenbeschwerde oder einer Störungsmeldung. Die Abbildung ist somit lediglich als allgemeines Muster zu interpretieren, da die Latenzzeitrelevanz und die relativen Anteile der jeweiligen Latenzzeiten je nach Anwendungsfall stark variieren können.

Wert

operative Transaktion

Wertverlust

Daten im DWH verfügbar

Analyseergebnisse verfügbar Entscheidung getroffen Maßnahme umgesetzt

Datenlatenz

Analyselatenz

Entscheidungslatenz

Aktionszeit

Abb. 3.4: Aktionszeit

Umsetzungslatenz

Zeit

Latenzzeiten von BI-Systemen (modifiziert übernommen aus Hackathorn 2002, S. 24)

Ein wesentlicher Faktor für die konkrete Ausgestaltung des BISystems ist die geforderte Aktionszeit, die als der Zeitraum zwischen der Erfassung eines Geschäftsvorfalls in den operativen Systemen und einer daraus resultierenden Maßnahme definiert ist. Die Aktionszeit setzt sich aus vier zeitlichen Verzögerungen zusammen (in Anlehnung an Hackathorn 2002, S. 24):

91

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Datenlatenz

Nachdem ein Geschäftsvorfall in den operativen Systemen dokumentiert wurde, werden die Transaktionsdaten in die dispositiven Systeme überführt. Die Datenlatenz beschreibt die Zeitspanne, die vergeht, bis die Daten gefiltert, harmonisiert, aggregiert und ggf. angereichert im Data Warehouse zur Verfügung stehen (vgl. auch Kapitel 2.3.1).

Analyselatenz

Nachdem die Daten bereitgestellt sind, können diese in den Analysesystemen manuell oder automatisch in den benötigten Kontext gestellt, grafisch aufbereitet und dem Adressaten zur Verfügung gestellt werden. Der hierfür benötigte Zeitraum ist die Analyselatenz.

Entscheidungslatenz

Der Anwender kann nun diese Informationen aufnehmen und bei Bedarf eine Entscheidung treffen. Die hierbei entstehende Entscheidungslatenz ist häufig eine der umfangreichsten Verzögerungen. Das BI-Anwendungssystem kann diese Zeitdauer nur indirekt durch die Qualität der entscheidungsrelevanten Inhalte und deren Aufbereitung beeinflussen.

Umsetzungslatenz Auf der Basis der gefällten Entscheidung und der dahinter liegenden Erkenntnisse können nun konkrete Maßnahmen ergriffen werden. Die Dauer bis zu der tatsächlichen Implementierung, beispielsweise in Form einer Änderung in den operativen Systemen, ist die Umsetzungslatenz. Data Warehousing

Anwendungen mit höheren Anforderungen an die Reaktionszeit haben zur Entwicklung verschiedener Implementierungsansätze für BI-Anwendungssysteme geführt. Diese Konzepte werden hier als Data-Warehousing-Ansätze bezeichnet, da sie die prozessuale Sicht der Beschaffung, der Speicherung und der Analyse der Daten für spezifische Anwendungsgebiete beschreiben. Im Weiteren werden vier mögliche Implementierungsvarianten unterschieden: Das klassische Data Warehousing, das Closed-loop Data Warehousing, das Real-time Data Warehousing sowie das Active Data Warehousing.

Klassisches Data Warehousing Beim klassischen Data Warehousing werden die Daten in periodischen Abständen gebündelt transformiert. Je nach Anforderung werden diese beispielsweise täglich, wöchentlich oder monatlich in einem festen Zeitfenster durch eine ETL-Stapelverarbeitung in die dispositive Datenhaltung übernommen. Die Analysesysteme greifen nur lesend auf diesen Datenbestand zu. Auf diese Weise ist eine hohe Datenkonsistenz sichergestellt, 92

3.1 Informationsgenerierung: Analysesysteme da bestehende Daten mit Hilfe von ETL-Prozessen lediglich komplettiert werden und Änderungen sich primär auf die Dimensionstabellen beschränken (vgl. Kapitel 2.4.4). Anwendungsbeispiele hierfür sind Planungs- und Kontrollinstrumente mit kurz- bis mittelfristigem Entscheidungshorizont (Ex-postAnalysen). Der klassische Ansatz beinhaltet noch keine speziellen Optimierungen bezüglich der Aktionszeit und dient somit als Referenz für eine Verkürzung der Latenzzeiten.

Closed-loop Data Warehousing Der Grundgedanke des Closed-loop-Ansatzes ist die Rückkopplung von Analyseergebnissen in operative und/oder dispositive Systeme. Durch die zusätzlichen Informationen werden die Datenbestände inhaltlich ergänzt und können somit auch andere Entscheidungsprozesse wirksam unterstützen. Anwendungsbeispiel CRM

Der Closed-loop-Ansatz wird vor allem im Anwendungsgebiet des Customer Relationship Managements umgesetzt, wodurch das analytische und das operative CRM miteinander verbunden werden. Letzteres umfasst alle „Anwendungen, die im direkten Kontakt mit dem Kunden stehen“ (Hettich et al. 2000, S. 1348). Um beispielsweise Cross- oder Up-Selling-Potenziale bei einem Kundenkontakt direkt aufzeigen zu können, werden die Ergebnisse einer Kundensegmentierung nach Interessengebieten in das operative CRM-System eingebunden. Auf dieser Grundlage kann das System dann konkrete Produktempfehlungen vornehmen.

Verringerung der Der Closed-loop-Ansatz verringert vor allem die UmsetzungslaUmsetzungslatenz tenz, da die Ergebnisse strukturiert und ggf. automatisiert in die Zielsysteme zurück geschrieben werden. Eine manuelle Anpassung der Datenbankstrukturen – z. B. durch Export- und Import von strukturierten Textdateien – wird dadurch vermieden.

Real-time Data Warehousing Im Real-time Data Warehousing wird der batchorientierte, periodische ETL-Prozess teilweise oder ganz durch eine Integration von operativen Transaktionsdaten in Echtzeit ersetzt. Der Begriff der Echtzeit (Real-time) ist dabei definiert als eine vernachlässigbar geringe Latenzzeit zwischen dem Anfallen der operativen Daten und deren Verfügbarkeit im Data Warehouse. Je nach Anwendungsfall kann dies im Bereich der Millisekunden oder Sekunden liegen.

93

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Die zeitnahe Verfügbarkeit der Daten im Data Warehouse kann über mehrere Mechanismen gewährleistet werden, wobei ein einfaches Kopieren der Daten zwischen operativen und dispositiven Systemen meist jedoch nicht ausreichend ist. So sind zur Sicherstellung der inhaltlichen Konsistenz des Real-time Data Warehouse in aller Regel Transformationsprozesse erforderlich (vgl. Kapitel 2.3.1). Nicht selten werden hierfür vorgeschaltete ODS (vgl. Kapitel 2.3.3) oder dedizierte EAI-Infrastrukturen verwendet, welche die technische und fachliche Transformation der Daten operativer Quellsysteme ermöglichen (Ruh et al. 2001; Linthicum 2001; Kaib 2002; Brobst 2002). Anwendungsbeispiel Wertpapierhandel

Ein klassisches Beispiel für die Anwendung von Real-time Data Warehousing ist der Bereich des Wertpapierhandels, bei dem die sofortige Verfügbarkeit von entscheidungsrelevanten Informationen zwingend erforderlich ist. Indizes von Aktien und festverzinslichen Papieren, Währungskurse sowie zusätzliche Informationen müssen möglichst schnell integriert und dem Endbenutzer zur Verfügung gestellt werden.

Verringerung der Datenlatenz

Das Ziel des Real-time Data Warehousing ist die Verringerung der Datenlatenz. Durch die selektive Ablösung der batchorientierten ETL-Prozesse stehen zeitkritische operative Daten schneller für Analysen zur Verfügung.

Active Data Warehousing Die Grundidee des Active Data Warehousing ist eine Nutzung des Data Warehouse in operativen Prozessen und somit eine stärkere Unterstützung des Lower Management (Akbay 2006; Schrefl/Thalhammer 2000, S. 34 ff.). Da operative Entscheidungssituationen in der Regel besser strukturiert sind als ihre strategischen Pendants, können in diesem Anwendungsszenario bestimmte Aktionen (teil-)automatisiert durchgeführt werden. Im Idealfall lassen sich somit wiederkehrende Entscheidungsaufgaben automatisch lösen. Event-ConditionAction-Modell

Zur Beschreibung dieses Sachverhalts dient das Event-ConditionAction-Modell (ECA model), das bereits seit längerem in aktiven Datenbanken in Form von Auslösern (trigger) umgesetzt wird (Elmasri/Navathe 2007, S. 825; Schrefl/Thalhammer 2000, S. 34). Eine Regel besteht hierbei aus drei Komponenten:

Ereignis

94

1.

Startpunkte des Prozesses sind Ereignisse (events). Beispiele hierfür sind die Verfügbarkeit neuer operativer Daten oder das Über- oder Unterschreiten von Schwellenwerten.

3.1 Informationsgenerierung: Analysesysteme Bedingung

2.

Anschließend erfolgen Prüfungen, ob bestimmte Bedingungen (conditions) gelten. Sind die Bedingungen nicht erfüllt, wird die Ausführung der Regel an dieser Stelle abgebrochen.

Aktion

3.

Sind die Bedingungen wahr, so werden die hierfür bestimmten Aktionen (actions) ausgeführt. Mögliche Aktionen sind die Durchführung von Transaktionen (intern in der dispositiven Datenhaltung oder extern in anderen Datenbanken) oder der Aufruf von externen Programmen.

Zur konkreten Umsetzung klassischer ECA-Regeln sind für multidimensionale Analyseregeln weitere Details zu bestimmen (Thalhammer et al. 2001, S. 248): • Die primäre Ebene der Dimensionshierarchie, auf die sich die Regel bezieht. • Die multidimensionalen Datenräume (Cubes), die für die Analyse verwendet werden. • Die Entscheidungsschritte, in Form von Wenn-dann-Regeln, die den Entscheidungsprozess beschreiben. • Weitere Bedingungen für die OLTP-Systeme, die erfüllt sein müssen, damit automatisch Änderungen an ihnen vorgenommen werden. Anwendungsbeispiel Fluggesellschaft

Mit Hilfe von Active Data Warehousing können komplexe Steuerungsprobleme besser unterstützt werden. Ein Beispiel ist die Koordination von Flugverbindungen durch eine Fluggesellschaft. Hierbei ist auf Änderungen im Flugplan zu reagieren, indem Kunden informiert, umgeleitet und ggf. umgebucht werden. Parallel müssen die Flugrouten angepasst werden – unter Berücksichtigung der Entfernungen, des Beladungsvolumens sowie der Kerosinpreise an den möglichen Zwischenstopps (Akbay 2006, Raden 2003, S. 4).

Verringerung der Analyse-, Entscheidungs- und Umsetzungslatenz

Das Active Data Warehousing integriert den Ansatz des Closedloop und erweitert ihn um eine aktive Entscheidungsunterstützung auf Basis von Analyseregeln. Damit verringert das Active Data Warehousing in seinem Anwendungsfeld die Latenzzeiten bei der Analyse, Entscheidung und Umsetzung.

Implementierungsansätze — Zusammenfassung Die hier vorgestellten Implementierungsansätze unterstützen jeweils unterschiedliche Anforderungen, die sich aus den Rahmenbedingungen spezifischer BI-Anwendungen ergeben. Das Real-time Data Warehousing verringert die Datenlatenz und kann 95

3 Informationsgenerierung, -speicherung, -distribution und -zugriff somit Daten für zeitkritische Analysen zur Verfügung stellen. Der Closed-loop-Ansatz stellt sicher, dass die Erkenntnisse systematisch und zeitnah in weiteren Anwendungssystemen zur Verfügung gestellt werden und verkürzt somit die Umsetzungslatenz. Das Active Data Warehousing, als umfangreichste Anwendungsmöglichkeit, automatisiert die Entscheidungsfindung und -umsetzung bei gut strukturierten Problemstellungen. Die einzelnen Implementierungsmöglichkeiten sind in Abhängigkeit des tatsächlichen betrieblichen Bedarfs zu wählen. Realtime- und Closed-loop-Lösungen sind dabei lediglich Ergänzungen zum klassischen Data Warehousing – das dadurch nicht obsolet wird. So wäre es beispielsweise verfehlt, für monatliche Wettbewerbsanalysen den Ansatz des Real-time Data Warehousing zu wählen, da hier die fachlichen Anforderungen einer Datenversorgung in Echtzeit nicht gegeben sind. In aktuellen Konzepten der dispositiven Datenversorgung kommen meist verschiedene Data-Warehousing-Ansätze kombiniert zum Einsatz, wobei jedoch in der Praxis häufig der gesamte Ansatz mit der Bezeichnung der modernsten und technisch herausforderndsten Komponente versehen wird. So ist es üblich, dass Unternehmen ihren Ansatz der dispositiven Datenversorgung als Real-time Data Warehouse bezeichnen, obwohl diese DWHKomponente lediglich für einen kleinen Teil ihrer BI-Anwendungen eingesetzt wird. Die folgende Abb. 3.5 zeigt zusammenfassend die einzelnen Implementierungsansätze und deren Einfluss auf die Latenzzeiten. Datenlatenz

Analyselatenz

Entscheidungslatenz

Umsetzungslatenz

Zeit

Closed-loopDWH Real-Time DWH

Abb. 3.5:

Gegenüberstellung und Latenzen

Active DWH

von

Implementierungsansätzen

3.1.4

Freie Datenrecherche

Freie Datenrecherche

Eine freie Datenrecherche ist die Nutzung einer Datenmanipulationssprache (data manipulation language, DML), um eine Teilmenge der Daten der dispositiven Datenhaltungssysteme (DWH, ODS, Data Marts) zu recherchieren und angemessen darzustellen.

96

3.1 Informationsgenerierung: Analysesysteme Im Gegensatz zu anderen Berichts- oder Analysesystemen bedient sich der Benutzer somit einer eher techniknahen Sprache. Üblicherweise erlauben diese Sprachen das direkte Lesen, Einfügen, Löschen und Ändern von Daten, wobei die Rechte selbstverständlich durch die Berechtigungskonzepte der dispositiven Datenhaltung geregelt werden (vgl. Kapitel 2.3.5). Structured Query Language (SQL)

Im relationalen Kontext hat sich die Structured Query Language) als anerkannter Standard durchgesetzt, wobei hier neben der oben erwähnten Datenmanipulation auch Funktionen der Datendefinition existieren, mit deren Hilfe die Strukturen der Tabellen, die Schemata, festgelegt werden können (Elmasri/Navathe 2007, S. 37 f.). Um auch den Anforderungen multidimensionaler Datenstrukturen zu genügen, wurden in die neueren Versionen des SQLStandards entsprechende Navigations- und Bearbeitungsfunktionen ergänzt (ISO 2008). SELECT NON EMPTY {[Zeit].[Jahre].Members} on rows

Zeilen: Dimension & Ebene

{[Verkäufer].[Land].[Niederlassung].Members} on columns

Spalten: Dimension & Ebene

FROM BMW-Händler

Hypercube

WHERE ([Main].[Umsatz])

Fakten: Umsatz

Stuttgart

Ulm

Essen

Düsseldorf

…

2003

1.492.123,23

1.556.025,49

1.476.279,18

2.529.752,00

…

2002

1.566.729,39

1.489.019,60

1.342.071,98

2.480.149,02

…

2001

1.504.060,21

1.353.654,18

1.167.019,11

2.066.790,85

…

…

…

…

…

…

…

Abb. 3.6: MDX

MDX-Abfrage

Darüber hinaus existieren weitere Datenmanipulationssprachen verschiedener Hersteller, die einen umfangreichen, aber proprietären Leistungsumfang besitzen. Ein populäres Beispiel stellt die Abfragesprache MDX (Multidimensional Expressions) der Firma Microsoft dar, die sich als De-facto-Industriestandard in der Praxis etabliert hat. Abb. 3.6 zeigt eine beispielhafte Abfrage. Generell sollten folgende Funktionen zur Recherche in multidimensionalen Datenräumen verfügbar sein:

97

3 Informationsgenerierung, -speicherung, -distribution und -zugriff • Datenauswahl und Navigation Um in der multidimensionalen Struktur adäquat navigieren und Daten gezielt selektieren zu können, müssen diese Konzepte auch in der Abfragesprache abgebildet werden. Hierzu gehören die Berücksichtigung einer fachlich angemessenen Anzahl von Dimensionen sowie die Steuerung über die Hierarchieebenen einzelner Dimensionsausprägungen. • Verdichtungen Die Verdichtung von Daten kann je nach Datenausprägung und Benutzerwünschen unterschiedliche Formen annehmen. So liegt auf der Hand, dass Umsätze additiv zusammenfassbar, Produktpreise jedoch lediglich als Durchschnittspreise auf höheren Hierarchieebenen interpretierbar sind. Geläufig sind demnach Summen, (gewichtete) Durchschnittswerte oder die Nennung der höchsten oder niedrigsten Werte (Extrema), wobei die Sprache sowohl eine Vorberechnung häufig verwendeter Verdichtungen als auch die jeweilige Ad-hoc-Berechnung (on the fly) erlauben sollte. • Belegungsfunktionen Belegungsfunktionen (allocations) gestatten die automatische Weitergabe bzw. Aufteilung von Werten auf der Basis von Profilen. Somit können Werte übergeordneter Hierarchieebenen auf Zellen in nachfolgenden Ebenen kopiert bzw. verteilt werden, wobei die Spannbreite von einfachen Zahlenkopien bis hin zu komplexen Umrechnungen auf der Basis mathematischer Schlüsselungen möglich ist. In Planungs- und BudgetierungsAnwendungen werden auf diese Weise beispielsweise Gemeinkosten einer konsolidierten Einheit (etwa der Zentrale) auf die Grundeinheiten (die Filialen) mit Hilfe einer Schlüsselung (z. B. im Verhältnis ihres jeweiligen Umsatzes) verteilt. • Faktengenerierung Die Faktengenerierung ermöglicht automatisierte, individuelle Berechnungen von verschiedenen Zelleninhalten wie z. B. die Ableitung von betriebswirtschaftlichen Kennzahlen. • Zusammenfassung von Dimensionselementen Eine individuelle Zusammenfassung von Dimensionselementen erlaubt benutzerspezifische Auswertungen. Somit können Sichten auf alternativen Hierarchieebenen generiert werden (beispielsweise die Definition eines Dimensionselements „Eurozone“, das alle Länder umfasst, die den Euro als Landeswährung führen). 98

3.1 Informationsgenerierung: Analysesysteme Vorteile

Das Arbeiten auf einer techniknahen Ebene bringt Vorteile mit sich. Da die Operationen direkt im Datenbestand ausgeführt werden, sind die Abfragen in der Regel performanter. Weitere Aspekte sind die große Flexibilität und die problemlose Weiterverwendbarkeit der Analyseergebnisse in anderen Systemumgebungen.

Nachteil

Den Vorteilen steht jedoch auch ein gewichtiger Nachteil gegenüber. So setzt der Einsatz einer Datenmanipulationssprache eine detaillierte Kenntnis der Sprache und einen hohen Grad an ITKompetenz voraus. Da Endbenutzer im Allgemeinen nicht über dieses Wissen verfügen, sind für sie die freien Datenrecherchen kaum sinnvoll einsetzbar. In vielen Fällen können sie sogar durch ungeschickte Anfragen die Performance des Datenhaltungssystems so stark beeinträchtigen, dass der gesamte Betrieb nachhaltig gestört wird. Aus den genannten Gründen werden diese Sprachen in aller Regel lediglich Datenbankadministratoren und Power-Usern – also besonders versierten Endbenutzern – zugänglich gemacht.

3.1.5

OLAP

Die Forderung nach benutzerfreundlichen, flexiblen Abfragesystemen für Ad-hoc-Analysen beschäftigt die Wissenschaft und Praxis bereits seit vielen Jahren. Für sehr viel Aufmerksamkeit sorgte in diesem Zusammenhang ein von Edgar F. Codd und Mitautoren veröffentlichter Artikel mit dem Titel „Beyond Online Analytical Decision Support“ aus dem Jahre 1993 (Codd et al. 1993a, Processing – OLAP S. 87 ff.). Hier wurde unter dem Begriff Online Analytical Processing (OLAP) eine neue Begrifflichkeit in die Diskussion eingebracht und von den Protagonisten als innovativer Analyseansatz vorgestellt, der eine dynamische Analyse in multidimensionalen Datenräumen ermöglichen sollte.

Kriterien des Online Analytical Processing In seiner ursprünglichen Form wurde der Begriff OLAP über zwölf Kriterien definiert (Codd et al. 1993b): 1. Multidimensionale konzeptionelle Sichtweise 2. Transparenz 3. Zugriffsmöglichkeit 4. Gleichbleibende Antwortzeiten bei der Berichterstellung 5. Client/Server-Architektur 99

3 Informationsgenerierung, -speicherung, -distribution und -zugriff 6. Generische Dimensionalität 7. Dynamische Behandlung dünn besetzter Matrizen 8. Mehrbenutzer-Unterstützung 9. Uneingeschränkte kreuzdimensionale Operationen 10. Intuitive Datenbearbeitung 11. Flexible Berichtserstellung 12. Unbegrenzte Anzahl von Dimensionen und Klassifikationsebenen Auch wenn diese Aufstellung anfangs aufgrund ihrer Ausrichtung auf ein konkretes, kommerziell erwerbbares Datenbanksystem heftig kritisiert wurde, so ist den Autoren – speziell Edgar F. Codd – die Initiierung einer damals längst überfälligen benutzerorientierten Diskussion zum Themenbereich der IT-basierten Managementunterstützung zu verdanken. Wissenschaftler und Praktiker beteiligten sich an dieser Diskussion und publizierten zusätzliche Kriterien, so dass letztendlich mehr als 300 Regeln im OLAP-Umfeld identifiziert werden konnten (Düsing/Heidsieck 2009, S. 108). FASMI: Fast analysis of shared multidimensional information

Eine Konsolidierung dieser Eigenschaften wurde 1995 von Pendse und Creeth mit der Reduzierung auf fünf Kerninhalte vorgenommen (Pendse/Creeth 1995; Pendse/Creeth 2008). Das Akronym FASMI steht für „Fast Analysis of Shared Multidimensional Information“. Diese Kriterien haben sich als kurze und prägnante Umschreibung des Analysekonzepts durchgesetzt und sind wie folgt definiert: • 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.

100

3.1 Informationsgenerierung: Analysesysteme

Operationen in multidimensionalen Datenräumen Multidimensionale Datenräume bestehen aus Fakten, Dimensionen und Hierarchisierungen (vgl. Kapitel 2.4.2). Obwohl theoretisch in ihrer Anzahl nicht begrenzt, besitzen betriebswirtschaftliche Anwendungen meist Dimensionen im einstelligen bzw. niedrigen zweistelligen Bereich. Die Limitation erklärt sich aufgrund der Charakteristika betriebswirtschaftlicher Problemstellungen und der begrenzten kognitiven Fähigkeiten des Menschen. So ist es unrealistisch, Auswertungen auf der Basis von mehreren hundert Dimensionsausprägungen durchzuführen, da dieses Konstrukt für die Analysten nicht mehr durchschaubar wäre. Geographie

Zeit

P

rod

te uk

Abb. 3.7: Cube

Cube und Dimensionen

Unabhängig von der Anzahl der Dimensionen wird stets der Würfel als Metapher für multidimensionale Datenräume gewählt. In diesem Zusammenhang wird nicht selten der Begriff Hypercube verwendet, der bereits durch die Worterweiterung die unbeschränkte Anzahl möglicher Dimensionen andeutet. Im weiteren Verlauf des Buches wird jedoch der in der Praxis übliche Begriff Cube präferiert. Die Abb. 3.7 verdeutlicht einen solchen mehrdimensionalen Datenraum mit seinen Dimensionen Zeit, Produkte und Geographie. 101

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Operationen

Üblicherweise werden verschiedene Klassen von Operationen differenziert, mit deren Hilfe spezifische Auswertungen in multidimensionalen 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. • Pivotierung/Rotation Häufig reicht ein zweidimensionaler Ausschnitt aus dem Cube für Analysen der betrieblichen Anwender aus. Eine solche Sicht ist beispielsweise eine Seite des Würfels.

Geographie

Geographie

Unter Pivotierung12 versteht man das Drehen des Würfels um eine Achse, so dass eine andere Kombination von zwei Dimensionen sichtbar wird (vgl. Abb. 3.8). Synonym hierzu wird auch der Begriff der Rotation verwendet. Dieses Konzept kommt außerdem in Form von Pivot-Tabellen bei gängigen Tabellenkalkulationsprogrammen zum Einsatz (z. B. Albright et al. 2006).

Zeit

Abb. 3.8:

Produkte

Pivotierung des Cubes

• Roll-up & Drill-down Um innerhalb der Dimensionshierarchien zu navigieren, stehen zwei Operatoren zur Verfügung. Durch einen Roll-up werden die Werte einer Hierarchieebene zu der darüber liegenden Verdichtungsstufe aggregiert. Dadurch verringert sich der Detaillierungsgrad. Die inverse Operation hierzu ist der Drill-down, bei dem ein aggregierter Wert wieder in seine Bestandteile auf der darunter

12

102

Aus dem französischen „pivot“, „Schwenkzapfen (an Geschützen, Drehkränen u. a. Maschinen)“ (Wahrig-Burfeind 2006)

3.1 Informationsgenerierung: Analysesysteme liegenden Ebene aufgeschlüsselt wird. Abb. 3.9 verdeutlicht den Zusammenhang. Pr od

1. Quartal

Pr od

uk tA

140.000

uk t

Pr B

100.000

od u

Pr kt

C

200.000

od u

kt

D

120.000

Drill-down

Roll-up Januar

40.000

30.000

70.000

40.000

Februar

45.000

35.000

60.000

35.000

März

55.000

35.000

70.000

45.000

Abb. 3.9:

Roll-up & Drill-down

• Drill-through & Drill-across Drill-through und Drill-across sind besondere Operationen, da sie eine Navigation über den originären multidimensionalen Datenraum hinaus ermöglichen. Stößt ein Drill-down auf die höchste Detaillierungsstufe, kann in der Regel keine weitere Verfeinerung erfolgen. Durch einen Drill-through wird jedoch die physikalische Datenquelle gewechselt und somit detailliertere Daten verfügbar gemacht. Der Wechsel findet ohne erkennbare Veränderungen der Benutzungsoberflächen statt und ist somit vom Benutzer nicht bemerkbar, also benutzertransparent. Je nach Granularitätsgrad kann hierfür auf eine weitere multidimensionale oder eine relationale Datenquelle zugegriffen werden. Der Drill-through ermöglicht somit eine erweiterte vertikale Recherche. Der Drill-across hingegen erweitert die horizontalen Recherchemöglichkeiten, indem er den Wechsel zwischen Cubes ermöglicht. Grundlage hierfür ist die Wiederverwendung von Dimensionshierarchien in mehreren Cubes. In einem Unternehmen können beispielsweise ein Cube für den Einkauf mit Einstandspreisen sowie ein weiterer für den Vertrieb mit Einkaufspreisen vorliegen, wobei beide Cubes die Dimensionen Geographie und Zeit verwenden. Durch einen Drill-across könnten über die Cubes hinweg Handelsspannen pro Produkt und Zeiteinheit analysiert werden (vgl. Abb. 3.10).

103

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Cube Vertrieb mit Verkaufspreisen

Cube Einkauf mit Einstandspreisen

Kunden

Lieferanten

Zeit

Zeit

Handelsspannen pro Zeiteinheit und Produkt

Abb. 3.10: Beispiel für die Nutzung der Drill-across-Operation

• Slice & Dice Geographie

Alle Produkte über alle Regionen für einen bestimmten Zeitpunkt Alle Regionen über den gesamten Zeitraum für ein bestimmtes Produkt

Alle Produkte über den gesamten Zeitraum für eine bestimmte Region

Zeit od Pr

te uk

Abb. 3.11: Zuschnitt des Datenraums durch den Slice-Operator Um die große Menge der Daten bedarfsgerecht filtern zu können, stehen ebenfalls zwei Operatoren zur Verfügung. Ein Slice ist in dem dreidimensionalen Beispielmodell eine Scheibe, die aus dem Datenwürfel entnommen wird. Faktisch wird dies durch eine Beschränkung einer Dimension auf einen Wert umgesetzt.

104

3.1 Informationsgenerierung: Analysesysteme Dadurch kann ein Produktmanager z. B. sämtliche Daten in Bezug zu seinem Produkt einsehen (vgl. Abb. 3.11).

Geographie

Zeit o Pr

kte u d

Abb. 3.12: Dice-Operator Ein Dice, wie in Abb. 3.12 dargestellt, ist ein mehrdimensionaler Ausschnitt des Cubes. Hierbei werden mehrere Dimensionen jeweils durch eine Menge von Dimensionselementen eingeschränkt. Das Ergebnis ist ein neuer multidimensionaler Datenraum, der ggf. extrahiert oder weiterverarbeitet werden kann. • Split & Merge Der Split-Operator ermöglicht einen Aufriss eines Wertes nach Elementen einer weiteren Dimension und somit eine weitere Detaillierung eines Wertes (Lehner 2003, S. 75). So kann beispielsweise der Umsatz einer Filiale für eine bestimmte Menge von Produkten wie in Abb. 3.13 dargestellt werden. Der inverse Operator hierzu ist der Merge, durch den der Einschub der zusätzlichen Dimension entfernt und somit die Granularität der Darstellung verringert wird.

105

3 Informationsgenerierung, -speicherung, -distribution und -zugriff

Geographie

Produkte Zeit

Stadtmitte

West

1.Quartal

2. Quartal

3. Quartal

Produkt A

12.000

12.000

12.000

Produkt B

8.000

10.000

8.000

Produkt C

16.000

16.000

16.000

Produkt A

10.000

8.000

10.000

Abb. 3.13: Split-Operator

OLAP — Benutzersicht und physikalische Umsetzung Es hat sich heute die Meinung etabliert, dass OLAP einen aus Benutzersicht mehrdimensionalen Datenraum aufspannt, der eine flexible, benutzerfreundliche Ad-hoc-Analyse erlaubt. Die physikalische Datenhaltung kann demnach losgelöst von der Benutzersicht erfolgen. Für die Repräsentation der Daten können somit alle denkbaren technischen Formen der Datenhaltung herangezogen werden, wobei primär relationale und multidimensionale Datenhaltungssysteme zum Einsatz kommen. In der Praxis wird die Mehrzahl der OLAP-Systeme in Form von Client-Server-Architekturen umgesetzt. Die Datenhaltung erfolgt in der Regel auf der Seite des Servers. Hierbei wird durch ein Präfix signalisiert, welche Datenbanktechnologie bei der physischen Datenspeicherung Verwendung findet (Gluchowski/ Chamoni 2010, S. 210 ff.). Die Abb. 3.14 verdeutlicht die möglichen OLAP-Umsetzungskonzepte und deren Datenhaltungskomponenten. R-OLAP

106

Beim relationalen OLAP (R-OLAP) kommen Star- und SnowflakeSchemata auf Basis von klassischen, standardisierten relationalen Datenbanksystemen zum Einsatz (vgl. auch Kapitel 2.4.2 und Kapitel 2.4.3). Die Vorteile dieser Variante liegen in der hohen Stabilität und Sicherheit in Anwendungsbereichen mit hohem Datenvolumen und großen Benutzerzahlen.

3.1 Informationsgenerierung: Analysesysteme Analyse R-OLAP

M-OLAP

Datenhaltung

H-OLAP

Benutzertransparenter Übergang

Multidimensionales DBMS

Relationales DBMS mit multidimensionalem Modell

Abb. 3.14: R-OLAP, M-OLAP und H-OLAP M-OLAP

Multidimensionale OLAP-Systeme (M-OLAP) verwenden herstellerabhängige, proprietäre Datenbanksysteme, die speziell auf eine hohe Performance in multidimensionalen Datenstrukturen ausgerichtet sind (vgl. Kapitel 2.3.2). Die Vorteile dieser Lösung liegen demnach vor allem in der Flexibilität und in dem Antwortzeitverhalten.

H-OLAP

Das hybride OLAP (H-OLAP) ist eine Variante, welche die Vorteile beider Techniken vereint. So erlauben diese OLAP-Systeme einen benutzertransparenten Übergang von relationaler und physikalisch mehrdimensionaler Datenhaltung. Üblicherweise werden in diesen Architekturen M-OLAP-Techniken bei den hochverdichteten Datenbereichen verwendet, die sich durch geringes Datenvolumen und eine eher überschaubare Anzahl von Benutzern auszeichnet. Wenn der Benutzer durch Drilldown-Navigation in detailliertere Datenbereiche vorstößt, wechselt er benutzertransparent in die relationale Datenhaltung.

Alternativen für die Benutzerführung OLAP-Werkzeuge bieten üblicherweise Funktionalität, die Freiheitsgrade des Benutzers bei der Analyse flexibel zu definieren und so individuelle OLAP-Anwendungen zu entwickeln. Gestaltungsspielräume bestehen dabei üblicherweise hinsichtlich • des Datenraums, der für Analysen verfügbar gemacht wird (Auswahl von Dimensionen, Attributen und Kennzahlen),

107

3 Informationsgenerierung, -speicherung, -distribution und -zugriff • der Zusammenstellung von Navigationsoptionen und Bedienelementen (Schaltflächen, Texteingabefelder, Comboboxen zur Dimensionsauswahl etc.) sowie • des Layouts der Analyseoberfläche (Platzierung und Dimensionierung von Grafiken, Tabellen, Logos, Bedienelementen etc.). Das Spektrum der so konzipierten Anwendungen reicht von vollständig geführten OLAP-Analysen bis hin zu weitgehend freien OLAP-Analysen. Geführte und freie Bei der geführten OLAP-Analyse verfügen die Systeme über intuitiv bedienbare, komfortable Benutzungsoberflächen, die es auch OLAP-Analysen IT-unerfahrenen Mitarbeitern erlauben, Analysen in multidimensionalen Datenräumen durchzuführen. Allerdings bieten diese Systeme lediglich eine eingeschränkte Analyseflexibilität, da ausschließlich antizipierte Navigationspfade, Berechnungsvarianten und Berichtsdarstellungen benutzerseitig angesteuert werden können. Freie OLAP-Analysen bieten lediglich eine eingeschränkte Benutzungsführung und erlauben individuelle Auswertungen und Weiterberechnungen.

Optionen zur Umsetzung der Benutzerschnittstelle Die Benutzerschnittstelle einer OLAP-Anwendung kann über ein dediziertes, auf dem Rechner des Benutzers installiertes ClientProgramm („Rich Client“) realisiert werden, durch die Einbindung in ein Tabellenkalkulationsprogramm oder über eine webbasierte Benutzerschnittstelle. Viele aktuelle Werkzeuge bieten die Möglichkeit, diese Optionen parallel zu nutzen. Eine Integration in Tabellenkalkulationsprogramme bietet sich v. a. für freie OLAP-Analysen an. Da IT-versierte Benutzergruppen – z. B. im Controlling – mit diesen Applikationen meist vertraut sind, ergeben sich durch die Kombination der beiden Systeme flexible Recherche-, Aufbereitungs-, Visualisierungs- und Exportfunktionalitäten. Abb. 3.15 verdeutlicht anhand des OpenSource OLAP-Systems Jedox Palo™ und des Tabellenkalkulationsprogramms MS-Excel™ eine solche Produktkombination. Immer größere Bedeutung erlangen webbasierte OLAP-Anwendungen. In diesen Fällen entfallen die dezentrale Installation und Wartung eines separaten Softwarewerkzeugs auf den Rechnern der Benutzer. Somit kann hierbei mit dem Browser auf eine vertraute Nutzungsumgebung aufgesetzt und eine einfachere Integ108

3.1 Informationsgenerierung: Analysesysteme ration der Benutzerschnittstelle in existierende WebInfrastrukturen ermöglicht werden (vgl. hierzu auch Kapitel 3.3.2).

Abb. 3.15: OLAP-Funktionalität und Tabellenkalkulation (hier: Jedox Palo™ für MS Excel™) In diesem Zusammenhang haben vor allem Technologien zur Realisierung sog. „Rich Internet Applications“ (RIAs) dazu geführt, dass die Unterschiede zu einem spezialisierten ClientProgramm immer weniger ins Gewicht fallen. Bei RIAs handelt es sich um interaktive Webanwendungen mit ansprechender Benutzerschnittstelle. Eine besondere Bedeutung hat dabei die Technologie „Ajax“ (Asynchronous Java and XML), die auf etablierten Web-Technologien fußt und diese um Möglichkeiten zu einer flexiblen Serveranbindung erweitert (Garrett 2005). Abb. 3.16 illustriert die Möglichkeiten am Beispiel einer mit dem Werkzeug „Cubeware Cockpit v6pro“ realisierten Anwendung auf der Basis eines Web Clients. Bei webbasierten, geführten OLAP-Anwendungen verschwimmen zunehmend die Grenzen zu den Berichtssystemen (vgl. Kapitel 3.1.7), so dass die beiden Anwendungsklassen trotz der unterschiedlichen Anwendungsschwerpunkte mittlerweile oft-

109

3 Informationsgenerierung, -speicherung, -distribution und -zugriff mals gemeinsam unter einer Überschrift („OLAP und Reporting“, z. T. auch nur „Reporting“) adressiert werden.

Abb. 3.16: OLAP-Anwendung in webbasierter Ajax-Oberfläche (hier: Cubeware Cockpit v6pro™)

3.1.6

Modellgestützte Analysesysteme Während bei der freien Datenrecherche und den OLAP-Systemen meist kleinere Berechnungen – z. B. Ableitung eines Deckungsbeitrags – durchgeführt werden, erfordern komplexe Auswertungen modellgestützte Systeme, die eine ausgeprägte algorithmische oder regelbasierte Ausrichtung aufweisen. Zu dieser Kategorie gehören die im Folgenden erläuterten Decision Support Systems, Expert Systems, das Data Mining, vom Data Mining abgeleitete Systeme für die Analyse unstrukturierter Daten (Text Mining) sowie anwendungsspezifische modellbasierte Analysesysteme (Web Mining und Process Mining). Aufgrund der anspruchsvolleren Verfahren werden solche Systeme auch unter der Bezeichnung „Advanced Analytics“ geführt (Bose 2009, S. 156).

Decision Support Systems Anfang der 70er Jahre wurde an der Sloan School of Management des Massachusetts Institute of Technology (MIT) ein Fra110

3.1 Informationsgenerierung: Analysesysteme mework für die Informationssysteme des Managements entwickelt (Gorry/Scott Morton 1971). Gorry und Scott Morton kamen bei diesen Arbeiten zu dem Schluss, dass die bis dato eingesetzten Systeme primär den Teil der strukturierten Managementaufgaben unterstützten. Auf Basis dieser Vorüberlegungen identifizierte Scott Morton das Einsatzfeld eines neuen Typs von computerbasierten Managementunterstützungssystemen, der sich im Gegensatz zu den etablierten Systemen durch eine algorithmische Orientierung auszeichnete. Diese Systeme wurden unter dem Begriff Decision Support Systems (DSS) – im Deutschen als Entscheidungsunterstützungssysteme (EUS) – bekannt und werden seitdem zur Unterstützung semi- und unstrukturierter Problemstellungen eingesetzt. Das Konzept der DSS wurde vielfältig weiterentwickelt und auch teilweise begrifflich unterschiedlich abgegrenzt (Turban et al. 2004, S. 103). In Anlehnung an die allgemein akzeptierte Definition wird im Weiteren unter einem DSS ein interaktives, modellund formelbasiertes System verstanden, das funktional auf einzelne (Teil-)Aufgaben bzw. Aufgabenklassen beschränkt ist (Mertens/Meier 2009, S. 12). Die Erstellung kann auf Basis von existierenden oder eigenständig entwickelten Methoden vom Endbenutzer selbst durchgeführt werden, indem er seine individuelle Problemstellung abbildet. In der Praxis werden kleinere DSSAnwendungen häufig auf der Basis von Tabellenkalkulationspro™ grammen wie MS-Excel erstellt (Albright et al. 2006). Komponenten eines DSS

Unabhängig von der eingesetzten Technologie besteht ein DSS aus mehreren Komponenten, die in Abb. 3.17 dargestellt sind. DSS Ablaufsteuerung Dialogführung

Modellund Methodenbank

Anwendungsunterstützung

Datenbasis

Abb. 3.17: Komponenten eines DSS • Datenbasis Die Datenbasis enthält die Werte für die Berechnungen. Zum Einsatz kommen hierbei aufgrund der Applikationsklassenaus111

3 Informationsgenerierung, -speicherung, -distribution und -zugriff richtung primär Data Marts bzw. Extrakte in Dateiform (sog. flat files). • Modell- und Methodenbank Methodenbank

Die Methodenbank hält alle Standard- und Spezialalgorithmen eines DSS vor. Als implementierte Methoden kommen hierbei vor allem heuristische, statistische, finanzmathematische und prognostische Verfahren zum Einsatz. Um eine komfortable Nutzung einer Methodenbank sicherzustellen, verfügen leistungsfähige Systeme zusätzlich über weitergehende Funktionen für die Organisation, Benutzung und Sicherung der Methodensammlung (Mertens/Meier 2002, S. 71 ff.).

Modellbank

Die sinnvolle Verknüpfung mehrerer Methoden zur Unterstützung einer Klasse von Entscheidungsaufgaben wird im DSSKontext als Modell verstanden. Eine Modellbank enthält somit eine Menge abgestimmter Methodensammlungen, die mit geringer Anpassung auf konkrete Problemstellungen angewandt werden können. Da der Übergang zwischen Methoden und Modellen eher fließend ist, wird in der englischsprachigen Literatur teilweise nicht zwischen Methoden- und Modellbank unterschieden, sondern beides unter dem Sammelbegriff model base subsumiert (Turban et al. 2004, S. 115). • Anwendungsunterstützung Die Komponente der Anwendungsunterstützung stellt sicher, dass Endbenutzer auch ohne detaillierte Methoden-/Modell- und IT-Kenntnisse selbständig DSS entwickeln und einsetzen können. Hierfür bietet die Komponente spezielle Hilfsmittel, die ein einfaches Zusammenführen der relevanten Daten und der erforderliche Methoden bzw. Modelle erlauben. So werden dem Benutzer z. B. Erklärungen zur Einsatzfähigkeit der Methoden/Modelle zur Verfügung gestellt, Interpretationshilfen für Ergebnisvarianten angeboten oder Auswertungen mit Hilfe von automatischen Parameter-Vorbelegungen erleichtert. • Dialogführung Die Dialogführung ermöglicht als direkte Schnittstelle zum Endbenutzer eine komfortable Interaktion zwischen Anwender und System. Sie erlaubt somit die intuitive Nutzung sämtlicher DSSKomponenten und steuert den gesamten Lösungsprozess von der Plausibilitätsprüfung der Eingabe bis zur Wahl der Ausgabeformate der Ergebnisse.

112

3.1 Informationsgenerierung: Analysesysteme

Expert Systems Die Entwicklung von Expert Systems (XPS) – im Deutschen als Expertensysteme oder wissensbasierte Systeme bezeichnet – stellt eine Teildisziplin des Forschungsbereiches der Künstlichen Intelligenz (Artificial Intelligence, AI) dar. Das Ziel von XPS ist es, das Wissen menschlicher Experten in abgegrenzten, domänenspezifischen Anwendungsbereichen mit Hilfe von IT-Systemen verfügbar zu machen. Hierbei beschränkt sich die Integration nicht allein auf das Fachwissen des Experten, sondern umfasst auch spezifisches Wissen um Problemlösungsmechanismen. Neben formalen Entscheidungskalkülen sollten daher insbesondere die langjährigen Erfahrungen menschlicher Entscheider, die sich in Heuristiken, Vermutungen und Annahmen manifestieren, in das XPS einbezogen werden (Kemper 1999, S. 45 f.; Gabriel 2008). Nach anfänglichen, zu euphorischen Forschungsansätzen in den 80er Jahren hat sich die Auffassung durchgesetzt, dass XPS in semi- oder schlecht-strukturierten Problemsituationen keine eigenen Entscheidungen treffen sollten. Vielmehr wird es als primäre Aufgabe von XPS angesehen Hilfestellungen bei der Entscheidungsfindung durch das Anbieten von Handlungsempfehlungen zu gewähren. Anwendungsgebiete für XPS finden sich beispielsweise bei der Kreditwürdigkeitsprüfung von Finanzdienstleistern oder im Rahmen der Durchführung von Risikoanalysen in Versicherungen. Darüber hinaus werden XPS als Subsysteme integrierter Anwendungen in Form von aktiven Hilfssystemen oder intelligenten Agenten eingesetzt. Auch wenn sie in dieser Rolle nicht als eigenständige Applikation im Vordergrund stehen, können sie so dennoch zu einem Bestandteil moderner BI-Konzepte werden.

Data Mining Die Anfänge der computergestützten Datenanalysen zur Mustererkennung lassen sich bis in die 60er Jahre zurückverfolgen. Aber erst die Etablierung harmonisierter dispositiver Datenreservoirs (ODS, DWH, Data Mart) hat diesen Systemen einen Durchbruch auf breiter Basis ermöglicht. Unter den Begriffen Data Mining oder Knowledge Discovery in Databases (KDD) hat die Datenmustererkennung eine Renaissance erlebt. In der Wissenschaft herrscht Uneinigkeit, ob die Begrifflichkeiten Data Mining und KDD synonym zu verstehen sind oder ob sich 113

3 Informationsgenerierung, -speicherung, -distribution und -zugriff hinter den Begriffen unterschiedliche Aspekte eines Konzeptes verbergen. In diesem Buch soll kein Beitrag zu dieser Diskussion geleistet werden. Vielmehr wird im Weiteren lediglich der in der Praxis vorherrschende Begriff Data Mining verwendet und für eine Diskussion der Begrifflichkeiten auf die einschlägige Literatur verwiesen (z. B. Bensberg/Schultz 2001; Fayyad et al. 1996, Han/Kamber 2006). 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“ (Bissantz et al. 2000, S. 380).

Data Mining

Kontroverse Diskussionen existieren darüber, ob Data-MiningMethoden zur Validierung von Hypothesen oder ausschließlich für eine hypothesenfreie Mustererkennung zu verwenden sind. Zu den verschiedenen Auffassungen vgl. Abb. 3.18. Deutlich wird, dass in einer engen Begriffsauslegung dem System ohne vorherige Hypothesenbildung sowohl das Selektieren der Datenbasis und die Methodenauswahl als auch die Analyse der Daten und die Ergebnisausgabe obliegt. Trad. Datenanalyse

Hypothesengenerierung

Selektieren der Datenbasis

Auswahl der Methoden

Analyse der Datenbasis

Zusammenfassung der Ergebnisse

Interpret. der Ergebnisse

Benutzer

Benutzer

Statistik-Exp.

IT-Experte

Statistik-Exp.

Benutzer

Selektieren der Datenbasis

Auswahl der Methoden

Data Mining i.e.S.

Analyse der Datenbasis

Zusammenfassung der Ergebnisse

Data-Mining-System Data Mining i.w.S.

Hypothesengenerierung

Selektieren der Datenbasis

Benutzer

Benutzer

Auswahl der Methoden

Analyse der Datenbasis Data-Mining-System

Interpret. der Ergebnisse Benutzer

Zusammenfassung der Ergebnisse

Interpret. der Ergebnisse Benutzer

Abb. 3.18: Traditionelle Datenanalyse und Data-MiningKonzepte (modifiziert übernommen aus Bissantz et al. 2000, S. 381) In der praxisüblichen weiten Begriffsauslegung konzentrieren sich die automatisierbaren Aktivitäten auf die Methodenauswahl, die Datenanalyse und deren Präsentation. Die Generierung von

114

3.1 Informationsgenerierung: Analysesysteme Hypothesen und die Festlegung der zu analysierenden Datenbestände werden weiterhin den Systembenutzern zugeordnet. Data-MiningMethoden

Die Methoden des Data Mining leiten sich aus den Bereichen der Statistik, der Künstlichen Intelligenz, des Maschinellen Lernens und der klassischen Mustererkennung (pattern recognition) ab. Je nach Aufgabenstellung können eine oder mehrere Methoden zum Einsatz kommen.

Einsatzgebiete für Data-MiningMethoden

Bei den Einsatzmöglichkeiten für Data-Mining-Methoden unterscheiden Hippner und Wilde die beiden grundlegenden Kategorien der Beschreibungs- und Prognoseprobleme (vgl. Abb. 3.19). Bei Beschreibungsproblemen steht die Strukturierung von bekannten Datenausprägungen im Vordergrund, während bei Prognoseproblemen eine Aussage über unbekannte oder künftige Merkmalswerte abgeleitet wird. Beide Kategorien lassen sich, wie nachstehend beschrieben, noch weiter detaillieren (im Folgenden Hippner/Wilde 2001, S. 96 ff.). Data-MiningProblemtyp

Beschreibungsprobleme

Prognoseprobleme

Deskription

Klassifikation

Abweichungsanalyse

Wirkungsprognose

Assoziation Gruppenbildung

Abb. 3.19: Problemtypen im Data Mining • 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.

115

3 Informationsgenerierung, -speicherung, -distribution und -zugriff • Abweichungsanalyse Im Mittelpunkt der Abweichungsanalyse stehen untypische oder fehlerhafte Werte, die durch die Verwendung eines Data-MiningModells erkannt werden. In der Praxis werden auf diese Weise z. B. Fälle von Kreditkartenmissbrauch identifiziert, wobei als potenzielle Kriterien außergewöhnlich hohe Summen oder atypische Zahlungsorte herangezogen werden können. • Assoziation Die Assoziation dient der Identifikation von Abhängigkeiten zwischen Objekten oder Attributen. Ein klassisches Beispiel hierfür sind Warenkorbanalysen auf Basis von Bondaten, durch die häufig gemeinsam gekaufte Waren identifiziert werden können. Als Data-Mining-Methoden können die Korrelationsanalyse und die Assoziationsanalyse eingesetzt werden. • Gruppenbildung Die Gruppenbildung wird oft auch als Segmentierung bezeichnet und dient der Identifizierung von sog. Clustern gleichartiger Objekte (wie z. B. Kunden) auf Basis von Ähnlichkeitsmerkmalen. Die Objekte innerhalb eines Cluster sollten möglichst homogen und die Objekte unterschiedlicher Cluster möglichst heterogen sein. Die Eigenschaften eines Clusters und die Merkmale, über die sich die Ähnlichkeit abgrenzen lässt, stehen im Vorfeld nicht fest. Als Data-Mining-Methoden sind die Clusteranalyse und künstliche neuronale Netzwerke in Betracht zu ziehen. • Klassifikation Bei der Klassifikation stehen bereits Klassen mit bestimmten Eigenschaften, den sog. abhängigen Zielgrößen, im Vorfeld fest. Das Ziel ist die automatische Zuordnung weiterer Daten zu den existierenden Klassen durch eine Auswertung der unabhängigen Merkmale. In der Praxis wird die Klassifikation z. B. für eine Bonitätsanalyse bei der Kreditvergabe verwendet. Die abhängige Zielgröße ist dabei die Bonität (kreditwürdig oder nicht), während die unabhängigen Merkmale demographischer oder soziographischer Art sein können (z. B. Alter, Einkommen, Berufsgruppe etc.). Mögliche Methoden sind die logistische Regressionsanalyse, Klassifikationsbäume, künstliche neuronale Netze und genetische Algorithmen.

116

3.1 Informationsgenerierung: Analysesysteme • Wirkungsprognose Bei der Wirkungsprognose wird auf Basis existierender Daten auf ein unbekanntes (zukünftiges, gegenwärtiges oder historisches Merkmal) geschlossen. So kann z. B. das Auftragsvolumen von Kunden auf Basis ihrer Kaufhistorie, der entsprechenden Branche und der allgemeinen Konjunkturdaten prognostiziert werden und somit als Grundlage für die eigene Kapazitätsplanung dienen. Passende Data-Mining-Methoden hierfür sind z. B. Regressionsanalysen, künstliche neuronale Netze, Box-JenkinsMethoden oder genetische Algorithmen. Von den Grundkonzepten des Data-Mining-Ansatzes wurden diverse spezifische Varianten zur Datenmustererkennung abgeleitet, die oftmals den eingängigen Wortbestandteil „Mining“ übernommen haben. Neben dem Text Mining, das auf die Analyse von Textsammlungen ausgerichtet ist, sind dies v. a. das Web Mining für die Untersuchung von Webinformationen, das Process Mining, das sich mit der Rekonstruktion und Untersuchung von Prozessen befasst. Das Text Mining ist aufgrund der großen Menge an relevanten Textinformationen in den Unternehmen besonders hervorzuheben. Da die Analyse semi- oder unstrukturierter Textinhalte besondere Anforderungen an die Datengewinnung, die Datenintegration und die Datenpräsentation mit sich bringt, ist es ratsam, die Diskussion nicht auf die Vorstellung einer einzelnen Klasse von Analysewerkzeugen zu beschränken, sondern vielmehr den übergreifenden Kontext der Einbindung unstrukturierter Textdaten in die Managementunterstützung zu beleuchten.

Text Mining Sowohl OLAP als auch klassische Data Mining Systeme dienen primär der Aufbereitung und Analyse strukturierter Daten. Strukturierte Daten können unmittelbar Datenbankfeldern zugeordnet werden und sind somit direkt maschinenverarbeitbar. Eine Vielzahl relevanter Informationen liegt jedoch in einer bestenfalls semi-strukturierten Textform vor, beispielsweise die Inhalte von

117

3 Informationsgenerierung, -speicherung, -distribution und -zugriff HTML-Seiten, PDF-Dateien, E-Mails, RSS-Feeds oder Einträge in einem Freitextfeld13. Es wurde wiederholt gezeigt, dass es betriebswirtschaftlich sinnvoll sein kann, diese Daten in die Managementunterstützung einzubinden und hierfür geeignete Werkzeuge einzusetzen (Mertens 1999, S. 415 ff.; Negash 2004, S. 180 ff.; Weiss 2005, S. 157 ff.). Besondere Bedeutung hat die Thematik durch die mittlerweile große Zahl an webbasierten Quellen erhalten (vgl. z. B. Hackathorn 1998). Anwendungsfelder finden sich u. a. bei der Analyse von Kundendaten im Customer Relationship Management, im betrieblichen Wissensmanagement sowie bei Wettbewerbs- und Marktanalysen (Competitive Intelligence) (Felden/Chamoni 2003, S. 642 ff.; Kemper/Baars 2006, S. 16 ff.; Baars/Kemper 2008, S. 132 ff.). Um unstrukturierte, textuelle Inhalte analysieren zu können, werden entsprechende Funktionalitäten für die Navigation und die Mustererkennung in Inhaltsbeständen benötigt. Ein Beispiel ist die Analyse thematischer Häufungen in Beschwerdeemails. Die für diese Klasse von Anwendungen notwendigen Verfahren werden unter der Überschrift Text Mining diskutiert14. Suche, Selektion und Vorverarbeitung von Inhalten

Mit der Auswertung von Text-Dokumenten sind spezifische Herausforderungen bei der Suche, der Selektion und der Vorverarbeitung der Inhalte verbunden, die dem Einsatz der eigentlichen Text-Mining-Schritte vorausgehen: • Suche und Selektion von Inhalten. In vielen Fällen ist es notwendig, eine erste (Vor-)Selektion potentiell relevanter Inhalte vorzunehmen, um die Zahl zu berücksichtigender Dokumente zu begrenzen. Das gilt in besonderem Maße, wenn Inhalte aus dem Web analysiert werden sollen. Die Suche kann dabei über Suchdienste Dritter oder eigene Web Crawler

118

13

Die Analyse weiterer Klassen unstrukturierter Daten, insbesondere Bild-, Audio- und Videoinhalte, wird derzeit in der Forschung intensiv verfolgt (Han/Kamber 2006, S. 607 ff.). Potentielle Einsatzmöglichkeiten in der Entscheidungsunterstützung finden sich beispielsweise in den Bereichen Objektsicherheit, Qualitätssicherung oder in der Analyse multimedialer Webinhalte.

14

In der Forschung verfolgt wird darüber hinaus die Extraktion einzelner Werte aus Textinhalten (Information Extraction), z. B. zur Gewinnung von Branchenkennzahlen aus über das Web bezogenen Unternehmensbeschreibungen. Die entsprechenden Verfahren sind jedoch derzeit in ihrer Einsetzbarkeit noch stark eingeschränkt.

3.1 Informationsgenerierung: Analysesysteme erfolgen, die sich rekursiv der Hyperlinks aus gefundenen Dokumenten bedienen, um weitere zu analysierende Dokumente aufzufinden. Im nächsten Schritt können selektierte Dokumente dann ähnlich wie bei einem Data Warehouse in einem integrierten Repository bereitgehalten werden, das von einigen Autoren auch als Document Warehouse bezeichnet wird (Sullivan 2001, S. 10 ff; Miliđ-Frayling 2005, S. 5 ff.). Die Realisierung erfolgt üblicherweise mit Content Management Systems (CMS) oder Document Management Systems (DMS) (vgl. hierzu auch die Kapitel 1.5 und 3.2.2). • Vorverarbeitung von Textinhalten. Bei der Vorverarbeitung von Textinhalten werden Verfahren eingesetzt, die unter dem Oberbegriff Natural Language Processing (NLP) zusammengefasst werden und die eine Extraktion von Bedeutungsinhalten aus Texten zum Ziel haben. Hierzu zählt die Aussonderung nicht sinntragender Worte (stop words), die Rückführung von Worten auf Wortstämme (stemming) bzw. Wortgrundformen (Lemmatisierung), die Markierung von Satzbestandteilen anhand ihrer grammatikalischen Funktion (part of speech tagging) oder die Auflösung von Synonymen mit Thesauren (Sullivan 2001, S. 31 ff.; Miliđ-Frayling 2005, S. 12 ff.; Hippner/Rentzmann 2006b, S. 102). Hierauf aufsetzen können Methoden zur kompakten Repräsentation und Beschreibung von Texten, etwa mit Hilfe des sog. „Vektorraummodells“, bei dem für jeden Text ein Vektor angelegt wird, der die Häufigkeiten einzelner Ausdrücke aus dem Textkorpus im Text quantifiziert. Nach den beschriebenen Vorverarbeitungsschritten liegen bereits strukturierte Beschreibungen der Inhalte vor, auf die das eigentliche Text Mining aufsetzt. Hierbei werden Verfahren eingesetzt, die auch aus dem Data-Mining-Kontext bekannt sind, etwa die Zuordnung eines Dokumentes zu bestimmten Kategorien (Klassifikation), die Gruppierung ähnlicher Dokumente (z. B. über Clusteranalysen), die Analyse des gemeinsamen Auftretens bestimmter Konzepte (Assoziationsmethode) oder die Aufdeckung von Themenhäufungen (Hippner/Rentzmann 2006a, S. 289). Auf diese Weise wird es möglich, auch größere Dokumentenbestände (semi-)automatisch zu explorieren, ggf. zusätzlich unterstützt durch Visualisierungsverfahren. Beispiele für betriebliche Einsätze sind die Analyse von Patentdatenbanken zur Aufdeckung von Technologietrends, die Analyse von Freitextfeldern in Transaktionsdaten oder die Analyse von Branchenmeldungen im Rahmen einer Konkurrenzanalyse. 119

3 Informationsgenerierung, -speicherung, -distribution und -zugriff

Nutzung von Dokumentenmetadaten als Analysedimensionen

Beispiel: Analyse von Vertriebsergebnissen

Für die integrierte Entscheidungsunterstützung von besonderem Interesse ist eine Verzahnung der beschriebenen Verfahren mit Systemen zur Aufbereitung und Analyse strukturierter Daten aus dem Data Warehouse. Ein hierfür mehrfach erprobtes (teil-)automatisierbares Verfahren besteht darin, strukturierte Metadaten zur Beschreibung der einzelnen Inhalte als Analysekategorien zu interpretieren, in ein DWH oder einen Data Mart zu exportieren und mit dort vorhandenen Daten zu verknüpfen. Das DMS oder CMS übernimmt dabei die Rolle einer weiteren Datenquelle für das quantitative dispositive Datenhaltungssystem, wobei Metadatenfelder aus dem DMS oder CMS in Analysedimensionen transformiert werden. Beispielsweise kann ein Metadatenfeld zum Autor auf eine Organisationsdimension projiziert werden. Sofern diese Dimensionen strukturgleich mit jenen zur Organisation quantitativer Daten sind, wird eine simultane Analyse strukturierter und unstrukturierter Daten möglich. Ein Beispiel für ein entsprechendes multidimensionales Datenmodell wird in Abb. 3.20 dargestellt (Galaxy-Schema, vgl. Kapitel 2.4.2). Das Modell war die Grundlage eines Systems zur integrierten Analyse von Vertriebsdaten und Außenberichtssegmenten und beruht maßgeblich auf Ideen von Cody et al. (2002). Die Verknüpfung der Daten erfolgte über die gemeinsamen Dimensionen Produkt, Zeit, Kunde und Ort. Für die quantitativen Vertriebsdaten wurde zusätzlich zwischen Plan- und Ist-Daten unterschieden (DT_Version). DT_Version KVersion Plan/Ist …

DT_Kunde KKunde Kundennr. Branche …

DT_Ort KOrt Niederlassung Region …

FT_Vertriebsanalyse KZeit KKunde KProdukt KOrt KVersion Umsatz Absatzmenge …

FT_Inhaltssegmente KZeit KKunde KProdukt Kort Dokumentverweise

DT_Produkt KProdukt Produktnr. Bezeichnung Produktgruppe … DT_Zeit KZeit Monat Quartal Jahr

Abb. 3.20: Integriertes Datenmodell zur Analyse strukturierter und unstrukturierter Inhalte (Frenkel et al. 2009, S. 4) 120

3.1 Informationsgenerierung: Analysesysteme Die Faktentabelle „Inhaltssegmente“ enthält keine quantitativen Messgrößen und wird lediglich zur Verknüpfung mit Verweisen auf die Texte genutzt15. Auf diese Weise konnten für bestimmte Kunden/Orte/Produkte/Zeitkombinationen Verweise auf Texte hinterlegt werden, mit denen quantitative Daten qualifiziert werden. Im Fall wurde auf dieser Basis eine OLAP-basierte Navigation in den so qualifizierten Daten ermöglicht (Frenkel et al. 2009, S. 3 ff.). Im einfacheren Fall kann für die Gewinnung der die Dokumente beschreibenden Metadaten auf bereits im DMS oder CMS gepflegte Felder zurückgegriffen werden, etwa zum Erstellungszeitpunkt der Dokumente oder zur verantwortlichen Organisationseinheit. Oftmals müssen Metadaten allerdings erst mit TextMining-Verfahren generiert werden. So kann mit Klassifikationsverfahren die Zuordnung von Texten zu definierten Produktkategorien oder Kundengruppen erfolgen. Ggf. sind auch explorative Verfahren (z. B. Clustering) vorzuschalten, um die für spätere Analysen relevanten Metadatenfelder überhaupt erst zu identifizieren.

Data Warehouse inkl. Metadaten zu unstrukturierten Inhalten

ETL-Tool zum Importieren der Metadaten in das DWH

direkte Extraktion von Metadaten (z.B. manuell gepflegt, Log-Daten…)

Generierung von Metadaten auf Basis von Text-MiningWerkzeugen

Text-Mining-Werkzeuge zur Klassifikation der Inhalte auf Basis definierter Dimensionen

CMS / DMS zur Vorhaltung unstrukturierter Inhalte

Text-Mining-Werkzeuge zur Exploration von Inhaltsbeständen zur Identikation relevanter Dimensionen

Abb. 3.21: Schritte zur Aufbereitung unstrukturierter Inhalte für die integrierte Analyse (Baars/Kemper 2008, S. 139) Mit auf diese Weise integrierten Ansätzen wird eine Navigation in großen Dokumentenbeständen auf Basis der im DWH definierten Dimensionen und Hierarchien möglich, wobei oftmals nicht die konkreten Inhalte selbst im Mittelpunkt stehen sondern die An-

15

Es handelt sich um eine sog. „factless fact table“, vgl. zu diesem Konzept Kimball/Ross 2002, S. 246 f.

121

3 Informationsgenerierung, -speicherung, -distribution und -zugriff zahl an Dokumenten zu bestimmten Ausschnitten in dem multidimensionalen Datenraum. Beispielsweise lassen sich so thematische Entwicklungen in Kundenanfragen verfolgen16, gezielte “Wissenslandkarten“ auf Basis von Einträgen in Erfahrungsdatenbanken ermitteln oder Supportanfragen analysieren. Die Verknüpfbarkeit mit den quantitativen Daten erlaubt darüber hinaus die Herstellung von Zusammenhängen, etwa zwischen der Häufung von Schadensberichten zu einem Produkt und der Absatzentwicklung (Kemper/Baars 2005, S. 125 f.). Grenzen der Auswertung textueller Informationen

Abschließend ist darauf hinzuweisen, dass die Auswertung textueller Daten trotz Fortschritten im Text Mining üblicherweise immer noch mit einem erheblichen manuellen Aufwand verbunden ist. Dieser ist umso größer, je weniger strukturiert die Inhalte sowie der Kontext ihrer Erstellung sind. Während im oben ausgeführten Außendienstbeispiel sowohl die Auswertungsdimensionen, der Grundaufbau der Dokumente als auch die grundsätzlich behandelten Themen bereits im Vorfeld bekannt waren, ist eine Analyse von Kundenemails oder von Blog-Einträgen um einiges herausfordernder.

Web und Process Mining Auf den domänenunabhängig konzipierten Ansätzen des Data und Text Mining setzen diverse anwendungsspezifische Verfahren auf. Web Mining

Aufgrund der hohen Bedeutung webbasierter Inhalte hat speziell das Web Mining Praxisrelevanz. Hierbei können die folgenden Varianten unterschieden werden (Bensberg/Schultz 2001, S. 680): • Web Log Mining (Fokus: Server-Protokolldateien). • Web Content Mining (Fokus: Inhalte von HTML-Dateien). • Web Structure Mining (Fokus: Verlinkung von Webseiten). Für den letzten Punkt wird vermehrt der Einsatz von SocialNetwork-Analysis-Verfahren diskutiert. Bei diesem aus der soziologischen Forschung stammenden Ansatz werden soziale Netzwerke exploriert, d. h. die Interaktionsbeziehungen zwischen Personen und Organisationen (Freeman 2004, S. 3 ff.). Hierfür werden diverse graphentheoretische Algorithmen genutzt, etwa zur Berechnung von Verbundenheits- und Zentralisierungsmaßen

16

122

Ähnlich dem öffentlichen trends.google.com.

Service

„Google

Trends“,

vgl.

3.1 Informationsgenerierung: Analysesysteme oder für die Abgrenzung von eng kooperierenden Gruppen (Wasserman/Faust 1994). Betriebliche Anwendungen finden sich z. B. im Marketing bei der Analyse von Aktivitäten auf Community-Webseiten, Produktbewertungen oder Blogs (WebTagebücher) (Kaiser 2009, S. 379 ff.; Warmbrodt et al. 2008). Vorgeschlagen wird auch ein Einsatz in der Analyse von Organisationsstrukturen, etwa auf Basis von E-Mail- oder Telefondaten, obwohl bei entsprechenden Einsätzen eine Reihe von Fragen bezüglich des tatsächlichen Nutzens sowie der Gewährleistung von Datenschutzanforderungen beantwortet werden muss17. Process Mining

Speziell für den Kontext des Prozessmanagements wurde das Process Mining entwickelt. Hierbei steht die Auswertung von Protokolldaten zur Rekonstruktion und Analyse von Prozessen im Mittelpunkt. Grundlage ist ein integriertes Repository für Prozessdaten („Process Data Warehouse“) (von der Aalst/Weijters 2004, S. 231 ff.; zur Mühlen 2001, S. 261 ff.). Unterschieden wird hierbei zwischen drei Analysetypen (vgl. Song/von der Aalst 2008, S. 301 f.): 1.

Discovery. Hierbei wird ein ex-ante nicht bekannter Prozessablauf nachvollzogen und in einem automatisch generierten Prozessmodell abgebildet.

2.

Conformance. Bei diesem Typ von Analyse werden tatsächliche Prozessabläufe mit Soll-Prozessmodellen oder Sollvorgaben für den Prozessablauf verglichen, um so Abweichungen aufzudecken, etwa eine veränderte Reihenfolge von Testschritten.

3.

Extension. Dieser Ansatz dient der Anreicherung bestehender Prozessmodelle, beispielsweise durch Ergänzung von Leistungsdaten, zur Kennzeichnung von Flaschenhälsen oder zur Extraktion von Entscheidungsregeln („Decision Mining“).

Den Einsatz eines Process-Mining-Werkzeugs zeigt Abb. 3.22. Darstellt wird der Vergleich eines Soll-Prozessablaufes mit den realen Ist-Prozessabläufen im Bereich der Wareneingangsprüfung. Die Prozessdaten stammen dabei von einem sog. Manufacturing Execution System (MES), das im Bereich der Produktionslogistik zur integrierten Maschinendatenerfassung und Prozesssteuerung eingesetzt wird.

17

Noch weiter gehen in Forschungsprojekten pilotierte Einsätze, bei denen spezielle Sensoren persönliche Interaktionen verfolgen, vgl. Putzke et al. 2008.

123

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Definierter Soll-Prozess:

Ist-Prozessabläufe gemäß Process-Mining-Analyse:

Abb. 3.22: Beispiel für den Einsatz eines Process-MiningWerkzeugs: Vergleich eines Soll-Prozesses mit dem Ist-Ablauf (Ludwig/Müller 2008, S. 70). Wie man erkennt, wird der definierte Prozessablauf nicht durchgängig eingehalten – der Eingangstest und der „Overall Thickness Test“ finden häufig parallel statt (vgl. Ludwig/Müller 2008, S. 69 ff.). Der Bereich des Process Mining ist noch relativ jung und in seinen Potentialen noch nicht vollständig durchdrungen. Vor allem der enge Bezug zur Operational Business Intelligence und zum Prozessmanagement lassen die Ansätze jedoch viel versprechend erscheinen (vgl. Kapitel 2.3.3). Besonderer Untersuchungsbedarf besteht noch bei der Integration in bestehende BI-Ansätze und -Modelle, etwa für die Aufdeckung von Zusammenhängen zwischen Prozess- und Ergebnisdaten.

3.1.7

Berichtssysteme

Bericht

Im betrieblichen Kontext wird unter einem Bericht (report) ein Überblick betriebswirtschaftlicher Sachverhalte zu einem abgegrenzten Verantwortungsbereich in aufbereiteter Form verstanden. Die Aufbereitung geschieht dabei in der Regel durch die

124

3.1 Informationsgenerierung: Analysesysteme Visualisierung von Sachzusammenhängen in Diagrammen, um die Aufnahme der Information durch den Empfänger zu verbessern. Die Erzeugung und Bereitstellung von Berichten wird unter dem Begriff des betrieblichen Berichtswesens zusammengefasst (Horváth 2009, S. 540). Eine gängige Unterteilung orientiert sich an den Adressaten der Berichte. Im Rahmen des externen Rechnungswesens (Financial Accounting) ist das Berichtswesen vor allem für börsennotierte Unternehmen wichtig und publiziert in periodischen Abständen die von den Kapitalmärkten geforderten Jahres- und Quartalsberichte. Im Folgenden wird lediglich das interne Berichtswesen als Teilbereich des internen Rechnungswesens (Management Accounting) betrachtet, dessen Aufgabe die Versorgung des Managements mit steuerungsrelevanten Informationen zu deren Arbeitsbereichen ist.

Klassifizierung betrieblicher Berichtssysteme Das betriebliche Berichtswesen setzt sich aus mehreren Prozessen zusammen, die in unterschiedlicher Art und Weise von BIWerkzeugen unterstützt werden (vgl. Abb. 3.23).

Berichtsgestaltung und -erstellung

Berichtsverteilung Berichtsverwaltung Berichtsaufnahme & -diskussion Abb. 3.23: Prozesse des betrieblichen Berichtswesens (modifiziert übernommen aus Leßweng 2003, S. 336) Im Rahmen der Berichtsgestaltung werden das Layout und die empfängerorientierten Inhalte eines Berichts festgelegt. Diese werden bei der Erstellung mit den zeitpunkt- oder periodenbezogenen Daten ausgefüllt und zu dem letztendlichen Bericht zusammengefasst. Das Ergebnis wird an den jeweiligen Empfänger verteilt und falls notwendig durch zusätzliche erläuternde Maßnahmen präsentiert. 125

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Die einmal verfügbaren Berichte werden für eine spätere Nutzung in der Berichtsverwaltung aufgenommen und katalogisiert. Der jeweilige Adressat kann somit direkt nach der Generierung oder auch nachträglich den Bericht einsehen und die Informationen entsprechend aufnehmen. Bei Bedarf kann sich daran eine Diskussion der Inhalte oder Ergebnisse mit Experten aus dem berichteten Fachgebiet anschließen (Leßweng 2003, S. 337). Klassifizierung

Die Berichtssysteme bieten von allen vorgestellten Analysesystemen die größte Erscheinungsvielfalt. Gluchowski unterscheidet in einer ersten Grobklassifikation die aktiven und passiven Berichtssysteme (vgl. Abb. 3.24). Berichtssysteme

Aktive Berichtssysteme

Periodische Berichtssysteme

Aperiodische Berichtssysteme

(Standard-Berichtswesen)

(Früherkennungssysteme)

Passive Berichtssysteme

Ad-hoc-Berichtssysteme

Abb. 3.24: Klassifizierung der Berichtssysteme (in Anlehnung an Gluchowski 1998, S. 1178) Als primäres Unterscheidungskriterium gilt der Auslöser für die Generierung eines Berichts. Aktive Berichtssysteme erstellen nach einer einmaligen Spezifikation der Berichtsinhalte und -formate selbständig die Berichte nach einem festen Muster und stellen sie den Adressaten zu. Dies kann je nach Zeitbezug in zwei Ausprägungen geschehen. Periodische Berichtssysteme

Periodische Berichtssysteme generieren in festen Zeitabständen – in der Regel monatlich – die Berichte. Als älteste und etablierteste Form werden sie auch unter dem Begriff des StandardBerichtswesens zusammengefasst.

Aperiodische Berichtssysteme

In Ergänzung hierzu kommen aperiodische Berichtssysteme zum Einsatz, die bei Überschreitung von Grenzwerten automatisch eine Benachrichtigung generieren. Damit ist gewährleistet, dass wichtige Ereignisse, die ansonsten innerhalb des festen Zeitintervalls des Standard-Berichtswesens unberücksichtigt geblieben wären, zeitnah erkannt werden. Berichtssysteme dieser Art werden vor allem für die betriebliche Früherkennung zur Identifika-

126

3.1 Informationsgenerierung: Analysesysteme tion von strategischen Potenzialen und Gefahren eingesetzt (Schöder/Schiffer 2001; Gehra 2005). Passive Berichtssysteme generieren nicht selbständig Berichte, sondern nur auf konkrete Anforderung eines Benutzers hin. Mit Hilfe solcher Ad-hoc-Berichtssysteme werden individuelle und bedarfsspezifische Berichte generiert. Für die Zusammenstellung der Informationen und des Layouts werden beim Anwender umfassendere IT-Kenntnisse benötigt. Ad-hoc-Berichtssysteme werden in der Praxis oft mit OLAP-Werkzeugen umgesetzt.

Interaktive Reporting-Plattformen Während die frühen Berichtssysteme in den 70er Jahren oft Individualentwicklungen waren, stehen heute für die konkrete Ausgestaltung vielfältige Entwicklungswerkzeuge zur Verfügung. Die umfassendste Form sind Reporting-Plattformen, die alle Berichtsprozesse unterstützen und eine Vereinheitlichung des Berichtswesens ermöglichen (z. B. Gluchowski et al. 2008, S. 205 ff.).

Dimension Dimensionselemente

Entwurfs -bereich

Abb. 3.25: Berichtsgenerator der Firma IBM™ Für die Berichtsgestaltung wird eine Entwurfsumgebung angeboten, in der auch Endbenutzer intuitiv Berichte mit hohen inhaltlichen und grafischen Anforderungen erstellen können. Zu diesem Zweck können per Drag-and-drop-Technik abstrakte Schablonen 127

3 Informationsgenerierung, -speicherung, -distribution und -zugriff erstellt werden. Die Datenauswahl erfolgt über OLAP-Operatoren oder freie Datenrecherchen (vgl. Kapitel 3.1.4). Darüber hinaus können Texte, Grafiken, Daten aus operativen Systemen und multimediale Elemente ergänzt werden. Ein Beispiel eines Berichtsgenerators der Firma IBM™ ist in Abb. 3.25 dargestellt. Das konkrete Berichtsergebnis bei der Erstellung entsteht durch das Befüllen der Schablone aus der dispositiven Datenhaltung. Die periodischen, aperiodischen und Ad-hoc-Berichte können auch als interaktive Berichte generiert werden. Diese Sonderform ermöglicht dem Berichtsempfänger die Auswahl einzelner Parameter, wie beispielsweise die Selektion einer Filiale, um einen Detailbericht zu generieren. Somit können noch zur Laufzeit Berichtsdetails angepasst werden. Darüber hinaus werden alle gängigen strukturierten Formate unterstützt (wie z. B. CSV oder XML). Abb. 3.26 zeigt einen generierten Bericht.

Abb. 3.26: Generierter Bericht unter Verwendung von Werkzeugen der Firma IBM™ Für die Berichtsverteilung, Berichtsdiskussion und Berichtsverwaltung ist das Intranet die primäre Kommunikationsplattform. Mit Hilfe dieser Technologie werden beispielsweise Push-Ansätze der Berichtsverteilung per E-Mail umgesetzt, führungsorientierte Weiterverarbeitungsmöglichkeiten – wie etwa Kommentierung, Wiedervorlage und Weiterleitung – eingebunden und portalba-

128

3.1 Informationsgenerierung: Analysesysteme sierte Verwaltungssysteme umgesetzt (vgl. auch die Einbindung in das BI-Portal in Kapitel 3.3.2).

MIS und EIS Das Management benötigt zur erfolgreichen Führung einer Unternehmung sowohl unternehmensinterne als auch -externe Informationen, deren adäquate Präsentation mit Hilfe von Berichten ermöglicht wird. Wie oben beschrieben, kommen für diese Zwecke verschiedene Werkzeuge oder Plattformen zum Einsatz. Versierte Power-User können diese Instrumente selbständig und eigenverantwortlich einsetzen. Die meisten Mitarbeiter erwarten jedoch spezifisch entwickelte, komfortable Zugangssysteme, die es Endbenutzern erlauben, die generierten Berichte eines Anwendungsbereiches auf einfache Weise aufzurufen, zu erweitern oder auszudrucken. In der Praxis werden die Systeme häufig mit Bezeichnungen belegt, aus denen ihre jeweilige Verwendung deutlich wird. VIS für Vertriebs-Informations-System oder ISTM für Informationssysteme Top Management sollen hier nur als Beispiele dienen. In der Wissenschaft hat sich auch für diese Kategorie von ITbasierten Unterstützungssystemen kein einheitlicher Oberbegriff etablieren können. Einige Autoren fassen beispielsweise diese Systeme als Data Support Systems zusammen (Mertens/Meier 2009, S. 12). Geläufiger – aber ebenfalls nicht außerhalb der Kritik – sind die im vorliegenden Buch verwendeten Begriffe Management Information Systems (MIS) und Executive Information Systems (EIS). Management Information Systems

Die Wurzeln des Begriffs Management Information Systems reichen bis in die 60er Jahre zurück. MIS verstand sich damals als total-integrierter Gesamtansatz der Managementunterstützung, scheiterte jedoch schnell aufgrund von technischen Restriktionen und unrealistischen Annahmen über die Steuerungsmöglichkeiten von Unternehmen. Im amerikanischen Raum etablierte sich der Begriff daraufhin als Sammelbegriff für alle partiellen ITSysteme zur Unterstützung des Managements (Laudon/Laudon 2009, S. 27). Im deutschsprachigen Bereich setzte sich eine engere, hier präferierte Abgrenzung durch. MIS werden hierbei als berichtsorientierte Analysesysteme verstanden, die sich primär interner, operativer Daten bedienen und vor allem auf die Planung, Steuerung und Kontrolle der operativen Wertschöpfungskette ausgerichtet

129

3 Informationsgenerierung, -speicherung, -distribution und -zugriff sind. Die Benutzergruppen sind daher insbesondere das Middle und Lower Management. Executive Information Systems

Die Executive Information Systems (EIS), im Deutschen auch als Führungsinformationssysteme (FIS) bekannt, besitzen eine konsequente Ausrichtung auf das Top Management. Ein EIS kann definiert werden als ein „unternehmensspezifisches und bereichsübergreifendes […] integratives und dynamisches Informationssystem zur informationellen Unterstützung der obersten Managementebene, das über ein großes Maß an Flexibilität und einen hohen Bedienungskomfort verfügt“ (Ballensiefen 2000, S. 54). Vollständig ausblendbare Kopf- und Menüleisten schaffen Platz für Inhalt

Portlets (Reports) sind frei platzierbar.

Verbindung von strukturierter und unstrukturierter Information

Verschiedene Sichten eines Portlets (Grafik, Tabelle)

Reportauswahl (PortletStore) mit Such- und Blätterfunktion

Abb. 3.27: bms:roi – ein EIS/MIS der Bayer MaterialScience AG™ Moderne EIS und MIS ähneln sich häufig im äußeren Erscheinungsbild, also in der Form der Präsentation und der Benutzungsoberfläche. In Abgrenzung zum MIS präsentieren EIS jedoch primär hoch verdichtete, steuerungsrelevante interne Daten sowie unternehmensexterne Informationen, wobei vermehrt auch unstrukturierte Informationen integrierbar sein sollten. Abb. 3.27 zeigt die Benutzeroberfläche eines benutzerfreundlichen Informationssystems für das Management der Firma Bayer MaterialScience AG. Hervorzuheben bei dieser Lösung ist v. a. die hohe Gestaltungsflexibilität, die es den Managern erlaubt, Informationsbereitstellung und -aufbereitung schnell an die sich 130

3.1 Informationsgenerierung: Analysesysteme wandelnden, individuellen Anforderungen anzupassen. Das betrifft die Zusammenstellung von Inhalten ebenso wie deren Anordnung sowie die Auswahl verschiedener Sichten auf einen selektieren Sachverhalt. Neben klassischen Reporting-Daten werden über Information-Retrieval-Komponenten auch unstrukturierte Informationen eingebunden. Technisch wird hierbei ein Ansatz gewählt, bei dem die einzelnen Inhalte über sog. PortletKomponenten in die Benutzeroberfläche eingebunden werden. Dieser Ansatz wird in Kapitel 3.3.3 weiter vertieft.

3.1.8

Konzeptorientierte Systeme Konzeptorientierte Systeme unterscheiden sich zu den o. a. generischen Basissystemen insbesondere durch die IT-basierte Umsetzung eines umfangreicheren, betriebswirtschaftlichen Verfahrens. Sie sind demnach implementierungsfähige, sinnvoll konstruierte Standardlösungen, die sich durchaus in weiten Teilen der beschriebenen Basissysteme bedienen können. Wie auch Standardlösungen in operativen Kontexten – z. B. in den ERPSystemen – sind sie jedoch stets unternehmensindividuell anzupassen, also auf die konkreten Anforderungen der Organisationen auszurichten (customization). Im Folgenden werden mit der Balanced Scorecard, der Planung, der Konsolidierung und dem Wertorientierten Management anerkannte betriebswirtschaftliche Konzepte und deren ITUnterstützung beispielhaft diskutiert.

Balanced Scorecard Seit der ersten Veröffentlichung 1992 durch Kaplan und Norton hat sich die Balanced Scorecard (BSC) zu einem etablierten Managementkonzept entwickelt (Kaplan/Norton 1992; Kaplan/Norton 2001). In der heutigen Form dient die BSC der Operationalisierung der Unternehmensstrategie durch eine systematische Erarbeitung, Kommunikation und Kontrolle der Unternehmensziele. Um eine ausgeglichene Steuerung der Organisation zu gewährleisten, werden mehrere Blickwinkel berücksichtigt. Neben der klassischen finanziellen Sichtweise sieht das ursprüngliche Konzept drei weitere Perspektiven vor: Die Kunden-, die Prozesssowie die Lern- und Entwicklungsperspektive. Diese Vorgabe ist allerdings nur als bewährtes Basisgerüst zu verstehen und kann durch unternehmensindividuelle Perspektiven ergänzt oder ersetzt werden. 131

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Für jede der Perspektiven werden strategische Ziele definiert. Jedes Ziel wird mit mindestens einer Kennzahl versehen, die als Indikator für die Zielerreichung gilt. Um eine Kontrolle zu ermöglichen, werden Vorgaben für Zielwerte der Kennzahlen festgelegt. Für die Erreichung der Ziele werden konkrete Maßnahmen definiert und in die BSC aufgenommen. Die Abb. 3.28 zeigt die Grundidee der Balanced Scorecard. Strategy Maps

Um eine anschauliche Beschreibung der Strategie zu ermöglichen, werden die mutmaßlichen Ursache-Wirkungs-Beziehungen zwischen den Zielen grafisch abgebildet. Diese „Strategy Maps“ sind demnach nicht als mathematische Abbildung der Zusammenhänge gedacht, sondern haben ihren Fokus auf der Schaffung eines gemeinsamen Verständnisses der Strategie (Kaplan/Norton 2004).

Finanziell Kernfrage: Wie sollen wir gegenüber Teilhabern auftreten, um finanziellen Erfolg zu haben? Ziele Æ Kennzahlen Æ Vorgaben Æ Maßnahmen Kunde

Interne Geschäftsprozesse

Kernfrage: Wie sollen wir gegenüber unseren Kunden auftreten, um unsere Vision zu verwirklichen?

Vision und Strategie

Kernfrage: In welchen Geschäftsprozessen müssen wir die Besten sein, um unsere Teilhaber und Kunden zu befriedigen? Ziele Æ Kennzahlen Æ Vorgaben Æ Maßnahmen

Ziele Æ Kennzahlen Æ Vorgaben Æ Maßnahmen Lernen und Entwicklung Kernfrage: Wie können wir unsere Veränderungs- und Wachstumspotenziale fördern, um unsere Vision zu verwirklichen? Ziele Æ Kennzahlen Æ Vorgaben Æ Maßnahmen

Abb. 3.28: Perspektiven der Balanced Scorecard (modifiziert übernommen aus Kaplan/Norton 1996, S. 76) BSC-Hierarchie (Kaskade)

132

Eine unternehmensweite Balanced Scorecard wird in der Regel Top-Down auf nachgelagerte Organisationseinheiten übertragen, so dass eine BSC-Kaskade entsteht. Neben dieser hierarchischen Verknüpfung werden auch Funktionsbereiche wie das Personal-

3.1 Informationsgenerierung: Analysesysteme wesen (Kolb 2008, S. 63 ff., Grötzinger/Uepping (Hrsg.) 2001) und die IT (Kesten et al. 2007, S. 229 ff.; Bernhard/Blomer (Hrsg.) 2003) über eigene BSCs in das Managementsystem eingebunden. Selbstverständlich lässt sich der BSC-Ansatz mit Hilfe unternehSpezielle BSCmensspezifischer Eigenentwicklungen auf Basis von allgemeinen Software vs. Eigenentwicklung BI-Werkzeugen (z. B. Wehrle/Heinzelmann 2004) erarbeiten, meist wird jedoch die Nutzung spezieller BSC-Software (Marr/Neely 2003; Bange et al. 2004) präferiert. Abb. 3.29 zeigt beispielhaft eine mit dem BSC-Werkzeug STRAT&GO Business Dashboard der Firma PROCOS Professional Controlling Systems AG realisierte BSC-Anwendung.

Abb. 3.29: Balanced-Scorecard-Anwendung auf Basis des Werkzeugs STRAT&GO Business Dashboard™ der Firma PROCOS™ 18 Die Balanced Scorecard Collaborative, eine Initiative der BSCErfinder Kaplan und Norton, bietet für die letzte Kategorie eine

18 URL: http://www.procos.com/de/img/pro_mod_mod_pco_04.gif

133

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Zertifizierung an, die bestimmte funktionale Mindeststandards voraussetzt (BSCol 2000): 1. Balanced Scorecard Design Das Werkzeug kann die Grundlogik einer BSC mit ihren Perspektiven, strategischen Zielen, Kennzahlen, Vorgaben (Zielwerten), Ursache-Wirkungs-Beziehungen und strategischen Maßnahmen abbilden (z. B. Meier et al. 2003, S. 115 ff.). 2. Strategiekommunikation Eine der Hauptaufgaben der Balanced Scorecard ist die Beschreibung und Abstimmung der Strategie über die gesamte Organisation. Aus diesem Grund muss werkzeugseitig die Dokumentation und Kommunikation einer ausführlichen Beschreibung der BSC-Elemente (Ziele, Kennzahlen, Vorgaben, etc.) unterstützt werden. 3. Monitoring der Maßnahmenumsetzung Maßnahmen können mehreren strategischen Zielen zugeordnet werden und durch Warnmechanismen überwacht werden (Exception Reporting). 4. Feedback und Lernen Um ein strategisches Lernen für den Entscheider zu ermöglichen, sind Berichte über die Kennzahlen und Analysemöglichkeiten über historische Daten zur Verfügung zu stellen (vgl. auch Kapitel 3.1.7). Phasen der BSCErstellung

Die Rolle und der Umfang der eingesetzten Werkzeuge sind stark von der jeweiligen Phase der BSC-Einführung abhängig. Hierbei können die drei Phasen der BSC-Erstellung, BSCImplementierung und die dauerhafte Nutzung der BSC als Managementsystem unterschieden werden (Horváth & Partners 2007 (Hrsg.), S. 337).

Integrationsstufe: BSC-Erstellung

Im Rahmen der BSC-Erstellung stehen die Dokumentation der Elemente und die prinzipielle Abbildung der Balanced Scorecard im Vordergrund. Da in dieser frühen Phase lediglich ein kleiner Benutzerkreis involviert ist, wird i. d. R. noch keine Anbindung an die Datenbereitstellungsebene benötigt.

Integrationsstufe: BSCImplementierung

Nach erfolgreicher Erstellung folgt die Phase der BSCImplementierung, in der die BSC-Nutzung im betrieblichen Ablauf etabliert wird. Hierfür wird bereits eine verteilte Anwendung benötigt, die eine Verknüpfung mehrerer Scorecards ermöglicht. Um die Zielerreichung überprüfen zu können, werden in perio-

134

3.1 Informationsgenerierung: Analysesysteme dischen Abständen die aktuellen Werte der Kennzahlen benötigt. Im Idealfall werden diese über einen Data Mart bezogen. Da die BSC aber auch qualitative Ziele enthält, muss die Möglichkeit der manuellen Eingabe von Werten gegeben sein. Die grafische Darstellung einer Strategy Map gehört ebenfalls zu den Anforderungen dieser Integrationsstufe. Integrationsstufe: Etablierung der BSC als Managementsystem

In der dritten und letzten Phase steht die dauerhafte Nutzung der BSC als Managementsystem im Vordergrund. Hierbei ist vor allen Dingen die flächendeckende Verfügbarkeit der BSC im Unternehmen wichtig, die i. d. R. über eine Portal-Integration realisiert wird.

Planung Planung und Budgetierung sind etablierte betriebswirtschaftliche Führungsinstrumente, mit deren Hilfe kurz- und langfristige Ziele definiert und innerhalb der Organisation koordiniert werden. Die Planung versteht sich dabei als systematische Auseinandersetzung mit der Zukunft und dient der Erfolgssicherung des Unternehmens. Dies geschieht durch die Festlegung eines Handlungsrahmens, der auf die Umsetzung der Unternehmensstrategie ausgerichtet und auf die erwartete Umwelt abgestimmt ist. Die Operationalisierung erfolgt in Budgets, die einen in Geldeinheiten bewerteten Plan aller Einnahmen und Ausgaben der voraussichtlichen Aktivitäten für eine bestimmte Organisationseinheit und einen definierten Zeitraum darstellen. Planungshorizonte

Die Unternehmensplanung lässt sich über mehrere Kriterien differenzieren (z. B. Horváth 2009, S. 165 ff.), wobei die geläufigste Unterscheidung die Aufteilung nach Planungshorizonten in strategische, taktische und operative Planung ist. Im Rahmen der strategischen Planung wird die grundsätzliche Ausrichtung des Unternehmens festgelegt und ein Zeithorizont von mehr als fünf Jahren betrachtet (Bea/Haas 2005, S. 50 ff.). Die taktische Planung erarbeitet konkrete operationale Ziele für das Gesamtunternehmen und legt Ressourcen und Maßnahmen zur Zielerreichung in den nächsten zwei bis fünf Jahren fest. Die operative Planung fokussiert den Zeitraum bis zu einem Jahr und beschäftigt sich mit der konkreten quantitativen Planung der wertschöpfenden Prozesse.

Planungsarten

Jeder dieser Planungshorizonte besteht aus mehreren Detailplanungen, die als Planungsarten bezeichnet werden (Hahn/ Hungenberg 2001, S. 360 ff.; S. 462 ff.). Die operative Planung orientiert sich dabei an den Funktionsbereichen und führt bei135

3 Informationsgenerierung, -speicherung, -distribution und -zugriff spielsweise eine Absatzplanung für das Marketing und den Vertrieb oder eine Beschaffungsplanung für den Einkauf durch (Mertens et al. 2003a, S. 297 ff.). Planungsebenen

Je nach Planungsart können einzelne Planungsebenen unterschieden werden. Bei einer Bilanzplanung im Konzern werden z. B. Planungen über die Ebenen der Gesellschaften, Geschäftsbereiche und des Gesamtunternehmens durchgeführt. Eine Absatzplanung hingegen kann über Sparten, Produktgruppen oder einzelne Produkte erstellt werden.

Metaplanung

Im Rahmen der Metaplanung werden unternehmensindividuell die einzelnen Planungshorizonte, -arten und -ebenen inklusive deren Interdependenzen in Form einer Planungsstruktur festgelegt. Dadurch ergibt sich für jedes Unternehmen ein individuelles Planungssystem, das aus miteinander vernetzten Teilplanungen besteht. So gehen beispielsweise die Umsatz-, Erfolgs- und Investitionsplanungen in die langfristige Finanzplanung ein (Reichmann 2006, S. 259).

Standardwerkzeuge & Planungsplattformen

Planungswerkzeuge haben die Aufgabe, das Planungssystem abzubilden und die Prozesse zur Planungsdurchführung zu unterstützen. Je nach Ausrichtung und Leistungsumfang können sie in Standardwerkzeuge und Planungsplattformen unterschieden werden (Dahnken et al. 2004, S. 55 ff.). Standardwerkzeuge sind hochgradig normiert und werden bereits mit konkreten Planungsvorlagen ausgeliefert. Dadurch können sie schnell im Unternehmen eingesetzt werden, sind aber in ihrer Flexibilität eingeschränkt. Planungsplattformen hingegen bieten eine offene Entwicklungsumgebung für komplexe unternehmensindividuelle Planungsmodelle. Klassische Planungsarten werden als Vorlage zur Verfügung gestellt, können aber beliebig angepasst und ergänzt werden (Meier et al. 2003, S. 90 ff.).

Funktionsumfang Der Funktionsumfang von Planungswerkzeugen kann je nach Produktphilosophie sehr unterschiedlich ausfallen. Basisfunktionalitäten sind die Erfassung und Speicherung der Planungsdaten, die Unterstützung durch Planungsfunktionen, eine Integration und Abgleichen der Teilpläne und die Unterstützung des Planungsprozesses bei verteilter Planung. Darüber hinaus können Simulationen die Planungserstellung unterstützen. Erfassung und Speicherung der Planungsdaten

136

Wichtige Grundlage für die Planung ist die Erfassung und Speicherung der Plandaten. Hierzu kommen in aller Regel Benutzungsoberflächen zum Einsatz, die sich an gängigen Tabellenkalkulationsprogrammen wie MS-Excel™ orientieren oder auf ihnen aufbauen. Alternativ bietet sich bei einer verteilten Pla-

3.1 Informationsgenerierung: Analysesysteme nung – z. B. in einem Konzern – die Nutzung einer webbasierten Oberfläche an. Die Speicherung erfolgt in der Datenbereitstellungsebene je nach Umfang der Planungsanwendung in einem Data Mart, DWH oder ODS. Planungsfunktionen

Planungsfunktionen sind allgemeine Verfahren zur Eingabe, Änderung und Generierung von Plandaten. Beispielsweise können durch eine Kopierfunktion Plan-Werte als Vorlage für IstWerte übertragen werden oder durch eine Prognosefunktion aus den Ist-Zahlen der Vorperiode eine Vorlage für die Plan-Zahlen der aktuellen Periode erstellt werden (Meier et al. 2003, S. 100 f.).

Integration und Abgleichen der Teilpläne

Nachdem die Daten der einzelnen Teilpläne erfasst wurden, erfolgt eine Integration der Ergebnisse. Durch den Abgleich der Daten werden Inkonsistenzen und Widersprüche aufgedeckt, die zu einer Korrektur einzelner Teilpläne führen können. Damit wird gewährleistet, dass die Gesamtunternehmensziele erreichbar sind und jede Detailplanung darauf abgestimmt ist. Bei Teilplanungen, die zentral durchgeführt werden, kann eine Konsistenzprüfung bereits bei der Dateneingabe durchgeführt werden. Bei mehrstufigen Planungen mit mehreren Planern kann ein Abgleich erst am Ende der Planungsrunde durchgeführt werden und kann somit in einem neuen Planungsdurchlauf resultieren.

Planungsprozess

Die Durchführung der Planung orientiert sich an einem Planungsprozess (Dahnken et al. 2004, S. 9 ff.; Horváth 2009, S. 157 ff.). Die Planungsrichtung kann vom Top Management ausgehen (top-down) oder sich an der Zusammenführung der Teilpläne der untergeordneten Einheiten orientieren (bottom-up). In der Praxis ist vor allem die Kombination beider Ansätze im Gegenstrom-Verfahren gängig, wobei im Dialog die endgültigen Zahlen in mehreren Planungszyklen ausgehandelt werden (Horváth 2009, S. 187 f.). Bei solch umfangreichen Planungen unterstützen Planungswerkzeuge die Koordination innerhalb der einzelnen Phasen der Datenerfassung, Validierung und Integration durch eine Überwachung des Bearbeitungsfortschritts. Hierbei kommen z. B. Status- und Trackingsysteme mit automatischen Benachrichtigungen zum Einsatz (Meier et al. 2003, S. 104 f.).

Simulation

Um die Ziel- und Entscheidungsfindung im Rahmen der Planung zu verbessern, können verschiedene Arten der Simulation eingesetzt werden (Mertens et al. 2003b). Unter Annahme bestimmter Wirkungszusammenhänge werden einzelne Faktoren und deren Auswirkungen auf Planungswerte durchgerechnet. Im Rahmen 137

3 Informationsgenerierung, -speicherung, -distribution und -zugriff von statischen Simulationen werden vor allem What-if- und How-to-achieve-Simulationen unterschieden. Bei der ersten Fragestellung steht die Auswirkung eines Ereignisses oder einer Maßnahme im Vordergrund, während die zweite Fragestellung sich mit der Erreichung eines Ziels beschäftigt. Für komplexe dynamische Simulationen existieren weitergehende Ansätze wie z. B. Systems Dynamics (Sterman 2000). Advanced Planning Systems

Eine spezielle Variante von Planungssystemen für den Bereich des Supply Chain Management sind die sog. Advanced Planning Systems (APS), die Komponenten zur Planung und Simulation von Liefernetzwerken beinhalten (Betge 2006, S. 4; Meyr et al. 2008, S. 349 ff.).

Konsolidierung Ein Konzern fasst mehrere abhängige Unternehmen unter einer einheitlichen Leitung zusammen. Um einen wahrheitsgemäßen Überblick der Vermögens-, Finanz- und Ertragslage des Konzerns zu gewährleisten, werden umfangreiche gesetzliche Anforderungen an einen Konzernabschluss gestellt. Im Rahmen der Konsolidierung werden die Abschlüsse der Konzernunternehmen verdichtet und konzerninterne Vorgänge aufgerechnet. Zur Vermeidung von Doppelzählungen werden eine Kapital-, Schulden- und Aufwands- und Ertragskonsolidierung sowie eine Zwischenergebniseliminierung durchgeführt (Wöhe/Döring 2008, S. 868 ff.). Das Resultat ist ein bereinigter Konzernabschluss, der aus Bilanz, Gewinn- und Verlustrechnung (GuV) und Anhang besteht. Ist ein Konzern international an mehreren Börsen gelistet, ist in aller Regel die Erstellung mehrerer Konzernabschlüsse nach verschiedenen Rechnungslegungsstandards erforderlich. Neben dem deutschen Handelsgesetzbuch (HGB) spielen vor allem die „International Accounting Standards/International Financial Reporting Standards“ (IAS/IFRS, seit 2005 für alle börsennotierten europäischen Unternehmen verpflichtend) und die US Generally Accepted Accounting Principles (US-GAAP, USA) eine wichtige Rolle. Neben der gesetzlichen Konsolidierung kann auch eine Managementkonsolidierung durchgeführt werden, deren Aufgabe die Aggregation von steuerungsrelevanten Informationen ist. Konzeptorientierte BI-Systeme unterstützen meist sowohl die gesetzliche als auch die Managementkonsolidierung, wobei – wie auch bei der BSC – nicht Eigenentwicklungen dominieren,

138

3.1 Informationsgenerierung: Analysesysteme sondern primär am Markt erwerbbare Standardwerkzeuge zum Einsatz kommen (Dahnken et al. 2003). Hierbei müssen die Werkzeuge insbesondere die folgenden Phasen der Konsolidierungsprozesse wirksam unterstützen können (Meier et al. 2003, S. 107 ff.): 1. Modellierung der Konsolidierungsstrukturen Die Grundlage für die Konsolidierung bildet die Abgrenzung der einzubeziehenden Unternehmen in einem Konsolidierungskreis. Hierbei ist es wichtig, vor allem die Beteiligungsstrukturen korrekt abzubilden. 2. Erfassung, Monitoring und Aufbereitung der Meldedaten Ein bedeutsamer Bestandteil von Konsolidierungssystemen ist die Strukturierung und Organisation des Meldeprozesses der Abschlussdaten der Konzernunternehmen. Das Monitoring des Status ermöglicht eine schnellere Reaktion auf verspätete Meldungen. Durch eine Währungsumrechnung kann die Umstellung auf Konzernwährung automatisch vorgenommen werden. Ebenso kann die Datenqualität durch die automatische Anwendung von Validierungen verbessert werden, in dem die Daten auf Plausibilität und Konsistenz überprüft werden. 3. Konsolidierung der Meldedaten Nachdem alle Meldedaten bereinigt vorliegen, findet die eigentliche Konsolidierung im engeren Sinne statt. Darunter fallen Maßnahmen wie die Kapitalkonsolidierung, die Schuldenkonsolidierung und die Zwischenergebniseliminierung.

Wertorientiertes Management Im wertorientierten Management (Value Based Management, VBM) steht eine Harmonisierung von Unternehmenssicht und Kapitalmarktsicht im Vordergrund. Die klassischen Kennzahlen zur Steuerung eines Unternehmens, wie z. B. Umsatzrentabilität oder Return on Investment, berücksichtigen nicht in ausreichendem Maße die Interessen der Anteilseigner eines Unternehmens. So kann die durchaus paradoxe Situation entstehen, dass in der Bilanz faktisch ein Gewinn ausgewiesen wird, nach Berücksichtigung der Kapitalkosten (im Sinne von Opportunitätskosten) aber keine Mindestrendite erwirtschaftet wurde. Diesen Sachverhalt illustrieren Copeland et al. 2002 in einer Gegenüberstellung der Sichtweisen des Managements und der Eigentümer bzw. Investoren (vgl. Abb. 3.30). 139

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Sichtweise des Management

Sichtweise der Eigentümer bzw. Investoren

+

+

Wertsteigerung (materieller Wertzuwachs) Mindestrendite

Gewinn Kapitalkosten

Verlust Bilanzielles Ergebnis

Verlust Ergebnis nach Berücksichtigung der Kapitalkosten

Abb. 3.30: Berücksichtung der Kapitalkosten (Copeland et al. 2002, S. 15) Um diesen Missstand zu beheben, propagiert der Ansatz des „Shareholder Value“ eine Unternehmenssteuerung, welche die Anforderungen der Anteilseigner berücksichtigt (Rappaport 1999). Als Grundlage hierfür dient die Berechnung eines Unternehmenswertes auf Basis von speziellen Kennzahlen: • Discounted Cash Flow (DCF, Rappaport 1999) • Economic Value Added™ (EVA™, Stewart 1999) • Cash Value Added (CVA) und Cashflow Return on Investment (CFROI, Stelter 1999, S. 233 f.) Während die zugrunde liegenden Basiselemente der Kennzahlen teilweise sehr unterschiedlich sind, weisen sie jedoch Strukturähnlichkeiten auf, die ihre Abbildung in Werttreiberbäumen erlauben (vgl. Abb. 3.31). In diesen Werttreiberbäumen stellen die generischen Werttreiber branchen- und betriebsunabhängige Größen dar. Die geschäftsspezifischen Werttreiber hingegen sind unternehmensindividuelle Größen, die erhoben und harmonisiert werden müssen (Mertens/Meier 2009, S. 225 ff.). Konzeptorientierte BI-Systeme – meist entwickelt mit entsprechenden Standardwerkzeugen – unterstützen hierbei die Definition, Darstellung und Simulation der Werttreiberbäume, wobei die benötigten Daten aus der dispositiven Datenbereitstellungsebene bezogen oder manuell eingegeben werden.

140

3.2 Informationsdistribution: Content und Document Management Einfluss

Wirkung

Geschäftsspezifische Werttreiber Verkaufte Stückzahl

Generische Werttreiber

Umsatzerlöse Umsatzwachstum

Marktanteil Umsatzkosten Image

Durchschnittlicher Marktpreis

Produktionskosten

Qualität

Stückpreis

EBITDA

NettoCashflow

Betrieblicher Aufwand Steuern Wertminderung/ Abschreibung

FreeCashflow

Shareholder Value

Investitionen in Anlagevermögen Betriebliche Investitionen

Bestand an Rohstoffen Investitionen in Umlaufvermögen Bestand an Halbfertigerzeugnissen Kapitalkosten

Diskontsatz

Bestand an Fertigwaren

Forderungen

Abb. 3.31: Generische und geschäftsspezifische Wertetreiber (Meier et al. 2003, S. 22) Das wertorientierte Management stellt einen innovativen, komplexen Ansatz dar, der sich zurzeit in Wissenschaft und Praxis großer Aufmerksamkeit erfreut. Zur Vertiefung der Thematik sei an dieser Stelle auf die einschlägige Literatur verwiesen (Copeland et al. 2002; Rappaport 1999; Meier et al. 2003, S. 19 ff. u. 124 ff.).

3.2

Informationsdistribution: Content und Document Management Bei der Entwicklung und Nutzung von BI-Lösungen wird häufig wertvolles Wissen aufgebaut, dessen zielgerechte Wiederverwendung erhebliche Effizienzgewinne verspricht. Profitieren können einerseits die Nutzer selbst, die durch den Rückgriff auf vorbereitete Ergebnisse Doppelarbeit vermeiden. Andererseits werden Entwickler bei der Realisierung neuer oder der Konsolidierung bestehender Anwendungen unterstützt. Relevante Inhalte betreffen zum einen die konkreten Ergebnisse von Analysen, beispielsweise eine mit Hilfe von Data-MiningVerfahren erzeugte Kundenklassifikation, und zum anderen deren Vorbereitung und Durchführung. Für letzteres können beispielsweise Anleitungen zur Umsetzung bestimmter Analysen,

141

3 Informationsgenerierung, -speicherung, -distribution und -zugriff parametrisierbare Analysemodelle oder auch fertige Lösungsentwürfe hinterlegt werden. Zur systematischen Verbreitung solcher Inhalte kann auf Werkzeuge für das betriebliche Wissensmanagement zurückgegriffen werden, wobei insbesondere der Klasse der Content und Document Management Systems eine große Bedeutung zukommt (Baars 2006, S. 409 ff.). Diese werden im Folgenden zunächst eingeordnet und charakterisiert, um dann im Anschluss die zu verteilenden Inhalte und ihre Aufbereitung weiter zu vertiefen. Besonders gewürdigt werden der Einsatz von maschinenlesbaren Datenaustauschformaten und von „Templates“ als Ansätze zur Erhöhung des Integrations- und Automatisierungsgrades. Hierbei wird unter einem Template eine parametrisierbare Vorlage verstanden, in der ein bewährter Lösungsentwurf in wiederverwendbarer Form hinterlegt ist19.

3.2.1

Werkzeuge für das betriebliche Wissensmanagement

Begriffshierarchie

Für eine systematische Einordnung des Einsatzes von Wissensmanagementwerkzeugen im BI-Kontext ist zunächst eine Begriffsklärung erforderlich. Der Wissensbegriff ist aufgrund seiner umgangssprachlichen Verwendung und der Behandlung in verschiedenen wissenschaftlichen Disziplinen ein viel diskutierter und heterogen verwendeter Begriff (z. B. Krcmar 2009, S. 623 ff.). In der Wirtschaftsinformatik wird hierfür häufig auf einen Ansatz aus der Semiotik20 zurückgegriffen. Die Abb. 3.32 zeigt eine Hierarchisierung der Begriffe „Zeichen“, „Daten“, „Informationen“ und „Wissen“.

Wissen

142

Wissen bildet die höchste Ebene und wird definiert als die „Gesamtheit der Kenntnisse und Fähigkeiten, die Individuen zur Lösung von Problemen einsetzen“ (Probst et al. 2010, S. 23). Im Vergleich zur Information wird bei Wissen der übergeordnete Begründungszusammenhang mit einbezogen (Pragmatik). Informationen fehlt diese Eigenschaft. Sie besitzen zwar kontextabhängige Bedeutung (Semantik), fokussieren aber lediglich ein-

19

Konzepte zur Umsetzung eines Template-Ansatzes finden sich bei verschiedenen größeren Werkzeuganbietern – allerdings unter sehr unterschiedlichen Bezeichnungen.

20

„Lehre von den Zeichensystemen (z. B. Verkehrszeichen, Bilderschrift, Formeln, Sprache) in ihren Beziehungen zu den dargestellten Gegenständen“ (Wahrig-Burfeind 2006, S. 1348).

3.2 Informationsdistribution: Content und Document Management zelne Aspekte eines Themenbereichs. Werden einzelne Zeichen lediglich aufgrund vorgegebener Regeln (Syntax) zusammengesetzt, spricht man von Daten.

Begrifflichkeiten

Beispiel Bewertung anhand Erfahrung & Vernetzung: Für eine Führungsposition sind 22 Jahre zu jung.

Wissen Pragmatik

Alter eines Bewerbers für eine Führungsposition: 22 Jahre

Informationen Semantik

Daten

22 Jahre Syntax

Zeichen

2, 2, J, a, h, …

Abb. 3.32: Abgrenzung des Wissensbegriffs (in Anlehnung an Rehäuser und Krcmar 1996, S. 6)

Wissensmanagement

Wissensmanagementsysteme

Kodifizierbares Wissen

Es liegt auf der Hand, dass Unternehmen generell daran interessiert sind, das betriebliche Wissen im Unternehmen zu dokumentieren, zu speichern und allen interessierten Mitarbeitern im Unternehmen verfügbar zu machen. Dieser Themenbereich wird üblicherweise unter der Überschrift Wissensmanagement (Knowledge Management) zusammengefasst und versteht sich als Summe aller organisatorischen und technischen Maßnahmen zur Unterstützung der o. a. Aufgabenfelder (Hansen/Neumann 2009, S. 576 f.) Wissensmanagementsysteme liefern als technische Komponenten die IT-basierte Unterstützung für das betriebliche Wissensmanagement, wobei die konkreten Ausprägungen der Wissensmanagementsysteme maßgeblich von den unternehmensspezifischen Rahmenbedingungen abhängen. Insbesondere spielt in diesem Zusammenhang der Grad der Kodifizierbarkeit des Wissens eine bedeutende Rolle. Hierunter wird das Wissen verstanden, das in strukturierter Form auf Datenträgern abgelegt und somit in dokumentierter Form entsprechenden Benutzerkreisen zugänglich gemacht werden kann.

143

3 Informationsgenerierung, -speicherung, -distribution und -zugriff

Implizites Wissen

Systeme zur Distribution kodifizierbaren Wissens

Als Komplement zu kodifizierbarem Wissen existiert Wissen, das sich in den Köpfen der Mitarbeiter manifestiert und aufgrund seiner Komplexität und Unstrukturiertheit nicht oder nur mit hohem Aufwand in elektronischer Form abgelegt werden kann. Der Austausch dieses Wissens, das auch als implizites Wissen bezeichnet wird, ist somit primär durch die direkte zwischenmenschliche Kommunikation bzw. Interaktion erreichbar. Die Informationstechnologie kann hier vor allem die Suche nach geeigneten Gesprächs- bzw. Kooperationspartnern erleichtern (z. B. mit Hilfe von sog. Skill-Management-Systemen oder mit ITgestützten sozialen Netzwerken) bzw. den Kommunikationsprozess selbst unterstützen (z. B. mit Hilfe von Video- oder Webkonferenzsystemen). Für die Ablage, die Aufbereitung, die Suche und die Weitergabe kodifizierbaren Wissens wird ein breites Spektrum an Systemen eingesetzt (Bahrs et al. 2009, S. 10 ff.). In der aktuellen Diskussion werden häufig Systeme für die Hinterlegung und Abfrage semantischer Metadaten zu Textinhalten (Technologien des „Semantic Web“, vgl. z. B. Mertens et al. 2009; Haak/Hahn 2005) oder für den gemeinsamen Aufbau benutzereditierbarer Hypertext-Sammlungen („Wikis“) thematisiert (König 2009)21. Diese Systemklassen können auch zur Unterstützung der Distribution von BI-Wissen eingesetzt werden, etwa bei der Dokumentation von Analysemodellen, in der Kommunikation von Werkzeugerfahrungen, zur Spezifikation von Vorgehensmodellen oder für die kooperative Generierung inhaltlicher Metadaten. Als Werkzeuge zur Verwaltung kodifizierten Wissens haben sich Content-Management-Systeme (CMS) und Document-Management-Systeme (DMS) etabliert, die für die Handhabung größerer Bestände unstrukturierter Daten ausgelegt sind. Entsprechend hoch ist der Stellenwert dieser Systemklassen beim Aufbau integrierter BI- und Wissensmanagement-Lösungen (Bange 2004; Becker et al. 2002; Klesse et al. 2003; Priebe et al. 2003). Die Integration wird zusätzlich dadurch erleichtert, dass mehrere

21

144

Derartige Ansätze werden auch aufgrund ihres dezentralen, benutzerorientierten und interaktiven Charakters in Abgrenzung zu traditionellen webbasierten Ansätzen unter der Überschrift „Web 2.0“ diskutiert. Der durch einen Beitrag O’Reilly (2005) bekannt gewordene Begriff ist allerdings zum einen stark marketinggetrieben und zum anderen nicht trennscharf, da hier inhaltliche und technische Aspekte vermengt werden.

3.2 Informationsdistribution: Content und Document Management größere End-to-End-Anbieter BI- und CMS-Werkzeuge als zusammengehörende Produktsuiten vermarkten.

3.2.2

Content- und Document-Management-Systeme im BI-Kontext Sowohl Content als auch Document Management Systems unterstützen den Umgang mit unstrukturierten Daten. Document Management Systeme (DMS) wurden dabei ursprünglich zur effizienteren Handhabung papiergebundener Informationen entwickelt und bieten Funktionalität für die Erfassung, Archivierung, Versionierung und Bereitstellung digitalisierter Dokumente. Content Management Systems (CMS) haben hingegen einen anderen Fokus – sie sind primär für den Umgang mit heterogenen elektronischen Medienformaten ausgelegt, etwa für numerische Daten, Texte, Grafiken, Bilder, Audio- oder Videosequenzen. Eine Besonderheit von CMS ist, dass zur Mehrfachverwendbarkeit der Daten eine strikte Trennung von Inhalt, Struktur und Layout erfolgt. CMS unterstützen insbesondere das Einfügen, Aktualisieren, Archivieren von Beiträgen sowie deren Aufbereitung und die inhaltliche Zusammenstellung im Verwendungsfall. Hierfür unterstützen sie u. a. Verfahren zur Versionskontrolle, zur Berechtigungsvergabe sowie zur Qualitätssicherung. Mit der Durchsetzung webbasierter Infrastrukturen wachsen die Systemklassen zunehmend zusammen – DMS werden um CMS-Funktionen ergänzt und umgekehrt.

Datenhaltungsrolle

Quellsystemrolle

In einem BI-Kontext können CMS und DMS verschiedene Rollen übernehmen (vgl. Abb. 3.32): In ihrer Rolle als Datenhaltungssysteme für unstrukturierte Daten sind sie der Datenbereitstellungsschicht zuzuordnen (vgl. Kapitel 1.5). Auf die dort hinterlegten Inhalte kann beispielsweise mit Hilfe von InformationRetrieval- oder Text-Mining-Komponenten zugegriffen werden. Sofern die in DMS oder CMS hinterlegten Metadaten für eine integrierte Analyse strukturierter und unstrukturierter Daten aufbereitet werden, fungieren sie als Quellsysteme für ein DWH oder einen Data Mart (vgl. hierzu den Abschnitt zur Analyse unstrukturierter Daten in Kapitel 3.1.6.).

Distributionsrolle

Stehen hingegen die in den Systemen enthaltenen Funktionen zur Inhaltsverwaltung im Mittelpunkt, so sind sie der Informationsdistribution zuzurechnen. Diese Rolle von DMS und CMS wird im Weiteren vertieft.

Funktionen von CMS und DMS

CMS und DMS verfügen üblicherweise über diverse Funktionen zur kontrollierten Verwaltung und Verbreitung von Inhalten 145

3 Informationsgenerierung, -speicherung, -distribution und -zugriff (Klesse et al. 2003, S. 121). Die einzelnen Funktionen sowie ihre Einsatzpotentiale im Kontext der Distribution von BI-Wissen werden im Folgenden erörtert (Götzer et al. 2008, S. 37 ff.; Bahrs et al. 2009, S. 164 ff. und S. 216 ff.; Baars 2006, S. 414 ff):

Business Intelligence (BI) Informationszugriff

Datenbereitstellung

Analysesysteme

Data Mart Core Data Warehouse Operational Data Store

Informations -distribution

Content & Document Mgmt.

Systemintegration

Metadaten

Informationsgenerierung/ -distribution

BI-Portal CMS und DMS für die Informationsdistribution

CMS und DMS als Datenhaltungssysteme

CMS und DMS als Quellsysteme (Bereitstellung von Metadaten als Grundlage für die integrierte Analyse strukturierter Daten und unstrukturierter Inhaltsbestände)

Abb. 3.33: Mögliche Rollen von Content- und-Document Management-Systemen in einem BI-Ansatz

• Dezidierte Zugriffssteuerung CMS und DMS bieten Funktionen zur differenzierten Rollenzuweisung und Rechtevergabe. Mit ihnen wird es möglich, den Zugriff auf zu verteilende BI-Inhalte gezielt zu steuern und so z. B. hierarchie- und funktionsbezogene Lese-, Schreib- und Löschbeschränkungen festzulegen So kann beispielsweise vermieden werden, dass kritische Wettbewerbsanalysen für die Strategiefindung im Unternehmen diffundieren. • Workflow-Steuerung Auf Rollenkonzepten aufbauende Workflow-Steuerungen ermöglichen insbesondere zwei- oder mehrstufige Freigabeprozesse. Damit kann die Problematik eines „Information Overload“ durch eine Akkumulation unbrauchbarer, rudimentärer und/oder fehlerbehafteter BI-Inhalte adressiert werden, d. h. die entsprechende Funktionalität kann als Grundlage für Qualitätssicherungssicherungsprozesse genutzt werden. 146

3.2 Informationsdistribution: Content und Document Management • Lebenszykluskonzepte für Wissenseinheiten Im Allgemeinen besitzen die zu verteilenden Inhalte keine unbegrenzte Gültigkeit. Beispielsweise machen die Dynamik in Markt- und Organisationsstrukturen, Veränderungen des Produktsortiments usw. zunächst Analyseergebnisse und später auch die dahinter stehenden Analysemodelle unbrauchbar. CMS und DMS bieten Funktionalität zur zeitgetriggerten Prüfung, Archivierung und/oder Aussortierung obsoleter Dokumente: BI-Inhalte können mit einem „Verfallsdatum“ versehen werden. • Check-In/-Out: Steuerung konkurrierender Zugriffe Sollen Inhalte nicht nur für den lesenden Zugriff genutzt werden, so ist es mit sog. Check-In/Check-Out-Mechanismen möglich, parallele Zugriffe zu vermeiden. Aktualisierungen an den Dokumenten können beispielsweise erforderlich sein, um einen Modellparameter anzupassen oder um einen obsoleten Ergebnisbericht zu aktualisieren. • Zusammenfassung von Dokumenten DMS bieten i. d. R. die Möglichkeit, verschiedene Einzeldokumente in einem Sammeldokument zusammenzufassen. Dadurch können korrespondierende Inhalte gemeinsam hinterlegt werden, z. B. um für eine Balanced Scorecard Reports zu verschiedenen Detailsichten zu bündeln. • Versionierung Sofern eingestellte BI-Inhalte modifiziert werden dürfen, erlauben Funktionen zur Versionierung die gezielte Rückverfolgbarkeit der Historie eines Dokumentes. Ggf. kann auch ein Versionensplit erfolgen, beispielsweise wenn aus einem Analysemodell für eine Warenkorbanalyse zwei neue Modelle für unterschiedliche Vertriebskanäle generiert werden. • Information Retrieval Funktionen für das Information Retrieval i. S. v. Funktionen zum Auffinden von Dokumenten zu bestimmten spezifizierten Informationsbedarfen sind für die Informationsdistribution von zentralem Interesse. Hat ein Unternehmen bereits einen ausgebauten Dokumentenbestand in einem DMS oder CMS hinterlegt, so wächst der Integrationsnutzen, da eine Anwendung zu einer Anfrage sowohl die vorhandenen Inhalte als auch ergänzte BI-Inhalte liefert. Insofern ist ein derartiger Ansatz auch als wichtiger Schritt auf dem Weg zur Zusammenführung von strukturierten und unstrukturierten Informationen zu verstehen. 147

3 Informationsgenerierung, -speicherung, -distribution und -zugriff

3.2.3

Distribution von BI-Ergebnissen und BI-(Teil)-Systemen Je nach Aufbereitung lassen sich die zu verteilenden Wissensinhalte in unterschiedlichem Maße effizient und flexibel weiternutzen. Das Spektrum reicht von eingeschränkt editierbaren Dokumenten bis hin zu flexibel parametrisierbaren Templates, die unmittelbar als vorbereite Vorlagen für Anwendungen bzw. Anwendungskomponenten eingesetzt werden können. Hierbei ist zu unterscheiden, ob die Analyseergebnisse selbst oder deren Erstellung betroffen sind. Eine Übersicht über die entsprechenden Optionen gibt Abb. 3.34. Distribution von BI-Analyseergebnissen Naheliegend ist zunächst, DMS und CMS zu nutzen, um damit im BI-Kontext entstehende elektronische Dokumente einer organisationsweiten Weiterverwendung zuzuführen. Dies betrifft insbesondere die Ergebnisse, die mit BI-Analysesystemen erzeugt werden und die üblicherweise als MS-ExcelTM-Dateien, im PDFFormat, als Webseiten o. ä. aufbereitet sind.

CSV

148

Eine Weiternutzung der Ergebnisse wird erleichtert, wenn die entsprechenden Daten in einer unmittelbar maschinenverarbeitbaren Form hinterlegt werden. Dies kann durch Nutzung eines werkzeugspezifischen Formates erfolgen, was allerdings die Nutzungsmöglichkeiten außerhalb der gewählten Analyseumgebung begrenzt. Ein größerer Adressatenkreis kann durch den Einsatz des Formates eines gängigen Tabellenkalkulationsprogramms erreicht werden. Am flexibelsten sind dedizierte Datenaustauschformate. Nahezu alle Programme zur Datenaufbereitung und -analyse können das Comma-Separated-Values-(CSV)-Format importieren, bei dem Werte in einfachen Textdateien hinterlegt sind und durch Trennzeichen (z. B. Semikolons oder Kommata) auf eine tabellarische Struktur abgebildet werden (Repici 2004). Ein Nachteil von CSV-Dateien ist, dass hierbei keine Metadaten zugeordnet werden.

3.2 Informationsdistribution: Content und Document Management Analyseergebnisse

ƒ Standardberichte ƒ Ad-hoc-Berichte ƒ Balanced Scorecards ƒ Jahresabschlüsse ƒ Segmentierungen ƒ Assoziationsanalysen ƒ Klassifikationen ƒ…

Form

Î

Î

Analysevorbereitung und -durchführung

ƒ Klassifikationsmodelle ƒ Entscheidungsmodelle ƒ Balanced-ScorecardDefinitionen ƒ Spezifikation eines OLAP-Cubes ƒ Kennzahlendefinitionen ƒ Parametrisierung einer Cluster-Analyse ƒ Datenanbindung für einen Standardreport ƒ…

Dokumentenformate

ƒ PDF ƒ HTML-Seite ƒ TextverarbeitungsDokument ƒ …

Maschinenverarbeitbare Datenformate

ƒ Proprietäres Format des Analysesystems ƒ CSV-Datei ƒ Tabellenkalkulationsdokument ƒ Eigenes XML-Format ƒ XBRL ƒ …

Form

Î

Î

Î

Beispiele

Beispiele

Dokumente mit einer Beschreibung der Analysevorbereitung und -durchführung

ƒ PDF ƒ HTML-Seite ƒ TextverarbeitungsDokument ƒ Präsentation mit kommentierten Screenshots ƒ …

Formate zur Spezifikation von Anwendungskomponenten

ƒ PMML (Spezifikation Data-Mining-Modell) ƒ RDL (Berichtsdefinition) ƒ ….

Templates

ƒ Template für Standardreport ƒ Template für ABCAnalyse ƒ Template für Klassifikation ƒ Template für eine OLAP-Anwendung mit Datenhaltung und -anbindung ƒ …

Abb. 3.34: Gegenstände/Formate der Informationsdistribution XML

Eine im Vergleich zu CSV-Dateien deutlich weitergehende Flexibilität beim Datenaustausch kann durch den Einsatz der Extensible Markup Language (XML) erzielt werden. Mit „XML Schema“ 149

3 Informationsgenerierung, -speicherung, -distribution und -zugriff können dabei weitreichende Struktur- und Formatvorgaben definiert werden und so eigene „XML-Dialekte“ (synonym: XMLSprachen, XML-Formate oder XML-Anwendungen) definiert werden. Die Mächtigkeit von XML fußt v. a. auf den umfangreichen Möglichkeiten zur Kombinierbarkeit verschiedener XML-Dialekte sowie in der flexiblen Formatkonversion über XSLT („XSL Transformation“) (Harold et al. 2004; W3C 2006). Im BI-Bereich kommt eine Vielzahl unterschiedlicher XML-Dialekte zum Einsatz (Schwalm/Bange 2004, S. 6 ff.). Ein für die BI-Informationsdistribution zunehmend relevantes Format ist hierbei XBRL. XBRL

Die Extensible Business Reporting Language (XBRL) dient primär dem Austausch von Geschäftsdaten eines Unternehmens. Dadurch können Abschlussdaten für eine Geschäftsperiode für bestimmte Rechnungslegungsstandards definiert und im Rahmen des externen Berichtswesens veröffentlicht werden (Nutz/Strauß 2002; Kranich/Schmitz 2003; Debreceny et al. 2009, S. 35 ff.). Adressaten sind Wirtschaftsprüfer, Anteilseigner, Analysten und die staatlichen Stellen, die für die Prüfung des Jahresabschlusses zuständig sind. Darüber hinaus kann XBRL aber auch für den Austausch zwischen Anwendungssystemen im Unternehmen und für das interne Reporting eingesetzt werden. Aufgrund der starken Verbreitung des Standards sowie seiner Einfachheit und Flexibilität wird dieser zunehmend auch als Austauschformat im BI-Bereich gesehen (Chamoni 2007, S. 179 ff.). Die Bedeutung des Standards für den BI-Bereich wird zusätzlich durch die multidimensionale Erweiterung XBRL-Dimensions gestärkt (Hernández-Ros/Wallis 2006; Debreceny et al. 2009, S. 129 ff.). Distribution von BI-(Teil-)Systemen zur Mehrfachnutzung

Weitergabe von Inhalten aus anspruchsvollen Analysen

150

Gerade OLAP- und Data-Mining-Werkzeuge sind primär zur Deckung einmaliger und individueller Informationsbedarfe konzipiert, d. h. die entsprechenden Ergebnisse sind i. d. R. einzelfallspezifisch (Klesse et al. 2003, S. 121 f.). Beispiele sind die Bewertung des Erfolgs einer einmaligen Verkaufsförderungsaktion oder die Ursachenaufdeckung bei einem regionalen Umsatzrückgang. Entsprechende Resultate dürften schwerlich in einem anderen Kontext Gültigkeit besitzen: Mit dem Wechsel von Periode, Bezugsobjekt oder Problemstellung entfällt auch die Relevanz der Analyse. Eine Verbreitung entsprechender Ergebnisse – sei es in Form eines Berichtsdokumentes oder mit Hilfe maschinenverarbeitbarer Daten – ist vor diesem Hintergrund nur eingeschränkt sinnvoll.

3.2 Informationsdistribution: Content und Document Management Distribution von Wissen über die Vorbereitung und Durchführung von Analysen

Über einen Einzelfall hinaus relevant ist hierbei jedoch das Wissen über die Vorbereitung und Durchführung der Analyse. Eine konkrete Deckungsbeitragsanalyse für eine bestimmte Filiale mag für andere Filialen irrelevant sein – die Durchführung einer analogen Analyse hingegen nicht. Festzuhalten sind dafür v. a. das Analysemodell inklusive der gewählten Analyseverfahren, -dimensionen und -parameterwerte, die Datenanbindung sowie ggf. ergänzend die Form und das Layout der graphischen, tabellarischen und/oder textuellen Aufbereitung. Ähnlich kann im Reporting von einer Wiederverwendung der Reportdefinition bei der Entwicklung neuer Berichte profitiert werden. Ein zunächst naheliegendes Vorgehen hierfür ist die Erfassung einer schrittweisen Anleitung, d. h. eine „Bedienungsanleitung“. Dieses Vorgehen hat jedoch den entscheidenden Nachteil, mit einem erheblichen Aufwand auf Seiten des Erstellers verbunden zu sein – muss er doch alle relevanten Schritte rekapitulieren und in einer für Dritte nachvollziehbaren Form verbalisieren. Auch die manuelle Abarbeitung der Anweisungen durch den Zweitnutzer erscheint recht mühsam (Baars 2006, S. 413 f.).

PMML und RDL

Templates

Die Wiederverwendbarkeit wird erleichtert, sofern maschinenverarbeitbare Formate zur Definition relevanter Anwendungsbausteine ausgetauscht werden, z. B. für die Datenanbindung oder des Analysemodells. Neben herstellerspezifischen Formaten können auch hier XML-Standards genutzt werden. So ist die Predictive Model Mining Language (PMML) zur Beschreibung und den Austausch von Data-Mining-Modellen konzipiert (DMG 2010). Neben der Datenquelle werden in PMML auch die vorbereitenden Transformationen des Datenbestands und die Parameter des verwendeten Modells spezifiziert (Schwalm/Bange 2004, S. 9). Ähnlich erlaubt es die vom Unternehmen Microsoft entwickelten Report Definition Language (RDL) Berichtsdefinitionen festzuhalten. Dies beinhaltet die Datenanbindung, das Layout inkl. Angaben zur Formatierung und Datenaufbereitung sowie Report-Metadaten (Bange/Schwalm 2005, S. 214; Microsoft 2008, S. 5 ff.). Noch weiter geht die Professionalisierung der Wiederverwendung bei einem Einsatz individuell parametrisierter Anwendungsvorlagen (Templates). Im Idealfall sind die weiterzugebenden Templates dabei so ausgelegt, dass manuelle Speicher-, Lade- oder Installationsaktivitäten weitgehend entfallen. Mehrere größere Hersteller haben hierzu in ihren BI-Suites (proprietäre) Konzepte realisiert und liefern teilweise bereits Standard151

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Templates für gängige Analyseanwendungen aus, die neben der Analyseschicht z. T. auch die Datenmodellierung und die Anbindung der Datenquellen beinhalten. Es ist zu betonen, dass der Automatisierungsgrad der Wiederverwendung auch bei einer Nutzung von Templates nicht beliebig ausbaubar ist. Zum einen können die Fachbereiche nicht von der intensiven Auseinandersetzung mit den fachlichen Inhalten entbunden werden (Bange 2007) – die Wahl der Datenquellen, die Transformationen, die Datenmodellierung und die Analysemodelle sind üblicherweise in hohem Grade von den fachlichen Spezifika abhängig. Zum anderen sind Hinweise etwa zu Einschränkungen der Aussagekraft von Analyseergebnissen nur bedingt maschinenverarbeitbar hinterlegbar. Insofern sollten die Analysetemplates neben Modell-, Auswertungs- und Formatierungsvorgaben auch um semistrukturierte Freitextannotationen angereichert werden können (Baars 2006, S. 413 f.). Grundsätzlich ist die zielgerichtete Distribution von Templates über DMS/WMS-Systeme vor allem in größeren BI-Umgebungen von zunehmender Relevanz – schon aufgrund ihrer schnell wachsenden Zahl. Inwiefern hierbei lediglich Dokumentationen und Referenzen distribuiert werden oder sogar die Templates selbst, hängt nicht zuletzt von deren Portierbarkeit ab. Weitergehende Konzepte sehen sogar einen werkzeugübergreifenden Austausch vor (Baars 2006, S. 417 ff.).

3.3

Informationszugriff: Portale Um einen konsistenten und effizienten Zugriff auf die diversen BI-Systeme zu gewährleisten, muss eine Benutzerschnittstelle für die Managementunterstützung sowohl die Komplexität der BIInfrastruktur durch eine Integrationsleistung verbergen als auch durch Personalisierung auf die Vielfalt an Anforderungen auf Benutzerseite eingehen. Ein einheitlicher Zugang ist dabei nicht nur zur der Akzeptanzsicherung erforderlich sondern auch, um den Blick auf übergeordnete Zusammenhänge zu lenken, etwa durch Nebeneinanderstellung strukturierter und unstrukturierter Inhalte. Eine Personalisierung hingegen ist ratsam, um den unterschiedlichen Rollen der Benutzer gerecht zu werden. Mit zunehmenden Anforderungen, BI-Inhalte und BI-Funktionen über heterogene Kanäle und Endgeräte verfügbar zu machen, wächst die Komplexität dieser Aufgaben.

152

3.3 Informationszugriff: Portale Neue Kanäle zur Bereitstellung von BI-Inhalten

BI-Inhalte können auf verschiedenen Wegen zum Benutzer gelangen – etwa über dedizierte Analysefrontends, als Bestandteil einer Unternehmenswebseite oder integriert in operative Anwendungen (etwa im Rahmen einer Closed-loop-Lösung, vgl. Kapitel 3.1.3). Ein Beispiel für einen neueren Kanal sind Feeds, die zur Verteilung von Kurzinhalten an unterschiedliche Frontend-Anwendungen gedacht sind (content syndication). Feeds können beispielsweise im Rahmen des Exception Reportings eingesetzt werden. Gängige Protokolle hierfür sind die Formate RSS und Atom (Hammersley 2005, S. 1 ff.). Ebenfalls an Bedeutung gewonnen haben Widgets, d. h. eigenständige Programmkomponenten mit eigener Benutzerschnittstelle, die in eine graphische Bedienoberfläche integriert werden, beispielsweise in die eines Betriebssystems. Widgets werden im BI-Kontext beispielsweise für die Visualisierung von Prozesszuständen eingesetzt.

Gestiegene Bedeutung mobiler Endgeräte

Bei den Endgeräten werden für den BI-Bereich neben stationären PCs auch zunehmend internetfähige Mobilgeräte interessant (Bensberg 2008, S. 72 ff.). Hervorzuheben ist dabei v. a. die Klasse der Smartphones als Symbiose aus Mobiltelefon und vernetztem Kleincomputer. Deren Bedeutung wird durch Entwicklungen bei Rechenleistung, Netzanbindung und Displaytechnologien ebenso gefördert wie durch die zunehmend Verbreitung und Akzeptanz derartiger Endgeräte.

Standards zur webbasierten Verknüpfung von Inhalten

Erleichtert wird die Realisierung von Lösungen, die den genannten Anforderungen gerecht werden, durch den Trend zu offenen und internetfähigen Formaten für die Übertragung und Konvertierung von Daten sowie durch Technologien zur webbasierten Bereitstellung einzelner Funktionen sowie von gekapselten, flexibel integrierbaren Programmkomponenten. Bzgl. der Datenformate sind die bereits in 3.2.3 diskutierten XML-Standards (z. B. XBRL) hervorzuheben. Weiter reichen Standards, die Programmfunktionalität auf Basis von Webtechnologien über das Internet aufrufbar machen – sog. Webservices. Schließlich werden in Webinfrastrukturen zunehmend Schnittstellen zur Einbindung von Widgets bereitgestellt, was eine Integration und Kombination von Diensten erleichtert. Die erforderliche Verteilung und Konvertierung von Daten, Services und Komponenten erfolgt

153

3 Informationsgenerierung, -speicherung, -distribution und -zugriff dabei üblicherweise über mehrschichtige Web-Infrastrukturen (Multi-Tier-Architekturen) 22. Bereits etabliert zur Integration des Informationszugriffs sind Portalsysteme, die insbesondere auch als Zugangssysteme für BIInhalte zum Einsatz kommen. Der Begriff des Portals leitet sich aus dem lateinischen „porta“ für Pforte ab und bezeichnet eine einheitliche und individualisierte Zugriffsmöglichkeit auf Inhalte und Applikationen. Im Folgenden werden die BI-relevanten Teile eines Unternehmensportals vorgestellt und die Kernfunktionalitäten der Benutzerunterstützung und der Integration diskutiert. Hierbei werden Einsatzmöglichkeiten zur Integration strukturierter und unstrukturierter Inhalte vertieft.

3.3.1

Einordnung des Portalbegriffs

Internet Portals

Der Portalbegriff hat seinen Ursprung im Internet. Durch die Fülle an Informationsangeboten im World Wide Web entstand die Notwendigkeit einer inhaltlichen Ordnung und Navigationsunterstützung für thematisch abgrenzbare Teilbereiche des Internets. Als Internet Portal wird dementsprechend eine Website bezeichnet, die strukturierte Informationen über im Web abrufbare Dokumente anbietet (Hansen/Neumann 2009, S. 810 ff.). Sie soll durch die Strukturierung der Inhalte einen Überblick schaffen und als zentrale Anlaufstelle für Informationssuchende dienen. Klassische Anbieter von öffentlichen Portalen sind z. B. Yahoo! oder im deutschsprachigen Raum web.de.

Portalklassen nach Davydov

Aus dem ursprünglichen Portalkonzept sind zahlreiche Adaptionen hervorgegangen. Davydov unterscheidet mehrere Portalklassen nach Einsatzgebieten und Adressaten (vgl. Abb. 3.35).

Öffentliche Portale

Öffentliche Portale (Public Portals) sind klassische Web-Portale, die im Internet allgemein verfügbar sind und eine große Bandbreite an Informationsdiensten, wie Katalog-, Such- und Nachrichtendienste anbieten (Hansen/Neumann 2009, S. 815 f.).

Persönliche Portale

Persönliche Portale (Personal Portals) sind ebenfalls allgemein zugänglich. Sie richten ihr Angebot jedoch auf mobile Endgeräte wie Smartphones aus und müssen aufgrund der technischen

22

154

Anwendungen, die auf diese Weise Daten, Services und Komponenten verschiedener Quellen zusammenführen, werden unter dem Begriff Mashups diskutiert. Mashups werden für den BI-Bereich z.T. auch als zukünftige Alternative zu Portalsystemen gesehen (Jhingran 2006, S. 3 f.).

3.3 Informationszugriff: Portale Restriktionen – insbesondere im Bereich der Darstellung – ausgeprägte Personalisierungsfähigkeiten aufweisen.

Portals

Public Portals

General Public Portals

Content Management Portals

Corporate Portals

Industrial Portals

EIPs

Business Intelligence Portals

Collaboration Portals

Personal Portals

Role Portals

B2C Portals

Pervasive Portals

B2B Portals

Appliance Portals

B2E Portals

Abb. 3.35: Portalklassen (Davydov 2001, S. 138, Hervorhebungen durch die Autoren) Unternehmensportale

Unternehmensportale (Corporate Portals) stellen internen und externen Anspruchsgruppen Informationen eines Unternehmens zur Verfügung und unterstützen Geschäftsabwicklungen. Eine weitere Detaillierung erfolgt anhand der Zielgruppe in sog. Role Portals (Amberg et al. 2003, S. 1396; vgl. auch Kapitel 1.3):

• Business-to-Consumer (B2C): Kundenprozessbezogene Portale.

• Business-to-Business (B2B): Portale zur überbetrieblichen Geschäftsabwicklung.

• Business-to-Employee (B2E): Portale zur innerbetrieblichen Geschäftsabwicklung. Enterprise Information Portal

Ein Enterprise Information Portal (EIP) dient der Entscheidungsunterstützung, indem geschäftsrelevante interne und externe Informationen zusammengeführt und dem Benutzer in aggregierter und personalisierter Form zur Verfügung gestellt werden (Shilakes/Tylman 1998; Firestone 2003, S. 3 ff.). Steht die Unterstützung der Zusammenarbeit eines Teams im Vordergrund – z. B. durch Diskussionsforen, Chats oder Workflows – spricht man von einem Collaboration Portal. Unstrukturierte oder semistrukturierte Daten in Form von Dokumenten oder digitalen 155

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Inhalten werden in einem Content Management Portal gehalten, während steuerungsrelevante Informationen den Schwerpunkt eines Business Intelligence Portal bilden. Die Abgrenzung der verschiedenen Enterprise-InformationPortale ist nicht trennscharf. Zwar können die drei Formen des Collaboration, Content Management und Business Intelligence Portals durchaus isoliert auftreten, jedoch stehen in der Praxis meist Unternehmensportale im Vordergrund, die diverse strukturierte und unstrukturierte Inhalte sowie Kommunikations- und Kooperationsdienste zusammenführen. Das Portal hat damit eine Integrationsfunktion auf Ebene der Benutzerschnittstelle.

3.3.2

Portal-Personalisierung Ein wichtiges konstituierendes Element für ein Portal ist die individuelle Anpassung der Darstellung und Inhalte an den Benutzer und dessen konkrete Informationsbedürfnisse durch Personalisierung (Schackmann/Schü 2001, S. 623 ff.). Prinzipiell kann Personalisierung im Hinblick auf die Reichweite in eine rollen- oder gruppenbezogene und eine individuelle Personalisierung unterschieden werden.

Rollen- oder gruppenbezogene Personalisierung

Bei der rollen- oder gruppenbezogenen Personalisierung werden Einstellungen bzgl. der Inhalte und Anwendungen aufgrund einer zentralen Vorgabe vorgenommen. Ein Benutzer kann dabei mehrere Rollen innehaben und mehreren Gruppen, wie z. B. einem Bereich, einem Standort und einer Managementebene, zugehörig sein. Gängig sind z. B. bereichsspezifische Startseiten, die vom Benutzer dann entsprechend weiter detailliert werden können (Kaiser 2002, S. 133).

Individuelle Personalisierung

Die individuelle Personalisierung ist benutzerspezifisch und kann explizit oder implizit erfolgen. Bei der expliziten Personalisierung kann der Benutzer aktiv verschiedene Elemente der Darstellung (Layout des Portals, Farben, Grafiken) und der Inhalte (Auswahl von Channels und Anwendungen) festlegen. Diese Art der Anpassung wird auch als Pull-Personalisierung bezeichnet (Bange 2004, S. 149; Schackmann/Schü 2001, S. 624).

Implizite Persona- Die implizite Personalisierung greift auf das gespeicherte Benutzerprofil und auf die anfallenden Nutzungsdaten zurück und lisierung leitet daraus selbständig Empfehlungen für interessante und relevante Inhalte für den Benutzer ab. Das Portal spielt hierbei eine aktive Rolle, indem die auftretenden Nutzungsmuster in einem Personalisierungssystem gespeichert und ausgewertet werden. 156

3.3 Informationszugriff: Portale Der technische Aufwand hierfür ist höher als bei der expliziten Personalisierung, wobei teilweise Data-Mining-Methoden für die Auswertung der Nutzungsdaten zum Einsatz kommen23. Verschiedene Personalisierungstechniken und deren Umsetzung werden in Bange 2004, S. 151 ff. diskutiert. Single Sign On

Ein weiterer wichtiger Punkt im Rahmen der Benutzerorientierung ist die Unterstützung eines Single Sign On. Dadurch wird gewährleistet, dass der Benutzer entsprechend seines Berechtigungsprofils durch eine einmalige Anmeldung Zugriff auf alle benötigten Inhalte und Anwendungen erhält. Als Grundlage dient ein Verzeichnisdienst – z. B. auf Basis von LDAP (Lightweight Directory Access Protocol) – in dem alle Benutzerdaten applikationsneutral gespeichert werden (Wahl et al. 1997). Die Berechtigungsverwaltung wird anwendungsübergreifend im Metadaten-Repository vorgenommen (vgl. Kapitel 2.3.4).

Benutzerorientierung im Portal

Durch die verschiedenen Personalisierungsmöglichkeiten und den Single Sign On ermöglicht das Portal eine hoch individualisierte und optimierte Arbeitsoberfläche für den Endbenutzer. Die Auswahl der einzelnen Analysesysteme und Inhalte des CMS können automatisch an dem tatsächlichen Bedarf des Anwenders ausgerichtet werden und ermöglichen so ein effektiveres Arbeiten.

3.3.3

Integration von Inhalten Eine Zusammenführung von unterschiedlichen Inhalten und Anwendungen unter einer gemeinsamen Oberfläche ist eine Kernfunktionalität des Portalansatzes. Die IT-basierte Managementunterstützung erhält dadurch einen zentralisierten und strukturierten Zugriff auf die verfügbaren Informationsangebote.

Portlets

Ein Portal setzt sich aus mehreren aggregierten Elementen zusammen. Die einzelnen Portalbausteine werden als Portlets bezeichnet und basieren beispielsweise auf den Java-Spezifikation 168 und 286 (Java Community Process 2003; Java Community Process 2008). Sie regeln in dem Zusammenspiel mit dem Portal für einzelne Teilbereiche die Auswahl der angezeigten Inhalte, deren Darstellung und die Überprüfung der Berechtigungen. Die

23

Es werden auch Ansätze erprobt, die auf einem Vergleich von Berichts-, Nutzer- und Nutzungsinformationen basieren, um so aktiv Inhalte (z. B. Berichte) zur Ansicht zu empfehlen, sog. kollaborative Recommender-Systeme, vgl. Jürck et al. 2009, S. 349 ff.

157

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Abb. 3.36 zeigt exemplarisch den schematischen Aufbau eines Portals, in dem unterschiedliche Portlets zum Einsatz kommen.

Navigation & Konfiguration Nachrichten

Detailbereich

Aktienkurse

(z.B. für BI-Applikation/Analysesystem)

Kommunikation & Kollaboration Suche

Abb. 3.36: Beispielhafter schematischer Aufbau eines Portals Herkunft: Intern/Extern

Je nach Herkunft lassen sich interne und externe Inhalte unterscheiden. Interne Inhalte werden aus unternehmenseigenen Informationssystemen bezogen und umfassen z. B. eigene Pressemitteilungen oder Managementberichte. Externe Inhalte hingegen stammen von Drittanbietern und umfassen wettbewerbsrelevante Daten wie Aktienkurse, Analysen oder Nachrichten.

Integration von Anwendungen

Klassische Portalinhalte sind in der Regel statisch. Erst durch die Integration von Anwendungen wird die reine Darstellung von Inhalten durch weitergehende Verarbeitungs- und Analysefunktionen ergänzt (Bange 2004, S. 149). Im BI-Bereich des Portals werden die webbasierten Analysesysteme integriert und stehen somit ohne zusätzliche Installation von Client-Software beim Benutzer zur Verfügung.

Kommunikations- Ergänzt wird das Portal durch Kommunikations- und Kollaborationsmöglichkeiten, die von klassischen Anwendungen wie und Kollaborationsmöglichkeiten E-Mail und Kalender bis hin zu umfangreichen Kommunikationssystemen wie Voice-over-IP reichen. Chats und Foren eignen sich ebenfalls für den Austausch von Wissen, benötigen aber für einen erfolgreichen Einsatz in der Regel eine entsprechende Betreuung (Bahrs 2009, S. 256 ff.; Kaiser 2002, S. 135 f.).

158

3.3 Informationszugriff: Portale Ein Portalansatz ist prädestiniert, eine integrierte Benutzerschnittstelle für den Zugang zu strukturierten und unstrukturierten Inhalten zu realisieren. Anders als bei dem in Kapitel 3.1.6 sind hierbei keine umfangreichen Eingriffe auf Ebene der Datenhaltung erforderlich. Portal

Portlet für die Analyse und Anzeige strukturierter Daten

Portlet zur Navigation in unstrukturierten Daten

(z.B. mit OLAPFunktionalität)

( z.B. mit InformationRetrieval -Funktionalität)

Komponente zur Realisierung eines simultanen Zugriffs auf strukturierte und unstrukturierte Inhalte Übersetzung der Benutzeraktionen im Portlet für die Anzeige der Analysekomponente in Aufrufe bei der Komponente für den Zugriff auf unstrukturierte Daten

Analysesystem (z.B. ein Data-Mart-basiertes OLAP System)

Übersetzung der Benutzeraktionen im Portlet für die Anzeige unstrukturierten Daten in Aufrufe im Analysesystem

Komponente für den Zugriff auf unstrukturierte Daten (z.B. in einem Content-Management-System)

Abb. 3.37: Integration des Zugriffs auf strukturierte und unstrukturierte Daten (Baars/Kemper 2008, S. 142)

Integration strkturierter und unstrukturierter Inhalte

Im einfachsten Fall (siehe Abb. 3.37) werden die strukturierten Inhalte einfach in unterschiedlichen Portlets nebeneinandergestellt – was durchaus bereits einen Integrationsnutzen bringen kann, da dies den Blick für eine inhaltsübergreifende Nutzung öffnet. Die Integrationspotentiale von lich weiter. Realisiert wurden gezielte Kopplung von Suchben (Becker et al. 2002, S. 255

Portalen gehen jedoch noch deutinsbesondere Lösungen, die eine und Navigationsfunktionen erlauf., Priebe et al. 2003, S. 281 ff.).

159

3 Informationsgenerierung, -speicherung, -distribution und -zugriff Beispiel: Bei der Navigation in einem OLAP-Cube mit Vertriebsergebnissen wird anhand der vom Benutzer betrachteten Auswertungsdimensionen (z. B. „Zeit“ und „Produktgruppe“), den eingesetzten Selektionskriterien (z. B. „nur norddeutsche Filialen“) und der gewählten Granularität (z. B. „Ergebnisse pro Quartal“) automatisch eine parallele Suche nach passenden Dokumenten im Content-Management-System durchgeführt (z. B. Analysen der Marktforschung zu den Kundenanforderungen in der Region Norddeutschland) (Kemper/Baars 2005, S. 122).

3.4

Zusammenfassung Im Rahmen der Informationsgenerierung werden aus den Daten der dispositiven Datenbereitstellung mit Hilfe von Analysesystemen Informationen zur Unterstützung der Unternehmenssteuerung gewonnen. Analysesysteme werden aufgrund ihrer funktionalen Ausrichtungen differenziert, wobei auf der Basis der datenseitigen Anbindung an die dispositive Datenhaltung neben dem traditionellen Data Warehousing neuere Implementierungsformen wie das Closed-loop-, das Real-time- und das Active Data Warehousing unterschieden werden können. Zu den generischen Basissystemen gehören die freien Datenrecherchen, die OLAP-Systeme, die modellorientierten Analysesysteme und die Berichtssysteme, die sich primär aufgrund ihrer jeweiligen Funktionalität und der Form der Benutzerführung unterscheiden lassen. Konzeptorientierte Systeme zeichnen sich durch die Integration betriebswirtschaftlich fundierter Verfahren aus, können in weiten Teilen auch generische Basissysteme beinhalten und werden in aller Regel mit Hilfe von Standardwerkzeugen entwickelt. Ziel der Informationsspeicherung und -distribution ist es, BIWissen unternehmensweit nutzbar zu machen. Hierfür werden Analyseergebnisse, Anwendungsbausteine und Templates abgelegt, dokumentiert und in adäquater Form interessierten Mitarbeitern zugänglich gemacht. Als Werkzeuge kommen Wissensmanagementsysteme zum Einsatz, wobei Content- und DocumentManagement-Systemen eine besondere Rolle bei der Vorhaltung und der Verteilung kodifzierten BI-Wissens zukommt. Für den zentralen Informationszugriff kommen v. a. Portale zum Einsatz, in denen Analyseinhalte und -funktionen unter einer einheitlichen Benutzungsoberfläche zugänglich gemacht werden.

160

3.4 Zusammenfassung Um die umfangreichen Informationsquellen handhabbar und komfortabel bedienbar zu gestalten, wird das Portal benutzerindividuell personalisiert. Besondere Herausforderungen bei der Informationsgenerierung und -distribution sind mit der Handhabung unstrukturierter Daten verbunden. Diese können zum einen über separate TextMining-Komponenten analysiert werden, mit Hilfe von Metadaten in das dispositive Datenhaltungssystem integriert und so für andere BI-Analysesysteme zugänglich gemacht werden oder mit Hilfe von Portalen in eine integrierte Benutzerschnittstelle eingebunden werden.

161

4

Entwicklung und Betrieb integrierter BI-Lösungen Das folgende Kapitel behandelt die iterative Entwicklung und den Betrieb unternehmensspezifischer BI-Lösungen. Die Ausführungen beginnen mit Vorbemerkungen zur aktuellen, geschäftsprozessorientierten Diskussion des IT-Einsatzes. Anschließend wird ein Konzept bestehend aus einer Makro- und einer MikroEbene vorgestellt, das gezielt auf die Belange eines integrierten BI-Gesamtansatzes ausgerichtet ist.

4.1

Vorbemerkungen Im Jahre 2003 erschien im Harvard Business Review ein provokanter Artikel von Nicholas G. Carr mit dem Titel „IT Doesn´t Matter“ (Carr 2003). Der Autor argumentierte in diesem Beitrag, dass das strategische Potenzial der IT erheblich überschätzt würde. Seiner Meinung nach wären Produkte der Informationstechnologie im Laufe der Zeit Handelsgüter des täglichen Gebrauchs geworden. Sie wären als sog. Commodities für jede Organisation am Markt erwerbbar und könnten aus diesem Grunde kaum Wettbewerbsvorteile generieren. Carr plädierte daher, nicht zu viel in IT zu investieren, eher Basis- anstelle von Schlüsseltechnologien einzusetzen und primär die Stabilität der IT-Basisinfrastrukturen in den Mittelpunkt zu stellen. Die Reaktionen auf Carrs Artikel waren heftig, teilweise polemisch und aufgrund von Argumentationsmängeln im Artikel durchaus berechtigt. Allerdings kann man Carr zu Gute halten, dass er mit seiner Schrift weltweit die kritische Diskussion über den IT-Wertbeitrag zum Unternehmenserfolg befeuerte. Heute besteht allgemein Konsens darüber, dass IT per se üblicherweise keinen Unternehmenswert generieren kann. So lässt sich empirisch dokumentieren, dass größere IT-Investitionen nicht automatisch zu höherem Unternehmenserfolg führen (Brynjolfsson/Hitt 2000, S. 32). Die aktuellen Diskussionen konzentrieren sich daher verstärkt auf die wirksame Gestaltung der Geschäftsprozesse als Treiber des Unternehmenserfolgs, wobei der zielgerichtete Einsatz der IT sehr wohl einen der Schlüsselfaktoren darstellt. Eine gelungene Darstellung dieser Zusammen-

163

4 Entwicklung und Betrieb integrierter BI-Lösungen hänge liefern Wigand et al. 1998 (siehe Abb. 4.1 nach Krcmar 2009, S. 520).

IT

Wert

beeinflusst

Geschäftsmodell

ermöglicht liefert

Geschäftsprozesse bestimmt

bedingt

Unternehmensstrategie

Abb. 4.1:

Zusammenhänge des Wertbeitrags durch IT (Wigand et al. 1998, nach Krcmar 2009, S. 520)

Deutlich wird, dass von den Unternehmensstrategien die Geschäftsmodelle abhängen, wobei diese üblicherweise definiert werden als Architekturen von Produkt-, Service- und Informationsflüssen unter Berücksichtigung der beteiligten Geschäftspartner, ihrer Rollen, des für sie anfallenden Nutzens sowie der einzelnen Erlösquellen (Timmers 1998, S. 4). Selbstverständlich beeinflussen die IT-Potenziale die Gestaltung der Geschäftsmodelle. Gleichzeitig induzieren die Anforderungen aus den sich etablierenden Geschäftsmodellen vice versa neue Entwicklungen im IT-Bereich. So konnten sich beispielsweise die heute üblichen Internet-Shopsysteme erst auf der Basis der Internet- und Webtechnologien etablieren, wobei erst die Implementierung dieser Ansätze die Entwicklung sicherer und benutzerfreundlicher webbasierter Bezahlverfahren forcierte. Weiterhin ist aus der Abbildung erkennbar, dass sich aus den Geschäftsmodellen die wertschöpfenden Geschäftsprozesse ableiten. Auch hier besitzt die IT eine dominierende Rolle, da mit ihrer Hilfe eine wettbewerbswirksame Gestaltung der Prozesse ermöglicht wird. Es liegt auf der Hand, dass ausschließlich die gelungene Gestaltung, Umsetzung und Steuerung dieser Prozesse den Unternehmenserfolg nachhaltig determinieren kann. Die IT bestimmt somit lediglich mittelbar die Leistungsfähigkeit einer Organisation. So besitzt beispielsweise ein Automobilhersteller, 164

4.2 Konzept integrierter BI-Ansätze der aufgrund einer gelungenen IT-basierten Lösung im Supply Chain Management zeitnah auf Kundenanforderungen reagieren kann, Vorteile gegenüber Konkurrenten, die hier keine befriedigenden Lösungen aufweisen können. Auch für den zielgerichteten Einsatz der IT in der Managementunterstützung ist es zwingend notwendig, die BI-Architekturen und -Vorgehensmodelle am Bedarf der Geschäftsprozesse auszurichten. Um einen Beitrag zur Lösung dieses Problembereichs zu leisten, wird im Folgenden ein generisches Rahmenkonzept zur Schaffung integrierter BI-Ansätze vorgestellt.

4.2

Konzept integrierter BI-Ansätze Das folgende speziell auf die Anforderungen der IT-basierten Managementunterstützung zugeschnittene Konzept stellt den integrierten BI-Ansatz in den Mittelpunkt und unterscheidet explizit eine Makro- und eine Mikro-Ebene.

Makro-Ebene

Die Makro-Ebene befasst sich mit übergreifenden Aufgaben des integrierten BI-Ansatzes, was insbesondere die Gestaltung übergeordneter Steuerungs- und Regelungsstrukturen, die sog. Governance24, umfasst. Auf der Makro-Ebene sind grundlegende konzeptionelle Entscheidungen zu treffen, die eine enge Verbindung zum Aufgabenfeld des strategischen Managements aufweisen. Sie werden ergänzt durch verbindliche Vorgaben und Empfehlungen zur Optimierung von Entwicklung und Betrieb. Diese Ordnungsstrukturen sind durch institutionalisierte Gruppen zu erarbeiten, im Zeitverlauf zu prüfen und im Bedarfsfall den sich wandelnden Umweltbedingungen anzupassen.

Mikro-Ebene

Die Mikro-Ebene beinhaltet dagegen die eigentlichen Entwicklungs-, Reengineering- und Betriebsprozesse der einzelnen BIAnwendungssysteme über deren gesamten Lebenszyklus hinweg. Diese Gestaltungsprozesse orientieren sich eng an den Vorgaben der Makro-Ebene. Sie werden unter starker Beteiligung der Endbenutzer mit Hilfe explorativ ausgerichteter Prototypen entwickelt und von Vertretern der Makro-Ebene überwacht. Die folgende Abb. 4.2 zeigt das Zusammenspiel der Makro- und Mikro-Ebene am Beispiel eines iterativ ausgerichteten Entwicklungsmodells im Detail.

24 Eine Erläuterung von Governance-Varianten erfolgt in Kapitel 4.3.

165

4 Entwicklung und Betrieb integrierter BI-Lösungen Den im Modell integrierten Controllingaktivitäten kommt eine hohe Bedeutung zu. Es können insgesamt drei verschiedene Bereiche des Controllings identifiziert werden:

Controllingaktivitäten

• Die Rahmenbedingungen der Makro-Ebene werden an sog. Controllingpunkten periodischen Prüfungen unterzogen. Im Bedarfsfall führt dies zur Modifikation der Rahmenvorgaben und somit zur Überarbeitung der Rahmenstrukturen. Auslöser für einen Anpassungsbedarf können sowohl interne als auch externe Impulse sein. So können z. B. technologische Neuerungen (wie die Etablierung leistungsfähiger Thin-ClientKomponenten) als externe Impulse eine Modifikation der Makro-Ebene bedingen. Veränderungen der Organisationsstruktur (z. B. aufgrund einer geschäftlichen Neuausrichtung) können hingegen als Beispiel interner Impulse gewertet werden.

Management / Fachabteilung / IV-Spezialisten / Vertreter der Makro-Ebene MikroEbene

MikroEbene

E´-Prozess BI-Anwdg. 1 (Projekt 1)

C

E´-Prozess BI-Anwdg. 2 (Projekt 2)

C

C

E´-Prozess BI-Anwdg. 3 (Projekt 3)

C

Reengineering BI-Anwdg. 1 (Projekt n+1)

C

C

C

Reengineering BI-Anwdg. 2 (Projekt n+2)

C

C

C

Reengineering BI-Anwdg. 3 (Projekt n+3)

C

Reengineering BI-Anwdg. 1 (Projekt n)

Interne Impulse

C

Interne Impulse

C

C

C

Externe Impulse

Externe Impulse

Institutionalisierte Servicegruppe für Business Intelligence

Zeit Legende:

C

Controllingpkt. der Makro-Ebene

Abb. 4.2:

166

C

Controllingpkt. mit Anpassungszyklus (Mikro-Ebene)

C

Controllingpkt. zur Abstimmung zwischen Mikro- und Makro-Ebene

Zusammenspiel der Makro- und Mikro-Ebene (modifiziert übernommen aus Kemper 1999, S. 287)

4.3 Makro-Ebene • Innerhalb der Mikro-Ebene existieren zwei unterschiedliche Typen von Controllingaktivitäten. Zum einen sind Controllingpunkte zu etablieren, mit deren Hilfe die Kongruenz zwischen den Funktionalitäten eines BI-Anwendungssystems und den sich wandelnden betriebswirtschaftlichen Anforderungen sichergestellt werden kann. Im Falle von marginalen Änderungen können Anpassungen im Rahmen von Anpassungszyklen sofort umgesetzt werden. • Zum anderen sind nach einem abgeschlossenen Reengineering der Makro-Ebene (ausgelöst durch interne/externe Impulse) zusätzlich sämtliche BI-Anwendungssysteme zu analysieren, um die Synchronität zwischen Mikround Makro-Ebene zu gewährleisten. Im Folgenden werden die Aufgaben der Makro- und MikroEbene konkretisiert.

4.3

Makro-Ebene Der Makro-Ebene sind innerhalb des Konzepts übergreifende Aufgaben zugeordnet. Besondere Bedeutung hat dabei die Schaffung stabiler Rahmenstrukturen für die jeweiligen Entwicklungsund Betriebsprozesse der Mikro-Ebene. Diese BI Governance ist eingebettet in die Bereiche der Corporate und der IT Governance und steht in enger Beziehung zu diesen (Kemper/Baars 2009a, S. 74 ff.).

Corporate Governance

Als Ausgangspunkt bezeichnet die Corporate Governance die unternehmensspezifische Gestaltung und Implementierung geeigneter Leitungs- und Kontrollstrukturen, die eine nachhaltige, an ethischen und kulturellen Werten orientierte Unternehmensführung sicherstellen soll (von Werder 2008).

IT Governance

Die IT Governance ist – mit geringem Zeitverzug – in diesem Umfeld entstanden. Sie umfasst die Gestaltung von Regelungen, Empfehlungen, Rollen und Verantwortlichkeiten sowie Richtlinien zur Projektpriorisierung, um eine wechselseitige Abstimmung der IT mit der Strategie des Unternehmens gewährleisten zu können (Weill/Ross 2004, S. 8 ff.; Johannsen/Goeken 2007, S. 21 ff.; IT Governance Institute 2003, S. 10 ff.).

BI Governance

BI Governance wird in diesem Kontext definiert als Bereich der organisatorischen Einbindung, der prozessualen Gestaltung und Steuerung des gesamten BI-Kontextes eines Unternehmens, um eine konsequente Ausrichtung des BI-Konzeptes an der Gesamt-

167

4 Entwicklung und Betrieb integrierter BI-Lösungen strategie des 2009a, S. 74). Übersicht Makro-Ebene

Unternehmens

sicherzustellen

(Kemper/Baars

Wie die Abb. 4.3 verdeutlicht, sind hierbei im Detail mehrere Aufgaben zu berücksichtigen, die in den Gestaltungsbereichen „Strategie“ sowie „Richtlinien und Leitlinien“ gebündelt werden. Ergänzt werden sie durch die beiden übergreifenden Funktionen des Controllings und der Organisation. Makro-Ebene des BI-Rahmenkonzepts Strategie Potenzialplanung

Controlling

Technologie- & Infrastrukturmanagement

Richtlinien & Leitlinien

Organisation

Portfoliomanagement

BI-Service- & Sourcing-Policies Dispositive Datenarchitektur Entwicklungs- & Betriebs-Rahmenbedingungen

Abb. 4.3: Strategie

Gestaltungsbereiche und Aufgaben der Makro-Ebene

Im Gestaltungsbereich der Strategie wird die grundlegende Ausrichtung des unternehmensindividuellen BI-Konzepts bestimmt. Die einzelnen Aufgaben umfassen • die Potenzialplanung, in der die BI-Anwendungssysteme konsequent am Informationsbedarf der Unternehmensziele ausgerichtet werden, • das Portfoliomanagement, das Transparenz über die anstehenden BI-Systeme und -Entwicklungsprojekte schafft und bei Ressourcenengpässen über eine sinnvoll priorisierte Reihenfolge entscheidet, sowie • das Technologie- und Infrastrukturmanagement, welches neue Technologieentwicklungen erkennt, beobachtet und zu gegebenem Zeitpunkt in den integrierten BI-Ansatz einbindet und die Skalierbarkeit der existierenden Infrastrukturen garantiert.

168

4.3 Makro-Ebene Richtlinien & Leitlinien

Besonderer Augenmerk der Makro-Ebene liegt auf klaren Vorgaben, die zum einen eine effiziente Umsetzung des BI-Konzepts ermöglichen, zum anderen aber auch ausreichenden Spielraum für innovative Lösungen und für schnelle Reaktionen auf betriebliche Herausforderungen belassen. Dies gewährleistet die Kombination von Richtlinien und Leitlinien.

Richtlinien

Unter Richtlinien werden dabei Handlungsvorschriften für einen bestimmten Geltungsbereich mit bindendem Charakter verstanden. Im Sinne einer Vorschrift oder Anweisung regeln sie die Handhabung von Tätigkeiten und definieren verbindliche Vorgaben und Einschränkungen.

Leitlinien

Leitlinien haben hingegen den Charakter einer Empfehlung, die auf systematisch entwickelten Erfahrungen und Feststellungen basiert. Durch sie können Tätigkeiten beschleunigt und vereinheitlicht werden, während gleichzeitig die Möglichkeit zur Anpassung auf den Einzelfall erhalten bleibt. Im Rahmen der Richtlinien und Leitlinien sind • die notwendigen Dienstleistungen für die Entwicklung und den Betrieb komplexer BI-Systeme sowie Regelungen zu deren Bezug am externen Markt festzulegen (BI Service und Sourcing Policies), • ein konzeptioneller, globaler Bauplan für die grundlegenden Informationsobjekte der Managementunterstützung zu erarbeiten (Dispositive Datenarchitektur) und • Gestaltungsvorgaben für die Professionalisierung der Entwicklungs-, Reengineering- und Betriebs-Prozesse vorzunehmen (Entwicklungs- und Betriebs-Rahmenbedingungen).

Controlling

Organisation

In der übergreifenden Funktion des Controllings wird die Zielerreichung des integrierten BI-Ansatzes kontinuierlich sichergestellt, indem interne und externe Veränderungen mit Auswirkungen auf die Makro-Ebene überwacht werden und bei Bedarf einen Reengineering-Prozess initiieren. Im Rahmen der Organisation werden die Verantwortlichkeiten und Entscheidungsbefugnisse im BI-Kontext festgelegt. Dies umfasst neben einer dezidierten, institutionalisierten Servicegruppe für Business Intelligence auch die Einbeziehung des Top Management in Entscheidungsgremien und die Kooperation zwischen IT- und Fachbereichen. Die einzelnen Aufgaben der Makro-Ebene werden im Weiteren detailliert. 169

4 Entwicklung und Betrieb integrierter BI-Lösungen

4.3.1

Potenzialplanung Wie die Vorbemerkungen in Kap. 4.1 gezeigt haben, kann mit Informations- und Kommunikationstechnologie der Erfolg eines Unternehmens positiv beeinflusst werden. Für diese Zwecke muss sich der Technologieeinsatz jedoch an den individuellen Bedingungen des Unternehmens ausrichten. Daraus ergibt sich die Bedeutung eines individuell ausgestalteten Rahmenkonzepts für integrierte BI-Anwendungssysteme. Ungenaue oder fehlende Potenzialschätzungen können zu erheblichen Missverhältnissen zwischen Kosten- und Nutzengrößen der angestrebten Systeme führen.

Wirtschaftlichkeit und Wirksamkeit

Die Abb. 4.4 verdeutlicht diesen Sachverhalt. Sie repräsentiert in Form einer Vierfelder-Matrix die generellen Positionierungsmöglichkeiten von BI-Anwendungssystemen und basiert auf den beiden Größen der Wirtschaftlichkeit und der Wirksamkeit.25 Wie die Abbildung verdeutlicht, existiert lediglich ein anzustrebender Gleichgewichtszustand, der – hier als strategisches Gleichgewicht bezeichnet – eine ideale Ausnutzung der Wirksamkeit bei einer hohen Wirtschaftlichkeit repräsentiert. Alle anderen Positionierungen können als Ungleichgewichtssituationen bezeichnet werden. So wird unter dem Strategischen Wirtschaftlichkeitsdefizit die Situation verstanden, in der BI-Anwendungssysteme effektiv das Potenzial nutzen, jedoch nicht effizient entwickelt und umgesetzt werden. Diese Situation kann auftreten, wenn aufgrund mangelnder Kenntnisse bedarfsunangemessene Konzepte, Methoden oder Werkzeuge der BI-Gestaltung Verwendung finden, die zu hohen Entwicklungs- und Betriebskosten führen. Das Strategische Wirksamkeitsdefizit hingegen ist durch die unzureichende Ausnutzung des BI-Potenzials gekennzeichnet. In diesen Fällen sind meist Teilsysteme der Managementunterstützung vorhanden, die – isoliert gesehen – durchaus problemangemessene Lösungen darstellen. Jedoch wird in Ermangelung der Kenntnis des unternehmensspezifischen Gesamtpotenzials nicht der gesamte Erfolgsbeitrag erbracht, der durch ein angemessenes BI-Rahmen25

170

Unter Wirksamkeit wird hierbei der Grad der individuellen Potenzialnutzung verstanden, den BI-Anwendungssysteme im Unternehmen leisten können. Die Wirtschaftlichkeit fokussiert dagegen die monetäre Dimension und präzisiert die Effizienz von BIAnwendungssystemen bei einer gegebenen Wirksamkeit (Heinrich/ Stelzer 2009, S. 117).

4.3 Makro-Ebene konzept erreichbar wäre. Unter der Strategischen Insuffizienz wird hingegen eine völlige Fehleinschätzung des gesamten Komplexes verstanden. Hier erfolgt aufgrund der Unkenntnis des unternehmensindividuellen Potenzials meist eine Überschätzung der Möglichkeiten, die gepaart mit mangelndem Wissen über Konzepte, Methoden und Werkzeuge zu nicht zufrieden stellenden BI-Entwicklungen führen.

Strategisches Wirksamkeitsdefizit

Strategisches Gleichgewicht

Strategische Insuffizienz

Strategisches Wirtschaftlichkeitsdefizit

gering

BI-Wirtschaftlichkeit

hoch

BI-Fehlentwicklungen in der Praxis

gering

hoch

BI-Wirksamkeit Abb. 4.4: Fehlentwicklungen in der Praxis

BI-Wirksamkeit und BI-Wirtschaftlichkeit (modifiziert übernommen aus Heinrich/Stelzer 2009, S. 102)

In der Praxis hat sich gezeigt, dass Mängel häufig durch eine fehlende oder ungenügende Ausschöpfung des Leistungspotenzials der BI-Anwendungssysteme verursacht werden. Daher sind sie in diesem Fall den Bereichen des Strategischen Wirksamkeitsdefizits sowie der Strategischen Insuffizienz zuzuordnen. Häufig sind diese Mängel feststellbar, wenn Unternehmen ausschließlich einen Medienwechsel von papiergebundenen zu elektronischen Berichten vorgenommen haben oder während des Einsatzes der BI-Lösungen mit nicht antizipierten Veränderungen – primär im Bereich der Ablauforganisation – konfrontiert wurden (Kemper 1999, S. 291).

171

4 Entwicklung und Betrieb integrierter BI-Lösungen Abstimmung des Informationsbedarfs

Der Hauptgrund für Mängel liegt in der fehlenden oder unzureichenden Abstimmung der BI-Konzepte mit dem strategischen Management des Unternehmens. Es ist einsichtig, dass das Potenzial von BI-Anwendungssystemen nur vor dem Hintergrund der langfristigen Unternehmensintention – dem sog. Leitbild (engl. Mission, Ward/Peppard 2003, S. 189) – und der daraus abgeleiteten Unternehmensziele bestimmt werden kann.

Methode der kritischen Erfolgsfaktoren

Die wesentliche Aufgabe der BI-Potenzialplanung ist demnach, die Umsetzung der strategischen Ziele optimal zu unterstützen. In der Praxis und in der Wissenschaft hat für diesen Komplex vor allem die Methode der kritischen Erfolgsfaktoren (KEF bzw. critcal success factors, CSF) auf breiter Basis Beachtung gefunden. Diese auf John F. Rockart zurückzuführende Methodik (Rockart 1979; Rockart 1982) basiert auf der in empirischen Studien gewonnenen Erkenntnis, dass die erfolgreiche Umsetzung von Strategien von einer begrenzten Anzahl von Parametern bestimmt wird.

KEF, BSC und SWOT

Eine gelungene Symbiose aus der Erfolgsfaktorenanalyse, dem Konzept der Balanced Scorecard (BSC) (vgl. Kapitel 3.1.8) und der SWOT-Analyse (Strengths, Weaknesses, Opportunities, Threats) zeigt die Abb. 4.5. Mission 3 2

Business objectives

A

1

E D C B

Critical success factors

A

Balanced Scorecard

E D C B A

CSFs Information to measure performance

C

Options for evaluation

Abb. 4.5:

172

Kritische Erfolgsfaktoren zur (Ward/Peppard 2003, S. 211)

B

SWOT CSF

A

SWOT-Bestimmung

4.3 Makro-Ebene Wie deutlich wird, können aus der langfristig angelegten Mission konkrete Unternehmensziele (business objectives) abgeleitet werden, wobei die Balanced Scorecard die Funktion der operativen Messung der Zielerreichung übernimmt26. Hierbei ist zu berücksichtigen, dass ein kritischer Erfolgsfaktor mehrere Unternehmensziele in verschiedener Intensität beeinflussen kann. Erst nach einer Analyse dieser Zusammenhänge sollte mit Hilfe einer SWOT-Analyse festgehalten werden, inwieweit die existierenden Geschäftsprozesse und Systeme der Managementunterstützung eine positive Beeinflussung der Erfolgsfaktoren ermöglichen und welche Potenziale in Zukunft mit Hilfe integrierter BIAnwendungen erschlossen werden können. Anwendungsbeispiel

Die Abb. 4.6 verdeutlicht beispielhaft die Zusammenhänge aus Sicht des IT-Einsatzes im Rahmen geschäftsprozessorientierter BISysteme und der daraus abzuleitenden differenzierten Architekturen und Entwicklungsmodelle.

Mission

Dauer der Geschäftsbeziehung Umsatz pro Kunde und Jahr Anzahl Reklamationen

Messung

Zeit Bestelleingang/-auslieferung Einhaltungsgrad Termine

Unternehmensziele

Messung

Unsere Mission ist es, in unserer Branche der Anbieter mit der weltweit höchsten Kundenorientierung und dem vollständigsten Sortiment zu werden. Bindung guter Kunden

Kritische Erfolgsfaktoren

Auftragserfassung Versandabwicklung Reklamation

Kundenservice Time-to-Market Termintreue

Geschäftsprozessgestaltung

Data-Mining-System zur Kundensegmentierung BI-Anwendung zur Früherkennung kündigungsbereiter Kunden (Churn-Analyse) Operational BI zur Prozesssteuerung

Erforderliche BI-Systeme

Real-time-Anbindung ODS-Architektur Agile BI-Systementwicklung

Abb. 4.6:

Differenzierte BI-Architekturen & -Entwicklungsmodelle

Beispiel aus dem CRM-Umfeld

26 Zum Konzept der BSC vgl. auch Kapitel 3.1.8.

173

4 Entwicklung und Betrieb integrierter BI-Lösungen So ist erkennbar, dass ausgehend von dem unternehmerischen Leitbild die Unternehmensziele abgegrenzt und die kritischen Erfolgsfaktoren identifiziert werden. Auf dieser Basis erfolgt die Gestaltung wirkungsvoller, die kritischen Erfolgsfaktoren unterstützenden Geschäftsprozesse. Es ist offensichtlich, dass diese Geschäftsprozesse in ihrer Ausprägung als direkte wertschöpfende Prozesse und als unterstützende Querschnittsprozesse differenzierte Anforderungen an die BI-Unterstützung stellen. Dieser Sachverhalt bewirkt, dass in größeren Unternehmen üblicherweise unterschiedliche BI-Architekturen für die Datenbereitstellung – wie Data Marts, Core Data Warehouses oder Datendirektdurchgriffe – mit divergierenden Datenaktualitäten (z. B. Real-time, tages-, wochen- oder monatsaktuell) zu koordinieren sind. Hierbei kann die Bandbereite der verwendeten Entwicklungsmodelle von agilen Vorgehensmodellen bis hin zu iterativen Ansätzen mit zyklischer Modulentwicklung reichen. So ist es beispielsweise für zeitkritische Berechnungen im RisikoManagement einer Bank nützlich, agile Vorgehensweisen für die Systementwicklung und eigenständige Data-Mart-Architekturen zu wählen, um untertägig revisionsfähige IT-Lösungen entwickeln zu können. Andere Applikationen – z. B. BI-Anwendungen im Personalwesen – sind häufig nicht zeitkritisch, erfordern jedoch große, harmonisierte Datenbestände verschiedener operativer Vorsysteme, so dass in diesen Fällen iterative Vorgehensmodelle und traditionelle DWH-Strukturen zu wählen wären.

4.3.2

Portfoliomanagement

Beeinflussung Geschäftsprozesse und kritischer Erfolgsfaktoren

In der Makro-Ebene sind abgrenzbare BI-Anwendungssysteme zu identifizieren und zu priorisieren, um auf Basis dieser Informationen ein BI-Projektportfolio zu entwickeln. Hierbei ist es naheliegend, dass vor allem die Systeme Umsetzungspriorität besitzen, die in hohem Maße die unternehmensspezifischen Erfolgsfaktoren (durch wirksame Unterstützung der relevanten Geschäftsprozesse) positiv beeinflussen (vgl. Kapitel 4.3.1). Allerdings sind für eine endgültige Entscheidung auch andere Kriterien einzubeziehen, die eine Wahl der zu entwickelnden BISysteme ebenfalls determinieren. Hier sind insbesondere zu nennen: • Notwendiger Integrationsgrad Komplexe Projekte, für die heterogene technische und/oder organisatorische Komponenten zusammengeführt werden

174

4.3 Makro-Ebene müssen, sind naturgemäß mit einem hohen Risiko des Scheiterns behaftet. • Fehlendes betriebliches Know-how Ähnliches gilt für Projekte, für deren Umsetzung im eigenen Unternehmen bislang kaum Erfahrungswissen existiert. Meist werden Mitarbeiter dieser Projekte im Entwicklungsprozess mit nicht antizipierten Problemen konfrontiert, die den Projekterfolg gefährden und oftmals die Einbindung externer Dienstleister erforderlich machen. • Hoher Aufwand Selbstverständlich sind betriebliche Projekte stets unter ökonomischen Gesichtspunkten zu bewerten. Sämtliche Projekte – auch Projekte strategischer Natur – haben sich aus diesem Grund im Vorfeld Kosten-/Nutzenbetrachtungen zu unterziehen, wobei je nach Projektcharakteristika neben quantitativen auch qualitative Aspekte Berücksichtigung finden können. • Betriebliche Reihenfolge In der Praxis tritt häufig der Fall ein, dass Projekte lediglich dann sinnvoll durchgeführt werden können, wenn andere Vorhaben bereits abgeschlossen sind. So ist es denkbar, dass die Entwicklung eines speziellen BI-Anwendungssystems erst nach erfolgreicher Implementierung spezifischer operativer Vorsysteme erfolgen kann. Besonderheiten bei Pilotsystemen

Ohne Frage hat sich auch die Wahl eines BI-Pilotsystems – also einer ersten BI-Anwendung des integrierten Ansatzes – diesen Kriterien zu stellen. Jedoch spielen gerade hier auch andere Aspekte eine bedeutende Rolle, da das Pilotprojekt den Startpunkt der Entwicklung des integrierten Ansatzes markiert und sämtliche Entscheidungen innerhalb des ersten Entwicklungsprozesses als erfolgskritisch für das Gesamtkonzept angesehen werden müssen. So sollte angestrebt werden, bereits mit der ersten Systementwicklung weite Teile der dispositiven Datenarchitektur zu konkretisieren und eine große Zahl von Endbenutzern funktional zu unterstützen. Die Auswahl eines umfangreichen Pilot-Anwendungsbereiches birgt zwar ein höheres Risikopotenzial, einen erheblichen Mehraufwand für die Lösung schlecht antizipierbarer Probleme leisten zu müssen. Insgesamt überwiegen jedoch die Vorteile eines solchen Vorgehens. Zum einen kann mit Hilfe von umfangreichen Pilotprojekten die Rahmenstrukturen der MakroEbene bereits frühzeitig iterativ umgesetzt, angepasst und auf deren Tauglichkeit hin überprüft werden. Zum anderen kann die 175

4 Entwicklung und Betrieb integrierter BI-Lösungen erfolgreiche Entwicklung eines umfangreicheren BI-Teilsystems als Katalysator für spätere Systementwicklungen dienen, da sich deren Aufwand aufgrund der dann bereits in großen Teilen durchgeführten Konkretisierung der dispositiven Datenarchitektur und der gewonnenen Entwicklungserfahrungen in hohem Maße verringern lässt.

4.3.3

Technologie- und Infrastrukturmanagement Die Makro-Ebene hat sich explizit mit der langfristigen Planung des Technikeinsatzes zur Umsetzung des Gesamtkonzeptes zu befassen. Hierbei sind sowohl Netzinfrastrukturen als auch Hardund Softwarekomponenten von Relevanz, da diese Infrastrukturen aufgrund der hohen Veränderungsdynamik der Technik ständigen Anpassungsprozessen unterliegen und dem im Zeitverlauf starken Wachstum des Datenvolumens gerecht werden müssen.

Wandel technischer Infrastrukturen Technologische Innovationen

Die Pflege der Rahmenkonzepte integrierter BI-Lösungen ist keiner zeitlichen Restriktion unterworfen. Daher ist die Beobachtung und Einschätzung technologischer Innovationsprozesse von entscheidender Relevanz, um erforderliche Migrationsprozesse in den technischen Infrastrukturen initiieren zu können. In der Makro-Ebene sind demnach Planungsgrundlagen zu erarbeiten und konkrete Planungen zu entwickeln, die eine optimierte, auf das Unternehmen ausgerichtete Technikmigration über den Zeitverlauf ermöglichen.27 Zur Präzisierung des Technologieverständnisses werden in der Wissenschaft meist die Begriffe Basis-, Schlüssel-, Schrittmacherund Zukunftstechnologien unterschieden (Heinrich/Stelzer 2009, S. 170 f.) Unter Basistechnologien werden in diesem Zusammenhang existierende Technologien verstanden, die sich etabliert und bewährt haben, von denen jedoch kaum weiteres Veränderungspotenzial zu erwarten ist. Schlüsseltechnologien hingegen sind neuere, am Markt verfügbare Technologien, deren Veränderungspotenzial in den Unternehmungen bislang nicht voll ausgeschöpft worden ist. Ihr Einsatz ist daher jedoch auch meist noch 27

176

Z. B. haben in den letzten Jahren viele Unternehmen ihre proprietären Benutzungsoberflächen durch Web-Frontends ersetzt, nachdem diese nach längerer Entwicklungszeit erstmalig wirkungsvoll einsetzbar waren.

4.3 Makro-Ebene mit nicht antizipierbaren Einsatzproblemen verbunden. Schrittmacher- und Zukunftstechnologien sind im Entwicklungsstadium befindliche oder sich abzeichnende Technologien, von denen erhebliches Veränderungspotential erwartet wird, die aber bis dato noch keine Relevanz im Rahmen der organisatorischen Gestaltung besitzen (Kemper 2003, S. 233). Beispiele

Ein Beispiel für eine Basistechnologie im BI-Kontext ist der Einsatz von relationalen Datenbank-Systemen. Die Nutzung von Radio Frequency ID zur funkbasierten Objektidentifikation (vgl. auch Kapitel 5.7) oder von Sensornetzwerken können als Schlüsseltechnologien angesehen werden. Beispiele für Schrittmacheroder Zukunftstechnologien sind der Einsatz von Technologien zur flexiblen Verteilung von DWHs über verschiedene Rechner im Internet mit Technologien des „Grid Computing“ oder die Analyse des emotionalen Gehalts textueller Inhalte.

Schalenmodell

Eine Visualisierung des Zusammenhangs in Form eines Schalenmodells erfolgt in der Abb. 4.7. Schrittmacher- / ZukunftsTechnologien

Einzelne Technik

SchlüsselTechnologien

Entwicklungslinie

BasisTechnologien

Abb. 4.7:

Integrierte BIAnwendungssysteme

Entwicklungsbereich

Schalenmodell (modifiziert übernommen aus Steinbock 1994, S. 33)

Im Mittelpunkt des Modells befindet sich das betriebliche Anwendungsfeld, hier im Beispiel „Integrierte BI-Anwendungssysteme“. Die umschließenden Schalen repräsentieren die Räume, in denen die relevanten Schrittmacher-/Zukunftstechnologien, Schlüssel- und Basistechnologien für die Umsetzung des gewählten Anwendungsbereiches zu positionieren sind. Die kleineren Kreise stellen die einzelnen Techniken dar, wobei der augenblickliche Entwicklungsstand dieser einzelnen Techniken 177

4 Entwicklung und Betrieb integrierter BI-Lösungen aufgrund der Positionierung innerhalb des Schalenmodells deutlich wird. Eine Entwicklungslinie repräsentiert den mutmaßlichen Entwicklungsverlauf einer neuen Technologie. Entwicklungsbereiche – in der Abbildung als „Wolke“ dargestellt – stehen für zusammengehörende Gestaltungskomplexe, die durch ein Set von Techniken unterstützt werden können.

Skalierbarkeit technischer Infrastrukturen Die gravierende Datenzunahme von integrierten BI-Lösungen ergibt sich bereits aufgrund der Besonderheiten von Data Warehouses. Laut Definition (vgl. Kapitel 2.2) werden die Daten in diesen Systemen historienbildend abgelegt. Sie werden demnach nicht gelöscht oder überschrieben, sondern stets durch ETLProzesse um neue Daten ergänzt. Des Weiteren bedingen auch die bei der Umsetzung des integrierten BI-Konzeptes zeitlich verschachtelten Entwicklungen von BI-Systemen eine ständige Ausweitung der dispositiven Datenhaltungskomponente. So ist es nicht unrealistisch, dass zu Beginn des Entwicklungsprozesses aufgrund des eingeschränkten Abbildungsbereiches und der noch geringen Historientiefe lediglich einige hundert Megabyte an dispositiven Daten verwaltet werden müssen, während im Verlaufe der Zeit aufgrund der sukzessiven Erweiterung des BI-Konzeptes und der sich bildenden Datenhistorie das Datenvolumen bis in den Tera- bzw. Petabyte-Bereich wachsen kann. Die auf der Makro-Ebene des Rahmenkonzepts zu installierende Planung der technischen Infrastrukturen hat sich daher der herausfordernden Aufgabe zu stellen, eine adaptive Skalierbarkeit der notwendigen Technikausstattung über den Zeitverlauf zu gewährleisten.

4.3.4

BI Service und Sourcing Policies

Notwendigkeit von BI Services

Lösungen zur betrieblichen Entscheidungsunterstützung basieren heute auf umfangreichen, vielschichtigen Architekturen und sind fachlich sowie technisch hoch integriert. Diese Komplexität stellt die Unternehmen vor die besondere Herausforderung, ein breites Spektrum an spezifischem Expertenwissen zu koordinieren. Dabei ist es nicht zwangsläufig zielführend, alle Kompetenzen intern aufzubauen und vorzuhalten. Unternehmen und ITAbteilungen, die alle Dienstleistungen für die Entwicklung und den Betrieb integrierter BI-Lösungen bündeln, sind eher die Ausnahme. In Zeiten der Arbeitsteilung und Spezialisierung wird

178

4.3 Makro-Ebene die eigene Expertise durch den selektiven und zielgerichteten Bezug von externen Dienstleistungen ergänzt, um das Leistungspotential des BI-Ansatzes ausschöpfen zu können. Eine methodische Voraussetzung ist die trennscharfe Abgrenzung der einzelnen Bausteine der Bereitstellung und des Betriebs von BI-Lösungen. Die Definition von solchen BI Services dient als Grundlage für eine wirkungsvolle Arbeitsteilung in der Umsetzung des BI-Konzepts.

BI Services

TemplateBereitstellung

TemplateBetrieb

WerkzeugBereitstellung

WerkzeugBetrieb

HardwareBereitstellung

HardwareBetrieb

Informationszugriff

ContentBetrieb

Informationsgenerierung /-distribution

ContentBereitstellung

Datenbereitstellung

Geschäftsnähe

Als Ausgangspunkt dient (vgl. Abb. 4.8) ein Ansatz zur Differenzierung von BI Services (Baars et al. 2007). Das Konzept spannt drei Dimensionen auf, die für die Abgrenzung von BI Services als erforderlich angesehen werden: die Komponenten, die Geschäftsnähe und die Lebenszyklusphasen.

Lebenszyklusphasen

Abb. 4.8: Komponenten

Differenzierung von BI Services (Horakh et al. 2008)

Die Dimension Komponenten umfasst die Architekturebenen des BI-Ordnungsrahmens, im Detail die Datenbereitstellung (vgl. 179

4 Entwicklung und Betrieb integrierter BI-Lösungen Kapitel 2), die Informationsgenerierung/-distribution (vgl. Kapitel 3.1 und Kapitel 3.2) sowie den Informationszugriff (Kapitel 3.3).

Geschäftsnähe

Die Dimension Geschäftsnähe unterscheidet infrastrukturorientierte und damit eher technische Services von stärker fachlich orientierten Dienstleistungen. Das Kernkriterium zur Differenzierung entlang dieser Dimension ist das Ausmaß an fachlicher Verantwortung, das ein Service-Nutzer einem Service-Anbieter überträgt. Je mehr Verantwortung für den eigentlichen Inhalt auf den Service-Anbieter übergeht, desto mehr muss dieser mit der fachlichen und kontextspezifischen Semantik des Anwendungsbereichs vertraut sein. Bezüglich der Geschäftsnähe werden die folgenden vier Schichten unterschieden: • Hardware meint die relevante Rechen-, Speicher- und Telekommunikationsinfrastruktur, die notwendig ist, um eine oder mehrere BI-Komponenten einzusetzen. • Werkzeuge umfassen das gesamte Spektrum an BI-Tools, also ETL-Werkzeuge, Data-Warehouse-Applikationen und Tools für Reporting und Visualisierung. • Templates sind vorkonfigurierte Anwendungen und vorbereitete Inhalte, die sich an unternehmensspezifische Anforderungen anpassen lassen (vgl. hierzu auch Kapitel 3.2.3). • Content ist unternehmensspezifisch angepasster Inhalt. Ein Anbieter auf dieser Ebene verantwortet die Definition, Sammlung, Strukturierung, Transformation und/oder Darstellung der entscheidungsrelevanten Daten.

Lebenszyklus

Die dritte erforderliche Dimension betrachtet die Phasen im Lebenszyklus der BI-Lösung: Es ist zu unterscheiden, ob ein Service primär auf die Entwicklung bzw. die Bereitstellung einer Komponente ausgerichtet ist oder auf deren Betrieb. Die Abb. 4.9 verdeutlicht die konkrete Spezifikation von Services anhand einiger Beispiele.

BI Service Policies Die Umsetzung des Konzepts erfolgt durch Richtlinien und Leitlinien in Form von BI Service Policies. Grundlegend ist hierfür, dass eine BI-Lösungen als Komposition von BI Services verstanden wird:

180

Geschäftsnähe

4.3 Makro-Ebene

Content

z.B. Sicherung der fachlich-inhaltlichen Datenqualität

z.B. Durchführung von Abweichungsanalysen im Data-Mining

z.B. Fachliche Bereitstellung von entscheidungsrelevanten, qualitativen Inhalten

Templates

z.B. Vordefinition von Workflows für Extraktionsprozesse

z.B. Entwicklung von Standards für Methodenund Datenauswahl bei Abweichungsanalysen

z.B. Bereitstellung von Rollen- oder Gruppenbezogenen Personalisierungsprofilen

Werkzeuge

z.B. Betrieb einer Data-WarehouseUmgebung

z.B. Bereitstellung einer vorkonfigurierten Data-Mining-Suite

z.B. Entwicklung und Betrieb von Portalsoftware

Hardware

z.B. Aufbau und Betrieb eines StorageSystems inkl. Storage Area Networks

z.B. Bereitstellung von performanten Workstations für Data-Mining-Analysen

z.B. Betrieb einer redundanten Netzanbindung für den stabilen und performanten Portalzugang

Datenbereitstellung

Informationsgenerierung / -distribution

Informationszugriff

Komponenten Abb. 4.9:

Komposition

Beispiele Service-Spezifikationen

Wie aus der Abb. 4.10 ersichtlich, sind die einzelnen Services für sich alleine stehend nur als Bausteine zur effizienten Gestaltung von BI-Lösungen für eine Vielzahl von Kunden. Erst durch die Komposition mehrerer komplementärer BI Services entsteht eine ganzheitliche BI-Lösung, die – unter Berücksichtigung von Konsistenz und Wiederverwendbarkeit – den konkreten Kundenanforderungen entspricht (Horakh et al. 2008). Durch BI Service Policies werden diese Rahmenstrukturen festgelegt und dokumentiert. Als Beispiele für die Beschreibung seien die Service-Bezeichnung, die Leistungsbeschreibung, der geschätzte Aufwand und die hinterlegten Service-Levels genannt.

Dokumentation in BI-ServiceBibliotheken

Für die BI Governance ist es von hoher Wichtigkeit, dass auch langfristig der Überblick und die Transparenz über die eingesetzten BI Services und BI-Lösungen gewahrt bleiben. Hierzu können BI-Service-Bibliotheken beitragen, indem sie die Definition der Services, deren Nutzung und Interdependenzen sowie die mit den Nutzern vereinbarten Service-Levels dokumentieren.

181

4 Entwicklung und Betrieb integrierter BI-Lösungen

BI-Lösung

BI-Lösung

BI-Lösung

Transparente Nutzung von BI-Services

BI-Services

BI-Services

BI-Services

Abb. 4.10: BI Services und BI-Lösungen (Horakh et al. 2008)

BI Sourcing Policies Durch den externen Bezug von Dienstleitungen können kurzfristig dringend benötigte Kompetenzen und Erfahrungen in BIProjekte einbezogen werden, ohne eine langfristige Bindung oder einen langwierigen Aufbau eigener Kompetenzen in Kauf nehmen zu müssen. BI Sourcing Policies

Als Regularium in Form von BI Sourcing Policies sind Richtlinien und Leitlinien von höchster Bedeutung. Sie definieren die Kriterien, anhand derer die externe Vergabe von Arbeitsaufträgen durchgeführt werden darf. Im Detail können für alle drei Dimensionen der BI Services Vorgaben und Empfehlungen ausgesprochen werden. Bei der Dimension „Geschäftsnähe“ existieren z. B. für die Infrastruktur und die Software-Werkzeuge oftmals übergeordnete IT-Rahmenkontrakte, die bei einer Auswahlentscheidung zu berücksichtigen sind. Diese Vorgaben lassen sich auch über mehrere Dimensionen kombinieren: so kann für den Betrieb (Lebenszyklusphase) eines bestimmten Werkzeugs (Geschäftsnähe) im Bereich der Datenbereitstellung (Komponente) festgelegt werden, dass nach externer Ausschreibung ein zusätzliches Angebot von einem internen BI-Dienstleister einzuholen ist.

4.3.5

Dispositive Datenarchitektur Eine der komplexesten und anspruchsvollsten Aufgaben der Makro-Ebene ist die Entwicklung der unternehmensumfassenden dispositiven Datenarchitektur, welche die Grundstrukturen für

182

4.3 Makro-Ebene

Datenarchitektur

Dispositive Datenarchitektur

den gesamten Bereich der Informationsversorgung des Managements festlegt. Der Begriff Datenarchitektur steht im Kontext der Datenmodellierung für den Aufbau eines globalen Bauplans zur Abbildung der grundlegenden Informationsobjekte und deren Beziehungen untereinander (Reindl 1991, S. 281; Rhefus 1992, S. 33). Unter der dispositiven Datenarchitektur ist somit der konzeptionelle Bauplan führungsrelevanter dispositiver Daten auf einer hohen Abstraktionsebene zu verstehen. Bei den folgenden projektspezifischen Datenmodellierungen dient sie als Referenzstruktur, an der sich sämtliche BI-Entwicklungen auszurichten haben. Durch die systemspezifischen Konkretisierungen und Verfeinerung entsteht im Zeitverlauf ein konkretes dispositives Datenmodell, das weitestgehend applikationsklassenneutral – also nahe der 3NF (vgl. Kapitel 2.4.1) – in den dispositiven Basisdatenhaltungssystemen umgesetzt werden sollte. Abb. 4.11 zeigt den Zusammenhang.

Abstimmung der dispositiven Datenarchitektur mit der operativen/externen Datenwelt

ArchitekturEbenen — jeweils dargestellt durch Entitäts- und Beziehungsmengen

BI-Projekt- Abstimmung Datenmodell 1

Abstimmung

Dispositive Datenarchitektur

BI-ProjektDatenmodell n

Zeit

Konkretisierung

Konkretisierung

Dispositives Datenmodell (nahe der 3NF, applikationsklassenneutral) Operative und externe Datenwelt

Daten-Transformation

... Produktion

Vertrieb

Einkauf

Externe Daten

Abb. 4.11: Dispositive Datenarchitektur und dispositives Datenmodell (modifiziert übernommen aus Kemper 1999, S. 298)

183

4 Entwicklung und Betrieb integrierter BI-Lösungen Dekomposition

Deutlich wird, dass die Datenarchitektur über mehrere Ebenen verfügt, wobei die Entwicklung auf der höchsten Ebene beginnt und mit Hilfe einer sukzessiven Dekomposition in die gewünschte Detaillierung überführt wird. Auf diese Weise werden die relevanten Entitäts- und Beziehungsmengen (-typen), die grundlegenden Hierarchisierungsformen und die betriebswirtschaftlich harmonisierten Attributierungen modelltechnisch abgebildet, die auf der Basis der Potenzialplanung (vgl. hierzu Kapitel 4.3.1) in intensiver und anspruchsvoller Arbeit abzuleiten und als Vorgaben zu konkretisieren sind. Es sei an dieser Stelle darauf hingewiesen, dass in jedem Falle eine Prüfung erforderlich ist, ob die gewünschten Strukturen sich aus den operativen/externen Datenbeständen bilden lassen, da ansonsten eine spätere datenspezifische Konkretisierung unmöglich ist. Die negativen Konsequenzen einer unterlassenen Abstimmung mit den operativen/externen Datenbeständen seien im Weiteren an einem konkreten Anwendungsbeispiel demonstriert: So ist in einem realen Fall aus dem Bereich des Versicherungswesens das „Versicherte Objekt“ in der dispositiven Datenarchitektur als wünschenswerter Kern-Entitätstyp identifiziert worden. Anschließend wurden auf der Basis der Datenarchitektur BI-Prototypen mit generierten Daten erzeugt, die Geschäftsanalysen auf der Basis der versicherten Objekte ermöglichten. Beispielsweise wurden dem Vorstand in diesem Zusammenhang DemoAnalysen präsentiert, bei denen mit Hilfe einer Objektselektion sämtliche korrespondierenden Versicherungsverträge des Unternehmens dargestellt wurden. Erst im Nachhinein wurde jedoch deutlich, dass dieser Typ von Auswertungen nicht mit den realen operativen Daten des Unternehmens durchführbar war, da das „Versicherte Objekt“ im operativen Kontext keine identifizierbare Entität darstellte, sondern lediglich in Form von Attributen mit unterschiedlichen Kodierungen in diversen spartenspezifischen Entitätsmengen des Typs „Vertrag“ eingebunden war.

4.3.6

Entwicklungs- und Betriebs-Rahmenbedingungen Im Rahmen der Makro-Ebene sind Gestaltungsvorgaben für die Mikro-Ebene festzulegen. Die Aufgabe dieses Gestaltungsrahmens liegt in der Professionalisierung der Entwicklungs-, Reengineering- und Betriebs-Prozesse durch eindeutige Vorgaben.

184

4.3 Makro-Ebene Die Entwicklung und Dokumentation von Richtlinien und Leitlinien bieten sich v. a. für die folgenden Bereiche an: • Aktivitäten, Phasen, Artefakte, Methoden, Werkzeuge und Rollen für die Systementwicklung bzw. das Reengineering. • Kulturkonforme Sicherheits- und Zugriffskonzepte. • Wissensmanagementintegration. • Benutzungsoberflächen und Portalintegration. Diese Punkte werden im Folgenden näher ausgeführt: • Aktivitäten, Phasen, Artefakte, Methoden, Werkzeuge und Rollen für die Systementwicklung bzw. das Reengineering EntwicklungsModell

Verbindliche Vorgaben für die reale Ausgestaltung der im Unternehmen Verwendung findenden Entwicklungsmodelle betreffen die exakte Beschreibung der durchzuführenden Aktivitäten und ihre Bündelung zu Phasen. Des Weiteren werden die zu entwickelnden Artefakte der einzelnen Phasen – also die zu erstellenden Ergebnistypen – exakt in ihrer Struktur mit Hilfe von Mustern vorgegeben, damit der jeweilige Projektfortschritt anhand von Meilensteinen leicht überprüft werden kann. Methoden und Werkzeuge werden einzelnen Aktivitäten oder Phasen verbindlich zugeordnet, um eine intersubjektive Nachvollziehbarkeit und hohe Produktivität der Entwicklungs/Reengineering-Prozesse sicherzustellen. Mit Hilfe von Rollen werden erforderliche Erfahrungen und Kenntnisse dokumentiert, die Mitarbeiter als Rollenträger aufweisen müssen, um erfolgreich spezifische Aktivitäten(-bündel) durchführen zu können. • Unternehmungskulturkonforme Sicherheits- und Zugriffskonzepte Das Sicherheitskonzept für BI-Anwendungssysteme betrifft zum einen die grundsätzlich für alle betrieblichen Informationssysteme relevanten Aufgabenstellungen wie etwa Schutz vor unternehmensexternem und -internem Missbrauch, Zerstörung oder Manipulation sowie vor der Gefahr der Systembeschädigung oder des Systemausfalls durch technisch bedingte Probleme bzw. umweltbedingte Faktoren.

Kulturelle Aspekte

Zum anderen sind jedoch für integrierte BI-Systeme vor allem die Aspekte von besonderer Relevanz, die sich aus einer weitestgehend unternehmensumfassenden dispositiven Datenhaltung er185

4 Entwicklung und Betrieb integrierter BI-Lösungen geben. Mit einer logisch zentralisierten, konsistenten Datenhaltung wird erstmalig in den Unternehmungen die Möglichkeit geschaffen, einen Großteil der führungsrelevanten Daten mit Hilfe einer integrierten Systemlandschaft zu recherchieren und auszuwerten. Diese Fähigkeit, die sicherlich für die Durchführung aperiodischer, ereignisorientierter Analysen der Gesamtunternehmung sinnvoll zu nutzen ist, kann jedoch im Rahmen der Abwicklung des Tagesgeschäftes erhebliche Probleme bereiten. Dieses ist vor allem dann der Fall, wenn – wie empirisch belegt – die Nutzung der dispositiven Datenhaltung zu Kompetenzüberschreitungen, Delegationsdurchgriffen oder Verletzungen von Verantwortungsbereichen führt (Kemper 1999, S. 308). Innerhalb der Makro-Ebene ist daher die Aufgabe zu lösen, die Datenzugriffsberechtigungen der Benutzerrollen so zu gestalten, dass zum einen das der Technik inhärente Potenzial genutzt wird und zum anderen ein Konflikt mit der Unternehmenskultur vermieden wird. • Wissensmanagementintegration Modell- und Ergebnisintegration

Ähnliche kulturell-organisatorische Aspekte kommen auch bei der Integration von BI-Inhalten in die Wissensmanagementsysteme des Unternehmens zum Tragen. So sind auf der MakroEbene neben den technischen Vorgaben, welche die IT-basierte Umsetzung der Distribution von BI-Wissen betreffen, v. a. die betroffenen organisatorischen Rahmenbedingungen hierfür zu gestalten (vgl. Kapitel 3.2.1). Fragen von Zugriffsberechtigungen, Anreizstrukturen oder Qualitätssicherungen sollen hier lediglich als Beispiele herangezogen werden, um das komplexe Gestaltungsgebiet zu umreißen. • Benutzungsoberflächen und Portalintegration

Corporate Identity Mit Hilfe der Benutzungsoberflächen und der Portalintegration und Style Guides werden die BI-Teilsysteme zu einem aus Benutzersicht logisch einheitlichen System integriert und die Funktionalitäten in situationsspezifischer, rollenabhängiger und benutzerindividueller Form präsentiert. Daher sind bereits in der Makro-Ebene verbindliche Vorgaben für die generelle äußere Erscheinungsform und funktionale Struktur der Mensch-Maschine-Schnittstelle festzulegen. Hierbei müssen sowohl die Aspekte der Corporate Identity – wie etwa die Einbindung von Logos oder die Verwendung von Farben – als auch die grundsätzlichen Style Guides in Bezug auf die Benutzerfreundlichkeit der Bedienungselemente – wie z. B. Bildschirmaufbau, Tastenbelegung, Ausnahmebehandlung, Design der Berichte und Geschäftsgrafiken usw. – berücksichtigt 186

4.3 Makro-Ebene werden. Hierbei sind für den Business-Intelligence-Bereich v. a. die Ergebnisse der Disziplin des Information Design relevant, die sich mit der Aufbereitung von Informationen beschäftigt mit dem Ziel, diese den Menschen möglich effektiv und effizient zugänglich zu machen (Horn 1999, S. 15).

4.3.7

Controlling Ein umfassendes Controlling beinhaltet eine erfolgsorientierte Planung, Überwachung und Steuerung des gesamten MakroBereichs, wobei vor allem die Kompatibilität der einzelnen Komponenten über den Zeitverlauf sichergestellt werden soll. Die Abb. 4.12 verdeutlicht diese Zusammenhänge. Unternehmensstrategie

Rahmenbedingungen

Veränderungsprozesse

aufgrund von Wettbewerbskräften und neuen Technologien

Ableitung

organisatorische verhaltensorientierte technologische

Ableitung

Externe Impulse

Strategisches Controlling des Unternehmens

Controlling der Makro-Ebene Potenzialplanung

Portfoliomanagement

BI-Services & Sourcing

Dispositive Datenarchitektur

Technologie- & Infrastrukturmanagement

Feedback

Feedback

Entwicklung

Betrieb

Controlling der Mikro-Ebene

Interne Impulse

Entwicklungs- & BetriebsRahmenbedingungen

Abb. 4.12: Controlling der Makro-Ebene Wie ersichtlich ist, besteht eine enge Verzahnung zwischen dem strategischen Controlling des Unternehmens, dem Controlling der Makro-Ebene und dem Controlling der Mikro-Ebene. Ein wesentliches Instrument hierfür sind die in der Potentialplanung entwickelten Ziel- und Kennzahlensyteme, die beispielsweise in Form einer BSC konkretisiert werden können (vgl. hierzu Kapitel 4.3.1) Strategisches Controlling

Aufgabe des Strategischen Controlling ist es, mit Hilfe qualitativer Methoden und Verfahren zu analysieren, inwieweit die strategische Ausrichtung des Unternehmens noch den sich im Zeitver187

4 Entwicklung und Betrieb integrierter BI-Lösungen lauf wandelnden Wettbewerbskräften und Technologieentwicklungen entspricht. Diese Veränderungsprozesse sind mit den sich ebenfalls im Zeitverlauf wandelnden unternehmensinternen Rahmenbedingungen abzustimmen.

Externe Impulse

Die Unternehmensstrategie und die organisatorischen, verhaltensorientierten und technologischen Rahmenbedingungen dienen als Grundlage für die Ableitung der Potenzialplanung (vgl. Kap. 4.3.1). Veränderungen auf Ebene des Strategischen Controllings lösen – aus Sicht des BI-Ansatzes – als externe Impulse eine Überprüfung des Rahmenkonzepts auf der Makro-Ebene aus.

Controlling der Makro-Ebene

Im Bereich der Makro-Ebene existieren Interdependenzen zwischen der Potenzialplanung und der sich daraus ableitenden Aktivitäten zur Abgrenzung eines BI-Projektportfolios, der Bestimmung von BI Services und -Sourcing, der Gestaltung der dispositiven Datenarchitektur und des adäquaten Technologieund Infrastruktureinsatzes. Deren jeweilige Ausprägungen beeinflussen wiederum die Rahmenbedingungen für Entwicklung und Betrieb.

Controlling der Mikro-Ebene

Das Controlling der Mikro-Ebene stellt sicher, dass die BIAnwendungssysteme in Entwicklung und Betrieb die Wirtschaftlichkeits- und Wirksamkeitsziele erreichen und den sich aus Benutzersicht wandelnden Anforderungen gerecht werden.

Interne Impulse

Aus den laufenden BI-Projekten und -Services der Mikro-Ebene erfolgt zu definierten Zeitpunkten ein Feedback an die Komponenten des Makro-Bereichs, z. B. in Form von aggregierten Statusmeldungen zu strategisch relevanten Zielerreichungen, Planabweichungen und Risiken. Größere Abweichungen oder Risiken können als interne Impulse ebenfalls eine Überprüfung des Rahmenkonzepts der Makro-Ebene auslösen.

Revision der Makro-Ebene

Neben den beschriebenen Anlässen durch interne oder externe Impulse können die Controlling-Aktivitäten der Makro-Ebene auch zu definierten Zeitpunkten in Form sog. Controllingpunkte durchgeführt werden (vgl. Abb. 4.2). Im Falle relevanter Abweichungen zwischen der existierenden und der anzustrebenden Ausgestaltung des Rahmenkonzepts wird eine Entscheidung über ein Revision der Makro-Ebene getroffen.

Abstimmung von Mikro- und Makro-Ebene

In der Folge von Änderungen sind ebenfalls Verträglichkeitsanalysen zwischen den bereits realisierten BI-Anwendungssystemen und der überarbeiteten Rahmenplanung durchzuführen. Diese werden in Abb. 4.2 als Controllingpunkte zur Abstimmung von Mikro- und Makro-Ebene bezeichnet. Im Bedarfsfalle initiieren

188

4.3 Makro-Ebene die Ergebnisse dieser Controllinganalysen einen ReengineeringProzess der existierenden BI-Systeme, um die Kompatibilität zwischen der neu gestalteten Makro-Ebene und der Mikro-Ebene wieder herzustellen.28

4.3.8

Organisatorische Gestaltung Der Aufgabenbereich der Organisation beschäftigt sich mit der unternehmensspezifischen Arbeitsteilung aller notwendigen Tätigkeiten für Entwicklung und Betrieb des integrierten BIAnsatzes. Hierbei sind die folgenden Charakteristika zu berücksichtigen: • Endgültige, zeitstabile Lösungen werden nicht erarbeitet: Sämtliche Aufgaben der Makro-Ebene sind zeitlich unbeschränkte Daueraufgaben. Sie sind kontinuierlich durchzuführen, da alle Komponenten im Zeitverlauf aufgrund der Veränderungen innerbetrieblicher Realitäten und unternehmensexterner Rahmenbedingungen ständig überprüft und angepasst werden müssen. • Aufgabenbündel besitzen strategische Bedeutung: Aufgrund ihrer übergreifenden Ausrichtung besitzen v. a. die im Makro-Modell abgegrenzten Aufgaben elementare Bedeutung für den Unternehmenserfolg. • Aufgabenlösungen verlangen ausgeprägte Koordination: Für die Lösung der Aufgaben ist eine enge Abstimmung zwischen Management, Fachbereichen und IT-Abteilung erforderlich. • Aufgaben verlangen interdisziplinäre Kompetenzen: Für eine erfolgreiche Aufgabenumsetzung im Bereich der Makro-Ebene sind Mitarbeiter erforderlich, die fundierte Kenntnisse in den Bereichen Betriebswirtschaft und Informationstechnologie besitzen und zusätzlich eine hohe Sozialkompetenz aufweisen. Diese Merkmale verdeutlichen die Notwendigkeit einer Verankerung auf hoher hierarchischer Ebene und die Einbeziehung von

28

So würde z. B. eine Revision der Makro-Ebene bzgl. des Einsatzes von Frontend-Systemen (Ablösung proprietärer Frontends zu Gunsten von Web-Frontends) zu einer entsprechenden Überprüfung und ggf. auch Anpassung der Altsysteme führen.

189

4 Entwicklung und Betrieb integrierter BI-Lösungen Mitarbeitern verschiedener orientierter Fachrichtungen.

betriebswirtschaftlicher

und

IT-

Hierbei stehen aufbauorganisatorische Strukturen wie BI Governance Committees und BI Competence Center sowie ablauforganisatorische Formen der Kooperationen zwischen IT- und Fachbereichen im Fokus.

Controlling

Die Abb. 4.13 verdeutlicht das Zusammenspiel der organisatorischen Komponenten in Form eines generischen Ansatzes. Dieser verdeutlicht die grundlegende Aufgabenteilung der organisatorischen Komponenten und ist nach Anzahl und Heterogenität strategischer Geschäftsfelder, primärer wertschöpfender Geschäftsprozesse und sekundärer, unterstützender Geschäftsprozesse stets unternehmensindividuell zu konkretisieren.

BI Governance Committee

Sicherstellung der Strategiekonformität

BI Competence Center(s) — BICC(s)

Linking Pin: IT, Fachbereich, Management

Makro-Ebene des BI-Rahmenkonzepts Strategie Potenzialplanung Portfoliomanagement Technologie- & Infrastrukturmanagement

Governanceaufgaben

Richtlinien & Leitlinien BI-Service- & Sourcing-Policies Dispositive Datenarchitektur Entwicklungs- & Betriebs-Rahmenbedingungen

Abb. 4.13: Governance – organisatorische Implementierung Im Folgenden werden die Komponenten des Ansatzes detailliert und eine beispielhafte Implementierung des Governance-Ansatzes innerhalb einer Konzernstruktur vorgestellt.

BI Governance Committees Innerhalb der Makro-Ebene fallen Entscheidungen mit unternehmensweiter Auswirkung auf die Managementunterstützung. 190

4.3 Makro-Ebene So kann z. B. ein zukunftsorientierter, strategischer Technologiewechsel eines DWH umfangreiche Anpassungen in zahlreichen Fachbereichsanwendungen nach sich ziehen. Es bedarf daher einer oder mehrerer bereichsübergreifender Entscheidungsinstanzen, die über grundlegende Fragestellungen zu Entwicklung und Betrieb bestimmen. Committees

In der IT haben sich Gremien als organisatorisches Konstrukt zur übergeordneten Entscheidung, Koordination und Kontrolle bewährt. In Form von sog. Committees (Lenkungsausschüssen) werden im Rahmen von Sitzungen zentrale Fragestellungen von hochrangigen Führungskräften diskutiert und beschlossen (Wieczorrek/Mertens 2008, S. 44 f.).

BI Governance

Für die Managementunterstützung bedarf es eines separaten höchsten Lenkungs- und Entscheidungsgremiums, das häufig unter der Bezeichnung „BI Governance Committee“ geführt wird (Larson/Matney 2004). Um wirkungsvoll Vorgaben definieren und Entscheidungen treffen zu können, muss die personelle Besetzung auf einer hohen hierarchischen Ebene erfolgen und die wichtigsten, mit BI-Technologien unterstützten, Geschäftsbereiche repräsentieren (Watson et al. 2004, S. 442 f.).

Committee

Aufgaben & Inhalte

Dezentrale BI Governance Committees

Die Mitglieder eines derart besetzten Gremiums kennen die Unternehmensstrategie und die betriebswirtschaftlichen Teilstrategien – bzw. haben sie aktiv mitgestaltet – und sichern somit im Rahmen der Potenzialplanung die Strategiekonformität des BIAnsatzes. Weitreichende strategische Entscheidungen im Portfolio- oder im Technologie- und Infrastrukturmanagement können ebenfalls in dieses oberste Gremium getragen werden. Für die weiteren Gestaltungsbereiche der Makro-Ebene dient das Gremium als oberste Beschluss- und Eskalationsinstanz. So können beispielsweise im Rahmen der Richtlinien zentrale Kriterien zur strategischen Priorisierung von BI-Anwendungssystemen und eine Budget-Obergrenze für dezentrale, fachbereichsnahe BIEntwicklungsprojekte verabschiedet werden. Bei nicht auflösbaren Ressourcenkonflikten im Rahmen des BI-Portfolios kann das Gremium als finale Entscheidungsinstanz z. B. die Zurückstellung von Projekten beschließen oder zusätzliches Budget für den Bezug von externen Kapazitäten bewilligen. Neben dem obersten Entscheidungsgremium kann das unternehmensspezifische BI-Konzept durch den Einsatz weiterer untergeordneter Gremien unterstützt werden. Bei großen Unternehmen, die in mehreren Geschäftsfeldern aktiv sind, können dezentrale „BI Governance Committees“ die BI-Aktivitäten der 191

4 Entwicklung und Betrieb integrierter BI-Lösungen jeweiligen Tochterunternehmen koordinieren. Weitere bereichsübergreifende Gremien können für operative technische oder fachliche Themen eingesetzt werden, wie z. B. die Prüfung und Sicherstellung der Datenqualität. Zusammensetzung und Frequenz der Zusammenkunft dieser Gruppen sind individuell von der Aufgabenstellung und deren unternehmensspezifischer Relevanz zu bestimmen.

BI Competence Center

BICC

Verbreitung

Hierarchische Einordnung

Die Aufgabenvielfalt und -komplexität der Makro- und MikroEbene sowie der Bedarf an interdisziplinären Lösungsansätzen zeigen die Notwendigkeit einer adäquaten institutionalisierten und eigenständigen BI-Organisationseinheit. Ihr kommt die Aufgabe zu, als organisatorische Schnittstelle zwischen den Vertretern der IT, der Fachbereiche und des Managements zu fungieren. In Praxis und Literatur hat sich hierfür die Bezeichnung „Business Intelligence Competence Center“ mit der Abkürzung „BICC“ etabliert (Rayner 2001; Miller et al. 2006; Gansor et al. 2010). Wie empirisch belegt, haben die meisten Unternehmen mit BILösungen in Wachstums- und Konsolidierungsphasen die Notwendigkeit einer selbständigen Organisationseinheit für die Entwicklung und den Betrieb von Business Intelligence erkannt (im Folgenden Unger/Kemper 2008). So hatten in einer Studie von 2007 bereits drei Viertel der befragten Unternehmen eine solche Einheit oder planten ihre zeitnahe Einführung. Insbesondere große und sehr große Unternehmen treiben die Etablierung solcher Einrichtungen aktiv voran. In der Praxis wird die IT-nahe Einbettung der BI-Unterstützungseinheiten favorisiert, wobei allerdings ein signifikanter Zusammenhang zur Unternehmensgröße besteht. Während kleine Unternehmen eine Integration direkt unterhalb der Geschäftsführungsebene präferieren, wächst mit zunehmender Größe des Unternehmens die Tendenz, die Unterstützungseinheiten als Bestandteil der zentralen IT-Bereiche zu integrieren. Die Personalausstattung einer BI-Einheit, die betreuten Benutzerzahlen sowie das zugeordnete Datenvolumina variieren dabei ganz erheblich – was angesichts der Heterogenität des Umfelds, der Abhängigkeit von den wahrgenommenen Aufgaben sowie der Heterogenität der betreuten BI-Lösungen auch nicht weiter verwundert.

192

4.3 Makro-Ebene Gestaltungsvarianten

Einzelne BI-Organisationseinheiten lassen sich anhand der wesentlichen Aufgaben im Lebenszyklus von BI-Systemen klassifizieren.29 Als Gestaltungsvarianten können dabei folgende Centertypen unterschieden werden: • Assistenz-Center übernehmen primär eine moderierende Funktion an der Schnittstelle zwischen IT-Bereich und Fachabteilungen. Aufgaben der Makro-Ebene können bei ihnen angesiedelt sein. • Volldienstleister verantworten im Gegensatz zu AssistenzCentern einen durchgehend sehr hohen Anteil der BIUnterstützungsleistungen. Sie fungieren als zentrale Erbringer von BI-Leistungen in einem Unternehmen. Dies betrifft sämtliche Aufgabenbereiche im BI-Kontext. Sie sind daher prädestiniert, Aufgaben der Makro-Ebene zu übernehmen, müssen allerdings über ein breites Know-how-Spektrum verfügen. • Ein Betriebs-Center zeichnet sich durch einen hohen Anteil am fachlichen BI-Betrieb und am BI-Support aus. • Hosting-Center besitzen von allen Gruppen den höchsten Anteil am Betrieb der technischen BI-Infrastrukturen. • In Entwicklungs-Centern steht die Gestaltung von BISystemen im Mittelpunkt. Die Aufgaben der Lebenszyklusphase des BI-Betriebs sind hier gar nicht oder nur in geringfügigem Umfang vertreten.

Besetzung & Rollenkonzepte

Die personelle Besetzung muss sich an der Ausgestaltung und der Zielsetzung der BI-Einheit orientieren und eine passende Kombination von Mitarbeitern verschiedener betriebswirtschaftlicher und IT-orientierter Fachrichtungen berücksichtigen. Anhaltspunkte für die benötigten Fähigkeiten und Profile bieten Rollenkonzepte, die auf einer generischen Ebene die BIspezifischen Anforderungen an die Akteure beschreiben (Miller et al. 2006, S. 63 ff.; TDWI 2009; Gansor et al. 2010, S. 132 ff.).

Kooperationen zwischen IT- und Fachbereichen In der Aufgabenregelung bei der Entwicklung und dem Betrieb von BI-Lösungen wäre es vermessen anzunehmen, dass es lediglich eine einzige, eindeutig definierbare Kooperationsvariante zwischen IT-Verantwortlichen und Vertretern der Fachseite gäbe.

29

Eine detaillierte Beschreibung der Entwicklungs- und Betriebsaufgaben folgt in Kapitel 4.4.

193

4 Entwicklung und Betrieb integrierter BI-Lösungen Bandbreite von Kooperationsvarianten

Vielmehr existiert in aller Regel eine Bandbreite von Kooperationslösungen, die den einzelnen Benutzergruppen entsprechende Handlungsspielräume gewähren. So ist es denkbar, dass Endbenutzer aus Vertriebsbereichen ausschließlich BI-Lösungen einsetzen, die vollständig durch die IT-Abteilung umgesetzt und betrieben werden. Technikaffine Organisationseinheiten – wie mathematische Abteilungen (z. B. Risiko-Management) – präferieren meist Lösungen, bei denen nahezu sämtliche Entwicklungs- und Betriebsarbeiten im Fachbereich selbst durchgeführt werden. Sie erwarten von den IT-Bereichen daher meist lediglich die Extraktion der Daten aus den operativen Quellen. Die Abb. 4.14 zeigt die Spannbreite der Kooperationsmöglichkeiten. BIKonsument Informationszugriff

Selektive BI-Kooperation

BIProfessional

Fachbereich

Informationsgenerierung Datenbereitstellung Datenextraktion

IT-Bereich z.B. Vertrieb

z.B. Supply Chain Management

z.B. RisikoManagement

Abb. 4.14: Alternative Kooperationsvarianten Fachbereich und IT (Kemper/Baars 2009a, S. 81) Veränderungen im Zeitverlauf

Es gilt in diesem Kontext weiterhin zu beachten, dass die Form der Kooperationsbeziehungen im Zeitverlauf – also während des Lebenszyklus der BI-Lösung – Veränderungen erfahren kann. Beispielsweise wäre es denkbar, dass eine Controlling-Einheit, die bislang lediglich den Informationszugriff in eigener Regie betrieben hat, in Zukunft Modifikationen im Bereich der Informationsgenerierung vornehmen möchte. In diesem Falle müssten die Kooperationsbeziehungen zwischen IT- und Controllingabteilung neu definiert werden, um Verantwortungsbereiche der beteiligten Organisationseinheiten dokumentieren zu können.

Beispiel zur organisatorischen Implementierung der Makro-Ebene Entwicklung und Betrieb integrierter BI-Ansätze sind zeitstabile Aufgaben, die eine adäquate organisatorisch verankerte Unterstützung erfordern. In diesem Rahmen sind die unternehmens194

4.3 Makro-Ebene

BI Gov. Com.

Touristik

Reise AG

Konzernleitung

BICC Vorsitz

Pharma

Finanzen

FinanzService

Logistik

Pharma AG

Personal

Logistik AG

Money AG

Baustoffe

IT-Service

Steine AG

Systems AG

Transfer GmbH

Planer GmbH

Stone Ltd.

Softskill GmbH

Traveller Ltd.

Freie Fahrt Ltd.

Sand GmbH

Consulting GmbH

Geschäftseinheiten

Tochterunternehmen

Geschäftsfelder

Gesamtunternehmen

spezifischen Verantwortlichkeiten, die Entscheidungsbefugnisse und die Arbeitsteilung aller notwendigen Tätigkeiten festzuhalten. Die Abb. 4.15 zeigt zur Illustration ein Beispiel der aufbauorganisatorischen Einbindung von Business Intelligence in einem Mischkonzern.

GE

GE

GE

Legende BI Governance Committee BI Competence Center (BICC)

Abb. 4.15: Beispiel organisatorische Einbindung von BI

BI GovernanceCommittee

Auf Ebene der Konzernleitung findet sich das konzernweite BI Governance Committee. Hier werden strategische BI-Konzernprojekte initiiert und diskutiert, wie z. B. Ansätze zur Vereinheitlichung der Konzernkonsolidierung in den Geschäftsfeldern. Weiterhin können strategische Technologie- oder Projektentscheidungen mit Auswirkungen auf mehrere Geschäftsfelder in dieses Gremium getragen werden.

Zentrales BICC

Das BI Governance Committee sorgt für Strategiekonformität der Aktivitäten des zentralen BICC aus Sicht der Gesamtunternehmung und legitimiert dessen Entscheidungen.

Dezentrale BI Governance Committees

Auf der Geschäftsfeld-Ebene entscheiden dezentrale BI Governance Committees über den geschäftsfeldspezifischen Informationsbedarf und die daraus resultierenden, notwendigen BILösungen.

195

4 Entwicklung und Betrieb integrierter BI-Lösungen

Spartenspezifische BICCs

Sie koordinieren somit die spartenspezifischen BICCs, die Rahmenstrukturen und Lösungen für das gesamte Geschäftsfeld entwickeln und betreiben. So kann z. B. ein gemeinsames LogistikDWH mit allen entscheidungsrelevanten Daten zu den Güterströmen den Tochterunternehmen zur Verfügung gestellt werden.

Lokale BICCs

Vor allem bei großen Tochterunternehmen finden sich vereinzelt weitere BI-Unterstützungseinheiten, die das lokale Geschäft und die operativen Geschäftseinheiten durch die Bereitstellung von endbenutzertauglichen BI-Lösungen unterstützen. Technikaffine Einheiten, wie in diesem Beispiel die „Money AG“, übernehmen häufig selbst einen hohen Anteil der Entwicklungsund Betriebsarbeiten in den Fachbereichen und benötigen daher meist keine zusätzliche BICC-Unterstützung in der eigenen Organisationseinheit.

4.4

Mikro-Ebene Die Mikro-Ebene beinhaltet in ihrer Rolle als Umsetzungsschicht die Entwicklungs-, Betriebs- und Reengineering-Aktivitäten der in der Makro-Ebene abgegrenzten BI-Teilsysteme. Sie konkretisiert somit die in der Makro-Ebene vorgegebenen Strukturen und hat sich an den verbindlichen Rahmenbedingungen dieser Ebene auszurichten, wobei selbstverständlich aufgrund von Erfahrungen auch Revisionsaktivitäten für die Makro-Ebene angestoßen werden können.

Makro-Ebene

196

Wie die Abb. 4.16 verdeutlicht, stehen die Vorgaben der MakroEbene im Zentrum der Entwicklungs- und ReengineeringAktivitäten und dienen zum einen der Durchführung von Qualitätssicherungsmaßnahmen. Zum anderen determinieren sie über die Portfoliobildung – wie der breite Pfeil in der Abbildung andeutet – das jeweils zu realisierende BI-System.

Support

Fachlicher Betrieb

Technischer Betrieb

Betriebs-Modell

Priorisierte BI-Anwendung

DatenModell

BenutzerFeedback

EntwicklungsModell

Q

BI-Anwendung

Aufbau, Erprobung und Konsolidierung des Prototypen

Q

Rahmenkonzept der MakroEbene BenutzerFeedback

Systemübergabe

Q

Qualitätssicherung

Informationssystem-Design

BenutzerFeedback

Controlling-Pkt.

C

BenutzerFeedback

Anpassungszyklen

Controlling-Phasen

Systemeinsatz

C

BenutzerFeedback

Qualitätssicherung

Q

Komm.-/Koop.system-Design

BenutzerFeedback

C

BenutzerFeedback

Systemablösung

BenutzerFeedback

Qualitätssicherung

Qualitätssicherung

C

BenutzerFeedback

BenutzerFeedback

Systemeinsatz

BI-Anwendung

BenutzerFeedback

ReengineeringModell

4.4 Mikro-Ebene

Abb. 4.16: Entwicklungs-, Betriebs- und Reengineering-Modell (modifiziert übernommen aus Kemper 1999, S. 322)

197

4 Entwicklung und Betrieb integrierter BI-Lösungen Entwicklung

Das gesamte Vorgehen im Entwicklungs-Modell ist datenakzentuiert und iterativ ausgerichtet. So wird zu Beginn das relevante Projekt-Datenmodell abgegrenzt und dokumentiert. Diese Aktivitäten werden – ebenso wie die nachfolgenden Entwicklungsschritte – in enger Kooperation mit den späteren Endbenutzern in mehreren Zyklen durchlaufen und an den Vorgaben der Makro-Ebene orientiert (in der Abbildung durch Rekursionen repräsentiert). Die Entwicklung des Informationssystem-Designs sowie des Kommunikations- und Kooperations-System-Designs erfolgt im Anschluss an die Projekt-Datenmodellierung in äquivalenter Weise. Nach Abschluss sämtlicher Modellierungsphasen wird der Prototyp aufgebaut, erprobt und konsolidiert. Hier sind ebenfalls wieder Rücksprünge in bereits durchlaufene Phasen – sowohl zu direkten Vorgängern als auch zu weiter zurückliegenden – möglich.

Betrieb

Der abschließende Prototyp wird als BI-Anwendungssystem in den operativen Einsatz übergeben, wenn er nach mehreren Zyklen als ausgereift, stabil und bedarfsangemessen bewertet wird. In dieser Phase des Systembetriebs erfolgt eine kontinuierliche fachliche und technische Betreuung des Anwendungssystems und der Endbenutzer. Im Zeitverlauf werden engmaschig Controllingpunkte gesetzt, so dass bei geringfügigen Abweichungen Anpassungsaktivitäten durchgeführt werden können.

Reengineering

Im Falle gravierender Differenzen zwischen der Soll- und IstKonzeption ist dagegen ein Teil des Entwicklungskreislaufes erneut im Rahmen eines Reengineering-Prozesses zu durchlaufen. Im Folgenden werden die Aktivitäten der Mikro-Ebene in den Bereichen Entwicklungs-Modell, Betriebs-Modell, ReengineeringModell sowie Organisatorische Implementierung weiter detailliert.

4.4.1

Entwicklungs-Modell Im Entwicklungsprozess sind sämtliche Aktivitätenbündel zusammengefasst, die zur Erstellung und zur operativen Inbetriebnahme eines BI-Anwendungssystems auf den Ebenen der dispo-

198

4.4 Mikro-Ebene sitiven Datenbereitstellung, der Informationsgenerierung und des Informationszugriffs erforderlich sind.30 Folgende Phasen des Entwicklungs-Modells können unterschieden werden: • Aufbau des Projekt-Datenmodells. • Bestimmung des Informations-System-Designs. • Bestimmung des Kommunikations- und Kooperations-SystemDesigns. • Aufbau, Erprobung und Konsolidierung des Prototypens.

Projekt-Datenmodell Im Rahmen der projektspezifischen Datenmodellierung sind anwendungsorientierte Fakten, Granularitäten und Dimensionshierarchien des zu entwickelnden BI-Anwendungssystems in enger Zusammenarbeit mit den späteren Endbenutzern festzulegen.31 Fakten

Die Fakten stellen die relevanten Kennzahlen der zu entwickelnden Anwendung dar und bestehen aus internen und/oder externen Daten und hieraus berechneten Werten. Die Ermittlung und Abgrenzung dieser Fakten ist in direkter Abstimmung mit der dispositiven Datenarchitektur durchzuführen, um eine Harmonisierung und Architekturverträglichkeit sicherzustellen.

Granularität & Auswertungsdimensionen

In einem weiteren Schritt ist die applikationsspezifische Granularität vorzugeben. Sie definiert den tiefsten Detaillierungsgrad der Fakten und legt auf diese Weise die Auswertungsdimensionen des zu entwickelnden Informationssystems fest, wobei die Dimensionen mit denen der dispositiven Datenarchitektur abgeglichen werden müssen. Die Dimensionen der dispositiven Datenarchitektur sind auf die Granularitätsebene aller geplanten BIAnwendungssysteme ausgerichtet. Daher ist es durchaus möglich, dass die Applikationsgranularitäten sich nicht auf dem Di-

30

Zweifellos stellen die harmonisierte Bereitstellung dispositiver Daten und die Anbindung der Analysesysteme für die Praxis zur Zeit die größten Herausforderungen dar. Die Integration von Business Intelligence und Wissensmanagement ist zwar als innovatives Forschungsgebiet relevant, in der Praxis jedoch erst in Ansätzen erkennbar. Bei der Darstellung des Vorgehensmodells wird dieser Themenkomplex daher lediglich skizziert.

31

Zur Vertiefung des Themenkomplexes vgl. Kap. 2.3.1.

199

4 Entwicklung und Betrieb integrierter BI-Lösungen mensionsniveau der dispositiven Datenarchitektur befinden, sondern bereits Verdichtungen darstellen.32 Das Projekt-Datenmodell konkretisiert einen Ausschnitt der in der Makro-Ebene definierten dispositiven Datenarchitektur, determiniert im weiteren Verlauf Transformationsprozesse und physische Strukturen in der dispositiven Datenhaltungskomponente des Unternehmens (vgl. Abb. 4.11). Schwachstellen in der Aufbau- und Integrationsphase des Datenmodells – beispielsweise ein unzureichender Abgleich mit den Vorgaben des Rahmenkonzeptes – ziehen daher gravierende Folgen für den gesamten BI-Entwicklungsprozess nach sich und sind nachträglich lediglich mit erheblichem Aufwand zu bereinigen.

Informationssystem-Design Das Informationssystem-Design baut auf dem Projekt-Datenmodell auf. Es dient der Definition und Dokumentation der aus Benutzersicht notwendigen Anforderungen an das BI-Anwendungssystem. Folgende Sachverhalte sind zu bestimmen: • Funktionalitäten für die applikationsspezifische Transformation der dispositiven Daten in Informationen (sofern nicht bereits im Datenmodell als betriebswirtschaftliche Anreicherungen definiert).33 • Auswertungsflexibilität des Informationssystems. • Darstellungsformen für das BI-Anwendungssystem. • Datenberechtigungen für Benutzerrollen.

Kommunikations-/Kooperationssystem-Design Diese Phase des Entwicklungsprozesses dient der Analyse und Dokumentation der erforderlichen Kommunikations- und Kooperationsaktivitäten zwischen Benutzern und Benutzergruppen. Auf Basis dieser Erkenntnisse sind Funktionalitäten synchroner und asynchroner Kommunikations- und Kooperationskomponenten

200

32

Beispielsweise kann die Dimension „Kunde“ der dispositiven Datenarchitektur für die Applikationsgranularität zu „Kundengruppe“ verdichtet sein.

33

Dazu zählt z. B. die Festlegung konkreter Ausprägungsformen des Ausnahme-Berichtswesens, von Kennzahlen und Indikatoren der Datenanalyse oder von statistischen Verfahren zur Unterstützung der Dateninterpretation.

4.4 Mikro-Ebene festzulegen (z. B. kontextsensitive E-Mail-Funktionen, Optionen zur Annotation von Berichten durch Benutzer oder Audio-VideoConferencing).

Prototypengestützte Entwicklung Nach Abschluss der Definition des Projekt-Datenmodells sowie des Designs des Informations- und Kommunikations/Kooperations-Systems, kann die Erstellung, Erprobung und Konsolidierung des Prototypen des zu entwickelnden BI-Teilsystems beginnen. Prototypische Umsetzung des ProjektDatenmodells

Hierbei kommt der prototypischen Umsetzung des Projektdatenmodells eine Schlüsselrolle zu, da sie die Komponente mit den größten Interdependenzen zu allen anderen Entwicklungsprozessen darstellt. Wie die Abb. 4.17 verdeutlicht, ist der Aufwand für diese Aktivitäten erheblich von dem unternehmensspezifischen Entwicklungsstand des integrierten BI-Ansatzes abhängig.

Altruistischer Anteil der ersten BI-Anwendung

So sind im Falle des Pilotprojektes, bei dem noch keine Konkretisierung durch Vorprojekte erfolgt ist, die umfassendsten Aktivitäten durchzuführen. Bei Nachfolgeprojekten können sich diese Aktivitäten erheblich reduzieren, da die dispositive Datenhaltung in diesen Fällen bereits durch die Entwicklungsprozesse vorgelagerter BI-Anwendungssysteme teilweise oder gänzlich angelegt und somit für das zu entwickelnde BI-Anwendungssystem nutzbar ist.

Altruistischer Anteil der ersten BI-Anwendung

Aufwand

BI-Entwicklung Traditionelle Entwicklung ..........

Aufwandsreduktion aufgrund bereits geleisteter Vorarbeiten

BI-Anwdg. Projekt 1

BI-Anwdg. Projekt 2

BI-Anwdg. Projekt 3

..........

BI-Anwdg. Projekt n

Anzahl der BI-Anwendungen

Abb. 4.17: Aufwandsdegression bei zunehmendem Reifegrad des BI-Ansatzes (modifiziert übernommen aus Kemper 1999, S. 327)

201

4 Entwicklung und Betrieb integrierter BI-Lösungen Existieren jedoch keine verwendbaren Vorleistungen, sind umfangreichere Arbeiten zur Übernahme der Daten in die dispositive Datenhaltung durchzuführen: • Identifikation der geeigneten unternehmensinternen -externen Datenquellen.

und

• Implementierung von ETL-Prozessen und deren metadatengestützter Dokumentation (vgl. Kapitel 2.3.1). Engerer Prozess des Prototypings und Systemübergabe

Der engere Prozess des Prototypings beinhaltet den iterativen Entwicklungs-, Erprobungs- und Konsolidierungsprozess des BIAnwendungssystems, der in mehreren Zyklen durchlaufen wird. Es werden erste Versionen des Teilsystems im Rahmen des explorativen Prototypings entwickelt und in sog. FeedbackRunden den Endbenutzern vorgestellt und mit ihnen diskutiert. Wird nach mehreren Entwicklungszyklen der Prototyp von den späteren Systembenutzern als bedarfsangemessen und mängelfrei beurteilt, erfolgt in einem abschließenden Entwicklungsschritt die Vorbereitung der letzten Prototyp-Version für den operativen Systembetrieb. In diesem Abschnitt des Entwicklungsprozesses werden die erforderlichen benutzerrollenspezifischen Berechtigungsstrukturen integriert und das BI-Anwendungssystem zu einem definierten Zeitpunkt in den operativen Betrieb übergeben.

4.4.2

Betriebs-Modell Die Betriebsprozesse gewährleisten die kontinuierliche Verfügbarkeit und Nutzbarkeit eines BI-Anwendungssystems und die Unterstützung der Endbenutzergruppen während der Einsatzphase. Folgende Bestandteile des Betriebs-Modells können unterschieden werden: • Technischer Betrieb. • Fachlicher Betrieb. • Support. • Controlling-Phasen.

Technischer Betrieb Der technische BI-Betrieb umfasst das Management der technischen Infrastrukturen wie z. B. Netzwerke, Server, Betriebssysteme, Datenbanken oder die Basisadministration der BI-Werkzeuge. 202

4.4 Mikro-Ebene Einordnung in BI-ServiceKonzept

Innerhalb des BI-Service-Konzepts fokussieren diese Tätigkeiten bei der Geschäftsnähe die Ebenen der Hardware und der Werkzeuge und decken bei den Komponenten alle Ebenen der Datenbereitstellung sowie der Informationsgenerierung, -distribution und des -zugriffs ab (vgl. Kap. 4.3.4).

Exemplarische Tätigkeiten

Auf Ebene der Datenbereitstellung umfasst das Aufgabenbündel z. B. als Teil der Filterung die automatische Bereinigung syntaktischer/sematischer Defekte (Mängel der 1. Klasse, vgl. Kapitel 2.3.1). In dieser ersten Transformationsschicht fallen technische Metadaten an, deren Pflege sinnvollerweise ebenfalls in der Verantwortung des technischen Betriebs liegt (vgl. Kap. 2.3.1 und 2.3.4).

Verknüpfung Makro-Ebene

Der technische Betrieb verantwortet darüber hinaus die operative Umsetzung der geplanten technischen Infrastrukturen aus der Makro-Ebene und gewährleistet somit die laufende Skalierbarkeit von Hardware und Werkzeugen (vgl. Kap. 4.3.3). Besondere Relevanz hat die Einhaltung der in Kap. 4.3.6 beschriebenen Rahmenbedingungen zur Vereinheitlichung der technischen Infrastrukturen. Aufgrund der niedrigen Geschäftsspezifität wird der technische Betrieb oftmals teilweise oder vollständig an einen internen oder externen Dienstleister vergeben. Dabei sind die Vorgaben und Empfehlungen der BI Service und Sourcing Policies zu berücksichtigen (vgl. Kap. 4.3.4).

Fachlicher Betrieb Im Rahmen des fachlichen BI-Betriebs erfolgt das BI-Applikationsmanagement. Es werden BI-spezifische IT-Leistungen erbracht wie bspw. die Administration eines Data Warehouse, die Berichtsproduktion oder die übergreifende Berechtigungsverwaltung. Einordnung in BI-ServiceKonzept

Komplementär zum technischen Betrieb sind die Tätigkeiten des fachlichen Betriebs in der Geschäftsnähe des BI-Service-Konzepts auf Ebene der Templates und des Contents einzuordnen, während bei den BI-Komponenten ebenfalls die vollständige Bandbreite unterstützt wird (vgl. Kap. 4.3.4).

Exemplarische Tätigkeiten

Durch die hohe Geschäftsspezifität bedarf es für die Tätigkeiten einer großen Vertrautheit mit der kontextspezifischen Semantik des Anwendungsbereichs. Diese kommt z. B. bei der Harmoni-

203

4 Entwicklung und Betrieb integrierter BI-Lösungen sierung, Aggregation und Anreicherung der Daten im Rahmen der Transformation sowie der Pflege von betriebswirtschaftlichen Metadaten zum Tragen (vgl. Kap. 2.3.1 und 2.3.4). Verknüpfung Makro-Ebene

BI-Konzepte mit integrierter Datenhaltung ermöglichen eine zentrale Berechtigungsverwaltung unter Berücksichtigung der durch die Makro-Ebene definierten Sicherheits- und Zugriffskonzepte. Bei organisatorischen Veränderungen im Zeitverlauf liegt es im Aufgabenbereich des fachlichen Betriebs, die rollenbasierten Zugriffsstrukturen nach Vorgabe der Makro-Ebene umzusetzen.

Support Der BI Support unterstützt den direkten Kontakt zu den Endbenutzern, indem er bspw. Problemlösungen im Umgang mit BIAnwendungen anbietet, Anfragen bearbeitet oder den Wissenstransfer koordiniert. Damit dient er als zentrale Annahmestelle für Anfragen zu der Nutzung und zu den Daten der BIAnwendungssysteme und ist in dieser Funktion dem fachlichen und technischen Betrieb vorgeschaltet. SupportHierarchie

Die Unterstützungsleistung der Support-Funktion kann differenziert werden anhand der benötigten Kompetenzen zur Problemlösung. Soweit möglich werden neue Unterstützungsanfragen von Endbenutzern direkt in erster Instanz bearbeitet und – ggf. unter Zuhilfenahme von Wissensdatenbanken – kurzfristig gelöst (First Level Support). Ist die Problemstellung unbekannt bzw. komplex, weil z. B. mehrere BI Services und BI-Werkzeuge tangiert sind oder das Nachvollziehen umfangreicher Transformationen notwendig ist, wird die Anfrage an Spezialisten aus dem technischen und fachlichen Betrieb weitergegeben (Second Level Support). Kann die Anfrage innerhalb der Betriebs-Ebene nicht zufriedenstellend beantwortet werden, können in letzter Instanz Ansprechpartner aus den Entwicklungsphasen oder des Werkzeugherstellers hinzugezogen werden (Third-Level-Support).

Controlling-Phasen In die Phase des operativen Betriebs von BI-Anwendungssystemen sind regelmäßige Controlling-Phasen eingebettet. Sie werden genutzt, um das System zum einen mit den sich aus Endbenutzersicht wandelnden Anforderungen und zum anderen mit sich ändernden internen und externen Rahmenbedingungen abzugleichen. Diese Controlling-Phasen dienen weiterhin der Kommunikation von Feedbacks an die Makro-Ebene und können 204

4.4 Mikro-Ebene periodisch oder im Bedarfsfall von Endbenutzern bzw. Endbenutzergruppen initiiert werden. Anpassungszyklen

Bei kleineren Änderungen können mit Hilfe von Anpassungszyklen erforderliche Systemadaptionen über die definierten technischen und fachlichen Administrationsschnittstellen (vgl. Kapitel 2.3.6) durchgeführt werden, größere Veränderungen bedingen jedoch ein professionelles Reengineering.

4.4.3

Reengineering-Modell Das Reengineering-Modell bestimmt die Aktivitäten, die bei Veränderungsbedarf eines BI-Anwendungssystems anfallen. Die Abb. 4.18 zeigt den Reengineering-Zyklus, der sich durch einen strukturidentischen Aufbau im Vergleich zum Entwicklungsmodell auszeichnet (vgl. Abb. 4.16). BenutzerFeedback

ReengineeringZyklus

ReengineeringModell

Informationssystem-Design

BenutzerFeedback DatenModell

Q

Qualitätssicherung

Q

BenutzerFeedback

Rahmenkonzept der MakroEbene BenutzerFeedback

Komm.-/Koop.system-Design

Q

Qualitätssicherung

Q

Aufbau, Erprobung und Konsolidierung des Prototypen

Controlling-Phasen

BetriebsModell

Anpassungszyklen BenutzerFeedback

C

BenutzerFeedback

C

BenutzerFeedback

BI-Anwendung

C

Controlling-Pkt. Systemeinsatz

C

Systemablösung Systemeinsatz

Abb. 4.18: Reengineering-Zyklus (modifiziert übernommen aus Kemper 1999, S. 330) Der Reengineering-Zyklus wird gestartet, wenn während der Einsatzphase eines BI-Anwendungssystems die in den Control205

4 Entwicklung und Betrieb integrierter BI-Lösungen ling-Phasen durchgeführten Adaptionsprozesse nicht mehr genügen, um die Systemadäquanz herzustellen. Es ist einsichtig, dass die Bearbeitungsintensität der einzelnen Phasen des Reengineering-Zyklus hierbei den jeweiligen Erfordernissen angepasst werden kann und nicht in jedem Falle alle Phasen vollständig umgesetzt werden müssen. Um eine Versorgungslücke des Managements zu vermeiden, wird das BI-Altsystem während der Reengineering-Aktivitäten unverändert weiter betrieben. Erst nach dem Abschluss sämtlicher Aktivitäten erfolgen die Ablösung des Altsystems und der Einsatz des modifizierten bzw. erweiterten BI-Anwendungssystems. Auch dessen weiterer Einsatz wird wiederum in den Betrieb übergeben und durch Controlling-Phasen begleitet, die je nach Ergebnis Anpassungszyklen einleiten oder einen erneuten Reengineering-Prozess erforderlich machen. Auf diese Weise ist der Einsatz des BI-Anwendungssystems durch eine iterative Folge von Controlling-Phasen, Anpassungszyklen und Reengineering-Prozessen gekennzeichnet und endet erst mit seiner endgültigen Außerdienststellung.

4.4.4

Organisatorische Gestaltung

Einbindung von Entwicklung & Reengineering

Die Entwicklungs- und Reengineering-Prozesse im BI-Kontext weisen die Charakteristika der Einmaligkeit, Zusammensetzung aus Teilaufgaben, Interdisziplinarität, Konkurrenz um Betriebsmittel, Bestimmung von Dauer und Aufwand sowie der zeitlichen Begrenzung auf. Daher ist für ihre Umsetzung die klassische Projektform geeignet. Sowohl Entwicklungs- als auch Reengineering-Prozesse sind durch stark prototypisch ausgerichtete Elemente gekennzeichnet. Die hierdurch erforderlichen, ständigen Rückkopplungen betonen die hohe Relevanz einer fundierten Auswahl der Projektbeteiligten. Die folgenden Anspruchsgruppen von BI-Anwendungssystemen sind daher angemessen zu berücksichtigen: • Manager oder ihre unmittelbaren Vertreter, auf deren Anforderungen als spätere Systembenutzer die grundlegenden Funktionalitäten, Darstellungsformen und Datensichten ausgerichtet sein müssen. • Fachbereiche, die als Datenlieferanten die semantische Qualität der in die dispositive Datenhaltung einfließenden Daten zu gewährleisten haben.

206

4.5 Zusammenfassung • IT-Bereiche, welche die technische Implementierung sämtlicher Systemkomponenten durchführen. • Vertreter der Makro-Ebene, welche die Koordination der Entwicklungs- und Reengineering-Aktivitäten mit den Vorgaben der Makro-Ebene verantworten. Einbindung des Betriebs

Mit Übergang des BI-Anwendungssystems in die Systemnutzung, verändern sich die Anforderungen an die organisatorische Einbindung aufgrund der teils abweichenden Charakteristika des Betriebs. Diese lassen sich mit Kontinuität, zeitlicher Unbegrenztheit, Zusammensetzung aus Teilaufgaben und Interdisziplinarität umschreiben. Während die Anspruchsgruppen gleich bleiben und auch eine personelle Kontinuität zwischen den Phasen förderlich und wünschenswert ist, verändern sich die grundsätzlichen Rollen und Einbeziehungen in der Betriebsphase: • Manager oder ihre unmittelbaren Vertreter werden als Endbenutzer des BI-Systems im Betrieb zu wichtigen Impulsgeber für Verbesserungen und Änderungsanforderungen. • Fachbereiche übernehmen je nach Kooperationsvereinbarung mit den IT-Bereichen Verantwortung für Teile der Datenbereitstellung sowie der Informationsgenerierung, -distribution und des -zugriffs (vgl. Kap. 4.3.8). • IT-Bereiche verantworten die Datenextraktion und je nach Kooperationsvereinbarung mit den Fachbereichen die Bereitstellung weiterer BI-Komponenten. • Vertreter der Makro-Ebene koordinieren die Betriebs-Aktivitäten mit den Vorgaben der Makro-Ebene.

4.5

Zusammenfassung Die Gestaltung integrierter BI-Ansätze verlangt den Einsatz eines Rahmenkonzepts, das weit über die isolierte Betrachtung der Systementwicklung hinausgeht. Dieses ist insbesondere deshalb erforderlich, da das Ziel der BI-Systementwicklung sich nicht auf die Erstellung eines isolierten Anwendungssystems bezieht, sondern auf den Aufbau einer abgestimmten, am Bedarf der Geschäftsprozesse ausgerichteten BI-Systemlandschaft für den gesamten dispositiven Bereich eines Unternehmens ausgerichtet ist. Das im vorliegenden Kapitel entwickelte Rahmenkonzept gliedert sich aus diesem Grunde in eine Makro- und eine Mikro-Ebene, wobei die Makro-Ebene die grundlegende BI Governance durch Rahmenbedingungen festlegt, während die Mikro-Ebene die mit 207

4 Entwicklung und Betrieb integrierter BI-Lösungen dem Rahmenkonzept abgestimmten Entwicklungs-, Betriebs- und Reengineering-Prozesse der BI-Teilsysteme beinhaltet. Die Makro-Ebene detailliert sich in die beiden Gestaltungsbereiche Strategie und Richtlinien und Leitlinien. Das strategische Aufgabenbündel umfasst dabei die Potenzialplanung, das Portfoliomanagement sowie das Technologie- und Infrastrukturmanagement. Verbindliche Vorgaben und Empfehlungen für die Mikro-Ebene werden durch die BI Service und Sourcing Policies, die dispositive Datenarchitektur und die Entwicklungsund Betriebs-Rahmenbedingungen festgelegt. Da die Erstellung und die kontinuierliche Anpassung dieser Rahmenbedingungen keine zeitlich befristete Aufgabe, sondern einen permanenten Prozess darstellt, sind für die Umsetzung, das Controlling und die Anpassung dieser Ebene dauerhafte Organisationsstrukturen in Form von Governance Commitees, BICCs und Kooperationsvereinbarungen zwischen Fach- und IT-Bereichen zu implementieren. Die einzelnen Entwicklungs- und Reengineering-Prozesse, die im Rahmen der Mikro-Ebene durchgeführt werden, sind hingegen in Form von Projekten umzusetzen, wobei die personelle Zusammensetzung der Projektteams aus Vertretern des Managements, der Daten liefernden Fachbereiche, der IT-Abteilung und der Makro-Ebene erfolgt. Das Vorgehensmodell der Mikro-Ebene ist bewusst prototypisch ausgerichtet und umfasst die iterativen Aktivitätenbündel der projektbezogenen Datenmodellierung, der Erstellung des Informationssystems- und Kommunikations/Kooperations-System-Designs sowie der Entwicklung, Erprobung und Konsolidierung von lauffähigen Prototypen. Diese Prototypen werden nach Abnahme durch die Manager vervollständigt, indem sie um die Aspekte des Echtbetriebs erweitert und als operative BI-Teilsysteme in den Einsatz übergeben werden. Während dieser Einsatzzeit garantiert die intensive Betreuung des technischen und fachlichen Betriebs die kontinuierliche Verfügbarkeit und Nutzbarkeit des BI-Anwendungssystems. Endbenutzer werden beim Systemeinsatz und bei Problemlösungen durch den Support unterstützt. Mit Hilfe engmaschiger ControllingPhasen wird analysiert, inwieweit das Teilsystem im laufenden Betrieb noch den sich wandelnden Anforderungen genügt. Im Falle geringfügiger Abweichungen können sofortige Anpassungszyklen eingeleitet werden, während bei gravierenden Änderungen ein Reengineering-Zyklus angestoßen werden muss, der einen nahezu phasenidentischen Aufbau zum Entwicklungsmodell besitzt. 208

5

Praktische Anwendungen Zur Verdeutlichung der dargestellten Themen werden im Folgenden Fallstudien vorgestellt. Sie sind nicht als „Best-PracticeLösungen“ zu interpretieren, sondern zeigen typische Systemimplementierungen und basieren auf realen Praxissystemen, die aus didaktischen Gründen modifiziert und anonymisiert wurden.

Data-Mart-basierte BI-Anwendung eines Finanzdienstleisters Die BI-Anwendung dient der Optimierung des Vertriebs eines Dienstleistungsunternehmens im Allfinanzbereich. Das System sollte ursprünglich als isolierte Data-Mart-Lösung umgesetzt werden, d. h. direkt mit transformierten operativen Daten versorgt werden. Aufgrund einer strategischen Entscheidung des Vorstands wurden die Pläne jedoch revidiert und die Anwendung als erster Baustein eines umfassenden Data-Warehouse-Ansatzes (Hub-and-Spoke-Architektur) gewertet. Die Systemumgebung besteht daher neben der proprietären Data-Mart-Lösung aus einer relationalen Core-Data-Warehouse-Komponente. Die Einordnung in den Ordnungsrahmen verdeutlicht Abb. 5.1.

Business Intelligence (BI) Informationszugriff

Informationsgenerierung/ -distribution

BI-Portal

Informationsdistribution

Analysesysteme

Data Mart

Datenbereitstellung

Content & Document Mgmt.

Core Data Warehouse Operational Data Store

Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Abb. 5.1:

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

Systemintegration

Data-Mart-basierte BI-Anwendung im Vertriebscontrolling (mit C-DWH)

Metadaten

5.1

Externe Daten

Data-Mart-basierte BI-Anwendung im Vertriebscontrolling

209

5 Praktische Anwendungen

Unternehmen Das Unternehmen ist ein Finanzdienstleister, der ursprünglich ausschließlich auf dem Markt der Baufinanzierung aktiv war, inzwischen jedoch seinen Handlungsspielraum ausgeweitet hat und seinen Kunden bundesweit individuell angepasste Finanzangebote unterbreitet. Die Hauptzielgruppe sind die ca. 1,5 Millionen Stammkunden, bei denen Cross-Selling-Potenziale erschlossen werden sollen. Sie werden von 7.000 Vertriebsmitarbeitern in einer einheitlichen Vertriebsorganisation für die Produktbereiche Bausparen, Baufinanzierung, Lebensversicherung und Bankprodukte betreut. Besonders die Lebensversicherungssparte hat im Rahmen dieser expansiven Marktstrategie einen stetigen Bedeutungszuwachs erfahren.

Motivation und Zielsetzung Das Management der Vertriebsorganisation war Initiator für die Systementwicklung im Vertriebscontrolling. Ihrer Einschätzung nach waren die Vorsysteme bzgl. der Datenqualität, Performance und Auswertungsflexibilität völlig unzureichend und entsprachen nicht den geänderten Geschäftsbedingungen des Unternehmens. Die einsetzende Diskussion um die Neuentwicklung führte im Top Management zu einer lebhaften Diskussion über die generelle Eignung der dispositiven Systeme des Hauses und bewirkte mittelfristig eine DWH-basierte Neukonzeption des Gesamtansatzes. Die Beschreibung reduziert sich aus pragmatischen Gründen im Weiteren jedoch primär auf die Details des ersten Bausteins des Ansatzes, der Optimierung des Vertriebscontrollings.

Lösungskonzept Systemanforderungen

Auf der Basis einer Anforderungsanalyse, die im ersten Schritt mit Hilfe von Interviews mit dem Vertriebsmanagement durchgeführt wurde, erarbeitete die Projektgruppe ein Lösungskonzept, das sowohl ein Basismodul zum Abruf vorgefertigter Standardberichte als auch ein Ad-hoc-Analysesystem vorsah. Insbesondere sollten hierbei die folgenden Anforderungen abgedeckt werden: • Abbildung der Struktur der Vertriebsorganisation über fünf Hierarchieebenen (Vertriebsleitung, Regional-, Landes- und Bezirksdirektionen sowie Bezirksleitungen) mit performanten Drill-down-Funktionalitäten.

210

5.1 Data-Mart-basierte BI-Anwendung eines Finanzdienstleisters • Standard- und Ausnahmeberichtswesen. • Ad-hoc-Analysen für Controlling-Mitarbeiter. • Grafische Auswertungsmethoden wie z. B. Balkendiagramme, Trend-, Portfolio- und ABC-Analysen. • Abbildung der unternehmensspezifischen Terminologie und Berichtsarten. • Integrierte und kontextabhängige Hilfefunktion. Dispositive Datenbasis

Bei der Speicherung der Daten entschied sich die Projektgruppe in Absprache mit dem im IT-Bereich neu implementierten BI Competence Center für eine proprietäre, physikalisch-mehrdimensionale OLAP-Datenhaltung. Zum Zwecke der periodischen (wöchentlichen) Beladung des Data Marts wurden in enger Zusammenarbeit mit der BI-Gruppe anschließend die geeigneten ETL-Programme implementiert und in den Einsatz übergegeben. Mit Hilfe dieser Programme werden seitdem die entsprechenden operativen Daten aus Gründen der Mehrfachverwendbarkeit zunächst als tagesaktuelle Werte in das C-DWH übernommen. In wöchentlichen Abständen werden die tagesaktuellen Daten mit Hilfe weiterer ETL-Programme verdichtet und in der gewünschten Granularität (also wöchentlich) in den proprietären Data Mart des Vertriebscontrollings übermittelt. Zur Bewältigung des Datenvolumens wurde die Historienbildung nach Absprache mit dem Management innerhalb des Data Marts auf drei Jahre festgelegt. Eine Steigerung der Performance wurde nach ersten Beschwerden der Endbenutzer durch Tuningmaßnahmen ermöglicht, wobei vor allem die „VorabBerechnung“ von Kennzahlen und Summen während des Beladevorgangs eine Beschleunigung der Antwortzeiten ermöglichte.

Ad-hoc-Analysen des Controllings

Für typische Ad-hoc-Analysen des Controllings werden als FrontEnd-Systeme die bereits im Unternehmen etablierten Tabellenkalkulationsprogramme eingesetzt, die um spezifische Optionen zur multidimensionalen Datenrecherche erweitert worden sind. So können die Endbenutzer je nach Auswertungszweck entscheiden, welche Dimensionen (Zeiträume, Werteausprägungen (Plan, Ist), Produktgruppen, Produkte und Organisationseinheiten) analysiert und/oder mit anderen Datensichten zu kombinieren sind.

211

5 Praktische Anwendungen Briefing Book

Einmal definierte Informationssichten können in sog. Briefing Books logisch abgespeichert werden. Diese aktiven Berichtsdefinitionen können zu späteren Zeitpunkten mit dem dann jeweils aktuellen Datenbestand aufgerufen werden und mit Hilfe von Drag-and-Drop-Techniken in weiteren Programmen wie Textverarbeitung und Präsentations-Software integriert werden.

Entwicklung und Betrieb Das System wurde auf Basis einer prototypisch orientierten Entwicklungsmethodik mit kurzen Entwicklungszyklen und engmaschigen Feedback-Runden erstellt, um den schnell wechselnden Anforderungen und Informationsbedarfen der Führungskräfte und des Controllings gerecht werden zu können. Ständiger Arbeitskreis

Zu diesem Zweck wurde ein Arbeitskreis gebildet, in dem sich Benutzer unterschiedlicher Ebenen – z. B. Regional- und Landesdirektoren sowie Controller – mit den Entwicklern austauschen können. Ein neuer Entwicklungszyklus, der in aller Regel aus dem Arbeitskreis initiiert wird, umfasst die folgenden Schritte: • Anregung aus dem Arbeitskreis. • Vorstudie durch das Entwicklungsteam. • Präsentation und Diskussion der Ergebnisse der Vorstudie. • Prototypenentwicklung. • Präsentation des Prototyps. • Testbetrieb der neuen Funktionalität unter realen Bedingungen. • Konsolidierung und Feinanpassung. • Betrieb mit laufender Akzeptanzüberprüfung. Im Rahmen der Vorstudie und der Prototypenentwicklung werden neu entwickelte Funktionalitäten mit den Benutzern diskutiert und sukzessive an deren Anforderungen angeglichen. Die Prototypen sind dabei als real lauffähige Teilsysteme anzusehen, deren Nutzen im täglichen Einsatz schnell überprüft werden kann, wodurch Fehlentwicklungen vermieden werden.

Abschließende Bemerkungen Teilautomatisierung der Analyseaufgaben 212

Die Entwicklung des Systems wird innerhalb des Vertriebsbereiches als Erfolg gewertet. Die Mitarbeiter bestätigen, dass sie seit dem Einsatz des Systems erheblich von operativen Datensamm-

5.2 ODS-erweiterter BI-Ansatz eines Telekommunikationsanbieters lungsaktivitäten entlastet sind und größere Freiräume besitzen, qualitative Aufgaben – wie etwa die Erstellung von differenzierten Analysen – durchführen zu können. Auch von Seiten des Top Management wird die Entscheidung als richtig gewertet, mit der Entwicklung des Systems einen ersten Baustein für eine DWH-basierte Systemlandschaft geschaffen zu haben. Da im Bereich der Datenqualität und der organisatorischen Migration in prozessorientierte Strukturen erhebliche unerwartete Probleme aufgetreten sind, konnten nicht sämtliche Pläne zur Neugestaltung der dispositiven Systemlandschaft sofort umgesetzt werden. Im Bereich des Marketings wurden jedoch kurz nach Einführung der neuen Vertriebslösung bereits weitere Systeme entwickelt, die sich zum großen Teil der bestehenden dispositiven Daten des C-DWH bedienen und erfolgreich für Kundenwertanalysen und die Planung von Marketingkampagnen eingesetzt werden konnten.

ODS-erweiterter BI-Ansatz eines Telekommunikationsanbieters Das vorgestellte System ist eine umfassende, unternehmensweite ODS-erweiterte Business-Intelligence-Lösung eines Telekommunikationsanbieters. Das System beinhaltet einen Operational Data Store, ein Core Data Warehouse, mehrere funktionsorientierte Data Marts sowie darauf aufbauende Analysesysteme und BIPortal-Komponenten (vgl. Abb. 5.2).

Business Intelligence (BI) Informationszugriff

Informationsgenerierung/ -distribution

BI-Portal

Informationsdistribution

Analysesysteme

Data Mart

Datenbereitstellung

Content & Document Mgmt.

Core Data Warehouse Operational Data Store

Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Abb. 5.2:

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

ODS-erweitertes, unternehmensweites eines Telekommunikationsanbieters

Systemintegration

• DWH-basiertes und ODSerweitertes BI-Anwendungs-system eines Telekommunikationsanbieters • Datenhaltung auf Transaktionsebene • Funktionsorientierte Data Marts • Analysesysteme • Portal-Zugriff

Metadaten

5.2

Externe Daten

BI-System

213

5 Praktische Anwendungen

Unternehmen Das Telekommunikationsunternehmen ist ein Anbieter für Sprach- und Datendienstleistungen. Es besitzt ein eigenes flächendeckendes Netzwerk und betreut damit mehrere Millionen Kunden. Der Wettbewerb auf dem Telekommunikationsmarkt hat sich seit der Liberalisierung stark verschärft. Wesentliche Kennzeichen hierfür sind eine rückläufige Rentabilität, eine geringere Kundenloyalität sowie eine hohe Preissensitivität bei gleichzeitig hoher Markttransparenz. Es hat eine Wandlung zum Käufermarkt stattgefunden. Dies ist mit hohen Kosten der Kundengewinnung, einer hohen Kundenfluktuation sowie einem intensiven Wettbewerb in den Bereichen Produktentwicklung und Dienstleistungen verbunden

Motivation und Zielsetzung Ausgehend von den genannten Herausforderungen verfolgt das Unternehmen die Ziele einer offensiven Marktbearbeitung sowohl zur Gewinnung weiterer Marktanteile als auch zur Nutzung von Cross-Selling-Potenzialen. Eine schnelle Marktreife für neue Produkte und Dienstleistungen sowie eine hohe Kundenbindung werden als ebenso essenziell angesehen wie eine hohe Kundenprofitabilität. Zur Umsetzung dieser Ziele wurden BI-Applikationen entwickelt, die folgende Anwendungen unterstützen: • Berichtswesen zum Umsatz- und Kosten-Monitoring. • Produktentwicklung und Preisgestaltung. • Steuerung von Werbemaßnahmen (Kampagnen-Management, Cross-Selling-Maßnahmen, Churn-Management usw.). • Minimierung der Forderungsausfälle. • Netzplanung und -ausbau. • Controlling des Intercarrier-Managements (Rechnungsabwicklung mit anderen Netzbetreibern).

214

5.2 ODS-erweiterter BI-Ansatz eines Telekommunikationsanbieters

Lösungskonzept Call Detail Record (CDR)

Teilnehmer A (Anrufer)

•A-Nummer •B-Nummer •Start-Datum •Start-Uhrzeit •Sekunden •Vermittlungsstelle •Trunk-In •Trunk-Out

Leitungsanschluss (Trunk) Netzwerk

•Anschluss •Kunde •Tarif •Produkt •Zeitzone •Entfernungszone •Einheiten •Preis

Teilnehmer B (Anrufempfänger)

Call Detail Records (bewertet) Netzschnittstelle

Call Detail Records (unbewertet/roh)

Abb. 5.3: Call Detail Records

Abrechnung (Billing)

Unbewertete und bewertete Call Detail Records

Im Rahmen des Betriebs von Telekommunikationseinrichtungen fällt ein enormes Volumen sehr detaillierter Verbindungsdaten an. Beispielsweise wird für jede Sprachverbindung im Netzwerk ein sog. Call Detail Record (CDR) generiert. Ein roher bzw. unbewerteter Call Detail Record enthält neben den Daten zum Anrufer (A-Nummer) und zum Anrufempfänger (B-Nummer) auch Informationen zum Beginn und zur Dauer des Gesprächs sowie zu den beteiligten technischen Netzwerk-Komponenten. Ein bewerteter Call Detail Record ist dagegen aus anderen Datenquellsystemen um weitere Informationen angereichert worden (vgl. Abb. 5.3). Im Netz des hier dargestellten TelekomUnternehmens fallen pro Tag mehr als 200 Millionen Call Detail Records an, die jeweils über einen Zeitraum von 6 Monaten gespeichert werden. Um diese große Datenmenge bewältigen und für dispositive Zwecke nutzen zu können, hat sich das Unternehmen für die Implementierung eines umfassenden, unternehmensweiten Business-Intelligence-Ansatzes entschieden (vgl. Abb. 5.2).

Operational Data Store und Core Data Warehouse

Die Daten der unterschiedlichen Quellsysteme werden zu Dimensionen zusammengefasst und in einem hohen Detaillierungsgrad im Operational Data Store vorgehalten (vgl. Abb. 5.4).

215

5 Praktische Anwendungen

Quellsysteme

•

Netzwerk

•

Abrechnung

•

Customer-Care-/ Call-Center

•

Auftragsmanagement

Detaillierte Daten des Operational Data Store

Verbindungsdaten (Call Detail Records)

Kundendaten Vertragsdaten Auftragsdaten

•

Computer Aided Selling

•

Provisionierung

•

Kampagnenmanagement

Abb. 5.4:

Vertriebsdaten

Detaillierte Datenhaltung des Operational Data Store

Operational Data Store und Core Data Warehouse sind logisch getrennt in relationalen, nahezu voll normalisierten Datenhaltungssystemen implementiert. Die ODS-Daten werden weitgehend untransformiert übernommen, da sie bereits in den operativen Quellsystemen in großen Teilen vereinheitlicht sind. Der ODS ist dem C-DWH vorgeschaltet und dient diesem als Datenquelle. Bei der Übernahme in das C-DWH durchlaufen die Daten einen vollständigen Transformationsprozess. Im C-DWH findet auch eine Historisierung nach fachlichen Gesichtspunkten statt. Hierzu wird eine Delta-Historisierung mit einer Current-FlagVariante eingesetzt (vgl. Kapitel 2.4.4). Die dispositive Datenhaltung des Unternehmens kann aufgrund des großen Umfangs seiner Nutzdaten in einer Größenordnung von ungefähr hundert Terabyte in die Kategorie der sog. großen Data Warehouses („Large Data Warehouses“) eingeordnet werden. Hierbei ergeben sich besondere Anforderungen an die System-Infrastruktur: • Recovery-Konzepte in den Beladungsprozessen Um die großen Datenmengen in den ODS und anschließend über Transformationsprozesse in das C-DWH zu laden, sind Batch-Prozesse im Nachtfenster nicht länger ausreichend. Vielmehr ist eine ganztägige Beladung erforderlich, so dass eine Qualitätssicherung der zu übernehmenden Daten nur in Ansät216

5.2 ODS-erweiterter BI-Ansatz eines Telekommunikationsanbieters zen möglich ist. Mängel in den zu übernehmenden Daten – wie z. B. doppelte Zählung von Verbindungsdaten oder verspätete Pflege von Tarifierungsmodellen – können daher häufig nicht im Vorfeld erkannt und bereinigt werden. Aus diesem Grunde war es im vorliegenden Fall erforderlich, stabile Verfahren zu integrieren, die eine sichere Rücknahme der entsprechenden Beladungsvorgänge sowie der darauf basierenden Aggregationen ermöglichen. • Partitionierte Datenhaltung Eine weitere Möglichkeit, mit großen Datenvolumina sicher umzugehen, ist die Aufteilung von Tabellen in mehrere kleine physikalische Tabellen. Mit Hilfe dieser Technik, die nicht selten als Partitionierung bezeichnet wird, wurde im Unternehmen die Fakttabelle in mehrere überschneidungsfreie kleinere Tabellen bzw. Partitionen unterteilt. Hierbei erfolgte die Partitionierung auf der Basis geschäftlich relevanter Zeiträume (Anahory/Murray 1997, S. 63 f. und S. 111 ff.). Dieses ermöglichte sehr gute Antwortzeiten, Zeitersparnisse bei Beladungsvorgängen sowie größere Flexibilität bei Backup- und Recovery-Vorgängen. • Aggregationen Um das Datenvolumen im Vergleich zur detailliertesten Granularitätsebene zu verringern, setzt das Unternehmen zusätzlich zu den Detaildaten Low-Level- und High-Level-Aggregate ein (vgl. Abb. 5.5). Die Low-Level-Aggregate stellen dabei eine erste Verdichtung der Detaildaten dar, weisen jedoch ansonsten noch einen hohen Detaillierungsgrad auf. Sie bilden die Grundlage der High-Level-Aggregate, die in Abhängigkeit von den fachlichen Anforderungen definiert werden. Data Marts & Analysesysteme

Das Unternehmen betreibt Data Marts auf relationaler Basis (R-OLAP) mit darauf aufsetzenden Analysesystemen für die Fachbereiche Marketing, Vertrieb, Controlling und Unternehmenssicherheit. Im Marketing-Bereich werden die Aufgaben des Cross Selling, des Churn-Managements, des Kunden-Managements und der Produktentwicklung unterstützt. Der Vertrieb befasst sich mit dem Umsatz-Monitoring, dem Management der unterschiedlichen Vertriebskanäle sowie der Provisionierung. Der Controlling-Bereich behandelt die Themen Umsatz- und Kostencontrolling, Forderungsausfälle und Intercarrier-Management. Die Unternehmenssicherheitsabteilung schließlich ist für die Betrugserkennung (Fraud Detection) mit Hilfe von Analyse- und DataMining-Verfahren verantwortlich.

217

5 Praktische Anwendungen

Aggregationsniveau

Daten

Call Detail Record (CDR)

• Kunde • A-Nummer • B-Nummer • Start-Datum • Start-Uhrzeit • Minuten • Zeitzone • Entfernungszone • Paket-ID • ...

CDR-Low-Level-Aggregat

• Kunde • B-Nummerngruppe • Datum • Stunde (0-23) • Minuten • Zeitzone • Entfernungszone • Paket-ID

CDR-High-Level-Aggregat

• Kunde • Jahr & Monat • Minuten • Entfernungszone • Zeitzone

Abb. 5.5: Operational Data Store und Core Data Warehouse

Aggregationsniveaus der Call Detail Records

Auf den Operational Data Store und das Core Data Warehouse haben nur ca. 20 Power-User und Analysten direkten Zugriff. Die übrigen Endbenutzer arbeiten dagegen mit den interaktiven Analysesystemen oder erhalten Standardberichte, die mit Hilfe der BI-Anwendungssysteme generiert werden.

Entwicklung und Betrieb Die Entwicklung der dispositiven Datenbasis und der Analysesysteme begann Ende der 90er Jahre. Das Vorgehen basierte auf einem Rahmenkonzept, in dem sowohl die Datenhaltungsinfra218

5.3 Data-Mart-basierte CRM-Anwendung im Einzelhandel struktur als auch die einzelnen BI-Anwendungssysteme vorab in einem Portfolio geplant und priorisiert wurden. Dieser „Masterplan“ ist zwischenzeitlich vollständig abgearbeitet, so dass die wesentlichen Anforderungen an die Anwendungen erfüllt sind. Laufende Weiterentwicklungen werden auf der Basis aktueller Anforderungen der Fachbereiche durchgeführt, wobei für die Betreuung und Weiterentwicklung eine zehnköpfige Betreuungsgruppe im IT-Bereich installiert wurde.

Abschließende Bemerkungen Die Erstellung des ODS-basierten DWH-Ansatzes wird im Unternehmen als richtiger Ansatz bewertet, da ohne diese Systeme eine erfolgreiche Steuerung des Geschäftes nach der Liberalisierung des Telekommunikationsmarktes nicht möglich sei. So konnten mit Hilfe der Systeme in den letzten Jahren CrossSelling-Erfolge signifikant gesteigert und die Abwanderungsrate der Kunden mit Hilfe des Churn-Managements um 50 Prozent gesenkt werden. Nach Angaben des IT-Bereiches hat sich vor allem auch die Entwicklung des ODS bewährt, da mit Hilfe dieses Systems eine operativ ausgerichtete, betriebswirtschaftlich und technisch harmonisierte Datenhaltung entstanden ist. BI-Neuentwicklungen bedienen sich in aller Regel ausschließlich dieses Quellsystems, so dass erhebliche Vereinfachungen aufgrund überflüssiger Schnittstellendefinitionen zu operativen Quellsystemen konstatiert werden können.

5.3

Data-Mart-basierte CRM-Anwendung im Einzelhandel Einer der viel diskutierten Anwendungsbereiche für BusinessIntelligence-Technologien ist das Customer Relationship Management (CRM). Im Folgenden wird eine BI-Anwendung für ein Kampagnenmanagement vorgestellt, wobei neben dem BIspezifischen analytischen CRM auch die für die Lösung relevanten Teile des operativen CRM erörtert werden (vgl. Abb. 5.6 und Kapitel 3.1.2).

219

5 Praktische Anwendungen Business Intelligence (BI) Informationszugriff

Informationsdistribution

Analysesysteme

Data Mart

Datenbereitstellung

Content & Document Mgmt.

Core Data Warehouse Operational Data Store

Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Abb. 5.6:

Systemintegration

Informationsgenerierung/ -distribution

BI-Portal

Metadaten

Data-Mart-basierte CRM-Anwendung im Kampagnenmanagement (mit Core DWH)

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

Externe Daten

Customer Relationship Management im Einzelhandel

Unternehmen Das Unternehmen ist eine Kaufhauskette mit Filialen in mehreren deutschen Großstädten. Um auf den verschärften Wettbewerb zu reagieren und eine zielgruppenspezifische Preis- und Rabattpolitik des Marketings zu unterstützen, entschied sich das Unternehmen frühzeitig, eine Kundenkarte mit einem entsprechenden Bonusprogramm ins Leben zu rufen.

Motivation und Zielsetzung Dem Einzelhandel stehen umfangreiche Anreizinstrumente in Form von Rabatten und Zugaben zur Verfügung. Deren Einsatz ermöglicht einen Dialog mit dem Kunden, in dessen Rahmen er Informationen über sein Kaufverhalten und seine Interessen zur Verfügung stellt. Teile dieser Informationen werden z. B. bei der Beantragung der Kundenkarte direkt abgefragt, während ein Großteil durch die Benutzung der Karte im Rahmen von Einkäufen indirekt erfasst wird. Direktmarketing durch Kampagnenmanagement

Dieser Informationsbestand ermöglicht ein Direktmarketing, bei dem der Kunde individuell mit einem konkreten, für ihn (vermutlich) interessanten Angebot angesprochen wird. Die Umsetzung des Direktmarketings erfolgt durch ein Kampagnenmanagement, das „die Planung, Abwicklung und Steuerung aller Aktivitäten bei der Durchführung einer Marketing- oder Verkaufsaktion“ umfasst (Englbrecht et al. 2004, S. 343). Ein integriertes Kampagnenmanagement ermöglicht eine individualisierte, effektive und effiziente Kundenansprache, in deren

220

5.3 Data-Mart-basierte CRM-Anwendung im Einzelhandel Rahmen geeignete Kommunikationskanäle – wie z. B. E-Mail, Post oder Telefon – kombiniert werden. Aufgrund der verbesserten Datenbasis in Form der individuell zuordenbaren Nutzungsdaten der Kundenkarte entschloss sich das Warenhaus zur Implementierung eines operativen Kampagnenmanagementsystems. Ergänzt werden sollte dies durch mehrere analytische BIKomponenten, welche die Entwicklung und Auswertung von Kampagnen unterstützen und die Responsequoten verbessern sollten.

Lösungskonzept Datenbereitstellungsebene

Die Verkäufe der Kunden werden an der Kasse im Warenhaus, dem sog. Point of Sale (POS), erfasst und gespeichert. Pro Tag werden dabei bundesweit bis zu einer Million Transaktionen durchgeführt, die nach Ladenschluss in einem batch-orientierten periodischen ETL-Lauf in ein Core Data Warehouse geladen werden. Die Daten werden historienbildend abgelegt, so dass nach einem sechsjährigen Produktivbetrieb das C-DWH ein Volumen von mehr als zehn Terabyte erreicht hat. Um das Kampagnenmanagement performant unterstützen zu können, kommt ein dedizierter Data Mart zum Einsatz. Neben den aggregierten Nutzungsdaten der Kundenkarten sind darin die Stammdaten der Kunden sowie die Spezifika der einzelnen Kampagnen gespeichert. Der Data Mart ist hierbei die gemeinsame Datenhaltung, auf die das operative Kampagnenmanagementsystem und die Analysesysteme zugreifen.

Analysesysteme

Zur Einordnung der eingesetzten Analysesysteme dient ein Regelkreis des Kampagnenmanagements, der die Phasen der Kampagnenentwicklung, -durchführung und -auswertung unterscheidet (vgl. Abb. 5.7). Im Rahmen der Kampagnenentwicklung wird die Planung der Kampagne vorgenommen. Operative Tätigkeiten, die hierbei abgewickelt werden, umfassen die Zieldefinition, die Budgetund Zeitplanung und die Prozessdefinition.

221

5 Praktische Anwendungen Trigger Zieldefinition

Zeitplanung Zielgruppenselektion

Wirkungsanalyse

er op

Responsemessung

ati

v

Kanalwahl

Kampagnenentwicklung

Kampagnenauswertung

Budgetplanung str at e gi s ch

Kostenanalyse

Prozessdefinition Ausführung und Steuerung

Kanalbefüllung

Kampagnendurchführung

Abb. 5.7: Zielgruppenselektion

Regelkreis des Kampagnenmanagements (Englbrecht et al. 2004, S. 343)

Ein besonderer Schwerpunkt liegt auf der Zielgruppenselektion, welche die Segmentierung der Kunden sowie die Auswahl der Zielsegmente und Kontrollgruppen umfasst. Dadurch wird die Konzentration auf möglichst homogene, eng abgegrenzte Kundengruppen gewährleistet. Als Data-Mining-Methoden kommen hierbei neuronale Netzwerke und Verfahren der multivariaten Statistik – wie z. B. die Clusteranalyse – zum Einsatz. Darüber hinaus können auch klassische Selektionsverfahren wie die ABC- oder RFMR-Analyse eingesetzt werden (Kaufdatum (Recency), Kaufhäufigkeit (Frequency) und Umsatzhöhe (Monetary Ratio), vgl. Englbrecht et al. 2004, S. 347; Musiol 1999, S. 31).

Kanalwahl

Bei der Kanalwahl werden ein oder mehrere passende Kommunikationsmedien für eine Kampagne gewählt. Kriterien hierfür sind u. a. die Präferenz des Kunden, die Kosten-Nutzen-Relation sowie die Responsewahrscheinlichkeit. Eine Entscheidungsfindung wird durch die Analyse der Ergebnisdaten aus bisherigen Kampagnen mit den oben genannten Data-Mining-Methoden unterstützt.

Kampagnendurchführung

Die Kampagnendurchführung umfasst die eigentliche Umsetzung und ist eine typische Anwendung des operativen CRM. Aus diesem Grund wird sie an dieser Stelle nicht weiter vertieft.

222

5.3 Data-Mart-basierte CRM-Anwendung im Einzelhandel Kampagnenauswertung

Bei der Kampagnenauswertung werden nach Abschluss der Kampagne die Daten zu den Rückläufern gemessen, gespeichert und weiterverarbeitet. Die Responsemessung erfasst in einem ersten Schritt die Warenkäufe, die der Kampagne direkt zuordenbar sind, im Kampagnenmanagementsystem. Darauf aufbauend werden im Rahmen der Wirkungsanalyse mit Hilfe von Data-Mining- und OLAP-Systemen Auswertungen durchgeführt. Das Ziel ist die Gewinnung handlungsrelevanter Informationen für den weiteren Verlauf der Kampagne oder zukünftige Kampagnen. Durch eine Assoziationsanalyse werden z. B. Cross-SellingPotenziale identifiziert, während eine Sequenzanalyse die Interdependenzen mehrerer aufeinander folgender Kampagnen aufzeigt. Ein weiterer wichtiger Punkt ist die Analyse des Reaktionsverhaltens, durch die unnötige Mailings mit niedriger Erfolgswahrscheinlichkeit vermieden werden können. Neben dem Effekt der Kosteneinsparung wird somit auch eine Verärgerung der Kunden durch unpassende oder ungewünschte Angebote vermieden. Diese Beispiele zeigen lediglich exemplarisch die Potenziale der Analysesysteme in der Kampagnenauswertung auf. Darüber hinaus sind auch weitere unternehmens- und kampagnenspezifische Analysen denkbar. Neben der Anwendung von Data-MiningModellen werden generelle Auswertungen über Standardberichte abgedeckt. Darunter fällt vor allem die Kostenanalyse, in welcher der Aufwand und der Erfolg in Form von Rückmeldungen monetär bewertet und in Verhältnis gesetzt wird.

Lernzyklus durch Closed-loop

Die Auswertungsphase des Kampagnenmanagements ist essenziell wichtig für die Etablierung eines Lernprozesses im Direktmarketing. Durch die Auswertungen entsteht Wissen über die Zusammenhänge zwischen Kundengruppen, Produkten und Kommunikationskanälen. Dieses kann in der Entwicklungsphase zukünftiger Kampagnen verwendet werden und ermöglicht somit eine sukzessive Verbesserung des Kampagnenmanagements. Technisch wird dies durch einen Closed-loop realisiert, indem die Daten aus der Responsemessung (Kanäle, Produkte/Produkttypen, Zielgruppen, Datum, vor- oder nachgeschaltete Kampagnen usw.) und der Wirkungsanalyse (Cluster mit hohen Responsequoten) in den Data Mart zurück geschrieben werden.

Entwicklung und Betrieb Das integrierte Kampagnenmanagement konnte bereits auf ein existierendes Core Data Warehouse mit einem entsprechenden Datenmodell aufbauen. Für den Data Mart wurde eine entspre223

5 Praktische Anwendungen chende Erweiterung zur Unterstützung der Kampagnen vorgenommen. Prototypengestütz- Bei der Auswahl der BI-Komponenten wurde ein Best-of-BreedAnsatz gewählt, bei dem die jeweils am besten geeigneten BIte Entwicklung Werkzeuge ausgewählt wurden. Um die Umsetzbarkeit zu gewährleisten wurde im Vorfeld ein Prototyp entwickelt (proof of concept). Dabei wurden die Mitarbeiter des Marketingbereichs einbezogen. Einzelne Benutzer hatten bereits Erfahrung mit Data-Mining-Anwendungen, die in den Entwicklungsprozess mit einfließen konnten.

Abschließende Bemerkungen Steigerung der Responsequote

Das Projekt wird unternehmensintern als Erfolg gewertet. Die Einführung eines integrierten Kampagnenmanagements eröffnete dem Unternehmen neue Effizienz- und Effektivitätspotenziale. Die in der Zielsetzung geforderte Verbesserung der Antworten wurde umgesetzt. Die Responsequote stieg um 300%, während die Anzahl der durchschnittlich angeschriebenen Kunden um 60% verringert wurde. Daraus resultieren Einsparungen bei den Werbekosten (z. B. für Postsendungen), so dass sich der zusätzliche Aufwand für die Bereitstellung des BI-Systems und die Durchführung der Analysen rechnet.

Integrierte Unterstützung der Kampagnendurchführung

Durch die strukturierte IT-unterstützte Vorgehensweise wurde die Koordination und Durchführung von mehr als 300 Kampagnen pro Jahr ermöglicht. Die analytischen BI-Komponenten stellten dabei die inhaltliche Abstimmung und die Nutzung der Erfahrungen aus vorangegangen Kampagnen sicher und ermöglichten auf diese Weise eine Optimierung der Marketingaktionen hinsichtlich ihrer Qualität und Quantität.

5.4

Real-time Data Warehousing einer Börsenorganisation In diesem Praxisfall wird eine Real-time-Data-WarehousingLösung vorgestellt, die interne und externe Benutzer mit statistischen Finanzmarktdaten versorgt. Die Datenhaltung verbindet historische und aktuelle Informationen, wie beispielsweise Preisund Umsatzdaten, Orders und Kursnotierungen, Clearing- und Abwicklungsdaten sowie Stammdaten zu Finanzinstrumenten, Börsenzulassungen und Handelsteilnehmern (vgl. Abb. 5.8).

224

5.4 Real-time Data Warehousing einer Börsenorganisation Business Intelligence (BI) BI-Portal

Informationsdistribution

Analysesysteme

Data Mart

Datenbereitstellung

Systemintegration

Informationsgenerierung/ -distribution

Content & Document Mgmt.

Core Data Warehouse Operational Data Store

Real-time Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Abb. 5.8:

Right Time

Informationszugriff

Metadaten

• Umfassendes BI-Anwendungssystem einer Börsenorganisation • Basierend auf Real-time Data Warehousing mit EchtzeitAnbindung an die operativen Systeme • Analysesysteme • Weltweite Distribution der Informationen • Portal-Zugriff

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

Externe Daten

Auf Real-time Data Warehousing basierendes BI-Anwendungssystem einer Börsenorganisation

Unternehmen Das betrachtete Unternehmen war ursprünglich eine nationale Wertpapierbörse und hat sich inzwischen zur größten Börsenorganisation der Welt entwickelt. Das Unternehmen erzielt einen Umsatz von über 2 Milliarden Euro pro Jahr mit ca. 3.000 Mitarbeitern. Über ein vollelektronisches Handels- und Abwicklungssystem sowie den Parketthandel werden ca. 96 Prozent des nationalen Aktienhandels abgewickelt.

Motivation und Zielsetzung Die durch den internetbasierten Handel entstandenen neuen Rahmenbedingungen des Geschäftsumfeldes haben die Nachfrage interner und externer Nutzer nach präzisen und vertrauenswürdigen Informationen zur Entscheidungsunterstützung in Echtzeit enorm erhöht. Das Unternehmen stellt sich dieser Herausforderung und hat sich zum Ziel gesetzt, mit Hilfe von Technologieführerschaft und schnellem Wachstum seine Position auf den von starkem Wettbewerb geprägten Finanzmärkten zu festigen und die globale Präsenz zu erhöhen. Hierbei besitzt das an dieser Stelle skizzierte BI-Konzept eine Schlüsselrolle, da es die erforderlichen Informationen weltweit an die Finanzplätze verteilt und eine zeitnahe Analyse dieser Massendaten erlaubt.

Lösungskonzept Systemanforderungen

Der BI-Gesamtansatz hat die Aufgabe, Handelsinformationen aus unterschiedlichen Börsenplätzen und -systemen in einem historienbildenden Core Data Warehouse zusammenzuführen, das als Basis für Informationsprodukte und für Datenanalysen dient. 225

5 Praktische Anwendungen Zielgruppen sind hierbei sowohl interne Mitarbeiter als auch Medien, externe Handelsteilnehmer und Emittenten. Interne Nutzer

Interne Nutzer sind die Manager, Analysten und Strategieentwickler des Unternehmens, die BI-Anwendungen für folgende Zwecke benötigen: • Kennzahlen hinsichtlich Liquidität, Rentabilität, Handel, Effizienz der Wertpapierabwicklung usw. • Identifikation von Markt- und Aktientrends. • Unterstützung neuer Produktentwicklungen und Marktinitiativen.

Externe Nutzer

Externe Nutzer sind Kunden, Händler, Wertpapier-Emittenten und Analysten, die sowohl operative als auch dispositive Informationen benötigen, auf deren Grundlage sie Handelsentscheidungen treffen, Portfoliostrategien erarbeiten sowie die Bereiche Vertrieb und Investor/Analyst Relations unterstützen können: • Verbreitung von präzisen Informationen zum erforderlichen Zeitpunkt („right-time“). • Spezifische Daten für jedes Marktsegment (z. B. Aktien, Rentenwerte, Derivate, Kassa-Märkte). • Historische Analysen über beliebige Dimensionen und Kennzahlen (z. B. Stückzahl, Preis, Zeit). • Flexible Zugangs- und Distributionskanäle (z. B. E-Mail, World Wide Web, File Transfer Protocol). • Analyse- und Verifizierungsmöglichkeiten für Handels- und Portfoliostrategien. • Identifikation von Markt- und Aktientrends.

Quellsysteme

Das Core Data Warehouse bindet insgesamt 25 operative Quellsysteme aus verschiedenen Geschäftsbereichen an. Nachfolgend werden die drei wichtigsten Quellen genannt: • Die Handelssysteme und Handelsinformationssysteme, deren originäre Aufgabe – neben dem eigentlichen Handel – die Erfassung, Formatierung und Anreicherung von Handelsdaten ist, die an Informationsdienstleister (wie z. B. Reuters™) verteilt werden. • Das Wertpapierinformationssystem, das tagesaktuelle Informationen zu etwa 350.000 weltweit notierten Wertpapieren bereithält. • Das Wertpapierabwicklungssystem für den nationalen Markt.

226

5.4 Real-time Data Warehousing einer Börsenorganisation C-DWH

Sämtliche Daten der relevanten operativen Systeme werden in das relationale Core Data Warehouse überführt und dort nahezu voll normalisiert (nahe 3NF) in hoher Detaillierung abgelegt. Diese Datenhaltung ist das Herzstück des Gesamtansatzes und stellt eine exklusive Datenquelle für alle o. a. IT-Systeme der internen und externen Benutzer dar. Das Core Data Warehouse wird aus diesem Grunde auch als unternehmensspezifischer single point of truth bezeichnet und über anspruchsvolle technische und organisatorische Mechanismen in seiner Konsistenz, Integrität, Performance und Verfügbarkeit gesichert.

Real-time Data Warehousing

Ein Teil der Beladung des C-DWH mittels Transformationsprozessen wird sowohl tagsüber als auch nachts in zahlreichen Batch-Prozessen durchgeführt. Die Besonderheit dieses BI-Anwendungssystems stellt jedoch derjenige Teil der Beladung dar, der in Echtzeit auf der Basis von Real-time Data Warehousing erfolgt. Zum einen erfolgt eine messagebasierte Echtzeitanbindung eines Handelsinformationssystems. So können bis zu 10.000 Messages pro Sekunde des Echtzeitdatenstroms dieses Handelsinformationssystems verarbeitet werden. Zum anderen werden über eine fachliche Administrationsschnittstelle (vgl. Kapitel 2.3.6), die technisch auf Basis einer EAI/WorkflowMiddleware realisiert wurde, von Spezialisten qualitätsgesicherte Informationen – wie z. B. aus Börsenpflichtblättern – in das C-DWH eingespeist. Insgesamt werden derzeit täglich ca. 500 Millionen Datensätze geladen, so dass eine Steigerung des Datenvolumens um etwa 20 Gigabyte pro Tag zu bewältigen ist.

Applikationsorien- Zur datenseitigen Unterstützung der Applikationen existieren innerhalb des Ansatzes keine dedizierten, physisch eigenständitierte Aggregate gen Data Marts. Vielmehr werden DWH-Extrakte applikationsorientiert aufbereitet – also aggregiert und angereichert – und in performanceoptimierter, denormalisierter Form logisch von den Detaildaten getrennt im relationalen System abgelegt. Datendistribution Die Distribution der Daten der dispositiven Datenbasis erfolgt entsprechend der explizit festgelegten Anforderungen zeitgenau über mehrere Kanäle, wie das World Wide Web, E-Mail oder FTP (File Transfer Protocol). Zusätzlich können M-OLAP-Datenwürfel extrahiert und bereitgestellt werden, die den Benutzern bei Bedarf die Durchführung freier Datenrecherchen und Ad-hocAbfragen in Bezug auf den Wertpapierhandel ermöglichen. Auf diese Weise werden weltweit ca. 3.000 externe Kunden – primär institutionelle Marktteilnehmer – bedient. Zusätzlich steht den internen Benutzern ein BI-Portal zur Verfügung, das 227

5 Praktische Anwendungen personalisierten, komfortablen Zugang zu allen Systemen und Komponenten ermöglicht. Neben der direkten Informationsversorgung von Mitarbeitern und externen Anspruchsgruppen besitzt die Datenhaltung die zusätzliche Aufgabe, als Quellsystem für die automatische Beladung nachgelagerter Systeme zu dienen, wie beispielsweise im Falle von vollelektronischen Handelssystemen, Web-Auftritten u. ä.

Entwicklung und Betrieb Die Entwicklung erfolgte mit Hilfe einer inkrementellen Vorgehensweise auf Basis eines Rahmenkonzeptes. In einem ersten initialen Projekt wurden primär technische Herausforderungen gelöst, indem beispielsweise Standardprozesse und wieder verwendbare Vorlagen definiert wurden. Diese Infrastrukturmaßnahmen dienten als Grundlage für die nachfolgenden Entwicklungsprojekte, in denen weitere Teilsysteme entlang der Wertschöpfungskette des Unternehmens implementiert worden sind. Sie decken heute die Bereiche von der Datensammlung, der Datentransformation und der Datenspeicherung bis hin zur Produktentwicklung und -distribution ab. Während der technische Betrieb – das Hosting – von der ITTochter des Unternehmens übernommen wird, obliegt die restliche Verantwortung für die Systemnutzung und insbesondere für die Korrektheit der ausgelieferten Daten einer eigenständigen, 17 Mitarbeiter umfassenden Organisationseinheit nach dem Prinzip der Single Process Ownership. Hier sind verantwortliche Rollen etabliert worden, die für die strategische Weiterentwicklung des Systems zuständig sind und für die Ausarbeitung neuer Anwendungsszenarien und marktfähiger Produkte sowie für das technische Innovationsmanagement des Systems Sorge tragen.

Abschließende Bemerkungen Die Umsetzung des Gesamtansatzes wird als Erfolg gewertet und erfreut sich unternehmensintern und -extern höchster Akzeptanz. So konnten in den letzten Jahren wesentliche Beiträge zur Kostenreduktion durch die Ablösung unwirtschaftlicher Altlösungen erbracht werden. Gleichzeitig erhöhte sich die Flexibilität und Innovationsfähigkeit des Unternehmens signifikant, so dass neue Märkte erschlossen und die Qualität der Kundenbetreuung nachhaltig verbessert werden konnten.

228

5.5 Agil entwickeltes BI-System einer Bankgesellschaft

5.5

Agil entwickeltes BI-System einer Bankgesellschaft In diesem Praxisfall wird eine agil entwickelte BI-Anwendung vorgestellt, die für den Wertpapierhandel einer Großbank aufgebaut wurde. Sie besitzt – parallel zum bankumfassenden BIGesamtkonzept – eine eigenständige Architektur bestehend aus einem Core Data Warehouse und anwendungsspezifischen Data Marts. Ferner werden Datenanalysen über entsprechende Schnittstellen um unstrukturierte Daten des Unternehmens (z. B. Texte) aus Content und Document Management Systems erweitert (vgl. Abb. 5.9). Business Intelligence (BI) Informationszugriff

Informationsdistribution

Analysesysteme

Data Mart

Datenbereitstellung

Content & Document Mgmt.

Core Data Warehouse Operational Data Store

Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Abb. 5.9:

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

Systemintegration

Informationsgenerierung/ -distribution

BI-Portal

Metadaten

• Agil entwickeltes BI-Anwendungssystem im Wertpapierbereich einer Großbank • Einbezug unstrukturierter Informationen • OLAP-Analysesysteme • Portal-Zugriff

Externe Daten

Agil entwickeltes BI-Anwendungssystem im Wertpapierbereich einer Großbank

Unternehmen Die Gesellschaft gehört zu den größeren Privatbanken, beschäftigt mehrere tausend Mitarbeiter, besitzt zahlreiche Geschäftsstellen und verfügt weltweit über eine Millionen Kunden. Die Bank hat umfangreiche Services sowohl für Privat- als auch für Geschäfts- und Firmenkunden. Das Leistungsportfolio reicht hierbei für Privatkunden von Kontenführung, Kreditkarten, Kredite, Sparen, Vorsorgen bis zur Immobilienfinanzierung. Für Geschäfts/Firmenkunden bietet die Bank umfangreiche Services wie Anlagenmanagement, Finanzierung oder Finanzrisikomanagement an.

Motivation und Zielsetzung

Etablierter BI-Ansatz

Die Bank verfügt über einen integrierten BI-Gesamtansatz mit einem unternehmensumfassenden Core Data Warehouse und darauf aufsetzenden abhängigen Data Marts. Für die Entwicklung von BI-Anwendungen werden in aller Regel iterative Vorgehensmodelle verwendet, die als inkrementelle Ansätze für die 229

5 Praktische Anwendungen Erstellung einzelner BI-Anwendungen im Rahmen des Gesamtkonzeptes herangezogen werden.

Veränderungsbedarf

Vor einigen Jahren wurde jedoch deutlich, dass dieser Ansatz nicht in allen Anwendungsdomänen zu befriedigenden Lösungen führte. Gerade den neuen Herausforderungen des Geld- und Kapitalmarkthandels konnte das Konzept nicht genügen. Die Komplexität des Geschäftes, die große Marktdynamik und die enorme Geschwindigkeit, mit der innovative Produkte am Markt platziert werden müssen, verlangten nach Meinung der Analysten nach neuen Ansätzen. Da teilweise revisionssichere Systemmodifikationen bzw. Neuentwicklungen in kürzester Zeit – teilweise sogar mehrfach täglich – zur Verfügung gestellt werden sollten, war allen Betroffen klar, dass gravierende Veränderungen in der BI-Architektur sowie bei der Systementwicklung, des Testens und der operativen Systemübergabe erforderlich waren. Die Neuausrichtungen dieses BI-Bereiches verlangten somit nach technologischen, prozessualen und organisatorischen Modifikationen. Erklärte Ziele waren dabei:

Ziele

•

Suche nach einem geeigneten Prozessmodell,

•

Aufbau einer eigenständigen, auf das Anwendungsgebiet ausgerichteten BI-Architektur,

•

Verbesserung der Kommunikation zwischen Fach- und ITBereich und

•

Sicherstellung der Revisionsfähigkeit.

Lösungskonzept Für die Lösung wurde ein eigenständiges, bereichsspezifisches Data Warehouse aufgesetzt. Der Zugriff auf operative Daten erfolgt über die ETL-Prozesse einer Staging Area. Hierbei werden ca. 70 operative Quellen eingebunden, deren Daten über Transformationsprozesse gefiltert und harmonisiert in das DWH geladen werden. Die Aggregation und die Anreicherung erfolgen in einer separaten Applikationsschicht. Die Daten werden anschließend in acht mehrdimensionalen Data Marts zur Verfügung gestellt, die in Form von R-OLAP-Systemen die Analyse und Berichterstattung ermöglichen.

Systemfuktionalitäten 230

Inhaltlich bildet das System sämtliche Facetten des Handelsprozesses ab, gibt Auskunft über Risiken und unterstützt das Limitmanagement, wobei über eine direkte Schnittstelle zum Content und Document Management zusätzliche unstrukturierte Informationen des Unternehmens eingebunden werden können. Das

5.5 Agil entwickeltes BI-System einer Bankgesellschaft System wird von ca. 200 Benutzern kontinuierlich verwendet, generiert ca. 1.000 Wochenberichte und wird ca. 500mal pro Woche für Ad-hoc-Analysen herangezogen.

Entwicklung und Betrieb Eines der Hauptprobleme war die organisatorische Neugestaltung der Arbeitsteilung zwischen IT- und Fachbereich. Hier wurde nach heftigen, kontrovers geführten Diskussionen und unter Einbindung der Geschäftsleitung eine strukturelle Neugliederung vereinbart. Diese sah vor, dass die Aufgabenteilung zwischen ITund Fachbereich grundlegend neu zu gestalten sei.

IT- und Fachbereich

So wurden die anwendungsorientierten IT-Mitarbeiter aus dem Verantwortungsbereich der IT gelöst und organisatorisch dem Fachbereich zugeordnet. Diese haben nun ihren Arbeitsplatz in der Business Unit und sind dem Leiter des Bereiches fachlich und disziplinarisch unterstellt. Ihre Aufgaben umfassen: •

Erstellung/Erweiterung der Portallösung

•

Entwicklung der Geschäftslogiken

•

Datenmodellierung und -qualitätssicherung

•

ETL- und Jobcontrol-Prozesse

Für diese Zwecke wurden im Fachbereich bewusst leistungsfähige Werkzeuge („Best-of-Breed-Ansatz“) eingesetzt, die über grafische Oberflächen ETL-Prozesse generieren, automatisch konsistente Metadaten erzeugen und die grafische Modellierung multidimensionaler Datenräume erlauben. Dem IT-Bereich obliegen hingegen weiterhin die klassischen, techniknahen Aufgaben, wie die Bereitstellung der Infrastruktur, der Sicherheit, des Tuning und des automatischen DeploymentProzesses.

Agiles Vorgehensmodell

Für den Systementwicklungsprozess wurde ein agiles Verfahren entwickelt, das die Arbeitsteilung zwischen IT- und Fachbereich unterstützt. Die im Fachbereich eingebundenen Anwendungsspezialisten sind – wie oben erwähnt – dafür zuständig, die Jobs zu erstellen, die Geschäftslogik zu entwickeln, die Reports zu generieren und den Deployment-Prozess anzustoßen. Hierfür sind explizit Prozessvorgaben definiert, z. B. das VieraugenPrinzip oder das gegenseitige Quittieren. Der IT-Bereich verantwortet hingegen bei Nutzung des agilen Vorgehensmodells lediglich die Aufgabe, bei auftretenden Fehlern ein zeitnahes Rollback der Altlösung zu gewährleisten. 231

5 Praktische Anwendungen

Abschließende Bemerkungen Die Umsetzung des agilen Konzeptes wird als voller Erfolg gewertet und ist kulturell im Unternehmen erfolgreich verankert. Anfängliche Ressentiments haben sich gelegt und aus heutiger Sicht tragen die eigenständige BI-Architektur und das agile Vorgehensmodell hervorragend dazu bei, das volle Potential der IT als Befähiger neuer, wirksamer Prozessstrukturen umzusetzen.

5.6

Unternehmensübergreifende BI eines Bundesverbandes Der in diesem Kapitel vorgestellte Fall zeichnet sich v. a. durch seine unternehmensübergreifende Ausrichtung aus (vgl. Abb. 5.10). Er verdeutlicht den Professionalisierungs- und Integrationsnutzen eines zentralisierten DWHs, in dem Daten mehrerer Unternehmen zusammengebunden werden.34 Entscheidend für die Bereitschaft der beteiligten Partner, sich an dem zentralen DWH zu beteiligen, war dabei nicht zuletzt die Wahl eines bei allen Beteiligten bekannten, akzeptierten und als unparteiisch angesehenen Intermediärs.

Business Intelligence (BI) Informationszugriff

Datenbereitstellung

OLAP und Reporting Simulation Data Mining

Informationsdistribution mit unterschiedlichst en Formaten

Data Mart Core Data Warehouse

Content & Document Mgmt.

Systemintegration

Informationsgenerierung/ -distribution

BI-Portal

Metadaten

• Unternehmensübergreifendes DWH mit Hub-andSpoke-Architektur • Dezentrale Metadatenhaltung • Mandantenfähigkeit

Transformationswerkzeug

Sonstige Leistungserbringer

Diverse externe Datenlieferanten Kassenärztliche Vereinigungen

Krankenkassen Krankenhäuser

Abb. 5.10: Unternehmensübergreifendes DWH in einem Krankenkassenverband

Unternehmen Die Gesellschaft bürgerlichen Rechts agiert als Spitzenverband von über hundert Krankenkassen und führt für diese Institutio-

34

232

Weitere Informationen über den zugrundeliegenden Fall finden sich in Teradata (2007).

5.6 Unternehmensübergreifende BI eines Bundesverbandes nen übergreifende Aufgaben bei der Interessensvertretung, in der Presse- und Öffentlichkeitsarbeit, bei der Kooperationsförderung und beim elektronischen Datenaustausch durch. Für letzteres übernimmt der Verband die Rolle einer zentralen Clearing-Stelle, wobei ungefähr eine halbe Millionen Leistungserbringer (Apotheker, Ärzte, Krankenhäuser u. ä.) angeschlossen sind, die ihre Abrechnungsinformationen über den Verband an die Krankenkassen weiterleiten. Dies betrifft Daten von ca. 15 Millionen Versicherten.

Motivation und Zielsetzung

Anspruchsvolle modellbasierte Analysen auf einer unternehmensübergreifend integrierten Datenbasis

Mit der Einrichtung eines zentralen DWH beim Verband wurde zum einen angestrebt, die einzelnen Krankenkassen von den Aufgaben des technischen Aufbaus eigener Reportinglösungen zu entlasten. Zum anderen ermöglichte eine umfassende Datenintegration die Entwicklung neuartiger Informationsservices. Beispiele sind die Darstellung der Ausgabenentwicklung bei den Krankenkassen oder der Einsatz anspruchsvoller modellbasierter Verfahren, z. B. Data-Mining-Analysen für die die Betrugserkennung, die Simulationen von Maßnahmen zur Krankheitsvorbeugung oder die Untersuchung der Wirksamkeit von Impfmaßnahmen. Darüber hinaus wird das DWH im Sinne des OperationalBI-Ansatzes (vgl. Kapitel 2.3.3) in der Angebots- und Rechnungsprüfung der Krankenkassen eingesetzt. Viele dieser Dienste könnten ohne das DWH nicht angeboten werden, da sie eine leistungsträgerübergreifende Datenintegration voraussetzen. Als etablierte Clearing-Stelle ist der Verband für diese Aufgaben prädestiniert.

Lösungskonzept Die in Abb. 5.10 visualisierte Architektur folgt einem Best-ofBreed-Ansatz, um eine performante Datenhaltung mit leistungsstarken Analysetools kombinieren zu können. Die von den Leistungserbringern bereitgestellten Abrechnungsdaten werden dem Verband über definierte Schnittstellen übergeben und in einem zentralen DWH gesammelt. Konkrete Informationslieferanten sind die Rechenzentren der Apotheken, kassenärztliche Vereinigungen, Krankenhäuser sowie diverse andere Leistungsträger. Zusätzlich integriert werden Daten zur Dimensionierung und Anreicherung, etwa über Produkte, Versicherte usw. Diese stammen von den Kassen selbst sowie teilweise auch aus externen Quellen. Die Heterogenität der Formate und Schnittstellen

233

5 Praktische Anwendungen machte die Entwicklung eines eigenen DatentransformationsWerkzeugs erforderlich. Das DWH selbst folgt einer Hub-and-Spoke-Architektur, wobei die Daten im C-DWH nahe der 3NF vorgehalten werden. Das dort hinterlegte Volumen beträgt ca. 10 Terabyte. Diese werden zur Sicherstellung der Verfügbarkeit zusätzlich gespiegelt. Die Kassen können über 150 logisch abgegrenzte Data Marts auf den Datenbestand zugreifen (die physisch auf einem System vorgehalten werden). Vielfältige Varianten der Informationsdistribution

Hohe Anforderungen an Berechtigungskonzept und Metadatenhaltung

Zur Analyse wird ein webbasiertes Reporting- und OLAPFrontend eingesetzt, das gleichermaßen für die Bereitstellung von Ad-hoc-Abfragen als auch für die Generierung von Standardberichten genutzt wird. Neben einer Ausgabe im HTMLFormat werden die Analyseergebnisse und Berichte zur Informationsdistribution auch in verschiedenen anderen Formaten (PDF, TM MS Excel , CSV, RSS-Feeds) bereitgestellt. Das System ist performant genug ausgelegt, um die derzeit ca. 2.500 Benutzer mit Informationen zu versorgen, wobei ca. 15% davon als Power User klassifiziert werden. Schon die Menge an Benutzern und beteiligten Organisationen erfordert ein striktes rollenbasiertes Autorisierungskonzept auf der Grundlage einer gezielten Metadatenpflege. Die Metadatenhaltung ist dezentral, d. h. es werden die Metadaten-Komponenten des DWH und des Analysewerkzeugs genutzt.

Entwicklung und Betrieb Die Entwicklung des Systems erfolgte stufenweise in einem Zeitraum von zehn Jahren. Hierzu wurde eine eigene Entwicklungseinheit mit mehreren Teilteams geschaffen. Für das System wurde ein professionelles Betriebs- und Servicekonzept erarbeitet, das neben einem zentralen Help-Desk auch regelmäßige Marketing- und Schulungsmaßnahmen beinhaltet. Ausbaufähigkeit durch mandantenfähige Lösung

Für die Zukunft wird die Öffnung der Lösung für andere Verbände verfolgt. Mit Blick auf diese Ausrichtung wurden alle Teilkomponenten bereits vollständig mandantenfähig ausgelegt, d. h. andere Verbände können auf derselben Funktionalität aufsetzen, agieren jedoch in eigenen, abgetrennten Datenräumen.

Abschließende Bemerkungen Der Krankenkassen-Verband kann als Modellfall für vergleichbare Lösungen von Unternehmensnetzwerken gesehen werden. 234

5.7 Data Warehousing in einer RFID-basierten Retail Supply Chain Organisationen, die als Betreiber ähnlicher Lösungen in Frage kommen, sind z. B. Internet-Marktplatzbetreiber, FranchiseGeber oder Leitungsgremien in Unternehmenskonsortien.

5.7

Data Warehousing in einer RFID-basierten Retail Supply Chain Im Rahmen des Lieferkettenmanagement (Supply Chain Management, SCM) werden DWH-basierte Systeme bereits seit geraumer Zeit angewendet, insbesondere in Form spezieller Planungsund Simulationsanwendungen (Advanced Planning Systems, APS). Das folgende Beispiel illustriert, wie neuartige Datenerfassungstechnologien im SCM für innovative BI-Anwendungen genutzt werden können. Konkret wird der Einsatz von Radio Frequency Identification (RFID, funkbasierte Identifikation) beleuchtet. Die Einordnung der Lösung in den Ordnungsrahmen dieses Buches verdeutlicht Abb. 5.11.

Business Intelligence (BI) Informationszugriff

Data Mart

Datenbereitstellung

Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Informationsdistribution

Analysesysteme

Content & Document Mgmt.

Operational Data Store

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

Systemintegration

Informationsgenerierung/ -distribution

BI-Portal

Metadaten

• Data Mart für das SCM (beim Warenverteilzentrum) • Vorhaltung angereicherter und integrierter RFID-Daten • Nutzung zur operativen Steuerung über ODS • Dispositive Nutzung zur Mustererkennung, Optimierung und Problemlokalisierung

Externe Daten

Abb. 5.11: Data-Warehousing in einer RFID-basierten Retail Supply Chain

RFID in der Supply Chain

Der Einsatz von RFID-Technologie im SCM wurde in den 2000erJahren vor allem durch Initiativen mehrerer größerer Handelskonzerne vorangetrieben. Flankiert wurden die Projekte durch weitreichende Standardisierungsmaßnahmen von Konsortien wie EPCglobal™, die sich nicht nur auf die RFID-Etiketten (Tags) selbst und die Lesegeräte (Reader) beziehen sondern auch auf die darauf aufsetzende Datenaustauschinfrastruktur (Angeles 2005). Die Potentiale der RFID-Technologie resultieren aus den Möglichkeiten einer weitgehend automatisierten Objektidentifikation, 235

5 Praktische Anwendungen einer Pulk-Erfassung (mehrere Objekte werden parallel identifiziert) sowie einer Kopplung von RFID-Systemen mit Sensorund/oder Lokalisierungs-Technologien. Dies verspricht eine erheblich gesteigerte Transparenz über Güterbewegungen in Lieferketten, wobei viele der diskutierten Nutzenaspekte eine Datenintegration, Datenaggregation und Datenanalyse implizieren – und damit eine BI-Lösung. Bei dem beschriebenen Projekt eines Handelskonzerns handelt es sich derzeit noch um eine (in Teilen pilotierte) Konzeption (Siegel 2008; Baars et al. 2008). Ähnliche Lösungen werden auch in anderen Supply Chains entwickelt und erprobt.

Unternehmen Das beschriebene Projekt wird maßgeblich von einem europäischen Handelskonzern vorangetrieben und in Kooperation mit mehreren IT-Dienstleistern, Herstellern und Logistikanbietern durchgeführt. Der Handelskonzern ist in insgesamt 25 Ländern aktiv und betreibt sowohl Groß- als auch Einzelhandelsgeschäfte (Verbrauchermärkte, Lebensmitteleinzelhandelsfilialen, Konsumelektronikfachmärkte). Die betrachtete Supply Chain betrifft Konsumgüterprodukte, die in der Volksrepublik China produziert, per Seeweg nach Europa transportiert und über ein (ebenfalls zum Handelskonzern gehörendes) Warenverteilzentrum an die einzelnen Filialen ausgeliefert werden.

Motivation und Zielsetzung Von der Einführung von RFID verspricht sich der Einzelhandel zunächst größere Automatisierungspotentiale (etwa in Warenannahme-, Sortier-, oder Kommissionierungsprozessen), eine Begegnung von Schwund und Fehllieferungen sowie korrektere und aktuellere Bestandsdaten. Die verbesserte Datengrundlage ist auch Ausgangspunkt für verbesserte Dispositionsentscheidungen. Warenverteilzentrum als koordinierende Instanz

236

Mittelfristig ist geplant, hierauf aufsetzend die Lieferprozesse grundlegend zu rekonfigurieren – und zu einer bedarfsgetriebenen Versorgung der Filialen zu kommen (Pull-Strategie), wobei das Warenverteilzentrum zur koordinierenden Instanz wird. Hierfür sollen sowohl die Filialen, die Hersteller als auch die diversen beteiligten Logistikdienstleister Entscheidungskompetenzen an das Warenverteilzentrum abtreten. Die erhofften Effekte sind deutlich verringerte Bestände in der Lieferkette, eine verbesserte

5.7 Data Warehousing in einer RFID-basierten Retail Supply Chain Verfügbarkeit von Waren bei den Filialen (Vermeidung von „Out-of-stock“-Situationen) sowie eine reduzierte Zahl an Fehlern. Eine Integration der betroffenen artikel- und lieferbezogenen Daten in einem DWH soll neben einer verbesserten Steuerung auch Analysen zur Aufdeckung von Problemursachen ermöglichen.

Lösungskonzept Die entwickelte Lösung setzt auf Konzepten des Konsortiums EPCglobal™ für einen unternehmensübergreifenden Datenaustausch auf:

EPC-Standards als Grundlage

•

EPC-Codes zur Identifikation von Containern, Paletten und Einzelartikeln,

•

lokale Repositories mit der von EPCglobal™ definierten Datenübergabe-Schnittstelle EPC Information Services (EPCIS) sowie

•

das EPCglobal Network, mit dem unternehmensübergreifend Daten zu RFID-bezogenen Ereignissen („EPC Events“) abgelegt und abgefragt werden können.

Des Weiteren werden in den betrachteten Szenarien Positionsund Sensordaten erhoben. Durch die Sammlung der Daten beim Warenverteilzentrum sowie eine Integration mit weiteren Daten zur Produktion (z. B. aus den Manufacturing Execution Systems der Hersteller), zu den Lieferstrecken, zu den Regalflächen und Kapazitäten (aus den diversen Warehouse Management Systemen) usw. kann ein harmonisierter Datenbestand für die Entscheidungsunterstützung in der Logistik aufgebaut werden (vgl. Abb. 5.12). Der Datenbestand kann sowohl transaktionsnah (Near-time) zur Unterstützung der operativen Steuerung und Kontrolle eingesetzt werden als auch – bei Historisierung und Aggregation – als Grundlage weiterreichender Entscheidungen, etwa bei der Aufdeckung von Problemen bei bestimmten Verantwortlichkeiten, Lieferstrukturen oder Umweltkonstellationen. Beispiele für auf den Daten basierende Anwendungen: •

Die Identifikation von Mängeln an Gütern während des Transports (beispielsweise auf Basis von Temperatur-, Feuchtigkeits- oder Drucksensoren) sowie darauf aufsetzend die Lokalisierung von Mangelursachen und die Analyse mögli237

5 Praktische Anwendungen cher Regelmäßigkeiten beim Auftreten der Mängel im Zeitverlauf.

Datenaustausch Manuf acturing Execution System

Extrakte

Warehouse Management System

WARENVERTEILZENTRUM

CONSOLIDATOR

HERSTELLER

Datenaustausch Warehouse Management System

Lokales EPC-IS

EINZELHÄNDLER

Datenaustausch Warehouse Management System

StoreManagement System

Extrakte Extrakte Lokales EPC-IS

Lokales EPC-IS

EPCglobal Network zur Überragung von EPC-Events

Business Intelligence im Warenverteilzentrum

Abb. 5.12: Supply-Chain – Datenaustausch (Siegel 2008, S. 60) •

Eine effizientere Versorgung der Filialen, etwa durch einen vom Warenverteilzentrum koordinierten Bestandsausgleich zwischen den Filialen unter Einbezug verfügbarer Regalflächenkapazitäten. Dies setzt eine hohe Genauigkeit und Aktualität der Daten voraus, die bei Einsatz der heute noch üblichen Barcodes oftmals nicht gegeben ist. Eine im DWH hergestellte Übersicht über Ist-Mengen im Zeitverlauf erlaubt es zudem, die Beschaffungspolitik fortlaufend zu optimieren.

•

Ein selektiver Rückruf von Produkten – basierend auf der betroffenen Chargennummer. Dieser Anwendung wird insgesamt ein besonders großes Potential zugesprochen, sie setzt aber eine sehr weitgehende Datenintegration voraus.

Entwicklung und Betrieb Wie oben angemerkt, befinden sich Lösungen der beschriebenen Art derzeit noch in einem Konzeptionsstadium. RFID wird im Einzelhandel zwar bereits von einigen Unternehmen im Produktivbetrieb genutzt – allerdings bislang nur auf Paletten- und teilweise Verpackungsebene und nicht zur Identifikation einzelner Artikel (was in Abhängigkeit der physischen Eigenschaften der jeweiligen Produkte sowie ihres Wertes auch nicht immer sinnvoll ist). 238

5.8 Operational BI in der Nutzfahrzeugproduktion Während für technische Restriktionen zunehmend Lösungen gefunden werden, sind weiterhin diverse organisatorische Fragen offen, insbesondere zur Verteilung von Kosten und Nutzen unter den Lieferkettenpartnern. Gerade für die Hersteller ist die Einführung der im Handel genutzten RFID-Tags oftmals mit Kosten verbunden, denen zunächst kein sichtbarer Nutzen gegenübersteht. Die anhaltende Investition in die Technologie sowie deren zunehmende Verbreitung auch im Bereich der Produktionssteuerung (vgl. hierzu auch das Beispiel aus Kapitel 5.7) lassen es jedoch wahrscheinlich erscheinen, dass sich Lösungen wie die beschriebene mittelfristig durchsetzen werden.

Abschließende Bemerkungen Eine zunehmend automatisierte Datenerfassung in der physischen Umwelt bringt neue Potentiale und Herausforderungen für die Entscheidungsunterstützung. RFID ist hier nur ein erstes Beispiel. Weitere sind die Einbindung von Maschinendaten in ein DWH über ein MES oder die Nutzung von Sensornetzen. Verteilten, in die physische Umwelt eingebettete IT-Komponenten, die per Funk interagieren („Ubiquitous Computing“), wird eine zentrale Rolle in zukünftigen IT-Infrastrukturen zugesprochen. Wesentliche Potentiale des Ubiquitous Computing bleiben dabei ohne eine Einbettung in einen Business-Intelligence-Ansatz zur entscheidungsorientierten Aufbereitung der Daten ungenutzt.

5.8

Operational BI in der Nutzfahrzeugproduktion Der folgende Fall illustriert den Trend, auch in der operativen Entscheidungsunterstützung in Produktion und Logistik integrierte Entscheidungs- und Managementunterstützungssysteme einzusetzen (vgl. Abb. 5.13).

Manufacturing Execution System

Interessant ist hierbei die enge Verzahnung der Analysesysteme mit der technischen Steuerung. Ausgangspunkt ist eine Klasse von Systemen, der im Bereich der Fertigung zunehmend Aufmerksamkeit gewidmet wird: Die sog. Manufacturing Execution Systems (MES). Ein MES zielt auf eine integrierte operative Produktionssteuerung ab und bietet Schnittstellen zu unterschiedlichsten Produktions-, Förder- und Transporteinrichtungen sowie zu Systemen für die Qualitätssicherung und das Personalmanagement (Kletti 2006, S. 21 ff.).

239

5 Praktische Anwendungen Business Business Intelligence Intelligence (BI) (BI) Informationszugriff

OLAP und Reporting Simulation Analysesysteme Data Mining

Data MartData Mart

Datenbereitstellung

Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Informationsdistribution Informationsmitdistribution unterschiedlichst en Formaten

Core Data MESWarehouse in der Rolle eines ODS

Systemintegration

Informationsgenerierung/ -distribution

BI-Portal BI-Portal

Metadaten

• MES übernimmt Anbindung der Anlagen • MES in der Rolle eines ODS für eine Operational-BILösung • Data Mart für die dauerhafte und historisierte Datenablage • Reporting, individuelle Auswertungen und (modellbasierte) Analysen auf Basis des Data Marts

Content Content & & Document Document Mgmt. Mgmt.

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

Externe Daten

Abb. 5.13: Operational BI in der Produktion eines Nutzfahrzeugherstellers

Unternehmen Das betrachtete Unternehmen kann einen Absatz von durchschnittlich 200.000 LKW pro Jahr vorweisen, die sich auf die beiden Sparten „Kleinlaster und leichte LKW“ sowie „mittelschwere und schwere LKW“ verteilen. Die LKW werden an drei Fertigungsstandorten montiert, wobei alle Motoren von einem zentralen Motorenwerk geliefert werden. Für die Produktion der zukünftigen Produktlinien wurde in einem mehrjährigen Projekt eine neue Motorenfabrik gebaut, die sich durch eine hohe Flexibilität und einen intensiven IT-Einsatz auszeichnet. Insgesamt werden hier jetzt in 2 Fertigungslinien 7 Motorentypen gefertigt, von denen wiederum jeweils im Schnitt 6 Varianten hergestellt werden. Fertigungsstationen und Transportsysteme sind hochgradig automatisiert und lassen sich schnell rekonfigurieren (Werkzeugwahl, Materialfluss etc.). Der Materialnachschub an der Fertigungsstraße erfolgt nach dem „Pull-Prinzip“, also nachfragegesteuert: Bei Bedarf werden Teile in einem vorgeschalteten Lager („Supermarkt“) angefordert. Die Regalpositionen der jeweils benötigten Teile im Supermarkt werden auf optischen Displays angezeigt (pick by light); die Zuordnung zu Transportbehältern erfolgt mit zweidimensionalen Barcodes. Jeder Transportbehälter ist mit einem RFID-Tag ausgestattet, das ein funkbasiertes Auslesen von Informationen zu den Teilen und zum Verwendungsort erlaubt. Der Transport zum Zielort erfolgt mit fahrerlosen Transportsystemen (FTS).

240

5.8 Operational BI in der Nutzfahrzeugproduktion Das MES hat drei Funktionen: •

Es steuert das Produktions- und Transportsystem der Fabrik. Dies betrifft die Zugangskontrolle und die Personalzeiterfassung ebenso wie die Bedarfserfassung, die Ansteuerung der Pick-by-light-Anzeigen, die Programmierung der RFID-Tags, die Steuerung der FTS und die Übertragung von Maschinenprogrammen.

•

Es dient der Datenerfassung und Integration und liefert so die Datenbasis für die Entscheidungslogik in der Fabriksteuerung.

•

Es erstellt für den operativen Fertigungsbereich („shop floor“) einfache Dashboards zur Visualisierung der aktuellen Prozessstati, die im Werk über diverse Monitore ausgegeben werden.

Funktionen des MES

Motivation und Zielsetzung Das MES ist im Fall die Grundlage für eine integrierte Steuerung, Planung und Kontrolle der operativen Transport- und Fertigungsprozesse in der Motorenfabrik – eine angesichts der mit der Variantenvielfalt verbundenen Komplexität anspruchsvolle Aufgabe. Auf Basis der im MES gesammelten Ist-Daten erfolgt dabei nicht nur eine Real-time-Steuerung des Produktionsbetriebs sondern auch eine kontinuierliche Analyse mit dem Ziel einer Aufdeckung von Optimierungspotentialen. Gleichzeitig erlaubt das MES eine schnelle Umsetzung von Rekonfigurationsmaßnahmen, etwa durch Veränderungen der Transportwege, der Taktung oder der Rüstvorgänge.

Lösungskonzept

Das MES in der Funktion eines ODS

Zur Realisierung der beschriebenen Ziele wurde das MES um eine Data-Mart-Schicht ergänzt. In dieser Lösung fungiert das MES einerseits als bidirektionale Schnittstelle zwischen den Produktions- und Transportsystemen und dem Data Mart. Es übernimmt andererseits auch die Aufgaben einer Filterung und Harmonisierung der Daten – was Grundlage für die vom Nutzfahrzeughersteller implementierten Steuerungsroutinen ist. Beispiele sind automatisierte Reaktionen auf Blockaden der FTS oder Maschinenstörungen, wobei bei anhaltenden Problemen automatisch eine stufenweise Eskalation zu höheren Hierarchieebenen erfolgt. Die im MES vorgehaltenen Daten sind nicht historisiert und beinhalten keine Aggregationsmöglichkeiten. Letztendlich über241

5 Praktische Anwendungen nimmt das MES im Fall damit die Funktion eines ODS und dient der Umsetzung einer Operational-BI-Lösung für die Produktionssteuerung (vgl. Kapitel 2.3.3).

Reporting für das Produktionsmanagement und OEE

Ad-hoc-Analysen

Im Data Mart erfolgt dann eine dauerhafte, historisierte und relational-multidimensionale Datenablage. Dies ist die Grundlage für die Generierung von Tages-, Wochen und- Monatsberichten für Meister, Schichtleiter und Werksleiter. Teilweise werden diese Berichte auch an höhere Managementebenen weitergeleitet. Wichtigste Kennzahl in der Berichtserstellung ist die Operational Equipment Effectiveness (OEE, Gesamtanlageneffektivität), in die drei Faktoren einfließen: Die Verfügbarkeit der Anlagen, deren Leistung (gemessen an der Abweichung der tatsächlichen von der geplanten Stückzeit) sowie die Qualität, die von Ausschussund Nachbearbeitungsmengen determiniert wird. Neben den Berichten werden Ad-hoc-Analysen auf den aggregierten Daten durchgeführt, die hauptsächlich Störungen, Fehlteile, Durchlaufzeiten, Teilebedarf und Teileverwendung betreffen. Teilweise werden auch anspruchsvollere modellbasierte Auswertungen durchgeführt, deren Ergebnisse bei Bedarf wieder an das MES zurückgespielt werden, etwa zur Rekonfiguration des Werkzeugwechsels.

Entwicklung und Betrieb Das System wurde als integraler Bestandteil der Fabrik geplant und wird in Kooperation von Werks-IT und zentraler IT gepflegt und weiterentwickelt. Als nächste Schritte sind die Ausstattung weiterer Werke mit vergleichbaren Lösungen vorgesehen (Lackiererei, Endmontage etc.) – sowie langfristig deren Verknüpfung: Eine aktuelle Einschränkung des Systems ist deren Beschränkung auf eine Fabrik. So kann die weitere Verwendung der Motoren nicht mehr in den Daten verfolgt werden – was eine Analyse der Konsequenzen von Entscheidungen im Motorenwerk Grenzen setzt. Notwendigkeit einer weitergehenden Integration

242

Des Weiteren werden derzeit in der Lösung keine betriebswirtschaftlichen Größen vorgehalten und es findet überdies keine Abstimmung mit übergeordneten Planungsebenen statt. Hierfür wird ein separates ERP-System mit einer Komponente für die Produktionsplanung und -steuerung (PPS) eingesetzt, in der die mittel- und langfristige Planung durchgeführt wird.

5.9 Template-basierte BI-Koordination im Konzernverbund

Abschließende Bemerkungen Die Kombination aus hochflexiblen Transport- und Produktionsanlagen, MES und Data Mart ermöglicht im Fall laufende Verbesserungen in der Motorenproduktion. Dies hat sich schon aufgrund der Variantenvielfalt als erforderlich erwiesen – die Komplexität lässt sich nur mit anspruchsvollen und flexiblen Steuerungs- und Analysetools beherrschen. Obwohl die beschriebene Lösung als Pioniersystem einzuordnen ist, sind die Integrationspotentiale auch im gegebenen Fall bei weitem noch nicht ausgeschöpft. So sind keine Möglichkeiten vorhanden, um etwa die Konsequenzen eines Wechsels der Lagerhaltungs- und Werkzeugwechselstrategie über die weiteren Produktionsstufen hinweg zu analysieren oder diese mit Kosteninformationen zu verknüpfen. Grundsätzlich ist das mögliche Zusammenwachsen einer ingenieursorientierten mit einer betriebswirtschaftlichen Entscheidungsunterstützung ein bislang nur unzureichend erschlossenes Feld der BI (Baars/Lasi 2010).

Template-basierte BI-Koordination im Konzernverbund Das im Folgenden ausgeführte Konzept zeigt Lösungsansätze für die technische und organisatorische BI-Koordination in einem größeren Unternehmen mit einer komplexen Matrixorganisation. Hervorzuheben ist dabei der Einsatz von Templates als Anwendungsvorlagen mit vorgegebenen Parametrisierungsoptionen. Die Templates erlauben es dem zentralen BI Competence Center (BICC), für die dezentralen BI-Einheiten definierte Gestaltungsspielräume zu öffnen und gleichzeitig das Risiko inkompatibler Lösungen einzudämmen. Die Architektur zeigt Abb. 5.14. Business Intelligence (BI) Informationszugriff

Informationsgenerierung/ -distribution

BI-Portal

Informationsdistribution

Analysesysteme

Data Mart

Datenbereitstellung

Content & Document Mgmt.

Core Data Warehouse Operational Data Store

Externe und operative Systeme mit strukturierten und unstrukturierten Daten

Systemintegration

• Dezentrale DWHs jeweils mit abgestimmten DataMarts • Vorgegebener Bebauungsplan für Anwendungen und Komponenten • Richtlinien etwa für technische Namen, Schnittstellen, Metadatenhaltung • Einsatz von Templates mit definierten Freiheitsgraden

Metadaten

5.9

SCM

E-Proc.

ERP

CRM

…

CAx

PPS

MES

PDM/PLM

…

Externe Daten

Abb. 5.14: Template-basierte Koordination von Landesgesellschaften bei einem Maschinen- und Anlagenbauer 243

5 Praktische Anwendungen

Unternehmen

Komplexe Tensororganisation

Der Konzern ist in drei Sparten aktiv (Maschinen zur Metallbearbeitung, Spritzgießmaschinen, Anlagen) und produziert an weltweit ca. 100 Standorten in 25 Ländern. Trotz der Heterogenität in der Produktpalette und der heterogenen Rahmenbedingungen bei den jeweiligen Landesgesellschaften wird für übergreifende Querschnittsfunktionen (u. a. Einkauf, Personalwesen, IT) eine enge Koordination sichergestellt. Hierbei interagieren zentrale Einheiten mit jeweils lokalen Produkt- und Landeseinheiten. Es liegt somit eine sog. Tensororganisation vor, bei der die Organisation anhand von drei Dimensionen (Produkt, Land, Funktion) strukturiert wird. Dieser Aufbau spiegelt sich auch in der BI-Organisation wider: Die in der IT aufgehängte BI wird über ein zentrales BICC gesteuert, das Richtlinien und Vorgaben definiert, die HardwareInfrastruktur für die DWHs bereithält (Hosting), zentrale Aufgaben bei Beschaffung und Systembetrieb übernimmt sowie für unternehmensweite Anwendungen verantwortlich ist. In den Regionalgesellschaften werden hingegen lokale Lösungen entwickelt, die weiter anhand der Produktsparten und z. T. auch der betrieblichen Funktionen differenziert sind.

Motivation und Zielsetzung Für den beschriebenen Konzern wurde ein Systemkonzept erforderlich, das scheinbar widersprüchlichen Anforderungen gerecht werden muss: Gestaltungsfreiräume bei den Regionalgesellschaften zur schnellen Anpassung an lokale Gegebenheiten, eine hohe Professionalisierung der Systementwicklung und des Systembetriebs sowie eine übergreifende Kompatibilität der Systeme im Konzern für sparten- oder unternehmensweite Anwendungen (u. a. konzeptorientierte Systeme für das wertorientierte Management mit abgestimmten Kennzahlenhierarchien bzw. „Werttreiberbäumen“, vgl. hierzu Kapitel 3.1.8). Schnell zeigte sich, dass weder eine Lösung mit einem unternehmensweiten DWH in Betracht kam noch ein dezentralunkoordinierter Ansatz. Es wurde ein Mittelweg zwischen Zentralisierung und Dezentralisierung gesucht, der in Form eines Template-basierten Ansatzes auch gefunden wurde.

Lösungskonzept Bebauungsplan

244

Fundament der Lösung im Konzern ist ein zentral koordinierter „Bebauungsplan“ zur Überwachung des BI-Anwendungs-

5.9 Template-basierte BI-Koordination im Konzernverbund portfolios. Dieser ist anhand der Unternehmens- und ITOrganisation strukturiert und definiert, welche Anwendungen und Anwendungskomponenten für die einzelnen Bereiche in Betrieb sind oder geplant werden. Gleichzeitig ordnet der Bebauungsplan die Verantwortlichkeiten zu. Beispielsweise liegen unternehmensweite Lösungen vollständig in der Hoheit des zentralen BICC, während eine Anwendung für die französische Niederlassung von der Regionalgesellschaft EMEA („Europe/MiddleEast/Africa) verantwortet wird. Bei funktions- oder spartenweiten Lösungen wiederum muss eine Abstimmung der betroffenen Einheiten in den Landesniederlassungen sichergestellt werden; die Applikation selbst wird dann auf Basis des DWH einer der Landesgesellschaften betrieben. Eine vereinfachte Bebauungsskizze wird in Abb. 5.15 visualisiert. Zentrale mit BICC Zentrales DHW

Anwendung Anwendung

…

Sparte 1

Sparte 2

Sparte 3

Anwendung

Anwendung

Anwendung

Regionalgesellschaft DHW R1

Regionalgesellschaft 2

Anwendung Anwendung

Anwendung

DHW R2

Anwendung Anwendung

Anwendung Anwendung

Anwendung Anwendung

Anwendung

Anwendung

… Regionalgesellschaft n

Anwendung:

Anwendung

Anwendung

Anwendung

Anwendung:

DHW Rn Anwendung

Anwendung Anwendung

Abb. 5.15: Nach Sparten und Regionen differenzierter Bebauungsplan

Vorgabe einer End-to-EndProduktsuite

Sowohl für die Zentrale als auch für die Niederlassungen wurden unabhängige DWHs aufgesetzt, die jedoch alle auf derselben, vorgegebenen End-to-End-Produktsuite basieren (inkl. DWH mit relational-multidimensionaler Datenhaltung, R-OLAP- und DataMining-Werkzeugen sowie einer Portalkomponente). Durch die Vorgabe der Werkzeuge wurde auf der Softwareseite die Kompatibilität sichergestellt und gegenüber dem Werkzeuganbieter eine bessere Verhandlungsposition erreicht. Darüber hinaus müssen sich alle Landesniederlassungen an einen Katalog von Richtlinien 245

5 Praktische Anwendungen für das Stammdatenmanagement, die Wahl von technischen Bezeichnungen, für die Metadatenhaltung und für die Kennzahlendefinition halten. Jedes DWH basiert auf untereinander abgestimmten Data Marts. Das DWH der Zentrale hat derzeit ein Volumen von ca. 8 Terabyte.

Templates als Koordinationsinstrument

Das BICC entwickelt, testet und wartet alle eingesetzten Grundkomponenten. Hierzu zählen insbesondere vorbereitete Anwendungs-Templates, die auf ein produktspezifisches Konzept des DWH-Werkzeuganbieters aufsetzen (vgl. hierzu auch die Kapitel 3.2.3 und 4.3.4). Das BICC kann in einem Template definieren, an welchen Stellen und bei welchen Komponenten welche Anpassungen vorgenommen werden dürfen. Dies bezieht sich beispielsweise auf den Datenimport, die Datenstrukturen (Stammdaten, Star-Schemata, Attributierung), die Vergabe von Zugriffsrechten, die Kennzahlendefinition, die Analysefunktionalität oder das Layout von Berichten. Die in den Templates vorgesehenen Freiheitsgrade variieren dabei stark: Im externen Reporting sind diese naturgemäß geringer als bei einer Lösung zur Überwachung von Produktions- und Wartungsprozessen. Durch eine Kombination fertiger Bausteine, angepasster Templates und selbstentwickelter Komponenten können individuelle Lösungen entwickelt werden. Gleichzeitig setzt die Forcierung von Wiederverwendung und Professionalisierung Kapazitäten frei, um in den Regionalgesellschaften auch anspruchsvolle Anwendungen etwa im Bereich Data-Mining und Simulation umzusetzen.

Entwicklung und Betrieb

Standardisierte Entwicklungsund Betriebsservices

Das Unternehmen verfolgt das Ziel, einen hohen „Reifegrad“ bei der Entwicklung und dem Betrieb von BI-Lösungen zu erreichen. Im BICC wird deshalb ein großer Aufwand bei der Definition von Entwicklungs- und Betriebsservices betrieben. Auch bei der Prozessdefinition können zentrale Vorgaben in definierter Weise lokal angepasst werden, um so den jeweiligen Rahmenbedingungen besser gerecht zu werden. Auf der Makro-Ebene ist der Bebauungsplan die übergeordnete Richtschnur, für die Mikroebene gibt es definierte Vorgehensmodelle, die vor allem in der Template-Entwicklung strikt eingehalten werden. Hierbei wurden u. a. mehrstufige Freigabeprozesse entwickelt, die eine systematische Qualitätssicherung sowie eine koordinierte Übertragung der Templates auf die Ziel-DWHs sicherstellen. Für den Betrieb wurden v. a. Service- und Support-

246

5.9 Template-basierte BI-Koordination im Konzernverbund Prozesse definiert. Einige davon werden mittlerweile auch durch spezielle IT-Werkzeuge unterstützt. Einen wesentlichen Beitrag zur Koordination der diversen Entwicklungen leistet der Template-Einsatz, da so die Durchsetzung bestimmter Standards technisch erzwungen wird. Da die Templates für die Regionalgesellschaften eine erhebliche Entlastung darstellen, werden diese auch ohne Widerstände angenommen.

Abschließende Bemerkungen Das Beispiel illustriert v. a. das Potential einer systematischen Nutzung von Templates. Die Entwicklung eines Templates geht einerseits deutlich über das Bereitstellen von Werkzeugen hinaus, determiniert aber andererseits nicht zwingend alle Inhalte. Templates sind ein wirksames Koordinationsinstrument, mit dem sichergestellt werden kann, dass Datenmodelle, Schnittstellen, Metadaten und Architekturen auch in dezentralen DWHUmgebungen kompatibel bleiben.

247

6

Ausblick Das sechste Kapitel gibt einen Überblick über Trends sowie aktuell diskutierte Weiterentwicklungen in der integrierten Entscheidungs- und Managementunterstützung. Hierfür wird eine von den Verfassern als wichtig erachtete – also subjektive – Auswahl getroffen und auf Themen eingegangen, deren Tragweite und Relevanz derzeit noch nicht abschließend prognostiziert werden kann. Der Bereich wird anhand von drei Unterkapiteln strukturiert: Entwicklungen im Bereich der Hard- und SoftwareInfrastruktur, Entwicklungen bei der Organisation des BIBereiches sowie Trends beim Ausbau von BI-Anwendungsdomänen. Das Kapitel endet mit einer Schlussbetrachtung zu Stand und Entwicklungen der Business Intelligence.

6.1

Entwicklungen im Bereich der Hard- und SoftwareInfrastruktur Dieses Buch fokussiert bewusst eine fachkonzeptionelle Perspektive, d. h. implementierungs- und werkzeugspezifische Hardund Softwareaspekte wurden weitgehend ausgeklammert (beispielsweise Schnittstellentechnologien, physisches Datenbankdesign, Speichernetzwerke, Alternativen zur Realisierung von MOLAP-Datenbanken usw.). Dennoch gibt es Entwicklungen auf diesen Ebenen, die den BI-Bereich gravierend verändern und mittelfristig auch Einfluss auf die Lösungskonzeption nehmen können. Einige davon werden in diesem Abschnitt weiter beleuchtet.

BI Appliances Ein bereits seit einiger Zeit zu beobachtender Trend ist das Aufkommen dedizierter Hardware-Lösungen, die entweder bestehende Software-Werkzeuge ersetzen oder mit solchen verschmolzen werden. Der hierfür genutzte Begriff Appliance kennzeichnet diese funktionsspezifische Hardware. Erhältlich sind insbesondere sog. DWH Appliances (Hinshaw 2004; McKnight 2005).

249

6 Ausblick

Grenzen und Potentiale von Appliances

Weitere Entwicklung bei den Appliances

De facto bleiben selbstverständlich auch beim Einsatz einer Appliance alle fachlichen Herausforderungen beim Aufbau einer DWH-Lösung bestehen. Diese betreffen die Definition individueller Datentransformationsroutinen, die fachlich-konzeptionelle Datenmodellierung sowie die Umsetzung individueller Berichtsund Analyselösungen. Aufwand entfällt primär auf Seiten der Installation und dem Performance-Tuning, z. B. bei der Anpassung der Datenmodelle an die Hardware, der Schnittstellenoptimierung, der Anbindung geeigneter Speicherhardware usw. (vgl. hierzu Brinkmann et al. 2005). Infolgedessen finden sich Beispiele für erfolgreiche Appliance-Einsätze auch überall dort, wo derartige Aktivitäten besonders ins Gewicht fallen, d. h. bei hohen Anforderungen bzgl. der Zugriffsgeschwindigkeit, der Handhabung großer Datenvolumina, der Zugriffszahlen oder der Rechnerleistung. Ob sich Appliances in der Zukunft weiter verbreiten werden, ist offen. Zwar ist zu erwarten, dass Anwender vermehrt anspruchsvolle Auswertungen einfordern werden, etwa zur Mustererkennung in multimedialen Inhalten. Da gleichzeitig aber auch universell verwendbare Hard- und Softwarewerkzeuge kontinuierlich benutzerfreundlicher und leistungsfähiger werden und Rechnerleistung vermehrt als extern angebotener Service eingebunden wird, ist es nicht unrealistisch, dass leistungsfähige Appliances in einer Nischenposition verbleiben werden.

Virtualisierung und verteilte BI Software Services

Virtuelle Maschinen

250

Weitere Trends, die einer starken Hardware/Software-Kopplung entgegenstehen, sind das Aufkommen von „Virtualisierungstechnologien“ sowie von webbasierten Schnittstellen für die standortunabhängige Integration von Softwarewerkzeugen. Bei der Virtualisierung erfolgt eine Abstraktion von der konkreten Rechnerhardware über eine sog. „Virtuelle Maschine“. Eine solche Software wird auf einem Rechner (oder einem Rechnerverbund) installiert, wobei der Virtuellen Maschine definierte Ressourcen zugewiesen werden. Als ergänzende Zwischenschicht kostet eine Virtuelle Maschine zwar Leistung, erlaubt dabei aber eine erhebliche Flexibilität, etwa um BI-Komponenten zwischen unterschiedlichen Maschinen zu portieren oder um diese gänzlich außer Haus zu geben – beispielsweise zu einem Anbieter mit besonders leistungsstarker Hardware.

6.1 Entwicklungen im Bereich der Hard- und Software-Infrastruktur

Rich-InternetApplications als Treiber für eine Verteilung von BI-Lösungen

Software-as-aService

Web Services

REST und Mashups

Weiterhin wird die Verteilung und Verlagerung von BI-Lösungen oder auch einzelner Komponenten durch Entwicklungen im Bereich der Web-Technologien begünstigt. So erweitern Werkzeughersteller ihre Produkte zunehmend um leistungsfähige Webfunktionalitäten, die sich in ihrem „Look and Feel“ als RichInternet-Applications (insbesondere unter Zuhilfenahme von Ajax) kaum mehr von dedizierten Client-Programmen unterscheiden. Bei OLAP-Werkzeugen ist diese Entwicklung bereits weit fortgeschritten (vgl. Kapitel 3.1.5). Mit diesen Technologien und den zunehmenden Bandbreiten fallen somit ehemals vorhandene Hürden für die Nutzung von Internetlösungen, die selbstverständlich auch mobil mit Smartphones genutzt werden können und den Weg zur „Mobilen BI“ ebnen (Bensberg 2008). Webtechnologien öffnen weiterhin die Tür für sog. „Software-asa-Service“-(SaaS-)Anbieter, die den Zugang zu Anwendungen per Web anbieten (Benlian et al. 2009). Derartige Dienstleistungen könnten sich zu attraktiven Alternativen zu eigenbetriebenen Lösungen entwickeln (Thomson 2009). Hierbei ist allerdings im Vorfeld exakt die applikationsspezifische Eignung zur Auslagerung zu analysieren. So kommen datenintensive und zeitkritische Anwendungen – etwa im Bereich der (Real-time-)Extraktion unternehmensintern vorgehaltener operativer Datenquellen – wohl auf absehbare Zeit nicht für SaaS-Modelle in Frage. Bei dem Betrieb von Portalen oder Content Management Systemen, bei einzelnen Analysediensten sowie in der Stammdatenbereinigung sind jedoch große SaaS-Potentiale erkennbar. Eine Auslagerung von Komponenten setzt in jedem Fall voraus, dass der Serviceaufruf und die Servicebereitstellung wirksam in die eigenen Infrastrukturen eingebunden werden können. Diese Integration kann mit Hilfe sog. Service Oriented Architectures (SOA) geleistet werden. Im Internetkontext werden diese v. a. auf Basis sog.Web Services umgesetzt. In diesem Kontext besitzen die Protokolle SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und UDDI (Universal Description, Discovery and Integration) Relevanz, mit deren Hilfe beispielsweise Datenquellen angebunden oder Anreicherungsfunktionen über das Web aufgerufen werden können. Neben diesen Diensten finden zunehmend einfachere Web Services Verwendung in der Praxis, die mit geringem Protokolloverhead auskommen und unter dem Begriff REST (Representational State Transfer) zusammengefasst werden. Häufig beschränkt sich eine REST-Schnittstelle auf den Austausch von 251

6 Ausblick Dateien im XML-Format. Zusammen mit flexibel einbindbaren Komponenten („Widgets“) werden REST-Technologien insbesondere dafür eingesetzt, Web-Angebote flexibel untereinander zu verknüpfen, um so anwendernah angebotsübergreifende Lösungen zu entwickeln – sog. „Mashups“. Hierbei werden Mashups für den BI-Bereich oftmals die Aufgaben eines Portals zugesprochen (Jhingran 2006, S. 3 f.; vgl. auch Kapitel 3.3). Diese Einordnung ist jedoch durchaus kritisch zu beurteilen, da MashupTechnologien für eine Reihe von Aufgaben auf der Zugriffsschicht keine Lösung bieten, wie etwa hinsichtlich der Berechtigungs- und Metadatenstrukturen. Aus diesem Grunde ist davon auszugehen, dass Mashups die etablierten Portale eher ergänzen als diese zu ersetzen.

Trend zu „BI in the Cloud“?

Zusammenfassend lässt sich festhalten, dass aufgrund der neuen Ansätze und Technologien BI-Infrastrukturen in der Zukunft zunehmend verteilt werden können. Selbstverständlich werden auch zukünftig anspruchsvolle BI-Lösungen (Datenmengen, Rechnerleitung, betrieblicher Integrationsgrad usw.) in einigen Fällen das Vorhalten eigener Hardware sowie evtl. auch spezieller Appliances erzwingen. Für eine Vielzahl von BIAnwendungen werden jedoch die Standorte, an denen die Komponenten betrieben werden, mittelfristig kaum noch ins Gewicht fallen. Häufig werden diese Ansätze zurzeit unter dem schillernden Begriff des „Cloud Computing“ diskutiert (Weinhardt et al. 2009), gewissermaßen als „BI in the Cloud“.

Neue Datenquellen und innovative Analysesysteme Innovative Anwendungen in der BI, wie sie beispielhaft im Kapitel 5 vorgestellt wurden, führen häufig zu dem Bedarf, neue Datenquellen und Analysekomponenten in die BI-Architekturen zu integrieren. Es ist davon auszugehen, dass die Bedeutung von Webquellen auch weiterhin zunehmen wird, da im Web vermehrt unternehmensrelevante Informationen angeboten werden, die über die zunehmende Bereitstellung von Metadaten wirksam erschlossen werde können. Derartige Metadaten können zum einen über XML-Formate unmittelbar maschinenverarbeitbar sein (vgl. Kapitel 3.2.3) oder aber zumindest indirekt eine erste Strukturierung unterstützen, etwa über die Bereitstellung von benutzergenerierten Schlagworten („Social Tagging“), Bewertungen oder Verlinkungen.

252

6.1 Entwicklungen im Bereich der Hard- und Software-Infrastruktur Trotz allem ist davon auszugehen, dass die effektive Analyse von Analyse unstrukturierter Daten im Webinhalten auch zukünftig eine große Herausforderung darstellen wird. So gewinnen die komplexen Technologien für das Text Web Mining oder die Ansätze der Social Network Analysis gerade für die Untersuchung von Webdaten einen zunehmenden Stellenwert (vgl. hierzu den Abschnitt zu „Web und Process Mining“ in Kapitel 3.1.6). Parallel werden im Bereich der Bild- und Videoanalyse neue Verfahren erprobt. Ein Beispiel ist die Identifikation von Gesichtern, Objekten, Orten oder ganzen Szenen in Bildern oder Videos – interessante Verfahren gerade auch bei Berücksichtigung der immer stärkeren Verbreitung von Webcams. Für den Bereich Business Intelligence wird es hierbei von großer Relevanz sein, inwieweit die oftmals aufwändigen Analysealgorithmen sinnvoll in bestehende BI-Umgebungen integriert werden können. BI-Potentiale eröffnen sich hierbei im Bereich der Früherkennung von Markttrends, der Analyse von Verhaltensmustern, der Qualitätssicherung in der Produktion usw. Ein weiterer Typus von Datenquellen entsteht aufgrund der Durchdringung der physischen Umwelt mit IT-Komponenten – die oftmals zudem drahtlos vernetzt ist. Diese unter den ÜberBI und Ubiquitous schriften Pervasive Computing und Ubiquitous Computing diskutierten Entwicklungen (Weiser 1996; Lyytinen/Yoo 2002, Computing Fleisch/Dierkes 2003) können zu einer gravierenden Erhöhung der auswertbaren Inhalte führen. Ein erstes Beispiel hierfür ist die in Kapitel 5.7 verfolgte Nutzung von RFID-Daten für die Gewinnung von Supply-Chain-Daten. Hinzu kommen Sensoren bzw. Sensornetzwerke und Daten von (fernwartbaren) „Smart Devices“, also von Geräten, die um IT-Komponenten und Internet-Zugang erweitert sind.

Datenquellen in technischen Bereichen

Schließlich gewinnen – wie das MES-Beispiel aus Kapitel 5.7 zeigt – Schnittstellen zu Systemen aus technischen Domänen an Bedeutung. Hierbei wird es eine große Herausforderung sein, die unterschiedlichen Entwicklungs-, Konstruktions-, Produktions- sowie Qualitätsdaten zu harmonisieren und für den BIKontext aufzubereiten. Eine erfolgreiche Integration würde hierbei erhebliches BI-Potential erschließen, etwa bei der Abstimmung zwischen Vertriebs- und Produktionsbereichen, in der Analyse von Designentscheidungen oder bei der Bewertung von Maßnahmen in der Produktion (Lasi 2009; Baars/Lasi 2010).

Ausbau des Template-Ansatzes Templates als flexibel parametrisierbare Vorlagen für Anwendungskomponenten haben sich bereits für einige Werkzeugan253

6 Ausblick bieter als wirkungsvolles Verkaufsargument bewährt. Sowohl bei der Abgrenzung und Verteilung von BI Services (vgl. Kapitel 4.3.4) als auch bei der Durchsetzung von Standards wie im Anwendungsbeispiel aus Kapitel 5.9 stellen Templates wertvolle Koordinationsinstrumente dar. Eine Herausforderung wird es hierbei sein, die Interoperabilität werkzeugspezifsicher Templates zu erhöhen, um sowohl die Modularisierung der Anwendungen als auch die Kooperation im Rahmen der Entwicklungsprozesse wirksam fördern zu können.

Operational BI und die Entwicklung des DWH zum Transformation-Hub Wie bereits in Kapitel 2.3.3 diskutiert, ist die unter dem Titel „Operational BI“ betriebene Unterstützung operativer Geschäftsprozesse mit Hilfe von BI-Werkzeugen bereits in einzelnen Anwendungsbereichen Realität. Insbesondere das ODS-erweiterte DWH übernimmt hierbei eine neue Rolle. So entwickelte sich dieser Ansatz von einem dedizierten Datenhaltungssystem für die Managementunterstützung hin zu einem umfassenden Integrationswerkzeug für dispositive und operative Systeme. Vom DWH zum „TransformationHub“?

6.2

Das DWH verliert somit zunehmend seine primäre Aufgabe als exklusives Datenhaltungssystem. Vielmehr kommt dem Ansatz zunehmend die Rolle zu, harmonisierte Daten für sämtliche Prozesstypen des Unternehmens zur Verfügung zu stellen. Der erweiterte DWH-Ansatz wandelt sich somit in entsprechenden Umgebungen zunehmend zu einem umfassenden Transformation Hub, der sowohl operativ als auch dispositiv für performante Datentransformationen eingesetzt wird (Kemper/Baars 2009b).

Entwicklungen im Bereich der BI-Organisation Im Bereich der Organisation sind derzeit mehrere voneinander abhängige Entwicklungen zu beobachten: Die weitergehende Professionalisierung der BI-Organisation, das Durchsetzen des Serviceansatzes in der BI sowie das Aufkommen organisationsübergreifender Lösungen.

Professionalisierung der BI-Organisation Wie Kapitel 5.9 unterstreicht, gibt es bereits heute Beispiele für Unternehmen mit stark differenzierter BI-Organisation und expliziter Implementierung leistungsfähiger BI-Governance-Strukturen.

254

6.2 Entwicklungen im Bereich der BI-Organisation Dennoch herrschen in vielen Unternehmen in diesen Bereichen noch erhebliche Unsicherheiten. Herausforderungen liegen hierbei vor allem in der unternehmensspezifischen Gestaltung der Arbeitsteilung zwischen der IT und der Fachseite, der effektiven organisatorischen Einbindung koordinierender BICCs sowie der Sicherstellung der Strategiekonformität der BI-Aktivitäten (Baars et al. 2010). Eine Herausforderung für die nahe Zukunft wird es hierbei sein, den Unternehmen einen Fundus von wirksamen Konzepten und Best-Practice-Sammlungen zur Verfügung zu stellen, um wertvolle Hilfestellungen zur Ausarbeitung des Rollenkonzeptes, bei der Abgrenzung von Services oder der Spezifikation von Richtlinien geben zu können. Das starke Engagement von Beratern und Wissenschaftlern in diesem Bereich lassen jedoch auch erwarten, dass entsprechende Konzepte zunehmend abgesichert, kommuniziert und in die Ausbildung von BI-Professionals integriert werden (Gansor et al. 2010).

Etablierung des Serviceansatzes In Kapitel 4.3.4 wurde ein Serviceansatz vorgestellt, mit dem die Abgrenzung und Verteilung von BI-Aufgaben unterstützt werden kann. Dass entsprechende Ansätze derzeit auf große Resonanz stoßen, überrascht nicht: Services tragen nicht nur zur Professionalisierung bei, indem sie kundenorientierte und messbare Einheiten definieren, sie helfen auch bei der Verteilung der Aufgaben über die diversen beteiligten Organisationseinheiten. Aufgrund ihrer strukturgebenden Natur legen sie überdies das Fundament für die Implementierung einer BI Governance. Im Bereich der BI-Service-Orientierung sind derzeit jedoch noch zwei wesentliche Fragen offen:

Kennzahlenbasierte Steuerung von BI Services

1.

Die Ausarbeitung stringenter Kennzahlensysteme und

2.

die Verknüpfung mit korrespondierenden Konzepten auf der IT-Seite.

Eine kennzahlenbasierte Steuerung ist nicht nur erforderlich für ein zielgerichtetes und werkzeuggestütztes Controlling der BI Services, sondern auch integraler Bestandteil eines GovernanceKonzeptes. Vor dieser Perspektive wird der Strategiebezug der Kennzahlen deutlich. Eine ziellose Messung operativer Prozesskennzahlen (z. B. Bearbeitungszeit für den Change-Request eines Anwenders, Anteil erfolgreicher Beladungsvorgänge, Integrität der Daten usw.) ist ggf. sogar schädlich, da hierdurch Fehlpriorisierungen gefördert werden können. Nur im Kontext 255

6 Ausblick eines qualitativ abgestimmten und strategieorientierten Systems können Kennzahlen Wirkung entfalten. Es bleibt zu verfolgen, welche Entwicklungen hierbei zu verzeichnen sind und welche Tragfähigkeit vorgeschlagene Konzepte wie BI Balanced Scorecards tatsächlich aufweisen.

Services im organisatorischen und im technischen Sinn

Bezüglich der Verknüpfung mit Konzepten auf der IT-Seite springt unmittelbar die Wortwahl Service in „Web Service“ oder „Serviceorientierte Architektur“ ins Auge. In der Tat gibt es hier mehrere Berührungspunkte, die es nahelegen, die technischen und organisatorischen Ansätze aufeinander abzustimmen. So sind viele BI Services im organisatorischen Sinn mit Leistungen verknüpft, die als Services im technischen Sinn umgesetzt werden können (Beispiele: Berechnung einer Kennzahl, Änderung einer Berechtigung, Durchführung einer Analyse, Suchen einer Vorlage im CMS, Anbinden einer Datenquelle).

Organisationsübergreifende Arbeitsteilung Hielten die meisten Anwender ein „BI Outsourcing“ noch Anfang der 2000er Jahre für undenkbar, so finden sich heute bereits erste Beispiele für erfolgreiche Projekte (Detemple et al. 2006). Der Schlüssel zur Realisierung eines solchen Ansatzes ist ein differenziertes Vorgehen, in dem BI nicht als homogener Block, sondern als ein Bündel aufeinander abgestimmter Services verstanden wird (Baars et al. 2007). Das Servicekonzept aus Kapitel 4.3.4 liefert hier Ansatzpunkte: Services auf der Hardware- und Werkzeugebene lassen sich ohne Frage einfacher auslagern als inhaltsbezogene Dienste. Dabei werden die in Kapitel 6.1 vorgestellten Entwicklungen zu maßgeblichen Treibern: Mit Hilfe von Virtualisierung, web-basierten Schnittstellen, Komponentenansätzen und Web Services können Anwendungen nicht nur von den techniknahen Schichten abstrahiert werden, sondern auch zunehmend flexibler verknüpft werden.

Agilität durch BI Outsourcing?

Mittelfristig sind hierdurch neue Lösungen denkbar, die dynamisch via Internet bereitgestellte Quell-, Analyse-, Datenhaltungsund Visualisierungskomponenten zusammenschalten und agil rekonfiguriert werden können, sofern die stabile Bereitstellung dieser Anwendungen vertraglich und technisch abgesichert werden kann. Kritisch ist dabei v. a. die Gewährleistung von Datenintegrität, Verfügbarkeit und Sicherheit zu sehen. Es ist zu betonen, dass es in Einzelfällen sinnvoll sein kann, auch Services auf der Content- und Inhaltsschicht in einem Outsourcing-Ansatz zu berücksichtigen. So gibt es bereits spezialisierte

256

6.3 Ausbau von BI-Anwendungsdomänen Anbieter für die Bereinigung von Kundenstammdaten oder für anspruchsvolle Datenanalysen.

6.3

Ausbau von BI-Anwendungsdomänen Zunächst ist zu betonen, dass die betriebliche Praxis – aller Euphorie für neue Lösungsansätze zum Trotz – voraussichtlich noch in der nahen Zukunft häufig mit BI-Projekten zur Bereitstellung „einfacher“ Reporting- und OLAP-Lösungen beschäftigt sein wird. Gerade im Mittelstand ist bei solchen „Basislösungen“ noch Nachholbedarf vorhanden. Das typische Projekt „Entwicklung eines OLAP-Cubes für das Vertriebsreporting“ wird deshalb auch in Zukunft das BI-Geschäft in weiten Teilen prägen. Gerade deshalb tragen jedoch innovative BI-Anwendungen etwa auf Basis anspruchsvoller Analysen, Planungen, Simulationen, der Einbindung von DSS-Komponenten oder der Anbindung der Prozesssteuerung maßgeblich zur Differenzierung bei und erlangen somit strategische Relevanz. Im Folgenden wird eine Reihe potentieller Entwicklungen vorgestellt.

Benutzerfreundliche Planung, Simulation und Analyse Dem Einsatz algorithmischer Ansätze aus den Bereichen Operations Research steht weiterhin die oftmals hohe Komplexität der Methoden entgegen. Herausforderungen für zukünftige Ansätze sind hierbei, die Werkzeuge in einer Weise in BI-Umgebungen einzubinden, die auch Anwendern ohne umfangreiche mathematische und statistische Vorbildung die Nutzung leistungsfähiger Auswertungen erlauben. Die Lösung dieser Probleme könnte etwa durch leistungsfähige Benutzerschnittstellen, eine stärkere Unterstützung bei der Methodenauswahl sowie eine automatische Prüfung und Absicherung eines sinnvollen Einsatzes von Modellen gefördert werden.

Stärkere Einbindung von Simulationsverfahren

Insbesondere dem Einsatz von Simulationsverfahren kann im Bereich der Managementunterstützung weiteres Potential bescheinigt werden. Mit diesen Methoden wird es verstärkt möglich werden, komplexe Entscheidungssituationen wirksam zu durchdringen, Schlussfolgerungen aus Daten methodisch abzusichern und eine angestrebte Differenzierung der Planungsbezugsgrößen zu ermöglichen (vgl. Kilger 1976, S. 54 ff.; Coenenberg 2003, S. 358 ff.). Die auf diese Weise entwickelten Planungsgrundlagen werden sich erheblich von den auch heute häufig noch üblichen Fortschreibungen von Ist-Werten unterscheiden können, so dass der seit Jahrzehnten bekannten Gefahr des Vergleichs von 257

6 Ausblick „Schlendrian mit Schlendrian“ (Schmalenbach 1934, S. 263) wirkungsvoll begegnet werden kann.

Competitive Intelligence Mit wirksamen Konzepten zur Integration von Internetquellen sowie neuen Analyseverfahren zur Aufbereitung unstrukturierter Daten wird es möglich, BI verstärkt auf die Durchführung von Markt- und Wettbewerbsanalysen – also auf den Bereich der sog. „Competitive Intelligence“ – auszuweiten. Competitive Intelligence (CI) bezeichnet hierbei einen systematischen, der Ethik verpflichteten Ansatz zum Erwerb und zur Analyse von Informationen über Wettbewerber und Markttrends, um die eigenen Unternehmensziele zu erreichen (angelehnt an: Kahaner 1996). Inhaltlich fokussiert CI die Prozesse der wettbewerbsorientierten Informationsbeschaffung und -analyse, wobei der Begriff Competitive Intelligence auch häufig zum Namensgeber für eigens eingerichtete Organisationseinheiten zur Untersuchung der marktbezogenen Wettbewerbsbedingungen verwendet wurde (Ghoshal/Westney 1991, S. 17 f.; Vedder et al. 1999, S. 109 f.; Lux/Peske 2002, S. 24-29). Grundsätzlich lässt sich festhalten, dass in der Diskussion und der Anwendung von CI eine technologisch-infrastrukturelle Unterstützung bislang wenig Raum eingenommen hat. Dies ist auch angesichts der bislang sehr heterogenen und überwiegend externen Informationsquellen für das CI verständlich: U. a. werden hier Produktbroschüren, Messen und Konferenzen, Kunden- und Delphi-Befragungen sowie Patentdatenbanken aufgeführt (Meier 2004, S. 406). CI-Anwendungen

258

Einen Überblick über den im CI thematisierten Anwendungsbereich sowie die Heterogenität der Lösungen gibt Abb. 6.1.

6.3 Ausbau von BI-Anwendungsdomänen Kriterien zur Unterscheidung von CI-Analysen

Ausprägungen

Beispiele

Inhalte

marktorientierte Analysen wettbewerberorientierte Analysen technologieorientierte Analysen umfeldorientierte Analysen

• • • •

unmittelbar obsolet bis von langfristiger Gültigkeit

• Bereitstellung von Aktienkursdaten zu den Hauptwettbewerbern • Analyse demographischer Entwicklungen im Zielgruppensegment

einmalig, wiederholt oder regelmäßig

• Analyse von Handlungsoptionen in einer Krisensituation • Marktanalyse im Rahmen einer Neuproduktentwicklung • Benchmarking mit Wettbewerbern

jährlich bis mehrmals täglich

• Benchmarking auf Basis von Jahresabschlussdaten • Bereitstellung von Daten zur Preispolitik von Wettbewerbern

keine Datenaufbereitung bis komplexe Analysen erforderlich

• Bereitstellung von Daten zu Aktienkursen • Analyse einer großen Zahl an Nachrichtenmeldungen zu Wettbewerbern aus unterschiedlichen Quellen

Marketing, Planung, F&E sowie strategisches Management, taktisches Management und operatives Management

• • • • • •

zeitliche Stabilität und Fristigkeit

Analyserhythmik

Analysefrequenz

Analysetiefe

Zielgruppen

Analyse der Konsequenzen des Aufkommens von Substitutsprodukten Analyse der Produktpolitik eines Wettbewerbers Analyse von Patentdatenbanken zur Identifikation technischer Trends Beobachtung politischer Entwicklungen in einem Zielmarkt

Kundensegmentbezogene Analyse von Marktanteilen Szenariobasierte Analyse des notwendigen Werbemittelbudgets Identifikation potentiell disruptiver Technologien SWOT-Analysen für die Strategieentwicklung* Branchenbezogene Marktanalysen für Produktmanager Identifikation von best practices der Konkurrenz bei bestimmten Logistikaktivitäten

* SWOT-Analyse (Strengths, Weakness, Opportunities, Threats): Analysetechnik zur Unterstützung des strategischen Managements

Abb. 6.1:

Competitive-Intelligence-Anwendungen (Kemper/Baars, 2006, S. 17)

BI im Nachhaltigkeitsmanagement/CSR Corporate Social Responsibility (CSR) – häufig auch synonym als Nachhaltigkeitsmanagement bezeichnet – wird als Konzept verstanden, „… das den Unternehmen als Grundlage dient, auf freiwilliger Basis soziale Belange und Umweltbelange in ihre Unternehmenstätigkeit und in die Wechselbeziehungen mit den Stakeholdern zu integrieren.“ (Kommission der Europäischen Gemeinschaften (Hrsg.) 2001, S. 7). CSR bezieht sich auf die drei Komponenten ökologische, ökonomische und soziale Nachhaltigkeit: 1. Ökologische Nachhaltigkeit Diese CSR-Dimension akzentuiert die Erhaltung von Natur und Umwelt für die nachfolgenden Generationen. Hierbei wird insbesondere den Aspekten Artenvielfalt, Klimaschutz, Bewahrung von Kultur- und Landschafts-

259

6 Ausblick räumen und Erhaltung der natürlichen Umgebung Beachtung geschenkt Komponenten der CSR

2. Ökonomische Nachhaltigkeit Dieser CSR-Bereich fokussiert die wirtschaftlichen Fundamente einer dauerhaften Erhaltung des Wohlstands unter besonderer Berücksichtigung des Schutzes wirtschaftlicher Ressourcen vor Ausbeutung oder Verschwendung. 3. Soziale Nachhaltigkeit Diese CSR-Facette konzentriert sich auf die Schaffung einer zukunftsfähigen, lebenswerten Gesellschaft, die eine menschenwürdige Partizipation aller Stakeholder ermöglicht. In diesen Kontext behandelt werden z. B. Fragen der Generations-, Verteilungs- und Vertretungsgerechtigkeit, des Arbeitschutzes oder der Gleichstellung der Menschen unabhängig von Geschlecht, Glauben, Hautfarbe usw.

Unternehmensspezifischer CSR-Ansatz

Die Integration eines CSR-Ansatzes beinhaltet die Konzeption einer CSR-Strategie und deren organisatorische Implementierung. Hierfür müssen CSR-Ziele definiert, Messkriterien in die Wertschöpfungskette eingebunden sowie umfassende CSRControlling- und CSR-Change-Management-Ansätze organisationsspezifisch verankert werden. Da davon auszugehen ist, dass für die Umsetzung dieser umfassenden CSR-Konzepte sehr leistungsfähige BI-Lösungen erforderlich sind, wird die CSR-Domäne nach Ansicht der Autoren eine der wachstumsstarken BIEinsatzgebiete der nächsten Jahre darstellen.

Verzahnung der BI mit technischen Domänen Technisch-produktorientierte Bereiche, etwa in der Forschung, der Konstruktion, der Arbeitsvorbereitung, der Produktion oder der Logistik sind bislang üblicherweise noch isoliert von der betriebswirtschaftlich ausgerichteten Unternehmens-BI. Die Beispiele aus Kapitel 5.7 und Kapitel 5.8 zeigen jedoch, dass in diesen Bereichen sehr wohl erste Ansätze erarbeitet werden. Eine bessere Ausschöpfung der oftmals umfangreichen technischen Datenquellen sowie eine Integration in die UnternehmensBI bergen jedoch erhebliche Potentiale. Einige Beispiele sollen dies illustrieren (Lasi 2009, S. 244 ff.; Koch/Baars 2009; Baars/Lasi 2010, S. 427 ff.): • Ein weitreichendes Problem in der Produktionslogistik ist der Schwund von Transportbehältern. Mit einer feinmaschigen 260

6.3 Ausbau von BI-Anwendungsdomänen Erfassung sowie einer DWH-basierten historisierten Vorhaltung der Bestandsmengen werden Analysen zu Fehlmengen im Zeitverlauf möglich. Dies unterstützt nicht nur eine effektive Beschaffung neuer Ladungsträger, sondern hilft auch bei der Verortung von Schwundursachen. •

Eine Kombination von Reklamationsdaten aus einem CRMSystem mit Daten zu Konstruktionsmerkmalen und Produktionsverfahren ermöglicht eine zielgerichtete und permanente Verbesserung von Produkten und Produktionsprozessen.

•

Die integrierte Analyse von Vertriebsdaten, Daten zu Entwicklungs- und Produktionsaufwand sowie Konstruktionsdaten kann die Produktgestaltung sowie die Ableitung von Produktstrategien unterstützen.

•

Eine umfassend historisierte Datenbasis auf Basis von MESund ERP-Daten macht es möglich, einzelne Produktionsanlagen oder ganze Produktionsverbünde auf Konfigurationsparameter hin zu untersuchen und unter Berücksichtigung von deren wertmäßigen Konsequenzen zu optimieren. Dies liefert die Grundlage für Entscheidungen etwa beim Makeor-Buy von Teilen oder Baugruppen.

BI-Anwendungen über Unternehmensgrenzen Viele der in Kapitel 6.1 vorgestellten Technologien fördern die Portabilität und Verteilung der Hard- und Softwareinfrastruktur und damit letztlich mittelfristig auch die Ablösung der BIAnwendungen von den physischen Grenzen einer Unternehmung. In diese Richtung zielen darüber hinaus auch die in 6.2 diskutierten Entwicklungen zur Vertiefung des Serviceansatzes in der BI sowie zur unternehmensübergreifenden Arbeitsteilung.

BI in Unternehmensnetzwerken, -verbünden oder -kooperationen

Dies öffnet auch die Tür für BI-Anwendungen, die unternehmensübergreifend Daten zusammenführen und aufbereiten. Ein zukunftsweisendes Beispiel wurde bereits anhand des Krankenkassenverbandes in Kapitel 5.6 vorgestellt; in der Praxis finden sich weitere (z. B. BARC 2007). Ein Einsatz im Umfeld von Unternehmensnetzwerken, -verbünden oder -kooperationen ist besonders vielversprechend, da hier ein übergeordnetes gemeinsames Zielsystem vorhanden ist. Sofern die Verantwortung für die Anwendung an einen im Netzwerk neutralen, vertrauten und etablierten Partner übergeben werden kann, werden die Einstiegshürden für einen unternehmensübergreifenden BI-Ansatz in erheblichem Maße gesenkt.

261

6 Ausblick Es ist somit durchaus vorstellbar, dass es mit webbasierten Integrationstechnologien möglich wird, unternehmensspezifische, unternehmensnetzwerkinterne, branchenbezogene und marktbezogene Daten in einem integrierten System flexibel zusammenzuführen.

6.4

Abschließende Bemerkungen Zurzeit wird nicht selten die provokante These „Business Intelligence der Zukunft wird ein integraler Bestandteil der operativen Systeminfrastruktur werden“ diskutiert. Befürworter dieses Ansatzes argumentieren, dass in der Praxis vermehrt integrierte ERP-Systeme implementiert werden, die sich einer gemeinsamen operativen, harmonisierten Datenhaltung bedienen und zunehmend auch die Historie der Daten vorhalten. Aus diesem Grunde wären dedizierte dispositive Datenhaltungssysteme (also ODS-, DWH-, Data-Mart-Lösungen) in naher Zukunft nicht länger erforderlich. Vielmehr könnten Managementinformationen direkt in den operativen Systemen vorgehalten werden bzw. über Ad-hoc-Transformation (sog. semantische Layer) quasi „on-the-fly“ erzeugt und visualisiert werden. Ohne Frage ist eine solche Diskussion gerechtfertigt und kann sicherlich kreative Diskussionen über sinnvolle Zukunftslösungen im Bereich der IT-basierten Managementunterstützung induzieren. Für die kommenden Jahre ist diese Idee nach Meinung der Verfasser jedoch lediglich als „Vision“ ohne große Umsetzungsreife einzuschätzen. So ist die Realität in der Unternehmenspraxis auch heute noch meist durch historisch gewachsene operative Systemwelten gekennzeichnet, die weder harmonisierte, geschäftsprozessorientierte Daten noch adäquate Historien zur Verfügung stellen. Wachsende Marktdynamik, zunehmende unternehmensübergreifende Kooperationsformen und die gestiegene Komplexität innovativer BI-Lösungen verlangen aus diesem Grunde nach eigenständigen BI-Architekturen, so dass die hier vorgestellten exklusiven dedizierten Ansätze der Transformation, Datenhaltung, Informationsgenerierunung und -distribution auch in Zukunft als tragfähige Konzepte der Entscheidungsunterstützung einzustufen sind.

262

Abkürzungsverzeichnis 1NF .......................................................................................................... Erste Normalform 2NF .......................................................................................................Zweite Normalform 3NF ......................................................................................................... Dritte Normalform Ajax ...................................................................................... Asynchronous Java and XML API .............................................................................. Application Programming Interface APS .......................................................................................... Advanced Planning System ATM .......................................................................................... Automated Teller Machine Atom ........................................................................................... Atom Syndication Format B2B .....................................................................................................Business to Business B2C .................................................................................................. Business to Consumer B2E ...................................................................................................Business to Employee BI ....................................................................................................... Business Intelligence BICC ................................................................ Business Intelligence Competence Center BSC .......................................................................................................Balanced Scorecard CAD .............................................................................................. Computer Aided Design CAE.......................................................................................Computer Aided Engineering CAM..................................................................................Computer Aided Manufacturing CAx .......................................................................................................Computer Aided [x] CDR ........................................................................................................ Call Detail Record C-DWH .............................................................................................Core Data Warehouse CFROI .............................................................................Cash Flow Return on Investment CI .................................................................................................. Competitive Intelligence CMS ...................................................................................... Content Management System CRM ......................................................................... Customer Relationship Management CSF ................................................................................................. Critical Success Factors CSR ....................................................................................Corporate Social Responsibility CSV ............................................................................................. Comma-Separated Values CVA ....................................................................................................... Cash Value Added CWM.............................................................................. Common Warehouse Metamodel DB ............................................................................................................ Deckungsbeitrag 263

Abkürzungsverzeichnis DBMS ............................................................................... Datenbankmanagementsystem DCF ................................................................................................. Discounted Cash Flow DML ...................................................................................... Data Manipulation Language DMS ..................................................................................Document Management System DSS ..............................................................................................Decision Support System DWH .........................................................................................................Data Warehouse EAI ................................................................................ Enterprise Application Integration EBITDA ...................... Earnings before Interest, Taxes, Depreciation, and Amortisation E-Business ............................................................................................ Electronic Business ECA.............................................................................................. Event, Condition, Action EII ................................................................................ Enterprise Information Integration EIP ........................................................................................ Enterprise Information Portal EIS .......................................................................................Executive Information System E-Mail ...........................................................................................................Electronic Mail EMEA..................................................................................... Europe, Middle Eeast, Africa EPC ............................................................................................... Electronic Product Code EPCIS .......................................................................................... EPC Information Services E-Procurement .............................................................................. Electronic Procurement ERM ...........................................................................................Entity-Relationship-Modell ERP ...................................................................................... Enterprise Resource Planning ETL ............................................................................Extraction, Transformation, Loading EUS ............................................................................ Entscheidungsunterstützungssystem ™ ™ EVA ............................................................................................ Economic Value Added

FASMI ........................................... Fast analysis of shared multidimensional information FIS .........................................................................................Führungsinformationssystem FTP ................................................................................................... File Transfer Protocol FTS ........................................................................................ Fahrerloses Transportsystem GuV ....................................................................................Gewinn- und Verlustrechnung HGB ..................................................................................................... Handelsgesetzbuch H-OLAP .......................................................................................................Hybrides OLAP HTML..................................................................................... Hypertext Markup Language IAS .............................................................................. International Accounting Standards IDV ................................................................................... Individuelle Datenverarbeitung 264

Abkürzungsverzeichnis IFRS .............................................................. International Financial Reporting Standards IP .............................................................................................................. Internet Protocol IS ........................................................................ Informationssystem/Information System ISO ........................................................... International Organization for Standardization IT .................................................................................................. Informationstechnologie IWF ..................................................................................... Internationaler Währungsfond KDD .......................................................................... Knowledge Discovery in Databases KEF .............................................................................................. Kritische Erfolgsfaktoren KonTraG ................... Gesetz zur Kontrolle und Transparenz im Unternehmensbereich LDAP ..................................................................... Lightweight Directory Access Protocol MDX .................................................................................... Multidimensional Expressions MES ................................................................................ Manufacturing Execution System MIS ................................................................................ Management Information System MIT ........................................................................ Massachusetts Institute of Technology M-OLAP ..................................................................................... Multidimensionales OLAP MS........................................................................................................................ Microsoft™ MSS ....................................................................................... Management Support System MUS ............................................................................. Managementunterstützungssystem NLP ....................................................................................... Natural Language Processing ODS ................................................................................................ Operational Data Store OEE .........................................................................Operational Equipment Effectiveness OLAP .....................................................................................Online Analytical Processing OLTP ..................................................................................Online Transaction Processing OMG........................................................................................ Object Management Group PDF.......................................................................................... Portable Document Format PDM ......................................................................................... Produktdatenmanagement PLM .............................................................................. Produktlebenszyklusmanagement PMML ......................................................................... Predictive Model Mining Language POS.................................................................................................................. Point of Sale PPS ........................................................................... Produktionsplanung und -steuerung RBAC ........................................................................................ Role-Based Access Control RDL......................................................................................... Report Definition Language REST .................................................................................. Representational State Transfer 265

Abkürzungsverzeichnis RFID .................................................................................. Radio Frequency Identification RFMR ....................................................................... Recency, Frequency, Monetary Ratio RIA...............................................................................................Rich Internet Application R-OLAP...................................................................................................Relationales OLAP RSS............................................................................................. Really Simple Syndication SaaS ................................................................................................... Software as a Service SCM ......................................................................................... Supply Chain Management SOA ..................................................................................... Service Oriented Architecture SOAP ..................................................................................Simple Object Access Protocol SQL ..........................................................................................Structured Query Language SWOT ...................................................... Strengths, Weaknesses, Opportunities, Threats UDDI ................................................... Universal Description, Discovery and Integration UML ........................................................................................ Unified Modeling Language UMTS........................................................ Universal Mobile Telecommunications System US-GAAP ................................. United States Generally Accepted Accounting Principles VBM........................................................................................... Value Based Management WSDL ........................................................................Web Services Description Language WTO ..........................................................................................World Trade Organization WWW ...................................................................................................... World Wide Web XBRL.................................................................. Extensible Business Reporting Language XML ...................................................................................... Extensible Markup Language XPS ................................................................................................................ Expert System XSL ................................................................................... Extensible Stylesheet Language XSLT .....................................................................................................XSL Transformation

266

Abbildungsverzeichnis Abb. 1.1:

Unterschiedliche Facetten von Business Intelligence .................................. 4

Abb. 1.2:

E-Business und Wertschöpfung .................................................................... 7

Abb. 1.3:

Einsatzfeld von BI-Anwendungssystemen ................................................... 9

Abb. 1.4:

BI-Ordnungsrahmen .................................................................................... 11

Abb. 2.1:

Charakteristika operativer und dispositiver Daten..................................... 16

Abb. 2.2:

Historisch gewachsene Datenversorgung managementunterstützender Systeme ......................................................................................................... 17

Abb. 2.3:

Daten-Pool-Ansatz ....................................................................................... 18

Abb. 2.4:

Architekturvarianten von DWH-/Data-Mart-Lösungen .............................. 22

Abb. 2.5:

ODS-erweiterte Data-Warehouse-Architektur ............................................ 25

Abb. 2.6:

Teilprozesse der Transformation ................................................................ 28

Abb. 2.7:

Erste Transformationsschicht – Filterung ................................................... 28

Abb. 2.8:

Mängelklassifikation im Rahmen der Bereinigung .................................... 29

Abb. 2.9:

Zweite Transformationsschicht – Harmonisierung .................................... 32

Abb. 2.10: Zuordnungstabellen zur Eliminierung von Schlüsseldisharmonien ......... 33 Abb. 2.11: Unterschiedliche Kodierung, Synonyme und Homonyme........................ 34 Abb. 2.12: Dritte Transformationsschicht – Aggregation ............................................. 37 Abb. 2.13: Vierte Transformationsschicht – Anreicherung .......................................... 38 Abb. 2.14: Data Marts und Core Data Warehouse ....................................................... 42 Abb. 2.15: Eigenschaftsprofile von operativen, Operational-Data-Store- und DataWarehouse-Systemen ................................................................................... 45 Abb. 2.16: Metadaten der dispositiven Datenbereitstellung ........................................ 48 Abb. 2.17: Zentrales Metadaten-Repository .................................................................. 51 Abb. 2.18: Dezentrale Metadaten-Repositories............................................................. 52 Abb. 2.19: Föderative Metadaten-Repositories ............................................................. 53 Abb. 2.20: Einschränkung der Recherchemöglichkeit durch eine hierarchieorientierte rollenbasierte Zugriffskontrolle ................................ 56 Abb. 2.21: Technische und fachliche Administrationsschnittstellen ........................... 58 Abb. 2.22: Erweiterte ERM-Notation ............................................................................. 59 Abb. 2.23: ERM-Beispiel ................................................................................................ 60

267

Abbildungsverzeichnis Abb. 2.24: Beispiel einer Relation ................................................................................. 61 Abb. 2.25: Umwandlung eines ERMs in ein Relationenmodell................................... 62 Abb. 2.26: Unnormalisierte Tabelle .............................................................................. 64 Abb. 2.27: Voll normalisierte Datenstruktur ................................................................. 65 Abb. 2.28: Parallele Dimensionshierarchien ................................................................. 67 Abb. 2.29: ERM einer Star-Modellierung....................................................................... 68 Abb. 2.30: Beispiel eines Star-Schemas ........................................................................ 68 Abb. 2.31: Update-Verfahren ......................................................................................... 73 Abb. 2.32: Snapshot-Verfahren...................................................................................... 74 Abb. 2.33: Delta-Historisierung mit Schlüsselerweiterung und Current-FlagAttribut .......................................................................................................... 75 Abb. 2.34: Delta-Historisierung mit Gültigkeitsfeldern ................................................ 76 Abb. 2.35: Historisierung unbalancierter Hierarchien ................................................. 77 Abb. 2.36: ERM der bisherigen Lösung ........................................................................ 79 Abb. 2.37: Information Package für die Verkaufsanalyse ........................................... 80 Abb. 2.38: Snowflake-Schema für Verkaufsanalyse und DB-Rechnung ..................... 81 Abb. 3.1:

Traditionelle Abgrenzung der dispositiven Systeme ................................. 87

Abb. 3.2:

Beispiele für BI-Analysesysteme ................................................................. 88

Abb. 3.3:

Analysesysteme für das Management ......................................................... 90

Abb. 3.4:

Latenzzeiten von BI-Systemen .................................................................... 91

Abb. 3.5:

Gegenüberstellung von Implementierungsansätzen und Latenzen .......... 96

Abb. 3.6:

MDX-Abfrage ................................................................................................ 97

Abb. 3.7:

Cube und Dimensionen ............................................................................ 101

Abb. 3.8:

Pivotierung des Cubes ............................................................................... 102

Abb. 3.9:

Roll-up & Drill-down ................................................................................. 103

Abb. 3.10: Beispiel für die Nutzung der Drill-across-Operation ............................... 104 Abb. 3.11: Zuschnitt des Datenraums durch den Slice-Operator ............................. 104 Abb. 3.12: Dice-Operator............................................................................................. 105 Abb. 3.13: Split-Operator ............................................................................................. 106 Abb. 3.14: R-OLAP, M-OLAP und H-OLAP................................................................. 107 Abb. 3.15: OLAP-Funktionalität und Tabellenkalkulation (hier: Jedox Palo™ für MS Excel™) .................................................................................................. 109

268

Abbildungsverzeichnis Abb. 3.16: OLAP-Anwendung in webbasierter Ajax-Oberfläche (hier: Cubeware Cockpit v6pro™) .......................................................................................... 110 Abb. 3.17: Komponenten eines DSS ........................................................................... 111 Abb. 3.18: Traditionelle Datenanalyse und Data-Mining-Konzepte ......................... 114 Abb. 3.19: Problemtypen im Data Mining .................................................................. 115 Abb. 3.20: Integriertes Datenmodell zur Analyse strukturierter und unstrukturierter Inhalte .............................................................................. 120 Abb. 3.21: Schritte zur Aufbereitung unstrukturierter Inhalte für die integrierte Analyse ....................................................................................................... 121 Abb. 3.22: Beispiel für den Einsatz eines Process-Mining-Werkzeugs: Vergleich eines Soll-Prozesses mit dem Ist-Ablauf ................................................... 124 Abb. 3.23: Prozesse des betrieblichen Berichtswesens ............................................. 125 Abb. 3.24: Klassifizierung der Berichtssysteme .......................................................... 126 Abb. 3.25: Berichtsgenerator der Firma IBM™ ............................................................ 127 Abb. 3.26: Generierter Bericht unter Verwendung von Werkzeugen der Firma IBM™ ............................................................................................................ 128 Abb. 3.27: bms:roi – ein EIS/MIS der Bayer MaterialScience AG™............................ 130 Abb. 3.28: Perspektiven der Balanced Scorecard ...................................................... 132 Abb. 3.29: Balanced-Scorecard-Anwendung auf Basis des -Werkzeugs STRAT&GO Business Dashboard™ der Firma PROCOS™ ........................ 133 Abb. 3.30: Berücksichtung der Kapitalkosten ............................................................ 140 Abb. 3.31: Generische und geschäftsspezifische Wertetreiber.................................. 141 Abb. 3.32: Abgrenzung des Wissensbegriffs .............................................................. 143 Abb. 3.33: Mögliche Rollen von Content- und-Document Management-Systemen in einem BI-Ansatz..................................................................................... 146 Abb. 3.34: Gegenstände/Formate der Informationsdistribution................................ 149 Abb. 3.35: Portalklassen............................................................................................... 155 Abb. 3.36: Beispielhafter schematischer Aufbau eines Portals.................................. 158 Abb. 3.37: Integration des Zugriffs auf strukturierte und unstrukturierte Daten ..... 159 Abb. 4.1:

Zusammenhänge des Wertbeitrags durch IT ........................................... 164

Abb. 4.2:

Zusammenspiel der Makro- und Mikro-Ebene ........................................ 166

Abb. 4.3:

Gestaltungsbereiche und Aufgaben der Makro-Ebene ............................ 168

Abb. 4.4:

BI-Wirksamkeit und BI-Wirtschaftlichkeit ................................................ 171

Abb. 4.5:

Kritische Erfolgsfaktoren zur SWOT-Bestimmung ................................... 172

269

Abbildungsverzeichnis Abb. 4.6:

Beispiel aus dem CRM-Umfeld ................................................................. 173

Abb. 4.7:

Schalenmodell ............................................................................................ 177

Abb. 4.8:

Differenzierung von BI Services ............................................................... 179

Abb. 4.9:

Beispiele Service-Spezifikationen ............................................................. 181

Abb. 4.10: BI Services und BI-Lösungen .................................................................... 182 Abb. 4.11: Dispositive Datenarchitektur und dispositives Datenmodell .................. 183 Abb. 4.12: Controlling der Makro-Ebene .................................................................... 187 Abb. 4.13: Governance – organisatorische Implementierung .................................... 190 Abb. 4.14: Alternative Kooperationsvarianten Fachbereich und IT .......................... 194 Abb. 4.15: Beispiel organisatorische Einbindung von BI .......................................... 195 Abb. 4.16: Entwicklungs-, Betriebs- und Reengineering-Modell .............................. 197 Abb. 4.17: Aufwandsdegression bei zunehmendem Reifegrad des BI-Ansatzes ..... 201 Abb. 4.18: Reengineering-Zyklus ................................................................................ 205 Abb. 5.1:

Data-Mart-basierte BI-Anwendung im Vertriebscontrolling .................... 209

Abb. 5.2:

ODS-erweitertes, unternehmensweites BI-System eines Telekommunikationsanbieters .................................................................. 213

Abb. 5.3:

Unbewertete und bewertete Call Detail Records..................................... 215

Abb. 5.4:

Detaillierte Datenhaltung des Operational Data Store ............................ 216

Abb. 5.5:

Aggregationsniveaus der Call Detail Records .......................................... 218

Abb. 5.6:

Customer Relationship Management im Einzelhandel ............................ 220

Abb. 5.7:

Regelkreis des Kampagnenmanagements ................................................ 222

Abb. 5.8:

Auf Real-time Data Warehousing basierendes BI-Anwendungssystem einer Börsenorganisation ........................................................................... 225

Abb. 5.9:

Agil entwickeltes BI-Anwendungssystem im Wertpapierbereich einer Großbank.................................................................................................... 229

Abb. 5.10: Unternehmensübergreifendes DWH in einem Krankenkassenverband. 232 Abb. 5.11: Data-Warehousing in einer RFID-basierten Retail Supply Chain ............ 235 Abb. 5.12: Supply-Chain – Datenaustausch ............................................................... 238 Abb. 5.13: Operational BI in der Produktion eines Nutzfahrzeugherstellers ........... 240 Abb. 5.14: Template-basierte Koordination von Landesgesellschaften bei einem Maschinen- und Anlagenbauer ................................................................. 243 Abb. 5.15: Nach Sparten und Regionen differenzierter Bebauungsplan .................. 245 Abb. 6.1:

270

Competitive-Intelligence-Anwendungen .................................................. 259

Literaturverzeichnis Abel, R., Bass, H. und Ernst-Siebert, R. (Hrsg., 2006), Kleine und mittelgroße Unternehmen im globalen Innovationswettbewerb: Technikgestaltung, Internationalisierungsstrategien, Beschäftigungsschaffung, München und Mering 2006. Akbay, S. (2006), Data Warehousing in Real Time, in: Business Intelligence Journal, Vol. 11, 2006, No. 1, S. 22-28. Albright, S.C., Winston, W.L. und Zappe, C.J. (2006), Data Analysis and Decision Making with Microsoft Excel, 3. Auflage, Belmont 2006. Amberg, M., Remus, U. und Böhn, M. (2003), Geschäftsabwicklung über Unternehmensportale, in: WISU, 32. Jg., 2003, Nr. 11, S. 1394-1399. Anahory, S. und Murray, D. (1997), Data Warehouse: Planung, Implementierung und Administration, Bonn, Reading et al. 1997. Anandarajan, M., Anandarajan, A. und Srinivasan, C.A. (2004), Business Intelligence Techniques, Berlin, Heidelberg et al. 2004. Angeles, R. (2005), RFID-Technologies: Supply-Chain Applications and Implementation Issues, in: Information Systems Management, Vol. 22, 2005, No. 1, S. 51-65. Ariyachandra, T. und Watson, J. (2006), Which Data Warehouse Architecture is the Most Successful, in: Business Intelligence Journal, Vol. 11, 2006, Nr. 1, S. 2-4. Baars, H. (2006), Distribution von Business-Intelligence-Wissen – Diskussion eines Ansatzes zur Nutzung von Wissensmanagement-Systemen für die Verbreitung von Analyseergebnissen und Analysetemplates, in: Chamoni, P. und Gluchowski, P. (Hrsg., 2006), Analytische Informationssysteme – BusinessIntelligence Technologien und Anwendungen, 3. Auflage, Berlin und Heidelberg 2006, S. 409-438. Baars, H. und Kemper, H.G. (2008), Management Support with Structured and Unstructured Data – An Integrated Business Intelligence Framework, in: Information Systems Management, Vol. 25, 2008, No. 2, S. 132-148.

271

Literaturverzeichnis Baars, H. und Lasi, H. (2010), Innovative Business-IntelligenceAnwendungen in Logistik und Produktion, in: Chamoni, P. und Gluchowski, P. (Hrsg., 2010), Analytische Informationssysteme – Business Intelligence-Technologien und -Anwendungen, 4. Auflage, Berlin, Heidelberg et al. 2010, S. 419-438. Baars, H., Horakh, T.A. und Kemper, H.G. (2007), Business Intelligence Outsourcing – A Framework, in: Proceedings of the 15th European Conference on Information Systems (ECIS2007), St. Gallen 2007. Baars, H., Kemper, H.G., Lasi, H. und Siegel, M. (2008), Combining RFID Technology and Business Intelligence for Supply Chain Optimization – Scenarios for Retail Logistics, in: Proceedings of the 41. Hawaii International Conference on System-Sciences (HICSS-41), Washington DC 2008. Baars, H., Müller-Arnold, T. und Kemper, H.G. (2010), Ansätze für eine differenzierte Business Intelligence Governance – Eine Konzeptentwicklung auf Basis einer Exploration, in: Schumann, M., Kolbe, L.M., Breitner, H.M., Frerichs, A. (Hrsg., 2010), Tagungsband der Multikonferenz Wirtschaftsinformatik 2010, Göttingen 2010, S. 1065-1076. Bahrs, J., Vladova, G., Baumgrass, A., Meuthrath, B. und Peters, K. (2009), Anwendungen und Systeme für das Wissensmanagement – ein aktueller Überblick, Berlin 2009. Ballensiefen, K. (2000), Informationsplanung im Rahmen der Konzeption von Executive Information Systems (EIS), Lohmar und Köln 2000. Bange C. (2007), The missing ‘Next Big Things’, auf den Seiten “The BI Verdict” des Business Application Research Center (BARC), publiziert am 08.03.2007, URL: http://www.biverdict.com/fileadmin/FreeAnalyses/Faileddozen.htm, Zugriff am 01.04.2010. Bange, C. (2004), Business Intelligence aus Kennzahlen und Dokumenten, Hamburg 2004. Bange, C. und Schwalm, S. (2005), XML-Einsatz in BusinessIntelligence-Systemen – Eine systematische Übersicht, in: Schelp, J. und Winter, R. (Hrsg., 2005), Auf dem Weg zur Integration Factory – Proceedings der DW2004 — Data Warehousing und EAI, Heidelberg 2005.

272

Literaturverzeichnis Bange, C., Marr, B., Dahnken, O., Narr, J. und Vetter, C. (2004), Software im Vergleich: Balanced Scorecard. 20 Werkzeuge für das Performance Management, München 2004. BARC (2007), Klassenbester – Convenience-Stores mit Business Intelligence. BARC-Guide Business Intelligence 2006/2007, Würzburg 2007, 20-21. Bartel, W., Schwarz, S. und Strasser, G. (2000), Der ETL-Prozess des Data Warehousing, in: Jung, R. und Winter, R. (Hrsg., 2000), Data Warehousing Strategie. Berlin und Heidelberg 2000, S. 43-60. Bauer, A. und Günzel, H. (Hrsg., 2009), Data-WarehouseSysteme: Architektur, Entwicklung, Anwendung, 3. Auflage, Heidelberg 2009. Bea, F.X. und Haas, J. (2005), Strategisches Management, 4. Auflage, Stuttgart 2005. Becker, J., Knackstedt, R. und Serries T. (2002), Informationsportale für das Management: Integration von Data-Warehouseund Content-Management-Systemen, in: von Maur E. und Winter, R. (Hrsg., 2002), Vom Data Warehouse zum Corporate Knowledge Center, Proceedings der Data Warehousing 2002, Heidelberg 2002, S. 241-262. Benlian, A., Hess, T. und Buxmann, P. (2009), Treiber der Adoption SaaS-basierter Anwendungen – Eine empirische Untersuchung auf Basis verschiedener Applikationstypen, in: Wirtschaftsinformatik, 51. Jg., 2009, Nr. 5, S. 414-428. Bensberg, F. (2008), Mobile Business Intelligence – Besonderheiten, Potentiale und prozessorientierte Gestaltung, in: Bauer, H.H., Dirks, T. und Bryant, M.D. (Hrsg., 2008), Erfolgsfaktoren des Mobile Marketing, Heidelberg und Berlin 2008, S. 7287. Bensberg, F. und Schultz, M.B. (2001), Data Mining, in: WISU, 30. Jg., 2001, Nr. 5, S. 679-681. Bernhard, M. und Blomer, R. (Hrsg., 2003), Report Balanced Scorecard in der IT. Praxisbeispiele – Methoden – Umsetzung, 2. Auflage, Düsseldorf 2003. Betge, D. (2006), Koordination in Advanced Planning and Scheduling-Systemen, Wiesbaden 2006. Bissantz, N., Hagedorn, J. und Mertens, P. (2000), Data Mining, in: Mucksch, H. und Behme, W. (Hrsg., 2000), Das Data Warehouse-Konzept, 4. Auflage, Wiesbaden 2000, S. 377-407. 273

Literaturverzeichnis Bose, R. (2009), Advanced analytics: opportunities and challenges, in: Industrial Management and Data Systems, Vol. 109, 2009, No. 2, S. 155-172. Brinkmann, A., Baars, H., Effert, S., Heidebuer, M. und Vodisek, M. (2005), An integrated Architecture for Business Intelligence Support from Application down to Storage, in: Proceedings of the International Workshop on Storage Network Architecture and Parallel I/Os, Saint Louis 2005. Brobst, S. (2002), Enterprise Application Integration and Active Data Warehousing, in: von Maur, E., Winter, R. (Hrsg, 2002), Vom Data Warehouse zum Corporate Knowledge Center, Proceedings der Data Warehousing 2002, Heidelberg 2002, S. 15-22. Brynjolfsson, E. und Hitt, L.M. (2000), Beyond Computation: Information Technology, Organizational Transformation and Business Performance, in: Journal of Economic Perspectives, Vol. 14, 2000, No. 4, S. 23-48. BSCol [Balanced Scorecard Collaborative] (2000), Balanced Scorecard Functional Standards, Release 1.0a, auf den Seiten der Balanced Scorecard Collaborative, publiziert am 05.05.2000, URL: https://www.bscol.com/pdf/Standardsv 10a.pdf, Zugriff am 01.04.2010. Buchmüller, P. (2008), Basel II: Hinwendung zur prinzipienorientierten Bankenaufsicht, Baden-Baden 2008. Cawsey, A. (2003), Künstliche Intelligenz im Klartext, München 2003. Chamoni, P. (2007), XBRL und Business Intelligence – From Business Reporting to Advanced Analytics, in: Debreceny, R., Felden, C., Piechocki, M. (Hrsg., 2007), New Dimensions of Business Reporting with XBRL, Wiesbaden 2007, S. 179-189. Chamoni, P. und Gluchowski, P. (2004), Integrationstrends bei Business-Intelligence-Systemen, in: Wirtschaftsinformatik, 46. Jg., 2004, Nr. 2, S. 119-128. Christmann, A. (1996), Data-Warehouse-Lösung der Stadt Köln, in: Online-Congress Band VIII: Data Warehousing, OLAP, Führungsinformationssysteme – Neue Entwicklungen des Informationsmanagements, Velbert 1996, S. C822.01-C822.12. Codd, E.F., Codd, S.B. und Salley, C.T. (1993a), Beyond Decision Support, in: Computerworld, Vol. 27, 1993, No. 30, S. 87-89.

274

Literaturverzeichnis Codd, E.F., Codd, S.B. und Salley, C.T. (1993b), Providing OLAP to User-Analysts: An IT Mandate, auf den Seiten der Hyperion Solutions Corporation, publiziert 1993, URL: http://dev.hyperion.com/resource_library/white_papers/ providing_olap_to_user_analysts.pdf, Zugriff am 01.08.2006. Cody, W.F., Kreulen, J.T., Krishna, V. und Spangler, W.S. (2002), The integration of business intelligence and knowledge management, in: IBM Systems Journal, Vol. 41, 2002, No. 4, S. 697-713. Coenenberg, A.G. (2003), Kostenrechnung und Kostenanalyse, 5. Auflage, Stuttgart 2003. Copeland, T.E., Koller, T. und Murrin, J. (2002), Unternehmenswert, Frankfurt am Main 2002. Dahnken, O., Keller, P., Narr, J. und Bange, C. (2004), Planung und Budgetierung, 21 Software-Plattformen zum Aufbau unternehmensweiter Planungsapplikationen, München 2004. Dahnken, O., Roosen, C., Bange, C. und Müller, R. (2003), Konsolidierung und Management-Reporting, München 2003. Davydov, M. (2001), Corporate Portals and e-Business Integration, New York 2001. Debreceny, R., Felden, C., Ochocki, B., Piechocki, M. und Piechocki, M. (2009), XBRL for Interactive Data – Engineering the Information Value Chain, Heidelberg und Berlin 2009. Detemple, K., Feidieker, D. und Münch, C. (2006), StatistiX®, die Informationsfabrik der Gruppe Deutsche Börse, in: HMD – Praxis der Wirtschaftsinformatik, 43. Jg., 2006, Nr. 247, S. 8493. DMG (2010), Data Mining Group, auf den Seiten der Data Mining Group, URL: http://www.dmg.org/, Zugriff am 01.04.2010. Do, H. und Rahm, E. (2000), On Metadata Interoperability in Data Warehouses, Report Nr. 01 (2000), Department of Computer Science, University of Leipzig, Leipzig 2000. Domschke, W. und Drexl, A. (2007), Einführung in Operations Research, 7. Auflage, Berlin und Heidelberg 2007. Dudenredaktion (Hrsg., 2006), Der Duden, Bd. 5, Das Fremdwörterbuch, 9. Auflage, Mannheim, Leipzig et al. 2006. Düsing, R. und Heidsieck, C. (2009), Analysephase, in: Bauer, A. und Günzel, H. (Hrsg., 2009), Data-Warehouse-Systeme: Ar-

275

Literaturverzeichnis chitektur, Entwicklung, Anwendung, 3. Auflage, Heidelberg 2004, S. 104-127. Eicker, S. (2001), Ein Überblick über die Umsetzung des DataWarehouse-Konzepts aus technischer Sicht, in: Schütte, R., Rotthowe, T. und Holten, R. (Hrsg., 2001), Data Warehouse Managementhandbuch: Konzepte, Software, Erfahrungen, Berlin, Heidelberg et al. 2001, S. 65-79. Elmasri, R. und Navathe, S.B. (2007), Fundamentals of Database Systems, 5. Auflage, Boston et al. 2007. Englbrecht, A., Hippner, H. und Wilde, K.D. (2004), Marketing Automation – Grundlagen des Kampagnenmanagements, in: Hippner, H. und Wilde, K.D. (Hrsg., 2004), IT-Systeme im CRM, Aufbau und Potenziale, Wiesbaden 2004, S. 333-372. European Commission, The Sectoral e-Business Watch (Hrsg., 2008), The European e-Business Report 2008, The impact of ICT and e-business on firms, sectors and the economy, 6th Synthesis Report of the Sectoral e-Business Watch, auf den Seiten der Sectoral e-Business Watch, publiziert 2008, URL: http://www.ebusiness-watch.org/key_reports/ documents/EBR08.pdf, Brüssel und Bonn 2008, Zugriff am 01.04.2010. Fayyad, U.M., Piatetsky-Shapiro, G. und Smyth, P. (1996), From Data Mining to Knowledge Discovery: An Overview, in: Fayyad, U.M., Piatetsky-Shapiro, G., Smyth, P. und Uthurusamy, R. (Hrsg., 1996), Advances in Knowledge Discovery and Data Mining, Menlo Park 1996, S. 1-34. Felden, C. und Chamoni, P. (2003), Web Farming and Data Warehousing for Energy Tradefloors, in: Proceedings of the IEEE/WIC International Conference on Web Intelligence (WI’03), Los Alamitos et al. 2003, S. 642-645. Finger, R. (2002), Historisierungskonzepte, Vortrag im Rahmen der Seminarreihe „Data Warehouses und Data Marts – Effizienter Einsatz für das Controlling“, Frankfurt am Main 2002. Firestone, J.M. (2003), Enterprise Information Portals and Knowldege Management, Woburn 2003. Fleisch, E. und Dierkes, M. (2003), Ubiquitous Computing aus betriebswirtschaftlicher Sicht, in: Wirtschaftsinformatik, 45. Jg., 2003, Nr. 6, S. 611-620.

276

Literaturverzeichnis Freeman, L.C. (2004), The Development of Social Network Analysis – A Study in the Sociology of Science, Vancouver 2004. Frenkel, J., Baars, H. und Kemper, H.G. (2009), Rahmenbedingungen für Systeme zur integrierten Analyse strukturierter und unstrukturierter Daten – eine fallstudienbasierte Exploration, Arbeitsbericht 01/2009 des Lehrstuhls für ABWL und Wirtschaftsinformatik I der Universität Stuttgart. Gabriel, R. (2008), Expertensystem, in: Kurbel, K., Becker, J., Gronau, N., Sinz, E. und Suhl, L. (Hrsg., 2008), Enzyklopädie der Sirtschaftsinformatik – Online-Lexikon, 3. Auflage, publiziert am 09.09.2008, URL: http://www.oldenbourg.de:8080/wienzyklopaedie/lexikon/technologien-methoden/KI-und-Softcomputing/Expertensystem/, Zugriff am 01.04.2010. Gabriel, R., Chamoni, P. und Gluchowski, P. (2000), Data Warehouse und OLAP – Analyseorientierte Informationssysteme für das Management, in: Zeitschrift für betriebswirtschaftliche Forschung, 52. Jg., 2000, Nr. 2, S. 74-93. Gansor, T., Totok, A. und Stock, S. (2010), Von der Strategie zum Business Intelligence Competency Center (BICC): Konzeption – Betrieb – Praxis, München 2010. Garrett, J.J. (2005), Ajax: A New Approach to Web Applications, auf den Seiten der Adaptive Path LLC (http://www.adaptivepath.com/), publiziert am 18.02.2005, URL: http://www.adaptivepath.com/ideas/essays/archives/ 000385.php, Zugriff am 01.04.2010. Gehra, B. (2005), Früherkennung mit Business-IntelligenceTechnologien: Anwendung und Wirtschaftlichkeit der Nutzung operativer Datenbestände, Wiesbaden 2005. Ghoshal, S. und Westney, D.E.: Organizing Competitor Analysis Systems, in: Strategic Management Journal, Vol. 12, 1991, No. 1, S. 17-31. Gluchowski, P. (1998), Werkzeuge zur Implementierung des betrieblichen Berichtswesens, in: WISU, 27. Jg., 1998, Nr. 10, S. 1174-1188. Gluchowski, P. (2001), Business Intelligence, in: HMD – Praxis der Wirtschaftsinformatik, 38. Jg., 2001, Nr. 222, S. 5-15. Gluchowski, P. und Chamoni, P. (2010), Entwicklungslinien und Architekturkonzepte des On-Line Analytical Processing, in: Chamoni, P. und Gluchowski, P. (Hrsg., 2010), Analytische 277

Literaturverzeichnis Informationssysteme – Business Intelligence-Technologien und -Anwendungen, 4. Auflage, Berlin, Heidelberg et al. 2010, S. 197-228. Gluchowski, P., Gabriel, R. und Dittmar, C. (2008), Management Support Systeme und Business Intelligence: Computergestützte Informationssysteme für Fach- und Führungskräfte, 2. Auflage, Berlin 2008. Gluchowski, P., Kemper, H.G. und Seufert, A. (2009), Innovative Prozess-Steuerung – Was ist neu an Operational BI?, in: BISpektrum, 4. Jg., 2009, Nr. 1, S. 8-12. Gorry, G.A. und Scott Morton, M.S. (1971), A Framework for Management Information Systems, in: Sloan Management Review, Vol. 13, 1971, No. 1, S. 55-70. Götzer, K., Schmale, R., Maier, B. und Komke, T. (2008), Dokumentenmanagement – Informationen im Unternehmen effizient nutzen, 4. Auflage, Heidelberg 2008. Grötzinger, M. und Uepping, H. (Hrsg., 2001), Balanced Scorecard im Human Resources Management: Strategie – Einsatzmöglichkeiten – Praxisbeispiele, Neuwied 2001. Gutenberg, E. (1983), Grundlagen der Betriebswirtschaftslehre, Bd. I: Die Produktion, 24. Auflage, Berlin, Heidelberg et al. 1983. Haak, L. und Hahn, A. (2005), Extraktion von Metadaten als Basis für eine semantische Integration heterogener Informationssysteme, in: Cremers, A.B., Manthey, R., Martini, P. und Steinhag, V. (Hrsg., 2005), Beiträge der 35. Jahrestagung für Informatik e.V. (GI) „Informatik 2005“, Bd. 2, Bonn 2005, S. 104-108. Hackathorn, R. (2002), Current Practices in Active Data Warehousing, auf den Seiten der Bolder Technology Inc., publiziert November 2002, URL: http://www.bolder.com/pubs/ NCR200211-ADW. pdf, Zugriff am 01.04.2010. Hackathorn, R.D. (1998), Web Farming for the Data Warehouse, San Franscisco 1998. Hahn, D. und Hungenberg, H. (2001), PuK: Planung und Kontrolle, Planungs- und Kontrollsysteme, Planungs- und Kontrollrechnung; wertorientierte Controllingkonzepte, 6. Auflage, Wiesbaden 2001. Hahne, M. (1999), Logische Datenmodellierung für das Data Warehouse – Bestandteile und Varianten des Star Schemas, 278

Literaturverzeichnis in: Chamoni, P. und Gluchowski, P. (Hrsg., 1999), Analytische Informationssysteme – Data Warehouse, On-Line Analytical Processing, Data Mining, 2. Auflage, Berlin, Heidelberg et al. 1999, S. 145-170. Hahne, M. (2002), Logische Modellierung mehrdimensionaler Datenbanksysteme, Wiesbaden 2002. Hammergren, T. (1996), Data Warehousing: Building the Corporate Knowledge Base, London 1996. Hammersley, B. (2005), Developing Feeds with Rss and Atom, Sebastopol 2005. Han, J. und Kamber M. (2006), Data Mining – Concepts and Techniques, 2. Auflage, Amsterdam et al. 2006. Hansen, H.R. und Neumann, G. (2009), Wirtschaftsinformatik 1. Grundlagen und Anwendungen, 10. Auflage, Stuttgart 2009. Harold, D., Mannila, H.R. und Means, W.S. (2004), XML in a rd Nutshell, 3 edition, Sebastopol 2004. Heinrich, L. und Stelzer, D. (2009), Informationsmanagement: Grundlagen, Aufgaben, Methoden, 9. Auflage, München und Wien 2009. Herden, O. (2009), Basisdatenbank, in: Bauer, A. und Günzel, H. (Hrsg., 2009), Data-Warehouse-Systeme: Architektur, Entwicklung, Anwendung, 3. Auflage, Heidelberg 2004, S. 53-59. Hernández-Ros, I. und Wallis, H. (2006), XBRL Dimensions 1.0, Recommendation, publiziert am 18.09.2006, URL: http://www.xbrl.org/Specification/XDT-REC-2006-09-18.htm, Zugriff am 01.04.2010. Hettich, S. und Hippner, H. (2001), Assoziationsanalyse, in: Hippner, H., Küsters, U., Meyer, M. und Wilde, K.D. (Hrsg., 2001), Handbuch Data Mining im Marketing, Wiesbaden 2001, S. 459-495. Hettich, S., Hippner H. und Wilde, K.D. (2000), Customer Relationship, in: WISU, 29. Jg., 2000, Nr. 10, S. 1346-1367. Hinshaw, F. (2004), Data Warehouse Appliances – Driving the Business Intelligence Revolution, in: DMReview, September 2004, S. 30-34. Hippner, H. und Rentzmann, R. (2006a), Text Mining, in: informatik spektrum, 29. Jg., 2006, Nr. 4, S. 287-290. Hippner, H. und Rentzmann, R. (2006b), Text Mining zur Anreicherung von Kundenprofilen in der Bankenbranche, in: HMD 279

Literaturverzeichnis – Praxis der Wirtschaftsinformatik, 43. Jg., 2006, Nr. 249, S. 91-98. Hippner, H. und Wilde, K.D. (2001), Der Prozess des Data Mining im Marketing, in: Hippner, H., Küsters U., Meyer M. und Wilde, K.D. (Hrsg., 2001), Handbuch Data Mining im Marketing, Wiesbaden 2001. Hippner, H., Rentzmann, R. und Wilde, K.D. (2006), CRM – Grundlagen, Ziele und Konzepte, in: Hippner, H. und Wilde, K.D. (Hrsg., 2006), Grundlagen des CRM – Konzepte und Gestaltung, 2. Auflage, Wiesbaden 2006, S. 45-74. Horakh, T.A., Baars, H. und Kemper, H.G. (2008), Management von Business Intelligence Services, in: Dinter, B., Winter, R., Chamoni, P., Gronau, N., Turowski, K. (Hrsg., 2008), Synergien durch Integration und Informationslogistik, Proceedings der DW2008, Bonn 2008. Horváth & Partners (Hrsg., 2007), Balanced Scorecard umsetzen, 4. Auflage, Stuttgart 2007. Horváth, P. (2009), Controlling, 11. Auflage, München 2008. Horn, R.E. (1999), Information Design – Emergence of a New Profession, in: Jacobson, R. (Hrsg., 1999), Information Design, Massachusetts 1999. Inmon, W.H. (1999), Building the Operational Data Store, 2. Auflage, New York, Chichester et al. 1999. Inmon, W.H. (2005), Building the Data Warehouse, 4. Auflage, New York, Chichester et al. 2005. Inmon, W.H., Terdeman, R.H. und Imhoff, C. (2000), Exploration Warehouse: Turning Business Information into Business Opportunity, New York, Chichester et al. 2000. ISO [International Organization for Standardization] (2008), ISO/IEC 9075-2:2008, Information technology – Database languages – SQL – Part 2: Foundation (SQL/Foundation), Genf 2008. Java Community Process (2003), JSR 168: Portlet Specification, auf den Seiten des Java Community Process, publiziert Oktober 2003, URL: http://www.jcp.org/en/jsr/detail?id=168, Zugriff am 01.04.2010. Java Community Process (2008), JSR 286: Portlet Specification 2.0, auf den Seiten des Java Community Process, Process,

280

Literaturverzeichnis publiziert März 2008, URL: http://www.jcp.org/en/jsr/detail? id=286, Zugriff am 01.04.2010. Jhingran, A. (2006), Enterprise Information Mashups: Integrating Information, Simply, in: Dayal, U., Whang, K.Y., Lomet, D.B., Alonso, G., Lohman, G.M., Kersten, M.L., Cha, S.K., Kim und Y.K. (Hrsg., 2006), Proceedings of the 32nd International Conference on Very large Data Bases (VLDB 2006), Seoul 2006, S. 3-6. Jürck, C., Förtsch, T.O., Jahn, B.U. und vom Ende, U. (2009), Einsatz von Recommender-Systemen zur personalisierten Informationsverarbeitung im Standardberichtswesen von DataWarehouse-Systemen, in: Hansen, H.R., Karagiannis, D. und Fill, H.G. (Hrsg., 2009), Business Services – Konzepte, Technologien, Anwendungen, 9. Internationale Tagung Wirtschaftsinformatik, Wien 2009, Band 2, S. 349-358. Kahaner, L. (1996) Competitive Intelligence, New York 1996. Kaib, M. (2002), Enterprise Application Integration. Grundlagen, Integrationsprodukte, Anwendungsbeispiele, Wiesbaden 2002. Kaiser, B.U. (2002), Portale – Interaktive Zugangssysteme als Voraussetzung erfolgreicher Managementunterstützung bei Bayer, in: Kemper, H.G. und Mayer, R. (Hrsg., 2002), Business Intelligence in der Praxis, Bonn 2002, S. 121-138. Kaiser, C. (2009), Analyse von Meinungen in sozialen Netzwerken des Web 2.0, in: Hansen, H.R., Karagiannis, D. und Fill, H.G. (Hrsg., 2009), Business Services – Konzepte, Technologien, Anwendungen, 9. Internationale Tagung Wirtschaftsinformatik, Wien 2009, Band 2, S. 379-387. Kaplan, R.S. und Norton, D.P. (1992), The Balanced Scorecard – Measures That Drive Performance, in: Harvard Business Review, 70. Jg., 1992, Nr. 1, S. 71-79. Kaplan, R.S. und Norton, D.P. (1996), Using the Balanced Scorecard as a Strategic Management System, in: Harvard Business Review, 74. Jg., 1996, Nr. 2, S. 75-85. Kaplan, R.S. und Norton, D.P. (2004), Strategy Maps, Stuttgart 2004. Kaplan, R.S. und Norton, D.P. (2001), Die strategiefokussierte Organisation – Führen mit der Balanced Scorecard, Stuttgart 2001. Kemper, H.G. (1999), Architektur und Gestaltung von Management-Unterstützungs-Systemen – Von isolierten Einzelsyste281

Literaturverzeichnis men zum integrierten Gesamtansatz, Stuttgart und Leipzig 1999. Kemper, H.G. (2003), Technologie und Kultur – Neue Akzente im Informationsmanagement, in: Kemper, H.G. und Mülder, W. (Hrsg., 2003), Informationsmanagement – Neue Herausforderungen in Zeiten des E-Business, Lohmar und Köln 2003, S. 225-243. Kemper, H.G. und Baars, H. (2005), Integration von Wissensmanagement- und Business-Intelligence-Systemen, in: Foschiani, S., Habenicht, W. und Wäscher, G. (Hrsg., 2005), Strategisches Wertschöpfungsmanagement in dynamischer Umwelt – Festschrift für Erich Zahn, Frankfurt et al. 2005, S. 117-137. Kemper, H.G. und Baars, H. (2006), Business Intelligence und Competitive Intelligence, in: HMD – Praxis der Wirtschaftsinformatik, 43. Jg., 2006, Nr. 247, S. 7-20. Kemper, H.G. und Baars, H. (2008), Management Support with Structured and Unstructured Data – An Integrated Business Intelligence Framework, in: Information Systems Management, Vol. 25, 2008, No. 2, S. 132-148. Kemper, H.G. und Baars, H. (2009a), Business Intelligence (BI) – Die neue Applikationsvielfalt verlangt nach wirksamen Governance-Strukturen, in: Neudörffer, M. (Hrsg., 2009), ITK Kompendium 2010 – Expertenwissen, Trends und Lösungen in der Informations- und Kommunikationstechnologie, Frankfurt am Main 2009, S. 74-83. Kemper, H.G. und Baars, H. (2009b), From Data Warehouses to Transformation Hubs – A Conceptual Architecture, in: Proceedings of the 17th European Conference on Information Systems (ECIS 2009), Verona 2009. Kemper, H.G. und Finger, R. (2010), Transformation operativer Daten – Konzeptionelle Überlegungen zur Filterung, Harmonisierung, Verdichtung und Anreicherung im Data Warehouse, in: Chamoni, P. und Gluchowski, P. (Hrsg., 2010), Analytische Informationssysteme – Business IntelligenceTechnologien und -Anwendungen, 4. Auflage, Berlin, Heidelberg et al. 2010, S. 157-174. Kemper, H.G. und Lee, P.L. (2002), Business Intelligence (BI) – Innovative Ansätze zur Unterstützung der betrieblichen Entscheidungsfindung, in: Kemper, H.G. und Mayer, R. (Hrsg., 2002), Business Intelligence in der Praxis, Bonn 2002, S. 1129. 282

Literaturverzeichnis Kesten, R., Müller, A. und Schröder, H. (2007), IT-Controlling – Messung und Steuerung des Wertbeitrags der IT, München 2007. Kilger, W. (1976), Einführung in die Kostenrechnung, Opladen 1976. Kimball, R. und Ross, M. (2002), The Data Warehouse Toolkit – The Complete Guide to Dimensional Modeling, 2. Auflage, New York und Weinheim 2002. Klawans, B. (2008), Embedded or Conventional BI: Determining the Right Combination of BI for Your Business, in: Business Intelligence Journal, Vol. 13, 2008, No. 1, S. 30-36. Klesse, M., Melchert, F. und von Maur, E. (2003), Corporate Knowledge Center als Grundlage integrierter Entscheidungsunterstützung, in: Reimer, U., Abecker, A., Staab, S. und Stumme G. (Hrsg., 2003), WM2003: Professionelles Wissensmanagement – Erfahrungen und Visionen, Bonn 2003. Kletti, J. (2006), MES – Manufacturing Execution System: Moderne Informationstechnologie zur Prozessfähigkeit der Wertschöpfung, Berlin 2006. Koch, M. und Baars, H. (2009): Analyzing RFID Data for the Management of Reusable Packaging, in: Proceedings of the 4th Mediterranean Conference on Information Systems (MCIS 09), Athen 2009. Kolb, M. (2008), Personalmanagement: Grundlagen – Konzepte – Praxis, Wiesbaden 2008. Kommission der Europäischen Gemeinschaften (Hrsg., 2001), Grünbuch Europäische Rahmenbedingungen für die soziale Verantwortung der Unternehmen. KOM (2001) 366 endgültig, Brüssel 2001. König, Stephan (2009), Ein Wiki-basiertes Vorgehensmodell für Business Intelligence Projekte, in: Baars, H., Rieger, B. (Hrsg., 2009), Tagungsband des Forschungskolloquiums Business Intelligence (FKBI09), CEUR Workshop Proceedings, Vol. 542, 2009, URL: http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-542/, Zugriff am 01.04.2010. Kranich P. und Schmitz H. (2003), Die Extensible Reporting Language – Standard, Taxonomien und Entwicklungsperspektiven, in: Wirtschaftsinformatik, 45. Jg., 2003, Nr. 1, S. 77-80. Krcmar, H. (2009), Informationsmanagement, 5. Auflage, Berlin und Heidelberg 2009. 283

Literaturverzeichnis Kurz, A. (1999), Data Warehousing Enabling Technology, Bonn 1999. Lai, E. (2008), Teradata creates elite club for petabyte-plus data warehouse customers, auf den Seiten der Computerworld, publiziert am 14.10.2008, URL: http://www.computerworld. com/action/article.do?command=viewArticleBasic&articleId= 9117159, Zugriff am 01.04.2010. Lasi, H. (2009), Aufbau eines IT-basierten Integrationskonzepts zur Unterstützung von Produktentwicklungs- und Produktionsprozessen, Lohmar und Köln 2009. Laudon, K.C. und Laudon, J.P. (2009), Management Information Systems – Managing the Digital Firm, 11. Auflage, New Jersey 2009. Lehner, W. (2003), Datenbanktechnologie für Data-WarehouseSysteme: Konzepte und Methoden, Heidelberg 2003. Leßweng, H.P. (2003), Business Intelligence Tools: Plädoyer für die Integration des Prozesses „Berichtsdiskussion“, in: Uhr, W., Esswein, W. und Schoop, W. (Hrsg., 2003), Wirtschaftsinformatik 2003, Medien – Märkte – Mobilität, Heidelberg 2003, Band II, S. 333-352. Linthicum D. (2001), B2B Application Integration, Boston 2001. Ludwig, E. und Müller, F.F. (2008), Einsatzszenarien von Process Mining in Produktionsprozessen, Bachelor-Arbeit, Universität Stuttgart 2008. Lux, C. und Peske, T. (2002), Competitive Intelligence und Wirtschaftsspionage – Analyse, Praxis, Strategie, Wiesbaden 2002. Lyytinen, K. und Yoo, Y. (2002), Issues and Challenges in Ubiquitous Computing, in: Communications of the ACM, Vol. 45, 2002, No. 12, S. 62-65. Marr, B. und Neely, A. (2003), Automating Your Scorecard: The Balanced Scorecard Software Report, Cranfield 2003. McKnight, W. (2005), Introducing the Data Warehouse Appliance, Part I, in: DMReview, März 2005, S. 16. Meier, M., Sinzig, W. und Mertens, P. (2003), SAP Strategic EnTM terprise Management /Business Analytics – Integration von strategischer und operativer Unternehmensführung, 2. Auflage, Berlin, Heidelberg et al. 2003. Meier, M.C. (2004): Competitive Intelligence, in: Wirtschaftsinformatik 46. Jg., 2004, Nr. 5, S. 405-407. 284

Literaturverzeichnis Mertens, M., Teiken, Y. und Appelrath, J. (2009), Semantische Anreicherung von strukturierten Daten und Prozessen in analytischen Informationssystemen am Beispiel von MUSTANG, in: Baars, H. und Rieger, B. (Hrsg., 2009), Tagungsband des Forschungskolloquiums Business Intelligence (FKBI09), CEUR Workshop Proceedings, Vol. 542, 2009, URL: http://sunsite.informatik.rwth-aachen.de/Publications/CEURWS/Vol-542/, Zugriff am 01.04.2010. Mertens, P. (1999), Integration externer, qualitativer und quantitativer Daten auf dem Weg zum Aktiven MIS, in: Wirtschaftsinformatik, 41. Jg., 1999, Nr. 5, S. 405-415. Mertens, P. (2002), Business Intelligence – ein Überblick, Arbeitspapier an der Universität Erlangen-Nürnberg 2/2002, Nürnberg 2002. Mertens, P. (2005), Integrierte Informationsverarbeitung 1 – Operative Systeme in der Industrie, 15. Auflage, Wiesbaden 2005. Mertens, P. und Meier, M.C. (2009), Integrierte Informationsverarbeitung 2, 10. Auflage, Wiesbaden 2009. Mertens, P., Billmeyer, A. und Bradl, P. (2003a), Informationsverarbeitung in der strategischen Unternehmensplanung, in: WISU, 32. Jg., 2003, Nr. 6, S. 795-803. Mertens, P., Billmeyer, A. und Bradl, P. (2003b), Simulation in der strategischen Unternehmensplanung, in: WISU, 32. Jg., 2003, Nr. 10, S. 1256-1268. Meyr, H., Rosi, H., Seipl, C., Wagner, M. und Wetteraure, U. (2008), Architecture of Selected APS, in: Stadtler, H. und Kilger, C. (Hrsg., 2008), Supply Chain Management and Advanced Planning – Concepts, Models, Software, and Case Studies, 4. Auflage, Berlin und Heidelberg 2008, S. 349-366. Microsoft (Hrsg., 2008), Microsoft Corporation, Report Definition Language Specification, Third Version, auf den Webseiten des Microsoft Developer Networks (msdn.microsoft.com), publicziert im Juli 2008, URL: http://msdn.microsoft.com/enus/library/dd297486.aspx, Zugriff am 01.04.2010. Miliü-Frayling, N. (2005), Text Processing and Information Retrieval, in: Zanasi, E. (Hrsg., 2005), Text Mining and its Applications in Applications to Intelligence, CRM and Knowledge Management, Ashurst 2005, S. 1-45. Mucksch, H. (2006), Das Data Warehouse als Datenbasis analytischer Informationssysteme – Architektur und Komponenten, 285

Literaturverzeichnis in: Chamoni, P. und Gluchowski, P. (Hrsg., 2006), Analytische Informationssysteme – Business Intelligence-Technologien und -Anwendungen, 3. Auflage, Berlin, Heidelberg et al. 2006, S. 129-142. Mucksch, H. und Behme, W. (2000), Das Data WarehouseKonzept als Basis einer unternehmensweiten Informationslogistik, in: Mucksch, H. und Behme, W. (Hrsg., 2000), Das Data Warehouse-Konzept, 4. Auflage, Wiesbaden 2000, S. 3-80. Musiol, G. (1999), Database Marketing: Optimale Zielgruppenbestimmung mit Hilfe statistischer Verfahren, München 1999. Negash, S. (2004), Business Intelligence, in: Communications of AIS, Vol. 13, 2004, S. 177-195. Nutz A. und Strauß, M. (2002), eXtensible Business Reporting Language (XBRL) – Konzept und praktischer Einsatz, in: Wirtschaftsinformatik, 44. Jg., 2002, Nr. 5, S. 447-457. O'Reilly, T. (2005), What Is Web 2.0? – Design Patterns and Business Models for the Next Generation of Software, auf den Webseiten des O’Reilly-Verlages, publiziert am 30.09.2005, URL: http://oreilly.com/web2/archive/what-is-web-20.html, Zugriff am 01.04.2010. Ottmann, T. und Widmayer, P. (2002), Algorithmen und Datenstrukturen, 4. Auflage, Heidelberg und Berlin 2002. Pendse, N. und Creeth, R. (1995), The OLAP Report, o. O. 1995. Pendse, N. und Creeth, R. (2008), What is OLAP? An analysis of what the often misused OLAP term is supposed to mean, auf den Seiten des OLAP Reports, publiziert am 03.03.2008, URL: http://www.olapreport.com/fasmi.htm, Zugriff am 01.04.2010. Porter, M.E. (1986), Competition in Global Industries – A Conceptual Framework, in: Porter, M.E. (Hrsg., 1986), Competition in Global Industries, Boston 1986, S. 15-60. Priebe, T., Pernul, G. und Krause, P. (2003), Ein integrativer Ansatz für unternehmensweite Wissensportale, in: Uhr, W., Esswein, W. und Schoop, W. (Hrsg., 2003), Wirtschaftsinformatik 2003, Medien – Märkte – Mobilität, Heidelberg 2003, Band I, S. 227-292. Probst, G., Raub, S. und Romhardt, K. (2010), Wissen managen, 6. Auflage, Wiesbaden 2010.

286

Literaturverzeichnis Putzke, J., Fischbach, K., Schoder, D. und Oster, D. (2008), Business Intelligence und die Analyse unternehmensinterner Kommunikationsprozesse, in: Bichler, M., Hess, T., Krcmar, H., Lechner, U., Matthes, F., Picot, A., Speitkamp, B. und Wolf, P. (Hrsg., 2008), Tagungsband der Multikonferenz Wirtschaftsinformatik 2008 (MWKI 2008), Berlin 2008. Raden, N. (2003), Exploring the Business Imperative of RealTime Analytics, Teradata Whitepaper, auf den Seiten der Hiredbrains Incorporated, publiziert im Oktober 2003, URL: http://www.hiredbrains.com/teradata.pdf, Zugriff am 01.04.2010. Rappaport, A. (1999), Shareholder Value, 2. Auflage, Stuttgart 1999. Rehäuser, J. und Krcmar, H. (1996), Wissensmanagement im Unternehmen, in: Schreyögg, G. und Conrad, P. (Hrsg., 1996), Managementforschung 6: Wissensmanagement, Berlin und New York 1996, S. 1-40. Reichmann, T. (2006), Controlling mit Kennzahlen und Management-Tools: die systemgestützte Controlling-Konzeption, 7. Auflage, München 2006. Reindl, M. (1991), Re-Engineering des Datenmodells, in: Wirtschaftsinformatik, 33. Jg., 1991, Nr. 4, S. 281-288. Repici (2004), How To: The Comma Separated Value (CSV) File Format, auf den Seiten der Creativyst, Inc., publiziert 2004, URL: http://www.creativyst.com/Doc/Articles/ CSV/CSV01.htm, Zugriff am 01.04.2010. Rhefus, H. (1992), Top Down und/oder Bottom Up – Kritische Erfolgsfaktoren auf dem Weg zu einer UnternehmensDatenarchitektur, in: Information Management, 7. Jg., 1992, Nr. 3, S. 32-37. Rockart, J. (1979), Chief Executives Define their own Data Needs, in: Harvard Business Review, Vol. 57, 1979, No. 2, S. 81-93. Rockart, J. (1982), The Changing Role of the Information Systems Executive: A Critical Success Factors Perspective, in: Sloan Management Review, Vol. 24, Fall 1982, S. 3-13. Romeike, F., Müller-Reichart, M. (2008), Risikomanagement in Versicherungsunternehmen: Grundlagen, Methoden, Checklisten und Implementierung, 2. Auflage, Weinheim 2008. Ruh, A., Maginnis, F. und Brown, W. (2001), Enterprise Application Integration, New York, Chichester et al. 2001. 287

Literaturverzeichnis Ruhnke, K. (2008), Rechnungslegung nach IFRS und HGB – Lehrbuch zur Theorie und Praxis der Unternehmenspublizität mit Beispielen und Übungen, 2. Auflage, Stuttgart 2008. Rupprecht, J. (2003), Zugriffskontrolle im Data Warehouse, in: von Maur, E. und Winter, R. (Hrsg., 2003), Data Warehouse Management, Berlin, Heidelberg et al. 2003, S. 113-147. Schackmann, J. und Schü, J. (2001), Personalisierte Portale, in: Wirtschaftsinformatik, 43. Jg., 2001, Nr. 6, S. 623-625. Scheer, A-W. (1998), Wirtschaftsinformatik – Referenzmodelle für industrielle Geschäftsprozesse, 2. Auflage, Berlin, Heidelberg et al. 1998. Schlageter, G. und Stucky, W. (1983), Datenbanksysteme: Konzepte und Modelle, 2. Auflage, Stuttgart 1983. Schmalenbach, E. (1934), Grundlagen der Selbstkostenrechnung und Preispolitik, 6. Auflage, Leipzig 1934. Schöder, H.H. und Schiffer, G. (2001), Konzeptionelle Grundlagen der strategischen Frühinformation, in: WISU, 32. Jg., 2003, Nr. 7, S. 971-978. Schrefl, M. und Thalhammer, T. (2000), On Making Data Warehouses Active, in: Proceedings of the Second International Conference on Data Warehousing and Knowledge Discovery, DaWaK 2000, London, Berlin und Heidelberg 2000, S. 34-46. Schreier, U. (2001), Data Dictionary, in: Mertens, P. (Haupt-Hrsg., 2001), Lexikon der Wirtschaftsinformatik, 4. Auflage, Berlin, Heidelberg et al. 2001, S. 129-130. Schwalm, S. und Bange, C. (2004), Einsatzpotenziale von XML in Business-Intelligence-Systemen, in: Wirtschaftsinformatik, 46. Jg., 2004, Nr. 1, S. 5-14. Scott Morton, M.S. (1983), State of the Art of Research in Management Support Systems, Vortrag im Rahmen des Colloquium on Information Systems, MIT, 10.-12. Juli, 1983. Shilakes, C.C. und Tylman, J. (1998), Enterprise Information Portals, New York 1998. Siegel, M. (2008), RFID-basierte BI-Analysen in der Supply Chain: Exemplarische Darstellung und Bewertung von Szenarien. Diplomarbeit, Stuttgart 2008. Song, M. und van der Aalst, W.M.P. (2008), Towards comprehensive support for organizational mining, in: Decision Support Systems, Vol. 46, 2008, S. 300-317. 288

Literaturverzeichnis Staberhofer, F. und Rohrhofer, E. (2007), Ganzheitliches Supply Chain Management – Das Steyr Netzwerk Modell (SNM) als neuer Managementansatz, in: Klaus, P., Staberhofer, F. und Rothböck, M., (2007, Hrsg.), Steuerung von Supply Chains – Strategien, Methoden, Beispiele. Wiesbaden 2007. Staudt, M., Vaduva, A. und Vetterli, T. (1999), Metadata Management and Data Warehousing, Technical Report des Instituts für Informatik der Universität Zürich, ifi-99.04, auf den Seiten der Universität Zürich, ftp://ftp.ifi.unizh.ch/pub/techreports/ TR-99/ifi-99.04.pdf, Zürich 1999, Zugriff am 01.04.2010. Staudt, M., Vaduva, A. und Vetterli, T. (2004), Metadaten, in: Bauer, A. und Günzel, H. (Hrsg., 2004), Data-WarehouseSysteme: Architektur, Entwicklung, Anwendung, 2. Auflage, Heidelberg 2004, S. 327-348. Steinbock, H.J. (1994), Potentiale der Informationstechnik – Stateof-the-art und Trends aus Anwendungssicht, Stuttgart 1994. Stelter, D. (1999), Wertorientierte Anreizsysteme für Führungskräfte und Management, in: Bühler, W. und Siegert, T. (Hrsg., 1999), Unternehmenssteuerung und Anreizsysteme, Stuttgart 1999. Sterman, J. (2000), Business Dynamics: Systems Thinking and Modeling for a Complex World, Boston, Burr Ridge et al. 2000. Stewart, B. (1999), The Quest for Value, New York 1999. Sullivan, D. (2001), Document Warehousing and Text Mining. Techniques for Improving Business Operations, Marketing, and Sales, New York: 2001. Teradata (Hrsg., 2007), Enterprise Data Warehouse Delivers Healthy Returns to BKK Insurance Companies, Teradata Whitepaper, publiziert 2007, URL: http://www.zdnet.de/ enterprise_data_warehouse_delivers_healthy_returns_to_bkk_ insurance_companies_download-39002355-88053037-1.htm, Zugriff am 01.04.2010. Thalhammer, T., Schrefl, M. und Mohania, M. (2001), Active data warehouses: complementing OLAP with analysis rules, in: Data & Knowledge Engineering, Vol. 39, 2001, No. 3, S. 241269. Thomson, J.K. (2009), Business Intelligence in a SaaS Environment, in: Business Intelligence Journal, Vol. 14, 2009, No. 4, S. 50-55. 289

Literaturverzeichnis Timmers, P. (1998), Business models for electronic markets, in: Electronic Markets, Vol. 8 (1998), No. 2, S. 3-8. Turban, E., Aronson, J.E. und Liang, T.P. (2004), Decision Support and Intelligent Systems, 7. Auflage, New Jersey 2004. Unger, C., Kemper, H.G. (2008), Organisatorische Rahmenbedingungen der Entwicklung und des Betriebs von Business Intelligence – Ergebnisse einer empirischen Studie, in: Bichler, M., Hess, T., Krcmar, H., Lechner, U., Matthes, F., Picot, A., Speitkamp, B. und Wolf, P. (Hrsg., 2008), Tagungsband der Multikonferenz Wirtschaftsinformatik 2008, Berlin 2008, S. 141-153. Vaduva, A. und Vetterli, T. (2001), Metadata Management for Data Warehousing: an Overview, in: International Journal of Cooperative Information Systems, Vol. 10, 2001, No. 3, S. 273298. Vajna, S., Weber, C., Bley, H. und Zeman, K. (2009), CAx für Ingenieure – eine praxisbezogene Einführung, 2. Auflage, Berlin und Heidelberg 2009. van der Aalst, W.M.P. und Weijters, A.J.M.M. (2004), Process Mining: A Research Agenda, in: Computers in Industry, Vol. 53, 2004, No. 3, S. 231-244. Vedder, R.G., Vanecek, M.T., Guynes, C.S. und Cappel, J.J. (1999), CEO and CIO Perspectives on Competitive Intelligence, in: Communications of the ACM, Vol. 42, No. 8, S. 109-116. Vetter, M. (1998), Aufbau betrieblicher Informationssysteme mittels pseudo-objektorientierter, konzeptioneller Datenmodellierung, 8. Auflage, Stuttgart 1998. von Maur, E., Schelp, J. und Winter, R. (2003), Integrierte Informationslogistik – Stand und Entwicklungstendenzen, in: von Maur, E. und Winter, R. (Hrsg., 2003), Data Warehouse Management, Berlin, Heidelberg et al. 2003, S. 3-23. W3C (Hrsg., 2006), Extensible Markup Language (XML) 1.1 (Second Edition), auf den Seiten des W3C, publiziert am 29.9.2006, URL: http://www.w3.org/TR/2006/REC-xml1120060816/, Zugriff am 01.04.2010. Wahl, M., Kille, S. und Howes, T. (1997), RFC 2253: Lightweight Directory Access Protocol (v3), 1997. Wahrig-Burfeind, R. (Hrsg., 2006), Wahrig Deutsches Wörterbuch, Gütersloh und München 2006. 290

Literaturverzeichnis Ward, J. und Peppard, J. (2003), Strategic Planning for Information Systems, Chichester, New York et al. 2003. Warmbrodt, H.S. und Hall, R. (2008), Social Network Analysis of Video Bloggers’ Community, in: Proceedings of the 41. Hawaii International Conference on System-Sciences (HICSS-41), Washington DC 2008. Wasserman, S. und Faust, K. (1994), Social Network Analysis – Methods and Applications, Cambridge 1994. Weber, I. (2009), Touchdown für Flughafen?, in: BI-Spektrum, 4. Jg., 2009, Nr. 1, S. 26-27. Wehrle, A. und Heinzelmann, M. (2004), Reporting und strategische Steuerung im Profifußball – Konzeption und Umsetzung eines Balanced Scorecard basierten Systems beim VfB Stuttgart, in: Controlling, 16. Jg., 2004, Nr. 6, S. 349-354. Weill, P. und Ross, J.W. (2004), IT Governance – How Top Performers Manage IT Decision Rights for Superior Results, Boston 2004. Weinhardt, C., Aadasivam, A., Blau, B., Borissov, N., Meinl, T., Michalk, W. und Stößer, J. (2009), Cloud-Computing – Eine Abgrenzung, Geschäftsmodelle und Forschungsgebiete, in: Wirtschaftsinformatik, 51. Jg., 2009, Nr. 5, S. 453-462. Weiser, M. (1996), Ubiquitous Computing, auf den Seiten des Palo Alto Research Center (Sandbox Server), publiziert am 17.3.1996, URL: http://www.ubiq.com/hypertext/weiser/ UbiHome.html, Zugriff am 01.04.2010. Weiss, S.M., Indurkhya, N., Zhang, T. und Damerau, F.J. (2005), Text Mining – Predictive Methods For Analyzing Unstructured Information, New York 2005. White, C. (2005), Data Integration: Using ETL, EAI, and EII Tools to Create an Integrated Enterprise, TDWI Whitepaper, publiziert im November 2005, URL: http://www.tdwi.org/research/ display.aspx?ID=7908, Zugriff am 01.04.2010. Wieken, J.H. (1999), Der Weg zum Data Warehouse – Wettbewerbsvorteile durch strukturierte Unternehmensinformationen, München, Reading et al. 1999. Wirtz, B.W. (2001), Electronic Business, Wiesbaden 2001. Wöhe, G. und Döring, U. (2008), Einführung in die allgemeine Betriebswirtschaftslehre, 23. Auflage, München 2008.

291

Literaturverzeichnis Wolf, K. und Runzheimer, B. (2009), Risikomanagement und KonTraG: Konzeption und Implementierung, 5. Auflage, Wiesbaden 2009. zur Mühlen, M. (2001), Process-driven Management Information Systems – Combining Data Warehouses and Workflow Technology, in: Gavish, B. (Hrsg., 2001), Proceedings of the Fourth International Conference on Electronic Commerce Research (ICECR-4), Dallas 2001, S. 550-566. Zwahr, A. (Hrsg., 2006), Meyers Grosses Taschenlexikon, Band 1, 10. Auflage, Mannheim 2006.

292

Sachwortverzeichnis

Sachwortverzeichnis A Abweichungsanalyse 116 Active Data Warehousing 94 Ad-hoc-Analysesysteme 99 Administrationsschnittstellen 26, 56, 227 Fachliche ~ 57 Technische ~ 57 Advanced Analytics 110 Advanced Planning Systems 138 Aggregation 35 Ajax 109, 251 Aktionszeit 91 Aktive Metadaten 48 Altruistischer Anteil 201 Analyselatenz 92 Analyseregel 95 Analysesysteme 85, 213 Ad-hoc-~ 99 Konzeptorientierte ~ 131 Modellgestützte ~ 110 Anreicherung 37 Applikationsklassenneutralität 39, 183 Applikationsorientierung 24, 36, 40, 41, 58, 66, 112, 227 Architektur 21, 24 Archivierung 71 Assoziation 116

B Backup 71 Balanced Scorecard 131, 173 Bebauungsplan 245 Berechtigungsverwaltung 54

Rollenbasierte Zugriffskontrolle 54 Berichtsorientierte Systeme 86 Berichtssysteme 124 Berichtswesen 125 Beschreibungsprobleme 115 Best-Of-Breed 50, 233 BI Competence Center 246, 255 BI Governance 167 BI Governance Committee 191, 195 BI Service 179, 255 BI Service Policies 180 BI-Service-Bibliothek 181 Komposition 181 BI Sourcing 182, 256 BICC Siehe BI Competence Center BI-Gesamtansatz Makro-Ebene 165, 167 Mikro-Ebene 165, 196 BI-Gremien 191 BI-Ordnungsrahmen 10 BI-Organisationseinheit 192 BI-Vorgehensmodell Controllingpunkte 166 Entwicklungmodell 199 Reengineering 205 Business Intelligence 1 BI-Ordnungsrahmen 10 Definition 8

C Call Detail Record 215 Check-In/Check-Out 147 Churn-Analyse 88, 217 Closed-loop Data Warehousing 93, 223

293

Sachwortverzeichnis Cloud Computing 252 Common Warehouse Metamodel 54 Competitive Intelligence 258 Content Management System 12, 145 Controllingpunkte 166 Core Data Warehouse 25, 39, 209, 213, 216, 221 Corporate Governance 167 Corporate Social Responsibility 259 Critical Success Factor 173 CSR Siehe Corporate Social Responsibility CSV-Format 148 Customer Relationship Management 8, 88, 219

D Data Manipulation Language 96 Data Mart 26, 41, 209, 213 Data Mining 113 Data Warehouse 19, 20, 24, 26, 209 Architektur 21 Core ~ 25, 39, 209, 213, 216, 221, 234 Data Mart 26, 41, 209, 213 Data Warehouse Appliance 249 Hub-and-Spoke-Architektur 24 Implementierungsansätze 90 Nabe-Speiche-Architektur 24 Virtuelles ~ 24, 27 Data Warehousing Active ~ 94 Closed-loop ~ 93, 223 Implementierungsansätze 90 Real-time ~ 93, 224, 229 Daten 142

294

Datenarchitektur 183 Dispositive ~ 183 Datenmodellierung 58 Entity-Relationship-Modell 59 Multidimensionale ~ 66 Daten-Pool-Ansatz 18 Decision Support Systems 111 Delta-Historisierung 74, 216 Deskription 115 Dimensionen 20, 66, 199 Direktmarketing 220 Dispositive Arbeitsleistung 15 Dispositive Daten 16 Dispositive Datenarchitektur 183 Document Management System 12, 145 Document Warehouse 119 Drill-across 103 Drill-down 102 Drill-through 103

E E-Business 6 Economic Value Added™ 140 Electronic Product Code 237 Embedded BI 21 End-to-End 50, 245 Entity-Relationship-Modell 59 Entscheidungslatenz 92 Entscheidungsunterstützungssys teme 111 Entwicklungmodell 199 EPC Siehe Electronic Product Code Erfolgsfaktor, kritischer Siehe CSF ETL 25, 26, 221 Event-Condition-Action-Modell 94 Executive Informaton System 129

Sachwortverzeichnis Expert Systems 113 Extensible Business Reporting Language 150 Extensible Markup Language 149, 153

F Fachliche Administrationsschnittstelle 57 Fact-Constellation-Schema 69 Fakten 66, 199 FASMI 100 Feed 153 Filterung 28 Flat File 112 Fraud Detection 46, 217 Freie Datenrecherche 96

I Individuelle Datenverarbeitung 86 Information Design 187 Information Extraction 118 Information Retrieval 147 Informationen 142 IT-Governance 167

K Kampagnenmanagement 220 Klassifikation 116 Knowledge Discovery in Databases 113 Kommunikationskanal 221 Konsolidierung 138 Konzeptorientierte Systeme 131

G Galaxien 69 Geschäftsmodell 164 Globalisierung 5 Granularität 20, 32, 199

H Harmonisierung 32 Hierarchisierungen 66, 199 Historisierung 21, 71 Delta-~ 74, 216 Snapshot-~ 73 Update-Verfahren 72 Homonyme 34 Hub-and-Spoke-Architektur 24 Hypercube 101

L Latenzzeiten 91 Legacy-Systeme 27 Leitbild 172 Leitlinien 169 Lemmatisierung 119

M Makro-Ebene 165, 167 Controlling 188 Management Information Systems 129 Management Support Systems (MSS) 1 Manufacturing Execution System 123, 239 Mashup 252

295

Sachwortverzeichnis MDX Siehe Multidimensional Expressions MES Siehe Manufacturing Execution System Metadaten 26, 47 ~management 51 ~standard 54 Aktive ~ 48 Common Warehouse Metamodel 54 Passive ~ 48 Metadatenmanagement 51 Metadatenstandard 54 Methode der kritischen Erfolgsfaktoren 172 Methodenbank 112 Mikro-Ebene 165, 196 Controlling 188 Mission 172 Mobile BI 251 Modellbank 112 Modellgestützte Analysesysteme 110 Modellorientierte Analysesysteme 85 Multidimensional Expressions 97 Multidimensionale Datenmodellierung 66

N Nabe-Speiche-Architektur 24 Natural Language Processing 119 Normalisierung 41, 63

O OLAP freie Analysen 108 geführte Analysen 108 H-OLAP, hybrides ~ 107

296

M-OLAP, multidimensionales ~ 107 R-OLAP, relationales ~ 106 Online Transaction Processing 16 Operational BI 45, 90, 254 Operational Data Store 24, 26, 43, 213, 216 Operative Daten 15

P part of speech tagging 119 Passive Metadaten 48 Personalisierung 156 Pilotsystem 175 Pivotierung 102 Planung 135 PMML Siehe Predictive Model Mining Language Point of Sale 221 Portal 154, 213 Portfoliomanagement 174 Portlet 157 Potenzialplanung 172 Pragmatik 142 Predictive Model Mining Language 151 Process Data Warehouse 123 Process Mining 123, 253 Prototyping 201, 212

R Radio Frequency Identification 177, 235, 240 RDL Siehe Report Definition Language Real-time Data Warehousing 93, 224, 229 Reengineering 205 Report Definition Language 151

Sachwortverzeichnis Reporting Plattformen 127 REST 251 RFID 240, Siehe Radio Frequency Identification RFMR-Analyse 222 Rich Internet Application 109, 251 Richtlinien 169 Rollenbasierte Zugriffskontrolle 54 Roll-up 102 Rotation 102

S SCM Siehe Supply Chain Management Segmentierung 116 Semantic Web 144 Semantik 142 Service Oriented Architecture 251, 256 Shareholder Value 140 Single Sign On 157 Slice & Dice 104 Smartphone 153, 251 Snapshot-Historisierung 73 Snowflake-Schema 70, 81 SOA Siehe Service Oriented Architecture Social Network Analysis 122 Software as a Service 251 Split & Merge 105 SQL Siehe Structured Query Language Stakeholder 6 Star-Schema 67 Stemming 119 Strategie 168 Strategy Maps 132 Structured Query Language 97 Supply Chain Management 8, 235 Support

First Level Support 204 Second Level Support 204 SWOT-Analyse 172, 173 Synonyme 34

T Technische Administrationsschnittstelle 57 Technologiemanagement 176 Template 151, 180, 246, 253 Text Mining 118 Transformation Hub 254 Transformationsprozess 25, 26 Aggregation 35 Anreicherung 37 ETL 25, 26 Filterung 28 Harmonisierung 32

U Ubiquitous Computing 239, 253 Umsetzungslatenz 92 Update-Verfahren 72

V Value Based Management 139 Versionierung von Dokumenten 147 Virtualisierung 250 Virtuelles Data Warehouse 24, 27

W Web 2.0 144 Web Crawler 118

297

Sachwortverzeichnis Web Mining 122, 253 Web Service 251 Wertorientiertes Management 139 Werttreiberbäume 140 Wiki 144 Wirkungsprognose 117 Wissen 142 kodifiziertes ~ 143 Wissensmanagementsysteme 143

X XBRL Siehe Extensible Business Reporting Language XML Siehe Extensible Markup Language XML Schema 149

Z Zeichen 142 Zielgruppenselektion 222

298