TOOLS FOR BUILDING INFORMATION SYSTEMS:ENTERPRISE TOOLS

ENTERPRISE TOOLS

Since the early days of business computing, system designers have envisioned information system architectures that would allow the seamless sharing of information throughout the corporation. Each major advance in information technology spawned a new generation of applications such as CIM or MRP II that claimed to integrate large parts of the typical manufacturing enterprise. With the recent

growth in client / server applications and more powerful relational databases, a new breed of ‘‘enter- prise’’ tools has emerged in the last 10 years. These enterprise tools enable the design of information systems, commonly called ‘‘enterprise resource planning’’ or ‘‘ERP systems,’’ that are truly enterprise- wide. They have become popular in large part because they are replacing older legacy systems that are often complex, redundant, and notoriously inﬂexible, with a suite of integrated application mod- ules and integrated data that is accessible throughout the enterprise. Another common feature among the various enterprise tools is that they are intended to develop a set of integrated applications, typically for large business enterprises. These business enterprises may be global in nature, and these systems are typically running on a distributed client / server platform with a common, integrated database.

Enterprise Tools Deﬁned

Today, when software vendors and consultants talk about enterprise tools they are referring to a class of tools that are frequently referred to as enterprise resource planning (ERP) software. ERP is a term used by the industry to refer to a collection of applications or modules that can be used to manage the whole business. ERP software describes the class of prepackaged software applications that can be conﬁgured and modiﬁed for a speciﬁc business to create an ERP system. Here we use the term ERP interchangeably with the term enterprise tools. ERP software or packages are deﬁned here as:

An integrated set of software modules designed to support and automate core business processes that may include logistics, sales, manufacturing, ﬁnance, and human resources.

A key point to note in this deﬁnition is that the software is integrated around a common user interface and around a shared database so that data can easily be shared between applications such as production and ﬁnance. Also of importance is the notion that the software is designed to be modular, so users can implement whichever modules they choose, and that it is oriented towards supporting business processes rather than the traditional functional view of the organization. It is this process view that is often the most misunderstood part of implementing an ERP system, since it can entail substantial reengineering of core business processes.

Evolution of Enterprise Resource Planning

The idea that a large corporate enterprise could be supported by a completely integrated information system is certainly not new. It has been envisioned since the early days of computers. These visions began to become more concrete in the manufacturing area when computer integrated manufacturing (CIM) systems became popular in the early 1980s. The goal of CIM was to link up the CAD output from the engineering function to marketing personnel so it could be reviewed and also be shared with the production planning and production departments. A part of the product’s design was the bill of materials (BOM), which contained the material speciﬁcations and quantities to produce a single unit of the particular product. In later versions of CIM, this BOM might also be used create an electronic order and send it to approved vendors via an electronic data interchange (EDI) connection. The basic beneﬁts were that it would decrease product development time and production costs while allowing designs to be changed rapidly and smaller production runs to be made. Because of its inherent complexity, few ﬁrms developed these in-house and most chose to purchase generic CIM software. However, CIM did not achieve all the anticipated gains in integration and gave way to another manufacturing integration concept, MRP II.

The lessons learned in trying to implement CIM in the manufacturing environment were used in the development of the newer material requirements planning (MRP) systems in the mid-1980s. The functionality of these new planning systems continued its expansion as companies tried to take a more holistic view of manufacturing processes. Improvements in new relational database technology made it possible to integrate the different departments involved in the manufacturing processed around a central database. MRP II systems extended the integrated manufacturing concept by linking the production schedule to other organizational systems in ﬁnance, marketing, and human resources. For instance, changes in customer demand would have a ripple effect on cash ﬂow planning, and personnel planning, in addition to purchasing. The goals again were to cut costs of production, reduce inventory, improve customer service, and integrate production decisions better with ﬁnance and marketing func- tions.

The Appearance of Enterprise Resource Planning

While MRP II remained focused on shortening the ordering and production cycles in a manufacturing environment, several advances in technology in the late 1980s led to the development of ERP tools and applications. Beyond the manufacturing processes, ERP encompasses business planning, sales planning, forecasting, production planning, master scheduling, material planning, shop ﬂoor control, purchasing and ﬁnancial planning, routing and bill of material management, inventory control, and other functions. As with MRP II, a centralized relational database is key to the success of an ERP application. Other new technologies that enabled the spread of ERP tools include the rapidly maturing client / server distributed architecture and object-oriented programming (OOP) development practices. Both of these factors make the ERP system more scalable both in terms of the hardware and also the modularity of the software. This scalability in turn lends itself to continuous expansion of their functionality, as can be seen by the rise of new ERP modules that extend to supply chain and customer relationship concepts, generating tighter linkages with both the customer’s and supplier’s own plan- ning systems.

As the scope of these integrated applications has grown, it is clear that the complexity has also grown. Horror stories about runaway ERP implementations appear frequently in the popular press. Two examples occurred in 1999 with the much-publicized problems of Hershey’s ERP implemen- tation and also a similar set of problems at Whirlpool. After more than $100 million had been spent on Hershey’s ERP implementation, Hershey’s inventory system did not work and they reportedly lost more than $100 million during the busy Halloween season (Stedman 1999b). ERP costs for large multinational ﬁrms can easily take several years and cost several hundred million dollars. Corning Inc. reported in 1998 that they expected their ERP project to take between ﬁve and eight years to roll out to all 10 of its manufacturing divisions (Deutsch 1998). Common complaints about ERP products are that they are inﬂexible and if anything special is desired, expensive consultants must be hired to design ‘‘tack on’’ modules that often must be programmed in some obscure proprietary language. This ‘‘one size ﬁts all’’ mentality makes it difﬁcult for smaller companies to justify the expense of an ERP systems. It may be that ERP will not ﬁt with certain types of organizations that require extensive ﬂexibility. Experience has shown that ERP systems seem to work best in those organizations with a strong top-down structure. Also, the very complexity of an ERP implementation frightens off many potential adopters because it may involve shifting to a client / server environment combined with an often painful process of reengineering.

