Die meisten S/4HANA-Business-Cases sind Fiktion – und das weiß das Management

Warum Business Cases in ERP-Projekten systematisch überschätzt werden

Es gibt mehrere Mechanismen, die zusammenwirken und Business Cases in die Höhe treiben – unabhängig von der Seriosität der Beteiligten.

Der erste ist strukturell: Business Cases in ERP-Projekten werden meistens erstellt, um eine Investitionsentscheidung zu begründen, nicht um sie zu hinterfragen. Das ist ein fundamentaler Unterschied. Wer mit dem Auftrag betraut wird, den Nutzen eines geplanten Projekts zu berechnen, produziert unter implizitem Druck eine Zahl, die das Projekt rechtfertigt. Das ist keine Lüge – aber es ist auch keine neutrale Analyse.

Der zweite Mechanismus ist methodischer Natur: Effizienzgewinne aus Prozessverbesserungen sind leicht zu schätzen und schwer zu realisieren. Der klassische Fall: „Durch S/4 reduzieren wir den manuellen Aufwand im Rechnungswesen um 30 Prozent.“ Das mag realistisch sein – aber es bedeutet nicht automatisch, dass 30 Prozent der Stellen eingespart werden. In der Realität verteilen sich die gewonnenen Stunden auf viele Mitarbeiter, die diese Zeit mit anderen Aufgaben füllen. Der Gewinn ist real, aber er ist unsichtbar in der GuV.

Drittens: Synergien, die von globalen Template-Rollouts erwartet werden, unterschätzen systematisch die Implementierungskosten von Abweichungen und die kulturelle Trägheit lokaler Organisationen. Ein globales Template, das für 80 Prozent der Länder passt und für 20 Prozent erhebliche Anpassungsarbeit erfordert, produziert Synergien – aber nicht in der Höhe, die ein vereinfachendes Modell verspricht.

Was das Management wirklich denkt

In vertraulichen Gesprächen bekennen viele CFOs und CEOs, dass sie den Business Cases für ihre ERP-Projekte nie vollständig geglaubt haben. Sie haben sie genehmigt, weil sie wussten, dass ein Wechsel auf S/4 mittelfristig keine Option ist – weil SAP den Support für ältere Systeme beendet, weil die Plattform veraltet ist, weil die technische Schuld wächst.

Das ist eine legitime Entscheidungsgrundlage. Aber sie ist eine andere als die, die im Business Case steht. Und dieser Unterschied hat Konsequenzen: Wenn das eigentliche Motiv „wir müssen, weil wir sonst veralten“ ist, aber das Rechtfertigungsdokument „wir werden deutlich effizienter und sparen 18 Millionen Euro“ sagt, dann entsteht ein Erwartungsgefälle, das sich nach dem Go-Live schmerzhaft bemerkbar macht.

Mitarbeiter, die gehört haben, dass das Projekt ihren Alltag vereinfachen wird, sind enttäuscht, wenn die ersten sechs Monate turbulent sind. Führungskräfte, die auf Nutzenzahlen angesprochen werden, die nie realisiert wurden, verlieren Vertrauen in Projektversprechen. Und das nächste Transformationsprojekt startet mit einem Vertrauensdefizit.

Wie ein Business Case aussieht, der ehrlich ist – und trotzdem funktioniert

Ehrliche Business Cases für S/4-Projekte bestehen aus drei Teilen, die klar voneinander getrennt werden.

Teil eins: Der Pflichtnutzen. Was passiert, wenn wir nicht migrieren? Steigende Wartungskosten, auslaufender Support, zunehmende Integration-Probleme, wachsende technische Schuld. Dieser Teil des Business Cases ist defensiv – aber er ist real und berechenbar. Viele Investitionsentscheidungen lassen sich allein damit rechtfertigen.

Teil zwei: Der wahrscheinliche Nutzen. Welche Effizienzgewinne sind realistisch, und wie werden sie konkret realisiert? Hier ist Präzision entscheidend. Nicht „wir sparen im Rechnungswesen 30 Prozent“, sondern: „Wir reduzieren die Bearbeitungszeit pro eingehender Rechnung von acht auf fünf Minuten. Das entspricht bei einem Volumen von 200.000 Rechnungen pro Jahr einer Kapazitätsreduktion von X Vollzeitstellen, die in Y realisiert werden.“ Dieses Niveau der Spezifikation ist unbequemer – aber es ist das einzige, das nach Go-Live überprüfbar ist.

Teil drei: Der mögliche Nutzen. Was wird möglich, wenn die neue Plattform steht? Bessere Echtzeitanalysen, neue Geschäftsmodelle, beschleunigte Abschlüsse, verbesserte Prognosefähigkeit. Dieser Teil sollte als Potenzial ausgewiesen werden, nicht als gesicherter Nutzen. Potenziale haben keine Eintrittswahrscheinlichkeit von 100 Prozent – und das sollte im Dokument stehen.

Nutzenrealisierung als eigenes Vorhaben führen

Der wichtigste Punkt ist struktureller Natur: Nutzenrealisierung passiert nicht automatisch. Sie muss geführt werden.

Das bedeutet konkret: Für jeden Nutzen im Business Case gibt es eine verantwortliche Führungskraft – nicht im Projekt, sondern in der Linie. Diese Person verpflichtet sich auf ein Ziel und einen Zeitplan. Sie bekommt ein Budget, wenn Investitionen nötig sind, und sie reportet quartalsweise an den CFO oder COO, was realisiert wurde und was nicht.

Kein einziges Unternehmen, das diesen Mechanismus nicht hat, realisiert seinen Business Case vollständig. Das ist keine Einschätzung – das ist eine Beobachtung aus Dutzenden von Projekten.

Ein Konsumgüterunternehmen hat das konsequent umgesetzt: Sechs Monate vor Go-Live wurde ein „Value Realization Board“ eingerichtet, das unabhängig vom Projektsteuerkreis operierte. Zwölf Nutzeninhaber aus der Linie, quartalsweises Review, direktes Reporting an den CFO. Zwei Jahre nach Go-Live waren 71 Prozent des geplanten Nutzens realisiert. Für ERP-Projekte ist das eine außergewöhnliche Quote – der Industriedurchschnitt liegt deutlich darunter.