Technovation 25 (2005) 433–441 www.elsevier.com/locate/technovation
A prototype multi-agent ERP system: an integrated architecture and a conceptual framework Bih-Ru Leaa,*, Mahesh C. Guptab, Wen-Bin Yuc a
Department of Business Administration, School of Management and Information Systems, University of Missouri—Rolla, Rolla, MO 65409, USA b Department of Management, College of Business and Public Administration, University of Louisville, Louisville, KY 40292, USA c Department of Information, Science and Technology, School of Management and Information Systems, University of Missouri—Rolla, Rolla, MO 65409, USA
Abstract This paper proposes a prototype multi-agent enterprise resource planning (MAERP) system that utilizes the characteristics and capabilities of software agents to achieve enterprise wide integration. A software agent is a self-contained, autonomous software module that performs assigned tasks from the human user and interacts/communicates with other applications and other software agents in different platforms to complete the tasks. Four types of intelligent software agents (coordinating agents, task agents, data collecting agents, and user interface agents) are examined and discussed in the proposed MAERPS architecture. We demonstrate how the proposed prototype MAERP system takes advantage of existing information systems among various functional areas to achieve the system integration of commercially available enterprise resource planning (ERP) systems, while avoiding numerous problems encountered during a typical ERP implementation. q 2003 Elsevier Ltd. All rights reserved. Keywords: Enterprise resource planning (ERP); Software agent; ERP architecture; ERP implementation
1. Introduction Modern businesses are too complex and dynamic to be managed optimally using traditional information systems or even rigidly structured enterprise resource planning (ERP) systems. Agent-based systems claim to be next generation software capable of adapting dynamically to changing business environment and of solving a wide range of business problems in areas such as supply-chain management (SCM), health care and patient monitoring, process control applications, and knowledge discovery (Papazoglou, 2001). Software agents are sophisticated computer programs that act autonomously on behalf of their users to solve complex problems, and a multi-agent system is a loosely coupled network of software agents that interact to solve problems that are beyond the individual capacities or knowledge of each problem solver.
software packages. A multi-agent-based ERP (MAERP) architecture is proposed to take advantage of the existing information systems and to exploit the capabilities and characteristics of the software agent-based computer systems. The rest of the paper is organized as follows. In the rest of this section, we discuss the evolution in information systems as an enabling technology and establish software agents as an innovation to solve complex business problems. Next, a brief introduction to software agent technology is provided to highlight its properties, various types, and applications in order to establish its viability for developing an ERP type system. Third, the architecture of an MAERP system is proposed. Fourth, a simple example is provided to explain the workings of the proposed MAERP system. We show various phases through which the proposed MAERP system will handle a typical query. Finally, the implications of the MAERP system and future research directions are provided.
1.1. Purpose 1.2. Research background The purpose of this paper is to explore the use of software agents to achieve the system integration of commercial ERP * Corresponding author. Tel.: þ 1-573-341-4184; fax: þ1-573-341-4812. E-mail address:
[email protected] (B.-R. Lea). 0166-4972/$ - see front matter q 2003 Elsevier Ltd. All rights reserved. doi:10.1016/S0166-4972(03)00153-6
Since 1950s when transaction processing systems were first introduced, information systems have been successfully implemented in different functional areas, each with its own database and data architecture, to support decision making.
434
B.-R. Lea et al. / Technovation 25 (2005) 433–441
Although such functional information systems have matured in terms of functionalities over the years of testing, modification, and maintenance, these systems have also caused problems such as data redundancy, information inconsistency and/or inaccuracy, and high system maintenance costs. In addition, such information systems are likely to result in poor decision quality due to the lack of cross-organizational perspective and communication difficulty (Jacobs and Whybark, 2000). Consequently, the whole organization may lose its competitive edges because it does not realize its full potential. In the late 1970s and early 1980s, the need for enterprise wide integrated systems intensified as global competition became inevitable, and product customization and innovation became important factors to retain customers and subsequently to gain market share (Kalakota and Robinson, 2000). Systems thinking based management philosophies such as total quality management and just-in-time systems were introduced, which necessitated the management of relationships among functional areas and cross-organizational processes. As early as 1969, Blumenthal proposed a framework for an enterprise wide information system. The development of such systems slowly evolved from standalone systems (e.g., a standard inventory control system) to material requirement planning/manufacturing resource planning (MRP I and MRP II) systems, and subsequently, to enterprise wide systems to include other functional areas such as sales and marketing, financial accounting, and human resource management. However, attempts to provide a complete enterprise wide software solution were not successful until the mid-1990s due to technical complexity, lack of resource availability, and unclear vision (Kumar and Van Hillegersberg, 2000). In the mid-1990s, the Gartner Group coined the term “ERP” to refer to next generation systems which differ from earlier ones in the areas of relational database management, graphical user interface, fourth generation languages, client – server architecture, and open system capabilities (Dahlen and Elfsson, 1999; Koch et al., 1999) The integration is normally implemented through the use of a common database among subsystems. All the subsystems “talk” directly to each other, and the data are made available in real time (Jacobs and Whybark, 2000). The information is updated as changes occur, and the new status is available for everyone to use for decision making or for managing their part of business. The decisions made in different functional areas are based on the same current data to prevent nonoptimal decisions from obsolete or outdated data. Expected benefits from ERP implementation include lower inventory, fewer personnel, lower operating costs, improved order management, on-time delivery, better product quality, higher productivity, and faster customer responsiveness (Robinson and Wilson, 2001). Most Fortune 500 companies have already adopted ERP systems, and many midsize companies (less than 1000 employees) are planning ERP implementation. Many
organizations have successfully adopted ERP systems, yet many more organizations spent fortunes only to find that business performance has not improved to satisfactory levels within the expected time frame (Robinson and Wilson, 2001; Slater, 1998a). Problems associated with ERP implementation are often classified into technical and organizational aspects. Technical aspects include the technology readiness of an organization, the complexity of commercial ERP software, data loss due to the compatibility of data architectures between the old legacy systems and the new ERP software (Slater, 1998b), and adequacies of newly redesigned business processes (Oliver, 1999; Baatz, 1996). Common organizational factors may include employees’ resistance to change, inadequate training, underestimated implementation time and cost, unwillingness to adopt new business processes, and strategic view of technology adoption (Slater, 1998b; Joshi and Lauer, 1999; Mabert et al., 2001). During the last decade, ERP evolution continued to include inter-organizational processes (i.e., suppliers and customers) and to explore viable alternate approaches (e.g., adopt certain stand-alone or partially integrated functional software modules) by exploiting newly available technologies. For example, National Institute of Standards and Technology (NIST) of the US government supported a Consortium for Intelligent Integrated Manufacturing Planning-Execution (CIIMPLEX), and the consortium members reported their findings on an application of a software agent system to enterprise integration for manufacturing planning and execution (Peng et al., 2002). Intelligent business agents claim to be the next generation of model based solutions for business-to-business and E-Commerce applications (Papazoglou, 2001) and have been examined in various research areas, such as SCM (Ito and Saleh, 2000; Yu and Graham, 2002), health care and patient monitoring (Larsson and Hayes-Roth, 1998), process control applications (Van Dyke Parunak, 1998), knowledge discovery (Jensen et al., 1999), and decision support systems (Hess et al., 2000).
2. Software agent: properties, classification and applications Researchers involved in agent research have used a variety of terms and offered definitions, explicating their use of each term. Although there is no general agreement as to what constitutes an agent, Franklin and Graesser (1996) provide taxonomy of autonomous agents and establishes how they are different from a computer program. In the literature, the term software agent is also referring to as “agent,” “autonomous agent,” intelligent agent,” and “business agent.” An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through effectors (Rusell and Norvig, 1995: p. 33). The term “agent” is used to represent software-based computer programs that have two abilities:
B.-R. Lea et al. / Technovation 25 (2005) 433–441
(i) the ability for autonomous execution and (ii) the ability to perform domain oriented reasoning. In general terms, a software agent is an autonomous, goal-oriented, softwarebased computer program that operates asynchronously, communicating and coordinating with other agents as needed (Fox et al., 2000). 2.1. Properties of software agents The prevailing opinion is that an agent may exhibit four important properties: (i) autonomy allows software agents to operate without the direct intervention of humans or others and to have certain degree of control over their actions and internal state; (ii) social ability allows software agents to interact and communicate with other agents (and possibly humans) via various agent communication language; (iii) reactivity allows agents to perceive their environment (e.g., the physical world, a user via a graphical user interface, a collection of other agents, or the Internet) and respond in a timely fashion to changes that occur in it; and (iv) proactiveness allows agents to exhibit goal-directed behavior by taking the initiative, not just merely by acting in response to their environment (Wooldridge and Jennings, 1995). 2.2. Capabilities of a software agent Newell (1988) argues that for software to be considered intelligent it should be able to do the following (i) exploit significant amounts of domain knowledge; (ii) tolerate error, unexpected and/or wrong input; (iii) use symbols and abstractions; (iv) exhibit goal-oriented behavior; (v) learn from the environment; (vi) operate in real time; and (vii) communicate using natural language. However, an intelligent software agent need not have all of these capabilities. For example, applications that involve only agent-to-agent interaction do not require the ability to communicate using natural language. Real-time response might not be required for many applications where just a timely response is sufficient. Also, highly capable intelligent agents could be constructed without possessing a learning capability, although “learning” is a very desirable characteristic. 2.3. Types of software agents Based on a software agent’s mobility, deliberation, roles, and abilities to cooperate, learn, and act autonomously, Nwana (1996) classified software agents into seven types: collaborative, interface, mobile, information/Internet, reactive, hybrid, and smart agents. Hess et al. (2000) propose a general framework for agent-enabled decision support systems. Five types of agents implemented in the system are as follows: data monitoring, data gathering, modeling, domain managing, and preference-learning.
435
2.4. Applications of software agents In general, agents are well suited for applications that involve distributed computation or communication between components, sensing or monitoring of the environment, or autonomous operation. Because agents have the ability to reason, they can easily perform sequences of complex operations based on messages they receive, their own internal beliefs, and their overall goals and objectives. Jennings and Wooldridge (1998) indicate that any process control system, which must monitor a real world environment and perform actions to modify it as conditions change in real time, is a good application of agent systems. Such systems can range from the very simple, for example, thermostats, to the extremely complex, for example, nuclear reactor control systems. Van Dyke Parunak (1998) demonstrates a shop floor control system that needs to interface with a factory-wide MRP system doing classical scheduling and indicates that a reasonable way to connect the legacy system to the new system is to encapsulate the legacy as an agent. Managers make informed decisions based on a combination of judgment and information from different functional areas on a timely base. Other applications of software agents have been found in health care and patient monitoring (Huang et al., 1995; Larsson and Hayes-Roth, 1998), SCM (Satapathy et al., 1998; Swaminathan et al., 1998; GarciaFlores et al., 2000; Fox et al., 2000; Ito and Saleh, 2000; Yu and Graham, 2002), knowledge discovery (Bose and Sugumaran, 1999; Jensen et al., 1999; Davies and Edwards, 1995), and decision support system (Hess et al., 2000).
3. An MAERP architecture The proposed MAERP architecture is composed of a set of four software agents: (i) a coordinating agent; (ii) an interface agent; (iii) a data collecting agent; and (iv) a set of task agents. We propose that this set of software agents within each functional area (say, department i and department j) interacts through a coordinating agent. Fig. 1 illustrates the abstract level of MAERP system architecture with coordination agents serving as the representatives of each department and communicating with each other over the company’s network. There is a user interface agent which serves as a communication tool between the user and the MAERP system, and there several task agents and data collecting agents that perform specific tasks within the department. Next, various functions/responsibilities undertaken by each type of software agent are discussed. 3.1. The coordination agent The coordination agent (CA) is the heart of this multiagent ERP architecture, is the representative of the department when communicating with other coordination
436
B.-R. Lea et al. / Technovation 25 (2005) 433–441
Fig. 1. An MAERP system architecture.
agents, and is the controller of the other agents within the department. A department can have one or many coordination agents depending on the nature of task complexity. The major responsibilities for the coordination agent include: † receiving instructions and reporting to the human user through an interface agent; † assigning data collection to and receiving data from a data collection agent; † relaying the dataset, assigning tasks to, and receiving feedback from task agents; and † communicating with and providing requested data to other coordination agents. With their domain knowledge, the coordination agents have the ability to monitor, communicate, and collaborate with other agents, react to various requests, as well as assign tasks to proper task agents and data collection agents.
3.3. The task agent The task agents (TA) usually possess mobility and can act autonomously within their own domain knowledge without the intervention of coordination agents. For example, a task agent that is assigned to monitor price change would go to and stay in a supplier’s site to monitor the supplier’s price and report any price change crosses given threshold values with or without the instruction from its coordination agent. The number of task agents varies by the number and complexity of tasks within a department. The functions of a task agent may also vary from department to department depending on what needs to be accomplished. In general, the responsibilities of a task agent include: † receiving data from the coordination agent; † performing data analysis by running specific program and/or algorithm; and then † reporting the results back to the coordination agent. 3.4. The interface agent
3.2. The data collection agent The objective of the data collection agents (DA) is to query specific database(s) within the department and obtain the information requested by its own coordination agent. It possesses specific domain knowledge needed to carry out its tasks. The “intelligence” in the data collection agents identifies invalid data and missing values so that the data is complete and applicable when being returned to the coordination agent. However, the structures or abilities of data collection agents need not be the same in different departments because each department may have a different database management system (DBMS) or data warehouse. The responsibility of a data collection agent is to: † retrieve information requested by its own coordination agent; † query specific database(s) within the department; and † perform data warehousing and prepare data set upon request from coordination agent.
The interface agent (IA) possesses the ability to learn and store preferences of users and the ability to monitor and inform users when tasks have been completed without the inquiry of users. With enhancement, the interface agent may observe and record the user’s disposition to follow the recommendations of coordination agents and invoke machine learning to determine many of the user’s preference. The primary responsibilities of an interface agent include: † communicating between human users and coordination agents; † interpreting results; and † preparing reports for human users.
4. An illustration of the proposed MAERP system In order to illustrate the proposed MAERP system in a manufacturing firm, we will explain the setting and describe a three-step approach to answer a specific query.
B.-R. Lea et al. / Technovation 25 (2005) 433–441
4.1. The setting Assume that a user in a marketing department needs to determine if the company can accept an order from customer X from city c for n units of product m at price p by Wednesday? For simplicity, let us assume that there are five departments: marketing, production, accounting, inventory, and logistics/distribution in the XYZ Company. Each department has its own information system, database, and data architecture. For example, the database was developed using COBOL for the accounting department, using dBase IV for the department of inventory management, using Microsoft Access 95 for the marketing department, using Cþ þ from a small software developing company for the logistics/distribution department, and using ORACLE for the production department. The database for accounting, production, and inventory management are stored in a mainframe from IBM, and the other databases are stored in a workstation running Microsoft NT server. We further assume that one coordination agent is assigned to the marketing (i.e., CA-M), accounting (i.e., CA-A), inventory (i.e., CA-I), and logistics/distribution (i.e., CA-D) departments. Due to the numbers and
437
complexity of tasks, two coordination agents are assigned to the production department for the product mix optimization system (i.e., CA-PO) and for the master production scheduling system (i.e., CA-PS). Further, for each coordination agent, there is one interface agent (IA), one data collection agent (DA), and several tasks agents (TA). 4.2. The example Fig. 2 provides an overview of MAERP system which will be used to answer the above query in four phases as follows. 4.2.1. Phase I In the marketing department, interface agent IA-M communicates the question of “whether the company is currently capable of accepting an order from customer W for x units of product Y at price z delivered to city M by Wednesday” to coordination agent CA-M. 4.2.2. Phase II By exercising domain knowledge, coordination agent CA-M organizes four tasks concurrently:
Fig. 2. An MSERP system application in a manufacturing firm.
438
B.-R. Lea et al. / Technovation 25 (2005) 433–441
1. communicate with coordination agent CA-I to obtain current inventory status of m; 2. communicate with coordination agent CA-D for delivery information; 3. inquire its own data collection agent (DA-M) in the marketing department for price of product m; and 4. monitor the status of requested information from various agents. 4.2.3. Phase III Upon receiving instructions from the coordination agent CA-A in Phase II, the following three tasks are executed simultaneously in different departments: 1. In the inventory management department, coordination agent CA-I inquires data collection agent (DA-I) for the inventory status on product m. (i) Data collection agent DA-I then queries inventory database and returns result to coordination agent CA-I. (ii) Coordination agent CA-I then returns the result back to coordination agent CA-M. 2. In the logistics and distribution department, coordination agent CA-M sends a request to task agent TA-D1 to examine a scenario of scheduling n unit of product m delivered to city c by Wednesday on top of the current delivery schedule. (i) Task agent TA-D1 executes a what-if analysis and returns the result back to CA-D. (ii) Coordination agent CA-D then returns the result back to coordination agent CA-M. 3. In the marketing department, data collection agent DA-M queries database and obtains current selling price ( p0 ) of product m given order quantity n and returns the result back to its coordination agent CA-M. 4.2.4. Phase IV Upon receiving all the information from coordination agent CA-I, coordination agent CA-D, and its own data collection agent DA-M, coordination agent CA-M exercises its own domain knowledge to evaluate the information and to make recommendations to the user. Based on the overall results, two sets of procedures may be executed by the coordination agent CA-M: (i)
Case 1—All conditions are met for order acceptance. (a) Coordination agent CA-M informs interface agent IA-M to notify the user that all conditions are met for order acceptance. (b) If the user commits the order, interface agent IA-M will communicate with the coordination agent to trigger a sequence of actions described as follows: (b-1) Coordination agent CA-M informs the coordination agent CA-D to commit the delivery.
(b-2) Coordination agent CA-D then sends a request to task agent TA-D1 to schedule the delivery. (b-3) Task agent TA-D1 informs coordination agent CA-D upon completion of delivery scheduling. (b-4) Coordination agent CA-D informs coordination agent CA-M upon notification from task agent TA-D1. (c) If the user rejects the order, interface agent IA-M will perform a sequence of actions described as follows: (c-1) Interface agent IA-M will record the user’s decision, which will be used to predict the user’s preference in the future. (c-2) Interface agent IA-M will communicate the user’s decision to coordination agent CA-M for necessary actions. (ii) Case 2—Not all conditions are met for order acceptance. One of strengths of MAERP is that agents possess the ability to negotiate among themselves with/without user intervention. For example, agents will execute a series of negotiation steps if not all conditions are met for order acceptance, as shown in the following example: (a) If the current price p0 of product m is higher than the asking price p, coordination agent CA-M will negotiate with coordination agent CA-A to see if the asking price p is acceptable with quantity n. (b) Coordination agent CA-A then sends a request to task agent TA-A to examine the feasibility of price p p (i.e., the lowest acceptable price) for an order of product m with n units. (c) Coordinating agent CA-A will perform a series of tasks based on results from TA-A: (c-1) If pp , p, procedures described in Case 1 will be executed. (c-2) If pp $ p, information about the lowest acceptable price p p will be sent back to coordination agent CA-A. (c-3) Coordination agent CA-A will communicate the new price information to coordination agent CA-M. (d) Upon notification of CA-A, coordination agent CA-M will inform the user through interface agent IA-A. (d-1) If the user accepts the new price, the same sequence of actions for accepting the order described in Case 1 will be taken. Interface agent IA-A will also record the user’s decision, which will be used to predict the user’s preference in the future. (d-2) If the user rejects the new price, the process will be terminated.
B.-R. Lea et al. / Technovation 25 (2005) 433–441
5. The managerial implication of the proposed MAERP system Intelligent business agents claim to be the next generation of model-based solutions for business-tobusiness and E-Commerce applications (Papazoglou, 2001). This study proposes another application for software agents as an implementation alternative of ERP. There are several implications of using MAERPS to achieve ERP integration without the pitfalls of commercial ERP software packages while taking advantages of existing information systems, as summarized in Table 1. 5.1. Flexibility in implementing MAERP system One of implications is the flexibility of MAERPS compared to commercial ERP software packages. The numbers and types of agents can be added or reduced as needed. The changes in the numbers or types of software agents or the implementation of new agents will not cause disruption or setback of business as a whole. 5.2. Operational and financial impact of implementing MAERP system Another implication is the local impact of system failure. Any failure in a specific area will not cause company-wide system failure because software agents are implemented locally. Unlike the implementation of a commercial ERP software package, there is no risk of data loss due to the conversion of databases from existing systems because data
439
collection agents can access existing databases that were developed in various forms. Furthermore, the implementation cost of a MAERPS is significantly lower than the cost of implementing a commercial ERP software package. By adding software agents, smaller program modules, to current information systems, the MAERP does not require as significant a financial investment as commercial ERP software packages. At the same time, MAERPS will take advantage of the existing information systems that are mature in terms of functionalities and are error free after years of testing, modification, and maintenance. The implementation of MAERP will also embrace an individual department’s own culture and the department’s existing expertise in using technologies. Consequently, there are fewer training needs and lower employee resistance because of the very limited business process redesigns required as well as the lower implementation costs and shorter implantation period. 5.3. Upgrading an MAERP system implementation A MAERP system is doable and easier to maintain, upgrade, or change than a commercial ERP software package. In most of cases, modifications may only be required in the agent interfaces (task agent and/or data collection agent in a department). A MAERP system is more secure than a commercial ERP software package because only limited information is communicated between departments through the use of agents. An enterprise-wise database is not necessary.
Table 1 Managerial implications Implications Impact of system failure Data redundancy, integrity, and accuracy
Traditional information systems Commercial ERP suits
Local impact Data redundancy is likely unavoidable and will result in integrity and accuracy problems Update, modification, and maintenance Difficult Effective decision making via Ineffective decision making due real-time information sharing across to outdated data or difficulty different functional area of obtaining cross functional data System interdependencies Often ignored Conflicting goals Often unavoidable Needs for business process Not applicable redesign due to ERP integration Technology readiness Often not a concern Implementation cost Existing Implementation time Existing Employee training Not needed Customization capability to support Not applicable current business processes
MAERP systems
Global impact Not a problem
Local impact
Easy Improved decision quality because real-time information sharing across functional areas Considered Not a problem Often unavoidable
Easy Improved decision quality because agent can obtain most appropriate/accurate information for used for decision Considered Not a problem Very limited
Critical to implementation success Often underestimated Often underestimated Intensive training needs Limited
Minimum impact Minimum Faster implementation Minimum Flexible
440
B.-R. Lea et al. / Technovation 25 (2005) 433–441
5.4. Availability of commercial shells for implementing MAERP system Although sophisticated software agents can be difficult to build from scratch due to the skills and knowledge needed, the widely available agent construction toolkits may provide a quick and easy start to building software agents without much agent expertise. For example, JATLite (Java Agent Template, Lite), developed at Stanford University, is a Java based toolkit that provides a basic infrastructure in which agents register with an agent message router facilitator using a name and password, connect or disconnect from the Internet, send and receive messages, transfer files, and invoke other programs or actions on the various computers where they are running (Heecheol et al., 2000). ZEUS, developed by British Telecommunications Labs using Java, is a collaborative agent building environment and component library providing a library of software components and tools that facilitate the rapid design, development, and deployment of agent systems (Nwana et al., 1999). Sodabot, a research project of the MIT Artificial Intelligence Lab, offers a universal computational framework for creating and using agent applications that provides the level of abstraction necessary to allow for the simple construction of complex agent applications with a graphic user interface (Coen, 1994). The Java-based agent framework for multi-agent systems (JAFMAS), developed at the University of Cincinnati, supports the implementation of communicating agents in Java and provides communication, linguistic, and coordination support through several Java classes. (Chauhan and Baker, 1998).
6. Conclusion and future research In this paper, we present a multi-agent system that is capable of providing enterprise wide integration. With this approach, we demonstrate that a set of software agents with specialized expertise can be quickly assembled to gather relevant information and knowledge, and more importantly, to cooperate with each other (other agents, information systems, and managers) in order to arrive at timely decisions in dealing with various enterprise scenarios. We provide a simple illustration to show how the proposed MAERP system might work. Through our illustration, we show how numerous actions/commands are executed by various agents, resulting in a multiple phased and structured conversation among agents. The MAERP architecture presented in this research is only the first step toward agent-based ERP systems. Further research is needed to extend the current work and to address its limitations. In cooperation with industry partners, we intend to develop a prototype MAERP system and to demonstrate that more practical and relevant problems can be addressed successfully.
We also intend to show that a systematic approach based on the theory of constraints can be used to develop an agentbased ERP system. Following the ideas proposed in Goldratt (2000), we believe that an agent-based ERP system can be developed with relative ease by focusing first on those components of an organization which are critical for identifying and optimizing the system’s constraints. The ERP system developed in this manner will show immediate impact on the financial performance of an organization. We would also like to extend the applications of the proposed MAERP system to the supply-chain environment where agents can be used to communicate and evaluate the performance of the supply-chain members based on new global performance measures such as throughput dollar days and inventory dollar days as suggested by Gupta (2003).
References Baatz, E., 1996. Ready or Not. CIO Magazine, June 15. Bose, R., Sugumaran, V., 1999. Application of intelligent agent technology for managerial data analysis and mining. Database for Advances in Information Systems 30(1), 77–94. Chauhan, D., Baker, A., 1998. Proceedings of the Second International Conference on Autonomous Agents. JAFMAS: a multi-agent application development system, pp. 100–107. Coen, M., 1994. SodaBot: a software agent environment and construction system. MIT AI Lab Technical Report 1493, June. Davies, W., Edwards, P., 1995. Proceedings of AAAI 1995 Spring Symposium on Information Gathering from Heterogeneous, Distributed Environments. Agent-based knowledge discovery, pp. 34–37. Dahlen, C., Elfsson, J., 1999. An Analysis of the Current and Future ERP Market with Focus on Sweden, Royal Institute of Technology, Stockholm. Fox, M., Barbuceanu, M., Teigen, R., 2000. Agent-oriented supply-chain management. International Journal of Flexible Manufacturing Systems 12, 165–188. Franklin, S., Graesser, A., 1996. Is it an agent, or just a program?: a taxonomy for autonomous agents. In: Muller, J.P., Wooldridge, M.J., Jennings, N.R. (Eds.), Intelligent Agents III: Agent Theories, Architectures, and Languages, Springer-Verlag, New York, pp. 21 –35. Garcia-Flores, R., Wang, X.Z., Goltz, G.E., 2000. Agent-based information flow for process industries’ supply chain modeling. Computer and Chemical Engineering 24, 1135–1141. Goldratt, E.M., 2000. Necessary But Not Sufficient, North River Press, Great Barrington, MA. Gupta, M., 2003. Constraints management—recent advances and practices. International Journal of Production Research 41(4), 647–659. Heecheol, J., Petrie, C.J., Cutkosky, M.R., 2000. JATLite: a Java agent infrastructure with message routing. IEEE Internet Computing 4(2), 87 –96. Hess, T.J., Rees, L., Rakes, T., 2000. Using autonomous software agents to create the next generation of decision support systems. Decision Sciences 31(1), 1–32. Huang, J., Jennings, N., Fox, J., 1995. An agent-based approach to health care management. International Journal of Applied Artificial Intelligence 9(4), 401–420. Ito, T., Saleh, M., 2000. A blackboard-based negotiation for collaborative supply chain system. Journal of Material Processing Technology 107, 398 –403. Jacobs, F., Whybark, D., 2000. Why ERP? A Primer on SAP Implementation, McGraw-Hill Higher Education, Boston.
B.-R. Lea et al. / Technovation 25 (2005) 433–441 Joshi, K., Lauer, T.W., 1999. Transition and change during the implementation of computer based manufacturing process planning system: an analysis using the equity implementation model. IEEE Transactions on Engineering Management 46, 156–167. Jennings, N., Wooldridge, M., 1998. Applications of intelligent agents. Agent Technology Foundations, Applications, and Markets, SpringerVerlag, New York. Jensen, D., Dong, Y., Lerner, B., McCall, E., Osterweil, L., Sutton, S., Wise, A., 1999. Proceedings of the International Joint Conference on Work Activities Coordination and Collaboration. Coordinating agent activities in knowledge discovery processes, pp. 137–146. Kalakota, R., Robinson, M., 2000. e-Business 2.0: Roadmap for Success, Addison Wesley, Boston. Koch, C., Slater, D., Baatz, E., 1999. The ABCs of ERP. CIO Magazine, December 22. Kumar, K., Van Hillegersberg, J., 2000. ERP experiences and evolution. Association for Computing Machinery, Communication of the ACM 43(4), 22–26. Larsson, J., Hayes-Roth, B., 1998. Guardian: an intelligent autonomous agent for medical monitoring and diagnosis. IEEE Intelligent Systems 13(1), 58–64. Mabert, V., Soni, A., Venkataramanan, M., 2001. Enterprise resource planning survey of US manufacturing firms. Business Horizon MayJune, 69–76. Newell, A., 1988. Putting it all together. In: Klahr, D., Kotovsky, K. (Eds.), Complex Information Processing: The Impact of Herbert A. Simon, Lawrence Erlbaum, Hillsdale. Nwana, H.S., Ndumu, D., Lee, L., Collis, J., 1999. ZEUS: a tool-kit for building distributed multi-agent systems. Applied Artificial Intelligence Journal 13(1), 129 –186. Nwana, H.S., 1996. Software agents: an overview. The Knowledge Engineering Review 11(3), 1– 40. Oliver, R., 1999. ERP is dead! long live ERP!. Management Review 88(10), 12–13. Papazoglou, M., 2001. Agent-oriented technology in support of e-business. Communications of the ACM 44(4), 71–77. Peng, Y., Finin, T., Labrou, Y., Chu, B., Long, J., Tolone, J., Boughannam, A., 2002. A multi-agent system for enterprise integration. International Journal of Agile Manufacturing 1(2), 213 –229. Robinson, B., Wilson, F., 2001. Planning for the market? Enterprise Resource Planning Systems and the Contradictions of Capital. Database for Advances in Information Systems, 32(4), 21– 33. Russell, S., Norvig, P., 1995. Artificial Intelligence: A Modern Approach, Prentice Hall, Englewood Cliffs. Satapathy, G., Kumara, S., Moore, L., 1998. Distributed intelligent architecture for logistics (DIAL). Expert System with Applications 14, 409 –424. Slater, D., 1998aa. ERP projects cost more than their Measurable Payback, Study Says. CIO Enterprise 15(January), 26–28. Slater, D., 1998b. The hidden costs of enterprises software. CIO Enterprise Magazine, June 15.
441
Swaminathan, J., Smith, S., Saleh, N., 1998. Modeling supply chain dynamics: a multiagent approach. Decision Sciences 29(3), 607– 632. Van Dyke Parunak, H., 1998. Practical and industrial applications of agentbased systems. White Paper, Industrial Technology Institute. Wooldridge, M., Jennings, N., 1995. Intelligent agents: theory and practice. The Knowledge Engineering Review 10(2), 115–152. Yu, W., Graham, J., 2002. Proceedings of the Seventeenth International Conference on Computers and Their Applications (CATA-2002). A multipleagent architecture for demand forecasting in electronic commerce supply chain system. Bih-Ru Lea is an assistant professor of Business Administration at the School of Management and Information Systems at the University of Missouri—Rolla. Dr. Lea earned her Ph.D. at the Clemson University and is interested in interdisciplinary research and teaching because of her unique academic training in operating management, management accounting, and computer information systems.
Mahesh C. Gupta is a professor in the Department of Management, University of Louisville. He obtained his MCom from the University of Jammu, India, his MSc from the University of Manitoba, Canada, and his PhD from the University of Louisville, USA. Dr. Gupta has published in numerous journals including International Journal of Operations and Production Management, International Journal of Production Research, European Journal of Operational Research, and Production and Inventory Management. Dr. Gupta is a member of APICS, DSI, INFORMS, ASQ, and POMS.
Wen-Bin Yu is an assistant professor of Information Science and Technology at the School of Management and Information Systems, University of Missouri at Rolla. His main research interests are in the fields of software agent applications, business process simulation and demand forecasting especially in a supply-chain environment.
