21 Apr 2018
Banks have always tried to modernize their core systems either by implementing a new system or upgrading their existing systems. The key reason to do this is to get a competitive advantage and also differentiate from their competitors. Banks traditionally have, and will invest in new technology as and when it becomes available and becomes stable. However, many a times this investment does not bring the anticipated benefits to the bank, primarily because of budget overruns or implementations getting delayed.
Here is an analysis below of what can be done differently and pit-falls to avoid at various stages of the implementation project.
Requirements Definition (functional): Most of the banks and vendors take the Statement of Work (SOW) as the requirements document. As a result, the goal i.e. ‘what the final system should be’ becomes a moving target, based on everyone’s own interpretation of the SOW.
Usually a group of Business Analysts will work with the bank to identify and document their existing processes and requirements and try to map them to their software, however, due to the lack of a strategic document or insight or both, this exercise quickly becomes a source of problem for the remainder of the project.
Ideally, at this stage, the resulting business analysis should list among other things
Any business analysis exercise that leaves the Gaps or the mapping to the new system will automatically result in another round of analysis. User Acceptance Test (UAT) cases are mandatory at this stage, as they will set the parameters for success or failure of the new system and will also allow the vendor to complete unit testing on their own.
Requirement Definition (Interfaces): Requirements gathering for systems that need to be integrated with the Core banking system present the next set of challenges in the implementation. Typically, during the preparation of the contract/ SOW neither the bank nor the vendor does a detailed study of the existing peripheral systems of the bank that are already integrated and being used. All these interfaces end up being discovered as the implementation progresses, and typically this requires both technical and functional knowledge to conduct a thorough requirement analysis. But in most of the cases these requirement are gathered by the Technical consultant, which results in the possibility of missing critical business related requirements.
Scope creep and change in requirement: (Without a well-documented business benefits document) Bank’s can easily lose focus because of the following reasons
System Build process: Next stage in the project is building the product on the system. As stated earlier, if the Business Analysis (BA) document does not have a mapping to the new system it will either result in a new round of business analysis or the techies will build it to “their” interpretation of the BA document or in the worst case both. The key is to use simple tools like Tables or Excel sheets to record system mappings so that they can be checked for correctness right after the build.
System Integration Testing: Readiness of the peripheral systems during system integration test (i.e. peripheral systems not being available) is also one of the reasons for implementation delays. In many of the implementations, the bank tries to change the peripheral systems along with the core banking system, which leads to a whole lot of requirement changes, resulting in many of the integration layers requiring to be rebuilt because of the changing requirements of the new peripherals in additional to the banks own new requirements.
Mostly, the built system is handed over to the bank, as UAT cases are not yet ready from the bank. Also, many a times training to the bank is conducted not on the build system specifically done for the bank, but on a generic build. Training conducted on the generic system, which gives ways for the business users to change the existing workflow is another reason for implementation times to stretch. The Bank’s UAT scripts are prepared before the training and also not aligned to the signed business requirement documents.
The most challenging part comes during UAT. Most of the Project Managers will agree that they have to go through multiple UAT cycles in a project due to one single issue. This issue is the Hands-off approach by higher management during the UAT stage. The higher management or their representatives look at the specs of the proposed system / products and approve it. However, at the UAT stage, the actual testing is done by the end users and unless they are sold on the idea of the new system, which is seldom the case, the new system and its vendors are viewed as adversaries instead of an opportunity to improve the business processes.
Another issue in the UAT phase is related to the migration scenarios, and this has to do with data clean up in the old system. Usually, this is delayed till the very end, however, for a successful implementation, this activity should be completed as soon as the system is delivered by the vendor after the build stage. If the migration can be tested and reconciled at this stage, then issues related to incorrect calculations or incorrect mappings will be identified well in advance. Very few banks consider migration as part of UAT and this usually becomes the delaying factor in implementations.
Performance Testing: Most of the project plans do not give importance to performance testing. All Project plans will indicate Build acceptance test (BAT), System Integration Testing (SIT) and User acceptance Test (UAT) but there will seldom be a phase or item for performance testing. Most banks/vendors will club performance test along with the UAT, but this stretches the UAT time because now both functionality and performance is being tested at the same time. Some of the Banks go along with the performance results provided by the vendors or the performance benchmark provided as part of the sales document. Banks seldom realize that the details are given by the vendors based on lot of assumptions which might not be applicable in their case.
Customizations: Customizations are necessary and imperative in core banking systems. These help the bank to be unique compared to their competitors in the market. But, it is important that the bank evaluate how much customization is necessary. Banks make the mistake of customizing a whole lot of things, which makes their process and systems rigid and closed. So, the bank has to re-do the entire work again in future if there is any change to their business process. Also, most of the times, banks do not do a cost benefit analysis of the change request that they raise on the core banking system. There are scenarios where banks spend a lot of money for a customization which could be have been easily eliminated by bringing in strong internal business process in the bank instead of changing the system.
Banks have to come out of their comfort zone of internal implementation methodologies and embrace methodologies suggested by experts who have been there and done that.
Any Core banking implementation helps to overcome the legacy challenges associated with redundant IT infrastructure and obsolete systems, and therefore brings about a reduction in application maintenance costs. The transformation helps in increasing operational efficiency and bringing systems standardization from front-office to back-office. However, it is important to properly assess both quantitative as well as qualitative benefits that a core banking transformation will achieve. A bank should embark on the changes only when there is a strong business case and a positive ROI associated with the change requirement.
Given the high risk associated with core banking implementation, it is essential for a bank to have strong governance and change management structure in place that would smoothly manage all aspects of the transformation from internal stakeholders to external partners.
