Business Intelligence – Arbeits- und Übungsbuch. Glossar, Aufgaben, Lösungsskizzen

Hans-Georg Kemper Henning Baars

Business Intelligence – Arbeits- und Übungsbuch

Aus dem Bereich IT erfolgreich lernen

Unternehmensweites Datenmanagement von Rolf Dippold, Andreas Meier, Walter Schnider und Klaus Schwinn Grundkurs Wirtschaftsinformatik von Dietmar Abts und Wilhelm Mülder Anwendungsorientierte Wirtschaftsinformatik von Paul Alpar, Heinz Lothar Grob, Peter Weimann und Robert Winter Masterkurs IT-Controlling von Andreas Gadatsch und Elmar Mayer Grundkurs Geschäftsprozess-Management von Andreas Gadatsch Business Intelligence – Grundlagen und praktische Anwendungen von Hans-Georg Kemper, Walid Mehanna und Carsten Unger

Business Intelligence – Arbeits- und Übungsbuch von Hans-Georg Kemper und Henning Baars

www.vieweg.de

Hans-Georg Kemper Henning Baars

Business Intelligence – Arbeits- und Übungsbuch Glossar, Aufgaben, Lösungsskizzen Mit 20 Abbildungen

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. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. 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 2008 Alle Rechte vorbehalten © Friedr. Vieweg & Sohn Verlag | GWV Fachverlage GmbH, Wiesbaden 2008 Lektorat: Günter Schulz / Andrea Broßler Der Vieweg-Verlag ist ein Unternehmen von Springer Science+Business Media. www.vieweg.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. Umschlaggestaltung: Ulrike Weigel, www.CorporateDesignGroup.de Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Gedruckt auf säurefreiem und chlorfrei gebleichtem Papier. Printed in Germany ISBN 978-3-8348-0434-1

Vorwort Das Arbeits- und Übungsbuch dient der Vermittlung von fundierten Business-Intelligence-Kenntnissen. Es deckt als eigenständiges Werk das gesamte Themengebiet ab, stellt aber insbesondere eine sinnvolle Ergänzung zum Lehrbuch Business Intelligence – Grundlagen und praktische Anwendungen dar. Die Inhalte dienen der Vertiefung des vermittelten Stoffes, ermöglichen das direkte Einüben und Ausprobieren des Erlernten anhand praxisrelevanter Aufgabenstellungen und bieten somit für Studenten und Praktiker wertvolle Hilfestellungen bei der nachhaltigen Durchdringung des Themengebietes „Business Intelligence – BI“. Das Buch gliedert sich in vier Blöcke, x

einem Glossar mit zentralen BI-Begriffen,

x

einem Übungsteil mit korrespondierenden Einzelaufgaben zu den einzelnen Lehrbuchkapiteln,

x

einem Teil mit Lösungen und Lösungsskizzen zu den Aufgabenstellungen des Übungsteils,

x

einem kurzen Teil mit Literaturempfehlungen zu den behandelten Themenschwerpunkten.

Das Arbeits- und Übungsbuch ist sowohl für individuelles Lernen als auch für gruppenorientiertes Arbeiten in Teams geeignet und bietet Dozenten wertvolle Hilfestellungen bei der Vorbereitung und Durchführung von Präsentationen, Vorlesungen und Übungen. Für die redaktionelle Unterstützung bei der Erstellung des Buches danken wir Frau Viola Koppetzki und Frau Catherine Kotalla. Wir wünschen allen Lesern viel Erfolg bei der Lektüre und freuen uns über kreative Anregungen. Stuttgart, im November 2007 Hans-Georg Kemper Henning Baars

V

Inhaltsverzeichnis 1

BI-Glossar ........................................................................................................1

2

Übungsaufgaben .......................................................................................... 21 2.1

Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen ....... 21

2.2

Datenbereitstellung für BI-Konzepte......................................................... 23

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext ..... 31

2.4

Informationsgenerierung, -speicherung, -distribution und -zugriff......... 46

2.5

Entwicklung integrierter BI-Anwendungssysteme.................................... 51 Lösungen und Lösungsskizzen ................................................................. 57

3

4

3.1

Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen ....... 57

3.2

Datenbereitstellung für BI-Konzepte......................................................... 61

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext ..... 75

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff....... 101

3.5

Entwicklung integrierter BI-Anwendungssysteme.................................. 117 Literaturempfehlungen ............................................................................ 133

VII

1

BI-Glossar Im Folgenden finden Sie ein Glossar mit den wichtigsten Begriffen aus dem Bereich „Business Intelligence“. Das Glossar ist sowohl auf das vorliegende Arbeitsbuch als auch auf das korrespondierende Lehrbuch Business Intelligence – Grundlagen und praktische Anwendungen ausgerichtet und bietet somit bei der Lektüre beider Werke nützliche Hilfestellungen. 1. Normalform (1NF). Eine Relation befindet sich in der 1NF, wenn sämtliche Nicht-Schlüsselattribute funktional von einem Schlüssel abhängen (Æ Normalisierung). 2. Normalform (2NF). Relationen der 2NF müssen so konstruiert sein, dass sie den Anforderungen der 1NF genügen und zusätzlich alle Nicht-Schlüsselattribute funktional vom gesamten Schlüssel abhängen. Mit anderen Worten dürfen bei zusammengesetzten Schlüsseln nicht bereits einzelne Schlüsselattribute bestimmte Nicht-Schlüsselattribute der Relation identifizieren (Æ 1. Normalform, Æ Normalisierung). 3. Normalform (3NF). Relationen befinden sich in 3NF, wenn sie den Anforderungen der 2NF genügen und zusätzlich keine funktionalen Abhängigkeiten zwischen Nicht-Schlüsselattributen existieren. Es darf somit nicht vorkommen, dass neben dem Schlüssel Nicht-Schlüsselattribute existieren, die andere Attribute der Relation identifizieren (Æ 2. Normalform, Æ Normalisierung). 4. und 5. Normalform. Diese Normalformen widmen sich den unabhängigen Beziehungen in zusammengesetzten Schlüsseln und der damit möglichen Redundanz innerhalb der Verbundschlüssel. Zur Vertiefung sei an dieser Stelle auf die Fachliteratur verwiesen. Active Data Warehousing ist eine Variante der datenseitigen Anbindung von Æ Analysesystemen, bei der auf der Basis von Datenkonstellationen (Ereignissen) automatisch Prozesse angestoßen werden. Typische Einsatzgebiete sind die Generierung von Ausnahmeberichten oder die Optimierung von Logistikprozessen durch automatisiertes Auslösen von Bestellprozessen oder 1

1

