Vier Entscheidungen vor der S/4HANA-Transformation

Deployment-Modell und Produktumfang unterscheiden

„SAP Real Estate“ ist kein einheitlicher Funktionsumfang über alle S/4HANA-Betriebsmodelle. Das klassische Flexible Real Estate Management (RE-FX) ist in der offiziellen Dokumentation für SAP S/4HANA On-Premise beschrieben. Für SAP S/4HANA Cloud Public Edition dokumentiert SAP dagegen Contract and Lease Management (CLM), insbesondere für Leasingbilanzierung nach IFRS 16 und ASC 842.

Die Konsequenz: Nicht mit Produktnamen starten, sondern mit benötigten Prozessen und dem konkreten S/4HANA-Betriebsmodell. Erst dann lässt sich belastbar bestimmen, was Standard ist, was integriert werden muss und wo ergänzende Lösungen erforderlich sind.

Prozessgrenzen und Verantwortlichkeiten festlegen

Vor dem Customizing braucht es ein End-to-End-Zielbild. Dazu gehören mindestens:

• Objekt-, Flächen- und Vertragsmanagement
• Konditionen, Anpassungen, Nebenkosten und Abrechnung
• Lease Accounting, Bewertung, Buchung und Periodenabschluss
• Übergaben an FI/CO sowie Reporting und Kontrollen
• Schnittstellen zu CAFM, Portalen, Workflow und Drittsystemen

Wichtig ist nicht nur, welcher Prozess in welchem System liegt. Ebenso klar müssen fachliche Verantwortung, Datenhoheit, Kontrollen und Ausnahmebearbeitung definiert sein.

Migration als fachliche Transformation behandeln

Eine RE-FX- oder CLM-Migration ist keine reine Tabellenübernahme. Objekte, Geschäftspartner, Verträge, Konditionen, Bewertungsparameter und Buchungshistorien stehen in fachlichen Abhängigkeiten. Benötigt werden deshalb ein fachliches Mapping, nachvollziehbare Transformationsregeln, Abstimmkontrollen und klare Abnahmekriterien.

Die eigentliche Frage lautet nicht: „Sind alle Datensätze geladen?“ Sondern: „Sind Verträge, Bewertungen, Buchungen und Salden im Zielsystem vollständig nachvollziehbar und betriebsfähig?“

Betriebsarchitektur vor dem Go-live entwerfen

Fiori-Rollen, Berechtigungen, APIs, Workflows, Hintergrundläufe, Abschlusskalender und Supportprozesse gehören in dasselbe Architekturmodell wie die Kernlösung. Ohne dieses Betriebsdesign entstehen nach dem Produktivstart manuelle Umwege, unklare Zuständigkeiten und schwer steuerbare Fehlerbilder.

Ein tragfähiges Design verbindet daher Fachkonzept, Lösungsarchitektur, Migration, Tests und Betrieb. Diese Entscheidungen sollten vor dem Design-Freeze dokumentiert, bewertet und mit Finance, Real Estate und IT abgestimmt sein.

Empfohlener nächster Schritt

Ein kompaktes Readiness Assessment schafft vor Projektstart Transparenz: Prozesslandkarte, Deployment- und Produktentscheidung, Fit-to-Standard, Integrationsbild, Datenrisiken und Betriebsmodell. So werden kritische Lücken sichtbar, bevor sie teuer werden.