ENTERPRISE RESOURCE PLANNING SYSTEMS IN MANUFACTURING:AN INTERNAL VIEW OF ERP SYSTEMS

AN INTERNAL VIEW OF ERP SYSTEMS

This section describes what ERP systems do and how they do it. Sections 2.1 through 2.3 describe the core functional elements of ERP systems: human resource management, ﬁnance management and accounting, contracts management, materials acquisition, materials inventory, maintenance manage- ment, order entry and tracking, manufacturing management, process speciﬁcation management, ware- housing, and transportation. Sections 2.4 through 2.6 describe implementation aspects, particularly ERP systems architecture, conﬁguration management tools, and Internet interfaces.

Scope of ERP Systems in Manufacturing Enterprises

As illustrated in the portion of Figure 2 bounded by the gray box, the functionality of ERP systems encompasses certain interactions among the following elements:

• Four categories of resources (inventories, facilities / equipment, labor, and money)

• Two generic activities (planning / decision support and execution / transaction management)

• Three types of manufacturing operations activities (supply, production, and delivery)

• Five major types of physical facilities (stockroom, plant ﬂoor, warehouse, vehicle / depot, and distribution center) through which material ﬂows in manufacturing enterprises

Because there is considerable variation among manufacturers as to which functions in which facilities fall within the scope of an ERP implementation, the gray box does not envelop all physical facilities. Typically, in some way or another, all transactions—all changes of state and many deci-

sions—are captured in an ERP system. Each of these facilities may use additional systems for plan- ning and analysis, execution level scheduling, control, and automated data capture. Some of the planning, analysis, scheduling, and management systems are part of, or tightly connected to, the ERP systems; others are more loosely connected. This variation results from two major factors: systems that are closely coupled to equipment, most of which are highly specialized, and systems that manage information and business processes speciﬁc to a particular industry that the ERP vendor may not offer. Because of the historic emphasis on reducing inventory costs, the management of stockroom is, in almost all cases, an intrinsic part of an ERP system. To the contrary, plant ﬂoor activity control is almost never a part of ERP. Management of execution activities within warehouses, vehicles / depots, and distribution centers may be handled in a centralized fashion by an ERP system or in a decentralized fashion by an applications speciﬁc to those facilities.

Transaction Management and Basic Decision Support: The Core of ERP

Transactions are records of resource changes that occur within and among enterprises. Through the use of a logically (but not necessarily physically) centralized database, it is the management of these transactions that constitutes the core of an ERP system. More speciﬁcally, this transaction database captures all changes of state in the principal resources of the manufacturing enterprise. It also makes elements of the current state available to personnel and software performing and supporting the operations of the enterprise. This scope encompasses all of the numerous resources (i.e., materials inventories, facilities / equipment, labor, and money) and product inventories of all kinds. It also includes the states and results of many business processes, which may not be visible in physical instances (e.g., orders, speciﬁcations). The detailed breakdown of this broad scope into common separable components is a very difﬁcult technical task, given the many interrelationships among the objects, signiﬁcant variations in the business processes, and the technical origins of ERP systems. Nonetheless, it is possible to identify general elements from that complexity and diversity. The functions of a manufacturing enterprise that are supported by transaction management correspond to the major types of resources as follows:

• For inventories, materials inventory and materials acquisition

• For facilities / equipment, manufacturing management, process speciﬁcation management, main- tenance management, warehousing and transportation

• For labor, human resource management

• For money, ﬁnancial management and accounting

• For product, order entry and tracking

These functions, in whole or in part, make up the core of ERP. The following sections describe each function and its relationship to core ERP. These functions are then discussed in terms of ﬁner-grain execution and planning activities.

Materials Inventory

This function is made up of all information on stores of materials and allocations of materials to manufacturing and engineering activities. That includes information on materials on hand, quantities, locations, lots and ages, materials on order and in transit, with expected delivery dates, materials in inspection and acceptance testing, materials in preparation, and materials allocated to particular man- ufacturing jobs or product lots (independent of whether they are in stock).

ERP systems routinely capture all of this information and all transactions on it. It is sometimes combined with materials acquisition information in their component architecture.

Execution activities supported by materials inventory include receipt of shipment, inspection and acceptance, automatic (‘‘low-water’’) order placement, stocking, stores management, internal relo- cation, issuance and preparation, and all other transactions on the materials inventory. Except for some stores management functions, all of these are revenue producing.

Planning activities supported by materials inventory include supply planning, manufacturing plan- ning, and manufacturing scheduling.

Materials Acquisition

This function deals primarily with information about suppliers and materials orders. It includes all information about orders for materials, including recurring, pending, outstanding, and recently ful- ﬁlled orders, and long-term order history. Orders identify internal source and cost center, supplier, reference contract, material identiﬁcation, quantity, options and speciﬁcations, pricing (ﬁxed or vari- able), delivery schedule, contacts, change orders, deliveries, acceptances, rejects, delays, and other notiﬁcations. It may also include invoices and payments. This also includes special arrangements, such as consignment and shared supply schedules.

