Call it a cautionary tale. Earlier this year, footwear maker Nike faced serious inventory reduction and misplacement as it rolled out a highly customized retail supply chain system that included applications from i2 Technologies.
At the time, i2 said the difficulties stemmed from tying the customized applications to other enterprise resource planning (ERP) and back-end systems.
And this case isn't unique, say those who advise against tinkering with ERP applications. While customizing may give you industry-specific capabilities, it can be expensive and difficult, and the custom software may require special maintenance, say critics. It may also make the core application unstable and prone to glitches.
But there's another side to the debate. Some IT professionals view at least some customization as not just desirable, but also inevitable. They point out that when firms install pure, out-of-the box applications, they may have to part with code and functions that have been developed over years to suit particular business processes.
"Every ERP installation is customized," says Steve Abrams, senior vice president of corporate payment solutions at MasterCard International, which is running Oracle business applications. "No one installs out of the box."
The problem for some is deciding just when to risk tampering with the ERP code. "There really isn't a rule of thumb [about customizing]," says Karen Peterson, an analyst at Gartner. "However, I would recommend that customization is only to be used when competitive advantage capabilities are required and are not within the core product."
Peterson says companies are leaning more toward vanilla ERP upgrades. Writing custom code is costly and can make it difficult to upgrade to newer versions of the application, among other problems, she adds.
But sometimes customization is the only answer to a specific business problem. For instance, according to an SAP AG spokesman, a bank in a South American country with a high crime rate had an unusual request for an ERP customization.
While implementing SAP's supply chain application, the bank, which asked not to be named, decided it needed to be able to forecast the demand for cash on peak withdrawal days, such as Fridays before Christmas or other public holidays, while factoring in, among other variables, the chance that a branch might be robbed. The spokesman says SAP fine-tuned the software to optimize the bank's money transportation operations, factoring in the possibility of theft. The transportation system became more efficient, and resulted in a 20 percent reduction of costs and a full return on investment in four months.
The Dark Side
The trouble, of course, is that botched customization jobs can lead to disaster as in Nike's case. The wide range of footwear products Nike sells also led to further difficulties in mapping the supply chain software to internal business processes. Nike Chairman and CEO Philip Knight, facing a drop in stock price and revenue, told shareholders, "I guess my immediate reaction is, 'This is what we get for $400 million?' "However, an i2 spokesperson said recently that the problems the companies had getting the technology to work were "in the past." She didn't detail how they arrived at a solution.
Such crises discourage users from venturing out onto the thin ice of customization. "It's a risky strategy," says Walter Taylor, ERP program director at Atlanta-based Delta Air Lines Inc.
Taylor is overseeing an SAP R/3 implementation for Delta. He says he opposes customizing because SAP already has solid applications with best practices built in. When you start tinkering with the code, you make the application unstable and start losing benefits, Taylor says. "It's better to re-engineer your business processes than rewrite code," he says.
Although there are some horror stories, Taylor says SAP implementations aren't that difficult if you go vanilla. Things get rough when you start trying to integrate SAP into legacy systems or trying to bolt on third-party applications. And if you're going to start to customize, you might as well start assembling complex best-of-breed packages as well, he says.
"I think most companies don't make these decisions very well," says Scott Stephens, chief technology officer at the Supply Chain Council Inc., a Pittsburgh-based industry consortium. "The folks with big [in-house] software groups tend to do it and then get stuck with software they have to maintain."
On the other hand, companies with clout can get the vendor to actually write their customization into the next software upgrade.
"Sophisticated companies look for software that can be tailored at the script level vs. changing the application kernel," Stephens says.
Some users may mix and match applications. Peabody, Mass.-based medical systems and components maker Analogic Corp. two years ago implemented a human resources application from Pleasanton, Calif.-based PeopleSoft Inc., but did things like adding extra fields into its supply chain and engineering-related ERP screens, says Analogic CIO Thor Wallace. He says that as long as you stick to the PeopleSoft parameters, the customizations will work even when you do an upgrade. He says companies should only customize applications gradually.
"These ERP systems are so big, you've got to take bite-sized pieces and bring up the system largely vanilla and then customize the areas," he says.
Toronto-based Bank of Montreal uses both homegrown and customized applications as well as ones right out of the box, according to Steven Pare, e-procurement team leader. Last October, the bank started rolling out Oracle's e-business applications to handle Web-based expense reporting and procurement, replacing an existing mainframe based legacy system.
To make the most of the savings of this automation, Pare avoided tampering with the applications except within the configuration framework provided by Oracle, which permits changes in workflow processes. For instance, he can configure the application to match invoices to receipts or purchase orders. The ERP applications he's rolling out aren't mission-critical, and it's better to rely on Oracle's code-writing and installation expertise to get the job done, Pare says.
"From our point of view, we're e-procurement people, not programmers," he says. "Oracle has an army of programmers, let them develop it."