Selecting an ERP commits an organisation to a way of working. The evaluation should therefore examine process ownership before feature lists.
Most technology programmes are scoped as delivery problems. Requirements are gathered, effort is estimated and a build begins. The harder question — what should change about how the organisation operates — is left unresolved, and the system inherits the ambiguity.
A useful starting point is to separate three things: the business objective, the operating process required to meet it, and the software that supports that process. When those are conflated, teams negotiate features instead of outcomes.
Structure resolves this. Map how work happens today, identify where information is re-entered or reconciled, and decide which processes should be standardised before any platform decision is made. The result is a smaller, sharper build with a clearer measure of success.
This is the work we do before we write software. It is also why our engagements begin with a Strategic Discovery rather than a requirements document.