MES Software Development: A Buyer Guide for Plants Still Scheduling on Whiteboards

Why an MES makes or breaks a multi-plant manufacturer

It is 6:10 a.m. at your second plant. The production meeting happens in front of a whiteboard covered in magnetic job cards, because the whiteboard is the only place the real schedule exists. Epicor says work order 4471, five hundred weldments, ships Friday. The whiteboard says the weld cell lost its second certified welder to a dentist appointment and the powder line is running a rush job that never touched the system. While the meeting runs, a shift supervisor sits at a terminal keying yesterday's paper travelers into the ERP, forty five minutes of typing that makes it accurate as of last night, which is to say, wrong.

This is the normal condition for manufacturers between roughly $20 million and $300 million in revenue. The enterprise resource planning system, whether it is NetSuite, Epicor Kinetic, SAP Business One, or Dynamics 365 Business Central, does exactly what it was bought to do: quotes, purchase orders, inventory dollars, invoices. It stops at the shop floor door. Everything between work order released and work order complete lives on whiteboards, paper travelers, and an end-of-shift spreadsheet, and that gap is precisely where your margin is decided.

Run the numbers on your own operation. Three plants, three shifts, a shift lead spending forty five minutes per shift transcribing travelers: that is over thirty hours a week of supervision spent typing. Add expedite fees discovered at packing and the customer who quietly resourced after the third late shipment. A manufacturing execution system, MES, is the layer that closes this gap. The six-figure question is whether you rent one off the shelf or build one that matches how your plants actually run.

Problem: your ERP thinks in work orders, your floor runs in operations

The ERP releases work order 4471 as a single object with a quantity and a due date. Your floor sees seven operations: saw, deburr, brake, weld, inspect, powder coat, pack, spread across four work centers with an outside plating step in the middle. The ERP has no opinion about any of that until someone backflushes the completion. So the material handler finds work in process by walking the aisles, and the answer to "where is job 4471 right now" is always "let me go look."

This is not a configuration problem you can fix inside the ERP. NetSuite and Business Central track order status, not operation status. Epicor's scheduling module assumes the data underneath is current, and it is a shift behind by design because updates depend on humans typing at the end of the day. Infinite capacity MRP dates were never meant to sequence a Tuesday afternoon on the brake press.

A custom MES puts a dispatch list on a tablet at every work center: what to run next, in what sequence, with the traveler, drawing, and setup sheet attached. Operators scan on at operation start and scan off at completion, so WIP is visible in real time without anyone typing at shift end. Digital Heroes builds the ERP sync as a two way contract: work orders and routings flow down, completions, scrap, and labor flow up, with a reconciliation screen for the ERP administrator instead of a mystery when counts drift. Finance keeps its system of record. The floor finally gets a system of execution.

Problem: machine data dies inside the PLC

Your CNC machines, presses, and packaging lines already know their cycle counts, fault codes, and run states. That data lives and dies inside a programmable logic controller, PLC, that nothing else reads. So overall equipment effectiveness, OEE, gets computed in a spreadsheet once a month from operator logs, and it flatters everyone: the 22 minute changeover recorded as 10, the micro stops that never get written down at all. In our experience, a plant that believes it runs at 75 percent measures closer to 55 once the machines are finally instrumented.

The ERP cannot help because it has no machine connectivity, and bolting on a historian gives you timestamps with no production context: it can say the machine stopped at 2:14 p.m., but not which order was running, who was at the station, or whether the stop was a die change or a jam.

A custom build connects machines over OPC UA or MTConnect where the controller supports it, and over Modbus, retrofit sensors, or current monitoring for the 1994 press with no network port. The MES joins machine events to the order and operator context it already holds. When a stop exceeds a threshold you define, the station tablet asks for a reason code within seconds, while the operator still remembers. OEE stops being a monthly argument and becomes a live number per shift, per machine, per part.

Problem: one quality claim triggers a three-day paper chase

An automotive customer emails: a bracket cracked at their line, and they want every shipment containing material from the same steel coil identified by Thursday. In a paper plant, two quality engineers spend three days pulling travelers from banker's boxes and cross referencing heat numbers against receiving logs. Then you over scope the containment because you cannot prove which lots are clean, and you pay to sort or scrap product that was fine.

ERP lot control does not solve this because it is blind through WIP: the system knows which coils you received and which finished goods you shipped, but the linkage between them was handwritten on a traveler, if it was captured at all.

A custom MES enforces genealogy at the point of consumption: the saw operation cannot start until the coil tag is scanned, and every downstream operation inherits the chain. Forward and backward trace becomes a query that runs in minutes: this coil touched these 14 work orders, which shipped in these 40 cartons to these 3 customers. For shops selling into automotive or aerospace, this is what IATF 16949 and AS9100 auditors want demonstrated, not described.

