Einleitung:
Kunden entscheiden sich aus einer Vielzahl von Gründen für SuccessFactors Employee Central, nachfolgend EC genannt. Der häufigste Grund ist die Schaffung eines globalen HR-Systems. Ein globales HR-System schafft die notwendige Grenze zwischen HR-Funktionen und Nicht-HR-Nutzfunktionen wie Gehaltsabrechnung/Zeit usw. Eine solche Abgrenzung ist zwar gut für das Geschäft, doch wird dadurch der Geschäftsprozess "Hire to Pay" in zwei Systeme aufgeteilt, was eine Integration erforderlich macht.
Da EC als globales HR-System vorgesehen ist, werden Mitarbeiter über dieses System eingestellt und entlassen. Handelt es sich bei dem Lohn- und Gehaltsabrechnungssystem um ein SAP-Lohn- und Gehaltsabrechnungssystem, erfolgt die Integration über ein bewährtes Integrationsmuster, die so genannte "Core Hybrid"-Integration. Diese Integration wird durch eine bewährte Infrastruktur namens Business Integration Builder (BIB) unterstützt, die mit dem Add-on PA_SE_IN geliefert wird. Über den BIB wurde in diesem Forum und anderswo schon viel diskutiert und debattiert. In diesem Blog geht es nicht um die Feinheiten des BIB, sondern vielmehr darum, wie SAP den BIB für den Produktivstart konzipiert hat.
[Bildquelle: Selbstgemacht]
Das BIB unterstützt sowohl die Migration als auch die Integration:
Kunden, die in den Echtbetrieb gehen, beginnen ihren Go-Live-Prozess häufig mit einer Migration von SAP HCM zu EC, gefolgt von einer anschließenden Integrationslast von EC zu SAP HCM.
Einrichtungen, die in der Regel am Go-Live-Prozess beteiligt sind:
- Org-Objekte - Geschäftsbereich, Abteilung, Abteilung, Team, benutzerdefinierte Objekte
- Positionen
- Stellenangebote
- Mitarbeiter
- Vernetzte Verbände
Benutzer-Persona:
Maria Mustermann: Dies ist ein Beispiel für eine Persona, die wir in diesem Blog verwenden werden, um die Migrations-/Integrationsprozesse zu beschreiben. Mary ist seit fast 30 Jahren berufstätig. Die Tabelle zeigt ihre Stellenabschnitte (aus den Infotypen 0000/0001 in SAP HCM).
| Veranstaltung | Datum des Beginns | Enddatum |
| Mieten Sie | 01.01.1991 | 31.12.1998 |
| Daten ändern | 01.01.1999 | 31.08.2002 |
| Daten ändern | 01.09.2002 | 31.12.2014 |
| Daten ändern | 01.01.2015 | 31.12.2018 |
| Daten ändern | 01.01.2019 | 31.12.2021 |
| Daten ändern | 01.01.2022 | 31.12.9999 |
Migration :
Die Migration bringt Daten von SAP nach SF über SAP Infoporter (BIB). Die Migration bringt nur begrenzte historische Daten ein. Es wird empfohlen, während der Migration nicht zu weit in die Historie zu gehen. Der Umfang der Daten, die über die Migration eingebracht werden, wird über den Stichtag gesteuertEs ist ratsam, so wenig Gepäck wie möglich mitzubringen - der Stichtag sollte also nicht zu weit in der Vergangenheit des Laufdatums liegen.
Es gibt zwei Arten von Migrationsläufen: Vollmigration und Deltamigrationslauf.
- Vollständiger Migrationslauf bringt alle Daten vom Stichtag bis zum Höchstdatum ein. Nach dem Migrationslauf wird das SF-System voraussichtlich zum Stammdatensystem der Akten werden.
- Wenn dies nicht der Fall ist (z. B. bei einem verzögerten Go-Live, bei dem die Kunden jeweils nur eine juristische Person in die Cloud verlagern), wachsen die Daten in SAP weiter an, so dass die Daten in SF veraltet sind.
- Um ein solches Szenario zu lösen, wird die Deltamigration verwendet, bei der nur das Delta zwischen SAP und dem Datum des ersten Migrationslaufs repliziert wird.
Migration im Detail:
- Sagen wir Migration Lauf hat eine Stichtag von 01.01.2021.
- Zum Zeitpunkt der Migration werden alle Objekte (O/S/P/C/...) von SAP nach SF repliziert. Org-Objekte werden ohne viel Aufhebens übernommen. Daher liegt unser Schwerpunkt auf dem Mitarbeiter.
- Alle Mitarbeiterdatensätze, deren Enddatum unter dem Stichtag liegt, werden ignoriert.
- Alle in die Zukunft datierten Mitarbeiterdatensätze werden unverändert repliziert.
- Die Mitarbeiterdatensätze, bei denen das Anfangsdatum kleiner als das Stichtagdatum und das Enddatum größer als das Stichtagdatum ist - nennen wir sie aktuelle Datensätze - werden am Stichtag geteilt. Nur der Abschnitt mit dem Stichtag als Beginndatum wird übertragen.
- Das Rekrutierungsdatum in SF ist standardmäßig auf das Stichtagdatum eingestellt. Das macht Talentmodule kaputt. Um dieses Problem zu lösen, ist es gängige Praxis, für alle Mitarbeiter vom Einstellungsdatum bis zum Stichtag eine anfängliche Job-Slice einzubringen. Dabei können wir entweder eine Dummy-Massenposition auf SF einrichten oder die Position während der Migration als optional kennzeichnen. Die letztere Option ermöglicht die Migration von Mitarbeitern vor dem Stichtag ohne eine Stelle.
- Der Datensatz der ersten Stelle wird somit zum Datensatz der ersten Einstellung. Das Ereignis in diesem Datensatz ist H, und der Ereignisgrund kann alles sein, was eindeutig eine Migration bezeichnet. Es kann auch "MIGRATION" genannt werden.
- Nach all diesen Informationen wollen wir nun sehen, wie Mary migriert wird.
| Veranstaltung | Ereignis Grund | Datum des Beginns | Enddatum |
| Mieten Sie | MIGRATION | 01.01.1991 | |
| Daten ändern | Daten ändern Abgeschnittene Scheibe | 01.01.2021 | 31.12.2021 |
| Daten ändern | Daten ChangeFuture datierte Scheibe (kommt so an wie sie ist) | 01.01.2022 | 31.12.9999 |
- Delta Migration Runs: Das tatsächliche Datum des Migrationslaufs kann technisch gesehen ein beliebiges Datum am oder nach dem Stichtag sein. Nach dem Migrationslauf sollten die an der Integration beteiligten Einheiten (O/S/P) der juristischen Personen, für die die Migration durchgeführt wurde, nun in SF beherrscht werden. Ist dies nicht der Fall, wachsen die Daten in SAP weiter an, was einen weiteren Migrationslauf (eventuell als Delta) erforderlich macht.
Integration:
Bei der Migration läuft die Integration von SF zu SAP. Diese Integration wird als Core-Hybrid-Integration bezeichnet und bringt regelmäßig Org- und Mitarbeiterdaten in SAP ein. Wie die Migration beginnt auch die Integration mit einem Stichtag. Der Integrationsstichtag ist das Datum, ab dem Datenänderungen in SAP repliziert werden.
Wie bei der Migration gibt es auch bei der Integration zwei Arten von Läufen. Der allererste Integrationslauf, bei dem Daten zwischen den beiden Systemen abgeglichen werden, und nachfolgende Deltareplikationsläufe, die regelmäßig Daten einbringen. In diesem Stadium ist es wichtig zu beachten, dass:
- Den Deltaläufen muss zwingend ein Initiallauf vorausgehen.
- Beim ersten Lauf werden die Infotypsätze nicht unbedingt zum Stichtag gesplittet.
Integration im Detail:
- Sagen wir, Integration hat auch eine Stichtag von 01.2021. Für die Integration sollte ein Stichtag festgelegt werden, der mit der Migration übereinstimmt oder nach der Migration liegt - auf keinen Fall vorher.
- Datum des Beginns der vollständigen Übertragung: FTSD/Abschaltung
- Dies ist das Datum, ab dem die Datenscheiben an SAP übertragen werden, auch Stichtag genannt.
- Dies ist in der Tat das Stichtagsdatum, das in der Transformationsvorlage für die Abfrage von EC-Objekten (Mitarbeiter/Organisation/Position/...) gepflegt wird.
- Die Stichtage auf Org- und Mitarbeitervorlagen sollten identisch sein.
- Erster Lauf: Der Erstlauf ist ein Datenausgleichslauf zwischen EC und HCM. Der Initiallauf repliziert Datenscheiben von der FTSD bis zum Höchstdatum (31.12.9999) für alle Entitäten. Dies ist obligatorisch. Es kann keinen Deltalauf ohne den Initiallauf geben.
- Daten-Slices vor FTSD werden ignoriert.
- Infotyp-Datenscheiben mit Beginndatum vor FTSD und Enddatum nach FTSD werden standardmäßig NICHT am FTSD geschnitten. Dies steht im Gegensatz zur landläufigen Meinung. Ob sie geschnitten werden oder nicht, hängt allein davon ab, wie identisch die Daten in SAP und SF sind. Daten werden NUR geschnitten, wenn die Daten in SF nach dem letzten erfolgreichen Delta-Migrationslauf bearbeitet/geändert wurden => Migrierte Daten sind nicht dasselbe wie integrierte Daten.
Dieses Bild aus der SAP-Dokumentation wird oft für den Irrtum verwendet, dass Infotypen zum Stichtag gesplittet werden. Infotypen werden nur dann geteilt, wenn die migrierten Daten und die integrierten Daten nicht identisch sind. SAP hat dazu sogar ein Addendum herausgegeben, das Klarheit schafft.
[Bildquelle für beide Bilder : SAP-Hilfedokumentation]
- Wann wird der Infotyp also wirklich geteilt?
- Es ist möglich, aus Gründen der Altlasten alle Daten zu migrieren, aber nur Teile der Daten zu integrieren. Z.B. 0009 - es ist möglich, dass die Migrationsvorlage alle 0009-Felder unverändert in SF kopiert. Bei der Integration werden jedoch nur IBAN und Zahlungsmodus (z. B. Überweisung) integriert ist.
- Bei der Migration wird eine unternehmensweite Mitarbeiteraktualisierung durchgeführt, z. B. eine Änderung des Benutzernamens. Dies führt zu einer Aufteilung von 0105 in SAP.
- Eine zukünftige datierte Scheibe, die nach der Migration im SF-System neu angelegt wird (die nicht Teil der Migration war), führt immer zu einem Infotypsplit der aktuell gültigen Datenscheibe.
- Und schließlich, wenn es explizit auf SF mit einem Ereignis "Erstes Ereignis nach der Migration" aufgeteilt wurde. Oder er wurde bereits vor der Migration mit einem ähnlichen Ereignis in SAP aufgeteilt. Das Splitten von Infotypen war bis zur Einführung von BIB die Norm. Dies führte zu Problemen bei der rückwirkenden Abrechnung und nachgelagerte Schnittstellen wurden unnötigerweise aktiviert, was zu weiteren Komplikationen führte. Daher hat SAP mit BIB ein Konzept für den Erstlauf entwickelt, das nicht unbedingt einen expliziten Infotypsplit erfordert.
- Was macht der Initialisierungslauf eigentlich noch?
- Wie bereits erwähnt, werden Infotypsätze selektiv aufgeteilt.
- Legt ein letztes Ausführungsdatum für die an der Integration beteiligten Entitäten fest.
- Was ist Last Run Date: LRD
- Das allererste Datum für den letzten Lauf wird am Ende des ersten Laufs erstellt.
- Nehmen wir an, der erste Lauf läuft auf dem 1th Jan 2021 um 13:30, dann wird das LSRD als 01.01.2021 13:30:00 aufgezeichnet.
- Beim nächsten Lauf wird jeder Delta-Datenzuwachs in der EG, der nach dem LSRD aufgetreten ist, an HCM weitergegeben, und es wird erneut ein LRD aufgezeichnet. Dieser wird im folgenden Lauf verwendet. Solche Läufe werden als Delta-Läufe bezeichnet.
- Delta läuft: Wie oben erläutert, handelt es sich um Läufe, die nach dem Erstlauf stattfinden. Der Ankerpunkt für den LRD-Lauf ist der Initiallauf und damit der FTSD. Ohne die Festlegung eines FTSD gibt es keine Möglichkeit für einen Delta-Lauf.
- Zu einem beliebigen Zeitpunkt kann bei Bedarf der Erstlauf erneut durchgeführt werden. Dabei wird wieder auf dieselbe FTSD Bezug genommen. Der FTSD ist also für eine Integration in Stein gemeißelt. Einmal festgelegt, kann sie nicht mehr geändert werden.
Endgültiger Stand von Mary Mustermanns Data Slices bei der Integration:
| Migration | Integration | ||||||
| Veranstaltung | Ereignis Grund | Datum des Beginns | Enddatum | Veranstaltung | Datum des Beginns | Enddatum | Kommentare |
| Mieten Sie | MIGRATION | 01.01.1991 | Mieten Sie | 01.01.1991 | 31.12.1998 | Unberührte | |
| Daten ändern | 01.01.1999 | 31.08.2002 | Unberührte | ||||
| Daten ändern | 01.09.2002 | 31.12.2014 | Unberührte | ||||
| Daten ändern | 01.01.2015 | 31.12.2018 | Unberührte | ||||
| Daten ändern | 01.01.2019 | 31.12.2021 | Wenn sich die Daten zwischen SF und SAP unterscheiden, gibt es einen Split. Es ist möglich, dass einige Infotypen gesplittet werden, während andere nicht gesplittet werden. | ||||
| Daten ändern | Daten ändern Abgeschnittene Scheibe | 01.01.2021 | 31.12.2021 | Daten ändern | |||
| Daten ändern | Daten ChangeFuture datierte Scheibe (kommt so an wie sie ist) | 01.01.2022 | 31.12.9999 | 01.01.2022 | 31.12.9999 |
Schlussfolgerung:
- Alles, was hier geschrieben wird, basiert ausschließlich auf unseren (INTEGRTR's) Erfahrungen mit LE und oberen KMU-Kunden.
- Unsere Erfahrungen mit der Migration beruhen ebenfalls ausschließlich auf dem BIB/Infoporter von SAP. Andere Migrationslösungen wie Clone and Test von Accenture sind anders konzipiert und können sich anders verhalten.
- Schließlich ist der Weg eines jeden Kunden zur Migration und erfolgreichen Integration einzigartig. Die Sensibilität des Unternehmens und die Realitäten vor Ort diktieren und übertrumpfen alle bekannten Weisheiten.
