Ea Article(2)

The Journal of Systems and Software 60 (2002) 195–209 www.elsevier.com/locate/jss

A reference system for internet based inter-enterprise electronic commerce Kitae Shin a, Choon Seong Leem b

b,*

a Department of Industrial Systems Engineering, Daejin University, South Korea Department of Computer and Industrial Engineering, Yonsei University, 134, Shinchon-Dong, Seodaemoon-Ku, Seoul 120-749, South Korea

Received 1 June 2000; received in revised form 1 December 2000; accepted 1 March 2001

Abstract As supply chain management and its global outsourcing are widely spread recently, many researches and development focus on integration of inter-enterprise information systems. The most important factors to achieve inter-enterprise integration are standardization and digitalization. The objectives of this work are to develop the reference model for internet based inter-enterprise electronic commerce and to implement a prototype system for its fundamental issues such as business process, information standards, and information system integration. The electronics assembly processes are chosen as the target industry. For the reference architecture of inter-enterprise electronic commerce, we also investigate intra-enterprise business processes and model them with IDEF0. The standard documents and its items are defined from analysis of traditional documents for outsourcing processes and EDI documents. For standard exchange method, web-based XML is adopted, and corresponding DTD and XSL for RFQ and Quotation are developed. In order to prove feasibility and effectiveness of the reference system a prototype system is introduced and implemented.
2002 Elsevier Science Inc. All rights reserved. Keywords: Inter-enterprise electronic commerce; Reference architecture; Function model; Information model; Standard document; XML-EDI

1. Introduction Electronic commerce (EC) can be defined as ‘to use information technology for improving business relations between trading partners’. The objects of EC are to reinvent the business process, reduce the cost, enhance customer satisfaction and finally increase the profit of the enterprise by integrating the individual information technology for automatic exchange of business related information. The basic expectation of adopting EC is to allocate all enterprise resources optimally for the improvement of enterprise’s competitiveness. It means new management paradigm enabling each enterprise to focus on its specialized function or field and to get prominent revenue through it. This requires not only intra-enterprise integration but also inter-enterprise integration (Kalakota and Whinston, 1996). The most important factors to achieve inter-enterprise integration are standardization and digitalization. Especially regarding standardization, there are several

*

Corresponding author. Tel.: +82-2-2123-4011; fax: +82-2-364-7807. E-mail address: [email protected] (C.S. Leem).

issues according to various hardware, software, documents and trading customs in typical companies. Because of these diversities, the standards for electronic documents and business processes are essential to accomplish the electronic commerce between enterprises (Orsolya and Sobah, 2000). There must be openness to adopt common protocols for using these standards through entire industry. Internet is recognized as the most useful communication media for electronic commerce. Internet makes it possible that almost every computing systems can be connected by TCP/IP and gives basement for employing platform-independent software and multi media functionalities by world wide web. Thus, it is very natural to investigate internet based inter-enterprise electronic commerce using information technology and standards to efficiently react for rapidly changing environments (Troy et al., 1999). The objectives of this work are to develop the reference model for internet based inter-enterprise electronic commerce and to implement a prototype system for its fundamental issues such as business process, information standards, and information system integration. The target industry in the work is electronics assembly supply chain and the target business is its outsourcing

0164-1212/02/$ - see front matter
2002 Elsevier Science Inc. All rights reserved. PII: S 0 1 6 4 - 1 2 1 2 ( 0 1 ) 0 0 0 9 2 - 9

196

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

process. The research scope is to develop standards for related business processes and their information exchange, to develop XML EDI as the standard exchange method, and to implement a prototype system. The remainder of this paper is organized as follows. First we introduce a reference model for inter-enterprise electronic commerce. Then we focus on functional models of the intra-enterprise activities related outsourcing. These are separately modeled in the viewpoint of contractor and supplier. We explain the information standards and information exchange system based on XML. Finally the concept of a prototype system and its implementation is described.

