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 adjust the existing APS system design 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.

As-Is

Scope

APS project includes the following functionalities:

• 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 categories listed above. A high level view of the scope of the APS project can be found 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 line and it is comprised of both the ECC's systems

Below is the detailed list of the interfaces

System Architecture

High-Level Architecture: Integration of Kinaxis with Existing SAP ECC Systems

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

Changes in Scope

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

Functionality

The following topics are identified as potentially requiring changes in APS solution during the ERP Rebuild project. Note that the below table represents only the functionalities that require a change. The total list of functionality that is in scope can be found in the attachments.

 Data

The following topics are identified as potentially requiring changes in the APS data structures/data sources during the ERP Rebuild project. Note that the below table represents only the functionalities that require a change. The total 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 alignment in process, data and integration across the new design.

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

System Architecture

Below is the proposed To-Be system architecture including some of the key elements to note 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 established to support this configuration.
• 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.

Time Phased System Diagram

There are two views to represent the need for different systems at different phases of the program. Both these views are outlined below.

The fist view represents the timeline view. This diagram below illustrates the time-phased instance strategy for the APS Project and ERP Rebuild Project. The diagram is divided into two sections: APS (at the top) and ERP Rebuild (on the bottom), reflecting their respective project timelines.

Instances are represented within the diagram to show how they are aligned with each phase of the APS and ERP Rebuild projects. These instances are mapped to the respective project timelines to reflect key milestones, implementation phases, and decision points. The staggered deployment of these instances represent the different system needs of each phase and outlined the need for parallel instances to be available for each overlapping phase.

The second view is the system landscape view. These are also split by project phase represented by the green bar.

Below is the detailed representation of the instances along with the transportation path. The left side of the pictures represent the APS project landscape requirements while the right side of the pictures represent the ERP rebuild landscape requirements.

Integration with key functionalities

Planning Data in S/4

Planning data from Maestro is required in S/4 at each day level 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, ensuring that the system operates efficiently within the constraints of the planning time fence.

Aggregation of data at weekly or monthly buckets is planned beyond the short-term horizon. However, this approach needs to be confirmed during the detailed design phase, based on various other factors such as ATP (Available to Promise) requirements.

• For planning beyond the short-term horizon, data will likely be aggregated into larger intervals, such as weekly or monthly buckets. This simplifies data management and focuses on long-term trends. However, the final aggregation strategy will be determined during the detailed design phase, considering factors such as ATP requirements and other operational dependencies.

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

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 planning processes and manage larger time frames efficiently.

During the detailed design phase, the following topics should be considered:

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

• PPDS
• Factory Scheduling

Cutover Approach

Following are some of the important considerations for cutover

• The Existing APS Production System Will Not Be Used for Go-Live During the ERP Rebuild Project:
  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 Instance:
  To ensure continuity and historical reference during the cutover to the new instance, planning history will be migrated 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 1st and 2nd Deployment

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.

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

Governance / Resources 

Following are some of the Governance Principles proposed for the project

• Dedicated design and development Maestro / Business teams to be embedded in the ERP Rebuild project team
• Change freeze of APS post drop 3