a time/cost trade-off method for scheduling - Semantic Scholar

International Journal of Electronic Business Management, Vol. 2, No. 4, pp. 201-209 (2004)

201

A PROCESS-ORIENTED METHODOLOGY FOR DESIGNING THE LOGISTICS SERVICE PROVIDER'S INFORMATION SYSTEM Brian Wang1,2, Hsing-Pei Kao1* and Jason Huang2 1 Institute of Industrial Management National Central University Chungli (320), Taiwan 2 e-Business Integration Section Taiwan Semiconductor Manufacturing Company Hsinchu (300), Taiwan

ABSTRACT The Logistics Service Provider (LSP) industry is undergoing radical change which focuses on the entire supply chain between manufacturers, warehouses, distributors and the ultimate clients. Due to the complexity and size of service coverage is increasing in meeting a great variety of stakeholder requirements, the LSP has to fully utilize information system that facilitates the transmission and processing of data as well as supporting decision-making regarding strategy, tactics and real-time operations. Hence, the LSP needs a comprehensive methodology to analyze and design the information system to meet business needs. This study proposes a process-oriented methodology for designing the information system of LSP. The systems life cycle design methodology is adopted as the general approach whereas Software Quality Function Deployment and business process design techniques, including Enterprise Ontology and Unified Modeling Language, are applied for detailed design. Keywords: Logistics Service Provider, Software Quality Function Deployment, Enterprise Ontology, Unified Modeling Language

*

1. INTRODUCTION

The common perception of LSP is undergoing a change due to two main reasons. First, there is increasing interaction of transport and value-added logistics services. Second, providing successful logistics solutions is becoming more dependent upon Information Systems (IS), process optimization capabilities and, consequently, knowledge [20]. Recognizing these developments, we take a broad view of the definition of a LSP provided by Arthur Andersen Consultant [1]: “All companies that provide transport, forwarding, warehousing, commissioning, knowledge-based supply chain related advisory and other truly transport-related services are regarded as being part of the logistics service provider”. The development of IS should start from business analysis and process design and modeling [19]. Business Process Modeling (BPM) is a technique used for describing, documenting and analyzing the businesses processes. Business process

models are created with the business users to produce an intuitive, non-technical model representing their perspectives of how the business is or should be conducted. In other words, these models form a basis for IS design and business process improvement. Figure 1 shows how BPM provides information about the structure of IS with needed functions and interface in terms of business objects, products, actors and activities.

Actors

Business Process Model Business Activities

Corresponding author: [email protected]

＊Object ＊Attributes ＊Line history ＊Hierarchy of objects ＊Relationships among objects ＊Mutual behavior

Products Actors

＊ I/O functions ＊ Dialogue functions ＊ Interface function etc. ＊ Function hierarchy

Object Model

Process Model Transaction Techniques (Design Rules)

Conceptual IS Model Usability Requirements

＊buffering needs ＊ user views ＊ data sets

Real World Structure

Real World Behavior

Top-Down Function Structure

Logical Database Structure Technology Constraints and Requirements and Database Design Rules

Technical IS Model

*

Products Business Objects

Program Modules Structure Technology Constraints/Requirements Program Design Rules

Figure 1: Process analysis for IS development

International Journal of Electronic Business Management, Vol. 2, No. 4 (2004)

202

Besides BPM, information engineers begin to apply Software Quality Function Deployment (SQFD) and Ontology Engineering (OE) in the development of the enterprise-wide and usually geographically distributed IS to support various processes. To improve the quality of software systems and its development process, SQFD is adopted throughout the system development life cycle. As a visual methodology, SQFD uses matrix forms to align the business priorities, the design features, and system specifications. Additionally, according to the benchmarked target values, the system designers establish objective metrics to indicate acceptable quality [14]. In brief, ontology is a structured representation of the information and, more exactly, is a domain vocabulary together with a set of precise definitions, or axioms, that constrain the meanings of the terms in that vocabulary sufficiently to enable consistent interpretation of statements that use that vocabulary [13]. Regarding IS development, the predefined ontology will enable consistency and commonality through the interoperability of processes, systems, and databases. As a general approach, ontology engineering should be performed once the goals and objectives of an enterprise have been decided and prior to the process analysis and design [22]. Figure 2 shows where SQFD and ontology engineering might logically fit in the development process and how they might interconnect with other development and engineering activities. SQFD Resources, Organizationa l Culture

