When Level 2 and MES don’t line up in a plant, the problem is rarely the interface itself. It is almost always a decision that was never made explicitly. Who owns the logic? Who owns the state? And who defines what is true when numbers do not match in the morning production meeting?
After working on multiple MES implementations, I have seen the same pattern across different plants and organizational structures. Integration problems do not usually explode on day one. They surface slowly after go-live, when production pressure is high and design changes are no longer cheap. What looked like a minor ambiguity during workshops becomes a recurring reconciliation topic once the plant runs 24/7.
“Integration problems are rarely technical failures.
They are governance decisions that were never made.”
Logic ownership is usually decided too late
In many projects, Level 2 and MES are defined as separate scopes. Different vendors, different contracts, different timelines. Integration is discussed near the end, often under schedule pressure.
That is typically when someone realizes that a fundamental business concept has two definitions.
In one project, the question was simple: when does production officially start? From an automation perspective, the answer was based on process signals. From an MES and reporting perspective, the answer was based on the first confirmed production object. Both definitions were reasonable. They just were not aligned.
The consequence was not technical confusion. It was business misalignment. Production reports showed one start time. Process dashboards showed another. KPIs derived from those timestamps differed slightly. Over time, that small difference created recurring reconciliation work between operations and controlling.
The root cause was not incorrect logic. It was the absence of a clear ownership decision during design workshops. Once two systems implement parallel definitions of a business event, integration becomes an ongoing negotiation instead of a stable architecture.
Duplication of calculations starts as a “temporary workaround”
Duplication rarely starts as a strategic choice. It starts as risk mitigation. A value calculated in Level 2 is reimplemented in MES because someone wants independence, validation, or flexibility.
In one implementation, production quantities were calculated in real time by the automation layer, and MES initially consumed those values without modification. Later, during reporting and performance review discussions, concerns about transparency and traceability led MES to implement its own calculation logic so it could “stand alone” for official reporting.
For a while, both numbers matched closely. Then operational exceptions and edge cases started to create small deviations. Technically, both systems were correct. From a process perspective, the difference was marginal. From a financial perspective, it was not.
That is when you get the meeting shown above. Operations presents 94.8%. Controlling presents 94.3%. Both defend their system. Both can explain their logic. The real debate is no longer about calculation methods. It is about authority.
Which number is official?
Which system feeds the ERP?
Which one is audited?
At that point, the integration problem has become a governance problem.
Tracking inconsistencies become credibility issues
Tracking problems are often perceived as technical glitches. In reality, they are credibility risks.
In one integration project, both Level 2 and MES had logic to create production objects under certain conditions. The intention was resilience. If one system missed an event, the other could compensate. On paper, this looked robust.
In practice, it introduced ambiguity. During a short communication issue, both systems created records for the same physical production unit. Downstream planning and reporting reflected two parallel realities. The cleanup required database corrections and manual validation.
The technical incident lasted minutes. The loss of trust in the system lasted much longer.
From a business perspective, the lesson was clear. A system architecture where multiple layers can create or redefine production reality may seem flexible, but it increases risk. Clear creation ownership and strict enrichment boundaries are more valuable than redundant intelligence.
State management is a governance decision
State transitions such as production start, completion, or closure are not only technical events. They are business events. They influence KPIs, reporting periods, cost allocation, and performance evaluation.
In one project, automation logic determined completion strictly based on process signals. MES added additional rules to prevent open records from remaining active too long, mainly for reporting completeness. Under normal operation, both systems aligned. Under exceptional conditions, they diverged.
The result was not a system crash. It was inconsistent reporting across departments. Operations saw one status. Planning saw another. Finance saw a third interpretation derived from reconciled data.
The issue was not software quality. It was overlapping authority over state transitions.
Clear state ownership is less about technology and more about governance. It requires explicit agreement on which system defines business reality and which systems consume it.
Where a Unified Namespace helps
A Unified Namespace does not solve governance problems automatically, but it exposes them quickly.
In traditional point-to-point architectures, conflicting definitions can remain hidden inside interfaces. Each system believes it is correct. Discrepancies are only detected in reports. In a publish and subscribe architecture, inconsistencies become visible as soon as two systems publish competing values for the same entity.
In one implementation, moving toward a Unified Namespace forced the team to formally document ownership of each published data element. That exercise revealed duplicated logic that had existed unnoticed for years. The technical migration was important, but the real value came from the architectural clarity it required.
However, architecture alone is not enough. Without governance rules that define who can publish, update, or override specific entities, a Unified Namespace can amplify confusion rather than reduce it.
What I have learned implementing MES
After several MES projects, I have come to a consistent conclusion. Most Level 2 and MES integration issues are not technical failures. They are governance gaps that surface once the system becomes business-critical.
They appear when ownership of calculations is assumed rather than documented, when state transitions are implemented in parallel to reduce perceived risk, and when architectural decisions are postponed to meet deadlines.
The most successful implementations I have seen share one characteristic. Early in the project, they explicitly define which system owns which business concept. Not only at the data level, but at the responsibility level.
Once ownership is clear, architecture becomes simpler. Reporting stabilizes. Reconciliation decreases. And integration stops being a recurring topic in steering committees.
Integration between Level 2 and MES is not primarily about interfaces. It is about defining authority.
And in MES projects, authority over data is authority over business reality.