The MES graveyard is full of two-year projects that died in workshops. The causes repeat so reliably that they amount to a checklist, and avoiding them points to a different way of buying execution software altogether.
Quick answer: MES projects fail for organizational reasons before technical ones: scope defined by committee, value promised at the end of a long rollout instead of along the way, operators treated as data-entry labor, and integration ambitions that make the ERP project look small.
The lightweight alternative inverts each: start on one line, deliver a measurable result in weeks, make the operator's job easier on day one, and integrate only what the use case needs.
1. The everything-scope. Classic MES selection gathers requirements from every department, producing a specification only a multi-year program can satisfy. The project's size then becomes its main risk: sponsors change, budgets tire, and the plant that needed help in Q1 is still attending workshops in Q4 of next year.
2. Value at the end. When the first measurable benefit arrives after go-live of everything, the project spends two years consuming credibility and none earning it. Momentum is a resource; big-bang designs spend it all upfront.
3. The operator as sensor. Systems designed in conference rooms make the floor feed them: more screens, more clicks, more codes. Operators respond rationally by feeding them garbage, and the MES becomes an expensive fiction generator. Any execution system that adds net work to the operator's shift will be defeated by the operators, and they will be right.
4. Integration maximalism. Bidirectional real-time sync with ERP, quality, WMS and the historian, before the first line is live. Every interface is a project; ten interfaces are a hostage situation.
5. Customization instead of adoption. When the tool bends to every existing habit, the plant pays enterprise prices to digitize its current chaos. The point was to change how work happens, not to laminate it.
Not less capable: differently sequenced. A lightweight execution layer starts where the money is (usually OEE visibility and the loop from stop to fix), goes live on one line in days, proves a measurable result inside a quarter, and expands line by line on the strength of that result.
Operator interactions are seconds, not minutes, and replace paperwork rather than adding to it. ERP integration is scoped to what the use case needs: orders, BOM and materials in, actuals out, nothing else until something else earns its keep. There is a quiet beneficiary in this sequencing: the continuous improvement team, which gets honest line data in weeks instead of after the program, converting the kaizen pipeline from anecdote and staged observation into evidence.
Full MES depth (genealogy, enforced routings, regulated e-records) gets added where the product and the customer demand it, not everywhere by default.
Ask three questions. How long until the first line is live and measuring? (Days and weeks are answers; quarters are a warning.) What will the operator do differently, and does it take more time or less than today? And what is the exit question of the pilot: which measurable result, by which date, decides go or no-go? Vendors with good answers welcome the questions. The others will talk about workshops.
What percentage of MES projects fail?
Published failure rates vary wildly with the definition of failure, from budget overrun to outright abandonment, and most figures trace back to vendor or analyst surveys. More useful than any percentage: the failure modes above are documented, repeatable and avoidable.
Do we need a full MES or is OEE software enough?
It depends on regulatory and traceability requirements. High-mix regulated production needs MES depth; many plants get the majority of the value from honest OEE, connected maintenance and light execution first, and add depth where demanded.
How long should an MES implementation take?
The first measurable value should arrive in weeks on one line. Plant-wide rollouts legitimately take longer, but a program whose first benefit is more than a quarter away is carrying avoidable risk.
We are midway through a struggling MES rollout. Restart or push through?
Neither; narrow. Pick the one line where the pain is worst, define a single measurable result and a date, and deliver that before touching the rest of the scope. Programs are rescued by shrinking to a win, not by pushing a failing scope harder, and the sunk cost is not a strategy.
Is a lightweight system a dead end for growth?
Only if it lacks the depth to grow into. The right question is sequencing: can it start small and add execution depth per line and per product where needed, rather than forcing everything everywhere first.
Fabrico deploys the execution layer line by line, with pilots that carry a defined exit question. See also: MES vs ERP, and how to design a pilot that proves something.