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:

1. Continues to use existing MOC systems with integration to SAP and MDM,
2. Activates SAP’s native MOC module and retires legacy systems,
3. 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

Each phase governs the controlled creation and modification of key product master objects:

• Unpackaged Product (ZBAS): Represents the core chemical identity of a product, capturing intrinsic physical and chemical properties, composition and compliance-relevant information. This object underpins all regulatory data (SDS, HS Codes, labeling classification) and forms the foundation for all downstream commercial and compliance activities. It is created during the Feasibility and Scale-Up phases and remains the reference entity throughout the product’s lifecycle.
• Packaged Product (ZDIR): Represents the marketable, saleable form of the product and inherits its composition and regulatory attributes from the corresponding Unpackaged Product. It governs all packaging, labeling and transport configurations (pack size, packaging materials, dangerous goods classification). The Packaged Product becomes active during Industrialization and Commercialization phases once packaging and logistics parameters are finalized. It is the entity extended to Sales and Distribution, Inventory and Customer systems.
• Raw Material Readiness: Encompasses supplier and raw material qualification processes managed through NPI. It ensures that all raw materials used in product formulations have completed the necessary quality, compliance and sourcing validation. This process governs new raw material creation, supplier change approvals and plant or country extensions, linking directly to Procurement and Product Stewardship functions.
• BOM & Recipe: Defines the approved product composition and its associated manufacturing resources (equipment, process parameters and routings). BOMs and Recipes are only generated and released through the NPI process once a product has passed feasibility and scale-up validations. This ensures that only verified and approved formulations enter production environments, maintaining strict control over change traceability, versioning, and master data consistency.
• Product Hierarchy: Provides structured classification of all products from Family → Line → Group → Commercial Product. This hierarchy links directly to master data replication and financial reporting structures in SAP, enabling clear lineage from development product to marketable SKU.

Historically, these product elements were partially governed through local MOC systems, with product changes (composition, specification, or packaging) processed independently of SAP. This created significant challenges including: 

• Inconsistent versioning of master data across sites.
• Duplicate approvals between MOC and SAP processes.
• Fragmented audit trails and non-aligned compliance documentation.
• Manual data maintenance and delays in replication to downstream systems.

The NPI process now provides an enterprise-level, SAP-integrated governance mechanism for managing all product lifecycle activities — from concept definition to commercialization — ensuring:

• Single-source data ownership
• Automated compliance replication
• Controlled workflows with global visibility
• Seamless traceability across all product creation and modification events.

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

1. All product creation and modification must be executed through the NPI process.
2. MOC workflows covering product specifications, formulations, packaging or market extensions will be disabled post-NPI go-live.
3. Operational and safety-related changes remain within site MOC systems.
4. Any functional gaps outside NPI’s scope will remain in MOC until future NPI enhancements.
5. Governance roles, data ownership and change boundaries to be defined in the NPI–MOC demarcation matrix.

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: Continue Using Existing MOC Systems (Full Integration with MDM and S/4HANA)

Retain all existing site-specific MOC systems for managing both product and operational changes. Each MOC platform would be integrated with the Master Data Management (MDM) layer and the multiple S/4HANA instances (ROW, CUI, China). Product changes would continue to originate in MOC, with approved data replicated to SAP post-approval.

Benefits

• Minimal business disruption: Existing MOC tools and user familiarity are retained.
• Regulatory continuity: Maintains current workflows aligned with local EHS and compliance frameworks.
• Short-term implementation ease: Avoids re-training or process redefinition at go-live.
• Localized autonomy: Sites maintain flexibility to manage process-safety and quality changes within familiar environments.

Limitations

• Integration complexity: Requires multiple custom interfaces to MDM and S/4, increasing cost and maintenance overhead.
• Data synchronization risk: Asynchronous updates may cause data misalignment or versioning errors between MOC and SAP.
• Governance fragmentation: Duplicated approvals and inconsistent master data ownership undermine single-source-of-truth principles.
• Limited scalability: Legacy technologies and decentralized control inhibit automation, analytics and standard reporting.
• Contradiction with program principles: This model diverges from SyWay’s global standardization and data governance vision.

Option B: Activate SAP MOC Module (Full Centralization in S/4HANA)

Activate SAP’s MOC module to replace all legacy MOC systems, consolidating product, process and operational change management into a single unified platform within S/4HANA.

Benefits

• Single governance framework: End-to-end change management integrated with SAP master data, Product Compliance and EHS modules.
• Complete traceability: Unified audit trail, approvals and document management across all change types.
• Enhanced reporting: Native alignment with SAP Analytics Cloud for enterprise-level transparency.
• Future-readiness: Creates foundation for digital twins, predictive maintenance, and sustainability compliance tracking.
• Elimination of legacy maintenance: Decommissions all local systems, reducing IT overhead.

Limitations

• High implementation cost and effort:Requires new global design, configuration and extensive change management.
• Timeline and resource impact on current project plan
• Functional coverage gaps:Standard SAP MOC does not natively support all site-specific process-safety and regulatory nuances without customization.

Option C: Hybrid Model (NPI for Product Changes, MOC for Operational/Safety Changes)

Adopt a hybrid governance model where all product-related creation and modification scenarios are controlled under the NPI business process, while existing MOC systems continue to manage operational, safety and plant-level changes.

Overlapping MOC workflows related to product data are deactivated post-NPI go-live.

Benefits

• Governance clarity: Distinct boundaries between product governance (NPI) and safety/operational governance (MOC).
• Alignment with SyWay principles: Supports single-source master data, standardized workflows and controlled replication across SAP modules.
• Business continuity: Retains local MOC systems for essential safety and environmental change tracking.
• Scalability: Provides a pathway for future convergence to SAP MOC when business readiness and NPI maturity allow.
• Reduced duplication: Eliminates parallel workflows for product changes, improving efficiency and audit compliance.
• Accelerated value realization: Enables global standardization without waiting for total MOC re-platforming.

Limitations

• Both SAP and multiple legacy MOC's systems will coexist, requiring clear procedural demarcation and governance documentation.
• Dependence on NPI coverage: Any gaps in NPI functionality must be managed through legacy MOC processes.
• User education requirement: Training and communication needed to ensure correct system usage and change classification.

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