Bye-bye, SAP HCM?

In the new motley world, the classic SAP HCM consultant is dying; the most diverse HCM architectures will accompany us over the next few years and require the most diverse expertise.

Anyone who can't keep up here is quickly out of the window. Despite open questions, the full-cloud HCM architecture has a lot of charm, and customers with aging HCM installations in particular are bracing themselves for the switch.

The only thing holding back the pioneering spirit of Swiss companies is the vexed licensing issue. And in some cases, for cost reasons, a hybrid scenario is chosen in which SAP SuccessFactors is operated purely as a talent management suite that communicates with an HCM backbone.

But the future is clearly in the cloud and full cloud scenarios will permeate the market.

Full Cloud HCM, Success Factors and Cloud Payroll

The decisive feature of the full cloud architecture lies in the master data management in SuccessFactors, in the Employee Central (EC) module.

EC completely replaces Personnel Administration and Organizational Management. The death blow for PA20 and PA30, our faithful companions for the last 20 years.

What is exciting is that SAP has managed to bring EC to the same level as master data management in SAP HCM in record time. Local fields for more than 17 countries, a solution that allows to feed an attached payroll system with all wage relevant data.

The first hurdle in the full cloud project is already obvious: Where do you make the cut between EC and payroll systems?

Some customers use EC only for global master data and all local data is maintained in payroll systems, which in turn can be run on premise or in the cloud.

Other customers opt for the "true" full cloud strategy and maintain all data completely in EC, so that the payroll systems are only used for monthly payroll production.

As long as EC does not include its own payroll engine, this topic will lead to discussions in every full cloud project and also provoke critical voices that ask what good is full cloud if you still have to dock a "classic" SAP payroll on the back.

We see this as a transitional phase, part of the transformation process, and if payroll is also sourced from the cloud, the critical arguments can also be refuted.

In the pure full-cloud world, all payroll-relevant data is managed in EC and transferred from there to an external payroll system. And here, too, there are various architecture options.

In addition to the SAP-hosted cloud payroll solution (based on ERP 6.0), the customer's existing SAP on-premise systems can be connected.

There are also BPO providers on the market who can set up the integration of the payroll data on their systems. These can be SAP-based, but also non-SAP-based payroll systems. Those who have a choice are spoiled for choice, and the decision-making processes are often lengthy.

Beam me up, Boomi

The question now remains how the data from EC gets into the respective payroll systems. SuccessFactors offers a variety of APIs that can be used for integration scenarios.

In addition to newer oData interfaces, the standard Payroll Integration was based on the SOAP-based SFAPI. Not all data is addressable via both interface types, although SAP has constantly expanded the oData interfaces, so that full coverage by oData APIs can be assumed in the future.

The Boomi middleware is currently available for transferring billing data from EC to an SAP payroll system. SAP delivers predefined iFlow content for this purpose, which performs the necessary data conversions.

In this constellation, Boomi acts as a replication master. This means that the replication of the data is triggered by Boomi. First, the SuccessFactors API is called, which delivers the changed employee data.

A selection is made for changed data since the last replication, so that a full load is never transferred. After the data conversion within Boomi, a web service is called in SAP and the prepared data is transferred to it in the form of an XML file.

The customer-specific mapping of field values can be completely configured in SAP here; a large part is possible via customizing tables.

If this is not sufficient, further options are available to the customer through their own BAdI implementations. Processing takes place sequentially and is visible in the application log at all times.

Any error messages during processing are reported by SAP back to EC via a separate Boomi process and are visible there in the Data Replication Monitor.

In it, the HR administrator has the option of correcting the incorrect data and marking the person again for replication. Successfully processed data changes are also reported back to EC.

The necessary programs and services in SAP are delivered as an add-on. The patches for this add-on follow the patch strategy of the cloud solution.

For some time now, the customer has been able to choose whether to ensure integration with the add-on or to use the integration built into the latest HCM releases.

Cheat pack mash-up?

Unfortunately - as of today - not all payroll-relevant data can be maintained in EC. This affects customer-specific or certain country-specific infotypes.

To ensure that the end user does not notice this shortcoming and to prevent the need for direct data maintenance in the payroll system, SAP has created the mash-up technology.

Data maintenance is carried out via a Webdynpro Abap application of the SAP system, which is integrated directly into EC as an iFrame. The web-based HR master data maintenance application delivered for the first time with HR Renewal is used here.

The logon to the SAP system is done via SAML2-based SSO. For this, every HR user who is allowed to maintain the mash-ups must have a user in the SAP system. However, the user is not aware of the actual login process.

So finally all the questions have been clarified and we can get started with the billing. The billing run takes place directly in the SAP Payroll system, good old RPCalc sends its regards. But here, too, innovation is the order of the day.

