Der Data Warehouse Mythos – Abgepackte Informationen aus dem Selbstbedienungsladen

Wohin mit der Datenflut? Eine bange Frage, die bereits in den Teenagerjahren der modernen Computer- und Informationstechnik die fortschreitende maschinelle Verarbeitung von Informationen begleitet und bis heute kein Jota an Gewicht verloren hat. Die IT-Industrie zitiert gern das Datenchaos im Primärspeicher und tonangebende Wirtschaftsinformatiker sprechen von „Information-Overload“, der sich unversehens zum „Overkill“ fortentwickeln kann. Wer nach kurzem Nachdenken auf die Delete-Taste hinweist, verkennt mit dieser verblüffend einfachen Antwort das Problem: Die codierten Bits und Bytes enthalten nützliche Informationen, die mit dem Löschen verloren gehen.

Besonders hellhörig reagiert in diesem Zusammenhang die Unternehmens-IT. Neben dem inzwischen etablierten Zwang zur regelkonformen Datenaufbewahrung gemäß staatlicher Auflagen sind es marktwirtschaftliche Verlockungen, die den Umgang mit Daten in eine neue Richtung lenken. „IT meets Business“ steht von Anfang an auf dem Beipackzettel, der die Idee und den Bau eines Data Warehouse (DW) inklusive der zugreifenden Front-End-Applikationen begleitet. Allerdings stellt sich schnell heraus, dass der Schritt vom klassischen Datensammler zur dispositiven Informationswirtschaft viele Anwenderfirmen mit enormen finanziellen, technischen und organisatorischen Hürden konfrontiert.

Wertschöpfung aus der Datenbank

Schon die frühen Pioniere des Data Warehousing verbinden ihre informationstechnischen Ambitionen mit grundsätzlicheren Gedanken zu Produktivität und Wachstum. Sie beschwören den informellen Wert einer speziell strukturierten Datenbank, befüllt mit erstklassigen Geschäftsinformationen, die der Anwender dank intuitiv handhabbaren Werkzeugen abholen, am Bildschirm betrachten und in seine Entscheidungsfindungen einfließen lassen kann. Flankiert wird dieser Aufruf zur unternehmensweiten Informationsbewirtschaftung durch wissenschaftliche Abhandlungen, die Mitte der 80er Jahre des vorigen Jahrhunderts immer häufiger auftauchen: Information sei ein Produktionsfaktor wie Arbeit, Boden und Kapital lautet die Kurzformel, die Feuilletonleser und Fachpresse zu lebhaften Debatten anregte.

Ohne hier näher auf das weitläufige Feld an Überlegungen zum Gelehrtenstreit einzusteigen, macht der hohe Stellenwert, den Informatiker dem Begriff Information einräumen, stutzig. Wer eine Nachricht liest, weiß doch noch lange nicht, um was es geht. Selbst gewöhnlich gut informierte Kreise sind überrascht, wenn alles anders kommt als erwartet und manche Gebrauchsanleitung muss man fünf mal lesen, um zu verstehen, was Sache ist. Die begriffliche Unschärfe nährt den Verdacht, dass die Informatikerzunft mit der in Aussicht gestellten Datenaufbereitung lediglich den Bogen zu etwas Handfestem spannen will. Denn übersetzt in den Kontext des Alltagsgeschäfts zeigt der Hinweis auf den Produktionsfaktor sogleich Brisanz für jeden Homo oeconomicus: Es geht um den wettbewerbsentscheidenden Vorsprung, der sich durch das intelligente Ausschöpfen der reichlich vorhandenen Datenquellen einstellen soll.

Auf diese Botschaft springen die Unternehmensstrategen in Sachen Data Warehouse an. Schließlich wurden bereits großzügige IT-Investitionen in Datenbanken und das Datenmanagement getätigt mit Zielrichtung Speichern und – im Fall einer abgestürzten Systemlandschaft – Wiederherstellen der applikationsgetriebenen (operativen) Datenbestände. Ganz zu schweigen von teuren Finanz-, Warenwirtschafts-, Produktionsplanungs- und Vertriebssystemen, die das Enterprise Ressource Planning (ERP) entscheidend vorantreiben sollen. Manchem Geldgeber drängt sich bereits die Frage auf, wie denn die Speicherung großer Datenmengen den Rückfluss der dafür notwendigen Ausgaben zustande bringen soll.