With all the problems and risks associated with ERP, why would anyone even want to consider an ERP system? Despite these problems, from 1995 to 1999 there was a tremendous growth in corporate implementation of ERP systems. Over 70% of the Fortune 500 ﬁrms (including computer giants Microsoft, IBM, and Apple) have implemented an ERP system. Though market growth slowed a bit in 1999 due to corporate focus on the Y2K problem, during this same ﬁve-year period, ERP vendors averaged about 35% annual growth (Curran and Ladd, 2000). Globally, the ERP market is projected to grow at a compound annual rate of 37% over the next few years, reaching $52 billion by 2002.

The reality is that if a company today wants an enterprise-wide IS, there are few alternatives to ERP tools. Though the risks are very high, the potential beneﬁts include Y2K and Euro compliance, standardization of systems and business processes, and improved ability to analyze data (due to improved data integration and consistency). A vice president at AlliedSignal Turbocharging Systems said the company was replacing 110 old applications with an ERP system and this would help the $1 billion unit do a much better job of ﬁlling orders and meeting delivery commitments (Davenport 1998). Prior to the year 2000, the most common expected beneﬁts of implementing an ERP solution cited in interviews of information technology executives included:

• Solved potential Y2K and Euro problems

• Helped standardize their systems across the enterprise

• Improved business processes

• Improved efﬁciency and lowered costs

• Needed to support growth and market demands

• Global system capabilities

• Ability to integrate data (Bancroft et al., 1998)

The Enterprise Tools Market

Next to electronic commerce, ERP is one of the most dynamic and rapidly growing areas of business computing. The market for ERP tools has grown at an average annual rate of 30–40% since 1994. ERP revenues for 1998 were approximately $23 billion and were expected to grow to $52B by 2002. Because it grew out of the MRP II market, the early focus of ERP tools was on the manufacturing complex, and it expanded from there, to service and even government and educational institutions. Penetration of this market by ERP tools has reached 70%, and it is said that almost all of the remaining companies are considering installing an ERP solution. The ERP tools market was really deﬁned and is still dominated by a German software company, SAP AG, which currently controls 33% of the ERP market. SAP had revenues in 1998 of $5.05 billion, a 41% increase from the year before (Curran and Ladd 2000). Oracle is the next-leading ERP tools vendor, at 10% of the market, then J.D. Edwards Inc. at 7%, PeopleSoft, Inc. at 6%, and Baan, NV rounding out the top 5 ERP vendors at 5%.

Begun in 1972 by four IBM German engineers, SAP virtually deﬁned the ERP tools market. Its early product, R / 2, was a mainframe-based extension to MRP II. However, its top leadership made the strategic decision in 1988 to focus all R&D efforts on developing enterprise solutions for the client / server platform. SAP was one of the earliest software vendors to recognize this fundamental shift and is now the leading client / server application software vendor and the fourth-largest software company in the world. The list of their clients includes 9 of the 10 companies with the top market value in the world and includes IBM, Microsoft, and Apple within the computer industry itself. Their product, R / 3, is available in 14 languages and is used by over 10,000 customers in more than 90 countries (Curran and Ladd 2000). SAP has expanded beyond its traditional base in manufacturing industries into service industries, education, and governmental agencies. Service industry clients include Burger King, Sothebys, Lufthansa, and Deutsche Banke. Among governments, the Canadian government standardized on SAP and has one of the largest public installations. MIT and several other institutions of higher learning have also implemented SAP to run their fundamental operations.

The cost of SAP’s R / 3 for a mid-sized company averages about $750,000, but the implementation costs can be many times the software costs. Typical costs for a full-ﬂedged Fortune 500 ﬁrm can typically run about $30 million in license fees and $100–200 million in consulting fees (Kirkpatrick 1998). SAP was the ﬁrst to institute a University Alliance, which fosters the teaching of business courses that use R / 3. SAP invests about 20–25% of its revenues in R&D. This represents an amount greater than all the other ERP vendors combined and ensures that it should be able to respond rapidly to changes in the ERP market.

Of the other ERP vendors, Oracle is in the odd position of being the second-largest software company in the world next to Microsoft and being second to SAP in the area of ERP tools. One reason for this is the fact that Oracle is the preferred database engine for SAP and so is often even shipped with R / 3 to new clients. However, Oracle has begun to compete more aggressively with SAP with respect to its ERP tools. Initially, it focused on developing ﬁnancial application modules and targeted the smaller to mid-sized corporate market. In the last several years, it has either devel- oped application modules in-house or purchased smaller software development ﬁrms, so that they now can compete with SAP on the entire ERP spectrum. In addition to its enterprise-wide ﬁnancial applications, Oracle has recently rolled out an Internet Procurement Suite, Oracle Exchange Suite, and the Oracle Customer Relationship Management (CRM) package. Of all the ERP vendors, it was the ﬁrst to aggressively extend the ERP functions to e-commerce. As such, 19 of the top 20 e- businesses (e.g., Amazon.com, eBay, Barnes & Noble, and CDNow) use Oracle ERP software. One indicator of this strategy is that in 1988 it was the ﬁrst to allow users to access their enterprise ISs from a standard web browser. Many venture capitalists reportedly refuse to fund an Internet start-up unless Oracle is a part of the business plan (Stroud, 1999).

