The two overlap a lot. The difference is mostly about scope, and about who the system is really for. Then there's MES/MOM, which has maintenance capability of its own and holds the downtime data both of them need. And there's ERP, which already covers more of the asset side than many people realise.

A quick note on terms. Strictly, MES covers production. MOM covers production, quality, inventory and maintenance, so it's MOM's maintenance capability I mean here. Most people search for "MES", so I use MES/MOM.

What a CMMS does

A CMMS (Computerised Maintenance Management System) helps a maintenance team get the work done. Its focus is the day-to-day:

• Maintenance work orders, from request to close
• Preventive maintenance schedules, by time or usage
• Labour and failure history for each asset
• Spare parts and the maintenance stores

It's usually run by the maintenance team, often for a single site. It's quick to implement, and many are cloud products priced per user.

What an EAM does

An EAM (Enterprise Asset Management) system manages physical assets across their whole life, from acquisition to disposal. It includes everything a CMMS does, and adds:

• The full asset lifecycle, including capital planning and replacement
• Asset costs and depreciation, linked to finance
• Reliability and criticality analysis
• Standards and performance across many sites
• Permits to work and contractor management for asset-heavy operations

It's usually owned at enterprise level, by asset management, engineering and finance as well as maintenance.

What ERP covers

ERP can do a fair amount of what an EAM does. Most ERPs already hold:

• The fixed asset register, with depreciation and asset value
• Capital projects and investment approvals
• Maintenance costs, spare parts purchasing and stores
• Supplier and contractor management

Many ERP suites go further, with maintenance orders and preventive schedules of their own, and some include a full EAM module. So before buying a separate EAM, check what your ERP already covers.

What MES/MOM does for maintenance

MES/MOM knows what each machine is doing right now: run hours, cycle counts, downtime and its reasons, speed losses and what the operator just reported. That's exactly what usage-based maintenance and MTBF need.

A MOM platform goes much further than supplying data. Its maintenance capability replaces the need for a CMMS, with production and maintenance in one connected platform. That brings benefits a separate CMMS can't match:

• One source of truth for downtime. Production and maintenance work from the same downtime records and the same KPIs, so nobody argues about whose numbers are right.
• Maintenance triggered automatically. A breakdown recorded on the line raises a maintenance request straight away, with the machine, the reason and the order already attached.
• Operators doing autonomous maintenance. Checks, cleaning and lubrication tasks appear on the screen operators already use, and anything abnormal goes straight to the maintenance team.
• One schedule both teams can see. Planned maintenance sits in the production schedule, so production and maintenance agree on when each machine is free.
• Preventive maintenance on real usage. Run hours and cycle counts come from the machines, not from estimates.

On top of that, you get the work orders, labour, spare parts and maintenance history you'd expect from a CMMS.

Side by side

Which do you need?

• Running, or choosing, a MOM platform? Its maintenance capability replaces the need for a CMMS.
• An MES for production only, or no shopfloor system yet, and the main problem is getting PMs done? A CMMS, fed with run hours and downtime from the MES where there is one, will work. But be aware that you'd be adding to a point solution architecture, which I advise against. The better option is to step back and re-evaluate your long-term vision for the shopfloor first.
• Leadership asking about asset value, replacement and capital spend? Check what your ERP covers first. It often handles the asset finances already.
• Asset-heavy, with advanced needs such as complex spare parts, reliability engineering, linear assets or regulatory asset records across many sites? That's where a full EAM earns its place.
• Unsure? Start with the problems. If nobody is asking about asset value or lifecycle cost, you probably don't need an EAM.

How they work together

With a MOM platform, maintenance work lives alongside production on the same data. With an MES focused on production only, the MES feeds run hours, counts and downtime to a separate CMMS, which plans and records the maintenance work. ERP holds the asset register and the costs. Where an EAM is also needed, MES/MOM covers the day-to-day maintenance and feeds counters and downtime to the EAM for asset management. Whatever the split, one system should own downtime reasons and one should own the work order. I cover that boundary in EAM, CMMS and MES: who owns the maintenance work order?

My view

A good MOM platform replaces the need for a CMMS. Its maintenance capability covers operator requests, work orders, preventive maintenance on actual run hours, and spare parts. Running a MOM and a separate CMMS side by side would be silly: two versions of downtime, and an interface to maintain between them.

If you run an MES that covers production only, it can feed a separate CMMS, and that works. But a full MOM is the better overall solution.

For the asset side, look to ERP first. It covers the asset register, depreciation and capital spend for most manufacturers, and some ERPs go much further. A full EAM is for asset-heavy businesses with advanced needs, where asset lifecycle and financial data go beyond what MOM and ERP cover together.

Which question is your maintenance system really answering today: getting the work done, or managing the assets?

Final yield: what comes out the end

Final yield is simply good units out divided by units started. If you start 1,000 and ship 970, final yield is 97%.

The problem is that it counts reworked units as good. A part that was fixed twice before it passed looks exactly the same as one that was right first time. That hidden rework costs time and capacity.

First pass yield: right first time, at one step

First pass yield (FPY), sometimes called first time yield, is the share of units that pass a step without rework or scrap. Some manufacturers, particularly in automotive, use first time through quality (FTTQ) for a similar measure, often across a whole process and counting any repair or retest as a failure.

FPY = units passing first time ÷ units entering the step

If 1,000 units enter a welding step and 950 pass without rework, FPY for that step is 95%.

FPY shows how well each step really performs. It's often measured for a single step, or for the line as a whole.

Rolled throughput yield: right first time, all the way through

Rolled throughput yield (RTY) is the probability that a unit gets through every step of the process right first time. You multiply the FPY of each step together.

RTY = FPY step 1 × FPY step 2 × FPY step 3 … and so on

Take a line with four steps, each with an FPY of 95%. RTY is 0.95 × 0.95 × 0.95 × 0.95, which is about 81%. So only 81 units in every 100 make it through without being touched again, even though every step looks good on its own and final yield might be 97%.

Side by side

Why it matters

RTY is the metric that reveals the "hidden factory": the rework loops and re-inspections that never show up in final yield. It's popular in Six Sigma for exactly that reason.

The weakest steps drag RTY down fastest, so it also tells you where to focus. Improving one poor step from 80% to 95% lifts RTY far more than polishing a step that's already at 99%.

Where the data comes from

To calculate FPY and RTY you need to know, at every step, which units passed first time and which were reworked. On paper, rework is often not recorded at all.

MES/MOM records each pass, fail and rework against the unit or lot and the operation, so FPY and RTY can be calculated automatically, by product and line. More in Manufacturing KPIs beyond OEE.

If you multiplied your step yields together today, how close would the answer be to the yield you report?

Industry 4.0: connected, data-driven manufacturing

Industry 4.0, the fourth industrial revolution, describes the shift to connected, data-driven manufacturing. The term came out of Germany in the early 2010s and spread quickly.

Its core ideas:

• Machines, sensors and systems connected, often through the industrial internet of things (IIoT)
• Data captured automatically, in real time
• Systems integrated vertically, from the machine to ERP, and horizontally across the supply chain
• Analytics, automation and AI used to optimise operations

Its focus is efficiency and productivity, largely through technology.

Industry 5.0: people, resilience and sustainability

Industry 5.0 is a concept set out by the European Commission in 2021. It doesn't replace Industry 4.0. It builds on it, and argues that technology should serve wider goals than efficiency alone.

It rests on three ideas:

• Human-centric: technology that supports and develops people on the shopfloor, rather than replacing them
• Resilient: operations and supply chains that can absorb disruption
• Sustainable: using resources and energy responsibly, and reducing waste

You'll also hear Industry 5.0 used to mean collaboration between people and robots, or "cobots". That's part of the picture, but the European Commission's framing is broader.

Side by side

What it means on the shopfloor

In practice the two overlap heavily.

Human-centric looks a lot like connected worker done well: digital work instructions, and AI that helps an operator rather than watches them. More in Connected worker vs MES and AI for frontline workers.

Resilient depends on knowing what's actually happening, in real time, so you can react when a supplier or a machine lets you down.

Sustainable needs energy, scrap and yield measured by machine and product, not estimated once a year. More in You can't hit ESG targets without shopfloor data.

All of those need the same foundation Industry 4.0 asked for: accurate, contextualised shopfloor data, captured as it happens. That's the job of MES/MOM.

My view

Industry 5.0 is a useful shift in emphasis, and it matters most when you build it into the same programme rather than treating it as a new one. I'd rather describe what something does than give it a version number. A smart factory is defined by outcomes, not by which revolution it belongs to, and you'll even see talk of Industry 6.0 now.

What Industry 5.0 does usefully is remind us that the point of all this technology is better work for people, sturdier operations and less waste, as well as more output.

Which of those three is furthest behind in your factory today?

Each one measures something different.

MTBF: how long it runs between failures

MTBF (mean time between failures) is the average time a repairable asset runs before it fails.

MTBF = total operating time ÷ number of failures

If a filler runs for 1,000 hours in a quarter and fails five times, its MTBF is 200 hours. Higher is better: the asset is more reliable.

MTTR: how long it takes to fix

MTTR (mean time to repair) is the average time it takes to get a failed asset running again.

MTTR = total repair time ÷ number of repairs

If those five failures took 15 hours to fix in total, MTTR is three hours. Lower is better: you recover faster.

Be clear what's included. Some sites measure only hands-on repair time. Others include waiting for a technician and spare parts. The second is what production actually feels, so it's usually more useful.

MTTF: how long it lasts

MTTF (mean time to failure) is the average time a non-repairable item lasts before it fails and is replaced. Think bearings, seals, sensors or light sources.

MTTF = total operating time ÷ number of items that failed

It helps you plan replacement intervals and spare parts stock.

Side by side

How they relate to availability

MTBF and MTTR combine into a simple measure of availability:

Availability = MTBF ÷ (MTBF + MTTR)

With an MTBF of 200 hours and an MTTR of three hours, availability is about 98.5%. Improve either side and availability goes up. That's the same availability that feeds OEE. More in What is OEE?

Where the data comes from

All of them depend on knowing exactly how long each stop lasted and why it happened. If downtime is written on a sheet at the end of the shift, short stops vanish and the reasons are guesses.

MES/MOM records each stop from the machine as it happens, with the reason and the order attached. That gives MTBF and MTTR a reliable basis, and gives maintenance planning the data it needs, whether in MOM or an EAM. More in CMMS vs EAM vs MES and maintenance strategies.

Do your maintenance and production teams calculate MTBF from the same downtime data?

The simplest way to separate them is by layer. Each one does a different job, at a different speed.

PLC: controlling the machine

A PLC (programmable logic controller) is a rugged industrial computer that controls a machine or a section of a line. It reads sensors, runs its program in a continuous scan, often every few milliseconds, and drives motors and valves.

PLCs sit at ISA-95 levels 1 and 2, right next to the equipment. They're built to run for years without stopping, and they keep running whether or not anything above them is connected. Most machines you buy come with one.

SCADA: supervising the equipment

SCADA (supervisory control and data acquisition) sits above the PLCs. It collects data from them and shows operators and engineers what the equipment is doing. It also raises alarms and lets people change setpoints. It's common in discrete plants, and across utilities spread over large areas.

SCADA sits at ISA-95 level 2. Its focus is the equipment, in real time.

DCS: controlling a process plant

A DCS (distributed control system) does a similar job to PLCs and SCADA combined, but is designed as one integrated system for large, continuous or batch process plants. Control is distributed across controllers around the plant, with operator consoles in a central control room. It holds temperatures, pressures, flows and levels at their setpoints, continuously.

Many DCS platforms include a batch manager that runs recipes in line with the ISA-88 batch standard. A DCS spans ISA-95 levels 1 and 2, and it's the heart of most chemical and pharmaceutical plants.

The line between a DCS and a PLC-plus-SCADA system has blurred over the years. As a rough guide, a DCS is chosen for large, tightly integrated process control, and PLCs with SCADA for machines and lines.

MES/MOM: managing the operation

MES/MOM sits above the control layer at ISA-95 level 3. It manages the operation rather than the equipment. It takes orders from ERP and guides operators through the work. It records what was made and what went into it, along with downtime and its reasons, quality results and the genealogy of every lot.

Its focus is the order, the material, the people and the evidence. Its time scale is minutes and shifts.

Side by side

Where they overlap

Visibility. SCADA, a DCS and MES/MOM can all show what a machine is doing. Often they read the same data from the same PLCs. Where SCADA is used mainly for visibility, MES/MOM can sometimes cover it. More in SCADA vs MES: what each one does, and do you need both?

Recipes. A DCS batch manager runs the control steps of a recipe. MES/MOM manages the order and material side: which lots are used, and the batch record. The boundary is the batch, and getting it right matters in regulated industries. More in ISA-88 and ISA-95: how the two standards fit together.

Sending data down. Some MES/MOM platforms send setpoints and recipes to the machine, as well as reading data up. Typically MES/MOM writes the values to tags through an OPC server, using a proper handshake. It sends the data, the values are copied into the tags, then the tags are read back and compared with what was sent. Only when they match is the machine cleared to run.

Doesn't the control layer already do this?

It does some of it. But PLCs, SCADA and a DCS are designed to control equipment, not to manage orders, material status, quality release or genealogy across the plant.

Some sites stretch the control layer to do more through custom code. It can work, but it pushes business logic into systems that weren't designed for it, and every change then carries control-system risk and validation effort.

How they connect

Data flows up from the control layer to MES/MOM, often through OPC UA or MQTT. MES/MOM adds the context of the order and the lot, then passes what the business needs to ERP. Instructions flow down the same path.

That's the ISA-95 model in practice. More in ISA-95 explained and OPC UA vs MQTT.

Which do you need?

• Every plant has PLCs, because the machines come with them.
• Large process plants are more likely to run a DCS.
• Utilities, such as water and energy networks, typically use SCADA to supervise equipment spread over a wide area. Discrete plants more often rely on PLCs with an HMI at each machine, though some use SCADA to supervise a line or a whole site.
• Anyone who wants to manage orders, quality and traceability on facts needs MES/MOM above the control layer.

If batch records are still assembled on paper, or downtime reasons still live on a whiteboard, it's the MES/MOM layer that's missing, not more control.

Which layer in your plant has the least reliable data today?

They overlap in places. But each is built for different work, and different people.

A quick note on terms. Strictly, MES covers production. MOM, manufacturing operations management, covers production, quality, inventory and maintenance. Most people search for "MES", so I use MES/MOM here, but it's the quality capability of MOM that matters.

What a QMS does

A QMS (Quality Management System) runs the processes that keep quality under control across the business. It works over weeks and months, and across sites and suppliers:

• Root cause investigations, CAPA (corrective and preventive action) and non-conformances
• Customer complaints
• Audits and certifications, such as ISO 9001, IATF 16949 or GMP
• Document control, change control and training records
• Supplier qualification and supplier quality

Its users are quality managers, QA, auditors and process owners. Its output is evidence that the system works, and actions that make it work better.

What a LIMS does

A LIMS (Laboratory Information Management System) runs the lab. It works in hours and days, sample by sample:

• Samples, labels and chain of custody
• Test methods, specifications and limits
• Results, often captured directly from lab instruments
• Analyst workload and lab scheduling
• Certificates of analysis (CoA) and stability studies

Its users are lab analysts and lab managers, with QA reviewing the results. Its output is a trustworthy result for every sample.

What MES/MOM does for quality

MES/MOM runs quality at the point of production, in real time and against the order that's running:

• Inspection plans and sampling, triggered by what's actually happening on the line
• In-process checks and SPC on critical characteristics
• Goods-in inspection of incoming material
• Non-conformances recorded at the source, with the order, lot, machine and operator attached
• Holding and releasing lots, so suspect material can't be consumed
• Batch release, drawing on the batch record and the test results

Its users are operators, team leaders, supervisors and quality technicians on the floor. Its output is quality data with full production context, captured as it happens.

Sampling triggered by events

This is one of the strongest reasons to run quality in MOM. Because MOM sees production, quality, inventory and maintenance events as they happen, any of them can add a check to the operator's list:

• An order starts, or the first part comes off after a changeover
• A tool is changed, or a mould goes back in after maintenance
• Inventory is created, or a new lot of material is consumed
• An out-of-spec measurement or a critical defect is recorded
• A process parameter trends above a threshold

The check arrives with everything already filled in: the order, material, lot, machine and operator. Nobody has to type any of it, and nobody has to remember to do the check.

Side by side

Where they meet

Non-conformances and CAPA. A non-conformance is found on the line and recorded in MES/MOM with full context. Serious or repeat issues, and the CAPA that follows, are best escalated into ERP, where the cost, supplier and customer sides are handled. They shouldn't be managed entirely inside MES/MOM, or a QMS on its own.

Incoming material. Goods-in inspection can run in MES/MOM. Results that affect how the supplier is paid, or that need taking up with the supplier, pass to ERP, which handles the commercial side. You don't need a LIMS for that.

Batch release. MES/MOM can release batches, drawing on the batch record and the test results, and an open deviation can block release. Pick one system for the decision and stick to it.

Specifications. Where a LIMS is used, it holds the lab test limits. MES/MOM holds the in-process limits. Agree which system is the master for each.

When you need a LIMS

The main reason for a LIMS is a lab with a heavy sample load, many instruments and strict regulations around them. That's mostly found in a few industries:

• Pharmaceuticals and biotech
• Chemicals and petrochemicals
• Food and dairy plants with their own microbiology labs
• Metals, mining and materials testing

Even there, a LIMS isn't always needed. Where the testing is simple, or done by an external lab, MOM can record the samples and results itself.

There's more on the boundaries with MES/MOM in QMS and MES: closing the quality loop and LIMS and MES: getting lab results to the line.

Which do you need?

• Defects found too late, or quality data without context? Start with quality in MOM.
• Certified or regulated? MOM, with non-conformances and CAPA escalated into ERP. A separate QMS rarely adds enough to justify it.
• Testing incoming materials? Goods-in inspection in MOM, with supplier issues passed to ERP.
• A large regulated lab? That's when a LIMS earns its place.

My view

A good MOM platform is the place to run quality. It manages the inspection plan, triggers checks from what's actually happening, captures every result with full context, and holds and releases material. Serious non-conformances and CAPA then escalate into ERP, where the business side is handled. With MOM and ERP working together, a separate QMS adds little.

If you run an MES that covers production only, it can feed a separate QMS with non-conformances and results, and that works. But a full MOM is the better overall solution.

A LIMS is a specialist tool for a heavy, regulated lab, in a handful of industries. Most manufacturers don't need one.

Where does an out-of-spec result go in your business today, and how long does it take to get there?

Each one answers a different question.

Takt time: the pace demand sets

Takt time is the rate you need to produce at to meet customer demand. It comes from the German word for a beat or pulse.

Takt time = available production time ÷ customer demand

If a line runs for 450 minutes a shift and customers need 900 units a shift, takt time is 30 seconds. To keep up, you need to finish one unit every 30 seconds.

Takt time comes from demand, not from the process. It's the target the line has to hit, and the starting point for line balancing.

Line balancing is how you meet it. It spreads the work across stations so each one's tasks fit within takt time, with as little idle time as possible, so material flows from station to station without piling up or running dry. On a paced line, such as a moving automotive assembly line, the line is then set to advance at that pace, sometimes slightly faster to allow for losses, and you'll often hear "takt" used for the fixed time each unit spends at every station. When demand changes, takt changes, and the line is re-balanced or the shift pattern adjusted.

Cycle time: how fast you actually work

Cycle time is how long it actually takes to complete one unit, or one step, from start to finish. You measure it on the line.

People use it in slightly different ways. It can mean the time for one operation, or for a unit to pass through the whole line. Agree which one you mean before you compare numbers.

In batch and process manufacturing, cycle time is often a fixed time rather than a time per piece: the planned time for the recipe or batch, such as a mixing, cooking or curing step. There, you compare the actual batch time with the recipe's planned time.

If cycle time is longer than takt time, you can't keep up with demand without overtime or more capacity. If it's well under takt time, you have spare capacity, or more resources than you need.

Lead time: how long the customer waits

Lead time is the total time from a customer placing an order to receiving it. It includes everything: order processing, waiting for materials, queuing between operations, processing itself, inspection and shipping.

Manufacturing lead time is the shopfloor part of that, from releasing an order to finishing it.

In most factories, processing is a small fraction of lead time. Most of it is waiting.

Side by side

How they relate

The three tell a story together.

Cycle time against takt time tells you whether you can meet demand. Compare them station by station and the bottleneck usually jumps out.

Lead time against total cycle time tells you how much waiting is in the system. If a product needs 40 minutes of actual work but takes five days to get through the factory, the opportunity is in the queues, not the machines.

Where the real numbers come from

Planning systems often use standard cycle times that someone entered years ago. Actual cycle times drift with product mix, operators, tooling and machine condition.

MES/MOM measures them as work happens: actual cycle times by product and machine, along with the waiting between operations. That replaces estimates with measured values, and keeps schedules realistic. More in APS vs ERP scheduling and Manufacturing KPIs beyond OEE.

When did you last compare your standard cycle times with what the line actually does?

The quickest way to separate them is by the question each one answers.

What ERP does

ERP (Enterprise Resource Planning) runs the business side of a manufacturer on one set of data: finance, sales orders, purchasing, inventory value, costing and, in most suites, HR. It's the system of record for money, customers, suppliers and stock value.

ERP thinks in days to months, and at the level of orders and totals.

What MRP does

MRP (Material Requirements Planning) works out what to make and buy, and when. It takes demand from sales orders and forecasts, explodes it through your bills of materials, nets off stock and open orders, then uses lead times to suggest planned production and purchase orders.

In most companies MRP is a module inside ERP rather than a separate system. Standalone MRP software also exists, usually for smaller manufacturers who don't need a full ERP suite yet. MRP II extended the idea to capacity and other resources, and is where much of modern ERP came from.

MRP mostly assumes infinite capacity, which is why many manufacturers add an APS for detailed scheduling. More in APS vs ERP scheduling.

What MES/MOM does

MES/MOM runs the work on the shopfloor. It releases the orders the plan creates to lines and operators, and guides people through each step. It records what was actually made and what went into it, along with downtime, scrap, quality results and the genealogy of every lot.

MES/MOM thinks in seconds and minutes. Its output is the truth about what actually happened, with the context attached.

Side by side

MRP vs ERP

If you're a small manufacturer choosing between standalone MRP software and an ERP, the difference is breadth. MRP covers planning and materials. ERP adds finance, sales, purchasing, costing and much more on the same data.

Either way, neither one is designed to run the shopfloor in real time.

How the three work together

The loop is simple in principle. MRP plans the orders. ERP releases them to MES/MOM. MES/MOM runs them and sends back what actually happened: quantities, scrap, material consumed, time taken.

That feedback is what keeps the next MRP run honest. If stock levels and yields are accurate and timely, the plan is built on reality. If they're keyed in late and rounded, MRP plans from fiction, and planners end up overriding it with spreadsheets.

Master data matters just as much. All three depend on the same BOMs, routings, units of measure and work centres being right. More in Your ERP master data isn't ready for MES.

Can ERP or MRP run the shopfloor on their own?

Some manufacturers book production straight into ERP at a terminal, typically every hour or at the end of the job or shift. It's a real step forward from paper, and ERP knows the order started and finished.

What it doesn't capture is what happened in between: the short stops, the reason for the scrap, detail on traceability and actual consumption, whether the check was done. That isn't ERP's job, and it's exactly what MES/MOM is for. More in MES vs ERP.

How accurate is the data your MRP plans from today?

They answer different questions.

ISA-88: how to control a batch

ISA-88, often called S88, is the standard for batch control. Its first part was published in 1995, and it's also adopted internationally as IEC 61512.

It gives you a common way to describe batch manufacturing:

• A physical model of the plant, from site and area down to process cells, units, equipment modules and control modules.
• A procedural model of how a batch is made, from the procedure down to unit procedures, operations and phases.
• A process model describing the stages and operations of the process itself, independent of the equipment.
• A recipe model that separates what to make from the equipment it's made on, so the same recipe can run on different units.

The big idea is separating the recipe from the equipment. Engineers build reusable phases once, such as charge, heat, agitate or transfer, and recipes combine them. That makes recipes far easier to change and reuse.

ISA-88 lives mostly at the control level, inside the DCS or batch manager.

ISA-95: how operations connect to the business

ISA-95 is the standard for integrating enterprise and control systems. Work on it began in the mid-1990s, Part 1 was published in 2000, and its core parts are adopted internationally as IEC 62264.

It's best known for the functional hierarchy, the familiar levels 0 to 4, and for defining the four areas of manufacturing operations: production, quality, inventory and maintenance. It also defines the objects that ERP and MES/MOM exchange: orders, materials, equipment, personnel and performance.

ISA-95 lives mostly at level 3 and the boundary with level 4. More in ISA-95 explained.

Side by side

Where they meet

The two standards were designed to fit together, and they overlap in a few places.

Equipment hierarchy. Both describe the plant as a hierarchy. ISA-88's process cells and units sit neatly under ISA-95's areas and work centres, so you can use one consistent model from ERP down to the control module.

Recipes and batch execution. ISA-88 defines general, site, master and control recipes. The upper ones are closer to product definitions in ISA-95, which MES/MOM manages, while the control recipe runs in the batch manager. MES/MOM handles the order and the materials, and the batch manager runs the phases. ISA-95 describes the exchange between them, and ISA-88 describes what happens inside.

Which do you need to know?

• Batch process plants: both. ISA-88 for how the control system runs the recipe, and ISA-95 for how that connects to MES/MOM and ERP.
• Discrete manufacturers: ISA-95 is the one that matters most. ISA-88's ideas about separating product from equipment are still worth knowing.
• Anyone integrating ERP and MES/MOM: start with ISA-95. It gives everyone a common vocabulary, which saves weeks of arguments about what "batch" and "lot" mean.
• Vendors and integrators serving process industries: both, because your customers will expect you to speak each one.

For the control side of the boundary, see PLC vs SCADA vs DCS vs MES.

Do your control engineers and your MES team use the same names for the same equipment?

It's a common question, often after a convincing demo. A unified namespace (UNS) has become a popular topic, and some people argue it can replace a traditional MES. Others see it as a way of connecting MES/MOM to everything else.

This article sets out what a UNS is, what MES/MOM does, and the risks and alternatives worth knowing about.

What a UNS is

A unified namespace is an architectural pattern rather than a product. It's a real-time view of whatever operational data connected applications have published to it, usually through an MQTT broker, organised by the plant hierarchy: enterprise, site, area, line, machine. Systems that need the data subscribe to it.

The idea is that each system connects once, to the namespace, rather than to each other. But point-to-point interfaces have strengths a UNS doesn't: the sender gets a response, so it knows each message arrived and was accepted, and a failure stays contained to one link.

Strip it back and a UNS is a way of organising data on top of a broker. It shows what's happening right now.

What MES/MOM is

MES/MOM is an application that runs the operation. It releases orders, guides operators through the work, enforces checks, records what was made from what, and stores the history with its context: the order, the material lot, the operator, the reason.

It also makes decisions in the moment. It can stop someone consuming a quarantined lot, or trigger an inspection because the material changed.

Side by side

Can a UNS replace your MES?

For visibility, partly. For running the operation, no.

The overlap is mostly in visibility. If what you need is live machine status and counts on a dashboard, a UNS with some light applications around it can show some of that.

It gets harder as soon as you need history or transactions. OEE is a good example. You can publish the current OEE to a UNS. But you can't aggregate OEE figures by order or by shift from the published values. You have to go back to the raw data, stored somewhere that keeps it, and calculated consistently, ideally to ISO 22400.

The same goes for genealogy and quality records, and anything an auditor will ask about. A UNS passes the data through. Something else has to keep it and give it meaning.

Risks and alternatives

It's worth being clear about the risks before you commit to one.

• No confirmation to the sender. Publishing is fire-and-forget: the sending system doesn't know whether anyone received or processed the data. That's a poor fit for transactions such as order releases, consumption and quality holds.
• Data can go missing quietly. Without confirmation, data can fail to reach the systems it's meant for, and errors as data moves between platforms aren't visible. You find out when the numbers don't match.
• No history or meaning on its own. It shows the current state. Something else has to store the history and add the context.
• It gets messy quickly. Without strong ownership, topic structures and payloads drift, and the namespace soon becomes a large pile of tags.
• The broker and security. The broker becomes a critical piece of infrastructure, and a hub that everything can publish to and read from needs careful access control.

The alternatives are well proven. Direct interfaces through standard APIs give a confirmed response for transactions, and integration through ERP keeps business transactions in one place. For analytics and AI, a data platform brings the history together. Most architectures use a mix, chosen flow by flow.

Where a UNS is used alongside MES/MOM

Where a UNS is in place, MES/MOM can subscribe to the machine data it needs, add the context of the order, the material lot, the operator and the shift, and publish that contextualised data back. Anything that must arrive, such as order releases, confirmations and quality status, should still go through interfaces that confirm it did.

Where to start

• Mainly live visibility? A UNS can show current machine status, but plan for what comes next. As soon as you need history, transactions or traceability, you'll need more than a UNS.
• Orders, quality, traceability and enforced processes? You need MES/MOM, connected to the rest through interfaces that confirm data arrived.
• Lots of systems that need the same data? Direct interfaces, an integration platform or a data platform are usually the safer options. A UNS is another, with the risks above.
• Already running MES/MOM? Publishing its contextualised data to a data platform is often a quick way to make it useful to everyone else.

There's more on the wider choice of approaches in Code, build, stitch or configure, and on the protocols underneath in OPC UA, MQTT and UNS in plain English.

My view

A UNS is a pattern to approach with caution. It can share live data, but it gives the sender no confirmation, keeps no history and needs strict governance to stay usable. For anything that must arrive, such as orders, consumption and quality status, I'd use interfaces that confirm it did. The debate gets heated online, almost political at times, which doesn't help anyone choose. Start from the flows you actually need, and pick the safest pattern for each one.

Where does a UNS sit in your architecture today: alongside your MES, or instead of one?

There's no single answer, because every factory starts from a different place. But there is an order that works, and most of the expensive mistakes I see come from doing the steps out of sequence. Buying software before mapping the process. Customising the software to match every old quirk.

So this is the route I'd follow, step by step, with a simple test for each one so you know when you're ready to move on.

Step 1: Be honest about where you are today

Not where the last board presentation said you are. Where you actually are.

One way I look at it is time to truth. Take an example: when a line stops at 2am, how long until the right person knows, and do they know why? The stages run from "eventually" to "without asking". Most factories sit somewhere between eventually and after the fact, and often further back than they'd like to admit. Travellers on clipboards, and a morning meeting that starts with someone reading yesterday's numbers from a notebook. That's "eventually", and it's very common.

You can't plan a route if you're lying to yourself about the starting point. More in Time to truth.

Ready to move on when: you can describe, with evidence, how data is captured today on each line, and you've agreed a realistic level with the people who run the shopfloor.

Step 2: Map the process before you buy anything

Digitise a broken process and you get a faster broken process.

Start with the physical structure: enterprise, site, area, line, machine. Then map what really happens, warts and all, rather than what the manual says. I like a swimlane grid with departments across the top and manufacturing processes down the side. Every handoff and every gap becomes visible.

Do it with operators, quality technicians, maintenance engineers and logistics in the room, not just managers. You'll almost certainly find two sites, or two shifts, making the same product in different ways. Decide which way you're going to standardise on before you build it into software. More in Map your processes.

Ready to move on when: you have current-state maps for the site you'll start with, and you've agreed the target process for it.

Step 3: Put a number on the problem

Leadership approves business impact, not features. So take the pain you found in step 2 and put money on it:

• What do scrap, rework and complaints cost a year?
• What's an hour of lost production on your bottleneck worth?
• How many hours a week go on manual data entry and chasing information?
• How much working capital is tied up in buffers you hold because you don't trust the data?

Then show how the risk will be managed: a phased rollout plan, with milestones and measures. In my experience, fear of overrun and failure is what really blocks most business cases. Address it directly. More in How to build an MES business case leadership will sign.

Ready to move on when: you have a sponsor with the authority to allocate resources, and the programme that's funded.

Step 4: Build the team

The team you build matters as much as the software you choose.

You need an executive sponsor who'll clear the way, a project manager who's properly freed up, IT and operations working as one team, and the right external expertise where you don't have it in-house. Bring in super users from the shopfloor early. If you're a multi-site business, think now about who will own the global standard later, usually a centre of excellence blending IT and OT.

And plan for resistance. Every project meets it, because change is uncomfortable. Involve people in the design and explain why it makes their shift easier. Adoption deserves as much investment as implementation. See Building the right team and Resistance to change is guaranteed.

Ready to move on when: named people have time in their diaries for the project, with their day jobs backfilled where needed.

Step 5: Fix the master data

This is the step everyone wants to skip.

ERP master data was usually set up for what costing needed. A routing with one generic operation called "Production" gives MES/MOM nothing to work with. You need to know which machines each operation runs on, realistic cycle and setup times, which material is consumed at which operation, and which quality checks apply at each step.

Get it right in ERP first, so every system benefits, then add any extra detail in the specialised applications where it's needed. More in Your ERP master data isn't ready for MES.

Ready to move on when: the materials, BOMs and routings for your first site are detailed enough to run the target process, and someone owns keeping them that way.

Step 6: Choose a platform for the long term

Now you're ready to talk to vendors, with process maps and real requirements rather than a wish list.

A few principles I'd hold to:

• Choose for where you're going, not just today's problem. A cheap tool for one form, then another for the next, swaps paper silos for digital silos.
• Look at breadth. Production, quality, inventory and maintenance overlap constantly. One platform on one set of data avoids arguing about whose numbers are right.
• Configure, don't customise. Every customisation costs you again at every upgrade.
• Check the vendor can keep investing. You'll run this system for a decade or more, and it needs to keep improving in that time.

Use the 12 questions to structure the evaluation, and put the system in front of one of your operators before you sign.

Ready to move on when: you've seen the system run your process, in a demo built for your type of manufacturing, and your operators have used it.

Step 7: Start with one site, with the end in mind

Commit to a whole site rather than a single production line. Within that site you can still phase what you switch on first. Often the best first move is removing the paper that hurts most: quality check sheets, downtime logs, work instructions or travellers.

Phasing doesn't mean narrow-minded. The end state should still be clear on day one, even if you only use part of the platform at first. That's the difference between a first phase that scales and one that becomes another silo. More in Going paperless.

Ready to move on when: the first site runs on the new system every shift, including nights and weekends, with no paper fallback.

Step 8: Connect the machines

Automatic data capture is what turns MES/MOM from a place where people type things in into a real-time view of the factory.

Start with your bottleneck assets. Detect stops automatically and let operators add the reason while it's fresh. Most people are genuinely surprised when they first see their micro-stops. More on the connectivity options in OPC UA, MQTT and UNS in plain English.

And treat every new connection as a security decision. MES/MOM sits between IT and OT. Keep the enterprise network away from the PLCs.

Ready to move on when: downtime and output on the bottleneck come from the equipment, not from memory at the end of the shift.

