Handling Complex Org Structures in SuccessFactors (Replicating from SAP HCM)

[rithinthomas2]

Complex Org Structure for integration with SAP HCM

While talking to customers, Specifically the ones migrating from HCM to SuccessFactors it has been a constant challenge to replicate their current org structure(OU - OU) to the Cloud counterpart (BU-DIV-DEPT)  framework where there is no constant across any layer and the bottom most org unit could be on any org layer as shown in the image below

 

Org Structure from SAP HCM

The Star in the above picture represents the bottom most layer of each structure. Employees could be assigned on any layer 

SuccessFactors offers a standard 3 layer org structure excluding Legal Entity as a standard offering which are categorized as Business Unit, Division and Department. In cases wherever all three 3 layers fits in for all combination of org layers it’s a win-win for everyone.

SuccessFactors Org Structure

Now, In SAP HCM, the above concept does not exist. It’s a 1 to 1 Mapping between org units which form a larger org structure and employees could be assigned on any of the org layers since positions can only be assigned to only one Org unit. Through these Org units other Org attributes like Manager/HOD and Cost Centre etc. may cascade /default to the Position/Job Info section (depending on your design).

SAP HCM Org Design

.

Few of the challenges while replicating such scenarios in SuccessFactors:

1. In cases where Cost Centre/HOD or any other attribute needs to be inherited from the Org Unit/Layer (Eg : Cost Centre/HOD etc.), we have to write multiple business rules for each layer. Sometimes its not possible to drive a common logic depending on the complexity of the scenario.


2. In case of Org Restructuring of Org Layers, multiple data upload to be done on all layers which makes it a very tedious activity.


3. Can not make all Org layers mandatory on Job info/Position which makes it difficult to filter data while reporting/data analysis as we cannot find values against all Org layers against Employees or Positions. Also while using filters across other functionalities across SucessFactors (E.g: Employee Directory)


4. In case of any custom layers (Custom MDF Object) added for additional org layers then we need to customize the replication program as well to accommodate these objects as well.

Question is how can we migrate this 1-1 mapping of org units in SAP HCM structure to a 3 layered structure of SuccessFactors and try to find a constant where we can attributes from the bottom most layer can be inherited  without having complex/multiple rules and logics (Eg: Cost Centre/HOD etc.) while making sure we do not have to customize the replication program from EC to S4.

Solution :

Create the Business Unit in the above structure as a "department" object. This can be associated to Legal Entity as well depending on the requirement.

Parent Department (sample created in SuccesFactors sales demo instance)

 

Create the next Org layer of Division as another department and assign the above "BU1" as the Parent Department.

Child Department (sample created in SuccesFactors sales demo instance)

Same logic to be applied to all layers below till the bottom most org unit and get the same org structure replicated as expected.

Complete Org Structure (sample created in SuccesFactors sales demo instance)

There could be multiple variations in this based on the above scenario. For E.g you can try to keep the 1st two layers (Business Unit & Division) constant and the third one (Department) could be variable. Advantages of doing so is  that you can leverage the existing filters Business Unit and Divisions across multiple functionalities across SuccessFactors (E.g : Reports, Employee Directory etc).

In case the 1st two layers are not constant and can not be used, you can also repurpose the , you can also repurpose the 1st two org objects (Business Unit and Division) to capture different data (Eg, Plant/Business area etc) depending on the nature of Business or Business Scenario.

Feel free to drop a comment in case you may have any variations where this scenario could possibly be helpful.

Stay home. Stay safe !

Rithin Thomas

[StevenLiu刘家骥]

Is this essentially bypassing the division/BU set up?

[rithinthomas2]

Hi Steven,

It wouldnt be my first preference to bypass BU and Division for Org layers. In case we can keep the 1st two layers constant for all org layers then we can retain these objects within the org layer.

There are client org structures which end in 1 layer as well. In such cases, BU and Division can be re-purposed for different data sources like Plant or Business Area (very specific to manufacturing clients).

However, depends on the client org structure.

Thanks and regards,

 

 

 

[pighairsap]

Hi,

 

I encountered a problem while I'm trying to do same thing.

I use Legal Entity and Department to build company structure hierarchy. Department has one-to-one association to Legal Entity. I added Department element twice in Company Structure configuration to display sub-department under parent department.

Sub-departments are displayed under parent department well, but the problem is all sub-departments are also displayed under associated legal entity. So if I expand a parent department, there are two departments displayed in Company Structure as image below.

Two SalesSub in one screen

How can I hide sub-departments from first row of departments like last image of your article?

[rithinthomas2]

Hi Changwon,

Apologies for the delay in response, I am guessing you would have found the solution already.

However, What you need to do is you need to configure a child entity to the department as shown in the below screenshot.

Thanks and Regards,