Wenn Reporting nicht mehr reicht – wo BI an seine Grenzen stößt
Veröffentlicht: 29. Juli 2026
Das Muster kennt fast jeder, der schon einmal ein BI-Projekt begleitet hat: 18 Monate Laufzeit, ein sauber aufgesetztes Datenmodell, ein Go-live mit Applaus. Die Dashboards sehen gut aus. Die Zahlen stimmen sogar.
Und ein Jahr später? Die Nutzungsstatistik zeigt eine Handvoll aktiver Anwender. Das Controlling arbeitet für den Forecast wieder in Excel. Die Vorstandsvorlage entsteht auf einem anderen Weg als das offizielle Reporting.
"Gescheitert“ heißt in BI-Projekten selten, dass etwas technisch nicht funktioniert. Es heißt vielmehr, dass die gewonnenen Erkenntnisse nicht in die Entscheidungen einfließen, die das Unternehmen tatsächlich voranbringen.
Reporting ist unverzichtbar – aber nur Teil der Antwort
Reporting ist die Grundlage moderner Unternehmenssteuerung. Es schafft Transparenz, macht Entwicklungen sichtbar und sorgt dafür, dass Entscheidungen auf einer verlässlichen Datenbasis getroffen werden können.
Doch Reporting beantwortet vor allem eine Frage: Was ist passiert?
Für die Unternehmenssteuerung reicht das allein nicht aus. Wer wissen möchte, welche Auswirkungen eine Entscheidung morgen hat oder welche Maßnahmen heute sinnvoll sind, braucht mehr als den Blick auf die Vergangenheit.
Vier Stufen und der Punkt, an dem die meisten Projekte stehen bleiben
Es hilft, den Reifegrad der eigenen Steuerung als Treppe zu denken:
Reporting:Was ist passiert?
Standardisierte Sicht auf Ist-Zahlen. Vergangenheitsorientiert, breiter Adressatenkreis, hoher Automatisierungsgrad. Notwendige Basis, aber eben nur Basis.
⬇
Analyse:Warum ist es passiert?
Drill-down auf Treiber, Abweichungsursachen, Kennzahlenzusammenhänge. Hier sind gute BI-Werkzeuge stark — sofern die Kennzahlenlogik im Modell hinterlegt ist und nicht nur in den Köpfen.
⬇
Planung:Was wollen wir erreichen?
Jetzt entstehen zum ersten Mal Daten, die es vorher nicht gab. Ziele, Maßnahmen, Verantwortlichkeiten. Gegenstromverfahren zwischen Top-down-Vorgabe und Bottom-up-Meldung. Rollierender Forecast. Das ist kein Auswerten mehr, das ist Erzeugen.
⬇
Simulation: Was wäre, wenn?
Szenarien durchrechnen, bevor entschieden wird. Sensitivitäten sichtbar machen. Best Case, Worst Case, Realistic Case nebeneinander, nicht als drei Excel-Dateien, sondern als Versionen eines Modells.
Die meisten BI-Projekte enden zwischen Stufe eins und zwei. Und genau dort entsteht die Enttäuschung: Das Management hat Entscheidungsunterstützung erwartet und Vergangenheitsbewältigung bekommen.
Warum aus Erkenntnissen oft keine Entscheidungen werden
Das ist keine Frage von Lizenzen oder Schulungen. Es sind vier strukturelle Gründe:
1. Lesend statt schreibend.
BI-Systeme sind darauf ausgelegt, Daten aus Vorsystemen zu konsumieren. Planwerte müssen aber erfasst, kommentiert, geändert und wieder geändert werden, von vielen Personen, mit nachvollziehbarer Historie.
2. Kein betriebswirtschaftliches Modell im Fundament.
GuV-Logik, die Verknüpfung von Ergebnis-, Finanz- und Bilanzplanung, Werteflüsse zwischen Kostenstellen: In einem generischen BI-Tool wird das nachgebaut. Jede Formel ist Handarbeit, jede Änderung ein kleines Projekt.
3. Szenarien sind kein Erstklassenobjekt.
Ist, Plan, Forecast I bis IV, Simulationsvarianten: das gehört als eigene Dimension ins Modell, nicht in Dateinamen mit Datumsstempel.
4. Kein Prozess.
Planung ist ein Workflow: Wer liefert was bis wann, wer gibt frei, wo hakt es gerade. Ohne Statusverfolgung und Freigabelogik wird jede Planungsrunde zur E-Mail-Verwaltung.
Das Ergebnis ist in vielen Häusern dasselbe: ein Excel-Schattenhaushalt neben dem offiziellen BI-System. Und damit die Situation, die man eigentlich abschaffen wollte: zwei Wahrheiten, von denen niemand genau sagen kann, welche gilt.
Was sich ändert, wenn Planung Teil der Architektur ist
Ein konkretes Beispiel. Der Einkaufspreis eines wesentlichen Rohstoffs steigt um acht Prozent.
Im Dashboard sehen Sie die Auswirkungen erst im nächsten Monatsabschluss, im Materialaufwand, rückblickend als Abweichung.
In einem integrierten Modell stellen Sie die Frage vorher: Was macht das mit dem EBIT? Ab welchem Monat wird die Liquidität eng? Welche Preisanpassung würde den Effekt kompensieren, und was passiert dann mit der Absatzmenge? Reißen wir einen Covenant? Und wie sieht das Ganze aus, wenn der Effekt nur zur Hälfte eintritt?
Der Unterschied ist nicht die Grafik. Der Unterschied ist, dass eine Änderung an einer Stelle des Modells automatisch durch Ergebnisrechnung, Liquiditätsplanung und Bilanz läuft, weil diese Zusammenhänge im System abgebildet sind und nicht in einem verketteten Tabellenblatt.
Das ist kein Entweder-oder
Der häufigste Denkfehler in dieser Diskussion: dass man sich entscheiden müsse. Muss man nicht.
Ein sinnvolles Zielbild sieht eher so aus: Eine Financial-Management-Lösung als führendes System für Planung, Forecast, Konsolidierung und Simulation, mit dem betriebswirtschaftlichen Modell und der Datenhoheit. Und darüber, wo gewünscht, die BI-Oberfläche für die breite Verteilung und Visualisierung. Die Planungsergebnisse fließen in die Dashboards, statt daneben zu existieren.
Genau an dieser Stelle setzt Corporate Planner an: als integrierte Lösung für Ergebnis-, Finanz- und Bilanzplanung, in der Reporting, Analyse, Planung und Simulation auf einem gemeinsamen Modell aufsetzen, ohne dass das Controlling für jede Szenariorechnung wieder in Excel ausweichen muss.
Fünf Fragen vor dem nächsten Projekt
Bevor Sie das nächste Budget für ein BI-Vorhaben freigeben, lohnen sich fünf Fragen:
- Welche Entscheidung soll mit dem Ergebnis besser getroffen werden — konkret benannt, nicht „mehr Transparenz"?
- Können Anwender im Zielsystem Werte eingeben, oder nur ansehen?
- Wie viele Klicks braucht ein zweites Szenario?
- Wo entsteht der Forecast heute wirklich — und wird das nach dem Projekt anders sein?
- Ist die Verknüpfung von Ergebnis, Liquidität und Bilanz im Modell hinterlegt oder in einem Tabellenblatt?
Wenn die Antworten unbequem sind, liegt das Problem selten am Visualisierungswerkzeug. Es liegt daran, dass ein Reporting-Projekt eine Steuerungsfrage lösen sollte.
