When people talk about global MES or MOM programs, the first things they usually mention are technology and templates: which platform to choose, how to design the architecture, how to build a global core model. All of that matters. But if you look at why programs stall, drift or quietly die after a few pilots, the root causes are rarely technical. They have more to do with who decides what, how those decisions are made, and how work is organised between global teams, local plants and partners.
In other words, the real backbone of a global MES/MOM program is governance and operating model. It is the part you don’t see on the architecture diagram, but it determines whether that diagram will ever become a reality across your factories.
Most organisations discover this the hard way. The first pilot goes live, the system works reasonably well, people are enthusiastic. Then the second and third plant come into scope, and suddenly basic questions are not clear anymore. Who is allowed to change the template? Who owns the data model? How much freedom does a plant have to adapt screens or workflows? Who approves new machine integrations or local reports? And when something goes wrong, who is accountable?
If these questions are not answered explicitly, they are answered implicitly – in meetings, emails, side conversations. That is when inconsistency creeps in. The same MES solution starts to look and behave differently from plant to plant, standards weaken, and the ability to compare performance or roll out new capabilities slows down. From the outside, it may still look like one global program. On the inside, it is a growing collection of variations.
The invisible work behind a successful global program
A good way to think about MES/MOM governance is to imagine it as a set of recurring conversations that are structured, predictable and shared. They connect strategy with daily reality in your plants. They define how decisions are taken, by whom, and based on what information.
At the top, there is usually some form of program steering group. This is where Operations, IT, Quality, Continuous Improvement, sometimes Finance and Supply Chain align on the direction: why the program exists, which value levers it is meant to move, how fast they want to go, which plants will be involved in which sequence. Without this alignment, the rest of the organisation receives mixed signals. One month MES is “a strategic priority”, the next month budgets are frozen and local initiatives are encouraged to go their own way.
Closer to the technical and process heart of the program, there needs to be a body that acts as guardian of the model. Call it an architecture board, a process council, a core team – the label matters less than the function. This is where standards are defined and maintained: process variants, data model, KPIs, integration patterns between machines, MES and ERP, rules for local extensions. When this group is weak or only symbolic, the template quickly fragments. When it is too rigid or detached from plant reality, the program loses the support of the people who actually have to live with the system.
Then there are the plants themselves. In global programs that work, plants are not passive recipients of a solution designed somewhere else. They have named roles: local project leads, key users, champions for operations, maintenance and quality. These people are the link between the template and the reality of specific lines, shifts and products. They provide feedback on what works and what doesn’t. They help ensure that decisions taken centrally are translated into practical change on the shop floor. And they are often the ones who keep the system alive after go-live, when the central project team has moved on.
Somewhere across these layers, there must also be clear ownership for machines and automation. It is surprisingly common for MES governance to stop at the application boundary, as if connecting machines were a separate, parallel story. In practice, of course, a global program cannot succeed if every plant negotiates its own way of integrating machines, naming tags, or deciding which signals matter. Governance has to cover how new lines and equipment will be made “MES-ready”, who approves integration standards, and how exceptions are managed.
None of this is glamorous work. It requires time, patience and a degree of discipline that is easy to underestimate when enthusiasm around the first pilot is still high. But without it, even the best roadmap and business case will eventually be slowed down by the weight of uncoordinated decisions.
Turning governance into something people can actually use
Governance often has a bad reputation. Many people associate it with bureaucracy, delays and long documents no one reads. That is not what a global MES/MOM program needs. What it needs is a practical operating model that answers a small set of recurring questions in a consistent way.
For example: who decides when a requirement is part of the global template, and when it is a local variation? How do you introduce a new KPI into the system? Who validates changes that affect master data shared across plants? How are new machines evaluated and connected so that their data fits into the existing model? When a plant asks for a change that might be useful elsewhere, who looks at that request with a network-wide perspective?
Clear answers do not mean centralising everything. In fact, the best programs are careful about what they truly need to hold at global level and what can remain local. They typically keep the core process logic, data structures, KPIs and integration patterns under tight control. Around that, they provide space for plants to solve their own problems, as long as they stay within defined boundaries.
The operating model also has a time dimension. During early pilots, governance can be relatively informal; the central team is small, everyone sits in the same meetings, and decisions are easy to coordinate. As soon as you move into rollout mode, the volume of activity increases sharply. More plants, more lines, more people involved. What used to be a quick chat becomes a decision that, if not documented and communicated, will be interpreted differently in different places. At that point, you need to make governance more explicit: simple decision logs, lightweight approval flows, clear communication channels.
The post go-live phase is another area where governance makes a big difference. Many programs treat “go-live” as the end of the story. In reality, it is the beginning of the system’s life in that plant. Issues, improvement ideas and new needs will appear. If there is no agreed way to triage them – what is support, what is a local enhancement, what should be fed back into the global template – frustration grows. Plants feel that they are not heard; central teams feel overwhelmed by requests. A basic model for run, enhance and standardise can prevent this: some items are fixed locally, some are collected and considered for the template, some are simply parked until a later wave.
From the outside, this may look like overhead. From the inside, it is what allows the program to keep moving. It turns governance from a set of documents into a set of habits: who meets with whom, how often, to look at which information and take which type of decision.
For Operations, IT, Continuous Improvement and Supply Chain leaders, the key message is simple: you cannot outsource governance. Partners and integrators can bring examples, structures and experience. They can help you see patterns from other industries and geographies. They can support the activities and provide professionals to help drive the initiative. But the final shape of your operating model has to reflect your organisation: your culture, your network, your ambitions. The earlier you start to think about this, the less energy you will lose later trying to retrofit governance onto a program that has already grown in a fragmented way.
A strong architecture and a solid MES/MOM platform are necessary for a global program. A well-designed template is essential. But without a clear answer to “who decides what, and how?”, they will never reach their full potential. Governance is the part of the solution that no one will see in the system screenshots, yet everyone will feel in the way the program moves – or doesn’t.
Download the post
Subcribe to my newsletter to download the post as printable PDF