Purpose

The Sales and Operational Planning (S&OP) processes and activities are an essential and strategic element of the ERP Rebuild project scope and design therefore, playing a pivotal role in the overall success of the project.

In parallel to the ERP Rebuild program, the Advanced Planning and Scheduling (APS) project is currently in progress and being executed concurrently, utilizing the Kinaxis Maestro tool (a leading S&OP software solution), to implement a product planning process and solution including the Demand Planning and Sales and Operational Planning functionalities within the Syensqo business.

This document serves as a guide, designed to offer an understanding of the current "As-Is" planning processes, the "As-Is" integration mechanisms, and the "As-Is" overall system landscape associated with the Maestro system, all within the scope of the APS project.

Additionally, this document aims to identify and highlight the changes required to ensure that the APS solution aligns seamlessly with the ERP Rebuild project’s goals, objectives and timelines. It outlines the potential adjustments and modifications needed to the existing APS system design and build to accommodate the ERP Rebuild related processes and solution changes. Furthermore, this document provides a detailed vision for the future state of the integration and system landscapes, showcasing how the APS and ERP systems will function cohesively after the rebuild program is complete. A proposed approach for data cleansing and cutover, aligned with the ERP rebuild design, is also included.

Table of Contents

Assumptions

The information in the document is based on the APS design known at the time of writing the document. This document will be reviewed and updated during the ERP Rebuild detailed design (After APS design is completed and in case of significant changes).

As-Is

ERP Rebuild Scope

The ERP Rebuild Project encompasses a total of nine processes within its end-to-end scope. Below is a brief summary of each process to provide an overview of the project’s comprehensive scope and objectives.

The following end to end processes will integrate with planning process in scope for the APS project:

• Plan to Fulfil
• Lead to Cash
• Budget to Forecast
• Source to Pay

Maestro Scope

APS project includes the following processes:

• Demand Planning
• Supply and Inventory Planning
• Production Planning and Scheduling
• S&OP / IBP

APS project is planned to be deployed in Drops with each drop delivering enhanced functionality of the processes listed above. A high level view of the scope of the APS project is described below:

Below is the split of the functionalities across multiple drops.

Interfaces

Multiple interfaces are required to connect the Maestro system with existing SAP ECC (ERP Central Component).

These interfaces will facilitate data exchange and integration between ECC and Maestro, supporting critical business processes such as planning, inventory management, order fulfillment, and reporting. They can be categorized into the following:

Below is an overview of the interfaces.

Note: ECC is represented as one bar and it is comprised of both the ECC's systems

Below is the detailed list of the interfaces

System Architecture

High-Level Architecture: Kinaxis integration with Existing SAP ECC Systems

The architecture for the Kinaxis Maestro system uses two productive instances, one for the composite business (Maestro US) and another for the rest of the business (Maestro ROW).

The integration of the Kinaxis system with the existing SAP ECC systems need to take into account the two distinct Kinaxis instances to support different business needs and geographical requirements:

1. Kinaxis US:

   • This instance will primarily serve the composites GBU (Global Business Unit).
   • It will facilitate compliance with export control regulations, specifically ITAR (International Traffic in Arms Regulations), ensuring all ITAR-related processes are managed effectively.
   • Hosting Location: This instance will be hosted in the United States to meet ITAR compliance requirements and regional data governance standards.

2. Kinaxis ROW (Rest of the World):

   • This instance will support the other GBUs, including Aroma, Novecare, TS, O&G (Oil & Gas), and Specialty Polymers.
   • The ROW instance will manage planning, supply chain, and operational data for these GBUs while aligning with the broader strategic goals.
   • Hosting Location: This instance will be hosted in Europe, ensuring efficient regional operations and compliance with European data protection standards.

Both instances will integrate with the existing ECC systems to enable real-time planning, supply chain visibility, and data sharing across multiple GBUs while adhering to regional compliance and operational requirements.

To-Be

Impacts

A detailed analysis/comparison has been conducted on the functionalities and data structures to be deployed as part of the scope of the APS and the conceptual design from the ERP Rebuild Projects. The analysis has identified a range of changes that will be required to the current APS design and build in order to align with the ERP rebuild Functional, Data and Interfaces requirements. 

Process

