Teil 3/3: Vom klassischen Reporting zur Governed Self-Service BI-Plattform

Über Chancen und Herausforderungen bei der Modernisierung einer BI-Plattform

In Teil 2 wurde beschrieben, wie aus Anforderungen eine BI-Lösung werden kann und wie eine Ressourcenplanung mit schwankenden Verfügbarkeiten funktionieren kann.

In diesem (letzten) Teil wird ein konkretes Vorgehensmodell aufgezeigt, mit dem schrittweise ein Governed Self-Service BI-System implementiert werden kann.

Schritt für Schritt zum Governed Self-Service BI-System: das ORDIX-Vorgehensmodell

In diesem Abschnitt wird es konkret. Anhand des ORDIX-Vorgehensmodells soll aufgezeigt werden, wie der Umstieg von einer klassischen Reporting-Infrastruktur zu einer modernen Governed Self-Service BI-Struktur gelingen kann. 

Ein Ziel ohne Plan ist nur ein Wunsch

Ohne Projektplan geht es nicht. Auch unter den bereits genannten Rahmenbedingungen nicht. „Ein Plan, der nicht geändert werden kann, ist schlecht.“, sagte einst ein römischer Dichter. Was im Römischen Reich schon galt, gilt im Kontext der Entwicklung einer klassischen Reporting-Plattform hin zu einer modernen Governed Self-Service BI-Plattform ohne Abstriche auch. Es bedarf eines Projektplans, der auf verändernde äußere Umstände flexibel reagieren kann und gleichwohl einen kontinuierlichen Projektfortschritt sicherstellt.

Um solch einen Projektplan zu entwickeln, müssen folgende sechs Schritte durchlaufen werden:

Schritt 1: Wer braucht was?

Eine detaillierte Analyse der Anforderungen des Projekts ist unerlässlich, um festzustellen, welche Ressourcen benötigt werden und welche Meilensteine definiert werden sollen.

Schritt 2: Wer mit wem?

Ermittlung der verfügbaren Ressourcen, die für das Projekt benötigt werden. 

Schritt 3: Wer kann wann?

Verfügbare Ressourcen stehen möglicherweise nicht konstant zur Verfügung. Schwankungen können beispielsweise aufgrund von Krankheiten, Urlauben oder projektexternen Tätigkeiten entstehen. 

Schritt 4: Der Weg ist das Ziel!

Ein Zeitplan, der die Anforderungen des Projekts und die verfügbaren Ressourcen sowie Zeitpuffer berücksichtigt, hilft dabei, Kapazitätsschwankungen und sich verändernde Anforderungen zu managen. 

Schritt 5: Agiles Projektmanagement als Erfolgsfaktor!

Ein Projekt mit schwankenden Kapazitäten und wechselnden Anforderungen erfordert Flexibilität in der Planung, um auf Veränderungen des Projekts reagieren zu können. Es ist daher empfehlenswert, auf eine agile Projektmanagementmethode zu setzen. 

Schritt 6: Kommunikationsstrukturen festlegen!

Die Kommunikation mit allen Beteiligten des Projekts ist entscheidend, um sicherzustellen, dass alle auf dem gleichen Stand sind und Änderungen oder Herausforderungen frühzeitig erkannt werden. Es ist empfehlenswert, hier feste Meetingstrukturen festzulegen. Das Vorgehen nach SCRUM hat sich dabei schon oft bewährt. 

Agiles Projektmanagement nach ORDIX Best Practice

Es wurde ein iteratives Vorgehensmodell angewendet, in welchem nach der Anforderungsanalyse und dem Entstehen erster Use Cases sehr zeitnah in die Implementierung eines ersten Prototyps übergegangen werden konnte. Inkremente, die innerhalb der Reviews den Stakeholdern präsentiert wurden, waren nicht zwangsläufig nach jedem Sprint vorgesehen. So wurden fachliche Reviews oftmals gesondert angekündigt und die Beteiligten nur bei Bedarf dazu eingeladen. 

Ziel dieses Vorgehens war es, schnell und dauerhaft einen Zustand zu erreichen, in dem nicht zwangsläufig in einem festen zeitlichen Intervall, aber insgesamt kontinuierlich, Arbeitsergebnisse produziert wurden. Es sollte zudem sichergestellt werden, dass Fachabteilungen frühzeitig Feedback und damit Einfluss auf die Entwicklung nehmen konnten und auch diese in den beschriebenen kontinuierlichen Prozess involviert werden.

Im Projekt ORDIX Reporting 2.0 wurde sich für SCRUM als Projektmanagementmethode nach einem ORDIX Best Practice-Ansatz entschieden. Im Unterschied zum SCRUM Framework wurde auf die Verwendung von Story Points verzichtet und Aufwände in Stunden geschätzt. In Sprint Reviews waren Stakeholder nur dann involviert, wenn Inkremente fertiggestellt wurden, die konkrete Ergebnisse im BI Frontend als Gegenstand hatten. Das Entwicklerteam hatte bei Rückfragen zudem direkten Zugriff auf die Fachabteilungen, der SCRUM Master übernahm dies lediglich bei komplexeren und übergreifenden Themen.

