Introduction
Upgrading or changing your business systems can be daunting. If anything extremely costly if not planned out with an eye to future proofing.
One of the biggest mistakes is to take what you current do and simple automate or copy the old system. Without taking the opportunities to remove wasteful and costly processes. If you are going to spend thousands and in some cases, millions on a new system, make sure you don't simply lift and shift.
Lift and Shift
We use the term 'lift and shift' when referring to copying the same ways of doing things. Without taking a step to improve what is not working or capitalising on some great functionality the new solutions offer.
What is often hushed up is that when you approach any tech provider, you will be dealing with a sales rep. They won't know how your organisation works nor will they understand how their product could actually improve your processes.
I have seen it plenty of times that the sales agent has flogged the solution and promised 'oh don't worry we can adapt the code, and programme that unique process for you'.
The vendor often can't. Therefore post contract, you end up having to create further manual workarounds and get a shocking invoice to boot, for all the add-on's. Even when they had better functionality but you wanted to keep the old inefficient process.
So what can you do to prevent ending up in such a predicament?
Have a checklist for your organisation
This is not in a chronological order as such, as some step might have already been done, e.g. a Target Operating Model (TOM). But a list of common areas that have set-back projects.
Note - I'm not mentioning budgeting as it is assume this will be done as part of the business case to open up the tendering process. However, be aware your budget can change depending on some of the below factors.
1. Why change? There will be a few reasons why you have come to this cross roads:
- It could be that your current system is becoming obsolete or no longer supported by the software company. Therefore, you have no choice but to move. In this case, start the replacement journey at least 3 years before the current system is due to expire. You will be surprise how long it takes to procure and implement. Do not rush.
- You have scaled quickly and your current system cannot handle the volumes you are processes. You have probably bought add on's and using multiple manual workarounds and spreadsheets.
- You have merged with another company and there needs to be a standardised system implemented.
It is important to appreciate, that if you find the IT alternatives don't work at this point of time for your organisation and budget. You might want to delay changing. Better to wait a few month to see what better alternatives come onto the market, or see if you can afford to build bespoke in-house.
2. Understand the time scales. Timescales can start at 1.5 years minimum to move a major system. I have seen some take up to 5/6+ years (though this is usually down to poor planning and committing to the wrong system). But on average 2-3 years for large companies.
Setting out timescales will help to manage expectations and lead to better project management overall. For example, will you want to have key staff members involved? If so, will they need back-fills to cover them while on the project? Without a firm timescale you can't estimate the cost of this. Also you might get some strong people refusing to join the project as they fear losing their job (their role becomes obsolete after the project) or missing out on other internal promotions.
3. What do you want to improve on? Before drawing up the ITT (invitation to tender) be clear what you can improve on. This will involve reviewing processes and setting out your ideal future state. You might find your current system could last a further year, through some minor process improvements, before you have to commit to a large project.
Therefore, it is well worth investing time to review processes. As it makes the tendering process less stressful, as you won't have vague requests that can be misinterpreted by the vendor, through no fault of their own.
4. Priorities your core needs, something like a MoSCoW exercise is vital to know your - Must haves, Should haves, Could haves and Won't haves. That way when looking at vendors, you can more rationally evaluate their pro's and cons. Plus, by being clear on what is important, it will be easier to push back to get the best fit for your organisation.
5. What is your Target Operating Model (TOM). This is not as necessary for an up-grade, but if changing systems is due to a merger or major organisational re-structure, be clear as to roles and responsibilities. Any vendor will have a catalogue of user functionality. However, not being clear on how these will map to end users and approval hierarchies can be a nightmare to fix.
6. For any EPM system the Chart of Accounts needs to be reviewed. This goes also for product catalogues, customer data bases, HR personal files, basically any repository of data needs to be tidied up for any new type of system. This helps the vendor guarantee they can manage your data in a way that works for your organisation. Mapping data to a new system is problematic if not managed early on in the process.
7. Reporting - be clear on the reporting needs for the organisation. This includes frequency and audiences. Do you want individuals to be able to create their own reports? Do you want key sales staff to be able to access real time data while out with clients on tablets etc?
8. Will the vendor provide UAT (User Acceptance Testing) documentation. Many claim to have these, however, they often are very low level tests and are not robust enough to do full end to end scenario testing. Testing one part of the process is never advisable.
You need to make sure when you turn on the new system, any data going in, flow through the entire system. This includes security protocols being adhered to as well as user interfaces work-flowing between departments e.g. payroll to HR and Finance. Poor testing leads to critical failures for a new system.
Therefore, if your preferred vendor can't provide, negotiation support to create tests as early as possible.
Planning
There will be nuances depending on the type of system you are taking on, size of your organisation, the maturity level of your organisation to adopt change etc.
However, the above are points that are important to be aware of. Even if you intend to hire an outside implementation firm, some of the lingo, won't seam so odd to you now. Plus helps you to frame interviewing questions for those tendering for the gig:).
Conclusion
By addressing current issues and designing how you want your IT system to work in the future, it will make the procurement process more navigable. And in turn improve the project outcomes.
It is hard for vendors to sell to you correctly, if they don't have a clear picture of your organisational needs. Some vendors can be very upfront about their limitations. Especially as some systems work better for the service sector versus manufacturing, for example.
It is not always fair to blame the vendor, when the ask is unclear.
