MES Integration Cost: You Are Buying A System And Paying For An Integration

A manufacturer receives a quote for a manufacturing execution system. The licence is a recognisable number. Underneath it sits a line called implementation that is two or three times larger, and nobody in the room can say what is inside it.

That line is the integration, and it is the whole project. MES integration cost tracks how many systems, stages and vendors your product passes through, rather than tracking the licence price, and two manufacturers with identical output can receive quotes that differ by a factor of three for entirely legitimate reasons.

What an MES actually does that an ERP does not

Worth settling in a paragraph, because a meaningful number of MES projects should have been ERP configuration projects.

An ERP knows what was planned and what was accounted for. It holds the work order, the bill of materials, the cost and the stock position. It is a system of record and it thinks in transactions.

An MES knows what actually happened, at what time, on which machine or line, by whom, and with what result. It thinks in events. The gap between the two is where scrap, rework, downtime and real cycle time live, and that gap is exactly what a customer audit asks you to evidence.

If the questions you cannot answer are planned against actual, where a batch went, or why yesterday's output was low, an MES is the right shape. If the questions are about stock accuracy and costing, that is usually ERP work with a scanner attached, and it costs a fraction as much.

The decision that drives the number

Before any vendor conversation, answer this: what is the smallest unit you will track, and does it carry an identity?

The options run from tracking a work order as a single object, through tracking a batch or lot, to tracking a bundle or a carrier, down to tracking an individual unit with a serial. Each step down multiplies the number of events, the number of scans, and the amount of physical marking on the floor.

In apparel this is the bundle question. A cut order becomes a lay, the lay becomes bundles, and whether those bundles carry identity decides whether you can answer where a defect entered. Tracking at bundle level means bundle tickets, a scan at every operation, and a data model that holds bundle genealogy back to the lay and the marker. Tracking at cut order level means far less of everything and a far weaker answer.

Neither is wrong. What is wrong is picking one implicitly. Teams that never make the decision end up with bundle tickets printed and nobody scanning them, which is the worst of both: the cost of the marking without the data.

A useful way to settle it is to write down the questions the business needs to answer, then pick the coarsest unit that answers all of them. If the only real requirement is planned against actual output per line per shift, work order level is enough and everything below it is expenditure with no buyer. If a brand audit requires you to identify which lay a defective garment came from, bundle level is the floor. Deriving the unit from the question rather than from the vendor's demo is the difference between a system that pays for itself and one that produces impressive screens nobody opens.

Two consequences follow directly.

Event volume scales with the decision. A plant running 8 operations that tracks at unit level generates 8 events per unit. The same plant tracking at bundle level with bundles of 20 generates one fortieth of that. This decides your infrastructure, your network at the floor, and whether an offline mode is a nice to have or a requirement.

Genealogy depth follows it. One up one down traceability, meaning what went into this and where did it go, is only as good as the identity you maintained. A recall exercise is the test, and the answer is decided by this choice rather than by the software.

Work that leaves the building

The section that separates a real estimate from a hopeful one.

Most mid-market manufacturers send work out. In apparel it is job work: cutting, embroidery, printing, washing, sometimes stitching, each at a different vendor with its own premises and its own paperwork. In engineering it is plating, heat treatment or coating. Every stage that leaves your building is a stage where you lose event capture unless you build for it.

The naive design assumes a scan at despatch and a scan at receipt, and treats the middle as a black box. That works until a customer asks what happened during those 6 days, or until quantities do not reconcile and nobody can say whether the loss happened at the vendor or in transit.

Three requirements for outwork stages, all of which cost real hours:

Reconciliation per stage. Sent quantity, received quantity, expected yield, and the variance explained rather than absorbed. Fabric sent for cutting comes back as pieces and remnants, and the yield is a number somebody has to own.

A vendor-facing capture surface. A simple portal or a mobile app the vendor's supervisor actually uses. Anything requiring their IT department will not be used, and paper returning by hand is what you are replacing.

Ownership and liability at each handover. Whose stock is it while it sits at the vendor, and who carries the loss. This is a data model question before it is a commercial one, and getting it wrong means your stock valuation is wrong for as long as work is out.

There is a fourth requirement that only appears in practice. Vendors work for several customers, and your work sits alongside somebody else's. Any capture surface you give them has to be quick enough to use during a real shift and has to survive the vendor having no reliable network, which usually means a mobile app that works offline and syncs when it can rather than a web portal that assumes connectivity.

Count your outwork stages and your vendor count before reading any quote. A build with 2 in-house stages and no outwork is not the same project as one with 5 stages across 12 vendors, and the second is where most of the cost difference between quotes comes from.

Machine connectivity is rarely the hard part

Teams expect the machine integration to dominate and it usually does not.

Where equipment is modern, the protocols are settled: OPC UA where the controls support it, MQTT for lightweight telemetry, MTConnect on machine tools. Connecting a machine that speaks one of those is a known quantity, typically 30 to 80 hours for the first of a type and considerably less for each subsequent identical unit.

The awkward cases are real and they are bounded. Older equipment with no interface needs a sensor and a small edge device, and counting cycles from a proximity sensor is unglamorous and works. Some machines expose nothing useful at all, and the honest answer there is manual capture at the operation.

The genuinely hard part is the reason code rather than the machine. A machine can tell you it stopped. It cannot tell you why. Downtime reasons come from an operator choosing from a list, and the quality of that list decides whether your OEE number is useful or decorative. A list with 40 reasons gets the first option selected every time. A list with 6, agreed with the people who use it, produces data somebody can act on.

