Issue

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

Recommendation

Summarise the recommendation being made for the reader, leaving the pro/con evaluation and exact decision-making process to the subsequent sections.

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

Clearly describe the underlying assumptions which informed or limited the choices available, or impacted the decision: cost, schedule, regulatory requirements, business drivers, country footprint, technology, etc. Include links as necessary. This section is important because a future change in circumstances might invalidate some key assumptions, which then prompts a decision to be revisited. 

Constraints

Capture any constraints or limitations inherent to the recommended option. This could be aspects which, if changed or removed in future, could cause the decision to be revisited or invalidated. For example, a constraint might be that a new product has significant gaps in important functionality, which caused an older alternative to be recommended. If those gaps are closed in future, this might cause the decision to be invalidated.

Impacts

Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.

Business Rules

The decision may translate into business rules which enforce the decision and will require configuration. List these business rules here. For example, "An Outline Agreement cannot be created via the RFQ process. An awarded RFQ can only result in a Purchase Order". 

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

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