PeopleSoft Inc. made its niche in the ERP market by being the company that disaffected SAP users could turn to as an alternative. When it was founded in 1987, it was a vendor of software for the human resource (HR) function. It has since focused on this application in the ERP market, while SAP has focused on inventory management and logistics processes. The quality of PeopleSoft’s HR modules was such that some companies would adopt SAP for part of their processes and PeopleSoft speciﬁcally for their HR processes. Because it was more ﬂexible in its implementations, PeopleSoft won over customers who just wanted a partial ERP installation that they could integrate more easily than with their existing systems. PeopleSoft was perceived as being more ﬂexible and cost-effective because it developed its whole ERP software suite by collaborating with ﬁrms like Hyperion, Inc. for data warehousing, data mining, and workﬂow management applications. Once PeopleSoft got into a company with its HR applications, it then began offering the ﬁnancial and other ERP software modules. This led to rapid growth; 1992 revenues of $33 million grew to $1.4 billion in 1998 (Kirkpatrick 1998). Along with the rest of the ERP software industry, PeopleSoft has been scrambling to extend its ERP offerings to the Internet. In 1999, it began development of eStore and eProcurement, and it acquired CRM vendor Vantive (Davis 1999).

Baan Software, a Dutch ﬁrm, was an early player in the ERP software market, shipping its ﬁrst product in 1982. It was the ﬁrst ERP vendor to focus on an open UNIX computing environment in 1987. Its early strengths were in the areas of procurement and supply chain management. Through internal development and acquisitions, Baan offers one of the most complete suites of ERP tools, including accounting, ﬁnancial, and HR applications in one comprehensive package or separately for functional IS development. Shifting toward an Internet focus, Baan has recently acquired a number of tool development ﬁrms and entered into an alliance with Sun for its Java-based software. It is also moving aggressively to integrate XML-based middleware into its next release of BaanERP (Stedman 1999a).

J.D. Edwards began in 1977 as a CASE tool vendor but developed its own suite of ERP appli- cations, primarily for the AS / 400 platform. Its modules now include manufacturing, distribution, ﬁnance, and human resources. The company emphasizes the ﬂexibility of its tools and has risen quickly to be fourth-largest ERP vendor, with nearly $1 billion in 1998 sales (Kirkpatrick 1998). It has been an aggressive ERP vendor in moving to the ERP Outsourcing model, where ﬁrms access the J.D. Edwards software over a secure network link to an offsite computer. This means ﬁrms’ pay a ﬁxed monthly fee per user and don’t have large up-front investments in expensive implementations and software and skills that are rapidly out of date. This network-distribution-based outsourcing model for ERP vendors has yet to be validated, though, and presents many potential technical problems.

Basic Concepts of Enterprise Tools

As one reads the literature on ERP tools, it quickly becomes apparent that very little academic research has been performed to in this rapidly emerging area. The ﬁeld, for the most part, is deﬁned by a few case studies, and research consists primarily of industry publications (Brown and Vessey 1999). Articles appearing in industry publications generate many new terms, which the authors seldom deﬁne, and they also tend to over-hype new technology. Various ERP-related terms have been put forth, including ERP tools, ERP integration tools, ERP network tools, ERP security tools, ERP software, and ERP system. Some vendors are also trying to move away from the term ERP to the term enterprise planning (EP) and even extended resource planning (XRP) systems (Jetly, 1999). As mentioned earlier, enterprise resource planning (ERP) is a term used by the industry to refer to prepackaged software tools that can be conﬁgured and modiﬁed for a speciﬁc business to create an enterprise IS. Common enterprise-wide processes are integrated around a shared database. Although mainframe versions of ERP tools exist, for the most part ERP tools assume a client / server platform organized around a centralized database or data warehouse. The essential concepts that generally deﬁne ERP tools include integration of application modules, standard user interfaces, ‘‘process view’’ support, integrated database with real-time access, and use of an ‘‘open’’ system architecture usually built around a client / server platform.

ERP and the ‘‘Process View’’

Another common feature of ERP tools / systems is that they usually involve the extensive application of business process reengineering (Curran and Ladd 2000). This process is often very painful because it may require an organization to reexamine all of its core processes and redesign whole departments. The ERP tool chosen actively supports this ‘‘process view.’’ In this sense, a process can be thought of speciﬁed series of activities or a way of working to accomplish an organizational goal. To be properly supported by an ERP tool, processes have a deﬁned structure and order and identiﬁable inputs and outputs. This process view is in contrast to the more traditional functional view, where processes are broken down into activities that lack integration. ERP tools offer further support for the process view of an organization by building into the system standard business processes such as order management or shipping scenarios. These scenarios are then used as the basis for conﬁguring and customizing an ERP system for the speciﬁc company. Certain vendors go so far as to try and capture the ‘‘best practices’’ within whole industries, such as the pharmaceutical industry, and use these as models for implementing ERP systems within that industry. Beneﬁts include streamlined business processes, better integration among business units, and greater access to real-time infor- mation by organizational members. For many organizations, movement to an ERP-based IS is seen as one way to use computer technology to provide substantial gains in productivity and speed of operations, leading to competitive advantage (Davenport 1998).

ERP and the Open Systems Architecture

It is clear that one of the reasons ERP tools became so successful was that they were able to take advantage of improvements in the client / server architecture and in middleware. The general move- ment to the client / server platform in the late 1980s meant that ﬁrms could reduce the cost of a highly centralized conﬁguration in favor of a more ﬂexible client / server setup. The C / S conﬁguration pre- ferred by most ERP vendors is that of the standard three-tier C / S platform, which consists of a presentation server, connected to the application server, which is in turn connected to the database server. The ‘‘3’’ in SAP’s R / 3 product name even refers to this three-tier platform, as opposed to the old R / 2 mainframe product.

ERP systems take advantage of new developments in middleware that make it feasible to distribute applications across multiple, heterogeneous platforms. This means that ERP applications can be running on different operating systems and can be accessing data stored in various formats on different database servers worldwide. The middle-ware built into such ERP packages such as SAP and PeopleSoft contains all the communication and transaction protocols needed to move the data back and forth from the database server to the presentation server. The ultimate goal of this is that the movement of data across the varied platforms be transparent to the user, who comes into the ERP applications via a common graphical user interface or even a standard browser interface for e- commerce extensions to the enterprise ISs.

ERP Application and Data Integration

