Aufdeckung der Herausforderungen bei einer SAP-Banking-Migration

Introduction

With the advancements in technology and increasing number of digital disruptors entering the banking sector, consumer expectation is rapidly involving and forcing the industry to  enter a consistent state of investment into  their service and product offering. Whilst it’s 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, its near on impossible to find knowledgeable resources who understand its capabilities, and if you are lucky enough to find some, wouldn’t recognise it anyhow thanks to a lifetime of tactical enhancements that were added to sweat its tenure.      With mounting pressure to offer unique, value add products and services it’s easy to understand why the banking industry has been turning to new and established technology partners to enable them through innovative and scalable, ‘plug in and play platforms which will go on to create new  revenue  opportunities, whilst at the same time, excite and protect the existing client base. And unlike projects of the past, they needn’t be exhausting or expensive, thanks to the industries investment in enhancing their own internal capabilities though to well thought through training and strategic talent acquisition.    

Then comes the challenge…the migration

As official SAP partners who specialise in its core banking solutions, and as someone who’s always operating within the financial services sector, it’s exciting to see that in the last few years banks have really started to reap the rewards from its 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’re 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 migrations 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 understood by the project team who are undertaking the exercise. 

I spoke with Jörg Mauelshagen, Co-founder and Managing Director of bancon, 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’re 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 at in which is being migrated into, and this throws up different challenges to maybe that of another technology in which the team have more experience.     Whilst I firmly support the decision taken by the banking industry, to utilise and build internal IT capability, which for me if a key to their future success and in some cases survival. The approach I would suggest is one of a half-way house, and one that doesn’t require an infinite budget or external resource pool if organised and executed correctly. By working with an enablement partner who has a detailed understanding of the technology at play, and them knowing the problems clients are likely to face when undertaking a migration, will directly reduce delays and 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 or executed the majority of all worldwide core banking migrations executed by SAP,  we’ve experienced our fair share of challenges, which allows us to lead or work under the existing project management structure and guide them 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 who set out to execute and manage SAP migration exercises in-house, we’re 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 taken care of by the IT team. However, this is far from the truth and should be seen as a core part of the project, an enabler to true business transformation. Experience has shown us that projects that put a focus on the migration exercise are far more likely to succeed and achieve project timelines and budgets. 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 and help the business achieve value sooner.    

Building a coherent migration team  

As explained by Jörg Mauelshagen, it’s imperative that you have a team with the right experience and skill-set to ensure the migrations 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, along with the tasks that need to be executed is key. As also stated, this shouldn’t lead to excesses costs if the correct enablement partner is selected.    

Understanding the art of the possible  

Understanding what is and isn’t feasible when undertaking a migration is essential, and is likely to 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 is leading  to project teams limiting their future capability or operational efficiency gains. Given the fact 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’s 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, along with its data structure. This lack of knowledge and understanding of the system can be overcome through a series of well-planned analysis exercises, executed by experienced resources and should be factored into the project plan long before a migration is expected to take place. In most cases this analysis can be done in parallel to other exercises so needn’t mean the delay to project deadlines.   

Data quality, data, data quality  

The single biggest challenge with any migration exercise, regardless of the technology being use, is the quality of the data held within the legacy system and one that accounts for the majority of project delays and exceeding costs. Assessing data quality upfront, will allow you more effectively plan for the upcoming project and you should ensure you have the right expertise to take action on poor quality data, as this is key to mitigating cost increases and project delays.  Also, you’re likely to see that  legacy  systems,  contain multiple entries for the same client. Agreeing upfront how this data should be handled in advised, to ensure data is not duplicated or incorrect made redundant.    

Data Volume 

The higher the volume of data, the higher the effort to migrate? Wrong. Higher data volumes don’t necessarily increase the complexity of the task at hand, however it’s likely to require a most robust cleansing and mapping process due to the increased likelihood of encountering poor quality data.    I spoke with Kirsten Wohlgemuth, Principle Migration Consultant at bancon, who went on to explain, ‘It often wrongly assumed that data volumes directly correlate to the effort required to transform the data before loading into the target system, and one that can cause confusion for those clients migrating lower account volumes. The main drivers behind effort estimates are

1. Data quality
2. Migration approach - including whether to undertake an automated or manual migration, or migrate incrementally or in one big-bang and 
3. The complexity of the mapping parameter and attributes between the source and target system.

For example, the team and I executed a migration for a Tier-1 Chinese bank, with account volumes in excess of 20-million which was achieved in under 1-year. This was possible through the fact that the products and processes being migrated had little variance from that of the source system. Compare this to a migration undertaken for a Netherlands based private bank, which had a fraction of the account volumes, yet took the same amount of time due to the high degree of variance and complexity in the products and processes being migrated across.   

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’s 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 definition process  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 analysed  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 impact it has to the go-live date of the migration. This is  again  where  you’ll  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 

Whilst it’s widely known that test cycle management is a key stage of a migration process, it’s usually underestimated as to how many test cycles will need to be performed. I’m starting to witness the increase in project teams who either only planned a small number of test cycles, which as testing progresses, is terminated not to be enough or before testing is even executed, estimated test cycles were reduced as a way to claw back lost time through earlier delays within the project. Cutting back on testing will more often or not lead to impacts to go-live success, so we’d always recommend to plan for more than is initially expected and spend due time on running as many cycles as are needed to ensure data quality.   

Closing comments  

Upgrading or replacing your core banking is challenging, migrating  data  even more so, however by  knowing the challenges faced upfront and selecting the right partner(s) with the experience, knowledge and understanding couldn’t be further emphasized and will make all the difference when it comes down to the latter stages of the project.

If you’d like to discuss further or have any questions relating to an SAP  Banking implementation or migration exercise, please feel free to get in touch with me directly via LinkedIn or bradley.jarrett@bancon-it.com