Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Understanding the Plant Level Costs and Benefits of ERP: Will the UglyDuckling Always Turn Into a Swan?

Thomas F. Gattiker*Dale L. Goodhue

Terry College of Business, University of Georgia, Athens, GA 30602; *tgattike@uga.edu

AbstractThis paper explores the impact of Enterprise ResourcePlanning (ERP) systems using the individualmanufacturing facility as the level of analysis. A model ofERP costs and benefits based on OrganizationalInformation Processing Theory is proposed. The modelresolves some of the apparently contradictory ERPimpacts that have been reported in the trade literature.The paper then describes ERP implementations in twoplants. Organizational Information Processing Theoryexplains many of the costs and benefits that wereobserved in the cases. The cases also revealed severalunexpected insights. Based on the case study findings, thepaper proposes a revised model of ERP impacts.Keywords: ERP, standardization, integration,interdependence, differentiation, manufacturing planningand control systems.

1. Introduction and overview

ERP systems promise unprecedented levels of businessintegration and related benefits. Expenditures on ERP arehuge and growing. While some observers have declaredthat the end of the ERP boom is at hand, plenty ofcountervailing evidence exists. For example, as of May1999, SAP 1999 sales are forecast to be twenty to twentyfive percent over 1998 [1].

However, ERP's problems are significant, as well.Almost half of the IT managers questioned in a 1998InformationWeek Research survey named ERP systemsas the most difficult systems to implement [2]. Moreover,numerous articles [3, 4] cite examples of outrightimplementation failures.

The authors share the industrial and academiccommunities' optimism about ERP. Because ERPpromises such potential benefits, understanding the costsand how to avoid them should be a research priority.

In their attempts to develop guidelines for avoiding theproblems described above, many researchers andpractitioners have focused on elements of theimplementation process, such as user involvement,management champions, etc.. However, we propose thatmany apparent implementation difficulties are due toother more fundamental causes. Furthermore, we

0-7695-0493-0/00

recognize the potential for subtle but important problemsto persist after implementation.

Because ERP systems involve significant processstandardization and data integration, the paper begins witha theoretical model of positive and negative impacts ofdata standardization from Goodhue, Wybo and Kirsch[5]. The paper then presents two case studies of "live"ERP systems. We demonstrate that the model explainsmany of the ERP benefits and problems observed, and wesuggest a modified model that is more adapted to the ERPdomain.

Though we eventually plan to conduct a full scalevalidation of the new model, in this paper we describe aninterim step: developing anecdotal case study evidenceby studying several manufacturing facilities in depth. Thetwo cases described here likely do not represent ERPexperiences in general. However, the cases may wellrepresent a class of ERP implementations because theyshare similar organizational characteristics andcomparable ERP impacts. It is important to understandthis class.

2. What is ERP?

An Enterprise Resource Planning system (ERP) is alarge, integrated system handling business processes anddata storage for a significant number of business units andbusiness functions. ERP systems are packaged systems,which means that they are designed with a class oforganizations in mind, and then implemented in a numberof different organizations. They permit some tailoring ofthe business processes to be used in any givenorganization, but only within fixed bounds, since all thebusiness processes are designed to work together using asingle set of shared databases. Important elements ofERP include data standards, process standards, processrestrictions, and integration as discussed below.

ERP systems employ a single database for the entireenterprise [3, 6, 7]. This feature requires data standards(“the use of common field definitions and codes acrossdifferent parts of the organization”, [5] p. 23) across theenterprise.

In addition to requiring data standards, ERP alsoentails the standardization of business processes acrossoperating entities [8]. Since different business processes

$10.00 (c) 2000 IEEE 1

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

often result in different data about those processes, therequirement of data standards to a large extent requiresprocess standards as well.

Furthermore, as packaged software, ERP systemsthemselves are limited in the processes that they canmodel. We refer to this type of standardization as processrestrictions. Designers of an ERP generally select acollection of what they determine are the “best practice”options for key business processes. When configuring anERP system, implementers typically choose from amongthe best practice options that the particular ERP packageprovides. While the range of configurations available inany major ERP package is wide, ERP systems arenevertheless unable to model some of the typical firm’sexisting procedures [9] and firms must fit their processesto the system [3]. Exhortations not to stray from theoptions provided by one’s ERP package can be foundthroughout the trade literature [2, 10] and elsewhere [7].

Integration is the linking together of the informationand processes of distinct subsets of the organization.Integration can occur between operating entities (such asplants) or between functions. In an integrated ERPsystem, a transaction in one subsystem instantaneouslyand automatically updates other subsystems. ERPsystems link all (or many) business functions andoperating locations together so all have access to allrelevant information as transactions occur [3]. Integrationrequires data standardization and process standardization.

3. Understanding ERP throughOrganizational Information ProcessingTheory.

