Projektmethodik: Erfolgsfaktor agile Business Intelligence Entwicklung

Mit großem Elan und Eifer starten wir jedes Mal aufs Neue in Projekte. Wir nehmen uns vor, alles besser zu machen als in der Vergangenheit, die „alten Zöpfe“ abzuschneiden und aus den Erfahrungen zu lernen.

Die Herausforderung ist jedoch, nicht nur in technischer und fachlicher Hinsicht besser zu werden, sondern auch die Methodik und Vorgehensweise ständig weiterzuentwickeln und die Unzulänglichkeiten vergangener Projekte zu eliminieren. Oft stellen wir dann fest, dass es gerade der Kernprozess der klassischen IT-Projektmethodik (Wasserfall) ist, der die eigentlichen Probleme verursacht. Gefangen in der Abfolge von Analyse – Design – Implementierung – Test – Go-Live sind wir gezwungen dem Kunden bereits zu Beginn des Projektes sehr detaillierte Anforderungen abzuverlangen, wohlwissend, dass die Fachbereiche dazu kaum in der Lage sein können. Diese Anforderungen werden sich über den Verlauf des Projektes ändern. Sei es, weil neue Erkenntnisse, die im Verlauf des Projektes gewonnen werden, den ursprünglichen Satz an Anforderungen verändern, oder sei es, weil sie in dem sich ändernden globalisierten Geschäftsumfeld einen neuen Stellenwert bekommen. Bestehende Vorgaben verändern ihre Priorität oder entfallen ganz, neue kommen hinzu. Und gerade weil wir das wissen, etablieren wir bereits zu Beginn des Projektes einen Change Management-Prozess. Noch keine einzige Anforderung ist aufgenommen und detailliert, aber der Prozess diese zu ändern steht bereits! In der Folgephase werden Anforderungen in ein IT-Design gegossen, ETL-Strecken, Datenmodelle, Cubes und Reports werden entwickelt. Zwischendurch wird auch immer wieder eine Anforderungsänderung aus dem Change Management-Verfahren eingearbeitet. Die Chance umfangreichere oder komplexere Änderungen einzuarbeiten nimmt im Verlauf der Entwicklung schnell ab, da bereits große Teile der Entwicklung abgeschlossen sind und die festgelegte zeitliche Planung keinen weiteren Raum bietet.

Ab einem bestimmten Punkt im Projekt werden Änderungswünsche des Kunden nicht mehr realisiert, sondern gehen gesammelt in eine „Phase 2“ ein, die dann im Nachgang zum derzeitigen Projekt implementiert werden soll. Vom Projektstart bis zum GoLive vergehen oft sechs Monate, ein Jahr oder noch mehr Zeit. Zum GoLive nimmt der Kunde das Projekt ab und die Anwender haben zum ersten Mal die Möglichkeit mit dem neuen System vollumfänglich zu arbeiten. Und obwohl der Großteil aller IT Projekte als erfolgreich abgeschlossen gefeiert wird, nimmt die Akzeptanz der Anwender oft dramatisch ab. Zu monolithisch, zu viele Funktionen, die man gar nicht braucht, zudem fehlen dringend benötigte Funktionalitäten. Das System ist zu komplex, durch Fachbereiche nicht bedienbar, zu unflexibel, neue Berichtsanforderungen können nicht durch die Fachbereiche abgebildet werden. So oder so ähnlich lauten die Urteile aus der Anwenderschaft.

Was definiert den Projekterfolg?

Das allgemeine Verständnis von Projekterfolg definiert sich, wie durch die Standish Group beschrieben, als: „The project is completed on-time and on-budget, with all features and functions as initially specified“[1]. Das mag so für Ingenieursleistungen oder Gewerke mit im Vorfeld fest zu definierendem Umfang und Funktion im Allgemeinen gelten. Aber: Ist ein IT Projekt und ein DWH /BI Projekt im Besonderen nicht ausschließlich dann erfolgreich, wenn der Kunde/Anwender über die genannten Punkte hinaus mit dem System zufrieden ist und in seiner Arbeit unterstützt wird? Als langjährige Experten für kundenindividuelle analytische Informationssysteme haben wir eine Reihe von Projekten realisieren dürfen. Die Erfahrungen zeigen uns, dass vor allem der Informationsbedarf volatil ist und ständigen Änderungen unterliegt, auch während eines laufenden Projektes. Zudem erzeugen Erkenntnisse, die man oft auch aus den Daten eines DWH gewinnt, auch oft neue Fragestellungen.