2.1.2. Purdue reference architecture (PERA) The Purdue Laboratory for Applied Industrial Control developed PERA as an endeavor in enterprise modeling for a CIM factory. The functional descriptions of the tasks and functions of the enterprise are divided into two major streams – information stream and manufacturing/customer service stream. The two functional streams are rearranged into three implementation sets of tasks and functions. They are human activities that are information and manufacturing/customer service related, information stream activities not carried out by humans, and manufacturing/customer service activities not carried out by humans (Bernus et al., 1996).

2. Reference architecture for inter-enterprise integration

2.1.3. GRAI model A GRAI conceptual model of a manufacturing system consists of three subsystems. The physical system transforms materials into products. This is coordinated by a hierarchy of control or decision system. The information system carries out all data transfers between and within these subsystems. In the life cycle of a manufacturing system, the analysis phase is to study the current structure and behavior of the system. And it also identifies constraints, goals and possible inconsistencies with cross-checking using GRAIgrid and GRAInet. The design specification phase determines the functional specification, the basic framework and the general behavior of the desired system. GRAI model is developed into GRAI integrated method (GIM) which uses existing systems design and cross-checking methods to help achieve simultaneous consideration of the decision, information and physical system (Doumeingts et al., 1995).

2.1. Enterprise reference architecture Enterprise reference architecture is a set of models that describe how an enterprise system functions from various points of view. It describes the system at its development stages from various perspectives. It aims to capture, standardize and utilize the similar aspects and features found throughout the enterprise (Bin and Yunlung, 2000). There are several famous reference architectures. 2.1.1. CIMOSA model The computer-integrated manufacturing open system architecture (CIMOSA) modeling framework follows a top-down and process-oriented structural approach to provide a complete presentation of an enterprise (Kosanke, 1995). The objective of CIMOSA is the appropriate integration of enterprise operations by means of efficient information exchange within the enterprise with the help of information technology. It defines an integrated methodology to support all phases of a CIM system life-cycle from requirements specification, through system design, implementation, operation and maintenance. In order to model specific aspects of the enterprise, CIMOSA defines four different views concerned with the enterprise. They are function, information, resource and organization. CIMOSA considers an enterprise function as a unified construct of the business user’s view of what tasks are required to achieve a particular enterprise objective. The enterprise function consists of three major section – functional part, behavior part, and structure part. The functional part captures the objective and constraints, as well as the relationship between inputs and outputs. The behavior part captures the dynamic section of the enterprise function such as procedural rules for flow of control. The structure part specifies the relationship among different levels of decomposition within a given enterprise function (Fox and Gruninger, 1998).

2.1.4. Architecture of integrated information systems (ARIS) The backbone of ARIS is a business process, each of which is specified according to four view. The organization view is created to group system entities and facilities. The data view is comprised of data entities that are responsible for recording manufacturing data and message that trigger activities. The function view is used to group the processes of the enterprise into a functional hierarchy. The control view provides the central role in the ARIS framework, logically linking the three other views by using the event driven process chain diagram (EPC). This architecture is mainly focused on the information systems for industrial operations (Scheer, 1994). 2.2. Inter-enterprise reference architecture Although previous works still stand for conceptual frameworks of enterprise integration, their focuses are made mainly on intra-enterprise business process. It is

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

