Why your ERP Integration Efforts End up Looking Like This . . .

Reader ROI

- Learn why software cannot be truly integrated across multiple vendors.

- See the difference between integration and interface.

- Discover how multivendor packages can work.

Getting different vendors to truly integrate complex software is impossible.

But that doesn't mean a more limited form of interfacing can't be achieved.

To sell a multimillion-dollar software system to a big company, a vendor needs a showcase customer. Jay Shreiner, former CIO of the cereal giant Kellogg, played that role for Oracle, which sells, among other things, ERP software. As showcase customers go, Shreiner was ideal: well known and good with customers and the press.

He needed to be good. Shreiner was helping Oracle sell a radically ambitious software product. Launched in 1996, Oracle CPG (consumer packaged goods), promised to integrate four complex software packages from four different vendors - Oracle's ERP software, Indus's enterprise asset management, Manugistics' supply chain management and IMI's order management - into a seamless whole. The combination of software would let CPG companies, which manufacture just about anything sold in a supermarket, run all aspects of their business, from estimating product demand to manufacturing to delivery. Oracle pledged to take responsibility for the integration and support of all of the separate software within CPG.

From a marketing perspective, CPG sounded great. Business executives in the consumer packaged goods industry saw Oracle's grand vision as a way to take a particularly angry monkey off their backs: the need for their own IT departments to do the work of integrating software from different software vendors.

Shreiner also saw it that way. He met with sceptical techies from potential CPG customers and did many interviews with the press affirming his faith in Oracle's ability to pull off this integration miracle. Why did Shreiner put himself on the line for Oracle? Because he was deeply invested as CPG's first customer. According to one source close to the project, Kellogg spent at least $US10 million and devoted as many as 30 programmers over the course of more than three years to helping Oracle piece together the CPG software package. In return, the company was able to influence the features and functions of CPG to meet the cereal company's particular needs. Kellogg was the "poster child" for the Oracle CPG product, says the source.

But after three years of trying, CPG never worked at Kellogg - or anywhere else for that matter, at least not the way Oracle had promised it would. "No one ever got CPG up and running [in its full form]," says Dave Boulanger, research director for enterprise management at AMR Research in Boston. "It was never completed." Some customers got pieces of CPG running, he says, but not the full product.

Donald Klaiss, Oracle's senior vice president of applications development, disagrees. He says that CPG was completed and that Oracle supports the software today. "We had an aggressive plan with our software partners to build integrations between the different pieces of CPG, and those were all built,'' Klaiss says. But former customers claim that Oracle did fail to finish CPG, and that failure cost them millions. "Millions thrown down a rat hole," says one former CIO and CPG customer from the food industry who declined to be identified. Of the three CPG customers interviewed for this story, two abandoned CPG altogether and replaced it with ERP systems from competing vendors. Another customer, Paragon Brands, a nappy manufacturer, is pursuing litigation against Oracle, and still another, Tri Valley Growers, a farm co-op in California, ended up in bankruptcy after spending millions trying to get CPG up and running.

What the CPG debacle demonstrates with frightening clarity is that the task of getting a host of different vendors to integrate CPG complex software programs to the level that Oracle aspired to with CPG is more than difficult; it's impossible. "If you had to point a finger at the root of the problem, it was the integration," says Boulanger. "They could never get the different systems to talk to each other adequately. It was like trying to tie them together with bailing wire."

"It's impossible to try to integrate four pieces like that from different vendors into a single product," agrees Barry Wilderman, a vice president at Meta Group (US).

Yet in the years since CPG was first introduced, the trend toward multivendor software packages has only increased. More and more vendors are banding together to try to increase the breadth of their product coverage to span such realms as e-commerce, Web-based procurement, CRM, ERP and supply chain management. And they are doing this at their customers' requests.

It's a fact of IT life that no single vendor can provide all the software necessary to run a business. CIOs are often left with the daunting task of trying to cobble together different vendors' software packages themselves. And it's a job they are increasingly unprepared to do as cost-conscious IT departments shed their in-house software developers. By buying more software packages from vendors, companies are increasingly beholden to those vendors to do this integration work for them. And the work itself is crucial. If the links between a company's warehouse software system and its finance system break down, its ability to ship goods and close its books grinds to a halt. As companies from Nike to Whirlpool to Hershey have discovered recently, CIOs who can't master the links between big software packages are putting the very survival of their company at risk.

So how do CIOs find their way out of this mess? By finding out what vendors really mean when they say their product is "preintegrated" with a software package from another vendor.

Page Break

