| Status | |
| Owner | The person responsible for driving this decision and documenting it. Type @ to mention people by name |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
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
Based on the analysis done including the activities to be carried out when a GBU re-org happens, it is recommended to go with Option A: One Sales Org per company code and GBU.
Background & Context
Syensqo has multiple business units that are independent and separate organizations operating in legal entities that are shared across more than 1 GBU (Refer to the picture below for the same). 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
Following are the options 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.
Key Steps to be undertaken in case of a GBU restructuring (Not comprehensive):
- Adjust the user's allocation in Next Labs DAM and DAE
valuation
Option A Sales Organization per company code and GBU | Option B Sales Org per Company code and Division to differentiate GBU's | Option C Sales Org per Company code and Profit Center to differentiate GBU's | Option D Sales Org per Company code and Next Labs DAM and DAE to fulfil the GBU requirements | |
|---|---|---|---|---|
| Fit for Purpose - Authorisations | Very High All the requirements can be fulfilled | High Some of the requirements will be fulfilled by Standard. Enhancements required to fulfil all the requirements | Low No Standard support. Enhancements required to fulfil all the requirements | Medium Enhancement / complex rules required fulfil all the requirements |
| Fit for Purpose - Reporting | Very High All the requirements can be fulfilled | High Some of the requirements will be fulfilled by Standard. Enhancements required to fulfil all the requirements | Medium Few of the reports are supported. Enhancements required fulfil all the requirements | Medium Enhancement / complex rules required fulfil all the requirements |
| GBU Re-structure - Data cleansing | High | High | Medium | Medium |
| GBU Re-structure - Reporting | Very High All the existing reports can be executed for converged / Diverged BU's and also look at the data pre-reorg | High Some reports can be executed for converged / Diverged BU's and also look at the data pre-reorg | Medium Few reports can be executed for converged / Diverged BU's | High All the existing reports can be executed for converged / Diverged BU's. However, pre-reorg data will not be available |
GBU Re-structure - Complexity | Medium | Medium | High | High |
Align to Simple and Standard | Very High | High | Low | Very High |
Implementation Complexity | Very High | Very High | Low | Low |
Performance | Very High | High | High | Low |
Recommendation | Very High | High | Low | Medium |
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.
