More enterprises are embracing software as a service (SaaS), including banks. Financial institutions have become more amenable to cloud computing as it has been extensively used and validated as a safe and cost-efficient solution.
One of the differences between having a piece of software installed within your bank’s network and using the SaaS model is that in most cases with the SaaS model you won’t get previews of changes.
Your vendors are going through change control processes and a substantial amount of validation and testing to ensure that you get the best experience possible after each update. But you can still be part of quality control by setting up an internal process to review the new solution being delivered to you.
These 5 steps should be part of your update validation process:
- Be aware when new releases do come out
Choose one or a few individuals to receive communications from vendors. With SaaS, the updates are usually more frequent than updates from your core systems. Some vendors have fixed release cycles, others update as changes are ready. Either way they will send communications, including pre-views, when applicable, so you want your team to be in the know.
- Based on the release notes, assess areas of potential impact
Once the key users are identified and registered with the vendor, have them assess the release notes for potential impacts to your operations. Do the changes touch an area on which you heavily rely, or do they cover a functionality that your bank does not use? If webinars, tutorials, or demos are available, have the key users attend and get familiarized with the changes. Changes may include bug fixes, something that will change how your team operates, or new useful functionality that you would benefit from.
- Define a testing plan and team to test the changes if needed
Going through testing will not only confirm the solution continues to work as expected but can also be a wonderful opportunity to get your bank familiarized with the changes. A testing plan depends on the scope of the change and should be based on the review done when assessing areas of potential impact. The areas of greater impact should receive more attention and detailed test cases. If you have a test instance or a sandbox, use it to play out different scenarios and data entries without compromising your production environment.
Test cases should also be as realistic as possible and mimic real business cases and situations you encounter during normal operations as well as corner cases. If possible, update your sandbox with the latest data to be as close as possible to production.
- Contact the vendor if there are any issues
Establish a relationship with your vendor where you and your team know how to contact them in case there are any issues that cannot be resolved internally. Don’t hesitate to ask for help, as your vendors want you to have a great, stress-free experience with their solution.
- Define work around steps to mitigate any issues caused by the changes until a fix can be delivered by the vendor
If an issue is found, how does it impact your operation? Do you need a workaround, or can you live with it? If you can’t come up with a workaround, your vendor may have one or two things to suggest, but it is important that the workaround is documented and shared with the team so that operations can continue until the vendor can address the issue.
Recurring vendor updates to your SaaS software are a necessary part of the software lifecycle process. But by following a few simple steps outlined above you can mitigate risk and ensure a smoother upgrade process for all involved.