The business processes defined as part of APS project will be adopted for ERP Rebuild. However a detailed assessment will be done during the detailed design phase to identify any gaps and address them accordingly.

Design 

The following topics have been identified as potentially requiring changes in APS solution to seamlessly integrate with ERP Rebuild project. The below table represents only the functionalities that require a change. The complete list of functionality that is in scope can be found in the attachments.

 Data

The following topics have been identified as  requiring changes in the APS data structures/data sources to enable seamless integration with ERP Rebuild project. The below table represents only the functionalities that require a change. The complete list of all the data elements can be found in the attachments.

Interfaces

Based on the current APS design and the ERP Rebuild conceptual design, the following interfaces are identified as requiring changes. These changes are necessary to ensure process and data alignment.

A detailed list of all the interfaces along with their specific changes is available in the attachments. 

System Architecture

Below is the proposed To-Be system architecture including some key elements when compared with the existing As-Is architecture

• Two S/4HANA instances will be implemented: one dedicated to China and another for the rest of the world. The Composites business will be divided across these systems.

• Data required for Composites planning from both S/4HANA systems will be integrated into the Maestro (US) instance, while data for the rest of the world will be routed to the Maestro (Global) instance.

• Two dedicated Cloud Platform Integration (CPI) systems will be deployed and configured to support this architecture.

• SAP Data Sphere will be used to consolidate and transfer data to the respective systems, limited to non-ITAR data only.

• ITAR-sensitive data will bypass Data Sphere and be directly exchanged between S/4HANA and Maestro.

Implementation Roadmap

The diagram below depicts the implementation roadmap for the APS Project and ERP Rebuild Project, including their respective system instances. The diagram is split into two sections: APS (at the top) and ERP Rebuild (at the bottom), representing their respective project timelines.

Currently, there is ideal alignment between the end of the APS project and the start of the ERP Rebuild Integration test. Any delays in the APS project or in ERP project timelines will be discussed in the planned Portfolio management meetings and/or other agreed governance forums to ensure continuous alignment. Once APS project is completed, ideally any further solution enhancements should cease in order to focus entirely on the ERP Rebuild project delivery. The freeze will maintain a clear and controlled environment during ERP Rebuild project deployments.

Time Phased Landscape Diagram

The following series of diagrams illustrate the time-phased system landscape view, segmented by project phases, as indicated by the green bars.

These diagrams provide a detailed representation of the system instances and their corresponding transport paths. The left side of each diagram represents the APS project landscape requirements, while the right side represents the ERP Rebuild landscape requirements.

(note: the coloured squares represent the Maestro instances while the white ovals represent the ERP instances - a legend of the ERP instance names can be found on the right hand side)

Key Open Design Topics

There are a number of key functional design topics that need to be discussed and agreed in detail design as they are foundational part of S/4 HANA.

Granularity of Planning Data in S/4 Hana

The Planning data from Maestro is required in S/4 Hana using the day as the smallest time bucket during the short-term horizon, i.e., before the planning time fence.

• During the short-term horizon, precise planning data at a daily granularity will be integrated from Maestro into SAP S/4HANA. This enables accurate and effective planning for production, purchasing and sales (ATP), ensuring that the system operates efficiently within the constraints of the planning time fence.

However, for longer horizons, the aggregation of data at a weekly or monthly bucket can be used beyond the short-term horizon. 

• For planning beyond the short-term horizon, data can likely be aggregated into larger time intervals such as weekly or monthly buckets. This simplifies data management (data volume across the interface) and focuses on more granular information in the short term and less granular in the long-term. The final aggregation strategy will need to be determined during the detailed design phase, considering factors such as ATP requirements and other operational dependencies.

Product Allocation (PAL)

Integration is required between the allocation in Maestro to the PAL tables in SAP. There is already a new interface included to cater to this requirement, however more details of how PAL table is structured will be determined during the detailed design phase.

Available To Promise (ATP)

ATP functionality in SAP requires up-to-date inventory information, production/procurement plans, and delivery priorities to determine accurate delivery dates.

This information will be readily available and detailed during the short-term horizon, ensuring precise commitments. However, for long-term horizons, the data will be aggregated to simplify the planning processes and manage larger time frames efficiently. (see "Granularity of Planning data" above).

