This case study details the most common inherited design mistakes made in an SAP ERP Central Component (ECC) Management of Global Employees implementation scenario, as well for an SAP SuccessFactors platform deployment in a talent-hybrid scenario. (For more details about the different deployment options, read the HR Expert article, “Integration Setup for a Core Hybrid SAP ERP HCM Solution.”) Here I provide details for correcting these design issues and workarounds for the existing records to avoid the reimplementation of the Management of Global Employees module in SAP ECC or any data purge in the SAP SuccessFactors platform. The overall design, however, still conforms to the standard integration design.

Case Study Scenario Details

In this scenario, Mark Smith is an employee with a global corporation. He was initially hired in Singapore (SGP), and is transferred, temporarily on assignment, to Australia (AUS) and then later to the United States (US). He returns to his home location of Singapore at the end of each assignment.

The Non-Standard Global Employment Approach in the Existing ECC System

The organization went live with SAP ERP HCM in 2003 with SAP R/3 version 4.7. The Management of Global Employees solution was still in the pilot phase and had been released for just a few countries (e.g., the US and Canada). Since the organization had all the global employment cases outside of these two countries, it could not implement the pilot global employment solution from SAP. So, the following process steps were followed (note that all the steps in this section are in the SAP ERP HCM system). At the start of any global assignment, the following steps were performed:

• The current employment record (in the home country) was set to inactive by running an action
• The new employment record (in the host country) was created by running a hiring action in the host country
• From the date of assignment, the system ID of the user in infotype 0105 and subtype 0001 were delimited in the current employment record, and the same system ID was assigned to the new employment record (e.g., the new personnel number) in infotype 0105 and subtype 0001

At the end of global assignment, the following steps were performed

• The new employment record (in the host county) was terminated by running the termination action
• The old employment record (in the home country) was set to active by running an action
• From the date of completion of assignment, the system ID of the user in infotype 0105 and subtype 0001 were delimited in the new employment record and the same system ID was assigned back to the old employment record (e.g., the previous personnel number)

This process resulted in the following issues:

• No checks were performed in the system to ensure that the assignee’s common data of the global assignee (such as name, address, and phone number) were in sync across all his assignment records (Figure 1)
• In some cases, different user names were created and assigned for each assignment record
• The user names for all assignees were managed manually, which is prone to error
• There was no standard link connecting the employees together to enable correct full-time employee (FTE) reporting. In the standard Management of Global Employees implementation, the Central Person object is linked to all the assignment records (PERNRs) of an employee (shown in Figure 2).

Until the 4.7 release in 2003, SAP did not offer a global employment solution for all geographies. Later when SAP brought in the Management of Global Employees functionality in SAP ERP HCM (Figure 2), it required a compulsory technical review of the existing system by SAP before enabling these switches. (Companies or implementation partners cannot enable this on their own; it can only be done by SAP consultants.) Because the number of global assignees was small in the organization in this case study example (fewer than one percent of the population), it was hard to justify the additional cost and effort to implement SAP’s Management of Global Employees module. Therefore, these cases continued to be managed manually in the SAP ERP HCM system.

Incorrect Design in the Current SAP SuccessFactors Platform

Similarly, the transition to the SAP SuccessFactors cloud solution in the organization was gradual. The organization first implemented the talent modules in SAP SuccessFactors (hybrid deployment) before implementing Employee Central (core hybrid deployment). Thus, the user profiles in the SAP SuccessFactors platform were defined during the hybrid deployment, which did not consider the future needs of integration. The user-id and user name fields both were mapped and updated with the same value in ECC as the Communication (0105) infotype and subtype System User Name (0001). This is an incorrect design (see the next section for standard mappings). The user-ID and user name fields are required for all other SAP SuccessFactors modules as well (e.g., Performance and Goals and Learning) to manage the active employee’s activities. Hence only the active employment record (AUS in this case) of the employee was loaded on the platform. Other inactive employments in Singapore (SGP) and the United States (US) were not loaded (Figure 3). This meant that the full history of an employee’s employment was not present in the SAP SuccessFactors system. These records are required in the system as they have impacts in implementations of the Time (part of Employee Central), Compensation, and Payroll modules, specifically.

Desired Future State

The standard ECC global employment solution (Figure 2) in SAP ERP HCM not only links the different employment records using the Central Person object, it also provides for compensation and assignment-planning features for each employment. Since the roadmap of the organization was to implement compensation and other modules in SAP SuccessFactors, these additional features (Compensation Planning and Assignment Planning) were not required in the SAP ERP HCM system. Therefore, the desired future state was that after the Employee Central module was implemented in SAP SuccessFactors, all the global-assignment records would be maintained in SAP SuccessFactors and replicated to SAP ERP HCM. Also, all the different personnel numbers in SAP ERP HCM (for the multiple global assignments) should be consistent and in sync (Figure 4). This meant that the personal information (such as name, address, and user name) should be the same for all the personnel numbers associated with the same employee across SAP ERP HCM (ECC) and SAP SuccessFactors Employee Central. In SAP SuccessFactors Employee Central:

