Issue

A request was made by the Syensqo Manufacturing excellence team to consider the option of having one Quality system across Syensqo.

Rationale behind the request:

• No Standardized process within and across the GBUs.
• The specifications are not same in 2 different plants for the same product for example PVDF in Tavaux  and in Changzhu.
• For the above reason, In several cases, analysis of CPK, SQC analysis across the 2 different sites are not possible.

      the values does not match because the labware is set up in different ways.

• No standardized reports possible within the plants in a GBU and across GBU .
• Currently Labware is configured in a way which the local sites want to define it.
• In Labware / Web LIMS the Samples are generated manually without any trigger from upstream processes, resulting in a lack of control and  process integration.
• In Labware / Web LIMS the operator can freely define whether execute a test or carry over previous results, without any predefined control.

Options available:

Following are the options proposed:

Option 1  – As-Is Approach

Under this approach, each GBU continues operating its existing Quality Management setup. Different LIMS versions and configurations remain in use across sites, which means data structures, reporting formats, and inspection results will continue to vary.

What does it mean for Sy-Way/Business:  No Process/Data Standardization , Difficult to implement Process Controls, Minimal Change / Training Impact, Minimal Risk , No resistance from Business, Difficult to implement central QM organization, Multiple systems

Option 2 - Hybrid Approach (CM As-Is / P&C and SpP Standardized)

Under this approach, Composites  retains its current configuration (“As-Is”), while other GBU’s  standardize their quality processes and integrate with SAP S/4HANA. This hybrid model promotes partial standardization while reducing disruption to ongoing CM operations. This option will also enable Syensqo to roll out a centralized Quality Management Organization.

What does it mean for Sy-Way/Business: Process/Data Standardization(Except CM) , Process Controls can be implemented(Except CM), High Change / Training Impact, High Risk , High resistance from Business, Can implement central QM organization(Except CM), Multiple Systems (SAP and Labware)

Option 3 – Technology Standardization (All GBUs Move to different LabWare systems, no Process changes in Labware)

This option envisions a complete migration where all GBUs (including P&C, SpP, and CM) move to a unified LabWare Technology(One instance for CM and other instance for rest of GBU’s). This option acknowledge the possibility for P&C to unify their plants in the current Labware implementation, removing WEBLIMS.

What does it mean for Sy-Way: No Process/Data Standardization , No Process Controls, Low Change / Training Impact, Low Risk , Low resistance from Business, Can implement central QM organization(Except CM), Multiple Systems (SAP and Labware), savings on effort are we remove WEBLIMS interfaces

Option 4 – Full Process Standardization (All GBUs Move to unified Labware Design)

This option envisions a complete migration where all GBUs (including P&C, SpP, and CM) move to a unified LabWare Design (One instance for CM and other instance for rest of GBU’s).. Quality processes would be fully standardized across the enterprise, ensuring consistent data structures, harmonized reporting formats, and a single source of truth for all inspection results. It requires a deep redesign of the Labware implementation.

What does it mean for Sy-Way: Process/Data Standardization(with some process variants for CM) , Process Controls can be implemented, High Change / Training Impact, High Risk , Medium/Low resistance from Business, Can and need to implement central QM organization, Single System (Labware)

Background & Context

Current Status and Challenges:

Syensqo currently operates with a distributed Quality Organization, where quality management responsibilities, processes, and systems are spread across multiple business units and sites. Over time, each GBU/plant has implemented its own technology landscape, leading to the coexistence of different Quality Management Systems, LIMS, and data management tools.

• Lack of Standardization Across GBUs and Sites
  • There is no standardized process within or across the Global Business Units (GBUs)
  • Specifications for the same product differ between plants — for example, the PVDF product in Tavaux and Changzhu plants is defined differently.
    As a result, cross-site analyses such as CPK and SQC cannot be performed consistently.
  • Measured values vary because LabWare configurations and test setups differ across sites.
    
    
• Inconsistent Reporting and Configuration
  
  
  • It is not possible to generate standardized reports either within a GBU or across GBUs due to differences in local configurations.

• • LabWare and WebLIMS is currently configured independently by each site, based on local preferences and practices, leading to inconsistent data models and test definitions.
    
    
• Lack of Integration and Process Control
  
  
  • In LabWare / WebLIMS, samples are created manually without any trigger from upstream processes (e.g., production, batch release, or quality notification).
    • This results in a lack of integration and limited traceability between quality results and operational data.
  • Operators can manually decide whether to execute a test or reuse previous results, with no predefined system controls or approval steps, creating risks in data integrity and compliance.

link: GBU Site wise analysis

link: Equipment list 

Impacts

R&I and S2S

1) Product industrialization

Once a test product becomes an industrial product, the industrial product specs are created in Labware and SAP for the production site --> in future this would be done in SAP only, no issue

 2) Tests done for sites by R&I labs on commercial products (SpP)

The results are shared to the site using G Drive/Aodocs  ->  no issue

The initial request is done by the site directly in Labware using a specific role --> 2 options, each site keeps one role in Labware for this, or sends the request to the R&I lab in another way (online form...)

Bertrand will check what volume of samples/tests is at stake here. 

3) Environmental testing

For example in Spinatta, 2 samples are created, one for the site, one for Bollate. Once Bollate has completed its tests, the site copies them to their sample, so everything is in one place. 3 options: the environmental lab in Spinetta continues to use Labware (it's a specific lab dedicated to environment); the site gets the Bollate results through a G Drive or equivalent and enters them in SAP; or the R&I lab enter the results in SAP (the current Labware setup can be replicated in SAP). 

Volume at stake: 100/150 samples per month 

4) Inovyn in Tavaux

This is not related to R&I but a side note that if we decide to eliminate Labware in SpP, the contract with Inovyn will have to be updated to include data entry in SAP QM

There may be other cases with interaction between the sites & R&I Labware, but around the table we didn't have an exhaustive view, the consensus is that above the most critical ones are listed.

R&I - product development phase - R&I for R&I

R&I for Industrial - will remain As- IS - this part will move to SAP QM  and Lab equipment connected will be taken into consideration

R&I - Analysis for customer complaints - this is done in G sheet 

Side note - R&I process can be standardized by moving everything to OneLIMS (Agilab)

Option considered

Option 1  – As-Is Approach

Under this approach, each GBU continues operating its existing Quality Management setup. Different LIMS versions and configurations remain in use across sites, which means data structures, reporting formats, and inspection results will continue to vary.

This is after carefully considering each options and its impacts on the cost, timelines and change impacts. the options were presented to Steerco on 26th Nov 2025 and the decision was endorsed to go with Option 1.

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.

See also

Change log