ERP packages include software for a wide range of applications, ranging from purchase orders to accounting and procurement to warehousing. They grew out of the need to plan, manage, and account for resources in manufacturing environments. In recent years, their functionality has grown in both breadth and depth. As companies integrate business units through consolidation or global operations, their information technology’s ability to support these changes is often challenged. The broad func- tionality of the ERP applications allows companies to replace much of their systems with ERPs, providing better support for new business structures and strategies. The great appeal of ERPs is that employees enter information only once and that information is then available to all applications company-wide. Activities tracked or triggered by the ERP software are also automatically captured in the enterprise’s accounting general ledger, without the risk of reentry errors. This means that IS reports throughout a company are based on accurate, real-time information. The value of this is borne out by the large amounts of money that multinational ﬁrms are willing to pay to implement ERPs.

An ERP tool provides companies with a standard interface for all of a ﬁrm’s IS applications, a feature that may be lacking with the older legacy application systems. This has become even more important with rise of CRM and the movement of ERP toward Web-enabled enterprise applications. Although standard, SAP’s R / 3 interface is famous for some confusing and complicated aspects. Research on an improved user interface is continuing, and the new versions are much improved and more intuitive. For e-commerce extensions to ERP-based ISs, users will soon be able to navigate using a standard web browser such as Microsoft’s Internet Explorer. Soon users will also have the option of accessing their ERP-based ISs using wireless, pen-based, hand-held computers (Marion 1999b).

Standard Enterprise Tool Applications

When companies look to implement an IS with an ERP tool, they typically analyze their functional requirements, technical integration issues, costs, and strategic issues. With respect to analyzing the functional requirements of a company and comparing them to the functionality of the various ERP tools available, this task is clouded somewhat by several factors. First, with the ERP emphasis on supporting core business processes, designers must be more knowledgeable about how all the cor- porate processes ﬂow into each other, from creating a sales document (i.e., report) all the way to maintaining records of employee proﬁles. Beyond this, with the new emphasis on business plans that integrate alliance partners and customers more closely, a company must move its focus away from a strictly intraorganizational one to an increasing awareness of transorganizational needs. Both of these needs are further complicated by the fact that each vendor deﬁnes the standard business pro- cesses in different ways and hence the component architectures of their software reﬂect a different set of conﬁgurable components. Also, within the different vendor packages there are varying degrees of overlap in the functionality of each of the modules. This makes it very difﬁcult to compare the functionality of speciﬁc modules from different vendors and how much of them will be able to be integrated into existing systems. The functionality varies, making it difﬁcult to do a proper comparison of the purchase cost and implementation cost of the modules. This problem is further complicated when one considers the different sets of ‘‘industry solutions’’ that ERP vendors push as ways of smoothing the implementation process.

One way to get around some of the problems in making comparisons of ERP tool functionality is to try to translate a particular company’s needs into a generic set of core processes, such as order management, inventory management, and so forth. Companies may then go through several iterations of attempting to map each vendor’s modules to those requirements until the desired level of func- tionality has been met. In this way, some of the gaps and overlaps will become more apparent. Further requirements, such as those related to technical, cost, support, and data integration can be overlaid onto the matrix to reﬁne the comparison further. This section examines the four standard core business processes that almost all ERP tools are designed to support. These processes include the sales and distribution processes, manufacturing and procurement, ﬁnancial management, and

human resources. Each ERP package deﬁnes these processes slightly differently and has varying degrees of functionality, but all tend to support the basic processes presented here with various combinations of modules.

Sales and Distribution Applications

With the advent of newer, more customer-oriented business models such as Dell’s ‘‘build to order’’ computer manufacturing model, it is increasingly important for companies to take customer needs into account and to do it in a timely fashion. ERP tools for supporting sales and distribution are designed to give customers a tighter linkage to internal business operations and help to optimize the order management process. The processes that are most typically supported by the sales and distri- bution (sales logistics) ERP modules include order entry, sales support, shipping, quotation genera- tion, contract management, pricing, delivery, and inquiry processing. Because the data and functional applications are integrated in a single real-time environment, all the downstream processes, such as inventory management and production planning, will also see similar improvements in timeliness and efﬁciency.

When companies adopt a particular ERP vendor’s package, they often begin with the sales and distribution model because this is the beginning of the business cycle. ERP customers are given a variety of different sales scenarios and can choose the ones that most closely mirror how they would like to run their sales processes. Then they can conﬁgure that module to reﬂect more accurately the way they want to support their sales processes. If they need to modify the module more substantially, they will have to employ programmers to customize the module and possibly link it to existing custom packages that they wish to keep. Whichever approach they choose, the generic sales processes that are chosen by the ERP customer can be used as a good starting point from which to conduct user requirements interview sessions with the end users within the company.

One example of a typical sales process that would be supported by an ERP sales and distribution module is the ‘‘standard order processing’’ scenario. In the standard scenario, the company must respond to inquiries, enter and modify orders, set up delivery, and generate a customer invoice (Curran and Ladd 2000). The system should also be able to help generate and manage quotes and contracts, do credit and inventory availability checks, and plan shipping and generate optimal transportation routes. One area that does distinguish some of the ERP packages is their level of support for inter- national commerce. For example, SAP is very good in its support for multiple currencies and also international freight regulations. Their sales and distribution module will automatically perform a check of trade embargoes to see if any particular items are blocked or are under other trade limits for different countries. They will also maintain international calendars to check for national holidays when planning shipping schedules. This application is also where customer-related data are entered and corresponding records maintained. Pricing data that is speciﬁc to each customer’s negotiated terms may also be a part of this module in some ERP packages (Welti 1999).

