Aufbau eines Data Warehouse für den Lebensmitteleinzelhandel

Transkript

1 Die Fallstudie aus der Wirtschaftsinformatik: Aufbau eines Data Warehouse für den Lebensmitteleinzelhandel Dipl.-Kfm. Carsten Bange, Dr. Heiko Schinzer, Würzburg 1. Ausgangssituation Der hohe Wettbewerbsdruck im Sektor des Lebensmitteleinzelhandels zwingt die Unternehmen zu weiteren Effizienzsteigerungen ihrer Leistungserstellung. Erreicht wird dies vor allem durch eine Integration der bisher stark heterogenen IT- Landschaften zu unternehmensweit integrierten Warenwirtschaftssystemen und einer Installation leistungsfähiger Business Intelligence- und Supply-Chain-Management- Systeme. Neben massiven Investitionen in die elektronische Erfassung der Warenströme (Scanner-Kassen, Nachorderterminals mit Funkübertragung) und die Einführung von betriebswirtschaftlicher Standardsoftware rückt das Data Warehouse- Konzept dabei weiter in den Mittelpunkt. Durch den Aufbau eines Data Warehouse können Analysen in den Bereichen Unternehmensführung und Controlling sowie im Filial-, Sortiments- und Aktionsmanagement auf eine solide Datenbasis gestellt werden, die schnellere und bessere Entscheidungen ermöglicht. Weiterhin erlauben moderne Analyseverfahren des Data Mining die Gewinnung neuer Informationen, die z. B. in der Layoutplanung, Sortimentsgestaltung oder Marketingplanung verwertbar sind. Auch die Öffnung des Data Warehouse für einen externen Zugriff von Zulieferern erhöht Informationsfluß und -geschwindigkeit zwischen den Partnern und führt zu einer engeren Verzahnung der Lieferkette. 2. Problemstellung Zur besseren Kontrolle des operativen Geschäftsablaufes und zur Bereitstellung von Informationen für Unternehmensführung, Marketing- und Vertriebsabteilung soll für einen Handelskonzern ein zentrales Data Warehouse aufgebaut werden. Aufgrund der zu erwartenden immensen Datenfülle und des im Haus vorhandenen Know-Hows wird eine relationale Datenbank als Warehouse Speicherkomponente ausgewählt (ROLAP-Ansatz). Für die erste Phase des Warehouse-Projektes wurden von der Einzelhandelskette folgende Analyse- bzw. Berichtsanforderungen formuliert: 1. Umsatzentwicklung

2 Nach Aufbau des Data Warehouse sollen Produktmanager tagesgenau über Umsatzentwicklung einzelner Produkte in den verschiedenen Filialen und Regionen informiert werden. Weiterhin werden auch Zeitreihenanalysen mit kumulierten Werten über Monate, Quartale und Jahre und eine Aufstellung der besten und schlechtesten Produkte und n (Top 10 / Bottom 10) in einer bestimmten Periode vorgenommen. Die sleiter möchten zusätzlich wissen, welche Umsatzanteile auf welche n und Produkte fallen, während Regionalmanager die Umsatzzahlen der einzelnen Filialen ihrer Region benötigen. 2. Kundenkarte Die Akzeptanz der neu eingeführten Kundenkarte soll analysiert werden. Die Kundenkarte wurde zur Steigerung der Kundenbindung eingeführt und ist mit einer Zahlungsfunktion ausgestattet, d. h. sie kann alternativ zu anderen en (bar, ec-karte, Kreditkarte) eingesetzt werden. Ausgewertet werden soll der Einsatz von Kundenkarten im Vergleich zu anderen Bezahlformen. 3. Kassierer Für eine Leistungskontrolle soll die Geschwindigkeit der Kassierer ermittelt werden. Bei allen Transaktionen an der Kasse wird automatisch eine Startzeit (Einlesen des ersten Produktes) und eine Endzeit (Abschluß des Bezahlvorgangs) erfaßt. Als Kennzahl wird der durchschnittliche Produktdurchsatz während einer Transaktion gewählt, wobei eine tägliche Ermittlung des Wertes ausreicht. Das Inhouse-Transaktionssystem des Einzelhändlers ist auf Basis eines relationalen Datenbankmanagementsystems (RDBMS) aufgebaut. Zur Erfüllung der Analyseanforderungen wurden in diesem Quellsystem folgende Tabellen(auszüge) als relevant identifiziert:

3 Stammdaten Artikel CHAR(20) Artikel_Kurzbez. CHAR(15) Artikel_Langtext CHAR(50) Verkaufsmengeneinheit nbez. Filiale Fil_ Regionsname Bewegungsdaten nbez. sbez. Startzeit Endzeit Artikelanzahl Bon_Betrag Transaktion NUMBER(10,2) Funktion Kassierer Bon_Detail Position CHAR(20) Artikel_Kurzbez. CHAR(15) Menge Verkaufspreis NUMBER(10,2) Kunde Karte_Ausstellung Karte_Ablauf Konto_Nr. BLZ ZT_Bez. Bon_Betrag CHAR(20) NUMBER(10,2) 3. Problemlösung 1. Identifikation von Fakten und Dimensionen Aus den vorgegebenen Analyseanforderungen müssen in einem ersten Schritt alle relevanten Fakten (Kennzahlen) identifiziert werden. Dies sind hier Verkaufspreis und Verkaufsmenge sowie die abgeleiteten Kennzahlen Umsatz (Preis * Menge) und Kassiergeschwindigkeit, errechnet aus Verkaufsmenge im Verhältnis zu Kassierdauer (Endzeit Startzeit). Weiterhin sind die verschiedenen Dimensionen der multidimensionalen Sicht auf die Datenbasis und ihr hierarchischer Aufbau entscheidend.