Ein DWH System ist demnach ein hochdynamisches System, dass sich den Anforderungen der Organisation anpassen und auftretende Informationsbedarfe schnell und zuverlässig decken muss. Allein aus diesem Grund wird der Ansatz ein Data Warehouse/BI System in einem groß angelegten Projekt fertigzustellen ad absurdum geführt. Vielmehr gilt es, den Aufbau eines unternehmensweiten Informationssystems in bedarfsorientierten Iterationen und in enger Abstimmung mit den Bedarfsträgern aufzubauen. Um diesem Umstand Rechnung zu tragen und darüber hinaus auch weitere Einschränkungen der klassischen Methoden auszuhebeln, haben wir Scrum, als den prominenten Vertreter der agilen Methoden, auf die Belange von DWH/BI Projekten angepasst und in ersten Kundenprojekten etabliert.

Scrum im BI Kontext

Scrum erkennt, wie alle agile Methoden, Änderungen in den Anforderungen nicht als etwas Unbequemes, das es zu „managen“ gilt, sondern als Chance, das Produkt (die Lösung) qualitativ zu verbessern und näher an die Fachbereiche und deren Anforderungen heranzubringen. Scrum nennt einzelne Anforderungen User Stories, die in einem Product Backlog zusammengefasst und nach Priorität (Business Value) absteigend sortiert werden. Verantwortlich für die Vollständigkeit und Priorisierung der Anforderungen ist der Product Owner aus dem Fachbereich. Anforderungen/User Stories werden – entsprechend der Priorisierung – iterativ in einem Sprint, der in der Regel drei bis vier Wochen dauert, realisiert und abschließend im Produktivsystem live gesetzt. Alle drei bis vier Wochen wird den Anwendern der Fachbereiche eine produktiv nutzbare Funktion/ein Bericht im operativen System zur Verfügung gestellt. Die Erfahrungen der Fachbereichsanwender können so als neue oder geänderte Anforderung in den nächsten Sprint einfließen – eine entsprechende Priorisierung durch den Product Owner vorausgesetzt. Durch die kontinuierliche Überwachung und Priorisierung des Product Backlog wird sichergestellt, dass ausschließlich Anforderungen mit hohem Businessnutzen realisiert werden, die berühmten „goldenen Klinken“ entfallen.

„Die Anforderungen an ein DWH/BI System verändern sich ständig. Immer schnellere Entwicklungszyklen werden notwendig, flexibel und agil auf neue Anforderungen, neue Technologien und neue Prozesse zu reagieren und den kontinuierlichen und qualitativ hochwertigen Fluss von Informationen im Unternehmen sicherzustellen.“

Ralf Hombach, Head of Business Unit Business Intelligence Solutions, cundus AG

Anpassung des Scrum-Prozesses

Den Besonderheiten eines DWH/BI Projektes wurde durch vorsichtige Anpassung des Scrum-Prozesses Rechnung getragen. In unserem Vorgehensmodell haben wir beispielsweise den Sprint 0 vorgeschaltet, eine Instanz, die es so im klassischen Scrum nicht gibt. Diese vorgeschaltete Phase wird genutzt, um die in BI-Projekten notwendige Grobanalyse der fachlichen Anforderungen, im Rahmen von kurzen moderierten Interviews, durchzuführen. Nach Abschluss der Interviews werden die dann vorliegenden groben, konsolidierten Anforderungen entsprechend unseres Konzepts zur Zerlegung der Anforderung (Requirement Decomposition) in die informatorischen und nicht-informatorischen Bestandteile eines konzeptionellen Datenmodells aufgeteilt.

Einen weiteren wichtigen Erfolgsfaktor stellt die agile Infrastruktur dar, die den agilen Entwicklungsprozess optimal unterstützt. In unserem Vorgehensmodell wird die direkte Entwicklungsarbeit auf virtuellen Maschinen durchgeführt, die auf lokalen Computern der Entwickler implementiert sind. Diese sind an ein zentralisiertes Quellcodeverwaltungssystem angeschlossen, um ein einheitliches Repository zu gewährleisten. Dieses Repository bildet die Grundlage für ein automatisiertes Deployment der Entwicklungsartefakte über alle Instanzen des Entwicklungsstranges (Entwicklungs-/Test-/Produktionsumgebung).