very clear that reference architecture for inter-enterprise business transactions are required toward electric commerce. For more efficient inter-enterprise electronic commerce, intra-enterprise resources also have to be integrated for mutual access and usage the information systems can give fundamental base for information sharing and business process improvement (Troy et al., 1999). Further things are required to make it true. First, it is necessary to make standards of EC not only for intra-enterprise but also for inter-enterprise. The standards include information, format, and business processes. Second, multi-media and information technologies are essential for business interface and information sharing. Third, there must be open mind to share their business information to increase overall performance. Let us consider the example of integration through EC in electronic assembly supply chain. A supplier can make online access to product engineering information which contractor provided. A contractor can also trigger the supplier’s production and procurement process and monitor its progresses in real time. This means that each company takes role as a department in an enterprise and they can share required information with seamless business process linkage. Inter-enterprise integration is more essential as EC becomes more popular. This integration needs to be agile to adapt to changing environment. In the near future, functionally specialized companies that meet the requirement could organize and part by projects and they will make virtual corporations. To support this, it is very important to develop the reference model for interenterprise commerce. The reference model can clarify the business processes, interfaces, and information and give firm base of standards for enterprise integration. Fig. 1 depicts the model of inter-enterprise business processes, documents, and related intra-enterprise processes. The model is developed based on the entire trading process characterized by contractor and supplier in the electronic assembly industry. The starting point of the model is contractor’s database that is entered by sales department. The end point is payment checking. The following sections are detail explanation about corresponding business process. 2.3. Outsourcing process A model to represent detailed outsourcing process among inter-enterprise trade is developed. In our model the process started from outsourcing requirement that was caused by product development, insufficient inventory, or other reasons. This process is constituted with requirement for quotation, selection, contract, receiving, inspection, and finally payment. Following are short explanation for major processes (CommerceNet; Internet supply chain partner interfaces; OMG; OAG; Ro-

197

settanet; SAP, 1998a; SAP, 1998b; Scheer, 1992; Wil and Van, 2000). • Requirements for outsourcing: This is the starting point of inter-enterprise trade. These requirements come from production planning, scheduling, material resource planning (MRP), and capacity requirement planning (CRP). Production department decides the items and quantities based on various information. • Acquiring related information: When there is requirement for outsourcing, a company acquires information about needed products. New suppliers can send their catalog or the company can distribute its acquisition plan to possible suppliers. • Pre-selection: The company selects the suppliers and sends them require for quotation (RFQ). Decisions are made using acquired information such as contractors, factory status, and managers by primary review and interview. Product catalog is also required for further investigation of product specifications. • Request for quotations: The company makes request for quotations (RFQs) after the analysis of product catalogues. In the catalogue analysis, specifications, quality, color, etc are used as criteria. • Selection of supplier and shipment of product data package: The company selects suppliers by re-established criteria from received quotations. Then they make product data package (PDP) for suppliers review. PDP contains detail information of products such as drawings, bill of materials, specifications, and information needed for parts assembly. PDP is sent to the selected suppliers and the suppliers can send their opinion for engineering change. • Contract: After negotiation of contract conditions such as unit price, quality, delivery conditions etc, contract details are fixed. The contract becomes the restricting framework for the following processes. • Release order and expedite: After contract, the company releases order according to contract and regularly checks the progress. If there is delay, they expedite or try to make alternatives. The checking frequency is dependent on importance of the items. • Goods receipts and inspection: Receipt department usually does this process. They prepare goods receipts with shipping notifications by suppliers. The supplier invoice is verified using item name, quantity, unit price, and delivery date with outsourcing order. After the goods receipts, inspection process checks the quantity, quality, and delivery date. If there is a delivery delay or product fault, they can give penalty to suppliers by contract. • Payment: The results of goods receipt and inspection are posted to accounting department. Accounting department pays to suppliers after verification of outsourcing order, invoice, and received goods.

198

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

Fig. 1. Reference architecture of inter-enterprise electronic commerce.

2.4. Order receiving process In this study we assume that suppliers open information in public about their company and products. Our model begins at the process of production capacity review after they receive trade suggestion such as inquiry or request for quotation (CommerceNet; Internet supply chain partner interfaces; OMG; OAG; Rosettanet; SAP, 1998a; SAP, 1998b; Scheer, 1992; Wil and Van, 2000).

• Production capacity review: When a supplier receives RFQ, they investigate their refined production capacity. Sales department checks master production scheduling (MPS), bill of materials, and inventory records. Based on these information, sales department finds out feasible production capacity and the possibility of new production order release, and order quantity modification. • Release quotation: Inquiry and quotation serve as guides to crucial presales processes. RFQ contains

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

