A key challenge banks face is managing the transition to a networked client/server architecture.
Most banks are still enmeshed in a tangle of spaghetti code that offers only a Band-Aid solution to continued reliance on mainframe-based architecture.
Take an increasingly apt example from banking today. A small- business banker, working for a bank that processes transactions on the mainframe and has stand-alone, PC-based, front-end loans support software, calls on a customer in Boston on a Monday morning. The business owner wants to know whether the bank will fund a substantial accounts receivable to a first-time customer on the West Coast.
Accepting the order means a lot to the bank customer. But the receivables amount exceeds its current credit facility. How long will the bank take to process the customer request?
At most banks, the loan officer must go through the following steps:
Ask the customer to complete a detailed application by hand.
Request access to the customer's account history on the mainframe, which will be printed out Tuesday morning.
Write a report for a credit committee overnight.
Input the application Tuesday morning to a front-end loan applications system, along with the analysis, so that a formatted report can be printed out.
Attend an appropriate credit committee meeting for approval on Tuesday afternoon.
Present to the customer approved terms and conditions on Wednesday morning.
That's when the banker gets the bad news: The customer settled for a 10% discount with his West Coast account in exchange for a 10-day cash payment.
Why did this happen?
The time and effort spent on assembling, inputting, and re-inputting all the information required for a decision was the bottleneck. Ten years ago, this approval process would have been considered efficient. Not today.
Consider another example showing how client/server technology could be harnessed to improve the speed of a loan approval.
The small-business account officer works for a New York-based bank that has installed client/server architecture allowing secured, on-line access to the customer. Here's how it works:
The Boston-based customer gets off the telephone with his potential buyer on the West Coast at 9 p.m. EST. He can win the new account if he can offer a 60-day payment term. His bank loan officer has gone home, but the customer gains access to the bank's menu-driven, on-line business service and is guided through an application for an increase in his receivables line.
Once the application is completed, the system takes over. It integrates the application with the customer's account history, runs a commercial credit score based on the history and new information provided, and generates a report for the bank officer.
At 8 a.m. the next day, the loan officer has an urgent E-mail message. Opening the mailbox, the officer gains access to a groupware file containing the application and report. Having reviewed them, the officer adds a recommendation and forwards the application using the groupware facility to a central credit office at 8:45.
At the same time, the officer calls the customer to say that a decision will be in his E-mail box by 10 a.m. The central credit office gives an approval by 9:30 and sends out a terms and conditions agreement to the customer, with a copy to the loan officer.
By 10 a.m., the loan officer is on the telephone, explaining terms and conditions to the customer. The business owner accepts and sends an E- mail to his West Coast buyer giving him a price with 60-day payment terms.
When the West Coast customer accepts the price at 11:00 a.m. EST, the bank's customer formally accepts the offer of an increased accounts receivables line.
The entire transaction was completed before the start of business on the West Coast, giving the bank's customer in Boston high credibility in the eyes of the new West Coast buyer.
This scenario is not lifted from some futurist's text. The hardware, applications software, data base and network technology required for the scenario are available, proven, and used by banks today.
The infrastructure that enables these transactions is the internal bank communications network and the public network provided by telephone utilities. Bank customers use standard communications software on their PCs to obtain secured access to a module within a front-end loans system on a file-server dedicated to processing small-business loans.
The key difference is that, once the customer completes an application, the server begins to communicate and process data automatically, much as a mainframe system would. In most cases today, such servers, even if they exist, are used only for extracting information from a data base, with minimal emphasis on leveraging their flexible processing and communications capabilities.
In our second scenario, the loan processing server is queued and triggered by preset procedures rather than the schedule-based processing routines that drive overnight processing on mainframe systems. The server processes specific routines based on the client's request, downloading customer account information from a small-business-customer data base running off a data base server that is refreshed every morning by data from the bank's core applications.
The small-business loan processing server also has access to relevant credit bureau information, integrates such data with the customer information already on file, produces a standardized report, and uploads it into a groupware application for the loan officer the next morning.
What will it take a bank to make such scenarios routine? The following four-step approach will accelerate the transition and increase its chances of success:
First, the bank diagnoses its current systems architecture by assessing it in terms of:
Which hardware platforms are used.
Where applications functionality resides.
Where data on customer accounts and transactions are stored.
What flexibility exists in gaining access to and manipulating data.
What network architecture delivers functionality to internal and external customers.
Second is the business process redesign.
This critical phase in managing the technology transition is often underestimated. The outcome is achieved by:
Developing scenarios such as the small-business receivables financing example above, in close interaction with technology specialists. These scenarios will be driven by the bank's business strategies.
Creating new, detailed process flows based on scenarios.
Detailing benefits of the redesign in revenue increases and cost savings.
Third, based on the business process redesign, complementary technology architecture is developed in order to:
Identify the functionality required and specify applications to drive these functions.
Develop data base requirements and specific data base solutions.
Specify hardware platforms.
Make detailed cost estimates for installing and operating the technology solutions.
The design of the technology solutions will affect the business process redesign as alternative solutions and their technology costs emerge.
The transition to new technology will not completely supplant mainframe-based processing. It will, however, ease development of a new functionality, especially for high-feature, low-transaction-volume products and services (as well as those supporting alternate delivery options such as PC banking and telephone banking).
Central to the transition's success is creation of a data warehouse infrastructure, which will routinely extract data from the entire range of transactions processing systems. The extracts will be stored in a relational data base, which can be available for decision-making on customer credit as described in the scenario above, customer profitability analysis, and product profitability analysis.
Fourth are approval and installation planning.
The cost-benefit analysis of the alternative business process redesign and technology solutions are presented to the bank's senior management team around line-of-business redesign opportunities. This lets them set priorities for the transition process to focus on where it is most likely to support bank strategic priorities.
Installation planning for the approved transition themes may often involve the outsourcing of both execution and subsequent management of the technology solution.
To supply the ever-increasing responsiveness that customers are demanding from banks, as the rest of the economy is upgraded to more efficient technology, banks will have no choice but to adopt networked client/server technology.
Moreover, such technology will significantly reduce the need for technology economies of scale and offer managements a viable alternative to being acquired. This transition is exceptionally challenging and must be driven by a bank's senior management in partnership with information technology management.
Successfully meeting this challenge, however, will dramatically improve the bank's ability to compete, give value to its customers, and ultimately control its own destiny.
