“I was provided with additional input that was radically different from the truth. I assisted in furthering that version.”
-Colonel Oliver North, from his Iran-Contra testimony
On paper, there is no argument against an enterprise data management strategy and, ergo, system. Virtually every bank strategic plan is based on the assumption that information is one of the most valuable, if not the most valuable, asset of the bank. “Getting better and timelier information” is on the wish list of just about every manager we talk to and is a prime topic in most RFPs.
On the other hand, there has been a reluctance to purchase the data warehouse solutions proposed by vendors. In some cases, there is no choice – the data warehouse solution is mandatory and priced as part of a core system proposal. However, when the system is optional, most banks pass. And, in many of the RFPs we run, the cost of the mandatory data warehouse solution is one of the reasons a core vendor’s proposal will lose.
The reason, at this point, is lack of a credible ROI analysis that can be backed up by case studies at existing client installations. More on that later.
First, some background. All of this effort is targeted to turning data into information, and information into knowledge (actually, there’s the next step of turning knowledge into wisdom, but I’m going to try and avoid getting too Berkeleyesque and zen-like here).
In broad herms, there have been two rounds of data warehouse development. Round 1 took core system information (loan servicing, deposits, GL) and passed it to a data repository – Oracle, SQL, DB2, or some other database program. In most cases, it was not all data, but those fields that were identified as being required the most for analysis. Standard operating reports were created to replace many paper-based ones. Ad hoc report writing tools were available but were far less user friendly than advertised.
Round 2 focused on ancillary systems. Data from many of the front-end and back-end systems were added to the data warehouse. Examples included FDR, CPI, Baker Hill, Shaw, ATM network systems, branch platform systems, Trust systems, and many other stand-alone systems used by the bank whose information was critical for analysis in the minds of bankers. Transfers of these files were automated. Report libraries improved. Ad hoc report writing tools improved, but still stopped short of any “user friendly” test.
From the vendor design perspective, these first two rounds were absolutely necessary. No enterprise information strategy would work without this design. The problem is we’re still here today with no ROI case.
Why? First, we have to agree that there is no single massive home run payoff to an investment in information management. No single report or study of a function will produce large enough results to handle what is still a large investment.
The components of a data warehouse ROI are pretty simple. Combine faster relationship growth, increased fee income, or reduced expenses and you’re there. Now, let’s take these in order. It is difficult to show how a data warehouse directly impacts growth in a big enough way to spend much money – did you need a data warehouse to decide that mortgage borrowers were good HELOC candidates or that there is an opportunity to cross-sell wealth management services to high-end commercial customers? Some improved fee income can be attributed to better information – witness the fee waiver report that everybody gets monthly, or the customer profitability report that caused changes in service charges – but again the connection is somewhat indirect. Did the warehouse really point banks to overdraft privilege programs or cash management sales?
Reduced expenses is the toughest argument, because it mostly relates to reduced time spent by employees gathering, balancing, securing, and reporting data. First, there is no explicit group performing the tasks – everybody does some of it as part of their job, and except for a few people in MIS or Financial, you can’t point to any positions that can be eliminated. Second, even where people can be identified, many managers vote to have the people instead of the systems anyway (people can be put on other assignments if necessary).
The point is not that enterprise information systems have no value or that banks should dismiss them. Rather, it is that quantifying that value into a traditional ROI is, at this point, very difficult.
So how does Round 3 of data warehouse systems help a bank achieve a collective growth, income, and expense benefit to justify the required ongoing investment?
Some thoughts:
- Figure out niches. At many banks, the biggest source of information frustration is the line of business that is highly niched. Examples among our clients include:
- “B” and “C” commercial RE and multi-family property lending
- Venture capital start-up lending
- Ethnic banking in a major metropolitan area
- Lending on long distance trucks
- Indirect auto lending
- Oil well lease financing
- Imaged lockbox for medical claims processing companies.
- In many cases, these business groups don’t use traditional core or ancillary banking systems (due to lack of required functionality/workflow) and, therefore, don’t interface data to or use the data warehouse product. The amount of manual effort that goes into information gathering and analysis in these groups, however, can be substantial. Data warehouse solutions that can aid in the automation of these business lines can add one important chip to the required justification stack.
- Focus on activity. Line of business managers, particularly in retail, value information on employee activities, production, and earnings as much as anything. Automated reporting on sales activity, sales results/success, trend analysis, and (for the third straight year!) automated incentive plan tracking are features that will reduce a lot of obvious manual work and, by the way, get bank ink on a check faster.
- Focus on integration of documents and other objects. A tremendous amount of information used for analysis at banks is paper-based or in spreadsheets. Appraisals, financial spreads for commercial loans, and a fair amount of borrower information that doesn’t ever get transferred from the application are examples of areas that bankers spend a lot of time finding, reading, and combining with online data. Is there interest in being able to write a loan report and incorporate a document or spreadsheet? Would this be viewed as a benefit? Whoo. Fan me.
Clearly, these ideas are part of a long-term picture. And, while the “partnership” concept has been over-hyped to the point of making me want to ralph my lunch, this is one area where it will need to work. Banks will need to be clear about their needs, understand that they will need to help fund development, and look hard at forcing people away from home-grown, Excel-based information systems. Vendors will need to understand that the next round of design will be hard, dirty fingernail work that will require very specific understanding of individual bank processes and information needs. Tain’t likely to be easy.
But you know what? Next to your employees, information is your most valuable asset. And, in the long run, you will have to think globally about its management.
So, to paraphrase every NFL announcer on the air, let’s take the data to the house.
-tr