H4S4 als Brücke in die Cloud: Was bei gewachsenen HR-Landschaften zählt

Die Umstellung auf SAP HCM for S/4HANA (H4S4) ist für viele Unternehmen ein Zwischenschritt auf dem Weg in die Cloud. Doch wie lässt sich eine gewachsene HR-Landschaft modernisieren, ohne geschäftskritische Prozesse zu gefährden? Welche Rolle spielen dabei Schnittstellen, Drittanwendungen und Fallback-Szenarien? Das erläutert Sebastian Eßling (Mindsquare) am Beispiel der Berliner Stadtreinigung (BSR).

Eine SAP-HCM-Landschaft zu modernisieren, bedeutet mehr als die Konversion eines Kernsystems. In über Jahre gewachsenen Umgebungen hängen zahlreiche Schnittstellen, Eigenentwicklungen und Drittanwendungen mit den bestehenden HR-Prozessen zusammen. Eine H4S4-Transformation muss deshalb nicht nur technisch funktionieren. Sie muss auch sicherstellen, dass die relevanten Prozesse während und nach der Umstellung stabil weiterlaufen.

Vor dieser Aufgabe stand auch die Berliner Stadtreinigung (BSR). Mit ausreichend Vorlauf vor dem für Ende 2027 angekündigten Supportende für das bestehende SAP-HCM-System entschied sie sich für die Umstellung auf SAP HCM for S/4HANA. Die neue Systembasis ist dabei nicht als endgültige Zielarchitektur vorgesehen: Perspektivisch soll die HR-Landschaft schrittweise in Richtung SAP SuccessFactors weiterentwickelt werden.

Während der Umsetzung wurde die Komplexität der bestehenden Anwendungslandschaft besonders deutlich. Einzelne Drittanwendungen, darunter eine Bewerbermanagementsoftware, waren zunächst noch nicht vollständig mit der neuen Umgebung kompatibel. Die daraus resultierenden Integrationsfragen mussten deshalb parallel zum Projektverlauf geklärt werden. Für die technische Umsetzung und die Koordination der Integrationsszenarien arbeitete die BSR mit mindsquare zusammen.

Die Systemlandschaft als Ganzes betrachten

Am Anfang der H4S4-Umstellung bei der BSR stand deshalb nicht unmittelbar die technische Konversion, sondern ein Readiness Check. Dabei wurden Ressourcen, Budget und Vorgehensmodell definiert und damit der Rahmen für die weitere Umsetzung geschaffen.

Gerade in gewachsenen HR-Landschaften sollte eine solche Bestandsaufnahme über das Kernsystem hinausgehen. Denn ob ein HR-Prozess nach der Umstellung funktioniert, hängt auch von den beteiligten Schnittstellen, Eigenentwicklungen und Drittanwendungen ab. Wichtig ist nicht nur, ob diese technisch funktionieren, sondern welche Rolle sie für den jeweiligen Prozess spielen.

Für die Bewertung helfen drei Fragen: Welcher Prozess hängt von einer Anwendung oder Schnittstelle ab? Welche Auswirkungen hätte eine Störung auf den laufenden Betrieb? Und welche Alternative steht zur Verfügung, wenn eine Integration nicht wie vorgesehen funktioniert? Auf dieser Basis lassen sich technische Abhängigkeiten nach ihrer Bedeutung für den jeweiligen HR-Prozess einordnen.

Wie relevant diese Abhängigkeiten werden können, zeigte sich auch im BSR-Projekt: Einzelne Drittanwendungen waren zunächst noch nicht vollständig mit der neuen Umgebung kompatibel. Die entsprechenden Integrationsfragen mussten daher parallel zur H4S4-Umsetzung bearbeitet werden.

Fallback-Szenarien statt improvisiertem Plan B

Um die eigentliche Systemumstellung abzusichern, wurden im BSR-Projekt frühzeitig alternative Lösungswege und ein eindeutiger Fallback-Mechanismus definiert. Vor Beginn der Konversion wurde ein vollständiges Backup erstellt. Es umfasste sowohl die Datenbank als auch die Applikationsebene und bildete damit den letzten stabilen Systemstand vor der Umstellung ab.