Define Goals, Objectives, and Metrics

Enterprise Goals, Objectives & Metrics

A1

Development Enterprise Ontology A2

Ontology Database

Model Enterprise Processes A3

IDEF 5

Past Experience Existing Infrastructure

IDEF 0, 1X, 3 & Simulatio n

Optimal Processe s

Reengineering Processes &

Implement Supporting IT Process, Infrastructure Changes, Build Systems Integrate A4 Technical, Functional & Organizational Levels A5 CASE Tools

Decision Support

Technical Int. Tools Cognitive Learning

Integrated IT Systems & Functions; Trained & Staff

Initiate Operations & Measures

Successfully Operating Enterprise

A6

Figure 2: Ontology engineering process This study proposes a process-oriented methodology for designing the information system of LSP (POM_LSIS). The systems life cycle design methodology is adopted as the general approach whereas SQFD and business process design techniques, including Enterprise Ontology, Objected-Oriented (OO) Models, and Unified Modeling Language (UML), are applied for detailed design.

2. SYSTEM FRAMEWORK OF LSP The complete architecture of a LSP’s logistics system is a composition of logistics network, processes, and information system. To develop the methodological framework, we extend the Generic Value Chain proposed by Dantuma [8] to define the value chain of LSP (Figure 3). S t a k e h o ld e r s R e q u ir e m e n t

O r ig in o f L o g is tic s S e r v ic e

P r o c e s s in g

I n fo r m a t io n S y stem o f L S P

P ro cess M anagem ent

T ra n sp o rt

S t o r a g e a n d /o r V a lu e - a d d e d L o g is t ic s A c t iv itie s

D e s t in a t io n o f L o g is tic s S e r v ic e

L o g is tic s N e tw o r k N o t a t io n :

I n f o r m a tio n F lo w

M a te r ia l F lo w

S ig n if ic a n t R e la tio n

Figure 3: Value chain of LSP According to [6,10], the logistics system should be initiated based on the stakeholders’ requirements; “stakeholders” at here refer to the partners who have interests or stakes in the partnership and the power to influence the design of the network and information system. They may include clients who request and receive service from the LPS and the members performing internal and external processes in the logistic network. While stakeholders’ requirements are varied, they are classified according to several characteristics, including services, regions, types of delivered items, pricing, and time (Figure 4). * Different purchaser and receiver * Optional delivery addresses, home or office * Option to request delivery time: -specific time -hrs -just in time * Quick Response, order to delivery * Home Delivery * Delivery pre-advise -note -call * Consolidation required

* Returns and refusals * Claims * Final assembly * Installation * After sales services * Customer Service and Help Desk * Payment modes -Credit and account cards -Prepaid -Invoice * Accurate delivery * Order completeness/damage free

Figure 4: Requirements of logistics services In general, the shipment orders (concerning the origin and destination of the delivered item) are placed by the clients to the LSP. Accordingly, the LSP needs to determine the role of intermediates in the

203

B. Wang et al.: A Process-Oriented Methodology logistics network to fulfill the order as per the client’s requirement. According to Dantuma [8], the steps of logistic service can be classified into: (1) Processing, which involves receiving and processing client’s order, planning the distribution of the shipments, and packing the item for its destination. (2) Transport, which involves moving the item from place to place, either directly to its final destination, or to an intermediate position in the logistics network. (3) Storage and/or Value Added Logistics, which is an optional intermediate stage in the process that can be used to add further value to the delivered item. There are several tools applicable for logistics process mapping [4]. As shown in Figure 5, the matrix approach is adopted for its simplicity to represent the linkages between logistics service steps, members and categories of the logistic service. Steps of Logistic Network Members of Logistic Network

Processing

Logistics Service Provider

Transport

Logistics Service Partner A

Storage and/or VAL

Logistics Service Partner B...N

Usually ontology engineering is executed before analyzing business process and designing the IS. Based on the ontology model, we will have a clear view about the LSP with respect to its position in the supply chain and internal organization and operations. The ontology model will ensure the consistency among development stages while keeping the generality of the methodology for various LSPs. In Figure 9, we adopt the ontology engineering of IDEF5, developed by [13], to define the development stages the LSP Ontology. Why

How

What

Where exchanges

Application

produces

Data

Technology

Information System Entity

uses

Customer’s Requirements

Actor

requires

NonInformation System Entity

requires

Operation

Types of LSP Carrier

Who

Resource

