RAPID framework RAPID framework
• The migration plan is drawn bearing in mind what the ‘end-state’ requirements are. The key aspect here is to ensure the new platform has what it needs, and the objective is not to migrate everything that is presently in the old system.
• Just as we align furniture to a new home’s layout, the data that is migrated will need to be enriched or enhanced to ensure requirements are met. There are multiple approaches from having default fill-in values to an end-to-end enrichment programme based on the complexity of data and availability of time.
• A series of ‘mock’ migrations are to be conducted to fine tune the migration logic, validate the migration code and finally, to clock the migration time. It’s important that the final cutover is executed in the span of 24 to 36 hours, and the repeated mock migrations help sharpen the axe for the final cut.
What to watch out for, is the readiness and accuracy of the approach adopted by the team assigned for validating the data migration. Remember, this is the activity that ensures all the details of the customer including his/her account balance and the financials of the bank are being migrated from one system to another.
Parameterisation: the fine print It is always amazing to note, that no matter how many implementations are done with the same product, and no matter how similar two banks are – in terms of geog- raphy, size, operating model, regulations etc – there are always significant variances to the subtle nuances of what products and services they offer, what procedures are adopted and how the financials are recorded and reported. Well-established global core banking solutions address these differences by way of a very important facet of the implemen- tation, called parameterisation. Right from defining the key variables that build the attributes of a product, to the segments of a customer and the aligned fee structure, defining the accounting treatment that is to be followed and the resultant financial reporting, all of the fine prints of the bank get to be captured and defined in the system through this phase. Ensuring that a core team of people from the bank gets fully famil- iarised with the parameters and the applica- tion is key to ensuring the needs are logically
RAPID framework Cedar’s RAPID framework to assess the go-live readi
RAPI
RAPID framework Cedar’s RAPID framework to assess the go-live readiness
framework IBS Journal January 2016
Cedar’s RAPID framework to assess the go-live readiness Cedar’s RAPID framework to assess go-live readiness
Resources Are the end-users – across branches, central opera- tions, technology unit, HO functions, finance and all customer-fac- ing roles fully trained and certified?
Application Have all the defects identified in the various rounds of testing been resolved and are all the aligned surround systems confirmed to be ready to launch?
Processes Have the new processes been documented, people trained, validated through simulation and end-to-end cycles of transactions experienced?
InfrastructureAre all elements of infrastructure, including production and DR environment, network, branch paraphernalia as well as the enablers tested and ready?
DataHas the migration of data been adequately validated? Are the migration reporting and validation well practiced?
articulated and captured in these parameters. Some of the forward-looking banks
NEW YORK NEW YORK
NEW YORK
also look to leverage this opportunity to develop system aligned process flow doc- uments (PFDs) that help to map the key processes of the bank, reflecting the steps that need to be executed, both within the system and outside the system. The PFD also helps to align with various roles of members within the bank, and serves as a quick reference document both for testing the solution flow, and also for training the end users.
Testing:
www.cedar-consulting.com www.cedar-consulting.com
www.cedar-consulting.com NEW YORK
CHICAGO LONDON PARIS DUBAI MUMBAI CHICAGO LONDON PARIS DUBAI MUMBAI
www.cedar-consulting.com NEW YORK
Cedar’s RAPID framework to assess the go-live readi Cedar’s RAPID framework to assess the go-live readiness
CHICAGO LONDON PARIS DUBAI MUMBAI CHICAGO LONDON PARIS DUBAI M
www.cedar-consulting.com
SHA SH
CHICAGO LONDON PARIS DUBAI M
the defining moment If one lists all the core banking pro- grammes that have failed in the history of technology platform transformations, it is most likely that most of them have been called off during the phase of testing. The ‘testing phase’ as it’s rightly called, is where the bank gets to validate whether the software is ready to be rolled out, and there are three important sub-questions that need a confirmation here:
•
Is the product doing all that it is supposed to do – for which the bank had invested in it?
• Have all the customisations that the bank asked for, been delivered and are
© IBS Intelligence 2016
www.ibsintelligence.com 29
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
