An ERP roadmap should sequence coherent business capabilities, not a catalogue of modules. Each wave must leave the organisation with an operable process, authoritative data, controlled interfaces and a measurable outcome.
Start from business constraints and dependency order. A quick finance installation can be sensible; a “finance-first” wave that creates years of temporary integrations and duplicate master data is not.
Define the destination in operating terms
State which decisions and end-to-end processes should improve, which controls must remain, and how the organisation will operate the platform. Describe the target at the level of order, purchase, inventory, project, workforce and financial outcomes rather than “implement ERP.”
Record constraints such as statutory dates, contract expiry, business season, acquisitions, capacity and unacceptable interruption. These shape sequence without becoming automatic deadlines.
Map dependencies before choosing waves
For every capability, identify process owner, master data, upstream and downstream systems, reporting, identity, integration, migration and operational support. Draw dependencies from the evidence needed by one capability to the output of another.
Common hidden dependencies include a product hierarchy needed by orders and finance, customer identifiers shared with CRM, supplier data used by purchasing and payment, and opening balances that rely on unreconciled operational history.
Score candidate waves
| Lens | Question | Evidence |
|---|---|---|
| Value | Which constraint or decision improves? | baseline, target and owner |
| Dependency | What must exist first? | data and interface map |
| Readiness | Can users, data and operations support it? | named capacity and acceptance tests |
| Risk | What is the consequence of failure? | rollback, fallback and exposure window |
| Coherence | Does the wave leave a complete service? | end-to-end scenario |
Prefer vertical capability slices
A vertical slice includes the process, roles, data, configuration, integrations, reporting, training and support required for one useful outcome. A horizontal “configure all modules, migrate all data, then train everyone” sequence delays learning and concentrates risk.
Some foundation work is unavoidable. Keep it tied to the first capabilities that will consume it and define acceptance; otherwise foundation becomes an open-ended technical programme.
Choose what to standardise now
ERP programmes expose local variation. Classify each difference as legally required, customer-valued, transitional or avoidable. Decide the common rule before configuration and record justified exceptions with owners and expiry.
Do not force every global decision into wave one. Standardise what the current capability needs, while protecting identifiers and design choices required by later waves.
Sequence data as a product
Assign authority and stewardship for customers, suppliers, items, accounts, locations and other shared objects. Schedule definition, cleaning, migration rehearsal and operating controls before dependent transactions.
Avoid a single late “data migration” bar. Each wave needs its own source boundary, control totals, exception process and post-launch ownership.
Build a roadmap with gates
- Scope gate: outcome, boundary, owner and exclusions agreed.
- Design gate: process, data, integration and control decisions accepted.
- Build gate: configuration and interfaces pass representative scenarios.
- Readiness gate: migration, users, support, recovery and cutover rehearsed.
- Value gate: stabilisation evidence supports expansion.
A later wave should not inherit unresolved critical defects simply because its calendar date arrived.
Plan coexistence explicitly
During a phased rollout, define system of record, interface timing, reconciliation and user entry point for every process crossing old and new systems. Limit the life of manual bridges and track their cost and error.
Include retirement activities in the roadmap: archive, retention, access removal, contract exit and support closure. A roadmap that only adds systems never completes the transformation.
Keep governance proportional to the wave
Give each wave a business owner, delivery owner and service owner. Define who can change scope, accept residual risk and decide go-live or delay. Central governance should protect shared architecture, data and control decisions while allowing the wave team to resolve local delivery detail.
Publish a short decision log showing date, options, evidence, owner and affected waves. This reduces repeated debate and exposes when a decision made for the first release is being treated as a permanent enterprise rule without review.
Test the roadmap against disruption
Run a tabletop scenario in which a critical data source is late, a location cannot cut over, or the first wave needs extended stabilisation. Determine which later work can continue, which dependencies move and how coexistence remains controlled. If every delay collapses the full programme, the waves are dates rather than independent capabilities.
Also test an early success: if adoption and value appear sooner than expected, confirm whether the organisation has capacity to accelerate responsibly or whether operating teams need time to absorb change.
Review sequence using evidence
At each wave, compare actual adoption, cycle time, exceptions, data quality, support demand and operating effort with the baseline. Reorder later work when assumptions change. Preserve the reason so stakeholders understand why the roadmap moved.
The roadmap is credible when each wave has a useful outcome, safe boundary and owner—and when stopping after any wave would leave an operable, understood estate rather than half a system.
Maintain two views: a concise outcome roadmap for business governance and a dependency plan for delivery teams. They should reconcile at every gate. Hiding detailed risk behind a simple slide is dangerous; making every stakeholder read thousands of tasks is equally ineffective.