InformationWeek
Defining The Business Value Of Technology
August 2, 1999
 Print this story |
continued...page 2 of 4
"If you don't do it quickly, then you find out the business the ERP package ends up [supporting] is different than the business the ERP package was meant to [support]," says Micros CIO Robert Moon. Though users had to wait for certain specific features, such as customized reporting, the project ended up on time and within budget, says Moon. And users had access to the applications' standard feature set while waiting for the customized versions. Micros is doing the same for its customer-relationship management package, also an Oracle application.
Another lesson Micros learned was that it's critical to map out business processes before implementing a system. Moon says ERP gave his company an opportunity to review its processes, to find better ways to do things. Simply having the application reflect existing practices, he says, "is like paving cow paths"--that is, making an existing route faster, instead of finding a better route.
For example, he says, the company needed to fix processes in purchasing, shipping, and, in particular, returned-material authorization, where damaged goods would sometimes get lost en route to the repair shop or on their way back to the customer. A new sales configurator implementation, Moon says, will reduce the amount of ordering and configuration mistakes but requires the company have its configuration settings precisely documented.
Mapping business processes is particularly important in the front office, where there's typically been little automation and processes are ill-defined. Southworth Products Corp., a Falmouth, Maine, manufacturer of material-handling equipment such as hydraulic lift tables, has spent much of the initial part of its implementation of Pivotal Inc.'s Relationship 99 package talking to salespeople to ensure they know where an incoming sales lead should be routed. It wasn't enough for the IT department to simply ask salespeople for requirements--it had to walk through the process with them. "They're terrific in telling us what they want to do, but not so good in getting the details down on paper," says IS manager Mark Hitchcox.
However, companies should avoid reviewing business processes without specific software functionality in mind, users and consultants advise. "If you start out with a blank piece of paper, you'll be documenting for a year without any tangible benefits," says Mark Sherman, VP of customer management solutions for services firm Cambridge Technology Partners Inc. In the early days of ERP, Cambridge helped companies reengineer before implementing the software. Now, Sherman says, he has clients compare the advantages of software packages, pick a package--and then build processes based on the capabilities of that software.
Plain Vanilla
Some businesses are taking that lesson to heart. Micros, for example, says in both ERP and CRM, any features that would have required customization were "thrown over the side." General Instrument, another Oracle customer, will take the same approach when it implements supply-chain and customer-relationship management apps over the next 18 to 24 months.
As a result, the company plans to keep its ERP implementations as simple as possible. However, the front office, with its focus on customers, is different than the process-oriented back end, Hash says."You need to be flexible," he adds, "because you're working with your customers and you can't afford to be limited by your application." For that reason, CCC plans to customize its Vantive front-office software, and examined the package closely to ensure that it could accommodate such customization.
Photo Hash by David Joel
The upside of limiting feature creep is faster implementation. When Micros Systems Inc., a Beltsville, Md., manufacturer of point-of-sale terminals for restaurants, started implementing its Oracle enterprise applications suite in October 1996, it had ambitious plans for the system. But as Micros neared the end of its self-imposed 12-month project time line, the company had to decide between extending the deadline or dropping features. It did the latter, preferring that to letting the project drag on.
Related links:
And from our sister publications:
Another area in which some past implementations went wrong, Sherman says, was in the decision to customize ERP packages. Customization was deemed necessary to bring an application in line with specific company processes, but Sherman says that was often a mistake. Customization adds time and cost to an implementation, as well as making it hard to upgrade an application once the developers have strayed from the vanilla version.
Still, not all IT departments say that what applies to ERP also applies to CRM. CCC Information Services, a Chicago vendor of auto insurance claims software and services, heavily customized its first implementation of Lawson Software's ERP package, which resulted in a painful upgrade. "We had to spend a lot of money to get out of that," says Ron Hash, CCC's director of IS.
continued...page 3, 4
return to page 1
Back to This Week's Issue
Featured Microsite