Step 9: Go live, then keep going

Go-live is the starting line. Plan hypercare with extra support on every shift, including nights, and super users who are visible and have time to help. Fix things quickly enough that people keep trusting the system.

Then measure what the business case promised, against the baseline you set before you started, and share the results. That evidence keeps leadership committed. More in Go-live is the starting line.

Ready to move on when: you can show the improvement you promised, in numbers leadership accepts.

Step 10: Scale with a template

Once the first site works, turn what you built into a template: standard processes, master data rules, KPIs, screens and integrations. Roll it out site by site, allowing local differences only where there's a genuine reason. Later sites go much faster. See Rolling out across sites.

The checklist

Where AI fits

You don't have to wait until the end for AI. Generative AI can help with procedures and plain-English questions early on, and once accurate, contextualised data is flowing from the shopfloor, predictive and optimising AI has something real to learn from. More in AI will transform your factory, if you give it the right data.

Which step is your factory on right now, and which one are you tempted to skip?

This guide puts them side by side. If you only read one thing, read the first table. If you're deciding what to buy, the last two tables are the useful ones.

The short version

ERP runs the business. MES runs production on the shopfloor. MOM runs the whole operation on the shopfloor, covering production, quality, inventory and maintenance on one set of data. Everything else is a specialist that adds depth in one area, connected to those three.

MES and MOM aren't competitors to ERP. They do a different job, at a much finer level of detail, for different people. I explain the difference between the two in MES vs MOM.

Side by side

The levels refer to ISA-95, the standard for how business and shopfloor systems fit together. Level 4 is business planning, level 3 is manufacturing operations, and levels 0 to 2 are the machines and their control.

MES vs ERP

This is the comparison I get asked about most.

ERP knows that 500 units of an order should be made this week, from which materials, at what cost. MES/MOM knows which operator ran the line at 2.14am, which lot went into machine 7, why the line stopped for 11 minutes, and whether the torque on station 4 was in tolerance.

The two work best together. MES/MOM sends ERP validated actuals instead of estimates, which improves costing, inventory and planning. And some ERPs designed with manufacturing in mind already cover more of the production side, which makes the gap smaller. More in What is ERP and Implement MES to remove complexity from your ERP.

One firm rule: never wire ERP straight to the machines. That's what MES/MOM is for.

MES vs MOM

MES is the production pillar. MOM is the whole operation.

If a vendor tells you their MES covers everything, ask which of the four ISA-95 areas it actually handles, and how deeply. Production, quality, inventory and maintenance overlap constantly. The operator does a bit of all four, often in the same ten minutes. One platform means the downtime production sees is the downtime maintenance sees, and quality checks are triggered by what's actually running.

Who owns which data

Most integration arguments I see come down to ownership. Agree this table early and a lot of them disappear.

One owner per object. Everyone else holds a copy.

Do you need it?

Not every factory needs every system. The skill is adding depth where the operation genuinely needs it, and not stretching a system into a job it was never designed for.

Many ERP suites include APS, WMS, EAM or service modules, so needing the capability doesn't always mean another vendor.

How they connect

Business transactions usually go through ERP. Execution detail can go direct when speed or richness demands it, such as drawings from PLM to the operator, or schedules from an APS to the line. Have a play with the patterns below.

I go through the options in Connecting MES/MOM to everything else, and system by system in The smart factory tech stack.

Which of these boundaries causes the most arguments in your business?

Most of them are genuinely useful. The question is which problem you're actually trying to solve, and whether you're solving it in a way that will still make sense in five years.

This guide goes through the main shopfloor applications by the job they do. At the end there's a table to match the problem you have to the application that fixes it.

What counts as a shopfloor application?

Anything used at the point of work, by the people doing the work, in real time. Operators, supervisors, quality technicians, maintenance engineers and logistics.

That's different from ERP, which runs the business from the office, and from SCADA, which controls the equipment itself. Shopfloor applications sit in between, at level 3 of ISA-95. Collectively, that layer is MES/MOM.

Production

Production execution and monitoring. Getting the right order onto the right line, starting and stopping it, and recording good counts, scrap and downtime, ideally straight from the equipment. The production order is the context everything else hangs off. This is the core of MES, and for many manufacturers their first step. See Production monitoring.

OEE and performance. Availability, performance and quality on the bottleneck, calculated from automatic data rather than end-of-shift estimates. Most people are genuinely surprised when they first see their micro-stops. See What is OEE? and KPIs beyond OEE.

Scheduling and release. ERP plans the orders. On the shopfloor, the job is fine-tuning the sequence and showing the line what to run next, and adjusting when a machine goes down. Complex sequencing may need APS on top. See Production scheduling.

Quality

In-process quality. Inspection plans and checks triggered by what's actually running, with measurements and defects recorded against the order and material. Holds when something is wrong. See Quality operations.

SPC. Control charts at the line, so operators see a process drifting before it makes scrap. Inspection tells you a part is bad; SPC tells you it's about to be. See SPC on the shopfloor.

Electronic batch and device records. In regulated industries, the record that proves you made it correctly, enforced as you go and reviewed by exception. See MES/MOM in regulated industries.

Inventory and traceability

Inventory and material tracking. Labelled units, lots, serials and containers, consumed and created against orders as it happens, with labels printed at the line. See Inventory management.

Line-side logistics. Replenishment requests based on real consumption or kanban signals, with a clean handover from the warehouse. See Warehouse management.

Traceability. Genealogy forwards and backwards, plus the tooling, operators, quality results and process parameters behind every lot. In a recall, the difference between minutes and a weekend in spreadsheets. See Your traceability probably isn't as good as you think.

Maintenance and assets

Maintenance. Fault reporting from the screen operators already use, work orders, planned and condition-based maintenance, and autonomous maintenance by operators, on the same downtime data production uses. See Maintenance.

Tooling. Tool life counted from real production, with cavities and readiness tracked alongside. No tool or no setter, and the job doesn't start. See Tooling.

Energy. Consumption linked to the machine and order that caused it, including what machines draw while idle. See Energy.

The people on the line

This is the part of the shopfloor that's changing fastest, because the workforce is. Experienced people are retiring, and their replacements stay for less time.

Digital work instructions. Presented automatically for the job that's running, always the latest version, step by step, with confirmations captured as you go. Not a PDF on a tablet. See Digital work instructions that know what's running.

Checklists and tasks. Start-up checks and safety sign-offs, triggered at the right moment and recorded with the context.

Shift handover. Built from what actually happened, with the supervisor adding what only a person knows. See Shift handover is a process.

Skills. Qualifications checked at the point of work, so the system stops the wrong person starting the wrong job rather than reporting it afterwards. See Skills you can enforce.

Together these are usually called connected worker. I'm a big believer in it. I'd just build it into the operational platform rather than buy it as another app. See Connected worker: one app, not five.

AI on the shopfloor

Operator copilots and knowledge assistants. Plain-English answers about procedures, alarms and past faults, at the point of work.

Shift summaries. Drafted from the data for a supervisor to review.

Visual inspection support. Image recognition flagging likely defects for the operator to confirm, so judgement stays with the person.

Predictive maintenance and predictive quality. Models trained on condition data, failure history, process parameters and operating context.

Every one of these draws on the applications above. AI needs the order, the material, the recent stops and the approved procedure. That context lives in MES/MOM. See AI for the frontline and Practical GenAI for the shopfloor.

Match the problem to the application

One platform or several?

You can buy most of these as separate products. An OEE tool here, a checklist app there, a standalone quality system, a CMMS.

That has real advantages. Each department gets a tool that's very good at its job, and you can start where the pain is biggest. Modern integration options, such as standard APIs and point-to-point interfaces, make connecting them easier than it used to be.

The trade-off shows up as the problems overlap. Quality needs to know what's running. Inventory needs to know whether a lot passed inspection. Maintenance needs production's downtime. The operator needs one screen, not five logins. Every boundary becomes an interface to own and retest, and some context gets lost at each one.

The map below shows how the pieces fit together, with MOM covering production, quality, inventory and maintenance in the middle. To draw your own, try the systems landscape tool.

My view

On one platform those overlaps are already handled, because everything shares the same data model. That's why my own preference is a MOM platform, which replaces the need for a standalone QMS or CMMS. Pick the problem that hurts most, and solve it on a platform that can grow into the rest. I set out all four approaches, including coding or building your own, in Code, build, stitch or configure.

Which row of that table describes your biggest problem right now?

Either way, the first 90 days matter more than they look. Get them right and you'll have a funded programme with a team behind it. Get them wrong and you'll spend a year on a tool that never scales.

This is how I'd use them.

Before day one: agree what "smart" means here

A smart factory isn't science fiction, and it doesn't need an "Industry 4.0" label. My definition:

A manufacturing environment where people, processes and technology work together, supported by data, to maximise efficiency, flexibility and quality.

More in What is a smart factory?

Put that, or your own version, in front of leadership and get agreement on it. It keeps the programme pointed at outcomes.

Days 1 to 30: understand where you really are

The first month is about listening and looking, not buying.

Walk the shopfloor, on every shift. Including nights. You'll see workarounds that never made it into the SOP, and paper in places nobody mentioned.

Find your time to truth. Pick a real stoppage from last week and trace when each person found out, and what they knew. Most factories land somewhere between "eventually" and "after the fact", and usually further back than they think. See Time to truth.

List every system and spreadsheet. ERP, any MES or point solutions, quality tools, maintenance systems, the spreadsheets that actually run things, and who owns each one. It's often longer than anyone expected.

Find the pain, with numbers. Where do downtime and scrap cost the most? Where do people spend hours typing data from one place into another? Ask operators and supervisors as well as managers.

By day 30 you should have: a maturity assessment you'd defend in front of the shopfloor team, and a shortlist of the biggest losses with rough numbers attached.

Days 31 to 60: decide where to start, and why

Pick the first site. Commit to a whole site rather than a single production line. One line on its own leaves people working two ways at once, and the value of production, quality, inventory and maintenance working from the same data only shows up across a site. Not necessarily the worst site, and not necessarily the easiest. Use the scorecard below.

Map its processes. Current state first, with the people who do the work, then the target. Digitise a broken process and you get a faster broken process. See Map your processes.

Check the master data for that site. Are the routings detailed enough to say which machine each operation runs on, with realistic cycle times? If ERP has one operation called "Production", you've found your first work package. See Your ERP master data isn't ready for MES.

Sketch the end state. Where should this be in three years, across all four pillars of production, quality, inventory and maintenance, and across sites? You won't build it all now. But the first step should head towards it.

By day 60 you should have: a chosen first site, its current and target processes, a master data gap list, and a one-page picture of the end state.

Days 61 to 90: build the case and the team

Write the business case. The most important thing is to calculate the ROI and articulate the value. Don't present cost in the absence of value. Set out current costs, expected benefits, realistic costs including your own people's time, and how the risk is managed through a phased rollout plan with milestones. Leadership approves business impact, not features. See How to build an MES business case.

Create a vision people buy into. A business case gets the money. A vision gets people behind it. Describe what the site will look like when it's done, in terms the shopfloor and the board would both recognise, and keep coming back to it.

Secure a sponsor. Someone senior enough to allocate resources and clear blockers. Without one, plant-level projects struggle.

Build the team. A project manager with real time, IT and operations together, super users from the shopfloor, and outside expertise where you don't have it. Backfill day jobs where you need to. Think beyond the first site, too. The people who deliver it are the start of a centre of excellence, which owns the template, the standards and the know-how as you roll out to other sites. See Building the right team and Rolling out across sites.

Write requirements from your process maps, not a wish list. Separate what you need now from what you might need later. Then you're ready to talk to vendors. See How to choose an MES.

By day 90 you should have: an approved programme, a vision people support, a sponsor, a team that can grow into a centre of excellence, and requirements based on real processes.

Choosing the first site: a scorecard

Score each candidate site from 1 to 5 on each question. The highest total is usually the right place to start, but read the notes before you decide.

Two cautions. Don't pick a site purely because it's the worst performer if its problems are mostly mechanical. And don't pick the easiest site if nothing you learn there applies anywhere else. If you only have one site, the decision is made, and the scorecard tells you where the effort will go.

What not to do in the first 90 days

• Don't buy software in month one. You don't know your requirements yet.
• Plan the AI and the data together. AI that predicts and optimises learns from the data foundation you're about to build, so choose an AI use case for the first site and let it shape what you capture. GenAI on your documents can start straight away. See AI will transform your factory, if you give it the right data.
• Don't start with a point solution you couldn't scale. A Phase 1 that becomes a silo costs you twice.
• Don't leave the shopfloor out. People support what they helped create. See Resistance to change is guaranteed.

After day 90

The next step is a formal process to review software vendors, built on the requirements you've just written. That's a subject in its own right, so I won't go into it here. How to choose an MES has the questions I'd ask.

What's the first thing you'd want to know about your own factory, if you had 30 days to find out?

So before we talk about the systems that sit around ERP, let's give it the credit it deserves.

What ERP actually is

ERP stands for Enterprise Resource Planning. It's the system that runs the business side of a manufacturing company on one shared set of data.

A customer places an order. ERP records it, checks stock, plans what needs making, raises purchase orders for the materials, books the receipts, values the inventory, invoices the customer and posts every transaction to the ledger.

Everything is one record, so the whole business works from a single version of the truth.

Before ERP, each of those steps lived in a different system, or a different spreadsheet, owned by a different department. Reconciling them took days. Month end took weeks.

What a good ERP does well

Most modern ERPs cover a broad footprint. In manufacturing, the core usually looks like this:

• Finance and accounting. General ledger, payables, receivables, fixed assets, consolidation across entities and currencies.
• Sales and customer orders. Quotes, orders, pricing, credit checks, delivery promises and invoicing.
• Purchasing and supply. Suppliers, purchase orders, receipts and three-way matching.
• Planning. MRP to work out what to make and buy, and when, based on demand, stock and lead times.
• Inventory and costing. Stock by location, valuation, standard and actual costs, and margin by product or customer.
• Production orders. Creating the orders, the bills of materials and routings behind them, and booking the results.

ERP is where production is planned and accounted for. It knows what should be made, from what, at what cost, by when.

Why it's worth getting right

I'll be honest, ERP gets a hard time it often doesn't deserve. When it's implemented well, it gives a manufacturer something genuinely valuable.

Control of the money. Every order, every purchase and every stock movement flows through to the ledger. Leadership sees margin by product and by customer, without anyone building a spreadsheet.

Promises you can keep. When sales confirms a delivery date, it's based on real stock, real lead times and a real plan rather than a guess.

A common language. Item codes, customers, suppliers, units of measure and cost centres mean the same thing in every department and every site. You only notice how much that's worth when you work somewhere without it.

A platform to grow on. Adding a plant or a new legal entity becomes a configuration task rather than a new system.

The modern trend towards cloud and composable ERP has made all of this more accessible too. Upgrades arrive continuously. Mid-sized manufacturers now get capability that only the largest could afford a decade ago.

Where ERP stops, by design

ERP is brilliant at running the business. It was never designed to run every operation inside it at the level of detail those operations need.

An ERP knows that 500 units of an order should be made this week. It doesn't need to know which operator ran the line at 2.14am, which batch of resin went into machine 7, why the line stopped for 11 minutes, or whether the torque on station 4 was in tolerance.

That level of detail lives elsewhere. Not because ERP is weak, but because it's a different job, with different users and different data.

That said, ERPs aren't all the same. Some were designed with manufacturing in mind and cover more of the production side than others, such as detailed routings and shopfloor reporting. If you run one of those, it will already handle more of the operational detail than a general-purpose ERP would. And that's helpful for shopfloor applications like MES/MOM, because there's a smaller gap to the extra detail those systems need.

What MES/MOM adds is a different layer of data: finer detail, captured in real time at the point of work, with every event tied to its order, batch, machine and operator. That context is what turns a production record into something you can act on in the moment and learn from over time.

That's where specialist applications come in, as a complement to ERP rather than a replacement for it.

The applications that sit alongside ERP

A good ERP becomes even more valuable when it's surrounded by the right specialists, each doing one job very well and sharing data with the core:

• MES/MOM runs the shopfloor across all four pillars: production (executing orders and recording output, scrap and downtime), quality (checks, SPC and holds), inventory (material movements, genealogy and traceability) and maintenance (breakdowns and planned work), feeding real actuals back to ERP.
• Connected worker puts instructions, checklists, skills and handover in front of the people doing the work.
• WMS handles complex warehousing, picking and storage strategies.
• APS produces detailed, constraint-based schedules when MRP's view isn't fine enough.
• CPQ configures complex products and quotes them accurately, and passes a buildable specification downstream.
• PLM owns the product definition and engineering changes before they reach ERP.

How they connect is a choice in itself. Some go through ERP, some go straight to MOM, and most manufacturers end up with a mix. Have a play with the patterns below.

Some ERP vendors offer genuinely best-of-breed options for several of these. Others partner. Either way, the principle is the same: a strong ERP core with specialist applications around it, all working from the same master data.

Be wary of anyone who tells you it has to be one or the other. The best-run manufacturers I see treat ERP as the backbone and add specialists where the operation genuinely needs them.

Where this learning path goes next

That's the core. The rest of this learning path looks at each of the specialists around it: what they do and where the boundary with ERP sits, so you can decide whether you actually need one.

Next up is the smart factory tech stack, system by system. Which of these is your business already stretching ERP to do?

The answer changes the cost of the project and the work operators do every shift. So it's worth deciding deliberately.

How you can trace

Lot (or batch) traceability. A quantity of material shares one identifier: a lot of resin from a supplier, or a batch from a mixer. You know which lots went into which lots. Most manufacturers trace at this level.

Serial traceability. Every individual item has its own identifier, usually a printed or engraved barcode or a data matrix. You know exactly which components went into exactly which unit. Common for high-value and regulated products.

Time-based traceability. In continuous processes, material doesn't arrive in neat lots. You trace by time window instead. MES/MOM records when each input lot was being consumed and when each output was produced, then matches the two. The window is usually offset by the time material takes to travel through the line, so an output made at 10:30 is matched with what went in at the start of the line, say at 10:00, rather than at 10:30. It's how extrusion and many continuous food lines do it.

Many manufacturers use a mix, such as serialised finished goods built from lot-tracked components.

Lot vs batch: is there a difference?

The two words are often used interchangeably, and in many factories that's fine. But there's a useful distinction.

A batch is a quantity made in one production run, usually under one order and one recipe. It's a production term, most common in process industries.

A lot is a quantity that shares one identity for traceability, whether you made it or bought it. A supplier's delivery of resin is a lot. A batch you produce becomes a lot once it's identified and stored.

The two don't always line up one to one. A large batch might be split into several lots for packing or release, and a lot can be made up of several batches, for example when finished goods are blended or packed together from more than one production run. In US pharmaceutical regulations, for example, a lot can be a whole batch or an identified portion of one.

What matters is that your MES/MOM can record both, and the links between them, so that you can trace from any lot back to the batches and raw material lots that went into it.

Side by side

Choosing the right level

Ask these for each material and product:

• What do customers or regulators require? Medical devices and aerospace parts often need serial-level records. Food usually needs lot-level.
• What does a recall cost? If one bad component means recalling a whole week's production, finer traceability pays for itself quickly.
• Will you service the product? Field failures trace back through the serial number to the as-built record. See Service data back to engineering.
• Can the process support it? Serialising thousands of small parts a minute needs marking and scanning at line speed. Sometimes lot level with tight lot sizes is the practical answer.

What makes traceability good

The level of granularity is only half the story. The difference between adequate and excellent traceability is what you capture alongside the genealogy: the tooling used, quality results at every stage, the operator, the machine, and the process parameters at the time.

That's what turns a recall from quarantining a week of production into identifying exactly which units contain the suspect material.

It also pays off long after the recall. The more context you capture, the easier it is to find the root cause of a problem and stop it happening again, which makes traceability data one of the best inputs to continuous improvement. More in Your traceability probably isn't as good as you think.

Where it lives

ERP usually tracks lots at the level the business needs, often with backflushing. The detailed genealogy, especially serial-level and time-based, is MES/MOM's job, because it's there when the material is actually consumed. Lot quantities need to be recorded as they happen, not calculated from the BOM afterwards.

If a complaint landed on your desk this afternoon, how long would it take to find every affected unit?

This page covers the essentials. The full glossary has over 200 terms, each with its own page explaining what it means in practice, with links to the articles that go deeper.

Want more? Browse the full glossary, from A to Z. Is there a term you keep hearing that isn't there? Let me know and I'll add it.

This article pulls together the patterns behind the rest of this series: PLM, CPQ, WMS, APS, QMS, EAM and LIMS.

Start with ISA-95, not with technology

ISA-95 gives you a common language for what flows between business systems (level 4) and manufacturing operations (level 3). I explain the model in What is ISA-95, and where does MES fit?

The useful part isn't the diagram. It's the discipline. For every integration, agree:

• What object is moving? An order, a material lot, a quality result, a downtime event.
• Which system owns it? One owner. Everyone else holds a copy.
• What triggers the move? An event, a schedule, a request.
• How fresh does it need to be? Seconds, minutes or overnight changes the design entirely.
• Does the sending system need confirmation? Does it need to know the receiving system processed the data successfully, or hit an error? For most transactions it does, and that rules some patterns out.

Get those answers for every flow before anyone mentions an API.

ERP is usually the hub

In most manufacturers, ERP sits between MES/MOM and the other business systems. Product data comes from PLM via ERP. Orders come from ERP. Inventory, cost and quality status go back to ERP. That's a sound design. ERP has to know about all of it anyway.

There are exceptions. Throughout this series I've described cases where a direct link alongside ERP makes sense: engineering drawings from PLM, high-frequency replenishment with a WMS, rich non-conformance data into a QMS, where one is used, in-process lab results from LIMS. The rule I'd suggest:

Business transactions go through ERP. Execution detail can go direct when speed or richness demands it.

A direct link is an addition to the ERP path, not a bypass of it.

The four patterns

Point-to-point. System A calls system B directly. Easy to understand, and often the safest option: the sending system gets a response from the receiving system, so it knows each message arrived and was accepted. As the number of systems grows, so does the number of links to maintain when either side changes.

Middleware or integration platform. An integration layer (an ESB, or a cloud iPaaS) sits in the middle. Each system connects once. Mapping, routing, retries and monitoring live in one place, in exchange for another layer to run and maintain.

Event-driven. Systems publish events ("order released", "lot on hold", "machine stopped") and anyone interested subscribes. Producers don't need to know who's listening, which decouples the systems and suits near real-time flows. The flip side is that the publisher doesn't know whether anyone received or processed what it sent.

Unified namespace (UNS). An event-driven pattern applied to the plant: a single, structured hierarchy (usually on MQTT) where systems publish their current state and others can subscribe. It has some limitations for business data. The sender gets no confirmation that the data arrived or was processed, there's no history by default, and it needs strong governance of the hierarchy, plus a broker to run and secure. I explain the basics, and the alternatives, in OPC UA, MQTT and UNS in plain English.

These aren't mutually exclusive. A common mix: direct links for transactional flows between MES/MOM and ERP, where a confirmed response matters most, with an integration platform or a UNS where many systems need the same data.

Transactions vs telemetry

One distinction that saves a lot of pain:

Be wary of anyone who wants to push ERP transactions through the same "fire and forget" path as sensor data. Losing a temperature reading is annoying. Losing a goods issue means your stock is wrong until the next count.

Design for the upgrade

The integration you build today will outlive at least two upgrades of every system it touches. A few habits that help:

• Use standard, supported APIs. Avoid writing directly to another system's database. It will work until the day it doesn't.
• Keep mapping logic out of both endpoints. Put it in the integration layer, where it can be changed without touching either system. It's configure, don't customise applied to integration.
• Monitor and alert. A failed message should page someone, not wait to be found at month end.
• Make it replayable. When something fails, you need to resend from the point of failure without creating duplicates.

How many of your current integrations would survive an ERP upgrade without anyone touching them?

It's a common question, especially in process industries where historians have been around for decades. Both collect data from the shopfloor. Both show trends. But they store different things, for different people, and answer different questions.

What a historian does

A process historian is a database built for time-series data at very high volume. It records machine signals and process variables, often every second or faster: temperatures, pressures, flows, speeds, levels, valve positions. It compresses that data efficiently so you can keep years of it.

Engineers love historians, rightly, for troubleshooting and long-term trending. "What was the oven temperature doing in the two hours before that batch failed?"

What MES/MOM does

MES/MOM records operational events and gives them context. An order started on Line 3. 2,400 good parts, 60 scrapped for short shots. A 12-minute stop, reason: jam at station 2. Lot 7781 consumed into order 4521. A quality check failed and the lot was put on hold.

MES/MOM also reads time-series values from tags, usually over OPC UA. The important difference is that it contextualises that data, so every value is tied to the order, material and machine it belongs to.

It also manages the work: releasing orders, guiding operators, enforcing checks and recording genealogy. A historian watches the process; MES/MOM runs the operation.

Side by side

How they work together

In the rare cases where you have both, use each for what it's good at:

• The historian keeps the high-frequency signals. MES/MOM doesn't need every reading.
• MES/MOM keeps the events and the context. Orders, lots, stops, reasons and results.
• The two link by time and equipment. When a lot fails inspection, MES/MOM tells you which machine and which hours; the historian shows you exactly what the process was doing then.
• A data platform brings both together when you want analytics or AI across many lines and sites.

Some MES/MOM platforms include historian capabilities, and some historians have added event features. The roles stay roughly the same. More on how these layers fit with data lakes and AI in Historians, data lakes and data fabric.

Which do you need?

Normally, you don't need both. MES/MOM isn't designed to hold the same volume of data as a historian, or to capture it at the same frequency. But for most manufacturers, the level of data MES/MOM captures is absolutely fine, and it removes the need for a separate historian.

In some rare cases you might need both, usually in process industries where engineers need very high-frequency signals kept for long periods.

My view

The trap is assuming a historian, or an IIoT platform full of tags, is enough to run the operation. It isn't designed to manage a production order or trace a lot. Manufacturers who try end up building those functions on top, which is effectively building a homegrown MES. I make the same argument in IIoT vs MES. The opposite trap is forcing MES/MOM to store every high-frequency signal when nobody uses it. Where that level of detail is genuinely needed, that's what a historian is for.

Does your historian know which order was running when that value spiked?

Because when a product fails in the field, the most useful question is: what was different about the ones that failed?

And the answer is very often sitting in your MES/MOM.

The systems at the far end of the thread

After shipment, product data spreads across a few places:

• Field service management (FSM) handles service visits, technicians, parts used and the fault found.
• ERP usually holds the installed base, warranty, service orders, returns and the cost of all of it. Many ERP suites include the service module.
• PLM owns engineering change requests: the formal route to fix the design.
• ERP, fed by the quality capability of MOM, or a QMS where one is used, owns complaints and CAPA.

And MES/MOM holds the as-built record: which component lots and serials went into each unit, which operator built it, which machine, the measurements recorded, any rework or deviations.

The typical failure investigation

A customer reports a failure. Service replaces a component. A few weeks later, another. Then five more.

Someone in quality pulls the serial numbers. Then the hard part starts. Which component lot was in each of those units? Which supplier? Were they all built on the same line, the same week? Was there a deviation or rework on any of them? What were the torque values?

If MES/MOM has a proper as-built record, those answers take minutes. If it doesn't, they take weeks of digging through paper travellers. Or they're never found at all, and the fix becomes "replace the component on every unit", the most expensive answer available.

How the loop connects

The serial number is the key that joins everything. A connected loop works like this:

1. Service records the failure against the unit's serial number, with the failed part and the fault.
2. ERP links it to the installed base, warranty and order history. Service orders and returns are business transactions, and they belong in ERP.
3. The as-built record answers what's common. Component lots, suppliers, build dates, machines, operators, process data. That's MES/MOM's contribution.
4. The fix goes to the right owner. A design weakness becomes an engineering change request in PLM. A process issue becomes a CAPA and a change on the shopfloor. A supplier issue goes to supplier quality.
5. Containment uses the same data. Which other units, in the field or in stock, share the suspect lot? Recall those, not everything.

Integration options

Again, there's more than one way to wire it.

Through ERP. Service data lives in ERP. Genealogy from MES/MOM is posted to ERP as serial and lot relationships. Investigations run from ERP. Simple, and it works well if ERP holds the serial-level genealogy you need.

ERP plus a genealogy query into MES/MOM. ERP and service hold the case. When an investigation needs depth (process values, measurements, rework history), the team queries MES/MOM directly, or through a data platform that combines both. ERP doesn't need to store every torque value. It needs to know where to look.

Direct feedback to engineering. Field failure trends and the matching build data go straight to the engineering team's PLM environment, alongside the formal change request. Engineers see not just "it failed" but "it failed on units where this characteristic ran near its upper limit".

Most manufacturers I speak to start with the first and grow into the second. The third is where real design improvement happens.

Make it a habit, not a crisis

This loop shouldn't only run during a recall. Field data, linked to build data, can tell you every month:

• Which suppliers' lots correlate with early failures
• Which process parameters predict warranty claims
• Whether a design change actually fixed the problem
• What a quality escape really cost, from scrap to service visit

That last one is powerful when you're building an MES business case.

So, pick your most expensive warranty issue from last year. Could you link every failed unit back to how it was built, in an afternoon?

That changes what you need from MES/MOM. The core functions are the same: orders, materials, quality, equipment, people. But the evidence requirements are much stricter, and the cost of getting it wrong is a recall or a regulator's warning letter.

Four regulated sectors, and how each shapes MES/MOM. I covered food separately in The biggest barriers to MES success in food manufacturing.

Pharmaceuticals and biotech

The heart of it is the batch record. Every step, every material, every weight, every check, every signature. On paper, a batch record can run to hundreds of pages, and reviewing it takes days.

An electronic batch record (EBR) in MES/MOM changes that:

• The recipe enforces the sequence, so steps can't be skipped
• Weights and measurements come from connected scales and instruments, not handwriting
• Deviations are flagged as they happen, not found during review
• QA can use review by exception, checking only what went outside the normal path

Electronic records and signatures must meet FDA 21 CFR Part 11 in the US and EU GMP Annex 11 in Europe: secure, attributable, audit-trailed, and validated. Data integrity rules apply to every record.

Validation is the big project overhead. Which brings me to a cautionary point: the more you customise, the more you validate. Here, configure, don't customise is a matter of compliance cost, not just good practice.

Medical devices

Device makers need a complete record of how each device or batch was built. In the US, the FDA's Quality Management System Regulation (QMSR) has incorporated ISO 13485 by reference since 2 February 2026, so the US now follows the same standard most manufacturers elsewhere already use.

For MES/MOM, that means:

• Serial or lot-level genealogy for every device and critical component
• Proof that operators were trained and qualified for the operation, at the time
• Equipment calibration status checked before use
• Labelling linked to the as-built record

Complaints and field issues must trace back to the build record quickly. I cover that end of the chain in Service data back to engineering.

Aerospace and defence

Aerospace is built on AS9100, and its customers expect serialised traceability that can last for the life of an aircraft. Decades.

Things that matter on the shopfloor:

• First article inspection (FAI, typically to AS9102) when a part is new, changed or moved to a new process
• Configuration control: building to exactly the right revision, which makes the PLM, ERP and MES link critical, often with a direct PLM connection for drawings and characteristics
• Special processes such as heat treatment and welding, with qualified people and validated parameters
• Counterfeit part prevention and full supplier traceability for critical components

Operators frequently need the drawing at the workstation. Paper travellers with handwritten stamps are still common in aerospace, and they're a major source of escapes and audit findings.

Automotive

Automotive suppliers work to IATF 16949, plus specific requirements from each OEM. The emphasis is on preventing defects at volume:

• PPAP (production part approval) before supply starts, and control plans that define every check
• Error-proofing at the station: right part, right torque, right sequence, enforced rather than checked afterwards
• Traceability of safety-critical components to the vehicle, so a recall can be targeted to specific VINs instead of a whole model year
• Rapid containment: when a defect is found, knowing within minutes which parts are suspect and where they are

The volumes are high and the margins thin, so traceability has to be automatic. Nobody hand-records lot numbers at 60 units an hour.

What they have in common

Strip away the acronyms and four principles repeat:

• Enforce, don't just record. The system should stop the wrong thing happening, not merely log it.
• Capture at the source. Data from the instrument or the scan, not typed from memory.
• Link everything to the unit or lot. Materials, people, equipment, results.
• Make the record reviewable. Quickly, by exception, years later.

Those are good principles in any industry. Regulation just removes the option to skip them.

If an auditor arrived tomorrow and picked a unit you shipped two years ago, how long would it take you to produce its complete record?

If those results arrive after the batch has already moved to the next stage, or worse, been packed and shipped, the lab might as well not exist.

What a LIMS does

A LIMS (Laboratory Information Management System) runs the lab. It manages:

• Samples, their labels and chain of custody
• Test methods, specifications and instrument data
• Analyst workload and lab scheduling
• Certificates of analysis (CoA) and stability studies

What MOM can do in the lab

A good MOM covers a lot of this itself. It triggers checks and samples from what's happening on the line, records results against the batch and phase, runs SPC on them, and produces certificates of analysis. Because it's running the batch, every result comes with the recipe, equipment, raw material lots and process conditions attached.

There are many good reasons to keep as much of this inside the MOM as possible: one system for the operator and the lab technician, no interface to maintain, and results that act on the batch the moment they're recorded.

When a separate LIMS earns its place

A LIMS is an option in some cases, and in certain industries there's more of a case for a separate LIMS than for a separate QMS. It's typically a heavy, regulated lab with many instruments, analysts and stability studies, such as in pharmaceuticals and biotech, chemicals, food and dairy plants with their own microbiology labs, and materials testing. Even there, check how much the MOM already covers before adding another system.

The flow when MOM handles the lab

This is the simpler option:

1. MOM triggers the sample. The batch reaches a phase that needs testing. MOM tells the operator, prints the label and adds the test to the lab's work list, with the batch, phase and equipment already attached.
2. The lab tests it in MOM. Results are recorded against the specification, by hand or straight from the instrument.
3. MOM acts. A pass releases the next step. A fail holds the batch, or triggers an adjustment such as adding more of an ingredient, then a re-sample.

No interface, no waiting for a message to arrive, and nothing typed twice.

The flow when a LIMS is used

This works too, but it needs integration:

1. MES/MOM triggers sampling. It tells the operator, prints the label and tells the LIMS a sample is coming, with the batch, phase and equipment attached.
2. The LIMS tests it. The lab receives the sample, runs the methods and records results against the specification.
3. Results come back. Pass, fail or out-of-spec values flow back to MES/MOM against the batch and phase.
4. MES/MOM acts. A pass releases the next step. A fail holds the batch, or triggers an adjustment and a re-sample.

The sample needs to be born with its context. If the lab has to type in the batch number from a handwritten label, you've lost both time and traceability. And when a reactor sits waiting for a result, a direct link between the LIMS and MES/MOM is usually worth having, rather than routing results through ERP.

Where ERP fits

