S/4HANA Migration Projektmanagement Change Management

S/4HANA-Migration: Was Unternehmen systematisch unterschätzen

Nach mehreren Großprojekten weiß ich: Die technische Seite ist selten das Problem. Was Projekte wirklich scheitern lässt – und wie du als Berater den Unterschied machst.

Yannick Lotz Yannick Lotz
· · 1 Min. Lesezeit

Nach einigen S/4HANA-Migrationen habe ich ein Muster erkannt. Es ist nicht das Gleiche, was Projektmanager in Kick-off-Meetings als Risiko nennen.

Was auf dem Papier steht

Wenn Unternehmen S/4HANA-Projekte planen, fokussieren sie sich auf:

  • Datenmigration und -qualität
  • Technische Integration (Schnittstellen, Middleware)
  • Lizenzkosten und Infrastruktur
  • Go-Live-Datum

Das sind legitime Themen. Aber sie sind nicht das, woran Projekte tatsächlich scheitern.

Was wirklich das Problem ist

1. Prozessverantwortung ist unklar

S/4HANA zwingt Unternehmen dazu, ihre Prozesse zu standardisieren. Plötzlich muss jemand entscheiden: Wie machen wir das eigentlich – wirklich? Nicht wie es in einer alten SOP steht, sondern wie es gelebt wird.

Diese Frage bringt politische Konflikte ans Licht, die vorher unsichtbar waren. Und die sind schwerer zu lösen als jedes technische Problem.

2. Key-User werden zu wenig eingebunden

Der klassische Fehler: Das Projektteam arbeitet monatelang an der Konfiguration, holt die zukünftigen Anwender erst kurz vor Go-Live ab – und wundert sich über Akzeptanzprobleme.

Key-User sind keine Tester am Ende. Sie sind deine wichtigsten Verbündeten in der Fachseite und müssen von Anfang an mitgestalten.

3. Das alte System war ein Dokumentationsersatz

In gewachsenen Systemen steckt implizites Wissen. Workarounds, die niemand mehr erklärt, aber alle nutzen. Felder, die für einen komplett anderen Zweck befüllt werden als vorgesehen.

Wenn du migrierst, verlierst du dieses Wissen – außer du hebst es aktiv.

Was das für Berater bedeutet

Als SAP-Berater bist du nicht nur Konfigurierer. Du bist Moderator, Übersetzer zwischen IT und Business, manchmal auch Therapeut für festgefahrene Diskussionen.

Technische SAP-Kenntnisse sind notwendig. Aber die Berater, die in schwierigen Projekten den Unterschied machen, bringen kommunikative Stärke mit – die Fähigkeit, mit unterschiedlichen Stakeholdern auf Augenhöhe zu reden.

Das kann man lernen. Es ist kein angeborenes Talent, sondern eine Kombination aus Methode und Erfahrung.

Hat dir dieser Artikel geholfen?

Folge mir auf LinkedIn für mehr Insights aus der SAP-Welt.