Moving employee data from on-premise SAP ERP to SuccessFactors Employee Central is no small task for an organization migrating to the cloud. In order to support these customers, SAP has built a full framework in their PA_SE_IN 100 SAP Integration add-on which can be used in combination with SAP Cloud Platform, Integration Services (aka HCI) as Middleware. Using these two tools to send employee data directly to the SucessFactors APIs, customers have a repeatable, reliable, and testable process for replicating employee data that doesn’t involve manually exporting and importing employee data into flat files.
In case you aren’t familiar with these tools, let me give a brief summary.
- PA_SE_IN 100 / Business Integration Builder (BIB) Integration Add On – This is a component installed on the on-premise ERP system which provides the reports and configuration activities necessary to replicate employee data to Employee Central.
- SAP Cloud Platform, Integration Services (formerly HCI) – A cloud-based middleware integration platform which features prebuilt integration flows that can be used to replicate employee data to the cloud.
- SuccessFactors Employee Central OData APIs – These APIs can be used to load employee and other data directly to your SuccessFactors instance. This will have the same result as the Import Employee Data or Import / Export Data tools in Employee Central, but can be automated.
I could write for pages regarding the setup steps for replicating employee data from SAP ERP To Employee Central, but there are many materials which cover the process very well. Here are a few:
- Replicating Employee Data from ERP To Employee Central – Implementation Guide (SAP)
- EC ERP Integration in a Nutshell – SAP Blog (Naresh Purohit)
- Move Your SAP ERP HCM Data to SuccessFactors Employee Central – SAP Press E-Bite (Luke Marson)
Having recently gone through an implementation using both PA_SE_IN 100 (Business Integration Builder) and SAP Cloud Platform, I wanted to give some high level tips that would have been useful to me at the beginning. Some of them may seem like common sense – but in a complex project it’s important to keep these “common sense” tips at the core!
1. Get the Requirements First
Converting employee data for tens of thousands of employees between two unique systems can be complicated, especially if you have hundreds of fields in scope for replication. Every field from SAP to Employee Central needs to be mapped, and some with value mappings, so that they can be converted to their correct EC counterpart. For example, in SAP it is Ohio. But in SuccessFactors’ OData API, it is Option ID 0000008101 (or whatever unique Option ID it is in your instance).
But before you even get into mapping these values, you need to figure out the basics. What employee data does you need to store in SuccessFactors? What custom fields do you need created in Employee Central to store your company’s data? Which of the standard EC fields do you want to enable and disable? What are the possible values for each of these fields?
Use the SuccessFactors Employee Central Implementation workbooks to outline exactly what fields will be used in EC, and where the corresponding info will come from in your on-prem system. If you have that ahead of time, building the replication scenario to match it will be a piece of cake.
2. Think about how much history is needed
This is a key question that will determine your strategy. Consider how much history of SAP ECC data you want to migrate over to Employee Central.
Some customers may wish to bring a certain time period of history to meet regulatory requirements if they plan on immediately shutting down their on-premise system.
If you are okay with only migrating “fresh” data, with no history, you can configure the add-on to only take the latest record from SAP ECC. This will make it easier as you will have less data to convert and will only have to worry about the cleanliness of the present data. If you have future dated records, you may want to run an action across your entire SAP system to create a split as of the earliest replication date. Then only the records on or after your Go Live Date will be migrated.
This decision will go into setting your “Earliest Replication Date”, a key property in defining your replication.
3. Consider security
Migrating employee data means migrating all employee data. SSNs, addresses, phone numbers, benefit information and more can potentially be included. Consider security when making a migration and testing plan.
For example, in your first few iterations perhaps scramble SSN and other sensitive data in the SAP ERP source client before migrating. That way when you are doing first rounds of testing, you can be more relaxed about potentially exporting the CSV files, having a large testing team with access, etc. and can focus on getting used to the process and technologies.
4(a). Don’t reinvent the wheel…
One intimidating part of starting your first migration from SAP ERP to Employee Central is building all of the field mappings necessary. However, you don’t have to start from scratch. As described in the implementation guide, SAP provides sample field mappings that you can use as a reference point. If you copy these field mappings from client 000 to your source client – it will give you a good starting point.
Many of these objects, such as home address, email and phone information are very standard among all companies. So the field mappings should be pretty close to your needs!
4(b). …but don’t feel stuck
The BIB Integration Add-On is completely customizable. Mapping a custom infotype field to a standard or custom Employee Central field is very easy. After importing the metadata from Employee Central, you simply map the target EC field with the source ERP infotype and field. You can even create a custom value mapping table to translate the value into its EC counterpart.
And if your requirements are more complicated, there are BADIs available for you to leverage. With a strong ABAP developer, you can map fields based on custom crosswalk tables, multiple different infotype criteria, or whatever else meets your requirements. I hope to expand on the available BADIs in a future blog, so let me know if you have specific interest.
5. Coordination between EC Team and Integration Team is a must
If you have one person (or one group) configuring Employee Central, and one person (or one group) configuring PA SE IN 100, they must be in sync at all times. The Business Integration Builder relies on two major inputs from Employee Central: the OData Metadata and the picklist .CSV file. If the Employee Central configurer adds a new field, the metadata will need to be re-exported and reimported into the ERP system. If the EC configurer changes a picklist value, the picklists will need to be reexported and reimported. In a quickly moving project with changing requirements and multiple testers, you can understand how one small change can snowball into a big mess if not properly communicated.
These two people or teams need to be in constant communication to be sure the two systems speak the same language.
6. Think about your overall strategy
The Business Integration Builder add-on offers two approaches for employee data replication: web-service based (using SAP Cloud Platform / HCI) and CSV based.This blog focuses on Web Service based replication, which leverages Employee Central’s OData APIs to upload employee data from SAP ECC.
In a CSV based approach, when the employee data extraction program is run, all employee data would be downloaded into a series of flat files (.CSV). These would then need to be imported manually into Employee Central.
Especially for any sort of ongoing replication, such as a hybrid or side-by-side scenario, web-based replication is the way to go. If doing a one-time load of employee data from SAP to EC, some customers prefer a CSV based approach because they can analyze every row of employee data before loading it to SF.
I typically configure the PA SE IN 100 add on to work for both a CSV and web based approach, so that more of a “hybrid approach” can be leveraged. The CSV files can still be exported for manual validation if needed before the replication is ran, but when it comes time to replicate, the data will be sent via SAP Cloud Platform. For actual conversion, I prefer the web based approach because any errors are written to the log tables in ERP so they can be easily accessed and maintained in an orderly fashion.
7. Start small
When first starting replication, start small.
First set up the connection.This is a prerequisite that can be unpredictable depending on what firewalls are setup in a customer’s system, or it can be completed in less than 30 minutes if everything works. I’ll write a separate blog on this category. But one of the first activities should be setting up the HCI flow, completing the connection details, and testing out the connection.
Once you get the connection setup, get the key employee data fields mapped and try it out. Send one employee first. Then add the other fields. Once one employee is replicated try a small group of employees. Work through their errors. Eventually you’ll get to a point where you feel comfortable running your whole employee extraction.
Breaking the initial replication setup into bite size pieces make it much more manageable.
8. Consider the mini master replication back
If you have any needs to replicate your data back to SAP ERP, such as a hybrid or side-by-side scenario, always consider what the mini master replication will look like when building your strategy. For example, if going through foundation object changes and you build a custom crosswalk table that works one way, think about how it will work in the opposite direction. You may need to reconfigure your SAP ERP system to accept the “new” values if making significant organizational structure changes as part of the EC Go Live. Have a plan in place.
Once Employee Central becomes the system of record for employee data, this step will ensure that any users or interfaces still using SAP ERP work as expected.
9. Test, test, test
With thousands of employees, and possibly hundreds of fields, there are lots of different cuts of data possible. A successful employee data migration can be especially challenging because it not only measures your configuration and mappings, but it also depends on the integrity of the employee data in your system today.
Have a devoted testing team available to validate the employee data in EC. Employee data can be exported via AdHoc reports in EC to ensure it matches expectations. If applicable, do another validation when the mini master results are written back to ECC.
The amount of testing that needs to be completed should not be underestimated. This is the core employee data, going through multiple layers of translation, and you need a team ready to find defects well ahead of go live.
10. Have technical and functional experts
Configuring the Business Integration Builder requires a mixture of technical and functional knowledge. Be sure you have a team to support that. In order to truly map the data, you have to create field mappings to show where every field in EC should come from. When necessary, you also have to create value mappings to translate every possible value in SAP ECC to every possible value in EC. This requires a strong functional leader who can get those details sorted out, a strong EC leader that understands the appropriate values in EC, and a strong technical resource who can configure these in the add-on, as well as utilize them in BADIs.
Be sure you have the talent necessary when putting together your conversion strategy.
I hope these ten tips are helpful for your employee data migration. Please share if you have any others which I may have left out!