“I think ‘immoral’ is probably the wrong word to use… I prefer the word ‘unethical.’”
– Ivan Boesky, inside stock trader
Several years ago, I was visiting with Chuck Van Loan, the CEO of Independent Bancorp in Michigan. I asked him what it was like to manage multiple subsidiaries with aggressive goals and strong line-of-business mentalities. His answer, which always stuck with me, was that it was like trying to herd cats.
Bank senior management and CIOs probably feel much the same way as they plan for and attempt to manage the newest technology wrinkle – the non-bank sub.
These days, in almost any bank holding company over $1 billion – and in many between $200 million and $1 billion – it is common to see subsidiaries consisting of not only a bank, but also an insurance company, securities broker/dealer, leasing company, trust company, wealth management company, ATM management company, or other non-bank subsidiary.
In most cases, the bank is the major sub and has the lion’s share of the technology budget and staff. The conundrum banks face is this: what is the role of the bank’s MIS group in managing technology across the entire holding company? What should be standardized? Who makes spending decisions? How is a necessary independence balanced with a required efficiency?
These are tough questions, because there isn’t a lot of precedent. In our travels, however, we have seen some very good ideas. I’d like to pass them on in the form of a high-level blueprint you can throw out for discussion and argument.
In general, we see three major groups of systems: 1) infrastructure and desktop tools, 2) core accounting and strategic systems, and 3) data and information. Here’s Gonzo’s take on each of these systems:
Standardize, centralize and manage costs with a vengeance.
Hardware, WANs, data lines, operating systems, security and other infrastructure hardware/software (“plumbing,” if you’re the non-technical type) just aren’t that different across industry lines. A single group should be responsible for decisions, installation, support, training, standards and cost-effective deployment in all of the subsidiaries.
Although this is sure to start some arguments, we feel the same way about most desktop software. E-mail, word processing, spreadsheet, contact management and other software don’t vary enough to justify disparate systems. We would include Web page design (not necessarily content) in this group as well.
“Unique” infrastructure/desktop software needs really aren’t unique. The bottom line is that complexity breeds cost and inefficiency, and standards mitigate both.
Let the cats roam.
Realistically, no banking group is ever going to understand core systems run by other industries. Let’s don’t make them try. Leave decisions, management and accountability with the subs.
Seriously challenge the need.
Here’s the tough one. On the one hand, everybody needs, or at least wants, to use best-of-breed systems. On the other hand, many management teams want to foster an environment where business units refer customers to each other (e.g., commercial to insurance, branches to trust, brokerage to commercial). They want salespeople to be able to see all relationships when dealing with a customer. They want to see customer profitability that incorporates all relationships. Many want combined statements, at least with summary information.
The truth is, user desires for best-of-breed systems and management desires for integrated enterprise customer information conflict, unless banks are willing to spend substantial amounts of money on data warehouse/data integration solutions. But that decision must be preceded by a very frank, honest discussion at the senior management level about how real needs are. It’s not enough to say, “We must have better information.” Instead, we suggest you ask these specific questions:
If you answer “yes” to these questions, you will need to enforce an enterprise data strategy that emphasizes standards and control over individual needs. If you answer “no,” save some money and let business groups meet their internal needs individually.
What’s important is to start building the framework to manage these issues. -tr