Why MES projects fail — and why it often has nothing to do with the MES
Florian Werner
Florian Werner, Xenium AG
IT Principal Consultant Data Science · · 9 min read
Guest post This post comes from our partner Xenium AG. At Pharma MES Europe 2026, cts Group and Xenium appear together — Xenium leads on strategy and project, cts builds the technical data foundation.

Why MES projects fail — and why it often has nothing to do with the MES

When a data project in pharma fails — what is really behind it? In my experience, almost never the technology. A few patterns, a few early signals, and the honest question of how your own projects measure up.

When a project around an MES (Manufacturing Execution System — the software layer between production control and enterprise systems) or an IDF (Industrial Data Fabric — an architecture that connects fragmented production data across OT and IT into a usable, contextualised layer) fails, the first place people look is the platform, the interface, the data model. After many of these projects, my experience points elsewhere: the fault rarely sits in the technology.

Most do not fail because data is missing. They fail because organisations start collecting data before they have defined what for. Raw data gets streamed — without context, without ownership, without a clear path to operational value.

That sounds counterintuitive. Anyone who puts serious money into a platform suspects the problem lies in the volume of data or the interface. You may see it differently from your own projects — all the more reason to talk. I am describing what I meet project after project.

The data is already there

In almost every plant the valuable data already exists — spread across MES, historian, ERP (Enterprise Resource Planning), LIMS (Laboratory Information Management System) and the automation systems. The problem is not its absence.

The problem is that it sits in silos, follows different structures and carries no shared meaning. Different sites use different naming conventions and practices. Over the years, local teams built pragmatic solutions that work for their line — but do not scale across equipment, functions and sites. The same business question then needs data from several disconnected systems.

And this is where it gets hard — not at the point of connectivity, but at the point of dependable business context. An IDF is no technology trophy. It should break down silos and make data usable across sites in real time. Successful initiatives are not built on data integration alone, but on turning fragmented production data into dependable context, self-service and better decisions.

Five patterns behind failed projects

I see five of them again and again. You may recognise one or two from your own organisation.

1. No clear why

The project starts with the intention to “collect data” — not with a concrete pain point on the shop floor, not with a business question, not with a defined metric. That turns the IDF into a platform initiative instead of a value initiative. What should come first: opaque OEE (Overall Equipment Effectiveness), manual shift logs, slow quality reporting, legacy systems with no ERP link, a missing cross-site view.

2. Raw data without context

Data gets streamed, but not explained. Process values are available, but not linked to equipment, batch, process step or business meaning. The user gets more data, but not more insight. Value only emerges when data is structured within its industrial reality — and contextualisation has to start early, not once the platform is already standing.

3. Underestimated enterprise complexity

A pilot works locally. Scaling across several sites is far harder. Global IT standards and local OT realities do not automatically fit together. Data integrity has to be secured across the entire lifecycle. And governance has to evolve from local pilot rules to global IDF rules. Without that evolution, the platform becomes the next legacy burden.

4. The rollout never reaches the teams

The architecture gets delivered — but daily work does not change. Operators still keep the shift handover in Excel. Quality reports still take too long. Trends are still pulled by hand. The IDF never becomes part of daily decisions. Real ROI only begins when colleagues actively use the tools to solve everyday friction in production.

5. No path for further development

The first use case is delivered — but there is no process to take in new ideas. Lessons are not shared, successes and stumbling blocks not communicated. The platform stagnates. A successful IDF needs an idea pipeline and visible internal communication to keep developing.

Honesty calls for the counter-check too: yes, there are projects where the technology really is the bottleneck — an old asset with no interface at all, for instance. Those exist. But they are the exception. In most cases the technical side is solvable, and the real struggle begins elsewhere. Where would you disagree?

When it is decided whether it will work

Very early. Usually much earlier than expected — often in the first workshops and the scoping phase. Not because every challenge can be predicted, but because you can judge whether a project has the foundation to survive challenges and create impact.

Because every major project runs into problems: data quality, technical dependencies, stakeholder conflicts, resource constraints, shifting priorities. That is normal. These problems do not decide success or failure. The foundation does.

The four early indicators

Indicator 1

Clear scope, shared understanding

Agreement on goals and priorities, on the core business problems and the success criteria — and on what is explicitly not part of the project.

Indicator 2

Management backing

Visible leadership support, fast decisions, active removal of roadblocks and cover when priorities collide.

Indicator 3

Realism about the data

An honest look at current data quality, transparency about gaps and limits, acknowledgement of the risks — instead of wishful thinking.

Indicator 4

The right team, involved early

The relevant perspectives are at the table from the start — not only once the architecture is standing.

The fourth point often decides more than the other three. “The right team” concretely means that every perspective a pharma data project needs is represented:

Role Brings
Business Understands business value, priorities and the expected outcomes.
Manufacturing Knows how production actually runs day to day.
Quality Knows compliance, validation and regulatory requirements.
IT Owns enterprise architecture, security and long-term operation.
OT Knows the equipment, the automation and the reality on the shop floor.
Technical implementation lead Carries end-to-end responsibility for the platform and technical delivery.
Project / strategy lead Ensures stakeholder alignment, steering, adoption and leadership-level decisions.
⚠ Warning signs in the first conversations

Does one of these sentences sound familiar from a kickoff? They show early that the foundation is still missing:

  • “Let’s build the platform first.”
  • “We’ll fix data quality later.”
  • “Everyone should be able to access everything.”
  • “We’ll define the use cases after implementation.”

What the strongest projects do differently

They start with a concrete problem on the shop floor, not with the platform. They define the why before they talk about technology. They connect process data with business goals and set roles and ownership before the first data packet is sent. They contextualise from day one — and use standards like ISA-95 to connect OT and enterprise systems. They treat governance as a living operating model, not a one-time setup.

The strongest projects are not the ones with the fewest problems. They are the ones with the strongest foundation. Many projects are won or lost before the first interface is in place.

A technically successful implementation is an important milestone — and can still be a commercial failure. Large technical challenges can usually be solved. Organisational ambiguity is far harder to repair later.

Much of this is deliberately a thesis, not a formula. Every plant is different, and in every project I learn more about where it reaches its limits. So I am less interested in whether you agree with me than in where you already see the foundation standing in your own projects, and where you do not. That is exactly what we would like to talk about in Berlin.

Read on · Part 4 of the series

Industrial Data Fabric: what it is, what it can do — and what it really delivered

Seen from the technical side: what sits behind an Industrial Data Fabric and how its value can be measured.

Read the post →

We will be discussing this at Pharma MES Europe 2026

In Berlin, cts Group and Xenium AG show why the foundation decides success — and how strategy, implementation and adoption come together.

Book a meeting at the stand