• An employee is uniquely identified by the person-id-external field value
• Each employment record for an employee is uniquely identified by the user-id field value
• The user associated with each employment record for the employee is uniquely identified by the username field

In ECC:

• An individual(employee) is uniquely identified by the Central Person field (Object CP) value or Person ID (infotype 0709) value
• Each employment record for an employee is uniquely identified by the personnel number field (Object P)
• The user associated with each employment record is uniquely identified by the username field infotype Communication (0105) and subtype 0001(System User Name [SY-UNAME])

Thus, the three fields in both systems are mapped as follows:

1. SAP SuccessFactors user-id = ECC personnel number
2. SAP SuccessFactors username = ECC username
3. SAP SuccessFactors person-id-external = ECC Central person or Person ID (infotype 0709)

Design Correction in SAP SuccessFactors

The key constraint in SAP SuccessFactors is that, once created, the user-id value of a user on the platform (or in Employee Central after its implementation), cannot be changed—it’s immutable. The same applies to the personnel number in ECC. Since the user-id values of the existing employees are already in the SAP SuccessFactors platform (hybrid model) and the user-id value cannot be changed, there were only two options to correct the inconsistent mapping design in the two systems:

1. Purge the users’ records in the SAP SuccessFactors platform and create new records in the SAP SuccessFactors platform with user-id fields containing the personnel number values from SAP ERP HCM. Then load the records after implementing Employee Central in SAP SuccessFactors (Figure 5).
2. Use the three fields in such a way that the mapping in the previous section holds true.

Since the first option of purging all the records meant that all the associated performance forms, learning history, development goals, and so on, associated with the employee would also be purged, this option was not feasible. Therefore, mapping all three fields in both the systems was the only viable option. The workaround mapping, shown in the bulleted list below, is the same as the standard mapping (explained earlier in this article), with one difference. The only difference is that in this proposed design the person ID external is always the user-id of the first (home) employment record:

• SAP SuccessFactors user-id = ECC personnel number
• SAP SuccessFactors user name = ECC username
• SAP SuccessFactors person-id-external = ECC Person ID (infotype 0709) = user-id of the home record of Global Assignees

Figures 6 shows the two possible types of global assignment records that exist in the SAP SuccessFactors platform. The first would be those employees who have a currently active global assignment (Employee1). The second would be those who had a global assignment in the past, but are back to the home assignment; hence, the global assignment is no longer an active (Employee2). Employee 1: The global assignee is on global assignment when the SAP SuccessFactors platform went live Employee 2: The global assignee is back from the global assignment when the SAP SuccessFactors platform went live and is now active at his or her home location Figure 7 shows the three possible types of global assignment records that would exist in Employee Central. It includes the two employee types in Figure 6 and adds another set of employees who would be hired after Employee Central goes live and then go on global assignment (Employee3). Note the different values in the SF User ID(user-id) fields for each employee.

Fixing the Design Issues in SAP ERP HCM

There were two things to be addressed in ECC:

1. How to set up the integration for these three global-assignment variants (Figure 7)
2. How to link all the home and host personnel numbers (existing and new) of global assignees so that their name, address, username, and so on are always in sync

In addition, both these objectives had to be achieved without implementing the Management of Global Employees module in ECC.

The Steps for Integrating the Three Variants

Once the mapping for the various employee record fields in SAP SuccessFactors Employee Central has been finalized, the design for mapping these employee record fields in SAP SuccessFactors Employee Central to the corresponding employee record fields in SAP ERP HCM must be updated in table PAOCFEC_EEKEYMAP to complete the integration (Figure 8).

1. For employees whose records are already in SAP ERP HCM, table PAOCFEC_EEKEYMAP must be updated to map the user-id in SAP SuccessFactors Employee Central to the personnel number in SAP ERP HCM. (Note that there are other fields apart from PERNR and user-id as well in this table that are used for various other integration/validation purposes, detailed in step 1, below)
2. For new employments to be created in SAP SuccessFactors Employee Central after go-live (this includes both new hires as well as new global assignments of existing hires), the implementation of a Business Add-In (BAdI) is required to tell the SAP ERP HCM system which field from SAP SuccessFactors Employee Central is to be used as the PERNR value for the new employee/employment record being created in SAP ERP HCM. This BAdI code implementation automatically updates table PAOCFEC_EEKEYMAP (detailed in step 2, below)