•

•

•

•

•

drawings, product specification, quantity, quality specification, and due date. Suppliers refer it when they prepare quotation. Quotations contain price condition, production condition, and delivery condition. Price condition represents unit price, billing, and processing/material costs. Production condition can include borrowing of materials or fixtures. Product data package review and confirm: The suppliers have to review PDP precisely before final confirm of contract. They compare their production skill and capability with product specification. They send engineering change request if needed. After the engineering review and change are finished, both sides confirm PDP. Contract: The contract specifies that customer will order a certain quantity of product from the supplier during a specified period. Contract usually contains all negotiation results such as price, duration, production, and delivery conditions. Receive orders: After the contract, the suppliers receive order according to the contract and stars production. If there are any changes of schedule or engineering, they notify to customers and discuss with them. The received orders are sent to production department to make production plan and check inventory. Shipping notification and delivery: After production is finished, the suppliers release shipping notification. If it is delayed than the due date of contract, they discuss with the contractor. They ship and deliver the product to the predefined destination with the predefined method by the contract. Billing: Order receiving processes conclude with billing. The supplier receives inspection results about quantity, quality, and delivery date. They make invoice with comparison of issue document and delivery document. Billing methods, such as separate invoice, collective invoice, and split invoice, are determined by the contract.

3. Functional model for inter-enterprise integration For framework of inter-enterprise EC, it is needed to identify related business processes and to define the required information and interface between enterprises. The inter-enterprise business processes are developed with IDEF0. These models are characterized by both sides, i.e. contractor and supplier (IDEF, 1993). 3.1. Outsourcing process Table 1 shows the structure of outsourcing processes, while Figs. 2 and 3 illustrate their IDEF0 function modeling. Corresponding explanations are as follows

199

Table 1 Structure of outsourcing processes A0: Outsourcing A1: Set up the selection criteria A11: Market survey and analysis A12: Decide outsourcing items A13: Decide exception for outsourcing A14: Decide supplier selection criteria A2: Select supplier A21: Request for quotation A22: Review the quotations A23: Investigate the supplier A24: Select supplier A3: Contract A31: Release product data package A32: Review the prototype A33: Negotiate the contract options A34: Negotiate price A35: Contract A4: Manage progress A41: Order management A42: Progress management A43: Goods receipt and inspection A44: Payment

(Internet supply chain partner interfaces; SAP, 1998a; SAP, 1998b). 3.1.1. Set up the selection criteria Production planning such as scheduling, MRP, and CRP, can initiate the screening process of outsourcing items. For the selected items engineering requirements and constraints are considered and these can be turned out to conditions for supplier selection. In market survey, company investigates the state-of-the-art technology and product, price, and trade conditions for required items. The outsourcing item list is finally determined after the comparison of the market survey results and item management information in the company. The exceptions and restrictions of outsourcing are determined by law restriction like patents, customer special request, specified manufacturer, and/or security. These restrictions may prevent the company from outsourcing and they have to in-house produce or specially manage that outsourcing. The selection criteria are defined based on the market survey for the selected outsourcing items. 3.1.2. Select supplier The company can send RFQ to pre-selected suppliers or entitle the notice for bid. When the company receives the quotations, they keep them securely and select negotiable suppliers. They will receive company introductory document that contains company name, history, capital, built-up date, trade information, product information, and product capacity. After review of that document, they may visit the suppliers and investigate the management status, current production status,

200

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

Fig. 2. IDEF0 function model of outsourcing (A0).

Fig. 3. IDEF0 function model of contract (A3).

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

