Projektteamschulung: Ein X-Faktor im S/4-Projekt

Stell dir vor, ein SAP S/4HANA-Projekt geht in die Konzeptionsphase. Die Workshops starten, erste Prozesse sollen im neuen System abgebildet werden. IT und Fachbereich sitzen zusammen – und sprechen aneinander vorbei.

Der eine spricht von Fiori-Apps, der andere von Excel-Auswertungen. Begriffe wie "Embedded Analytics", "Business Partner" oder "Universal Journal" fliegen durch den Raum, doch kaum jemand kann sie sauber einordnen. Es wird viel genickt, wenig verstanden – und am Ende werden Entscheidungen getroffen, die auf Halbwissen beruhen. Kennst du solche Situationen?

Sie sind kein Einzelfall. Und sie entstehen fast immer dann, wenn Projektteams ohne ein solides Verständnis der Systemlogik, der neuen Prozessarchitektur und der zugrunde liegenden Zielbilder in die Umsetzung starten.

Das Fatale: Die Konsequenzen zeigen sich nicht sofort. Am Anfang läuft scheinbar alles rund – bis später im Design, in der Realisierung oder beim Testing plötzlich auffällt, dass wichtige Weichen völlig falsch gestellt wurden. Und dann wird es teuer. Sehr teuer.

Denn was zu Beginn versäumt wurde, lässt sich später nur mit viel Aufwand und Zeit korrigieren. In manchen Fällen gar nicht mehr.

Und genau deshalb ist die fundierte Schulung des Projektteams kein Randthema. Sie ist der Schlüssel dafür, dass dein S/4HANA-Projekt auf stabilem Fundament steht – und nicht auf Sand gebaut wird.

Wenn von „Projektteamschulung“ die Rede ist, denken viele zuerst an klassische Endanwenderschulungen – also an Trainings kurz vor dem Go-Live. Doch das greift zu kurz.

In der frühen Phase eines SAP S/4HANA-Projekts geht es nicht darum, später mal Transaktionen bedienen zu können. Es geht um etwas anderes – etwas Fundamentaleres.

Projektteamschulung bedeutet in diesem Kontext: Die relevanten Personen im Projekt – also sowohl IT als auch Business – entwickeln ein gemeinsames, tragfähiges Verständnis dafür, was SAP S/4HANA überhaupt bedeutet, welche fachlichen und technischen Veränderungen auf sie zukommen und welche Spielräume und Grenzen das System bietet.

Es geht um Systemlogik, zentrale Konzepte, neue Datenstrukturen, moderne Oberflächen (z. B. SAP Fiori), prozessorientiertes Denken und das Verständnis für Standardisierungsprinzipien.

Wer gehört dazu?

Zur Zielgruppe dieser frühen Qualifizierungsmaßnahmen gehören nicht nur die Key-User:innen oder Modulverantwortlichen. Gemeint sind alle, die Entscheidungen treffen, Anforderungen definieren oder Designprozesse mitgestalten:

• Prozessverantwortliche und Fachbereichsvertretende
• IT-Architekt:innen, Modulbetreuende und Entwickler:innen
• Testmanager:innen und Schnittstellenkoordinierende
• Mitglieder des Transformation Office oder der zentralen Projektsteuerung
• Und nicht zuletzt: die Führungskräfte, die das Projekt strategisch begleiten

Denn eines ist klar: Wenn ein gemeinsames Grundverständnis fehlt, wird das Projekt zum Dauer-Übersetzungsbüro. Und das kostet Zeit, Geld – und Nerven.

Wann ist der richtige Zeitpunkt?

Früh. Sehr früh. Idealerweise vor Beginn der Fit-Gap-Analyse oder der Design-Workshops. Sobald über Prozesse, Templates und Systemlösungen gesprochen wird, sollte das Team bereits ein gutes fachliches und technisches Verständnis mitbringen. Sonst werden diese Diskussionen zu reinen Ratespielen.

Und du kannst dir denken, wohin das führt: zu Entscheidungen, die man später nicht mehr nachvollziehen kann – oder teuer korrigieren muss.

Wenn ein SAP S/4HANA-Projekt ohne fundierte Projektteamschulung startet, bleiben die Folgen oft zunächst unsichtbar. Doch sie wirken – schleichend, aber tiefgreifend.

Hier sind fünf typische Effekte, die sich in nahezu jedem ungeschulten Projektteam zeigen. Und alle haben eines gemeinsam: Sie verzögern, verteuern und belasten das Projekt unnötig.

