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.

13.02.2007

Was Unternehmen wirklich brauchen

Die größten Stolpersteine für Anwender verbergen sich am Beginn von Business-Intelligence-Projekten. Ein umsichtiges und systematisches Vorgehen kann helfen. Die Zeit der Insellösungen ist vorbei.

Lösungen für Business Intelligence (BI) haben Konjunktur. Ursprünglich im Controlling zu Hause, sollen Anwendungen für Reporting und Analyse mittlerweile ebenso Vertrieb, Produktion oder Marketing mit aktuellen Zahlen zur Geschäftsentwicklung versorgen. Wo BI-Projekte ihren Ursprung haben, hängt stark von der Branche und den damit verbundenen Prozessen des Anwenders ab (Direktvertrieb, Logistik, Fertigung). Dabei ist in der letzten Zeit zu beobachten, dass der Mittelstand (Unternehmen mit maximal 3000 Mitarbeitern) BI-Projekte gezielter angeht als bisher, berichtet Richard Graf, Vorstand des Beratungshauses Simplefact in Nürnberg. Trotzdem bleiben immer noch viele Projekte hinter ihren Zielen zurück oder scheitern rundheraus.

BI-Aussteller auf der CeBIT

Neben einigen Herstellern und Beratungshäusern, die schon früh im Mittelstand unterwegs waren, haben mittlerweile auch Marktgrößen wie SAS Institute Mittelstandsstrategien. Die meisten von ihnen finden Sie auf dem Messe-Forum "Business Intelligence und Enterprise Information Integration" in Halle 3, Stand C45:

Applix: Halle 3, Stand C45;

Arcplan Information Services: Halle 3, Stand 45;

Board M.I.T.: Halle 3, Stand C45;

Business Objects: Halle 3, Stand C45;

Cognos: Halle 3, Stand D51;

CSB-System AG: Halle 5, Stand D16;

Cubeware: Halle 3, Stand D44;

Hapec: Halle 3, Stand D51;

Hyperion Solutions: Halle 3, Stand C45;

Infor Global Solutions: Halle 5, C24;

Informatica: Halle 3, Stand C45 und Stand D43;

ISR Information Products AG: Halle 1, Stand A68;

Microsoft Deutschland: Halle 3, Stand C45;

Microstrategy: Halle 3, Stand 45;

MIK: Halle 3, Stand C45;

Qliktech; Halle 3, Stand C45;

Sage Software: Halle 5, Stand B04;

SAS Institute: Halle 3, Stand C45;

SoftM: Halle 3, Stand C26;

SPSS: Halle 3, Stand D56;

Winterheller Software: Halle 3, Stand D58.

Best Practices

• BI-Projekte werden mehr durch die Branche und Prozesse (zum Beispiel Fertigungstiefe) eines Unternehmens bestimmt als durch dessen Größe;

• ...brauchen die Beteiligung von IT und Fachbereich;

• ... dürfen sich nicht nur mit Berichten beschäftigen, sondern müssen immer die Architektur und das Daten-Management berücksichtigen;

• ... dürfen nicht durch die Produkte eines Herstellers gesteuert werden;

• ... sind keine klassischen IT-Projekte nach dem Wasserfallmodell, sondern werden phasenweise und iterativ umgesetzt;

• ... sollten mit einem Grobkonzept für ein Data Warehouse beginnen und nicht mit endlosen Detailanforderungen, die schnell veralten;

• Pflichtenheft, Meilensteine, Abnahmen und phasenweises Testen sind ein Muss.

Schlechte Vorbereitung

Die Ursache hierfür liegt häufig in der schlechten Vorbereitung und Umsetzung des Projekts. Anwender beschäftigen sich zu oft mit der geplanten Berichtsdarstellung, statt sich um die Architektur und das Daten-Management der Lösung zu kümmern. Sie sollten dringlichst vermeiden, sich von einem BI-Hersteller ein Produkt vorgeben zu lassen und sich an dieses anzupassen, warnt Graf. Dies betreffe auch Software von ERP-Spezialisten, die mittlerweile BI-Funktionen in "ihrem Bauch" tragen, aber eigentlich nur Sinn geben, wenn ein Kunde praktisch sämtliche Unternehmensdaten nur über diese Umgebung verwaltet. "Es gibt kein operatives System, das alle BI-Anforderungen abdecken kann."