ERP usually owns batch status for the business: quarantined, released, rejected. It needs that to plan, to ship and to report stock.

Incoming materials can be tested in MES/MOM too. Results that affect how the supplier is paid, or that need raising with the supplier, pass to ERP.

Final batch release draws on the test results and the batch record. MES/MOM can release the batch, as part of review by exception on the electronic batch record, and post the status to ERP. Where a LIMS is used, release sometimes sits there instead. Pick one place and stick to it.

Watch out for

• Specifications defined twice. Where a LIMS is used, the spec must not live in both systems, or they'll drift. Pick one owner and don't duplicate.
• Results without process context. A failed test is far more useful when you can see the temperature profile of the phase it came from. Context turns a lab result into a root cause.
• Manual transcription. Any result keyed by hand from one system into another is a data integrity risk, and in regulated industries an audit finding waiting to happen.
• Units that don't match. One system reports mg/kg, the other expects ppm. Or one rounds to one decimal place and the limit is set to two. Test the edge cases before go-live, not after the first false pass.

How long does a batch in your plant sit waiting for a lab result? And how much of that wait is the test, versus the paperwork around it?

When those two views live in different systems with no link between them, you get two versions of the truth about downtime. And an argument in every morning meeting.

The systems involved

EAM (Enterprise Asset Management) and CMMS (Computerised Maintenance Management System) both manage maintenance, from different angles. EAM covers the full asset lifecycle and the financials across many sites. A CMMS is more focused on actually looking after and managing the assets from an operational point of view: it's the tool the maintenance team uses day to day. I compare the two in more detail in CMMS vs EAM vs MES. Both handle:

• The asset register and hierarchy
• Preventive maintenance plans and schedules
• Maintenance work orders, labour and history
• Spare parts and maintenance stores

ERP often provides the EAM capability itself, or owns the financial side: asset values, depreciation, purchasing of spares, maintenance cost.

MES/MOM knows what the asset is doing right now. Run hours, cycle counts, downtime and its reasons, speed losses, the product being made, and what the operator just reported.

I covered the shopfloor side in MES functionality: maintenance. This one's about the boundary.

Why maintenance belongs in the MOM

A standalone CMMS does the day-to-day maintenance job well. Maintenance built into a MOM platform does the same job, and adds what a standalone system can't:

• One version of downtime. The stop the operator records is the stop maintenance works from. Nobody reconciles two sets of numbers.
• Work triggered by real usage. Cycle counts, run hours and machine conditions are already there, so preventive maintenance follows what the machine actually did, not the calendar.
• Requests from the screen operators already use. A breakdown is raised in a couple of taps, with the order, product and stop already attached.
• Maintenance and production planned together. Maintenance windows appear in the production schedule, and production can see when a machine is due to come down.
• Autonomous maintenance on the same platform. Operator checks and technician work orders sit side by side, on the same asset history.
• No interface to maintain. Nothing to retest at every upgrade, and no context lost at a boundary.

The overlap

This is where the two worlds collide:

• Downtime. MES/MOM records that the machine stopped, for how long, and the reason. Maintenance needs exactly that to plan and to measure MTBF and MTTR.
• Usage-based maintenance. "Service every 50,000 cycles" needs a counter. MES/MOM has it. EAM/CMMS has the plan.
• Breakdown requests. An operator spots a problem. Where do they raise it? Ideally on the screen they already use.
• Planned maintenance windows. Maintenance wants the machine. Production wants to run. Somebody has to schedule both.

Integration options

Through ERP. MES/MOM sends downtime and counters to ERP, where the maintenance module (or an EAM connected to ERP) acts on them. One hub. Works well when ERP already runs maintenance and the trigger frequency is low, say daily counter updates.

Direct MES/MOM to EAM/CMMS, with ERP for cost and parts. MES/MOM sends counters, conditions and breakdown requests straight to the EAM/CMMS, which raises the work order. Planned maintenance windows come back to MES/MOM so the schedule reflects them. ERP still handles spares purchasing and costs. This suits plants with frequent, condition-based triggers.

Maintenance inside MES/MOM. A MOM platform's own maintenance capability covers the full job, simple or complex: operator-raised requests, work orders, preventive maintenance on real usage, autonomous maintenance, spare parts and downtime analysis, all in one place. No integration at all.

None of these is universally right for EAM, but where a MOM is in place, its maintenance capability should replace a separate CMMS.

Whichever option you choose

Downtime reasons should live in one system. In almost every case that's MES/MOM, because that's where the stop is recorded as it happens. If maintenance re-codes a stop in the EAM, send the change back. If you don't, production and maintenance will report different numbers, and both will be right according to their own system.

The work order should live in one system. A request can be raised from anywhere, but the work order, its status and its history belong in one place.

Operators shouldn't need a second system. Ask an operator to leave MES/MOM and open the CMMS to report a breakdown, and they'll shout across the shopfloor instead. The request should start where they already work. I make the same argument in connected worker: one app, not five.

Production must be able to see maintenance windows. If the schedule doesn't know about a planned stop, it's just unplanned downtime with extra paperwork.

Where this goes next

Predictive maintenance depends on exactly this link. The models need machine conditions and production context from MES/MOM, and they need somewhere to send their predictions that results in a work order. Without the integration, a prediction is just an alert nobody acts on.

My view

A good MOM platform replaces the need for a CMMS: requests, work orders, preventive maintenance and downtime in one place. Running a MOM and a CMMS side by side makes little sense. Where an EAM is needed for asset lifecycle and capital planning, use the rules above so MOM still owns downtime, and production and maintenance tell the same story.

An MES that covers production only can feed a CMMS instead, using the same rules. But a full MOM is the better overall solution.

So, look at last month's top five downtime causes in your MES. Now look at your maintenance system. Do they tell the same story?

Four strategies

Reactive. Fix it when it breaks. Cheap to plan, expensive when it happens: unplanned downtime, emergency repairs, knock-on damage and missed deliveries.

Preventive. Maintain on a schedule, by calendar time or by usage such as running hours or cycles. Much better than reactive, but blunt. Sometimes you service too early and waste parts and labour. Sometimes too late, and it fails anyway.

Condition-based. Maintain when the equipment's actual condition says so: vibration, temperature, current draw, pressure, oil quality. You act on what's happening rather than on the calendar.

Predictive. Use patterns in condition data and failure history to forecast a failure before it happens, often with machine learning. The goal is to act at the last sensible moment, planned around production.

Side by side

Choosing per asset

Ask these about each asset:

• What does a failure cost? Include lost output on the bottleneck, scrap, safety and customer impact.
• Does it give warning? Some failures show signs weeks ahead. Others are sudden.
• Can you measure that warning? If there's no sensor and no practical way to add one, condition-based and predictive aren't options yet.
• Do you have the history? Predictive models learn from past failures. Without failure history, start with condition-based limits.

A light bulb in a corridor runs to failure. A gearbox on the bottleneck with a vibration signature is a good candidate for condition-based maintenance, and later predictive.

Why everything starts with downtime data

You can't predict failures you don't record accurately. Most factories still log downtime at the end of the shift, from memory, with a reason chosen from a list that's too long or too vague. Short stops aren't recorded at all.

Get that right first: stops detected automatically from the equipment, with operators adding the reason while it's fresh, and production and maintenance working from the same record. MES/MOM does that, and usage counters from production can drive preventive maintenance straight away. More in Predictive maintenance needs data you probably aren't collecting yet.

Where operators fit

Operators notice problems first. Autonomous maintenance, such as cleaning and routine inspections, catches a lot before any sensor would. Give operators a fast way to raise a fault from the screen they already use, and those observations become data too.

My view

Predictive maintenance gets the headlines, but I think the right answer for most factories is a mix. Some equipment should simply be run until it fails. A few critical assets are worth predicting. And none of it works without accurate downtime data.

Which of your assets are you maintaining on a schedule that would be better served by condition, or the other way round?

What a standalone QMS does

A QMS (Quality Management System) handles quality processes across the business, over weeks and months, and across sites and suppliers:

• CAPA (corrective and preventive action)
• Customer and supplier complaints
• Audits and certifications
• Document control and training records
• Supplier quality and approvals

A good MOM does all of that, and more

A good MES/MOM covers everything a standalone QMS does: CAPA, customer and supplier complaints, sampling, SPC, non-conformances and audits.

On top of that, it has something a QMS never has: the context. It knows which order, material, lot, machine and operator every result relates to, because it's running the production. And it can use the rest of the MOM data to trigger quality checks from other events, such as an order starting, a tool change, a new lot of material or a process parameter drifting. I cover that in QMS vs LIMS vs MES.

ERP handles the business consequences of quality: stock status (available, blocked, in inspection), supplier returns, scrap cost and the money side of a complaint. Serious non-conformances escalate into ERP, where the cost, supplier and customer sides already live.

I covered shopfloor quality in MES functionality: quality operations, and SPC in SPC on the shopfloor.

Why a standalone QMS is almost always the wrong choice

• It's a poor experience for the operator. They run the order in MES, then switch to the QMS to record a check or a defect, with a different login, different screens, and the order details typed in again. It slows them down, and it's where mistakes creep in.
• Context gets lost at the boundary. The QMS only knows what the interface sends it. The measurements, the machine settings and the photo often stay behind.
• Checks can't follow what's happening. A QMS can't see a tool change or a new lot arrive, so it can't trigger the right check at the right moment.
• Holds get out of step. If quality blocks a lot in the QMS and the line doesn't know, the line will happily consume it.
• You pay twice. Licences, upgrades and an interface to maintain, for capability your MOM already has.

Where the loop breaks

A typical story goes like this. An operator finds a defect. They record it in MES, scrap the part and carry on. A week later, quality runs a report in the QMS, spots a trend and raises a CAPA. The CAPA team asks for details. Nobody can remember which shift, which lot, which machine or which operator.

The information existed. It just didn't travel.

With quality inside the MOM, the loop looks different:

1. The non-conformance is recorded once, at the source, with full context: order, operation, lot, machine, operator, measurements and photo.
2. Rules decide what happens next. One-off scrap stays where it is. A repeat defect, a critical characteristic or a customer-impacting issue raises a CAPA automatically, and escalates into ERP where there's a cost, supplier or customer impact.
3. The investigation and actions work from the same record the operator created, so the team investigating sees exactly what happened on the line.
4. Actions that change the process come straight back to the line: a new inspection, a tighter limit, a revised instruction.

If you already have a QMS

If a QMS is already in place, connect it directly to MES/MOM, so non-conformances arrive with their full context, and send stock status changes through ERP, because ERP must know what's blocked.

Whichever way it's wired, one rule applies: when a lot goes on hold, every system that could move or consume it must know immediately. Decide which system raises the hold, and make sure it reaches ERP, MES/MOM and any WMS in minutes, not at the next batch interface run.

Don't forget the documents

Work instructions, specifications and inspection plans need approving, and the operator needs to see the approved revision for this order, not a copy someone saved locally in 2023.

The best option is a central document repository that every application can access. Each document is stored once, tagged by product, revision and operation, and read by MES/MOM, ERP and PLM alike. Nobody maintains two copies, and every system sees the same approved version.

My view

A standalone QMS is almost always the wrong choice. A good MOM does everything it does, with the production context it will never have, and the operator works in one system instead of two. Escalate serious non-conformances into ERP for the business side, and you have a closed loop with nothing to stitch together.

If you run an MES that covers production only, it can feed a separate QMS, and that works. But it's a compromise, and a full MOM is the better overall solution.

When a CAPA concludes "retrain operators", how do you prove the retraining happened before that operator next ran the job? That's where skills you can enforce close the loop.

Most of the scheduling debate is really about ERP and APS. ERP plans; APS sequences against real capacity. MES/MOM mostly takes the orders once they've been scheduled and releases them to the line, with some basic short-interval scheduling of its own.

The confusion usually starts with the word "schedule" meaning something different in each one.

Different horizons, different jobs

ERP plans in weeks and months. MRP works out what to make and buy, and when, against demand. It mostly assumes infinite capacity, or uses rough-cut checks. Output: planned and released production orders with due dates.

APS (Advanced Planning and Scheduling) sequences in days and hours. It takes those orders and builds a finite-capacity schedule: which order on which machine, in what sequence, respecting changeovers, tooling, labour and material availability.

MES/MOM works in minutes. It tells the line what to run now, records what actually happened, and reacts when reality doesn't match the plan: a breakdown, a quality hold, a missing component, an absent operator.

When is ERP scheduling enough?

More often than people expect. With a handful of lines, stable products and simple changeovers, ERP's scheduling plus a prioritised order list in MES/MOM can cover most needs.

APS earns its keep when sequencing is genuinely hard: sequence-dependent changeovers (light to dark colours, allergen-free before allergen), shared tools or moulds, multi-stage processes where one bottleneck drives everything, or hundreds of orders a day competing for the same resources.

Many ERP suites include APS capability, so it may be a module you already own rather than another system.

Where the scheduling logic lives

There are several ways to split the work:

• ERP schedules, MES/MOM releases. Simplest. ERP releases orders in priority order, MES/MOM shows them to the line and supervisors adjust on the day.
• APS schedules via ERP. ERP sends orders to APS, APS sequences them, the sequence comes back to ERP and down to MES/MOM. ERP stays the single path to the shopfloor.
• APS schedules, with a direct link to MES/MOM. ERP sends orders to APS. APS sends the sequence straight to MES/MOM and receives actuals straight back, so it can reschedule within the shift. ERP still gets order status and confirmations.
• Short-interval scheduling in MES/MOM. Some MES/MOM platforms include detailed scheduling for the shopfloor horizon. Good for plants where the main problem is the next 24 hours, not next week.

Each is valid. The direct APS link suits plants that reschedule several times a shift, where the round trip through ERP is too slow. Plants that reschedule once a day often use the simpler options.

Whichever option you choose, one system needs to own the sequence. If APS publishes a schedule and supervisors re-sequence in MES/MOM, the other system has to be told.

The feedback loop

A schedule is only as good as the data it's built on. And most plans are built on standard cycle times and setup times that nobody has checked in years.

MES/MOM knows the real numbers. Actual cycle times by product and machine. Actual changeover durations. Real availability after breakdowns and micro-stops. Real yield.

Fed back, those numbers improve the plan over time. Without them, planners keep building schedules from outdated standards, and supervisors tend to stop trusting the schedule and run the line from a whiteboard.

Where MES/MOM fits

MES/MOM doesn't need to be your planning system. Its job is releasing the work and feeding back what happened. It shows the line what to run next from the scheduled orders, and reports what actually happened so the next plan is better.

Whatever sits upstream, the operator needs a clear answer to one question: what do I run next? Plus the reason, if it changed. A prioritised order list in MES/MOM, sequenced by the plan, updated when the plan changes, with the materials and tooling status visible.

My view

Not every manufacturer needs an APS. For many, ERP plans the orders, MES/MOM sequences them and releases them to the lines, and supervisors adjust as the day unfolds. That covers a lot of ground, especially with a stable product mix.

An APS earns its place when building a feasible schedule becomes a job in its own right, for example when changeovers decide the sequence or several lines share one bottleneck. Then it's well worth having, and it gets far better results when MES/MOM feeds it what actually happened on the shopfloor.

Whichever route you take, be clear which system owns the sequence. Two systems that both believe they own it is where scheduling goes wrong.

So, when did someone last compare your planned setup times to the actuals?

The fix is agreeing where each one's responsibility starts and stops, rather than picking one winner.

What each one is for

ERP owns inventory as a business asset. Quantities by item and site, valuation, purchasing, receipts, shipments, and the stock that planning relies on. It's the financial truth.

WMS owns inventory in the warehouse. Exact bin locations, putaway strategies, pick paths, wave planning, cycle counts, dock and yard, and any automation such as conveyors or AS/RS. It's the physical truth inside the warehouse walls.

MES/MOM owns inventory on the shopfloor. Line-side stock, kits, work in progress (WIP), what was consumed by which order, and which lot went into which product. It's the truth at the point of use.

I covered the shopfloor side in MES functionality: logistics and warehousing. This article is about the boundaries.

Which option fits your warehouse?

There are several options for warehousing. For the most complex requirements, particularly distribution centres, a WMS is the most advanced option and adds the most value. It makes the most sense when you have:

• High volumes and complex pick strategies
• Warehouse automation to control
• Multiple storage zones with different rules: temperature, hazardous, high-value
• A distribution operation alongside manufacturing

For simpler warehousing, ERP combined with the inventory and logistics capability of a MOM platform can be enough, with MOM running material from receipt to the line.

The boundary that matters: the line

The messy part is the handover between warehouse and production. Let's walk through it.

Replenishment. The line needs material. Who asks for it? There are two good options. MES/MOM can raise the request, because it knows what's running, what's next and what's left line-side, so replenishment follows real consumption or kanban signals. Or ERP or a WMS can plan it from upcoming orders, picking and staging material ahead of time, which keeps warehouse work planned and suits stable schedules.

Delivery. The warehouse picks and moves the material. WMS (or ERP) manages that task and records that stock left the warehouse.

Receipt line-side. MES/MOM takes ownership. From here, it tracks the lot at the line, in a supermarket or at the machine.

Consumption. MES/MOM records what was actually used, by order and by lot. That flows back to ERP for stock and cost.

Output. Finished goods are created and labelled in MES/MOM, then put away in the warehouse and handed over to ERP or WMS.

Where it goes wrong

• Backflushing hides reality. ERP deducts standard quantities when output is declared. Scrap, overuse and substitutions disappear. Record actual consumption in MES/MOM where it matters.
• Line-side stock is a black hole. Material leaves the warehouse and "vanishes" until the next stock count. Give it a location in MES/MOM.
• Two systems manage the same bins. If WMS and MES/MOM both think they own the supermarket, they'll both be wrong. It needs clear ownership and handover in both directions.
• Quality status doesn't travel. A lot put on hold by quality must be blocked in every system that could move or consume it. More on that in QMS and MES.

A simple test

Pick a component and ask three people where all of it is right now: the warehouse manager, the line supervisor and the finance controller. Do the answers match?

The sale is won in CPQ (Configure, Price, Quote). The product is built on the shopfloor. In between, a lot can get lost.

What CPQ does

CPQ lets sales, or the customer directly, configure a product from a set of options and rules. It knows that option A rules out option B, that the large frame needs the heavy-duty base, and what the whole thing costs. It produces a valid, priced quote.

It's particularly good for products with lots of options that have to fit together. Configuring a new car is a good example: the model, engine, trim, colour, wheels and option packs, where some choices rule others out and every combination has its own price. Windows and doors are another. Each one is made to measure, with choices of frame material, glazing, colour, opening style, handles and locks, so no two orders are quite the same. CPQ makes sure the configuration is valid and correctly priced, so sales can quote with confidence and the factory receives something it can actually build.

When the quote is accepted, you have a configuration. A list of choices. That's not something the shopfloor can build from. Yet.

Configuration to order: ERP sits in the middle

In most setups the accepted quote becomes a sales order in ERP, with the configuration attached. ERP then does the heavy lifting:

• Resolves the configuration into an order-specific BOM, using variant rules on a configurable "super BOM"
• Selects the matching routing operations, and drops the ones this variant doesn't need
• Plans materials and capacity
• Releases a production order for that exact variant

That order, with its specific BOM and routing, goes to MES/MOM. From the operator's point of view, it's just an order. The configuration has already been turned into something buildable.

This is the most common pattern, and for configure-to-order products with well-defined options, it works well. ERP is where the configuration has to become cost, stock and capacity anyway.

Where it gets harder: engineer-to-order

Configure-to-order means every option already exists. Engineer-to-order (ETO) means some of it doesn't. The customer wants something the rules don't cover, and engineering has to design it.

Now the flow has a second path. Sales hands over to engineering. Engineering designs the special parts in PLM. Those release to ERP, which updates the order BOM and routing. Only then can the order go to MES/MOM.

Two things I'd watch for here:

• Partial release. ETO products often start production before engineering is finished. Long-lead items and standard sub-assemblies go first. MES/MOM needs to handle an order whose later operations aren't defined yet.
• Order-specific documents. A one-off bracket has a one-off drawing. The operator needs it, at the right revision, at the operation. ERP usually won't carry it.

That second point is where some manufacturers add a direct link from PLM to MES/MOM for drawings and instructions, while the order itself still comes through ERP. I go through the options in PLM, ERP and MES: where the digital thread actually runs.

What the operator needs to see

The configuration should change what the operator sees. Not as a list of option codes, but as instructions for this unit:

• Only the steps that apply to this variant
• The right component, with its picture, at each step
• Option-specific checks, such as wiring tests for the export voltage
• Clear flags for anything unusual, like a customer-special part

That's where digital work instructions that know what's running help. If every operator reads a generic instruction and mentally filters it for the options on the traveller, you're relying on memory. Error-proof it instead: let MES/MOM show only what applies, and scan components against the order BOM.

Options at a glance

CPQ itself connects to ERP, not to MES/MOM. The configuration reaches the shopfloor as part of the order, with its BOM, routing and option codes, so MES/MOM can select the right instructions. Keep ERP's order BOM as the authority. Two systems interpreting the same configuration independently will, eventually, disagree.

Closing the loop

Configured products give you a goldmine of data, if you capture it. Which options take longest to build? Which combinations cause the most rework? Which options get changed after the order is placed? Which "standard" options are really bespoke every time?

That's MES/MOM data. Feed it back to the people who maintain the CPQ rules and the product range. How many of your options are priced as if they're easy to build, when the shopfloor knows otherwise?

A bill of materials changes shape as it moves from design to a finished product. Each stage has a different owner, and a lot of integration arguments come from not agreeing who owns which one.

Stage 1: the engineering BOM

The EBOM describes the product as designed. It's structured by function: the assemblies and parts an engineer thinks in. It lives in PLM, alongside the CAD models and specifications.

What it usually doesn't include: packaging, glue, labels, or the fact that two sub-assemblies are made in different plants.

Stage 2: the manufacturing BOM

The MBOM describes the product as it will be built. Same product, restructured around the process:

• Sub-assemblies grouped by where they're built, not by function
• Consumables, packaging and labels added
• Phantom kits for parts picked together
• Plant-specific variants where two sites build it differently

For configurable products, the MBOM is often a 150% BOM. It holds every possible option and variant in one structure, more than any single product would ever use, with rules that decide which parts apply to which configuration.

In most manufacturers, the MBOM lives in ERP, alongside the routing. That makes sense. ERP needs it to plan, purchase and cost.

There's an option here. Some manufacturers build the MBOM in a manufacturing process planning module that sits with PLM, then release it to ERP. Others receive the EBOM into ERP and restructure it there. Both work. What matters is that there's one owner, and everyone knows who it is.

Stage 3: the order BOM

When ERP releases a production order, it takes a copy of the MBOM for that order, at the revision that's effective on that date, for that quantity. That copy is the order BOM.

For configurable products, this is where the 150% BOM is resolved into a 100% BOM: exactly the parts needed for the configuration the customer ordered, and nothing else. The order BOM is a 100% BOM.

This is what goes to MES/MOM. Not the master MBOM. The specific list of components and quantities for this order.

It can change after release. A planner substitutes an alternative component. A shortage forces a different lot size. That's normal, and it's one reason ERP usually stays in the middle. It has to account for those changes anyway, for cost and stock.

Stage 4: the as-built record

The as-built record is what was actually used. Which lot of component A, which serial number of sub-assembly B, which operator fitted it, at what torque, with which measurements recorded.

This is MES/MOM's job. Nobody else is there when it happens. The as-built record is the foundation of your traceability and, for serialised products, the genealogy you'll need years later when a field failure comes back. More on that in Service data back to engineering.

Who owns what

Where it goes wrong

Nobody owns the MBOM. Engineering thinks manufacturing engineering owns it. Manufacturing engineering thinks it's ERP's master data team. It drifts. It's an ERP master data problem long before it's an MES problem.

The as-built is reconstructed from the order BOM. If MES/MOM just backflushes what the order said it should use, you don't have an as-built record. You have a copy of the plan. That's fine for some products. It's useless when you need to know which customers got the suspect lot.

Some ERPs do record an as-built, but it's based on the materials ERP issued to the order, with no confirmation that what was issued is what was actually consumed. Material gets swapped at the line, part-used packs are finished first, a lot runs out halfway through. That's where MES/MOM helps: it records what was actually used, as it's used, by scanning the lot or serial at the point of consumption.

MES/MOM is asked to own the MBOM. It happens when ERP's BOM is too coarse for the shopfloor, so someone builds the "real" BOM in MES. Be wary of this. You now have two masters, and they will disagree. Fix the MBOM in ERP instead, or add the missing detail as operation-level data rather than a parallel BOM.

Revisions drift apart. The order BOM says revision C. The drawing on the operator's screen says revision D, because it was pulled as "latest" from a shared drive. Every document the operator sees should be tied to the revision on the order.

Where a direct PLM link fits

Some manufacturers send selected engineering data straight from PLM to MES/MOM: drawings, models, critical characteristics. It doesn't change BOM ownership. The order BOM still comes from ERP. The direct link adds context the operator needs to build and check it. For documents and drawings, a central document repository is usually the better option: every document stored once, tagged by product, revision and operation, and read by every system, so there's no need for a direct link at all. I cover the options in PLM, ERP and MES: where the digital thread actually runs.

So, here's a test. Pick a finished product shipped last month. Can you show its EBOM revision, the MBOM it was planned against, the order BOM, and the exact lots and serials that went into it? If any one of those takes a day of digging, that's your gap.

In practice, the thread has knots in it. And the biggest one is usually the handover between engineering and production.

Let's align on what each system does, and then look at how they connect. Because there's more than one right answer.

What PLM owns

PLM (Product Lifecycle Management) is engineering's system. It holds the definition of what a product is:

• CAD models and drawings
• The engineering bill of materials (EBOM)
• Specifications and critical characteristics
• Engineering changes, their approvals and their revision history

It's the source of truth for design. It is not the source of truth for how or where you build it.

What ERP owns

ERP owns the business side of making it. The manufacturing bill of materials (MBOM), routings, costing, purchasing, planning and the production order itself.

The EBOM and MBOM are rarely the same thing. Engineering structures a product by function. Manufacturing structures it by how it's built: sub-assemblies, phantom kits, consumables, packaging, the plant it's made in. That restructuring usually happens in ERP, or in a manufacturing process planning tool sitting alongside PLM. I explain that journey in EBOM, MBOM, as-built: who owns the BOM at each stage.

What MES/MOM owns

MES/MOM owns execution. Which order is running, on which line, by which operator, with which material lot, and what happened. Counts, scrap, downtime, quality checks, genealogy.

MES/MOM doesn't need the whole product definition. It needs exactly the right slice of it, for the order that's running now.

ERP usually sits in the middle

In most manufacturers I speak to, the product data reaches the shopfloor through ERP. PLM releases the EBOM to ERP. ERP builds the MBOM and routing, plans the work and releases production orders. Those orders, with their BOM and routing, go down to MES/MOM.

That's a good design. ERP is where costing, purchasing and planning happen, so it has to know about every BOM and every change. Routing everything through ERP gives you one controlled path and one place where the order is defined.

But it isn't the only option.

When a direct PLM to MES link makes sense

ERP does its job well: items, quantities, operations, cost and the order itself. Carrying a 400 MB 3D model, a 30-step illustrated work instruction or a list of 60 inspection characteristics with tolerances is a different job, and it's one PLM is already doing.

That's where some manufacturers add a direct link from PLM to MES/MOM, alongside the ERP path. ERP still sends the order, BOM and routing. PLM sends the engineering content the operator needs to build it right.

It tends to make sense when:

• You build complex, highly engineered products. Aerospace, defence, industrial equipment. Operators need the drawing, not just a part number.
• Inspection plans come from engineering. Critical characteristics defined in PLM become the in-process checks in MES/MOM.
• Change frequency is high. Where engineering changes land weekly, waiting for them to ripple through ERP adds lag.
• Work instructions are authored in engineering. If they live in PLM, it's simpler to publish them from there than to copy them.

If you make high-volume, stable products with simple instructions, the ERP-only route is often all you need. Don't build an integration you won't use.

There's a better option for documents and drawings than a direct link, though. A central document repository stores every drawing, instruction and specification in one place, tagged by product, revision, operation and equipment. Every application in the landscape reads from it: PLM publishes to it, ERP references it and MES/MOM shows the operator the right revision for the order that's running. That's my preferred solution, and it removes the need for a direct PLM to MES/MOM link for documents at all. Each document is stored once, and every system sees the same approved version.

The hard part: changes and effectivity

Whichever option you choose, engineering changes are where the thread snaps.

An engineering change order (ECO) gets approved in PLM. Then what? Which orders does it affect? The ones already on the shopfloor? Only new ones? From serial number 1042? From a date? When the old stock of a component is used up?

That's effectivity, and it has to be agreed between engineering, planning and production before you design the integration. In my experience, most "MES shows the wrong revision" problems aren't technical. Nobody agreed who decides the cut-in point.

A few rules that help:

• One system decides effectivity. Usually ERP, because it knows the stock and the open orders.
• MES/MOM executes against the revision on the order. Not "the latest" revision in PLM.
• Direct PLM content is revision-locked. If PLM sends a work instruction directly, it must match the revision ERP put on the order.
• Changes mid-order are explicit. If a change has to hit an order already in progress, MES/MOM should force an acknowledgement at the operation, not quietly swap the drawing.

Closing the loop back to engineering

The thread should run both ways. MES/MOM knows things engineering never sees: which characteristics drift, which operations generate the most scrap, which revision caused rework.

Some of that goes back through ERP as cost and yield. The rich detail, such as SPC data against a specific characteristic, is more useful sent straight back to the engineers who own the design. That's a third option worth considering once the downward flow is stable.

So, which path is right for you? Ask your operators what they look at when they build a product. If the answer is a part number and a quantity, ERP has you covered. If it's a drawing they had to print themselves, you may need that direct link.

So if your feed is blowing up too and you want some context, this one's for you. I'm still learning on this topic myself, so treat it as a practical starting point rather than the final word.

What is agentic AI?

Most of the AI people have used is conversational. You ask, it answers, and you decide what to do with the answer.

Agentic AI goes further. An agent is given an objective and works towards it with some autonomy. Broadly, it:

• Perceives. Gathers information about the situation.
• Reasons. Works out what the information means.
• Plans. Decides what needs to happen to reach the objective.
• Acts. Carries out the steps, often by using other software tools.
• Learns. Reviews the result and gets better over time.

The important word is acts. An agent doesn't just tell you the line is running behind. It might re-sequence the schedule, raise a maintenance request or notify the planner. That's a big step up from a dashboard, so it needs careful thought before any agent is allowed to act.

Copilots vs agents

You'll hear "copilot" and "agent" used almost interchangeably. There's a useful difference.

A copilot helps a person when they ask. An operator asks how to clear a fault and gets the answer from the SOPs. A supervisor asks for a shift summary. The person stays in charge of every step.

An agent is given a goal rather than a question. It plans the steps and works through systems to gather information and take actions, until the job is done or it needs a person.

Copilots are usually the easier first step. They're low risk, and you find out quickly where your data lets you down.

What is MCP?

MCP stands for Model Context Protocol. It's an open, standardised way for AI agents to connect to other systems: applications, databases and APIs.

Why does it matter?

• It gives agents a common way to talk to software, without a custom integration for every pairing.
• It describes what data and functions a system offers, so an agent understands what it can do there.
• Agents can discover and use tools in connected systems without everything being hard-coded in advance.
• The system stays in control of what's exposed, so you decide which data and actions an agent can reach.

MCP gives agents a standard way to work across the many systems a factory already runs. Which, if you've ever looked at a factory's application landscape, is exactly what's needed.

What could agents do on the shopfloor?

Some plausible examples, roughly in order of risk:

• Prepare. Pull together the data for the morning meeting and draft the agenda from yesterday's losses.
• Investigate. Trace a customer complaint back through batches, inspections and process parameters, and present a likely root cause for a person to confirm.
• Recommend. Suggest a revised schedule after a breakdown, showing the impact on each order.
• Act within limits. Raise a maintenance work order when a condition threshold is crossed, or put a suspect lot on hold pending inspection.

Notice that the first three still end with a person making the call.

The catch: agents are only as good as what they connect to

An agent that acts on bad data acts badly, and quickly.

If it's reading downtime that was typed in at the end of a shift, inventory that's only roughly right, and quality results sitting in a spreadsheet, its decisions will reflect that. The speed that makes agents attractive also makes their mistakes expensive.

That's why agentic operations sit at the far end of time to truth, the "without asking" stage. They need:

• Trustworthy, real-time data. Captured automatically where possible, validated at the point of work.
• Context. Which order, which material, which machine, which shift. That context lives in MES/MOM.
• Systems that enforce rules. If an agent tries to consume a quarantined lot, the operational system should stop it, just as it would stop a person.
• Clear guardrails and audit trails. What the agent may do on its own, what needs approval, and a record of every action it took and why.

You need to work up to a point where the decisions being made are trusted. Then you can take the human out of the loop and let the system automate the decision making.

My advice

Be curious, not credulous.

Start with agents that prepare, investigate, and act only when approved by a person. Work towards agents making decisions automatically once they've built up trust inside your organisation. Make sure every action is logged and reviewable. And build the foundation alongside the agents. Each agent you add shows you where the data needs to be better, and the factories with clean, contextualised data will get the most from them.

What's the first task you'd trust an agent with in your factory, and what would you never let it touch?

They're all asking the same underlying question: what kind of shopfloor systems do we want to run for the next ten years?

There are broadly four answers.

Online, this debate can get almost political, with very strong voices in every camp. It doesn't need to be confrontational. Different approaches suit different companies, and there are trade-offs whichever way you go.

I'll be upfront about my own position before I start. I work for a vendor of the fourth kind, and it's my preferred approach, particularly for manufacturers with multiple sites. I've tried to describe each approach the way its best advocates would.

1. Code it from scratch

What it is. Your own developers write a bespoke system in a general-purpose language, on your own database and infrastructure. Every screen, rule, report and interface is your code. This is the classic homegrown MES, and plenty of factories still run one.

Where it works well:

• Complete control. It does exactly what you want, in exactly the way you want, and you own the intellectual property.
• Processes no vendor handles well. If your manufacturing processes aren't handled well by any of the main software vendors, code may be the only way to support them.
• No licence fees. The developers' time is the main cost, which can look attractive at first.
• Deep knowledge in-house. The people who wrote it understand your process and your system inside out.

It's usually a better fit for smaller companies with a narrow scope than for enterprises with many sites. Building from scratch is a bit like building a kit car. It can be rewarding, as long as you have the right expertise. But you miss out on years of innovation from people who've done it many times before, and it usually ends up a bit rough around the edges, without any of the comforts and extras.

What to watch:

• The longest road to value. A system of any real scale takes years to build well, including the parts every factory needs, such as genealogy and audit trails.
• People cost more than licences. Hiring people full time to build and run it is expensive, and it gets more expensive over time as people leave and others have to take over.
• The gaps are easy to miss. Product teams spend years on user experience, performance at scale, security, industry best practice, standard KPIs such as ISO 22400, and how data should be stored and structured so you're ready for things like AI. An internal team can get some of the way quickly, but it's hard to match that depth and usability. The people building it are often not MES experts either. AI can speed up the build today, but there's still a real risk the result isn't fit for purpose.
• You own everything, forever. Security patches, operating system and database upgrades, documentation, testing and support all sit with you. Keeping it up to date is hard, so many homegrown systems stagnate, and risk becoming a security threat.
• Key-person dependency is at its highest. When the original developers leave, the knowledge often leaves with them. Towards the end of their life, I've seen many homegrown systems outsourced to try to maintain and improve them, and that's always expensive and a recipe for disaster.
• It gets harder as you grow. Add plants and the need to standardise, and custom code tends to multiply until the system is outgrown.

A typical example: a system written years ago by a small internal team, which still runs the plant and does its core job well. Few people understand how it works, change requests take months, and nobody wants to be the one who touches it.

We often go in and replace homegrown systems that have reached the end of their life: hard to use, no longer secure or performant, and often the person who built them has left. More on what changes when you replace one in Replacing a homegrown MES.

2. Build from building blocks

What it is. You assemble your own applications on a platform made for builders: low-code tools, IIoT and data toolkits, databases, dashboards, with some of your own code where needed. You're not starting from nothing, because the platform handles the plumbing. The tools are flexible, but they're not a finished product. Your people design and build each application, then keep it running.

Where it works well:

• Much faster than coding. Configuring something in a low-code environment is usually far quicker than building it from scratch.
• Flexible. There's a lot of freedom in how you put the blocks together, although you still work within what the platform allows.
• It empowers your own people. Engineers can make changes themselves without waiting for a vendor, as they can with a good configurable platform.
• Lower cost at first. Licences for building-block tools often look modest, and a narrow use case, such as a dashboard or a digital checklist, can be live in weeks. But costs can grow over time, and the total cost of ownership can end up being very high.

You see this most in smaller companies with tech-savvy teams, and some of the platforms in this space are doing very well.

What to watch:

• Joining the blocks up correctly. This is the biggest risk. You have the building blocks, but whether they're stitched together in the right way is down to whoever built them. You're relying on them having connected the right transactions and called the right things, and it gets complicated, especially for the people who pick the system up later.
• It relies heavily on internal skills. Design, testing, documentation and support are yours, for the life of every application.
• Apps can multiply. It's easy to end up with a collection of apps solving narrow problems, rather than one joined-up, connected operation, and it can get messy very quickly.
• You design the data model. Context only exists if someone models it and keeps it consistent as the applications grow.
• Key-person dependency. Knowledge sits with the people who built each app. When they move on, it goes with them. You can fall back on the vendor or a systems integrator if needed, but that goes against one of the main reasons for choosing this approach.

A typical example: a plant with a capable digital team builds a downtime tracking app, which proves useful. Later it builds another app for non-conformances, then one to manage replenishment and movements to the line. Over time the apps are disconnected from each other, even though they all sit on the same platform.

Low-code isn't only for building-block platforms. The best modern MES/MOM platforms include low-code tools of their own for screens, workflows and more. So you can build everything yourself on a low-code platform, or take a MES/MOM platform and configure it, building on it with the same kind of tools. The difference is how much is already built for you, on one connected data model, before you start.

3. Stitch together point solutions

What it is. You buy specific tools for each department or team and connect them: an OEE tool, a quality system, a CMMS, a connected worker app, a scheduling tool. Sometimes they're joined through a unified namespace (UNS), where each application publishes what it knows and subscribes to what it needs.

Where it works well:

• Each team chooses. Each department is able to select its own tool.
• Quick wins, one area at a time. You can start where the pain is biggest without committing to everything at once, although a modular MOM platform lets you grow into it over time too.
• Freedom to swap. If one tool disappoints, you can replace it without replacing everything, though you then have to redo the integrations.

What to watch:

• Integration is the hard part. Integrations between third-party systems work well when they're designed properly, and point-to-point is often the safest option. But each one is a significant part of the project, and needs an owner and retesting whenever either side upgrades. Getting the right people from every team aligned, and making sure each integration is designed correctly, is a big challenge in itself. You can end up with integration spaghetti across the landscape, and when several systems need updating at once, it gets messy.
• A UNS isn't a shortcut. The sender gets no confirmation that data arrived, so data can quietly fail to reach the systems that need it, and it brings its own governance and history challenges.
• Context thins out between systems. You can't pass all the context across every integration, so naturally you share a subset. The quality system knows a sample failed, but not necessarily what the machine was doing at the time.
• A UNS shows what's happening now. It's an organisational structure on top of a broker, so you still need applications around it to add meaning and keep the history. OEE is a good example: you can't aggregate an OEE figure, you have to go back to the raw data. It's a useful pattern, but not a silver bullet.
• Operators juggle applications. Switching screens and logging in and out, losing context at each step. When something goes wrong, which system do they check first? I've seen people try to put a single front end over all the underlying applications, and I've never seen it work well. The applications underneath move on, the front end quickly falls out of date, and every change has to be made in several places at once.
• Hard to scale. When departments choose their own systems, it's usually happening at plant level, not enterprise level. Point solutions chosen that way usually struggle to scale across the landscape, which limits standardisation and benchmarking between sites.
• Someone has to own the architecture. Designing and governing the UNS structure, the data model, the integrations and the security around them is down to you.

A typical example: a site buys a strong OEE tool, a separate quality app and a connected worker tool, each chosen by a different team. Each works well on its own. The work, and most of the value, then sits in connecting them so that a failed check, the order that was running, the material lot and the operator's sign-off all line up.

4. Configure an out-of-the-box platform

What it is. You buy an MES/MOM platform that already covers production, quality, inventory, maintenance and more on one data model, and you configure it to your processes rather than coding it. Most are modular, so you can start with one or two functions and switch on more as you go. You extend it at the edges where you genuinely need to.

Where it works well:

• The data is connected and contextualised from the start. A downtime event, a quality result, a material consumption and an operator's sign-off all belong to the same order, in the same system.
• No integrations between shopfloor functions. Production, quality, inventory and maintenance share one database, so nothing waits to be transferred. Operators get one login and one interface, and context stays intact as they move between tasks.
• The vendor builds and maintains it. Best practice from many factories, standard KPIs, upgrades, security and new capabilities such as AI all arrive through the roadmap, paid for across many customers.
• Start small on the right path. Begin with production or quality, then add inventory, logistics, maintenance, tooling or energy later without a new project to connect them.
• You can still make it your own. A good platform lets you build your own screens, reports and workflows with low-code tools, without going back to the vendor.

What to watch:

• Costs can look higher up front. The whole scope and journey is evaluated at the start, so the total cost of ownership is more visible than with the other approaches. There are fewer indirect costs, but more direct ones. Expect the cost per site to start higher, then fall significantly as you roll out to more sites.
• You adapt some processes. You'll need to decide the mix: where you adapt to the system, and where the system adapts to you. Adapting isn't a bad thing. These systems are often built around best practice, so go into those conversations with an open mind.
• Not every platform is truly configurable. Some are really toolkits that need a lot of coding to fit together, or a number of acquired applications that aren't well integrated. Check how much is configuration and how much is customisation.
• Integrations still need work. Configuration reduces customisation, but rarely removes it entirely, especially for integrating equipment and third-party software.
• You depend on a vendor. Their roadmap and commercial health matter, so choose carefully. See How to choose an MES.

A typical example: a manufacturer goes live with production and quality on its first site, then switches on inventory and maintenance on the same platform the following year, without building an interface between them.

Side by side

Most factories end up with a mix

In practice very few factories are purely one type. A common and sensible pattern is a platform as the operational backbone, with specialist systems where the requirements are genuinely advanced, such as a WMS for complex warehousing or an EAM for advanced maintenance. Connect it to the wider business through direct interfaces, and some building or coding at the edges for the things that really are unique, ideally managed in a standard way as part of the platform.

So the real question is which one you make the backbone.

How to decide

• What will each option cost over ten years, including your own people, not just the first quote?
• Who maintains it when the original team moves on?
• How much of the value depends on data from different functions lining up in real time?
• How many interfaces will you own, and who will monitor them?
• Is your manufacturing process really unique, or is it the business processes around it? See Configure, don't customise.
• How will you add AI and new capabilities, and who will build them?

My view

Personally, I like being part of a connected ecosystem. It's a bit like a phone, laptop and watch from the same ecosystem: everything works together, and it gets better over time.

I think a configurable platform gives the most value over time, particularly for large, multi-site manufacturers. All the data is connected and in context from the moment it's captured. There are no integrations between shopfloor functions to build or maintain, and nothing waits to be transferred. And you're not building and maintaining it yourself for ten years. The vendor does that, across many customers.

That's a view, not a law. Processes no main vendor handles well can justify writing your own code, and a smaller company with a strong digital team can do very well building from blocks. Building and configuring aren't really competing, because they suit different kinds of business. A site with good specialist tools already in place, and the discipline to govern the integrations between them, can get a lot from stitching.

Whichever you choose, start on the right path, with the destination in mind.

If you're already running a homegrown system, there's no shame in it. Many were written when the market had nothing suitable, and they've served their factories well.

Which of the four is your backbone today, and is it the one you'd choose again?

But a twin is only as good as the data feeding it. And for most of what happens in a factory, that data comes from MES/MOM.

What is a digital twin?

A digital twin is a virtual model of a physical asset, process or entire factory, kept in sync with the real thing through live data, and used to understand and predict how it behaves.

There are different flavours. A twin of a single machine, used by engineers to model wear or tune performance. A twin of a production process, used to test changes before making them. A twin of a whole factory, used to plan layouts, capacity and investments.

Most serious definitions share four ingredients:

• A model of the physical thing: its structure, behaviour and constraints.
• A live connection that keeps the model in step with reality.
• History, so the twin learns how the real thing behaves over time.
• A purpose: simulation or prediction that helps someone make a better decision.

MES/MOM isn't the model, and it doesn't do the simulation. What it does is supply much of the live connection, in a form the model can actually use.

Why MES/MOM matters to a twin

Think about what a well-implemented MES/MOM knows at any moment:

• Every line and machine, and its current state: running, stopped, in changeover
• Which order is running where, and how far through it is
• Every lot of material, where it is, what state it's in and what it was made from
• Every quality result, linked to the product and process conditions at the time
• The condition and maintenance status of each asset
• Who is working where, and what they're qualified to do

That's real-time operational data, already in context. Not just "machine 7 stopped", but which order was running, on which shift, with which material, for how long and why. A twin needs exactly that to stay true to the factory it represents.

Sensors and historians give a twin the physics: temperatures, pressures, speeds. PLM gives it the product and process design. MES/MOM gives it the operational reality: what's being made, where, by whom, how well, and what got in the way.

What the twin adds on top

Where a digital twin goes further is the model and the simulation. Running what-if scenarios before you change anything in the real world:

• What happens to throughput if we add a second shift on Line 2?
• Where's the new bottleneck if we speed up the filler by 10%?
• Should we buy another press, or fix the changeovers on the ones we've got?
• What does next month's schedule look like if this order slips a week?

That's where I find the future genuinely exciting. Data-driven decisions about investments, layouts and schedules, tested virtually first, instead of argued over in a meeting.

Simulation is only as good as the data behind it

A simulation built on assumed cycle times, estimated downtime and a theoretical capacity model will give you very confident, very wrong answers.

The value comes from a twin that's fed by reality. Actual cycle times by product. Actual downtime patterns by machine and shift. Actual scrap rates. Actual changeover durations.

Which brings us back to the data foundation. MES/MOM, historians, connected equipment and data platforms feeding the twin with a live, accurate, contextualised picture. Build that, and simulation becomes trustworthy. Skip it, and your twin is a very attractive guess.

Get the data flowing before you build the twin

I'm wary of digital twin projects that start with the visualisation. The 3D model looks impressive in the boardroom. But if the data behind it is typed in at the end of each shift, it's a nice picture of a factory that doesn't really exist.

Start with the data source you probably already need: MES/MOM capturing what's actually happening, accurately and in context. Then build the twin on top of it, aimed at a real decision you need to make.

Is there a decision coming up in your factory that you'd love to test virtually before committing to it?

If you can explain why each of these is wrong, you'll be ahead of most people in the room.

1. "AI will solve everything on its own"

AI can do a remarkable amount in a factory. What it can't do is learn from data that was never captured.

Most manufacturers still struggle to capture accurate, contextualised data from the shopfloor, while their ambitions for AI grow fast. That's healthy, as long as the two move together. Predictive and optimising AI learns from your operations, so it gets better as the data does. Manual entries and delayed ERP transactions give it little to work with. Automatic capture with context gives it a great deal. Generative AI can help from day one, working on your documents, procedures, maintenance notes and shift logs, and even turning messy history into usable data. Build the data and the AI together, and each makes the other worth more.

More on this in AI will transform your factory, if you give it the right data.

2. "Excel is good enough"

Excel is the number one competitor to MES/MOM. That should worry people more than it does.

It's flexible and familiar, which is exactly why it's dangerous. Spreadsheets become the de facto system for production, quality and downtime. They get emailed around and saved locally, and nobody knows which version is current.

Excel has no real-time capture, no validation, no traceability, no equipment connection and no audit trail. It's a brilliant tool for analysis. It's a terrible system for running operations.

3. "Smart manufacturing is just MES/MOM"

I spend a lot of time explaining why MES/MOM matters, so this one might surprise you.

MES/MOM is the operational backbone. But a smart factory is broader: ERP for the business, PLM for product data, scheduling, warehousing, the lab, connectivity, historians, data platforms, analytics and AI. MES/MOM sits at the heart of it. It isn't the whole thing. See The smart factory tech stack.

4. "Why do I need MES if I have ERP?"

ERP manages the business. MES/MOM manages the factory.

ERP works at the level of detail business planning needs. MES/MOM works at the granular, real-time level the shopfloor needs, with interfaces designed for frontline workers rather than office users. You'd never use an MES to do the job of an ERP, so why use an ERP to do the job of an MES?

ERP data actually gets better when MES/MOM is in place, because it receives validated actuals rather than backflushed estimates. More in MES vs ERP.

5. "IIoT replaces MES/MOM"

IIoT sounds cooler. It's trendier. But connecting sensors and collecting data is only a small part of what MES/MOM does.

IIoT gives you data points. MES/MOM turns them into operational management: running orders, enforcing quality checks, tracking inventory, handling maintenance. They're complementary, not interchangeable. I go into it in IIoT doesn't replace MES.

6. "Connected worker is the same as MES/MOM"

It isn't. Standalone connected worker platforms handle checklists, tasks, handover and skills. All valuable. But they don't run production orders, perform SPC or manage traceability.

Connected worker belongs inside MES/MOM, so the operator gets one application with full production context. Bolted on beside it, you've given them two. See Connected worker: one app, not five.

7. "Our processes are unique"

Unless you're doing something truly niche, your manufacturing processes are not unique.

What may be unique are your business processes around manufacturing. Most "we're different" conversations turn out to be habit, comfort and workarounds that grew over time. Question them before you pay to build them into software. More in Configure, don't customise.

8. "We'll build our own"

For a small manufacturer with capable technical people, or a narrow scope, a homegrown system can work well for a while. As requirements grow, it often runs out of steam.

Requirements grow. The person who built it becomes the single point of failure, and eventually they leave. No vendor support, no upgrade path, no roadmap. I've seen a lot of homegrown systems replaced, and the hidden costs are usually higher than anyone expected. I compare the options in Code, build, stitch or configure.

A bonus one: "MES and MOM are just two names for the same thing"

They're often used that way, and I've done it myself. But really they describe different scopes. MES is the production pillar. MOM covers production, quality, inventory and maintenance on the same data. Plenty of products sold as "MES" only cover production, so ask which pillars a system actually handles. More in What is MES/MOM?

Which of these do you hear most often? And which one did I miss?

A smart factory runs on several applications working together. The skill is knowing what each one is for, where the boundaries sit, and when you actually need it. Get that wrong and you either over-buy or stretch a system into a job it was never designed for.

Let's go through it layer by layer.

The enterprise layer

ERP (Enterprise Resource Planning) runs the business. Finance, procurement, sales orders, costing, high-level planning and inventory valuation. It's where production orders are usually created, based on demand and stock. More in What is ERP?

PLM (Product Lifecycle Management) holds the product definition. Engineering designs, specifications, bills of materials, changes and their approvals. It's the source of truth for what a product is. More in PLM, ERP and MES.

APS (Advanced Planning and Scheduling) produces detailed, constraint-based schedules when ERP's planning isn't enough. Useful where you have complex sequencing, shared resources or tight changeover constraints. More in APS vs ERP scheduling.

EAM (Enterprise Asset Management) manages physical assets across their whole life, including their costs, for asset-heavy businesses with advanced needs. ERP often covers the asset register, depreciation and capital spend already, so check what it does first. Day-to-day maintenance belongs in either a MOM platform or a standalone CMMS. A MOM platform is preferable, because it keeps production and maintenance on the same data. More in CMMS vs EAM vs MES.

The operations layer

MES/MOM runs the factory. It receives orders from ERP, executes them on the shopfloor, enforces quality checks, tracks inventory and traceability, supports maintenance, guides operators and sends actuals back. I explain the distinction between MES and MOM in MES vs MOM.

It sits at the heart of the stack, because it's the system that connects the business to the machines, and the departments to each other.

Alongside it, depending on how much depth you need:

• WMS (Warehouse Management System) for complex warehousing: optimised picking, storage strategies, automation, yard and dock management. It's the most advanced option for the most complex warehousing, particularly distribution centres. For simpler warehousing, ERP or the inventory capability of MOM can be enough, but it really depends on the situation. More in WMS vs MES vs ERP.
• LIMS (Laboratory Information Management System) for lab testing, sample management and certificates, mainly in lab-heavy, regulated industries. Most manufacturers don't need one. More in LIMS and MES.
• QMS (Quality Management System) for enterprise quality processes: complaints, CAPA, audits, document control. A good MOM platform covers most of this alongside shopfloor checks and SPC, with serious non-conformances and CAPA escalated into ERP, which replaces the need for a separate QMS. More in QMS vs LIMS vs MES.

How they connect

The systems above can be integrated through ERP, directly to MOM, or a mix of both. In the middle sits MOM, covering production, quality, inventory and maintenance on one set of data. Pick a pattern, an application or a part of MOM to see what it does and what flows where.

The connectivity layer

Below the operations layer sit the machines, PLCs and sensors, and the connectivity that links them upwards: OPC UA and MQTT, sometimes a separate IIoT platform, and occasionally a unified namespace. MES/MOM often provides that connectivity itself. I explain those in OPC UA, MQTT and UNS in plain English.

The golden rule here: don't connect ERP directly to machines. ERP needs aggregated data at sensible intervals, such as confirmations, consumption and scrap, not raw machine signals. Turning one into the other is MES/MOM's job.

The data layer

Historians store high-frequency time-series data: every temperature reading, every pressure, every second. MES/MOM also reads time-series values and adds context, and for most manufacturers that removes the need for a separate historian. Only in rare cases do you need both. More in Historian vs MES.

Data warehouses, lakes and platforms bring data together from MES/MOM, ERP, historians and other sources for reporting, analytics and AI.

I go into those in Historians, data lakes and data fabric.

How it fits together

Two ways of looking at it help.

Vertically, it's the ISA-95 stack. Orders, schedules and master data flow down from ERP. Actuals, consumption and quality results flow up from the shopfloor. Each layer works at the level of detail it needs.

Horizontally, it's the flow of a customer order through the factory: from product design in PLM, to the order in ERP, the schedule in APS, execution and quality in MES/MOM, storage in WMS, and shipment back through ERP.

Questions to ask about each system

For every system in your landscape, ask:

• Is the functionality we already have enough for our requirements here?
• If not, do we need more depth in an existing system, or a dedicated application?
• Where exactly is the boundary, and what data crosses it, how often, at what level of detail?
• Who uses it, and how many applications will they need to open to do their job?

Don't skip that last question. Every boundary you add is an integration to build and maintain, and often another screen for an operator.

It's not a one-size-fits-all approach. It changes with your processes, your scale and your budget. But it pays to make long-term, deliberate decisions and pick applications that will grow with you.

Which system in your landscape is doing a job it was never designed for?

Increasingly, MES/MOM is being implemented as an enterprise application rather than a site-by-site project. The decision is made once, for the whole business, and the rollout to each site is then planned and phased. That changes how you organise for it.

The template approach

The idea is straightforward. You build a standard configuration that represents your global way of working: the template. Then you roll it out to each site, adjusting only what's genuinely necessary for local conditions.

The template defines:

• Standard processes for production, quality, inventory and maintenance
• Master data standards: naming, hierarchies, units, reason codes
• Global KPIs, calculated the same way everywhere
• Standard screens, reports and workflows
• Standard integrations with ERP and other enterprise systems

Why it works

Consistency. Every site measures OEE the same way, so you can compare and benchmark them.

Speed. Later sites go live much faster, because most of the work is done.

Lower cost. You configure once and deploy many times, rather than paying for the same design work at every site.

Easier support and upgrades. One standard is far easier to maintain than ten variations.

The hard part: managing local variation

Every site will tell you it's different. Some of the time, it is. Most of the time, it's habit.

Different sites often make the same or similar products with different processes. Sometimes the process even changes on the same equipment depending on who's working. That variation evolved organically or was driven through acquisition, but it's something you'll need to consider carefully if you want to standardise.

Use the rollout to drive genuine consistency. Allow and manage local differences where there's a real reason: regulation, a genuinely different process, a different product. Remove or limit the rest, where it's really just habit. This is where process mapping pays for itself.

The centre of excellence

The template needs an owner. Increasingly, that's an enterprise centre of excellence: a dedicated team driving adoption across every factory in a consistent, considered way.

It's a blend of IT and OT:

• IT because it owns the application, infrastructure, landscape and integrations.
• OT because it owns master data standards, manufacturing processes, screens, global KPIs, inspection plans, maintenance procedures and workflows.

Companies that build strong central teams like this tend to thrive when it comes to delivering MES/MOM across many sites.

Local teams still matter

A centre of excellence doesn't replace site teams. Each site still needs local champions, super users and someone who owns adoption on the shopfloor. They become extensions of the centre of excellence at each plant.

A model that works well: the centre owns the standard and the roadmap, the site owns adoption and continuous improvement, and both feed lessons back into the template.

Start the template with your first site

Even if you're starting with one factory, design with the template in mind. Keep site-specific decisions separate from global ones. Document why each choice was made.

It's much easier to build a template from a first site designed that way than to untangle one that wasn't.

How many different versions of "the same process" are running across your sites today?

• About 37 million commercial flights took off in 2024, roughly 100,000 a day. At 99.99%, ten of them wouldn't land safely. Every day.
• Pharmacies in England dispense about 1.16 billion prescription items a year. At 99.99%, more than 300 people a day would get the wrong medicine.
• Your heart beats about 100,000 times a day. At 99.99%, it would miss ten.
• A line making a million parts a week would ship 100 bad ones, every week.

You can't inspect your way to that level of quality. Checking every part is expensive and slow, and when the test destroys the part, it's impossible.

SPC is the alternative. Instead of inspecting everything, you measure a sample at the right frequency and use statistics to show how capable the process is, and whether it's changing. It keeps the number of inspections down while keeping quality high, and it gives you a level of confidence you can trust.

Inspection tells you a part is bad. SPC tells you a part is about to be bad.

That's the other big difference, and it's why statistical process control is one of the most valuable things you can put in front of an operator. Yet in a lot of plants, SPC still means a quality engineer updating a spreadsheet at the end of the week. By then, the scrap is already in the bin.

Specification limits vs control limits

This is the concept people mix up most, so let's align on terminology.

Specification limits come from the customer or engineering. A shaft must be 25.00 mm, ±0.05 mm. Inside the limits is good. Outside is scrap or rework.

Control limits come from the process itself. They're calculated from your own data, typically three standard deviations either side of the average. They show the process's natural variation, so you can tell when something has changed.

A process can be in control and still make scrap, predictably, if its natural spread is wider than the specification or sits too close to one limit. And a process can be entirely within specification while going out of control, drifting steadily towards a limit. That second case is exactly what SPC exists to catch.

Control charts

A control chart plots measurements over time, with the average and control limits drawn on. Operators look for points outside the limits, or patterns that shouldn't happen by chance.

For variable data (things you measure, such as length, weight or temperature), the common charts are:

• X-bar and R: averages and ranges of small subgroups, say five parts every hour
• X-bar and S: the same, using standard deviation, for larger subgroups
• I-MR: individual values and moving range, when you only get one measurement at a time, like a batch result
• EWMA or CUSUM: weighted charts that pick up small, slow shifts sooner than the standard charts

For attribute data (things you count), the choice depends on two questions:

The rules that matter

A point outside the control limits is the obvious signal. But patterns inside the limits often tell you more. The ones I'd teach every operator:

• One point beyond the control limits. Something just changed.
• Seven or more points in a row on one side of the average. The process has shifted.
• Six or more points steadily rising or falling. A trend, often tool wear or temperature drift.
• Points hugging the limits, or alternating up and down. Over-adjustment, or two streams mixed together.

Don't switch on every rule. Too many alarms and operators learn to ignore them. Start with a few, then add more where they prove useful.

Capability: Cp, Cpk, Pp and Ppk

Capability compares your process spread with the specification.

• Cp asks: if the process were perfectly centred, would it fit within the specification?
• Cpk asks: given where the process actually sits, does it fit?

Pp and Ppk ask the same two questions, but measure the spread differently.

Cp and Cpk use the variation within subgroups, the short-term spread you'd see in five parts made one after another. That's the process's potential when nothing else moves.

Pp and Ppk use the overall variation across all the data, including the shifts between subgroups: a new lot of material, a different shift, a tool change. That's what the customer actually receives.

On a stable process, the two sets of numbers are close. If Cpk is much higher than Ppk, the process is moving between subgroups, and that's where to look. Ppk is often used for initial studies of a new process, and Cpk for ongoing production once it's proven stable.

A Cpk of 1.33 is a common minimum for ongoing production. Automotive customers often ask for 1.67 on safety and critical characteristics, and for a Ppk of 1.67 in the initial study before production approval. Check your own customers' requirements; they vary. If your Cp is good but your Cpk is poor, you don't need a better machine. You need to centre the process.

Capability only means something when the process is in control. Calculate it on a process that's all over the place and you'll get a number. It just won't mean anything.

Why SPC belongs in MES/MOM

SPC works when the person who can act on it sees it in time. That's the operator, at the line, during the shift.

Running SPC in MES/MOM gives you things a standalone tool or spreadsheet can't:

• Checks triggered by what's running. The right characteristics for this product, at the right frequency.
• Data from the gauge, not the clipboard. Connected instruments remove transcription errors.
• Context on every point. Order, lot, machine, tool, operator, shift. When the chart shifts, you can see what changed.
• Action, not just alarms. A rule violation can require the operator to record a reason and a corrective action before continuing, or put the lot on hold.

I covered inspection plans and quality operations in MES functionality: quality operations. SPC is the part that turns those inspections from a pass/fail record into an early warning.

Closing the loop

SPC data is gold upstream too. Engineering wants to know which characteristics are hard to hold, so they can rethink tolerances or design. Quality wants trends across sites, in MOM or in a QMS where one is used. Where critical characteristics are defined in PLM, sending the capability results back closes the digital thread.

Here's a question to take to your next quality review: of last month's scrap, how much showed up as a trend on a control chart first, and nobody acted on it?

The frontline gets less attention. I think that's a mistake, because it may be where AI makes the biggest difference to how a factory feels day to day.

The real problem AI can help with

Imagine having your best people working all the time. On the night shift. On a bank holiday. On the first day of a new starter.

That's the opportunity. Your most experienced operators carry years of knowledge about how each machine behaves, what each product needs, and what to do when something odd happens. As they retire, that knowledge leaves with them.

AI is there to help those people go further. It can capture what they know and put it in front of everyone else, at the moment they need it.

What works today

An operator copilot. A plain-English assistant on the screen the operator already uses. "What's the changeover procedure for this product?" "What does this alarm mean?" "What did we do last time this fault came up?" Answers in seconds, drawn from your procedures and history.

Shift summaries. Generated from what actually happened: orders, stops, quality checks, outstanding actions. The supervisor reviews instead of writing from memory. More in Shift handover is a process.

Real-time coaching. When process data drifts towards a known problem, the system suggests the corrective action an experienced operator would take, before it becomes scrap.

Visual inspection support. On high-volume lines, vision systems reject defects automatically, because no operator could keep up. Where a defect is harder to judge, or volumes are low, image recognition can flag it for the operator to confirm, so nothing gets missed.

Why context decides whether it's useful

A generic chatbot can tell you what OEE is. It can't tell you why Line 4 stopped three times this morning.

To be genuinely useful on the shopfloor, an AI assistant needs to know:

• Which order is running, and on which machine
• The material, its lot and its quality status
• What's happened on this line recently: stops, reasons, results
• The current, approved procedures for this exact operation
• Who's asking, and what they're qualified to do

All of that lives in MES/MOM. When connected worker and AI are built into the operational platform, the assistant has direct access to the context that makes its answers right. When it's a separate tool, it's guessing.

Keep people in charge

A few principles I'd hold to:

• Assist, don't decide. AI suggests; the operator or supervisor decides, especially anywhere quality or safety is involved.
• Show the source. An answer should point back to the procedure or the data it came from, so people can check it.
• Respect the system's rules. If MES/MOM would block an action, an AI suggestion shouldn't get round it.
• Learn from the floor. Let operators flag wrong or unhelpful answers. They'll tell you quickly.

The people who benefit most

New starters benefit most, and fastest. They get answers without interrupting someone every ten minutes, and they're guided through tasks they've only done once.

But experienced operators benefit too. Less time answering the same questions. Less time on paperwork. More time on the work that actually needs their expertise.

That's the goal. Not fewer people, but every person working closer to your best.

What's the question your new starters ask most often, and who answers it today?

But research gets quoted badly. A number from one survey turns up on a vendor slide with no source, no date and no context. So here are the figures I find most useful, where they come from, and what they actually tell you.

Manufacturers believe in it, and they're spending

Deloitte's 2025 Smart Manufacturing Survey asked 600 executives at large US manufacturers (over $500 million revenue and 1,000 employees) about their plans (Deloitte, 2025).

• 92% believe smart manufacturing will be the main driver of competitiveness over the next three years.
• 78% allocate more than 20% of their improvement budget to smart manufacturing.

My first question on seeing the 92%: what on earth are the other 8% doing?

The more useful point is the second one. Strategy without investment is wishful thinking. These numbers suggest manufacturers are finally backing their digital ambitions with real money.

The reported returns

The same survey asked respondents what they'd seen from their smart manufacturing initiatives. On average:

• Production output: 10% to 20% improvement
• Employee productivity: 7% to 20% improvement
• Unlocked capacity: 10% to 15% improvement

Those are big numbers, and they line up with what I see in real projects. More output from the same equipment. Less time spent on manual data entry and chasing information. Capacity that was always there, hidden in micro-stops and slow changeovers.

To put capacity in context: what would just a 1% improvement in OEE mean for your business? For most manufacturers it's a very significant number, and it's not uncommon for improvements to be in the 10% to 20% range.

Most manufacturers haven't started

MarketsandMarkets puts the global MES market, software and services together, at around $16 billion in 2025, growing to almost $26 billion by 2030 (MarketsandMarkets). Software-only estimates are lower: IoT Analytics puts MES software at $5.5 billion in 2024 (IoT Analytics, 2025). IoT Analytics also reports that 54.4% of small and medium-sized manufacturers still rely on manual methods (pen and paper or spreadsheets).

That's the opportunity. If most of your competitors are still running on paper and Excel, investing now is a genuine competitive advantage, not just catching up.

The people problem is driving it

Two more figures explain why investment is accelerating.

• 72% of industrial organisations report negative impacts on operational performance from frontline workforce issues (LNS Research, 2023).
• US manufacturing could need 3.8 million new employees between 2024 and 2033, and 1.9 million of those roles could go unfilled (Manufacturing Institute and Deloitte, 2024).

When you can't hire your way out of a problem, you have to make the people you've got more effective, and make new starters productive faster. That's a big part of the case for connected worker and MES/MOM.

What the research doesn't tell you

Be careful with averages.

• They describe large companies. This survey focused on manufacturers with over $500 million revenue. Your results may differ, in either direction.
• They're self-reported. Respondents say what they've seen. That's useful, but it isn't an audited result.
• They lag. Surveys capture what happened over the last year or two, in a market moving quickly.
• They don't tell you how. The same technology delivers very different returns depending on the processes underneath it, the team running it and whether the data is trusted.

None of that takes away from the research. Studies like Deloitte's are one of the best views we have of what manufacturers are actually achieving, at scale, and the message is clear and encouraging: the returns are real, and they're there for the taking.

In my experience, the difference between a small improvement and a big one comes from getting the technology and the people right together: the right platform, processes fixed first, data that's trusted, and leadership that stays committed after go-live.

Use the research, then build your own case

Research is useful for one thing above all: getting leadership to take the conversation seriously. It won't approve your budget on its own.

For that you need your own numbers. Your downtime, your scrap, your overtime, your late deliveries, translated into money. I walk through how in How to build an MES business case leadership will sign.

Which of these numbers would land best with your leadership team?

Ask a different question, such as how much capacity is hiding in the hours we don't run at all, and you need a different measure. That's where OOE and TEEP come in.

They all share the same core

All three multiply availability, performance and quality. Performance and quality are calculated exactly the same way in each. What changes is the time you measure availability against.

I explain the calculation itself in What is OEE?. This article is about the time base.

Three time bases

Think of a week as a stack of time:

• Calendar time. Every hour there is: 24 hours a day, 7 days a week.
• Operating time. The hours the factory is open and staffed.
• Planned production time. Operating time minus planned stops such as breaks, meetings, trials and planned maintenance.

Each measure uses a different layer as its baseline.

Because the baseline grows each time, the numbers fall as you go down the table. A line can show a healthy OEE and a much lower TEEP, simply because it only runs two shifts a day, five days a week.

A quick example

Take a line that's open 80 hours a week, has 8 hours of planned stops, and runs 60 of the remaining 72 hours. Assume performance and quality are both 90%.

• OEE availability = 60 ÷ 72 = 83%. OEE = 0.83 × 0.9 × 0.9 = 67%
• OOE availability = 60 ÷ 80 = 75%. OOE = 0.75 × 0.9 × 0.9 = 61%
• TEEP availability = 60 ÷ 168 = 36%. TEEP = 0.36 × 0.9 × 0.9 = 29%

Same line, same week. Three very different numbers, each one right for its question.

When to use which

Use OEE for day-to-day improvement. It's what operators and supervisors can influence directly, and it's the measure most people recognise. Measure it on the bottleneck.

Use OOE when you suspect planned stops have crept up. Long breaks, overrunning meetings, generous changeover allowances and planned maintenance during peak demand all hide inside OEE's baseline. OOE exposes them.