BI-Glossar Ermittlung alternativer Lieferwege in Engpassfällen (Æ Data Warehousing). Ad-hoc-Analysesysteme sind flexible Abfragesysteme zur Deckung eines spontanen Informationsbedarfs (Æ OLAP). Administrationsschnittstellen der BI-Datenhaltungssysteme (Æ Operational Data Store, Æ Data Warehose, Æ Data Mart) sind systemgestützte Zugänge, mit deren Hilfe technische und betriebswirtschaftliche Spezialisten sämtliche Bereiche der dispositiven Datenhaltung pflegen können. Somit können mit ihnen die Subprozesse der Æ Transformation, die Daten oder Datengruppen und die rollenbasierten Æ Berechtigungsstrukturen generiert, modifiziert und gelöscht werden. Aggregation ist die Dokumentation der Verdichtungsstrukturen über die Dimensionen gefilterter und harmonisierter Daten (Æ Filterung, Æ Harmonisierung, Æ Transformation). Analysesysteme ist der Oberbegriff für sämtliche IT-Systeme des Managements, mit deren Hilfe Daten in einen anwendungsorientierten Kontext überführt, spezifisch aufbereitet und präsentiert werden. Es werden sowohl Æ generische Basissysteme als auch Æ konzeptorientierte Analysesysteme unterschieden. Analytisches CRM dient der Untersuchung des Kundenbestandes und -verhaltens. In diesem Umfeld werden auf der Basis kundenzentrierter Æ Data Warehouses mit Hilfe von Æ Analysesystemen (vor allem Æ Data Mining und Æ OLAP) Kundenwertmodelle, Kundensegmentierungen bzw. -klassifikationen und kundenspezifische Verhaltensänderungen ermittelt (Æ Churn-Analysen) Anreicherung ist die Abbildung und/oder Berechnung betriebswirtschaftlicher Kenngrößen aus gefilterten, harmonisierten und ggf. aggregierten Daten (Æ Filterung, Æ Harmonisierung, Æ Aggregation, Æ Transformation). Balanced Scorecard ist ein Managementkonzept, mit dessen Hilfe ein Unternehmen auf der Basis von verschiedenen interdependenten Betrachtungsperspektiven geführt werden kann. Das Verfahren wurde von Kaplan/Norton in den 1990er Jahren entwickelt und beinhaltet in seiner ursprünglichen Fassung die Perspektiven Finanzen, Kunden, Geschäftsprozesse und Lernen/Entwicklung, für die jeweils Ziele, Messgrößen und Einflussfaktoren über verschiedene Dekompositionsstufen generiert/erhoben/überwacht werden (Æ konzeptorientierte Systeme).

2

1

BI-Glossar

Berechtigungsstrukturen werden im BI-Kontext in aller Regel als integrierte Bestandteile der BI-Datenhaltung in Form von rollenbasierten Zugriffssystemen realisiert. Hierbei werden Benutzer und Benutzergruppen aufgrund ihrer Aufgaben und Verantwortlichkeiten die Mitgliedschaften an benötigten Rollen zugewiesen. Die Rollen determinieren nach dem Need-to-knowPrinzip die Rechte, die zur Erfüllung definierter Aufgaben und Funktionen benötigt werden. Somit können Zugriffsrechte sachlich begründet und redundanzfrei für sämtliche Analysesysteme an zentraler Stelle angelegt und administriert werden. Berichtssysteme sind Æ Analysesysteme, die einen Überblick betriebswirtschaftlich relevanter Sachverhalte zu einem abgegrenzten Verantwortungsbereich präsentieren. Im BI-Kontext sind vor allem Æ interaktive Reportplattformen und generierte Berichte in Form von Æ Management Information Systems (MIS) und Æ Executive Information Systems (EIS) von Relevanz. Best-of-Breed-Lösungen bestehen aus Einzelkomponenten, die jeweils mit leistungsfähigen Spezialprodukten verschiedener Anbieter umgesetzt werden (Æ End-to-End-Lösungen). BI-Governance ist ein Teil der IT-Governance und meint den Bereich der organisatorischen Einbindung, der prozessualen Gestaltung und Steuerung des gesamten BI-Kontextes eines Unternehmens, um eine konsequente Ausrichtung des BI-Konzeptes an der Gesamtstrategie des Unternehmens sicherzustellen. Boyce-Codd-Normalform. Diese Normalform fokussiert mögliche funktionale Abhängigkeiten und damit Redundanzen in Relationen mit zwei oder mehreren sich überlappenden zusammengesetzten Schlüsselkandidaten. Zur Vertiefung sei an dieser Stelle auf die Fachliteratur verwiesen. Business Activity Monitoring (BAM) ist die kontinuierliche Überwachung kritischer Geschäftsprozesselemente bzw. –teilprozesse, um potentielle Engpässe im Prozessablauf frühzeitig identifizieren, dokumentieren und beheben zu können. Business Intelligence (BI) bezeichnet einen integrierten, unternehmensspezifischen, IT-basierten Gesamtansatz zur betrieblichen Entscheidungsunterstützung. Der Begriff hat sich mittlerweile in der Praxis und in der Wissenschaft etabliert und löst zunehmend die bis dato etablierte Bezeichnung Æ Management Support Systems (MSS) ab. Churn-Analysen gehören zum Æ analytischen CRM und dienen der Ermittlung kündigungsbereiter, wertvoller Kunden zum Zwe3

1

BI-Glossar cke ihrer Rückgewinnung. In aller Regel werden hierbei mit Hilfe geeigneter Methoden des Æ Data Mining spezielle Verhaltensmuster gesucht, die als frühe Signale einer potentiellen Beendigung der Geschäftsbeziehung gewertet werden können. Der Begriff Churn ist als Kunstwort zu interpretieren und lässt sich auf die plakative Formel „Change-and-Turn“ zurückführen, die eine angestrebte Absichtsänderung des Kunden und die Erneuerung der Kundenbindung meint. Closed-loop Data Warehousing bezeichnet eine Anbindung eines Æ Analysesystems, bei der erzeugte Daten in die operativen Quellen und/oder in das Æ Data Warehouse zurückgeschrieben werden. Ein typisches Anwendungsgebiet ist der Bereich Æ Customer Relationship Management (Æ Data Warehousing). Common Warehouse Metamodel (CWM) ist ein von der Object Management Group (OMG) entwickelter Standard für den flexiblen Austausch von Metadaten zwischen BI-Werkzeugen und Metadaten–Repositories (Æ Metadatenmanagement) verschiedener BI-Datenhaltungssysteme (Æ Operational Data Store, Æ Data Warehouse, Æ Data Mart). Content Management Systems (CMS) sind Systeme, die Informationsobjekte mit beliebiger elektronischer Darstellungsform (Daten, Texte, Graphiken, Bilder, Audio-/Videosequenzen) verwalten, wobei aus Gründen der Mehrfachverwendbarkeit eine strikte Trennung von Inhalt, Layout und Struktur erfolgt. CMS unterstützen insbesondere das Einfügen, Aktualisieren und Archivieren von Objekten sowie deren Aufbereitung und Zusammenstellung im Verwendungsfalle. Core Data Warehouse (C-DWH) ist bei der Æ Hub-and-SpokeArchitektur die zentrale Datenhaltungskomponente (Hub), die entweder direkt aus internen und externen Datenquellen oder aus vorgelagerten Æ Operational Data Stores über Æ ETLProzesse befüllt wird. Das C-DWH wird in aller Regel mit Hilfe relationaler Datenhaltungssysteme umgesetzt und kann durchaus Datenvolumina bis in den dreistelligen Terabyte-Bereich erreichen. Cube (Würfel) wird als Metapher für einen Æ mehrdimensionalen Datenraum verwendet (Æ Hypercube). Customer Relationship Management (CRM) ist ein umfassender Ansatz zur systematischen Unterstützung der Kundenbeziehungen. Generell wird zwischen kommunikativem CRM zur