Stattdessen rät Graf aus Erfahrung auch Mittelständlern zu einem separaten Data Warehouse mit konsolidierten Daten als Basis für Analyse- und Reporting-Tools. Dessen Aufbau sei ein iteratives evolutionäres Vorgehen, das wenig mit klassischen IT-Projekten nach dem Wasserfallmodell gemein habe. Typisch sei vielmehr, dass es zu Beginn des Vorhabens zwar Vorgaben von Anwendern vorlägen (Fachkonzept), viele Einzelheiten und Anforderungen sich aber erst im Verlauf des Projekts ergäben beziehungsweise lösen ließen. Es sei der größte Unsinn, zu empfehlen, vorab alle Ziele bis ins Detail festzuklopfen, weil diese oft gar nicht bekannt sein könnten oder im Projektverlauf überholt würden, warnt Graf.

Dies bedeutet nicht, dass ein Data-Warehouse-Projekt einem Blindflug gleichkommt. Anwender sollten nur nicht zu Beginn des Projekts monatelang an der Beschreibung umfänglicher Datenmodelle und Anforderungen an die BI-Umgebung arbeiten, die dann oft aufgrund neuer Anforderungen oder Erkenntnisse ohnehin hinfällig sind. Dies gilt sowohl für große Unternehmen als auch im Mittelstand. Allerdings sei die Gefahr endloser Projekte im Mittelstand geringer: "Die Geschäftsführung versteht die Prozesse und den "Sinn" und entscheidet schnell, konsequenter und oft auch nachhaltiger. Dadurch gelingt es häufiger, ein Enterprise Data Warehouse durchzusetzen, auch über die Abteilungen und unterschiedlichen Interessen hinweg."

Suche nach den Kennzahlen

Im Einzelnen unterziehen Anwender ihre Daten vor der Implementierung einer Ist-Analyse und bilden das Data-Warehouse-Modell in einem "Proof of Concept" samt Architektur ab. Dabei sollten zunächst nur wenige, aber für den Anwender wesentliche Kennzahlen berücksichtigt werden. Letztere zu bestimmen ist nicht immer einfach, räumt Graf ein, zumal Anwender oft selbst nicht wissen, was sie brauchen, oder Kennzahlen unterschiedlich gewichten und definieren. Hilfreich sei es daher, bei der Auswahl der Metriken immer zu fragen: Was ist mein Kerngeschäft, und wie bekomme ich den höchsten Nutzen aus meinen Daten heraus (Investitionsschutz)? Nicht zu vergessen sind zudem gesetzliche Vorgaben zur Datenspeicherung und -schutz.

Einen vergleichbaren Ansatz bewirbt Alexander Jochum, Berater bei Data Mart Consulting in Neu-Isenburg. Er empfiehlt Unternehmen, Reporting und Analysesysteme als "architected data marts" aufzubauen, deren gemeinsame Basis ebenfalls ein Data Warehouse ist. Am Beginn müsse ein Workshop stehen, in dem alle Projektbeteiligten gemeinsam ein möglichst übergreifendes und langfristig angelegtes Grobkonzept ihres Data Warehouse entwerfen. Ziel ist es, festzuhalten, welche Anforderungen in den kommenden Jahren zu erwarten sind und wie und mit welchem Aufwand sich aus ihnen das Datenmodell ableiten lässt. "Man muss sich zumindest ansatzweise darüber im Klaren sein, wie später die Schnittstellen zu anderen Data Marts aussehen sollen, um beispielsweise einmal eine Vertriebslösung durch Daten aus der Kostendeckungsbeitragsrechnung ohne großen Aufwand erweitern zu können."

Insellösungen ohne Chance

Beide Praktiker sind sich einig, dass isolierte BI-Lösungen aus wirtschaftlichen Gründen heute nicht mehr entstehen dürfen: "Die Zeit der Fachbereichssysteme und Insellösungen ist vorbei", sagte Jochum. Die interne oder ausgelagerte IT sei mehr denn je gezwungen, Kosten über Service-Level-Agreements klar zuzuordnen und ihr Sammelsurium an BI-Produkten zu konsolidieren. Zudem spreche heute die gestiegene technische Komplexität von BI-Lösungen gegen Alleingänge: "Früher ließen sich BI-Systeme noch auf dem Client und mit kleiner Datenbank lokal installieren und managen, heute müssen mehrschichtige Architekturen aufgebaut und gewartet werden. Fachabteilungen seien daher mehr denn je auf die IT angewiesen, die ihrerseits auf eine Standardisierung der technischen Plattform dränge. Eine Vereinheitlichung auch der Endanwendern-Tools ist hingegen oft weder sinnvoll noch möglich, da verschiedene Anwendergruppen verschiedene Frontends benötigen. Die Nachteile mit Blick auf die gewünschte Konsolidierung des Portfolios halten sich aber in Grenzen, solange die Tools zur darunterliegenden Plattform passen.

