Finance Transformation ist kein IT-Projekt

SAP S/4HANA ist live. Die Migration läuft. Die Systemintegratoren liefern. Und trotzdem weiß niemand im Steering Committee, ob das Programm auf Kurs ist — weil die Steuerungslogik zwischen Finance, IT und Business nie definiert wurde.

Warum Finance-Transformationen technisch gelingen und operativ scheitern

Die meisten SAP- und Finance-Transformationsprogramme sind als IT-Projekte aufgesetzt. Es gibt einen Systemintegrator, einen Projektplan, ein Budget, einen Go-Live-Termin. Die Organisation konzentriert sich auf Datenmigration, Customizing, Testing, Cutover. Das ist notwendig — aber es ist nur die Hälfte.

Die andere Hälfte ist die Frage, wie das Unternehmen nach dem Go-Live gesteuert wird. Welche KPIs gelten in der neuen Welt? Wer ist verantwortlich für den Forecast — Finance oder das Projekt? Wie werden Abweichungen eskaliert? Wer entscheidet, wenn der neue Prozess nicht funktioniert und der alte nicht mehr existiert?

In den meisten Programmen werden diese Fragen nicht beantwortet — nicht weil sie unwichtig wären, sondern weil niemand dafür zuständig ist. Der Systemintegrator baut das System. Das PMO steuert den Projektplan. Finance liefert die Zahlen. Aber die Governance-Architektur, die all das zusammenhält, wird von niemandem verantwortet.

Das Ergebnis: Technisch funktioniert das System. Operativ funktioniert die Steuerung nicht. Der CFO bekommt Reports, die formal korrekt sind, aber keine Entscheidung ermöglichen. Das Steering Committee tagt, aber steuert nicht. Und sechs Monate nach Go-Live fragt der Vorstand, warum die Transformation nicht die versprochenen Ergebnisse liefert.

Drei Governance-Lücken, die jede Finance-Transformation gefährden

Die erste Lücke: KPI-Logik wird nicht mitgedacht. In der alten Welt gab es etablierte Kennzahlen, etablierte Reports, etablierte Interpretationen. In der neuen Welt — mit S/4HANA, SAC, neuen Buchungslogiken — sind diese Kennzahlen nicht mehr automatisch vergleichbar. Wer die KPI-Architektur nicht parallel zur Systemmigration neu definiert, baut ein System, das Daten produziert, aber keine Steuerung ermöglicht.

Die zweite Lücke: Finance hat keine Rolle im Programm. In den meisten Transformationsprogrammen sitzt Finance am Rand — als Budget-Kontrolleur und Zahlenzulieferer, nicht als Governance-Instanz. Finance wird eingeladen, wenn der Forecast fällig ist, aber nicht, wenn Architekturentscheidungen getroffen werden. Das führt dazu, dass Systemdesign-Entscheidungen ohne Finance-Perspektive fallen — und Finance nach Go-Live mit einem System arbeiten muss, das nicht zu seinen Steuerungsanforderungen passt.

Die dritte Lücke: Entscheidungsstrukturen zwischen Projekt und Linie sind nicht definiert. Während der Transformation gibt es parallele Verantwortlichkeiten — die Projektorganisation und die Linienorganisation. Beide treffen Entscheidungen, aber die Schnittstellen sind nicht geregelt. Wer entscheidet über den Kontenplan — das Projekt oder der CFO? Wer gibt die Planungslogik frei — der Workstream Lead oder der Head of Controlling? Ohne klare Entscheidungsmatrix entstehen Blockaden, die das Programm monatelang aufhalten.

Finance Transformation als Governance-Projekt denken

Eine Finance-Transformation, die nachhaltig funktioniert, braucht drei Strukturelemente jenseits der Systemimplementierung.

Erstens eine KPI-Architektur, die parallel zum System aufgebaut wird. Das bedeutet: Nicht erst nach Go-Live definieren, welche Kennzahlen gelten, sondern vom ersten Tag an die Frage stellen, wie das Unternehmen in der neuen Welt gesteuert werden soll. Welche KPIs braucht der CFO? Welche das Steering Committee? Welche der Workstream Lead? Die Antworten darauf bestimmen das Systemdesign — nicht umgekehrt.

Zweitens eine definierte Finance-Governance-Rolle im Programm. Finance muss nicht nur Zahlen liefern, sondern an Architekturentscheidungen beteiligt sein. Das erfordert eine Rolle, die zwischen System-Design und Steuerungsanforderung vermittelt — jemand, der sowohl SAP FiCo versteht als auch weiß, was der CFO im Steering Committee braucht. In den meisten Programmen existiert diese Rolle nicht. Sie sollte existieren.

Drittens eine Entscheidungsmatrix zwischen Projekt und Linie, die vor dem Go-Live steht — nicht danach. Wer entscheidet welche Fragen, auf welcher Ebene, mit welcher Datenbasis? Welche Entscheidungen trifft das Projekt autonom, welche erfordern Linienfreigabe? Das klingt nach Bürokratie. In der Praxis ist es das Einzige, was verhindert, dass ein Programm an seiner eigenen Komplexität erstickt.

Meine Rolle in Finance-Transformationen

Ich arbeite seit über 20 Jahren an der Schnittstelle von Finance, IT und Business in SAP- und Finance-Transformationsprogrammen. Mein Fokus ist nicht die Systemimplementierung — dafür gibt es Systemintegratoren. Mein Fokus ist die Steuerungslogik, die das Programm erst steuerbar macht.

Bei Rolls-Royce Power Systems habe ich als Senior Project Lead Finance & IT ein Projektcontrolling-Framework auf Basis von SAP PPM und SAC aufgebaut und die Integration von Angebots-, Produkt- und Finanzdaten in SAP verantwortet. Bei der Hamburger Hochbahn habe ich die Finance-seitige Begleitung der S/4HANA-Einführung geleitet — von der konzernweiten Planungsrichtlinie bis zur Umsetzung in SAP Analytics Cloud. Bei Mast-Jägermeister habe ich die integrierte Unternehmensplanung in SAC entwickelt und die Migration von R/3 nach S/4HANA begleitet.

Ich arbeite in Unternehmen in DACH, remote und vor Ort. Mein Mehrwert ist die Brücke zwischen der technischen Transformation und der Frage, wie das Unternehmen danach tatsächlich gesteuert wird.