During the detailed design phase, the following topics are discussed further:

• Using Replenishment Lead Time (RLT) instead of ATP for long-term horizon orders:
  For orders falling within the long-term planning horizon, RLT could be utilized to approximate availability dates. This approach reduces the complexity of ATP checks while providing reasonable delivery estimates based on predefined lead times for procurement or production.
• Using ATP for long-term horizon orders with aggregated data:
  An alternative approach involves continuing to use ATP functionality for long-term orders but leveraging aggregated data in less granular time buckets. This may require specific configurations or assumptions about inventory levels, production schedules, and other factors to enable effective ATP calculations despite the lower data granularity.

Enterprise Scheduling

There are a small number of plants that are large and complex enough to warrant the need for a more finite scheduling capability.

There are two options to fulfil this requirement:

• PPDS - SAP's native detailed scheduling engine
• Factory Scheduling - Detailed scheduling using the Maestro platform

In detail design, a decision tree will be defined with criteria that will determine if a manufacturing plant can benefit for detailed scheduling or not. Once this decision tree is agreed and the manufacturing plants assessed, either SAP or Kinaxis will be confirmed as the tool for detailed scheduling.

Cutover Consideration

A number of topics have been discussed in relation to the ERP Rebuild cutover approach:

• Use of Existing APS Production System for ERP Rebuild Go-Live:
  As part of the ERP Rebuild project's go-live strategy, the current APS production system will not be utilized. Instead, a new instance will be implemented to support the transition and operational readiness.

• Migration of Planning History to the New Production Instance:
  To ensure continuity and historical reference during the cutover to the new instance, planning history will be migrated to the relevant location as part of the cutover strategy. Two migration options have been identified, and the final choice will be determined during the detailed design phase:

  • Option 1: Extract only the historical key figures (e.g., demand trends, supply chain planning insights) and store them in Datasphere. This approach focuses on essential planning insights while minimizing data volume.
  • Option 2: Extract all source data, including Planned Orders, Purchase Orders, and other relevant transactional data, and store them in Datasphere. This option provides a more comprehensive historical data migration for extended historical analysis and operational continuity.

Interim Process between 2 ERP Rebuild Go-Lives

1. Specialty Polymers (SpP) and Global Supply Chain:
   The supply chain transaction overlap between the Specialty Polymers legal entities in scope for Group 1 and the Rest of Syensqo is minimal, based on the analysis conducted by the ERP Rebuild team. As a result:

   • The new ERP Rebuild Maestro Non Composites system can operate primarily with the Specialty Polymers (SpP) entities with only minimal manual adjustments required.
   • These adjustments will primarily involve Buy-Sell transactions with the global supply chain to ensure alignment and continuity.

2. Composites and Rest of Syensqo:
   The supply chain transaction overlap between Composites and the Rest of Syensqo is also minimal, as confirmed by the analysis conducted by the APS team. Therefore:

   • The Business As Usual (BAU) APS Composites Production system can continue to operate as-is without the need for interim processes or significant changes during the go live 1 of the ERP rebuild program.

3. Other Company Codes in the BAU Non-Composites Environment:
   For the remaining company codes within the BAU Non-Composites environment, the transaction overlap with the global supply chain is minimal. As a result:

   • These entities can continue operations with only minimal manual adjustments, specifically related to Buy-Sell transactions, to maintain alignment with the global supply chain network.

Below is an high level diagram to illustrate the interim period:

Governance 

Until the APS and ERP Rebuild projects will merge, planned for June 2026,  they will continue to be governed independently by their respective Steering Committees.

However, in order to ensure continuous alignment, the APS project leadership will attend the ERP Rebuild relevant meetings. The monthly Project portfolio meeting will be another forum where the alignment between the two parallel projects will be ensured.  

Once the 2 projects merge, the APS project director will become part of the ERP Rebuild leadership team, continuing to lead the Kinaxis team, under the ERP Rebuild project Steering Committee governance.

After the project merger, any changes in the APS project will follow the ERP Rebuild Change Request process.

Resources and Kinaxis Playpen system

ERP Project will require business and Kinaxis professional services resources to support, in the first instance , the Detail design phase. Kinaxis will also provide a free Kinaxis system to be used as playpen throughout 2025.

Attachments