MES Software Problems: The 5 That Keep the Whiteboard Alive, and How to Avoid Them

Why do MES projects drift into rebuilding the ERP?

Because the gap the plant feels is not the gap the plant describes. Ask a production manager what is wrong and you will hear about purchasing lead times, about inventory counts being wrong, about the ERP being useless. Some of that is true and almost none of it is what a manufacturing execution system fixes. The actual gap is narrow and specific: the enterprise system releases work order 4471 as one object with a quantity and a due date, and your floor sees seven operations across four work centres with an outside plating step in the middle. Between release and completion, nothing in the ERP has an opinion.

Once a project starts adding screens outside that gap it stops being an execution system and starts being a second ERP with a smaller budget and no accounting. The failure is not usually dramatic. It is that the operator stations, the dispatch lists and the scan based work in process tracking, which is where the payback lives, get pushed to phase two and phase two gets cancelled.

The discipline that works is a boundary written down before kickoff. Work orders, routings and bills of material flow down from the ERP. Completions, scrap and labour flow up. Everything in between belongs to the execution layer, and anything outside it is a change request that has to displace something. Say it in the first meeting and repeat it whenever someone asks whether the system could also handle purchasing, because someone always does, usually in week nine.

What goes wrong with routings, bills of material and work in process data?

Routings in most mid-market ERPs are aspirational. They were entered when the part was introduced, they reflect how the job was quoted rather than how it runs, and the floor has been working around them for years. Operations that were merged on the shop floor are still two lines in the system. A step that always goes to an outside processor is not in the routing at all because purchasing handles it separately. Standard times are whatever the estimator used.

Feed those routings into a dispatch list and operators will tell you within a day that the system is wrong, and they will be right. Then they stop scanning, and the project is dead. Routing clean-up is a workstream with plant involvement, not a data import, and it usually means walking the floor with a supervisor per part family. Expect to find that a meaningful number of routings do not match reality, and expect that discovery to be uncomfortable for whoever owns the ERP.

The second problem is opening work in process. On cutover day there is material sitting between operations, some of it partially complete, some of it in an outside processor's building, some of it in a rework loop. It has to enter the new system somewhere, and the honest approach is a physical count against a defined cutover moment, entered as opening positions with the operation each lot is standing at. The alternative, which is trying to reconstruct where everything is from paper travelers, takes longer and produces a system nobody believes in week one. Pick a low-volume week, count, and start clean.

Why do machine connections and the ERP sync break after launch?

Machine connections break because the mix is never what the proposal assumed. A plant with thirty machines rarely has thirty that speak OPC UA or MTConnect. It has eleven modern controllers, nine that need a protocol bridge, six that only offer a discrete output you can watch, and four with no useful signal at all, including a 1994 press that predates ethernet. Retrofit sensors and current monitoring cover the last group, and they cost more per machine than the modern ones do.

The failure after launch is subtler: the connection stays up and the context goes missing. A historian can tell you the machine stopped at 2:14 in the afternoon. Without the order, the operator and the reason code, that is a timestamp rather than information. Build the prompt at the station so a stop exceeding a threshold you set asks for a reason within seconds, while the operator still remembers, and join the machine event to the order context the system already holds.

The ERP sync breaks in the ordinary ways integrations break: a completion is rejected mid-shift because the ERP has the order on hold, a retry after a timeout posts a completion twice, a unit of measure conversion rounds in a direction nobody expected. Ask any developer how the sync fails, not whether. The honest answer describes queues, retries, idempotency and a reconciliation view where an ERP administrator sees rejections rather than discovering them at quarter end close. Anyone who says the integration just works has not run one through a period close.

What happens when genealogy and audited traceability are not covered?

You find out during a customer claim, which is the worst possible moment. An automotive customer emails that a bracket cracked at their line and wants every shipment containing material from the same steel coil identified by Thursday. In a paper plant that is two quality engineers pulling travelers from boxes for three days, and then over-scoping the containment because you cannot prove which lots are clean, so you sort or scrap product that was fine.