4

1

BI-Glossar

Koordination der vielfältigen Kundenkontaktpunkte (MultiChannel-Management), operativem CRM zur Unterstützung von Kampagnen, Pre- und After-Sales-Aktivitäten sowie Æ analytischem CRM unterschieden, wobei ausschließlich das Æ analytische CRM zum Bereich Æ Business Intelligence zählt. Data Cleansing (Data Scrubbing) bezeichnet als Sammelbegriff die Prozesse zur Datenbereinigung. Im Mittelpunkt stehen Verfahren zur Fehlererkennung, Fehlerkorrektur, Syntaxabgleichung sowie zur Dublettenerkennung und -eliminierung (Æ Staging Area). Data Mart ist ein kleinerer Datenpool, der für eine Klasse von Applikationen eines spezifischen Anwendungskontextes gebildet wird. Er kann als eigenständige (meist abteilungsbezogene) Lösung direkt aus operativen/externen Quellen gespeist oder als Teil eines umfassenderen DWH-Ansatzes aus einem Æ Core Data Warehouse mit Daten versorgt werden (Æ Hub-and-SpokeArchitektur). Data Mining ist ein Sammelbegriff für Verfahren der Datenmustererkennung, mit denen effizient in großen Datenmengen nichttriviale Muster erkannt und dem Benutzer adäquat präsentiert werden können. Als Methoden kommen sowohl Beschreibungsverfahren (Deskription, Abweichungsanalyse, Assoziation, Gruppenbildung) als auch Prognoseverfahren (Klassifikation, Wirkungsprognose) zum Einsatz. Data Warehouse (DWH) ist ein Datenreservoir mit betriebswirtschaftlich harmonisierten Daten, das aus operativen und externen Quellen gespeist wird und als Datengrundlage der dispositiven (planerischen) IT-Systeme eines Unternehmens dient. Der Begriff DWH wurde primär von William H. Inmon Anfang der 1990er Jahre geprägt, der das DWH als themenorientierte, integrierte, zeitbezogene und non-volatile Datensammlung für die Zwecke der Managementunterstützung definierte. Data Warehousing bezeichnet die Nutzung des Æ Data Warehouses durch Æ Analysesysteme. Je nach Implementierungsalternative wird zwischen Æ klassischem Data Warehousing, Æ Closed-loop Data Warehousing, Æ Real-time Data Warehousing und Æ Active Data Warehousing unterschieden. Datenarchitektur bezeichnet einen Bauplan eines Datenmodells. Sie besteht in aller Regel aus einer begrenzten Anzahl (meist Terabyte).

x

Anwendungen mit großen Benutzerzahlen.

M-OLAP (Multidimensionales OLAP) basiert auf herstellerabhängigen, proprietären Datenbanksystemen, die speziell auf multidimensionale Datenstrukturen ausgerichtet sind. Vorteile: x

Sehr hohe Performance selbst bei komplexen mehrdimensionalen Abfragen.

x

Platzsparende Speicherung (komprimierte Datenhaltung).

x

Häufig sehr benutzerfreundliche Front-End-Funktionalitäten.

Nachteile: x

Datenhaltung als „Black-Box“ ausgelegt und somit auch für IT-Spezialisten nicht nachvollziehbar.

x

Sicherheits- und Administrationskonzept häufig rudimentär.

x

Keine einfache Migration auf andere Werkzeuge möglich.

x

Spezielles Entwicklungs-Know-how erforderlich.

Einsatzbereiche: x

Anwendungen mit geringem Datenvolumen und kleiner Benutzergruppe.

H-OLAP (Hybrides OLAP) basiert auf beiden o.a. Technologien und erlaubt einen benutzertransparenten – also für den Benutzer während seiner Anwendung nicht erkennbaren – Übergang von relationaler und physikalisch mehrdimensionaler Datenhaltung.

113

3

Lösungen und Lösungsskizzen Vor-/Nachteile: x

Soll Vorteile beider Technologien vereinen und Nachteile eliminieren.

Einsatzbereiche: x

Anwendungen mit großer Drill-down-Tiefe und sichtenspezifisch stark schwankenden Benutzerzahlen. Die M-OLAP-Techniken werden in diesem Falle bei den hochverdichteten Datenbereichen eingesetzt (geringes Datenvolumen, geringer Benutzeranzahl). Bei Drill-downOperationen in Detaildaten erfolgen benutzertransparente Übergänge in die relationalen Datenhaltungssysteme.

Aufgabe V-4-4: Balanced Scorecard Ihre Argumentation könnte folgende Punkte beinhalten: Eine Balanced Scorecard (BSC) gehört zu den konzeptorientierten Systemen, bei denen IT-Werkzeuge Hilfestellungen bei der Umsetzung umfangreicherer, betriebswirtschaftlicher Verfahren anbieten können. Bei der BSC-Entwicklung stehen jedoch nicht die Werkzeuge, sondern ganz eindeutig die betriebswirtschaftlichen Ansätze im Mittelpunkt, deren organisatorische Implementierung es zu planen und umzusetzen gilt. So sind bei den Perspektiven (nach Kaplan/Norton: Finanzen, Kunde, Geschäftsprozesse und Lernen/Entwicklung) jeweils Ziele, Messgrößen und Einflussfaktoren über verschiedene Dekompositionsstufen im Zeitverlauf zu generieren, zu erheben und zu überwachen. Hierbei sind u.a. folgende Problemstellungen zu lösen:

114

x

BSC-Integration in die Unternehmensstrategie.

x

Planung von BSC-Kaskaden.

x

Zielbestimmung und Zieloperationalisierbarkeit.

x

Aufbau geeigneter Messkonzepte.

x

Klärung der Datenverfügbarkeit und Datenqualität.

x

Bestimmung von Interdependenzen in und zwischen den Perspektiven.

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff x

Zuordnung organisatorischer Verantwortlichkeiten und Implementierung von Betreiberkonzepten.

Für einen Erfolg ist es mit dem Kauf eines BSC-Werkzeuges somit nicht getan. Aufgabe V-4-5: Business Intelligence und Wissensmanagement Ihre Argumentation könnte folgende Punkte beinhalten: Die Integration von Business Intelligence (BI) und Systemen des betrieblichen Wissensmanagements (WM) macht Sinn, da BIAnalysen einerseits betriebliches Wissen generieren und somit Input für das Wissensmanagement liefern und es anderseits sinnvoll ist, BI-Analysen um Bestände des Wissensmanagements anzureichern, um aussagefähige Interpretationen von BIAnalyseergebnissen zu ermöglichen. Potentiale – Integration von BI in WM Beispiel 1: Wiederverwendung von Analyseergebnissen x

