|
||
|
||
|
|
|
|
|
|
|||
|
|
|
|
|
|||
|
 
|
|
|
Doug Busch is vice president and chief information officer of Intel, the world's largest chip maker, where he manages an IT budget of $1.2 billion. Busch joined Intel in 1987 and held various technical and management positions before being appointed CIO in January 2002. Prior to joining Intel, Busch managed research and development programs at Battelle Memorial Institute, including advanced automation programs for the aerospace and nuclear industries. Busch sat down with Gartner VP and Research Fellow Martin Reynolds to discuss some of the issues facing Intel's IT organization and CIOs in general. Interview conducted 10 June 2004
How did you get to be CIO at Intel? Doug Busch: I was actually trained as a mechanical engineer. I came to Intel and worked in the manufacturing organization developing process equipment, process automation, and supervisory control systems for shop floors. Over time, more and more of my work got to be in the information systems side of the house, so I became interested in architecture and systems integration and the systems aspects of how we used information in our factories. I became a giant pain in the neck for most of the people I worked with, as I argued about bringing in new technology and taking a more systematic approach to system integration. Eventually I ended up leading the strategic planning and technical architecture activity for the IT organization. Reynolds: How has your budget changed over the last year? Busch: We're running pretty much flat to last year. We came down a fairly significant budget ramp, reducing spending, and then flattened out about Q3 of last year. The balance of our spending is shifting a little bit, though. We've been rolling off depreciation, and we're starting to do more capital spending, refreshing some of the equipment that we need, and rolling the new depreciation back on to use the latitude that we've got on that. Capital spending's up probably 20 or 30 percent. Reynolds: CEOs look at the IT guys and all those computers and think maybe they can save some money there. What kind of scale were you asked to cut, and how did you do it?
Because of the really tough climate in the semiconductor industry, my budget has actually ratcheted down about 4 percent from 2001 to 2002, and about 12 percent from 2002 to 2003. It's been hard, but I think we have benchmarking evidence to show we were running pretty close to world-class efficiency going into this process. We've had to find ways to do things differently. We're not all the way there yet. We're still working on getting those cost savings. We've focused on making sure we do it in a way that's not destructive to our team or to the company's objectives. Reynolds: You didn't want to pass your cost savings on to somebody else in the form of increased payments? Busch: Right. It accomplishes nothing. We set a goal of a 70 percent yield on the cost savings we achieve. If we cut spending in a particular area by $1 million, we don't want more than $300,000 of it to pop up somewhere else. We're actually doing better than that. We're getting probably 80 or 85 percent yield on what we've done to date. But it has required an enormous amount of innovation to get there. You can't do it by just slashing and burning. Reynolds: You've made a significant investment in wireless for employee mobility over the last couple of years. So you're pretty much fully deployed now?
No, we're still on the path. We're going slower than I would like to, mostly just because of budgetary constraints, but we're going in priority of customer demand. We're currently about 60 percent coverage on our square footage, and probably 80 percent in terms of the highest priority, and of the value that we'd get out of it. That's in terms of coverage of the buildings with APs [access points]. Reynolds: Now that you're into it this far, how do you feel about it? Busch: Interestingly, way better than I expected to. Prior to the deployment, I was a poster child for the recalcitrant CIO on this topic. I was never skeptical about the value, but I thought we were going to have more difficulty than we did. I anticipated lots of coverage problems and stability problems, and I don't think I fully appreciated how much difference it was going to make in the way people would use the Notebooks. It's turned out to be less problematic — in fact, quite clean from a deployment standpoint, and more valuable from a business standpoint than I expected. Here's an example. This is so mundane, it's almost embarrassing, but before we got wireless widely deployed in Intel conference rooms, there was a standard pattern of showing up at the beginning of a meeting and spending the first five minutes scrambling for connections. You'd fight for them, and half the time, somebody would drag in a hub, and they'd be stringing cable — we have some really awful pictures of conference rooms laced with wire and stuff. It doesn't happen anymore. You start the meeting a lot quicker. We've gotten increasingly dependent on everyone having access to the Internet in our meetings. If this was a meeting with just Intel employees, we would have the agenda and the meeting material on a little application we call Web Meeting Manager. I haven't had a paper copy in a meeting for years. You open up your calendar, you go and get your material; all the meeting minutes and stuff are kept on that site. Everybody around the table will be using their Notebooks during the course of the meeting. It would be impractical if we didn't have wireless as widely deployed as we do. So I'm a big fan, at this point.
How about Sarbanes-Oxley? Is that having any effect on what you're doing in IT? Busch: We've looked really hard at Sarbanes-Oxley, and we have a program in place to address any issues that come up. Intel has historically adopted a super high-road approach on any kind of financial reporting and financial controls issues. Lately we've ratcheted our expectations up another notch, not just to get compliant with Sarbanes-Oxley, but to stay ahead of it so we're a level above the minimum requirement. Reynolds: Speaking of which, one of the things that bothers me with Sarbanes, actually with accounting in general, is the issue of control — that somebody could get onto someone else's PC and authorize all kinds of stuff they shouldn't. How are you dealing with authentication on individual PCs? Busch: We don't authenticate based on the hardware device. We authenticate based on the user. We enforce a number of routine good practices, such as automatic timeouts after a short period of inactivity, and a single sign-on mechanism. We're very rigid about enforcing strong password characteristics and password expiration. And we regularly audit to make sure that dead accounts are out of the environment.
What did you use for single sign-on? Is it something Intel did? Busch: That's one of the things we did as an internal development project. There are solutions for it available now in the marketplace. It's an application that gives a user a single password that synchronizes across all the systems the user is registered to access. It also enforces password strength and expiration dates. Yet, I periodically have people tell me they're too important to have to refresh their password. I'm singularly unsympathetic to that notion. You invite people to come to your Web site, you invite people to send e-mail, and there's this enormous community of people who think it's amusing to cause trouble for other folks.
I think we're going to have to evolve to the same view of security that we've evolved to for reliability and data integrity. Historically, people would design systems and then at the end of the design cycle say, "OK, how am I going to make it reliable?" Now, smart developers design reliability into the application. We're still hearing people say, "OK, my application is done. How am I going to make it secure?" It's too late at that point. You've got to design security in at the conceptual stage. Reynolds: Intel has a pretty serious practice of measuring return on IT. Is this beneficial, from an internal perspective? Busch: It's been extremely useful for a couple of reasons. First, we try to have a clear understanding of what we expect to get out of any particular investment, or out of sustaining what we've got, and use that to manage our portfolio investment and fine-tune the way we design projects to produce the best return. Second, this practice has allowed us to build relationships with our internal business partners and take joint responsibility for the success and the payback of the programs.
I've told my finance team some day I'm going to ask them to close IT's books for the quarter without using any spreadsheets, and that I'll buy them a box of 10-key calculators and ledger pads. Afterwards, they need to tell me how many more people they would have to hire to keep doing it that way. Then, we'll compare that cost to the cost of the IT tools they have been using and see how cost effective it looks without IT. It's a ridiculous thing to do, but the mental exercise leads to the conclusion that the 3, 4 or 5 percent the company has been spending on IT isn't some runaway train of money. It's the foundation of why we're able to be competitive. Reynolds: Key in on that one item, on wasting money on IT. Sometimes you do a project and it doesn't work out. Is that money wasted if you've had three or four projects that really did work out? Busch: You want to have a big funnel to collect ideas and then explore them. When stuff doesn't pan out, you learn from it and move on. You don't want to have big projects with enormous amounts of money committed fail because of poor execution or poor management. But, even at that level, there's some yield that you have to expect, and you try to learn from it. I think the other thing is having the courage to kill the program and not the people. You've got to be able to say: "These are the things we've learned from this. These are the things that you should have done better. But, you're not going to be punished for the fact that you took a risk to do something."
Reynolds: About encouraging innovation in your IT staff — having thoughts that benefit you outside of their regular jobs. How do you do to encourage that?
We've actually had a theme on IT innovation for the past several years. It's interesting, because we're trying to get people to think beyond the shortest path to a goal, in two different arenas. One is in the context of the job they do every day. Find ways to avoid problems, find ways to apply innovative methods, break the box on how they think about things. The other is to go clear beyond what their day job is, and think about, for example, usage models. What are the customers' needs we may not be responding to at all? What ways can we take advantage of emerging technology or business process improvements that may be out of scope for what they're currently doing? I did a little analysis a few months ago, and looked at three different domains of innovation. There are continuous improvement kind of innovations. The things Intel makes its bread-and-butter on, reducing defect density and things like that. We do that constantly in IT and in the applications groups. There's a relatively predictable pay-off from those kinds of innovations. You focus on them, you can find improvements to make, and you know you'll get something back out of them. There's another category of innovation which is much more difficult, but predictable if you apply adequate resource to it. In the larger context of Intel's business, it's like when we made the transition to deep UV from conventional lithography, hundreds of millions of dollars worth of investment. You pretty much knew if you made the R&D investment, you could make that transition and solve the problems. Then there's a third category, which is much less predictable, and all you can do, to use an analogy, is till the field, fertilize and water it, and hope something takes root. Those are the truly breakthrough improvements that go beyond incremental improvement or predictable outcomes. In Intel's history, we've actually had a number of these: the micro-processor by Ted Hoff, the invention of the EPROM by Dov Frohman. Nobody can put an investment program in place that says, "I'm going to invent the next microprocessor." It's a lucky accident. But you can create an environment that allows that kind of innovation to happen. And it's a willingness to listen to different ideas; it's enough headroom in people's work days, so they can actually think beyond the task in front of them. We're trying to do all those, and I think the probability is relatively low we will generate the next microprocessor or EPROM out of IT, but I want to have the ground fertilized, so that if it happens, it can happen. Reynolds: I've got one last question for you. Of all the things you've done with IT over the last few years, what is the thing you'd like to replicate in every project? Busch: The thing I would replicate is making sure every job, or at least every organization within IT, has a forward-looking kind of R&D component, and not to allow organizations to focus exclusively on turning the crank on what they've got today. If you don't look downstream at the opportunities in front of you, you choke off the continuous improvement path.
Reynolds: Well, thanks, Doug.  |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
