Explaining the Variable Pay Program Components

The Employee History Data (EHD) file lists all the bonus-eligible employees and their assignment details. These assignment details are used to determine which bonus scheme they belong to.

Employee History Data is used for the following:

1. Calculation of bonus target or basis.
2. Assignment dates in the employee history data are used to determine proration.
3. Eligibility for bonus plan is determined by fields in the Employee History Data file.

The functionality supports pulling data from fields of one custom MDF object during the Import Employee History from Employee Central process for Variable Pay templates.

Bonus caps can be defined in the following two ways:

• By Bonus Plan: The total of the business goal payout amounts cannot exceed a pre-configured percentage of the prorated target amount for that assignment.
• By Employee: The total payout amount for the employee cannot exceed a pre-configured percentage of the sum of the prorated target amounts for the employee.

Business goals are objectives laid out by the company, typically measuring profits and revenues against a given target.

Business goals are linked to bonus plans and assigned weights for payout calculation.

The three Payout Function Types for calculating business goal payout are:

• Interpolation: Interpolation Payout Function type works by approximating the payout value between the two given data points.
• Step: The system will always take the lower value when achievement is between performance targets.
• Direct: Business goal payout will be based on customer entered values.

If your organization needs to control which users can see which fields of a Variable Pay program, Field-Based Permissions provide this control, just as in SAP SuccessFactors Compensation.

Administrators can add restrictions to standard and custom fields, limiting the field’s visibility and editability by Role-Based Permissions role. This allows Human Resources employees to view sensitive information on the worksheet but keep that information hidden from planners.

Another use of Field-Based Permissions is to control which users, such as HR or administrators, have access to any override capability.

1. Document your process prior to the kickoff: This does not need to be a detailed document, but you should have a high-level overview that may be passed along to the consultant.
2. Keep your workflow simple: This is especially true for your first year. Consider the approval levels, which can lead to higher-level managers getting numerous emails. Complex approval processes, such as iterative and steps requiring signatures for certain exceptions, could lead to a prolonged process.
3. Provide a dedicated resource: Your Compensation department may be small relative to the overall organization, and compensation analysts and managers are typically taxed with numerous high-level projects that prevent them from fully comprehending what they expect to learn during implementation.
4. Identify the system admin before or during project kickoff: This allows the consultant time to have the admin practice and demonstrate their knowledge.
5. Ensure that the implementation team has easy access to key stakeholders: Ideally, these stakeholders should be involved in the project and be authorized to make any necessary decisions when needed.
6. Have your own (internal) discussions to map out current processes and roles: Taking the time for this first step helps ensure that these roles will be translated into Role-Based Permissions (RBP) accordingly.
7. Keep the repurposing of system fields and functionality to a minimum: SAP SuccessFactors is very flexible and allows for the repurposing of many items to meet a client’s needs. However, overuse of this flexibility may cause problems with future implementations because other modules may require certain functionality. When there is no other option, these changes should be well-documented and easily accessible by future consultants.
8. Review the latest release information as upgrades and enhancements occur: However, future functionality is not in scope during an implementation.