Bye-bye, SAP HCM?

In der neuen kunterbunten Welt stirbt der klassische SAP-HCM-Berater; die unterschiedlichsten HCM-Architekturen werden uns die nächsten Jahre begleiten und verlangen unterschiedlichste Expertise.

Wer hier nicht mithalten kann, ist schnell weg vom Fenster. Trotz offener Fragen überzeugt die Full-Cloud-HCM-Architektur mit viel Charme, und insbesondere Kunden mit in die Jahre gekommenen HCM-Installationen wappnen sich für den Umstieg.

Einzig die leidige Lizenzfrage bremst den Pioniergeist Schweizerischer Unternehmen. Und teilweise wird aus Kostengründen doch für ein hybrides Szenario entschieden, bei dem SAP SuccessFactors als reine Talent Management Suite betrieben wird, die mit einem HCM Backbone kommuniziert.

Aber die Zukunft liegt eindeutig in der Cloud und die Full-Cloud-Szenarien werden den Markt durchdringen.

Full Cloud HCM, Success-Factors und Cloud Payroll

Entscheidendes Merkmal der Full-­Cloud-Architektur liegt in der Stammdatenverwaltung in SuccessFactors, im Modul Employee Central (EC).

EC löst komplett die Personaladministration und das Organisationsmanagement ab. Der Todesstoß für PA20 und PA30, unsere treuen Begleiter der letzten 20 Jahre.

Spannend ist, dass SAP es in Rekordzeit geschafft hat, EC auf dasselbe Niveau zu bringen wie die Stammdatenverwaltung in SAP HCM. Lokale Felder für mehr als 17 Länder, eine Lösung, die es erlaubt, ein angehängtes Payroll-System mit allen lohnrelevanten Daten zu füttern.

Die erste Hürde im Full-Cloud-Projekt liegt bereits auf der Hand: Wo macht man den Schnitt zwischen EC und Payroll-Systemen?

Einige Kunden nutzen EC nur für globale Stammdaten und alle lokalen Daten werden in den Payroll-Systemen gepflegt, die ihrerseits on premise oder in der Cloud betrieben werden können.

Andere Kunden entscheiden sich für die „wahre“ Full-Cloud-Strategie und pflegen komplett alle Daten in EC, sodass die Payroll-Systeme nur noch zur monatlichen Lohnproduktion dienen.

Solange EC keine eigene Payroll-En­gine beinhaltet, wird dieses Thema in jedem Full-Cloud-Projekt zu Diskussionen führen und auch kritische Stimmen hervorrufen, die sich fragen, wozu Full Cloud gut sein soll, wenn man hinten dran noch eine „klassische“ SAP-Payroll andocken muss.

Wir betrachten das als Übergangsphase, Teil des Transformationsprozesses, und wenn die Payroll auch aus der Cloud bezogen wird, lassen sich die kritischen Argumente auch entkräften.

In der reinen Full-Cloud-Welt werden also alle abrechnungsrelevanten Daten in EC geführt und von da in ein externes Payroll-System übertragen. Und auch hierfür gibt es wiederum verschiedene Architektur­optionen.

Neben der von SAP gehosteten Cloud-Payroll-Lösung (auf Basis von ERP 6.0) können die bereits vorhandenen SAP-on-Premise-Systeme des Kunden angebunden werden.

Ebenfalls gibt es BPO-Anbieter auf dem Markt, welche die Integration der Abrechnungsdaten auf ihre Systeme einrichten können. Dies können SAP-, aber auch Non-SAP-basierte Payroll-Systeme sein. Wer die Wahl hat, hat die Qual, und die Entscheidungsprozesse sind oft langatmig.

Beam me up, Boomi

Bleibt nun die Frage, wie die Daten aus EC in die jeweiligen Payroll-Systeme gelangen. SuccessFactors bietet eine Vielzahl von APIs, an welche für Integrationsszenarien verwendet werden können.

Neben neueren oData-Schnittstellen basierte die Standard Payroll Integration auf dem ­SOAP-basierten SFAPI. Nicht alle Daten sind über beide Schnittstellentypen ansprechbar, wobei SAP die oData-Schnittstellen ständig erweitert hat, sodass in Zukunft von einer vollständigen Abdeckung durch oData-APIs auszugehen ist.

Für die Übertragung der Abrechnungsdaten von EC zu einem SAP-Payroll-System steht aktuell die Middleware Boomi zur Verfügung. SAP liefert hierfür vordefinierten iFlow-Content aus, der die notwendigen Datenumsetzungen vornimmt.

Boomi fungiert in dieser Konstellation als Replikationsmaster. Das bedeutet, dass die Replikation der Daten von Boomi angestoßen wird. Dabei erfolgt als Erstes ein Aufruf des SuccessFactors-APIs, welches die geänderten Mitarbeiterdaten liefert.

Hierbei erfolgt jeweils eine Selektion auf geänderte Daten seit der letzten Replikation, sodass nie ein Fullload übertragen wird. Nach der Datenumsetzung innerhalb von Boomi wird ein Webservice in SAP aufgerufen und diesem die aufbereiteten Daten in Form eines XML-Files übergeben.

