1. Analyse and identify – understand and map out your AS-IS business processes and your TO-BE target operating model. This should include any existing technology roadmap and initiatives, your overall business strategy and timelines. It is HIGHLY RECOMMENDED that organisations challenge themselves in understanding their readiness for change. The cultural element of whether your team is onboard and engaged needs drawing out here.  If you can identify potential pain points now, you can save yourself a lot of internal heartache once you get to implementation.  
2. Document the requirements – it’s also very important to get your teams thinking in the right way and not simply state what they do today to create your “future state”.  This is where the external help comes in, as User Stories and process swim-lanes (that concentrate on “outputs/outcomes”) will help you focus on efficiencies in your processes. Experienced Business Analysts (BAs) are worth their weight in gold here in guiding your team through this and this will help you massively when it comes to vendor selection. 
3. Separate what your organisation WANTS from what it NEEDS – you should challenge yourself and your teams in really separating the two as they are very different in almost every aspect. If your future state is based on Wants….you’ll likely be implementing for years with little benefit realised (and spiralling costs…). 

If this is your first change project, you really will need to get some support and work with people who have done this and seen the good, the bad and the ugly when it comes to programmes of change like this. Importantly, whilst you may have an idea regarding systems you’ve used before or are market-leading, this is the time to be solution agnostic. What you really don’t want is to start defining your “TO-BE” state with a system in mind as you may end up building inefficiencies into your operating model (the classic “leading the witness”).  

To reiterate again, once you start on this journey of discovery, your people will either be super happy to be involved (yay, no more spreadsheets!!) or they will start to worry.  We will discuss in a later piece the importance of outlining the benefits to “the individual” and not just to the company.  By bringing them along on the journey you’ll have a happier and more engaged team – but more on that later.  

Building the Business Case  

There are differing thoughts with regards to building a business case depending on the size of your organisation and what you are looking to achieve.  

Large organisations undergoing multiple in-parallel business and technology initiatives will need a strong and detailed business case. The “fight” for budget will require the business case to be far more forensic with extremely detailed benefits outlined. 

 For smaller organisations, it’s often that senior management or the investor will already know that an ERP is likely required (e.g. companies on a Buy and Build Strategy and the need for one source of the truth) so functionality and reducing barriers to growth and good data is often as important a factor as the basic “cost-benefit”. 

The reasons for and benefits of a project may seem perfectly obvious to the C-Suite and others who are intimately involved with it, but to stakeholders and other decision-makers, it may not be so obvious. Often, they are dealing with a myriad of different business units, business objectives and tasks which need to be done. A well-prepared business case can help your project stand out amongst the competing priorities within your organisation and may be the key to getting approval and finances for the project. Still, no matter what size the company, the business case should explain the following: 

• Key objectives 
• Outline the business need 
• Provide important background and supporting information to put the investment into context 
• Describe how the investment aligns with the organisation strategic business plan 

• Provide a robust estimate of the whole-of-life costs of the investment, and its financial benefits 
• Estimate the non-financial benefits of the investment 
• Describe the approach to be used, including timelines, resources, the procurement strategy and governance 
• Rigorously assess the inherent risks, including how they are likely to affect the investment and outline strategies for mitigating them 
• Convey the level of uncertainty surrounding the proposal 

• Provide options for the Senior Management Team (SMT) to consider in reaching a decision 

A robust business case is really helpful during the project as well, as it can be used to ensure you’ve not gone off track and the benefits you expected are being realised. 

Now, and this is controversial….the business case should always come before the Discovery piece…but could it be done in parallel or is it needed as per the above? For many organisations, once the NEED for an ERP has been clearly identified, they know they are going ahead with the Discovery. If you’re in this space, we recommend the business case is still created, yet at a higher level.  

Granted, we’ve already stated in the first paragraph that (post the stepping-stones exercise) you’ve identified the need for an ERP (we’ve not gone daft!). Still, many organisations will have competing priorities for budget, so a robust business case will help you to climb up that priority list.  

The dreaded presentation….. 

 When it comes to presenting your case, you may or may not know your audience well. If you‘re at a privately owned Mid-Corp, it’s likely you do so you can temper the presentation knowing how they like to receive information (many have an utter dislike of lengthy PowerPoints!). If you have PE investors then it’s likely you may not be so close. If this is the case, ask your SMT – who will know the Investment Directors – about how they have presented such data in the past. In this case, you will have to ensure that you take them on a Value Creation journey that is linked not only to the company but to the overall investment itself. There are always some “soft” benefits that can’t easily be backed up with data. Don’t over-egg these and make it clear they are just that – it will save you being hauled over the coals in future for not realising any financial benefit you have allocated to them. 

 What’s next? 

 Now that you’ve undergone your Discovery, you’re ready to start thinking about how to pick the right solution, what you need from an implementation partner and how should the programme team look. 
 
In the next episode, we will walk you through vendor selection (“to RFP or NOT to RFP” – that is the question) and how to set your programme up for success.