Datenintegration ist nicht nur IT-Sache

18.03.2005
Praktiker erläutern, wie man steigende Anforderungen im Data Warehousing bewältigen kann.

Die Bewirtschaftung eines Data Warehouse oder Data Mart in Business-Intelligence-(BI-)Projekten zählen zu den teuersten und langwierigsten Aufgaben. Zugleich steigen die Anforderungen. Treiber sind vor allem gesetzliche Auflagen (Compliance), steigende Datenvolumina etwa im Handel oder der TK-Industrie sowie der Wunsch, die Lösungen für operative Prozesse nützlicher zu machen. Das Management, aber auch Fachbereiche fordern daher eine konsolidierte Datenhaltung sowie eine abteilungsübergreifende und zeitnahere Sicht auf die gespeicherten Geschäftsinformationen. Viele Lösungen sind indes oft nur lokal und teilweise redundant aufgebaut worden.

Früh auf Datenqualität setzen

Wie sich die Daten wertvoll machen und gut integrieren lassen, war Thema einer Podiumsdiskussion der computerwoche auf der CeBIT. Dort riet BI-Experte und Berater Wolfgang Martin, sich um die Datenqualität frühzeitig in den operativen Prozessen zu kümmern und nicht erst beim Aufbau des Data Warehouse. Letzteres sollten Unternehmen nicht länger über die immer noch verbreiteten skriptbasierenden Batch-Läufe befüllen, weil es hier zu Unterbrechungen kommen kann, was wiederum zu inkonsistenten Daten führt. Zudem sei immer öfter keine Zeit mehr vorhanden, den Lauf zu wiederholen.

Laut Georg Franzke, Experte für ETL und Datenqualität (ETL = Extraktion, Transformation und Laden) bei SAS Deutschland, lasse sich über Skripte die Datenqualität nicht verbessern: "Spätestens dann, wenn die erste Fehlentscheidung auf der Basis falscher Berichte getroffen wird, kann dies Millionen kosten." Soll dennoch kein spezielles ETL-Werkzeug zur Automatisierung der Prozesse eingeführt werden, müssten Anwender laut Martin das Skripting mit einem System-Management kombinieren und mit klaren Vorgaben (Restart und Recovery) verbinden. Manche Unternehmen steuern das Datenladen auch mit Message-Queues.

Auch Andreas Helbig, Ressortleiter MIS, Bereich Zentrales Controlling bei der TÜV Rheinland Group, kennt die Herausforderungen bei der Datenintegration. Sein Unternehmen führte 1995 zunächst ein standardisiertes Management-Informationssystem für die Konzernplanung und das Berichtswesen ein. Dazu mussten heterogene ERP-Systeme angebunden und einheitliche Datenstrukturen geschaffen werden. Letzteres geschah gleichzeitig bereits im Quellsystem, wodurch die Akzeptanz deutlich höher lag als bei herkömmlichen Brückentabellen zur Überführung. Zudem sollte die Lösung erweiterbar sein.

In einem zweiten Projekt wurde ein Berichtswesen für die Matrixorganisation der TÜV Rheinland Group aufgebaut. Hier lagen Herausforderungen darin, dass der Datenzugriff auf die spezifischen Kostenrechnungssysteme der einzelnen TÜV-Gesellschaften erfolgen sollte, was zu Interessenskonflikten zwischen der Kostenrechnung als internem Führungsinstrument und der konzernweiten Segmentberichterstattung führte. Einheitliche Datenstrukturen mussten daher aufgebaut werden. Zudem wird der Detaillierungsgrad der Lösung laufend weiterentwickelt.

Heute existieren eine Vielzahl standardisierter Data Marts beim TÜV Rheinland, die miteinander verbunden sind. Im Gegensatz zu zentralen, aber laut des Managers schwer wartbaren Data Warehouses habe dieser Ansatzes "den Vorteil, dass wir angesichts der sich häufig ändernden Anforderungen Applikationen deutlich schneller ändern können." Allerdings will man sich die Option einer Konsolidierung aller Data Marts bewahren. Alternativ, so SAS-Mitarbeiter Franzke, können Anwender auch ein wei- teres Data Mart aufbauen, das aber schon die neue Architektur hat. "Wichtig ist, die Zahl der Schnittstellen so klein wie möglich zu halten, da hier die Fehler lauern."

