Building an ERP Business Case. Define the benefits, starting measures and people responsible.
An ERP investment deserves approval when leadership can explain which operating conditions will change, who will change them, and how the business will know whether the investment worked. That explanation should survive the removal of every software feature from the presentation.
“Support growth” is a strategic intention. “Allow the existing order-management team to handle the planned transaction mix without extending the exception backlog” is an operating hypothesis. The second statement creates useful questions: what is the current workload, which exceptions consume time, and what must change besides the system?
The investment thesis proposed here makes those questions explicit. It is a practical decision tool, rather than a forecasting formula. Its purpose is to help executives approve a defensible commitment and give delivery teams a consistent basis for making trade-offs after funding.
Begin with the constraint on the business
Write the problem as an observable condition affecting a business outcome. Include the people or transactions affected, the consequence, and the boundary within which it occurs.
For example: “Orders requiring a price exception wait for approval across two departments, leaving customer service unable to confirm a reliable dispatch date.” That statement can be investigated. “Our systems are outdated” cannot explain why a new approval workflow deserves investment.
Trace the condition before prescribing a solution. A delay may originate in ambiguous commercial policy, missing customer data, unavailable approvers, or a technical limitation. A system can support a new process, but it cannot decide which customer promise takes priority. If the root cause remains contested, fund a bounded discovery exercise before committing to the full transformation.
Also distinguish two investment decisions that may share one program. A continuity decision addresses a substantiated need to replace an unsupported or unsuitable operating platform. An improvement decision seeks better performance. The first needs evidence of the constraint and credible replacement options; the second needs a causal argument for the additional benefits. Mandatory replacement does not make every proposed enhancement necessary.
Write the thesis as a chain that can break
Use this sentence as a starting point: “If we change this process for this population, supported by these capabilities and operating decisions, we expect this measured result by this review point, provided these dependencies hold.”
Then document six connected elements:
- Pain: The present operating condition and its consequence.
- Baseline: The current measure, population, period, and known limitations.
- Process change: The decisions, activities, responsibilities, or controls that will work differently.
- Outcome: The improvement leadership wants, including its timing and boundaries.
- Owner: The business leader accountable for changing the process and sustaining the result.
- Evidence: The records and review method that will confirm or challenge the thesis.
The connections matter more than filling every box. Faster invoice production cannot automatically justify a claim about faster cash collection if disputes, customer payment behavior, or approval delays remain unchanged. The benefit owner should explain the missing links or narrow the claim.
Give each link a confidence description: observed, supported by a small trial, assumed, or awaiting evidence. These labels are deliberately qualitative. A percentage attached to confidence can look precise while concealing disagreement over the underlying mechanism. An important assumption should create a research action with an owner, rather than a more optimistic slide.
Establish a baseline people can reproduce
A useful baseline comes with a measurement contract. Define what starts and stops the clock, which transactions count, how exceptions are treated, where the records come from, and who can reproduce the calculation. Preserve the underlying extract or an appropriately controlled reference to it.
For an order-release measure, specify whether elapsed time begins at initial entry or after the order is commercially complete. State whether weekends count. Identify whether cancelled orders, credit holds, and missing customer information are included. Choosing a narrow population can be legitimate, but the boundary must remain visible when the result is reported.
Look at distribution as well as the average. An improvement in routine orders can conceal a worsening tail of difficult orders. Segment by the factors that could change the interpretation, such as channel, location, order type, or approval route. Avoid breaking the population into so many small groups that the result becomes unstable or impossible to maintain.
If the evidence is weak, say so. An interview-based estimate can identify a problem worth investigating. It should not quietly become an audited baseline. The investment decision may include a short measurement phase, with later funding conditional on what that phase establishes.
Separate economic benefit from available time
Reduced handling time creates capacity. Turning that capacity into a financial benefit requires another decision. The organization might absorb growth, reduce temporary labor, reassign work, improve service, or remove a planned hire. Each route needs its own assumptions and accountable owner.
Suppose a team expects to recover eight hours a week from duplicate entry. Multiplying those hours by a loaded employment rate estimates the value of time under a stated convention. It does not establish a reduction in cash expenditure. Unless staffing or spending changes, the cash benefit may be zero while the operational benefit remains valuable.
Keep three benefit types separate in the register: spending that will actually stop or be avoided, capacity that will be redeployed, and operating outcomes that should be measured without forcing an artificial monetary value. Finance should validate the treatment. The same released hour cannot support both an avoided-hire claim and a separate redeployment claim without explaining how the allocation works.
Risk-reduction claims require similar restraint. Identify the failure being addressed, the exposure, the current controls, and the evidence available. Where credible likelihood data is absent, present the decision as a reasoned risk judgment. Do not manufacture an expected-loss calculation merely because the approval template contains a currency field.
Work a hypothetical thesis all the way through
Consider a hypothetical distributor whose commercially complete orders wait for manual release. All figures below are illustrative, not benchmarks or reported results.
A review of 400 qualifying orders over eight weeks finds a median release time of 14 business hours. The team also records orders taking more than two business days. Interviews suggest that unclear approval routing and incomplete price-authority records drive much of the waiting, but the records have not yet proved that explanation.
The proposed process establishes a maintained authority register, directs exceptions to a named decision-maker, and makes unresolved items visible to a daily operating owner. The initial target is a median of eight business hours after an agreed stabilization period, with no deterioration in unauthorized-price exceptions. The commercial operations director owns the outcome; finance owns the definition of the control measure.
Before full approval, the team tests the routing rules on a sample of historical exceptions. It checks whether a qualified approver could have made each decision using the proposed information. Missing authority records become a dependency with a remediation owner. The test can challenge the thesis before configuration begins.
The financial case claims no payroll reduction. Instead, it proposes redeploying released capacity to clear an existing customer-query backlog. That secondary outcome receives its own baseline and owner. If the same staff are also assigned additional project duties, the redeployment claim must be revisited.
Disconfirming evidence is specified in advance: release time fails to improve despite correct use of the process; the longest delays come from information outside the planned boundary; or unauthorized exceptions rise. Any of these observations triggers investigation of the causal argument. None is an excuse to redefine the metric after the fact.
Make the benefit register usable during delivery
For each benefit, retain a compact record containing the metric definition, baseline window, target and review date, accountable owner, enabling process changes, dependencies, counter-metric, and evidence that would challenge the claim. Add the decision supported by the benefit and a link to the approved scope item or work package in the team's own repository.
A counter-metric protects against optimizing one result at another's expense. Faster purchasing approval might be paired with unauthorized-spend exceptions. Lower inventory might be paired with customer service performance. Choose the trade-off that is plausible in your operation; a generic list of measures creates reporting work without necessarily protecting the outcome.
When a design change is proposed, ask which benefit it strengthens, weakens, or leaves unchanged. Some changes are required for safe operations even when they add no incremental benefit. Others are attractive conveniences. The register helps leaders distinguish those cases without pretending that every decision can be reduced to a financial score.
Changes to targets should preserve the original commitment, the revised expectation, the reason, and the approver. Silent rebasing prevents learning. A transparent revision can be entirely appropriate when transaction mix, business strategy, or an external dependency changes.
Use approval to set the next evidence gate
The approval meeting should finish with a decision about both funding and uncertainty. Ask the sponsor and benefit owners to resolve five questions:
- Which outcomes justify the investment, and which are optional improvements?
- Which assumptions remain unproven, and what will it cost to test them?
- What business decisions and staff commitments are necessary to make the process change real?
- What evidence would cause leadership to reduce scope, change direction, or stop?
- Who will review benefits after the delivery team has moved on?
A staged commitment can be sensible when a small amount of investigation will resolve a large uncertainty. It also has costs: another approval cycle, possible loss of momentum, and additional planning work. Use it where the evidence can genuinely change the decision, rather than making every project pass through ceremonial gates.
Continue reviewing the thesis at design approval, before the operating transition, and after the agreed stabilization period. The exact timing should follow the business cycle needed to observe the outcome. A monthly process cannot be judged from a few days of activity.
For an immediate next step, select the largest claimed benefit in the current proposal and build one complete record. Ask its owner to defend the baseline, the process change, and the disconfirming evidence without referring to a feature list. Any gap becomes a specific task before the next commitment. CuriousRubik's suggested starting point is this shared examination of the operating logic: the investment becomes easier to govern when everyone can see what has to be true.