is performed by

Location

Figure 6: Procedure for designing the information system architecture

Forwarder

Information System Development Principles Enterprise Ontology Principles

Express Logistic Provider

Storage Provider

ICT Provider

BPM Principles OOA & OOD Rules

Figure 5: Types of intermediates In the Zachmen framework [25], an Enterprise Architecture Framework is a generic classification scheme for designing information systems. Adopting the concepts of the framework and matrix representation, we start from modeling the operational flows of logistics. Then we identify the performers who are responsible for executing certain operations, and match each operation to an application method (or methods). Finally we identify the needed data or technology for each application method. Following this “operation ↔ performer ↔ application ↔ data ↔ technology” mapping procedure, we are able to clearly portray the overall architecture of the information system. Figure 6 shows the meta-model of this procedure and the relationships between entities.

3. DEVELOPMENT OF LSP ONTOLOGY

Literature Surveys about LSP

Develop the Process-Oriented IS of LSP A0 UML

IDEF 5

PCD

Software QFD

Figure 7: Top level of POM_LSIS Information System Development Principles

Enterprise Ontology Principles


Develop LSP Ontology A1

Meta LSP Ontology Model

BPM Principles

OOA & OOD Rules

Integrate System Analysis and Design A2

Specifications of the IS

IDEF 5 ARIS

SQFD

Here, we present all information and principles required in the development process. The development stage and I/O relations of top level are represented in Figure 7, which is further decomposed into two sub-functions shown in Figure 8.

Specifications of the IS

UML

Figure 8: Second level of POM_LSIS To develop the ontology model, we firstly survey a great number of LSP websites and existing studies. Accordingly, we identify and specify objects


204

by using the object-oriented concepts to analyze the collected documents. These object entities are categorized into two groups: (1) Supply Chain Level, which involves all the members in the supply chain. Each member in the supply chain executes a defined role and interacts with others. We divided these members into three main types: origin of logistics service, intermediates (include LSP and its partners), and destination of logistic service. (2) Enterprise Level, which focuses on the LSP itself. At this level, we specify the types of services LSP could provide and what kinds of processes should be designed for satisfying the stakeholders’ requirements. The defined objects can be further categorized as non-information system entities and information system entities. In addition, the relationships between objects can be expressed from the process perspective. Figures 10 and 11 show the meta LSP ontology model and the meta model of logistics service process.

Summary of Surveys

Study LSP Industries A11

Object Classes

Identify and Specify Objects A12

Identify and Classify Relations

Relation Matrices

A13

Refind and Validate Ontology A14

Meta LSP Ontology Model

Figure 9: Development stages the LSP ontology IntermediateLogistics Service Partner

Origin of Logistics Service

fetches goods from

Destination of Logistics Service

delivers goods to

cooperates with

Level 1－

delivers goods to

fetches goods from

provides

Supply Chain

Intermediate-LSP

meets

develops

manages

Client’s Requirement

Logistics Service Process is created by

Level 2Enterprise (LSP)

meets fits facilitates

Logistics Service

Solution

Figure 10: Meta LSP ontology model Operation consumes

triggers produces

is performed by

Location

Non-Information System Entities

Actor

Application

utilizes

utilizes

Resource houses

For the system analysis and design, we adopt the concepts from Rational Unified Process (RUP), which is a comprehensive UML and OO focused methodology, to generate four models: Requirement Model, Business Model, Process Model, and Object Model (Figure 12). Enterprise Ontology Principles Literature Surveys about Express Logistic Provider Meta LSP Ontology Model

Construct Business Model A21

Information System Development Principles Business Model of Express Logistics Provider

Construct Requirement Model A22

SQFD Matrices

Business Process Management Principles

Construct Process Model A23

Software Quality Function Deployment (SQFD)

Event-driven Process Chain (EPC)

Process Models

OOA & OOD Rules

Construct Object Model

Specifications of POM_LSIS

A24

UML

Data Flow Diagram

Entity Relationship Diagram

Figure 12: Object-oriented system analysis model

Enterprise Ontology Principles


4. INTEGRATED SYSTEM ANALYSIS AND DESIGN

exchanges

Data

uses

Technology

Information System Entities

Figure 11: Meta model of logistics service process

