Are you preparing to implement the “big three” modules in the SAP SuccessFactors suite? Implementing Recruiting Management, Onboarding, and Employee Central can yield benefits to an organization. You have all your hiring and employee data in one system. However, you need to carefully consider some points to make sure you get the most benefit out of these integrated modules. Integrating data correctly across these modules will prevent lots of rework and make the system much more friendly to your end users. 

Many organizations are implementing these three SAP SuccessFactors solutions, Recruiting Management, Onboarding, and Employee Central, in a siloed fashion. The siloed model for the implementation design results in much of the initial design work needing to be redone to synchronize the process. Decisions made in one area for configuration directly affect the overall system flow of the three modules. We provide you with an informative guide for minimizing the risks associated with this kind of multi-module implementation. 

Our focus is on the key design decisions that companies must make in the implementation phase. To elucidate, we cover our recommendations, gathered from our years of hands-on implementation experience, to give implementation teams a solid baseline when tasked with an HR system deployment of this type. 

Use Standard Organizational Objects

We recommend a design approach focused on leveraging delivered configuration as much as possible. The system is designed with standard organizational structure objects. Because these objects are inherent in the system design, they tend to “talk” across modules better than custom elements might. Teams or sub-departments are examples of custom objects.

Recruiting as of the 1705 release now sits on a MetaData Framework (MDF) platform, resulting most notably in improved data flow between recruiting and Employee Central, but custom objects may need to be recreated in the Onboarding module, which can add to configuration and testing timelines.

That means that any future maintenance to your org structure must be updated in all three modules as well. It is much simpler to create and maintain your org structure and data if you use the standard structure available. Figure 1 is an example.

For more information about Employee Central organization structures, follow this link: https://scn.sap.com/community/erp/hcm/blog/2014/10/28/the-successfactors-employee-central-organization-structure

Figure 1

An example of a standard org structure in SAP SuccessFactors Employee Central (that can be leveraged in Recruiting and Onboarding)

Recommendation 2: Deploy Employee Central First in the Implementation Cycle

A high-level assumption with this data flow is that Employee Central should be considered as the master system of record and should be deployed before or at the same time as Recruiting and Onboarding.

With this approach, we suggest that the Recruiting and Onboarding leads will have a solid understanding of the system decisions in the core HR setup to facilitate more efficient design decisions in Recruiting and Onboarding.

These stakeholders need to understand how the data collected in their modules may ultimately be used in Employee Central. These workstreams need to have a clear picture of what is required as the Employee Central configuration is the master system of record for the employee.

The organizational structure and position and job code objects will be built out in Employee Central so that the other two workstreams can use this dataset. For example, the job code object can be used in Recruiting to auto-populate salary ranges and Fair Labor Standards Act (FLSA) status onto a requisition based on the job code selected. However, this can only be done if the job code object is set up in Employee Central to house this data.

The two workstreams need to communicate constantly to make things like this work. With Employee Central as the ultimate system of record (as the data will reside in Employee Central during the employment of a worker), picklist values should be replicated in Recruiting and Onboarding, which means there is less field-mapping rework required. For example, the job level on the Employee Central position will be the same set of values used in the requisition form in Recruiting. This means that the job levels are defined in Employee Central, but are passed from position to requisition in a seamless manner.

If design decisions are made for Employee Central first, you will know which data needs to be collected for an employee. You can then work backward to determine where that data should be collected. For example, name and home address information is typically collected on the job application in Recruiting and passed easily to Onboarding through to the core HR module, which is Employee Central.

Emergency contact information is usually collected in Onboarding. Compensation details may be entered directly into Employee Central at the point of hire. In this way, working backward, you can collect all the necessary data that needs to be exported into Employee Central, and you can also determine which data does not need to be mapped into the other modules. For instance, who is assigned as the recruiter on a requisition is critical to Recruiting functionality and may be important to metrics, but it is simply not important to attach this to the new hire’s data. Once the person is hired, no one is concerned about who the recruiter was.

