Implementing an enterprise resource planning system is the Everest of the IT profession. Too many firms go through hell scaling the ERP heights. If only they had the Sherpa-like benefits of hindsight.
The four companies profiled here have that hindsight now, and they can help you reap the benefits. If you listen carefully to ERP war stories such as those that follow, you hear some of the same advice repeated over and over: never underestimate resources required, make business operations own the system, don’t start until you have top management commitment. Yet these stories also provide evidence that every ERP project is different, and it’s a rare company that doesn’t learn some hard lessons along the way. Be forewarned.
SMED INTERNATIONAL: MEETING THE DEADLINE
Calgary-based SMED International custom builds modular office furniture and wall systems. It posts sales of $200 million-plus a year and employs 1,700 people.
Eighteen months ago, SMED decided to replace an “unsophisticated” home-grown legacy system with ERP modules from the Netherlands-based Baan Company. It hoped to improve customer service by tracking the status of orders better, and increase profits by more closely tracking costs and thereby optimizing prices.
Having clear objectives going into an ERP implementation is critical, says SMED president and project champion Andrew Moor. “ERP is often sold as a panacea. It rarely is. You’ve got to know what problems you’re trying to solve and tailor the implementation to that – and not try to fix 20 disparate problems at once. We did a good job of focusing.”
SMED began implementing major distribution, manufacturing and finance modules in March 1998. It turned the system on in one part of the firm (representing about 30% of revenues) in January of this year – on time. It will roll Baan out to the rest of the company over the rest of this year.
It’s too early to gauge the success of Phase One, says ERP project manager Doug Hunt. “You wouldn’t expect to see benefits for at least six months because of the learning curve involved and the need to tweak the system,” he says. “But my intuition is that it’s doing what we wanted it to do. It’s forcing discipline and repeatability in our business processes.”
The implementation went “fairly smoothly.” One factor was the company’s determination to minimize customization. All modifications had to be cleared by a high-level steering committee chaired by Moor. “It’s very important that you put those controls in place,” he says. “There are a lot of things that people [in operational groups] would like to have. A lot of places you just have to compromise.”
Hunt and Moor both attribute the success of the implementation in part to the company’s project partner Arthur Andersen & Co. On the other hand, the project was subject to cost overruns, partly, Hunt suggests, because SMED relied too heavily on Arthur Andersen consultants to get the project completed on time.
Moor believes this was a worthwhile trade-off. Finishing on time, even if it means spending a little more on consulting help, is paradoxically the best way to control overall project costs, he says.
“Every week a project runs overtime will cost you,” he says. “The most critical thing is to finish on time. And to do that, you have to have a strong management structure in place.” Arthur Andersen helped provide that. It also takes discipline and determination, Moor adds. “It’s too easy to see that you’ve fallen behind and not be concerned. But you’ve got to be concerned. You’ve always got to bring the project back to the original time line.”
Still, Hunt says the company has learned from the first phase and will reduce its reliance on consultants in future. Consultants are ultimately more expensive than well-trained in-house staff, he says, because they have to learn the business before they can be optimally effective – and then they leave.
The over-reliance on consultants in the first phase stemmed in part from a failure to provide adequate technical and project management training for the core project team of users from operational groups and IT department technical experts. The result was they couldn’t carry the ball in some critical areas.
Hunt will also be more careful in future about selecting core team members. Operational managers tended to nominate people who were available rather than those with requisite skills. One missing ingredient in the mix was decision-making skills – and authority. This slowed the process of getting sign-off from operational units.
For the next phases of the project, Hunt will also integrate the programming staff working on modifications more tightly into the core project group to get the benefit of their technical expertise.
SMED has been plagued by some user resistance. Integration of front-end and back-end processes means sales people can no longer count on engineers in manufacturing to fill in the blanks in specifications for custom orders, for example. And if an order isn’t entered completely, the system kicks it out. This is frustrating for users.
Part of the problem, Hunt says, is that too many end users skipped training on the system, believing they could learn easily enough on the fly once the system was installed. It’s too late now to go back and lay on additional training. User acceptance problems have been minimized, though, by Moor’s contribution as project champion. It’s a critical role, Hunt says. “He has been energetically selling the project in the rest of the organization. When people see his commitment, it’s that much easier to get theirs.”
HONDA CANADA: CLEAR MONITORING PROCESS
Honda Canada Inc. is the $5-billion-a-year Canadian subsidiary of the Japanese auto giant. It employs 3,200 people. The company manufactures Civics and Odyssey minivans at its two plants in Alliston, Ont., north of Toronto.
Two years ago, Honda decided to implement the ERP finance, payroll and HR modules from PeopleSoft Inc. of Pleasanton, Calif. Honda’s legacy HR and finance systems were ten years old at the time and not Y2K-compliant. Also, its U.S. sister company was implementing PeopleSoft and the corporation wanted to bring some consistency to its North American operations.
At the same time, Honda Canada was looking to automate and integrate processes, such as budgeting, that had previously been handled by stand-alone PC systems, and to generally streamline processes in its finance departments.
The company selected KPMG Canada as its implementation partner. Project champion David Sudbury, Honda’s vice president of finance and administration, says KPMG’s contribution was critical to the overall success of the project, which was completed on time and, nominally, on budget.
“They really helped, especially in developing the project management structure in the early stages,” Sudbury says. “We couldn’t have done it without them.”
That project management structure was another key success factor, he believes. Honda set up a separate project management organization, with representatives from both its manufacturing and sales divisions, but with one common project manager. A steering committee of senior managers met monthly.
“The steering committee focused in on problem resolution through all phases. And with monthly reporting to senior management, there was a very clear monitoring process in place,” Sudbury says. “That helped us a great deal.”
Another reason the implementation was a success was that Honda, like SMED, kept the lid on customizations. This is in keeping with the company’s philosophy of “continuous improvement,” Sudbury says. Its basic strategy is to start small and build from a solid base – get the ERP system up and running first, for example, and then work on refining it to milk the benefits.
Honda also learned through the benchmarking it carried out with vendors and with its U.S. sister that firms that made a lot of modifications often ran into difficulties when they later upgraded the ERP software. Many found they had to redo modifications because the new version wasn’t sufficiently backward compatible.
This was something Honda wanted to avoid at all costs, especially since it was already looking ahead to upgrading to the next full version of the PeopleSoft program, Version 8, which will be a major overhaul. Honda hopes the new version will enable radical streamlining of its financial processes through the introduction of e-commerce solutions.
Honda’s ERP implementation was by no means letter-perfect – no ERP implementation ever is. The major glitch was underestimating the infrastructure requirements of the PeopleSoft system.
Despite analysis by both PeopleSoft and IBM showing Honda’s current database and processing hardware were adequate, in the end the company had to beef up mainframe computing and database capacity, and insert a third tier of network servers to get the response times and system stability required.
“You really have to challenge your hardware and software vendors at the beginning to make absolutely sure you have a clear picture of what the infrastructure requirements are,” Sudbury cautions.
It’s also important when drawing conclusions about project requirements from the experiences of other companies to make sure you’re comparing “apples to apples,” he adds.
Sudbury won’t say how much the infrastructure upgrades cost, but it was “significant.” Those cost overruns were not factored into the overall project budget, the only reason it retained its on-budget status.
The other major problem, a common one, was underestimating the amount of training required to get users up to speed. “We found we had to constantly reinforce the training allocation, and ended up making a bigger investment in training than expected [by about 50%], just to make sure people could use the system to its full potential.”
Sudbury’s advice to companies about to embark on an ERP implementation: never underestimate the level of complexity or the level of resources required to complete the project. Do the return on investment analysis carefully to ensure benefits justify eventual costs. “And train, train, train.”
UNIVERSITY OF TORONTO: THE NEED FOR USER BUY-IN
Five years ago, with Y2K looming ominously on the horizon, the University of Toronto realized it would have to bite the bullet and replace its 20-year-old home-grown administration and finance systems. The old systems were unintegrated, slow, clumsy and expensive to maintain – and definitely not Y2K compliant.
The university turned to Germany-based SAP, and began implementing that firm’s major financial and administrative modules four years ago. Today, it is still adding ancillary modules, most recently a payroll system.
Has enterprise resource planning lived up to the university’s expectations? “If you’d asked two years ago, the answer from most people involved would probably have been no,” admits Jack Gorrie, the Provost’s Advisor on Information Technology, the closest thing the university has to a CIO. “But if you ask them today, they’d say yes. They’ve come to see the benefits of the system. Now it’s seen in hindsight as the right move – but it was a protracted process of getting people to buy into it.”
The course of the implementation did not always run smoothly, Gorrie concedes, and the school’s IT brains trust did indeed learn some hard lessons. The overriding need to secure user buy-in was probably the most important.
The implementation team, made up of SAP, IBM and permanent university employees supported by outside ERP experts, did consult with end users, but Gorrie admits the team “perhaps didn’t spend enough effort on [securing buy-in].” There was as a result some user backlash against the system initially.
Lesson learned: “You need to get users into the loop early on so they feel they’re part of the team rather than poor pawns being forced to use the new system,” Gorrie says.
The backlash problems, though, were part of a domino effect. The root problem was nderestimating the size, complexity and cost of the ERP project. “One lesson learned is that it always takes longer than you expect,” he warns.
As costs associated with just getting the system up and running mounted, there was less funding available for user training. And adequate, timely training is another key factor in securing user buy-in, Gorrie says.
“The new system required quite a shift in the way people operated. It was a steep learning curve for administrative people who had to deal with it.”
Another mistake in retrospect was to do the training sequentially, in small groups one after the other, starting relatively early in the implementation process. By the time the system was actually up and running, the first users trained had forgotten what they learned. This was exacerbated by the fact that it took longer than expected to get the system up and running.
As always, cost and time overruns were intimately related. Time, after all, is money. Costs were higher than expected partly because the project required more outside help than anticipated. The initial strategy was to hire full-time IT staff up to the level that would be needed for the long haul, and then use expert consultants as needed. It was easier to get funding for supposedly short-term consulting help.
“Unfortunately,” says Gorrie, “hiring consultants didn’t turn out to be a one-year scenario, it turned out to be three years. Perhaps we would have been wiser to hire outside people on long-term contracts.”
The university also had difficulty hanging on to full-time IT staff once they were fully trained on SAP.
“This is going to be an ongoing problem for any shop that gets into this game,” Gorrie says. “In the process of upgrading your staff, you’re making them more attractive to other shops. It’s not a reason for not going into it, but it’s something you have to keep on top of.”
The university is now implementing programs designed to reduce staff turnover. And it learned from other problems it encountered with the SAP implementation as well. The more recent implementation of a non-SAP student-records system avoided most of the user backlash problems.
HIGH LINER FOODS: SENIOR MANAGEMENT INVOLVEMENT
After Atlantic fish stocks disappeared almost overnight in the early 1990s, frozen seafood maker High Liner Foods of Lunenburg, N.S. saw its annual revenues plummet from over $700 million to barely $200 million.
In order to survive, the company went through an intense period of re-engineering. At the end of the process, High Liner realized it didn’t have the systems it needed to streamline processes and reduce head count. It ended up selecting an ERP system from Denver-based J.D. Edwards to replace a mix of unintegrated homegrown and off-the-shelf packages.
“We had to do it,” High Liner IS director Dick Joyce says of the decision to implement the ERP system. “We had no other real options.” High Liner made the buying decision in late 1993, began implementing in 1994, and has now installed finance, sales order processing, logistics, distribution, manufacturing and, most recently, warehousing modules.
The system is delivering exactly what the company wanted, Joyce says, and the project has come in for the most part on time and on budget. He attributes that success to two main factors: J.D. Edwards’ “conference room pilot” methodology, and high-level management support for the project within High Liner. That support is actually a requirement of the conference room pilot approach.
In the J.D. Edwards methodology, senior managers from operational departments get involved in defining company processes and adapting them to the practices incorporated in the ERP system. Later they’re involved in testing the system with real data – the conference room pilot – and ultimately, training users.
“When the VP of finance is leading the training, boy, it’s effective,” Joyce says. “It makes it awfully hard for an accountant not to play along.”
Senior management support went right to the top of the organization at High Liner. “When I talked to associates in other companies, they were always rather envious of me when I told them my president could show you how the system works,” Joyce says.
Another factor in High Liner’s success was the decision to make virtually no changes to the J.D. Edwards system. It was a decision supported, again, at the highest levels in the company, Joyce says. And that support was crucial.
The decision to limit modifications came out of bitter past experience, though. “We had bought a [non-ERP] package in our U.S. company and customized it to death,” Joyce says. “It was broken as well. We knew we weren’t going to go that route again.”
High Liner did have to learn as it went. One of the early lessons was how to plan for training to ensure everybody got enough. High Liner, like others, initially underestimated the requirement.
“The most effective dollar you spend on the project is for training,” Joyce says. “You want to get the end user to own the system, and that’s [through training] how you get them to do it. You sure don’t want IT to own the system.”
High Liner also faced some unique challenges – undertaking a major capital project at a time when profits weren’t high was one. Another was adapting business processes and the J.D. Edwards system to the fact that the company could never really predict when its supplies of raw materials would arrive because of the collapse of the Atlantic fishery.
Joyce’s advice to IS executives starting out on an ERP implementation – don’t own the system. Make sure operational groups own it. Otherwise it’s inevitable you’ll go over budget and end up fighting with users about changes.
“If I don’t sell a pound of fish, why would I own a sales order processing system?” Joyce asks.
Tony Martell is a freelance writer specializing in technology and IT management. He is based in London, Ont.
