The symptom, stated plainly
Finance closes the month out of the ERP. Production runs off a spreadsheet named something like Master Plan v14 FINAL.xlsx. Shipping keeps a clipboard. Purchasing keeps its own list because the reorder points in the system are wrong and everyone knows it. Somewhere in the middle sits a person whose actual job, whatever their title says, is reconciling those views once a day so nobody notices the gap.
That person is the most important system integration in the company and they are not documented anywhere. When they take a vacation, on-time delivery drops. This is worth stating without judgment: it is an entirely rational adaptation to software that asks for effort it does not repay.
The diagnosis follows from that. For every transaction the system asks a human being to perform, what does that person get back? If the answer is nothing — if scanning the traveler at operation forty produces no benefit the operator can perceive — the transaction will be skipped when the line is busy, batched at the end of the week, or entered from memory. And once transactions are entered from memory, every downstream number is fiction with a timestamp on it.
You are probably here because
- Someone has proposed replacing the ERP and the number is large
- Inventory on hand is wrong often enough that planning output is ignored
- The shop floor modules were bought and never turned on
- Two departments produce two different answers to the same question
The section on master data is where most of the damage actually is. The section on the thin layer is what we usually end up building, and it is smaller than people expect.
Why the shop floor modules were never adopted
Nearly every implementation we have looked at was scoped around the general ledger. That is not a criticism; it is how these projects are justified and how the money is approved. Finance is the first-class citizen, the chart of accounts gets weeks of attention, and operations is configured afterward by an implementation partner working against a fixed bid and a go-live date.
The result is a system that is correct in every accounting sense and hostile to the person standing at a machine. Ten fields where two would do. A part number that must be typed rather than scanned. A screen that requires a mouse in a place where people wear gloves. A response time of six seconds on a transaction performed two hundred times a shift. None of that is a defect the vendor would acknowledge, and all of it is fatal to adoption.
Master data is where the damage is
Before anyone builds anything, look at four tables. In our experience this is where most of the perceived ERP failure actually lives, and none of it requires new software to fix.
The item master. Count the duplicates. Three spellings of the same purchased component, created by three buyers over six years, is normal and it quietly breaks every aggregate you compute. Check units of measure and their conversions, especially anywhere a part is bought in one unit and consumed in another. A wrong conversion factor produces planning output that is off by a factor and looks plausible enough to survive for years.
The bill of material. Does it match what the line actually builds? Substitutions made on the floor for eighteen months and never engineered back in are common. So are missing consumables that get expensed instead, which makes standard cost wrong in a direction nobody investigates because it flatters the margin.
Routings and standards. Setup and run times that came from a quotation, never revisited after the tooling changed. If your routings say a part takes eleven minutes and the floor knows it takes seventeen, capacity planning is a fiction and everyone downstream has learned to ignore it.
Planning parameters. Lead times, order minimums, safety stock, reorder points. These are usually set once at implementation and left. A supplier lead time entered as fourteen days in 2016, currently running thirty-five, produces shortages that get blamed on planning discipline.
Yield and scrap factors deserve a specific mention because they are so often left at zero. If a process reliably loses a few percent and the system does not know it, every order will short by that amount and the plant will compensate with informal padding that nobody records.
The transactions that lie
Backflushing — relieving component inventory automatically when a parent is reported complete, based on the bill of material — is the single most common source of inventory that looks right in the system and is wrong on the floor. It is not a bad practice. It is a trade: you accept less accuracy in exchange for far fewer transactions, and it works well for stable processes with accurate bills and low scrap.
It works badly everywhere else, and it fails silently. The bill says two of a component; the operator used three because one was damaged. The system relieves two. The variance surfaces at the next physical count, months later, as an unexplained shrink, and by then nobody can attribute it. Backflush the cheap and stable items. Issue the expensive, the traceable and the high-variability items at the point of use, where a human being confirms what was actually consumed.
Two more worth checking. Reporting production at the end of a run rather than at each operation means work in process has no visible position, so nobody can answer where an order is without walking the floor. And a receiving transaction performed the following morning from a stack of packing slips means the material is physically available and systemically invisible for a shift, which triggers expedites for parts that are already in the building.
On-hand accuracy, and what “good” looks like
Everything above resolves into one number: can you trust on-hand quantity by location? Planning output is only as good as that input, and no analytics layer repairs it.
The way to know is cycle counting — counting a rotating subset continuously and measuring accuracy at the location level rather than in aggregate dollars. Aggregate dollar accuracy is a much easier test and it hides the failures that hurt, because a large positive error on one item offsets a shortage on another and the total looks fine while the line waits for parts.
Well-run operations we have seen hold location-level accuracy in the high nineties. Down in the eighties, planning output is noise and the planners already know it, which is why they override it, which is why nobody trusts the system, which is the loop you are trying to break. Establish the number honestly before deciding what to build, because it determines whether the useful project is software at all.
The thin layer, and the rule that keeps it safe
The pattern that works, and the one we build most often, is not a replacement. The ERP stays the system of record. In front of it goes a small, fast, purpose-built layer covering the handful of things operations does every hour: scan an order, move material, report an operation complete, record a nonconformance, look up where something is. Four or five screens, each doing one thing, each usable in under ten seconds with a barcode gun and no mouse.
Then it writes back through the ERP's own supported interface — its API, its published web services, or its documented staging tables with the vendor's own import process. Never directly into the database.
That rule is worth its own paragraph. An ERP database is not a data model; it is the persistence layer under an application that enforces rules the tables do not. Direct writes bypass validation, skip the accounting entries a transaction is supposed to generate, and produce records that look correct and reconcile to nothing. They also void support, and they break at the next upgrade, which will arrive at an inconvenient moment. Reading from a replica for reporting is fine and normal. Writing is through the front door, every time.
| Approach | What it is good for | Rough shape | The risk |
|---|---|---|---|
| Fix master data | Duplicate items, unit conversions, stale lead times, zero scrap factors | Internal work, weeks, mostly a person with authority to decide | Nobody owns it afterward and it decays again |
| Turn on what you own | Modules bought at implementation and never configured | Your ERP partner, days to weeks | Same usability problems that caused the original abandonment |
| Thin operator layer | High-frequency floor transactions; the daily reconciliation job | Two to four months, one or two engineers | Becomes a second system of record if scope is not held |
| Reporting layer on a replica | Disagreements between departments about the same number | Weeks, once definitions are agreed | Publishing numbers built on inventory nobody trusts |
| Full replacement | Unsupported version, vendor gone, or the business model changed | Multi-year, seven figures, disruptive by construction | Carrying the same bad master data into a new system |
Building for a person wearing gloves
An operator screen is not an office screen, and most of what makes an internal tool pleasant in an office is irrelevant or harmful on a floor.
Read from three feet, under bad lighting, through a scratched screen protector. Touch targets sized for a gloved finger. The barcode gun is the primary input device and the keyboard is a fallback, which means every field that can be scanned should be scannable and the scan should advance the workflow without a submit button. Assume the network drops, because in a metal building it does: the transaction queues locally, the operator gets an unambiguous indication of what has and has not been recorded, and it flushes when the connection returns. Nothing is more damaging to adoption than an operator who is not sure whether their work was saved.
Speed is a feature with a threshold. Under a second feels instant. Six seconds, two hundred times a shift, is twenty minutes of a person's day and it teaches them to batch.
And the tool needs a defender. In practice that is the shift supervisor. If the supervisor believes in it, it survives turnover and bad weeks. If they were not consulted while it was designed, it will not, however good it is.
Where you do not need us
If the modules you need were purchased at implementation and never configured, the right first move is your ERP partner, not a custom build. It is cheaper and it stays supported.
If the problem is one report that two departments disagree about, that is a definition to write down and a query to fix. It does not need a project.
If the item master has not been cleaned, do that first and do it internally. It requires someone with the authority to declare which part number wins, and that authority does not come from outside the company. Any software built on top of it before that will inherit the mess.
And if a replacement genuinely is the right answer — an unsupported version, a vendor who has exited, a business that has moved from make-to-stock to configure-to-order, or three systems left over from acquisitions — then that is a program with its own governance, and a thin layer would only postpone it. Say so early. The most expensive version of this work is a custom layer built to avoid a decision the company has already made and not yet admitted.
The mistakes that repeat
- Replacing the ERP to fix master data, then loading the same master data into the new one
- Writing directly to the ERP database because the API was inconvenient
- Designing floor screens in a conference room without a supervisor in it
- Backflushing high-variability or traceable items and discovering the gap at a physical count
- Publishing dashboards on top of on-hand quantities nobody believes
- Measuring inventory accuracy in aggregate dollars, which hides the errors that stop the line
- Letting the thin layer grow until it is a second system of record with its own truth
- No owner for planning parameters, so lead times are correct for one week after go-live
A sequence that works
- Count the spreadsheets that operations depends on, and ask each owner what the ERP failed to give them
- Measure location-level inventory accuracy before deciding anything
- Audit the four tables — items, bills, routings, planning parameters — and name an owner for each
- Ask what modules you already own and what turning them on would cost
- Pick the three highest-frequency floor transactions and build only those
- Write back through the supported interface, read from a replica, never write to the database
- Test on the floor, in gloves, on the real network, before go-live and not after
- Retire a named spreadsheet as the acceptance criterion for each screen
Bottom line
The reason operations does not use the ERP is almost never that the ERP is bad software. It is that it was configured for the ledger, that the master data underneath it decayed without an owner, and that the transactions it asks for cost the person performing them more than they return. All three of those are fixable without a replacement project, and the order matters: measure inventory accuracy, repair the four master tables, then put a small fast layer in front of the system for the things people do every hour. Hold that layer to a handful of screens, write back through the front door, and judge it by the spreadsheets it retires rather than by the features it has.
Frequently asked questions
Usually not, and usually not for the reason being given. Replacement is warranted when the version is unsupported, the vendor has exited, the business model has changed in a way the system cannot express, or acquisitions have left several systems to consolidate. Poor adoption, bad master data and untrusted inventory are not replacement reasons, because all three travel with you into the new system unless they are fixed first.
No. The database is the persistence layer under an application that enforces rules the tables do not, so direct writes skip validation and the accounting entries the transaction should generate, producing records that reconcile to nothing. They also typically void vendor support and break at the next upgrade. Read from a replica freely; write through the API, the published web services, or the documented import process.
Cycle count and measure at the location level, not in aggregate dollars, because offsetting errors make the aggregate look healthy while the line waits for parts. Well-run operations hold location-level accuracy in the high nineties. In the eighties, planning output is noise and your planners are already overriding it, which is the real signal.
It is a trade, not a mistake: fewer transactions in exchange for less accuracy. It holds up for cheap, stable, low-scrap components with accurate bills of material. It fails quietly for expensive items, traceable items and anything with variable consumption, because the error surfaces months later as unattributable shrink. Split the treatment by item rather than applying one policy to everything.
For three or four high-frequency transactions with one supported write path back to the ERP, two to four months with one or two engineers is a realistic range, and the integration work is usually larger than the screens. The variable that moves it most is not engineering, it is how quickly the organization can agree on definitions and give someone authority over master data.