ERP/MES/QMS Process Orchestration — How to Prevent the Three Systems from 'Clashing'

Summary: ERP manages orders, MES manages production, and QMS manages quality. Each system writes its own data, and it’s only at the end of the month that inspection results reveal abnormalities—this is a common pain point in the digital transformation of most manufacturing enterprises. This article examines the data flow relationships, common conflict scenarios, and actionable integration solutions from a process orchestration perspective.

1. Case Study: A Nonconforming Product Handling Form Takes a Six-Day 'Long March'

A full inspection process at an automotive parts factory discovered a batch of products with dimensional deviations. The quality inspector issued a nonconforming product handling form in the QMS. According to the procedure, the form should be sequentially approved by the quality supervisor, analyzed by the technical engineer, followed by production plan adjustments, warehouse freezing, and financial deductions. Ideally, this process should be completed within 4 hours.

In reality: After the nonconforming form is approved in the QMS, it requires manual notification to the production planner to lock the inventory in ERP, and then to the MES to pause the production scheduling of the corresponding process. Finally, the workshop kanban must be manually updated. The systems lack process linkage, relying entirely on manual information transfer. As a result, the batch of products continued to be processed in MES, leading to 300 units requiring rework.

This is not a problem of having too few IT systems but a typical consequence of lack of process orchestration among the systems.

2. Differences in the Positioning of ERP, MES, and QMS

The three systems are essentially designed to meet different levels and time granularities of management needs:

Key Insight: These three systems are not substitutes but complements. ERP tells MES what needs to be done today, MES informs ERP what has actually been done, and QMS verifies at each inspection point whether the work is done correctly, feeding back nonconforming information to MES and ERP for closed-loop handling.

3. Five High-Frequency Conflict Scenarios and Orchestration Solutions

Scenario One: Incoming Inspection Triggers Receipt

Where Does the Conflict Lie?

When a purchase order arrives in ERP, the warehouse must wait for the incoming quality control (IQC) results from QMS to confirm receipt. The result: the inspection results in QMS have already been deemed acceptable, but the order in ERP remains in a 'pending inspection' status. The warehouse cannot proceed with subsequent storage and shelving, and the procurement department cannot confirm whether the batch payment should enter the payment process. Worse still, if the material is urgently needed, the production line is waiting for the material to start, and every additional hour of waiting translates into real financial losses due to production line downtime.

Orchestration Solution:

Purchase Arrival → ERP Creates Pending Inspection Status → QMS Assigns Inspection Task
   ↓ (Inspection Completed, Results Transmitted)
ERP Automatically Completes Receipt + MES Automatically Releases Inventory Availability

Key Implementation: When the inspection in QMS is completed and deemed acceptable, an 'inspection confirmation' signal is pushed to ERP via API, along with necessary fields such as the inspection report number, batch number, and quantity. If nonconforming, it triggers the ERP return process (generates a return order) and simultaneously notifies MES to freeze the batch, preventing it from being used in production.

During the transition period when real-time API integration is not feasible, an intermediate table solution can be set up: QMS writes the inspection results into the iqc_result table in a shared database, and ERP queries this table every minute. Upon discovering a qualified record, it automatically executes the receipt action. Although there is a delay of about one minute, it is far superior to the manual handling that can take hours or even days.

Scenario Two: Process Inspection Triggers Line Stop/Resume

Where Does the Conflict Lie?

QMS identifies a process anomaly and determines that the production line needs to be stopped for rectification. However, MES continues to schedule production according to the original plan because it has not received the stop signal.

Orchestration Solution:

QMS Identifies Anomaly → MES Pauses Corresponding Process/Work Order
   ↓ (Rectification Completed)
QMS Verifies Compliance → MES Resumes Scheduling + ERP Records Adjusted Man-hours

The core here is: MES must expose a 'line status control' interface, and QMS should directly write the anomaly determination into this interface, bypassing manual relaying. If MES does not open this interface, a secondary solution is to automatically push a 'recommended line stop' work order to MES operators after QMS determination, which they can confirm with a single click.

Scenario Three: Nonconforming Product Handling Across Systems

Where Does the Conflict Lie?

After the nonconforming product handling form completes the approval process in QMS, subsequent actions (inventory freezing, work order rework, cost recalculation) that need to be executed across systems remain at the 'manual notification' stage—System A completes the task, but System B is unaware.

Orchestration Solution:

Establish a unified 'nonconforming product handling event' broadcast mechanism:

Scenario Four: Change Notification Affects Work-in-Progress

When an engineering change (ECO/ECN) is approved in QMS, the scope of impact may include:

• Unstarted purchase orders in ERP need to switch to new materials
• Work-in-progress in MES needs to be evaluated to determine whether to continue processing or switch immediately
• Old materials in the warehouse that have been stored but not yet used need to be frozen or returned to the supplier

The complexity of this scenario lies in: different change types (material change, process change, specification change) have completely different impact assessment rules for work-in-progress, making it difficult to cover with a unified script. Most companies adopt a semi-automatic mode of 'QMS approval → automatic calculation of affected orders → manual confirmation of each item' to balance efficiency and risk control.

Orchestration Solution:

QMS Change Approval Passed → Automatic Impact Scope Scan
   ↓ (Match by Material/Work Order Number)
ERP Marks Affected Purchase Orders + MES Marks Affected Work-in-Progress
   ↓
