Roll Your Own

Despite the proliferation of good off-the-shelf software, some shops still prefer to build it themselves. Here's why.

At a national sales meeting, the president of Reliant Pharmaceuticals Inc. rose to ask if there were any questions. "Throw anything at me," he said to the salespeople assembled. Someone immediately asked, "When are we getting automated?"

"Never," the president answered. "I want you out selling our products to physicians, not playing with computers."

Everyone in the room cheered.

"They didn't want sales force automation," explains Reliant's CIO, Ron Calderone, because they didn't want to have to carry a laptop or a PDA or some other handheld data-entry device that such systems typically require.

Nevertheless, Liberty Corner, N.J.-based Reliant needed a system to keep track of the activities of its growing sales force. Although there were many commercial packages available, user resistance led the company to develop its own sales force automation, or SFA, system, one that eliminated the data entry device in favor of simple telephone input to a speech-recognition front end. "Oddly enough, they didn't view that as SFA," Calderone says.

Accommodating the special needs of users is just one reason why companies continue to develop their own applications. IT shops are bucking the trend toward off-the-shelf applications and are opting to use custom-developed systems in the following situations:

  • A package falls short in one or two crucial respects and is bloated with unneeded features.
  • Companies can develop their own system more cheaply, especially when they have deep subject-matter expertise.
  • An application is of strategic importance, and the company wants to control every aspect of it.
  • The vendor is too slow or is unwilling to adapt its package to changing user needs.
  • The package doesn't integrate well with existing systems or with the company's IT infrastructure.
  • Support and maintenance costs are too high.

Simple and Easy

It wasn't user considerations alone that drove Reliant's roll-your-own strategy, Calderone says. He estimates that a commercial SFA package would have cost the company $4 million to $6 million for hardware, software, customization, help desk, telecommunications and training. "I have eliminated a number of these costs," he says. "For example, I have no need for a help desk because the system is so easy and simple -- it's really just people answering questions over the phone." He says his SFA system cost less than 15% of the amount he would have spent on a full commercial package, albeit with fewer features.

Cardinal Health Inc. in Dublin, Ohio, also developed its own SFA tools -- Web-based applications written in Visual Basic. Because the company had a long history of working with these kinds of tools, it knew exactly what it wanted and saw in-house development as low-risk and low-cost. In addition, says Rich Gius, CIO in Medical Products and Services, ongoing maintenance and support costs for a commercial product would have been far greater.

Explains Gius, "Our homegrown tool integrates directly with our common data warehouse, but a tool from the outside would have required a replication of our data warehouse into their own table[s], so the integration cost, the data management and cleansing costs would have been significant."

Gius says that the build-vs.-buy decision should be made on a case-by-case basis but that more complicated applications generally should be purchased. "In the case of a warehouse management system, we would prefer to build on the collective knowledge of vendors and benefit from their software that reflects the sum of all their other customers' needs," he says. "And I'd never build an ERP or an inventory control system or an order fulfillment system. There's enough competition in the marketplace now that I'd be comfortable we could get a reasonable price."

Subjective evaluation criteria should be supplemented with more rigorous financial analyses, says Gius. Cardinal evaluates projects based on a number of metrics, including return on investment and discounted cash flow . "It's evolved into more of an economic value-added model to take into account the weighted cost of capital," he adds.

It All Depends

IT executives generally say it makes little sense to develop your own commodity, or utility, system, such as payroll or general ledger. But one company's utility can be another's strategic asset. Choice Homes Inc., a $750 million house-builder in Arlington, Texas, chose to develop its own suite of accounting systems -- general ledger, accounts payable and accounts receivable -- even though many mature commercial choices are available. It was the only way to get the extremely flexible reporting necessary to satisfy the needs of autonomous, remote construction managers, says CIO Andrew Brimberry.

"I actually believe that our general ledger does give us a competitive advantage, because we can close our books at the end of the month in two days and at the end of the year in four days," Brimberry says. "So we know very quickly what money we are making and where we need to adapt."

It's even possible, he says, to look at profit and loss data in the middle of the month at various levels, all the way down to a single house under construction -- something he says commercial packages can't match.

Another bit of conventional wisdom that Brimberry rejects is the notion that by buying software, IT shops can leave the unpleasant support and maintenance chores to the vendor. He says he spends more time fixing his payroll and human resources systems -- the only applications he hasn't developed internally -- than any others. "Their standards of development aren't as high as [ours]," he explains.

Indeed, for some companies, the ongoing system costs and maintenance issues are more important than the initial procurement costs. Chris Hjelm, chief technology officer at Chicago-based online travel company Orbitz LLC, developed a contract management system in-house for the bargain-basement price of $50,000, and he says that supporting it requires just a quarter of one person's time. Because the system is simpler than comparable commercial packages, and because it's better integrated with other Orbitz systems, it's easier to maintain, he says.

And, Hjelm says, for a fast-changing online company like Orbitz, software vendors are just too slow. "Their timelines tend to be measured in six-month to one-year increments at best, but when we do software innovation for our commercial Web site, we do it in two-week increments."

Competitive Advantage

Reinsurance Group of America Inc. in Chesterfield, Mo., developed its own "enterprise administration system" that manages customer data, contracts and policies, calculates premiums and performs other back-office functions. Azam Mirza, vice president of global software, says he would have had to buy six to eight commercial packages to do all of those things.

But an even more important consideration, Mirza says, was that by rolling its own $35 million system, Reinsurance Group was able to include international functions such as currency conversions and multiple languages. "That's a huge competitive advantage for us," he says. "Everybody in the reinsurance industry is trying to build a global administration system, but they are two to five years behind us."

Mirza rejected the option of working with a software vendor to add global functions to an existing product. "We didn't want to end up with a commercial package that others could buy that we helped build," he says. "It would have been a custom system for us, and then a package for all of our competitors."

VisionQuest National Ltd., which provides intervention services for at-risk youth and has offices in Pennsylvania and Arizona, installed an ERP package but found that its billing module couldn't handle the complex contracts that VisionQuest had with its customers. So it hired consultants to help build a billing module compatible with the rest of the ERP package, says Greg Seyk, CIO and vice president for IT.

"They tried to force-fit us into the [package], using a variety of creative approaches, and we just couldn't get it to work," Seyk says. The consultants finally wrote the billing system from scratch, and contract programmers developed a custom child-tracking system as well. Both efforts proved difficult. "We went through two sets of consultants before our third set finally finished the child-tracking system," Seyk says.

Seyk offers this advice to those who decide to develop systems using contract developers: "Qualifying consultants is a huge, huge task. You can get references and do reasonable due diligence, but when the rubber meets the road, the consultants may not have the skills to do the custom programming."

An Ongoing Debate

The debate over buying off-the-shelf software or building your own is IT's version of "Tastes great!" "Less filling!" Read about both points of view at QuickLink 38533.

Copyright © 2004 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon