Als TUI 1998 begann, sich an die Bereinigung seines Informationsdschungels zu machen, hatte das Großunternehmen mit einer heterogenen IT-Landschaft zu kämpfen. Die einzelnen Geschäftsbereiche betrieben eigene operative Systeme, aus denen sie ihre Daten für Auswertungen und Berichte gewannen. Die Bandbreite reichte von Buchungs-, Kundendienst- und Kostenrechnungssoftware bis hin zu Kalkulationslösungen und Systemen für die Beförderungsplanung- und Disposition. "Es gab keine einheitliche Sicht auf die Informationen und deshalb eine Vielzahl von Inkonsistenzen", erinnert sich Heinz Kreuzer, CIO bei TUI und Sprecher der Geschäftsführung der IT-Tochter TUI-Infotec. In der Folge seien uneinheitliche Listen aus verschiedenen Datenbanksystemen gewonnen worden. Die Weiterverarbeitung lief häufig über "manuelle Schnittstellen" - die Daten mussten teilweise ausgedruckt und in andere Excel- oder Access-Systeme eingegeben werden.

Bevor sich TUI an die Einführung eines konzernweiten Data Warehouse machen konnte, musste daher ein betriebswirtschaftliches Modell erarbeitet werden. Dabei definierte das Unternehmen seine gesamte Begriffs- und Datenwelt sowie die verbindenden Beziehungsgeflechte. Die TUI konzentrierte sich bei ihrem Initialprojekt auf den Bereich Touristik in Deutschland. Dabei standen die Themenfelder Hotel, Flug und Vertrieb im Vordergrund. "Man kann nicht alles in einem einzigen Projekt bewältigen", erklärt Kreuzer. Vielmehr müsse man einen Teil des Unternehmens herauspicken und sauber modellieren: "Wenn da die richtigen Leute mitarbeiten, kann man das Modell zu 90 Prozent auf andere Bereiche und Märkte übertragen." Nachdem das betriebswirtschaftliche Datenmodell stand, machte sich der Touristikkonzern daran, seinen Datenbestand zu sichten und die Qualität zu prüfen. "Die Systeme befanden sich in einem ziemlich schockierenden Zustand", so Kreuzer. Besonders problematisch sei

der teilweise unsaubere Umgang mit einzelnen Datenfeldern gewesen: "Wenn ein Feld durch Systemerweiterungen oder neue Anforderungen missbraucht wird, lassen sich die dort hinterlegten Informationen oft nur noch im Zusammenhang mit anderen Feldern interpretieren."

Hinzu kam, dass Kennzahlen oder Berichtsgrößen in den verschiedenen Systemen unterschiedliche Bezeichnungen hatten. Beispielsweise waren für den Kunden die Begriffe Gast, Teilnehmer und PAX in Umlauf. Andererseits gab es Fälle, wo sich hinter einzelnen Begriffen wie Umsatz oder Deckungsbeitrag unterschiedliche Bedeutungen verbargen. Bestimmte Kenngrößen werden außerdem nicht in allen Systemen nachgehalten. Die Kategorie "provisionspflichtiger Umsatz" ist beispielsweise nur für den Vertrieb relevant. "Viel Wissen steckt da in den Köpfen der Mitarbeiter", so Kreuzer. Semantische Brüche hätten sich daher nicht mit Hilfe von Tools analysieren lassen: "Das war eine echte Sisyphusarbeit."