ERP systems support part of an enterprise’s materials acquisition function by handling all of this information for active suppliers and orders and journalizing all transactions. But they regularly purge closed orders and relationships, using the journal or some other export mechanism to move this information to an archival or data warehouse system. ERP systems generally maintain simple ma- terials speciﬁcations directly but typically carry only references to more complex speciﬁcation doc- uments in some other product data management (PDM) or document management system.

Execution activities supported by materials acquisition include internal requests, placement of external orders and changes, receipt and acceptance of materials, and all other transactions against materials orders. All of these are revenue-producing activities.

Planning activities supported by materials acquisition include supply chain development, supplier identiﬁcation and qualiﬁcation, supply planning, manufacturing planning, and cash-ﬂow projections.

Order Entry and Tracking

These functions focus on the customer order through its life cycle. Order entry is the mechanism by which the decision to make product enters the ERP system. It begins with the capture of customer order, including all speciﬁcations and options, quantities, packaging requirements, and delivery re- quirements. It ends with the creation of one or more corresponding manufacturing orders and delivery orders. At that point it becomes order tracking, which follows the customer order through the ful- ﬁllment processes (for the surrogate orders) and ﬁnally through the payment processes. It is important to note that although manufacturing may be driven directly by customer order, there is a decision point between the entry of the customer order and the release of the associated manufacturing orders, and in most ERP systems they are maintained as separate objects. While this release is often auto- mated, it is a critical business control point and the automation reﬂects the business rules for the release.

The execution activities supported by order entry and tracking include the revenue-producing activities of customer order capture, production start, and delivery start.

The planning activities supported by order entry and tracking include tactical planning for all of engineering, manufacturing, and delivery, according to the nature of the business as described in Section 1.3.2.

Manufacturing Management

This function deals primarily with the tracking of work through the manufacturing facilities and the management of manufacturing resources that are used in performing that work.

The manufacturing resources include personnel, equipment, and materials. Because each of these is also the subject of another ERP domain (human resources, maintenance, inventory), there is always overlap among the concerns. And because many ERP systems developed from manufacturing resource planning (MRP II) systems, which dealt with various aspects of those resources listed above, there is no agreement about where the boundaries are. The one concern that is clearly unique to manufac- turing management is the assignment of resources to speciﬁc work items. But at some level of planning that depends on resource availability and resource capabilities, which are the boundary areas.

The tracking of work begins with tentative and actual placement of manufacturing orders through the order entry component described above. In general, the manufacturing order information is a part of the manufacturing management component. Planning processes determine which resources (ma- terials, equipment, labor) will be assigned to fulﬁlling these orders in which time frames and these assignments are captured. Execution processes draw materials (usually tracked as lots) and use equip- ment and personnel to perform the work. These usages and the ﬂow of work through the facility are captured. Finished goods leave the manufacturing domain for some set of distribution activities, and at this point the completion of the manufacturing orders is tracked.

The execution processes supported by manufacturing management are the revenue-producing pro- cesses that convert materials into ﬁnished goods, but that support is limited to tracking those pro- cesses.

The planning processes supported by manufacturing management are all levels of manufacturing resource planning and scheduling, except for detailed scheduling, as noted above.

Process Speciﬁcation Management

This function deals with the information associated with the design of the physical manufacturing processes for making speciﬁc products. As such, it is an engineering activity and like product engi- neering, should be almost entirely out of the scope of core ERP systems. But because several infor- mation items produced by that engineering activity are vital to resource planning, ERP systems maintain variable amounts of process speciﬁcation data. In all cases, the materials requirements for a product lot—the ‘‘manufacturing bill of materials’’—are captured in the ERP system. And in all cases, detailed product and materials speciﬁcations, detailed equipment conﬁgurations, detailed op- erations procedures, handling procedures, and equipment programs are outside the core ERP infor-

mation bases. These information sets may be maintained by ERP add-ons or third-party systems, but the core contains only identiﬁers that refer to these objects.

For continuous-process and assembly-line facilities, the major process engineering task is the design of the line, and that is completely out of scope for ERP systems. What ERP systems maintain for a product mix is the line conﬁgurations (identiﬁers) and equipment resources involved, stafﬁng and maintenance requirements, the set of products output, the production rates and yields, and the materials requirements in terms of identiﬁcation and classiﬁcation, start-up quantities, prepositioning requirements, and feed rates.