While SAP GUI access via VPN was often required for this until then, the entire payroll processing can now be carried out completely web-based with the new Payroll Control Center.

From the point of view of the already existing infrastructure, the integration of the mash-ups in EC and the connection of Boomi to an on-premise SAP system mean certain changes.

While it was sufficient in many cases up to now to make the SAP HCM system accessible only internally or via VPN, this is no longer sufficient in the cloud world. Access from EC takes place in real time either by the user or Boomi.

File interfaces are therefore omitted and are not even offered by SAP in the standard. Access takes place online via HTTPS directly into the SAP system. Accordingly, the systems must be made accessible from the Internet.

An SAP web dispatcher or another existing reverse proxy in the DMZ ensures the necessary security. Certificate-based login for the web services or IP whitelisting can additionally increase security.

Pitfalls, Dos and Don'ts

In contrast to the previous SAP patch strategy (annual enhancement packages and monthly HR patches), the strategy in the cloud is changing. Error corrections and new functions are now launched on a quarterly basis and are immediately "forced" on all customers.

The cloud customer has no choice whether to have the new release or not. While this has advantages, it also entails certain risks. Not only the SAP SuccessFactors release is patched, but also the Boomi content and the SAP add-on.

If you want to benefit from the new functions or if you are struggling with a replication error, the patching of Boomi and SAP (by the customer) is indispensable. As long as the integration in SAP runs via a separate add-on, this is not a major problem.

However, if the customer uses the integration delivered via HR packages, the HR components have to be patched on a quarterly basis, which involves implementation and testing efforts.

Another aspect of the integration is the users required in SAP. As mentioned above, all mash-up users must have an SAP user. In most cases, the number of these users is manageable and therefore stress-free to handle.

If, on the other hand, the payslip generated in SAP is to be made available to employees via EC, all employees suddenly need an SAP user (self-service scenario), and at this point at the latest, duplicate user maintenance becomes more than just a nuisance.

In the meantime, SAP offers a generation report that creates SAP users based on the replicated personnel numbers. The users are named according to the EC user ID (roughly equivalent to the personnel number), which may violate existing naming conventions.

Likewise, integration into a central user administration is only possible to a limited extent. In this respect, SAP recommends that user administration for both SuccessFactors and SAP be handled via their identity management solution.

In practice, however, this is not absolutely necessary, as long as you can live with the limitations of the user report or do without automatic user generation.

When implementing EC, the underlying SAP data model should always be taken into account. Keys, e.g. employee subgroups or similar, should be designed uniformly in EC and SAP wherever possible, so that subsequent mapping of field contents is only minimally necessary.

This also ensures that the maximum field lengths within SAP are not exceeded. Adjustments to payroll-relevant fields within EC often also result in an adjustment in the SAP Payroll system.

This must be taken into account in the project as well as in ongoing operations, so that both areas are always kept in sync.

If EC and an SAP Payroll are set up at the same time, the world is comparatively simple. However, if a new EC system is to be docked to an existing SAP Payroll system via Boomi or an existing EC system is to be docked to a new SAP Payroll, this requires a thorough analysis of all settings.

Incompatible configurations have to be adapted and often there is no way around so-called data splits. A data split means that a data record in both SAP and EC must be split into two records on a key date, so that only data from a certain date is replicated. Today, there are no tools for these splits in either SAP or EC.

One must also be aware that in this architecture variant one must in fact configure two systems "redundantly": SAP Payroll and EC. These duplicated settings also increase the effort compared to a pure SAP HCM on-premise installation.

The Future? A look into the crystal ball

A replacement of Boomi by Hana Cloud Integration (HCI) is planned for 2015. What has already been realized in the hybrid scenario is now to be made available to full cloud customers.

However, since HCI is not part of the EC license in the current offering (unlike Boomi), existing customers are unlikely to switch. HCI could be interesting for new customers because the SAP system no longer has to be accessible from the Internet for replication, but the data transfer is initiated by an agent (program on a server at the customer's site) and thus the traffic only takes place outbound.

However, the opening of certain URLs to the outside world is still required for the use of the mash-ups.

The development of the integration add-on versus HR standard must continue to be monitored. As mentioned above, direct integration in the HR standard can lead to increased effort for the customer due to the changed patch cycles.

The new interfaces based on Fiori, which will be rolled out in the fall, will be interesting to see. This means that SuccessFactors is also aligning itself with SAP's UX paradigm and will appear even more as a single solution in the future, even if there are still a lot of different technologies and systems at work behind it.

And the key question that we are eagerly awaiting SAP's answer to is, of course, the future of SAP Payroll. Will it be fully integrated into EC at some point or even part of S/4? It remains exciting and all eyes and ears are directed to Walldorf...