Die Erstellung einer wertorientierten Lieferantensegmentierung in A-, B- und C-Lieferanten oder die Ermittlung kündigungsbereiter Kunden sind meist kostenintensiv, zeitaufwändig und mit erheblicher Komplexität verbunden.

x

„Mehrfach-Analysen“ über (teil-)identische Problembereiche sind an der Tagesordnung.

x

Lösung: Um Metadaten angereicherte Analyseergebnisse erlauben die Mehrfachverwendung generierter Resultate.

Beispiel 2: Wiederverwendung von Analysetemplates x

Komplexe Data-Mining-Modelle zur wertorientierten Lieferantensegmentierung in A-, B- und C-Lieferanten oder zur Ermittlung kündigungsbereiter Kunden sind nicht weniger aufwändig.

x

„Mehrfaches Entwickeln“ (teil-)identischer Modelle ist an der Tagesordnung.

x

Lösung: Um Metadaten angereicherte Analysetemplates erlauben die Mehrfachverwendung erstellter Systeme. 115

3

Lösungen und Lösungsskizzen Potentiale – Integration von WM in BI Beispiel 3: Customer Relationship Management (CRM) x

CRM-Applikationen basieren häufig auf Kundenwertanalysen. Meist wird dieser Kundenwert ausschließlich auf der Basis quantitativer Größen bestimmt (Umsatz, Gewinn, Potential). Informationen über individuelle Kosten liegen meist in unstrukturierter Form vor und werden daher nicht berücksichtigt. Z.B. Betreuungszeit per Telefon, Beschwerde- und Garantieaktionen, Kundenloyalität und Weiterempfehlung.

x

Lösung: Operationalisierung und Integration der Informationen in die OLAP-Anwendung würde ein exakteres Bild der Profitabilität des Kunden ergeben.

Beispiel 4: OLAP-Produktanalyse x

Mehrdimensionale Datenanalysen (Data Mining) deuten häufig auf „Ausreißerwerte“ hin (z.B. Umsatzeinbruch bei einer Produktkategorie, in einer Region, für eine Kundengruppe). Obwohl zu allen Dimensionen mannigfaltige Informationen innerhalb und außerhalb des Unternehmens verfügbar sind, sind sie in der BI-Anwendung nicht recherchierbar.

x

Lösung: Zuordnung textlicher, unstrukturierter Informationen könnte die Erklärung quantitativer Abweichungen erläutern.

Konzeptionelle Lösungsmöglichkeiten: Drei-schichtiger BI-WM-Integrationsansatz.

116

x

Integration auf der Präsentationsebene Hier wird die Integration auf der Ebene des Portals umgesetzt, so dass mit Hilfe dieser Einstiegsseite über Single-Signon beide Systeme (WM und BI) parallel auf der Basis identischer Abfragen recherchiert werden können.

x

Integration auf der Logikebene Hier wird durch geeignete Middleware sichergestellt, dass Analyseergebnisse und -modelle zwischen BI und WM (und vice versa) ausgetauscht werden können.

x

Integration auf der Datenebene Hier erfolgt die Integration durch den direkten Austausch von Fakten aus unstrukturierten Dokumenten und die Zu-

3.5

Entwicklung integrierter BI-Anwendungssysteme

ordnung unstrukturierter Dokumente zu BI-Analysen mittels Metadaten (Text Mining im engeren und im weiteren Sinne). Schwierigkeiten bei der Umsetzung integrierter Lösungen:

3.5

x

Konvertierung aller Dokumente in webfähige Formate.

x

Zugriff auf Dateiformate ohne Installation der Trägersysteme.

x

Versionsverwaltung, Delta-Analysen und Gültigkeitszeiträume.

x

Benutzerverwaltung und Berechtigungsstrukturen.

x

Kosten-/Nutzenaspekte.

x

Qualitätssicherung.

Entwicklung integrierter BI-Anwendungssysteme Basisfragen (B) Aufgabe B-5-1: Vorgehensmodelle (VM) VM gewährleisten einen arbeitsteiligen, einheitlichen, nachvollziehbaren Prozessablauf der Systementwicklung. Gemeinsamkeiten: VM bündeln Aktivitäten zu Phasen und integrieren Meilensteine zur Ergebnisprüfung. Zu dokumentieren sind durch VM: x

Bestimmung der Phasenziele.

x

Nennung der Aktivitäten und ihrer jeweiligen Rollenzuordnung.

x

Beschreibung der Ergebnistypen (Artefakte) anhand von Mustern.

x

Vorgabe von Methoden, Verfahren, Richtlinien und Werkzeugen.

117

3

Lösungen und Lösungsskizzen Unterschiede: x

Alternative Phasenabgrenzungen.

x

Unterschiedliche Fokussierung von Problemschwerpunkten.

x

Verschiedene Rücksprungsmöglichkeiten in Vor-Phasen.

x

Unterschiedliche Akzente im Softwarelebenszyklus (Entwicklungs-, Einsatzphasen).

Aufgabe B-5-2: Sequentielle Vorgehensmodelle (VM) x

Sequentielle VM sind durch eine vorgegebene Ablauffolge der einzelnen Phasen gekennzeichnet.

x

Historie reicht in die 1960er Jahre (Beginn des Software Engineering, also des „ingenieur-mäßigen“ Vorgehens bei der Softwareentwicklung).

x

Frühe Ansätze wurden erweitert und verändert. Das Wasserfallmodell erlaubt als erster gebrauchsfähiger Ansatz einen gewissen Grad der Auflösung der streng sequentiell abzuarbeitenden Phasen (Sprung in jeweilige Vorphase).

x

Das Wasserfallmodell stand Pate für verschiedenste unternehmensspezifische Vorgehensmodelle und Neuentwicklungen, z.B. für das ursprünglich für die Bundeswehr konzipierte, heute weit verbreitete V-Modell.

x

Sequentiellen VM liegt die Annahme zugrunde, dass Anforderungen an IT-Systeme im Vorfeld vollständig spezifizierbar sind und diese – einmal entwickelt – relativ veränderungsstabil im Unternehmen eingesetzt werden können.

x

Spezifizierbarkeit und Veränderungsstabilität waren lange Zeit zutreffend und sind in operativen Kontexten – wie z.B. bei Systemen der Lohn- und Gehaltsabrechnungen – auch heute durchaus noch anzutreffen.

Aufgabe B-5-3: Iterative Vorgehensmodelle (VM) Welche der Aussagen ist (sind) falsch? ; Für iterative VM sind vor allem zyklisch durchgeführte, technisch-orientierte Machbarkeitsanalysen charakteristisch. (Technisch-orientierte Machbarkeitsanalysen gehören zu 118

3.5

Entwicklung integrierter BI-Anwendungssysteme

dem Bereich des experimentellen Prototyping und werden im Bedarfsfall – bei innovativen Technologien oder vorhersehbaren technischen Herausforderungen – in allen Vorgehensmodellen eingesetzt.) ; Bei iterativen VM erfolgt die Systementwicklung primär durch Mitarbeiter der betriebswirtschaftlichen Abteilungen. (Iterative VM haben nichts mit individueller DV zu tun. Es wird bei der Verwendung von iterativen VM somit keinerlei Aussage über die Zusammensetzung der Projektgruppe getroffen.) ‰ Bei iterativer Systementwicklung wird konsequent die Methodik des explorativen Prototyping eingebunden.

