Kaputt oder nur verzögert? Warum die echte Diagnose eines S/4-Programms bei den Zahlen beginnt, nicht beim Backlog.

Zwei Probleme, die von außen identisch aussehen

Aus der Sicht des Lenkungsausschusses senden ein verzögertes und ein kaputtes S/4-Programm dieselben Signale: rutschende Termine, ein Backlog, der wächst statt schrumpft, und ein Implementierungspartner, der um mehr Zeit, mehr Budget oder mehr Personal bittet. Jedes dieser Signale ist mit „wir sind im Zeitplan zurück" vereinbar — und jedes davon ist genauso mit „das zugrunde liegende Design funktioniert nicht" vereinbar. Genau deshalb werden beide verwechselt, und genau deshalb ist die Standardantwort auf beide meist dieselbe: mehr Kapazität, mehr Zeit.

Diese Antwort ist bei einem verzögerten Programm oft richtig. Bei einem kaputten Programm ist sie es fast nie.

Der Test, der die beiden unterscheidet

Ein Programm ist verzögert, wenn Umfang und Zeitplan gerutscht sind, das zugrunde liegende Finance-Design — Kontenrahmen, CO-Struktur, die CO-FI-Brücke, Konsolidierungs- und RAR-Logik — aber tragfähig ist. Sobald die Implementierung aufholt, hält der Abschluss, Controlling vertraut den Zahlen, und der Backlog war tatsächlich die Restriktion.

Ein Programm ist kaputt, wenn selbst das Aufholen des Backlogs es nicht beheben würde — weil der Abschluss auf dem heute existierenden Design nicht hält, unabhängig davon, wie viel davon schon gebaut wurde. Mehr Implementierungskapazität liefert nur mehr von einem Design, das nicht saubereren schließt — nur schneller. Das ist das eigentliche Merkmal: Behebt das Fertigstellen des Plans, wie er geschrieben ist, den Abschluss — oder muss der Abschluss neu entworfen werden, bevor das Fertigstellen des Plans überhaupt etwas bedeutet.

Wenn S/4-Finance nicht saubere schließt, ist nicht das System das Problem — sondern das Programm. Recovery beginnt bei den Zahlen, nicht beim Backlog.

Warum „mehr Kapazität" ein kaputtes Programm schlimmer macht

Recovery wird nicht über einen ROI-Rechner verkauft, und das aus gutem Grund: Der Wert, ein kaputtes Finance-Design zu reparieren, ist qualitativ — kein Wert, den eine Excel-Liste im Vorfeld saubere projiziert. Was ein Lenkungsausschuss tatsächlich kauft, wenn er „mehr Kapazität" für ein tatsächlich kaputtes Programm genehmigt, ist mehr vom selben Kontenrahmen, derselben CO-Struktur, derselben Konsolidierungslogik — weiter ausgebaut, auf demselben Fundament, das nicht schließt. Der Backlog schrumpft. Der Abschluss hält trotzdem nicht. Der nächste Statusbericht sieht einen Zyklus lang besser aus — und die beiden danach schlechter.

Die Alternative ist nicht automatisch „von vorne anfangen". Es ist eine definierte Diagnose, die klärt, bevor weitere Kapazität gebunden wird, ob das Fundament selbst geändert werden muss.

Was eine finance-geführte Diagnose tatsächlich prüft

Kontenrahmen und CO-Struktur — entworfen oder übernommen

Ein Kontenrahmen und eine Controlling-Struktur, die aus einer Vorlage, einem Vorgängersystem oder einer anderen Business Unit kopiert wurden, laufen — bis Profit-Center-Hierarchien, Umlagen und Margenanalyse eine echte Management-Frage beantworten müssen. Die Diagnose fragt, ob die Struktur für die Reporting-Realität dieser Gruppe entworfen wurde, oder übernommen und nie wieder überprüft.

Konsolidierung und RAR — hält der Konzernabschluss dem Audit stand

Group Reporting, Intercompany-Eliminierung, Währungsumrechnung und — wo Vertragsumsätze betroffen sind — RAR-Logik nach IFRS 15 / ASC 606 erzeugen entweder einen statutarischen Abschluss, der einer Audit-Prüfung standhält, oder sie tun es nicht. Genau hier zeigt sich meist, dass ein „verzögertes" Programm eigentlich „kaputt" ist: Die Einzelabschlüsse sehen sauber aus, und die Konzernzahl reconciliiert trotzdem nicht — aus Gründen, die niemand im Programm vollständig erklären kann.

Programm-Governance — eine verantwortliche Linie oder diffuse Vendor-Verantwortung

Ein Programm, in dem Finance, IT und der Implementierungspartner jeweils eine andere Erklärung dafür haben, warum der Abschluss nicht hält, ist ebenso ein Governance-Problem wie ein technisches. Teil der Diagnose ist zu klären, ob es eine durchgängige Verantwortungslinie vom CFO bis in die Finance-Workstreams gibt — oder ob „wer ist schuld" zu einem festen Tagesordnungspunkt geworden ist.

Die Fragen, die verzögert von kaputt unterscheiden

Ein strukturiertes Diagnosegespräch beantwortet in der Regel eine kleine Menge an Fragen, die zusammen belastbarer sind als jeder einzelne Statusbericht:

• Läuft der Periodenabschluss im System, oder hängt er von einem Excel-Flickwerk ab, das nur ein oder zwei Personen wirklich verstehen?
• Lassen sich Konsolidierungs- und RAR-Zahlen bis zur Quelltransaktion zurückverfolgen, ohne dass jemand die Logik aus dem Gedächtnis rekonstruieren muss?
• Hat die Beziehung zum Implementierungspartner das Vertrauen des CFO schon verloren, oder geht es bei der Reibung noch um Umfang und Zeitplan?
• Ist der aktuelle Backlog die eigentliche Restriktion, oder ist er ein Symptom einer früheren Design-Entscheidung, die nie überprüft wurde?

Ein Programm, das eine neue S/4-Implementierung im Standardumfang ohne diese Finance-Tiefe-Komplexität durchläuft, ist meist bei einem Standard-Implementierungspartner besser aufgehoben — Recovery ist ein anderes Gespräch für eine andere Situation, kein universelles Upgrade für reguläre Implementierungsarbeit.

Wie Stabilisierung aussieht, wenn die Diagnose „kaputt" ergibt

Ein Recovery-Mandat ist als definierte Intervention gerahmt, nicht als offene Aufstockung: eine Diagnose, ein realistisches, zwischen CFO, Programm und Anbietern abgestimmtes Re-Baseline, senior geführte Stabilisierung der FI-, CO-, Group- und RAR-Workstreams, bis der Abschluss tatsächlich hält, und eine bewusste Übergabe zurück an ein internes Team, sobald das der Fall ist. Der Exit ist von Anfang an Teil des Designs — kein nachträglicher Gedanke, sobald die Rechnungen nicht mehr gerechtfertigt aussehen.

Was das für einen CFO bedeutet, der um „mehr Kapazität" gebeten wird

Wenn ein Lenkungsausschuss das nächste Mal gebeten wird, mehr Zeit, mehr Budget oder mehr Personal für ein Programm zu genehmigen, das ständig Termine verpasst, lohnt sich zuerst nicht die Frage „wie viel mehr brauchen wir" — sondern die Frage, ob der Abschluss tatsächlich halten würde, wenn der aktuelle Plan exakt wie geschrieben fertiggestellt würde. Wenn die ehrliche Antwort Nein ist, sollte das folgende Gespräch über das Finance-Design gehen, nicht über die Personalstärke.