Other sales processes that might be considered a part of the sales and distribution module (de- pending on the particular ERP product) include support for direct mailing campaigns, maintenance of customer contact information, and special order scenarios such as third party and consignment orders. With the rapid growth of the newer CRM software packages, much of the support for these processes is now being moved to the Internet. E-mail and Web-based forms enabling customer input mean that ERP sales and distribution modules will have to evolve rapidly along CRM lines. Currently, the most advanced with respect to this type of web integration is the ERP package from Oracle, but the other vendors are moving quickly to enhance their current sales and distribution module func- tionality (Stroud 1999).

Manufacturing and Procurement Applications

Certainly the most complex of the core business processes supported is the large area generally called manufacturing and procurement. Because ERP tools grew out of MRP II and its precursors, these modules have been around the longest and have been ﬁne-tuned the most. The suite of ERP modules for this application is designed to support processes involved in everything from the procurement of goods used in production to the accounting for the costs of production. These modules are closely integrated with the ﬁnancial modules for cash ﬂow and asset management and with the sales and distribution modules for demand ﬂow and inventory management. Key records maintained by these application modules include material and vendor information.

Among the supply chain activities, the manufacturing and procurement applications handle ma- terial management, purchasing, inventory and warehouse management, vendor evaluation, and invoice veriﬁcation (Bancroft et al. 1998). These activities are so complex that they are typically divided up among a whole suite of manufacturing modules, such as in SAP’s R / 3, which consists of materials management (MM), production planning (PP), quality management (QM), plant maintenance (PM), and project management (PM). These various modules can be conﬁgured in a wide variety of ways and can accommodate job shop, process-oriented, repetitive, and build-to-order manufacturing envi-

ronments. The PM module is designed to support the management of large, complex projects, such as shipbuilding or special construction projects. Also, despite being oriented more towards large manufacturing enterprises, ERP vendors have made great strides in modifying these modules to accommodate the special needs of service industries such as education and government.

With respect to procurement processes, ERP tools can be used to conﬁgure the desired IS in many ways, but they are generally built around a standard procurement scenario. Whether a company must procure subcontract work, consumable goods, or material for their day-to-day production stock, the chain of procurement activities is somewhat similar. These activities involve recognizing a ma- terial need, generating a purchase requisition, sending out RFQs to approved vendors, choosing a vendor, receiving and inspecting the goods, and verifying the vendor invoice (Curran and Ladd, 2000). In this area, many companies already use EDI effectively to support their procurement processes, and so most ERP tools are equipped to support standard EDI transactions. The growth of the Internet and extended supply chain management means that ERP tools are increasingly linked directly to their preapproved vendors to further shorten the procurement cycles.

Accounting and Finance Applications

Like the other core business activities, accounting has been undergoing a total reorientation towards a more process-oriented view of the enterprise. Most ERP tools support the accounting and ﬁnancial processes with another suite of modules and submodules. These include general ledger, AR / AP, asset management, controlling, taxation, and cash ﬂow projection. The more robust ERP packages support accounting for multiple divisions, across multiple currencies, and also support consolidation of ﬁ- nancial statements across countries and divisions. Again, because of the integrated nature of all the ERP applications and data, the output from these modules is generated in a much more efﬁcient and timely manner than in the older, legacy systems. The key, of course, is to make sure that the data are highly accurate when it is entered into the system. The downside of data integration is that inaccurate data can be spread through many different applications’ reports.

A large part of the accounting and ﬁnancial activities in an enterprise is the efﬁcient processing of vendor payments and the posting of payments in the correct order into the various ledger accounts. This can be done automatically via EFT or manually in an ERP system, depending on the preferences of the vendor or customer. One of the outputs from the procurement process is a vendor-produced invoice, and this input is the usual starting point for the external accounting activities. Once the invoice is entered either via EDI, manual entry, or even scanning, the invoice is posted to the appro- priate account and the amount is veriﬁed by matching it with a purchase order and any other partial payments. Once veriﬁed, a payment release is issued and payment is issued either electronically or manually. On the customer side, the accounting module also maintains the customer credit records and generates dunning notices (i.e., reports) according to a predeﬁned dunning procedure for each individual customer. The ERP application system will also automatically add on any interest or processing charges that are deﬁned as part of the sales contract for that particular customer. As payments are received and entered into the system, it applies them to the appropriate invoice and moves them to the appropriate GL account.

Most ERP tools also support a variety of management accounting activities. The largest part of these internal accounting activities center on cost management and proﬁtability analysis. Depending on the type of organization, costs can be collected as a byproduct of procurement and production and the system can be conﬁgured to generate cost estimates, simultaneous production costing, and also ﬁnal costs for a period or a project. These costs can be further analyzed and broken down by organizational unit and by speciﬁc product or project. Proﬁtability analysis can likewise be conducted at various points in the process and be broken down by organizational unit and product or project. One must bear in mind that with a properly conﬁgured suite of ERP ﬁnancials, the data that are collected and analyzed for these controlling reports are very timely and generating the reports can be done much more efﬁciently than previously. Analysis can also be conducted across international divisions of the company and whole product lines.

Human Resource Applications

Typically the last set of business processes to be converted to an ERP system, HR applications have recently become very popular as companies look to areas where they might be able to gain a com- petitive advantage within their respective industries. Because of this, there has been substantial im- provement in the HR modules of the leading ERP vendors. This improvement in turn has led to a substantial second wave of ERP implementations among those early adopters, who may have only adopted the ﬁnancial and manufacturing or sales modules in the ﬁrst wave of ERP implementations (Caldwell and Stein 1998).

In most organizations, HR too often has become a catchall for those functions that do not seem to ﬁt elsewhere. As a result, HR typically houses such disparate functions as personnel management, recruiting, public relations, beneﬁt plan management, training, and regulatory compliance. In ERP applications, the HR modules house the employee data and also data about the current organizational structure and the various standard job descriptions. The latest wave of ERP tools now supports most of these activities in a growing suite of HR modules and submodules. For example, personnel man- agement includes the recruitment, training and development, and compensation of the corporate workforce. Typical recruitment activities include realizing the internal need for new personnel, gen- erating a job description, posting advertisements, processing applicants, screening, and selecting the ﬁnal choice for the position. Once the position has been ﬁlled, then training assessments can be done and a beneﬁt and development plan can be implemented. Other core processes in the HR module include payroll processing, beneﬁts, and salary administration; sometimes they include time and travel management to help employees streamline reimbursement for travel expenses.