Solche Zweifel spielen in den Jahren 1990 ff. zunächst eine untergeordnete Rolle. Das Innovationstempo der Hard- und Softwareindustrie strebt gerade mit Client-/Server-Systemen, Internet, E-Business und Network Computing einem neuen Höhepunkt entgegen. Die Datenbank ist etablierte Lagerstätte und Verwaltungsort von elektronisch erzeugten Daten mit einer Allzweck-Software, die sich um Datenzugriff, Flexibilität, Verfügbarkeit und Sicherheit kümmert. Doch die Speicherboliden gelten als träge Kolosse. Das unterschiedslose Sammeln in einem zentralen Datenpool hat nämlich einen gravierenden Nachteil: Darin tummeln sich strukturierte Daten wie Telefonbücher oder Adresslisten ebenso wie komplexe und unstrukturierte Datentypen, angefangen bei Textdateien über E-Mails, Kundeninfos, Bürger- und Patientenakten bis zu Multimedia-Files mit Bild und Sound. Zudem ändert sich der Inhalt relationaler Online-Datenbanken mit jeder noch so kleinen Transaktion – die Suche nach geschäfts- und entscheidungsrelevanten Informationen stößt wegen der Vielzahl von internen und externen Datenquellen mit all den inkommensurablen Datentypen und –formaten auf ernsthafte Schwierigkeiten.

Die neue Produktivkraft Information erweist sich in dieser Form als sperrige Datensammlung, die einfach nicht zu den Managementetagen passt. Dort geht es um kurz- oder weitsichtige Entscheidungen mit messbaren Renditezielen und sichtbaren Erfolgen. Das Informationsbedürfnis der Führungskräfte richtet sich auf betriebliche Berichtssysteme, die das Streben nach Business Intelligence und Excellence unterstützen und in auswählbaren Zeiträumen Rückschlüsse auf die Qualität, Leistungs- und Wettbewerbsfähigkeit der gerade laufenden Geschäftsprozesse einschließlich der damit befassten Akteure im Unternehmen zulassen.

Verblüffend viele Fragen

Viele Fragen füllen die To-do-Liste eines Managers, der sich anschickt, die aktuellen Geschäftsgänge auf Effizienz und Rentabilität zu überprüfen. Einmal braucht er in Zahlen gefasste Fakten, wie schnell etwas, wo und zu welchem Preis über den Ladentisch ging. Dann sind es Markttrends, die Einfluss nehmen auf das Kaufverhalten oder das Marktgebaren konkurrierender Unternehmen. Stehen neue Verhandlungen mit Zulieferern an, muss der gesamte Einkauf durchleuchtet werden und floppt eine Produktlinie, geht es an die Ursachenforschung mit allen Begleiterscheinungen, die der Misserfolg so mit sich bringt.

Zahlreiche Data-Warehouse-Ruinen vor allem in den 80er und 90er Jahren des vorigen Jahrhunderts belegen, dass der Bau solcher Systeme einigen Hirnschmalz erfordert, jede Menge Arbeit und Investitionen bewegt und viele Fallstricke parat hält. Der einfache Grundgedanke, Daten zwecks Analyse aus dem Transaktionsraum des Tagesgeschehens herauszulösen und daraus Informationen für unterschiedliche Anwenderzwecke zu generieren, lässt sich nicht per Plug & Play in eine funktionstüchtige IT-Architektur umsetzen.

Weitere Schwierigkeiten stellten sich ebenfalls in den Anfangsjahren des Data Warehousing ein. Ältere Semester kennen noch den Joke mit den Bierflaschen und den Babywindeln. Nach intensiver Datenanalyse und mehrdimensionalem Abgleich diverser Kennziffern im Data Warehouse des US-Handelshauses Wal Mart erhalten die Filialleiter von der Zentrale den Tipp, Windeln und Feiertagsgetränk nebeneinander vor der Kasse zu platzieren. Siehe da, der Absatz beider Produktarten tendierte nach diesem Cross-Selling-Act – vor allem Wochenends – nach oben. Marketing- und Verkaufsprofis haben solche Glanzleistungen superteurer Warehouse-Techniken indes kalt gelassen. Tiefschürfende Einsichten in die Geheimnisse der Verkaufssteuerung im Supermarkt vermittelt diese Art der Informationsgewinnung nicht.

Mathematische Spielchen fürs Management

Die eher trivialen Analyseergebnisse der Anfangsjahre hat dem Data-Warehouse-Konzept nicht geschadet. Betriebswirtschaftlich orientierte Informatiker und Professoren mit nebenamtlichen Consultingaufträgen hatten längst die Ressource Information zur Steuerungsgröße für Geschäftsprozesse erklärt. Auf Kongressen und diversen Firmenveranstaltungen kursierte die Vorstellung, ein komplettes Unternehmen quasi vom Schreibtisch aus am Bildschirm per Dashboard und Cockpit über Key Indicators und automatisierte Reportings zu steuern. Das begeisterte zunehmend das gehobene Management, schließlich muss der Motor rund laufen und das wird immer schwieriger.

