An ERP programme can fail well before configuration begins. It usually fails when a business selects a platform, budget or timeline before it has agreed on the operational problems it is solving. So, what does ERP discovery include? It includes the structured work needed to understand current operations, define future requirements, expose delivery risks and create a defensible implementation plan.
For organisations in manufacturing, aged care, distribution, hospitality or government, discovery is not an administrative pre-project phase. It is where operational knowledge is translated into decisions that technology, finance and frontline teams can stand behind. Done properly, it creates clarity without pretending every detail can be resolved upfront.
What Does ERP Discovery Include in Practice?
ERP discovery brings business leaders, process owners, IT teams and implementation specialists into a shared assessment of the organisation’s needs. The objective is not simply to gather a long list of requested features. It is to identify what must change, what should remain stable and what the organisation can realistically deliver.
The depth of discovery depends on the size of the organisation, the number of sites, the level of integration required and whether the project is a new implementation, an upgrade or a replacement of several disconnected systems. A single-site manufacturer with standard finance and inventory processes will need a different level of assessment from an aged care provider managing resident services, workforce requirements, funding obligations and compliance reporting.
A disciplined discovery typically covers the following areas.
- Business objectives, success measures and programme scope
- Current-state processes, systems, pain points and workarounds
- Future-state process design and prioritised requirements
- Data quality, migration needs and reporting requirements
- Integrations, infrastructure, cybersecurity and access controls
- Delivery governance, change management, resourcing and training
- Implementation options, estimates, risks and a phased roadmap
These workstreams are connected. A decision about standardising purchasing, for example, can affect approval workflows, supplier master data, budget controls, reporting and employee training. Discovery gives the project team a way to assess those effects before they become costly changes during delivery.
Establishing the Business Case and Scope
The first task is to understand why the organisation is considering ERP change now. Leaders may point to poor inventory visibility, manual finance processes, inability to consolidate reporting, ageing technology, compliance exposure or barriers to growth. These are valid starting points, but they must be converted into specific outcomes.
A useful discovery asks questions such as: Which decisions are currently delayed by incomplete information? Which processes create rework or control failures? What growth, regulatory or service commitments must the new platform support? How will the organisation measure improvement after go-live?
This work also defines the boundaries of the initiative. It determines which legal entities, business units, sites and functions are in scope, as well as what is deliberately deferred. Scope discipline matters because an ERP project can absorb almost any adjacent improvement idea. A future-state ambition is not automatically a first-release requirement.
Prioritising Requirements Rather Than Collecting Wishes
Requirements workshops should involve the people who perform and manage the work, not only senior sponsors. Finance, operations, procurement, warehousing, customer service, HR and IT often see different parts of the same process. Their input reveals where hand-offs fail and where local workarounds have become normal practice.
The output should distinguish between critical operational requirements, compliance or control requirements, valuable improvements and lower-priority preferences. This prevents the project from treating every request as equally urgent.
There is a trade-off here. Excessive customisation may preserve familiar processes, but it can increase cost, complicate upgrades and create long-term support dependency. Adopting standard ERP processes can reduce that burden, yet it may require genuine change in roles, approvals or ways of working. Discovery makes that choice visible and gives leadership a basis for deciding where configuration, process change or tailored development is justified.
Mapping Current and Future Processes
Process mapping is central to ERP discovery because systems do not operate in isolation. A sales order can move through pricing, credit checks, supply planning, picking, dispatch, invoicing and revenue reporting. If the project focuses on one screen or one department at a time, it can miss controls and dependencies that matter across the full process.
Current-state mapping identifies process variations, bottlenecks, duplicate data entry, spreadsheet dependencies and informal approvals. These are not necessarily signs of poor performance. In many organisations, they are practical responses to limitations in legacy systems. However, the implementation team needs to understand why each workaround exists before removing it.
Future-state design then establishes how the organisation intends to work with the new ERP. It should address standard processes as well as important exceptions, such as urgent purchasing, complex manufacturing orders, resident billing adjustments or government approval pathways. The aim is an agreed operating model, not a theoretical ideal that staff cannot apply under normal pressure.
Assessing Data, Integrations and Technical Readiness
ERP projects often underestimate the condition of existing data. Customer, supplier, item, employee and asset records may be duplicated, incomplete or governed differently across business units. Historical transactions may need to be retained for reporting, audit or operational reference even when they are not migrated into the new system.
Discovery defines which data will move, what must be cleansed, who owns each data domain and how migration will be validated. It also establishes a realistic approach to archiving and historical access. Migrating every record is rarely the best decision. The right approach depends on regulatory requirements, reporting needs, data quality and the effort required to make legacy information usable.
Integration assessment is equally important. ERP commonly connects with payroll, banking, point-of-sale systems, customer portals, warehouse technology, production equipment, CRM, document management and business intelligence tools. For each integration, discovery should identify the business purpose, source of truth, data exchanged, frequency, failure handling and ownership.
Technical readiness includes identity and access management, cybersecurity controls, hosting preferences, network capability, backup expectations and disaster recovery requirements. For regulated industries and public-sector environments, governance, auditability and data residency considerations may significantly influence solution design.
Planning People, Governance and Change
ERP transformation is a business change programme supported by technology. The best process design will not deliver value if decision-makers are unavailable, process owners do not have authority, or staff receive training too late to adopt new responsibilities.
Discovery establishes programme governance: the executive sponsor, steering group, business process owners, project manager, technical leads and escalation paths. It should also identify the internal subject matter experts required for workshops, testing, data validation and training. These people need protected time. Asking them to run business-as-usual workloads while carrying a major implementation creates avoidable risk.
Change planning starts early. Stakeholder analysis identifies who will be affected, what will change for them and where resistance or uncertainty may emerge. Training needs should be considered by role, location and system access level. In multi-site organisations, local champions can provide practical feedback and support adoption, but only if their responsibilities are clear.
The Decisions and Deliverables That Matter
A quality discovery phase should end with more than workshop notes. It should give sponsors a coherent decision pack that supports investment approval and delivery mobilisation. While formats vary, the key deliverables generally include a documented scope, future-state process designs, prioritised requirements, data and integration assessment, solution approach, risk register, governance model, change approach, indicative delivery plan and budget estimate.
The estimate should state its assumptions. Early estimates are necessarily less precise than figures produced after detailed design, particularly where legacy data, integrations or tailored functionality are complex. Presenting a range with clear assumptions is more responsible than offering false certainty.
For Epicor implementations in manufacturing and aged care environments, a partner with sector knowledge can help distinguish genuine industry requirements from inherited habits that no longer serve the organisation. SoftLabs approaches discovery as the foundation for accountable delivery, bringing business analysis, technical assessment and implementation experience into the same conversation.
When Discovery Needs More Time
Not every programme needs a lengthy discovery. A focused assessment may be sufficient for an organisation with clear processes, limited integrations and a proven template. Conversely, additional time is warranted where multiple entities operate differently, data ownership is unclear, compliance obligations are significant or leaders are considering major process standardisation.
The cost of deeper discovery must be weighed against the cost of discovering critical issues midway through build or testing. The right question is not whether discovery can be made shorter. It is whether it provides enough evidence for the organisation to commit with confidence.
A useful next step is to ask each process owner one practical question: what must work reliably on the first business day after go-live? Their answers will often reveal the priorities that should shape the entire ERP discovery programme.