Das kundenspezifische Mapping von Feldwerten kann hierbei vollständig in SAP konfiguriert werden; ein großer Teil ist über Customizing-Tabellen möglich.

Sollte dies nicht ausreichen, so stehen dem Kunden weitere Möglichkeiten durch eigene BAdI-Implementierungen bereit. Die Verarbeitung erfolgt sequenziell und ist im Applikationslog jederzeit sichtbar.

Allfällige Fehlermeldungen während der Verarbeitung werden über einen separaten Boomi-Prozess von SAP zurück an EC gemeldet und sind dort im Data Replication Monitor ersichtlich.

Darin hat der Personalsachbearbeiter die Möglichkeit, die fehlerhaften Daten zu korrigieren und die Person erneut für eine Replikation zu markieren. Erfolgreich verarbeitete Datenänderungen werden ebenfalls an EC zurückgemeldet.

Die notwendigen Programme und Services in SAP werden als Add-on ausgeliefert. Die Patches für dieses Add-on folgen der Patch-Strategie der Cloud-Lösung.

Seit einiger Zeit kann der Kunde wählen, ob er die Integration mit dem Add-on sicherstellen möchte oder die in den neuesten HCM-Releasen integrierte Integration anwenden möchte.

Mogelpackung Mash-up?

Leider können – Stand heute – nicht alle abrechnungsrelevanten Daten in EC gepflegt werden. Hiervon sind kundenindividuelle oder bestimmte länderspezifische Infotypen betroffen.

Damit der Enduser von diesem Manko nichts merkt und um zu verhindern, dass doch noch direkte Datenpflege im Payroll-System notwendig wird, hat SAP die Mash-up-Technik ins Leben gerufen.

Die Datenpflege erfolgt dabei über eine Webdynpro-Abap-Anwendung des SAP-Systems, die als iFrame direkt in EC integriert wird. Hierbei wird die erstmalig mit HR Renewal ausgelieferte, webbasierte Personalstammdatenpflege-Applikation verwendet.

Die Anmeldung am SAP-System erfolgt über SAML2-basierten SSO. Dafür muss jeder HR-Benutzer, welcher die Mash-ups pflegen darf, über einen Benutzer im SAP-System verfügen. Vom eigentlichen Login-Prozess bekommt der Anwender aber nichts mit.

Endlich sind also alle Fragen geklärt und es kann losgehen mit der Abrechnung. Der Abrechnungslauf erfolgt direkt im SAP-Payroll-System, der gute alte RPCalc lässt grüßen. Aber auch hier ist Innovation angesagt.

War bis dahin hierfür oft noch ein SAP-GUI-Zugriff über VPN erforderlich, so kann heute mit dem neuen Payroll Control Center die ganze Payroll-Abwicklung komplett webbasiert durchgeführt werden.

Aus Sicht der bereits vorhandenen Infrastruktur bedeuten die Integration der Mash-ups in EC und die Anbindung von Boomi an ein On-Premise-SAP-System gewisse Umstellungen.

War es bis heute in vielen Fällen ausreichend, das SAP-HCM-System nur intern oder per VPN erreichbar zu machen, reicht dies in der Cloud-Welt nicht mehr aus. Der Zugriff aus EC erfolgt in Realtime entweder durch den Anwender oder Boomi.

Fileschnittstellen fallen deshalb weg und werden von SAP im Standard gar nicht angeboten. Der Zugriff erfolgt online über HTTPS direkt in das SAP-System. Entsprechend müssen die Systeme aus dem Internet erreichbar gemacht werden.

Ein SAP-Webdispatcher oder ein anderer, bereits vorhandener Reverse Proxy in der DMZ gewährleisten die notwendige Sicherheit. Zertifikatsbasierter Login für die Webservices oder ein IP-Whitelisting können die Sicherheit zusätzlich erhöhen.

Fallstricke, Dos und Don’ts

Abweichend von der bisherigen SAP-Patch-Strategie (jährliche En­hancement Packages und monatliche HR Patches) ändert sich die Strategie in der Cloud. Neu kommen Fehlerkorrekturen und neue Funktionen im Quartalsrhythmus auf den Markt und werden sogleich allen Kunden „aufgezwungen“.

Der Cloud-Kunde hat keine Wahl, ob er den neuen Release haben möchte oder nicht. Was einerseits Vorteile hat, birgt aber auch gewisse Risiken. Denn nicht nur der SAP SuccessFactors Release wird gepatcht, sondern ebenfalls der Boomi Content und das SAP Add-on.

Möchte man von den neuen Funktionen profitieren oder kämpft man mit einem Replikationsfehler, ist das Patchen von Boomi und SAP (durch den Kunden) unabdingbar. Solange die Integration in SAP über ein separates Add-on läuft, stellt dies auch keine größere Problematik dar.

Verwendet der Kunde aber die via HR Packages ausgelieferte Integration, ist quartalsweise ein Patchen der HR-Komponenten notwendig, verbunden mit Implementierungs- und Testaufwand.

