A packaged product or software written for your process

Comparison criteria

Criteria are stated explicitly and neither option is declared a winner: which one fits depends on the constraint that binds hardest in your operation.

Separate the process differences that matter from the ones that are habit

Almost every evaluation reaches a list of gaps between what the plant does and what the product supports, and the quality of the decision depends on how honestly that list is triaged. Some differences exist because the operation is genuinely unusual — a process step nobody else runs, a customer requirement peculiar to your sector, traceability at a granularity the industry does not assume. Others exist because a spreadsheet was built a decade ago and everyone worked around it since. Adopting a package is cheap where the gap is habit and expensive where it is real. Do that triage with the people who actually perform the work, and record which gaps you decided to absorb, because those decisions get relitigated during rollout.

Modification is a liability that compounds at every release

The route most plants actually take is neither pure: a package is bought and then modified where it did not fit. Each modification is reasonable on its own and the accumulated set determines what the next upgrade costs, because every change outside supported configuration has to be reassessed, retested and often rebuilt. Enough of them and the plant is effectively maintaining bespoke software while paying licence fees, and eventually stops upgrading at all — which is how a system ends up several versions behind on an unsupported platform. Keep a register of every modification with its business justification, review it before each upgrade, and remove the ones whose original reason has expired.

Ask who answers the telephone during the night shift

Software that records production becomes load-bearing quickly, and the real difference between the two routes shows up when it fails at an inconvenient moment. A supported product has a defined response commitment, a defect process and other customers who have already hit the same problem. Commissioned software has whoever wrote it, if they are still employed and reachable, and a support arrangement that has to be negotiated rather than assumed. Whichever route is taken, secure the continuity explicitly: source code held in escrow or in your own repository, current documentation, more than one person able to work on it, and a written response commitment with real consequences attached.

Frequently asked questions

Is a heavily configured package the same as custom software?

Not while the configuration stays inside what the vendor supports, which is the boundary that matters. Supported configuration survives upgrades and is covered by the support agreement; work beyond it is yours to maintain even though it sits inside somebody else's product. The trouble is that the boundary is often unclear during implementation, when an integrator is keen to satisfy every request. Ask explicitly, item by item, whether each change is supported configuration or an extension, and record the answer.

What usually goes wrong when a manufacturer builds its own system?

Two patterns dominate. The first is requirement drift: the operation is described optimistically, exceptions are discovered during rollout, and the build expands well beyond its estimate. The second is dependence on one developer who understands the whole system and eventually leaves. Both are manageable with ordinary discipline — write requirements with the people doing the work, insist on documentation and code review as deliverables, and ensure more than one person can change anything critical.

Can spreadsheets remain part of a manufacturing system?

They persist in nearly every plant, and the useful distinction is what they are trusted with. Analysis, planning scenarios and one-off calculations are reasonable spreadsheet work. Holding the authoritative record of what was made, tested or released is where they become a liability, because version control, access rights, audit trail and calculation integrity are all weak and errors propagate silently. Where a spreadsheet has become the system of record for something that matters, that is the case for replacing it, whichever route you then take.