SAP Succession and Development Tutorial (Part 1)

Succession and Development (often called Succession Planning, part of the SuccessFactors Talent Management suite) exists to answer a critical business question: if a key employee leaves tomorrow, who is ready to step in, and who needs development to get there? Without a structured tool, organizations rely on spreadsheets and tribal knowledge, which do not scale and are not auditable for governance, risk, or board reporting purposes.

At its core, the module revolves around a small number of interlocking objects. The Succession Org Chart is the primary visual interface, showing positions or incumbents in a hierarchy, similar to the standard org chart but overlaid with talent risk indicators such as flight risk, impact of loss, and readiness. A Talent Pool is a curated group of employees who are potential successors for a role, job family, or leadership level; pools are useful when planning is not tied to one specific position but to a category of critical talent (for example, 'Future Finance Directors'). Nominations link a candidate (a person) to a target (a position, an incumbent's role, or a pool) with a readiness rating, such as Ready Now, Ready in 1-2 Years, or Ready in 3-5 Years. The Nine-Box (or similar) matrix plots performance against potential, pulling ratings typically sourced from Performance Management forms and Calibration sessions, giving a visual talent segmentation used in succession review meetings.

A foundational design decision is whether succession planning is Position-based or Person (Incumbent)-based. Position-based planning ties succession data to a specific position number synchronized from the position org structure (relevant when Position Management is enabled in Employee Central), which is well suited to organizations with strict headcount and position control. Incumbent-based planning ties succession data to the person currently holding a role without requiring a formal position hierarchy, which suits organizations that manage structure more loosely through job/reporting relationships. This decision affects almost every downstream configuration choice, including how the org chart is built and how nominations resolve when someone changes jobs.

Data flows into Succession primarily from Employee Central (job information, organizational structure, employee profile fields) and from Performance & Goals (overall performance ratings feeding the matrix) and can also incorporate custom fields captured directly in the Succession module, such as risk of loss or impact of loss, which are typically maintained by HR business partners or managers during planning cycles.

For a beginner consultant, it is essential to understand that Succession and Development is a planning and visibility tool, not a payroll or organizational change system: nominating someone as a successor does not move them into a job; a separate recruiting, internal mobility, or job change process in Employee Central actually executes that transition. Confusing planning data with transactional data is one of the most common early misunderges in this module.

A mid-size manufacturing company implementing Employee Central also purchases the Succession add-on to prepare for retirements among plant managers. The project team must decide between position-based and incumbent-based planning before building the org chart, because the client has inconsistent position management practices across regions. The consultant runs discovery workshops, confirms that only the corporate region uses strict position control, and recommends incumbent-based planning company-wide for simplicity, deferring position-based succession to a later phase for corporate leadership roles only.

• Treating a succession nomination as if it automatically changes the employee's job or reports-to relationship, when it is only a planning record.
• Choosing position-based planning without confirming that Position Management is properly maintained in Employee Central, leading to broken or incomplete org charts.
• Failing to clarify with the client whether talent pools or the org chart (or both) will be the primary planning interface, causing rework later.
• Assuming performance ratings will automatically populate the nine-box matrix without checking that Performance Management route maps and rating scales are correctly aligned to Succession.

• Confirm the position-based vs incumbent-based decision early, since it drives configuration of the org chart, matrix, and permissions.
• Align on data sources for ratings (Performance Management vs manually entered) before building the nine-box matrix.
• Use talent pools for job families and cross-position bench strength, and position-based nominations for named critical roles.
• Document clearly for HR users that succession nominations are planning data, not transactional job changes.

Interviewers often ask candidates to explain the difference between position-based and incumbent-based succession planning and to justify which one fits a given organizational structure; a strong answer ties the decision back to how Position Management is used in Employee Central and the implications for org chart stability during reorganizations.