Aufgabe B-5-4: Inkrementelle Entwicklungsmodelle Charakteristika: x

Die Anforderungen an das Gesamtsystem werden bereits zu Beginn der Entwicklung vollständig erfasst und modelliert.

x

Die Gesamtarchitektur des zu entwickelnden Systems wird generiert.

x

Die sukzessive Entwicklung der einzelnen Module erfolgt architekturkonform.

Einsatzgebiet BI: Das inkrementelle Modell eignet sich für Anwendungsgebiete, die in Form von Teilsystemen entwickelt werden, deren gesamter Entwicklungsprozess jedoch weitestgehend antizipierbar bleibt, d.h. nicht von gravierenden Unwägbarkeiten technischer Entwicklungen und/oder stark variierenden Benutzeranforderungen geprägt ist. BI-Ansätze stellen in großen Teilen ein solches Anwendungsgebiet dar, da hier die Schaffung einer zeitbeständigen BI-Infrastruktur angestrebt wird, in deren Kontext Einzelsysteme hoch-integriert interagieren. Aufgabe B-5-5: Iterative, evolutionäre und inkrementelle Entwicklungsmodelle Welche der Aussagen ist (sind) richtig?

119

3

Lösungen und Lösungsskizzen ‰ Iterative, evolutionäre und inkrementelle Entwicklungsmodelle stellen drei verschiedene Ansätze der Systementwicklung dar. (Iterative Entwicklungsmodelle stellen den Oberbegriff dar. Somit gehören evolutionäre und inkrementelle Modelle zu den iterativen Entwicklungsmodellen.) ; Prototypisch ausgerichtete Entwicklungszyklen einzelner Module kennzeichnen sowohl das evolutionäre als auch das inkrementelle Entwicklungsmodell. ‰ Das inkrementelle Vorgehensmodell impliziert eine konsequente Abkehr von projektorientierten Vorgehensweisen. (Nein, einzelne Teil-Systeme werden in Projektform entwickelt.) ; Das evolutionäre Vorgehensmodell unterscheidet sich vom inkrementellen Vorgehensmodell vor allem durch das Fehlen einer zu Beginn zu generierenden Gesamtarchitektur des zu entwickelnden Systems. Aufgabe B-5-6: BI-Vorgehensmodell – Makro-Ebene Welche der Aufgaben gehören zur Makro-Ebene (zum Rahmenkonzept) eines unternehmensumfassenden BI-Ansatzes. ; BI-Potentialplanung ‰ Reengineering bestehender BI-Subsysteme (Gehört zur projektorientierten Mikro-Ebene.) ‰ Aufbau eines Projektdatenmodells (Gehört zur projektorientierten Mikro-Ebene.) ‰ Implementierung von ETL-Prozessen (Gehört zur projektorientierten Mikro-Ebene.) ; Aufbau einer dispositiven Datenarchitektur ; Erstellung eines BI-Portfolios Aufgabe B-5-7: BI-Potentialplanung BI-Wirksamkeit bezeichnet den Grad der individuellen Potentialnutzung, den BI-Ansätze im Unternehmen leisten.

120

3.5

Entwicklung integrierter BI-Anwendungssysteme

BI-Wirtschaftlichkeit fokussiert die monetäre Dimension und präzisiert die Effizienz von BI-Ansätzen bei einer gegebenen Wirksamkeit. Fehlentwicklungen: Nicht selten werden isolierte Teilsysteme der Managementunterstützung professionell entwickelt, die durchaus problemangemessene Teillösungen darstellen. Jedoch wird in Ermangelung der Kenntnis des unternehmensspezifischen Gesamtpotentials nicht der Erfolgsbeitrag erbracht, der durch ein angemessenes BI-Rahmenkonzept erreichbar wäre (geringe Wirksamkeit des Gesamtansatzes, gute Wirtschaftlichkeit bezogen auf die Teillösung; es existiert also ein BI-Strategiedefizit). Ein weiterer, in der Praxis nicht selten anzutreffender Mangel ist die völlige Fehleinschätzung des gesamten BI-Komplexes. Hier erfolgt aufgrund der Unkenntnis des unternehmensindividuellen Potentials meist eine Überschätzung der Möglichkeiten, die gepaart mit mangelndem Wissen über Konzepte, Methoden und Werkzeuge nicht zu zufriedenstellenden BI-Entwicklungen führen. Dieser Fall tritt häufig auf, wenn eine Fachabteilung den BIAnsatz „in eigener Regie“ plant und technisch umsetzt (geringe Wirksamkeit, geringe Wirtschaftlichkeit; somit liegt in diesem Fall ein BI-Strategie- und Umsetzungsdefizit vor). Aufgabe B-5-8: Dispositve Datenarchitektur Welche der Aussagen (ist) sind korrekt? ; Die dispositive Datenarchitektur stellt den „Bauplan“ zur Abbildung der grundlegenden managementrelevanten Informationsobjekte und deren Beziehungen untereinander dar. ‰ Die dispositive Datenarchitektur dient als unmittelbare Vorgabe der Implementierung der ETL-Prozesse. (Nein, das ist die Aufgabe der Projekt-Datenmodelle der Mikro-Ebene.) ; Detaillierte Attributierungen werden üblicherweise in der Datenarchitektur nicht vorgenommen.

121

3

Lösungen und Lösungsskizzen ‰ Im Mittelpunkt der Architekturentwicklung stehen die Anforderungen aus Managementsicht. Eine Abstimmung mit der operativen/externen Datenwelt ist nicht erforderlich, ja sogar kontraproduktiv. (Nein, auf jeden Fall ist ein Abgleich mit der operativen/externen Datenwelt erforderlich, da ansonsten „Luftschlösser“ konzipiert werden, die aus den verfügbaren operativen Daten nicht abbildbar sind.) ; Die Architektur dient den einzelnen Projektdatenmodellen als Referenzstruktur, deren sie sich zu bedienen haben. ; Das gesamte dispositive Datenmodell wird über den Zeitverlauf durch die Generierung einzelner Projektdatenmodelle erschaffen. Aufgabe B-5-9: BI-Projektportfolio Ein BI-Projektportfolio ist eine Dokumentation gemeinsam koordinierter, untereinander abzuwägender BI-Projekte zur Bestimmung zeitlicher und budgetorientierter Präferenzen. Hauptkriterium für hohe Priorisierung (theoretisch): x

Das Projekt besitzt ein hohes Potential kritische Erfolgsfaktoren positiv zu beeinflussen.

Relevante Nebenbedingungen, die die Reihenfolge beeinflussen:

122

x

Existenz von Macht-/Fachsponsoren, hohe Akzeptanz der Fachseite für ein bestimmtes Themengebiet.

x

Hoher Integrationsgrad (technisch/organisatorisch) und somit hohe Komplexität der Systementwicklung.

x

