Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

03.08.2006

BI-Konsolidierung: Strategie ist Pflicht

Ein guter Plan zum Wechsel der Analyse- und Berichtssoftware allein reicht nicht. Man muss sich auch daran halten.
Eine Strategie für Business Intelligence und Data Warehousing muss eine Reihe von Themen und Anforderungen abdecken. Die Praxis bleibt oft dahinter zurück.
Eine Strategie für Business Intelligence und Data Warehousing muss eine Reihe von Themen und Anforderungen abdecken. Die Praxis bleibt oft dahinter zurück.

Der Kostendruck in Unternehmen macht auch vor Systemen für Data Warehousing und Business Intelligence (BI) nicht Halt. Er zwingt die IT zur Konsolidierung. Das ist Wasser auf die Mühlen der Produktanbieter, die seit Jahren versuchen, sich als exklusive Lieferanten bei den Kunden zu etablieren.

Konsolidierung ist hochpolitisch

Diese Gründe erschweren es in der Praxis, zu einer Data-Warehouse- und BI-Strategie zu kommen:

• Befindlichkeiten der Beteiligten: Die Analysephase deckt frühere Fehler auf; die Konsolidierung reduziert die Anzahl der Werkzeuge; neue Software entwertet bestehendes Know-how; Arbeitsplätze sind gefährdet; Arbeitsverträge und Vereinbarungen passen nicht mehr.

• Irritationen und Unsicherheiten: Die Definition der Ziele ist komplex; IT und Fachbereich scheuen die Verantwortung; eine fertig gekaufte Lösung verleitet zum Verzicht auf eigenes Denken; Berater bevorzugen bestimmte Hersteller, auch wenn deren Produkte nicht optimal zum Kunden passen.

• Machtkämpfe um die Daten: IT und Fachbereich verstehen einander nicht, weil sie zu weit entfernt sind; der Datenbesitzer torpediert die Konsolidierung oder lenkt sie nach seinen Interessen.

Leitsätze für den Warehouse-Aufbau

• grob starten;

• stufenweise verfeinern (Investitionsstrategie mindestens auf fünf Jahre planen);

• früh ein "Big Picture" der Systemarchitektur entwerfen (mit Machbarkeitsbetrachtung);

• die Architektur detailliert und für alle Beteiligten verbindlich beschreiben;

• ständig die Qualität sichern.

Mehr zum Thema

www.computerwoche.de/

572388: BI-Strategie und Competence Center;

557809: Personalaufwand in BI-Projekten;

557518: Datenqualität;

570255: Kostendruck im ITK-Markt

Tatsächlich finden sich in Unternehmen in der Regel eine Reihe von Insellösungen für Reporting und Analyse, die über die Jahre mit Hilfe diverser Tools entstanden. Häufige Argumente, die für eine Konsolidierung dieses Sammelsuriums sprechen, sind hohe Lizenz- und Wartungsgebühren, die mangelnde technische Skalierbarkeit der Lösung, zu viele Schnittstellen sowie der Wunsch, flexibler auf neue geschäftliche Anforderungen reagieren zu können. Eine Konsolidierung muss aber nicht unbedingt auf eine Migration hinauslaufen, sondern kann auch bedeuten, zusätzliche Produkte einzuführen, um weniger abhängig von einem einzigen Anbieter zu werden, erklärt Richard Graf, Vorstand des BI-Systemhauses Simple Fact aus Neumark in der Oberpfalz.

Eine Konsolidierung schafft viele Risiken und Probleme. Beispielsweise müssen Anwender Umstellungskosten zwischen 50000 und 300000 Euro einkalkulieren - so zumindest die Erfahrungen bei Simple Fact. Die Ausgaben fließen in Konzeption, Aufnahme des Ist- Zustands, Migrationskonzept und Zielarchitektur. Die Projektlaufzeiten dauern zwischen sechs Wochen und drei Monaten. "Manche Kunden lassen sich aber auch ein halbes Jahr Zeit", schildert Graf seine Erfahrungen. Eine weitere, nur allzu vertraute Erkenntnis jedes Projektverantwortlichen sei, "dass eine Konsolidierung immer auch bedeutet, jemanden etwas wegzunehmen oder ihn überflüssig zu machen". Dies sorgt für viel politischen Sprengstoff.

Trial and Error kostet nur

Unternehmen brauchen daher eine klare und kommunizierte Strategie zur Konsolidierung ihrer BI- und Data-Warehouse-Landschaft. Von Ansätzen, ein Data-Warehouse-System per "Trial-and-Error" abzulösen, ist dringend abzuraten. Unzureichende Planung führt in der Praxis nur dazu, dass nachträglich Änderungen der Strategie oder Systemarchitektur nötig werden, die laut Graf immense Kosten verursachen. Ein Strategiewechsel beim Data Warehousing vermag Unternehmen zwei bis drei Jahre zurückzuwerfen, "was in manchen Branchen unternehmenskritisch sein kann", so der BI-Experte.

