An ERP selection decision can shape operating performance for the next decade. Yet many organisations begin by comparing features before agreeing on the commercial problems the system must solve. Knowing how to select ERP software starts with a more disciplined question: what must change in the way the organisation plans, controls, delivers and reports?
For Australian mid-market and complex organisations, ERP is rarely just a finance system replacement. It is a decision about data quality, delegation, inventory discipline, project visibility, cyber risk, compliance and the capacity to scale without adding unnecessary administration. The right platform improves control while making work easier for the people responsible for running the business.
Start with the business case, not the software demo
A polished demonstration can make almost any ERP appear capable. The more useful test is whether a prospective system supports a clearly defined improvement program. Before speaking seriously with vendors, establish the outcomes that justify investment and the cost of maintaining the current environment.
These outcomes will vary. A distributor may need accurate available-to-promise stock and tighter warehouse processes. A project-based business may need reliable work-in-progress, margin and resource reporting. A regulated entity may place greater weight on audit trails, segregation of duties and controlled approval workflows. A growing group may need faster consolidation across entities, currencies or locations.
Put a baseline around the issues. Measure month-end close time, manual journal volumes, inventory adjustments, order-processing delays, aged debtors, rework, spreadsheet dependence and the effort required to produce board reporting. This creates an investment case grounded in performance rather than broad claims about modernisation.
It also clarifies what not to solve in the first phase. ERP projects become difficult when every historic frustration is treated as a mandatory requirement. Prioritise the processes that affect cash, margin, compliance, customer service and management confidence in the numbers.
Define requirements around decisions and controls
Traditional requirements documents often become long catalogues of functions. They are useful, but they do not reveal whether the system will support better decisions. Frame requirements around the decisions people need to make and the controls required to make them with confidence.
For example, instead of stating that finance needs “better reporting”, specify that the CFO needs a consolidated view of cash, committed spend, forecast movement and debtor risk within an agreed reporting cycle. Instead of requesting “inventory functionality”, define how planners will manage replenishment, exceptions, stock ageing and purchase commitments across sites.
Separate essential capability from familiar practice
Teams can unintentionally design a new ERP around old workarounds. Some current processes genuinely protect customers, compliance or margin. Others exist because the legacy system could not support a simpler method.
Ask process owners why each step exists. If the answer is “because we have always done it that way”, test whether the step should be removed, automated or redesigned. This is where process improvement and technology selection need to work together. Configuring an inefficient process into a new platform is an expensive way to preserve inefficiency.
Include governance requirements early
Governance should not be deferred to the implementation phase. Define approval limits, delegation rules, audit requirements, master-data ownership, user access principles, retention obligations and incident escalation expectations as part of selection.
This matters particularly for organisations with boards, public funding, regulated operations or multiple legal entities. Strong governance does not need to create friction. When roles, workflows and exceptions are designed well, it gives leaders faster assurance and gives staff clearer authority to act.
Assess fit across the whole operating model
A capable ERP must fit more than the finance team. Evaluate how it supports the connected flow of information from customer demand through purchasing, operations, delivery, invoicing, cash collection and management reporting.
Microsoft Dynamics 365 Business Central, for example, is often a strong option for organisations seeking enterprise-grade financial and operational capability without the cost and complexity associated with larger enterprise platforms. Its suitability still depends on the operating model, required integrations, industry needs, transaction volumes and the organisation’s capacity to adopt new ways of working.
Consider the system’s fit across four practical dimensions:
- Core operations: Finance, purchasing, sales, inventory, projects, service and multi-entity requirements should work together without excessive manual reconciliation.
- Data and reporting: Leaders need timely, trusted information. Assess the data model, reporting tools, dashboard capability and the ability to connect operational and financial measures.
- Integration and extension: Most organisations retain specialist applications. Confirm how the ERP will connect with payroll, CRM, ecommerce, banking, field service, data platforms and industry tools.
- People and scale: Review usability for frontline teams, mobile access where needed, role-based experiences, training requirements and the capacity to support growth, new entities or changed service models.
Do not assume that a system with the most features offers the best fit. Excess capability can create cost, configuration complexity and lower adoption. The objective is sufficient flexibility to support planned change without building a platform that requires specialist intervention for every adjustment.
Evaluate data readiness before committing
Data is often the hidden constraint in ERP programs. Duplicate customer records, inconsistent chart-of-accounts structures, uncontrolled product codes and incomplete supplier information can undermine even a well-configured system.
During selection, assess the quality and ownership of the data that will move into the new environment. Identify which records are authoritative, what historical data is genuinely needed, where data is created and who is accountable for maintaining it. A clean start may require archiving low-value history and establishing new standards rather than transferring every record from legacy systems.
This is also the point to address reporting definitions. If sales, operations and finance calculate margin, revenue or project status differently, a new ERP will expose the conflict quickly. Establish common measures and data ownership before configuration begins. Better dashboards cannot compensate for ambiguous definitions.
Compare implementation partners, not only products
ERP outcomes depend heavily on the partner’s ability to understand the business, challenge weak processes and manage delivery risks. Software selection and partner selection should therefore be linked.
Look beyond certifications and reference lists. Ask how the partner will run discovery, manage scope, handle data migration, test controls, train users and provide support after go-live. Seek evidence that they can translate executive objectives into practical process design, rather than simply configure standard features.
A credible partner should be direct about trade-offs. Customisation may be justified where it protects a distinctive operating advantage or meets a non-negotiable regulatory obligation. It should be questioned where a standard process would deliver the required outcome with lower long-term cost and upgrade risk.
For organisations dealing with broader performance issues, it is valuable to work with advisers who can connect ERP design to finance improvement, governance, risk, workforce adoption and operational performance. i3 Australia takes this integrated view because technology is most effective when the surrounding processes, accountabilities and decisions are equally clear.
Run demonstrations using real scenarios
Avoid generic demonstrations. Give shortlisted vendors a set of representative scenarios based on actual work, including normal processing and exceptions. Require them to show the process end to end, with the relevant approvals, reporting impact and user roles.
A useful scenario might begin with a customer order, progress through stock allocation or procurement, delivery and invoicing, then show the cash-flow and margin impact in management reporting. Another might test a delegated purchase approval, a pricing exception, a project variation or a late supplier invoice. The objective is to see how the system behaves when work is not perfectly standard.
Include operational users in these sessions, not just project sponsors. Finance leaders may value controls and reporting, while warehouse, project or customer-service teams will identify usability issues that determine whether the process works in practice. Capture feedback consistently against agreed criteria so the loudest voice does not dominate the decision.
Build a whole-of-life cost and risk view
Licence costs are only one part of the investment. A realistic assessment includes implementation, integration, data cleansing, internal project time, training, change management, support, future enhancements and the cost of maintaining any custom development.
Compare these costs against the financial and operational benefits expected from the program. Benefits may include lower working capital, reduced manual effort, faster close cycles, fewer errors, stronger compliance evidence, better purchasing discipline and more reliable forecasting. Some benefits will be measurable quickly; others, such as improved decision confidence and resilience, require judgement but remain commercially significant.
Risk should be considered with the same discipline. Assess vendor viability, cybersecurity arrangements, data hosting and privacy obligations, service continuity, contract terms, implementation dependency and the risk of business disruption during change. A lower initial price can become expensive if it leaves the organisation with fragile integrations, poor support or inadequate controls.
Plan adoption as part of the selection decision
The best-designed ERP cannot improve performance if people work around it. Selection should therefore test the practical change required: new roles, revised approvals, cleaner data practices, different reporting rhythms and a reduced reliance on personal spreadsheets.
Executives should visibly sponsor these changes and explain the reason for them. Teams are more likely to adopt a new process when they understand how it reduces duplicate work, protects customers, improves accountability or gives them better information to act on. Training must be role-based and supported by practical guidance during the first reporting cycles, not treated as a one-off event before go-live.
The right ERP decision is not the one that promises the longest feature list. It is the one that gives your organisation clearer control, more reliable information and a workable foundation for responsible growth. Select with the future operating model in view, then hold every product, partner and design choice to the outcomes that matter most.