SAP Knowledge Base Article - Public

2085961 - Position-Based Planning - How to Setup, Permission and Use Position Based Planning - Succession

Symptom

  • The position model was introduced in 2007 to satisfy one fundamental requirement: nominating successors to positions, regardless of which employees occupy those positions. This can include TBH (to be hired) positions, not occupied by any employee.

Environment

  • Succession Management

Resolution

To achieve this, the following features were introduced:

  1. A new entity called a position, which includes a unique position code.
  2. A position hierarchy, similar to (but separate from) the employee hierarchy.
  3. Support for displaying that hierarchy with the new org chart.
  4. Permission controls for managing positions via the org chart.
  5. A third nomination method, for attaching succession plans to positions (rather than roles or incumbents).

These features also form the foundation for workforce modeling, which is planned for a future release.

Terminology

In this document and the product:

  • A role is a job description and a set of competencies/skills required for that job. It can be as broad or narrow as the instance administrators want it to be. Roles are grouped into families.
  • A position is a specific instance of a role that can be filled by an employee, or it can be vacant. For example, we might have a role called "Sales Director", and there might be 4 specific positions using that role (Sales Director West, Sales Director East, etc.).
  • A job code is used to match an employee or a vacant position to a role. Roles can have multiple job codes associated with them, but employees can only have one.
  • TBH means "to be hired" when discussing a position. Synonymous with vacant. Of the 4 positions described above, some could be filled and some could be TBH-but all will appear on the position-based succession org chart. (Only the filled positions will show on the regular org chart, however, since the system creates it using only data from active employee records.)

Creating the Position Model

Usage

Administrators have two options for creating the position model: generating it from employee data, or importing it from an external source.

 Capture.PNG a.PNG

It is strongly recommended that administrators pick one and only one of these methods for managing the position hierarchy. Combining imports with sync operations can result in duplicating position data and/or overwriting good data with bad.

Note that you must populate the position model with one of these two methods before using the position org chart; otherwise you will get an error.

Option 1: Generating the position model from employee data:

This option is intended for customers that do not already have a master source for position data.

Administrators with user management permissions should find this option in Admin Tools:

  Capture.PNG b.PNG

The Sync command screen looks like this…read the on-screen instructions carefully:

  Capture.PNG c.PNG 

The sync function can be used to "seed" the position hierarchy based on the employee data. You can run it once employee records are loaded and it will create a matching position for each employee.

The first option to select in the sync function is what to do with inactive incumbents: either mark their positions as TBH, or delete the positions. The sync process bases its changes on employee data, so this only changes positions that have inactive employees in them-not positions that are already marked as TBH. (To delete TBH positions, you must either go to the org chart to delete them manually, or use the import function with the "DELETE" command described below.)

There are 3 sync options for when employees report to new managers:

  1. The first option is conservative, erring on the side of creating new positions, which is the safest route-all position-based succession plans will be preserved. However, this can also result in unnecessary positions records that will have to be removed manually.
  2. The second option is aggressive: positions always follow employee changes, and new TBH positions are never created in the wake of an employee move. This means you will spend less time cleaning up unnecessary TBH positions. But, you will have to manually intervene when a position gets moved that should have been kept under the old workgroup.
  3. The third option is a hybrid approach which applies some additional logic. Here's a scenario which illustrates the behavior with this option:

1. Employee A reports to Employee B who reports to Employee C

2. Employee B moves to another team, now reporting to Employee D and Employee A is temporarily assigned to report to Employee C (via the employee import)

a. Sync process is run

i. Employee B gets a new position; his old position is now TBH (and retains the successors, if any)

ii. Employee A does not get a new position

3. When Employee B's old job is filled, Employee A slides back down to report to the "new" Employee B (via the employee import)

a. Sync process is run

i. Employee A does not get a new position

2. Employee A gets a big promotion, and is now at the same level as Employee C

a. Sync process is run

i. If Employee A had successors, Employee A gets a new position; her old position is now TBH (and retains the successors)

ii. If Employee A did not have successors, Employee A does not get a new position…the new Employee B now has no direct reports

It is unlikely that any set of rules will be right 100% of the time for a large & complex organization; there is always the possibility that after the general rule is applied and the sync process is run, a manager or HR planner will need to intervene and manually update the position hierarchy. See Reconciling the Position Model and Employee Data for information on manually updating the position hierarchy when there are changes to employee data.

Option 2: Importing position data:

This option is intended for customers already managing positions in their HRIS or other "master" system, or customers who have purchased succession planning licenses for a smaller population than the number of total employees they are loading.

Administrators with user management permissions should find these options in Admin Tools:

  Capture.PNG d.PNG

The import file is used for creating and updating the incumbents of position records, as well as attributes of vacant positions. The same format can be exported from a position model on demand. The order of the columns may vary; additional fields may be inserted in the future.

