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

Background & Context

Plant represents a physical location where materials are produced, procured, stored, maintained or distributed. Following is 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 wrt 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

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

Change log

Workflow history