Tuning Up GM's IT Strategy

As it enters the final stage of its 10-year outsourcing pact with EDS, the company is incrementally looking at a more best-of-breed approach to outsourcing. Like many large multinational conglomerates these days, GM is continuing its quest to reduce its IT costs while spending on technologies that can shorten manufacturing cycles, improve customer and dealer relationships and add efficiencies to all of its processes. While EDS will remain GM's key data-center partner until at least 2006, the company is also doling out business to other systems integrators, notably IBM Global Services, which helped GM build a 22-node global supercomputing network that is being used to reduce the time it takes to process compute-intensive CAD/CAM jobs. This will reduce cycles that once took 36 hours to just 12 hours. While IGS is the key integrator handling non-EDS projects, GM is using other solution providers for more smaller engagements as well, according to Tony Scott, GM's CTO.

In a recent interview with VARBusiness senior editor Jeffrey Schwartz, Scott discussed GM's relationships with its partners, as well as what is leading the auto giant's agenda in 2003. Scott, who reports directly to CIO Ralph

Szygenda, sets all IT and telecommunications architectural standards for the company worldwide.

After slashing vehicle development time from four years to 18 months, GM is looking for further productivity improvements. Reducing cycle time is among GM's key priorities, according to Scott. Also key on GM's IT agenda: removing the complexity of software, consolidation of hardware, and taking all the processes that the company has digitized and building an architecture that will enable real-time decision-making.

VARBusiness: What's the outlook for spending on IT for 2003 at GM?

Scott: We're trying to do two things simultaneously. One is to continue to take cost out of our ongoing operations and maintenance areas while preserving historical levels of new application development. It's a balancing act between those two areas. Our track record so far has been great in terms of our ability to do that. On the operating side, we're focused on things like server consolidation and [a broader] use of standards, more centralization and the kinds of things that take operational cost out. But we also realize that survivability in the business is dependent on our continuing to deliver new applications and improve business functionality. Our overall spending will probably decrease from year to year, but I think most of that difference will come out of the operations cost, not new application development.

VB: So what percentage do you see it decreasing?

Scott: It's single-digit kinds of numbers.

VB: What kind of applications development will you be focusing on?

Scott: There continues to be opportunity to optimize our whole supply chain,to not only take time out, but to improve accuracy in that space. And the second area is customer relationship management,continued focus on the customer and improving our responsiveness and communication with our customer base.

VB: When you say customer relationship management, do you plan to roll out a new CRM suite?

Scott: Yes. We are doing Siebel.

VB: A lot of CRM efforts have not yielded benefits that customers had hoped going into them. How are you looking to avoid falling into that trap?

Scott: We're in the design and requirements phase of our project right now. Like all of our projects at GM, we have very specific business metrics that we ultimately measure the success on the project.

VB: Is EDS going to be involved?

Scott: EDS is one of the vendors. I think the situation at GM is that EDS is still a significant portion of our outsourced business. We are 100 percent outsourced as far as IT is concerned, and EDS is still the lion's share of that, but, obviously, other vendors are involved as well, such as IBM Global Services.

VB: How much business do you envision moving away from EDS as your contractual terms permit?

Scott: The original term of our agreement, which started for a 10-year period, doesn't change very much to 2006. Each year, by contract, we have an agreement regarding how much business we can compete against EDS, so that picture doesn't materially change until 2006.

VB: You recently awarded IBM the supercomputing contract. Do you see other projects like that going to other providers?

Scott: Oh, yes, but it will follow the pattern of things that we've done in the past six or seven years with EDS.

VB: Is EDS giving you what you want?

Scott: I think our overall relationship is probably as good as it has ever been. Obviously, when you drill down, there are always areas you'd hope would be better, and there are other areas that are outperforming expectations. But, on average, I'd say it's as good as it has ever been.

VB: Are you at all concerned about EDS' current financial situation?