Lehr- und Handbücher zu Data Warehouse lassen indes nach wenigen Seiten erkennen, dass der Weg von codierten Zeichen und Zeichenketten zu einer aussagekräftigen Information über den aktuellen Stand der Krebsforschung in Europa oder die Auktionshistorie am Hamburger Fischmarkt weit und sehr holprig ist. Das Extracting, Transforming und Loading (ETL) der Daten in ein neu modelliertes Warenhaus für Geschäftsinformationen ähnelt einem Spießroutenlauf: Einmal lässt die Datenqualität und Aktualität zu wünschen übrig, dann belasten die Abfragen und das Online Analytical Processing (OLAP) die Systemperformance im gesamten Bereich des so genannten Online Transaction Processing (OLTP).

Aufgehalten hat das die Wirtschaftsinformatiker und Softwareentwickler nicht. Längst sind sie sich einig, dass die „Systemintelligenz“ steigerungsfähig ist und dass diese Herausforderung nur durch das Konzipieren eben jener Informationsspeicher zu meistern ist, die eine transparente, integrierte und logisch-konsistente Gesamtsicht auf die Daten vermitteln.

Informationen am laufenden Band

Kontroverse Auseinandersetzungen über Architektur, Datenmodell und Inhalte eines Data Warehouse prägen die Entstehungsgeschichte der informationsorientierten Datenhaltung. Schon einer der Gründerväter des Data Warehouse, der IBM-Mann Bill Inmon, sorgt vor zwanzig Jahren mit seiner Definition für Verwirrung. Unklar ist demnach, ob eine unternehmensweite Informationsbereitstellung anzustreben sei, oder die Fachabteilungen jeweils eigene Data Marts unterhalten sollen. Offenbar schwebte Inmon damals bereits ein sehr umfassendes Business-Intelligence-System vor, das den Steuerungs- und Cockpit-Gedanken verfolgt.

Business Intelligence bedeutet frei übersetzt Bescheid wissen über die Vorgänge im Job Floor, die angeschlossenen Managementebenen und das regionale und globale Umfeld bezüglich der Erfolgsaussichten anstehender unternehmerischer Ziele. Mathematisch beseelte Geister wie Inmon fanden sich nicht damit ab, dass erste Versuche mit Management Informations Systemen (MIS) oder Decision Support System (DSS) gründlich fehl schlugen. Unermüdlich feilten Anfang der 90er Jahre des vorigen Jahrhunderts Informatiker und Softwarearchitekten an Referenzarchitekturen für ein umfassendes Business-Warehouse-System.

Data-Warehouse-Lösungen sind nach ihrer grundsätzlichen Konzeption für das analytische Verarbeiten von Daten bestimmt. Ein Extraktions-Werkzeug zapft alle verfügbaren Datenquellen periodisch oder ereignisgesteuert an und schreibt nach voreingestellten Kriterien die Daten in einen meist physikalisch vorhandenen Zwischenspeicher (Staging-Area oder Operational Data Store). Eine Transformationskomponente integriert die unterschiedlichen Datentypen zu einem einheitlichen, konsistenten Datenbestand und lädt das Ergebnis in die Data-Warehouse-Datenbank.

Dieser so genannte ETL-Prozess findet bereits als Datenfiltering mit diversen Gruppierungs- und Verdichtungsverfahren statt. Das zugrundeliegende Datenmodell berücksichtigt quantifizierende und qualifizierende Daten ebenso wie content-bezogene und transaktionsorientierte Daten. Auf die DW-Datenbank greifen dann die Front-Ende-Werkzeuge zu, die je nach Machart Finanzdaten auf mögliche Risiken untersuchen, Umsatzzahlen für bestimmte Zeitperioden und Regionen zusammenstellen oder Absatzprognosen erstellen.

Knappes Ladefenster aus 1+n Quellsystemen

Damit das System bei den Abfragen nicht einfach ins Blaue hinein fabuliert, sind mehrere Vorkehrungen notwendig. Das Datenbankschema ist mehrdimensional vorstrukturiert, die gesamte Architektur mehrschichtig aufgebaut. In der Fachsprache ist die Rede von Datenobjekten und einer 3-Tier-Architektur. Aus der IT-Sicht sind Daten aus dem operativen Feld jetzt Rohstoff, der automatisiert gewonnen und aufgebrochen wird und dem analytischen Zugriff der Fachabteilungen und des Top-Managements zur Verfügung steht. Der Datenimport unterliegt der peniblen Reinigung von redundanten Tabelleneinträgen und einer themenorientierten Sortierung. Damit diese umfangreichen und standardisierten Basisdaten nicht ihre Aussagekraft verlieren, unterliegen Extraktion und Transformation einer periodisch fortgeschriebenen Aktualisierung. Alles muss schnell ablaufen, möglichst im 24-Stunden-Rhythmus.

