Acknowledgements

I would like to thank NLMK Consultant Artur Avzalov for his excellent support and great ideas in design of organizational structures.

Introduction

Organizational Data is the heart of SAP SuccessFactors HXM Suite and it requires comprehensive design to feed other SuccessFactors modules and integrated systems with reliable data.

The most fundamental part of Organizational Data is the Company Structure.

In this blog post, we will demonstrate an approach for design of Company Structure in Employee Central that allows us to keep SAP ERP HCM Organizational Structure from unnecessary technical reorganization when implementing EC on production SAP ERP HCM systems.

The target audience of this post are experienced SuccessFactors Employee Central, SAP ERP HCM and Integration Core Hybrid Consultants and Architects.

Details

In SAP ERP HCM, the Company Structure is built with use of Organizational Units that collect all attributes of Company Structure like Legal Entities (aka Company Codes), Personnel Areas, Personnel Subareas, Cost Centers, etc.

In EC, there are multiple approaches to build Company Structure, and the most comprehensive document on it is the IDP Employee Central Core Hybrid: Organization Structure Design Consideration. In this post, we will try adding valuable details to the above-mentioned IDP.

The first level of Company Structure

The first level of Company Structure should always be a separate object that is specially designated to this role and is not used at other levels of Company Structure. Starting from this object all lower levels are selected on Positions and displayed in the Company Structure Overview. The first-level object is also used as the starting point for various Business Rules that populate data to lower levels of the Company Structure and Positions.

The first-level object should always be linked (i.e. migrated from ERP and replicated back to ERP) with the route Organizational Units. For example, if in SAP ERP HCM there is only one route Organizational Unit, then there is only one code of the first-level object in EC. If there are twenty route Organizational Units in SAP ERP HCM, then there are twenty codes of the first-level object in EC.

Depending on the current SAP ERP HCM and SuccessFactors BizX design at the client, the first level of Company Structure is most likely represented either with Division or Business Unit or a custom object:

Divisions are frequently used in BizX to represent Legal Entities. Also, Legal Entities are frequently maintained as an attribute of the route Organizational Units in SAP ERP HCM.
Business Units are also frequently used as the first level if the client have the same types of Businesses in different Locations and Legal Entities.
A custom object is frequently used as the first level for grouping purposes in SAP ERP HCM, e.g. a group of companies.

Despite the guidance from the above-mentioned IDP, we advise to use neither Legal Entity nor Department as the first-level object for the following reasons:

EC Legal Entities are replicated from table T001 of SAP ERP (the Company Codes table) with use of transaction ECPAO_TRANS_FO_OBJ and are themselves an attribute of Organizational Units.
Departments are used for lower levels of Company Structure and are not convenient in the role of the route object.

The second and lower levels of Company Structure

The second and lower levels of Company Structure should be Departments, as described in the IDP § 6.3, p. 10. Other analytics like Legal Entities, Matrix Positions, Pay Scale Areas, Pay Scale Types, Countries, Locations, Personnel Areas, Business Units, Divisions (the latter two if not used as the first-level object), etc. should be attributes of Departments.

Sometimes, it is possible to designate the upper levels of Company Structure to certain analytics (e.g. Country, Location, Business Unit or Division), which can be used in Business Rules, Workflows and Permissions.

It is more convenient to link the second-level Department to the first-level object with use of a custom field (not an association) and the third- and lower-level Departments to the parent Department with use of the standard parentDepartment field.

Compared to associations, fields are more preferable because they support OnChange Business Rules, which can be used for the on-change evaluation of the Department’s level, which in turn can be used for other Department’s Business Rules and Configuration UI to display or hide fields depending on the level of the Department.

Configuration of Position Data

Let us assume that:

Hiring Managers can create a Position from scratch;
Positions can belong to any level of the Department hierarchy, as shown in Figure 1;
Positions inherit the company-structure data through the assigned Department (e.g. Legal Entity, Division, Business Unit, Matrix Positions, Pay Scale Area, Pay Scale Type, Pay Group, Personnel Area, Personnel Subarea, Country, Location, etc.), which can be used in Business Rules, Workflows and Permissions on Positions;
Employees also inherit Department and other company-structure data through the assigned Position, which can also be used in Business Rules, Workflows and Permissions on Employees.

Figure 1. Company Structure in Employee Central and assignment of Positions to Departments

To address these requirements, we need to add all levels of the Company Structure as a set of custom fields, configure Field Criteria and OnChange Business Rule in order to transfer the selected Department to the standard field department (the latter is configured to be read-only and is synchronized to jobInfo), as shown in Table 1.

Table 1 Configuration of Fields on Position for entry of Company Structure *

Fields Name	Valid Values Source	Visibility	Rule ID	Source Field Name	Destination Field Name
division	Division	EDITABLE
cust_Department_L2	Department	EDITABLE	Position_department	cust_Division	division
cust_Department_L3	Department	EDITABLE	Position_department	parentDepartment	cust_Department_L2
cust_Department_L4	Department	EDITABLE	Position_department	parentDepartment	cust_Department_L3
cust_Department_L5	Department	EDITABLE	Position_department	parentDepartment	cust_Department_L4
cust_Department_L6	Department	EDITABLE	Position_department	parentDepartment	cust_Department_L5
cust_Department_L7	Department	EDITABLE	Position_department	parentDepartment	cust_Department_L6
department	Department	READ_ONLY **

