R/3's Succession Planning functionality, which helps organizations identify internal talent, requires a commitment from the business side of the organization. The continual update of detailed employee data is essential for a successful implementation. The author provides tips for designing or updating your succession planning strategy.
Having the ability to identify internal talent is a goal of most organizations. R/3’s Succession Planning (SP), part of the HR module, is designed to do exactly that. It gives you the ability to identify potential successors for highly leveraged positions, and to compare and contrast the qualifications of employees in similar positions. It also provides a repository of information for internal recruiting and the ability to match individuals for positions based on their competencies and the requirements of the position.
The SP module and its career planning component allow you to:
- Advance employees’ professional development. You can use it to map different career path scenarios.
- Ensure that staffing requirements are met. You can devise alternate organizational structures and positions to create potential scenarios of your company structure.
Unlike implementations of other R/3 modules, SP does not require a large amount of technical support. Although the technology itself is quite advanced, it only gets you halfway to a successful implementation. The other requirement is the continual update of detailed employee data, which depends on a commitment from the functional/business side of the organization.
In this article, I will focus on the cornerstones to the implementation of SP, which are the configuration of the qualifications catalog and the strategy for implementation of its use. One of SAP’s newest modules, it has very little reference material available. Below are the key considerations to take into account when designing or updating your succession planning strategy:
- Making the business commitment
- Creating a qualifications catalog
- Creating a rating scale and determining who does the rating
- Inputting requirements at the job or position level
- Identifying methods of collection
- Keeping the data current
Note
The SP functionality described here applies to releases starting with 4.0. To learn more about implementing Career or Succession Planning at your organization, visit the SAP Web site and use its new search functionality to search for “succession planning” documents for your specific version of R/3.
Making the Business Commitment
The various functions to set up succession planning are largely a business-driven initiative and commitment. The actual configuration of the components can be performed by a business/functional analyst and do not require a high degree of technical skill. An ideal candidate to perform the configuration would be someone familiar with your company’s use of the objects in the Personnel Development (PD) component (organizational units, positions, jobs, etc.).
At one level, you can look at succession planning as simply storing information on your employees in R/3 that is used to evaluate them and to make business decisions regarding their future. Most companies already store a great deal of employee information, including address, dependents’ names, organizational information, cost center, and salary. Succession planning data is another large subset of information that needs to be kept current in order for it to be meaningful. Many HR professionals already struggle to have employees update their most basic information, such as addresses, which is why succession planning requires such a significant commitment.
The implementation of any succession planning initiative requires you to dedicate a large amount of time to determine the key performance indicators that you wish to measure, to what level of detail you want to go, and who is qualified to rate someone on subjective classifications. The design stage of the succession-planning project is usually the most time-consuming. The decisions you make determine if the deployment is a successful one.
Creating Your Qualifications Catalog
R/3 refers to the repository of all the data you wish to track for an employee as a qualifications catalog. Determining what data you want to store is the first step toward building your qualification groups and catalog. You can select individual criteria including qualifications, preferences, potential, designations, dislikes, and career goals. Or you may combine them as you wish. This catalog is structured hierarchically on the basis of qualification groups. For example, if you have a qualifications group called “languages,” the qualifications under that group might be English, Russian, and Italian. Determining what data you want to store is often a challenge. There is no global set of qualifications that all companies share. Beyond some basic similarities, each company usually wants to track qualifications that are unique to its business. Taking it a step further, you may want to track different qualifications for different employees in your company. For example, you could create a technical skills qualification group containing skills such as Visual Basic, ABAP, COBOL, or SQL.
To design an ideal qualifications catalog, you must first determine which qualification groups are generic to all employees in your organization. For example, language, education, or business-specific licenses might be generic enough that you would want to have them apply to all employees. You then need to list the individual qualifications for each. Language is an easy one, because you can copy the list of languages from the language table on infotype 0002. Education could include classifications such as high school diploma, bachelor’s degree, master’s degree, or Ph.D. After determining your generic classifications, you identify qualification groups and qualifications that you wish to store for each level of employee. For example, a qualification group specific to accounting would house all the qualifications that are important to your accounting department.
Creating Your Proficiency/Rating Scale and Determining Who Does the Rating
For each qualification group, you are required to create a rating or proficiency scale. It is not meaningful to know that employees have ABAP as a technical programming requirement when you do not know if they can code at a programmer level or if they can only do some basic commands. You have many options in terms of creating your proficiencies. You can keep it simple and create a rating scale from 1 to 5 with 1 being a low rating and 5 being a high rating.
This leads me to the next point of who is doing the rating. Say you have a qualification group called “management skills” with qualifications for leadership, resilience, and analytical thinking. If you allow employees to rate themselves on these subjective qualifications, they can give themselves high marks. On the other end of the spectrum, if you allow a supervisor to enter the ratings, they may not be accurate. This is a common challenge when companies implement any form of a succession model. What many companies do, whenever possible, is to restrict the qualifications to objective criteria. Instead of rating managers as good or bad, you can rate them on the number of years in management, something that does not require an opinion.
However, in some instances, these types of ratings can be too general. Just because a manager worked for the company 20 years, it does not mean that he is a good manager. If your company has designed the SP module to help determine potential successors for key positions, you may need more information. A popular strategy is including actual performance ratings from reviews. If you are using the Compensation and Appraisal modules, you can integrate the data from them. If you are not, then you can store the performance scores as qualifications. You can create a qualification, call it “Annual Performance Rating,” and store the value there. Then, when you search through your SP data repository to look for a potential candidate for promotion or internal placement, you can specify that you want to retrieve only those who scored higher than a rating of 08 (on a 1-10 scale), for example.
Inputting Requirements at the Job or Position Level
In addition to storing qualifications for your employees, you can also assign requirements at either the job (PD object type C) or the position (PD object type S) level. The distinction here is that qualifications are attached to a person (object type P) in R/3 and are held by that person regardless of where they go within the organizational structure.
Requirements can be attached at the job code or position level and are generic to that object. For example, for a manager job code, you can input requirements such as supervisory or budget management experience. Placing those requirements on the job rather than on the position allows for less maintenance. If you have an accounting manager position, it would already be associated with all of the requirements from the job level. However, if the accounting manager position is located in a Spanish-speaking community and fluency in Spanish is required, you can place that requirement at the position level. The maintenance of requirements is not required for the deployment of succession planning, but it does provide you with more functionality than tracking qualifications alone. It is popular among those using the SP model for internal recruitment.
Identifying Collection Methods
You next need to determine how to collect the data. Companies that have some form of an SAP Employee Self-Service application have an advantage, as the data can be collected and fed directly into the system. Companies that do not have it must investigate other options. One company where I worked developed a custom Web page form on its company intranet (in basic HTML). Employees logged in via their personnel number and a password and then selected their (self-rated) qualifications via the form, which was loaded by an ABAP program. For qualifications that were determined by a supervisor, the supervisor logged into a similar intranet form and entered the supervisor-rated qualifications, which were also fed into R/3 via an ABAP program. At another company, we incorporated the qualifications questionnaire in hard copy sent to employees (who did not have computer access). We asked them to complete it, and then it was entered manually by HR staff.
Keeping the Data Current
Once the data is initially collected, you need to keep it up to date. During your initial data collection, it’s helpful to deploy a communication strategy to let employees know why you want to collect it. You may find that you get mixed reviews. Some employees may see it as a threat — a fear that it is HR’s opportunity to see that they do not have a college education or that they have no formal training and consequently are at risk of being terminated. Other employees will see it as an opportunity for advancement and a chance to brag about their achievements. Your announcement strategy has to keep both of these types of employees in mind. Ongoing reminders to employees in all HR communications are also key. Whichever data collection utility your company deploys, you need to provide regularly scheduled opportunities for employees to update their information.
Access to Your SP Data
Once the qualifications catalog is designed and the data collection and upkeep strategies are deployed, the payback is immediate. The storage of an employee’s qualifications can be displayed through the PA infotypes (Figure 1).

