Process – the key to developing your ERP system’s business case

Businesses are driven by processes. In Banking, for example, there’s a defined process for opening savings accounts for new clients. If that process isn’t followed, then inefficiency and errors will result.

Processes make complex tasks simpler, resulting in predictable and higher quality outcomes. Similarly, well-formed processes contribute to better business cases and more favourable funding reviews.

The development process uses established standards and methods for building the business case.

The selection process decides what projects get funded by using fair and transparent decision-making methods.

The benefits realisation process tracks ongoing value realisation against the original forecast (in the business case).

In this series we’ll focus on the 7-step business case development process. We’ll cover the first 4 steps in this article, and we’ll wrap up the development process in Part 3.

Step 1. Identify the scope of the business case

Your ERP system supports the needs of individual business units, as well as the business as a whole. For financial and political reasons, the ERP business case is too important to make avoidable mistakes.

Your first step is to identify the scope of the business case so that it satisfies the needs of executive decision makers, without becoming excessively broad and cumbersome.

You will identify the ERP solution(s) being investigated, the investment options, the business units that will be affected, and the people and resources that will be consulted.

Step 2. Establish the important decision criteria

Gather all the relevant decision criteria from decision-makers and influencers. Be careful of irrelevant or missing criteria.

Find out, through interviews and questionnaires, who cares about what (the decision criteria), and how much it matters (the weighting factors).

Consult as widely as practically possible. ERP systems reach into all corners of the enterprise, and the credibility of the business case may be called into question if there’s a suspicion that some business units (or someone’s concerns or needs) were overlooked.

Step 3. Align the anticipated functionality with the business’s goals

Aligning functionality is the process of linking the ERP technology features to improved business capabilities, using the following form:

Feature that enables Capability to support business Goal that delivers Value

For example:

The ability to link the customer order status (feature) to a proposed Customer Web Portal enables Customer Self Service (capability), which in turn improves Customer Satisfaction (goal) which results in higher customer retention, and more revenue over time while reducing customer service costs (value).

Avoid the mistake of connecting a technology feature to a capability and not carrying that through to value.

For example:
Wrong way – The system is built on the SQL database (feature) for data integrity (capability)
Right way – The widely supported SQL database platform (feature) is proven to reduce system TCO (capability), contributing to our aim of lowering IT costs (goal and value).

Step 4. Calculate the business benefits in terms of payoff

In this step you calculate the tangible business value using the aligned business benefits that you identified in step 3.

The most common reasons that business cases get rejected are due to bad assumptions in formulas, baseline numbers that are not credible, and obscure or missing calculations.

What’s wrong with this benefit calculation?

Cost savings will be R 9 500 000.00, based on retaining 1000 customers with acquisition costs of R 9500.00 per customer.

  • The calculation and its logic haven’t been presented, so that raises doubts
  • There’s no time period given
  • The magnitude of change is unclear. Are those 1000 customers 100% of your customer base? If so then that’s a very “high sensitivity” payoff.
  • What’s driving this churn rate, and what’s its connection with the proposed solution?
  • What are the constituent parts of the “replace a customer” cost, and do they vary?

There are three “best practices” in presenting your payoff information.

  1. It must be relevant. The formula selected must be acceptable to the decision-making team and the business unit that it affects. If the data and conclusions offend key individuals, then you may have to accede to their wishes (and maybe add that information elsewhere in “Notes”).
  2. The input data must be readily available and current. For example, it may harm your cause to use payroll information that is years out of date when calculating input costs.
  3. Simplicity and clarity are essential. Your decision-makers will (for the most part) be non-financial people from Operations, Sales, Manufacturing etc. They will have to “get it” the first time when they look at your calculations and explanations.

How to structure each business payoff line

Within the constraints of clarity and brevity you can structure your business plan in the way that best suits your requirements, but here are some tips for ensuring that you get the essentials right.

Identify the right key metrics. The key metric is the performance variable that management will focus on to maximise the benefit from this new or enhanced capability.

In the customer retention example above, the key metric would be “Reduce customer churn rate”.

List and explain the variables separately from the formulas to reduce complexity. For example:

  • Revenue (average) per lost customer
  • Cost of customer acquisition – marketing costs
  • Cost of customer acquisition – selling costs
  • Total number of customers

Make your formulas easily understandable. Sub formulas may be required to calculate interim figures that are included in the final calculation. Explain the algebra where it looks complicated (and even if it doesn’t!).

Coming up next: We continue the 7-step business case development process and finalise the business case.