Informatika | Gazdasági Informatika » 12 Best Practices for a core banking upgrade

12 Best Practices for a Core Banking Upgrade Bankers who have recently completed or are in the midst of a core banking system replacement share their top tips for a successful migration. Bankers often refer to core systems migrations as open heart surgery -- the vast platforms that support all retail transactions are that critical to the life of a bank. Accordingly, the costs -- and risks -- of core banking projects are high. To help you improve the prognosis for your core banking modernization initiative, Bank Systems & Technology asked some bankers who recently completed or are in the middle of a core banking upgrade, as well as the analysts who help them, for their advice on what makes such a project smooth and successful. Here are their top 12 tips: 1. Cleanse data before the migration "Data cleansing is something you have to do beforehand," insists Rudiger Schmidt, head of core banking international at Deutsche Bank, which is implementing TCS BaNCS Core Banking for

global transaction banking in a five- to six-year project that began last year. "Clean up the data in the old system; dont expect the new system to do it" Getting basic information, especially account and customer data, in order is a critical first step, argrees Stefan Besterman, senior manager at consultancy LECG (Devon, Pa.) "Firms need to focus on mastering their data so they can aggregate and maintain control over all of this information," he says. Silicon Valley Bank ($14.8 billion in assets), which is running its legacy and new core banking systems concurrently as it gradually performs its conversion module by module over five years, had engineers ensure that its reporting and online delivery systems were getting the right information from both its legacy and new core systems, according to Bruce Wallace, head of global services. The Santa Clara, Calif.-based bank put all of its customer information files on its new Oracle (Redwood Shores, Calif.) Flexcube core

last year so it would have a single repository even while some accounts remain on the legacy platform. When new data is entered in one system, the other core is updated automatically. 2. Set a schedule and stick to it "For a program like this, momentum is the most important thing; as a result, schedule is important," says Dave Curran, program director of Commonwealth Bank of Australias (US$770 billion in assets) core banking modernization initiative. "These programs are really big, and if you lose your schedule, youll lose your budget and everything else." Schedule drives cost, Curran points out. "In our case, its a four-year program If that four-year program becomes a six-year program, it will cost 50 percent more, because the biggest cost is people. If people work 50 percent longer, it will cost 50 percent more." The price tag for Commonwealth Banks four-year core banking project, which began in 2008, has been publicly estimated at $580 million. The

Sydney-based bank is converting its platforms to SAP for Banking Sticking to a schedule also improves decision making, Curran notes. "If the schedule is not important, you could easily get to the point where you cant make decisions because you want to have another discussion, another meeting, another steering group or conference call, and meanwhile youve lost two or three weeks," he says, adding that the focus on keeping on schedule moves everyone along. "That means occasionally youll make some less-than-perfect decisions. But you can tidy those up later rather than trying to build the perfect solution." Evoking the common analogy, Curran warns, "You cant afford to leave the patient on the table too long. If youre working on the heart and see something wrong with the liver, you might have to get back to that later." 3. Create a high-level decision-making body to arbitrate between different points of view, such as lines of business or operations and IT,

advises Bart Narter, SVP of Boston-based analyst firm Celent. The group -- which should include the heads of operations, IT, retail banking, commercial banking and commercial lending -- should meet at least twice a month, and decisions should be final and binding, he says. "If youre totally reengineering and creating a new system that will affect all parts of the bank, you could go into a two-month spin cycle on a certain issue," Narter notes. "You get senior people to meet once every two weeks and make decisions." At Silicon Valley Bank, an executive steering committee that conducts periodic assessments of the core banking migration includes executives from IT, product ops, the credit group, the front office and the global team. Its chaired by Greg Becker, the banks president, who makes final deployment decisions. "Three key executives are intimately involved in the deployment and execution of the program -- thats absolutely critical," relates the banks

