# What an ERP actually knows about the shop floor

> An ERP holds three objects that decide whether a production plan is worth anything: the bill of materials, the routing and the work order. Each of them encodes assumptions that are rarely examined, and the errors compound quietly — a two per cent scrap factor at three levels is six per cent of material, and ninety-nine per cent transaction accuracy over twenty movements is eighty-two.

Page: https://ganiindustrial.com/insights/what-an-erp-knows-about-the-shop-floor · 2026-10-17 · Language: en

When a production plan turns out to be wrong, the software is blamed and the master data is the cause. That is not a defence of any particular ERP; it is an observation about what these systems actually contain. An ERP does not know anything about a factory directly. It knows a model of the factory, written by people, in three objects: what a product is made of, how it is made, and what has been authorised to be made. If those three are accurate, a mediocre system produces useful plans. If they are not, no amount of configuration helps, and the plant ends up running on spreadsheets kept by whoever has been there longest.

This note goes through the three objects, the arithmetic each one hides, and the boundary between what an ERP can see and what it structurally cannot. It is written from the position we are usually in: holding somebody else part numbers, building to their documentation, and having to make their planning data agree with what happens on our floor.

## Where the ERP sits, and where it does not

The reference model worth knowing is the functional hierarchy published as IEC 62264 and more commonly called ISA-95. It divides a manufacturing enterprise into levels. Level 0 is the physical process. Level 1 is sensing and actuating. Level 2 is supervisory monitoring and control, which is the PLC and the SCADA, working in milliseconds. Level 3 is manufacturing operations management — the detailed scheduling, dispatching, tracking and data collection usually implemented as an MES. Level 4 is business planning and logistics, which is the ERP, working in shifts, days and weeks.

The reason to care about the model is not taxonomy. It is that each level has a native time constant, and crossing them carelessly produces systems that cannot work. An ERP asked to dispatch individual operations to individual machines in real time is being asked to do a level 3 job with a level 4 clock. A PLC asked to hold the production history of a serial number is being asked to be a database. Most of the integration projects we are called into have one of those two mistakes in them, and the fix is not better interfaces but moving a function to the level it belongs on.

## The bill of materials, and the factors inside it

A bill of materials looks like a parts list and behaves like a program. It is a set of parent-component-quantity relations, usually multi-level, each with an effectivity window that says from which date or which serial number the relation applies. It carries alternates, where one of several approved components may be used, and it carries phantom or transient assemblies, which exist in the structure for engineering clarity but are never stocked: the planning run passes straight through them to their components. Phantoms are useful and they are also where quantities go missing, because a phantom that someone later makes stockable changes the behaviour of every plan above it.

The factor that causes the most quiet error is scrap, sometimes called yield or shrinkage, applied per component or per operation. It is arithmetic and it compounds. Consider an assembly four levels deep where each of three levels carries a two per cent component scrap factor. The gross requirement for the bottom component is the net requirement divided by 0.98 three times, which is a multiplier of 1.0625. Six and a quarter per cent more material than the net structure suggests, for a figure nobody in the room remembers entering. Set the factors too low and the plant runs short at the end of every batch; set them generously at every level and the inventory quietly grows. Either way the number belongs to measurement rather than to habit, and it should be reviewed against actual scrap reporting at least annually.

The second quiet error is units. A component bought per metre, stocked per metre and consumed per piece requires a conversion that lives in exactly one place and is almost never tested. Cable, heat shrink, cable ties, terminal rail and adhesive are the usual suspects. The symptom is an inventory value that drifts without any physical cause.

## The routing, where the lead time is mostly waiting

A routing is the sequence of operations, each tied to a work centre, each with a setup time, a run time per piece, and the queue, wait and move allowances around it. Planned lead time for an operation is setup plus run multiplied by quantity plus queue plus move, and the last two terms usually dominate.

Take an operation with 30 minutes of setup and 1.5 minutes of run time per piece, on a batch of 200. The work content is 30 plus 300, so 330 minutes. Now add the standard allowances most systems carry: one day of queue in front of the work centre, which is 480 minutes on a single shift, and 60 minutes to move the batch afterwards. The planned lead time is 870 minutes, and 540 of those — 62 per cent — are waiting rather than working. This is the single most useful number to show anybody who believes the way to shorten lead time is to buy a faster machine.

