IBS Journal January 2016


1


• Activities • Pre-requisites • Timelines • Milestones • Critical path • Ownership


• Internal communication


2


• Product walk- through


• Gaps & requirement finalisation


• Customisation effort finalisation


• Initial product review / sanity check


7 phases of core banking transformation 3


4


• DM strategy • Data mapping


• Develop script/tools


• Verification approach


• Mock & drill migrations


• Final migration run plan


• Logic formats


• System parameters


• Technical design


• Process alignment


• Integration


• Quality control


5


• System integra- tion test


• User accept- ance test


• Penetration test


• Performance test


• Acceptance certification


There have been quite a few instances where there is more than one version of the plan that is being followed, and that could be quite ominous – having a single view of the programme and everyone being aligned to it is very important.


Customisation: taming the animal Even before the right core banking solution supplier is identified, banks would typically have gone through a long process of determining the key gaps in the system that need to be customised, in order for the solution to meet with the bank’s require- ments. One of the very initial activities of the implementation programme is where the bank team reviews the product in detail, and reviews the above gaps once again, so that they are fully understood by the supplier’s development team, and are rightly reflected in the functional and sys- tem requirement specifications document. It’s important to have this validated and signed off, as this thereafter becomes the key reference document for the product enhancement team, who typically sit offshore where the customisations are carried out. Other than the interfaces which are


required for the core banking platform to co-exist with other surviving applications, customisations generally constitute both product level changes as well as require- ments prevalent in the region where the bank operates in. Additionally, there would also be ‘bank-specific’ customisations that are required to align with the way in which the bank operates. Now this is where the trouble starts. As long as the changes required in the system are critical – either from a regulatory or regional practice stand- point, they are quite inevitable and need to be accommodated. However, floodgates tend to open up when the bank team tends to go a little overboard and looks to tweak


28 © IBS Intelligence 2016 www.ibsintelligence.com


6


• Core team training


• End-user training


• Computer- based training


• Change management


• Business simulations


7


• Roll-out strategy


• Customer communication


• Full dress rehearsal


• Go-live


• Post go-live stabilisation


the system to make it do what the bank has been ‘traditionally’ practising, from a process perspective. This could sometimes get as bizarre as having to buy an Airbus 380 and making it run on the road! This needs to be contained, and nipped in the bud. Remem- ber, the lesser the customisations, the high- er the chances of a successful implementa- tion and a smooth sail thereafter. A simple rule of thumb that helps


determine if customisation is required would be to use this three-point checklist:


• Is the absence of this customisation likely to violate regulatory compliance norms?


• Would there be a serious deviation from the local/regional practices without this customisation?


•


Is there a very high financial or customer service impact, should this customisation not be done?


If the answer to one or more of the above questions is yes, then you should allow for the customisations to happen. Where the answer is no across all three, then it’s an obvious case for dropping. From my own ex- perience, at least 50% or more of the initially identified customisation items do not have an affirmative answer for all of the above!


Data migration: lock, stock and barrel Data migration is the single longest track that starts way upfront in the programme, and continues till the last migration run, which is also called the final cutover. The whole idea is to ensure that all the data that is required to run the new core bank- ing system gets migrated from the existing sources of data, including the current core banking platform and the aligned ancillary systems. Akin to the shifting of a house, the process of migrating data brings about some striking similarities:


analysis: core banking implementation


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