A new ERP can be one of the largest operational investments an organisation makes, yet many programs still begin with software requirements rather than business decisions. That is why strategy and a new ERP have to be linked to deliver value: the system must enable the operating model the organisation intends to run, not simply replace ageing technology or digitise inefficient processes.
For a CFO, this may mean faster and more reliable reporting, stronger cash control and less dependence on spreadsheets. For a COO, it may mean consistent processes across sites, better inventory visibility and the capacity to scale without adding unnecessary administration. For boards, it means clearer accountability, dependable information and confidence that growth is not outpacing governance.
Without this connection, an ERP implementation can still go live on time and on budget while failing to improve performance. The technology works, but the business has not materially changed.
The ERP is an operating model decision
Enterprise resource planning software is often described as a finance or IT project. It is neither, at least not primarily. It is an operating model decision because it determines how core business activities are structured, controlled, recorded and reported.
A platform such as Microsoft Dynamics 365 Business Central affects how a purchase is approved, when revenue is recognised, how inventory is replenished, who can amend master data, and what leaders see when they review performance. These are management decisions with commercial and governance consequences.
If the organisation’s strategy is to expand through acquisition, the ERP must support a disciplined approach to integrating entities, charts of accounts, reporting dimensions and delegated authority. If the strategy is to protect margin in a volatile supply environment, the system needs to provide timely visibility of demand, stock, supplier performance and landed costs. If customer service is the differentiator, the process design must give teams accurate, usable information at the point of action.
The question is not simply, “What features do we need?” It is, “What must this organisation be able to do better, more consistently and with greater control?”
Why strategy and a new ERP must be linked
Strategy establishes the choices an organisation makes about where to compete, how to create value, what risks it will accept and which capabilities it must build. An ERP translates many of those choices into everyday workflows, data structures, approval rules and management reporting.
That translation matters because strategic intent is lost when it is not reflected in day-to-day operations. A business may state that it wants tighter working capital management, for example, but achieve little if credit processes, purchasing controls, inventory policies and cash forecasting continue to sit in disconnected systems and personal spreadsheets.
Linking strategy and ERP design creates a clear line of sight between investment and outcomes. It allows leaders to define which measures should improve, who owns the relevant process, what decisions need better information and which controls cannot be compromised. It also gives implementation teams a basis for resolving competing requests. Not every stakeholder preference should become a configuration requirement.
This is particularly relevant in complex Australian organisations where operations span multiple legal entities, locations, funding models, regulatory obligations or stakeholder groups. Standardising everything may not be appropriate. Equally, allowing every business unit to retain its own methods can create cost, reporting risk and fragmented accountability. Strategy provides the criteria for deciding where consistency is essential and where local flexibility adds value.
Start with the value case, not the software demonstration
Software demonstrations can be persuasive because modern ERP platforms present a wide range of capabilities. However, capability is not the same as value. A function only creates value when it changes a meaningful business outcome and is adopted within a workable process.
Before selecting or configuring an ERP, leadership should establish a practical value case. This does not require a lengthy theoretical strategy exercise. It requires agreement on the performance problems that matter most and the capabilities required to address them.
For example, an organisation may identify that month-end reporting takes too long because finance teams reconcile data from separate systems. The strategic issue is not merely reporting speed. It may be that leaders are making pricing, investment and workforce decisions using information that is incomplete or several weeks old. The ERP response could include a unified chart of accounts, clearer data ownership, automated intercompany processes and role-based reporting.
Similarly, a distribution business dealing with stock-outs and excess inventory may not need more reports. It may need agreed replenishment rules, reliable item data, defined service levels and stronger accountability for purchasing decisions. The system should reinforce those disciplines, not provide a more polished way to work around their absence.
A well-formed value case usually connects ERP investment to a manageable set of outcomes: improved margin visibility, reduced manual effort, stronger compliance, more accurate forecasting, faster close cycles, lower inventory exposure or improved service performance. These outcomes should be measurable, even where the initial baseline is imperfect.
Process design is where value is won or lost
Replacing old software without redesigning processes is a common way to preserve old problems at greater cost. The pressure to replicate existing workflows is understandable. Teams are busy, and familiar processes feel safer during change. Yet a like-for-like migration often embeds manual hand-offs, weak controls and inconsistent data practices for another decade.
Process redesign does not mean pursuing standardisation for its own sake. It means examining whether each process supports the organisation’s strategic priorities, control environment and customer commitments. In some areas, a standard process will reduce cost and risk. In others, a carefully designed exception is commercially justified.
Finance is a good example. Standard purchase-to-pay controls may be appropriate across most of the organisation, particularly where delegated authority, budget control and auditability are priorities. A project-based operation, however, may need more tailored workflows for contract variations, project costing or milestone billing. The right design balances usability with governance rather than treating them as opposing objectives.
Leaders should also resist measuring success solely by the number of customised features delivered. Excessive customisation can increase implementation effort, weaken upgrade paths and make the platform dependent on a small group of specialists. Configuration should support genuine competitive or regulatory needs, not preserve preferences that no longer serve the business.
Data, governance and accountability cannot be added later
ERP programs frequently reveal data problems that have been tolerated for years: duplicate customers, inconsistent product codes, unclear ownership of records, missing cost information and different definitions of the same performance measure. These are not technical inconveniences. They are governance issues.
When decision-makers cannot trust the data, they recreate reports outside the system. When teams maintain their own spreadsheets, controls fragment. When no one owns master data, the quality deteriorates again after go-live.
A strategy-led program addresses this early by defining critical data, accountability and decision rights. Which customer, supplier, item, employee and financial data is essential to performance? Who can create or change it? What validation is required? Which metrics must be consistently defined across the organisation?
This work can feel less urgent than system configuration, but it is central to resilience. Accurate, timely data enables leaders to identify deteriorating margins, forecast cash pressure, monitor commitments and respond to disruption before it becomes a larger commercial problem.
Change is a leadership responsibility
ERP adoption is often described as change management, but that phrase can obscure the leadership task involved. Employees need to understand what is changing, why it matters and how new ways of working will be supported. They also need practical training, accessible process guidance and clear escalation paths when issues arise.
More importantly, leaders must model the discipline the new system is intended to create. If executives continue requesting off-system reports, approving exceptions informally or tolerating incomplete data, the organisation receives a clear message that the ERP is optional.
The most effective programs involve operational leaders, finance, technology, risk and people teams from the outset. This integrated approach is consistent with the way i3 Australia works: performance, governance, process and technology are connected issues that require coordinated decisions.
Measure benefits after go-live, not just delivery milestones
A go-live is a transition point, not the end of the investment. The first months should focus on stabilisation, adoption and evidence that expected benefits are emerging. Some benefits, such as reduced manual rework or a faster close, may appear quickly. Others, including improved planning discipline and lower working capital, require sustained management attention.
Benefits should be reviewed against the original value case and assigned to accountable business owners. If expected gains are not appearing, leaders need to determine whether the cause is process design, data quality, training, control settings or a broader operational issue. The answer is rarely “the system needs another report”.
A new ERP delivers its greatest value when it becomes a management platform: one that helps people make better decisions, apply controls consistently and act on reliable information. Treat the program as a strategic operating model initiative, and the technology becomes a practical foundation for stronger performance, not another expensive layer of complexity.