Ein betriebswirtschaftliches Faktum, wie beispielsweise „Verkaufszahl“, setzt sich aus mehreren Attributen zusammen. Für die jeweils anstehende Sichtweise auf die Daten wie Produktart, Zeit und Geographie, haben DW-Experten den Begriff der Dimension geschaffen. Da meist mehrere Dimensionen im Spiel sind fasst man diese zu Hierarchieebenen zusammen und verdichtet diesen Bereich mit Hilfe einer Berechnungsvorschrift. Fachleute bezeichnen den Verdichtungsgrad von Daten innerhalb einer Hierarchie als Granularität.

Häufig übersehen wird dabei, dass die Attribute aus unterschiedlichen Quellsystemen stammen können, im Data Warehouse aber zusammen als eine „Entität“ erscheinen. Beispielsweise bestellt jemand im Internet-Shop einen MP3-Player und bezahlt per Kreditkarte, will aber das Gerät in einer Geschenkverpackung an eine bestimmte Lieferadresse schicken – dann glühen die Drähte in der damit befassten IT-Infrastruktur. Die Kunst besteht darin, die angestoßenen Buchungsvorgänge mit unterschiedlichen Laufzeiten zu einem Faktum – inklusive Empfangsquittung und potentieller Reklamation – im Data Warehouse zusammenzuführen.

Wenn das gelingt, ist der halbe Weg vom Tabellendickicht zur strukturierten Informationshülse geschafft. Technisch gesehen ist man bei einem OLAP-Modell mit eigener Rechenlogik gelandet. Ob der Markt für neue MP3-Player noch aufnahmefähig ist und wie hoch der nächste Deckungsbeitrag dieser Produktgattung sein wird, das lässt sich leider noch nicht feststellen. Diese Aufgabe obliegt eigenen Analyse-Applikationen im so genannten Frontend-Bereich, die solche Fragestellungen an das System – üblicherweise ein relationales Datenbankmanagementsystem – richten. Ob die hinterlegten Dimensionsdefinitionen und Kennzahlen ausreichen, um brauchbare Anhaltspunkte für die nächste Werbekampagne oder das Einkaufsordering zu erhalten, hängt von der Komplexität der Analyse ab – wer viel wissen will, muss lange warten.

Das Unternehmen insgesamt gerät unter den Händen der Informatik mehr und mehr zu einem mathematischen Gebilde. Nach dieser Lesart besteht die Firma aus einem sich ständig verändernden (operativen) Datenbestand, der sich mit Hilfe der Sammelkomponente (ETL) und einer Modellierungssoftware (OLAP) in einen Würfel verwandelt. Dieser getrennt von den Online-Datenbanken existierende Cube wird regelmäßig aktualisiert und bildet einen konsolidierten Datenraum mit zahlreichen Informationsobjekten und unterschiedlichen Bezugs- und Zuordnungsregeln. Die Kenngrößen eines Datenwürfels liegen in einer Faktentabelle, die auch alle Beziehungen zu den Klassifikationsstufen der verschiedenen Dimensionen enthält.

Alle Elemente in den OLAP-Würfeln beinhalten bereits thematisch vorsortierte Informationen aus unterschiedlichen Datenbanktabellen, die beim Online Transaction Processing (also im laufenden Rechenbetrieb) in relationalen Abhängigkeiten zu einander stehen. Zum Beispiel Zeittabellen wie Tag, Woche, Quartal und Jahr sowie Artikelstammdaten, die in Relation zu Produktnamen- und gruppen stehen, deren Abverkäufe an verschiedenen Standorten erfasst werden. Das zugrundeliegende Datenmodell im Data-Warehouse-Bereich beschreiben so genannte Metadaten, die in einem eigenen Repository liegen.

Wo steckt die Intelligenz

Vom komplizierten Innenleben des Data Warehouse sieht der Anwender nichts. Allenfalls kommt er mit den Metadaten in Form eines Informationskatalogs und dazugehöriger Navigationshilfe in Berührung. Er nutzt analytische Anwendungen um an die wirklichen oder vermeintlichen Informationsschätze heranzukommen. Die Bandbreite der Werkzeuge reicht mittlerweile von klassischen Reporting- und Abfragegeneratoren bis zu Data Mining und Dokumenten-Retrieval. Die schwer fassbare Business Intelligenz rattert im Hintergrund, entbindet aber keinen Nutzer von der Verpflichtung auf erfolgreiche Aktivitäten. Die wöchentlichen oder monatlichen Zielvereinbarungen gelten nicht für die Maschinen, sondern für die Mitarbeiter.

