Issue

Syensqo currently operates with two distinct sales organization structures, each developed independently to meet the needs of different markets or product lines. This disparity in sales structures leads to challenges in managing sales processes, reporting, and cross-functional collaboration. Furthermore, the existing structures are not agile enough to support future reorganization efforts. As part of the ERP Rebuild program there is a need to design and implement a standardized sales organization structure that unifies the existing sales orgs, ensuring operational efficiency, consistency in reporting, and the flexibility to adapt to future reorganization needs.

Recommendation

Using one Sales Org per combination of Company Code per GBU is recommended. This is based on an analysis which includes the activities to be carried out when a GBU re-org happens and the best fit based on the GBU specific requirements. This is labelled as "Option B" in the document.

Background & Context

Syensqo operates through several Global Business Units (GBUs), each with its own independent sales processes and revenue recognition procedures. The GBU is a commercial representation of the Syensqo organization. These GBUs are spread across multiple countries, necessitating the assignment of various legal entities (Company Codes) to manage local operations and comply with regulatory requirements (this is the operational view of Syensqo). While some of these legal entities are dedicated to a single GBU, others serve multiple GBUs. This means that certain legal entities handle transactions and financial activities for more than one GBU, leading to shared use of these entities across different units. 

For legal entities that serve multiple Global Business Units (GBUs), it is essential to design the sales organizational data in a manner that effectively supports operational, legal, and commercial requirements. This design should ensure:

• Operational Support: The sales organizational data must be structured to facilitate smooth and efficient commercial business processes for each GBU. This includes configuring enterprise structure objects to align with the specific needs and workflows of each commercial unit while leveraging shared legal entities.

• Legal Compliance: The data setup must comply with the legal and regulatory requirements in each country where the legal entities operate. This involves adhering to local taxation rules, financial reporting standards, and other legal obligations that affect sales and revenue transactions.

• Commercial Requirements: The sales organizational data should be designed to support comprehensive and accurate commercial reporting. This includes generating reports that reflect the performance and financials of each GBU while ensuring that shared legal entities can provide consolidated and detailed insights as needed.

• Agility and Scalability: The design must be flexible enough to adapt to changes in business needs or expansion into new markets. It should be scalable to accommodate future growth, additional GBUs, or changes in regulatory requirements without requiring significant restructuring.

Current State

Currently, Syensqo employs a mix of methods to meet these GBU requirements:

• Separate Sales Organizations: For some entities and GBUs, distinct sales organizations are used to represent different GBUs, ensuring clear segregation.

• Combination of Division and Distribution Channel: For other GBUs and entities, a combination of divisions and distribution channels is used to achieve the required separation.

Below is the current Legal entity and Sales Org Statistics in the system.

Considerations for the To-Be State

Following are some of the key Requirements at GBU Level identified as part of workshops 

1. Commercial Segregation of Information and User Access:

   • Requirement: The system must ensure that information and access are segregated based on the Global Business Unit (GBU) to which users belong. For instance, a salesperson working in one GBU should not be able to view or access master data or transactional data from another GBU, even if both GBUs operate under the same legal entity. This segregation is crucial for maintaining data privacy and integrity within the system.

2. Commercial and Management Sales Reporting by GBU:

   • Requirement: The system must support both commercial and management reporting for each GBU. This includes:

     • Transactional Level Reports: Detailed reports that provide insights into day-to-day transactions within each GBU.

     • Summarized Management Reports: High-level reports that aggregate data for strategic decision-making. Both types of reports should be able to be segregated and secured according to the GBU, ensuring that each GBU's data is reported and analyzed independently

To develop a new design for the enterprise structure, a comprehensive analysis of various master data attributes that differ across Global Business Units (GBUs) within a legal entity has been conducted. This analysis is crucial for understanding the dependencies and interactions between these attributes and the overall enterprise structure. The following master data attributes, which vary at the enterprise structure level, have been identified and should be considered in the design so that the Sales Processes are not disrupted:

Material Attributes:

1. Item Category Group: Defines the category of the material item, influencing how it is processed and managed within the system.
2. Account Assignment Group: Determines the type of account assignment for the material, affecting how costs and revenues are recorded and managed.
3. Product Hierarchy: Represents the classification of products in a hierarchical structure, facilitating better management and reporting of product lines.

Customer Attributes:

1. Incoterms: Specifies the terms of delivery agreed upon with the customer, outlining the responsibilities for shipping, insurance, and transport costs.
2. Terms of Payment: Defines the payment conditions and schedules agreed with the customer, affecting cash flow and financial planning.
3. Shipping Conditions: Indicates the preferred shipping methods and requirements for the customer, impacting logistics and delivery processes.
4. Delivery Priority: Assigns a priority level to customer orders, influencing the order processing and fulfillment sequence.

Assumptions

None at this point 

Constraints

None Identified at the time of writing the document

Impacts

Following are the impacts