Um die Kapazitätsschwankungen der eingesetzten Ressourcen bestmöglich berücksichtigen zu können, wurde die Länge der Sprints auf eine Woche festgelegt, um auch kleinen Fortschritt der Inkremente schnell sichtbar zu machen, aber auch um früh feststellen zu können, wenn es bei Inkrementen zu keinem oder zu geringem Fortschritt kommt. Use Cases wurden im Product Backlog abgelegt, die spezifischere Aufteilung in einzelne Tasks erfolgte innerhalb der Sprint Plannings und wurde im Sprint Backlog abgelegt. Neue Use Cases wurden dann in einen Sprint aufgenommen, wenn Kapazitäten frei wurden. Die Priorisierung wurde von den Product Ownern definiert. Das Entwicklerteam tauschte sich täglich für maximal 15 Minuten in einem Daily aus. Es wurde Wert daraufgelegt, dass an diesem Meeting möglichst jeder teilnimmt, auch wenn er keinen Arbeitsfortschritt zu präsentieren hatte. Entsprechend wurde bei der Terminfindung darauf geachtet, eine für alle möglichst günstige Zeit zu finden.

Zum Ende eines jeden Sprints wurden die Arbeitsergebnisse im Sprint Review präsentiert. Stakeholder und Product Owner nahmen auf Einladung dann teil, wenn der Fortschritt für sie relevant war. Je nach Umfang und Kapazitäten wurde das fachliche Review auch in gesonderte Termine ausgelagert. In der Retro sprach das Entwicklerteam, auch zusammen mit Product Ownern und Stakeholdern darüber, was im vergangenen Sprint gut funktioniert hat und wo man etwas verbessern könnte.

Insgesamt wurde sehr großer Wert darauf gelegt, die SCRUM Events zeitlich kompakt zu halten, damit diese zum einen nicht die Entwicklungsarbeiten ausbremsen und sich zum anderen mit den projektexternen Tätigkeiten der beteiligten Ressourcen in Einklang bringen lassen. Durch dieses Vorgehen wurde eine hohe Akzeptanz und damit verbunden eine hohe Teilnehmerquote der jeweiligen Meetings erreicht.

SCRUM-Events nach ORDIX

Um den beschriebenen Prozess starten zu können, bedarf es zunächst der Definition, Festlegung und Priorisierung von Use Cases. Ein Use Case ist wiederum einer oder mehreren Fachabteilungen zugeordnet und benötigt eine oder mehrere Datenquellen.

Welcher Use Case Priorität hat und demnach auch, mit welchen Fachabteilungen erste Use Cases spezifiziert werden, lag im Projekt ORDIX Reporting 2.0 in der Verantwortung der Product Owner. Diese legten auch die verantwortlichen Stakeholder fest und benannten bei Bedarf weitere technische und fachliche Know-how-Träger.

War der Use Case spezifiziert, kam er über das Product Backlog in einen Sprint, mit dem Ziel, schnell einen ersten Prototyp bzw. ein Inkrement zu entwickeln. Ansprechpartner bei fachlichen Fragen waren für das Entwicklerteam stets die definierten Stakeholder. Der SCRUM Master hatte hierbei lediglich eine unterstützende und koordinierende Rolle und war nur bei komplexen und fachlich übergreifenden Themen involviert. 

Regelmäßig wurden Arbeitsergebnisse den Stakeholdern präsentiert und Feedback in den nächsten Sprint übernommen. Sobald ein Inkrement einen Zustand erreicht hatte, in dem es von den Stakeholdern freigegeben werden konnte, wurde es zur finalen Abnahme an die Product Owner übergeben. Dies war die letzte Instanz, in der Änderungswünsche an das Entwicklerteam adressiert werden konnten, ehe das Inkrement in einer ersten Version für den Roll-out freigegeben wurde. 

Fazit: BI-Projekte sind eigentlich keine Projekte – es Bedarf eines dauerhaften Invests

Der Definition nach ist ein Projekt ein einmaliges Vorhaben mit einem bestimmten Ziel, welches einen Beginn und ein Ende aufweist. Ein Governed Self-Service BI-Projekt im eigentlichen Sinne ist hingegen nie zu Ende. Zwar haben einzelne Komponenten des Projektes ein Ende, wie beispielsweise die Einführung einer neuen BI-Software oder die Anbindung von bestimmten Datenquellen. Mit steigender Anwendung des BI-Tools entstehen jedoch regelmäßig weitere Anforderungen, die der Umsetzung bedürfen.

Es ist am Ende eine Frage der Abgrenzung, ob man hierbei noch von einem Projekt spricht oder ob Betrieb nicht die passendere Bezeichnung ist. Unstrittig ist: So wie ein Unternehmen sich stets weiterentwickelt und verändert, sollte es auch die BI-Landschaft tun. Es ist ratsam sich von dem Gedanken zu lösen, dass es sich bei einem BI-Projekt um ein klassisches IT-Projekt handelt, das aus unterschiedlichen Motiven einfach umgesetzt werden muss.

Losgelöst von Branche und unabhängig davon, ob Kleinunternehmen, Mittelständler oder Konzern: Ein BI-System braucht, jedes Unternehmen, um seine Geschäfte effektiv steuern und langfristigen Erfolg sicherstellen zu können. Ein BI-Projekt ist daher grundsätzlich weniger als Investment in die IT, sondern vielmehr als Investment in das ganze Unternehmen zu sehen. So wie man das Unternehmen kontinuierlich weiterentwickelt, so sollte man auch stets die eigene BI-Landschaft weiterentwickeln. Und so muss das auch jede gute BI-Beratung tun. Wieso sollte es dort auch anders sein?