Fehlendes betriebliches Know-how im eigenen Hause und somit Zwang externer Unterstützung (Kosten, Risiken).

x

Großer Aufwand und lange Entwicklungszeit und damit verbundene potentielle Akzeptanzprobleme auf der Fachseite.

x

Zwingende betriebliche Reihenfolge, weil beispielsweise zunächst geplante operative Systementwicklungen fertig gestellt werden müssen.

3.5 x

Entwicklung integrierter BI-Anwendungssysteme

Rechtliche Vorgaben, z.B. im Rahmen des Risikomanagements oder Basel II.

Aufgabe B-5-10: Unternehmenskultur und Business Intelligence Unter Unternehmenskultur wird die Gesamtheit gemeinsamer Werte, Normen und Einstellungen verstanden, die ein Muster bilden, ein sog. Weltbild. Dieses Weltbild konkretisiert sich in Verhaltensstandards, deren expliziter Anteil als ManagementPhilosophie oder in Form von Führungsgrundsätzen operationalisiert werden kann. Unternehmenskultur ist somit strukturbestimmend, keinem raschen Wandel unterworfen und basiert auf Traditionen und gesellschaftlichen Paradigmen. Im Unternehmen determiniert sie insbesondere die Form der Kommunikations- und Kooperationsbeziehungen, die Verteilung von Macht und Status und die Kriterien für den Einsatz von Anreizen. Die Entwicklung und der Einsatz von BI-Anwendungssystem tangiert diesen Bereich erheblich. Die Schaffung von Transparenz im Managementbereich kann zu erheblichen Implikationen führen, wie der Verletzung von Vertrauensstrukturen, der Torpedierung von Führungsgrundsätzen (z.B. Konzepten wie Management-by-Objectives) oder der Missachtung organisatorischer Zuständigkeiten. Unternehmenskulturelle Aspekte sind daher im gesamten Lebenszyklus von BI-Anwendungssystemen zu thematisieren. Es ist eine optimale Lösung zu finden, die einerseits das Potential der IT ausschöpft, aber auf der anderen Seite nicht zu Problemen mit gewachsenen, etablierten Strukturen und somit zur Ablehnung (mangelnder Akzeptanz) durch die Betroffenen führt. Aufgabe B-5-11: Reengineering der Makroebene x

Das Reengineering der Makro-Ebene bezeichnet die im Zeitverlauf erforderlich werdende Überarbeitung des Rahmenkonzeptes aufgrund von Veränderungen interner/externer Randbedingungen (technisch, organisatorisch, rechtlich).

x

Die Durchführung von Controlling-Aktivitäten der MakroEbene erfolgt zu definierten Zeitpunkten oder bei außergewöhnlichen Anlässen in Form von sog. Controllingpunkten. 123

3

Lösungen und Lösungsskizzen x

Die Abweichungen zwischen der existierenden und der anzustrebenden Ausgestaltung der Rahmenplanung (gemessen an den Controllingpunkten) initiiert eine Entscheidung über ein Reengineering der Makro-Ebene.

x

Anschließend werden Verträglichkeitsanalysen zwischen den bereits realisierten BI-Anwendungssystemen und der überarbeiteten Rahmenplanung durchgeführt und die BIAnwendungssysteme ggf. angepasst. (Controllingpunkte zur Abstimmung zwischen Mikro- und Makro-Ebene.)

Aufgabe B-5-12: BI-Support Eine organisatorische Etablierung ist erforderlich, da x

im BI-Kontext keine endgültigen, zeitstabilen Lösungen erarbeitet werden (zeitlich unbeschränkte Daueraufgaben, BI als Prozess),

x

die Aufgabenbündel strategische Bedeutung besitzen (BI besitzt elementare Bedeutung für den Unternehmenserfolg),

x

die Aufgaben eine dauerhaft ausgeprägte Koordination verlangen (meist ist eine ständige enge Abstimmung zwischen dem Management, den Fachbereichen und den ITAbteilungen erforderlich).

Aufgabe B-5-13: Mikro-Ebene Welche der Aussagen (ist) sind korrekt? ; Die Mikro-Ebene konkretisiert als Projektebene die Entwicklungs- und die einsatzbegleitenden ReengineeringAktivitäten der jeweiligen BI-Anwendungssysteme des in der Makro-Ebene definierten BI-Portfolios. ; Projekt-Datenmodelle der Mikro-Ebene determinieren die jeweils zu implementierenden ETL-Prozesse des entsprechenden BI-Anwendungssystems, sofern die Daten nicht durch andere, bereits entwickelte BI-Anwendungssysteme im DWH verfügbar sind. ‰ Die ETL-Prozesse sind Bestandteil des jeweiligen BIAnwendungssystems und werden nach Außerdienststellung des BI-Anwendungssystems ebenfalls eliminiert. (Falsch. Nach Außerdienststellung eines BI-Anwendungs124

3.5

Entwicklung integrierter BI-Anwendungssysteme

systems müssen i.d.R. die ETL-Prozesse erhalten bleiben, da diese Prozesse das Core DWH bedienen und die Daten dort auch von anderen BI-Anwendungssystemen genutzt werden.) ; In einer üblichen Hub-and-Spoke-Architektur werden durch die Einzelprojekte sowohl die Data Marts als auch Ausschnitte des Core DWH systemtechnisch umgesetzt. ‰ Bei Änderungen an BI-Anwendungssystemen ist in jedem Falle ein Reengineering-Zyklus erforderlich. (Falsch. Kleinere Änderungen werden im Rahmen von Anpassungszyklen durchgeführt und bedingen somit keinen dedizierten Reengineering-Zyklus.) ‰ Während eines erforderlichen Reengineering-Zyklusses kann das entsprechende BI-Anwendungssystem nicht genutzt werden. (Die Außerdienststellung des alten BI-Anwendungssystems erfolgt erst nach erfolgreichem Reengineering-Zyklus.) Aufgabe B-5-14: Entwicklung von BI-Anwendungssystemen Entwicklungs- und Reengineering-Prozesse weisen typische Projektcharakteristika auf, wie Einmaligkeit, Zusammensetzung aus Teilaufgaben, Interdisziplinarität, Konkurrenz um Betriebsmittel, Bestimmung von Dauer und Aufwand sowie der zeitlichen Begrenzung. Einzubinden sind x

Manager oder ihre unmittelbaren Vertreter, da sie als spätere Systembenutzer die grundlegenden Funktionalitäten, die Darstellungsformen und die Datensichten determinieren.

x

Fachbereiche, die als Datenlieferanten die semantische Qualität der in die dispositive Datenhaltung einfließenden Daten zu gewährleisten haben.

x

IT-Spezialisten, die die technische Implementierung sämtlicher Systemkomponenten durchführen.

x

Vertreter der Makro-Ebene, die die Koordination der Entwicklungs- und Reengineering-Aktivitäten mit den Vorgaben der Makro-Ebene verantworten.

125

3

