Do you buy? Or do you build and adjust?
It is an elder among IT debates. It is our own "Tastes great!" "Less filling!"
When you need a new enterprise software tool, what's wiser: buying a packaged application from a major vendor and customizing as needed? Or developing it yourself from scratch? Interviews with IT leaders show this conundrum is no closer to resolution today than it was a quarter-century ago. But that doesn't mean that things haven't changed.
Build advocates need only wave a fistful of Computerworld articles dating back to the mid-1990s, when enterprises discovered the joy of ERP. It is hardly a secret that many ERP, CRM and supply chain management implementations have blown up—wasting millions, causing corporate turmoil for years and, in a few cases, being named as factors in bankruptcies. Moreover, CIOs and business executives alike have grumbled in recent years that even when such projects "succeed" (that is, when they don't fail utterly), return on the investment comes slowly—if at all.
On the other hand, there's clearly a limit on how large an application IT can create. "You don't see enterprises trying to re-create SAP," jokes Jennifer Chew, an analyst at Forrester Research Inc. in Cambridge, Mass. Many of the applications CIOs point to as triumphs of the build philosophy are relatively modest—making data easier for users to access via a browser, perhaps, or allowing previously isolated software tools to communicate with one another.
So what'll it be, buy or build? Some of today's arguments may surprise you.
Buying and Crying
Rich Bursek, CIO and senior vice president at Lydian Trust Co., recently made the decision to buy a packaged application, and the process reinforced his philosophy to build his own software whenever possible.
Lydian, a Palm Beach Gardens, Fla.-based parent company to several financial-services businesses, needed Web-based mortgage-origination software that the lenders use to receive and process loan requests. Many vendors offer mature applications that fill this vertical need. "It would have taken us a year to build it" at a cost of about $1 million, Bursek says. The price of the packaged application selected by Lydian (Bursek declined to name the vendor because the contract has yet to be locked in) is about $250,000, he says, and another $250,000 in resources—in-house developers' time and consulting—is needed to get the application running.
The capper is that Lydian hopes to put the packaged application in production in six months. "So that's a half-million-dollar savings, plus we're six months closer [to a functioning application]," Bursek says. "When I took those two factors to the board, it was pretty persuasive."
While the 50% savings made this a clear-cut buy decision, Bursek discusses the experience with enthusiasm usually reserved for a pulled groin. Lydian's senior management team has a strong IT background and prefers to build applications whenever possible—and despite the overwhelming cost advantage of purchasing packaged mortgage-origination software, this experience is doing little to change their minds about the non-finance-related advantages of the build approach. (Bursek believes the unpleasantness isn't his specific vendor's fault, but rather the nature of the buy beast.)
In January, after running the numbers, Bursek knew he would purchase a packaged application and began vendor meetings. "That took us a month, which everyone told us was very aggressive, and another [month] to negotiate and sign the contract," he says. (As noted above, there are still T's to be crossed, I's to be dotted.) The software was installed in March and was scheduled to go live May 1.
"We have five people dedicated to managing this project," Bursek groans. "Five dedicated resources doing nothing else." Three are business analysts who act as conduits between Lydian's business units and IT, and two are developers writing code to make sure the company's existing applications work with the new mortgage-origination software. "When you're working with vendors there's this ongoing battle," Bursek says. "Things snowball; you can lose control." He contrasts this experience with a recent build project—an extranet sales tool for third-party brokers and account executives who do business with Lydian.
The company needed to give those professionals real-time, browser-based access to mortgage approval status. Bursek simply grabbed a few developers from his six-member team and went at it. "I met with an analyst and a systems architect" to sketch out the basics, he says. "Then we made a presentation to two people in operations and started development the same week. From problem analysis to going live took three weeks."
Bursek shakes his head. "With vendors, it's just a grueling process." In particular, he chafed at the vendor selection process, the contract negotiations and the need to rely on outside developers. But in the case of the mortgage-origination software, the massive price differential trumped all other arguments and made the buy decision unavoidable.
Customize With Caution
 |
 |
| Rich Bursek, senior vice president and CIO, Lydian Trust Co. | |
One of the popular build arguments is that there's really no such thing as a major packaged application—vendors' suites must be customized so heavily that getting your allegedly off-the-shelf application running requires a massive amount of developer time and a shotgun wedding with an integrator. But some IT leaders turn this argument inside out. According to David Schwartz, CIO at George Washington University in Washington, the big problem with ERP implementations is that companies overcustomize software. "A lot of these modifications are simply preferences," he says. "People change the way a screen looks or what appears on a report."
"If you buy packages, you want to keep customization to an absolute minimum," agrees Chuck Mackey, IT director at the Elkay Division of privately held Elkay Manufacturing Co. in Oak Brook, Ill.
The diversified manufacturer of plumbing products and cabinets built its own software until 1997, when it put in place a PeopleSoft Inc. ERP suite. And despite a lousy experience with a systems integrator (Mackey declines to name the firm but says, "They did a very poor job for us"), he has no regrets. Elkay's annual PeopleSoft maintenance fee is equivalent to two or three developers' salaries, Mackey estimates. And for that fee, he says, "today we're totally Web-enabled. There's sure no way we would have gotten here with two or three more developers."
In 2000, when George Washington embarked on an implementation of an Oracle Corp. ERP suite, Schwartz minimized customization and instead updated the university's business processes to match best practices recommended by Oracle. "That's tough. You go through a chain of pain when you're re-engineering and changing corporate culture," he says. "But now our systems reflect recognized best practices."
|
 |
|
Rick Peltz, CIO, Marcus & Millichap |
Working with systems integrator BearingPoint Inc. (formerly KPMG Consulting Inc.), the university implemented the ERP suite in two years at a total cost of $25 million, Schwartz says. Between George Washington developers, BearingPoint consultants and line-of-business representatives, the implementation team numbered 50 to 60. Schwartz claims there are Ivy League colleges (which he declines to name) "that paid two or three times" $25 million because they went wild on customization.
Build If You Must
"The last thing we wanted to do was build this app ourselves," says Rick Peltz, CIO at Marcus & Millichap. Late last year, the Encino, Calif.-based real estate investment brokerage company shopped around for off-the-shelf tools that would let its sales agents pull data from many sources (photos, published articles, government information and others), use it to generate marketing packages for individual properties and send that information back to the company's SQL Server database. Peltz assumed that he would use Microsoft Corp.'s PowerPoint, a tool the agents were familiar with, as a front end. Surely it would be simple to find a package that could send the data back to headquarters.
But even with his two consultants "on the phone all the time with Microsoft" trying to pull something together, Peltz found that PowerPoint's architecture made it impractical to set up a way to prevent users from deleting information they had created. This feature was a must-have; turnover among real estate agents is high, and many are technology neophytes, so Peltz was concerned that users would accidentally delete marketing packages they had just created.
As a result, Marcus & Millichap was forced to spend its budget ($250,000 to $500,000) "to re-create PowerPoint from a [user interface] perspective, but without all the functionality," Peltz says—and with the ability to build "whiteboard" fields that users can't delete. While the company would have preferred to buy a packaged application, Peltz did find some advantages in building his own. Four months after work began, the tool was already being beta-tested because Marcus & Millichap set its own aggressive timetable. And the consultants who were initially earmarked for integrating packaged software have instead been writing code and auditing one another's work.
About the only thing that's certain in enterprise software today is that even passionate build advocates aren't about to create true ERP or CRM suites from scratch. But at the sharp end of business, where money is made or lost, perhaps no vendor can truly meet your company's needs—perhaps you're on your own. AMR Research Inc. analyst Eric Austvold believes a new mind-set is required: "In the past, people thought of packaged apps as the endgame," he says. "But we need to start thinking of them instead as the foundation—the system of record."
Ulfelder is a freelance writer in Southboro, Mass. Contact him at sulfelder@charter.net.