Ein weiterer Aspekt der Integration sind die in SAP benötigten Benutzer. Wie oben erwähnt müssen alle Mash-up-Benutzer über einen SAP-User verfügen. Meistens ist die Anzahl dieser Benutzer überschaubar und daher stressfrei zu handhaben.

Soll hingegen der in SAP erzeugte Payslip den Mitarbeitenden über EC zur Verfügung gestellt werden, benötigen plötzlich alle Mitarbeitenden einen SAP-Benutzer (Self-Service-Szenario), und spätestens hier wird die doppelte Benutzerpflege mehr als nur lästig.

SAP bietet in der Zwischenzeit einen Generierungsreport an, welcher basierend auf den replizierten Personalnummern die SAP-Benutzer anlegt. Die Benutzer werden dabei gemäß der EC-User-ID (entspricht in etwa der Personalnummer) benannt was vorhandene Namenskonventionen verletzen kann.

Ebenfalls ist die Integration in eine zentrale Userverwaltung nur bedingt möglich. Von SAP wird diesbezüglich empfohlen, die Benutzerverwaltung sowohl für SuccessFactors wie auch für SAP über ihre Identity-Management-Lösung abzuwickeln.

In der Praxis ist dies aber nicht zwingend notwendig, sofern man mit den Limitierungen des Benutzerreports leben oder auf eine automatische Benutzergenerierung verzichten kann.

Bei der Implementierung von EC sollte in jedem Falle das zugrunde liegende SAP-Datenmodell berücksichtigt werden. Schlüssel, z. B. Mitarbeiterkreise oder Ähnliches, sollten wo immer möglich in EC und SAP einheitlich gestaltet werden, sodass ein nachträgliches Mapping der Feldinhalte nur noch minimal notwendig ist.

Somit wird auch sichergestellt, dass die maximalen Feldlängen innerhalb von SAP nicht überschritten werden. Anpassungen an abrechnungsrelevanten Feldern innerhalb von EC haben häufig auch eine Anpassung im SAP-Payroll-System zur Folge.

Dies muss im Projekt wie auch im laufenden Betrieb berücksichtigt werden, sodass beide Bereiche immer synchron gehalten werden.

Werden EC und eine SAP-Payroll zeitgleich neu aufgesetzt, so ist die Welt vergleichsweise einfach. Soll nun aber ein neues EC-System via Boomi an ein bestehendes SAP-Payroll-System oder ein bestehendes EC-System an eine neue SAP-Payroll angedockt werden, so bedarf das gründlicher Analyse sämtlicher Einstellungen.

Nicht kompatible Konfigurationen müssen angepasst werden und häufig kommt man um sogenannte Datensplits nicht herum. Ein Datensplit bedeutet, dass ein Datensatz sowohl in SAP als auch in EC per Stichtag in zwei Sätze aufgeteilt werden muss, damit nur noch Daten ab einem bestimmten Datum repliziert werden. Für diese Splits gibt es heute weder in SAP noch in EC entsprechende Hilfsmittel.

Man muss sich auch bewusst sein, dass man in dieser Architekturvariante faktisch zwei Systeme „redundant“ konfigurieren muss: SAP-Payroll und EC. Diese doppelt geführten Einstellungen erhöhen entsprechend auch den Aufwand im Vergleich zu einer reinen SAP-HCM-on-Premise-Installation.

The Future? Ein Blick in die Glaskugel

Für das Jahr 2015 ist eine Ablösung von Boomi durch die Hana Cloud Integra­tion (HCI) geplant. Was im hybriden Szenario bereits realisiert wurde, soll nun auch den Full-Cloud-Kunden verfügbar gemacht werden.

Da die HCI im aktuellen Offering aber nicht Bestandteil der EC-Lizenz ist (im Gegensatz zu Boomi), werden bestehende Kunden wohl eher nicht umstellen. Für Neukunden könnte die HCI interessant sein, weil für die Replikation das SAP-System nicht mehr vom Internet erreichbar sein muss, sondern der Datentransfer von einem Agent (Programm auf einem Server beim Kunden) initiiert wird und damit der Traffic nur outbound stattfindet.

Für die Verwendung der Mash-ups wird aber nach wie vor die Öffnung von gewissen URLs nach außen benötigt.

Die Entwicklung der Integration Add-on versus HR-Standard gilt es weiterhin zu beobachten. Wie oben erwähnt kann die direkte Integration in den HR-Standard durch die geänderten Patchzyklen zu erhöhtem Aufwand für den Kunden führen.

Gespannt sein darf man auf die im Herbst ausgerollten, neuen Oberflächen basierend auf Fiori. Damit gleicht sich auch SuccessFactors dem UX-Paradigma von SAP an und wird in Zukunft noch mehr als eine Lösung aus einem Guss auftreten, selbst wenn dahinter noch eine Menge unterschiedlicher Technologien und Systeme am Werken sind.

Und die Gretchenfrage, auf deren Antwort von SAP wir gespannt warten, ist natürlich die Zukunft der SAP-Payroll. Wird diese irgendwann einmal ganz in EC integriert sein oder sogar Teil von S/4? Es bleibt spannend und alle Augen und Ohren sind nach Walldorf gerichtet…