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 <20) sog. Kern-Entitätstypen und Kern-Beziehungstypen zur Dokumentation der grundlegenden Informationsobjekte und 5

1

BI-Glossar deren Beziehungen untereinander. Die dispositve Datenarchitektur stellt somit den Bauplan des unternehmensspezifischen BIDatenmodells dar und dient als Referenzstruktur für den Aufbau BI-spezifischer Æ Projekt-Datenmodelle. Datenpool-Ansatz ist ein Vorläuferkonzept des Æ Data Warehouses (DWH). In Abgrenzung zum DWH werden die Daten bei einem Datenpool-Ansatz jedoch nicht betriebswirtschaftlich aufbereitet und in den Anwendungskontext der Managementunterstützung transformiert, sondern lediglich über Kopier- und Extraktionsvorgänge in physisch von den operativen/externen Quellen separierte Datenbanken überführt. Auf diese Weise wird zumindest die zeitliche Konsistenz der dispositiven Daten gesichert und die Beeinträchtigung der Performance operativer Systeme aufgrund einmaliger Kopier- und Extraktionsvorgänge reduziert. Decision Support Systems (DSS) sind interaktive, formelbasierte Systeme zur Unterstützung individueller Einzelentscheidungen oder zur Unterstützung spezieller Klassen von Entscheidungsaufgaben. DSS verfügen neben einer Dialogführung und einer Anwendungsunterstützung über eine Datenhaltung sowie über spezifische Modell- und Methodenbanken. Üblicherweise werden DSS heute mit komfortablen Tabellenkalkulationsprogrammen – oft MS-ExcelTM – umgesetzt. Ein typisches Einsatzgebiet ist die Investitionsrechnung, bei der Alternativinvestitionen mit verschiedenen Methoden der Investitionsbeurteilung unter Verwendung diverser Szenarien (best-case, worst-case) beurteilt werden. Delta-Historisierung ist eine Variante der Æ Historisierung, bei der ausschließlich die Daten aktualisiert werden, die sich im Zeitverlauf im operativen Datenkontext geändert haben. Um neben den neuen Datenausprägungen auch den Altdatenbestand auswertbar zu halten, kommen spezielle Verfahren mit Ladezeitstempeln und Gültigkeitsfeldern zum Einsatz. Dice ist eine Operation in einem Æ mehrdimensionalen Datenraum, bei der eine oder mehrere Dimensionen jeweils auf ausgewählte Ausschnitte von Elementen beschränkt werden. Der Name Dice leitet sich aus der gängigen graphischen Darstellung der Operation ab. Meist wird der dreidimensionale Würfel (Æ Cube) als Metapher des Æ mehrdimensionalen Datenraums verwendet, so dass bei Reduktion aller Dimension auf eine Menge von Elementen in der Tat ein Dice (eine kleiner Würfel) erzeugt wird.

6

1

BI-Glossar

Dimensionen beschreiben den Kontext der zu analysierenden Æ Fakten in einem Æ multidimensionalen Datenraum. Typische Dimensionen sind „Produkt“, „Kunde“ und „Zeit“. Drill-across ist eine Operation in einem Æ mehrdimensionalen Datenraum, bei der ein Wechsel zu anderen Würfeln (Æ Cube) auf der Basis strukturidentischer Dimensionstabellen erfolgt. Drill-down ist eine Operation in einem Æ mehrdimensionalen Datenraum, bei der ein aggregierter Wert schrittweise in die Bestandteile der darunter liegenden Hierarchieebenen aufgeschlüsselt wird. Die inverse Operation hat die Bezeichnung Æ Roll-up. Drill-through ist eine Operation in einem Æ mehrdimensionalen Datenraum, bei der ein Würfel (Æ Cube) im Rahmen einer vertikalen Recherche (Æ Drill-down) verlassen wird und Detaildaten aus vorgelagerten operativen/dispositiven Datenhaltungssystemen recherchiert werden. E-Business bezeichnet die Durchführung einer, mehrerer oder aller Phasen (Informations-, Vereinbarungs- und Abwicklungsphase) von geschäftlichen Transaktionen mit Hilfe von Internettechnologien (TCP/IP-Protokollstack). Embedded BI ist ein Ansatz, bei dem BI-Funktionalitäten direkt in die operativen Systeme und deren Datenhaltung integriert werden. Die Einsatzgebiete reduzieren sich in diesem Gebiet eher auf klar abgrenzbare Entscheidungssituationen, die keine ausgeprägte Datenintegration mit anderen Anwendungskontexten und auch lediglich beschränkten Zugriff auf historisierte Datenbestände bedingen. Sinnvolle Einssatzszenarien liegen insbesondere im Bereich der Logistik, bei dem z.B. Fehlbestände Nachbestellungen initiieren, optimale Routenplanungen aufgrund aktueller Rahmenbedingungen durchgeführt oder Ausnahmeberichte aufgrund spezieller Prozesszustände angestoßen werden. End-to-End-Lösungen sind BI-Ansätze, die komplett mit Hilfe der abgestimmten Werkzeuge eines einzelnen Herstellers umgesetzt werden. Typische Produktfamilien, die vom Æ ETL-Prozess bis hin zum Æ Portal reichen, bieten z.B. die Unternehmen SAPTM, MicrosoftTM und SASTM an (Æ Best-of-Breed-Lösungen). Enterprise Application Integration (EAI) meint die Integration von heterogenen, autonomen Anwendungssystemen entlang der Wertschöpfungskette, wobei die Zusammenführung auf der Datenebene (Æ Operational Data Store), auf der Funktionsebene

7

1

BI-Glossar (Æ Service Oriented Architecture) oder auf der Präsentationsebene (Æ Portal) erfolgen kann. Enterprise Ressource Planning (ERP) sind integrierte ITSysteme zur Unterstützung der relevanten betrieblichen Funktionsbereiche wie Einkauf, Produktion, Vertrieb, Personal und Finanzwesen. ERP-Systeme bedienen sich einer zentralisierten Datenhaltung und ermöglichen auf diese Weise eine konsistente, integrative Abwicklung funktions- und bereichsübergreifender Geschäftsprozesse (Æ Legacy-Systeme). Entity Relationship Model (ERM) ist eine Methodik zur Erstellung semantischer (betriebswirtschaftlich-fachlicher) Modelle. Es besteht im Kern aus Entitätstypen zur Erfassung gleich strukturierter Entitäten (Objekte) und aus Beziehungstypen, die gleich strukturierte Beziehungen zwischen Entitäten der beteiligten Entitätstypen darstellen. Die Ursprünge des von Peter Chen entwickelten Verfahrens liegen in den 1970er Jahren. Im Verlaufe der Zeit wurde die Methodik fachlich erweitert und mit verschiedensten Notationen versehen. ETL-Prozess (Extraction, Transformation, Loading) bezeichnet das IT-gestützte Verfahren, mit dessen Hilfe operative Daten extrahiert, syntaktisch/semantisch transformiert und anschließend in die gewünschten Datenhaltungssysteme (Æ Operational Data Store, Æ Data Warehouse, Æ Data Mart) geladen werden (Æ Staging Area). Evolutionäres Entwicklungsmodell ist in Abgrenzung zum Æ evolutionären Prototyping ein eigenständiges, Æ iteratives Vorgehensmodell. Es besitzt eine klar definierte Vorgabe von Aktivitätenbündeln (Phasen), beinhaltet jedoch in Abgrenzung zum Æ inkrementellen Entwicklungsmodell keine Aktivitäten zur Entwicklung einer Gesamtarchitektur am Projektanfang. Einsatzgebiete für das evolutionäre Entwicklungsmodell sind innovative Anwendungsbereiche mit hoch dynamischen technischen und betriebswirtschaftlichen Rahmenbedingungen, die eine Konzeption einer angestrebten Gesamtarchitektur zu Anfang eines Entwicklungsprozesses unmöglich machen. So sind z.B. einige der in mobilen Reiseportalen eingesetzten Technologien – wie UMTS, mobile Agenten usw. – noch als Schlüsseltechnologien mit vielen Unwägbarkeiten einzuschätzen. Eine stabile Gesamtarchitektur eines iterativ zu entwickelnden Systems wäre in diesem Anwendungskontext zu Projektanfang somit nicht erstellbar. Evolutionäres Prototyping wird häufig als eigenständige Vorgehensweise dargestellt und meint die Ablösung des zeitlich be-

8

1

BI-Glossar

grenzten Entwicklungsprozesses sowie die konsequente Abkehr von projektorientierten Vorgehensweisen. Nicht zu Unrecht hat sich diese Art der Systemerstellung mit der Kritik auseinanderzusetzen, dass das zu entwickelnde System als dauerhaftes Provisorium weder über optimale Architekturen noch über geeignete Integrationspotentiale für neue Teilsysteme verfügt. Executive Information Systems (EIS) sind generierte Berichtssysteme für das Top-Management. Sie bedienen sich interner und externer, meist verdichteter quantitativer/qualitativer Daten und verfügen über eine komfortable, primär graphisch orientierte Benutzeroberfläche. Experimentelles Prototyping dient der Überprüfung der technischen Machbarkeit eines Systems, also der Erprobung der softund hardwaretechnischen Komponenten. Meist kommt das experimentelle Prototyping am Anfang des Projektes (bei innovativen Schlüsseltechnologien) oder zu Beginn der technischen Realisationsphase zum Einsatz, um Fehlentscheidungen im technischen Kontext zu vermeiden. Expert Systems (XPS) sind Systeme, die das Wissen menschlicher Experten in abgegrenzten, domänenspezifischen Anwendungsgebieten verfügbar machen sollen. Hierbei beschränkt sich die Integration nicht allein auf Fachwissen, sondern umfasst auch spezifisches Problemlösungswissen auf der Basis von Heuristiken, Vermutungen und Annahmen. Nach anfänglicher Euphorie in den 1980er Jahren hat sich mittlerweile die Meinung durchgesetzt, dass XPS in semi- oder schlecht-strukturierten Problemsituationen keine eigenständigen Entscheidungen treffen sollten, sondern lediglich wertvolle Hilfestellungen bei der Entscheidungsfindung anzubieten haben. Exploratives Prototyping bezeichnet eine Variante des Æ Prototyping, mit dessen Hilfe die Systemanforderungen (Requirements) in Kooperation mit den späteren Endbenutzern erhoben werden. In diesem Zusammenhang wird zunächst in aller Regel ein erster Prototyp mit den antizipierbaren fachlichen Funktionalitäten erarbeitet und in mehreren Zyklen mit den Endbenutzern verfeinert und abgestimmt, bis die Anforderungen an das spätere System vollständig definiert sind. Fact-Constellation-Schema ist eine Modellierungsvariante, bei der neben der originären Faktentabelle sog. aggregierte Faktentabellen gebildet werden, die verdichtete Fakten auf der Basis ausgewählter Stufen der Dimensionshierarchien beinhalten.

9

1

BI-Glossar Fakten sind die Kennzahlen in einem Æ multidimensionalen Datenraum, die in BI-Anwendungen analysiert werden. Sie werden über Æ Dimensionen spezifiziert. Filterung bezeichnet den Prozess der Datenextraktion aus den operativen Datenbeständen und die anschließende Bereinigung syntaktischer sowie inhaltlicher Defekte der extrahierten Daten (Æ Transformation). Freie Datenrecherchen sind Analysen, die mit Hilfe von Datenmanipulationssprachen (z.B. SQL, MDX) durchgeführt werden. Sie sind in aller Regel aufgrund ihrer Komplexität lediglich von versierten Benutzern (IT-Professionals oder sog. Power Usern) einsetzbar und finden daher im Endbenutzerbereich, also in den betriebswirtschaftlichen Fachbereichen, meist keine direkte Verwendung. Galaxie ist eine Kombination von zwei oder mehreren StarSchemata, bei denen die Faktentabellen über strukturidentische Dimensionstabellen mit einander verbunden sind. Generische Basissysteme sind Æ Analysesysteme, die als eigenständige Komponenten in umfassende BI-Lösungen integriert werden können. Zu den generischen Basissystemen gehören Æ freie Datenrecherchen, Æ Ad-hoc-Analysesysteme, Æ modellgestützte Analysesysteme und Æ Berichtssysteme. Granularität bezeichnet die Detaillierungsebene der abgelegten Daten innerhalb eines dispositiven Datenhaltungssystems (Æ Operational Data Store, Æ Data Warehouses oder Æ Data Mart). Harmonisierung bezeichnet den Prozess der syntaktischen und betriebswirtschaftlichen Abstimmung gefilterter Daten (Æ Filterung) und deren Anhebung auf die gewünschte Æ Granularität der dispositiven Datenhaltung ( Æ Operational Data Store, Æ Data Warehouses, Æ Transformation). Historisierung bezeichnet Konzepte, mit deren Hilfe Änderungen in Attributsausprägungen, Beziehungen und Entitäten im Zeitablauf dokumentiert werden können, um unterschiedliche fachliche Zustände auswertbar zu machen. Solche Änderungen sind vor allem in Dimensionstabellen relevant, bei denen im Zeitverlauf Attributsausprägungen (z.B. Adressenänderung eines Kunden) oder Strukturänderungen in Hierarchisierungen (z.B. Neugliederung von Regionen) vorkommen können. Da die Häufigkeit der Änderungen eher als gering einzustufen ist, wird im angelsächsischen Sprachgebrauch in diesem Zusammenhang häufig plakativ von „slowly changing dimensions“ gesprochen.

10

1

BI-Glossar

Gängige Formen der Historisierung sind Æ Snapshot-Historisierung und Æ Delta-Historisierung. H-OLAP meint Æ Analysesysteme, die sich als Hybridsysteme sowohl proprietärer, mehrdimensionaler Datenhaltungen (Æ MOLAP) als auch relationaler Datenhaltungen (Æ R-OLAP) bedienen. In aller Regel werden hierbei die hochverdichteten, vom Volumen daher meist überschaubaren Daten in proprietärer Technik (M-OLAP) abgelegt, die umfangreicheren Detaildaten meist in relationalen Datenbanken. Der Übergang zwischen den beiden Datenbanktechniken erfolgt während der Anwendung unter Beibehaltung der Benutzeroberfläche und ist somit benutzertransparent (also vom Endbenutzer nicht bemerkbar). Hub-and-Spoke-Architektur ist die Bezeichnung eines weitverbreiteten DWH-Ansatzes, der aus einem Æ Core Data Warehouse (Hub) und darauf aufsetzenden, also abhängigen Æ Data Marts (Spokes) besteht. Hypercube ist ein Synonym für Æ Cube. Durch das Präfix „Hyper“ wird signalisiert, dass der Analyseraum nicht auf die drei Dimensionen eines Würfels beschränkt ist. Inkrementelles Entwicklungsmodell ist deutlich komplexer als das Æ evolutionäre Entwicklungsmodell. Es sieht die Entwicklung einer Gesamtarchitektur vor. Die entsprechende Konzeption erfolgt aufgrund der technischen und betriebswirtschaftlichen Anforderungen an das spätere Gesamtsystem in den frühen Phasen des iterativen Systementwicklungsprozesses. Diese Gesamtarchitektur gibt somit den verbindlichen Rahmen für die iterative Entwicklung der zu integrierenden Module vor, deren Realisierung alle 3 bis 6 Monate zu neuen, in die Gesamtarchitektur einzubettenden Subsystemen führt. Einsatzgebiete für das inkrementelle Entwicklungsmodell sind Anwendungsgebiete mit vielen interagierenden Subsystemen, die zwar zeitlich verzahnt bzw. sequentiell entwickelt, jedoch in ihrer letzten Ausbauund Integrationsstufe weitestgehend antizipierbar sind. Unternehmensumfassende BI-Lösungen sind typische Anwendungsgebiete für das inkrementelle Entwicklungsmodell. Interaktive Reportplattformen sind Werkzeuge für die Berichtsdefinition und -erstellung. Hierfür wird eine Entwurfsumgebung angeboten, mit deren Hilfe Endbenutzer intuitiv Berichtsschablonen mit hohen inhaltlichen und grafischen Anforderungen aufbereiten können. Die Schablonen werden anschließend mit dispositiven Daten gefüllt, so dass auf diese Weise – je nach

11

1

BI-Glossar Anforderung und Umsetzung – periodische, aperiodische oder Ad-hoc-Berichte generiert werden. Iterative Vorgehensmodelle sind Æ Vorgehensmodelle, mit deren Hilfe angestrebte Systeme sukzessive – also Modul für Modul – entwickelt und in den operativen Einsatz gegeben werden. Sie zeichnen sich insbesondere durch die Integration wiederkehrender Entwicklungsabschnitte und durch eine konsequente Einbindung der Methode des Æ explorativen Prototyping aus, die als Kommunikationsmethodik zwischen Systementwicklern und späteren Systemnutzern eingesetzt wird. Zielsetzung iterativer Vorgehensmodelle ist es, den Auftraggebern möglichst schnell (meist binnen 3-6 Monaten) lauffähige Teilsysteme zur Verfügung stellen zu können, wobei die Summe der Teilsysteme jeweils die aktuelle Version des Systems darstellen (Versioning). Hauptvertreter iterativer Vorgehensmodelle sind das Æ evolutionäre Entwicklungsmodell und das Æ inkrementelle Entwicklungsmodell. Klassisches Data Warehousing ist ein Implementierungsansatz, bei dem sich das jeweilige Æ Analysesystem ausschließlich lesend der Daten des Data Warehouses bedient (Æ Data Warehousing). Konzeptorientierte Analysesysteme beziehen sich auf spezifische betriebswirtschaftliche Problemstellungen und bilden als parametrisierbare Standardlösungen betriebswirtschaftlich etablierte Ansätze ab. Ein typischer Vertreter ist hierbei die Æ Balanced Scorecard. Legacy-Systeme sind Alt-Systeme einer historisch gewachsenen IT-Infrastruktur. Meist stellen sie isolierte Lösungen für spezielle Anwendungskontexte dar (Insellösungen), die untereinander ausschließlich über komplexe Schnittstellen kommunizieren können (Æ Enterprise Resource Planning). Management Information Systems (MIS) werden begrifflich unterschiedlich abgegrenzt. Im deutschsprachigen Bereich ist es üblich, unter MIS generierte berichtsorientierte Analysesysteme zu verstehen, die sich primär interner, operativer Daten bedienen und vom Middle- und Lower-Management für die Planung, Steuerung und Kontrolle der operativen Wertschöpfungskette verwendet werden. Management Support Systeme (MSS) ist eine Sammelbezeichnung für das Konglomerat von Informations- und Kommunikationssystemen der IT-basierten Managementunterstützung. Der

12

1

BI-Glossar

Begriff basiert auf Überlegungen von Scott Morton (MIT) in den frühen 1980er Jahren und ist – vor allem in der wissenschaftlichen Szene – auch heute noch gebräuchlich, wird jedoch zunehmend von der aktuellen Begrifflichkeit Æ Business Intelligence verdrängt. Mehrdimensionaler Datenraum ist ein durch Fakten (Measures), Dimensionen und Hierarchisierungen definierter Analyseraum. So beschreibt beispielsweise die Recherchemöglichkeit des Umsatzes (Faktum) nach Produkten, Regionen und Kunden (Dimensionen) und den entsprechenden Dimensionsaggregationen (Hierarchisierungen) nach Produktklassen, Gebieten und Kundengruppen einen dreidimensionalen Datenraum. In der Praxis sind Analyseräume mit bis 10 Dimensionen üblich, wobei hier nicht technische Restriktionen, sondern die betriebswirtschaftliche Sinnhaftigkeit die Anzahl der Dimensionen beschränkt. Metadaten sind Daten über Daten und dienen der Beschreibung der Bedeutung und der Eigenschaften von Inhalten und Prozessen innerhalb der BI-Datenhaltungskomponenten (Æ Operational Data Store, Æ Data Warehouse, Æ Data Mart). So werden mit Hilfe von Metadaten Informationen über Zugriffsberechtigungen, betriebswirtschaftliche Kennziffern, Dimensionshierarchisierungen, Transformationsprozesse, Quellsysteme und den jeweiligen fachlich verantwortlichen Mitarbeitern abgelegt (Æ Common Warehouse Metamodel). Metadaten-Management bezeichnet die Verwaltung von Metadaten und erlaubt das Generieren, Modifizieren, Administrieren und Löschen von Æ Metadaten der unternehmensspezifischen BI-Lösungen. Es ist leicht nachvollziehbar, dass bei Æ End-toEnd-Lösungen zentralisierte Ansätze des Metadaten-Managements umgesetzt werden können, während bei Æ Best-of-BreedLösungen aufgrund der technischen Heterogenität häufig dezentralisierte Ansätze Einsatz finden, wobei der Austausch der Metadaten zwischen den einzelnen Komponenten mit Hilfe von Schnittstellen umgesetzt wird. Eine Kombination aus beiden oben angeführten Ansätzen stellt das föderierte Metadaten-Management dar. Bei diesem Ansatz existiert neben den dezentralen Metadaten-Systemen ein zentrales Metadaten-Repository, das als zentrale Stelle den Austausch der Metadaten über standardisierte Schnittstellen bewerkstelligt (Æ Common Warehouse Metamodel).

13

1

