Erfolgsrezept für BI-Projekte

Adrian Heiniger ist Senior Solution Architect bei IT-Logix AG, Urs Grunder Senior Solution Architect und Partner. Die Investitionen für Data Warehousing (DWH) und Business Intelligence (BI) wachsen stark. Gemäss IBMs aktueller «2011 Global CIO Study» bezeichnen 83 Prozent der befragten CIOs die Einführung von BI und Business Analytics innerhalb der nächsten drei bis fünf Jahre als oberste Priorität, um die Wettbewerbsfähigkeit ihres Unternehmens zu verbessern. Auch die Fachabteilungen wollen sich künftig intensiver mit BI beschäf­tigen: Über 60 Prozent (IBM CFO Studie 2010) planen grös­sere Veränderungen, unter anderem im Hinblick auf die Geschäftsanalytik. Brisant ist in diesem Zusammenhang, dass viele BI-Projekte die gesetzten Ziele nicht erreichen. In der letzten Studie des britischen National Computer Centre gab eine Mehrheit (53%) der rund 100 befragten Unternehmen an, die Leistungsfähigkeit in Bezug auf die gesetzten Geschäftsziele sei höchstens durchschnitt­lich. Nur gerade 6 Prozent sehen ihre Ziele als «sehr gut» abgedeckt (www.futureofenterprise computing.com/2011/06/data-warehouse-and-bi-projects-fail-to-meet-companies-require ments). Die Gründe dafür dürften in den Spezifika von BI- und DWH-Projekten sowie in den im Gegensatz zum klassischen Software Enginee­ring noch wenig etablierten Vorgehens- und Architekturstandards zu finden sein.

Was die langjährige Projekterfahrung bezüglich der Eigenheiten von BI-Projekten lehrt, bringt Dr. Stephan König von der FH Hannover in einem Arbeitspapier auf den Punkt (http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-542/paper03.pdf). Demnach unterscheiden sich Projekte zur Entwicklung von BI-Anwendungen in drei wichtigen Punkten von der klassischen Anwendungsentwicklung: - Die abteilungsübergreifende Integration der Daten erfordert neben politischem Geschick insbesondere auch eine einheitliche Definition der fachlichen Begrifflichkeit und Metriken. - Die Anforderungsanalyse ist schwierig, da sich künftiges exploratives Anwenderverhalten nur schwer in vorab klar definierten Use Cases abbilden lässt. - Es handelt sich bei BI-Anwendungen um komplexe zentrale Systeme, die eng mit bestehenden operativen Systemen vernetzt sind und eine enge Zusammenarbeit zwischen der IT-Abteilung und den Fachabteilungen erfordern. Obwohl heute für DWH/BI-Projekte meist Standard-Software eingesetzt wird, sind inhaltlich in aller Regel Individuallösungen gefordert. Das daraus resultierende Spannungsfeld verlangt nach einer nachhaltigen Architekturdefinition. Ohne konsequente Orientierung an Normen und bewährten Praktiken, an fachlichen Standards aus dem DWH/BI-Umfeld, können solche Projekte viel Aufwand respektive Kosten generieren. Im schlechtesten Fall sind die resultierenden Lösungen kaum ausbau- und wartungsfähig.

Das Projekt-Framework von Ralph Kimball (www.kimballuniversity.com) hat sich dabei als praxis­orientierte Hilfe erwiesen. Das Lifecycle Toolkit ist ein umfassendes, technologieneutrales Mo­dell, das den ganzen Lebenszyklus eines DWH/BI-Systems abdeckt: angefangen bei der Programm-/Projektplanung über das Projekt­mana­gement, die Analyse der Geschäfts­anfor­derungen, die sehr umfassend dokumentierte Architektur sowie Design und Entwicklungsar­beiten bis zu Betrieb und Weiter­entwicklung. Die Erläuterungen sind dabei mit vielen Beispielen, Vorlagen und wertvollen Instrumenten angereichert. Das Framework orientiert sich an den Geschäftsanforderungen und widmet sich in ers­ter Linie der Nutzen-Realisierung. Im Bereich Projektplanung, Projektmanagement und Analyse der Geschäftsanforderungen gibt es gewisse Überschneidungen mit allgemein gültigen Projektvorgehensmodellen. Das Lifecycle Toolkit ist jedoch keinesfalls als Ersatz solcher Modelle zu verstehen, sondern als Ergänzung, die zusätzlich sehr detailliert auf die erwähnten zentralen DWH/BI-spezifischen Eigenheiten eines Projekts eingeht.