1. Fehlendes Prozessverständnis führt zu falschen Anforderungen

Ein häufiges Szenario: Die Fachbereiche beschreiben ihre Anforderungen so, wie sie ihre bisherigen Abläufe kennen – meist entlang gewachsener Strukturen im Altsystem.

Dabei ist S/4HANA kein „neues SAP ECC“, sondern eine komplett neu gedachte Plattform. Viele Funktionen wurden konsolidiert, vereinfacht oder in Form von Best Practices standardisiert.

Ohne ein solides Verständnis dieser neuen Prozesslogik neigt das Projektteam dazu, alte Abläufe in die neue Welt „hineinzupressen“. Das führt zu unnötigen Customizings, technischen Workarounds – und letztlich zu einem System, das weder modern noch wartbar ist.

Anders gesagt: Wer die neue Küche plant, ohne zu wissen, welche Geräte dort bereits fest eingebaut sind, kauft schnell doppelt – oder verplant die Arbeitsfläche.

2. IT und Fachbereich sprechen nicht dieselbe Sprache

ERP-Projekte sind Teamarbeit – aber nur, wenn alle das gleiche Vokabular sprechen.

Was passiert, wenn das nicht der Fall ist? Die Fachseite formuliert Anforderungen, die IT interpretiert sie – und alle gehen davon aus, dass das Gegenüber schon weiß, was gemeint ist. Tut es aber nicht.

Ein Beispiel: Wenn im Workshop der Begriff „Belegfluss“ fällt – meinen dann alle das Gleiche? Weiß das Projektteam, wie dieser in S/4HANA standardmäßig dargestellt wird? Oder wird mitgedacht, dass der klassische SD-Belegfluss in Fiori völlig anders visualisiert wird?

Ein weiteres Beispiel ist der „Transport“: Während die IT-Abteilung den Transfer ihrer Entwicklungen als Transport von einem System ins nächste betrachtet, sieht der Logistiker seine konsolidierten Auslieferungen davonfahren.

Ohne eine gemeinsame begriffliche und konzeptionelle Basis entstehen Missverständnisse. Und die schleichen sich direkt in die Spezifikation – und damit ins System.

3. Schlechte Designentscheidungen sind teuer – und kaum reversibel

Entscheidungen im S/4HANA-Projekt haben oft Systemwirkung. Welche Prozesse werden zentral abgebildet, welche dezentral? Wird mit Embedded Analytics oder externen BI-Systemen gearbeitet? Wie soll der Business Partner (BP) aufgebaut sein?

Solche Grundsatzentscheidungen werden häufig bereits in der frühen Designphase getroffen. Ohne tiefes Systemwissen geraten sie schnell zur Bauchentscheidung.

Das Problem: Diese Weichenstellungen lassen sich später nur schwer – manchmal gar nicht – rückgängig machen. Und die „Kosten der Korrektur“ steigen exponentiell mit jedem weiteren Projektmonat.

Ein Beispiel aus der Praxis: Ein Unternehmen entscheidet sich für eine eigene Lösung zur Debitoren-Stammdatenpflege – ohne zu wissen, dass dies in S/4HANA standardisiert über den Business Partner läuft. Später muss die Eigenlösung teuer zurückgebaut werden, weil sie mit anderen Modulen kollidiert.

Fazit: Wer früh schlecht entscheidet, zahlt später doppelt – in Geld, in Komplexität und in Projektlaufzeit.

4. Verunsicherung und Demotivation im Projektteam

Nicht zu unterschätzen: die psychologische Komponente. Mitarbeitende, die sich fachlich oder technisch überfordert fühlen, ziehen sich zurück. Sie stellen weniger Fragen, bringen sich seltener ein – oder blockieren aus Unsicherheit sogar bewusst Veränderungen.

Diese stille Verunsicherung kostet das Projekt wertvolles Know-how. Denn gerade die Fachexpert:innen im Team sind unverzichtbar, wenn es darum geht, Prozesse sinnvoll zu standardisieren oder das richtige Zielbild für den Fachbereich zu entwerfen.

Wer jedoch den Eindruck hat, „nicht mehr mitzukommen“, verliert die Motivation – und im schlimmsten Fall auch die Bindung ans Projekt.

5. Verlorenes Wissen bremst spätere Rollouts aus

Ein SAP S/4HANA-Projekt endet nicht mit dem ersten Go-Live. Meist folgt eine Reihe weiterer Rollouts, Erweiterungen oder Optimierungswellen.

