Potential issues and possible solutions during Core Banking System replacement projects - Part 2.

MINDSPIRE BLOG

Follow MINDSPIRE on social!

András Breuer

Head of Banking Transformation

András has gained 15+ years of experience in the Financial Sector as a Core Banking Systems implementation expert and project manager.

He is currently leading the Core Banking Transformation Services at MINDSPIRE, while supporting our key implementation projects as lead expert and QA.

He also spent 4 years as a line manager at K&H Bank having been responsible for e-channels, front-end, cards, treasury and investment system analysts.

His main strengths are Core Banking platforms, business and IT architecture design and vendor side communication.

Modeling, specification, list of requirements

In the case of a phased approach, it is recommended to make the large and complex tasks that need to be implemented in one phase comprehensible for external and internal stakeholders.

In addition, it is worth structuring them in such a way that stakeholders are comfortable with these tasks, can get a grasp of them and can manage them properly. The possibility of overarching understanding is also worth paying attention to in the case of a big bang approach to CBS replacement projects. Long-term transparency of the tasks and their interdependencies is even more important for a phased approach.

For a traditional project, which is less complex than the core banking transformation, the approach of preparing a specification according to local traditions (without modeling), along which the development is carried out, may work well.

However, the following potential problems may arise on CBS replacement projects:

• On the one hand, the correlations between the tasks within the phase, as well as the monitoring of changes, become very difficult due to the high degree of complexity of the business functionality supported by the system. In the case of universal banks, virtually all components are interrelated, which must be understood and analyzed from the aspects of banking operations as well as the specific implementation tasks. In practice, no one can see through this complex, multidimensional structure alone.
• On the other hand, in the case of multiple phases, each phase in itself is a rather expensive and complicated exercise. The amount of changes that can be expected between stages is significant, it affects a substantial part of the solutions created up to that point, and it is also necessary to be able to transform basic solutions. Traditional specifications designed for marginal modifications usually do not support so much change. Other projects usually implemented by banks have a much shorter turnaround time and contain much fewer problems than the replacement of core banking systems, so changes on the fly do not cause challenges of a similar magnitude. However, during the CBS transformation, new products that may appear in the meantime, the legal regulations and the bank’s strategic goals, as well as the bank’s application architecture can all change significantly.

These two problems can lead to a situation, where it would only be possible to successfully execute the project theoretically, if the team would have between ten and a hundred experts with outstanding expertise and adaptability in banking business as well as IT, who should also be able to work together very efficiently and smoothly.

They should be able to keep in their minds thousands of pages of specifications, as well as the logical models and relationships defined therein, and communicate about these in an understandable way within the team, as well as to other units of the organization and to the stakeholders.

Each member of the team should be able to comprehend most of the tasks end-to-end. In practice, a model should be put together in their minds, that is not depicted in any tool.

The probability of gathering such a team is unimaginable for me, I have not seen this in real life so far.

Based on the above, I recommend that the following should definitely be modeled. By modeling, I mostly mean the identification, cataloging, dependency- and change tracking of the following pieces of information:

• business capabilities and requirements,
• application architecture,
• system integrations,
• data.

A suitable tool must be used for modeling the core banking system. In Archi, architecture can be designed according to the ArchiMate methodology, in BizzDesign, for example, it is also possible to perform BPMN, interface, data and UML modeling in addition to the ArchiMate methodology, but Enterprise Architect (Sparx) or ARIS or other similar tools may also be suitable. The point is that the selected solution must be able to monitor the relationships between the listed elements and their changes, and it must support the parallel work of several colleagues on the same model elements (manage concurrent changes).

In other words, the team needs to agree at a higher level of abstraction about the elements of the scope and in what tool they wish to represent all these. Using this framework, they will be able to communicate on a high level with stakeholders about what is happening during the execution of the CBS replacement project.

Should we choose a Big Bang or a phased approach?

Replacing a core banking system is a time-consuming, expensive and complex task. For this reason, the idea comes up more and more often that it is not worth implementing this in one step, but in phases. This approach is typically chosen to reduce the risks of core banking transformation and to deliver faster, more regular, commercially interpretable results. In the Central and Eastern European region during the recent years we have seen many examples of one-step ‘Big Bang’ and phased ‘Baby Steps’ projects as well.

Based on the implemented CBS transformation projects, it can be stated that the goal can be reached with both the phased and the one-step solution. Also, it seems clear that the Big Bang approach is faster and less expensive. In terms of success and risks, the one-step approach does not appear to be an obviously worse choice. However, the first activation, for example in terms of deposits, usually happens earlier in the case of projects implemented in several phases.

