Planning the Design for Recruit to Onboard

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

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.

• Who is responsible for maintaining Job Profile Builder?
• Who is creating the Positions?
• Does the Hiring Manager create or only copy an existing position in the Position Org Chart?

Consider segregation of duties while planning business processes by Role. For example, if the HR service center is involved, they can’t complete all administration tasks related to the Recruit to Onboard process. Ideally, the HR Admin/Human Resource Business Partner (HRBP) should perform this step.

It is important to define the various conditions/rules for Internal Hire scenarios. Here are a few leading practice recommendations:

• Position Change: Event-based without Recruiting and Onboarding, typically initiated by a manager for a change in position as a result of an annual Merit & Performance process that could result in a change in position and compensation due to Promotion.
• Requisition-based: Going through Recruiting and Onboarding, typically initiated by an employee by applying to a different position via the internal career portal for the same or a different country. The new position is ideally located in a different Legal Entity, Department, Cost Center, or Organizational Structure. For example, a Financial Credit Analyst applying for a Flight Operations Manager role.
• Crossboarding: Going through Onboarding, similar to a Position Change, but the new position could be in a different organizational structure or come with additional responsibilities that require the employee to go through Onboarding to sign additional forms.

• The Job Profile Builder to Requisition interaction is not mandatory for the Recruit to Onboard process. A complete Job Profile Builder reusable library for all job codes by go-live is good to have if there are resources and time constraints.
• However, it is highly recommended to Identify a pilot group of Job Codes based on Location/most recruited positions/divisions, etc., and define complete Job Profile Builder components: Job Family, Job Role, Job Profile, Job Description, Competencies, Skills, etc.
• It is not possible to send data first from Recruiting to Employee Central (EC) when a candidate is hired and then additional data from Onboarding (ONB) once onboarding is complete. All candidate data should be passed to ONB and then EC.
• Leverage EC Position Management to create job requisitions starting from positions and inheriting pre-defined information regarding job description, salary ranges, etc. Note: if the customer is using position management, the system must have the position in place before the requisition can be created.
• The leading practice is to pass candidate data from Recruiting to Onboarding, then from Onboarding to Employee Central when customers are leveraging all three modules.

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:

• Much design planning is required while migrating any HRIS system; however, it is very important when the existing Talent modules in SAP SuccessFactors have years of history built based on the structure of the non-EC HRIS system.
• Evaluate the SAP SuccessFactors release version of existing Talent modules, and if time permits in the roadmap, always update the existing Talent modules to the most recent release version.
• Give sufficient time to define the UserID, Username, and Person ID fields if Learning Management is already live. The leading practice recommendation is to use Active Directory/Windows ID as Username and Employee Number as UserID. Refer to ALP: Platform Shared Objects and RBP for more information.
• Identify and allocate resources and time in the project plan for retrofit activities and essential cross-module integration between modules in Recruit to Onboard, and other talent modules (e.g., Employee Central and Compensation/Variable Pay, Onboarding and Learning). Refer to ALPs: Reward and Retain and Develop to Grow.
• Revisit the Role-Based Permissions (RBP) Framework and existing talent Roles/Groups to redefine the Roles and, if possible, Granted/Target Groups.
• It is advisable to create a Custom Business Rule for Rehire Check during the Manage Pending Hires process for active employees prior to a Recruit to Onboard go-live. You can store the basic employee information in a custom Metadata Framework (MDF) table.

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.

• There is an advantage when Recruit to Onboard is the first process implemented, as you get maximum time to design the Foundation and Organizational structure.
• Involve all customer Business SMEs/Leads during the Recruit to Onboard design workshop. Compensation SMEs, Learning SMEs, and others can contribute to the overall design of the Recruit to Onboard process, which will result in less retrofit work when Talent modules are implemented.
• Try not to create too many Custom Objects or Tables, or design to accommodate a business process which is already available as part of the standard offering in one of the Talent Modules and is in the roadmap to implement. For example, creating many custom portlets to store compensation information or history.

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