The word catastrophe might sound sensationalist — but platform selection is key and if the wrong platform is selected this can be a very bad scenario.. a catastrophe..
So, how can this type of situation be avoided?
Most banks release prodigious RFPs with thousands of difficult questions some looking for functional fit (Can your product do x?) and others attempting to peer into the very soul of the vendor (What is the greatest weakness of your product, and how are you addressing it?) What these questions can miss is the fundamental fit of the product in the context of the bank.
Most core banking projects are transformational in nature – the processes are expected to evolve rather than legacy processes implemented in a modern package. Yet some packages are easier to work with than others and the difference is with the concepts behind the package and how they align with the concepts prevalent in the bank. Banks will expect to adopt new processes but they may not be able to accept new concepts.
Processes are flexible, they can change and platform features come and go — but concepts inherent in packaged products are often at the core of the solution and encapsulated in these concepts are assumptions on how a bank should be run. If these assumptions prove to be invalid for your bank, adopting the package is more difficult. If the concepts align, many aspects of the project become easier.
Concepts are actors and objects expected to be participating in a process. The behaviour and attributes of the actors and objects have been defined within the package based on the assumptions of the scenarios they will participate. If these prove false the result can be either a heavy customization (changing the fundamentals of the package) or major changes in concepts in the bank.
A great place to start in banking software selection is to assess the concepts inherent in the key processes in the organization? How do these conceptual entities interact and what are the rules and flows associated with their interaction?
For the vendor, what is the conceptual flow inherent in the package (for the same processes) and are there any new concepts? Are any of the current concepts missing?
One of the first things that many banks notice is that modern banking platforms have a customer centric rather than account centric design. Customer centricity means that the customer entity is associated with data and activities previously associated at the account level. Some modern platforms include new concepts such as offer, contract, bundle: how will these new concepts mesh with the existing landscape — what are the corollaries? Some of the existing concepts only exist because of legacy constraints. When these concepts are no longer relevant what are the impacts? Downstream systems are expecting these concepts to be present, what happens when they are missing?
The challenge with conceptual misalignment is that it’s really difficult to mask and the associated effort and complexity associated with compensating for the mismatch adds up.
I suggest developing a conceptual view on the bank side and requesting a similar view from the vendor and then discussing the differences. It will be clear what assumptions were made in the creation of the package, and the legacy bound concepts should also be apparent on the bank side.
When the concepts are aligned, the platform is a good fit from many perspectives and when concepts are not aligned everything becomes more difficult.