Business Intelligence: Was Unternehmen wirklich brauchen

09.02.2007

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 (siehe auch "Turbulente Zeiten für Business Intelligence").

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." (siehe auch "BI ist nicht mehr Nabel der Welt")

Es geht nicht mehr ohne Data Warehouse

Berater Richard Graf: "Durch ein langsames Vorgehen kommt man schneller ans Ziel."

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. Richtig sei es, ein grundsätzliches Ziel (think big) zu haben, das dann schrittweise und in Iterationen mit der Zeit an Kontur gewinnt.

Dies bedeutet nicht, dass ein Data-Warehouse-Projekt einem Blindflug gleichkommt (siehe Tabelle "In acht Schritten zur Lösung"). Anwender sollten nur zu Beginn des Projekts die Latte nicht zu hoch legen und, wie es immer noch geschieht, 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 einfach, schnell, konsequenter und oft auch nachhaltiger. Dadurch gelingt es häufiger, ein Enterprise Data Warehouse durchzusetzen und auch über die Abteilungen und unterschiedlichen Interessen hinweg zum Laufen zu bringen."

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.

Berater Alexander Jochum: "Projekte dürfen nicht länger als drei bis sechs Monate dauern."

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. Daher lasse sie eigenmächtige und isolierte Projekte in den Fachabteilungen, wie sie lange an der Tagesordnung waren, nicht mehr zu. Auch die gestiegene technische Komplexität von BI-Lösungen spreche 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. (siehe auch "BI-Software ist vielen zu komplex")

Durch ein schrittweises Vorgehen lernt der Anwender schon in einer frühen Phase des Projekts viel über seine Kunden- oder Produktionsdaten, besonders was deren Qualität betrifft, 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 hingegen, mit der die Datenstrukturen abgebildet werden, 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. Als Faustregel lässt sich aber sagen, dass bei Neuprojekten mindestens 20 Prozent der Aufwendungen auf das Konzept entfallen, so Jochum.

Vom Grobkonzept zu den Details

Vorgehensmodell Business Intelligence

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.