Für den Abbruch waren klare Kriterien definiert: Trat während der Umstellung ein als „produktionsverhindernd“ eingestufter Fehler auf, der sich innerhalb des vorgesehenen Projektzeitfensters nicht beheben ließ, konnte die Konversion abgebrochen und das Backup zurückgespielt werden. Das System wäre damit auf den Stand vor Beginn der Umstellung zurückgesetzt worden. Für die Anwender hätte das bedeutet, am nächsten Werktag mit dem bisherigen System weiterarbeiten zu können.

Die Entscheidung über einen solchen Fallback war vorab geregelt. Sie lag gemeinsam bei der SAP-Basis der Geschäftseinheit IT und dem Projektleiter; die technische Rücksicherung hätte das SAP-Basis-Team übernommen. Ursache, Zeitpunkt, Entscheidungsträger und durchgeführte Maßnahmen eines Abbruchs wären zudem dokumentiert worden.

Ein definierter Fallback beschreibt nicht nur, wie der letzte stabile Systemstand wiederhergestellt wird. Er regelt bereits vor dem Cutover, unter welchen Bedingungen die Umstellung abgebrochen wird, wer die Entscheidung trifft und welche Schritte anschließend erforderlich sind. Gerade bei geschäftskritischen HR-Systemen wird aus einem allgemeinen „Plan B“ so ein klar geregeltes und unmittelbar umsetzbares Verfahren.

Eng damit verbunden ist die Vorbereitung des Produktivwechsels durch mehrere Testläufe. Bei der BSR fanden zunächst zwei Probeumstellungen auf einem Sandboxsystem statt. Anschließend wurden nacheinander das Entwicklungs- und das Testsystem umgestellt. Ziel war es, Fehler möglichst vor der Konversion des Produktivsystems zu identifizieren und zu beheben.

Die technische H4S4-Umstellung der BSR erfolgte Ende Oktober 2025 im vorgesehenen Zeitfenster. Anfang November ging das System in den Regelbetrieb über; anschließend begleiteten die Projektteams die Stabilisierung.

Wenn die Transformation beim Anwender ankommt

Parallel zur H4S4-Transformation wurden bei der BSR Employee und Manager Self-Services auf Basis von SAP Fiori eingeführt und weiterentwickelt. Beschäftigte können darüber unter anderem Urlaubsanträge und Stammdatenänderungen bearbeiten, während Führungskräfte Genehmigungen digital steuern und auf aktuelle HR-Daten zugreifen können. Rund 1.200 Beschäftigte und etwa 250 Führungskräfte nutzen die Self-Services und digitalen HR-Funktionen.

Damit reicht die Transformation über die technische Systemumstellung hinaus. Während eine Backend-Konversion für viele Beschäftigte weitgehend unsichtbar bleibt, verändern neue Self-Services konkrete Arbeitsabläufe. Mit ihrer Einführung rücken deshalb auch Kommunikation, Schulung und Anwenderunterstützung in den Fokus.

Bei der BSR wurde die Einführung der Self-Services unter anderem durch Schulungsvideos und begleitende Kommunikationsmaßnahmen unterstützt. Die Digitalisierung setzte zunächst im Büro- und Verwaltungsumfeld an; perspektivisch sollen auch operative Bereiche einbezogen werden.

H4S4 als Basis für den nächsten Schritt

Für die BSR ist H4S4 allerdings nicht die endgültige Zielarchitektur, sondern die Basis für die weitere Entwicklung in Richtung SAP SuccessFactors. Über das konkrete Projekt hinaus lassen sich daraus drei Punkte für H4S4-Vorhaben ableiten: Erstens sollte die Migration nicht am Kernsystem enden, sondern die Abhängigkeiten der gesamten HR-Landschaft berücksichtigen.  Zweitens schaffen klar definierte Fallback-Szenarien Sicherheit für den Produktivwechsel, insbesondere dort, wo geschäftskritische HR-Prozesse wie die Entgeltabrechnung jederzeit gewährleistet sein müssen. Und drittens sollte die technische Modernisierung mit Blick auf die langfristige Zielarchitektur geplant werden.

Eine H4S4-Transformation schafft damit nicht automatisch einen kürzeren Weg in die Cloud. Sie kann aber eine stabile Ausgangsbasis schaffen, um die weitere HR-Transformation gezielt und in aufeinander abgestimmten Etappen vorzubereiten.