For batch facilities, the major process engineering tasks are the materials selection, the routing (i.e., the sequence of work centers with particular setups), and the detailed speciﬁcations for opera- tions within the work centers. The materials requirements, the yields, and the routings for products and product mixes are critical elements of the ERP planning information. The detailed work center operations are unimportant for planning, and all that is captured in the ERP core is the external references to them, the net stafﬁng and time requirements, and the assigned costs of the work center usages.

For job shop facilities, the major process engineering tasks are materials selection, the routing, and the detailed speciﬁcations for operations within the work centers. The materials requirements and yields for speciﬁc products are critical elements of the ERP planning information. The routing is often captured as a sequence of work center operations—unit processes, each with its own equip- ment, stafﬁng and time requirements, associated detail speciﬁcation identiﬁers, and assigned cost. The detailed unit process speciﬁcations—operator instructions, setup instructions, equipment control programs—are kept in external systems.

No execution processes are directly supported by process speciﬁcation management. All levels of resource planning are directly and indirectly supported by this information.

Maintenance Management

This function includes all information about the operational status and maintenance of equipment, vehicles, and facilities. Operational status refers to an availability state (in active service, ready, standby, in / awaiting maintenance, etc.), along with total time in service, time since last regular maintenance, and so on. The ERP system tracks maintenance schedules for the equipment and actual maintenance incidents, both preventive and remedial, and typically an attention list of things that may need inspection and reﬁt. Any maintenance activities include both technical data (nature of fault, repair or change, parts installed, named services performed, etc.) and administrative data (authori- zation, execution team, date and time, etc.). In addition, this component tracks the schedules, labor, and work assignments of maintenance teams, external maintenance contracts and calls, and actual or assigned costs of maintenance activities.

In those organizations in which machine setup or line setup is performed by a general maintenance engineering group rather than a setup team attached to manufacturing operations directly, it is com- mon to have such setups seen as part of the maintenance component rather than the manufacturing component. Similarly, operational aspects of major upgrades and rebuilds may be supported in the maintenance component of the ERP system. These are areas in which the behavior of ERP systems differs considerably.

This component supports sourcing, manufacturing, and delivery activities indirectly. Maintenance, per se, is purely a support activity.

Planning activities supported by maintenance management include all forms of capacity planning, from manufacturing order release and shipment dispatching (where immediate and expected availa- bility of equipment are important) up to long-term capacity planning (where facility age and statistical availability are important).

Warehousing

This function deals with the information associated with the management of ﬁnished goods and spare parts after manufacture and before ﬁnal delivery to the customer.

For products made-to-stock, this domain includes the management of multiple levels of distri- bution centers, including manufacturer-owned / leased centers, the manufacturer’s share of concerns in customer-owned / leased centers, and contracted distribution services. The primary concerns are the management of space in the distribution centers and the management of the ﬂow of product through the distribution centers. Thus, there are two major elements that are sometimes mixed together: the management of the distribution center resources (warehouse space, personnel, and shipping and re- ceiving facilities) and the management of ﬁnished product over many locations, including manufac- turing shipping areas, distribution centers per se, and cargo in-transport. Distribution center and product (family) includes tracking actual demand experience, projected demand and safety stocks, units on hand, in-ﬂow and back-ordered, and units in manufacture that are earmarked for particular distribution centers. The primary object in product distribution tracking is the shipment because that

is the unit of product management at the factory, in transportation, and through all distribution centers, except possibly the one nearest the ﬁnal customers. For shipments, what is tracked is the product content, the ultimate recipient, the current location, and the associated delivery / shipping orders.

For certain products made-to-order (both made-on-demand and option-to-order), the distribution center approach is used because it facilitates planning and use of delivery resources and usually because a sizable part of the manufacturer’s product line (such as spare parts) is made to stock. In these cases, the information managed is similar to the made-to-stock case, but actual demand and safety stock concerns are replaced by tracking speciﬁc customer orders. Customer orders are part of shipments up to the ﬁnal distribution center, and ﬁnal delivery to customer is tracked from there.

For most products made-to-order, the warehousing component manages information only for ﬁn- ished goods in factory holding areas awaiting shipment and shipments that are in transportation to the customer. In this case, each shipment is associated with a particular customer at creation, and it may be associated with one or more manufacturing orders even before manufacturing starts. For shipments, what is tracked is the product content, the customer order, the current location, and the associated delivery / shipping orders. In many make-to-order cases, the manufacturing holding areas are managed as manufacturing resources instead of warehousing resources, and the shipments are managed as part of order tracking, thus eliminating the warehousing component.

Execution activities supported by warehousing are the revenue-producing delivery of ﬁnished goods via distribution centers and the support activities of distribution center management. The primary planning activities supported by warehousing are distribution planning and distribution re- quirements planning.

Transportation

This function includes all aspects of movement of parts and ﬁnished goods among manufacturing facilities and distribution centers as well as ﬁnal delivery to customers. It can be subdivided into the management of vehicle ﬂeets, transportation service contracts, and shipping orders.