Use TEEP when someone asks for a new line or another big capital investment. A low TEEP with a decent OEE often means the capacity already exists, in the hours you don't currently run. Before you buy a new machine, ask whether adding a shift would do the job.

Getting the data right

All three depend on the same thing: accurate time data. You need to know when the line was running, stopped, in a planned stop or not scheduled at all, and you need the reasons. Recorded from memory at the end of a shift, none of these measures is worth much. Captured automatically by MES/MOM from the equipment, they all fall out of the same data.

ISO 22400 defines manufacturing KPIs formally, and is worth using if you compare figures across sites.

What's your TEEP, and has anyone ever asked?

MES/MOM should be the answer to a lot of that. When it's implemented well, it is.

But too many food projects stumble. The technology matters, and choosing the right platform is one of the biggest decisions you'll make. The people matter just as much, and they're the part that's most often underestimated. These are the four barriers I see most often, and what to do about each.

1. People need as much attention as the technology

Most project plans are built around the technology: the platform, the integrations, the configuration. That work is essential. But the team you build, and how you bring the shopfloor with you, has just as big an impact on your success. Without the right people in the right roles, and a sponsor who'll clear the way, even the best system will struggle to deliver.

I speak to many food manufacturers who underestimate the change management. Operators have run the same process for years, sometimes decades. Ask them to adopt a new digital system without involving them in the design, or explaining why, and you'll get resistance. Sometimes quiet, sometimes not.

Get operators involved early. They know the process better than anyone, including the workarounds that never made it into the SOP. Their input makes the system better. Their buy-in makes adoption faster.

2. Starting too big, too fast

The second mistake is trying to do everything at once. Production, quality, inventory, maintenance and traceability, across every line and every site, on day one.

It's doable. But it multiplies the risk, and food is not an industry that forgives a bad week on the line.

Phase the delivery, and get early wins on the board, but make the decision as a company.

The manufacturers who succeed think big and start pragmatically. They know the end state. They just don't try to get there in one leap.

3. Underestimating the data foundation

Food manufacturers often want the headline capabilities straight away: real-time OEE, automated batch traceability, SPC on critical quality parameters, digital allergen control. All the right things to want.

But they sit on top of the unglamorous basics. Master data. Recipes and bills of materials. Routings. Equipment hierarchies. Specifications and inspection plans.

Food adds its own layer of complexity here. Recipes with substitutions, variable yields from natural raw materials, units that change from kilograms in to cases out, shelf-life rules that differ by product. If that isn't defined properly, nothing downstream works properly either.

I'd urge anyone starting an MES/MOM project to invest properly in this phase. Rushing through data preparation to reach the exciting functionality is one of the most common causes of delay and rework I see. Get the data right first. The rest follows.

4. Choosing the wrong platform

Be wary of a cheaper solution chosen as a stop-gap.

Too many food manufacturers fill one gap with one small tool. A checklist app for hygiene sign-offs. A standalone OEE dashboard. A separate quality app for line checks. Each solves today's problem. Few of them share data, and none of them can grow into what you'll need next year.

Food is the industry where that hurts most, because the questions that matter cut across every department at once. Which batches of finished goods contain this lot of raw material? Did it pass goods-in inspection? Which line ran it, after which clean-down, with which allergen changeover? Answer that from four disconnected systems and your two-minute recall becomes a two-day investigation.

Pick a mature, configurable MOM platform from the start. One that puts production, quality, inventory and maintenance on the same data, and handles food's specific requirements natively rather than through customisation:

• Batch and lot traceability, forwards and backwards
• Recipe and formulation control, including substitutions
• Shelf-life, expiry (FEFO) and FIFO enforcement
• Allergen management and changeover validation
• Yield and give-away tracking at the line

Yield is often the single biggest profit lever in food. A system that shows you give-away by line, by shift and by product in real time can pay for itself on that alone.

Practical advice for anyone starting the journey

Assemble the team before you touch the technology. You need an experienced project manager, operational subject matter experts, IT support, and an executive sponsor who will clear roadblocks. If you lack MES/MOM expertise internally, bring in an experienced partner, ideally one who has delivered MES/MOM in food before. A good consultant or systems integrator shortens the learning curve enormously.

Define success early, and make it specific. What does good look like after phase one? Scrap down by a set percentage? Batch release in hours rather than days? Digital traceability for every finished pallet? Allergen changeovers signed off digitally? Measure it, and use the system to capture the data that proves it. That evidence is what funds phase two.

Don't underestimate quick wins. When an operator sees their own downtime data for the first time, or a quality manager traces a batch in seconds rather than hours, adoption accelerates. Those moments build momentum. And momentum is what carries a project from a pilot line to an enterprise standard.

If you're in food and beverage and partway through a project, which of these barriers is giving you the most trouble right now?

When you've built something in-house, moving to a commercial platform brings challenges most manufacturers don't see coming. The technical work is significant, and the people side is just as big. It's the part most plans leave out.

The developers who built it

Your in-house team can be your greatest asset or your biggest obstacle.

They know every quirk. The workarounds, the business rules, the integrations, the reasons things are the way they are. That knowledge is irreplaceable during a transition.

They're emotionally invested. They've spent years building something that worked. Watching it replaced can feel like a rejection of their efforts.

They can make or break the project. These are smart people. You want their energy going into making the new system succeed, not quietly undermining it.

Your job is to turn them from reluctant participants into champions:

• Give them ownership. Position them as the bridge between old and new. Make them super users. Give them a job title that reflects the new responsibility.
• Incentivise success. Financially or otherwise, tie their reward to the project landing well. Success can lift their careers significantly.
• Listen to them. They know where the old system's edge cases are buried. Use that knowledge in design and testing.
• Show them what's possible. Better analytics, AI, scalability, a modern experience for operators. Things they could never have built alone.

Treat them as partners rather than obstacles and they become your most powerful advocates. But don't let anyone sabotage the project from within. That's a leadership responsibility.

The "replicate everything" mentality

Because the homegrown system was built specifically for your operations, people expect the replacement to mirror every feature and quirk.

That creates unrealistic expectations. If leadership doesn't manage it, customisation creeps up and timelines stretch.

The 95% problem

The new system might handle 95% of requirements brilliantly. That missing 5% becomes the focus of all the criticism.

Strong voices fixate on what's different, rather than the big improvements: a better data model, better user experience, better reporting, AI capabilities and far more configurability. The advantages get lost in debates about recreating legacy behaviour.

Hidden complexity

Homegrown systems are full of undocumented workarounds, manual steps around the edges and tribal knowledge. They only surface during implementation, usually at the worst moment.

Spend time upfront mapping what the system really does, and what people do around it. Your developers are invaluable here.

Resistance to change

Users get attached to familiar workflows, even inefficient ones. Any change can feel like a step backwards rather than an opportunity.

That's normal. Plan for it. I cover how in Resistance to change is guaranteed.

The goal isn't to rebuild what you had

Your homegrown application is being replaced for a reason. It's time to move forward.

Replicating the old system inside the new platform isn't a path to success. It wastes the investment in modern capabilities and creates customisation you'll pay for at every upgrade.

Strong leadership keeps the project on track: minimise customisation, adopt industry best practice, and focus the team on the new system's strengths rather than recreating old limitations.

What's been your biggest surprise when replacing a homegrown system?

Where should it all live? It depends what you want to do with it, so let's go through the main options.

Historians

Historians are databases built for time-series data at very high volume: machine signals, process variables, sensor readings, often every second or faster.

They've been part of manufacturing IT for decades and they're still widely used, especially by engineers for troubleshooting and long-term trending. "What was the oven temperature doing in the two hours before that batch failed?"

MES/MOM also reads time-series values from the machines, usually over OPC UA, and adds the context: which order, material and machine each value belongs to. It isn't designed to hold the same volume of data as a historian, or to capture it at the same frequency. But for most manufacturers, what MES/MOM captures is absolutely fine, and it removes the need for a separate historian. Only in rare cases do you need both. More in Historian vs MES.

Data warehouses

Structured databases optimised for reporting. They pull data from MES/MOM, ERP, quality and other systems, and organise it for business intelligence tools.

Best for well-structured, aggregated data that answers known questions: output by site by month, scrap cost by product family.

Data lakes

Large stores of raw, unstructured or semi-structured data. Anything can go in: machine data from historians, transactions from MES/MOM and ERP, IIoT streams, logs, images.

Data lakes are often the raw material for advanced analytics and machine learning. The risk is obvious: without structure and context, a lake becomes a swamp.

Data fabric and data mesh

More recent architectural ideas. Rather than physically copying everything into one place, they focus on making data discoverable and usable across the enterprise wherever it lives.

It weaves data together rather than moving it all. Useful in large organisations with many systems and sites.

How it typically fits together

A common pattern in mature factories:

1. MES/MOM captures operational events and gives them context: order, material, machine, shift, reason, result.
2. A historian, in the rare cases it's needed, keeps very high-frequency machine data.
3. A data platform (lake, warehouse or fabric) brings MES/MOM, ERP and other data together for analytics and AI.

The lines between these categories are blurring, and vendors increasingly offer platforms that cover more of the stack. But the roles stay roughly the same.

Which layer does AI read from?

AI can pull data from anywhere. It can look across MES/MOM, ERP, a data lake or a data fabric, and combine what it finds. That's one of its real strengths.

But to add value, AI needs to understand the data model: what each piece of data means, and how it relates to the rest. The context that makes the data valuable is created upstream, at the point of work, by MES/MOM. A data lake full of uncontextualised machine signals won't give a model much to learn from. One that includes which order, which material and which shift was involved, linked to quality outcomes and maintenance history, will.

To go further and actually execute transactions, such as raising a maintenance request or putting a lot on hold, AI also needs to understand what it can do with that data model. That's where MCP comes in. I explain it in Agentic AI and MCP.

I explain why in Raw machine data is worthless.

Build the data and the platform together

I've seen manufacturers build impressive data platforms before they have reliable data to put in them. The lake fills up. Nobody trusts what's in it. The data science team spends most of its time cleaning.

Don't do one and then the other. Capture accurate, contextualised data on the shopfloor and build the platform at the same time, so the data foundation is there and ready for the technology.

Where does most of your shopfloor data live today?

You've spent months planning, configuring, testing and training. The system goes live. Everyone breathes a sigh of relief.

But go-live is the starting line. What happens next decides whether MES/MOM delivers the value in the business case, or quietly becomes an expensive way to print labels.

The first few weeks: hypercare

The weeks straight after go-live are critical. Problems will surface. They always do.

An edge case nobody tested. A process that works differently on the night shift. An integration that behaves unexpectedly under real production load.

Plan for it:

• Extra support on the floor, on every shift, not just days
• Super users visible and available, with time freed up to help
• A fast route for issues, with someone deciding priorities daily
• Daily reviews of what went wrong and what's been fixed
• Leaders on the shopfloor, seeing it for themselves and showing the teams this is a priority

The goal is to fix things fast enough that people keep trusting the system. Lose that trust in the first month and adoption is very hard to win back.

Measure what you promised

Go back to the business case. What did you say would improve? Scrap, downtime, OEE, batch release time, traceability?

Measure it from day one, against the baseline you set before the project. Share the results, good and bad. That evidence is what keeps leadership committed, and the rollout on track.

Celebrate the quick wins

When an operator sees their own downtime data for the first time, or a quality manager traces a batch in seconds instead of hours, that's when adoption accelerates.

Make those moments visible. They build momentum, and momentum is what carries a project from the first site to an enterprise standard.

Then keep improving

There's no point at which you declare victory and say "we're done". Smart manufacturing isn't a project with an end date. It's a way of operating.

Continuous improvement becomes the rhythm: small changes, driven by data, involving everyone from the shopfloor to the boardroom. Plan, do, check, act, and round again.

The difference now is the data. Before, improvement was often based on gut feel and anecdotes. Now it's based on accurate, real-time, contextualised information. I cover how in Kaizen and MES.

Keep the system evolving

Successful manufacturers don't implement MES/MOM and stand still. They:

• Review configuration regularly as processes change
• Extend scope into new pillars and new sites
• Explore new capabilities as the product evolves, including AI
• Keep a small, permanent team that owns the system and its roadmap

Your competitors are investing in smart manufacturing. It's not enough to implement a project and stop. You need to keep evolving.

What happened in the first month after your last go-live?

But it's usually sold as a technology you switch on. It isn't. It's the end of a journey, and most factories are still near the start.

Three ways to maintain equipment

Reactive. Fix it when it breaks. For critical equipment, the most expensive approach by a distance: unplanned downtime, emergency repairs, knock-on damage, missed deliveries.

Preventive. Maintain on a schedule, by time or cycle count. Better. But schedules are blunt. Sometimes you maintain too early and waste parts and labour. Sometimes too late, and it breaks anyway.

Condition-based and predictive. Maintain based on the actual condition of the equipment. Vibration, temperature, current draw, pressure, cycle counts. Predictive goes a step further and uses those patterns to forecast a failure before it happens.

That last one is the goal. But you can't jump to it.

Why downtime is where it starts

Downtime is usually the biggest loss when you look at OEE. For most manufacturers, it's the single largest area for improvement.

Before you can predict failures, you need to know your failures. Accurately. Which machine, how long, how often, for what reason, during which order.

Most factories don't have that yet. Downtime is recorded at the end of the shift, from memory, with a reason code chosen from a list that's too long or too vague. Short stops aren't recorded at all.

Get that right first. Automatic stop detection from the equipment, with operators adding the reason while it's fresh. It's not glamorous, but it's the foundation everything else stands on.

What the models need

Predictive maintenance models learn the patterns that come before a failure. That means collecting the right data, over time:

• Condition data. The sensor readings that change as a component degrades. You may need new sensors for this, so start with your bottleneck assets.
• Failure history. When things actually failed, and why. Without it, the model has nothing to learn from.
• Maintenance actions. What was actually done each time: the part replaced, the adjustment made. Otherwise the model can't tell a repaired machine from a degrading one.
• Operating context. What the machine was doing at the time: which product, which speed, which material. A spike in temperature during a heavy product run means something different from the same spike on a light one.

Condition data and failure history are often in separate places. Operating context usually only exists in MES/MOM. That's why I'm wary of predictive maintenance projects that sit in a silo, disconnected from what production was doing.

Production and maintenance on the same data

This is a point I come back to often.

Production and maintenance both care about downtime. If production records stops in one system and maintenance works from another, they'll disagree about what happened. The morning meeting turns into an argument rather than a plan.

When maintenance lives in the same platform as production, both teams see the same stops, the same reasons and the same equipment history. Repair windows can be planned around the schedule. And the data that predictive models need is already joined up.

I cover how maintenance fits into MES/MOM in MES functionality: maintenance.

Don't forget the operator

Asset care is increasingly the operator's job too. Autonomous maintenance: cleaning, lubrication, visual checks, tightening, spotting early signs of wear.

Operators often notice problems long before a sensor does. A new noise. A different smell. A machine that "doesn't feel right". Give them a quick, easy way to log it from the screen they already use, and you add a source of early warning no model can replicate.

Start small

You don't need sensors on every machine on day one.

1. Get accurate downtime data, automatically, on your bottleneck assets.
2. Move maintenance into the same system as production, so everyone sees the same picture.
3. Add condition sensors where the cost of failure is highest.
4. Collect failure history consistently. Anomaly detection can start on the condition data straight away, while the failure history builds up for a predictive model.
5. Then pilot a predictive model on one asset type, and measure the result.

Every step pays back on its own. And by the time you reach step five, you'll have the data a model actually needs.

Which asset in your factory would you most like to see failing a week before it does?

1. Connecting ERP directly to machines

This is a huge no-no.

ERP is the backbone of the business, and it does that job well. It isn't designed for real-time communication with shopfloor equipment. It doesn't have the data model, the transaction speed or the user interface for it. It needs aggregated data at a sensible frequency, not raw signals from a PLC.

People who try it end up with custom interfaces between ERP and the equipment. They're expensive to maintain and add work to every ERP upgrade, because ERP was never meant to handle machine signals.

MES/MOM exists precisely to sit between ERP and the shopfloor. Use it. And if it isn't in place yet, buffer the machine data in a connectivity layer you can later feed into MES/MOM, not ERP.

2. Underestimating what it takes to code your own

Building your own can be an OK option in some cases, usually for smaller companies with a narrow scope and the right expertise. Coding an entire MES/MOM platform from scratch is a much bigger commitment than it looks.

Homegrown systems start small. Someone builds a database, adds some screens, connects a couple of machines. It works, for a while. A system of any real scale takes years to build well, and the gaps are easy to miss: user experience, industry best practice, standard KPIs such as ISO 22400, and integrations.

Then requirements grow. The person who built it becomes the single point of failure, and eventually they leave. Every upgrade and every new capability is yours to build. I cover replacing these systems in Replacing a homegrown MES.

3. Buying point solutions with no destination in mind

Plenty of projects start with something small to fill a gap: an OEE tool, a checklist app, a standalone quality system, an energy dashboard.

It solves the immediate problem. Then requirements grow. You need quality connected to production, inventory connected to quality, maintenance connected to downtime. The point solution can't do it.

Now you're either replacing it, or adding more tools and connecting them. Stitching best-of-breed applications together can work, but every boundary is an interface to own and some context is lost at each one. It's fine to start small, but start small on the right path, with the destination in mind. Whichever route you take, know how it grows, and what connecting the pieces will cost. I compare the options in Code, build, stitch or configure.

4. Over-customising

The more custom work you do, the bigger the budget you need now and later. Custom code needs maintaining and retesting with every upgrade. And it often means you've encoded a bad process into software instead of fixing it.

Configure, don't customise. More in Configure, don't customise.

5. A lightweight connected worker platform that collides with MES/MOM

Connected worker platforms are everywhere. They solve real problems: checklists, tasks, shift handover, skills.

But operators don't just manage checklists. They run production orders, perform inspections, consume material and do autonomous maintenance. A standalone connected worker tool doesn't cover those on its own. So you add MES/MOM later, and now operators use two systems and the data is split, unless you plan how they connect.

MES/MOM with connected worker built in gives you similar quick wins on one platform. If you go standalone, decide up front how it will connect to everything else. More in Connected worker: one app, not five.

6. Treating IIoT as a replacement for MES/MOM

IIoT is trendier, and IoT platforms are the right choice in some cases. But they're the connectivity layer, not operational management. If you need MES functionality, you need an MES.

I've seen manufacturers connect hundreds of sensors and build beautiful dashboards, then realise they still can't manage a production order, track an inspection or trace a lot. IIoT feeds MES/MOM. It doesn't replace it. See IIoT doesn't replace MES.

The common thread

Every one of these mistakes comes from solving today's problem without thinking about where you're heading. The quick fix that looks cheap and turns out expensive.

Before any technology decision, ask: will this still be the right choice when we're three times bigger and want production, quality, inventory and maintenance on the same data?

Which of these six have you seen up close?

It's accurate on the day it's updated. It's checked during audits. And it has absolutely no influence on who actually runs which machine at 3am on a Sunday.

Skills management is a process

It's easy to think of skills as an HR record. It isn't. It's an operational control.

Who is qualified to run this machine? To set up this tool? To release this batch? To perform this inspection? Whose certification has expired? Who needs retraining because the procedure changed last week?

If that isn't managed, you get unqualified people running processes they shouldn't. Not because anyone is careless, but because the supervisor is short-staffed and the spreadsheet isn't in front of them.

Recording is not enforcing

There's a big difference between a system that records skills and one that enforces them.

Recording tells you, after the fact, that someone without the right qualification ran the order. Useful for an audit. Too late for the product.

Enforcing stops it happening. The operator logs in at the machine. The system checks their qualifications against what the order and operation require. If they're not qualified, they can't start it, and the supervisor gets told why.

That's the shift from a report to a control.

What good looks like

• Skills defined against the work. Not just "trained on Line 3", but qualified for specific operations, equipment and products.
• Expiry dates that mean something. Certifications lapse automatically and the person is flagged before it happens, not after.
• Procedure changes trigger retraining. When a work instruction is revised, the people qualified on the old version need to acknowledge the new one.
• Checks at the point of work. At login, at order start, at a critical step. Not in a monthly report.
• A clear path to qualify. Training tasks, sign-off by a qualified person, and a record of who signed off whom.

Why it matters more now

The workforce problem makes this urgent.

Experienced operators are retiring. New starters arrive with less background and stay for less time. More temporary and agency workers fill gaps. Every one of those trends increases the risk that someone ends up on a task they aren't ready for.

Good skills enforcement doesn't just protect quality. It gives new starters confidence. They know the system will guide them and stop them before they make a serious mistake, and that makes them productive faster.

In regulated industries it goes further. You often have to prove that only qualified people performed critical steps. Doing that from a spreadsheet after the event is painful. Doing it from a system that enforced it at the time is straightforward.

Why it belongs inside MES/MOM

A standalone skills tool can hold a beautiful matrix. But it can't stop someone starting an order, because it doesn't know an order is being started.

Enforcement needs the operational context: which order, which operation, which machine, which material. That lives in MES/MOM. Put skills in the same platform and the check happens naturally, at the moment it matters.

It's another example of why connected worker capabilities belong inside the operational platform. I make the wider case in Connected worker: one app, not five.

A simple test

Ask your supervisors one question: if an unqualified operator tried to start an order on your most critical machine tonight, what would stop them?

If the answer is "the supervisor would notice", you're relying on heroics. And heroics don't scale.

How is your skills matrix managed today, and when was it last updated?

OPC UA in one paragraph

OPC UA (Open Platform Communications Unified Architecture) is the industry standard for machine-to-system communication. It's vendor-neutral and platform-independent. Its big strength is the information model: a tag doesn't just carry a value, it carries meaning. This is a temperature, on this machine, in degrees Celsius. Security is built in. The classic pattern is client and server, where a system connects to a machine and reads what it needs, and the standard also defines a publish-subscribe mode.

MQTT in one paragraph

MQTT is a lightweight messaging protocol. Devices and systems publish messages to a central broker, and anything interested subscribes. Nobody polls anybody. It's light and copes well with unreliable networks, which is why it's popular for IIoT and edge devices. On its own, MQTT doesn't say what a message means. Sparkplug B adds that, with a defined payload format and a way to track whether each device is online.

Side by side

Where each one fits

OPC UA is usually the first hop. Many machines and PLCs speak it natively, and gateways translate older protocols into it. If you want to read structured data from a machine with its meaning intact, OPC UA is the natural choice.

MQTT can be the distribution layer. Once data is collected, MQTT moves it efficiently to everyone who needs it: MES/MOM, a historian, a data platform, an analytics tool. Many systems subscribe without each one connecting to every machine.

Both can be used in the same factory. Pick the right one for each job, rather than assuming you need both.

Where UNS comes in

A unified namespace is an architecture, usually built on an MQTT broker. It's a real-time view of whatever operational data connected applications have published to it, organised by the plant hierarchy: enterprise, site, area, line, machine.

It carries real risks. The sender gets no confirmation that the data arrived or was processed, so data can fail to reach the systems it's meant for without anyone noticing. It keeps no history, and without strict governance it quickly becomes a very big pile of tags with no context. Direct interfaces, which confirm each message, are often the safer choice. More in OPC UA, MQTT and UNS in plain English.

And MES/MOM?

Connectivity moves data. MES/MOM gives it meaning.

A broker can tell you a machine changed state. MES/MOM knows which order was running, which material, which shift, and that the operator entered the reason as a jam. Where a UNS is used, MES/MOM can consume machine data from it and publish contextualised data to it. More in Raw machine data is worthless.

Questions to ask vendors

• Which protocols do your machines and PLCs support natively?
• Does the MES/MOM connect to OPC UA servers directly, subscribe to an MQTT broker, or both?
• Can it publish its own contextualised events to a broker?
• If you use MQTT, which payload convention: Sparkplug B or something custom?
• How is security handled at each hop?

My view

I don't think it's a contest. They solve different problems. OPC UA brings meaning and security at the machine. MQTT moves data efficiently to many consumers. Both can sit in the same factory, so pick the one that fits each job.

Which camp are you in, and why?

Manufacturers publish ESG reports full of ambitious goals. Lower energy, less waste, smaller carbon footprint. Meanwhile, many of their shopfloors run exactly as they did five years ago, with no visibility and no data to improve from.

We already have the technology to optimise resource consumption, cut waste in real time and monitor energy across operations. Most manufacturers just aren't using it to feed their sustainability reporting.

Why it doesn't happen

Because it requires commitment.

It means challenging existing processes, investing time and budget upfront, and following through on what the sustainability report promised. That's uncomfortable. It's much easier to publish the goal than to instrument the factory.

But you can't manage what you can't measure. And most factories can't measure what matters for ESG at the level of detail that would let them improve it.

What ESG actually needs from the shopfloor

Sustainability reporting is increasingly regulated in more regions, and auditors want evidence, not estimates. Much of that evidence originates on the shopfloor:

• Energy per machine, per order, per product. Not just a monthly meter reading for the site.
• Idle consumption. What machines draw when they aren't producing anything. Often a surprise.
• Scrap and waste. How much, where, why, and of which material.
• Yield. Raw material in versus good product out. In food and process industries, often the biggest lever of all.
• Water and other utilities, where they matter to your process.

Every one of those is a production metric as much as a sustainability one.

Sustainability and profit are the same conversation

Cutting scrap reduces waste and cost. Reducing idle energy lowers emissions and the energy bill. Improving yield uses fewer raw materials and improves margin.

When you frame ESG as a compliance exercise, it competes for budget. When you see it as operational efficiency with a reporting benefit, it pays for itself.

Where the data comes from

MES/MOM already knows what's being produced, on which machine, for which order, and how much was scrapped. Add energy monitoring at the machine level, and you can attribute consumption to the products that caused it. Energy per piece. Carbon per order. Waste per product line.

That context is what turns a utility meter into actionable data. Without it, you know the site used more energy this month. With it, you know Line 3 runs its ovens for two hours before the first order starts on Mondays.

I cover energy as part of MES/MOM in MES functionality: energy.

Beyond energy monitoring

There's a growing set of tools for carbon accounting, emissions tracking across scopes 1, 2 and 3, water and waste management, and product-level sustainability reporting. They're useful. But they all need operational data to be accurate, and most of them get it from MES/MOM and energy management systems.

Buy the reporting tool before you've instrumented the factory, and you'll be reporting estimates very efficiently.

Where to start

1. Pick your biggest energy consumers and meter them at the machine level.
2. Link that consumption to production orders in MES/MOM.
3. Make scrap and yield visible by line, shift and product.
4. Look for the obvious wins first: idle running, warm-up times, compressed air leaks, scrap hotspots.
5. Then connect the data to your sustainability reporting.

You'll probably find the first few improvements pay for the metering.

So, are you using MES/MOM, or any system, to drive measurable sustainability improvements? Or is it still mostly in the report?

This article sets out how the two compare.

What each one means

On-premises means you run the MES/MOM software on servers you own or rent, either in the factory or in your own data centre. Your team, or a partner, looks after the servers, databases, backups and upgrades.

Cloud means the software runs on a cloud platform, usually delivered by the vendor as software as a service (SaaS). The vendor runs the infrastructure and keeps the application up to date. Most cloud MES/MOM also includes an edge component at each site, close to the machines.

Most "on-premises" MES isn't on the premises

One point often gets missed. When MES/MOM serves several sites from one instance, it usually sits in a central data centre. Every site except perhaps one already reaches it over a wide-area network or the internet.

So the dependency on connectivity that people associate with cloud often exists already. The real difference is who runs the infrastructure, and how the system is kept up to date.

Side by side

What cloud brings

Security. Major cloud platforms invest in security at a scale few manufacturers can match: continuous monitoring and rapid patching, backed by independent certifications. Patches are applied as standard rather than waiting for a maintenance window.

Scalability. Adding a new site or line is mostly configuration, with no servers to buy. Capacity can grow as data volumes climb with machine connectivity and AI.

Staying current. Updates arrive regularly and in small steps, so there's no large upgrade project every few years. On-premises customers often put those upgrades off, and fall behind.

Access to new capabilities. New features, including AI and analytics, reach customers as they're released.

Less infrastructure to run. The vendor looks after servers, databases, backups and disaster recovery. Your team can spend that time on processes and improvement.

Resilience. Cloud platforms offer redundancy across data centres, which would be expensive to build yourself.

What on-premises brings

Full control over timing. You decide exactly when changes happen, which some regulated sites value. If you've recently invested in data centre capacity and skills, on-premises also makes use of them.

Working without connectivity. A site with no reliable connection, or an air-gapped environment in defence and some critical infrastructure, may need everything on site. But honestly, very few manufacturers actually operate this way.

Handling the common concerns about cloud

Connectivity and latency. Internet connectivity is now close to as reliable as power for most sites, and a central on-premises instance depends on the network in the same way. Real-time machine connectivity sits at the edge, close to the equipment, so latency isn't an issue there. The cloud handles the operational application and analytics.

Data residency and regulation. Cloud regions let you keep data in the country or region you need, though some data residency requirements, and some aerospace and defence programmes, still call for your own data centre. In regulated industries, look for vendors with a validated cloud approach and clear documentation for quality and compliance teams.

Questions to ask a cloud MES vendor

• How often is the platform patched?
• How often are updates released, and can we test them before they reach production?
• Which regions can our data be held in?

Licensing

On-premises can be licensed perpetually or by subscription. Cloud is usually a SaaS subscription, with the hosting cost included. Compare the total cost over the life of the system, including infrastructure and the upgrade projects each model involves.

My view

I think cloud is now the right default for most manufacturers. If your MES/MOM already runs in a central data centre, you carry the network dependency without the security and scalability benefits the cloud adds. Subscription licensing also gives vendors the predictable revenue to keep investing in a product you'll rely on for a decade or more.

On-premises still has a place where connectivity really isn't available. Some aerospace and defence programmes, and some data residency rules, also call for your own data centre. For everyone else, I'd want a good reason not to choose cloud.

If your MES/MOM already runs in a central data centre, what's keeping it out of the cloud?

That's the connectivity layer. And it's surrounded by acronyms and strong opinions. I won't go down every rabbit hole, but you need enough to have a sensible conversation.

OPC UA

OPC stands for Open Platform Communications. OPC UA (Unified Architecture) is the modern version and the industry standard for machine-to-system communication.

What makes it useful:

• It's platform-independent and vendor-neutral, so equipment from different manufacturers can be read in a consistent way.
• It doesn't just carry values. It carries structure and meaning: this tag is a temperature, on this machine, in these units. And it has security built in.

If there's one connectivity standard to know, it's this one. Many machines and PLCs support it directly, and gateways can translate older protocols into it.

MQTT

MQTT is a lightweight messaging protocol. Instead of a system asking each machine for data, devices publish messages to a central broker, and any system that's interested subscribes to them.

It's simple, efficient and works well over unreliable networks, which is why it's popular for IIoT and edge devices. On its own, MQTT doesn't define what the data means. Extensions such as Sparkplug add that structure.

OPC UA and MQTT aren't really competitors. Both can be used in the same factory, so pick the right one for each job.

Unified namespace (UNS)

A unified namespace is an architectural pattern rather than a product. It's a real-time view of whatever operational data connected applications have published to it, usually through an MQTT broker, organised by the plant hierarchy: enterprise, site, area, line, machine.

Systems publish what they know, and others can subscribe. It's one integration option, alongside point-to-point interfaces, which give the sender a response, and integration through ERP.

It's worth being clear about its limitations:

• No confirmation for the sender. Data is published, and the publisher doesn't know whether the system that needed it received or processed it. Errors as data moves between platforms aren't visible.
• Data can fail to arrive where it's meant to be. Without that confirmation, a missed production confirmation or stock movement can go unnoticed until someone finds the numbers don't match.
• No history by default. It shows what's happening right now. On its own it doesn't keep the history, and it doesn't add the meaning. You still need applications around it to do that.
• It can get messy quickly. It needs a strict structure, strong governance of who publishes what, and a broker to run and secure.
• Fewer point-to-point interfaces isn't always better. For transactions between systems, a point-to-point interface with a confirmed response is often the safest option.

OEE is a good example of the history point. You can publish the current OEE to a UNS, but you can't aggregate OEE figures by order or shift. For that you have to go back to the raw data, stored somewhere that keeps it.

So a UNS can be used to share real-time data with systems that only need the latest value. For anything that must arrive, such as orders, consumption or quality status, use an integration that confirms it did.

Where MES/MOM fits

Connectivity moves data. MES/MOM gives it meaning.

A UNS can tell you a machine's state changed. MES/MOM knows which order was running, which material, which shift, and that the operator just entered the reason as a jam. That contextualised data is often exactly what other systems want to subscribe to.

Where a UNS is used, MES/MOM can consume machine data from it and publish contextualised operational data to it. More on why that context matters in Raw machine data is worthless.

A few practical rules

• Don't connect ERP directly to machines. ERP needs aggregated data at sensible intervals, not raw machine signals.
• Start with what you'll use. Connect bottleneck assets and the signals you need for counts, states and key parameters first.
• Agree a naming standard early. Asset hierarchies and tag names are dull, and they decide whether the data is usable later.
• Treat OT security as part of the design. Not an afterthought once everything's connected.

What to ask vendors

• Which protocols do you support natively: OPC UA, MQTT, others?
• Can you consume and publish to a unified namespace?
• How do you handle older equipment without modern interfaces?
• How are connections configured: by your team through configuration, or through custom development?

How connected is your shopfloor today, and how much of that data has context?

Usually it's a quick chat at the door. Maybe a few lines in a logbook, or a note on the whiteboard. The outgoing supervisor is tired and wants to go home. The incoming one is trying to take in five things at once.

Details get lost. And the new crew starts the shift partly blind.

What a handover needs to answer

A good handover answers a short list of questions, every time:

• What's running, and how is it going against plan?
• What were the big stops, why, and are they fixed?
• What's waiting: orders, material, quality results, maintenance work?
• Are there any quality issues or holds the next shift needs to know about?
• Any safety concerns?
• What's coming up that needs preparation: changeovers, trials, new products?

None of that is complicated. The problem is that most of it lives in different places, and in people's heads.

Why verbal handovers fail

Memory is selective. People remember the dramatic breakdown and forget the material shortage that will stop the line in two hours.

Handovers also vary by person. One supervisor gives a thorough brief. Another says "all good" and leaves. On paper, both shifts handed over.

And nothing is recorded in a way anyone can search later. When a customer complaint arrives three weeks on, nobody can find out what was said at the 10pm handover on the 4th.

Build the handover from real data

This is where a digital handover changes things. Instead of relying on memory, start from what actually happened.

That doesn't mean replaying every detail of the shift. The system holds all of that if anyone needs it. A good handover surfaces the insights, the exceptions and the escalations, the things the next crew needs to act on:

• Performance against plan, and any orders that fell behind
• Insight into downtime: the biggest losses, repeat stops and anything still unresolved
• Quality exceptions: failed or outstanding checks, and anything on hold
• Material shortages that will hit the next shift
• Escalations, and open maintenance requests on the line's equipment

