What Your ERP Can't See — The Manufacturing Floor Your System Doesn't Know About

The ERP works. The floor still runs on whiteboards.

Walk through almost any Australian manufacturer doing $30–$80 million a year and you'll see the same thing. Sales has an ERP. Purchasing has the ERP. Finance lives in the ERP. The morning production meeting? It's around a whiteboard at the end of line three. The schedule is printed off the night before and marked up by hand. Supervisors read work orders off their phones. QA inspectors walk the floor with paper checklists on clipboards. At end of shift, someone keys what they remember into the system — or doesn't.

Meanwhile, the ERP — the one you implemented two or three years ago, on time, on budget — is sitting in the office telling sales the schedule is on track. It is, on paper. It just isn't on the floor.

If you're reading this and recognising it, you're not alone, and your business isn't broken. This is the structural reality at almost every mid-market manufacturer in Australia. The ERP is doing what an ERP does. It just doesn't reach the place where the actual work happens. And the longer that gap stays open, the more it costs.

ERPs were never designed to manage the floor

The first thing to defuse is the blame. Operators get blamed for not entering data. IT gets blamed for the implementation. The ERP partner gets blamed for not configuring it right. Whoever signed the cheque gets blamed for buying the wrong thing.

None of those are usually the actual problem. ERPs were designed — at their core — to manage transactions. Purchase orders, work orders, sales orders, invoices, inventory movements, GL postings. They are extraordinary at that. They were not designed to manage execution: the moment-by-moment reality of what's actually happening on the floor. Setup times, machine state, in-process scrap, the reason the line stopped at 2:14pm, the operator who quietly extended a cycle by 12 seconds because the tool was running hot. That layer is a different system class — usually called an MES, or a shop-floor data capture tool — and most $20m–$150m manufacturers don't have one. They have an ERP, and they're asking it to do MES things.

This is a category error, not a failure of effort. It's the same reason you don't run payroll out of your CRM. The system you have is doing exactly what it was designed for. The work the floor is doing isn't being captured, because nothing is capturing it.

The four places data falls on the floor

When the ERP doesn't reach the floor, data doesn't just go missing — it falls in specific, predictable places. We see the same four gaps in almost every operational review we run with manufacturers.

Sales-to-production: quoting in one language, building in another

Sales quotes the job using costing assumptions that came from the last estimate, the last similar project, or the BD manager's instinct. Those numbers go to the customer. The customer accepts. The order drops into the ERP. Production schedules it using a different routing — different setup times, different labour rates, different operations sequence than what the quote assumed. Sometimes a different machine entirely. By the time the job is done, the actual cost bears little resemblance to the quoted cost. The quote becomes the price. The price becomes the customer's expectation. The cost was somewhere else entirely. This is exactly the friction we describe on the manufacturing page — sales quotes with one set of assumptions, production plans with another.

Production-to-data: the work happens, the system doesn't see it

The floor is producing parts. The machines are running. The data isn't reaching the system in any meaningful way. Setup times live on supervisors' clipboards. Cycle times live in the operator's muscle memory. Scrap, rework, downtime — all of it gets summarised at end of shift, if at all, and re-keyed into the ERP later (if at all). The ERP shows the work order as "in progress." It doesn't know the press has been down for 90 minutes because the changeover took longer than the routing assumed. This is the same pattern as the double-entry tax — same data captured twice, badly, with the production version always a shift behind reality.

QA-to-traceability: paper answers, digital questions

Quality inspections happen on paper or in a separate quality module that doesn't connect to anything else. When a defect surfaces — a customer complaint, a non-conformance, a recall question — traceability requires manually reconstructing which batch, which raw material lot, which operator, which shift, which machine. What should be one click is hours of manual work, sometimes days. And in regulated environments — food, medical devices, defence — that gap isn't just an operational problem. It's a compliance problem.

Finance-to-margin: the answer always arrives late

Job costing happens at month-end. Standard costs absorb the actuals. Variances are explained — or rationalised — after the fact. By the time the CFO knows that batch 4471 lost money, the next three batches are already running on the same broken assumptions. When a board member or owner asks "how profitable was that job?" the honest answer is "we'll know in three weeks." This is the exact pattern we explore in why your accountant and your PM see different numbers — the data is in different places, and reconciliation is always retrospective.

