H4S4-Migration: Diese Fragen stellen sich SAP-HCM-Kunden – mit Alexander Graf und Lukas Habermann

…zum Anschauen

YOUTUBE-CHANNEL abonnieren: https://www.youtube.com/c/Rz10De_ms

…zum Hören

…zum Lesen

H4S4 ist die HCM-Lösung auf S/4HANA und bildet den technischen Nachfolger des klassischen SAP HCM. Der Migrationsprozess zu H4S4 ist aktuell besonders relevant und der Wechsel zeitkritisch: die Wartung für Altumgebungen läuft regulär bis 2027 aus.

Vor dem Projekt: Grundsatzentscheidung und Bestandsaufnahme

Am Anfang steht die Grundsatzentscheidung: Weiter On-Premises betreiben oder in die Private Cloud wechseln? Beides ist möglich, unterscheidet sich aber in Governance, Verantwortlichkeiten und Vertragslogik. Gerade im regulierten Umfeld lohnt eine nüchterne Betrachtung der organisatorischen Folgen der Cloud-Option – inklusive Zeitpuffer für Vertragsprüfung.

Danach folgt der Realitätscheck: Eine strukturierte Bestandsaufnahme der Systeme, Schnittstellen und Eigenentwicklungen zeigt, wo Aufräumen Pflicht ist und welche Abhängigkeiten bestehen. Eine Pilotmigration ist besonders wirksam: Sie macht technische und organisatorische Hürden sichtbar, liefert belastbare Laufzeiten und hilft, Test- und Cutover-Pläne zu kalibrieren. Aus diesen Bausteinen entsteht eine Roadmap mit klaren Meilensteinen, Rollen und Kapazitäten.

Während des Projekts: Vorgehen, Aufräumen und Prüfungen

Nach der Planung folgt die Umsetzung: In dieser Phase sorgen ein klares Vorgehensmodell, gezieltes Aufräumen und belastbare Prüfungen für Stabilität.

Ansatz und Umfang: Ziel ist ein verlässliches Brownfield-Vorgehen. Abrechnung und Zeitwirtschaft sollen nach dem Upgrade funktionsgleich laufen; Änderungen werden dort eingeführt, wo Technik es erzwingt oder Altlasten bremsen.

Zeit und Altlasten: Versteckte Referenzen auf „nicht mehr genutzte“ Schemen bzw. Infotypen tauchen oft im Test auf. Konsequentes Aufräumen – insbesondere bei Zeitkollisionen und historischen Regeln – verhindert Überraschungen.

Umgebungseffekte: OS-/DB-Wechsel, Code-Pages, Zeichensätze – Randbedingungen können Output (z. B. Zahlungsdatenträger) beeinflussen. Dress-Rehearsals inklusive Batch-Ketten für Zeit und Payroll sind Pflicht.

Custom Code: Readiness-Checks ersetzen keine ATC-Analyse. Eigenentwicklungen sind gezielt auf HANA-Tauglichkeit, Performance und API-Nutzung zu prüfen.

Identitäten und Geschäftspartner

Mit H4S4 rückt die saubere Führung von Identitäten in den Vordergrund. Der Business User verknüpft SU01-Benutzer und Geschäftspartner; eine einheitliche Regel für die Bildung der IDs verhindert spätere Mapping-Aufwände. Wo möglich, wird auf die Replikation von Geschäftspartnern über Landschaften verzichtet, um Inkonsistenzen zu vermeiden. Ob der Mitarbeiter-Geschäftspartner sofort benötigt wird, hängt vom Prozess ab: Wer Reisekosten ausschließlich über Payroll erstattet, bereitet die Aktivierung und später nachziehen.

Nach dem Go-Live: Betrieb verstetigen und nachschärfen

Nach der Migration sichern belastbare Betriebsroutinen den Erfolg. Job-Ketten, Monitoring und Benachrichtigungen werden auf Basis der Dress-Rehearsals feinjustiert, während das Betriebshandbuch Zuständigkeiten, Eskalationen und Prüfschritte bündelt. Parallel startet der geplante Abbau von Altlasten, die zugunsten der Stabilität noch nicht angefasst wurden. Dokumentation und Enablement sind kein Anhang, sondern Kern des Projekts: Änderungen und Freigaben werden auditierbar festgehalten, Fach- und IT-Teams gezielt geschult.

Aufwand und Budget: Faktoren statt Fixpreisgefühl

Die Spannweite reicht – abhängig von Landschaft, Eigenentwicklungen, Schnittstellen, Vorprojekten und Testtiefe – von kompakten Aufwänden bis hin zu sechsstelligen Vorhaben. Ausschlaggebend sind neben der Betriebsoption vor allem die Anzahl der Systeme, die Menge an Custom Code, notwendige OS/DB-Wechsel und der angestrebte Testumfang. Wer Pilot und Readiness-Analyse vorschaltet, trifft belastbarere Aussagen und vermeidet Nachsteuerung im kritischen Pfad.

Fazit zu H4S4

H4S4 ist technisch ein Upgrade und organisatorisch ein Migrationsprojekt mit klarer Methode. Wer früh über die Betriebsoption entscheidet, Readiness-Check und Pilotmigration koppelt, Abrechnung und Zeit konservativ hebt, Identitäten sauber führt und Betriebsroutinen von Beginn an mitplant, senkt Risiken spürbar. Nach dem Go-Live sorgen konsequentes Monitoring, dokumentierte Prozesse und der gezielte Abbau von Altlasten für eine stabile Basis – und genau darum geht es im HR-Kernsystem. Der Umstieg sichert also Wartung und Zukunftsfähigkeit, harmonisiert den Betrieb mit dem S/4-Stack und schafft eine stabile Basis für HR-Kernprozesse. Da Wartungsfristen auslaufen (regulär bis Ende 2027, optional bis 2030), lohnt der rechtzeitige Start besonders.