All manufacturers manage shipping orders—the decision to move shipments of parts and ﬁnished goods from one facility to another in the process of fulﬁlling customer orders. What is captured for the order is the associated shipments, the starting and ending locations, the means of transfer, the nominal pickup and delivery times, and the associated authorizations. The means of transfer can be by owned vehicles or transportation service contracts, or a combination.

For transportation service contracts, what is tracked is the contractual information, the shipping and housing orders placed under those contracts, the states of those orders and corresponding states of the internal shipping orders, and the shipments themselves. In addition, the system tracks other actions under the contract, including payment authorizations, change orders, delays, misdeliveries, damaged and misplaced goods, and shipments not accepted.

The management of vehicle ﬂeets, for enterprises that have their own, entails the capture of maintenance and spare parts information and the capture of vehicle stafﬁng, routes and schedules, and current orders, states, and locations. In general, the activities are the same as those of contract shipping organizations, but the manufacturer’s transportation ﬂeet has only one customer and usually a small and mainly predeﬁned set of destinations.

Execution activities supported by transportation include movement of parts between manufactur- ing centers and movement of spare parts and ﬁnished products to customers and distribution centers, all of which are revenue producing. The supporting activities of managing transportation ﬂeets and services are also supported.

Planning activities supported by transportation include delivery planning, transportation resource planning, and transportation route planning.

Human Resource Management

The human resource management (HRM) component includes the management of all information about the personnel of the manufacturing enterprise—current and former employees, retirees and other pensioners, employment candidates, and possibly on-site contractors and customer representa- tives. For employees, the information may include personal information, employment history, orga- nizational placement and assignments, evaluations, achievements and awards, external representation roles, education, training and skills certiﬁcation, security classiﬁcations and authorizations, wage / salary and compensation packages, pension and stock plan contributions, taxes, payroll deductions, work schedule, time and attendance, leave status and history, company insurance plans, bonding, and often medical and legal data. For contract personnel, some subset of this information is maintained (according to need), along with references to the contract arrangement and actions thereunder.

The HRM system is often also the repository of descriptive information about the organizational structure because it is closely related to employee titles, assignments, and supervisory relationships.

The execution activities supported by the HRM system are entirely support activities. They include the regular capture of leave, time, and attendance information and the regular preparation of data sets for payroll and other compensation actions and for certain government-required reports. They also include many diverse as-needed transactions, such as hiring and separation actions of various kinds, and all changes in any of the above information for individual personnel. But the HRM system supports no revenue-producing function directly, and it often plays only a peripheral role in strategic planning.

Finance Management and Accounting

This function includes the management of all information about the monies of the enterprise. The primary accounting elements are grouped under accounts payable (all ﬁnancial obligations of the organization to its suppliers, contractors, and customers); accounts receivable (all ﬁnancial obligations of customers, suppliers, and other debtors to this organization); and general ledger (the log of all real and apparent cash ﬂows, including actual receipts and disbursements, internal funds transfers, and accrued changes in value). In reality, each of these is divided into multiple categories and accounts. While smaller organizations often do ﬁnance management under the heading general ledger, larger ones, and therefore ERP systems, usually separate the ﬁnance management concerns from general ledger transactions. They include ﬁxed asset management (acquisition, improvement, amortization, depreciation of plants, facilities, and major equipment); ﬁnancial asset management (cash accounts, negotiable instruments, interest-bearing instruments, investments, and beneﬁcial interests [e.g., part- nerships]); and debt management (capitalization, loans and other ﬁnancing, and ‘‘assignments of interest’’ [e.g., licenses, royalties]).

The major enterprise execution activities supported by the ﬁnance management component are contracting, payroll, payment (of contractual obligations), invoicing, and receipt of payment. Payroll is a supporting activity, but payment and receipt are revenue producing.

The primary ﬁnancial planning activities supported are investment planning, debt planning, and budget and cash ﬂow planning and analysis.

Interaction Points

It is the intent of many ERP vendors to provide the information systems support for all the business operations of the manufacturing enterprise, and ERP systems have gone a long way in that direction. But there are still several areas in which the manufacturing organization is likely to have specialized software with which the ERP system must interface. The primary mission of the ERP system is to provide direct support to the primary operations activities (materials acquisition, manufacturing, prod- uct delivery) and to the planning and management functions for those operations. The software environment of a large manufacturing enterprise includes many other systems that support nonoper- ations business functions. This includes product planning and design, market planning and customer relations, and supply chain planning and development. Additionally, software that supports the de- tailed manufacturing processes and the control of equipment is so specialized and therefore so diverse that no ERP provider could possibly address all customer needs in this area.

On the other hand, the wealth of data managed within the ERP core, as well as its logical and physical infrastructure and the demand for those data in many of these related processes, open the door for integrating these other functions with the ERP system. This is the situation that leads to demands for open ERP interfaces.

