Die Einführung von SAP SuccessFactors, der cloudbasierten HR-Lösung von SAP, unterscheidet sich erheblich von herkömmlichen SAP HCM Projekten. Während man in der "alten Welt" bzw. On-Premise Umgebung daran gewöhnt war, Prozesse und Funktionen jederzeit anzupassen zu können, erfordert die Nutzung der Cloud eine stärkere Ausrichtung an Best Practices und dem „Standard“ des Herstellers.
Das macht ein Umdenken erforderlich, seitens des einführenden SAP-Anwenderunternehmens als auch bei dem entsprechenden Implementierungspartner. Wie die Einführung von SAP SuccessFactors trotzt dieser Herausforderung ein Erfolg werden kann, diskutieren projekt0708 Geschäftsführer Michael Scheffler und Jörg Ehrlich, Solution Architect bei projekt0708.
Ergänzende Informationen zu dieser Episode:
„Lessons Learned SAP SucessFactors Einführungsprojekte“, HR/IT Talk Episode #3 (08/2019), https://www.projekt0708.de/unternehmen/podcast/episode/lessons-learned-sap-sucessfactors-einfuehrungsprojekte.html
p78 Launch for Success Packages für SAP SuccessFactors (SAP Qualified Partner Packaged Solutions): https://www.projekt0708.de/loesungen/launch-for-success-packages-fuer-sap-hr-loesungen.html
SAP SuccessFactors Human Experience Management Suite (SAP SuccessFactors HXM Suite): https://www.sap.com/germany/products/hcm.html
Studienzusammenfassung „HR in der Cloud Hoher Nutzen, typische Herausforderungen“ von SAP und hkp/// group: https://www.hkp.com/de/article/hr-in-der-cloud-hoher-nutzen-typische-herausforderungen
Das Interview zum Nachlesen
Die Erfolgsgeschichte eines SAP SuccessFactors Experten: Ein Blick in die berufliche Laufbahn von Jörg Ehrlich
Michael Scheffler:
Damit herzlich willkommen zu dieser Folge von HR-IT-Talk, mein Name ist Michael Scheffler. Jörg, du beschäftigst dich seit Jahren in verschiedenen Rollen mit den personalwirtschaftlichen Lösungen der SAP und somit natürlich auch seit einiger Zeit mit SAP SuccessFactors, der cloudbasierten Lösung von HR. Als Solution Architect bist du bei uns maßgeblich bei großen Einführungsprojekten, national, international unterwegs, oftmals landen die wichtigen architektonischen Entscheidungen, aber auch Fragestellung im Hinblick auf das Datenmodell oder prozessspezifische Fragestellungen unserer Kunden bei dir auf dem Tisch.
Wie bist du denn zu diesem Experten geworden, der du heute bist? Kannst du vielleicht deine berufliche Laufbahn, deinen Werdegang ein wenig beschreiben? Viele, die mit uns zu tun haben, kennen dich ja bereits, aber sicherlich nicht alle Hörerinnen und Hörer.
Jörg Ehrlich:
Gerne, gerne, ich freue mich auch wieder dabei zu sein. Ist ja schon eine Weile her, dass wir zusammen einen Podcast gemacht haben.
Michael Scheffler:
2019, ich habe nachgeschaut.
Jörg Ehrlich:
Also schon ein paar Jahre. Wie bin ich zu dem Experten geworden, der ich heute bin? Das ist eine spannende Frage. Grundsätzlich beschäftige ich mich mein ganzes berufliches Leben jetzt mit dem Thema SAP HR.
Michael Scheffler:
Mein Beileid (lacht).
Jörg Ehrlich:
Ja genau. Das ist jetzt ca. 15 Jahre, ähnlich wie du auch Michael, aber nicht ganz so lange. Ich habe im On-Premise-Bereich damals angefangen, komme eigentlich aus dem Fachbereich, aus dem HR-Fachbereich im Bankenumfeld damals, ein Traineeprogramm gemacht, aber habe relativ schnell gemerkt, dass die Bits und Bytes und die Zusammenhänge in der IT und die auch zu verstehen, mich mehr reizen und habe mich quasi dahin entwickelt.
Bin jetzt auch seit über zehn Jahren bei Projekt0708 und da auch in beiden Welten anfangs unterwegs gewesen, aber dann zunehmend eben in dem Thema SuccessFactors, d. h. ich beschäftige mich jetzt seit mehr als zehn Jahren mit dem Thema SuccessFactors und habe Kunden von uns quasi auf dieser Reise mit begleitet in die Cloud zu gehen. Ich habe mich, wie ich angefangen habe, wir kannten uns ja schon vorher und da war das Thema bei unseren Kunden noch nicht wirklich existent, das Thema SuccessFactors und Cloud im Allgemeinen. Von daher ist da sehr viel in den letzten zehn Jahren passiert und ich habe quasi bei Projekt0708 das Thema SuccessFactors aufgebaut, indem ich erste Projekte übernommen habe. Ich habe angefangen im Recruiting, damals haben wir das noch selbst eingeführt bei uns, um natürlich auch uns auseinanderzusetzen mit der Software und dann immer weiterentwickelt.
Ich habe mich in die Talent-Themen eingearbeitet, d. h. Goals, Performance, Development etc. und am Anfang war ich noch ein bisschen eine One-Man-Show, was das Thema SuccessFactors anging und habe das Thema quasi bei uns in der Beratung aufgebaut, das Team aufgebaut und mich weiter ausgebildet, in den Modulen zertifiziert und war dann lange zuständig für das SuccessFactors-Team bis vor ein, zwei Jahren, habe da sehr viel Account und Projektmanagement gemacht, viel People Development, also das SuccessFactors-Teams im Endeffekt aufgebaut und vor einem Jahr aufgrund unseres Wachstum und vor dem Hintergrund, dass wir uns im HR-Consulting neu aufgestellt haben, auch organisatorisch, wollte ich eigentlich näher wieder an die Implementierung gehen und an die eigentliche Lösung. An die eigentliche Lösung, an Lösungen für Kundenherausforderungen zu finden und da bin ich in der Rolle des Solution Architects jetzt gelandet, was mir sehr viel Spaß macht.
Was mache ich da genau? Das ist recht vielfältig. Zum einen bin ich Sparringspartner für unsere Berater, wenn es darum geht, Lösungen für Herausforderungen im Projekt zu finden. Kann man einen Workaround finden oder gibt es eine einfache Erweiterung dort? Verbaut man sich etwas? Gibt es alternative Möglichkeiten?
Das sind so die Fragestellungen. Ich übernehme oftmals den eher technischeren Part in Implementierungsprojekten, wenn es geht die Lösung zu erweitern oder zu integrieren mit der AP z. B. oder wenn es um die Konzeption von SuccessFactors-Systemarchitekturen geht, also wie viele Systeme habe ich da jetzt? Brauche ich drei oder vier? Wie bekomme ich die Daten von einem System ins andere? Nicht zuletzt beschäftige ich mich sehr stark auch mit Innovationen innerhalb SuccessFactors, d. h. was passiert da, was kann man da nutzen? Bin da eigentlich immer am Ball, aber auch rund um SuccessFactors, d. h. wie kann man etwas erweitern, wie kann man andere Technologien wie z. B. KI auch nutzen, um SuccessFactors zu komplettieren.
Eine Expertenperspektive auf SAP SuccessFactors: Funktionale Stärken, Schwächen und Innovationen
Michael Scheffler:
Jörg, was denkst du, wie viele SAP SuccessFactors-Projekte hast du im Laufe deiner Karriere begleiten dürfen? Klar, es gibt immer komplexere und weniger komplexe, aber wie viele, über den Daumen gepeilt, waren das?
Jörg Ehrlich:
Also ich würde schon schätzen 40-50 Kundenprojekte werden das sein, wobei das nicht immer komplette SuccessFactors-Einführungsprojekte sind, wo man jetzt die komplette Modullandschaft implementiert, sondern da sind auch Proof of Concepts dabei, sog. POC oder HR-IT-Strategieprojekte, Projekte zur Weiterentwicklung bestehender Module. Vielleicht hat auch ein anderer Implementierungspartner ein Modul implementiert und wir schauen uns das an, überprüfen das, schauen, was man vielleicht noch machen kann.
Dann gibt es natürlich unterschiedliche Größen bei den Kunden. Kunden, die ich schon viele Jahre begleite wie der DM, bei der wir SuccessFactors Recruiting in Deutschland, Österreich und einigen SE-Ländern eingeführt haben. Aber auch kleinere Kunden, die ich entweder sporadisch begleite oder immer mal wieder, wenn es halt um diverse Fragestellungen geht.
Michael Scheffler:
In welchen Modulen bist du zertifiziert?
Jörg Ehrlich:
Recruiting. Also grundsätzlich bei den Zertifizierungen gibt es die Associate Zertifizierung und die Professional Zertifizierung. Für diese Zertifizierung muss man noch Projekterfahrung nachweisen. Die habe ich im Bereich Recruiting, Recruiting Marketing und Management und eine Associate Zertifizierung im Bereich Goals, Performance, Learning, Talenthybridintegration und Career Development.
Michael Scheffler:
Alles klar, Respekt. Ich denke, es ist herausgekommen, dass du wirklich ein sehr erfahrener Experte auf dem Gebiet der SAP SuccessFactors-Lösung bist und auch schon viel erlebt hast, gesehen hast im Laufe der Jahre. Insofern bin ich froh, dass ich dich heute hier zu diesem Thema befragen darf. Du hast vorhin auch angesprochen, 2019 haben wir uns schon mal über deine Lessons Learned zu SAP SuccessFactors-Einführungsprojekten unterhalten. Wer da mal reinhören möchte, das war die Folge 3. Seitdem ist viel passiert. Nicht nur eine Pandemie liegt hinter uns, sondern auch diverse Release-Updates durch die SAP.
SAP SuccessFactors ist in den Jahren natürlich kontinuierlich weiterentwickelt worden. Vielleicht starten wir deshalb nochmal mit einem Big Picture. Wo siehst du derzeit die funktionalen Stärken der cloudbasierten Lösung, Jörg? Wo siehst du die Schwächen? Ich spiele natürlich auf die Payroll und Zeitwirtschaft an, die oftmals nach wie vor bei unseren Kunden und bei den SAP-Anwenderunternehmen im klassischen SAP HCM-On-Premise-System verortet wird. Wo siehst du Stärken und Schwächen der Lösung?
Jörg Ehrlich:
Sehr gerne. Du hast Recht, es ist wirklich eine Menge passiert in den letzten zehn Jahren. Unterschiedlich in den Modulen. Gerade der Innovationsgrad unterscheidet sich stark zwischen den einzelnen Modulen. Ganz generell, die Stärke, auch wenn man es jetzt mit einer On-Premise-Landschaft vergleicht, ist die Innovationsgeschwindigkeit, dass man über die halbjährlichen Releases Innovationen bekommt, die man implementieren kann, die man sich vielleicht auch erstmal anschauen, austesten und einen Pilot starten kann, d. h. man hat, was das angeht, mehr Flexibilität und eine höhere Innovationsgeschwindigkeit. Das mal ganz generell.
Was ist allgemein passiert im Bereich SuccessFactors? Du hast das Thema Zeitwirtschaft angesprochen, da können wir später gerne näher drauf eingehen. Zeitwirtschaft, das ist eine große Neuerung, dass es ein Time Management im EC gibt, auch gar nicht so lang, was vielleicht nicht die absolut komplexesten Anforderungen abdeckt, aber wir haben das auch mit einem größeren Mittelstandskunden von uns durch konzipiert.
Da würde z. B. das native Time Management in EC schon ausreichen. Im Bereich Time Management hat sich einiges getan, sodass man da auf jeden Fall einen Blick auf EC werfen kann. Es hat sich sehr viel getan, wenn es um das Thema Onboarding geht. Es gibt eine Weiterentwicklung des Onboardings. Früher gab es das Onboarding 1.0, jetzt sprechen wir da über Onboarding 2.0, was komplett neu konzipiert und entwickelt wurde. Das ist auch etwas, wo wir einen großen Bedarf aktuell sehen, auch wenn es um Kundeneinführungsprojekte geht und das ist schon eine große Verbesserung. Allgemein, auch das UI, gerade im Learning ist da einiges passiert und wird noch einiges passieren. Ich hatte erwähnt, dass die Innovationsgeschwindigkeit unterschiedlich ist in den Modulen.
Wenn man sich z. B. Recruiting anschaut, da ist z. B. im Vergleich weniger passiert. Da würden sich viele Kunden mehr wünschen. Aber wenn es darum geht neue Technologien, ich hatte es angesprochen, wie Künstliche Intelligenz z. B. zu nutzen, auch dort macht die SAP einen riesen Schritt mit dem sog. Talent Intelligence Hub, wo es um das ganze Thema Skills und Kompetenzen geht. Das ist ja immer ein Thema und wird zukünftig ein größeres Thema werden. Wie kann ich Mitarbeiter im Unternehmen finden? Woher weiß ich überhaupt, welche Fähigkeiten die haben? Wie kann ich die optimal einsetzen und auch entwickeln? Dort im Rahmen dieses Talent Intelligence Hub, was eine sehr neue Entwicklung in SuccessFactors ist, mit Einsatz von KI gibt’s da eben Lösungen. Das ist ein Thema, was die SAP derzeit ganz stark pusht.
Die Zukunft der Payroll in SAP SuccessFactors: Insights zum Core-Hybrid-Modell und Next-Gen-Payroll
Michael Scheffler:
Gut, ich habe verstanden Zeitwirtschaft hat die SAP große Schritte gemacht im SuccessFactors-Umfeld. Dann lass uns doch mal den Finger in die ECP-Wunde legen, in den Payroll-Bereich. Wie sieht es um die oftmals erwähnte Next-Gen-Payroll aus und was ist das eigentlich? Vielleicht kannst du nochmal grundsätzlich erläutern, was hier die Roadmap der SAP insbesondere für Deutschland ist und wo genau die Unterschiede zwischen der EC-Payroll, also ECP und der Next-Gen-Payroll liegen.
Jörg Ehrlich:
Gerne. Wenn es um das Thema Payroll geht, haben wir folgende Möglichkeiten aktuell: Wenn der Kunde aktuell schon eine On-Premise-Payroll nutzt, was viele unserer Kunden tun und gerade in der Dachregion ist das schon eine gesetzte Lösung, dann kann man quasi EC führend implementieren, d. h. die Stammdatenverwaltung, auch mit ESS-/MSS-Szenarien, die sind quasi führend in SuccessFactors Employee Central und dann gibt es eine produktbasierte Integration, um die Daten quasi ins SAP HCM bringen, um dann dort die Payroll selber zu betreiben, d. h. man nutzt sein SAP HCM-System und die Payroll, die man eh schon hat oder führt die quasi ein On-Premise, d. h. man betreibt das Ganze selber.
Michael Scheffler:
Also eine hybride Systemlandschaft?
Jörg Ehrlich:
Hybride Systemlandschaft. Die SAP spricht da von einem Core-Hybrid. Da habe ich aktuell die Möglichkeit, weil du die Roadmap angesprochen hast, bis 2030, wenn ich dann eine Extended Maintenance nehme, auf dem SAP HCM-System oder dann eben auf der Lösung Human Capital Management für S4HANA, kurz H4S4, wenn ich dahin migriere, kann ich es dort weiterbetreiben und da gibt es Wartungszusagen bis aktuell 2040. Das ist die eine Option, gerade für Kunden, die eben eine Payroll On-Premise schon haben.
Die EC-Payroll aktuell ist technisch das Gleiche, ist 1:1 technisch die On-Premise-Payroll, nur dass eben von der SAP gehostet wird, d. h. wenn ich die noch nicht habe, dann muss ich keine Systemlandschaft bei mir aufbauen, das Ganze warten etc. und hosten, sondern die SAP hostet das für mich. Rein von den Funktionen ist es das Gleiche. Es gibt noch ein Payroll-Controllcenter oder ein paar Extras vielleicht, aber grundsätzlich von der technischen Grundlage ist es das gleiche wie die On-Premise-Payroll. Die Next Generation Payroll, die du angesprochen hast, ist quasi eine komplette Neuentwicklung der Payroll, d. h. SuccessFactors als Public Cloudlösung verfügt derzeit nicht über eine Payroll und die wird quasi entwickelt.
Da ist SAP dran, aber das ist natürlich eine komplexe Sache und da ist es so, dass das jetzt mit UK pilotiert wird, aber es gibt aktuell keine Aussage, wann für Deutschland die Next Generation Payroll, also wirklich neuentwickelte Payroll in der Public Cloud SuccessFactors, wann die zur Verfügung stehen wird. Das kann bis 2030 sein, muss aber nicht. Da gibt es tatsächlich keine verbindliche Aussage derzeit, keine klare Roadmap. Aber ich glaube es ist auf jeden Fall nicht in den nächsten zwei Jahren zu erwarten.
Michael Scheffler:
Gut und in Sachen hybride Systemlandschaften, du hast es gerade angedeutet, für viele unserer Kunden ein wichtiges Thema, Core-Hybrid ist da eines der Modelle, was oftmals in der Praxis im Einsatz ist. Welche Erfahrungswerte besitzt du hier und kannst du unseren Hörerinnen und Hörern mitgeben?
Jörg Ehrlich:
Core-Hybrid-Modell hast du angesprochen. Vielleicht nochmal zusammenfassend: Core-Hybrid heißt, ich nutze Employee Central als führendes Stammdatensystem, d. h. ich pflege dort als HR-Sachbearbeiter, als Manager vielleicht im Rahmen eines Manager Self Services, als Mitarbeiter im Rahmen eines ESS-Szenarios und ich repliziere die Daten in SAP HCM. Dazu gibt es ein Integrationsprodukt auf Basis der Business Technology Platform BTP, da gibt es eine Integration Suite und da gibt es quasi einen produktisierten Ansatz. Es gibt ein Add-On im SAP HCM, was man einspielt und dort wird quasi Standard Coding, die Möglichkeiten das Standard Coding zu erweitern, es wird ein Customizing ausgeliefert, d. h. man muss schon was tun, um das zu implementieren, aber es ist schon viel vorgedacht in dieser produktisierten Integration.
Was wir sehen aktuell, ist ein Shift hin zu diesem Core-Hybrid-Modell von dem sog. Talent Hybrid. Talent Hybrid heißt, ich habe nur die Talentmodule, Recruiting, Goals, Performance etc. in SuccessFactors, aber das führende Stammdatensystem für meine Mitarbeiterdaten ist weiterhin noch SAP HCM. Da gibt es auch eine Integration zu, die ist wesentlich einfacher, weil da geht’s nur um einen Mini-Stamm oder um Fragestellungen wie „wie bekomme ich jetzt die Daten aus dem Recruiting übergeleitet ins SAP HCM, um da die Einstellungen vorzunehmen?“. Das ist schon ein Shift, was eben daran liegt, dass viele unserer Kunden sich mit dem EC beschäftigen als führendes Stammdatensystem und es dann auch implementieren und es dann quasi auf dieses Core-Hybrid-Modell hinausläuft.
Michael Scheffler:
Und die von dir eben erwähnte Business Technology Platform und die dort vorhandene Integrationsschicht, wie sehen da deine Erfahrungen in der Praxis aus? Wird die auch tatsächlich so eingesetzt oder integrieren da die Kunden links und rechts etwas daneben hin?
Jörg Ehrlich:
Wenn es jetzt um eine SAP-Integration geht, also wirklich darum, SAP HCM zu integrieren, dann setzen die meisten auf die produktisierte Integration auf Basis der Business Technology Plattform. Das bringt wesentliche Vorteile, weil da schon viel vorgedacht ist. Viele unserer Kunden nutzen die CP auch für andere Szenarien schon, d. h. es ist oftmals schon Knowhow da.
Das ist schon etwas, was sich mehr und mehr etabliert. Wenn es jetzt um Non-SAP-Lösungen geht, z. B. ein Non-SAP-Payroll-Provider für irgendeinen Land, Singapur z. B. im Rahmen eines internationalen Rollouts, dann ist es tatsächlich so, dass viele schauen „was ist der Aufwand, wenn ich das über die BTP mache oder gibt’s da noch leichtgewichtigere Lösungen?“. Es gibt ein Integration Center, eine sehr einfache Lösung in SuccessFactors, vielleicht reicht das ja schon.
Auch wenn der Auswahlstandort nicht so groß ist und es jetzt um ein paar Hundert Mitarbeiter geht, vielleicht reicht da vielleicht ein Flat-File oder kann der Payroll-Provider oder das System, was ich integrieren möchte, kann das die Daten per AP abholen? Muss ich immer die Daten nur pushen, sondern vielleicht kann das andere System die Daten per AP abholen. Auch das ist ein valider Weg und dort muss man nicht zwingend über die BTP gehen. Deswegen tun das auch nicht alle Kunden.
Optimale Anpassungen und Erweiterungen von SAP SuccessFactors: Nutzung von Schnittstellen und Partnerlösungen
Michael Scheffler:
Eine Reihe von SAP-Partnern, u. a. wir, bieten sog. SAP Qualified Partner Packaged Solutions an, dann z. B. für SAP SuccessFactors EC oder Recruting. Dabei handelt es sich um vorkonfigurierte Best Practice Systeme und wir haben ein solches auch im Portfolio, nennt sich dann Launch for Success, aber die gibt es eben von einer ganzen Reihe von Partnern. Was hältst du davon, wenn man als einführendes Unternehmen, als SAP-Anwendungsunternehmen vielleicht sogar auf der grünen Wiese auf so welche vorkonfigurierten ready to use Pakete setzt?
Jörg Ehrlich:
Grundsätzlich ist es immer eine Option. Man sollte sich die Optionen immer anschauen. Ich glaube man muss unterscheiden, wie groß und wie komplex die Organisation ist. Gerade für Mittelständler, für kleinere Unternehmen, die vielleicht auch noch keine großen Prozesse implementiert haben, da kann das wirklich ein guter Startpunkt sein oder hat man Passungsgrad auch schon von 80-90 Prozent. Meiner Meinung nach wird man immer etwas anpassen müssen, d. h. es wird keine Lösung geben, die einfach für alle passt, d. h. im Rahmen des Customizings, der Konfiguration wird es immer gewisse kundeneigene Anforderungen geben.
Gerade für kleinere Unternehmen glaube ich je nach Modul, dass man da mit den ready to use Paketen einen großen Schritt machen kann und schneller implementieren kann. Für größere Organisationen kommt es tatsächlich ein bisschen drauf, was du gerade auch gesagt hast, green field heißt ja ich implementiere auf der grünen Wiese, es ist noch nichts da oder brown field, ich habe vielleicht schon eine komplexere Systemarchitektur, ich habe schon einige Module. Für brown field Implementierungen würde ich es nicht empfehlen.
Da kann man es sich anschauen, aber dadurch, dass die Module ja schon integriert sind miteinander, macht das nicht allzu viel Sinn. Für Neueinführungen auf der grünen Wiese, auch für größere Organisationen, kann so ein ready to use Paket auf jeden Fall ein guter Startpunkt sein um Geschwindigkeit zu gewinnen und das als Baseline zu nehmen, um seine Anforderungen im Rahmen eines fit gaps dagegen abzugleichen. Das kann auf jeden Fall Sinn machen.
Michael Scheffler:
Was kann man denn tun, wenn der Standard nicht ausreicht? Ich kann mich erinnern in unserer Folge 2019 hattest du sehr ausführlich dargelegt, dass eben cloudbasierte Lösungen oder Einführungsprojekte von cloudbasierten Lösungen wie SAP SuccessFactors komplett anders sind als klassische On-Premise-Einführungsprojekte, weil man eben nicht beliebig hinzuprogrammieren oder erweitern kann. Jetzt hat sich da im Cloudumfeld sehr viel getan. Ich denke da an die APIs, also Schnittstellen, die SAP SuccessFactors zur Verfügung stellt, um dann eben doch Erweiterungsmöglichkeiten als Unternehmen nutzen zu können. Das Ganze läuft dann auch sehr stark in Verbindung mit der SAP BTP ab. Was kannst du dazu berichten? Wie sehr werden in der Praxis bei den Einführungsprojekten, die wir begleiten, Zusatzfunktionen über diesen Weg bereitgestellt?
Jörg Ehrlich:
Also grundsätzlich an dieser Aussage, dass man quasi in SuccessFactors nichts programmieren kann, nicht den Code verändern kann und quasi eine Entwicklungsumgebung hat, da hat sich erstmal nichts dran geändert. Das ist nach wie vor so, dass man quasi die Lösung konfiguriert, aber eben ohne Code. Wenn wir über Erweiterungen sprechen, sind es im Wesentlichen Integrationen, d. h. Lösungen, die daneben stehen und den Standard komplettieren und teilweise Extensions, wo man versucht das so einzubetten, dass man denkt, man ist noch in SuccessFactors, aber tatsächlich ist man auf der BTP.
Da ist es tatsächlich so, dass wenn wir über Erweiterungen im weitesten Sinne sprechen, dass gerade bei größeren Einführungsprojekten das immer ein Thema ist. Das ist es aber so, dass Unternehmen zusätzlich auf Partnerlösungen setzen, um die zu integrieren statt etwas selber zu entwickeln. Die Möglichkeit es selber zu entwickeln auf der BTP und dann über eine Extension einzubinden, die gibt es, aber die ist natürlich auch aufwendig. Gerade wenn es darum geht, wir implementieren etwas und diese Anforderung kommt ja meistens im Projekt hoch und ich habe schon einen Go-Live avisiert, dann habe ich ja meist auch nicht so viel Zeit bzw. ich möchte jetzt nicht erstmal ein halbes Jahr ein Projekt machen, um dort eine Erweiterung selber zu bauen.
Von daher schauen sich viele Unternehmen um „was gibt’s denn auf dem Markt und wie gut kann man das integrieren?“. Im Recruiting-Bereich macht es keinen Sinn, gerade für das Thema Mitarbeiterempfehlung, irgendwas selber zu machen, weil da gibt es Anbieter, das ist denen ihr Kerngeschäft und die bieten jetzt zunehmend auch aufgrund der Marktmacht der SAP standardisierte Integrationen an, um die Lösungen dann quasi in SuccessFactors Recruiting zu integrieren. Da sehen wir eine sehr vielfältige Landschaft, d. h. natürlich auch, dass das ganze Thema Systemlandschaft komplexer wird. Es wird hybrider dadurch, aber im Endeffekt ist man dadurch schneller als wenn man das selber entwickelt.
Lessons Learned in SAP SuccessFactors Projects: Key Insights and Best Practices
Michael Scheffler:
Gut Jörg, dann lass uns mal zum eigentlichen Hauptthema der heutigen Folge kommen, nämlich deine ganz persönlichen Lessons Learned und ich möchte an der Stelle nochmal verweisen auf unsere Folge aus 2019. Viele der Punkte von damals sind sicherlich heute auch noch aktuell und gültig. Was kannst du da berichten. Über welche Stolpersteine bist du in den letzten vier Jahren in den SuccessFactors-Projekten bei unseren Kunden gestolpert? Was möchtest du unseren Hörerinnen und Hörern mitgeben?
Jörg Ehrlich:
Ich habe mal vier rausgegriffen. Es sind einige Sachen, die man jetzt betrachten kann und die vor vier Jahren sind natürlich nach wie vor valide. Was für mich ganz persönlich ein Lessons Learned ist, ist das ganze Thema „wo fange ich an?“. Ich nenne es jetzt mal „saubere Datenbasis anschaffen“. Grundsätzlich verfolgt die SAP die Strategie „start anywhere, go anywhere“, d. h. grundsätzlich rein technisch kann man mit jedem der Module aus der Suite starten.
Man muss nicht zwingend mit EC starten, um die Funktion des jeweiligen Moduls nutzen zu können. Aber es gibt natürlich Prozesse, die so miteinander integriert sind, dass eine gewisse Reihenfolge auf jeden Fall Sinn macht. Wenn man vor hat in den nächsten drei Jahren seine Kernprozesse, also Personaladministration, Planstellen-Management und die damit verknüpften Self Services auch in die Cloud zu bringen, also dafür Employee Central zu nutzen, dann würde ich damit auch starten. Wir haben es immer wieder gesehen, dass man mit Goals und Performance oder Recruting startet, das wird immer dazu führen, dass man extra Aufwände hat und in diesem Zeitraum, wo ich EC noch nicht habe, auch Funktionseinschränkungen teilweise habe.
Beispiel Recruiting: Ich kann keine Stellenanforderung erzeugen aus dem Planstellen-Management heraus und ich kann die Daten des Bewerbers dann auch nicht für die Einstellung benutzen. Wenn ich dann quasi erst Recruiting und dann EC mache, ist die Datenbasis auch eine andere, d. h. ich muss auf jeden Fall nochmal an meine Daten, an meine Prozesse ran und ich habe einfach extra Aufwände. Wenn EC ein Thema ist, dann würde ich immer mit EC starten, um dort eine saubere Datenbasis zu schaffen.
Michael Scheffler:
Also quasi als Fundament der Lösung?
Jörg Ehrlich:
Als Fundament der Lösung, genau. Es gibt Ausnahmen. Gerade wenn es um das Thema Geschwindigkeiten geht, aber ich glaube gerade bei diesen Ausnahmen muss man vorher eben genau betrachten „was heißt das?“. Was heißt das, wenn wir dann EC einführen?“ und man muss sich dann vergewissern „wo muss man nochmal ran? Wo muss man nochmal nacharbeiten? Wo gibt es für den Endanwender noch eine Änderung prozessual?“.
Das muss man einfach mitbetrachten. Ich würde es nicht ausschließen, aber ich glaube es ist wichtig, das im Projekt frühzeitig zu konzipieren. Das ist ein großer Lesseons Learned aus Projekten. Ein zweiter ist, hängt auch mit dem „start anywhere, go anywhere“ zusammen, es gibt Kombinationen bei der Einführung oder bei der Reihenfolge der Einführung der Module, die weniger sinnvoll sind. Bspw. Onboarding 2.0 als Lösung, wo es ja darum geht, ich habe einen Kandidaten gefunden und der soll zum einen seine Daten, die ich vielleicht sonst papierbasiert abgefragt habe, Bankverbindung, Sozialversicherung, Notfallkontakt etc., das soll er jetzt quasi auf digitalem Wege übermitteln. Das zum einen.
Aber auch die ganzen anderen Themen, die weicheren Themen wie „wie sieht mein erster Tag aus? Wo muss ich überhaupt hinkommen? Wer sind meine zukünftigen Kollegen? Wie kann ich mich mit denen austauschen vorab?“. Das ist ja die Onboarding-Lösung. Die macht aus meiner Sicht wenig Sinn, wenn ich jetzt kein Employee Central habe. Rein technisch ist das möglich. Ich kann sagen „ich mache Recruiting und Onboarding und später dann EC“, aber da wird man schnell sehen „ich kann einen großen Funktionsumfang von diesem Onboarding eben nicht nutzen“, weil der Onboardee seine Daten direkt in EC-Masken eingibt, das liegt dann in SuccessFactors, aber wenn mein führendes Stammdatensystem für die Einstellung noch On-Premise ist, dann brauche ich dort irgendeine Integration, irgendeinen Prozess, wie ich die Daten dann überleite.
Da gibt es nichts out of the box für Onboarding 2.0, von daher ist da die Reihenfolge aus meiner Sicht sehr wichtig zu betrachten und die Abhängigkeiten auch. Ein weiteres Beispiel ist das Thema Nachfolgeplanung, Succession Management. Das wäre jetzt nichts, womit man sofort startet, weil ohne Performance-Daten und ohne Daten im weitesten Sinne aus dem Talent-Bereich, macht das keinen Sinn.
Dann limitiere ich mich einfach und habe weniger Funktionen. Deswegen macht es Sinn, sich gerade bei der Reihenfolge und der Kombination und der Wechselwirkungen zwischen den Modulen vorab im Rahmen einer Roadmap Gedanken zu machen und das als vorgelagertes HR-IT-Strategieprojekt mit den Key Stakeholdern im Unternehmen zu diskutieren, zu konzipieren und dann aber auch Verbindlichkeit zu schaffen, indem man die Roadmap gemeinsam entwickelt und dann eben diese Aspekte der Sinnhaftigkeit der Reihenfolge und der Kombination darin betrachtet.
Michael Scheffler:
Das möchte ich nochmal unterstreichen, der sog. Bebauungsplan ist essenziell. Den empfehlen wir all unseren Kunden, sofern ein solcher nicht vorhanden sein sollte. Oftmals ist er in der Praxis nicht da und deswegen, du hast es gerade super ausführlich dargelegt, ist das ein ganz wichtiger Schritt bevor man an solche Cloudvorhaben herangeht.
Jörg Ehrlich:
Absolut. Ein weiteres Lessons Learned ist, ich habe ganz am Anfang gesagt, ich wäre oftmals in die Projekte geholt, wenn es darum geht, Lösungen für Kundenherausforderungen zu finden und da ist man natürlich schnell auch bei einem Workaround, d. h. „kann ich eine Funktion, eine Standardfunktion vielleicht abweichend verwenden?“. Gibt’s eine Integration innerhalb der Suite, die ich über das angesprochene Integration Center machen kann? Da ist schon ein Lessons Learned, Workarounds sind gut, aber nicht jeder Workaround ist sinnvoll. Hier sollte man wirklich genau schauen „wo schaue ich vom Standard ab?“ und dort auch die Vor- und Nachteile diskutieren.
Ich möchte es nicht ausschließen oder verteufeln, ich bin nicht generell gegen Workarounds, ganz im Gegenteil, das ist Teil meines Jobs auch, aber es ist wichtig die zu diskutieren und nicht einfach zu implementieren „kurzfristig funktioniert das doch“, sondern sich die Zeit zu nehmen, zu betrachten „was muss ich bei einem Release-Wechsel beachten oder zusätzlich testen?“. Sich bewusst zu werden und das zu dokumentieren. Umgesetzt ist es schnell, aber wenn dann Personen im Unternehmen wechseln, fällt das hinten herunter. Da wirklich sensibel damit umzugehen einfach. Ein weiteres Lessons Learned ist, was wir oftmals sehen, nachdem Go-Live ist das Projekt nicht zu Ende.
Man ist live und man hat viele Anforderungen im Rahmen von Workshops diskutiert, nicht alle kann man umsetzen, auch rein aus dem zeitlichen Aspekt heraus und dann hat man, je nachdem wie man die Workshops gemacht hat, auf einem digitalen Whiteboard oder irgendwo hat man das mal diskutiert, aber oftmals halten die Kunden das nicht konsequent nach. Dann sagt man „das machen wir vielleicht später, ist vielleicht was für die Phase 2, ist vielleicht nicht absolute Go-Live-kritisch, dass wir diese Funktion haben“, aber oftmals gehen diese Informationen verloren, auch weil Personen z. B. wechseln und da empfiehlt sich wirklich die kontinuierliche Pflege eines Backlogs und dann eben auch ein Prozess, wie man dieses Backlog füllt und auch aktuell hält.
Das heißt, dass man da wirklich regelmäßig draufschaut und schaut „ist das noch eine Anforderung? Brauchen wir das noch? Hat sich da die Priorität geändert?“ und dann auch im Rahmen der Releases absteckt „ist das etwas, was wir implementieren können?“ und da empfiehlt es sich auch einen Prozess zu etablieren mit eigenen Releases auch rauszugehen, dass man nicht über das Jahr verteilt viele kleine Anpassungen macht, sondern mehrere kleine Anpassungen bündelt, Erweiterungen oder Optimierungen bündelt und dann kleine Mini-Projekte oder Releases macht, um auch den Impact auf die Organisation geringer zu halten.
Es wird ja einen Change geben, jemand ist von diesem Change betroffen und wenn ich das sehr kontinuierlich über das Jahr mache, fordert es mehr Ressourcen für das Thema Test als wenn ich mehrere Erweiterungen bündele, vielleicht auch in Abhängigkeit „wann kommen die Releases der SAP?“. Da einfach am Ball zu bleiben und auch Personen und eine gewisse Governance aufzubauen, die genau das treiben und die da auch Lust dran haben, das weiterzuentwickeln.
Ich habe von der Innovationsgeschwindigkeit gesprochen, was ja ein Hauptvorteil der Cloud ist, die dann auch wirklich zu nutzen und die Bereitschaft zu haben, vielleicht mal in ein Early Adapter Programm der SAP reinzugehen oder wenn es darum geht „wie soll die LMS-Homepage ausschauen?“, dass man sich dort einfach einbringt auch als Kunde mit der SAP, um da aktiv dran zu arbeiten und dann auch einfach am Ball bleibt, was eben Neuerungen angeht und das vielleicht auch mal mit einem Pilot im Haus zu verproben. Da einfach nicht mit Go-Live das ganze Thema abzuhaken, sondern da kontinuierlich am Ball zu bleiben. Das ist eines meiner neuesten Erkenntnisse, wenn ich rekapituliere, dass das wirklich extrem wichtig ist.
Michael Scheffler:
Ja ich denke wir können jetzt auch vermutlich noch eine Stunde weiter über deine Erfahrung diskutieren, aber leider sind wir am Ende der Zeit. Insofern möchte ich dir ganz herzlich für deinen wertvollen Input danken. Ich glaube das war super ausführlich. Wenn wir unseren bisherigen Turnus beibehalten, dann können wir uns 2027 wieder über deine dann neu vorhandene Erfahrung unterhalten. Das passt perfekt. Das ist dann auch das Ende der Standardwartungszusage für SAP ERP HCM und da hat sich dort dann sicherlich viel getan. Nochmals vielen Dank, Jörg. Wir sehen und hören uns.
