SF EC zu SAP HCM Core Hybrid: Was passiert beim Go-live wirklich mit den Mitarbeiterdaten?

Einleitung:

Kunden entscheiden sich aus den unterschiedlichsten Gründen für SuccessFactors Employee Central, im Folgenden EC. Der häufigste ist der Aufbau eines globalen HR-Systems. Ein globales HR-System zieht die notwendige Grenze zwischen HR-Funktionen und HR-fremden Servicefunktionen wie Payroll, Time usw. So sinnvoll diese Grenze fachlich ist, sie zerteilt den Hire-to-Pay-Prozess in zwei Systeme – und das macht eine Integration erforderlich.

Ist EC als globales HR-System gesetzt, werden Mitarbeitende dort eingestellt und ausgesteuert. Handelt es sich beim Payroll-System um ein SAP-Payroll-System, läuft die Integration über ein gut etabliertes Integrationsmuster, die sogenannte "Core Hybrid" Integration. Getragen wird sie von einer bewährten, unermüdlichen Infrastruktur namens Business Integration Builder (BIB), die mit dem Add-on PA_SE_IN ausgeliefert wird. Über BIB wurde in diesem Forum und anderswo schon viel diskutiert und gestritten. Dieser Blogbeitrag befasst sich nicht mit den Feinheiten von BIB, sondern damit, wie SAP das Verhalten von BIB beim Go-live gestaltet hat.

[Bildquelle: Eigene Darstellung]

BIB unterstützt sowohl Migration als auch Integration:

Kunden, die live gehen, starten ihren Go-live-Prozess häufig mit einer Migration von SAP HCM nach EC, gefolgt von einem anschließenden Integrationslauf von EC nach SAP HCM.

Häufig am Go-live-Prozess beteiligte Entitäten:

1. Org-Objekte – Business Unit, Division, Department, Team, kundeneigene Objekte
2. Planstellen
3. Jobs
4. Mitarbeitende
5. Verknüpfte Assoziationen

User Persona:

Mary Mustermann: Eine Beispiel-Persona, die uns durch diesen Blogbeitrag begleitet, um die Migrations- und Integrationsläufe zu veranschaulichen. Mary arbeitet seit knapp 30 Jahren. Die Tabelle zeigt ihre Job-Slices (abgeleitet aus den Infotypen 0000/0001 in SAP HCM.)

---

Migration :

Die Migration bringt Daten von SAP nach SF über den SAP Infoporter (BIB). Dabei werden nur eingeschränkte historische Daten übernommen. Es empfiehlt sich, bei der Migration nicht zu weit in die Historie zurückzugehen. Der Umfang der über die Migration übernommenen Daten wird über das Cut-off-Datum gesteuert. Es ist klug, so wenig Ballast wie möglich mitzunehmen, das Cut-off-Datum sollte also vom Laufdatum aus gesehen nicht zu weit in der Vergangenheit liegen.

Die Migration kennt zwei Arten von Läufen: den vollständigen Migrationslauf und den Delta-Migrationslauf.

• Der vollständige Migrationslauf bringt alle Daten vom Cut-off-Datum bis zum Highdate. Nach dem Migrationslauf wird erwartet, dass das SF-System zum führenden System der Stammdaten wird.
• Wenn das nicht eintritt (z. B. bei einem gestaffelten Go-live, bei dem Kunden eine juristische Person nach der anderen in die Cloud bringen), wachsen die Daten in SAP weiter, wodurch die Daten in SF veralten.
• Um ein solches Szenario zu lösen, wird die Delta-Migration eingesetzt, bei der nur das Delta aus SAP seit dem Datum des ersten Migrationslaufs repliziert wird.

Migration im Detail:

