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

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

Warum ein funktionierendes Business Intelligence-System für alle Unternehmen essenziell ist, wurde bereits in Teil 1 ausgeführt.

In diesem Teil geht es um die Aufnahme von Anforderungen und wie diese hin zu einer BI-Lösung entwickelt werden können. Es geht um Ressourcen, Verfügbarkeiten und wie diese in einer Projektplanung zu berücksichtigen sind.

„Ich brauche unbedingt einen Report, der mir zeigt …" von der Anforderung zur BI-Lösung

Wie kommt man von konkreten Anforderungen aus den Fachbereichen hin zu einem Selfservice BI-System? Es existieren zahlreiche Herangehensweisen und Methoden, die hierbei unterstützen können. Bei der ORDIX AG hat man sich für Use Cases, angelehnt an User Storys, bekannt aus dem SCRUM Framework, entschieden.

In einem Use Case werden konkrete fachliche Anforderung ohne technischen Kontext beschrieben. Dies kann z. B. sein: „Der Vertrieb möchte auswerten, wann ein Projektbudget aufgebraucht ist. Hierzu bedarf es unterschiedlicher Simulationsmöglichkeiten: Die Beraterinnen und Berater fakturieren zu 50, 75 oder 100 %. Geplante Urlaube sollen dabei ebenso berücksichtigt werden, wie Feiertage. Über ein Ampelsystem sollen bald auslaufende Budgets entsprechend gekennzeichnet werden.“ Diese vereinfacht beschriebenen fachlichen Anforderungen sind dahingehend essenziell, als dass sie es allen Beteiligten zunächst auf einer abstrakten Ebene ermöglichen, die Anforderungen einzuordnen. Es bietet sich hierbei regelmäßig an, mit einheitlichen Fragenkatalogen zu arbeiten, um Anforderungen strukturiert aufzunehmen und daraus Use Cases ableiten zu können. Zudem kann so sichergestellt werden, dass für das Projektteam relevante Informationen stets frühzeitig zur Verfügung stehen.

Nach der Anforderungsaufnahme wären in einem klassischen Reporting-Projekt die nächsten Schritte zunächst die Quelldaten zu analysieren, einen oder mehrere Datamarts zu implementieren, ehe der Bericht entwickelt wird. In einem Selfservice BI-Projekt gestaltet es sich anders. Auch hier gibt es Standard-Berichte, die vorgefertigt sind und zum Abruf bereitstehen. Die Herausforderung besteht jedoch darin, ein Datenmodell zu entwickeln, was neben den o. g. Fragestellungen auch möglichst viele weitere Fragen in diesem Kontext beantworten kann. Hierbei muss stets ein Abgleich zwischen bereits entwickelten Berichten und neuen Anforderungen stattfinden. Insbesondere dann, wenn es Anpassungen am bereits bestehenden Datenmodell zu machen gilt, muss sorgfältig überprüft werden, ob und wie sich diese auf bestehende Standard-Reports auswirken. Nur so kann ein bereichsübergreifendes, konsistentes Datenmodell entwickelt werden, was die oben genannten Anforderungen erfüllt.

Über ausgewogene Ressourcenplanung und den Super Consultant

Als wenn Ressourcenplanung unter stark schwankender Verfügbarkeit nicht bereits herausfordernd genug wäre, fordert noch eine weitere Komponente größere Aufmerksamkeit. Der Wunsch nach einem Super Consultant. Das Verlangen nach ihm ist stets groß, unabhängig davon, ob es sich um ein internes oder ein Kundenprojekt handelt. Der Super-Consultant besticht im Wesentlichen durch folgende Merkmale:

• Er ist jung, verfügt aber bereits über 20 Jahre Berufserfahrung.
• Es gibt nichts, was er nicht kann. Defizite sind ihr ein Fremdwort.
• Er wird nicht krank und Urlaub findet er auch unnötig.
• Obwohl er bereits Principal Consultant ist, begnügt er sich mit einem Junior-Stundensatz.

Zugegeben, wer hätte nicht gerne einen oder mehrere Projektmitarbeiter mit diesen Eigenschaften? Die Realität zeichnet jedoch oftmals ein anderes Bild. Projektmitarbeiter haben unterschiedliche Stärken und es gilt ein Team aufzubauen, was sich dahingehend möglichst optimal ergänzt. Oftmals wird in diesem Zusammenhang auch eine Diskussion darüber geführt, inwieweit Junior Consultants für ein Projekt überhaupt infrage kommen. Die kritischen Argumente von Kunden sind dabei oftmals die gleichen: das Projekt steht unter Druck, es wird viel Erfahrung benötigt, die Betreuung ist zu aufwändig oder man möchte schlicht und ergreifend nicht für die „Ausbildung“ eines Consultants bezahlen. Hinterfragt man die einzelnen Argumente, erfährt man oftmals, dass in der Vergangenheit schlechte Erfahrungen in diesem Kontext gesammelt wurden.

