Guide
An ERP business case is approved once and then quietly forgotten, which is why so many programmes deliver a system and no value. Here is how to write one that is honest about cost, specific about benefits and still useful two years later.
By Christopher Fagan, Managing Partner, PEF Consulting Partners
The weakest business cases start with the system the IT team has already chosen and work backwards to justify it. The strongest start with the cost of the current state: the month end that takes fifteen days, the three spreadsheets that reconcile stock, the customer orders keyed twice, the audit findings, the support contract on a system the vendor has stopped developing. Put a number on each, with a source and an owner. That number is the ceiling of what the programme can be worth, and it tells you quickly whether an ERP replacement is the answer or whether a cheaper fix would do.
The cost side of an ERP business case has seven lines, and most cases include three. Software licences or subscriptions over at least five years. The implementation partner. Internal time, which is routinely the largest line and routinely left out because it is not a cheque. Data cleansing and migration. Integration with the systems that stay. Change, training and the dip in productivity around go live. And contingency, which should be fifteen to twenty five per cent of the total, not a token five. Our guide to ERP implementation cost in the UK gives ranges by company size; the point here is that a business case which omits internal time and contingency is wrong by half before it starts.
A benefit is only real when it has a baseline, a target, a date and a person who will be asked about it. Headcount savings need to name the roles and the date they are not replaced. Working capital benefits need the stock or debtor days today and the target. Revenue benefits need the mechanism, not the hope. Avoided cost, such as a legacy support contract, is legitimate; soft benefits such as better decision making are fine to describe and should carry no value in the numbers. A business case with five owned benefits beats one with thirty unowned ones every time it is reviewed.
A credible case compares at least three options: do nothing and keep paying the cost of the current state, fix the current system, and replace it. For replacement it compares the shortlisted platforms on total cost over five years rather than year one price, and it says what the organisation gives up with each. Boards approve business cases they trust, and nothing builds trust faster than an author who has set out the case against their own recommendation.
The business case should be re approved at the end of design, when the scope and cost are known properly, and reviewed at every stage gate after that. Benefits should move from the business case into a tracker before go live, and the tracker should be reported to the board until the last benefit has landed or been written off. In our experience the programmes that deliver value are not the ones with the best original case. They are the ones where somebody kept checking it.
Related reading: ERP implementation cost UK, the ERP implementation plan, benefits realisation consultancy, ERP selection consultants, the free business case template.
The cost of the current state, the options considered, the full cost of the recommended option over at least five years including internal time and contingency, the benefits with baselines, targets, dates and owners, the risks and the governance for keeping the case under review.
Total the owned benefits over five years, subtract the total cost over the same period including the second year onwards, and look at the payback year as well as the overall return. Most honest ERP cases pay back in year three or four; a case that pays back in year one is usually missing cost.
The business, with finance and the process owners, supported by someone independent of the vendors. A case written by the implementation partner or the software vendor will be accurate about their costs and optimistic about everything else.
At the end of design, at every stage gate and then quarterly after go live until the benefits are realised. A business case that is never revisited after approval is the most common reason an ERP programme ends up as a system without a return.
If you need an ERP business case that will survive a sceptical board and still be useful after go live, a short confidential conversation is where we start.