Integrating information systems and corporate strategy.

Integrating information systems and corporate strategy

Imagine that you've just been appointed the executive responsible for information systems in your organization. You find that you're inheriting a clean running DP/MIS shop. You've got a lot of bright people and a lot of good hardware and technology. Transaction processing is going well, as is administrative office automation. But your predecessor was removed for some reason. Clearly, just running a clean DP/MIS shop is no longer enough.

Let's look at some of the pressures you're under. On the one hand, you're being asked to integrate a far broader range of technologies and disciplines than ever before, everything from records management to neural networks. On the other hand, just as you're being asked to integrate, you're also being asked to decentralize the Is function. Business itself is decentralizing to get closer to the customer. And you, as information systems head, must match that decentralization of the business to stay close to your customers. How do you go both ways at once?

Also, your users are clamoring to get these systems more quickly. But as the backlog seems to grow, you're being asked to trim your budgets. These are difficult economic times. And you are overhead, not always seen as a contribution to profits. Again, conflicting objectives.

Moreover, you are expected to play a role in the formulation of business strategy. And yet the financial executive you report to does not view information systems as a strategic resource. Rather, he has an administrative mindset. Therefore, you aren't invited to key business meetings.

All the while, you're being asked to innovate. To do new things in this company. To bring a new way of thinking about information systems. At the same time, you're fighting fires day after day, just struggling to keep your head clear without the budget increases or resources that you'd need to get above it all.

The question is, what will you, our new information systems executive, do?

What are the IS options?

Some common reactions on the part of top management just don't seem to help. For example, the new executive could do nothing. Ninety-eight percent of the CEOs and executive vice presidents of planning were satisfied, said a recent Roper poll, with their IS function. Now, if all they expect is administrative data processing, they're easily satisfied, right? So the person who raises the issue of strategic systems to these top executives has then to deliver; he or she is putting him or herself in the hot seat.

Another option is to build a more responsive information systems organization. But what if the IS executive's past work has been primarily administrative in nature rather than strategic? Then the backlog will be primarily administrative as well. And if the executive builds a more responsive IS organization, he or she is just going to reinforce all the faster the image of IS as a backroom operation that is not really critical to business strategy.

What I'm saying is that somehow this executive has got to do something different. He or she has got to break loose from the administrative mindset, and build a new image of IS as a strategic resource.

In other words, the executive has to demonstrate IS strategic value to the top executives. First, in order to get budgets approved. Second, in order to get participation by top executives in the planning processes. Third, so that the staff will willingly adopt new methods. And finally, of course, so that end users at all levels of the organization will generate more strategic requests.

Before going further, let's define strategic systems. To say that strategic systems equal EDI is a very narrow view. This comes from the DP era. It is essentially a transactions-processing view. Strategic systems should be defined as any information system that contributes directly to the strategic objectives of business.

Strategic systems are everywhere. They are not big, five-year projects. Strategic systems do not need to transform the entire organization. Rather, strategic systems make individuals in all departments brighter and more collaborative and more responsive to their company's market.

The challenge, then, of this newly appointed IS executive is not to build a stratetic system--or two or three--but to build a culture of strategic value. A culture in which users all over the company are bubbling up good ideas, creative ideas for making money with IS. A culture in which company priorities for this limited resource are set by the marketplace--a marketplace that's not bottlenecked through a steering committee rigged towards large projects.

Once this culture of strategic value exists throughout the IS staff, the head of IS will gradually earn his or her way onto the executive committee. The invitation will be based on the track record the executive develops as he or she identifies new opportunities for strategic value and also informs peers of opportunities that IS can offer.

How does this executive build this culture of strategic value? I liken it to changing the direction of a giant oceanliner like the QE II.

The principles

First, let me establish a few basic principles.

The information systems staff should be regarded as a business within a business. This will lead everyone to treat users as customers and to see the inside user community as a marketplace. This, in turn, leads to thinking about marketing strategies and competition. In order to compete effectively, IS needs a broad and well-integrated product line--which leads to thinking about architecture. Finally, to be a low-cost producer of routine services, you need to think about reliability and efficiency.

Most important, this philosophy of a business within a business should lead to an entrepreneurial attitude throughout the IS function. IS is not staff, but a little company that's going to go out there and win in the internal marketplace.

Now, if a company is going to be in this business for a long time, it's got to build a structure that lasts. That's why I see the entire IS function as a finely tuned machine--like a computer program. And when there's a bug in the program, it's the IS executive's job to fix that bug so it doesn't happen again.

The most fundamental issue is building an IS staff that functions as a high-performance team. There's a lot of work involved in integrating diverse technologies into an architecture that (1) is responsive to business needs, (2) has strategic value, and (3) delivers IS systems efficiently and reliably.

The only way the IS executive can achieve that is by learning to live with what he or she has--not waiting for a head count increase--and moving toward high-performance teamwork. The IS executive can't afford obstacles like internal politics or disincentives to innovation. He or she needs to establish a common vision, at all levels of IS, of the principles of organization design needed to build that high-performance teamwork. For a business within a business, this vision is equivalent to an organization plan.

Next, the executive has to spread innovation through the company. In the DP era, innovation meant technological innovation. In the strategic era, it requires users to change the way they do business. There is no payoff unless they do. The IS executive can no longer hide in a glass house worrying about technological innovation. He or she has to drive organizational innovation.

Now, that is not a technical problem; it's a political problem--which does not mean it cannot be planned. In fact, politics must be turned into a science. A consumer products company might think of this as its business plan: how to break into a new market segment.

