Governing Global MES/MOM Programs: The Operating Model You Don’t See on the Architecture Diagram
If you work in manufacturing, you’ve probably seen plenty of architecture diagrams. Boxes for ERP, MES, SCADA, PLCs, historians, maybe a data lake, maybe an “AI layer” floating on top. These diagrams are useful to describe intent, but they often hide the part that hurts the most when you go from theory to practice: how information actually moves from machines, through MES, into the systems that run the business.
The gap between the clean architecture slide and the messy reality on the shop floor is where complexity, delays and frustration tend to accumulate. Different generations of machines, varying automation standards, local integrations built over years, parallel tools that nobody quite wants to retire — all of these make life harder for Operations, IT and improvement teams who just want to understand what is going on and act on it.
Designing a realistic architecture for MES means accepting that complexity upfront and deciding what the operational stack should look like from machines to enterprise. It’s less about fitting boxes into the right ISA-95 level and more about answering three simple questions: where does operational truth live, how does it get there from the equipment, and how will this scale across more than one plant?
The vertical thread: from machine signals to operational truth
A useful way to look at your architecture is to follow a single piece of information on its journey. Take something simple, like a line stoppage. A motor overloads, a sensor fails, a material doesn’t feed correctly. At the machine level, an event is generated, an alarm appears on the HMI, the operator reacts. In a fragmented architecture, that’s where the story ends: the problem is fixed, the line restarts, and the only trace is a note in a logbook or someone’s memory.
In a well-designed stack, that same event follows a clear vertical path. It is captured by the automation layer, exposed in a structured way, passed through a data acquisition or edge layer if needed, and arrives in MES with enough context to understand when it happened, on which line, for which order and product, in which operating mode. MES can classify it as a specific downtime reason, update OEE calculations, relate it to other losses happening on the same shift, and store it in a form that can be analysed over time or across plants.
The same story can be told for quality results, speed changes, setup confirmations, energy consumption. The point is not that every detail must go through MES, but that there is a deliberate design for which information flows from the machines into MES and why. That design is what turns raw signals into operational truth: the version of reality that operators, supervisors, planners and supply chain teams can rely on.
IT and OT teams often come at this problem from different angles. OT is close to the machines and cares about real-time control, safety, line availability. IT thinks in terms of applications, data models, security, scalability. MES sits right in the middle. If its role is not clearly understood, you end up with a patchwork of direct machine-to-ERP links, local databases, point-to-point interfaces and reports that all tell slightly different stories.
By putting MES at the centre of the operational stack, you are not trying to centralise everything in one place. You are deciding that when it comes to executing production orders, tracking what happened on the line, understanding where time and material were lost and how that affects the plan, there should be one system of record. Machines still talk to each other at the control level; ERP still plans and accounts at a business level.
MES is the layer where the two worlds meet.
This has very practical consequences. It means agreeing on how key concepts are represented in MES: equipment, work centres, orders, products, batches, shifts. It means defining how machine states and events map into those concepts, so that “running”, “stopped”, “changing over” or “waiting for material” mean the same thing wherever you are in the network. It also means being honest about integration: deciding when you need a structured integration layer or edge gateway instead of another ad-hoc interface, and investing in standard patterns rather than one-off solutions.
Designing for scale, change and more than one plant
A lot of architecture discussions are focused on “what works best for this plant”. That is understandable, but if you know that your long-term goal is a multi-site MES or MOM program, the question should quickly become: what will still make sense when we have ten or twenty plants connected?
At that scale, the weak points of a purely local architecture become obvious. If every site has its own way of connecting machines to MES, adopting slightly different naming for equipment and tags, defining downtime codes differently, or using custom fields in unique ways, your ability to compare and steer performance across the network is limited. Each plant may be optimised on its own terms, but the company as a whole is not learning as fast as it could.
Designing for scale does not mean forcing every plant into an identical mould. It does mean being deliberate about where you need consistency. For example, you might decide that the way you represent production assets, orders, standard loss categories and core quality checks in MES should be standard across all sites. The way individual screens look, how work instructions are presented, or how local reports are laid out may have more flexibility as long as they don’t break the core model.
The architecture also has to accommodate change. New machines will arrive. Old ones will be retrofitted or retired. Lines will be reconfigured. Plants will be added or transferred. A rigid, tightly coupled system might look efficient on day one, but it becomes fragile as soon as the real world shifts. A more resilient architecture keeps interfaces as clean as possible, separates concerns between layers, and avoids embedding business logic deep into places where it is hard to change, such as PLC code that was never meant to be touched again.
From a technology perspective, this often translates into a hybrid approach: some capabilities close to the machines, where latency and determinism matter; a strong MES layer that orchestrates operations and captures context; a data platform and integration backbone that can serve analytics, AI and cross-plant use cases without constantly disturbing the operational systems. The exact mix of on-premise, edge and cloud will depend on your constraints, but the design principle is the same: make sure each layer knows what it is responsible for and how it communicates with the others.
For Operations, IT, Continuous Improvement and Supply Chain managers, the value of this work is not in having the most elegant architecture diagram. It is in reducing friction when you want to do basic things: bring a new line into MES without six months of discovery, roll out the same performance dashboard to five plants without rewriting the logic every time, run a simple comparison of scrap on a product family across three sites without spending weeks cleaning data.
A good architecture does not remove all complexity from manufacturing; that would be unrealistic. What it does is organise that complexity in a way that makes it manageable. It ensures that when a machine stops, when a batch fails quality, when a changeover takes longer than planned, you have a reliable way for that information to travel up the stack and trigger the right actions. And it gives you a foundation you can build on: for better planning, for smarter maintenance, for sustainability reporting, for AI applications that depend on clean, contextualised data.
In many ways, designing the operational stack from machines to MES to enterprise is like designing a language that your factories can use to tell you what is really happening. The clearer that language is, the easier it becomes to listen, learn and act at scale.