Written by Bradley Jarrett, Director, Financial Services Transformation
Overview
With the advancements in technology and increasing number of digital disruptors entering the banking sector, consumer expectation is rapidly evolving and forcing the industry to enter a consistent state of investment into their service and product offering. Whilst it is now common for banks to have a digital first strategy, they are often held back by the limitations of their core legacy systems. Systems, that are so old and dated, it is almost impossible to find knowledgeable resource who understand its capabilities. If you are lucky enough to find some, they would unlikely recognize it thanks to a lifetime of undocumented enhancements that were added to sweat its tenure.
With mounting pressure to offer unique, value add products and services it is easy to understand why the banking industry has been turning to new and established technology partners to enable them through innovative and scalable, ‘plug and play’ platforms to create new revenue opportunities, while protecting the existing client base. Unlike projects of the past, they need not be exhausting or expensive, thanks to the industry’s investment in enhancing its own internal capabilities through rigorous training and strategic talent acquisition.
Then comes the challenge…the migration
As official SAP partners who specialize in its core banking solutions, and as someone who has personally always operated within the financial services sector, it is exciting to see that in the last few years banks have really started to reap the rewards from their investment of building up their own internal capability, and in most circumstances have done so to a high degree of success. However, one area where we are witnessing less success is when it comes to the process of migrating the data from the legacy platform to the newly implemented solution. Whilst reasons for this vary, many of the examples derive from the fact that migration exercises can vary widely based on numerous reasons including data quality, tools being used and the technology of both the target and source, which is not properly appreciated by the project team that is undertaking the exercise.
I spoke with Jörg Mauelshagen, our Group Director and Co-founder, who shared his view,
“With the increasing appetite from banks to drive down the cost of innovation and IT transformation by owning and executing migration projects, we are seeing an increase in the number of projects which are delayed as a consequence. In most cases, this is caused by a lack of understanding of the technology into which it is being migrated and this throws up different challenges of perhaps another technology in which the team has more experience.
“Whilst I firmly support the decision taken by the banking industry to utilize and build internal IT capability, which for me is a key to their future success and in some cases survival, the approach I would suggest is a half-way house. One that does not require an infinite budget or external resource pool if organized and executed correctly. By working with an enablement partner who has detailed knowledge of the technology at play and an understanding the problems clients are likely to face, will directly reduce delays, effort and in most cases guide you away from any dead-ends. Better still, these experienced resources should be flexible enough to operate under the bank’s management structure, complementing the internal skill-set and as a direct result, will drive success whilst also minimising costs as a large portion of the resourcing is kept in-house.”
Jörg goes on to explain, “As SAP Partners who have led and executed the majority of SAP’s worldwide core banking migrations, we have experienced our fair share of challenges. This allows us to lead and work under the existing project management structure and guide clients away from the problems they are likely to face and prepare effectively for the upcoming exercise. ”
The challenges faced when undertaking a migration exercise.
With the increasing number of banking clients set out to execute and manage SAP migration exercises in-house, we are often asked to advise on what problems the project teams are likely to face.
Understanding the importance of a migration
The general perception of a migration exercise is one of relative simplicity and an exercise executed towards the end of a project by the IT team. However, this is far from the truth and includes correlating legacy data with either newly established, or existing business processes. Therefore, migration should be seen as a core part of the project, an enabler of true business transformation. Experience has shown us that project managers who understand this and put focus on the migration exercise, are far more likely to succeed and achieve their timelines within budget. Creating a migration domain as part of the project management board upfront, or part way through the project, is advised and will help to eliminate future risks, deepen understanding of the migration process and help the business achieve value sooner.
Building a coherent migration team
As explained by Jörg Mauelshagen, it is imperative that you have a team with the right experience and skill-set to ensure the migration’s success. Blending a team of internal resources who understand the wider transformation goals and legacy - platform, with external resources who understand the target system technology and tasks that need to be executed is key. As also stated, this should not lead to excess costs if the correct enablement partner is selected.
Understanding the art of the possible
Understanding what is and is not feasible when undertaking a migration is essential and will enable you to further your transformation aspirations. We are seeing an increase in the number of decisions being made off the back of a set of outdated assumptions, which os leading to project teams limiting the future capability or operational efficiency gains. A key factor in upgrading or replacing core banking infrastructure is to enhance propositional offerings, whilst improving operational efficiency through automation and transforming business processes. It is counterproductive to limit expectations off the back of past migration experiences or outdated or incorrect assumptions.
Lack of knowledge on the legacy systems data
Core platforms used by banks have often been running in excess of 20-years, so we often encounter the inconsistent archiving of legacy system documentation and lack of obtainable skilled resources who understand the functional and technical processes and data structure. This lack of knowledge and understanding can be overcome through a series of well-planned analysis exercises, executed by experienced people and should be factored into the project plan long before a migration is due to take place. In most cases, this analysis can be done in parallel to other exercises so need not bring delay to a project deadlines.
Data quality
The single biggest challenge with any migration exercise, regardless of the technology being used, is the quality of the data held within the legacy system. This is one that accounts for the majority of project delays and excess costs. Assessing data quality upfront, will allow you to plan more effectively for the upcoming project and should ensure you have the right expertise to take action on poor quality data. This is key to mitigating cost increases and project delays. Also, you are likely to see that legacy systems, contain multiple entries for the same client. Agreeing upfront how this data should be handled is advised, to ensure data is neither duplicated nor made redundant if incorrect.
Data Volume
The higher the volume of data, the higher the effort to migrate, right? Wrong. Higher data volumes do not necessarily increase the complexity of the task at hand however, it is likely to require a most robust cleansing and mapping process due to the increased likelihood of encountering poor quality data.
I spoke with Zaui Mahmud Taleb, one of our experienced Senior Consultants, who explains, “It is often wrongly assumed that data volumes directly correlate to the effort required to transform the data before loading into the target system. It’s one that can cause confusion for those clients migrating lower account volumes. The main drivers behind effort estimates are:
- Data quality and whether the historic data requires much transformation, cleansing or reconciliation.
- Migration approach, including whether to undertake an automated or manual migration, or migrate incrementally or in one big-bang and
- The complexity of the business process mapping between the source and target system.
For example, bancon executed a migration for a Tier One Chinese bank, with account volumes in excess of 12 million which was achieved in under 24 months. This was possible because the products and processes being migrated had little variance from that of the source system and the data quality was near best I’ve come across. Compare this to a migration undertaken for a German bank, which had a fraction of the account volumes. It took the same amount of time due to the high degree of variance and complexity in the products and processes migrated across, along with quality of data that required a high decrease of reconciliation.”
Understanding and alignment of business processes
Understanding of the legacy data sets, parameters and attributes and how these map to newly implemented business process, is another key challenge any migration domain will face. It is incorrectly assumed that data parameters will be similar or have 1:1 pairing, which is often not the case. This is another challenge alleviated by creating a migration domain, who should be involved in the formation of newly created business processes.
Evolving project scope
Changes to project scope will almost always impact the migration process, and therefore changes need to be analyzed well in advance of implementation. Time and again changes to project scope are made without involving the migration domain, and causes unnecessary delays to the project. We often witness changes being unwound due to the impact it has to the go-live date of the migration. This is again where you will reap benefit from having a migration domain, who as part of the change board, will help to eliminate any unwarranted delays and allow for effective decision making on proposed scope changes.
Test, test and test again
Besides from running multiple test cycles, it is also advised to thoroughly test business processes with successfully migrated data. This is to ensure that the newly migrated data and the newly implemented processes ‘marry up’ and run as expected. However, what I often witness is a limited set of testing which is restricted to only the commonly used processes, mainly as a way to reduce effort and time. We recommend investing in a more comprehensive set of testing, extending this to cover those less frequently used processes, such as year-end settlement, as a way of avoiding a breakdown in processes in the distance future. It goes without saying, not all processes can be tested. That said, it is not uncommon for specialist migration consultancy partners, such as bancon, to have proprietary automated testing tools which increase the thoroughness of testing whilst at the same time reducing the manual burden. Win win.
Closing comments
Upgrading or replacing your core banking is challenging, migrating data even more so but, by knowing the challenges faced upfront and selecting the right partner(s) is the key to success and will make all the difference when it comes down to the latter stages of the project.
If you would like to discuss further or have any questions relating to an SAP Banking implementation, or migration exercise including our proprietary set of testing tools, please feel free to get in touch with me directly via LinkedIn or email bradley.jarrett@bancon-it.com.
