Make Mine Vanilla, Part 2

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More .

Going “vanilla” with your ERP software isn’t a one-scoop deal. Besides getting their initial installs up and running faster, companies are finding that new software upgrades with greater functionality are allowing them to replace some custom code with off-the-shelf software that their ERP vendor, not their in-house IT staff, will support.

As commercial ERP packages become more complete, more and more companies are looking carefully at the upgrades they receive to see if what comes on the CD-ROM can replace some of their custom code. That’s what Pacific Coast Feather, a $300 million retailer of bed linens, comforters and pillows, is doing this spring, as it upgrades its SAP R/3 ERP system to the latest version.

Lessons Learned

1) Minimize changes to new implementations by requiring users to get approval from up the chain of command to modify the system.

2) Modularize your custom code, so it can be separated from the vendor’s code while doing upgrades.

3) Use upgrades as an opportunity to re-examine customizations to see if they can be replaced by new functionality from your software vendor.

When it first installed R/3 in 1995, the Seattle-based firm had vowed not to modify the system. It quickly realized that was unrealistic, says Gwen Babcock, Pacific Coast Feather’s CIO. “Sometimes,” she says, “business reality requires you to make exceptions.”

Pacific Coast Feather had no choice but to write its own code, says Babcock, because some of the functionality it needed simply didn’t exist in R/3 in 1995. “We had much greater EDI requirements then R/3 provided at the time,” she recalls. R/3 version 4.6, however, which Pacific Coast Feather is installing now, includes EDI capabilities, and so the company is replacing its custom code with standard R/3 code.

That’s a wise move, says Mike Mansfield, a partner and Oracle practice managing director at systems integrator Computer Sciences Corporation (CSC), of El Segundo, Calif. “When we go through an upgrade with a client,” he says, “we always try to do an education session with them on the new functionality, and encourage them to reassess any older modifications to determine if they are now redundant.”

Less customization could mean less work for companies like CSC. But in the short term, at least, the consultants don’t seem to be too worried. There’s plenty of work doing upgrades, and even companies doing relatively straightforward installations rarely choose to go it alone. Waste Management, for example, hired Miami, Flor.-based consulting firm AnswerThink to help install its new PeopleSoft system.

Babcock believes using standard R/3 code as much as possible lets Pacific Coast Feather take advantage of the knowledge about business processes that it built into SAP’s software. “R/3 is designed around best business practices,” Babcock explains, “and if they do it a certain way, there’s got to be a reason. So if the upgrade takes a different approach, we look at it and ask ourselves, ‘should we change the way we do things?'”

Replacing Pacific Coast Feather’s code with standard R/3 functionality should also improve the system’s reliability, Babcock says. “When we have performance problems or data integrity issues,” she says, “it’s invariably our custom stuff, because otherwise the system is rock solid.”

Driving customization to zero

Babcock also expects that removing custom code will make the next upgrade easier. Pacific Coast Feather has upgraded R/3 twice since installing it in 1995, and while SAP’s upgrade process is designed to deal with customization, the process is still time consuming. Pacific Coast Feather has been careful to separate out all its custom code–each file is marked with the prefix ZD or ZE–so that Babcock’s team can pull off its custom code, do a standard upgrade, and then reapply the customizations. The upgrade tools supplied by SAP can identify conflicts between user customizations and the new version of R/3. Those sections of code have to be re written, and then tested, first by the programmers to make sure they compile cleanly and execute, and then by business analysts to make sure they function the same way the older version did. As a result, Babcock estimates that dealing with customizations can take up to one-third of the total time involved in an upgrade.

Even with all the work involved, Pacific Coast Feather may be ahead of other companies in simply being able to do an upgrade. “I’ve seen plenty of users who have done so much customization that they can’t do an upgrade at all,” says Enterprise Applications Group’s Greenbaum. “They end up having to do a full-blown implementation.”

So it’s no surprise that Babcock is not the only CIO who hopes to reduce customization. “Wherever possible, our ERP clients want to go vanilla,” says Mansfield. He estimates that three-quarters of CSC’s clients with extensive customization plan to use upgrades to remove a significant portion of the custom code. They don’t expect it to happen overnight, he says, “but their long-term plan is to drive customization to zero.”

But Mansfield finds that not everyone can–or wants to–avoid customization. “There will always be a few people out there who are convinced they need to modify things to make it fit their environment,” he says.//

Dan Orzech is a Philadelphia-based writer specializing in technology. His work has appeared in the Los Angeles Times, the Philadelphia Inquirer, and many computer industry publications. He can be reached at orzech@well.com.