Readiness is a decision about conditions, not enthusiasm
An ERP programme is ready to move when the organisation can explain the operating outcome, scope, decision rights, data condition, integration boundary and support model well enough to test them. A signed budget and a preferred platform do not establish those conditions. They only show that a commercial decision is approaching.
Treat readiness as a set of evidence-backed gates. Each gate should have an owner, an inspectable artefact and a consequence if it remains open. A vague amber status invites negotiation at the steering meeting. A gate that states which process, data sample or authority is missing makes the next action clear.
The aim is not to remove every uncertainty before discovery. It is to distinguish uncertainties that the implementation can safely resolve from omissions that would make design, migration or acceptance arbitrary. Readiness protects the programme from learning basic facts after commitments have become expensive to reverse.
| Readiness area | Minimum evidence | Decision if absent |
|---|---|---|
| Outcome and scope | Named journeys, entities, locations and exclusions | Reframe the programme |
| Process ownership | Owners and exception decisions | Resolve authority |
| Data | Profiled samples and accountable sources | Run a data discovery |
| Integration | System map, interfaces and failure paths | Bound technical discovery |
| Operating model | Support, change and access responsibilities | Design ownership first |
Write the operating outcome in observable terms
Start with the decisions and transactions that must improve. “Replace the legacy ERP” describes an asset change, not a business outcome. A useful statement names who performs the work, where delay or error occurs, what must become different and which measure would show a material improvement.
Connect every major module to that statement. Finance, procurement, inventory, projects and reporting should not enter scope because they appear in a vendor catalogue. Record the operating problem each capability addresses and the dependency it creates. This exposes modules that can be deferred and requirements that are really policy questions.
Keep benefits conditional. Faster close, better stock visibility or fewer manual reconciliations depend on process, data and adoption changes that software alone cannot guarantee. Record the baseline, proposed mechanism and evidence needed after rollout instead of turning an aspiration into a promised saving.
Map scope by end-to-end journey
Department lists hide the handoffs where ERP work becomes difficult. Map a small set of end-to-end journeys such as quote to cash, purchase to pay, hire to retire or record to report. Include triggers, approvals, exceptions, master data, documents, interfaces and the point where the outcome becomes usable.
For each journey, identify variants by entity, country, channel, product family and transaction type. Do not assume that a global process is identical because the same verb is used. A local tax rule, fulfilment model or approval threshold may change the data and control design even when the screen appears familiar.
Publish explicit exclusions. If a warehouse, acquired entity or specialist process is deferred, state how it will operate and exchange data during the transition. An exclusion without an interim design returns later as an emergency integration or a shadow spreadsheet.
Confirm process owners can make design decisions
A workshop attendee is not automatically a process owner. Name who can decide policy, approve a standard, accept a controlled variation and resolve a cross-functional conflict. Implementation stalls when every team can request a change but nobody can choose between incompatible requirements.
Create a decision calendar for the first design horizon. Include chart of accounts, product and supplier governance, approval limits, role boundaries, reporting definitions and the treatment of exceptions. Give each item a latest useful decision date so unresolved questions do not silently consume testing time.
Use the site’s four-stage operating process to separate evidence gathering from commitment. A concise decision record should state the question, options, evidence, choice, owner and review trigger. Meeting minutes are not a substitute because they rarely show which statement became authoritative.
Profile data before planning migration waves
Inventory master and transactional data by source, owner, volume, age, sensitivity and use. Then profile representative extracts for duplicates, missing keys, invalid relationships, inconsistent units and values that no longer match the operating rule. A field list cannot reveal whether the records can support the target process.
Decide what must be cleansed at source, transformed during migration, created in the target or retained outside it. Assign ownership for every rule and preserve the reason. Technical teams can implement a mapping, but business owners must decide whether two records represent the same customer, product or supplier.
Run an early mock load with reconciliation. Compare counts, control totals, relationships and a sample of priority journeys. The purpose is to test the migration method and expose ownership gaps, not to produce a theatrical percentage complete.
Make the integration boundary inspectable
List every system that sends, receives or depends on ERP data. Record the business purpose, interface method, frequency, owner, authentication, data classification, failure behaviour and recovery route. Include manual files and local automations because they often carry critical work that architecture diagrams omit.
The GOV.UK guidance on choosing technology recommends choices that preserve the ability to adapt and change direction. Its public-service context differs, but the principle is useful for ERP architecture: document where a proprietary interface, data model or operating dependency makes later change harder.
Test one representative journey across the proposed boundary before finalising the delivery plan. Include an error, a delayed message and a changed record. A happy-path payload proves connectivity, while an operational scenario shows whether teams can detect, reconcile and recover the service.
Design roles, controls and support together
Define who requests access, approves it, provisions roles, reviews conflicts and removes access when responsibilities change. Use real job activities rather than copying a generic role catalogue. A technically valid permission set can still fail if it prevents ordinary work or combines authority that policy requires to remain separate.
Connect preventive controls with evidence and exception handling. An automated approval is useful only when the rule is understood, changes are governed and the owner can inspect what happened. Identify which controls require configuration, workflow, reporting, operating review or a combination of them.
Prepare the service model before user acceptance testing. Name support channels, priorities, escalation, vendor interfaces, monitoring, knowledge ownership and the route for recurring problems to influence design. The service desk management pathway provides a useful frame for that ownership.
Build an evidence-led implementation plan
Sequence work around risk reduction rather than module labels. A data domain with uncertain ownership, a critical integration and a high-volume exception may deserve attention before a simpler visible feature. Each phase should produce an inspectable result that changes the confidence of a future decision.
Use a bounded enterprise software pilot for assumptions that can be tested without creating a hidden production service. Define representative users, journeys, controls, data, measures and a stop rule. Record what the pilot cannot prove about scale or operating duration.
Maintain a dependency map across design, configuration, data, integration, testing, learning and support. A date is credible only when the evidence and decision needed before it are visible. Treat schedule compression that removes validation as a change in risk, not as free acceleration.
Use a firm readiness gate
Before approving the main implementation commitment, review the outcome, scope, owners, data profile, integration map, role design, support model, phased evidence and unresolved risks in one pack. Confirm that the pack agrees with the commercial scope and does not depend on capabilities the supplier has only described informally.
Classify every open item as safe discovery, commitment condition or blocker. Safe discovery has a bounded method and does not invalidate the business case. A condition must be resolved before a named contractual or delivery event. A blocker prevents a responsible commitment because the programme cannot yet explain its exposure.
Readiness does not mean the organisation knows the final configuration. It means the next investment has a clear purpose, bounded uncertainty and owners capable of learning without losing control of the operating service. That is a stronger start than a detailed schedule built on unexamined assumptions.
Cross-check readiness against configuration and cost evidence
Use NIST SP 800-128 on security-focused configuration management to challenge whether the programme has identified the configurations, monitoring and responsibilities that will protect business functionality. Its US federal scope does not make it a universal ERP method, but it exposes ownership and baseline questions that implementation plans often defer.
Review the cost assumptions with the US GAO Cost Estimating and Assessment Guide. The guide is written for public programmes, yet its emphasis on scope, technical baseline, assumptions, sensitivity and updates helps test whether an ERP business case can be inspected and revised rather than merely approved.
If these checks expose an unowned configuration area or a cost driver with no evidence, route it to a bounded discovery action before commitment. Readiness improves when uncertainty receives a method, owner and deadline, not when the steering pack changes its colour.
