Insurance Solutions | Georgina | 10 May 2018
The TSB’s computer crisis has been one of the worst in recent memory. As a major customer service disaster, it is likely to cost the bank millions and stain its reputation for years to come.
While still fresh and still causing major issues, it’s wise to take heed and understand if there are any lessons to be learned. This is especially important for other industries with similar legacy environments to contend with. Namely, the insurance industry.
So how did the TSB’s crisis occur? Simply put, it was a combination of factors…. none of which are particularly unique or rare to think this couldn’t happen again.
Timeline of major events
- The TSB split from Lloyds Banking Group in 2013
- The banking system the TSB would adopt was a clone of the original group’s system
- The TSB rented this system from Lloyds Banking Group for £100million per year
- In March 2015, Spain’s Banco Sabadell bought the TSB (for £1.7billion)
- Banco Sabadell put plans in place to merge the TSB’s system with its own Proteo banking software (renamed ‘Proteo4UK’ for this programme)
- Originally scheduled to be delivered in just 18 months, the programme had a number of delays, but finally went live 23rd April 2018
- Hours later systems began to fall over and major issues started to spring up
- More than two weeks later and the problems are still being dealt with
The main points to address here are:
- The cloned system and the state of the legacy systems
- Understanding what was ‘fit for purpose’
- The short timeframe given for migration to the ‘new’ system
The legacy systems may well have been fit for an organisation as large as Lloyds Banking Group, but once the TSB separated and was much, much smaller its needs and scale became different. The TSB may have had its hand forced to adopt the existing systems, and at a cost of £100million per year – it’s easy to understand the decision to migrate to a new system. However, the short timeframe and apparent lack of system knowledge turned this into a ‘big bang’ migration approach, rather than the ‘evolution’ approach that it should have been.
Read our whitepaper on Enabling Digital in a Legacy Environment here
What should have happened instead?
Antiquated systems creaking under the weight of an ever-churning, ever-growing customer base, are more and more commonplace; especially in the insurance industry. Green screens, mainframes, core systems too ‘core’ to remove/replace are prevalent. Add into the mix that mergers and acquisitions add more and more systems to the architecture.
Moving to a new, fit for purpose system is the right strategy. But how should that be accomplished without encountering the major problems such as those seen in the TSB’s situation?
- Better IT Governance and controls
- A fully understood and agreed upon scope for migration
- A staged and measured approach to legacy migration
- Adequate system training
- Thorough testing
In short, the TSB’s situation demonstrates why a more measured approach to legacy migration is often a better approach.