It also explains why batch size is the strongest lever available. Halve the batch to 100 and the work content falls to 180 minutes while the queue and move allowances stay, so the lead time goes from 870 to 720 minutes, a 17 per cent reduction, at the cost of one more setup. Halve it again and the gain continues, until setup time consumes the saving. That is the whole argument for setup reduction: it is not about machine utilisation, it is about buying the right to run smaller batches.

Routing times carry a second problem, which is that they are standards rather than measurements. A run time that is 20 per cent optimistic makes every capacity plan 20 per cent optimistic, silently, for years, and the plant learns to add its own margin on top until nobody trusts the system at all. When we take on a customer part number we time the operations on our own floor during the pilot batch and give the customer the measured figures, because a routing that matches reality is the cheapest planning improvement available to either side.

## The work order, and the lie of backflushing

A work order is the authorisation to make a quantity of something by a date, against a bill of materials and a routing frozen at release. Most systems consume the components by backflushing: when a quantity is reported complete, the system deducts the components the bill says should have gone into it. It is efficient and it is an assumption, and it is wrong whenever reality diverges — scrap that was not reported, an approved alternate that was used without a substitution record, a kit that was short and completed from the open stock on the bench.

Each of those is small and they accumulate, because inventory accuracy is multiplicative rather than additive. If every individual transaction is 99 per cent reliable, a part that is received, inspected, put away, picked, kitted, issued, partly returned, moved between operations and finally reported — twenty touches, which is ordinary — has a record accuracy of 0.99 to the twentieth power, about 82 per cent. The sentence to retire is not that the ERP is wrong. It is that the ERP never claimed to know what is on the shelf; it knows what has been reported, which is a different thing, and the gap is a measurable quantity rather than a mystery.

The remedy is cycle counting rather than annual wall-to-wall counts: a small number of locations verified every day, weighted so that the fast-moving and high-value items are counted far more often than the rest, with each discrepancy investigated for its cause instead of simply adjusted. A count that produces an adjustment and no cause teaches nothing. The measure that matters is the percentage of counted locations that match, not the net value of the adjustments, because positive and negative errors hide each other in a total.

## What should have gone in, and what did

A bill of materials states what should have gone into a unit. An as-built record states what did: the actual lot of each component, the station and operator, the firmware version, the measured test values, the serial number. They are different objects and the difference becomes important exactly once, on the day a supplier reports a suspect lot and somebody has to say which shipped units contain it.

Answering that from the bill of materials is not possible, because the bill does not know which lot was consumed on which day. Answering it from an as-built genealogy takes minutes in both directions: from a component lot forward to every unit that contains it, and from a returned unit backwards to everything that went into it. Which direction a plant needs decides how much it is worth paying for, and the honest way to size the investment is to price the recall you would otherwise have to make at full batch width.

## The part an ERP cannot do, and should not be asked to

An ERP has no model of a machine state and no clock fine enough for one. A work order says four hours at work centre 310. It does not know that the station was blocked for 90 seconds because a feeder jammed, or that the cycle ran at 61 seconds rather than 58 for the first hour while the fixture warmed up. Those facts decide whether the plant makes its numbers, and they live at level 3 — a per-part, per-station record of when the part arrived, when the station finished and why the machine waited.

That record is cheap to produce in a modern controller and it is the only honest input to a capacity plan, because it turns routing standards into measurements. The pattern that works is narrow and dull: the controller timestamps parts, level 3 aggregates them into completions, scrap and downtime reasons, and the ERP receives confirmations and returns released orders. Nothing crosses the boundary in real time, nothing on the floor waits for a business system, and the planning data improves every week because it is being fed by what actually happened.

## What we maintain for a customer part number

When we take over a product, the planning data is part of the transfer rather than an afterthought. We agree the bill of materials structure level by level against the released drawings, record the scrap factors we measure instead of inheriting them, time the routing operations during the pilot batch and hand over the measurements, and define which items are lot-controlled and which are serialised before the first production order is released. The gap analysis that opens a transfer project asks for this data in the same breath as the drawings, because a product can be built from drawings alone, and it cannot be planned from them.


---

GANI Industrial — engineering, manufacturing and lifecycle for European OEMs. Bursa, Türkiye.
Site index: https://ganiindustrial.com/llms.txt