Scott: Sure, like all companies we deal with. We have regular dialogue with EDS, but, fundamentally, we're not worried about its survival. We think it's a good, solid company. They have great people, good products, and they will figure out how to survive through this.

VB: Are you getting better pricing leverage in the current climate?

Scott: I think EDS has been responsive, as have our other vendors, in leveraging progress in technology and economies of scale and other efficiencies to deliver pricing improvements to us.

VB: What technologies are on your watch list?

Scott: It's not so much a technology as it is an area of focus: reducing complexity. That's a big issue for us. You've got Web servers, app servers, caching servers, database servers and the list goes on. That increasing complexity is increasing cost, speed of deployment and quality issues across the board. We've been focusing on improving software quality with our large technology vendors, reducing complexity and using more industry-standard technologies to try to impact some of those areas.

VB: So are you looking to Web services to help solve that?

Scott: Web services are a piece, but there's more than that. Let's take software quality as an example. There is no yardstick in the industry for measuring software quality. So, unlike steel that we buy from the steel manufacturers to put into automobiles, where there are well-understood and widely

adopted standards for quality, there is no such thing in software. It's a science experiment every time we bring software and hardware in, and bring it together in terms of whether it's going to work or not. And that's just not a sustainable model for the long term. The example is if GM sold you a car that you had to take to your mechanic to have him assemble and configure before you turn the key on, that's just not a good business model long term. That's the relative state of the art that we're in today. When GM wants to deploy a business solution, we spend a lot of money assembling the parts, configuring, tuning and tweaking, and what have you. We think that whole process needs to get a lot more efficient and productive and deterministic in terms of its outcome.

VB: How would you like to see that addressed?

Scott: I'll give you a couple of examples. I was addressing the CEOs of some of the larger software companies a few months ago out in California, and I asked these executives a question [regarding] their flagship product,"Is the default configuration of that software the way you would recommend most of your customers to run that software?" The answer was "no" in most of those cases. Putting the CD in and installing the software usually requires lots of tuning and configuration before it's optimized. It would be nice if suppliers could adopt simpler methods.

Also, I like IBM's initiative on autonomic computing with more self-configuring, self-healing sorts of capabilities. I think it could make a huge contribution to our speed of deployment,and our ultimate cost of deploying.

VB: To the issue of default settings, are you suggesting that vendors should reevaluate how they configure their software, or are you talking about overall software quality?

Scott: How many of those settings are even necessary in the first place? There's a subset of those settings that really makes a difference, and the rest of them are something an engineer finds interesting but really doesn't in the end make a huge difference. The second issue is adherence to industry standards. Anything that's vendor-unique or proprietary contributes to the high cost of support operation and maintenance, and to slower rather than faster deployment. To become a standard at GM, one of the things that we look at is adherence to industry standards. It could be XML or J2EE or open-architecture types of things, as opposed to technologies I can only buy from a specific vendor.

VB: How much does Linux factor into your short- and long-term thinking?

Scott: It's not a big player right now, though it's certainly moving up on our radar screen. The issue for us, in this 100 percent outsourced model, is it could be a bigger player if there were differences in the costs of ongoing maintenance and support in Linux vs. the traditional players. Right now, there's marginal or no difference. And because that cost is five to seven times the original acquisition cost, it's not compelling for us right at the moment. If the model changes and there are significant changes in the ongoing maintenance and support costs for Linux, then that could be a game-changer. But right now, that doesn't appear to be the case. It's the whole package,not just the software, but the hardware, too. As a simple example, if I'm being charged by a vendor, whether it's EDS or somebody else, based on number of boxes, or based on the fact that there's a box there, and there's no difference in the cost of support for that box, whether it's a Linux box or a traditional Unix-based box, then Linux offers no advantage.

VB: How aggressive will you be with implementing Web services?

Scott: Where it's appropriate. Web services is not a panacea for all the business-system issues in any company, much less GM, but we have significant activity going on in a number of areas of the business where it is an appropriate solution. GMAC,our financial services area,has been a leader. Some of our consumer-facing activities in GM are making use of Web-services technology already, and we're pleased with the results so far.

