Das sog. Core Hybrid Szenario ist eines unter vielen möglichen Bereitstellungsoptionen, mit welchem SAP-Anwenderunternehmen ihr existierendes SAP HCM On-Premise System, mit dem cloudbasierten SAP SuccessFactors integrieren können. Dies gilt insbesondere, wenn eine Entgeltabrechnung und die Zeitwirtschaft in Verwendung sind. Aber wie genau lässt sich eine solche hybride Systemlandschaft optimal umsetzen? Wie lässt sich diese im produktiven Tagesgeschäft beherrschen? Und was kann die Business Technology Platform in Sachen Standard-Integration leisten – oder auch nicht leisten? Diesen Fragestellungen gehen projekt0708 Geschäftsführer Michael Scheffler und sein Gast, Wolfgang Domaschka Teamlead Technology bei projekt0708, auf den Grund.
Ergänzende Informationen zu dieser Episode:
On-Demand Webinar: “Hybride Welten - Integration von SAP SuccessFactors und SAP HCM. Fokus: Core Hybrid & Talent Hybrid"
Das Interview zum Nachlesen
Michael Scheffler:
Herzlich willkommen zu dieser Folge von HR-IT-Talk, mein Name ist Michael Scheffler. Servus Wolfi, willkommen bei HR-IT-Talk. Danke, dass du dir heute die Zeit genommen hast unseren ZuhörerInnen einen tiefen Einblick in das Thema hybride Systemlandschaften zu geben. Das ist ja heute unser Thema. Dabei werden wir uns im ersten Schritt über die verfügbaren technischen Optionen der SAP-Anwenderunternehmen unterhalten und dann im Speziellen auf das Modell des Core-Hybrid-Modells eingehen. Aber dazu dann später mehr. Kannst du bitte zuvor im ersten Schritt ein paar Worte über dich persönlich sagen? Und so viel vielleicht vorab, du hast eine sehr niedrige Personalnummer bei projekt0708.
Wolfgang Domaschka:
Ja, da hast du recht. Es ist sogar die Nummer 1. Aber erstmal hallo von meiner Seite und freut mich, dass ich heute dabei sein darf. Ja zu meiner Person, ich bin jetzt auch schon relativ lang aus meiner Sicht im SAP-Bereich unterwegs, es sind jetzt 14 Jahre und davon auch schon 12 bei projekt0708. Ich bin als Personalnummer 1 gestartet, hatte somit auch so ein bisschen das Glück zu sehen, wie die Firma gewachsen ist. Wir haben ja so als Startup losgelegt. Mittlerweile sind es ja doch über 50 Mitarbeiter, war schon spannend so die letzten 12 Jahre das alles zu beobachten.
Ich komme klassisch aus dem On-Premise-Bereich wie du ja auch. In den Jahren zuvor habe ich eigentlich hauptsächlich On-Premise-Projekte natürlich auch betreut, verschiedenste Themen, alles, was sich ums Thema HR dreht und dabei hauptsächlich die Themen HR-Core, also Personaladministration oder auch Organisationsmanagement betreut, aber auch andere Module wie Performance Management, Vergütungsmanagement und Prozessdigitalisierung. Seit 2020 kümmere ich mich auch um das Thema Integration zwischen SAP-HCM und Employee Central und dabei hauptsächlich um den Core-Hybrid.
Auch an mir ist die Cloudwelt nicht vorbeigefahren, sondern ich bin intensiv beschäftigt mit dem Thema und ich leite hier auch mittlerweile unser internes Team, das sich hauptsächlich mit diesem Thema beschäftigt und da haben wir alle Hände voll zu tun.
Bereitstellungsoptionen für hybride SAP-Systeme im HR-Kontext
Michael Scheffler:
12 Jahre, Wahnsinn! Ging schnell, so im Rückspiegel betrachtet. Ja danke, Wolfi, für die Vorstellung. Dann lass uns inhaltlich mal bitte durchstarten. Ganz global gesprochen, welche Bereitstellungsoptionen existieren denn im SAP-Umfeld, um hybride Systeme, also On-Premise, aber auch Cloudlösungen der SAP natürlich immer im HR-Kontext miteinander zu integrieren? Kannst du uns da mal einen Überblick verschaffen bitte.
Wolfgang Domaschka:
Wenn wir natürlich jetzt hier über On-Premise und über Cloudlösungen sprechen, dann ist das, was uns größtenteils betrifft einmal die On-Premise des SAP-HCM, also die klassische On-Premise-Lösung und in der Cloudlösung sprechen wir von SuccessFactors. Da sind zum einen inbegriffen die ganzen Talent Management Module, aber eben auch Employee Central für den HR-Core. Gerade für diese Konstellation, dass die Firmen eigentlich aus dem On-Premise-Bereich kommen und jetzt eben in die Cloud gehen wollen oder wechseln wollen, hat sich die SAP verschiedene Bereitstellungsoptionen ausgedacht.
Ich versuche mal einen kleinen Einblick zu geben in die verschiedenen Optionen. Ich denke mal so die klassischste Version, die jetzt auch schon seit Längerem auf dem Markt ist, ist der Talent-Hybrid. Talent-Hybrid bedeutet, dass eben die HR-Kernprozesse wie z. B. Personaladministration oder auch das Org-Management, aber auch die Abrechnungen und die Zeitwirtschaft, dass die weiter im HCM bleiben, also On-Premise. Aber alles, was so rund um das Thema Talentmanagement geht, dass das eben vorab schon in die Cloud ausgelagert wird. Das ist eigentlich eine sehr häufig eingesetzte Variante.
Eine zweite Option, die die SAP bereitstellt, ist das sog. Side by Side. Side by Side wird dann interessant, wenn es sich um große, global agierende Unternehmen handelt. Dann wäre z. B. eine Vorgehensweise, dass man sagt „ein Teil der Unternehmung geht in die Cloud“, d. h. dann wirklich Full-Cloud, d. h. alles, was um die Mitarbeiter, sowohl HR-Core als auch Talentmanagement ist dann cloudgehostet. Das Headquarter bleibt z. B. weiterhin im HCM. Gerade bei großen Unternehmen ist es auch einfach nicht so einfach möglich zu sagen „wir machen jetzt den kompletten Big Bang und steigen eben von einer Lösung auf die andere um“ und dadurch ist es halt eben eine Möglichkeit so einen kleinen Zwischenschritt zu machen, d. h. Side by Side interssant zum einen für global agierende Unternehmen, aber auch eben Unternehmen, die nicht sofort alles in einem Step machen sollen. Sie wollen sich vielleicht erstmal angucken „wie funktioniert die Cloudlösung in einer unserer kleinen Bereiche?“, das kann natürlich auch länderbasiert sein, um dann so peu à peu den Übergang in die Cloud zu schaffen.
Wobei man auch sagen muss, dass die Empfehlung von der SAP dahingehend natürlich immer ist, lieber einen Big Bang zu machen. Das reduziert einfach insgesamt die Gesamtaufwände und macht das Ganze auch weniger komplex. Am Ende ist das aber bei wirklich großen Firmen auch unrealistisch in einem Big Bang die ganze Umstellung zu machen. Als dritte Option, die für uns relevanteste Option, ist der sog. Core-Hybrid. Im Core-Hybrid ist es so, dass man so einen zweifachen Ansatz hat. Zum einen gehen die Kernprozesse, also Personaladministration und Organisationsmanagement werden in die Cloud verlagert und auch zusammen mit dem Talentmanagement beispielsweise, wenn im Einsatz, aber die Gehaltsabrechnung und auch das Zeitmanagement bleiben weiterhin On-Prem.
Der Grund dahinter ist eigentlich ganz simpel, dass Stand jetzt eben die Gehaltsabrechnung und die Zeitwirtschaft im SuccessFactors Employee Central noch nicht ganz ausreichend sind. Da gibt’s noch ein paar Punkte, die nachzuarbeiten sind von SF-Seite und somit die Kunden das noch nicht als Option sehen, um ihre Gehaltsabrechnung On-Premise abzulösen. Daraus entstanden ist so dieses Core-Hybrid-Szenario, dass dann auch gleichzeitig dieses Integrationsszenario mit sich bringt, d. h. man bringt einmal alle Daten aus dem SAP-On-Premise nach SuccessFactors Employee Central und hat dann aber eine stetige Replikation, also ein Zurückspielen der Daten aus SuccessFactors, um halt eben die Zeitwirtschaft und auch die Gehaltsabrechnung weiter am Laufen zu halten.
Vielleicht der Vollständigkeit halber, es gibt noch die beiden anderen Optionen. Einmal die Full-Cloud, d. h. SAP-On-Premise wird komplett abgeschaltet und alles geht in die Cloud und noch als letzte Option Full-On-Premise, das ist ja das Vergangenheitsmodell, dass die Cloudlösungen gar nicht zum Einsatz kommen.
Integration von Mitarbeiter- und Organisationsdaten in hybriden SAP-Systemen: Ein detaillierter Blick auf das Core-Hybrid-Szenario
Michael Scheffler:
Danke, Wolfi, für den Überblick. Wir möchten uns ja in der heutigen Podcastfolge schwerpunktmäßig über den Core-Hybrid unterhalten. Du hast es gerade schon angedeutet, das ist das Modell, was bei unseren Kunden mit am häufigsten in Verwendung ist. Viele SAP-Anwenderunternehmen, die betreiben eine Abrechnung, die betreiben eine Zeitwirtschaft On-Premise und müssen die natürlich auch am Laufen halten. In diesem Szenario wird ja SAP SuccessFactors EC, also Employee Central, als sog. Master führend für Personal- und Organisationsdaten eingesetzt, also die personalwirtschaftlichen Stammdaten liegen in der Cloud.
SAP-HCM hingegen wird als sog. Slave der Empfänger dieser Stammdaten und verarbeitet diese dann in Hinblick auf Payroll und Zeitwirtschaft. Kannst du uns bitte nochmal im Detail erläutern, welche Objekte genau in diesem Szenario wo liegen und wie da die Integration und Interaktion zwischen diesen beiden Welten ist? Das ist ja noch eine sehr komplexe Situation und deswegen, glaube ich, ist es spannend wenn du uns das nochmal etwas detaillierter erläutern würdest.
Wolfgang Domaschka:
Ich würde sagen unterteilen kann man es eigentlich in drei Blöcke, die man betrachten muss. Zum einen sind es natürlich die Mitarbeiterdaten als ein Block. D. h. man möchte alles, was jetzt den Mitarbeiter betrifft, also seine Stammdaten aus dem HCM ins EC bekommen. Im SAP spricht man da ja von Infotypen und im Employee Central spricht man dabei von Entitäten, die Gruppierungen von bestimmten Feldern beinhalten. D. h. Mitarbeiterdaten ist immer ein großer Teil, der eben einmal migriert werden muss von SAP nach Employee Central und sobald diese Migration abgeschlossen ist, erfolgt dann die Pflege ausschließlich im Employee Central und dadurch muss auch eine Replikation erfolgen.
Neben den Mitarbeiterdaten sind der zweite große Block die Org-Daten, die man immer betrachten muss. Bei Org-Daten sprechen wir dann von Organisationseinheiten, von Planstellen, von Stellen, die auch teilweise im Eins-zu-Eins, teilweise nicht ganz identisch wiederzufinden sind im Employee Central. Mit Eins-zu-Eins meine ich, bei Organisationseinheiten ist es z. B. so, dass es im EC dafür mehrere Möglichkeiten gibt das abzubilden, da würde ich später auch nochmal genauer drauf eingehen. Planstellen haben auch eine ähnliche Konstellation oder ein ähnliches Konstrukt im SAP-HCM wie im EC genauso.
Es sind schon feine Unterschiede da, die bei solchen Projekten beachtet werden müssen. Generell neben den Mitarbeiterdaten gibt’s eben auch die Organisationsdaten, die dann übertragen werden. Als dritten Teil, den wir immer noch betrachten müssen, sind das die Kostenstellen. Bei den Kostenstellen ist es so, dass die meistens gar nicht aus dem HCM-System kommen, sondern aus dem Finance and Controlling System. Dabei bleibt es eigentlich immer so, dass es keine Replikation aus dem SF zurück gibt, sondern die Pflege bleibt eigentlich im Finance and Controlling System und da werden die Kostenstellen einfach immer wieder stetig von da aus migriert.
Bei Mitarbeiterdaten und Org-Daten haben wir das Setup, wir migrieren zuerst alles und danach wird repliziert. Bei Kostenstellen bleibt die Pflege weiterhin im Finance and Controlling System.
Michael Scheffler:
D. h. technisch gesprochen, wenn ich dich jetzt richtig verstehe, ist dann auch immer ein ERP- oder S4-System involviert bei einer solchen Schnittstelle in so einer hybriden Variante?
Wolfgang Domaschka:
Exakt. Man kann die Kostenstellen aus beiden Systemen in SuccessFactors replizieren. Zum einen könnte man es aus dem Fico-System ziehen. Man kann aber auch das HCM-On-Premise-System verwenden. Aus Zukunftssicht, wenn man sagt, man möchte z. B. längerfristig damit planen HCM abzuschalten, dann macht es z. B. mehr Sinn das Fico-System als Quersystem zu verwenden. Viele Kunden entscheiden sich ja auch das HCM-System zu nutzen, um halt eben nur eine Quelle für die Replikation zu haben. Das ist beides möglich.
Infotypen und Datenintegration in hybriden SAP-Systemen: Strategien und Entscheidungsprozesse im Detail
Michael Scheffler:
Verstehe und da wird dann auf HCM-Ebene wahrscheinlich noch über ALE-Technologie aus dem Fico-System die Kostenstellenübertragung geleistet?
Wolfgang Domaschka:
Exakt. Das ist die Basis. Das Senden der Daten ist dann nicht ALE, aber die Basis ist eben diese ALE-Verteilung.
Michael Scheffler:
Gut, habe ich verstanden. Spannende Sache, d. h. in Abhängigkeit von dem jeweiligen Szenario muss man dann auch die Infotypen jetzt mal in klassischer SAP-HCM-Terminologie gesprochen dem Szenario zuordnen und replizieren?
Wolfgang Domaschka:
Genau. Da wird es nochmal spannend. Es ist natürlich so, dass wir gesagt haben, wenn alle Daten der Mitarbeiter nach Employee Central migriert sind, wird Employee Central führend für die Datenpflege. Das bedeutet aber nicht, dass komplett alle Daten in Zukunft immer in Employee Central gepflegt werden, sondern es kann auch je nach Definition festgelegt werden, dass die Pflege für bestimmte Daten im HCM bleibt. Das ist eigentlich das, was man zu Beginn des Projekts mit dem Fachbereich erörtert.
Erstmal braucht man eine Aufstellung „welche Infotypen werden überhaupt benötigt? Welche sind im Einsatz im HCM? Welche sollen in Zukunft im EC gepflegt werden?“ und dann muss man eben immer Infotyp für Infotyp für alle Daten definieren „bleiben die im HCM? Wird die Pflege zukünftig im Employee Central stattfinden?“.
Michael Scheffler:
Und das betrifft wahrscheinlich auch die kundeneigenen Infotypen?
Wolfgang Domaschka:
Exakt. Da ist es dann eigentlich gut gemacht von SAP, man kann auch sehr schnell kundeneigene Infotypen in die Integration mit aufnehmen. Ist aber natürlich immer, je mehr Infotypen desto komplexer wird am Ende ein Projekt, weil man muss nicht nur auf SAP-Seite die Konfiguration vorgenommen werden, dass diese übertragen werden können, sondern es muss auch auf Employee Central Seite was gemacht werden. Diese kundeneigenen Infotypen werden in kundeneigene Entitäten am Ende überführt und die müssen auch erstmal angelegt werden.
Je mehr Standard, desto schneller und einfacher ist eine Integration, aber natürlich haben die meisten Kunden auch kundeneigene Infotypen. Vielleicht noch ergänzend, auch mal so als Beispiel, dass man sagt „welche Daten bleibt im HCM oder welche sind nur im EC?“. Man kann das ein bisschen unterscheiden. Klassische Daten, die dann nach einem Liveschalten von Employee Central ausschließlich im Employee Central gepflegt werden sind persönliche Daten, also die Namen, Vorname, Nachname usw. Adressdaten ist ein Klassiker, die Bankdaten und auch die Vergütungsinformationen. Das wird in der Regel im Employee Central gepflegt.
Es gibt aber auch Daten, die nach der Migration auch weiterhin im HCM gepflegt werden. Da wäre z. B. eine Möglichkeit, es gibt den sog. Infotyp 105, da sind verschiedene Kommunikationsdaten beinhaltet, da kann man z. B. die E-Mail-Adresse mit erfassen, die Telefonnummer usw. und da ist es halt manchmal so, dass Kunden eigene Kommunikationsarten benutzen, die sie für irgendwelche Prozesse verwenden, die aber nicht zwangsläufig nach Employee Central gebracht werden müssen, weil sie da eigentlich nur als Information liegen, um irgendwelche HCM-Prozesse abzubilden. Man kann eigentlich immer generell sagen, man muss sich bei allen Daten, die man migrieren will, hinterfragen „brauche ich diese Daten zwangsläufig im EC oder wollen wir die zukünftig gar nicht mehr pflegen?“.
Michael Scheffler:
Und in dem Beispiel was du gerade gebracht hast mit dem Infotypen Kommunikation, da würde man ja sicher sogar auf Subtypenebene sich entscheiden müssen, was im SAP-HCM als Master verbleibt und was dort dann als Slave aus dem EC rüberkommt. Ist das richtig?
Wolfgang Domaschka:
Exakt.
Technische Architektur und Integration in hybriden SAP-Systemen: Die Rolle der Business Technology Platform und Unterschiede zwischen Daten- und Prozessintegration
Michael Scheffler:
Gut, das macht die Sache nicht einfacher. Wie sieht denn die zugehörige technische Architektur im besten Falle aus? Welche Voraussetzungen sind denn zu erfüllen seitens des SAP-Anwenderunternehmens? Also Stichwort Business Technology Platform, kannst du uns dazu was sagen?
Wolfgang Domaschka:
Wenn wir beim Beispiel Core-Hybrid bleiben, der Weg, wie die Integration laufen soll, ist da schon weitestgehend vordefiniert. Wenn wir uns die Systemlandschaft angucken, haben wir natürlich das SAP-HCM-System erstmal als ursprüngliches Quellsystem für die Migration. Dann haben wir auf der anderen Seite Employee Central und in der Mitte, wie du gerade eben schon angesprochen hast, fungiert dann die Business Technology Platform mit der sog. Cloud Platform Integration als Mittelware. Das ist so das Setup, das man dann hat. Da muss man sich im Projektbeginn über die Systemlandschaft entsprechend Gedanken machen. Wie wollen wir die verschiedenen Systeme miteinander verbinden? Was bekommen wir von der SAP zur Verfügung gestellt? Wo müssen wir noch was lizensieren?
Das sind so diese Grundfragen, die man zum Thema Systemlandschaft sich stellen muss. Aber dieser Weg ist erstmal gesetzt für den Core-Hybrid für die Standardintegration. Wenn man sich den Datenfluss anschaut, da vielleicht interessant, diese ganze Steuerung, also wann werden Daten abgeholt? In welchen Zyklen, periodisch? Da ist der Initiator oder der Verwalter mehr oder weniger das HCM-System, also das On-Premise-System. Diese Abfragen „jetzt hat sich was an meiner Adresse geändert“, diese Abfrage wird immer aus dem HCM-System heraus gestartet.
Aus Sicht des Datenflusses kann man sich das gut vorstellen, das HCM startet eine Abfrage, das geht über die Mittelware entsprechend über sichere Wege bis ins EC. Da wird dann gefragt „hat sich irgendwas geändert?“ und wenn sich was geändert hat, wird eben diese Information, ob sich was geändert hat, zurückgespielt, wieder über die Mittelware ins HCM-System.
Michael Scheffler:
Also das ist quasi ein Pull-Prinzip? SAP-HCM fordert die neue Information via Business Technology Platform im SF an und dadurch wird das dann verarbeitet und ggfls. zurückgeschickt?
Wolfgang Domaschka:
Genau. Es gibt eine Ausnahme. Das ist die sog. Push-Replikation. Da kann man ein zusätzliches Szenario noch mit on top setzen, um für bestimmte Prozesse im Employee Central eine schnellere Datenverarbeitung anzustoßen. Da ist immer der Klassiker, es wird jemand eingestellt und dann wird ein Teil der Daten im Employee Central gepflegt, dann muss aber um z. B. eine erfolgreiche Gehaltsabrechnung durchführen zu können, müssen im HCM noch Daten gepflegt werden.
Damit dieser Versatz während einer Einstellung oder der Zeitraum, wie ein Sachbearbeiter eine Einstellung durchführen kann, nicht zu groß wird, gibt es eine sog. Push-Replikation. D. h. der Sachbearbeiter stellt im SF jemanden ein und auf diese Einstellungsmaßnahme wird direkt im HCM-System diese Abfrage ausgelöst, um die geänderten Daten abzuholen, d. h. man hat einen relativ schnellen Übertrag vom EC nach HCM.
Michael Scheffler:
Das ist ein guter Punkt, was du hier ansprichst. Wir haben jetzt viel über das Thema Datenintegration gesprochen und das was du gerade hier thematisierst, ist ja eine Prozessintegration. Wo ist denn hier der Unterscheid? Kannst du uns das mal erläutern bitte?
Wolfgang Domaschka:
Ich denke mal Datenintegration ist das, worüber wir gerade klassisch gesprochen haben. Man nimmt sich bestimmte Informationen, entweder aus dem HCM oder aus dem Employee Central, macht dann das entsprechende Mapping „wo sollen die Daten landen in den korrespondierenden Systemen?“ und dann werden diese Daten transferiert. Jetzt haben wir aber wie gerade eben angesprochen so ein bisschen dieses Thema, jetzt haben wir eine Person, die tritt neu ein und da wir immer noch die Konstellation haben, dass z. B. die Abrechnung weiterhin im SAP-HCM stattfindet, müssen dahingehend entsprechende Infotypen gepflegt werden, es müssen Daten ergänzt werden, die wir gar nicht im Employee Central vorrätig haben und was auch zum Stand jetzt auch gar keinen Sinn macht die zum Employee Central zu bekommen.
Da kommt eben die Prozessintegration ins Spiel. Prozessintegration würde ja dahingehend bedeuten, man startet eine Einstellungsmaßnahme im Employee Central und füllt dann alle Daten aus, alles, was eben notwendig ist, die Daten zur Person, die Adresse, die Bankverbindung und spätestens wenn man eben alle Daten vollständig gepflegt hat, wäre der Workflow im Employee Central erstmal abgeschlossen und das HCM-System würde gar nichts mitbekommen und hätte dann eigentlich einen „Workflow-Bruch“ und es müsste auf irgendeinem Weg der Sachbearbeiter mitbekommen, dass er im HCM auch noch was pflegen muss.
Da hat die SAP ziemlich brandneu eine neue Technologie mit ins Spiel gebracht und zwar den Cross-System-Workflow. Der ermöglicht es Workflows, die im SF gestartet wurden, also z. B. eine Einstellungsmaßnahme dann eben auch wieder über die gleichen Mittelware, über die BTP ins HCM zu bringen und dort diesen Workflow aufzugreifen und wiederum eigene Workflows zu starten. Das läuft dann über die Technik „Prozesse und Formulare“ und das ist auf jeden Fall eine sehr spannende Technik, die wir gerade am Ausarbeiten sind, die ist noch sehr neu. Ich glaube zweites Halbjahr 2022 jetzt mal veröffentlicht worden. Da sind wir gerade dran. Könnte auf jeden Fall vielen Kunden das Leben vereinfachen.
Out-of-the-Box-Integration und der Business Integration Builder: Möglichkeiten und Grenzen für SAP-Anwenderunternehmen
Michael Scheffler:
Prozesse und Formulare ist ja ein Thema, was uns schon seit vielen Jahren umtreibt. Als Organisation haben wir viele Projekte machen dürfen und das auch wieder die SAP hier drauf setzt, super spannend. Ich würde gerne noch auf ein weiteres Thema zu sprechen kommen und zwar die sog. Pre-Package-Integration-Solutions der SAP. Mich würde mal interessieren, was jetzt alles von dieser Integration, die du angesprochen hast, im Standard abbildbar ist.
Was ist da out of the box möglich für die SAP-Anwenderunternehmen? Wo endet der Standard? Vielleicht kannst du uns da ein bisschen was erzählen. Und um das Ganze nochmal abzuschließen, was ist genau der Business Integration Builder? Kannst du uns da ein bisschen aufschlauen bitte.
Wolfgang Domaschka:
Also diese sog. Pre-Packaged-Solutions oder auch Integrationsszenarien sind von der SAP ausgelieferte, vordefinierte Pakete, die sich zu den einzelnen Integrationsmöglichkeiten oder damit ergänzend daherkommen. Es gibt z. B. für den Core-Hybrid, wenn man sich für diese Lösung entscheidet, gibt es bestimmte Integrationsszenarien, die man dann nutzen kann. Ein Integrationsszenario wäre z. B. ich übertrage Mitarbeiterdaten und ich repliziere Mitarbeiterdaten. Ein drittes und viertes Integrationsszenario wäre dann, ich migriere Org-Daten und ich repliziere wieder Org-Daten und auch die Kostenstellenreplikation ist ein eigenes Integrationsszenario.
Es gibt natürlich noch weitere Integrationsszenarien und das wächst auch stetig an. Was da immer automatisch out of the box mitkommt, ist für die wichtigsten Infotypen sowohl im Mitarbeiterbereich als auch im Organisationsmanagement-Bereich, dass da schon mal vorgefertigte Mappings und vorgefertigte Wege ausgeliefert werden, d. h. man muss jetzt, wenn man z. B. sich komplett am Standard halten würde und keine kundeneigenen Infotypen, Felder alles im Standard wäre, dann könnte man relativ schnell über diese Pre-Packaged-Soluations eine Verbindung zum SF EC herstellen und da einfach schon mal Daten übertragen. Das, was im Standard ausgeliefert wird, kann man dann relativ schnell nutzen.
Um das Ganze zu nutzen, um vielleicht auf den BIB zu sprechen zu kommen, das haben sicherlich schon mal die einen oder anderen gehört, die sich mit dem Thema beschäftigt haben, also der BIB ist das Herz der Integration. Das ist die technische Grundlage, die diese Integrationsszenarien verwenden. Was da gemacht wird, zum einen bietet das verschiedene Customizing-Möglichkeiten, um die Verbindung herzustellen zwischen den Systemen, d. h. wie man das HCM-System mit der Mittelware verbindet, mit der CPI und auch mit dem SF EC. Es gibt bestimmte Grundkonfigurationen, die vorgenommen werden müssen und am wichtigsten, es wird eine Unterstützung geliefert zum Mapping der Felder.
Das sind die sog. Transformation Templates. Da wird für jeden Infotypen die entsprechende Employee Central Entität aus EC gegenübergestellt und dann wird Feld für Feld durchgegangen und ein Mapping vorgenommen. Bspw. ich möchte eine Person mappen und dann mappe ich den Vornamen im SAP auf den Vornamen im EC, Nachname genauso und dann mappe ich z. B. noch das Geschlecht der Person und da kommt nochmal eine weitere Komponente ins Spiel und zwar das Auswahllistenmapping. Das ist noch ein wichtiger Bestandteil, der vorgenommen werden muss.
Die Werteliste sind eben nicht identisch im SAP-HCM und im EC. Wenn man z. B. sagt „männlich“, bedeutet das im HCM technisch eine „1“. Im EC ist es „M“ und somit muss man eben sagen „1 soll zu M gemappt werden“ und das sind solche Feinheiten, die am Anfang so ein bisschen Fleißarbeit bedeuten, aber da liefert die SAP aber auch schon einige Beispielwerte vor. Was ich bisher noch bei keinem Projekt hatte, ist, dass man nicht selber programmieren musste. Das ist das, was so ausgeliefert wird. Dass man nur per Customizing alles mappt, da müsste das SAP-System noch sehr jung sein und vielleicht mit einer geringen Population, aber wenn das System schon länger am Laufen ist und auch mehrere kundeneigene Infotypen dazukommen, dann kommt man eigentlich nicht drum herum selber etwas zu implementieren.
Die SAP bietet immer neben dieser Möglichkeit einfach nur zu mappen auch immer die Möglichkeit etwas zu implementieren per Buddys. Diese Buddys sind Schnittstellen, um Coding an gewissen Stellen zu hinterlegen. Das ist eigentlich in jedem Projekt bisher notwendig gewesen.
Michael Scheffler:
Gut, aber die gute Nachricht ist, man kann dort flexibel eingreifen und mittels Quellcode auf das Mapping einwirken.
Wolfgang Domaschka:
Genau. Wenn man jetzt sagt man möchte die Organisationsdaten migrieren, dann ist es ja so, dass SAP ganz viel mit Vererbung arbeitet, d. h. man hat eine Aufbaustruktur und man pflegt an oberster Stelle eine Kostenstelle, d. h. dann ist diese Kostenstelle für alle darunterliegenden Organisationseinheiten und Planstellen eben maßgebend, wenn nicht in der Zwischenebene nochmal eine weitere Kostenstelle zugeordnet wird.
Dieses Prinzip kennt aber SuccessFactors nicht und auch die Migration kennt das erstmal so nicht. An der Stelle muss man eben sagen, wenn man nicht gerade die oberste Org-Einheit überträgt an der die Kostenstelle direkt zugeordnet ist, dann muss man da eben programmieren und sagen „was ist deine Kostenstelle?“ und das kann man nicht einfach nur mappen. Das ist ein so ein Klassiker.
Ablauf eines Integrationsprojekts: Schritte und Vorbereitungen für eine erfolgreiche Umstellung auf den Core-Hybrid-Ansatz
Michael Scheffler:
Mich würde interessieren, wie genau läuft ein solches Integrationsprojekt im Detail ab? Der von dir eben skizzierte Core-Hybrid, wie gehen wir hier bei unseren Kunden vor? Wie würdest du so ein Vorhaben angehen? Kannst du das mal beschreiben?
Wolfgang Domaschka:
Gerne. In dem Format macht es Sinn, dass ich mir vielleicht die wichtigsten Schritte mir ein bisschen herauspicke. Was immer ganz wichtig ist, ist die Vorbereitung des SAP-HCM-Systems und auch des Fico-Systems, ich hatte zuvor ja erwähnt, dass der BIB die Basis ist, auf der gearbeitet wird und die ist erstmal nicht so out of the box in jedem System vorhanden. Man muss ein sog. Integration Package installieren, das PASIEN-Package und das beinhaltet alles, was man braucht für die Integration und eben diesen BIB.
Ähnliches gibt es für die Kostenstellenreplikation, d. h. der erste Schritt ist eigentlich so, man macht erstmal eine technische Systemanalyse, guckt „sind die ganzen Voraussetzungen da? Ist das SAP-System vorbereitet? Ist die Mittelware im Einsatz?“.
Das sind so die Vorbereitungsschritte. In einem weiteren wichtigen Step geht’s dann erstmal um die Datenanalyse. Zum einen ist es wichtig aus SAP-HCM-Sicht, aber auch aus Employee Central Sicht, d. h. man analysiert „welche Daten sind im HCM im Einsatz momentan? Was will man im Employee Central in Zukunft abbilden?“.Was will man vom Employee Central Best Practise nutzen?
Es gibt ja von der SAP einen bereits von der SAP ausgelieferten Employee Central Best Practise, wir haben auch einen P78 Best Practise, den wir entwickelt haben auf Basis der Implementierungsprojekte bisher und da muss einfach mal eine Datenanalyse gemacht werden und aus dieser Datenanalyse entstehen dann die Employee Central Workbooks. Ich glaube jeder, der schon mal mit SuccessFactors oder in Implementierungsprojekten gearbeitet hat, kennt diese Workbooks. Die gibt’s ja zu den verschiedenen Modulen und auch für EC gibt’s ein Workbook und das ist mal so die Voraussetzung, dass dieses Workbook am Ende gefüllt ist. In diesen Workbooks geht’s eigentlich nur darum zu sagen „welche Felder, welche Portlets wollen wir nutzen und welche Felder davon und wie sind die Eigenschaften der Felder? Ist es ein verpflichtendes Feld? Wird es vielleicht gar nicht erst angezeigt?“.
Und daraus ableitend entstehen dann die Integration Workbooks. Die sind auch immer sehr wichtig. Die Integration Workbooks beinhalten dann alle Felder, die in den EC-Workbooks definiert wurden, d. h. man nimmt da alles mit auf, weil man will das im Zweifel ja auch befüllen aus dem SAP-HCM, was man später im EC anzeigen will und ergänzt dann dahingehend das Mapping zum HCM und entsprechend vielleicht die Information, ob hier eine eigene Logik noch hinterlegt werden muss.
Auf dieser Basis wird dann das Customizing vorgenommen im BIB. Wenn eben diese Steps abgeschlossen sind, Datenanalyse, danach die Zielkonfiguration inklusive Workbooks, dann die Integration und BIB-Customizing, dann erfolgt zum Go-Live in einer Cut-Over-Phase die Datenmigration. Man muss sich da irgendwann mal auf ein bestimmtes Go-Live-Datum einigen. Das ist auch das sog. Cut-Over-Date.
Zu diesem Datum werden dann alle Daten aus dem SAP-HCM migriert, d. h. man macht einmal einen Fullload aus dem HCM ins Employee Central und dann nach der Datenvalidierung selbst findet der Startschuss zur Replikation statt und ab dann ist Employee Central führend als System. Das sind im Groben die wichtigsten Schritte, die da sind. Im Detail steckt noch viel mehr dahinter, auf EC-Seite müssen alle Prozesse definiert werden usw. und auf Integrationsseite gibt’s noch einige Dinge, die im Detail besprochen werden müssen, aber so mal die groben Schritte.
Michael Scheffler:
Das Testen ist wahrscheinlich auch nicht ganz unwesentlich an der Stelle.
Wolfgang Domaschka:
Genau. Testen und vor allem auch, was ein großer Aufwand auf Kundenseite ist, das haben wir auch schon festgestellt, dass das meistens unterschätzt wird an der Stelle.
Bewältigung einer komplexen Hybrid-Systemlandschaft: Tipps und Empfehlungen für den reibungslosen Betrieb und den Umgang mit Herausforderungen
Michael Scheffler:
Das kann ich mir vorstellen. Das Projekt ist abgeschlossen, die Daten wurden erfolgreich migriert und integriert. Wie geht’s weiter? Wie lässt sich eine solche komplexe hybride Systemlandschaft im Tagesgeschäft eigentlich beherrschen? Wie kann man da den Betrieb sicherstellen? Hast du da ein paar Erfahrungswerte für uns?
Wolfgang Domaschka:
Idealerweise läuft alles rund (lacht). Es ist natürlich nicht so. Man hat halt verschiedene Abhängigkeiten. Zum einen hat man eine komplexe Systemlandschaft, also man hat ein HCM-System, man hat eine Mittelware, man hat ein SF-System. Man hat sogar noch einen Cloud Connector. Es kann eben an verschiedenen Stellen haken, sagen wir es mal so. Es kommt irgendwo ein Fehler hoch und man weiß eventuell nicht genau, woran es liegt. Es kann eben passieren. Deswegen muss man bei der Fehleranalyse in verschiedenen Systemen eventuell nachgucken, falls Fehler auftreten.
Da bietet die SAP zum einen im SAP selbst das sog. Application Log, wo man gucken kann, ob was schiefgelaufen ist. In der CPI gibt’s auch so Tracing-Möglichkeiten, um Fehler zu erkennen und auf EC-Seite ist der sog. Datenreplikationsmonitor im Einsatz, der dann eben bestimmte Fehlermeldungen zurückliefert.
Michael Scheffler:
Also eine Vielzahl von Tools, die die SAP einem da an die Hand gibt, um eben nachzuvollziehen, ob irgendwas auf die Bretter gegangen ist oder auch nicht.
Wolfgang Domaschka:
Genau. Also eigentlich läuft die Replikation doch meistens relativ smooth am Ende. Es kann natürlich sein, dass es irgendwo hakt und man eben überprüfen muss und es nicht gleich einsichtig ist.
Michael Scheffler:
Wolfgang, kannst du uns zum Ende hin nochmal ein paar Praxistipps geben? Welche Empfehlungen kannst du unseren ZuhörerInnen geben? Welche Stolpersteine lassen sich denn vermeiden? Ich bin sicher du bist über den einen oder anderen gestolpert. Hast du hier Handlungsempfehlungen für unsere ZuhörerInnen? Was kannst du ihnen da sagen?
Wolfgang Domaschka:
Eine Handlungsempfehlung so aus den Erfahrungen der letzten Projekte ist immer, dass man versuchen sollte die Schnittstelle nicht zu komplex werden zu lassen. Man neigt immer schnell dazu zu sagen „das kriegen wir noch mit rein. Kann man programmieren. Kriegen wir schon irgendwie hin“.
Bei der Migration ist es vielleicht noch okay, weil Migration findet ja einmalig statt. Es wird einmalig migriert. Aber gerade bei der Replikation, wo man ja auch programmatisch eingreifen kann, ist es schon so, dass das über einen längeren Zeitraum läuft und je mehr Komplexität man da reinbringt, umso schwieriger ist es auch dauerhaft zu warten. Deswegen macht es manchmal auch Sinn zu sagen „brauchen wir das wirklich? Gerade irgendwelche Sonderlocken oder kann man das nicht besser organisatorisch vielleicht lösen?“.Es lohnt sich das in Frage zu stellen und dem Fachbereich ist meist nicht mehr klar, was das für eine Außenwirkung hat, wenn sie eine Anforderung stellen und dass man das ruhig mal challenged und sagt „muss das wirklich sein? Kann man das nicht anders lösen?“.
Das ist eine Empfehlung. Was wir festgestellt haben, meistens ist es ja so, dass wenn man das Projektsetup erstellt, dass es dann immer einen Stream gibt, der sich hauptsächlich um Employee Central kümmert. Ist ja auch klar, ist ja ein anderes Tool an sich. Es ist eine andere Technik dahinter. Aber es gibt ein Team, die kümmern sich um Employee Central, um die Konfiguration, die Business Rules und die Prozesse und es gibt einen Technikstream, der sich um die Integration kümmert. Was wir festgestellt haben, es ist extrem wichtig, dass die ganz viel zusammenarbeiten und auch die Konfiguration Hand in Hand läuft, d. h. die Replikation sehr sensibel auf vieles reagiert und besser unterwegs ist, wenn man da wirklich Hand in Hand arbeitet.
Vielleicht noch so von der Definition her, was vielleicht auch noch ein Tipp ist, was wir festgestellt haben im Zuge der Aufbaustruktur ist es einfacher die Department Only Struktur zu nutzen. Das ist auch so eine Empfehlung von der SAP. Es gibt ja die sog. Implementation Design Principles. Da gibt es zu verschiedenen Kontexten Hilfestellungen, die man abrufen kann. Das ist online auch verfügbar. Eine Empfehlung ist eben die Department Only Struktur, das bedeutet, Employee Central würde ja im Standard eine Aufbaustruktur vorsehen, in der man verschiedene Objekte hat, z. B. an oberster Stelle ist die sog. Business Unit. Das ist ein eigenes Objekt.
Darunter dann die Vision, was ein eigenes Objekt ist und darunter dann das Department. Anders als im SAP-HCM, wo wir nur Organisationseinheiten haben, ist das eine leicht andere Abbildungsvariante. Was aber in der täglichen Pflege und auch in der Umsetzung beim Migrationsprojekt dann auch ein bisschen schwieriger darzustellen ist. Das als Tipp für Aufbaustruktur immer die Department Only Struktur zu nutzen. Das sind nur Departments, die dann im Employee Central abgebildet werden.
Michael Scheffler:
Alles klar. Das waren mal super tiefe, spannende Einblicke in das Thema Integration. Ich glaube es ist rübergekommen, dass es eine sehr komplexe Situation werden kann, eine sehr anspruchsvolle Situation werden kann. An der Stelle vielen Dank, Wolfi, und ich denke wir können das zu gegebener Zeit nochmal vertiefen.
Wolfgang Domaschka:
Gerne. Auch vielen Dank für die Einladung und ich stimme dir zu, es ist ein sehr komplexes Thema und wird auch noch durch viele Punkte, die in Zukunft noch kommen werden, mit S4HANA usw. wird es nicht unspannender das Thema.
Michael Scheffler:
Das stimmt. Vielen Dank.
Hat Ihnen dieser Podcast gefallen? Dann freuen wir uns sehr über fünf Sterne bei iTunes. Feedback zu dieser Folge oder Themenvorschläge für künftige Episoden gerne per Mail an podcast@projekt0708.com.
