Projektmanagement

Eines der heute noch vielerorts herrschenden Missverständnisse ist aber die Annahme, dass ein Data Warehouse einmalig erstellt wird und dann lediglich der üblichen Programmpflege unterliegt. Um einen nachhaltigen Nutzen für das Unternehmen zu gewährleisten, muss hier jedoch ein Unternehmensprozess definiert und installiert werden. Um dies zu verdeutlichen, wird häufig der Begriff des Data Warehousing als Prozess genutzt. Dieses Verständnis ist gerade deshalb von hoher Bedeutung, weil ein solcher Prozess sowohl die Technik und den Service des IT-Bereichs beansprucht als auch die eigentlichen Nutznießer der Informationen, den Fachbereich und das Management.

Ein erfolgreicher Betrieb, aus dem tatsächlich ein Nutzen gezogen werden kann, hängt wesentlich von dem abgestimmten, harmonischen Zusammenwirken der Prozesselemente und der Beteiligten ab. Dieser Erfolg lässt sich an der Flexibilität und möglichen Anpassungsgeschwindigkeit ablesen. Schließlich unterliegen Prozesse der Geschäftssteuerung permanenten Veränderungen, aus denen regelmäßig neue Anforderungen an das Data Warehouse erwachsen. Nur wenn diese schnell und problemlos umgesetzt werden können, was in der Regel das nahtlose Zusammenwirken aller Beteiligten erfordert, können wichtige Wettbewerbsvorteile erzielt und gesichert werden.

Bei der Strukturierung der Prozesse für den Betrieb eines Data-Warehouse-Systems sollte unbedingt darauf geachtet werden, dass diese durchgängig sind. So müssen die (vertikalen) Abläufe den kompletten Weg der Dateninhalte von der Quelle über die einzelnen Transformationsschritte bis hin zur Bereitstellung für die Berichts- und Analysezwecke der Anwender umfassen. Dies gilt für jeden Data Mart, also jeden Fach- oder Themenbereich. Ein weiterer (horizontaler) Prozess sollte etabliert werden, der die Erweiterung um weitere Data Marts umfasst und zugleich deren künftigen Betrieb berücksichtigt, also sowohl einen harmonisierten Ablauf als auch die Abstimmung der Inhalte.

Die Geschäftsabläufe sind erst dann vollständig, wenn ein klares Rückkopplungsverfahren mit den operativen Systemen festgelegt und der Datenkreislauf geschlossen wird. Denn nur so kann sichergestellt werden, dass Ergänzungen, Änderungen oder Korrekturen, die im Data Warehouse festgestellt werden, auch an die Quellen weitergegeben und dort beispielsweise in der Stammdatenpflege berücksichtigt werden.Stabile Prozesse im Umfeld des Data Warehouse sind eine wichtige Voraussetzung für die Verfügbarkeit und Zuverlässigkeit der Managementinformationen. Eine Herausforderung liegt hier in der Anpassbarkeit der Strukturinformationen, wie Produktportfolio, Kundenstamm und Unternehmensorganisation, da diese den wahren Mehrwert der Informationen ausmachen.

Auch Größe und Organisationsstruktur eines Unternehmens haben erheblichen Einfluss auf die Architektur und somit das generelle Vorgehen in Data-Warehouse-Projekten. In großen, multinationalen Konzernen ist es mitunter sehr schwer, konzeptionell ein unternehmensweites Datenmodell zu erarbeiten. Unterschiedliche Interessen, bestehende Informationssysteme, Anforderungen von Fachabteilungen sowie internationale Tochtergesellschaften und Sparten müssten vereinheitlicht werden – eine Herausforderung, die viele Projekte bereits in der Konzeption scheitern lässt.

Selbst wenn diese erste Phase mit Hilfe zahlreicher Kompromisse überwunden wird, bergen eben diese die Gefahr des Misslingens, weil die Lösung nicht den Bedürfnissen entspricht. DATA MART Consulting empfiehlt den Ansatz des modularen Data Warehouse durch architected Data Marts, also einzelne, fach- oder spartenspezifische Data Marts unter Berücksichtigung des unternehmensweiten Datenmodells. Bei der modularen Konzeption durch architected Data Marts erhält idealerweise jeder Anwenderkreis nur die auf seine Bedürfnisse zugeschnittenen Informationen. Dies hat auch den Vorteil, dass Projektverantwortung und Sponsorenfragen einfacher zu klären sind und Investitionen durch die unmittelbare Nutzung der einzelnen Data Marts nach deren Fertigstellung überschaubar bleiben. Zudem kann nach jedem eingeführten Data Mart neuerlich über die Fortsetzung des Projekts entschieden werden.

Natürlich spielt die Datenqualität bei allen Anwendungen im Unternehmen eine wichtige Rolle. Untersuchungen haben jedoch ergeben, dass 5 bis 20 Prozent aller gespeicherten Daten in Unternehmen fehlerhaft oder so nicht verwendbar sind. Dieses Problem spitzt sich zu, wenn immer mehr unterschiedliche Informationssysteme intern und extern miteinander verknüpft werden. Dementsprechend hängen auch der Erfolg und die Akzeptanz entscheidungsorientierter Informationssysteme stark von der syntaktischen und semantischen Korrektheit der zugrunde liegenden Quellsysteme ab.

