Architecture

When to customise ERP vs keep spreadsheets

A decision framework to reduce unnecessary customisations while still solving real business constraints.

Some spreadsheet usage is acceptable if controls and ownership are clear.

Customise only when the process is stable, high-value, and unlikely to change materially.

Assess upgrade impact before approving any extension backlog item.

Why this guide matters

• Some spreadsheet usage is acceptable if controls and ownership are clear.
• Customise only when the process is stable, high-value, and unlikely to change materially.
• Assess upgrade impact before approving any extension backlog item.

What a good approach looks like

• Assess each customisation request against value, process stability, upgrade impact, and support overhead.
• Keep a formal design authority to approve extensions and retire low-value bespoke logic over time.
• Where spreadsheets remain, define ownership, control checks, and reconciliation points clearly.
• Review the extension portfolio every quarter to maintain system simplicity and upgrade readiness.

Common mistakes to avoid

• Selecting software before agreeing the future operating model and decision criteria.
• Allowing one department to dominate the design while finance, operations, and IT assumptions remain untested.
• Using generic demos and partner promises instead of evidence from real scenarios, real data, and real reporting needs.

Practical next steps

• Document success metrics, owner accountabilities, and a realistic sequencing plan across finance, operations, and technology teams before committing budget.
• Use a weekly risk review with named owners, due dates, and mitigation actions so scope discussions do not restart every fortnight.
• Treat the guide as a working playbook and use it in steering meetings, partner workshops, and stage-gate reviews rather than leaving it as background reading.