Business models act as a blueprint to construct the information system. In the business model, we clearly define the organization structure, functions, applications, location, data, technology and resources of the LSP. The goal of requirement model is to describe what the system should do and allows the developers and the stakeholders to agree on that description. At here, the stakeholders include system owner, system users, system designer, system builders, system analyst, and IT vendors and consultants [24]. A business process is a set of activities that are executed in order to achieve a business objective; this objective is usually to offer the right product or service to a client with a high degree of performance measured against cost, longevity, service to a client [12]. Process modeling is a technique for organizing and documenting the structure and flow of data through a system’s process and/or the logic, policies, and procedures to be implemented by a system’s process. Object model is a way of representing systems and components of a system using the object-oriented concepts. An object model contains a set of business objects, applications, process, actor, data and their relationships. These objects together form a class structure that is the logical design view of all (or part of) a software system. In Object-Oriented Analysis (OOA), we clearly define all objects in the system. The steps of OOA include identify objects, identify attributes of object and establish relationship among objects. In Object-Oriented Design (OOD), the specifications of LSP_IS include process model, component model, actor model and meta model.

B. Wang et al.: A Process-Oriented Methodology

205

5. IMPLEMENTATION OF POM_LSIS

We use “service” and “region” to categorize the clients’ requirements since these two factors can be used to validate the distribution architecture. As an example, we choose one pattern (International Air Service between Region A and region C) as the input to the requirement model. Table 3 shows client’s requirement patterns and Table 4 shows requirement-to-role assignment.

In this section, we demonstrate how the proposed methodology POM_LSIS is applied with a simplified case for the Express Logistics Service Provider (ELSP). An ELSP operates large fleets of aircraft for pick and delivery services as well as what are termed express logistics hubs, which are in turn linked to air-freight or road-freight centers. Figure 13 shows the general structure of the logistics network (at the supply chain level).

Table 3: Example of client’s requirement patterns Single Region Region

Region Region Region A

Consignor

Value Added Logistics Provider

B

Region

Region

Region

C

(A~B)

(A~C)

(B~C)

Consignee

Storage Provider (Express Hub)

Forwarder

Road Carrier

Figure 13: General structure of the logistics network for express logistics provider

Freight Service

Service Nexe-day air

●

○

●

△

●

△

Second-day air

○

●

△

○

●

○

○

○

○

△

●

△

△

△

△

●

●

●

○

○

●

△

●

●

○

○

○

△

△

△

△

△

△

●

○

●

Ground

deliver

service International air

Value Added Services

Express Logistics Provider

MultipleRegions

Electronic tracking Delivery confirmation Customs clearance service

●: Strong ○: Medium △: Weak

At the enterprise level, we focus on the definition of entities of process. An example is shown for one entity of process in Table 1. We furthermore summarize the attributes of the specialization of this Entity. Take vehicle routing and scheduling as an example, Table 2 shows the summaries of the attributes of the specialization of the Method.

Table 4: Example of requirement-to-role assignment Role

International Air (Region A) International Air

Transportation Planning Application (Parent: Process)

(Region A to Region C)

Description Order consolidation

Method

Vehicle routing and scheduling Carrier rate management Carrier selection.

Input Output Status

Data Information Being used Completed

Table 2: Example of the specialization of entity Vehicle Routing/Scheduling Method (Kind: Transportation Planning)

Attribute Objective Precondition Input Output

Description Minimize total cost Transportation order has been received Transportation order and constraints Assignment of vehicles, their departure time and sequence of client visits

Value-added Forwarder Storage

Road

Logistics

Logistics

Provider

Carrier

Provider

Provider

(Express

Pattern Segment

Table:1 Example of entity Attribute

Express

International Air (Region C)

Hub)

∗ ∗ ∗

∗

∗

∗

∗

∗

∗

As aforementioned, SQFD is an effective way to approach the initial information collection in the information system development. The POM_LSIS construction includes five stages (Figure 14). Since the requirement-to-role assignment patterns have been defined, they will be the “How” of the first phase in part I. The Operations will be “what” of the first phase. In second phase, the Operations can be decomposed into Activities. In third phase, the relationships between Activity and Actor have been described. In fourth phase, we have defined the needed Data of Activities. In fifth phase, the relationships between Data and Technology are depicted. Tables 5 and 6 show some partial results from SQFD.


206 Function Role

Activity

Actor

Operation

Activity

Data Activity

Technology Data

Figure 14: Hierarchy of SQFD matrices Table 5: First phase of SQFD matrix Operation

A. Pre- sales

Role Express Logistics Provider

B. Planning

Order

