Human Capital Management Blogs by Members
Gain valuable knowledge and tips on SAP SuccessFactors and human capital management from member blog posts. Share your HCM insights with a post of your own.
cancel
Showing results for 
Search instead for 
Did you mean: 
Latyshenko2
Active Participant
This article came into being because the Implementation Design Principles Employee Central Core Hybrid: Organization Structure Design Consideration do not provide a universal solution on how to create the Company structure in Employee Central. Nevertheless, the solution exists and allows preserving the most of the existing organizational structure when moving from SAP HCM to Employee Central.

And before we delve into the details, I would like to thank my colleague Artur Avzalov for his support and ideas in the design of organizational structures. The design that I show in this article, we developed together on a real project.

Introduction


Organizational Structures are the heart of SAP SuccessFactors HXM Suite and requires comprehensive design to feed all SuccessFactors modules and integrated systems with the reliable foundation data. And the most fundamental part of Organizational Structures is the Company Structure.

In this article, we will demonstrate an approach for design of Company Structure in Employee Central that allows us to keep SAP HCM Organizational Structure from the unnecessary changes.

The article is addressed to experienced consultants in SuccessFactors Employee Central, SAP HCM and Core Hybrid.

The Company Structure


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

In the Employee Central module, there are many approaches on how to build the Company Structure, which is comprehensively described in the following IDP document Employee Central Core Hybrid: Organization Structure Design Consideration. From all the approaches described in the document, we will show the least painful; and we will also give some valuable recommendations that make the approach universal.

The first level of the Company Structure


For the purposes of the first level of the Company Structure, there should be a separate MDF object designated to this role and not used as the base for the other levels of the 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 Positions and the lower levels of the structure.

The codes of the first-level object should be linked to the root Organizational Units in SAP HCM, i.e. migrated from SAP HCM and replicated back to SAP HCM. For example, if there is only one root Organizational Unit in SAP HCM, then there should be only one code of the first-level object in Employee Central; and if there are several root Organizational Units in SAP HCM, then there are should be the same codes of the first-level object in Employee Central.

Depending on the design of SAP HCM and SuccessFactors Talent implemented at the client, the first level of the Company Structure would be either Division or Business Unit or a custom object:

  • Divisions are frequently used in SuccessFactors Talent as the list of Legal Entities. Also, Legal Entities (i.e. Company Codes) are frequently maintained as the main attribute of the root Organizational Units in SAP HCM.

  • Business Units are used as the first-level object if the client runs the same types of Businesses through different Legal Entities or in different countries.

  • A custom MDF object is used as the first level for grouping purposes, for example, for the groups of companies or as the single root object.


Despite the guidance from the above-mentioned IDP document, we advise using neither Legal Entity nor Department as the first-level object because of the following reasons:

  1. In SuccessFactors, Legal Entities are transferred from SAP HCM,[1] where they are used as the attribute of the Organizational Units; therefore, they should also become the attribute of the respective MDF object in Employee Central.

  2. Departments are used as the lower levels of the Company Structure; therefore, it is not convenient to use them in the role of the root object.


The second and the lower levels of the Company Structure


The second and the lower levels of the Company Structure should be based on Department, as described in the IDP document (see § 6.3 Option 1, p. 10). Other MDF objects, including Legal Entity, Matrix Positions, Pay Scale Area, Pay Scale Type, Country, Location, Personnel Area, Business Unit and Division,[2] should be attributes of Departments.

It is a good practice to designate the upper levels of Departments to a particular attribute (e.g. Country, Legal Entity, Location, Business Unit or Division), which significantly expands capabilities of Business Rules, Workflows and Permissions.

The child-level object should be linked to the parent-level object through a field (not an association) because the field has the On-Change Event and thus can execute the Evaluate-Purposed Business Rule upon the data entry in order to determine the level of the current Department in the Company Structure. The level of Department is used to populate values from the upper levels and to control visibility of the fields on the Configurable UI.

As shown in Figure 1, the highest-level Departments (i.e. the second level of the Company Structure) are linked to the first-level object with use of a custom field. The lower Departments are linked to the parent Department with use of the standard field parentDepartment. For details, see the IDP document Employee Central Core Hybrid: Organization Structure Design Consideration, § 6.3.1 Org Unit Department Object Structure and Configuration, p. 11.


Figure 1. The Company Structure in Employee Central and the Assignment of Positions to Departments



Configuration of Position


Let us assume that there are the following expectations from the Position Management:

  • Hiring Managers[3] can create Positions in Employee Central from scratch;

  • Positions can belong to a Department of any level in the Company Structure, as shown in Figure 1;

  • Positions inherit data from the Company Structure when they are assigned to the respective Department in order to use the data in Business Rules, Workflows and Permissions of Positions;

  • Employees also inherit data from the Company Structure when they are hired to a particular Position; and the data is also used in Business Rules, Workflows and Permissions of Employees.