Why "let's upgrade the ERP" usually misses the point

The instinctive reaction — when the floor doesn't match the system — is to assume the ERP is wrong. Maybe the implementation was bad. Maybe the partner was bad. Maybe the platform was the wrong choice. Maybe a fresh ERP, properly implemented this time, would close the gap.

Usually it wouldn't. The ERP isn't the wrong system. It's the right system doing the job it was designed to do. Replacing it with a different ERP — even a better one — gives you a different ERP that also doesn't reach the floor. Two years and several million dollars later, the same whiteboard is still in the same place. Sometimes with the same handwriting on it.

The structural fix is a shop-floor data capture layer — the bit that gets information out of machines, operators, and inspections and into the ERP in something close to real time. That layer can be a full MES, a lightweight shop-floor tablet/barcode tool, PLC integration with sensors and IIoT devices, or a bespoke data capture app talking to the ERP through middleware. The right answer depends on the manufacturing process: discrete vs. process, batch sizes, regulatory load, how digitised the equipment already is. The wrong answer is "we just need a bigger ERP."

Three honest paths forward (and how to choose)

There are three credible ways to close the gap. None of them are universally right. The choice depends on revenue, complexity, and how much disruption the business can absorb.

Option A — Add a shop-floor data capture layer to the existing ERP

This is the most common solution we recommend at $20m–$80m. Keep the ERP. Add a tablet- or barcode-based capture tool on the floor that pushes real-time data into the ERP via API or middleware. Operators log to a tablet at each station. Setup, run, scrap, downtime, and QA capture all happen at the source. Data lands in the ERP without re-keying.

Pros: low disruption to finance and the broader business. Quick wins on margin visibility. The ERP investment is preserved. Cons: integration design matters more than the tool you pick. A badly integrated capture tool ends up creating more manual reconciliation, not less. This is the option we see go wrong most often when it's chosen on tool features rather than integration architecture.

Option B — Move to an ERP with native shop-floor capability

Best fit at $80m+ where the ERP is already due for review and the appetite (and budget) for change is real. Solutions in this category include the manufacturing modules of NetSuite, Microsoft Dynamics 365 Supply Chain, IFS, and industry-specific platforms like Plex, Aptean, or Epicor. The MES capability is built in rather than bolted on.

Pros: single system, less integration overhead, often better long-term TCO. Cons: bigger investment, longer implementation, real change management. This is a multi-year journey, not a six-month project.

Option C — Layer a dedicated MES alongside the ERP

Best fit for manufacturers with high process complexity, regulated environments, or mixed-mode production where neither the ERP nor a lightweight capture tool will be enough. Dedicated MES platforms — Tulip, Critical Manufacturing, AVEVA, Siemens Opcenter — sit between the floor and the ERP and are purpose-built for execution.

Pros: deepest functionality for execution-heavy environments. Cons: bigger lift; needs experienced implementation; integration to the ERP is a project of its own. This is rarely the right starting point unless the operational complexity genuinely demands it.

The question to ask before you spend a dollar

Reframe the decision. Don't start with "what tool should we buy?" That's the question everyone wants to answer because it's the most concrete. It's also the question that leads to platform-shaped solutions to business-shaped problems.

Start with: where does data actually fall on the floor today, and what is it costing us? Map the four gaps — sales-to-production, production-to-data, QA-to-traceability, finance-to-margin — for your business specifically. Walk a job through each of them. Quantify the cost of each gap in the language the board cares about: margin leakage, rework, late delivery penalties, customer escalations, retention risk. Some gaps will be expensive. Some will be tolerable. The ones that are expensive are where the work starts.

Once you have that map, the platform question becomes a business case rather than a vendor decision. You stop asking "is this the best MES?" and start asking "does this close my biggest gap, and what would the next twelve months look like if it did?" That's a question every operations manager, GM, and CFO can answer.

This is the same methodology we apply to every operational review at Kaizen — we map the flow before we touch the system. In manufacturing, that flow is the flow of product alongside the flow of data. The two should match. Where they don't, that's the gap. And the gap is almost never where people first assume it is.