analysis: core banking implementation
IBS Journal January 2016
the parameterised values working well?
• Have the data used for testing shown they have been migrated accurately?
About the author
The experience of the User Acceptance Test (UAT) is always the lead indicator to what end users are likely to experience once the product is rolled out, and therefore it’s important to ensure this is managed well. Large core banking implementations typi- cally would have at least four to five rounds of UAT before there is a general consensus for the product to be rolled out. Additional- ly, a series of System Integration Tests (SIT) are conducted, prior to the UAT, to validate the technical aspects of the system and the interfaces that have been built. There are also specialised third party testing vendors whose services are leveraged for executing this activity, and practices being adopted around AGILE testing methods as well. The key is to start this activity quite early in the game. In addition to the UAT, there are two other popular tests that banks are looking to conduct, and quite rightly so. The first is performance testing, wherein the speed and performance of the system is validat- ed on the specific hardware, to ensure the response time and end user experience (and in the case of channel transactions, custom- er experience) is assured. The second test is penetration testing, which is to validate that there are no soft spots for an external access into the system. This is more important, where the system is exposed on the internet.
V Ramkumar is a Partner at Cedar Management Consulting International LLC. Ram has over 20 years of strategic and technology transformation experience, and is responsible for over 40 large technology transformation programmes. He can be reached at
v.ramkumar@cedar-consulting.com
30
Training: unlearning and learning No matter how good the system is, and no matter how well the product is customised, parameterised and tested, if the training of the product is incomplete or insufficient, then there is every likelihood that the product gets to be ‘disowned’ by the users. And the risk of this is quite large where the users are used to an old platform and the merits/benefits of the new platform are not sufficiently explained and appreciated. The ‘unlearning’ of the old ways of doing things is equally, if not more important, than the learning of the new platform. One of the most common errors that
many banks tend to do in the training is to limit this to technology or system training in the classroom. This false comfort results
© IBS Intelligence 2016
www.ibsintelligence.com
in serious challenges after the system goes live, as the users find it difficult to apply this knowledge in the real world. The train- ing should not only impart the knowledge of the new screens and processes around it, but also ensure the users have actually ‘played with the new system’ in their own environment (and not just in the class- room or CBT). This is also addressed by way of having ‘business simulations’, where all users across the bank are made to actually simulate the life of a normal working day in the bank, by posting the transactions just the way they would after the system went live, and the efficacy of the process and accuracy of the system and its reporting is reassured.
Going live and roll-out: rubber hits the road When the big moment does arrive – and before you realise it, there will be a stage where the marathon becomes a little tiring, and you want to get the system rolled out as soon as you can. There will always be two schools of thought, where one believes we need ‘to take the plunge’, while the other says exactly the opposite – ‘it’s too deep to leap now’. It would therefore not be necessarily the function of people to think or feel about their respective readiness, but leverage a structured framework to measure things holistically. Cedar’s RAPID framework (see p29) is extensively used to determine if the bank is indeed ready to launch the new platform, and helps to measure across the five parameters – Resources, Application, Processes, Infrastructure and Data. Needless to say, the above is not meant
to be exhaustive, but a more definitive and vital check-list for the launch of the core banking platform. Independent of whether it is a ‘big-bang’ go-live or a phased roll-out, unless you have a green light across all of the above parameters, it would be a little prema- ture to announce the arrival of the newborn. That being said, the success and efficacy of the new system does not get measured by how smooth the cutover was, but almost always, inevitably, based on how good the experience is after the system went live. And that’s a function, as we discussed before, of how well we could have the users learn the new platform and unlearn the old ways of doing things. After all, the only constant, as they say, is change!
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
