Accelerating Your Next SAP SuccessFactors Performance Management

⇨ Making decisions during implementation not only introduces unnecessary risk, but also result in project delays and increased cost to deliver a full solution.

⇨ A set of standard decisions need to be made for new performance management implementation that are also technology application-agnostic.

⇨ The article discusses some of the core areas which might serve as pre-work for an SAP SuccessFactors performance and goals implementation

A new performance management system implementation, especially in the case of SAP SuccessFactors, can be daunting. A lack of readiness from the customer side in terms of the design decisions that will be eventually needed as part of the implementation is one of the main reasons for this.

Assimilating information and making decisions during an implementation takes a significant amount of time and such activities should be carried out by the customers ahead of any technology implementation. Making decisions during implementation not only introduces unnecessary risk, but also result in project delays and increased cost to deliver a full solution that users feel comfortable with.

Although it can be argued that there is a fine line between whether processes should drive the design of a cloud application or if cloud application influences organizational processes, regardless of the answer, there is a set of standard decisions that need to be made for new performance management implementation that are also technology application-agnostic.

Such decisions can be crucial for technology engagement because rushed business decisions might result in tech changes after the rollout and can increase costs. Also, the fact that since performance management activities tend to be cyclical (one program a year), organizations have only one chance to get it right. Lastly, the lack of “business readiness” typically results in descoping many features and functionality turning the program into a downward spiral. This article covers the areas that companies can focus on before an implementation to position themselves effectively and strongly, while reducing the implementation risk and timeline. Here are some of the core areas which might serve as pre-work for an SAP SuccessFactors performance and goals implementation.

Decisions to Be Made

Programs and Populations

A significant decision that needs to be made involves clearly defining the performance management programs and the populations that will use them.

In case of SuccessFactors, there are several features and functionalities that can support various programs, especially about performance and goals modules. A typical setup includes an annual goal-setting phase in which the system offers a template for users to create and track performance goals. Features like cascading or sharing goals to teams are available including approvals, updates, and so on.

Once the goals for the cycle have been defined, continuous performance management might be used, which involves a place in the system for users to track frequent activities that are granular events and align them to performance goals. Activities once “completed” can be turned into achievements which are the building blocks of goals. In other words, users now have a place to track all the good things they are doing on a day-to-day basis, which make up the “status” of the performance goal that was agreed upon at the beginning of the cycle.

The system also offers the ability to request feedback in general and align it to a specific activity to complement continuous performance management. Such feedback requests are invitations sent to users of choice that might, in written format, document the current thinking towards someone or someone’s performance.

Users can also provide feedback proactively and is meant to be a more informal way of documenting “pointers” on the spot for employees to start, stop, or continue doing in their day-to-day. Also, the system does have a solution to conduct 360 reviews. Plus, 360 forms might be generated in a centralized way to the entire organization at once or on an ad-hoc basis. The system offers a robust features to enable this process.

Lastly, one of the key processes for any performance management program involves an annual performance review form. Although the design of such programs varies, these typically include a section to assess final performance goals status, both organizational core competencies and job-specific competencies, and calibrate the overall final rating (calibration might also be done in the system). Although these do not replace a conversation, they typically include comment sections, ratings, acknowledgements, and a wide variety of additional features and functionalities.

It is also important to know which programs might be supported at a company level and which ones will be enabled by SAP SuccessFactors. In summary, SuccessFactors offers:

• Performance Goals Management
• Continuous Performance
• Continuous Feedback
• Performance Management Forms

In addition to understanding which programs are supported and which will be enabled by SAP SuccessFactors, organizations also need to define which user groups will have access to them.

The system offers flexibility in terms of features and functionality that can be mixed and matched. Although the initial reaction might be to make available everything for everyone, the reality is that organizations might choose to only offer certain pieces of functionality to certain people, or even different design of the functionality to different people because of certain contingencies. As an example, if an organization decides to promote goals management only to the professional population and not to the “indirect” population, two versions of a performance management form might be generated—for professional employees, which includes a goals management component, and the rest of the population without it.

