ERP Extensions in New Zealand

Three ways to solve it, and only one gets quoted

Almost every ERP requirement can be met three ways, and most briefs describe only the middle one.

1. Change the process. Free, permanent, and unpopular.
2. Customise the ERP. The default answer, and an obligation you carry through every future upgrade.
3. Build alongside and integrate. More expensive up front, frequently cheaper over five years.

Ask each firm to price at least two of these. A quote that only considers customisation has skipped the decision that actually matters.

Ask the process question once, honestly

A meaningful share of ERP customisation exists to preserve a process designed around a system two generations old, which nobody has revisited because questioning it is awkward.

Worth asking about each requirement:

• Why do we do it this way? Is there a reason, or is it history?
• How does the ERP expect this to work, and is that actually worse or just unfamiliar?
• Does this difference win us anything with customers?
• What would it take to change, and what would it cost?

Where the standard way is merely unfamiliar, changing the process is free and never needs maintaining. Where your way is a genuine competitive advantage, customise with confidence. The mistake is not distinguishing between them.

Configuration covers more than people expect

Before anything is built, exhaust what the ERP already supports:

• Custom fields and additional data on existing records.
• Workflows and approval rules.
• Document layouts — invoices, purchase orders, packing slips.
• Report writers, which are usually more capable than anyone uses.
• User-defined pricing rules and discount structures.
• Dashboards and saved views.

Configuration survives upgrades, can often be changed by your own administrator, and costs a fraction of development. Ask each firm to mark which parts of your requirement are configuration and which need code, then to justify the code.

Every customisation is an upgrade cost, forever

This is the number missing from most business cases.

ERP vendors ship major releases. Every customisation has to be retested, and some reworked, each time. That is a recurring cost for as long as the customisation exists — and it compounds, because the twentieth customisation is tested alongside the other nineteen.

Modern extension frameworks are far better than the old practice of modifying core code, and the obligation has not gone away.

Ask directly: what does the next vendor upgrade cost with this customisation, and without it? Then multiply by however many upgrades you expect in five years. Businesses that ask this question customise less.

When to build alongside

A separate application, integrated with the ERP, is the better answer more often than it is chosen. It is worth considering when:

• The requirement is substantial rather than a field and a rule.
• It is likely to keep changing as the business evolves.
• The interface matters — people using it all day need something better than an ERP screen.
• Mobile access is needed.
• People outside your business need to see it, such as customers or suppliers.

The advantages are real: it survives vendor upgrades untouched, you change it on your own schedule, and it can be built by developers who are not scarce ERP specialists — which matters in New Zealand, where ERP consultants are expensive and booked.

The trade is another system to run and an integration to maintain. Ask for a five-year cost comparison rather than a build price.

Involve your ERP partner early

Whether or not they do the work, they should know about it before it starts. They know the upgrade path, they may have views on what is supported, and they will be supporting the system afterwards.

Ask each developer:

• Have you worked with our ERP partner before?
• Does this approach use the vendor's supported extension framework?
• Could this affect our support agreement?
• Who is responsible if a customisation causes a problem the vendor is asked to fix?

Customisation done quietly is how a business discovers its support arrangement has been compromised, usually at the worst moment.

Insist on documentation and tests

Customisations outlive the people who commissioned them, and in three years somebody will ask why the system does something unusual.

Ask for a written record of what was changed and why, in a form that survives staff turnover; automated tests, so the next upgrade can be verified rather than hoped through; and a named owner for each customisation with a periodic review of whether it is still needed.

That last one is worth building in. Customisations are added constantly and removed almost never, and some of yours are certainly supporting a process that ended years ago.

Comparing five quotes

Read for:

• Who priced more than one of the three options?
• Who asked whether the process could change?
• Who quantified the upgrade cost of each customisation?
• Who wanted your ERP partner involved?
• Who included tests and documentation?

Describe what the ERP will not do, why that matters commercially, how many people are affected, and which ERP and version you are on. Firms who do this work will ask whether the process could change before they quote the code.