OpEd: MES industry faces 3 problems that few are discussing

Almost four years ago, I joined Pico because it showed me a different way to modernize a shop floor. A common thread across that: the decision to digitize the shop floor was exorbitantly expensive- often with a seven-figure price tag- or (and) it was going to take a year or two to even set up the system.

Four years later, I've spoken with hundreds of operations leaders, plant managers, and quality directors at both large manufacturers and start-ups. I've watched dozens of MES selections, many implementations, and more than a few quiet failures that nobody writes case studies about.

What I’ve learned: The MES industry faces three main problems that few are discussing. The problems aren’t technical problems. They’re cultural problems that sabotage folks before they ever plug in their first network cable.

Problem 1: We’re trying to overreach with the tech stack planning

I love a good vision and strategy session. It is very important to know where you are going. These sessions can provide guidance for years to come. But they also make tech deployment susceptible to bloat. For some, this leads to the wrong behaviors. This top-down strategy over-enables by focusing on the procurement process instead of the problem-solving process. The RFP asks for 300+ requirements. The RFP committee is explicitly 8-12 people, with many more tacit, offline approvers. Conversations roll into more conversations. By then, the evaluation alone has rolled on for 6 months or more.

A key part of this bloat is that every end user and stakeholder thinks they have the biggest problem to solve. As a result, they add it to the pile. To solve it, the project champion turns to analyst frameworks—such as Gartner Magic Quadrant, IDC MarketScape, or LNS Research Solution Selection Guides. These frameworks implicitly reward comprehensive feature comparison. "Did you check the box?" is easier to defend in a steering committee than "Did you ship value?"

In the end, there is a perfectly architected framework that has been fully evaluated. It will be deployed in 14 months. In 18 months, the trained operators who didn’t speak up about usage gaps or the actual friction on the production floor will have left. The product-process mix has changed. The IT specialist who knew the secrets to deploying it accurately has moved on to a bigger opportunity.

I’ve seen teams try to compare 7+ MES at once. What they really wanted to solve was a single actual production problem: poorly tightened bolts. My favorite feature request during one assessment was, “What AI-powered predictive insights does the platform provide?” At that point, I thought I needed to personally help run their shop. No one there could define what they needed in terms of features or how to approach the problems they wanted solved.

The most concerning thing I see is the lack of a plan to deliver any improvements in the first 90 days. The question shouldn’t be, ‘Do I get all the features I can think of?’ The question we need to ask is: 'Which station, on which line, has a problem I can solve in six weeks or less?' Architecture follows iteration, not the other way around.

Problem 2: Vendors overpromising what they can do

I recently received a callback from a company we spoke with three years ago. They originally chose another vendor to address their inspection problems, but that solution failed to provide accessible, easy image capture and storage. A second vendor offered the same promise and delivered similar results. Overpromising is common in sales. I’m not completely clean here either. I, too, have told engineers Pico can be set up in half a day—true only in ideal conditions. In practice, environments rarely cooperate. Networks have issues. Electronics fail.

MES as a category has been promising the same things for over 20 years: real-time visibility, paperless shop floors, a single source of truth, and OEE improvements. Many of those promises are true in principle but false in delivery. Most promise "out of the box" features that require 6 months of configuration. Most run demos from a "cleaned" environment, not a real, messy shop floor. I talked with one engineer a few weeks ago. He told me a story about another vendor. During the demo, he interrupted to ask the vendor to create the work instruction in real time. The vendor couldn’t.

There are gray areas in the promise of capabilities. The main one is integration capabilities. The promise of “pre-built” ERP connectors is often touted as the best. It turns out most require a $200k systems integrator to come in and rebuild it. Sometimes, the ERP+MES vendor’s branded software didn’t integrate to the level promised.

What I’ve learned about “the promise,” as with Problem 1 above: know what you’re solving for. Try it out. If the problem is bigger than a demo can solve, ask the vendor to put you in touch with a customer who’s had it solved. Ask about the customer service, too.

Problem 3: Underestimating the value of iterating on the shop floor

The biggest unlock I’ve learned and relearned from modern MES isn’t the better tech stack architecture. It’s the ability to put the system on a station or line, capture data, then adjust—and repeat. This is counterintuitive to tech teams used to deploying ERPs and PLMs. For shop floor teams used to the PDCA [Plan-Do-Check-Act] cycle, it’s about running that process without getting stuck in a planning-only iteration loop.

From my experience, the teams that get the most out of their MES standardize a line or station—both the flow and the level of operator guidance. They deploy tools (IT & OT) to collect data. Then they look at what the data tells them to drive a round of rapid improvements. As part of this, they engage the operators to see how the system is being used. They collect feedback from the operator on the system—“I need more definition here,” or “the work instruction is too long there, and I don’t read it.” Operators are the superusers here. Within just a couple of runs, they will be able to tell whether the system is working or just another IT initiative to ignore.

Then roll out a few more stations – collect, compare, adjust.  

I’ve seen customers use this pattern to go from 2 stations in the first month to nearly 200 stations in 6 months. In other systems, they would still be discussing who in the quality department needs to sign off on the system.

As I teach my students, compounding is about starting early and sticking with it. The toolset matters less than the operating cadence. Even a partial, imperfect system that delivers data in 2 weeks is better than a perfect system implemented in 14 months. Early adoption and compound learning are the strategic win.

My hard take: The manufacturers who win the next decade won't be the ones with the best ‘AI-enabled MES architecture.' The ones from the last decade didn’t win with Industry 4.0 buzzwords. The winners will be those who deploy quickly, build a habit of iterating, learn from it, and improve every two weeks for five years. That habit is worth more than any software you'll ever buy — including ours.

The 3 problems above don’t occur in isolation. They are interwoven and reinforce each other. A manufacturer looking for every feature will be susceptible to vendors who overreach. A vendor who’s overpromised will hide behind a long implementation, lacking iteration. A failed implementation can lead to a jaded, longer selection process next time. The easiest way to break that trend? Start small and build momentum.

I’m not making this up either. We had one customer who was worried about testing failures. They already had a big MES deployed, and it wasn’t solving the problem. We went into a few stations on a line and helped collect the data. They fixed the problems and drove continuous improvement. Three years later, we were across 5 of their plants.

If you’re stuck on how to deploy, grab the lean leader or try the following:

1. Pick one station. Not a line, not a plant. One station with one defined problem.

2. Define what 'better' looks like with a number. Scrap reduction, FPY improvement, audit-prep time, and onboarding days. One number, not seven.

3. Give yourself a six-week deadline. If it can't be done in six weeks, the scope is wrong, not the timeline.

4. Involve one operator from day one. Not from go-live. From the first whiteboard sketch.

5. Design the simplest solution that could plausibly work. You will throw away half of what you designed. That's the point.

6. After six weeks, write down what you learned. Not what built — what you learned. That document is worth more than the system.

7. Pick the next station(s). Repeat.

If you can't do the above in your organization - if the procurement process won't allow a six-week pilot, if IT requires a 14-month scoping review, if the budget cycle is annual and inflexible - that constraint is the real problem. Solve that first. The MES will follow.

We built Pico first and foremost for the folks running the shop floor. When I was running factories, it was the tool I wanted: something to help the team deploy, iterate, and continuously improve. But more important than any tool are the habits teams build—habits become the competitive advantage, and tools simply enable them.

I write about this stuff every other week. If it's useful, subscribe to our newsletter. No pitching, just patterns from the shop floor.

If you’re trying to figure out where to start or how to pivot from a path you’re on, I'll spend 30 minutes on a call with you — no sales, no pitch. Just helping you scope the first station.