SAP Readiness Check für H4S4 Schritt für Schritt: Die Vorbereitung

Der SAP Readiness Check liefert die Landkarte für die Migration nach H4S4. Ohne saubere Vorbereitung im System bleibt sie unvollständig.

Die Mainstream Maintenance für SAP ERP Central Component (ECC) und somit für das Human Capital Management (HCM) endet 2027. Wer bis dahin nach SAP HCM for S/4HANA (H4S4) migrieren will, braucht zuerst belastbare Fakten über das bestehende SAP HCM On-Premise Altsystem. Genau die liefert das von der SAP bereitgestellte Werkzeug SAP Readiness Check. In der ANNEXT Methodik steht er ganz am Anfang, noch vor jeder Aufwandsschätzung und bildet die Datenbasis einer jeden H4S4 Pre-Study. In dieser dreiteiligen Blog-Serie beschreiben wir den Readiness Check im Detail:

• Der vorliegende erste Teil behandelt die notwendigen technischen (System-)Vorbereitungen,
• Teil zwei die eigentliche Durchführung im SAP HCM System in Verbindung mit SAP for Me und
• Teil drei die Auswertung & Analyse der Ergebnisse.

Der Readiness Check zeichnet die Landkarte des Vorhabens

Der SAP Readiness Check ist ein von der SAP bereitgestelltes Self-Service Tool. Er sammelt im bestehenden SAP HCM System statistische Daten und einen begrenzten Satz von Konfigurationsdaten, überträgt diese an die Readiness Check Application, eine spezielle Cloud Anwendung der SAP und stellt die Ergebnisse in einem interaktiven Dashboard dar. SAP gliedert den Ablauf in fünf Schritte, von der (System-)Vorbereitung über Ausführung, Übertragung und Auswertung bis zur eigentlichen Migration bzw. Systemumstellung und empfiehlt den Readiness Check im Rahmen der SAP Activate Methodik früh im Projektverlauf, spätestens aber zu Beginn der Prepare Phase durchzuführen. Für Kunden mit aktivem Wartungsvertrag entstehen hierbei keine zusätzlichen Kosten.

Für ein Migrationsprojekt in Richtung H4S4 beantwortet der SAP Readiness Check vor allem die nachfolgenden Fragestellungen: Wo verändert sich der Funktionsumfang, also welche Simplification Items sind relevant? Wie groß ist der Bestand an Eigenentwicklungen (Custom Code) und welcher Teil davon muss mit Blick auf die HANA-DB oder obsolete Repository Objekte angepasst werden? Sind Drittanbieterlösungen bzw. 3rd-Party-AddOns und aktivierte Business Functions kompatibel? Und welche Größenordnung ergibt sich für die künftige HANA-DB, die eine technische Voraussetzung für H4S4 ist?

Das passende Szenario steht am Anfang

SAP bietet den Readiness Check als Familie von Szenarien mit jeweils eigenem zentralem Hinweis an. Für die Systemumstellung nach SAP HCM for S/4HANA gilt der Hinweis 2913617, der neben der H4S4 On-Premise Edition auch die Private Cloud Edition (PCE) abdeckt. Auch existiert ein eigenes Szenario für SAP SuccessFactors (Hinweis 3193560), das ein bestehendes SAP ERP HCM System mit Blick auf einen Wechsel in die Cloud untersucht. Steht die Zielarchitektur noch nicht fest, ergeben beide Szenarien zusammen ein vollständigeres Bild.

Zielversion und Prüfumfang stehen vor der Installation

Zu Beginn des Readiness Checks müssen zwei Entscheidungen getroffen werden. Erstens die Zielversion, denn der Check läuft stets gegen die geplante Softwareversion von SAP S/4HANA wie z. B. S/4HANA 2025. Sollte sich diese Zielversion im Projektverlauf ändern, muss der gesamte Readiness Check wiederholt werden. Zweitens der Prüfumfang. Verpflichtend sind nur zwei Hinweise, nämlich 2758146 für das zugrundeliegende Framework und 2399707 für die Prüfung der Simplification Items samt Kompatibilitätsanalyse. Alle weiteren Kollektoren, etwa für Sizing, Datenvolumen, Integration oder Eigenentwicklungen, werden nur eingebaut, wenn die zugehörige Prüfung gewünscht sind. Da Simplification Items bzw. “Vereinfachungen” in H4S4 Projekten einen Aufwandstreiber darstellen können, empfehlen wir diesen Bereich besonders intensiv zu prüfen. Mehr dazu in Teil 3 unserer Blog-Serie.

Die Vorbereitung beginnt im Entwicklungssystem

