Issue

Syensqo has different types of plants including virtual plants created to support different activities ex: Intercompany, Subcontracting etc.. Due to a large number of virtual plants, the supply chain transactions become very cumbersome, and the automation opportunities are limited. As a part of the ERP Rebuild program there is an opportunity to standardise and simplify the plant structure.

Recommendation

Based on the analysis, Option B: Simplify and standardise the Plant Structure is proposed. This option will simplify the and standardise the number of plants and the supply chain network of Syensqo. All the plants will have to evaluated based on the plant decision tree during the detailed design

Background & Context

Plant represents a physical location where materials are produced, procured, stored, maintained or distributed. Following are some of the key functionalities at plant level

• Materials are valuated at plant level
•   Inventory management functions including inventory reporting are carried out at plant level
•   Materials Requirement Planning (MRP) is carried out at plant level
•   Production and production planning activities are executed at plant level
• Maintenance and maintenance planning activities are executed at plant level
• A plant is the location where the technical objects of a company are installed i.e. Workcenter, functional location etc.
• Many master data objects are maintained at plant level ex: Material master MRP, Purchasing, QM etc.
• Plant is a key element for application system security

The current plant structure has a lot of duplicate plants and virtual plants which increases the complexity of supply chain transactions as the stock movements have to be carried out on the virtual plants even though physically the stock is not moving, increasing operational overhead as these virtual plants needs to be kept in sync with inventory, purchasing transactions and intercompany / intracompany transactions.

Assumptions

• Advanced Intercompany will be implemented in Syensqo which will get rid of the traded plants KDD017 - Intercompany Processing in the new ERP Solution - ERP Rebuild - Syensqo - Wiki knowledge base
• Sub-contracting plants are not required and will be managed via the standard sub-contracting process

Constraints

Any change in the current understanding of tax treatments / regulatory requirements will change the plant design

Impacts

Following are the impacts

Data Conversion and migration: Data from the As-Is systems need to be mapped based on the proposed Plant Structure

Cutover: Inventory migration approach should consider the plant design

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

Business Rules

A location will be defined as a plant if atleast one the following conditions are met:

• Inventory is held and the ownership linked with this location 
• Inventory is valued separately and material price varies
• Technical objects like functional locations etc., are reported and mapped to this location
• Location executes production and / or maintenance activities
• Has its own set of material master data values e.g. lead times, lot sizes etc.
• Location requires separate authorizations

Options considered

Following are the options proposed

Option A: Continue with the As-Is Plant Structure

No changes in the existing plant structure and we copy all the valid plants from the As-Is system

Option B: Simplify and standardise the Plant Structure

As a part of this option, the plants are proposed to be simplified based on a decision tree. Each and every plant needs to be evaluated against the decision tree during detailed design to identify which of the As-Is plants are valid and needs to be created as plants in the To-Be structure

Evaluation

	Option A: Continue with the As-Is Plant Structure	Option B: Simplify and standardise the Plant Structure
Operational Complexity	Con: Multiple virtual plants cause a lot of operational complexity as the virtual transactions needs to be posted without any physical movements Stock take is cumbersome Stock Valuation is complicated	Pro: No virtual plants except for technical purposes (ex: Advanced Intercompany Sales). Document flow and logistics flow matches and therefore the transactions are less complex
System Complexity	Con: Complex enhancements to fulfil the requirements of virtual plants Multiple virtual plants introduce complexity / performance issues in reporting	Pro: Lesser plants in the system. Complex enhancements not required to keep the stock in sync
Automation Complexity	Con: Multiple complex automations required to keep the system in sync	Pro: Any new automations can be built easily as there are not virtual plants and virtual postings and therefore lesser scenarios to model
Data migration Complexity	Pro: Less complex as the data mappings required are minimum	Con: Complex as there will be data mappings and de-duplications required.

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