Transportation

Warehouse

Processing

Planning

Planning

1…n

1…n

Value-added Service

1…n

Provider

In the process model, it is important to develop complete and consistent process representations. Figure 15 indicates the hierarchical relationship between operation flows by presenting the detailed process sequence in terms of events, activities, data and actors. This process combines the results of second, third and fourth phases of SQFD matrices. Figure 16-A to 16-E show five phases of the process model development. (1) Phase 1: (Pre-)sales Operations: establish the agreement between Consignor and Express Logistics Provider. (2) Phase 2: Planning Operations: collect data and translate into information about the chain members. (3) Phase 3: Physical Operations: model physical operations (transport, transshipment and storage). (4) Phase 4: Monitor and Control of Operations: check any unexpected accidents and respond. (5) Phase 5: Administrative Operations: Issue invoice and payment.

Forwarder Storage Provider (Region A)

1…n

Road Carrier (Region A)

Function 1

First Layer

Function 2

Function 3

Function 4

Function 5

1

Storage Provider (Region C)

1…n Event 3.1

Road Carrier (Region C)

1 Second Layer

C. Physical Operation Transportation

D. Monitoring/ Controlling

Material

Shipment

Fleet/ Vehicle

Handling

Control

Monitoring

1…n

1…n

Data

Activity 3.1

Actor

Event 3.2

E. Administration Reporting Invoicing 1…n

Actor

1 Activity 3.3.1

Activity 3.3.2

Event 3.3.1

Event 3.3.2

1…n 1…n

1…n

0…n

0…n

1

0…n

0…n

1

Figure 15: Hierarchy of process model

1…n 1…n

F u n c tio n

Function

P re -s a le s

Table 6. Sceond phase of SQFD matrix (partial) Vehicle

Carrier

Carrier

routing and

selection

scheduling

scheduling

Shipment

Consignor


Transportation (Express Logistics

Origin

1

T ra n s p o rta tio n P la n n in g

O rd e r P ro c e s s in g

E x p re ss L o g is tic s P ro v id e r

O rd e r M a n a g e m e n t


S to ra g e P ro v id e r (R e g io n C )

and routing

1…n

O rig in

R o a d C a rrie r (R e g io n C )

consolidation scheduling

Operation Planning

C o n s ig n o r

Role

Shipment

P la n n in g

R o le

Pre-sales

Activity

Data

1…n

Order Processing Order Management

W a re h o u s in g P la n n in g

F o rw a rd e r




S to ra g e P ro v id e r (R e g io n C )

W a re h o u sin g P la n n in g

Figure 16-A

Figure 16-B

Provider) Transportation Planning (Road

F u n c tio n P re -s a le s

C o n s ig n o r

1

S to r a g e P ro v id e r (R e g io n A )

Transportation (Road Carrier-Region C)

1

P h y s ic a l O p e ra tio n

T r a n s p o r t a t io n P la n n i n g

T ra n s p o rt a ti o n

O rd e r P ro c e ssin g O rd e r M anagem ent

F u n c tio n P re -s a le s

W a re h o u s in g P la n n i n g

W a re h o u s in g

F o rw a rd e r






S to r a g e P ro v id e r (R e g io n C )

W a re h o u sin g P la n n i n g

W a re h o u s in g

S to r a g e P ro v id e r (R e g io n A )

T r a n s p o r ta ti o n P la n n i n g


F le e t a n d V e h ic le M o n i to ri n g

O rd e r P ro c e ssin g O rd e r M anagem ent

S h ip m e n t P ro g ress C o n tro l T r a n s p o r ta ti o n P la n n i n g


W a r e h o u s in g

F o rw a rd e r







S to r a g e P ro v id e r (R e g io n C )


W a r e h o u s in g

C o n s ig n e e

Figure 16-C

M o n ito rin g a n d C o n tro llin g


D e s tin a tio n

C o n s ig n e e

P h y sic a l O p e ra tio n

O rig in

R o a d C a rrie r (R e g io n A ) E x p re ss L o g is tic s P ro v id e r


P la n n in g

R o le C o n s ig n o r

O rig in

R o a d C a rrie r (R e g io n A ) E x p re ss L o g is tic s P ro v id e r

Carrier-Region A) Planning

P la n n in g

R o le

D e s tin a tio n

Figure 16-D

207

B. Wang et al.: A Process-Oriented Methodology Function

Pre-sales

Physical O peration

