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

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 organizational 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

1. 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: 25 April 2021).
2. 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: 25 April 2021).
3. Migrating Data from SAP ERP HCM to Employee Central Using Infoporter. Document Version 1H 2021 – 2021-04-23. Available at https://help.sap.com/doc/1cb0fa7722f44260b5ab7e6b8d7ab33c/2105/en-US/SF_ERP_EC_Data_Migration_en-US.pdf (Accessed: 25 April 2021).
4. TalentLyft (2021) What is Hiring Manager? Available at https://www.talentlyft.com/en/resources/what-is-hiring-manager (Accessed: 25 April 2021).