Agile Infrastruktur

Diese Art der Infrastruktur ist erforderlich, um in agilen Projekten folgende Anforderungen zu erfüllen:

• Unabhängiges Arbeiten einzelner Entwickler
• Leichtes Ausführen des gesamten Test- und Deploymentprozesses
• Fachanwendern bereits früh die Möglichkeit geben neue Features testen zu können
• Schneller Zugriff auf sowie Wiederherstellung von älteren Entwicklungsversionen und korrespondierenden Daten
• Fortlaufende Sicherstellung eines in sich validen DWH/BI-Systems
• Parallelisierung von Entwicklung und operativem Betrieb

Im speziellen müssen wir Herausforderungen meistern die sich im BI-Kontext ergeben und sie mit in die Architektur der Landschaft einfließen lassen. Diese sind:

• BI-Entwicklung unterscheidet sich sehr von der klassischen Softwareentwicklung
• Die Entwicklungsartefakte sind gröber im Vergleich zur klassischen Softwareentwicklung
• Diese Artefakte können nur mit erheblichem Aufwand zusammengeführt werden – wenn dies überhaupt möglich ist
• Wir haben direkte Abhängigkeiten zwischen den Entwicklungsartefakten, z.B. zwischen den ETL-Paketen / Cubes von den Datenbanken
• Die Unterstützung von Entwicklungswerkzeugen ist auf die klassische Softwareentwicklung hin optimiert

Wir haben in den Projekten, die wir seit 2009 mit Scrum realisiert haben (200 bis 2.500+ Manntage), ausschließlich positive Erfahrungen machen dürfen. Sowohl die Qualität der Lösung als auch die Akzeptanz der Systeme bei den Anwendern liegt um ein Vielfaches höher, als in vergleichbaren Projekten nach klassischen Methoden. Das priorisierte Bearbeiten der wichtigsten Kundenherausforderungen und regelmäßige GoLives tragen dazu bei, frühzeitig den Geschäftsnutzen zu heben und die Entwicklung überflüssiger Funktionalitäten zu vermeiden. Durch aktive Einbeziehung der Anwender, Implementierung eines kontinuierlichen Verbesserungsprozesses, unterstützt durch Reflektion am Sprintende und professioneller Testprozesse, können wir die bestmögliche Lösungsqualität erreichen und BI-Projekte erfolgreich umsetzen Dennoch ist ein BI-Projekt mit Scrum nicht automatisch erfolgreich. Dass es gilt, wichtige Rahmenbedingungen einzuhalten haben wir in einer Vielzahl anspruchsvoller Kundenprojekte über die Jahre praxisnah erfahren.

Neben der konsequenten Einhaltung des Prozesses zählt dazu auch die Verfügbarkeit eines versierten Scrum Masters sowie die fachliche Unterstützung durch einen Product Owner mit entsprechenden Entscheidungsbefugnissen. Essenziell ist auch die enge Zusammenarbeit mit den Teams für den technischen Betrieb und den fachlichen Support. Da bereits nach einem Sprint die ersten Ergebnisse in den Live Betrieb übergehen, sind der Support (Infrastruktur und Prozess) sowie der Betrieb der Live Umgebung sicherzustellen. Die unterstützende Infrastruktur muss möglichst frühzeitig bereitgestellt werden und die professionellen Deployment-, Build- und Testprozesse etabliert sein.

Die Anforderungen an ein DWH/BI System verändern sich ständig. Immer schnellere Entwicklungszyklen werden notwendig, um flexibel und agil auf neue Anforderungen, neue Technologien und neue Prozesse zu reagieren und den kontinuierlichen und qualitativ hochwertigen Fluss von Informationen im Unternehmen sicherzustellen. Um mit diesem Tempo Schritt halten zu können, bedarf es neuer Methoden, Ideen und Vorgehensmodelle. Agile Methoden, gepaart mit einer agilen Architektur und Modellierungsoptionen, die den schnellen Wechsel ebenso friktionsfrei unterstützen, sind schon heute ein Wettbewerbsvorteil für die Unternehmen, die diese einsetzen.

RALF HOMBACH
CLAAS PLANITZER

Diesen Artikel finden Sie auch in der it management Ausgabe 5 – 2013.