Planning

Role

Consignor

M onitoring and Controlling

A dm inistrative O peration

Origin

Road Carrier (Region A )

Transportation Planning

T ransportation

Fleet and Vehicle M onitoring

Invoicing

Shipment Progress C ontrol

Invoicing

Order Processing


Order M anagement

Customer Order Customer_order_id quantity date_received delivery_date delivery_location consignor_id consignor_name status

Invoice (To Customer) invoice_id customer_order_id issuer date_time amount discount type of payment payment_term tim_unit status

integer integer date date string integer string [issued, accepted, refused, completed paid]

integer integer string date integer integer integer integer [d, m] [issued, paid requested]


Storage Provider (Region A )

W arehousing Planning


Forw arder

Invoicing

W arehousing

Forwarding Order Fleet and Vehicle M onitoring

T ransportation

Road Carrier (Region C )


T ransportation

Storage Provider (Region C )

W arehousing Planning

W arehousing

Fleet and Vehicle M onitoring

Invoicing

Invoicing

Invoicing

Destination

Consignee

forw_order_id order-id commodity quantity_goods package_type gross_weight net_weight volume date_delivered date_pickup forwarder_id transp_op_id forwarder_name status

Figure 16-E: Complete process model

integer integer integer integer integer integer integer integer date date string integer string [issued, accepted, refused, completed paid]

Invoice (From Forwarder) invoice_id forwarder_order_id issuer date_time amount discount type of payment payment_term tim_unit status

integer integer string date integer integer integer integer [d, m] [issued, paid requested]

Figure 19-B: Object diagram

The final stage of the methodology is to constructing the Object Model. According to the procedure in Figure 17, the object model could include various sub-models as shown in Figure 18 and Figures 19-A to 19-G.

Department of Transport

Department of Transport Planning

Plant

Vehicle scheduling

Document preparation Movement

Uploading

Unloading

Identify Class, Objects

Class Diagram

Receiving

Receiving

Space determination

Storage

Storage

Identify Attributes of Objects Department of Warehouse Planning

Object Diagram

Establish Relationship among Objects

Information Flow

Department of Warehousing

Material Flow

Figure 19-C: Activity model

Figure 17: Procedure of building business object model Application Model (Component Model)

Data to Technology Matrix

Figure 19-D: Objects of method

Role to

Data Model (Data Flow Diagram)

Business Object Model Operation and (Class & Object Operation to Activity to Diagram) Activity

Data Matrix

Activity Model (Activity Diagram)

Transportation Service (from Plant 1~3 to DC A)

Matrices

Activity to Actor Matrix

Vehicle Scheduling Transportation Planner

Actor Model (Use Case Diagram)

Document Preparation

Transportation Management System

Transporter

Figure 18: Relations of object models

Receiving Warehouse Operator

Physical Logistics Function

Space Determination Warehouse Planner

Warehouse Management System

Storage

Order Processing

Customer Service

Transportatio n

Warehousing

Material Handling

Figure 19-A: Class diagram

Packaging

Figure 19-E: Use case diagram


208

Application Component

LSP_IS Subsystem

Transportation Management System Subsystem

Inventory Management System

Subsystem

Warehouse Management System

Process Control

Interaction Control

Dialogue Control

Subsystem

Order Management System

Business Class Fundament

Data Management

al Classes

Figure 19-F: Component diagram Database

Transportation D ocumentation

Document Preparation O rder Information

Logistics N etw ork

D ate

Vehicle Scheduling

Movement

S cheduling Result

Q uantity

S cheduling Result Record

Database

Figure 19-G: Data flow diagram

6. CONCLUSION Although LSPs have become increasingly more important in the integrated supply chain, there are only few researches pertaining to their business models, operational processes, and information systems. In this paper, we propose a process-oriented methodology for designing logistics service information system which integrates Business Process Modeling and System Analysis/Design. By paying proper attention to both theory and the practicality, this methodology consists of the prevalent methods to customize the IS of LSPs. Based on the current study, there are several issues remain to be studied, including the evaluation of the Enterprise Ontology model, the reengineering of LSP process, and project management to design the LIS.