Wenn das Wissen über die Systemlogik, die getroffenen Designentscheidungen und die Hintergründe nicht im Projektteam verankert ist, geht dieses Wissen verloren – oder bleibt in den Köpfen einzelner externer Berater:innen.

Das erschwert spätere Rollouts erheblich. Neue Teams müssen sich mühsam einarbeiten, Entscheidungen aus der Vergangenheit werden nicht verstanden, und jede Änderung wird zum Risiko.

Anders gesagt: Ohne geschulte Projektbeteiligte fehlt die innere Anschlussfähigkeit – und aus einem agilen Rollout-Modell wird schnell eine schleppende Dauerbaustelle.

SAP S/4HANA-Projekte sind Investitionen. In Technologie, in Prozesse – und vor allem in Menschen. Und genau deshalb rechnet sich eine fundierte Projektteamschulung – oft schneller, als gedacht.

Natürlich kostet Schulung Zeit. Und ja, gerade in den frühen Phasen ist der Kalender voller Kick-offs, Scoping-Meetings und Governance-Abstimmungen. Der Gedanke liegt nahe: „Die Schulung holen wir später nach – wenn wir wissen, worauf es wirklich ankommt.“

Doch dieser Denkfehler kommt teuer.

Wer früher versteht, trifft bessere Entscheidungen

In den ersten Wochen werden die entscheidenden Weichen gestellt. Projektmethodik, Template-Struktur, Integrationsarchitektur, Customizing-Leitplanken. All das entsteht zu einer Zeit, in der viele Beteiligte noch nicht genau wissen, wie S/4HANA eigentlich „tickt“.

Wer hier überblickt, wie Prozesse im Standard abgebildet sind, wo Flexibilität möglich ist – und wo nicht –, trifft informierte Entscheidungen. Entscheidungen, die sich später nicht rächen. Und das spart nicht nur Geld, sondern auch Energie.

Geringe Kosten – großer Hebel

Verglichen mit dem Gesamtbudget eines S/4HANA-Projekts ist die Investition in Schulung gering. Oft genügen einige kompakte, zielgerichtete Formate – sei es als Präsenztraining, Online-Modul oder interaktiver Workshop.

Der Hebel hingegen ist groß: Ein geschultes Team arbeitet strukturierter, kommuniziert klarer, vermeidet Doppelarbeit – und kommt schneller zu belastbaren Ergebnissen.

Schulung stärkt Ownership und Projektidentifikation

Noch ein oft unterschätzter Effekt: Frühzeitige Schulung vermittelt Wertschätzung. Sie zeigt den Beteiligten, dass sie ernst genommen werden – nicht nur als Ausführende, sondern als Mitgestaltende.

Und genau das fördert Ownership. Wer weiß, worum es geht, bringt sich ein, hinterfragt, schlägt vor – statt bloß Anweisungen umzusetzen. So entsteht ein echtes Projektteam, das gemeinsam in dieselbe Richtung denkt und handelt.

Ein SAP S/4HANA-Projekt verändert mehr als nur das IT-System. Es berührt Arbeitsweisen, Denkstrukturen und Entscheidungsprozesse – über Abteilungsgrenzen hinweg.

Damit so ein Vorhaben gelingt, braucht es ein Projektteam, das nicht nur mitarbeitet, sondern mitdenkt. Und dafür braucht es Wissen. Systemwissen, Prozessverständnis und ein Gefühl für das, was möglich – und was sinnvoll – ist.

Projektteamschulung ist kein Zusatzmodul, das man irgendwann bei Bedarf nachholt. Sie ist das Fundament, auf dem alles andere aufbaut: Designqualität, Zusammenarbeit, Motivation und Umsetzungsgeschwindigkeit.

Fehlt dieses Fundament, wird das Projekt wacklig. Es entstehen Missverständnisse, Fehlentwicklungen und unnötige Kosten. Und das, obwohl sich all das vermeiden ließe – mit einer gezielten Qualifizierung zur richtigen Zeit.

Deshalb: Plane Schulung nicht als „Begleitmaßnahme“, sondern als integralen Bestandteil deiner Projektarchitektur. So stärkst du dein Team – und legst den Grundstein für ein tragfähiges, zukunftssicheres System.

Denn am Ende entscheidet nicht das Tool über den Projekterfolg, sondern das Verständnis der Menschen, die damit arbeiten.