ERP lot control does not solve this because it is blind through work in process. The system knows which coils you received and which finished goods you shipped, and the link between them was handwritten on a traveler if it was captured at all. Genealogy has to be enforced at the point of consumption: the saw operation cannot start until the coil tag is scanned, and every downstream operation inherits the chain.

The cost trap is retrofitting. Adding enforced genealogy, append-only audit trails and electronic signatures after a system is in production costs roughly what the first release did, because it touches every transaction and every screen and it invalidates the data you have already collected. Designed in from the first sprint it is mostly discipline. So name the standard during discovery. If you sell into automotive or aerospace, IATF 16949 and AS9100 auditors want traceability demonstrated by query rather than described in a procedure. If you touch medical or food, say so, because FDA 21 CFR Part 11 expectations around electronic records and signatures shape the architecture rather than the interface.

Should you build custom or configure what you already own?

Buy when you are a single plant with under roughly 25 machines, your processes look like the demo with discrete assembly, linear routings and minimal rework, and you can absorb a platform implementation. Tulip or L2L sitting on top of your ERP is a defensible answer at that size and cheaper than building. Buy also if a parent company has standardised on Siemens Opcenter or Rockwell's Plex, because fighting corporate IT is not a project, it is a career decision.

The walls mid-market manufacturers hit with commercial platforms are consistent. Licensing priced per user or per station multiplies across three shifts and every plant. Integrator-led implementations commonly run 12 to 18 months and often cost more than the licences. And each platform carries a process model, so where your plant differs, with outside plating loops, shared work centres across value streams, or one serialised product line inside a lot controlled plant, you either change the plant or pay to customise software you will never own.

Build when any two of these are true: you run multiple plants with different processes, the whiteboard still beats the ERP schedule, per-seat quotes across your shift structure exceed roughly $80,000 a year, your traceability requirement is contractual and audited, or the way you route and rework product is part of why customers choose you.

How do hidden costs get into the quote?

Five drivers, all of them answerable before signing.

• Machine mix and age. Five OPC UA capable machines are cheap. Thirty mixed-generation controllers with two that predate ethernet are not, and the difference is per machine rather than a rounding error.
• Routing clean-up. Priced as data migration in most proposals, delivered as weeks of walking the floor with supervisors, because the routings in the ERP are not how the plant runs.
• Offline tolerance. A network blip must never stop a line, which means local caching and queued synchronisation at every station and roughly double the testing.
• Regulated traceability. Append-only audit trails and electronic signatures cost little when designed in and roughly a first release when retrofitted.
• Each additional site. A second plant with a different process is a second data model conversation, not a deployment.

Scanners, label printers and ruggedised tablets are real line items and rarely the driver. In Digital Heroes delivery experience a focused first release covering one plant with operator stations, dispatch lists, scan based work in process tracking, scrap and downtime capture and two-way ERP sync runs $60,000 to $130,000 over 12 to 16 weeks, with a full multi-plant platform at $150,000 to $400,000 phased over 6 to 12 months.

What separates a build that works from one that fails here?

Make them draw your data model before you sign. A team that has built execution software will whiteboard work orders decomposing into operations, lots consuming into genealogy, serials, reason code taxonomies and shift calendars without being prompted. If the first diagram shows orders and statuses and nothing else, they are about to learn manufacturing on your budget.

Interrogate machine connectivity with specifics. Which controller families they have integrated. What they do with a machine that only speaks a serial protocol from the 1990s. How they timestamp events when the network drops and the station has been running offline for forty minutes. Vague answers here become change orders in month four.

Then get the rollout right, because this is where good builds die. Run the new system in parallel on one value stream or work centre, keep the paper traveler alongside the scans for two to four weeks, and retire paper cell by cell. The whiteboard usually dies on its own once supervisors trust the dispatch list, and that trust is earned by the dispatch list being right about the routing, which is why routing clean-up comes first.

And settle ownership before kickoff. Code, database schemas, machine connectivity adapters and documentation should be yours, running in your cloud account or on-premise at the plant, with no per-seat or per-station meter. That absence of a meter is a large part of why a three-shift, multi-plant operation builds in the first place, and it is worth nothing if the software is licensed back to you.