If your MES/MOM is capturing the shift, the data behind all of this already exists. The handover becomes a summary generated from it, highlighting what matters, which the outgoing supervisor reviews and adds to.

The supervisor's job changes from remembering everything to adding the things only a person knows. "The new operator on Line 2 needs keeping an eye on." "That noise on the filler is back."

Make it structured, not just digital

A free-text box on a screen is barely better than a logbook. Structure is what makes handover consistent:

• The same sections every time, so nothing gets skipped
• Required sign-off from both the outgoing and the incoming supervisor
• Open actions carried forward until someone closes them
• Links straight to the order, stop or inspection being discussed

"See the stop at 02:14 on Line 3" is far more useful when the incoming supervisor can tap it and see the detail.

Why it belongs inside MES/MOM

You can buy standalone handover tools. They're better than paper. But they don't know what happened on the shift unless someone types it in again.

When handover is part of the same platform as production, quality and maintenance, it's informed by real operational data rather than a standalone form. That's the theme of Connected worker: one app, not five. One system, one source of truth, no re-keying.

Where AI fits

Generative AI is genuinely useful here. Give it the shift's data and it can draft a clear summary of what matters in seconds, pulling out the exceptions rather than listing everything. The supervisor checks and edits it rather than writing it from scratch.

It's a good first AI use case: frequent, time-consuming, low-risk if a person reviews it, and easy to measure. More examples in Practical GenAI for the shopfloor.

Start this week

You don't need new software to improve handover tomorrow. Agree the six questions above. Use them every shift. Make both supervisors sign it.

Then, when you're ready, make the system fill in most of the answers for you.

How does handover work in your factory today, and when did it last go wrong?

They focus on features and functionality, which matter, but give the human element far less attention. But your MES/MOM is only as effective as your organisation's willingness to change.

You need good technology, and choosing the right platform matters. But even the best platform can be held back by poor processes and low adoption. You can connect every machine and integrate with ERP, and still fail.

Every project meets resistance

In my experience, every project meets at least some push back. If someone tells you their project met no resistance, they either weren't paying attention or they're not being honest.

People resist change not because they're difficult or don't care, but because change is uncomfortable. It disrupts routines and challenges expertise.

For someone who's done their job well for fifteen years, being told "we're changing how you work" can feel like being told they've been doing it wrong.

Why good projects struggle

Even technically strong implementations can struggle when:

• Leadership didn't communicate the vision clearly
• Shopfloor teams weren't brought along on the journey
• Change management was an afterthought
• Internal expertise wasn't developed or kept

What leadership has to do

Successful transformation is impossible without strong leadership buy-in. Leaders need to:

1. Set the vision. Where we're heading, and why. Communicated clearly and often.
2. Back the change management. Resistance is the status quo. Get this wrong and the project fails.
3. Build a strong team. The right people at every level, cross-functional and properly supported. More in Building the right team.
4. Invest in resources. Find the knowledge and skills gaps. Upskill where you can, and hire where you can't. Put critical people in positions of ownership and accountability, and make them responsible for the outcome.
5. Bring the detractors inside. Find the people most likely to resist, particularly those who built the homegrown system being replaced. Give them responsibility, and incentivise them to make the new system a success.

If digital transformation is a business priority, give it the support and attention a business priority deserves.

Bigger programmes meet less resistance

It sounds backwards, but a programme to implement MES/MOM across the whole landscape usually meets less resistance than a small one. It gets more leadership attention and more visibility, so it gets more support internally. The executives have already bought in, and the expectation is clear: people implement it and get on board.

A departmental application or a small pilot sends a different message. It looks as though the decision could still be reversed, and that's often where the most resistance comes from. It isn't a done deal, so people think they can influence it.

Involve people early

Bring operators, supervisors, quality and maintenance into the design, not just the training.

They know the process better than anyone, including the workarounds. Their input makes the system better. And people support what they helped create.

Explain the why

People need to understand not just how to use the new system, but why it's better for them. Less paperwork. Fewer arguments about numbers. Clearer instructions. Less time chasing information.

If the only message is "management wants more data", expect resistance. If the message is "this makes your shift easier", you'll get help.

Invest in adoption, not just implementation

Implementation ends at go-live. Adoption should have started before go-live, but it certainly doesn't end there.

• Super users on every shift, trained early and given time to support others
• Quick wins made visible, like an operator seeing their own downtime data for the first time
• Feedback channels that actually lead to changes
• Leaders on the shopfloor, visible and showing support

Ask yourself honestly: do we have the internal capability to make this work? Have we prepared our people? Are we ready to invest in adoption, not just implementation?

Much of the difference between success and failure is the culture you build around the system.

What's been your experience of change on the shopfloor?

You know the site used more energy this month. You don't know why.

What energy monitoring in MES/MOM covers

• Consumption by machine and line, from meters or directly from the equipment.
• Consumption by order and product, by linking energy to what was being produced at the time.
• Idle consumption: what machines draw when they're on but not producing.
• Energy per piece or per kilogram, so you can compare products, lines and sites fairly.
• Alerts when consumption moves outside expected limits.

Context is what makes it useful

An energy meter on its own tells you how much was used. That's helpful, but it doesn't tell you what to do.

The value comes when energy is linked to operational context, which is exactly what MES/MOM has. Which order was running. Which product. Which shift. Whether the machine was producing, idle, in changeover or stopped.

Now you can answer useful questions:

• Which products cost the most energy to make, per unit?
• How much do we spend running machines that aren't producing anything?
• Why does Line 3 use 15% more energy per piece than Line 2 for the same product?
• What's our energy cost per order, for pricing and costing?

The usual quick wins

When manufacturers first see energy in context, the same things tend to show up:

• Ovens, compressors and heaters left running between orders or over weekends
• Long warm-up times before the first order of the week
• Compressed air leaks running 24 hours a day
• Older equipment using far more than newer equipment for the same output

None of these need new technology to fix. They need visibility.

Energy and sustainability reporting

Sustainability reporting increasingly needs evidence rather than estimates, and much of that evidence starts on the shopfloor. Energy per product, linked to production data, is the foundation for product-level carbon reporting.

I make the wider case in You can't hit ESG targets without shopfloor data.

Start with the big consumers

You don't need to meter everything. Start with your largest energy users and your bottleneck lines, link them to production data, and look for the obvious waste first. In my experience, the first improvements can often pay for the metering.

This article is part of the MES functionality in depth learning path.

Do you know which of your products is the most energy-intensive to make?

Here are four uses I think are practical today.

1. Asking questions in plain English

Most operational data sits behind reports someone has to build, filter and export. GenAI lets people ask for what they need directly.

"Write a one-page report for my continuous improvement manager explaining OEE trends on Line 4 over the last 12 months, highlighting anything that could have affected the results."

That report used to take an engineer half a day. Now it's a first draft in seconds, which the engineer reviews and sharpens.

The time saved isn't the main win, though. It's that people ask questions they'd never have bothered to raise before, because getting the answer was too much effort.

2. Helping configure systems

Configuring shopfloor software is detailed work: equipment, materials, routings, reason codes, inspection plans. It's also where a lot of implementation time goes.

"Configure a new packing line in the packing department. Ask me any questions you need to complete the setup."

GenAI can walk someone through a setup conversationally, fill in the obvious parts and ask about the rest. It doesn't remove the need to understand your processes. It makes the mechanical part faster, and it lowers the bar for people who aren't system experts.

3. A knowledge assistant on every screen

Operators and engineers have questions all day:

"What's the calculation for Cpk?" "What is this screen showing me?" "What's the changeover procedure for product X on this machine?"

A GenAI assistant that knows your procedures, specifications and the system itself answers in seconds, at the point of work. For new starters that's huge. It means they're not interrupting the one experienced person on shift every ten minutes.

4. Shift summaries and handover

Shift handover is usually verbal, or a few lines in a log. Detail gets lost and the incoming crew starts partly blind.

GenAI can write the handover from what actually happened: which orders ran, where the stops were, which quality checks are outstanding, what's waiting. The outgoing supervisor reviews it and adds the things only a person knows. I cover handover in more depth in Shift handover is a process.

The condition that decides how much this delivers

Every one of these depends on the same thing: the AI has to have access to good, contextualised operational data.

A report on OEE trends is only as accurate as the downtime data behind it. A shift summary is only useful if the shift's activity was captured in a system, not on paper. A knowledge assistant needs current procedures, not the version from three years ago on a shared drive.

The good news is that you don't have to wait for perfect data to start. A knowledge assistant works on the documents you have today, as long as you point it at the current versions. GenAI can read and structure messy history too, such as free-text maintenance notes or scanned logbooks, which makes your data better rather than waiting for it. The shift summaries and the questions about live performance are where the operational data foundation really matters.

That's why GenAI built into, or connected to, your MES/MOM is far more useful than a general chatbot. It has the context: which order, which line, which material, which shift.

A word of caution

GenAI generates plausible text. Plausible is not the same as correct.

Be wary of letting it make decisions on its own in a production environment. Use it to draft, summarise, explain and assist, with a person reviewing anything that matters. And make sure answers can be traced back to the data they came from, so people can check them.

Start where a wrong answer is cheap, like a first-draft report, and build trust from there.

Where to start

Pick the task your engineers or supervisors complain about most. The weekly report. The handover. The questions new starters keep asking.

That's usually the best first use case: frequent, time-consuming, low-risk, and easy to measure.

Which of the four would save your team the most time?

Neither side is wrong. They're optimising for different things.

Let's align on some terminology

IT (information technology) is the world of business systems: ERP, email, office applications, data centres and the cloud. It manages information.

OT (operational technology) is the hardware and software that monitors and controls physical equipment: PLCs, SCADA, DCS, sensors, drives and the machines themselves. It manages physical processes.

In ISA-95 terms, OT lives at levels 0 to 2 and IT at level 4. Level 3, manufacturing operations, sits between them. That's where MES/MOM lives.

Side by side

Why they think differently

The cost of getting it wrong. If an office server reboots unexpectedly, people grumble. If a controller reboots mid-batch, you might scrap the batch or damage the equipment. OT engineers are cautious for good reason.

Age. Some controllers on a shopfloor run operating systems that went out of support a decade ago, and they'll stay in service for another decade because the machine they control still works perfectly. IT's instinct to upgrade everything on a schedule doesn't fit.

Timing. Most IT systems are happy with a response in a second or two. A control loop may need an answer in milliseconds, every time.

Security. In IT, you scan networks and patch quickly. In OT, an aggressive network scan can knock over a 20-year-old controller, and a patch may need the line stopped and the process revalidated.

Why convergence matters now

Smart manufacturing needs data to flow from the machines up to the business, and plans to flow back down. AI and cloud platforms both need shopfloor data to leave the plant safely, with its context intact. None of that works if IT and OT run as separate kingdoms.

Convergence doesn't mean IT takes over OT, or the reverse. It means an agreed architecture, and people on both sides who understand each other's constraints.

Where MES/MOM fits

MES/MOM is the most IT-like thing on the shopfloor and the most OT-like thing in the IT landscape. It talks to ERP and the cloud on one side and to PLCs and SCADA on the other. That makes it both a bridge and a security boundary.

It's also why ownership of MES/MOM can get political. Some businesses give it to IT, some to operations, and some share it.

Making it work

• Agree the architecture together. IT and operations teams both need to be involved as key stakeholders, and aligned on what connects to what and where the data goes.
• Use standard connectivity. OPC UA and MQTT rather than custom interfaces. See OPC UA, MQTT and UNS in plain English.
• Never connect the enterprise network straight to a PLC. Go through MES/MOM, with controlled connections between the two networks.
• Put people from both sides on the project team from the start, not just at sign-off.

My view

MES/MOM needs both. IT should own the application, infrastructure, integrations and security. OT and operations should own the processes, master data standards, screens and KPIs. In multi-site businesses that blend usually becomes a centre of excellence. More in Rolling out across sites.

Who owns MES/MOM in your business today: IT, OT, or both?

What each one does

SCADA (supervisory control and data acquisition) is for real-time control and monitoring of equipment. Process engineers and control room operators use it to see what the plant is doing and adjust it: setpoints, alarms, valve states, tank levels.

MES/MOM is for managing operations: which order is running, what's been produced, what was scrapped and why, whether quality checks were done, what material was used, what maintenance is due. The full scope is in What is MES/MOM?

So far, clearly different. But there's overlap.

Where they overlap

MES/MOM also gives real-time visibility of the shopfloor through PLC connections. Some MES systems offer advanced two-way communication with equipment: sending setpoints and recipes down to the machine, not just reading data up. Some show things like fill levels in tanks and silos.

And often, SCADA and MES are reading the same data from the same PLCs anyway.

When MES/MOM can do the job on its own

In many discrete and lighter process environments, where SCADA is mainly used for visibility rather than tight process control, MES/MOM can often cover what's needed.

The benefits of rationalising:

• One system for operators. A simpler user experience, with production context alongside machine status.
• A simpler application landscape. Fewer systems to integrate, maintain and secure.
• Lower cost. Fewer licences, less infrastructure, less support.
• Faster troubleshooting. When a machine alarms, the order, the material and the operator are right there.

When you need both

In heavier process industries, SCADA usually stays. Think continuous chemical processes, utilities, complex batch control or anything with safety-critical control loops. There, SCADA and the control layer are doing real-time control that MES/MOM isn't designed for.

In that case, get the boundary clear. SCADA controls the process. MES/MOM manages the operation, receiving the data it needs from the control layer and sending down orders, recipes and parameters where appropriate.

How to decide

Ask:

• Is SCADA here mainly for control, or mainly for visibility?
• Are operators using both systems to do their jobs? If so, what are they getting from each?
• Are the two systems reading the same signals from the same PLCs?
• Could MES/MOM provide the visibility operators need, with production context added?

My view

Do you need both? Maybe, but not always. If SCADA is mostly a visibility layer, and operators are switching between two screens to see the same machine, I think it's worth exploring whether one system will do. Where SCADA is doing real control, keep it and get the boundary right.

I'm sure plenty of people will disagree with parts of this. So, in your factory, is SCADA doing control, visibility, or both?

But don't get left behind. If you can't do everything, at least do something.

A great first step is removing paper from the shopfloor.

Paper is the enemy of progress

Paper travellers. Job cards. Clipboards. Printed work instructions. Quality check sheets. Logbooks. Whiteboards.

They get lost, they get damaged, and they're often illegible. The data on them arrives late, if it arrives at all, and someone has to type it into a system later. Usually at the end of the shift. Usually from memory.

What you gain

The more paper you remove, the more of these benefits you get:

• More accurate data. Captured at the moment, not reconstructed afterwards.
• A simpler operator experience. No binders, travellers or printouts. The right information at the right time, on one screen.
• Real-time visibility. No waiting until the end of the shift or the job to see what's happening.
• Data-driven decisions. Based on facts, not on whoever shouts loudest in the morning meeting.
• Automatic data collection. Once you're digital, connecting the equipment becomes a natural next step.
• Prompts to do the right thing. The system guides operators through each step and flags what's been missed.

Where to start

Pick the paper that hurts most. Often that's:

• Quality check sheets, where errors and missed checks cause real problems
• Downtime logs, where the numbers are guesses
• Work instructions, where version control is a constant battle
• Travellers, where finding out where an order is means walking the floor

It can be phased. One process, one form at a time.

The one mistake to avoid

Start as big or small as you like, but always start with the end in mind.

The trap is choosing a quick, cheap tool to digitise one form, then another tool for the next, then another. Each one works. None of them talk to each other. And none can grow into production execution, traceability or maintenance.

Before long you've swapped paper silos for digital silos, and you'll need to switch and re-invest, or your progress stalls.

So think about your end game, even on day one. Choose a platform that can start with digital forms and checklists, and grow into full MES/MOM without starting again. That's the same argument I make in Connected worker: one app, not five.

Don't just copy the paper

One more thing. Don't recreate the paper form on a screen field by field.

Use the move to ask whether every field is needed, whether some can be captured automatically, and whether the process itself could be simpler. Digitising a bad form gives you a bad digital form.

Which piece of paper on your shopfloor would you most like to see the back of?

Get it right, and you have a platform that grows with you for years. Get it wrong, and you'll be evaluating again in three to five years, this time with the added pain of migrating away from a system that didn't fit.

I've seen too many selections go wrong because the focus was on price, or on a narrow set of today's problems. Or on a massive list of requirements that didn't reflect the real need, with a scoring system that eliminated the best fit on a technicality, or because some vendors scored higher on less important requirements. Here are the questions I'd ask every vendor.

Technical foundation

1. What's your approach to master data synchronisation with ERP? Who owns materials, BOMs and routings, and how do changes flow?
2. How do you integrate with our existing landscape? What methods of communication do you use for integrations, and how flexible are they?
3. Can you handle our industry's specific requirements and compliance?

User experience

4. How does it work on tablets, mobiles and shopfloor terminals? Not just the office screens.
5. Is the interface genuinely intuitive for operators? Does it look and feel like the apps your operators use on their own phones?
6. How much training will our people need? Your operators and the team who'll configure it, and is there self-serve online training?

Functional scope

7. How deep is your coverage beyond production? Quality, inventory and traceability, maintenance, tooling, energy, connected worker.
8. Will it stop people across departments needing multiple systems? One application, one data model, or several products integrated together?
9. Does it give real-time visibility across all production processes?

Scalability and future-proofing

10. What's your roadmap for AI and advanced technology? Is the application being actively developed, and which capabilities are available today rather than still on the roadmap?
11. How do you support IIoT and modern connectivity? How is machine data captured automatically, and put in context?
12. Will it grow with us? Across sites, and across functions we don't need yet but will.

Don't write a wish list

Many RFPs read like a list of nice-to-haves. If you're asking for everything, you don't know what you want.

I once saw an RFP asking whether an MES could publish production results directly to social media. A head-scratcher, for sure.

My advice:

• Focus on your real requirements, and document them accurately.
• Be clear about what you need now, and separate it from what you might need later.
• Think about future needs at the level of platform capability, not detailed features.
• Base it on your process maps. If you've done the work in Map your processes, your requirements will be specific and vendors can answer properly.

Going overboard makes it harder for everyone, gives you misleading answers, and slows the whole process down. If you're working with an adviser or systems integrator on the RFP, use their experience to keep it focused. The good ones have seen hundreds of these, and they know which requirements genuinely separate one platform from another.

See it, don't read about it

Written answers to 400 RFP questions will mostly say "yes". Demonstrations tell you far more.

Give shortlisted vendors your real scenarios: one of your products, one of your processes. Ask them to demo it, not just present slides. And towards the end of the selection process, ask to speak to customers who are similar to you.

Choose the partner too

You're not only buying software. You're choosing the people who'll help you implement it. Look for a partner who understands manufacturing, not just technology, with a track record in your industry.

Be wary of choosing a cheaper solution as a stop-gap. It's rarely cheap by the time you've outgrown it.

What other questions should manufacturers be asking? I'd love to hear yours.

OEE gets most of the attention. It's probably the most widely adopted manufacturing KPI in the world, though not everyone rates it as the best measure, and on its own it won't tell you everything. Some of the most useful measures sit just underneath it,

There's an international standard for manufacturing KPIs, ISO 22400. You don't need to memorise it, but it's worth knowing it exists, especially if you're comparing figures across sites or systems.

Here are the ones I'd make sure you can measure.

First-pass yield

The percentage of output that passes every quality check first time, with no rework.

It tells you how capable your process really is. A line can have decent OEE quality rate and still be quietly reworking 10% of what it makes. First-pass yield exposes that.

You'll also hear "first time through". It's subtly different depending on who defines it, so agree the definition before you compare numbers.

Scrap rate

The percentage of output that's waste.

Don't just count the material. Scrap also throws away the machine time, labour and energy that went into making it. In food and process industries, the related measure of yield, raw material in against good product out, is often the single biggest profit lever.

Cycle time

The time it takes to produce one unit, against the target.

Cycle time variation across shifts and operators is one of the clearest signs of an unstandardised process. It also feeds the real-time schedule, so the system can estimate when an order will actually finish.

Changeover time

The time it takes to switch from one product to the next.

In high-mix, low-volume manufacturing, changeovers are often the biggest constraint on throughput. Measuring them accurately is the first step to reducing them.

OTIF

On Time In Full. The percentage of orders delivered complete and on the date promised.

This is the KPI that connects shopfloor performance to the customer. You can have great OEE and still miss deliveries if the wrong things were made at the wrong time. OTIF keeps everyone honest.

MTBF and MTTR

Your maintenance KPIs.

• MTBF (mean time between failures): how often equipment breaks down.
• MTTR (mean time to repair): how quickly you fix it.

Together they tell you whether your reliability is improving and where maintenance effort is best spent. More in MES functionality: maintenance.

Getting the data right

Every one of these KPIs depends on accurate, granular data. Calculated from end-of-shift entries, they'll be wrong in ways that look perfectly plausible.

The best approach:

• Capture counts, states and stops automatically from the equipment.
• Calculate KPIs in one system, from one set of data, so production, quality and maintenance aren't each producing their own version.

That's a big part of what MES/MOM does.

Don't measure everything

One word of warning. It's tempting to build a dashboard with 40 KPIs. Nobody will look at it.

Pick a small number that connect to what the business cares about: usually output, quality, cost and delivery. Make sure they're trusted. Then use them every day, in the morning meeting, to decide what to fix next.

Which KPI does your leadership team ask about most, and do you trust the number?

Nobody reads them unless they're new or something's gone wrong. And even then, they have to find the right page for the right product on the right machine.

Digital work instructions are key to making sure the right thing happens at the right time, in the right way, no matter who's doing it. But only if they're done properly.

The problem with paper

Version control. A procedure changes. Someone updates the master document. Did every printed copy get replaced? On every line? On every shift? You'd be surprised how often the answer is no.

Finding the right one. Instructions vary by product, machine and operation. On paper, the operator has to work out which one applies.

No proof it was followed. A signature at the bottom of a sheet says someone was there. It doesn't say they did each step.

Knowledge stays in people's heads. The real tips, like the extra adjustment that stops the jam, often never make it into the document at all.

What digital should mean

Putting a PDF on a tablet isn't digital work instructions. It's paper on a screen.

Proper digital work instructions are:

• Presented automatically. The operator starts an order and the instructions for that product, operation and machine appear. No searching.
• Always the latest version. Revised centrally, live everywhere immediately, with the old version retired.
• Step by step. One step at a time, with images, video or diagrams where they help.
• Interactive. Steps confirmed, measurements entered, checks completed as part of the flow, not afterwards.
• Linked to skills. When an instruction changes, the people qualified on it acknowledge the new version.

Why context changes everything

The real value comes when instructions know what's running.

If the system knows the order, the material, the machine and the tool, it can show exactly the right steps and parameters. Not a generic procedure with "for product X see section 4.2".

It can also respond to what's happening. A material lot changes, so a check appears. A tool hits its change limit, so the changeover instructions appear. A quality result is borderline, so the corrective steps appear.

That works best when work instructions live inside MES/MOM, alongside production, quality and inventory. A standalone instructions tool doesn't know a lot just changed.

Onboarding in days, not months

This is where I see the biggest impact.

When the process lives in someone's head, a new starter shadows them for weeks. When the process is documented, standardised and presented step by step, people become productive in days.

With the workforce challenges most manufacturers face, that's not a nice-to-have. It's how you keep lines running when experienced people retire and new people don't stay as long.

Capture what the experts know

One more thing. Use the move to digital as a chance to capture tribal knowledge.

Sit with your best operators. Ask what they do that isn't in the procedure. The adjustment they make on a cold morning. The sound that means something's about to jam. Put it in.

Then let operators flag when an instruction is wrong or unclear, from the screen they're working on. Instructions should improve continuously, not once every few years when an audit comes round.

Where to start

Pick the process with the most variation between shifts, or the one where new starters struggle most. Digitise it properly, with context, and measure the difference in errors and onboarding time.

How many versions of the same work instruction are on your shopfloor right now?

IIoT is a concept, not a system

IIoT, the Industrial Internet of Things, is about connecting machines, sensors and devices so their data can be collected and used. When people say IIoT, they usually mean OPC UA, and increasingly MQTT.

It's a concept. Many systems help deliver it: IIoT platforms, historians, edge devices and MES/MOM itself.

In ISA-95 terms, IIoT lives in the connectivity layer: Levels 1 and 2, the sensors and the control systems.

MES/MOM is operational management

MES/MOM sits at Level 3. It takes that sensor data and puts it to work:

• It knows which order is running, so a count becomes progress against a plan.
• It knows the material and the lot, so data becomes traceability.
• It knows the quality plan, so a measurement triggers the right check at the right time.
• It knows the maintenance history, so a fault becomes a work request with context.
• It guides and validates what operators do, not just what machines do.

IIoT gives you data points. MES/MOM gives you operational management.

Data collection is part of MES

Collecting data from devices, sensors and equipment is one of the core functions of MES/MOM. So an IIoT platform overlaps with one part of MES, the connectivity and data collection, rather than with the whole. MES/MOM often acts as the IIoT layer itself, connecting directly to machines, so a separate IIoT system isn't always needed.

How to make IIoT projects succeed

IIoT has real value. Successful projects tend to share a few traits:

• They're connected to operations. IoT data that feeds MES/MOM, or sits inside it, gains the context of the order and the lot.
• They focus on data quality. The right sensors, properly calibrated, with data validated before it's trusted.
• They start small. Bottleneck assets first, then scale across the site.
• They take security seriously. Connecting OT equipment to networks without proper cybersecurity is asking for trouble.

How they work together

Where a separate IIoT platform is used, it feeds data into MES/MOM, a historian or a data platform. MES/MOM turns it into managed operations and contextualised data. A data platform makes it available for analytics and AI.

My view

Some companies market themselves as IIoT platforms when they don't have enough functionality to be a full MES. To be fair, it's great marketing: IIoT sounds much cooler than MES. But it creates real confusion for buyers.

The pattern I see is a manufacturer investing heavily in sensors and dashboards, then realising they still can't manage a production order or trace a lot. So they build those functions on top, or buy an MES/MOM and integrate the two, and do some of the work twice. It's not about how many devices you connect. If you need MES functionality, you need an MES.

How is your IIoT project going, and can it tell you which order was running when that sensor spiked?

This article is about making a bought platform fit. If you're weighing that against writing your own, building from building blocks or stitching specialist tools together, I compare all four in Code, build, stitch or configure.

Everyone wants a system that "fits our processes". Vendors say their product is "fully flexible". And nobody defines what they mean. So let me break it down.

The six levels

Out of the box. Pre-configured content. Turn it on, add your master data and you're running. Ideal for standard dashboards, reports and common processes.

Configurable. Settings you switch on and off to make the system work your way. No code needed. But you do need proper training and thought to set up master data and settings correctly.

Low-code and no-code. Drag-and-drop builders for business logic, screens, dashboards and reports. Great for more complex needs without writing actual code.

Integrations. MES/MOM connects to almost everything: ERP, APS, WMS, automated vehicles, shopfloor equipment, sensors, metrology. Some integration work is inevitable. Pick a system with strong, flexible integration capabilities.

Extensions. Overrides that change behaviour without touching the underlying product code, and work in a standardised, supported way.

Customisations. Changes to the product to support specific business logic. This is where it gets expensive. Hard to maintain, hard to upgrade, and they'll cost you for as long as you run the system.

Why the distinction matters

Every customisation is code that has to be specified, built, tested, documented and then retested with every upgrade. It creates a dependency on specific developers. And very often, it encodes a bad process into software rather than fixing the process.

Less mature systems often look cheaper upfront. But the total cost of ownership grows fast as customisations pile up. You pay again at every upgrade, or you stop upgrading and get stuck on an old version.

So a higher licence cost isn't necessarily something to shy away from. Be wary of a cheap quote from anyone who doesn't understand your processes in detail, because that's usually how costs escalate.

In software, almost anything is possible. But what's possible now can become very hard to live with later.

Your processes probably aren't unique

I hate to break it to you, but unless your processes aren't handled well by any of the main software vendors, your manufacturing processes are not unique.

What might be unique are your business processes around manufacturing. And a lot of what feels unique is habit, comfort and workarounds that grew over the years.

So you have a choice. Adapt to the system, have the system adapt to you, or a mix. If it's a mix, you need to decide the mix deliberately.

How to keep customisation down

If you're buying a platform, pick a mature, configurable one. The more you can achieve through configuration, the less you'll need to customise. But be realistic: you won't remove customisation completely, especially for integrations with third-party software.

Assess every gap with an open mind. For each point where you'd need to deviate from how the software works, ask: is this business-critical and must work exactly as before? Or could a process change or some training close the gap, so we use the software the standard way?

Adopt best practice. A mature MES/MOM is built around what works across many factories. Insisting on your own way for everything usually costs more than it returns.

Have strong project management on both sides. Vendor and manufacturer. Someone needs to say no, politely and often, to requests that recreate the old system in the new one.

A warning sign

If a vendor tells you everything needs to be custom-built, be wary. That's a sign of an immature product, or of requirements that haven't been challenged.

Some products are really toolkits, which need a lot of coding to fit together, or a number of acquired applications that aren't well integrated. Others are configurable through master data and low-code tools, so your own team can build screens and reports without going back to the vendor. Ask which you're looking at.

And if your own team is pushing for heavy customisation, challenge them. Are we customising because the process genuinely requires it, or because we're unwilling to change the process?

What's the one part of your process you're most worried an off-the-shelf system won't handle?

It's one of the most common questions in manufacturing software, usually from people who know ERP well and are meeting MES for the first time. The answer starts with what ERP does well.

What ERP does

ERP runs the business side of a manufacturer on one set of data. Finance, sales orders, purchasing, planning through MRP, inventory valuation and costing. When it's implemented well, leadership sees margin by product and customer, and sales can promise dates based on real stock and lead times.

In manufacturing, ERP is where production is planned and accounted for. It creates the production order, holds the bill of materials and routing behind it, and books the result. More in What is ERP, and why every manufacturer needs a good one.

What MES does

MES, and its broader form MOM, runs the shopfloor. It takes the order from ERP and executes it: which line, which operator, which material lot, what was produced and scrapped, and why the machine stopped. MOM extends that across quality, inventory and maintenance on the same data.

It works at the point of work, in real time, with screens designed for operators rather than office users. More in What is MES/MOM?

Side by side

Where they overlap

The overlap is real, and it's where most of the confusion comes from.

Production orders. Both systems hold them. ERP owns the order as a business object; MES/MOM owns what happened while it ran.

Inventory. ERP owns stock as a financial asset. MES/MOM owns line-side stock, work in progress and what each order consumed.

Quality. MES/MOM runs quality on the shopfloor. It manages the inspection plan, triggers checks from what's running, records the results and puts material on hold when something fails. ERP needs a view of some of that, usually aggregated: results on critical characteristics, defects and scrap for costing, supplier quality issues, and non-conformances that need managing through to closure. MES/MOM captures the detail and passes ERP what it needs.

Shopfloor reporting. Many ERPs can record operation completions and quantities, and some ERPs designed with manufacturing in mind cover detailed routings and shopfloor reporting well. That makes the gap to MES/MOM smaller.

What MES/MOM adds is a different layer of data: finer detail, captured in real time at the point of work, with every event tied to its order, batch, machine and operator.

Can ERP do the job of an MES?

For a small, simple operation, ERP's shopfloor reporting may be enough. Plenty of manufacturers start there.

It stops being enough when you need any of these:

• Real-time data straight from the machines, including short stops
• Downtime reasons captured at the point of work, with OEE by line, shift and product
• Lot and serial traceability down to which component went into which finished item, with quality results and process parameters attached
• Material validated at the point of use: right item, right status, in date and next in FIFO sequence
• In-process quality checks and SPC triggered by what's running
• Labels printed at the moment inventory is created, rather than pre-printed
• Guided work instructions and error-proofing for operators
• Operator skills and certifications checked before a job can start
• Tool life counted from real production
• Recipes and setpoints sent to the machine for the order being run
• Electronic batch or device history records for regulated products
• Maintenance working from the same downtime data as production
• Energy use linked to the order and product that caused it

Standard ISA-95 practice is also not to connect ERP directly to the machines. MES/MOM, or a connectivity layer, sits between them.

How they work together

The usual pattern:

1. ERP releases a production order, with its BOM and routing, to MES/MOM.
2. MES/MOM releases it to the shopfloor and captures what happens as it runs.
3. MES/MOM sends back actuals: quantities produced, material consumed by lot, scrap and labour.
4. ERP uses those actuals for costing, inventory and the next round of planning.

ERP data gets better when MES/MOM is in place, because it receives validated actuals instead of estimates. More in Implement MES to remove complexity from your ERP.

Master data is the bit people underestimate. MES/MOM needs more detail than most ERP routings were set up with, so get it right in ERP first, then add any extra detail in MES/MOM where it's needed. See Your ERP master data isn't ready for MES.

Deciding where the line sits

A few questions settle most of it:

• Who uses this function: people in the office, or people on the shopfloor?
• How fresh does the data need to be: overnight, or right now?
• Does it need context from the machine, the lot or the operator?
• Does it need more detail than the business needs for costing and planning?

The more answers point to the shopfloor, the more it belongs in MES/MOM.

My view

You'd never use an MES to do the job of an ERP. So why use an ERP to do the job of an MES? The best-run manufacturers I see don't treat this as ERP versus MES. They treat ERP as the backbone and add MES/MOM where the operation needs the detail.

Where does the line sit in your business today, and is it where you'd draw it if you started again?

Moulds, dies, jigs, fixtures, cutting tools. In injection moulding, stamping, pressing and casting, the tool is often the single biggest factor in product quality. A worn tool produces poor-quality parts. A broken tool stops the line. And no tool means the order can't start at all.

Yet in a lot of factories, tooling is managed on a whiteboard or in a spreadsheet. That works, until it doesn't.

What tooling management covers

• Tool register. Every tool, its type, location, status and history.
• Tool life. Shots, strokes, cycles or hours, counted automatically from production, against limits.
• Maintenance and refurbishment. Planned work triggered by usage, not just the calendar, plus repairs logged against the tool.
• Cavities. For multi-cavity tools, which cavities are active or blocked, because a blocked cavity limits output.
• Tool sets. Tools that must be used together, which adds complexity to setup and planning.
• Readiness. Whether the tool for the next order is available, maintained and at the machine.

Why it belongs in MES/MOM

Tooling touches almost every other pillar.

Production: tool life is counted from actual production, and an order can't run without the right tool.

Quality: when defects appear, the tool and cavity are often the first suspects. Recording which tool and cavity made each part makes root cause analysis much faster.

Maintenance: tools need maintenance just like machines, ideally based on usage.

Planning: the schedule needs to know whether the tool, and the setter, are available.

That's a lot of overlap. In a separate system, every one of those links becomes an integration, or a phone call. A specialist tool-management system can still make sense for very large tool rooms, with presetting and regrinding to run.

Tooling and traceability

Including tooling in traceability is one of those things that seems minor until you need it.

