In April, at ABA’s The Great Exchange Conference in Baltimore, Ken Proctor, director of risk management, Brintech, gave a well-attended presentation, Bank Trends in IT Implementation and Risk Management. With sly humor, the straight-talking Proctor offered his take on technology trends. He cited the popularity, among urban banks, of spending on the internet, and noted that, among all banks, spending on branch automation had become a priority. Retaining deposits, attracting new business customers, and boosting productivity with IT remained significant objectives among the community bankers polled in the research Proctor referenced.

The consultant also zeroed in on some basic issues about how systems actually get purchased. One key theme: It’s important to choose vendors based on how their wares will contribute to business objectives. It’s a common-sense message that resonates at a time when C-suite officers are asking middle managers to be especially accountable. Here, we ask Proctor about alignment, risk management, and smart IT planning.

You often hear that it’s important “to gain alignment between the business and IT departments.” Why is such coordination of objectives and efforts still such a challenge a full decade after the great tech bubble of the late ’90s?
Proctor It’s interesting. From what I’ve seen, part of problem is that business and IT personnel don’t fully trust the other. While the two sets of employees are more likely to share information than ever before, each group tends to be unfamiliar with the expertise of the other. That lack of familiarity makes it hard to exchange meaningful information.

Besides, business executives tend to want to put an order in for a system—or application—and get it fast tracked. They want to keep the ROI analysis straightforward—what will work for my group and what will affect my costs in the short run.

The IT guys tend to think about the broader corporate perspective and other issues, including how a given system will integrate with the existing infrastructure.

On the other hand,  IT guys might not always consider factors like usability or familiarity of an application or vendor. They’ll wave their hand and say, “Why do they want that for?” Basically, there’s room for both sides to contribute, even though working this way involves some tough negotiation.

Sounds like you would advocate a more centralized approach, one where a committee would vet a request for a system.
Proctor Not necessarily. Not centralized as in—“IT decides. Or, people who don’t touch the system decide.” Because, from what I’ve observed, many business unit personnel know what they need a system to do and for that reason must have input. (Sometimes, executives aren’t sure why they are buying a system. Maybe they’ve responded to a sales pitch and get stuck on a fast moving train—a different problem.) But, again, I do think it’s important to purchase a given IT system with a full set of considerations, including if it’s really needed or cost justified given its expected use by employees or customers. You also need to consider how well a given application will affect security.

In the presentation, you also spent time talking about operational risk more broadly, including IT-related risk management. When you work with customers, how do you get them started in their risk analysis?
Proctor There are so many misconceptions about risk management that I consider getting my clients comfortable with the terminology my first task. In the banking business, people asked to think about a risk management program tend to think first of credit risk. Or, they think of purchasing insurance to hedge certain types of risk, or they think of hiring a security officer, or they think of adopting internal controls. And, quite frankly, risk mitigation in that sense is so far down into the weeds. Moreover, trying to work this way is attempting to solve a problem that hasn’t been clearly defined with a “silver bullet approach” that’s been randomly defined. You’re not going to get ideal results that way. And so, I get them thinking about defining their challenges as a first step.

Really, operational risk management—which is people, process, and IT related risks—also refers, broadly, to defining (and mitigating) anything that could negatively impact your business or keep you from achieving your defined business and revenue objectives.

Knowledge is power, then, as the saying goes. What always amazes me are the stories I hear about firms that, due to M&A, aren’t sure what they actually have in terms of IT assets. Talk about an unknown exposure…
Proctor Yes, you see operations in all different states out there. Many banks are highly organized. They have an IT risk management and security policy and they use it. And best-practice banks know what serversthey have and where, what desktop units they have, and understand who in the bank uses those assets and have them locked down pretty well.

Still, there are banks that aren’t at that level of sophistication yet or are temporarily disorganized after a major change to their operations.

Then you have organizations that just have to rethink how they operate. I had a client—a bank close to a billion dollars in assets—recently ask us to help determine what servers and other IT assets they had and what, exactly, they were being used to do. The bank had no idea. Now, there are tools out there to map environments and handle the forensics and I knew we could do the work he wanted, but I did tell him that I was surprised that he didn’t know that information already.

I’m sure that comment alone got him thinking.
Proctor I think it did. All we can ask for is improvement. But I will say this: many banks spend too much time on what I consider to be low value-added controls. Often I joke, it’s like rearranging deck chairs on the Titanic. The industry tends to create a lot of reports and check the low-value controls too much.

