In my previous SuccessFactors Employee Central blogs, I had discussed the Organization Structure and Pay Structure. The third element to managing the enterprise is the Position object and the Position Management feature. In this blog, I will provide an overview of the Position object and how it works in Employee Central, as well as cover the Position Management feature and how it impacts organizational management. In addition, we will look at some of the standard reporting options and integration points.
SAP provide a very detailed Position Management handbook on SAP Service Marketplace (S-user required) that I recommend reading if you want to learn the full details of Position Management, since it contains the wealth of information on the Position object, using and configuring Position Management, and the system behavior for the various scenarios of Position Management. Since this information is readily accessible to SAP customers I will not repeat any of the details provided in the handbook. In addition, I will not be covering Metadata Framework-specific features such as permissions or creating scenario-based workflows.
A quick note about hyperlinks in this blog
Please note that throughout this blog there are many references to handbooks and implementation guides on SAP Service Marketplace. Since SAP are regularly updating and modifying handbooks and implementation guides to include the latest features and releases then over the course of the lifetime of this blog some links may change. Wherever I have referenced a handbook or implementation guide I have also included a link to its parent folder with the text “SAP Service Marketplace”, which should change less frequency. Please let me know if you find any broken links! Now let’s take a look at the Position object.
Position object
The Position object is a Generic Object, meaning that it is built and configured in the Metadata Framework. This brings many benefits, such as:
- Easy configuration of the Position object fields
- Creation of rules to meet a variety of scenarios
- Scenario-based workflow
- Rule-based data propagation
- Auto-creation of Position Code
- Showing pending workflow data or not
- Associations with other objects
- Robust, granular, and structural-based security options
Various functions are provided in the Rules Engine so that rules can be built to query Positions and their incumbents, such as Get Incumbent by Position, Get Next Available Manager By Position and Get Number Of Child Positions. The Rules Engine can also be used to create rules to trigger different workflows based on different scenarios, such as approving changes to positions that have or are above a certain level of grade or approving a change in To Be Hired status.
A standard Position object definition is provided, which a customer can adapt to their own needs using the standard Metadata Framework functionality. This object definition can be seen in the screenshot below:
Positions are assigned to an employee in Job Information, above the Organization Structure section. If configured, the Position Entry Date and Time in Position fields are also displayed. The screenshot below shows a Position assigned to an employee:
Positions can have a parent Position, so that a tree structure can be created and visualized in the Position Org Chart. This is known as the Position Hierarchy. The Position Hierarchy in the Position Org Chart can be seen below:
Position Management
Position Management provides standard and configurable behavior in the system to manage positions across the enterprise. While a customer does not need to use Position Management in order to use the Position object, it does provide many features and benefits.
Let’s take a look at some of the key features provided in Position Management and then at some of the general configuration settings.
Shared Positions
Employee Central supports sharing of positions by one or more employees. This must be set for each shared position individually by setting the Multiple Incumbents allowed field value to Yes.
Capacity Control
Capacity Control enables the FTE of the incumbent(s) of a position to not exceed the FTE value defined for the Position. This feature is particularly useful for retaining stable headcounts and for budgeting.
The system checks the FTE value of the incumbent(s) against the FTE value of the Position in the following scenarios:
- During the New Hire transaction
- A new Position is assigned to an employee or the FTE of an employee is changed
- The FTE value of the Position of an employee is changed
- Either the Position or the employee’s FTE value is changed on an historical Job Information record
- During a Position transfer or Position reclassification takes places and the system searches for a suitable position
This must be set for each position by setting the Capacity controlled field value to Yes and defining a value for the Target Capacity (FTE) field.
Matrix Relationships
An employee’s Job Relationships can be inherited from a Position when the Position is assigned to the employee. On the Position these are called Matrix Relationships. The holder of each Position defined under the Matrix Relationships section of a Position will be synchronized to an employee’s Job Relationships.
This enables Position-based Job Relationships to be maintained on Positions rather than individually for each employee and thus enables consistency across the enterprise. It also enables additional permissioning for incumbents of Positions that are defined as Matrix Relationships of another Positions.
Position Types
The Type field can be used to identify different types of positions, for which standard system behavior can be modified. The system comes with two standard Position Types (Regular and Shared Position), but custom Position Types can be created in the Manage Data UI.
This feature is particularly useful if certain types or groups of positions require different types of changes to other types or groups of positions. For example, shared positions may require different types of manager re-assignment if the manager leaves the parent position, since the two incumbents may have different managers or matrix managers.
There are three types of system behavior that can be modified for each Position Type:
- Trigger a workflow for changes to an employee’s Job Information that change a Position and if those Position changes need to be synchronized to one or more incumbents
- When a manager leaves their position, determine to which employee the direct reports of the manager should report to
- If the Position Hierarchy is changed, specify how the reporting line should change
In addition, rules can be setup so that they respect the Position Type and could therefore drive different behavior in data synchronization, workflow triggering, etc.
The screenshot below shows the settings for a Position Type:
Right to Return
On the Position, it can be determined whether an employee who goes on a Global Assignment or a Leave of Absence has the right to return to that Position. This feature can only be used if Time Off and/or Global Assignments are used in the system. The feature is based on two rules that are used to determine:
- If the incumbent remains in their Position while on Global Assignment/Leave of Absence
- If the incumbent can return to their Position when the Global Assignment/Leave of Absence ends
Right to Return is also visualized on the Position Org Chart.
Position Transfer or Position Reclassification
When a Position Transfer or Position Reclassification takes place, information maintained on the Job Information for an employee will be synchronized to the Position object assigned to the employee. The fields that are synchronized are defined by a rule that can be assigned in Position Management Settings in the field Rule for Synchronizing Position after Job Information Change.
In most cases the system determines a Position Transfer as a change of manager for an employee, although in the case of a promotion an employee would move to a new position without a change to the existing position. The system determines a Position Reclassification as changes to an employee’s Job Information by a manager. These are technically defined on the relevant Event Reason Foundation Objects by setting the value of the Follow-Up Activity on Position field to either Position Reclassification or Position Transfer.
When a Position Transfer takes place, the system searches for a position under the employee’s manager’s Position that has the To be hired field value set to Yes and assigns the employee to this Position. If no Position is found then a new Position is created and the employee is assigned to it. The Position’s FTE value will be taken from the employee’s FTE field. The To be hired field value of the “old” Position remains as No and the To be hired field value of the “new” Position is set to Yes. In addition, direct reports of the employee are transferred to the employee’s “old” manager.
When a Position Reclassification takes place, the system changes the Position of the employee as per the rule assigned in Position Management Settings. In the case of a shared position the system will perform a position transfer instead.
The system can be changed so that it does not search for a new Position. This is done by setting the Search for Position in Position Transfer field value to No in Position Management Settings.
Data Propagation and Synchronization
Although Employee Central supports propagation of data to or from the Position object, Position Management can define specific data propagation rules for certain Position Management scenarios so that objects and employee data can be kept synchronized when changes are made. There are three scenarios where data propagation is used:
- Propagating Job Classification data to a Position when a Job Classification is assigned to or changed for a Position
- Propagating Position data to an employee’s Job Information when a Position is assigned or the employee’s assigned Position is changed
- Propagating Job Information to a Position in the chase of a Position Transfer or Position Reclassification
Rules are used to determine which fields are to be propagated and these rules are assigned in the Position Management settings. For propagation of Job Classification data to Position many of my clients typically propagate data such as Job Title, Job Level, Employee Class, organizational data (i.e. Company and Department), and FTE.
Future-dated propagation (called Forward Propagation) is a standard feature of the system and is typically used for Right to Return.
Configuration Settings
There are various configuration settings in the system that determine the overall behavior of the system and thus how Position Management works. Some of these are related to the features that were discussed above. These configuration settings are accessed in OneAdmin in Employee Files > Position Management Settings. The user interface of Position Management Settings is split into 5 tabs:
- General
- Hierarchy Adaptation
- Synchronization
- UI Customizing
- Right To Return
The General tab is where the following types of features are configured:
- Whether Position Types are used
- How the To Be Hired field should behave during assignment and unassignment of an employee to a Position
- How an employee’s Position assignment should be validated (for multiple incumbents and capacity control) when employee data is imported via a Job Information import
- If the Position code should be automatically generated
The General tab can be seen in the screenshots below:
The Hierarchy Adaptation tab defines which hierarchy – Position Hierarchy, Reporting Hierarchy, or neither – the system leads with. This means that the other hierarchy is adapter based on changes to that hierarchy. For example, John Smith moves to a vacant Position that has 3 direct reports and so the manager of the new employees will change to John Smith. Also in this tab, the behavior of the hierarchies during a Position Import and Job Information import can be defined.
The Synchronization tab determines the behavior of the system when synchronizing data from a Position to an employee’s Job Information, and vice-versa. This includes the rules for defining fields used in synchronization of Position to an employee’s Job Information and vice-versa, as well as whether a Position is searched for a reclassification or transfer of a Position and which area of the organization should be used for retaining a stable headcount.
The UI Customizing tab defines:
- The rule used to specify which fields of a Position that are copied to a new Position when one is created in the Position Org Chart
- In MSS, whether the list of Positions should be filtered by Company
- Whether to display the Positions Under Employee field in the New Hire screen, Job Information screen in MSS, and in the History screen
The Right To Return tab determines the rules and event reasons that defines the behavior of the Right to Return feature.
Position Profiles in Job Profile Builder
Job Profile Builder enables Job Profiles to be created for Position objects and not just Roles. These can then be used in creating requisitions or in skills management. It makes a lot of sense to have Job Profiles for Position objects, since many organizations will have some positions have specific competencies, skills, or other requirements that are unique to that instance of a position. Regional or country-specific positions are a great example of where local skills or qualifications can be needed for what is otherwise the same position across each region or country.
The screenshot below shows all of the Position objects assigned to the Maintenance Manager Role:
The screenshot below shows skills mapped to a Position object:
The screenshot below shows a Job Profile for a Position object:
Reporting
SuccessFactors offers two types of reporting for Employee Central that can be used to report on Positions:
- Detailed Reporting
- Employee Central Advanced Reporting
Detailed Reporting provides reporting capabilities for Metadata Framework objects, which of course includes the Position object. Through this reporting type users can build reports using any array of fields on a Position. In addition, the calculation capabilities with Detailed Reporting can be used to perform functions such as data aggregation or if/then/else statements.
Employee Central Advanced Reporting provides over 70 out-of-the-box reports that customers can use or re-use as templates for their own reports. It is technically a sub-component of Detailed Reporting. Three exist that can be used for Position Management reporting purposes:
- Position Overview
- Position Details
- Disparities between Reporting Line and Position Hierarchy
The Position Overview report provides a list of all positions in the company with the pre-defined position fields, such as Name, Code, Status, Start Date, End Date, Job Code, Job Level, Employee Class, Company, Business Unit, Department, etc. A screenshot of this report can be seen below:
The Position Details report is a more detailed version of the Position Overview report, and thus provides a more detailed overview of all positions in the company. It displays all fields shown in the Position Overview, along with details of the incumbent like First Name, Last Name, Person ID, Employment Status, FTE, etc. A screenshot of this report can be seen below:
The Disparities between Reporting Line and Position Hierarchy report identifies any differences between the reporting line (the reporting Manager whom an employee reports to) and the position hierarchy (a position-to-position reporting structure). It lists all positions with the incumbent, the incumbent’s manager, the incumbent’s manager’s position and the parent position of the incumbent’s position. Any differences between the incumbent’s manager’s position and the incumbent’s position’s parent position are highlighted in the Discrepancy column with a description of the discrepancy in the Comment column.
In addition, Positions can be shown in reports made on employee data in Ad-Hoc Reporting. The Job Information (Date Range) domain enables reports to be created using data from Job Information (e.g. Position or Position Entry Date fields) as well as all fields of the Position object that an employee is assigned to. However, Ad-hoc Reporting is not the optimal solution for reporting on Position object data and it is not recommended to use it for Position reporting.
Integrations
The Position object is integrated with both Recruiting Management and Succession Planning. Additionally, the SuccessFactors OData API enables Position object data to be integrated with other systems.
Recruiting Management
Naturally there is integration with Recruiting Management, as one might expect. Requisitions can be created (for both current date and for a future date) from Position objects in the Position Org Chart, with an assigned requisition visible on the Position in the Position Org Chart (both for current and future-dated requisitions) and navigation to the requisition is possible. A candidate can be automatically assigned to the Position in the requisition in the “Pending Hires” transaction in Employee Central.
The Rules Engine offers two functions: the ability to derive a requisition template to be used for the Position object and the ability to define field mapping between the Position object and the new requisition.
The flow diagram below – taken from the Position Management handbook – shows the flow of the Recruiting Management integration.
Succession Planning
For Position-based succession planning, Succession can leverage the Position object from MDF and share the same Position Org Chart that is seen in Company Info. This changes the way that various succession planning processes key off the Job Code; when not leveraging the MDF position object then the position incumbent’s job code drives succession planning processes while with the MDF position object the position’s job code drives succession planning processes.
Job Profile Builder
As mentioned above, Position objects are integrated into Job Profile Builder to enable Job Profiles to be created specifically for positions.
Integration with external systems
The SuccessFactors OData API enables query, insert, update, and upsert of Generic Object data, including Position object data. Data is not deleted, rather it would be date-delimited. This enables Position data to be integrated with any system, so long as the system or middleware supports the OData protocol.
Exposure of a Generic Object via the OData API can be controlled on the Generic Objects object definition by setting the appropriate value (Editable, Read Only or Not Visible) of the API Visibility field.
How does this all compare to SAP ERP HCM?
In SAP ERP HCM the position is a mandatory object that – like in Employee Central – can be independent of a Job. However, Position Management in Employee Central adds a significant wealth of functionality that I have not yet seen used significantly in SAP ERP HCM. Features such as position control, position types, position transfers and reclassifications, and matrix relationships add significant value to the system. The Position object is also much more flexible than in SAP ERP HCM, so customers can define fields and rules for the Position object, as well as configure settings and create rules to define how the system behaves in certain employee lifecycle scenarios.
SAP ERP HCM customers should find that Position Management is much more robust in Employee Central than they might be used to in SAP ERP HCM and therefore have much more control of how the system behaves in relation to how Positions are managed within their organization. This would certainly be a benefit to most of the SAP ERP HCM customers I have come across in my career.
Roadmap
SAP are committed to continued enhancements for Position Management. In the b1508 release they are planning to introduce mass changes functionality for positions and incumbents (focused on organizational entities that need to be applied in positions and job information) and adding Pay Ranges and related attributes to the Position object definition. The image below shows some of the public roadmap items that have recently been delivered and are planned over the next 6 and 6-12 months.
I also understand that SAP are considering to build a more robust position budgeting module that is likely to be called “Operational Workforce Planning”, although this is not a commitment by SAP and the usual disclaimer applies that this may never be released and that you should always make plans based on existing functionality only.