Moreover, as the ERP market expands to medium-sized enterprises, the cost of the monolithic ERP system has proved too high for that market, leading ERP vendors to adopt a strategy using incremental ERP components for market penetration. This strategy in turn requires that each com- ponent system exhibit some pluggable interface by which it can interact with other component sys- tems as they are acquired. While ERP vendors have found it necessary to document and maintain these interfaces, thus rendering them open in a limited sense, none of the vendors currently has an interest in interchangeable components or standard (i.e., public open) interfaces for them. But even among components there are ‘‘forced’’ ERP boundaries where the medium-sized enterprise has longer-standing enterprise support software (e.g., in human resources and ﬁnance). These also offer opportunities for standardization.

At the current time, the most signiﬁcant ERP boundaries at which standard interfaces might be developed are depicted in Figure 3.

Contracts Management

Contractual relationships management deals with the information associated with managing the for- mal and legal relationships with suppliers and customers. It consists of tracking the contract devel- opment actions; maintaining points of contact for actions under the agreements; and tracking all formal transactions against the agreements—orders and changes, deliveries and completions, signoffs, invoices and payments, disputes and resolutions, and so on. ERP systems rarely support the document management function, tracking the contract document text through solicitation, offer, counteroffer, negotiation, agreement, amendments, replacement, and termination. They leave that to a legal or

business document management system and carry only references into that system where needed. They do routinely capture all transactions against agreements, but they often capture them in different places. Only a few centralize all these transactions under contracts management.

Supplier Relationship Management

This activity includes information on contractual arrangements with suppliers and points of contact, relationship history (orders, fulﬁllments, disputes, resolutions), business evaluations, and technical evaluations of products and capabilities, including certiﬁcations for speciﬁc materials. For speciﬁc materials (or product families), there are approved supplier lists that identify suppliers from whom the organization may order that material, often with preference ranking or ranking criteria.

Customer Relationship Management

As mentioned previously, the objective of CRM is to add value for customers through those processes that involve direct contact with customers before, during, and after sales. This function encompasses marketing and sales activities related to the identiﬁcation and characterization of markets, the char- acterization of product opportunities within those markets that are consistent with the strategies and expertise of the enterprise, and the development of those markets into a customer base that generates recurring demand for the products of the enterprise. ERP systems may support demand planning activities that make projections for existing products with target volumes and time requirements as well as projections for new products or product modiﬁcations. ERP systems may also support cus- tomer inquiries as to product lines and company capabilities as well as inquiries and negotiations for alternative supply arrangements. As discussed in Section 2.2.3, ERP systems always support customer orders for existing products, customer order changes and cancellations, and inquiries about customer order status.

Product Conﬁguration Management

A product conﬁgurator tracks the design of product options from desired features to manufacturing speciﬁcations. It captures product planning, pricing, and engineering decisions about option imple- mentations and interoption relationships. The sales conﬁgurator component tells the sales staff what option combinations a customer can order and how to price them. The manufacturing conﬁgurator converts the option set on a customer order to a speciﬁcation for bill of materials, station setup, prepositioning requirements, batching requirements, and process selections.

In ‘‘to-order’’ environments, an ERP system may include a product conﬁguration function. A product conﬁgurator captures customer-speciﬁed product options in make-to-demand, option-to- or- der, and engineer-to-order environments. In those environments, product conﬁgurators connect the front ofﬁce with the back ofﬁce. In make-to-demand and option-to-order environments, product con- ﬁgurators link sales with manufacturing operations. In engineer-to-order environments, product con- ﬁgurators are a conduit between sales and engineering.

Product Data Management

While ERP systems are the principal repository for all operations data, they contain only fragments of product and process engineering data. One of the reasons for this is that the ERP core is short transactions with concise data units, while engineering data management requires support for long transactions with large data ﬁles. As ERP systems have grown over the last 10 years, PDM systems have grown rapidly as the product engineering information management system, especially in me- chanical and electrical parts / product industries. The rise of collaborative product and process engi- neering in the automotive and aircraft industries has led to increasing capture of process engineering information in the PDM. Product engineering software tools, particularly CAD systems, are used to design tooling and other process-speciﬁc appliances, and these tools often have modules for gener- ating detailed process speciﬁcations from the product deﬁnitions (e.g., exploded bills of materials, numerical control programs, photomasks). These tools expect to use the PDM as the repository for such data. Moreover, increased use of parts catalogs and contract engineering services has led to incorporation of a signiﬁcant amount of part sourcing information in the PDM. Many ERP vendors are now entering the PDM product market, and the interface between PDM and ERP systems is becoming critical to major manufacturers and their software providers.

Supply Chain Execution

