Embarking on a software upgrade can be a daunting and uncertain task for many CFOs, often clouded in over technical terms and confusing jargon. Regardless of the reason for your upgrade there are basic common components which each CFO should be familiar with before embarking on any software upgrade project.
This Expert Insight is written by Anna Puzone, head of enterprise performance management at information management company Zetta Business Solutions.
You will upgrade your technologies for many reasons, these are just a few I feel are relevant to this post:
- You like to stay up to date with the latest technology
- Your software provider will stop supporting your current version
- You require new functionality that is available in the new version
The steps should entail the following basic steps regardless of the size of your implementation or organisation. You should try to follow all the steps, what should vary is the duration and effort needed in each and that depends largely on what it is you're doing and who in your 
organisation is affected by the change.
This is not an exhaustive list or detailed evaluation of those steps, merely an overview of the building blocks, there are additional optional steps that you may need, such as integration to third party tools or legacy systems you have in place, new functionality configuration etc.; but those are a discussion of another day.
1. Plan and research
Follow a plan, regardless of how large or small your implementation, whether it is a large ERP tool or a smaller packaged solution, you need to have a plan and know what steps to follow.
It is important to understand what it is that you are doing as part of this upgrade, who is going to be affected, are you going to do it internally or are you going to get an external consultant to assist/deliver.
When you plan your execution and assign people you will have a clear picture of any potential risks you may encounter and be able to prepare for them.
What are you hoping to get from the upgrade? - Are the changes in the release applicable to your implementation?
- Will it affect any of your business processes? How does it change?
- Do you need to train your staff on the new release?
- Is it a minor update or a major upgrade?
All of those questions will affect the way in which you handle this undertaking.
Be clear as to what you are hoping to get out of the upgrade, for example if you are simply doing this because the current version will be out of support and there are no changes in the new release that impact your current processes, you are likely to do less testing and go through the process quickly.
If you are upgrading because you want to make use of the multicurrency revaluation process, you will spend more time testing the impact of this new process on your current revaluations and you will spend more time configuring that module to get the most benefit from the improvement. You may even need to change your business process to get maximum benefit. It is important to understand the scale upfront.
2. Have a roll back strategy
Whether you have a project team that is planning all the steps or you are simply going to put the disk into the drive and click 'Next' several times, there are unforeseen circumstances outside of your control that you need to be prepared for.
Regardless of the size of your organisation, if you encounter a problem, how long can you go without this system being operational? Is it weeks, days, hours? What can you afford? In reality your answer is likely to be "I can't afford this to be out of use at all". You need to have a sound roll back strategy, a way out if you will in the event that something goes wrong.
Always have the latest tested back up of your environment that you can restore should there be any issues.
3. Clear areas of responsibility
Whether your upgrade is handled internally or you have external expertise involved, you need to be clear on areas of responsibility. I have seen many organisations entrust the whole upgrade to third parties, who despite their best efforts often have no way of knowing the business impact.
Especially in the world of finance systems, there are aspects of any upgrade that are often lost in translation between the CFO and technology expert. One of those, which I feel very strongly about is balancing your figures. That statement to any finance professional is bread and butter; an involuntary activity that is so basic it often goes implied. To the technology expert the same statement means count the records before and after. So when you get together and ask the pertinent question "Do we balance?" the answer will be "Yes", what is it missing however is context that only you as the CFO will understand. Are the decimal places in my amount field still correct, or have I just unknowingly restated my entire position? The record count may be the same but if you have just cut off 2 decimals from the entire database, the before and after balances across your lines items won't balance. Queue highly charged "he did, she did" CFO and service provider argument, rework and delays all of which both parties could do without.
Answer, you as the owner of the data must be prepared to take ownership of it. It is your information value not the service providers', make sure you have the control and own it.
4. Execute
Adhere to your plan and timelines. Have all the necessary people aware and available should you need them.
5. Test
How can you be certain when something does what it promises to do? You put it to the test.
There many levels of testing required in an upgrade, the duration, complexity and number of iterations depends on the size. There are many ways of performing the tests too, manual and automated testing solutions are available from many sources.
As a CFO you will put a lot of trust into the software developers to ensure that by upgrading it doesn't break the existing functionality, you will entrust your service provider or IT team to execute the process effectively and timely; but you will have to put in the effort to verify that trust by performing business level testing.
The vendors would have spent countless hours testing their software and it will work, the service provider/IT would perform testing to make sure the system is up, stress testing to make sure it will perform well, but the business process and balancing testing should rest with the business owners. Only you have the knowledge that yield correct conclusions.
6. Deploy
Once you have gone through the above steps, whether it took you weeks or hours you will be ready to let others know it's ready and they can start using it.
The formality of this step is again dependent on the size of your organisation and the people involved.
It could involve training on the new release, installation of new client software on everyone's machines, it could have a several step process just in itself or if you're small it could be an email to say "We've upgraded, enjoy"
What's important is communication, and that goes for every step in this process. You want all the people who will be impacted by the upgrade to be aware and be able to ask questions of the experts at any point.
Change is often unsettling to most people, it is important to make it as seamless and simple as possible whilst considering all the risks and its mitigating factors. When you do that, it needn't be a dreaded exercise that it often becomes.
Happy upgrades.
- Stay connected, up to date and in the loop on what is happening in the world of finance and keep track of newly published expert insights and interviews with CFOs and CEOs. Become an online member and receive our newsletter, follow us on Twitter and join us on LinkedIn.
- Share your ideas with the CFO Community as well with an interview or during one of our CFO events. Please contact Jurriën Morsch at [email protected]
