| Status | |
| Owner | |
| Stakeholders | The business stakeholders involved in making, reviewing, and endorsing this decision. Type @ to mention people by name |
Issue
Syensqo currently operates multiple Management of Change (MOC) systems across Syensqo to govern product, process and operational changes.
In parallel, the New Product Introduction (NPI) business process, developed within the S/4HANA environment, defines a standardized and integrated framework for Product Creation and Product Modification activities across the product lifecycle.
A decision is required to determine whether Syensqo:
- Continues to use existing MOC systems with integration to SAP and MDM,
- Activates SAP’s native MOC module and retires legacy systems,
- Implement a hybrid model, where the NPI process governs all product-related scenarios and MOC systems remain active only for non-product, operational or safety-related changes.
Recommendation
Adopt Option C – Hybrid Model (Recommended Approach).
The NPI solution will govern all product-related creation and modification scenarios within SAP. Corresponding workflows and templates in existing MOC systems will be deactivated for any process covered by NPI. Legacy MOC systems will continue to manage non-product changes, including operational, process-safety, environmental or site-level engineering modifications.
This model ensures a single source of truth for product governance while preserving local MOC control for safety and compliance and avoiding costly integrations or system duplication.
Background & Context
The NPI process defines the standardized pathway through which Syensqo brings a product from concept to commercialization, ensuring quality, compliance and business readiness. The NPI framework integrates R&D, Product Stewardship, Supply Chain, EHS and Finance functions through distinct lifecycle phases
NPI Process Summary
Phase | Purpose / Description | Key Outcomes / Deliverables |
|---|---|---|
Feasibility / Solution Development | Research, formulation and initial recipe design to meet target requirements. | Defined composition (BOM), processing parameters, lab-scale validation. |
Pilot | Practical evaluation of feasibility under lab or pilot-scale conditions. | Confirm product concept viability, generate early data for scale-up |
Scale-Up | Transfer of validated composition and process to production assets under standard conditions. | Confirm manufacturability and cost structure, finalize recipe and FMEA. |
Industrialization | Full production with operational ownership; validate robustness and repeatability. | Process validation, qualification batches and readiness for commercialization. |
Commercialization | Product launch, costing and replication to downstream systems. | Product release, market activation and compliance documentation. |
Each phase governs the controlled creation and modification of key product master objects:
- Unpackaged Product (ZBAS): Represents intrinsic composition and compliance identity.
- Packaged Product (ZDIR): Represents marketable form, including packaging, labeling and transport attributes.
- Raw Material Readiness: Controls supplier qualification and material changes.
- BOM & Recipe: Defines approved composition and manufacturing resources.
- Product Hierarchy: Structures Product Family → Line → Group → Commercial Product relationships.
Historically, product-related changes were often processed through local MOC systems, leading to inconsistent governance, duplicate data maintenance and integration gaps. The NPI process now offers an enterprise-level alternative for product lifecycle governance integrated natively within SAP.
Assumptions
- The NPI business process covers all defined product lifecycle scenarios.
- SAP’s native MOC module remains inactive; activation would only occur if a full global migration of all MOC processes was undertaken.
- MOC systems currently manage site-specific process-safety, environmental and operational changes that are outside NPI scope.
- Each legacy MOC would require separate integration with MDM and S/4HANA if retained for product workflows.
- Hybrid approach allows clear functional demarcation without disrupting safety or compliance processes.
Constraints
- NPI does not manage operational, maintenance or asset-level change workflows.
- Legacy MOC coexistence required during NPI cutover for in-flight product changes.
- Local regulatory documentation may need to be retained in existing MOC systems for audit purposes.
- User training required to enforce correct usage boundaries between NPI and MOC.
Impacts
Process Impact
- NPI becomes the authoritative process for all product lifecycle governance.
- MOC systems focus solely on non-product, safety, and operational changes.
- Reduces duplicate data entry and approval steps.
System Impact
- Simplifies integration landscape by removing redundant MOC-to-SAP interfaces.
- Strengthens traceability through native SAP data flows (EHS, GTS, Product Compliance, Salesforce).
Data & Migration Impact
- Product change records in MOC will be retired or closed before NPI go-live.
- Historical data archived in compliance repositories.
Governance Impact
- Global Product Lifecycle governance owned by NPI Process Owner.
- Site MOC Coordinators maintain accountability for local operational changes.
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
List the options (viable options or alternatives) you considered. These often require a longer explanation with diagrams, or references to other documents (links are best, but attachments are also possible). Use enough detail to adequately explain what you considered so that a project or business stakeholder reviewing this decision will not come back and ask "did you think about...?"; this leads to loss of credibility and questioning of other decisions. This section also helps ensure that you considered enough suitable alternatives rather than just copy/pasting SAP's recommendations.
Option A: Option Title
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Option B: Option Title
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Option C: Option Title
Describe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Option D: Option Title
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 |
|
|
|
|
| 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.
