The Synergy of Business and Technology Aligned


These real-world examples should provide notice to companies to sit up straight and take the business/technology disconnect seriously. But remember that so far our examples have only focused on what amounts to one side of the story; all IT projects don't end up being miserable failures, or at best, neutral results. When done right ”when business, process, and technology progress hand in hand ”they can act as a catalyst that drives some fundamental changes in how companies approach technology. Consider an example from Scott Hayward, Managing Director at JPMorgan Chase and Company and former chief operating officer (COO) of Investment Banking in the Americas at J.P. Morgan.

Industries like investment banking and consulting are notorious for their high employee turnover ” especially in response to changing market conditions and the introduction of new and disruptive technologies. As a result, there's a lingering fear among banks and consulting firms that when employees leave they'll take their domain expertise and client relationships ”the core of the business ”out the door with them. To institutionalize this knowledge so that this information stays put even as employees come and go, firms often turn to call-reporting systems that capture client conversations. Other employees can then access these conversations to brush up on the latest client needs or to help them cross-sell other products and services.

On paper, call reporting seems to be a no-brainer for investment bankers. But in practice, Hayward received a less-than -enthusiastic response:

Before I got to investment banking and while I was there between 1994 and 1998, I think we probably tried to implement call reporting ”something that would capture our conversations with the client ”no less than three or four times. Each time, it was just assumed that if we built the system people would use it, even without looking all the way upstream first. But instead, we found limited acceptance.

Despite the complimentary relationship between call-reporting technology and the banker's need to institutionalize client knowledge and relationships, the system went largely unused, and most client information continued to be stored in the same place that it had been before: in the employees' heads. According to Hayward, this disregard stemmed from a failure to modify the processes that the employees were accustomed to:

The thing people overlooked was that they didn't go through a complete process: What are the objectives of the business? What's the strategy to achieve those objectives? What are the business processes to implement those strategies? And only then: what technologies do you use to enable you in those processes?

But this isn't Hayward's only experience with call reporting. "The other place that I've seen it," he says, "and the only place that I've seen it work, in fact, is where I am now in investment management."

Like before, call reporting was intended to service clients better, so that no matter where a client touched the organization, the employees would know the last conversation they had, what was on the client's mind, and what his or her needs and concerns were. These are crucial considerations anytime you have more than one person interfacing with a client, such as in JPMorgan Chase and Company's client-service model for investment management, which includes three points of contact: client advisors, portfolio managers, and account managers.

The call-reporting system was designed to capture information and share it between each of these groups, so that a client advisor, for example, wouldn't have to pick up the phone and get updates from the portfolio manager and account manager before talking to the client. "Anytime someone met with a prospect they were trying to convert to a client, or anytime they met with an existing client whether it was a telephone call or in-person meeting," Hayward explains, "those things would get captured."

Like in Hayward's previous experience in investment banking, however, there was a risk that despite its promise, the system might go unused. Hayward's team countered this possibility by establishing a system of incentives that encouraged employees to actually modify their business processes and take advantage of the call-reporting tool:

Basically, people were told that if information wasn't reflected in the call reporting tool, whether it was from the pipeline or new awards we had won, then they wouldn't get credit for it. So the head of sales would say "if I don't see it in the system, then I don't recognize you did it. You get no credit for it. And when we sit down on a quarterly basis and review your progress, you won't get credit for it then either."

The metrics, then, were deliberately built around not just rolling out the technology, but instead encouraging the end-to-end, business-process-technology change that the project required.

Not surprisingly, the client advisors took to the system and achieved the business advantages the project was intended for in the first place.

Consider how Hayward's successful call-reporting project came to pass. At first, the business recognized an opportunity for innovation. Then, they tasked the IT department to build a new system. But at the same time they made it a priority to stress to the client advisors (with a very big stick) why it was important to use it. So when the system finally arrived, the user base was already on board (see Fig. 1.4).

Figure 1.4. Hayward's call-reporting project maintained alignment between business, process, and technology, with impressive results

How Alignment Goes Above and Beyond

Compared to some of the horror stories recounted in this chapter, Hayward's call-reporting vignette looks pretty good. In fact, it looks really good. But, in a sense, it only represents a neutral outcome: there wasn't any disconnect, but at the same time, being aligned from business through process through technology hadn't chalked up any pluses beyond what the system was designed to do in the first place.

Hayward's account of this successful call-reporting system, however, doesn't end with just implementing the system and seeing end-users adopt it. As the employees became more familiar with the system and saw firsthand what it could do for them, their attitude towards it changed. Usually, just getting people to take a look at and consider using new features is a battle unto itself. But the most powerful advantage, Hayward concludes, is when you actually get end-users to ask for more functionality instead of needing to have managers cram it down their throats:

We started to have client advisors or client portfolio managers call the technology team that built the system and the business person who had responsibility for it and say: "Can you build in something so that when I write my call report and put in action steps, it automatically sends a note to the person who's responsible for doing that action step? And as we get closer to the due date of that action step, can it then monitor whether or not it's been completed, and send a reminder when it gets close to the completion date?"

Now, management didn't ask for that; the end user did. The people who are actually on the front lines asked for that. That's nirvana, in my opinion, when you've designed technology directly into how you do your business.

These ideas from client advisors and portfolio managers got Hayward's management team thinking about some enhancements of their own:

One of the things that we had been trying to do for a long time was to get the investment management team to cross sell more, so naturally we were looking for information about whether they were doing it and if so, how much (for example, they had specific targets on the number of private equity sales they needed to achieve, the number of real estate sales or conversations they needed to achieve, etc.). Specifically, we wanted to know how much time they were spending on new client acquisition or cross selling as opposed to retention.

All of this stuff is useful for managers, but it's also useful for the users, because then they can say: "you know I spent a lot of time focusing on private equity, and that tells me that the nature of my client base is more focused on private equity. And so, this type of enhancement would help users know the mind of their client better."

What ultimately evolved in this case is really quite remarkable : the project put in motion a cycle of innovation that cross-pollinated ideas across boundaries between business and technology. Managers have been known to gripe that IT specialists with little understanding of the business are given too much control over IT projects. At the same time, CIO's worry that employees with only a limited understanding of technology are asking coders for the impossible . But by aligning business, process, and technology, Hayward's call-reporting project shows that neither of these concerns has to be true. Innovative ideas can come from anywhere , be understood by everybody, and then be put into place with a mutual understanding of opportunities, goals, and responsibilities. But this happens only after a crucial prerequisite has been met: alignment between business, process, and technology.



The Alignment Effect. How to Get Real Business Value Out of Technology
The Alignment Effect: How to Get Real Business Value Out of Technology
ISBN: 0130449393
EAN: 2147483647
Year: 2001
Pages: 83
Authors: Faisal Hoque

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net