The world is filled with press releases and trade show booths in which vendors promise "full integration" among their products. But integration can mean two different things: one relatively easy to achieve, the other maniacally difficult.

On the maniacal side is true integration, in which the guts of the two software programs are linked together to look and act like a single software program. They are built using the same basic programming technologies, share the same user interface and use a common data model, which means they refer to information the same way. In a single vendor's ERP software, the system's different software components - such as HR, finance or order management - are all tightly linked. Make a change in a customer's order in the warehouse, and the folks in finance will see their receivables total change automatically. The business benefit of this type of integration is speed. "If you're a company like Gillette or Colgate Palmolive, you need computer systems capable of responding immediately to Wal-Mart, to say Â'I have product and can ship it now'," says AMR Research's Boulanger. "Real-time response to customers with accurate data is critical to staying in business."

Achieving true integration is extraordinarily difficult for even one vendor to pull off, not to mention the four vendors that Oracle tried to put together in CPG.

According to Klaiss, Oracle achieved this level of integration with one vendor, Datalogix, by buying the company and rewriting the software to fit with Oracle's own technology and data model. But the other pieces of CPG were not integrated to become "a single product", as Oracle's original CPG press release promised. "Not exactly, no," says Klaiss.

Instead, Oracle and its CPG partners wrote software interfaces designed to translate information from one CPG component into a form that the other CPG components could understand. This kind of interface integration allows different software programs to exchange information, much like two kids passing notes in class. Though cheaper and less complex than true integration, interface integration is prone to error and moves information more slowly than true integration.

And even interface integration can be difficult when you're trying to do it across four different vendors, as Oracle did with CPG. Oracle and the other CPG vendors had to agree to the specific types of information that should be shared among their programs and then write an interface for each information exchange - more than 100 interfaces altogether, according to Klaiss. CPG customers say the sheer number and complexity of the interfaces led to problems and repeatedly missed deadlines for CPG releases. "Getting everyone at those different partner companies to agree and to work around a common development and rollout schedule was a virtually impossible task," says one former CPG customer from the food industry. Klaiss acknowledges that some CPG releases were late, adding that "it's much more difficult to do integration [across multiple vendors] than if you manage all the resources yourself."

Page Break

Multivendor alliances aren't just about software integration, however. When vendors agree to integrate their software, they are also agreeing to integrate their companies - which can be much harder to pull off. One sure route to disaster for CIOs is choosing a multivendor alliance where the vendors compete over the same customers or software functionality.

Consider the alliance between procurement software maker Ariba, supply chain specialist i2 and their matchmaker, IBM's consulting division. From the moment the alliance was announced in March 2000, IBM became the shrink attempting to hold a dysfunctional marriage together. Ariba and i2 coveted each other's software - indeed, while proclaiming loyalty to the alliance, Ariba tried to buy Agile, a supply chain software vendor that competed with i2 (the deal fell through), and i2 bought a procurement software vendor, RightWorks, that competed directly with Ariba. The two vendors also coveted each other's customers. Unlike CPG, i2 and Ariba never tried to integrate their two products into a single unit. Customers who wanted the two software programs to communicate had to pay IBM to make it happen. The shaky alliance ended earlier this year.

"By definition, all these folks eventually become competitors," says Jim Prevo, CIO and vice president of Vermont-based Green Mountain Coffee Roasters, which bought into a software alliance between ERP vendor PeopleSoft and Vertex, a small software company that does tax calculations on online purchases. "They may do a good job of interfacing with each other, but they are always looking to expand into new markets and add new functionality. It's just the nature of the business," Prevo says.

Even if they're not in direct competition with one another, vendors would much prefer to have their best programmers working on new software rather than building integration links. The complexity and limited payback of integration work inevitably leads to problems and delays. And customers of the alliance can pay a heavy price for them.

Page Break

That's what allegedly happened to Tri Valley Growers, the farm co-op behind such well-known brands as Redpack tomatoes and Libby's fruits, which had $US8.8 billion in revenues in 1999. In 1996, the co-op's business and technology leaders wanted to buy a fully integrated ERP system to run the entire business, from the vine to the grocery shelves. Impressed by Lead CPG Salesman George Van Ness, Tri Valley's business leadership quickly bought in to Oracle's vision.

At a meeting with Tri Valley in late 1996, Van Ness "acknowledged that there were integration issues to be worked out, but he kept assuring our executives that the problems would be solved and that [Oracle] would support us, no matter what", says a CPG project participant at Tri Valley who did not want to be identified.

That assurance was enough for Tri Valley's business leaders, says the source. "There was some good personal chemistry between their management and ours." That led Tri Valley to purchase the full Oracle CPG suite for $US3.1 million in April 1997.

The evolving difficulty of the CPG integration at Tri Valley was reflected in Oracle's estimates for the consulting costs on the project. In November 1996, Oracle's estimate was $US300,000 to install the software. In May 1997, when the final consulting contract was signed, that figure had ballooned to $US2.7 million, according to court documents obtained by CIO from a lawsuit that is still in progress.

It wasn't long before the relationship between Oracle and Tri Valley began to sour. Tri Valley's technology project team complained repeatedly that the CPG software that Oracle's project leaders had said was finished was really not, and that the pieces Oracle did provide did not work when loaded into Tri Valley's computer systems. Tri Valley says Oracle kept promising to fix the problems with new releases of the CPG software but that Oracle continually missed its deadlines for completion of those releases. Tri Valley dropped its CPG project in 1998 and replaced it with Oracle arch-rival SAP's R/3 system at an additional cost of $US1.2 million, according to court documents.

But the last-minute switch couldn't save the co-op. Tri Valley declared Chapter 11 bankruptcy last year and has since sold off its brands. What little remains of Tri Valley - mostly lawyers and accountants - is suing Oracle for $20 million for its failed CPG installation. Though the company does not go so far as to blame CPG for the collapse of the company, its lawsuit claims that the co-op would have saved more than $5 million per year if the software had worked. An Oracle spokesperson said the company has denied Tri Valley's allegations in court, but said she could not comment while litigation is pending.

The lesson of Tri Valley's experience is clear to one IT manager who worked on the project. "The nontechnology executive management has to take the technical details seriously and not consider them something that the geeks will work out amongst themselves," he says. "Those technology difficulties are, in fact, serious business risks."

By 1999, even Larry Ellison, Oracle's CEO, was publicly acknowledging problems with CPG. But he blamed others for its woes. At a press conference following an Oracle users' group meeting in April 1999, Ellison said about CPG: "[It] sounded great, but the trouble is we can't control our [CPG] partners. We're going to be very careful going forward not to take responsibility for something someone else has to do. That was a huge mistake, and we will never do it again." At Oracle's user group meeting in Hawaii in October 2000, Ellison flatly told customers that they should turn their back on CPG and upgrade to Oracle's new software package, 11i.

By then, Shreiner had left Kellogg after more than three years of trying to make CPG work. To his credit, he never hid the fact that the software was incomplete, sources say. "[He] was consistent with the underlying tone that CPG needed to be worked out and that there were issues," says one former IT manager at Tri Valley. Referring to Shreiner's exit in early 2000, another source close to the project says: "There were people whose careers depended on getting CPG up and running." Shreiner was one of them. (Responding to our letter requesting an interview, Shreiner wrote: "I do not feel it would be appropriate to comment or contribute to this story.") His successor, Rajan Nagarajan, announced in May that Kellogg in the United States would begin the process of converting over to SAP's ERP software, which it acquired when Kellogg bought biscuit and snack-maker Keebler. The new system will eventually erase whatever traces of CPG remain at Kellogg worldwide, according to a source close to Kellogg. Nagarajan declined to be interviewed for this story.

George Ryerson, director of IT for WestFarm Foods, a Seattle-based dairy cooperative, managed to hang on to his job despite being a CPG customer. He had an advantage. He came to CPG relatively late in the game, beginning his implementation in February 1999. By then the myth of true CPG integration had been dispelled. WestFarm Foods bought interface connections between select pieces of software from the original CPG portfolio. Throughout the six-month installation, Ryerson minimised the changes he made to the three pieces of CPG software that WestFarm bought.

He also rode herd on the two CPG software vendors, Oracle and IMI, that installed software at WestFarm. He developed a "black book" on the two vendors and gave a copy of it to all users of the system. "It's a customer service guide based on the problem type, the vendor, the primary contacts at each vendor and how to [get the vendor's immediate attention] if the system is down," he says.

Because Ryerson made very few modifications to the CPG software, it was easier to get Oracle and its partners to accept responsibility for bugs. "That saved our bacon," he says. Even with minimal modifications to CPG, however, the installation was still a challenge, though Ryerson won't elaborate. "I'm not going to tell you how many [official CPG bugs] there were," he says. If other CPG installations are any indication, there were many.

Oracle stopped selling CPG in late 1999 and Klaiss says the software is being incorporated into Oracle's new suite. So Ryerson is now faced with a choice: either upgrade to 11i, as all CPG customers are being encouraged to do, or start from scratch with another ERP vendor.

Page Break

Not all multivendor alliances end in disaster, however. That's because they have started out with the understanding that all they will achieve is interface integration. They also understood from the get-go that vendors are like two cats in the living room: one has to willingly cede the higher spot on the furniture to the other if there is to be any peace between them.

David Root, CFO for Eagle's Flight, an Ontario-based management training company, thinks he has found the right combination of partners in Great Plains, a North Dakota-based maker of ERP software for small and midsize companies (recently acquired by Microsoft), and Siebel, the giant CRM software company that focuses primarily on the Fortune 500. In this multivendor relationship, Siebel is the alpha cat. It has stronger brand recognition and a much larger customer base than Great Plains. So Great Plains has been willing to take on the lion's share of the integration work and provide all the support for customers. "We accept what Siebel throws over the fence to us, but we do have a voice in deciding what they throw," says Holly Holt, senior product manager of front office with Great Plains.

More important, the integration between the two products is of the note-passing variety rather than the hard-core melding that Oracle aspired to with CPG. The note-passing mechanism makes upgrading the integration simpler and cheaper, and users can adjust the frequency of the note passing to get to near real-time. But the work of integrating the software has been nowhere near that fast. "Things do move more slowly than if we were dealing with each vendor individually," says Root. Now that Microsoft has purchased Great Plains, Root will be watching carefully to see if the pace slows any further.

Green Mountain's Prevo finds that he often has to herd his vendors into a room to get them moving. "We find that we have to get PeopleSoft and Vertex to talk together in front of us to get a solution that works," he says.

Yet despite all the potential problems with multivendor integration, Prevo and Root say they have little choice but to try to make it work. "We looked into the cost issue of integrating something ourselves versus buying preintegrated software, and there was no comparison," says Root. But changes to Great Plains software alone would have required his staff to rewrite the interfaces between Great Plains and Siebel every six months. "We just couldn't have afforded to do it," Root concludes.

Page Break

1. VISIT THE DEVELOPERS' OFFICE.

There is no better gauge of vendors' investment in their alliances than the number of developers they devote to the integration effort. Demand to visit the shared office where developers from both companies are working together on the integration. If such an office doesn't exist that means that neither company is serious enough about the alliance, and you should walk away.

2. GET THE VENDORS TOGETHER IN A ROOM AND OBSERVE HOW THEY WORK WITH EACH OTHER BEFORE SIGNING UP.

"You can tell when vendors are making their first sales call together, it's like watching doubles partners who have never played tennis together," says Bob Renner, CTO of ForestExpress, an Atlanta-based e-commerce exchange for the forest products industry. "We made [the partner vendors] demonstrate their products to us together as a team and observed how they worked together."

3. CUSTOMER REFERENCES FROM VENDORS HAVE LITTLE VALUE.

No two installations of big, complex enterprise software such as ERP are alike. Thus, no reference customer can tell you how a multivendor ERP package will work in your company. But if you want some guideposts, demand a list of all the vendors' past and present customers, not just the one or two they've picked to showcase.

4. TWO IS BAD ENOUGH; THREE IS IMPOSSIBLE.

It is difficult enough for two vendors to coordinate their software releases and integrate them. More than two and the task becomes impossible - so keep it simple.

5. GET ONE THROAT TO CHOKE.

Insist that one vendor be responsible for supporting the multivendor integration. If responsibility is shared among them, there will be finger-pointing when something goes wrong and fixes will take longer.

6. VENDORS MUST BE COMPLEMENTARY, NOT COMPETING.

Partner vendors should not covet each other's sales markets or software functionality. If they do, the alliance will fail - a victim of competition.

7. BE PREPARED TO WAIT.

Partner vendors will always attend to their core products first. Integration upgrades will inevitably lag behind upgrades of the individual software packages.

8. BECOME A MARKET WATCHER.

CIOs have to become financial and technology analysts and determine whether vendors' alliances will hold together.

9. DON'T ACCEPT "COMING SOON" INTEGRATION.

"A vendor's sales organisation is always ahead of its development group," says George Ryerson, director of IT for WestFarm Foods. "The salesmen would say Â'We can't show you because it's in the next release, but it'll be a knockout". We used to break out laughing when we heard that one."

10. IF THE VENDORS CAN'T DELIVER, ACCEPT FAILURE AND MOVE ON.

If the integration between two vendors' software isn't working right or isn't complete after a year of trying, stop the project. Prolonging the agony will cause real damage to your business.