SuccessFactors Employee Central uses a simple but effective way to manage the enterprise, which differs somewhat to how SAP ERP HCM manages the enterprise. In this blog, we will discuss the organization structure as well as part of the job structure. Please note that the standard-delivered configuration of Employee Central will be discussed, although we will touch on the extensibility options to enhance this.
The organization structure in SuccessFactors has a different approach than SAP. In addition to having a more granular and configurable structure, it also incorporates the Company/Legal Entity into this structure. In SAP, the Company Code is part of the Enterprise Structure and is assigned directly to employees in infotype 0001. There are concepts of Employee Group, Pay Structure, Pay Scale Structure, and Cost Center hierarchy in Employee Central, but no concept of a Personnel Structure. We’ll explore pay structures in a later blog. The Employee Central system is extremely flexible in allowing the standard configuration to be modified as such to allow a customer to create an organization structure exactly as they require. This could be hiding or changing existing objects or adding new objects. Personally I believe that the organization structure in Employee Central makes more sense to business users and I will expand on this further as we continue.
A little terminology
Before we start, it’s worth going through a little Employee Central terminology:
Employee Central term Description SAP ERP HCM equivalent
Foundation Objects The primary objects and data that is used in employee records (e.g. Company, Job Classification, Pay Grade, etc.) Object Type / Master Data / Transparent table
Assocations Relationships between objects Relationship
Generic Objects Custom objects crated with the Metadata Framework Object Type
Organization Structure The organization structure used to manage the enterprise Organization Structure
Propagation Auto-population of field values on an employee’s Employment Information from Foundation Objects Default values set by Features in PE03
In the standard-delivered configuration the organization structure is composed of the following Foundation Objects:
Additionally, these objects can either be removed if not required or re-purposed in the struc
ture (e.g. change a Department to a sub-Division). New objects can also be added within the structure using the Metadata Framework. The diagram below illustrates the “top” 4 objects in the structure, with the standard-delivered Associations between objects:
A Legal Entity cannot have a parent of the same type. A Division can belong to multiple Business Units and a Department can belong to multiple Divisions. In addition, both a Division and Department can have a parent of the same type, thus creating a hierarchy of these object types.
We can compare the objects in this structure to SAP object types or fields:
Foundation Object SAP ERP HCM equivalent
Legal Entity Company Code
Business Unit Business Area / Organizational Unit (Object type O)
Division Organizational Unit (Object type O)
Department Organizational Unit (Object type O)
Location Personnel Area / Personnel Subarea
Cost Center Cost Center (Object type K)
The Organization Structure Objects
During the implementation of Employee Central, each Foundation Object can be configured to store certain details about the object. This can be used for reference or can be used to populate values into fields on an employee’s Employment Information record (called propagation in Employee Central terminology). Of course, many of these objects can be re-purposed as required and new objects can be added.
The Legal Entity object – sometimes referred to as Company – contains the definitions for all legal entities that are part of the customer’s enterprise. Every employee must have a Legal Entity assigned when being hired or setup in the system (just as they would in real life!). By default, a Legal Entity defines the country and default Pay Group, Location, currency, and standard hours for employees within that company. Country-specific information can be stored on a Legal Entity object. In SAP ERP HCM, the Legal Entity is the Company Code that is selected on the infotype 0001 screen during the hiring action.
The screenshot below shows the object record for the ACE USA Legal Entity.
The field below the Country field is country-specific fields for the country United States. These fields differ by country. Other data from this page can be propagated to the employee’s Job Information or Compensation Information, such as the Default Pay Group or Default Location field values.
A Business Unit represents a segment of a Legal Entity that focuses on a specific business function, such as manufacturing, sales, or marketing. There is no direct equivalent object in SAP, although a Business Unit could be represented by the Business Area in PA or by an Organizational Unit object in OM.
A Division is simply a division of a Business Unit. However, it can be used directly as a Division of a Legal Entity if required, such is the flexibility of Employee Central. There is no direct equivalent object in SAP, although a Division could be represented by an Organizational Unit object.
Divisions are broken down into one or more Departments. This is more typically represents an Organizational Unit object in SAP and is often the lowest denominator of the organization structure.
The Location, as the name suggests, represents a physical location. It is used to identify the employee’s location. By default, the Location defines the time zone and standard weekly hours of the employee. Locations can be grouped by Location Groups for further organization and reporting. In SAP, the location is often the Personnel Subarea.
A Cost Center represents the units that account for business costs, just as in SAP ERP and other HRIS’. Although it is part of the organization structure, it is more of a designation for the costs of an employee than part of the organization in which they reside. However, some organizations do use Cost Center as part of the organization structure. Cost Centers can have parent Cost Centers so that a hierarchy can be created.
Generic Objects can be created in the Metadata Framework and associated to Foundation Objects so that additional layers can be introduced to the organization structure. Generic Objects are created with the Metadata Framework. Extensive details on creating Generic Objects can be found in the Metadata Framework Implementation Handbook on SAP Service Marketplace (S-user required) and in this SAPexperts article Creating Metadata Framework Objects in SuccessFactors Employee Central (subscription required).
Associations between Foundation Objects (including Generic Objects)
Associations are relationships between objects that define the hierarchical relationship and filters for these objects. In essence, they define the parent-child relationship and whether a child relationship must exist for a parent object. In addition, they are used to filter object lists. An Association must have a multiplicity defined, which is either One-to-One or One-to-Many:
One-to-One: Defines that the object can only be associated to one other object
One-to-Many: Defines that the object can be associated to multiple objects
In the diagram above we can see several associations. Departments are associated to Divisions, while Divisions are associated to Business Units, and Business Units are associated to Legal Entities. Business Units, Divisions, and Departments can have parents of the same type.
A manufacturing Company has 3 Business Units called “Plastics”, “Woods”, and “Metals”. The “Plastics” Business Unit has 3 Divisions associated to it, called “R&D”, “Manufacturing”, and “Distribution”, while the “Metals” Business Unit has 2 Divisions associated to it, called “Metalworks” and “Alloys”, and the “Woods” Business Unit has 2 Division associated to it called “Carpentry” and “Timber”. This is demonstrated below.
An administrator is hiring a new employee. On the Job Information screen of the New Hire process an administrator selects the Legal Entity and then the “Plastics” Business Unit. In the Divisions drop-down the administrator will only see the values “R&D”, “Manufacturing”, and “Distribution”. Likewise, if they select the “Metals” Business Unit then in the Divisions drop-down they will only see “Metalworks” and “Alloys” and if they select the “Woods” Business Unit then in the Divisions drop-down they will only see “Carpentry” and “Timber”.
How does this look in EC?
Details of an employee’s organizational assignment is defined when the employee is hired. This information can of course be changed as required. The Job Information portlet found on the Employment Information page of an employee shows details of the position assignment, organizational assignment, and job information. The screenshot below shows the position assignment and organizational assignment for an employee can be seen below.
Here we can see the different elements of the organization structure that we have discussed. In the screenshot below we can see a demonstration of the associations example that we discussed above.
A Job Classification object (also a Foundation Object) contains details of an employee’s job role. Like in SAP, many employees can be assigned the same Job Classification (although in SAP this is through the Position object). It defines a large number of attributes about the job that an employee will hold, such as weekly hours, employee class, pay grade, and whether the employee is full or part time. In the standard-delivered configuration Job Classifications are associated to Business Unit objects. Country-specific information can be stored on a Job Classification object.
When a Job Classification is assigned to an employee a number of values from the Job Classification Foundation Object can be propagated. This is often common fields like Job Title, Pay Grade, Standard Weekly Hours, etc. The screenshot below shows the Job Information of an employee in the Job Information portlet. This information appears below the Organization Information seen in the above screenshot.
What about Positions?
Employee Central – as well as SuccessFactors – leverages the Job Classification as the standard “job role” of an employee. However, it does also support full Position Management if required. In SAP HCM, the Position object is mandatory for every employee, while use of the Job varies from organization to organization. In Employee Central Positions are not linked to the Organization Structure, which provides customers a choice of whether or not to use Position Management. Positions can have parent positions and thus a Position-based org chart is available in SuccessFactors. Positions are Generic Objects and are managed through the Metadata Framework.
How does this all compare to SAP ERP HCM?
I believe that the flexibility of the Employee Central organization structure enables organizations to more accurately setup a structure that truly reflects how they are organized. Although this is possible in SAP ERP HCM, it cannot be done with the level of granularity and accuracy that is possible in Employee Central. It is a simple yet effective way to accurately represent the organization within Employee Central as it is structured outside of the system. Many of the organizations that I have worked with have no problem with leveraging the Employee Central’s Foundation Objects to represent their organization structure in Employee Central as it fits how they operate and how they think organizationally.
The organization structure in Employee Central is extremely flexible and enables organizations to design their organization structure in a way that reflects the real-life structure of their business. SuccessFactors provides endless possibilities in how this can be configured and managed in the system and provides customers with a method to create an enterprise structure that suits their business. Customers should ensure that they investigate the integration options available if they are going to maintain an organization structure in SAP HCM. The standard integration provided by SAP will integrate the standard organization structure from SuccessFactors, but customizing this structure will mean additional mapping and integration work.