'Why are we doing this?'
Do we only need to replace an end-of-life platform? That could be a reason, but it cannot be the only reason. Replacing or introducing a new ERP solution should result in more than that. More recent ERP solutions will definitely have more and deeper functionality than the one that will be replaced or upgraded and should at least be able to apply new technological possibilities (e.g. mobility, AI, analytics, …) which are currently not within reach.
Therefore it is worthwhile to spent top management time in investigating where and how those new possibilities will support your organization to better realize your company's strategic objectives. Where can a new ERP platform make business processes more efficient? Where can it help you to use new marketing and sales channels? How can it help you to increase your customer intimacy ? Dreaming is allowed, but make sure to clearly define those objectives. A good old school management consulting advice is to use the acronym SMART. Describe the objectives in a Specific, Measurable, Achievable, Realistic and Timely way.
Those objectives should be used along the implementation project as your reference framework. If decisions need to be made to solve issues, to agree on budget or scope modifications or to decide what requirements are “must haves”, “nice to haves” or “should haves”, always go back to the project goals and objectives. They should be your guidelines.
"How about costs & benefits?"
Off course, since an ERP implementation is a major investment, some investment analysis must be made. What are the expected costs and benefits ?
What I always propose is to describe the costs and benefits in a quantitative way and in a qualitative way. Expected benefits can not always be translated into euros (e.g. “management will have a dashboard with personalized real time KPI’s”), therefore a qualitative description can be useful.
The easiest part to quantify is the cost. There is the project cost which is a one-time cost and the cost of operating the platform which is a periodic cost (CAPEX vs OPEX). Important is to consider the Total Cost of Ownership (TCO) of the new platform. Make sure to identify all possible and relevant costs. And have also a look at costs that will disappear, specially when you are moving to a cloud architecture. In that case infrastructure costs, labor costs and software license costs and maintenance costs will go down.
Be realistic and honest. Make sure to take into account sufficient contingencies. A good practice is to consider a number of scenario’s and each time have “worst case” and “best case” variant :
- Scenario 1 : “what if we do nothing"
- Scenario 2 : “what if we update our existing solution”
- Scenario 3 : “what if we install a new platform”
Quantifying the benefits is a more tricky business. The easiest way is to start with the IT side. The introduction of a new platform can lead to less software and hardware costs, less maintenance costs, less external support, …. . In some cases, this can already be sufficient to motivate the investment. Quantifying the business benefits is usually more difficult. Hoping for headcount reduction is not always a good way of quantifying benefits. First of all this is quite a negative way for looking at the project and secondly this can not be used to convince and motivate your employees. Making processes more efficient, reducing errors, creating additional sales channels, improved customer satisfaction, …. are better candidates to identify benefits.
Last but not least, a good risk analysis is an essential part of the business case. It is not a problem to have a number of risks. Not knowing the risks is much more dangerous.
When you know and identify the risks, you can manage and mitigate them. A good way of analyzing identified risks is to get an insight in the probability the risk might occur and in the business impact it can have. An easy way of visualizing is to map the risks on a probability/impact matrix. Each quadrant has it’s own strategy. High impact and high probability risks need to be avoided at all times, low impact and low probability must be accepted and no effort should be spent on them. The other two categories are the risks that can be managed. This is done by drawing up a risk management action plan that must be closely followed up during the project.
I hope it is now clear that a business case is not only about numbers and euros but it is also about knowing why we are doing this, knowing the risks and knowing how to manage them.
Our next blog will discuss the project management of an ERP implementation more in detail.
Interested to know more about ERP? We wrote an Ebook that provides even more information. You can download it here.