Warum Reporting-Anpassungen im Unternehmen so lange dauern - ... und was Controller konkret tun können

Die Anpassung des Reports dauert noch.

In vielen Unternehmen hören Controller:innen immer wieder diesen Satz. Und oft dauert sie nicht Tage, sondern Monate. Währenddessen entstehen Excel-Zwischenlösungen, manuelle Auswertungen oder lokale Power-BI-Dateien. Offizielle Reports hinken dem Bedarf hinterher, während inoffizielle Lösungen wachsen.

Die entscheidende Frage lautet daher nicht mehr: Warum dauert Reporting so lange? Sondern:

Warum passiert das systematisch — und was kann das Controlling konkret dagegen tun

Für „Reporting“ gibt es in vielen Unternehmen keinen Product Owner

In vielen Organisationen verteilt sich Reporting über mehrere Bereiche: IT betreibt Systeme und Infrastruktur, Finance verantwortet Inhalte, Fachbereiche formulieren Anforderungen, Data-Teams entwickeln Datenmodelle, externe Partner bauen Reports. Aber häufig besitzt niemand Reporting als Product Owner.

Neue Anforderungen entstehen permanent — zusätzliche Kennzahlen, neue Organisationsstrukturen, veränderte Steuerungslogiken, regulatorische Anforderungen, Management-Sonderauswertungen. Ohne klare Verantwortung entsteht ein bekannter Effekt: Anforderungen sammeln sich, Prioritäten wechseln, und jede Anpassung wird zu einem kleinen Projekt. Für Controller bedeutet das: Der Bedarf ist vorhanden — die Lösung kommt irgendwann.

Die versteckte Komplexität hinter "nur einem neuen Feld"

Viele Anforderungen wirken zunächst trivial: "Wir brauchen noch eine zusätzliche Dimension." Oder: "Der Forecast soll zusätzlich versioniert werden." Technisch bedeutet das jedoch häufig: Anpassung mehrerer Datenmodelle, Prüfung von Datenherkünften, Performance-Optimierung, Anpassung von Berechtigungen, Tests mit mehreren Fachbereichen, Abstimmung mit bestehenden Reports.

Ein konkretes Beispiel: Ein Industrieunternehmen möchte im monatlichen Kostenstellenbericht eine neue Dimension ergänzen — die Unterscheidung nach Instandhaltungsart (präventiv vs. korrektiv). Die Anforderung klingt nach einer Stunde Arbeit. Die Realität: Das Datenmodell muss angepasst werden, bestehende historische Daten müssen re-klassifiziert werden, drei weitere Reports nutzen dasselbe Modell und müssen mitgetestet werden, die Berechtigungen für zwei Benutzergruppen müssen überprüft werden. Drei Monate später ist der Report fertig — die Instandhaltungsleitung arbeitet seit Woche zwei mit einer Excel-Datei.

Ein scheinbar kleines Feld kann mehrere Reports und Prozesse beeinflussen. Deshalb dauern Änderungen deutlich länger, als Fachbereiche erwarten. Und genau in dieser Wartezeit entsteht der nächste Excel-Workaround.

Projekte finanzieren Migration — nicht Steuerungslogik

Ein strukturelles Problem liegt oft bereits in Transformationsprojekten selbst. Budgets fließen primär in Systemmigration, Prozessstabilisierung, Go-Live-Sicherung und technische Umstellungen. Was danach kommt, wird häufig als Optimierung betrachtet: bessere Managementreports, Forecast-Vergleiche, operative Steuerungsberichte, konsistente KPI-Modelle.

Was im Projekt als Phase-2-Thema gilt, ist im Betrieb das Kerngeschäft des Controllings.

Doch genau diese Elemente bestimmen den Alltag des Controllings. Werden sie nicht frühzeitig eingeplant, entsteht nach dem Go-Live erneut manueller Aufwand. Excel schließt dann die Lücke zwischen technischer Plattform und Steuerungsrealität.

Warum Self-Service das Problem nicht löst

Moderne Self-Service-BI-Plattformen versprechen schnellere Anpassungen durch die Fachbereiche selbst. In der Praxis zeigt sich jedoch: Ohne klare Datenmodelle und verbindliche Definitionen entstehen lediglich neue lokale Auswertungen — diesmal in Power BI statt in Excel. Das Problem verlagert sich, es löst sich nicht.

Hinzu kommt die Dynamik des Geschäfts: neue Produkte, neue Märkte, neue Organisationsstrukturen, neue Steuerungsmodelle. Während Unternehmen sich ständig verändern, bleiben Reportingstrukturen oft statisch. Excel hingegen ist sofort anpassbar — deshalb greifen Fachbereiche erneut darauf zurück. Nicht aus Bequemlichkeit, sondern weil Entscheidungen nicht warten können.

Praxis-Tipp: Warum Reporting-Anpassungen so lange dauern

Fünf typische Situationen aus der Controlling-Praxis — und warum jede davon zu Excel führt:

Das Muster: Jede dieser Situationen führt zur selben Konsequenz — Excel schließt die Lücke, die das System lässt. Schnell, individuell, und ohne Governance.

Was Controller konkret tun können

Der entscheidende Punkt: Reporting ist kein reines IT-Thema. Es ist ein Steuerungsthema. Und hier hat das Controlling erheblichen Einfluss. Nachhaltiges Reporting benötigt klare Regeln für Kennzahlen, Datenherkunft und Verantwortlichkeiten — ohne diese Regeln entstehen weiterhin parallele Wahrheiten, unabhängig von der eingesetzten Technologie.

