Frank Westendorf ist seit über 30 Jahren in der SAP-Welt zuhause, zunächst als Entwickler und Teamleiter beim Hersteller selbst, später als Berater und seit 2019 als Geschäftsführer der Consileon Applied Business GmbH. Im Interview spricht er offen über die häufigsten Fehler bei SAP S/4HANA-Migrationsprojekten, warum Transformationen trotz jahrelanger Ankündigung immer noch scheitern und was Unternehmen tun können, um es besser zu machen.
Das Gefühl kann ich gut verstehen, und ich höre es regelmäßig. SAP hat die Deadlines tatsächlich mehrfach nach hinten geschoben: erst 2025, dann 2027, inzwischen gibt es mit der Extended Maintenance eine Option bis 2030. Das hat viele Unternehmen in eine gefährliche Komfortzone gewiegt.
Aber die Situation hat sich fundamental verändert. Der Mainstream-Support für SAP ECC endet Ende 2027. Das ist ein harter Schnitt. Danach gibt es keine Sicherheits-Updates mehr, keine neuen gesetzlichen Anforderungen werden eingespielt, keine regulatorischen Anpassungen. Wer bis 2030 weitermachen will, zahlt für die Extended Maintenance extra und läuft trotzdem auf einer Plattform ohne Weiterentwicklung.
Hinzu kommt ein praktisches Problem, das viele unterschätzen: SAP S/4HANA Migrationsprojekte dauern in der Realität deutlich länger als geplant. Die Horváth-Studie aus dem ersten Quartal 2025, für die 200 SAP-Anwenderunternehmen befragt wurden, zeigt: Im Durchschnitt dauern Projekte 30 Prozent länger als geplant. Nur 8 Prozent der Unternehmen, die die Migration abgeschlossen haben, lagen im Zeitplan. Wer 2026 noch nicht ernsthaft mit der Planung begonnen hat, hat ein reales Fristproblem.
Beides ist wahr, aber ich würde die Reihenfolge umdrehen. Das Support-Ende erzeugt natürlich Druck. Aber wer die SAP S/4HANA Migration nur als Compliance-Übung betrachtet, weil SAP es verlangt, macht einen grundlegenden Fehler. Er wird viel Geld ausgeben und wenig zurückbekommen.
S/4HANA ist eine fundamental andere Architektur. Das Universal Journal zum Beispiel: Statt vieler getrennter Nebenbücher gibt es eine einzige Datentabelle für alle Finanztransaktionen. Das klingt technisch, hat aber konkrete Auswirkungen. Periodenabschlüsse, die früher Tage gedauert haben, können in Stunden erledigt werden. Echtzeit-Auswertungen, die bisher einen separaten BI-Stack erforderten, laufen direkt im System.
Was mich in der Beratung wirklich begeistert: S/4HANA öffnet die Tür für KI-Anwendungen, die auf SAP ECC schlicht nicht möglich waren. Automatisierte Rechnungsprüfung, prädiktive Cashflow-Analysen, intelligente Abweichungserkennung in der Kreditorenbuchhaltung: Das sind keine Zukunftsvisionen, das setzen wir heute in Projekten um. Wer die SAP S/4HANA Migration nur als Pflichtübung abarbeitet und seine Prozesse eins zu eins kopiert, verspielt diese Chance.
Die ehrliche Antwort ist: Es kommt darauf an, wie man die SAP S/4HANA Migration angeht. Wer einen reinen Lift-and-Shift macht, also das alte System technisch umzieht, ohne Prozesse anzufassen, wird keinen überzeugenden ROI nachweisen können. Die Kosten sind real, der Nutzen bleibt gering.
Wer die Migration aber als Transformationsprojekt begreift, sieht ein anderes Bild. Konkret: Viele unserer Kunden im FiBu-Umfeld haben nach der SAP S/4HANA Migration ihren Periodenabschluss um 40 bis 60 Prozent beschleunigt. Manuelle Abstimmungsaufwände in der Hauptbuchhaltung sinken erheblich, weil das Universal Journal viele der alten Übertragungs- und Abstimmungsschritte überflüssig macht. Die Integration von KI in Folgeprozesse, etwa in der Rechnungsverarbeitung, bringt weitere Effizienzgewinne.
Für den CFO ist noch ein anderer Aspekt relevant: Ein ECC-System, das nicht mehr gewartet wird, ist ein operatives Risiko. Fehlende Sicherheitsupdates, keine Unterstützung bei gesetzlichen Änderungen: Das kann teuer werden. Die Alternative „nichts tun“ hat also auch einen Preis, der in der ROI-Berechnung oft vergessen wird.
Das ist wahrscheinlich die Frage, mit der ich am häufigsten konfrontiert bin, und bei der ich am direktesten antworten kann, weil ich die Muster über viele Projekte hinweg kenne.
Der größte Fehler: Die SAP S/4HANA Migration wird als IT-Projekt behandelt. Der CIO ist verantwortlich, die Fachabteilungen sind Zulieferer. Das scheitert regelmäßig. S/4HANA-Migrationen sind Transformationsprojekte. Sie verändern, wie Finanzbuchhaltung, Controlling, Einkauf und Logistik arbeiten. Wenn der CFO nicht aktiv mitgestaltet und die Fachabteilungen nicht von Beginn an eingebunden sind, entstehen Lösungen, die technisch funktionieren, aber operativ nicht funktionieren.
Der zweite klassische Fehler: unterschätzte Datenkomplexität. Viele Unternehmen haben über 15 oder 20 Jahre ihr SAP-System individuell angepasst: eigene Transaktionen, eigene Reports, gewachsene Schnittstellen. Diese technische Schuld verschwindet nicht durch eine Migration. Sie muss bewusst aufgelöst oder bewusst übernommen werden. Wer das nicht vorher analysiert, erlebt böse Überraschungen in der Testphase.
Und dann ist da die Governance. ISG hat in einer Studie festgestellt, dass viele Projekte an unklaren Entscheidungsrechten scheitern: zu viele Beteiligte, zu wenig klare Verantwortung, Entscheidungen werden verschleppt. Das ist kein technisches Problem, das ist ein Führungsproblem.
Ich fange mit dem Offensichtlichsten an: Ich bin seit 1994 in der SAP-Welt, davon 12 Jahre beim Hersteller selbst, zunächst als Entwickler, dann als Teamleiter. Das bedeutet, ich verstehe SAP nicht nur als Berater von außen, sondern kenne die Architektur, die Designentscheidungen und die Schwachstellen von innen. Das ist ein echter Unterschied in der Projektkommunikation, mit SAP und auch mit dem Kunden.
Was uns darüber hinaus unterscheidet: Wir kommen bei vielen Kunden über den laufenden Betrieb. Wir übernehmen erst die Wartung und Administration des bestehenden Systems, lernen es wirklich kennen: die individuellen Anpassungen, die gewachsenen Prozesse, die neuralgischen Punkte. Wenn wir dann in eine SAP S/4HANA Migrationsdiskussion einsteigen, reden wir nicht über ein System, das wir aus Dokumenten kennen, sondern eines, das wir von innen kennen. Das reduziert Überraschungen erheblich.
Und wir machen Prozessmodellierung vor der Migration zur Pflicht, nicht zur Option. Bevor wir ein einziges Byte migrieren, verstehen wir gemeinsam mit dem Kunden, wie seine FiBu- und Controlling-Prozesse heute laufen und wie sie nach der SAP S/4HANA Migration laufen sollen. Das kostet am Anfang Zeit, spart sie aber vielfach später.
Drei Dinge, die ich immer wieder erlebe.
Erstens der Umfang des Customizings. Deutsche Unternehmen haben historisch stark in individuelle SAP-Anpassungen investiert: steuerrechtliche Besonderheiten, branchenspezifische Anforderungen, interne Prozesslogiken. Im Krankenhaus kommt beispielsweise die KHBV hinzu, die eigene Buchführungsanforderungen mitbringt, die sich von handelsrechtlichen Regelungen teils erheblich unterscheiden. All das muss analysiert, bewertet und in der SAP S/4HANA Migration berücksichtigt werden.
Zweitens: Datenmigration und Datenqualität. Das wird systematisch unterschätzt. Ein Migrationstool, das die Datenbank technisch überführt, gibt es. Aber saubere, konsistente, vollständige Stammdaten sind Vorarbeit, die Monate dauern kann und intensive Zusammenarbeit zwischen IT und Fachbereich erfordert.
Drittens: Change Management. Menschen müssen mit einem neuen System arbeiten, anders als bisher. Wenn die Anwenderseite nicht mitgenommen wird, passiert Folgendes: Das System ist technisch live, aber die Mitarbeiter arbeiten mit Workarounds, pflegen Excel-Listen parallel und rufen im Helpdesk an. Das ist teuer und frustrierend. Wir investieren deshalb bewusst in Schulung und Begleitung der Anwender, nicht als Pflichtprogramm am Ende, sondern als Teil des Projekts von Beginn an.
Die entscheidende Erkenntnis zuerst: Eine SAP S/4HANA Migration kann nicht allein von der IT geführt werden. Es braucht zwingend Führung aus den Fachbereichen und Rückendeckung von ganz oben.
Auf Kundenseite brauche ich einen Projektleiter, der Mandat hat und Entscheidungen treffen kann, ohne sechs Eskalationsstufen durchlaufen zu müssen. Ich brauche Key User aus FiBu und Controlling, die den Ist-Prozess wirklich kennen und die Soll-Prozesse mitgestalten. Und ich brauche IT-Kompetenz, die versteht, welche Systemlandschaft vorhanden ist und wohin wir wollen.
Auf unserer Seite stellen wir gemischte Teams auf: Fachberater mit tiefer FICO-Kenntnis, technische Berater für Systemkonversion und Datenmigration sowie einen Projektmanager, der die Steuerung übernimmt. Was wir nicht machen: ein riesiges Team aufstellen, das Kapazität signalisiert, aber in dem keiner das Projekt wirklich durch und durch kennt. Wir arbeiten mit überschaubaren, verantwortlichen Teams.
Und ein Punkt, der oft unterschätzt wird: Der Übergang von der Testphase zum Go-live. Genau in dieser Phase muss das Gesamtteam aus Kunde und Berater wirklich funktionieren. Das ist kein Moment für Zuständigkeitsdebatten.
Ich gebe Ihnen eine ehrliche Antwort, keine Marketing-Antwort.
Für ein mittelständisches Unternehmen mit einer überschaubaren SAP-Landschaft, wenig individuellem Customizing und gut vorbereiteten Daten: 12 bis 18 Monate von der Prozessmodellierung bis zum Go-live. Das ist das untere Ende, und es setzt voraus, dass die Entscheidungen auf Kundenseite zügig getroffen werden.
Für Organisationen mit komplexeren Systemlandschaften, etwa Krankenhausverbünde, die mehrere Häuser zusammenführen, oder Industrieunternehmen mit vielen individuellen Anpassungen und Schnittstellen, können das 24 bis 36 Monate sein, manchmal mehr. SAP S/4HANA Migrationsprojekte in diesem Umfang laufen oft in Wellen: erst ein Kernprozess oder Standort, dann weitere.
Was die Horváth-Studie zeigt und was ich aus der Praxis bestätigen kann: Die meisten Projekte planen zu optimistisch. Der realistische Puffer liegt bei 20 bis 30 Prozent auf der Gesamtlaufzeit. Wer das nicht einrechnet, gerät unter Druck und trifft in der Endphase schlechte Entscheidungen.
Deshalb mein klarer Rat: Wer bis Ende 2027 fertig sein will, muss jetzt starten. Nicht in sechs Monaten, jetzt.
Das Risiko ist real. Ich wäre nicht ehrlich, wenn ich das kleinreden würde. Die Zahlen sprechen eine klare Sprache: Laut Horváth-Studie 2025 haben mehr als 60 Prozent der Unternehmen bei ihrer SAP S/4HANA Migration Budget, Zeitplan oder Qualitätsziele verfehlt. 65 Prozent stellen nach der Migration erhebliche Qualitätsmängel fest.
Aber diese Risiken sind nicht schicksalhaft. Sie entstehen aus bekannten, vermeidbaren Fehlern. Und wer das weiß, kann gegensteuern.
Was Risiko bei der SAP S/4HANA Migration wirklich reduziert: Erstens eine ehrliche Bestandsaufnahme vor Projektstart. Wie komplex ist die aktuelle Systemlandschaft wirklich? Wie sauber sind die Daten? Welche individuellen Anpassungen gibt es, und welche davon werden tatsächlich noch gebraucht? Zweitens klare Projektsteuerung mit echten Entscheidungskompetenzen, nicht Komitees, die Empfehlungen aussprechen, sondern Menschen, die entscheiden können. Drittens ausreichend Zeit für Test und Datenmigration: Das ist der am häufigsten unterschätzte Teil des gesamten Projekts.
Was wir bei Consileon explizit tun: Wir machen vor der eigentlichen SAP S/4HANA Migration eine Prozess- und Systemanalyse. Wir wissen, worauf wir uns einlassen, bevor wir starten. Und wir empfehlen lieber einen phasenweisen Ansatz, erst den Kernprozess, dann ausbauen, als den Big-Bang, der alles auf einmal umstellt. Das Risiko ist beherrschbarer, die Lernkurve steiler, und der erste Go-live-Erfolg motiviert das gesamte Team für das, was noch kommt.
Ich sage das ohne Überheblichkeit: Die großen Integratoren haben ihre Stärken. Wenn Sie ein Konzernprojekt mit 50 Standorten weltweit stemmen müssen, brauchen Sie entsprechende Kapazitäten.
Aber was ich in der Praxis immer wieder erlebe: Große Teams sind keine Garantie für gute Ergebnisse. Im Gegenteil: Je mehr Beteiligte, desto diffuser wird oft die Verantwortung. Die ISG-Studie hat das auf den Punkt gebracht: Viele SAP S/4HANA Migrationsprojekte scheitern nicht an fehlender Kompetenz, sondern an unklaren Entscheidungsrechten und fehlenden Verantwortlichkeiten zwischen zu vielen Beteiligten.
Was wir bieten: Tiefe statt Breite. Ein überschaubares, erfahrenes Team, das Ihr Projekt wirklich kennt, von der Prozessanalyse bis zum Go-live. Direkte Kommunikation, kurze Entscheidungswege. Und einen Berater, der Ihre SAP-Landschaft nicht nur aus der Projektdokumentation kennt, sondern im besten Fall schon aus dem laufenden Betrieb.
Dazu kommt: Wir sind SAP Silver Partner mit zertifizierter Kompetenz, aber wir sind kein verlängerter Arm von SAP. Wir sagen Ihnen auch, wo der SAP-Standard sinnvoll ist und wo individuelle Lösungen mehr bringen. Dieses unabhängige Urteil ist in einer SAP S/4HANA Migration, die viele Jahre Ihres Unternehmens prägen wird, viel wert.
Stellen Sie sich vor, Ihr Finanzteam könnte dem eigenen ERP-System eine Frage stellen wie einem erfahrenen Kollegen: „Zeig mir die Ausreißer im Cashflow der letzten 90 Tage und erkläre, woher die Abweichungen kommen.“ Und das System antwortet in natürlicher Sprache, sofort, mit den richtigen Zahlen aus dem laufenden Betrieb.
Das ist kein Zukunftsszenario. SAP hat im vierten Quartal 2025 rollenbasierte KI-Assistenten in SAP Joule eingeführt, darunter einen explizit für Finanzmanager. Controlling, Cashflow-Prognose, Verrechnungslaufergebnisse: SAP Joule im Finanzwesen ist keine Spielerei mehr, sondern produktive Software, die in S/4HANA-Umgebungen heute eingesetzt wird.
Für viele CFOs und CIOs ist das eine gute Nachricht. Und gleichzeitig eine unbequeme: Denn wer SAP Joule im Finanzwesen nutzen will, muss eine Voraussetzung erfüllen, die nicht jedes Unternehmen heute hat.
SAP Joule ist der generative KI-Assistent von SAP, direkt in die SAP-Produktlandschaft eingebettet. Im Finanzbereich bedeutet das: Joule greift auf Echtzeitdaten im System zu, versteht den betriebswirtschaftlichen Kontext und kann in natürlicher Sprache mit Controllern, Buchhaltern und Finanzmanagern interagieren.
Im vierten Quartal 2025 hat SAP konkrete Funktionen für das Finanzwesen ausgerollt. Business-Analysten und Controller erhalten einen direkten Überblick über Verrechnungslaufergebnisse per Joule-Funktion. Finanzmanager können Cashflow-Prognosen mit KI-Unterstützung erstellen, ohne separate BI-Tools aufzurufen. Seit dem ersten Quartal 2026 ist zudem der Joule Studio Agent Builder allgemein verfügbar, mit dem Unternehmen eigene Joule-Agenten für ihre spezifischen Finanzprozesse entwickeln können.
Das ist ein Qualitätssprung gegenüber dem, was bisher unter KI im SAP-Umfeld verstanden wurde. Keine isolierten Add-ons, keine externe KI-Plattform, die an SAP andockt. Joule ist in S/4HANA integriert, arbeitet mit den echten Unternehmensdaten und hält dabei Rollen und Berechtigungen ein.
Hier liegt das Problem, das in vielen CFO-Gesprächen noch zu wenig Raum findet: SAP Joule im Finanzwesen entfaltet seinen Nutzen nur dann, wenn die Datenbasis stimmt. Und die Datenbasis stimmt nur dann, wenn das Unternehmen auf S/4HANA migriert ist und seine Prozesse und Datenstrukturen dabei sauber aufgeräumt hat.
Wer noch auf SAP ECC läuft, hat keinen Zugang zu Joule. Die KI-Funktionen sind exklusiv für die S/4HANA-Plattform. Das klingt nach einem Detail, ist aber für die aktuelle Lage im Markt hochrelevant: Laut der Horváth-Studie aus dem ersten Quartal 2025 haben von 200 befragten SAP-Anwenderunternehmen erst 37 die Migration abgeschlossen. Die große Mehrheit läuft noch auf Altsystemen.
Hinzu kommt ein Qualitätsproblem, das unabhängig von der Migrationsplattform existiert: Viele Unternehmen haben über Jahre hinweg historisch gewachsene Datenstrukturen, inkonsistente Stammdaten und individuell angepasste Prozesse. Eine KI, die auf dieser Basis arbeitet, produziert unzuverlässige Ergebnisse. Garbage in, garbage out, nur schneller.
Das bedeutet: Wer SAP Joule im Finanzwesen wirklich nutzen will, muss zwei Dinge sicherstellen. Erstens die technische Migration auf S/4HANA. Zweitens die Prozess- und Datenqualität, die diese Migration idealerweise mitbringt, wenn sie als Transformationsprojekt und nicht als reiner technischer Umzug angegangen wird.
Die gute Nachricht: Beides ist planbar. Die schlechte Nachricht: Beides braucht Zeit, mehr als viele CFOs und CIOs heute einplanen.
SAP S/4HANA Migrationsprojekte dauern in der Praxis 12 bis 36 Monate, je nach Komplexität der Systemlandschaft. Der Mainstream-Support für SAP ECC endet Ende 2027. Wer also bis zur Deadline auf S/4HANA sein und gleichzeitig die Voraussetzungen für sinnvolle KI-Nutzung wie SAP Joule im Finanzwesen schaffen will, muss jetzt mit der ernsthaften Planung beginnen, nicht in sechs Monaten.
Drei Dinge sollten dabei von Anfang an mitgedacht werden. Erstens die Datenstrategie: Welche Stammdaten müssen bereinigt werden? Welche Strukturen entstehen im neuen System, die Joule später sinnvoll nutzen kann? Zweitens die Prozessmodellierung: Welche Finanzprozesse sollen nach der Migration KI-gestützt laufen? Diese Antwort beeinflusst, wie das S/4HANA-System konfiguriert wird. Drittens die Rollendefinition: Joule arbeitet rollenbasiert. Wer darf was sehen und steuern? Berechtigungskonzepte müssen von Beginn an mitgedacht werden.
Wer diese drei Punkte erst nach dem Go-live klärt, verschenkt einen erheblichen Teil des Potenzials, das die Migration eigentlich freisetzen sollte.
SAP Joule im Finanzwesen ist kein Versprechen mehr, das irgendwann eingelöst wird. Es ist ein verfügbares Werkzeug, das heute in produktiven S/4HANA-Umgebungen eingesetzt wird und konkrete Effizienzgewinne in Controlling und Rechnungswesen bringt.
Aber es ist kein Werkzeug, das man einfach einschaltet. Es setzt eine Plattform und eine Datenqualität voraus, die sich Unternehmen im Rahmen einer durchdachten S/4HANA-Migration erarbeiten müssen. Die Frage ist also nicht: Wollen wir KI im Finanzwesen? Die Frage ist: Schaffen wir jetzt die Grundlage dafür?
Wer diese Frage zu lange aufschiebt, wird 2027 nicht nur ohne modernen SAP-Support dastehen, sondern auch ohne die KI-Fähigkeiten, die Wettbewerber dann bereits produktiv nutzen.
Mehr zur S/4HANA-Migration und zu den Voraussetzungen für KI-gestützte Finanzprozesse lesen Sie auf unserer Seite zur SAP FICO Beratung. Wie eine durchdachte Migration konkret aussieht, erklärt Frank Westendorf im Interview zur S/4HANA-Migration.