Problem: scrap shows up five weeks later as a variance nobody can explain

The controller closes the month and finds a six percent unfavorable material variance at plant one. Nobody can say which jobs, operations, or weeks produced it, because scrap was recorded as a single number on the traveler, if the operator remembered. By the time anyone investigates, the worn tooling that caused it has run 40 more jobs.

ERP quality modules capture scrap at completion, as a quantity, which is the information you already had. What you need is the reason, the operation, and the moment.

In a custom MES, scrap is reported at the station where it happens, with a reason code from your own taxonomy, tied to the operation, machine, operator, and material lot. A supervisor gets an alert the shift an operation's scrap rate crosses your threshold, not at month end. Quality holds stop a traveler in software: a held order physically cannot be scanned into the next operation until disposition. Rework loops, the thing generic tools model worst, get first class treatment because the workflow is built from your actual routing exceptions.

Problem: off-the-shelf MES forces your plant into someone else's model

The commercial MES market is real: Siemens Opcenter, Rockwell's Plex, Tulip, L2L. If they fit, use them. But mid market manufacturers hit three walls. Licensing is priced per user or per station, and a three shift plant multiplies every seat across all three crews; clients arrive at Digital Heroes holding six figure annual quotes before implementation has even been scoped. The implementation itself is integrator led and commonly runs 12 to 18 months, often costing more than the licenses. And most expensive of all, the platform has a process model, and where your plant differs, outside plating loops, shared work centers across value streams, one serialized product line inside a lot controlled plant, you either change the plant or pay to customize software you will never own.

Building inverts that. The data model starts from your routings and your exceptions. No per seat meter runs across three shifts and three plants. When you add plant four, you deploy software you own instead of renegotiating a license.

What custom MES development costs and how long it takes

These bands come from Digital Heroes delivery experience across 2,000+ projects, not an analyst report. A focused first release, typically one plant with operator stations, dispatch lists, scan based WIP tracking, scrap and downtime capture, and two way ERP sync, runs $60,000 to $130,000 and ships in 12 to 16 weeks. A full platform, machine connectivity across dozens of assets, finite scheduling, genealogy and recall tooling, multi plant rollout, runs $150,000 to $400,000 phased over 6 to 12 months, with the floor using release one while later phases are built.

What pushes MES toward the top of those bands: the number and age of machine integrations (five OPC UA capable CNCs are cheap, thirty mixed generation PLCs with two that predate ethernet are not), regulated traceability with electronic signatures, finite scheduling with your real constraints encoded, offline tolerance so a network blip never stops a line, and every additional site with a different process. Scanners, label printers, and ruggedized tablets are real line items but rarely the driver.

Build vs buy: an honest line in the sand

Buy when you are a single plant with under roughly 25 machines, your processes look like the demo (discrete assembly, linear routings, minimal rework), and you can absorb a platform implementation. Tulip or L2L on top of your ERP is a defensible answer there, and cheaper than building. Also buy if a parent company has already standardized on Opcenter or Plex; fighting corporate IT is not a project.

Build when any two of the following are true: you run multiple plants with different processes, the whiteboard still beats your ERP's 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. At $100,000 to $400,000 of budget, our position is direct: a multi plant, high volume operation with nonstandard flows should build the execution layer and keep the ERP for what it is good at. The companies that regret building are the ones that tried to rebuild the ERP too. Do not. Build the layer the ERP never covered.

How to choose a developer for MES software

First, make them draw your data model before you sign. A developer who has built MES will whiteboard work orders decomposing into operations, lots consuming into genealogy, serials, reason code taxonomies, and shift calendars without prompting. If the first diagram shows orders and statuses and nothing else, they are about to learn manufacturing on your budget.

Second, interrogate machine connectivity with specifics: which PLC families they have integrated, what they do with a controller that only speaks a 1990s serial protocol, how they timestamp events when the network drops. Vague answers here become change orders later.

Third, ask how the ERP sync fails. Not whether, how. The honest answer describes queues, retries, and a reconciliation view for when the ERP rejects a completion mid shift. Anyone who says the integration just works has not run one through a quarter end close.

Fourth, if you are audited, ask for compliance artifacts from past builds: append-only audit trails, electronic signature flows for FDA 21 CFR Part 11 if you touch medical or food, document control patterns for AS9100 or IATF 16949. Compliance retrofitted after the fact costs roughly what the first release did. Designed in from the first sprint, it is mostly discipline.