A board approving an ERP business case is deciding one thing: whether this is the best use of the next $20M to $80M and three years of management attention, against every other call on both. It is not voting on the software. Most cases fail for two reasons. The benefits are soft, a slide of percentages no named person will sign up to deliver, so finance discounts them to zero. And the cost is a single number, a point estimate that is wrong the day it is written because no program of this size lands on one figure. A case that survives does the opposite: an owner behind every benefit, a range behind every cost, and the assumptions on the page.
What the case must answer
A board case answers four questions, in order, and a case that skips one gets sent back. The first is the decision: what is being approved, by when, and what the money buys. State it as a number and a date, not a direction. The second is the cost: the five-year total, as a range, broken into software, implementation, run cost, and internal time.
The third is the benefit: what the company gets back, who owns each piece, and when it lands. The fourth is the risk of doing nothing. An ERP case is rarely a free choice between the new system and a stable present. The present is a system on a support deadline, a finance team closing the books in 12 days by hand, or a platform that blocks an acquisition. Name what the current state costs each year it continues, because that is the number the investment is measured against.
Benefits need named owners and a hard-versus-soft split
The fastest way to lose a board is to present benefits nobody owns. A benefit with an owner is a commitment: the owner's name is next to the number, and that number goes into next year's operating plan. A benefit with no owner is a hope, and a finance director reads it as zero. Before a benefit enters the case, a line manager who controls that budget line has to agree it is real and agree to be measured on it.
Split the benefits into hard and soft, and lead with hard. A hard benefit changes a number finance already tracks: headcount, working capital, maintenance spend, days to close. A soft benefit is real but not yet countable: better decisions, higher morale, fewer errors. Soft benefits belong in the case as context, never in the return calculation. If the investment only works once the soft benefits are counted, it does not work.
Hard benefits size with plain arithmetic the board can follow. A company carrying $300M in inventory that releases 2 to 3% through better planning frees $6M to $9M of cash, once. A finance function of 40 people that avoids 6 hires over three years at a loaded $90,000 each avoids about $540,000 a year by year three. A close cycle that drops from 12 days to 6 does not show up as cash directly, so tie it to the headcount or overtime it removes, not to the days themselves. The arithmetic matters less than the discipline: every number traces to an owner and an assumption.
| Benefit | Owner | Basis | How it is measured |
|---|---|---|---|
| Working-capital release | VP Supply Chain | 2 to 3% of $300M inventory, one-time | Inventory on balance sheet, quarterly |
| Finance headcount avoided | Controller | 6 hires avoided by year 3 at $90,000 loaded | Approved headcount plan vs. actual |
| Maintenance retired | CIO | Legacy support and hosting removed at go-live | Vendor invoices, year over year |
| Faster close | Controller | 12 days to 6, overtime and temp cost removed | Close calendar and overtime hours |
| Fewer manual adjustments | Controller | Soft, context only | Not in the return |
Costs are ranges, and the number that matters is five years
A single cost figure is the weakest line in most cases, because it is precise about something nobody can know yet. Present every cost as a range, and show the five-year total, not the go-live number. The go-live number understates the commitment by roughly half.
Three published ratios size the range. Implementation runs 1x to 3x first-year software cost, so $10M of software implies $10M to $30M to put it in. Run cost, the vendor support, cloud, and managed services after go-live, runs 15 to 25% of implementation a year, so a $20M implementation carries $3M to $5M a year to keep running. On top of both sits internal cost, the salaries of the business people pulled onto the program, which commonly runs 20 to 30% of external cost and almost never appears in the vendor's figure. A program with $20M of external cost is spending another $4M to $6M of its own people's time, and the board should see it, because that time comes out of the day job.
| Cost line | Range | Basis |
|---|---|---|
| Software (5-year) | $10M | Subscription or licence plus maintenance |
| Implementation | $10M to $30M | 1x to 3x first-year software |
| Run cost (per year) | $3M to $5M | 15 to 25% of implementation |
| Internal time | $4M to $6M | 20 to 30% of external cost |
| Five-year total | $45M to $75M | Sum across the term |
Build these numbers rather than quote them. The ERP implementation budget workbook holds the line items, and the cost estimator turns a software figure and a company size into a five-year range you can defend in the room.
The assumptions register keeps the case honest
Every number in the case rests on an assumption, and the assumptions are where cases quietly go wrong. The fix is a register: one page listing each material assumption, the number it drives, who owns it, and how confident you are. The 2 to 3% working-capital release assumes the planning module is configured and used, which assumes the demand data is clean, which assumes a data cleanup effort nobody has yet scoped. Write that chain down. A board that sees the assumptions trusts the case more, not less, because it can see what would have to be true.
The register does a second job after approval. In year three, when someone asks whether the investment paid off, the register is what the review reads against. Without it, a benefit that missed looks like a failure; with it, you can see whether the benefit missed because the assumption changed, the owner did not deliver, or the number was wrong to begin with. Each of those is a different lesson. Keep the register live through the program, and update the number whenever the assumption behind it moves.
The cost of waiting is part of the case
A business case that only shows the cost of acting, and treats staying put as free, is only half a case. The current state has a running cost, and naming it is what turns the decision from "spend $50M" into "spend $50M or keep paying $X a year and rising." Sometimes waiting is the right call, and a case strong enough to show its own do-nothing line is strong enough to say so.
The do-nothing cost takes a few shapes. A platform on a support deadline, such as SAP ECC before December 31, 2027, exposes the company to extended-maintenance premiums of around 2 percentage points on the maintenance base, and eventually to running unsupported. A finance team closing by hand carries overtime, temporary staff, and the risk of a restatement. A system that cannot support a new country or a planned acquisition caps growth the board has already approved. Put a number and a date on each, because a do-nothing cost that rises every year is often the strongest argument in the case.
Set a benefits baseline you can measure
A benefit you cannot measure after go-live is one you cannot claim. Before the program starts, record today's number for every hard benefit in the case: the current inventory level, the current finance headcount, the current close in days, the current maintenance spend. That is the baseline, and it has to be captured before anything changes, because after go-live the old number is gone and the argument becomes unwinnable.
Set the measurement date with the baseline. Benefits do not arrive at go-live; a working-capital release or a headcount reduction commonly takes 12 to 24 months after go-live to show up, once the system is stable and the process has changed. Say so in the case, so the board expects the year-three review rather than a year-one one, and so the owner is measured on the right date. A baseline plus a named measurement date is what lets the company tell, three years on, whether the $50M did what the case said it would.