The spirit of effective risk management  is there, but maybe some of that scrutiny is misplaced. Certainly, the scrutiny will be misplaced if we don’t start with the right context in the first place.

So then, you’re advocating that a bank review its operational profile?
Proctor Yes. If you think about the discipline in terms of a bank’s strategic vision and what their operations actually look like [as compared to the vision], managing risk can be anything from “I might not have the right technology,” to “Gee, in analyzing this area of the business it’s obvious that I’m not collecting the right information about a customer, which could come back to haunt me,” to “When I look at what skill sets are required to do the work I need for the outcomes I said I want, it’s pretty clear I don’t have the right people at this time; I need to hire differently. I’m vulnerable now.”

Good risk management begins with risk assessment, which is about linking relevant details to an accurate snapshot of an organization. You create awareness by looking at the big picture and looking at how the parts relate to the whole. Then, and only then, do you figure out what insurance you need, or what sort of internal controls or information security plan you need and so on.

Walk me through your process of transitioning clients from “silver bullets” to strategic thinking.
Proctor If you, as a client, are trying to go through a risk assessment plan, I start with something I call the seven-lever approach to change management: people, business process, organization, technology, customers, markets, and products and services. When you start to drill down into these categories, identifying the stakeholders in each area, chances are, you are going to think of something in each that needs to be addressed and from there you can get specific in your planning. There’s a stakeholder involved, there’s some project that needs to get scoped out and funded.

Zeroing in on IT specifically, sometimes, your evaluation will show that there’s technology that isn’t being used to its fullest potential (all those unused features for instance) or applications that need to be added.

Sometimes the applications don’t have to change but the business process surrounding the technology does. Typically, some weakness or flaw has to be compensated for in some way.

Would you say this works well because it gets a client to break things down step by step?
Proctor Yes. I find that walking clients through this seven-lever evaluation is a good, systematic way to begin identifying risk exposures. You start to look at them individually and see how they are interrelated. By the way, this sort of driver-based exercise is also a good first step in figuring out what sort of IT systems need to be used by an organization. It will help your technology planning become relevant and support your strategic business.   

That makes sense. In your presentation, you had some fun with the notion that many IT decisions are made for the wrong reasons. What are your concerns?
Proctor My biggest concern is helping a bank avoid being stuck with a system that won’t grow with it or doesn’t serve its agenda. When it comes to spending big bucks on technology, it’s amazing how little thought goes into it. I remember having a slide where I gave examples such as, the CFO attended a conference in Mexico or vendor X flew the head of Retail to Orlando for a weekend and the decision was made. Five years later, everyone hates the results.

And those sorts of scenarios happen more often then you’d think, even in this era. That’s why I think the profiling process is so important. It’s also important to look at business and technology trends and gauge where you want to go strategically. To do that you need to start from a clear assessment of where you stand initially. Not who has the best pitch and who promises something blue sky that a bank isn’t even sure it wants or, more to the point, that it isn’t sure it can’t get with existing equipment or by humbler means. So ask the tough questions:  what are we going to use this for? Why are we buying it now?

 

How are we going to link to anything else we already have? What initiatives are valuable to us? And—getting back to risk management—how does this particular system impact our risk profile? Does it fit in with our architecture?

How are you defining architecture?
Proctor How am I going to plan and  construct this hierarchy of systems to get the best possible results—including the maximum use of information I’ve gathered throughout my operation.

In my definition, I’m not strictly talking about a platform (e.g., Unix vs. Linux) or anything strictly technical. It’s more conceptual.  How can we  best facilitate a coordination among systems and how systems will exchange information without too many layers of middleware or too many copies of the records.

 

Keep in mind, the point of all this technology we’ve placed in banks over the years, the point of all this automation —in a general sense—is to reduce unnecessary labor, cut out unnecessary manual steps. Now, as an industry, we’re at a point where we are operating quite leanly, in fact, as lean as we really can get away with functioning.

It’s more the case that people are trained differently and handle multiple functions than the case that you have all these extra people looking for jobs to do.

 

And so, in order for these lean operations we’ve created to work, of course, the technology has to be effective and it has to pick up the slack. Otherwise, you won’t get the results you expect to get. Really, every system should count. BJ

 

The electronic version of this article available at: http://lb.ec2.nxtbook.com/nxtbooks/sb/ababj0708/index.php?startid=42

TrackBack URI for this entry