Ecosystem thinking has become mainstream when banks and banking providers are considering solutions for renewing banking platforms. Typically, the options are to rely on a single vendor strategy, or to consider a multivendor approach. The contemporary version of the multivendor approach is also referred to as composable banking. The philosophy is based on modern technology that enables the selection, and ultimately the connection of, best of breed solutions.
The philosophy was first launched by Mambu, then later incorporated in more accepted general vocabulary by other core banking vendors. Composable banking is explained in more detail in Siili’s recent white paper.
When a bank chooses a solution for their upcoming project, they will face several pertinent questions: how can they ensure the solution will cater for their needs? Should they write down a series of detailed requirements and ask for proposals from vendors, or should they ask vendors to propose the optimum solution from their own perspective? Which approach will guarantee a successful implementation project?
During my 20-year career in the field of European banking I have witnessed several major transformation projects. Including banks changing their core systems. Some of the projects were short sprints and others were long projects spanning many years. Some resulted in success, while others simply failed.
What led to the success of certain projects while causing others to fail? What factors contributed to these outcomes? Are there steps banks can take to ensure they opt for solutions that lead to success? In this blog post, I will draw on my experiences to provide insights for these questions.
Ever since early 2000, I’ve seen a shift from IT to Procurement driven buying processes. Banks have become professional buyers. In numerous financial institutions, the procurement procedures are carefully planned, and the bidding processes are designed to yield appropriate yet cost-effective choices. Yet, despite best intentions, some projects still fail. There is a saying that summarizes this rather well: ‘the devil is in the detail.’
The most common reason for such issues is that the devil appears when projects start to get into detail. Often the scenario goes something like this: the procurement process selects a solution that is considered to best fit a set of predetermined requirements. Parties negotiate contracts and the project starts. Parties start to become familiar with the details of the solution, business processes, and associated systems. Small issues start to surface. Issues that once appeared minor start piling up and contribute to more substantial issues. Eventually, they cause delays, additional work, and increased cost. The schedule and budget start to slip and the project fails when the momentum takes hold.
How can banks avoid this? Why do some projects succeed?
When I was working for world leading core banking providers, I wondered why some clients were happy and some weren’t. In the end, they were operating in the same business, in the same region, and were implementing and using the same solution. I first thought it was the solution that didn’t fit. After switching from one provider to another I noticed that the situation was universal. This raises the question as to why some clients succeed and some do not? I just had experienced a disastrous project, so I had first-hand experience of an unhappy client. The reasons for failure were obvious afterwards.
As I delved into various cases, I unearthed numerous factors contributing to both missed opportunities and project failures. However, what intrigued me even more was the absence of a clear explanation for satisfied clients. To unravel this mystery, I embarked on a mission to secure invitations to meetings with these contented clients. The experience proved to be truly enlightening.
There were two constants that repeatedly surfaced:
- Experienced people with open mind
- Acknowledging and embracing different approach
In the world of banking, things may seem quite similar on the surface, but in reality, every bank has its own unique nuances and intricacies. It's akin to trying to swap an engine from a Volkswagen to a Ford. Despite both being compliant cars approved for use on the road, the engine sizes and connection details are distinct, making the exchange far from straightforward.
Similarly, when it comes to banking, all banks must adhere to the same regulations, yet their IT systems can vary significantly. I once had the opportunity to propose a compliance development project to a bank. We collaborated closely to design a tailored solution, and the project delivery went smoothly, leaving the bank delighted with the outcome. However, when I presented the same proposal to another bank operating in the same country, they declined, on the basis that it wasn't compliant.
This discrepancy begs the question: What can banks do to ensure they assemble the right team with the appropriate expertise for a project? How can they navigate the challenge of embracing different approaches while maintaining compliance? In the upcoming Part 2 of this blog series, I will investigate best practices and the practical steps that I've witnessed to be successful in addressing these crucial questions. Stay tuned for more insights.
Written by:
Tommi Hinkkala
Senior Sales Manager at Siili
Tommi Hinkkala is Senior Partner and Sales Manager at Siili Solutions, where he is building an ecosystem of best partners and identifying solutions for banks and other financial institutions. Prior joining Siili, Tommi has an experience of two decades in banking and Finance and picked up experience in Tieto, Sampo Group, Worldline, Temenos and Mambu during which he helped numerous customers in the Nordics and Northern Europe.