Unit of measure is where the numbers go wrong

The quiet failure that produces confidently wrong reporting.

A roll of fabric is bought in metres, issued in metres, cut against a marker measured in metres, and yields pieces counted in units, with remnants that are metres again. Somewhere in that chain a conversion happens, and if it happens in three places with three definitions, the variance report is fiction.

The same pattern shows up everywhere: cases and eaches, kilograms and units, sheets and parts. Hold the conversions in master data with a single owner, never in application code, and add a test that fails the build on a hardcoded factor.

Where the marker report exists, it is the source of truth for the fabric line, and getting it into the costing engine matters more than any dashboard. A costing model fed by an estimate rather than by the actual marker efficiency will disagree with reality by a margin that compounds across every style.

Dyelot and shade add a second axis to the same problem. Two rolls of the same fabric code are not interchangeable if they came from different dyelots, and a system that treats them as one stock line will cheerfully allocate across a shade break that a customer will reject. The identity has to sit at roll level and travel through cutting into the bundle, which is another argument that lands on the tracking unit decision above rather than on any feature list.

Remnants are the third. Fabric left after cutting is real value, it is measured in the same unit as the roll it came from, and most systems either lose it or double count it. Decide whether a remnant returns to stock as a distinct object with its own dimensions, and whether it can be allocated to a later cut. That decision is cheap in design and expensive as an afterthought, because it changes what a stock figure means.

Adoption is a design constraint, not a training plan

The plant floor decides whether the project worked, and it decides on ergonomics rather than on features.

An operator paid on rate will optimise for rate. Add three taps to an operation and the scans happen at the end of the shift in a batch, or one badge gets shared, and the timestamps you are collecting become fiction that looks like data. This is not a discipline problem. It is a design problem with a predictable outcome.

Design to the physical sequence. One scan where a scan already made sense. A screen readable at arm's length by somebody wearing gloves. An offline mode that works, because floor networks drop and a system that stops when the network does gets abandoned within a week.

Make it an acceptance criterion rather than a hope. Measure the scan compliance rate per operation in the first month, and treat anything under 95 percent as a design defect rather than a training gap. Quality capture belongs at the operation and inline rather than at the end of the line, because a defect count attributed to the whole garment tells you nothing about where it entered.

Defects per hundred units is the measure most plants already understand, and it only becomes actionable when it is attributed to an operation. A line running at 8 defects per hundred units tells a supervisor there is a problem. The same figure broken down by operation tells them which machine to look at before lunch. That attribution is a data model decision made during design, not a report that can be added later, because the events either carried the operation or they did not.

Hardware choice belongs in the same conversation. A rugged handheld that survives being dropped on a concrete floor costs more than a consumer tablet and lasts several times longer in that environment, and the replacement rate is a line in the running cost that nobody puts in the business case. Where gloves are worn, capacitive screens stop working, which is the kind of detail that only surfaces when somebody spends a shift on the floor rather than in a meeting room about the floor.

What it costs, with the hours shown

Published rates, published hours, arithmetic you can argue with.

Component	Hours	Note
Work order and routing model	140 to 300	Stage count drives it
Identity and genealogy at the chosen unit	180 to 420	The decision above lands here
Shop floor capture app, offline tolerant	220 to 460	Designed to the scan sequence
ERP integration, per system	80 to 200	Tally is XML over HTTP, not a modern API
Each machine type connected	30 to 80	First of a type, less for each repeat
Outwork stage with vendor capture	90 to 200	Per stage, plus reconciliation
OEE, downtime reasons and reporting	120 to 260	The reason list is the deliverable

At $40 to $100 per hour by role, blending to $60 to $70, a single-site build with 3 in-house stages, 1 ERP integration and no outwork lands near 740 to 1,640 hours, so roughly $48,000 to $107,000 at a $65 blend. Add 90 to 200 hours per outwork stage and 30 to 80 per machine type. Phase one runs 12 to 20 weeks to a slice the floor actually uses, and that qualifier matters: adoption is decided on the cutting table and the sewing line rather than in user acceptance testing.

A sequence that reaches a usable slice

First, decide the tracking unit and write it down. One line. It determines the event volume, the genealogy depth and roughly half the cost.

Second, master data and unit conversions. Unglamorous, gating, and the reason projects stall in month three when nobody funded it.

Third, one production line end to end, including its quality capture, before adding a second. Resist breadth until one line produces numbers the plant manager believes.

Fourth, the ERP integration with a reconciliation report as a named deliverable rather than a report somebody promises later.

Fifth, outwork stages, which are the hardest and benefit from everything learned on the internal ones.

Sixth, and only now, OEE and dashboards. Building these first is the most common sequencing error, because a dashboard fed by incomplete scans teaches everyone to distrust the system before it has had a chance to work.

One thing to run in parallel from week one: a weekly reconciliation between what the floor recorded and what the ERP accounted for, on a single product, by hand if necessary. It is tedious and it is the only reliable early warning that the two systems are drifting. A mismatch found in week 3 is a mapping bug. The same mismatch found in month 6 is a data cleanup with a quarter of history behind it.

Two questions before you read any quote. What is the smallest unit you will track, and how many stages happen outside your building? Those two answers explain most of the difference between any two numbers you are given, and neither of them is a question about software.