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

Abstract: ERP manages orders, MES manages production, and QMS manages quality. Each system writes its own data, and inspection results are only discovered to be abnormal at the end of the month—this is a common pain point during the digital transformation of most manufacturing enterprises. This article examines the data flow relationships, common conflict scenarios, and implementable integration solutions from the perspective of process orchestration.

1. Case Study: A Nonconforming Product Handling Form Takes Six Days to Complete

A full inspection process at an automotive parts factory found a batch of products with dimensional deviations. The quality inspector issued a nonconforming product handling form in the QMS. According to the procedures, the form should sequentially undergo: quality supervisor approval → technical engineer analysis → production plan adjustment → warehouse freeze → financial deduction. Ideally, this should be completed within 4 hours.

In reality: After the nonconforming product handling form was approved in the QMS, it required manual notification to the production planner to lock the inventory in ERP, and then to notify MES to pause the production scheduling for the corresponding process. Finally, the workshop kanban had to be manually updated. —There is no process linkage between the systems, and information is entirely passed manually. 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 rather 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 to do today, MES tells ERP what was actually done, and QMS verifies at each inspection and control node whether the work was done correctly, and feeds 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 is the Conflict?

When a purchase order arrives in ERP, the warehouse waits for the incoming inspection result from QMS to confirm receipt. The result: the inspection result in QMS has already been determined as qualified, but the order in ERP remains in the "pending inspection" status. The warehouse cannot proceed with subsequent storage and shelving, and the procurement department cannot confirm whether the batch of goods should enter the payment process. Worse still, if the material is urgently needed, the production line is already waiting for the material to start, and every additional hour of waiting results in 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 determined to be qualified, 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 the inspection is不合格, it triggers the ERP return process (generates a return order) and simultaneously notifies MES to freeze the batch to prevent it from being used in production.

During the transition period when real-time API integration is not possible, 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, ERP automatically executes the receipt action. Although there is a delay of about one minute, it is far superior to manual operations that take several hours or even span days.

Scenario Two: Process Inspection Triggers Line Stop/Resume

Where is the Conflict?

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

Orchestration Solution:

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

The core here is: MES must expose a "line status control" interface, and QMS directly writes the anomaly determination into this interface, bypassing manual relaying. If MES does not open this interface, a secondary solution is to automatically push a "suggested line stop" work order to the MES operator after QMS determination, which the operator can confirm with one click.

Scenario Three: Nonconforming Product Handling Across Systems

Where is the Conflict?

After the nonconforming product handling form completes its approval flow in QMS, the subsequent actions (inventory freeze, 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 Notifications Affecting Work-in-Progress

After 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: "QMS approval → automatic calculation of affected orders → manual confirmation of each item," balancing 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: Continue Using / Rework / Scrap, Results Transmitted Back 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 ratings are still manually calculated in Excel by the procurement department.

Orchestration Solution:

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

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

4. Mode Selection for 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 flow correctness, and then consider introducing a unified orchestration platform. First, address the chaos, 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 define 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 the channels annotated with data interfaces and data formats.

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 scripts for automatic operations (RPA), database triggers (read-only database synchronization), and manual confirmation nodes (system pushes pending tasks for operator confirmation and execution), but each alternative means adding a "manual gear" to the orchestration chain.

Step Three: Implement in Priority Order

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 materials 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)—untimely inventory freezing can lead to nonconforming products being further processed, with serious consequences.
3. Engineering Change → Work Order Notification (monthly frequency, medium impact)—although the frequency is not high, the impact is broad. A well-handled set of rules can cover 80% of change scenarios.
4. Supplier Performance → Automatic Evaluation Update (monthly frequency, low impact)—low requirements for timeliness, suitable for the last batch of implementations.

Step Four: Establish Runbooks and Exception Handling

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

• What are the confirmation signals for normal flow (monitoring indicators)
• Who and within what time frame will intervene if the chain breaks
• What is the manual fallback process (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 qualified inspection data from QMS but does not trigger the status change from "pending inspection" to "confirmed." As a result, the subsequent financial settlement process will not be automatically triggered.

Correction: Each data interface should include clear 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: Ignoring Exception Frequency Monitoring

"Automation has been running 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 due to interface timeouts, over 200 nonconforming product handling forms were not received by ERP, and neither QMS nor ERP was aware until the customer traced the issue—this is not a problem with functionality but with the visibility of 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 kanban: interface success rate, average response time, number of exceptions, number of pending manual interventions, 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 that "people are not just relaying messages."

Knowledge code: 3.5.3

Version: v20260716

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