Step 1. The standard table PAOCFEC_EEKEYMAP was populated for all the existing employees on the platform. The first three fields—Employee_ID, Employment_ID, and Work_Agr_Item_Id—are auto-populated in Employee Central once the employee records are uploaded into Employee Central from SAP ERP HCM (or uploaded manually using load templates). The required mapping that creates the file from SAP SuccessFactors Employee Central to be uploaded in SAP ERP HCM is as follows:

• EMPLOYEE_ID (person ID) from Employee Central
• EMPLOYMENT_ID (employment ID) from Employee Central
• WORK_AGR_ITEM_ID (work agreement item ID) from Employee Central
• PERNR (personnel number) from SAP ERP
• BUKRS (company code) from SAP ERP
• EMPLOYEE_ID_EXT (person-id-externa)l from Employee Central
• USER_ID (user-ID) from Employee Central

In the case of the organization in which the solution was implemented, a comma-separated value (CSV) file was created by downloading it from SAP SuccessFactors Employee Central using an ad-hoc report (where fields from various tables could be chosen for the report dynamically). Then this file was used to update table PAOCF_EEKEYMAP in SAP ERP HCM ABAP using program PAOCF_EC_UPLOAD_EEKEYMAP_UPLOAD (direct table updating is not possible). Step 2. Implement the BAdI for all new employment records (this includes both new employees and new global assignments for existing employees in SAP SuccessFactors Employee Central). This BAdI implantation tells the SAP ERP HCM system which field from SAP SuccessFactors Employee Central is to be considered as PERNR in SAP ERP HCM. Note there is an exception made in the If condition of the Management of Global Employees module. This is to accommodate cases in which the user-id fields for Employee1 and Employee2 have a non-numeric value in the platform in Figure 7. In BAdI EX_PAOCF_EC_EXT_PERNR_MAP, the following logic was added in method IF_PAOCF_EC_EXT_PERNR_MAP~MAP_EXT_PERNR. (This is executed for new hires only—e.g., the first record of Employee3 in Figure 7): Personnel number = person-id-external (This field maps to column SF Person ID External in Figure 7) The following logic was added in method IF_PAOCF_EC_EXT_PERNR_MAP~PROCESS_EMPLOYEE_COMMON_ADDIN: IF the employment records have the global assignment (GA) event, then: Read the PERNR field from table PAOCF_EEKEYMAP using the EMPLOYEE_ID, EMPLOYMENT_ID, and WORK_AGR_ITEM_ID values of the user (this combination is for all user-ids in SAP SuccessFactors). This is the most significant condition. Note that instead of mapping one field (e.g., the user-id field) to the PERNR field in SAP ERP HCM, three fields—EMPLOYEE_ID, EMPLOYMENT_ID, and WORK_AGR_ITEM_ID—have been mapped. This condition would return the correct PERNR for all cases (Employee1, Employee2, and Employee3 in Figure 7). For the ELSE condition, have the following code logic: Set personnel number = person-id-external The IF condition takes care of all global employments scenarios (new or old), while the ELSE condition takes care of all the new hires in Figure 7.

The Steps for Linking the Personnel Numbers in SAP ERP HCM

Of the three possible employee record variants mentioned in Figure 7, the third case (Employee3 RBOND) represents all the employees who are hired after the design changes were made. Hence, the personnel numbers are linked automatically using the Central Person object in ECC due to the implemented design change. For the other two employees (Employee1 and Employee2) who already existed in SAP ERP HCM, each global-assignment record had a different personnel number and a different Central Person object linked to it (Figure 9). For each employee in SAP ERP HCM, there should be only one Central Person object as per the standard design and the design that was implemented (Figure 10). This is done in two steps:

1. Delete the PERNR to Central Person relationship for all the host assignment PERNR records (home assignment PERNR record relationship to its Central Person was kept as is)
2. Create a relationship between the Central Person of the host assignment record and all the host assignment PERNR records

Step 1. Delete the PERNR to Central Person relationship for all the host assignment PERNR records using SAP program RHRHDL00. Note that all the fields (except the Object ID field) need to be filled in the same way as shown in Figure 11. The Object ID field should have the personnel number (PERNR) for which the Central Person record is being deleted. Once the entries have been made (and checked), click the execute icon to delete the Central Person record that is linked to the personnel number record. It is always advisable to first do this step in test mode to double-check which records are being deleted. Step 2. Link the host personnel number with the home personnel numbers using infotype 0031(reference personnel number). This is done in transaction code PA30 (Figure 12). Enter the host personnel number (567041 in this example) and 0031 as the infotype, and then click the create icon. This opens the screen in Figure 13, where the host personnel number is to be entered manually. Make the required manual entries and click the save icon in the ribbon to save the new record (Figure 12). This links all the personnel numbers to a common central person, which can be viewed in table HRP1001 (Figure 13).