Implementing an Enterprise System

Because of the large investment in time and money, the selection of the right enterprise tool has a tremendous impact on the ﬁrm’s strategy for many years afterward. Choosing a particular ERP package means that a company is entrusting its most intimate core processes to that vendor’s software. This is a decision that cannot be easily reversed after it has been made. Some ﬁrms have chosen to implement an ERP package not realizing the extent of the commitment involved and then had to stop the project in the middle (Stedman 1999b). This is often because these companies are unwilling to reexamine their core processes to take advantage of the integrated nature of an ERP package.

What makes choosing an ERP package different from other types of organizational computing decisions? As discussed above, the large scale and scope of an ERP system make it even more critical than local or functional IS applications for the well-being of the enterprise, apart from the high-cost issue. It is also different in that it is oriented towards supporting business processes rather than separate islands of automation and so the typical implementation involves business experts more than technology experts as opposed to traditional system implementations. The process-oriented nature of an ERP implementation also means that cross-functional teams are a large part of the design process. Because of the high potential impact on an organization due to the redesign of core business processes and reduction of the labor force needed for these processes, one of the more subtle differences is that end users may ﬁght the changes brought about by an ERP system. Therefore, project leaders must also be skilled in ‘‘change management’’ (Davenport 1998).

Choosing an Enterprise Tool

Given that an ERP implementation is so risky to an enterprise, what should a ﬁrm consider when choosing an ERP tool? There are currently a handful of case studies in the academic literature and numerous anecdotal references in the trade literature. From these we can derive some factors that a ﬁrm should take into account. Probably the most important criterion is how well the software func- tionality ﬁts with the requirements of the ﬁrm. A ﬁrm could develop a matrix of its core business process requirements and then try to map the modules from the various ERP packages to the matrix to see where obvious gaps and overlaps might exist (Jetly 1999). A byproduct of this analysis will be a better understanding of the level of data and application integration that the package offers. Increasingly, the ERP package’s support for electronic commerce functions will be a major factor in choosing the right package.

Beyond an analysis of the ERP package functionality, a ﬁrm must also take technical factors into consideration. Each package should be evaluated for the ﬂexibility of the architectures that it supports and its scalability. How well will this architecture ﬁt with the existing corporate systems? How many concurrent users will it support and what is the maximum number of transactions? Will the module require extensive modiﬁcations to make it ﬁt with our business processes and how difﬁcult will it be to change them again if my business changes? Given the potential complexity of an ERP implemen- tation, potential users should be concerned about the ease of use and amount of training that will be required for end users to get the most out of the new system. ERP vendor-related questions should center on the level of support that is offered and how much of that support can be found locally. They should also look into the overall ﬁnancial health and stability of their prospective ERP vendors and the scope and frequency of their new product releases and updates.

With respect to cost, several factors should be kept in mind when choosing an ERP package. First is the cost of the software and hardware itself that will be required. Besides the required number of new database and application servers, hardware for backup and archiving may also be required. Software costs are typically on a per-module basis and may vary between modules, but a ﬁrm may also have to purchase the submodules in order to get the desired functionality. If these modules need to be customized or special interfaces with existing systems need to be programmed, ﬁrms should consider the amount of customization required. This cost is exaggerated for some ERP packages, such as SAP’s R / 3, which require knowledge of the rather exotic proprietary language ABAP / 4 in order do extensive customization. Training and ongoing support for these packages will be a contin- uing expense that should also be considered.

Enterprise System Implementation Strategies

With the high cost of implementing an enterprise information system, developers are under pressure to build them as quickly as possible. Given that the actual system development costs can typically range from 2–10 times the actual cost of the software and hardware (Doane 1997), many ERP consulting ﬁrms have sprung up to service this market. Of course, each of them has its own meth- odology which it claims to be faster and more efﬁcient than the other’s. Most of these methodologies represent some variation of the traditional phased systems implementation, so this will be discussed here. Another current ERP debate is the relative merits of the ‘‘big bang’’ conversion strategy as opposed to a slower, phased conversion (Marion 1999a).

Because of the strategic nature of ERP decisions, they are usually made at the top executive level. To help coordinate an ERP implementation, ﬁrms often create a steering committee with some top executives and high-level management from each of the affected divisions of the ﬁrm. The committee will determine the initial scope of the ERP implementation and also which area of the ﬁrm will act as a test bed for debugging the initial IS, assuming the ﬁrm does not choose to do a big bang implementation. As a result, a ﬁrm may choose to begin with the sales and distribution module in its marketing department and expand from there. A project team consisting of IS professionals and end users should then be formed. This team will work in conjunction with the steering committee. Studies show that the importance of the project leader cannot be underestimated and that this person should have strong leadership skills and some experience in implementing an ERP-based IS (Bancroft et al. 1998).

It is the project team’s job to analyze the current business processes that will be the focus of the ERP-based IS and look at the existing hardware and software along with the existing data and interfaces. In order to explore the ERP software functionality in more detail, ﬁrms sometimes map the initial business processes to the chosen ERP package and do a limited test installation. After exploring the ERP package, the project team will come up with a detailed new design of the business processes in question and a prototype system may be developed and tested by users. Once the prototype has been accepted by users, then the complete ERP-based IS application will be developed and implemented and the data migration will take place. Once the IS has been rolled out for the initial application, it will be expanded to include the rest of the enterprise applications that have been

identiﬁed in the initial scope of the project. It should be noted that most ERP packages support this development process with built-in CASE tools, standard process scenarios and scripts, and possibly a set of recommended ‘‘best’’ practices for speciﬁc industries.