quality assurance activity, and shop status. This activity also includes interview with executives. They compare and select suppliers that they need with the results from review and investigation. They also determine the trade level of the supplier. This can be used as the level of progress management. 3.1.3. Contract The company negotiates with selected suppliers. They discuss with suppliers about the details of the contract, such as quality assurance, trade options, delivery, and price. The final contract is made after settlement. At the early stage of contract processes the company releases PDP that contains the detailed production information. The selected supplier has to review that and request the engineering change if necessary. Then the supplier sends the prototype made by PDP. The company confirms PDP after checking the engineering change request and the prototype. To set up detailed contract options, they discuss about quality assurance, claim procedure, packaging, delivery, and ordering policy. They also negotiate pricing policy including payment conditions and methods. After all the things are settled down they exchange contract documents. 3.1.4. Manage progress The order is fulfilled as in the contract. These activities contain order management, progress management, and payment. Order management starts from the receiving of request for outsourcing and screens them, and releases order to the contracted suppliers. Production or inventory department request progress information. The progress management inquires the production progress to the supplier by predetermined interval or the request from other departments. If there is some delay they expedite or make alternatives. When they receive shipping notification, inventory management department prepares the goods receipts. The supplier’s invoice is verified with received goods and order information. Inspection process checks the quantity, quality, and delivery date. Inspection results can be used as supplier evaluation. Inventory data are updated and goods receipts information are sent to production department. The results of goods receipts are also posted to accounting department to prepare payment according to payment methods of contract. 3.2. Order receiving process Table 2 shows the structure of order receiving processes, while Figs. 4 and 5 illustrate their IDEF0 function modeling. Corresponding explanations are as follows (Internet supply chain partner interfaces; SAP, 1998a; SAP, 1998b).

201

Table 2 Structure of order receiving processes A0: Order receiving A1: Process quotation A11: Market survey A12: Receive request for quotation A13: Send quotation A2: Contract A21: Receive product data package A22: Send the prototype A23: Negotiate the contract options A24: Negotiate price A25: Contract A3: Manage progress A31: Order receiving management A32: Production planning A321: BOM management A322: Inventory management A323: Master production planning A324: Material requirement planning A325 L Capacity requirement planning A33: Progress management A34: Shipping management A35: Invoicing

3.2.1. Process quotation A supplier regularly gathers the market information to prepare order receiving. To get market information they survey market trend by searching industry status. When they receive inquiry or RFQ, they review suggestion and reply for that. They may use market information, such as trade and technology development status of other companies in the same industry, as references to set up the trade directions and conditions. When the suppliers receive inquiries or RFQ, they have to reply after checking for engineering feasibility, available-to-promise (ATP), and profitability. This activity is closely related with engineering, production, and finance department. The quotation is released to the customer. This can include some modification from original RFQ and customers can also request change options. 3.2.2. Manage progress After the contract, the supplier receives orders according to the contract and starts production. When the order is received, the supplier reply orders confirmation. The received orders are sent to production department to make production plan and check inventory. BOM management extracts product structure and calculates required quantities by part explosion. Inventory management checks available quantities for making net requirement. Received orders are regarded as fixed in MPS calculation. MRP makes production plan with MPS, BOM, and inventory information. CRP can adjust the production schedule considering production capacity by production line or work shop. The supplier may regularly send progress reports or reply for progress inquiry from the customer. They ship the products

202

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

Fig. 4. IDEF0 function model of order receiving (A0).

Fig. 5. IDEF0 function model of manage progress (A3).

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

quotation with XML using pseudo standards. Fig. 6 depicts developing process of pseudo standard documents (Electronic Business XML; Yoshinori, 1997).

according the contract and orders and release shipping notification. The shipping information also posts to finance department. The finance department prepares billing and they fix the invoice when they receive inspection results from the customer.

4.1. Standard documents When analyzing business processes of inter-enterprise EC, we also investigate the traditional documents exchanged between enterprises. The documents are gathered from real electronics assembly companies. These documents are compared with the extracted documents and their contents for outsourcing processes. Table 3 summarizes the extracted documents, which are listed according to the sequence of usage and correspondence from both sizes of by outsourcing and order receiving (Electronic Business XML; KEDIFACT, 1995; KTNET, 1995a). In this research, EDI document structure and contents for RFQ and quotation is developed. EDI structure of quotation is designed to give the sequence information when EDI system would translate and

