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 and GBU is recommended. This is based on an analysis which includes the activities to be carried out when a GBU re-org happens. This is labelled as "Option A" in the document. 

Background & Context

Syensqo has multiple business units that are independent and separate organizations operating in legal entities that are shared across more than one GBU. Following are some of the key requirements at GBU level:

1. Operational segregation of information and access to the users in the system based on the GBU they belong to (ie. a sales person in one GBU can't see master data or transactional data from another GBU even if they are in the same legal entity)
2. Operational and Management Reporting by GBU. This means that both transactional level reports as well as summarized management reports must both be able to be segregated and secured by GBU

Currently a combination of methods is used to represent these GBU requirements, i.e. Separate Sales Org per GBU for some entities and GBU's and a combination of Division and Distribution Channel for the other GBU's and entities. This non-standard way of representation creates a lot of overhead / inconsistencies while reporting and also pose a significant challenge when the GBU's are restructured. 

Assumptions

None at this point 

Constraints

None Identified at this point

Impacts

Following are the impacts

Data Conversion and migration: Data from the As-Is systems needs to be split / enhanced based on the proposed Sales Org Structure

Downstream System: There will be an impact on all the downstream systems that use Sales Org and there should be a one-time remediation or mapping exercise that should be undertaken

Business Rule

N/A

Options considered

The following options were considered:

Option A: Sales Organization per company code and GBU

As part of this option, the proposal is to create one Sales Org per a combination of Company Code and the GBU's that are part of that company code. 

• Sales Org permeates through all sales related master data and transactional data and is held at the header of any object that has a header and line-item concept. Therefore, all sales master data and transactional data can use sales org as an authorization differentiator
• All sales reports have sales org as the primary selection criteria and Sales org can be passed as a key attribute in all management reporting or finance reporting which will fulfil the reporting requirements

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 B: 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.

• Division is part of the sales enterprise structure object and is linked to a sales org. It permeates through only some of the sales related master data and transactional data (for example, customer master does not have a division view). It is often held at both the header and line item of the transactional documents and a document can technically have lines belonging to different divisions and therefore only some sales master data and transactional data can use division as an authorization differentiator.
• Only some standard sales reports have division as a selection criterion. Division can be passed as an attribute in some management reporting or finance reporting.

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

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

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

• Profit Center is part of the sales enterprise structure and is only attached to some sales transactional data. It is only held at item level of transactional documents and there is no standard authorization object on profit center in sales transactions. Therefore, profit center can be used as an authorization differentiator for limited scenarios
• Only a very small number of standard reports have profit center as a selection criterion and therefore many customisations to the standard reports are required. Note: Performance is going to be a question as the profit center is at line-item level

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

Option D: 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

Insert links and references to other documents which are relevant when trying to understand this decision and its implications. Other decisions are often impacted, so it's good to list them here with links. Attachments are also possible but dangerous as they are static documents and not updated by their authors.

Change log

Workflow history