Handcodiertes ablösen

Laut dem BI-Spezialisten Martin lassen sich Data Marts bei guter Architektur auch weiterverwenden. "Handcodierte Lösungen sollte man aber irgendwann ablösen." Zudem wüchsen Analytik und operative Prozesse zusammen und verlangten künftig eine serviceorientierte Architektur. In ihr wäre dann das Data Warehouse ein Service-Provider. Ebenso rät ETL-Spezialist Franzke eine Architektur für die Datenintegration möglichst vorausschauend zu planen. Dabei sollte auch die Datenqualität nicht aus den Augen verloren werden. Es sei kein technisches Problem mehr: "Letztlich brauchen Sie nur einen weit oben im Unternehmen, der sagt: Macht es!"

Dem stimmte auch Helbig bei. In seinem Projekten hing der Erfolg letztlich vom Sponsoring des Vorstands ab. Der Weg zu einheitlichen Vorgaben war indes auch für Helbigs Team langwierig und brauchte viel Überzeugungsarbeit. Sein eigener Bereich MIS fungiert dabei als Vermittler zwischen Fachabteilungen und IT. Während BI-Experte Martin die Benennung eines Vorstandsbeauftragten für Datenqualität vorschlug, strebt Helbig keine Institutionalisierung an. "Wir müssen aber dafür sorgen, dass die Daten für alle nachvollziehbar bleiben, da so eine hohe Datenqualität und Benutzerakzeptanz entstehen."

Ein anderes Beispiel gab Jens Ulrich Höft, Mitarbeiter im Bereich Schaden-Controlling Data Warehouse der Assekuranzgruppe VGH. In seinem Unternehmen wird derzeit ein Data Warehouse für das Controlling eingeführt, das ein Host-basierendes Altsystem durch ein inhaltlich und technisch effizienteres Statistiksystem ersetzen soll. Die Probleme mit der bisherigen Lösung lagen darin, dass sie einen hohen Programmieraufwand verursachte und nur von Spezialisten gewartet werden konnte. Hinzu kamen lange Antwortzeiten, weil die Lösung auf dem Host neben anderen operativen Systemen im Einsatz war. Ebenso waren übergreifende Auswertungen nur mit hohem Aufwand machbar und die Resultate oft nicht eindeutig. Mittlerweile ist ein Bereich des Data Warehouse produktiv. Anwender könnten jetzt Auswertungen vornehmen, die sie für tägliche Entscheidungen brauchen. So lassen sich beispielsweise Versicherungsdaten aus dem Bereich Schaden und Vertrieb kombinieren, um zu prüfen, ob eine Schadensregulierung vor Ort zu Mehrabschlüssen führt.

Aufbau des Projektteams

Organisatorisch ist laut Höft nicht mehr allein die IT für das Data Warehouse verantwortlich. Vielmehr umfasst das Projektteam Controller, Entwickler, zwei externe Berater und einen Mitarbeiter eines IT-Dienstleisters. "Es sollen jene die ETL-Prozesse schreiben, die sich auch mit den Daten am besten auskennen." ETL-Experte Franzke hält dennoch Datenqualität für ein IT-Thema. Nur sie könne als neutrale Instanz die sich zum Teil überlappenden Anforderungen mehrerer Abteilungen koordinieren. Zudem gebe es neue Ansätze, in denen die Fachabteilung die Datenqualität mit Hilfe von Metadaten bestimmt, also was Dubletten, Vor- und Nachname etc. sind. Die Steuerung des ETL-Prozesses übernehme hingegen die IT. Dem stimmte Martin zu: "Fachliche Anforderungen gehören in die Fachabteilung, denn es gibt keine Datenqualität ohne Metadaten."