BI-Glossar Modellgestützte Analysesysteme weisen eine ausgeprägte algorithmische oder regelbasierte Ausrichtung auf. Zu ihrer Klasse gehören Æ Decision Support Systems, Æ Expert Systems und das Æ Data Mining. M-OLAP basiert auf proprietären, also herstellerabhängigen, mehrdimensionalen Datenhaltungssystemen. Diese Datenbanken werden für die Analysen in Æ mehrdimensionalen Datenräumen optimiert, sind jedoch im Gegensatz zu relationalen Strukturen (Æ R-OLAP) nicht standardisiert (Æ OLAP). Normalisierung bezeichnet eine Vielzahl von Regeln, um Datenbestände in redundanzärmere bzw. redundanzfreie Strukturen zu überführen. Üblicherweise gilt eine relationale Datenstruktur als voll-normalisiert, wenn sie sich in der dritten Codd´schen Normalform befindet. (Æ 1. Normalform, Æ 2. Normalform, Æ 3. Normalform, Æ Boyce-Codd-Normalform, Æ 4. und 5. Normalform). OLAP ist die Abkürzung für Online Analytical Processing und meint ein Æ Ad-hoc-Analysesystem in Æ mehrdimensionalen Datenräumen. Je nach Grad der Benutzerführung können freie OLAP-Analysesysteme und geführte OLAP-Analysesysteme unterschieden werden, wobei sich der Rechercheraum bei geführten Analysen auf antizipierte Analysepfade beschränkt. Je nach technischer Umsetzung wird zwischen Æ R-OLAP, Æ M-OLAP und Æ H-OLAP unterschieden. OLTP steht für Online Transaction Processing und bezeichnet operative IT-Anwendungen, bei denen sich mehrere Benutzer derselben Systeme und Datenbestände bedienen, wie z.B. bei Auskunfts-, Buchungs- und Bestellsystemen. Operational Data Store (ODS) speichert aktuelle transaktionsorientierte, semantisch und syntaktisch abgestimmte Daten aus verschiedenen Quellsystemen und stellt sie für spezielle Anwendungs- und Auswertungszwecke bereit, wobei in aller Regel keine ausgeprägte Historienbildung der Daten erfolgt. Ein ODS kann eine Vorstufe eines Æ Data Warehouses für den BI-Kontext darstellen und/oder als konsistente Datenquelle geschäftsprozessorientierter Anwendungssysteme fungieren, wobei das ODS in diesem Falle eine Lösungsvariante im Rahmen des Æ Enterprise Application Integration darstellt. Partitionierte Dimensionstabelle ist eine Dimensionstabelle, die lediglich Teile der Gesamthierarchie einer Dimension enthält und somit als kleine Tabelle bei Abfragen auf verdichteten Da-

14

1

BI-Glossar

tenstrukturen (Æ Fact-Constellation-Schema) zu kürzeren Antwortzeiten führt. Pivotierung ist eine Operation in einem Æ mehrdimensionalen Datenraum, bei der der Würfel (Æ Cube) gedreht wird, so dass andere Dimensionen sichtbar werden. Das bedeutet, dass die Fakten des Würfels anhand einer anderen Kombination aus Dimensionen aufgeschlüsselt werden (z.B. Kunde-Artikel statt Kunde-Zeit). PMML (Predictive Model Markup Language) ist ein auf XML basierender Standard zur Beschreibung und zum Austausch von Analysemodellen des Æ Data Mining. Portal bezeichnet ein System, das als Web-Site einen zentralen Zugriff auf personalisierte Inhalte und Anwendungen gewährleistet. Es ermöglicht durch Single Sign-On und durch anpassbare, homogene Benutzeroberflächen einen komfortablen Zugang zu heterogenen Anwendungssystemen. Es bietet somit in seiner Ausprägung als BI-Portal einen einheitlichen Zugriff auf sämtliche BI-Subsysteme. Projekt-Datenmodelle sind projektspezifische Verfeinerungen von Teilen einer Æ Datenarchitektur. Die Entwicklung eines BIProjekt-Datenmodells konkretisiert somit einen Ausschnitt der dispositiven Æ Datenarchitektur und determiniert die jeweils zu implementierenden Prozesse der Æ Transformation sowie die physischen Strukturen der BI-Datenhaltungskomponenten. Prototyping meint das Erstellen von Prototypen, also das Erarbeiten von Mustern mit allen wesentlichen Eigenschaften eines geplanten Produktes. Im IT-Kontext werden Æ experimentelles Prototyping, Æ exploratives Prototyping und Æ evolutionäres Prototyping unterschieden. Real-time Data Warehousing ist die Anbindung der Æ Analysesysteme an aktuelle, transaktionsorientierte Daten, die zeitgleich zur operativen Datenhaltung im Data Warehouse verfügbar gemacht werden (Æ Data Warehousing). R-OLAP basiert auf Æ relationalen Datenbanken. In diesen Fällen sind die Daten in aller Regel in performanceoptimierten Strukturen abgelegt, wobei das Æ Star-Schema und das Æ Snowflake-Schema die bekanntesten Varianten der relationalen Modellierung Æ mehrdimensionaler Datenräume darstellt (Æ OLAP). Roll-up ist eine Operation in einem Æ mehrdimensionalen Datenraum, bei der Werte einer Hierarchieebene schrittweise zu 15

1

BI-Glossar den darüber liegenden Verdichtungsstufen aggregiert werden. Die inverse Operation hat die Bezeichnung Æ Drill-down. Sequentielle Vorgehensmodelle sind traditionelle Vorgehensmodelle, die sich durch eine mehr oder weniger streng sequentielle Ablauffolge der einzelnen Phasen auszeichnen. Frühe Konzepte reichen bis in die 1960er Jahre zurück und ermöglichten erstmalig die Darstellung eines klar definierten Entwicklungsprozesses. Ein bekannter Vertreter ist das sog. Wasserfallmodell, das auch noch heute in vielfältigen Varianten eingesetzt wird. Service Oriented Architecture (SOA) ist ein Konzept für eine verteilte Informationsarchitektur, bei der gekapselte, anwendungsnahe Dienste von Anbietern angekündigt, von Nachfragern gesucht und aufgerufen werden können. So wären z.B. Kreditwürdigkeitsprüfungen, die von externen Organisationen angeboten werden, über SOA zu recherchieren und über standardisierte Schnittstellen direkt in IT-Systeme integrierbar (Æ Web Services). Slice ist eine Operation in einem Æ mehrdimensionalen Datenraum, bei der durch Beschränkung von Dimensionen auf Einzelwerte der Rechercheraum begrenzt wird. Der Name Slice leitet sich aus der gängigen graphischen Darstellung der Operation ab. Meist wird der dreidimensionale Würfel (Æ Cube) als Metapher des Æ mehrdimensionalen Datenraums verwendet, so dass bei Reduktion einer Dimension auf einen Wert in der Tat ein Slice (eine Scheibe) des Würfels erzeugt wird. Snapshot-Historisierung ist eine Variante der Æ Historisierung, bei der – unabhängig ob geändert oder nicht – sämtliche Datensätze im Rahmen eines Aktualisierungslaufes an die bestehenden Datensätze angehängt werden. Zur Kennzeichnung der aktuellen Datensätze kommen spezielle Verfahren mit Ladezeitstempeln und Gültigkeitsfeldern zum Einsatz. Snowflake-Schema ist eine Variante der performanceoptimierten, relationalen Datenmodellierung in Æ mehrdimensionalen Datenräumen. Die Abgrenzung des Konzeptes wird in der Literatur kontrovers diskutiert. Im Allgemeinen wird jedoch davon ausgegangen, dass Snowflake-Schemata als Konglomerate verschiedener Optimierungsansätze zu verstehen sind. So finden bei der Snowflake-Modellierung häufig Ansätze zur Bildung von Æ Fact-Constellation-Schemata und Æ partitionierten Dimensionstabellen Verwendung. Der Begriff Snowflake-Schema bezeichnet die optische Anmutung des fertiggestellten Modells, das bei ge-

16

1

BI-Glossar

schickter Anordnung aller Tabellen an eine Schneeflocke erinnert. Staging Area bezeichnet einen Datenbereich, in dem extrahierte Daten aus operativen/externen Quellen temporär zwischengespeichert werden, um dort bereinigt und transformiert werden zu können (Æ Data Cleansing). Anschließend werden sie in die Zieldatenbank (Æ Operational Data Store, Æ Data Warehouse, Æ Data Mart) geladen (Æ ETL-Prozess). Star-Schema bezeichnet eine Datenmodellierungsvariante Æ mehrdimensionaler Datenräume auf der Basis des relationalen Modells. Grundsätzlich besteht ein Star-Schema aus einer Faktentabelle mit informationstragenden Attributen (z.B. Umsatz, Kosten) und einem Verbundschlüssel, der sich aus den Schlüsseln der involvierten Dimensionstabellen zusammensetzt. Die Dimensionstabellen repräsentieren die Auswertungskategorien und beinhalten in aller Regel auch die Hierarchie der Auswertungsdimensionen. Die Bezeichnung Star-Schema lässt sich aus der sternförmigen Anordnung der Dimensionstabellen um die im Mittelpunkt stehende Faktentabelle ableiten. Strukturierte Daten verfügen im Gegensatz zu Æ unstrukturierten Daten über eine IT-spezifische interne Struktur. Zu dieser Gruppe gehören vor allem numerische Daten, die in Datenbanksystemen abgelegt werden. Aber auch mit Metadaten versehene und morphologisch aufbereitete Texte (Æ Text Mining) können zu den strukturierten Daten gezählt werden, wobei diese Kategorien zur Abgrenzung numerischer Daten häufig auch als semistrukturierte Daten bezeichnet werden. Systemlebenszyklus (SLZ) eines BI-Systems beinhaltet sämtliche Entwicklungs- sowie Betriebs- und Wartungsaktivitäten von der Initiierung bis zur Außerdienststellung eines BI-Anwendungssystems (Æ Total Cost of Ownership). Text Mining bezeichnet – in Anlehnung an Æ Data Mining – die automatisierte Entdeckung neuer, nicht trivialer Informationen aus Texten. In einer engen Auslegung des Begriffes wird hierbei ausschließlich die direkte Analyse des aufbereiteten Textes verstanden. Die weite Auslegung umfasst zusätzlich den Prozess der Textdatenaufbereitung, also die Überführung unstrukturierter Texte (Æ unstrukturierte Daten) in maschinenlesbare, morphologisch abgestimmte, strukturierte Texte. Total Cost of Ownership (TCO) eines BI-Systems bezeichnet die Summe sämtlicher Kosten (budgetierten/nicht-budgetierten), 17

1

BI-Glossar die es im Laufe seines Æ Systemlebenszyklus verursacht. Neben den Anschaffungs- und Entwicklungskosten sind somit auch Betriebs-/Administrationskosten sowie Qualifikations- und Schulungskosten für die Höhe des TCO relevant. Transformation bezeichnet den für die betriebswirtschaftliche Interpretation der operativen Daten erforderlichen Gesamtprozess, der sich aus den Sub-Prozessen der Æ Filterung, Æ Harmonisierung, Æ Aggregation und Æ Anreicherung zusammensetzt. Unstrukturierte Daten besitzen im Gegensatz zu Æ strukturierten Daten keine IT-spezifische interne Struktur und sind ohne Aufbereitung DV-technisch nicht analysierbar. Typische Beispiele für unstrukturierte Daten sind Dokumente wie Briefwechsel, Geschäftsberichte, Aufstellungen oder Webseiten (Æ Text Mining). Vorgehensmodelle steuern den arbeitsteiligen Prozessablauf der Systementwicklung und des Systemeinsatzes. Sie bestimmen somit die durchzuführenden Aktivitäten, die abzuarbeitende Reihenfolge der Aktivitäten, die Zuordnung der Aktivitäten zu Rollen und deren Trägern sowie die Ergebnisse der Aktivitäten im gesamten Æ Lebenszyklus der IT-Anwendung. Zur Beherrschung der Komplexität werden die durchzuführenden Aktivitäten mit Hilfe von Meilensteinen (Milestones) überprüft und zu sinnvollen Phasen (Aktivitätenbündeln) zusammengefasst. Hierbei werden von den Vorgehensmodellen die jeweiligen Phasenziele bestimmt, die erwarteten Ergebnistypen anhand von Mustern beschrieben sowie Methoden, Verfahren, Richtlinien und (teilweise auch) Werkzeuge vorgegeben. Im Allgemeinen werden traditionelle, Æ sequentielle Vorgehensmodelle und Æ iterative Vorgehensmodelle unterschieden. Web Services dienen der webbasierten Umsetzung Æ Service Oriented Architectures mit Hilfe von Standard-InternetProtokollen. Meist kommen die Protokolle UDDI für die Umsetzung des Verzeichnisdienstes, WSDL zur Beschreibung der Dienste und SOAP zur Kommunikation (zum Aufruf) des Services zum Einsatz. Wissensmanagement bezeichnet die Summe aller organisatorischen und technischen Maßnahmen zur Speicherung, Dokumentation, Qualitätssicherung und Distribution betrieblichen Wissens. Eine enge Beziehung zwischen Æ Business Intelligence und Wissensmanagement ist nahe liegend, da BI-Analysen einerseits betriebliches Wissen generieren und somit Input für das Wissensmanagement liefern. Anderseits ist es häufig sinnvoll, BI-

18

1

BI-Glossar

Analysen um Bestände des Wissensmanagements anzureichern, um aussagefähige Interpretationen von BI-Analyseergebnissen zu ermöglichen. XBRL (eXtensible Business Reporting Language) basiert auf XML und dient als standardisierte Auszeichnungssprache für die Erstellung elektronischer Dokumente im Bereich der externen und internen Rechnungslegung.

19

2

Übungsaufgaben

Der zweite Block beinhaltet die Übungsaufgaben. Es werden zwei Typen von Fragen unterschieden. Basisfragen (B) dienen der Überprüfung des Grundlagenwissens und lassen sich direkt aus den Inhalten des jeweiligen Lehrbuchkapitels beantworten. Verständnisfragen (V) überprüfen, ob das in den jeweiligen Kapiteln des Lehrbuchs vermittelte Faktenwissen untereinander vernetzt und fallspezifisch zur Lösung von Problemstellungen herangezogen werden kann.

2.1

Business Intelligence — Begriffsabgrenzung und Ordnungsrahmen Basisfragen (B) Aufgabe B-1-1: Historische Entwicklung IT-basierter Managementunterstützung Erläutern Sie die Historie IT-basierter Managementunterstützung. Beziehen Sie hierbei explizit Stellung zum Begriff Management Support Systems (MSS). Aufgabe B-1-2: Business Intelligence – Erste Begriffsdeutungen Woher stammt der Begriff „Business Intelligence“ und wie hat er sich in Praxis und Wissenschaft etabliert?

21

2

Übungsaufgaben Aufgabe B-1-3: E-Business und grundlegende Systeme der Wertschöpfung Was wird unter E-Business verstanden? Erläutern Sie in diesem Zusammenhang die Begriffe „ERP“, „E-Procurement“, „SCM“ und „CRM“. Aufgabe B-1-4: Identifikation von BI-Anwendungssystemen Welche der folgenden Systeme sind Ihrer Ansicht nach üblicherweise keine BI-Anwendungssysteme? ‰

Reisekostenabrechnung

‰

Balanced Scorecard

‰

Debitorenbuchhaltung

‰

Call-Center-Steuerung mit ACDS (Automated Call Distribution System)

‰

Konzernkonsolidierung

‰

Vertriebscontrolling

‰

Lagerhaltungsmanagement

‰

Analytisches CRM

‰

Workflow-Management für die Verarbeitung von Geschäftsdokumenten

Verständnisfragen (V) Aufgabe V-1-1: Management Support Systems und Business Intelligence Ist es Ihrer Meinung nach sinnvoll, den etablierten Begriff "Management Support Systems“ durch die neue Bezeichnung „Business Intelligence“ abzulösen? Aufgabe V-1-2: Business Intelligence als unternehmensspezifische Lösung Erläutern Sie, warum BI nicht als Produkt käuflich erwerbbar, sondern stets unternehmensindividuell zu implementieren ist.

22

2.2

2.2

Datenbereitstellung für BI-Konzepte

Datenbereitstellung für BI-Konzepte Basisfragen (B) Aufgabe B-2-1: Operative und dispositive Datenhaltung Welche der folgenden Eigenschaften sind charakteristisch für dispositive Datenhaltung? ‰

Handhabung paralleler Schreibzugriffe durch eine Vielzahl von Benutzern.

‰

Dominanz zeitpunktbezogener Datenhaltung.

‰

Primär Ergänzung statt Überschreiben bestehender Daten.

‰

Überwiegend Vorhaltung aggregierter Daten.

‰

Ausrichtung ausschließlich auf strategische Fragestellungen.

‰

Zielsetzung: Management- und Entscheidungsunterstützung.

‰

Datenhaltung wird auf Basis von Themen bzw. Anwendungsgebieten strukturiert und modelliert.

‰

Abfragen (Queries) sind im Wesentlichen im Voraus bekannt; die Datenhaltung kann entsprechend optimiert werden.

‰

Große Bedeutung historischer Daten.

Aufgabe B-2-2: Grenzen der Nutzung operativer Datenbestände für die Managementunterstützung Nennen Sie schwerwiegende Probleme, die bei einem direkten Zugriff managementunterstützender Anwendungen auf die Datenbestände operativer Transaktionssysteme auftreten können. Aufgabe B-2-3: Data-Warehouse-Definition William H. Inmon stellt in seiner Data-Warehouse-Definition vier Merkmale in den Mittelpunkt. Welche sind dies? x

___________________________

x

___________________________ 23

2

Übungsaufgaben x

___________________________

x

___________________________

Aufgabe B-2-4: Zentrale und dezentrale Data-Warehouse-Architekturen Nennen Sie wesentliche Vorteile einer zentralen DataWarehouse-Architektur gegenüber einem dezentralen Ansatz mit isoliert entwickelten und betriebenen Data Marts. Aufgabe B-2-5: Komponenten für die dispositive Datenhaltung Welche Typen von Datenhaltungssystemen kommen heutzutage für die Ablage dispositiver Daten zum Einsatz? Aufgabe B-2-6: Operational Data Stores (ODS) Markieren Sie, welche der folgenden Aussagen korrekt sind. ‰

Bei Einsatz eines ODS ist kein Core DWH mehr erforderlich.

‰

Auf ein ODS kann auch schreibend zugegriffen werden.

‰

Ein ODS wird zeitnah aktualisiert.

‰

Auf ein ODS greifen oftmals auch operative Systeme zu.

‰

In einem Data Warehouse werden Daten üblicherweise auf Transaktionsebene vorgehalten, in einem ODS üblicherweise in aggregierter Form.

‰

In einem ODS werden die Daten üblicherweise nicht dauerhaft hinterlegt.

‰

In einem ODS werden die Daten nicht subjektbezogen vorgehalten.

‰

Ein ODS ist besonders für Einsatzszenarien geeignet, in denen Daten in „Real-time“ bereitgestellt werden müssen.

Aufgabe B-2-7: Transformationsschritte Welche Schritte werden im Rahmen der Transformation operativer in dispositive Daten notwendig?

24

2.2

Datenbereitstellung für BI-Konzepte

Aufgabe B-2-8: Bereinigungsaktivitäten Nennen Sie Beispiele für Fälle, in denen die folgenden Arten von Bereinigungsaktivitäten notwendig sind: 1) Automatische Erkennung und Korrektur 2) Automatisierbare Erkennung und manuelle Korrektur 3) Manuelle Erkennung und Korrektur Aufgabe B-2-9: Harmonisierung der Syntax Unterscheiden Sie Fälle, bei denen im Rahmen der Integration heterogener Datenquellen eine Harmonisierung der Syntax erforderlich wird. Aufgabe B-2-10: Beispiele für Aufgaben im Bereich der Datentransformation Nehmen Sie eine paarweise Zuordnung der Beispiele (links) zu den entsprechenden Aufgabenstellungen im Bereich der Datentransformation (rechts) vor: 1. Im Kostenrechnungsmodul sind die Fixkosten der einzelnen Filialen pro Monat, im Warenwirtschaftssystem die Deckungsbeiträge pro Produkt, Kunde, Tag und Filiale hinterlegt. Es sollen Filialergebnisse analysiert werden.

a. Filterung – automatisierbare Erkennung und automatisierbare Korrektur

2. Im CRM-System wird der Kunde in einem Attribut „PARTNER“ geführt, im ERPSystem werden Kunden als „CUSTOMER“ bezeichnet. Die Dateien sollen zusammengeführt werden.

b. Filterung – automatisierbare Erkennung und manuelle Korrektur

3. Identifizierender Schlüssel eines Artikels ist im Warenwirtschaftssystem eine EANNr., im PPS-System die Seriennummer.

c. Harmonisierung der Granularität

25

2

Übungsaufgaben 4. Im „Nettoerlös“ sind im neu akquirierten Unternehmen mengenabhängige Vertriebseinzelkosten der Erzeugnisse (z.B. Frachten) bereits grundsätzlich mit eingerechnet, in allen anderen Konzerntöchtern jedoch nicht.

d. Eliminierung von Schlüsseldisharmonien

5. Für das neue Call-Center in Cottbus liegen aufgrund eines Defekts für den Monat 05-07 keine Daten zu den Gesprächsdauern mehr vor. Für fehlende Zeitangaben werden üblicherweise Durchschnitte als Näherung akzeptiert.

e. Harmonisierung von Synonymen

6. Im Lagerhaltungssystem sind Zugänge und Abgänge pro Artikel erfasst. Es sollen Lagerumschläge analysiert werden.

f. Semantische Harmonisierung

7. Als Umsatz mit einem Privatkunden ist für den Monat Juni 2007 18.000 EUR für die Produktgruppe „Diverses Staubsaugerzubehör“ eingetragen, obwohl dieser Wert üblicherweise 1.000 EUR nicht überschreitet.

g. Anreicherung

8. Für jeden Handelspartner ist im ERPSystem im Attribut „PARTNER“ die deutsche Bezeichnung des Landes der Hauptniederlassung hinterlegt (z.B. „Deutschland“). In den zu integrierenden Daten aus dem Marktforschungssystem werden im Attribut „PARTNER“ die Länder mit Hilfe ihrer ISO-3166-Kürzel identifiziert (z.B. „.de“).

h. Harmonisierung der Domänen

Aufgabe B-2-11: Core Data Warehouse und Data Marts Welche der folgenden Aussagen zur Unterscheidung von Core Data Warehouses und Data Marts sind korrekt?

26

‰

Ziel eines Data Marts ist die effiziente Unterstützung von Entscheidern einer spezifischen Unternehmenseinheit.

‰

Für die Datenhaltung wird im Core Data Warehouse primär M-OLAP verwendet.

2.2

Datenbereitstellung für BI-Konzepte

‰

Im Core Data Warehouse werden Daten üblicherweise in feiner Granularität vorgehalten, im Data Mart hingegen zumeist höher aggregiert.

‰

Ein Core Data Warehouse sollte so konzipiert werden, dass es möglichst flexibel für noch nicht vorab bekannte Analyseanwendungen genutzt werden kann.

‰

Im Core Data Warehouse werden die Daten auf abteilungsspezifische Bedürfnisse ausgerichtet.

‰

In der Regel erlauben Data Marts den Endbenutzern direkte Zugriffe auf die Daten.

