ENTERPRISE RESOURCE PLANNING SYSTEMS IN MANUFACTURING:ERP CHALLENGES AND OPPORTUNITIES

ERP CHALLENGES AND OPPORTUNITIES

While evidence suggests that ERP systems have brought about profound positive economic effects by eliminating inefficiencies, there is still room for substantial improvement. The technical challenges and opportunities for ERP systems arise from how well these systems satisfy the changing business requirements of the enterprises that use them. Case studies in the literature highlight the unresolved inflexibility of ERP systems (Davenport 1998; Kumar and Van Hillegersberg 2000). The monolithic nature of these systems often hampers, or even prevents, manufacturers from responding to changes in their markets. Those market changes relate to ERP systems in two important ways: the suitability of decision support applications to an enterprise’s business environment and the degree of interoper- ability among applications both within and among enterprises.

These two issues lead to three specific types of activities to improving ERP interoperability: technology development, standards development, and business / technology coordination.

Research and Technology Development

Decision Support Algorithm Development

Manufacturing decision support systems (DSSs), especially those that aid in planning and scheduling resources and assets, owe their advancement to progress in a number of information technologies, particularly computational ones. The early versions of these applications—namely materials require- ments planning (MRP) and manufacturing resource planning (MRP II)—assumed no limitations on materials, capacity, and the other variables that typically constrain manufacturing operations (e.g., on-time delivery, work-in-process, customer priority). The emergence of constraint-based computa- tional models that represent real-world conditions has enabled manufacturers to better balance supply and demand. In spite of the improvement in DSSs, significant opportunities still exist. Different models apply to different business environments. With the rapid pace of change, the commercial viability of the Internet, and the push to ‘‘go global,’’ there are new variables to examine and new models to develop. Instead of convergence to any single optimization function, there will likely be specialization to classes of functions. That specialization has begun as illustrated in Figure 2 and described in Section 3.2 Continued specialization (not simply customization) is likely and necessary. Those classes will account for the variety of ways that manufacturing enterprises choose to differ- entiate their operations from those of their competitors. While cost reduction has been the focus of the current generation of DSSs, models that also address revenue enhancement and response time are expected to be the focus of future generations.

Component Decomposition Analysis

As decision support technology evolves, so too does ERP system functionality. While advances in software functionality affect an enterprise’s continuous IT improvement strategy, they do not comprise all of that strategy. Migration is another critical aspect of continuous IT improvement. That is, replacing and upgrading an existing system—in whole or in part—must be possible for an enterprise to move from one functional state to another. In general, ERP vendors have focused on providing functionality at the expense of replaceability and upgradability (Sprott and Wilke 1998). Conse- quently, lock-in effects are major concerns for manufacturing and nonmanufacturing enterprises alike.

Possessing the concepts of services and encapsulation, components are touted as the solution to this problem. A component delivers functionality to a user or another software entity through one or more well-defined interfaces. Encapsulation means that a component is a separate entity, thus making it easier with which to manage, upgrade, and communicate. Yet components alone do not guarantee interoperability, especially in complex e-business and electronic commerce environments. For ERP systems to be interoperable, there must be widespread agreement on the services that ERP applica- tions provide and on the boundaries of encapsulation. Numerous approaches to defining services and interfaces exist, including vendor-specific conventions, intraenterprise conventions, industry-specific standards, and technology-specific standards.

These approaches all lack broad perspective and thus do not meet the challenges of enabling ERP interoperability in e-business and electronic commerce environments. To achieve interoperability with the vendor-specific conventions, a single ERP vendor must dominate not just the ERP system market but the markets of all the other systems that (need to) interoperate with ERP. Intraenterprise conven- tions work up to the bounds of the enterprise, as long as there are no major internal changes (such as mergers or acquisitions). The approach based on industry-specific standards fails to realize that the focal point of operations is business process and that information varies according to the char- acteristics of those processes. Industries obviously are defined by product, not business process, and commonality of product does not translate into commonality of business process. Operations-wise, what makes sense for one supply chain member (e.g., an original equipment manufacturer [OEM]) does not necessarily make sense for another (e.g., a lower-tier supplier). The fourth approach, technology-specific standards, tends to yield limited solutions because it focuses on syntax and not semantics. Without agreement on the meaning of the information to be exchanged and the func- tion that the information supports, the challenges of reconciliation persist. Many technology-focused efforts fail to perform sufficient domain-specific information requirements analysis.

Because electronic commerce dramatically changes the nature of power and control in supply chains, component decomposition analysis must address the three emerging models of business-to- business (B2B) markets. The first approach is an OEM-controlled model such as those recently announced by U.S. automakers and defense contractors (Stoughton 2000). The second is supplier- controlled model such as those in metals, chemical, and paper industries. The third is an open model that allows control to be shared among all supply chain players. Many think that the open model will prevail in the long run. However, industries will not collectively reach that point at the same rate or at the same time. To realize this model, it is necessary to look beyond industry-specific exchange of operations data. It is necessary to analyze business processes and characterize them at appropriate levels of detail. These characterizations would highlight the different kinds of components and thus the information that needs to be exchanged in different scenarios.

Standards Development

