Custom ERP or off-the-shelf: how manufacturers should decide

Start with how the factory runs

An ERP holds the factory's working record: what was ordered, what is in stores, what is on the floor, what it cost and what was shipped. Choosing one means deciding how closely software should follow the way you operate, and how far you will change the way you operate to follow the software.

There are three routes. A standard package is bought and configured. A custom system is built from scratch around your processes. Between them sits a ready platform that already covers the common modules and is customised where your factory differs. Each can be right. The mistake is choosing from a feature list or a demonstration before you have written down how work really moves through your plant.

When a standard package fits

A standard package fits when your processes are close to common practice and you are willing to adopt the package's way of working where they differ. This is often true for finance, payroll, routine purchasing and straightforward make-to-stock production. In these areas common practice is usually good practice, and bending software to preserve an old habit adds cost without benefit.

A package also suits a company that wants a known upgrade path and a wide pool of trained users, and has little appetite for owning software. To test the fit, walk through your main processes in the package as delivered. If most of them work with configuration alone, and you can live with the gaps or change your process to close them, a standard package is a sound choice.

When the package makes the factory work around it

Trouble starts when the way you make things is the part that does not fit. The signs are easy to spot. Production planning is done in a spreadsheet and typed into the ERP afterwards. Stores keeps a parallel register because the system's units or locations do not match the shelves. Work sent to outside processors is tracked by phone. Quality records sit on paper. Costing is rebuilt at month end from exports.

When this happens, the ERP records history and the real control sits elsewhere. Typical causes include mixed production modes, by-products and rework loops, variable yields, customer-specific quality checks, complex subcontracting and costing rules particular to the business. Heavy customisation of a package can close the gaps, but it can make upgrades difficult and leave you dependent on the people who wrote the changes.

The middle path: a ready platform, customised

A fully custom build fits any process, but you pay to build the ordinary parts too: item masters, purchase orders, goods receipts, invoices and user roles. Those are much the same in most factories and gain nothing from being written again.

The middle path is a ready platform that already has the standard manufacturing modules and is designed to be customised. You start from working software and spend the custom effort only where your plant differs, such as your routing, your quality gates or your costing method. Our manufacturing ERP is a platform of this kind: ready, and customised to how each client operates.

Check three things with any platform. Confirm that customisations survive updates. Confirm who owns the data and how you can get it out. Confirm that it integrates with the systems you will keep, such as accounting, machines or a customer portal.

What to map before deciding

Before you speak to any vendor, map how the plant works today. Do it on the floor, with the people who do the work. The official procedure and the real one often differ, and the system has to serve the real one.

Follow one order from enquiry to dispatch and write down every step, document and handover. Cover production flow, including routings, batch sizes, rework and subcontracting. Cover stores: locations, units of measure, issues and returns, and how stock is counted. Cover purchasing from request to approval to receipt. Cover quality at incoming, in-process and final stages, and what happens to rejected material. Cover costing: how material, labour, overhead and scrap reach a product's cost.

Then collect every spreadsheet, register and messaging group people rely on. Each exists because a system did not do something, so together they form an accurate requirements list. Mark each need as standard, different but changeable, or different and essential. The size of the last group tells you which route fits.

• Production flow, rework and subcontracting
• Stores, units and stock counts
• Purchasing and approvals
• Quality checks and rejections
• Costing method and the spreadsheets in real use

Data migration

Migration is the same work whichever route you choose, and it is easy to underestimate. Old data is rarely clean. The same item exists under several codes, units are inconsistent, bills of material are out of date and supplier records are duplicated.

Clean before you move. Agree one item coding scheme and one unit per item. Verify bills of material and routings with production. Decide how much history to bring: open orders, current stock and balances are essential, while old closed transactions can often stay in an archive that people can still query. Do a physical stock count close to cut-over so that opening stock is real. Run at least one full trial migration and have users check the result against records they know.

For a leading insurance group, we migrated databases dating from 2003 to a modern pipeline with zero production downtime. That result belongs to that engagement. The habits behind it apply to any migration: profile the data, rehearse and reconcile.

• One item code and one unit per item
• Verified bills of material and routings
• A decision on how much history to move
• Physical stock count before cut-over
• Trial migration checked by users

Roll out by module

Switching everything on in one day puts every department under strain at once and makes faults hard to trace. A phased rollout takes longer on paper and is safer in practice.

A common order starts with masters and stores, since everything else depends on accurate items and stock. Purchasing follows, then production, then quality, then costing and reporting once the transactions underneath can be trusted. Run each module until its users stop keeping the old spreadsheet beside it. That is the real sign of adoption. Name one owner per module from the business side, train on your own data, and review a short list of open issues every week.

• Masters and stores
• Purchasing
• Production
• Quality
• Costing and reporting

What to do next

Follow one order through your plant this week and list every spreadsheet and register it touches. Sort each need into standard, changeable or essential. If the essential list is long, look at a customisable platform or a custom build before you sign for a package.