Durch ein schrittweises Vorgehen lernt der Anwender schon früh im Projekt viel über die Qualität seiner Kunden- oder Produktionsdaten und kann dieses Wissen in die nächsten Iterationsschritte des Modells einbringen, erzählt Simplefact-Vorstand Graf: "Indem man langsam vorgeht, kommt man schneller ins Ziel." Hier liege der Schlüssel zum erfolgreichen BI-Projekt und zu schlanken Lösungen. Gelinge es, einen funktional fokussierten "Prototypen" aufzubauen, an dem man lernen und sich orientieren kann, steige die Erfolgswahrscheinlichkeit für das spätere Projekt auf 80 bis 90 Prozent. Die Technik zur Abbildung der Datenstrukturen sowie die Auswertungs-Tools seien nur Mittel zum Zweck und vergleichsweise leicht und beherrschbar. Wie viel Zeit Unternehmen mit dem "Scoping" verbringen müssen, hängt letztlich davon ab, wie gut sie ihre Anforderungen und Daten bereits kennen, ergänzt Jochum. Als Faustregel lasse sich aber sagen, dass bei Neuprojekten mindestens 20 Prozent der Aufwendungen auf das Konzept entfallen.

Vom Grobkonzept zu den Details

Geht es an die Umsetzung, so sind für jeden Iterationsschritt im Projekt klare Anforderungen zu definieren. "Das IT-Konzept muss aber abgesegnet sein, bevor die Implementierung beginnt", mahnt Graf. Jede Anpassung muss sich in Konzept und Umsetzung widerspiegeln. Letzteres allein schon deshalb, um Festpreise machen zu können. Die Projektphasen müssen eindeutig definiert und evolutionär sein. Dem stimmt Berater Jochum zu, bevorzugt aber in diesem Zusammenhang den Vergleich eines BI-Projekts mit einem Regelkreis: Man fängt mit Feinspezifikationen an, deren technische Details aber erst im Projekt geklärt beziehungsweise verifiziert werden und dann ihrerseits in die Vorgaben einfließen.

Das Endziel eines BI-Projekts darf während der einzelnen Projektphasen nie aus den Augen gelassen werden, warnt Berater Graf: "Es gibt klare Meilensteine: Proof-of-Concept, Fertigstellung der Version 0.9 und dann Abnahme der ersten Vollversion." Ebenso sei es zentral, im Vorgehensmodell die Kontrolle der Datenqualität und ein regelmäßiges Testen des Systems zu berücksichtigen sowie sich über Backup- und Recovery-Verfahren für das Data Warehouse und allgemein die Betriebssicherung Gedanken zu machen. Laut Graf sollte ein Data-Warehouse-Projekt nicht länger als sechs bis neun Monate dauern. Berater Jochum fordert sogar, dass eine Implementierung (Grobkonzept, Aufbau Data Mart) nie mehr als drei bis sechs Monate verschlingen darf, vorausgesetzt, es treten keine gravierenden Probleme während der Umsetzung auf.

Dennoch ist es in Großunternehmen weitaus schwieriger als im Mittelstand, ein übergreifendes "Enterprise Data Warehouse" zu gestalten, schränkt Berater Graf ein. Widersprüchliche Erwartungen, politische Gründe, Streit über die Datenhoheit und Budgets würden dies oft verhindern oder doch nur die kritisierten fach- oder aufgabenspezifischen Data Marts ermöglichen. Allerdings sei es auch im Mittelstand nicht immer einfach zu erklären, warum ein Data Warehouse in seinem Modell ein Stück weit über die konkreten Anforderungen hinausgehen soll (und so vielleicht mehr kostet). Um das richtige Maß zu finden, müsse man sich "auch einmal mit dem Geschäftsführer streiten und sich für das Wesentliche des Projekts einsetzen", fordert Graf. Wenn die Grundidee des Projekts hingegen aufgegeben werde, gebe es nur eine Antwort: Rücktritt, und dazu gehört Mut. "Meist sieht man sich immer zweimal im Leben."