• Nehmen wir an, der Migrationslauf hat ein Cut-off-Datum vom 01.01.2021.
• Am Migrationstag werden alle Objekte (O/S/P/C/…) von SAP nach SF repliziert. Org-Objekte gehen ohne viel Aufhebens durch. Unser Fokus liegt daher auf den Mitarbeitenden.
  1. Alle Mitarbeitersätze, deren Endedatum vor dem Cut-off-Datum liegt, werden ignoriert
  2. Alle zukunftsdatierten Mitarbeitersätze werden unverändert repliziert.
  3. Die Mitarbeitersätze, deren Beginndatum vor und deren Endedatum nach dem Cut-off-Datum liegt, nennen wir sie aktuelle Sätze, werden zum Cut-off-Datum gesplittet. Übertragen wird nur der Slice mit dem Cut-off-Datum als Beginndatum.
  4. Das Recruit Date in SF wird auf das Cut-off-Datum vorbelegt. Das ruiniert die Talent-Module. Um das aufzulösen, ist es gängige Praxis, für alle Mitarbeitenden einen initialen Job-Slice vom Einstellungsdatum bis zum Cut-off-Datum mitzubringen. Dabei können wir entweder eine Dummy-Massenplanstelle in SF verwenden oder die Planstelle während der Migration als optional kennzeichnen. Die zweite Option erlaubt die Migration von Mitarbeiter-Jobdaten vor dem Cut-off-Datum ohne Planstelle.
  5. Der initiale Job-Satz wird damit zum initialen Einstellungssatz. Das Ereignis auf diesem Satz ist H, und der Ereignisgrund kann beliebig gewählt werden, um die Migration eindeutig zu kennzeichnen. Er kann auch schlicht "MIGRATION" heißen.
  6. Vor diesem Hintergrund schauen wir uns an, wie Mary migriert wird.

• Delta-Migrationsläufe: Das tatsächliche Datum des Migrationslaufs kann technisch gesehen jedes Datum am oder nach dem Cut-off-Datum sein. Nach dem Migrationslauf sollten die an der Integration beteiligten Entitäten (O/S/P) derjenigen juristischen Personen, für die migriert wurde, nun in SF geführt werden. Ist das nicht der Fall, wachsen die Daten in SAP weiter und ein weiterer (womöglich Delta-) Migrationslauf wird nötig.

---

Integration:

Nach der Migration läuft die Integration von SF nach SAP. Diese als Core-Hybrid-Integration bezeichnete Strecke bringt Org- und Mitarbeiterdaten regelmäßig nach SAP. Wie die Migration startet auch die Integration mit einem Cut-off-Datum. Das Integrations-Cut-off-Datum ist das Datum, ab dem Datenänderungen nach SAP repliziert werden.

Ebenfalls wie bei der Migration gibt es auch bei der Integration zwei Arten von Läufen: den allerersten Integrationslauf, der die Daten zwischen beiden Systemen angleicht, und die anschließenden Delta-Replikationsläufe, die regelmäßig Daten übertragen. An dieser Stelle ist wichtig festzuhalten:

• Delta-Läufen muss zwingend ein Initiallauf vorausgehen.
• Der Initiallauf splittet Infotypsätze nicht zwangsläufig zum Cut-off-Datum.

Integration im Detail:

1. Nehmen wir an, auch die Integration hat ein Cut-off-Datum vom 01.2021. Das Cut-off-Datum der Integration sollte mit dem der Migration übereinstimmen oder später liegen, keinesfalls früher.

2. Full Transmission Start Date: FTSD/Cut Off

   1. Auch als Cut-off-Datum bekannt, ist dies das Datum, ab dem Daten-Slices nach SAP übertragen werden.
   2. Es ist tatsächlich genau jenes Cut-off-Datum, das im Transformation Template gepflegt wird, mit dem EC-Objekte (Employee/Org/Position/…) abgefragt werden.
   3. Die Cut-off-Daten in den Org- und Mitarbeitervorlagen sollten identisch sein.

