A practical ERP roadmap starts with a clear map of actual work, not a list of desired features. The team first needs to establish process flow, data, exceptions, responsibilities and integrations. It can then translate findings into a target process state, dependencies and delivery phases. A sound ERP modernisation plan separates corrections with an immediate effect from changes that require a new data model, integration or change in accountability.
An ERP roadmap supports decisions about implementation sequence. It should answer several practical questions:
Without these answers, a roadmap often becomes a sequence of technical activities: migration, configuration, development and testing. Such a plan can be detailed while still failing to address the cause of a problem. If sales enters data under different rules, for example, faster transfer of orders into production only speeds up the transfer of inconsistent data.
The purpose of a current and target state map is not to prove that people work incorrectly. Its purpose is to describe actual work, including the workarounds that keep operations running, and to decide which of them should remain, be standardised or be removed.
The initial map should follow work from trigger to completion, rather than follow the organisation chart. For procurement, it may start with a material requirement and continue through a request, approval, purchase order, goods receipt, invoice and liability entry. For manufacturing, the flow may cover planning, material issue, labour reporting, quality control, inventory movement and costing.
For each step, record:
It is important to distinguish the documented process from the actual process. An instruction may state that an order is entered in the ERP, while the sales representative first manages the agreement through email, a spreadsheet or another system. An instruction may require approval, while the actual decision happens by phone and the approval is entered later. The roadmap must start from the real picture because it reveals operational dependencies.
Problems in ERP projects often appear to be technical, although they begin with unclear data ownership. If nobody is accountable for the item, customer, supplier, bill of materials or work-centre master data, the system will eventually contain duplicates, outdated values and local exceptions.
For critical data, define:
This decision directly determines project sequence. It is not sensible to expand an integration before deciding which system owns critical data. A new report is not stable until metric definitions and data sources are aligned.
Do not describe an integration only through system names and a technical interface. Record which business event transfers the data, which field is transferred, when the transfer occurs, what happens on error and who resolves the discrepancy.
For example, transferring an order from a sales system into ERP may raise questions about price, tax code, delivery date, customer status and changes after confirmation. If some of this data changes in both systems, the issue is not only the integration. The issue is an undefined source of truth and unclear responsibility for change.
A target process state does not need to be a perfect picture of the future. It needs enough precision to support change decisions. It describes the future workflow, rules, responsibilities, data and required controls.
For each gap between the current and target state, formulate the change as a business decision. Instead of a broad item such as "digitise approvals", it is more useful to state that a purchase request receives an owner, the amount determines the approval level, approval leaves an auditable record, and a purchase order is created only after the appropriate status is reached.
This description helps separate four types of change:
One finding can require several types of change. Manual entry of a bill of materials, for example, may require organised item master data, a clear owner for the bill of materials, a change rule and ERP functionality for version control. The roadmap should show this connection rather than treat each item as an unrelated requirement.
A practical ERP roadmap often has three levels of work.
Quick corrections solve a clear problem with limited system change and without creating future debt. They may include removing duplicate entry, standardising a mandatory data field, clarifying approval responsibility or producing a simpler report from an already reliable source.
Not every small change is a quick correction. If a temporary rule increases the number of local exceptions or creates another parallel record, it can make later modernisation harder. It is useful to add a retirement condition for such a temporary solution to the roadmap.
This phase creates conditions for larger changes. It usually covers master data, data definitions, business rules, responsibilities and acceptance criteria. It also includes decisions about which system owns which data.
Foundation work often appears less visible than a new feature, but it determines the reliability of later work. Skipping this phase usually moves the issue into migration, testing or daily user work.
Structural changes include broader process redesign, ERP functionality introduction or modernisation, migrations and integrations. They require defined scope, a business owner, test scenarios, transition decisions and an operating plan after go-live.
For more complex processes, it can be useful to divide the phase by business domain, such as order to cash, procure to pay or production planning to costing. The split is meaningful only when each domain can operate stably after transition and when dependencies are openly stated.
Assess five questions for every change:
The final question is particularly important. Acceptance should not be reduced to technical testing. For a material-issue process, acceptance may include accurate inventory status, a recorded user, the ability to process an exception and a reconciled trail for accounting. This connects the requirement to a business outcome without relying on broad statements.
Assume a team wants to connect a sales order, production planning, warehouse activity and invoicing. It may be tempting to develop the order transfer first. A more reasonable sequence can begin by checking item master data, units of measure, price rules and data owners. The next step is agreement on order statuses and the point at which an order becomes binding for planning.
Only then does it make sense to define the data transfer, order-change handling, error behaviour and successful-transfer control. The next phase can connect material requirements and warehouse issue, followed by invoicing and the accounting trail. This sequence may not provide the fastest visible integration, but it reduces the risk of moving unchecked or contradictory data through several processes.
A roadmap is not a fixed promise of every date. Dependencies may change after closer data analysis, discovery of exceptions or a decision by an external partner. Each phase should therefore contain assumptions, open decisions and a readiness criterion for the next step.
It is also not useful to standardise every local exception immediately. Some exceptions protect a customer relationship, a specific manufacturing practice or a legal requirement. Before removal, establish its purpose, frequency, owner and risk. Standardisation without this review can move work from the system back into spreadsheets and informal channels.
The largest trade-off is usually between speed and preparation. Analysis that runs too long delays value, but early implementation without decisions on data and accountability increases rework. A good ERP modernisation plan is therefore not a maximally detailed document. It is a working instrument that clearly shows what happens now, what waits for prerequisites and who removes blockers.
Before selecting a solution or locking the scope, bring together process owners, data owners and people who perform the operational steps. For one priority process flow, create the current state, target state and a list of gaps with dependencies. Then classify every item as a quick correction, foundation activity or structural change.
If the team does not yet have a reliable view of processes and priorities, ERP and process screening can provide a structured starting point. For processes that cross sales, manufacturing, warehouse and accounting, it is useful to view them as connected operations rather than separate departmental requirements.