Lösungen und Lösungsskizzen Aufgabe B-5-15: Reifegrad und BI-Entwicklungsprozesse Die Reduktion des Entwicklungsaufwandes wird durch Lerneffekte aufgrund der Erfahrungen bei der Entwicklung der Vorsysteme und der Konsolidierung/Konkretisierung des Rahmenkonzeptes bewirkt. Vor allem aber spielt der Reifegrad des Core DWH eine wesentliche Rolle bei der Aufwandsdegression für nachgelagerte Systementwicklungen. So können Nachfolgeprojekte auf Core-DWH-Strukturen vorgelagerter BIAnwendungssysteme zugreifen, wobei die Identifikation der geeigneten unternehmensinternen und -externen Datenquellen und die Implementierung von ETL-Prozessen und deren metadatengestützter Dokumentation entfallen kann.

Verständnisfragen (V) Aufgabe V-5-1: „Think big – start small“ Der Spruch „think big – start small“ ist irreführend, da er suggeriert, dass ein unternehmensweites BI-Konzept bereits mit kleinen Projekten (wenig Budget) gestartet werden kann, wobei der große Ansatz lediglich „gedanklich“ vorhanden sein muss. Ihre kritische Diskussion könnte folgende Argumentationspunkte beinhalten:

126

x

Die BI-Entwicklung ist grundlegend unterschiedlich von traditionellen Entwicklungsprozessen, da zeitgleich mit dem ersten BI-Anwendungssystem die Umsetzung einer zukunftssicheren BI-Infrastruktur zu initiieren ist, in deren Kontext Einzelsysteme hoch-integriert interagieren.

x

Ohne ein eigenständiges, in seinen Strukturen determiniertes Rahmenkonzept wird ein unternehmensweiter BI-Ansatz kaum erfolgreich zu entwickeln sein. Im Rahmenkonzept erfolgen die BI-Potentialplanung, die Erstellung der dispositiven Datenarchitektur, der Aufbau des BI-Projektportfolios, die Festlegung der Entwicklungsrahmenbedingungen und die Planung der technischen Infrastrukturen. Weiterhin sind im Rahmenkonzept Controllingaufgaben wahrzunehmen und die organisatorische Eingliederung des BI-Supports zu definieren.

3.5 x

Entwicklung integrierter BI-Anwendungssysteme

Das BI-Konzept ist stets ein strategisches Projekt und bedingt Fach-/Machtsponsoren, da für BI-Rahmenkonzepte nur sehr schwierig monetär bewertbare Wirtschaftlichkeitsanalysen durchgeführt werden können.

Aufgabe V-5-2: Evolutionäre Entwicklungsmodelle Charakteristika: x

Zum Projektstart wird auf eine vollständige Definition der Benutzeranforderungen an das Gesamtsystem verzichtet.

x

Eine neue Produktversion (Systemversion) entsteht durch die Erhebung der Anforderungen des nachfolgenden Teilsystems, dessen zyklische Umsetzung und die Verbindung mit den vorgelagerten Teilsystemen.

x

Die Systementwicklung beginnt mit der Umsetzung von Kern- bzw. Muss-Anforderungen.

x

Jede Ausbaustufe bedingt eine vollständige Anforderungsanalyse, einen vollständigen Entwurf und die Erstellung eines wartbaren Programmcodes (kein einfaches „Code and Fix“).

Einsatzbeispiel: Die Vorteile des evolutionären Modells sind die kurzen Auslieferungsrhythmen einsatzfähiger (Teil-)Systeme, wobei die Erfahrungen aus der frühzeitigen praktischen Anwendung einer Version neue Leistungsmerkmale prägen, die als geänderte Anforderungen in den nächsten Entwicklungsschritt eingehen. Einsatzgebiete der Entwicklungsmodelle sind daher in Bereichen mit schlecht antizipierbaren technischen/fachlichen Rahmenbedingungen zu sehen (Einsatz von Schlüsseltechnologien, nicht vorhersehbare Funktionalitäten und kaum antizipierbare Benutzerakzeptanz bzw. -präferenzen). Ein Beispiel für den Einsatz evolutionärerer VM ist der Bereich „Real-Time-Data-Warehousing für die Steuerung der Logistikkette eines Handelshauses mit RFID-Daten“. In diesem Gebiet sind weder Benutzeranforderungen noch das Technologieumfeld vollständig antizipierbar. Die möglichen (Teil-)Produkte des evolutionären Systementwicklungsprozesses könnten sein:

127

3

Lösungen und Lösungsskizzen x

Entwicklung eines ersten Teilsystems, das einen begrenzten Ausschnitt der Logistikkette unterstützt, z.B. die Kommissionierung im Warenverteilzentrum. Dies würde insbesondere den Aufbau eines „Real-time“-Data-Marts sowie die begrenzte Einführung von RFID im Warenverteilzentrum beinhalten.

x

Entwicklung und Anbindung eines Teilsystems zur Steuerung der Lieferlogistik zwischen Warenverteilzentrum und Filialen, bei gleichzeitigem Aufbau von Komponenten zum „Realtime“-Datenaustausch zwischen Filialen, Warenverteilzentrum und Logistikdienstleistern. Herausforderungen sind der organisationsübergreifende Datenaustausch und die Integration von Positionsdaten.

x

Entwicklung eines Teilsystems zur Steuerung der Lieferlogistik zwischen Warenverteilzentrum, Consolidator (für die Containerlogistik in den Häfen) und Herstellern – in diesem Teilprojekt kommt die Komplexität der Einbeziehung von Offshore-Partnern hinzu.

x

Integration von Sensordaten zur Überwachung und Analyse von Temperaturen und mechanischen Einwirkungen in den Lieferprozessen.

Aufgabe V-5-3: Entwicklung eines unternehmensweiten BI-Ansatzes Wie in der Aufgabenstellung verdeutlicht, soll eine unternehmensweite Hub-and-Spoke-Architektur entwickelt werden. Bei dieser „klassischen“ BI-Architektur sind ein Core DWH und davon abhängige Data Marts zu erstellen. Ihre kritische Diskussion könnte folgende Informationen beinhalten. Alternative 1: Orientierung am Wasserfall-Modell Charakteristika: Bei diesem Vorgehen erfolgt keine iterative Entwicklung einzelner Teilsysteme. Vielmehr wird das Gesamtsystem „aus einem Guss“ geplant und umgesetzt, wobei zunächst das komplette Core DWH entwickelt und anschließend die einzelnen Data Marts aufgesetzt werden.

128

3.5

Entwicklung integrierter BI-Anwendungssysteme

Pro: ƒ

Es wird eine konsistente Gesamtarchitektur der BI-Lösung aufgebaut.

ƒ

Die einheitliche Produktionsumgebung (Schnittstellen, Extraktionsroutinen etc.) erleichtert die technische Umsetzung.

Contra: ƒ

Die Implementierungsdauer wird lang sein.

ƒ

Änderungen in den fachlichen Anforderungen können während des Entwicklungsprozesses nur in sehr eingeschränktem Maße berücksichtigt werden.

ƒ

Es existiert die Gefahr des Akzeptanzverlustes, da den Endbenutzern (Kunden) erst spät lauffähige Systeme zur Verfügung gestellt werden können.

ƒ

