Managing M&A Operational IT Complexities
Merger and acquisition (M&A) activity within the financial services sector is back at the top of the agenda again. The ongoing economic turmoil has led to the likes of Santander acquiring Bradford & Bingley, and Lloyds TSB bailing out HBOS. The desired outcome of M&A activity is to create a more stable environment but, no matter what happens on the economic side, the operational side of a M&A is fraught with complexities and if unsuccessful can cause irreparable damage to a brand and poor customer service.
What is certain, however, is that we are looking at a period of high risk and uncertainty. Furthermore, as one of the most highly regulated industries, the result is a moving pavement for many banks as far as IT rationalisation is concerned.
Indeed, the financial services sector has never faced such a complex scenario for M&A activity as it does now. There are numerous strategic issues to be taken into account during the planning, due diligence and post-acquisition phases. IT considerations alone that need to be addressed are:
The answers are all lying somewhere between ‘no’ and ‘probably not’. And with all that data to migrate and integrate, you could argue it is like conducting open-heart surgery on the move.
Traditional approaches, such as ‘extract, transform, load’ (ETL) and scripting, involve a quarantine period that can stop businesses dead. If a bank did this it would create unacceptably high levels of risk that can have a negative impact on company and customer operations. That’s why, according to Bloor research, 72% of financial institutions believe that data migration is too risky and, as a consequence, migrations are delayed or not timed to maximise the business benefit.
With budgets coming under increasing pressure, successful and on-time application data migrations have never been more vital. Just how can companies successfully conduct business-centric application data migration within a financial services M&A minefield?
The process needs to avoid downtime and reduce risk and cost, while ensuring a full business level audit trail for compliance purposes. And at the same time it must abstract the business from the technology.
The concept of ‘progressive’ data migration enables business operations to continue trading with zero downtime and also to choose between several migration approaches to suit the situation – banks will only succeed if they combine this with a focus on putting the customers, and the people and processes that support them, at the core of their transformation, consolidation or optimisation programme.
This new progressive approach creates business agility, provides short time to value and delivers the confidence to base migrations on the requirements of the business, therefore de-risking the process. The major benefit of zero downtime means that business disruption is minimised through concurrent synchronisation of data and business process migration between legacy and new systems. Progressive migration also supports and enables agility in local, regional and global business transformation – ideal for multinational financial services institutions.
The current economic market issues will naturally affect the lives of vast numbers of people across all geographies and markets. Whether the UK and US rescue plans work or not, there is no doubt we are looking at a period of high risk and uncertainty. However, a downturn is often an ideal time for businesses generally to focus on their priorities and optimise their business and IT applications to drive efficiency, customer focus and help them reach their goals.
Scarcity of capital will generate increased competition for the cash that is available. Consequently, it will be even more important that businesses (in particular banks who have received a high level of negative press in recent months) do everything they can to make sure their existing customers stay with them and keep spending, that they are extraordinarily tough on driving out unnecessary internal costs, and that they spend to innovate and win new market share from less agile competitors.
These three requirements force enterprises to rethink and refine the way they operate – to transform or optimise in other words – and quickly. Rapid change is always hard to achieve in any global organisation and while global banks can adapt locally, fundamental change across the whole corporation incorporating the processes they use to market and sell, fulfil and service customers is much harder, but absolutely must be done to ensure survival and growth. Flexible IT infrastructure is key to enabling a business to adapt in order to survive and then grow.
Having said all this, let’s go back to the earlier question: “Just how can companies successfully conduct business-centric application data migration within a financial services M&A minefield?” No one company is the same, of course, so below is a guideline for how best to approach this crucial operation.
Scope-creep kills many projects – and migration is no exception. Clearly identifying the existing data that will really be needed in the ‘to-be’ world helps to contain the project to an achievable timescale and cost. But as I describe later – don’t expect this to remain static. If things cannot be scoped, they should almost certainly be outside the project remit; else you will not be able to demonstrate success. Governance and compliance are factors in the foreground of executives’ minds and are ignored at major peril.
New application implementation projects invariably take significant time to deliver, and business rarely remains static throughout their duration. Anticipating change, but having an open and rigorous approach to managing it, is essential.
Being explicit about realistic data quality driven by what the business will need saves effort over-working bad data that will never be either fixable or even useful in the future. Perfect data quality is probably unattainable and usually unnecessary – but the business must make the choices about what to discard, what to keep and what effort to put into fixing data that won’t meet the demands of the new systems.
Migration should not be forced into the transformation or optimisation project as a tactical afterthought, rather it should be built into the project from the outset to start delivering results and generating ROI for the business as soon as possible from the new application or IT environment.
Application testing with carefully constructed data is an essential step in the software development process. Just as important is to test the migration processes with as much real-world data as possible. This gives two vital benefits. First, historic data has a nasty habit of containing undocumented surprises introduced over many years that the existing systems and processes work around, but these could certainly trip up the new ones. Second, it is often only when end-users see their real data populating the new application that they really understand how it will behave – the earlier this happens, the earlier results will be realised.
Data drawn from multiple sources, created by different people using their own unique naming conventions, creates issues when developing the appropriate datasets. There will sometimes be no automated way of connecting the widget named ‘XYZ-789’ in one system with the same widget named ‘ABC123’ in a different one. Flexibility in developing interim solutions, providing an effective and methodical approach for subject matter experts is required. In the same way, data about customers, products and inventory will often be duplicated many times with slightly differing attributes in different systems – this in turn needs to be rationalised before loading into the new world applications.
The team needs people who really understand application data migration to lead it, with ready access to business and technical subject matter experts. The existing IT applications support team will generally not suffice. People need to understand the process, complexities and methodology of migration.
Great communication underpins all good projects and regular, effective updates from all team members maintain and manage project progress. Collaboration between the technical and business-focused people and engagement with internal and external stakeholders will only work based on common, timely accurate data expressed in terms all can understand and relate to.
Supporting business-centric data migration in complex, mission-critical environments requires sophisticated built-for-purpose software that will not let you down. Use a tried and tested application data migration method and platform to greatly reduce the risk of late delivery or failure. Traditional ETL will not and cannot solve this for business software applications.