4 Aus den Analyseanforderungen und vorhandenen Tabellen des Transaktionssystems können die Dimensionen Ware ( Produkt), Verkaufsstelle (Region Filiale), Mitarbeiter (Region Filiale Mitarbeiter), Zeit (Jahr Quartal Monat Tag), Bon, Kunde und abgeleitet werden. 2. Entwicklung des Datenmodells Als logische Datenmodelle zur Umsetzung von multidimensionalen Strukturen in relationalen Datenbanken existieren hauptsächlich das Star-Schema, das Snowflake- Schema und das sog. Galaxy-Schema. Alle drei Modellierungstechniken beinhalten das Redesign und die Denormalisierung bzw. bewußte Vermeidung von Normalisierungsschritten der operationalen Datenstrukturen, die durch das Entity-Relationship- Modell (ERM) von Chen dargestellt werden. Das im vorliegenden Fall gewählte Star- Schema bildet das vergleichsweise einfachste Datenmodell. Es besteht aus zwei Arten von Tabellen, der Fact-Table und den Dimension-Tables. Zentraler Dreh- und Angelpunkt des Star-Schemas ist die Fact-Table. Innerhalb dieser Tabelle wird jeder Artikelumsatz in Form eines Datensatzes erfaßt, wodurch das Datenvolumen entsprechend groß werden kann. Ein Datensatz der Fact-Table besteht aus Schlüsselund numerischen Attributen. Schlüsselattribute werden im oberen Teil der Fact-Table angegeben und stellen die Verknüpfung mit den Dimension-Tables her. Die Anzahl der Schlüsselattribute entspricht somit in der Regel der Anzahl der Dimension-Tables im Star-Schema. Numerische Attribute befinden sich im unteren Bereich des Fact- Tables und enthalten die eigentliche Fakten bzw. Kennzahlen. Sie korrespondieren mit dem Wieviel einer Abfrage (z. B. Umsatz, Verkaufsmenge) und können selbst Berechnungsgrundlage für neue Kennzahlen (z. B. Kassiergeschwindigkeit) sein. Dimension-Tables enthalten neben einem Schlüsselattribut, über das eine Verknüpfung mit der Fact-Table realisiert wird, beschreibende Attribute, die eine konkrete Abfrage spezifizieren (z. B. Umsatz für Produkt A). Innerhalb der Dimension-Tables werden Konsolidierungshierarchien aufgebaut (z. B. Jahr, Quartal, Monat etc.) wobei diese Abhängigkeiten graphisch nur in ihrer Reihenfolge dargestellt werden.

5 Bon Artikel Zeit Tag Woche Wochenname Monat Monatsname Quartal Jahr Verkaufsstelle Fil_ Regionsname Filial_ Fakten Menge Verkaufspreis Umsatz Kassiergeschw. Artikel_Kurzbez. nbez. sbez. Kunde Kassierer Fil_ Regionsname ZT_Bez. Abb.: Star-Schema mit Fact-Table und 7 Dimension-Tables 3. Aufbau des Data Warehouse Während die Abbildung des logischen Datenmodells in die Tabellenstruktur des relationalen Data Warehouse keine Schwierigkeiten bereitet, ist die Definition der Extraktions- Transformations- und Ladeschritte deutlich aufwendiger. Hierfür werden häufig spezielle Werkzeuge eingesetzt (ETL-Tools), welche die Daten der Quellsysteme aufbereiten und in das Warehouse überspielen. Da das Transaktionssystem des Einzelhandelskonzerns auf relationalen Datenbanken basiert, stellt die Anbindung der Datenquellen und Extraktion der erforderlichen Tabellen kein großes Problem dar. Transformationen müssen vorgenommen werden, um einige Dimensionen aufzubauen (beispielsweise die Hierarchiestufen der Dimension Zeit aus dem Feld ) oder abgeleitete Kennzahlen zu berechnen (Umsatz und Kassiergeschwindigkeit). Die Ladeprozesse werden durch Scheduler automatisiert, die über Nacht für eine Aktualisierung der tagesgenauen Daten des Warehouse sorgen.

6 4. Literaturhinweise Inmon, W. H.: Building the data warehouse. New York, 2. Aufl Kimball, R.: The data warehouse toolkit : practical techniques for building dimensional data warehouses. New York, 3. Aufl Muksch, H./Behme, W.: Das Data-Warehouse-Konzept. Architektur Datenmodelle Anwendungen. Wiesbaden, 3. Aufl Schinzer, H./Bange, C./Wehner, J./Zeile, C.: Management mit Maus und Monitor. Ausgewählte Business Intelligence-, OLAP- und Data Warehouse-Werkzeuge im Vergleich. München Schinzer, H./Thome, R.: wisu Studienblatt: Aktive Informationsgewinnung mit einem Data Warehouse. In: wisu das wirtschaftsstudium 28 (1999) 4.