GEGENSTEUERN MIT ARCHITECTED DATA MARTS

Transkript

1 WARUM SCHEITERN DATA WAREHOUSE-PROJEKTE? GEGENSTEUERN MIT ARCHITECTED DATA MARTS Data Warehouse beschreibt die Festlegung eines unternehmensweiten - und Informationsmodells und dessen IT-technische Umsetzung. Leider verleitet sie dazu, das Thema zu sehr technologisch zu begreifen und nicht als permanenten Unternehmensprozess. V or der eigentlichen Einführung eines Data Warehouse und dem Beginn dieses Prozesses sollten daher zunächst Antworten auf Fragen gefunden werden, die die Organisation des Unternehmens selbst betreffen. Hinzu kommt die Klärung der Aspekte qualität und Projektmanagement beziehungsweise Informationsbedarf der unterschiedlichen Benutzerkreise. Erst wenn diese Punkte zufriedenstellend geklärt sind, können sie schließlich zu einer adäquaten Technologieauswahl führen. Organisation des Unternehmens Die Größe und die Organisationsstruktur eines Unternehmens haben erheblichen Einfluss auf die Architektur und somit das generelle Vorgehen in Data Warehouse-Projekten. Bei großen, multinationalen Konzernen ist es mitunter sehr schwer, konzeptionell ein unternehmensweites modell zu erarbeiten. Unterschiedliche Interessen, bestehende Informationssysteme, Anforderungen von Fachabteilungen sowie internationale Tochtergesellschaften und Sparten müssen hinsichtlich des unternehmensweiten modells vereinheitlicht werden - eine Herausforderung, die viele Projekte schon in der Konzeptionsphase scheitern lässt. Selbst wenn diese erste Phase mit Hilfe zahlreicher Kompromisse überwunden wird, bergen eben diese Kompromisse die Gefahr des Scheiterns durch die fehlende spätere Akzeptanz der Benutzer in sich. Eine in der Praxis erfolgreich angewandte Methode, um diese Problematik zu umgehen, ist der Aufbau eines modularen Data Warehouse, das aus miteinander verbundenen, so genannten architected Data Marts besteht. Dabei werden einzelne, fachspezifische oder spartenspezifische basen unter sukzessiver Berücksichtigung des unternehmensweiten modells aufgebaut. Das modulare Data Warehouse ergibt s i c h 28

2 durch das physische oder logische Zusammenführen dieser Data Marts. Für diese Vorgehensweise sprechen sehr überzeugende Argumente: Der jeweilige Data Mart entspricht zu 100 Prozent dem Informationsbedarf des jeweiligen Benutzerkreises. Projektverantwortung und Sponsorenfrage sind einfacher zu klären. Die Investitionen bleiben durch die unmittelbare Nutzung der einzelnen Data Marts nach deren Fertigstellung überschaubar. Nach jedem eingeführten Data Mart wird erneut eine Entscheidung über die Fortsetzung des Projekts getroffen. Bei Unternehmen mit weniger ausgeprägten Organisationsformen, wie zum Beispiel im Mittelstand, kann es allerdings sinnvoller sein, eine unternehmensweite atomare basis zu konzipieren und zu erstellen, aus der die benötigten Informationen generiert werden. Dies wird vor allem im Zuge der Umsetzung von Basel II für viele investitionsorientierte Firmen von großer Wichtigkeit sein, da neben den harten Faktoren - den Kennzahlen, die aus der Bilanzkonten und GuV-Konten gewonnen werden - die so genannten weichen Faktoren, die den Umfang und die Qualität der Unternehmensleistung widerspiegeln, eine große Rolle spielen. Diese Informationen werden unter anderem aus analytischen CRM-Systemen erzeugt und umfassen Wachstumsstrategie, Vertriebsstrategie, Markt und Wettbewerb, Management und Organisation sowie Controlling. qualität Selbstredend spielt das Thema qualität bei allen Anwendungen im Unternehmen eine wichtige Rolle. Besonders deutlich wird sein Stellenwert jedoch beim Aufbau von Data Warehouse- beziehungsweise Data Mart-Lösungen. Untersuchungen haben ergeben, dass fünf bis 20 Prozent aller gespeicherten in Unternehmen fehlerhaft oder nicht zu nutzen sind. Der Produktionsfaktor Information lässt sich aber nur dann erfolgreich nutzen, wenn eine hohe qualität gegeben ist - gleiches gilt für die Akzeptanz entscheidungsorientierter Informationssysteme im Sinne von Data Warehousing und Business Intelligence Managementreporting Legalreporting Artikelauswertungen/- analysen Clickstreamanalysen Lieferantencontrolling Einkaufscontrolling Werbeerfolgrechnung Kundenanalysen Aktions-/Kampagnencontrolling Kostenrechnung Artikelinformationen Artikeldaten Lagerdaten Kundeninformationen Kundendaten ergänzende Kundendaten Aktionsdatendaten Kampagnendaten Basisinformationen Ground Level Auftrags-/Frakturdaten Einkaufs-/Bestelldaten Versanddaten Buchungsdaten Zeitachse Lieferanteninformationen Lieferantendaten ergänzende Einkaufsdaten Organisationsstruktur Beteiligungsdaten Kosteninformationen Kostenarten Kontoplan Bilanz/GuV Struktur opr. Systeme VH opr. Systeme EH opr. Systeme GH Finanzsysteme Bild 1: Das Data Warehousing als Unternehmensprozess. Kostenstellen-/Firmeninformationen Werbe-/Marketinginformationen Es hat sich als äußerst vorteilhaft erwiesen, zu Projektbeginn sogenannte Scoping Workshops durchzuführen, in denen ein Grobund Feinkonzept erarbeitet oder eine Überprüfung bereits bestehender Konzepte vorgenommen wird. 29

