If there is a prevailing theme that vendors are addressing in their demonstrations these days, it’s “openness.” In most vendor presentations, you can expect the interval between “good morning” and the first use of the word “open” to be about 10 seconds.
There is a reason for the focus – openness is a high priority for buyers right now. However, like many other phrases in banking (think “we’re your partner”), the term “open” has become so broad-based it loses any specific meaning.
What does open mean, anyway? At a high level it means a vendor has the technology, expertise, and willingness to interface its systems and data with other vendors and systems using agreed-upon standards and protocols. The benefits include automated transaction processing, automated sharing of information, simpler updates on both sides, easier use of systems, and lower cost of ownership.
Can’t argue the allure there, can you? Nope. Unfortunately, this simple, high-level scenario hasn’t exactly translated into reality. Banks seldom buy all the products they need from one vendor. They run multiple systems on multiple platforms and are still struggling to share data, eliminate redundant processing and, in general, translate the high-level picture into real, measurable benefits.
So when a bank hears a vendor’s “open” talk, I’m reminded of a suitor insisting to a young woman that the spiritual side of their relationship is far more important than the physical. Though it may be true this time, she’s heard it before and experience has shown her that his actions, ahem, are likely to prove otherwise. (Gonzo scribes are excluded from this stereotype, of course. Not one of us has ever found himself at a Scottsdale watering hole uttering the words, “It’s your mind I’m really attracted to.”)
Well, never mind that right now. The bottom line is that open systems, if leveraged, present a significant opportunity for banks to improve sales, service and efficiency. However, banks need to confirm that the openness is specific and real. How? Here are some tips to help you get the open systems design you need.
- There are different degrees of open.
As my partner Carl Faulkner has patiently explained to me several times, the fact that a vendor has an API (Application Programming Interface, a program that essentially publishes the protocols and rules needed to access a system) doesn’t necessarily mean the vendor’s system is completely open. Some APIs allow access to all core data and transactions. Others allow access to a limited set. This can make a big difference in how systems are able to interface. For example, it may be the difference between a loan origination interface to a servicing system that only funds the loan and one that allows all borrower data (collateral, financials, property information) to automatically be moved to the servicing system with the funding transaction.
Bottom line: Your IT group will need to be diligent in ensuring open means wide open and not “the door is slightly cracked” open.
- Don’t confuse “open” with “easy.”
The fact that there is an API won’t guarantee smooth sailing when interfacing two complex systems. For example, it’s one thing to interface an accounts payable system with a fairly limited set of transactions to a core GL system. It is quite another to interface a teller system that has hundreds of data fields, inquiries and transactions. New technology hasn’t really changed this. APIs and newer programming tools may have made the job easier, but hundreds of transactions are still hundreds of transactions.
Bottom line: Even with new tools, you can plan on more complexity, more testing, and more problem resolution than you first estimated to integrate two “open” systems. My rule for years has been to take the first time estimate for an interface, double it, and add a week.
- “Open” isn’t always a positive.
I was recently sitting in a core systems demo where a user asked what online signature verification system the vendor used. The response: “We’re open to whatever system you choose.” The reaction in the room was funny. What everyone heard was that in addition to picking a core system, they now had to go out and do more work picking an online signature system – and they didn’t want to. They just wanted something that already worked. Oddly, though the vendor responded in exactly the right way, it produced a negative reaction.
My point is this – open is important when systems have high strategic importance. Loan origination, business cash management, and call center management are examples of systems that can be huge differentiators, and banks need a core vendor that is up-front and responsive when interfacing is needed. Openness is far less important when systems are tactical – online reports, teller transaction processing, and fixed assets are three examples where banks just want something that has competitive functionality and already works.
Bottom line: Banks need to have a healthy debate about when open is really important and communicate the results of these discussions to vendors. Vendors need to listen and focus. Let’s put the effort where it makes a difference.
- It’s as much about desire as it is about design.
The best open systems design in the world won’t outweigh a vendor that takes too long, charges too much, and just doesn’t want to interface something for you. What would you rather have – that prospect, or a vendor that may have older systems and tools but would work through weekends and give up Super Bowl tickets to meet your deadline? Yeah, me too.
Bottom line: If a vendor that says it will be open hasn’t proved it with other clients, it’s very likely you won’t see it, either. For example, if no core system user has ever interfaced a third party sales/CRM system to a core system, neither will you. Request specific examples of clients who have asked to interface systems. Then call those clients. You’ll get your “openness” story.
- Front end is more important than back end.
The systems that most need to leverage open design are the systems bankers and customers use in delivery – branch, call center, Internet banking. Many of the interfaces to back-end systems (profitability, data warehouse, fixed assets) require the passing of data from core, but I wouldn’t say that those types of efforts warrant a claim of openness.
Bottom line: Openness is proven at the front end.
- Open is as open does (thanks, Forrest Gump).
A CEO sitting next me at a demo leaned over and whispered, “So what do I get from open?” His point was that we have to translate the benefits of open design into something measurable and meaningful – faster delivery times, lower unit cost, provably reduced technology costs, measurable employee productivity – and he’s right.
Bottom line: It still gets back to measuring results. And while vendors can and should be expected to help with this, it is really the bank’s job.
The technology tools are there, and everybody benefits from the correct execution. I, for one, am open to that idea.
-tr