1. Reporting als Produkt definieren
   
   Reporting braucht einen namentlichen Owner, der Anforderungen priorisiert, Änderungen entscheidet und Konsistenz verantwortet. Ohne Ownership bleibt Reporting Stückwerk.
   
   Aus der Praxis: Ein Fertigungsunternehmen mit vier Werken hatte ein klassisches Problem: Der monatliche Kostenstellenbericht lag in drei verschiedenen Versionen vor — eine vom Werkscontroller, eine vom zentralen Controlling, eine vom CFO-Büro. Alle drei wurden aus denselben Quelldaten erzeugt, kamen aber zu unterschiedlichen Ergebnissen, weil Umlageschlüssel und Periodenabgrenzungen verschieden interpretiert wurden. Die Lösung war nicht technisch, sondern organisatorisch: Ein namentlicher Report-Owner wurde bestimmt. Die Anzahl der „dringenden Sonderauswertungen“ halbierte sich innerhalb eines Quartals — weil plötzlich ein Ansprechpartner existierte, der Nein sagen durfte.
2. Kritische Reports identifizieren
   In vielen Unternehmen erzeugen wenige Reports den größten Nutzen — oder verursachen den größten manuellen Aufwand. Controller sollten fragen: Welche Reports werden tatsächlich für Entscheidungen genutzt? Wo entsteht monatlich manueller Excel-Aufwand? Hier lohnt sich Automatisierung zuerst.
   
   Aus der Praxis: In einem Chemieunternehmen mit Produktionsstandorten in vier Ländern existierten nach dem ERP-Go-Live offiziell 140 aktive Berichte. Eine strukturierte Analyse ergab: Nur 14 davon wurden tatsächlich für Führungsentscheidungen genutzt. Ein Automatisierungsprogramm, das sich ausschließlich auf diese 14 Entscheidungsberichte konzentrierte, sparte nach sechs Monaten 55 Stunden manuellen Controlling-Aufwand pro Monat. Die restlichen 126 Berichte wurden stillgelegt — ohne nennenswerte Beschwerden.
3. Excel-Nutzung sichtbar machen
   Excel ist oft unsichtbarer Bestandteil offizieller Reportingprozesse. Controller können Transparenz schaffen: Wo werden Daten regelmäßig exportiert? Wo entstehen lokale Zusatzrechnungen? Welche Reports existieren nur außerhalb des Systems?
   
   Aus der Praxis: Das Controlling-Team eines Handelsunternehmens führte eine einfache Übung durch: Jedes Teammitglied dokumentierte zwei Wochen lang, welche Excel-Dateien täglich geöffnet wurden und welche manuellen Berechnungen vorgenommen wurden. Das Ergebnis: Mehr als 65 Prozent der operativen Controlling-Arbeit fand außerhalb der offiziellen Systeme statt. Erst diese Transparenz erzeugte den Handlungsdruck, den keine Strategiepräsentation zuvor erreicht hatte.
   Praxistipp: Eine einfache Tabelle mit den Spalten „Dateiname“, „Zweck“, „Häufigkeit“, „Wer nutzt das Ergebnis“ genügt als Ausgangspunkt.
4. Versionierung und Historisierung einfordern
   Viele manuelle Lösungen entstehen, weil historische Vergleichswerte fehlen. Welche Forecast-Version war gültig? Wie sah die Planung im letzten Quartal aus? Ohne Versionierung wird Excel zur Zeitmaschine des Controllings.
   
   Aus der Praxis: In einem Maschinenbauunternehmen gab es nach dem Go-Live keine systemische Forecast-Versionierung. Als der Vorstand im Oktober fragte, warum die Jahresprognose im Vergleich zum April um 8 Mio. EUR gesunken war, konnte niemand antworten. Die Versionen existierten nur in den E-Mail-Postfächern der beteiligten Controller.
   
   Controller sollten Versionierungsanforderungen konkret formulieren: „Wir benötigen den Forecast-Stand vom letzten Arbeitstag eines jeden Monats, abrufbar für die zurückliegenden 24 Monate, je Kostenstelle und Kostenart, mit Kommentierung der wesentlichen Annahmen.“ Diese Präzision macht die Anforderung umsetzbar — und den Business-Nutzen sichtbar genug, um in der Projektpriorisierung zu bestehen.
5. Reporting-Backlog priorisieren
   Viele Reporting-Teams arbeiten implizit mit einem wachsenden Backlog aus Änderungsanforderungen — ohne dass dieser sichtbar ist. Ein einfaches Kanban-Board mit den Kategorien „eingereicht“, „in Analyse“, „in Entwicklung“ und „live“ schafft Transparenz und reduziert Erwartungskonflikte zwischen Fachbereich und IT.
   
   Aus der Praxis: In einem Logistikunternehmen stapelten sich nach dem ERP-Go-Live 47 offene Reporting-Anforderungen — keine davon priorisiert. Nach Einführung eines Backlogs mit viertejährlicher Priorisierungsrunde sank die Umsetzungszeit für neue Reports von 14 auf 6 Wochen.
   
   Für CFOs und Finance-Leiter bedeutet das: Reporting ist kein operatives Nebenprodukt der IT, sondern Teil der Steuerungsarchitektur. Wer diese Ebene nicht aktiv gestaltet, überlässt sie dem Zufall — oder Excel.

Fazit: Reporting ist ein Steuerungsprodukt

Reporting-Anpassungen dauern nicht wegen mangelnder Technologie. Sie dauern, weil Reporting im Unternehmen oft nicht als strategisches Steuerungsinstrument organisiert ist. Solange Reporting nur als Nebenprodukt von IT-Projekten betrachtet wird, entstehen weiterhin manuelle Nebenwelten.

Reporting ist kein IT-Thema. Es ist das Fundament, auf dem jede datengetriebene Entscheidung steht — oder eben nicht steht.