REFERENCES 1. Arthur Andersen Corporate Finance Logistics Group, 2001, Mergers & Acquisitions in the Logistics Industries. 2. Benjamin, P. C., Menzel, C., Mayer R. J., Fillion F., Futrell M. T., DeWitte P. S. and Lingineni, M., 1994, Ontology Capture Method (IDEF5), College Station, TX, Knowledge Based Systems, Inc. 3. Bowersox, D. J. and Closs, D. J., 1996, Logistics Management: The Integrated Supply Chain Process, McGraw-Hill Companies, Inc. 4. Bowersox, D. J., Closs, D. J. and Cooper, M. B., 2002, Supply Chain: Logistics Management, McGraw-Hill Companies, Inc. 5. Coyle, J. J., Bardi, E. J. and Langley, C. J., 1996, The Management of Business Logistics, 6th Edition, West Publishing Company. 6. Damen, F. T. W., 2001, “Service-controlled agile logistics,” Logistics Information Management,

Vol. 14, No. 14, pp. 185-195. 7. Damen, Z., Nijenhuis, W. and Verwijmeren, M., 1999, Transport Scenario Description, Cross-Organisational Workflow, ESPRIT E/28635. 8. Dantuma, L. M. Y. and Hawkins, R. W., 2001, TNO Strategy, Technology and Policy, TNO Report, TNO and Telematica Institute. 9. Farquhar, A., 1997, Ontolingua Tutorial, Knowledge Systems Lab, Stanford University. 10. Georgiadis, D., Shinakis, M. and Tyrinopoulos, Y., 2001, The Design and Implementation of a Demand Driven Freight Transport Application. 11. Ham, A. V. D. and Demakes, R., 2001, Function Specifications and Architecture Development, Telematic Application Programme Transport Sector. 12. Jacobson, I. 1995, The Use Case Construct in Object Oriented Software Engineering, In J. M. Carroll (ed) Scenario-based Design: Envisioning Work and Technology in System Development. Pub: John Wiley and Sons. 13. Knowledge Based System Laboratory, 1994, IDEF 5 Method Report, Knowledge Based Systems, Inc. 1408 University Drive East College Station, Texas 77840. 14. Lamia, W. M., 1995, “Integrating QFD with object oriented software design methodologies, QFD Symposium. 15. Lauber, J., and Jablonsky, J., 1999, Mathematical Modeling of Distribution Networks, University of Economics, Department of Econometrics. 16. Leu Investment Research, 2001, “Sector report logistics Europe: From muscle power to brain power,” Bank Leu. 17. Presley, A. R., 1997, “A representation method to support enterprise engineering,” Doctor Philosophy, The University of Texas at Arlington. 18. Price Water House Coopers, 1999, “Logistics management service opportunities for Ireland,” Strategic Development of Internationally Traded Service Industries through Ireland. 19. Repa, V., 1999, “Business process based information system development,” Paper for BIS99 Conference. 20. Sauvage, T., 2003, “The relationship between technology and logistics third-party providers,” International Journal of Physical Distribution & Logistics Management, Vol. 33, No. 3, pp. 236-253. 21. Scheer, A. W., 1999, “Business process engineering: reference models for industrial enterprise,” Second, Completely Revised and Enlarged Edition, Springer-Verlag. 22. Slattery, N. J., 1997, “A study of ontology and its uses in information technology systems,” Software Engineering & Economic Conference. 23. TRD International Cranfield University, 2001, TR

B. Wang et al.: A Process-Oriented Methodology 5001 ARTEMIS Final Report. 24. Whitten, J. L., Bentley, L. D. and Ditteman, K. C., 2001, System Analysis and Design Method, McGraw-Hill Companies, Inc. 25. Zachman, J. A. 1987, “A framework for information systems architecture,” IBM Systems Journal, Vol. 26, No. 3.

ABOUT THE AUTHORS Brian F. Wang is the section manager of e-Business Integration Section, TSMC. He is currently a doctoral student of the Institute of Industrial Management at National Central University, Taiwan where he earned a MBA degree in 1998. He has 6 years of experience in implementing ERP and SCM systems in Telecommunication and Semiconductor industries.

209 His research interests include ERP, SCM and Logistics Management. Hsing-Pei Kao is an Associate Professor affiliated with the Institute of Industrial Management at National Central University, Taiwan R.O.C. He received his Ph.D. degree in Industrial Engineering at Clemson University in 1992. His current research interests include SCM, MES, BPM, and Concurrent Engineering. Jason J. Huang is a System Engineer with Commodity and e-Business Department, TSMC. He holds a MBA in Industrial Management, National Central University, Taiwan. (Received September 2004, revised November 2004, accepted December 2004)