Viele Projekte befassen sich nur mit den Anforderungen einzelner Fachbereiche. So entstehen Informationssilos, die bereits mittelfristig den Nutzen stark einschränken. Das Lifecycle Toolkit legt den Fokus auf eine integrierte Lösung, die das Gesamtunternehmen unterstützt und Ana­lysen über Fachbereichs-, System- und Prozessgrenzen hinweg erlaubt. Dies ohne einen ite­rativen Ansatz für Systementwicklung und -ausbau auszuschliessen, was auch eine agile Entwicklung erlaubt. Das Framework unterstützt somit die Nachhaltigkeit des Erfolgs. Das zentrale Instrument ist die sogenannte «Enterprise Bus Mat­rix», die in der Anforderungs­­erhe­bungs­phase entsteht. Darin werden die Haupt­ge­schäfts­prozesse oder Geschäftsereig­nisse abgebildet, aus denen die Messgrössen (Fakten) entstehen, sowie die dazugehörigen, oft prozessübergrei­fenden Stammdaten (Dimensionen). An den Messgrössen, die in den Prozessen entstehen, sind meist mehrere Fachbereiche interessiert. Der Fokus soll also auf den Prozessen liegen und nicht auf den Fachbereichen. Das bedeutet, dass eine fachübergreifende Vereinheitlichung der Kenn­zahlen erforderlich ist. Die Enterprise Bus Matrix zeigt im Endeffekt das grosse Bild der angestrebten Lösung. Ein Prozess oder eine Prozessgruppe aus der Matrix ist geeignet, als Scope (Aufgabenbereich) eines einzelnen Projekts innerhalb des DWH/BI-Programms und als Grundlage für die dimen­sionale Modellierung zu dienen.

Um zukünftige Anwenderbedürfnisse bestmöglich abzudecken, muss darauf geachtet werden, dass die bestehenden Daten flexibel ausgewertet und die Lösungen in evolutionären Schritten weiterentwickelt werden können, ohne dabei die bestehende Funktionalität zu gefährden. Die Eckpfeiler einer solchen Lösung sind daher eine organisationsübergreifende Sicht, ein prozessorientierter Ansatz, ein vereinheitlichtes Kennzahlensystem sowie strikte dimensionale Modellierung mit übergreifend verwendbaren Dimensionen (Conformed Dimensions). Redundante Daten in verschiedenen Fachabteilungen werden eliminiert beziehungsweise von vornherein vermieden. Zudem werden Messgrössen der Prozesse (Fakten) in der höchstmöglichen Granularität ins Data Warehouse eingebracht. Möglicherweise ist dies im initialen Projekt gar nicht gefordert, aber so wird die Möglichkeit gewahrt, auch zukünftige Anforderungen an Auswertungen und Analysen mit einem höheren Detaillie­rungsgrad abzudecken. Da in BI-Projekten keine neuen Daten geschaffen, sondern nur solche aus operationellen Systemen für Auswertungszwecke umgeformt werden, kommt der Verifikation der Anforderungen gegenüber den Daten aus den beteiligten Systemen eine grosse Bedeutung zu. Es wird deshalb bereits bei der Analyse der Geschäftsanforderungen geprüft, ob die Verfügbarkeit und Verlässlichkeit der Quelldaten die Anforderungen abdecken können. Während es in allgemeinen Applikations­projekten eher untypisch ist, sich in einer so frühen Phase mit datentechnischen Details zu befassen, ist in einem DWH/BI-Projekt die frühe Prüfung kritisch für den Projekterfolg. Nicht selten wächst die Erkenntnis bezüglich fehlender oder qualitativ schlechter Datenbestände ohne diese frühe Datenanalyse erst während der Implementierung. Der Umgang mit Datenunzulänglichkeiten wird zu diesem fortgeschrittenen Zeitpunkt im Projekt dann enorm teuer.

Die Bedeutung der sehr engen Zusammen­arbeit zwischen Fachbereichen und IT wird im Lifecycle Toolkit immer wieder betont – und bei der Personalbesetzung (Staffing) innerhalb des Projektverlaufs auch entsprechend Rechnung getragen. Viele BI-Projekte werden mit einem zu breiten Scope geplant und wollen zu viel auf einmal liefern. Bei der Programm-/Projektplanung ist gemäss Kimball aus diesem Grund zu beachten, dass eine DWH/BI-Lösung unbedingt iterativ, also in mehreren Projektzyklen zu entwickeln ist. Damit kann rascher Nutzen reali­siert werden. Der Erfolg wird wahrscheinlicher, da mit diesem Vorgehen die Komplexität eines einzelnen, kleineren Projekts geringer und damit besser zu meistern ist. Dabei stellt der erste Zyklus eines solchen Programms eine spezielle Herausforderung dar. Er muss nebst erstem konkreten Nutzen für das Geschäft auch grundlegende Konzepte und Infrastruktur liefern. Man ist also gut beraten, gerade das erste DWH/BI-Projekt nicht mit Anforderungen zu überladen.

Kompetenz und Erfahrung sind unverzichtbar. Ein Framework mit Instrumenten, Vorlagen und bewährten Praktiken ist sehr wichtig. Um es aber auch richtig anwenden zu können, braucht es ausgebildete und erfahrene Fachkräfte. Ist das neben all den in diesem Artikel genannten Punkten zusätzlich noch gegeben, steht einem wirklich erfolgreichen Projekt nichts mehr im Wege.