Although ERP systems may offer a one-system solution to supporting the operations of a given enterprise, one cannot expect that solution to extend beyond the walls. The information transactions supporting the materials ﬂows from suppliers to the manufacturing enterprise and the ﬂows of its products to its customers are becoming increasingly automated. Although basic electronic data in- terchange (EDI) transaction standards have been in existence for 20 years, they are not up to the task. They were intentionally made very ﬂexible, which means that the basic structure is standard but most of the content requires speciﬁc agreements between trading partners. Moreover, they were made to support only open-order procurement and basic ordering agreements, while increased au- tomation has changed much of the behavior of open-order procurement into automated catalogs and automated ordering and made several other supplier–customer operation techniques viable in the last several years. Thus, there is a need for ERP systems to operate, via upgraded e-commerce interfaces, with the ERP systems of the partners in the supply chain.

Supply Chain Planning

Until recently, ERP-supported planning algorithms focused on the internal behavior of the enterprise in managing its production and distribution, treating both customers and suppliers largely as black boxes with documented behaviors. The new concept is resource and market planning that focuses on the participation of the enterprise in various supply chains; thus, it can be effective only if it is part of a joint planning effort of multiple partners in those chains—the enterprise, its peers in the chain, its customers in the chain, and its suppliers. The joint planning activity must be supported by infor- mation interchanges between the decision-support software in (or linked to) the separate ERP systems of the partners. Algorithms for performing such joint planning are emerging, and ﬁrst-generation software to support those algorithms is now available under the title advanced planning and sched- uling (APS). Further development of these algorithms and interfaces is a necessary element of the future of ERP systems.

Manufacturing Execution

At some point, the gathering of manufacturing resource status information and work-in-process in- formation becomes speciﬁc to the resource and the particular manufacturing task. It requires spe-

cialized systems to implement the specialized data-capturing technology and convert those data into resource planning, job planning, and tracking information. Further, particularly in discrete batch and job shop environments, the resource scheduling process itself becomes deeply involved with the details of the manufacturing tasks and the resource setups. Finally, a great deal of information gath- ered on the manufacturing ﬂoor is used to improve the process and product engineering as well as the characterization of machine capabilities, process yields, product quality, and so on. This domain is now loosely called manufacturing execution systems. Such systems deal with the details of data gathering, conversion, and assessment for speciﬁc purposes and industries. Future ERP systems must expect to interface with such companion factory management systems in a signiﬁcant number of customer facilities. The need is to share resource planning information, resource status information, and order / job / lot release and status information.

Human Resource Management

Although it is considered a part of ERP, human resource management (HRM) systems have already penetrated the medium-sized enterprise market in many industries, of which manufacturing is only a subset. As ERP systems grow out of the manufacturing industry to other business areas, the need for interfacing with established HRM systems becomes apparent. And this makes standard interfaces to the HRM component more attractive to ERP and HRM vendors and customers.

Finance

In a similar way, most businesses, large and small, have long since built or acquired ﬁnancial man- agement software to support their business practices. Moreover, those practices and the related legal requirements vary signiﬁcantly from country to country and, to a lesser extent, from state to state. For ERP systems, this means no ‘‘one size ﬁts all’’ customers or even all business units of a single customer. Thus, interfaces to specialized and in-place ﬁnancial software packages will continue to be a requirement.

Elements of ERP Implementations

The previous section addressed the functional aspects—the ‘‘what’’—of ERP systems. This section deals with the ‘‘how’’ of ERP, speciﬁcally the generic software elements of current commercial ERP systems. It does not address the rationale used by a speciﬁc manufacturing enterprise to manage its own ERP selection, deployment, and upkeep. However, it covers brieﬂy some of the tools for man- aging an ERP system. Additionally, it describes the generic architectures used by ERP vendors.

The basic elements of an ERP implementation include the core transaction system, packaged decision support applications provided by the ERP vendor, in-house or third-party extended appli- cations, and a collection of tools for managing various aspects of the system (Figure 4). Each of these software elements reside in a computing environment that is typically distributed and possibly multiplatform.

Core ERP—Transactions

The ERP core consists of one or more transaction databases as well as transaction services. As described in Section 2.2, these services include capturing, executing, logging, retrieving, and moni- toring transactions related to materials inventories, facilities / equipment, labor, and money.

Packaged Decision Support Applications