VB: You mentioned you plan to keep investing in your supply-chain initiatives. Is Covisint still at the core of that?

Scott: It's one piece of the puzzle. Covisint is the auto industry's collective answer in terms of the marketplace between suppliers and the OEMs and so on. But every company,whether it's Ford or Chrysler,has a company side of that. We still have a lot of internal activity that's outside of the purview of Covisint that we can focus on and hopefully improve. GM has made some dramatic improvements in its supply chain in order-to-delivery areas, and we think there's ongoing opportunity there. The results are already phenomenal. For example, we've had a 50 percent reduction in order-delivery times, from the moment a dealer puts an order in for a vehicle to the time it actually arrives on the lot. We've had a better than 50 percent improvement in order accuracy. That has a profound impact up and down the supply chain. It changes dealer behavior. When they have more confidence in the delivery accuracy of GM, they won't do things like order extra inventory when they don't need it, which takes a lot of extra inventory out of the system. It contributes to better customer satisfaction when a dealer says we've ordered this car, and it's going to be here on Thursday the 21st and it arrives on Thursday the 21st. That greatly improves customer satisfaction as opposed to arriving a couple of days early or a couple of days late.

VB: How would you characterize your key strategic goals for this year?

Scott: Overall, the macro-theme is to make GM as much a real-time corporation as possible. The next biggest wave will come from enabling the human beings in GM to make decisions faster. Up until now, we've been throwing a lot of technology at completely digitizing the business, which includes automating all the paper interfaces and paper processes, and so on. So we've taken our product development time from 48 months to 18 months. A lot of that has been by reengineering the business processes and connecting the dots digitally. If you look back historically at reengineering the business processes, what you saw were people having to wait around for computers to do things. That has been flipped on its edge at GM right now. People aren't sitting around waiting for computers to do things as much. Instead, we have a case where we may have computers sitting around waiting for humans to do things. So the next big wave of productivity improvement will come from digitally and electronically assisting people to make decisions faster,more asynchronous collaboration and faster decision times, compressing the human-decision cycle out of necessity involved in every single business.

VB: What are some of the tools you see enabling that?

Scott: Things like workflow tools, collaboration tools, shared workspaces, portable technology, handheld computers and employee connectivity at home. Because it's a 24-hour, around-the-clock business cycle for a large company like GM, infrastructure is just as important as applications.

VB: Are you bullish on mobile devices?

Scott: I'm pretty excited about them. I think you're seeing steady and significant capability increases in those areas. Faster processors, better technology and batteries, better technology and displays,I think they're becoming pretty indispensable in business.

VB: What's your take on the new tablet PC?

Scott: I think it's going to take another turn of the crank before there's widespread mass adoption. I think, fundamentally, they're onto the right idea, but I can see a number of areas of refinement it will need before it takes off. For example, the handwriting software is very good, it's very easy to use and does a reasonably good job of capturing your handwriting on the tablet, but handwriting recognition isn't as fully integrated into the application as ultimately it needs to be. So it's still a cut-and-paste and insert kind of mode, instead of natively writing into an application.

VB: How are you procuring products differently than you have in the past?

Scott: I think you're going to see a much more intimate relationship between us and technology providers directly. We are going to be more demanding and more vocal in terms of what our requirements are from a technology perspective. I think that's a change from how things worked in the past. In the past, we sort of waited for a vendor to come out with technology, and we'd take a look at it and see if it was something we could use or not.

We plan to have much more influence on the shape and direction of the technology, even while it sits in the lab, than we might have had in the past. That includes feature and function, and prioritizing. Also, I don't see any end to us being very focused on the cost side of this. The pressure there, if anything, will continue to increase. And we will be looking for how to make the total cost of ownership of technology solutions better. We can't afford the level of quality that has been predominant in the industry right now. The model of put-it-in-production-and-see-what-breaks is not a good model. We have to engineer a higher-level quality of solutions.