Finally, IS has got to get out there and deliver strategic systems. That involves two things: finding the right opportunities and figuring out what to do about them. Planning methods that worked for DP/MIS and for administrative office automation will just not work in the strategic era.

Strategic planning is a controversial topic. One reason that strategic planning methods do not deliver strategic systems is that the methods being used are for the most part designed to do a good job of architecture but not designed to identify systems opportunities. So there is the need for a new approach--not to architecture planning, not to capacity or operations planning, but to "opportunity" planning.

Now, strategy gets enacted all through the organization. So the IS executive must look beyond the company's half dozen broad objectives to see how they are deployed through the organization. In this way, the executive identifies the particular people in the hot seat who must achieve each objective. To me, that is what strategic or opportunity planning is all about: finding the people in the hot seat with a direct linkage back to strategy.

What is unique about them and their mission? What particular challenges do they face? One does not get that in-depth understanding of a user's business in a broad organization plan. That is why functional specifications should not be set during this planning process, but rather should wait until there is a one-on-one needs assessment interview. Here, too, structured methods of the past don't work. We need a new business-driven approach.

How to win executive backing

Another issue is the gaining of executive support. Let's assume the IS executive has high-performance teamwork and a politically viable action plan, and he or she is out there delivering strategic value again and again. How does the IS individual get that executive support?

There are two ways to do this. One is to provide solid evidence of the IS contribution to the bottom line. The second is to get the executive hooked with a hands-on experience.

Regarding evidence, I think many financial people are rightly skeptical about productivity statistics. In effect, one is asking: "Who got fired? Where was time saved?" But when one is talking about productivity, one is locking in that old administrative view that the objective is to save a few minutes of administrative time. Well, the IS team had better learn to talk a new language, one that concentrates instead on reporting value-added contributions.

Value added does not mean intangible benefits. These benefits are very real, except one does not measure them in terms of outputs divided by inputs. Nor are they measured with industrial engineering methods. What one can do is isolate the profit contribution of a particular information system. Because when one is looking at contribution to profits, that is tangible.

There's another way to build executive support. The executives who already support IS are usually those who have had some personal experience with it. That's why executive information systems are critically important today in gaining the boss' support. It's important both to the business end and to the IS function. However, we have found in our research that what might be called "common wisdom" about executive information systems may, in fact, be myth.

For example, a lot of people believe that what executives want is touch-screen, menu-driven access to operational data bases. Well, we've been out talking to these executives, and they're using all of the tools in the tool kit, picking their own tool set based on their own personality, the culture, the business environment, and what they're after.

The results of this are fascinating. What executives are doing with these tools is not saving phone calls and paperwork, not relieving their secretaries or their operations supervisors of a workload. Rather, executives talk about using these tools personally to drive a change in the corporate culture, to build a shared vision of values in the organization. For example, we heard a CEO talk about transforming an engineering-driven company into a market-driven company.

So IS must start talking the executives' language. One way to reach them is to convey what other executives are doing online. After listening to these success stories, the prospect will say, "Now, you're talking my language. Those are the same things I worry about."

The key to executive information systems is not ease of use. It's not accuracy of data. The key is that executives perceive a link between a particular tool and the things they're worried about. If they see that link, the systems will work. If they don't see that link, no matter how pretty the system, it just won't work.

In summary, there are four management processes: building high-performance teamwork; proactively managing organizational politics; delivering strategic systems, again and again; and building executive support through hard evidence and actual experience.

The story of Mike

Remember the story of the IS executive I introduced at the start? I was really the story of Mike and a very well-run DP/MIS shop with a four-year backlog, with complaints of unresponsiveness, and with executives skepticism to the point where a task force was looking into the payoff of IS.

So what did Mike do about it? Well, it started with Mike and I meeting with his boss, the CFO, and the corporate CIO. We assessed progress on all four fronts I've described. That led to two parallel efforts. We began right away to build a high-performance team by reorganizing Mike's department and broadening its range of technologies, its architectural vision. The IS team members had no one really doing architecture. They were pretty much just systems developers in the DP/MIS era.

In parallel, they began developing a chargeback mechanism. Now, a market depends on perception of value at the same time as perception of cost. And the two have got to come together to make the market work.

Therefore, in parallel to chargebacks, we used the benefits measurement technique to measure the backlog--to justify it, if you will. As a result, users canceled 25 percent of the backlog on the spot and also found a few items in the backlog more strategic in value.

So the message went to the executive committee that we can indeed be strategic, that some of that backlog is really worth doing. On the other hand, some of it is not worth doing.

What I've just described is phase one, which was done in six months. In the next six months, there will begin a three-pronged effort. Now that we've got the new organization and a market effectively in place, we'll begin an architectural planning process. First, we'll come up with a common definition of architecture. Then we'll need a common framework for architecture: computing architecture, communications architecture, information architecture, and cooperative processing architecture. Then we'll fill in what we know today, the decisions we've made to date--which, in turn, will leave a lot of empty cells to be filled as business needs warrant.

Finally, we'll begin to implement strategic systems. These will be short term and high payoff. We won't spend all year doing a one-year plan. We'll do a quick view of organizational strategy and from there find the hot spots. Then, in the value-added needs assessment interviews, we'll explore these questions: What is the most we can do with the least? Where are the golden apples? In which areas do we find the most added value?

Transforming Mike's DP shop into a strategic IS resource will be tough. It will work if Mike is one who can manage processes rather than projects, if he is not just a computer programmer but an organizational programmer, and if he understands that his job is that of managing innovation in information systems.