It’s easy to reminisce about how simple things were when the Internet first showed up at our banks:
- Remember when Tim in Marketing took his first HTML class?
- How about that spinning logo on the home page that froze up everyone’s browser?
- Who could forget the excitement around self-proclaimed revolutions like Wingspan, CyberCash and Flooz? Bankers had fun sipping lattes and talking about “business models.”
Yes, it was an exciting and pretty harmless flirtation with Web technology. Sure, the industry drank a bit too much vision and wore a few strategic lampshades, but… no harm, no foul.
Fast forward to 2002 and Web is no longer a wild party we can forget while hiding those embarrassing Polaroids in the bottom drawer. No Gonzomongers, these days it’s more like a “for better or worse” commitment. Just think about what the term “Web” now means to us all. It’s not simply a place we go, and it’s not just a new delivery channel. Instead, these days when we think “Web,” we think about a technology or infrastructure that is weaving its way into every nook and cranny of the organization. Walk into any bank today and you’ll see bankers telling technologists that they must have browser-based systems. Half of them have no idea exactly how browser technology will benefit them, but they are certain they need it.
The industry is now abuzz with talk of Web services, XML, SOAP, .Net, WSDL – all neat new ways of describing the perpetual lie in technology: “Someday soon, computer systems will integrate seamlessly with one another.”
I would like to send a loud warning to bankers everywhere: Web technology is not a panacea for every frustration we’ve had with computers since playing our first game of Pong. In fact, without good planning, it’s highly likely that we’ll just move our mainframe and Windows information silos to newer, cooler, Web-based silos. In a mad rush to deploy new systems without a clear plan, banks could end up with a hodgepodge of funky navigation, redundant functionality, and disparate information.
If you don’t believe me, let’s go through a common example:
The Van de Lay Bank & Trust wants to build a customer-focused sales culture. In response to this novel strategy, the Retail Banking group buys a Web-based contact management system that needs to be integrated with its branch platform system. The Marketing group begins deploying a 1:1 marketing module with the bank’s Internet banking provider. The Commercial Lending group has rolled out ACT! for all its loan officers while the I.T. department is busy building a custom intranet sales calling program for the Trust Company. Finance begins implementing a customer profitability application, and Human Resources starts pining for a Web-based incentive tracking system. Sound familiar? In this situation, we have an I.T. group working on seven different applications to solve a fairly straightforward business need: build a customer information system that tracks our sales and service interactions, fulfills basic account opening duties, and helps us perform analytics for marketing, profitability and incentive tracking. Complexity creeps in.
What’s brewing on the horizon is a collision of Web technologies in our banks coming from three different directions.
#1: Internet banking solutions are being integrated into back office systems.
The real action with Internet banking these days is process integration with back end systems. For example, if the customer initiates a stop pay on the Web site, that data should flow straight into the core system, the transaction must be posted and a stop payment notice generated. Right now, banks are busy replacing the hamsters on wheels in the back office with automated interfaces from Internet banking applications. This involves a great deal more integration muscle from a bank’s I.T. department and requires a fairly flexible Internet banking solution. In addition, banks will need simple, reusable interfaces in and out of their core systems.
#2: Banks are custom developing more intranet applications.
Custom application development is exploding in many banks. While Cornerstone is not typically a fan of customized systems, there are some valid reasons why this upsurge is happening. First of all, packaged Web applications haven’t been functionally adequate, nor are they proven enough to give bankers what they need. Second, the pricing on high-end Web applications has scared many bankers into developing less elegant but cheap stuff on their own. Finally, these new packaged applications still require a huge amount of integration and tweaking to make them work in a bank’s specific environment. Banks that are customizing things on their intranet simply have not seen a strong value proposition from the vendor market yet.
#3: Vendors are starting to deliver browser-based applications.
Whether they’re loan origination, teller or CRM, browser systems are increasing in number. These systems are still pretty immature, and the watch words are BUYER BEWARE. But very soon, we all will be deploying these applications because they will be the only vendor versions supported.
With this collision on its way, let’s make a promise, GonzoBankers – let’s not screw up this next round of technology. If business areas and I.T. groups do not work together on designing this Web infrastructure, we all will get the technology environment we deserve.
To ensure that something worth a damn evolves over the next few years, bankers and techies should run through the following checklist before deploying any new Web systems.
#1: Can this application cross delivery channels?
A “cross-channel” application can be used on a bank’s Web page, call center, and in the branch. As much as possible, banks should try to deploy these types of solutions. In addition to reducing the number of applications and interfaces necessary in an organization, they also help banks build user-friendly systems for their front lines. For instance, several vendors (www.mortgagebot.com [2], www.digitalinsight.com [3]) created Internet lending systems for customers to apply for loans and receive decisions online. These tools were so simple to use that now they are being deployed in branches and call centers as point of sale tools, replacing clunky internal systems.
#2: How does this application relate to other departmental systems?
Every new Web-based system will be a piece in a larger puzzle the bank is trying to solve. Before letting one department go whole hog with a system, the bank should evaluate what’s going on in other parts of the company. Senior management should strongly challenge business areas to share applications and development resources as much as possible.
#3: Is this a keeper or a throwaway solution?
Many I.T. groups are being forced to find interim solutions for business needs while Web technology matures. It will be important upfront for everyone to agree what applications are likely to be trashed in a 1 – 3 year time frame. This will help avoid over-investing in something that is just there to plug a hole.
#4: Does this system fit within our technology architecture?
Business areas hate to hear the techies bark about technical architectures, but the truth is the techies are right here. When bankers hear SQL, XML, et al, they need to take a deep breath and realize these propeller-heads are trying to help them.
#5: What type of integration can realistically be expected?
In the euphoria that lingers after the Web system demos, there will be a tendency to gloss over the integration challenges with these new products. Right up front, business areas, I.T. departments, and vendors will need to negotiate exactly what data will flow from what systems and how much time and money it will take. Many Web systems will fail as a result of a naïve outlook on system integration.
#6: Have we designed the system to be SIMPLE?
From the moment the Mosaic browser was born, the promise of Web technology has been to make technology simple. The problem is that bankers and technologists both love to over-engineer things. Want a database? Let’s do 4,357 different fields! Need work flow? How about 18,000 different ways to set up a loan? We build Taj Mahals and whine about lack of usage. Meanwhile, simple applications like Kazaa, PayPal and Amazon get eaten up by users.
Somewhere between the business area and the technologists, banks need good process designers making sure that simplicity and usability are burned into every new system.
Will history rhyme?
Mark Twain once said, “History may not repeat itself, but it does rhyme a lot.”
Let’s face it. We all had high hopes for seamless systems when those DOS-based personal computers first hit the bank. We celebrated a second coming when client/server technology arrived. Yet today, when you ask bankers their greatest frustration with technology, it is invariably system integration.
Web technology will provide banks with yet another chance to address this frustration, but this will not just be a job for technologists. Maybe we won’t make it to the information promised land, but let’s do a better job this time around.
-spw