When a complaint arrives, being able to say "these parts were made with tool T-114, cavity 3, between 02:00 and 04:00, when it was at 92% of its life" changes the investigation completely. You can scope the problem precisely, rather than quarantining a week of production. More in Your traceability probably isn't as good as you think.

Turning a bottleneck into a planned activity

The biggest win I see is simple. No tool or no setter, and the job doesn't start.

When tool requirements, availability, setup and setter readiness are tracked together, changeovers become planned activities instead of scrambles. The tool is prepared before it's needed. The setter is scheduled. The previous order finishes and the next one starts.

In high-mix environments, that alone can recover a surprising amount of capacity.

This article is part of the MES functionality in depth learning path.

How do you know today whether the tool for tomorrow's first order is ready?

Otherwise you're maintaining the same data in several places. Not a recipe for success.

But please don't assume your existing ERP master data is good enough.

MES needs more detail

MES/MOM is a more detailed application for factory data. That's why you're investing in it: to get a granular, real-time view of the factory.

So guess what. The master data needs to be at a level that supports it.

Most ERP implementations had enough to worry about. Often the routing detail was set to what costing needed, and nothing more. That's not a criticism. It's what was needed at the time, based on the information available.

But MES/MOM needs to know things like:

• The individual machine in the line that each operation runs on, not just the work centre
• Semi-finished material numbers at the right level of detail, as material moves through the operations
• Realistic cycle times and setup times, by product and machine
• Which materials are consumed at which operation, not just in the order overall
• Units of measure that convert correctly between operations
• Which quality checks apply at which step

If ERP has one generic operation called "Production", MES/MOM has nothing to work with.

Fix it once, for everyone

A part of any MES/MOM project is getting the ERP master data right. That often means improving materials, BOMs and, most commonly, routings.

The principle is simple. The system of record for each piece of master data needs enough detail for every application that relies on it. Not just MES/MOM, but warehouse, maintenance and planning systems too.

Fix it at the source, once, and let it flow to everyone who needs it. Where a specialised application needs extra detail, add it there.

Plan for it early, ideally with your ERP project

Successful projects don't assume their data is MES-ready. They invest time to clean and standardise materials, BOMs and routings early, rather than trying to fix it later in the project.

If you're implementing or upgrading ERP, plan MES/MOM alongside it, even if MES/MOM goes live later. Design the master data once, at the level of detail both need. Otherwise you'll rework it later, and master data rework takes time, costs money and has a knock-on impact on other modelling decisions, such as costing and planning.

Don't rush it

Master data isn't glamorous. Everyone wants to get to real-time OEE, automated traceability and SPC. But those all sit on top of the basics.

Get the data right first. Everything else follows.

Where do you see the most confusion around master data between ERP and the shopfloor?

Connected worker tools and MES/MOM both put software in front of operators, so it's natural to ask how they compare. This article sets out what each does, and the two main ways to buy connected worker: as a standalone app, or built into MES/MOM.

What is connected worker?

Connected worker is about guiding frontline workers and supporting them in their daily activities. It's also about giving them access to the information and insights they need about the work to be done and the assets they look after.

A connected worker capability is the digital layer between your frontline people and everything they need to do their job well. In practice:

• Digital checklists and task management
• Shift handover that doesn't rely on a scribbled note or a quick chat at the door
• Skills and certification tracking, enforced at the point of work
• Documents, SOPs and work instructions, always the latest version
• Health and safety procedures and sign-offs

Each of these replaces something that, in most factories, still runs on paper, whiteboards or memory.

Why it matters now

The workforce problem is not a future problem.

72% of industrial organisations say frontline workforce issues have hurt their operational performance (LNS Research, 2023). Your most experienced people are approaching retirement, and the knowledge that keeps your lines running lives in their heads, not in any system. Median tenure in US manufacturing is now 4.9 years (USAFacts), so the people replacing them won't be around long enough to absorb it the old way.

And the gap is getting wider. Deloitte and the Manufacturing Institute estimate US manufacturing could need as many as 3.8 million new employees between 2024 and 2033, and that 1.9 million of those jobs could go unfilled (Manufacturing Institute, 2024). In the same release, 65% of manufacturers named attracting and retaining talent as their primary business challenge.

That changes the job of shopfloor software. It's no longer enough to record what happened. It has to guide a new starter through the process so they get it right on their second day, not their second year.

Connected worker capabilities are designed to do that, and spending on them is growing fast. MarketsandMarkets puts the connected worker market at $8.6 billion in 2025, growing at 18.5% a year to around $20 billion by 2030 (MarketsandMarkets, 2025).

What MES/MOM does for operators

MES/MOM runs the operation. For an operator, that means:

• Running production orders, with changeovers, counts, scrap and downtime
• Performing quality inspections and taking samples for the lab
• Consuming raw materials and labelling what they produce
• Carrying out autonomous maintenance on their equipment

Many MES/MOM platforms now include connected worker capabilities as well, such as checklists and handover.

Side by side

Two ways to buy connected worker

A standalone app. Quick to get going, with good mobile screens and easy configuration. It handles the people side well. On its own it doesn't know which order is running, so it can't trigger a quality check when the material changes, or stop someone consuming a quarantined lot. When those needs arrive, the app is integrated with MES/MOM, or worse (and more common) used alongside it. Operators then work across two systems, and each boundary is an interface to own. Some connected worker platforms also aim to be a single front end across several back-end applications, which can work, though the front end can become bespoke and fall behind the products underneath.

Built into MES/MOM. Checklists and skills sit on the same platform and data as production and quality. That gives them context:

• Checklists know the context. A start-up checklist appears because this order is starting on this line, not because it's 6am.
• Quality checks are triggered by events. A material change, a tool change or a count threshold prompts the right inspection automatically.
• Skills are enforced, not just recorded. An operator who isn't qualified on a machine can't start an order on it.
• Shift handover is built from real data. The incoming crew sees what ran, what stopped and what's waiting.

But you must make the right decision up front to allow you to grow into a broader and more capable system over time, rather than opting for a point solution now as a quick fix. Both routes are covered more broadly in Code, build, stitch or configure.

Questions to ask vendors

• What happens when we need production execution and quality on the same screen?
• How does a checklist know which order, material and machine it relates to?
• Can skills block an action, or only report on it?
• If we add MES/MOM modules later, is it the same data model or another integration?

My view

I'm a big believer in connected worker, and it's often the best place to start: going paperless on checklists and handover delivers value in weeks and builds trust with the shopfloor early. My preference is connected worker built into MES/MOM rather than bolted on beside it. As soon as frontline workers need more than one application, that introduces friction, and nobody wants to switch between screens to piece together what's happening.

Start with the end in mind. Connected worker is the front door. MOM is the house behind it. Make sure you're buying a door that's attached to a house.

Have you implemented a standalone connected worker tool and then needed MES/MOM on top? I'd genuinely like to hear how that went.

They don't. If you're going to spend money on any of them, it's worth knowing which is which.

Let's align on some terminology

Artificial intelligence (AI) is the broad category. Any system that performs tasks that would normally need human intelligence: recognising patterns, making decisions, predicting outcomes.

Machine learning (ML) is a subset of AI. You train an algorithm on historical data so it can predict an outcome from new data, faster and more consistently than a person could. The key word is train. You need a data set and a model, and you train, test and refine it before you trust it. It's not magic. It's statistics at scale.

Generative AI (GenAI) is a different subset. Large language models that generate text, images, code and other content. This is what most people mean when they say "AI" today.

So when someone says "we're doing AI on the shopfloor", the first question is: which kind?

Machine learning: older than you think

Machine learning and statistical methods have been in MES/MOM for longer than most people realise.

Statistical process control (SPC) has been spotting drifting processes for decades. It's not branded as AI, but it's the same family of thinking: learn what normal looks like, then flag what isn't.

Predictive maintenance uses algorithms to find patterns in vibration, temperature, current or cycle counts that come before a failure. Proven, practical, and paying back in factories today. I cover the data it needs in Predictive maintenance needs data you aren't collecting yet.

Newer ML applications are opening up even more:

• Process parameter optimisation. Finding the speeds, temperatures and pressures that minimise scrap for each product and material.
• Predictive quality. Predicting whether a part or batch will pass inspection before it's inspected, so you can act while it's still on the line.
• Anomaly detection. Flagging unusual combinations of signals that no person watching a dashboard would catch.
• Vision inspection. Cameras and trained models spotting defects consistently, often running at the edge, right at the machine.

Generative AI: useful in different ways

GenAI's sweet spot is helping people, not controlling machines. Some genuinely practical examples:

• Asking questions in plain English. "Write a one-page summary of OEE on Line 4 over the last 12 months for the CI manager, and flag anything unusual."
• Configuring systems. "Set up a new packing line in the packing department, and ask me what you need to know."
• A knowledge assistant. "How do I calculate Cpk?" or "What is this screen telling me?"
• Shift summaries. What ran, what stopped and what's waiting, written up for the incoming crew.

I go through more of these in Practical GenAI for the shopfloor.

Agentic AI: the next step

You'll also hear a lot about agentic AI. These are systems that don't just answer a question but plan and carry out a task: gathering information, deciding what to do, acting through other software, and learning from the result.

It's exciting. It also asks the most of your data, because an agent acting on your operations data and transactions needs very good data and very clear guardrails. I explain it for operations leaders in Agentic AI and MCP, explained.

What all three need

Every one of these depends on data, but not always the same data, or at the same time.

ML learns from your own operational history, so it needs good, granular, contextualised data collected over time. It can't learn patterns from shift totals typed in at 6am.

GenAI arrives already trained, so it can start earlier. It works well on the documents and know-how you already have, however messy: procedures, manuals, maintenance notes, shift logs. It can even help clean that history up, for example by classifying years of free-text downtime comments into consistent reasons. But when you ask it about live operations, it can't summarise a shift accurately if the shift's data is scattered across paper, Excel and three systems.

An agent can't safely act on information it can't trust.

So AI that predicts or acts grows with the data foundation, and the two are best built together. Each use case shows you which data to capture next, and each improvement in the data makes the model better. GenAI on documents and knowledge can start now. On the shopfloor, MES/MOM is where most of that data is created and given its context: which order, which material, which machine, which shift, and why.

A practical way to start

Start with a decision you'd like to make better, and work on the AI and the data for it together.

• Which failure would you most like to see coming?
• Which quality defect costs you most?
• Which report do people spend hours building every week?
• Which question do new starters ask most often?

Then ask whether you have the data that decision needs, at the right granularity, with the right context. If you do, there's probably an AI use case worth piloting. If you don't, you've found both the data to build and the AI use case that justifies building it. Capture the data on one line, and start the model there as the history grows.

Which of these three is closest to what your business is asking for right now?

I hear this constantly. And I know how it feels. It's infuriating.

The good news is that it's usually not the idea that's being rejected. It's the way it's being presented.

What's really blocking it

When I dig into stalled business cases, the same things come up:

• "We don't have the data to prove the ROI."
• "Our executives don't understand the urgency."
• "The investment looks too big."
• "We tried something similar and it didn't work."

And underneath all of them, one thing: fear. Fear of overrun, overspend and failure. Nobody wants to be the executive who green-lit the project that went wrong. I get it. Their job is on the line.

So your business case has to deal with that fear directly.

Speak business, not features

Leadership doesn't need technical specifications. It needs business impact.

Start with the pain points that keep your leadership awake at night, and put money on them:

• Quality: what do scrap, rework and customer complaints cost per year?
• Downtime: what's an hour of lost production on your bottleneck worth in revenue?
• Labour: how many hours a week go on manual data entry, chasing information and building reports?
• Delivery: what has late or incomplete delivery cost in penalties, lost orders or lost customers?
• Inventory: how much working capital is tied up in buffers you hold because you don't trust the data?

Then connect those numbers directly to what the system will change.

The structure that gets approved

Business cases get approved faster when they clearly show:

1. Current-state costs. What the problems cost today, in money.
2. Future-state benefits. What will improve, by how much, and when.
3. Realistic implementation costs and timeline. Including your internal people, not just licences and services.
4. How the risk is managed. Milestones, measures and decision points.

I'd spend the most time on the fourth point, because it deals with the fear.

Reframe the risk

The strongest business cases reframe the conversation completely.

Transformation as risk mitigation. The bigger risk isn't the investment. It's the quality escape, the failed audit, the experienced operator retiring with all the knowledge in their head.

The cost of doing nothing. Your competitors are moving. Customers are getting less patient with quality issues and late deliveries. Every year you delay has a cost, and it's usually bigger than people assume.

Use the 1% question

I always ask: what would a 1% improvement in OEE be worth to your business? Or what would a 1% reduction in scrap mean, and so on.

Work it out. For most manufacturers it's a very significant number. Then compare it with the improvements the research reports. Deloitte's 2025 survey found average improvements of 10% to 20% in production output among large manufacturers investing in smart manufacturing. I pull together more of the research in What the research says about smart factory ROI.

Use outside research to make the conversation credible. Use your own numbers to make it real.

Don't promise everything on day one

Don't promise transformation overnight. Set milestones. Show quick wins. Build momentum.

Some companies pay for their MES in months rather than years, on tangible benefits alone, such as less scrap and more uptime. There are intangible benefits too, like happier customers and less firefighting.

Your leadership doesn't need perfection. It needs confidence that you understand the risks and have a plan to manage them.

What's holding back your next strategic investment: the numbers, or the nerves?

The honest answer is: it depends. But that's not very helpful, so let me be more specific.

The typical range

For a first site, my answer is between six and twelve months from kick-off to go-live.

Other people's experience varies. When I ran a poll on LinkedIn a while ago, the most common answer for the first factory was 12 to 18 months. A focused deployment, covering production and quality at one site, can be done in around six months. A broad programme covering several pillars, complex integration and many lines takes longer.

Subsequent sites are usually much faster, especially if you build a template, and several sites can be done in parallel. More on that below, and in Rolling out across sites.

Why it isn't just a software install

It's easy to think of MES/MOM as software you install. It isn't. A project is also:

• A master data clean-up
• Organisational change
• Process change
• Hours and hours of communication

That takes time. It also takes your best people, so you need to make sure they're available, backfilling their day jobs if needed.

How one project went live in four months

I've been involved in MES projects that went live in as little as four months. People often ask how.

The key factors were:

1. The customer knew what they were buying. They were well educated on MES before they started.
2. The team was superb. The right people were available. It was their top priority, and everything else fell in behind it.
3. The product was highly configurable. The implementation was almost entirely out of the box, with very little custom work.
4. The initial scope was small to medium. Not a full-blown MOM on day one. Start with the core, then grow into the rest.

None of those are about the software being installed faster. They're about preparation, people and scope.

What makes projects overrun?

The usual culprits:

• Scope creep. Trying to implement every suggestion, especially when recreating an old or homegrown system. See Replacing a homegrown MES.
• Master data. Discovering halfway through that routings and BOMs aren't detailed enough. See Your ERP master data isn't ready for MES.
• Under-resourcing. The people the project needs are already the busiest in the business. See Building the right team.
• Unchallenged processes. Customising to match every existing quirk instead of simplifying first. See Map your processes and Configure, don't customise.
• Integration surprises. Legacy equipment and systems that are harder to connect than expected. See Connecting MES/MOM to everything else.

Big bang or phased?

Phasing the delivery is usually the sensible way to run it. That might mean production and quality first, then inventory and maintenance, or rolling out site by site, or both.

What I'd avoid is treating the first site as a trial that has to earn the next. Make the decision once, at company level, then plan the phases. A strategic decision gets real executive attention, and executives who've committed to it make sure it succeeds. It also makes the programme company-wide, so you get standards and benchmarking across sites, and a stronger centre of excellence. And nobody has to persuade each factory to take it on, because it's the company's strategic direction.

Sometimes a bigger bang is right, depending on the situation. Either way, think big and start pragmatically. Have the end state in mind even if you are starting smaller.

Later sites, in parallel

Once the template is in place, you don't have to roll out one site at a time. Group sites into batches, and bring their teams together for training and for reviewing and managing master data. Then either go live in parallel, or stagger the go-live weeks across the batch.

Over time, your own team should be able to run most of these rollouts, if not all of them, if you want to. You don't have to. You can also choose a systems integrator or the vendor to do everything.

The most important variable is you

A good vendor or partner will guide you through the challenges. But the biggest factor in how long it takes is how ready you are: how clear your requirements are, how strong your team is, and how willing you are to change your processes.

How long did your first MES project take, and what would you do differently?

Downtime is usually the biggest loss in OEE. For most manufacturers it's the single largest area for improvement. That makes maintenance one of the most valuable pillars of MOM, and one of the most overlooked.

What maintenance covers in MES/MOM

• Equipment and asset hierarchy. Sites, areas, lines, machines and their components, structured so data rolls up properly.
• Fault reporting. Operators raise issues from the screen they already use, linked to the machine and the order that was running.
• Work orders. Corrective, preventive and condition-based, with tasks, parts and sign-off.
• Planned maintenance. By time, by cycle count, or by condition, scheduled around production rather than against it.
• Autonomous maintenance. Cleaning, lubrication, inspections and checks carried out by operators.
• Maintenance KPIs. MTBF (mean time between failures) and MTTR (mean time to repair) by asset, line and reason.

Production and maintenance need the same data

This is the main reason I believe maintenance belongs in MOM.

Production and maintenance both care about downtime. If production records stops in one system and maintenance logs faults in another, they'll disagree about what happened. How can you have a productive morning meeting when the two teams can't even agree on how long the machine was stopped?

When both work in the same platform:

• The stop production sees is the fault maintenance sees, with the same duration and reason.
• Maintenance can see the production schedule and plan repair windows around it.
• Production can see upcoming planned work and prepare for it.
• Every repair is linked to the stops it fixed, so you can tell whether it worked.

Operators are part of maintenance now

Day-to-day asset care is increasingly the operator's job. That's a good thing. Operators notice problems first.

But it means operators need, in the same place they run production:

• Their autonomous maintenance tasks, at the right time
• The upcoming planned maintenance on their equipment
• Issues already logged against their assets, so they don't log them twice
• A fast way to raise a new fault, with photos if needed

If that sits in a separate CMMS, it's another login and another screen. Adoption usually suffers.

When an EAM makes sense

MOM's maintenance capability covers the ground a CMMS would. An EAM is a different case.

A full EAM (Enterprise Asset Management) system makes sense for asset-heavy businesses with advanced needs, and it's where asset lifecycle and financial data belong, rather than in MOM. Typical needs include complex spare parts management, reliability engineering, linear assets and regulatory asset records across many sites.

It doesn't always have to be a separate EAM. ERP can do a fair amount of this too. Most ERPs already hold the asset register, depreciation, capital projects and maintenance costs, and some include a full EAM module. Check what your ERP covers before buying another system.

The step towards predictive maintenance

Getting maintenance onto the same data as production is also the foundation for condition-based and predictive maintenance. Models need failure history, condition data and operating context together. I cover the journey in Predictive maintenance needs data you aren't collecting yet.

My view

A good MES/MOM with maintenance capability replaces the need for a CMMS. For asset lifecycle and financials, look to your ERP first, and only add an EAM where asset management genuinely goes beyond what MOM and ERP cover together. If you do, draw the boundary carefully, so operators and production still see downtime and maintenance status in MES/MOM. Running a MOM and a CMMS side by side just creates another interface, and another version of the truth.

If your MES covers production only, it can feed a separate CMMS, but a full MOM is the better overall solution.

This article is part of the MES functionality in depth learning path.

Do your production and maintenance teams agree on last week's downtime?

They don't.

I see it all the time. Traceability at order or batch level in ERP, often with backflushing. It's better than nothing. But it's nowhere near what's possible, and you usually find that out on the worst possible day: when a recall or a serious complaint lands.

What ERP traceability usually gives you

ERP typically knows that a production order consumed certain materials and produced a certain quantity. With backflushing, consumption is often calculated from the bill of materials after the fact, not recorded as it happened.

So you know roughly what went into an order. You don't know exactly which lot went into which part of it, when, or under what conditions.

ERP does that business-level job well, and some ERPs go further on traceability than others. For a straightforward product with low risk, that may be enough. For most manufacturers, a proper MOM gives the most detailed view.

What full traceability looks like

With MES/MOM, traceability can go much deeper. It tracks the tooling, process parameters, quality checks and the skills of the people doing the work, alongside a far tighter record of what was made, when, and from what. Start with the genealogy:

• Serialised items, tracked individually
• Specific lot quantities, so you know exactly how much of each lot went into each output
• Exactly what was created, and when, so the window you search when tracing backwards or forwards is as tight as possible
• Time-based traceability for continuous processes, matching the materials consumed in a time window with the output produced in that window, offset by the time material takes to travel through the line
• Bi-directional tracing: forwards from a raw material lot to every finished product it touched, and backwards from a finished product to everything that went into it

That's the genealogy. But it's only the start.

The supplementary data is where the real value is

The difference between adequate and excellent traceability is everything you capture alongside the genealogy:

• Tooling used at each operation
• Quality results at every level: goods-in inspection, in-process checks, final inspection
• Context: operator, timestamp, machine and machine position
• Skills of the people who did the work, and whether they were certified for it at the time
• Process parameters at the time the item or batch was made: temperatures, pressures, speeds

When a quality issue is detected, this is what makes root cause analysis straightforward instead of guesswork. You can see that every failed part came from the same cavity of the same mould, during the same two hours, when the temperature drifted.

Why it matters in a recall

Picture a complaint arriving on a Friday afternoon.

With order-level ERP traceability, you know which orders might be affected. You quarantine everything from that period to be safe. You spend the weekend in spreadsheets and paper records trying to narrow it down.

With full traceability, you trace the affected lot forwards in minutes, identify exactly which finished products contain it, check their inspection results and process conditions, and quarantine only what's genuinely at risk.

Speed is only part of it. The bigger differences are how much good product you destroy, how much customer trust you keep, and how confident you are in front of a regulator.

Inventory and quality on the same data

This is a good example of why I care about MOM rather than separate systems.

Traceability needs inventory movements, production events and quality results linked together. If inventory lives in one system and quality in another, you can trace the material, but not easily its inspection status at each step. Every integration boundary is a place where context gets lost.

When they share one platform, an inspection result is attached to the lot it was performed on, and the lot is attached to everything made from it.

It still syncs with ERP

None of this replaces ERP. MES/MOM holds the detail and sends ERP what it needs, at the right level: actual consumption rather than backflushed estimates. ERP's data gets better, not worse. More on that in MES vs ERP.

A simple test

Pick a finished product shipped last month. Ask your team how long it would take to tell you every raw material lot in it, the inspection results at each stage, and the machine conditions when it was made.

If the answer isn't measured in minutes, your traceability isn't as good as you think. If it is, congratulations. You're in the minority.

When did you last run a mock recall, and how long did it take?

If there's one phrase that captures what a smart factory is really about, it's that. PLCs, sensors, historians and IIoT platforms all generate enormous amounts of it.

But data on its own is worthless. What matters is the context around it.

A signal is not information

At the bottom of the stack you've got raw machine data. A PLC sends a signal every time a machine cycles. A temperature sensor reports every second. A proximity switch fires when a product passes.

This data is accurate. It's real-time. And it's completely meaningless on its own.

A signal that says "machine stopped" tells you nothing useful. When did it stop? For how long? Was it during a run or between orders? What was being made? Who was on shift? Why did it stop?

Context turns a signal into something you can act on

The same event, contextualised:

Machine 3 on Line 7 stopped at 14:23 during production order 4521, while making material X, on shift B. The stop lasted 12 minutes. The reason was a jam at station 2. It's the third time that reason has occurred in 48 hours.

Same signal. Completely different value.

Contextualised data is data that's been enriched with the who, what, when, where, why and how. That's what makes it useful for analysis, decisions and AI.

From signal to decision

The journey looks like this:

1. Raw signal. The machine stopped.
2. Contextualised data. Which machine, order, product, shift, reason and duration.
3. KPIs. OEE, availability, scrap rate, MTBF, energy per piece.
4. Dashboards. What's happening now, and what happened last shift, last week, last month.
5. Decisions. Replace the tool causing 40% of rejects on Machine 3. Change the maintenance interval on Line 7. Look at why Friday nights underperform.

Each step adds meaning. And each step depends on the one before it. You can't calculate a trustworthy OEE from signals nobody has put in context.

Where context comes from

On the shopfloor, context comes from the system that knows what's supposed to be happening: the production order, the material, the routing, the operator, the quality plan.

That's MES/MOM. It's the central hub of contextualised operational data, sitting between ERP above and the machines below. It takes the raw signal and attaches everything around it.

Where context gets lost

This is where I get opinionated.

The broader the scope of MES/MOM, the richer the context. Production, quality, inventory and maintenance overlap constantly:

• A quality failure links to the production order, the raw material lot and the process parameters at the time.
• A machine stop matters to production, maintenance and planning.
• Material consumption ties to equipment performance and yield.
• A tool change explains a shift in dimensions on the parts that followed.

When those live in one application, every piece of data carries all of that context automatically.

When they're spread across separate systems and integrated, you lose some of it at every boundary. You can't pass everything through an integration, so you pass a subset. The quality system knows a sample failed, but not what the machine was doing. The CMMS knows a fault was logged, but not that the line was mid-changeover.

Integrating separate applications nearly always loses some context. A well-designed integration layer can carry more of it, but someone has to model that context and keep it consistent. In a single platform it's there by default. I compare the approaches in Code, build, stitch or configure.

Context is what AI really needs

Everyone wants AI on the shopfloor. Very few have the data to feed it.

Machine learning models learn from patterns. Give them context-free signals and the patterns they find are shallow. Give them stops linked to products, shifts, materials, maintenance history and quality outcomes, and they can start to find causes, not just correlations.

That's why I see MES/MOM as the foundation for AI. It creates the contextualised data set that makes AI worth doing.

Where the data lives after that

The contextualised data lives in MES/MOM for as long as you need it. Analytics and AI teams often also work from a data lake, or use a data fabric, to bring it together with data from ERP and other sources across many sites. I explain how those fit together in Historians, data lakes and data fabric.

But the context is created at the point of work. If it isn't captured there, no data platform downstream can invent it later.

How much of the data in your factory today would pass the "Machine 3 on Line 7" test?

Otherwise you'll just digitise a mess. And if you digitise a broken process, you get a faster broken process.

It's easy to skip this work, and it makes a big difference.

Same product, different process

It's very common to find two factories making the same product, using different processes. Not slightly different: different routings, different quality checks, different changeover steps, even different words for the same thing.

It's not just between sites. Inside one factory, day shift and night shift often do things differently. Both acceptable, so nobody questions it. But the data isn't comparable, and nobody can say which way is better.

Processes evolve organically. Someone finds a quicker way. A supervisor's workaround sticks. Over the years, the "official" process bears little resemblance to what actually happens.

You can't standardise what you haven't documented. And you need to decide which process to digitise before you build it into software.

Start with the physical structure

Map the skeleton first, top down: enterprise, site, area, line, machine.

It sounds basic, but agreeing this hierarchy early saves a lot of pain later. It's what your process maps, your data and your reports will all hang on.

Then map what actually happens

Map what really happens, warts and all, rather than what the manual or the ISO documentation says.

The tool I like for this is a swimlane diagram, with a twist:

• Across the top, a lane for each department or system: ERP, production, quality, inventory, maintenance, automation.
• Down the side, a lane for each manufacturing process: cutting, welding, mixing, painting, assembly, packing.

That gives you a grid. Each activity sits in the cell where that department meets that process.

Take welding as an example. Material is delivered to the line (inventory). Orders are released (ERP). The order is started and the machine changed over (production). Input material is consumed (inventory). An in-line check is performed, with rework if it fails (quality). Counts are recorded (production). Finished material is labelled (inventory). ERP is updated.

Lay it out like that and the invisible becomes visible. You see every handoff, every place information has to move between people or systems, and every gap.

Involve the people who do the work

Map with operators, quality technicians, maintenance engineers and logistics, not just managers.

They know the workarounds. They know the tribal knowledge. They know the step that's in the procedure but never happens, and the one that always happens but isn't written down anywhere.

And be honest. If the map is messy, that's what you're going to fix. A perfect-looking diagram of a process that doesn't exist is counterproductive.

Then question everything

Once you've mapped the as-is, ask of every step:

• Why do we do it this way?
• What would happen if we stopped?
• Does it add value, or just time?
• Is it a genuine requirement, or someone's preference?

You'll hit resistance. "We've always done it this way." "Our process is different." Sometimes that's true. Most of the time it's habit. More on that in Configure, don't customise.

Design the to-be, for the operator

The to-be process isn't the as-is with a screen bolted on. It should be simpler, more standard, with technology reinforcing it.

Design it for the person doing the work. If your new process takes twelve clicks to replace two seconds on paper, you've gone backwards.

Why it pays back

Doing this upfront:

• Makes your requirements specific, so your RFP is focused and vendors can respond properly
• Reduces customisation, because you've simplified before you build
• Speeds up implementation, because the configuration team knows exactly what to build
• Gives you the basis for testing and training

Skip it, and you'll do the same work later, during the project, with the clock running and the services bill growing.

When did you last map what really happens on your shopfloor, rather than what the procedure says?

The trouble is that most ways of answering it invite flattery. Ask a leadership team to rate its own maturity and the answer usually matches the last board presentation, not the shopfloor.

So I prefer to start with a real example. Something like this:

Line 3 stops at 02:14. A bearing has been running hot. When does the right person find out, and do they know why?

Follow one event like that through the factory and you learn more than any framework slide will show you. I call it time to truth: how long it takes your factory to know what really happened, with enough context to act on it.

Eventually: paper and Excel

The operator writes "machine fault, 40 minutes" on a downtime sheet. The sheet goes in a tray. At some point someone types it into a spreadsheet, if it gets typed up at all.

By the time anyone looks, the detail has gone. Which bearing? Was it the third time this month? Nobody can say, so the same failure happens again. And because every department keeps its own spreadsheet, every department has its own version of the number.

How you'll recognise it: travellers on clipboards, downtime on a whiteboard, and a morning meeting that starts with someone reading out yesterday's numbers from a notebook.

End of hour or shift: ERP on the shopfloor

Production and scrap are typically booked into ERP at a terminal every hour, or at the end of the job or shift. It's a real step forward. The quantities are in the system of record, and finance can cost the order.

The truth arrives when someone books the confirmation. You know how many were good and what it cost. You don't know why 40 were scrapped or why the line stopped, because ERP's job is running the business. Watching what happens between an order starting and finishing is a different job.

How you'll recognise it: accurate order totals, and nobody able to explain them.

After the fact: digitalised

Tablets replace the clipboards, and point solutions arrive: an OEE tool on a couple of lines, a checklist app, a maintenance app and a quality tool. Data still gets typed in by hand, and the tools don't talk to each other.

The truth arrives sooner, but always after the fact. Someone keys it in once the stop is over, from memory or a scribbled note, so it's rounded. The short stops never make it in, and the downtime record doesn't know which order was running.

How you'll recognise it: an app for every department, and a weekly report someone builds by copying between them.

Right now: automatic data capture

The data stops being typed in. This is usually where MES/MOM arrives as the operational backbone, bringing production, quality, inventory and maintenance onto the same data and connecting the floor to ERP.

The stop is logged at 02:14 from the machine itself. The operator picks a reason at 02:16. The order and the material are already attached, because the system knows what was running.

How you'll recognise it: operators work from one screen, and nobody argues about the numbers any more.

Before it happens: harmonious systems

A connected business. MES/MOM, ERP, PLM, scheduling, quality and data platforms work as one deliberate architecture. Each system does its own job and shares what it knows, and sensor coverage grows.

Now the bearing's temperature trend raises a warning at 23:40. Maintenance changes it during a planned stop on the night shift. Line 3 never goes down.

How you'll recognise it: maintenance gets scheduled because the data says so, not because the calendar does.

Before anyone asks: agentic, human in the loop

AI agents work on trusted, contextualised data, and prepare the decision before anyone thinks to ask for it. An agent spots the bearing trend, raises the maintenance work order with the spare part reserved, and books it into the next planned stop. A supervisor approves it in seconds, with the facts in front of them.

People stay in control. And every approval teaches you something: the recommendations people accept unchanged, week after week, are the ones you can start to trust on their own.

How you'll recognise it: decisions that used to take a meeting take a click.

Without asking: autonomous

Agents make routine decisions on their own, inside limits the business has agreed. An agent re-sequences tomorrow's schedule around a late delivery and tells the planner what changed. People set the rules, handle the exceptions and review the rest when they choose.

Autonomy here is earned decision by decision. It's never switched on for the whole factory at once.

How you'll recognise it: honestly, you probably won't yet. Very few factories are genuinely here, whatever their marketing says.

AI adds value at every stage, but the value compounds

You don't have to wait for "without asking" to get value from AI. What changes from stage to stage is how much it can do.

With paper and Excel, the value is low. AI can help you read the data you have, but it can't analyse what was never captured. An AI assistant on a spreadsheet can tidy it up and chart it more clearly, and that's about it.

With ERP on the shopfloor, AI can spot trends in the totals, but it can't explain them without shopfloor context. AI can find trends in transactional data and forecast from them, such as a product whose scrap cost is creeping up across orders. But it sees totals rather than causes, so it can tell you what happened far more often than why.

With digitalised point solutions, it's modest. AI can make sense of data people enter by hand and spot patterns across disconnected tools, for example grouping free-text downtime notes into common causes. It's held back by data that's rounded and keyed in late.

From stage 4 onwards, the value of AI climbs much faster. Once the truth arrives "right now", with its context, AI can learn from your own operations, spotting anomalies and finding root causes. A copilot can explain why Line 3 stopped from the facts, not a guess. With harmonious systems it predicts and optimises across the whole stack, because planning, engineering, quality and maintenance data finally line up: maintenance is planned from the bearing's condition, and the schedule moves around it. At "before anyone asks", agents prepare the action and people approve it. And at "without asking", AI acts on routine decisions within agreed limits.

AI adds value at every stage, but the biggest gains come in the later ones. That's why AI and the data belong in the same plan, from the start. Prediction needs history, and history needs data captured accurately and automatically, with its context. Put AI to work at whatever stage you're at, and let it pull the data forward: every gap it runs into tells you what to capture next, and every stage you move up makes it more capable. I go further into this in AI will transform your factory, if you give it the right data.

Where most factories are

Most factories I see sit somewhere between "eventually" and "after the fact". A few are genuinely "right now" across the board. The jump to right now is usually the biggest single step in value, because it's where data becomes trustworthy and departments start working from the same picture.

Your factory has a shape, not a single answer

This is the part a single maturity score hides. Time to truth is rarely the same everywhere.

It's common to find machine stops logged "right now" while quality checks still arrive "eventually" on paper. Or a plant with excellent dashboards and nobody who owns the process behind them. One site can be well ahead of another in the same group.

The slowest area sets the pace. Fast machine data doesn't help much if the reason, the quality result or the person who should act on it arrives a day later.

So ask the question area by area: process, data, systems, people, and analytics.

How to use it

Ask it at the next leadership meeting. Pick a real event from last week, a stop or a quality escape, and trace when each person learnt about it, and what they knew.

