Falle 1: Ein Data-Warehouse wird nur deshalb mit Informationen gefüllt, weil die Daten schon vorhanden und verfügbar sind.
Wer kennt nicht den alten Konflikt, den für einen DV-Fachmann zu global artikulierten Bedürfnissen der Anwenderseite programmtechnisch gerecht zu werden? Umfangreiche Listen aus Tabellen, Bezeichnungen, Datenauszügen verwirren eher und helfen dem künftigen Nutzer nicht bei der Entscheidung, was denn nun für das künftige Data-Warehouse wichtig ist. Auch die Einteilung in Kategorien wie "absolut notwendig", "wichtig" und "nice to have" sind bei diesem Ansatz nur ein Zeichen für die Unerfahrenheit des DW-Managers. Es ermüdet den User, endlose Listen von Feldnamen, Tabellendefinitionen etc. abzuarbeiten, die richtigen herauszufiltern und läßt die Begeisterung abflauen. Das kann nur in einer Sackgasse enden.
Falle 2: Das Datenbankdesign eines Data-Warehouse gleicht dem einer transaktionsorientierten Datenbank und ist auf sie übertragbar.
Data-Warehousing läßt sich nicht mit der transaktionsorientierten Verarbeitung vergleichen. Hier entwickelt der Anwendungsprogrammierer einen Prozeß, der zehn-, 1000- oder 10000mal in der gleichen Form benutzt wird. Data-Warehousing dagegen folgt der Verhaltensweise eines Anwenders: ein Problem oder eine Fragestellung nach jeder Seite und in jede Richtung hin untersuchen und damit einmalige, jeweils unterschiedliche Abfragen auf den Datenbestand absetzen. Das Ziel ist, Summen, Aggregate, Durchschnitte zu bilden und Trends zu berechnen. Deshalb sind Warehouse-Datenbanken denormalisiert, speziell für diese Form der Massendatenanalyse ausgelegt und müssen entsprechend aufgebaut werden. Wer lediglich die Daten spiegelt oder extrahiert, ohne sie zu bereinigen - womöglich noch auf demselben Zielsystem -, zahlt nicht nur seinen Tribut an Performance und Speicherkapazität, sondern findet am Ende anstatt eines Warehouse einen Datenfriedhof vor.
Falle 3: Die Wahl fällt auf einen Data-Warehouse-Manager und Projektleiter, dem die technologische Lösung näherliegt als die Interessen und die Akzeptanz der Benutzer.
Data-Warehouse ist eine Frage des Service und nicht eine der Maximierung von Speicher- und Plattenkapazitäten.
Falle 4: Die Konzentration liegt nur auf periodischen Auswertungen und Ad-hoc-Datamining.
Es ist eine subtile Unterscheidung, aber eine mit gravierenden Auswirkungen: Manchmal zeigt ein intelligentes Frühwarnsystem auf der Basis eines Data-Warehouse mehr Effekt und meßbare Ergebnisse als der perfekt durchgestylte Aufbau eines Reportingsystems auf der Grundlage alter Abfragegewohnheiten.
Falle 5: Manager und Executives werden in dem Glauben gelassen, daß sie durch ein Data- Warehouse bessere Entscheidungen treffen. Oder: der beste Weg einen Sponsor zu verlieren.
Die Zielsetzung von Data- Warehousing klingt wie die des 4GL-Booms der siebziger Jahre und auch die der EIS-Welle in den späten Achtzigern: den Endanwendern besseren Zugang zu den Unternehmensdaten zu ermöglichen. Die Programmiersprachen der vierten Generation haben lange überlebt, die EIS stiegen sehr schnell auf, waren aber genauso schnell wieder vom Markt verschwunden. Warum? Ein Erklärungsansatz könnte sein, daß der bessere Zugriff auf die Daten in der Verkaufs- und Marketing-Argumentation populistisch den gestandenen Managern und Executives bessere Entscheidungen prognostizierte. Und wer will sich das schon gerne sagen lassen?
Falle 6: Erwartungshaltungen aufbauen, die sich nicht einhalten lassen.
Data-Warehouse-Projekte durchlaufen meist zwei Phasen: In der Verkaufsphase wird dem Benutzer vor Augen geführt, wie sich mit einfachen grafischen Tools in Sekundenschnelle auf die gewünschten Daten zugreifen läßt. Im darauffolgenden Stadium wird die Planung ausgeführt.