行政院國家科學委員會專題研究計畫 成果報告
運用網路服務與代理人於 SCM/APS 與 ERP 協同合作架構之研 究
計畫類別： 個別型計畫
計畫編號： NSC93-2213-E-011-029-
執行期間： 93 年 08 月 01 日至 94 年 07 月 31 日 執行單位： 國立臺灣科技大學工業管理系
計畫主持人： 歐陽超
報告類型： 精簡報告
處理方式： 本計畫可公開查詢
中 華 民 國 94 年 9 月 12 日
Developing an Agent-based APS and ERP Collaboration Framework
(Final report for NSC- 93-2213-E-011-029)
C. Ou-Yang S.J. Hon
Department of Industrial Management
National Taiwan University of Science and Technology 43, Sec. 4, Keelung Rd.
Taipei, Taiwan, 106
Abstract
In order to rapidly response to customer demand, SCM and ERP have been widely implemented in the business. However, SCM was designed as a planning level tool to support the business making related activities. For instance, the advanced planning system (APS) in the SCM was aimed at developing a proper production schedule to support the potential orders. On the other hand, ERP was used in the execution level in an enterprise to integrate the order execution related business process. In order to integrate the two systems, there were several gaps exists such as the suitability of using the APS results in the ERP.
In this research, an integrated SCM/APS and ERP framework will be proposed to support the collaboration among these systems. It applies the concept of web service and agent collaboration to support the issues such as workflow integration and collaboration encountered during the integration period. There are three main stages in this framework. In the business analyze stage; the collaboration process among the SCM/APS and ERP will be analyzed and constructed by using eEPC (extended Event Process Chain) modeling method. This resulted process will be used in the next stage, the business design stage to design the agent-based collaboration system. A workflow oriented agent-based analyzed method, WARP (Workflow Automation through Agent-based Reflective Processes), will be used to analyzed the collaboration business process and construct the related agents. Finally, in the implementation level, the related agents will be constructed by integrating i2 FP SCM modules and DataSystem Workflow ERP under the Web-based environment.
Key words: APS, ERP, Web-service, Agent, Collaboration
1. Introduction
In order to support the sales people to obtain the potential customer orders, many companies have implemented ERP technologies to the support the production related analysis occurred during the RFQ (Require for Quotation) stage in the sales campaign process. One of the major tasks of RFQ is to estimate the quantity of the products that can be delivered on time. This includes the jobs such as inventory checking, WIP (work in process) reviewing and re-scheduling the production plan. In general, these tasks should be performed accurately and quickly as well. However, due to the complicated relationships among the sales, inventory and production functions, most of the business can only address on building the bridge among a few functions. For instance, most of the sales might only focus on checking the inventory of the finished products if a customer required an urgent RFQ.
Collaborative product commerce (CPC) is one of the few innovative concepts addressed on linking the gap between design department and the rest of business functions. Basically, CPC is focused on enhancing customer and business visibility and accelerating operational visibility. Companies want to attend the CPC environment must upgrade the inter-net capabilities to allow online product development and service [Rayson 01].
In this research, an integrated SCM/APS and ERP framework will be proposed to bridge the gaps among the sales, inventory and production related business functions.
The major objective of the proposed framework was to provide an environment for the sales people to analyze the production related problems during the RFQ stage in from both the inventory and production scheduling points of view.
This system applied the concept of agent-based collaboration to support the issues such as workflow integration and collaboration among various business functions encountered during the integration period. There are three main stages in this framework. In the business analyze stage; the collaboration process among the SCM/APS and ERP will be analyzed and constructed by using eEPC (extended Event Process Chain) modeling method. This resulted process will be used in the next stage, the business design stage to design the agent-based collaboration system. A workflow oriented agent-based analyzed method, WARP (Workflow Automation through Agent-based Reflective Processes), will be used to analyzed the collaboration business process and construct the related agents. Finally, in the implementation level, the related agents will be constructed by integrating i2 FP SCM modules and DataSystem Workflow ERP under the Web-based environment.
2. Background
The concepts of collaborative product commerce has been widely applied recently due to the rapidly development of the information technology. Basically, there are several kinds of collaborative activities addressed by industries. One occurs in the product design stage. That is, the cooperation among various designing units during the product development stage. For instance, different design unit might be responsible for designing the separate portion of a product, or various design units might share the works for a complicated design project so as to shorten the total product development time. In order to support this kind of cooperation environment, it is necessary to construct a framework such that separate design groups can share the real time design information. Several works have been addressed on applying WWW technologies to integrate the design environment. For instance, Huang et al. have developed a web-based system “CyberReview” to support the collaborative product review process [Huang 01][Huang 02]. This work first defined the mapping processes from the design object to the review criteria. Several on line WWW facilities were provided to support the design review decision making process such as uploading;
downloading and submitting designing documents to the related review sites. Another work was focused on developing a web-based collaborative system for integrating the design and manufacturing activities [Chang 99]. This system applied the feature-based approach to construct the part. The constructed part can then be reviewed by others through the browser in terms of VRML format. The other research was addressed on developing a multi-disciplinary product development and analysis environment [Roy 97]. This system integrated several related tools required for designing, analyzing and manufacturing through a WWW/Internet environment. Therefore, the designers from various stages can apply this tool to cooperate in a product development project.
Recently, several researchers have addressed the concept of incorporating the tasks among the design unit and material management unit [Bartuli 95] [Ou-Yang 01]. In the tradition approach, the design engineers have paid very few attentions in the required materials or components during the product design stage. The results might be the required materials or components cannot be produced or purchased during the following stages and hence cause the necessity of engineering change (EC).
In the mass customized production system, frequently EC activities are necessary but also might increase the difficulties in the product/production management. For instance, EC might increase the production lead-time as well as enhancing complexity of the ERP and scheduling tasks. The results might be the increase of scrap cost, postpone the due date and lower customer satisfaction. Also, it could generate problems in the PDM areas such as version control and configuration management [Cunningham 96][Krishnamurthy 95][Coughlin 92] [Reidelbach 91].
Agent based system has been applied in many fields required mutual cooperation among various organization units. In the shop floor manufacturing, agent has been used to support the collaboration among the controllers of various manufacturing facilities. For instance, an agent-based discrete shop floor control system was developed to coordinate and control a range of shop floor facilities such as CNC and conveyor [Schoop 01]. Another agent-based emulation system was developed to assist a manufacturing system to reach the status of lean manufacturing. This system applied distributed agents to analyze and simulate the production schedule for a pull-based production system [Ivezic 99].
In addition to the area of manufacturing industries, e-commerce is another field focused on agent-based collaboration. An on-line bargaining systems was proposed by Lin et al.. This multi-agent system including three separate agents can be used in a dynamic price issuing and matching environment [Lin01]. Another multi-agent system InterMarket was developed to assist the user to find the potential business opportunities in an on-line marketplace. In terms of two types of agents, mobile agent and intelligent agent, this system can find the potential trading opportunities for the intended sellers or buyers and improve the success probabilities of the trading events [Kowalczyk 02].
In addition to the related research, several agent-based analyze method and implementation tools have been developed. DeLoach has proposed a Multiagent Systems Engineering (MaSE) approach for the tasks of agent system design. This approach modified from the famous Object Modeling Technique (OMT) and Unified Modeling Language (UML), such that it can easily decompose the problem domain and describes the coordination and communication activities among multiple-agents [DeLoach 99]. Another analyzing approach Gaia dealing with both macro and micro level aspects of a design and has developed its own modeling constructs and language [Wooldridge 00]. As for the implementation tools, ZEUS seems a convenient tool. It is a JAVA based toolkit, which provides a visualized design environment. Also, an agent library is provided such that the designer can easily extends the functions of related agents [Nwana 99].
Recently, the development of enterprise application integration (EAI) related tools tend to reduce the complexity of the tasks of integration [Linthicum 01]. In general, the intra and inter-business flow among the integrated applications should be analyzed and specified first. Then, for each activity in the process, the linkage with the components of the related application should be developed. The EAI platform can carry out each activity from its respective application based on the pre-defined business flow.
3. Problem Description
As mentioned before, the major objective of this research was to develop an agent-based integration framework to support the ATP tasks performed by the sales people. In order to develop such a system, several issues would be faced:
1. What kinds of business function and information should be considered in order to fulfill an ATP task?
In general, an ATP task should consider variety of production related activities such as inventory, transportation and WIP, in order to achieve a feasible solution.
These activities belonged to various business functions. Therefore, one of the major issues was to analyze the required business functions and related business information in order to support the ATP task.
2. What is the business process for an ATP task?
As just mentioned, although the sales department was responsible for an ATP task, many other business functions were still required to support the sales personnel.
Since a lot of negotiation activities might be taken place among these functions, the interrelationships among the functions might be complicated. Therefore, the next issue would be to define a proper business flow to represent the complicated cooperation tasks occurred during an ATP activity.
3. What kind of infrastructure is appropriated such that the required business functions could be properly integrated?
According to the previous issues, the proposed framework should support a complicated coordination process included several business functions. Therefore, it is necessary to have an infrastructure that can not only to integrate various business functions, but also to support the negotiation activities among the functions.
Based on the above issue, an agent-based framework integrating an ERP module and an APS module will be proposed to analyze the business flow; to define the related coordination schema; and to construct the integrated infrastructure.
4. The Proposed Framework
Fig-1 shows the structure of the proposed framework. There are three phases in this framework: Analysis Phase, Design Phase and Implementation Phase. In the Analysis phase, the business workflow for the ATP process will be analyzed. There are two sub-phases: Conceptual Analysis and Process Analysis. In general, the macro functions of the ATP task as well as their working sequence will be developed in this phase. Then, the detailed process activities and the related information will be defined in the Process Analysis Phase.
In the Design Phase, an agent analysis approach WARP (Workflow Automation through Agent-based Reflective Processes) [Blake 2003] was modified and used to
analyze the developed ATP process model and to construct the agent-based system.
Basically, WARP was an UML based modeling approach consisted of two main portions. The first one was to specify the workflow and related information of the modeling domain, and the second portion was to define the required agents and their roles and tasks. In other words, in addition to the agent related concepts, the workflow related ideas were also embedded in the WARP approach. A brief introduction about the modified WARP approach would be specified in the next section.
The final phase was the implementation phase consisted of two sub-phases: the implementation analysis phase and the implementation phase. The former phase was to analyze the implementation environment from three points view: interface, agent and web service. Then, based on the analyzed results and the developed agent model, an agent-based APS and ERP collaboration system was developed to perform the ATP function.
4.1 The WARP Approach
There are three main modeling stages required to describe in the WARP modeling approach: structure modeling, dynamic modeling and non-functional modeling (Fig-2-1). Basically, the latter models required the information defined in the previous models.
4.1.1 The Structure Modeling Stage
The major purpose of structure modeling was to define the main services required in a workflow system as well as the roles played by each service in a respective workflow. Basically, the main types of service and their required attributes were be defined in terms of “service representation view” diagram. For example, in a particular web-based workflow system, four types of service were required. They are
“web service”, “DB intranet service”, “remote service” and “payment intranet service”. Their related attributes were defined in Fig-2-2. Each service can play various roles in variant service. These relations were be specified in terms of “role association” diagram. For instance, “web service” would play the role “customer interface” in a particular workflow as shown in Fig-2-3. Finally, the association of the roles with respective to a workflow system were be defined by “workflow structure view” diagram. For example, there are four roles (customer interface, inventory, shipping and payment) required in the workflow “online ordering” as shown in Fig-2-4.
4.1.2 The Dynamic Modeling Stage
The main purpose of dynamic modeling was to show the process sequence of
the roles in a workflow. The “role collaboration” diagram would be used. It is very similar to the activity diagram applied by UML modeling approach. Fig-2-5 shows the role collaboration diagram for the online ordering process. Each role defined in the previous stage has a column in the diagram. For each column, the tasks performed by that role would be specified. In addition, the messages transferred among the tasks during the process of the workflow also were be defined. The processing sequence among the roles and task and the transferred messages would be linked in terms of dotted arrows.
4.1.3 The Non-functional Modeling Stage
The final modeling stage was the non-functional modeling stage. It includes the
“failure atomicity view” model defining the tasks requiring performing while the process failed in the normal situation. Three kinds of diagram were contained in the model: “workflow structure view”, “role collaboration model”, and “control model”.
In general, the former two models were defined during the structuring modeling stage and the dynamic modeling stage. In this phase, only the failure conditions were added into the model. For instance, in Fig-2-6, the failure situation would take place while an invalid ID was typed in. Therefore, the “error handling” aspect was added into the
“workflow structure view”, and the message “invalid ID” and the task “roll-back and abort” was added into the “role collaboration model”.
The concept of the final model, “control model” was very similar to the “role collaboration model” except that the transferred messages among the tasks were not addressed on this model. Therefore, it is not a required model if the “role collaboration model” was specified.
Another model should be addressed in this stage was the “execution atomicity priority view”. Basically, in this stage, the process priority of the services in a workflow was specified in this diagram. For instance, in Fig-2-7, the service
“purchase ticket” should be performed in front of the service “reserve hotel”.
4.1.4 Modified WARP Agent
WARP has defined various types of agents such as “site manager agent”, “global workflow manager agent” … etc.. For each type of agent, it is also required to define three kinds of task components “communication component”, “police execution”
component, and “data management component”. For detailed of these components, please refer to [Blake 02].
In this research, the representation of the agent tasks has been modified in terms of “agent responsibility table” and “agent rule table” The former one was used to define the responsibilities of each agent (Table-1). Each agent can have more then one
responsibilities. The latter one was used to define the rules performed by each agent (Table-2). Each agent also can perform more than one rule.
4.1.5 Standard Operation Flow
In the WARP agent modeling, the operation sequence among various agents can be represented as an UML sequence diagram (Fig-2-8). Each agent can transform from one status to another during its processing period and hence can contain many states. The processing sequence among the different states of an agent as well as the inter-operation sequence among the agents can be represented in terms of sequence diagram.
5. The Proposed ERP/APS Collaboration Model 5.1 Analysis Phase
The major objective of the analysis stage was to find the relationship among advanced planning system (APS) and enterprise resource planning system (ERP). The required analyzed tasks would be defined in the “Concept Analysis Phase”. The inter-operation sequence among APS and ERP would be specified in the “Process Analysis Phase”.
5.1.1 Concept Analysis Phase
In this phase, four types of analysis would be performed. The function analysis was the first tasks to be carried out, followed by data analysis, process analysis and time analysis (Fig-3-1). The time analysis results would be used to modified data analysis model and process analysis model.
In the function analysis, the related subsystems in the APS and ERP modules would be identified first. Then, for the recognized subsystems, their related tasks and the features of these tasks would be identified (Fig-3-2).
Based on the identified features of the tasks in the APS and ERP systems, the related data used by these tasks would be found in the data analysis stage (Fig-3-3).
The required jobs included re-defining the conflicted data items, as well as specifying the data transferred between APS and ERP.
Based on the data transferred among two systems, the process analysis stage would be in charge of two types of work (Fig-3-4). One was to identify the sub-systems in APS and ERP which were responsible for sending and receiving the data. Another was to identify the sequence of the data transferred among the systems.
The APS/ERP collaboration process would be initially identified in this stage.
Once the data transferred sequence was defined, the final stage, time analysis, would be responsible for analyzing the data synchronization problem for the two
systems (Fig-3-5). That was to analyze the proper time for modifying the related data stored in two systems.
5.1.2 Process Analysis Phase
The major objective of this phase was to identify the process co-relation among ERP and APS systems. As mentioned before, the proposed framework was used to support the sales people to perform production related analysis in the RFQ (request for quotation) stage. Therefore, the related business processes including ordering process, material planning process, capacity planning process, purchasing process, and production ordering process. Basically, the ordering process would be carried out once a RFQ was proposed by a customer. Then, the required material and production capacity would be planned based on the contents of this order. Finally, the purchasing process would be arranged and the production order would be planned. The relationships among these processes were shown in Fig-4.
Based on the initial analysis, the next task was to perform the detailed analysis.
Fig-5 showed the process flow represented by an EPC (event process chain) diagram.
Once a customer issued a RFQ, the related product data would store in the ERP system. The inventory check would be carried out by ERP. If the inventory quantities were enough for the order, the related sales personnel should determine to accept the order or reject it. On the other hand, if the inventory was not enough, the insufficient quantities should be input into the APS system to calculate required capacity to produce the products. In addition, the required raw materials also should be analyzed.
The APS system would generate the planning results including the PO (production orders), the factory problems such as insufficient capacity, the workload report, and the MO (manufacturing orders). If the capacity was not enough, the sales personnel should notify the customer to modify the order based on the APS reports. Otherwise the order should be rejected. If the order was modified by the customer, the generated PO and MO should store in the ERP system for later execution.
The final task of this phase was to categorize the tasks in the above process as either APS or ERP functions. For instance, the tasks such as receiving customer order, purchasing, and issuing manufacturing orders should be categorized as ERP functions.
On the other hand, the jobs such as production planning and capacity planning should be considered as APS functions. It was necessary to design related agents to carry out these functions. In addition, it also required the functions such as messages display;
transformation and notification to support the communications among the agent. The relationships of these functions were shown in Fig-6.
5.2 Design Phase
Based on the outcomes of process analysis, the major objective of this phase was to design the suitable agent-based framework in terms of WARP concepts. As mentioned before, this phase should define the agent-based APS/ERP collaboration framework through structure modeling stage, dynamic modeling stage, non-functional modeling stage, as well as standard operation flow.
5.2.1 Use Case Diagram
The use case diagram would define the required functions in the collaboration system. Fig-7 showed these functions and related users. According to the analyzed results from the process analysis phase, the functions such as customer ordering, purchasing, issuing manufacturing orders were used by ERP. On the other hands, the functions such as material planning and capacity planning were categorized as APS functions. In addition, the functions such as message transformation, error detection, and the decision of order acceptance were also necessary. The related personnel in the business as well as the required agents in the system were also defined in this diagram.
5.2.2 Structural Modeling Stage
Three kinds of model should be defined in this stage. Fig-8 showed the Service Representation View of the proposed system. Five kinds of service were defined:
“Order Service”, “Web Service”, “Data Service”, “Suggestion Service” and “Plan Service”. Among those, Order Service supported the tasks such as processing customer orders, issuing manufacturing orders and production orders. Web Service provided the environment such that APS and ERP services can be performed on the web environment. Data Service was responsible the tasks related to database access.
Suggestion Service was used in analyzing whether the services such as inventory level and production schedules could satisfy the orders. Finally, Planning Service supported the APS tasks.
Fig-9 showed the Role Association View of the proposed system. Five types of roles and their respective services were defined. In addition, the required functions in each role were also specified. As can be seen, the role “Order” was used to generate order information provided by “Order Service”. The role “Sales Interface” and “PP (production planning) Interface” were used to perform the data interface tasks carried out by the web service. The role “Agent” was used to carry out “Data Service”,
“Suggestion Service” and “Plan Service”. Finally, “Plan Service” would also be executed by role “Planner”.
The developed roles would be classified into two business processes: “Ordering Process” and “Planning Process” as shown in the workflow structure view (Fig-10).
5.2.3 Dynamic Modeling Stage
Once the roles and their related business were defined, the next task was to identify the correlation among the roles in each business process. The “role collaboration diagram” would be used to representation process sequence among the roles.
Fig-11 showed the role collaboration diagrams for ordering process. As specified in the workflow structure view (Fig-10), three roles “Sales Interface”, “Order” and
“Agent” were included in this process. Fig-11-1 showed the working sequence for these roles in the sub-process “before accepting order”. The “Sales Interface” function
“GetOrderData” would be carried out first, then, the contents of the order would be executed by “InsertOrderData” function of the role “Order”. The next step would be carried out by “MakeSuggestion” of the role “Agent”. The outcomes would be sent to
“ReplySuggestion” function of the role “Sales Interface”.
Fig-11-1 and Fig-11-2 showed the sub-process “after accepting order”. If the contents of the order could be carried out by current production plan, the “role” agent would transfer its planned data to ERP to update its database. In addition, the system would execute “NotifyPurchasingDirector” and “NotifyProductionManager”
functions (Fig-11-1). On the other hand, if the current production plan or inventory level could not satisfy the order and the customer agreed to modify the order contents or due date, then, the APS system should be re-executed (Fig-11-1).
Fig-12 shows the APS planning process. Based on the defined roles, the planner would execute the infinite capacity plan, solve the shop floor and materials related problems, and carried out the CAO (Constraint Anchored Optimization) for the finite capacity plan. The MO (manufacturing orders) and PO (purchasing orders) would be released finally.
5.2.4 Nonfunctional Modeling Stage
One of the major objectives of this stage was to specify certain situations which might cause the system fail or require the system to reset. In this research, the following situations were considered and represented as role collaboration diagrams (Fig-13). One was to manage user login process. Role “Sales Interface” was responsible for this process (Fig-13-1). Another situation was that although the requested order was accepted by company, the customer still not issued the formal order. That is, the system should verify the order status with the customer through sales personnel, and modify the order data if it was not formally issued by that customer (Fig-13-2). The third situation was that the order was rejected. Then, all the order data should be removed from the system (Fig-13-3). The final condition was to
confirm the data transferred from APS to ERP, and to ensure the correctness of the transformation (Fig-13-4).
Another objective of this stage was to specify the working sequence of certain role functions. Fig-13-5 showed the sequence. Basically, the order receiving should be followed by the function of inventory checking, APS planning and making suggestions. This sequence should not be altered during the cooperation operations.
5.2.5 WARP Agent
Once the process sequence of the collaboration systems was defined, the next step was to identify the responsibilities and rules of the agents in the system. Table-3 showed the five agents used in the proposed system and their respective responsibilities. Among those, APS and ERP agents were defined by this research.
The rest three agents were required by the implementation system “ZEUS”. Based on the results of previous modeling stages, the main responsibilities of ERP agent were to receive the customer orders, send the contents of the order as well as the related BOM and routing information to APS for processing planning, and managing the inventory data. In addition, the main duties for APS agent were to perform the processing planning and to determine the potential orders can be carried out or not. Based on their responsibilities, the required rules for ERP and APS agents were shown in Table-4 and Table-5 correspondingly.
5.2.6 The Operation Flow
Once the details of each agent had been defined, the next step was to show the cooperation sequence among the agents and the related users. This was defined in terms of sequence diagrams. For instance, Fig-14 showed a concise case, which is the inventory was enough to satisfy the customer requirement and the customer intended to issue the formal order. In this case, the sales will input the order through interface into ERP database, then, ERP agent would be called to query its inventory database.
The outcomes would be sent to sales manager and the sales personnel to accept the order.
Another example showed a complicated situation (Fig-15). That is the APS outcomes could not satisfy the customer order but the customer could update the order contents and issued the formal order. In this condition, Once ERP agent found the inventory could not satisfy the order, it would call APS agent to perform the planning tasks. The planning results would be sent to the sales department to make proper recommendation to customer. The customer could modify and re-issue the order based on the planning results and available inventory. The APS system would be activated and carried out the planning tasks again. The PO and MO data would be generated
based on the planning results. These data would be sent to ERP database. ERP system would issue the formal production orders and purchasing orders to fulfill the potential customer order.
6. Implementation Phase
The proposed system has been implemented by integrating an ERP system (Data System ERP), an APS System (i2 Factory Planner) and an agent based software (ZEUS). Fig-16 showed the implementation framework. The developed APS agent and ERP agent were built in ZEUS. There are three tasks defined in ZEUS:
ERPDecide, APSDecide, and MOPOdeliver. The rules specified in Table-4 and Tabls-5 were built into these tasks. Then, ERPDecide was assigned to ERP agent, and APSDecide, MOPOdeliver were assigned to APS agent. For instance, Fig-17 showed the rules built in ERPDecide task.
In order to build the communication among the agents; the database of DataSystem ERP and i2 APS, a set of codes written by Java or JSP (JavaService Pages) were developed to assist the communication among users; ERP agent; APS agent, and the respective database (Table-6). Among the codes, the files with “java”
extension were built in ZEUS, and the codes with “jsp” extension were built in a web service development tools “Tomcat”. The responsibilities of the developed codes and their relations with the system entities were shown in the process sequence diagram (Fig-18). Basically, the “java” related codes were responsible for the communication among agents, and ERP/APS database. The “jsp” codes were used for the communication with the users through web interface.
Fig-19-1 showed the BOM of the sample product used in the system test. The related inventory was specified in Fig-19-2. These data were stored in the database of i2 (Fig-19-3).
Fig-20 showed the test sequence. An order was input by the sales through user interface (Fig-20-1). The system would check the inventory based on the order quantity. Since the inventory quantity could not satisfy with the order quantity, the system would prompt to the user to execute the APS (Fig-20-2). Once the user agreed the request, the ERP agent would communicate with APS agent (Fig-20-3). The related rules would be triggered (Fig-20-4) and a process planning task in APS would be carried out. The APS planning output showed that there was no late order and short capacity (Fig-20-5). Therefore, ERP agent would send a mail to the user to notify the planning results (Fig-20-6) and allow the user to communicate with the customer.
7. Conclusions
This research has proposed an agent-based ASP/ERP collaboration system to assist an ATP task in a RFQ process. The major contributions of this research were:
1. Integrating ASP and ERP modules to support the customer order process.
The time consumed in the replying an RFQ might play a critical role in the successful of achieving that order. As mentioned before, the information of an order was stored in an ERP system. However, most of the ERP system still lacks the capabilities of calculating the required production capacity of a potential order.
Therefore, the proposed integration system would improve the efficiency of RFQ.
That is, the sales could spend less time in responding an RFQ based on more accurate production planning results.
2. A framework was proposed to build an agent-based system to support APS and ERP collaboration activities.
This research has proposed a framework to build an agent-based system from process analysis stage, through agent system analysis stage, till final integration system development phase. In addition, by means of WARP analysis approach, the agent-based collaboration system can be carried out in web environment.
Few possible future works includes:
1. The RFQ process focused on this research could only process one order each time.
The concept of processing multiple orders was not addressed on this work. The business process would be more complicated for that case. It might require additional agents to process the inter-actions among ERP and APS, and hence worth for further research.
2. This research only addressed on one ERP system. Since for a complicated business environment, a company might install more than one kind of ERP to process complicated orders and production process. It required further works to build the business process and to analyze the cooperation activities for that condition.
Acknowledgement
The authors would like to acknowledge the financial support by National Science Council, Taiwan, through project no. NSC- 93-2213-E-011-029
Reference
[Bartuli 95] G. Bartuli and R. W. Bourke, “The Best of Both World: Planning For Effective Coexistence of Product Data Management and MRP II System”, http://www.pdmic.com/articles/bestboth.html, 1995.
[Blake 02] M.B. Blake, ”An Agent-Based Cross-Organizational Workflow Architecture in Support of Web Services”, Proceedings of the 11th IEEE WETICE 2002/IEEE Computer Society Press, Pittsburgh, PA, 2002.
[Blake 03] M.B. Blake, and H. Gomaa, " Object-Oriented Modeling Approaches to Agent-Based Cross-Organizational Workflow" , Software Engineering for Large-Scale Multi-Agent Systems (SELMAS2003) in conjunction with the International Conference on Software Engineering (ICSE2003), 2003
[Chang 99] H.C. Chang and F.L. Lu, “WWW-Based Collaborative System for Integrated Design and Manufacturing”, Concurrent Engineering: Research and Applications, Vol.7, No.4, 1999, p319-p334.
[Coughlin 92] P.D. Coughlin, “Engineering Change and Manufacturing Deployment in New Product Development”, Integrated Design and Manufacturing for Competitive Advantage, edited by G.I. Susman, Oxford University Press, p157-p177, 1992
[Cunningham 96] M. Cunningham, P. Higgins and J. Browne, “A Decision Support Tool for Planning Bills-of-Material”, Production Planning & Control, Vol.7, No.3, 1996, p312-p328.
[Diprima, 82] M. Diprima, “Engineering change control and implementation considerations”, Production and Inventory Management, 1st Quarter, 1982, p81-p87.
[Fogarty 91]D.W. Fogarty, J.H. Blackstone, JR. and T.R. Hoffmann, Production and Inventory Management , South-Western, Ohio, USA, 1991.
[Huang 01] G.Q. Huang, S.W. Lee and K.L. Mak, “Synchronised Web Applications for Product Development in the 21st Century”, International Journal of Advanced Manufacturing Technology, Vol. 18, 2001, p605-p613.
[Huang 02] G.Q. Huang, “Web-based Support for Collaborative Product Design Review”, Computers in Industry, Vol. 48, 2002, p71-p88.
[Krishnamurthy 95] K. Krishnamurthy, K.H. Law, “A Data Management Model for Design Change Control”, Concurrent Engineering : Research and Applications, Vol. 3, No. 4, 1995, p329-p343.
[Linthicum 01] D.S. Linthicum, B2B Application Integration, Addison Wesley, NJ, 2001.
[Martely 89] R. Martely, “Reduction in Lead Time Does Make the Difference in Profitable Operations”, Industrial Engineering, October, 1989, p25-p30.
[Ou-Yang 01] C. Ou-Yang and H.C. Liu, “Developing and Computer-aided Environment to Investigate the Influence of Design Schedule Changes on MRP”,
International Journal of Advanced Manufacturing Technology, Vol.17, p.11-p.16, 2001.
[Rayson 01] P. Rayson, “Relate, Empower and Free”, Manufacturing Engineer, Feb, 2001, p8-p12.
[Reidelbach 91] M.A. Reidelbach, “Engineering Change Management for Long Lead-Time Production Environments”, Production and Inventory Management Journal, 2nd Quarter, 1991, p84-p88,.
[Roy 97] U. Roy, B. Bharadwaj, S.S. Kodkani and M. Cargian, “Product Development in a Collaborative Design Environment”, Concurrent Engineering: Research and Applications, Vol.5, No.4, 1997, p347-p365.
[Sky 99] R.W.E. Sky and R.O. Buchal, “Modeling and Implementing Concurrent Engineering in a Virtual Collaborative Environment”, Concurrent Engineering:
Research and Applications, Vol.7, No.4, 1999, p279-p289.
[Ye, 02] N. Ye, “Information Infrastructure of Engineering Collaboration in a Distributed Virtual Enterprise”, International Journal of Computer Integrated Manufacturing, Vol.15, No.3, 2002, p265-p273.
Event
Function Organization
Unit
Event
Function Data
Fig-1 Proposed Framework
(1)
(2)
(3) (4)
(5) (6)
(7) (8)
Fig-2 WARP Methodologies [Blake 00]
(1)
(2)
(3)
(4)
(5)
Fig-3 Concept Analysis Phase
Ordering Process
Material Planning Process
Capacity Planning Process
Procurement Process
Issue Production Order Process
Fig-4 Relationships among the Main Business Processes
Input Order to APS APS System
Solve Material Shortage
Problem s
Manual Finite Capacity
CAO Material Planning
Reports
Automatic Finite Capacity
C AO Solved
Material Problem s Unsolved
Material Problems
Unsolved Capacity Problem s Solved
Capacity Problem s Capacity Planning
Reports
Factory Problem s
Generate Workload
Generate MO Generate
PO
Process Order Custom er Issues a RFQ
ERP Order System
Sales Dept.
Production Dept.
Generate Planning Results
Stored ERP Order Data
Finish Input Order
Infinite Capacity Plan
Check Inventory
Inventory Enough Inventory not
Eoungh
Determine Order Executability
Modified Order
Rejected Order
Cancel the ERP Order Approve
ERP Order
Generate Factory Problem s
Report
Finish ERP Process
Finish ERP Process
Fig-5 Production Analysis Process in a RFQ
Input PO to ERP
Input MO to ERP ERP
Procurement System
ERP Manufacturing System Generate
Workload
Generate MO Generate
PO
Purchase Dept.
Finish Input PO
Finish Input MO Generate Factory Problems
Report
Determine Order Executiabilities
Order cannot be Carried Out
Order can be Carried Out
Notify Customer
Modified Order
Rejected Order
Carry Out APS Update Order
Updated Order
Update Order Data to APS
Updated Data
Finish Planning
Notify Customer
Modified Order
Rejected Order
Fig-5 Production Analysis Process in a RFQ (Continued)
Fig-6 Functional Relationships Diagram
Fig-7 Use Case Diagram for the Collaboration Framework
Fig-8 Service Representation View
Fig-9 Role Association View
Fig-10 Workflow Structure View
(1)
(2) (3)
Fig-11 Role Collaboration Model for Ordering Process
Fig-12 Planning Process
(1)
(2)
(3) (4)
(5)
Fig-13 Failure Atomicity and Recovery Handling Views
Fig-14 Operation Flow Diagram for One Cooperation Condition
ERP Agent interface
Sales ERP DB
call ERPAgent
Reply Inventory Quantity
Make a Suggestion base on Rules
Notify Sales Manager to Approve Order
Sales Manager
Input Order Data
Insert Order Data
Query Inventory Quantity
Approve Order
APS Agent APS DB Production Management Purchasing People
Call APSAgent
Tell Order Data
Insert Order Data Tell Order Data
Detect Data
Detect Result
Notify Production Management to Run APS
Finish APS and Tell APS Result Call APSAgent
Tell APS Result
Make a Suggestion base on Rules
Tell Suggestion
Tell Suggestion Result
Get MO,PO Data
Reply MO,PO Data
Tell MO,PO Data
Insert MO,PO Data
Detect Data
Detect Result
Detect Result Notify Production Management to Make Products
Notify Purchasing People to Purchase Materials Agent's Responsibility：
ERPAgent - RA5
Update Order Data
Update Order Data
Call APSAgent
Agent's Responsibility：
APSAgent - RA5 Agent's Responsibility：
APSAgent - RA3 Reply Inventory Quantity
Make a Suggestion base on Rules Query Inventory Quantity
Call APSAgent
Update Order Data
Update Order Data
Notify Production Management to Run APS
Finish APS and Tell APS Result
Fig-15 Operation Flow Diagram for another Cooperation Condition
Application Service Site
Ethernet
APS Agent ERP Agent Web server
I2 Factory Planner Txt DB
DataSystem Workflow ERP MS SQL
2000
ZEUS Tomcat
Fig-16 Implementation Framework
Fig-17 Rules Setting for Task ERPDecide
Fig-18 Roles of the Developed Codes in the Coordination Process
ERP Agent interface
Sales ERP DB
call ERPAgent
Reply Inventory Quantity
Make a Suggestion base on Rules
Notify Sales Manager to Approve Order
Sales Manager
Input Order Data
Insert Order Data
Query Inventory Quantity
Approve Order
APS Agent APS DB Production Management Purchasing People
Call APSAgent Tell Order Data
Insert Order Data Tell Order Data
Detect Data
Detect Result
Notify Production Management to Run APS
Finish APS and Tell APS Result Call APSAgent
Tell APS Result
Make a Suggestion base on Rules
Tell Suggestion
Tell Suggestion Result
Get MO,PO Data Reply MO,PO Data
Tell MO,PO Data Insert MO,PO Data
Detect Data
Detect Result
Detect Result Notify Production Management to Make Products
Notify Purchasing People to Purchase Materials index.jsp, Login.jsp,
DOinput.jsp DOinput1.jsp
Update Order Data
Update Order Data
Call APSAgent Reply Inventory Quantity
Make a Suggestion base on Rules Query Inventory Quantity
Call APSAgent Update Order Data
Update Order Data
Notify Production Management to Run APS
Finish APS and Tell APS Result
ERPEP.java, ERPThread.java ERPAgent.java
ERPDecide.clp ERPAgent.java
APSEP.java APSAgent.java Mailer.java
FPvaluesInput.jsp FPvaluesOK.jsp
APSEP.java, APSThread.java APSAgent.java
APSDecide.clp APSAgent.java
ERPEP.java, Mailer.java ERPAgent.java
DOquery.jsp, DOresult.jsp DOupdate.jsp
ReplayDO.jsp
NotifySM.jsp, NotifySMOK.jsp
DOquerySM.jsp, DOresultSM.jsp approve.jsp
APSEP.java, APSThread.java APSAgent.java MOPOdecide.clp
ERPEP.java ERPAgent.java
APSEP.java, Mailer.java APSAgent.java
(1)
Item Code Item Name Item Quantity
NAIL NAIL 10000
GLUE GLUE 50000
WOOD WOOD 1000
LAMINATE LAMINATE 300
PARTICLE_BOARD PARTICLE_BOARD 350
LEG LEG 150
TABLE_TOP TABLE_TOP 0
TABLE TABLE 0
(2)
(3)
Fig-19 Sample Product and Its Inventory (A)
(B)
(1) (2)
(3)
(4)
(5)
(6)
Fig-20 The Execution of the Integration System APSAgen
ERPAgen
Agent Type Responsibility by Agent
Agent A 1. Responsibility 1
2. Responsibility 2
Table 1 Agent Responsibility Table
Rules Rule 1 IF
Received messages THEN
Performed related actions
Table 2 Agent Rules Table
Agent Type Responsibilities of Agent (RA) ERP Agent
(Designed by this research)
1. Identify the inventory status, and require APS to ensure the feasibility of accepting order.
2. Send the order information to APS.
3. Store the manufacturing orders and purchasing data into ERP.
4. Notify sales to accept or reject the order.
5. Detect the correctness of data transferred from ERP to APS.
APS Agent (Designed by this research)
1. Store the customer orders into APS.
2. Analyze the production status and to assist ERP Agent to determine the order status.
3. Notify APS outcomes to ERP
4. Notify the production department and purchasing department to execute the production plan purchasing respectively.
5. Detect the correctness of data transferred from APS to ERP.
Agent Name Servers (ANS)
(ZEUS required)
1. Store the IP address for each agent.
Facilitators (ZEUS required)
1. Store the functions of each agent.
Visualizer (ZEUS required)
1. Provide agent user interface.
2. Monitor agent communication status.
Table-3 Agent Responsibilities
R1 IF
Receive the order information from user interface AND
The order data was not analyzed THEN
Query the inventory status from EPR database R2 IF
inventory quantity≧order quantity THEN
Notify sales that the order can be accepted.
R3 IF
inventory quantity＜order quantity THEN
Call APS agent and transfer the order contents to APS agent (2) Received the planning outcomes from APS agent
R4 IF
Customer order analyzed outcome received from APS agent THEN
Send the analyzed outcome and inventory data to sales (3) Received MO, PO from APS agent
R5 IF
MO and PO received from APS agent THEN
Store MO and PO into ERP database and call APS agent to check the data correctness
(4) Receive APS agent request for data verifying R6 IF
Receive APS agent request for data verifying THEN
Check ERP and APS database and notify production control to carry out APS plan
Table-4 Rules of ERP Agent
(5) Receive order change data R7 IF
Receive modified order information from user interface THEN
Update ERP database and call APS agent and transfer the order contents to APS agent
(6) Query inventory update R8 IF
ERP inventory has been consumed THEN
Re-execute APS planning
Table-4 Rules of ERP Agent (Continued)
(1) Receive order information from ERP agent R1 IF
Receive order information from ERP agent THEN
Store the data in APS database, and call ERP agent for data validation (2) Analyze factory problems
R2 IF
Receive APS factory problem analyzed outcomes THEN
Determine customer order acceptable R3 IF
factory has no problem THEN
Inform ERP agent to accept the order and can be fulfilled within due data
R4 IF
Factory has production delay or short quantity THEN
Inform ERP agent the possible delay or short quantity R5 IF
Factory has production delay only THEN
Inform ERP agent the possible delay (3)Inform APS planning outcomes to ERP agent R6 IF
ERP required MO and PO THEN
Transfer MO and purchasing data to ERP Agent (4) ERP Agent request data check
R7 IF
ERP agent requested data confirmation THEN
Check ERP and APS database and send the outcomes to production and purchasing people
Table-5 Rules of APS Agent
File Name Functions ERPAgent.java Communicate with ERP system APSAgent.java Communicate with i2 APS
ERPDecide.clp Analysis the inventory and communicate with APSAgent APSDecide.clp Assist ERPAgent to analyze the order contents
MOPOdeliver.clp Send MO、PO data to ERPAgent
ERPThread.java Support ERPAgent to identify the data delivered from JSP interface
APSThread.java Support APSAgent to identify the data delivered from JSP interface
Login.jsp ERP＆APS Web service interface DOinput.jsp、
DOinput1.jsp
Interface for order input Interface for inventory check DOquery.jsp、
DOresult.jsp
Order query interface (for sales people)
DOquerySM.jsp DOresultSM.jsp
Order query interface (for sales manager)
DOupdate.jsp Order data update
ReplayDO.jsp Reply customer about order planning outcomes voidDO.jsp Order cancel
approve.jsp Order approve FPvaluesInput.jsp
FPvaluesOK.jsp
Input the data of factory problems analyzed from APS
NotifySM.jsp NotifySMOK.jsp
Notify sales manager
Table-6 JSP (JavaServer Pages) Codes and Related Functions