Differential Handling: Use Up / Rework / Scrap, Results Transmitted to QMS to Form a Change Closed Loop

Scenario Five: Automatic Collection of Supplier Performance

QMS accumulates a large amount of incoming inspection data, but supplier performance scores are still manually calculated by the procurement department using Excel.

Orchestration Solution:

QMS Incoming Inspection Pass Rate → Monthly Automatic Aggregation
   ↓
ERP Corresponding Supplier Record → Automatic Update of Supplier Performance Score
   ↓
Score Below Threshold → Automatic Trigger of ERP Supplier Freeze + Sending Improvement Requirements

Real-time linkage is not necessary for this scenario; batch processing is sufficient (daily/weekly regular synchronization). The key is consistent data standards—supplier codes in ERP and QMS must align, otherwise, performance data will not correspond to the correct supplier.

4. Modes of Process Orchestration

For small and medium-sized manufacturing enterprises, it is not recommended to start with ESB or message queues—first, identify 5-8 core cross-system processes, use point-to-point APIs to ensure data flows correctly, and then consider introducing a unified orchestration platform. Address the chaos first, then introduce the tools.

5. Four-Step Method for Implementing Process Orchestration

Step One: Draw Cross-System Process Maps

Select 3-5 high-frequency cross-system scenarios (such as incoming inspection, nonconforming product handling, change management), and draw L2-level process maps, clearly defining which system and role each node belongs to, and what the inputs and outputs are.

Key Output: Cross-system process 'swimlane diagram', with each swimlane corresponding to a system, and data interfaces and formats annotated in the channels.

Step Two: Inventory Existing System Interface Capabilities

Compare the process maps and check the API capabilities of each system:

• Does ERP open an order status modification interface?
• Does MES provide a production line control interface?
• Can QMS proactively push events?

For systems that do not open interfaces, consider the following alternatives: system script automatic operations (RPA), database triggers (read-only database synchronization), and manual confirmation nodes (system pushes pending tasks for operators to confirm and execute). However, each alternative solution means adding a 'manual gear' to the orchestration chain.

Step Three: Roll Out According to Priority

It is recommended to prioritize based on the principle of 'high frequency + high risk = priority'. The priority matrix has frequency (daily/weekly/monthly) on the horizontal axis and impact level (causing line stop/ causing rework/ just efficiency loss) on the vertical axis:

1. Incoming Inspection → Receipt (daily frequency, high impact) — This is the scenario where 'waiting for material to stop production' is most likely to occur and is the entry point for many companies.
2. Nonconforming Product → Freeze/Rework (weekly frequency, high impact) — Timely inventory freezing is crucial to prevent nonconforming products from being further processed.
3. Engineering Change → Work Order Notification (monthly frequency, medium impact) — Although the frequency is not high, the impact is broad, and a well-handled set of rules can cover 80% of change scenarios.
4. Supplier Performance → Automatic Evaluation Update (monthly frequency, low impact) — This has low time sensitivity and is suitable for the last batch of rollouts.

Step Four: Establish Runbooks and Exception Handling

The biggest risk in process orchestration is: if the automation chain breaks, no one knows. Create a Runbook for each orchestration process, clearly defining:

• What signals confirm normal flow (monitoring indicators)
• Who and within what time frame will intervene if the chain breaks
• What the manual downgrade process is (when the system is unavailable)
• Automatic retry mechanisms and retry limits

6. Common Failure Reasons

Reason One: Only Data Synchronization, No Process Synchronization

Many companies interpret system integration as 'data being copied from one database to another', neglecting the state synchronization required for process orchestration. For example, ERP receives the inspection pass data from QMS but does not trigger the state change from 'pending inspection' to 'confirmed'. As a result, subsequent financial settlement processes will not be automatically triggered.

Correction: Each data interface should include explicit state migration instructions, not just data copying.

Reason Two: Orchestration Logic Hardcoded in a Single System

Some companies implement all cross-system process logic in custom QMS development. When QMS is upgraded or switched, the entire orchestration network collapses.

Correction: Orchestration logic should be located outside the systems—either in an ESB/integration platform or in an independent process engine, with each system exposing atomic operation interfaces.

Reason Three: Neglecting Monitoring of Exception Frequencies

'Automation has run for three months without any issues' is not the correct way to evaluate orchestration quality. The right questions to ask are: How many retries are there in the middleware logs? How many exceptions require manual intervention? How many times has the data pushed from QMS to ERP been modified on the spot? During a customer audit, it was discovered that over 200 nonconforming forms were not received by ERP due to interface timeouts, and neither QMS nor ERP was aware of this until the customer traced it—this is not a functional issue but a complete lack of visibility into exceptions.

Correction: Set KPIs for the exception rate and number of manual interventions for each orchestration process, and continuously monitor and improve. It is recommended to display at least the following indicators on the integration dashboard: interface success rate, average response time, number of exceptions, number of pending manual interventions, and last successful run time. Set alarm thresholds for each indicator, triggering notifications when the success rate falls below 98%.

The ultimate goal of system integration is not to have 'data in one place', but to ensure 'people are not the messengers'.

Knowledge Number: 3.5.3

Version: v20260716

Author: Quality Excellence Think Tank The Quality Excellence Think Tank is dedicated to providing systematic professional knowledge, methodologies, and practical tools for quality management practitioners, helping companies continuously improve their quality capabilities.