Warum BI-Projekte technisch gelingen und trotzdem scheitern

BI-Projekte scheitern meist nicht an der Technik, sondern an der fehlenden Übersetzung zwischen Fachbereich und IT. Wo niemand verantwortet, dass aus einem Steuerungsbedarf eine testbare Anforderung wird, bleibt selbst ein technisch einwandfreies Dashboard ungenutzt.

Ein vertrautes Bild: das Projekt ist fertig, genutzt wird es trotzdem nicht

Das Projekt wurde termingerecht abgenommen. Die Datenmodelle sind sauber, die Performance stimmt, das Dashboard sieht professionell aus. Und trotzdem öffnen die Fachabteilungen weiter ihre alten Excel-Tabellen, sobald eine echte Entscheidung ansteht. Dieses Muster wiederholt sich in vielen Mittelstandsunternehmen, unabhängig davon, mit welchem Werkzeug gearbeitet wurde.

Das Muster hat einen gemeinsamen Nenner: Die technische Umsetzung war nicht das Problem. Das Problem war, dass niemand im Projekt die Übersetzung zwischen dem, was der Fachbereich zur Steuerung braucht, und dem, was die IT effizient bauen kann, verantwortet hat.

Wie die Lücke entsteht

IT-Dienstleister – intern wie extern – werden in der Regel nach Anforderungsdokumenten beauftragt. Diese Dokumente entstehen oft unter Zeitdruck und beschreiben, welche Felder ein Dashboard zeigen soll, seltener, welche Entscheidung damit getroffen werden soll. Die IT liefert exakt das Dokument, technisch korrekt und pünktlich. Nur beantwortet das Dokument nicht immer die richtige Frage.

Der Fachbereich wiederum bemerkt die Lücke oft erst im Betrieb, wenn eine konkrete Steuerungsfrage auftaucht, die im Dashboard nicht abbildbar ist. Zu diesem Zeitpunkt ist das Projektbudget meist aufgebraucht, und die Änderung landet als kostenpflichtiger Change Request – oder wird gar nicht mehr umgesetzt, und die Excel-Tabelle bleibt die eigentliche Steuerungsgrundlage.

Die fehlende Rolle zwischen Business und IT

In den Projekten, die ich begleitet habe, war der entscheidende Unterschied selten das gewählte Tool. Entscheidend war, ob es eine Rolle gab, die beide Sprachen sprach: die des Controllings, das in Kennzahlen und Entscheidungsschwellen denkt, und die der IT, die in Datenmodellen und Systemgrenzen denkt.

Diese Rolle übersetzt einen Satz wie „wir brauchen bessere Transparenz über die Profitabilität“ in eine konkrete, testbare Anforderung: welche Kennzahl, auf welcher Aggregationsebene, aus welchen Quellsystemen, mit welcher Aktualisierungsfrequenz. Ohne diese Übersetzung bauen IT-Teams technisch korrekte Lösungen für eine falsch verstandene Frage.

Drei Muster, die auf fehlende Übersetzung hindeuten

Ein erstes Muster ist ein Anforderungsdokument, das ausschließlich aus Feldlisten besteht, ohne zugehörige Entscheidungslogik. Ein zweites Muster ist ein Projektteam, in dem Fachbereich und IT sich erst in der Abnahmephase zum ersten Mal ausführlich über den tatsächlichen Bedarf austauschen. Ein drittes Muster ist ein Prototyp, der erst kurz vor Projektende erstmals von den späteren Nutzern gesehen wird.

Jedes dieser Muster lässt sich früh erkennen, wenn man gezielt danach schaut. Sie treten selten einzeln auf – meist verstärken sie sich gegenseitig, weil fehlende Entscheidungslogik zu spätem Nutzerfeedback führt und umgekehrt.

Wie das im Projektalltag abläuft

Der Ablauf ist meist derselbe: Ein Anforderungsdokument listet über mehrere Seiten die Felder auf, die ein Dashboard zeigen soll. Der beauftragte Dienstleister liefert pünktlich und technisch sauber genau diese Felder. Monate nach dem Go-Live nutzt ein Teil der Fachabteilung das Werkzeug, der Rest arbeitet weiter mit eigenen Auswertungen.

Fragt man nach, fehlt fast nie ein Feld. Es fehlt eine Vergleichsebene – etwa die eigene Region gegen den Vorjahresmonat, bereinigt um Sondereffekte. Diese Anforderung stand in keinem Dokument, weil niemand gefragt hatte, welche Entscheidung das Dashboard ermöglichen soll. Die Nachbesserung kostet am Ende mehr als die Klärung vor Projektbeginn gekostet hätte.

Was stattdessen funktioniert

Projekte, die diese Fallstricke vermeiden, beginnen mit einer kurzen, aber verbindlichen Phase zur Klärung der Kennzahlenlogik – vor dem ersten Zeilencode. Diese Phase dauert selten länger als zwei bis drei Wochen, spart aber typischerweise ein Vielfaches an späteren Änderungsaufwänden.

Zusätzlich hilft ein früher, bewusst unfertiger Prototyp. Ein Dashboard-Entwurf, der nach einer Woche mit echten Nutzern getestet wird, deckt Fehlannahmen auf, während sie noch günstig zu korrigieren sind. Diese beiden Maßnahmen – frühe Kennzahlenklärung und früher Prototyp – lassen sich in praktisch jedes bestehende Projektvorgehen integrieren, unabhängig vom gewählten BI-Werkzeug.

Wichtig ist außerdem, wer diese Klärungsphase verantwortet. Wird sie allein der IT übertragen, entstehen erneut technisch getriebene Anforderungen. Wird sie allein dem Fachbereich übertragen, fehlt oft das Wissen darüber, welche Anforderungen sich mit vertretbarem Aufwand umsetzen lassen. Tragfähig wird die Phase erst, wenn eine Person sie verantwortet, die beide Perspektiven versteht und zwischen ihnen vermittelt, statt nur Anforderungen weiterzureichen.

Fazit für die Projektplanung

Wenn ein BI-Projekt nach der technischen Abnahme ungenutzt bleibt, lohnt sich der Blick auf die Anforderungsphase, nicht auf die Implementierung. Die Technik war in den meisten Fällen nicht das Problem. Die fehlende Übersetzung zwischen Business und IT war es – und die lässt sich mit der richtigen Rolle im Projekt gezielt schließen.

Für Geschäftsführungen im Mittelstand bedeutet das konkret: Bevor ein BI-Projekt beauftragt wird, lohnt sich die Frage, wer im Projekt die Übersetzung zwischen Fachbereich und IT verantwortet. Fehlt eine klare Antwort, ist das ein früher Hinweis darauf, dass das Projekt trotz technisch sauberer Umsetzung an derselben Stelle scheitern könnte wie viele vergleichbare Vorhaben zuvor.