Every year, hundreds of banks choose new systems to help improve their business operations. Each of these banks typically goes to great lengths to evaluate the new system and vendor, hoping to minimize the risk of a bad implementation or a system that doesn’t fit the bill. But how do banks really know if their evaluation is accurate? How can they be sure the new system will meet their needs?
BankPoint started as a consulting company, and we’ve been putting in banking systems for more than 20 years. In our experience, we’ve never seen a system that didn’t have gaps (a material deficiency in the system that didn’t meet the stated requirements). Furthermore, it’s nearly impossible to fully test a system during vendor demos, or even in a lab environment. Until the system is up and running in production, you won’t know for sure whether it will meet all your needs. There are simply too many variables and too many requirements, some of which have yet to be discovered.
Choosing the Right Vendor
So, what can banks do? How can they choose a system and sign a multi-year contract if they know there will be gaps, and what can they do to close the gaps once identified? The answer lies with the vendor. The evaluation of the vendor is, in many ways, more important than the evaluation of the system itself. Because we know there will be gaps, the vendor must be willing and able to close those gaps. In other words, the vendor must be flexible enough to bend but not break.
When selecting a system, we recommend focusing on two things: requirements fit and vendor flexibility. First, look for 80-90% coverage of your must-have features when evaluating system functionality against your requirements. Why not 100%? Because it’s nearly impossible to find a system that fits 100% of your requirements. Instead, look for a system that largely meets your needs but may require a few alterations. Second, be sure the vendor is flexible enough to adapt the system to your needs. Here’s where you fill in the other 10-20% of the missing requirements. If you choose the right vendor, they will help you fill in those gaps during the implementation process. But how, exactly, will they do that?
Closing Requirements Gaps
Once you’ve identified functional gaps (assuming there is an 80-90% fit in other areas) you should work with your vendor to close those gaps during the implementation using one of the following methods:
- Process Change
Often, you may discover that a requirement is not actually a business requirement, but rather a holdover from legacy processes. Many banks suffer from “we’ve always done it this way” syndrome, leading to a list of requirements that are not business requirements, but requirements rooted in the old way of doing things. A good vendor should always ask, “Why?” If you peel the onion on a requirement by asking, “Why is it done that way?”, it should eventually lead to a business need. If one of the answers is “because we’ve always done it that way,” it’s time to re-examine your process. Modern, robust systems will contain a bevy of best practices that you should be looking to adopt. The bank’s processes should strive to adapt to the system’s processes, rather than the other way around. With a little analysis, you may find that some of your requirements are not needed.
For some gaps, workarounds may be sufficient. Work with the vendor to look for ways of meeting your requirements without enhancements. This usually involves adding a few extra steps to a process or utilizing multiple areas of the system to achieve the desired result. In many cases, workarounds can be a valuable approach to resolving system gaps, especially gaps that are not as critical. A good vendor should be able to recommend several workarounds for each requirements gap.
- System enhancements
When all else fails, consider system enhancements. If you’ve discovered a critical gap in requirements that can’t be adequately resolved with process change or workarounds, ask the vendor if it would be possible to enhance the system to provide the missing functionality. Depending on the size of the gap, an agile vendor should be able to develop that functionality during the implementation, so the feature is tested and ready before your launch date. If the gap is critical and you’ve discovered it early enough, you can even bake the enhancement into the contract, requiring the vendor to deliver the feature to your satisfaction within some time period, or you can terminate the agreement. Don’t hesitate to hold the vendor accountable for critical system gaps.
Of the three options above, system enhancements are usually the most difficult, depending on the complexity of the enhancement. This is where vendor flexibility comes into play and why the selection of the vendor is so critical. If the vendor is a large company, you may find that they are more rigid. Software changes can be challenging with larger vendors, leading to costly, time-consuming enhancements, or worse, no enhancement at all. If the vendor is a smaller or newer company, they may not have the maturity to develop critical enhancements on the fly. Look for a vendor in the sweet spot: big enough and mature enough to deliver on system enhancements, and agile enough to deliver the enhancements quickly. Talk to the vendor’s references and ask if they were able to deliver on system enhancements.
All systems have gaps. Your goal should be to discover those gaps as quickly as possible during the system evaluation process, or even during the implementation. If you’ve chosen the right vendor, they can help you close those gaps quickly so you can enjoy the benefits of your new system sooner than later.