As companies begin transitioning to the cloud, we are getting a lot of questions around how to migrate to Employee Central from on premise SAP system effectively. What are the key questions to address prior to making the leap to the cloud and what are the important considerations needed in the process? Throughout this blog, I will address these questions today in order to alleviate some of the mystery surrounding this process.
The first and most important question you must ask as an organization is if you plan on keeping your SAP on premise system up to date with the data from Employee Central, or will you retire it at go-live? In my experience, many customers choose to keep their legacy SAP environment due to the number of existing integrations that would need to be reproduced and signed off in Employee Central. This is a daunting task as part of the initial rollout and requires coordination with many different vendors and their individual testing requirements. Thus, the lowest risk approach is to replicate data from Employee Central back to legacy SAP and let the existing integrations and payroll processing run as they do today. You can then replace the integrations and payroll over time as separate projects, where the risk is more manageable.
Next, you must decide as an organization if you want to roll out the entire employee population in one big bang or, if you will take a phased approach.
Core Hybrid
If you plan on having everyone go live at the same time, then you are looking at a “Core Hybrid” approach to your data replication back to legacy SAP. This means that Employee Central is the system of record for all employees and the employee data only flows in one direction (EC -> SAP). This simplifies the replication process greatly as you don’t have to deal with transfers between live and non-live populations. This also means that data migration, conversion, validation, and regulatory approval must be acquired globally for go live. Switching to a phased rollout later on is not recommended as it will require a total redesign of your approach and replication process. My biggest piece of advice for this approach is to begin your mapping process as early as possible. Specifically, begin thinking through the desired future data model you want to have in EC vs. the current data model in SAP. There are a few key elements to check in this mapping and design decisions need made with conversions between the systems in mind. All of the following mappings must be able to convert seamlessly between EC and SAP. If there is ambiguity, it can cause issues later with the SAP configuration for valid dropdown values based on area/subarea and group/subgroup groupings on the SAP side.
1. Employee Group/ Subgroup to WorkAgreementAdminCategoryCode/ WorkAgreementTypeCode
2. Company Code/ Personnel Area/Personnel Subarea to Company/Location
3. Action/ Reason to PersonnelEventTypeCode/ PersonnelEventReasonCode
4. Pay component frequency in Employee Central to Payroll Area frequency in SAP
NOTE: The payment frequency (Hourly, Bi-weekly, Monthly, etc.) coming from Employee Central is validated against the payroll area frequency used in SAP. We’ve encountered and created workarounds to this validation for customers where these could not be aligned.
These values must be able to convert in both directions if you are going to successfully perform data conversion and load for go-live as well as ongoing replication of data from EC back to legacy SAP. Be especially careful of a single EC event type/reason mapping to multiple SAP action/reasons based on other attributes or context. If a single event is mapped to hire, rehire, and job change for instance, it will cause replication issues with the SAP validation checks for existing employees and status changes.
Side-by-Side
Alternatively, if instead, you plan on a phased rollout with different waves of employees going live at different points then you are looking at a “Side-by-Side” approach to your replication process. This means that for the live population Employee Central is the system of record and will replicate employees down to legacy SAP (EC -> SAP). However, for the non-live population you will maintain SAP as the system of record and transfer the employees to Employee Central using either web service integration or file extracts (SAP -> EC). All of the mapping decision points referenced above will still apply to this process. If this is your approach, the recommendation is to split your population by company or country for the phases. The replication configuration allows you to specify which companies and countries to feed to legacy SAP.
In addition, you can also configure the allowed countries as part of the SAP inbound logic to filter out countries that are not in scope. Any employee records that are in a non-live country/company will be dropped from the replication in this manner, however you still need a way to send the SAP data for those employees back to Employee Central. There are several ways to accomplish this, such as leveraging the standard SAP extraction templates or writing your own custom code to extract templates in CSV format for transfer via SFTP. Alternatively, you can leverage the web service integration delivered by SAP to transfer employee data. SAP is working on expanding the configuration capabilities of this interface to handle custom relationships and other data you may want to export by giving you the ability to write your own extract logic to map to an EC field. I have seen the demo of this and it will be a very powerful addition to the integration capabilities to get more real time data transfer. In either approach, you must filter the employees sent over by the inverse set of companies/countries as the live population to avoid any circular employee updates from the change pointers. Additionally, there is a more complex scenario addressing how to transfer employees from live to non-live or vice versa. I will cover this more in depth in another blog post.
In summary, you need to decide on your approach early as it affects the replication scope between Employee Central and SAP greatly. There are also impacts to your configuration and customization requirements to facilitate the selected approach. I referenced several critical mappings that you need to have ironed out early in your design process to avoid headaches later. These are the most common causes of replication related errors between the systems, so having a solid data model mapping up front will eliminate those issues later on. Finally, if you decide on a phased rollout, then you will need to break your population up by company or country in order to prevent employees from the non-live population from being sent.
Hopefully this post has been informative and started the requirements gathering process for your organization. I will be posting a subsequent article on Side-by-Side integrations and some of the pitfalls to avoid in my next blog post. If you have questions please contact me at mwhite@gpstrategies.com.
About the Authors