Then ask it on the floor. You'll usually get two different answers, and the gap between them is where the work is.

So, if Line 3 stopped at 02:14 tonight, when would you know?

It's one of the most common questions in manufacturing, and the answer has a big effect on which systems fit.

The simple version

Discrete: the final product could, in theory, be taken apart back into its components. A bike.

Process: no matter what you do, you can't get back to the raw materials. A cake. You're never getting that egg back.

That's the core idea. In practice each side splits into a few types, and plenty of factories run more than one.

Discrete manufacturing

Individual, countable items. You count pieces, and often track serial numbers. Within discrete, there are distinct patterns.

Repetitive. The same or similar products run continuously on dedicated lines at high volume. Think automotive components, consumer electronics, white goods or packaged goods. Performance is about line rate and OEE.

Job shop or high-mix, low-volume. Many different products in small quantities, each following its own route through shared machines. Think machining or fabrication. Changeovers and scheduling are the big challenges.

Assembly. Components brought together into a finished product, from simple kits to complex machines. Getting parts to the line when they're needed, in sequence, matters most, along with recording which components went into which unit.

Process manufacturing

Materials are transformed: mixed, blended, heated or reacted. You measure in kilograms and litres, not pieces. Recipes and formulations matter, and natural variation in raw materials means yield varies too.

Batch. A defined quantity is made in one run, following a recipe, and the whole batch is treated as one unit for quality and traceability. Common in food, pharmaceuticals, cosmetics and speciality chemicals.

Continuous. Material flows through the process without stopping, often 24 hours a day, for weeks or months. Think refining, paper, steel, extrusion or bulk chemicals. Stopping is expensive, so stability and process control are everything, and traceability is often time-based rather than by lot.

Mixed-mode

Many manufacturers don't fit one category. A food company mixes a batch (process), then fills and packs it into cases (discrete). A plastics company runs a continuous extrusion line that feeds discrete cutting and packing.

Mixed-mode is common, and the handover points between modes are where systems are most tested.

Side by side

A separate question: how you respond to demand

People often mix manufacturing type up with production strategy, which is a different axis:

• Make to stock: build ahead of demand to forecast.
• Make to order: build once the customer orders.
• Configure to order: build a standard product with customer-chosen options. More in From CPQ to the shopfloor.
• Engineer to order: design and build something unique for each customer.

A job shop can be engineer to order, and a repetitive line can be make to stock. Both axes shape what you need from MES/MOM.

Why the type matters for MES/MOM

The type of manufacturing shapes almost every decision in a project.

Process design. Repetitive lines think in rates. Job shops think in routings. Batch thinks in recipe steps and parameters. Continuous thinks in stability over time.

Data and KPIs. Units of measure, how you calculate yield, how traceability works (serial, lot or time-based), and which quality checks matter.

Operator screens. A discrete operator wants to see the next part and its count. A process operator wants the current recipe step and its parameters. Same system, very different screens.

Technology choice. Not every MES handles every type well. Some were built for discrete and stretched into process, or the other way round. You'll feel that in unit-of-measure handling, recipe management, traceability and mixed-mode handovers.

What to ask a vendor

Pin this down early in any evaluation:

• Can you show me my type of manufacturing running in your system, not a similar one?
• How do you handle mixed-mode, where one line is process and the next is discrete?
• How do units of measure convert between operations, from kilograms in to cases out?
• How do you handle time-based traceability on continuous lines?
• Is all of that done through configuration, or customisation?

My view

I've been explaining MES for well over a decade, and this question matters more than people realise. Mixed-mode is far more common than most software brochures suggest. I'd look for a platform that handles every mode across the enterprise through configuration. If a vendor needs custom work to handle your basic manufacturing type, that's a warning sign. More on that in Configure, don't customise.

How would you describe your own manufacturing: one type, or a mix?

The short answer

• MES (Manufacturing Execution System) is the production pillar: executing orders, recording counts, scrap and downtime, and calculating OEE.
• MOM (Manufacturing Operations Management) covers the whole operation: production, quality, inventory and maintenance. A MOM platform does all four on the same data.

MES is one part of MOM. Not a synonym for it.

Where the terms came from

MES is the original term. Early systems focused on the production process: release the order, run it, record what happened.

Over time, many systems grew. They took on quality, inventory and traceability, maintenance, logistics, tooling, energy, skills. At that point "execution system" didn't describe what they did any more, and MOM emerged as the more accurate name.

The ISA-95 standard defines four areas of manufacturing operations management: production, quality, inventory and maintenance. That's the MOM scope.

Side by side

Why the distinction matters

The scope decides whether everyone in operations works from the same data.

Production and maintenance both care about downtime. Quality needs to know what's being produced and from which material. Inventory needs to know whether a lot has passed inspection. And the operator does a bit of all four, often in the same ten minutes.

With a MOM platform, that's one system and one source of truth. The downtime production sees is the downtime maintenance sees. Quality checks are triggered by what's actually running. Traceability links every lot to its inspection results and process conditions.

One platform, or a system per pillar?

The alternative to a MOM platform is a separate system for each pillar, integrated together: an OEE tool here, a quality system there, inventory in ERP, a CMMS for maintenance.

The trade-offs:

• Context is lost at each integration. Usually only a subset of the data passes across, by design, so some context stays behind in each system.
• Integrations need maintaining. They need retesting with every upgrade on either side.
• Operators may juggle applications. Different logins, different screens.
• Data can diverge. Two systems can hold different versions of the same downtime or stock.

What to ask a vendor

Because "MES" gets used loosely, the label tells you very little. Ask instead:

• Which of production, quality, inventory and maintenance do you cover natively?
• How deep does each one go? Show me, don't tell me.
• Do they share one data model, or are they separate products integrated together?
• What does the operator see: one application, or several?

Those answers tell you far more than whether the brochure says MES or MOM.

Which term should you use?

Use whichever your audience understands. MES is still the more common search term.

On this site, MES means production execution, MOM means the whole operation, and MES/MOM means the category. For the full picture of what each pillar does, start with What is MES/MOM?

My view

A good MOM platform replaces the need for a separate QMS or CMMS. You may still need an EAM or a LIMS, depending on your industry and regulations. Dedicated systems should be deliberate choices about depth, with clear boundaries. What I'd avoid is drifting into four point solutions because each one fixed a single problem quickly.

When you look at your own factory, how many systems does it take to cover those four pillars today?

I genuinely saw "Industry 6.0" on LinkedIn recently, and it made my blood boil. We shouldn't need a version number to describe something's value. We should be able to say what it actually does.

So, labels aside, this is the definition I use.

A smart factory is a manufacturing environment where people, processes and technology work together, supported by data, to maximise efficiency, flexibility and quality.

No magic, and no science fiction. The right information reaches the right person at the right time, and decisions are based on facts rather than gut feel.

Why the old way is breaking

Manufacturing has always been complex. Planning, execution, quality, maintenance, inventory: none of it is new.

The old way of managing that complexity worked. Experienced people, informal communication, local decisions. The operator who tweaks the machine by ear. The supervisor who just knows. The engineer who can hear a bearing going.

It worked because the environment was stable. Fewer products, predictable demand, reliable supply, a workforce that stayed for decades.

That stability has gone. Customers want more variety, faster, with full traceability and on time every time. Costs are up across materials, energy and labour. And the experienced people who held it all together are retiring, taking the knowledge with them.

The complexity hasn't changed much. The capacity to cope with it informally has run out.

Five things that define a smart factory

1. Defined processes. Clear, documented processes that make expectations, handoffs and exceptions explicit. Not tribal knowledge. Not "ask Dave, he knows how it works." Processes anyone can follow, enforced by the system, consistent across shifts, teams and sites.

2. Planning connected to execution. Not a schedule thrown over the wall and hoped for the best. A two-way link: the schedule reflects what's actually happening on the shopfloor, and the shopfloor sees what's coming next. When a machine goes down, the planner knows immediately.

3. Real-time data at the point of work. Timely, contextualised information where the work happens. Not just machine data. Work instructions, specifications, drawings and SOPs too, always the latest version. The operator shouldn't have to go looking.

4. Decisions made from a single source of truth. When the morning meeting starts, the data is already there. Nobody spent two hours pulling it together from spreadsheets. AI supports more of those decisions as the foundation grows, and the two develop together. Generative AI can help from day one, with procedures and know-how. AI that predicts and optimises operations learns from the data, so it gets more capable with every line you connect.

5. People backed to make the call. Supported by structure, not relying on heroics. When processes are clear and systems are connected, people stop firefighting and start improving.

Notice that only one of those five is really about technology. That's deliberate.

A smart factory doesn't reduce complexity

I think this gets overlooked.

A smart factory doesn't make manufacturing simpler. The complexity is what it is. What it does is increase your capacity to handle it. Those five things create coordination capacity the informal model never had.

What it actually delivers

Everything comes back to two things: selling more, or improving margin. Ideally both.

In practice that shows up as:

• More from the equipment you already have. Accurate downtime and micro-stops, visible for the first time. Customers are genuinely surprised by how much capacity was hiding.
• Better quality. Real-time SPC catches drift before it becomes scrap.
• Lower inventory. When you trust the data, you stop carrying buffers to cover for not trusting it.
• Traceability in minutes. A complaint that took days to investigate takes minutes.
• Proactive maintenance. Condition data instead of the calendar or the breakdown.
• Faster onboarding. New starters guided by the system rather than shadowing someone for months.

The research backs this up. In Deloitte's 2025 Smart Manufacturing Survey of 600 large manufacturers, respondents reported average improvements of 10% to 20% in production output, 7% to 20% in employee productivity and 10% to 15% in unlocked capacity (Deloitte, 2025).

It's a mindset, not a technology project

If you take one thing from this article, take this.

I've seen it too many times. A company buys software, expects everything to change, and six months later nothing has. The technology didn't fail. The approach did.

A smart factory means getting process, technology and people right together, and keeping them aligned:

• Process gives you structure: how work flows, end to end.
• Technology gives you scale: it supports and enforces those processes.
• People give you adaptability: judgement, improvement, problem-solving.
• Data is the foundation underneath all three.

Strengthen one and neglect the others, and you just move the imbalance somewhere else. Technology on top of undefined processes is an expensive way to automate chaos.

Where MES/MOM fits

On the shopfloor, MES/MOM is the system that makes most of those five things real. It runs the defined processes, connects planning to execution, puts real-time data at the point of work and creates the single source of truth. It's also where most of the data that AI depends on comes from.

It isn't the whole smart factory. ERP, PLM, connectivity, data platforms and analytics all have their place, and I break down the full picture in The smart factory tech stack. But it sits at the heart of it.

Where to start

Be honest about where you are today. Asking how long your factory takes to know what happened is a good way to do that. Then pick the problems that hurt most. You have the option to start as big or small as you like, but always start with the end in mind.

Everyone wants to cross the finish line without running the race. The manufacturers who get there are the ones who start running.

So, which of those five does your factory struggle with most?

This article looks at the main challenges, and where shopfloor systems such as MES/MOM help.

Food safety and quality

Food safety is the top priority. A lapse can put consumers at risk, and a single recall brings the cost of withdrawn product and lasting damage to a brand.

Control has to run from the arrival of raw ingredients to the finished pack. That includes allergen management and accurate labelling, all within changing regulatory requirements. More in allergen management.

Waste and give-away

Ingredient and energy prices move with global markets, and demand shifts with seasons and trends. Waste in food and beverage takes many forms:

• Spoilage of perishable materials
• Energy lost in heating and cooling
• Over-production that expires before it's sold
• Batches reworked because they missed specification on taste or appearance

Give-away, product packed above the declared weight to stay safe, is a particular issue. Small amounts per pack add up across millions of units. More in give-away.

Yield and recipe control

Yield from raw materials is often the largest single profit driver, so small improvements can have a large return. Manual processes add variability: inconsistent weighing, and recipes adjusted from experience rather than data.

Workforce and skills

Attracting and keeping skilled people is hard across manufacturing, and food and beverage is no exception. Modern equipment and precise processes need people who follow the right procedure every time. Paper-based training and instructions slow down onboarding and make consistency harder, which leads to errors and lost productivity.

Supply chain resilience and traceability

Food and beverage supply chains are often complex and global. Geopolitical events and sudden shifts in demand can disrupt ingredients or packaging.

End-to-end traceability, from farm to fork, helps manage those risks. It helps detect food fraud, and allows a fast, targeted response when there's a quality issue. More in Lot vs batch vs serial traceability.

Where MES/MOM helps

Precise traceability also narrows recalls. When the system knows exactly which batches used an affected lot, fewer batches need to be recalled. Real-time inventory and production status feed better supply chain planning too.

Usability matters for adoption, particularly with younger operators: intuitive, mobile-friendly screens are more likely to be used consistently. More in Connected worker vs MES.

Before starting a project, read The biggest barriers to MES success in food manufacturing. The food and beverage page collects the most relevant articles and tools.

My view

In food and beverage, I'd look first at yield and give-away, because that's where small improvements pay back fastest. A strong MES/MOM foundation helps food and beverage manufacturers move from reacting to problems to preventing them, which is what keeps consumers' trust over time.

Which of these challenges is costing your plant the most today?

Work it out for your bottleneck. More output from equipment you already own, and perhaps a capital project you no longer need. For most manufacturers it's a significant number. The 1% OEE calculator does the sums for you.

Well-implemented programmes often go well beyond 1%. In Deloitte's 2025 Smart Manufacturing Survey, large manufacturers reported average improvements of 10% to 20% in production output and 10% to 15% in unlocked capacity from smart manufacturing initiatives (Deloitte, 2025).

Where the savings come from

Less downtime, more output. Downtime is usually the biggest loss in OEE. Automatic stop detection and accurate reasons show exactly where capacity goes. Short stops are often the biggest surprise, because they rarely make it onto paper. More in What is OEE?

Less scrap and rework. Real-time quality checks and SPC catch drift before it becomes defects, and error-proofing stops the wrong material being used. Every scrapped part also wastes the machine time and energy that went into it. See SPC on the shopfloor.

Less time on admin. Hours go on paperwork and chasing information. Digital capture gives that time back.

Lower inventory and WIP. When real-time stock data can be trusted, the buffers held to cover for not trusting it can come down. That frees working capital.

Faster, narrower recalls. With full traceability, you can identify exactly which products are affected and quarantine only those, instead of everything made in a week. See Your traceability probably isn't as good as you think.

Better ERP data. MES/MOM posts actual consumption and scrap back to ERP, rather than backflushed estimates, which improves costing and reduces surprises at month end. More in How MES takes complexity out of your ERP.

Lower energy cost. Linking energy to machines and orders exposes idle running and waste. See MES functionality: energy.

Benefits that are harder to put a number on

• Happier customers, from better quality and more reliable delivery
• Faster onboarding, because the system guides new starters
• Fewer arguments, because everyone works from the same data
• Less firefighting, so people can work on improvement instead
• A foundation for AI, which depends on the contextualised data MES/MOM creates

Include these in a business case, but lead with the hard numbers. Finance teams fund what they can measure.

The benefits grow over time

Think about your first smartphone. You probably bought it to make calls. Today, making calls is one of the least important things you use it for.

MES/MOM often follows a similar pattern. Manufacturers usually invest for one or two reasons, such as efficiency or compliance. Those who adopt it fully tend to find more value each year, as they use more of the data and extend into new areas. And much like a mobile phone, once you're used to everything MES/MOM does, it's hard to imagine going back to not having one.

Turn it into a business case

1. Quantify current costs: downtime, scrap, overtime, late deliveries and inventory.
2. Estimate realistic improvements for each, based on your own data.
3. Count the costs honestly, including your own people's time and ongoing support.
4. Make it one decision for the whole programme, and phase the delivery.

How to build an MES business case leadership will sign walks through it in detail. What the research says about smart factory ROI pulls together the wider evidence.

My view

I've seen companies pay for their MES in months rather than years, on tangible benefits alone. But that only happens when they've measured their own losses first. The 1% question is where I'd start every time, because it turns a technology conversation into a business one.

So, what would a 1% improvement in OEE be worth to you?

Most factories now have a continuous improvement (CI) team, or at least a CI lead. The work they do depends on facts about where time and material are lost. That's where MES/MOM comes in.

Where Kaizen came from

"Kaizen" is an everyday Japanese word for improvement. Its use as a management philosophy grew out of post-war Japanese industry, helped by the US Training Within Industry (TWI) programmes of the late 1940s and 1950s, and was refined most famously inside Toyota.

The idea reached a wide Western audience through Masaaki Imai's 1986 book Kaizen: The Key to Japan's Competitive Success. A few years later, Western researchers coined the term "Lean" to describe the Toyota approach, popularised by The Machine That Changed the World in 1990.

Kaizen started in manufacturing, but its principles are now used far more widely, in healthcare and software development among others.

The core ideas

You'll find many lists of "Kaizen principles" online. These are the ideas that turn up consistently in the original sources:

1. Continuous improvement and respect for people. Toyota describes these as the two pillars of the Toyota Way. Improvement never stops, and it's done with the people who do the work, not to them.
2. Small steps, by everyone. Many small, low-cost improvements, made continually at every level, rather than waiting for a big project.
3. Go to the gemba. The gemba is where the work happens. Regular gemba walks, where leaders walk the shopfloor to see problems or potential problems first hand, beat any report read in an office.
4. Standardise, then improve. A common saying in Lean circles: without a standard, there can be no Kaizen. You need a stable way of working to measure an improvement against.
5. Eliminate waste. Muda, the Japanese word for waste, covers anything that doesn't add value for the customer, including waiting, defects, overproduction, excess movement and excess inventory.
6. Plan, do, check, act. The PDCA cycle: plan a change, try it, check the result, then standardise it or try again.

Quality circles and suggestion schemes are two classic ways of putting this into practice. Small teams meet regularly to solve problems in their own area, and everyone is encouraged to put forward ideas, however small.

A Kaizen cycle, step by step

Finding the opportunity. Without good data, improvement teams tend to work on whatever is loudest. Automatic loss capture, including short stops that rarely make it onto paper, shows where the biggest losses really are. More in Manufacturing KPIs beyond OEE.

Understanding the process. Many CI projects start with weeks of observation with a clipboard and stopwatch. When cycle times and downtime reasons are already recorded by product and machine, that study can take hours instead. Map the process too, because data alone won't show you the workarounds. See process mapping.

Making the change stick. A new standard written on paper is easy to drift away from. Built into digital work instructions, it's the default for every shift. More in digital work instructions.

Checking the result. Improvements often fade within months of a kaizen event. With the same measures running continuously, you can see whether a gain has held, and step in when it starts to slip.

The digital morning meeting

The daily performance meeting is one of the most practical places to see Kaizen and MES/MOM working together.

In many factories the morning meeting takes a long time to prepare. Data comes from ERP, spreadsheets, separate reports and handwritten notes, and the first part of the meeting is spent agreeing whose numbers are right.

A typical agenda runs in a set order:

1. Health and safety. Accidents and near misses first, always.
2. Quality. Defects, holds and customer issues.
3. Performance. Output, OEE and the biggest downtime losses.
4. Big issues and projects. Anything that needs escalating or a decision.
5. The day ahead. What's planned today, and what could get in the way.
6. Actions. New actions logged with an owner, and last time's actions followed up.

With connected operations, the meeting runs from one screen that follows the same agenda, with yesterday's data already in it. Nobody needs to prepare it.

Actions are logged against the data that prompted them, and the open ones come back at the next meeting until they're closed, so you can see whether they worked. That's PDCA running every day. More on the data behind it in Time to truth.

Benefits and challenges

MES/MOM doesn't solve the cultural challenges. It does make the results visible, which helps keep momentum going.

My view

Kaizen needs facts, not opinions. The best CI teams I've worked with spend their time improving rather than collecting data, and that's only possible when the shopfloor data is captured automatically and trusted by everyone. A good MES/MOM won't create a Kaizen culture on its own, but it removes a lot of the friction that kills one.

How much of your CI team's time goes on gathering data rather than acting on it?

Putting manufacturing execution into MES/MOM, alongside ERP, usually simplifies ERP and improves the data it holds. This article explains why.

What each system is built for

ERP manages and integrates the core business: finance, sales, purchasing, planning and inventory valuation. It gives the organisation one platform for business data, and it's the backbone of most manufacturers. More in What is ERP?

MES/MOM is built to run manufacturing operations. It captures data from the shopfloor as things happen, and guides operators through the work. It sits between ERP and the equipment. More in What is MES/MOM?

Why ERP struggles on the shopfloor

ERP is excellent at business processes, but it isn't designed for the granular, real-time detail the shopfloor needs. Forcing it to cope usually means custom code and workarounds, which make ERP harder to maintain and upgrade.

User experience suffers too. ERP screens are designed mainly for office users, not for an operator wearing gloves at a machine.

The shopfloor is fast-moving, with many machines and people working together. Capturing what happens there, from machine status to material consumed by lot, needs a system built for real time. That's the job MES/MOM is designed for.

The shift towards a focused ERP

Expectations of ERP have changed. Gartner's idea of "composable ERP" describes ERP as a strong core that integrates with specialist applications, rather than trying to do everything itself.

Shopfloor execution is one of those specialist areas, and it's best practice for MES/MOM to handle it. Keeping it out of ERP also simplifies ERP deployments and roll-outs, and lowers its cost of ownership.

It also means choosing the right application for each area. Some vendors offer both ERP and MES/MOM, and many manufacturers successfully run ERP from one vendor and MES/MOM from another. Either way, the integration between them deserves careful attention:

• Building and maintaining the interface. Orders, master data, confirmations, consumption and stock movements all have to flow reliably, in both directions.
• Upgrades. Every upgrade on either side means retesting the integration, and the two roadmaps won't always line up.
• Ownership when something breaks. When a confirmation goes missing, someone has to own the problem end to end.
• Master data alignment. Materials, BOMs, routings and units of measure have to mean the same thing in both systems.

Standard integrations from a single vendor can remove much of that effort. Where the systems come from different vendors, standard interfaces and an experienced integration partner do the same job. More in integration patterns and Your ERP master data isn't ready for MES.

MES removes the need for ERP extensions

Bridging ERP's shopfloor gaps often means custom extensions. They're costly to build and maintain, and they add risk at every upgrade.

With MES/MOM alongside ERP, both systems can run closer to their standard functionality. Where a manufacturing process does need something specific, MES/MOM is the natural place for it, because it owns that process. MES/MOM platforms are usually designed to be configured for different processes, which makes shopfloor changes quicker, without touching ERP. See Configure, don't customise.

ERP keeps the data it needs, and often gets better data

A common worry is that ERP loses visibility of production volumes or quality results once MES/MOM is in place. In practice ERP keeps at least the same information it had before, because MES/MOM keeps it up to date.

MES/MOM handles the high-volume, detailed data, and sends ERP what it needs, often aggregated, which also reduces the transaction load on ERP.

The quality of ERP data usually improves:

• Actuals rather than estimates. MES/MOM posts actual consumption and output, rather than backflushed standard quantities.
• More accurate costing. Real machine time and material usage replace estimates, so product costs reflect what actually happened.
• Timely updates. Production is confirmed as it happens, rather than keyed in at the end of a shift.
• Supplier quality. Inspection results on incoming material can flow back to ERP, for example where they affect what a supplier is paid.

An analogy: the menu and the fitness app

Reading the calories on a restaurant menu is like ERP on the shopfloor. It's useful, high-level information: one number per meal. For some people that's enough.

A good fitness app is like MES/MOM. It doesn't just count calories. It tracks your macros, your steps and workouts, how much water you drink, how well you slept and your heart rate, as the day goes on. On their own, each one is just a number. Brought together, they show you things you'd never spot otherwise: that you train worse after a short night, or that your energy dips on the days you skip breakfast. And it nudges you while you can still do something about it, not at the end of the month.

MES/MOM does the same for a factory. Machine states, counts, scrap, quality results, material lots, operator skills, tool life, maintenance history and energy are all captured as they happen, and all tied to the same order. Put together, they show why one line runs slower on nights, or that a defect only appears when a particular supplier's lot meets a particular mould cavity.

ERP can tell you that you made 1,000 widgets yesterday. MES/MOM can tell you that widget 847 failed its quality check at 14:32, and what needs to happen next. Manufacturing execution happens in seconds and minutes, which is why the shopfloor needs a system built for it.

Where to draw the line

A few questions help decide where a function belongs:

• Who uses it: people in the office, or people on the shopfloor?
• How fresh does the data need to be: right now, or later?
• Does it need context from the machine or the operator?
• Does it need more detail than the business needs for costing and planning?

The more answers point to the shopfloor, the more the function belongs in MES/MOM. More in MES vs ERP.

My view

I'm a fan of ERP. ERP and MES/MOM complement each other: ERP provides the plan, and MES/MOM executes it and feeds back the reality. What I'd avoid is asking ERP to run the shopfloor. You'd never use an MES to do the job of an ERP, so why use an ERP to do the job of an MES? Getting that boundary right simplifies ERP and gives it better data.

How much custom code in your ERP exists only to handle the shopfloor?

This article covers the people you need on your side, and what successful project teams tend to have in common.

Identify the stakeholders and decision makers early

Before any configuration starts, identify the people who can influence the project and involve them from the beginning. They control resources and can remove obstacles, or create them.

Executive sponsor

A senior executive with the authority to allocate resources and make strategic decisions. Enterprise MES/MOM programmes usually have one, because they're seen as strategic investments. Plant-level projects without executive sponsorship often struggle when they need budget or a decision that crosses departments.

IT

IT is responsible for the technical side: deployment options, infrastructure, integration, security and coordination with local IT at each site. Involving IT early surfaces technical constraints while there's still time to plan around them. More in IT vs OT.

Operations

Representatives from production, quality, logistics and maintenance. These are the people whose work changes most, and who know how the process really runs. Operators in particular hold detailed process knowledge that rarely appears in procedures. Without their input, requirements tend to describe the process on paper rather than the process on the shopfloor.

Your vendor or systems integrator

And of course, you'll be working closely with your vendor's or systems integrator's team throughout.

The project manager

Strong project leadership is one of the clearest predictors of success. The project manager oversees the implementation and, in multi-site businesses, the roll-out to further plants and warehouses.

It's a complex role. A good project manager typically brings:

• Domain knowledge. An understanding of MES/MOM and your production processes, including the challenges specific to your industry.
• Communication skills. The ability to manage expectations and keep stakeholders informed, including those who aren't yet convinced the project is a good idea.
• Planning discipline. A plan, built with the vendor or integrator, that sets out milestones and dependencies.
• Problem-solving. Anticipating roadblocks, and resolving issues before they cause delays.
• People management. Leading a cross-functional team, many of whom don't report to them, and keeping it motivated.
• Budget management. Tracking spend against the plan, including your own people's time, and raising overruns early.
• Risk management. A live view of risks and issues, each with an owner and a plan to deal with it.
• Time management. Keeping the plan moving and protecting the critical path.
• Scope control. Saying no, or not yet, to changes that would derail the plan.
• Supplier management. Holding the vendor and any integrators to what was agreed, and working with them as one team.

They also act as the main point of contact between the internal team, stakeholders, the vendor and any consultants.

Internal expertise

Internal process knowledge is often overlooked. Experienced people on the shopfloor know where the workarounds are, and what goes wrong at 3am.

They don't all need to be on the core team. Involve them when processes are being designed and tested, and make it easy for them to raise questions or suggestions. It improves the requirements and builds support for the change. It also lets external partners spend their time where their expertise adds the most.

Choosing your delivery partner

Your vendor or systems integrator brings the product knowledge and implementation experience. Where your own MES/MOM experience is thin, an independent consultant can also help on your side.

When choosing who you'll work with, look for:

• A track record of MES/MOM delivery, ideally in your industry
• Hands-on implementation experience, not only advisory work
• A preference for keeping the solution as simple as your processes allow
• Willingness to transfer knowledge to your own team

Vendors and their partners have usually implemented the product many times, so their experience of common pitfalls is worth using.

Roles and communication

Define each team member's role and responsibilities at the start, and share them with everyone involved. Agree how often the team communicates, and with which stakeholders. Clear ownership speeds up decisions and makes issues visible sooner.

Resistance to change

Some resistance is normal in any implementation. Address it directly:

• Explain the reasons. Show how the project supports business goals, and how it makes daily work easier. The executive sponsor can help carry that message.
• Involve people. Ask for feedback, include users in testing, and act on what they say.
• Train properly. Make sure people have the skills and support to use the new system with confidence.
• Give detractors a stake. Find the people most likely to resist, particularly anyone who built the system being replaced, and give them real responsibility for making the new one succeed.
• Celebrate progress. Recognise early wins publicly, so people can see the change working.

More in Resistance to change is guaranteed. Plan for it.

What successful teams have in common

Across successful projects, the same patterns appear:

Master data deserves a special mention. See Your ERP master data isn't ready for MES.

For multi-site manufacturers, the core team often becomes a permanent centre of excellence that owns the template and supports each new site. More in Rolling out across sites.

Give the team ownership

Provide the resources the team needs, and recognise milestones as they're reached. Teams with real ownership tend to be more committed to the outcome, and for the people involved, a successful MES/MOM project can be a career-defining experience.

Related reading: How long does an MES implementation take? and Go-live is the starting line.

My view

In my experience, the team you build matters as much to the success of an MES deployment as the platform you choose. The strongest programmes are defined at enterprise level, with a centre of excellence for global standards and stakeholders at every level across operations and IT. I can't stress enough how important it is to involve frontline workers: they're the people the system is meant to help, and they know how the process really runs.

Who on your current or next project would you least like to lose?

Large language models show why. The technology is remarkable, but on its own it would be close to useless. What made it so capable was the internet: decades of text that people put online for it to learn from. Your shopfloor data plays the same role for your factory. Give AI accurate, contextualised data about your operation and it can do remarkable things with it. Without that data, it can tell you a lot about factories in general, and very little about yours.

The slide everyone wants

A common goal on strategy slides is a single line: "Use AI to optimise the factory."

Behind that goal sit all the things that make it work:

• Defined, documented processes
• An MES/MOM platform running those processes on the shopfloor
• Machines connected, with data collected automatically
• Data contextualised with the order, material, shift and reason
• A data platform that keeps it over time
• Dashboards people use, and baselines to measure against
• A team that trusts the numbers
• A use case and a hypothesis to test

AI delivers the biggest gains, and everything else on that list is what makes those gains possible. It isn't a queue to clear before AI gets a turn. The organisations getting the most from AI work on the whole list at once, and the AI and the data each move faster because of the other.

AI isn't a black box

AI finds patterns in data. Machine learning trains an algorithm to predict an outcome from what it has seen before. You need a clear question and data to learn from, then you train and test the model. It's statistics at scale: useful and powerful, but dependent on what goes in.

A model fed with end-of-shift manual entries and backflushed consumption will produce confident-looking predictions on a weak foundation.

What a good data foundation looks like

Granular. Individual stops rather than shift totals, and individual measurements rather than daily averages.

Automatic where possible. Counts and machine states come straight from the equipment. People record what only people know, such as the reason for a stop.

Contextualised. "Machine stopped" means little on its own. The same event with the line, order, product and reason attached is something a model can learn from. More in Raw machine data is worthless.

Connected across departments. Predictive quality needs process parameters and inspection results in one place. Predictive maintenance needs machine condition alongside what was being produced. When production, quality, inventory and maintenance live in separate systems, some of that context is lost at each integration. This is where MOM's broader scope matters. See MES vs MOM.

Where AI already delivers

AI and statistical methods have been part of MES/MOM for longer than many people realise. Statistical process control has detected drifting processes for decades, and condition-based maintenance uses algorithms to spot patterns that come before a failure.

Newer applications are real too:

• Process parameter optimisation. Using history to find the settings that minimise scrap for a product and material.
• Predictive quality. Predicting whether a part will pass inspection before it's inspected.
• Anomaly detection. Spotting unusual patterns in production data that people would miss.
• Generative AI for people. Asking questions of operational data in plain English, or generating shift summaries. Examples in Practical GenAI for the shopfloor.

Each depends on good data, collected over time, with context.

Where generative AI delivers from day one

Generative AI is different from AI that learns from operational data. It works well on information most factories already have, however messy: SOPs, work instructions, equipment manuals, maintenance work orders, shift logs and free-text comments.

Typical uses:

• Search with understanding. Documents are indexed by meaning, so a question like "how do we clear a jam on the capper?" returns an answer drawn from the relevant passages, with a link to the source. This is usually called retrieval-augmented generation (RAG).
• Turning text into data. A model can read years of free-text maintenance notes and extract the asset and the failure mode, or classify operator comments into consistent downtime reasons. That helps build the data foundation.
• Digitising paper. Photos of handwritten logbooks and scanned checklists can be read and turned into records.
• Questions in plain English. Even a partial data set becomes more useful when people can ask about it directly.

The limits:

• It can't recover what was never captured. If short stops weren't recorded, no model will find them.
• It's only as current as its sources. An outdated SOP produces an outdated answer.
• It can sound right and be wrong. Answers should be grounded in your own documents, show their source, and be reviewed by a person when they matter.
• Acting is different from answering. Once AI recommends or takes actions on live operations, data quality and guardrails matter again. More in Agentic AI and MCP.

Building operational AI and the foundation together

Most manufacturers aren't able to take advantage of the AI and advanced technologies available today. The first steps are capturing shopfloor data and implementing AI use cases on that data, in parallel. You don't have to wait for the data foundation to be finished. GenAI on documents and know-how can start straight away, so people see value early. Time to truth describes the stages.

Where to start

Start with a question rather than a model: what decision would you make differently with perfect data about it? Then work backwards. What data would that take, and how much of it is accurate and in context today? The gap is the roadmap.

My view

I'm genuinely excited about what AI will do for manufacturing. AI will improve your factory, provided you give it the right data and context, in the same way that large language models only became useful once they had the internet to learn from. The manufacturers who'll get the most from it are the ones building that foundation and their AI together, starting now: defined processes, MES/MOM on the shopfloor and contextualised data that builds up over time. Start GenAI on your documents today, and build the data that lets AI predict and optimise alongside it.

What's the one decision in your factory you'd most like AI to help with, and do you have the data for it yet?

Many people think of MES as production only: running orders and calculating OEE. That's the production pillar, and it's important. But operators don't stop there. They perform quality checks, consume and create material, look after their equipment and follow procedures. A full MOM supports all of it, on the same data.

If you're new to the subject, start with What is MES/MOM?, then use this page to go deeper into each function.

Production

Production monitoring. Running and monitoring production orders in real time: order context, machine integration, counts, scrap, downtime and the data behind OEE.

Production scheduling. What ERP schedules and what MES/MOM fine-tunes, so the shopfloor always sees a live plan.

Quality

Quality operations. Inspection plans, in-line checks, SPC, non-conformances and holds, all tied back to the order and the material.

Inventory

Inventory management. Everything from raw materials to finished goods: lots, containers, consumption, labelling and traceability.

Warehouse management and logistics. Receiving, putaway, picking, supermarkets and line-side replenishment.