Die haben sich inzwischen daran gewöhnt, das analytische Instrumentarium, soweit es denn brauchbare Ergebnisse bringt, in Form von Warenkorb-, Kunden- oder Performanceanalysen in ihren Alltag einzubauen. Am einfachsten geht das mit Business-Kennzahlen wie Umsatz, Stückzahl, Retouren oder Lagerbestände. Die lagern in den Faktentabellen. Selektions- und Filtermerkmale holt sich der Anwender aus den Dimensionstabellen. Das ganze hinterlässt den Eindruck eines Baukastensystems, das mitunter sogar Business-Templates im Sinne inhaltlich vorgefertigter Geschäftsprozesse enthalten kann.

Gut gerüstet mit hochverdichteten Informationen gehen die Unternehmen jetzt auf die Märkte los. Was dabei herauskommt ist kein großes Geheimnis. Es mag sein, dass Anwender mit einem Risk-Management-Tool die Finanzierungs- und Refinanzierungskosten im Unternehmen auf einem niedrigen Level halten können, aber ein Blick in die Wirtschaftspresse deutet auf das glatte Gegenteil: Die Risikoanalysen der Banken gingen im Fall Hypothekenspekulation gründlich in die Hosen. Das Finanzdesaster erfasst schon auf Grund des Ausmaßes auch real wirtschaftende Teile der Gesellschaft. Ähnliches gilt für spektakuläre Fehleinschätzungen im Flugzeugbau, der Biotech- und Baubranche oder der ehemaligen Mobilfunksparte von Siemens. Auf der Liste der Pleiten des Jahres tummeln sich regelmäßig fast 30 000 Unternehmen – recht unwahrscheinlich, dass niemand ein Data Warehouse einsetzt.

Zusatz

Wer kann besser analysieren

Etwa zehn Jahre mühten sich Entwickler von IBM, Teradata, Sybase, Microsoft und Oracle ab, die mehrdimensionale Speicherung von Daten in einem Schneeflocken-, Galaxie- oder Starschema hinzukriegen. Immer wieder stehen zwei große Themen im Raum: Datenqualität und Performance. Zahlreiche Erweiterungen der Datenbanktechniken und trickreiche Einfälle wie das Aufteilen einer Tabelle mit umfangreichen Extensionen auf mehrere kleine Partitionen oder die Einführung von Bitmap-Indexierung und bessere Gruppierungsfunktionen der Abfragesprache SQL (Structured Quere Language) entschärfen die gröbsten Hindernisse. Eine kleine Gruppe von Spezialherstellern, darunter Cognos, Hyperion, Business Objects, SAS, Informatica oder Comshare, machen mit eigenen Software-Paketen auf sich aufmerksam. Meist stammen sie aus dem OLAP- und ETL-Umfeld und profitieren von den Schwächen der herkömmlichen Datenhaltung.

Während nahezu alle Komponenten auf jeder Ebene des Data-Warhouse-Modells in ihrem technischen Reifegrad zugelegt haben, wächst auch die Begehrlichkeit der Hersteller möglichst viel vom Business-Intelligence-Kuchen abzukriegen. Datenbankhersteller fangen an, die analytischen Fähigkeiten ihrer Datenbankmanagementsysteme zu erweitern. Die Performanceschwächen der klassischen OLAP-Cubes bei Verarbeitung größerer Datemnengen sind zwar noch nicht ausgebügelt, aber die meisten Hersteller lassen sich nicht auf die konkurrierenden Varianten MOLAP (multidimensionale Datenbank mit entsprechenden Datenstrukturen) oder ROLAP (Multidimensionalität wird auf zweidimensionalen Tabellen abgebildet) festlegen und bieten beides an.

Je mehr der Funktionsumfang einer Business-Intelligence-Suite ausgedehnt wird, desto stärker reizt das die Platzhirsche der IT-Welt. Im letzten Jahr schnappten sich SAP, Microsoft und IBM vormals selbständige Anbieter mit jahrelanger Entwicklungserfahrung. Zwar erhält die Gemeinde der Data-Warehouse-Anbieter mit Teradata nach der Trennung vom Mutterkonzern NCR wieder selbständigen Zuwachs, aber die Reihen haben sich mit dem Weggang von Hyperion, Cognos und Business Objects doch sehr gelichtet. Die Frage ist, was nutzt das dem Anwender.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: