Why Osram Stuck with SAP

PDF Download

INTERACTIVE TOOL
Moving to an enterprise portal? Download labor estimates (Excel) and project tasks (MS Project).

PDF download of both files
 

The Internet had arrived and Osram wanted to extend its business electronically, taking orders over the Web from its 3,000 distributors on the continent.

Osram had decided it would have to use another vendor, such as market leader Siebel Systems, to manage its relationships with customers online. Or it would temporarily develop a solution on its own. It almost was an open-and-shut case to Mehrdad Laghaeian, vice president of information technologies and chief information officer at Osram. Quite simply, SAP—oft-criticized for being late to adopt Internet technologies—had no product in this arena. Osram had to go elsewhere.

Byrne could not change SAP’s product lineup, but he was not about to give up so easily. He had Laghaeian give a call to Kevin McKay, at the time the chief executive of SAP America. Not long after, Laghaeian and other executives from the two firms gathered around a long, sunlit conference room on the second floor of Osram’s headquarters in Danvers, Mass.

Their attention was focused on a presentation from Peter Lorenz, a product development manager in Germany. He proceeded to give Laghaeian and Osram’s technology staff a look at a project under way in Walldorf, Germany, where SAP is based. The development work centered around a product titled simply, at the time, Internet Sales.

The rest of the world now knows the product as the Customer Relationship Management piece of mySAP.com, a panoply of computer programs for conducting business between businesses over the Web. But, on this spring day in 1999, Lorenz had no product to present. Just slides.

Laghaeian, who had spent a year helping develop an e-business strategy for Osram, would have a tough recommendation for Osram’s business managers to work through. He could lock himself more into SAP’s embrace—in effect betting his company’s electronic business future on its German partner—or pursue a safer strategy that lessened its dependence on one supplier of its enterprise software needs.

Other companies report similar quandaries about how to manage their increasing dependencies on single software companies whose growing portfolios of products underpin their most fundamental processes. Carreker Corp., a supplier of consulting and software to banks, for instance, is in the midst of restructuring its business processes because it is finding it easier to conform to PeopleSoft software, than change it; Odwalla has found the best way to get what it needs to manage its energy juice manufacturing business is not to scream at its primary enterprise business software vendor, Oracle, but to promote its partner in public and get free training and consulting in return; and, payroll processor ADP has taken a tough-love stance with IBM, putting Big Blue’s software team on a rigorous development tracking system it calls the Train; it also makes a point of airing any difficulties at least twice a month. And where Life Time Fitness found its exercise club and health food business constricted by its reliance on Microsoft software, JetBlue Airways embraced Microsoft software as a key means of achieving a cost advantage as a discounter.

But Laghaeian faced an immediate, practical dilemma: Did he go with a product already on the market, even though that would be fraught with the technical difficulty of making it work smoothly with the SAP data and programs that Osram already had in place? Did he buy time by developing a homegrown answer and hope that vendors would catch up? Or did he go through a year of living fretfully, trying to co-develop a product with SAP that met the German software supplier’s needs to support a wide range of other businesses with the product, and, along the way, try to fine-tune it to meet Osram’s needs, as well?

“Where do I go?” asked Laghaeian. Because if he went elsewhere, he would have to “introduce a new interface, and that means two vendors—as one upgrades, the other does not.” Sticking just with SAP is good “because they’re so big everyone wants to connect to them, but even so, the connection is something everybody has to wait for.”

Besides, the data that ran Osram’s business—its manufacturing and accounting systems, its sales and product plans—was tied up in SAP’s flagship suite of enterprise planning software known as R/3. And that was not going to change.

Osram had adopted SAP in August 1994. That was about a year and a half after Osram GmbH, a German company, had bought the Sylvania lighting and precision materials businesses from Texas-based GTE Corp., a telecommunications company, for $1.1 billion. At the time, using enterprise-wide software on a combination of desktop and server computers was considered the cutting edge of corporate technology. Osram was nearly finished with its R/3 deployment.

The deployment had started in corporate finance and worked its way through Osram Sylvania’s biggest division, General Lighting. The software was being used to give the new owners a firm grip on how the North American assets were performing, financially. But chief executive Dean Langford also wanted an “internal supply chain” to improve the efficiency of the company, which did everything from creating the glass and chemicals that went into light assemblies, to the bulbs and ballasts themselves.

Indeed, Osram Sylvania had used the rollout of R/3 to completely reorganize and flatten the structure of its information technology department. At one time, Laghaeian was almost under siege. He alone had 30 direct reports, meaning he “ran like crazy” from cubicle to cubicle and meeting to meeting, to keep on top of the deployment. He worked routinely until 8 p.m. at night and lost weight because of the demands of hands-on management of the deployment of routers, servers, hubs and network cabling over the span of the $70 million, five-year project.

SAP, meanwhile, also was under the gun. By the end of 1999, it had sued Siebel Systems, the company that had largely created the Customer Relationship Management software category, for “predatory hiring practices aimed at SAP,” as its rival hired away 27 of its employees. The hires included two former presidents of SAP America, Paul Wahl and Jeremy Coote. By the end of 2000, SAP also started a program to resell some customer management software—instead of developing its own—from call-center supplier Clarify, a unit of Nortel. But it later backed off.

With that much pressure on SAP, Osram figured it would have some leverage on its vendor. Both Osram and SAP had to succeed in the marketplace. So Laghaeian decided to back a product he had never seen—with the understanding that if SAP couldn’t deliver, Osram would walk away without financial sacrifice.

“[McKay] told us, ‘Whatever it takes, we’ll make it right,'” says Laghaeian.

In the end, Osram decided to bet its e-business strategy on Lorenz’s slideware, and the period that would follow would be what Laghaeian now calls the most stressful 13 months of his life.

“Is this the project that [was] going to kill me?” he would ask himself. “I don’t know. Let’s find out.”

Osram was betting its online future not merely on a product not yet proven in the marketplace, but one that was not yet even created. Really, though, Laghaeian and crew were betting on the capabilities of its long-time provider of enterprise software. And the sense that it was better off managing a vendor it knew well, SAP, than learning to manage a relationship with a new one. Besides, other CRM vendors did not focus on what Osram said it really wanted: to manage its chain of suppliers, integrate internal and external communications, and serve customers better online.

So Osram wrapped itself more tightly into the arms of SAP. It’s a decision many chief information officers and project leaders are making, as they find themselves tack- ling ever-more complex software and information systems deployments.

In the post dot-com era, when e-business is about the heavy lifting of integrating your business and your technology with suppliers and partners and customers whom you may not even know, and where returns on that work are uncertain, betting heavily on a single vendor may be the least painful option—so long as you can muster enough resources to manage a vendor that may be several times your size, and still get day-to-day business done.

“It’s easier to manage a small number of strategic relationships than a large number of random relationships,” says John Swainson, General Manager of IBM’s Software Application and Integration Middleware division. “Customers have discovered that being a systems integrator is expensive.”

In Osram’s case, that commitment meant reordering itself to focus more on the needs of its customers and partners and less on the internal demands created by its ERP system.

Contrary to the popular notion that locking your company into the embrace of one enterprise vendor limits options, technology managers at the companies sampled here, including Carreker, Odwalla, ADP, JetBlue and others, say it makes meeting corporate objectives simpler.

“Life becomes more complex if you have more pieces,” Laghaeian of Osram says. He trained as an electrical engineer and found that, when designing machines, reliability goes down as the number of components goes up.

“It’s like the space shuttle. So I always had that in mind,” he says, “to design with as few pieces as possible. It’s the same thing” in deploying large information systems.