3. Initiallauf: Der Initiallauf ist ein Datenabgleichslauf zwischen EC und HCM. Er repliziert Daten-Slices vom FTSD bis zum Highdate (31.12.9999) für alle Entitäten. Er ist verpflichtend. Ohne Initiallauf kann es keinen Delta-Lauf geben.

   1. Daten-Slices vor dem FTSD werden ignoriert.

   2. Infotyp-Daten-Slices mit Beginndatum vor und Endedatum nach dem FTSD werden standardmäßig NICHT zum FTSD geschnitten. Das widerspricht der landläufigen Annahme. Ob geschnitten wird oder nicht, hängt allein davon ab, wie identisch die Daten zwischen SAP und SF sind. Ein Slice entsteht NUR dann, wenn die Daten in SF nach dem letzten erfolgreichen Delta-Migrationslauf bearbeitet oder geändert wurden => Migrierte Daten sind nicht dasselbe wie integrierte Daten. Eine Abbildung in der SAP-Hilfedokumentation wird oft herangezogen, um fälschlich zu schließen, Infotypen würden zum Cut-off-Datum gesplittet. Infotypen werden nur dann gesplittet, wenn migrierte und integrierte Daten voneinander abweichen. SAP hat dazu sogar ein Addendum veröffentlicht, das dies klarstellt.

   3. Wann also splittet der Infotyp tatsächlich?

      1. Es ist möglich, aus Legacy-Gründen alle Daten zu migrieren, aber nur Teile davon zu integrieren. Beispiel 0009: Die Migrationsvorlage kopiert womöglich alle Felder des 0009 unverändert nach SF. Bei der Integration werden aber nur IBAN und Zahlungsart (z. B. Überweisung) integriert.
      2. Nach der Migration wird eine unternehmensweite Mitarbeiteraktualisierung durchgeführt, z. B. eine Änderung der Benutzernamen. Das führt zu einem Split des 0105 in SAP.
      3. Ein zukunftsdatierter Slice, der nach der Migration frisch im SF-System angelegt wird (und nicht Teil der Migration war), führt immer zu einem Infotyp-Split des aktuell gültigen Daten-Slices.
      4. Und schließlich, wenn in SF explizit mit einem Ereignis "First Event after Migration" gesplittet wird. Oder wenn in SAP bereits vor der Migration mit einem vergleichbaren Ereignis gesplittet wurde. Bis zur Einführung von BIB war das Splitten von Infotypen die Norm. Das führte zu Rückrechnungsproblemen in der Payroll, und nachgelagerte Schnittstellen wurden unnötig aktiviert, was weitere Komplikationen nach sich zog. Deshalb hat SAP mit BIB das Konzept des Initiallaufs eingeführt, das keinen expliziten Infotyp-Split zwingend erfordert.

4. Was macht der Initiallauf sonst noch?

   1. Wie erwähnt splittet er Infotypsätze selektiv.
   2. Er etabliert ein Last Run Date für die an der Integration beteiligten Entitäten.

5. Was ist das Last Run Date: LRD

   1. Das allererste Last Run Date entsteht am Ende des Initiallaufs.
   2. Läuft der Initiallauf beispielsweise am 1. Januar 2021 um 13:30, wird das LSRD als 01.01.2021 13:30:00 festgehalten.
   3. Beim nächsten Lauf wird jeder Datenzuwachs in EC, der nach dem LSRD entstanden ist, an HCM übergeben, und es wird erneut ein LRD festgehalten. Dieses wird im darauffolgenden Lauf verwendet. Solche Läufe heißen Delta-Läufe.

6. Delta-Läufe: Wie oben beschrieben sind das die Läufe nach dem Initiallauf. Der Ankerpunkt für den LRD-Lauf ist der Initiallauf und damit das FTSD. Ohne festgelegtes FTSD ist kein Delta-Lauf möglich.

7. Der Initiallauf kann bei Bedarf jederzeit erneut ausgeführt werden. Er bezieht sich dann wieder auf dasselbe FTSD. Das FTSD ist für eine Integration also in Stein gemeißelt. Einmal gesetzt, lässt es sich nicht mehr ändern.

---

Endstand der Daten-Slices von Mary Mustermann nach der Integration:

---

Fazit:

• Alles hier Geschriebene beruht ausschließlich auf unseren (INTEGRTRs) Erfahrungen mit Großkunden und größeren Mittelständlern.
• Auch unsere Migrationserfahrung beruht ausschließlich auf SAPs BIB/Infoporter. Andere Migrationswerkzeuge wie Accentures Clone and Test sind anders konzipiert und können sich anders verhalten.
• Und schließlich: Der Weg jedes Kunden zur Migration und anschließenden Integration ist einzigartig. Fachliche Erwägungen und die Realität vor Ort geben den Ton an und stechen alle bekannten Weisheiten.