In addition to transaction management, ERP vendors provide decision support applications that offer varying degrees of function-speciﬁc data analysis. The terms decision support application and de- cision support systems (DSS) refer to software that performs function-speciﬁc data analysis irrespec- tive of enterprise level. That is, decision support includes applications for supply, manufacturing, and distribution planning at the execution, tactical, and strategic levels of an enterprise. There is consid- erable variability among ERP vendors regarding the types of decision support applications that they include as part of their standard package or as add-ons. At one end of the spectrum, some vendors provide very speciﬁc solutions to niche industries based on characteristics of the operations environ- ment (i.e., process and business nature) as well as enterprise size in terms of revenue. For example, an ERP vendor at one end of the spectrum might focus on assembly line / engineer-to-order environ- ment with decision support functionality limited to manufacturing and distribution planning integrated with ﬁnancials. At the other end of the spectrum, an ERP vendor could offer decision support functionality for supply, manufacturing, and distribution planning at all enterprise levels for a host of operations environments for enterprises with varying revenues. While such a vendor offers an array of decision support tools, one or more tactical level, function-speciﬁc applications (i.e., supply, man- ufacturing, distribution) are typically part of a standard ERP implementation (Figure 2). The others

tend to be considered add-ons. While a vendor may offer these add-ons, a manufacturer may opt to forgo the functionality they offer altogether or implement them as extended applications, either de- veloped in-house or procured from third-party software vendors.

Extended Applications

The wealth of data in ERP systems allows many manufacturing enterprises to use ERP as an infor- mation backbone and attach extended applications to them. The motivation for such applications is that manufacturers typically see them as necessary to achieve differentiation from competitors. These applications may be developed in-house or by a third party. A third party may be a systems integrator who develops custom software, or it may be a vendor who develops specialized commercial software. As discussed in Section 2.3, these add-ons may provide additional functionality for customer and supplier relationship management, product data management, supply chain planning and execution, and human resource management. Regardless of the source, these applications must integrate with the ERP. Application programmer interfaces (APIs) are the common mechanism for integrating ex- tended applications with the ERP backbone, and speciﬁcally the ERP core. Even among their partners and strategic allies (i.e., certain systems integrators and third-party software vendors), ERP vendors discourage the practice of integrating their standard applications with extended applications because of potential problems with upward compatibility. Because APIs to the ERP core have a longer expected lifetime, APIs are presently the most common approach to accessing information in the ERP system.

Tools

Given the enormous scope of the system, ERP can be a challenge to set up and manage. As such, ERP and third-party vendors provide software tools for handling various aspects of these complex systems. These tools generally fall into two categories: application conﬁguration tools, which support the setup and operation of the ERP system itself, and enterprise application integration (EAI) tools, which support integration of the ERP system into the enterprise software environment.

ERP Conﬁgurators In an effort to decrease the amount of time and effort required to install, operate, and maintain an ERP system, vendors may provide a variety of application conﬁg- uration tools. These tools vary in complexity and sophistication, but they all perform essentially the following tasks:

• Deﬁne the computing topology: Query the manufacturing administrator about the enterprise computing environment, the operating platforms, and the number, locations, and kinds of user workstations. Direct the setup program to install the appropriate versions of the ERP core and packaged modules on the server and workstation platforms.

• Deﬁne the information base: Query the manufacturing administrator about the speciﬁcs of their business information environment and assist in developing specialized information models (based on the vendor’s generic ERP models) to support those business speciﬁcs. Automatically conﬁgure the ERP databases and transaction formats accordingly.

• Deﬁne tasks and workﬂows: Query the manufacturing administrator about the speciﬁcs of their business processes, map individual tasks to users across organizations, applications, and systems, and assist in developing specialized workﬂow models and decision support models. Then au- tomatically conﬁgure the ERP workﬂow / task models, decision support invocations, and report formats.

• Deﬁne security and control requirements: Query the manufacturing administrator for user clas- siﬁcations by task responsibilities and authorizations. Deﬁne the user privileges, activity logging requirements, and security controls.

Enterprise Application Integration Unlike application conﬁguration tools, which are part of an ERP vendor’s suite and centered on the ERP system as the integrator of business processes, enterprise application integration (EAI) tools are actually a non-ERP-speciﬁc category of software tools whose primary function is to support business processes by linking up distinct software systems in the overall enterprise computing environment. As such, they view ERP as one part of a manufac- turer’s entire IT solution. But many of these tools come with predeﬁned interfaces to speciﬁc ERP systems (some are provided by ERP vendors) and are designed primarily to link other software systems and applications with the ERP system.

This is a relatively new and fragmented class of software, employing a number of techniques of varying sophistication and providing quite variable capabilities. One view of EAI is as ‘‘a selection of technologies to address a number of applications integration problems’’ (Gold-Bernstein 1999). In this perspective, EAI technologies include platform integration solutions (messaging, message queueing, publish-and-subscribe, and object request brokers), message brokers (translations and trans- formation, intelligent routing, and application adapters), some graphical user interface (GUI) tools to deﬁne routing and mapping rules, and process automation and workﬂow.