As an alternative to this phased approach to ERP implementation, some ﬁrms choose the big bang approach, which is riskier but less expensive, in which a ﬁrm shifts its entire application for the whole ﬁrm from its old legacy system to its new ERP application. This is a high-risk implementation method because the resulting system may have so many bugs that chaos may result, after which it may take months for the ﬁrm to recover. An example of the potential problems occurred in the fall of 1999 when Hershey’s tried to implement its ERP inventory application using the big bang approach and lost over $100 million due to its failure to manage inventory properly (Stedman 1999b). However, there have been big bang success stories at McDonalds Corp. and Rayovac, and perhaps the beneﬁts of this approach can outweigh the risks (Marion 1999a). Some of the beneﬁts include lower cost because it requires less expensive consultant time. It also reduces the amount of interface development with the old legacy systems because there is no temporary connection to maintain with the new ERP applications. The other problem with the long phased approach is that when one application is ready, updated versions of the ERP software are available for other applications when they are ready to be rolled out, and then developers must deal with a whole new set of compatibility and conversion issues.

Critical Success Factors for ERP Implementations

From the various case studies reported in the trade literature, several key factors have been reported that seem critical for the success of an ERP implementation (Bancroft et al. 1998). These include:

1. Management support for making the hard decisions

2. Capability and readiness of the organization for making changes

3. A balanced project team with strong leadership

4. Reasonable project scope

5. The right ERP package

6. The right implementation method

7. A strong training plan for users and the project team

The most commonly cited of these factors is the importance of management support for the success of the project. This factor has been widely documented for other types of business computing projects, but it is especially important in implementing an ERP system because this may involve a radical redesign of some core processes and resulting major changes in the organization. In a project as complex as an ERP system, problems will occur. Leaders must maintain the strong vision to persevere through all the changes. One study showed that nearly 75% of new implementations resulted in some organizational change, and these changes could be very severe (Boudreau and Robey 1999). Project teams should also be balanced with respect to business area experts and IS professionals. As the software becomes easier to conﬁgure and has more complete functionality, it seems clear that the trend of shifting more responsibility away from the IS professionals to the business experts will continue (Bancroft et al., 1998). Because of the cross-functional nature of ERP-based ISs, it is also important that team members be drawn from multiple business units and assigned full-time to the project (Norris et al., 1998).

Future of Enterprise Tools

The new generation of enterprise tools is beginning to enable large corporations to reap signiﬁcant gains in efﬁciency and productivity, but the investment costs of implementing an ERP system can be a huge hurdle for smaller companies. Enterprise tools will continue to improve in overall func- tionality and ease of use as modules are developed and reﬁned. The functionality will continue to be extended to the customer, supplier, and other business partners in what some call the Extended Resource Planning (XRP) software generation (Jetly 1999). Most of these extensions are based on some form of e-business model using the Internet. A description of some of the principal newer enhancements to ERP systems follows. These are taking enterprise ISs into the transorganizational realm.

Enterprise Tools and Supply Chain Management (SCM )

One logical outgrowth of the increased integration of enterprise-wide data and support for core business processes is the current interest in supply chain management. In the 1980s, much of the focus in manufacturing was on increasing the efﬁciency of manufacturing processes using JIT, TQM, Kanban, and other such techniques. Given the large investment in these improvements in manufac- turing strategies, companies managed to lower the cost of manufacturing goods as far as was practical. These same companies are ﬁnding that they can take a system view of the whole supply chain, from suppliers to customers, and leverage their investment in ERP systems to begin to optimize the efﬁ- ciency of the whole logistics network. In this context, supply chain management is deﬁned as follows:

A set of approaches utilized to efﬁciently integrate suppliers, manufacturers, warehouses, and stores, so that merchandise is produced and distributed at the right quantities, to the right locations, and at the right time, in order to minimize system-wide costs while satisfying service level requirements (Simchi-Levi et al. 2000).

Until recently, ERP vendors have focused their efforts on providing real-time support for all the manufacturing transactions that form the backbone of the supply chain and left the more focused decision support applications to software companies such as i2 Technologies and Manugistics. These companies have produced whole families of decision support systems to help analyze the data pro- duced by the ERP-based IS and make better decisions with respect to the supply chain. The interfaces between the standard ERP tools and the new generation of DSSs is where some of the most interesting and valuable research and development is being conducted. As companies improve their support of speciﬁc supply chain activities, they can expand the level of integration to include supporting activities from ﬁnancial operations and human resources.

When taking a supply chain view of its operations, a company must begin with the notion that there are three basic ﬂows within their enterprise: materials, ﬁnancials, and information. At deﬁned points in the supply chain, data can be collected and stored. The goal of ERP-based ISs in this view is to enable the enterprise to collect and access this information in a timely fashion. This reduces inventory levels, reduces costs, and improves customer service and satisfaction, and each product produced by the enterprise will also have an accompanying information trail that can be tracked and used for planning and estimating lead times. It must be kept in mind that this integrated information ﬂow is available in real time as a basis for decision making.

Much of the recent interest in supply chain management and ERP stems from the e-business models that have been emerging. These models now call for tighter linkages between suppliers and customers, and the ERP tools must support these linkages. This extended supply chain management makes use of the Internet to link with suppliers and customers via standard browsers and TCP / IP protocols. This means that not only will customers be able to track their orders, but companies will be sharing inventory and BOM information with their suppliers. In fact, one of the major unresolved issues in ERP research is the question of inter-ERP linkage. Most vendors have their own standard format, and until there is general agreement within the industry, inter-ERP data sharing will require the development of sophisticated middleware to share data between ISs at companies using different vendors’ ERP tools (Simchi-Levi et al. 2000).

Enterprise Tools and Customer Relationship Management (CRM )

