Planning the Design for Reward to Retain

Next, you'll learn the key design planning steps when working on a Reward to Retain implementation project.

Next, you’ll learn the crucial final design considerations for implementing Reward to Retain together with other cross-module processes. Whether it's a Greenfield implementation or a phased Brownfield scenario, involving all customer Business Subject Matter Experts (SMEs) during the Reward to Retain design workshop is essential for successful integration across various processes. We will delve into topics such as integration aspects, competency framework, role-based permissions, and job profile builder to ensure a seamless implementation. You’ll learn how to align processes, consider data migration impacts, and navigate the complexities of implementing Reward to Retain in conjunction with other modules.

In the Greenfield scenario, the customer is an entirely new SAP SuccessFactors (SF) implementation integrated with or without Employee Central. The following are important considerations.

• Define end-to-end processes across Employee Central (EC), Talent, Time, Payroll, and Benefits with clear roles and data exchange.
• Define process variants for regular employees and contingent workers.

• What data is mastered in EC, and what data is only needed in Time, Payroll, and Benefits?

• What data needs to be synced back to EC?

Involve all customer Business SMEs during the Reward to Retain design workshop to discuss and align on common topics like:

• Integration aspects across the Process
  • For example: Goal Management with Learning Management
  • Performance Management with Career Development Planning, etc.
• Competency Framework
• Role based Permission
• Job Profile Builder

A Brownfield implementation is a scenario in which a customer is implementing a new SAP SuccessFactors (SF) module while live on an existing SF module. Working on a Brownfield project is complex, and efforts will need to be focused on the following SAP SuccessFactors modules/features:

• People Profile
• Recruiting
• Recruiting Marketing
• Onboarding
• Performance and Goal Management
• Compensation and Variable Pay
• Learning Management System
• Succession
• Succession to EC Global Assignment
• Workforce Analytics
• Role-Based Permissions

Let’s go through each module to determine the best course of action.

• SAP SuccessFactors Employee Central (EC) serves as HR Core and contains relevant information to manage employees through their lifecycle with an organization from hiring to retirement (or termination).
• EC contains many more data points about employees (e.g., national ID, dependent information, etc.) that are essential for core HR but not needed for talent management. Therefore, only a selective set of data is integrated into the People Profile.
• Clients who have implemented Talent before EC will want to ensure that data elements required for those other modules are now sourced from EC via data mapping activities.

• People Profile is the platform for Talent Management activities and modules, requiring core employee data housed in an HRIS system, which is EC in SAP SuccessFactors (SF).
• Employee Central leverages Metadata Framework (MDF) portlets.
• Currently, Profile and Succession use XML portlets accessible through Talent Search.
• Each portlet will need to be reviewed to determine if they are necessary for Succession for Talent Search or if EC replaces them.
• Succession uses a separate profile tab typically called Talent Profile (client determines name), which is a good way to determine what the client considers Talent Data vs. EC only.
• Examples of Talent Data might include Licenses/Certifications, Education, or Functional Work History.

• All position and organization data will be sourced from Employee Central - Requisition fields need to be reviewed and mapped.
• Revisit Requisition approval processes to leverage EC workflow.
• Position Management
  • To Be Hired flag in Employee Central.
  • 1 position: 1 requisition: 1 hire.
• Job Profile Builder (JPB)
  • Positions will now be available and inherit the Job attributes.
  • If Job Codes change, there will be rework to remap.

Data mapping activities will take place to ensure EC supports module data requirements.

• SAP SuccessFactors Onboarding uses the same entities, MDF Objects, and data model/APIs/Localization as Employee Central. It is essential to plan field design, considering regression impacts between both processes.
• Reporting on Onboarding data is done using People Analytics. For the enablement of People Analytics, SAP Identity Authentication Service (IAS) and Identity Provisioning Service (IPS) enablement are technical prerequisites.

• Data mapping activities will take place to ensure EC supports the module data requirements.
• Job Profile Builder
  • Typically implemented with Position Management.
  • In Performance and Goals (PM/GM) – Drives the competency mapping.
  • Need to partner with Recruiting, Succession, and Compensation owners to align strategy.
• Reporting Filters may be impacted by data changes coming from Employee Central via the HRIS Sync (User Data File).

Data mapping activities will take place to ensure EC supports the module data requirements.

• Data mapping activities will take place to ensure EC supports the module data requirements.
• The most significant change for the LMS will be receiving Job and Organization data from EC.
• Data that compose these files today will need to be remapped to EC for file transfer and consumption by the LMS.
• Recommend evaluating the Integration Center-based approach to sourcing data from EC.
• Assignment Profile Analysis: Review other data changes for impact on Assignment Profiles.
• SAP SuccessFactors Suite: Impact of Implementing Employee Central for LMS Customers