Organizational information processing theory statesthat organizations must process information to resolveuncertainty and thus make advantageous decisions. Inorder to process information, organizations must chooseappropriate coordination and control mechanisms (SOP's,committees, computerized information systems, etc.)based on the level and types of uncertainty they face [11].Uncertainty comes from a number of sources, includingthe complexity of the tasks of individual sub-units, theinterdependence of and differentiation among sub-units,and the external environment in which the sub-units1 exist[12, 13].

Goodhue, Wybo and Kirsch [5] apply the theory to thecosts and benefits of data standardization. Their modelpredicts that the benefits of data standardization increasewith the interdependence among sub-units (the degree towhich the sub-units must exchange information ormaterial in order to complete their tasks). On the otherhand, the costs of data standardization increase with sub-unit differentiation (the uniqueness of tasks, technologies,

1 The term sub-unit is used to refer to the parts, such as plants

or functional departments, that make-up the organization.

0-7695-0493-0/00

and local2 conditions in sub units). Therefore, their modelsuggests that data standardization will not always yieldnet benefits. Because integration and standardization arekey features of ERP, the Goodhue, Wybo, Kirsch modelshould explain costs and benefits of ERP.

4. Benefits and costs from ERP

The literature suggests numerous ERP benefits, whichwe have grouped into four categories3. Many firms installERP systems to improve the flow of information acrosssub-units [3]. Goodhue, Wybo and Kirsch [5] point outthat standardization and integration facilitatecommunications and better coordination. After all, datastandards eliminate the burden of reconciling ortranslating information that is inconsistently definedacross two or more sub units [15], and they do away withthe potential for translation errors and ambiguity about afield’s true meaning [16]. ERP also reduces theadministrative costs of sharing information, since iteliminates manual activities involved with keyinginformation from one system to another. Finally, ERPmay improve the timeliness of information.

Second, the process standardization and integrationacross organizational units enables the centralization ofadministrative activities, such as accounts payable andpayroll. This may allow administrative savings [3].

Third, ERP may reduce IS maintenance costs andincrease the ability to deploy new IS functionality [8].Standardization of the information systems across sub-units creates economies of scale in development andmaintenance whether these are done in-house or whetherthe firm de facto outsources them by using packagedsoftware, such as ERP. Fourth, ERP may be instrumentalin moving a firm away from inefficient business processesand toward accepted best practice business processes [14].

4.1. Interdependence: The key to ERP benefits

The Goodhue, Wybo and Kirsch model predictsbenefits related to better communication and coordination(the first category above) will accrue wheninterdependence is present. This includes sequentialinterdependence (events in one function requiringresponses in another) and pooled interdependence [17].Because ERP facilitates communication and coordination,it can improve the management of interdependence.Since interdependence among sub-units varies, the degree

2 The term local is used throughout to denote a level of

analysis that includes plants, branches, sales offices, etc., and excludescentralized functions, such as divisional or corporate management.

3 We note that a major reason for implementing ERP systemsis to replace legacy systems because they are not Y2K compliant orbecause they lack needed functionality, or both. However, since thesebenefits could be obtained with local (non-ERP) systems, we do notconsider this a benefit of ERP per se.

$10.00 (c) 2000 IEEE 2

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

to which firms realize ERP’s potential should vary, aswell.

4.2. ERP costs

The Goodhue, Wybo and Kirsch model also suggeststhat when there is substantial differentiation among sub-units, ERP systems will produce compromise costs,higher design costs, or bureaucratic delays. Asdifferentiation among sub-units increases, so does thelikelihood that a global, standardized IS will be a poor fitwith local conditions at any given sub-unit. For example,personnel might not get information in the format that isrequired by their job characteristics. Furthermore, localsub-units might not be able to react to locally changingconditions because IS impacts must be evaluated in termsof an IS that is shared by the entire organization.

Alternatively, the Goodhue, Wybo Kirsh suggest thatsome information systems may accommodate the diverseneeds of numerous differentiated sub-units. However, theGoodhue, Wybo and Kirsh model states that doing sorequires sophisticated IS configurations. The costs ofimplementing, designing and maintaining such systemsare high [5].

5. Research methodology

One intent of the study was improving ourunderstanding of how differentiation can lead todifficulties in an ERP implementation. The focus was onmanufacturing facilities because of the belief that plantswithin a firm would best exhibit differentiation in taskand environmental characteristics. Two case study siteswere chosen opportunistically through contacts in localAPICS chapters. No effort was made to selectparticularly unsuccessful or successful firms. DuringSpring of 1999, we interviewed at least seven individualsin each site, including multiple interviews with both plantmanagers, and a cross-section of individuals in roles suchas Controller, Purchasing Manager, Customer ServiceRepresentative, IT Manager and DepartmentSuperintendent. Most interviews lasted approximately 1hour and followed a semi-structured format. Mostinterviews were taped and transcribed. We toured bothfacilities and reviewed documents, such as organizationcharts and statements of objectives. Table 1 summarizeskey characteristics of the cases.

6. Case study summaries

6.1. Forest Products Corporation

Forest Products Corporation (FPC) manufacturesconstruction materials such as joists, beams, plywood andengineered lumber. FPC has approximately $1.2 billion in

0-7695-0493-0/00

sales annually, generated from 20 manufacturingfacilities, all in North America. Finished goods arestocked at the plants and shipped directly to customersand distributors. We focus on FPC’s Augusta plant.

In 1993 management decided to implement a numberof SAP modules (version 2.1) across all plants because ofincreasing IT costs and a desire for closer integrationamong plants. Along with outside consultants, a projectteam from corporate IT began implementing SAP startingwith Augusta. Because of the differences among plants,they implemented a different configuration of SAP ateach plant and they made customizations to SAP code.Unfortunately, the team spent the entire implementationbudget on just 4 plants, and the project was put on hold.Thereafter the firm hired a new IS director who pointedout the need for one company-wide ERP "vision."

FPC then formed a "blueprint team" to develop acompany-wide business and ERP plan. After theblueprint was created, SAP 3.1 was to be implemented inall 20 plants in 2 years (prior to the year 2000), with thehelp of a consultant. The first implementation occurred atthe Augusta plant and was completed August 1998. Ashop-floor data collection system and SAP front end,called FACE, was also implemented company wide.

6.1.1. The Augusta plant. The plant producesengineered beams and other similar materials. It has fourdepartments: green, dryer, press and finishing. In thegreen department trees are received, prepared, and“unrolled” into sheets of veneer. In the dryer departmentveneer is dried and then stored in bundles. In the pressdepartment, bundles of veneer are cut into strips andmixed with glue before being fed into a press. The pressruns one continuous length of material. As material exitsthe press it is cut into fifteen to fifty foot billets. Infinishing, these are cut into finished lengths, which arebundled and sent into the storage yard.

There are a number of stock items (standard depth,width and length) but many products are sawed to order.Sawed-to-order material is referred to as configurablematerial or N-STOK. After being cut and bundled infinishing, stock and non-standard (N-STOK) products gointo finished inventory. Offcuts (leftover sections ofbillets from finishing) and rejects containing some usablematerial go into recovery-reclaim inventory for use later.

Each plant’s customer service department takes orders.Stock orders that cannot be filled from finished goodsinventory are promised against future production. Non-standard orders are sawed to order (from recovery/reclaiminventory material, or new production).

The wide variety of finished goods configurations itships sets the Augusta plant apart from other facilities inthe company. In its product line, it is the only plant thathandles non-stock lengths. For example, Augustamanufactures all European (metric) orders which is asignificant business segment.

$10.00 (c) 2000 IEEE 3

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

6.1.2, Benefits from ERP. According to theinterviewees, the system has produced several importantbenefits at the plant level. SAP maintains perpetualinventories of finished goods and of some intermediatematerials. These increase the plant’s ability to make andkeep customer commitments. Additionally, severalinterviewees stated that SAP improves accountability andself-discipline within the plant. SAP provides visibility ofproduction orders that are open in the plant and itprovides accurate inventories of intermediate materials,such as veneer. At the company level, SAP improvescoordination among plants for filling customer orders.All plants’ inventories are viewable from a single system;and some plants can enter finished goods orders againstone another’s inventories.

The first three of Augusta’s four departments (green,dryer, and press) are satisfied with SAP. Unlike the

fscrrss

r

0-7695-0493-0/00

inishing department, these production areas are verytraightforward in terms of manufacturing planning andontrol, and typical of most operations in FPC. Theeaction of the manager of the dryer department isepresentative of these departments. He stated that theimplicity of their processes has a lot to do with theiratisfaction:

When you take a log and you peel it, and you makea stack of 4 x 8 veneer, all SAP is doing is tracking:that’s worth 90 cubes, 90 cubic feet. Then when thedryer uses it, through the FACE system, wewithdraw that from inventory and it minuses outand it gets added to the next stuff along the line.

Furthermore, SAP has eliminated or automated manyeporting and data entry chores.

Table 1. Cross case summary of key characteristics

Forest Products Auto Products - Heavy Equip. Div.

ERP Characteristics:

System installed SAP OracleImplementation begin (in plant) Ver. 2.1 1993; Ver. 3.1 1998 1997Business functions in implementation MM, FI, SD Manufacturing; Finance and Payroll.

Number of plants in implementation 20 7 initially; then 1In house IT manager No YesConsulting firm assisted Yes YesPlant representation in vision setting Yes (Plant Manager) MinimalBusiness Characteristics:Products Manufactured Engineered Lumber Mechanical componentsPlant employment 350 200Manufacturing configuration Continuous/Repetitive but "finish to order" RepetitiveMajor processes Processing, cutting, packaging Machining, assemblyKey differences from peers Higher variety and customization Repetitive-- most peers are batchKey manufacturing and marketinginterdependencies within company(involving the plant studied)

Like items in multiple plants' finished goodsinventories; Transshipment of oneintermediate material

None- No common materials or interplantshipments.

ERP Benefits --Plant Level Better discipline, enhanced inter-departmental coordination and easierreporting in many departments.

Improved BOM and inventory accuracy

ERP Problems--Plant Level Poor quality and relevance of information atplant and department levels. Drasticincreases in resources required forreporting and inventory control in Finishingdepartment. Poor conceptualunderstanding of system in some areas.

Poor information quality at departmental andplant level. Cumbersome and poor productionand inventory control. Increase in resourcesrequired for production reporting. Poorconceptual understanding of system in mostareas.

ERP Benefits-- Organization level Multi-plant finished inventory visibility; orderpromising. Other substantial benefits likely,but not the focus of this study.

None observed. Substantial benefits possible,but not the focus of this study.

Plant manager's evaluation of systemtoday

Not a good fit for the business or mfr.environment. "Overkill."

"Still wish we had something else"

6.1.3 Problems from ERP. Many problems stemfrom the poor visibility of information regarding N-STOKorders and recovery-reclaim inventory. The accuracy andunderstandability of performance measurement andaccounting data are also issues. The problems often resultin the use of informal systems or "going without."

6.1.4. N-STOK. One goal of the SAP 3.1implementation was to enable available to promisecalculations. Doing so without adding unacceptable levelsof complexity and IS staff required drastically reducingFPC’s number of stock model numbers. Starting with theSAP 3.1 implementation, FPC instituted “configurablematerial” or N-STOK part numbers for all non-standard

$10.00 (c) 2000 IEEE 4

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

products. A given N-STOK number is used for all non-standard products with a given width and depth,regardless of length. For example, all non-standard itemsthat are 3.5 inches wide and 14 inches deep are assignedpart number 897686, regardless of their length. Since N-STOK part numbers do not indicate length they cannot beused as unique identifiers for a given configuration ofproduct. Therefore, although it carries a N-STOKnumber, the unique identifier for any non-stock item is thesales order number and line number.

Because of its heavy volume of non-standard business,relative to other plants, Augusta experienced problemsrelated to N-STOK. For example, the master schedulerneeds to know what orders have been placed, and whatrecovery-reclaim is available for cutting. For any plannedorder related to N-STOK, the SAP standard reports hereceives indicate the quantity, depth and width of thematerial needed, but not the length. To discern the lengthhe needs to open up the appropriate line item of thespecific sales orders. As a result the master schedulerspends approximately 30 minutes per day looking up N-STOK requirements in sales orders. N-STOK createssimilar problems in the customer service department.

6.1.5. Recovery-Reclaim. Offcuts and partial bundlesare stored in recovery-reclaim inventory until they can beused on new orders or completed. Because of its highvariety of configurations, Augusta has some of the“toughest cuts” in the company. This wide variety of cutsresults in a lot of leftover billet sections and thus a lot ofrecovery-reclaim inventory to manage.

Since FPC's ERP system is part-number driven, theonly way to record the exact contents of recovery reclaimwould be to assign a part number to every piece that wasplaced into recovery reclaim. FPC management feels thisis not worthwhile because of the sheer (potentiallyinfinite) variety of lengths of offcuts and rejects.Therefore, all material that is placed into recovery-reclaimis inventoried under a single part number, and SAP only“knows” the total cubic feet in recovery-reclaim.

This poor visibility into recovery-reclaim causesproblems for the plant. For example, to avoid wastingusable material, the master scheduler needs to schedulecuts from material in recovery-reclaim, instead of cuttinginto “fresh” billets. The scheduler would like to solve theproblem by keeping a perpetual recovery-reclaiminventory in Excel; however, doing so would require afull-time clerk which the plant cannot afford. Thereforemaking the best use of recovery-reclaim is difficult, andthe master scheduler estimates it has added five to tenhours to his work week.

The finishing department, too, must do manualcalculations in order to manage the material flow into andout of recovery-reclaim each day. This activity consumesabout 1 man-day everyday, and the department recentlyhired a clerk solely to work on it.

0-7695-0493-0/00

6.1.6. Performance reporting. In addition tovisibility problems for critical information, there is also aproblem with the meaningfulness and accuracy of SAPreports. This surfaces in a number of different areas andis often addressed by maintaining alternate reportingsystems.

In the finishing department, production and costnumbers generated by SAP are not useful to the finishingmanager. The key performance indicator for the finishingdepartment manager is recovery (net finished goodproductions divided by billets received into thedepartment to be sawn into finished goods). Howeverbecause of recovery-reclaim, SAP does not provide ameaningful recovery metric that the department managercan use to gauge performance on a daily basis. Recoveryis understated some days and overstated on others.Because the SAP daily production report is notmanagerially meaningful, the Finishing DepartmentManager and other managers use a manually generatedDepartment Production Report maintained on Excel.

Really, SAP, even though that’s eventually what theplant’s performance is based on, I don’t really use alot of the numbers that we’re entering. Numberone, they’re not easy to get to. I know my wayaround the system, but they’re not easy to get to. Idon’t trust the numbers that it gives me.

Similarly, the senior plant accountant and the plantmanager have concerns about the accuracy of SAPgenerated reports. Some problems are inherent in FPC’sSAP configuration. For example, because a N-STOK partnumber does not signify length, it is difficult to track thecost per unit. This creates problems valuing certainbusiness, such as European sales. Other deficiencies maybe due to errors in the logic implemented. The plantmanager and accountant have noted many discrepanciesbetween SAP-based performance reports and bothhistorical averages and manually generated reports.Corporate has investigated some of these and the plant’sinternal figures or estimates have been found correct.

As a result, the plant manager and his team make manydecisions based on a manually generated plant productionreport. This report draws data from the FACE system,and from various departmental reports, some of which aregenerated from tally sheets on the shop floor.

Even though the Senior Plant Accountant has years ofexperience in a variety of manufacturing environments, hehas difficulty comprehending how costs are calculatedand passed on from one department to another in thecurrent system. Furthermore, because SAP limits hisaccess to information and the format into which it isorganized, SAP makes it more difficult to investigate andunderstand. He feels that eventually the problems will befixed and that reports will be customized more to meet theneeds of the plant but that right now resources are aproblem. However he points out that in previous systems

$10.00 (c) 2000 IEEE 5

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

he would have done much of this customization himself.Now, because of the integration of plants and associatedcomplexity, he is dependent on the corporate SAP team.

If you tinker with something, you’re tinkering withsomething that 19 other plants are using, too, andyou just can’t do that. You don’t know what, andnot all the plants are exactly the same, so you don’tknow what you’ll screw up somewhere else.

6.2. Auto Products Corp: Heavy EquipmentDivision

Auto Products Corporation has approximately 200manufacturing facilities with six billion dollars in annualsales. The Gainesville plant is one of 7 in the HeavyEquipment Division. The plant supplies several of themajor OEM's.

In the mid-1990’s Division and Corporate IT personnelrealized that Y2K and customers' increasing IT-relateddemands (EDI, etc.) made existing systems costly. Theyviewed ERP as a solution. Manufacturing, too, was awareof the increasing IT backlog and supported ERP. Finallymanagement wished to centralize plant accounting andbelieved ERP would provide the needed infrastructure.

Both corporate accounting and the division decided toimplement Oracle around 1995. The division’s coreimplementation team, called the SLAM team, was formedin December 1996 and was assisted by a consulting firm.The Gainesville implementation was the first in thedivision. It began in Spring 1997 and went live inOctober 1997

6.2.1. The Gainesville plant. Gainesville’s product ismade by machining metal parts and then assembling themtogether along with some electrical components. Fourmodels comprise over eighty percent of shipments. Theseitems are produced continuously. Most materialsmanagement and manufacturing activity involves onlyone hundred or so part numbers. Gainesville differs frommany of the other plants in the division because many ofthe other plants produced a greater variety of end itemsless regularly. It is a repetitive manufacturer while mostof the others are batch plants.

About three months into the Gainesvilleimplementation, the plant manager was replaced.Between 1996 and 1997, demand had increaseddrastically, and the plant experienced extreme difficulty inmeeting commitments. The plant’s first priority wasshipping product to meet customer needs, not the Oraclesystem. As a result, the Oracle implementation teammade numerous configuration decisions without inputfrom Gainesville personnel. There were othercompromises between the needs of manufacturing and thesystem's imperatives. For example, Gainesville wasexpected to change its part numbers to a division standardbeing developed for the ERP. According to the plant

0-7695-0493-0/00

manager, changing part numbers would have affected dataaccuracy and the time required to do transactions.Furthermore the plant had a huge investment in printeddocumentation based on the existing part numbers.

While Oracle was running after October 1997, to alarge extent it was bypassed until after the fact, andinformal systems and legacy systems, were used to planand control plant operations. The plant managed to shipproduct in spite of, not because of, Oracle:

We were able to get the point that we didn’t let it[Oracle] impact our customers, we made productsand shipped products and did what we needed to doto catch up with the system. – Plant Manager

6.2.2. Shop floor control problems. A major sourceof the problem was the Oracle shop floor module. Eightypercent of Gainesville’s shipments came from a fewproducts, which consisted of only fifteen to twenty parts.For the most part, production was continuous andpersonnel knew the necessary work instructions andmaterial flows. However, the ERP shop floorconfiguration was designed to control each step in theprocess via system-issued production orders. In additionto scrap and inventory transactions, an Oracle transactionwas required when work orders were started and stopped.In fact, completing a finished product required 26 Oracletransactions in the shop. Aggravating this were Oracle’stransaction screens, which employees consideredcumbersome and slow. Early on, management respondedby deciding that operators would record transactions inlogs. These were transcribed into spreadsheets and paperreports, which were delivered to the office, where theOracle transactions were entered.

A new division vice-president came to power inSeptember 1998. Soon after, he cancelled the divisionOracle project. The Gainesville implementation, whichwas complete, effectively became stand-alone as the otherplants remained on their AS-400 systems.

At roughly the same time, the plant manager began aprogram, called “Streamline”, to simplify Gainesville’slogical and computerized systems. Streamline replacedOracle’s order driven shop floor control system with aKanban system (a simple control system using visualsignals to coordinate production between departments).As part of the Streamline initiative, the plant IS team anda group of consultants replaced the Oracle shop floormodule with a customized module borrowed from anotherfacility. With the exception of scrap reporting, the newmodule has eliminated transactions on the shop floorbecause the module is based on backflushing. Onetransaction, which is made when a product is shipped,replaces the original module’s myriad shop floortransactions. When the ship transaction is entered, thesystem automatically creates the jobs and generates thetransactions that would have been done manually underthe old module.

$10.00 (c) 2000 IEEE 6

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

Using the Streamline principles, the plant todaysatisfies its customers. Though purchasing uses Oracle,Oracle is not an integral part of manufacturing andmaterials management. Kanban controls the shop floor,and spreadsheets are used for production and materialplanning. The plant manager characterized the situation asfollows:

I would strongly disagree [with the statement “youare running your plant using Oracle”]. We arerunning our plant based off of our manual systems,and we have simplified Oracle to a point to be ableto use it to accurately reflect our financial status.

6.2.3. Complexity and understanding. Gainesville’scurrent management is a fairly sophisticated group. Theyhave a solid conceptual understanding of the frameworkof more general accounting systems and manufacturingplanning and control systems (such as MRPII). Bycontrast, many feel they do not understand the modelunderlying ERP. For example, the plant managercomplained:

I mean I am not a dumb person, but I have got totell you I don’t understand. And, I was thematerials manager in my previous life and Iunderstand MRPII, and I have a financialbackground as well. All of this [accounting andmaterials management standard bodies ofknowledge] stuff makes good sense to me, but Icannot make sense…. I mean when a transactionhappens over here it is so integrated I don’t knowwhat is going to happen with it.

Many of the people interviewed expressed concern thatthe plant would not be able to continually adapt Oracle asconditions change and modifications to business practicesare needed.:

You’ve got to adapt to the system, the system’s notgoing to adapt to us. Right now [new practices]would have to be tailored to Oracle. It’s not like wecould take Oracle and mold it around what we wantit to do. - Purchasing Manager

Several interviewees partially attributed their concernsabout adaptability and innovation to their poorunderstanding of the system. Though the IS Managerstated that you can develop competitive advantagesworking with Oracle, she added, “You’re going to have tohave a core group that really, really knows that software.”Apparently, most Gainesville personnel have notdeveloped this level of understanding. Several interviewssuggested that the level of integration across functionalareas contributes to some of their reluctance to manipulatethe system. For example, on manager stated:

You're affecting so many more disciplines… Onechange may mean 25 changes. There's not enoughpeople out there that fully understand the wholepicture, because it's modular. They [can’t] tell you

0-7695-0493-0/00

because it is, "I worked with one consultant overhere because they were the expert in purchasing. Iworked with the other group because they were theexperts in accounting." Until somebody knows thewhole picture, how can you not be scared to make achange.

7. Applying the model to the cases

Based on the findings in our case studies, we present amodel based on the Goodhue, Wybo, Kirsch model. Ourmodel is in Figure 1, which is discussed below.

7.1. Interdependence and ERP benefits

Following Goodhue, Wybo and Kirsch, Figure 1suggests that when interdependence among sub-unitsexists, ERP provides communication and coordinationbenefits, many of which manifest themselves most clearlyat the corporate level. Because our research focused onthe local level, we were not in a position to thoroughlydiscern all corporate-wide benefits. Even so, there issome evidence of global benefits, such as bettercoordination among sub-units. For example, ForestProducts’ ERP allowed customer service reps to seeinventory across multiple plants and to place customerorders against other plants’ finished inventories. Weassume that other global benefits accrue in these firms,especially where pooled interdependence exists.However, there was minimal interdependence involvingthe plants, (such as interplant material shipments) andthus we observed few plant-level ERP benefits.

Figure 1 emphasizes global benefits driven byinterdependence and local costs driven by differentiation,but not local ERP benefits. Our research was wellpositioned to discern both benefits and costs at the locallevel, and we did definitely see some laudable localbenefits. As we reported above, Forest Products' ERPimproved coordination and discipline betweendepartments within the Augusta plant, and it automatedsome manual tasks. Similarly, implementing ERP forcedimprovements in BOM accuracy at Auto Products. Theseare substantial benefits, however, we must be cautiousabout labeling them as ERP benefits per se because theseimprovements could have been accomplished with singlesite systems, such as MRPII.

7.2. Differentiation and local problems

Figure 1 predicts that ERP will impose costs whendifferentiation exists among entities in an enterprise,because differentiation increases the likelihood that theERP will be a poor fit to the operational and informationalneeds of some local units. Our cases support thisassertion. The most severe problems associated with ERPwere related to the fact that both plants were ugly

$10.00 (c) 2000 IEEE 7

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

ducklings: They differed significantly from the otherplants that were in the ERP implementation.

Forest Products’ Augusta plant differs from otherplants due to the wide variety of non-standard finishedproducts it makes, and the resulting need to utilize N-STOK part numbers and recovery/reclaim. When FPCconfigured SAP to handle N-STOK and recovery/reclaim,it assumed that non-standard cuts and non-standardproducts were rare. The resulting “ungraceful” manner ofhandling of N-STOK and recovery-reclaim was worthputting up with at the other plants. But at Augusta it ledto operational problems for the master scheduler and thefinishing manager, as well as reporting problems thatrolled up to the plant manager level since it under-reported an important component of production. TheAugusta plant has responded by relying on several manualsystems, but these are resource intensive and still have notsolved its problems regarding the accuracy ofinformation.

Similarly, APC's Gainesville plant differed from otherplants in its division due to its product-process structure.The shop floor module that was implemented wasappropriate for a plant producing a high variety of modelsor models with a complex product structure. Each step in

0-7695-0493-0/00

the production process was controlled by a discrete workorder and required numerous ERP transactions.Reporting the status of each work order allowed closetracking of work-in-process and intermediate componentinventories. Such a system was a good fit for many of theplants in the division, but not for Gainesville. Gainesvillemakes only four major products from a handful ofcomponents. Cycle times are short and routings fixed.Therefore, there is little need to control production withwork orders or for detailed inventory tracking.

With it’s twenty-some reporting points and awkwardinterfaces, the Gainesville ERP’s shop floor interfacesstifled production until Auto Products was able touncouple production from the ERP by interposing the“Streamline” system front end. Then the plant could usemanual systems that fit its needs such as Kanban andspreadsheets. In effect, the plant developed thecoordination and control processes it needed and thenretrofitted or jury-rigged Oracle so it would not be toodisruptive. The Oracle system has not significantlyimpacted manufacturing, materials, or purchasing becausethey rely on manual systems.

Interdependenceamong sub-units

Improved coordination among plants.Better corporate-wide mgmt. info.Administrative savings.IS development & maintenance savings.

Differentiation amongsub-units Poorer fit between

ERP system and localoperational andinformation needs ofsome plants

Better fit between ERPand global operationalneeds

Local level effects:Reliance on legacy and informalsystems.Diminished quality & relevance ofinformation.More resources needed fortransformation, reporting and planning.

Diminished local levelunderstanding ofinformation systems

Reduced ability to to generate and tosupport local adaptation and innovation

In the presence ofthese characteristics:

ERP (standardization andintegration) leads to: Which yields these outcomes:

Limits on resourcesdedicated to locallevel implementation

Any level of localmgmt./staff skill &education

Figure 1. Revised model of ERP impacts

7.3. Modifying the degree of standardization

Although experimental control is not a strength of casestudies, we note that events in both cases essentially

encompass two implementations each. And within eachcase, the level of integration and standardization differedbetween implementations, as did the ERP costs andbenefits. FPC's version 2.1 implementation was highly

$10.00 (c) 2000 IEEE 8

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

customized in Augusta while the version 3 implantationemphasized standardization and expedience. We note thatthe first version of SAP handled N-STOK and recovery-reclaim better than the second implementation.Furthermore, interviewees felt that reporting was better inthe first system. Auto Products Corp’s Gainesville plantstarted as part of a divisional implementation, but becamestand-alone when the division Vice President cancelledthe project. After the project became stand-alone, theplant switched from Oracle’s order driven shop floormodule to the demand flow module, which proved to be amuch better fit.

7.4. The role of resources

One might argue that the problems experienced atFPC and Auto Products are transitory – that after an initialrough period the systems will be appropriately configuredand local operations will run smoothly again. The plantsmay not be exploiting certain flexibilities built into theirERP packages. In fact one plant manager mentioned thispossibility. However, because of the complexity of theERP, neither he nor anyone on his staff has the necessaryunderstanding of the system to even know if there is amore sophisticated global configuration that meets hisneeds while maintaining compatibility with the otherplants requirements. Resources required to evaluate thisand to possibly implement a more sophisticatedconfiguration are scarce and costly.

Moreover, because it is simpler to implement andmaintain one standard configuration, in some instanceslimits on the firm’s permanent IS resources will stillnecessitate standardization and thus make it difficult toaccommodate ugly ducklings. For example, ForestProducts’ made a deliberate decision to accept theshortcomings of the way its SAP configuration treats N-STOK because a more accommodating solution wouldhave required that several people be added permanently tothe corporate IS staff. While this is a case of a deliberatedecision not to accommodate differentiation, severalinterviewees suggest that uniqueness also determineswhich unanticipated problems go untreated, as well. Oneinterviewee stated:

Nobody’s going to back you up now because you’rethe only plant with a problem. The problems thatare getting fixed are problems that are prettysimilar throughout all plants. The problems thataren’t getting fixed are the ones that are individualproblems, specific to plants.

When differentiation exists among a firm's sub-units, it may be wise to allocate more resources(consultants, IS staff, etc.) to the ugly ducklings so thatthose sub-units can fully exploit whatever flexibilityexists in the ERP. As suggested in Figure 1, failure to do

0-7695-0493-0/00

so likely saddles ugly ducklings with systems that areinconsistent with their operational needs or environments.

7.5. Systems complexity and innovation

Finally, though we were not looking for it, ourcases suggested that ERP systems may hinder localbusiness processes innovation. The people who workclosest to a business process and its information systeminterface often best understand how it works and how itcould be improved. Indeed, “tinkering” or experimentingwith small changes drives improvement in many firms.

The level of integration in ERP makes for highlycomplex systems with difficult to understandinterrelationships between subsystems. Numerousinterviewees, including those who clearly understoodprevious systems, complained that they found the ERP’scomplexity bewildering.

When front line managers and staff do not understandthe business system, they are in a much weaker positionto generate possible process and control innovations.Further, they will not be able to easily test out theirinnovative ideas, since they lack the authority and know-how to make many changes. Finally, those who crossthese first hurdles face the possibility that changes mightnegatively impact other parts of the organization.

This could move the locus of innovation, perhapstoward the ERP vendor firm or to a specialized corporategroup. This possibility is significant and deserves furtherconsideration.

8. Conclusion

Today’s common wisdom reflects a belief in theefficacy of transplanting business practices from one firmto another. This assumption is embedded in ERP. At theglobal, macro level, business processes typically doappear interchangeable. Often business practices areportable and a firm's ERP driven practices are superior toits original ones. At first, new practices may seemawkward in some plants, but eventually these uglyducklings will transform into swans. This is apparentlythe belief of the CEO who informed Ross [8], “We toldpeople that they could write down every change they feltthey need on this piece of paper and we would take it tothe steering committee who would reject it” (p. 3).

Indeed we encountered situations in our cases wherelocally unique practices could have been changed in favorof standard ones. For example, the Gainesville plantcould have changed its part numbers to the divisionstandards with some up-front costs but no long-termpenalty.

On the other hand, some “ducks” really are different.The macro perspective may overlook valid local task orenvironmental characteristics that require a particular (andsometimes particularistic) business process in a single

$10.00 (c) 2000 IEEE 9

Proceedings of the 33rd Hawaii International Conference on System Sciences - 2000

facility. For most of its plants, Forest Products likelymade a profitable trade-off by accepting limited visibilityof non-stock part numbers (N-STOK) in exchange for areduction in discrete part numbers and the ability toperform available-to-promise calculations. However, inAugusta, that configuration does not work and cannotwork if non-stock orders remain a high portion of theirbusiness.

Finally, the possibility that the complexity of thesesystems may have the effect of reducing some types ofinnovation merits concern. It may be only that more timeand training is required before local users are comfortableand proficient enough to make local innovations, or itmay be that local innovations will not be part of the ERPpicture in many circumstances-- a disturbing possibility.

Clearly ERP can deliver unprecedented benefits andwe are not arguing otherwise. However, our casessuggest action along two fronts. For ERP vendors, theysuggest continuing to improve the systems' flexibility sothey can accommodate local differences. Our study alsosuggests working to make the underlying logic of thesesystems somewhat more transparent. (Clearly these arelarge challenges!). For implementers, the findingssuggest more carefully analyzing potential differencesamong local units and not dismissing out of handmanagers who claim they are different. The cases alsosuggest that implementers allocate sufficient resources totraining local users in the logic of the whole system.

References

[1] “SAP Reiterates: Sees '99 Sales Up 20-25 Percent,”Reuters newswire, 1999.

[2] C. Wilder and B. Davis, “False Starts, StrongFinishes,” Informationweek, pp. 41-53, 1998.

[3] T. Davenport, “Putting the Enterprise in the EnterpriseSystem,” Harvard Business Review, vol. 76, pp. 121-131, 1998.

[4] M. H. Martin, “An Electronics Firm Will Save BigMoney by Replacing Six People With One and Lose All ThisPaperwork, Using Enterprise Resource Planning Software. ButNot Every Company Has Been so Lucky,” Fortune, vol. 137,1998, pp. 149-151.

0-7695-0493-0/00

[5] D. L. Goodhue, M. D. Wybo, and L. J. Kirsch, “TheImpact of Data Integration on the Costs And Benefits ofInformation Systems,” MIS Quarterly, vol. 16, pp. 293-311,1992.

[6] N. H. Bancroft, H. Seip, and A. Sprengel,Implementing SAP R/3, 2nd ed. Greenwich, CT: Manning, 1998.

[7] T. Curran and G. Keller, SAP R/3 Business Blueprint:Understanding the Business Process Reference Model. UpperSaddle River, NJ: Prentice Hall, 1998.

[8] J. W. Ross, “The ERP Revolution: Surviving VersusThriving,” MIT, Cambridge, MA, White Paper November 1998.

[9] A. McAffe, “Vandelay Industries, Inc.,” . Boston:Harvard Business School, 1997.

[10] J. Connoly, “ERP: Corporate Cleanup,”Computerworld, vol. 33, 1999, pp. 74-78.

[11] J. R. Galbraith, “Organization Design: AnInformation Processing View,” Interfaces, vol. 4, pp. 28-36,1974.

[12] R. L. Daft and R. H. Lengel, “OrganizationalInformation Requirements, Media Richness and StructuralDesign,” Management Science, vol. 32, pp. 554-571, 1986.

[13] M. L. Tushman and D. A. Nadler, “InformationProcessing as an Integrating Concept in Organizational Design,”Academy of Management Review, vol. 3, pp. 613-624, 1978.

[14] D. P. Cooke and W. J. Peterson, “SAP ImplementationStrategies And Results,” Conference Board, Research Report1998.

[15] G. Huber, “Organizational Information Systems:Determinants of their Performance and Behavior,” ManagementScience, vol. 28, pp. 138-155, 1982.

[16] A. P. Sheth and J. A. Larson, “Federated DatabaseSystems for Managing Distributed, Heterogeneous, andAutonomous Databases,” ACM Computing Surveys, vol. 22, pp.184-236, 1990.

[17] J. D. Thompson, Organizations in Action. New York:McGraw-Hill, 1967.

$10.00 (c) 2000 IEEE 10