Die für den Readiness Check notwendigen Daten aus dem SAP ERP HCM Quellsystem werden mittels spezieller Kollektoren bereitgestellt. Diese müssen zunächst im Entwicklungssystem eingebaut und von dort über das reguläre Transportwesen via Qualitätssicherungssystem bis in das Produktivsystem überführt werden. Der SAP Solution Manager ist dafür entgegen einer verbreiteten Annahme nicht erforderlich. Der Note Assistant (Transaktion SNOTE) muss vor dem Einbau aktuell sein; der Note Analyzer ermittelt mit der Eingabedatei aus dem Hinweis 3308130 fehlende oder veraltete Stände. Zudem sollten die relevanten Softwarekomponenten landschaftsweit denselben Support Package Stand besitzen.

Berechtigungen entscheiden über den Zeitplan

Zwei getrennte Berechtigungsthemen sind im Vorfeld ebenfalls zu klären. Für die Einplanung der Kollektoren im SAP ERP HCM Quellsystem werden spezielle Berechtigungen benötigt, wie beispielsweise das Berechtigungsobjekt S_PROGRAM mit der Programmgruppe RC_COLL sowie den Aktionen SUBMIT, BTCSUBMIT und VARIANT. Fehlen diese, kann die Hintergrundverarbeitung nicht korrekt gestartet werden. Da der Lauf auf dem Produktivsystem durchgeführt werden muss, empfiehlt sich daher der Einsatz eines BATCH-Users mit entsprechend umfassenden Berechtigungen.

Ferner werden Berechtigungen im SAP for Me notwendig. Das zugrundeliegende Berechtigungskonzept (Hinweis 3310759) wurde im Zeitverlauf neu aufgelegt und umfasst Berechtigungen zum Anzeigen, Anlegen, Bearbeiten, Löschen und Teilen der Readiness Check Analysen. Vergeben werden sie durch die Superadministratoren des eigenen Unternehmens. Sofern notwendig können die Berechtigungen z. B. von externen Consultants, die mit dem Readiness Check beauftragt wurden, auch selbständig angefordert werden. Nach der Genehmigung dauert es rund zwei Stunden bis die Änderung greift.

Systeme und Mandanten folgen klaren Regeln

SAP empfiehlt die Ausführung der Kollektoren im Produktivsystem bzw. Produktivmandanten, weil nur dort die tatsächliche Nutzung sichtbar wird. Zwei Ausnahmen bestehen: Die Konsistenzprüfung der Simplification Items gehört in den Mandanten 000, die Analyse der Eigenentwicklungen in das Entwicklungssystem. Steht das Produktivsystem z. B. aufgrund von fehlenden Berechtigungszugriffen nicht bereit, beschreibt der Hinweis 2568736 einen Workaround über eine Systemkopie, allerdings mit Einschränkungen bei einzelnen Prüfungen.

Was den Custom Code im HR betrifft, ist dieser unserer Erfahrung nach oftmals historisch gewachsen und selten vollständig dokumentiert. Daher bietet sich ergänzend zum Readiness Check die Analyse über die SAP Fiori Custom Code Migration App oder das ABAP Test Cockpit (Transaktion ATC) an. Der SAP Custom Code Migration Guide liefert hierfür sehr hilfreiche, technische Informationen (das bestmögliche Vorgehen zur Custom Code Analyse werden wir sehr bald in einem eigenständigen Blog Beitrag behandeln).

Der wichtigste Punkt betrifft den Datenschutz. Der Readiness Check erhebt keine Bewegungsdaten, sondern Nutzungsstatistiken, Angaben zum Datenvolumen und Konfigurationseinstellungen. Entscheidend für die Abstimmung mit Betriebsrat und Datenschutz: Das erzeugte Archiv lässt sich vor der Übertragung in lesbarer Form prüfen und bei Bedarf maskieren. Diese Prüfung gehört dokumentiert, bevor jemand auf Hochladen klickt.

Ausblick: Teil zwei der ANNEXT Blog-Serie beschreibt die Durchführung

Sind die in diesem Blog Beitrag diskutierten Vorbereitungen abgeschlossen, folgt der operative Teil: Die Zielversion und den Umfang im Report RC_COLLECT_ANALYSIS_DATA wählen, die Kollektoren einplanen, die Hintergrundjobs überwachen, die Ergebnisse herunterladen und die Analyse in SAP for Me anlegen. Darum geht es im zweiten Teil unserer Blog-Serie. Teil drei behandelt die Auswertung, also die Übersetzung der Ergebnisse in konkrete Arbeitspakete. Beide werden wir in den nächsten Wochen veröffentlichen. Schauen Sie gerne wieder vorbei.