• Data mapping activities will take place to ensure EC supports module data requirements.
• Position Management will be sourced from EC and shared with SAP SuccessFactors Recruiting. If a client has already implemented EC Position Management from their current HRIS or uses the Succession Position Management tool, this will be impacted.
• Organization structure elements like Legal Entity, Division, Department, Location, etc., are maintained as custom fields in position objects used in Succession planning and appear in Position tile filters under Succession. With EC in scope, these will be Generic Objects and will not appear in filters. Hence, the decision has to be made whether to retain the custom fields, create a Business Rule to sync the values from EC standard fields to custom fields, or to delete the custom fields if the filters are not business-critical. Also, if the decision is to retain the custom fields, the same will be hidden in the position UI for a better user experience.
• If the position codes are to be retained as is, the succession data will remain intact; hence, there is no need for data migration.
• If the position codes are to be overwritten, back up position & succession nomination data, and map succession nominations from old positions to new positions, and then upload. Only the latest nomination information is migrated, not the history.

• Home position is unassigned from the assignee’s home record. Succession nominations to the home position (if any) will remain with the home position. Succession plans can still be managed for the home position.
• The assignee’s home record should be nominated as a successor in both home and host entities as the host record is interim. Managers should be educated on the same.
• Home record – The Successor portlet under Talent Profile shows the nominations for the home position, and since the home position is unassigned, no successors are shown. If need be, home positions can be filled by another incumbent.
• Host record – No nominations are transferred from home to host or vice versa. In other words, there will not be any nominations as part of the talent insights of the host assignment. However, successors can be added to the host position.
• The Talent Profile acts as an internal CV within SF. Due to separate User IDs, two Talent Profiles and Talent Cards will be created for both home and host assignments.
• Background elements like Certificates, Formal education, Language, Awards, etc., will sync across home and host records.

• Rework to leverage Employee Central vs. external HRIS or other sources.
• Historical Data
  • WFA can source multiple data sources per module for an additional fee, which would need to be scoped due to complexity at the time of the project.
  • Some customers provide Frozen File(s) of historical data, and/or we have sourced the legacy system if it is still available.
  • Considerations: Weigh the risks, costs, and benefits of sourcing the historical data.
  • When a company switches HR systems, business processes often change, and fields are replaced or made obsolete. Therefore, the quality of the historical data can be compared to apples and oranges. Typically, 2-5 years of history usually provide sufficient trends in WFA from which a customer can build on using current HR system data for an apples to apples comparison.

• With the addition of EC, there will be new types of permissions available – Effective Dated (Current, History, Edit/Insert & Correct).
• Employee Self-Service (ESS) / Manager Self-Service (MSS): RBP allows fields to be permissioned by default to these roles and accessed via the Profile. (Decision: Can leveraging EC RBP allow the client to sunset other ESS/MSS tools?)
• Revisit existing RBP configuration to ensure any changes are updated and tested.

A Brownfield - Retrofit implementation is a scenario in which the customer has been live on one or more SAP SuccessFactors (SF) modules for many years and is now implementing Employee Central. The following are important considerations.

• Think through what requirements exist for Job Profile Builder (JPB)/Job Architecture in future talent solutions.
• Consider what future Compensation data will be required to run compensation processes, including data for determining eligibility and budgets.
• Consider how Learning could be assigned in the future and include those data elements in EC.
• Create a proper transactional system, with a clear split on what is relevant in Core HR vs. Payroll and Time.

• Data mapping activities will take place to ensure EC supports module data requirements.
• Job Profile Builder​ (job codes/job classifications).
• Typically implemented with Position Management​.
• In Performance and Goals (PM/GM) – Drives the competency mapping​.
• Need to partner with Recruiting, Succession, and Compensation owners to align strategy​.
• Reporting Filters may be impacted by data changes coming from Employee Central via the HRIS Sync (User Data File)​.
• It may require rebuilding the organizational and cost centers data transfer interface and the Security Domain structure.
• If User IDs need to change, a mass merge may be required to transition to new User records in Learning. Scripts to alter User ID are no longer supported. We have a User Merge API that can be used with a change in User ID, but this API is subject to the same guardrails and will take time to target an entire population.
• It may require analyzing user attributes used in Assignment Profiles (see details in notes).

There are many product-specific design planning considerations for the Reward to Retain ALP Greenfield, Brownfield, and Brownfield Retrofit implementation scenarios, depending on customer requirements.