| Status | |
| Owner | |
| Stakeholders | The persons consulted or otherwise involved in making this decision. Type @ to mention people by name |
The ERP Rebuild project will introduce SAP S4/HANA as the the ERP system for Syensqo, instead of the current different ECC systems. Meanwhile, Sysensqo is running a project to introduce an external planning system: Maestro.
We must define the boundaries between S4 HANA and Maestro functionalities and the data flows to be implemented between the 2 systems.
The planning process is composed by the following elements:
The following pictures shows how the steps can be executed in the different systems:
Option A

Maestro is used for S&OP, DM, MRP and Detailed Scheduling, S4/HANA is used for Order Management, S4/HANA and/or MES is used for Shop Floor control, depending on the MES system functionalities available for each plant / production line. In this option the transactional data flow from Maestro to S4/HANA will include Firmed and Dispatched Planned Orders.
Option B

Similar to Option A, but here S4/HANA takes care also of Detailed Scheduling, via PP-DS functionalities. While Maestro will run MRP, we keep the option open to run MRP also in S4/HANA. This can be defined for a subset of products, by plant choice. We will have anyway MRP running for maintenance related parts, spare parts and other indirect materials. In this option the transactional data flow from Maestro to S4/HANA will include Firmed Planned Orders (not Dispatched).
Option C

Here we open up the possibility to manage MRP and Detailed Scheduling both in Maestro and S4/HANA. This will allow each GBU or plant to pick up the system that suits them better and increase the flexibility of the planning model used by Syensqo, to leverage the best of both systems.
The complexity of the interface is higher in this option, as we must design a flexible data flow from Maestro to S4/HANA; able to send Planned Independent Requirements, Firmed Planned Order, or Firmed and Dispatched Planned Orders, depending on the system used by each plant for MRP and for Capacity levelling.
Option B is the recommended one: Maestro will take care of S&OP, Demand Management and MRP. This includes Sales Forecast, Customer Requirements, Indepndent Requirement and high level production plan. S4/HANA will be the master system for Production Planning and FIne Scheduling, via MRP and PP/DS functionalities.
At the moment in Syensqo the tools and methods for production planning are not harmonized:
S&OP happens in some cases in Dynasis, in many cases in Google Sheets or local tools. The same is valid for Demand Management.
MRP is mostly running in SAP ECC, even though it is largely used by some plants, almost ignored by others, that are replanning manually their production ignoring MRP results.
Fine Scheduling and Capacity Levelling is performed in Google Sheets, Local Tools or just manually.
Shop Floor management (urgencies, outages, last minute changes) are managed mostly visually directly in the shop floor and are visible only after actual confirmations.
The scope of Maestro project (Kinaxis) is to substitute Dynasis and provide a unique standard tool for S&OP and DM across all Syensqo.
Maestro Project does not include Fine Scheduling and Capacity levelling at the moment.
Important to note that other external systems, like Google Sheets, Excel, local tools, are not part of the model anymore, each plant will identify S4/HANA or Maestro as the MRP and Fine Scheduling system. This is valid for all 3 options.
Order Management must be in S4/HANA as this is the system where Product costing and Actual costing happen.
S4/HANA will be also the master system for Process Orders / Production Orders towards all MES different systems, likewise current MES systems.
Describe the impact of the decision on other aspects such as other processes, infrastructure, other SAP modules or systems, data cleansing and migration, developments, automations, interfaces, in-flight projects, etc.
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".
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.
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
Decribe the option in sufficient detail for a reader familiar with the subject matter to understand it properly
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 |
|
|
| |
| Criterion 3 |
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.
