Abstract: Enterprise resource planning software, such as the packaged solutions from SAP, Oracle, Baan, and People Soft, can offer not only greater efficiencies but also the opportunity for inter-departmental teamwork and communication. In order to integrate diverse departmental functions into a single information system, department management must work together. For instance, product numbers must be the same to allow manufacturing, accounting, customer service, and finance departments to each add their specific information to an inventory system. Effective change management is crucial to attaining the benefits of enterprise resource planning. Employee training for new tasks and responsibilities should not be neglected. It is important to evaluate new technology for its enterprise utility, and not simply use any available features regardless of their actual impact on productivity.
Full Text: COPYRIGHT 1997 Cahners Publishing Associates LP Enterprise Resource Planning software promises benefits that range from increased efficiency to transformations of quality, productivity, and profitability. But the unintended consequences can derail you. OCTOBER 6, 1995, WAS AN UNFORGETABLE DAY FOR CABLE SYSTEMS INTERNATIONAL, a $400 million manufacturer based in Phoenix. First, it officially opened for business after being spun off from AT&T. Second, the manufacturer of copper cable for AT&T and other long-distance companies went live with Enterprise Resource Planning (ERP) software from SAP. Nine-hundred of its 1,800 employees were new; the rest were AT&T veterans accustomed to doing business the AT&T way.
SAP's integrated system presented some unexpected organizational challenges, say's Tony Piccirillo, vice president of operations. "Typically, people like to work in universes they're comfortable with," Piccirillo says. "We tend to work in functional silos. Even though it's painful in terms of culture change, [if you use SAP] you can't work in functional silos." For example, if accounting configured the general ledger without checking with customer service, "We might not have captured the right product line in the right [accounting] bucket," Piccirillo says. When his staff did a "string test" of the SAP modules, checking how information flowed from one module to another, they found all kinds of glitches. The bottom line: The data didn't cross-check.
To solve the problem, the company created informal cross-lateral teams, partnering financial, IT, customer service, and production-control employees who shared information in an effort to harmonize the data. "We didn't do that intentionally going into [the implementation]. It didn't occur to us," Piccirillo says. "We migrated to it over time." Piccirillo, who's happy with R/3, the SAP product, says the problems eventually solved themselves through teaming. Because it"forced people to go out of their way and check with other organizations to make sure they weren't going to mess something up," SAP turned out to have an extra benefit. "It strengthened our company overall," he says. "Employees know more about the whole enterprise vs. being part of a niche." Using packaged Enterprise Resource Planning software from companies like SAP, Baan, Oracle, and PeopleSoft, and a raft of smaller companies like Cincom Systems and SSA, managers hope to extract more information from integrated systems and thereby achieve greater efficiency and profitability. There's no doubt that such business benefits are achievable. But perhaps the most important skills needed for an ERP implementation are team-building and communication skills--so-called "soft" skills that many information systems managers don't think about. Why are these soft skills so important? Because integration of unlike departments causes all sorts of problems, in addition to creating benefits. SAP requires that managers harmonize part numbers, for instance, so that customer service, manufacturing, accounting, and finance use the same terms for the same inventory. If a company's departments operate by their own rules, the system won't function properly.
In the darkness of the second shift, Kay Kirk loads and unloads close to $40,000 worth of parts that will be used to make axles for heavy trucks. Kirk had tracked these truckloads of materials in the same low-tech way for more than a decade: by marking them off the packing list with a yellow highlighter. Once a day, another employee stopped by Kirk's loading dock and picked up a bushel of receipts, to be manually entered into the legacy system later. But a few months ago, Kirk was trained on an Oracle materials receiving system, part of a new ERP system her company, $7.6 billion Fort Wayne, Ind., Dana Corp., installed in its Spicer Heavy Axle and Brake Division to make order out of a hodgepodge of home-grown, antiquated manufacturing resource planning (MRP) systems. Kirk and her fellow employees on the shipping docks were apprehensive when they were told they would have to learn to use the computer to do their jobs. But Kirk went through with it, and today she enters receipts into a networked PC, the first step in an on-line, integrated process that computes inventory in real time.
Kirk's shift in tasks was just one small example of the changes the company has experienced since it transformed its eclectic blend of systems to Oracle's ERP modules. The plant accomplished its metamorphosis in only 24 hours. "It was a nuclear event; it happened overnight," says project manager Mike Dale. "The mushroom cloud went off, and everything is different." The plant is a more efficient place now. Orders are taken electronically, the line is scheduled electronically, and parts are shipped electronically. But it didn't happen without causing fear on the part of veteran employees.
ERP implementations usually require people to create new work relationships, share information that once was closely guarded, and make business decisions they never were required to make. These kinds of changes are marked by resistance, confusion, redundancies, and errors-unless managed properly.
About half of ERP implementations fail to achieve hoped-for benefits because managers "significantly underestimate the efforts involved in change management," says Alfred Grunwald, CEO of Deloitte & Touche Consulting Group/ICS, a consulting company with headquarters in Chadds Ford, Pa. "What happens in most of our engagements, to be quite frank, is that many clients...focus on the benefit: reduced inventory, shortened lead times, higher customer satisfaction. What they don't focus on is, 'Is my average employee prepared? Have I provided the educational content to my employees so they actually take full advantage of the new process?' Many organizations neglect the issue of change management. They say, 'We know how to do that.' The reality is that that's not necessarily the case." In public policy circles, this is called "unintended consequences." A manager comes up with a grand scheme to fix a systemic problem, tying together bill-of-materials, shop-floor scheduling, and other traditional manufacturing functions with the rest of the enterprise, and doesn't realize the problems the solution creates.
Unintended consequences include the emotional fallout that's left when employees suddenly are given much greater responsibilities. Managers sometimes neglect to assess not only the skills development needed by employees like Kirk, but also the organizational changes required of them. "The fact is that the amount of workload and the amount of human resources power in most organizations needed to run the new environment is not different," Grunwald says. "But the skills are dramatically different."
What vendors of ERP call "cross-functional integration" takes time. Sure, you can change hardware and software overnight. But it takes weeks or months to scale learning curves. And that is part of the equation that many organizations fail to recognize: To realize significant benefits of an ERP overhaul, they must invest in significant assessment of organizational change and in training employees on new business processes. At Dana Corp., for instance, Mike Dale says, "We've got a lot better tools to monitor delivery, vendor performance, inventory, and the shop floor. I can't really say they've been fully taken advantage of yet. We're still kind of young at this."
Plant and IT managers with experience doing ERP transformations say they run into another problem: Software loaded with features can lead you astray. People tend to use all of the features that their software provides, whether those features are actually helpful in moving the company toward profitability, high quality, and efficiency, says Jeff Wood, plant manager at Par Industries in Moline, Ill. "There is a tendency sometimes to become very enamored with all the bells and whistles that go with fully integrated ERP systems, and that can cause problems down the road. Wait times, dynamic lot sizing, all of this really sexy statistical stuff can backfire: There's a temptation to say, 'Boy, this is neat; I can recalculate my lot sizes dynamically every three days!' That can cause a huge disruption if misapplied."
Wood, who joined the $70 million scientific-equipment manufacturer three years ago, revamped the manufacturing processes that have been in place since Par implemented its Baan ERP system in 1992. "We adjusted the system values more in line with short-cycle manufacturing," he says. "We found lead times were inflated, lot sizes were inflated, queue and wait times were inflated." Upon examination, he says, "we collectively decided that all the changes we decided in the past were improvements were in fact not improvements. Say I have a machine that we only need to run three hours a day to satisfy customers. To run it for four hours a day to increase inventor,2, makes no sense."
Applying a manufacturing methodology called the Theory of Constraints and using the ERP software to support this process, Wood and production and materials manager Stacey Moon stopped operating the shop floor according to forecasts of orders and instead built to customer order. Although Wood could use the software to calculate forecasts and economic order quantities (EOQs), he chose not to because neither made sense for Par's business, he felt. "One lesson I've learned through scar tissue: Especially if you're a techno-geek, you see something new and fancy, you want to use it. I fight that battle with myself all the time." After a year, delivery performance went from 60% on time to more than 95%; lead times to customers went from six to two weeks; repair parts went from two weeks to two days; work-in-process inventory dropped almost 60%; and the life of a shop order went from weeks to hours. Finally, inventory accuracy increased "from an embarrassing number to 97%," Wood says.
The plant was able to build to customer orders in such short times in part because the software allowed Wood and Moon to run closed-loop MRP every 15 minutes, rather than on a weekly batch cycle. Even this seemingly positive change, however, caused unexpected organizational strife. Previously, plant workers knew their jobs (and their significant overtime pay) were secure because, as Moon says, "we used to have racks and racks of material in front of the shop." Under the new system, materials weren't released until workers were available to assemble orders. "Everyone was afraid we would run out of work," she says. Production workers were afraid they were going to be laid off and that Pat's business was shaky. "None of those things were true," says Moon. "I knew there was plenty of work because I could see the plans in place, and we were satisfying the needs at the same time." Over time, Moon was able to assure workers that their jobs were secure. Today, they're working overtime and volume is up, despite a work force that has remained flat.
Pat's business has changed not only the way employees work, but also the ways in which their work is measured. While packaged ERP software alone doesn't force successful transformations, the data available and smart use of the data makes worker transformation possible. Says Moon of shop workers: "Now they're being measured on velocity, creativity, flexibility. They're skilled to work on different machines and go where the work is. Efficiency is not a valid measurement at Par."
How do manufacturing plants implement major changes without incurring tremendous upheaval? The advice is time-worn: Map processes before implementing new systems; involve users up front; and expect the unexpected.
That's what Jim Payne, director of information services at Safariland, did. Safariland is a $50 million Ontario, Calif., maker of body armor for police. This year, Payne is implementing a PowerCerv ERP system that integrates manufacturing, distribution, and finance. Previously, running an old Prime MRP system, the company couldn't access business information that was needed for making decisions. Faced with explosive growth, the MIS department was sinking fast. "People were queuing up in the MIS department, and it was like going up a down escalator and the escalator's going faster than you are," Payne says.
Before rearranging all internal systems into a client/server configuration, Payne mapped the company's internal business processes. He found people manually entering data that existed in the computer systems. He ultimately disbanded the data processing department and trained customer service reps to use computers. More significantly, he's looking at ways to integrate ERP with e-mail and with the Japanese kanban just-in-time process used on the manufacturing floor. Ultimately, the company's 1,000 dealers will be able to enter orders into Safariland's Web site, which will be linked directly to the ERP software.
* Involve your user community on the front end and keep users involved. This begins with a system-requirements definition and an examination of your existing business processes. * Examine your internal business processes to make sure they dovetail with your selected system in a way that takes advantage of the system's strengths. * Adopt a preference for changing your processes to make them compatible with the system, rather than vice versa. Customize only when essential. * Take your system live when you have solid audited data and the users are ready, rather than on some specific date. (In an implementation of this size, unexpected delays are bound to occur because not all problems are foreseeable.) User training should include problem solving with the system, not simply how-to training for routine transactions. * Remember that problems with business processes cannot be fixed by running the data they produce through a new and better system. If you don't fix your problems, they come with you to the new system.