Ein Interview mit Frank Westendorf, Geschäftsführer Consileon Applied Business
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.
Herr Westendorf, die SAP S/4HANA Migration ist seit Jahren ein Thema. Viele CFOs und CIOs haben das Gefühl: Das wird schon wieder verschoben. Warum ist das immer noch so aktuell?
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.
Ist die SAP S/4HANA Migration eine Pflicht, weil SAP es so will, oder gibt es echte, eigene Gründe für Unternehmen?
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.
Sprechen wir über Zahlen: Sind das am Ende nur Kosten, oder gibt es einen nachweisbaren ROI?
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.
Man hört immer wieder, dass SAP-Projekte scheitern oder sich massiv verzögern. Was sind die wahren Ursachen?
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.
Was macht Consileon in SAP S/4HANA Migrationsprojekten anders?
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.
Was sind aus Ihrer Erfahrung die größten Herausforderungen bei der SAP S/4HANA Migration?
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.
Wie muss ein Team für die SAP S/4HANA Migration aufgestellt sein, damit das Projekt funktioniert?
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.
Wie lange dauert eine SAP S/4HANA Migration realistischerweise?
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.
Wie hoch ist das Risiko bei der SAP S/4HANA Migration, und was kann man konkret dagegen tun?
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.
Letzte Frage: Warum sollte ein CFO oder CIO die SAP S/4HANA Migration mit Consileon angehen und nicht mit einem der großen Systemintegratoren?
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.