4. Information model inter-enterprise integration Current standard EDI documents contain unnecessary items and require data repetitions when we adopt those to outsourcing process. The reason is that EDI is developed for general usage and trade. We analyze traditional documents that are used in outsourcing process of electronics assembly industry. With this approach, standard documents are extracted and their information contents are identified. We also analyze standard EDI documents for contents and structures. We develop pseudo standard documents for outsourcing with analysis results. Pseudo standard implies is used as the standard in our study. We implemented RFQ and

Fig. 6. Development process of standard documents.

Table 3 Document sequence in outsourcing vs. order receiving Outsourcing !

Sequence

Request for product catalog/company information Request for quotation Request for quotation change Outline contract Product data package Modified PDP/PDP confirmation Contract confirmation Outsourcing order Request for order change Request for progress report Expedite Receipt notification Inspection report/Request for return

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Payment notification

203

Order receiving Product catalog/company information Quotation Modified quotation Outline contract Request for engineering change PDP confirmation Contract confirmation Order confirmation Order change confirmation Progress report Shipping notification Invoice Payment confirmation

204

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

Fig. 7. EDI document structure of RFQ.

reverse-translate data transmission items. Fig. 7 depicts the EDI document structure of RFQ (KT-NET, 1995b). Also, the segment specification is specified according to the designed EDI document structure. Segment specification defines data element, composite data element, and code element that can fill the segment. Referring UN/EDIFACT syntax rules and message design guidelines we develop EDI document structure for RFQ of outsourcing processes. The EDI document for RFQ consists with message header, beginning of message, date/time/period, free text, reference, name/address, contact information, communication information, currencies, item line, additional product ID, item description, measurements, quantity, and message trailer. For example, Table 4 is the segment specification of message beginning in RFQ. 4.2. Design for XML-EDI In this work, XML is adopted for the efficient production and exchange of documents on the internet. The

types of documents used in ordinary enterprises are numerous various and there are many differences between inter-enterprise and intra-enterprise purposes. Suppliers have to follow the customer’s own requests by custom of outsourcing, which often causes re-entry and manual operations in documentation. In order to solve this problem, we defined the standard documents and develop standard exchange method based on XML. The documents along with processes are directly linked with internal database of enterprise. When the user selects the document, the document format is retrieved from format database. The pre-entered data are filled automatically through integration of internal and format database. Thus, it is possible to eliminate the repetitive entry and to input the only additional information. Each segment of produced documents are saved in document database. Saved segments are translated with XML by predefined DTD for each document. Fig. 8 describes the concept of XML-EDI translation (KEDIFACT, 1995; KT-NET, 1995a; KT-NET, 1995b). The company that received the XML EDI documents can retrieve them using DTD and XSL. DTD defines

Table 4 Segment specification of message beginning in RFQ BGM-M

1-Beginning of message

Function

Identify format and function of EDI document. Send related identification #.

Segment #

2

C002 Document/message name 1001 Document/Message name, coded) 1131 Code list qualifier 3055 Code list responsible agency, coded 1000 Document/message name 1004 Document/message number 1225 Message function, coded

Length C C an..3 C an..3 C an..3 C an..35 C an..35

KAN R R N N R

C an..3

P_1 ¼ RFQ

Order number by sender 2: 3: 4: 6:

C an..3

4343 Response type, coded

Description

N

Append Delete Modify Confirm

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

205

Fig. 9. Concept of XML–EDI de-translation.

Fig. 8. Concept of XML–EDI translation.

document format and XSL does document presentation. XML documents can be presented with ordinary web browsers. Fig. 9 shows the concept of de-translation with XML and EDI.

Traditional EDI systems require a dedicated program to translate and de-translate related information. The SGML based EDI systems also require special browsers to retrieve the documents. Our system, however, XML based EDI systems do not require special programs or browsers. This can be done by DTD and XLS that define format and representation of the documents. Fig. 10