Aufgabe B-2-12: Begriffe der Metadatenhaltung Bezeichnung für Metadaten, die unmittelbar von den BIWerkzeugen gelesen und zu Steuerungszwecken verarbeitet werden können:

Bezeichnung für ein Metadaten-System, das logisch zentralisiert ist, dafür aber auf mehreren unterschiedlichen physischen Metadatenhaltungssystemen aufsetzt:

Referenzmodell der OMG für technische Metadaten zur Standardisierung des Austauschs von DWH-Metadaten:

Aufgabe B-2-13: Metadaten der Datentransformation Nehmen Sie eine paarweise Zuordnung der linken und der rechten Begriffe anhand des Verwendungszwecks vor: 1. Metadaten zur Kennzahlenbildung

a. Quelldaten

2. Metadaten über die Charakteristika der ERP-Umgebung

b. Filterung 27

2

Übungsaufgaben 3. Metadaten über Regeln zur Behandlung „leerer“ Felder in Quelldaten

c. Harmonisierung

4. Metadaten zur Vereinheitlichung der Granularität

d. Aggregation

5. Metadaten zu Dimensionshierarchisierungen

e. Anreicherung

6. Metadaten zu Benutzerprofilen

f. Informationszugriff

Verständnisfragen (V) Aufgabe V-2-1: Diskussion der Data-Warehouse-Definition von William H. Inmon William H. Inmon definiert den Begriff „Data Warehouse“ anhand der vier Merkmale „Subjektorientierung, Integration, Zeitraumbezug, Non-Volatilität“. Halten Sie alle vier Eigenschaften immer noch für zwingend erforderlich? Für welche Anwendungen könnte es Ihrer Meinung nach sinnvoll sein, eine DataWarehouse-Definition zu wählen, bei der von einzelnen Merkmalen abgerückt wird? Aufgabe V-2-2: BI – Operative und dispositive Daten Erörtern Sie die Unterschiede zwischen operativen und dispositiven Daten. Verdeutlichen Sie Ihre Ausführungen anhand von selbst gewählten Beispielen. Aufgabe V-2-3: Virtuelle Data Warehouses / Enterprise Information Integration Sie werden mit folgender Behauptung konfrontiert: „Das DataWarehouse-Konzept ist obsolet. Moderne ERP-Systeme beherrschen Enterprise Information Integration, d.h. Daten für die Entscheidungsunterstützung werden unmittelbar aus den verschiedenen

28

2.2

Datenbereitstellung für BI-Konzepte

Quellsystemen zusammengezogen. Das hierfür benötigte System ist das so genannte Virtual Data Warehouse“. Diskutieren Sie diese Aussage vor dem Kontext aktueller Entwicklungen im Business-Intelligence-Bereich. Aufgabe V-2-4: Data-Warehouse-Alternativen für einen Kosmetikhersteller Ein Hersteller von hochwertigen Markenpflegeprodukten mit drei Sparten (Hautpflege, Kosmetik, Haarpflege) plant die Einführung eines Systems zur Analyse der Umsatzsituation. Zugegriffen wird insbesondere auf Daten, die vom nachgelagerten Handel bereitgestellt werden. Überlegt wird, Ergebnisse derartiger Analysen unmittelbar in die Planung und Steuerung von Verkaufsförderungsmaßnahmen einzuspeisen und mittelfristig ein kontinuierliches „Real-time“Monitoring des Verkaufs zu ergänzen. Im Unternehmen existieren bereits drei Managementunterstützungslösungen: x

ein Reportingsystem mit Finanzkennzahlen für das TopManagement,

x

eine OLAP-Lösung zur Analyse der Lagerhaltungsprozesse und

x

eine OLAP-Lösung für das Marketing-Management der Haarpflege-Sparte.

Alle Lösungen arbeiten bislang auf jeweils unabhängigen DataMarts. Diskutieren Sie mögliche Ansätze für die Datenbereitstellung für den vorgestellten Fall. Aufgabe V-2-5: Transformationsprozesse bei der Anbindung von Daten aus einem mobilen Wartungssystem Im Rahmen eines CRM-Projektes eines Maschinenherstellers soll eine Anwendung zur Analyse von Serviceprozessen entwickelt werden. Grundlage ist ein bereits etabliertes System zur Unterstützung der Servicemitarbeiter vor Ort. Hierbei können mit mobilen Endgerä-

29

2

Übungsaufgaben ten (PDAs) in einer Maske u.a. die folgenden Daten über Eingabefelder erfasst werden: x

Der Kunde (Freitextfeld und Mussfeld – ohne Eingabe wird eine Speicherung verweigert).

x

Der Einsatzort (Freitextfeld und Mussfeld).

x

Die betroffene Maschine (das System gibt die Liste aller zur Auswahl stehenden Maschinen vor, Mussfeld).

x

Die betroffene Komponente (Freitextfeld, Mussfeld).

x

Name und Adressdaten der Kontaktperson (optionale Freitextfelder, z. T. mit Syntaxprüfung).

x

Der Problemtyp (Auswahl aus einer Liste vorgegebener Problemkategorien; als Standardantwort ist "unspezifizierte technische Störung" ausgewählt, Mussfeld).

x

Problembeschreibung (optionales Freitextfeld, Mussfeld).

x

Aufwand in Minuten (Mussfeld mit Syntaxprüfung).

x

Allgemeine Angaben zum Kunden (optionales Freitextfeld).

x

Cross-Selling-Potentiale (optionales Freitextfeld).

x

Durchgeführte Aktivitäten, z.B. „Problemanalyse“, „Ersatz von Verschleißteilen“, etc. (mehrzeiliges Freitextfeld; Mussfeld).

x

Status nach Besuch (Auswahl aus einer Liste von vorgegebenen Kategorien, z.B. „Abgeschlossen“, „Weiterer Feldeinsatz erforderlich“ etc.).

Die entsprechenden Daten sollen zusammen mit Vertriebs- und Finanzdaten aus dem ERP-System analysiert werden. Diskutieren Sie mögliche Probleme hinsichtlich der Qualität der betroffenen Daten sowie notwendige Transformationsprozesse.

30

2.3

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext

Performanceoptimierte Datenmodellierung im relationalen Kontext Vorbemerkung: Alle ER-Modelle im Aufgaben- und im Lösungsteil folgen der Schlageter/Stucky-Notation. Dabei gibt die Kardinalität eines Entitätstyps jeweils an, wie oft eine Entität dieses Typs in die Beziehungen des jeweiligen Beziehungstyps eingehen kann.

Basisfragen (B) Aufgabe B-3-1: ERM-Notation

ZUSAMMENSETZUNG VERTRAGS# n m

SLA

m

SPEZIFIZIERT

n

LEISTUNG

m ZUSAMMENGEFASST IN n

WERKVERTRAG

VERTRAG DIENSTLEISTUNGSVERTRAG

Welche Kritik würden Sie an dem gezeigten ER-Modell üben? ‰ Ein Entitätstyp darf keine Beziehung zu sich selbst eingehen. ‰ „WERKVERTRAG“ und „DIENSTLEISTUNGVERTRAG“ müssen über einen Beziehungstyp mit „VERTRAG“ verknüpft werden. ‰ Beziehungstypen dürfen nicht ohne Uminterpretation in andere Beziehungstypen eingehen, daher ist die gezeigte Verbindung zwischen „SPEZIFIZIERT“ und „ZUSAMMENGEFASST IN“ falsch. 31

2

Übungsaufgaben ‰ Bei „WERKVERTRAG“ und „DIENSTLEISTUNGSVERTRAG“ fehlen Kardinalitäten. ‰ Zur „LEISTUNG“ gehören keine Attribute des Entitätstyps „VERTRAG“. Aufgabe B-3-2: ERM für Wartungsverträge

MASCHINE

n

BESTEHT AUS

1

KOMPONENTE

m

WARTUNGS VERTRAG

...

...

n

KUNDE

Welche der folgenden Sachverhalte werden in dem Modell abgebildet? ‰ Eine Maschine kann aus mehreren Komponenten bestehen. ‰ Eine Komponente kann auch ohne Zuordnung zu einer Maschine angelegt werden. ‰ Ein Wartungsvertrag ist immer einer Maschine und einem Kunden zugeordnet. ‰ Zu einer Maschine können mehrere Wartungsverträge abgeschlossen werden. ‰ Jeder Kunde schließt einen oder mehrere Wartungsverträge ab. ‰ Bei einem Kunden sind immer mehrere Komponenten zu warten.

32

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext ‰ Ein „WARTUNGSVERTRAG“ wird als eigenständiger Entitätstyp interpretiert, der Beziehungen zu weiteren (hier gestrichelt angedeutet) Entitätstypen eingehen kann. Aufgabe B-3-3: Modellierung eines Reparaturauftrags Welche der vier gezeigten Varianten bildet die folgende Anforderung korrekt ab? „Ein Reparaturauftrag wird identifiziert über den Erfassungszeitpunkt, den betroffenen Kunden, einen Schaden und eine Filiale. Für jeden Schaden kann es maximal einen Reparaturauftrag geben.“

KUNDE

n

1)

FILIALE

m

REPARATURAUFTRAG

o

ZEIT

p

SCHADEN

KUNDE

n

2)

FILIALE

m

REPARATURAUFTRAG

o

ZEIT

0,1

SCHADEN

33

2

Übungsaufgaben

KUNDE

n

3)

FILIALE

m

REPARATURAUFTRAG

1

ZEIT

0,1

SCHADEN

KUNDE n

FILIALE

4)

m

REPARATURAUFTRAG

0,1 BEZIEHT SICH AUF m

SCHADEN

34

1

ZEIT

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Aufgabe B-3-4: ERM und Relationenmodell

KUNDE o

ZEIT

n

KAUF

1

GEHÖRT ZU

n

WARENKORB

m ARTKEL

Welche der folgenden Relationen wurden korrekt aus dem gezeigten ERM abgeleitet? ‰

