How to-and How Not to-Implement ERP

Here are a few important observations and recommendations from a Coopers & Lybrand consultant who has been spending a lot of time lately working with companies in their enterprise resource planning (ERP) implementations.

The implementation of an enterprise resource planning (ERP) system in a company is fraught with danger, both at the company level and at the personal level. That's the warning from Robert S. Putrus, manager of Business Systems Advisory Services at Coopers & Lybrand (Detroit). It is not that Putrus doesn't think that ERP systems are, consequently, to be avoided. But what he does strongly recommend is that firms take a careful, methodological approach to implementation. He points out, "ERP implementation is a high-risk program. It crosses different organizations within a company. And the investments are substantial in terms of buying the software and equipment, the training required, and the amount of time spent. The failure costs are much higher than the cost of the software alone." In fact, one of the costs of a failed program can be the loss of one's job. A stiff price to pay for what is ideally something that can help improve operations.

But while he counsels planning and care, he urges that implementations occur with urgency: "Rapid implementation is key." To go slow is to court failure.

Putrus has a great deal of familiarity with both information technology and manufacturing technology. He holds a bachelors in electrical engineering and three masters, in control systems engineering, computer engineering, and business administration. He is a licensed professional engineer in the state of Michigan; a certified management consultant, and a senior member of the Society of Manufacturing Engineers.

One of Putrus's early interests was with material flow through factories. In the early 1980s he was manager of Application Engineering at Volvo Automated Systems, involved in the implementation of automated guided vehicles (AGVs). Putrus recalls that back then, the practice at Volvo in Sweden used to determine how much room was required to move an AGV through a facility was to build a metal frame, put markers on its corners, and then pull it through a turn. The markers would show the amount of space the vehicle moved through. This, he notes, was rather time consuming, requiring about eight hours to create the plots on paper. He decided that there must be a better way to perform the task. So Putrus and some people at the University of Michigan set about to develop a computer-aided design (CAD) based modeling system that permitted the creation of the appropriate layout in about five minutes. "Today," he notes, "this can be done in less than a minute."

This simulation exercise led him to be interested in line balancing in order to determine the optimal throughput for materials and parts through a factory. While working on his MBA, and while working as a principal management consultant at Digital Equipment, Putrus's interest shifted into another direction. "People were talking about computer-integrated manufacturing," he recalls. "So I began to work on establishing a methodology for justification that would take into account the intangibles. It would look at technology from a business standpoint."

Putrus has been concentrating of late on ERP implementations. He says that during the last year-and-a-half he's talked with some 50 clients and has come up with some recommendations related to things to avoid when it comes to an ERP implementation. ("What type of company needs an ERP system?" you might be wondering. According to Putrus, a $30-million company is one that is sufficiently big to require what he calls "a professional system.")

So, when won't an implementation succeed?

1.When there is no executive sponsor. Putrus points out that ERP crosses functions within a company. Therefore, the program needs someone with the authority to bring various functional managers together. As he points out, people must devote time and resources to the project, and if they don't think that doing so is in their best interest, they will undoubtedly find something other than working on ERP to do.

2.When the project is viewed as being just of interest to Finance. Or Information Systems (IS). Or Manufacturing. Or...It is all, not one.

3.When there is no full-time project manager.

4.When, because of the hardware/software/communications intensity the IS people make the decisions. The problem here, Putrus points out, is that they may not have a good understanding of functional requirements.

5.If no one does due diligence on the vendor.

6.When there is no documentation of the implementation procedure.

7.When the effort is made to implement ERP of existing processes. Putrus suggests that reengineering of processes is essential.

8.If there is a massive change of
everything.

Putrus recommends an approach wherein there is an upfront analysis of such things as company competitiveness, the long-term business objectives, a detailing of the functional business processes, a listing of the business issues at an operational level, and a listing of the company initiatives. Fundamentally, what is created is an architecture of the businesses. Senior management, of course, is the group that defines what the business objectives are. Then it is a matter of having the functional managers become involved so that there can be a determination of how the objectives can be met and to look within the architecture and to make a determination (using a numeric scale) of what needs to be addressed, taking into account the fact that there are finite resources. (Note: Putrus delivered a paper at the Autofact `96 Conference titled "Business Re-engineering Through Collaborative Decision Making" that spells out his methodology for helping managers walk through an analysis and decision-making process whether it is for ERP or some other initiative.)

There is a basic four-step approach he recommends:

1.Define the requirements. This is project planning. Develop a list of the key features and functions. Develop business scenarios, from order to shipment and collection.

2.System evaluation and selection. Here it is making a request for information (RFI) to about four companies. Get at least two to do demos. Do reference checks. Select a vendor. (Putrus suggests that consultants are extremely helpful at this stage because they have had experience working with various ERP suppliers.)

3.Procure and pilot the system.

4.Go live/cutover to the ERP system.

Putrus says that a single-site ERP implementation program shouldn't take more than one year. If it takes longer, he explains, people are likely to burnout and/or quit. And if these are key individuals, then the company can be set back since more time is lost.

"This is a high-risk , high-visibility project," Putrus says. Done right, it can mean high rewards, as well.