Employee Central Core Hybrid: Organization Structu...

Sharath_T_N · ‎2024 Jun 14

Abstract

This blog post introduces you to the published SuccessFactors Implementation Design Principle (SFIDP) document: (Employee Central Core Hybrid: Organization Structure Design Considerations). Implementation Design Principle documents are owned and managed by SAP SuccessFactors Product Success who engage and collaborate with select, interested partners along with SAP Professional Service to tap the rich implementation experience that is distilled in the document after a formalized product review process before wider publication.

Acknowledgements:

This document had valuable contribution from SAP SuccessFactors partners towards authoring and including Brandon Toombs, Kelly Paragas, Patrik Neubacher and Umesh Chaudhari. The collaboration and insights from these distinguished experts, who have extensive experience working on global projects, have inspired us to present robust options on this topic. Their expertise and dedication have been instrumental in shaping the comprehensive solutions outlined in this document.

Introduction

Organizational Management is recognized as a pivotal component within SAP SuccessFactors HCM, contributing significantly to the efficient structuring and operation of every organization. Leveraging SAP SuccessFactors HCM, businesses can streamline their organizational frameworks, fostering enhanced productivity, collaboration, and strategic alignment across all levels.

The standard organizational structure in SuccessFactors typically comprises three hierarchical levels: Business Unit, Division, and Department. The default alignment of these structures is hierarchical, with the Business Unit serving as the parent of the Division, which, in turn, is the parent of the Department. Should additional levels be necessary, a common approach involves Departments reporting to one another.

SuccessFactors offers a higher degree of flexibility to accommodate the unique requirements of each customer's organizational model. Common adjustments may include disabling one of the three levels (such as the Business Unit), reordering the hierarchy (making the Division the parent of the Business Unit), or introducing custom organizational levels (like adding "Region" below the Division but above the Department). However, the focus of this document is not to enumerate the various customization options available, but rather to provide a 'safe harbor' approach and rationale for adopting it."

A common oversight observed in some implementations is the exclusive consideration of SAP SuccessFactors Employee Central, neglecting the usage of organizational objects in other modules.

Ten points to consider during the design of a Org Structure

Which are the standard fields in the Employee Profile that are mapped to EC Org Objects
How deep does the organizational hierarchy go in the organization? Which are the levels where certain decisions are made?
From a reporting point of few which are the objects used and how deep in the hierarchy we need the reports
Usage of Org Objects in Workflows
Usage of Org Objects in Role based permissions
Usage of Org Objects in Talent modules such as Recruitment, Learning Management system, Performance Management and so on
Visualization requirements of the Org hierarchy
Relation between the org Objects
Impact on downstream Application
Impact of mass changes /Re-org

By addressing these points, organizations can ensure a comprehensive understanding and effective utilization of organizational objects within the SuccessFactors ecosystem, leading to enhanced operational efficiency and strategic decision-making.

Detailed Solution

The document gives 2 options as solution options. Both options have this commonality

Utilizes standard objects available within SuccessFactors for seamless integration and compatibility.
Aligns with the design principles of SAP SuccessFactors HCM, ensuring consistency and adherence to best practices.

Supports the Core-Hybrid model of SAP HCM, facilitating smooth transition and integration between on-premise and cloud-based solutions.

Option 1 – Standard Foundation Objects:

The first option proposes the utilization of the three standard foundation objects: Business Unit, Division, and Department to construct the organizational structure design, along with its hierarchical relationships and associations corresponding to each level. At the apex of the hierarchy lies the Business Unit, positioned at Level One (L1), succeeded by Division at Level Two (L2), with the Department occupying the lowest tier at Level Three (L3).

Please refer to the IDP document for the details. The blog only gives the highlights

Option 1

Pros:

Seamless integration with other SAP modules.
standard objects are easier to maintain because the data structure and associated attributes are supported by the SAP SuccessFactors Product
Beneficial future enhancements from SAP releases.

Cons

Limited to three levels and may not align with the organization’s unique organizational structure (that is, additional levels are needed)
Confined with the standard object hierarchy and definition. Some organization treats Division as Level 1 and Business Unit as Level 2.
Requires changing how the organization is structured which may not be operationally feasible

Option 2 – Additional Levels in the Hierarchy:

This option becomes relevant when the reporting and Role-Based Permission requirements extend beyond the first three levels within SAP SuccessFactors Employee Central. Option 2 addresses scenarios where there's a necessity for reporting or incorporating more than three levels of hierarchy, or when the creation of source/target permission groups is required without resorting to the use of Custom Objects.

Department Level Structure

The picture below shows how the additional organizational level structure using the parent-child relationship of the Department object can be configured within the Department object itself.

Define other fields like Department Level 1, Department Level 2, and so on. as indicated in the figure below (This is optional see the advantages in the section below). These are custom fields defined on the department object. Level 1 is the root node; it would not have any parent. Level 2 would have level 1 as the parent. Continuing, in the same way, custom fields are arranged in a top-down approach would mean the number of department objects shown can be filtered at every level.

Please refer to the IDP document for the details. The blog only gives the highlights.

Option 2

PROS

As in Option 1, using the standard objects ensures seamless cross-module integration
Standard objects are easier to maintain because the data structure and associated attributes are supported and maintained by SAP Product Team
You take advantage of future enhancements on additional features applied on each release to standard objects on each release.
Using the standard Department to Parent Department association for a multi-level org unit approach makes the often-used integration to SAP HCM easier.
In addition, the standard Department to Parent Department association for a multi-level org unit approach provides a simplified process regarding re-organization as you can easily move Departments and associated Child-Departments.

Cons

Search possibilities such as within Company Structure Overview, are less user-friendly compared to using several standalone custom objects for the organizational structure since all are selectable independent of the level when searching for Departments.
Using all standard objects in combination with the replication of an Organizational object to SAP HCM may lead to duplicates in the first two Department levels
Introducing the Business Unit and Division as top levels might be more beneficial in the case of a global functional organizational structure compared to a commonly used local entity-based structure
Requires changing how the organization is structured which may not be operationally feasible
Including a full-level structure within the Department (and Position and/or Job Information) requires mass updates and the creation of time slices for any affected Department record (and Position and/or Job Information) without currently benefiting from standard mass-update features

Leading Practice: Using Position Hierarchy and Disabling Chief Positions in SAP

SAP SuccessFactors has established a clear strategic direction that emphasizes the transition from chief positions to a position-to-position hierarchy within Employee Central. Future functionalities and updates within Employee Central will be designed based on this position-to-position framework. Consequently, all customers will eventually need to adapt their SAP HR hierarchies to align with this new approach.

To effectively manage this transition, it is advisable to undertake the shift away from chief positions during the Employee Central implementation phase. This approach is recommended for several reasons:

Integrated Testing Cycle: The implementation of Employee Central inherently includes a comprehensive testing phase. Integrating the transition to a position-to-position hierarchy within this cycle allows for thorough testing of the new structure. Postponing the transition would necessitate a separate, extensive testing phase at a later date, which can be resource-intensive.
Change Management Synergy: The Employee Central implementation already involves significant change management efforts. Addressing the hierarchy transition concurrently allows these efforts to encompass any challenges or adjustments needed for the new hierarchy structure. This coordinated approach can mitigate resistance and streamline the adoption process.

Recommended Steps for Transition Planning

Communicate the Change to Key Stakeholders
Inventory -Existing Business Processes
Inventory Technical and Integration Assets
Delimit Chief Relationships in the Project Environment

As a rule, hierarchy is evaluated using the reporting structure (based on O-S-P), the module RH_GET_LEADING_POSITION can also evaluate the alternative reporting structure that is based on the position hierarchy. The switch WFLOW SA002 has the value 'X' in table T77S0, and the position hierarchy is evaluated instead of the reporting structure(O-S-P). Refer to the note https://launchpad.support.sap.com/#/notes/2652564 for more details.

Authorizations

Structural authorizations, which are based on evaluation paths and dynamic determination of root org units will possibly have to be reviewed, for processes such as MSS/ESS and reporting (note that even if EC becomes the system of record for employee master data, some of the above processes, including ESS/MSS may still exist in ERP).

Wokflows

If workflows in the SAP ERP HCM system are based on the standard role resolution function modules, they will not be affected by the absence of the A012 relationship, because in the first iteration, they always try to get the directly linked positions. Only in the case that there are no directly linked positions, the leading positions are considered. If you have custom-specific coding in place, make sure to check that your coding supports this approach.

Reporting

Many reports can be built on specific evaluation paths. Those that use A012 will need to be evaluated and adjusted.

Conclusion/Key Takeaways

We hope this document has provided you with a good understanding of the concepts and use cases discussed in the SAP SuccessFactors Implementation Design Principles (SFIDP). Please refer to the IDP document for the details. The blog only gives the highlights. By exploring these foundational elements, you are now better equipped to navigate the complexities of organizational structure design.

We encourage you to delve deeper into the document to fully appreciate the nuanced strategies and practical recommendations it offers. This comprehensive guide is designed to support you in making informed and strategic decisions for setting up an effective and future-ready organizational structure.

For a complete list of published Implementation Design Principles for SAP SuccessFactors Solutions, visit SAP SuccessFactors Customer Community page.

Link to the IDP document