Populations typically are partitioned in:

• Employee group/type
• Region
• Location

Thus, the absolute most important decision that needs to be made up-front involves understanding the following:

• The programs the organization would like to support
• Programs that the system can support
• Programs that the organization wants to enable
• Programs to be used for the different user groups

Goals Design

Deciding on what information is needed to track a goal is also essential. This includes the fields necessary for a goal to be maintained in the system and who is expected to populate it. These are some examples of fields to be included:

• Goal name
• Tasks
• Start date
• End date
• Status
• Milestones
• Comments

Beyond figuring out the necessary fields; it might even be a good idea to go one step further and confirm the field type as well as any other detail. For example, “Status” must be a dropdown type of field and the values for the dropdown include “Not Started,” “On Track,” “Behind,” “Canceled,” and “No Longer Relevant.”

Route Maps (Workflow)

Route maps, or workflows ,are the sequence of steps a performance form needs to go through. This is important because it’s fully driven by the process that forces organizations to do process work ahead of the technology implementation. Some of the key questions about it include:

• Would there be an employee self-assessment?
• Would there be a calibration step?
• Behavior within each steps
• Are the steps only for managers and employees, or would other roles be involved too such as matrix manager and HR?
• Name and description of each step

Having answers to these would save a tremendous amount of time.

Translations

Decide whether you’d like to translate all the different features and functionality. For example, if you defined the goal design as well as the steps for the performance form, assuming that you do want to translate these to other languages, you can begin the process even before the technology implementation begins.

Remember that anything that includes text must be translated for consistency purposes. These might include labels, instructions, dropdowns, help text, email notifications, etc.

Mobile

Decide whether you’d like to consider rolling out the functionality in the SAP SuccessFactors mobile app. Although this might sound like an easy decision, it might not be. Some things to consider include functionality parity with desktop version, user experience, current mobile use policy, translations, permissions, etc.

Rating Scales

Assuming you will have rating scales for rating purposes in your performance management form, these ratings scales can be defined ahead of time. This should include a decision on whether everything (goals ratings, competency ratings, etc.) and everyone (all potential variations of the form to support different populations) will support the same rating scale, or these would change depending on variations. Important items to consider include ratings, labels, descriptions for the labels, whether they would be calculated rating or not, etc.

Calibration

Calibration is the process in which different groups of employees, typically at the same level, are reviewed across teams to ensure a balanced distribution of performance ratings, as well as to avoid biases like a “5” for manager A is equivalent to a “2” for manager B.

Although SAP SuccessFactors offers a fairly robust solution, the process of calibration, depending on the organization, tend to be different and/or complex; therefore, the key decision would be whether calibration would be done in the system or outside the system. This would have an impact on the configuration.

Compensation Integration

A fundamental element of compensation management tends to be the impact an individual performance rating might have in guidelines. Although compensation management might, or might not be done in the system, the idea is that these performance ratings flow automatically to the compensation module, if done in the system, or at least an integration to a third-party system is considered.

In addition, things like ensuring that the ratings and the guidelines match, for example if you have a rating of “Too New to Rate” or “Unrated,” what impact would it have on compensation? Also, timing of events is key:

• When does the performance management cycle end and when does compensation begin?
• Do ratings need to be completely finalized before flowing to compensation, or they’re in progress, so might still be sent?
• What happens if performance ratings change in the middle of compensation planning?

These are a few of very important questions that should be cleared out before involving the technology.

Reporting

Lastly, an inventory of all reports needed to support and monitor the performance management cycle should be defined ahead of time. This inventory should include at a minimum:

• Name of the report
• Report description
• Information that the report should include
• Audience for the report
• Report priority (must-have or nice-to-have)

Although this list eventually might be refined and expanded during the implementation, it will save a tremendous amount of time as well as influence the design of the system to ensure that the information needed (and in the format needed) can be reported.