• Data Conversion and Migration: Data from the As-Is systems need to be mapped based on the proposed to-be Sales Org structure and logics.
• Integrated Systems (Upstream/Downstream): There will be an impact on all integrated systems and applications that use the Sales Org for identification purposes. There needs to be a one-time remediation or mapping exercise undertaken to identify all impacted systems and respective mitigation strategies need to be worked out during detailed design.
• Sales Enterprise Structure Object definition: The rest of the sales enterprise structure object definition is dependent on the sale organization structure (division, distribution channel, etc)

Business Rule

One Sales Organization is defined per combination of Company Code and GBU.

Options considered

The following options were considered:

Option A: Sales Organization per company code

The proposed strategy involves establishing a distinct Sales Organization (Sales Org) for each Company Code . This means that each Sales Org will be specifically aligned with a Company Code as per the diagram below.

Future requirements fit:

GBU Re-structure Impact

Key Steps to be undertaken in case of a GBU restructuring (Not comprehensive):

• Revalidate the security restrictions if they are still applicable or not
• Adjust the enterprise structure objects affected
• Update the relevant master data attributes
• Potentially update any developments made to support this approach.

NOTE: Since there is a commercial requirement represent GBU, there will need to be a way to represent the GBU in all sales related transactions. In order to achieve this using this option, a number of different objects will be required to enable this representation (for example, distribution channel, division, order type, profit center, etc). 

Option B: Sales Organization per company code and GBU

The proposed strategy involves establishing a distinct Sales Organization (Sales Org) for each unique combination of Company Code and Global Business Unit (GBU) within the company. This means that each Sales Org will be specifically aligned with a particular Company Code and the associated GBUs operating under that Company Code as per the diagram below.

Future requirements fit:

GBU Re-structure Impact

Key Steps to be undertaken in case of a GBU restructuring (Not comprehensive):

• Select/Create a Master Sales Org(s) when 2 or more Sales Org are being converged / diverged
• Extend all active Master data to Master Sales Org(s) is not already existing 
• Lock the master data on the rest of the Sales Org which are not required and remove the transactional access
• Extend the users / authorisations of the users to the Master Sales Org(s)
• Report on all the converged / diverged Sales Org's until the reporting horizon is reached

Option C: Sales Org per Company code and Division to differentiate GBU's

As part of this option, the proposal is to create a Sales Org per each company code and use divisions to differentiate the GBU's within the Sales Org.

Future requirements fit:

GBU Re-structure Impact

Key Steps to be undertaken in case of a GBU restructuring (Not comprehensive):

• Select/Create a Master Division(s) when 2 or more Divisions are being converged / diverged
• Extend all active Master data to Master Division(s) is not already existing 
• Lock the master data on the rest of the Divisions(s) which are not required and remove the transactional access
• Extend the users / authorisations of the users to the Master Division(s)
• Report on all the converged / diverged Division's until the reporting horizon is reached
• Update any developments to align with new or updated structures

NOTE: Since there is a commercial requirement represent GBU, there will need to be a way to represent the GBU in all sales related transactions. In order to achieve this using this option, a number of different objects will be required to enable this representation (for example, distribution channel, division, order type, profit center, etc)

Option D: Sales Org per Company code and Profit Center to differentiate GBU's

The proposal to create a Sales Organization (Sales Org) for each Company Code. Within each Sales Org, Profit Centers will be used to manage and differentiate between various GBUs by tracking and managing revenues, costs, and profitability for different segments of the business.

GBU Re-structure Impact

Key Steps to be undertaken in case of a GBU restructuring (Not comprehensive):

• Change profit center hierarchy and levels, it would mean that some reorganization activity is required to clean up the profit centers
• Authorisations needs to be re-built as the hierarchies of the converged / diverged business has changed
• COPA characteristics have to be updated for the reports to be accurate

NOTE: Since there is a commercial requirement represent GBU, there will need to be a way to represent the GBU in all sales related transactions. In order to achieve this using this option, a number of different objects will be required to enable this representation (for example, distribution channel, division, order type, profit center, etc)

Option E: Sales Org per Company code and Next Labs DAM and DAE to fulfil the GBU requirements

As part of this option, the proposal is to create a Sales Org per each company code and use Next Labs DAM and DAE to restrict the data and reports to the business user. The business user can see only the data relevant to their GBU.

• This option is a database level restriction and requires all the rules to be built from scratch which will require very complex combinations.
• It Relies heavily on the correct allocation of users and will also have to cater for a design where users that are part of the global organization
• Is not visible to the user in master data, transactional data or reporting attributes.
• This approach will result in a significant increase of the volume of data being protected by NextLabs, which presently is only foreseen to be used for sensitive IP that is also export-controlled (i.e. Bills of Material and associated manufacturing-related data such as Routings, Costing BOM, etc.). This increased use of NextLabs will likely result in performance impacts to a large number of Sales-related transactions as each access to NextLabs-protected data will introduce additional latency into the data access. 

Key Steps to be undertaken in case of a GBU restructuring (Not comprehensive):

• Adjust the user's allocation in Next Labs DAM and DAE

Evaluation

See also

Change log

Workflow history