3 Critical Errors in ERP-MOM-MES Integration

In the past four days, we examined the ERP’s record system, MES’s execution layer, and MOM’s orchestration umbrella separately. Today our question is different: What are the most common mistakes when connecting these three layers, and why do connected systems start responding unconsciously when they break apart?

Let me start with a shop floor scenario.

Scenario: Conflicting Records

Wednesday morning, 09:00. Operator Ayşe starts a work order for Product B on Machine M3. At the same time, the accounting module in ERP creates an estimated record: “Product B, 100 pieces planned, material cost for 100 pieces is X.”

14:00. MES record: “Machine M3, Product B, 60 pieces completed, 3 pieces scrap, 1 machine breakdown (25 minutes).” But ERP still says “100 pieces planned, estimated cost X.”

Friday. The customer expects 100 pieces. The ERP sales manager says “okay, 100 pieces, delivered.” But what actually happened: 97 pieces (3 scrap) and 25 minutes of unplanned downtime. Where does this discrepancy disappear?

Answer: When the data flow is broken, this discrepancy doesn’t land in any system. Production doesn’t know (because MES data isn’t going to ERP), ERP doesn’t know (because standard cost, not actual cost, is running), and the customer doesn’t know (because they think 100 pieces were delivered, but cost should be calculated on 97 pieces).

This breakage has three sources.

Error 1: Concurrent Write Conflicts

When a work order is being updated in both ERP and MES at the same time, whose write takes priority can become unclear.

Example: ERP planning schedules 100 pieces of Product B on Machine M3. At the same time, MES is waiting for Product A on Machine M3 to finish. MOM also says “start Product B once M3 is free.” Three systems see the same machine in the same time window differently.

If integration operates on a last-write-wins basis, the most efficient system doesn’t win—the most frequent writer does. This may be acceptable in make-to-stock production (same product, same quantity). But in make-to-order production, every order is different. Whoever writes last is considered “correct.”

Solution: Event-driven integration. Each system only writes to its own domain. ERP creates the order, MOM makes the plan, MES records the execution. Feedback always flows through MOM. There is no direct path from MES to ERP.

Error 2: Data Ownership Ambiguity

Another common mistake: “Whose data is the standard cost?”

ERP looks at the recipe and says “standard time for Product B is 3.5 hours.” But MES says “this week, Product B’s 4 work orders averaged 4.2 hours.” The reason for this difference: new operator, machine setup, quality issue. ERP doesn’t change the standard because “standard” doesn’t change.

So who is responsible for this discrepancy? Accounting looks at ERP: “Product B’s cost is this.” Production looks at MES: “Our cost is this.” Two teams work with different numbers.

In this case, the purpose of integration is not to copy data but to determine who owns it.

Each system writes what it owns; others read. If you build integration without knowing who writes what, after three months no one trusts any number.

Error 3: Uncalculated Latency Tolerance

Integration is called “real-time,” but how much delay can each data type tolerate?

Instant (milliseconds): Command from MES to machine controller. Machine started, stopped. At this level, delay = failure.

Within minutes: Work order status from MES to MOM. “Started, stopped, finished.” MOM expects this data because current information is required for decision-making.

Within hours: Cost and progress from MOM to ERP. ERP doesn’t need to ask “where is production right now?” ERP uses this data when closing at month-end.

Within days: New order from ERP to MOM. MOM picks it up in its planning cycle (usually daily).

Not all data needs to be real-time. But how much delay each data type can tolerate must be determined in advance. In particular, these two speeds must not be mixed:

  1. Execution data (MES->MOM): Delay is unacceptable. We need to know if the machine stopped.
  2. Planning data (ERP->MOM): Delay is acceptable. Even if the order reaches MOM by noon tomorrow, it’s fine if planning happens on Wednesday.

If you put these two speeds on the same wire, either planning data becomes unnecessarily fast (cost) or execution data becomes slow (risk).

Netsis, Odoo, Logo, Paraşüt: At What Level Do They Connect?

The integration levels of four common ERP solutions in Turkey differ:

Netsis: Has API support but is “batch-oriented.” Hourly bulk file exchange is possible. Real-time data flow is difficult. When connecting with MOM, hourly batch can be an acceptable assumption. But if you expect “instant status” with Netsis, it will disappoint.

Odoo: API is very open. Each event can go to a separate endpoint. Near real-time connection with MOM and MES is possible. But Odoo’s internal MOM functions are limited; a third-party MOM software is required.

Logo (Go): Enterprise level, good API support. But cost is high. In a factory using Logo, integration usually stays within Logo’s own ecosystem. Third-party MOM integration is possible but limited.

Paraşüt: Accounting-focused. MES and MOM integration are almost non-existent. In a business using Paraşüt, MES and MOM usually work independently, data is carried manually.

The critical question in these choices: “Will you build the integration layer yourself, or will you use the solution provider’s integration module?”

infab.cloud’s Integration Position

infab.cloud is designed as a layer that bridges the gap between ERP and MES. It communicates directly with machines (Level 1-2), takes MOM decisions, and returns reports to ERP in the format “work order closed, actual time is this, scrap is this.”

This way, no changes are needed on the ERP side. Whether it’s Odoo, Netsis, Logo, or Paraşüt, infab.cloud receives work order data through a standard API and returns actual production data.

In a setup without an integration layer, you need to write separate integration code for each new ERP or each new MES system. This is not a one-time cost but a continuous maintenance burden.

Conclusion: Connecting Is Not a Method, It’s a Responsibility

The critical takeaway when connecting ERP, MOM, and MES is this: It’s not about copying data to each other, it’s about determining who owns the data. Who writes what, who reads what, how much delay is acceptable?

Integrations built without answering these questions face two problems after three months: Either data conflict (who wrote last, is that correct?) or data loss (who never wrote, is there a gap?).

In the next article, we will examine the difficulty of building these integration layers alone and the MOM + ERP + MES synthesis.

Previous articles: What is MOM? and ERP-MOM-MES data flow