As ERP vendors continue to extend the functionality of their packages, one area where there has been tremendous growth has been in the ability of the software to support a company’s links to its clients. Interest in better supporting these linkages has led to the development of a niche software market called customer relationship management (CRM) software. CRM supports business functions typically performed by marketing, sales, and service. CRM software is designed to support these functions by helping to identify, select, develop and retain customers. With the recent move to e- business, the traditional view of CRM has changed to look to how CRM software can be combined with electronic commerce technology to gain a competitive advantage. This means that new CRM software helps to move existing processes such as order entry to the Internet and supports new processes such as email-based customer support. Companies are now revising their business strategies to take advantage of Web-enabled CRM software to support Web marketing and customer interaction. Besides supporting sales staff, the new breed of CRM software supports a ‘‘contact center,’’ which is a focal point of phone, Web, e-mail, ATM, and kiosk customer interactions. These front-ofﬁce activities then must be linked in real time to back ofﬁce functions that fall into the domain of the traditional ERP package.

While the predictions for the maturing ERP market indicate that its growth rate is slowing, the market for CRM software is just starting to explode. One industry analyst has predicted that the market will grow at an annual growth rate of 49% over the period from 1999–2003, when it will reach $16.8 billion in sales (Bowen, 1999). Of this market, the top vendors in 1998 were Siebel Systems, Vantive, and Clarify, who together represent 40% of the CRM tool market. Siebel became the market leader by changing its focus from client / server sales force automation applications to developing an integrated, Web-based CRM suite, with sales, marketing, and customer modules. It has generated more than 50 partnerships with industry giants, such as the recent alliance with IBM. With strategy, their revenues increased from $36 million in 1996 to $329 million in 1998 (Zerega 1999).

Because of the immense potential of the CRM market and because it ﬁts well with their attempts to turn their product lines toward an e-business orientation, all the major ERP vendors are now looking to expand into the front-ofﬁce domain. ERP vendors are doing this by acquiring CRM vendors, developing alliances with pure CRM vendors, developing their own packages, or as in the case of SAP, a combination of these. In October of 1999, Peoplesoft announced that it was acquiring one of the leading CRM vendors, Vantive. Similarly, Baan has already purchased Aurum Software and has formed an alliance with Cap Gemini to integrate its CRM applications into BaanERP (Gold- baum 1999). Of the top ﬁve ERP vendors, Oracle is the only one currently offering a front-ofﬁce system. It is ahead of the ERP market in developing a suite of Web-enabled CRM applications that integrate easily with its tools for back-ofﬁce enterprise systems. It has aggressively pursued alliances with hardware vendors such as HP to allow Oracle and HP salespeople to collaborate and share information over the Internet (Stroud 1999). In this way, it cosells its CRM solutions and shares customer data. Oracle also announced in March of 1999 that it would integrate its CRM suite with SAP’s ERP tools (Sykes 1999). In contrast, SAP does not currently offer a CRM module for its product, R / 3.

SAP is the ERP market leader with the most comprehensive and integrated package of ERP applications. Yet it is seen as being late to move its focus to Web-enabled enterprise application systems. In the fall of 1999, it unveiled its long-awaited MySAP.com and is attempting to use its large client base of active installations for leverage into the CRM market. Given its huge investments in R&D, SAP has never been inclined to purchase niche players in related software markets but has preferred to develop its own tools in-house. With respect to CRM tools, its eventual plan is to package CRM modules as a part of its new MySAP.com architecture for e-business portals (Bowen 1999). It will be browser-based, using Microsoft’s Internet Explorer, and will provide seamless access to R / 3’s enterprise-wide applications. Although SAP has yet to deliver its own CRM modules, it is predicting that CRM-related revenues will eventually outpace revenues from sales of ‘‘pure’’ ERP packages (Bowen 1999).

Because of its huge growth potential, the CRM market is very dynamic, with a stream of new entrants and the expansion of current CRM vendors’ tools. With respect to ERP packages, the trend is toward the eventual blending of ERP with CRM modules. This will occur as the major ERP vendors continue to turn their focus toward e-business. It is expected that this new amalgam of front- ofﬁce with back-ofﬁce applications will lead to a seamless new set of IS development tools called ‘‘e-business suites’’ (Goldbaum 1999).

Enterprise Tools and Electronic Commerce (EC )

As the ERP market has matured, ERP vendors have rushed to be the ﬁrst to redesign their products so that they Web-enable their enterprise tools. The rapidly evolving model of ERP and e-commerce means that users anywhere in the world will be able to access their speciﬁc enterprise-wide ISs via a standard, browser-based interface. In this model, the ERP platform deﬁnes a new suite of e-business modules that are distributed to suppliers and clients using the standards of the Internet. The ERP tool can thus be used to build an e-business ‘‘portal’’ that is designed speciﬁcally for everything from small ‘‘e-tailers’’ to large multinational corporations. This portal will streamline links with customers, suppliers, employees, and business partners. It will extend the linkage between the enterprise and transorganizational classes of ISs.

One way that this model is emerging is as a turnkey supplier of e-business function support. For example, SAP’s new web portal model, MySAP.com, can be used to help a new e-tailer design and build its website. Using an innovative natural language interface, a business person can describe the features he or she wants for the company website and a basic web page will be automatically generated. The website will be further linked with whatever functionality is desired from the back- ofﬁce enterprise IS, via the Web-enabled suite of modules in MySAP.com. These modules might include processing customer orders, creating and maintaining a corporate catalog for customers to browse, processing bank transactions, monitoring customer satisfaction, and allowing customers to check the status of their orders. The same platform can be used to maintain the company’s business- to-business applications, such as eProcurement and information sharing with business partners and clients. For a fee, MySAP.com users can ‘‘rent’’ back-ofﬁce decision support software for forecasting, data mining, and inventory planning and management. These services are delivered over the Internet and users pay on a per-transaction basis. This web portal also serves as the platform for business- employee transactions, helping employees communicate better, monitor their beneﬁt plans, plan for and receive training, and possibly provide more advanced knowledge management support.

Search This Blog

Operation Research course