Wenn S/4HANA-Projekte scheitern, liegt es selten an der Technik. Datenmodelle stehen, Schnittstellen laufen, das Customizing ist sauber dokumentiert – und trotzdem herrscht nach dem Go-Live Unzufriedenheit auf allen Seiten. Das Projekt gilt technisch als Erfolg und wird von den Menschen, die täglich damit arbeiten sollen, dennoch als Misserfolg empfunden. Genau hier liegt eine der größten, aber am meisten unterschätzten Herausforderungen einer S/4HANA-Transformation: die Akzeptanz der Anwender:innen. Dieser Beitrag zeigt am Beispiel der Finanzbuchhaltung, wie sich der Faktor Mensch bei der S/4HANA-Transformation über den gesamten Projektverlauf aufbauen und messen lässt.
Auf einen Blick
- Entscheidend für den Projekterfolg ist nicht nur, ob das System läuft, sondern ob die Anwender:innen es annehmen.
- Vier Ursachen stehen meist dahinter: fehlendes „Warum“, späte und generische Schulungen, spät eingebundene Key User:innen und eine ungewohnte UX.
- Change Management gehört von Anfang an in den Projektplan – mit eigenen Zielgruppen, Phasen und Messgrößen.
- Im Rechnungswesen genügt es nicht, Bedienabläufe zu schulen: Anwender:innen müssen das neue Datenmodell verstehen.
Warum Akzeptanz so oft übersehen wird
In den meisten Projektplänen dominiert die technische Perspektive: Prozessdesign, Customizing, Datenmigration, Testphasen. Change Management taucht zwar meist irgendwo im Projektplan auf, aber oft erst spät. Mit knappem Budget und als bloße Formalität, statt als eigenständiger Erfolgsfaktor.
Die Folgen zeigen sich meist erst nach dem Go-Live, wenn es eigentlich zu spät ist:
- Anwender:innen pflegen weiterhin ihre gewohnten Excel-Listen parallel zum System.
- Die neue Fiori-Oberfläche wird als Belastung empfunden, nicht als Erleichterung.
- Alte Gewohnheiten und Workarounds aus dem Altsystem bleiben bestehen.
- Der Support wird mit Rückfragen überlastet, die eigentlich Schulungsthemen wären.
Das Muster ist fast immer dasselbe: Die Technik war bereit, die Menschen nicht. Darum ist der Faktor Mensch bei der S/4HANA-Transformation unumgänglich.
Die eigentlichen Ursachen
Wer genauer hinschaut, findet meist eine Kombination aus vier Faktoren:
Fehlende Kommunikation des „Warum“
Anwender:innen wissen oft, dass sich etwas ändert, wissen aber nicht warum. Ohne ein nachvollziehbares „Warum“ bleibt jede Umstellung eine von oben verordnete Maßnahme statt einer sinnvollen Weiterentwicklung.
Schulungen zu spät und zu generisch
Häufig finden Schulungen kurz vor dem Go-Live statt, oft einheitlich für alle unabhängig von der Rolle und dem Vorwissen. Einkäufer:innen brauchen andere Inhalte als Buchhalter:innen in der Anlagenbuchhaltung.
Fehlende Einbindung der Key User:innen
Wenn Fachbereiche erst am Ende des Projekts eingebunden werden, fehlt ihnen die Zeit, sich das System zu eigen zu machen und damit auch die Rolle als glaubwürdige Multiplikatoren im Team.
Ungewohnte UX ohne Gewöhnungsphase
Der Wechsel von klassischem SAP GUI zu Fiori ist für viele Anwender:innen ein grundlegender Umstieg und nicht nur ein optischer Wechsel. Ohne ausreichend Zeit für die Eingewöhnung wird aus einer moderneren Oberfläche schnell ein wahrgenommener Rückschritt.
Was sich für Anwender:innen in der Finanzbuchhaltung konkret ändert
Wie groß der Umstieg tatsächlich ist, zeigt ein Blick in die Finanzbuchhaltung. Die neue Oberfläche ist hier nur die sichtbarste Veränderung. Darunter verschiebt sich das Datenmodell, und mit ihm das Verständnis dafür, wo die Zahlen eigentlich herkommen.
| Bereich | Was sich ändert | Was Anwender:innen verstehen müssen |
| Stammdaten | Debitoren und Kreditoren werden im Business Partner zusammengeführt, statt in getrennten Transaktionen gepflegt zu werden. | Es gibt einen gemeinsamen Einstieg mit anderen Rollen und Sichten. |
| Belegdaten | Finanzwesen und Controlling buchen auf dieselbe Belegbasis. Abstimmbuchungen und die klassische FI/CO-Abstimmung entfallen weitgehend, Kostenarten werden als Sachkonten geführt. | Welche gewohnten Abstimm- und Kontrollschritte wegfallen, welche bleiben und wo Kostenarten jetzt gepflegt werden. |
| Anlagenbuchhaltung | Die Anlagenbuchhaltung ist in das Hauptbuch integriert: Anlagenbewegungen und Abschreibungen werden direkt im Universal Journal abgebildet, parallele Bewertungen laufen über Ledger. | Warum Anlagen- und Hauptbuchwerte nicht mehr getrennt abgestimmt werden müssen und wie die Bewertungsbereiche den Ledgern zugeordnet sind. |
| Buchungserfassung | Klassische Transaktionen und Fiori-Apps stehen teilweise nebeneinander zur Verfügung. | Welcher Weg für welche Buchung im Projekt verbindlich vorgesehen ist, damit die Abläufe einheitlich bleiben. |
| Auswertungen | Listen und Berichte laufen über neue Apps oder liefern andere Sichten auf dieselben Daten. | Wo die gewohnte Liste jetzt zu finden ist und warum Summen anders aussehen können. |
So geht man mit den Änderungen um
Wer diese Veränderungen nicht erklärt, bekommt nach dem Go-Live genau die Rückfragen, die der Support nicht immer beantworten kann: „Wo finde ich jetzt meine Liste?“ und „Warum stimmt die Summe nicht mehr mit meiner Excel-Auswertung überein?“
Gerade im Rechnungswesen ist das heikel, weil Anwender:innen ihre Ergebnisse gegenüber Abschlussprüfern und Fachbereichen verantworten müssen. Hier genügt es nicht, Bedienabläufe zu schulen. Die Anwender:innen müssen verstehen, warum ein Ergebnis so zustande kommt, wie es im neuen System ausgewiesen wird.
Umgekehrt zahlt sich eine gute Vorbereitung unmittelbar aus. Wer die Anwender:innen vor dem Go-Live gezielt vorbereitet, entlastet den Support genau dort, wo er sonst am stärksten belastet wird: Orientierungsfragen werden bereits in der Schulung, in Kurzanleitungen oder durch die Key User:innen im Fachbereich beantwortet und entstehen gar nicht erst als Tickets. Der Support kann sich auf echte Störungen und Fehler konzentrieren, die Hypercare-Phase bleibt beherrschbar und die Anwender:innen erleben das neue System von Anfang an als verlässlich statt als Hürde.
Was erfolgreiches Change Management ausmacht
Die gute Nachricht: Diese Probleme sind vermeidbar, wenn Change Management von Anfang an fest zum Projekt gehört und nicht erst am Ende in das Projektgeschehen eingreift.
| Ursache des Scheiterns | Gegenmaßnahme | Wirkung |
| Fehlendes „Warum“ | Transparent kommunizieren. Nutzen, Zeitplan und Auswirkungen auf den Arbeitsalltag frühzeitig und ehrlich vermitteln – auch unangenehme Punkte gehören dazu. | Die Umstellung wird als sinnvolle Weiterentwicklung verstanden. |
| Schulungen zu spät und zu generisch | Rollenbasiert schulen. Inhalte an den tatsächlichen Tätigkeiten der Anwender:innen orientieren, nicht an einer allgemeinen Systemeinführung. | Schulungen sind für die jeweilige Rolle relevant. |
| Fehlende Einbindung der Key User:innen | Key User:innen früh einbinden. Sie kennen die Fachbereiche, ihre Sprache und ihre Sorgen. | Key User:innen werden zu glaubwürdigen Botschaftern im Team statt zu Tester:innen kurz vor dem Go-Live. |
| Ungewohnte UX ohne Gewöhnungsphase | Feedbackschleifen und Hypercare einplanen. Nach dem Go-Live Rückmeldungen ernst nehmen und schnell in Anpassungen oder Nachschulungen übersetzen. | Die Gewöhnung an die neue Oberfläche wird begleitet. |
Wer braucht was? Die Stakeholder-Gruppen im Überblick
Diese Maßnahmen wirken nur, wenn man die Zielgruppen unterscheidet. Nicht jede:r im Unternehmen braucht dieselbe Information zur selben Zeit:
| Zielgruppe | Was sie brauchen |
| Management und Projektsponsor | Das „Warum“ sichtbar vorleben und Schulungs- sowie Key-User-Zeiten ausdrücklich absichern, damit sie bei engem Zeitplan nicht als Erstes entfallen. |
| Key User:innen | Freiraum im Tagesgeschäft, frühen Systemzugang und das Mandat, Rückmeldungen ins Projekt zu tragen. |
| Endanwender:innen | Informationen dazu, was sich für ihre konkrete Arbeit ändert – in ihrer Sprache und nicht im Projektjargon. |
| Support und IT | Kenntnis der typischen Fragen, bevor sie gestellt werden, und klare Wege, um Fachfragen weiterzureichen. |
Change Management entlang der Projektphasen
Statt einer einzelnen Schulungswoche vor dem Go-Live empfiehlt sich ein Rhythmus über das gesamte Projekt. So wird aus Change Management ein durchgängiger Strang, der parallel zur technischen Umsetzung läuft:
| Projektphase | Fokus | Konkrete Maßnahmen |
| Vorbereitung | Zielbild und Zielgruppen | Zielbild und Nutzen klären, Stakeholder identifizieren, Key User:innen benennen und für ihre Projektarbeit freistellen. |
| Konzeption | Auswirkungen erfassen | Key User:innen in Workshops einbinden und die Auswirkungen auf Rollen und Abläufe systematisch sammeln. |
| Realisierung | Lernen vorbereiten | Das Schulungskonzept rollenbasiert aufsetzen und die Testphasen als Lernphasen nutzen, nicht nur als Abnahme. |
| Go-Live-Vorbereitung | Anwender:innen befähigen | Schulungen durchführen, die Kommunikation verdichten und Support-Strukturen bereitstellen. |
| Betrieb und Hypercare | Verankern | Rückmeldungen auswerten, Nachschulungen anbieten und erste Erfolge sichtbar machen. |
Typische Widerstände und wie man ihnen begegnet
Auch bei guter Planung wird es Widerstand geben. Das ist kein Zeichen von Böswilligkeit, sondern meist ein Hinweis auf eine Lücke im Konzept:
| Typische Aussage | Was dahintersteckt | Was hilft |
| „Das hat früher besser funktioniert.“ | Vertraute Abläufe gehen verloren, und Neues wirkt teilweise aufwendiger. | Vor dem Go-Live offen benennen, was im neuen System anders und teilweise auch aufwendiger ist, statt nur Vorteile zu betonen. |
| „Dafür habe ich keine Zeit.“ | Schulung und Test konkurrieren mit dem Tagesgeschäft. | Schulungs- und Testzeiten vom Management ausdrücklich freigeben und in die Kapazitätsplanung aufnehmen. |
| „Ich frage lieber meinen Kolleg:innen.“ | Es fehlen Schulungsunterlagen oder feste Anlaufstellen. | Kurzanleitungen und feste Sprechstunden in den ersten Wochen bereitstellen. |
Woran man Akzeptanz messen kann
Akzeptanz wirkt oft wie ein weiches Thema, lässt sich aber überraschend gut greifbar machen. Mögliche Indikatoren sind:
| Indikator | Was er zeigt | Wann erheben |
| Anzahl und Art der Support-Tickets | Handelt es sich um Schulungsfragen oder um echte Fehler? | Während der Testphasen |
| Teilnahmequote und Feedback zu den Schulungen | Ob die Schulungen die Anwender:innen erreichen und wie hilfreich sie sind. | Nach jeder Schulung |
| Nutzung der neuen Apps und Transaktionen im Vergleich zu Workarounds | Ob das neue System tatsächlich genutzt wird. | Laufend ab Go-Live |
| Stimmungsbild der Key User:innen | Frühindikator für die Akzeptanz im Team. | In regelmäßigen Kurzumfragen |
Wer diese Werte früh erhebt, kann gegensteuern, bevor sich Workarounds verfestigen.
Fazit
S/4HANA-Projekte scheitern selten an der Technik – sie scheitern an der Distanz zwischen System und Mensch. Der Faktor Mensch bei der S/4HANA-Transformation spielt eine entscheidende Rolle. Wer Change Management nicht als Pflichtaufgabe, sondern als integralen Projektbestandteil versteht, schafft die Basis dafür, dass eine technisch erfolgreiche Transformation auch von den Menschen im Unternehmen als Erfolg erlebt wird.
Fünf Fragen, die sich jedes S/4HANA-Projektteam stellen sollte:
- Wissen unsere Anwender:innen, warum wir diese Transformation machen?
- Sind unsere Key User:innen von Anfang an eingebunden, oder erst kurz vor Go-Live?
- Sind unsere Schulungen rollenspezifisch oder für alle identisch?
- Haben wir genug Zeit für die Gewöhnung an die neue UX eingeplant?
- Gibt es eine echte Hypercare-Phase nach dem Go-Live, oder endet das Projekt mit dem Go-Live-Datum?
adesso business consulting: Wir begleiten Ihre Transformation
Eine S/4HANA-Transformation gelingt, wenn Technik und Menschen zusammenkommen. Als adesso business consulting unterstützen wir Unternehmen bei ihren Transformationen und setzen unsere Erfahrung im Change Management gerne dafür ein, dass Ihr Projekt nicht nur technisch, sondern auch bei den Anwender:innen ein Erfolg wird. Gemeinsam legen wir einen Fokus auf den Faktor Mensch bei der S/4HANA-Transformation.
Sprechen Sie uns an. Wir freuen uns darauf, gemeinsam mit Ihnen die Menschen im Unternehmen für Ihre S/4HANA-Transformation zu gewinnen.