Fig. 10. Illustration of DTD design for RFQ.

206

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

presents some portion of DTD design for RFQ as an illustration.

5. Prototyping of inter-enterprise electronic commerce 5.1. Prototype functions We define functional tree of internet based outsourcing management system from models of inter-enterprise EC and analysis of intra-enterprise functions. This system consists of master data management, EDI documents management, contract management, progress management, product information management, internal process support, and suppliers management. Fig. 11 describes the system function tree. Master data management deals the information about suppliers and products. It also manages the user’s information and permissions. Supplier information contains entire data for the supplier such as name, CEO, contact information, contract status, and credit information. Product information has the static information such as ID, specification, suppliers, functionality, and standard cost. Drawing information is dealt in product information management and there is a link to interface them. EDI document management is the essential function to implement the inter-enterprise electronic commerce. It can support to make the required document and translate it with XML. It can check the delivery of document if the supplier received it or not.

Contract management deals the RFQ and bid processes. It releases the RFQ or announces for bid. It manages the whole processes of quotation receipt, evaluation, selection, and final contract. Progress management deals the processes from order releases to good receipts. It release the outsourcing order according to the contract. It checks the progress of production and expedites. After goods receipts, it inspects the product and posts payment request to finance department. Product information management is related to engineering department. It manages the product data package and engineering change. It has the responsibility for releasing PDP and receiving engineering change request. Engineering change request is sent and reviewed by engineering department. After this it confirms PDP and maintains all change history. Internal process support integrates the outsourcing system with legacy systems such as production, inventory, quality, and finance system. Order request manages the requests from production department. It reviews and selects the items that need outsourcing. And it gives the progress information through progress management. Goods receipt is invoked by the shipping notification that is handed through delivery management. It checks the products and invoices and then posts the information to inventory management. Inspection examines the quantity, quality, and delivery date. This information is sent to quality management. We develop internal process support as the interface to integrate legacy system. The interface database is used to implement the loosely coupled system. This acts as buffer and

Fig. 11. System function tree.

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

interface area for information exchange between outsourcing system and legacy system. A dominant characteristic of outsourcing in electronics assembly industry is long term relationship. It is

207

important to have reliable and stable suppliers. So many companies try to support their suppliers. Supplier management can do these functions. It helps that suppliers are able to hold stable quality level and manage it.

Fig. 12. System architecture.

Fig. 13. Illustration for order release.

208

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209

Supplier management keeps track of quality and delivery. They may audit the quality assurance system and give related training. The information gathered from quality and delivery management feeds back to supplier’s credit management. 5.2. Implementation For implementation of the prototype system, we use a 3-tier application architecture model. The outsourcing company runs the server that operates the outsourcing documents and data. This server is implemented with Windows NT 4.0 as operating system, MS SQL server 6.5 as DBMS, and IIS 4.0 as web server. ASP 2.0 is used to implement business logic of the system. The client system is used by the outsourcing company and suppliers together. The required client systems are windows operating system and MS internet explorer 5.0 that support XML. Fig. 12 presents the system architecture. As a basic function, the server system offers document exchange between companies. It manages documents exchange and verifies the delivery of them. The server also manages the database that handles the intra-enterprise business process. Users can use stored data through web. This database plays key roles to integrate the business processes. Data entry can be distributed to all related processes. And it can also integrate the companies in intra-enterprise EC. The suppliers are usually small sized companies in electronics assembly industry. Many suppliers do not have their own information systems. So in this system the suppliers can manage the documents as file without database system. The unified interfaces are required to integrate the companies. Web server does this role. The users, either from the outsourcing company or suppliers, can access the system with only web browsers. This gives platform independent, any place and any time connection. Fig. 13 shows the screen for order release of the prototype.