Wallace. Commonwealth Bank of Australia also has an executive steering committee for its core banking project thats chaired by the banks group chief executive and meets monthly. "Weve had 39 meetings and hes only missed one -- because he was sick," says Commonwealth Banks Curran. "Thats a clear example of priority setting." 4. Use a guinea pig One bank in the Northeast US reportedly acquired a smaller bank and piloted its new core banking system at the acquired institution in order to work out the kinks before conducting a full-scale rollout, according to an industry observer who requested anonymity. Conduct this type of test before the new signage goes up and the main bank will be insulated from complaints and criticism about early hiccups in the new software. 5. Create a reusable blueprint Deutsche Bank has created a "migration factory" -- a set of methodologies, tools and capabilities for migrating to or from any platform. According to Deutsches

Schmidt, the bank has built a "storybook" of structured processes for migrating checklists, command center structures, communications structures and all of the other changes needed to facilitate a cutover from one system to another. "Were formalizing it, documenting it and making it repeatable," says Schmidt, who adds that his group is leveraging experiences from former migrations, reusing formerly created tools and runbooks, and improving them. "Each and every defect we find in this migration will be later reworked in the runback." 6. Dont try to do everything at once "You should not try to put all the items on your wish list into your requirements for the new system," Deutsches Schmidt advises. "There will be some users who will feel that if they dont put their wish list in now, theyll never get what they want. But this is open heart surgery," he continues, recalling the common core migration theme. "For the first transformation,

reduce new functionality as much as possible -- just try to migrate your existing business on the new platform," Schmidt adds. "Once you are on a new platform, youre able to get to a new level of productivity, and then you can start implementing new functionalities." 7. Create small subprojects that can deliver value along the road To try to make the process as seamless as possible for clients, Silicon Valley Bank is taking a modular approach to its core banking conversion, migrating one piece at a time over the course of five years. It started with foreign currency loan software, piloting it with a few existing and new clients. According to the banks Wallace, after deploying each module, the bank reassesses its strategy, looking at the success of the deployment and what might have changed from a market or client perspective from when the bank made its original assumptions. "We have course-corrected a couple of times along the way," he relates. "Not

because the deployments didnt go the way we expected them to, but because certain dynamics or our original assumptions had changed. We continue to reassess each time we do a deployment to make sure we have the right prioritization." So far, the bank has been averaging two deployments a year, with two and a half deployments planned for 2011 -- two major deployments with a "mini release" of additional capabilities in between, Wallace says. Commonwealth Bank of Australia, which started its core modernization with a customer data integration project and a deposit program, sees its four-year modernization initiative as a series of projects. Yet, "Youve got to make sure you have regular releases to business," the banks Curran notes. "You cant disappear into the background for two or three years Banks and markets dont have that kind of patience." 8. Expect time and cost overruns "Ive never seen a core banking project go on time," contends

Celents Narter. "Because its such a large, complex project, there are always surprises, and theyre rarely pleasant." 9. Try to enable and retain existing IT employees, even if youre changing IT platforms "Say youre moving from an IBM mainframe to Unix and your IT staff only knows IBM," Narter says. "Its incredibly demotivating to people to know that as soon as the project is done, theyre going to be let go." Instead, invest in retraining the best existing staff on the new system "Among other things, they understand the operations of the bank," Narter explains. 10. Have end users practice using the new system before official rollout "Theyll come up with things that dont work right," points out Narter. End-user training on the new core system is also important to user adoption and the ultimate success of the project, he adds. 11. Manage the migration strictly "The cutover itself has to be a military-like operation to run

smoothly," Deutsche Banks Schmidt says. Commonwealth Bank of Australias Curran points out that good governance is important at all stages. At the "get fit before the operation" stage, Commonwealth worked to integrate all of its customer service touchpoints, upgrade its customer service and Internet platforms, and drive $200 million of annual spend out of IT budgets to help fund the core upgrade, he reports. In a later phase, the migration will involve "cloud enablement of the organization" -- Commonwealth plans both to buy services from the cloud and to make its services available in the cloud, according to Curran. "You can only do that when you have the core, service orientation and architecture right," he says. 12. Be prepared to quickly fix glitches in the new system Half of the effort in deploying a new core banking system with zero downtime is testing, Deutsche Banks Schmidt asserts. "But at the end, you wont be able to test everything,

otherwise youd need to replay, say, an entire years worth of transactions, and even then you havent covered everything," he says. "Besides very expensive testing, you have to be able to react fast to any problem after go-live, and you have to be flexible and prepared for some manual workarounds."