Mit Business Intelligence (BI) hat sich seit Beginn der 90er Jahre ein Terminus durchgesetzt, der inhaltlich und nicht rein technologisch den Zweck von Informationssystemen beschreibt. Diese Sicht hilft, Projekte auf den richtigen Weg zu bringen, denn BI sollte vor allem Thema der Unternehmensführung und der Fachbereiche sein, während die IT lediglich eine beratende und ausführende Funktion ausübt. Vor der Einführung eines BI-Systems sind zunächst organisatorische Fragen zu klären, die auch Aspekte wie die Datenqualität und das Projekt-Management beziehungsweise den Informationsbedarf der unterschiedlichen Benutzerkreise abdecken. Danach kann eine adäquate Technologieauswahl beginnen.
Die Größe und die Organisationsstruktur eines Unternehmens haben erheblichen Einfluss auf die Architektur und somit das generelle Vorgehen in BI-Projekten. In großen, multinationalen Konzernen ist es mitunter sehr schwer, konzeptionell ein unternehmensweites Datenmodell zu erarbeiten. Unterschiedliche Interessen, bestehende Informationssysteme, Anforderungen von Fachabteilungen sowie internationale Tochtergesellschaften und Sparten müssten dazu vereinheitlicht werden - eine Herausforderung, die viele Projekte schon in der Konzeption scheitern lässt.
Lokale Lösungen, zentrales Modell
Selbst wenn diese erste Phase mit Hilfe zahlreicher Kompromisse überwunden wird, bergen eben diese die Gefahr des Scheiterns, weil die BI-Lösung nicht den Bedürfnissen der Benutzer entspricht. Um dieses Problem zu umgehen, sollte ein Data Warehouse modular aufgebaut sein, sprich: aus miteinander verbundenen (architected) Data Marts bestehen. Dies bedeutet, dass sukzessive einzelne, fach- oder spartenspezifische Datenhaltungen unter Berücksichtigung des unternehmensweiten Datenmodells aufgebaut werden, die physisch oder logisch jedoch auf dem zentralen Data Warehouse basieren.
Dadurch erhält idealerweise jeder Benutzerkreis nur die auf seine Bedürfnisse zugeschnittenen Informationen als Data Mart. Dies hat auch den Vorteil, dass die Projektverantwortung und Sponsorenfrage einfacher zu klären sind und die Investitionen durch die unmittelbare Nutzung der einzelnen Data Marts nach deren Fertigstellung überschaubar bleiben. Zudem kann nach jedem eingeführten Data Mart neuerlich über die Fortsetzung des Projekts entschieden werden.
Sonderbehandlung für den Mittelstand
Bei Unternehmen mit weniger ausgeprägten Organisationsformen etwa aus dem Mittelstand kann es hingegen sinnvoller sein, eine unternehmensweite "atomare" Datenbasis zu konzipieren und zu erstellen, aus der die benötigten Informationen generiert werden. Dies wird vor allem durch die kommenden Eigenkapitalrichtlinien Basel II für viele investitionsorientierte Firmen von großer Wichtigkeit sein, denn sie müssen neben "harten" Faktoren wie Kennzahlen, die aus Daten der Bilanz- und Gewinn-und-Verlust-Konten gewonnen werden, auch "weiche" Faktoren wie den Umfang und die Qualität der Unternehmensleistung bewerten. Die dazu benötigten Informationen stammen unter anderem aus analytischen CRM-Systemen und umfassen Wachstumsstrategie, Vertriebsstrategie, Markt und Wettbewerb, Management und Organisation sowie Controlling.
Garbage in - Garbage out
Selbstredend spielt die Datenqualität bei allen Anwendungen im Unternehmen eine wichtige Rolle. Untersuchungen haben jedoch ergeben, dass fünf bis 20 Prozent aller gespeicherten Daten in Unternehmen fehlerhaft oder nicht zu verwenden sind. Der Produktionsfaktor Information lässt sich daher nur eingeschränkt nutzen. Dieses Problem spitzt sich in dem Maße zu, wie immer mehr unterschiedliche Informationssysteme intern und extern miteinander verknüpft werden. Dementsprechend hängen auch der Erfolg und die Akzeptanz entscheidungsorientierter Informationssysteme im Sinne von Data Warehousing und BI stark von der syntaktischen und semantischen Korrektheit der ihnen zugrunde liegenden Quellsysteme ab.
Die Folge ist oft, dass im Vorfeld eines BI-Projekts der Startschuss für eine langwierige Qualitätsoffensive im Daten-Management fällt. Dabei handelt es sich jedoch um eine undankbare, manchmal gar unlösbare Aufgabe, da sie die abstrakte Vorwegnahme von späteren Folgefehlern im Data Warehouse erfordert. Diese liegen jedoch oft in den relevanten Datenbeständen und ihren Metadaten und werden erst im Data Warehouse selbst bei der Verarbeitung ebendieser Strukturinformationen sichtbar.
Die Datenbewirtschaftung sollte deshalb ins Data Warehouse verlegt werden, wobei die Transformation zu den gewünschten Informationen als Katalysator dient. Fehler müssen dann in den Ursprungssystemen korrigiert werden, wenn möglich mittels geschäftsprozessorientierter Plausibilitätsprüfungen. So entsteht eine Doppelprüfung, denn diese Kontrollen (Stichwort "Cleansing") sollten ebenfalls in den Datenbewirtschaftungsprozess, ob mit oder ohne ETL-Tools (ETL= Extraktion, Transformation und Laden) integriert sein. Dieser innerhalb des Projekts entstehende Aufwand muss allen Beteiligten bereits vor Projektbeginn ins Bewusstsein gerufen und eingeplant werden.
Eine Besonderheit von BI-Lösungen ist die Arbeit mit sensiblen Daten, was Fragen zum Datenschutz aufwirft, sowie der Umstand, dass solche Projekte unternehmenspolitisch hoch angesiedelt sind. Hier hat es sich als vorteilhaft erwiesen, zu Projektbeginn Scoping-Workshops zu veranstalten, in denen ein Grob- und Feinkonzept erarbeitet oder bereits bestehende Vorlagen geprüft werden. Dabei sollten das Projektziel und die Geschäftsprozesse definiert werden und eine Kosten-Nutzen-Analyse erfolgen. Ferner sind die Aufgaben klar zuzuordnen sowie Projektphasen und Meilensteine festzulegen. Zur Strukturierung hilft es auch, die gewünschten Berichte beziehungsweise Analysen und Auswertungen, die die BI-Lösung liefern soll, nach A, B und C zu gewichten.
Wichtig ist, dass an den Sitzungen maßgebliche Vertreter der jeweiligen Fachbereiche teilnehmen, so dass alle Beteiligten die Ergebnisse tragen und auch im Verlauf des Projekts als bindend erachten. Während der Umsetzung sollten sie stets Informationen über den aktuellen Stand der Dinge erhalten. Das können Kopien der Korrespondenz, Sitzungsprotokolle, Ressourcenzuordnungen und Zeitpläne, Berichte zu offenen Punkten und zum Projektstatus (zeitlich und monetär), Dokumentationen sowie die Präsentation der Meilenstein-Ergebnisse sein.
Fixpreise oder Prototypen
Grundsätzlich lassen sich bei BI-Projekten zwei Arten der Umsetzung unterscheiden: Festpreis, nach Zeit und Material (Vorgabe: Pflichtenheft) oder Prototyping. Festpreisprojekte bergen die Gefahr, dass Prozessänderungen oder die Sicherung der Datenqualität erhebliche Modifikationen erforderlich machen. Das reine Prototyping kann wiederum zum Fass ohne Boden werden. Geht man davon aus, dass Data Warehousing ein permanenter Unternehmensprozess ist, gilt das natürlich auch für die Zeit der Erstentwicklung. Es empfiehlt sich daher ein Mix, der sich aus den Projektzielen herleitet und sich - eventuell mit Prototyping - aus Festpreis sowie Zeit- und Materialkomponenten zusammensetzt.
Erst nach alledem sollte es an die Produktauswahl gehen. Allerdings kann auch eine unpassende Technik das ganze Unterfangen zum Scheitern bringen. Unternehmen sollten sich vor dem Neukauf auch die Produkte noch einmal anschauen, die sie bereits einsetzen und technische Glaubenskriege über die beste Datenbanktechnik vermeiden, da sie zu nichts führen. Maßgebend können allein die im Scoping-Workshop erarbeiteten und beschlossenen Anforderungen der unterschiedlichen Benutzerkreise sein. Ergab sich hier, dass 80 Prozent der Anwender Berichtsfunktionen mit eingeschränkten Analysefunktionen wie Drilldown oder Dimensionsrotation nutzen, ist es aus Kosten-Nutzen-Sicht wenig sinnvoll, diese Leute mit dem gleichen Analyse-Tool auszustatten wie die restlichen 20 Prozent, die weit reichende Analysefunktionen bis hin zum Data Mining benötigen. Das Gleiche gilt für die ermittelten Datenzugriffsprofile. Greifen 80 Prozent der Nutzer auf verdichtete Daten zu, kann dies für eine schnelle Molap- oder eine Hybrid-Lösung sprechen, die sich aus integrierter mehrdimensionaler und relationaler Datenhaltung zusammensetzt.
Tool-Auswahl wirft viele Fragen auf
Sollen hingegen Szenarien und Planungen innerhalb der bestehenden Strukturen möglich sein, bedarf es des Schreibzugriffs. Das im Workshop verabschiedete Anwenderkonzept muss in Verbindung mit Unternehmensportalen und Web-Lösungen realisierbar sein. Die definierten Update-Intervalle - oder mit anderen Worten das "Einfrieren" von bestimmten Daten im Data Warehouse, damit alle für eine definierte Zeit auf den gleichen Informationsbestand zugreifen - sollten genau in die vorhandenen Zeitfenster passen. Damit verbunden ist die Frage nach dem Einsatz eines ETL-Tools oder einer individuellen Lösung.
Hinsichtlich der Technik sind also viele Fragen zu klären: Gibt es Informationen, die in Echtzeit (Realtime oder Active Data Warehouse) hinzugespielt werden, und sind hierfür EAI-Technologien nötig? Sind die vorhandenen BI-Komponenten damit kompatibel? Sollen Closed-Loop-Komponenten wie zum Beispiel im Kampagnen-Management, betrieben werden? Wie sieht die Integration mit bereits eingeführten Komponenten aus? Die Fragen lassen sich beliebig weiterspinnen und sollen hier lediglich andeuten, wie komplex die Entscheidungsfindung sein kann. (as)
*Wolfgang Dähler ist Geschäftsführer der Data Mart Consulting GmbH in Hamburg.
Abb.1: Vielfalt der Datenbanken
Bei der Implementierung eines Data Warehouse muss vorab geklärt werden, welche Informationen benötigt werden und welche Auswertungen und Analysen geplant sind. Quelle: Datamart Consulting
Abb.2: Von den operativen Daten zu den Informationen
Für den Aufbau einer Business-Intelligence-Lösung stehen heute zahlreiche Techniken für die Integration, Speicherung, Auswertung, Verteilung und Darstellung der Daten bereit. Quelle: Datamart Consulting