Issue

Syensqo has two systems which have very different rules for defining the Sales Org. 

Recommendation

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

Constraints

Impacts

Business Rules

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

See also

Change log

Workflow history