Die Folge ist, dass häufig im Vorfeld eines Data-Warehouse-Projekts der Startschuss für eine langwierige Qualitätsoffensive im Datenmanagement fällt. Dies ist allerdings eine undankbare, manchmal sogar unlösbare Aufgabe, da sie die abstrakte Vorwegnahme von späteren Folgefehlern im Data Warehouse erfordert. Diese sind jedoch oft in den relevanten Datenbeständen und ihren Metadaten verborgen und werden erst im Data Warehouse selbst bei der Verarbeitung eben dieser Strukturinformationen sichtbar.

Die Datenbewirtschaftung sollte deshalb ins Warehouse verlegt werden, wobei die Transformation zu den gewünschten Informationen als Katalysator dient. Fehler müssen in den Ursprungssystemen korrigiert werden, wenn möglich mittels geschäftsprozessorientierter Plausibilitätsprüfungen. So entsteht eine Doppelprüfung, denn diese Kontrollen (Stichwort „Cleansing") sollten ebenfalls in den Datenbewirtschaftungsprozess, ob mit oder ohne ETL-Tools (Extraktion, Transformation, Laden), integriert sein. Dieser innerhalb des Projekts entstehende Aufwand muss allen Beteiligten bereits vor Projektbeginn ins Bewusstsein gerufen und eingeplant werden.

Eine Besonderheit von Data-Warehouse-Projekten ist die Arbeit mit sensiblen Daten, was Fragen zum Datenschutz aufwirft, sowie der Umstand, dass solche Projekte unternehmenspolitisch hoch angesiedelt sind. Hier hat es sich als vorteilhaft erwiesen, zu Projektbeginn Scoping-Workshops zu veranstalten, in denen ein Grob- und Feinkonzept erarbeitet oder bereits bestehende Vorlagen geprüft werden. Dabei sollten das Projektziel und die Geschäftsprozesse definiert werden und eine Kosten-Nutzen-Analyse erfolgen. Ferner müssen die Aufgaben klar zugeordnet und Projektphasen beziehungsweise Meilensteine festgelegt werden. Hilfreich ist auch, die gewünschten Berichte beziehungsweise Analysen und Auswertungen nach A, B und C zu gewichten und eine klare Prioritätenliste festzulegen. Die Bedeutung der Organisation, sowohl bei der Implementierung als auch im Betrieb, wird heute leider noch oft unterschätzt. Wer aber Data Warehousing als Prozess versteht, muss auch die Ressourcen entsprechend organisieren. Ob dies über eine Abteilung oder lediglich ein virtuelles Team erfolgt, ist zweitrangig.

Wichtig ist, dass an den Sitzungen maßgebliche Vertreter der jeweiligen Fachbereiche teilnehmen, so dass alle Beteiligten die Ergebnisse tragen und auch im Verlauf des Projekts als bindend erachten. Während der Umsetzung sollten sie stets Informationen über den aktuellen Stand der Dinge erhalten. Das können Kopien der Korrespondenz, Sitzungsprotokolle, Ressourcenzuordnungen und Zeitpläne, Berichte zu offenen Punkten und zum Projektstatus (zeitlich und monetär), Dokumentationen sowie die Präsentation der Meilenstein-Ergebnisse sein.

Grundsätzlich lassen sich drei Arten der Umsetzung unterscheiden: Festpreisprojekte, Projekte nach Zeit und Material – beide auf der Basis eines Pflichtenhefts – und das Prototyping. Erstere bergen die Gefahr, dass Prozessänderungen oder die Sicherung der Datenqualität erhebliche Modifikationen erfordern. Das reine Prototyping wiederum kann zum Fass ohne Boden werden. Es empfiehlt sich daher ein Mix beider Arten, der sich aus den Projektzielen herleitet und sich – eventuell mit Prototyping – aus einem Festpreis sowie Zeit- und Materialkomponenten zusammensetzt.

Erst wenn diese Entscheidungen und Vorarbeiten bewältigt sind, sollte die Produktauswahl in Angriff genommen werden. Maßgebend sollten hierbei die in den Scoping-Workshops erarbeiteten und beschlossenen Anforderungen der unterschiedlichen Anwenderkreise sein.

Wenn sich zum Beispiel gezeigt hat, dass 80 Prozent der Anwender Berichtsfunktionen 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 weitreichende Analysefunktionen bis hin zum Data Mining benötigen. Das Gleiche gilt für die ermittelten Datenzugriffsprofile. Greifen 80 Prozent der Nutzer auf verdichtete Daten zu, kann dies für eine schnelle MOLAP- oder eine Hybrid-Lösung sprechen, die sich aus einer integrierten mehrdimensionalen und relationalen Datenhaltung zusammensetzt.

Sollen hingegen Szenarien und Planungen innerhalb der bestehenden Strukturen möglich sein, bedarf es des Schreibzugriffs. Das im Workshop verabschiedete Anwenderkonzept muss sich in Verbindung mit Unternehmensportalen und Web-Lösungen realisieren lassen. Die definierten Update-Intervalle – oder mit anderen Worten das „Einfrieren" von bestimmten Daten 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 Technik sind also viele Fragen zu klären: Gibt es Informationen, die in Echtzeit eingespielt werden, und sind hierfür EAI-Technologien nötig? Sind die vorhandenen Data-Warehouse-Komponenten damit kompatibel? Sollen Closed-Loop-Komponenten, wie zum Beispiel im Kampagnen-Management, betrieben werden? Wie sieht die Integration mit bereits eingeführten Komponenten aus? Die Fragen lassen sich beliebig weiterspinnen und sollen hier lediglich andeuten, wie komplex die Entscheidungsfindung sein kann.Heinrich Smielowski/hei