Manufacturing ERP: the system that decides what your factory can promise

The item master is the project, not the software

Most of the effort in an ERP programme goes into deciding what an item is and who may create one. Plants arrive with the same physical part carried under several numbers, bought and made versions of the same thing, units of measure that differ between purchasing and production, and dormant records nobody dares delete. Until that is resolved, every downstream calculation inherits the confusion. The remedy is unglamorous: a numbering rule, a single owner with authority to reject requests, a cleanse of dead records before migration rather than after, and a gate that stops purchasing ordering a part engineering has not released. Skipping the stage does not remove the work, it moves it into the months after go-live where it costs far more.

Routings describe a factory that has to still exist next year

A routing tells the system which work centres a part visits, in what order, and how long each step takes. Plants often load them once from an old system and never revisit them, so the ERP plans against a shop that has since bought a machine, merged two cells or outsourced a process. The symptom is a plan that planners privately correct on paper. Setting standard times is a political act as much as a technical one, because the same figures feed capacity, product cost and sometimes operator performance reporting. A workable compromise is to keep routings honest for planning purposes, hold the labour-reporting argument separately, and give every work centre a named owner accountable for its data.

Standard costing turns arguments into variances

The system costs a product by rolling material up at standard price and adding labour and overhead absorbed through the routing. None of that reflects what the period actually cost; the difference surfaces as purchase price, usage, rate and volume variances. Those are useful when everyone treats a variance as a question rather than a verdict, and corrosive once they become a scoreboard. Finance and operations should settle in advance how often standards are reset, who approves a change, and what a variance obliges someone to do. Where the routing is wrong the cost is wrong, and quoting from that cost is how a plant wins work it then loses money making.

The transactions nobody enjoys doing decide whether stock is real

Every figure on screen rests on shop-floor transactions: material issued, operations confirmed, quantities and scrap declared, finished goods received. Each is work for someone who would rather be making parts, so the design question is how to capture them with least friction — scanning at the point of movement, backflushing routine consumption while counting expensive items properly, confirming at meaningful boundaries instead of at every operation. Where reporting runs late or gets invented, planning degrades quietly and the first visible symptom is a stock figure the storeman does not believe. Physical counting discipline is the audit that keeps everything else honest, and it belongs to operations rather than to finance alone.

How you can tell the programme has drifted

Failure rarely looks like software that does not run. It looks like a parallel spreadsheet, a planner who exports everything and replans by hand, or a modification backlog that has made upgrading unaffordable. The usual causes are scope that grew past the sponsor's attention, no named owner for each data domain, a cutover scheduled into a busy season, and training delivered as a demonstration rather than practice on real orders. Countermeasures are dull and effective: freeze scope, migrate less than you think you need, run old and new processes against the same week of live orders, and plan for a temporary dip in output instead of promising there will not be one.

Frequently asked questions

Can a manufacturer run production on a general business ERP?

It depends on how the plant makes things. Simple assembly with stable products and shallow structures can be handled by a general system with inventory and product structure modules. Deep multi-level products, revision-controlled designs, process orders, batch genealogy or heavy customer configuration will expose the gaps quickly, usually around scheduling, traceability and shop-floor reporting. The honest test is to take a genuinely awkward order you already received and walk it through the system end to end before anyone signs a contract.

Should the ERP be scheduling the shop floor?

Standard planning runs generally assume capacity is unlimited and simply offset lead times backwards from a due date. That is adequate where material is the constraint and the shop is rarely full. Where a bottleneck governs throughput, or sequence-dependent changeovers dominate, the plan will be optimistic and supervisors will override it anyway. Plants in that position either add finite scheduling above the ERP or accept that the ERP sets priority while a human sets sequence. Deciding this deliberately beats discovering it after go-live.

What is the earliest warning that adoption is failing?

Watch for spreadsheets reappearing. When a planner keeps a private file to work out what to build, or a storeman keeps a notebook of real quantities, the system has lost credibility on something specific — usually unreliable lead times, inaccurate inventory, or a report nobody can produce from standard tools. Log those workarounds as defects rather than dismissing them as user resistance, because each one marks a data or process gap that will otherwise harden into permanent practice.