KUNDE (Kunden#,...)

‰

ARTIKEL (Artikel#, Kunden#, Zeit,...)

‰

KAUF (Artikel#, Zeit, Kunden#,...)

‰

KAUF (Artikel#, Zeit, Kunden#, Warenkorb#,...)

‰

KAUF (Artikel#, Zeit, Kunden#, Warenkorb#,...)

‰

GEHÖRT_ZU (Kunden#, Artikel#, Zeit, Warenkorb#,...)

‰

WARENKORB (Warenkorb#, Artikel#, Zeit, Kunden#,...)

Aufgabe B-3-5: Normalisierung – erste Normalform Welche der folgenden Relationen befindet sich in erster Normalform? ‰

KUNDE (Kunden#, Vorname, Nachname, Anschrift_1, Anschrift_2)

‰

BESTELLUNG (Kunden#, Bestelldatum, Artikel#, Artikel, Artikelgruppe)

‰

WARTUNG (Auftrags#, Reparierte_Komponente_1, Reparierte_Komponente_2, Reparierte_Komponente_3, Reparierte_Komponenet_4, WeitereReparierteKomponenten)

35

2

Übungsaufgaben ‰ BESTELLPOSITION (Bestell#, Positions#, Positionsbeschreibung, Artikel#, Anzahl, Listenpreis) ‰ ARTIKEL (Artikel#, Artikelname, Artikelgruppe) Aufgabe B-3-6: Normalisierung – zweite Normalform Welche der folgenden Relationen befindet sich in zweiter Normalform? ‰

KUNDE (Kunden#, Vorname, Nachname, Kundengruppen#, Kundengruppenname)

‰

BESTELLUNG (Kunden#, Bestelldatum, Artikel#, Artikel, Artikelgruppe)

‰

ARTIKEL (Artikel#, Artikelname, Artikelgruppen#, Artikelgruppe)

Aufgabe B-3-7: Normalisierung – dritte Normalform Welche der folgenden Relationen befindet sich in dritter Normalform?

36

‰

KUNDE (Kunden#, Vorname, Nachname, Kundengruppen#, Kundengruppenname)

‰

BESTELLPOSITION (Bestell#, Positions#, Artikel#, Anzahl, Listenpreis)

‰

ARTIKEL (Artikel#, Artikelname, Artikelgruppen#, Artikelgruppe)

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Aufgabe B-3-8: Normalisierung – Normalformen Welche der drei Normalformen sind verletzt? Verletze Normalform 1NF

2NF

3NF

PATIENT

(Patienten#, Liste_Diagnosen)

‰

‰

‰

FILIALE

(Filial#, Bundesland, Land)

‰

‰

‰

ARTIKEL

(Artikel#, Artikelbezeichnung, Artikelgruppen#, Artikelgruppenleiter)

‰

‰

‰

‰

‰

‰

‰

‰

‰

BUCHUNG (Sollkonto#, Habenkonto#, Betrag, KontentypSoll, KontentypHaben) BESTELL

(Kunden#, Artikel#, Datum, Menge, Lieferart, Transportgesellschaft, Transportgesellschaft_Tel)

Aufgabe B-3-9: Konzepte multidimensionaler Datenmodellierung Wie werden die folgenden Ansätze üblicherweise bezeichnet? 1) Anfertigen von Sicherungskopien, um Datenbereiche bei fachlichem Bedarf (z.B. Revision, Rechtsstreit) wiederherstellen zu können: _____________________________________________________ 2) Angelsächsische Bezeichnung für den Sachverhalt, dass auch Dimensionstabellen üblicherweise im Zeitverlauf Änderungen unterliegen, denen technisch wie betriebswirtschaftlich begegnet werden muss: _____________________________________________________

37

2

Übungsaufgaben 3) Aufteilung der Dimensionstabellen zur Performanceoptimierung, oftmals auf Grundlage der definierten Aggregationen und in Verknüpfung mit Summationstabellen: _____________________________________________________ 4) Integration mehrerer Star-Schemata auf Basis strukturidentischer Dimensionstabellen: _____________________________________________________ 5) Historisierungsverfahren, bei dem bei jeder Aktualisierung einer Dimensionstabelle sämtliche Datensätze – also sowohl die geänderten wie auch die unveränderten – an die existierende Tabelle angehängt werden: _____________________________________________________ 6) Sicherung von Datenbeständen auf speziellen Sicherungsmedien, um bei technischem Systemfehlverhalten Datenbereiche wiederherstellen zu können: _____________________________________________________ 7) Konzepte, mit deren Hilfe Änderungen von Attributsausprägungen, Beziehungen und Entitäten im Zeitablauf dokumentiert werden: _____________________________________________________ 8) Schema mit generierten, abhängigen Summationstabellen zur Performancesteigerung bei Analysen auf aggregierten Daten: _____________________________________________________ 9) Historisierungsverfahren mit zeilengenauer Historisierung der Dimensionstabellen: _____________________________________________________ 10) Attribut zur Markierung aktuell gültiger Daten. _____________________________________________________

38

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Aufgabe B-3-10: Eigenschaften des Star-Schemas Welche der folgenden Aussagen sind korrekt? ‰

Das Star-Schema ist die Datenhaltung von M-OLAPSystemen.

‰

Mit einem Star-Schema kann eine multidimensionale Datenhaltung realisiert werden.

‰

„Star-Schema“ und „OLAP“ sind Synonyme.

‰

Fakten im Star-/Snowflake-Schema sind ausschließlich monetäre Kennzahlen.

‰

Dimensionstabellen sind häufig wegen der umfangreichen Attributierung sehr groß, Faktentabellen hingegen aufgrund der wenigen zu hinterlegenden Kennzahlen (jeweils nur zwei oder drei Kennzahlen pro Zeile) sehr klein.

‰

Im Star-Schema wird häufig die zweite Normalform verletzt.

‰

Die Redundanz im Star-Schema ist vertretbar, da auf die entsprechenden Daten primär lesend zugegriffen wird.

Aufgabe B-3-11: Analysen auf Basis eines Star-Schemas DT_Zeit

DT_Produkt

KZeit

KProdukt

Monat Jahr

Produkt KProduktgruppe Produktgruppe Maße

FT_Umsatzanalyse

DT_Verkäufer KVerkäufer Name KRegion Region KLand Land

KZeit KVerkäufer KProdukt KKundentyp Umsatz Var.-Kosten DT_Kundentyp KKundentyp Kundentyp

39

2

Übungsaufgaben Welche der folgenden Analysen sind mit dem gezeigten StarModell nicht möglich, sofern keine weiteren Datenquellen verfügbar sind? ‰

Entwicklung des Deckungsbeitrags (= Umsatz abzüglich der variablen Kosten) im Zeitverlauf.

‰

Vergleich der variablen Kosten je Geschäftsjahr.

‰

Gewinne pro Filiale für die Region 3.

‰

„Top 10“ der deckungsbeitragsstärksten Produkte.

‰

Performanceanalyse der Verkäufer in den verschiedenen Regionen.

‰

Identifizierung der umsatzstärksten Kundentypen.

‰

Optimierung der Regalnutzung (Deckungsbeitrag / benötigte Regalfläche).

‰

Vergleich des durchschnittlichen Umsatzes pro Kundentyp.

Aufgabe B-3-12: Auswahl von Historisierungsverfahren

40

SnapshotHistorisierung

DeltaHistorisierung

Im Call-Center eines Versandunternehmens mit Telefonvertrieb werden die Mitarbeiter jeweils bestimmten Vorwahlbereichen zugeordnet. Für Performance-Analysen wird ein Star-Schema entworfen, das u.a. eine Telefonnummer enthält. Die Telefonnummern der Kunden ändern sich regelmäßig. Ob entsprechende Änderungen eingepflegt wurden, ist nicht direkt aus den operativen Daten ersichtlich.

Update

Welches Verfahren zum Umgang mit den folgenden Änderungen von Dimensionsdaten würden Sie jeweils empfehlen?

‰

‰

‰

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Ein Telekommunikationsunternehmen speichert Verbindungsdaten für eine große Zahl an Privatkunden. Alle Änderungen an den Kundenstammdaten (z.B. neue Kundenadresse, verantwortlicher Ansprechpartner) werden automatisch protokolliert. In den Analysen sind die Kundendaten den im jeweiligen Betrachtungszeitraum verantwortlichen Servicemitarbeitern zuzuordnen.

‰

‰

‰

Für die Serviceoptimierung eines Herstellers von Laser-Schneidemaschinen wird ein StarSchema entworfen, in dem u.a. eine Kundendimension mit der E-Mail-Adresse des Hauptansprechpartners vorgesehen ist. Im zugrunde liegenden operativen CRM-System werden alle Änderungen an den Stammdaten protokolliert – auch die der E-MailAdressen.

‰

‰

‰

Aufgabe B-3-13: Eigenschaften von Historisierungsverfahren Welche der folgenden Aussagen sind korrekt? ‰

Eine Historisierung mit Gültigkeitsfeldern ist einer DeltaHistorisierung immer vorzuziehen, da hierdurch genauere Zuordnungen möglich werden!

‰

Das „Update-Verfahren“ ist kein Historisierungsverfahren.

‰

Über die Zeitstempel werden bei Historisierungsverfahren sowohl kumulierte Faktenabfragen über aktuelle Dimensionsausprägungen als auch zeitpunktbezogene Auswertungen des Datenbestandes ermöglicht.

‰

Current-Flags vereinfachen den Umgang mit Änderungen in den Dimensionstabellen.

‰

Bei Delta-Historisierung mit künstlicher Schlüsselerweiterung können zwar Änderungen an den Dimensionsdaten nachvollzogen werden, es sind jedoch keine zeitpunktbezogenen historischen Auswertungen der Fakten möglich, da in der Faktentabelle lediglich auf die aktuellen Zeilen der Dimensionstabellen verwiesen wird.

41

2

Übungsaufgaben

Verständnisfragen (V) Aufgabe V-3-1: Datenmodell für die Erfassung von Kundenreklamationen Im Rahmen eines CRM-Projektes muss ein System zur Erfassung von Kundenbeschwerden überarbeitet werden. Entwickeln Sie aus dem folgenden Ausschnitt des Anforderungskatalogs ein Entity Relationship Model (ERM): ƒ

Ein Beschwerdeanruf kann über den Kunden, den HelpDesk-Mitarbeiter und den Beschwerdezeitpunkt identifiziert werden.

ƒ

Jeder Beschwerdeanruf kann sich auf beliebig viele Störungen beziehen. Eine Störung kann in mehreren Anrufen thematisiert werden.

ƒ

Zu jeder Störung ist als Eigenschaft eine „Störungsbeschreibung“ zu hinterlegen.

ƒ

Bei einer Störung handelt es sich entweder um eine leichte oder um eine schwere Störung. Zu den schweren Störungen werden die „Störungsklasse“ und der „Problemlösungsweg“ als ergänzende Attribute hinterlegt.

ƒ

Jeder Kunde ist einer Kundengruppe zugeordnet.

Überführen Sie Ihr ER-Modell in ein Relationenmodell. Aufgabe V-3-2: Datenmodell für die Raumplanung Es soll ein System zur Raumplanung erstellt werden. Entwickeln Sie hierzu zunächst ein ER-Modell auf Basis folgender Anforderungen und überführen Sie dies im Anschluss in ein Relationenschema:

42

ƒ

Jedes Büro gehört zu einem Haus. Ein Haus beinhaltet mehrere Büros.

ƒ

Jedem Haus ist ein Hausmeister zugeordnet. Ein Hausmeister kann für mehrere Häuser zuständig sein.

ƒ

Jedes Büro wird von einem oder mehreren Mitarbeitern belegt. Ein Mitarbeiter kann im Laufe der Zeit das Büro wechseln.

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext ƒ

Der Hausmeister ist selbst ein Mitarbeiter.

ƒ

Zu jeder Belegung werden diverse Kostenpositionen erfasst.

Aufgabe V-3-3: Normalisierung für ein Fakturierungssystem Ein auf importierte Mobilgeräte spezialisierter Elektronikhändler verwaltet seine Verkäufe mit Hilfe einer selbst erstellten DesktopDatenbank. Mit dem starken Anwachsen des Geschäfts häufen sich die Probleme mit dem bislang tadellos laufenden und mit einer vorbildlichen Benutzerschnittstelle ausgestatteten Programm. Sie erhalten den Auftrag einer Überarbeitung. Sie finden folgendes Relationenmodell vor: RECHNUNG

(V#, Zeit, K#, KundeNachname, KundeVorname, KundeAnschrift, KundeTel,...)

RECHNUNGSPOS

R#, Artikel#, Artikelbezeichnung, Anzahl,...)

ARTIKEL

(Artikel#, Bezeichnung, Artikeltyp#, Artikeltypbezeichnung, Zulieferer_1, Zulieferer_2, Zulieferer_3,...)

VERKÄUFER

(V#, Nachname, Vorname,...)

Diskutieren Sie den Normalisierungsprozess und überführen Sie das Modell in die 3. Normalform. Aufgabe V-3-4: Normalisierung und Datenqualität Bei der Analyse von Wartungsaufträgen treten erhebliche Mängel bei den Daten des operativen Quellsystems zu Tage. Hier ein Auszug des zugrunde liegenden Relationenschemas: WART_AUFTRAG

(Kunden#, Bearbeiter#, Datum, Maschinen#, Auftragstyp_1, Auftragstyp_2, Bearbeitername, BearbeiterProvisionssatz,...) 43

2

Übungsaufgaben BEARBEITER

(Bearbeiter#, Name, Vorname, Position, Provisionssatz,...)

KUNDE

(Kunden#, Firmenname, Handelsregistereintrag, Kundengruppen#, Kundengruppenbezeichnung, Region, Marketingleiter_Region,...)

MASCHINE

(Maschinen#, Maschinentyp, Maschinentypbeschreibung,...)

STÖRUNG

(Maschinen#, Kunden#, Bearbeiter#, Datum, Maschinentyp, Störungstyp, BeschreibungStörungstyp,...)

KOMPONENTE

(Komponenten#, Typ, Maschinen#, Funktion, Datum,...)

BAUGRUPPE

(Oberteil-Komponenten#, UnterteilKomponenten#,...)

Identifizieren Sie Normalformenverletzungen und diskutieren Sie mögliche Konsequenzen für die Datenqualität. Entwerfen Sie ein alternatives Datenbankschema in 3NF. Aufgabe V-3-5: Star-Schema zur Unterstützung des Managements von Wartungsprozessen MASCHINENTYP n

KUNDE

GEHÖRT ZU

n 1 m ZEIT

1 WARTUNG

o BEARBEITER

44

BETRIFFT STÖRUNG VON

n MASCHINE

2.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Für die Vertriebsunterstützung werden im CRM-System Daten zum oben gezeigten ER-Modell festgehalten. Entwerfen Sie ein mögliches Star-Schema für freie Vertriebsanalysen. Hinsichtlich der verfügbaren Attribute können Sie eigene Annahmen treffen. Stellen Sie fünf mögliche Analysen vor, die Sie auf Basis Ihres Modells durchführen können. Aufgabe V-3-6: Galaxie und Analysemöglichkeiten Für einen Händler von Baumaschinen wird ein Data-Mart auf Basis einer „Galaxie“ entwickelt. Diskutieren Sie, welche Analysen mit dem folgenden Modell möglich werden. Nennen Sie dabei mindestens fünf Beispiele für konkrete Analysen. DT_Kunde KKunde Name KKundengruppe Kundengruppe

FT_Verkauf KZeit KKunde KArtikel Listenpreis Menge Rabatt Vertriebseinzelkosten

DT_Zulieferer

FT_Einkauf

KZulieferer

KZulieferer KArtikel KZeit

Name Land

Listenpreis Menge Rabatt Lieferdauer

DT_Artikel KArtikel Seriennr. Artikelname KArtikeltyp Artikeltyp DT_Zeit K_Zeit Monat Quartal Jahr

Aufgabe V-3-7: Mehrdimensionales-Schema für eine Videothek Für eine landesweit aktive Videothekenkette soll ein Data Mart zur Optimierung der Produktpolitik entworfen werden. Der Data Mart soll als Grundlage für freie Datenrecherchen und für OLAP-Analysen eingesetzt werden. Aus dem Bestellsystem und Ihrer Filmdatenbank können Sie folgende Relationen extrahieren:

45

2

Übungsaufgaben FILIALE

(Filial#, Strasse, PLZ, Ort)

KUNDE

(Kunden#, Name, Vorname, Strasse, PLZ, Ort)

DVD

(DVD#, Spielfilm#, Extras)

VERLEIH

(Ausgabetag, Kunden#, Filial#, Rabatt, Verzugsgebühr)

VERLEIH_POS

(Ausgabetag, Kunden#, Filial#, DVD#, Rückgabetag, Schadenstyp, Gebühr)

SPIELFILM

(Spielfilm#, Titel, Altersfreigabe, Regisseur, Genre, Dauer)

Entwerfen Sie einen Vorschlag für ein Schema auf Basis der verfügbaren Daten. Aufgabe V-3-8: Snowflake-Schema

2.4

ƒ

Was wird unter dem Begriff „Snowflake-Schema“ verstanden?

ƒ

Welche Vor- und Nachteile sind mit der Generierung eines Snowflake-Schemas verbunden?

ƒ

In welchen Situationen halten Sie den Ausbau eines StarSchemas zu einem Snowflake-Schema für sinnvoll?

Informationsgenerierung, -speicherung, -distribution und -zugriff Basisfragen (B) Aufgabe B-4-1: Traditionelle Abgrenzung dispositiver Systeme Erklären Sie, warum die traditionelle Darstellung dispositiver ITSysteme in Form einer Pyramide mit eindeutiger System- und

46

2.4

Informationsgenerierung, -speicherung, -distribution und -zugriff Benutzergruppenzuordnung in der heutigen Zeit nicht länger angebracht ist. Aufgabe B-4-2: Latenzzeiten Erläutern Sie den sog. „Wertverlust von Informationen“ anhand verschiedener Latenzzeiten. Diskutieren Sie, mit welchen DataWarehousing-Ansätzen einzelne Arten von Latenzzeiten reduziert oder eliminiert werden können. Gehen Sie in Ihren Ausführungen insbesondere auf die „betriebswirtschaftliche Angemessenheit“ der entsprechenden Ansätze ein. Aufgabe B-4-3: Data Warehousing Geben Sie exemplarisch Einsatzgebiete der unterschiedlichen DWH-Implementierungsansätze „Klassisches Data Warehousing“, „Closed-loop Data Warehousing“, „Real-time Data Warehousing“ und „Active Data Warehousing“ an. Aufgabe B-4-4: Freie Datenrecherchen Welche der Aussagen ist (sind) richtig? ‰

Freie Datenrecherchen sind mit OLAP-Recherchen gleichzusetzen.

‰

Werkzeuge wie SQL und MDX sind techniknahe Abfragesprachen, die aufgrund ihrer Komplexität nur von versierten Endbenutzer (Power Usern) oder IT-Mitarbeitern eingesetzt werden sollten.

‰

Mit freien Datenrecherchen können Benutzer durch ungeschickte Abfragen die Performance der dispositiven Datenhaltung elementar verschlechtern.

Aufgabe B-4-5: OLAP Was wird unter den FASMI-Kriterien verstanden?

47

2

Übungsaufgaben Aufgabe B-4-6: Decision Support Systems (DSS) Erläutern Sie die Komponenten einer DSS-Architektur und erklären Sie, warum die meisten DSS heute mit Tabellenkalkulationsprogrammen umgesetzt werden. Aufgabe B-4-7: Expertensysteme Wann können Expertensysteme selbständig Entscheidungen treffen und in welchen Fällen werden sie lediglich als entscheidungsunterstützende Systeme eingesetzt? Aufgabe B-4-8: Data Mining Welche der Aussagen ist (sind) falsch? ‰

Data Mining ist als computergestützte Datenanalyse zur Mustererkennung ein neues Anwendungsgebiet, das vor 20 Jahren noch nicht existierte.

‰

Data Mining meint – je nach Auslegung – die hypothesenfreie oder die hypothesenbasierte Suche nach nicht trivialen Mustern in Datenbeständen.

‰

Die Bezeichnungen Clusterbildung und Klassifikation sind Synonyme, meinen also dieselbe Methode.

Aufgabe B-4-9: Berichtssysteme Erläutern Sie die Unterschiede zwischen „aktiven“ und „passiven“ Berichtssystemen und bilden Sie für jeden Berichtstyp ein aussagekräftiges Beispiel. Aufgabe B-4-10: Interaktive Report-Plattformen und generierte Berichte Welche der Aussagen ist (sind) falsch? ‰

48

Interaktive Report-Plattformen sind professionelle Werkzeuge für Spezialisten der IT-Abteilung, um für die Fachbereiche fertige Berichte generieren zu können. Ein direkter Einsatz dieser Werkzeuge in den Fachbereichen macht keinen Sinn.

2.4

Informationsgenerierung, -speicherung, -distribution und -zugriff ‰

Management Information Systems sind algorithmisch (formelbasiert) ausgerichtet und unterscheiden sich aus diesem Grunde von berichtsorientierten Executive Information Systems.

‰

Executive Information Systems sind auf das TopManagement ausgerichtet und verfügen daher über großes Maß an Bedienungskomfort.

Aufgabe B-4-11: Konzeptorientierte Systeme Erläutern Sie, was im BI-Kontext unter konzeptorientierten Systemen verstanden wird. Aufgabe B-4-12: Wissensmanagement (WM) Welche der Aussagen ist (sind) richtig? ‰

BI-Analysen können Wissen erzeugen, das an anderer Stelle im Unternehmen sinnvoll genutzt werden kann. Es sollte deshalb überprüft werden, die Erkenntnisse in das betriebliche Wissensmanagement zu integrieren.

‰

Es ist sinnvoll, BI-Analysen mit Inhalten aus Wissensmanagementsystemen anzureichern, um aussagefähige Interpretationen von BI-Analyseergebnissen zu ermöglichen.

‰

Integrationspotentiale zwischen BI und WM ergeben sich auf der Präsentationsebene, der Logikebene und der Datenebene.

Aufgabe B-4-13: Portal Erläutern Sie kurz die Eigenschaften eines BI-Portals.

Verständnisfragen (V) Aufgabe V-4-1: Analytisches CRM Ein Handelshaus beabsichtigt, für den Marketingbereich wirkungsvolle BI-Lösungen zu implementieren. Erläutern Sie die 49

2

Übungsaufgaben Einsatzmöglichkeiten für BI-Analysen im CRM und erörtern Sie infrastrukturelle Voraussetzungen einer technischen Umsetzung. Aufgabe V-4-2: Analysesysteme für den Controllingbereich Im Controlling Bereich eines Großunternehmens der chemischen Industrie sollen neben den bislang eingesetzten Tabellenkalkulationsprogrammen neue IT-Werkzeuge für die Produkt- und Kundenanalyse ausgewählt werden. Der Leiter des Bereiches wünscht sich vor allem Antworten auf schlecht antizipierbare Fragestellungen, wie z.B.: x

Gibt es Auffälligkeiten im Bereich produkt-/kundenspezifischer Umsätze, die einen überproportionalen Einfluss auf das operative Ergebnis haben?

x

Welche Kunden besitzen den größten Anteil am Erlös und an der verkauften Menge?

x

Welche Produkte weisen die größten Ausschussquoten auf?

Welche Typen von Analysesystemen kommen für den Controllingbereich in Frage? Diskutieren Sie die Möglichkeiten der verschiedenen Systemtypen. Aufgabe V-4-3: OLAP-Varianten Der Fachbereich und die IT-Abteilung eines Unternehmens streiten über die richtige Auswahl eines OLAP-Systems. Zur Diskussion stehen die Ansätze R-OLAP, M-OLAP und H-OLAP. Diskutieren Sie die jeweiligen Vor- und Nachteile sowie die Einsatzbereiche dieser Ansätze. Aufgabe V-4-4: Balanced Scorecard Der Leiter der Abteilung IT hat bei einem führenden Werkzeughersteller eine parametrisierbare Standardlösung zum Aufbau einer Balanced Scorecard erworben. Nun hofft er schnell und einfach dieses konzeptorientierte System im eigenen Unternehmen implementieren zu können, um der Geschäftsleitung neue wirkungsvolle Führungsinstrumente an die Hand geben zu können. Glauben Sie, dass diese Vorgehensweise erfolgversprechend ist? 50

2.5

Entwicklung integrierter BI-Anwendungssysteme

Aufgabe V-4-5: Business Intelligence und Wissensmanagement Das Top-Management eines großen Telekommunikationsdienstleisters beabsichtigt, den BI-Bereich und die Systeme für das betriebliche Wissensmanagement zu integrieren. Konkretisieren Sie die Potentiale einer solchen Integration anhand von Beispielen, zeigen Sie konzeptionelle Lösungsmöglichkeiten auf und diskutieren Sie potentielle Schwierigkeiten bei der Umsetzung einer integrierten Lösung.

2.5

Entwicklung integrierter BI-Anwendungssysteme Basisfragen (B) Aufgabe B-5-1: Vorgehensmodelle (VM) Erläutern Sie die grundsätzliche Notwendigkeit des Einsatzes von Vorgehensmodellen (Prozessmodellen) bei der Entwicklung von IT-Anwendungssystemen. Beschreiben Sie auf einer abstrakten Ebene die Gemeinsamkeiten und Unterschiede verfügbarer Vorgehensmodelle. Aufgabe B-5-2: Sequentielle Vorgehensmodelle (VM) Erläutern Sie Historie, Charakteristika und Einsatzpotentiale sequentieller Vorgehensmodelle und gehen Sie hierbei insbesondere auf das Wasserfallmodell und neuere Varianten dieses VMTyps ein. 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.

‰

Bei iterativen VM erfolgt die Systementwicklung primär durch Mitarbeiter der betriebswirtschaftlichen Abteilungen. 51

2

Übungsaufgaben ‰

Bei iterativer Systementwicklung wird konsequent die Methodik des explorativen Prototyping eingebunden.

Aufgabe B-5-4: Inkrementelle Entwicklungsmodelle Erläutern Sie den Aufbau inkrementeller Entwicklungsmodelle und argumentieren Sie, warum diese Modelle meist bei der Entwicklung unternehmensumfassender BI-Ansätze eingesetzt werden. Aufgabe B-5-5: Iterative, evolutionäre und inkrementelle Entwicklungsmodelle Welche der Aussagen ist (sind) richtig? ‰

Iterative, evolutionäre und inkrementelle Entwicklungsmodelle stellen drei verschiedene Ansätze der Systementwicklung dar.

‰

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.

‰

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.

52

‰

BI-Potentialplanung

‰

Reengineering bestehender BI-Subsysteme

‰

Aufbau eines Projektdatenmodells

‰

Implementierung von ETL-Prozessen

‰

Aufbau einer dispositiven Datenarchitektur

‰

Erstellung eines BI-Portfolios

2.5

Entwicklung integrierter BI-Anwendungssysteme

Aufgabe B-5-7: BI-Potentialplanung Diskutieren Sie die Begriffe BI-Wirtschaftlichkeit sowie BIWirksamkeit und erläutern Sie übliche Fehlentwicklungen in der Praxis. 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.

‰

Detaillierte Attributierungen werden üblicherweise in der Datenarchitektur nicht vorgenommen.

‰

Im Mittelpunkt der Architekturentwicklung stehen die Anforderungen aus Managementsicht. Eine Abstimmung mit der operativen/externen Datenwelt ist nicht erforderlich, ja sogar kontraproduktiv.

‰

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 Was wird unter einem BI-Projektportfolio verstanden und nach welchen Kriterien kann ein solches Portfolio in der Praxis abgegrenzt werden? Aufgabe B-5-10: Unternehmenskultur und Business Intelligence Diskutieren Sie den Zusammenhang zwischen Unternehmenskultur und BI-Ansätzen.

53

2

Übungsaufgaben Aufgabe B-5-11: Reengineering der Makroebene Was wird unter dem Reengineering der Makroebene verstanden? Aufgabe B-5-12: BI-Support Nennen Sie Gründe, warum es notwendig ist, dauerhafte organisatorische Strukturen für einen BI-Support zu etablieren (z.B. in Form eines BI-Competence-Centers – BICC). 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. ‰ 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. ‰ Während eines erforderlichen Reengineering-Zyklusses kann das entsprechende BI-Anwendungssystem nicht genutzt werden.

54

2.5

Entwicklung integrierter BI-Anwendungssysteme

Aufgabe B-5-14: Entwicklung von BI-Anwendungssystemen Erläutern Sie, warum BI-Anwendungssysteme in Projektform entwickelt werden und welche Anspruchsgruppen in diesen Projekten angemessen repräsentiert sein sollten. Aufgabe B-5-15: Reifegrad und BI-Entwicklungsprozesse Diskutieren Sie, warum die Höhe des Aufwands einzelner BIAnwendungssysteme vom Reifegrad des BI-Ansatzes abhängt.

Verständnisfragen (V) Aufgabe V-5-1: „Think big – start small“ Diskutieren Sie kritisch den oben angeführten, populären (Berater-) Spruch im Kontext der BI-Entwicklung. Aufgabe V-5-2: Evolutionäre Entwicklungsmodelle Beschreiben Sie Charakteristika evolutionärer Entwicklungsmodelle und zeigen Sie an einem Beispiel auf, wo diese Form der Systementwicklung sinnvoll eingesetzt werden kann. Aufgabe V-5-3: Entwicklung eines unternehmensweiten BI-Ansatzes In der IT-basierten Managementunterstützung eines Maschinenbauunternehmens ist im Laufe der Zeit eine sehr heterogene und zum Teil redundante Systemlandschaft entstanden. Dies verursacht in der Unternehmenszentrale großen Aufwand bei der Datensammlung und -aufbereitung; beispielsweise müssen zahlreiche MS-ExcelTM-Tabellen einzeln abgeglichen, inhaltlich abgestimmt und zusammengeführt werden, um stimmige Managementinformationen generieren zu können.

55

2

Übungsaufgaben Nun soll eine Neugestaltung der IT-basierten Managementunterstützung erfolgen, wobei das Management eine unternehmensweite BI-Lösung auf der Basis einer Hub-and-SpokeArchitektur anstrebt. Für die Implementierung der neuen Lösung werden im Unternehmen zwei Entwicklungsvarianten diskutiert. 1.

BI-Entwicklung auf Basis von Wasserfallmodellen.

2.

BI-Entwicklung auf der Basis evolutionärer Entwicklungsmodelle.

Diskutieren Sie die jeweiligen Vor- und Nachteile der einzelnen Ansätze und beurteilen Sie diese im Hinblick auf die dargestellten Rahmenbedingungen.

Aufgabe V-5-4: Entwicklung einer BI-Lösung für das Controlling Der Leiter der Abteilung Marketing ist sehr unzufrieden mit den dispositiven Systemen seines Bereichs. Lange Wartezeiten, uneinheitliche Informationen und mangelnde Flexibilität der Berichte sind seine Hauptkritikpunkte. Da er von der Unternehmensleitung Signale bekommen hat, dass eine Neuentwicklung eines unternehmensweiten BI-Ansatzes zur Zeit nicht in Frage kommt, entschließt sich der Controllingleiter für den Aufbau einer abteilungsspezifischen Lösung. Welchen Aufbau könnte ein solches BI-System besitzen und mit welchem Vorgehen wäre diese Lösung erfolgreich zu entwickeln und zu betreiben?

56

3

Lösungen und Lösungsskizzen Im dritten Block finden Sie die Lösungen und Lösungsskizzen zu den Übungsaufgaben des zweiten Blocks. Die Antworten stellen insbesondere bei den Verständnisfragen keine Musterlösungen dar, sondern sind als Sammlungen wichtiger Aspekte zu interpretieren, die Sie bei Ihrer individuellen Aufgabendiskussion unterstützen sollen.

3.1

Business Intelligence — Begriffsabgrenzung und Ordnungsrahmen Basisfragen Aufgabe B-1-1: Historische Entwicklung IT-basierter Managementunterstützung Ihre Antwort könnte folgende Punkte beinhalten: x

Die IT-basierte Managementunterstützung reicht bis in die 1960er Jahre zurück (Ausbreitung der kommerziellen Computernutzung).

x

Rückblickend können die ersten, auch als Total System Approaches bezeichneten Konzepte aufgrund überzogener Erwartungshaltungen und einer heute eher als naiv anmutenden Technikgläubigkeit allesamt als gescheitert bezeichnet werden.

x

Erste wirkungsvolle IT-Ansätze zur Unterstützung der Führungskräfte wurden in den 1970er Jahren als modellorientierte Decision Support Systems (DSS) und berichtsorientierte, eng auf spezielle Anwendungsbereiche fokussierte Management Information Systems (MIS) entwickelt.

x

Der Begriff „Management Support Systems (MSS)“, im deutschen „Management-Unterstützungs-Systeme (MUS)“, 57

3

Lösungen und Lösungsskizzen wird seit den 1980er Jahren als Sammelbegriff für sämtliche IT-Aktivitäten zur Managementunterstützung verwendet. (Frühe Veröffentlichung: Michael S. Scott Morton: State of the Art of Research in Management Support Systems, Paper presented at the Colloquium on Information Systems, MIT July 10-12, 1983). Aufgabe B-1-2: Business Intelligence – Erste Begriffsdeutungen Ihre Antwort könnte folgende Punkte beinhalten: x

Der Begriff „Business Intelligence“ stammt aus dem Beratungsumfeld (Protagonist: Gartner Group) Mitte der 1990er Jahre.

x

Als führende Werkzeughersteller sich des Begriffes bedienten und BI als Sammelbegriff für sämtliche von ihnen angebotenen Produkte verwendeten, setzte sich der Begriff in der Praxis durch.

x

Eine klare BI-Definition existierte anfangs nicht. Vielmehr waren die BI-Deutungen eher beratungs- bzw. herstellerorientiert ausgerichtet und von großer Beliebigkeit.

x

Erste kritische wissenschaftliche Auseinandersetzungen mit dem Begriff BI sind im deutschsprachigen Bereich seit Anfang des neuen Jahrhunderts verfügbar. Der vielschichtige Begriff „Intelligence“ wurde hierbei von Anfang an nicht als „Intelligenz“ sondern als „(Management-)Information“ interpretiert, die es zu generieren, zu speichern, zu recherchieren, zu analysieren, zu interpretieren und zu verteilen gilt.

Aufgabe B-1-3: E-Business und grundlegende Systeme der Wertschöpfung Ihre Antwort könnte folgende Punkte beinhalten:

58

x

Der Begriff „E-Business“ etablierte sich Ende der 1990er Jahre (Protagonist: IBMTM) und stellt eine Erweiterung des Begriffes „E-Commerce“ dar.

x

Während E-Commerce primär die kunden- bzw. lieferantenspezifischen Transaktionen in den Mittelpunkt stellt, wird unter E-Business die generelle Abwicklung einer,

3.1

Business Intelligence – Begriffsabgrenzung und Ordnungsrahmen mehrerer oder aller Phasen (Informations-, Vereinbarungs- und Abwicklungsphase) von geschäftlichen Transaktionen mit Hilfe von Internettechnologien (TCP/IP-Protokollstack) verstanden. x

E-Business ist somit der umfassendere Begriff und beinhaltet auch das Einsatzgebiet des E-Commerce.

x

Aufgrund der weit verbreiteten Nutzung der Internettechnologie in Form von Intranets und Extranets betreibt heute nahezu jede Unternehmung E-Business.

x

Intra-Business-Systeme (Inhouse E-Business) sind insbesondere aktuelle ERP-Systeme (Enterprise Resource Planning), die unter Nutzung von Intranets als integrierte IT-Systeme zur Unterstützung der relevanten betrieblichen Funktionsbereiche wie Einkauf, Produktion, Vertrieb, Personal und Finanzwesen zum Einsatz kommen.

x

SCM (Supply Chain Management) als Vertreter von Business-to-Business-Systemen (B2B-Systemen) dient der Optimierung der Lieferkette unter Einbeziehung von Lieferanten (und Vorlieferanten) und Kunden (als Auftraggeber).

x

E-Procurement bezeichnet die internetbasierte Abwicklung elektronischer Einkaufsprozesse im B2B-Kontext.

x

Unter CRM (Customer Relationship Management) wird ein umfassender Ansatz zur systematischen Unterstützung der Kundenbeziehungen verstanden, wobei EBusiness-Systeme zur Unterstützung des kommunikativen CRM, des operativen CRM und des analytischen CRM zum Einsatz kommen. CRM kann sowohl die Form B2B als auch B2C (Business-to-Consumer; Consumer = privater Endkunde) annehmen.

Aufgabe B-1-4: Identifikation von BI-Anwendungssystemen Welche der folgenden Systeme sind Ihrer Ansicht nach üblicherweise keine BI-Anwendungssysteme? ; Reisekostenabrechnung (Abrechnungssysteme sind operativer Natur.) ‰

Balanced Scorecard

59

3

Lösungen und Lösungsskizzen ; Debitorenbuchhaltung (Beschäftigt sich mit der Erfassung und Administration offener Forderungen.) ; Call-Center-Steuerung mit ACDS (Automated Call Distribution System) (Optimiert Schaltungen eingehender Telefonate in InboundCall-Center.) ‰

Konzernkonsolidierung

‰

Vertriebscontrolling

‰

Lagerhaltungsmanagement

‰

Analytisches CRM

; Workflow-Management für die Verarbeitung von Geschäftsdokumenten (Unterstützt die elektronische Ausführung und Steuerung von Geschäftsprozessen.)

Verständnisfragen (V) Aufgabe V-1-1: Management Support Systems und Business Intelligence Ihre Argumentation könnte folgende Punkte beinhalten:

60

x

Grundsätzlich sind neue Bezeichnungen lediglich dann gerechtfertigt, wenn sich die neuen Lösungen in erheblichem Maße qualitativ von althergebrachten Ansätzen unterscheiden.

x

Neue Ansätze werden in der Regel durch geänderte Rahmenbedingungen initiiert bzw. erforderlich (neue gesetzliche Anforderungen, Veränderungen im Wettbewerbsumfeld oder technische Innovationen).

x

Im Bereich des Managements von Unternehmen werden die folgenden wesentlichen Trends wirksam: Weltweite Marktöffnung (Globalisierung); gestiegene, teilweise gesetzlich geregelte Informationsnachfrage der Anspruchsgruppen (z.B. Risikomanagement, Basel II); Technologieentwicklung (Internet, SOA, EAI,…); neue, stark auf Integration ausgerichtete Managementansätze (Balanced Scorecard, Value Based Management).

3.2

Datenbereitstellung für BI-Konzepte

x

BI wird heute verstanden als unternehmensspezifische, integrierte Lösung mit gemeinsamer harmonisierter Datenhaltung, großen Datenvolumina niedriger Granularität (Transaktions- und Prozessablaufdaten), Einbindung an das betriebliche Wissensmanagement usw.

x

Fazit: Der neue Begriff BI ist sinnvoll, da die traditionelle Bezeichnung Management Support Systems lediglich als Dachbegriff für verschiedenste, oft isolierte Systeme der Managementunterstützung verwendet wird.

Aufgabe V-1-2: Business Intelligence als unternehmensspezifische Lösung Ihre Argumentation könnte folgende Punkte beinhalten:

3.2

x

BI-Anwendungen sind – wie alle IT-gestützten Systeme – stets in den jeweiligen unternehmensindividuellen Kontext zu integrieren. Hierbei sind neben der Anpassung technischer Komponenten vor allem die wechselseitige Abstimmung mit unternehmenskulturellen, aufbau- und ablauforganisatorischen sowie sozialpsychologischen Rahmenbedingungen zu beachten.

x

Entgegen einigen, meist herstellerspezifischen Aussagen können BI-Lösungen somit nicht als Fertigprodukte käuflich erworben werden. Lediglich Werkzeuge oder Rumpflösungen zum Aufbau unternehmensindividueller Lösungen sind am Markt verfügbar.

Datenbereitstellung für BI-Konzepte Basisfragen (B) Aufgabe B-2-1: Operative und dispositive Datenhaltung ‰

Handhabung paralleler Schreibzugriffe durch eine Vielzahl von Benutzern. (Üblicherweise wird auf dispositive Daten lesend zugegriffen.)

61

3

Lösungen und Lösungsskizzen ‰ Dominanz zeitpunktbezogener Datenhaltung. (Dispositive Daten beschreiben i.d.R. Zeiträume.) 5 Primär Ergänzung statt Überschreiben bestehender Daten. 5 Überwiegend Vorhaltung aggregierter Daten. (Die Identifikation betriebswirtschaftlich relevanter Zusammenhänge beruht meist auf der Analyse verdichteter Daten.) ‰

Ausrichtung ausschließlich auf strategische Fragestellungen. (Zunehmend werden dispositive Datenbestände auch für taktische oder sogar operative Managemententscheidungen angelegt.)

5 Zielsetzung: Management- und Entscheidungsunterstützung. 5 Datenhaltung wird auf Basis von Themen bzw. Anwendungsgebieten strukturiert und modelliert. ‰ Abfragen (Queries) sind im Wesentlichen im Voraus bekannt; die Datenhaltung kann entsprechend optimiert werden. (Dispositive Daten sind speziell für komplexe, wechselnde und somit für nicht vollständig antizipierbare Abfragen ausgelegt.) 5 Große Bedeutung historischer Daten. Aufgabe B-2-2: Grenzen der Nutzung operativer Datenbestände für die Managementunterstützung Wesentliche Probleme sind: 1) Beeinträchtigung der Leistung operativer Systeme, da für eine Managementunterstützung umfangreiche Abfragen erforderlich sind, die zudem nur schwer vorhersagbar sind. 2) Die Daten der diversen operativen Systeme sind untereinander nicht harmonisiert und somit üblicherweise inkonsistent. 3) Für jedes managementunterstützende System müssen Extraktions- und Harmonisierungsprozesse neu realisiert werden. Aufgabe B-2-3: Data-Warehouse-Definition x

62

Themenorientierung, also die Ausrichtung auf die Belange der Manager (z.B. Kunden, Regionen, Produkte).

3.2

Datenbereitstellung für BI-Konzepte

x

Integration, also die Zusammenführung aus verschiedensten internen und externen Quellen.

x

Zeitraumbezug, also die Repräsentanz definierter Zeiträume (z.B. Tage, Wochen, Quartale).

x

Non-Volatilität, also die Komplettierung des Datenbestands und nicht die Überschreibung der AltDatenbestände.

Aufgabe B-2-4: Zentrale und dezentrale Data-Warehouse-Architekturen Eine zentrale Data-Warehouse-Architektur x

erleichtert unternehmensweite Analysen durch einen integrierten Datenbestand,

x

erlaubt eine effiziente Wartbarkeit aufgrund einer (logischen) Zentralisierung,

x

schafft bei etablierten DWH-Strukturen eine Reduktion des Entwicklungsaufwandes einzelner Systeme durch Lerneffekte, klare technische Vorgaben und bereits etablierte ETLProzesse und

x

fördert die Kommunikation von Ergebnissen im Unternehmen durch Aufbau eines „Single-Point-of-Truth“.

Aufgabe B-2-5: Komponenten für die dispositive Datenhaltung x

Operational Data Stores, für die Ablage transaktionsorientierter, integrierter Daten,

x

Core Data Warehouses zur bereichs- oder unternehmensumfassenden, anwendungsneutralen und integrierten Datenbereitstellung sowie

x

Data Marts als kleinere anwendungsspezifische Datenpools, die häufig als (transformierte) Extrakte aus dem Core Data Warehouse gebildet werden.

63

3

Lösungen und Lösungsskizzen Aufgabe B-2-6: Operational Data Stores (ODS) ‰

Bei Einsatz eines ODS ist kein Core DWH mehr erforderlich. (Unterschiedliche Anwendungsbereiche, oftmals ist ein ODS einem DWH vorgelagert.)

5

Auf ein ODS kann auch schreibend zugegriffen werden.

5

Ein ODS wird zeitnah aktualisiert.

5

Auf ein ODS greifen oftmals auch operative Systeme zu.

‰

In einem Data Warehouse werden Daten üblicherweise auf Transaktionsebene vorgehalten, in einem ODS üblicherweise in aggregierter Form (Umgekehrt.)

5

In einem ODS werden die Daten üblicherweise nicht dauerhaft hinterlegt.

‰

In einem ODS werden die Daten nicht subjektbezogen vorgehalten.

5

Ein ODS ist besonders für Einsatzszenarien geeignet, in denen Daten in „Real-time“ bereitgestellt werden müssen.

Aufgabe B-2-7: Transformationsschritte Schritte zur Transformation operativer in dispositive Daten: 1) Filterung, als Datenextraktion sowie Bereinigung syntaktischer und semantischer Mängel in den Daten, 2) Harmonisierung, als syntaktische und semantische Abstimmung gefilterter Daten aus unterschiedlichen Quellen sowie deren Anhebung auf eine einheitliche Granularität, 3) Aggregation, als Zusammenfassung von Daten (z.B. durch Summen- oder Mittelwertbildung) auf Basis definierter Aggretationspfade sowie 4) Anreicherung, als Erweiterung des Datenbestandes durch Berechnung betriebswirtschaftlicher Kenngrößen.

64

3.2

Datenbereitstellung für BI-Konzepte

Aufgabe B-2-8: Bereinigungsaktivitäten Beispiele für Bereinigungsaktivitäten: Beispiele für automatisierbare Erkennung und Korrektur: x

Umformatierungen von Einheiten, z.B. Umwandlung von „€“ in „EUR“.

x

Umformatierungen von Zahlendarstellungen, z.B. Übersetzung von Zeichenketten für Altersangaben in Zahlenwerte.

x

Änderung von Feldlängen, z.B. durch längere Felder für Seriennummern.

x

Auffüllen von fehlenden Daten durch Einfügen von interpolierten Werten, beispielsweise Einfügen fehlender Monatsfixkostenwerte durch den Mittelwert der umliegenden Monate.

x

Auffüllen von Angaben, die Plausibilitätsbedingungen verletzten, durch Bezug korrekter Werte aus zusätzlichen Quellen, beispielsweise bei fehlenden Lieferantenangaben.

Beispiele für automatische Erkennung und manuelle Korrektur: x

Überschreiten eines antizipierten Maximalwertes, z.B. wenn der Absatz eines Artikels den vorhandenen Bestand übersteigt.

x

Unüblich hohe oder niedrige Umsatz- und Kostenwerte.

x

Keine Identität von Soll und Haben.

x

Ungewöhnliche Altersangaben (z.B. „98“ bei Zugangsdaten für ein Online-Spiel, das sich an Jugendliche richtet).

Beispiele für manuelle Erkennung und Korrektur: x

Technisch bedingte Fehler im Datenbestand, z.B. durch Überschreiben historischer durch aktueller Werte.

x

Fehlerhafte Daten aufgrund von Missverständnissen bei der Datenerfassung, z.B. fehlerhafte Interpretation einer Angabe zur zukünftigen Bedarfsmenge.

x

Tippfehler, z.B. verdrehte Ziffernfolgen in Seriennummern.

x

Bewusste Falschangaben, z.B. bei Erfassung von Kundenzufriedenheitswerten durch Außendienstmitarbeiter.

65

3

Lösungen und Lösungsskizzen x

Erfundene Werte, z.B. durch Interviewer bei Konsumentenbefragungen.

Aufgabe B-2-9: Harmonisierung der Syntax Situationen in denen die Syntax von zu integrierenden Datenquellen harmonisiert werden muss: 1) Schlüsseldisharmonien, d.h. zur Identifikation eines Objektes werden in unterschiedlichen Systemen unterschiedliche Schlüssel genutzt. 2) Unterschiedliche Codierung von Daten, d.h. identische Eigenschaften werden mit unterschiedlichen Werten beschrieben (Attributnamen und Inhalte sind identisch, Wertebereiche bzw. Domänen unterscheiden sich). 3) Synonyme, d.h. verschiedene Attributnamen identifizieren dieselben Sachverhalte (Bedeutung und Domäne sind identisch). 4) Homonyme, d.h. Attributnamen sind identisch, stehen jedoch für unterschiedliche Bedeutungen. Aufgabe B-2-10: Beispiele für Aufgaben im Bereich der Datentransformation

66

1. Im Kostenrechnungsmodul sind die Fixkosten der einzelnen Filialen pro Monat, im Warenwirtschaftssystem die Deckungsbeiträge pro Produkt, Kunde, Tag und Filiale hinterlegt. Es sollen Filialergebnisse analysiert werden

c. Harmonisierung der Granularität

2. Im CRM-System wird der Kunde in einem Attribut „PARTNER“ geführt, im ERP-System werden Kunden als „CUSTOMER“ bezeichnet. Die Dateien sollen zusammengeführt werden.

e. Harmonisierung von Synonymen

3. Identifizierender Schlüssel eines Artikels ist im Warenwirtschaftssystem eine EANNr., im PPS-System die Seriennummer.

d. Eliminierung von Schlüsseldisharmonien

3.2

Datenbereitstellung für BI-Konzepte

4. Im „Nettoerlös“ sind im neu akquirierten Unternehmen mengenabhängige Vertriebseinzelkosten der Erzeugnisse (z.B. Frachten) bereits grundsätzlich mit eingerechnet, in allen anderen Konzerntöchtern jedoch nicht.

f. Semantische Harmonisierung

5. Für das neue Call-Center in Cottbus liegen aufgrund eines Defekts für den Monat 05-07 keine Daten zu den Gesprächsdauern mehr vor. Für fehlende Zeitangaben werden üblicherweise Durchschnitte als Näherung akzeptiert.

a. Filterung – automatisierbare Erkennung und automatisierbare Korrektur

6. Im Lagerhaltungssystem sind Zugänge und Abgänge pro Artikel erfasst. Es sollen Lagerumschläge analysiert werden.

g. Anreicherung

7. Als Umsatz mit einem Privatkunden ist für den Monat Juni 2007 18.000 EUR für die Produktgruppe „Diverses Staubsaugerzubehör“ eingetragen, obwohl der Wert üblicherweise 1.000 EUR nicht überschreitet.

b. Filterung – automatisierbare Erkennung und manuelle Korrektur

8. Für jeden Handelspartner ist im ERPSystem im Attribut „PARTNER“ die deutsche Bezeichnung des Landes der Hauptniederlassung hinterlegt (z.B. „Deutschland“). In den zu integrierenden Daten aus dem Marktforschungssystem werden im Attribut „PARTNER“ die Länder mit Hilfe ihrer ISO-3166-Kürzel identifiziert (z.B. „.de“).

h. Harmonisierung der Domänen

Aufgabe B-2-11: Core Data Warehouse und Data Marts 5 Ziel eines Data Marts ist die effiziente Unterstützung von Entscheidern einer spezifischen Unternehmenseinheit. ‰ Für die Datenhaltung wird im Core Data Warehouse primär M-OLAP verwendet.

67

3

Lösungen und Lösungsskizzen 5 Im Core Data Warehouse werden Daten üblicherweise in feiner Granularität vorgehalten, im Data Mart hingegen zumeist höher aggregiert. 5 Ein Core Data Warehouse sollte so konzipiert werden, dass es möglichst flexibel für noch nicht vorab bekannte Analyseanwendungen genutzt werden kann. ‰ Im Core Data Warehouse werden die Daten auf abteilungsspezifische Bedürfnisse ausgerichtet. 5 In der Regel erlauben Data Marts den Endbenutzern direkte Zugriffe auf die Daten. Aufgabe B-2-12: Begriffe der Metadatenhaltung Bezeichnung für Metadaten, die unmittelbar von den BIWerkzeugen gelesen und zu Steuerungszwecken verarbeitet werden können: Aktive Metadaten Bezeichnung für ein Metadaten-System, das logisch zentralisiert ist, dafür aber auf mehreren unterschiedlichen physischen Metadatenhaltungssystemen aufsetzt: Föderiertes Metadatenmanagement Referenzmodell der OMG für technische Metadaten zur Standardisierung des Austauschs von DWH-Metadaten: Common Warehouse Metamodel Aufgabe B-2-13: Metadaten der Datentransformation

68

1. Metadaten zur Kennzahlenbildung

e. Anreicherung

2. Metadaten über die Charakteristika der ERP-Umgebung

a. Quelldaten

3. Metadaten über Regeln zur Behandlung „leerer“ Felder in Quelldaten

b. Filterung

3.2

Datenbereitstellung für BI-Konzepte

4. Metadaten zur Vereinheitlichung der Granularität

c. Harmonisierung

5. Metadaten zu Dimensionshierarchisierungen

d. Aggregation

6. Metadaten zu Benutzerprofilen

f. Informationszugriff

Verständnisfragen (V) Aufgabe V-2-1: Diskussion der Data-Warehouse-Definition von William H. Inmon ƒ

Die Definition von William H. Inmon ist weiterhin für die meisten Anwendungsdomänen relevant.

ƒ

Die Kriterien Subjektorientierung, Integration und NonVolatilität sind für die Entscheidungsunterstützung prägend.

ƒ

Das Kriterium Zeitraumbezug hingegen steht heute in einigen Fällen in der Diskussion. Aufgrund technischer Fortschritte im Hard- und Softwarebereich ist eine transaktionsorientierte Datenhaltung für das Core DWH heute realistisch. Die Vorteile eines solchen Core DWH liegen vor allem in der Mehrfachverwendbarkeit transformierter Daten niedriger Granularität, die eine flexible Befüllung diverser Data Marts in verschiedenen Granularitätsstufen erlaubt.

Aufgabe V-2-2: BI – Operative und dispositive Daten x

Einsatzfeld operativer Daten: Abwicklung der Geschäftsprozesse, z.B. Aufnahme einer Kundenbestellung, an die die Kommissionierung der bestellten Ware anschließt. Einsatzfeld dispositiver Daten: Informationen für das Management, Entscheidungsunterstützung, z.B. Visualisierung der zeitlichen Entwicklung des Bestellbestandes, differenziert nach Produktgruppen.

69

3

70

Lösungen und Lösungsskizzen x

Ausrichtung operativer Daten: Detaillierte Geschäftsvorfalldaten, beispielsweise Angaben zu einem Lagerzugang. Ausrichtung dispositiver Daten: Transformierte Daten, z.B. Angaben zum durchschnittlichen Lagerbestand pro Monat und Artikeltyp.

x

Zeitbezug operativer Daten: Aktuell; zeitpunktbezogen; auf die Transaktion ausgerichtet, z.B. der aktuelle Status eines Fertigungsauftrags. Zeitbezug dispositiver Daten: Unterschiedliche, aufgabenabhängige Aktualität; Historienbetrachtung, z.B. sind für die Erstellung eines Quartalsreports mit Angaben zur langfristigen Entwicklung der Fertigungskosten monatsaktuelle Daten ausreichend.

x

Zustand operativer Daten: Häufig redundant; inkonsistent; unnormalisiert, z.B. werden Kundendaten oftmals in den unterschiedlichen Systemen (Webshop, ERP-System, CRMSystem) in heterogener Form vorgehalten und speziell in kleineren Systemen in denormalisierter Form hinterlegt (z.B. drei Felder für Anschriften in einer Tabelle). Zustand dispositiver Daten: Konsistent modelliert; kontrollierte Redundanz, beispielsweise sollten für analytische CRMSysteme Kundendaten aus den diversen Marketing-, Serviceund Vertriebssystemen zusammengezogen werden können. Dies erfordert eine konsistente und systematische Modellierung aller kundenbezogenen Daten.

x

Update bei operativen Daten: Laufend und konkurrierend, z.B. laufende Aktualisierung des Lieferstatus durch die beteiligten Logistikpartner. Update bei dispositiven Daten: Ergänzend; Fortschreibung abgeleiteter, aggregierter Daten, z.B. Festhalten summierter Liefermengen pro Tag. Daten zu neuen Tageslieferungen werden jeweils ergänzt.

x

Queries bei operativen Daten: Strukturiert; meist statisch im Programmcode, beispielsweise Abfrage der Daten zu einer Bestellung. Queries bei dispositiven Daten: Ad-hoc für komplexe, ständig wechselnde Fragestellungen, z.B. Auswertung der Bestellmengen wahlweise nach Kundengruppen und Produkten oder pro Zeit und Region sowie vorgefertigte Standardauswertungen, z.B. ein Standardbericht zur Entwicklung der Bestellbestände.

3.2

Datenbereitstellung für BI-Konzepte

Aufgabe V-2-3: Virtuelle Data Warehouses / Enterprise Information Integration In einer Antwort könnten folgende Argumente ausgeführt werden: x

Die Heterogenität der gewachsenen Infrastrukturen (LegacySysteme) erschwert den Zugriff auf das relevante Datenmaterial.

x

Die Ressourcenbelastung für operative Systeme ist aufgrund der schweren Antizipierbarkeit von Managementabfragen kaum kalkulierbar.

x

Die für Managementabfragen wichtigen Zeitreihenbetrachtungen sind aufgrund der häufig nicht existenten Historienführung in operativen Systemen zumeist unmöglich.

x

Operative Daten können lediglich mit Hilfe umfangreicher Transformationsregeln in relevante Managementinformationen überführt werden. Diese Transformationsschritte sind im Fall des „Virtuellen Data Warehouses“ für jede Abfrage neu zu durchlaufen.

x

Eine systematische Pflege der integrierten Datenbestände (inklusive einer systematischen, oftmals teilweise manuellen Identifikation und Korrektur von Mängeln in den Datenbeständen) ist mit einem virtuellen Data Warehouse nur sehr eingeschränkt möglich.

Fazit: x

Unternehmensweite BI-Lösungen sind ohne dispositive Datenhaltung nur schwer realisierbar.

x

Für abgegrenzte „Real-time“-Anwendungen zur Unterstützung operativer Prozesse, in denen die Aktualität wichtiger ist als die Qualität der Daten, kann ein flankierender Einsatz eines „Virtuellen Data Warehouses“ sinnvoll sein.

dedizierte

Aufgabe V-2-4: Data-Warehouse-Alternativen für einen Kosmetikhersteller Mögliche Punkte zur Einordnung und Abgrenzung des Falls x

Es wird eine Neuentwicklung einer Lösung betrieben. Gleichzeitig muss jedoch auf die Existenz bestehender Ma71

3

Lösungen und Lösungsskizzen nagementunterstützungs-Lösungen werden. x

Rücksicht

genommen

Besondere Herausforderungen entstehen durch die Notwendigkeit zur Integration externer Daten sowie durch die „Realtime“-Anforderungen.

Alternative 1: „Unabhängige Data Marts“ x

Bestehende Anwendungen können getrennt weiterbetrieben werden. Das Projekt kann dadurch effizient abgewickelt werden.

x

Die Architektur unterstützt das Design einer vollständig auf die betroffene Anwendung ausgerichtete, performante Lösung.

x

Nachteile liegen in der Begrenzung der Analysemöglichkeiten, der limitierten Ausbaubarkeit sowie im entstehenden Aufwand für Betrieb und Wartung der parallelen Datenhaltungssysteme mit jeweils individuellen ETLProzessen.

Alternative 2: „Zentrales Core Data Warehouse ohne Data Marts“

72

x

Bringt eine Bereinigung der bestehenden Infrastruktur mit sich, geht damit jedoch deutlich über die ursprüngliche Zielsetzung hinaus.

x

Führt zu erheblichen Kosten und organisatorischen Herausforderungen aufgrund der notwendigen Datenharmonisierung und Anwendungsintegration.

x

Möglicherweise kommt es im späteren Betrieb durch parallele Direktzugriffe auf das neue Core Data Warehouse zu Performanceengpässen.

x

Da Daten in einem Core Data Warehouse oftmals in geringerem Maße anwendungsspezfisch aufbereitet werden können, kann der Ansatz gegenüber Data-Mart-basierenden Lösungen zu Performancenachteilen führen.

x

Vorteile liegen in der auf Erweiterbarkeit ausgelegten zentralisierten Systemlandschaft und den weit reichenden Analysemöglichkeiten (beispielsweise für Analysen zur Auswirkung von Preissenkungen auf den Servicegrad und die Lagerbestände).

3.2

Datenbereitstellung für BI-Konzepte

Alternative 3: „Data Warehouse mit nachgelagerten Data Marts“ – Hub-and-Spoke-Architektur. x

Die Performancenachteile einer zentralen Lösung werden vermieden.

x

Es entsteht eine ausbaubare und integrierte Lösung, die hier mit den Vorteilen anwendungsoptimierter Datenhaltungen verknüpft wird.

x

Wie bei einer zentralen Lösung entsteht jedoch Aufwand für Integration und Ablösung der bestehenden Data-Martbasierten Lösungen.

Bedeutung eines ODS x

Für „Real-time“-Anforderungen und die Verknüpfung mit operativen Systemen kann die Entwicklung eines ODS erforderlich sein.

x

Dies sollte bereits beim Design der Datenhaltung vorgesehen werden, um eine effiziente Integration von ODS und Core Data Warehouse zu ermöglichen.

Aufgabe V-2-5: Transformationsprozesse bei der Anbindung von Daten aus einem mobilen Wartungssystem Beispiele für mögliche Probleme mit der Datenqualität im beschriebenen Fall: x

Die Freitextfelder sind nicht ohne weiteres durch den Einsatz von Informationssystemen auswertbar.

x

Bei den optionalen Feldern besteht die Gefahr, dass diese nur in Ausnahmefällen ausgefüllt werden.

x

Bei den Muss-Textfeldern können beliebige Inhalte eingegeben werden, was zu unbrauchbaren Daten führen kann.

x

Das Feld "Allgemeine Angaben zum Kunden" hat keine klare Zweckeingrenzung und ist somit nicht ohne Weiteres eindeutig interpretierbar.

x

Es besteht das Risiko, dass es zur Häufung von Vorgabewerten kommt ("unspezifizierte technische Störung"), die nicht die korrekten Sachverhalte repräsentieren.

73

3

Lösungen und Lösungsskizzen x

Weitere Herausforderungen liegen in der Zusammenführung mit den Vertriebs- und Finanzdaten durch unzureichend harmonisierte Daten (z.B. die Angabe der Kundenbezeichnung).

Beispiele für prozesse:

voraussichtlich

erforderliche

Transformations-

x

Filterung: Extraktion der Daten sowohl aus dem Servicesystem als auch aus dem ERP-System.

x

Filterung: Automatische Bereinigung semantischer Fehler, z.B. Korrektur von unvollständigen Ortsangaben mit Hilfe bestehender Referenzdaten.

x

Filterung: Automatische Identifikation und manuelle Bereinigung syntaktischer Fehler, z.B. fehlerhafte und nicht auflösbare Komponentenangaben.

x

Filterung: Automatische Identifikation und manuelle Bereinigung semantischer Fehler, z.B. unstimmige Angaben von Bearbeitungsminuten.

x

Filterung: Manuelle Bereinigung semantischer Fehler, z.B. Überprüfung des angegebenen Problemtyps, wenn der Vorgabewert „unspezifizierte technische Störung“ gewählt wurde.

x

Harmonisierung: Syntaktische Harmonisierung durch Bereinigung der Homonyme, Synonyme und Codierungsinkonsistenzen, z.B. für die Angleichung der Kundenidentifikation im ERP- und im Servicesystem.

x

Aggregation: Verdichtung der Daten, z.B. durch monatsweise Zusammenfassung von Bearbeitungszeiten, Besuchshäufigkeiten oder Besuchsfrequenzen.

x

Anreicherung: Bildung von Kennzahlen, z.B. zur Produktivität der Servicemitarbeiter.

Schlussfolgerung: x

74

Evtl. kann es sinnvoll werden, die Eingabemaske im Servicesystem zu überarbeiten, insbesondere durch Definition von zusätzlichen Mussfeldern, durch Einbindung von Plausibilitätsprüfungen und vorgegebenen Antwortkategorien sowie durch Verzicht auf Standardangaben.

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext x

3.3

Flankierend sind organisatorische Maßnahmen zur Sicherstellung der Datenqualität zu erwägen (z.B. Sanktionen bei mangelhafter Ausfüllung).

Performanceoptimierte Datenmodellierung im relationalen Kontext Vorbemerkung: Alle ER-Modelle im Aufgaben- und im Lösungsteil folgen der Schlageter/Stucky-Notation. Dabei gibt die Kardinalität eines Entitätstyps jeweils an, wie oft eine Entität dieses Typs in die Beziehungen des jeweiligen Beziehungstyps eingehen kann.

Basisfragen (B) Aufgabe B-3-1: ERM-Notation

kein Attribut von Leistung ZUSAMMENSETZUNG

Relationen können nur zwischen Entitäten hergestellt werden. VERTRAGS#

n m

SLA

m

SPEZIFIZIERT

n

LEISTUNG

m ZUSAMMENGEFASST IN n

WERKVERTRAG

VERTRAG DIENSTLEISTUNGSVERTRAG

Kritik am Modell: ‰ Ein Entitätstyp darf keine Beziehung zu sich selbst eingehen. Eine Entität eines Entitätstyps kann sehr wohl mit anderen Entitäten desselben Typs verknüpft werden. Solche „reflexiven

75

3

Lösungen und Lösungsskizzen Beziehungen“ werden beispielsweise auch genutzt, um Stücklisten abzubilden. ‰ „WERKVERTRAG“ und „DIENSTLEISTUNGSVERTRAG“ müssen über einen Beziehungstyp mit „VERTRAG“ verknüpft werden. Es handelt sich um die Modellierung einer Generalisierung / Spezialisierung. ; Beziehungstypen dürfen nicht ohne Uminterpretation in andere Beziehungstypen eingehen, daher ist die gezeigte Verbindung zwischen „SPEZIFIZIERT“ und „ZUSAMMENGEFASST IN“ falsch. ‰ Bei „WERKVERTRAG“ und „DIENSTLEITUNGSVERTRAG“ fehlen Kardinalitäten. Bei einer Generalisierung / Spezialisierung werden üblicherweise keine Kardinalitäten angegeben. ; Zur „LEISTUNG“ gehören keine Attribute des Entitätstyps „VERTRAG“.

Aufgabe B-3-2: ERM für Wartungsverträge

MASCHINE

m

BESTEHT AUS

1

KOMPONENTE

m

WARTUNGS VERTRAG

n

KUNDE

76

...

...

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Das gezeigte Modell drückt Folgendes aus: 5 Eine Maschine kann aus mehreren Komponenten bestehen. ‰

Eine Komponente kann auch ohne Zuordnung zu einer Maschine angelegt werden.

5 Ein Wartungsvertrag ist immer einer Maschine und einem Kunden zugeordnet. 5 Zu einer Maschine können mehrere Wartungsverträge abgeschlossen werden. ‰

Jeder Kunde schließt einen oder mehrere Wartungsverträge ab. Eine Entität des Entitätstyps „KUNDE“ muss nicht zwangsläufig in die Assoziation „WARTUNGSVERTRAG“ eingehen.

‰

Bei einem Kunden sind immer mehrere Komponenten zu warten.

; Ein „WARTUNGSVERTRAG“ wird als eigenständiger Entitätstyp interpretiert, der Beziehungen zu weiteren (hier gestrichelt angedeutet) Entitätstypen eingehen kann. Das Rechteck um die Relation kennzeichnet eine Uminterpretation. Aufgabe B-3-3: Modellierung eines Reparaturauftrags Abbildung der Anforderung „Ein Reparaturauftrag beinhaltet den Erfassungszeitpunkt, den betroffenen Kunden, einen Schaden und eine Filiale. Für jeden Schaden kann es maximal einen Reparaturauftrag geben.“

77

3

Lösungen und Lösungsskizzen

KUNDE

n

1)

m

FILIALE

REPARATURAUFTRAG

In dieser Variante können jedem Schaden mehrere Reparaturaufträge zugeordnet werden.

o

ZEIT

p

SCHADEN

KUNDE

n

2)

m

FILIALE

REPARATURAUFTRAG

o

ZEIT

9

0,1

SCHADEN

korrekte Lösung

KUNDE

Bei dieser Variante muss es zu jedem Zeitpunkt genau einen Reparaturauftrag geben. Gleichzeitig kann pro Zeitpunkt maximal ein Auftrag erfasst werden.

n

3)

FILIALE

m

REPARATURAUFTRAG 0,1

SCHADEN

78

1

ZEIT

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext

KUNDE n

m

FILIALE

4)

REPARATURAUFTRAG

Ein Auftrag kann in dieser Variante auch ohne Angabe des Schadens existieren.

1

ZEIT

0, 1 BEZIEHT SICH AUF m

Jedem Schaden können hier 0,1 oder beliebig viele Reparaturaufträge zugeordnet werden.

SCHADEN

Aufgabe B-3-4: ERM und Relationenmodell

KUNDE o

ZEIT

n

KAUF

1

GEHÖRT ZU

n

WARENKORB

m ARTKEL

Welche der folgenden Relationen wurden korrekt aus dem gezeigten ERM abgeleitet? ; KUNDE (Kunden#,...) Jeder Entitätstyp wird durch eine Relation umgesetzt.

79

3

Lösungen und Lösungsskizzen ‰

ARTIKEL (Artikel#, Kunden#, Zeit,...) Kunden# und Zeit sind nicht in ARTIKEL abzulegen, da ansonsten Wiederholungsgruppen notwendig würden.

‰

KAUF (Artikel#, Zeit, Kunden#,...) Der Entitätstyp „KUNDE“ geht in den Beziehungstyp „KAUF“ ein – der Primärschlüssel der Relation „KUNDE“ muss damit auch Teil des Primärschlüssels von „KAUF“ werden.

‰

KAUF (Artikel#, Zeit, Kunden#, Warenkorb#,...) Der Entitätstyp „WARENKORB“ geht nicht in den Beziehungstyp „KAUF“ ein. Der Primärschlüssel von Warenkorb wird somit auch nicht Teil von dessen Primärschlüssel!

; KAUF (Artikel#, Zeit, Kunden#, Warenkorb#,...) ‰

GEHÖRT_ZU (Kunden#, Artikel#, Zeit, Warenkorb#,...) Die Relation ist aufgrund der 1-n-Beziehung nicht erforderlich. Die Beziehung ist mit einem Fremdschlüssel in „KAUF“ umzusetzen.

‰

WARENKORB (Warenkorb#, Artikel#, Zeit, Kunden#,...) Ein Warenkorb kann mehrere Käufe zusammenfassen. Die Fremdschlüssel sind demnach nicht korrekt.

Aufgabe B-3-5: Normalisierung – erste Normalform Welche der folgenden Relationen befindet sich in erster Normalform? ‰ KUNDE (Kunden#, Vorname, Nachname, Anschrift_1, Anschrift_2) Mit der Wiederholungsgruppe „Anschrift_1, Anschrift_2“ wird die 1NF verletzt – eine einzelne Anschrift kann nicht eindeutig über eine Kundennummer identifiziert werden. ; BESTELLUNG (Kunden#, Bestelldatum, Artikel#, Artikel, Artikelgruppe) ‰

WARTUNG (Auftrags#, Reparierte_Komponente_1, Reparierte_Komponente_2, Reparierte_Komponente_3, Reparierte_Komponente_4, WeitereReparierteKomponenten) Hier sind die „REPARIERTEN KOMPONENTEN“ nicht funktional vom Schlüssel abhängig.

; BESTELLPOSITION (Bestell#, Positions#, Positionsbeschreibung, Artikel#, Anzahl, Listenpreis) ; ARTIKEL (Artikel#, Artikelname, Artikelgruppe) 80

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Aufgabe B-3-6: Normalisierung – zweite Normalform Welche der folgenden Relationen befindet sich in zweiter Normalform? ; KUNDE (Kunden#, Vorname, Nachname, Kundengruppen#, Kundengruppenname) ‰ BESTELLUNG (Kunden#, Bestelldatum, Artikel#, Artikel, Artikelgruppe) Artikel und Artikelgruppe sind nur von einem Schlüsselattribut, nicht aber vom ganzen Schlüssel abhängig. ; Artikel (Artikel#, Artikelname, Artikelgruppen#, Artikelgruppe) Aufgabe B-3-7: Normalisierung – dritte Normalform Welche der folgenden Relationen befindet sich in dritter Normalform? ‰ KUNDE (Kunden#, Vorname, Nachname, Kundengruppen#, Kundengruppenname) Der Kundengruppenname ist funktional von der Kundengruppen# abhängig. ; BESTELLPOSITION (Bestell#, Positions#, Artikel#, Anzahl, Listenpreis) ‰ ARTIKEL (Artikel#, Artikelname, Artikelgruppen#, Artikelgruppe) Die Artikelgruppe ist funktional von der Artikelgruppen# abhängig.

81

3

Lösungen und Lösungsskizzen Aufgabe B-3-8: Normalisierung – Normalformen Welche der drei Normalformen sind verletzt? Verletze Normalform PATIENT

1NF

2NF

3NF

5

5

5

‰

‰

5

(Patienten#, Liste_Diagnosen)

Ein Attribut in 1NF darf keine „Liste“ enthalten. FILIALE

(Filial#, Bundesland, Land)

Das Land kann über das Bundesland bestimmt werden. ARTIKEL

(Artikel#, Artikelbezeichnung, Artikelgruppen#, Artikelgruppenleiter)

‰

‰

5

Das Attribut „Artikelgruppenleiter“ ist funktional abhängig vom Attribut „Artikelgruppennr.“ BUCHUNG (Sollkonto#, Habenkonto#, Betrag, KontentypSoll, KontentypHaben)

‰

5

5

„KontentypSoll“ ist lediglich vom Schlüsselattribut „Sollkontennr.“ funktional abhängig, nicht jedoch vom gesamten Schlüssel. Analog: „Habenkontennr.“ und „KontentypHaben“. BESTELL

(Kunden#, Artikel#, Datum, Menge, Lieferart, Transportgesellschaft, Transportgesellschaft_Tel)

‰

‰

5

„Transportgesellschaft_Tel“ ist funktional von der Transportgesellschaft abhängig.

82

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Aufgabe B-3-9: Konzepte multidimensionaler Datenmodellierung Wie werden die folgenden Ansätze üblicherweise bezeichnet? 1) Anfertigen von Sicherungskopien, um Datenbereiche bei fachlichem Bedarf (z.B. Revision, Rechtsstreit) wiederherstellen zu können: Archivierung 2) Angelsächsische Bezeichnung für den Sachverhalt, dass auch Dimensionstabellen üblicherweise im Zeitverlauf Änderungen unterliegen, denen technisch wie betriebswirtschaftlich begegnet werden muss: Slowly Changing Dimensions 3) Aufteilung der Dimensionstabellen zur Performanceoptimierung, oftmals auf Grundlage der definierten Aggregationen und in Verknüpfung mit Summationstabellen: „Snowflaking“ (Ergebnis: Snowflake-Schema) 4) Integration mehrerer Star-Schemata auf Basis strukturidentischer Dimensionstabellen: Galaxie 5) Historisierungsverfahren, bei dem bei jeder Aktualisierung einer Dimensionstabelle sämtliche Datensätze – also sowohl die geänderten wie auch die unveränderten – an die existierende Tabelle angehängt werden: Snapshot-Historisierung 6) Sicherung von Datenbeständen auf speziellen Sicherungsmedien, um bei technischem Systemfehlverhalten Datenbereiche wiederherstellen zu können: Backup

83

3

Lösungen und Lösungsskizzen 7) Konzepte, mit deren Hilfe Änderungen von Attributsausprägungen, Beziehungen und Entitäten im Zeitablauf dokumentiert werden: Historisierung 8) Schema mit generierten, abhängigen Summationstabellen zur Performancesteigerung bei Analysen auf aggregierten Daten: Fact-Constellation-Schema 9) Historisierungsverfahren mit zeilengenauer Historisierung der Dimensionstabellen: Delta-Historisierung 10) Attribut zur Markierung aktuell gültiger Daten. Current Flag

Aufgabe B-3-10: Eigenschaften des Star-Schemas Welche der folgenden Aussagen sind korrekt? ‰ Das Star-Schema ist die Datenhaltung von M-OLAPSystemen. M-OLAP-Systeme setzen auf nicht-relationalen, proprietären Datenhaltungssystemen auf. ; Mit einem Star-Schema kann eine multidimensionale Datenhaltung realisiert werden. ‰ „Star-Schema“ und „OLAP“ sind Synonyme. Das Star-Schema dient der Realisierung einer multidimensionalen Datenhaltung mit relationalen Strukturen. Diese muss nicht zwangsläufig für OLAP-Anwendungen genutzt werden. Andererseits muss OLAP nicht unbedingt mit einem StarSchema realisiert werden. ‰ Fakten im Star-/Snowflake-Schema sind ausschließlich monetäre Kennzahlen. Häufig dienen auch nicht-monetäre Kennzahlen als Fakten, beispielsweise Zeiten, Mengen oder Volumenangaben.

84

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext ‰

Dimensionstabellen sind häufig wegen der umfangreichen Attributierung sehr groß, Faktentabellen hingegen aufgrund der wenigen zu hinterlegenden Kennzahlen (jeweils nur zwei oder drei Kennzahlen pro Zeile) sehr klein. Tatsächlich ist die Größe der Dimensionstabellen in den meisten Fällen im Vergleich zur Faktentabelle vernachlässigbar. Die Faktentabelle repräsentiert eine Relationsmenge, es können daher im äußersten Fall für jede Kombination aus Dimensionswerten Tupel auftreten.

‰

Im Star-Schema wird häufig die zweite Normalform verletzt. Nein. Es wird jedoch häufig die 3NF verletzt.

; Die Redundanz im Star-Schema ist vertretbar, da auf die entsprechenden Daten primär lesend zugegriffen wird.

Aufgabe B-3-11: Analysen auf Basis eines Star-Schemas DT_Zeit

DT_Produkt

KZeit

KProdukt

Monat Jahr

Produkt KProduktgruppe Produktgruppe Maße

FT_Umsatzanalyse

DT_Verkäufer KVerkäufer Name KRegion Region KLand Land

KZeit KVerkäufer KProdukt KKundentyp Umsatz Var.-Kosten DT_Kundentyp KKundentyp Kundentyp

Nicht möglich sind mit dem gezeigten Datenmodell folgende Auswertungen: ‰ Entwicklung des Deckungsbeitrags (= Umsatz abzüglich der variablen Kosten) im Zeitverlauf. Die Deckungsbeiträge können „on-the-fly“ berechnet werden. Es wäre jedoch zu überlegen, die Faktentabelle direkt mit im Voraus berechneten Deckungsbeitragswerten anzureichern, um Antwortzeiten zu reduzieren. 85

3

Lösungen und Lösungsskizzen ; Vergleich der variablen Kosten je Geschäftsjahr. Das Geschäftsjahr weicht üblicherweise vom Kalenderjahr ab. In der Zeitdimension sind jedoch keine Angaben zum Geschäftsjahr enthalten, anhand derer aggregiert werden kann. ; Gewinne pro Filiale für die Region 3. Für die Berechnung von „Gewinnen“ fehlen Daten zu den Fixkosten. ‰ „Top 10“ der deckungsbeitragsstärksten Produkte. ‰ Performanceanalyse der Verkäufer in den verschiedenen Regionen. ‰ Identifizierung der umsatzstärksten Kundentypen. ; Optimierung der Regalnutzung (Deckungsbeitrag / benötigte Regalfläche). Über die vorhandene Regalfläche liegen keine Daten vor. ‰ Vergleich des durchschnittlichen Umsatzes pro Kundentyp. Verdichtungen können nicht nur durch Summen- sondern auch durch Durchschnittsbildung erfolgen. Aufgabe B-3-12:

SnapshotHistorisierung

DeltaHistorisierung

Im Call-Center eines Versandunternehmens mit Telefonvertrieb werden die Mitarbeiter jeweils bestimmten Vorwahlbereichen zugeordnet. Für Performance-Analysen wird ein Star-Schema entworfen, das u.a. eine Telefonnummer enthält. Die Telefonnummern der Kunden ändern sich regelmäßig. Ob entsprechende Änderungen eingepflegt wurden, ist nicht direkt aus den operativen Daten ersichtlich.

Update

Auswahl von Historisierungsverfahren

‰

5

‰

Ein Update würde die in den Telefonnummern enthaltenen analyserelevanten Zuständigkeitsinformationen überschreiben. 86

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Ein Telekommunikationsunternehmen speichert Verbindungsdaten für eine große Zahl an Privatkunden. Alle Änderungen an den Kundenstammdaten (z.B. neue Kundenadresse, verantwortlicher Ansprechpartner) werden automatisch protokolliert. In den Analysen sind die Kundendaten den im jeweiligen Betrachtungszeitraum verantwortlichen Servicemitarbeitern zuzuordnen.

‰

‰

5

‰

‰

Die große Kundenzahl spricht gegen eine SnapshotAktualiserung. Für die Serviceoptimierung eines Herstellers von Laser-Schneidemaschinen wird ein StarSchema entworfen, in dem u.a. eine Kundendimension mit der E-Mail-Adresse des Hauptansprechpartners vorgesehen ist. Im zugrunde liegenden operativen CRM-System werden alle Änderungen an den Stammdaten protokolliert – auch die der E-MailAdressen.

5

Historische E-Mail-Adressen von Ansprechpartnern sind aller Voraussicht nach nicht analyserelevant.

Aufgabe B-3-13: Eigenschaften von Historisierungsverfahren Welche der folgenden Aussagen sind korrekt? ‰ Eine Historisierung mit Gültigkeitsfeldern ist einer DeltaHistorisierung immer vorzuziehen, da hierdurch genauere Zuordnungen möglich werden! Eine Delta-Historisierung steht nicht im Widerspruch zur Nutzung von Gültigkeitsfeldern. In der Tat werden die beiden Verfahren oftmals kombiniert. ; Das „Update-Verfahren“ ist kein Historisierungsverfahren. ; Über die Zeitstempel werden bei Historisierungsverfahren sowohl kumulierte Faktenabfragen über aktuelle Dimensionsausprägungen als auch zeitpunktbezogene Auswertungen des Datenbestandes ermöglicht.

87

3

Lösungen und Lösungsskizzen ; Current-Flags vereinfachen den Umgang mit Änderungen in den Dimensionstabellen. ‰ Bei Delta-Historisierung mit künstlicher Schlüsselerweiterung können zwar Änderungen an den Dimensionsdaten nachvollzogen werden, es sind jedoch keine zeitpunktbezogenen historischen Auswertungen der Fakten möglich, da in der Faktentabelle lediglich auf die aktuellen Zeilen der Dimensionstabellen verwiesen wird. Eine Schlüsselerweiterung ist im Kontext einer DeltaHistorisierung ermöglicht eine flexible Analyse der Fakten, da die Schlüsselerweiterungen in Dimensions- und Faktentabellen existieren.

Verständnisfragen (V) Aufgabe V-3-1: Datenmodell für die Erfassung von Kundenreklamationen Ein mögliches ERM für das CRM-System könnte wie folgt aussehen:

KUNDE

1

GEHÖRT ZU

m

KUNDENGRUPPE

o

ZEIT

n

BESCHWERDEANRUF

m

HELP-DESK MITARBEITER n

m

THEMATISIERT

n

LEICHTE STÖRUNG STÖRUNGSKLASSE

STÖRUNG SCHWERE STÖRUNG

LÖSUNGSWEG

88

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Und ein abgeleitetes relationales Modell wie folgt: KUNDENGRUPPE

(Kundengruppen#)

KUNDE

(Kunden#, KundenGruppen#)

HELPDESKMITARBEITER

(MA#)

STÖRUNG

(Störungs#)

ANRUF

(MA#, Kunden#, Zeit)

THEMATISIERT

(MA#, Kunden#, Zeit, Störungs#)

STÖRUNG

(Störungs#, Störungsbeschreibung)

LEICHTE_STÖRUNG

(Störungs#, Standardlösung)

SCHWERE_STÖRUNG

(Störungs#, Störungsklasse, Problemlösungsweg)

Aufgabe V-3-2: Datenmodell für die Raumplanung Das ERM für die Raumplanung könnte wie folgt ausgearbeitet werden:

BÜRO

GEHÖRT ZU

1

HAUS

n

1 BETREUT m n BELEGUNG

n

MITARBEITER

HAUSMEISTER

o

ZEIT

n

1VERURSACHT

1

KOSTENPOSITIONEN

89

3

Lösungen und Lösungsskizzen Und ein abgeleitetes relationales Modell wie folgt: BÜRO

(Büro#, Haus#)

HAUS

(Haus#, Personal#)

MITARBEITER

(Personal#, Name,...)

HAUSMEISTER

(Personal#, … )

BELEGUNG

(Büro#, Pers#, Zeit)

KOSTENPOSITION (Pos#, Büro#, Pers#, Zeit, Kostenart, Betrag)

Aufgabe V-3-3: Normalisierung für ein Fakturierungssystem Vorgefundenes Schema: RECHNUNG

(V#, Zeit, K#, KundeNachname, KundeVorname, KundeAnschrift, KundeTel,...)

RECHNUNGSPOS

R#, Artikel#, Artikelbezeichnung, Anzahl,...)

ARTIKEL

(Artikel#, Bezeichnung, Artikeltyp#, Artikeltypbezeichnung, Zulieferer_1, Zulieferer_2, Zulieferer_3,...)

VERKÄUFER

(V#, Nachname, Vorname,...)

Das Schema weist folgende Normalformenverletzungen auf:

90

ƒ

Verletzung der 1. Normalform: In der Artikelrelation wird eine Liste von drei Zulieferern geführt. Problem: Diese Modellierung limitiert das Schema künstlich auf 3 Zulieferer pro Artikel.

ƒ

Verletzung der 2. Normalform: In der Rechnungsrelation werden diverse Angaben zu Kunden geführt – diese sind jedoch nur von der Kundennummer abhängig und nicht vom gesamten Schlüssel. Problem: Bei mehreren Rechnungen für denselben Kunden müssen Kundenname, Anschrift und Telefonnummer immer wieder neu eingegeben werden. Neben der

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext entstehenden Mehrarbeit wächst auch das Risiko von Inkonsistenzen im Datenbestand. Aussagekräftige Abfragen, Auswertungen oder Vergleiche sind auf dieser Grundlage problematisch. ƒ

Verletzung der 2. Normalform: In der Relation „Rechnungsposition“ ist die Artikelbezeichnung nicht vom vollen Schlüssel sondern lediglich von der Artikelnummer abhängig. Problem: Auch hier kommt es zur redundanten Datenhaltung mit dem Risiko inkonsistenter Artikelbezeichnungen.

ƒ

Verletzung der 3. Normalform: Die Artikeltypbezeichnung in der Artikelrelation ist funktional von der Artikeltyp# abhängig. Problem: Für alle Artikel desselben Typs muss neben der Artikeltyp# auch die Artikeltypbezeichnung korrekt eingegeben werden. Hierdurch ergibt sich Redundanz und somit die Gefahr von Inkonsistenz innerhalb des Datenbestandes.

Alternativer Vorschlag: VERKÄUFER

(V#, Nachname, Vorname,...)

ZULIEFERER

(Z#, Name, Vorname, …)

KUNDE

(K#, KundeNachname, KundeVorname, KundeAnschrift, KundeTel, ...)

ARTIKEL

(Artikel#, Bezeichnung, Artikeltyp#,…)

ARTIKELTYP

(Artikeltyp#, Artikeltypbezeichnung, ...)

RECHNUNG

(V#, Zeit, K#, ...)

RECHNUNGSPOS

(V#, Zeit, K#, Artikel#, Anzahl)

ZULIFERUNG

(Artikel#, Z#)

91

3

Lösungen und Lösungsskizzen Aufgabe V-3-4: Normalisierung und Datenqualität Vorgefundenes Relationenschema: WART_AUFTRAG

(Kunden#, Bearbeiter#., Datum, Maschinen#, Auftragstyp_1, Auftragstyp_2, Bearbeitername, BearbeiterProvisionssatz,...)

BEARBEITER

(Bearbeiter#, Name, Vorname, Position, Provisionssatz,...)

KUNDE

(Kunden#, Firmenname, Handelsregistereintrag, Kundengruppen#, Kundengruppenbezeichnung, Region, Marketingleiter_Region,...)

MASCHINE

(Maschinen#, Maschinentyp, Maschinentypbeschreibung,...)

STÖRUNG

(Maschinen#, Kunden#, Bearbeiter#, Datum, Maschinentyp, Störungstyp, BeschreibungStörungstyp,...)

KOMPONENTE

(Komponenten#, Typ, Maschinen#, Funktion, Datum,...)

BAUGRUPPE

(Oberteil-Komponenten#, UnterteilKomponenten#,...)

Das Schema weist folgende Normalformenverletzungen auf: Verletzung der 1NF: ƒ

Im WART-AUFTRAG findet sich die Wiederholungsgruppe "Auftragstyp".

Verletzung der 2NF:

92

ƒ

In WART-AUFTRAG sind der „Bearbeitername" und der "BearbeiterProvisionssatz" bereits von der "Bearbeiter#" funktional abhängig.

ƒ

In STÖRUNG ist "Maschinentyp" funktional abhängig von der "Maschinen#".

ƒ

Problem: Aus der Verletzung der 2NF resultiert Redundanz und es steigt das Risiko von Inkonsistenzen, was spätere Analysen beeinträchtigen kann (z.B. keine kor-

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext rekte Verdichtung bei unterschiedlichen Bearbeiternamen oder Berechnungen mit fehlerhaften Provisionssätzen). Verletzung der 3NF: ƒ

In KUNDE ist die "Kundengruppenbezeichnung" funktional abhängig von der "Kundengruppen#".

ƒ

In KUNDE ist das Attribut "Marketingleiter_Region" funktional abhängig von der "Region".

ƒ

In STÖRUNG ist "BeschreibungStoerungstyp" funktional abhängig vom "Störungstyp".

ƒ

Problem: Die redundante Vorhaltung der Attribute „Kundengruppenbezeichnung“, "Marketingleiter_Region" und "BeschreibungStörungstyp" kann zu widersprüchlichen Eingaben führen. Es handelt sich um Attribute, die üblicherweise im Rahmen von Analysen für die Verdichtung genutzt werden („Aggregationshierarchien“).

Alternativer Vorschlag: WART_AUFTRAG

(Kunden#, Bearbeiter#, Datum, Maschinen#, Auftragstyp#...)

BEARBEITER

(Bearbeiter#, Name, Vorname, Position, Provisionssatz,...)

AUFTRAGSTYP

( Auftragstyp#, Auftragstyp,....)

KUNDE

(Kunden#, Firmenname, Handelsregistereintrag, Kundengruppen#, Region,...)

REGION

(Region#, Region, Marketingleiter_Region,...)

KUNDENGRUPPE

(Kundengruppen#, Kundengruppenbezeichnung,...)

MASCHINE

(Maschinen#, Maschinentyp#,...)

MASCHINENTYP

(Maschinentyp#, Maschinentyp, Maschinentypbeschreibung,...)

STÖRUNG

(Maschinen#, Kunden#, Bearbeiter#, Datum, Störungstyp#, ...)

93

3

Lösungen und Lösungsskizzen STÖRUNGSTYP

(Störungstyp#, Störungstyp, BeschreibungStoerungstyp,...)

KOMPONENTE

(Komponenten#, Maschinen#, Typ, Funktion, Datum,...)

BAUGRUPPE

(Oberteil-Komponenten#, UnterteilKomponenten#,...)

Aufgabe V-3-5: Star-Schema zur Unterstützung des Managements von Wartungsprozessen

MASCHINENTYP n

KUNDE

GEHÖRT ZU

n 1 m ZEIT

1 WARTUNG

BETRIFFT STÖRUNG VON

n MASCHINE

o BEARBEITER

Möglicher Lösungsansatz: 1.

Identifizierung von betriebswirtschaftlich relevanten Ereignissen, denen Fakten zugeordnet werden können. Betriebswirtschaftlich von Interesse sind im gegebenen Fall voraussichtlich Vorgänge, die im Beziehungstyp WARTUNG beschrieben werden. Das zu entwerfende Datenmodell dient somit der Analyse von Wartungsvorgängen.

2.

Identifizierung möglicher Dimensionen zur Beschreibung der Ereignisse: ƒ

94

Das ERM zeigt, dass jeder Wartungsvorgang über einen Kunden, einen Bearbeiter und eine Zeitangabe (z.B. der

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Vorgangsbeginn) identifiziert wird. Darüber hinaus lässt sich jeder Vorgang eindeutig einer Maschine zuordnen. Dies sind potentielle Dimensionen, zu denen sich aus dem ERM Attributwerte ableiten lassen. ƒ

Evtl. ergeben sich aus den Attributen von WARTUNG oder den zuvor genannten Entitätstypen weitere Dimensionen, beispielsweise zu einem eingesetzten Werkzeug.

3. Identifizierung möglicher Fakten Mögliche zu analysierende Kennzahlen könnten sein: Die Wartungsdauer, der Wartungserfolg, die Wartungskosten sowie der für die Wartung gegebenenfalls angesetzte Rechnungsbetrag. Evtl. müssen einige dieser Fakten berechnet werden, beispielsweise die Wartungsdauer über die Differenz von Wartungsende und Wartungsbeginn. 4. Konkretisierung der Dimensionen und Hierarchien Direkt aus dem ERM ersichtlich ist eine zweistufige Hierarchie MASCHINE (zu MASCHINENTYP). Weitere Attribute und Hierarchien sind über die Attribute der beteiligten Entitätstypen abzuleiten. Interessante Attribute für Verdichtungen wären beispielsweise der Maschinentyp, das Produktionswerk, das Maschinenbaujahr, die organisatorische Zugehörigkeit des Bearbeiters, seine Qualifikation und seine Dienstjahre. Anmerkung: Unter Abwägung von Datenvolumen und Analysemöglichkeiten kann entschieden werden, auf welchem Aggregationsniveau die Daten vorliegen sollen (z.B. nur auf Monatsebene, nur auf Maschinentypsebene etc.).

95

3

Lösungen und Lösungsskizzen 5. Entwurf des Star-Schemas DT_Zeit

DT_Maschine

KZeit

KMaschine

Wochentag Monat Kalenderjahr Geschäftsjahr

Maschine KMaschinentyp Maschinentyp Werk Baujahr Garantie

FT_Wartung KZeit KKunde KMaschine KBearbeiter

DT_Bearbeiter KBearbeiter

Wartungsdauer Wartungserfolg Wartungskosten Rechnungsbetrag

Name Qualifikation Dienstjahre KOrgeinheit Orgeinheit LeiterOrgeinheit

DT_Kunde KKunde Kunde Branche Größenklasse Hauptniederlassung

6. Mögliche Analysen Hier eine Auswahl möglicher Analysen:

96

ƒ

Welche Höhe besitzen die Wartungskosten einer bestimmten Maschine eines ausgewählten Baujahrs?

ƒ

Bei welchen Kunden fällt außergewöhnlich viel Wartungsbedarf an?

ƒ

Ist die verfolgte Garantiepolitik sinnvoll? Welcher Anteil an Wartungskosten liegt im Garantiezeitraum und wird daher nicht in Rechnung gestellt? [Anmerkung: Hier wäre ein Ausbau zu einer Galaxie mit Umsatzdaten interessant, um das Akquisepotential der Garantiepolitik mit ins Kalkül einzubeziehen.]

ƒ

An welchen Wochentagen ist der Wartungserfolg am geringsten?

ƒ

Welche Organisationseinheiten betreiben die effektivste Wartung, bemessen an Kennzahlen wie „Anteil erfolgreicher Wartungsvorgänge“ und „durchschnittlicher Wartungsdauer“.

ƒ

Lohnt sich die Beschäftigung hochqualifizierter Servicemitarbeiter? Unterscheiden sich durchschnittliche Wartungserfolge und Wartungsdauern bei unterschiedlichen Qualifikationen?

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext Aufgabe V-3-6: Galaxie und Analysemöglichkeiten Gegebenes Star-Schema: FT_Verkauf

DT_Kunde KKunde Name KKundengruppe Kundengruppe

KZeit KKunde KArtikel Listenpreis Menge Rabatt Vertriebseinzelkosten

DT_Zulieferer

FT_Einkauf

KZulieferer

KZulieferer KArtikel KZeit

Name Land

Listenpreis Menge Rabatt Lieferdauer

DT_Artikel KArtikel Seriennr. Artikelname KArtikeltyp Artikeltyp DT_Zeit K_Zeit Monat Quartal Jahr

Beispiele für Analysen auf dem Stern „Einkauf“: ƒ

Wie haben sich die variablen Einkaufskosten im Zeitverlauf entwickelt?

ƒ

Wie stark unterscheiden sich zwei konkrete Zulieferer bezüglich ihrer durchschnittlichen Lieferzeiten für denselben Artikel?

ƒ

„ABC-Analyse“ der Artikeltypen: Welche Artikeltypen verursachen den größten Beschaffungskostenanteil und müssen deshalb besonders aufmerksam überwacht werden?

Beispiele für Analysen auf dem Stern „Verkauf“: ƒ

Gibt es Kunden, die im Zeitverlauf eine besondere Einkaufsmacht aufgebaut haben?

ƒ

Welche Kundengruppe kauft welche Artikeltypen?

ƒ

Gibt es Artikel, für die besonders hohe Vertriebseinzelkosten anfallen?

97

3

Lösungen und Lösungsskizzen Beispiele für integrierte Analysen über beide Sterne: ƒ

Wie haben sich die Deckungsbeiträge entwickelt (Berechnung: Bruttoerlös – Rabatte - Vertriebseinzelkosten Netto-Beschaffungskosten)?

ƒ

Wie lange wird ein bestimmter Artikel durchschnittlich gelagert (Lieferdatum – Beschaffungsdatum)?

ƒ

Welchen Anteil haben die Vertriebseinzelkosten an den variablen Kosten? Unterscheidet sich dieser Anteil bei den verschienen Artikeltypen?

Aufgabe V-3-7: Mehrdimensionales-Schema für eine Videothek Folgende Relationen liegen vor: FILIALE

(Filial#, Strasse, PLZ, Ort)

KUNDE

(Kunden#, Name, Vorname, Strasse, PLZ, Ort)

DVD

(DVD#, Spielfilm#, Extras)

VERLEIH

(Ausgabetag, Kunden#, Filial#, Rabatt, Verzugsgebühr)

VERLEIH_POS

(Ausgabetag, Kunden#, Filial#, DVD#, Rückgabetag, Schadenstyp, Gebühr)

SPIELFILM

(Spielfilm#, Titel, Altersfreigabe, Regisseur, Genre, Dauer)

Möglicher Lösungsansatz: 1. Identifizierung von betriebswirtschaftlich relevanten Ereignissen, denen Fakten zugeordnet werden können. Im gegebenen Schema kann als zentrales Ereignis der Verleih identifiziert werden. Bei jedem Verleih können einem Kunden mehrere DVDs ausgehändigt werden. Der Verleih kann dabei auf der Ebene von Verleihvorgängen oder (feiner) auf der Ebene einzelner Verleihpositionen (DVDs) betrachtet werden. Für beide Varianten können potentiell relevante Analysen abgeleitet werden.

98

3.3

Performanceoptimierte Datenmodellierung im relationalen Kontext 2. Identifizierung möglicher Dimensionen zur Beschreibung der Ereignisse Jeder Verleih- und Bestellvorgang wird über einen Kunden, eine DVD und einen Tag identifiziert. Wichtiger als die konkrete DVD als Medium dürfte der darauf hinterlegte Spielfilm sein. Evtl. ist es sinnvoll zu analysieren, welchen Einfluss das DVD-Attribut Extras auf die Verleihumsätze hat. Im Folgenden wird jedoch auf eine eigenständige Dimension „DVD“ verzichtet. 3. Identifizierung möglicher Fakten Mögliche Kennzahlen sind für den Verleihvorgang die summierte Brutto-Verleihgebühr (als Summe der Gebühren der Einzelpositionen), die gewährten Rabatte, die Verzugsgebühr sowie die resultierende Netto-Verleihgebühr. Für die Verleihposition können über die Verleihgebühr, die Verleihdauer und die Existenz von Schäden Fakten definiert werden. 4. Konkretisierung der Dimensionen und Hierarchien Die Attribute können zunächst aus den Relationen der dimensionsprägenden Relationen übernommen werden. Als Hierarchie ist aus dem Relationenschema unmittelbar der „Ort“ identifizierbar. Weitere Hierarchien können beispielsweise über die Altersfreigabe oder das Filmgenre abgleitet werden. 5. Entwurf des Schemas Auf Basis der genannten Vorüberlegungen kann ein Schema entworfen werden:

99

3

Lösungen und Lösungsskizzen DT_Spielfilm KSpielfilm Titel Altersfreigabe Regisseur Genre Dauer Preise mitStar

DT_Kunde KKunde Name Strasse PLZ Ort

FT_Verleihposition KFiliale KZeit KKunde KSpielfilm KDVD Verleihgebühr Verleihdauer wurdeBeschädigt

FT_Verleihvorgang KFiliale KZeit KKunde Brutto-Verleihgebühr Rabatt Verzugsgebühr Netto-Verleihgebühr

DT_Filiale KFiliale Strasse PLZ Ort

DT_Zeit KZeit Datum Wochentag Monat Jahreszeit Jahr VorFeiertag

Aufgabe V-3-8: Snowflake-Schema

100

ƒ

Der Begriff „Snowflake-Schema“ wird nicht einheitlich verwendet. Gemeinsam ist den verschiedenen Ansätzen die Überführung eines Star-Schemas in eine Struktur, die bei geschickter grafischer Umsetzung Ähnlichkeit mit der Form einer Schneeflocke aufweisen kann. Dazu kommt es insbesondere dann, wenn Dimensionstabellen aufgeteilt werden.

ƒ

Grundsätzlicher Nachteil einer Zerlegung der Dimensionstabellen ist die daraus resultierende höhere Modellkomplexität.

ƒ

Wesentlicher Vorteil einer Zerlegung sind geringere Tabellengrößen, über die verkürzte Zugriffszeiten erzielt werden können.

ƒ

Ein häufig gewählter Ansatzpunkt zur Zerlegung ist eine Partitionierung der Dimensionstabellen anhand der einzelnen Verdichtungsstufen der Hierarchie („partitioning by level attribute“), da hier häufig gewählte Einstiegspunkte in das Modell abgebildet werden. Es wird z.T. aus Performance-Gründen empfohlen, beschreibende Attribute zu den höheren Hierarchieebenen parallel in

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff den detaillierteren Tabellen zu belassen und damit bewusst zusätzliche Redundanz aufzubauen. ƒ

3.4

Eine Partitionierung der Dimensionstabellen sollte sinnvoll mit der Bildung von Summationstabellen eines FactConstellation-Schemas verknüpft werden. In diesen Fällen werden für häufig angefragte Aggregationswerte vorverdichtete Fakttabellen erzeugt, auf die über partitionierte Dimensionstabellen direkt zugegriffen werden kann. Ein solcher Ansatz ist immer dann sinnvoll, wenn hohe Datenvolumina zu hinterlegen sind, die Benutzer jedoch häufig mit aggregierten Daten arbeiten.

Informationsgenerierung, -speicherung, -distribution und -zugriff Basisfragen (B) Aufgabe B-4-1: Traditionelle Abgrenzung dispositiver Systeme Die traditionelle Abgrenzung ist irreführend und birgt die Gefahr von Fehlinterpretationen. Kritik: x

Es werden isolierte Systemklassen dargestellt, die sich in der Praxis in dieser Form nicht wiederfinden lassen. Vielmehr weisen heute viele Analysesysteme als integrierte Lösungen eine Vielzahl von Funktionalitäten auf, die früher lediglich in separierten Einzelsystemen zum Einsatz kamen. So sind z.B. DSS auf der Basis von Tabellenkalkulationsprogrammen in vielen Fällen direkt mit OLAP-Funktionalitäten versehen oder bieten als Front-End-Systeme einen direkten Zugang zu endbenutzerorientierten Data-Mining-Lösungen.

x

Eine eindeutige Zuordnung der Systemklassen zu einzelnen Managementebenen gilt für aktuelle Analysesysteme nicht mehr. Die Entwicklungen der letzten 10 Jahre – wie z.B. flachere Hierarchien, jüngere, IT-kundige Manager, neue benutzerfreundliche Technologien – haben bewirkt, dass die

101

3

Lösungen und Lösungsskizzen Bandbreite der verwendeten Analysesysteme auf jeder Managementebene zugenommen hat. x

Eine komplexe datenseitige Verfechtung der Systeme, die in früheren Lösungen mit eigener Datenhaltung durchaus bestand und mit Hilfe von zu programmierenden Schnittstellen gelöst werden musste, existiert bei DWH-basierten Infrastrukturen nicht länger.

Aufgabe B-4-2: Latenzzeiten Ein möglicher „Wertverlust von Informationen“ entsteht durch die folgenden Latenzzeiten: Datenlatenz beschreibt die Zeitspanne, bis die Daten gefiltert, harmonisiert, aggregiert und ggf. angereichert im Data Warehouse zur Verfügung stehen. Analyselatenz ist die Zeitspanne, die für die manuelle oder automatische Überführung der Daten in den benötigten Kontext verwendet wird, also für die betriebswirtschaftliche Transformation, die visuelle Aufbereitung und die Distribution an die Adressaten. Entscheidungslatenz stellt den Zeitraum dar, der zwischen der Analyseverfügbarkeit und der darauf basierenden Entscheidung anfällt. Umsetzungslatenz meint die Zeit zwischen der Entscheidung und der Durchführung konkreter Maßnahmen.

102

x

Das Real-time DWH eliminiert die Datenlatenz.

x

Das Closed-loop DWH reduziert die Umsetzungslatenz.

x

Das Active DWH reduziert (eliminiert) die Analyse-, Entscheidungs- und Umsetzungslatenz.

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff Betriebswirtschaftliche Angemessenheit: Implementierungsmöglichkeiten dienen der adäquaten Lösung betrieblicher Problemstellungen. Moderne Ansätze ergänzen somit die traditionellen Lösungen und machen sie nicht obsolet. Z.B. wäre es unangebracht, für monatliche Wettbewerbsanalysen den Ansatz des Real-time Data Warehousings zu wählen, da hier die fachlichen Anforderungen einer Datenversorgung in Echtzeit nicht gegeben sind. Aufgabe B-4-3: Data Warehousing Klassisches Data Warehousing: Die Analysesysteme bedienen sich nur lesend der Datenbasis. Einsatzgebiete: typisches Reporting (periodische, a-periodische, Ad-hoc-Berichte usw.). Closed-loop Data Warehousing: Die Analysesysteme schreiben erzeugte Daten in die operative und/oder dispositive Datenbasis zurück. Einsatzgebiete: Kampagnenmanagement (Durchführung von Kundensegmentierungen mittels Data Mining und elektronische Weitergabe der Segmentierung an die operative Adressdatendatei). Risikomanagement (Bildung von Risikosegmenten mittels Data Mining und anschließende automatisierte Segmentierung operativer/dispositiver Dateien aufgrund der Analyseergebnisse). Real-time Data Warehousing: Analysesysteme bedienen sich aktueller dispositiver Daten, die zeitgleich im Data Warehouse und in der operativen Datenhaltung verfügbar gemacht werden. Einsatzgebiete: Börsenspezifische Tickerdienste, Real-timeÜberwachung erfolgskritischer Produktionsprozesse. Active Data Warehousing: Analysesysteme stoßen durch Ereignisse (z.B. Datenkonstellationen) automatisch (Berichts-)Prozesse an. Einsatzgebiete: Optimierung von Frachtwegen bei unvorhergesehenen Ausfällen (Verspätungen) bei bestimmten Lieferwegen, Ausnahmeberichte (Push-Prinzip) aufgrund vorab definierter Schwellwertüberschreitungen. 103

3

Lösungen und Lösungsskizzen

Aufgabe B-4-4: Freie Datenrecherchen Welche der Aussagen ist (sind) richtig? ‰

Freie Datenrecherchen sind mit OLAP-Recherchen gleichzusetzen. (Nein, freie Datenrecherchen werden mit Datenmanipulationssprachen wie SQL oder MDX direkt formuliert.)

;

Werkzeuge wie SQL und MDX sind techniknahe Abfragesprachen, die aufgrund ihrer Komplexität nur von versierten Endbenutzer (Power Usern) oder IT-Mitarbeitern eingesetzt werden sollten.

;

Mit freien Datenrecherchen können Benutzer durch ungeschickte Abfragen die Performance der dispositiven Datenhaltung elementar verschlechtern. (Ja, z.B. kann ein ungewollter „Full Table Scan“, also das komplette Auslesen einer Tabelle, die Performance einer Datenbank empfindlich stören.)

Aufgabe B-4-5: OLAP Pendse und Creeth definierten 1995 fünf Kernanforderungen an OLAP-Systeme. Das Akronym FASMI steht für „Fast Analysis of Shared Multidimensional Information“. Fast: Das System soll reguläre Abfragen innerhalb von 5 Sekunden, komplexe Abfragen in maximal 20 Sekunden beantworten. Analysis: Das System soll intuitiv bedienbare und frei wählbare Analysen mit beliebigen Methoden ermöglichen. Shared: Es existiert eine effektive Zugangssteuerung und die Möglichkeit eines Mehrbenutzerbetriebs. Multidimensional: Unabhängig von der zugrunde liegenden Datenbankstruktur ist eine konzeptionelle multidimensionale Sicht gegeben.

104

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff Information: Die Skalierbarkeit der Anwendung ist auch bei großen Datenmengen gegeben, so dass die Antwortzeiten von Auswertungen stabil bleiben. Aufgabe B-4-6: Decision Support Systems (DSS) Datenbasis: Die Datenbasis enthält die Eingabe- und Ergebniswerte. Modell- und 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. 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. 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 erforderlichen Methoden bzw. Modelle erlauben. Dialogführung: Die Dialogführung erlaubt 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.

105

3

Lösungen und Lösungsskizzen Moderne Tabellenkalkulationsprogramme verfügen über sämtliche DSS-Architekturkomponenten und werden aus diesem Grunde häufig für kleinere DSS-Anwendungen eingesetzt. x

Datenhaltung = Tabellenblatt (-blätter) oder Verknüpfung mit externer Datenquelle, z.B. einem Data Mart oder einem Data Warehouse

x

Modell-/Methodenbank = Zielwertsuche, Szenarien, mathematische Funktionen (Finanzmathematik, Statistik, Logik, …)

x

Anwendungsunterstützung = kontextsensitive Hilfen

x

Dialogführung = Menüleisten, Dialogboxen, …

Aufgabe B-4-7: Expertensysteme Entscheidungssysteme: Das System trifft die Entscheidung selbständig. Diese Variante ist nur in gut strukturierten Problemsituationen realistisch, die vollständig beschreibbar sind und für die eindeutige Lösungen automatisiert gefunden werden können (z.B. Routineentscheidungen bei Kreditwürdigkeitsprüfung, …). Entscheidungsunterstützung: In semi- oder schlecht-strukturierten Problemsituationen sollten systemseitig keine eigenen Entscheidungen getroffen werden, da die Komplexität meist nur durch den Menschen bewertbar ist. Hier werden systemseitig demnach lediglich Hilfestellungen bei der Entscheidungsfindung angeboten (Produkteinführungen in neuen Märkten, Investitionsanalysen,…). Aufgabe B-4-8: Data Mining Welche der Aussagen ist (sind) falsch? ; Data Mining ist als computergestützte Datenanalyse zur Mustererkennung ein neues Anwendungsgebiet, das vor 20 Jahren noch nicht existierte. (Falsch, IT-Systeme zur Datenmustererkennung existierten bereits in den 1960er Jahren.) ‰

106

Data Mining meint – je nach Auslegung – die hypothesenfreie oder die hypothesenbasierte Suche nach nicht trivialen

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff Mustern in Datenbeständen. (Richtig, Data Mining umfasst in weiter Begriffsauslegung die hypothesengestützte Untersuchung, Data Mining in enger Begriffsauslegung meint die hypothesenfreie Analyse.) ; Die Bezeichnungen Clusterbildung und Klassifikation sind Synonyme, meinen also dieselbe Methode. (Falsch, bei der Clusterbildung werden durch die Aufdeckung von Ähnlichkeitsmerkmalen sog. Cluster von gleichartigen Objekten gebildet (Segmentierung). 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.) Aufgabe B-4-9: Berichtssysteme 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. x

Periodische Berichtssysteme generieren in festen Zeitabständen – in der Regel monatlich – Berichte. Anwendungsfall: Monatliche Umsatzberichte mit Soll-/Ist/Abweichungen (Standard-Berichtswesen).

x

Aperiodische Berichtssysteme generieren bei Überschreitung von Grenzwerten automatisch eine Benachrichtigung. Berichtssysteme dieser Art werden vor allem für die betriebliche Früherkennung zur Identifikation von strategischen Potentialen und Gefahren eingesetzt. Anwendungsfall: Überschreiten einer vorab definierten Ausschussquote im Produktionsprozess.

Passive Berichtssysteme Hier werden Berichte auf konkrete Anforderung eines Benutzers hin erstellt. Für die Zusammenstellung der Informationen und des Layouts werden beim Anwender meist anwendunsgorientierte IT-Kenntnisse benötigt. Anwendungsfall: Ad-hoc-Analyse zur Recherche aktueller Verkaufsmengen. 107

3

Lösungen und Lösungsskizzen Aufgabe B-4-10: Interaktive Report-Plattformen und generierte Berichte Welche der Aussagen ist (sind) falsch? ; Interaktive Report-Plattformen sind professionelle Werkzeuge für Spezialisten der IT-Abteilung, um für die Fachbereiche fertige Berichte generieren zu können. Ein direkter Einsatz dieser Werkzeuge in den Fachbereichen macht keinen Sinn. (Falsch, interaktive Report-Plattformen sind in aller Regel endbenutzertaugliche Werkzeuge und können somit auch in den Fachbereichen zur Entwicklung von Berichten herangezogen werden.) ; Management Information Systems sind algorithmisch (formelbasiert) ausgerichtet und unterscheiden sich aus diesem Grunde von berichtsorientierten Executive Information Systems. (Falsch, Management Information Systems (MIS) sind – wie auch Executive Information Systems (EIS) – berichtsorientiert. Sie unterscheiden sich primär durch den Benutzerkreis, den Verdichtungsgrad und die Ausrichtung der Daten. So sind EIS primär für das TopManagement konzipiert, zeigen daher eher aggregierte Informationen und beinhalten einen meist höheren Grad an externen Informationen.) ‰

Executive Information Systems sind auf das TopManagement ausgerichtet und verfügen daher über großes Maß an Bedienungskomfort.

Aufgabe B-4-11: Konzeptorientierte Systeme Konzeptorientierte Systeme

108

x

stellen eine IT-basierte Umsetzung eines umfangreicheren, betriebswirtschaftlichen Verfahrens (z.B. Balanced Scorecard, Konzernkonsolidierung) dar,

x

sind implementierungsfähige, sinnvoll konstruierte Standardlösungen und

x

sind stets unternehmensindividuell anzupassen, also auf die konkreten Anforderungen der Organisationen auszurichten (customization).

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff Aufgabe B-4-12: Wissensmanagement (WM) Welche der Aussagen ist (sind) richtig? ;

BI-Analysen können Wissen erzeugen, das an anderer Stelle im Unternehmen sinnvoll genutzt werden kann. Es sollte deshalb überprüft werden, die Erkenntnisse in das betriebliche Wissensmanagement zu integrieren.

;

Es ist sinnvoll, BI-Analysen mit Inhalten aus Wissensmanagementsystemen anzureichern, um aussagefähige Interpretationen von BI-Analyseergebnissen zu ermöglichen.

;

Integrationspotentiale zwischen BI und WM ergeben sich auf der Präsentationsebene, der Logikebene und der Datenebene.

Aufgabe B-4-13: Portal Portal allgemein: x

Ein Portal realisiert eine Zusammenführung von unterschiedlichen Anwendungen unter einer gemeinsamen Oberfläche.

x

Es besitzt Personalisierungsmöglichkeiten (rollen-/gruppenbezogene, individuelle und implizite Personalisierung).

x

Es bietet Single-Sign-On-Funktionalität, erlaubt also durch einmalige Anmeldung den autorisierten Zugriff auf Ressourcen und Dienste entsprechend eines Berechtigungsprofils.

BI-Portal: x

Das BI-Portal ist der zentrale Informationszugang zu sämtlichen BI-Subsystemen.

x

Das BI-Portal ist häufig ein Bestandteil eines umfassenderen Enterprise-Information-Portals (EIP).

109

3

Lösungen und Lösungsskizzen

Verständnisfragen (V) Aufgabe V-4-1: Analytisches CRM Customer Relationship Management (CRM) umfasst neben dem operativen und dem kommunikativen auch das analytische CRM. Ausschließlich das analytische CRM gehört zum Themenkomplex BI und sollte primär fokussiert werden. Ihre Vorschläge könnten folgende Punkte beinhalten: 1. Typische CRM-Analysen x

Fraud Detection = Betrugserkennung aufgrund von Datenmustern.

x

Churn Analysis = Erkennung kündigungsbereiter, guter Kunden mit dem Ziel der Rückgewinnung.

x

Kundenwertanalysen = Bestimmung des wirtschaftlichen Wertes eines Kunden über seinen gesamten Lebenszyklus.

x

Kampagnenmanagement = Planung, Überwachung und Steuerung von Werbekampagnen. Die Kampagnendurchführung erfolgt mit Hilfe des operativen CRM.

2. Infrastrukturelle Voraussetzungen

110

x

Aufbau und Pflege eines kundenorientierten DWH (Stamm-, Bestands- und Bewegungsdaten auf Kundenebene). Datenquellen: operative Vorsysteme und Daten aus sämtlichen Kundenkontaktpunkten (Touch Points, Multi-ChannelManagement).

x

Einsatz wirksamer Softwarewerkzeuge für den Aufbau von Anwendungen des Data Mining und OLAP.

x

Als Implementierungsvariante kommt das Closed-loop-DataWarehousing in Betracht. Z.B. können die über Data-MiningSysteme ermittelten Kundensegmentierungen ohne Medienbrüche in die operativen/dispositiven Kundendateien als zusätzliche Informationen eingebunden werden (Unterstützung des Kampagnenmanagements). Weiterhin können die Erkenntnisse aus durchgeführten Kampagnen als wertvolle Information für nachgelagerte Aktionen (Wirkungsanalysen) in den dispositiven Kontext zurückgeschrieben werden.

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff Aufgabe V-4-2: Analysesysteme für den Controllingbereich Ihre Argumentation könnte folgende Punkte beinhalten: x

Der Einsatz von isolierten Tabellenkalkulationsprogrammen birgt die Gefahr, dass aufgrund der arbeitsplatzbezogenen Datenaufbereitung und -haltung ein unkontrollierbarer Datenwildwuchs entsteht (arbeitsplatzbezogene Insellösungen).

x

Aufgrund der skizzierten Fragestellungen wird deutlich, dass ein reportorientiertes System in Form eines Standardberichtswesens allein nicht ausreichend sein wird. Vielmehr sind hier Werkzeuge einzusetzen, die eine dynamische Analyse (Ad-hoc-Analyse) erlauben.

x

OLAP-Systeme könnten eine Alternative darstellen. Mit ihrer Hilfe könnten benutzerseitig flexible Analysen in den mehrdimensionalen Datenräumen (hier Kunde und Produkt) durchgeführt werden. Allerdings wären bei den in der Aufgabe skizzierten Fragestellungen zeitaufwändige Suchen in den Datenräumen erforderlich, wobei verschiedenste Dimensionen (Dimensionshierarchien) miteinander kombiniert und analysiert werden müssten.

x

Endbenutzertaugliche Data-Mining-Systeme könnten in diesem Szenario bessere Ergebnisse erzeugen, da sie in der Lage sind, erfolgreiche Analysepfade aufgrund von Datenkonstellationen (z.B. Ausreißerwerten) zu bestimmen, so dass die Analysegüte und -zeit reduziert werden kann.

x

Sowohl OLAP als auch die endbenutzertauglichen DataMining-Werkzeuge können auf zentralisierte Daten (z.B. Data Marts) zugreifen, wobei die dem Controller geläufige Benutzeroberfläche (z.B. das Tabellenkalkulationsprogramm) meist beibehalten werden kann (OLAP-/Data-MiningMethoden als Plug-in-Funktionalität).

Aufgabe V-4-3: OLAP-Varianten Ihre Argumentation könnte folgende Punkte beinhalten: x

Fachbereiche interessieren sich in aller Regel primär für die aus Benutzersicht relevanten Charakteristika eines Systems. IT-Bereiche fokussieren hingegen meist die Integrations- und Administrationsfähigkeit von IT-Systemen.

111

3

Lösungen und Lösungsskizzen x

Aus Benutzersicht bezeichnet OLAP ein System zur Ad-hocRecherche in mehrdimensionalen Datenräumen. Dieses System sollte neben guter Performance und hoher Benutzerfreundlichkeit alle gängigen Operatoren zur flexiblen Analyse anbieten, also Slice & Dice, Drill-down & Roll-up, Pivotierung, Drill-through & Drill-across, Split & Merge.

x

Die physikalische Datenhaltung kann demnach – gleiche Funktionalität, Performance und Benutzerfreundlichkeit vorausgesetzt – losgelöst von der logischen Sicht erfolgen (Benutzertransparenz der Technik). Allerdings weisen verschiedene Datenhaltungstechniken häufig Charakteristika auf, die auch die benutzerseitigen Funktionalitäten beeinflussen. In der Praxis kommt es deshalb häufig bzgl. der einzusetzenden OLAP-Technik zur Diskussion zwischen den betriebswirtschaftlichen Fachbereichen und den IT-Bereichen.

Folgende OLAP-Varianten sind möglich: R-OLAP (Relationales OLAP) basiert auf klassischen, standardisierten relationalen Datenbanksystemen, bei denen performanceoptimierte Star- und Snowflake-Schemata zum Einsatz kommen. Vorteile: x

Ausgereifte Technologie.

x

Sehr gute Skalierbarkeit.

x

Hohe Stabilität und Sicherheit.

x

Ausgereiftes Administrations- und Benutzerkonzept.

x

Einfache Migration auf Produkte anderer Hersteller (standarisierte Datenhaltung und damit hoher Investitionsschutz).

x

Nachvollziehbare Datenstrukturen (Tabellenstrukturen).

x

Weit verbreitetes Entwicklungs-Know-how.

Nachteile: x

112

Komplexe Verfahren zur Sicherung der Performance (Denormalisierungen, Indizierungen usw.).

3.4

Informationsgenerierung, -speicherung, -distribution und -zugriff x

Häufig schlechtere Performance bei komplexen Abfragen in multidimensionalen Datenräumen als bei Verwendung von M-OLAP-Technik.

Einsatzbereiche: x

Anwendungen mit hohem Datenvolumen (>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