An ERP implementation can begin with an approved budget, an experienced delivery partner and a convincing demonstration while still lacking the conditions for success. The unresolved questions are usually familiar: whose process will become the standard, what the business is willing to stop doing, who owns disputed data, and which operational outcomes justify the disruption.
These are expensive questions to discover after contracts, milestones and staffing commitments are fixed. Implementation then becomes a sequence of negotiations disguised as configuration decisions. Workshops can reopen the business model, and exceptions can acquire technical solutions because nobody has authority to remove their underlying causes.
The practical implication is straightforward. Before committing to the main implementation, leaders should authorize a bounded readiness phase that produces decisions and evidence. Its purpose is to expose the assumptions on which cost, scope and benefits depend. Completing a requirements spreadsheet is insufficient if its most important rows conceal disagreement.
The earliest failure is an unmade business decision
Consider the request to introduce a common approval workflow. Finance expects every purchase above a threshold to require central review. Operations expects urgent materials to bypass that queue. Subsidiary leaders expect their delegated authority to survive. All three can endorse “standardized procurement” while imagining incompatible designs.
A requirements workshop may capture all their preferences. A delivery team can estimate the resulting workflow. Neither activity resolves which authority model the company wants. If the disagreement is deferred, the implementation absorbs its consequences through extra branches, repeated testing and further approval meetings.
The useful question is therefore not whether the requirement has been documented. Ask whether a named executive has decided the trade-off and whether affected teams understand its consequences. A decision should specify scope, permitted exceptions, accountability and the conditions under which it can be reopened. The project should preserve legitimate disagreement in a decision log rather than allow it to reappear as an unexplained defect.
This emphasis has a long-established foundation. The US Government Accountability Office’s Business Process Reengineering Assessment Guide, published in 1997, puts customer needs, performance problems, strategic goals and organizational change within the scope of process redesign. It does not reduce improvement to deploying an application. That public-sector guidance is useful as a management reference, although it is not evidence of a universal commercial ERP failure rate.
A business case needs a mechanism
“Better visibility” is an aspiration. It becomes an investable benefit only when a person can explain how a different operating practice changes an outcome.
For example, a daily view of overdue receivables may support earlier collection calls. The benefit depends on invoice accuracy, dispute ownership, collector capacity and customer behavior. A new dashboard cannot independently produce the cash outcome. If the implementation budget funds reporting but the operating plan provides no time for follow-up, the mechanism is incomplete.
For each major benefit, record five things: the current problem, the operational change, the person who can make that change, the observable measure and the principal dependency. Add the evidence supporting the baseline. A benefit owner should have authority over the behavior that creates the benefit, rather than merely responsibility for reporting it.
Separate cashable savings from released capacity. Reducing repetitive work creates useful time, but it does not automatically reduce payroll. A credible case can value capacity without pretending it is a cash saving. It should say which additional work that time will support and who will verify that the capacity became available.
Finally, describe the alternative to the implementation. Targeted process repair, selective integration, a smaller deployment or delayed replacement may create enough value at lower risk. A business case that compares only competing vendors has already excluded an important class of decisions.
Data uncertainty is a scope uncertainty
A data migration plan often lists objects: customers, suppliers, products, balances and open transactions. The harder questions concern meaning and authority. Does an inactive customer remain eligible for a return? Which source establishes the contractual payment terms? Who can approve merging two suppliers that share an address but have different legal identities?
An estimate based on record counts can miss this work. Ten thousand consistent records may require less effort than a few hundred commercially sensitive conflicts. Early profiling should therefore test business rules and exceptions, not simply count missing fields.
The Government Data Quality Framework, published by the UK government in 2020, treats quality as fitness for purpose and emphasizes accountability and improvement at source. For ERP readiness, that suggests defining what each critical dataset must support before declaring it ready. A customer file fit for marketing segmentation may still be unsuitable for credit control.
Take a representative sample of critical data through a provisional transformation. Reconcile it to the source, ask business owners to review exceptions, and measure how long resolution actually takes. Use those observations to revise the migration estimate. If nobody can settle a conflict, record an ownership gap rather than assign an optimistic cleansing completion date.
Test the delivery model before trusting its calendar
A project calendar can look credible because activities are detailed. Detail is not the same as executable sequencing. A design workshop cannot conclude if the policy decision it depends on is scheduled later. A test cycle cannot validate realistic accounting if the opening balances have not been reconciled. A process owner cannot devote three days a week to design while remaining fully accountable for an unchanged operational workload.
Readiness should include a capacity plan for the business, not only for the implementation partner. Identify named people, expected availability, backfill arrangements and escalation routes. Ask managers to agree what work will stop or move while their staff contribute. Generic promises of “business participation” should not underpin a fixed launch date.
GAO’s 2010 review of Department of Defense business-system modernization recommended stronger integrated schedules, cost analysis and quantitative measures of intended business capabilities. Its original recommendations reinforce the relationship between realistic plans and accountability. The complexity of those government programs differs from a midmarket business, so their experience should inform questions rather than supply a borrowed prediction of commercial results.
A supplier should be able to explain the assumptions behind its estimate, the work excluded from its scope and the conditions that trigger replanning. Procurement pressure that removes visible contingency without removing uncertainty creates a cleaner commercial document and a weaker operating plan.
A hypothetical distributor changes the decision
Imagine a distributor preparing to replace finance, purchasing and inventory systems across three warehouses. The following figures and circumstances are illustrative, not client results.
Its proposed case promises a faster close and fewer urgent replenishment orders. The initial schedule assumes common product records, one purchasing policy and warehouse managers available for weekly workshops. A four-week readiness exercise tests those assumptions before the main implementation contract is finalized.
The team selects two product families and traces receipts, transfers, returns and supplier invoices. It finds that one warehouse treats a carton as the stocking unit while another records individual items. Historical conversion factors are missing for several active products. Finance also discovers that goods received near month-end are recognized differently across locations.
Those findings change the required decisions. Procurement owns the approved purchasing units; warehouse operations owns physical handling units; finance owns valuation rules. A jointly approved conversion table connects the three. Disputed conversions enter an exception queue with a commercial owner, rather than being silently inferred by the migration team.
The exercise also finds that warehouse managers cannot support the planned workshop calendar during a seasonal peak. Leadership has three feasible choices: fund backfill, narrow the first deployment or move the date. It chooses a smaller first release covering finance and one warehouse, with explicit interfaces to the remaining locations.
This is not automatically the best answer for every distributor. A shared inventory allocation requirement might make a split deployment too risky. The important result is that leadership makes the trade-off with evidence, before the original date becomes a public promise.
For the revised release, the acceptance criteria include reconciled opening inventory, successful processing of the sampled exceptions and a demonstrated month-end receipt cutoff. The business case now links faster close to an agreed operational practice. It also names the team responsible for maintaining conversion rules after launch. Readiness has changed the investment, not merely improved its documentation.
Use a readiness gate that can actually stop the project
A practical gate can fit on a single decision sheet. The following is a working heuristic, not a certified maturity model or a statistically validated scoring system.
- Outcome: Can each major benefit be connected to a measurable operational change and an accountable owner?
- Process: Have the consequential cross-functional decisions been made, including permitted local variation?
- Data: Has a representative sample been profiled, transformed and reconciled, with unresolved exceptions assigned?
- Capacity: Have business contributors and their managers committed realistic availability?
- Delivery: Are dependencies, exclusions and uncertain estimates visible in the implementation plan?
- Operation: Is there a credible owner for support, controls, releases and data maintenance after launch?
Avoid averaging these questions into one reassuring score. A serious unresolved financial-control issue should not be canceled out by excellent training materials. Classify each gap by consequence: blocks commitment, permits commitment with a dated condition, or can safely be resolved during delivery. Assign one person to accept each residual risk.
The board or steering group should receive the recommendation, unresolved assumptions and alternatives together. It should be possible to approve a limited next stage without pretending that the whole program is ready. Conversely, “conditional approval” should not become a device for starting all work while the conditions remain untouched.
Readiness has a stopping rule
There is a genuine counterargument: discovery can become expensive paralysis. Teams can spend months refining process maps while old systems continue to create risk. Some requirements become clear only when users encounter a working configuration. Excessive preparation can harden untested assumptions as easily as insufficient preparation can hide them.
The answer is a bounded readiness phase with explicit questions and a stopping rule. Investigate uncertainty that could materially change scope, cost, sequence or the operating model. Leave reversible configuration choices for implementation. Use representative prototypes to test contentious assumptions rather than attempting to describe every future screen.
A business facing an unsupported system or an imminent acquisition may have little time. In that case, shorten the commitment horizon. Fund the minimum safe transition, protect critical controls and make deferred decisions explicit. Urgency changes the sequencing of risk management; it does not make unowned risks disappear.
The best pre-implementation work produces a clearer decision: proceed, proceed with a smaller first release, repair a prerequisite, or reconsider the investment. A project that pauses because its assumptions failed a cheap test has protected value. The more dangerous program is the one that interprets a signed contract as proof that the business is ready.
