| Status | |
| Owner | The person responsible for driving this decision and documenting it. Type @ to mention people by name |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
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
Summarise the recommendation being made for the reader, leaving the pro/con evaluation and exact decision-making process to the subsequent sections.
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
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 |
|
|
|
|
| Criterion 2 |
|  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.