Die Komplexität des Gesamtprozesses ist kaum beherrschbar.

ƒ

Es existiert die Gefahr einer „technisch“-orientierten Systementwicklung, da die Beteiligung der Endbenutzer sehr eingeschränkt ist.

Empfehlung: Nicht zu empfehlen. Diese Form der BI-Entwicklung wurde häufig in ersten Projekten der 1990er Jahre gewählt. Sie scheitert meist aus den o.a. Gründen. Alternative 2: Orientierung am evolutionären Modell Charakteristika: Bei diesem Ansatz werden zunächst Data Marts entwickelt, die anschließend mit einem aufzubauenden Core DWH unterlegt werden. Pro: ƒ

Sehr schnelle Entwicklung einsatzfähiger Lösungen für die Fachabteilungen.

ƒ

Der schnelle Erfolg sichert zunächst die Akzeptanz der Endbenutzer.

ƒ

Der schrittweise Entwicklungsprozess unterstützt die iterativen Lernprozesse der Teams im Umgang mit den Technologien, den Daten und dem Vorgehen. 129

3

Lösungen und Lösungsskizzen Contra: ƒ

Es existiert die Gefahr, dass Insellösungen entwickelt werden, da kein Rahmenkonzept die Entwicklungsprozesse koordiniert.

ƒ

Die Erstellung eines konsistenten Core DWH ist nach Entwicklung einzelner Data Marts kaum möglich, da i.d.R. ETL-Prozesse, Hierarchien und Aggregationsniveaus heterogen realisiert werden und die abgebildeten Konzepte nicht fachlich harmonisiert sind.

Empfehlung: Für das hier skizzierte Vorhaben nicht geeignet. Aufgabe V-5-4: Entwicklung einer BI-Lösung für das Controlling Da eine klare Entscheidung getroffen wurde, kein unternehmensweites BI-Konzept zu entwickeln, handelt es sich bei diesem Projekt um eine abteilungsspezifische Lösung. Demnach wird mit Werkzeugen aus dem DWH-Umfeld lediglich ein isoliertes System zur Optimierung einer Klasse von Problemstellungen aus einem Anwendungsbereich erstellt. Als erster Baustein eines unternehmensspezifischen Ansatzes eignet sich die Entwicklung in Ermangelung eines Rahmenkonzeptes und eines Core DWH somit nicht. Ihre Diskussion könnte folgende Argumente beinhalten: Architekturvorschlag: x

Es wird ein Data Mart erstellt, der direkt an operative/externe Datenhaltung angebunden wird.

x

Als Datenhaltungssystem kommt eine physikalisch mehrdimensionale oder relationale Datenbank in Frage, auf die Reporting- und OLAP-Werkzeuge aufsetzen können.

BI-Entwicklungsmodell:

130

x

Es wird ein inkrementelles Vorgehen vorgeschlagen, wobei bewusst kein dediziertes Rahmenkonzept entwickelt wird.

x

Die Projektleitung ist aufgrund der engen betriebswirtschaftlichen Fokussierung und der geringen technischen Komple-

3.5

Entwicklung integrierter BI-Anwendungssysteme

xität durch die Fachseite (aus dem Controlling) zu rekrutieren. x

In jedem Falle sollten für die Entwicklung und für die anschließende Wartung Spezialisten aus dem IT-Bereich eingebunden werden, damit eine professionelle Erstellung und ein anschließender Betrieb über den gesamten Systemlebenszyklus sichergestellt ist.

131

4

Literaturempfehlungen Die folgenden Literaturempfehlungen stellen keine vollständige Liste verfügbarer Bücher zum Themenbereich Business Intelligence dar. Vielmehr handelt es hier um Monografien und Sammelbände (keine produktspezifischen Werke) auch älterer Jahrgänge, in denen die beschriebenen Themenblöcke nach unserer Ansicht didaktisch gut aufbereitet und anwendungsorientiert vermittelt werden. Die Liste reflektiert den Stand vom November 2007. Referenzbuch für das vorliegende Arbeits- und Übungsbuch: Kemper, H.-G.; Mehanna, W.; Unger, C.: Business Intelligence: Grundlagen und praktische Anwendungen – Eine Einführung in die IT-basierte Managementunterstützung. 2. ergänzte Auflage, Wiesbaden 2006. Monografien Adamson, C.: Mastering Data Warehouse Aggregates – Solutions for Star Schema Performance. New York 2006. Bauer, A.; Günzel, H.: Data-Warehouse-Systeme – Architektur, Entwicklung, Anwendung. 2. überarbeitete und aktualisierte Auflage, Heidelberg 2004. English, L. P.: Improving data warehouse and business information quality. New York u.a. 1999. Gluchowski, P.; Gabriel, R.; Dittmar, C.: Management Support Systeme und Business Intelligence – Computergestützte Informationssysteme für Fach- und Führungskräfte. 2. vollständig überarbeitete Auflage, Berlin u.a. 2008. Han, J.; Kamber, M.: Data Mining – Concepts and Techniques. 2. Auflage, Amsterdam u.a. 2006. Hoberman, S.: Data Modeling Made Simple – A Practical Guide for Business & Information Technology Professionals, New York 2007.

133

4

Literaturempfehlungen Imhoff, C.; Galemmo, N.; Geiger, J. G.: Mastering Data Warehouse Design – Relational and Dimensional Techniques. New York 2003. Inmon, W. H.: Building the Data Warehouse. 4. Auflage, Indianapolis 2005. Inmon, W. H.: Building the Operational Data Store. 2. Auflage, New York u.a. 1999. Kimball, R.; Caserta, J.: The data warehouse ETL toolkit – Practical techniques for extracting, cleaning, conforming, and delivering data. Indianapolis 2004. Kimball, R.; Reeves, L.; Ross, M.; Thornthwaite, W.: The Data Warehouse Lifecycle Toolkit – Expert Methods for Designing, Developing, and Deploying Data Warehouses. New York u.a. 1998. Kimball, R.; Ross, M.: The data warehouse toolkit – The complete guide to dimensional modelling. New York u.a. 2002. Moss, L.; Atre, S.: Business Intelligence Roadmap – The Complete Project Lifecycle for Decision-Support Applications. Boston u.a. 2003. Thomsen, E.: OLAP Solutions – Building Multidimensional Information Systems. 2. Auflage, New York u.a. 2002. Sammelbände Chamoni, P.; Gluchowski, P. (Hrsg.): Analytische Informationssysteme – Business Intelligence-Technologien und Anwendungen. 3. vollständig überarbeitete Auflage, Berlin 2006. Hannig, U. (Hrsg.): Knowledge management and business intelligence. Berlin u.a. 2002. Maur, E. von; Winter, R. (Hrsg.): Data Warehouse Management – Das St. Galler Konzept zur ganzheitlichen Gestaltung der Informationslogistik. Berlin u.a. 2003. Mucksch, H.; Behme, W. (Hrsg.): Das Data-Warehouse-Konzept – Architektur, Datenmodelle, Anwendungen. 4. vollständig überarbeitete und erweiterte Auflage, Wiesbaden 2000.

134