A simpliﬁed view of a typical EAI architecture is provided in Figure 5. The EAI package consists of a number of application-speciﬁc adapters, each of which is capable of extracting data from and providing data to a particular application software package in some form convenient to that appli- cation. The adapter may also communicate directly with a central EAI engine that moves data sets between the adapters in some message form. In many cases the message is just a ﬁle, while in some cases the sole function of the adapter is to command the application to input or output a particular ﬁle. In some architectures, the adapter is responsible for converting the application information to or from a common interchange model and format used by the EAI package. In others, each adapter produces information in a convenient form and the engine is responsible for the conversion of the messages or ﬁles between the adapters, using a common reference model or an application-to- application-speciﬁc translation, or both.

Most EAI packages are designed primarily to solve intraenterprise communication problems. Many provide some mechanisms for Web-based access as a means of interaction with customers and suppliers.

ERP Architectures

For purposes of illustration, the ERP community refers to tiers when describing the general logical architectures of ERP systems. While the notion of tiers generally implies a hierarchy, such is not the case with tiers in present-day ERP architectures. Advances in distributed computing technologies enable more open communication among components. Instead, these tiers are the basic types of logical elements within an ERP implementation and thus provide a means for describing various ERP execution scenarios.

Figure 6 illustrates the ﬁve tiers of ERP architectures: core / internal (often called data), application, user interface, remote application, and remote user interface. A common intraenterprise scenario involves the data, application, and user interface tiers. This scenario does not preclude application- to-application interaction. Similarly, common interenterprise scenarios include an internal user or application requesting information from an external application or an external user or application requesting information from an internal application. The Internet is the conduit through which these internal / external exchanges occur. Additionally, in many ERP systems web browsers have emerged as the platform for both local and remote user interfaces.

ERP and the Internet

The emergence of the Internet as the primary conduit for exchange of ERP-managed information among trading partners has spawned the term Internet-based ERP. This term does not convey a single concept but may refer to any of the following:

• Internal user-to-ERP-system interfaces based on web browsers

• External user-to-orders interfaces based on web browsers

• Interfaces between decision support software agents of different companies that support supply chain operations

• Interfaces between decision support software agents of different companies that support joint supply chain planning

The increasingly commercial nature of the Internet and the development of communication exchange standards have had signiﬁcant impact on ERP systems. In describing this impact, the term tier is used in the context of ERP architecture (Section 2.5).

Internal User-to-ERP Interfaces

Also called application hosting, this approach employs user interfaces (Tier 3) based on Internet / Web technologies, notably Java, the Hypertext Markup Language (HTML), and the Extensible Markup Language (XML). In this scenario, ERP vendors as well as systems integrators take on a new role as application service providers (ASPs). This is an important change in the product archi- tecture of ERP, in that the ERP vendor no longer has to maintain the dedicated workstations or the workstation software for users so connected. It also means that the ERP vendor cannot price that part of its services by station but instead uses transaction volume metrics. This differs from other impacts by being purely intranet-based (i.e., all such connections are from within the enterprise and thus subject to alternative controls and security mechanisms).

External User-to-ERP Interfaces

In this scenario, a remote user (Tier 5), via an interface based on Web technologies, accesses appli- cation service modules (Tier 2). This is a widely used approach among ERP vendors and CRM vendors. It differs from the ﬁrst by having many electronic business technical concerns, including access authorization and data ﬁltering, secure sockets, and contract and payment references. The critical question here is whether the functions supported include order entry or just order tracking and how the Web services are related to internal orders management. The CRM system may act as a staging system with no direct connect between the Web interface and the ERP system itself.

B2B Supply Chain Operations Interfaces

This scenario involves communication between a remote application and a local application (i.e., Tier 4 and Tier 2). The actual exchange is usually based on EDI or some XML message suites,* using ﬁle transfers, electronic mail, or some proprietary messaging technology to convey the messages. This scenario is signiﬁcantly different from the above in that neither of the communicating agents is a user with a browser. Rather, this is communication between software agents (decision support modules) logging shipment packaging, release, transportation, receipt, inspection, acceptance, and possibly payment on their respective ERP systems (with some separate Tier 3 user oversight at both ends). Special cases of this include vendor-managed inventory and consignment management, which illustrate the use of the Internet in direct support of an operations process.

* E.g., RosettaNet (RosettaNet 2000), CommerceNet (CommerceNet 2000), Electronic Business XML (Electronic Business XML 2000), Open Applications Group Interface Speciﬁcation (OAGIS) (Open Applications Group 2000).

Joint Supply Planning (Advanced Planning and Scheduling) Interfaces This scenario also involves communication between a remote application and a local application (i.e.,Tier 4 and Tier 2) with the exchange based on a common proprietary product or perhaps an XML message suite. Again the communicating agents are software systems, not users with browsers, but their domain of concern is advanced planning (materials resource planning, distribution resource planning, etc.) and not shipment tracking. There are very few vendors or standards activities in this yet because this represents a major change in business process. This scenario illustrates use of the Internet in direct support of a tactical planning process.