File format is CSV. Extended ASCII characters (curly quotes, etc.) are not supported. The same file encoding options supported in the Employee Import function (including Western (ISO), Unicode (UTF-8), and foreign-language encodings) are supported here. Enclose text values in double-quotes.

The position import file format is as follows:

 

Column header:

Sample value:

Column required?

May be blank?

Description:

MODEL

1

Required

No

In the future we may support importing multiple distinct position models. Today, this value must always be "1".

POSITIONCODE

salesrep123

Required

Yes

The position code is a unique identifier for the position record. It can be customer-supplied (alphanumeric) or auto-generated (numeric). Leaving this value blank will always create a new position, whereas if it supplied, the system will use it to check for an existing position first and then update it if found.

USERID

jsmith1

Required

Yes

The employee's user ID. The value in this file must match an existing active employee record (specifying a nonexistent or inactive userID will result in an error). If left blank, the current incumbent (if any) will be removed from the position, leaving the position marked as TBH.

MANAGERPOS

salesmgr32

Optional

No

The position code of the position that this position reports to. (Note that this is not a user ID; the employee's current manager could be different than the position they are projected to report to.) If a position has no manager, use the value NO_MANAGER. If updating existing positions this column is not required, but if the column is included, blank or invalid position codes will result in errors.

KEYPOSITION

0

Optional

Yes

Indicates whether the position is key, or a level of criticality. This can be set by a rating scale, so while the most common options are 1 (Yes) and 0 (No), any numeric value that corresponds to a criticality rating can be used. If column is not included, value for existing positions will not be changed. If column is included but value is blank, record will be set to 0.

JOBCODE

salesrep

Optional

Yes

The job code of a vacant (TBH) position. If the position is occupied, this will not change the current incumbent's jobcode--that must be changed via the employee import or updating functions. If left blank, the TBH position will not be connected to a role, which will limit the ability to create succession plans or job reqs for the position.

TITLE

Account Manager

Optional

Yes

The title of a vacant (TBH) position. If the position is occupied, this will not change the current incumbent's title--that must be changed via the employee import or updating functions. If left blank, the position will not have a visible title on the org chart.

DEPARTMENT

Sales

Optional

Yes

Fields that usually describe an employee may be included in additional columns: Department, Division, Location, Manager (specify a user ID), HR (specify a user ID), Matrix_Manager (specify a user ID), CustomManager (specify a user ID), and Custom01 through Custom15. Like jobcode and title, these fields can only update TBH positions: if the position is occupied by an active user, these values will be ignored. (The reason being that the employee import/management functions have all the necessary rules that govern employee data changes, while this import function does not.) Use the same header and value format as in the employee import file. These fields are typically used when the company is doing succession planning for vacant positions and the permissions structure requires that these fields be specified to determine which positions users can create succession plans for. If a TBH position has no manager, use NO_MANAGER (just as you would in the employee import file).

DIVISION

ACE Software

MANAGER

cgrant1

etc.

 

ACTION

DELETE

Optional

Yes

If you include the optional ACTION column in your import file, you can mark position records to be deleted on import. At this time "DELETE" or blank (null) are the only valid values; all other values are ignored and will generate a warning message. If you delete a position, the action cannot be undone-you will need to re-create the position if you want to restore it. Deleting a position has no effect on the incumbent employee (if any).

The same file format is used for both imports and exports.

If you import all your position data from an HRIS, you may want to disable position editing functions for succession planners. You can do this in the Admin > Org Chart Configuration > Position Dialog:

  Capture.PNG e.PNG 

 

The manager userID should be specified for TBH positions created via the import file to match the incumbent of the manager position, to ensure that planning & visibility permissions are correctly applied. [c2]

Technical Details:

In the import file format above, only the first 5 fields-Model, PositionCode, userID, ManagerPos, and KeyPosition-are stored in the SuccessFactors position record. All other fields are held in user records (including TBH positions, which get an invisible "vacant" user record). So:

  • If you enter these values for a TBH position and then fill the position with an employee, the original "vacant" employee record is removed and the position now assumes the title, department, division, etc. of the new incumbent.
  • Conversely, if you remove an incumbent from a position, the system will create a new vacant employee record, copying the title and the fields relevant for permissioning (department, division, matrix & custom managers, etc.) from the prior incumbent.

These "vacant" employee records are managed behind the scenes, unbeknownst to the user. With this mechanism, the position and employee records are never in conflict, since the position takes on the qualities of the incumbent.

Position Import Error Codes:

-5

Invalid Manager ID

-7

Invalid UserID

-10

Manager Cycle Detected

-15

Invalid Matrix Manager ID *

-17

Invalid Custom Manager ID *

-18

Invalid Second Manager ID *

-19

Second Manager Cycle Detected *

* These error codes will only appear for TBH positions (since the relevant fields for incumbents are not updated via the position import, even if you include the values in the import file).

Viewing & Manipulating Positions through the Org Chart

Configuration

  • You must define a view-template called "positionOrgChart" in the live profile data model that lists the fields that can be edited for positions (whether filled or vacant). Here's an example:

<view-template id="positionOrgChart"visibility="none" pdf-printing-enabled="false">

<label>Position Org Chart</label>

<description>This view template is for position edits in the position Org Chart</description>

<edit-template id="editPosition">

<label>Edit Position</label>

<description>Edit Position</description>

<standard-element-ref refid="jobCode"/>

<standard-element-ref refid="department"/>

<standard-element-ref refid="division"/>

<standard-element-ref refid="location"/>

<standard-element-ref refid="custom03"/>

</edit-template>

</view-template>

The view-template can only include standard-element fields defined in the data model. However, in general, it should only include fields that would remain unchanged regardless of what individual fills the position; attributes like hire date, gender, risk of loss, etc. would not be appropriate.

The view-template should typically include the fields used to limit Succession Planning Permission. These can include Department, Division, Location, manager, matrix manager, HR manager, custom manager, and the custom succession reporting fields. Jobcode is strongly recommended since it is the link to the role definition, required for nomination forms.

The position code, manager position, incumbent, and key position (yes/no) are part of the position record, and should not be included in the view-template-they always appear in the position edit dialog. Position Code is a unique value that can be supplied by the customer. (If it is not supplied, the system will fill it with a unique ID number.)

Title also should not be included in the view-template; it will always be included automatically. It will still respect the title field write permissions in the data model.

 

Key Position Setup:

The administrator can configure whether or not the "key position" indicator is used for position records. Look for this link in Admin Tools:

  Capture.PNG f.PNG 

The Position Setup screen looks like this:

  Capture.PNG g.PNG 

 

On this screen the administrator can choose whether to use a simple Boolean (yes/no) "key position" option, or a rating scale for "criticality" that can have 3 or more levels. The default is "No" - do not use key/critical position indicator.

Note: if the key position indicator is used, all users with succession org chart access will be able to see which positions are marked as "key".

This administrative setup should be synchronized with the org chart configuration setup so that succession org chart users have the option to highlight key positions. A new section should be added immediately before the <SMFormId> tag:

Boolean (yes/no) key position configuration example:

</gradientOption>

<keyPositionOption indicator="boolean" key="">

<label>Highlight key positions</label>

<keypositionset></keypositionset>

</keyPositionOption>

<SMFormId>4</SMFormId>

Criticality with rating scale configuration example:

</gradientOption>

<keyPositionOption indicator="scale" key="Criticality">

<label>Highlight critical positions</label>

<keypositionset>

<keyposition>

<label>All positions</label>

<value>0</value>

<index>0</index>

</keyposition>

<keyposition>

<label>Moderately critical & up</label>

<value>1</value>

<index>1</index>

</keyposition>

<keyposition>

<label>Highly critical positions</label>

<value>2</value>

<index>2</index>

</keyposition>

</keypositionset>

</keyPositionOption>

<SMFormId>4</SMFormId>

The possible values for the "indicator" attribute are "no", "boolean" and "scale" (all in lowercase). Note that these correspond to the 3 options (in order) in the admin Position Setup page.

If indicator is "scale", the "key" value should be the rating scale name. The "key" attribute is required but the value is ignored when using the Boolean option.

The "value" tag in the <keyposition> group corresponds to the rating scale value of criticality. A zero-based scale is recommended, to match the key position values that would be imported in the position import file (0 is not key, 1 and up are varying levels of criticality). For example, this rating scale would support the org chart XML configuration above:

0.0 Non-critical position
1.0 Moderately critical position
2.0 Highly critical position

Usage

To view the position-based org chart, look for the Succession org chart link. In v10, it is in the Succession nav bar to the left of live profile; in Ultra and Revolution, it is under the Succession tab.

The following rules govern who can use the position org chart & manipulate positions on it:

Permission

How to grant it

View position hierarchy (includes key position indicator)

Organization Report Permission (on/off; does not limit scope)

Add/Edit/Delete positions (position code, pos. manager, incumbent, key position)
& TBH attributes (Dept/Div/Loc, or other fields defined in the view-template)

Administrative Privileges > Manage Users > Change User Information (on/off; does not limit scope)

OR Succession Planning Permission (limits scope to defined population), if enabled by the administrator in the Position Setup screen

(either qualifies)

Edit user info (Dept/Div/Loc, or other fields defined in the view-template)

Administrative Privileges > Manage Users > Change User Information (on/off; does not limit scope)

OR Data Model permissions

(either qualifies)

View succession data (Succession fields in data model, successors)

Succession Management and Matrix Report Permissions (limits scope to defined population)

Note: the new org chart respects data model permissions for self only. This enables managers to see their own successors without seeing their own potential, risk of loss, etc. However, if you grant Succession Management and Matrix Report permission to "self", that person will also be able to see their own placement on the 9-box reports.

Nominate successors

Succession Planning Permission (limits scope to defined population)

To add a position, pull down the menu on a node in the position org chart to "Add Direct Report" or "Add Peer". The new position record will be "seeded" with the demographic data (department, division, etc.) from the node that you start the add process from (either the manager or the peer).

To edit a position, pull down the menu to "Edit Position".

Note that it may be possible, if you do not have admin privileges for changing user information, to add or edit a position and remove your own ability to edit it subsequently. For example, you can create a new TBH position and fill out all the values (department, division, etc.), but if you then change the incumbent to be an existing user that you do not have data model permission to change, those fields will not be updated and will be read-only when you reopen the edit window.

Highlighting key positions:

If the key position options have been enabled, users can select display options that highlight key positions-or, more accurately, "dim out" non-key positions, so they can focus on planning just for the more important positions. The Boolean (yes/no) key position indicator looks like this:

  Capture.PNG h.PNG 

 

Creating Position-Based Succession Plans

Configuration

Permissions are controlled for position nominations much the same way as they are for person-based nominations. This means you (or the administrator) must set permissions for succession planners using these admin tools:

   Capture.PNG i.PNG 

 

 

 

 

 

The Succession Planning permission determines who you can create succession plans for, while the Succession Management and Matrix Report permission determines which employees you can see detailed succession & performance data about. See the Succession configuration guide for complete information on using these permissions.

Usage

Users can create succession nomination forms the same way they do for role-person based nominations: either pull down the org chart menu to "Find successors…", or use the Create Form function under the My Forms tab and pick a role. The user will be prompted to pick a position on the same screen where they would in the past be picking a person (the screen lists positions with their Position Code, Title, and Incumbent, if any).

You can create succession plans for TBH positions, just like those that are filled. You can also click the QuickCard icon on TBH positions to see information about the role (connected via the jobcode), such as the job description and the required competencies. If you have the Recruiting module enabled, you can initiate a job requisition for a position from the org chart menu as well.

The nomination process is set up and conforms to the rules described in the Nomination Configuration Guide. Position-based planning supports both form-based nominations and the "Instant Nomination" option.

Position-based succession plans are stored with an internal Position ID which cannot be recovered if the position is deleted. So, be careful not to delete positions that have valid succession plans.

Reconciling the Position Model and Employee Data

Configuration

The position audit report is a spreadsheet report that must be activated in provisioning, like the other spreadsheet reports. (Download the RDF file from CVS or contact the TSE team if you need the template loaded for your instance). Users must also be granted access to the spreadsheet report.

Usage

Administrators can run a Position Audit Spreadsheet Report to analyze data in the position model that does not match that in the employee data.

The position audit report includes these worksheets:

 

Vacant Positions

Which positions are still vacant? Are these legitimate vacancies or should the position be removed from the position hierarchy?

Orphaned Positions

Are there any positions defined that not connected in the hierarchy?

Employees with No Position

Who are the employees that are not associated with any position in the hierarchy?

Employees in Multiple Positions

Are there any employees occupying more than one position? Which positions do they occupy and who is the position manager?

To edit position incumbents one at a time, users can open the position org chart and use the "Edit Position" command. The user must have the position edit permissions described under Manipulating Positions, above. When editing the position, users can select "Filled" and enter an incumbent by name; the auto complete function will help the user find the appropriate active employee to place in the position.

 

 

 

 

 

 

To update the entire position model based on current employee data, administrators can re-run the "Sync Position Model…" command in Admin Tools. When re-running the sync command, the administrator should pay close attention to the available options for dealing with inactivated and moved incumbents.

 

Note that by default, vacated positions will remain on the position model and will be marked as TBH (the administrator intends to fill this position with another employee). However if you select the "Deleted" option for inactive incumbents, those positions will be deleted from the position model. If you delete these positions, the action cannot be undone-you will need to re-create those positions manually (or they will be re-created on the next Sync operation when a new employee fills the position).

As mentioned above, the sync command is not recommended for customers managing their position data via the position import file.

Attachment:

How_to-use_position_model_for_customers.doc

 

Tags

BizX Performance Management

BizX Succession Management

BizX: Performance Management

BizX: Succession Management

Keywords

KBA , sf succession , LOD-SF-SCM , Succession Management , How To

Product

SAP SuccessFactors HCM Core all versions

Attachments

How_to-use_position_model_for_customers.doc