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

Steps to be undertaken in case of a GBU restructuring:

• 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.

Steps to be undertaken in case of a GBU restructuring:

• 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

Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

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

Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly

Evaluation

Outline why you selected a position. The best format could be a pro/con table (sample below), but is up to you as the author. You must consider complexity, feasibility, cost/effort to implement, but also ongoing operational impact and cost. You must consider the program principles and explain any deviations in detail. This is probably as important as the decision itself.

	Option A	Option B	Option C	Option D
Criterion 1	Pro Con	Pro Pro	Pro Con	Pro Con
Criterion 2	Pro Con	Con	Pro Pro	Con Con
Criterion 3	Pro	Con	Con	Pro

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