Standards play an important role in achieving interoperability. With respect to ERP systems, oppor- tunities exist for establishing standard interface specifications with other manufacturing applications.

ERP–PDM Interfaces

As discussed in Section 2.3.5, there is an obvious interaction point between ERP and PDM systems. Thus, there is a need for interfaces between the two systems to share separately captured engineering and sourcing specifications. In the longer run, the goal should be to have PDM systems capture all the product and process engineering specifications and to extract resource requirements information for use in ERP-supported planning activities. Conversely, sourcing information, including contract engineering services, should be captured in the ERP system. To do this, one needs seamless inter- actions as seen by the engineering and operations users.

ERP–MES Interfaces

As presented in Section 2.3.8, future ERP systems must expect to interface with such companion factory management systems in a significant number of customer facilities. There is the need to share resource planning information, resource status information, order / job / lot release, and status infor-

mation. However, developing such interfaces is not a straightforward exercise. The separation of responsibilities and the information to be exchanged vary according to many factors both at the enterprise level and the plant level. Prestandardization work is necessary to identify and understand those factors.

Supply Chain Operations Interfaces

Supply chain information flows between the ERP systems of two trading partners have been the subject of standardization activities for 20 years, with a spate of new ones created by Internet com- merce opportunities. Most of these changes concentrate on basic ordering agreement and open pro- curement mechanisms. Requirements analysis of this information is necessary before actual standards activities commence. As the business practices for new trading partner relationships become more stable, standards for interchanges supporting those practices will also be needed. Changes in business operations practices as well as in decision support systems have changed the information that trading partners need to exchange. This includes shared auctions, supply schedule, vendor-managed inventory, and other operational arrangements, but the most significant new area is in joint supply chain planning activities (i.e., advanced planning and scheduling).

4.3. Establishing Context, Coordination, and Coherence for Achieving Interoperability Several developments in the past decade have combined to extend the locus of information technology from research labs to boardrooms. The commercialization of information technology, the pervasive- ness of the Internet, and the relatively low barriers to market entry for new IT companies and their technologies all serve to create an environment of rapid growth and change. The ERP arena, and electronic commerce in general, suffer from a proliferation of noncooperative standards activities, each aimed at creating interoperability among a handful of manufacturers with specific software tools and business practices. There is an imperative to reduce competition among standards efforts and increase cooperation.

Understanding the complex environment that surrounds ERP and other e-business and electronic commerce applications is a critical challenge to achieving interoperability. Topsight is a requirement for meeting this challenge. The objective of topsight is to establish context, coordination, and co- herence among those many activities that seek standards-based interoperability among manufacturing applications. While the hurdles that exist in the current environment are considerable, there is sig- nificant need—as well as potential benefit—for an industry-led, multidisciplinary, and perhaps gov- ernment-facilitated effort to provide direction for the development and promulgation of ERP and related standards.

The notion of topsight for improving interoperability among specific applications is not new. The Black Forest Group, a diverse assembly of industry leaders, launched the Workflow Management Coalition (WfMC), which has produced a suite of specifications for improving interoperability among workflow management systems. A similar ERP-focused standards strategy effort would strive to understand better the diversity of operations and operations planning in order to improve interoper- ability among ERP and related systems.

For a topsight effort to succeed in an arena as broad as ERP, particularly one that is standards- based, there must be a cross-representation of consumers, complementors, incumbents, and innovators (Shapiro and Varian 1999).

As consumers of ERP systems, manufacturers and their trading partners face the risk of being stranded when their systems do not interoperate. The lack of interoperability in manufacturing supply chains can create significant costs (Brunnermeier and Martin 1999), and those costs tend to be hidden. More accurate cost structures must be developed for information goods, particularly for buy- configure-build software applications. Unlike off-the-shelf software applications, ERP systems are more like traditional assets, in the business sense, with capital costs and ongoing operational costs.

Complementors are those who sell products or services that complement ERP systems. Given the role that ERP plays in electronic commerce, this group is very large. It includes both software vendors and systems integrators and management consultants. Some of the software that complements ERP was discussed previously in Section 2.3. Others include additional categories of software necessary for achieving e-business: EDI / e-commerce, business intelligence, knowledge management, and col- laboration technologies (Taylor 1999).

Incumbents are the established ERP vendors, and they make up a market that is very dynamic and diverse (Table 2). Achieving consensus of any kind with such a diverse market is a considerable challenge. To achieve ERP interoperability requires, among others, deeper understanding of common elements. That understanding can be acquired by detailed functional and information analysis of the ERP systems.

The notion of innovators in the standards process focuses on those who collectively develop new technology. While many individual technology development activities associated with ERP and elec- tronic commerce might be considered innovative, there have been few explicit collective development

efforts. Most ERP vendor partnerships tend to be confined to making existing products work together through application programmer interfaces. They generally do not involve the joint creation of new (and often complementary) technologies. The dynamics that compel banks and credit card companies to pursue smart card development do not exist in the ERP environment. However, there are others who meet this definition of innovator. Academia is one group of innovators whose relationship with ERP vendors tends not to make headlines. Still, many of the technologies in today’s ERP systems have academic roots. The perspective of university researchers across numerous disciplines would add significant value to a topsight effort.