3 Bild 2: Die unterschiedlichen Prozessaspekte des Data Warehousing als architected Data Marts. 2 dispositiv Data Mart Data Mart Data Mart Nicht von ungefähr steht die Technologieauswahl an letzter Stelle. Sind die oben genannten Einflussfaktoren für ein erfolgreiches Data Warehouse-Projekt nicht erfüllt, kann auch die beste Technologie das Scheitern nicht verhindern. Aller- Maßgebend für die spätere Technologieauswahl können allein die im Scoping Workshop erarbeiteten und beschlossenen Anforderungen der unterschiedlichen Benutzerkreise sein. operativ (BI). Mit der zunehmenden internen und externen Vernetzung unterschiedlicher Informationssysteme rückt die Frage nach der syntaktischen und semantischen Korrektheit der basis somit immer weiter in den Vordergrund. Damit fällt häufig im Vorfeld eines Data Warehouse-Projektes der Startschuss für eine langwierige Qualitäts- Offensive im -Management. Dabei handelt es sich jedoch um eine undankbare, manchmal gar unmögliche Aufgabe, da sie die abstrakte Vorwegnahme von späteren Folgefehlern im Data Warehouse erfordert - Fehler, die oft in den relevanten beständen und ihren Metadaten liegen und erst im Data Warehouse selbst bei der Verarbeitung eben dieser Strukturinformationen sichtbar werden. Es liegt daher nahe, den bewirtschaftungsprozess ins Data Warehouse zu verlegen und die Transformation zu den gewünschten Informationen als Katalysator zu be- pool unternehmensweite, vereinheitlichte Betrachtungsweisen und Begriffe 1 Wertschöpfungskette Data Mart trachten. Die erkannten Fehler müssen dann - und das ist eine unumstößliche Regel - in den Ursprungssystemen korrigiert werden, wenn möglich mittels geschäftsprozessorientierter Plausibilitätsprüfungen. So entsteht eine Doppelprüfung, denn diese Plausibilitätsprüfungen (Stichwort Cleansing ) sollten ebenfalls in den bewirtschaftungsprozess (ob mit oder ohne ETL-Tools) integriert werden. Dieser innerhalb des Projektes entstehende Aufwand muss allen Beteiligten bereits vor Projektbeginn ins Bewusstsein gerufen und eingeplant werden. Projektmanagement 3 Unabhängig davon, welche Vorgehensweise gewählt wird, sind in Data Warehouse-Projekten bestimmte Besonderheiten zu beachten, die in der Sensibilität der und auch des schutzes begründet liegen, aber auch in der politisch hoch angesiedelten Bedeutung des Projektes für das jeweilige Unternehmen. Es hat sich als äußerst vorteilhaft erwiesen, zu Projektbeginn so genannte Scoping Workshops durchzuführen, in denen ein Grob- und Feinkonzept erarbeitet oder eine Überprüfung bereits bestehender Konzepte vorgenommen wird. Wichtig ist, dass an den Workshops maßgebliche Vertreter der jeweiligen Fachbereiche teilnehmen, so dass die Ergebnisse von allen getragen werden und bindend sind. In den Workshops sollten folgende Punkte festgelegt werden: Definition des Projektziels Definition der Geschäftsprozesse Kosten-Nutzen-Analyse Gewünschte Berichte beziehungsweise Analysen und Auswertungen (gewichtet nach A, B und C) Abgrenzung (Was wird nicht gemacht?) Definition von Projektphasen und Meilensteinen Über den gesamten Verlauf des Projektes ist es wichtig, alle Teilnehmer analog zu diesen Ergebnissen über den Projektfortschritt zu informieren. Hierzu bieten sich Korrespondenz und Meeting-Protokolle, Ressourcenzuordnungen und Zeitpläne, Berichte zu offenen Punkten, Berichte zum Projektstatus (zeitlich und monetär), Dokumentationen und die Präsentation der Meilenstein-Ergebnisse vor allen Beteiligten an. Grundsätzlich lassen sich bei Data Warehouse-Projekten drei Arten der Abwicklung unterscheiden: Festpreis, nach Zeit und Material (Vorgabe: Pflichtenheft) und Prototyping. Bei Festpreisprojekten ergeben sich mögliche Probleme aus Data Warehouse-Besonderheiten, wie der oben beschriebenen Sicherung der qualität, oder durch notwendige Prozessänderungen, die sich aus dem Umfeld des Unternehmens ergeben und unter Umständen erhebliche Modifikationen nach sich ziehen. Das reine Prototyping kann wiederum zum Fass ohne Boden werden. Geht man von der Prämisse aus, dass Data Warehousing ein permanenter Unternehmensprozess ist, gilt das natürlich auch für die Zeit der Erstentwicklung. Es empfiehlt sich daher ein Mix, der sich aus den Projektzielen herleitet und sich (eventuell mit Prototyping) aus Festpreis und Zeit- und Material-Komponenten zusammensetzt. Technologie IT Management