_{* In the example, Division is used as the first-level object of the Company Structure and a custom field cust_Division is used to assign the second-level Departments to the first-level Divisions. ** The department field is editable during migration of Position Data from ERP to EC, which is relation A-003 from Position to Organizational Unit in SAP ERP HCM.}

Code 1 show an example of the OnChange Business Rule that evaluates the department field. For ease of navigation, we recommend to use the Business Rule for MDF Based Objects with purpose Evaluate and assign the rule to the OnSave event; however, the latter is optional.

Code 1. Body of the OnChange Business Rule for evaluation of the standard department field

rule() {
  if(literal(Position.cust_Department_L7) != null) {
    Position.department = Position.cust_Department_L7;
  }
  else if(literal(Position.cust_Department_L6) != null) {
    Position.department = Position.cust_Department_L6;
  }
  else if(literal(Position.cust_Department_L5) != null) {
    Position.department = Position.cust_Department_L5;
  }
  else if(literal(Position.cust_Department_L4) != null) {
    Position.department = Position.cust_Department_L4;
  }
  else if(literal(Position.cust_Department_L3) != null) {
    Position.department = Position.cust_Department_L3;
  }
  else if(literal(Position.cust_Department_L2) != null) {
    Position.department = Position.cust_Department_L2;
  }
  else {
    Position.department = null;
  }
}

Configuration UI for Position

Previously we made an assumption that Positions are created by Hiring Managers, which means that the User Interface should be as simple as possible and we need to hide the unused levels of Department.

To address these requirements, we need to use Configuration UI for Positions with an onInitUI / onInsertUI Business Rule to control visibility of the custom fields with Department of level three and lower. In addition, we need to hide the standard department field on the Configuration UI, as it duplicates the selection.

Code 1. Example of the onInitUI and onInsertUI Rule used to hide empty custom fields of Company Structure on the Configuration UI for Position

rule() {
  if(Position.cust_Department_L2 == null) {
    Position.cust_Department_L3.visibility == "no";
    Position.cust_Department_L4.visibility == "no";
    Position.cust_Department_L5.visibility == "no";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
  else if(Position.department == Position.cust_Department_L7 || Position.department == Position.cust_Department_L6) {
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "yes";
    Position.cust_Department_L5.visibility == "yes";
    Position.cust_Department_L6.visibility == "yes";
    Position.cust_Department_L7.visibility == "yes";
  }
  else if(Position.department == Position.cust_Department_L5) {
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "yes";
    Position.cust_Department_L5.visibility == "yes";
    Position.cust_Department_L6.visibility == "yes";
    Position.cust_Department_L7.visibility == "no";
  }
  else if(Position.department == Position.cust_Department_L4) {
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "yes";
    Position.cust_Department_L5.visibility == "yes";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
  else if(Position.department == Position.cust_Department_L3) {
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "yes";
    Position.cust_Department_L5.visibility == "no";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
  else if(Position.department == Position.cust_Department_L2) {
    Position.cust_Department_L3.visibility == "yes";
    Position.cust_Department_L4.visibility == "no";
    Position.cust_Department_L5.visibility == "no";
    Position.cust_Department_L6.visibility == "no";
    Position.cust_Department_L7.visibility == "no";
  }
}

Conclusion

The Company Structure in Employee Central is capable of mirroring the SAP ERP HCM Organizational Structure and does not require unnecessary reorganization for technical purposes.

Reference list

Latyshenko, V.V., 2020. The Core Hybrid integration model on the example of Cost Centers. SAPinsider, [online]. Available at https://www.sapinsideronline.com/wp-content/uploads/2020/12/The-Core-Hybrid-Integration-Model-on-the-Example-of-Cost-Centers.pdf (Accessed: 10 August 2021).
Employee Central Core Hybrid: Organization Structure Design Consideration. Document Version 1.2 – 2020-07-28. Available at https://d.dam.sap.com/a/Hf6JH6M/IDP%20Employee%20Central%20Core%20Hybrid%20-%20Organization%20Structure%20Design%20Consideration%20V1.2.pdf (Accessed: 10 August 2021).
Migrating Data from SAP ERP HCM to Employee Central Using Infoporter. Document Version 1H 2021 – 2021-07-21. Available at https://help.sap.com/doc/1cb0fa7722f44260b5ab7e6b8d7ab33c/2105/en-US/SF_ERP_EC_Data_Migration_en-US.pdf (Accessed: 10 August 2021).
TalentLyft (2021) What is Hiring Manager? Available at https://www.talentlyft.com/en/resources/what-is-hiring-manager (Accessed: 10 August 2021).

Mirroring of the SAP ERP HCM Organizational Structure in the EC Company Structure