Dennoch gibt es Möglichkeiten, Junior Consultants mit ihren individuellen Stärken in ein Projekt so einzubinden, dass für alle Beteiligten ein Mehrwert entsteht. Dass ein sinnvoller Beitrag zum Projekt geleistet wird, der Junior Consultant sein Know-how erweitert und zu keinem Zeitpunkt der Eindruck beim Kunden entsteht, er würde die „Ausbildung“ des Junior Consultants bezahlen und dieser das Projekt verlangsamen. Wie das gelingen kann? In erster Linie durch eine ehrliche und realistische Selbsteinschätzung, aber vor allem durch ein ausgewogenes Staffing.

Junior Consultants der ORDIX AG verfügen grundsätzlich über eine solide Grundausbildung. Wenn nicht explizit mit dem Kunden anders vereinbart, werden sie auch nicht für Projekte vorgesehen, die nicht zu ihrem Skillset passen. Wenn ein passendes Projekt im Raum steht, gilt es zunächst zu prüfen, inwieweit ein Junior Consultant in dieses integriert werden könnte. Die Anforderungen und Bedürfnisse sind dabei sowohl auf Mitarbeiter- als auch auf Kundenseite stets im Einzelfall zu betrachten. Ein Kunde, zu dem ein starkes Vertrauensverhältnis aufgrund einer bereits lang existierenden Partnerschaft besteht, bringt eine andere Grundoffenheit mit, als ein möglicher Neukunde. Ein Junior Consultant hat vielleicht schon erste Erfahrungen im Projektumfeld sammeln können, während es für einen anderen der erste Projekteinsatz ist. So oder so: Es geht nicht ohne einen starken Sparringspartner. Und hierbei bietet es sich regelmäßig an, Junior Consultants in einem Team mit erfahrenen Consultants anzubieten. Die erfahrenen Consultants übernehmen hierbei eine Art Mentornrolle und unterstützen an den Stellen, wo es nötig ist. Ebenso ist es wichtig, über realistische Tätigkeitsfelder des Junior Consultants zu sprechen und diese entsprechend in das Projekt einzuplanen.

Von Beginn an offen und transparent geplant und kommuniziert, schafft ein solches Vorgehen nicht nur Vertrauen, sondern bringt auch einen entsprechenden Mehrwert für das Projekt und seine Mitarbeiter.

Das beschriebene Szenario gilt selbstverständlich auch für interne Projekte bei der ORDIX AG. Auch hier galt es, eine ausgewogene Mischung zwischen Junior Consultants und erfahrenen Consultants zu finden. Nicht zuletzt auch, um entsprechendes Know-how aufzubauen. Und auch hier galt es dies intern entsprechend transparent und offen zu kommunizieren und von vorneherein in den Projektplan einfließen zu lassen. Warum sollte es in einer BI-Beratung auch anders sein als in den meisten Kundenprojekten?

Warum Sichtbarkeit das A und O ist und wieso es gerade zu Projektbeginn so wichtig ist

Eine Herausforderung in einem Self-Service BI-Projekt ist zu Beginn stets die geringe Sichtbarkeit nach außen. Bis erste Berichte erstellt werden können, muss ein konsistentes Datenmodell vorliegen. Dies wiederum kann erst entwickelt werden, wenn mehrere, fachübergreifende Anforderungen bekannt sind. In dieser Phase können Stakeholder schnell unruhig werden, da kaum nicht-technische Ergebnisse sichtbar werden bzw. jene nur mit hohem Erklärungsaufwand oder sehr abstrakt präsentiert werden können.

Was in dieser Situation helfen kann, ist, den Prozess, zumindest am Anfang, umzudrehen. Damit ist gemeint, zunächst Standardberichte zu entwickeln, obwohl noch kein Datenmodell zur Verfügung steht. Zweifelsohne ist dies nicht in jedem Umfeld darstellbar und ja, es erzeugt Mehraufwand. Jedoch keinen, der zwangsläufig umsonst ist. Denn auch hier lassen sich wertvolle Erkenntnisse gewinnen, die im weiteren Projektverlauf durchaus wertvoll sein können. Konkret geht es darum, Berichte ohne konsistentes Datenmodell zu entwickeln, also beispielsweise direkt auf den Daten eines Quellsystems. Mit Abstrichen in den Bereichen Datenkonsistenz und Datenqualität und einigen Limitierungen, um die Datenverfügbarkeit je nach Berechtigungsstufe des Anwenders auch einzuschränken, zu können. Das Vorgehen bietet sich insbesondere dann an, wenn eine neue BI-Software eingeführt wird. So können Fachanwender bereits erste Erfahrungen mit der BI-Software sammeln und es kann bereits in einer frühen Projektphase über Anforderungen an bestimmte Darstellungsformen oder Corporate Identity gesprochen werden.