Reichlich Erfahrung gesammelt

Die gute Nachricht ist, dass Unternehmen mittlerweile viel Wissen rund um den Aufbau solcher Systeme gesammelt haben. Das kommt ihnen bei der Migration und Implementierung zugute. Auch können sie auf zahlreiche "Best Practices" zurückgreifen, mit denen Dienstleister und Hersteller werben. Allerdings lässt sich nicht alles, was hier angeboten wird, auch umsetzen. Simple-Fact-Vorstand Graf rechnet vor: Nur 75 Prozent der definierten Ziele, die das Unternehmen mit der Konsolidierung verfolgt, werden in den tatsächlichen Projektauftrag übernommen.

Zudem ist es üblich, Zusatzaufgaben im Projekt unterzubringen, die "man schon länger machen wollte". Dadurch ändert sich jedoch der Fokus, und plötzlich beziehen sich nur noch 50 Prozent der Vorgaben auf das ursprüngliche Ziel. Zudem wird typischerweise das gemacht, was die Abteilungen am besten beherrschen (Kompetenzkonserve), was nicht unbedingt mit dem Projektauftrag übereinstimmen muss. Hinzu gesellen sich Probleme mit der Datenqualität, der mangelnden Erweiterbarkeit des Systems sowie eventuell einer schlechten Produktauswahl.

Am Ende meist Best of Breed

Zum Beispiel erscheint es attraktiv, von einem Hersteller gleich eine komplette BI-Suite zu erwerben. Doch nach dem heutigen Reifegrad können diese Produkte nicht immer die hohen Erwartungen erfüllen, warnt Graf. In der Praxis kommt daher am Ende eine Best-of-Breed-Lösung heraus.

Die Konsolidierungsstrategie sollte klar ausgearbeitete Verfahren und Richtlinien enthalten, die die Ziele und die angestrebte Systemarchitektur definieren. Zudem muss sie allen Beteiligten vermittelt werden: "Es reicht nicht, wenn der Chefarchitekt alles im Kopf hat, sondern sämtliche Beteiligten brauchen eine Dokumentation mit klaren und nachvollziehbaren Aussagen."

Zentral für alle einsehbar

Ein dokumentierter und abgenommener Ergebnisstand samt Versions-Management ist zwingend notwendig, um im Projekt die richtigen Entscheidungen zu treffen. Dabei kann es auch nötig werden, während der Arbeiten noch Details einzubringen. Alle Ergebnisse müssen an zentraler Stelle strukturiert vorliegen und alle Beteiligten diese je nach Berechtigung einsehen können.

Wichtig bei der Konsolidierung einer Data-Warehouse-Umgebung ist es, einen breiten Fokus mit Blick "unter die Haube" zu wählen, also eine gleichrangige Betrachtung von Datenhaltungen, Daten-Management, BI-Frontends und BI-Anwendungen. Knackpunkte sind erfahrungsgemäß das Metadaten-Management und die Datenqualität. Letztere lässt sich schon mit einfachen Instrumenten verbessern: durch ein Profiling von Datenbeständen und Datenlieferungen, ein klares Schichtenmodell der Datenhaltung sowie ein auch fachlich administrierbares Prüf- und Plausibilitätsregelwerk, mit dem sich Auffälligkeiten als Bericht zusammenfassen lassen.

Fingerspitzengefühl gefragt

Viel Fingerspitzengefühl und Durchsetzungskraft erfordert die "politische Großwetterlage", in der sich das Projekt entwickelt (siehe Kasten "Konsolidierung ist hochpolitisch"). "Es muss Leute geben, die mit Mut, Offenheit und Klarheit das Vorhaben voranbringen können", weiß Graf. Wie in anderen IT-Initiativen, so kommt auch in Data-Warehouse- und BI-Projekten der Widerstand gegen eine Konsolidierung aus der betroffenen Abteilung und von den Dienstleistern. Dazu Graf: "Wer die Daten hat, hat die Macht und steuert damit die Kosten - vor allem wenn nicht nur der Betrieb, sondern auch die Entwicklung ausgelagert ist."

Doch Führungskräfte in der IT scheuen sich heute oft vor der Verantwortung und der Konfrontation. Dies sei verständlich, räumt Graf ein. Schließlich stehen viele von ihnen seit Jahren unter Druck und gelten als reiner Kostenverursacher.

Lieber selber denken

Es liegt am Management, hier ein anderes Betriebsklima zu schaffen, soll das Geschäft künftig noch funktionieren. Keinen Ausweg sieht der Simple-Fact-Vorstand darin, die Verantwortung an den Hersteller zu delegieren, statt eigene Kompetenz zu schaffen: "Das System muss sich an den Geschäftsprozessen und der Einzigartigkeit des Unternehmens ausrichten und nicht umgekehrt." Genauso wenig solle man das Denken den Beratern überlassen, weil sie die Projekte ihrer Kunden oft nach den eigenen Herstellervorlieben gestalten.