4 dings kann eine nicht passende Technologie dieses Scheitern auch problemlos verursachen. Technologisch ausgerichtete Glaubensfragen, wie rein relational, ROLAP, MOLAP usw. sind daher fehl am Platz. Darüberhinaus gehören auch Technologien, die im Unternehmen bereits einsetzt werden, auf den Prüfstand. Maßgebend können allein die im Scoping Workshop erarbeiteten und beschlossenen Anforderungen der unterschiedlichen Benutzerkreise sein. Ergab das Anforderungsprofil, dass 80 Prozent der potentiellen Nutzer Berichtsfunktionalitäten mit eingeschränkten Analysefunktionen wie Drill Down oder Dimensionsrotation nutzen, ist es aus Kosten-Nutzen-Sicht wenig sinnvoll, diese mit dem gleichen Analyse-Tool auszustatten, wie die restlichen 20 Prozent, die weit reichende Analysefunktionalitäten bis hin zum Data Mining benötigen. Das Gleiche gilt für die ermittelten zugriffsprofile. Greifen 80 Prozent der Nutzer auf verdichtete zu, kann dies aufgrund der schnellen Zugriffszeiten für eine MOLAP-Lösung oder eine Hybrid-Lösung sprechen, die sich aus integrierter mehrdimensionaler und relationaler haltung zusammensetzt. Sollen hingegen Szenarien und Planungen innerhalb der bestehenden Strukturen möglich sein, muss ein Schreibzugriff vorhanden sein. Das im Workshop verabschiedete Anwenderkonzept mit Finanzdaten MAFO- Ökonometrische Data Warehouse bewirtschaftung und Cleansing Strukturinformationen CRM/ Vertrieb Produktion bestimmten Zugriffsparametern muss in Verbindung mit Unternehmensportalen und Weblösungen realisierbar sein. Die definierten Update-Intervalle - oder mit anderen Worten das Einfrieren von bestimmten im Data Warehouse, damit alle für eine definierte Zeit auf den gleichen Informationsbestand zugreifen - sollten genau in die vorhandenen Zeitfenster passen. Damit verbunden ist die Frage nach dem Einsatz eines ETL-Tools oder einer individuellen Lösung. Hinsichtlich der Technologie sind also eine Vielzahl wichtiger Fragen zu klären: Gibt es Informationen, die in Echtzeit (Realtime oder Active Data Warehouse) hinzugespielt werden und werden hierfür EAI-Technologien genutzt? Sind die vorhandenen Data Warehouse-Komponenten damit kompatibel? Sollen Closed-Loop-Komponenten, wie zum Beispiel Kampagnenmanagement, betrieben werden? Wie sieht die Integration mit bereits eingeführten Komponenten aus? Letzteres ist durchaus eine wichtige Frage, auch wenn die Komponenten von einem Hersteller kommen. Die Fragen, die hinsichtlich der Technologie gestellt werden müssen, lassen sich beliebig weiterführen und sollen hier lediglich einen Eindruck der Komplexität der richtigen Entscheidung vermitteln. Zusammenfassung Lager/ Distribution Für das Scheitern beziehungsweise den nicht voll zufriedenstellenden Erfolg von Data Warehouse-Projekten können somit sehr unterschiedliche Faktoren ausgemacht werden. Über die Auswahl der richtigen Technologie hinaus sind diese häufig beim Projektmanagement - was die kalkulierten Kosten oder die Zeit angeht - zu finden, wenn unrealistisch Bild 3: Vorgehensweise zur Sicherung der qualität im Data Warehousing. Es sind eine Vielzahl wichtiger Fragen zu klären: Gibt es Informationen, die in Echtzeit (Realtime oder Active Data Ware-house) hinzugespielt werden und werden hierfür EAI-Technologien genutzt? Sind die vorhandenen Data Warehouse-Komponenten damit kompatibel? IT Management

