cpm: a collaborative process modeling for cooperative manufacturers

9
CPM: A collaborative process modeling for cooperative manufacturers Kwangyeol Ryu, Enver Yu ¨ cesan * Technology and Operations Management Area, INSEAD, Boulevard de Constance, 77305 Fontainebleau Cedex, France Received 10 April 2006; accepted 4 May 2006 Abstract In a manufacturing system, we need to capture collaborative processes among its components in order to clearly define supporting functions of a system. However, pervasive process modeling techniques, including IDEF3, Petri Nets, and UML, are not sufficient for modeling collaborative processes. Therefore, we have developed a novel modeling method referred to as collaborative process mod- eling (CPM) to describe collaborative processes. CPM models can be transformed into marked graph models so that we can use the anal- ysis power of Petri Nets. In this paper, we first briefly discuss these process modeling techniques. Then, we illustrate the CPM method and transformation rules with illustrative examples. CPM allows us to develop collaborative process models, understand and facilitate the realization of collaboration, and verify models before moving onto development. Ó 2006 Elsevier Ltd. All rights reserved. Keywords: Collaborative process modeling; Marked graph; Petri Nets 1. Introduction Highly volatile market conditions make it difficult for manufacturers to match supply with customer demand. In order to cope with this competitive and dynamically changing environment, the manufacturing industry requires collaboration in both internal and external opera- tions. A collaborative environment for manufacturing is an automated environment that enables people to collaborate and interact with each other for developing and achieving a new project regardless of their geographic locations, time, and interaction methods [1]. Endogenous collaboration includes operations between corresponding entities within a system with respect to hardware and software. For exam- ple, synchronization between processing machines and material handlers requires collaboration of hardware; whereas communication between control software and traveling agents, which gather relevant information, neces- sitates collaboration of software. Especially, industry requires technologies that guarantee interoperability among software systems in a distributed computing envi- ronment for collaboration of software [2]. On the other hand, exogenous collaboration means cooperation of high-level entities such as between departments or enter- prises. Most endogenous and exogenous processes have been discussed by researchers in manufacturing systems and supply chain management, respectively. We first start, however, by defining the involved pro- cesses and the individual responsibilities before consider- ing collaboration. To this end, we usually model processes or workflows to derive a common understanding from them. There are various tools or techniques perva- sively used for modeling processes such as IDEF3, Petri Nets, unified modeling language (UML), architecture of integrated information systems (ARIS), etc. Such tech- niques, however, are insufficient for describing collabora- tive practices because they have difficulty in representing multiple actors participating in each collaborative opera- tion while keeping consistency of the overall process. Such techniques usually generate process models containing actors with a limited boundary (e.g., multiple pieces of equipment in a single shop floor, individuals in a 1474-0346/$ - see front matter Ó 2006 Elsevier Ltd. All rights reserved. doi:10.1016/j.aei.2006.05.003 * Corresponding author. Tel.: +33 1 60 72 40 17; fax: +33 1 60 74 55 00. E-mail addresses: [email protected] (K. Ryu), enver.yucesan@in- sead.edu (E. Yu ¨ cesan). www.elsevier.com/locate/aei Advanced Engineering Informatics 21 (2007) 231–239 ADVANCED ENGINEERING INFORMATICS

Upload: kwangyeol-ryu

Post on 15-Jul-2016

218 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: CPM: A collaborative process modeling for cooperative manufacturers

ADVANCED ENGINEERING

www.elsevier.com/locate/aei

Advanced Engineering Informatics 21 (2007) 231–239

INFORMATICS

CPM: A collaborative process modeling for cooperative manufacturers

Kwangyeol Ryu, Enver Yucesan *

Technology and Operations Management Area, INSEAD, Boulevard de Constance, 77305 Fontainebleau Cedex, France

Received 10 April 2006; accepted 4 May 2006

Abstract

In a manufacturing system, we need to capture collaborative processes among its components in order to clearly define supportingfunctions of a system. However, pervasive process modeling techniques, including IDEF3, Petri Nets, and UML, are not sufficientfor modeling collaborative processes. Therefore, we have developed a novel modeling method referred to as collaborative process mod-eling (CPM) to describe collaborative processes. CPM models can be transformed into marked graph models so that we can use the anal-ysis power of Petri Nets. In this paper, we first briefly discuss these process modeling techniques. Then, we illustrate the CPM methodand transformation rules with illustrative examples. CPM allows us to develop collaborative process models, understand and facilitatethe realization of collaboration, and verify models before moving onto development.� 2006 Elsevier Ltd. All rights reserved.

Keywords: Collaborative process modeling; Marked graph; Petri Nets

1. Introduction

Highly volatile market conditions make it difficult formanufacturers to match supply with customer demand.In order to cope with this competitive and dynamicallychanging environment, the manufacturing industryrequires collaboration in both internal and external opera-tions. A collaborative environment for manufacturing is anautomated environment that enables people to collaborateand interact with each other for developing and achieving anew project regardless of their geographic locations, time,and interaction methods [1]. Endogenous collaborationincludes operations between corresponding entities withina system with respect to hardware and software. For exam-ple, synchronization between processing machines andmaterial handlers requires collaboration of hardware;whereas communication between control software andtraveling agents, which gather relevant information, neces-sitates collaboration of software. Especially, industry

1474-0346/$ - see front matter � 2006 Elsevier Ltd. All rights reserved.

doi:10.1016/j.aei.2006.05.003

* Corresponding author. Tel.: +33 1 60 72 40 17; fax: +33 1 60 74 55 00.E-mail addresses: [email protected] (K. Ryu), enver.yucesan@in-

sead.edu (E. Yucesan).

requires technologies that guarantee interoperabilityamong software systems in a distributed computing envi-ronment for collaboration of software [2]. On the otherhand, exogenous collaboration means cooperation ofhigh-level entities such as between departments or enter-prises. Most endogenous and exogenous processes havebeen discussed by researchers in manufacturing systemsand supply chain management, respectively.

We first start, however, by defining the involved pro-cesses and the individual responsibilities before consider-ing collaboration. To this end, we usually modelprocesses or workflows to derive a common understandingfrom them. There are various tools or techniques perva-sively used for modeling processes such as IDEF3, PetriNets, unified modeling language (UML), architecture ofintegrated information systems (ARIS), etc. Such tech-niques, however, are insufficient for describing collabora-tive practices because they have difficulty in representingmultiple actors participating in each collaborative opera-tion while keeping consistency of the overall process. Suchtechniques usually generate process models containingactors with a limited boundary (e.g., multiple pieces ofequipment in a single shop floor, individuals in a

Page 2: CPM: A collaborative process modeling for cooperative manufacturers

232 K. Ryu, E. Yucesan / Advanced Engineering Informatics 21 (2007) 231–239

department of a company, etc.) or without specifying anycorresponding actor.

The lack of power of pervasive modeling techniques fordescribing collaboration has motivated us to develop a newmodeling method, collaborative process modeling (CPM).By using CPM, we can (1) develop collaborative processmodels, (2) understand and facilitate the realization of col-laboration, and (3) analyze and verify models before mov-ing onto development. The application of the UMLframework in developing CPM elements provides full mod-eling power. Furthermore, transformation rules intomarked graphs make it possible to use the analysis powerof Petri Nets.

The paper is organized as follows: Section 2 reviews andcontrasts process modeling techniques. CPM is introducedin Section 3 along with transformation rules and illustra-tive examples. Section 4 offers concluding comments.

2. Review of process modeling techniques

2.1. Process modeling using IDEF3

IDEF was introduced as part of the integrated com-puter-aided manufacturing (ICAM) project in 1981; itcomprises IDEF0, IDEF1, IDEF1x, IDEF3, and othergraphically based modeling notations [3]. Among numer-ous IDEF methods, two of them serve as the basis fordescribing processes: IDEF0 and IDEF3. IDEF3 providesa structured method for expressing the domain experts’knowledge about how a particular system or organizationworks (i.e., process modeling); while IDEF0 provides amethod for defining which activities should be done in asystem or organization (i.e., function modeling) [4]. Themain strength of IDEF methods, including IDEF3, is notonly the simplicity of notation, but also the availabilityof well-defined tools with powerful expressiveness accord-ing to their purpose of modeling (e.g., IDEF0 for functionmodeling, IDEF1x for data modeling, IDEF3 for processmodeling, IDEF5 for ontology modeling, etc.).

IDEF3 describes processes as ordered sequences ofevents or activities including relations between time-basedbehaviors [3]. Even though it provides an easy way ofdescribing and understanding processes, IDEF3 is a staticmodeling method, not suitable for representing dynamicprocesses. The lack of tools for model verification is knownas a weakness of IDEF3. In modeling collaborative pro-cesses, IDEF3 has a limitation in identifying all partici-pants involved in collaboration, because activities in anIDEF3 model are normally regarded as done by a singleactor. Even though multiple actors can be indicated byusing referents, one of the elements used to represent addi-tional information, these actors may not be formallyincluded in the model (refer to the proper usage of referentsin [3]). As a matter of fact, integration of existing modelsdeveloped by using IDEF3 is extremely difficult becauseactors in each model are different and no relation betweenthem exists in the model.

2.2. Process modeling using Petri Nets

Petri Nets are widely used to design and analyze concur-rent processes utilizing shared resources (machines, equip-ment, operators, and so forth) [5]. A Petri Net (PN) isformally defined as a four-tuple C = (P,T, I,O), where Pis a finite set of places p, T is a finite set of transitions t,I and O are sets of input and output places of the corre-sponding transition, respectively. For example, It and Ot

are the input and output place of t.The dynamic behavior of a PN is defined by its marking

l, where l is a state vector with lp denoting the number oftokens in p. By tracing the flow of tokens, we can diagnoseor anticipate dynamically changing system states. Generalanalysis methods for PN include liveness (PN is classifiedinto five levels from L0 to L4 according to the degree ofstate transitions reachable from the initial state), bounded-ness (PN is bounded when the number of tokens in anyplace is finite in any marking), conservation (PN is conser-vative when the weighted number of tokens in any markingis fixed and finite), and consistency (PN is consistent ifthere exists a firing vector with all positive elements). A liveand consistent PN has a cycle, and this is a typical charac-teristic of manufacturing systems.

A marked graph is a PN in which each place has exactlyone input and one output [6]. PN can be referred to as amarked graph when PN fulfills the condition in Eq. (1)

pi 2 P ; jIpij ¼ jftjjpi 2 OðtjÞgj ¼ 1;

jOpij ¼ jftjjpi 2 IðtjÞgj ¼ 1 ð1Þ

A marked graph is suitable for modeling manufacturingsystems because of its cyclicality (i.e., it is a live and consis-tent PN). A cycle is represented as a sequence of transi-tions. For example, the cycle is tj1tj2 . . . tjk if there existspir for each tjr and tjr+1 in the sequence, which satisfiespir 2 O(tjr), pir 2 I(tjr+1), and tj1 = tjk. The cycle of a systemis consequently modeled with a closed path from a transi-tion which is returning back to the same transition.

Petri Nets provide a precise and powerful method formodeling concurrent processes. Similar to the case ofIDEF3, however, it is also difficult to use them for dealingwith collaborative processes. We can possibly represent allrelevant participants into a single Petri Nets model, or usecolored tokens to differentiate them. In any case, the num-ber of participants becomes the most important factor;hence the addition of a new one severely affects model com-plexity. When the model size becomes larger, the modelbecomes more difficult to build and read.

2.3. Process modeling using UML

UML is a de facto standard modeling language devel-oped by the object management group (OMG) to specify,visualize, and document models of software systems as wellas non-software systems [7]. It is an expressive, graphical,extensible, and visual modeling language [8]. UML is based

Page 3: CPM: A collaborative process modeling for cooperative manufacturers

K. Ryu, E. Yucesan / Advanced Engineering Informatics 21 (2007) 231–239 233

on the object-oriented paradigm, and enables the extrac-tion of architecturally significant elements of a model withrespect to different viewpoints, independent of the system’sscale [9]. UML has three main modeling viewpoints: usecase model, static model, and dynamic model [10].

UML is syntactically rich, user friendly, and flexible.However, it lacks the formality required to support simula-tion and analysis [11]. Many researchers, therefore, havetried to introduce other techniques (e.g., Petri Nets andIDEF) while using UML to compensate for its deficiency.There also exist formalization efforts focused on static ele-ments, leaving dynamic semantics almost untouched [11].In UML, there is a diagram for representing collaboration,referred to as collaboration diagram, which is nothingmore than another way of representing an activity diagram.Activity diagrams have limited ability to describe collabo-rative processes; when a process is conducted by two par-ticipants, we can locate the process on the border line of‘‘swimlanes’’. In case of more then three participants, itbecomes more difficult to represent the process withswimlanes.

2.4. Process modeling using ARIS

Architecture of integrated information systems (ARIS)is the technique for modeling business processes and pro-vides the method called event-driven process chain (EPC)[12]. EPC is used as a component of modeling processesin SAP R/3 (SAP AG), LiveModel/Analyst (IntellicorpInc.), and Visio (Visio Corp., MicroSoft Corp.) as well asin ARIS (IDS Prof. Sheer GmbhH). A process representedby EPC is the connection of events using logical connectors(e.g., AND, OR, XOR) and functions. eEPC (extended

Table 1Comparison of process modeling methods (IDEF3, Petri Nets, UML, and AR

Criteria IDEF3 Petri Nets

Generalcharacteristics

Simplicity forusing method

Very easy Fairly easyon its versio

Model complexity Very simple Fairly simpwith a big s

Model understandability Very easy Mostly diffiStandardization Strong Very weak (Formalism Not existing or

very small(elaboration)

Existing stro

Collaborationprocessmodeling

Representability Not very large Very large

Dynamics Limited(temporal linksand junctions)

Strong

Collaboration Impossible Possible (bubecome very

Multiple actors Impossible Possible (buand comple

Model verification Impossible Powerful (wModel simulation Impossible Possible

EPC) supports process modeling by using EPC compo-nents with business objects and organization units. ARIShas five modeling views (i.e., function, organization, data,output and control) supported by the ARIS toolset. Espe-cially, it is possible to represent actors of each process byusing the organization view, which is necessary for express-ing multiple participants of collaborative processes.

Similar to IDEF3 and UML, there is no direct methodto verify the model for consistency, completeness, etc.For this, van der Aalst [13] developed a method whichenables model transformation from EPC into Petri Netsby mapping an event to a place and a function to a transi-tion. However, his research is limited to the transformationof an EPC model, which does not include organizationentities. To the extent that a collaborative process is con-ducted by multiple organization entities, his work doesnot support the transformation of collaborative processes.Considering multiple actors in the model is importantbecause pre or post processes related to a collaborativeprocess may be differently performed based on the strategyof each organization.

2.5. Comparison of IDEF3, Petri Nets, UML, and ARIS

IDEF3, Petri Nets, UML, and ARIS are modeling tools,developed with a proper aim and specifications, thereforethey have individual pros and cons. Differences amongthree methods are summarized in Table 1.

As depicted in Table 1, only ARIS provides a separatetool (i.e., organization symbol) for representing multipleactors of a process. This means that collaborative processescan be modeled by using ARIS. Even though it is possibleto simulate ARIS models for estimating execution time of

IS)

UML ARIS

dependingn

Fairly easy Easy

le (but complexize model)

Simple Simple

cult Easy Easymany versions) Fairly strong Strongng formalism Partially existing

(e.g., OCL)Not existing orvery small (elaboration)

Fairly large(restricted to diagrams)

Fairly large

Limited (temporal relationsbetween entities or objects)

Limited (withlogical connectors)

t modelscomplex)

Limited (withcollaboration diagram)

Possible (withorganization symbol)

t unclearx)

Limited (with swimlane) Possible (withorganization symbol)

ith formalism) Impossible ImpossibleImpossible Possible

Page 4: CPM: A collaborative process modeling for cooperative manufacturers

234 K. Ryu, E. Yucesan / Advanced Engineering Informatics 21 (2007) 231–239

tasks or searching for a bottleneck point, the verification ofthe process model itself is not directly possible. Petri Netsare more powerful to represent dynamic behavior thanother methods. Petri Nets are complicated for modelingcollaborative processes, and have lower readability thanother methods. However, they have superior analysis capa-bilities based on a strong formalism. Therefore, coupling ofPetri Nets with other methods has been attempted in liter-ature in order to compensate for the weakness of thesemethods and exploit the analysis methods of Petri Nets.For example, research for this purpose includes the com-plementary use of UML [11] or IDEF [5] with Petri Nets,the transformation of UML models into Petri Nets [13–15], and the transformation of ARIS models into Petri Nets[13]. Some researchers have tried to employ IDEFapproaches to compensate for the deficiencies of UML[10]. These four modeling methods are often used in a com-plementary fashion, which indicates that it is reasonable touse multiple modeling approaches.

We introduce a novel modeling approach, referred to ascollaborative process modeling (CPM), applying the UMLactivity diagram notation. We have also developed a ruleset for transforming a CPM model into a marked graphto take advantage of the analytical power of Petri Nets,which make it possible to verify process models. As high-lighted in Table 1, CPM brings together the desirable char-acteristics of the various modeling methods within a singleframework.

3. Collaborative process modeling (CPM)

3.1. CPM definition

In order to model collaborative processes, we firstclassify collaboration into two types: intra- and inter-collaboration. Intra-collaboration is cooperation betweendifferent groups within the same organization, andinter-collaboration occurs in operations between different

Table 2CPM elements

Intra-collaboration processActor_IDs

Decision

Horizonsynchro

Process

Symbol Description Symbol Descrip

Resour

Referen

Inter-collaboration processActor_IDs

Normal processActor_ID

organizations [16]. Based on the type of collaboration,workflows or security strategies are applied differently toorganizations. CPM is the methodology to model collabo-rative processes among multiple actors with different affili-ations. Normal process modeling is also possible withCPM. CPM has the following characteristics:

• CPM is process-oriented.• CPM elements are based on UML notation, and consist

of eight elements (refer to Table 2).• CPM is an easy-to-understand process because normal/

intra-collaboration/inter-collaboration processes arerepresented with different symbols.

• The processes carried out by corresponding participantscan be modeled in a single CPM model, and each partic-ipant is explicitly identified in the models.

• CPM models can be transformed into marked graphmodels so that analytical methods of Petri Nets can beused.

In CPM, we use a rounded rectangle and an edgedrectangle for intra- and inter-collaboration, respectively.Normal processes are illustrated by using a common rect-angle. Symbols for decision, synchronization, process tran-sition, resources, and reference note look familiar sincethey are often used in an ordinary sequence diagram.

Explicit Indication of all participants in a collaborativeprocess makes it possible to keep track of responsibilityfor monitoring and conducting collaborative works duringtheir operations. Even though CPM has no element fordirectly representing a state of processes or a system asin an activity diagram of UML, we can grasp state transi-tions by understanding the flows between processesinstead.

Collaboration modeling with CPM can clearly identifythe participants in charge of reporting or performing tasksby representing all participants in collaboration. CPM con-siders three kinds of actors including Company, Depart-

tal and verticalnization

transition

tion

ce

ce note

Page 5: CPM: A collaborative process modeling for cooperative manufacturers

Table 3Participants in Fig. 1

Company/Department Description

C1 Part production companyd1 Strategic planning teamd2 Part design teamd3 Part production teamd4 Marketing team

C2 Mold design companyd1 Marketing/technology teamd2 Mold design teamd3 Purchasing/procurement team

C3 Mold production companyd1 Marketing/strategy teamd2 Mold production and management teamd3 Quality management team

C4 Engineering service companyd1 Engineering service team1

K. Ryu, E. Yucesan / Advanced Engineering Informatics 21 (2007) 231–239 235

ment, and Individual. Rules for representing Actor_ID(s)

in Table 2 are as follows:

• Company: C = {ciji = 1, . . . , l}, Di � C.• Department:

Di ¼ fdijjdi

j 2 ci; i ¼ 1; . . . ; l; j ¼ 1; . . . ;mg; P ij � Di:• Individual: P ij ¼ fpij

k jpijk 2 di

j; i ¼ 1; . . . ; l; j ¼ 1; . . . ;m;k ¼ 1; . . . ; ng:

Based on this definition of actors, Actor_ID(s) of eachprocess can be represented as follows:

• Normal process: ciðdijðp

ijk ÞÞe.g., hc1ðd1

3ðp132 ÞÞi

• Intra-collaboration process: ci(Di) or ciðdi

jðP ijÞÞe.g.,hc1ðd1

2ðp123 Þ; d1

3ðp131 ÞÞi; hc1ðd1

2ðp123 ; p

124 ÞÞi

• Inter-collaboration process: Ce.g., hc1ðd12ðp12

3 ÞÞ;c2ðd2

1ðp213 ; p

214 ÞÞi, hc1ðd1

1ðp113 Þ; d1

2ðp121 ; p

123 ÞÞ; c2ðd2

1ðp213 ; p

214 ÞÞi

3.2. Illustrative CPM

By using the CPM elements in Table 2, Fig. 1 showsan illustrative process model, which represents collabora-tive works conducted by multiple mold companies. Tomanufacture a mold, a product must be designed firstby using CAD software. Then, each part and assemblyof a mold is designed reversely from the product design.When a mold manufacturer gets a mold design, mold pro-duction is ready to be started. The CPM model in Fig. 1briefly illustrates these processes. Participants indicatedin the model are listed in Table 3. Note that shaded pro-cesses indicate that they contain sub-processes; any pro-cess can be decomposed in this manner, similar toIDEF. Also note that numbered processes (i.e., – ) areused for model transformation discussed in the nextsection.

c1(d12)

Design drawing & mockup development

c1(d11, d1

2)

Design review

c1(d13)

Product design(2D & 3D)

c1(d11, d1

2, d13)

Revision and final evaluation of product design

c1(d13), c4(d 4

1)

Design evaluation through engineering services

PDM

c1(d14)

Bidding and selection of a moldcompany

c1(d13), c2(d

21)

Investigation ofproduct design and structure

c2(d22)

Modelingmolding pfinal assem

c2(d21, d2

2)

Verification and transformation of model data

DW

satisfiable ?[No]

[Yes]

satisfiable ?[No]

[Yes]

c1(d11, d1

2)

Concept & Ideasketch of a product

Fig. 1. An illustrative CPM model of collab

3.3. Transformation of the CPM model

3.3.1. Transformation rules and procedure

Process models developed using CPM can be trans-formed into Petri Nets models. However, it is impossibleto get a direct mapping of eight elements of CPM ontoPetri Nets, since Petri Nets consist of only four components(i.e., transitions, places, arcs, and tokens). Therefore, wefirst define marked graph building blocks (MGBB) with acombinatorial use of Petri Nets components, as illustratedin Table 4. CPM models are then transformed into markedgraph models by replacing CPM elements with correspond-ing MGBB and following the transformation rules. Thedetailed procedure for model transformation is as follows:

Step 1 Remove reference notes from the CPM model,since they are not defined as MGBB.

after gettingmold from contractor

of arts and bly

c1(d14), c2(d2

3)

Selection ofmaterial for moldbase

c1(d12, d1

3), c3(d3

1)

Consent to molddrawings

c3(d32)

Production planningand scheduling

c3(d31, d3

2)

Decision of outside order or self-production

c3(d32)

Making parts of a mold

c3(d33)

Inspection and post-processing

decision ?

[outside order][self-production]

c3(d32, d 3

3)

Completion of a moldprocess by assemblingparts of a mold

DW1 2

3

4 5

6

orative works among mold companies.

Page 6: CPM: A collaborative process modeling for cooperative manufacturers

Table 4Marked graph building blocks (MGBB)

intra-collaborationprocess

inter-collaborationprocess

normal process

decision

synchronization

process transition

resource

Symbol Marked Graph Building Block

(split-type)

(join-type)

(all places)

(link places to transitions)

(link to transition)

ending mark(additional)

(end)

(start)- link to first transitions

[ P0 ]

[ P1 ]

[ P2 ]

[ P3 ]

Input forextension

Output forextension

236 K. Ryu, E. Yucesan / Advanced Engineering Informatics 21 (2007) 231–239

Step 2 Choose a level of detail for marked graph models.Company, Department, and Individual levels areavailable for the transformation.

Step 3 Replace the CPM elements with MGBB to gener-ate marked graph models. A selection rule isused to choose a proper MGBB of a process.When Department (or Individual) is selected forthe transformation level, it is possible to make alink between processes of different departments(or individuals) if and only if they belong to thesame company. At this point, we have to insertan additional MGBB, i.e., ‘‘synchronization’’(either split-type or join-type) between boundaryprocesses of different department (or individual).Note, however, that ‘‘synchronization’’ is not nec-essary for the links to ‘‘decision’’ or ‘‘endingmark’’.

Step 4 Complete the transformation by adding an ‘‘endingmark’’ between the transition(s) of the MGBB indi-cating the first process and the place(s) of theMGBB meaning the last process. When adding an‘‘ending mark’’, it is possible to make a connectionbetween processes of actors if their upper-levelorganization is same (e.g., different individuals inthe same department, or different departments inthe same company).

Table 5 illustrates the rules for selecting a proper MGBBfor each collaborative process. For example, when theCPM model is to be transformed and Company_level isselected for transformation level, then [P0] will be usedfor representing normal and intra-collaboration processes,and [P1] for inter-collaboration processes in the model.Note that the same building block [ P0 ] is used for normal

Page 7: CPM: A collaborative process modeling for cooperative manufacturers

Table 5MGBB selection rules for process transformation

Process Level

Company Department Individual

Normal process [P0]Intra-collaboration process [P0] [P1] [P2]Inter-collaboration process [P1] [P2] [P3]

121p

12d

13d

122p

132p133p

131p

12d

13d

121p122p

132p133p

131p

Fig. 3. Illustrative representation of hc1ðd12ðp12

1 ; p122 Þ; d1

3ðp131 ; p

132 ; p

133 ÞÞi.

K. Ryu, E. Yucesan / Advanced Engineering Informatics 21 (2007) 231–239 237

processes regardless of the transformation level, becausethey are conducted by a single actor. Here, P0–P3 are thebuilding blocks represented in Table 4. P1 is the MGBBextended from P0 by adding ‘‘Input for extension’’ to theinput transition of P0 and ‘‘Output for extension’’ to theoutput place of P0. By doing so, P1 can illustrate actorswho belong to the organization represented in P0. Like thismanner, P2 and P3 can be defined by extending P1 and P2,respectively.

While replacing processes with [P1]–[P3], we need todecide how many input transitions and output placesshould be generated corresponding to the types of processand the transformation level. Let N(x) be the total numberof x who participate in a collaboration process. When wedivide [P3] into four sections as illustrated in Fig. 2, [P3]consists of x0–x3, [P2] consists of x0–x2, and [P1] consistsof x0 and x1. According to the type of process and thetransformation level, the number of input transitions andoutput places in each section is determined as illustratedin Table 6. Note that all normal processes and intra-collab-oration processes at Company_level are not consideredsince each number of transition and place is always one.Also note that the number of transitions and places inthe section of x0 is fixed, thereby we do not mention it inTable 6. For example, the intra-collaboration process rep-resented by hc1ðd1

2ðp121 ; p

122 Þ; d1

3ðp131 ; p

132 ; p

133 ÞÞi can be repre-

sented as in Fig. 3. The number of transitions or places

Table 6Rules for generating transitions and places

Process Level

Company Department Individual

Intra-collaborationprocess

– x1 x1 x2

NðdijÞ Nðdi

jÞ Nðpijk Þ

Inter-collaborationprocess

x1 x1 x2 x1 x2 x3

N(ci) N(ci) NðdijÞ N(ci) Nðdi

jÞ Nðpijk Þ

section x0section x1

section x2section x3

Fig. 2. Sections in [P3].

in synchronization, decision, and ending mark also canbe determined following the same manner by consideringthe number of actors who get involved.

3.3.2. Illustrative transformation of CPM model

Following the procedure and the rules of transformationintroduced in the previous section, we have transformedthe numbered processes in Fig. 1 to the marked graphmodel. Fig. 4 illustrates the resulting transformation, whichshows the initial markings of the marked graph. Note thatwe have chosen Company_level for the transformation.Tokens are inserted only into places indicating resourcesand start processes. For enhanced readability, we havemarked circled numbers and callouts on marked graphmodels to indicate the corresponding processes in Fig. 1and the relevant companies or teams.

A transformed model generally consists of sub-modelscorresponding to its level of detail. For instance, the resul-tant model shown in Fig. 4 is just one of marked graphmodels focusing on the company c3. If we transform all ele-ments in Fig. 1, then we could get three Marked Graphmodels centered on c1, c2, and c3 (except for c4 becauseof insufficient information). In a similar fashion, we canderive several models with different point of views from asingle CPM model.

Fig. 5 depicts the resulting transformation with the sameCPM model but with a different level of detail, namelyDepartment_level. As the main participants of processesare the teams of c3, the connection of the places for theirprocesses is revealed as a closed loop. We can check thecycle of processes and monitor their states by firing

ending mark decision

(start)

(end)

resource

c3

c1

c3

c1

1

4

2 3

56

Fig. 4. A transformation result at Company_level.

Page 8: CPM: A collaborative process modeling for cooperative manufacturers

(start)c3

d 33

d32

d32

d33

d 33

d 32

d 32

d31

d 31

d32d3

2

d31

d31

d13

d12

d 31

d 12

d 13

c3

c1

ending mark decision

(end)

resource

c3

c1

1

5

4

6 3

2 3

Fig. 5. A transformation result at Department_level.

238 K. Ryu, E. Yucesan / Advanced Engineering Informatics 21 (2007) 231–239

transitions. Obtaining marked graph models enables us toanalyze the system with various Petri Net methods. This,however, is omitted in this paper. The resulting transfor-mation at the individual level is also omitted since we canobviously obtain them by applying the same rules withMGBBs expanded for the Individual_level.

4. Concluding remarks

Many systems or organization have processes necessitat-ing cooperation with others. Such collaboration should beplanned, deployed, and managed with the right tool ormethod. The first step of any project generally involvesbuilding models from various perspectives. We concentrateon process models since the project is a succession of pro-cesses. To construct process models, various pervasivemodeling techniques or methods are used such as IDEF3,Petri Nets, UML, ARIS, etc. However, these techniquesare not sufficiently powerful to exactly model collaborativeinitiatives undertaken simultaneously by multiple partici-pants. This is shown by the comparison in Section 2.4together with a brief literature review. Therefore, we havedeveloped a new modeling method referred to as CPM.

In CPM, a total of eight elements have been definedbased on the notation of UML activity diagrams. UsingCPM is as simple as IDEF3, but it has high power of rep-resentation like UML. By transforming CPM models intoPetri Net models, we can analyze or verify the models withanalytical methods of Petri Nets. However, we have notexplicitly dealt with the analysis of the models.

CPM has following characteristics; (1) modeling itself isstraight forward, (2) CPM models are highly readable, (3)actors involved in each collaborative process are readilyrecognizable, (4) it supports the design of efficient schedulesand workflows by identifying in advance collaborationopportunities, and (5) analysis of a model is possible bytransforming it into a marked graph and using the methodsof Petri Nets.

As an application of the CPM method, we have success-fully derived collaborative activities as a form of a ‘‘busi-ness template’’ from the CPM models, and templates arenow under implementation as a web-based hub systemfor on-line collaboration among Korean mold industry.

CPM has a weakness for modeling collaborative pro-cesses from various viewpoints since it is process-oriented.Furthermore, CPM still remains a conceptual method,which has not yet been deployed as computer software.In the project mentioned above, modeling and model trans-formation has been conducted manually. Therefore, thedevelopment of web-based CPM software will be pursuedto automate these time-consuming tasks.

Acknowledgements

This work was supported by the Korea Research Foun-dation Grant funded by Korea Government (MOEHRD,Basic Research Promotion Fund) (M01-2004-000-20378-0)as well as by the Foreign Ministry of France and EGIDE.We would like to express our gratitude for their support.

References

[1] W. Shen, Editorial, Special issue on collaborative environments fordesign and manufacturing, International Journal of AdvancedEngineering Informatics 19 (2) (2005) 79.

[2] S.C. Feng, K.A. Stouffer, K.K. Jurrens, Manufacturing planning andpredictive process model integration using software agents, Interna-tional Journal of Advanced Engineering Informatics 19 (2) (2005)135–142.

[3] R.J. Mayer, C.P. Menzel, M.K. Painter, P.S. deWitte, T. Blinn, B.Perakath, Information Integration for Concurrent Engineering(IICE) IDEF3 process description capture method report, KnowledgeBased Systems Inc., 1995.

[4] NIST, Draft federal information processing standards publication183. Integration definition for function modeling (IDEF0), 1993.Available from: <http://www.idef.com>.

[5] K. Santarek, I.M. Buseif, Modelling and design of flexible manufac-turing systems using SADT and Petri Nets tools, Journal of MaterialsProcessing Technology 76 (1998) 212–218.

Page 9: CPM: A collaborative process modeling for cooperative manufacturers

K. Ryu, E. Yucesan / Advanced Engineering Informatics 21 (2007) 231–239 239

[6] K. Thirusangu, K. Rangarajan, A note on the construction of markedgraphs, Information Processing Letters 55 (1995) 211–215.

[7] J. Rumbaugh, I. Jacobson, G. Booch, The Unified ModelingLanguage Reference Manual, Addison-Wesley, 1999.

[8] S.S. Alhir, UML in a Nutshell, O’Reilly & Associates Inc., 1998.[9] K. Ryu, Y. Son, M. Jung, Modeling and specifications of dynamic

agents in fractal manufacturing systems, Computers in Industry 52 (2)(2003) 161–182.

[10] C. Kim, R.H. Weston, A. Hodgson, K. Lee, The complementary useof IDEF and UML modelling approaches, Computers in Industry 50(2003) 35–56.

[11] L. Baresi, Improving UML with Petri Nets, Electronic Notes inTheoretical Computer Science 44 (4) (2001) 1–13.

[12] A.W. Sheer, Business Process Engineering, ARIS-Navigator forReference Models for Industrial Enterprises, Springer, Berlin, 1994.

[13] W.M.P. van der Aalst, Formalization and verification of event-drivenprocess chains, Information and Software Technology 41 (1999)639–650.

[14] K. Han, A workflow analysis using the transformation of an UMLactivity diagram into a Petri Net, IE Interfaces 17 (2) (2004) 200–207(in Korean).

[15] J.P. Lopez-Grao, J. Merseguer, J. Campos, From UML activitydiagrams to stochastic Petri Nets: application to software perfor-mance engineering, in: Proceedings of the 4th International Work-shop on Software and Performance (WOSP ’04), CA, USA, 2004, pp.25–36.

[16] K. Ryu, H. Choi, S. Lee, Framework of e-collaborative engineeringservices for mold companies in Korea, in: Proceedings of IMSInternational Forum 2004, Italy, 2004, pp. 1128–1137 (Part 2).