To get Position Management closer to the above-mentioned expectations, we should make the following configuration for Position:

  1. The set of custom fields with respective criteria for entry of all the levels of the Company Structure, as shown in Table 1;

  2. The Evaluate-Purposed Business Rule that is triggered by the On‑Change Events of the fields for the Company Structure in order to fill the standard field department, as shown in Programming Code 1;

  3. For field department – visibility ‘Read Only’ and synchronization to jobInfo.


 
Table 1 Configuration of the Set of Fields for the Company Structure on Position











































































Field Name   Valid Values Source Visibility  Rule ID2  Source Field Name  Destination Field Name
division1 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_ONLY3

1 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 highest-level Departments to the Division. 2 See an example of the rule in Programming Code 1. 3 The department field should be editable during the migration of Position data from SAP HCM to Employee Central because it stores the relationship A-003 from Positions to the Organizational Unit 

Programming Code 1 shows an example of the Evaluate-Purposed Business Rule that is executed by the On‑Change Events of the fields for the Company Structure in order to calculate the value for field department of the Position.

Programming Code 1. The Body of the Business Rule for the Evaluation of Field department of Object Position
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;
}
}

Configurable UI for Position


Previously, we assumed that Hiring Managers can create Positions from scratch, which, in turn, requires intuitive UIs without the technical fields and without the unused empty fields for the lower levels of the Company Structure.

If it is required to hide/display fields of the Position UI depending on some circumstances (for example, when the UI is opened by a Hiring Manager or if a certain level of the Company Structure is empty) then we need to activate the Configurable UI.

Programming Code 2 shows an example of the UI Rule that controls the visibility of the fields for the Company Structure: the rule displays the child-level field only if the respective parent-level field is filled in. The rule is intended for the following UI Events:

  • The onInitUI Event that controls the field visibility when then the UI is opened, which also includes the insertion of a new record;

  • The onChange Events of the parent-level fields that controls the visibility of the child-level field once the respective parent-level field is changed.


Programming Code 2. The UI Rule that controls the visibility of the fields for the Company Structure* 
rule() {
if(literal(Position.cust_Department_L6) != null) {
Position.cust_Department_L2.visibility == "yes";
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(literal(Position.cust_Department_L5) != null) {
Position.cust_Department_L2.visibility == "yes";
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(literal(Position.cust_Department_L4) != null) {
Position.cust_Department_L2.visibility == "yes";
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(literal(Position.cust_Department_L3) != null) {
Position.cust_Department_L2.visibility == "yes";
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(literal(Position.cust_Department_L2) != null) {
Position.cust_Department_L2.visibility == "yes";
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";
}
else if(literal(Position.division) != null) {
Position.cust_Department_L2.visibility == "yes";
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 {
Position.cust_Department_L2.visibility == "no";
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";
}
}

* In the example, Division is used as the first-level object of the Company Structure

Conclusion


From the technical point of view, Employee Central can completely replicate the organizational structures of SAP HCM; therefore, the major changes of the organizational structure can be dictated only by the business needs and not by the technical restrictions.

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... (Accessed: 13 March 2022).

  2. Employee Central Core Hybrid: Organization Structure Design Consideration. Document Version 1.2. Available at https://d.dam.sap.com/a/Hf6JH6M/IDP%20Employee%20Central%20Core%20Hybrid%20-%20Organization%20Struct... (Accessed: 13 March 2022).

  3. Migrating Data from SAP ERP HCM to Employee Central Using Infoporter. Document Version 2H 2021 – 2022-02-28. Available at https://help.sap.com/doc/1cb0fa7722f44260b5ab7e6b8d7ab33c/latest/en-US/SF_ERP_EC_Data_Migration_en-U... (Accessed: 13 March 2022).

  4. TalentLyft. What is Hiring Manager? Available at https://www.talentlyft.com/en/resources/what-is-hiring-manager (Accessed: 13 March 2022).





[1] Company Codes are maintained in the Customizing table T001 and transferred from SAP HCM to Employee Central with use of transaction ECPAO_TRANS_FO_OBJ ‘Transfer Foundation Objects to EC.’ If there is a choice of transferring the Company codes either from SAP ERP or from SAP HCM, then the latter is more preferable.


[2] If an MDF object (for example, Business Unit or Division) is used as the base for the first level of the Company Structure, then it is recommended having two fields for the MDF object on each Department. The first field if filled only for the highest-level Departments (i.e. the the second level of the Company Structure) and used for data entry of Departments/Position and the Company Structure Overview. The second field is filled for all Departments and used for Business Rules and Permissions.


[3] Hiring manager refers to a person in the company responsible for hiring employees to fill an open position. Generally it's a person from the department in which the employee needs to be hired and acts as the future employee’s direct superior.


 

Russia

Author: Vladimir Latyshenko