Warum BI nicht mit Evaluation des Front-Ends beginnt

Die Ursachen warum ein BI-Projekt scheitern kann sind vielfältig. Aufgrund meiner Tätigkeiten in diversen KMUs in den unterschiedlichsten Branchen bin ich der Meinung, dass sich KMU teilweise zu früh mit der Evaluation des „Front-Ends“ (Benutzeroberfläche) auseinander setzen. Ein Hauptgrund darin sehe ich, weil die KMU nicht ausreichend über Know-How in diesem Bereich verfügen, sowie die finanziellen Mittel verständlicherweise knapp sind.

Grössere Unternehmen beschäftigen sich oft schon länger mit dem Thema „Business Intelligence“ und haben deshalb die internen Ressourcen dafür geschaffen, so zum Beispiel ein BI-Competence Center. Bei kleineren Unternehmen ist es oft so, dass ein ERP System im Einsatz ist und man für das Reporting die darin vorhanden Funktionen nutzt. Der Klassiker ist auch ein rein Excel-basiertes Reporting. Alle Daten werden via Export-Funktion ins Excel übertragen. Gerade bei aufwendigeren Auswertungen muss man sich die Frage stellen, ob diese Excel-Variante noch effizient genug ist und die Fehleranfälligkeit nicht zu hoch ist?

Wenn sich ein KMU entscheidet in den Bereich „BI“ zu investieren (ohne internes Know-How), wird oftmals mit der Evaluation des Front-Ends begonnen. Nachfolgend möchte ich an einem kleinen Beispiel aufzeigen, welche Vor- und Nachteile dieses Vorgehen mit sich bringen kann.

Case: KMU mit einem ERP, bisher kein BI-Tool im Einsatz, Controller bekommt vom CFO den Auftrag ein einfaches BI-Tool einzuführen, der Mitarbeiter kennt sich bisher nur in diesem Thema anwenderseitig aus.

So beginnt der Controller mit der Themen-Recherche und stösst dabei schnell auf die Produkte wie beispielsweise Tableau, Qlik oder Power BI. Der Controller kann schnell anhand von den Test-Umgebungen einsehen, ob ihm das Tool „handlich“ ist oder nicht. Der Vorteil von diesem Vorgehen ist, dass sich der Controller gut in diesem Bereich auskennt und so schnell erste Erkenntnisse gewinnt. Anschliessend kann er kostenlose Produkt-Präsentationen in Anspruch nehmen. Natürlich ein weiterer grosser Vorteil, da die finanziellen Ressourcen begrenzt sind.

Jetzt kommt das grosse ABER: die Evaluation des Front-Ends ist meiner Meinung nach nur noch die „Kür“ des ganzen Prozesses. Die nachfolgende Grafik soll aufzeigen, was alles vor dem letzten Punkt der „Visualisierung“ in Betracht werden soll.

Als Basis sollte sich der Controller überlegen, wie die Unternehmensstrategie aussieht. Dies kann man als Richtschur sehen: Wo will das Unternehmen hin? Darauf basierend wird abgeleitet, mit welchen IT-Systemen wie man in Zukunft arbeiten möchte. Wenn ein KMU diese IT-Strategie noch nicht verfasst hat, so kann der Controller im Minium durch Gespräche mit der IT das Vorhaben abholen.

Anschliessend ist es für den Projekterfolg sehr wichtig, dass eine BI-Strategie ausgearbeitet wird. Es kann auch in einem kleinen und simplen Rahmen stattfinden. In diesem Schritt wird beispielsweise überlegt, wie die Steuerungs- und Planungsprozesse aussehen sollen. Aber auch welche Anforderungen es an das Reporting gibt.

Goverance: Darauf aufbauend sorgt ein funktionierender organisatorischer Rahmen mit definierten Rollen und Prozessen für die erfolgreiche und strategiekonforme Umsetzung im täglichen Miteinander zwischen den Fachseiten und der IT.

Im nächsten Schritt wird die ganze Architektur aufgebaut:

1. 1. Datenquellen: Welche Systeme sind einzubeziehen?
   2. Datenintegration: Wie werden die von der Quelle (via Staging-Bereich) ins DWH/Datamart geladen? Es muss sich überlegt werden, welche Daten überhaupt fürs Reporting gebraucht werden. Ich würde die Granularität als eines der wichtigsten Design-Merkmale einschätzen. Die Daten müssen unbedingt granular sein, da man sonst Flexibilität verliert.
   3.  Daten Modellierung: Wie sollen die Daten modelliert werden? Ist zum Beispiel das Stern-Schema das richtige?
   4.  Daten Visualisierung: Wie will man die Daten darstellen?

Wichtig hierbei zu beachten ist, dass es kein richtig oder falsch gibt. Der Controller sollte jedoch immer die Strategie sowie die Anforderungen im Auge behalten. Erst im Anschluss kann man sich um die Produktion der integrierten Daten kümmern. Die Basis für dieses Daten Management stellt die entsprechende Infrastruktur dar.

Am Schluss erfolgt dann noch die erwähnte „Kür“: die Visualisierung und der Produkt-Entscheid des  Front-Ends (Reporting Tool). Wenn das Case-KMU das Vorgehen gemäss der Pyramide wählt und zuerst das Back-End aufbaut, braucht es zwar einiges mehr Zeit und Geld am Anfang, aber man kann dadurch intern mehr Know-how aufbauen. Ausserdem gibt es die Möglichkeit, das Berichtswesen grundsätzlich zu verbessern, anstatt nur die Excel-Variante abzulösen. Während meiner Praxiserfahrung habe ich festgestellt, dass das Front-End schlussendlich Geschmacksache ist und nicht zu stark von den Erfahrungen und Bedürfnissen der Mitarbeitenden abhängig sein soll. Die Umsetzung gemäss BI-Strategie gibt die Richtung vor.

Ich würde allen KMU raten, diese Extra-Meile zu gehen, wenn nötig mit einem externen unabhängigen Berater, damit man sich nicht anfänglich in der Evaluation des Reporting-Tools verliert.

Quellen / weitere Artikel:

https://www.linkfish.eu/6-bausteine-fuer-erfolgreiche-bi-strategien-und-bi-projekte/

https://www.10hoch10.com/wiki/bi-architektur/

https://www.cio.de/a/die-erfolgreiche-bi-strategie,2264284,4

https://www.computerwoche.de/a/woran-bi-projekte-scheitern,2366850