Excel vs ERP for industrial machinery manufacturing: where spreadsheets stop coping

In many machinery plants the real system is a set of spreadsheets. Design exports the BOM to Excel, purchase keeps a sheet of what has been ordered for each build, the production manager has a progress tracker with a column per stage, and the accounts team builds the cost of each machine at the end. Each file is sensible on its own.

Excel is quick, flexible and familiar, and a good BOM sheet built by someone who knows the machine is worth a lot. The question is not whether spreadsheets are good or bad, but when the number of builds, people and changes goes past what separate files can hold reliably.

Where Excel works well for a machine builder

• Quotation and cost estimates for a new machine, built by one person.
• A first-cut BOM exported from the design tool, before it is released.
• One-off analysis: a make-or-buy comparison, a vendor rate check, a capacity look at the assembly bays.
• A small shop running one or two builds at a time, where the owner sees everything.

Where do spreadsheets become difficult?

One BOM, several copies

Design holds one version, purchase works from another, and stores issues against a third that someone printed last month. When a part is revised, every copy has to be updated by hand, and usually one is missed. The wrong revision gets bought or made, and it is found at assembly.

Shortages across builds

Each build has its own purchase sheet, but the stores rack is shared. Two builds count on the same motor, or a bearing issued to one build is borrowed for another. Working out what is really short across all open builds means joining several files, so it is done rarely, and shortages turn up when the fitter needs the part.

Long-lead items

A gearbox ordered with a twelve-week lead time sits as a line in a sheet. Nobody is reminded to chase it in week eight, and the delivery date the customer was given quietly becomes impossible.

Vendor work

Parts sent for machining, painting or panel wiring are recorded on challans and maybe in a register. Whether they are late, short or rejected is known only when someone asks, usually when the build is already waiting.

Build progress

A progress tracker only knows what someone typed into it. The real status is in the bay, in the fitters' heads and in WhatsApp messages, so the weekly report to the customer takes a walk round the floor and a few phone calls to write.

Design changes and rework

When a part is changed mid-build or a sub-assembly is reworked after a failed check, the spreadsheet is overwritten. Later, nobody can say what was changed, which machine got which version, or what the rework cost.

Cost per machine

Material, labour and vendor charges come from different files and are added up after dispatch. By then the margin on the machine is a fact, not something anyone can still manage.

Spreadsheets and ERP compared, task by task

An ERP is an operational system, not a bigger spreadsheet

The difference is when the data is created. A build tracker is updated once the work is over, usually by a planner who heard about it second hand. A manufacturing ERP with shop-floor recording is filled in as the work is done: stores issues material to the build, the fitter marks the operation complete, QC records the alignment check, the vendor return is booked against the challan. Progress and cost are read from those entries rather than compiled.

That is why moving to an ERP that only covers purchasing and accounts often disappoints a machine builder. The files that cause the most trouble are the progress tracker and the shortage list, and both are about the floor.

When should a machinery manufacturer move from Excel to ERP?

There is no size at which a builder has to stop using Excel. The test is how often the files fail to give a current answer you can trust. These are the signs plants most often point to.

• Several people work on the same build. Design, purchase, stores and production each keep a version, and they no longer agree.
• More than a few builds run in parallel. One tracker can follow one machine; with five in the bay, nobody has the whole picture.
• BOMs change during builds. Customer options and engineering revisions arrive after release, and keeping every copy right is a job in itself.
• Material is hard to track. Items marked received cannot be found, or turn out to have gone to another build.
• Progress updates arrive late. The office knows where a build stands only after someone has walked the floor.
• Checks and test results are on paper. Stage checks and trial run records sit in a file, not with the build.
• A field failure is hard to trace. Finding which supplier's bearing or which motor went into a machine sold last year takes a search through old files.
• Rework cannot be seen. Nobody can say how much rework the last five machines needed, or where it came from.
• Customers ask for more. A buyer wants weekly progress, inspection records or a witnessed trial run, and the files cannot produce them quickly.
• Nobody knows current WIP. What is half built, what is at vendors and what is waiting for parts needs a count to answer.

None of these means Excel has failed. They mean the business has grown past what separate files can hold. Two or three at once usually mean the files cost more time than a system would. The guide to implementing ERP in a machinery plant covers what the move involves.

Keeping what works

A machine builder keeps plenty of spreadsheets after an ERP goes live. Quotation models, make-or-buy comparisons and one-off analysis stay in spreadsheets, using exports from the system. What moves is the operational record: builds, BOMs, stock by lot, progress, checks, vendor work and dispatch. In FleekERP that record sits on the build's work order, with inventory and lot traceability for material and the planning board for sub-assemblies and long-lead items, while the books stay in Tally or Zoho.

For how a build, its sub-assemblies and its vendor work run on one record, see FleekERP for industrial equipment makers.