6. Conclusion Recently global supply chain management and its outsourcing are widely spread. It becomes more important to make virtual enterprise environment. It makes true the efficient exchange and sharing of business and technology knowledge. The objectives of this research are to develop the reference model for internet based inter-enterprise electronic commerce and to implement a prototype system for testing fundamental issues such as business process, information standards, and information system integration. The electronics assembly process are chosen as target industry because it has more closer relationship and involves technological information exchange. For

modeling inter-enterprise EC with IDEFO, we investigate intra-enterprise business processes. It is found that standards for information and exchange method are essential elements to implement the inter-enterprise EC. We analyze the traditional documents for outsourcing and EDI documents to define standard information. We define standard documents and its items according to the developed model. For standard exchange method, we adopt web and XML. The web is to offer the unified interface environment for small sized companies that involved in this industry. We used XML to give platform independent representation of documents. XML would eliminate the need of special translate programs. We developed DTD and XSL for RFQ and quotation as examples. To prove the feasibility and effectiveness, the prototype systems is developed and implemented. We defined required functionalities for internet based outsourcing management system. As a result, a set of reference model is presented for inter-enterprise EC. They are reference architecture, standard documents, and standard exchange system. The prototype system can be expanded to achieve reduced time and cost, increased data accuracy, and easy suppliers management.

Acknowledgements This work is partially supported by the Postdoctoral Fellowships Program from Korea Science & Engineering Foundation (KOSEF).

References Bernus, P., Nemes, L., Williams, T.J., 1996. Architectures for Enterprise Integration. Chapman and Hall, London. Bin, W., Yunlung, C., 2000. A framework for strategically-driven evaluation of enterprise information systems. Int. J. Prod. Res. 38 (17), 4071–4084. CommerceNet., http://www.commerce.net. Doumeingts, G., Vallespir, B., Chen, D., 1995. Methodologies for designing CIM systems: a survey. Comput. Indus. 25, 263–280. Electronic Business XML (ebXML), http://www.ebxml.org. Fox, M.S., Gruninger, M., 1998. In: Enterprise Modeling, AI Magazine. AAAI Press, Fall, pp. 109–121. IDEF-0, integrated-computer-aided manufacturing definition, activity model, integration definition for function modeling, NIST FIPS pub 183, 31 December 1993. Internet supply chain partner interfaces: White Paper, http://www.rosettanet.org/press/white.html. Kalakota, R., Whinston, A.B., 1996. Frontiers of Electronic Commerce. Addision-Wesley, Reading, MA. KEDIFACT, 1995. KEDIFACT Directory (in Korean). Kosanke, K., 1995. CIMOSA – Overview and status. Comput. Indus. 27, 101–109. KT-NET, 1995. Handout for EDI documents (in Korean). KT-NET, 1995. MIG Analysis (in Korean). Object Management Group (OMG), http://www.omg.org.

K. Shin, C.S. Leem / The Journal of Systems and Software 60 (2002) 195–209 Open Application Group (OAG), http://www.openapplications.org. Orsolya, S., Sobah, A.P., 2000. Extended enterprise engineering – a model-based framework. Concurrent Eng. 8 (1), 32–39. Rosettanet., http://www.rosettanet.org. SAP., 1998a. Materials Management. Functions in Detail R/3 System in CD. SAP., 1998b. Sales and Distribution. Functions in Detail R/3 System in CD. Scheer, A.W., 1992. Architecture of Integrated Information Systems. Springer, Berlin.

209

Scheer, A.-W., 1994. Business Process Engineering-Reference Models for Industrial Enterprises. Springer, Berlin. Troy, J.S., Fu-Ren, L., Shaw, M.J., 1999. Business-to-business electronic commerce and convergent assembly supply chain management. J. Inform. Technol. 14, 361–373. Wil, M.P., Van, D.A., 2000. Process-oriented architectures for electronic commerce and interorganizational workflow. Inform. Syst. 24 (8), 639–671. Yoshinori, T., 1997. Implementation and evaluation of multi-media compatible EDI. In: Proceeding of CALS Expo International.