An overall data field document is an invaluable resource at this point in the project. Using the previous example, I explain how if you have this kind of documentation, you would now be able to see that emergency contact information is not needed in Recruiting. Home address information must be configured in all three modules and integrated between them. This mapping document can be used to visually track where data comes from and how it is used. The mapping document can also feed the specific requirements for each individual module. Table 1 shows a simple example of such a document.

Recommendation 3: Know the Limitations of the Systems

The capabilities of each of these three modules are very different, and while they complement each other, they may not always accommodate all functionality across the entire process flow.

For example, Employee Central offers extensive country-specific capabilities. However, this functionality is not supported in Recruiting. So in Employee Central, you may have different pay ranges associated with a job code based on the country where the job is located. In Recruiting, the pay range can be auto-populated into a requisition from the job code, but Recruiting only uses the standard job classification object and cannot populate different values based on country. This means less automation of data, resulting in a higher risk of data error.

If populating the pay range onto a requisition based on job code is critical, then separate job codes need to be established for each country. If simplifying the job code structure is more important, then Recruiting may have to live with not being able to auto-populate pay ranges onto requisitions.

You also may have the need to duplicate some data in the system. This can make maintenance more difficult, but can be beneficial in the long run. For instance, the job classification object has a standard field for salary grade. Salary grade may be a beneficial field to include on a requisition, but Recruiting can’t use the standard salary grade field to auto-populate a requisition. A custom field can be added to the job classification object to hold the salary grade, and this custom field can be used on the requisition.

The drawback is that the same data needs to be maintained in two different fields on the job classification object. This isn’t too complicated, as copying and pasting the column on the import file accomplishes this task. However, the people responsible for maintaining this data must establish a process to ensure this is done, and to keep the data in sync. The benefit is that the data then becomes available to be used in the Recruiting module.

Recommendation 4: Consider Integrating Employee Central Position Management with the Recruiting Requisition

It is important to remember that the integration of these three modules is not limited to the new hire data that moves from one module to the next with the hiring activity. You can also integrate job data from one module to the next before a new hire is identified. This integration provides consistency to your processes and allows you to bring your data full circle.

With this integration, a position must be created in Employee Central using the Position Org Chart, perhaps a peer or lower-level position as shown in Figure 2.

Figure 2

Peer Position setting on the Position Org Chart (that can be seamlessly leveraged in Recruiting and Onboarding)

Once the position is created, you can detail all the attributes of the position in the master system of record—Employee Central. You then create a requisition from that position and eventually hire a candidate into the position you created. This allows for complete consistency of data throughout the process, as data is “automatically” fed from one module to the next. This process is outlined in Figure 3.

Figure 3

Basic flow from position to requisition to new hire

We do have one word of caution to consider when using this integration: The new hire is hired into the position exactly as it was originally created in Employee Central. If attributes of the job are changed on the requisition, the position for the new hire won’t be exactly the same as the position he or she applied for in Recruiting. This could cause problems with compliance, and it can certainly cause administrative problems internally and issues with job expectations for your new hire. Our recommendation for making sure this doesn’t happen is to restrict editing of job data on the requisition and to only bring job attributes over from the position. If something changes, the requisition is canceled, the position is modified, and a new requisition is created.

Paul Rose

Paul Rose is a Product Center of Excellence Manager for Employee Central at Aasonn (www.aasonn.com). He is the global subject-matter expert for Aasonn and is responsible for ensuring best practice Employee Central implementations on a global scale. Paul has a degree in Business (BComm) as well as an MBS in HR. You can follow him on Twitter @paulrosehcm.

 

You may contact the author at prose@aasonn.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.

Leanne Goplen Zabriskie

Leanne Goplen Zabriskie is Aasonn’s Center of Excellence Manager for SAP SuccessFactors Recruiting and Onboarding. She is an experienced consultant, passionate about process design and implementation. She brings her experience as a recruiter and recruiting manager to her role, as well as her system’s expertise, primarily with SAP SuccessFactors and Taleo. As a subject-matter expert for Aasonn, she is responsible for best-practice recommendations and consultant education. She has spoken at conferences and events, most recently SuccessConnect 2016 in Vienna.

You may contact the author at lzabriskie@aasonn.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.