5 Bild 4: Themen und Technologien beim Data Warehousing. eigene Berichte oder eigene haltung Relationale Tabellenabfragen, Data Mining, Olap-Analysen OLAP: API s (OLE DB, SNAPI usw.) SQL ROLAP: Java, ActiveX, SQL Über die Auswahl der richtigen Technologie hinaus sind diese häufig beimprojektmanagement was die kalkulierten Kosten oder die Zeit angeht zu finden, wenn unrealistisch geplant oder versteckte Kosten unterschätzt werden. Webserver unternehmensinterne Relationale haltung nach lösungsorientiertem modell, teils mit Aggregation geplant oder versteckte Kosten unterschätzt werden. Weitere Aspekte sind zum Beispiel auch die überzogenen Erwartungen der Anwender oder deren mangelnde beziehungsweise fehlende Akzeptanz. Es erscheint daher sehr sinnvoll, die Abwicklung des gesamten Projekts an einer Stelle zu bündeln. Es hat sich bewährt, ein externes Beratungsunternehmen hinzuziehen, das bereits über Erfahrungen bei der Durchführung derartiger Projekte verfügt und sich voll und ganz auf Multidimensionaler OLAP Server mit multidimensionaler haltung extraktion, -aggregation, -selektion, -prüfung, -bereinigung, -transformation Kassensystem Front Office denormalsiert Personalsystem Planungssysteme Buchhaltungs-- systeme Repository BDE Wegewirschaftssysteme PPS Vertriebssteuerung Rechnungswesen Warenwirtschaftssysteme normalsiert Relationaler OLAP- Server mit relationaler haltung oder on the fly -Berechnung Scannerdaten, Marktforschungsdaten, Währungsumrechnungen, Aktienkurse, Brancheninstitute Repository zur Verwaltung der und Strukturen unternehmensexterne die Aufgabe konzentrieren kann. Dieses sollte den Prozess von Anfang bis Ende begleiten und sowohl Fragen der Organisation des Unternehmens, der qualität als auch des Projektmanagements mit allen Beteiligten ansprechen, bündeln und die spezifischen Problematiken berücksichtigen. Ausführliche Tests, Aktivitäten zur Qualitätssicherung und Produktionalisierung, technische und inhaltliche Dokumentationen sowie die anschließende kompetente Unterstützung der Anwender sind darüber hinaus wichtige Erfolgsfaktoren. Nur wenn Kommunikations-, Kompetenz-, Verantwortungs- und Verständnisprobleme zwischen Anwendern, der IT-Abteilung und dem Projektmanagement durch gezielte und kompetente Beratung überwunden werden, kann ein Data Warehouse-Projekt zur Zufriedenheit eines Unternehmens durchgeführt werden. Wolfgang Dähler w.daehler@datamart.de IT Management