The top bank managers often listen to and verify proposals for phasing by branch, segment, channel (“mobile first”, “friends and family”) or product range. In addition, it often arises that it is worth distinguishing between the completed functionality (phasing) and the services offered to customers from it (rollout).
According to my experience, if you want to go with a phased approach, the cheapest, fastest, and easiest for CBS transformation project is identifying a phasing strategy, which intersects the least possible number of end-to-end processes.

I consider end-to-end processes intersecting, when they affect both the existing and the new core banking systems. The more such intersecting processes there are, the more interim developments have to be made, which will only be needed temporarily due to the phased implementation. A lot of these interim solutions are developed between the legacy and the new system. After the completion of the CBS transformation project, they will no longer be in use, as by then the old system has been completely replaced.

End-to-end business processes of banks are mostly separated by product range. Phasing per branches or per channels would intersect a large number of end-to-end processes. A successful solution would mean that all the functionality to support each product line must be ready in the new system for the first branch to go live, while each satellite system must be able to manage having both the legacy as well as the new system in production at the same time. I do not recommend such an approach. According to my experience, the easiest product to implement is the term deposit, and the processes of daily banking and lending are of comparable complexity.

In summary, according to my experience, each phase in itself is an expensive, time-consuming and highly complex task.
During the rollout planning, if we do not want to offer the functions completed in the new CBS system to all customers at the same time, then we must be able to serve the same business capability in parallel from the old and the new solution. This has the following consequences:

• All regulatory, business, and operational changes must be tracked in a synchronized manner in two parallel systems, as long as the parallel operation exists.
• Each satellite application must be prepared for the situation that the capability it previously provided by one system will now be provided by the same system for some customers, while for other customers, it will be provided by a different solution in a slightly different way. Typically, all satellite systems must be armed with this dual capability.

In case of a parallel solution, the previous and the new system will receive a much lower load compared to the full, and it is sufficient to operate them at a lower performance level. However, this is not necessarily true for all components, if an old system – new system router application is built, then it must also be able to serve the full load.

Overall, a phased CBS rollout is an expensive and complex risk mitigation option. In addition, there is a possibility that the project will run out of momentum before its completion and stop midway.

Therefore, by choosing this approach, we recommend phasing by product line, taking care to bring the project to its end, keeping in mind the goals of the project.

If you have any questions about the above, don’t hesitate to contact us and our CBS experts will get in touch with you!

According to my experience, it is worthwhile to analyze what other changes are expected in the architecture before the GAP analysis phase of the CBS transformation. If the bank consciously prepares for these parallel changes and keeps the related activities in sync, it can control the impact of the projects on each other and reduce the unexpected deadline and financial overruns caused by them.

It is worth considering what strategic business projects and programs the bank plans to implement in the coming years, as well as which applications will need to be replaced during this period. Application replacements may become necessary, because their support has expired or the necessary infrastructure is outdated, or the bank is unable to modify them at the speed of regulatory or business needs. It is also worth mapping the expected regulatory changes in this regard, as well as identifying the fundamental changes of the more fundamental architectural elements, such as an ERP system, if they exist.

With a conscious approach, a significant part of the problems and risks generated by parallel changes can be handled well. With proper preparation, holding targeted forums and creating plans, the various efforts can be done harmoniously and in sync.

If you have any questions about the above, send us a message and our experts will contact you!

Summary

The complexity of projects transforming the core banking ecosystem is several orders of magnitude greater than that of the next most complex task. This involves such lead times, costs, and interconnections, for which it is worth preparing thoroughly.

It is recommended to analyze the organization’s view of the CBS system replacement, for example, compared to the changes made earlier, how much of a challenge this endeavor will pose. If it is established that it is much more complicated than the most complex and successfully finished project up to now, then it is also necessary to examine whether the methodology in general usage by the bank, designed and applied for marginal changes in comparison, is suitable for this task as well.

In my opinion, another serious challenge of the projects transforming the CBS environment comes from the fact that there are many, many interconnections in the core banking system of a universal bank. It is possible that in a simpler project, some architects can manage these in their mind, but on orders of magnitude larger scales, it is unlikely that this can be solved without a support tool.

In our opinion, during a CBS system replacement, it may be worthwhile to consider laying a more serious methodological foundation. The core banking system experts of MINDSPIRE are happy to share their experiences in an informal conversation. In addition, our company can also play a role in the development of a customized CBS transformation methodology.

If you are planning a transformation related to a CBS solution, it is definitely worth taking advantage of the free consultation offered by our company, MINDSPIRE Consulting. In doing so, we review the specific circumstances, and based on the lessons learned from similar projects we can search for answers to the questions that arise.

Please see MINDSPIRE’s related:

Do you have a question or comment?

Our latest Banking Transformation References