Over the past decade, banks in the Middle East have embarked upon a number of core banking transformation initiatives with the stated objective of improving business agility, only to realize the magnitude of challenges and their unpreparedness mid-way, and finally go live compromising on quite a lot of objectives. Given that a transformation initiative has tremendous interplay across multiple service providers including the banking product (solution) vendor, system integrators, assurance specialists and others, this article heavily draws upon our organization’s experience providing assurance services during core banking transformation engagements and highlights some of the common pitfalls along with possible remedial measures.
A common pitfall is the absence of a common understanding among the banks’ stakeholders on the expectations from a transformation program. Replacing a legacy system with a ‘modern’ core banking platform does not automatically result in improved business processes or translate into the better customer experience. The Program Sponsor needs to have onboard all key stakeholders, prioritize key features for implementation, strategize the roadmap and periodically evaluate the business benefits delivered during the course of the transformation program.
Our recommendation: The original business case, payback, and benefits realization needs to be revisited periodically to examine the impact of program delays. Corrective actions need to be initiated that may include a re-look at the program objectives and scope, especially when programs involve huge budgets and are spread over long timelines.
As a part of the program initiation, all key features/requirements need to be cataloged to align with the bank’s business/operations process flow. This activity needs to be done independent of the product (solution) vendor. An observed practice is the banks’ tendency to identify the core banking product first based on high-level product walkthrough sessions without going through the exercise of documenting business requirements. In a lot of instances, requirements were documented only for those features that deviated from the existing functionality available. In our experience, selecting the core banking product first resulted in mismatches between product features and business operations requirements, excessive customizations during implementation and deferring some of the business critical requirements for implementation post Go-Live due to program schedule pressures resulting in expectations mismatch for business stakeholders. Also, incorrectly implemented/deferred implementation of requirements results in maintenance costs for all such changes and delayed business benefits realization.
Our recommendation: Engaging specialists (in-house or external) to document business requirements through structured storyboarding sessions or business process documentation led walkthrough sessions with business stakeholders can ensure a prioritized set of features and functions. This should be used as a basis for core banking product selection.
Another common trend observed was to bundle too many initiatives as a part of the transformation program. Core banking transformation per se may lead to technology and architecture changes. However, bundling it with various other initiatives such as business process re-engineering, new middleware implementation, and the introduction of new delivery channels (Including digital platforms) besides replacement of some surround systems and adopting an omnibus approach complicates an already complicated program and adds a significant number of failure points. Banks have tried to tide over this situation, trying to engage service providers who specialize in such services. However, the enormity of the task of managing multiple solution vendors, stakeholders, and conflicting priorities has resulted in mixed results.
Our recommendation: A strong Program Office that oversees multiple programs being run in parallel is critical to ensure success in this context. An empowered Program Office with Staffing experienced Program Management staff & clearly established accountability would mitigate some of the risks. A phased approach to implementation was more successful rather than a big bang approach.
Quality Assurance services are almost an afterthought during transformation programs. There is an inherent assumption that core banking products are standard products that do not require extensive testing and hence, inadequate time and budget is allocated for verification and validation. What is overlooked is that core banking products need to be tested extensively for integration with other applications in the ecosystem besides being thoroughly tested for custom developed features. We have observed a few banks engage the services of the core banking product for testing services as well. The downside to the approach is the lack of an independent perspective of requirements implementation.
Our recommendation: Banks need to plan and budget for Quality Assurance services adequately during the program initiation itself. Engaging independent assurance service providers can help detect incorrect requirement implementation (prior to Go-Live) that would otherwise go unchallenged in the absence of an independent perspective.
A key aspect that gets missed out during the contracting process is the absence of Service Level Agreements (SLAs) that aligns the interests of all the service providers in the program. Most contracts are bilateral (between the bank and each service provider) and hence can potentially miss out the inter-dependencies. For example, SLAs pertaining to the delivery of defect fixes and quality of defect fixes has a direct impact on the quality assurance program, but the requirements of the QA service provider are ignored during the contracting process with the core banking product vendor thereby having a direct impact on the program schedule. Engaging external advisory firms have produced mixed results on this front.
Our recommendation: Banks need to factor in inter-dependencies of all service providers during the contracting process. Banks need to conduct adequate due diligence before engaging third-party advisory firms who can weigh in with industry benchmarks and help them with the contracting process and subsequent monitoring.
Another critical area often glossed over is the extent of the complexities involved in data migration. The legacy application would have undergone extensive customizations driven by business and regulatory requirements with inadequate documentation describing the changes resulting in an inadequate grasp of the data structures of legacy systems leading to a bigger problem – migrating the data from legacy system to the target system in a reliable manner.
Our recommendation: Early involvement of in-house business/application experts, engagement of the right specialist firms for data migration services and product (solution) vendor teams, agreement on acceptable data quality and scheduling adequate mock runs early during the program to ascertain data quality are some mitigation measures.
As a part of dress rehearsal/operational readiness, banks often complete infrastructure testing, end-user training on the new solution and go live. In a few instances, centralized helpdesk services are set up to tide over the challenges associated with change management. However, there is no ‘ready reckoner’ available for end users to assist with navigating the newly implemented core banking system.
Our recommendation: Banks should get adequate documentation done and get business user manuals created that is in line with the customized version of the IT system being implemented. This will help tide over users’ resistance to uptake of the new system, a key challenge associated with change management.
Some of the other challenges include a lack of attention to non-functional requirements, ability to manage the scope and exit criteria during various rounds of testing through tight gating criteria and a lack of a strong governance and oversight mechanism. All core banking transformation engagements have their fair share of challenges. Acknowledging the complexities and addressing the same through appropriate risk mitigation measures can help banks tide over some of these challenges.
*This article was previously published in Banker Middle East Issue 30 June 2016