The following article has been approved for viewing by mature audiences only. Young managers, bankers approaching retirement, and anyone with a compromised cardiovascular system may only read this material with permission slips from their doctors.
We’ve heard it said that choosing a new core processing system is really not all that difficult—the hard part is in getting the actual conversion done. After all, so “they” say, the options with respect to core system providers have been declining in recent years to a point product differences are negligible. Someone should probably share that “news” with the folks at Harland, OSI, Metavante’s newly rejuvenated Kirchman group, Fiserv/ITI with its new iSeries platform, and the credit union and thrift systems being re-written or “updated” to include new technology architectures and business functionality. All of these systems—and there are even more than are listed above—have something new and different to offer those financial institutions seeking a system positioned for the future rather than stalled in the past.
Folks, let’s be brutally honest: Core system conversions are difficult. It is never wise to embark on a core system change without compelling reasons—several of them. Darrell K. Royal, the legendary run-oriented football coach at The University of Texas, once said, “When you pass the ball only three things can happen and two of them are bad.” (Hmmm… wonder how he reconciles that with UT’s national championship win with 267 yards passing vs. 289 yards on the ground?) When a bank undertakes a core system conversion virtually everything that can happen is bad, at least in the short term. The best that can be expected is that things will work as well on Monday morning after the conversion as they did the Friday before. Down the road, many things may be improved, but in the short run just maintaining the status quo is a huge win!
Yet organizations do make these painful changes. Why? See if your bank fits any of these criteria:
- your system was first developed in the 1960s or 1970s
- your system is mainframe-based (think big-iron IBM and Unisys systems)
- your vendor is not adding new clients each year (excluding those compulsory conversions forced by mergers and acquisitions)
- your system has no hope of providing business services for loans and deposits without major architectural changes
- your vendor is not yet halfway through a “re-write” that it planned to have finished by 2002
- your system has not had any significant upgrades within the last 10 years
If any of these sound familiar, your bank is operating a system known to vendors as a “cash cow.” Your dearly beloved vendor is content to invest whatever is minimally necessary to keep on milking it, but there is no commitment to keeping it alive for the long term.
The same industry consolidation that has reduced the number of financial institutions has also diminished the future prospects for those bovine core systems that should be Quarter Pounders by now. Even if your system is adequate for the time being, if your organization has changed significantly as a result of growth or acquisition, or if it is changing as a result of shifting strategic objectives, you may not have much choice about making a change.
So what do you do if you’re in that very uncomfortable position of needing to change systems? Get ready to be even more uncomfortable as you read on, because the world of core system conversions has changed, and it is not getting any easier! Increased complexity in our systems environment is requiring an even higher level of conversion expertise and excellence.
Let’s explore an imaginary example. Hypothetical Bank’s conversion team wants their conversion to be a major success. The team sets the following best practice goals for the conversion:
- The data mapping will be superior; all fields will be verified old-to-new.
- Pre- and post-conversion balancing will go well, including all individual tellers and all G/L and profit center activity.
- Training will be thorough.
- Individual sign-on and other “logical” security will be established by the audit department.
- ATM cards will not be changed or re-issued.
- Project team effort will be good—dedicated staff will spend over a year in preparation.
- Project management activities will be admirable, with a brand new Project Management Office supervising the conversion effort.
- Senior management will be kept informed of progress throughout the project.
- Human resources in key areas will be bolstered in preparation for the conversion.
- Vendor support is going to be excellent—lots of “subject matter experts” will be available during and after conversion weekend.
- Pre-conversion testing will be performed better than ever before.
- The timing of the conversion will be well thought out, taking into account holidays and other seasonal fluctuations in activity levels.
- There will be little “scope creep”—the conversion will remain manageable as to the amount of change employees and customers will experience.
- All of the new hardware and software will be installed and tested in advance of the conversion.
- Ancillary system integration will be sound, so that item processing file transfers, loan origination system interfaces, imaging system integration, etc. will be installed early on.
While Cornerstone would include all of these classic best practices in our project plans, these attributes no longer guarantee a successful conversion. This is 2006, and Hypothetical, despite a classic conversion plan, is going to experience a nightmare. This nightmare will primarily stem from the increased complexity of today’s technology environment and the inability to thoroughly identify, plan for and mitigate the “gotchas” that arise so often these days. Let me bring this point home to you, GonzoBankers, with some real-world examples. Listed below are actual “gotchas” I have seen in our industry coupled with unfortunate reaction (in quotes) that bankers have when these issues occur:
- One bank had mapped its old account-based system data to a new customer-based system and inadvertently combined some business and personal accounts. This made the business owners’ personal account information visible to those company employees who were authorized to pay bills from corporate accounts but not authorized to have knowledge of the owner’s personal finances. (“Oh my goodness! How many more sweetheart accounts could there be?”)
- A bank’s Internet banking system, which was modified slightly to accommodate a custom request, worked fine under low–volume conditions but didn’t work efficiently when volume was high, bringing the entire Internet banking system to a crawl at peak-volume times. (“Did we really need them to present paid items in check number sequence instead of in chronological sequence?”)
- One institution found that just a few account number swaps to resolve duplicate accounts were not perfectly input, resulting in mispostings that were noticed by customers within minutes of their occurrence. (“Aren’t we glad we now have all of our check images immediately available for viewing via Internet banking?”)
- Another bank discovered that its batch system, which ran perfectly in a test environment, didn’t do so well in handling ATM and switch activity in real-time AND producing batch reports and statements, so that its online systems were late coming up in the morning. (“That’s not a big deal. All of our teller and branch personnel are trained to work in offline mode for brief periods of time. It’s a bit slower, but we get it done”.) It dawned on this same bank that, with its online information a day old, all of its Internet Banking and cash management customers started to grumble. To make matters worse these customers are so used to having information instantly accessible that they use our voice response unit when the online is stale. (“I thought no one ever used VRU bill pay any more!”)
- Capacity is also a major “gotcha” One bank found its VRU struggling because 12 of the bank’s 48 VRU lines were inoperative on the new VRU box, a problem that was not visible when the bank was testing. (“How were we supposed to simulate enough traffic to keep the first 36 lines busy?”) Another bank discovered that its contact center‘s trunk lines, which operated perfectly for what used to be “normal” volumes, couldn’t keep up with the excessive volume of calls after the conversion. When no one in the bank could get an outgoing line, incoming calls would ring endlessly—another problem that was never seen before. (“Thank heaven for cell phones!”)
- Two or three days into a conversion, one bank discovered that certain merchants were rejecting its online bill payments because of a minor formatting discrepancy between the old bill pay system and the new one. (“Aargh! More calls to the call center!”)
- Several banks have discovered that minor problems with their core systems can cause the ATM switch to go into “stand-in” processing unnecessarily. (“We never had to use stand-in with the old system!”)
- Banks today often find that, immediately after converting, high branch traffic on top of a lack of employee poise with the new systems leads to unbelievably long lines in the branches. (“Won’t closing time ever get here? Damn those extended hours!!!”)
After weeks of fighting with (and generally putting an end to) these types of errors, oversights and misunderstandings, banks ultimately breathe a sigh with relief. (“TGIF… but wait! Our new grocery store branches are open all weekend!”)
Had enough? While I know of no single organization that was unlucky enough to experience all of these real-world problems, almost every bank seems to run into a few of these issues. Technology may be evolving at a rapid pace, but ask yourself, “Are my bank’s conversion processes and expertise evolving fast enough to handle this change?”
There are financial institutions that pull off core system conversions even in this brave new world of around-the-clock, raging system transparency. While banks still need to embrace the best practices that Hypothetical Bank used in our example above, there are some new rules for the road in conversions these days.
#1: Project Management – Solid project management methodologies have to be embraced for all aspects of the conversion, not just those activities touching I.T. Best practices organizations are injecting project discipline into the business areas as well during conversions.
#2: Testing – Testing activities are being expanded to ensure that all functionality and all delivery channels are pushed to limits that may not seem “normal” on conversion day. Interfaces and interoperability between ancillary systems and the core application are receiving a much greater level of attention.
#3: Training – Best practices banks are putting teeth into their conversion training. A strong commitment to training, including proficiency testing and formal certification techniques, has to be present to ensure that users are ready for the switch to be thrown.
#4: Command Center – Banks today are finding better success with extensive up-front planning and execution for those “intensive care” days immediately following conversion. Problems will arise, but those whose command centers can identify issues and implement/communicate solutions quickly can make these issues seem immaterial within a week after going live.
We’ll share even more of the details about how successful conversions are accomplished in a follow-up to this article in the near future.
Like it or not, old banking systems pass into oblivion, just like old football philosophies. Your vendor can’t keep milking that cash cow of a system forever (and at your expense). Core system conversions are to be avoided like the plague, but the harsh reality is that the features/functionality available with an updated system will compel some organizations to take on this onerous task. If your bank is in the position of “when” and not “if” to make a change, remember that the name of the conversion game has changed, too.
-bm
“Luck is what happens when preparation meets opportunity.”
—Darrel K Royal