Figure 1
Display of qualifications
The user-friendly search method allows you to easily identify internal talent. One function called the SAP Profile Matchup (Figure 2) allows you to compare the qualifications and requirements of objects (employees [P], jobs [C], and positions [S]) against each other. You can compare an employee’s qualifications with the requirements of a potential position this employee is interested in to see if he or she meets the requirements and to determine how well-suited the employee is to the position.

Figure 2
Profile Matchup screen

Danielle Larocca
Danielle Larocca is currently the Senior Vice President of Human Capital Management for EPI-USE Labs. Previously she was the Executive Vice President of Operations/Chief Knowledge Officer at a technology start-up. She has more than 20 years of strategic leadership experience in multi-national business, business process re-engineering, and project and people management. Danielle is an expert on SAP Human Resources (HR) and reporting and has authored four best-selling books on SAP. She is a regular speaker at numerous conferences around the world on topics such as HR, technology, change management, and leadership. She is an official SAP Mentor, a global designation assigned to less than 160 professionals worldwide, who serve as influential community participants in the SAP ecosystem. This group is nominated by the community and selected by the SAP Mentors’ Advisory Board to keep SAP relevant. Danielle also serves as an expert advisor for SAP Professional Journal.
You may contact the author at me@daniellelarocca.com.
If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.